SPs MUST NOT require the presence of a <saml:NameID> element and MUST NOT rely on the content of this element for long term identification of subjects; <saml:Attribute> elements MUST be used for this purpose in the manner detailed below.

To clarify. Do you have to user storage providers? One AD and one custom DB? With the SAML IdP using the custom DB?

If Keycloak already has access to the users directly, why redirect to the SAML IdP at all? Couldn't Keycloak just authenticate directly? 

Or alternatively not load the same users at all directly in Keycloak, but only through the external SAML IdP? I'm not following the rational around this approach.

That being said isn't a custom first broker login flow what you want? There you can link users automatically in the way you want.

On Fri, 19 Apr 2019 at 01:20, Dmitry Telegin <demetrio(a)carretti.pro&gt; wrote: > Background > > ========== > > > > Consider the problem: we are preparing a Keycloak deployment with > the > > following properties: > > - users come from LDAP/AD, self-registration disabled; > > - vast majority of the users will be authenticating via a 3rd party > > SAML IdP that shares user DB with our Keycloak. > > > > To make onboarding easier, we want to free the users from the need > to > > manually link their accounts with the IdP, by mass pre-creating the > > links programmatically using Admin REST API. > > > > In theory, this should be doable by issuing a POST to > > users/{id}/federated-identity/saml, passing IdP's userId and > userName, > > which should create and persist a FederatedIdentity instance. > > > > In practice, we're hitting a roadblock because of how SAML brokered > > identities are implemented in Keycloak. > > > > Problem > > ======= > > > > Currently, it is hardcoded [1] that FederatedIdentity's userId and > > userName should be taken verbatim from SAML assertion's NameID > value > > (via intermediary BrokeredIdentityContext). The problem is that > most > > SAML IdPs provide meaningless NameIDs, like hashes or purely random > > strings. In general, SAML NameID is not predictable. To make things > > worse, NameID can be different for SPs, so we can't simply peek it > in > > another application already integrated with the IdP. > > > > OTOH, incoming assertion is guaranteed to contain other attributes > that > > are well-known to us and uniquely identify the user, like e.g. > mobile > > phone number. > > > > [1] https://github.com/keycloak/keycloak/blob/master/services/src/m > ain/ > > java/org/keycloak/broker/saml/SAMLEndpoint.java#L398  > > > > Solution > > ======== > > > > The problem could be solved by introducing a configurable (and thus > > more flexible) mechanism to map SAML assertions to > FederatedIdentities. > > With that, we could instruct Keycloak to take userId and userName > from > > arbitrary assertion attributes, or even complex expression, similar > to > > what we have in UsernameTemplateMapper. > > > > Questions are: > > 1. From what I've learned, this should be doable with the help of a > > custom IdP mapper, using preprocessFederatedIdentity() method. Is > that > > correct? > > 2. Regardless of the answer to 1, would Keycloak team welcome this > > contribution? > > > > Some thoughts not directly related to this particular problem; from > my > > 3+ years experience with Keycloak and its corporate users, I can > surely > > tell that SAML under no circumstances should be considered either > > legacy or obsolete. It is *very* actively used in the areas like > > fintech, education and healthcare. I'd myself be happy to see > Keycloak > > become 1st class SAML IdP/broker, and going to do my best to make > it > > happen. I'm particularly interested in improving SAML/OIDC > > interoperability in terms of IdP-initiated SSO and token exchange. > > > > Best regards, > > Dmitry > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 4/18/19 7:18 PM, Dmitry Telegin wrote: > Currently, it is hardcoded [1] that FederatedIdentity's userId and > userName should be taken verbatim from SAML assertion's NameID value > (via intermediary BrokeredIdentityContext). The problem is that most > SAML IdPs provide meaningless NameIDs, like hashes or purely random > strings. In general, SAML NameID is not predictable. Predictable NameID's are possible with SAML but to get them you must  specify the desired NameIDPolicy in the request and the IdP must be  capable of honoring that request. Have you determined the IdP's being  utilized are incapable of honoring a NameIDPolicy of your choice?