WAS v8.5 > Secure applications > Authenticate users > Select a registry or repository > Configure LDAP user registries

Locating user group memberships in a Lightweight Directory Access Protocol registry

We can configure WebSphere Application Server security to use LDAP servers. The LDAP specifications allow for different mechanisms to define group memberships. Depending on the LDAP server implementation, we can use methods to determine group memberships. WAS can search group memberships directly or indirectly. Also, we can configure the product to search one or more static groups, recursive or nested groups, and dynamic groups for some LDAP servers.

• 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 if 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, we 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, we 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 we 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, we can configure WAS security to use this attribute to determine these groups.

    Depending on the implementation, and LDAP server can caluculate 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 WAS. 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 WAS. In this configuration, WAS 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 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, configure the appropriate value in the Group Member ID map field on the Advanced LDAP Settings panel using the following methods.

    • If we use static group membership, you must specifiy 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, use attribute:attribute pairs. For example, if the objectclass for the user is userand the objectclasst contains attributes 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, configure the appropriate value in the Group attribute definition properties for the repository.

    • If static group membership is used, specify the name of the object class, and the attribute 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 dmgr 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.

      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 use the attribute. For example, if the objectclass for the user is user, and it contains attributes called ingroup containing each group membership, then we specify the direct group membership in the Group attribute definition property for the repository. Perform the following steps:
      1. In the dmgr 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.

      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 is known as a nested group. You configure WAS to properly discover all groups by following this nesting as it applies to either a stand-alone LDAP registry or a 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, 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 LDAP user registry settings.

      Put a check mark in the Perform a nested group search check box.

    • LDAP Registry within a Federated Repositories Registry Within Federated repositories, 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 dmgr 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.

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

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. We cannot obtain recursive group memberships from a Domino server directly. For LDAP servers without recursive searching capability, WAS 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 the LDAP server does not provide recursive searches and you want a recursive search.

Subtopics

• Configure dynamic and nested group support for the SunONE or iPlanet Directory Server
  Configure dynamic and nested groups to simplify WAS security management and increase its effectiveness and flexibility.
• Configure dynamic and nested group support for the IBM Tivoli Directory Server
  Configure dynamic and nested groups to simplify WAS security management and increase its effectiveness and flexibility.
• Configure dynamic and nested group support for the SunONE or iPlanet Directory Server
  Configure dynamic and nested groups to simplify WAS security management and increase its effectiveness and flexibility.
• Configure dynamic and nested group support for the IBM Tivoli Directory Server
  Configure dynamic and nested groups to simplify WAS security management and increase its effectiveness and flexibility.

Related concepts:

Standalone LDAP registries
Dynamic groups and nested group support for LDAP

Related

Configure LDAP user registries
Use specific directory servers as the LDAP server

+

Search Tips   |   Advanced Search