Question

I am front-ending an app with Shibboleth authentication. How can I retrieve the authenticated username in order to display it in my app?

Answer 1

eduPerson Object Class Specification (200806)

2.2.8. eduPersonPrincipalName (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.6

---

RFC 4512 definition
( 1.3.6.1.4.1.5923.1.1.1.6

      NAME 'eduPersonPrincipalName'

      DESC 'eduPerson per Internet2 and EDUCAUSE'

      EQUALITY caseIgnoreMatch

      SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )

Application utility class: standard; # of values: single

Definition

The “NetID” of the person for the purposes of inter-institutional authentication. It should be represented in the form “user@scope” where scope defines a local security domain. Multiple “@” signs are not recommended, but in any case, the first occurrence of the “@” sign starting from the left is to be taken as the delimiter between components. Thus, user identifier is to the left, security domain to the right of the first “@”. This parsing rule conforms to the POSIX “greedy” disambiguation method in regular expression processing. When the scope is a registered domain name, the corresponding registrant organization is to be taken as the scope. For example, [e-mail] would imply that the identity behind the ePPN has the “NetID” “francis” at the instituion of higher education that registered itself with the domain name “trinity.edu.” If other value styles are used, their semantics will have to be profiled by the parties involved. Each value of scope defines a namespace within which the assigned principal names are unique. Given this rule, no pair of eduPersonPrincipalName values should clash. If they are the same, they refer to the same principal within the same administrative domain.

Notes

If populated, the user should be able to authenticate with this identifier, using locally operated services. Local authentication systems should be able to adequately affirm (to both local and remote applications) that the authenticated principal is the person to whom this identifier was issued.

The initial intent is to use this attribute within the Shibboleth project, http://shibboleth.internet2.edu/. However, it has quickly become clear that a number of other applications could also make good use of this attribute (e.g. H.323 video, chat software, etc). eduPersonPrincipalName (EPPN) would be used as follows: A resource owner, A, would look at B’s directory entry to discover B’s EPPN. A would then tell the local authorization system that B’s EPPN is allowed to use the resource. When B tries to access the resource, the application (or access control infrastructure) would validate B’s identity, check with the local authorization system to ensure that B has been granted the appropriate access privileges, and then either grant or deny access.

EPPN looks like a Kerberos identifier (principal@realm). A site might choose to locally implement EPPN as Kerberos principals. However, this is not a requirement. A site can choose to do authentication in any way that is locally acceptable.

Likewise, EPPN should NOT be confused with the user’s published email address, although the two values may be the same. Some sites have chosen to make the user portion of email addresses and security principals the same character string; other sites have chosen not to do this. Even when they appear to be the same, they are used in different subsystems and for different purposes, and there is no requirement that they have to remain the same.

The uid attribute of the user’s object within the local white pages directory may also contain a login id, a security principal; some systems (eg NDS) may put a login id in the cn attribute. These attributes are defined within objectclasses that are universal. Unfortunately, their use is not prescribed in a sufficiently precise and consistent manner for use with cross domain authorization. A variety of systems already make conflicting use of these attributes; consequently, we have defined this new attribute.

An assumption is that EPPNs are managed on an enterprise basis by the univ of univ.edu. A particular EPPN is assigned solely to the associated user; it is not a security principal identifier shared by more than one person. Lastly, each EPPN is unique within the local security domain.

How long, if ever, before a formerly assigned EPPN is reassigned to a differrent individual is an institutional decision. Some institutions will choose never to reassign EPPNs. Others may opt for a relatively short hiatus before reassignment. While this complicates the work of the relying parties, it is unavoidable given institutional autonomy. See MACE best practice documents on identifiers for further discussion of these issues.

This attribute should prove useful in creating some applications that are based on currently deployed technologies and on code that does not currently use LDAP or require a PKI. This attribute should help to create a framework to foster interesting inter-institutional collaborations between sites that use different technologies. In short, this attribute provides a foundation for yet another abstraction layer.

Example applications for which this attribute would be useful
controlling access to resources

Example (LDIF Fragment)
eduPersonPrincipalName: [e-mail]

Syntax: directoryString; Indexing: pres,eq,sub

---

References:
http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonPrincipalName