CS3 usersprovider, inconsistent behavior for enabled/disabled users
- Dominant language
- Go
- Stars
- 2.1k
- Forks
- 274
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 103
Description
I am not really sure if this qualifies as a bug, but I think we need to revisit how we handle the enabled state of users in oCIS.
Originally we introduced the enabled/disabled flag on the libregraph usermanagement API to be able to temporary prevent a user from using oCIS. I.e. a disabled user should not be able to login to ocis. The libregraph API exposes an `accountEnabled` flag on the user objects representing the state of the user. That flag is only visible to user that have the `Accounts.ReadWrite` permission assigned. Unprivileged user can't see that flag and can lookup disabled user just normally.
The user objects on the CS3 API otoh don't have any enabled/disabled flag. The current behavior is the following:
* `FindUsers` does not care about the enabled/disabled state of users, it will return any user that matches the search criteria
* `GetUser` does also not care about the enabled disabled state
* `GetUserByClaim` is the only call that does it different. It will only return "enabled" users. I guess this is implemented this way to actually deny access to oCIS for disabled users when using anything else than the builtin IDP. The `accountResolver` middleware in the proxy service uses `GetUserByClaim` (via `auth-machine`) to resolve the user by some claim from the OIDC userinfo response. So if GetUserByClaim did return disabled users this would not work.
As you can see the current behavior is pretty inconsistent and should be streamlined (or removed).
I guess we first need to agree on what the semantics of the enable/disable state should really be. If it it really just about disallowing a user to access ocis, this flag should just be handled by the IDP (and the usermanagement API when using the builtin IDP). The different behavior of `GetUserByClaim` that was added for the `accountResolver` middleware should be removed.
And we would also need to find a better way to handle the "lockout" by group membership feature implemented for the educational Users.
cc @micbar @tbsbdr
Contributor guide
Assessment
This issue has not been assessed yet.