Apereo CAS - Multifactor Authentication with RADIUS

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.

The ability to authenticate credentials using the RADIUS protocol and a compliant RADIUS server has been available in CAS for some time. In more recent CAS versions, this capability has been improved to support multifactor authentication scenarios by allowing CAS to recognize the Access-Challenge response type. This is a special signal sent by the RADIUS server requesting more information in order to allow access. The authentication flow is typically composed of the following steps:

  • Primary authentication via RADIUS typically using username+password credentials.
  • Capturing the Access-Challenge and the session State passed back from the RADIUS server.
  • RADIUS server provides the end-user with a one-time code, typically via SMS, email or mobile app.
  • Reroute the next step in the authentication flow, allowing the end-user to enter the code.
  • Submit the code and the previous State to the RADIUS server.
  • Validate the final response which should be an Access-Accept type, if all goes well.

A patch was submitted to the CAS project a while back to handle this exact scenario. This brief tutorial incorporates this patch into the CAS software and outlines the necessary configuration steps required to deliver multifactor authentication via RADIUS as noted above.

Our starting position is based on the following:



The setup is fairly simple, given CAS does all of the heavy-lifting. First, we need to prepare the CAS overlay with the right set of dependencies to enable RADIUS functionality:



…and next, we need to teach CAS about our RADIUS setup:

# Handle primary authentication via RADIUS (i.e. username+password)

# Handle MFA via RADIUS (i.e. one-time code)

# Signal webflow to handle MFA via RADIUS


That should do it. When credentials are validated via RADIUS as part of primary authentication, the user is routed to the next screen to enter the code provided by the RADIUS server via SMS, etc. Once entered, CAS will submit the code as well as any previous session state back to the RADIUS server which would have it validate the request and produce a successful response that allows CAS to collect attributes and establish a single sign-on session.

Note that we are also configuring CAS to limit the number of authentication attempts to 1, meaning after the first failed attempt at providing a valid token CAS would reject MFA and should route back to the login screen to restart the flow.


To test the basic tenants of this scenario using CAS APIs, the following code snippet may be used as an example:

RadiusClientFactory factory = new RadiusClientFactory(1813, 1812, 2000, "", "xyz");
JRadiusServerImpl server = new JRadiusServerImpl(RadiusProtocol.MSCHAPv2, factory);
RadiusResponse response = server.authenticate("username", "password", Optional.empty());

System.out.println("Enter code: ");
Scanner scanner = new Scanner(System.in);
String code = scanner.nextLine();

Optional<Serializable> state = Optional.of(response.getAttributes()
    .filter(a -> a.getAttributeName().equalsIgnoreCase("State"))
RadiusResponse mfaResponse = server.authenticate("username", code, state);

LDAP Attributes

Since RADIUS is used to handle primary authentication, we are going to try to switch to LDAP in order to fetch for user attributes. The following configuration should do the job:




We are instructing CAS to build the final authenticated Principal identified by the uid attribute (instead of whatever the user types into the login form as the credential id). We have some settings for the LDAP attribute repository that describe the LDAP server, and of course we have a section of settings for attribute mapping where we fetch uid and virtually rename/remap it to uid or we fetch cn and remap it to commonName, etc.

After the primary authentication event, the attribute repository kicks in to determine the needed attributes for the user by running the query uid={0} against the LDAP server where {0} is replaced with the authenticated user id (typically the credential id). Once the user entry is located, attributes are fetched and mapped and the authenticated Principal from the CAS perspective has an identifier determined by the uid attribute as well as at most four extra person attributes attached to it, which can then be used for attribute release.


Huge thanks to Jozef Kotlar, Bo Simonsen, Jesper Grøndahl and many others who contributed guidance, code, and working examples to see this feature to completion.


I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please feel free to engage and contribute as best as you can.

Misagh Moayyed

Related Posts

CAS 6.0.0 RC4 Feature Release

...in which I present an overview of CAS 6.0.0 RC4 release.

Apereo CAS 6.0.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.0.x Deployment - WAR Overlays

Learn how to configure and build your own CAS deployment via the WAR overlay method, get rich quickly, stay healthy indefinitely and respect family and friends in a few very easy steps.

Apereo CAS - Jib at CAS Docker Images

Learn how you may use Jib, an open-source Java containerizer from Google, and its Gradle plugin to build CAS docker images seamlessly without stepping too deep into scripting Dockerfile commands.

Apereo CAS 6 - Administrative Endpoints & Monitoring

Gain insight into your running Apereo CAS 6 deployment in production. Learn how to monitor and manage the server by using HTTP endpoints and gather metrics to diagnose issues and improve performance.

Apereo CAS - SAML2 Metadata with MongoDb

CAS distributed SAML2 metadata management using MongoDB, where you learn how to store metadata documents inside MongoDB for CAS as a SAML2 identity provider and all other registered SAML2 service providers.

Apereo CAS - Slurp Configuration with Groovy

Learn how CAS configuration may be consumed via Groovy to simplify and consolidate settings for multiple deployment environments and profiles.

Apereo CAS - Configuration Management with MongoDb

CAS distributed configuration management using MongoDb, where you learn how to store and secure CAS configuration settings and properties inside MongoDb.

Apereo CAS - Integration with HashiCorp Vault

CAS distributed configuration management using HashCorp Vault, where you learn how to store and secure CAS configuration settings and properties inside Vault.

CAS 6.0.0 RC3 Feature Release

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