[keycloak-dev] Proposal: more flexible brokered identity with SAML IdP

[Dmitry Telegin]

Hi Stian,
Turns out we already have a JIRA issue: https://issues.jboss.org/browse
/KEYCLOAK-7969
Per Kantara Initiative recommendations,
> 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.

This issue is in the core of the overall problem we're trying to solve,
so probably we don't need to dive deep into the details of our
particular setup. Nevertheless, I've answered your questions below.
On Wed, 2019-04-24 at 14:37 +0200, Stian Thorgersen wrote:
> To clarify. Do you have to user storage providers? One AD and one
> custom DB? With the SAML IdP using the custom DB?

Sorry for confusion - there's no custom DB, LDAP is shared between
Keycloak and SAML IdP. We can even simplify this by assuming that
there's no LDAP at all, and Keycloak user DB is somehow synchronized
with the IdP. So Keycloak and IdP have the same view of users, and we
only need to pre-create brokered identity links. This is currently not
possible because Keycloak requires the knowledge of SAML NameID in
order to do that, and NameIDs are random / non-predictable.

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

This is the requirement. SAML IdP might use different authentication
infrastructure (OTP, smartcards, Kerberos) that our Keycloak has no
access to.
> 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.

This is also the business requirement. The list of users in Keycloak
should be complete from the start, and not being populated gradually as
the users log in.
> 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.

It could have been, but we need to perform linking based on SAML
attributes, and currently SAML context is not exposed to the
authenticators, which is another known issue:https://issues.jboss.org/b
rowse/KEYCLOAK-9936http://lists.jboss.org/pipermail/keycloak-dev/2019-
January/011514.html
Regards,Dmitry
> On Fri, 19 Apr 2019 at 01:20, Dmitry Telegin <demetrio at carretti.pro>
> 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 at lists.jboss.org
> > 
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev