When using search-and-bind strategy, the user attributes are already returned in the first search.
If the user happens to not have privileges to perform a search, the second search may fail.
(user only has bind privileges)
See https://github.com/cloudfoundry/uaa/issues/342
Previously there were some incorrect dependency versions. This commit fixes
that.
We added dependencyManagement for Spring Framework and corrected
Thymeleaf and embedded redis versions.
Currently the search filter used when retrieving user details is hard coded.
New property in ActiveDirectoryLdapAuthenticationProvider:
- searchFilter - the LDAP search filter to use when searching for authorities,
default to search using 'userPrincipalName' (current) OR 'sAMAccountName'
Prior to this change, ApacheDSContainer created a LdifFileLoader
without a ClassLoader. This limited its ability to load LDIF files
and causes a problem with an executable war in Spring Boot. See [1]
for details.
ApacheDSContainer now initialises LdifFileLoader with a ClassLoader.
This allows it to locate LDIF files packaged in WEB-INF/classes in
the case of an executable war file. The executable jar case was not
affected by this problem as, in that case, the LDIF file is pacakaged
in the root of the jar and is accessible via getSystemResourceAsStream
[1] https://github.com/spring-projects/spring-boot/issues/1550
This refers to groups that have member: <another group DN> as an attribute
- Add in a utility method in the SpringSecurityLdapTemplate to retrieve multiple attributes and their values from an LDAP record
- Make the DefaultLdapAuthoritiesPopulator more extensible
- Add an LdapAuthority object that holds the DN in addition to other group attributes
- Add a NestedLdapAuthoritiesPopulator to search statically nested groups
