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 through a self-service web portal, by business logic implementing automated user (de)provisioning or through the Identity Manager SOAP API.
By default, all requests require authorization -- but business logic may override this and auto-approve requests.
Authorizers are selected automatically and may be chosen using OrgChart data (i.e,. managers of the requester or recipient), using resource owner data or through other means, such as lookups in an external database or directory.
Each group of authorizers consists of some N>=1 authorizers. Some number M<=N of the authorizers in each group must approve a request before it will be fulfilled by Identity Manager.
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 who is being asked to complete a task, most commonly change authorization.
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.