What this is about
Ben works for the customer nordbau and leaves on 30 September. His access should end, his work should stay. There are three handles for this, and they do different things:
| Handle | Who | Takes away |
|---|---|---|
| revoke a role | a tenant administrator or a platform administrator | a single permission |
| suspend the account | a platform administrator | all access, reversible |
| close the account | a platform administrator | all access, final |
The process on 30 September
-
1Admin→CIASlists Ben's role assignments:
GET /cias/admin/role-assignments?userId=… -
2Admin→CIASrevokes each one of them:
POST /cias/admin/role-assignments/{id}/revokewith a reason -
3CIAS→Keycloakremoves the role, and only then is the assignment
REVOKEDWhat takes access away comes first. If the second step fails, Ben still does not hold the role. -
4Admin→CIASsuspends the account:
POST /cias/admin/users/{id}/suspendwith a reason -
5CIAS→Keycloakdisables the account, and only then does the record become
SUSPENDED -
6Admin→CIASlater, when nothing is open any more:
POST /cias/admin/users/{id}/closewith a reasonResult: RecordCLOSED, account disabled in Keycloak. Nothing is deleted, and there is no way back out ofCLOSED.
Why in this order? Suspending alone leaves every role in place: if the account is ever reactivated, Ben has exactly the rights he had before. And closing is final, so it comes last, once it is certain that nobody needs to do anything with the account any more.
What takes effect when
gantt
title Revoked and suspended at 00:00 (access token 5 minutes)
dateFormat mm:ss
axisFormat %M:%S
section Keycloak
role removed, account disabled :milestone, k1, 00:00, 0s
section Login
no login, no refresh any more :done, a1, 00:00, 5m
section Old token
role still in the token, requests run :crit, t1, 00:00, 3m
section Afterwards
token expired, no new one :active, n1, 03:00, 2m
| What you change | Effect on new tokens | Effect on the token the person already holds |
|---|---|---|
| role revoked | immediately, the role is missing from the next token | only with the next token, that is at the latest when the access token expires |
| time-limited assignment expires | after the next run of the timer, by default every 5 minutes | then as above |
| attribute value per tenant revoked | – | at most 30 seconds, because that value is not in the token |
| account suspended or closed | immediately: Keycloak issues no token for a disabled account, not even on a refresh | not at all, it expires normally |
| the whole tenant suspended | – | at most 30 seconds, after which every request is refused at the tenant gate |
Why this is so is explained under Why revoking permissions takes effect with a delay: on every request CIAS only checks the signature and the expiry of the token and does not ask Keycloak whether the roles still hold.
Which handle for which case
| Occasion | Handle and effect |
|---|---|
| Ben changes department and no longer needs a permission | revoke the role. Takes effect with the next token |
| Ben is on parental leave and will come back | suspend the account. Reactivate it later, the rights are back |
| Ben leaves the company | revoke the roles, suspend the account, later close it |
| Suspected misuse, it has to stop now | suspend the account. No new token at once; you wait out the running one |
| The whole customer stops | suspend the tenant, see A customer cancels |
What happens to the person’s data
- the user record in CIAS, with status
CLOSED - the account in Keycloak, disabled, including membership in the organization and in groups
- role assignments nobody revoked
- every row in CDMS Ben created or changed
- the history: every revision with name, IP address and browser
- the CIAS audit:
Revoked,Suspended,Closed, each with its reason
- new login: impossible
- refreshing the token: fails
- every request, as soon as the last token has expired
Nothing is deleted, and there is no endpoint for it either: neither for users nor for tenants. The reason lies in the data itself. In CDMS rows hang on the person, and the history names her; a deleted account would leave those references pointing nowhere, and later an auditor could no longer say who did what.
User models are models in which every person only sees her own rows. Ben’s rows there stay assigned to him and are invisible to everybody else, because the owner filter works with your own id. Whoever has to look at them once more needs a user switch. It only succeeds as long as CIAS still finds Ben as a person, he still belongs to the tenant nordbau, through the organization or his attributes tenant or allowedTenants, and a valid consent from Ben exists. Otherwise CIAS answers with 403. Ben cannot give a new consent after he has left. Whoever wants to hand them to another person creates them there anew.
What the audit records
| Handle | Entry | Contains |
|---|---|---|
| role revoked | AuthorizationEvent.Revoked | assignment, person, role, tenant, reason |
| time-limited role expired | AuthorizationEvent.Expired | assignment, person, role, tenant |
| account suspended | UserEvent.Suspended | user id, reason |
| account closed | UserEvent.Closed | user id, reason |
The reason is mandatory for all three. It is not stored on the record but in the event and therefore in the audit. Who acted is added by the audit from the token of the request. No entry is created for a group membership somebody ends, or for roles that exist only in the Keycloak console. See Which events are logged.
Traps
Next
- Suspend, reactivate, close and The lifecycle of a user
- Revoke a role and Time-limited roles
- Why revoking permissions takes effect with a delay
- What remains after a delete
- The case of a whole customer: A customer cancels