Build and implement a single sign-on solution

Integrate an open-source Java-based authentication component into the Web portal

It is difficult to implement a single sign-on solution in an existing application (one Sign-on,sso, that is, to authenticate a user to all network resources), but each developer faces this problem when building a complex portal. Because portals need to be integrated with back-end resources, and each backend resource has its own authentication requirements, the portal often has to provide the user with a single sign-on feature. In this article, Chris Dunne describes his experience of building a single sign-on solution for a Web portal in one step. He will explain how to set up an open source solution (central authentication Service from Yale University) and how to extend it to be based on Microsoft Active Directory Infrastructure for authentication.

0 Reviews

Chris Dunne, technical director, Big picture software

September 19, 2007 content

Develop and deploy your next application on the IBM Bluemix cloud platform.

Get started with your trial

I found in my work that the need for a variety of portal applications is growing. The technical and functional requirements of the portal are becoming more and more complex. Although there are tools to build a simple portal, the integration of portals with remote or legacy data sources is still not easy to solve. One of the issues is authentication.

Authentication is a complex issue. Portals need to authenticate users to back-end data sources and applications, but these applications may have a different underlying security infrastructure. The ideal and most efficient authentication solution is a single-Sign-on,sso solution, in which users can authenticate to all network resources by logging in only once.

Recently, when building an education portal that required SSO, I researched many commercial and open source SSO solutions. In this article, I'll step through the process of building a simple SSO system using a free SSO implementation (CAS from Yale University). Why choose Single Sign-on.

How many people have implemented their own authentication mechanisms (often some kind of simple database query). Do you often consider the workflow required to create and manage user accounts. In any development project, authentication is a common task. If you're lucky, the company already has some common authentication classes or libraries. However, this task is often overlooked as a trivial matter that occurs only in the background.

In general, companies often do not have a consistent authentication policy or a reliable authentication framework. Over time, this causes a large number of applications to have their own authentication requirements and user repositories. Everyone needs to remember multiple usernames and passwords to access different applications on the network. This is a big burden for the management and support departments-you must set up accounts for each employee in each application, and help them solve problems when they forget their passwords, and so on.

Authentication is a common requirement for many applications, platforms, and infrastructures. In general, a user should not need more than one user name. Ideally, he should only have to prove his identity once and then be able to access all of the network resources that have been authorized.

The goal of SSO is to allow the user to access all applications with one login. It provides a unified mechanism for managing user authentication and implementing business rules to determine user access to applications and data.

Before discussing the technical details of single sign-on, let's talk about some of the benefits and risks of single sign-on. Benefits include: Increased user efficiency. Users are no longer plagued by multiple logons and do not need to remember multiple IDs and passwords. In addition, users who forget their passwords and turn to support personnel will also be reduced. Increase the efficiency of developers. SSO provides a common authentication framework for developers. In fact, if the SSO mechanism is independent, developers do not need to worry about authentication at all. They can assume that authentication is complete as long as a user name is attached to the application's request. Simplify management. If an application joins a single sign-on protocol, the burden of managing user accounts is mitigated. The degree of simplification depends on the application, because SSO handles only authentication. Therefore, the application may still need to set the user's properties (such as access privileges).

For single sign-on, some of the frequently mentioned issues include: hard to refactor. Refactoring the SSO solution to accommodate existing applications is difficult, time-consuming, and expensive. The unattended desktop. Implementing SSO can reduce some security risks, but it also increases other security risks. For example, if a user leaves his machine after logging in, a malicious user can access his resources. Although this is a pervasive security issue, SSO can make the problem even worse because a malicious user can access all authorized resources. When multiple logons are used, the user can log in only one system at a time, so only one resource is compromised. Single point of attack. When using single sign-on, all applications use a centralized authentication service. This is an attractive target for hackers who want to implement a denial-of-service attack.

Therefore, SSO is not without drawbacks. But I believe that, in the eyes of users, administrators, and developers, its advantages outweigh the drawbacks.

Back to top SSO Open source project

As mentioned earlier, I am currently building a WEB portal for an educational institution. This portal will provide an online learning environment for students participating in the remote course.

The building blocks for this portal are already in place. The site has been established, the course content has been developed, the virtual learning environment is in place, and ancillary applications (such as diaries, calendars, e-mails and notebooks) have been built or have been made. All of these components are being used by students, and each application runs on its own server.

Customers now want to be able to access these applications remotely through a Web browser, so to build a portal to provide a single entry into the application, the portal should provide the user with a single sign-on capability. After the user logs in, authenticates his identity, and then he is able to access all authorized resources in the portal.

I decided to search for information on how to implement the SSO scenario and find helpful white papers, products, and open source projects. I use the following criteria to limit the scope of the search: Java implementation. This portal application infrastructure is Java-based, so I want the SSO implementation to be based on the Java language as well. Easy to implement. In this scenario, easy implementation means that there is no need to make extensive changes to the infrastructure or existing applications. The effect has been proven. It should have been adopted by a number of large organizations and is still in an active development phase. Compatible with LDAP. Our customers use Microsoft Active Directory Server, so I need the system to be able to easily authenticate against ADS.

I am delighted to find several excellent open source projects. (See the list in resources.) ）

I started using a CAS (central authentication Service) system from Yale University to develop a prototype because it met all of my conditions. It is Java-based and the source code is open. Just using JSP tags and servlet filters makes it fairly easy to implement in a Java application environment. Yale University is using it, which shows that its quality meets my conditions. It also allows you to easily change or extend the actual authentication mechanism (whether it is querying the database or the user name and password on the LDAP server).

Home Page Top CAS Overview

Note that when using the CAS protocol, the application does not see the user's password. The CAS server performs authentication, and only it can see the user's password. This increases security because the user name and password are not passed over the network to other applications.

The following figure illustrates how authentication is performed in a system that integrates a CAS server. Figure 1. How CAS protocols perform authentication

The following are the main steps in this authentication protocol. The user tries to access the application using the URL of the application. The user is redirected to the CAS login URL, using an HTTPS connection, and the name of the service he is requesting is passed as a parameter. A User name/password dialog box is displayed to the user. The user enters the ID and password, and the CAS authenticates him. If authentication fails, the target application will never know that the user has tried to access it-the user was stopped on the CAS server. If authentication succeeds, CAS redirects the user back to the target application and appends a parameter called ticket to the URL. Then, CAS tries to create a memory cookie called the ticket-granting cookie. This is for automatic re-verification in the future, and if this cookie exists, it means that the user has successfully logged in and the user does not need to enter his username and password again. The application then checks to see if the ticket is correct, and whether it represents a valid user, by opening an HTTPS connection to invoke the Casservicevalidate URL and passing the ticket and service names as parameters. CAS checks whether the ticket is valid and is associated with the requested service. If the check succeeds, CAS returns the user name to the application.

If you develop with the Servlet 2.3 specification, you don't even need to worry about these steps. A servlet filter will handle the entire protocol. All you have to do is configure the filter parameters in the Web. xml file. That's how I do it-it means that there is very little modification to the application code in the portal.

In-depth discussion of CAS is beyond the scope of this article, and I recommend that you read articles from Yale University that are listed in resources to determine whether this authentication scheme meets your needs.

Back to top CAS Getting Started

Setting up the CAS software is very simple, but before you start setting up, you should be aware of some of the software I use. I only tested CAS with Tomcat 4.1, Java development Kit 1.4, and Ant 1.5. (The files and client libraries mentioned here can be downloaded from resources.) ）

First, download the CAS server and client library. Customer libraries have been developed for many languages and environments, including Java, ASP, Perl, PHP, and PL/SQL.

CAS uses HTTPS, so this feature must be enabled in Tomcat. I find it a bit tricky, but it shouldn't be difficult to follow the instructions I've provided (Readme_tomcat_ssl.txt file).

Unzip the CAS server ZIP file and use the Ant build script to build the CAS server software. Deploy the WAR file (Web Archives) to the Tomcat/webapps directory. When you start Tomcat, use the WAR file to create a CAS directory in Tomcat/webapps.

Download the CAS client library. Unzip the ZIP file and you'll see a number of directories. I'm going to use the Java client library. The Ant build script is also available. Run the build script. This generates a jar file called Casclient.jar. Copy this file to the Common/lib directory in the Tomcat root directory.

Now, you need to configure your application to use CAS. The application for demonstration in this article is an example of a reliable "HelloWorld" servlet provided by Tomcat. This application should be under the/webapps/examples directory in the Tomcat system. Modify the Web. xml file to configure the servlet filter.

The Web. xml file for the

HelloWorld JSP contains the following servlet filter configuration. It uses local host and port 8443 for HTTPS. Modify these settings according to your own configuration. The zip file I provide contains an example of the Web. xml file. Listing 1. Default servlet filter configuration for HelloWorld JSP

<filter> <filter-name>cas filter</filter-name> <filter-class>edu .yale.its.tp.cas.client.filter.casfilter</filter-class> <init-param> <param-name>edu.yale.its. Tp.cas.client.filter.loginurl</param-name> <param-value>https://localhost:8443/cas/login</ param-value> </init-param> <init-param> <PARAM-NAME>EDU.YALE.ITS.TP.CAS.CLIENT.FILTER.V Alidateurl</param-name> <param-value>https://localhost:8443/cas/proxyValidate</param-value> &L T;/init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.servername</param-na me> <param-value>localhost</param-value> </init-param> </filter> <filter-mapp ing> <filter-name>cas filter</filter-name> <url-pattern>/*</url-pattern> </filter- Mapping> 

Start Tomcat. Then enter the URL http://localhost/examples/servlet/HelloWorldExample. This will redirect you to the CAS login screen. The default authenticator only requires that you provide the same string for the user name and password, for example, to enter a demo in two domains. Then, you are redirected to the HelloWorld page.

This is a simple CAs demo, but it shows how easy it is to make existing Java servlet applications use CAS by using this powerful servlet filter. You can also use JSP tag sets instead of servlet filters, which are suitable for applications or application servers that cannot use servlet filters.

Back to top Active Directory Server authentication

In my Education portal project, it's easy to modify the application because I can get the source code. I used a servlet filter in each application. In this case, CAS will perform authentication when the user first accesses the portal and requests a restricted application or data source. After authentication succeeds, the CAS servlet filter can examine the ticket and pass the user name as a parameter to the requesting application. I have modified the existing application logon screen to receive the user name parameters from CAS after successful authentication. The application can then use this parameter to authorize the user and audit records of the user's activity.

However, the CAS itself does not come with any really useful authenticator. The default authenticator simply checks that the user name and password are the same. In the Education Portal project, I use Microsoft's Active Directory Server to store the user's personal information. So I need to extend the CAS server to check the user name and password against Active Directory server.

CAS designers of Yale University developed an pluggable authenticator architecture. By extending the Passwordhandler interface, developers can create a class to implement password-checking logic. Listing 2. Pluggable Authenticator schema for CAS

/** 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 have to do is learn how to use Active Directory Server to check the user name and password, create a class to extend the interface, and add code that performs the authentication.

ADS is a directory server that is compatible with LDAP3. It supports many different authentication methods, mainly including anonymous (anonymous), simple, and SASL (easy authentication and Security Layer). Anonymous authentication is not appropriate for my project; Simple authentication sends passwords in clear text, which is not sufficient. So I use SASL.

The SASL supports pluggable authentication. This means that LDAP clients and servers can be configured to negotiate with each other and use one of several authentication mechanisms. The following is part of the current definition SASL mechanism: Anonymous cram-md5 digest-md5 External Kerberos V4 Kerberos V5 SecurID Secure Remote Password s/key X .509

Among these mechanisms, popular LDAP servers (such as Sun, OpenLDAP, and Microsoft-provided servers) support External, DIGEST-MD5, and Kerberos V5.

CAS itself is similar to Kerberos, and they have many of the same concepts, such as ticket and Ticket-granting ticket (which are actually called ticket-granting cookies in CAS), and their protocols are similar. Therefore, it seems natural to choose the Kerberos mechanism. In addition, the addition of support for Kerberos authentication allows CAs to represent users in future development as a WEB-based Kerberos proxy, which enables CAs to manage all aspects of Kerberos ticket for users. This means that remote users can also access local and network resources using the same Kerberos authentication mechanism.

The Kerberos protocol is already built into ADS and Windows 2000/xp. The Java authentication and Authorization Service (JAAS) provides an implementation of the Kerberos Login Module (a tutorial in resources lists a detailed description of how to build a sample application). To be precise, it is the Gss-api SASL mechanism, but it provides Kerberos v5 authentication only for LDAP3 servers.

Kerberos authentication is a simple process (if you follow these instructions carefully): Configure the Login Module for the application class in the JAAS configuration file.

Edu.yale.its.tp.cas.auth.provider.KerberosAuthHandler  
{
com.sun.security.auth.module.Krb5LoginModule Required client=true;
};

Creates a logincontext that passes the name of the class that performs the authentication and the CallbackHandler object.

LoginContext LC = New LoginContext (CASApp.class.getName (), 
                    new Cascallbackhandler ());

Call the login () method to perform authentication. If the execution process is not an exception, authentication succeeds. If an exception is thrown, the exception indicates the cause of the failure.

To learn more about Kerberos authentication, we recommend that you take advantage of the resources at the end of this article. (I also provided my own implementation and configuration files, Kerberosauthhandler and Cascallbackhandler. ）

You need to create a new Passwordhandler implementation, Kerberosauthhandler, which follows the above method to authenticate against Active Directory Server that uses Kerberos v5. Listing 3. Creating a new Passwordhandler implementation

public class Kerberosauthhandler implements Passwordhandler {public Boolean authenticate (JAV  Ax.servlet.ServletRequest request, string Username, string
	
    Password) {logincontext LC = NULL; try {/* Set up the Callback handler, and initialise */* The UserID and Password fields */Cascallbackhandle
	   R ch = new Cascallbackhandler ();
   	   Ch.setuserid (username);
		
	   Ch.setpassword (password); /* initialise the login context-loginmodule configured */* in cas_jaas.conf and/*/set to use KRB

	   5LoginModule. */lc = new LoginContext (KerberosAuthHandler.class.getName (), ch);

    /* Perform the authentication */Lc.login ();
     } catch (Loginexception le) {System.err.println ("Authentication attempt failed" + le);
    return false;

  } return true; }
}

This class name and Cascallbackhandler object are passed when the LoginContext is created. The JAAS configuration file specifies the login module used by this class.

When invoking the login () method, the login module knows what information it needs to obtain from the user/application in order to authenticate. When Kerberos is used, it requires a user name and password, so it constructs an array that contains two callback objects (NameCallback and PasswordCallback), and then calls the CallbackHandler object, This object determines how these callbacks are executed and obtains the user name and password.

I use the setter method on CallbackHandler to set the user ID and password explicitly in the simplest and most advantageous way. The CallbackHandler then pass them to the NameCallback and PasswordCallback objects. Listing 4: Setting the ID and password with SetName (Casuserid) and SetPassword (Caspassword)

public class Cascallbackhandler implements CallbackHandler {private String casuserid;

    Private Char [] caspassword;  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 (Caspassword);
		} else {throw new unsupportedcallbackexception (Callbacks[i]);
    }}} public void Setuserid (String userid) {casuserid = userid;
	public void SetPassword (String password) {Caspassword = new char[password.length ()];
    Password.getchars (0, Caspassword.length, Caspassword, 0); }

The next thing to do is to have CAS use the new authentication processor. This is done by using the following settings in the Web. xml file of the CAS server in Webapps/cas: listing 5. Let CAs use the new authentication processor

<!--Authentication Handler--
    <context-param>
        <param-name> edu.yale.its.tp.cas.authhandler</param-name>
        <param-value>
             Edu.yale.its.tp.cas.auth.provider.KerberosAuthHandler
        </param-value>
    </context-param>

A ZIP file (Kerberosauthsrc.zip in resources) contains a Web. XML example.

You must restart Tomcat, but this time you will need to set some Java runtime properties. Unzip the ZIP file (kerberosauthsrc.zip) and copy the files cas_jaas.conf, krb5.conf, and Setkerberosjvmoptions.bat to the Tomcat_home directory. Run Setkerberosjvmoptions.bat, and then start Tomcat.

Now, you can experiment with the HelloWorld application again. This time, you can use a valid Kerberos user name and password pair that is defined in active Directory Server.

Back to top concluding remarks

Without a unified strategy, developers will have to replicate the security mechanisms that are customized for each network application. This can lead to various scalability and maintenance issues. The single sign-on solution provides a unified framework for security and authentication, which greatly reduces the burden on users, administrators, and developers.

The concept, technology, and implication of single sign-on are complex for users and administrators, and I have only scratched the surface of this field. However, I explained how to use the CAS system of Yale University to implement a single sign-on scenario, and also described in detail how to extend this technology to LDAP Server users (specifically, Active Directory server that uses the Kerberos protocol ) for authentication.