Locating user group memberships in a Lightweight Directory Access Protocol registry

You can configure WebSphere® Application Server security to use Lightweight Directory Access Protocol (LDAP) servers. The LDAP specifications allow for different mechanisms to define group memberships. Depending on your LDAP server implementation, you can use methods to determine group memberships. WebSphere Application Server can search group memberships directly or indirectly. Also, you can configure the product to search one or more static groups, recursive or nested groups, and dynamic groups for some Lightweight Directory Access Protocol (LDAP) servers.

Procedure

  • Evaluate group memberships.
    • Static group membership: All LDAP server implementations support static group membership. The group object contains a list of users or groups that are members of the group. To determine the groups in which a user is a member, you must get the list of all groups, and then query each group in turn to see whether the user is a member of that group. This operation results in (0)zero groups and does not scale well.

      Several LDAP servers enable user objects in the LDAP server to contain information about the groups to which they belong. Examples of LDAP servers that support direct group searches include Microsoft Active Directory Server and the owner of eDirectory.

    • Dynamic group memberships:

      Some user group memberships are computable from attributes within the user object. IBM® Directory Server and Sun ONE Directory Server are two examples of LDAP servers that support dynamic group membership. In some LDAP servers, you can use an attribute to include a user's dynamic group memberships, nesting group memberships, and static group memberships to determine all the group memberships from a single attribute.

      For example, in IBM Directory Server, you can return all group memberships including the static groups, dynamic groups, and nested groups using the ibm-allGroups attribute. In the Sun ONE directory server you can use the nsRole attribute to calculate, all roles, including managed roles, filtered roles, and nested roles. If an LDAP server has such an attribute in a User object to include dynamic groups, nested groups, and static groups, you can configure WebSphere Application Server security to use this attribute to determine these groups.

      Depending on the implementation, and LDAP server can calculate dynamic group membership. In this case, this dynamic computation is performed entirely by the LDAP server under a single LDAP query and is invisible to WebSphere Application Server. While this approach is not as efficient as direct groups, server-side dynamic queries are more efficient than determining group membership using static group queries.

      Dynamic group membership, when it is supported by the LDAP server, is frequently reflected back to the LDAP client, which is the WebSphere Application Server. In this configuration, WebSphere Application Server is required to compose the appropriate dynamic query against LDAP for each group. This operation results in 0(zero) groups and does not scale well.

    Tips:
    • Use the efficient direct group membership where possible.
    • Use the relatively efficient dynamic group membership where the LDAP computes membership within a single query.
    • Use static group membership, or client side dynamic group membership as a secondary alternative. This option only performs well on systems where the number of groups within the LDAP server is "small".

    The configurations for the supported, listed LDAP servers are pre-defined to use the optimal group membership mechanisms. They assume that the standard object types and schemas for that LDAP vendor are in use on the LDAP server.

  • Evaluate the LDAP registry configuration.
    • Standalone LDAP registry
      If you are configuring an LDAP server outside of the list of pre-configured types, you must configure the appropriate value in the Group Member ID map field on the Advanced LDAP Settings panel using the following methods.
      • If you use static group membership, you must specify objectclass:attribute pairs. If the objectclass for the group object is, groupOfUniquePersons, and within that objectclass, members are listed as persons, then the static group membership Group Member ID map is groupOfUniquePersons:persons.
      • If direct group membership is used, attributes exist in the objectclass, you must use attribute:attribute pairs. For example, if the objectclass for the user is userand the objectclasst contains attributes that are called ingroup, which contains each group membership, then the direct group membership Group Member ID map is ingroup:member.
    • LDAP Registry within a Federated Repositories Registry
      If you are configuring an LDAP server outside of the list of pre-configured types, you must configure the appropriate value in the Group attribute definition properties for the repository.
      • If static group membership is used, you must specify the name of the object class, and the attribute that is used for indicating membership in Group attribute definition -> Member attributes. If the group objectclass for the user is, groupOfUniquePersons, and within that objectclass, members are listed as persons, then the static group Member attributes property is set follows:
        1. In the administrative console, click Security > Global security.
        2. Under Available realm definitions, select Federated repositories, and then Configure. In a multiple security domain environment, click Security domains > domain_name. Under Security Attributes, expand User Realm, and click Customize for this domain. Select the Realm type as Federated repositories and then click Configure.
        3. Under Related items, click Manage repositories.
        4. Click Add to specify a new external repository or select an external repository that is preconfigured.
        5. Under Additional properties, click Group attribute definition.
        6. Under Additional properties, click Member attributes.
        7. Click New to specify a new member attribute.
        8. Set the Name of member attribute field to persons.
        9. Set the Object class field to groupOfUniquePersons.

        When you finish adding or updating your federated repository configuration, go to the Security > Global security panel and click Apply to validate the changes.

        Set the Name of member attribute field to persons

        Set the Object class field to groupOfUniquePersons

        When you finish adding or updating your federated repository configuration, go to the Security > Global security panel and click Apply to validate the changes.

      • If direct group membership is used, then attributes exist in the objectclass for the user and you must use the attribute. For example, if the objectclass for the user is user, and it contains attributes that are called ingroup that contain each group membership, then you specify the direct group membership in the Group attribute definition property for the repository. Perform the following steps:
        1. In the administrative console, click Security > Global security.
        2. Under User account repository, select Federated repositories from the Available realm definitions field and click Configure.
        3. Under Related items, click Manage repositories.
        4. Click Add to specify a new external repository or select an external repository that is preconfigured.
        5. Under Additional properties, click Group attribute definition.
        6. Set the Name of group membership attribute field to ingroup.

        Set the Name of group membership attribute field to ingroup.

        When you finish adding or updating your federated repository configuration, go to the Security > Global security panel and click Apply to validate the changes.

  • Evaluate Nested Groups.
    • Nested Groups
      Depending on the LDAP server implementation, groups can contain only users, or can contain other groups, which are known as a nested group. You configure WebSphere Application Server to properly discover all groups by following this nesting as it applies to either a stand-alone LDAP registry or an LDAP Registry within a Federated Repositories Registry.
      • Standalone LDAP Registry The stand-alone LDAP registry default setting performs only a single group membership query. If the groups returned are in fact subgroups of other groups, you must enable the Perform a nested group search property on the Advanced LDAP Settings panel of the LDAP registry as follows:
        1. Click Security > Global security.
        2. Under User account repository, click the Available realm definitions drop-down list, select Standalone LDAP registry, and click Configure.
        3. Under Additional properties, click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings.
        4. Put a check mark in the Perform a nested group search check box.
      • LDAP Registry within a Federated Repositories Registry Within Federated repositories, you must configure what you expect the results of the query to return. Based on this information, the Federated repository makes the appropriate calls to establish all group membership. If the LDAP server returns all nested group information within a single direct group query, then you set the Scope of group membership attribute property in the group attribute definition to Nested. as follows:
        1. In the administrative console, click Security > Global security.
        2. Under User account repository, select Federated repositories from the Available realm definitions field and click Configure.
        3. Under Related items, click Manage repositories.
        4. Click Add to specify a new external repository or select an external repository that is preconfigured.
        5. Under Additional properties, click Group attribute definition.
        6. Set the Scope of group membership attribute property in the group attribute definition to Nested.
      • If the LDAP server returns only the direct membership, then the registry must then make subsequent queries to establish complete membership. To force the Federated Repository to issue subsequent queries, set the Scope of group membership attribute property in the Group attribute definition for the repository to Direct.

Results

While using the direct method, dynamic groups, recursive groups, and static groups can be returned as multiple values of a single attribute. For example, in IBM Directory Server all group memberships, including the static groups, dynamic groups, and nested groups, can be returned using the ibm-allGroups attribute. In Sun ONE, all roles, including managed roles, filtered roles, and nested roles, are calculated using the nsRole attribute. If an LDAP server can use the nsRole attribute, dynamic groups, nested groups, and static groups are all supported by WebSphere Application Server.

Some LDAP servers do not have recursive computing functionality. For example, although Microsoft Active Directory server has direct group search capability using the memberOf attribute, this attribute lists the groups beneath, which the group is directly nested only and does not contain the recursive list of nested predecessors. The Lotus Domino LDAP server only supports the indirect method to locate the group memberships for a user. You cannot obtain recursive group memberships from a Domino server directly. For LDAP servers without recursive searching capability, WebSphere Application Server security provides a recursive function that is enabled by clicking Perform a Nested Group Search in the Advanced LDAP user registry settings. Select this option only if your LDAP server does not provide recursive searches and you want a recursive search.