<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 class="sectionedit9"><a name="utilisation_des_identifiants_utilisateur_opaques" id="utilisation_des_identifiants_utilisateur_opaques">Utilisation des identifiants utilisateur opaques</a></h2>
<div class="level2">
<p>
Voir <a href="https://services.renater.fr/federation/faq/shibboleth#definition_d_un_identifiant_utilisateur_opaque" class="wikilink1" target="_self" title="federation:faq:shibboleth">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 <strong>eduPersonTargetedID</strong>.
</p>
<p>
Vous devrez configurer le fichier <em>AAP.xml</em> de votre fournisseur de services Shibboleth comme indiqué ci-dessous :
</p>
<pre class="code"><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> <strong><acronym title="Hyper Text Transfer Protocol">HTTP</acronym>_SHIB_TARGETEDID</strong> (avec Shibboleth 1.3). Le format du eduPersonTargetedID est le suivant : identifiant_IdP<strong>!</strong>identifiant_SP<strong>!</strong>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 class="sectionedit10"><a name="comment_configurer_un_fournisseur_de_services_pour_qu_il_soit_reconnu_par_plusieurs_federations" id="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">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"><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a></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"><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a></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" rel="noreferrer" target="_blank"><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></a>"<br>
> > Destination="<a href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO" rel="noreferrer" 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" rel="noreferrer" target="_blank"><a href="https://demo-auth.ortolang.fr/auth/realms/ortolang" target="_blank">https://demo-auth.ortolang.fr/auth/realms/ortolang</a></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">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" rel="noreferrer" target="_blank"><a href="https://janus.cnrs.fr/idp" target="_blank">https://janus.cnrs.fr/idp</a></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>