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 

I’ve uploaded a PowerPoint presentation about Waffle that I made to my team. It can be a good start for talking points and a presentation about Windows authentication in Tomcat, Jetty, etc.

I often hear from people that Microsoft sucks. When I worked there I found it funny.

I recently had a recurrent crash in Visual Studio 2008. I would switch to the HTML design view (ASP.NET application or simple HTLM page) et voila, crash. Annoying, to say the least. The call stack ended up somewhere in MFC and didn’t look promising. I spent a lot of time being frustrated until this morning, when I decided to actually do something about it.

Microsoft has active forums for all its software. Visual Studio 2008 forum is here: http://forums.asp.net/1112.aspx. Turns out that one of the existing hotfixes seemed related to the area where I was seeing the crash. I downloaded and installed it, the problem went away. It also looks like if it didn’t, I could get a very reasonable turn-around on the forum after reporting a crash as someone is being paid to work the forum and collect issues, publish announcements and patches. No annoying forms and no calling on the phone some entry-level support person on the other side of the planet. It’s a developer-to-developer relationship and this is exactly how I like it.

Most Tomcat users begin by implement Form-based authentication. Those deploying applications into enterprises soon discover that those enterprises use an Active Directory and have single sign-on on all intranet sites. They eventually find Waffle, but don’t want to take the ability to do form-based logon away.

How do we give users a way to logon either way?

You can accomplish this with the Waffle MixedAuthenticator.

Configure Tomcat

Download and Copy Files

Download Waffle 1.3 and copy waffle-jna.jar, jna.jar and platform.jar to Tomcat's lib directory.

Configure Mixed Authenticator Valve

Add a valve and a realm to the application context. For an application, modify META-INF\context.xml.

1. <?xml version='1.0' encoding='utf-8'?>
2. <Context>
3.   <Valve className="waffle.apache.MixedAuthenticator" principalFormat="fqn" roleFormat="both" />
4.   <Realm className="waffle.apache.WindowsRealm" />
5. </Context>

Security Roles and Constraints

Configure security roles in WEB-INF\web.xml. The Waffle Mixed Authenticator adds all user's security groups (including nested and domain groups) as roles during authentication.

1. <security-role>
2.   <role-name>Everyone</role-name>
3. </security-role>

Restrict access to website resources.

1. <security-constraint>
2.     <display-name>Waffle Security Constraint</display-name>
3.     <web-resource-collection>
4.       <web-resource-name>Protected Area</web-resource-name>
5.       <url-pattern>/*</url-pattern>
6.     </web-resource-collection>
7.     <auth-constraint>
8.       <role-name>Everyone</role-name>
9.     </auth-constraint>
10.   </security-constraint>

Add a second security constraint that leaves the login page unprotected.

1. <security-constraint>
2.     <display-name>Login Page</display-name>
3.     <web-resource-collection>
4.       <web-resource-name>Unprotected Login Page</web-resource-name>
5.       <url-pattern>/login.jsp</url-pattern>
6.     </web-resource-collection>
7.   </security-constraint>

Configure Form Login

Configure Form Login parameters with the location of the login page (repeated from the security constraint above) and an error page for failed logins. Modify WEB-INF\web.xml.

1. <login-config>
2.    <form-login-config>
3.       <form-login-page>/login.jsp</form-login-page>  
4.       <form-error-page>/error.html</form-error-page>  
5.    </form-login-config>
6. </login-config>

Login Page

Create a login page based on the following code. There're two requirements for the login form. The form-based authentication must post to any valid location with the j_security_check parameter. The destination page will be loaded after a successful login. The single sign-on form must similarly post to any valid location with the j_negotiate_check parameter in the query string.

Here’s a rudimentary example that lands an authenticated user on index.jsp.

1. <form method="POST" name="loginform" action="index.jsp?j_security_check">
2.     <table style="vertical-align: middle;">
3.         <tr>
4.             <td>Username:</td>
5.             <td><input type="text" name="j_username" /></td>
6.         </tr>
7.         <tr>
8.             <td>Password:</td>
9.             <td><input type="password" name="j_password" /></td>
10.         </tr>
11.         <tr>
12.             <td><input type="submit" value="Login" /></td>
13.         </tr>
14.     </table>
15.     </form>
16.     <hr>
17.     <form method="POST" name="loginform" action="index.jsp?j_negotiate_check">
18.     <input type="submit" value="Login w/ Current Windows Credentials" />
19.     </form>

Demo

A demo application can be found in the Waffle distribution in the Samples\Tomcat\waffle-mixed directory. Copy the entire directory into Tomcat's webapps directory and navigate to http://localhost:8080/waffle-mixed/. Pick your method of login!

How does it Work?

Implementation details follow. Read at your own risk.

From the unauthenticated login page we are making two possible requests: one will trigger Single Sign-On and another will trigger form-based authentication. To do single sign-on we will need access to the request/response objects and to do forms authentication we will need access to the realms interface. The place where we have both is in org.apache.catalina.Authenticator.

1. @Override
2. protected boolean authenticate(Request request, Response response, LoginConfig loginConfig) {
3.  
4.     String queryString = request.getQueryString();
5.     boolean negotiateCheck = (queryString != null && queryString.equals("j_negotiate_check"));
6.     boolean securityCheck = (queryString != null && queryString.equals("j_security_check"));
7.  
8.     Principal principal = request.getUserPrincipal();
9.     
10.     AuthorizationHeader authorizationHeader = new AuthorizationHeader(request);        
11.     boolean ntlmPost = authorizationHeader.isNtlmType1PostAuthorizationHeader();
12.  
13.     if (principal != null && ! ntlmPost) {
14.         return true;
15.     } else if (negotiateCheck) {
16.         if (! authorizationHeader.isNull()) {
17.             return negotiate(request, response, authorizationHeader);
18.         } else {
19.             sendUnauthorized(response);
20.             return false;
21.         }
22.     } else if (securityCheck) {
23.         boolean postResult = post(request, response, loginConfig);
24.         if (postResult) {
25.             redirectTo(request, response, request.getServletPath());
26.         } else {
27.             redirectTo(request, response, loginConfig.getErrorPage());
28.         }
29.         return postResult;
30.     } else {
31.         redirectTo(request, response, loginConfig.getLoginPage());
32.         return false;
33.     }
34. }

Negotiate mimics the behavior of NegotiateAuthenticator, while form post follows the standard Authenticator registration process.

1. private boolean post(Request request, Response response, LoginConfig loginConfig) {        
2.     String username = request.getParameter("j_username");
3.     String password = request.getParameter("j_password");
4.     IWindowsIdentity windowsIdentity = null;
5.     try {
6.         windowsIdentity = _auth.logonUser(username, password);
7.     } catch (Exception e) {
8.         return false;
9.     }
10.     
11.     WindowsPrincipal windowsPrincipal = new WindowsPrincipal(windowsIdentity, context.getRealm(), _principalFormat, _roleFormat);
12.     register(request, response, windowsPrincipal, "FORM", windowsPrincipal.getName(), null);
13.     return true;
14. }

Links

• Download Waffle
• MixedAuthenticator.java

Jamais deux sans trois.

In a previous post I showed how to use the Waffle Tomcat Authenticator to implement single-sign-on with Tomcat. That works very well and utilizes the concept of Tomcat realms to protect various resources. Turns out, there’re disadvantages to this approach. These are quite well explained in the Tomcat Security Filter project. It all boils down to not requiring a realm, so lets see how to use the Waffle NegotiateSecurityFilter with Tomcat (you should be able to use it with other implementations, including Jetty).

Download

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

Configure Tomcat

Copy Files

Copy waffle-jna.jar, jna.jar and platform.jar to Tomcat's lib directory. You can package these files with your application, but this is easier for the demonstration.

Security Filter

Add the security filter to WEB-INF\web.xml.

1. <filter>
2.   <filter-name>SecurityFilter</filter-name>
3.   <filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
4. </filter>
5. <filter-mapping>
6.   <filter-name>SecurityFilter</filter-name>
7.   <url-pattern>/*</url-pattern>
8. </filter-mapping>

That’s it.

Demo Application

A demo application can be found in the Waffle distribution in the Samples\Tomcat\waffle-filter directory. Copy the entire directory into Tomcat's webapps directory and navigate to http://localhost:8080/waffle-filter/.

Retrieving User Principal

If you’re familiar with Tomcat you’ll be surprised that <%= request.getUserPrincipal().getName() %> works in a JSP page with this filter in place and no realm configuration. Theoretically Tomcat says you cannot assign a Principal to the request in a filter. The guys at the Tomcat Security Filter Project found a very simple solution – wrap the request up and pass the wrapper into the next filter in the chain. We use the same technique as you can see in NegotiateSecurityFilter.java and NegotiateRequestWrapper.java.

1. WindowsPrincipal windowsPrincipal = new WindowsPrincipal(windowsIdentity, null, _principalFormat, _roleFormat);
2. subject.getPrincipals().add(windowsPrincipal);
3. session.setAttribute("javax.security.auth.subject", subject);
4. NegotiateRequestWrapper requestWrapper = new NegotiateRequestWrapper(request, windowsPrincipal);
5. chain.doFilter(requestWrapper, response);

Links

• Single Sign-On: Tomcat Negotiate Authenticator (Kerberos + NTLM) w/ Waffle: explains how to do Single Sign-On with a Tomcat Authenticator.
• Windows/Active Directory Authentication: Tomcat + JAAS w/ Waffle: explains how to do Windows authentication in Tomcat with JAAS
• NegotiateSecurityFilter.java Source Code

We used to have code that checked whether a username/password was valid, then tried to enumerate user groups in Active Directory. That didn’t work for nested groups, domains with trusts and many other scenarios in-between. Then we wrote what eventually became Waffle. This week-end I added a JAAS LoginModule to Waffle 1.3. You can use this with anything that supports JAAS, such as Tomcat for BASIC, DIGEST or FORMS authentication. This is actually a simple demonstration (as opposed to the Single Sign-On Negotiate/NTLM/Kerberos valve) of Waffle and is how we originally used it. Here’s how.

Download

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

Configure Tomcat

Copy Files

Copy waffle-jna.jar, jna.jar and platform.jar to Tomcat's lib directory.

JAAS Realm

Add a JAAS realm to the application context. Modify META-INF\context.xml of your application.

1. <Context>
2.   <Realm className="org.apache.catalina.realm.JAASRealm"
3.          appName="Jaas"
4.          userClassNames="waffle.jaas.UserPrincipal"
5.          roleClassNames="waffle.jaas.RolePrincipal"
6.          useContextClassLoader="false"
7.          debug="true" />
8. </Context>

Authentication

Modify WEB-INF\web.xml of your application.

Enable BASIC, DIGEST or FORMS authentication for this realm.

1. <login-config>
2.   <auth-method>BASIC</auth-method>
3.   <realm-name>Jaas</realm-name>
4. </login-config>

Configure security roles. The Waffle login module adds all user's security groups (including nested and domain groups) as roles during authentication.

1. <security-role>
2.   <role-name>Everyone</role-name>
3. </security-role>

Restrict access to website resources. For example, to restrict the entire website to locally authenticated users add the following.

1. <security-constraint>
2.   <display-name>Waffle Security Constraint</display-name>
3.   <web-resource-collection>
4.     <web-resource-name>Protected Area</web-resource-name>
5.     <url-pattern>/*</url-pattern>
6.   </web-resource-collection>
7.   <auth-constraint>
8.     <role-name>Everyone</role-name>
9.   </auth-constraint>
10. </security-constraint>

Login Configuration

Create a login configuration file, login.conf. This configuration file specifies how to plug the Waffle Windows Login Module.

1. Jaas {
2.     waffle.jaas.WindowsLoginModule sufficient;
3. };

The login.conf configuration file is passed to Java with -Djava.security.auth.login.config=<path-to-file>/login.conf.

JAAS Security Policy

Create JAAS policy configuration file, jaas.policy. This file specifies which identities are granted which permissions.

1. grant Principal * * {
2.   permission java.security.AllPermission "/*";
3. };

The policy file is passed to Java with -Djava.security.auth.policy=<path-to-file>/jaas.policy.

Start Tomcat

You must start Tomcat with Security Manager enabled (-security) and configure it with a login configuration and policy. For example, the following will start Tomcat using the demo login.conf and jaas.policy from the Waffle samples.

Demo Application

A demo application can be found in the Waffle distribution in the Samples\Tomcat\waffle-jaas directory. Copy the entire directory into Tomcat's webapps directory, start Tomcat as explained above, and navigate to http://localhost:8080/waffle-jaas/. You will be prompted for your Windows login, enter your Windows credentials and log-in.

Links

• Waffle
• JAAS LoginModule Source Code

Prologue

I was debugging a GWT application that worked well with FORM authentication and refused to work with integrated Windows auth (NTLM/Kerberos) on some machines. It all started with a benign error message.

The log reveals an interesting stack.

Exception while dispatching incoming RPC call
java.lang.IllegalArgumentException: encodedRequest cannot be empty
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:226)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:163)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

We’re in the middle of an Ajax POST. Examining the HTTP request we find that it doesn’t have a body. This explains why GWT is throwing this exception, but doesn’t explain why this happens. I asked for help on both the GWT group and on EXTJs premium forum, but didn’t get anything useful.

POST /dbprotect/com.example.gwt.main/service/ServiceRPC HTTP/1.1
Accept: */*
Accept-Language: en-us
Content-Type: text/x-gwt-rpc; charset=utf-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0; …)
Host: localhost:20080
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAAAB7IIogkACQAxAAAACQAJACgAAAAFAs4OAAAAD0RET1VCLVJFRFdPUktHUk9VUA==

The Heart of the Salamander

I mentioned that I had two environments: one that worked and one that didn’t. The defining moment came when John pointed out that the working environment was choosing Kerberos, while the non-working environment was choosing NTLM when performing Negotiate authentication. It was clear that after a Kerberos auth the POST no longer carried an Authorization header and had a body.

I (mistakenly) concluded that this was a GWT bug with Internet Explorer. It failed the same way in Chrome though, so this wasn’t some kind of conspiracy.

The Reckoning

I started reading GWT code. I also read the NTLM RFC. The latter was helpful.

This scheme differs from most "normal" HTTP authentication mechanisms, in that subsequent requests over the authenticated connection are not themselves authenticated; NTLM is connection-oriented, rather than request-oriented. So a second request for "/index.html" would not carry any authentication information, and the server would request none. If the server detects that the connection to the client has been dropped, a request for "/index.html" would result in the server reinitiating the NTLM handshake.

A notable exception to the above is the client's behavior when submitting a POST request (typically employed when the client is sending form data to the server). If the client determines that the server is not the local host, the client will initiate reauthentication for POST requests over the active connection. The client will first submit an empty POST request with a Type 1 message in the "Authorization" header; the server responds with the Type 2 message (in the "WWW-Authenticate" header as shown above). The client then resubmits the POST with the Type 3 message, sending the form data with the request.

I got bitten by the NTLM protocol. It hurt.

The Fix

This fix was easy. When an empty POST is sent, we must follow the protocol and perform authentication instead of assuming that the client is already authenticated (we did do that in a previous GET). This is now properly implemented in the Waffle Tomcat Authenticator (source).

Suboptimal Performance

There’s a big side effect to this NTLM negotiation – degraded performance. You’re getting a POST request that requires authentication every time you have a new connection. This happens a lot with AJAX sites, such as GWT-based ones. A workaround is described in KB251404, setting HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Internet Settings/DisableNTLMPreAuth to 1.

In a properly configured Active Directory you’re most likely to be using Kerberos anyway. This requires a valid SPN. Read this article to start – it’s about SQL server, but applies to all services. Adding a HTTP/server.com:port SPN was sufficient in some of my test environments to avoid NTLM altogether.

I’ve added a Tomcat Negotiate (Kerberos + NTLM) authenticator to Waffle 1.3 for Tomcat 6. Here’s how to use it.

Download

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

Configure Tomcat

Copy Files

I started with a default installation of Tomcat 6. Checked that I could start the server and navigate to http://localhost:8080. Copy the following files into tomcat’s lib directory.

• jna.jar: Java Native Access
• platform.jar: JNA platform-specific API
• waffle-jna.jar: Tomcat Negotiate Authenticator

Authenticator Valve

Add a valve and a realm to the application context in your context.xml (for an application) or in server.xml (for the entire Tomcat installation).

1. <Context>
2.   <Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both" />
3.   <Realm className="waffle.apache.WindowsRealm" />
4. </Context>

Security Roles

Configure security roles in your application’s web.xml. The Waffle authenticator adds all user's security groups (including nested and domain groups) as roles during authentication.

1. <security-role>
2.   <role-name>Everyone</role-name>
3. </security-role>

Restrict Access

Restrict access to website resources. For example, to restrict the entire website to locally authenticated users add the following in web.xml.

1. <security-constraint>
2.   <display-name>Waffle Security Constraint</display-name>
3.   <web-resource-collection>
4.     <web-resource-name>Protected Area</web-resource-name>
5.     <url-pattern>/*</url-pattern>
6.   </web-resource-collection>
7.   <auth-constraint>
8.     <role-name>Everyone</role-name>
9.   </auth-constraint>
10. </security-constraint>

Test

Restart Tomcat and navigate to http://localhost:8080/.

You should be prompted for a logon with a popup. This is because by default localhost is not in the Intranet Zone and the server returned a 401 Unauthorized. Internet servers with a fully qualified named are detected automatically.

Internet Explorer

Ensure that Integrated Windows Authentication is enabled.

1. Choose the Tools, Internet Options menu.
2. Click the Advanced tab.
3. Scroll down to Security
4. Check Enable Integrated Windows Authentication.
5. Restart the browser.

The target website must be in the Intranet Zone.

1. Navigate to the website.
2. Choose the Tools, Internet Options menu.
3. Click the Local Intranet icon.
4. Click the Sites button.
5. Check Autmatically detect intranet network.
6. For localhost, click Advanced.
7. Add http://localhost to the list.

Firefox

1. Type about:config in the address bar and hit enter.
2. Type network.negotiate-auth.trusted-uris in the Filter box.
3. Put your server name as the value. If you have more than one server, you can enter them all as a comma separated list.
4. Close the tab.

Navigate to http://localhost:8080 after adding it to the Intranet Zone.

You should no longer be prompted and automatically authenticated.

Logs

In the logs you will see the following output for a successful logon.

My laptop is not a member of an Active Directory domain, but you would see domain groups, including nested ones here. There’s nothing special to do for Active Directory. The authenticator also automatically handles all aspects of the Negotiate protocol, chooses Kerberos vs. NTLM and supports NTLM POST. It basically has the same effect in Tomcat as choosing Integrated Windows authentication options in IIS.

Links

• Tomcat Negotiate Authenticator Source Code

Related Projects

• Tomcat SPNEGO by Dominique Guerrin: this is a very good prototype of a filter. It uses JNI and not JNA, doesn’t support NTLM POST and the code is pretty thick.
• SPNEGO Sourceforge: it’s a nightmare to configure, doesn’t work without an Active Directory domain and requires an SPN
• JCIFS NTLM: no longer supported and they recommend using Jespa
• Jespa: a commercial implementation that claims to do the same thing as Waffle, but uses the Netlogon service instead of the native Windows API

In a previous post I’ve described an initial implementation of OpenDS as a naming and directory service, including extending the directory schema and reading and writing directory objects with JNDI. As actual (read: competent) Java developers took over my prototype, they switched from JNDI to spring-ldap. The resulting code is much more pleasant, and I got to learn a bit more about Spring.

Service Object

Lets get something useful in and out of the directory: a Service object. Naturally it doesn’t matter where it came from, so the Service class is a simple container.

You’ll immediately notice that in contrast with the previous implementation, this object knows nothing about being stored in a directory. I was lazy then, but this time Spring forces helps me write better code.

Service DAO

At the core of spring-ldap lies LdapTemplate that executes core LDAP functionality and encapsulates all the plumbing. We’re going to implement a simple DAO for our Service objects that can, for example, retrieve all services.

Notice a few important things here. First, we have not specified how to connect to the LDAP server - that will appear in the runtime configuration. Secondly, we use ServiceAttributesMapper, a class that knows how to map LDAP attributes into a Service object, achieving a very nice separation of concerns.

Spring Configuration

To make it all work we need some configuration. We can define a springldap.xml configuration file for our tests, another one for production, etc.

What does this do?

1. Defines the values for the LdapContextSource. In our case, a url to our OpenDS installation, a base path to the objects, a user and password to access the directory.
2. Defines how to construct an LdapTemplate that encapsulates LDAP core functionality. It takes the context source defined above.
3. Tells Spring to set the LdapTemplate property of the ServiceDAO with the value above.

We could have done this all in code, but Spring helps us create another level of abstraction and enables a complete configuration-based runtime experience.

Getting Services

We still need to tell Spring to use this configuration at runtime before we can call DAO methods such as getAllServices.

This is nice! With Spring, we have achieved complete separation of responsibilities and pluggable configuration and, all things considered, wrote a lot less code.

More DAO

Create or Update a Service

Delete a Service

Get a Service by Name

Running the Code

You can run the source code from this article with OpenDS and Eclipse.

1. Check out the source code with SVN from svn://svn.vestris.com/codeproject/JndiDemo.
2. Install OpenDS from http://www.opends.org.
3. Copy schema\Services.ldif into OpenDS\config\schema\100-Services.ldif and restart OpenDS.
4. Import the JndiDemo project into Eclipse and run JUnit tests in the src-test package.

Links

• Source Code for this Article
• OpenDS Directory Server
• Getting Started with JNDI and OpenDS
• Spring-LDAP

In writing new MSI installers, you must think about upgrade. I always recommend major upgrade – uninstall and reinstall is much cleaner. In that case the Installed vs. NOT Installed properties get confusing very quickly, so we came up with some shortcuts that make life easier.

We include the following file in every installer, as is.

Runtime.wxi follows.

Don’t forget to define the OLDERVERSION_BEINGUPGRADED and NEWERVERSION_INSTALLED properties in the Upgrade table.

And change the install sequence for major upgrade.

Initially we had to deal with a legacy InstallShield installer and these properties were more complicated. Read this post instead if that’s what you’re trying to do.

I announced in a previous post that AppSecInc. has open-sourced its Wix extensions. We’ve continued developing the project for our own needs and have seen some adoption, especially for installing databases. This was expected, since what distinguishes these extensions from stock Wix ones is a programming model that is not narrowly focused on MSSQL, effectively supporting any ODBC database today and creating the opportunity to support other database targets, such as Oracle.

In this post I’ll show you how to get started with installing an MSSQL database in just a few lines of code.

Adding References

First, you must add a reference to the WixDataSource extension to your Wix project and include the DataSource extension’s namespace into the Wix XML declaration.

ODBC Connection

To connect to a database you need an ODBC connection. For now, we don’t have ODBC_CONNECTION_STRING defined, so each implementation that uses this connection will need (and does) supply its own default. For example, SQL server extensions assume that the default connection string refers to a local database with Windows authentication.

MSSQL Database

We can now define an MSSQL database.

What’s happening here?

We tell the extension to create a database called DemoDatabase using the DemoSQLServerConnection. We tell it to create the database on install and not to drop it on uninstall. We also tell it to check whether the database exists and not to fail if that’s the case. This is a typical scenario where a DBA will pre-create the database and the installer will need to create tables and upload initial data into it.

We’ve nested the database under a component, so component rules apply. You can include the component into a feature and the user can, for example, choose to install or not install the feature. You can add other conditions at many levels here, etc.

Database Schema

A database without a schema is not very useful. We author a .sql file that creates the schema and execute it on FirstInstall (for more explanation on FirstInstall and Upgrading conditions see this post).

To simplify things for the purposes of this post, the Schema.sql file knows how to handle its own upgrade.

There’re some more interesting things here. Notice that we use a generic ODBCExecute extension that works for this specific MSSQL database. The declaration has a Type=”SqlServer”. This is a new feature in MSI Extensions 1.2 – the file will be parsed with an actual SQL parser, split by GO statements (configurable) and execute the statements one-by-one. The idea is that the parsers can one day become converters and adjust syntax from, for example, HQL to SQL of a specific database target. For now, this makes SQL execution identical to one in MSSQL Query Analyzer.

Secondly, with MSI Extensions 1.2, Schema.sql may be an ANSI or a UTF-8 file. This is detected automatically. You can finally deploy your databases with Russian table names or content.

User Experience

We now want to give users an opportunity to choose where to install this database and which credentials to use. For this purpose we add the WixCommonUiExtension.dll to the project and redefine the UI sequence to reference some stock dialogs.

Notice the DbCreateCredDlg that was inserted and a few defaults for various options that drive this dialog. The latter supports testing credentials, choosing whether to use SQL Server or Windows authentication, etc.

The DbCreateCredDlg looks like this and publishes the ODBC_CONNECTION_STRING property, connecting the dots between the UI and the ODBC connection used to create the database.

Conclusion

That’s it. You now have a working database installer with virtually zero lines of code.

Overview

I finally found some time to implement Facebook Connect for FoodCandy.com. You can now do the following.

• Sign-Up with a Facebook account, no questions asked on FoodCandy.com.
• Associate an existing Facebook account with a previously created FoodCandy.com account.
• Login to FoodCandy with a previously associated Facebook account.

Is it hard?

It’s not. There’s about a day of work for all the items above, including this post.

Why am I writing this?

Two reasons.

There’re several interesting aspects to the FoodCandy service model, in particular that the website is just a front-end UI to SnCore and cannot do authentication. It needs to pass all data to the services back-end via a SOAP API, which in turn will do authentication. This means that we need to do more work and less magic.

I had to do some wrestling with JavaScript and the Facebook API at login. Most of the examples I found didn’t quite work. This post should, hopefully, be more helpful to those implementing Facebook Connect in C# / ASP.NET.

Application Registration

I registered an application, which gave me an API key and a shared secret. The first is public, but the latter is going to be stored on the back-end and used to verify login signatures or make authenticated calls to Facebook. You would typically store both in some configuration file, SnCore has a settings framework that lets you store both public information and “password”-like settings accessible to the back-end only.

Single Sign On

The best document to read first is here.

A Facebook Login Button

1. public string GetLoginUrl(string returnUrl)
2. {
3.     return string.Format("http://www.facebook.com/login.php?api_key={0}&extern=1&fbconnect=1&req_perms=publish_stream,email&return_session=1&v=1.0&next={1}&fb_connect=1&cancel_url={1}",
4.         FacebookAPIKey, Renderer.UrlEncode(string.Format("{0}/FacebookConnect.aspx?connect=1&ReturnUrl={1}", mSessionManager.WebsiteUrl, Renderer.UrlEncode(returnUrl))));
5. }

The URL specifies the following.

• Tell Facebook login to return to FacebookConnect.aspx with parameters that will indicate the redirect location after a successful login. Facebook application settings require you to specify a single login return location. In addition this must be a dynamic page with a ? in the URL.
• Tell Facebook that we want publish_stream and email access. The publish_stream option asks the user to authorize our application to publish content on Facebook, which is beyond the scope of this post. The email option asks the user to authorize our application to send the user an e-mail. You don’t actually ever get the user’s e-mail, but an application-specific e-mail forward address.

Redirect After Login

A logged-in user is now returned to FacebookConnect.aspx with a number of parameters in the URL that contain session information.

Facebook JavaScript can process all that into cookies. The cookie names start with the API key. You can find a lot more detail about cookies here.

Invoking this JavaScript gave me a lot of headache – I was properly redirected to FacebookConnect.aspx, but no cookies were set. The problem was that you need to initialize the Facebook API, then synchronously wait for it to set the cookies and therefore complete.

1. <div id="fb-root"></div>
2. <script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
3. <script type="text/javascript">
4.   var facebookAPIKey = "<% Response.Write(FacebookAPIKey); %>";
5.   FB.init(facebookAPIKey);
6.   FB.ensureInit(function() {
7.    FB.Connect.get_status().waitUntilReady( function( status ) {
8.       switch ( status ) {
9.       case FB.ConnectState.connected:
10.          window.location="<% Response.Write(ReturnUrl); %>";
11.          break;
12.       case FB.ConnectState.appNotAuthorized:
13.       case FB.ConnectState.userNotLoggedIn:
14.          FB.Connect.requireSession();
15.      alert('There was an error logging in.');
16.       }
17.    });
18.   });
19. </script>

Verifying the Signature

FacebookConnect.aspx does the job at performing a cross-site Facebook login, then redirects back to the initial login page. The latter must now verify that the login is legit and locate a FoodCandy account associated with this Facebook login. I do this work in the actual login page.

If you’re doing all of this on the client side, read this document for background and use the Facebook Connect library. I had to split the process between the front-end and the back-end and used it for a reference implementation.

Facebook cookies are collected in a sorted list, concatenated and signed.

1. public SortedList<string, string> GetFacebookCookies(HttpCookieCollection cookies)
2. {
3.     SortedList<string, string> sortedCookies = new SortedList<string, string>();
4.     string cookiePrefix = FacebookAPIKey + "_";
5.     foreach (string cookieName in cookies)
6.     {
7.         if (cookieName.StartsWith(cookiePrefix))
8.         {
9.             var cookie = cookies[cookieName];
10.             sortedCookies.Add(cookie.Name.Substring(cookiePrefix.Length), cookie.Value);
11.         }
12.     }
13.  
14.     return sortedCookies;
15. }

The signature must match the value of the cookie with the same name as the API key.

1. var sb = new StringBuilder();
2. foreach (String s in cookies.AllKeys)
3. {
4.     sb.AppendFormat("{0}={1}", s, cookies[s]);
5. }
6.  
7. sb.Append(facebookSecret);
8. string stringToHash = sb.ToString();
9.  
10. StringBuilder computedHash = new StringBuilder();
11. byte[] hash = MD5.Create().ComputeHash(Encoding.UTF8.GetBytes(stringToHash));
12. foreach (byte b in hash)
13. {
14.     computedHash.AppendFormat("{0:x2}", b);
15. }
16.  
17. return computedHash.ToString().ToLowerInvariant() == signature.ToLowerInvariant();

Facebook Account Id to FoodCandy Account Id

Once the signature is verified, you can trust the Facebook user id stored in the “user” cookie. It’s a 64-bit integer. I created a new table in SnCore called AccountFacebook and allow users to associate facebook IDs with their account. If the back-end can locate such an account, an SnCore login ticket is issued, which completes the login operation.

1. AccountFacebook account = (AccountFacebook)session.CreateCriteria(typeof(AccountFacebook))
2.         .Add(Expression.Eq("FacebookAccountId", FacebookAccountId))
3.         .UniqueResult();

FoodCandy Signup with Facebook

The signup process first goes through the same logon process as described above, except that the final landing page is one that will create an account. Most of what I describe below is well explained here, albeit for an older version of the API. This should serve as a refresher.

First, I got hold of the Facebook Developer Toolkit that implements calls to Facebook using the Facebook Graph API. It is initialized with the API key, the secret and a session key. The toolkit is going to be making server-to-server calls from FoodCandy to Facebook, it’s all back-end operation.

1. Facebook.Session.ConnectSession facebookSession = new Facebook.Session.ConnectSession(
2.     FacebookAPIKey, FacebookSecret);
3.  
4. facebookSession.SessionKey = facebookCookies["session_key"];
5. facebookSession.UserId = long.Parse(facebookCookies["user"]);
6. Facebook.Rest.Api facebookAPI = new Facebook.Rest.Api(facebookSession);

At signup I need the user’s name, e-mail and birthday. I’d also like to get the user’s location and maybe even a picture.

1. Facebook.Schema.user user = facebookAPI.Users.GetInfo();
2.  
3. TransitAccount ta = new TransitAccount();
4. ta.Name = user.name;
5. ta.Birthday = DateTime.Parse(user.birthday_date);
6. acct.CreateWithFacebook(t_facebook.FacebookAccountId, user.proxied_email,
7.     ta, ManagedAccount.GetAdminSecurityContext(session));
8.  
9. if (user.current_location != null)
10. {
11.     ta.City = user.current_location.city;
12.  
13.     int country_id;
14.     if (ManagedCountry.TryGetCountryId(session, user.current_location.country, out country_id))
15.         ta.Country = user.current_location.country;
16.     
17.     int state_id;
18.     if (ManagedState.TryGetStateId(session, user.current_location.state, user.current_location.country, out state_id))
19.         ta.State = user.current_location.state;
20. }
21.  
22. if (user.picture_big != null)
23. {
24.     TransitAccountPicture t_picture = new TransitAccountPicture();
25.     t_picture.AccountId = acct.Id;
26.     ThumbnailBitmap bitmap = new ThumbnailBitmap(new Bitmap(user.picture_big));
27.     t_picture.Bitmap = bitmap.Bitmap;
28.     t_picture.Thumbnail = bitmap.Thumbnail;
29.     t_picture.Name = user.pic;
30.     ManagedAccountPicture m_picture = new ManagedAccountPicture(session);
31.     m_picture.CreateOrUpdate(t_picture, ManagedAccount.GetAdminSecurityContext(session));
32. }
33.  
34. SnCore.Data.Hibernate.Session.Flush();
35. return acct.Id;

That’s a lot of private information that you gave me with a single click! Let's look at the created account.

Try it! Signup to FoodCandy with a Facebook account.

Links

• FoodCandy Source Code
• FacebookConnect.aspx / .cs
• FacebookPageManager.cs
• SnCore Social Networking Framework

Java Native Access (JNA) 3.2.5 shipped quietly last week.

JNA now includes platform.jar that has cross-platform mappings and mappings for a number of commonly used platform functions, including a large number of Win32 mappings as well as a set of utility classes that simplify native access. The code is tested and the utility interfaces ensure that native memory management is taken care of correctly. I’ve contributed a boatload of code in this area, so when something doesn’t work you can blame me.

Before you map your own functions, check the platform package documentation for an already mapped one.

Platform-specific structures are mapped by header. For example, ShlObj.h structures can be found in com.sun.jna.platform.win32.ShlObj. Platform functions are mapped by library. For example, Advapi32.dll functions can be found in com.sun.jna.platform.win32.Advapi32. Simplified interfaces (wrappers) for Advapi32.dll functions can be found in com.sun.jna.platform.win32.Advapi32Util.

The following large areas have been covered to some extent in native interfaces and utility libraries: Registry, SSPI, Active Directory, DPAPI, Users and Groups and Shell.

• Download 3.2.5

There will be more refactoring and coverage in the next release. It also seems to have picked up a little traction on the mailing list as people have been sending patches with more Win32 code. I’ll do my best at committing that, so send more. The goal is to eventually cover all of win32 SDK and put the Java to Win32 interoperability problem to rest.

Sometimes great is the enemy of good. I recently had to harvest a large number of files to create a wix installer. I tried heat.exe, but after struggling with its generation style and even considering writing an XSLT, I decided it would be faster to just code what I want in C#. This generates a .wxi file that follows somewhat of a standard of naming components .C, directories .D and skipping .svn folders.

It just gets the job done.

I often hear from .NET programmers “I’d like to get into Java, not the language, but all that J2EE stuff …”. I am one of those people so I try to use any opportunity to try something I’ve never touched before.

We’re moving to a SOA model with the product at my day job. One of the fundamental questions is: “How does a service find another service?”. The standard answer is to use a naming and directory service and in Java you talk to one of these things with JNDI.

First, a few basics.

• Naming service is a fundamental facility in any computing system. It’s the means by which names are associated with objects and objects are found based on their names. For example, to access a file on the computer you must provide its name.
• Directory Service is an extension of the naming services. A directory service associates names with objects and also allows such objects to have attributes. Thus, you not only can look up an object by its name but also get the object's attributes or search for the object based on its attributes.

By using a directory service, you can simplify applications and their administration by centralizing the storage of shared information. For our purposes such information includes SOAP service URIs. For example, you can find demoService (a previously agreed-upon name of the demo service) at http://localhost:20080/demo.

Client & Server

I picked up OpenDS, on open-source server from Sun. After a straightforward installation (set OPENDS_JAVA_HOME to a JRE location and run setup.bat) I had an LDAP server running as a Windows Service (OpenDS) on port 389. There’s a handy bat\control-panel.bat that launches a schema and object browser.

We can now access this server with JNDI, which comes standard with Java Platform 1.1.2 or later.

This outputs the attributes of my initial domain context that was created at setup time.

The Goal

Let’s create a directory for our SOAP services. The goal is to be able to store a collection of service objects, each containing a well-defined URL and retrieve service URLs using the service names.

Extending the Schema

The OpenDS schema is stored in .ldif files in the config\schema directory. The directory schema can be extended by importing LDIF files, modifying those in the schema directory or programmatically with JNDI. I’ll write an import an .ldif file.

There’re several RFCs with various well-known attribute types, such as name or uid. We’re only missing serviceUri, which we can define as a custom attribute.

Our Service type is defined as follows: an object with a common name (cn), a humanly readable name (name), an object class (Service), a unique identifier (uid) and an url to the service (serviceUri).

OIDs

You can generate a root OID using this script (save the script to disk and run cscript script.vbs) and keep adding numbers to it. It’s just a globally unique number that identifies an attribute or a class. I generated OID 1.2.840.113556.1.8000.2554.999999.

Service in Java

Lets define a Service Java class that can be used to read and write objects to the directory.

This is a simple container for attributes. The UnimplementedDirContext is an empty class that throws NotImplementedException on two dozen methods that are required by a full DirContext.

A Services Organization

We’d like to organize services under a Services organization. I’ve created that manually in the directory. The full directory path to the OU is o=Services,dc=example,dc=com.

Writing to the Directory

A write is a call to bind. Binding means connecting a name to an object. You can rebind, ie. either create or update an existing object.

Here’s what we have in the directory now (this is the Manage Entries UI from the control panel tool that comes with OpenDS).

Retrieving from the Directory

In order to retrieve a strongly typed object from the directory we must supply an object factory. When the factory encounters an object with an objectClass=Service, it will create an instance of such.

The initial directory context must be told to use this factory.

Finally, the retrieval becomes a simple lookup.

Deleting Directory Objects

To complete the picture, lets delete a directory object. This is the opposite of bind, unbind.

A Word on XML

All this requires server-side Java code and keeping the LDAP port 389 open.

Alternatively, OpenDS provides an implementation of Directory Services Markup Language (DSML), an XML API to directory services. It’s then possible to switch JNDI client code from LDAP to DSML using a Sun early access JNDI client for DSML.

Links

• Naming and Directory Services Tutorial
• OpenDS Directory Server
• Source Code for this Article
• Service.java
• UnimplementedDirContext.java
• ServiceFactory.java

I finally got to porting Waffle to pure java with JNA. This means you don’t need .NET framework or COM to call Waffle from Java. It’s pure java.

Waffle is a thin interface that simplifies Windows authentication and authorization, therefore providing a practical and workable back-end for NTLM, Negotiate, Kerberos and other SPNEGOs. Here’re some scenarios that you can now do without any headache directly in Java.

Logon a user: get his local and domain groups

This calls Win32 LogonUser, examines the user token and extracts all local and domain group memberships from it. This obviously includes nested groups. For more details of how this is implemented in JNA see this earlier post.

Here’re the first lines of output for my current user:

Active directory: get the list of trusted domains

The typical scenario is presenting a dropdown in front of the user to choose domains he can logon to. This list includes the current domain and all domain trusts.

Active directory: is this computer joined to a domain?

For systems that run both with and without active directory you need to programmatically figure out whether a computer is joined to a domain or a workgroup. If it’s joined to a domain or a workgroup you want to know what domain the computer is joined to.

Local machine: enumerate local groups

Negotiate: single sign-on

This is the sweetest waffle, both the client and the server-side of the Negotiate protocol made super easy. You would typically split this code in two halves and do the work of transmitting the tokens between client and server. In the end, the user is logged on to the server side and you can examine his local and domain groups.

Integration and Download

Waffle now has the same (or very similar) interface in C#, COM, Jacob and pure Java. So you can use it in a variety of applications. For COM we supply a merge module for your installer. For C#, reference Waffle.Windows.AuthProvider.dll. For Java, reference waffle-jna-auth.jar and include jna.jar and platform.jar in your distribution.

• Download Waffle 1.3

dotNetInstaller 1.9 was released today, April 5th, 2010.

Features include support for windows patch installers (.msp), many improvements to uninstall support, improved registry checks and registry variable substitutions, improvements in CABing performance and reliability and numerous bug fixes. Download build 1.9.5931.0.

The Grey Rat

There’s a giant grey rat outside of my window and a bunch of non-union workers laboring in the rain. The union guy who’s guarding the rat and giving away flyers got too cold and went inside the building. But I digress, the post is about working with Unions in Java Native Access (JNA).

Preamble

I was trying to retrieve Active Directory forest trust information via DsGetForestTrustInformationW. The function takes a pointer to a PLSA_FOREST_TRUST_INFORMATION, a pointer to a pointer to an LSA_FOREST_TRUST_INFORMATION structure. So far so good, we just need to pay attention to the several levels of indirection: whenever we want the value of a pointer to something, it’s a ByReference.

LSA_FOREST_TRUST_INFORMATION is a structure that contains a RecordCount number of PLSA_FOREST_TRUST_RECORD items. Those are pointers, so Entries is an array of pointers. Since we want the value of a pointer, we use ByReference again.

A pointer to a record is simply a structure that contains a pointer to the record.

Union inside a Structure?

Still with me? The record is declared like this:

Note that MSDN has a mistake here, missing the Time field, which gave me lots of headache and wasted hours of my time. Got to use definitions in platform SDK.

This is a union. How do you declare this in JNA?

A union is just like a structure, except that every field lives at an offset zero. In JNA, you must tell the union which field to use before reading the value.

In our case we override read() and set the type depending on the ForestTrustType value. Then re-read the union from memory. Voila.

Notes

Committed to JNA under com.sun.jna.platform.win32 in rev. 1060.