Situation:
- Container-based AtScale is configured to use an identity provider aka IdP (independent of protocol).
- The AtScale identity broker service is configured to do role-based access control (RBAC) using a mapper from the IdP user role or group.
Problem:
Changes / revocation of user permissions does not affect a user that is already logged into AtScale.
Answer:
Container-based AtScale requires a user to log out and then log in, for changes to permissions to become in effect. There is no mechanism to sync users' permissions into it's embedded directory; user permissions are fetched on login.
The following controls exist to help with this situation:
1. Client idle and session timeouts are configurable, which can trigger revocation of access / permissions. The defaults are pre-set; they inherit the single sign-on (SSO) default. For local tooling, they are typically set to 3 days. Additional how-to article: https://help.atscale.com/hc/en-us/articles/26639822153495-How-do-I-adjust-the-session-and-idle-session-timeouts-for-AtScale-UI .
2. If required, the customer could integrate with the AtScale identity broker's logout API endpoint. Changes on the IdP can force a new fetch of claims, which can call the logout endpoint and kill the client's session. This would then force a fresh login. Further reading below:
- Logout documentation - https://keycloak.discourse.group/t/revoking-or-invalidating-an-authorization-token/1032
- Logout API Endpoint - https://www.keycloak.org/docs-api/22.0.5/javadocs/org/keycloak/protocol/oidc/endpoints/LogoutEndpoint.html
- Stackflow conversation on how to implement - https://stackoverflow.com/questions/46689034/logout-user-via-keycloak-rest-api-doesnt-work
3. Specifically for OIDC protocol: There is a Revoke Refresh Token configuration option. When Enabled, refresh tokens are revoked and other tokens are issued that the client must use. This action applies to OIDC clients performing the refresh token flow.