WebSSO:Web Single Sign On

From caGridWiki

Introduction

The WebSSO framework provides a comprehensive, Single Sign On solution for web application using caGrid’s GAARDS Framework. Users may navigate between participating applications without being challenged to provide login credentials. Likewise, WebSSO establishes a grid session for the user, allowing them access to other grid services unchallenged.

Out of Box SSO Component

The WebSSO Team, along with the caGrid Architecture team, evaluated various open source technologies for selecting an out of box standard Web Single Sign On Product. JA-SIG’s Central Authentication Service (CAS) was selected for these reasons:

1. Provides a simple, spring-based, pluggable approach to add functionality
2. Simple, non-intrusive, filter-based integration with target web applications (other ways possible too)
3. Extendable Client/Server Protocol. Provides capability of returning signed SAML assertions back to client from the server, hence providing a higher level of security
4. Extensive documentation, user base, and a larger development team.

JA-SIG’s Central Authentication Service (CAS)

The caGrid’s WebSSO Project uses CAS as the core component for providing the Single Sign On Framework. CAS is an authentication system originally created by Yale University to provide a trusted way for applications to authenticate a user. CAS became a JA-SIG project in December 2004.

CAS will be enhanced to use the caGrid’s GAARDS framework in back-end to authenticate the user. Also this framework will be enhanced to obtain’s user’s grid credentials on the client side and provide it to the Target Web Application.

More details on CAS can be obtained from their website at: http://www.ja-sig.org/products/cas/.

It provides details about its inner-architecture, protocols, available features, and how to use them.

For the caGrid WebSSO Project, we employ the following JA-SIG CAS components:

CAS Server v3.2.2 Stable Release: This is the server component of the SSO, which facilitates authentication of user’s credentials, establishment of the Single Sign On Session, and granting the SSO Session Tickets.

JA-SIG’s CAS Client for Java v3.1.3: This is the client-side web agent that includes classes for ticket validation, proxy ticket acquisition, servlets, filters for implementing the client portion of the CAS protocol, and Assertion Java object for representing the results of a validation attempt. This library is usable for implementing custom CAS functionality, and can be used stand-alone to CASify existing applications.

WebSSO leverages the CAS Client for Java in such a way that it doesn’t prevent other existing CAS clients from being used, since it doesn’t modify the underlying client/server protocol or modify the client code in any way.

Overview

The following diagram showcases all the components that are involved in the WebSSO framework. These components and their interactions are explained below.

Overview of WebSSO Work Flow

Component of WebSSO Framework

Following are the minimum set of components involved in an implementation of the WebSSO Framework. The diagram above depicts a single target application which is protected using WebSSO. If there is more than one application, then there will be a corresponding number of CAS Agents deployed along with them.

Client Browser

The Client is the end user trying to access a Target Web Application using a browser. The client browser is useful for persisting the Single Sign On session using a cookie, thereby allowing the SSO Server to identify the user and not challenge him for credentials when redirected from another application.

Target Web Application

This is the central authentication server which controls the entire Single Sign On framework. This component is provided by CAS. It also provides a login page which will be configured to adapt the look and feel of the CCTS Suite. It will be enhanced to communication with caGrid’s GAARDS

CAS Single Sign On Server

This is the central authentication server which controls the entire Single Sign On framework. This component is provided by CAS. It provides the login page which will be adapted to the look and feel of the CCTS Suite. It will be enhanced to employ caGrid’s GAARDS framework to authenticate a user using their local credentials. In return, this server will obtain his grid credentials and pass them to the Credential Delegation Service and publish a delegation policy as in who all can access the grid credentials. Once use is authenticated, it generates a service ticket which is transferred back to the client. It then uses this ticket to confirm that the SSO Session has been established and retrieve user’s attributes from the SSO Server.

CAS Agent

This is the client component of the CAS Single Sign On framework which will be deployed and configured as part of the target web application. It is a standard client which all applications can integrate through the web.xml. It intercepts all the client’s request to check if the single sign on session is established or not. It not it routes the user’s request to the Central Sign On Server allowing the user to authenticate himself and establish the SSO Session. On return from the Central Server the client intercepts the user’s request and validates the user’s session against the server. On success it also interacts with the Delegation Service to obtain user’s Grid Credential. Then CAS Agent forwards the user request along with the user’s attributes and grid credentials to the target application.

Authentication Service

To achieve federation, WebSSO allows a user to login using their local credentials. The CAS Single Sign On Server will be configured to point to an Authentication Service, which stands in front of a user’s Identity Provider. This Authentication Service accepts their Username/Password credentials and authenticates against the configured Identity Provider. If successful, it retrieves the user's attributes from the Identity Provider and formulates a SAML Assertion which is sent back to the Central Server.

Dorian

Once a user is authenticated from the Authentication service, the Central Server forwards the SAML Assertion to Dorian. The Central Server is configured to point to a single Dorian Server which acts as Identity Federation Service for the v0.5 Release. It generates their grid credentials (which is simply a short-lived proxy certificate) and returns the same to the Central Server.

Credential Delegation Service

The Credential Delegation Service is being built by the caGrid team which will be used to store the User’s Grid Credential along with a delegation policy. This delegation policy determines which applications have access to user’s Grid Credentials. On successful obtaining the User’s Grid Credential, the SSO Server publishes a delegation policy along with the User grid credentials to the Credential Delegation Service. On the client side the CAS Agent connect to the Credential Delegation Service using Target Application's Host Credentials and passed the Delegation EPR(End Point Reference) to retrieve User grid credentials. If it is permitted then the Credential Delegation Service returns the user’s grid credentials back to the CAS Agent, which is then forwarded the Target Application for it to use to access grid services.

GTS

Both the WebSSO Server and Client use GTS(Grid Trust Fabric) to validate the User's Grid Proxy . A Sync Description file is used to connect to the GTS Service running on the Grid. Both the WebSSO Server and Client use this file to connect to the GTS Server and validate if the user's proxy or CA has not been revoked. WebSSO provides facility to programmatically start SyncGTS both on client as well as server. If the user opts to start SyncGTS Daemon manually they can do so by following step at GTS page.

Single Sign in work flow

Following is the process flow for components to establish a single sign on session:

1. User initiates a request to the target application (which is protected by the SSO Framework) by typing its URL into the browser. The user's request is intercepted by the CAS Agent, which searches for an established session. Since it does not exist, it redirects the user’s request to the CAS Server providing the target application’s URL as return point.
2. The CAS Server displays a login page, and the user provides their username/password pair for authentication.
3. The CAS server provides these credentials to the Authentication Service.
4. If the credentials are valid, the Authentication Service returns a signed SAML Assertion to the CAS Server.
5. The CAS server passes the signed SAML assertion to Dorian.
6. Dorian ensures that the SAML assertion is signed by a registered Authentication Service and returns short-term Grid Credentials (Grid Proxy) for the user.
7. They CAS server validates the Grid Proxy obtained from Dorian against the GTS to make sure that it is still valid and the CA has not be revoked.
8. Once validated, the CAS server obtains the list of Host Identities from the configuration files and formulates a delegation policy. It publishes this delegation policy, passing the user’s Grid Credentials to the Credential Delegation Service
9. Once the Delegation Policy is published in the Credential Delegation Service successfully, it returns an End Point Reference (EPR) pointing to this Delegation Policy back to the WebSSO Server
10. Now it formulates a service ticket, attaches it as part of the URL as a GET parameter, and redirects the user back to the application using the provided return URL.
11. The CAS Agent for the application intercepts the request and retrieves the Service Ticket. It validates this Ticket with the CAS Server to ensure the user was authenticated recently.
12. CAS Server validates the ticket and returns an assertion object with the user's attributes to the client. The CAS Agent retrieves this information, and attaches it to user Request/Session.
13. The CAS Agent connects to the Credential Delegation Service using the Host Credentials of the Target Web Application to retrieve the User’s Grid Credentials (Grid Proxy) by passing the Delegation EPR(End Point Reference).
14. The Delegation Server retrieves the Host Identity from the call and checks it against the user's published policy. If the application has been given delegation rights, it returns the Grid Proxy for that user back to the CAS Agent.
15. The CAS Agent validates the Grid Proxy against GTS and the attaches it as an attribute to the Session and forwards the request to the target application.
16. The Target Application can retrieve all user attributes from the Request/Session including the user’s Grid Credentials. It then can use this Grid Credential to access a grid service on user’s behalf.