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/main/ 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