Skip to main content

Reliable Authorization - Hitachi ID Identity Manager

Authorization Overview

A single flow-chart (state diagram) is used to authorize all requests in the Hitachi ID Identity Manager workflow engine. The Identity Manager workflow engine supports:

  • Parallel change authorization.
  • Multiple groups of multiple authorizers.
  • Automatic reminders to unresponsive authorizers.
  • Automatic escalation, when authorizers continue to be unresponsive.
  • Delegation -- for example, when authorizers take extended leaves of absence.
  • Authorizers with veto power over some or all of a request.

Selecting the Right Authorizers

Requests may be submitted to the Identity Manager workflow engine using the included request web portal, by business logic monitoring changes in a system of record (SoR), via a batch loader or through the inbound web services API.

Any request may require approval. Business logic selects authorizers and determines how many are required (possibly zero). Multiple authorizers may be selected, with some level of consensus required (e.g., N of M).

Authorizers are selected automatically and may be chosen by their relationship to the requester and/or recipient. For example, the recipient's manager, or a department head, or a regional security officer are common authorizer choices. Authorizers may be based on what was requested, such as the owner of an application or group. Finally, authorizers may be selected via lookup into an external service or database.

Reminders, Escalation and Delegation

Workflow is used in Identity Manager to approve change requests, to implement approved requests, to certify user access and more. A participant in the workflow process is a person invited to complete a task.

The Identity Manager workflow engine has built-in support for automatic reminders, escalation and delegation, so as to elicit reliable responses from individually-unreliable users:

  • When participants are first chosen, their out-of-office status on their primary e-mail system may be checked, to trigger early escalation to an alternate participant.
  • Non-responsive participants that have been asked to review a request receive automatic reminders. The reminder interval is configurable.
  • Participants who remain non-responsive (too many reminders) are automatically replaced with alternate participants, identified using escalation business logic. Escalation is most often based on OrgChart data -- i.e., the original authorizer's direct manager is often the escalated authorizer.
  • Participants can pro-actively delegate their authority, temporarily or permanently. Delegation may trigger its own approval -- asking the new participant to accept a new responsibility.
  • A workflow manager can reassign participants attached to open requests, for instance when they are terminated or when a request is urgent and already-assigned participants are not available.

Parallel Approvals by Default

Identity Manager supports both parallel and serial change authorization, but Hitachi ID Systems encourages all of its customers to use parallel authorization.

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

The difference between parallel and serial authorization is that parallel authorization favors efficient SLA, while serial authorization shields subsequent authorizers from the occasional, inappropriate request that an earlier authorizer would reject. In Hitachi ID Systems experience, users are aware that their requests will be highly visible and almost never make requests that are unlikely to be approved. Consequently, the number of inappropriate requests is close to zero in practice and there is no real business advantage to shielding later authorizers from spurious requests. As a consequence, the advantages of parallel authorization -- improved SLA and reduced process complexity -- are the deciding factor.

page top page top