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. Resource-linked authorizers are normally augmented by organizationally-linked authorizers. This logic specifies how many approvers are required (possibly zero) and who they are.

A rules table is used to select participants for a workflow request. The request is compared to a series of rules and where a rule matches, authorizers are assigned, typically via a user class that relates authorizers 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 participants are required, they should all be invited at the same time. This leads to better response times than inviting each participant only after the previous one completed their task.
  • Where the task is to approve a request, allow N of M participants to do the job. For example, many scenarios require approval by HR -- and a good rule is to allow any one of three HR staff to approve a request.
  • Random selection of participants from larger 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 participants, by default every few hours after the first invitation.
  • Escalation from non-responsive participants to their alternates. For example, after sending three reminders to a participant, escalate the request to their manager.

  • A UI that allows users to delegate their responsibilities to someone else for a period of time, for example during a planned 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 Office 365 and to pre-emptively escalate requests to other users if the original participants 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 Service Level Agreement (SLA) , while serial authorization shields later authorizers from the occasional, inappropriate request that an earlier authorizer would have blocked. In Hitachi ID 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.