[keycloak-user] Problem using SAML IdP
Bill Burke
bburke at redhat.com
Fri Jan 22 08:56:41 EST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160122/60fa519b/attachment-0001.html
More information about the keycloak-user
mailing list