Central Authentication Service

About CAS

Central Authentication Service (CAS) is a single sign-on protocol designed to allow potentially untrusted web applications to authenticate users against a trusted central server. Applications that authenticate with CAS never see the users credentials, since the authentication happens only on the CAS server. According to University policy, web applications or pages which require access by members of the campus community are required to use CAS.

OIT runs a CAS server and you can find more information about it and CAS in general (including getting started) in the OIT Knowledge Base article KB0012958.

The Computer Science Department also runs a CAS server that authenticates users that have an account with the department. The URL for this server is https://signon.cs.princeton.edu/.

CS Department CAS is provided by DjangoMamaCAS Server. They maintain a helpful programming guide for software developers (we also have some sample code below).

How it works

In summary:

  1. Your app redirects a user to the CAS server login when they need to be authenticated.
  2. After the user logs in (or if they are already logged in), the CAS server returns the user to your application with a "service ticket" appended to the URL.
  3. Your application sends a request to the CAS server to validate the service ticket.
  4. If the service ticket is valid, the CAS server will respond with the Net ID of the user that generated that token if the token is valid. At this point your application can consider the user with that Net ID as authenticated, and typically set a cookie or session data indicating that they have been authenticated (to prevent further redirects to the CAS server for re-authentication).

Using CAS authentication for your website

If you are developing an website that requires authentication, you should use either the CS CAS server or the OIT CAS server. Generally speaking, if you know all of your app users have a CS account, then use the CS CAS server. All faculty and CS graduate students have CS accounts, but not all CS undergraduate students do.

If you need users to log in that may not have a CS account, like a TA from another department or undergrads (many do not have CS accounts), you should use the OIT CAS server.

When integrating your app with CAS, it doesn't matter which server is used, since they both implement the same protocol. All you have to do is swap the URLs used for each of the two servers.

There are many client libraries available for authenticating with CAS. For PHP, we recommend using the phpCAS library. We have sample PHP code available for download to help you get started with adding CAS authentication to your PHP web pages. For Python, including Django and Flask, we recommend the python-cas library.   If you're using any other languages try searching for an existing library to works with CAS.

If you're just looking to enforce authentication for a particular directory on your web page and don't want to deal with a whole client library, you can also use an Apache extension mod_cas_auth that's available on our web servers. To use it, simply create the following .htaccess file in the directory you want to protect:

AuthType CAS
AuthName "Authorized users only"
Require valid-user

This will force all users to authentication with the CS CAS server before granting access (we don't support authenticating with OIT CAS with this approach). Anyone with a CS account could get access.

You could also limit access to a specific set of users:

AuthType CAS
AuthName "Authorized users only"
Require user test1 test2 test3

More .htaccess configuration options can be found on the documentation. 

Authentication vs Authorization

CAS will authenticate users, but not necessarily authorize them, since authorization is specific to each application. When a user logs into your app via CAS, your app will receive that user's Net ID so your app can identify who logged in. You can then use this Net ID to verify if the user is authorized to perform some action within your app.

For example, your app may have a role system, with roles like "admin" and "editor". Your app should maintain a list of Net IDs that belong to each role, and then perform the business logic to make sure they are authorized for that role.

You can also leverage LDAP attribute for some basic authorization checking. You can query our LDAP server to determine what LDAP group an authenticated user belongs to, and only allow users of a specific group like "fac" or "grad". The sample code linked above shows you how to do this in PHP.

Tags: