User Auth Plug-in
Author: Collin VanDyck
Users in Cascade Server can be authenticated in one of three ways:
- Normal
- LDAP
- Custom
The Normal authentication works as expected, comparing supplied the user-supplied password against the password stored in the Cascade database. Note that these passwords are hashed to prevent accounts being compromised.
LDAP authentication applies to users imported from the LDAP migration tool. These users log in the same way as other users, except that instead of comparing a password against the Cascade database, Cascade will attempt to access the LDAP store using the supplied credentials. If successful, authentication is successful and the user logs in.
Custom authentication refers to a plug-in architecture Cascade exposes to allow 3rd party authentication frameworks to authenticate users in a variety of ways.
To support custom authentication, Cascade server provides a series of hooks into the authentication life cycle. Developers coding such a custom plug-in will have the ability to redirect the browser to arbitrary URLs (such as a single sign on web application).
Plug-in Development
When writing a plug-in, the custom java class must implement the interface
com.hannonhill.cascade.model.security.authentication.Authenticator
This interface defines two main methods:
public boolean redirect(HttpServletRequest request, HttpServletResponse response, AuthenticationPhase phase) throws IOException;
and
public String authenticate(HttpServletRequest request, HttpServletResponse response);
The redirect() method is called by the Cascade authentication framework based on what phase of the authentication life cycle is active. The AuthenticationPhase is an enum with two values: LOGIN and LOGOUT.
For the LOGIN phase, Cascade first instantiates the custom authentication module and calls redirect with the LOGIN authentication phase parameter. At this point, the module will redirect to an external webapp to perform the authentication, at which point the authentication web application should redirect the browser back to Authenticator.AUTHENTICATION_URI.
Cascade will then invoke the module once more and call authenticate(). The module at that point should know whether or not the user was successfully authenticated, and should everything go well, the module should return the username of the successfully authenticated user. At this point, Cascade establishes a user session for the authenticated user and the user is considered to be logged in to Cascade.
The other phase, LOGOUT, is called when the logout link is clicked and after Cascade invalidates the user session. The typical behavior here is for the custom authentication module to redirect the browser back to the external authentication web application.
It is important to remember to not store state in the authentication module using instance members. Each call on the authentication module is made after a fresh instantiation, and as such, data stored as instance members will be lost in between invocations.
The authentication module code is typically bundled into a JAR file and placed in the $cascade_home/server/default/lib directory. After bouncing the app server, the custom classes should be available.
A configuration file must be created to tell Cascade how to load the custom plug-in:
$cascade_home/authentication-config.xml: