| Oracle® Identity Manager Administrative and User Console Guide Release 9.0.3 Part Number B32450-01 |
|
|
View PDF |
| Oracle® Identity Manager Administrative and User Console Guide Release 9.0.3 Part Number B32450-01 |
|
|
View PDF |
Attestation enables reviewers to be notified of a report they must review that describes the provisioned resources that certain users have. The reviewer can attest to the accuracy of the entitlements by providing a response. This attestation action, along with the response the reviewer provided, any associated comments, and an audit view of the data that the reviewer viewed and attested 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 a business process that is hard-coded with configuration parameters in Oracle Identity Manager that creates an attestation task for a user in Oracle Identity Manager. 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 kicked off, 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 sub-flows in the provisioning processes defined in Oracle Identity Manager.
Attestation activity can be initiated on a periodic or an ad-hoc basis.
A reviewer can delegate particular entitlements in an attestation task to someone else for review. This creates another attestation task that is assigned to the delegated user.
This appendix discusses the following topics:
An attestation process is the mechanism by which an attestation task gets set up. It therefore needs to know how to define all the components that make up the attestation task, and associate it with a schedule at which it needs to occur. This definition is also the basis on which the same attestation task can be initiated on an ad-hoc basis. Thus, an attestation process definition will include:
Attestation Type: There are two types of attestation processes:
User Entitlement Attestation: This conforms with the user-based attestation scope
Resource Entitlement Attestation: This conforms with the resource-based attestation scope
Attestation Scope: This defines the algorithm by which the target user entitlements of the attestation process will be calculated. This will be based on the type
Definition of Attestation Schedule: When attestation process should be kicked off on a scheduled basis
Process Owner: This is a designated group of users that are responsible for monitoring any activities related to the process.
They will be notified of any issues that occur when the process executes.
They will have privileges to view the Process Definition, but will not have admin privileges by default
They will have the ability to execute the process in an ad-hoc manner
Process Administrators: These are the groups of users that have administrative privileges over the process definition. This essentially maps to our normal 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.
Any attestation process can be disabled in order to prevent it from running at its preconfigured schedule. This control gives an administrator better control over the environment. A disabled attestation process can be enabled, but it cannot be enabled if its next run time is in the past. A user who enables an attestation process must set its next run time in the future.
Any attestation process can be deleted. This is be a soft-delete. It does not actually delete the records, since these must be maintained for audit purposes. Instead, the attestation process will be marked as deleted.
A deleted process no longer appears in the administrative interfaces. Since process names and codes are unique, a name once used is no longer available, and no new attestation process may 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 appears in a user's attestation inbox. The following are the basic components of an attestation task
Task Source: This specifies whether the attestation task came about as 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 was the source of the entitlements.
Attestation Scope: Defines what the reviewer has to attest to. This is a list of user provisioned resource instances defined as follows:
Resource-Based: All user provisioned resource instances being attested to are for the specified resource. The scope is any user who has a non-revoked instance of the specified resource.
User-Based: The user entitlements being attested to are for a specific set of users. The reviewer attests to all the appropriate entitlements for the users in the set.
Attestation Data: Detailed data for the user entitlements in the attestation scope. This is basically data from the process form of the provisioned resource instance
Attestation Date: Defines the date on which the attestation task was initiated, and the point in time with respect to the attestation data that the user must attest to. Note that the reviewer does not attest to what the user has today. They attest to what the user had on the date specified in the attestation task. Usually, the two dates are the same. But the distinction eliminates complexities due to activity lag.
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 should 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 where processes have been configured incorrectly, and is useful in early stages of a rollout.
Delegate: The reviewer wants to reassign the attestation of this entitlement to another qualified person.
Important 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, proxy management, and so on.When an attestation process is executed, an attestation request is created and recorded in the Oracle Identity Manager data store. This request acts as an audit record of the times that an attestation process is executed. The attestation request record consists of basic identifying 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
An administrator can mark each resource object definition in Oracle Identity Manager as being financially significant or not.
The role of this property is to flag resources that should have some kind of attestation coverage. This can then be used in determining the following:
What resources that do not have an attestation process defined should have one
What resource entitlements that have not been attested to should have been
When determining the user entitlements that need attestation as part of an Attestation Process that has user-based attestation scope, only those entitlements of a user will be considered that are for a resource marked as being financially significant.
When a resource is created, this flag will default to off (not financially significant).
If 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:
There may be too many entitlements covering too many users in the attestation task
The reviewer does not have enough visibility into the users that the entitlements pertain to
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 that 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 did the delegation, which task it was spawned from, and all the other usual information, for example, the request ID, and so on. 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 is the stage starts when an attestation process is run. The flowchart in Figure A-1 describes the workflow.
Figure A-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, but there can be a set of reviewers.
For each reviewer, the process creates an attestation task, and sets its associated attestation date. If the reviewer is invalid, the process adds the name and other details of the reviewer to a list of bad reviewers. A reviewer is invalid if the Oracle Identity Manager User record is disabled or deleted, or if the user has a proxy that is currently active. It also computes a list of reviewers with no email address defined.
For each valid reviewer, the process calculates all the user entitlements that the reviewer needs to attest to as part of that task, as determined by the attestation scope defined in the process. If the attestation scope is user-based, it retrieve only the resources that are marked as being financially significant. The process then adds a reference and any related information regarding those user entitlements to the attestation data of the task. It also takes the number of entitlements covered by that task, and adds it to the statistical field for Total Number of Entitlements identified for Attestation in the process instance. The process then sends an email message to the reviewer.
After examining each reviewer, the process checks for invalid reviewers and emails a list of invalid reviewers, if there are any, to the process owner. It also sends email to process owners about the reviewers with no email 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, they receive an email, and the task appears in their attestation inbox. The reviewer views task details in their attestation inbox.
From the task details page, the reviewer provides a response and an optional 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, the reviewer must provide a delegated user. Optionally, the reviewer can provide comments regarding why they are delegating the attestation activity to that user.
After the reviewer provides responses to all entitlements, he or she can commit their action for the attestation task by submitting all responses.
Figure A-2 Flow of Events when Reviewer Responds to Entitlement
At this point, the next stage of the Attestation Business Process would kick off.
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.
If the response is either to certify or reject, 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, the attestation detail at the provisioned resource level is not changed.
Depending on the attestation process type, the User Attestation Event Occurred or the Resource Attestation Event Occurred task is inserted into the provisioning process of the resource instance. This kicks off any attestation driven workflows that may have been defined. Any comments are saved to the task's notes field.
The attestation entitlement detail in the task is marked as Response Submitted.
Figure A-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 sub-flow 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 email to the Process Owner outlining the details of the refusal.
Next, the process examines if the response for any of the entitlements in the task was delegated. If there were any such entitlements, the process identifies all users the reviewer selected as a delegate, and creates an attestation task for each. Each attestation task is for just only the entitlements that the reviewer delegated to the user. The delegated user receives email notification of the delegation.
After all the delegated attestation tasks are created, the sub-flow finishes and joins back into the main flow.
With the follow-up flow 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 ad-hoc execution. It supports both drivers for initiation of attestation processes.The attestation engine uses messaging to off-line processing when appropriate to create transaction separation, and ensure that there are no end-user performance issues.
A new system scheduled task that is responsible for examining the Attestation Processes defined in Oracle Identity Manager, and creating the necessary attestation tasks in the system.
Salient features of this scheduled task are:
Out of the box, this scheduled task will be set to run every night. This is just the default value we provide; the customer will be able to change this to their needs
It will examine the attestation process definition table for all active (not disabled) attestation processes
For any process it finds that needs to be run (its next scheduled start time is in the past), it will initiate a call to the Attestation Engine to initiate the attestation process.
The provisioning processes defined in Oracle Identity Manager will be enhanced to listen to triggers coming from Attestation activity. In this way, a customer could 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 – either "User Attestation Event Occurred" or "Resource Attestation Event Occurred" – would provide the audit trail for the attestation history of the specific user entitlement.
There would be one instance of this task for each time that resource instance was attested by the appropriate type of attestation process
The response code set on the task would indicate what the response provided by the reviewer was
The user tagged as the person creating the task would indicate who the reviewer was
Any comment provided by the user would be in the notes field for the task
Using response-generated tasks, the default task can kick off workflow to respond to a particular attestation response received. So, for a particular resource, the customer could configure that the "Reject" response should kick off the appropriate workflow tasks in the provisioning process for disabling the account, as an example.
As part of the Attestation Processes, the Attestation Engine will send out emails to various interested parties. In order to make the emails configurable by the customer with respect to content, they will be made available as email templates of type 'General' in the Oracle Identity Manager Email Definition store. For context-sensitivity, the emails will support a set of email variables, that will be replaced by the appropriate values.
This template is used to build the email to send to the reviewer when an attestation task is assigned to him or her.
The following are variables in the Notify Attestation Reviewer template:
| Variable Name | 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 |
This template is used to build the email to send to a reviewer when an attestation task is delegated to him or her.
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 was Assigned |
<Attestation Task.Delegated By First Name> |
First Name of reviewer that did the delegation |
<Attestation Task.Delegated By Last Name> |
Last Name of reviewer that did the delegation |
<Attestation Task.Delegated By User Id> |
User ID of reviewer that did the delegation |
The following is the Subject line of email 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 Invalid Attestation Reviewers template is used to build the email to send to process owners notifying them of any invalid reviewers found while generating attestation tasks within a process.
The following are variables in the Notify Process Owner about Attestations Reviewers template:
| Variable | Definition |
|---|---|
<Attestation Request.Request Id> |
ID of the Attestation Request |
<Attestation Definition.Process Name> |
Name of the Attestation Process |
<Attestation Request.Request Creation Date> |
Date the Attestation Request was created |
<Attestation Task.Reviewer First Name> |
First Name of reviewer that was invalid |
<Attestation Task.Reviewer Last Name> |
Last Name of reviewer that was invalid |
<Attestation Task.Reviewer User Id> |
User ID of reviewer that was invalid |
<Attestation Task.Reviewer Invalid Reason> |
Reason the reviewer was invalid |
The following is the Subject line of email messages defined by the Notify Process Owner about Attestations Reviewers template:
Some of the reviewers are invalid for the attestation process <Attestation Definition.Process Name>, request <Attestation Request.Request Id>
The body of the message contains the following information:
The following attestation process generated some invalid reviewers. Attestation process: <Attestation Definition.Process Name> Attestation Request ID: request <Attestation Request.Request Id> Request date: <Attestation Request.Request Creation Date> Invalid Reviewers: <Attestation Task.Reviewer First Name> <Attestation Task.Reviewer Last Name> [<Attestation Task.Reviewer User Id>] - <Attestation Task.Reviewer Invalid Reason>
The Notify Declined Attestation Entitlements template is used to build the email 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 reviewer |
<Attestation Task.Reviewer Last Name> |
Last Name of reviewer |
<Attestation Task.Reviewer User Id> |
User ID of reviewer |
<Attestation Data.Provisioned User First Name> |
First Name of user being attested |
<Attestation Data.Provisioned User Last Name> |
Last Name of user being attested |
<Attestation Data.Provisioned User User Id> |
User ID of user being attested |
<Attestation Data.Resource Name> |
Name of resource being attested |
<Attestation Data.Entitlement Descriptive Data> |
The descriptive data of the entitlement being attested |
The following is the Subject line of email 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 appears 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 email to send to process owners notifying them of any reviewers where there is no email 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 the Attestation Request was created |
<Attestation Task.Reviewer First Name> |
First Name of reviewer that was invalid |
<Attestation Task.Reviewer Last Name> |
Last Name of reviewer that was invalid |
<Attestation Task.Reviewer User Id> |
User ID of reviewer that was invalid |
The following is the subject line for emails defind by the Notify Process Owner About Reviewers with No Email Defined template:
Email 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 email addresses defined. Attestation requests have been generated for these reviewers and can be accessed by logging into Oracle Identity Manager. However, notification emails 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>]
