Re: [keycloak-user] Problem using SAML IdP

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; 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@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>>> <mailto: <keycloak-user@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>>> > >>>>> > > <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@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>>> > >>>>> > <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 >>>>> >>>> >>> -- >>> 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