What is CAS
The central authentication system provides a means for authenticating users
against a central repository. Instead of asking a user for their username and password at
every application, the CAS server provides a mechanism for users to login once and not
have to login to every application every time they are used. The CAS server stores a
cookie in the users browser when they successfully authenticates and looks for the cookie
before requesting a user to present their credentials.
How do I call CAS
There are four interfaces to CAS; login, logout, serviceValidate, and validate. The
login function checks to see if the user needs to present their credentials. The logout
function destroys all stored credentials and forces the user to reauthenticate before
proceeding. The serviceValidate function provides a two level authentication method to
verify the ticket that is stored in the browser was presented by the CAS server and not
someone pretending to be the authentication source. If the second level authentication is
successful, the web server gets an xml construct that contains the username representing a
valid authentication process. The validate function performs the same operation but
simply returns a yes followed by a carriage return and the username.
Login
The login servlet is the first interface into the server. Its first action is to check the
browsers cookie and compare it to the ticket cache that it manages. If the cookie
information matches the ticket cache then the user does not need to present credentials for
application access. If the cookie is not present or the cookie is invalid the user must
present their username and password before proceeding. These credentials are then used
to bind to the campus Kerberos server. If the bind is valid, a cookie that contains this
users offset into the ticket cache is stored in the browsers memory. The cookie remains
valid until the browser exits, a destroy request is received by the browser, or the CAS
server restarts and flushes the ticket cache. The ticket cache is typically cleaned every few
minutes but tickets are maintained for 12 hours from creation.
The sequence of events for a login starts with the users browser connecting to a
web service. (1) The user does nothing more than connecting to the web server requesting
a web page, an example would be http://my.web.net/service.html
. (2)The web service
then redirects the browser to connects to the CAS server using the web servers web page
as the web service requested. This redirection takes the form of https://netid.rice.edu?service=http://my.web.net/service.html. (3)Once the CAS server
validates the browser cookie or user credentials, it returns a ticket to the browser and
redirects it to the web service. This takes the form of http://my.web.net/service.html?ticket=random_sequence. (4)At this point the web service
can either choose to trust the user credentials if it does not need the NetID or perform a
serviceValidation if it does.
ServiceValidation
The serviceValidation servlet takes the ticket and service values passed in the
form of an html parameter to the CAS server. The CAS server then takes the ticket and
uses it to index into its ticket cache that it retains in memory. The ticket stored in the
cache contains a hash value of the service and is used to validate the cookie presented by
the client browser.
The sequence of events for a login starts with the users browser connecting to a
web service. (1) The user does nothing more than connecting to the web server requesting
a web page, an example would be http://my.web.net/service.html. (2)The web service
then redirects the browser to connects to the CAS server using the web servers web page
as the web service requested. This redirection takes the form of https://netid.rice.edu?service=http://my.web.net/service.html. (3)Once the CAS server
validates the browser cookie or user credentials, it returns a ticket to the browser and
redirects it to the web service. This takes the form of http://my.web.net/service.html?ticket=random_sequence. (4)At this point the web service
can either choose to trust the user credentials if it does not need the NetID or perform a
serviceValidation if it does.
ServiceValidation
The serviceValidation servlet takes the ticket and service values passed in the
form of an html parameter to the CAS server. The CAS server then takes the ticket and
uses it to index into its ticket cache that it retains in memory. The ticket stored in the
cache contains a hash value of the service and is used to validate the cookie presented by
the client browser.
The serviceValidation function is an interaction from the web service to the CAS
server to verify that the ticket and the service handles are valid. This request takes the
form of https://netid.rice.edu?service=http://my.web.net/service.html?ticket=random_number.
The browser is not involved in this interaction because the web service needs to interact
with the CAS service to verify the ticket number. The CAS server returns an xml
construct that contains a success structure or an error if the ticket is invalid. Embedded in
the xml headers is the NetID which the web service can then use to personalize the web
application. At this point, the web service can construct its html content and respond to
the browser.
Obtaining the NetID from the CAS server
The NetID is obtained from the CAS server by extracting it from the xml headers
returned from serviceValidate or text string returned from validate. The serviceValidate
function returns the following headers:
| Code Block |
|---|
<cas:serviceResponse xmlns:cas='http://netid.rice.edu/cas'>
<cas:authenticationSuccess>
<cas:user>NetID</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
|
If the serviceValidate fails, the function returns the following headers:
| Code Block |
|---|
<cas:serviceResponse xmlns:cas='http://netid.rice.edu/cas'>
<cas:authenticationFailure code=" failure code">
</cas:authenticationFailure>
</cas:serviceResponse>
|
The validate function performs the same a similar operation but returns a different
response string. For a successful authentication, validate returns:
| Code Block |
|---|
yes
NetID
|
If the validate fails, the function returns:
| Code Block |
|---|
no
failure
|