[keycloak-user] Problem using SAML IdP
Jérôme Blanchard
jayblanc at gmail.com
Fri Jan 22 15:55:48 EST 2016
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 at redhat.com> 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 at 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 at redhat.com>
>> bburke at 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 at gmail.com>
>>> jayblanc at 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_identifiant_utilisateur_opaque>
>>>>
>>>> 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 at redhat.com>
>>>> bburke at 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 at gmail.com>
>>>>> jayblanc at 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 at redhat.com>
>>>>>> bburke at 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 at redhat.com>
>>>>>>> bburke at redhat.com
>>>>>>> > <mailto: <bburke at redhat.com>bburke at 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>
>>>>>>> https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint
>>>>>>> "
>>>>>>> > > 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/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint>
>>>>>>> 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>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 at lists.jboss.org>
>>>>>>> keycloak-user at lists.jboss.org <mailto:
>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at 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 at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>> <mailto: <keycloak-user at lists.jboss.org>
>>>>>>> keycloak-user at 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
>>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160122/179dfcdc/attachment-0001.html
More information about the keycloak-user
mailing list