Central Authentication Service (CAS) - A quick tutorial

The Central Authentication Service (CAS) is a single-sign-on / single-sign-off protocol for the web. It permits a user to access multiple applications while providing their credentials (such as userid and password) only once to a central CAS Server application.

Key Terms :-

Service Ticket (ST)
A service ticket is an opaque string that is used by the client as a credential to obtain access to a service. The service ticket is obtained from CAS upon a client’s presentation of credentials and a service identifier to /login

Service ticket properties

• Service tickets are only valid for the service identifier that was specified to /login when they were generated. The service identifier SHOULD NOT be part of the service ticket.
• Service tickets MUST only be valid for one ticket validation attempt. Whether or not validation was successful, CAS MUST then invalidate the ticket, causing all future validation attempts of that same ticket to fail.
• CAS SHOULD expire unvalidated service tickets in a reasonable period of time after they are issued. If a service presents an expired service ticket for validation, CAS MUST respond with a validation failure response.
• It is RECOMMENDED that the validation response include a descriptive message explaining why validation failed.
• It is RECOMMENDED that the duration a service ticket is valid before it expires be no longer than five minutes. Local security and CAS usage considerations MAY determine the optimal lifespan of unvalidated service tickets.
• Service tickets MUST contain adequate secure random data so that a ticket is not guessable.
• Service tickets MUST begin with the characters, ST-.
• Services MUST be able to accept service tickets of up to 32 characters in length. It is RECOMMENDED that services support service tickets of up to 256 characters in length.

Ticket-granting cookie (TGC)
A ticket-granting cookie is an HTTP cookie[5] set by CAS upon the establishment of a single sign-on session. This cookie maintains login state for the client, and while it is valid, the client can present it to CAS in lieu of primary credentials. Services can opt out of single sign-on through the renew parameter described in Sections 2.1.1, 2.4.1, and 2.5.1.

Cookie is set as CASTGC

ticket-granting cookie properties

• A ticket-granting cookie SHALL be set to expire at the end of the client’s browser session if Long-Term support is not active (4.1.1) for the corresponding TGT.
• CAS SHALL set the cookie path to be as restrictive as possible. For example, if the CAS server is set up under the path /cas, the cookie path SHALL be set to /cas.
• The value of ticket-granting cookies SHALL contain adequate secure random data so that a ticket-granting cookie is not guessable in a reasonable period of time.
• The name of ticket-granting cookies SHOULD begin with the characters TGC-.
• The value of ticket-granting cookies SHOULD follow the same rules as the ticket-granting ticket. Typically, the value of the ticket-granting cookies MAY contain the ticket-granting ticket itself as the representation of the authenticated single sign-on session.
• ticket and ticket-granting cookie character set - In addition to the above requirements, all CAS tickets and the value of the ticket-granting cookie MUST contain only characters from the set {A-Z, a-z, 0-9}, and the hyphen character -.

Ticket-granting ticket (TGT)
A ticket-granting ticket (TGT) is an opaque string that is generated by the CAS server that is issued upon an successful authentication event upon /login. This ticket may be tied to the ticket-granting cookie which represents the state of the single sign-on session, with validity period and acts as the foundation and baseline for issuance of service tickets, proxy-granting tickets, and more.


 ticket-granting ticket properties

• Ticket-granting tickets MAY be used by services to obtain multiple service tickets. Ticket-granting tickets are not one-time-use tickets and are associated with a validity period and expiration policy.
• Ticket-granting tickets MUST expire when the client whose authentication is being managed logs out of CAS.
• Ticket-granting tickets MUST contain adequate secure random data so that a ticket is not guessable in a reasonable period of time through brute-force attacks.
• Ticket-granting tickets SHOULD begin with the characters TGT-.
• It is RECOMMENDED that ticket-granting tickets be encrypted when shared with other external resources in order to minimize security vulnerabilities as they are tied to the ticket-granting cookie and represent the authentication session.

API  Calls

Login :

GET : https://yourcompany.com/cas/login?service=test
this will give back the service ticket
the service is optional, but it would recommended to add a service filter.


https://yourcompany.com/cas/login?ticket=ST-31006626-w4NSorG4OvzPuliQCHTDdEpoS5rC0ExiziO-p004


This will logout
https://yourcompany.com/cas/logout?service=test.com
if the service is provided, the application will be redirected to the url provided after the logout



https://yourcompany.com/cas/v1/tickets
POST /cas/v1/tickets HTTP/1.1
Host: yourcompany.com
Accept: application/json
tenantID: 831D8B107020BBEBE0400F0A32207789
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

username=testuser&password=pass1234

This will give the TGT back.


This will make you login everytime, but looks like not supported in our implementation
https://yourcompany.com/cas/login?renew=true


https://yourcompany.com/cas/serviceValidate
 checks the validity of a service ticket and returns an XML-fragment response. /serviceValidate MUST also generate and issue proxy-granting tickets when requested.

pgtUrl [OPTIONAL] - the URL of the proxy callback.


This will validate and give back the response as below
https://yourcompany.com/cas/serviceValidate?service=test&ticket=ST-31006626-w4NSorG4OvzPuliQCHTDdEpoS5rC0ExiziO-p004



<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>myusername</cas:user> 
<cas:emp_id>9031569335</cas:emp_id>
</cas:authenticationSuccess>
</cas:serviceResponse>

The above response is configurable based on the information available in your IDP.

https://yourcompany.com/cas/validate
checks the validity of a service ticket. /validate is part of the CAS 1.0 protocol and thus does not handle proxy authentication.




References:
https://wiki.jasig.org/display/CAS/Home
https://wiki.jasig.org/display/casum/restful+api
https://wiki.jasig.org/display/CASUM/User+Manual
http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html