RSA^® Authentication Manager Documentation

Yes

Administrative Role OverviewAdministrative Role Overview

Administr ators manage all aspects of your deployment, such as users, tokens, and security domains. Each administrator is assigned an administrative role that has its own set of administrative privileges and areas of responsibility.

Administrative roles control what an administrator can manage. When an administrative role is assigned to a user, the user becomes an administrator.

Types of Administrative RolesTypes of Administrative Roles

There are two types of administrative roles:

Predefined roles. You can assign predefined roles in their default form, or you can edit the permissions for each role.

For example, if you do not want administrators with the Help Desk role to view authentication agents, you can use the Security Console to remove that permission from the role.
Custom roles. You can create custom roles with different privileges and areas of administrative responsibility, depending on your organization’s needs.

For example, suppose your organizational hierarchy is divided into three security domains: HR, R&D, and Finance. Because financial data is sensitive, you might create a custom administrator who can run and view finance reports in the Finance security domain.

Administrative Role AssignmentAdministrative Role Assignment

After you have decided which roles you need for your deployment, and added any custom roles you require, you can assign the roles to administrators.

Know the following about assigning administrative roles:

You can assign administrative roles to any user in your identity source. You will probably only assign administrative roles to members of your information technology (IT) organization and possibly a few other trusted individuals in your organization.
When you assign a role to a user, the user becomes an Authentication Manager administrator and can use the Security Console to administer the deployment.
When you assign a role to an administrator, the administrator is then able to perform the administrative actions specified by the role in the security domains specified by the scope of the role.
You can only assign administrative roles with privileges equal to or less than those of your own role. That is, you cannot assign privileges that you do not have. For example, if your administrative role only allows you to add, edit, and delete users, and create and assign administrative roles, you cannot assign a role that enables users to receive on-demand tokencodes.
You cannot edit an administrative role that has more permissions than your role.
You can assign more than one role to an administrator. When you do this, the administrator can only perform administrative actions in a security domain that is included in the scope of the role that grants the permission.

For example, suppose an administrator has one role that grants him permission to manage users in the San Jose security domain, and another role that grants him permission to manage authenticators in the New York security domain. In the Security Console, the administrator is allowed to manage users in the San Jose security domain, but not the New York security domain, so users in the New York security domain are not visible to the administrator. The same rule applies to authenticators. The administrator can manage and view authenticators in the New York security domain only.
Be sure to assign roles that grant only enough permissions and include a scope just broad enough to accomplish their tasks. Avoid granting administrative roles to administrators who do not need them.

For example, if an administrator’s job only requires him to administer users in the Boston security domain, avoid including the San Jose and New York security domains in the scope of his role.

Administrative Administrative Role ComponentsRole Components

An administrative role has two components:

Permissions based on the function of the role
The Scope (security domains and identity sources) in which the permissions can be applied

PermPermissionsissions

The permissions in an administrative role determine the actions that an administrator can take on objects such as users, user groups, security domains, and policies. Be sure to assign permissions that allow administrators to manage all of the objects that are needed to accomplish their assigned tasks, but do not assign permissions that are not necessary.

You can modify the permissions to manage the following areas:

Role basics
Security domain administration
Delegated administration
Users
User groups
Reports
SecurID tokens
User authentication attributes
Authentication agents
Trusted realms
RADIUS
On-demand tokencodes
Provision requests

The following permissions are available for all objects in your deployment:

All. Perform any administrative action on the object.
Delete. Delete an object.
Add. Add an object.
Edit. View and edit an object, but not to add or delete.
View. View an object, but not to add, edit, or delete.

You can expand or reduce the scope of an administrator’s role by modifying permissions. For example, assume that you are the Super Admin for FocalView Software Company. The administrator in your Boston office has a role that limits him to assigning and managing authenticators. You want the administrator to also manage agents. You can modify the administrator’s current role instead of creating a new one.

These actions give the administrator permission within the Boston security domain and any of Boston’s lower-level security domains, if applicable. If the administrative scope only includes the Boston security domain, the administrator can only manage the objects, users, authenticators, and agents, for example, belonging to that domain.

Suppose that multiple administrators have the role that manages authenticators. If you modify the role so that one of the administrators can also manage agents, all administrators with that role can also manage agents. In this case, you may want to create a new role for the one administrator who manages both authenticators and agents.

Another option is to create a second role that allows agent management and then assign the role to the administrator. In this case, the administrator would have two assigned roles.

For example, if an administrator’s only task is assigning tokens to users, you would probably assign the following permissions to the role:

View users
View tokens
Assign tokens to users
Issue assigned software tokens
Replace assigned tokens
Import tokens (optional)
Enable and disable tokens (optional)

The optional permissions above slightly expand the administrative role to complement the stated task of assigning tokens to users. You would not, however, assign the permissions to add and delete users, resynchronize tokens, or manage emergency offline authentication, as they are not related to the stated task of assigning tokens to users.

Permissions Required to Create Administrative Roles and Delegate PermissionsPermissions Required to Create Administrative Roles and Delegate Permissions

An administrator who creates a new administrative role must have the following permissions associated with their role:

Permission to create administrative roles.
The same permissions that he or she wants to add to the new administrative role.
Permission to delegate the permissions granted to his or her role. This is determined by the Permission Delegation setting for the role assigned to the administrator who is creating the new role.
Permission to manage the security domain that is associated with the new role.

When you assign permissions to a role, make sure the administrator has all the permissions necessary to perform assigned tasks. For example:

An administrator who assigns tokens to user must have permission to view and assign tokens, and view users.
An administrator who resets user passwords must have permission to reset passwords and view user records.
An administrator who assigns administrative roles to users must have permission to assign roles and view user records.
An administrator who assigns users to user groups must have permission to assign users to user groups and view user records.

You can delegate permissions to other administrators if your role permits you to create or assign existing roles to other users.

For instructions on selecting Permission Delegation, see Duplicate an Administrative Role.

Permission Limits for Managing Identity Attribute DefinitionsPermission Limits for Managing Identity Attribute Definitions

You can limit what permissions an administrative role grants to manage specific custom-defined identity attribute definitions. For any identity attribute definition, an administrative role can grant Modify, View, and None permissions.

For more information, see User Attributes.

You can set permissions for specific identity attribute definitions on the Permissions page when you add or edit an administrative role.

For more information, see Duplicate an Administrative Role and Edit Permissions for an Administrative Role.

ScopScopee

The scope of an administrative role determines in what security domains an administrator may manage objects and from what identity sources an administrator may manage users and user groups.

For more information, see Security Domains.

Be sure to assign a scope broad enough so that the administrator can access the necessary security domains and identity sources. However, avoid assigning a scope that grants access to security domains and identity sources where the administrator has no responsibilities.

Also, avoid creating situations in which an administrator can view and manage a certain user group, but cannot at least view all the users in that user group. This happens when a user group from a security domain within the administrator’s scope contains users from a security domain outside the administrator’s scope. When the administrator views the user group members, he or she only sees the members from the security domain within his or her scope. This creates a situation in which administrators may take action on a group, for example, granting a group access to a restricted agent, without being aware of all the users affected. This can result in users being granted privileges that they should not have.

To avoid this situation, follow these guidelines:

Allow all administrators to at least have view permission on all users in all security domains. This ensures that there are no cases where administrators are unaware of any members of a group they are administering.
Make sure that a user group and all members of the user group are in the same security domain. This ensures that administrators who have permissions to view user groups and to view users are able to see all member users.
If you want the administrator to run reports on the viewable information, grant the appropriate permission. Some reports require more than view permission.

Know the following about scoping administrative roles:

When the scope of an administrative role is defined most broadly, the role can manage the security domain where the role definition was saved and all of the lower-level security domains beneath it.
An administrative role that manages an upper-level security domain always manages the lower-level security domains beneath it.
You can limit the scope of an administrative role to specific security domains, as long as those security domains are at or below the security domain that is associated with the role. An administrative role can only manage down the security domain hierarchy, never up.
The security domain where you save the administrative role impacts the scope of the role. For example, suppose the top-level security domain is Boston, and the lower-level security domains are named New York and San Jose. If you save an administrative role to the New York security domain, administrators with that role can only manage objects in the New York security domain and in lower-level security domains within the New York security domain. Administrators with that role cannot manage objects in the Boston or San Jose security domains.

You can save the Super Admin role in the top-level security domain, and then save all other administrative roles in a lower-level security domain. This prevents lower-level administrators, for example, Help Desk Administrators, from editing the Super Admin’s password and then using the Super Admin’s password to access the Security Console.

Scope ExampleScope Example

For example, consider the following hierarchy.

An administrative role saved in the top-level security domain can be scoped to manage any security domain in the deployment. For example, it can manage only security domain F, or every security domain.
An administrative role saved in security domain A can be defined to manage security domain A and all the lower-level security domains below it.
An administrative role saved in security domain C can be defined to manage E, or both C and E.
An administrative role saved in security domain E can be defined to manage only security domain E.

An administrative role can be defined so that it manages only users or user groups within a particular administrative scope who match certain criteria. These are called attribute-based roles. For example, if you have defined an identity attribute definition for location, an administrative role can manage all users in security domain A and down the hierarchy (C, D, E, and F).

You can also create a role that only allows an administrator to edit specified custom user identity attribute definitions. You configure permissions to a specific identity attribute definition as part of the role’s permissions.

For a given attribute, the role can specify one of the following access permissions: