| Oracle® Identity Manager Administrative and User Console Guide Release 9.0 B25936-01 |
|
 Previous |
 Next |
| Oracle® Identity Manager Administrative and User Console Guide Release 9.0 B25936-01 |
|
Previous |
Next |
Attestation is a mechanism by which reviewers are periodically notified of a report they must review that outlines the provisioned resources that certain users have. The user can then attest to the entitlements accuracy with an appropriate response. This attestation action, along with the response the reviewer provided, any associated comments, and an audit view of the actual data that the reviewer viewed and attested to, is tracked and fully audited to provide a complete trail of accountability. The way in which all of this manifests itself in Oracle Identity Manager will be in the form of an Attestation Task.
Attestation will be supported in Oracle Identity Manager through the definition of Scheduled Attestation Processes. It is important to understand that an attestation process is not a workflow in itself, as we know and understand workflows in the Oracle Identity Manager context. Instead, it is a business process set up (hard-coded with configuration parameters) in Oracle Identity Manager that creates an Attestation Task for a user in Oracle Identity Manager. The user (the reviewer) must accomplish this process in order to provide correct audit information.
Tracking of attestation activity for a particular provisioned resource instance will be done through tasks in the provisioning processes of resource objects, and the customer has the ability to initiate workflow activity based on these attestation actions. In this way, the framework provides for additional activities to be kicked off (and therefore actual workflow that can be modeled in the process definition form/workflow designer to be initiated) based on the initial attestation action. Thus there will be Attestation Sub-Flows within the provisioning processes defined in Oracle Identity Manager.
Any attestation activity could be kicked off on a periodic basis, or in a completely ad-hoc manner (kick-off now), with the former being the more common use case.
Delegation provides a mechanism by which a reviewer can select certain entitlements within an Attestation Task, and assign them to someone else for review. This in effect creates another Attestation Task assigned to the delegated user.
This appendix includes the following information:
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. Any disabled attestation process can be enabled, of course. However, it cannot be enabled if its "next run time" is in the past (since that would cause it to run almost immediately). So any user enabling an attestation process will first have to set its next run time into the future.
Any Attestation Process can be deleted. This would be a soft-delete, since it would not actually delete the records (must be maintained for audit purposes). Instead, the Attestation Process will be marked as deleted.
Any Process deleted will no longer appear in the administrative interfaces. Since Process names and codes need to be maintained as unique, a name once used will not be available. Hence even though an Attestation Process may have been deleted, 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. This attestation task would show up in a user's Attestation Inbox. The following are the basic components of an Attestation Task
A Reviewer: The user that has to do the attestation activity
Task Source: This defines the way in which 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 which reviewer did the delegation, and which task was the source of the entitlements
Attestation Scope: Defines what the reviewer has to attest to. This is essentially a list of user provisioned resource instances. There will be two ways in which scope can be defined:
Resource-Based: In this algorithm, all user provisioned resource instances being attested to are for the specified resource. Thus, the attestation scope is any user who has a non-revoked instance of the specified resource.
User-Based: In this algorithm, the user entitlements being attested to are for a specific set of users. The reviewer will be attesting all the appropriate entitlements that the users that fall within the set have
Attestation Data: Detailed data for the user entitlements that fall within 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. This is important to understand. The reviewer is not attesting to what the user has today. They are attesting to what the user had on the date that the attestation task is asking the reviewer to attest to. Usually, the two dates (today and the attestation date) will be the same. But the distinction is important to eliminate complexities due to activity lag
Attestation Actions: These are the actions that the reviewer can take on the attestation scope. Again, it is important to note that the action is not at the overall attestation task level, but rather against each entitlement in the attestation scope. The framework supports four attestation actions:
Certify: The reviewer has looked at the details of the user entitlement, and certifies that the user being reviewed is allowed to have this entitlement in the form as it exists (with the data/fine-grained permissions that it has)
Reject: The reviewer has looked at the details of the user entitlement, and does not think that the user should have this entitlement in the form as it exists
Decline: The reviewer does not feel qualified to attest to this entitlement, and therefore does not want to accept the responsibility of attesting to the entitlement. This will mostly be used in cases where processes have been wrongly configured, and will be valuable in early stages of a rollout
Delegate: The reviewer wants to reassign the attestation of this entitlement to someone who they feel is more qualified to make the appropriate judgment
|
Important Note: It is important to remember that the attestation tasks are not workflow tasks in the Oracle Identity Manager definition, since they are not created as part of workflow. This is a completely separate task concept, and as such, will not support all the task management features that our workflow engine supports, like dynamic assignment, escalation, proxy management, and so on. |
The Attestation Inbox is a new concept being introduced in Oracle Identity Manager. While it will look and behave just like the other two inboxes we currently have ("Pending Approvals" and "Open Tasks"), it is not based upon tasks in Oracle Identity Manager workflows. Instead it enables the user to manage attestation tasks (as described earlier) that are assigned to them.
From this inbox, the user will be able to see the attestation tasks assigned to him, view the details of the tasks (in a drill-down manner) and provide responses and comments.
Any time 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 all the times that an attestation process was executed. The Attestation Request record is composed of some basic identifying and audit data, and also some statistical data that is used in reports. The data includes
A Request ID
Date & Time of execution of the process
Date & Time of completion of the process
Total Number of Entitlements identified for Attestation
Number of Entitlements certified
Number of Entitlements rejected
Number of Entitlements declined
Each Attestation Task created as a result of this Request will record the Request ID as part of its record.
The Date & Time of completion of the process is considered to be the date and time when for that Request:
Total Number of Entitlements = Number Certified + Number Rejected + Number Declined
Each Resource Object Definition in Oracle Identity Manager would have an extra property that would allow an administrator to mark it as being "financially significant" or not.
The role of this property would be to flag resources that should have some kind of attestation coverage. This can then be used in determining:
Which resources that should have an attestation process defined do not have one
Which resource entitlements that should have been attested to have never 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).
There may be cases where the reviewer assigned an Attestation Task cannot realistically attest to all the entitlements contained within that task. There may be multiple reasons for this:
There may be too many entitlements covering too many users within the attestation task
The entitlements covers users that the reviewer does not have enough visibility into
In such cases, rather than declining the attestation, the reviewer may want to get other people involved in the review - either as a way of "dividing-and-conquering" the work, or because those people are better equipped to answer the questions that attestation is asking. In other words, the reviewer would like to delegate attestation of certain entitlements within the task to other reviewers. This is supported through delegation.
When a reviewer wants to delegate attestation, they would select a set of entitlements within the task and specify another user to assign those entitlements to for review. This would result in the creation of a new Attestation Task, one that is assigned to the selected reviewer, and 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 Attestation Task it was spawned off from, and all the other usual information (Request ID, and so on). The new Attestation Task is treated as any Attestation Task, and can even be further delegated.
The following is a description of the Attestation Lifecycle Process that will be implemented in Oracle Identity Manager. Due to the elements of human interaction, it can be divided into multiple stages.
This is the stage that is kicked off 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 (executed), it will first create a corresponding Attestation Process Instance. It will then look at its definition to figure out who the reviewers for this run of the Attestation Process are. In most cases, it will be just one reviewer, but there are use cases where the reviewer definition could result in a set of reviewers.
For each reviewer found, the process would create an Attestation Task, and set its associated Attestation Date. If the reviewer happens to be invalid, the process will add 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 either disabled or deleted, or if the user has a proxy set up that is currently active. It also computes a list of reviewers with no email address defined.
For each valid reviewer, the process will calculate 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 will retrieve only those resources that are marked as being financially significant. The process would then add a reference and any related information regarding those user entitlements to the Attestation Data of the task. It will also take the number of entitlements covered by that task, and add that to the statistical field for "Total Number of Entitlements identified for Attestation" in the Process Instance. The process would then send an email to the Reviewer.
After going through each reviewer, the process would check to see if there were any invalid reviewers. If there were, then the list of invalid reviewers will be emailed to the process owner. It also sends email to process owners about the reviewers with no email address defined.
After this stage, all the attestation tasks will be in the attestation inboxes of the reviewers.
When an Attestation Task is assigned to a reviewer, they will receive an email, and the task will show up in their Attestation Inbox. The reviewer would then go to their Attestation Inbox and look at the task details.
From the task details page, the reviewer would provide a response (optionally, with a comment) for each entitlement. This would also mark that attestation entitlement detail (within the task) as "Response Provided".
In case the reviewer's response to any of the entitlements was to "Delegate", then the reviewer would be taken through additional steps of providing the user to delegate the attestation activity to for those specific entitlements. Optionally, the reviewer could provide comments regarding why they are delegating the attestation activity to that user.
Once the reviewer has provided responses to all entitlements, they will be allowed to submit their action (commit) 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.
First, the Attestation Task would be marked as ÒSubmittedÓ. At this point the attestation task is frozen, and cannot be acted on any further. Then, for each user entitlement in the attestation task, the response provided will be examined.
If the response was either to certify or reject, then the provisioned resource instance (corresponding to that entitlement) will be updated with this fact. At the provisioned resource instance level, the last attestation result, the time at which last attestation occurred, and who the reviewer was, will be recorded. So if the response was to decline or delegate, then the attestation detail at the provisioned resource level will not be changed.
Irrespective of the response, either the ÒUser Attestation Event OccurredÓ or ÒResource Attestation Event OccurredÓ task (depending on the attestation process type) will be inserted into the provisioning process of the resource instance. This would kick off any kind of attestation driven workflows that the customer may have defined. Any comment provided will be saved to the task's notes field.
The attestation entitlement detail (within the task) will be marked as ÒResponse SubmittedÓ.
Figure A-3 Flow of Events After Attestation Task Response is Submitted
Irrespective of the response, the appropriate statistics will be updated on the Process Instance. The statistics being updated would be:
Number of Entitlements certified
Number of Entitlements rejected
Number of Entitlements declined
Number of Entitlements delegated
Once all entitlements are covered, a sub-flow for follow-up action will be initiated. In this flow, the process will examine if the response for any of the entitlements in the task was ÒdeclinedÓ. If there were any such entitlements, then the process will create an email to send to the Process Owner outlining the details of the refusal.
Next, the process will examine if the response for any of the entitlements in the task was ÒdelegatedÓ. If there were any such entitlements, then the process will identify all users the reviewer selected as a delegate, and create an Attestation Task for each. Each Attestation Task will be for just those entitlements that the reviewer delegated to the user. The delegated user will receive an email notifying them of the delegation.
Once 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 will be marked as ÒCompleteÓ.
The Attestation Engine is the engine that implements the Attestation Lifecycle Process. It will be 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). Thus it supports both drivers for initiation of Attestation Processes.The attestation engine will make use of messaging to off-line processing in the appropriate places, thereby creating transaction separation, and ensuring that there are no end-user performance issues.
There will be a new system scheduled task that will be 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/her.
| 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/her.
| 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 |
<Attestation Task.Delegated By User Id> has delegated to you an attestation task from attestation process <Attestation Definition.Process Name>
The attestation task details are as follows
The template 'Invalid Attestation Reviewers' 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.
| 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 |
Some of the reviewers are invalid for the attestation process <Attestation Definition.Process Name>, request <Attestation Request.Request Id>
The following attestation process generated some invalid reviewers.
The Notify Declined Attestation Entitlements template is used to build the email to send to process owners notifying them of any declined entitlement attestations.
| 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 |
User access rights in attestation request <Attestation Request.Request Id> have been declined by <Attestation Task.Reviewer User Id>
Attestation of the following user access rights were declined by the reviewer.
The template 'Attestation Reviewers With No Email Defined' is used to build the email to send to process owners notifying them of any reviewers where there is no email address defined
| 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 |
Email address is not defined for some of the reviewers in attestation process <Attestation Definition.Process Name>, request <Attestation Request.Request Id>
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.
