Passwordless authentication in CAS allows users to login without having to type in a password. Instead, passwords take the form of tokens that expire after a configurable period and are shared with users using communication methods such as email or SMS. Using this strategy, users are simply asked for an identifier (i.e. username) which is used to locate the user record that contains forms of contact such as email and phone number.
This is a short tutorial on how to set up CAS to use Passwordless Authentication to avoid the insecure practice of using a shared password for different services and improve user experience, especially for mobile devices and applications.
Our starting position is based on:
Once you have decorated the CAS WAR Overlay with the proper extension module, you will need to adjust your CAS configuration (i.e.
cas.properties file) to tune the feature for the following:
How should user records and contact information be found, given an identifier?
To keep things simple for this tutorial, we are going to use a static map of usernames that are linked to their methods of contact, such as email or phone number. The key in the map is taken to be the username eligible for authentication while the value can either be an email address or phone number that would be used to contact the user with issued tokens.
Tokens generated by CAS and shared with users are signed and encrypted. We can instruct CAS to use specific crypto keys for this purpose.
If you skip this step, CAS will automatically generate at startup and will issue warnings in the logs for you.
We can also adjust the expiration time of generated tokens:
To keep things simple, we will configure CAS to share tokens with users via email. How do we configure email settings such as message body, from, subject and the server settings?
firstname.lastname@example.org cas.authn.passwordless.tokens.mail.text=Your CAS Passwordless token is <strong>%s</strong>. cas.authn.passwordless.tokens.mail.subject=Your CAS Passwordless Token cas.authn.passwordless.tokens.mail.html=true
We will also instruct CAS (and Spring Boot underneath) to use a dummy email server, running on
spring.mail.host=localhost spring.mail.port=25000 # spring.mail.testConnection=true
Once you attempt to access a CAS-protected application and assuming the application is properly registered with CAS, you’d be redirected to the CAS login screen as such:
casuser is the only entry in our simple account store that is set up for passwordless authentication. Once
casuser logs in, CAS will ask for the shared token that is now shared with the user via an email message:
The email message from CAS will arrive in the user’s inbox with the token:
Assuming the token is still valid, CAS will ask and accept the token from the user and will proceed normally to route the flow to the requested application.
Pretty simple, eh?
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 know that all other use cases, scenarios, features, and theories certainly are possible as well. Feel free to engage and contribute as best as you can.