Using nested groups in user registries

Using groups can vastly reduce the cost of administering authorization. However, for WebSphere Application Server - Express security, it is not possible to use nested groups (that is, groups that contain other groups) with the LocalOS user registry, and nested groups are not supported for LDAP user registries prior to WebSphere Application Server - Express Version 5.0.1.

The following reasons prohibit the use of nested groups:

• It is not possible for an i5/OS group profile to be a member of another group profile.

• Prior to Version 5.0.1, the mechanism that WebSphere Application Server - Express uses for determining user membership in a group does not recognize nested groups. The mechanism only searches all groups for a user's member attributes. It cannot determine if a group is itself a member of another group.

For LDAP servers without recursive searching capability, WebSphere Application Server - Express security provides a recursive function that is enabled by selecting the Perform a Nested Group Search option in the Advanced LDAP user registry settings. See Locating a user's group memberships in LDAP for more information.

WebSphere Application Server - Express Version 5.0.1 (and later) and Version 5.1 uses the nested group feature that is new in LDAP 4.1. These versions of WebSphere Application Server - Express support the nested group feature in any IBM Directory Server product that supports LDAP 4.1. The IBM Directory Server product that runs on iSeries is called i5/OS Directory Services, and ships with OS/400 V5R2 or later. Note that fixes are required to provide full LDAP 4.1 support. For more information about i5/OS Directory Services and the necessary fixes, see iSeries Directory Services (LDAP): New V5R2 Enhancements. (http://www.ibm.com/servers/eserver/iseries/ldap/whatsnew41.htm)

When WebSphere security is configured to use IBM_Directory_Server as the LDAP server type and the IBM Directory Server LDAP directory server supports LDAP 4.1, group membership is determined with the ibm-allGroups attribute.

For example, suppose group92 is bound to the Administrator role of the WebSphere administrative console. The group2 group is a member of group92. Because group2 contains user2 and user4, these users are authorized to log into and use the administrative console.

In this example, the LDAP directory contains the following entries:

    dn: c=US
    objectclass: top
    objectclass: country
    c: US
    description=United States
    
    dn: o=IBM, c=US
    objectclass: top
    objectclass: organization
    o: IBM
    description=International Business Machines
    
    dn: cn=user2, o=IBM, c=US
    objectclass: person
    objectclass: inetOrgPerson
    objectclass: top
    objectclass: organizationalPerson
    objectclass: ePerson
    cn: user2
    sn: Sec Two
    uid: user2
    userpassword: security
    
    dn: cn=user4, o=IBM, c=US
    objectclass: person
    objectclass: inetOrgPerson
    objectclass: top
    objectclass: organizationalPerson
    objectclass: ePerson
    cn: user4
    sn: Sec Four
    uid: user4
    userpassword: security
    
    dn: cn=group2, o=IBM, c=US
    objectclass: top
    objectclass: groupOfNames
    cn: group2
    member: cn=user2, o=IBM, c=US
    member: cn=user4, o=IBM, c=US
    description: WSA Group Two
    
    dn: cn=group92,o=IBM,c=US                  
    objectclass: top                        
    objectclass: groupOfNames  
    objectclass: ibm-nestedGroup             
    cn: group92                             
    description: WSA Group Ninety Two      
    ibm-memberGroup: cn=group2, o=IBM, c=US

Note that, in the last entry, group2 is a member of group92. Its membership is specified in the ibm-memberGroup attribute for group92.