CAS uses Windows AD to verify the user's Single Sign-on

In the simplest installation, Yale CAS only performs same-sex authentication on users and passwords. Of course, the source code of CAS server also contains instances of other authentication methods, developers can use other authentication methods through the passwordhandler interface, such as database user name and password matching authentication, digital signature authentication, operating system user authentication, and LDAP user authentication. The following section describes a simple example of CAS user verification using user information in Windows Active Directory.

Active Directory Server Authentication

In my educational portal project, the application can be easily modified because the source code is available. I have used the servlet filter for each of these applications. in this case, CAS will perform the authentication when the user first visits the portal and requests a restricted application or data source. once authentication is successful, the CAS servlet filter can validate the ticket and pass the username as a parameter to the requested application. I have modified the existing application login screens to accept the username parameter from CAS after a successful authentication. the applications can be then use this parameter to authorize users and provide an audit trail of user activity.

Unfortunately, CAS does not come with any truly useful authenticators. the default authenticator simply verifies that the username and password are identical. in the educational portal project I use Microsoft's Active Directory Server to store the user profiles. so I needed to extend the CAS server to authenticate the username and password against the Active Directory Server.

The creators of CAS at Yale University have developed a pluggable authenticator architecture. by extendingPasswordHandlerInterface, a developer can create a class to implement the password-checking logic.

Listing 2. CAS's pluggable authenticator Architecture

/** Interface for password-based authentication handlers .*/
Public interface passwordhandler extends authhandler {

/**
* Authenticates the given username/password pair, returning true
* On success and false on failure.
*/
Boolean authenticate (javax. servlet. servletrequest request,
String username,
String password );
}

All I had to do was find out how to check the username and password using Active Directory Server, create a class to extend this interface, and add the code to perform the authentication.

ADS is an LDAP3-compliant Directory Server. It supports a number of different authentication methods, the principal ones beingAnonymous,Simple, AndSASL(Simple authentication and security layer ). anonymous Authentication is of no use in this instance; simple authentication sends the password as cleartext, again not suitable for these needs. so SASL is the option I will use.

SASL supports pluggable authentication. This means that you can configure the LDAP client and server to negotiate and use any of a range of mechanisms. The following are some of the currently defined SASL mechanisms:

• Anonymous
• CRAM-MD5
• Digest-MD5
• External
• Kerberos v4
• Kerberos V5
• SecurID
• Secure Remote Password
• S/Key
• X.509

Of these mechanics, popular LDAP servers (such as those from sun, OpenLDAP, and Microsoft) support external, Digest-MD5, and Kerberos v5.

CAS itself is Kerberos-like, sharing privileges of the same concepts such as tickets, ticket-granting tickets (actually called ticket-granting cookies in CAS), and a similar protocol. so choosing this mechanic felt like a natural fit. also adding support for Kerberos authentication will enable cas, in a future development, to act as a web-based Kerberos agent on behalf of the user, allowing CAs to manage all aspects of Kerberos tickets for its users. this wowould mean that the same Kerberos authentication mechanisms used to access local and network resources cocould also be used by remote users.

The Kerberos protocol is already built into ads and Windows 2000/XP. the Java authentication and authorization Service (JAAS) provides an implementation of a Kerberos login module (see resources for the tutorial that provides detail on how to get a sample application running ). to be precise, it is GSS-API SASL mechanic that you will use, but this only supports Kerberos v5 authentication to ldap3 servers.

Kerberos authentication is a straightforward process (assuming you follow the instructions carefully ):

1. Configure the login module for your application class in your JAAS configuration file.

Edu. Yale. Its. Tp. Cas. Auth. provider. login using uthhandler
{
Com. Sun. Security. Auth. Module. krb5loginmodule required client = true;
};

2. CreateLoginContext, Passing the name of the class doing the authentication, andCallBackHandlerObject.

Logincontext lc = new logincontext (casapp. Class. getname (),
New cascallbackhandler ());

3. Calllogin()Method to perform the authentication. If this executes without exceptions, then authentication is successful. if an exception is thrown, then the exception indicates the cause of the failure.

For a more in-depth look at Kerberos authentication, I suggest you use the resources at the end of the article. (I 've also provided a download of my implementation and configuration files,KerberosAuthHandlerAndCASCallBackHandler.)

You need to create a newPasswordHandlerImplementation,KerberosAuthHandler, Which uses the above methods to authenticate against the Active Directory Server using Kerberos v5.

Listing 3. Creating the new passwordhandler implementation

Public class extends uthhandler implements passwordhandler {

Public Boolean authenticate (javax. servlet. servletrequest request,
String username,
String password)
{

Logincontext lc = NULL;

Try
{
/* Set up the callback handler, and initialise */
/* The userid and password fields */

Cascallbackhandler CH = new cascallbackhandler ();
Ch. setuserid (username );
Ch. setpassword (password );

/* Initialise the login context-loginmodule configured */
/* In cas_jaas.conf and */
/* Set to use krb5loginmodule .*/
Lc = new logincontext (Response handler uthhandler. Class. getname (), ch );

/* Perform the authentication */
LC. login ();

}
Catch (loginexception le)
{
System. Err. println ("authentication attempt failed" + le );
Return false;
}
Return true;

}
}

WhenLoginContextIs created, I pass the classname andCASCallbackHandlerObject. The JAAS configuration file specifies the login module to use for this class.

Whenlogin()Method is called, the login module knows what information it needs from the user/application in order to authenticate them. in the case of Kerberos, it needs a username and password, so it constructs an array of two callback objects (NameCallbackAndPasswordCallback) And then calltheCallbackHandlerObject, which decides how it shoshould perform these callbacks and retrieve the username and password.

I have taken the simplest and most encrypt dient route and explicitly set the user ID and password usingsetterMethods onCallbackHandler. ThenCallbackHandlerSimply passes these on toNameCallbackAndPasswordCallbackObjects.

Listing 4. Setting ID and password with setname (casuserid) and setpassword (cassword)

Public class cascallbackhandler implements callbackhandler
{

Private string casuserid;
Private char [] cassword;

Public void handle (callback [] callbacks)
Throws java. Io. ioexception, unsupportedcallbackexception {
For (INT I = 0; I <Callbacks. length; I ++ ){
If (callbacks [I] instanceof namecallback ){
Namecallback cb = (namecallback) callbacks [I];
CB. setname (casuserid );

} Else if (callbacks [I] instanceof passwordcallback ){
Passwordcallback cb = (passwordcallback) callbacks [I];
CB. setpassword (cassword );

} Else {
Throw new unsupportedcallbackexception (callbacks [I]);
}
}
}

Public void setuserid (string userid)
{
Casuserid = userid;
}

Public void setpassword (string password)
{
Cassword = new char [password. Length ()];
Password. getchars (0, cassword. length, cassword, 0 );
}
}

The next thing to do is tell CAs to use the new authentication handler. Do this by setting the following in the web. xml file for the CAS server inWebapps/CAS:

Listing 5. Telling CAs to use the new authentication Handler

<! -- Authentication Handler -->
<Context-param>
<Param-Name> edu. Yale. Its. Tp. Cas. authhandler </param-Name>
<Param-value>
Edu. Yale. Its. Tp. Cas. Auth. provider. login using uthhandler
</Param-value>
</Context-param>

An Example Web. XML is encoded in the ZIP file ({%uthsrc.zip in resources ).

You'll have to restart tomcat, but this time you'll also need to set some Java runtime properties. expand the ZIP file ({{uthsrc.zip) and copy the files cas_jaas.conf, krb5.conf, and set{osjvmoptions. BAT toTomcat_homeDirectory. Run the setpolicosjvmoptions. BAT and then start Tomcat.

Now you are ready to repeat the helloworld experiment. This time you can use a valid Kerberos username and password pair as defined in your Active Directory Server.

Single sign-off

Without a uniied strategy, developers re-implement custom security for each network application. this can result in a variety of scalability and maintenance problems. single Sign-On solutions can be that uniied framework for security and authentication, alleviating much of the burden on users, administrators, and developers.

The concept of Single Sign-on, the technologies, and the implications for users and administrators are complex, so I have only scratched the surface in this article. but I have provided you with some practical ways to implement a single sign-on scheme using the proven CAS application from Yale University, and have also detailed a method to extend this technology so you can use it to authenticate users to a LDAP Server (specifically, to an active directory server using the Kerberos protocol ).