Windows Authentication

Description

Implementing Windows security generally involves two processes, authenticating determining who the user with Weave is using their Windows username and userid then using information contained in an Active Directory server to determine what roles a user has access to.

The first process can be implemented independently of the second, and while the second could be implemented independently of the first it doesn't really make sense.

Integrated Authentication

To implement Windows integrated authentication and allow internal users to login to Weave automatically using their Windows username involves editing that is a user can be identified by their Windows userid but their roles can be read from a database or the user.properties file rather than from Active Directory.

Info
The authentication of the Windows user information if performed using the SMB protocol. Access to the role information in Active Directory is performed using the LDAP protocol.

The configuration for Windows and Active Directory authentication is done via 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

...

as all the authentication is.

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.

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	Default request filter chain
linenumbers	true

	<bean id="ntlmProcessingFilterfilterChainProxy" class="org.acegisecurity.uiutil.ntlm.NtlmProcessingFilterFilterChainProxy">
		<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.

Code Block

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="smbAuthenticationProvider"/>
				<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>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.

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	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,ntlmProcessingFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
				/**=httpSessionContextIntegrationFilter,ntlmProcessingFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
			</value>
		</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 smbAuthenticationManager.

...

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	The root NTLM filter definition
linenumbers	true

	<bean id="smbAuthenticationProviderntlmProcessingFilter" class="org.acegisecurity.providersui.smbntlm.SmbNtlmAuthenticationProviderNtlmProcessingFilter">
		<property name="authorizationProvider">defaultDomain"><value>DOMAINNAME</value></property>
			<ref<property localname="nullDaoAuthenticationProvider"/domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		</property><property name="authenticationManager" ref="ntlmAuthenticationManager"/>
	</bean>

Again a fairly simple section, but again it references yet another section that we need to add, the nullDaoAuthenticationProvider.

...

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

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

	<bean id="nullDaoAuthenticationProviderntlmEntryPoint" class="org.acegisecurity.providersui.smbntlm.NullPasswordDaoAuthenticationProviderNtlmProcessingFilterEntryPoint">
		<property name="userDetailsService" ref="userDetailsService"//>

Code Block

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


	<bean id="ntlmAuthenticationManager" class="org.acegisecurity.providers.ProviderManager">
		<property name="userCache"providers">
			<list>
				<ref local="smbAuthenticationProvider"/>
				<bean class="org.acegisecurity.providers.daoanonymous.cache.EhCacheBasedUserCacheAnonymousAuthenticationProvider">
					<property name="cache"key" value="changeThis"/>
				</bean>
				<bean class="org.springframeworkacegisecurity.cacheproviders.ehcacherememberme.EhCacheFactoryBeanRememberMeAuthenticationProvider">
						<property name="cacheManagerkey">
							<bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean value="changeThis"/>
						</property>bean>
			</list>
			<property name="cacheName" value="userCache"/>
					</bean>
				</property>
			</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>

Active Directory

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 utilize the users.properties file.

This information is obtained using the LDAP specification.

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

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>

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
title	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>
		</property>
	</bean>

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="ntlmAuthenticationManagerntlmProcessingFilter" class="org.acegisecurity.ui.providersntlm.ProviderManagerNtlmProcessingFilter">
		<property name="providers">defaultDomain"><value>DOMAINNAME</value></property>
			<list>
				<ref local="ldapAuthenticationProvider"/>
				<bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
					<property name="domainController"><value>172.16.0.30</value></property>
		<property name="authenticationEntryPoint" ref="ntlmEntryPoint"/>
		<property name="keyauthenticationManager" valueref="changeThisntlmAuthenticationManager"/>
				</bean>
				<bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider<property name = "JCifsProperties">
			<map>
				<property<entry name="key" value="changeThis"/jcifs.smb.client.username">
					<<value>username</bean>value>
				</list>entry>
		</property>
	</bean>

And then setup the new ldapAuthenticationProvider as follows

Code Block

xml

linenumbers

true


	<bean id="ldapAuthenticationProvider" class="org.acegisecurity.ui.ntlm.ldap.authenticator.NtlmAwareLdapAuthenticationProvider">
		<constructor-arg>
			<ref local="authenticatorLdap"/>		<entry key="jcifs.smb.client.password">
					<value>password</value>
				</entry>
			</map>
		</constructor-arg>
		<constructor-arg>
			<ref local="populatorLdap"/>
		</constructor-arg>
	property>
	</bean>

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

The authentication would be configured as follows

...

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.

...

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

The initialDirContextFactory is also used by the userSearchLdap and the populaterLdap beans so we'll look at that firstNtlmProcessingFilter 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	Selectively applying NTLM authentication
linenumbers	true

	<bean id="initialDirContextFactoryntlmProcessingFilter" class="org.acegisecurity.ldapui.ntlm.DefaultInitialDirContextFactoryIPFilteredNtlmProcessingFilter">
		<constructor-arg<property valuename="defaultDomain"ldap:><value>DOMAINNAME<//172value></property>
		<property name="domainController"><value>172.16.0.30:38930</"value></>property>
		<property name="managerDn"authenticationEntryPoint" ref="ntlmEntryPoint"/>
			<value>CN=username,OU=Users,DC=example,DC=com,DC=au</value>
		</property>
		<property name="authenticationManager" ref="ntlmAuthenticationManager"/>
		<property name="managerPasswordexcludedIpAddresses">
			<value>password</value><list>
			</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=example,DC=com,DC=au</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

linenumbers

true


	<bean id="populatorLdap	<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>

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	Setting up a connection to the LDAP server
linenumbers	true


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

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="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 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="populatorLdap" class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
		<constructor-arg>
			<ref local="initialDirContextFactory"/>
		</constructor-arg>
		<constructor-arg>
			<value>OU=Weave,DC=cohga,DC=local</value>
		</constructor-arg>
		<property name="groupRoleAttribute">
			<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>
		<property name="groupSearchFilter">
			<value>(member={0})</value>
		</property>
		<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=example,DC=com,DC=au</value>
		</constructor-arg>
		<property name="groupRoleAttribute">
			<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>
		<property name="groupSearchFilter">
			<value>(member={0})</value>
		</property>
		<property name="defaultRole">
			<value>ROLE_USERS</value>
		</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 alos 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 utilizing 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

...

SupplementedLdapAuthoritiesPopulator">
	<property name="userDetailsService" ref="ldapDetailsService"/>
	...
</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="userProperties">
		<bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
			<property name="location" value="ldap.properties"/>
		</bean>
	</property>
</bean>

Then 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 2

New Version Current

Key

Windows Authentication

Description

Integrated Authentication

Debugging

Integrated Authentication

Active Directory

Customising the the SMB authentication process

Selectively applying NTLM authentication

Active Directory Groups

Supplementing LDAP Roles

Page Comparison

Versions Compared

Old Version 2

New Version Current

Key

Windows Authentication

Description

Integrated Authentication

Debugging

Integrated Authentication

Active Directory

Customising the the SMB authentication process

Selectively applying NTLM authentication

Active Directory Groups

Supplementing LDAP Roles