Shibboleth ID concepts

[Cantor, Scott]

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

I don't think SAML1 vs SAML2 has much to do with it (or any other protocol), but in short, there isn't much around for people to look at, and it's so dense and complex that one finds most developers won't anyway.

At one point I tried to find some time to work on a best practices guide:

https://spaces.internet2.edu/display/fedapp/Home

Never had the time to do it.

Of late, we have a couple of things in InCommon land. Nate has been working a guide for Net+ vendors that will be public soon. We also have a nascent effort to work on best practices around identifiers (for example, the email thing you mentioned) which we hope will be more well scoped then my initial attempt. It's being done as an InCommon SIG and is open to anybody to participate:

https://spaces.internet2.edu/display/InCUserIdentifiers/Home

Very early, but I hope we can make progress.

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

That's pretty well game over in today's world.

> AFAIK, Shibboleth 2.x introduced the NameID for this purpose, but how
> many SPs do really use that?

That's not a Shibboleth thing or a SAML 2 thing. Are you referring to eduPersonTargetedID? That is defined for both SAML versions and just for convenience was tied semantically to a SAML 2 construct, but it's not SAML 2 specific.

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

If SPs need to know that, their software sucks.

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

That is not the case. Please read the material I wrote on the subject in the wiki.

> So, should we release our same persistentId value both as
> NameID and as eduPersonTargetedID attribute?

If you need to.

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

I think you'll get a lot more mileage from the latter. We can't force people to handle complex identifiers, and most directed identifiers like that one are complex.
 
-- Scott