Apereo CAS - Custom Login Fields w/ Dynamic Bindings


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.

Despite what you may have heard, I am here to put a stop to all rumors and clarify definitively that this blog post has nothing to do with Taylor Swift. Instead, this post deals with a pretty simple CAS use case, which is:

How does one include additional fields into the login form and get access to field data in a custom CAS authentication handler?

Sounds quite legitimate. Let’s start with the simpler answer, which is that any CAS authentication handler can always directly tap into the HttpServletRequest object to query and fetch parameters passed by the login form and other views. One could do this in Spring Framework speech using something like:

...
HttpServletRequest request = ((ServletRequestAttributes)
  RequestContextHolder.currentRequestAttributes()).getRequest();
Object parameter = request.getParameter("whatever");
...

If this feels a bit uncomfortable, let’s dig deeper to see how CAS might accommodate this use case in more official ways.

Our starting position is based on:

Overview

CAS presents the ability to augment the login form to include additional custom fields. These fields are taught to CAS using settings that describe modest behavior and tweaks for each and are then processed by the Spring Webflow engine to be bound to the object model that is ultimately in charge of handling and managing user input.

Example

So imagine that in addition to the usual username and password fields you also wanted to ask the user for their phone as a mandatory field. To do this, you’d teach CAS about the new phone field:

cas.view.customLoginFormFields.phone.messageBundleKey=customLoginFormField.phone
cas.view.customLoginFormFields.phone.required=true

The CAS message/language bundle, typically custom_messages.properties file, should also contain the text for the new field:

customLoginFormField.phone=Telephone
customFields[phone].required=Telephone number must be specified.

If you build and bring up CAS, you might see something like this:

image

…and if you attempt to submit the form without the phone field:

image

Authentication Handling

Next, let’s say you have registered the following authentication handler with CAS:

public class MyAuthenticationHandler extends AbstractUsernamePasswordAuthenticationHandler {
    ...
    protected AuthenticationHandlerExecutionResult authenticateUsernamePasswordInternal(
        final UsernamePasswordCredential credential, final String originalPassword) {
        ...
    }
    ...
}

To receive and process the new phone field in your custom authentication handler, you would do something like:

protected AuthenticationHandlerExecutionResult authenticateUsernamePasswordInternal(
    final UsernamePasswordCredential credential, final String originalPassword) {
    Object phone = credential.getCustomFields().get("phone");
    ...
}

Finale

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.1.0 RC3 Feature Release

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

Apereo CAS - Webflow Decorations

Learn how you may decorate the Apereo CAS login webflow to inject data pieces and objects into the processing engine for display purposes, peace on earth and prosperity of all mankind, etc. Mainly, etc.

Apereo CAS - SAML2 Metadata Query Protocol

Learn how you may configure Apereo CAS to fetch and validate SAML2 metadata for service providers from InCommon's MDQ server using the metadata query protocol.

Saving Time is Time Consuming

May you live in the best of times. May you live in the startup times.

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.