dotNetInstaller 1.10 was released July 12th, 2010. dotNetInstaller is a very popular general purpose setup bootstrapper for Microsoft Windows created by Davide Icardi. I’ve been maintaining the project and contributing the vast majority of the features since 2008, mostly driven by our needs at work.

> Download

Here’re some highlights in this release.

• Added support for executable components with an optional response file and installation directory.
• Added lots of convenience features in Installer Editor, such as remembering configuration files.
• Added os_filter that behaves like lcid_filter for operating system IDs.
• Added user-defined image control.
• Holding the keyboard Control key and double-clicking on a bootstrapper component will install it, regardless of whether the component is selected or not.
• Added /ProcessorArchitecture:list to InstallerLinker to link an installer targeting a specific platform architecture.

The next release (2.0) should be very exciting as I’ve been prototyping an HTML-based installer that gives users full control of the bootstrapper UI. Stay tuned.

WAFFLE exposes native Windows authentication facilities to C# and Java clients using JNA. Version 1.3 has shipped Wednesday, July 21, 2010. WAFFLE has seen incredible interest and production adoption in the last few months as I’ve coded a bunch of Java filters > Download 1.3.

• If you’re writing PInvoke in C# or Java code for Windows authentication, save yourself some time, WAFFLE has these features for you:
• Account lookup locally and in Active Directory via Win32 API with zero configuration.
• Enumerating Active Directory domains and domain information.
• Returns computer domain / workgroup join information.
• Supports logon for local and domain users returning consistent fully qualified names, identity (SIDs), local and domain groups, including nested.
• Supports all functions required for implementing server-side single-signon with Negotiate and NTLM.
• Supports Windows Identity impersonation.
• Includes a Windows Installer Merge Module for distribution of C# binaries.
• If you're using Tomcat or Jetty with an IIS front-end to do authentication only, Waffle has the following features and will allow you to get rid of IIS:
• A Tomcat Negotiate (NTLM and Kerberos) Authenticator Valve - Tutorial.
• A generic Servlet Negotiate (NTLM and Kerberos) Security Filter - Tutorial.
• A Tomcat Single Sign-On + Form Authentication Mixed Valve - Tutorial.
• A Spring-Security Negotiate (NTLM and Kerberos) Filter - Totorial.
• A Spring-Security Windows Authentication Manager.
• A JAAS Login Module - Tutorial.

WAFFLE has originated at AppSecInc. and the team deserves the credit. John has a blog too, check it out.

In this post I’ll explain how to configure the Waffle Spring-Security Negotiate filter to do single-sign-on on Windows and touch on how much more elegant the spring-based filter configuration is versus, for example, the generic servlet filter.

Download

Download Waffle 1.3. The zip contains Waffle.chm with the latest version of this tutorial.

Configure Your Application

Configure Spring-Security

We'll assume that Spring-Security is configured via web.xml with a filter chain and a Spring ContextLoaderListener. The Waffle beans configuration will be added to waffle-filter.xml.

1. <filter>
2.     <filter-name>springSecurityFilterChain</filter-name>
3.     <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
4. </filter>
5. <filter-mapping>
6.     <filter-name>springSecurityFilterChain</filter-name>
7.     <url-pattern>/*</url-pattern>
8. </filter-mapping>
9. <context-param>
10.     <param-name>contextConfigLocation</param-name>
11.     <param-value>/WEB-INF/waffle-filter.xml</param-value>
12. </context-param>
13. <listener>
14.     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
15. </listener>

Package Files

You need waffle-jna.jar, jna.jar, platform.jar and commons-logging-1.1.1.jar from the Waffle distribution as well as Spring and Spring-security JARs. Those should be placed in your application’s classpath (eg. packaged in WAR). If you’re using Tomcat, for demo purposes you can put these files in Tomcat’s lib.

Windows Authentication Provider

Declare a Windows Authentication provider. This is the link between Waffle and the operating system.

1. <bean id="waffleWindowsAuthProvider" class="waffle.windows.auth.impl.WindowsAuthProviderImpl" />

Waffle Security Filter Providers

Declare a collection of Waffle security filter providers that implement various authentication protocols.

1. <bean id="negotiateSecurityFilterProvider" class="waffle.servlet.spi.NegotiateSecurityFilterProvider">
2.   <constructor-arg ref="waffleWindowsAuthProvider" />
3. </bean>
4.  
5. <bean id="basicSecurityFilterProvider" class="waffle.servlet.spi.BasicSecurityFilterProvider">
6.   <constructor-arg ref="waffleWindowsAuthProvider" />
7. </bean>
8.  
9. <bean id="waffleSecurityFilterProviderCollection" class="waffle.servlet.spi.SecurityFilterProviderCollection">
10.   <constructor-arg>
11.     <list>
12.       <ref bean="negotiateSecurityFilterProvider" />
13.       <ref bean="basicSecurityFilterProvider" />
14.     </list>
15.   </constructor-arg>
16. </bean>

If you’re not very familiar with Spring, you will start loving it right here. We’re adding two providers to a collection in a configuration file. This means that we don’t need to have another configuration mechanism than this one to add or remove one. We don’t need to do this in code either. Each class instance (bean) is also configurable individually – we can, for example, configure the name of the realm for Basic authentication.

1. <bean id="basicSecurityFilterProvider" class="waffle.servlet.spi.BasicSecurityFilterProvider">
2.   <constructor-arg ref="waffleWindowsAuthProvider" />
3.   <property name="Realm" value="DemoRealm" />
4. </bean>

It’s more verbose, but it’s much more flexible.

Add a Waffle Security Filter

Add the Waffle security filter and entry point to the sec:http configuration section. The filter will be placed before the Basic authentication filter that ships with Spring-Security. The filter uses the collection of authentication filter providers defined above to perform authentication.

1. <sec:http entry-point-ref="negotiateSecurityFilterEntryPoint">
2.   <sec:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY" />
3.   <sec:custom-filter ref="waffleNegotiateSecurityFilter" position="BASIC_AUTH_FILTER" />
4. </sec:http>
5.  
6. <bean id="negotiateSecurityFilterEntryPoint" class="waffle.spring.NegotiateSecurityFilterEntryPoint">
7.   <property name="Provider" ref="waffleSecurityFilterProviderCollection" />
8. </bean>

Spring-Security Authentication Manager

Define a required default Spring-Security authentication manager. We’re not going to use it in this setup because the filter takes care of authentication and the user doesn’t have a way to supply, for example, a username and password.

1. <sec:authentication-manager alias="authenticationProvider" />

Note that Waffle does include a Spring-based authentication manager for form-based authentication or non-web-based scenarios.

The Filter Itself

Finally, define the Spring-Security Waffle filter that uses the collection of security filter providers to perform authentication.

1. <bean id="waffleNegotiateSecurityFilter" class="waffle.spring.NegotiateSecurityFilter">
2.   <property name="Provider" ref="waffleSecurityFilterProviderCollection" />
3. </bean>

Demo Application

A demo application with the complete configuration file can be found in the Waffle distribution in the Samples\waffle-spring-filter directory. Copy the entire directory into Tomcat's webapps directory and navigate to http://localhost:8080/waffle-spring-filter/. You should be automatically logged-in under your current Windows account.

You can also see/browse the configuration source code here.

Links

• Spring-Security
• Waffle

I never remember how to do this, so here’s a refresher. In MSBuild you can easily define a list with properties and iterate over it.

Run the sample above with msbuild test.proj /t:ShowSquirrels.

Take Hyperic SIGAR, a very popular Java API that lets you collect system information. It has two major drawbacks.

1. It uses a native library (eg. hyperic-sigar-x86.dll), which you have to install separately from your application’s jar/war.
2. It’s GPL v2. My legal department immediate flagged that as a no-go since we’re a commercial product.

Sounds like we could live with the first problem, but we can’t live with the second. Licensing is a pest.

While we’re at it, we should be able to leverage JNA and fix the first problem too. In the end we could end up with a very nice library that lots of people use.

Oshi Project

Introducing the Oshi Project. I’ve put a day of work into it and a bit of design thought in terms of operating system and hardware interfaces. I’ve implemented those for Windows, so it can generate this kind of output.

Here’s the code for the above.

What’s Next?

Give Oshi a try, http://oshi.codeplex.com/.

Oshi needs your help to implement *nix ports and create interfaces for other types of software and hardware information, such as disks, processes, printers, etc. Some of the functionality may be generic and should be pushed into JNA.

I’ve written an unusually high number of unit tests for the Java portion of Waffle, mostly because the project became popular really fast with all those Java people trying to do Windows authentication. Some have succeeded and some filed several rather complicated bug reports that dealt with concurrency, sessions across HTTP requests, etc. It all needed to be unit-tested in order to make industrial-grade software.

If you asked me yesterday, I would have said that Waffle unit tests cover 99% of the code. But Emma says otherwise, and it’s probably right.

Running Emma with JUnit

It took me half an hour to integrate Emma. Pretty easy. You should do it too.

I downloaded Emma from http://emma.sourceforge.net and added it to ThirdParty/emma. What I want next is a cover target that can execute all unit tests with code coverage. We’re doing this in ANT with JUnit.

Define Emma JARs Location and ClassPath

Instrument Files

I went the route of not changing my build tasks and instrumenting the .class files already built. Then I swap in those files with the instrumented ones. Note that Emma only generates .class files for instrumentable classes – those not containing debugging information, interface definitions and such aren’t included.

Running Tests

The tests are run the same way as before, but we need to tell Emma where to write its output.

Generating an EMMA Report

Finally, we want to get a nice HTML document that summarizes coverage.

Here’s an output.

I see a lot of red. Emma doesn’t think I am doing such a great job after-all.

Links

• EMMA on SourceForge
• Waffle Build.xml with Emma Coverage