Internet2 Middleware |
Architecture Committee |
Directory Working Group |
(MACE-Dir) |
| Document: | |
| Internet2-mace-dir-eduPerson-200210 | October/2002 |
| Copyright © 2002 by UCAID | |
| and/or the respective authors | |
| Comments to: | |
| nmi-support@nsf-middleware.org |
The “200210” version of the eduPerson object class specification is described in this document. This version is appropriate for adoption in a production enterprise directory service environment.
EduPerson is an auxiliary object class for campus directories designed to facilitate communication among higher education institutions. It consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes. The eduPerson attributes are found in the next section. All these attribute names are prefaced with eduPerson. The eduPerson auxiliary object class contains all of them as “MAY” attributes:
( 1.3.6.1.4.1.5923.1.1.2
NAME 'eduPerson'
AUXILIARY
MAY ( eduPersonAffiliation $ eduPersonNickname $
eduPersonOrgDN $ eduPersonOrgUnitDN $
eduPersonPrimaryAffiliation $ eduPersonPrincipalName $
eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN )
It is recommended that person entries have the person, organizationalPerson and inetOrgPerson object classes defined. The former two are defined in X.521 (2001) and inetOrgPerson is defined in RFC 2798 and based in part on RFC2256. EduPerson attributes would be brought in to the person entry as appropriate from the auxiliary eduPerson object class. This represents a change from eduPerson 1.0 where the object class was defined as structural, and inherited from other person classes. Sites that have implemented eduPerson 1.0 should not experience any operational difficulties due to the object class difference between structural and auxiliary. If, however, one were to export an ldif file of person entries from an eduPerson 1.0-based directory, the ldif would have to be tweaked before being imported into a directory implementing the current version, 200210 to add the person, orgPerson and inetOrgPerson object classes to the entry.
Attributes from the person, organizationalPerson and inetOrgPerson classes are listed alphabetically in the second section of this document. The purpose of listing them is primarily as a convenience to enterprise directory designers, but in some cases notes were added to clarify aspects of meaning or usage in the education community beyond what can be found in the original standards documents.
If widespread agreement and implementation of this object class in campus directories is achieved, a broad and powerful new class of higher education applications can be deployed. Additional information on eduPerson including LDIF for implementing the object class and attributes, is available at its home on the web: http://www.educause.edu/eduperson.
Attributes in the following section were newly defined for eduPerson. Each entry specifies whether the attribute was first defined in the current version (200210) or the original version 1.0.
1. eduPersonAffiliation (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.1
( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Definition
Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).
Permissible values (if controlled)
faculty, student, staff, alum, member, affiliate, employee
If there is a value in eduPersonPrimary Affiliation, that value should be stored here as well.
The list of allowed values in the current version of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of the later versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it would be semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute empty.
"Member" is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."
"Affiliate" is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
directory of directories, white pages,
controlling access to resources
eduPersonAffiliation: faculty
Syntax: directoryString; Indexing: pres,eq,sub
2. eduPersonEntitlement (defined in eduPerson 200210); OID: 1.3.6.1.4.1.5923.1.1.1.7
( 1.3.6.1.4.1.5923.1.1.1.7
NAME 'eduPersonEntitlement'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: extended; # of values: multi
Definition
URI (either URN or URL) that indicates a set of rights to specific resources.
Notes
A simple example would be a URL for a contract with a licensed resource provider. When a principal's home institutional directory is allowed to assert such entitlements, the business rules that evaluate a person's attributes to determine eligibility are evaluated there. The target resource provider does not learn characteristics of the person beyond their entitlement. The trust between the two parties must be established out of band. One check would be for the target resource provider to maintain a list of subscribing institutions. Assertions of entitlement from institutions not on this list would not be honored. See the first example below.
URN values would correspond to a set of rights to resources based on an agreement across the relevant community. MACE (Middleware Architecture Committee for Education) affiliates may opt to register with MACE as a naming authority, enabling them to create their own URN values. See the second example below.
The driving force behind the definition of this attribute has been the MACE Shibboleth project. Shibboleth defines an architecture for inter-institutional sharing of web resources subject to access controls. For further details, see the project's web pages at http://shibboleth.internet2.edu/.
Examples:
eduPersonEntitlement: http://xstor.com/contracts/HEd123
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
controlling access to resources
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
Syntax: directoryString;
3. eduPersonNickname (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.2
( 1.3.6.1.4.1.5923.1.1.1.2
NAME 'eduPersonNickname'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Definition
Person's nickname, or the informal name by which they are accustomed to be hailed.
Notes
Most often a single name as opposed to displayName which often consists of a full name. Useful for user-friendly search by name. As distinct from the cn (common name) attribute, the eduPersonNickname attribute is intended primarily to carry the person's preferred nickname(s). E.g., Jack for John, Woody for Durwood, JR for Joseph Robert.
Carrying this in a separate attribute makes it relatively easy to make this a self-maintained attribute If it were merely one of the multiple values of the cn attribute, this would be harder to do. A review step by a responsible adult is advisable to help avoid institutionally embarrasing values being assigned to this attribute by would-be malefactors!
Application developers can use this attribute to make directory search functions more "user friendly."
directory of directories, white pages
eduPersonNickname: Spike
Syntax: directoryString; Indexing: pres,eq,sub
4. eduPersonOrgDN (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.3
( 1.3.6.1.4.1.5923.1.1.1.3
NAME 'eduPersonOrgDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )
Application utility class: core; # of values: single
Definition
The distinguished name (DN) of the of the directory entry representing the institution with which the person is associated.
Notes
With a distinguished name, the client can do an efficient lookup in the institution's directory to find out more about the organization with which the person is associated.
Cn (common name), sn (surname, family name) and this attribute, eduPersonOrgDN, are the three attributes satisfying the "core" application utility class of eduPerson.
The directory entry pointed to by this dn should be represented in the X.521(2001) "organization" object class The attribute set for organization is defined as follows:
o (Organization Name, required}
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet
businessCategory
seeAlso
searchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject auxiliary object class to the organization object pointed to by this dn, which endows it with a labeledURI attribute. Some directory servers implement this object class by default. For others, the schema may need to be extended using this definition (using the syntax specified by RFC2252):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )
directory of directories, white pages
eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: None recommended
5. eduPersonOrgUnitDN (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.4
( 1.3.6.1.4.1.5923.1.1.1.4
NAME 'eduPersonOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
Application utility class: standard; # of values: multi
Definition
The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s). May be multivalued, as for example, in the case of a faculty member with appointments in multiple departments or a person who is a student in one department and an employee in another.
Notes
With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's organizational unit(s).
The directory entry pointed to by this dn should be represented in the X.521(2001) "organizational unit" object class. In addition to organizationalUnitName, this object class has the same optional attribute set as the organization object class:
ou (Organization Unit Name, required) Note that O is NOT required.
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet
businessCategory
seeAlso
searchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject auxiliary object class to the organization object pointed to by this dn, which endows it with a labeledURI attribute. Some directory servers implement this object class by default. For others, the schema may need to be extended using this definition (using the syntax specified by RFC2252):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )
directory of directories, white pages
eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: eq
6. eduPersonPrimaryAffiliation (defined in eduPerson 1.0);
OID: 1.3.6.1.4.1.5923.1.1.1.5
( 1.3.6.1.4.1.5923.1.1.1.5
NAME 'eduPersonPrimaryAffiliation'
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
Specifies the person's PRIMARY relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).
Permissible values (if controlled)
faculty, student, staff, alum, member, affiliate, employee
Appropriate if the person carries at least one of the defined eduPersonAffiliations. The choices of values are the same as for that attribute.
Think of this as the affiliation one might put on the name tag if this person were to attend a general institutional social gathering. Note that the single-valued eduPersonPrimaryAffiliation attribute assigns each person in the directory into one and only one category of affiliation. There are application scenarios where this would be useful.
The list of allowed values in the current version of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of future versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it is semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute unpopulated.
"Member" is intended to include faculty, staff, student, and other persons granted a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."
"Affiliate" is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
directory of directories, controlling access to resources