|
NSF Middleware Initiative Document: internet2-mace-dir-localdomainperson-200505.html Category: Informational |
Brendan Bellina University of Notre Dame |
|
Copyright © 2005 by Internet2 and/or the respective authors |
May 2005 |
|
Comments to: nmi-support@nsf-middleware.org |
Local Domain Person Object Class Study
In the fall of 2003 a survey authored by Brendan Bellina and Ann West of the MACE-Dir team was circulated via Internet2 and EDUCAUSE email lists. The intent of the survey was to determine how institutions are using locally defined person object classes or attributes in their enterprise LDAP directories. This document is an analysis of the results provided by 23 institutions as of April 20, 2004. The author and the MACE-Dir team hope that this analysis may prove helpful to those directory architects and designers who have the need to maintain attributes and information beyond the limits of the eduPerson object class.
Abstract
Table of Contents
1 Introduction.
2 Conventions used in this document
3 Terminology & Usage Examples
4 Attribute Creation and Approval Processes
4.1 Why Create Local Attributes
4.2 The Directory Standards Committee
5 Implementation of EduPerson
5.1 eduPerson Object Class Deviations
6 Use of Local Attributes and Local Object Classes.
6.1 Additional Personal Characteristics
6.2 Additional Contact Information
6.3 Student-Specific Information
6.4 Employee-Specific Information
6.5 Multi-campus Information
6.6 Linkage Identifiers
6.7 Entry Metadata
6.8 Security Attributes
6.9 Privacy Attributes
6.10 Authorization Information
6.11 Other Miscellaneous Attributes
7 Object Class Characteristics
8 Future Plans Being Considered
9 Most Valuable Multiple-Use Local Attributes
10 Addenda
10.1 Survey Text – Fall 2003
11 Documents and Links
12 Advice To Implementers
13 Change Log
14 Acknowledgments
15 References
16 Contact Information 20
This document is an analysis of the responses to a MACE-Dir survey conducted in the Autumn of 2003. The intent of the survey was to determine similarities in the practices of institutions regarding person-related attributes in locally maintained enterprise directory LDAP object classes.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.
ACI - Access Control Instruction
Access control is the mechanism by which you define access. When the server receives a request, it uses the authentication information provided by the user in the bind operation, and the access control instructions (ACI’s) defined in the server to allow or deny access to directory information. The server can allow or deny permissions such as read, write, search, and compare. The permission level granted to a user may be dependent on the authentication information provided. (Definition taken from iPlanet Directory Server 4 documentation.)
ACL - Access Control List
A list of Access Control Instructions (ACI’s) constitutes an Access Control List.
authentication (authN)
Authentication is the process of establishing whether or not a real-world subject is who or what its identifier says it is. Identity can be proven by: Something you know, like a password; Something you have, as with smart-cards, challenge-response mechanisms, or public-key certificates; Something you are, as with positive photo identification, fingerprints, and biometrics. (For more on this topic, see the Internet-2 Middleware Authentication website at <http://middleware.internet2.edu/core/authentication.html>.)
authorization (authZ)
The determination that a request can be honored is known as authorization. (For more on this topic, see the Internet-2 Middleware Authorization website at <http://middleware.internet2.edu/core/authorization.html>.)
auxiliary object class
An LDAP object class that is used to add a set of related attributes to an entry that already belongs to a structural object class.
directory
A directory is a specialized database that may contain information about an institution’s membership, groups, roles, devices, systems, services, locations, and other resources.
eduOrg
An LDAP object class authored and promoted by the EDUCAUSE/Internet2 eduPerson Task Force to facilitate the development of inter-institutional applications. The eduOrg object class focuses on the attributes of organizations. Current documentation on the eduOrg object class is available at <http://www.educause.edu/eduperson/>.
eduPerson
An LDAP object class authored and promoted by the EDUCAUSE/Internet2 eduPerson Task Force to facilitate the development of inter-institutional applications. The eduPerson object class focuses on the attributes of individuals. Current documentation on the eduPerson object class is available at <http://www.educause.edu/eduperson/>.
enterprise directory
An enterprise directory is a core middleware architecture that may provide common authentication, authorization, and attribute services to electronic services offered by an institution. See the “Middleware Business Case” <http://middleware.internet2.edu/earlyadopters/draft-internet2-ea-mw-business-case-00.pdf> for a thorough discussion of the values provided by enterprise directory services.
enterprise directory infrastructure
The infrastructure required to support and maintain an enterprise directory. This may include multiple directory hardware components as well as the processes by which data flows into and out of the directory service.
GUID
GUID stands for Globally Unique Identifier. A guid is a unique identifier intended to identify a single person for the entire period of their intersection with an institution’s electronic services.
inetOrgPerson
inetOrgPerson is a standard LDAP object class that contains attributes describing people. inetOrgPerson is structurally descended from the standard organizationalPerson object class and often used as a parent for localized object classes.
Kerberos
Kerberos is a network authentication system for use on physically insecure networks, based on the key distribution model presented by Needham and Schroeder. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptography systems such as DES.
LDAP directory
An LDAP directory is one that supports the Lightweight Directory Access Protocol (LDAP). LDAP is a widely adopted IETF standard directory access protocol well suited to the authentication and authorization needs of modern application architectures. Sun Java System Directory Server
(formerly SunONE Directory Server, formerly iPlanet Directory Server), Netscape Directory Server, OpenLDAP, Novell eDirectory, Oracle Internet Directory, IBM Secureway, and Microsoft Active Directory are examples of directory products that support the LDAP protocol. (For more on this topic, see RFC1487 http://www.ietf.org/rfc/rfc1487.txt, RFC1777 http://www.ietf.org/rfc/rfc1777.txt, RFC2251 http://www.ietf.org/rfc/rfc2251.txt, and the LDAP Roadmap http://www.kingsmountain.com/ldapRoadmap.shtml.)
metadirectory (also meta-directory)
The metadirectory is a set of processes where source data is captured, identities are joined, and resulting data is transformed according to business processes and then stored or pushed to a directory or other application-serving repository. (For more on this topic, see Metadirectory Practices for Enterprise Directories in Higher Education <http://middleware.internet2.edu/dir/metadirectories/internet2-mace-dir-metadirectories-practices-200210.htm>.)
object class
An LDAP object class defines what attributes can be in an LDAP entry. Typically an object class models a real-world object such as a person.
registry
The registry is the system in which identity of resources is resolved. This often refers to a database component of the enterprise directory.
alt. def.: Data taken from multiple source/owner systems to which “intelligence” has been applied in preparation for feed to one or more directories, applications, or other consumer systems. Further “intelligence” may be applied as part of any individual feeding process. Registry data may be housed in a relational database, indexed files, or a directory server.
structural object class
An LDAP object class that describes the basic aspects of an object.
The enterprise directory architect must face the need to consider the appropriateness of creating local object classes and attributes in order to support applications. This may arise for several reasons, including the needs to meet authentication requirements, authorization requirements, or attribute release requirements.
The practice of using standard object classes such as person, organizationalPerson, inetOrgPerson, and eduPerson, helps to reduce the need for creating local attributes, but as a directory implementation matures occasions are likely to arise in which the standard object classes and attributes alone do not suffice. In such cases the creation of local object classes with local attributes is generally preferred to extending the standard object classes or overloading standard attributes.
Standard object classes may not be suitable for other reasons. Universities whose directory implementations preceded eduPerson may not have adopted the eduPerson object class, and respondents from the University of Amsterdam and Cardiff University in Wales, United Kingdom indicated that the eduPerson object class did not meet their requirements due in part to the differences between European and American campus systems.
Several questions which should be considered when adding attributes or object classes include:
- should an attribute be added to an existing object class or a new object class created
- should an existing standard attribute be used rather than creating a new attribute
- how should a new object class be related to existing object classes
- will the new attribute be used exclusively by one application or accessible by multiple applications or services
- is the content of the new attribute sensitive, and if so how will appropriate access be ensured and inappropriate access be prevented
- how should the attribute be indexed to ensure maximum efficiency without the degradation of overall directory performance
- what should be the syntax of the new attribute be to ensure appropriate searching
- what metadirectory processes will be required to populate the attribute for new and existing entries
With all of the questions to be considered it is not surprising that a directory architect may find it tempting to overload the use of an already existing attribute from a standard object class or extend a standard object class rather than creating a new attribute in a locally defined object class.
Even so, survey respondents overwhelmingly indicated that they avoided extending standard object classes, instead creating their own local object classes for their local attributes. Reasons given for this include: a desire to prevent conflicts in attribute names as standards evolve; the belief that local object classes will be more flexible to maintain; a belief that separate object classes are easier for outsiders to understand; and the desire to have an unmistakable separation between locally defined attributes and standard attributes.
While some institutions have informally entrusted the directory architect with the authority to make decisions regarding the creation and maintenance of attributes and object classes, others are developing formal committees to manage directory standards. Both Rutgers University and Denison rely upon campus committees to determine the appropriate attributes for directory entries. These committees consist of individuals representing the different departments and data stewards of the campus.
The value of formal institutional committees is described in the NMI-EDIT Enterprise Directory Implementation Roadmap <http://www.nmi-edit.org/roadmap/directories.html>:
To ensure a smooth transition between existing policy and political environments, make sure that individuals critical to the process buy into your plan. Data custodians, for instance, should be involved not only in the initial data discussions and feed implementations, but also the longer term oversight and management of the directory. If your campus doesn't have a data administration policy for the various systems on campus, you will need to address this to build the directory. Begin discussing of big policy issues such as this early on, because they take significant time to develop.
Question: Have you implemented the eduPerson object class or an object class that makes use of the eduPerson attributes? Which attributes have you populated or intend to populate and how are you making use or planning to make use of them?
The eduPerson object class is a product of the EDUCAUSE/Internet2 eduPerson Task Force which has the mission of defining an LDAP object class that includes widely-used person attributes in higher education to facilitate the implementation of inter-institutional applications. The current eduPerson specification is available at <http://www.educause.edu/eduperson/>.
Of the twenty-three respondents, nineteen had implemented the eduPerson object class. Respondents who had not implemented eduPerson cited the earlier development of their directory service (Columbia University) or the view that eduPerson does not adequately meet the requirements of European institutions due its U.S. focus and to the differences between European and American campus systems (Cardiff University, University of Amsterdam).
While the responses do not necessarily indicate widespread implementation of eduPerson outside of the United States, Thomas Lenggenhager at the Swiss Education & Research Network (SWITCH) reported the active use of an eduPerson derived object class, swissEduPerson, in their Shibboleth (<http://shibboleth.internet2.edu/>) deployment. It should also be noted that as of this writing work on an international eduPerson standard is underway which may prove applicable to a more geographically diverse audience.
The University of Amsterdam also plans to implement eduPerson in summer 2004 as a prerequisite to deploying Shibboleth and U-Portal. They expect to make use of the eduPerson affiliation attributes, but may need to extend the vocabulary to accommodate local requirements.
Of the nineteen institutions which have implemented eduPerson, sixteen populate some number of the eduPerson attributes. Respondents who had not yet populated eduPerson attributes explained that they expect to as local and inter-institutional applications require them.
The eduPerson attributes most commonly implemented are the affiliation attributes eduPersonPrimary Affiliation and eduPersonAffiliation. The count of respondents populating eduPerson attributes is as follows:
13 eduPersonPrimaryAffiliation
12 eduPersonAffiliation
9 eduPersonPrincipalName
5 eduPersonNickname
5 edupersonOrgDN
5 eduPersonOrgUnitDN
4 edupersonEntitlement
The eduPersonPrimaryAffiliation and eduPersonAffiliation attributes, while the most commonly implemented, have in some cases been extended to include values that are not within the specified vocabulary in order to be more compatible with institutional data and applications.
Melinda Jones of the University of Colorado at Boulder describes their extensions to the vocabulary of eduPersonAffiliation as follows:
Of the permissible values, we are not using “alum”. We expanded the list of values to include “Officer/Professional” and “Retiree”. We may at some time add something like “alum” and a “prospect” affiliation. We have found that this attribute, along with the attribute “description” are very helpful in authorization to services. Together they are the best representation of how someone is affiliated at UCB.
Notre Dame currently populates eduPersonAffiliation and eduPersonPrimaryAffiliation with some non-standard values, but plans to replace the non-standard values with the standard value “member” and store non-standard affiliation values in a locally defined ndAffiliation attribute.
Finding the eduPerson affiliation attribute vocabulary somewhat limiting, Columbia University also stores its affiliation values in a local attribute.
The University of Amsterdam expects that the eduPerson affiliation vocabulary may need to be extended to include local values to reflect
… contractstudent (does not follow the regular curriculum and pays his/her own way - no government subsidy), retiree or pensioner (ex-professors that are still involved in research and get facilities from the university), guest-teachers, prospective students, maybe some different categories of affiliate.
- Marijke Vandecappelle, University of Amsterdam
Question: Have you created additional local attributes?
Twenty-two of the twenty-three respondents indicated that they had implemented additional local attributes. In several cases the number of additional attributes exceeded thirty. In almost all cases locally defined attributes were added to a locally defined object class rather than extending a standard object class. Most respondents have implemented a single local object class for people, but one, the University of Alaska, chose to implement separate local object classes for students and employees, in addition to a uakEduPerson object class. The University of Notre Dame has implemented an ndEduPerson object class for people, but in addition has implemented an auxiliary ndDirectoryEntry object class which contains attributes such as ndGuid (a globally unique identifier) which are common to all directory entry types, including people and groups.
Flexibility and the desire to remain standards-compliant were the reasons given for creating local object classes rather than modifying a standard object class such as inetOrgPerson or eduPerson.
While local attributes differ among institutions, the needs that the attributes are intended to meet often fall within common categories. Each of the following subsections will discuss a classification of attributes.
Personal characteristics describe the individual represented by the entry. The attributes cn, surname, givenname are examples of standard attributes which describe personal characteristics. Nearly half of respondents had defined local attributes to capture additional personal characteristics. The following appeared in multiple survey responses:
Gender – used to indicate whether an individual is male or female (specified by three non-U.S. institutions only, so perhaps this is less useful, usable, or relevant for U.S. institutions)
Prior name – a multi-valued attribute used to hold a person’s prior name(s) for searching/matching purposes.
Middle name – a multi-valued attribute used to hold a person’s middle name(s) for searching/matching purposes.
Formal/Official name – a single-valued attribute used to hold the formal version of a person’s name.
Spouse name
Birth date
Deceased date
Marital status – single, married, separated, divorced
Citizenship – a multi-valued attribute containing codes for the person’s citizenship
Immigration status
Home town
Generation Qualifier – Jr., Sr., III, IV, V, VI, etc.
Less common personal characteristics specified by survey respondents include:
Personal Title After – Indicates that the person’s personal title follows their name rather than preceding it (exp. John Cardinal O’Hara)
Sort name – Used to hold the version of the name by which it should be sorted. This addresses names such as “Vincent Van Gogh” which might be sorted on “Gogh” rather than “Van”.
Many respondents use local attributes to meet the need for additional contact information. The need for such attributes is common due to the nature of the populations present in higher education. The following are the most common with some explanation of population and usage:
Addresses – campus, local, home, permanent, unlisted
Phone numbers – campus, local, home, permanent, unlisted, mobile
Emergency contact information – name, phone, address
Several respondents use local attributes to meet the need for student-specific information to be captured for use by applications. The following are some of the local attributes reported:
Class – Freshman, Sophomore, Junior, Senior, 5th Year, etc.
Major
Minor
College
Concentration
Curriculum
Degree
Status – codes from student system indicating applicant, enrolled, etc.
Cohort year – the year a person prefers to be grouped with [note: how is it used]
Start date
Last term enrolled
Several respondents use local attributes to meet the need for employee-specific information to be captured for use by applications. The following attributes were reported:
Primary Department
Title + department – a multi-valued linkage of these two attributes
Primary title + department
Affiliation – local values, generally more varied or granular than what eduPersonAffiliation allows
Office Hours
Type/category code/position – generally codes provided by the Employment/HR system
For institutions which have multiple campus it may be useful to define a campus code attribute, as the University of Colorado at Boulder has done to indicate which campuses a person is associated with (cuEduPersonPrimaryCampus, cuEduPersonCampus). The number of survey respondents was not great enough to determine the degree to which this is a useful attribute at other multi-campus institutions.
Linkage attributes are those identifiers which are used to link a directory entry with records in external data stores or other directory entries. The use of linkage identifiers can obviate the need to synchronize data elements between systems of record and the enterprise directory. One respondent stressed that this can be critical in keeping directory maintenance and administration costs low.
...linkage identifiers are a key factor in keeping the size of the EDS small. When pressure builds to expand the type and amount of data kept in the EDS beyond what the technical staff can reasonably maintain, adding linkage identifiers can release that pressure by offering natural pathways from the EDS to the richer data repositories that the application builders actually need access to. If each application needed access to multiple data repositories then this approach would fail (one big reason for having an EDS is to offer one-stop data shopping, and if you make the EDS so small that application builders still have to shop around, the value of the EDS comes into question). Typically, though, each application really only needs access to the EDS - and maybe one other data repository. So, e.g., an “alumni whitepage” application may indeed require access to a richer set of addresses and contact information than we can reasonably maintain in the EDS. As a result, this application may need to use a linkage ID to get from the EDS to a set of corresponding user objects in the alumni/development back-end database. But that's just two systems they need to access. It's not as if they're multiplexing across multiple systems; rather, just two systems: the EDS and one other database. As a result, their application is not rendered dramatically more complex by requiring the builders to utilize a linkage ID and directly access the alumni/development database.
- Richard L. Goerwitz III, Carleton College
Linkage attributes are also used in the implementation of metadirectory services. Attributes commonly listed by respondents in this category include:
Directory Unique ID – GUID or UUID used to identify the entry
ERP ID – the ID used in the primary ERP system (examples include the SCT Banner PIDM and the Peoplesoft ID)
Kerberos Principal
University ID
Email aliases
Student ID
Government assigned identifiers – U.S. Social Security Number (SSN), Social Insurance Number (SIN), Citizenship/Immigration ID
Network Operating System (NOS) identifiers – A link to Microsoft Active Directory sid, dn, cn, or uid; Netware ID; UNIX uid
Application Foreign Keys – links to external data base records to allow the retrieval of information from those data stores upon request
Former/Prior id’s
Entry metadata attributes are used to contain information about the entry itself, often its status, birth, and death. Such attributes can be critical to metadirectory processing. The following are the most common with some explanation of population and usage:
Entry creation date
Decay date – indicates the date at which the entry begins the deactivation process
Expiration date – indicates the date at which the entry should be deactivated
Countdown – a numeric value indicating the number of days remaining until deactivation will occur
Proxy – the dn of a person allowed to edit the entry in addition to the entry owner
Entry type – indicates what type of entry an entry is: individual, group, object, device
Administrator Comment – used by the directory administrator to make non-public notes about the entry
Entry Owner – used to indicate the owner of a non-person account
Data Source – indicates which system of record is the master source for the entry
Rather than including entry metadata attributes in their localDomainPerson object class, the University of Notre Dame created an auxiliary object class, ndDirectoryEntry, to contain such attributes.
Security attributes are used to assist in authentication-related activities such as password self-reset. Three of the respondents store PIN numbers, while one stores questions and answers, in order to allow users to reset their own password without having to know it.
Another security-related attribute mentioned in survey responses is Public key (University of Illinois uiucEduPersonalPublicKey (user populated), Notre Dame ndPGPpublickey (not currently populated), is Public key, which is a cryptographic key (one part of a public-private key pair) used to facilitate document/email encryption and document signing.
Nearly half of respondents had defined local attributes in order to indicate the privacy preferences of constituents. Most often these attributes indicate whether an entry is visible publicly, visible only to affiliates of the institution, or not visible at all. In some cases only specific attributes, such as phone, address, and email address, are restricted, in other cases all attributes are restricted.
Carleton College uses three Boolean attributes: carlHideInfo, carlHideInfoExternally, and carlHidePersonalInfo. carlHideInfo is set to true for those who have requested privacy under the FERPA (U.S. Family Educational Rights and Privacy Act) act. carlHideInfoExternally is set to true to prevent the release of campus contact information to those external to Carleton. carlHidePersonalInfo is set to true to restrict access to home contact information.
University of Alabama in Huntsville, Oakland University, University of Illinois at Urbana-Champaign, the University of Colorado at Boulder, and the University of Alaska each use a single attribute (uahEduRestrict, ouEduPersonPrivacy, uiucEduSuppress, cuEduPersonPrivacy, keepPrivatePerFERPA, respectively) to indicate whether a person has requested the release of their entry to be restricted.
Worcester Polytechnic Institute uses an attribute, wpieduPersonPrivacy, to indicate that the personal attributes are not released except to authenticated users.
Rutgers University uses a single attribute, rulinkRutgersEduHidden, to indicate whether it is hidden externally (value “external”) or hidden completely (value “true”). The University of Amsterdam uses the attribute privacyDirective similarly to indicate if an entry may be published on the web, seen by institutional users only, or not seen at all.
The University of Notre Dame uses a combination of two local attributes and the standard entry-level aci (access control instruction) attribute to allow a wide range of user-selectable privacy settings. The ndEntryStatus attribute is used to indicate whether an entry is visible to the public, visible only to ND users, or completely restricted. Through a self-service web site ND users can set the ndEntryStatus attribute to affect their entire entry, but in addition specify the same levels of restriction individually for each of their directory attributes with their preferences recorded in the attribute ndVisibilityControl and enforced via an entry level aci.
In addition to the keepPrivatePerFERPA attribute in their uakStudent object class, the University of Alaska has attributes in their uakEmployee object class, acceptFERPA and acceptFERPAdate, which indicate that an employee has accepted the responsibility of viewing FERPA restricted student records and the date and time of this acceptance.
Authorization for services is often implemented in LDAP directories either through the use of entry attributes or group memberships. (For information regarding LDAP groups please see the MACE Best Practices for Directory Groups document at http://middleware.internet2.edu/dir/groups.)
Most of the survey respondents are not yet using their LDAP directories to provide central authorization services, but those that are do so in one of two ways.
The first and simplest way is to implement a separate attribute for each application or service that a person is authorized for. This results in local attributes such a wirelessLANaccess, BlackboardAccess, DialInAccess. This can result in a large number of isolated attributes however as more applications and services begin to use the central directory service.
The second way make use of a single generic authorization attribute.
The University of Amsterdam is migrating from the use of several application-level attributes to a single multi-valued generic attribute called “uvaApplicaties” which will be used to list the names of services that may be used or are specifically denied.
The University of Notre Dame uses a generic multi-valued attribute called “ndAuthEligible” to indicate which service dn’s are authorized to see the entry. Each LDAP-enabled application uses a service dn to perform a pre-authentication search by uid when a person logs in to the application, and so if an entry does not have the service dn listed in its ndAuthEligible then the query will fail and the user will be unable to log in to the application.
Survey respondents may also be using group memberships to provide authorization capability, but this was not a specific topic of the survey.
Without clear standards to provide direction locally defined attributes can and do vary significantly among institutions. While most attributes are unique to an institution a few attributes stand out as perhaps worth considering for broader use.
Cardiff University uses an attribute to store the groups that an entry is a member of, cardiffInterestGroup. An attribute such as this can prove useful in order to retrieve attributes of group members with a single query, to construct groups based on group memberships, and to define aci’s to allow group members specific privileges.
The University of Notre Dame has a similar group-list attribute called ndWasMemberOf which is populated just prior to an entry being deactivated so that in the event that the entry needs to be reactivated it can be quickly added back into any automated groups it had been a member of without having to wait until the nightly enterprise group rebuild process. While not as useful as an isMemberOf attribute it does not incur the overhead of synchronizing group memberships and member attributes. There is an isMemberOf attribute in Notre Dame’s Microsoft Active Directory component of their enterprise directory, but the attribute, while populated automatically, has not been used.
Question: If localDomainPerson attributes are part of a localDomainPerson object class, then is that object class a structural or auxiliary object class, and if the former, is its superior inetOrgPerson, eduPerson, or some other object class?
As discussed in section 4.1 above almost all respondents had decided to create local object classes to contain additional attributes rather than extending a standard object class.
Of the respondents who provided details about their localDomainPerson object class, six had defined the object class as structural with its superior being inetOrgPerson, and six had defined it as an auxiliary object class, and one split local attributes between both an auxiliary object class and a structural object class.
One reason given by a few schools for using a structural object class is that the eduPerson standard recommends that the localDomainPerson object class be a structural object class with its superior being inetOrgPerson.
Those who chose to use auxiliary object classes cite additional flexibility.
The University of Notre Dame chose to implement both a auxiliary object class and a structural object class. The auxiliary object class ndDirectoryEntry contains attributes which are intended to be common to all entries in the directory, which includes an entry GUID, notation attribute, status attribute, source attribute, usage attribute, category attribute, owner, create date, modify timestamp, expiration date, deactivation date, and a few additional attributes. The ndEduPerson object class is a structural oc whose superior is inetOrgPerson, following the eduPerson recommendations, and contains the attributes that are specifically for people.
Question: What attributes have you considered creating but have not? Why not?
Most respondents left this question blank or responded that there were none. A few of the interesting responses to this question include:
We have considered implementing a number of attributes called uvicEduPersonPrevXXX, where this records previous values for the XXX attribute. We have not done so yet because we are not certain that the maintenance and publishing of historical information is an appropriate use of LDAP. We have also considered creating attributes called uvicEduPersonULXXX where this records unlisted values for the XXX attribute, such as unlisted telephone numbers etc. In this case we have not proceeded because we are uncertain of the soundness of creating new attributes for this purpose, when the same effect might be accomplished through ACLs etc.
- Garry Sagert, University of Victoria
People want everything but the kitchen sink in LDAP. But our position is that we are too small to maintain a large, central identity-provisioning system tied to LDAP. We maintain a simple LDAP server that contains virtually no data of its own. It merely accepts and merges data from other systems, such as our ERP system, our development/alumni relations database, our security card-access system, and our prospect recruitment system. We find that this arrangement is maintainable at Carleton, and it circumvents political problems that come when you try to centralize identity/authentication provisioning.
- Richard L. Goerwitz III, Carleton College
I've tried to resist creating anything that is not used and I also strongly resist creating attributes that represent status information for programmers. There is always pressure from people to put in things for 'future use' or just because they are there. I only add attributes when the future use becomes current use. That works fairly well.
- Marijke Vandecappelle, University of Amsterdam
It is worth noting that three of the respondents that have MIT Kerberos realms have resisted adding enterprise account passwords into their directory – Columbia University, the University of Colorado at Boulder, and the University of Notre Dame. The primary reason given that Kerberos is designed to be a password store, while LDAP directories are not. Northwestern University has indicated plans to move in the opposite direction, moving the role of password store from Kerberos to their central registry.
Question: Are there local attributes that have been valuable to more than one application? If so, what attributes and what applications?
Attributes that indicate affiliation, privacy, contact information, group membership, system identifiers, entry status information, and application/service authorization were most commonly listed in the responses.
Affiliation attributes were found to be of use for portal services, access to self-service, degrees of privacy settings (Notre Dame, for example, allows students to mark their directory entries public, visible to ND-users-only, or completely private, while staff and faculty can only choose public or ND-users-only), authorization for applications, and white pages (online campus directory service).
Privacy attributes were found to be of use for white pages applications and other applications which are allowed to search the directory and display information. They are also useful for metadirectory functions when determining what data to release to other databases or directories from the central directory.
Contact information attributes (addresses, phone numbers, etc.) were found to be useful for white pages and portal applications.
Entry status information, group membership, and application/service authorization attributes were found to be useful for authorization services.
System identifiers were found to be useful for the implementation of metadirectory services and for allowing applications to use the directory as a means of retrieving the information necessary to retrieve information about a person from other databases and services.
Employee departmental/title attributes were found to be useful for authorization services and white pages.
Below is the text from the survey distributed in the Fall of 2003.
A request for information on local directory object class attributes:
This request will be distributed through several media and mailing lists, so our apologies to those who receive multiple copies.
It is becoming common practice for institutions to extend their enterprise directory schema with both the eduPerson object class and a local object class that contains additional attributes not included in the eduPerson specifications, referred to in this note as “localDomainPerson”. Over time, these localized object classes are modified to support the growing number of directory-enabled applications at the institution and may grow to contain a significant number of attributes.
The Internet2 MACE-Dir team would like to collect information from institutions who have implemented these localized object class attributes as opposed to standard schemas and eduPerson. Once collected, this information will be analyzed in order to determine whether there are patterns of deployment that can be recommended as common or best practices and can inform future revisions of the eduPerson schema.
If you have implemented a localized object class at your institution, please consider sharing your knowledge and experience with others by providing responses to the following questions. The information we receive will be published in an anonymous and aggregated fashion on a MACE-Dir sponsored website and may be referenced in future white papers and educational materials.
An online version of this survey is available at: http://middleware.internet2.edu/dir/. Please respond to either the email questions below or use the web form for your submissions.
1. Have you implemented the eduPerson objectclass or an objectclass that makes use of the eduPerson attributes? Which attributes have you populated or intend to populate and how are you making use of or planning to make use of them?
2. Have you created additional local attributes? If yes, please provide naming, indexing, and usage information, as well as information as to their range of values and how they are populated and their relation to your systems of record and/or registry database.
3. Are these local attributes…
a) part of a localDomainPerson (If yes, please provide specifics including whether the localDomainPerson object class is structural or auxiliary, and if the former whether its superior is inetOrgPerson, eduPerson, or some other objectclass.)
Or
b) local extensions to eduPerson or other standard person-related object classes? (If yes, please describe.)
4. What was your rationale for deciding on 3(a) or 3(b) above?
5. What attributes have you considered creating but have not? Why not?
6. Are there local attributes which have been valuable to more than one application? If so, what attributes and what applications?
7. If you have not implemented a localDomainPerson object class, then what have you done to support the specific attribute needs of the directory-enabled applications at your institution?
8. What institution or organization within an institution do you represent?
9. Please provide the email address and name of someone who can be contacted for additional follow-up questions or clarification.
10. Please provide a link to online documentation if available.
11. Do you grant permission for credited excerpts of your response to be used in forthcoming summaries and/or educational materials?
Please send responses to Brendan_Bellina@nd.edu and Ann West at awest@educause.edu.
The MACE-Dir team appreciates your involvement.
The MACE-Dir team is a working team of the Middleware Architecture Committee for Education (MACE) focused on directory technology issues. For more information, refer to http://middleware.internet2.edu/dir/
The EDUCAUSE/Internet2 eduPerson object class is an LDAP was designed and is maintained by MACE-Dir and is used to facilitate the implementation of inter-institutional applications. For more information, refer to http://www.educause.edu/eduperson/.
MACE Best Practices for Directory Groups
<http://middleware.internet2.edu/dir/groups/draft-internet2-mace-dir-groups-best-practices-01.html>
<http://www.educause.edu/eduperson/>
Metadirectory Practices for Enterprise Directories in Higher Education
NMI-EDIT Enterprise Directory Implementation Roadmap
<http://www.nmi-edit.org/roadmap/directories.html>
A Recipe for Configuring and Operating LDAP Directories
<http://www.duke.edu/~gettes/giia/ldap-recipe/>
Links to additional directory schema/design information provided by respondents:
Rutgers (<http://rulink.rutgers.edu/schema.html>)
Univ. of Illinois (<http://www.cites.uiuc.edu/ldap/schema.html>)
Univ. of Victoria (<http://ldap.uvic.ca>)
SWITCH (<http://www.switch.ch/aai/docs/LDAP-schemas/swissedu-1.1.schema> and <http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf>)
Michigan Tech (<http://ldap.mtu.edu/docs/public/mtu_dsinfo/index.shtml>)
MIT (<http://web.mit.edu/admin/assignments/object-identifiers>)
University of Alaska (<http://www.alaska.edu/its/hat/doc_center/EDIR.pdf>)
Notre Dame (<http://eds.nd.edu>)
Internet2 Middleware (MACE) website <http://middleware.internet2.edu/>
Internet2 MACE Authentication website <http://middleware.internet2.edu/core/authentication.html>
Internet2 MACE Authorization website <http://middleware.internet2.edu/core/authorization.html>
This section lists the changes (other than typographical corrections) that have been made between released versions
This author wishes to acknowledge the contributions of Ann West of EDUCAUSE/Internet2, Nate Klingenstein of Internet2 for the online development, and the members of the MACE-Dir group for their valuable feedback.
The author gratefully acknowledges the survey respondents for their time and the valuable information they provided. They are (in no particular order):
Barry Ribbeck of the University of Texas Health Science Center at Houston
Allan E. Johannesen of Worcester Polytechnic Institute (WPI)
James H. McCullars of The University of Alabama in Huntsville
Chris G. Sellers from Oakland University
Marijke Vandecappelle of the University of Amsterdam
Benn Oshrin or Columbia University
Paul Rock of Cardiff University
Albert Steiner of Northwestern University
Garry Sagert of the University of Victoria
Jameson Watkins of the University of Kansas Medical Center
Thomas Lenggenhager of the Swiss Education & Research Network (SWITCH)
Richard L. Goerwitz III of Carleton College
Sean Singh of the University of Rochester
Charlie Reitsma of Denison University
Paul Hill of the Massachusetts Institute of Technology (MIT)
Todd Piket of the Michigan Technological University
Brendan Bellina of the University of Notre Dame du Lac
Art Vandenberg of Georgia State University
Charles Hedrick of Rutgers University
Michael A. Grady of the University of Illinois at Urbana-Champaign
Melinda Jones of the University of Colorado at Boulder
Wes Craig of the University of Michigan – Ann Arbor
David Bantz of the University of Alaska
The author gratefully acknowledges the support of Internet2 and the National Science Foundation through the NSF Middleware Initiative (NMI) program.
Internet2 MACE Authentication website <http://middleware.internet2.edu/core/authentication.html>
Internet2 MACE Authorization website <http://middleware.internet2.edu/core/authorization.html>
Brendan Bellina
University of Notre Dame
Email: bbellina@nd.edu