Persistent ID instead of Transient Name ID

[Peter Schober]

* Melvin Lasky via users <users at shibboleth.net> [2023-01-11 16:51]:
> In all my time of using shibboleth, I’ve never had a vendor say they
> want 0 attributes. But, alas, that’s what I’m faced with this
> week. However, they do want a persistent ID that’s non-identifiable
> to a person? I’m not even sure how this would be possible

Well, not /directly/ identifiable, to /them/, /solely/ from the value
of the identifier -- would be the fully qualified version of that
statement.

> This is what they asked for: "Do you have the option to send an
> opaque, unique, and unchanging user identifier? "

You could check out section 8.3.7 of SAML Core:
https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

> Also in their metadata they have:
>     <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
>     <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
>     <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
>     <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
> 
> Which I don’t understand, LOL.

Hopefully the explanation from SAML Core helps.

If you intended to literally fulfill that requirement and start
supporting SAML 2.0 persistent NameIDs in 2023 CE then you would:
* set idp.persistentId.sourceAttribute in conf/saml-nameid.properties
  to the attribute to use as basis for those opaque values. (Note that
  derived values will only be as unchanging as the source attribute
  you derive them from.)
* uncomment/enable the SAML2PersistentGenerator in
  conf/saml-nameid.xml
and reload the relevant NameID generation sub system or restart the IDP.

Then based on the above metadata your IDP should release persistent
NameIDs (keyed off of the configured source attribute) to that SP (and
potentially others) -- assuming you don't have added support to assert
emailAddress-valued NameIDs before. (If you did you'd have to add a
NameID override for this SP, too.)
You can validate this using `aacli --saml2 -n $someuser -r $spentityid`

*But* since saml2int v2 essentially deprecated use of any and all
NameIDs (except for transient, but only to enable SLO) I'd seriously
question whether adding support for (literal) SAML 2.0 persistent
NameIDs now would be a good idea?
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html

Maybe the SP can be convinved to accept a SAML PairwiseID *attribute*
instead, after all. Which you probably won't have readily available in
your IDP either, but at least you'd be adding the modern replacement
format that way, not the legacy data structure.

HTH,
-peter