Automatic Disabling/Deleting users by OIDC removal

[fritterhoff]

Description:

At the moment we have an Synapse instance connected to gitlab including a filter using the attribute_requirements:. I just had to recognize that deleting a user from the defined group does not disable the matrix user. Would it be possible to check if the gitlab user is still in the group and otherwise to disable/delete the matrix user?

[squahtx]

related: #11326 Support back-channel logouts from OIDC providers

[sandhose]

Back-channel logout is definitely a step in that direction, but isn't supported by GitLab.

There is a working group in the OpenID foundation called RISC (Risc Incident Sharing and Coordination) which tries to define a standard way to signal account security events (account locked, unlocked, removed, compromised) based on RFC8417: Security Event Token. This would allow us to react when the following events happen on the IdP side, according to the spec draft:

• Account Credential Change Required signals that the account identified by the subject was required to change a credential. For example the user was required to go through a password change.
• Account Purged signals that the account identified by the subject has been permanently deleted.
• Account Disabled signals that the account identified by the subject has been disabled. The actual reason why the account was disabled might be specified with the nested reason attribute described below. The account may be enabled in the future.
• Identifier Changed signals that the identifier specified in the subject has changed.
• Identifier Recycled signals that the identifier specified in the subject was recycled and now it belongs to a new user.
• A Credential Compromise event signals that the identifier specified in the subject was found to be compromised.
• Opt-In/Out related events. Users must be able to opt-in or out of RISC events between the IdP and the app, hence those events.
• Recovery Activated signals that the account identified by the subject activated a recovery flow.
• Recovery Information Changed signals that the account identified by the subject has changed some of its recovery information. For example a recovery email address was added or removed.
• Sessions Revoked signals that all the sessions for the account identified by the subject have been revoked.

Not all events are relevant to Synapse, but I definitely find those interesting.

The good news for us is that security event token look a lot like logout tokens from the OIDC back-channel logouts (which was by the way intended by the OIDC folks), so a lot of the implementation is already done in the OIDC back-channel logout PR.
The bad news is that RISC is not widely adopted by OIDC providers. I know Google adopted it and brands this as Cross-Account Protection, but there is basically zero chance that GitLab adopts this soon.

[fritterhoff]

Hi @squahtx and @sandhose,

thanks for your hints. I actually was thinking about utilizing the is_user_expired?

[squahtx]

is_user_expired

That looks promising if you're happy to develop a third party module for your needs.

[fritterhoff]

is_user_expired

That looks promising if you're happy to develop a third party module for your needs.

I would check how complex that is but from by point of view that seems to be rather simple?