Repository navigation
Organization feature will only show linked IDPs if the user has already one linked #43295
|
I'm testing the organization feature with Keycloak 26.2 latest, and somehow I'm stuck. In my testing, I came to a blocker for me to use the organization feature. When a user is already linked to an IDP, a public IDPs or another IDPs connected to the organization, Keycloak doesn't show other public or organization IDPs on the login form anymore. User not linked to any IDP: Same user linked to an open (public) IDP: Or when the user is linked to a hitten IDP: Is this expected? In my opinion this behaviour is wrong. |
Replies: 7 comments 6 replies
|
Hello Wilm, thank you for reaching out. I assume this is due to the assumption that a user has one IDP they log in with. A user can still be part of multiple organizations if they have been invited to those organizations. Still they would log in with their (one) IDP. Could elaborate when a user would have multiple IDPs connected, and how that would work in practice? Did you try to link a user to an IDP via the account console, and would that help in your setup? Maybe @keycloak/core-iam can add more to this. |
|
Hi Alexander, Manually linking via the account console doesn't help. Honestly, I haven't seen the use case for a user to link his user via the account console. How is the user supposed to know what values to add in the linking dialog? But that's another story. Maybe there is a good reason not to show the other IDPs, but I can't see it. |
|
I assume the two IdPs configurations you set up in Keycloak are then pointing to the same actual IdP on the customer side, as otherwise there would be different user details provided by the IdPs, and that could IMHO mix up the data stored in Keycloak. There is a mechanism in Keycloak to have the user choose between the organizations they are part of. I think the following could help in your setup:
If a client wants to know about the organization, it can pass different values via the |
|
The different IDPs for the customer could point to the same EntraID, but with different apps there, or different instances of Octa with the same HR system behind for the users in the Octa system. We haven't seen problems with this approach, the users are linked to both IDPs in Keycloak, as the user attributes for the linking are the same for both IDPs. |
|
I assume one didn't see the use case for that, and I see that using different IDPs would work in your case, but not in a general case. Maybe @keycloak/core-iam has more insights for that. While I see why chose the setup in your current setup, I don't see yet if a similar user experience can be achieved with the options available in Organizations. |
|
It would be great to know why the other IDPs are hidden, if there is already an IDP linked for the user. I'm sure it's intentional, but I just don't understand it and it would help me if it weren't so. |
|
@sguilhen I'm sorry to drag you into this question, but I've seen your comments on other tickets related to organizations and IDPs and thought it might be helpful. From what I've seen in #35059, the use case to have multiple IDPs (even the same IDP multiple times) linked to one Keycloak user isn't a unique case. Maybe you can share your thoughts about this. |
|
Let me bring @pedroigor and @martin-kanis to the discussion - I don't recall exactly the criteria for showing the Idps in the context of organizations. @wschomburg In your example's second screen, the user is already linked to the @pedroigor having the user linked to a realm-level idp shouldn't prevent the user from selecting an org idp, should it? I thought the authenticator logic would still apply here and allow selection of the org idp. Or is another authenticator detecting the existing link and filtering out all other idps except the one the user is already linked to? |
|
That's right, in the second screen, the user is already linked to the open (public) IDP. |
|
I started poking around trying to remember the logic behind this. As you can see in the code above, if the user already has federated identities, only those idps are returned for selection. This was the behavior we already had in place in the old We need to think if this makes sense in the context of orgs - as it stands today, if the user already has a federated identity, then the only way to federate them with a new idp is via client-initiated account linking. @pedroigor any thoughts? |
|
@sguilhen Have you already decided on the behavior? |
|
We can change this behavior in the context of organizations. It could be a switch in the org broker settings to set whether or not a broker should be available to members when they are not yet linked with the broker. |
Created #47431 to track this.