Current problem
SCIM is a IETF standardized protocol made to compliment existing SSO protocols, by keeping the application (Fluxer in this instance) in sync with the IDP (Authentik, Authelia, Keycloak, Google, Okta, etc) which is treated as a source of truth for all users, and the status and overall state of the users.
TLDR: When a user is added, removed, or otherwise modified in the IDP (lets say in this case, Authentik), it is reflected in the application (in this case Fluxer) via the SCIM protocol
Proposed change
- Implement RESTful APIs, JSON parsing, and Authentication for SCIM as defined in RFC 7644 and its addendums
- Implement Admin UI pages for configuring SCIM, as well as logging what changes occur from SCIM syncing sessions
- Implement user logic within SCIM so that when a user is added, updated, or deleted, it is reflected in Fluxer (This might have some nuance to it, for example some instances when a user is deleted from the IDP might not want the user to be outright deleted on Fluxer, and instead they might want the user banned for data archival/ediscovery/legal reasons, similarly there might be cases where the user SHOULD be deleted due to GDPR regulations, this should probably be left to the instance maintainer to figure out and decide based on the use case, similarly the user
activeboolean behavior might also want to be configurable for similar reasons (IE: do you deactivate, ban, log out, or otherwise delete a user if they are inactive? What happens when they become active again? Etc)) - Implement group logic within SCIM so that group membership from the IDP can transfer into admin panel rights, and maybe server roles (This one i wouldn't say is a strict requirement due to how ambitious it is, albeit it would be very very useful, imagine if you were able to control user access to channels in servers based on IDP groups? AFAIK Slack offers a somewhat similar feature)
1 comment
Comment by @illspirit