1. glassfish
  2. GLASSFISH-3509

LDAP performance issues: LDAPRealm.dynamicGroupSearch


    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 9.0pe
    • Fix Version/s: not determined
    • Component/s: security
    • Labels:
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:


      Regarding class "" 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
      filter = DYNAMIC_GROUP_FILTER;":
      Unfortunately the 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)


        No work has yet been logged on this issue.


          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: