Managing a proxy authorization group

Directory Server, Version 6.1

Managing a proxy authorization group

The proxy authorization is a special form of authentication. By using this proxy authorization mechanism, a client application can bind to the directory with its own identity but is allowed to perform operations on behalf of another user to access the target directory. A set of trusted applications or users can access the IBM® Tivoli® Directory Server on behalf of multiple users.
The members in the proxy authorization group can assume any authenticated identities except for the administrator or members of the local or global administrative groups. Members of the proxy authorization group also have the authority to use the group authorization control.
Note:

The administrator and members of the local administrative group have the authority to assume the identity of a global administrator group member by sending a group authorization control for the global administrator group.
The proxy authorization group can be stored under either localhost or IBMpolicies. A proxy authorization group under IBMpolicies is replicated. A proxy authorization group under localhost is not. We can store the proxy authorization group under both localhost and IBMpolicies. If the proxy group is not stored under one of theses DNs, the server ignores the proxy part of the group and treats it as a normal group.
As an example, a client application , client1, can bind to the IBM Tivoli Directory Server with a high level of access permissions. UserA with limited permissions sends a request to the client application. If the client is a member of the proxy authorization group, instead of passing the request to the IBM Tivoli Directory Server as client1, it can pass the request as UserA using the more limited level of permissions. What this means is that instead of performing the request as client1, the application server can access only that information or perform only those actions that UserA is able to access or perform. It performs the request on behalf of or as a proxy for UserA.
Note:

The attribute member must have its value in the form of a DN. Otherwise an Invalid DN syntax message is returned. A group DN is not permitted to be a member of the proxy authorization group.
Administrators and administrative group members are not permitted to be members of the proxy authorization group. All administrators have authority to use the proxy authorization control, without having to be in that group.
The audit log records both the bind DN and the proxy DN for each action performed using proxy authorization.

Creating a proxy authorization group

To create a proxy authorization group, create a group entry using either the Web Administration Tool or the command line.

Using Web Administration:

If you have not done so already, expand the Directory management category in the navigation area.

Do one of the following:

Click Add an entry.
Click Manage entries and select the location (cn=ibmPolicies or cn=localhost) and click Add.

Select the groupofNames object classes from Structural object class menu.
Click Next.
Select ibm-proxyGroup auxiliary object class from the Available menu and click Add. Repeat this process for each additional auxiliary object class you want to add. We can also delete an auxiliary object class from the Selected menu by selecting it and clicking Remove.
Click Next.
In the Relative DN field, enter cn=proxyGroup.
In the Parent DN field, enter the distinguished name of the tree entry you are selecting, for example, cn=localhost. We can also click Browse to select the Parent DN from the list. Select your choice and click Select to specify the Parent DN that you want. The Parent DN defaults to the entry selected in the tree.
Note:

If you started this task from the Manage entries panel, this field is prefilled for you. You selected the Parent DN before clicking Add to start the add entry process.
At the Required attributes tab enter the values for the required attributes.

cn is proxyGroup.
Member is in the form of a DN, for example, cn=Bob Garcia,ou=austin,o=sample.

Notes:

If the attribute is multi-valued and you want to add more than one value for a particular attribute, click Multiple values. Do not create multiple values for cn value. The proxy authorization group must have the well known name, proxyGroup. See Multiple values for attributes.
If an attribute requires binary data, click Binary data. See Binary data for attributes
If your server has language tags enabled, click Language tag value to add or remove language tag descriptors. See Language tags and Language tag values for attributes for more information.
If an attribute contains referrals, click Manage referral. See Referrals and Creating default referrals for more information.

Click Optional attributes.
At the Optional attributes tab enter the values as appropriate for the attributes.
Click Finish to create the entry.

Using the command line:

To create the proxy authentication group with an initial member in the cn=localhost location, issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=proxyGroup,cn=localhost
cn: proxyGroup
member:  cn=client1, ou=austin, o=sample
objectclass: top
objectclass: container
objectclass: groupOfNames
objectclass: ibm-proxyGroup
To add an additional member, issue the command:
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=proxyGroup,cn=localhost
cn: proxyGroup
changetype: modify
add: member
member:  cn=client2, ou=austin, o=sample
Modifying a proxy authorization group

Using Server Administration:

To modify the proxy authorization group such as adding or deleting members of the group, see Modifying an entry.

Using the command line:

To modify the proxy authorization group in the cn=IBMpolicies location, issue the following command:
Note:

This command deletes user1, and adds user2 and user3.
idsldapmodify -D <adminDN> -w <adminPW> -i <filename>
where <filename> contains:
dn: cn=proxyGroup,cn=IBMpolicies
changetype: modify
delete: member
member:  cn=client1, ou=austin, o=sample
-
add: member
member: cn=client2, ou=austin, o=sample
-
add: member
member: cn=client3, ou=austin, o=sample
Copying a proxy authorization group

Using Server Administration:

Copying a proxy authorization group is useful if you want to have the same proxy authorization group under both localhost and IBMpolicies.
To copy a proxy authorization group, see Copying an entry.

Using the command line:

To view the proxy authorization group contained in localhost, issue the command:
idsldapsearch -D <adminDN> -w <adminPW> -b cn=localhost  objectclass=ibm-proxyGroup
The following is the output for this command:
Dn: cn=proxyGroup, cn=localhost
Cn: proxyGroup
objectclass: ibm-proxyGroup
objectclass: groupOfNames
member: cn=client1, ou=austin, o=sample
member: cn=client2, ou=austin, o=sample
member: cn=client3, ou=austin, o=sample
Select the proxy authorization group. Use an editor to change cn=localhost to cn=IBMpolicies, and save the changes to <filename>.
Then issue the following command:
idsldapmodify -a -D <adminDN> -w <adminPW> -i <filename>
where <filename>contains:
Dn: cn=proxyGroup, cn=IBMpolicies
Cn: proxyGroup
objectclass: ibm-proxyGroup
objectclass: groupOfNames
member: cn=client1, ou=austin, o=sample
member: cn=client2, ou=austin, o=sample
member: cn=client3, ou=austin, o=sample
Removing the proxy authorization group

To remove a member from the proxy authorization group use either of the following methods.

Using Web Administration:

To remove a proxy authorization group, see Deleting an entry.

Using the command line:

To remove the proxy authorization group issue the command:
idsldapdelete -D <adminDN> -w <adminpw> -s "cn=ProxyGroup,cn=IBMpolicies"
Although the proxy authorization group can be managed by the Web Administration Tool, proxy authorization is not recognized by any of the other Web Administration Tool functions. The proxy authorization function is utilized by including the Proxy Authorization Control with your LDAP operations or using the LDAP commands with the -y option. For example:
idsldapsearch -D "cn=client1,ou=austin,o=sample" -w <client1password> 
           -y "cn=userA,o=sample" -b "o=sample" -s sub ou=austin 
Based on the above idsldapsearch specification, client1 can read from the target directories whatever userA has permission to read.

[ Top of Page | Previous Page | Next Page | Contents | Index ]