Identity Management

From Web Developer Network Wiki
Jump to: navigation, search



The University of Nebraska-Lincoln has deployed an LDAP Directory containing information about UNL faculty, staff and students.

Requesting Access

To request access, complete the following PDF and submit it to the Identity Management Team.


LDAP Introduction

The following terms describe the structure of the directory, as defined in Wikipedia []:

  • A directory is a tree of directory entries
  • An entry consists of a set of attributes
  • An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema. (Each entry may have a different schema.)
  • Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN.


Roles and groups are defined in Practices in Directory Groups


Do we, and if so, how do we distinguish future hires? Attribute or group? Do we distinguish enrolled from eligible to enroll? Attribute or group? Need to consider eduPersonScopedAffiliation. e.g. Please note that users may have multiple roles (eg. a faculty member who is also a student).


Persons in SAP, holding an active faculty appointment (at UNL)2


Persons in SAP, holding an active staff appointment


Persons in SIS, indicated as eligible to enroll


Persons in SAP, holding an active affiliate appointment


Guest role and mechanism are still under development.

Phase 1 of implementing guest access will focus on the development of a "Sponsored Guest" role. Testing for the Guest role and mechanism will take place during the Spring Term of the 2008/09 Academic Year. As currently defined, creation of a Sponsored Guest will be initiated by the sponsoring UNL faculty or staff member. Guest username will be the guest's email address (after the address is confirmed by the guest).

  • Sponsored Guests will be available in Identity Management for a period of 6 months, and are allowed one renewal (by a sponsor) for another 6 month period. If a guest user continues to need access beyond two 6-month periods, it constitutes a long-term relationship with UNL, and they need to be entered as an SAP Affiliate or another more appropriate role
  • An automatically-generated email will be sent to the sponsor one month prior to the expiration of the Sponsored Guest account


We're exploring tools for delegating group management. Grouper is an example.

Directory layout


Entries in the directory are organized into organizational units (OUs). The directory is mostly flat, with accounts grouped in OUs by broad type:

Organizational unit (OU) Status Description
people available UNL faculty, staff, students, and affiliates
service internal use Service accounts
groups pending discussion
orgs pending discussion
guests pending discussion


The following is an overview of the attributes available for entries in the people OU. Table lists the attributes common to all people. Table and table list attributes for entries from the HR and SIS systems. Currently, persons with multiple roles will have multiple entries. For example, Joe Smith is a faculty member, as well as a student. He would have two accounts, possibly jsmith2 with a faculty role and s-jsmith1 with a student role.

Table 1: People, common attributes

Attribute Status Example
cn available "Joe Smith", "Joe B Smith"
displayName available Joe B Smith
eduPersonAffiliation available staff
eduPersonPrimaryAffiliation available staff
givenName available Joe
initials available j
mail available
mailAlternateAddress future
mailRoutingAddress future
sn available Smith
uid available jsmith2
unlAuthority available "SIS" or "Human Resources"
unlBirthdate available 19700831
unlEmailAlias available jsmith2
unlEmailNickname available joesmith
unlGender available "M" or "F"
unlIDCardISO available 1234123412341234
unlPrimaryAffiliation available "faculty", "staff", "student", or "affiliate"
unlUNCWID available 12345678
  • In the future, we will be putting the published email address into the "mail" attribute (currently called alias). The actual delivery address will be stored in "mailRoutingAddress". Alternate addresses (currently called nicknames) for the person will be stored in mailAlternateAddress.

Table 2: People, HR attributes

Attribute Status Example
postalAddress available 29 SEC UNL 68588-0657
street available 29 SEC UNL 68588-0657
telephoneNumber available (402)472-1234
title available Web Developer
unlHRAddress available 29 SEC UNL 68588-0657
unlHREmployeeID available 00012345
unlHRPrimaryDepartment available Information Services
  • With improved HR data, we will be changing the format of "postalAddress" and "street". Attributes to consider include "localityName", "stateOrProvinceName", and "postalCode"

Table 3: People, SIS attributes

Attribute Status Example
unlSISClassLevel "FR", "SO", "JR", "SR", "2ND", "GR", "P1" to "P6", "UNC"
unlSISCollege "ANR", "ARH", "ASC", etc. (19 three-character codes)
unlSISDegree "BS", "MS", "JD", etc. (over 80 four-character codes)
unlSISFeeLevel future
unlSISLocalAddr1 123 Nowhere Drive
unlSISLocalAddr2 Apt 1
unlSISLocalCity Lincoln
unlSISLocalState NE
unlSISLocalZip 68123-4567
unlSISLocalPhone 402-123-4567
unlSISMajor CHME
unlSISPermAddr1 123 Nowhere Drive
unlSISPermAddr2 Apt 1
unlSISPermCity Lincoln
unlSISPermState NE
unlSISPermZip 68123-4567
unlSISPermPhone 402-123-4567
unlSISStudentID 000123456
unlSISStudentStatus "eligible", "futureEligible", "registered", "graduated", "pastRegistered", "futureRegistered"
  • Should the local and permanent addresses be a single field with a newline between lines? They are not separate data elements.

Security and confidentiality


Applications directly authenticating users against the directory MUST NOT save credentials. Passwords MUST NOT also be saved in a temporary store, such as cookies or sessions. Passwords MUST exist only in memory while the web request is being processed.4

Non-directory information

Applications using non-directory information MUST NOT disclose it to unauthorized parties. This applies to non-directory attributes, as well as any information on individuals who have requested privacy.

Saving directory data

It is strongly RECOMMENDED that only directory information be saved to local servers, along with minimal identifying key information like "NUID." This practice is intended to give software providers data that is as up-to-date as possible, as well as to minimize the number of points at which sensitive data may be compromised.

It is understood that other information may be required based on the needs of the software you are using. Please respect the intent of keeping protected data stored in the source (IdM) system whenever possible. Feel free to contact the Identity Management team concerning special needs, questions, or concerns.


Server information

Role Hostname Primary Backup Need to add DNS entry for backup server

Secure sockets layer (SSL)

Need a certificate. Get from ipsCA?

Persistent connections

Applications using persistent connections MUST set the initial size to one or fewer. The idle timeout MUST be 60 seconds or less. That is, applications may maintain one persistent connection to the directory server, and temporarily create as many additional connections as required. Additional connections that are no longer in use must be closed in 60 seconds. This is to limit the number of unused connections to the directory server. If your application has different requirements, exceptions will be made.

Authenticating users

Single sign-on (CAS)

JA-SIG Central Authentication Service (CAS) is a web single sign-on tool. Visit for more info on using CAS to authenticate UNL persons accessing your website.


UNL supports Shibboleth federated authentication. To try it out, visit and use provider ID

The user is redirected to UNL's Central Authentication Service (CAS) to enter their MyUNL username and password.


OpenID is a decentralized web single sign-on system.

UNL as an IdP (identity provider)

UNL may choose to act as an IdP for OpenID. This would allow UNL community members to authenticate to OpenID protected services. A UNL IdP implementation is not currently on a timeline.

Best practices

Terms of Service (TOS)

The following resources are well-established at UNL and are RECOMMENDED for establishing Terms of Service for access to your web-based resources:

Personal tools