SCIM 2.0 support

[pslestang]

Is your feature request related to a problem? Please describe.

Feature is not related to a problem

Describe the solution you'd like

I would like Kratos implements SCIM 2.0 protocol https://tools.ietf.org/html/rfc7642 https://tools.ietf.org/html/rfc7643 https://tools.ietf.org/html/rfc7644

Describe alternatives you've considered

Alternative is to use an other software

Additional context

NA

[aeneasr]

If the feature is not related to a problem, why do you need it? Maybe you could explain a bit more why you need SCIM. We're generally open to have it implemented but lack resources to do so as there are other, more important things such as 2FA/MFA, Ory Hydra integration, and more.

We do however appreciate contributions if you're up to the challenge!

[pslestang]

I mean by it's not related to a problem that I do not face an issue with the current code (understand a bug in the code), I'd just like to get SCIM protocol implemented mainly because it is a standard with a standard REST API and that I prefer use standards instead of relying on custom implementation. I do note for the contributions and will contribute if possible!

[aeneasr]

Awesome! If you plan on working on this we should synch up so that we can reduce the amount of work you have to do!

Generally, Ory Kratos implements the things needed for SCIM such as custom identity schemas (called SCIM schemas in SCIM). I think the first priority when implementing SCIM support would be to identify areas which are currently not SCIM compatible (I don't think there are any to be honest!) and lay out a plan how Ory Kratos data would be made SCIM compatible.

[abujagonda]

What is the current status of SCIM 2.0 support in Ory Kratos?

[smoyer64]

I'm one of the authors of Penn State's Go SCIM Client. It was supposed to be APL 2.0 licensed but is missing the LICENSE file. While the code is client-oriented, the types are applicable to both server and client implementations so it might provide a good start. If you're interested, I can attempt to get Penn State to add the missing license file. If you want to start from scratch, I have a lot of SCIM (and Go) experience could probably help. If Go 1.18 is a possibility, a SCIM Resource could be a generic type used by User, Group, etc. If I was doing this again, I'd probably use a generator for a lot of the repeated code.

EDIT: One other impediment to making SCIM support easy is that the RFCs allow JSON "additional properties" as do many other APIs - this is supported in many programming languages but support in Go has languished - https://github.com/golang/go/issues/6213#issuecomment-1142639776. There are work-arounds but it's not always simple (or pretty).

[rafaelvannucci]

Hi team!

Having SCIM is a game changer for us (considering we become an Ory customer in the future).

Okta understood the business value in provide provisioning/deprovisioning capabilities in their integration network. SCIM offer a great ROI because is scalable, as most of enterprise customers doesn't have time, resources etc to manage a giant number of SaaS applications lifecycle (ie. Slack, Google, and more 5,000 apps...)

[smoyer64]

@aeneasr - I didn't see anything appropriate on the Ory Jobs board but I'd be interested in implementing SCIM as part of Kratos. Ten years ago we (The Pennsylvania State University) hoped that the Apache Directory team would merge the various projects into a unified identity system. After years of watching people choose Sailpoint, Auth0 and Okta, I'm impressed with what you've built and wish you nothing but the best!

[aeneasr]

@smoyer64 thank you so much for the kind words, sounds like quite the journey :) While we don't have roles specifically for SCIM (there are currently mor epressing priorities) we always look for opportunities wherever they arise! If you're interested to work on SCIM at Ory, please do apply (e.g. for full stack) :)

[alexrollin]

Is there any update on SCIM support?

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️