In our humble opinion, [Groups are Bad|Groups Are Bad] and we needed to utilize attribute on the individual user entry to determine the roles.
Adding the realm configuration below allows this to work:
%%prettify
{{{
<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="10"
connectionURL="ldap://192.168.1.7:389"
alternateURL="ldap://192.168.1.8:389"
userBase="ou=people,dc=yourdomwin,dc=com"
userSearch="(cn={0})"
userSubtree="true"
userRoleName="dictcrole"
connectionName="cn=admin,ou=...,cn=...,dc=yourdomwin,dc=com"
connectionPassword="********"
/>
}}}
/%
The values of the "dictcrole" attribute on the user entry will be utilized to determine the roles.
We are using this with [JSPWiki] and have some information on [JSPWiki Roles and Groups] compared to [Container Authentication and Authorization|Tomcat And LDAP].
!!!What Really Happens
Being [LDAP] guys, we wanted to know what Tomcat was really doing. We turned on a trace on our [LDAP] [DSA] and we found out:
%%prettify
{{{
19:00:00 958E1BA0 LDAP: (192.168.1.4:40693)(0x001e:0x60) DoBind on connection 0x9ced280
19:00:03 958E1BA0 LDAP: (192.168.1.4:40693)(0x001e:0x60) Bind name:cn=admin,ou=...,dc=yourdomwin,dc=com, version:3, authentication:simple
18:34:40 958E1BA0 LDAP: (192.168.1.4:40693)(0x001e:0x60) Sending operation result 0:"":"" to connection 0x9ced280
<!-- Above we see the bind on an existing connection of the user defined in the "connectionName" from the Realm element -->
19:00:00 959E2BA0 LDAP: (192.168.1.4:40693)(0x001f:0x63) DoSearch on connection 0x9ced280
03:29:04 959E2BA0 LDAP: (192.168.1.4:40693)(0x001f:0x63) Search request:
base: "ou=people,dc=yourdomwin,dc=com"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(cn=jim)"
attribute: "dictcrole"
19:00:00 959E2BA0 LDAP: (192.168.1.4:40693)(0x001f:0x63) Sending search result entry "cn=jim,ou=...,ou=people,dc=yourdomwin,dc=com" to connection 0x9ced280
19:00:04 959E2BA0 LDAP: (192.168.1.4:40693)(0x001f:0x63) Sending operation result 0:"":"" to connection 0x9ced280
<!-- Above we see the search for the username as entered, jim, which is determined by the "userSearch" from the Realm element
Some things to note, the value of the userRoleName (dictcrole) is the only attribute requested which is a good thing as it is more efficient.
The scope:2 is determined by the Realm element userSubtree="true" was utilized for the search.
The base: "ou=people,dc=willeke,dc=com" is determined by the Realm element userBase="ou=people,dc=willeke,dc=com"
-->
18:10:25 93B94BA0 LDAP: (192.168.1.4:40693)(0x0020:0x60) DoBind on connection 0x9ced280
19:00:01 93B94BA0 LDAP: (192.168.1.4:40693)(0x0020:0x60) Bind name:cn=jim,ou=...,ou=people,dc=yourdomwin,dc=com, version:3, authentication:simple
18:34:40 93B94BA0 LDAP: (192.168.1.4:40693)(0x0020:0x60) Sending operation result 0:"":"" to connection 0x9ced280
<!-- Above we see the bind on an existing connection, but a different connection than the connectionName, for the of the user found in the previous search -->
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) DoSearch on connection 0x9ced280
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) Search request:
base: ""
scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=*)"
no attributes
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) Empty attribute list implies all user attributes
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) Server configured to also include operational attributes
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) Sending search result entry "" to connection 0x9ced280
19:00:00 B6E23BA0 LDAP: (192.168.1.4:40693)(0x0021:0x63) Sending operation result 0:"":"" to connection 0x9ced280
<!-- The above is a keep-alive for the "connectionName" connection as it is a search of the rootDSE of the LDAP server. -->
}}}
/%!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]