SEC-427: Make LdapAuthoritiesPopulator optional

[spring-projects-issues]

["Stefan Podkowinski":https://jira.spring.io/secure/ViewProfile.jspa?name=spod](Migrated from ["SEC-427":https://jira.spring.io/browse/SEC-427?redirect=false]) said:

Today I was trying to update from rc2 to the lattest release. Unfortunately I had a pretty hard time without any success in the end. The problem is that after the introduction of the changes discussed in SEC-264, group based authorities lookup through ldap is now required in the lattest LdapAuthenticationProvider implementation. However, in our current ldap scenario we use only user attributes for getting the authorities, e.g. 'department'. Groups are not available at all! This worked worked fantastic with rc2 so far.

Following the initial thoughts Luke Taylor's (again SEC-264) .. "The handling of role attributes from the user's entry would be dealt with in the mapper, so that the LdapUserDetails object returned from the authenticator could potentially be used directly by Acegi. The DefaulLdapAuthoritiesPopulator would then only be responsible for additional role searches (i.e. other roles which were not part of the user's entry) and an authorities populator would no longer be required as part of the configuration. "

.. I would suggest to make the AuthoritiesPopulator optional in the LdapAuthenticationProvider. I.e. create a new constructor and add a check for null in createUserDetails(). (patch could be provided if you agree with these changes)

[spring-projects-issues]

["Luke Taylor":https://jira.spring.io/secure/ViewProfile.jspa?name=luke] said:

This seems sensible enough. I don't see why the current setup should be so hard to work with though - just use a null implementation of the populator.

[spring-projects-issues]

["Luke Taylor":https://jira.spring.io/secure/ViewProfile.jspa?name=luke] said:

I've added a Null populator implementation to the class and an extra constructor which just takes the authenticator as an argument.