skip to main content
Infrastructure Division of Information Technology

TAMUFederation

TAMUFederation Attributes

Federation and Identity Attributes

In a federation scenario, when a Subject attempts to access a protected Service Provider site an Identity Provider is asked to provide information, in the form of "identity attributes", about the Subject to the Service Provider. The Service Provider uses this information to evaluate whether the Subject is authorized to access the protected resource and for other purposes. These attributes might include information unique to that Subject, like an identifier email address, or more general information such as organizational affiliation or group membership.

The Identity Provider sets policies about which attributes and values are sent to which Service Providers. Without the Service Provider specifically requesting additional data, the only information returned is the Subject's targeted ID. If a Service Provider requires more information about an individual, they must contact the Identity Provider and request the additional attributes.

TAMUFederation Attribute Summary

Many of the attributes recommended for use in the TAMUFederation are used among InCommon participants. To ensure TAMUFederation participants are also able to participate in InCommon, the TAMUFederation will follow the guidelines recommended by InCommon for attributes the two Federations have in common. For the convenience of TAMUFederation participants, the InCommon recommendations are provided below.

The following is a non-exhaustive list of the attributes commonly encountered in the use of TAMUFederation-enabled services.

Attribute Summary Table
Friendly Name Formal Name Datatype Multi-valued?
eduPersonAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.1 String Enumeration Yes
eduPersonScopedAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.9 Domain-Qualified String Enumeration Yes
eduPersonPrincipalName urn:oid:1.3.6.1.4.1.5923.1.1.1.6 Domain-Qualified String No
eduPersonUniqueId urn:oid:1.3.6.1.4.1.5923.1.1.1.13 String, max. 256 characters No
sn urn:oid:2.5.4.4 String Yes (treated as Single-valued by TAMU IdP)
givenName urn:oid:2.5.4.42 String Yes (treated as Single-valued by TAMU IdP)
mail urn:oid:0.9.2342.19200300.100.1.3 String Yes (treated as Single-valued by TAMU IdP)
tamuEduPersonUIN urn:oid:1.3.6.1.4.1.4391.0.12 String No

Attribute Descriptions

eduPersonAffiliation

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

Multiple values where value is one of:

  • member
  • student
  • employee
  • faculty
  • staff
  • alum
  • affiliate
  • library-walk-in

Usage Notes

The primary intended purpose of eduPersonAffiliation is to convey broad-category affiliation assertions between members of an identity federation. Given this inter-institutional context, only values of eduPersonAffiliation with broad consensus in definition and practice will have any practical value.

A user can possess many affiliations, though some values are mutually exclusive. This attribute is often made available to any Shibboleth service provider, and is a good way to filter or block users of a given general type.

In particular, "member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

The "member" affiliation MUST be asserted for people carrying one or more of the following affiliations: faculty or staff or student or employee.

Note: Holders of the affiliation "alum" are not typically "members" since they are not eligiblea for the full set of basic institutional privileges enjoyed by faculty, staff and students.

Cautionary note: There are significant differences in practice between identity providers in the way they define faculty, staff and employee and the logical relationships between the three. In particular there are conflicting definitions of "staff" and "employee" from country to country that make those values particularly unreliable in any international context.

The "affiliate" value for eduPersonAffiliation indicates that the holder has some definable affiliation to the university NOT captured by any of faculty, staff, student, employee, alum and/or member. Typical examples might include event volunteers, parents of students, guests and external auditors. There are likely to be widely varying definitions of "affiliate" across institutions. Given that, "affiliate" is of dubious value in federated, inter-institutional use cases.

For the sake of completeness, if for some reason the institution carries digital identity information for people with whom it has no affiliation according to the above definitions, the recommendation is simply not to assert eduPersonAffiliation values for those individuals.

"Library-walk-in:" This term was created to cover the case where physical presence in a library facility grants someone access to electronic resources typically licensed for faculty, staff and students. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary. For a more direct way of using eduPerson attributes to express library privilege information, see the eduPersonEntitlement value "urn:mace:dir:entitlement:common-lib-terms" as defined in the MACE-Dir Registry of eduPersonEntitlement values http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html.

The presence of other affiliation values neither implies nor precludes the affiliation "library-walk-in."

It is not feasible to attempt to reach broad-scale, precise and binding inter-institutional definitions of affiliations such as faculty and students. Organizations have a variety of business practices and institutional specific uses of common terms. Therefore each institution will decide the criteria for membership in each affiliation classification. What is desirable is that a reasonable person should find an institution's definition of the affiliation plausible.


eduPersonScopedAffiliation

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. Multiple values are expected. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary.

The right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName (e.g., "tamu.edu") The "scope" portion MUST be the administrative domain to which the affiliation applies.

Usage Notes

Consumers of eduPersonScopedAffiliation will have to decide whether or not they trust values of this attribute. In the general case, the directory carrying the eduPersonScopedAffiliation is not the ultimate authoritative speaker for the truth of the assertion. Trust must be established out of band with respect to exchanges of this attribute value.


eduPersonPrincipalName

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

A single value of the form user@domain, where user is a name-based identifier for the person and where the domain portion MUST be the administrative domain of the identity system where the identifier was created and assigned. Each value of domain defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName.

Usage Notes

Values of eduPersonPrincipalName are often, but not required to be, human-friendly, and may change as a result of various business processes. Possibilities of changes and reassignments make this identifier unsuitable for many purposes. As a result, eduPersonPrincipalName is NOT RECOMMENDED for use by applications that provide separation between low-level identification and more presentation-oriented data such as name and email address. Common identity protocols provide for a standardized and more stable identifier for such applications, and these protocol-specific identifiers should be used whenever possible; where using a protocol-specific identifier is not possible, the eduPersonUniqueId attribute may be an appropriate "neutral" form. Syntactically, ePPN looks like an email address but is not intended to be a person’s published email address, or to be used as an email address. Consumers must not assume this is a valid email address for the individual.


eduPersonUniqueID

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

A long-lived, non re-assignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications.

This identifier represents a specific principal in a specific identity system. Values of this attribute MUST be assigned in such a manner that no two values created by distinct identity systems could collide. This identifier is permanent, to the extent that the principal is represented in the issuing identity system. Once assigned, it MUST NOT be reassigned to another principal. This identifier is meant to be freely sharable, is public, opaque, and SHOULD remain stable over time regardless of the nature of association, interruptions in association, or complexity of association by the principal with the issuing identity system. When possible, the issuing identity system SHOULD associate any number of principals associated with a single person with a single value of this attribute.

This identifier is scoped and of the form uniqueID@scope. The uniqueID portion MUST be unique within the context of the issuing identity system and MUST contain only alphanumeric characters (a-z, A-Z, 0-9). The length of the uniqueID portion MUST be less than or equal to 64 characters. The scope portion MUST be the administrative domain of the identity system where the identifier was created and assigned. The scope portion MAY contain any Unicode character. The length of the scope portion MUST be less than or equal to 256 characters. Note that the use of characters outside the seven-bit ASCII set or extremely long values in the scope portion may cause issues with interoperability.

Usage Notes

This attribute offers a powerful alternative to the use of eduPersonPrincipalName as a user identifier within applications and databases. Its power lies in the fact that it tends to be more stable than EPPN because it doesn't change merely in response to superficial name changes. It still may change, but generally in a more controlled fashion. It also requires a policy of non-reassignment. That is, while a given user may be associated with more than one value over time, a single value once assigned will never be assigned to any other user. When appropriate, the value can remain consistent across multiple service providers, if those systems have a demonstrated relationship and need to share information about the user's activities. Such sharing must be tightly controlled.

Relying parties SHOULD NOT treat this identifier as an email address for the principal as it is unlikely (though not precluded) for it to be valid for that purpose. Most organizations will find that existing email address values will not serve well as values for this identifier.


sn

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

Multiple string values containing components of the users's "family" name or surname.


givenName

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

Multiple string values containing the part of the user's name that is not their surname or middle name.


mail

Formal Definition

https://wiki.refeds.org/display/STAN/eduPerson

Description

Preferred address for the "To:" field of email to be sent to this person. Usually of the form localid@univ.edu. Though multi-valued, there is often only one value.

Usage Notes

Some mail clients will not display entries unless the mail attribute is populated. See the LDAP Recipe for further guidance on email addresses, routing, etc. (http://middleware.internet2.edu/dir/docs/ldap-recipe.htm).


tamuEduPersonUIN

Formal Definition

http://infrastructure.tamu.edu/directory/attribute/attribute_tamuEduPersonUIN.html

Description

Universal Identification Number (UIN) assigned to the person by the Texas A&M University System.

Useful Links