<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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? <br>
<br>
<div class="moz-cite-prefix">On 1/22/2016 11:00 AM, Jérôme Blanchard
wrote:<br>
</div>
<blockquote
cite="mid:CAPNq5vZsRRDQVOkmneWkby=qc0=F=MOXoxg_JfKjFL8mydHGOg@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
style="font-size:13px" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.com</a></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
moz-do-not-send="true"
href="mailto:jayblanc@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jayblanc@gmail.com">jayblanc@gmail.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">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">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">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">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
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.com</a></a><br>
> <mailto:<a
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.com</a></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
moz-do-not-send="true"
href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint"
target="_blank"><a class="moz-txt-link-freetext" href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a></a>"<br>
> > Destination="<a
moz-do-not-send="true"
href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO"
target="_blank"><a class="moz-txt-link-freetext" href="https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO">https://janus.cnrs.fr/idp/profile/SAML2/POST/SSO</a></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
moz-do-not-send="true"
href="https://demo-auth.ortolang.fr/auth/realms/ortolang"
target="_blank"><a class="moz-txt-link-freetext" href="https://demo-auth.ortolang.fr/auth/realms/ortolang">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
moz-do-not-send="true"
href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint"
target="_blank"><a class="moz-txt-link-freetext" href="https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint">https://demo-auth.ortolang.fr/auth/realms/ortolang/broker/2db5eab3f83cbaa5a322dcf3f9ac552d/endpoint</a></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
moz-do-not-send="true"
href="https://janus.cnrs.fr/idp"
target="_blank"><a class="moz-txt-link-freetext" href="https://janus.cnrs.fr/idp">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
moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a>
<mailto:<a
moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a>><br>
> > <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></a><br>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division
of Red Hat<br>
> <a
moz-do-not-send="true"
href="http://bill.burkecentral.com"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></a><br>
>
_______________________________________________<br>
> keycloak-user
mailing list<br>
> <a
moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a>
<mailto:<a
moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a>><br>
> <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></a><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true" href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></pre>
</body>
</html>