Customizable User Interface
(1) (2) The entire Hitachi ID Identity Manager user interface is customizable and translatable. This includes graphical changes, text changes, layout changes, language translations, etc. No user interface elements are hard-coded into Identity Manager.
User interface customization is simple to implement. Common elements, such as page layout and HTML preambles, are factored out into standard macros using an open source macro language (M4). Modifications made to M4 macros are propagated across the entire user interface.
Note that M4 (at least as it is used in Identity Manager) is really just 3 keywords: include, define and ifelse. It is not something that administrators really have to learn. Rather, the complexity is in the information architecture (what elements are defined where). To customize the Identity Manager UI, all that is needed is an understanding of HTML and CSS, plus a bit of patience to find the right macro to edit -- so that a change will propagate to the entire UI.
UI customizations are defined separately from the core UI, using a macro override scheme. This allows most customizations to survive Identity Manager version upgrades with minimal intervention. For example, customers may define a new markup for HTML tables. This markup is placed in an override file and takes precedence over the default HTML table code. When Identity Manager is upgraded, the customized markup will continue to take precedence over default HTML code.
In addition to modifying HTML and CSS code, customers can change the values of a number of system variables which alter Identity Manager behavior. For example, password policy, intruder lockout frequency and duration, non-password authentication rules and more can all be adjusted from the Identity Manager administrative web UI. System variables also survive version upgrades.
Identity Manager behavioral modifications are made using plug-in points, rather than (as is common with many other applications) by modifying the JSP or ASP source code of Identity Manager itself.
Plug-ins are scripts or executables installed on the Identity Manager server. Identity Manager components call plug-in programs to make business policy decisions or to look-up information. Examples include:
- Look up a user's known, existing login accounts.
- Helpful for integration with an existing meta directory.
- Plug-ins are provided for LDAP directories and SQL databases.
- Look up a user's security questions.
- Can be used to leverage existing authentication data.
- Plug-ins are provided for LDAP and SQL implementations.
- Assign a new login ID to a newly created user.
- A sample script is provided that implements popular ID schemes.
- Validate form inputs for workflow requests.
- Is normally used to validate form inputs, such as checking that a new hire's home address has mutually-consistent city, state and area code fields.
- Can also populate hidden fields (e.g., directory OU) and assign IDs (e.g., e-mail address) based on business policy.
- Assign appropriate authorizers to workflow requests.
- May be based on the requester, recipient, entitlements or operations involved.
- Global authorization logic is easier to manage than assigning static authorizers to every conceivable kind of request.
- Escalate from non-responsive authorizers to alternates.
- A default implementation is provided, to escalate to the previous authorizer's manager.
This architecture, which encapsulates business logic into stand-alone scripts or executables, has two important benefits:
- It is significantly easier for organizations to adjust Identity Manager behavior, since all such modifications are made in simple, self-contained files.
- Business logic implemented in this way survives Identity Manager version upgrades, reducing the cost and delay associated with major upgrades.