Use keycloak tokens instead of generating our own ones when serving client auth requests

[alexeykazakov]

No description provided.

[alexeykazakov]

Keycloak doesn't support User profile images so we will need to generate gravatar URLs in api/user/show.
We also would like to keep the existing functionality which allows us to generate our own JWT tokens for the existing and future tests only.

[alexeykazakov]

Another problem to solve. We are currently using "uuid" as a unique userID in JWT key which maps to uuid DB primary key for Identity. But keycloak use it's own users ID and unique user names and returns it in the token as "sub" and "preferred_username" claims.

We could solve it by saving the keycloak's "sub" value in Identity.uuid when creating an Identity instead of generating a new uuid in DB or introducing a new attribute to the model object + a field in DB - "username".
"username" will be more consistent in terms of it's usage in both our and RHD keycloaks. "Sub" is generated in the particular keycloak instances and "sub"s in our keycloak and in the RHD for the same user will be different. If we clean up our keycloak's DB then a new "sub" will be generated when it fetch a user from the RHD IDP. But username is always the same (and unique) everywhere. Not sure if we care ;)

I would try to use the "sub" value as Identity.uuid for now... @aslakknutsen @kwk any thoughts?

[kwk]

@alexeykazakov can you please give examples of how the tokens look like in the different systems, or can you add pointers to the documentation of each system's user/identity representation? That would simplify the discussion a lot.

[alexeykazakov]

Here is an example of payload from KC token:

{
  "jti": "9bc92321-e8ca-4c60-8a18-af64668917b8",
  "exp": 1485321165,
  "nbf": 0,
  "iat": 1485320865,
  "iss": "http://localhost:8180/auth/realms/demo",
  "aud": "fabric8-online-platform",
  "sub": "a3cec17d-e3bb-4ef2-9feb-9bcbefc85552",
  "typ": "Bearer",
  "azp": "fabric8-online-platform",
  "auth_time": 1485320379,
  "session_state": "ca915331-705e-4cf7-8ffe-7a25429aab47",
  "acr": "0",
  "client_session": "0067d3ad-a963-41b8-9e4b-15d22c28d1c8",
  "allowed-origins": [],
  "realm_access": {
    "roles": [
      "uma_authorization"
    ]
  },
  "resource_access": {
    "account": {
      "roles": [
        "manage-account",
        "view-profile"
      ]
    }
  },
  "name": "Alexey Kazakov",
  "preferred_username": "igels",
  "given_name": "Alexey",
  "family_name": "Kazakov",
  "email": "igelsss@gmail.com"
}

[alexeykazakov]

Here is a suggestion for updated User/login model and how we can fit it in our IDPs models.

What we currently have is:

Identity (represents a user)

• uuid (generated automatically) - This uuid is used as "creator" and "assignee" in our payloads and it's also stored in the JWT token we generate after authentication.
• fullName (human name - string)
• avatarImage (URL string)
• users []User (list of associated users, each user just represents a email)

User

• uuid (generated automatically)
• email (just a string)
• identity-uuid (Identity association)

Proposed model:

User (represents a user account in our system)

• uuid (generated automatically) - Our internal user ID. Used for associations with Logins
• fullName (human name - string)
• avatarImage (URL string)
• logins []Login (list of associated logins)

Login I actually don't like this name. Can we call it Identity Provider User or somewhat else to avoid confusions? This is a representation of user provided by some particular Identity Provider such as: a) Our Keycloak; b) GitHub (for remote WI's); c) JIRA (for remote WI's), etc.

• uuid - Generated automatically for remote WI but in case of KC the uuid from the KC user is used. This uuid is used as "creator" and "assignee" in our payloads and it's also represented in the KC token we retrieve from KC during authentication. So, our token is always associated with a Login.
• username (string) - Username used by corresponding IDP. It's not unique in our system (it's supposed to be unique for the particular IDP though).
• email (string)
• idp (string) - Some IDP key/ID which will indicate from what IDP we got this Login. Possible values: "keycloak", "github", "jira", etc.

When a user is logging in we authenticate in our Keycloak (which uses developers.redhat.com as the default IDP). A new Login is created. We use uuid of the Keycloak user. idp="keycloak". We also create a User and associate these User - Login. We return the retrieved Keycloak token which will be used by UI for authentication. So there is a strong assassination between a token and a keyclaok Login.

When we import a remote WI (from JIRA, github, etc) we create a Login which is not associated with any User yet. Open question: how we associate remote WI's (imported from github, etc) with User. We would need some manual workflow for that.

This update will requre a massive refactoring in almighty-core (and ui probably too) :-(