PBENCH-865 First pass at implementing OIDC token decode framework

[npalaska]

First pass at implementing the authentication framework for decoding third-party identity provider tokens. This PR is not replacing the current authentication mechanism we have right now, this PR is for adding a framework that we can adopt slowly in our authentication flow as we go.

Addresses issue PBENCH-865

Presently this PR provides the following things:

• Validating OIDC tokens
• Decoding OIDC tokens online and offline
• Getting userinfo from userinfo oidc endpoint
• Revoking the token
• Logging out of the third-party identity provider session

[dbutenhof]

Good start; just a few minor comments.

[portante]

Great start. How are you thinking it would integrate along side our existing auth mechanism?

[npalaska]

How are you thinking it would integrate along side our existing auth mechanism?

This shouldn't bring many changes in terms of how we authenticate the REST endpoints, REST endpoints would still have a decorator that checks the validity of the Bearer access_token and performs the required action.

However, following subsequent changes will happen (that I can think of):

• Our current auth mechanism uses JWT to encode the tokens, we will drop this one completely.
• We will drop our active_tokens table entirely.
• We need to decide whether we need to keep the users table or completely drop it.
  • We can keep the users table and fill the user information extracted from the access token into the users table and then implement groups and roles ourselves to manage externally logged-in users along with our internal users.
  • We extract the user information from the third party tokens and create a user identity in our Keycloak instance with the user information provided from the token. This will help us in leveraging roles and groups for externally logged-in users as well.
• On the dashboard side there will be 3 ways a user can log in
  • Via Redhat SSO, where a Pbench dashboard redirects user to the Redhat SSO login page and gets the token back on behalf of the user. We don't have any control over the token generation and the user information it contains.
  • Via our Keycloak instance, where Pbench dashboard redirects user to our Keycloak instance login page. We have full control over the sessions and tokens of these users.
  • via third-party identity provider like Google/Github etc, where a Pbench dashboard redirects user to the third-party identity provider login page and gets the token back on behalf of the user. Like Redhat SSO we don't have any control over the token generation and the user information it contains.
• Once the Pbench server has the access token generated by any of the above methods, the REST endpoint decorator will introspect the token to check its validity and gather the user information. This is where access to our endpoints can either be granted to denied.
• Users that use Pbench CLI to generate tokens like pbench_token_generate should still be able to use the CLI to generate tokens. However, these tokens will be generated with a confidential client as opposed to a public client like pbench-dashboard.
• Users can still be able to create their identity in our Keycloak instance via CLI with the Pbench-server confidential client.
• On the server Instance, an admin user should be able to use Click CLI to do the actions like create roles, and groups, add users to groups/roles, assign roles to groups, update/delete users, and manage user sessions (only for those who logged in with our Keycloak instance), etc.

[riya-17]

Looks good

[webbnh]

Under the assumption that Nikhil is about to make a major revision to this PR, I'm going to stop reviewing now and just post what I've got.

[npalaska]

I still remain unconvinced we'll only be using the access token from Keycloak only, but that is just me.

Sure we don't want to be restricted to decoding only one type of token, but this framework can be extended to decode any identity tokens, not just the Keycloak broker. We should be able to decode any token that is generated by the OIDC-compliant identity providers.

[portante]

Sequence diagram changes look okay to me.

[webbnh]

The diagram looks great!

However, I found one misspelling, and I think it would look better if you terminated the flow instead of letting it run off the bottom of the page. Also, there is one pair of somewhat mismatched labels which would be good to make match.

Beyond those, I found some capitalization and other typographical nits that you might want to consider amending.

[npalaska]

Addressed the minor typos.

[webbnh]

🚀