<div dir="ltr"><div><div><div>Yes exactly. <br></div>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 : <br><br> protected Response handleLoginResponse(String samlResponse, SAMLDocumentHolder holder, ResponseType responseType, String relayState) {
<br> try {
<br> AssertionType assertion = AssertionUtil.getAssertion(responseType, realm.getPrivateKey());
<br> SubjectType subject = assertion.getSubject();
<br> SubjectType.STSubType subType = subject.getSubType();
<br> NameIDType subjectNameID = (NameIDType) subType.getBaseID();
<br> //Map<String, String> notes = new HashMap<>();
<br> if (subjectNameID.getFormat() != null && subjectNameID.getFormat().toString().equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) {
<br> if (assertion.getAttributeStatements() != null ) {
<br> for (AttributeStatementType attrStatement : assertion.getAttributeStatements()) {
<br> for (AttributeStatementType.ASTChoiceType choice : attrStatement.getAttributes()) {<br> AttributeType attribute = choice.getAttribute();
<br> if (attribute.getFriendlyName().equals("eduPersonTargetID") || attribute.getName().equals("urn:oid:1.3.6.1.4.1.5923.1.1.1.10")) {
<br> if (!attribute.getAttributeValue().isEmpty()) {
<br> //TODO Use NameId of this attribute to replace subjectNameID
<br> }
<br> }
<br> }
<br> } <br> (...)<br> }
<br> }<br><br></div>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 ?<br><br></div>Best regards, Jérôme.<br><div><div><div><br><br><div><div dir="ltr"><span style="font-size:13px"><br></span></div><div dir="ltr"><span style="font-size:13px">Le ven. 22 janv. 2016 14:56, Bill Burke <</span><a href="mailto:bburke@redhat.com" style="font-size:13px" target="_blank">bburke@redhat.com</a><span style="font-size:13px">> a écrit :</span></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Can you spell out exactly what you need here as I'm not
understanding.<br>
<br>
You need to support a complex attribute type? Is that it?</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 1/22/2016 4:27 AM, Jérôme Blanchard
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi Bill, all, <br>
<br>
</div>
I succeed in authenticating via shibboleth
federation using SAML IdP but I encounter problem.<br>
</div>
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).<br>
</div>
If I avoid this test, authentication works well using
the UsernameTemplateMapper.<br>
</div>
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...<br>
</div>
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.<br>
</div>
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.<br>
</div>
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...<br>
<br>
</div>
Best regards, Jérôme.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le jeu. 14 janv. 2016 à 15:37, Jérôme Blanchard
<<a href="mailto:jayblanc@gmail.com" target="_blank">jayblanc@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Thanks for your answer.<br>
</div>
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) : <br>
<h2><a name="msg-f:1524080979926326179_msg-f:1524080948012771841_msg-f:1524074810140845538_msg-f:1523352597466697855_utilisation_des_identifiants_utilisateur_opaques">Utilisation
des identifiants utilisateur opaques</a></h2>
<div>
<p>
Voir <a href="https://services.renater.fr/federation/faq/shibboleth#definition_d_un_identifiant_utilisateur_opaque" title="federation:faq:shibboleth" target="_blank">la
description du eduPersonTargetedID</a>
</p>
<p>
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 <b>eduPersonTargetedID</b>. </p>
<p>
Vous devrez configurer le fichier <i>AAP.xml</i> de
votre fournisseur de services Shibboleth comme indiqué
ci-dessous :
</p>
<pre><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></pre>
<p>
L'attribut sera accessible pour l'application dans
l'en-tête <acronym title="Hyper Text Transfer
Protocol">HTTP</acronym> <b><acronym title="Hyper Text Transfer Protocol">HTTP</acronym>_SHIB_TARGETEDID</b>
(avec Shibboleth 1.3). Le format du
eduPersonTargetedID est le suivant : identifiant_IdP<b>!</b>identifiant_SP<b>!</b>identifiant_utilisateur
<br>
</p>
<p><br>
</p>
<p>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 !!<br>
</p>
</div>
I'm going to have a look at UsernameTemplateMapper.<br>
</div>
Thanks again, Jérôme.<br>
<div>
<h2><a name="msg-f:1524080979926326179_msg-f:1524080948012771841_msg-f:1524074810140845538_msg-f:1523352597466697855_comment_configurer_un_fournisseur_de_services_pour_qu_il_soit_reconnu_par_plusieurs_federations"></a></h2>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le jeu. 14 janv. 2016 à 15:23, Bill Burke
<<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
<br>
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.</div>
<div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 1/14/2016 6:20 AM, Jérôme Blanchard wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi all, <br>
<br>
</div>
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.<br>
</div>
It's really annoying for me and I'm trying
to investigate a way to solve this problem.<br>
</div>
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. <br>
</div>
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.<br>
</div>
Do you think this approach is good ?<br>
<br>
</div>
<div>Best regards, Jérôme.<br>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mer. 6 janv. 2016 à 09:31, Jérôme
Blanchard <<a href="mailto:jayblanc@gmail.com" target="_blank">jayblanc@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>Hi Bill, all, <br>
<br>
</div>
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 ?<br>
<br>
</div>
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.<br>
<br>
</div>
Best regards, Jérôme.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mar. 5 janv. 2016 à 16:13,
Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We won't be able to
support temporary ids (transient) for awhile
as it<br>
requires temporary user creation which
requires some rearchitecting.<br>
<br>
As for
"urn:mace:shibboleth:1.0:nameIdentifier" if
you spec it out in a<br>
JIRA and it is simple enough to implement
support for, we may be able to<br>
get it in.<br>
<br>
On 1/5/2016 8:18 AM, Jérôme Blanchard wrote:<br>
> Hi Bill,<br>
><br>
> Thanks for your answer regarding
transient and temporary ids. I<br>
> understand the problem due to keycloak
account creation and binding to<br>
> the IdP.<br>
> Renarter is using Shibboleth ; Is there
is any work on shibboleth<br>
> integration for keycloak ?<br>
> If I look into the idps entities
descriptors of renater, I found that it<br>
> uses also another nameid format based on
shibboleth namesapce :<br>
>
<md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat><br>
>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><br>
><br>
> Do you think it is possible to patch the
saml idp provider (or to create<br>
> another one dedicated to shibboleth) in
order to integrate keycloak to<br>
> our identity federation (renater) ?<br>
><br>
> Best whiches for this upcoming year and
thanks for your great work<br>
> around keycloak.<br>
><br>
> Jérôme.<br>
><br>
><br>
> Le mar. 22 déc. 2015 à 21:10, Bill Burke
<<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>
a écrit :<br>
><br>
> Our brokering doesn't support
temporary user ids from the "parent" IDP.<br>
> Transient Ids in SAML or temporary
ids.<br>
><br>
> On 12/22/2015 11:46 AM, Jérôme
Blanchard wrote:<br>
> > Hi,<br>
> ><br>
> > I'm trying to integrate
keycloak into a the french research<br>
> federation<br>
> > of identity (renater) and I'm
facing some problems.<br>
> > Actually, when IdP respond to
keycloak i'm getting the following<br>
> error :<br>
> > PL00084: Writer: Unsupported
Attribute<br>
> >
Value:org.keycloak.dom.saml.v2.assertion.NameIDType<br>
> ><br>
> > It seems that this IdP is using
transient NameID policy only and<br>
> using<br>
> > the unspecified field in the
idp config in keycloak generate this<br>
> > exception as a return.<br>
> ><br>
> > Log of the keycloak server is
joined.<br>
> ><br>
> > I have no idea of what
happening because when I was using the test<br>
> > federation, everything was
working but no I'm in the production<br>
> > federation, login fails.<br>
> ><br>
> > The renater federation is using
Shibolleth and keycloak is not<br>
> supported<br>
> > by federation moderators so I'm
alone in the dark now...<br>
> ><br>
> > Renater provides an IdP list
that I have to parse and<br>
> synchronized with<br>
> > IdP in keycloak. As a return I
provide a list of all endpoints<br>
> for each<br>
> > keycloak registered IdP to
allow federation IdP to answear<br>
> correctly to<br>
> > the right endpoint. All of this
is done by a small web app deployed<br>
> > aside keycloak and using REST
API to synchronize all the IdP.<br>
> ><br>
> > One of the IdP entity
descriptor is joined. As you can see, only<br>
> > transient nameid policy is
supported and if I configure keycloak<br>
> to use<br>
> > email or persistent, I received
a response saying that the nameid<br>
> is not<br>
> > supported :<br>
> ><br>
> > <samlp:AuthnRequest<br>
>
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"<br>
> >
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"<br>
> ><br>
> AssertionConsumerServiceURL="<a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a>"<br>
> > Destination="<a href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" rel="noreferrer" target="_blank"></a><a href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" target="_blank">https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO</a>"<br>
> > ForceAuthn="false"
ID="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"<br>
> > IsPassive="false"
IssueInstant="2015-12-22T16:13:15.987Z"<br>
> >
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"<br>
> >
Version="2.0"><saml:Issuer<br>
> ><br>
>
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang</a></saml:Issuer><samlp:NameIDPolicy<br>
> > AllowCreate="true"<br>
> ><br>
>
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/></samlp:AuthnRequest><br>
> ><br>
> ><br>
> > <saml2p:Response
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"<br>
> ><br>
> Destination="<a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" rel="noreferrer" target="_blank"></a><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a>"<br>
> >
ID="_9d03761957aade819b6823c35bbab278"<br>
> >
InResponseTo="ID_c53b5759-cb97-4e95-b540-877a7a6c625d"<br>
> >
IssueInstant="2015-12-22T16:13:16.420Z"
Version="2.0"><saml2:Issuer<br>
> >
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"<br>
> ><br>
>
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"><a href="https://janus.cnrs.fr/idp" target="_blank"></a><a href="https://janus.cnrs.fr/idp" target="_blank">https://janus.cnrs.fr/idp</a></saml2:Issuer><saml2p:Status><saml2p:StatusCode<br>
> ><br>
>
Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><saml2p:StatusCode<br>
> ><br>
>
Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>Required<br>
> > NameID format not<br>
> >
supported</saml2p:StatusMessage></saml2p:Status></saml2p:Response><br>
> ><br>
> ><br>
> > Any help would be gracefully
appreciated.<br>
> ><br>
> > Thanks a lot, Jérôme.<br>
> ><br>
> ><br>
> ><br>
> >
_______________________________________________<br>
> > keycloak-user mailing list<br>
> > <a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
>
_______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div></blockquote></div></div></div></div></div></div>