Integrating Platform Security with Apereo CAS SSO

Introduction

Single sign-on (SSO) is a user/session authentication process that allows a user to provide her credentials only once at a single entry point in order to access multiple applications. SSO authenticates the user to access all applications to which access has been granted. This eliminates future authentication requests when the user changes applications during a given session.
Web SSO refers strictly to applications accessed through a web browser. Access requests to a web resource are intercepted either by a component on the server or by the application itself. Users who are not authenticated will be redirected to an authentication service and will only return to the page after re-authenticating.

CAS or Central Authentication Service is a Web SSO protocol. Its purpose is to allow users to access several applications by providing their credentials (e.g. username and password) only once. It also allows web applications to authenticate users without accessing the users' own credentials (password).
The CAS protocol involves at least 3 agents:

• A client browser from which the user accesses.

• The web application that requests authentication.

• The CAS server.

When the user visits an application that requires authentication, the application redirects the request to the CAS server. The CAS server validates the user's authentication (normally by checking the user and password against a database (LDAP,...).
In this case it will be the CAS server itself that provides the user interface to do the user authentication.
If the authentication is successful, then the CAS server returns a service ticket to the client. The application validates the ticket by contacting the CAS Server via a secure connection and providing its own service identifier. The CAS server then returns information on whether the user has been successfully authenticated.

Apereo CAS

One of the most widely used Web SSO solutions is Apereo CAS.

The main features for which it has been selected are the following:

• Open Source project.

• Open and well documented protocol.

• Plugin-oriented authentication (LDAP, DB,...).

• Support for multiple protocols (CAS, Oauth, OpenID,...).

• Has an extensive client library (Java, .Net, PHP, Perl...).

• Integration with uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle and others.

• Widely adopted.

https://www.apereo.org/projects/cas

Apereo CAS Architecture

The following figure shows the Apereo CAS architecture:

Open

The CAS server is built with Java technology (Spring Framework) and its main task is to authenticate users and grant access to configured services (CAS clients) by generating and validating tickets.
A CAS client can be:

• Any application that communicates using the supported protocol (libraries).

• Software developed to facilitate the integration of platforms or applications using one of the supported protocols (connectors).

CAS Server Preparation

We use Apereo CAS version 5.1, deployed from cas-overlay-template-5.1. For more information:
https://apereo.github.io/cas/5.1.x/
https://github.com/apereo/cas-overlay-template/tree/5.1

The server configuration involves two aspects:

• The actual configuration of the CAS Server components, and

• The registration and configuration of applications that delegate authentication to the server.

CAS Server configuration

The CAS server is configured using the cas.properties file.

This file will include information relating to connectors with authentication databases for users, ticketing, encryption, etc.

For more information: https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html

As we have seen before, several databases are used:

• Corporate LDAP as user directory.

• ConfigDB as alternative user directory.

• RealTimeDB on MongoDB for ticket storage (cookies).

The CAS server will also display the user interface that will serve as a single login page for all registered applications.

In this way, whenever an application requests authentication from the CAS Server, it will present a login screen where the user will enter his credentials. Once validated, the user will be redirected to the main page that is configured in each of the client applications.

Configuration of client applications

For applications that delegate their authentication to the CAS server, it is necessary to create an application profile for each one.
It will consist of a JSON that will identify the service, the urls it includes, logout page, and evaluation order.

CAS Client configuration

Same as it is necessary to carry out a previous configuration on the server, the client applications that are going to delegate authentication to the server must be adapted, including different connectors and configurations.
Depending on the type of application to be integrated, it will be necessary to use a library in the selected technology (Java, .Net,...) as we have seen previously, or to use a connector that performs the integration (drupal, ...).

Example: Control Panel integration as a CAS client

The Control Panel is a web application that can also be registered as a CAS client.

The steps to be carried out to integrate and configure it on the CAS server will be explained below.