Integrating Platform Security with Apereo CAS SSO

Owned by DevPortal Editor (Unlicensed)
13/09/21
5 min read


Disclaimer

This IM is deprecated, see our new IM Premium



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:

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.

Control Panel configuration

For the Control Panel application to connect and delegate authentication to the CAS server, it is necessary to include the java library provided by Apereo CAS and to configure the application's own security. .
The Control Panel application is a Spring Boot application. This will be included in the configuration of the connector with the CAS server:

You must also configure the Spring security filter:
And configure the entry point in the Spring Boot configuration.

The included configuration serves as an example to take into account the necessary steps when configuring an application to delegate authentication to the CAS server.

For each technology and application used, a similar procedure is necessary. For this, please refer to the documentation available on Apereo's website.
https://apereo.github.io/cas/5.1.x/integration/CAS-Clients.html

CAS Server configuration for Control Panel authentication

Once the Control Panel integration has been implemented, the next step is to register the application in the CAS Server.
To do this, a .json file will be created with the associated configuration. It should look like this:

Once again, this is an example configuration. For more details, refer to the Apereo documentation.
https://apereo.github.io/cas/5.1.x/integration/Delegate-Authentication.html

Complete authentication flow


Next you can find a diagram with the sequence diagram of the complete use case (in Spanish; translations after the diagram).

  1. Access to application URL: The user enters the url of the Web Application in the browser.
  2. Request is intercepted: The browser sends the request, which is intercepted by the CAS Server.
  3. UI Login: The CAS server provides the unified login UI for the SSO:
  4. UI to user: The browser presents the login UI to the user.
  5. Enter credentials: The user inputs id and password.
  6. Credentials are sent: The browser sends the credentials to the CAS Server.
  7. CAS Server validates credentials: CAS Server validates the credentials (against LDAP, databases, ...).
  8. CAS Server generates ticket: The CAS Server generates a ticket.
  9. Ticket is sent to App: The ticket is sent to the application.
  10. Ticket / App validation is requested: The application requests the validation of the user by means of the ticket and Application id.
  11. Ticket / App is validated: The CAS server validates the credentials for the ticket user and the application.
  12. Confirmation is sent: The validity of the credentials is confirmed to the application.
  13. App internal logic:Internal logic of the Application, which includes an invocation to a service registered in the API Manager.
  14. Invoked using API Key config: The service is invoked using the API Key corresponding to the application registered in the API Manager.
  15. External service invocation: The external service is invoked via the API Manager.
  16. API Manager response: The application receives the response from the API Manager.
  17. App internal logic: Internal application logic. It builds the response UI.
  18. App Response: The Application sends the response.
  19. UI response to the user:The UI is presented to the user with the result.