Texas A&M University - Infrastructure Services

Frequently Asked Questions

  1. What is CAS?
  2. How does CAS work?
  3. What is returned from CAS?
  4. How long is a CAS session valid?
  5. I authenticated using Firefox, but when I also run Internet Explorer, why does it ask to be authenticated again?
  6. Can I redirect the logout to go to my Web page and not the CAS logout page when a user logs out?
  7. What cookies are stored in the browser?
  8. I am developing a program for students and faculty and want to use this service to authenticate users. How do I do this?
  9. I need to let a vendor, parent, or visiting faculty member have temporary access to some data that I am protecting. How do I get a NetID assigned to them so that they can authenticate and see the information that I want them to see?
  10. Is there a server I can use for testing?
  11. Where can I find more information on CAS?

Q: What is CAS?
A: Please read the CAS Overview.


Q: How does CAS work?
A: CAS authentication takes place in three phases.

When a user tries to access an application, the application determines if the user needs to authenticate, i.e. does the user have an active session? If the user needs to authenticate, the application redirects the user to the CAS server login URL (see Technical Information page for TAMU CAS login URL), passing the application URL or service as a service parameter.

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

When the CAS server receives the request, CAS determines whether or not the user is already logged into CAS. It does this by querying to see if the user has a ticket-granting cookie, or TGC, that CAS recognizes. If the user does not have a TGC or CAS does not recognize the TGC, the user is prompted to log in.

Once the user is logged into CAS, CAS redirects the user back to the application. A unique one-time-only random ticket (String) is added as a request parameter.

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

When the application receives the redirect with the service ticket, it knows the user has successfully authenticated with CAS but doesn't know who the user is. To obtain that information, the application must call the validation service at the CAS server validation URL, passing the Web service and ticket returned from the login process.

The service ticket issued by CAS is short-lived, valid only for 5 minutes. When the CAS validation service receives the request, it checks to see if 1) the calling service is the service to which the ticket was issued; 2) the ticket is valid; and 3) the ticket has not expired. If all three are true, CAS will return the calling service a payload with information about the user. For details about the payload returned by CAS, please visit the Technical Information page.

The third phase of CAS authentication is really a recommendation. CIS suggests that each Web service create a session to authenticate with other services on the same application/Web server. If a valid session exists on the Web or application server, the CAS server does not need to be called for authentication.


Q: What is returned from CAS?
A: The CAS Payload section of the Technical Information page provides details on the information returned (and its format).


Q: How long is a CAS session valid?
A: Once a person logs in, their CAS session is valid until they close all instances of their browser or request a logout.


Q: I authenticated using Firefox, but when I also run Internet Explorer, why does it ask to be authenticated again?
A: Authentication is valid for a single browser. If you use two browsers or browsers on different machines, you need to authenticate again inside each browser.


Q: Can I redirect the logout to go to my Web page and not the CAS logout page when a user logs out?
A: Yes. To log a user out of CAS, your application should make a call to the CAS server logout URL.

https://cas_server/cas/logout

If you add the additional parameter

https://cas_server/cas/logout?service=http://your_server/yourWebPage

the CAS server redirects the user to the Web page that you specify after logout.


Q: What cookies are stored in the browser?
A: Two cookies are stored in the user's browser by the CAS service. The first is a session cookie stored by the application server. This cookie is used for load balancing and session preservation across servers. The cookie is named JSESSIONID and has an encrypted value that ties it to the host and /cas authentication service on that host. The second cookie is placed there by the CAS server and has the name CASTGC. The value stored in this cookie is the host of the CAS server, a link to the /cas authentication service on that host, and an index to the session pointer on the server. Both of these values are destroyed when the browser exits, the session expires, the CAS server is restarted, or the /cas/logout service is called from the browser or Web service with which the browser interacts.


Q: I am developing a program for students and faculty and want to use this service to authenticate users. How do I do this?
A: If you are using CAS 2, you will need to download the client interface libraries customized for TAMU and integrate them into your Web pages. Sample code modified to work in the TAMU environment is available for several programming languages.

If you are using CAS 3, you will need to download the appropriate CAS 3 client from the JA-SIG Web site. For convenience, we are providing some CAS 3 clients.

New development continues for CAS clients and the central distribution site at JA-SIG.org will have the most up-to-date list of client ports. If you need more help, contact the CIS staff and request programming assistance. In many instances, the changes are relatively trivial and do not require much knowledge or detailed understanding of the CAS environment.


Q: I need to let a vendor, parent, or visiting faculty member have temporary access to some data that I am protecting. How do I get a NetID assigned to them so that they can authenticate and see the information that I want them to see?
A: This is a difficult question that is not answered by the CAS software. CIS is currently evaluating modifications to the Neo/LDAP/Kerberos implementation to allow for this temporary authentication. The CAS software is dependant on the data from the LDAP and Kerberos servers so getting the user information into these repositories is the only requirement. No changes are needed in the CAS software, just the data that it reads.


Q: Is there a server I can use for testing?
A: Yes. Details on the CAS development servers is provided on the Technical Information page. The development servers provides the same services as the production systems and uses the same call interface.

The development CAS server still uses the production LDAP servers for now. CIS is researching adding a test LDAP service that will allow creating different NetIDs with varying attributes. However, for now, the CAS development servers calls the TAMU Enterprise LDAP for authentication.

Please note CAS utilizes SSL for communications from and to an application. For the production servers, a certificate purchased from Thawte is used. However, for test and development purposes, Infrastructure Systems & Services locally signed certificates are used. The Infrastructure Systems Signing Authority Certificate can be found at http://www.tamu.edu/OpenSys-CA.crt. To request your own Infrastructure Systems signed certificate, please email unix-admin@tamu.edu. For some environments, by adding the Infrastructure Systems CA certificate to the list of trusted hosts or to the certificate ring, the popup to verify the certificate can be avoided.


Q: Where can I find more information on CAS?
A: The central repository for CAS development is on JA-SIG.org. This site is maintained by the developers and covers topics from architecture to implementation. The CAS 2 architecture document builds upon the CAS 1 document, so be sure to read both documents for the full view of the CAS architecture. The protocol document covers both versions.