[keycloak-user] Problem using SAML IdP
Bill Burke
bburke at redhat.com
Fri Jan 22 12:53:16 EST 2016
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
> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:bburke at redhat.com>
>>>> > <mailto:bburke at redhat.com
>>>> <mailto: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"
>>>> > >
>>>> 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 at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> <mailto:keycloak-user at lists.jboss.org
>>>> <mailto:keycloak-user at 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 at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> <mailto:keycloak-user at lists.jboss.org
>>>> <mailto:keycloak-user at 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160122/0b02290a/attachment-0001.html
More information about the keycloak-user
mailing list