[keycloak-user] Problem using SAML IdP
Jérôme Blanchard
jayblanc at gmail.com
Thu Jan 14 09:37:27 EST 2016
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> 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> 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> 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>> 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>
>>> > > 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>
>>> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160114/5f2b1a87/attachment-0001.html
More information about the keycloak-user
mailing list