Selecting the Right Authorizers

Requests may be submitted to the Hitachi ID Identity Manager workflow engine using the included request web portal, by an automated process that monitors a system of record for changes, via a batch loader or through the inbound web services API.

Any request may require approval. Any operation on any managed resource (account/target system, group membership, role assignment) may have one or more authorizers assigned. These resource-linked authorizers are normally augmented by organizationally-linked authorizers, selected via business logic. This logic specifies how many approvers are required (possibly zero), who they are, etc.

A rules table is normally used to select participants for a workflow request. The request is compared to a series of rules and where a rule matches, participants, such as authorizers, are assigned, typically using a user class that relates the new participant to the requester or recipient. Rule matching may be based on the form that was used, the membership of the requester or recipient in a group, the type of operation requested, the initial or end-state risk score for the recipient, the entitlement(s) involved, etc.

Soliciting prompt, reliable action

The Identity Manager workflow engine is designed to get quick and reliable feedback from groups of business users, who may be individually unreliable. This is accomplished with:

  • Where multiple authorizers are required, they are all invited at the same time. This leads to better response times than inviting each authorizer only after the previous one has approved a request.
  • Approval by N of M authorizers. For example, many scenarios require approval by HR -- and the usual rule is to allow any one of three HR staff to approve a request.
  • Random selection of authorizers from large groups. Continuing with the HR example, there may be more than 3 people in the HR department, so a random sample is chosen for each request.
  • Automatic reminders to non-responsive authorizers, by default every four hours after the first invitation to review a request.
  • Escalation from non-responsive authorizers to their alternates. By default, escalation happens in place of the fourth reminder, and is to the original authorizer's manager.
  • A UI that allows users to delegate their approval authority to someone else for a period of time, such as a vacation.
  • Organizations are encouraged to deploy a cloud-hosted proxy system and the Hitachi ID Mobile Access app on user phones. This allows authorizers to approve or reject requests from their mobile phone -- from any location, at any time, without a VPN.
  • Identity Manager can also be configured to check a user's out-of-office status or away message on e-mail systems such as Microsoft Exchange, and to pre-emptively escalate requests to other users if the user has indicated that they are out of the office.

Parallel Approvals by Default

The workflow system in Identity Manager can invite participants in parallel (all at once) or sequentially (one or a few at a time). Hitachi ID Systems encourages customers to use parallel invitations.

With either parallel and serial authorization, every relevant authorizer must approve a change before it is implemented. As a result, there is no security consequence to the choice of one method over the other.

Parallel authorization favors efficient SLA, while serial authorization shields later authorizers from the occasional, inappropriate request that an earlier authorizer would have blocked. In Hitachi ID Systems experience, users are aware that their requests will be highly visible and rarely make inappropriate requests. Consequently, almost all requests are approved, so the volume of requests that are blocked by earlier authorizers in a sequential process is very low. The advantages of parallel authorization -- improved SLA and reduced process complexity -- outweigh the advantages of serial authorization.