Bug 48629 - JNDIRealm and roleNested doesn't work with roleSearch="(member={1})"
Summary: JNDIRealm and roleNested doesn't work with roleSearch="(member={1})"
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.24
Hardware: All All
: P2 minor (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-01-27 13:35 UTC by tahitiangabriel
Modified: 2010-04-11 08:51 UTC (History)
0 users

patch (702 bytes, application/octet-stream)
2010-01-27 13:35 UTC, tahitiangabriel
add roleNested entry in doc (434 bytes, patch)
2010-02-01 10:30 UTC, tahitiangabriel
Details | Diff
bring {1} to work in JNDIRealm with nested roles (3.21 KB, patch)
2010-02-09 06:28 UTC, Felix Schumacher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tahitiangabriel 2010-01-27 13:35:47 UTC
Created attachment 24898 [details]

roleNested introduced with Tomcat 6.0.24 works well with roleSearch="(member={0})", but not with roleSearch="(member={1})"

From tomcat doc :
"Use {0} to substitute the distinguished name (DN) of the user, and/or {1} to substitute the username."

I've attached a patch to change line :
filter = roleFormat.format(new String[] { groupDN });
into :
filter = roleFormat.format(new String[] { groupDN, groupDN });

Like that it handles both {0} and {1}.


Comment 1 Mark Thomas 2010-01-30 15:10:38 UTC
This has been fixed in trunk and proposed for 6.0.x.

Many thanks for the patch.
Comment 2 Konstantin Kolinko 2010-01-30 15:58:10 UTC
I do not think that this patch is good.

See, groupDN is a full distinguished name of a role, while in your case {1} was just a name. Does it work for your configuration?


For reference, previous discussion:

In any case,
1) If your configuration works when you do
roleSearch="(member={1})" when {1} is a DN of a group,
 then I think we would better provide a separate attribute to specify search filter for the nested roles.

roleSearch="(member={1})" roleNestedSearch="(member={0})"
where {0} in the second case is a group DN, as it is now.

We can default roleNestedSearch to be the same as roleSearch when roleNested="true",  and to default roleNested="true" when roleNestedSearch is explicitly specified.

2) If you need unqualified rolename,
it can be obtained, but the patch will be more complicated.

In the code we have
  Set<String> newGroupDNs = new HashSet<String>(groupMap.keySet());
  for (String groupDN : newGroupDNs) {
  groupMap.put(dname, name);

We should replace Set<String> newGroupDNs  with
  Map<String,String> newGroups = new HashMap<String,String>(groupMap);

Perform iteration over entrySet of the map:
  for (Map.Entry<String,String> newGroup : newGroups.entrySet()) {

Then, newGroup.getKey() will give us the groupDN and newGroup.getValue() will give us the group name.

3) It would be nice to update realm-howto.html with documentation on using the roleNested="true". It is not documented yet.  Can you propose a patch for /webapps/docs/realm-howto.xml,  or at least describe your configuration so that it can be provided as an example there?
Comment 3 tahitiangabriel 2010-02-01 10:02:22 UTC
I think having roleNestedSearch="(member={0})" is a very good idea. Like that it should work for all kind of configurations.

For the moment I've switched to the "member={0}" instead of "member={1}", so I can use tomcat 6.0.24 in production.

Here's my conf (for a Domino 8.5) :
<Realm className="org.apache.catalina.realm.JNDIRealm"

I'm not sure my english is good enough to update the doc...
Comment 4 tahitiangabriel 2010-02-01 10:30:40 UTC
Created attachment 24916 [details]
add roleNested entry in doc

Here's a small patch to add the roleNested entry in the doc.
Maybe it should be nice to add an example also.
Comment 5 Felix Schumacher 2010-02-09 06:28:21 UTC
Created attachment 24953 [details]
bring {1} to work in JNDIRealm with nested roles

Made the corrections proposed by Konstantin Kolinko.
Comment 6 Mark Thomas 2010-03-08 18:01:55 UTC
Thanks for the patch.

I have applied it to trunk and proposed it for 6.0.x.
Comment 7 Mark Thomas 2010-04-11 08:51:36 UTC
Thanks again for the patch. It has been applied to 6.0.x and will be includedin 6.0.27 onwards.