[keycloak-user] Problem using SAML IdP
Jérôme Blanchard
jayblanc at gmail.com
Fri Jan 22 11:00:28 EST 2016
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> 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> 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> 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>
>>>>> 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 <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
>>>
>>>
> --
> 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/d4104df6/attachment-0001.html
More information about the keycloak-user
mailing list