| Oracle® Identity Manager Administrative and User Console Guide Release 9.1.0.2 Part Number E14765-02 |
|
|
View PDF |
| Oracle® Identity Manager Administrative and User Console Guide Release 9.1.0.2 Part Number E14765-02 |
|
|
View PDF |
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 provisioned resources of other users. A reviewer can attest to the accuracy of the 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:
Attestation Scope: This defines the algorithm by which the target user entitlements of the attestation process are determined.
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.
Process Administrators: These are the groups of users that have administrative permissions over the process definition. This essentially maps to the typical delegated administrator model.
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 the 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 a user's attestation inbox. The following are the basic components of an attestation task:
A 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 overall attestation task level, but rather against each entitlement in the attestation scope. The following are attestation actions:
Certify: The reviewer certifies that the user being reviewed is allowed to have this entitlement in the form with the data and fine-grained permissions that it has.
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 attestation administrator group.
Delegate: The reviewer wants to reassign the attestation of this entitlement to another qualified person.
Note:
The attestation tasks are not workflow tasks in the 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, for example, dynamic assignment, escalation, and proxy management.When an attestation process is executed, an attestation request is created and recorded in the Oracle Identity Manager database. This request acts as an audit record of the times that 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 task that is created as a result of a request stores the request ID as part of its record.
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 entitlements is as follows:
Total Number of Entitlements = Number Certified + Number Rejected + Number Declined
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.
Note:
A reviewer can view the list of users available for delegation only if the user is a member of a group that has read permissions for the organization to which the users belong. However, if the reviewer is an administrator with read permissions, the reviewer can view all the users available in the organization for delegating the tasks.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.
The following is a description of the attestation lifecycle in Oracle Identity Manager.
This stage starts when an attestation process is run. Figure 15-1 describes the workflow involved in this stage.
Figure 15-1 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. The user that has not yet been used in the attestation request is the highest priority user from the group. Alternatively, if all users are used, then the next priority user from the process owner group is fetched. If no user is found from this process, then the task is assigned to XELSYSADM.
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 15-2 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 15-3 shows the flow of events after the attestation task response is submitted.
Figure 15-3 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 15-3 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 the 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 feature 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 the 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
This template is used to build the e-mail to send to a reviewer when an attestation task is delegated to the reviewer.
The following are variables in the Notify Delegated Reviewers 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 is assigned |
| Attestation Task.Delegated By First Name | First name of the reviewer who performed the delegation |
| Attestation Task.Delegated By Last Name | Last name of the reviewer who performed the delegation |
| Attestation Task.Delegated By User Id | User ID of the reviewer who performed the delegation action |
The following is the Subject line of e-mail messages defined by the Notify Delegated Reviewers template:
Attestation Task.Delegated By User Id has delegated to you an attestation task from attestation process Attestation Definition.Process Name
The body of the 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 Delegated By: Attestation Task.Delegated By First Name Attestation Task.Delegated By Last Name [Attestation Task.Delegated By User Id]
The Notify Declined Attestation Entitlements template is used to build the e-mail to send to process owners notifying them of any declined entitlement attestations.
The following are variables in the Notify Process Owner about Declined Attestation Entitlements template:
| Variable | Description |
|---|---|
| Attestation Request.Request Id | ID of the attestation request |
| Attestation Definition.Process Name | Name of the attestation process |
| Attestation Task.Reviewer First Name | First name of the reviewer |
| Attestation Task.Reviewer Last Name | Last name of the reviewer |
| Attestation Task.Reviewer User Id | User ID of the reviewer |
| Attestation Data.Provisioned User First Name | First name of the user being attested |
| Attestation Data.Provisioned User Last Name | Last name of the user being attested |
| Attestation Data.Provisioned User User Id | User ID of the user being attested |
| Attestation Data.Resource Name | Name of the resource being attested |
| Attestation Data.Entitlement Descriptive Data | Descriptive data of the entitlement being attested |
The following is the Subject line of e-mail messages defined by the Notify Process Owner About Declined Attestation Entitlements template:
User access rights in attestation request Attestation Request.Request Id have been declined by Attestation Task.Reviewer User Id
The following is displayed in the body of the message:
Attestation of the following user access rights were declined by the reviewer. Reviewer: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id] Attestation Process: Attestation Definition.Process Name Attestation Request ID: request Attestation Request.Request Id Access Rights Data: Attestation Data.Provisioned User First Name Attestation Data.Provisioned User Last Name [Attestation Data.Provisioned User User Id] - Attestation Data.Resource Name - Attestation Data.Entitlement Descriptive Data
The Attestation Reviewers With No Email Defined template is used to build the e-mail to send to process owners notifying them of reviewers for whom there is no e-mail address defined.
The following are variables in the Notify Process Owner About Reviewers with No Email Defined template:
| Variable | Description |
|---|---|
| Attestation Request.Request Id | ID of the attestation request |
| Attestation Definition.Process Name | Name of the attestation process |
| Attestation Request.Request Creation Date | Date when the attestation request was created |
| Attestation Task.Reviewer First Name | First name of the reviewer that is invalid |
| Attestation Task.Reviewer Last Name | Last name of the reviewer that is invalid |
| Attestation Task.Reviewer User Id | User ID of the reviewer that is invalid |
The following is the Subject line for e-mail defined by the Notify Process Owner About Reviewers with No Email Defined template:
E-mail address is not defined for some of the reviewers in attestation process Attestation Definition.Process Name, request Attestation Request.Request Id
The following is the body of the message:
The following attestation reviewers do not have e-mail addresses defined. Attestation requests have been generated for these reviewers and can be accessed by logging in to Oracle Identity Manager. However, notification e-mails were not sent. Attestation process: Attestation Definition.Process Name Attestation Request ID: request Attestation Request.Request Id Request date: Attestation Request.Request Creation Date Reviewers Without Email: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id]
A menu item in the Administrative and User Console provides access to the Attestation Process Configuration pages. Oracle Identity Manager administrators can use these pages to:
Define new attestation processes.
Manage existing processes.
Initiate ad-hoc attestation processes.
The top-level Attestation menu contains the following links:
Create
Manage
Dashboard
These menu items are governed by the same delegated administration permissions that govern all menu items in the Administrative and User Console.
These menu items are defined but not assigned to any group in Oracle Identity Manager. They will be assigned to the System Administrators group in Oracle Identity Manager if audit compliance components are installed.
Attestation has the following dependencies:
The User Profile Audit feature must be enabled.
Historical data must be collected at least up to the Process Form level.
If the auditing level is set below the required levels, then clicking menu item links related to attestation generates the Attestation Feature Not Available page, and prevents the user from defining any attestation processes.
Audit levels are controlled by the system property called XL.UserProfileAuditDataCollection and the attestation feature expects this value to be set to at least Resource Form.
Note:
The Oracle Identity Manager Permission model applies to the procedure described in this section. This model restricts any list of targets (for example, users) to only those targets for which the logged-in user has read access.To create an attestation process:
In the left navigation pane, expand the Attestation menu, and then click Create.
The Step1: Define Process page is displayed.
Enter values for the fields described in the following table, and then click Continue:
| Field | Description |
|---|---|
| Name | A unique name for the attestation process. The name must be unique across system administrator and deleted attestation processes. |
| Code | An identifying code (up to 32 characters) for the process. The code must be unique across system administrator and deleted attestation processes.
Note: A code enhances the identification of the attestation process definition. However, if you do not specify a value in the Code field, then the attestation process is identified by the unique name. |
| Description | Detailed description of the attestation process. |
On the Step 2: Define User Scope page:
Select an attribute from the Attribute list. The Attribute list displays the user attributes given in the FormMetaData.xml file and the user-defined attributes from the user form. The attribute that you select is used to specify the criteria that must be met by users on whom the attestation process is applied.
From the Condition list, select a condition. The Condition list of values will change based on the type of attribute selected. For example, if you select User ID in the Attribute field, then the conditions displayed are Contains, Does Not Contain, Is Exactly, and Is Not Exactly. If you select the Start Date attribute, then the conditions displayed are Before, After, and Between.
In the Value field, enter a value for the user attribute.
Select the Recursive option. The Recursive check box is used for the entities for which you want to include the child entities while defining user scope. For example, if you select Organization in the user scope and then select Recursive, then the operation also includes all the suborganizations.
Click Add to add a new row to the user scope table, and click Continue.
On the Step 3: Define Resource Scope page, select a resource for the attestation process as follows:
From the Attribute list, select one of the resource attributes listed in the following table:
| Attribute | Expression | Description |
|---|---|---|
| Name | Full text or wildcard | The name of the resource. |
| Type | Lookup values with the option to select all or a subset | The type of resource. |
| Resource Audit Objectives | Lookup values with the option to select all or a subset | The audit objectives assigned for a resource, which is provisioned. For example, whether or not the resource is financially significant.
For more information about Resource Audit Objectives, see "Viewing Resource Details". |
| Administrator User Groups | Lookup values with the option to select all or a subset | The user groups that have administrative permissions for a resource. |
| Authorized User Groups | Lookup values with the option to select all or a subset | The user groups that are authorizers or approvers for the resources. |
| Resource Status | Full text or wildcard | The status displayed when a resource is provisioned to a user, such as Certify, Reject, Open, or Closed. |
From the Condition list, select a search condition.
In the Value field, enter a value for the resource attribute.
Click Add to add a new row to the resource scope table, and then click Continue.
On the Step 4: Define Administration Details page, define the reviewer to attest data, the attestation process schedule, and the process owner by performing the following steps:
From the Reviewer list, select the type of reviewer for the attestation process, such as a single specific user or resource administrator with highest priority. Then, select the reviewer from the adjoining lookup field.
Specify the attestation process schedule to run the attestation process once or repeatedly after a specific number of days, months, or years.
In the Starting on field, specify a start date for the attestation process.
In the Process owner group lookup field, specify a group that is the process owner for the attestation process.
If you want the process owner to be notified by e-mail if the reviewer refuses the attestation process, select Email process owner if reviewer refuses attestation request. Then, click Continue.
On the Step 5: Verify Info page, review the details of the attestation process, and then click Create Process.
You are redirected to a page with a message that you have successfully created an attestation process definition. Clicking the process name takes you to the Attestation Process Detail page. To create another attestation process, click Create Another Attestation Process Definition.
The Attestation Process Detail page is described in the "Managing Attestation Processes" section.
To manage attestation processes:
In the left navigation pane, expand the Attestation menu, and then click Manage. The Manage Attestation Process page is displayed.
On the Manage Attestation Process page, enter the search criteria for the attestation process you want to manage. You can search by attestation process name, process code, reviewer type, or process owner. After you enter your search criteria, click Search. The Attestation Process Details page is displayed with the attestation processes that match your search criteria. The attestation processes displayed are the ones that the logged-in administrator is allowed to view based on permissions, or by virtue of being a member of the Process Owner group. This page does not show any deleted processes. The columns displayed on the page are listed in the following table:
| Column | Description |
|---|---|
| Names | Specifies the name of the process. |
| Code | Specifies the attestation process code. |
| Description | Specifies a description for the process. |
| Status | Indicates whether the attestation process is active or system administrator. |
| Type | Specifies the type of resource. |
| User Scope | Specifies the scope of the user who will be a part of the attestation process. |
| Resource Scope | Specifies the resources that are within the scope of the attestation process. |
| Reviewer Type | Indicates the type of the reviewer. |
| Reviewer Name | Indicates the name of the reviewer. |
| Schedule | Indicates if the process is scheduled to run only once, or on a daily, monthly, or yearly basis. |
| Last Start | Specifies the last time an attestation process was run. |
| Next Start | Specifies when the process is scheduled to run next. |
| Process Owner Group | Indicates the process owner group. In addition, it specifies whether or not the process owner will be notified by e-mail if the reviewer refuses the attestation request. |
| Last Completion | Specifies the last time an instance of this process was completed. |
The rest of this section discusses the following topics:
To edit an attestation process:
On the Attestation Process Detail page, click Edit.
On the Edit Attestation Process page, make the required changes to the attestation process, and then click Save.
The fields on the Edit Attestation Process page are the same as those displayed in the "Creating Attestation Processes" section.
To disable an active attestation process:
On the Attestation Process Detail page, click Disable.
Note that the Disable button is displayed only when a process is active.
On the Disable Attestation Confirmation page, click Confirm Disable.
An attestation process can be enabled only if its next start time is in the future and if the process is disabled.
To enable an attestation process:
On the Attestation Process Detail page, click Enable.
Note that the Enable button is displayed only when the process is disabled.
On the Enable Attestation Confirmation page, click Confirm Enable.
You can edit, disable, or delete an attestation process only as a process administrator with the required permissions.
To delete an attestation process:
On the Attestation Process Detail page, click Delete.
On the page, click Confirm Delete.
This feature enables you to run unscheduled attestation processes. To run an attestation process, click Run Now on the Attestation Process Detail page. This starts the attestation process independent of the attestation schedule.
Only users in the process owner group can start unscheduled attestation processes.
The tasks of adding, deleting, and updating administrative groups for attestation processes are similar to the tasks of adding, deleting, and updating administrative groups for users and organizations.
To manage the administrators of an attestation process, select Administrators from the Additional Details list on the Attestation Process Detail page. The Administrative Groups page is displayed. You can use this page to add and remove administrators for an attestation process and update administrator permissions.
The permission model for an attestation process definition is as follows:
To view the attestation process definition, the user must be either of the following:
A member of a group that has the appropriate read permissions in the administrators group
A member of the group that is the process owner
To edit the attestation process definition, the user must be a member of a group that has the required write permissions in the administrators group.
To delete the attestation process definition, the user must be a member of a group that has the required delete permissions in the administrators group.
To view the execution history of an attestation process, select Execution History from the Additional Details list on the Attestation Process Detail page. The Attestation Process Execution History page is displayed.
The following are the columns in the Attestation Process Execution History table:
| Column | Description |
|---|---|
| Request ID | ID for the attestation process instance that was run |
| Reviewer | Name of the reviewer for the attestation process |
| Initiated On | Date and time when the request was started |
| Completed On | Date and time when the request was completed
If the request is still pending, then it shows Not Completed. |
On the Attestation Process Execution History page, click the request ID link to open the Request Detail page. On this page, you can filter the requests according to the certified, rejected, open, and closed state.
You use the Attestation Dashboard to view the state of attestation processes that are owned by any group of which you are a member. To use the Attestation Dashboard, expand the Attestation menu, and then click Attestation Dashboard. The Attestation Dashboard page displays a table listing the state of attestation processes that are owned by any group of which you are a member. The Attestation Dashboard table contains the columns listed in the following table:
| Column | Description |
|---|---|
| Process Code | The attestation process code. |
| Process Names | The name of the process. The Attestation Process Detail page is displayed when the link for an attestation process name is clicked. |
| Last Completion | The date and time when the instance was run before the latest one was completed. If it does not exist, then the value must be None. It is a link that takes the user to the Attestation Request Detail page for the required Attestation Request. |
| Current Request Date | The date and time when the last instance of this Process was run. If it has never been run, then the value is New. It is a link that takes the user to the Attestation Request Detail page for the required Attestation Request. |
| Current Completion | The date and time when the last instance run was completed. If it has not been completed, then the value is Pending. |
| Total Records | The total number of entitlements identified for attestation and covered by an attestation task as part of the last process instance. |
| Certified | The number of entitlements certified in the last attestation process instance. |
| Rejected | The number of entitlements rejected in the last attestation process instance. |
| Open | All the open records for which no responses have been provided by the reviewers. |
You can access the drill-down page from the Attestation Dashboard page. The drill-down page displays the attestation details of all entitlements covered by a particular run of the Attestation Process.
To view attestation request details:
Click the link for the Last Completion or Current Request Page fields listed in the table on the Attestation Dashboard page.
The Attestation Request Detail page displays the request details for the selected attestation process, along with a table that contains the following columns:
| Column | Description |
|---|---|
| User | User whose entitlement is being attested. The data is displayed as a link. When you click the link, the user profile page is displayed with the user details for the attestation date. |
| Resource | Resource that is the basis for the entitlement being attested. The data is displayed as a link. When you click the link, a page is displayed with the process form data of the entitlement for the attestation date. |
| Descriptive Data | Description of the provisioned resource instance. |
| Comments | Comment or status of the request. The value can be one of the following:
|
| Attestation Result | Last response that was provided for the attestation. |
| Reviewer | User who provided the response. The data is displayed as a link. When you click the link, the user profile page is displayed with the current user details. |
| Delegation Path | If the attestation of an entitlement goes through any delegation, then you can use the View link in this column to see the Delegation Path Detail page. If no delegation has taken place, then None is displayed. |
| Comments | Reviewer comments. Long comments are truncated, and tooltips are used to show the full text of the comments. |
Any attestation requests that require delegation include a link in the Delegation Path column.
Clicking the link displays a Delegation Path page that provides information about the delegation path of the attestation request.
The Data Attested field shows details about the entitlement being attested. It constructs the value by putting together user information, the resource name, and descriptive data in the following format:
User_First_Name User_Last_Name [User_ID] - Resource_Name - Descriptive_Data
The table on the Delegation Path page contains the following fields:
| Column | Description |
|---|---|
| Reviewer | The reviewer to whom the entitlement for attestation is assigned. The data is displayed as a link. When you click the link, the current user profile data is displayed. |
| Attestation Result | Action supplied by the reviewer. Except for the first record, the value is always Delegated. |
| Attestation Date | The date and time of the attestation response of the reviewer. |
| Comments | Reviewer comments. Long comments are truncated, and tooltips are used to show the full text of the comments. |
As part of the attestation process, the attestation engine sends e-mail to concerned parties at various stages. You can configure e-mail content by using e-mail templates of the General type in the Oracle Identity Manager Email Definition store.
In the templates, the form user is defined as XELSYSADM. You can change it to a different user. You must ensure that the e-mail address is defined for the user selected to use these templates. Otherwise, the system may not be able to send out notifications.
The following e-mail notification templates are available:
Notify Attestation Reviewer: Used for sending e-mail when an attestation task is assigned to a reviewer.
Notify Delegated Reviewers: Used for sending e-mail to reviewers when an attestation task is delegated to them.
Notify Declined Attestation Entitlements: Used for sending e-mail to users in the Process Owner group if a reviewer declines any entitlements.
Attestation Reviewers With No E-Mail Defined: Used for sending e-mail to users in the Process Owner group if an e-mail address is not defined for any of the reviewers.
A system scheduled task called Attestation Grace Period Expiry Checker is used to examine the attestation processes defined in Oracle Identity Manager and to create the required attestation tasks.
The features of the Attestation Grace Period Expiry Checker scheduled task are:
The scheduled task is set to run every 30 minutes by default. You can change this according to your requirement.
The scheduled task examines all active attestation processes.
The scheduled task checks for attestation processes whose expiry date is within one, two, or three days and sends warning e-mail to the corresponding reviewers. If the attestation process has already expired, then it removes the actions provided by the reviewers and assigns it to the next priority member in the process owner group.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|