Page Comparison

...

First up we'll look at how to provide the user with access to the system without having to enter a username/password via Windows integrated authentication. Then we'll look at extending this to also obtain the access levels for the users from the domain.

Integrated Authentication

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

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 to enable Windows authentication is add an additional filter to perform the NTLM authentication steps when required.

...

Note
The latest windows authentication bundle is downloadable here

Debugging

You may want to turn on the logging of the security processing during the setting up of the authentication, since it'd disabled by default.

To do this ensure that the following two lines appear in logging.properties and any others referencing security are removed (in case they reduce the logging)

Code Block

	none
	none
title	Enable security process logging
linenumbers	true


log4j.logger.org.acegisecurity=DEBUG
log4j.logger.com.cohga.server.security=DEBUG

Then when someone is logging in the log file will show the progress and what roles they were granted, which should help you to understand what role names must be used in the access control lists

Integrated Authentication

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

Looking at the default security.xml file it contains the following near the top:

Code Block

	xml
	xml
title	Adding NTLM filter to Default request filter chain
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>

Here we've added the ntlmProcessingFilter to the list of filters that will be applied to the incoming requests.

Now we need to create the ntlmProcessingFilter filter and configure it to use the local domain.

To do this we add a new section to the security.xml file to define a new NtlmProcessingFilterWhat 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 to enable Windows authentication is add an additional filter to perform the NTLM authentication steps when required.

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 Block

	xml
	xml
title	The root Adding NTLM filter definitionto request filter chain
linenumbers	true

	<bean id="ntlmProcessingFilterfilterChainProxy" class="org.acegisecurity.uiutil.ntlm.NtlmProcessingFilterFilterChainProxy">
		<property name="defaultDomain"><value>DOMAINNAME</value></property>filterInvocationDefinitionSource">
		<property name="domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>	<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>

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 added to the filter list, now we need to create two more sections that this filter references, the ntlmEntryPoint and the ntlmAuthenticationManager.

The ntlmEntryPoint takes care of the communication for the server to obtain the Windows userid from the browser.
The ntlmAuthenticationManager then sends that information through a list of AuthenticationProviders to validate that it's correct.Here we've added the ntlmProcessingFilter to the list of filters that will be applied to the incoming requests.

Now we need to create the ntlmProcessingFilter filter and configure it to use the local domain.

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

Code Block

	xml
	xml
title	NTLM entry point for obtaining the user information from browserThe root NTLM filter definition
linenumbers	true

	<bean id="ntlmEntryPointntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilterEntryPointNtlmProcessingFilter"/>

Code Block

xml

title

NTLM authentication manager for verifying the user information from browser

linenumbers

true


	<bean id="ntlmAuthenticationManager" class="org.acegisecurity.providers.ProviderManager">
		<property name="defaultDomain"><value>DOMAINNAME</value></property>
		<property name="domainController"><value>172.16.0.30</value></property>
		<property name="providersauthenticationEntryPoint">
			<list>
				<ref local ref="smbAuthenticationProviderntlmEntryPoint"/>
				<bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
					<property <property name="keyauthenticationManager" valueref="changeThisntlmAuthenticationManager"/>
				</bean>
				<bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider">
					<property name="key" value="changeThis"/>
				</bean>
			</list>
		</property>
	</bean>

The ntlmEntryPoint does not require any configuration, but we can see that the ntlmAuthenticationManager references yet another item that we need to add, the smbAuthenticationManager.
The smbAuthenticationManager provides authentication via the SMB protocol of the authentication information extracted by the NtlmProcessingFilter.

Note

The AnonymousAuthenticationProvider and RememberMeAuthenticationProvider ensure that anonymous users can connect and users that have indicated that they want to be remembered (if the login form is used) can be logged in from the cookie that was previously set. If neither of these things are applicable then it's possible to remove these 2 authentication providers and rely on the smbAuthenticationProvider.

...

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 added to the filter list, now we need to create two more sections that this filter references, the ntlmEntryPoint and the ntlmAuthenticationManager.

The ntlmEntryPoint takes care of the communication for the server to obtain the Windows userid from the browser.
The ntlmAuthenticationManager then sends that information through a list of AuthenticationProviders to validate that it's correct.

Code Block

A SMB NTLM aware authentication provider

	xml
	xml	2
title	NTLM entry point for obtaining the user information from browser
linenumbers	true


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

Code Block

	xml
	xml
title	NTLM authentication manager for verifying the user information from browser
linenumbers	true

	<bean id="smbAuthenticationProviderntlmAuthenticationManager" class="org.acegisecurity.providers.smb.SmbNtlmAuthenticationProviderProviderManager">
		<property name="authorizationProviderproviders">
			<ref <list>
				<ref local="nullDaoAuthenticationProvidersmbAuthenticationProvider"/>
				<bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
		</property>
				<property name="key" value="changeThis"/>
				</bean>

In this case we're referencing yet another item, the nullDaoAuthenticationProvider authentication provider.
The nullDaoAuthenticationProvider is a simple authentication provider that uses a separate UserDetailsService to retrieve the information about what roles a user has, and if you're using the default security.xml file for this that will be the users.properties file.
Alternatively the UserDetailsService could be accessing a database to retrieve the users roles, and later we'll be looking at changing this to use Active Directory (via LDAP) to determine the users roles.

Code Block
xml	xml
2	A SMB simple password authenticator
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> <bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider"> <property name="key" value="changeThis"/> </bean> </list> </property> </bean>

The ntlmEntryPoint does not require any configuration, but we can see that the ntlmAuthenticationManager references yet another item that we need to add, the smbAuthenticationManager.
The smbAuthenticationManager provides authentication via the SMB protocol of the authentication information extracted by the NtlmProcessingFilter.

Note

The AnonymousAuthenticationProvider and RememberMeAuthenticationProvider ensure that anonymous users can connect and users that have indicated that they want to be remembered (if the login form is used) can be logged in from the cookie that was previously set. If neither of these things are applicable then it's possible to remove these 2 authentication providers and rely on the smbAuthenticationProvider.

Setting up the smbAuthenticationProvider is just a matter of configuring the SmbNtlmAuthenticationProvider with the authorizationProvider provider to be used.

Code Block

	xml
	xml
title	A SMB NTLM aware authentication provider
linenumbers	true


	<bean id="smbAuthenticationProvider" class="org.acegisecurity.providers.smb.SmbNtlmAuthenticationProvider">
		<property name="authorizationProvider">
			<ref local="nullDaoAuthenticationProvider"/>
		</property>
	</bean>

If youIn this case we're starting with the default security.xml file that should be the final new section we need to add, since the userDetailsService that it references should already exist. And you could restart the server and assuming that the users.properties file has an entry for each user they should be able to log in without having to enter a username/password.

Customising the the SMB authentication process

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.

...

referencing yet another item, the nullDaoAuthenticationProvider authentication provider.
The nullDaoAuthenticationProvider is a simple authentication provider that uses a separate UserDetailsService to retrieve the information about what roles a user has, and if you're using the default security.xml file for this that will be the users.properties file.
Alternatively the UserDetailsService could be accessing a database to retrieve the users roles, and later we'll be looking at changing this to use Active Directory (via LDAP) to determine the users roles.

Code Block

	xml
	xml
title	A SMB simple password authenticator
linenumbers	true


	<bean id="nullDaoAuthenticationProvider" class="org.acegisecurity.uiproviders.ntlmsmb.NtlmProcessingFilterNullPasswordDaoAuthenticationProvider">
		<property name="defaultDomainuserDetailsService"><value>DOMAINNAME</value></property>
		<property name ref="domainController"><value>172.16.0.30</value></property>userDetailsService"/>
		<property name="authenticationEntryPointuserCache" ref="ntlmEntryPoint"/>
			<bean class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
				<property name="authenticationManager" ref="ntlmAuthenticationManager"/cache">
		<property name = "JCifsProperties			<bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">
			<map>
				<entry<property keyname="jcifs.smb.client.usernamecacheManager">
					<value>username</value>
				</entry>
				<entry key="jcifs.smb.client.password"<bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>
					<value>password</value>
				</entry>property>
			</map>
		</			<property name="cacheName" value="userCache"/>
					</bean>
				</property>
			</bean>
		</property>
	</bean>

Additional properties that can effect the SMB authentication process can be found here.

Selectively applying NTLM authentication

You can specify what IP addresses you want NTLM authentication to apply to, or not apply to, allowing you to support NTLM authentication for internal users and bypass it for external ones, for example (this prevents external users from being presented with a username/password dialogue box that they will probably not have valid values for).

To do this you need to replace the ntlmProcessingFilter, rather than using the org.acegisecurity.ui.ntlm.NtlmProcessingFilter class you should use the If you're starting with the default security.xml file that should be the final new section we need to add, since the userDetailsService that it references should already exist. And you could restart the server and assuming that the users.properties file has an entry for each user they should be able to log in without having to enter a username/password.

Customising the the SMB authentication process

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 Block

	xml
	xml
title	Setting username/password for domain access
linenumbers	true


	<bean id="ntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.

...

Note
All the previous configuration items still apply, and should still be set, for the `IPFilteredNtlmProcessingFilter`. This new version just provides additional configuration options.

The new configuration items that the IPFilteredNtlmProcessingFilter provides are excludedIpAddresses and includedIpAddresses, and are set as a list of IP addresses or address ranges.

Code Block
xml	xml
title	Selectively applying NTLM authentication
linenumbers	true
<bean id="ntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilter">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="defaultDomainauthenticationManager"><value>DOMAINNAME</value></property> <property name ref="domainController"><value>172.16.0.30</value></property>ntlmAuthenticationManager"/> <property name ="authenticationEntryPoint" ref="ntlmEntryPointJCifsProperties"/> <property name="authenticationManager" ref="ntlmAuthenticationManager"/<map> <entry key="jcifs.smb.client.username"> <property name="excludedIpAddresses"> <list> <value>192.168.2.0/24<<value>username</value> <value>138.19.19.50</value> </list>entry> </property> <property<entry namekey="includedIpAddressesjcifs.smb.client.password"> <list><value>password</value> <value>172.16.0.0/16</value></entry> </list>map> </property> </bean>

You don't need to provide both excludedIpAddresses and includedIpAddresses, in fact it's more than likely that you'll only want to provide one, either listing those addresses that should be NTLM authenticated, and everyone else isn't, or listing those addresses that should not be NTLM authenticated and everyone else should. But, if you do provide both then the exclude list is checked first. Also, if the include list is set then the IP address must appear in the list for NTLM authentication to be attempted.

Info
The IPFilteredNtlmProcessingFilter class is provided in version 1.0.7 or later of the `org.acegisecurity.ntlm` bundle

As of version 1.3.4 of the org.acegisecurity.ntlm bundle there's an additional property that can be set for the IPFilteredNtlmProcessingFilter, and that's domainRole, which when set will add the role (exactly as it appears in the security.xml file) to the list of roles the user has. This allows you to utilise multiple Active Directory domain to authenticate user and provide access control based on what domain the user was authenticated againstAdditional properties that can effect the SMB authentication process can be found here.

Selectively applying NTLM authentication

You can specify what IP addresses you want NTLM authentication to apply to, or not apply to, allowing you to support NTLM authentication for internal users and bypass it for external ones, for example (this prevents external users from being presented with a username/password dialogue box that they will probably not have valid values for).

To do this you need to replace the ntlmProcessingFilter, rather than using the org.acegisecurity.ui.ntlm.NtlmProcessingFilter class you should use the org.acegisecurity.ui.ntlm.IPFilteredNtlmProcessingFilter, this implementation of the NtlmProcessingFilter can then be provided with additional configuration items specifying which IP addresses should/shouldn't be provided with the option to authenticate using NTLM.

Note
All the previous configuration items still apply, and should still be set, for the `IPFilteredNtlmProcessingFilter`. This new version just provides additional configuration options.

The new configuration items that the IPFilteredNtlmProcessingFilter provides are excludedIpAddresses and includedIpAddresses, and are set as a list of IP addresses or address ranges.

Code Block

	xml
	xml
title	Using multiple domain for Selectively applying NTLM authentication
linenumbers	true

	<bean id="ntlmProcessingFilterInternalntlmProcessingFilter" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilterIPFilteredNtlmProcessingFilter">
		<property name="defaultDomain"><value>INTERNAL<><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="doaminRole"><value>ROLE_INTERNAL</value><excludedIpAddresses">
			<list>
				<value>192.168.2.0/24</value>
				<value>138.19.19.50</value>
			</list>
		</property>
		<property name="includedIpAddresses">
			<list>
				<value>172.16.0.0/16</value>
			</list>
		</property>
	</bean>

	<bean id="ntlmProcessingFilterExternal" class="org.acegisecurity.ui.ntlm.NtlmProcessingFilter">
		<property name="defaultDomain"><value>EXTERNAL</value></property>
		<property name="domainController"><value>201.20.109.76</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
		<property name="doaminRole"><value>ROLE_EXTERNAL</value></property>
		<property name="includedIpAddresses">
			<list>
				<value>201.20.0.0/16</value>
			</list>

You don't need to provide both excludedIpAddresses and includedIpAddresses, in fact it's more than likely that you'll only want to provide one, either listing those addresses that should be NTLM authenticated, and everyone else isn't, or listing those addresses that should not be NTLM authenticated and everyone else should. But, if you do provide both then the exclude list is checked first. Also, if the include list is set then the IP address must appear in the list for NTLM authentication to be attempted.

Info
The IPFilteredNtlmProcessingFilter class is provided in version 1.0.7 or later of the `org.acegisecurity.ntlm` bundle

As of version 1.3.4 of the org.acegisecurity.ntlm bundle there's an additional property that can be set for the IPFilteredNtlmProcessingFilter, and that's defaultRole, which when set will add the role (exactly as it appears in the security.xml file) to the list of roles the user has. This allows you to utilise multiple Active Directory domain to authenticate user and provide access control based on what domain the user was authenticated against.
Note: If you're using LDAP to provide the users roles then it's also possible to set a defaultRole in the LDAP populator.

Code Block

	xml
	xml
title	Using multiple domain for authentication
linenumbers	true


	<bean id="ntlmProcessingFilterInternal" class="org.acegisecurity.ui.ntlm.IPFilteredNtlmProcessingFilter">
		<property name="defaultDomain"><value>INTERNAL</value></property>
		<property name="domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
		<property name="includedIpAddresses">
			<list>
				<value>172.16.0.0/16</value>
			</list>
		</property>
		<property name="defaultRole"><value>ROLE_INTERNAL</value></property>
	</bean>

	<bean id="ntlmProcessingFilterExternal" class="org.acegisecurity.ui.ntlm.IPFilteredNtlmProcessingFilter">
		<property name="defaultDomain"><value>EXTERNAL</value></property>
		<property name="domainController"><value>201.20.109.76</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
		<property name="includedIpAddresses">
			<list>
				<value>201.20.0.0/16</value>
			</list>
		</property>
		<property name="defaultRole"><value>ROLE_EXTERNAL</value></property>
	</bean>

Not that to enable this both filters need to be added to the filter chain:

Code Block

	xml
	xml
title	Adding NTLM filter to request filter chain
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,ntlmProcessingFilter1,ntlmProcessingFilter2,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
				/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter1,ntlmProcessingFilter2,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
			</value>
		</property>
	</bean>

Active Directory Groups

Information about what active directory groups a user belongs to can be used to provide role information to Weave for the users that are authenticated using Windows integrated authentication, removing the need to utilise the users.properties file.

This information is obtained from an AD domain controller using the LDAP protocol.

Info
When setting up the LDAP integration it's recommended that the JXplorer tool be used to test the settings, because the JXplorer uses the LDAP server in the same way as Weave but provides an interactive method for verifying the settings. Image Added

To enable LDAP as a source of authentication information the ntlmAuthenticationManager we created earlier needs to be altered to use an LdapAuthenticationProvider rather than the SmbAuthenticationProvider.

So we fist need to change the ntlmAuthenticationManager to

Code Block

	xml
	xml
title	Enabling LDAP support for authenticating users
linenumbers	true


	<bean id="ntlmAuthenticationManager" class="org.acegisecurity.providers.ProviderManager">
		<property name="providers">
			<list>
				<ref local="ldapAuthenticationProvider"/>
				<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>

And then setup the new ldapAuthenticationProvider as follows:

Code Block

	xml
	xml
title	LDAP authentication provider that can handle NTLM authenticated users
linenumbers	true


	<bean id="ldapAuthenticationProvider" class="org.acegisecurity.ui.ntlm.ldap.authenticator.NtlmAwareLdapAuthenticationProvider">
		<constructor-arg>
			<ref local="authenticatorLdap"/>
		</constructor-arg>
		<constructor-arg>
			<ref local="populatorLdap"/>
		</constructor-arg>
	</bean>

This provider uses two other item to provide information, the authenticationLdap bean and the populatorLdap bean.

Note
We use the `NtlmAwareLdapAuthenticationProvider` here because the user has been authenticated using their windows userid. If you're not using windows integrated authentication you can still LDAP to provide the roles for a user, but in that case you'd use the `LdapUserDetailsService` which isn't covered here.

The authentication would be configured as follows:

Code Block

	xml
	xml
title	The authenticator that will search an LDAP directory for the user
linenumbers	true


	<bean id="authenticatorLdap" class="org.acegisecurity.ui.ntlm.ldap.authenticator.NtlmAwareLdapAuthenticatorImpl">
		<constructor-arg>
			<ref local="initialDirContextFactory"/>
		</constructor-arg>
		<property name="userSearch">
			<ref local="userSearchLdap"/>
		</property>
	</bean>

...

Which as we can see requires two other items, the initialDirContextFactory and the userSearchLdap.

The initialDirContextFactory is also used by the userSearchLdap and the populaterLdap beans so we'll look at that first

Code Block

	xml
	xml
title	Adding NTLM filter to request filter chainSetting up a connection to the LDAP server
linenumbers	true

	<bean id="filterChainProxyinitialDirContextFactory" class="org.acegisecurity.utilldap.FilterChainProxyDefaultInitialDirContextFactory">
		<property<constructor-arg namevalue="filterInvocationDefinitionSource"ldap://192.168.0.16:389/"/>
			<value>
				CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
				PATTERN_TYPE_APACHE_ANT<property name="managerDn">
				/server/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter1,ntlmProcessingFilter2,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
				/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter1,ntlmProcessingFilter2,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
			<<value>CN=Administrator,OU=Users,DC=cohga,DC=local</value>
		</property>
		<property name="managerPassword">
			<value>password</value>
		</property>
	</bean>

Active Directory Groups

Information about what active directory groups a user belongs to can be used to provide role information to Weave for the users that are authenticated using Windows integrated authentication, removing the need to utilise the users.properties file.

This information is obtained from an AD domain controller using the LDAP protocol.

When setting up the LDAP integration it's recommended that the JXplorer tool be used to test the settings, because the JXplorer uses the LDAP server in the same way as Weave but provides an interactive method for verifying the settings.

To enable LDAP as a source of authentication information the ntlmAuthenticationManager we created earlier needs to be altered to use an LdapAuthenticationProvider rather than the SmbAuthenticationProvider.

So we fist need to change the ntlmAuthenticationManager to

xml

Code Block
xml

Info
Connecting to the LDAP server with JXplorer Image Added

Info
Connected to the LDAP server with JXplorer Image Added

Here the ip address, manager distinguished name and manager passwords must be set to appropriate values for a user that can read for the active directory server.
I've used the Administrator user to connect to LDAP in the example above but you do not want to do that on a production system (and you should be worried if your IT department gives you the password for this user just to do this). Instead you should have IT create a limited user account that you can connect with.

Note

The dsquery.exe program can be used to find the distinguished name of the user: dsquery user

Image Added

The two final beans, the userSearchLdap and populatorLdap also require information that is specific to the environment you're running within, the userSearchLdap beans would be something like the following:

Code Block

	xml
	xml
title	Setting up an LDAP search for a user
linenumbers	true

	<bean id="ntlmAuthenticationManageruserSearchLdap" class="org.acegisecurity.providersldap.search.ProviderManagerFilterBasedLdapUserSearch">
		<property name="providers"><constructor-arg>
			<list><value>OU=Users,DC=cohga,DC=local</value>
				<ref local="ldapAuthenticationProvider"/>
				<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></constructor-arg>
		<constructor-arg>
			<value>(sAMAccountName={0})</value>
		</constructor-arg>
		<constructor-arg>
			<ref local="initialDirContextFactory" />
		</constructor-arg>
		<property name="searchSubtree">
			<value>true</value>
		</property>
	</bean>

...

This configuration assumes that there is a branch in the tree matching the first constructor arg and that the sAMAccountName value of any users found there will match the username they logged into Windows with.

Info
JXplorer showing a users entry Image Added

Finally the populatorLdap is responsible for mapping the username to the roles and would be configured as follows

Code Block

	xml
	xml
title	Setting up an LDAP serach for groups
linenumbers	true

	<bean id="ldapAuthenticationProviderpopulatorLdap" class="org.acegisecurity.uiproviders.ntlm.ldap.authenticatorpopulator.NtlmAwareLdapAuthenticationProviderDefaultLdapAuthoritiesPopulator">
		<constructor-arg>
			<ref local="authenticatorLdapinitialDirContextFactory"/>
		</constructor-arg>
		<constructor-arg>
			<value>OU=Weave,DC=cohga,DC=local</value>
		</constructor-arg>arg>
		<property name="groupRoleAttribute">
			<value>cn</value>
		<constructor-arg></property>
			<ref<property localname="populatorLdapsearchSubtree"/>
			<<value>true</constructor-arg>value>
	</bean>

This provider uses two other item to provide information, the authenticationLdap bean and the populatorLdap bean.

The authentication would be configured as follows

Code Block

xml

linenumbers

true


	<bean id="authenticatorLdap" class="org.acegisecurity.ui.ntlm.ldap.authenticator.NtlmAwareLdapAuthenticatorImpl	</property>
		<property name="rolePrefix">
		<constructor-arg>	<value>ROLE_</value>
		</property>
		<ref<property localname="initialDirContextFactory"/>convertToUpperCase">
			<value>true</value>
		</constructor-arg>property>
		<property name="userSearchgroupSearchFilter">
			<ref local="userSearchLdap"/><value>(member={0})</value>
		</property>
	</bean>

Which as we can see requires two other items, the initialDirContextFactory and the userSearchLdap.

The initialDirContextFactory is also used by the userSearchLdap and the populaterLdap beans so we'll look at that first

...


	<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
		<constructor-arg value="ldap://192.168.0.16:389/"/>
		<property name="managerDn">
			<value>CN=Administrator,OU=Users,DC=cohga,DC=local</value>
		</property>
		<property name="managerPassword">
			<value>password</value>
		</property>
	</bean>

Here the ip address, manager distinguished name and manager passwords must be set to appropriate values for a user that can read for the active directory server.

The two final beans, the userSearchLdap and populatorLdap also require information that is specific to the environment you're running within, the userSearchLdap beans would be as follows

...


	<bean id="userSearchLdap" class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
		<constructor-arg>
			<value>OU=Users,DC=cohga,DC=local</value>
		</constructor-arg>
		<constructor-arg>
			<value>(sAMAccountName={0})</value>
		</constructor-arg>
		<constructor-arg>
			<ref local="initialDirContextFactory" />
		</constructor-arg>
		<property name="searchSubtree">
			<value>true</value>
		</property>
	</bean>

This configuration assumes that there is a branch in the tree matching the first constructor arg and that the sAMAccountName value of any user found there will match the username they logged into Windows with.

Finally the populatorLdap is responsible for mapping the username to the roles and would be configured as follows

Code Block
xml	xml
title	Setting to populate users roles from LDAP
linenumbers	true
<bean id="populatorLdap <property name="defaultRole"> <value>ROLE_USERS</value> </property> </bean>

This configuration is setup to search for groups and use the member attribute of the group to determine if the user belongs.
This setup is assuming that there has been a security group created in the Active Directory server called Weave and that the roles/groups for Weave are created under there.
This "should" take the active directory groups that the user belongs to and convert them to a format that's usable in Weave, and also assigns a default ROLE_USERS role to all users (which you can remove if it's not appropriate).

Info
JXplorer showing a group entry Image Added

You will then need to create Weave Access Control Lists utilising the roles that users will be assigned.

Supplementing LDAP Roles

As of version 1.4.4 of the org.acegisecurity.ntlm bundle it's possible to supplement the roles set via LDAP from a separate users details service (i.e. for example from a user.properties type file).

In this updated bundle there is a new SupplementedLdapAuthoritiesPopulator that can replace the DefaultLdapAuthoritiesPopulator in your security.xml and this authorities populator can be configured with an additional user details service, which if set will be used to look up the user being authenticated and if they're found the roles provided by the user details service will be added to the current user.

To implement the new authorities populator you should change:

Code Block

	xml
	xml
title	Old DefaultLdapAuthoritiesPopulator
linenumbers	true


<bean id="populator" class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
	...
</bean>

to

Code Block

	xml
	xml
title	New SupplementedLdapAuthoritiesPopulator with reference to user details service
linenumbers	true


<bean id="populator" class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
		<constructor-arg>
			<ref local="initialDirContextFactory"/>
		</constructor-arg>
		<constructor-arg>
			<value>OU=Users,DC=cohga,DC=local</value>
		</constructor-arg>
	.providers.ldap.populator.SupplementedLdapAuthoritiesPopulator">
	<property name="groupRoleAttribute"userDetailsService" ref="ldapDetailsService"/>
			<value>cn</value>
		...
</property>
		<property name="searchSubtree">
			<value>true</value>
		</property>
		<property name="rolePrefix">
			<value>ROLE_</value>
		</property>
		<property name="convertToUpperCase">
			<value>true</value>
		</property>
	bean>

This will change it from DefaultLdapAuthoritiesPopulator to SupplementedLdapAuthoritiesPopulator and add a reference to the service that will provide the additional role information, which can be included by adding:

Code Block

	xml
	xml
title	New user details service reading roles from a file
linenumbers	true


<bean id="ldapDetailsService" class="org.acegisecurity.userdetails.memory.InMemoryDaoImpl">
	<property name="groupSearchFilteruserProperties">
			<value>(member={0})</value>
		</property>
	<bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
			<property name="location" value="defaultRoleldap.properties"/>
			<value>ROLE_USERS</value>
	</bean>
	</property>
	</bean>

This "should" take the active directory groups that the user belongs to and convert them to a format that's usable in Weave, and also assigns a default ROLE_USERS role to all users (which you can remove if it's not appropriate).

You will then need to create Weave Access Control Lists utilising the roles that users will be assigned.

You may need to ensure that logging of the security related information is output by weave to be able to determine what roles a user is assigned to when they login. To do this ensure that the following two lines appear in logging.properties and any others referencing security are removed (in case they reduce the logging)

...


log4j.logger.org.acegisecurity=DEBUG
log4j.logger.com.cohga.server.security=DEBUG

Then when someone is logged in via active directory the log file will show what roles they were granted, which should help you to understand what role names must be used in the access control listsThen you can create the ldap.properties, which has the same format as the existing users.properties file, in the workspace directory and any user listed there will have those roles added. e.g.

shaun=password,ROLE_TEST

Note the password is ignored, we're just mapping the userid to the roles and adding those roles to the current user.
There is currently no capability to remove roles or disable the users access using the SupplementedLdapAuthoritiesPopulator.

Alternatively you could also use the following if you just had a couple of users:

Code Block

	xml
	xml
title	New user details service reading roles from its configuration
linenumbers	true


<bean id="ldapDetailsService" class="org.acegisecurity.userdetails.memory.InMemoryDaoImpl">
	<property name="userMap">
		<value>
			shaun=password,ROLE_TEST
		</value>
	</property>
</bean>

You could even use the JdbcDaoSupport class if you wanted to get this information from a database.

Versions Compared

Old Version 6

New Version Current

Key

Integrated Authentication

Debugging

Integrated Authentication

Customising the the SMB authentication process

Selectively applying NTLM authentication

Customising the the SMB authentication process

Selectively applying NTLM authentication

Active Directory Groups

Active Directory Groups

Supplementing LDAP Roles