Shibboleth ID concepts

[Manuel Haim]

Hi list,

even though we have a Shibboleth 2.x IdP cluster and some SPs running at
our institution for a while now, there seem to be some concepts of
inter-institutional federated identity management which just seem to
come into my mind and cause disorientation.

As we start to deal with external SPs, there are lots who claim to speak
Shibboleth, but it merely sounds like the Babylonian confusion. Some
just want an assertion of the user's affiliation ("Is he a student of
yours?"), some want a unique identifier ("Tell us his ID so we can
personalize his login and welcome him again where he last left.") or
even his mail address as primary key ("By his mail address we can always
contact him, and it also seems unique to us, how could one ever lose it
to another user?").

But what are best practices in a world of mixed SAML1 and SAML2 SPs? And
what can we, as an IdP, teach the SPs about the pitfalls of identity
management?

In our case, usernames and mail addresses are recycled after a while,
thus leading to the eduPersonPrincipalName not being all-time unique.
How do we ensure that a user's account at an external SP will not be
accessed by a different person some time?

AFAIK, Shibboleth 2.x introduced the NameID for this purpose, but how
many SPs do really use that? We can define an all-time-unique
persistentId as NameID, but the SPs need to know that it is not
available as a normal attribute but as a NameID. And when my mind comes
to SAML1 SPs, they still seem to prefer an eduPersonTargetedID attribute
instead (which once had the intent to be a per-SP anonymized unique ID
for a single user), while I thought the eduPersonTargetedID was
deprecated. So, should we release our same persistentId value both as
NameID and as eduPersonTargetedID attribute? Can we rely and trust in
SPs to use these? Is it a common practice to use them? Or should we
better take care of our usernames, mail addresses and the
eduPersonPrincipalName, so their values are never recycled?

Your tips and experiences are appreciated.

Best regards,
Manuel Haim