Roles

Roles are a Directory Server entry mechanism similar to the concept of a group. A group has members; a role has members. A role’s members are LDAP entries that possess the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Directory Server has a number of different types of roles but OpenSSO Enterprise can manage only one of them: the managed role.

The other Directory Server role types can still be used in a directory deployment; they just can not be managed by the OpenSSO Enterprise console. Other Directory Server types can be used in a policy’s subject definition. For more information on policy subjects, see Creating Policies and Referrals.

Users can possess one or more roles. For example, a contractor role which has attributes from the Session Service and the Password Reset Service might be created. When new contractor employees join the company, the administrator can assign them this role rather than setting separate attributes in the contractor entry. If the contractor is working in the Engineering department and requires services and access rights applicable to an engineering employee, the administrator could assign the contractor to the engineering role as well as the contractor role.

OpenSSO Enterprise uses roles to apply access control instructions. When first installed, OpenSSO Enterprise configures access control instructions (ACIs) that define administrator permissions. These ACIs are then designated in roles (such as Organization Admin Role and Organization Help Desk Admin Role) which, when assigned to a user, define the user’s access permissions.

Users can view their assigned roles only if the Show Roles on User Profile Page attribute is enabled in the Administration Service.

OpenSSO Enterprise should be configured with Directory Server to use the referential integrity plug-in. When the referential integrity plug-in is enabled, it performs integrity updates on specified attributes immediately after a delete or rename operation. This ensures that relationships between related entries are maintained throughout the database. Database indexes enhance the search performance in Directory Server.

There are two types of roles:

• Static: Static roles are created without adding users at the point of the role’s creation. Once the role is created, you can then add specific users to it. This gives you more control when adding users to a given role.

• Dynamic: Dynamic roles are created through the use of an LDAP filter. All users are funneled through the filter and assigned to the role at the time of the role’s creation. The filter looks for any attribute value pair (for example, ca=user*) in an entry and automatically assign the users that contain the attribute to the role.

To Create a Static Role

1. Go to the organization where the Role will be created.

2. Click the Roles tab.

   A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

   Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

   Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

   ---

   Note –

   When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

   ---

   Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In OpenSSO Enterprise, the LDAP organizational unit is often referred to as a container.

   Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

   People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

   ---

   Note –

   Other containers can be configured with OpenSSO Enterprise to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

   ---

   Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

   When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

   Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the OpenSSO Enterprise application.

   Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

3. Click the New Static button.

4. Enter a name for the role.

5. Enter a description of the role.

6. Choose the role type from the Type menu.

   The role can be either an Administrative role or a Service role. The role type is used by the console to determine and here to start the user in the OpenSSO Enterprise console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

7. Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

   No permissions

   No permissions are to be set on the role.

   Organization Admin

   The Organization Administrator has read and write access to all entries in the configured organization.

   Organization Help Desk Admin

   The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

   Organization Policy Admin

   The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

   Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

To Add Users to a Static Role

1. Click the name of the role to which you wish to add users.

2. In the Members list, select Add User from the Select Action menu.

3. Enter the information for the search criteria. You can choose to search for users based on one or more the displayed fields The fields are:

   Match

   Allows you to select the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

   First Name

   Search for users by their first name.

   User ID

   Search for a user by User ID.

   Last Name

   Search for users by their last name.

   Full Name

   Search for users by their full name.

   User Status

   Search for users by their status (active or inactive)

4. Click Next to begin the search. The results of the search are displayed.

5. Choose the users from the names returned by selecting the checkbox next to the user name.

6. Click Finish.

   The Users are now assigned to the role.

To Create a Dynamic Role

1. Go to the organization where the Role will be created.

2. Click the Roles tab.

   A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

   Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

   Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

   ---

   Note –

   When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

   ---

   Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In OpenSSO Enterprise, the LDAP organizational unit is often referred to as a container.

   Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

   People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

   ---

   Note –

   Other containers can be configured with OpenSSO Enterprise to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

   ---

   Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

   When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

   Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the OpenSSO Enterprise application.

   Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

3. Click the New Dynamic button.

4. Enter a name for the role.

5. Enter a description for the role.

6. Choose the role type from the Type menu.

   The role can be either an Administrative role or a Service role. The role type is used by the console to determine and where to start the user in the OpenSSO Enterprise console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

7. Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

   No permissions

   No permissions are to be set on the role.

   Organization Admin

   The Organization Administrator has read and write access to all entries in the configured organization.

   Organization Help Desk Admin

   The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

   Organization Policy Admin

   The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

   Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

8. Enter the information for the search criteria. The fields are:

   Match

   Allows you to include an operator for any the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

   First Name

   Search for users by their first name.

   User ID

   Search for a user by User ID.

   Last Name

   Search for users by their last name.

   Full Name

   Search for users by their full name.

   User Status

   Search for users by their status (active or inactive)

9. Click OK to initiate the search based on the filter criteria. The users defined by the filter criteria are automatically assigned to the role.

To Remove Users from a Role

1. Navigate to the Organization that contains the role to modify.

   Choose Organizations from the View menu in the Identity Management module and select the Roles tab.

2. Select the role to modify.

3. Choose Users from the View menu.

4. Select the checkbox next to each user to be removed.

5. Click Remove user from the Select Action menu.

   The users are now removed from the role.

To Add a Role to a Policy

OpenSSO Enterprise objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Modifying Policies and Referrals.