skip to main content

Authentication & Authorization Services

Central Authentication Service (CAS)

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.