Hi, I'm trying to integrate keycloak into a the french research federation of identity (renater) and I'm facing some problems. Actually, when IdP respond to keycloak i'm getting the following error : PL00084: Writer: Unsupported Attribute Value:org.keycloak.dom.saml.v2.assertion.NameIDType It seems that this IdP is using transient NameID policy only and using the unspecified field in the idp config in keycloak generate this exception as a return. Log of the keycloak server is joined. I have no idea of what happening because when I was using the test federation, everything was working but no I'm in the production federation, login fails. The renater federation is using Shibolleth and keycloak is not supported by federation moderators so I'm alone in the dark now... Renater provides an IdP list that I have to parse and synchronized with IdP in keycloak. As a return I provide a list of all endpoints for each keycloak registered IdP to allow federation IdP to answear correctly to the right endpoint. All of this is done by a small web app deployed aside keycloak and using REST API to synchronize all the IdP. One of the IdP entity descriptor is joined. As you can see, only transient nameid policy is supported and if I configure keycloak to use email or persistent, I received a response saying that the nameid is not supported : <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" ForceAuthn="false" ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" IsPassive="false" IssueInstant="2015-12-22T16:13:15.987Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" ID="_9d03761957aade819b6823c35bbab278" InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" IssueInstant="2015-12-22T16:13:16.420Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required NameID format not supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> Any help would be gracefully appreciated. Thanks a lot, Jérôme. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Bill, Thanks for your answer regarding transient and temporary ids. I understand the problem due to keycloak account creation and binding to the IdP. Renarter is using Shibboleth ; Is there is any work on shibboleth integration for keycloak ? If I look into the idps entities descriptors of renater, I found that it uses also another nameid format based on shibboleth namesapce : <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> Do you think it is possible to patch the saml idp provider (or to create another one dedicated to shibboleth) in order to integrate keycloak to our identity federation (renater) ? Best whiches for this upcoming year and thanks for your great work around keycloak. Jérôme. Le mar. 22 déc. 2015 à 21:10, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : Our brokering doesn't support temporary user ids from the "parent" IDP. Transient Ids in SAML or temporary ids. On 12/22/2015 11:46 AM, Jérôme Blanchard wrote: > Hi, > > I'm trying to integrate keycloak into a the french research federation > of identity (renater) and I'm facing some problems. > Actually, when IdP respond to keycloak i'm getting the following error : > PL00084: Writer: Unsupported Attribute > Value:org.keycloak.dom.saml.v2.assertion.NameIDType > > It seems that this IdP is using transient NameID policy only and using > the unspecified field in the idp config in keycloak generate this > exception as a return. > > Log of the keycloak server is joined. > > I have no idea of what happening because when I was using the test > federation, everything was working but no I'm in the production > federation, login fails. > > The renater federation is using Shibolleth and keycloak is not supported > by federation moderators so I'm alone in the dark now... > > Renater provides an IdP list that I have to parse and synchronized with > IdP in keycloak. As a return I provide a list of all endpoints for each > keycloak registered IdP to allow federation IdP to answear correctly to > the right endpoint. All of this is done by a small web app deployed > aside keycloak and using REST API to synchronize all the IdP. > > One of the IdP entity descriptor is joined. As you can see, only > transient nameid policy is supported and if I configure keycloak to use > email or persistent, I received a response saying that the nameid is not > supported : > > <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > xmlns="urn:oasis:names:tc:SAML:2.0:assertion" > AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" > Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" > ForceAuthn="false" ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > IsPassive="false" IssueInstant="2015-12-22T16:13:15.987Z" > ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Version="2.0"><saml:Issuer > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy > AllowCreate="true" > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> > > > <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" > Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" > ID="_9d03761957aade819b6823c35bbab278" > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > IssueInstant="2015-12-22T16:13:16.420Z" Version="2.0"><saml2:Issuer > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required > NameID format not > supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> > > > Any help would be gracefully appreciated. > > Thanks a lot, Jérôme. > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Bill, all, In the case of a transient only nameid, would it be possible to create a dedicated attribute mapper in order to use for exemple the email attribute as name identifier ? PS : the urn:mace:shibboleth:1.0:nameIdentifier is in fact use in SAML v1 for request a nameid that is transient also... so there is no solution in this way. Best regards, Jérôme. Le mar. 5 janv. 2016 à 16:13, Bill Burke <bburke(a)redhat.com&gt; a écrit : > We won't be able to support temporary ids (transient) for awhile as it > requires temporary user creation which requires some rearchitecting. > > As for "urn:mace:shibboleth:1.0:nameIdentifier" if you spec it out in a > JIRA and it is simple enough to implement support for, we may be able to > get it in. > > On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: > > Hi Bill, > > > > Thanks for your answer regarding transient and temporary ids. I > > understand the problem due to keycloak account creation and binding to > > the IdP. > > Renarter is using Shibboleth ; Is there is any work on shibboleth > > integration for keycloak ? > > If I look into the idps entities descriptors of renater, I found that it > > uses also another nameid format based on shibboleth namesapce : > > > <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> > > > <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> > > > > Do you think it is possible to patch the saml idp provider (or to create > > another one dedicated to shibboleth) in order to integrate keycloak to > > our identity federation (renater) ? > > > > Best whiches for this upcoming year and thanks for your great work > > around keycloak. > > > > Jérôme. > > > > > > Le mar. 22 déc. 2015 à 21:10, Bill Burke <bburke(a)redhat.com > > <mailto:bburke@redhat.com>> a écrit : > > > > Our brokering doesn't support temporary user ids from the "parent" > IDP. > > Transient Ids in SAML or temporary ids. > > > > On 12/22/2015 11:46 AM, Jérôme Blanchard wrote: > > > Hi, > > > > > > I'm trying to integrate keycloak into a the french research > > federation > > > of identity (renater) and I'm facing some problems. > > > Actually, when IdP respond to keycloak i'm getting the following > > error : > > > PL00084: Writer: Unsupported Attribute > > > Value:org.keycloak.dom.saml.v2.assertion.NameIDType > > > > > > It seems that this IdP is using transient NameID policy only and > > using > > > the unspecified field in the idp config in keycloak generate this > > > exception as a return. > > > > > > Log of the keycloak server is joined. > > > > > > I have no idea of what happening because when I was using the > test > > > federation, everything was working but no I'm in the production > > > federation, login fails. > > > > > > The renater federation is using Shibolleth and keycloak is not > > supported > > > by federation moderators so I'm alone in the dark now... > > > > > > Renater provides an IdP list that I have to parse and > > synchronized with > > > IdP in keycloak. As a return I provide a list of all endpoints > > for each > > > keycloak registered IdP to allow federation IdP to answear > > correctly to > > > the right endpoint. All of this is done by a small web app > deployed > > > aside keycloak and using REST API to synchronize all the IdP. > > > > > > One of the IdP entity descriptor is joined. As you can see, only > > > transient nameid policy is supported and if I configure keycloak > > to use > > > email or persistent, I received a response saying that the nameid > > is not > > > supported : > > > > > > <samlp:AuthnRequest > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > > xmlns="urn:oasis:names:tc:SAML:2.0:assertion" > > > > > AssertionConsumerServiceURL=" > https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... > " > > > Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" > > > ForceAuthn="false" ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > > > IsPassive="false" IssueInstant="2015-12-22T16:13:15.987Z" > > > ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > > > Version="2.0"><saml:Issuer > > > > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> > https://demo-auth.ortolang.fr/auth/realms/ortolang > </saml:Issuer><samlp:NameIDPolicy > > > AllowCreate="true" > > > > > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> > > > > > > > > > <saml2p:Response > xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" > > > > > Destination=" > https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... > " > > > ID="_9d03761957aade819b6823c35bbab278" > > > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > > > IssueInstant="2015-12-22T16:13:16.420Z" > Version="2.0"><saml2:Issuer > > > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" > > > > > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> > https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><sa... > > > > > > Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode > > > > > > Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required > > > NameID format not > > > > supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> > > > > > > > > > Any help would be gracefully appreciated. > > > > > > Thanks a lot, Jérôme. > > > > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user(a)lists.jboss.org <mailto: > keycloak-user(a)lists.jboss.org&gt; > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >

Shibboleth only supports transient name ids? I find that hard to believe. Remember Keycloak would just look like any other client. IMO you should go that route. Also though, I think you might be able to write a Broker Mapper, take a look at UsernameTemplateMapper. This SPI is undocumented and unsupported at the moment, but I hope to change that soon. On 1/14/2016 6:20 AM, Jérôme Blanchard wrote: Hi all, According to shibboleth specification, IdP of a federation usually use transient NameID which makes Shibboleth impossible to interface with keycloak, even if we manage the Discovery Service externally in order to maintain IdP list mapping between federation and keycloak. It's really annoying for me and I'm trying to investigate a way to solve this problem. In my federation, some doc say that if you need to manage personnal user information in your application, you have to rely on a dedicated attribute in order to retreive real user id and not the transient opaque one. In this case, an attribute called eduPersoneTargetedId exists and can be use by shibboleth. I am trying to patch the saml broker in order to take into consideration this attribute in a kind of attributeToNameIdMapper but I have to admit that I'm lost a bit in the code. Do you think this approach is good ? Best regards, Jérôme. Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard <jayblanc(a)gmail.com&gt; a écrit : > Hi Bill, all, > > In the case of a transient only nameid, would it be possible to create a > dedicated attribute mapper in order to use for exemple the email attribute > as name identifier ? > > PS : the urn:mace:shibboleth:1.0:nameIdentifier is in fact use in SAML v1 > for request a nameid that is transient also... so there is no solution in > this way. > > Best regards, Jérôme. > > Le mar. 5 janv. 2016 à 16:13, Bill Burke <bburke(a)redhat.com&gt; a écrit : > >> We won't be able to support temporary ids (transient) for awhile as it >> requires temporary user creation which requires some rearchitecting. >> >> As for "urn:mace:shibboleth:1.0:nameIdentifier" if you spec it out in a >> JIRA and it is simple enough to implement support for, we may be able to >> get it in. >> >> On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: >> > Hi Bill, >> > >> > Thanks for your answer regarding transient and temporary ids. I >> > understand the problem due to keycloak account creation and binding to >> > the IdP. >> > Renarter is using Shibboleth ; Is there is any work on shibboleth >> > integration for keycloak ? >> > If I look into the idps entities descriptors of renater, I found that >> it >> > uses also another nameid format based on shibboleth namesapce : >> > >> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> >> > >> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> >> > >> > Do you think it is possible to patch the saml idp provider (or to >> create >> > another one dedicated to shibboleth) in order to integrate keycloak to >> > our identity federation (renater) ? >> > >> > Best whiches for this upcoming year and thanks for your great work >> > around keycloak. >> > >> > Jérôme. >> > >> > >> > Le mar. 22 déc. 2015 à 21:10, Bill Burke <bburke(a)redhat.com >> > <mailto:bburke@redhat.com>> a écrit : >> > >> > Our brokering doesn't support temporary user ids from the "parent" >> IDP. >> > Transient Ids in SAML or temporary ids. >> > >> > On 12/22/2015 11:46 AM, Jérôme Blanchard wrote: >> > > Hi, >> > > >> > > I'm trying to integrate keycloak into a the french research >> > federation >> > > of identity (renater) and I'm facing some problems. >> > > Actually, when IdP respond to keycloak i'm getting the following >> > error : >> > > PL00084: Writer: Unsupported Attribute >> > > Value:org.keycloak.dom.saml.v2.assertion.NameIDType >> > > >> > > It seems that this IdP is using transient NameID policy only and >> > using >> > > the unspecified field in the idp config in keycloak generate >> this >> > > exception as a return. >> > > >> > > Log of the keycloak server is joined. >> > > >> > > I have no idea of what happening because when I was using the >> test >> > > federation, everything was working but no I'm in the production >> > > federation, login fails. >> > > >> > > The renater federation is using Shibolleth and keycloak is not >> > supported >> > > by federation moderators so I'm alone in the dark now... >> > > >> > > Renater provides an IdP list that I have to parse and >> > synchronized with >> > > IdP in keycloak. As a return I provide a list of all endpoints >> > for each >> > > keycloak registered IdP to allow federation IdP to answear >> > correctly to >> > > the right endpoint. All of this is done by a small web app >> deployed >> > > aside keycloak and using REST API to synchronize all the IdP. >> > > >> > > One of the IdP entity descriptor is joined. As you can see, only >> > > transient nameid policy is supported and if I configure keycloak >> > to use >> > > email or persistent, I received a response saying that the >> nameid >> > is not >> > > supported : >> > > >> > > <samlp:AuthnRequest >> > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >> > > xmlns="urn:oasis:names:tc:SAML:2.0:assertion" >> > > >> > AssertionConsumerServiceURL=" >> https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >> " >> > > Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" >> > > ForceAuthn="false" ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >> > > IsPassive="false" IssueInstant="2015-12-22T16:13:15.987Z" >> > > ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >> > > Version="2.0"><saml:Issuer >> > > >> > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> >> https://demo-auth.ortolang.fr/auth/realms/ortolang >> </saml:Issuer><samlp:NameIDPolicy >> > > AllowCreate="true" >> > > >> > >> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> >> > > >> > > >> > > <saml2p:Response >> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >> > > >> > Destination=" >> https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >> " >> > > ID="_9d03761957aade819b6823c35bbab278" >> > > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >> > > IssueInstant="2015-12-22T16:13:16.420Z" >> Version="2.0"><saml2:Issuer >> > > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" >> > > >> > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> >> https://janus.cnrs.fr/idp >> </saml2:Issuer><saml2p:Status><saml2p:StatusCode >> > > >> > >> Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode >> > > >> > >> Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required >> > > NameID format not >> > > >> supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> >> > > >> > > >> > > Any help would be gracefully appreciated. >> > > >> > > Thanks a lot, Jérôme. >> > > >> > > >> > > >> > > _______________________________________________ >> > > keycloak-user mailing list >> > > keycloak-user(a)lists.jboss.org <mailto: >> keycloak-user(a)lists.jboss.org&gt; >> > > https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > >> > >> > -- >> > Bill Burke >> > JBoss, a division of Red Hat >> > http://bill.burkecentral.com >> > _______________________________________________ >> > keycloak-user mailing list >> > keycloak-user(a)lists.jboss.org <mailto: >> keycloak-user(a)lists.jboss.org&gt; >> > https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> > -- Bill Burke JBoss, a division of Red Hathttp://bill.burkecentral.com

Hi Bill, all, I succeed in authenticating via shibboleth federation using SAML IdP but I encounter problem. One SAML attribute of our authentication response is not of type String but a fulle NameID type (eduPersonTargetId) and makes the authentication crash because of class BaseWriter which is not able to serialize an attribute which is not a String (line 176). If I avoid this test, authentication works well using the UsernameTemplateMapper. By the way, it does not solve the whole problem. The provider user id and the provider user name store the saml auth response nameid (and not an attribute) which makes the next IdP SAML session impossible to use the same keycloak account because of a change of this transient nameid... Actually, I don't see another solution than rewriting another Identity Provider based on Shibboleth attribute as a fork of the SAML provider but including. It will also allows me to include the Shibboleth DIscovery Service directly in keycloak instead of providing another webapp to ensure the federation idps synchronization by parsing periodiccaly the WAYF file. I will also provide a small patch for the BaseWriter in order to allow serialization of complex types attribute, except if you have in mind to do so... Best regards, Jérôme. Le jeu. 14 janv. 2016 à 15:37, Jérôme Blanchard <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a écrit : Thanks for your answer. In fact Shibboleth supports others saml nameid but in the renater federation, it only contains transient nameid. Here is a part of their doc (sorry it's in french) : Utilisation des identifiants utilisateur opaques Voir la description du eduPersonTargetedID <https://services.renater.fr/federation/faq/shibboleth#definition_d_un_ide... Votre application a peut-être besoin de manipuler de identifiants utilisateur, dont la valeur est stable d'une session à l'autre ; par exemple pour gérer les préférences utilisateur. Or, pour des raisons de protection des données personnelles, les fournisseurs d'identités ne peuvent vous transmettre les identifiants des utilisateurs. Dans ce cas, vous pouvez demander aux fournisseurs d'identités de vous communiquer des identifiants stables mais opaques, appelés *eduPersonTargetedID*. Vous devrez configurer le fichier /AAP.xml/ de votre fournisseur de services Shibboleth comme indiqué ci-dessous : <AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" Header="Shib-TargetedID" Alias="targeted_id"> <AnySite> <AnyValue/> </AnySite> </AttributeRule> L'attribut sera accessible pour l'application dans l'en-tête HTTP *HTTP_SHIB_TARGETEDID* (avec Shibboleth 1.3). Le format du eduPersonTargetedID est le suivant : identifiant_IdP*!*identifiant_SP*!*identifiant_utilisateur According to their doc, nameid are session based and not user based so if you want stable identifier, you have to ask for eduPersonTargetedID attribute !! I'm going to have a look at UsernameTemplateMapper. Thanks again, Jérôme. Le jeu. 14 janv. 2016 à 15:23, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : Shibboleth only supports transient name ids? I find that hard to believe. Remember Keycloak would just look like any other client. IMO you should go that route. Also though, I think you might be able to write a Broker Mapper, take a look at UsernameTemplateMapper. This SPI is undocumented and unsupported at the moment, but I hope to change that soon. On 1/14/2016 6:20 AM, Jérôme Blanchard wrote: > Hi all, > > According to shibboleth specification, IdP of a federation > usually use transient NameID which makes Shibboleth > impossible to interface with keycloak, even if we manage the > Discovery Service externally in order to maintain IdP list > mapping between federation and keycloak. > It's really annoying for me and I'm trying to investigate a > way to solve this problem. > In my federation, some doc say that if you need to manage > personnal user information in your application, you have to > rely on a dedicated attribute in order to retreive real user > id and not the transient opaque one. In this case, an > attribute called eduPersoneTargetedId exists and can be use > by shibboleth. > I am trying to patch the saml broker in order to take into > consideration this attribute in a kind of > attributeToNameIdMapper but I have to admit that I'm lost a > bit in the code. > Do you think this approach is good ? > > Best regards, Jérôme. > > > Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard > <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a écrit : > > Hi Bill, all, > > In the case of a transient only nameid, would it be > possible to create a dedicated attribute mapper in order > to use for exemple the email attribute as name identifier ? > > PS : the urn:mace:shibboleth:1.0:nameIdentifier is in > fact use in SAML v1 for request a nameid that is > transient also... so there is no solution in this way. > > Best regards, Jérôme. > > Le mar. 5 janv. 2016 à 16:13, Bill Burke > <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : > > We won't be able to support temporary ids (transient) > for awhile as it > requires temporary user creation which requires some > rearchitecting. > > As for "urn:mace:shibboleth:1.0:nameIdentifier" if > you spec it out in a > JIRA and it is simple enough to implement support > for, we may be able to > get it in. > > On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: > > Hi Bill, > > > > Thanks for your answer regarding transient and > temporary ids. I > > understand the problem due to keycloak account > creation and binding to > > the IdP. > > Renarter is using Shibboleth ; Is there is any work > on shibboleth > > integration for keycloak ? > > If I look into the idps entities descriptors of > renater, I found that it > > uses also another nameid format based on shibboleth > namesapce : > > > <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> > > > <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> > > > > Do you think it is possible to patch the saml idp > provider (or to create > > another one dedicated to shibboleth) in order to > integrate keycloak to > > our identity federation (renater) ? > > > > Best whiches for this upcoming year and thanks for > your great work > > around keycloak. > > > > Jérôme. > > > > > > Le mar. 22 déc. 2015 à 21:10, Bill Burke > <bburke(a)redhat.com <mailto:bburke@redhat.com> > > <mailto:bburke@redhat.com > <mailto:bburke@redhat.com>>> a écrit : > > > > Our brokering doesn't support temporary user > ids from the "parent" IDP. > > Transient Ids in SAML or temporary ids. > > > > On 12/22/2015 11:46 AM, Jérôme Blanchard wrote: > > > Hi, > > > > > > I'm trying to integrate keycloak into a the > french research > > federation > > > of identity (renater) and I'm facing some > problems. > > > Actually, when IdP respond to keycloak i'm > getting the following > > error : > > > PL00084: Writer: Unsupported Attribute > > > > Value:org.keycloak.dom.saml.v2.assertion.NameIDType > > > > > > It seems that this IdP is using transient > NameID policy only and > > using > > > the unspecified field in the idp config in > keycloak generate this > > > exception as a return. > > > > > > Log of the keycloak server is joined. > > > > > > I have no idea of what happening because > when I was using the test > > > federation, everything was working but no > I'm in the production > > > federation, login fails. > > > > > > The renater federation is using Shibolleth > and keycloak is not > > supported > > > by federation moderators so I'm alone in the > dark now... > > > > > > Renater provides an IdP list that I have to > parse and > > synchronized with > > > IdP in keycloak. As a return I provide a > list of all endpoints > > for each > > > keycloak registered IdP to allow federation > IdP to answear > > correctly to > > > the right endpoint. All of this is done by a > small web app deployed > > > aside keycloak and using REST API to > synchronize all the IdP. > > > > > > One of the IdP entity descriptor is joined. > As you can see, only > > > transient nameid policy is supported and if > I configure keycloak > > to use > > > email or persistent, I received a response > saying that the nameid > > is not > > > supported : > > > > > > <samlp:AuthnRequest > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > > xmlns="urn:oasis:names:tc:SAML:2.0:assertion" > > > > > > AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" > > > > Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" > > > ForceAuthn="false" > ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > > > IsPassive="false" > IssueInstant="2015-12-22T16:13:15.987Z" > > > > ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > > > Version="2.0"><saml:Issuer > > > > > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy > > > AllowCreate="true" > > > > > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> > > > > > > > > > <saml2p:Response > xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" > > > > > > Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" > > > ID="_9d03761957aade819b6823c35bbab278" > > > > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" > > > IssueInstant="2015-12-22T16:13:16.420Z" > Version="2.0"><saml2:Issuer > > > > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" > > > > > > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode > > > > > > Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode > > > > > > Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required > > > NameID format not > > > > supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> > > > > > > > > > Any help would be gracefully appreciated. > > > > > > Thanks a lot, Jérôme. > > > > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org > <mailto:keycloak-user@lists.jboss.org>> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > <mailto:keycloak-user@lists.jboss.org > <mailto:keycloak-user@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Yes exactly. But I also need to use this complex type attribute in the Endpoint.handleLoginResponse as the subjectNameID in order to avoid using the provided transient nameID ; something like : protected Response handleLoginResponse(String samlResponse, SAMLDocumentHolder holder, ResponseType responseType, String relayState) { try { AssertionType assertion = AssertionUtil.getAssertion(responseType, realm.getPrivateKey()); SubjectType subject = assertion.getSubject(); SubjectType.STSubType subType = subject.getSubType(); NameIDType subjectNameID = (NameIDType) subType.getBaseID(); //Map<String, String> notes = new HashMap<>(); if (subjectNameID.getFormat() != null && subjectNameID.getFormat().toString().equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) { if (assertion.getAttributeStatements() != null ) { for (AttributeStatementType attrStatement : assertion.getAttributeStatements()) { for (AttributeStatementType.ASTChoiceType choice : attrStatement.getAttributes()) { AttributeType attribute = choice.getAttribute(); if (attribute.getFriendlyName().equals("eduPersonTargetID") || attribute.getName().equals("urn:oid:1.3.6.1.4.1.5923.1.1.1.10")) { if (!attribute.getAttributeValue().isEmpty()) { //TODO Use NameId of this attribute to replace subjectNameID } } } } (...) } } Do you think I need to patch this class in order to allow this or do you think there is a way of integration in keycloak considering the shibboleth federation use case ? Best regards, Jérôme. Le ven. 22 janv. 2016 14:56, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : Can you spell out exactly what you need here as I'm not understanding. You need to support a complex attribute type? Is that it? On 1/22/2016 4:27 AM, Jérôme Blanchard wrote: > Hi Bill, all, > > I succeed in authenticating via shibboleth federation using SAML > IdP but I encounter problem. > One SAML attribute of our authentication response is not of type > String but a fulle NameID type (eduPersonTargetId) and makes the > authentication crash because of class BaseWriter which is not > able to serialize an attribute which is not a String (line 176). > If I avoid this test, authentication works well using the > UsernameTemplateMapper. > By the way, it does not solve the whole problem. The provider > user id and the provider user name store the saml auth response > nameid (and not an attribute) which makes the next IdP SAML > session impossible to use the same keycloak account because of a > change of this transient nameid... > Actually, I don't see another solution than rewriting another > Identity Provider based on Shibboleth attribute as a fork of the > SAML provider but including. > It will also allows me to include the Shibboleth DIscovery > Service directly in keycloak instead of providing another webapp > to ensure the federation idps synchronization by parsing > periodiccaly the WAYF file. > I will also provide a small patch for the BaseWriter in order to > allow serialization of complex types attribute, except if you > have in mind to do so... > > Best regards, Jérôme. > > Le jeu. 14 janv. 2016 à 15:37, Jérôme Blanchard > <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a écrit : > > Thanks for your answer. > In fact Shibboleth supports others saml nameid but in the > renater federation, it only contains transient nameid. Here > is a part of their doc (sorry it's in french) : > > > Utilisation des identifiants utilisateur opaques > > Voir la description du eduPersonTargetedID > <https://services.renater.fr/federation/faq/shibboleth#definition_d_un_ide... > > > Votre application a peut-être besoin de manipuler de > identifiants utilisateur, dont la valeur est stable d'une > session à l'autre ; par exemple pour gérer les préférences > utilisateur. Or, pour des raisons de protection des données > personnelles, les fournisseurs d'identités ne peuvent vous > transmettre les identifiants des utilisateurs. Dans ce cas, > vous pouvez demander aux fournisseurs d'identités de vous > communiquer des identifiants stables mais opaques, appelés > *eduPersonTargetedID*. > > Vous devrez configurer le fichier /AAP.xml/ de votre > fournisseur de services Shibboleth comme indiqué ci-dessous : > > <AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" Header="Shib-TargetedID" Alias="targeted_id"> > <AnySite> > <AnyValue/> > </AnySite> > </AttributeRule> > > L'attribut sera accessible pour l'application dans l'en-tête > HTTP *HTTP_SHIB_TARGETEDID* (avec Shibboleth 1.3). Le format > du eduPersonTargetedID est le suivant : > identifiant_IdP*!*identifiant_SP*!*identifiant_utilisateur > > > According to their doc, nameid are session based and not user > based so if you want stable identifier, you have to ask for > eduPersonTargetedID attribute !! > > I'm going to have a look at UsernameTemplateMapper. > Thanks again, Jérôme. > > > > Le jeu. 14 janv. 2016 à 15:23, Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>> a écrit : > > Shibboleth only supports transient name ids? I find that > hard to believe. Remember Keycloak would just look like > any other client. IMO you should go that route. > > Also though, I think you might be able to write a Broker > Mapper, take a look at UsernameTemplateMapper. This SPI > is undocumented and unsupported at the moment, but I hope > to change that soon. > > > On 1/14/2016 6:20 AM, Jérôme Blanchard wrote: >> Hi all, >> >> According to shibboleth specification, IdP of a >> federation usually use transient NameID which makes >> Shibboleth impossible to interface with keycloak, even >> if we manage the Discovery Service externally in order >> to maintain IdP list mapping between federation and >> keycloak. >> It's really annoying for me and I'm trying to >> investigate a way to solve this problem. >> In my federation, some doc say that if you need to >> manage personnal user information in your application, >> you have to rely on a dedicated attribute in order to >> retreive real user id and not the transient opaque one. >> In this case, an attribute called eduPersoneTargetedId >> exists and can be use by shibboleth. >> I am trying to patch the saml broker in order to take >> into consideration this attribute in a kind of >> attributeToNameIdMapper but I have to admit that I'm >> lost a bit in the code. >> Do you think this approach is good ? >> >> Best regards, Jérôme. >> >> >> Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard >> <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a écrit : >> >> Hi Bill, all, >> >> In the case of a transient only nameid, would it be >> possible to create a dedicated attribute mapper in >> order to use for exemple the email attribute as name >> identifier ? >> >> PS : the urn:mace:shibboleth:1.0:nameIdentifier is >> in fact use in SAML v1 for request a nameid that is >> transient also... so there is no solution in this way. >> >> Best regards, Jérôme. >> >> Le mar. 5 janv. 2016 à 16:13, Bill Burke >> <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : >> >> We won't be able to support temporary ids >> (transient) for awhile as it >> requires temporary user creation which requires >> some rearchitecting. >> >> As for "urn:mace:shibboleth:1.0:nameIdentifier" >> if you spec it out in a >> JIRA and it is simple enough to implement >> support for, we may be able to >> get it in. >> >> On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: >> > Hi Bill, >> > >> > Thanks for your answer regarding transient and >> temporary ids. I >> > understand the problem due to keycloak account >> creation and binding to >> > the IdP. >> > Renarter is using Shibboleth ; Is there is any >> work on shibboleth >> > integration for keycloak ? >> > If I look into the idps entities descriptors >> of renater, I found that it >> > uses also another nameid format based on >> shibboleth namesapce : >> > >> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> >> > >> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> >> > >> > Do you think it is possible to patch the saml >> idp provider (or to create >> > another one dedicated to shibboleth) in order >> to integrate keycloak to >> > our identity federation (renater) ? >> > >> > Best whiches for this upcoming year and thanks >> for your great work >> > around keycloak. >> > >> > Jérôme. >> > >> > >> > Le mar. 22 déc. 2015 à 21:10, Bill Burke >> <bburke(a)redhat.com <mailto:bburke@redhat.com> >> > <mailto:bburke@redhat.com >> <mailto:bburke@redhat.com>>> a écrit : >> > >> > Our brokering doesn't support temporary >> user ids from the "parent" IDP. >> > Transient Ids in SAML or temporary ids. >> > >> > On 12/22/2015 11:46 AM, Jérôme Blanchard >> wrote: >> > > Hi, >> > > >> > > I'm trying to integrate keycloak into a >> the french research >> > federation >> > > of identity (renater) and I'm facing >> some problems. >> > > Actually, when IdP respond to keycloak >> i'm getting the following >> > error : >> > > PL00084: Writer: Unsupported Attribute >> > > >> Value:org.keycloak.dom.saml.v2.assertion.NameIDType >> > > >> > > It seems that this IdP is using >> transient NameID policy only and >> > using >> > > the unspecified field in the idp config >> in keycloak generate this >> > > exception as a return. >> > > >> > > Log of the keycloak server is joined. >> > > >> > > I have no idea of what happening >> because when I was using the test >> > > federation, everything was working but >> no I'm in the production >> > > federation, login fails. >> > > >> > > The renater federation is using >> Shibolleth and keycloak is not >> > supported >> > > by federation moderators so I'm alone >> in the dark now... >> > > >> > > Renater provides an IdP list that I >> have to parse and >> > synchronized with >> > > IdP in keycloak. As a return I provide >> a list of all endpoints >> > for each >> > > keycloak registered IdP to allow >> federation IdP to answear >> > correctly to >> > > the right endpoint. All of this is done >> by a small web app deployed >> > > aside keycloak and using REST API to >> synchronize all the IdP. >> > > >> > > One of the IdP entity descriptor is >> joined. As you can see, only >> > > transient nameid policy is supported >> and if I configure keycloak >> > to use >> > > email or persistent, I received a >> response saying that the nameid >> > is not >> > > supported : >> > > >> > > <samlp:AuthnRequest >> > >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >> > > >> xmlns="urn:oasis:names:tc:SAML:2.0:assertion" >> > > >> > >> AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" >> > > >> Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" >> > > ForceAuthn="false" >> ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >> > > IsPassive="false" >> IssueInstant="2015-12-22T16:13:15.987Z" >> > > >> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >> > > Version="2.0"><saml:Issuer >> > > >> > >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy >> > > AllowCreate="true" >> > > >> > >> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> >> > > >> > > >> > > <saml2p:Response >> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >> > > >> > >> Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" >> > > ID="_9d03761957aade819b6823c35bbab278" >> > > >> InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >> > > IssueInstant="2015-12-22T16:13:16.420Z" >> Version="2.0"><saml2:Issuer >> > > >> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" >> > > >> > >> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode >> > > >> > >> Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode >> > > >> > >> Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required >> > > NameID format not >> > > >> supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> >> > > >> > > >> > > Any help would be gracefully appreciated. >> > > >> > > Thanks a lot, Jérôme. >> > > >> > > >> > > >> > > >> _______________________________________________ >> > > keycloak-user mailing list >> > > keycloak-user(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> <mailto:keycloak-user@lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org>> >> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > >> > >> > -- >> > Bill Burke >> > JBoss, a division of Red Hat >> > http://bill.burkecentral.com >> > _______________________________________________ >> > keycloak-user mailing list >> > keycloak-user(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> <mailto:keycloak-user@lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org>> >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Hi, Stack trace is joined. Using a UsernameTemplateMapper is not enough cause the broderId keep the transient nameid that is used to link the IdP to the keycloak Account. As soon as the IdP session expires, if I use the IdP again, a new transient nameId is generated and keycloak is not able to map the incoming SAML response to the right keycloak Account. It so open the first login form and ask for a user name (prepopulated with the ${ALIAS}.${NAMEID} syntax or the mapper value (I am unable to use the complex type in this UsernameTemplateMapper (like ${ATTRIBUTE.eduPersonTargetID.value[0]})). By the way, this attribute mapper does not override the brokerUserId : String brokerUserId = config.getAlias() + "." + subjectNameID.getValue(); identity.setBrokerUserId(brokerUserId); so a transient subjectNameID is a problem even with the UsernameTemplateMapper... It always creates a new link between account and IdP and this link does not work if the keycloak account already exists. Do you see more clearly my understanding ? (I'm sorry for my poor english) Le ven. 22 janv. 2016 à 17:06, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : Can you show me the actual crash? Stack trace? If the attribute is parsed correctly, you should be able to write a UsernameMapper to handle everything no? On 1/22/2016 11:00 AM, Jérôme Blanchard wrote: > Yes exactly. > But I also need to use this complex type attribute in the > Endpoint.handleLoginResponse as the subjectNameID in order to > avoid using the provided transient nameID ; something like : > > protected Response handleLoginResponse(String samlResponse, > SAMLDocumentHolder holder, ResponseType responseType, String > relayState) { > try { > AssertionType assertion = > AssertionUtil.getAssertion(responseType, realm.getPrivateKey()); > SubjectType subject = assertion.getSubject(); > SubjectType.STSubType subType = subject.getSubType(); > NameIDType subjectNameID = (NameIDType) subType.getBaseID(); > //Map<String, String> notes = new HashMap<>(); > if (subjectNameID.getFormat() != null && > subjectNameID.getFormat().toString().equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) > { > if (assertion.getAttributeStatements() != null ) { > for (AttributeStatementType attrStatement : > assertion.getAttributeStatements()) { > for (AttributeStatementType.ASTChoiceType choice : > attrStatement.getAttributes()) { > AttributeType attribute = choice.getAttribute(); > if > (attribute.getFriendlyName().equals("eduPersonTargetID") || > attribute.getName().equals("urn:oid:1.3.6.1.4.1.5923.1.1.1.10")) { > if (!attribute.getAttributeValue().isEmpty()) { > //TODO Use NameId of this attribute to replace > subjectNameID > } > } > } > } > (...) > } > } > > Do you think I need to patch this class in order to allow this or > do you think there is a way of integration in keycloak > considering the shibboleth federation use case ? > > Best regards, Jérôme. > > > > Le ven. 22 janv. 2016 14:56, Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>> a écrit : > > Can you spell out exactly what you need here as I'm not > understanding. > > You need to support a complex attribute type? Is that it? > > > On 1/22/2016 4:27 AM, Jérôme Blanchard wrote: >> Hi Bill, all, >> >> I succeed in authenticating via shibboleth federation using >> SAML IdP but I encounter problem. >> One SAML attribute of our authentication response is not of >> type String but a fulle NameID type (eduPersonTargetId) and >> makes the authentication crash because of class BaseWriter >> which is not able to serialize an attribute which is not a >> String (line 176). >> If I avoid this test, authentication works well using the >> UsernameTemplateMapper. >> By the way, it does not solve the whole problem. The >> provider user id and the provider user name store the saml >> auth response nameid (and not an attribute) which makes the >> next IdP SAML session impossible to use the same keycloak >> account because of a change of this transient nameid... >> Actually, I don't see another solution than rewriting >> another Identity Provider based on Shibboleth attribute as a >> fork of the SAML provider but including. >> It will also allows me to include the Shibboleth DIscovery >> Service directly in keycloak instead of providing another >> webapp to ensure the federation idps synchronization by >> parsing periodiccaly the WAYF file. >> I will also provide a small patch for the BaseWriter in >> order to allow serialization of complex types attribute, >> except if you have in mind to do so... >> >> Best regards, Jérôme. >> >> Le jeu. 14 janv. 2016 à 15:37, Jérôme Blanchard >> <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a écrit : >> >> Thanks for your answer. >> In fact Shibboleth supports others saml nameid but in >> the renater federation, it only contains transient >> nameid. Here is a part of their doc (sorry it's in >> french) : >> >> >> Utilisation des identifiants utilisateur opaques >> >> Voir la description du eduPersonTargetedID >> <https://services.renater.fr/federation/faq/shibboleth#definition_d_un_ide... >> >> >> Votre application a peut-être besoin de manipuler de >> identifiants utilisateur, dont la valeur est stable >> d'une session à l'autre ; par exemple pour gérer les >> préférences utilisateur. Or, pour des raisons de >> protection des données personnelles, les fournisseurs >> d'identités ne peuvent vous transmettre les identifiants >> des utilisateurs. Dans ce cas, vous pouvez demander aux >> fournisseurs d'identités de vous communiquer des >> identifiants stables mais opaques, appelés >> *eduPersonTargetedID*. >> >> Vous devrez configurer le fichier /AAP.xml/ de votre >> fournisseur de services Shibboleth comme indiqué >> ci-dessous : >> >> <AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" Header="Shib-TargetedID" Alias="targeted_id"> >> <AnySite> >> <AnyValue/> >> </AnySite> >> </AttributeRule> >> >> L'attribut sera accessible pour l'application dans >> l'en-tête HTTP *HTTP_SHIB_TARGETEDID* (avec Shibboleth >> 1.3). Le format du eduPersonTargetedID est le suivant : >> identifiant_IdP*!*identifiant_SP*!*identifiant_utilisateur >> >> >> According to their doc, nameid are session based and not >> user based so if you want stable identifier, you have to >> ask for eduPersonTargetedID attribute !! >> >> I'm going to have a look at UsernameTemplateMapper. >> Thanks again, Jérôme. >> >> >> >> Le jeu. 14 janv. 2016 à 15:23, Bill Burke >> <bburke(a)redhat.com <mailto:bburke@redhat.com>> a écrit : >> >> Shibboleth only supports transient name ids? I find >> that hard to believe. Remember Keycloak would just >> look like any other client. IMO you should go that >> route. >> >> Also though, I think you might be able to write a >> Broker Mapper, take a look at >> UsernameTemplateMapper. This SPI is undocumented and >> unsupported at the moment, but I hope to change that >> soon. >> >> >> On 1/14/2016 6:20 AM, Jérôme Blanchard wrote: >>> Hi all, >>> >>> According to shibboleth specification, IdP of a >>> federation usually use transient NameID which makes >>> Shibboleth impossible to interface with keycloak, >>> even if we manage the Discovery Service externally >>> in order to maintain IdP list mapping between >>> federation and keycloak. >>> It's really annoying for me and I'm trying to >>> investigate a way to solve this problem. >>> In my federation, some doc say that if you need to >>> manage personnal user information in your >>> application, you have to rely on a dedicated >>> attribute in order to retreive real user id and not >>> the transient opaque one. In this case, an >>> attribute called eduPersoneTargetedId exists and >>> can be use by shibboleth. >>> I am trying to patch the saml broker in order to >>> take into consideration this attribute in a kind of >>> attributeToNameIdMapper but I have to admit that >>> I'm lost a bit in the code. >>> Do you think this approach is good ? >>> >>> Best regards, Jérôme. >>> >>> >>> Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard >>> <jayblanc(a)gmail.com <mailto:jayblanc@gmail.com>> a >>> écrit : >>> >>> Hi Bill, all, >>> >>> In the case of a transient only nameid, would >>> it be possible to create a dedicated attribute >>> mapper in order to use for exemple the email >>> attribute as name identifier ? >>> >>> PS : the urn:mace:shibboleth:1.0:nameIdentifier >>> is in fact use in SAML v1 for request a nameid >>> that is transient also... so there is no >>> solution in this way. >>> >>> Best regards, Jérôme. >>> >>> Le mar. 5 janv. 2016 à 16:13, Bill Burke >>> <bburke(a)redhat.com <mailto:bburke@redhat.com>> >>> a écrit : >>> >>> We won't be able to support temporary ids >>> (transient) for awhile as it >>> requires temporary user creation which >>> requires some rearchitecting. >>> >>> As for >>> "urn:mace:shibboleth:1.0:nameIdentifier" if >>> you spec it out in a >>> JIRA and it is simple enough to implement >>> support for, we may be able to >>> get it in. >>> >>> On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: >>> > Hi Bill, >>> > >>> > Thanks for your answer regarding >>> transient and temporary ids. I >>> > understand the problem due to keycloak >>> account creation and binding to >>> > the IdP. >>> > Renarter is using Shibboleth ; Is there >>> is any work on shibboleth >>> > integration for keycloak ? >>> > If I look into the idps entities >>> descriptors of renater, I found that it >>> > uses also another nameid format based on >>> shibboleth namesapce : >>> > >>> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> >>> > >>> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> >>> > >>> > Do you think it is possible to patch the >>> saml idp provider (or to create >>> > another one dedicated to shibboleth) in >>> order to integrate keycloak to >>> > our identity federation (renater) ? >>> > >>> > Best whiches for this upcoming year and >>> thanks for your great work >>> > around keycloak. >>> > >>> > Jérôme. >>> > >>> > >>> > Le mar. 22 déc. 2015 à 21:10, Bill Burke >>> <bburke(a)redhat.com <mailto:bburke@redhat.com> >>> > <mailto:bburke@redhat.com >>> <mailto:bburke@redhat.com>>> a écrit : >>> > >>> > Our brokering doesn't support >>> temporary user ids from the "parent" IDP. >>> > Transient Ids in SAML or temporary ids. >>> > >>> > On 12/22/2015 11:46 AM, Jérôme >>> Blanchard wrote: >>> > > Hi, >>> > > >>> > > I'm trying to integrate keycloak >>> into a the french research >>> > federation >>> > > of identity (renater) and I'm >>> facing some problems. >>> > > Actually, when IdP respond to >>> keycloak i'm getting the following >>> > error : >>> > > PL00084: Writer: Unsupported Attribute >>> > > >>> Value:org.keycloak.dom.saml.v2.assertion.NameIDType >>> > > >>> > > It seems that this IdP is using >>> transient NameID policy only and >>> > using >>> > > the unspecified field in the idp >>> config in keycloak generate this >>> > > exception as a return. >>> > > >>> > > Log of the keycloak server is joined. >>> > > >>> > > I have no idea of what happening >>> because when I was using the test >>> > > federation, everything was working >>> but no I'm in the production >>> > > federation, login fails. >>> > > >>> > > The renater federation is using >>> Shibolleth and keycloak is not >>> > supported >>> > > by federation moderators so I'm >>> alone in the dark now... >>> > > >>> > > Renater provides an IdP list that >>> I have to parse and >>> > synchronized with >>> > > IdP in keycloak. As a return I >>> provide a list of all endpoints >>> > for each >>> > > keycloak registered IdP to allow >>> federation IdP to answear >>> > correctly to >>> > > the right endpoint. All of this is >>> done by a small web app deployed >>> > > aside keycloak and using REST API >>> to synchronize all the IdP. >>> > > >>> > > One of the IdP entity descriptor >>> is joined. As you can see, only >>> > > transient nameid policy is >>> supported and if I configure keycloak >>> > to use >>> > > email or persistent, I received a >>> response saying that the nameid >>> > is not >>> > > supported : >>> > > >>> > > <samlp:AuthnRequest >>> > >>> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >>> > > >>> xmlns="urn:oasis:names:tc:SAML:2.0:assertion" >>> > > >>> > >>> AssertionConsumerServiceURL="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" >>> > > >>> Destination="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" >>> > > ForceAuthn="false" >>> ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >>> > > IsPassive="false" >>> IssueInstant="2015-12-22T16:13:15.987Z" >>> > > >>> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >>> > > Version="2.0"><saml:Issuer >>> > > >>> > >>> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo-auth.ortolang.fr/auth/realms/ortolang</saml:Issuer><samlp:NameIDPolicy >>> > > AllowCreate="true" >>> > > >>> > >>> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> >>> > > >>> > > >>> > > <saml2p:Response >>> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >>> > > >>> > >>> Destination="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" >>> > > ID="_9d03761957aade819b6823c35bbab278" >>> > > >>> InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >>> > > >>> IssueInstant="2015-12-22T16:13:16.420Z" >>> Version="2.0"><saml2:Issuer >>> > > >>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" >>> > > >>> > >>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://janus.cnrs.fr/idp</saml2:Issuer><saml2p:Status><saml2p:StatusCode >>> > > >>> > >>> Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode >>> > > >>> > >>> Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required >>> > > NameID format not >>> > > >>> supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> >>> > > >>> > > >>> > > Any help would be gracefully >>> appreciated. >>> > > >>> > > Thanks a lot, Jérôme. >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ >>> > > keycloak-user mailing list >>> > > keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> <mailto:keycloak-user@lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org>> >>> > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > > >>> > >>> > -- >>> > Bill Burke >>> > JBoss, a division of Red Hat >>> > http://bill.burkecentral.com >>> > >>> _______________________________________________ >>> > keycloak-user mailing list >>> > keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> <mailto:keycloak-user@lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org>> >>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

I think so. If the call to this mapper is done during in the handleLoginResponse it should do the trick but it should also be able to parse a complex type to extract value of a NameIdType. Le ven. 22 janv. 2016 18:53, Bill Burke <bburke(a)redhat.com&gt; a écrit : > So, if you have a maper for the brokerUserId, that would solve the > problem? > > > On 1/22/2016 12:19 PM, Jérôme Blanchard wrote: > > Hi, > Stack trace is joined. > Using a UsernameTemplateMapper is not enough cause the broderId keep the > transient nameid that is used to link the IdP to the keycloak Account. > As soon as the IdP session expires, if I use the IdP again, a new > transient nameId is generated and keycloak is not able to map the incoming > SAML response to the right keycloak Account. It so open the first login > form and ask for a user name (prepopulated with the ${ALIAS}.${NAMEID} > syntax or the mapper value (I am unable to use the complex type in this > UsernameTemplateMapper (like ${ATTRIBUTE.eduPersonTargetID.value[0]})). > By the way, this attribute mapper does not override the brokerUserId : > String brokerUserId = config.getAlias() + "." + subjectNameID.getValue(); > identity.setBrokerUserId(brokerUserId); > so a transient subjectNameID is a problem even with the > UsernameTemplateMapper... > It always creates a new link between account and IdP and this link does > not work if the keycloak account already exists. > > Do you see more clearly my understanding ? (I'm sorry for my poor english) > > Le ven. 22 janv. 2016 à 17:06, Bill Burke <bburke(a)redhat.com&gt; a écrit : > >> Can you show me the actual crash? Stack trace? If the attribute is >> parsed correctly, you should be able to write a UsernameMapper to handle >> everything no? >> >> On 1/22/2016 11:00 AM, Jérôme Blanchard wrote: >> >> Yes exactly. >> But I also need to use this complex type attribute in the >> Endpoint.handleLoginResponse as the subjectNameID in order to avoid using >> the provided transient nameID ; something like : >> >> protected Response handleLoginResponse(String samlResponse, >> SAMLDocumentHolder holder, ResponseType responseType, String relayState) { >> try { >> AssertionType assertion = AssertionUtil.getAssertion(responseType, >> realm.getPrivateKey()); >> SubjectType subject = assertion.getSubject(); >> SubjectType.STSubType subType = subject.getSubType(); >> NameIDType subjectNameID = (NameIDType) subType.getBaseID(); >> //Map<String, String> notes = new HashMap<>(); >> if (subjectNameID.getFormat() != null && >> subjectNameID.getFormat().toString().equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) >> { >> if (assertion.getAttributeStatements() != null ) { >> for (AttributeStatementType attrStatement : >> assertion.getAttributeStatements()) { >> for (AttributeStatementType.ASTChoiceType choice : >> attrStatement.getAttributes()) { >> AttributeType attribute = choice.getAttribute(); >> if (attribute.getFriendlyName().equals("eduPersonTargetID") >> || attribute.getName().equals("urn:oid:1.3.6.1.4.1.5923.1.1.1.10")) { >> if (!attribute.getAttributeValue().isEmpty()) { >> //TODO Use NameId of this attribute to replace >> subjectNameID >> } >> } >> } >> } >> (...) >> } >> } >> >> Do you think I need to patch this class in order to allow this or do you >> think there is a way of integration in keycloak considering the shibboleth >> federation use case ? >> >> Best regards, Jérôme. >> >> >> >> Le ven. 22 janv. 2016 14:56, Bill Burke < <bburke(a)redhat.com&gt; >> bburke(a)redhat.com&gt; a écrit : >> >>> Can you spell out exactly what you need here as I'm not understanding. >>> >>> You need to support a complex attribute type? Is that it? >>> >>> >>> On 1/22/2016 4:27 AM, Jérôme Blanchard wrote: >>> >>> Hi Bill, all, >>> >>> I succeed in authenticating via shibboleth federation using SAML IdP >>> but I encounter problem. >>> One SAML attribute of our authentication response is not of type String >>> but a fulle NameID type (eduPersonTargetId) and makes the authentication >>> crash because of class BaseWriter which is not able to serialize an >>> attribute which is not a String (line 176). >>> If I avoid this test, authentication works well using the >>> UsernameTemplateMapper. >>> By the way, it does not solve the whole problem. The provider user id >>> and the provider user name store the saml auth response nameid (and not an >>> attribute) which makes the next IdP SAML session impossible to use the same >>> keycloak account because of a change of this transient nameid... >>> Actually, I don't see another solution than rewriting another Identity >>> Provider based on Shibboleth attribute as a fork of the SAML provider but >>> including. >>> It will also allows me to include the Shibboleth DIscovery Service >>> directly in keycloak instead of providing another webapp to ensure the >>> federation idps synchronization by parsing periodiccaly the WAYF file. >>> I will also provide a small patch for the BaseWriter in order to allow >>> serialization of complex types attribute, except if you have in mind to do >>> so... >>> >>> Best regards, Jérôme. >>> >>> Le jeu. 14 janv. 2016 à 15:37, Jérôme Blanchard < <jayblanc(a)gmail.com&gt; >>> jayblanc(a)gmail.com&gt; a écrit : >>> >>>> Thanks for your answer. >>>> In fact Shibboleth supports others saml nameid but in the renater >>>> federation, it only contains transient nameid. Here is a part of their doc >>>> (sorry it's in french) : >>>> Utilisation des identifiants utilisateur opaques >>>> >>>> Voir la description du eduPersonTargetedID >>>> <https://services.renater.fr/federation/faq/shibboleth#definition_d_un_ide... >>>> >>>> Votre application a peut-être besoin de manipuler de identifiants >>>> utilisateur, dont la valeur est stable d'une session à l'autre ; par >>>> exemple pour gérer les préférences utilisateur. Or, pour des raisons de >>>> protection des données personnelles, les fournisseurs d'identités ne >>>> peuvent vous transmettre les identifiants des utilisateurs. Dans ce cas, >>>> vous pouvez demander aux fournisseurs d'identités de vous communiquer des >>>> identifiants stables mais opaques, appelés *eduPersonTargetedID*. >>>> >>>> Vous devrez configurer le fichier *AAP.xml* de votre fournisseur de >>>> services Shibboleth comme indiqué ci-dessous : >>>> >>>> <AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" Header="Shib-TargetedID" Alias="targeted_id"> >>>> <AnySite> >>>> <AnyValue/> >>>> </AnySite> >>>> </AttributeRule> >>>> >>>> L'attribut sera accessible pour l'application dans l'en-tête HTTP >>>> *HTTP_SHIB_TARGETEDID* (avec Shibboleth 1.3). Le format du >>>> eduPersonTargetedID est le suivant : identifiant_IdP*!*identifiant_SP >>>> *!*identifiant_utilisateur >>>> >>>> >>>> According to their doc, nameid are session based and not user based so >>>> if you want stable identifier, you have to ask for eduPersonTargetedID >>>> attribute !! >>>> I'm going to have a look at UsernameTemplateMapper. >>>> Thanks again, Jérôme. >>>> >>>> Le jeu. 14 janv. 2016 à 15:23, Bill Burke < <bburke(a)redhat.com&gt; >>>> bburke(a)redhat.com&gt; a écrit : >>>> >>>>> Shibboleth only supports transient name ids? I find that hard to >>>>> believe. Remember Keycloak would just look like any other client. IMO you >>>>> should go that route. >>>>> >>>>> Also though, I think you might be able to write a Broker Mapper, >>>>> take a look at UsernameTemplateMapper. This SPI is undocumented and >>>>> unsupported at the moment, but I hope to change that soon. >>>>> >>>>> >>>>> On 1/14/2016 6:20 AM, Jérôme Blanchard wrote: >>>>> >>>>> Hi all, >>>>> >>>>> According to shibboleth specification, IdP of a federation usually >>>>> use transient NameID which makes Shibboleth impossible to interface with >>>>> keycloak, even if we manage the Discovery Service externally in order to >>>>> maintain IdP list mapping between federation and keycloak. >>>>> It's really annoying for me and I'm trying to investigate a way to >>>>> solve this problem. >>>>> In my federation, some doc say that if you need to manage personnal >>>>> user information in your application, you have to rely on a dedicated >>>>> attribute in order to retreive real user id and not the transient opaque >>>>> one. In this case, an attribute called eduPersoneTargetedId exists and can >>>>> be use by shibboleth. >>>>> I am trying to patch the saml broker in order to take into >>>>> consideration this attribute in a kind of attributeToNameIdMapper but I >>>>> have to admit that I'm lost a bit in the code. >>>>> Do you think this approach is good ? >>>>> >>>>> Best regards, Jérôme. >>>>> >>>>> >>>>> Le mer. 6 janv. 2016 à 09:31, Jérôme Blanchard < <jayblanc(a)gmail.com&gt; >>>>> jayblanc(a)gmail.com&gt; a écrit : >>>>> >>>>>> Hi Bill, all, >>>>>> >>>>>> In the case of a transient only nameid, would it be possible to >>>>>> create a dedicated attribute mapper in order to use for exemple the email >>>>>> attribute as name identifier ? >>>>>> >>>>>> PS : the urn:mace:shibboleth:1.0:nameIdentifier is in fact use in >>>>>> SAML v1 for request a nameid that is transient also... so there is no >>>>>> solution in this way. >>>>>> >>>>>> Best regards, Jérôme. >>>>>> >>>>>> Le mar. 5 janv. 2016 à 16:13, Bill Burke < <bburke(a)redhat.com&gt; >>>>>> bburke(a)redhat.com&gt; a écrit : >>>>>> >>>>>>> We won't be able to support temporary ids (transient) for awhile as >>>>>>> it >>>>>>> requires temporary user creation which requires some rearchitecting. >>>>>>> >>>>>>> As for "urn:mace:shibboleth:1.0:nameIdentifier" if you spec it out >>>>>>> in a >>>>>>> JIRA and it is simple enough to implement support for, we may be >>>>>>> able to >>>>>>> get it in. >>>>>>> >>>>>>> On 1/5/2016 8:18 AM, Jérôme Blanchard wrote: >>>>>>> > Hi Bill, >>>>>>> > >>>>>>> > Thanks for your answer regarding transient and temporary ids. I >>>>>>> > understand the problem due to keycloak account creation and >>>>>>> binding to >>>>>>> > the IdP. >>>>>>> > Renarter is using Shibboleth ; Is there is any work on shibboleth >>>>>>> > integration for keycloak ? >>>>>>> > If I look into the idps entities descriptors of renater, I found >>>>>>> that it >>>>>>> > uses also another nameid format based on shibboleth namesapce : >>>>>>> > >>>>>>> <md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat> >>>>>>> > >>>>>>> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> >>>>>>> > >>>>>>> > Do you think it is possible to patch the saml idp provider (or to >>>>>>> create >>>>>>> > another one dedicated to shibboleth) in order to integrate >>>>>>> keycloak to >>>>>>> > our identity federation (renater) ? >>>>>>> > >>>>>>> > Best whiches for this upcoming year and thanks for your great work >>>>>>> > around keycloak. >>>>>>> > >>>>>>> > Jérôme. >>>>>>> > >>>>>>> > >>>>>>> > Le mar. 22 déc. 2015 à 21:10, Bill Burke < <bburke(a)redhat.com&gt; >>>>>>> bburke(a)redhat.com >>>>>>> > <mailto: <bburke@redhat.com&gt;bburke(a)redhat.com&gt;&gt; a écrit : >>>>>>> > >>>>>>> > Our brokering doesn't support temporary user ids from the >>>>>>> "parent" IDP. >>>>>>> > Transient Ids in SAML or temporary ids. >>>>>>> > >>>>>>> > On 12/22/2015 11:46 AM, Jérôme Blanchard wrote: >>>>>>> > > Hi, >>>>>>> > > >>>>>>> > > I'm trying to integrate keycloak into a the french research >>>>>>> > federation >>>>>>> > > of identity (renater) and I'm facing some problems. >>>>>>> > > Actually, when IdP respond to keycloak i'm getting the >>>>>>> following >>>>>>> > error : >>>>>>> > > PL00084: Writer: Unsupported Attribute >>>>>>> > > Value:org.keycloak.dom.saml.v2.assertion.NameIDType >>>>>>> > > >>>>>>> > > It seems that this IdP is using transient NameID policy >>>>>>> only and >>>>>>> > using >>>>>>> > > the unspecified field in the idp config in keycloak >>>>>>> generate this >>>>>>> > > exception as a return. >>>>>>> > > >>>>>>> > > Log of the keycloak server is joined. >>>>>>> > > >>>>>>> > > I have no idea of what happening because when I was using >>>>>>> the test >>>>>>> > > federation, everything was working but no I'm in the >>>>>>> production >>>>>>> > > federation, login fails. >>>>>>> > > >>>>>>> > > The renater federation is using Shibolleth and keycloak is >>>>>>> not >>>>>>> > supported >>>>>>> > > by federation moderators so I'm alone in the dark now... >>>>>>> > > >>>>>>> > > Renater provides an IdP list that I have to parse and >>>>>>> > synchronized with >>>>>>> > > IdP in keycloak. As a return I provide a list of all >>>>>>> endpoints >>>>>>> > for each >>>>>>> > > keycloak registered IdP to allow federation IdP to answear >>>>>>> > correctly to >>>>>>> > > the right endpoint. All of this is done by a small web app >>>>>>> deployed >>>>>>> > > aside keycloak and using REST API to synchronize all the >>>>>>> IdP. >>>>>>> > > >>>>>>> > > One of the IdP entity descriptor is joined. As you can >>>>>>> see, only >>>>>>> > > transient nameid policy is supported and if I configure >>>>>>> keycloak >>>>>>> > to use >>>>>>> > > email or persistent, I received a response saying that the >>>>>>> nameid >>>>>>> > is not >>>>>>> > > supported : >>>>>>> > > >>>>>>> > > <samlp:AuthnRequest >>>>>>> > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >>>>>>> > > xmlns="urn:oasis:names:tc:SAML:2.0:assertion" >>>>>>> > > >>>>>>> > AssertionConsumerServiceURL=" >>>>>>> <https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >>>>>>> https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >>>>>>> " >>>>>>> > > Destination=" >>>>>>> <https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO> >>>>>>> https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" >>>>>>> > > ForceAuthn="false" >>>>>>> ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >>>>>>> > > IsPassive="false" IssueInstant="2015-12-22T16:13:15.987Z" >>>>>>> > > >>>>>>> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >>>>>>> > > Version="2.0"><saml:Issuer >>>>>>> > > >>>>>>> > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> >>>>>>> <https://demo-auth.ortolang.fr/auth/realms/ortolang> >>>>>>> https://demo-auth.ortolang.fr/auth/realms/ortolang >>>>>>> </saml:Issuer><samlp:NameIDPolicy >>>>>>> > > AllowCreate="true" >>>>>>> > > >>>>>>> > >>>>>>> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest> >>>>>>> > > >>>>>>> > > >>>>>>> > > <saml2p:Response >>>>>>> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >>>>>>> > > >>>>>>> > Destination=" >>>>>>> <https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >>>>>>> https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa... >>>>>>> " >>>>>>> > > ID="_9d03761957aade819b6823c35bbab278" >>>>>>> > > InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d" >>>>>>> > > IssueInstant="2015-12-22T16:13:16.420Z" >>>>>>> Version="2.0"><saml2:Issuer >>>>>>> > > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" >>>>>>> > > >>>>>>> > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> >>>>>>> <https://janus.cnrs.fr/idp>https://janus.cnrs.fr/idp >>>>>>> </saml2:Issuer><saml2p:Status><saml2p:StatusCode >>>>>>> > > >>>>>>> > >>>>>>> Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode >>>>>>> > > >>>>>>> > >>>>>>> Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required >>>>>>> > > NameID format not >>>>>>> > > >>>>>>> supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response> >>>>>>> > > >>>>>>> > > >>>>>>> > > Any help would be gracefully appreciated. >>>>>>> > > >>>>>>> > > Thanks a lot, Jérôme. >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > _______________________________________________ >>>>>>> > > keycloak-user mailing list >>>>>>> > > <keycloak-user(a)lists.jboss.org&gt; >>>>>>> keycloak-user(a)lists.jboss.org <mailto: >>>>>>> <keycloak-user@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org&gt; >>>>>>> > > <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> > > >>>>>>> > >>>>>>> > -- >>>>>>> > Bill Burke >>>>>>> > JBoss, a division of Red Hat >>>>>>> > <http://bill.burkecentral.com>http://bill.burkecentral.com >>>>>>> > _______________________________________________ >>>>>>> > keycloak-user mailing list >>>>>>> > <keycloak-user@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>>>>> <mailto: <keycloak-user(a)lists.jboss.org&gt; >>>>>>> keycloak-user(a)lists.jboss.org&gt; >>>>>>> > <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> > >>>>>>> >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> <http://bill.burkecentral.com>http://bill.burkecentral.com >>>>>>> >>>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com >>>>> >>>>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hathttp://bill.burkecentral.com >>> >>> >> -- >> Bill Burke >> JBoss, a division of Red Hathttp://bill.burkecentral.com >> >> > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.com > >