skip to main content

Authentication & Authorization Services

Central Authentication Service (CAS)

Authentication using CAS

When a Subject attempts to access an on-line service, the Service Provider often needs to determine whether or not to allow the Subject to use the resource. The first step in making this decision is verifying or authenticating the Subject's identity, i.e. "Are you who you claim to be?". This verification is accomplished via an authentication event where:

  • The Subject presents a Credential, which consists of the Subject's unique identifier and associated authentication material such as a password, PIN, or certificate key.
  • The Verifier validates the correctness of the Credential.

Origins and Philosophy

Due to the proliferation of web-enabled Service Providers, Yale University developed the Central Authentication Service (CAS) to provide a centralized Single SignOn Verifier for campus Service Providers. The centralized service offered a number of advantages to both Service Providers and Subjects. Service Providers did not have to manage user accounts or maintain Credential Stores and could focus on maintenance and development of their core services while Subjects had fewer Credentials to manage. CAS has been adopted and implemented by a number of universities and is now an Apereo Foundation project.

A CAS server provides the following service URIs:

List of CAS URIs and their description
URI Description
/cas/ Redirects to /cas/login
/cas/login Login service
/cas/logout Logout service
/cas/validate CAS 1.0 service ticket validation URI
/cas/serviceValidate CAS 2.0 service ticket validation URI
/cas/proxyValidate CAS 2.0 service ticket and proxy ticket validation URI
/cas/proxy CAS 2.0 proxy ticket service
/cas/p3/serviceValidate CAS 3.0 service ticket validation URI
/cas/p3/proxyValidate CAS 3.0 service ticket and proxy ticket validation URI
/cas/samlValidate SAML service ticket validation URI (Jasig CAS feature, not in CAS protocol)

Basic Authentication Scenario

The illustration below outlines the basic steps in a successful CAS authentication event. For a comprehensive description of CAS features, please review the Central Authentication Service protocol documentation.

Diagram of steps in CAS authentication event

Preliminary Step: Service Provider CAS-enables their site

To rely on the CAS service for authentication, the Service Provider:

  • Registers the site with the CAS service.
  • Adds a CAS client to the core service code. CAS clients are available in many programming languages to allow the Service Provider to select one written in the same programming language used by their service.
  • Configure the CAS client, specifying the portion of the site to be CAS-protected, and any parameter values to be included in the redirect to the CAS service. Possible redirect parameter customizations are reviewed in the next section.

Step 1: Subject attempts to access a CAS-protected Service Provider site

When a Subject navigates to a CAS-protected Service Provider site, the Service Provider's CAS client redirects the Subject's browser to the CAS service /cas/login URI. The identifier for the Service Provider is included as a parameter so that CAS knows which Service Provider is requesting authentication.

http(s)://cas_server/cas/login?service=http(s)://your_server/yourApplication

Step 2: Subject logs in to CAS

The first time a Subject is redirected to /cas/login, CAS will respond by displaying a login screen, requesting the Subject's Credentials. When the Subject enters his Credential, the login form submits the Credential to /cas/login using the HTTP POST method.

Step 3: CAS validates the Credential

CAS submits the Credential to the Credential Store for verification. If the Credential is valid, CAS retrieves a set of attributes about the Subject to be included in the response to the Service Provider site. CAS uses the attributes to create a Ticket Granting Ticket which it stores in a cookie on the Subject's browser.

What is a cookie?

A cookie is a small text file that is stored by a browser on the Subject's machine. Cookies are plain text; they contain no executable code.

A cookie is created when a web server sends an HTTP response containing a Set-Cookie header to the browser. Anytime the browser accesses a page on the web server after the cookie is created, the cookie value will be included in the request.

A Set-Cookie header at a minimum contains the cookie value. The value can be assigned a name using the cookieName=cookieValue syntax. In addition to the value, a Set-Cookie header may contain:

  • An expiration timestamp for the cookie. Without an expires option, the cookie has a lifespan of a single session.
  • The domain to which the cookie should be sent. The default value for the domain option is the host name of the web site setting the cookie; a domain value specified in the Set-Cookie header must be part of the default value or it is ignored.
  • A path on the web server can be specified to further control when the cookie is sent. The default value for the path option is the path of the URL that sent the Set-Cookie header.
  • A secure flag indicating that the cookie is sent only when a request is made using SSL and the HTTPS protocol.

The Ticket Granting cookie created by CAS stores the Ticket Granting Ticket value. The domain is allowed to default to the web server hosting the CAS service, but the path is set to '/cas' rather than being allowed to default to '/cas/login' so that the Ticket Granting Ticket value will be sent to any of the CAS URIs. The secure flag is set to ensure the Ticket Granting Ticket value is sent only via an encrypted connection.

The full list of cookies that can be created and stored by the CAS server are:

  • CASTGC - the ticket granting cookie
  • csrftoken - use to protect against CSRF attacks
  • sessionid - the session cookie
  • CASMFA - the 2-factor trusted computer token

Step 4: CAS verifies Service Provider is registered

After the Subject successfully authenticates, CAS compares the value of the service parameter to the list of Service Provider sites in the CAS service registry. If the value matches an entry in the registry, CAS proceeds to the next step. Otherwise, CAS displays an error informing the Subject that the Service Provider site is not eligible to use CAS for authentication.

Step 5: CAS generates Service Ticket/redirects browser back to Service Provider site

For a legitimate service, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.

http(s)://your_server/yourApplication?ticket=ST-9781-123cvUwGGkp980

Step 6: Service Provider validates Service Ticket

The Service Provider's CAS client starts a new connection to /cas/serviceValidate or /cas/p3/serviceValidate including the Service Ticket in the connection string. CAS verifies that the Service Ticket is valid (the Service Ticket value exists in CAS' database, the Service Ticket is less than 2 minutes old, and the Service Provider site validating the ticket is the site that was sent the ticket). If the Service Ticket is valid, CAS responds with the Subject's username and any additional Subject attributes the Service Provider is authorized to receive.

After Initial Authentication Event

If the Subject attempts to access a different CAS-protected Service Provider site, the second site will once again redirect the Subject's browser to /cas/login URL as described in Step 1 above.

When the browser attempts to access the /cas/login site, the Ticket Granting Ticket previously stored in a cookie on the Subject's browser by the CAS service is included in the request. CAS checks the validity of the Ticket Granting Ticket by verifying the ticket value is present in its database and that the Ticket Granting Ticket has been used in the last 6 hours.

If the Ticket Granting Ticket is valid, CAS considers the Subject to be authenticated and skips Steps 2 and 3 as outlined above. If the Ticket Granting Ticket is invalid, CAS completes all the steps listed above.

Service Provider modifications to login process

The Service Provider's CAS client may include one or more of the following parameters:

  • service - The Service Provider identifier, usually the URL of the Service Provider site. CAS will redirect the Subject back to the URL upon completion of a successful authentication event.
    Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu
    If this parameter is not included, CAS displays a message notifying the Subject that they have successfully logged in.
  • renew - Boolean value indicating whether or not the Service Provider wants to bypass Single Sign-On. This value is defaulted to False, so the renew parameter is required only when it should be set to True.
    When set to False, CAS checks for an existing Single SignOn session (managed using the cookie storing the Ticket Granting Ticket) for the Subject. Only when the Subject does not have an active Single SignOn session does CAS require a Credential to be presented.
    When set to True, CAS requests a Credential to be presented regardless of whether or not an active Single Sign-On session exists.
    Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&renew=true
  • gateway - Boolean value indicating whether or not the Service Provider wants CAS to only check for a Single-Sign On session. This value is defaulted to False, so the gateway parameter is required only when it should be set to True.
    When set to False, CAS checks for an existing single sign-on session for the Subject. If the Subject does not have an active Single Sign-On session, CAS will prompt the Subject for a Credential.
    When set to True, CAS checks for an existing Single Sign-On session for the Subject.
    • If a Single Sign-On session exists, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.
    • If a Single Sign-On session does not exist, CAS redirects the Subject's browser back to the Service Provider URL without requesting a Credential to be presented/including a Service Ticket.
    Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&gateway=true
    The gateway parameter is used for landing pages, where the Subject is not required to be authenticated to view content. This parameter allows sites to customize page content depending on whether or not a Single Sign-On session exists.

Technical Requirements and Information

Texas A&M CAS Server

  • production server: cas.tamu.edu
    • login URL:
      https://cas.tamu.edu/cas/login
    • validation URLs:
      https://cas.tamu.edu/cas/validate
      https://cas.tamu.edu/cas/serviceValidate
      https://cas.tamu.edu/cas/p3/serviceValidate
    • logout URL:
      https://cas.tamu.edu/cas/logout
  • development server: cas-dev.tamu.edu
    • login URL:
      https://cas-dev.tamu.edu/cas/login
    • validation URLs:
      https://cas-dev.tamu.edu/cas/validate
      https://cas-dev.tamu.edu/cas/serviceValidate
      https://cas-dev.tamu.edu/cas/p3/serviceValidate
    • logout URL:
      https://cas-dev.tamu.edu/cas/logout

CAS Payload

CAS returns user information in either plain text or XML. To receive the payload in plain text, your application should call the '.../validate' server validation URL. To receive the payload in XML, your application should call the '.../serviceValidate' server validation URL.

Although there are two different '.../serviceValidate' server validation URLs for CAS 2.0 and CAS 3.0, they will return the exact same payload. While CAS had possessed the <cas:attributes> element to return additional elements in the payload in CAS 2.0, it was not formally documented in the CAS protocol until the CAS 3.0 protocol was published.

Applications wishing to enforce two-factor authentication will need to use the XML payload ('.../serviceValidate'). The plain-text payload ('.../validate') will not provide details about the authetication event.

Payload Content

CAS allows the payload to be customized. Texas A&M's CAS deployment takes advantage of this feature to return both the user's UIN and NetID. No other customizations have been made to the payload to ensure that 3rd party CAS-enabled applications will not require modifications to work with Texas A&M's CAS implementation.

Applications wishing to enforce two-factor authentication will need to request that the authenticationMethod attribute be added to the payload. This attribute will return one of two values:

  • Password: the user completed one-factor authentication
  • Token: the user completed two-factor authentication

CAS payload format

XML payload (the ' .../serviceValidate ' response)
Successful validation
CAS returns an XML document containing:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>netid</cas:user>
    <cas:attributes>
      <cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>
      <cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>
    </cas:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>
Failed validation
CAS returns an XML document containing
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code="...">
    Optional authentication failure message
  </cas:authenticationFailure>
</cas:serviceResponse>

Plain Text payload (the ' .../validate ' response)
Successful validation
CAS returns a 2 line response:
yes
netid







Failed validation
CAS returns a 2 line response:
no





CAS payload format when two-factor information is included

XML payload (the ' .../serviceValidate ' response)
Successful validation with single-factor authentication
CAS returns an XML document containing:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>netid</cas:user>
    <cas:attributes>
      <cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>
      <cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>
      <cas:authenticationMethod>Password</cas:authenticationMethod>
    </cas:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>
Successful validation with two-factor authentication
CAS returns an XML document containing:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>netid</cas:user>
    <cas:attributes>
      <cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>
      <cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>
      <cas:authenticationMethod>Token</cas:authenticationMethod>
    </cas:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>
Failed validation
CAS returns an XML document containing
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code="...">
    Optional authentication failure message
  </cas:authenticationFailure>
</cas:serviceResponse>

Plain Text payload (the ' .../validate ' response)
Successful validation
CAS returns a 2 line response:
yes
netid






















Failed validation
CAS returns a 2 line response:
no






Session Life

Once a Subject has authenticated, the session is valid for 6 hours. A Subject can also end a session by closing all instances of the browser or requesting a logout.


Testing

Test your application with CAS by using the development URLs listed above.

Separate requests must be made to register an application in the CAS development service registry and CAS production service registry.
As an alternative to registering an application URL for testing with CAS, developers may use either of the following URLs:

  • https://localhost
  • https://localhost:8443

These two URLs are already in the CAS development service registry.


Registering an Application

CAS utilizes a service registry. Your application must be registered with CAS or CAS will not respond to any requests made by the application.

Registering a tamu.edu website

To register your application, send an email with the following information to helpdesk@tamu.edu:

  • protocol type: https is expected
    • CAS-protecting an http site is discouraged since the ticket exchange between CAS and the application will be transmitted unencrypted. A better method is to set up the application's http address to redirect to the https address and register the https address with CAS.
    • If you require CAS to be enabled for an http site, you must include an explanation of why the site cannot be set up as https.
    • Https certificates can be requested at https://cert.tamu.edu.
  • application URL
  • application type: production or development version of application
  • technical contact name and email address
    The technical contact must be an active faculty or staff employee of Texas A&M.
  • if your application will be requiring two-factor authentication, request that the authenticationMethod attribute be added to the payload

The technical contact will receive an email confirming registration of the application/service.

Registering a non-tamu.edu website

Since CAS returns identity information about the user, more information is needed for any non-tamu.edu website utilizing CAS. Any outside party/site partaking in CAS authentication must also comply with the following:

  • Be performing an institutional service for which the Local Education Agency (LEA) or school would otherwise use employees;
  • Be under the direct control of the LEA or school with respect to the use and maintenance of education records (that is, there must be a signed agreement);
  • Be subject to requirements in §99.33(a) of the FERPA regulations governing the use and re-disclosure of Personally Identifiable Information from education records.

The site also needs to provide language similar to the information on the https://www.tamu.edu/statements/privacy.html site specifically about privacy and security.

The application must also publish a statement, visible before login, that indicates to the NetID account holder that:

  • They have left the Texas A&M network;
  • They are logging into a website hosted by ServiceProvider on behalf of College/Division/DeptName of Texas A&M University.

To enable CAS for a non-tamu.edu website please complete and submit a request form.


InCommon Intermediate Certificate

Texas A&M's CAS utilizes SSL for communications from and to an application. On May 19,2015, CAS (cas.tamu.edu) and Shibboleth (idp.tamu.edu) switched to SHA-2 signed certificates.

For both production and development servers, an InCommon certificate is used. The PEM-encoded InCommon Intermediate Certificate used in CAS can be downloaded below.

The legacy, SHA-1 signed InCommon CA certificate (CN=InCommon Server CA):
Download InCommon intermediate certificate.

The SHA384 signed InCommon CA certificate bundle (CN=InCommon RSA Server CA and CN=USERTrust RSA Certification Authority):
Download the InCommon SHA384 intermediate bundle.
The SHA384 signed InCommon CA certificate only (CN=InCommon RSA Server CA, Serial Number=47:20:d0:fa:85:46:1a:7e:17:a1:64:02:91:84:63:74):
Download the InCommon SHA384 intermediate only.
The USERTrust RSA cross-signed Root CA certificate only (CN=USERTrust RSA Certification Authority, Serial Number=13:ea:28:70:5b:f4:ec:ed:0c:36:63:09:80:61:43:36):
Download the cross-signed USERTrust RSA certificate only.

To request your own InCommon certificate, please visit https://cert.tamu.edu.


Community

tamu-auth@listserv.tamu.edu is a mailing list devoted to Texas A&M's CAS and LDAP services. Developers using those services are encouraged to subscribe.

CAS Client Code

Texas A&M's CAS deployment returns the standard payload so CAS client code from the Apereo Foundation Web site can be used.

CAS Client Code Samples

CAS Client Best Practices

Texas A&M's CAS service allows all university students and system employees log in to a single site, and use that login at any number of CAS-enabled sites on campus. This single-sign-on model presents a number of unique opportunities and challenges to developers, as it is very different from traditional forms of authentication.

When you write an application that is CAS-enabled, it joins a community of hundreds of applications from around the university. Just like any community, it helps if we all follow some basic guidelines to be respectful of our users and other applications. We will be expanding this section based on feedback from both CAS developers and users.

  1. Do not log users out of CAS. This is the most common and contentious topic, as it is counterintuitive. There are a few reasons for not logging a user out of CAS:

    • It inconveniences users. One of the most useful features of CAS is that it allows you to log in once and access multiple resources. You should not assume that a user is done with their CAS session because they have logged out of your application.

    • It implies single-sign-out. CAS is a single-sign-on service. It does not provide single-sign-out, so users are still logged into any other CAS-enabled services that they used during that session. Users should be encouraged to close their browsers completely when they are done using services.

    • In many cases, what you really want is renew=true. If you are calling the logout page to force a user to re-authenticate before accessing a resource, you are not using the service correctly. CAS provides a mechanism for forcing re-authentication. By including renew=true in the query string of the redirect to the login page, CAS will prompt the user to enter their username and password again before returning to your service. This provides "verification" of the login without impacting customers' access to other applications.

  2. Use landing pages that are not CAS-enabled. Landing pages give your users a clear view of the application they are visiting prior to logging into CAS. This allows them to make an informed decision before logging into your site. It also gives you a place to send users after logging them out of your application that can provide additional guidance. For an example of landing pages for login and logout, see https://filex.tamu.edu/ and https://filex.tamu.edu/accounts/logout/.

  3. Tell the user who they are. This is a good practice in general, particularly if you think your application may be used in an environment where multiple people might access the same workstation. Additionally, there is a class of attacks (with a very narrow set of use-cases) that can take advantage of a user not knowing whose account they are logged in with.

Discussion about these topics on the tamu-auth@listserv.tamu.edu mailing list is strongly encouraged. And as you think of other best practices for CAS developers, please share them with the rest of the community for discussion. Practices that gain consensus support will be added to this page.