persitentID nameID for specific SPs, transient for default

[Peter Schober]

* Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> [2017-12-13 18:53]:
> indeed in the edugain federation metadata, the SP does ask for a
> NameIDFormat to be persitent (and (or ?)) transient

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).

But the SP in question (the "https://monitor.eduroam.org/..." one)
also supports the eduPersonTargetedID attribute, 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.

I'm pretty sure the same applies to the other SP by RENATER,
https://services.renater.fr/shibboleth 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.

So ignoring NameIDS seems to be the proper way to deal with both of
your cases.


> 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

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.


> <!-- SAML 2 NameID Generation -->
>     <util:list id="shibboleth.SAML2NameIDGenerators">
> 
>         <ref bean="shibboleth.SAML2TransientGenerator" />
> 
>         <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
>         <ref bean="shibboleth.SAML2PersistentGenerator" />
> 
>         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>             p:attributeSourceIds="#{ {'mail'} }" >
> 
>                 <property name="activationCondition">
>                 <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://services.renater.fr/shibboleth" />
>                 </property>
>         </bean>
> 
>     </util:list>

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.)

> # 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

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.)

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.

Best regards,
-peter