Redundant Keycloak Realm Api call to resolve user groups in Rb, Query and Audit

Query service uses Keycloak realm to resolve user groups via Rest for every task list request using https://github.com/Activiti/activiti-cloud-service-common/blob/448c871049dcececd7df279c4613e32966f3f22f/activiti-cloud-services-common-identity-keycloak/src/main/java/org/activiti/cloud/services/identity/keycloak/KeycloakUserGroupManager.java#L87 .

Because JWT access token does not contain the list of effective user groups:

{
  "jti": "bcd08573-d4d5-4ad8-8c65-8913e9388ec5",
  "exp": 1558536769,
  "nbf": 0,
  "iat": 1558536469,
  "iss": "http://activiti-cloud-gateway.staging.35.223.143.26.nip.io/auth/realms/activiti",
  "aud": "activiti",
  "sub": "784ca026-cfaa-422c-88e8-b7565515ff71",
  "typ": "Bearer",
  "azp": "activiti",
  "auth_time": 0,
  "session_state": "2fd790dd-c27e-46fb-a7de-d99f2e152ad5",
  "acr": "1",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "offline_access",
      "ACTIVITI_USER",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "email profile",
  "email_verified": false,
  "name": "h r",
  "preferred_username": "hruser",
  "given_name": "h",
  "family_name": "r",
  "email": "[e-mail]"
}

It is not optimal to do that for every request, because it is slow and impacts overall response time when calling Rest Apis.

Another problem is that Keycloak Admin client is instantiating RestEasy Http Client with default connection pool of maximum 10 connections:

https://github.com/keycloak/keycloak/blob/da85cff53b239250fa880e086b2721ba41a9a1e8/integration/admin-client/src/main/java/org/keycloak/admin/client/Keycloak.java#L72

This configuration creates ThreadPoolExecutor with limited number threads in the pool which will cause blocking with more than 10 concurrent requests:;

This is likely the reason of a connection timeout when Task Controller tries to connect to Keycloak to extract realm data to get user roles.

To solve this problem we can use Keycloak User Groups mapper to inject the list of user groups into extra claims inside JWT token below.

[rgauss]

It is the best practice to limit TTL of the access token to under 60 seconds to mitigate any security risk.

We’ve discussed that as well and may change the default lifespan in the future, and ADF based apps will actually check for an active Keycloak session every 30 seconds to ensure no logout has occurred, but we may encounter use cases where even 1 min is too long.

Here is the implementation of fallback KeycloakClientPrincipalDetailsProvider

Looks great, thanks.

I can run tests and provide performance results comparison between embedded and non-embedded group claim, in a few days.

That would be very helpful, thanks.

we should consider removing Keycloak Admin Client wrapper from Rb at some point, because it represents security backdoor into Keycloak Realm via Rest Api using admin user credentials provided in the Rb configuration properties.

We definitely don’t want to expose ‘super’ admin credentials, though we will likely need a form of client credentials (hopefully rotating) for other reasons (one of which may be user impersonation) and can enable use the client service account to read the user / group information.

And again, we still need to accomodate the use case of a user being a member of 100s or 1000s of groups and I don’t think we want to pack that into a JWT so we’ll need a fallback at a minimum.

Also, JWS could be used to encrypt the JWT if there is need to protect sensitive information.

You’re probably referring to JWE, and we considered that as well, but are more likely to use obfuscated public tokens with a public-private token exchange at the API gateway in the future.

[igdianov]

Yes, here is the capture of the Claim Task operation that made additional Search by user name Rest Api call to resolve subject UUID. It has also been making additional Rest call to get user roles…