Use nested groups in user registries

Use groups can vastly reduce the cost of administering authorization. However, for WebSphere Application Server 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 Version 5.0.1.

The following reasons prohibit the use of nested groups:

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

• Prior to Version 5.0.1, the mechanism that WebSphere Application Server 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.

WebSphere Application Server 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 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 OS/400 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 OS/400 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=user5, o=IBM, c=US
    objectclass: person
    objectclass: inetOrgPerson
    objectclass: top
    objectclass: organizationalPerson
    objectclass: ePerson
    cn: user5
    sn: Sec Five
    uid: user5
    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: group92W
    description: WSA Group Ninety Two
    member: cn=user5, o=IBM, c=US
    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.