Skip to main content

Custom Business Logic - Hitachi ID Identity Manager

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:

  1. Limiting which users can make change requests at all.
  2. 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?).
  3. 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).
  4. Limiting the operations that a given requester can initiate (e.g., create a new user, terminate existing accounts, modify attributes or group memberships, etc.).
  5. 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.
  6. Auto-setting user profile attributes -- for example login IDs, e-mail addresses, file- and mail-server locations and directory OUs.
  7. 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 intact:

  1. Integrations may use either already-installed or new connectors and their configuration moves forward.
  2. Forms, UI settings, data flows, batch processes, scheduled reports and so on migrate to the new system.
  3. User data, such as request history and profile information is normally either retained or migrated to the new system.

In the event that a customer had received customizations 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.

All UI customization (HTML, CSS, JS, images), customer-specific business logic (policy rules, authorizer routing, data filters, etc.) and language text are kept in files separate from the core product. These files either survive an in-place patch upgrade or are copied to the new instance.

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 (compare to ASP or JSP applications, where customizations are intermingled with core product code).
page top page top