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:
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.
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:
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.