kratos
kratos copied to clipboard
ory
SCIM 2.0 support
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
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!
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!
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.
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).
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...)
@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!
@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) :)
