Planning for a Periodic Access Review

An access review can be a labor- and time-intensive process for any business enterprise. The Identity Manager periodic access review process helps minimize the cost and time involved by automating many parts of the process. However, some of the processes still are time-consuming. For example, the process of fetching user account data from a number of locations for thousands of users can take a considerable amount of time. The act of manually attesting records can be time-consuming as well. Proper planning improves the efficiency of the process and greatly reduces the effort involved.

Planning for a periodic access review involves the following considerations:

• Scan times can vary greatly depending on the number of users and the resources involved.

  A single periodic access review for a large organization can take one or more days for scanning, as well as one or more weeks for manual attestation to complete.

  For example, for an organization with 50,000 users and ten resources, an access scan might take approximately one day to complete, based on the following calculation:

  1 sec/resource * 50K users * 10 resources / 5 concurrent threads = 28 hours

  If resources are spread across geographies, network latencies can add to the process time.

• Using multiple Identity Manager servers for parallel processing can speed up the access review process.

  Running parallel scans is most effective when the resources are not common across the scans. When defining an access review, create multiple scans and restrict resources to a specific set of resources, using different resources for each scan. Then when you launch the task, select multiple scans and schedule them to run immediately.

• Customizing the Attestation workflow and rules gives you greater control and can provide greater efficiency:

  For example, customize the Attestor rule to spread attestation duties across multiple attestors. The attestation process assigns work items and sends out notifications accordingly.

• Using Attestor Escalation Rules helps improve response time for attestation requests.

  Set the Default Escalation Attestor rule, or use a customized rule, to set up an escalation chain of attestors. Also specify escalation timeout values.

• Understand how to use the Review Determination Rules to save time by automatically determining which entitlement records need to be manually reviewed.

• Bundle notification of attestation requests for a scan by specifying a scan-level Notification Workflow.

Tuning Scan Tasks

During the scan process, multiple threads access the user’s view, potentially accessing resources on which the user has accounts. After the view is accessed, multiple audit policies and rules are evaluated, which may result in the creation of compliance violations.

To prevent two threads from updating the same user view at the same time, the process establishes an in-memory lock on the user name. If this lock cannot be established in (by default) 5 seconds, then an error is written to the scan task and the user is skipped, thus providing protection for concurrent scans that are processing the same set of users.

You can edit the values of several “tunable parameters” that are provided as task arguments to the scan task:

• clearUserLocks (Boolean). If true, then all current user locks are freed before the scan starts.

• userLock (integer). Time (in milliseconds) to wait when trying to lock a user. The default value is 5 seconds. A negative value disables locking for that scan.

• scanDelay (integer). Time (in milliseconds) to sleep between dispatching scan threads. The default value is 0 (no delay). If you provide a value for this argument, then the scan is slower, but the system is more responsive to other operations.

• maxThreads (integer). Number of concurrent threads used to process a scan. The default value is 5. If resources are very slow to respond, increasing this number may increase scan throughput.

To change the values of these parameters, edit the corresponding Task Definition form. For more information, see Chapter 3, Identity Manager Forms, in Sun Identity Manager Deployment Reference.