[keycloak-dev] Claims Mapping and Identity Federation

Pedro Igor Silva psilva at redhat.com
Fri Feb 20 10:46:17 EST 2015


Regarding what you said about claims, going to think on what you said during the weekend. Get back to you on Monday :)

I'm glad that you are already considering making internal code more flexible so we can deal with access tokens, id tokens, saml assertions or whatever is issued by KC prior to return them to service providers. This is also one of the things in my requirements list.

Some comments in line.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:36:31 PM
> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> 
> I'm still working things out.  Right now I have a realm set of
> ProtocolMappers.  The data model is
> 
> protocol (saml or oidc)
> protocolMapper (this references a provider)
> 
> These 3 are for simple one to one attribute mappings.
> 
> protocolClaim
> sourceAttributeType
> sourceAttribute
> 
> For OIDC there will be just one protocolMapper for simple one to one
> claim/attribute mappings.  For SAML there will be a "Friendly
> AttributeStatement" and "URI AttributeStatement" for attribute mappings.
> 
> For more complex OIDC stuff, there will be you'll be able to write a
> provider that implements an AccessTokenTransformer interface so that you
> can modify the access token however you want.

What about the ID token. I think this guy is the most important in this context.

> 
> For more complex SAML stuff you'll haven multiple transformation points.
>   You'll be able to get access to the SamlBuilder for each saml document
> type.  You also be able to get access to the document model after the
> Builder has created it.
> 
> The idea is that we want to have full extension points for use cases we
> haven't seen.
> 
> As for Identity Brokering, we'll have something very similar.  For
> OIDC/SAML brokering, we'll have ProtocolMappers that implement a
> SamlImporter or TokenImporter interface and we'll have simple
> claim/assertion to UserModel.attribute mappings, and a more extension
> transformation interface.
> 
> 
> 
> On 2/20/2015 10:18 AM, Pedro Igor Silva wrote:
> > When brokering an identity provider, we also need to map claims in order to
> > properly federate the users identities in Keycloak.
> >
> > When doing identity federation, we may have different claims from different
> > providers. We may also need to update those claims when re-authenticating
> > with a specific provider.
> >
> > Another possible situation is that we may have the same claim (eg.: same
> > name) across different providers. So we need some way to identify this
> > conflict and fix. Or just update the claim specific for a provider.
> >
> > How that is being considered by the claim mapping that is being developed ?
> >
> > Regards.
> > Pedro Igor
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


More information about the keycloak-dev mailing list