Managing Roles

A
role is an alternate grouping mechanism that is designed to be more efficient
and easier for applications to use. While roles are defined and administered
like groups, a generated role attribute in each member entry automatically
indicates the roles of an entry. For example, an application can read the
roles of an entry, rather than having to select a group and browse the members
list.

By default, the scope of a role is limited to the subtree where the
scope is defined. However, you can extend scoping of the nested role. You
can allow the scope to nest roles located in other subtrees and to have members
anywhere in the directory. For details see To Extend the Scope of a Role and Example of a Nested Role Definition.

This section explains how to use roles securely, and how to manage roles
from the command line.

Using Roles Securely

To use roles securely, you must set access control instructions (ACIs)
to protect appropriate attributes. For example, user A possesses the managed
role, MR. Managed roles are equivalent to static groups, and explicitly assign
a role to each member entry by adding the nsRoleDN attribute
to the entry. The MR role has been locked using account inactivation through
the command line. This means that user A cannot bind to the server because
the nsAccountLock attribute is computed as “true”
for that user. However, suppose the user was already bound and noticed that
he is now locked through the MR role. If no ACI exists to prevent the user
from having write access to the nsRoleDN attribute, the
user can remove the nsRoleDN attribute from his own entry
and unlock himself.

To prevent users from removing the nsRoleDN attribute,
you must apply ACIs. With filtered roles, you must protect the part of the
filter that would prevent the user from being able to relinquish the filtered
role by modifying an attribute. Users should not be allowed to add, delete,
or modify the attribute used by the filtered role. In the same way, if the
value of the filter attribute is computed, all the attributes that can modify
the value of the filter attribute need to be protected. As nested roles can
contain filtered and managed roles, the preceding points should be considered
for each of the roles that are contained in the nested role.

The nsRoleDN attribute indicates that the entry is a member of a managed
role. The managed role is identified by the DN of its role definition. To
allow users to modify their own nsRoleDN attribute, but
to prevent users from adding or removing the nsManagedDisabledRole,
add the following ACI:

Notice that the nsFilteredRoleDefinition object
class inherits from the LDAPsubentry, nsRoleDefinition, and nsComplexRoleDefinition object
classes. The nsRoleFilter attribute specifies a filter
that finds all employees in the ou=sales organization that
have subordinates, for example:

The filter string of a filtered role can be based on any attribute,
except computed attributes that are generated by the CoS mechanism.

When filtered role members are user entries, you can choose to restrict
their ability to add or remove themselves from the role. Protect the filtered
attributes with ACIs.

Example of a Nested Role Definition

The roles
that are nested within the nested role are specified by using the nsRoleDN attribute. Use the following command to create a role that contains
both the marketing staff and sales manager members of the roles created in
the previous examples:

Notice that the nsNestedRoleDefinition object
class inherits from the LDAPsubentry, nsRoleDefinition, and nsComplexRoleDefinition object classes. The nsRoleDN attributes
contain the DN of the marketing managed role and the sales managers filtered
role. Both of the users in the previous examples, Bob and Carla, would be
members of this new nested role.

The scope of this filter includes the default scope, which is the subtree
where the filter is located, and the subtree below any values of the nsRoleScopeDN attribute. In this case, the ManagerFilter is
in the ou=sales,ou=People,dc=example,dc=com subtree. This
subtree must be added to the scope.

Extending the Scope of a Role

Directory Server provides an attribute that allows the scope of a
role to be extended beyond the subtree of the role definition entry. This
single-valued attribute, nsRoleScopeDN, contains the DN
of the scope to be added to an existing role. The nsRoleScopeDN attribute
can only be added to a nested role. See Example of a Nested Role Definition.

To Extend the Scope of a Role

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

The nsRoleScopeDN attribute enables you to extend
the scope of a role in one subtree to include an entry in another subtree.
For example, imagine two main subtrees in the example.com directory tree: o=eng,dc=example,dc=com ( the engineering subtree) and o=sales,dc=example,dc=com (the sales subtree.) A user in the engineering subtree requires
access to a sales application governed by a role in the sales subtree (SalesAppManagedRole). To extend the scope of the role, do the following:

Create a role for the user in the engineering subtree.

For
example, create the role EngineerManagedRole. This example
uses a managed role, but it could just as well have been a filtered or nested
role.

Create a nested role, for example, SalesAppPlusEngNestedRole , in the sales subtree to house the newly created EngineerManagedRole and the initial SalesAppManagedRole .

Add the nsRoleScopeDN attribute to the SalesAppPlusEngNestedRole, with the DN of the engineering subtree scope that you want to
add, in this case, o=eng,dc=example,dc=com.

The
necessary permissions must be granted to the engineering user so that he can
access the SalesAppPlusEngNestedRole role and, in turn,
the sales application. In addition, the entire scope of the role must be replicated.

Note –

The restriction of extended scope to nested roles means that an
administrator who previously managed roles in one domain only has rights to
use the roles that already exist in the other domain. The administrator is
not able to create an arbitrary role in the other domain.