Information Technology Reference
In-Depth Information
Extension Case Study 2: Two-Factor Authentication with SMS One-
Time Tokens
Sometimes, web applications have the requirement for “Two-Factor
Authentication” for extra security. In other words, the user is expected to
produce two independent sets of credentials to be successfully
authenticated. Two-Factor Authentication is also described as “what you
have and what you know”. This is more secure than merely having two
passwords, because two passwords can be stolen as easily as one, but two
factors are harder for a malicious user to steal from a legitimate user than
one, because a physical object has to be stolen in addition to a piece of
information.
There are many forms of Two-Factor Authentication
26
, but what we will
illustrate here is a simple scheme involving a mobile phone (what the user
has) and a password (what the user knows).
Remember that CA S is an Open Source product with several
customisation/extension points, making it easy to add the functionality we
need. One of these extension points is the login screen. We will touch on the
ability to customise the login screen using stylesheets specif ic to a partner
organisation later on, but the customisation that we will use here is a change
of screen flow
27
.
CAS uses Spring Web Flow internally, so any Java web developer with
knowledge of Spring Web Flow should find it easy to make the change we
describe below.
The idea behind this implementation of Two -Factor Authentication is that
every user of the protected business application has a mobile phone that
they always carry with them. They also know their Single Sign -On password.
The CAS server will prompt them for a user ID and password as always, but
instead of generating tickets and letting them into the application upon
26
CAS already supports authentication through either passwords or X.509
certificates. With a simple code tweak, it can be made to require both, thereby
providing another implementation of Two-factor Authentication.
27
Keep in mind that although the change we describe should not negatively impact
security, it will need to be documented and the new design reviewed by auditors
before it can go into production. The auditors must confirm that the extension
implemented does not compromise the basic CAS security protocol in any way, since
it is only meant to add an extra authentication step before tickets are generated.
