Hi folks, we’d like to implement Realm Detection in our multi-tenant application and use the entire Ory stack as well as external IdPs. In other words, we have B2E and B2B scenarios.. the former uses Kratos and the latter, external IdPs (e.g.: azure ADs). Are there examples and documents already available for this? In case it’s not clear, by Realm Detection, I mean the scenario in which users enter their username first and we determine where to send them next: next page to enter password (B2E) or another Idp’s auth page (B2B).

Hi @mammoth-country-5949 Ory doesn't provide Realm Detection out of the box. You will need to wire up some services around Ory to do that, which is fine to do - since Ory products are designed to fit into your architecture instead of the other way around. Which part of system would you want Ory to manage?

I understand that Ory doesn’t do Realm Detection.. We’ll have to build our tenancy model and tenant detection (using emails) ourselves.. what we wanna do is something like this: 1- Use Kratos for internal users.. For federated authentication, I think we can use Hydra, but I need guidance here 3- Use Keto for all fine grained authorizations 1- Use Oathkeeper proxy in front of our services which uses Authenticators (this has to work with both internal and federated authentication) and Keto authorizer

I think for the scenarios you listed above, all of that is possible - to an extent. Do you want complete tenant isolation e.g. I log into realm A, but won't have a session with realm B. Or is it okay to log into realm A and have a session in realm B? Also since you have multi-tenants, are they dynamic? Can you predict the number of tenants? Ory does not support multi-tenancy, e.g. I get a business that registers on the platform and now they have their own kratos / keto / hydra / oathkeeper instantly setup. The scenario for this gets quite complicated quickly, depending on your use case. You can, however, setup Ory to service each realm with a new instance of the Ory stack. In the case of third party access to your user data, you would need Hydra + Kratos.

Thanks. To answer your questions: 1- Tenants are never dynamic. 2- We do need tenant isolation. This is in case a malicious actor in 1 legitimate tenant tries to attack another tenant. This is a low possibility, but we can’t rule it out.

It is quite difficult to answer such an extensive question since this is very much an architectural question. Ory can of course fit into your architecture, but with such a broad set of guidelines I cannot really give you exact answers. Depending on the way you want to authenticate the user, you could attach meta information to the session depending on the realm you want them to login to. I do think in your use case you will most likely always be using Hydra to federate the login throughout the many tenants. maybe @able-glass-7253 can also share some insight here

that’s fair and thank you for your help.. to be clear, I’m not expecting architectural guidance here.. I mentioned multi-tenancy simply for clarity.. I really have 2 specific questions/unknowns at this point.. 1- How do I configure federation with an Azure AD (or AD on-prem)? Specific example here would be very much appreciated. 2- How do I attach meta information to a session? Again, specific example would be greate

Hi @mammoth-country-5949, you may be able to use Kratos if all you need is for a subset of users to sign in via an OIDC-compliant IdP (in this case Azure AD). Have you seen this[1] doc page? If all the realms your users are registered with are Azure AD organizations, you would set the

microsoft_tenant

value to "organizations", and AD would then do the realm detection for you. Regarding your second question, the answer depends on the specific scenario. Sessions are immutable and there is no way to attach metadata to them per se. But you may use a reverse proxy (such as Oathkeeper using it's mutators/hydrators) to attach data to each request with a session. Or if, perchance, the data is included in the user's ID token the first time the user signed up, you can a) define a jsonnet mapper to map it to the user's identity traits[2], or b) retrieve the token itself[3]. [1]: https://www.ory.sh/docs/guides/social-signin/microsoft [2]: https://www.ory.sh/docs/guides/social-signin/microsoft#data-mapping [3]: https://www.ory.sh/docs/guides/social-signin/get-tokens

Very interesting.. I had not seen No.1.. in fact, I assumed OIDC is only provided through Hydra..

I assumed OIDC is only provided through Hydra..

To put it simply Kratos is an OIDC client while Hydra is an OAuth2/OpenID server.

@mammoth-country-5949 You mentioned "an application" and "external IdPs", which suggests you may not need to use Hydra. Hydra would enable you to become an "external IdP" for independent applications (e.g. if you wanted your employees to sign into Slack using your Kratos, or if you had independent applications that don't trust each other with the Kratos admin API whose users you'd like to manage centrally)

thanks for the explanation..