The Central Authentication Service (CAS) provides the ability to log in to many password-protected web systems using a NetID and password. It simplifies access so users do not need to keep track of multiple IDs and passwords.

Getting Started

If a campus system uses CAS, a user is prompted to log in with a NetID and password.

Help and Support

See the Infrastructure Services website for information about setting up CAS on a campus website.


The Central Authentication Service (CAS) is provided at no charge to Texas A&M University, the A&M System and TAMUS Auxiliaries.


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 only allowed for development sites since the ticket exchange between CAS and the application will be transmitted unencrypted. Campus websites are encouraged to set up the application's http address to redirect to the https address and register the https addressed with CAS.
    • Https certificates can be requested at https://cert.tamu.edu.
  • Application URL
  • Application Type: production and 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 minimum trust level required is set to Two-Factor, or
    • 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 the Service Provider on behalf of College/Division/Department of Texas A&M University.

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

Texas A&M's CAS deployment returns the standard payload so CAS client code from the Apereo website can be used. CAS client code samples are available.

Service Details

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.

Technical requirements and information about the Texas A&M CAS implementation are available on the Infrastructure Services website. A description of the CAS service and an illustration of a basic authentication scenario are also available.


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.

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.

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 campus members' 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 see http://google.tamu.edu/ and http://gateway.tamu.edu/.

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 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.

Was this page helpful?