Use of the
eduPersonPrincipleName attribute should be reconsidered and possibly be phased out and replaced with the
subject-id attribute from the OASIS SAML 2.0 SubjectID Attributes Profile.
This is a globally unique identifier that looks like an email address but does not have to be. (It can be a valid email address, if you want, but noone recieving the value as an eduPersonPrincipalName attribute should try to send email there.)
Many applications expect an identifier that's suitable to being shown in the interface once logged-in. I.e., there's an expectation that an identifier is (among other things):
- not very long (as persistent NameIDs are),
- not very ugly (again persistent NameIDs),
- and can ideally be recognized by the subject to be her own / represent herself.
Most applications also seem to expect that such identifiers never change, which combined with the other requirements (globally unique, not overly long, not ugly, known/recognizable to the subject) makes this impossible to fulfill at most academic institutions. I.e., you can't win and no one attribute can solve all the requirements people throw at it.
Practically speaking there are only two reasonable ways to generate eduPersonPrincipalName values:
- from the login name / userid, by appending the scope of the IDP (e.g.
@example.ac.at) at the end, or
- by re-using the email address as eduPersonPrincipalName attribute.
The first variant (uid + scope) has the disadvantage of exposing part of the login credentials (though the userid shouldn't generally be considered secret as there usually are many ways to discover it). But it's guaranteed to exist and can be assumed to be well-known to the subject (as it has to be entered for authentication purposes), at least in its "unscoped" form.
The second variant (re-using email address values) has the problem that this only works if you're issuing email addresses in your domain (IDP scope) for all subjects that should also have an eduPersonPrincipalName attribute value (which is all your population, basically). This is required because SAML Service Providers check the scope (domain part) of eduPersonPrincipalName attibute values against the published (i.e., allowed) scopes of IDPs (column "scope"), in order to protect themselfs from one IDP impersonating subjects from another IDP. So if your IDM system hands over external email addresses to your SAML IDP (e.g.
@gmail.com, etc.) you cannot re-use email addresses as eduPersonPrincipalName attributes (at least not for that part of the population that you provide the IDP with external email addresses for).
Of course all variants here have the issue that email addresses (and sometimes even login names) occasionally change, e.g. when people change their names after marriage/divorce or religious convertion and wish for their email address (or login name) to reflect those changes. And sometimes such identifiers might even be re-assigned from one person to another (the worst case), maybe after a dormancy period of a few years. So applications relying on eduPersonPrincipalName (or any identifier that doesn't prohibit reassignment) will need to be prepared to handle such changes.
For application integrators the potential alternatives to relying on eduPersonPrincipalName in the Higher Education and Research sector basically are:
subject-idattribute from the OASIS SAML 2.0 SubjectID Attributes Profile. This is the likely future replacement for most uses of eduPersonPrincipalName.