Administrators 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.
Predefined roles.Authentication Manager provides 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.
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.
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:
Security domain administration
RSA SecurID tokens
User authentication attributes
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:
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.
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.
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.
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: