Page Comparison

h2. 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.

{warn}
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.
{warn}

h3. 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

{code:xml|linenumbers=true}
	<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>
{code}

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}}

{code:xml|linenumbers=true}
	<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>
{code}

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}}.

{note}
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.
{note}

{code:xml|linenumbers=true}
	<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>
{code}

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

{code:xml|linenumbers=true}
	<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>
{code}

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

{code:xml|linenumbers=true}
	<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>
{code}

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.

{code:xml|linenumbers=true}
	<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>
{code}