The Hitachi ID Identity Manager workflow engine externalizes business logic into plugin
programs, which are typically implemented as short scripts responsible
for very specific functions. Business logic is typically written in
Python but any language can actually be used.
Examples of workflow business logic include:
- Limiting which users can make change requests at all.
- Limiting which user profiles a given requester can see (e.g.,
a manager can see his subordinates, but should the subordinates
be able to see the manager's profile?).
- Limiting the resources that a given requester can make changes to
(e.g., some users may be able to change their LDAP profile, but
perhaps not their mainframe or ERP access rights).
- Limiting the operations that a given requester can initiate (e.g.,
create a new user, terminate existing accounts, modify attributes
or group memberships, etc.).
- Validating user profile attributes entered through the request portal -- for
example, ensuring that things like department codes are legitimate,
and that the value of one form input is consistent with another.
- Auto-setting user profile attributes -- for example login IDs,
e-mail addresses, file- and mail-server locations and directory OUs.
- Routing completed requests to appropriate authorizers, such as a
requester's manager, resource owners, etc.
Custom Logic Survives Version Upgrades
When upgrading Identity Manager to a new version, whether this is done by
patching an existing application instance or migrating configuration
and operational data to a new instance, the bulk of the system remains
- Integrations may use either already-installed or new connectors and
their configuration moves forward.
- Forms, UI settings, data flows, batch processes, scheduled reports
and so on migrate to the new system.
- User data, such as request history and profile information is normally
either retained or migrated to the new system.
Most deployments also include components, which implement policies
using a combination of scripts invoked by plug-in programs and
policy tables. The components are considered part of the
core product and are upgraded when the core product is upgraded.
This upgrade includes migrating old policy rules to the new component.
All UI customization (HTML, CSS, JS, images) and language text are
implemented in files kept in a separate folder hierarchy from the
equivalent files used by the default UI. These files override segments
of the default UI -- e.g., snippets of CSS or HTML that replace
equivalent CSS or HTML snippets in the default UI. These override
files are copied from the old version to the newer version at the time
A strict separation between core product capabilities and customer
modifications has two important benefits:
- Customizations are safe, in the sense that they cannot break core
product capabilities or logic.
- Customizations survive upgrades, since they are clearly separated
from the core product.
In rare cases where a customer has received customizations or patches to
the core Identity Manager executables or SQL stored procedures and if those
changes have not yet been merged into a generally available release,
then Hitachi ID Systems provides a new build with the same patches included.
Such changes are tracked in a Hitachi ID Systems revision control system that
holds any customer-specific source code changes.
- 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.