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