10:06 a.m.
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(a)redhat.com
<mailto:bburke@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(a)gmail.com <mailto:jayblanc@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_ide...
>
>
> 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(a)redhat.com
> <mailto:bburke@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(a)gmail.com <mailto:jayblanc@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(a)redhat.com <mailto:bburke@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(a)redhat.com <mailto:bburke@redhat.com>
>> > <mailto:bburke@redhat.com
>> <mailto:bburke@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(a)lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>
>> <mailto:keycloak-user@lists.jboss.org
>> <mailto:keycloak-user@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(a)lists.jboss.org
>> <mailto:keycloak-user@lists.jboss.org>
>> <mailto:keycloak-user@lists.jboss.org
>> <mailto:keycloak-user@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