...

kubectl -n infrastructure edit statefulset keycloak

containers:
  - args:
    - -Dkeycloak.profile.feature.token_exchange=enabled
    - -Dkeycloak.profile.feature.admin_fine_grained_authz=enabled

curl -k ^
  -d "client_id=admin-cli" ^
  -d "username=root" ^
  -d "password=changeme" ^
  -d "grant_type=password" ^
  "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/token"

curl -k ^
  -H "Content-Type: application/x-www-form-urlencoded" ^
  -d "client_id=admin-cli" ^
  -d "requested_subject=cc14e5d4-e8da-4108-92ad-c87066aed4c3" ^
  -d "subject_token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJueEZ..." ^
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" ^
  "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/token"

curl -k ^
  --request GET ^
  --url "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/userinfo" ^
  --header "accept: application/json" ^
  --header "authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAi1dXVSZ3daQldhTTJZaXNlZElFXzg..."

...

As standard, the installation is done by means of a Helm chart. Two demonstration tenants are created and configured automatically. Further tenants for productive use have to be added and configured manually.
>> /wiki/spaces/YMY/pages/320049969>> Installation Guide

The manual installation and configuration of Keycloak for yuuvis® Momentum API are broadly described here.

...

Note: For productive use, it is recommended to connect Keycloak to a different relational database management system (RDBMS) instead of the embedded standard H2. Suggestions for compatible RDBMS are provided by Keycloak: https://www.keycloak.org/docs/latest/server_installation/index.html#database.

Keycloak: Tenant and User

...

• Call the Keycloak Admin Console: http://localhost:8080/auth/admin/
• Select the tenant and and add the host name of the web page via Realm Settings > Security Defenses > Content-Security-Policy > frame-ancestors.
  Multiple host names are seperated by blank spaces.

Impersonation

In order to allow users with a specific role to log in as any other user, impersonation can be activated in Keycloak. Thus, users with this specific role can use their own password to log in to the account of any other user within their tenant. In Keycloak, the feature is realized via impersonation by means of token exchange.

Activating Token Exchange

• Open the StatefulSet of Keycloak in your Kubernetes cluster for editing by running the command:

  Code Block
  language bash
  kubectl -n infrastructure edit statefulset keycloak

  
  

• Extend the containers section as follows:

  Code Block
  language yml
  containers: - args: - -Dkeycloak.profile.feature.token_exchange=enabled - -Dkeycloak.profile.feature.admin_fine_grained_authz=enabled

  
  

• Restart Keycloak.

Configuring the User Account and Keycloak Clients

• Call the Keycloak Admin Console: http://localhost:8080/auth/admin
• Select the user you want to grant access to other user accounts and switch to the Role Mappings tab.
• Display the Client Roles for the realm-management client and assign its impersonation role to the user.
• In the same realm, select the client admin-cli and switch to the Permissions tab.
• Flip the Permissions Enabled switch to ON.
• In the appearing table, click token-exchange in the scope-name column.
• From the Create Policy selection list in the Apply Policy section, select Role.
• Name it impersonation-policy.
• From the Realm Roles selection list, select the administrative role that will enable users to impersonate other users within their tenant. Tick the Required checkbox.
• From the Clients selection list, select realm-management.
• From the Client Roles selection list, select impersonation. Tick the Required checkbox.
• Save the configuration for the policy.
• Save the configuration for the permission settings.

Testing Impersonation with cURL

The following commands use an administrative user root with the password changeme belonging to the tenant tenant1 with the impersonation authorization as configured before. This user requests access to the account of the user specified by the ID cc14e5d4-e8da-4108-92ad-c87066aed4c3.

• Request a token for the administrative user with the impersonation authorization:

  Code Block
  language bash
  curl -k ^ -d "client_id=admin-cli" ^ -d "username=root" ^ -d "password=changeme" ^ -d "grant_type=password" ^ "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/token"

  
  

• Request a token for the account of the target user where the login is needed. The previously retrieved token of the administrative user is referenced as subject_token whereas the ID of the target user is specified as requested_subject.

  Code Block
  language bash
  curl -k ^ -H "Content-Type: application/x-www-form-urlencoded" ^ -d "client_id=admin-cli" ^ -d "requested_subject=cc14e5d4-e8da-4108-92ad-c87066aed4c3" ^ -d "subject_token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJueEZ..." ^ --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" ^ "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/token"

  The retrieved token can be used by the administrative user root for authentication in yuuvis® Momentum with the account of the target user.

• The following command retrieves user-specific information on the user who will be logged in with the token specified in the authorization header. Check whether the token retrieved before identifies the desired target user. Thus, in this example, the command should retrieve a data set for the user with ID cc14e5d4-e8da-4108-92ad-c87066aed4c3.
  

  Code Block
  language bash
  curl -k ^ --request GET ^ --url "http://localhost:8080/auth/realms/tenant1/protocol/openid-connect/userinfo" ^ --header "accept: application/json" ^ --header "authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAi1dXVSZ3daQldhTTJZaXNlZElFXzg..."

  
  

Suppressing Duplicate Information on Roles

Per default, the access token generated by Keycloak contains the roles of the currently logged-in user. The AUTHENTICATION service creates an internal JSON Web Token (JWT) that includes the unchanged Keycloak access token. However, in order to allow a separate role management, the AUTHENTICATION service requests the roles of the corresponding in a separate request and adds them to the internal JWT in addition to the Keycloak access token. The roles stored in the original Keycloak access token are a duplicate of the information and are always ignored. In order to reduce the size of the JWT, their inclusion in the Keycloak access token can be suppressed by applying the configuration adjustment described below. Thus, for any request to the yuuvis® Momentum API, the request header size is reduced.

• Call the Keycloak Admin Console: http://localhost:8080/auth/admin/ with administrator login.
• Select the realm for which the configuration is to be changed.
• Open the Client Scopes.
• Open the roles scope.
• In the Mappers tab, delete the entries realm roles and client.

These configuration steps have to be applied to each realm in each Keycloak instance in which to suppress the inclusion of role information in the Keycloak access token.

Session Management

For each user session, HTTP client and browser set session cookies as described here:
>> Authentication against the Core API

Additionally, the following cookies are set by Keycloak. For more information, please refer to the official Keycloak documentation.

• AUTH_SESSION_ID_LEGACY
• AUTH_SESSION_ID
• KEYCLOAK_IDENTITY_LEGACY
• KEYCLOAK_IDENTITY
• KEYCLOAK_PROXY_SESSION_ID
• KEYCLOAK_SESSION_LEGACY
• KEYCLOAK_SESSION

Summary

This article explained how to install and configure Keycloak as an identity provider and access management system for yuuvis® Momentum in a manual procedure.

...