Integrated Windows Authentication (IWA) provides a user-friendly interface for single sign-on. IWA uses ‘Simple and Protected GSSAPI Negotiation Mechanism' (SPNEGO) to allow the initiators and acceptors to negotiate the underlying protocol to be used for authentication. In this article, we will discuss how to enable SPENGO to support single sign-on for a two-tier web based application using the popular Spring framework.

Even though we only focus on a two-tier application, there are multiple places in these two tiers that SPNEGO needs to be enabled. At the client side, we need the client code to require the use of the SPNEGO protocol; we need to enable the Spring HTTP Invoker to use the HTTP 4.0.1 client, which needs to be SPNEGO enabled. At the server side, we need to configure the application server to support SPNEGO and we need to secure the Spring web application using SPNEGO protocol.

The Sample Application
The sample application used in this article retrieves a message such as "Hello world" from the server. The client uses the Spring HTTP Invoker to access the server application. It will first retrieve a Spring HelloWorld bean, then it will retrieve the message defined on that Spring bean. The Spring bean is a secured resource; it's configured to be protected by the container-managed security and the SPNEGO protocol for authentication. In order for the client to log on to the server, the client's Windows credential will be used for the authentication. The detailed authentication process can be described as follows:

• The server authenticates itself to the security domain controller such as Microsoft Active Directory.
• The client accesses a secured resource and wants to negotiate the security mechanisms using SPNEGO. The negotiated protocol could be Kerberos or NTLM.
• The server sends back the challenge and the mechanism to use to the client.
• The client uses its Windows credential to get a SPNEGO token from the security domain controller such as Microsoft Active Directory.
• The client sends the SPNEGO token to the server.
• The server uses its own SPNEGO ticket to decode the client's token and responses to the client.

This process can take several round-trips for the client to authenticate to the server.

The Un-Secure Implementation
Before attempting to secure the sample application with SPENGO, let's understand how the application is implemented using Spring and the Spring HTTP Invoker without security.

Let's start from the server side. As described in Pro String [2], the following areas are needed to build a Spring service-based web application that uses the HTTP Invoker architecture.

Create the Service Interface and Implementation
We will define an interface, an implementation and a bean. These are simple POJO classes. The interface defines one method:

public HelloWorldBean getHelloWorld();

For the Hello world implementation, we do not return a "Hello World" string. Instead, we return a HelloWorldBean.

public HelloWorldBean getHelloWorld() {
HelloWorldBean helloBean = new HelloWorldBean();
helloBean.setMessage("Hello World");
helloBean.setSender("Zhiyong Li");
return helloBean;
}

The "Hello World" message can be retrieved from the bean when its "toString" method is called.

public class HelloWorldBean implements Serializable {
private String message;
private String sender;
public String getMessage() { return message; }
public void setMessage(String message) { this.message = message;}
public String getSender() { return sender;}
public void setSender(String sender) { this.sender = sender; }
public String toString() {
return "Message: " + message + " from \"" + sender +"\".";
}
}

The above bean class can be easily expanded to provide other business logic instead of simply returning the "Hello World" message.

Configure an Instance of HttpInvokerServiceExporter

The Hello World service needs to be made available for the client to consume. This is achieved by exporting the service through the HttpInvokeServiceExporter defined in httpinvoker-servlet.xml.

<bean name="/helloWorldService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
<property name="service">
<ref bean="helloWorldService"/>
</property>
<property name="serviceInterface">
<value>com.sas.iwa.sample.server.HelloWorldService</value>
</property>
</bean>

The service bean in the above definition is defined in the applicationContext.xml file that specifies the actual implementation class for the service.

<bean id="helloWorldService" class="com.sas.iwa.sample.server.HelloWorldImpl"/>

Configure an Instance of Spring DispatcherServlet
To make this Spring application a web application, we need to use the Spring dispatcher servlet. This servlet dispatches and invokes the appropriate services based on the requested URL. The corresponding XML piece that defines the dispatcher servlet in the web.xml is shown below:

<web-app>
<servlet>
<servlet-name>httpinvoker</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>3</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>httpinvoker</servlet-name>
<url-pattern>/http/*</url-pattern>
</servlet-mapping>
</web-app>

Now let's look at the client side. At the client side, we configure to use the HTTP Invoker proxy bean as shown below. The proxy handles all the communication details between the client and the remote Spring services that are deployed in the application server. The service URL has several parts. The "HelloWorld" after the "machinename:port" is the context root of the web application. The service that will be accessed is the last part of the URL "helloWorldService" and its interface is called HelloWorldService.

<beans>
<bean id="helloWorldService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl">
<value>http://localhost:8080/HelloWorld/http/helloWorldService</value>
</property>
<property name="serviceInterface">
<value>com.sas.iwa.sample.server.HelloWorldService</value>
</property>
</bean>
</beans>

Since the proxy handles all the communication details, the client code is very simple (see below). It uses the above configuration information defined in the HelloWorld.xml to get the application context. The context is used to get the "helloWorldService" service interface and then its method of "getHelloWorld" is called. The "getHelloWorld" returns the "HelloWorldBean". The "toString" method of the bean is called and the result is printed out.

public static void main(String[] args) {
ApplicationContext ctx = new FileSystemXmlApplicationContext(
"helloworld/conf/http/HelloWorld.xml");
HelloWorldService helloWorld = (HelloWorldService)ctx.getBean("helloWorldService");
System.out.println(helloWorld.getHelloWorld());
}

Secure the Application with SPNEGO
Next we'll use SPNEGO to secure the sample applications. Figure 1 shows the different parts of the applications where SPNEGO needs to be enabled. Specifically, the orange and yellow colored components need to be enabled with SPENGO. Let's discuss the server side first.

The Server Side
At the server side, we need to configure SPNEGO support for JBoss. The "User Guide for JBoss Negotiation" discusses in detail how to accomplish this.[4] In addition, we need to configure container-managed security to secure the "Hello World" service. This can be done by adding the security constraint to the web.xml as shown in Listing 1. (The listings can be downloaded here.) In that list, the auth-method is "SPNEGO". This value should match the name of the "Authenticator" defined in JBoss jboss-service.xml for using "SPNEGO" authentication protocol. "SASWebUser" is a role that can be used for the role-based access security.

We also need to add another JBoss-specific jboss-web.xml file to specify which security domain (also called application policy) should be used for this Hello World application. The jboss-web.xml is listed below, where the "java:/jaas/SPNEGO" is the application-policy described in the "User Guide for JBoss Negotiation."[4] If you have followed that document, that application policy should have already been defined in login-config.xml in your deployed JBoss.

<?xml version="1.0" encoding="US-ASCII"?>
<!-- File containing settings specific to the JBoss application server -->
<jboss-web>
<context-root>HelloWorld</context-root>
<security-domain>java:/jaas/SPNEGO</security-domain>
</jboss-web>

The SPNEGO application policy also uses the role definition file, for example, spengo-roles.properties. If you have a user such as sasdemo who will log on, that user needs to have role SASWebUser, which is defined in the above mentioned properties file as follows:

sasdemo@BCI.SAS.COM=SASWebUser
sasdemo=SASWebUser

The Client Side
The default HTTP client used by the Spring HTTP Invoker is the HTTP client shipped with the JDK. That HTTP client does not support SPENGO authentication (or any authentication mechanisms). We can also configure Spring to use the Commons HTTP client by using Spring CommonsHttpInvokerRequestExecutor. However, the current Spring implementation only supports Commons HTTP 3.x client. That client does not support SPNEGO either. We have two options for addressing this issue:

• We can enhance the Commons HTTP client to support SPENGO. There is an open source SPNEGO implementation for it. However, that implementation only supports the HTTP client GetMethod. Spring relies on the HTTP client PostMethod. There is no easy solution to get the package to work with the PostMethod. HTTP Kerberos support [5] includes additional information.
• We can try to use the Commons HTTP 4.0.1 client. There is an open source SPNEGO implementation for the HTTP 4.0.1 client as well. However, Spring does not support the HTTP 4.0.1 client in its 2.x and 3.x releases. More specifically, it does not provide an HTTP Invoker request executor for the HTTP 4.0.1 client.

We decided to pursue the second approach. We will port CommonsHttpInvokerRequestExecutor for the HTTP 4.0.1 client and use the open source HTTP Kerberos support as described in HTTP Kerberos support for the HTTP 4.0.1 client. The new Commons40HttpInvokerRequestExecutor is included in the source code that you can download. The HTTP Kerberos support requires two configuration files: one for Kerberos support and another for the JAAS login module. The first file is provided in Listing 2 and should be updated based on your specific configuration. The second file for the JAAS login module is listed below.

com.sun.security.jgss.login {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true;
};
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true;
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true debug=true;
};

Further, the HTTP Invoker needs to update the HTTP context to use the NEGOTIATION schema; this is accomplished by sub-classing Commons40HttpInvokerRequestExecutor and overwriting its createHttpContext method. The code is provided in Listing 3. We also need to change the proxy factory bean so that it can provide an HTTP client that is configured to use the NEGOTIATION protocol. That code is in Listing 4. The key method in that class is "afterProperteisSet", which sets up the Kerberos specific properties and also sets "negotiate" as the authentication schema. You may notice that we define one of the Kerberos properties "sunSecurityKrb5Debug" as an instance variable. The purpose is to allow that value to be able to be overwritten in the Spring configure file. Other Kerberos properties in Listing 4 can be defined the same way as well.

We can now configure the requestExecutor at the Spring configuration file using the two classes discussed above.

<bean id="helloWorldService" class="org.springframework. remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
value = "http://windowpain.bci.sas.com:8080/HelloWorld/http/helloWorldService"/>
<property name="serviceInterface"
value = "com.sas.iwa.sample.server.HelloWorldService" />
<property name="httpInvokerRequestExecutor">
<ref local="requestExecutor"/>
</property>
</bean>
<bean id="requestExecutor" class="com.sas.security.auth.Commons40NegotiateHttpInvokerRequestExecutor">
<property name="httpClient">
<bean class="com.sas.security.auth.KerberosHttpClient40FactoryBean">
<property name="sunSecurityKrb5Debug" value="true" />
</bean>
</property>
</bean>

When "HelloWorld/http/helloWorldService" is requested, instead of using the default requestExecutor that uses the JDK's HTTP client, we have instrumented Spring to use our customized requestExecutor, which will use the HTTP 4.0.1 client and the customized SPNEGO-aware HTTP client factory bean. You may also notice the property sunSecurityKrb5Debug for KerberosHttpClient40FactoryBean in requestExecutor. That property definition allows us to turn on/off the debug from the Spring configuration file.

Of course, we need to update our client code HelloWorldClient to use this configuration file. This is a one-line change to our client code:

ApplicationContext ctx = new FileSystemXmlApplicationContext(
"helloworld/conf/http/iwaHelloWorld.xml");

Configure and Run the Sample Application
The sample application is packaged into two files: the client zip file IWA-HelloWorld.zip contains all source code and the required JARs. The hello.bat in the client zip file can be invoked to run the example. The server-side code is packaged into a war file, HelloWorld.war, and you need to deploy it to JBoss. However, before the example can be executed, you need to configure JBoss to support SPNEGO.

If you use JBoss 4.x such as 4.2.0, the SPNEGO is not packaged. You will need to download the jboss-negotiation by following the instructions in "User Guide for JBoss Negotiation." [4] To configure JBoss to support SPNEGO, you need to follow the JBoss negotiation document as well.

When following the JBoss negotiation document, make sure the name of the negotiation method in jboss-service.xml is "SPENGO" and the application-policy in jboss-login.xml is also "SPNEGO".

The Spring jar, the HTTP 4.1 client and the HTTP 4.1 Kerberos support have been packaged into the client zip file IWA-HelloWorld.zip. Since Kerberos support requires Java 6, Java 6 is required to run the client code.

You can download the source code for the sample application from the Resources Section. The sample application was deployed and tested on JBoss application server 4.2.0.

Conclusion
IWA is a powerful and user-friendly approach to secure your enterprise applications. However, to configure and implement such a system is a rather complicated process. This article has demonstrated the technologies involved and how to use them together to develop such an application using the popular Spring framework. Interested readers should be able to use the process and the code described in this article to develop their own IWA-enabled applications.

If your application has more than two tiers and you want to pass the client credential through the mid-tiers, you'll need the additional technology called "delegation." SPNEGO authentication and credential delegation with Java [6] has an example on how to implement the delegation. Finally, recently the Spring Security Kerberos Extension reached its first milestone. [7] Interested readers can decide whether that approach works for you.

Resources

1. Download the client and server sample applications for this article here and here.
2. Pro String, written by Rob Harrop and Jan Machacek, has a very good description about the Spring HTTP Invoker and the sample implementations.
3. JBoss application server can be downloaded from here.
4. User Guide for JBoss Negotiation contains the instructions on how to configure JBoss to support SPNEGO negotiation mechanism. The SPNEGO support for JBoss is packaged in a single jar: jboss-negotiation.jar.
5. HTTP Kerberos support for HTTP Client 4.0.1 is described here. The contents of this zip file httpclient4kerb20090710.zip have been included in this article's sample application download.
6. SPNEGO authentication and credential delegation with Java
7. Spring Security Kerberos / SPNEGO Extension
8. For Java 6 security features including SPNEGO support, refer to: http://java.sun.com/javase/6/docs/technotes/guides/security/index.html