[GLASSFISH-3509] LDAP performance issues: LDAPRealm.dynamicGroupSearch Created: 17/Aug/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: alfish Assignee: raharsha
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 3,509


Regarding class "com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" revison
1.6, I have 2 enhancement requests regarding LDAP performance:

I was interested in the JAAS-LDAP Provider, when I noticed design glitches in
handling dynamic ldap groups (groups that only have a memberURL attribute) that
have a severe influence on ldap performance:

1) Regarding: public static final String DYNAMIC_GROUP_FILTER =

note: The 2 asterisks "*" should be removed to allow faster directory searches
on the objectclass attribute
public static final String DYNAMIC_GROUP_FILTER =

second note: a groupofurl can be a standalone ldap objectclass, therefore the
filter definition should be simplified:
public static final String DYNAMIC_GROUP_FILTER = "(objectclass=groupofurls)";

2) in the member method "dynamicGroupSearch(...)" regarding code line "String
Unfortunately the ctx.search is done using this bad designed ldap filter, which
is actually equivalent to "(check all groups you can find in the ldap
directory)", this really slows down your application, if you have many
groupofurls in your ldap directory, but are only interested in evaluation of a
few of them.

note: the directory may contain a lot of groupofurls of other applications as
well, even in the same tree branch. groups you may not be interested in your
application. but the current code will evaluate them all.

For practical ldap runtime performance with "groupofurls" never ever search for
all groupofurls, only check those groups you really need for an application,
unfortunately this requires a property that names the groups you want to be checked:

to do this, the JAAS provider needs to get a property value from the application
that defines an appspecific group-searchfilter:
good filter example:
that would states 3 example groups, that might be relevant for an example
application, instead of
bad filter example: filter=(objectclass=groupofurls))

An application that really really wants all groups checked could do this:
(this just simplifies coding: in all cases you have some parameter to search
with a more restricted ldapfilter)

Comment by Shing Wai Chan [ 04/Oct/07 ]

reassigned to raharsha

Comment by raharsha [ 05/Oct/07 ]

Will work on this.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Thu May 28 16:43:41 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.