jelhub
commented
1 year ago Hi, You are probably right regarding SCIM spec, but scimgateway gives the flexibility to let plugin decide most of the behavior, and plugin-code is fully managed and customized.
There are only a few attributes that scimgateway actually cares about and these are: id, userName, externalId, displayName (for groups). These must be used correct. All other attributes that may be included will be passed as-is to plugin (does not either check any SCIM Schema)
There are endpoints and use cases where "groups are member of user" fits better than "user member of group"
For PUT this behavior is not default. You actually have to configure scim.usePutGroupMemberOfUser=true to allow this behavior.
How PATCH and POST handle user object attributes is decided by customized plugin-code. All attributes that come are passed to plugin without any restrictions, including any user groups attribute.
For some of the example plugins that are included we have:
plugin-loki: don't care about attributes and naming, what comes will be used.
plugin-azure-ad (config file decides attributes and mapping): https://github.com/jelhub/scimgateway/blob/master/config/plugin-azure-ad.json#L112-L253
- Allowed attributes must be defined in config mapping. There are
no groups attribute mapping defined on userand it will be ignored.
plugin-ldap (default configured for AD and config file decides attributes and mapping): https://github.com/jelhub/scimgateway/blob/master/config/plugin-ldap.json#L153
- Allowed attributes must be defined in config mapping. This plugin also
allows groups as a user attribute. Removing this config will prevent this behavior.
plugin-sql (don't use config file for attributes and mapping, but instead hardcoded in plugin) https://github.com/jelhub/scimgateway/blob/master/lib/plugin-mssql.js#L301-L331
- Only a few attributes are handled, and
groups as a user attribute is not included.
https://github.com/jelhub/scimgateway/blob/e85ef9041d53546d4c1699de0372b4c7788bacc0/README.md?plain=1#L347C1-L349C292
The groups attribute on the user resource is readOnly mutability (per RFC 7643 section 4.1.2):
PUT, PATCH and POST should not be able to modify the attribute - so any functionality tied to the "groups as members of users" concept isn't compliant with the SCIM 2.0 spec.