We recently worked on a project where right from the start we knew that we’d be hosting a multitude of public facing applications, providing both web interfaces and RESTful services. The nature of the information passing through these services dictated the need for a consistent approach to authentication that would be applicable to both application users and server-to-server communication.
In this blog I will talk about our integration of a Central Authentication Service (CAS) and some key experiences from the project.
Why is a CAS Important?
Authentication is defined as the process of determining whether someone or something is in fact who or what it is declared to be. This differs from authorisation, which is determining whether an authenticated entity can perform a given operation.
In our solution, while each application would be responsible for authorisation, we will have one Central Authentication Service responsible for all authentications to streamline the sign on process for users.
Choosing the Right CAS Product
We chose to implement a Central Authentication Service using the JASIG CAS open source product: http://www.jasig.org/cas
This product was chosen for the following benefits:
- Open Source – well documented, free
- Written in Java which made direct integration into our services (which where also 100% Java) straight forward
- Clients available for other languages (we knew we would need to integrate with non-Java systems)
- Configurable with an array of available backend authentication systems.
- Spring Security has a compatible CAS plugin.
Integrating the CAS
Integrating the CAS into our environment was quite straightforward as we already had a module responsible for maintaining our participating users and passwords. Implementing the required AuthenticationHandler interface using this module was the best solution for us and it meant we didn’t need to define additional data sources or JDBC connections just for CAS.
We found integrating CAS into our Spring Web applications very simple. Our applications were broken into two categories: those where we wanted to programmatically perform the authorisation, and those where a specific role is required. For the first group, registering the “HTTP Filters” provided by the CAS in the web.xml was sufficient; for the second group we used Spring Security with an intercept-url to specify the required role.
For our Production environment, each CAS instance in the cluster is deployed in its own application server. With a MySQL database cluster used for the ticket storage, we have been able to easily achieve our target of being able to create a 100 Service Tickets per second.
We also took advantage of the built in auditing and throttling services. This is critical for use in a clustered production environment. All authentication attempts are logged to a database – with the details from all nodes being logged to a central location, we were able to enable throttling across the cluster. The maximum number of failed authentication attempts in a given timeframe can be configured to suit the intended user base and associated security requirements. Enforcing request throttling should be considered mandatory when enabling the REST interface.
We have also found updating the JASIG CAS product very easy. We recently completed updating to version 4.0.0 which allowed us to update all applications to the latest 3.2 release versions of Spring Framework and Spring Security.
We found the following reference sites helpful with our CAS integration:
