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