Description

In this document we describe the way authentication is handled for Fermi/EXO/LSST applications.

CAS Server

The CAS Server is a Single Sing On (SSO) service. It currently allows users to log in against the SLAC Kerberos Serverver by providing their Unix or Windows credentials. We plan to switch to using CROWD as the main authentication engine, still using CAS as the single sign-on.

The CAS Server is currently deployed at http://glast-ground.slac.stanford.edu/cas

Below we describe the handshake mechanism that is at the heart of the single-sign-on service provided by CAS; also we describe the five basic interactions that are provided by the CAS server. 

Handshake with CAS

The authentication process with CAS is accomplished via a handshake between the tomcat server and the CAS Server (as shown in the diagram below). The dynamic of the handshake depends on the type of request sent to CAS:

Login

1. The tomcat server sends an authentication request to CAS of the form https://glast-ground.slac.stanford.edu/cas/login?service=return_URL
2. If the request sent to CAS has never been authenticated (this is done via secure cookies by CAS), the user will be prompted with a CAS login page in which the user will have to provide his/her credentials
3. When the user authentication is successful (or when the request sent to CAS had already been authenticated before), CAS will send back a request to the provided service parameter of the form return_URL?ticket=....   where ticket is an internal CAS parameter that identifies the logged in user
4. When the original server receives the above request, with a ticket parameter, it sends back another request to the CAS server to validate the ticket parameter.
5. The result of the ticket validation is the id of the authenticated user

Renew

An authentication renew request to CAS contain the renew parameter: https://glast-ground.slac.stanford.edu/cas/login?service=return_URL&renew=true.

This feature of the CAS protocol allows clients to opt out of single sign on. It allows a client to advise the CAS server login to always authenticate a user regardless of whether a single sign on session already exists.

This is a useful feature for when there are certain services that would like to use CAS as the authentication mechanism but allow access to sensitive material. They can force CAS to reauthenticate a user to ensure that they are signing in the correct user (and its not a pre-existing SSO session that wasn't terminated.

See the jasig renew documentation for more details.

Gateway

The CAS Server includes a feature whereby it is possible to set the request parameter "gateway" to "true" on the request for CAS login. If "gateway" is "true", then CAS will not paint the user login screen. If it can accomplish authentication by single sign on - that is, by detecting the CAS ticket granting cookie - then it will redirect to the URL specified by the "service" parameter with a valid service ticket. If it cannot accomplish single sign on, then it will redirect to the "service" URL without painting any login screen.

This allows your application to detect and take advantage of user single sign on without bothering the user with a login screen in the case where he or she is not yet logged on. This is useful for main pages and is probably a "best practice", since it allows the user to learn about the service to which he might authenticate before being abruptly presented with the CAS login screen out of context.

See the jasig gateway documentation for more details.

Logout

URL: cas/logout

Ticket Validate

The Proxy validation request is a direct invocation of a CAS interface to validate the ticket return by either a login/gateway/renew request. Upon successful ticket validation the request returns the username associated with the authenticated ticket.

URL: proxyValidate?ticket=.....&service=.....

Login Filter

The login Filter works in conjunction with the CAS server. It is installed on all (most) web applications. It is responsible to handle the user's login and make sure that once a user is logged in (or logged out) this information is propagated to all other applications.

Currently the login Filter lives in org-srs-web-base. 

Initialization

The Login Filter is installed on any web application that wants to add login capabilities.

The following are initialization parameters to the login filter.

Logic

The Logic of the Login Filter is represented in the diagram below.

The main goal of the login filter is to handle interactions with CAS. Since the handshake with the CAS server introduces an overhead on the user's request the login filter tries to reduce the number of times such interactions occur. To achieve this it makes use of session attributes and non persistent cookies.

Note: when discussing the logic below we have to keep in mind that the Login Filter handles requests from different applications (i.e. different sessions on different tomcat servers) coming from different domains (which implies that access to cookies might vary depending on the domain).

After a successful login with the CAS server (either via a login/gateway/renew request) the Login Filter will write the following variable in the session scope of the application:

• userName the name of the logged in user as provided by CAS

Since this is a session variable it applies only to a specific application and cannot be accessed by other applications. The purpose of the userName variable is to avoid having to force the login on a user, once it has already occurred.

Additionally, for each successful handshake, the login filter will write two non persistent cookies:

• cas.lasthandshake.time the time the last handshake was successful
• cas.lasthandshake.username the username of the last handshake

The purpose of these cookies:

• to detect if the username is still valid: a user could send a request to renew its credentials and login with a different username. In this case the cas.lasthandshake.username will be different than the session userName, indicating that the current session must have a new handshake with CAS
• to minimize the number of times the LoginFilter sends requests back to the CAS Gateway to assess the validity of the SSO session. If the username is still valid and some time has elapsed from the last successful handshake, the loginFilter will send a new handshake request with the CAS server
• the following is no longer valid. See below on Logging out. (to detect if the user logged out. When any application sends a logout request to the CAS server, the cookies will be removed. The absence of the cookies will tell a different application that the user has logged out.)

This works only within the specific domain, since cookies are domain specific.
For a complete logout all active sessions have to be invalidated and this can be achieved by closing the browser.

The Login Filter implements the following features:

• The Login Filter logic is bypassed for:
  • requests to pages that match any item in the list provided in the skipPages initialization parameter
  • requests incoming from servers in the tomcat_servers database table in the database specified by the configDb initialization parameter   

When a user logs out with CAS or its TicketGrantingTicket session expires, CAS sends a POST message to each of the services that requested ticket validations. When the login filter receives such post it will invalidate the session corresponding to the invalidated ticket (if still possible). See ?the following Jira.

Comments

It seems that the attribute loginChecked is not used, i.e. that the logic that was skipping the filter when the login had been checked has been lost, or that this attribute is no longer needed.

New CAS Server

Integration of Cas with Crowd