CUIT's Identity Management architecture is based on a combination of internally developed programs, opensource products, and commercial products. Where possible, we adhere to open standards to facilitate the adoption of our services.

Identity Management at Columbia revolves around the University Network ID (UNI), a unique identifier assigned to each individual in any way associated with the University. The UNI serves as the primary public electronic identifier on campus (even when other identifiers are used internally), and is used for email, printing, computer labs, CLIO (library catalog), PeopleSoft self service, VPN and dialup access, and numerous smaller web-based applications.

Enrollment occurs when an individual first becomes part of the Columbia community, usually when they first arrive on campus, but sometimes earlier. Individuals activate their electronic identity (UNI) by providing personal information.

• UNIs have the following characteristics:
  • The form [a-z]+[0-9]+, where the letter components are generally the initials of the individual and the numeric components are sequentially assigned collision numbers.
  • Never reassigned to another individual.
  • May change for an individual under very limited circumstances, such as name change.
• Enrollment takes place in real time via WebCreate. The information required varies according to the individual's source feed, but may include one or more of date of birth, SSN, and PIN sent via mail.

In the process of activating a UNI, the individual selects a password to attach to it. This combination of UNI+password may then be used by various applications to authenticate an individual (ie: to confirm the individual is who her or she claims to be).

• Passwords are stored in an MIT Kerberos V Key Distribution Center, consisting of a master server that replicates nightly to a secondary server, both of which run on Solaris 9.
• Passwords must meet minimum strength requirements, which preclude the use of dictionary words and other easy to guess characteristics.
• There is no centrally mandated maximum password age, however authorized applications have access to this data and may choose to reject authentication according to their own policies.
• Password changes are executed in real time on the master server.

CUIT accepts demographic data from various sources around the University, including the major student (SIS) and personnel (PAC) systems, various University affiliates (Barnard, Teachers College, etc), and numerous local departments. This information is correlated to generate the UNI for the individual as well as to generate a single entry in the enterprise directory.

This entry contains information such as the individual's name, address, department, and telephone number. In addition, the entry also contains information regarding aspects of the individual related to the source feed, known as affiliations. Affiliations are not publicly visible, and may be used for authorization purposes.

Currently, a complicated hierarchy establishes the "best" source for an individual who comes from multiple feeds, and this best source is reflected as the individual's primary role in the directory. However, by late 2006 it is expected that the directory will no longer require a primary role and will simply display all available roles for an individual. All affiliations for the individual are maintained with their entry, regardless of the number of source feeds.

Not all individuals associated with the University may be publicly visible via the directory. Notably, students who request privacy via FERPA as well as alumni with no other connection to the University are only visible to authorized applications. Furthermore, some publicly visible individuals may request the suppression of individual fields within their entry.

• The directory is implemented using OpenLDAP v1, which only supports LDAP v2. These servers run on Solaris 9. An upgrade is planned to OpenLDAP v2 (which supports LDAP v3) running on Linux.
• The directory is rebuilt nightly.
• Data from the major systems and affiliates is provided via batch file transfers and is processed nightly. Data from the various departments is provided via the web interface waffil and is processed two or three nights per week.
• Data processing is performed against an Oracle database and a legacy Ingres database using a number of locally developed programs and scripts.

The primary source of central authorization information is the demographic feed data described above. An individual may receive different affiliations according to her or his source feed or feeds, including the attributes set for the individual within the feed by the feed administrator. When the individual is no longer a member of the feed, he or she loses the affiliations granted by that feed. This may then result in, for example, loss of access to restricted web sites or loss of email service.

A secondary source of central authorization information is group membership on the central unix servers (aka cunix groups). Users may create and manage their own cunix groups, with memberships subsequently reflected in the enterprise directory as affiliations. Expansion and generalization of this service is planned.

• Central authorization information is recorded as a multivalued attribute affiliation attached to the individual's directory entry.
• Authorization information is not publicly visible, and is only made available to approved applications.
• Authorization information can only be obtained via WIND (as described below) or by binding to the directory with a Kerberos IV ticket for the user. The latter method is deprecated and will be replaced when the directory servers are upgraded by late 2006.

The Columbia University WebISO (WIND) allows web-based applications to authenticate anyone with a UNI without the password being passed through the application. According to the needs of the application, an encrypted identifier may be returned instead of the UNI.

For approved applications, authorization information may also be returned in the response.

• More information about WIND is available here.
• For non-CUIT maintained servers, Apache modules that interface with WIND have been written by CCIT and CCNMTL.
• WIND runs in the Tomcat Java application environment on Solaris 9 servers.

Web pages served from the central secure web server (www1.columbia.edu) and other CUIT maintained servers may take advantage of UNI authentication and affiliation information for authorization purposes using the standard Apache access control mechanism (eg: via .htaccess).

• The locally developed, OpenSource Apache module mod_auth_pamacea, used in conjunction with the central Unix server PAM infrastructure.

Provisioning and deprovisioning of accounts on the primary email (Cyrus) and unix (Cunix) systems happens automatically based on the demographic feed data and affiliations described above.

This service is currently available only for servers maintained by the CUIT Unix & Email Systems group.

• Account information is written in real time to a separate directory server pool, running OpenLDAP v2 on Solaris 9.
• Solaris 9 and earlier servers use locally written PAM (pam_krb54) and nameservice switch (nss_ahpl) modules.
• Linux servers use the standard pam_krb5, pam_access, and nss_ldap modules.

CUIT is participating in several early adoption pilots of federated identity, allowing members of the Columbia University to access services maintained by other universities and organizations using their Columbia UNI.

• Shibboleth.

• CUIT Identity Management data flow graph.
• CUIT Identity Management servers graph.