From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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.

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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, February 20, 2015 1:50:41 PM Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation On 2/20/2015 10:46 AM, Pedro Igor Silva wrote: > 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. > I'm a bit nervous about this as we end up having to expose the entire SAML document model to users. I don't see any way around it though. There are so many esoteric SAML features that we won't be able to support due to time constraints, yet I want to be able to allow users to apply their own extensions to support them.

> Some comments in line. > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Friday, February 20, 2015 1:36:31 PM >> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation > > What about the ID token. I think this guy is the most important in this > context. > AccessToken extends ID Token. ID Token is created from the access token.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)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. I'm not sure if you really need something different for SAML. The reason is that we can just ask users if what they want to use 'Name' or 'Friendly Name'. At that end, that is what really matter, right ? Just know the name of the attribute to map to an internal one.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, February 20, 2015 8:48:53 PM > Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation > > > > On 2/20/2015 11:07 AM, Pedro Igor Silva wrote: >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Friday, February 20, 2015 1:36:31 PM >>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation >>> >> >> I'm not sure if you really need something different for SAML. The reason is >> that we can just ask users if what they want to use 'Name' or 'Friendly >> Name'. >> >> At that end, that is what really matter, right ? Just know the name of the >> attribute to map to an internal one. >> > > From looking at SAML document it looks like you can have a attribute > name types (uri, basic, and unspecified). I'm not sure of the > difference between basic and unspecified. Do you? AFAIK these are about how you interpret attributes. I think you can just ignore that in this case. You are more interested in map names than deal on how they should be interpreted. Users will probably know what they are mapping. > > Then "Friendly Name" is optional. Yeah it is optional, but you can have something like that: <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName="mail"> In this case, it is much easier to use FriendlyName when mapping than what is in Name. See, here there is an usage of NameFormat, in this case uri. We can just ignore ... If I'm correct about what you are doing, users will just say: Get "mail" from SAML Assertion and create a "email" claim in Keycloak.