Access Keys:
Skip to content (Access Key - 0)

WebSSO

Overview

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 GTSServer 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 Workflow

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 WebSSO Client,which searches for an established session. Since it does not exist, it redirects the user's request to the WebSSO Server providing the target application's URL as return point.
  2. The WebSSO Server displays a login page, and the user provides their username/password pair for authentication.
  3. The WebSSO server provides these credentials to the Authentication Service.
  4. If the credentials are valid, the Authentication Service returns a signed SAML Assertion to the WebSSO Server.
  5. The WebSSO 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 WebSSO 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 WebSSO 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 WebSSO Client 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. WebSSO Server validates the ticket and returns an assertion object with the user's attributes to the client. The WebSSO Client retrieves this information, and attaches it to user Request/Session.
  13. The WebSSO Client 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 WebSSO Client 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.

Single Sign Out Workflow

Following is the process flow for components for single sign out session:

The user is logged into the target Web Application and able to access multiple Web applications without providing credentials provided all the Web Applications are integrated with WebSSO as specified in above Single Sign On Work Flow.

WebSSO has set one CAS TGT(ticket granting ticket) representing the user's single sign on session, and set a CAS TGT cookie on the user's browser. WebSSO has also recorded the service tickets and url entries for the webapps that user was able to access during Single Sign on. The target webapps have created local sessions for the user, and are also storing the service ticket in cache.

  1. User clicks on logout link on Web Application (i.e. Target WebApp-1) through the web browser.
  2. WebApp-1 receives the request, parses it and looks up the session containing the corresponding service ticket. Once found, it deletes the session. Although the user still has the session set on the browser, future requests to this webapp will result in a redirection to WebSSO for login.
  3. Target WebSSO Client-1 sends a logout url request to WebSSO server.Logout url has CAS TGT(ticket granting ticket) and delegation EPR as GET parameters.WebSSO server deletes ticket granting ticket for that user from its registry.
  4. WebSSO Server would connect to the Delegation Service to obtain the User's Grid Credential. Now using this credential it would issue a Destroy Delegation Policy to the Delegation Service. This effectively end user's Grid Session as a new application cannot obtain the user's grid credentials anymore.
  5. The WebSSO Server will callback to each of the services that are registered with the system(user is able to access services during Single Sign On) and send a https SAML POST request message which has service ticket of the user.Following is sample SAML post message: 
    <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID "[RANDOM ID]" Version="2.0" IssueInstant="[CURRENT DATE/TIME]">
<saml:NameID   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">'@'NOT_USED'@'
</saml:NameID>
<samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex>
</samlp:LogoutRequest>
  6. Each of the application retrieves session identifier from the SAML message. Maps this session identifier to CAS Service Ticket present in their local registry, deletes from its registry and also invalidates user session.
  7. WebSSO renders the logout page to the user's browser, including a header deleting the CAS TGT cookie.
    Now if the User tries to access a protected resource in target Web Application using same browser, Web Application will challenge the User to provide credentials again as it cannot find a Single Sign On session.
View the Project Status.
Last edited by
Saba Bokhari (789 days ago) , ...
Adaptavist Theme Builder Powered by Atlassian Confluence