Topics Map > University of Chicago > IT Services > Accounts, Identity, & Security
Overview to CNet Authentication Services
This article provides a technical overview to the CNet authentication service.
To use CNetIDs and CNet passwords to sign into external applications, vendors must use Shibboleth to authenticate the ID and password. If you are hosting an application on-campus you may also be able to use LDAP. The guide below presents all of the CNet authentication methods, highlights some of their distinct properties, and directs you where to get on-boarding support.
All CNet authentication services, with the exception of UChicago Active Directory, also honor UChicago 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||No|
|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, best option for vendor applications especially ASPs|
|RADIUS||Network Access Devices||None||No||No||No|
The "Platform support" column lists popular platform technologies that can provide authentication services to the applications they host.
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 unless that application has specifically set it up to do so. 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 IT Services 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 your local support organization.