Hello, one of the maintainers of https://github.com/ory/kratos (the system used in the blog post) here :) We started Ory Kratos because we saw so many developers struggle with OAuth2 and OpenID Connect. If you have any questions around application auth, OAuth2, or Go, open source I'll try to do my best to answer them accurately!
> I found it hard to quickly determine whether Kratos can run completely
> self-hosted, or that there's always some connection to Ory / Ory Cloud services.
I would appreciate answering that at the proper comment, I'm sure many readers here are very interested in the privacy aspect:
Thank you for working on this interesting open source product.
I have some questions:
- Is it possible to have multiple organizations in one single instance? Can I have some superusers that have access to all organizations?
- Can I delegate authentication for a subset of users (in my case this will always be an entire organization) to another authentication provider (say Microsoft ADFS)?
- Do you support SAML 2.0 clients?
- Do you have a REST API which can be used to create / deactivate users?
Thank you for these questions! First of all I want to say that Ory Kratos is built for customer facing authentication first, so many of the enterprise requirements (e.g. LDAP integration) are still missing. Our vision is to build the de-facto open standard for auth, so enterprise IAM is on the roadmap. It just needs time & community feedback to get there :)
To answer your questions:
- Is it possible to have multiple organizations in one single instance? Can I have some superusers that have access to all organizations?
Depends how you interpret multiple organizations. If those are distinct users (meaning the same person has a profile in org A and org B and does not reuse them), so a true multi-tenant system, then this is not built in and we do not plan to add it.
Running Ory Kratos is very cheap in terms of resources (few MB of ram and no CPU on idle) so it's very affordable to spin up another instance. This doesn't work well for fully-automated deployments such as SaaS systems, but it does work if you are thinking about corporate systems.
You might also look for Ory Cloud, where you can deploy a new Ory Kratos instance with a simple API call.
- Can I delegate authentication for a subset of users (in my case this will always be an entire organization) to another authentication provider (say Microsoft ADFS)?
Yes! Right now we only support OpenID Connect and OAuth1/OAuth2 delegation but more to come.
- Do you support SAML 2.0 clients?
Not yet, but there's an active design document with discussions on different implementation scenarios.
- Do you have a REST API which can be used to create / deactivate users?
Creation - absolutely! Deactivation is not yet available as an API but identity state is already implemented, so adding it is really just a few lines of code.
There are also endpoints for revoking all active sessions which logs out users immediately of one to all systems.
The project for which I'm most interested in a solution like Ory Kratos is a multi-tenant SAAS, with a few hundred organizations. The organizations in general already have other systems that they use to keep track of employees, and so they want to be able to interface with our system to create and deactivate (or delete) users.
So it would suffice if we could host all organizations in one instance, and that we would still be able to directly expose Ory Kratos API's to our clients without them being able to see users in other organizations.
Funny story. We had a client doing a SAML integration using HTTP-redirect bindings. It worked when you turned off request signature verification (which is fine for testing, but is like using alg="none" for JWTs, a non-starter in production), but failed when that was turned on. We dug in with the client and another vendor, set up some test servers, and identified the bug[0]. Turns out that you can't canonicalize the signature's URL encoded form, because both uppercase and lowercase hex values are allowed, by the SAML spec.
Our open source SAML library[1] has been around for years and used by many clients in FusionAuth and our other projects. It'd never run into this particular edge case. It is a wild west out there in SAML land and it takes years to build a bulletproof implementation. Ory folks, if you can leverage an existing implementation rather than rolling your own, I'd highly advise that approach.
That is also to say nothing of the incoming privacy/cookie limitation changes that are coming in the next few years. This will unfortunately probably negatively affect SAML, which is not a specification that has evolved much. If this is of interest to you, I'd recommend the Federated Identity W3C community group[2].
That said, FusionAuth supports SAML in many forms[3]. SAML support varies across vendors and implementations, but other providers like Keycloak and IdentityServer do so as well.
