PK
:@oa, mimetypeapplication/epub+zipPK :@ iTunesMetadata.plisth
This chapter is divided into the following sections:
Attestation enables users designated as reviewers to be notified of reports they must review. These reports describe entitlements of other users. A reviewer can attest to the accuracy of these entitlements by providing a response. The attestation action, along with the response the reviewer provides, any associated comments, and an audit view of the data that the reviewer views and attests to, is tracked and audited to provide a complete trail of accountability. In Oracle Identity Manager, this process is known as an attestation task.
In Oracle Identity Manager, attestation is supported through the definition of scheduled attestation processes. An attestation process is not the same as an Oracle Identity Manager workflow. It is implemented as a configurable business process in Oracle Identity Manager, and it creates an attestation task for a user. The user acts as a reviewer, and must complete this process to provide correct audit information.
Tracking of attestation activity for a provisioned resource instance is done through tasks in the provisioning processes of resource objects. You can initiate workflow activity based on attestation actions. Additional activities to be started, and a workflow that can be modeled in the process definition form or workflow designer can be initiated, based on an initial attestation action. This is possible due to attestation subflows in the provisioning processes defined in Oracle Identity Manager.
Attestation activity can be initiated on a periodic basis or when required.
A reviewer can delegate specific entitlements in an attestation task to another user for review. This action creates another attestation task that is assigned to the delegated user.
This section discusses the following topics:
An attestation process is the mechanism by which an attestation task is set up. Input that an attestation process requires includes information about how to define the components that constitute the attestation task and how to associate the attestation task with a schedule at which the task must be run. This definition is also the basis on which the attestation task can be initiated when required. An attestation process definition includes:
User Scope or Resource Scope: This defines the algorithm by which the target user entitlements of the attestation process are determined.
Reviewer Setup: This specifies the reviewer, who attests the entitlements of other users. An attestation process can specify a particular user as the reviewer, or can specify more abstractly how to select the reviewer. For example, the reviewer can be specified as the user's manager, as an administrator of the resource, as an authorizer of access to the resource, or as a member of the role that grants the entitlement.
Definition of Attestation Schedule: This specifies the schedule for running the attestation process.
Process Owner: This is a designated group of users that are responsible for monitoring activities related to the process.
They will be notified of any issues that occur when the process runs.
They will have permissions to view the process definition, but will not have administrative permissions by default.
They will be able to execute the process whenever required.
A single attestation process could result in multiple attestation tasks, if that process defines a set of reviewers. In such a case, the process would result in one attestation task for each reviewer in the set.
The following sections describe how you can control attestation processes.
An attestation process can be disabled by the system administrator to prevent it from running at its preconfigured schedule. This gives an administrator better control over the environment. A system administrator attestation process can be enabled, but it cannot be enabled if its Next Run Time value is in the past. A user who enables an attestation process must set its next run time in the future.
An attestation process can be deleted. This is called a soft-delete. It does not actually delete the records because the records must be maintained for audit purposes. Instead, the attestation process will be marked as deleted.
A deleted process is not displayed in Oracle Identity Manager Administrative and User Console. Because process names and codes are unique, a name once used is no longer available, and no new attestation process can be created with the same name.
The basic purpose of the attestation process is to set up an attestation task in Oracle Identity Manager. The attestation task is displayed in the Attestation tab of the TaskList in the Oracle Identity Manager Self Service, where you can manage this task or delegate it to someone else to manage. The following are the basic components of an attestation task:
Reviewer: This specifies the user who performs the attestation.
Task Source: This specifies whether or not the attestation task is a result of a process or because of delegation by another reviewer. In the case of delegation, the task must track the reviewer who delegated the task, and which task is the source of the entitlements.
Attestation Data: This is detailed data about user entitlements in the attestation scope. This data is from the process form of the provisioned resource instance.
Attestation Date: This defines the date on which the attestation task is initiated.
Attestation Actions: These are the actions that the reviewer can take on the attestation scope. The action is not at the level of attestation task overall, but rather against each entitlement in the attestation scope. The following are attestation actions:
Certify: The reviewer agrees that the user being reviewed is allowed to have the entitlement in its current form, including any specific data or fine-grained permissions.
Reject: The reviewer does not think that the user must have this entitlement in the form.
Decline: The reviewer does not want to accept the responsibility of attesting to the entitlement. This action is usually for cases in which processes have been configured incorrectly, and is useful in the early stages of a rollout.
A reviewer declines a task when the reviewer wants someone else to act upon the task. When a task is declined, it gets assigned to a random user in the System Administrator role.
Delegate: The reviewer wants to reassign the attestation of this entitlement to another qualified person.
Note: The attestation tasks are not workflow tasks in Oracle Identity Manager definition. They are not created as part of workflow. Attestation tasks do not support all the task management features that the workflow engine supports such as dynamic assignment, escalation, and proxy management. |
When an attestation process is executed, an attestation request is created and recorded in Oracle Identity Manager database. This request records for audit purposes, when an attestation process is executed. The attestation request record consists of basic identity and audit data and statistical data that is used in reports. The data includes the following items:
A request ID: Each attestation request has a unique identifier. Each attestation task that Oracle Identity Manager creates as a result of a request, stores as part of its record, the request ID of the associated attestation request.
Date and time of execution of the process.
Date and time of completion of the process: The date and time of completion of the process is considered to be the date and time for that request.
Total number of entitlements identified for attestation.
The number of provisioned resources that matched the selection criteria (of the resource scope of the attestation process) during this particular execution of the attestation process.
Number of entitlements certified.
Number of entitlements rejected.
Number of entitlements declined.
The reviewer who is assigned to an attestation task may not be able to attest to all the entitlements in the task. There may be multiple reasons for this. For example:
There may be too many entitlements covering too many users in the attestation task
The reviewer is not sure about the reasons for which the entitlements were provisioned
In these cases, the reviewer may want to involve other people in the review. A reviewer can delegate attestation of certain entitlements in the task.
To delegate attestation, the reviewer selects a set of entitlements in the task and delegates them to another user. This creates a new attestation task that is assigned to the selected reviewer.
The new task contains only those entitlements that the original reviewer selected. The original reviewer is no longer responsible for providing an attestation response for those entitlements. The new attestation task assigned to the delegate would track who performed the delegation, which task it was created from, and some other information, for example, the request ID. The new attestation task is treated in the same manner as any other attestation task. It can even be delegated. Figure 19-1 shows delegate attestation page.
The following is a description of the attestation lifecycle in Oracle Identity Manager.
This stage starts when an attestation process is run. Figure 19-2 describes the workflow involved in this stage.
Figure 19-2 Creating an Attestation Task: Workflow
When the attestation process is run, it first creates a corresponding attestation process instance. It then identifies the reviewers for this run of the process. In most cases, there is only one reviewer. There can even be a set of reviewers.
Whenever an invalid reviewer is found, a new reviewer is fetched from the process owner group. Oracle Identity Manager will select, if possible, a member of the process owner group who has not yet been used as a reviewer for this attestation request. If this is not possible, then Oracle Identity Manager will select a member of the process owner group who has already been selected to act as a reviewer. If Oracle Identity Manager cannot find a member of the process owner group, then it will assign XELSYSADM as the reviewer for the attestation task.
For each valid reviewer, the process calculates all the user entitlements that the reviewer must attest to as part of that task, as determined by the attestation scope defined in the process. The process then adds a reference and any related information regarding those user entitlements to the attestation data of the task. It also adds the number of entitlements covered by that task to the statistical field for the total number of entitlements identified for attestation in the process instance. The process then sends an e-mail message to the reviewer. It also sends e-mail to process owners about the reviewers with no e-mail address defined.
At the end of this stage, all the attestation tasks are in the attestation inboxes of the reviewers.
When an attestation task is assigned to a reviewer, the reviewer receives an e-mail, and the task is displayed in the reviewer's attestation inbox. The reviewer views task details in this inbox.
From the task details page, the reviewer provides a response and, if required, a comment for each entitlement. This marks the attestation entitlement detail in the task as Response Provided.
If the reviewer's response includes delegating the attestation activity for a specific entitlement, then the reviewer must provide a delegated user. Optionally, the reviewer can provide comments explaining why the reviewer is delegating the attestation activity to that user.
After the reviewer provides responses to all entitlements, the reviewer can commit their action for the attestation task by submitting all responses.
Figure 19-3 Flow of Events When Reviewer Responds to Entitlement
At this point, the next stage of the Attestation Business Process begins.
The Attestation Task is marked as Submitted. At this point the attestation task is frozen, and cannot be acted on further. For each entitlement in the attestation task, the response is examined by the system. If the response is to either certify or reject, then the provisioned resource instance corresponding to that entitlement is updated accordingly. At the provisioned resource instance level, the last attestation result, the time at which last attestation occurred, and who the reviewer was are recorded. If the response is to decline or delegate, then the attestation detail at the provisioned resource level is not changed.
The User Attestation Event Occurred task is inserted into the provisioning process of the resource instance. This starts any attestation-driven workflows that may have been defined. Any comments are saved to the notes field of the task.
The attestation entitlement detail in the task is marked as Response Submitted. Figure 19-4 shows the flow of events after the attestation task response is submitted.
Figure 19-4 Flow of Events After Attestation Task Response Is Submitted
The following statistics are updated on the process instance:
Number of entitlements certified
Number of entitlements rejected
Number of entitlements declined
Number of entitlements delegated
After all entitlements are covered, a subflow for follow-up action is initiated. In this flow, the process examines if the response for any of the entitlements in the task was declined. If there were any such entitlements, then the process sends e-mail to the Process Owner outlining the details of the decline action.
Next, the process examines if the response for any of the entitlements in the task was delegated. If there were any such entitlements, then the process identifies all the users that the reviewer selected as delegates and creates an attestation task for each. Each attestation task is only for the entitlements that the reviewer delegated to the user. The delegated user receives e-mail notification about the delegation.
After all the delegated attestation tasks are created, the subflow is completed and it merges back into the main flow. Figure 19-5 shows the flow of events of the follow-up action subflow.
With the follow-up subflow complete, the attestation task is marked as Complete.
The attestation engine implements the attestation lifecycle. It is a service in Oracle Identity Manager architecture that exposes APIs to receive instructions to initiate a particular attestation process. The API is called from the attestation scheduled task as well as from the Run Now button on the Attestation Process Detail page to support on-demand execution. It supports both drivers for initiation of attestation processes.
The attestation engine uses the JMS messaging service to perform offline, queued processing. This ensures better performance.
Note: Attestation depends on the entry in the user profile audit data. If the audit entry is not generated for a user who is part of the attestation process, then the reviewer would not be able to see the user and process form information in attestation. To avoid such situations, ensure that the Issue Audit Messages Task scheduled task is run before performing the attestation run. |
This new system scheduled task is responsible for examining the attestation processes defined in Oracle Identity Manager, and creating the necessary attestation tasks in the system.
Features of this scheduled task are:
By default, this scheduled task is set to run every night. You can change the schedule according to your requirements.
This scheduled task examines the attestation process definition table for all active (not system administrator) attestation processes
If the scheduled task finds that the next scheduled start time of a process is in the past, then the task sends a call to the Attestation Engine to initiate the attestation process.
You can enhance the provisioning processes predefined in Oracle Identity Manager to listen to triggers coming from attestation activity. In this way, you can define custom workflows as part of the provisioning workflow that would respond to attestation taking place (or not taking place, in case of a refusal), and therefore be initiated when attestation takes place. This serves two purposes:
The default attestation task in the flow, User Attestation Event Occurred, would provide the audit trail for the attestation history of the specific user entitlement.
There is one instance of this task for each time that resource instance is attested by the appropriate type of attestation process.
The response code set on the task indicates what the response provided by the reviewer is.
The user tagged as the person creating the task indicates who the reviewer is.
Any comment provided by the user is in the notes field for the task.
Using response-generated tasks, the default task can start the workflow to respond to a particular attestation response received. Therefore, for a particular resource, you can specify that the Reject response must start the appropriate workflow tasks in the provisioning process for disabling the account, as an example.
As part of the attestation processes, the Attestation Engine sends out e-mail to various interested parties. To make the e-mail configurable with respect to the content, they are made available as e-mail templates of the General type in Oracle Identity Manager Email Definition store. For context-sensitivity, the e-mail contain a set of variables that can be replaced with the required values.
This template is used to build the e-mail to send to the reviewer when an attestation task is assigned to the reviewer.
The following are variables in the Notify Attestation Reviewer template:
Variable | Description |
---|---|
Attestation Definition.Process Name |
Name of the attestation process |
Attestation Definition.Process Code |
Code for the attestation process |
Attestation Task.Task Assigned Date |
Date the attestation task was assigned |
The following is the Subject line of e-mail messages defined by the Notify Attestation Reviewer template:
A new attestation task for attestation process Attestation Definition.Process Name has been added to your attestation inbox
The body of the e-mail message contains the following information:
The attestation task details are as follows Process Name: Attestation Definition.Process Name Process Code: Attestation Definition.Process Code Data Type: Access Rights Assigned Date: Attestation Task.Task Assigned Date