Using a custom attribute as the eppn
Cantor, Scott
cantor.2 at osu.edu
Tue Aug 9 14:51:23 EDT 2016
> We have a database full of
> users who registered for the QDR site with a variety of email addresses,
> many of which do not end in ".edu". Therefore, by definition, we do not
> have an eduPersonPrincipalName for each of our users.
The "real" EPPN attribute is simply a standard attribute for identifying a user by means of a human-friendlyish value that's not required to be an email address but does have that format and a basic notion of domain-qualification (i.e., scope) that makes it useful in certain ways. It is NOT an email address and it certainly doesn't have to end in .edu. It has nothing to do with education at all in point of fact. The rest of the world simply hacked up an Internet based on email addresses, and higher ed didn't.
> I'm attempting to
> use the users' email addresses as their eppns. Right now I've configured my
> IdP to send the users email address in an attribute called "eppn"
EPPN is not called "eppn" in SAML. LDAP attributes that are standardized are named by URN-based OIDs, and EPPN is one of those. So if you're not using the OID, you're not using EPPN and you can do whatever the heck you like, but the result will confuse whoever comes along later.
As far as populating the "real" EPPN attribute with an email address, that is allowable, provided you meet the requirements of the EPPN attribute's defintion, which admittedly aren't really substantial.
> Is it possible to configure a custom attribute named "eppn", or does the
> eppn have to be a .edu address?
The default policy in the SP applies a scoping rule to the values mapped to the local SP attribute called "eppn" such that the SAML metadata has to carry a Scope extension authorizing the domain/scope appearing in the values. It doesn't matter that it ends in .edu, it matters that it's authorized for the IdP to assert it.
That rule fires regardless of why/how the local attribute called "eppn" got populated, the rules act based on the local attribute ID only. If you don't want it to fire, you can change the policy.
Somebody should get this application to stop requiring a header called "eppn". Applications should not be dictating the name of the data element they consume. Hacking things into specifically named headers is a recipe for a lot of confusion.
-- Scott
More information about the users
mailing list