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
- 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
- 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 an automated process that monitors
a system of record for changes, via a batch loader or through the inbound
web services API.
Any request may require approval. Any operation on any managed
resource (account/target system, group membership, role assignment)
may have one or more authorizers assigned. These resource-linked
authorizers are normally augmented by organizationally-linked
authorizers, selected via business logic. This logic specifies
how many approvers are required (possibly zero), who they are, etc.
A rules table is normally used to select participants for a workflow
request. The request is compared to a series of rules and where
a rule matches, participants, such as authorizers, are assigned,
typically using a user class that relates the new participant to
the requester or recipient. Rule matching may be based on the
form that was used, the membership of the requester or recipient in
a group, the type of operation requested, the initial or end-state
risk score for the recipient, the entitlement(s) involved, etc.
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
- 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
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 deny. 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 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.
- Network architecture:
Identity Manager network architecture.
- Replicated, High Performance Database Architecture:
Identity Manager includes built-in data replication and uses stored procedures to ensure optimized transaction processing.
- Included Connectors:
Connectors included in Identity Manager and their capabilities.
- Auto-Discovery System:
How the Identity Manager automatically discovers new, deleted and changed users on integrated systems and applications.
- Reconciling User IDs:
How Identity Manager maps user IDs on different systems back to their human users, both automatically and with human assistance.
Integrations between Identity Manager and other parts of an IT infrastructure.
- Custom Business Logic:
How organizations can implement their own business logic without modifying the core Identity Manager product or impairing system reliability or upgradeability.
- Dynamic Workflow:
How Identity Manager invites business users to review and approve changes to user profiles.
- Reliable Authorization:
Using parallel invitations, reminders, escalation and delegation to get reliable results from human authorizers.
- Roles & Rules:
Using roles and rules to simplify the management of user provisioning policies.
- Self-service Group Management:
Using the included Group Manager module to move AD group management to a self-service model.
- Event Notification:
Identity Manager can alert people and other systems of changes that it detects on target systems and of events that took place within identity management and access governance business processes.
- Server Requirements:
How to configure Identity Manager servers and how many are required.
- Customizable User Interface:
How the Identity Manager user interface can be branded, rearranged and adapted to specific customer requirements.
- Language Support:
Languages in which Identity Manager can display its user interface.