In our humble opinion, 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:

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

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

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-12) was last changed on 04-Oct-2017 12:21 by jim