2.4 Understanding the Types of Users for the Identity Applications

Users of the identity applications generally fall into the following categories:

2.4.1 Administrative Users

The identity applications have several types of administrative users. During installation, you establish the following administrators:

Identity Vault Administrator

A user who has rights to configure the Identity Vault. This is a logical role that can be shared with other administrative user types.

The Identity Vault Administrator needs the following rights:

  • Supervisor rights to the User Application driver and all the objects it contains. You can accomplish this by setting the rights at the driver container level and making them inheritable.

  • Supervisor Entry rights to any of the users that are defined through the directory abstraction layer user entity definition. This should include Write attribute rights to objectClass and any of the attributes associated with the DirXML-EntitlementRecipient, srvprvEntityAux and srvprvUserAux auxiliary classes.

  • Supervisor rights to the container object cn=DefaultNotificationCollection, cn=Security. This object persists email server settings used for automated provisioning emails. It can contain SecretStore credentials for authenticating to the email server itself.

  • Supervisor rights to the container object cn=Authorized Login Methods, cn=Security. During the User Application installation the SAML Assertion object is created in this container.

  • Ensure that you have supervisor rights to the cn=Security container before you install User Application. During the User Application installation, the container cn=RBPMTrustedRootContainer is created under the cn=Security container.

    Alternatively, manually create the cn=RBPMTrustedRootContainer,cn=Security container (create an object called Trusted Root Container with object class NDSPKI:Trusted Root inside the Security container), and then assign supervisor rights to the container.

User Application Administrator

A user who has the rights to perform administrative tasks for the identity applications. This user has the following attributes:

  • Can manage the Dashboard, Catalog Administrator, and User Application.

  • Can use iManager to administer workflow tasks, such as enabling, disabling, or terminating in-process workflows.

  • Does not have any special privileges within the identity applications.

  • Does not need any special directory rights because it controls application-level access to the identity applications from the Dashboard and User Application. Although a User Application Administrator has the ability to customize the look and feel of the applications, the identity applications use the LDAP administrator credentials to modify the selections in the Identity Vault.

  • Can manage the password for this account.

    A feature of password self-service is password synchronization status. To enable the User Application Administrator to view the password synchronization status for other users (for troubleshooting or other reasons), you should create a PasswordManagement group and assign one or more users to this group. The members of this group are allowed to view the password synchronization status of other users. If you choose to create this group, it must:

    • Be named PasswordManagement.

    • Be given the privileges to the Identity Vault. The group must have rights to read the user’s eDirectory object attribute for users whose password synchronization status they need to view.

    IMPORTANT:NetIQ Self Service Password Reset (SSPR) is the default password management program for Identity Manager. For more information, see Managing Your Password in the NetIQ Identity Manager - User’s Guide to the Identity Applications.

2.4.2 Administrator and Manager Categories

The identity applications use a security model that recognizes three general categories of administrators and managers:

Domain Administrator

An administrator who has the full range of capabilities within a particular domain, and is able to perform all operations on all objects within the domain for all users

Domain Manager

A delegated administrator who has the ability to perform selected operations for a subset of authorized objects within the domain for all users

Team Manager

A business line manager who can perform selected operations for a subset of authorized objects within the domain, but only for a designated set of users (team members)

The following diagram illustrates the security model:

Team Managers

A Team Manager is a user designated as a manager of a team, which represents a set of users, groups, or users and groups that can perform provisioning requests and approval tasks associated with the team. Although a team might match a group that exists in the user directory, teams are not the same thing as groups. That is, a group or a member of a group cannot perform team capabilities except when assigned to a team.

You can assign Team Managers either in the Teams page in the Dashboard or the Administration > Team Configuration tab in the User Application. You can allow Team Managers to make requests on behalf of and act as a proxy for team members. For more information on configuring teams, see the following sources:

2.4.3 Designers

Designers use the Designer for Identity Manager to customize the User Application for your enterprise. Designer is a tool aimed at information technology professionals such as enterprise IT developers, consultants, sales engineers, architects or system designers, and system administrators who have a strong understanding of directories, databases, and their information environment and who act in the role of a designer or architect of identity-based solutions.

To create or edit workflow objects in Designer, the user needs the following rights on the RequestDefs.AppConfig container for the specific User Application driver.

  • [Entry Rights] Supervisor or Create

  • [All Attribute Rights] Supervisor or Write

To initiate a workflow, the user must have Browse [Entry Rights] on the RequestDefs.AppConfig container for the specific User Application driver or individually per request definition object if you are using a delegated model.

2.4.4 Business Users

Business users interact with the User Application’s Identity Self-Service, Work Dashboard, and Roles and Resources tabs. A business user is an authenticated user, such as an employee, a manager, or a delegate or proxy for an employee or manager. A delegate user is a user to whom one or more specific tasks appropriate to that user’s rights can be delegated, so that the delegate can work on those specific tasks on behalf of someone else. A proxy user is user who acts in the role of another user by temporarily assuming that user’s identity. All of the rights of the original user apply to the proxy. Work owned by the original user continues to be owned by that user.

The user’s capabilities within the User Application depend on what features of the User Application Administrator has enabled for them. They can be allowed to:

  • View and edit user information, with appropriate rights

  • Search for users or resources using advanced search criteria, which can be saved for later reuse

  • Recover forgotten passwords

The User Application can be configured so that users can:

  • Request a resource (start one of potentially many predefined workflows)

  • View the status of previous requests

  • Claim tasks and view tasklists (by resource, recipient, or other characteristics)

  • View proxy assignments

  • View delegate assignments

  • Specify one’s availability

  • Enter proxy mode to claim tasks on behalf of another

  • View team tasks and request team resources