What is CASThe central authentication system provides a means for authenticating users against a central repository. Instead of asking a user for their username (netId) 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 CASThere 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. LoginThe 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. IMAGE 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 Image Removed. (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 Image Removed. (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 Image Removed. (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. IMAGE 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 Image Removed. (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 Image Removed. (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 Image Removed. (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. IMAGE 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 Image Removed. 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: If the validate fails, the function returns: Code Block |
no
failure code
For more information please visit the links at the right. They contain the full documentation that should help you with any type of CAS integration that you are planning to do. |