<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 13/12/2017 à 22:05, Peter Schober a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">* Jehan PROCACCIA <a class="moz-txt-link-rfc2396E" href="mailto:jehan.procaccia@tem-tsp.eu"><jehan.procaccia@tem-tsp.eu></a> [2017-12-13 18:53]:
</pre>
<blockquote type="cite">
<pre wrap="">indeed in the edugain federation metadata, the SP does ask for a
NameIDFormat to be persitent (and (or ?)) transient
</pre>
</blockquote>
<pre wrap="">
The Shibboleth IDP will use the first format listed that it can
support. So if you configuired your IDP to support persistent NameIDs
there'd be nothing else for you to do/change in this case (persistent
listed before transient in NameIDFormat).</pre>
</blockquote>
OK, I understand that because NameIDFormat in edugain metadata list
persitent before transient<br>
<br>
<pre wrap=""><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat></pre>
<br>
then , no matter the order beans are defined in my saml-nameid.xml
(here transient before persistent) <br>
<br>
<i> <util:list id="shibboleth.SAML2NameIDGenerators"></i><i><br>
</i><i> <ref bean="shibboleth.SAML2TransientGenerator"
/></i><i><br>
</i><i> <ref bean="shibboleth.SAML2PersistentGenerator" /></i><i><br>
</i><i> <bean
parent="shibboleth.SAML2AttributeSourcedGenerator"</i><br>
<br>
that's the order in metadata that will decide wich one to use .<br>
<br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
But the SP in question (the <a class="moz-txt-link-rfc2396E" href="https://monitor.eduroam.org/...">"https://monitor.eduroam.org/..."</a> one)
also supports the eduPersonTargetedID attribute, </pre>
</blockquote>
yes, I didn't realised in the first place that in <br>
<pre wrap=""><md:RequestedAttribute Name="urn:oid:<b>1.3.6.1.4.1.5923.1.1.1.10</b>" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
</pre>
oid 1.3.6.1.4.1.5923.1.1.1.10 stands for : eduPersonTargetedID !
(cf
<a class="moz-txt-link-freetext" href="https://www.internet2.edu/products-services/trust-identity/mace-registries/internet2-object-identifier-oid-registrations/">https://www.internet2.edu/products-services/trust-identity/mace-registries/internet2-object-identifier-oid-registrations/</a>)
<br>
<br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">so instead of messing
with NameIDs you can simply generate the attribute as you always did
and release it via the attribute filter, as you always did.</pre>
</blockquote>
you mean as a <i>AttributeDefinition xsi:type="</i><i><b>ad:Simple</b></i><i>"</i>,
and not necessarely as<i> AttributeDefinition
id="eduPersonTargetedID"</i> of type <i>xsi:type="</i><i><b>ad:SAML2NameID</b></i><i>"
</i><i><b>nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</b></i><i>"
</i><br>
<br>
I've probably been missleaded to that complexity of persitent NameID
because of perhaps old docs ? <br>
<a class="moz-txt-link-freetext" href="https://services.renater.fr/federation/docs/installation/idp3/chap11#creer_un_attribut_persistentidedupersontargetedid">https://services.renater.fr/federation/docs/installation/idp3/chap11#creer_un_attribut_persistentidedupersontargetedid</a><br>
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID#NativeSPTargetedID-SAML2.0Attribute">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID#NativeSPTargetedID-SAML2.0Attribute</a><br>
<br>
So I build now eduPersonTargetedID as a simple attribute based on
our ldap eppn value<br>
<br>
<resolver:AttributeDefinition id="eduPersonTargetedID"<br>
xsi:type="ad:Simple"
sourceAttributeID="eduPersonPrincipalName"><br>
<resolver:Dependency ref="myLDAP" /><br>
<resolver:AttributeEncoder
xsi:type="enc:SAML1String"<br>
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
/><br>
<resolver:AttributeEncoder
xsi:type="enc:SAML2String"<br>
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
friendlyName="eduPersonTargetedID" /><br>
</resolver:AttributeDefinition><br>
<br>
but still not sure if I need to use <i>AttributeEncoder
xsi:type="enc:SAML2String"</i> or <i>AttributeEncoder
xsi:type="enc:SAML1XMLObject"</i> ?<br>
<br>
here are idp-process log when I connect now to
<a class="moz-txt-link-freetext" href="https://monitor.eduroam.org/sp">https://monitor.eduroam.org/sp</a><br>
<i><br>
</i><i>2017-12-14 11:06:35,647 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247]
- Attribute Definition '</i><i><b>eduPersonTargetedID</b></i><i>':
produced an attribute with the </i><i><b>following values </b></i><i>[StringAttributeValue{<a class="moz-txt-link-abbreviated" href="mailto:value=procaccia@tem-tsp.eu">value=procaccia@tem-tsp.eu</a>}]</i><i><br>
</i><i>2017-12-14 11:06:35,688 - DEBUG
[net.shibboleth.idp.attribute.filter.AttributeRule:177] -
Attribute filtering engine
'/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/AttributeRule:_31e435e70cb69d038291a0f733a06691'
</i><i><b>Filter has permitted the release of 1 values for attribute
'eduPersonTargetedID'</b></i><i><br>
</i><i> <saml2:Attribute FriendlyName=</i><i><b>"eduPersonTargetedID</b></i><i>"</i><i><br>
</i><i> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" </i><i><b>NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"</b></i><i>></i><i><br>
</i><i> <saml2:AttributeValue</i><i><br>
</i><i> xmlns:xsd=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a></i><i><br>
</i><i>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xsi:type="xsd:string"><a class="moz-txt-link-abbreviated" href="mailto:procaccia@tem-tsp.eu">procaccia@tem-tsp.eu</a></saml2:AttributeValue></i><i><br>
</i><i> </saml2:Attribute></i><i><br>
</i><i>2017-12-14 11:06:43,744 - INFO [Shibboleth-Audit.SSO:241] -
20171214T100643Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|</i><i><br>
</i><i>|uid,mail,</i><i><b>eduPersonTargetedID</b></i><i>,eduPersonPrincipalName||_7078212a76e5317000482206b25264955</i><br>
<br>
so everything seems fine, howerver I still cannot verify access to
the service as of <br>
<a class="moz-txt-link-freetext" href="https://monitor.eduroam.org/sp/module.php/saml/sp/saml2-acs.php/default-sp">https://monitor.eduroam.org/sp/module.php/saml/sp/saml2-acs.php/default-sp</a>
end up on a HTTP ERROR 500 !? (perhaps a pb on their side currently
...) <br>
and Renater test attribute page
<a class="moz-txt-link-freetext" href="https://test.federation.renater.fr/test/ressource">https://test.federation.renater.fr/test/ressource</a> does works fine
but doesn't show me the <b>eduPersonTargetedID , <br>
</b>neither the consent module, before sending attributes, it only
showed me<b> </b>uid,mail,eduPersonPrincipalName and not
eduPersonTargetedID<b> !?</b><br>
<br>
I'll wait for monitor.eduroam.org , perhaps a maintenance state ...
, but it still strange to me why attribute viewer test service don't
show my eduPersonTargetedID<b><br>
</b>If I did it wrong , please let me know .<b><br>
<br>
</b>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
I'm pretty sure the same applies to the other SP by RENATER,
<a class="moz-txt-link-freetext" href="https://services.renater.fr/shibboleth">https://services.renater.fr/shibboleth</a> as that shows no sign of
requiring a persistent NameID, and also not an emailAddress-type
NameID as you have configured for that service.
I highly doubt that RENATER Would really require custom modifications
to all their member IDPs in order to let them access this SP. In SAML
Metadata that SP requires "mail" via RequestedAttributes, so again I'd
simply ignore NameIDs here and release the mail attribute, same as for
every other service that needs the subject's email address.</pre>
</blockquote>
yes mail attribute is released correctly for those SPs<br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
So ignoring NameIDS seems to be the proper way to deal with both of
your cases.</pre>
</blockquote>
again, maybe I've been missleaded by "old docs/practices " ? , but
still I see lot of IDPs owners in my community generating that
eduPersonTargetedID persitendID on a DB (storeID) <br>
I am not following that path until now for reason of simplicity and
not having to manage a DB (spof) , <br>
Is that persitendID with associated storeID a best practice ? <br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">my problem is that I need to generate an eduPersonTargetedID for
some SPs and I don't want to have a storeID in a DB used for each
and every connexions, and don't dare to manage a DB for those rare
usages So I want to generate that eduPersonTargetedID as a
computedID on the fly and use it only for a "whitelist" of specific
SPs
</pre>
</blockquote>
<pre wrap="">
You can do the same with "proper" persistent NameIDs, i.e., generate
them algorithmically. Release is triggered via NameIDFormat elements
automagically, but you can override that in multiple ways (activation
conditions, relying party overrides) if needed.
</pre>
<pre wrap="">
As explained above (and you should just ask RENATER instead of having
me speculate or do guesswork on your own part) this SP is unlikely to
need NameIDs with the format
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
(I'll refrain from commenting on the synax as I've managed to avoide
activationConditions everywhere so far.)
</pre>
<blockquote type="cite">
<pre wrap=""># For computed IDs, set a source attribute and a secret salt:
idp.persistentId.sourceAttribute = mail
idp.persistentId.useUnfilteredAttributes = true
# Do *NOT* share the salt with other people, it's like div ?ulging your private key.
idp.persistentId.algorithm = SHA
idp.persistentId.salt = secret
</pre>
</blockquote>
<pre wrap="">
Well, obviously (?) email addresses make a very bad basis for
persistent NameIDs (same for eduPersonTargetedIDs) as commonly they'll
change once a person changes parts of her name or her userid. At least
you could combine that with another attribute in the attribute
resolver that's unlikely to be the same for another person with the
same name/userid, e.g. birth date. (Contatenate email+birthdate in a
new AttributeDefintion and make that the sourceAttribute for your
persistent NameIDs and for eduPersonTargetedIDs.)</pre>
</blockquote>
for now, to debug, i've built my attribute based on eppn, but if it
finnaly works, you're right , I could concatenate name+birthdate or
whatever with a ScriptAttributeDefinition I guess :<br>
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition">https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition</a><br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
And of course instead of setting useUnfilteredAttributes=true you
probably should simply release the email attribute to the SP, which
would then trigger the release of the email attribute-based NameID.</pre>
</blockquote>
yes found in
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration">https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration</a><br>
"<i>The process above requires that you explicitly release the
attribute to use as a source in your filter policy. If you wish,
you can avoid this step by using a generator property (</i><i><code>useUnfilteredAttributes</code></i><i>)
that allows an unreleased attribute to be used as a source, but
note that doing so creates a sort of "pseudo-policy" exposing
information to an SP outside of the normal filtering process.</i>"<br>
<br>
Thanks a lot .<br>
jehan .<br>
<blockquote type="cite"
cite="mid:20171213210438.5ts244vie4qgikmj@aco.net">
<pre wrap="">
Best regards,
-peter
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>