Alternate Windows Security Setup

Owned by Shaun Forbes
Last updated: 19 Sept, 2011Version comment
3 min read

Description

Windows Server 2008 can have issues with the NTLM authentication method used with Weave.
This page outlines a method of configuring the Weave authentication to work around this until the issue is resolved.

The reason that this method works and the other doesn't is that this setup bypasses the checks on the credentials that the browser has submitted, since the new method used by Windows 2008 to validate the credentials is not yet supported.
Obviously this is a security risk, and this method should be viewed as a convenience for the user rather than a method of securing access to sensitive information.

Alternate Integrated Authentication

To implement Windows integrated authentication and allow internal users to login to Weave automatically using their Windows username involves editing the security.xml file to replace the login form with handling with the NTLM processor.

So looking at the default security.xml file it contains the following near the top

	<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
		<property name="filterInvocationDefinitionSource">
			<value>
				CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
				PATTERN_TYPE_APACHE_ANT
				/server/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
				/**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
			</value>
		</property>
	</bean>

What this section does is to determine which filters are applied to any incoming requests, passing everything that matched /server/** through the first list, and everything else through the second.

What we want to do here is add an additional filter to perform the NTLM authentication steps when required. But before we add the new filter to the list we need to add the new definition for the filter object itself.

To do this we add a new section to the security.xml file to define a new NtlmProcessingFilter

	<bean id="ntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilter">
		<property name="defaultDomain"><value>DOMAINNAME</value></property>
		<property name="domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
	</bean>

The two values in there DOMAINNAME and 172.16.0.30 need to be replaced with values that are appropriate for your environment.

This is the filter that we will eventually add to the filter list, but we first need to create two more sections that this references, the ntlmEntryPoint and the ntlmAuthenticationManager.

This is the first place where this configuration is different from the original NTLM setup, namely the nullDaoAuthentication provider is used instead of the smbAuthenticationProvider.

	<bean id="ntlmEntryPoint" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilterEntryPoint"/>

	<bean id="ntlmAuthenticationManager" class="org.acegisecurity.providers.ProviderManager">
		<property name="providers">
			<list>
				<ref local="nullDaoAuthenticationProvider"/>
				<bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
					<property name="key" value="changeThis"/>
				</bean>
				<bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider">
					<property name="key" value="changeThis"/>
				</bean>
			</list>
		</property>
	</bean>

The ntlmEntryPoint is pretty straight forward, but we can see that the ntlmAuthenticationManager references yet another section that we need to add, the nullDaoAuthenticationManager.

	<bean id="nullDaoAuthenticationProvider" class="org.acegisecurity.providers.smb.NullPasswordDaoAuthenticationProvider">
		<property name="userDetailsService" ref="userDetailsService"/>
		<property name="userCache">
			<bean class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
				<property name="cache">
					<bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">
						<property name="cacheManager">
							<bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>
						</property>
						<property name="cacheName" value="userCache"/>
					</bean>
				</property>
			</bean>
		</property>
	</bean>

That should be the final new section we need to add, since the sections that it references should already exist. So all that remains is to add the first section we added to the list of filters

	<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
		<property name="filterInvocationDefinitionSource">
			<value>
				CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
				PATTERN_TYPE_APACHE_ANT
				/server/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
				/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
			</value>
		</property>
	</bean>

Here you can see that we've added the ntlmProcessingFilter to the two filter lists, this should allow used that are logged into Windows to have that username automatically recognized by Weave.

But that doesn't take care of determining what the user has access to once they're logged in. That will still need to be done via the users.properties file (to map usernames to roles), unless you setup security.xml to utilise information stored in Active Directory.

Depending upon the version of active directory you're running you may need to specify a username/password for the ntlmProcessingFilter, so if you find authentication errors in the weave.log file after enabling integrated authentication then change the ntlmProcessingFilter to the following and set the appropriate username.password.

	<bean id="ntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilter">
		<property name="defaultDomain"><value>DOMAINNAME</value></property>
		<property name="domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
		<property name = "JCifsProperties">
			<map>
				<entry key="jcifs.smb.client.username">
					<value>username</value>
				</entry>
				<entry key="jcifs.smb.client.password">
					<value>password</value>
				</entry>
			</map>
		</property>
	</bean>