Reliable Authorization
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 through a self-service web UI, 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.
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
The Identity Manager workflow engine has built-in support for automatic reminders, escalation and delegation:
- When participants are first chosen, their out-of-office status on their primary e-mail system may be checked, to trigger early escalation.
- Non-responsive participants that have been asked to review a request receive automatic reminders. The reminder interval is configurable.
- Participants who remain non-responsive 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 authorizer to accept responsibility.
- A workflow manager can reassign the participants attached to open requests, for instance when they are terminated or when a request is urgent and the authorizer is unavailable.
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 (Service Level Agreement), while serial authorization shields subsequent authorizers from the occasional, spurious 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 spurious 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 advantage of parallel authorization -- improved SLA and reduced process complexity -- are the deciding factor.
The bottom line is that parallel authorization offers better SLA to Hitachi ID Systems customer and is simpler to configure and maintain. It is therefore preferable.