Home idP discovery based upon SP's baseUri

[vchhabra]

Hello @sventorben

Ours is a multi-tenant application where each tenant is given its own vanity host. For e.g

https://abc.example.org
https://xyz.example.org
..

And email domains are unique only within a tenant boundary (users across tenants could have same email).

Given above scenario, we need a way to configure Home idP discovery based upon the SP's base URI such that:

Auth requests from https://abc.example.org should be relayed to idP - abc-idP
while requests from https://xyz.example.org should be relayed to idP - xyz-idP

Do you plan to support URI based home idP discovery?

I understand that Keycloak has support for client suggested identity provider via kc_idp_hint query parameter. But I believe by having a similar option (base URI prefix) through this extension will help automate our process without impacting clients.

Looking forward to hear on this.

Thanks.

[sventorben]

Hello @vchhabra,

Unfortunately, I have no plans to support such a feature, yet. I'm not saying I'll never do it, but it's the first time anyone has asked. So I'd like to understand the use case a bit better at first.

• Is your keycloak also hidden behind a vanity domain?
• Is there a reason why the SP/Client does not forward directly to the correct vanity URL or the associated IdP? Why do you federate this with a central Keycloak instance?

Thanks
Sven-Torben

[vchhabra]

Hello @sventorben,

Thank you for your response.

Is your keycloak also hidden behind a vanity domain?

No.

Is there a reason why the SP/Client does not forward directly to the correct vanity URL or the associated IdP? Why do you federate this with a central Keycloak instance?

We have multiple such (multi-tenant) SaaS products and by leveraging Keycloak as an Identity broker and federating all authentications through it we are trying to achieve SSO across these products.

At high level, here is what we have:

Does it provide you the information you are looking for?

Thanks again,
Vikas

[sventorben]

Hello @vchhabra,

yes, thanks.
However, I still do not get the relationship between the SaaS Application and Resident IdP. How are these related to each other? Is it a valid scenario that a user tries to access the application on the left, gets redirected to the central Keycloak instance, gets redirected to the left resident IdP, and then tries to access the application on the right? Or does the user have to have an account in the IdP within the same yellow box as the application?

Another question is how the central Keycloak instance knows about the vanity url/domain of the SP? Would that be based on the clientId and the configuration of the client?

Regards
Sven-Torben

[xgp]

Per our conversation here p2-inc/keycloak-orgs#83 another use case for a method of looking up the IdP.

We have an extension to enable multi-tenancy in Keycloak which creates a new entity called Organization. We allow, in a restricted fashion, each Organization to "own" their own IdP. There is a child entity to Organiztion called OrganizationDomain which establishes the relationship between an Organization and email domain names that they have verified ownership of. Once we have looked up that relationship, we look up an IdP based on an Organization ID stored as an attribute.

All of that is to say that a simple attribute or URI is not sufficient to satisfy our use case. We have previously forked the code, and looked at what would be required for the current code to work with our use case, and the ability to override or replace by SPI the HomeIdpDiscoverer would be sufficient.

Let me know what direction you'd like to take with this, and we're happy to draft an implementation. Thanks @sventorben