Add support for userDN which cannot be composed by adding a prefix an…

[rubenvanwanzeele]

…d a suffix to the username at all. So where authentication is handled with the userPrincipalName, but where the userDN is required for authorization. I haven't found a REALM implementation that resolves this issue.

The setup I'm handling is a AD one. For making this more concrete: The userPrincipalName format is [email protected] while the distinguishedName format is CN=John The Great,CN=Users,DC=whatever,DC=whatever,DC=com The username is seen as {firstName}{lastName} (without the spaces), while the group membership (used for authorization) is handled with the userDN.

Currently I created a custom implementation for supporting this LDAP; but I was wondering whether I am the only one facing this problem. Instead of working with an userDnTemplate, I worked with an authenticationTemplate and a user search base. Using those, I was able to retrieve the userDN. This approach still supports providing the userDN template as authenticationTemplate (I supposed this to be the case when the userSearchBase is not provided).

This is the config file I'm currently using: ldapRealm = com.company.ldap.realm.CustomLdapRealm ldapRealm.authenticationTemplate = {0}@whatever.whatever.com ldapRealm.userSearchBase = CN=Users,DC=whatever,DC=whatever,DC=com ldapRealm.userSearchFilter = (sAMAccountName={0}) ldapRealm.groupSearchBase = OU=Groups,DC=whatever,DC=whatever,DC=com ldapRealm.groupSearchFilter = (member={0}) ldapRealm.groupSearchFilterAttribute = distinguishedName ldapRealm.groupRoleAttribute = cn ldapRealm.contextFactory.url = ldap://whatever.whatever.com:389 ldapRealm.contextFactory.systemUsername = system-user ldapRealm.contextFactory.systemPassword = system-password

I have a local branch where I've implemented the changes in case you're willing to check them out.

Please be critic to what I've done, Your experience in this area might result in a better approach for handling this.