Assume these are the users in each realm:
realm1 : [ “jaxley”, “nancy” ]
realm2 : [ “LDAP:foouser@example.org”, “SAML:baruser@example.org" ]
If realm1 configuration == "Authenticate against realm2 with fallback to local realm (realm1)”
AND A User tries to log in, then authenticate the user against realm2 first (internally); if the user is not found or fails, try against the local realm realm1. If that succeeds, that is the
user and they are now authenticated.
Thus, if foouser@example.org tried to log into realm1, they would be tried in realm2 first (their home realm).
But if “jaxley” tried to log into realm1, an attempt would be made against realm2 and fail (no “jaxley” there), then an attempt against realm1 would be made. If that succeeds, that is the user and they are now authenticated.
What I want to be able to do is to maintain a set of users inside a Keycloak realm, but I want to still be able to create multiple additional realms to represent different configurations (e.g. Internal-facing vs. external-facing). The challenge is how
when applications use those additional realms to authenticate can we seamlessly allow authentication in our preferred order of searching. I’d hate to have the official answer to be to use the APIs to write a login UI ourselves…
This kind of “preferred order of authentication sources” capability as a declarative configuration option is a feature of many commercial IdM and authentication tools. The conflict between users with the same login ID across realms is either resolved
by fully qualifying the user IDs or using the search order to make some sources weighted higher in the search path so those win.
-Jason
Can you elaborate on how you imagine "fallback to the local realm" would work?