SCIM

[sebadob]

... continuing the off-topic discussion from #337 here :)

[sebadob]

@jgraichen Another thing that came to my mind regarding data sync from downstream applications is of course that you could use read-only API keys. This would work right away, but is of course no standard interface and would require custom implementations downstream.

[sebadob]

There is a (pretty new) rust crate which implements the scim v2 models - https://github.com/ShiftControl-io/scim-v2-rust
So I guess implementing SCIM would not be too bad. The code looks fine and its basically all the model definitions.

[AdamJSoftware]

This seems like an interesting idea. It seems that most other Auth Providers are very much just concerned with logging in. I feel like this is a bit of problem when it comes to integrating it with you application. I know now which is user is logged in. But I am unaware of any other users that exists. Zitadel seems to do a fantastic job solving this problem but it seems that there server consumes more memory than I can afford. A lightweight implementation (like rauthy) would be right up my ally.

[AdamJSoftware]

I do notice that rauthy has an admin API but the problem is that it is not "standardized". Having to implement just one protocol would be ideal.

[sebadob]

SCIM has nothing to do with Rauthy's API. Of course it is not standardized because there can't be any standard. Every application is different. SCIM support would mean that Rauthy would do outgoing requests to client applications that need to implement the endpoints. What is standardized though is the OIDC API and flows, and this is very easily integrated with any application out there. You will find multiple client libraries for oauth / oidc for probably every language.

Regarding the admin API, you most probably don't need to integrate this anywhere. Just use Rauthy's UI to get all information you need and perform actions.

I actually decided against implementing SCIM in the meantime, because it would not provide any benefit for me. As long as not someone else submits a PR or there is a feature request from a company in some other way, it is very unlikely that SCIM will come in the near future.

[polarathene]

I actually decided against implementing SCIM in the meantime, because it would not provide any benefit for me.

Fair enough 👍

It's quite popular in enterprise / SaaS products. I'm not sure how much adoption there is in open-source projects.

docker-mailserver has had a request for it since the OAuth2 / OIDC authentication would allow a user to login, it does not help with provisioning an account for that user in advance. Without that the software does not know about the user until they login, so no mailbox is created thus they cannot have mail sent until that has happened.

SCIM support helps software in scenarios like that, where a user managed by the IdP can login via SSO, but also ensure that the SCIM servers (apps providing SCIM endpoints for IdP to use) have users provisioned/synced. Otherwise, they need to be manually provisioned and de-provisioned when no longer part of the organization.

The standardized API with SCIM helps with that integration, but as Authentik notes in a blogpost about their SCIM implementation (client and server roles) just following specs still encountered issues. Most open-source IdP with SCIM support tends to only be inbound (the IdP offers a SCIM endpoint for another IdP like Microsoft or AWS to provision/sync with), and for Go based implementations they use a common SCIM library that lacks groups support. The proprietary SCIM implementations like Okta has aren't without caveats either 🤷‍♂️

[andoks]

Unless I have missed something from one of the many openid-connect related specifications, providing a SCIM 2 API would be one possible avenue of providing client applications (RPs) with a standard way of retrieving user information about other users than the currently logged in one using the /Users endpoint without having to store information for all users logged in to their systems mapped to the "sub" claim, and update it themselves every time a user accesses the system with updated values for user information in their ID token. It could be very practical to simply store the "sub" claim in the database when a user does some action, and using the SCIM2 API to fetch said users info to present to other users when they view said action in lists etc.

[sebadob]

It could be very practical to simply store the "sub" claim in the database when a user does some action, and using the SCIM2 API to fetch said users info to present to other users when they view said action in lists etc.

SCIM works in the other direction. Your IdP would be the client and it would push updates to client applications, which must implement the SCIM API following the RFC.

If you just want to fetch data from Rauthy, you can do this already very easily when you just create an API Key with read access. You could then do exactly what you would like to do.

[andoks]

It could be very practical to simply store the "sub" claim in the database when a user does some action, and using the SCIM2 API to fetch said users info to present to other users when they view said action in lists etc.

SCIM works in the other direction. Your IdP would be the client and it would push updates to client applications, which must implement the SCIM API following the RFC.

Sure, the standard describes mutating the data too, but it seems to me that it also provides API for simply reading the information from the IDP

If you just want to fetch data from Rauthy, you can do this already very easily when you just create an API Key with read access. You could then do exactly what you would like to do.

Not in a standardized way I assume (I have not yet had the time to browse all the docs)? What I mean is that given that a few IDPs provide both OIDC and SCIM, one could in theory (as a client application developer) rely on these APIs to get both SSO like functionality, but also use the read-access to all users' info that SCIM provides to display information about other users in a vendor-neutral way (if the SCIM endpoint identified users by the ID received in the sub claim, which e.g MS Entra does not sadly - because they provide the sub claim as a PPID source)

[sebadob]

Sure, the standard describes mutating the data too, but it seems to me that it also provides API for simply reading the information from the IDP

That might be, I don't know. We don't have any use for SCIM currently so I never digged deeper into the topic.

[polarathene]

SCIM works in the other direction.

It can work both ways AFAIK, but generally intended that the IdP is the client.

If you just want to fetch data from Rauthy, you can do this already very easily when you just create an API Key with read access. You could then do exactly what you would like to do.

The intent with SCIM is to have a standard API to integrate with instead of vendor specific ones. For common use-cases that simplifies such integration support, thus SCIM compatibility has appeal like you would with OIDC and LDAP. Compared to LDAP however it's managed via HTTP API which is a bit nicer to secure and proxy IIRC.

That said, vendor-specific APIs tend to be more versatile / powerful when more control is needed.

My interest in SCIM doesn't have the app query info from the IdP, since the IdP would not store metadata about users specific to that apps provisioned users (mail quotas, aliases, etc). SCIM would just be used for as an alternative account provisioner vs local file/db or external LDAP sources. Presently OIDC auth needs to be paired with those existing provision methods and kept in sync.

---

It may be viable for another service to act as a bridge. Either via some event system like webhook triggers or polling vendor specific APIs to stay in sync and perform the role of a SCIM client.

That could then have a config to support various IdPs in an ad-hoc way? 🤷‍♂️ Perhaps that'd be a bit similar to oauth-proxy.

I've noticed that Ory, Authelia and a few others have similarly been reluctant towards adopting SCIM. Zitadel has been planning to approach it for some time but still very much WIP last I checked. Casdoor only offers inbound SCIM to provision users into Casdoor, using the same Go lib as Zitadel plans to, thus no group support. I think kanidm was making some progress with SCIM too.

It's understandable if rauthy stays focused on what it does best, letting the SCIM ecosystem in open-source projects mature more until demand is higher for it to be more worthwhile :)

[sebadob]

The main problem is, that we don't use it at all. Rauthy was born out of the need for a good system for a somewhat smaller company with about a hundred users. User on- / offboarding is not an issue.

Regarding an implementation, that's probably the reason why all the open source projects have issues with SCIM. They typically don't use it themselves, so they would not spot issues on a daily basis and need to rely on issues that others may create.
I did the mistake in the past to implement features that I don't use or am not even familiar with. While the implementation may not be the biggest problem when following RFCs and do proper testing, they will fall behind over time, because you would not only forget about them, but you would also not keep track of stuff you don't need and the implenentations will fall behind. That is almost guaranteed.

I did some implementations for other companies, which then were paid features. In that case at least my time is not wasted because of implementing something that I don't use at all or actually don't really care about.

[sebadob]

Just as an update here:

I will most probably implement (at least some) SCIM functionality after the UI migration, avatars and backchannel logout has been implemented. It will take some time until I get there, but at least most important things like user CRUD will come at some point.

I opened an issue for this.

[sebadob]

SCIM has been relaeased in the meantime.