eduPersonTargetedId
Peter Schober
peter.schober at univie.ac.at
Sat Nov 11 05:11:32 EST 2017
* IAM David Bantz <dabantz at alaska.edu> [2017-11-10 18:57]:
> We use eduPersonUniqueId for unchanging assigned identifier based on the
> numeric identifier assigned all persons in our ERP;
> "forever" is too long to guarantee, but well established business practices
> maintain that identifier indefinitely regardless
> of changes in status or other identifiers assigned to that person. While
> less familiar to vended service providers, several have
> agreed to rely on ePUId rather than ePPN or other identifiers as the
> underlying key for users precisely because we do assure
> continued validity and no reassignment of the identifier. We generally
> release it as an attribute rather than using for NameID in the subject.
Sure, but unless support of ePUID is universal (or sufficiently wide)
as an SP you're stuck with having to support a range of identifiers,
not just one (even if UAlaska had the best possible IDM system; others
might not).
The Shib SP makes this trivial with the REMOTE_USER precedence list,
and you're free to only include identifiers in that list that satisfy
your requirements for stability/non-reassignment/whatever. (Or you can
iterate over the alternatives in your own code, of course.)
So now that we have chance of significantly reducing the deployment
complexity for both IDPs and SPs -- by using one of the 2 new
standardized SubjectID attributes Scott mentioned -- we'd be stupid
not to use them whenever possible at all.
While SPs that force you to configure the relevant attributes manually
in some b2b fashion won't benefit from new, hopefully widely-deployed
standard identifiers it won't hurt them either if we chose to supply
those very standard identifiers.
-peter
More information about the users
mailing list