Documentation - Brief Guide to CNet Authentication
Overview
Word has gotten around that to do the right thing and use CNetIDs and CNet passwords, applications should use LDAP. While not wrong, this isn't the whole story. LDAP is one way to use CNet authentication, but there are others, just as right and often a better fit to circumstances. This guide presents all of the CNet authentication methods, highlights some of their distinct properties, and tells you where to get on-boarding support.
All CNet authentication services, with the exception of UC Active Directory, also honor UCH Active Directory credentials. In case a person has both a CNetID and a UCHAD account, only the CNetID may be used with CNet authentication services.
CNet Authentication Services
The following table introduces the various CNet authentication services and some of their properties.
| Authentication Service | Platform Support | Application Support | SSO | Attributes | Off-campus |
| LDAP | Apache, most application servers, most operating systems | Often available as an alternative to internal authentication | No | Yes, enterprise attributes | Yes, in some cases |
| Active Directory (UCAD) | IIS, .NET | Windows integrated services | Yes, within UCAD | Yes, but application specific | No |
| Shibboleth | Apache, IIS, application servers such as Tomcat, some grid technologies, commercial security suites such as RSA Federated Identity Manager | Web applications that rely on their application server or web server to provide authentication service | Yes, across web applications | Yes, enterprise attributes |
Yes |
|
(deprecated) |
Apache, IIS | Applications that rely on their containers to provide authentication | Yes, across web applications |
No | No |
| RADIUS |
Network Access Devices |
None |
No | No |
No |
The "Application support" column gives a hint about which types of applications can use the authentication service. Of course, one must always double-check in each particular case.
"SSO" stands for Single Sign-On, which means that once a user has authenticated, they are not challenged to do so again as they access other applications in a common SSO domain. Those that are not SSO expose plaintext CNet passwords to applications, raising concern about the operating practices surrounding the application. All else being equal, you should choose an SSO authentication service.
The "Attributes" column indicates if attributes about the user are available to the application in addition to a simple thumbs up or down for authentication.
The "Off-campus" column indicates whether the authentication service is available for use with applications hosted outside of the campus network.
Note: Web applications that rely on their web or application servers to provide them with authentication service are preferred over forms-based authentication provided within the application for two important reasons. First, they can be integrated with an SSO authentication service, making it easier for users and more secure since plain text passwords are not exposed. Second, decoupling authentication from the application allows NSIT to update its authentication services without impact to the application.
If you're unsure of how or how well your application might integrate with any of these authentication services, please contact the corresponding support organization given below.
LDAP
Essential Data
Host: ldap.uchicago.eduPort: 389 if using StartTLS, 636 with SSL
Base DN: dc=uchicago,dc=edu
Scope: subtree
Filter: (&(uid=<username>)(objectclass=inetOrgPerson))
Template: uid=<username>,ou=people,dc=uchicago,dc=edu
Overview
LDAP is a well-established technology that is used for authentication, on-line directory, and as a provider of user attributes to fuel authorization decisions or support integration needs. Many user attributes are available from LDAP. Some commonly used by applications include
* eduPersonAffiliation: lists the user's primary affiliations with the University such as staff, faculty, student, alum, hospital, and several others
* ChicagoID: used instead of the SSN to identify people in various University databases
* cn: common name
See this page for a complete list with definitions.
Many canned applications are billed as "LDAP enabled". This may mean many things and often does but need not imply that the application can authenticate using NSIT's LDAP service - caveat emptor.
The LDAP host identified above is a load-balanced target to provide high availability for typical LDAP-reliant applications.
On-boarding and support
Network Based Services provides LDAP support.
Some LDAP-enabled applications need to be issued a "service account" or "BINDDN", i.e., have their own username and password in the LDAP directory, just as users have CNetIDs. This is a custom support option.
The operator of an LDAP-enabled application may need to have their operating and security practices vetted since they'll be handling CNet passwords. NSIT may require corresponding contractual language with ASPs.
Note: Applications perform user authentication with LDAP by asking the user to enter their username and password. They use the supplied values to authenticate to the LDAP directory as the user. The way LDAP works, though, the application must first determine the location of the user's "LDAP entry". Some applications do so by first searching LDAP to find the entry matching the supplied username. Others rely on a template configuration that reflects where our operational practices put users' entries in our LDAP directory. Applications that search first can also make use of test accounts in LDAP. Since test accounts are located in a special area within the LDAP directory, applications that rely on a template approach cannot access them.
LDAP authentication moves plaintext passwords over the network. Hence, our LDAP servers are configured to refuse authentication attempts unless the connection is encrypted using either TLS or SSL. Note that an application that is not so configured will still send a plaintext password over the network, even though the authentication attempt will necessarily fail.
University of Chicago Active Directory (UCAD)
Overview
UC Active Directory securely provides Single Sign-On authentication to Windows-integrated services that are part of the UCAD Forest, including login to workstations that are "joined" to UCAD.
On-boarding and support
NSIT's Distributed Desktop Support and distributed IT support groups usually handle on-boarding needs for user desktops and for Windows servers and integrated applications. NSIT's SEA-WSS group may need to provide special support for integrating some applications within UCAD.
Note: UCH Active Directory accounts are not usable within UCAD at this time.
Shibboleth
Essential data
U Chicago IdP's entityId: urn:mace:incommon:uchicago.edu
IdP metadata location: http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
Overview
Shibboleth, being an implementation of the only standards-based web single sign-on protocol, is the most common means for providing CNet authentication to external services. It is also the best option for providing an SSO experience across campus-based web applications.
All LDAP user attributes can be delivered by shibboleth.
If an external service belongs to the InCommon Federation, shibboleth authentication is already available to it. Otherwise, the process of connecting to the shibboleth authentication service involves the exchange of certain metadata between the "Service Provider", i.e., the thing that protects the application, and the "Identity Provider", i.e., the thing that logs users in, so that they can recognize and authenticate each other.
Two non-identifying user attributes are provided to all external service providers by default, and a larger set of user attributes are provided by default to many campus-based applications. Some shibbolized applications also need specified attributes about the logged in user, such as their name, email address, or service-specific entitlements. Release of any attributes beyond those provided by default requires a special agreement or contract between UC and the application operator.
On-boarding and support
Network Based Services provides shibboleth support.
Note: The attributes released by default to external services are eduPersonTargetedID and eduPersonScopedAffiliation. The first is a "pseudonymous" identifier, meaning that it enables the application to offer personalized user services without requiring U Chicago to provide personally identifying information about the user. This is accomplished by cryptographic techniques that prevent the user's identity from being discovered, even by applications that collude to correlate user experience information. The second lists the user's eduPersonAffiliation values, along with a standards-based way of saying "these affiliations pertain to uchicago.edu".
Attributes released by default to many on-campus applications are name, eduPersonAffiliation, CNetID or UCHADid, ChicagoID, ucDepartment, ucCurriculum, ucPriv, and ucIsMemberOf.
Pubcookie
Use of this technology has been deprecated. Shibboleth should be used instead.
RADIUS
Overview
RADIUS is a technology used exclusively by network devices such as wireless access points.
On-boarding and support
If you think you need RADIUS, you really need to speak with NSIT's Network Based Services first!
Note: Don't use RADIUS unless you have a specific agreement with Network Based Services.
Last updated: 7/30/09