Why you should choose CAS as your SSO system


Collaborate
The blog is managed and hosted on GitHub. If you wish to update the contents of this post or if you have found an inaccuracy and wish to make corrections, we recommend that you please submit a pull request to this repository.

Most of the customers for whom I work have already chosen the CAS server and its ecosystem when I come in to help them.

Yet, from time to time, I’m contacted earlier in the decision process when the client is still thinking about the products and protocols he wants to use. Advocating for the CAS server is an easy task for me, even if generally, technical reasons are just a small part of the game (politics and relationships really matter).

I especially want to disabuse people who believe that CAS software is just about the CAS protocol, it’s so much more.

Some may think that as a CAS committer and as an IAM freelance, I’m biased towards CAS. This is true, but certainly less than any salesman who will earn fees for each sold product.

Eventually, this is what I say:

1) CAS is Open Source

Most customers primarily choose Open Source software because it’s free. While this is a good reason, they still need to pay consultants to help them. To me, there are greater benefits, especially the fact that you can contribute to the project. If you buy an SSO system from a big company, want a new feature and are the only one in the world, it’s too bad for you, there is little chance you will get your new feature. With Open Source software, you can make it happen!

2) CAS is a very modern software

While the general code quality of the CAS server has always been good, I must admit that the whole architecture and design have strongly improved since version 5 where it has embraced the Spring Boot ecosystem. I was a bit reluctant on this huge change, but Misagh was definitely right as using Spring Boot was a big jump forward. There are some glitches here and there, but overall, the code is easy to read and understand and things are really modular.

3) CAS has many features

The CAS server offers many useful capabilities, from obvious ones to more advanced ones. It handles various authentication methods, multi-factor authentication (MFA), can remember the user, force or try authentication, offers a dashboard and monitoring, has logs and audits, manages passwords, etc. Of course, you cannot only assess a software by the number of its features but having many options is generally a good thing.

The CAS server is one of the most popular software in IAM. With around five thousands stars on github.com, CAS is a well-known project. Many higher-education schools and companies use it, so you can easily find help from the CAS community or paid consultants. The more the CAS server is installed, the more people read its source code and test it, the more security vulnerabilities are discovered and fixed. It makes it a safe choice for your SSO system.

5) CAS fits everywhere

Your existing environment is the first most important criteria when choosing an SSO system. Most companies never start a new project from scratch: for example, they use Redis on CentOS, a bit of MongoDB also and their users’ storage is an old LDAP system. You must cope with all that constraints. If your software only supports technologies A and B, you can only address clients willing to use A or B. The CAS server can:

  • use many authentication methods: LDAP, databases, X509, Cassandra, Radius, Spnego, JWT, AWS Cloud Directory and many more
  • handle many storage systems: Memcached, Redis, Oracle, Hazelcast, CouchDB, Couchbase, etc.

6) CAS is the master of interoperability

Your existing environment is also the second most important criteria when choosing an SSO system! Big bang projects almost always fail and it’s hard to deal with legacy. I don’t remember having a customer without an existing software to integrate with. And this is the great strength of CAS:

  • the CAS server can act as a SAML IdP, an OAuth provider, an OpenID Connect provder or as a CAS server of course
  • but it can also play the role of a client delegating the authentication to another CAS server, to a SAML IdP, to Facebook, Google, Twitter and many other identity providers.

This is one of the main contributions I brought to CAS and I’m especially proud of this interoperability.

CAS clients used for integration in web applications exist in many technologies as well: Java, PHP, .Net, Ruby, Python, Node.js, Apache module, etc.

CAS is a great software, it is worth considering if you plan to choose an SSO system.

Jérôme LELEU

Originally posted on the pac4j blog

Related Posts

CAS 6.1.0 RC3 Feature Release

...in which I present an overview of CAS 6.1.0 RC3 release.

Apereo CAS 6.1.x - Credential Caching & Proxy AuthN

Learn how you may configure Apereo CAS to capture and cache the credential's password and the proxy-granting ticket in proxy authentication scenarios, pass them along to applications as regular attributes/claims. We will also be reviewing a handful of attribute release strategies that specifically affect authentication attributes, conveying metadata about the authentication event itself.

Apereo CAS 6.1.x - Attribute Repositories w/ Person Directory

An overview of CAS attribute repositories and strategies on how to fetch attributes from a variety of sources in addition to the authentication source, merge and combine attributes from said sources to ultimately release them to applications with a fair bit of caching.

Apereo CAS 6.1.x - Building CAS Feature Modules

An overview of how various CAS features modules today can be changed and tested from the perspective of a CAS contributor working on the codebase itself to handle a feature request, bug fix, etc.

CAS 6.1.0 RC2 Feature Release

...in which I present an overview of CAS 6.1.0 RC2 release.

Apereo CAS - Riffing on Attribute Release Policies

Learn how to release the kraken of attributes to CAS clients, relying parties and service providers using a variety of attribute release policies and authentication protocols, sampled and collected here to fun and profit.

Apereo CAS - Delegated Authentication to SAML2 Identity Providers

Learn how your Apereo CAS deployment may be configured to delegate authentication to an external SAML2 identity provider.

Apereo CAS - Custom Login Fields w/ Dynamic Bindings

Learn how to extend the Spring Webflow model to add custom fields to the CAS login form and the authentication process and take advantage of the additional user-provided data in customized authentication handlers.

Apereo CAS as an OAuth2 Authorization Server

Learn how to configure CAS as an OAuth2 Authorization Server and configure Spring Boot client app to work with it

Apereo CAS - SAML2 Identity Provider Integration w/ Gitlab (also staring HAProxy and LDAP)

Learn how Apereo CAS may act as a SAML2 identity provider for Gitlab and run everything locally on a workstation with Docker and Java.