Repository navigation
Replies: 3 comments 12 replies
|
Within a month of this FR raised, I need this feature as well. When you have a subdomain for every customer, you can’t create those many clients and configure different IDPs for them. |
|
Red Hat also has this need. Right now it's being handled in a bunch of extensions and custom flows, but we'd love to get this into Keycloak. To extend on this a bit though we have the need to define a group of users associated with a customer, that is linked to a particular IdP. This will also force this group of users to login with the IdP. We also want to link this up with LDAP and/or SCIM to support syncing of users. Which further starts going down to route of a sub-realm within a realm to have a context for a specific customer, where other things can live as well, like groups, roles, service accounts, etc. |
|
@alechenninger FIY |
|
Yeah the more I think about it the more it seems like a first-class "tenant" within a realm is going to simplify a lot. And then of course, given a "realm" already models a tenant, reusing a realm as in "subrealms" seems natural. Attempts to get around using a subrealm seem to be awkward and error prone to me. Should we take an honest look at a couple of options of what it would take to get a subrealm concept off the ground in the most iterative way possible? |
|
I think sub-realm level tenants would be another great feature but not a precondition for this idea. |
|
I agree subrealms are not a precondition to purely IdP selection based on login email domain by itself. I have a very similar but hacky proof of concept that does the domain-based redirect as well, and we do some related things on redhat.com. At the end of the day, when you have this scenario of different subsets of users belonging to different customers (in your particular scenario this customer also owns a particular domain), I think customers want:
You can tackle just one feature in isolation, but how do the rest of the features come together? Do they end up with a sensible solution to the customer and Keycloak administrator–one easy to manage abstraction? Or are they disjointed, requiring additional extensions or heavy refactoring to pull them together? Honest questions, but I have my doubts. Even just trying to get domain-based IdP right can get tricky in isolation, for example:
This is all to say, an authenticator alone isn't a complete solution. Several other pieces have to come together. And it still doesn't yet provide the other features the customer is looking for. First class federation at a "tenant" level (e.g. subrealm, but perhaps a group could work with some caveats, open to ideas there of course), would be able to address the whole solution with a few basic config options that encapsulate all of that complexity rather than requiring many different configurations to come together in exactly the right way to provide the solution. There is a related proposal we're working on a Red Hat that may be a smaller stepping stone, I'll link to that here when it is shared. I'm just wondering if we should maybe start pursuing subrealm or something like it sooner than later. |
|
@jbman I think I have what you are looking for right here as an extension. I could contribute this to the Keycloak project if desired and if it does not need too much work for additional features. |
|
I just created #13206 to track this :) |
|
Do you use the new account console already? With the new console, it should be easy to remove the "Linked IdP section" from the |
|
@sventorben we do use it, but then that will indeed kill off the ability to see current links with IdP's such as Google/GitHub/etc. |
|
@jbman I deployed your extension on kyecloak 19.0.0, but dont see "Home Idp discovery" tab on "identity providers -> provider details" page. |
|
@nitdgpvijay The new admin console is not supported yet. |
Uh oh!
There was an error while loading. Please reload this page.
We have a request for a feature which selects the target Identity provider based on the login email address of the user. Instead of a list of login buttons, the user will get just an email input field and a text like "Please provide your email, we then open the appropriate login page for you". The feature needs a mapping configuration with entries which map an email domain names to target IdP. It also needs to deliver a new login screen where just the email of the user is requested.
The feature is relevant in scenarios where you have multiple IdPs configured at one realm where users of different companies login with their business email as username. You don't want to end up with users selecting the wrong IdP and you also don't want to present the complete list of configured IdPs at the login screen. Several cloud IdPs apply this pattern, like e.g. MS Azure at https://portal.azure.com/.
The feature may be implemented with a custom Authenticator. When having it open source it could be included in the default Authentication flow like the default "Identity Provider Redirector" (class
IdentityProviderAuthenticator). Just deactivated, without any mappings configured. A soon as you configure one or more domain to IdP mapping, the screen which requests the user's email would be displayed. Such a newResolveIdPAuthenticatorcould be included right after the existing "Identity Provider Redirector".Is there any interest in such an Authenticator developed and contributed to the Keycloak Open Source project?
All reactions