1.3 User Application User Types

The Identity Manager User Application users fall into these categories:

1.3.1 Administrators

The User Application defines several types of administrative users. The administrative users defined in Table 1-3 are defined at installation.

Table 1-3 User Application Administrative Users

User

Description

LDAP 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 LDAP administrator account is a proxy user for the User Application to carry out tasks on the LDAP server that an ordinary logged-in user might not have permission to execute, such as creating a new user, group, or container. It represents credentials (username and password) used to bind to the Identity Vault to perform system LDAP operations, so these are the rights that the User Application itself needs to run. The LDAP administrator needs:

  • 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.

  • Read Rights to the container object cn=DefaultNotificationCollection, cn=Security. This object persists e-mail server settings used for automated provisioning e-mails. It can contain SecretStore credentials for authenticating to the e-mail server itself.

User Application Administrator

A user who has the rights to perform administrative tasks for the User Application. This user can:

  • Use the Administration tab of the User Application to manage the User Application.

  • Use iManager to administer workflow tasks (such as enabling, disabling, or terminating an in-process workflows)

  • Use iManager or Designer to create new provisioning requests, manage e-mail templates.

  • Run reports on Novell Audit logging data.

This user does not have any special privileges on the Requests & Approvals tab of the User Application.

This user does not need any special directory rights because it controls application level access via the Administration page. Although a User Application Administrator has the ability to manage themes in the Administration page, the User Application uses the LDAP administrator credentials to modify the theme selections in the Identity Vault.

Password self-service: One task of the User Application Administrator is to configure password self-service for the User Application. 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), it is recommended that you 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.

Provisioning Application Administrator

A user who is intended to allow you to delegate provisioning management tasks to a business user without giving him or her full administration rights to the User Application. By default, the Provisioning Administrator cannot access the Administration page, but he or she has full rights to the Request & Approvals tab. For example, when the Provisioning Application Administrator logs in, he or she does not need to select a team because all users are considered to be his or her team members.

Roles Module Administrator

A user assigned to the Roles Module Administrator system role, which allows members to create, remove, or modify all roles, and grant or revoke any role assignment to any user, group, or container. This role also allows members to run any report for any user.

For more information on the Roles Module Administrator, see the discussion of roles security in the Identity Manager User Application: User Guide .

iManager Administrators

In addition to the users and their associated tasks above, Identity Manager includes administrators that use iManager to:

  • Create new provisioning requests and workflows.

  • Define teams.

  • Define or manage e-mail templates.

  • Administer workflow tasks (such as enabling, disabling, or terminating in-process workflows).

The user that performs these tasks can be one of the administrators listed above, or a different user that has been given the privileges to perform these tasks.

To create or edit or edit workflow objects in iManager, 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.

1.3.2 System Roles

Users can be assigned to any of the following system roles:

  • Roles Module Administrator

  • Roles Manager

  • Roles Auditor

  • Security Officer

Users assigned to these roles have different capabilities within the User Application. For more information on the system roles, see the discussion of roles security in the Identity Manager User Application: User Guide .

1.3.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 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.

1.3.4 Users

The user is the person who views and interacts with the User Application’s Identity Self-Service, Requests & Approval, and Roles tabs. A user can be:

  • 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 delegates can work on those specific tasks on behalf of someone else. A proxy user is an end 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.

  • An anonymous or guest user. The anonymous user can be either the public LDAP guest account or a special account set up in your Identity Vault. The User Application Administrator can enable anonymous access to some features of the Identity Self-Service tab (such as a search or create request). In addition, the User Application Administrator can create pages that allow the user to request a resource. See Table 1-8 for information on configuring anonymous access.

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

  • View hierarchical relationships between User objects by using the Org Chart portlet.

  • 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 in order to claim tasks on behalf of another.

  • View team tasks, request team resources, and so forth (managers only).