IdPv3 and Hathitrust: how to resolve and release SAML

[Peter Schober]

* Wang, Lihua <lwang2 at gc.cuny.edu> [2017-07-10 18:41]:
> In the worst case, we probably could resolve sAMAccountName or some
> other attribute to eppn, but it seems best to be able to use
> persistentNameID based on the above description.

What should be added is that you can use whatever you want (as
unsuitable as you can get) and still get away with it, provided you
use an RDBMS for persistece *plus* are prepared to own the processes
of getting that database updated in a timely, automated fashion, so
that changed source identifiers will not lead to reassignment or
undesired change of the resulting persistent NameIDs.

I just remembered that side of the discussion looking for Scott's
comment about GUIDs not benig suitable (had I know it was documented I
would simply have reference the docs) -- and that documentation also
provides the full picture, one we haven't painted here so far:
https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration

So either your IDM systems are sufficiently mature to provide you with
long-lived stable identifiers that never are re-assigend to another
subject. (Then you could get away with "computed" IDs and not care
about persisting them into an RDBMS.)
Or your IDM processes are sufficiently mature you can prevent any
such changes from affecting SAML SPs. (Needs an RDBMS, plus processes
that propagate changes from the IDM system.)

If you don't have either... well you can still either join the mighty
League of Half-Assed IDP Deployers (I may have had my share in
drafting members) or join the noble Lords of Unsupportnix and Just Say
No to persistent Identifiers (with the added bonus that you get to
twist ePPN to ever new ways, because it's the only attribute you can
support). ;)

-peter