Rationale for standardized IAM implementations
Hitachi ID Systems offers a series of reference implementations of Hitachi ID Identity Manager, branded as Hitachi ID Identity Express to its customers and partners.
The objective of a reference implementation is to minimize the time, cost and risk associated with IAM system deployment. Instead of spending months with consultants to document existing processes, adjust them and then implement automation on a "clean slate" system, Hitachi ID Systems recommends discarding old, inefficient processes, adopting best practices and implementing a full set of IAM processes in just a few days. Reference implementations can reduce the total cost of initial IAM deployment by 80% to 90%.
Types of reference implementations
The idea of a reference implementation is not to suggest that every IAM deployment can be the same. That's one end of a spectrum -- 100% standardized. The other end of the spectrum -- 100% custom, is also unnecessary. Instead, reference implementations apply to classes of organizations, which have near-identical requirements and would benefit from a shared implementation.
Hitachi ID Systems has identified a number of such patterns, including:
- Corporate-style IAM (Corp) to manage the access of employees and contractors.
- Partner portal IAM (B2B), to delegate administration of users to administrators in each organization.
- Higher education IAM, to manage the access of students, faculty, staff and alumni.
- Healthcare delivery IAM, to manage the access of doctors, nurses, clinicians, support and administrative staff in hospitals.
- Password management, for most organizations.
- Privileged access management, also for most organizations.
Doubtless there are other patterns, but the above set are an excellent start and fit the needs of most organizations.
Business advantages of adopting Identity Express
Replacing legacy IAM processes with Identity Express has the following advantages over custom IAM implementations:
- Optimized IAM processes: The business processes codified
in Identity Express have been optimized for fast service and
robust internal controls, improving on the legacy processes in
- Complete functionality: When implementing a custom IAM
system, organizations can only automate one or two processes at a time.
Most start with onboarding, deactivation or access reviews and
only later automate transfers, leaves of absence, name changes,
rehire detection, etc. In contrast, Identity Express allows organizations
to automate a comprehensive set of identity lifecycle processes
- Efficient implementation: By adopting a pre-configured set of processes and policies, organizations minimize deployment risk, reduce implementation cost and shorten time to value.
Components and policy tables to customize IAM processes
Real-world Identity Manager deployments must enforce policies that are specific to each organization. It is important to implement such policies in a manner that does not require product customization, as that would make it difficult to patch or upgrade the system. It is also desirable to avoid writing custom (or any) code, as a typical IAM administrator is more skilled in integrations and process definition than programming.
Identity Manager combines two approaches to policy definition, to meet these objectives:
Some kinds of policies are applicable to all deployments, so are built into Identity Manager.
- For example, segregation of duties policies specify toxic combinations of entitlements that no user should be assigned -- with the detail being which entitlements should be collected into SoD rules.
- Another example is privacy controls, which determine what data about one user another user is allowed to see and/or edit. The need for this is universal, but the linkage between sets of identity attributes and types of requester/recipient relationships is specific to each implementation.
All such built-in policies are configured using the web-based Identity Manager management UI.
Policies implemented as components and configured with rules tables:
Other types of policies have more variability, in the sense that how they are computed varies from one style of deployment to another. Policies where the strategy varies between different deployments include:
- Setting default values for request attributes.
- Validating user-entered form inputs.
- Computing request attributes.
- Routing requests to appropriate authorizers and implementers.
- Identifying dependencies between entitlements and either blocking requests where they are not met or automatically adding missing items to requests.
- Automatically adding operations to requests, for example moving an account to a different OU or a mail folder to a different server as a consequence of a location change.
- Computing access risk and adjusting processes as a consequence.
For the latter type of policies, Hitachi ID Systems publishes pre-built components. Multiple components often perform the same function, but using different approaches, so the appropriate component must be chosen for each Identity Manager implementation. For example, selecting authorizers in a Identity Manager deployment is quite different than selecting authorizers in a Hitachi ID Privileged Access Manager deployment; controlling access to user profiles in a B2B partner profile is quite different than the same function in a corporate (employee and contractor facing) implementation.
Policy components are configured by editing a rules table using the web-based Identity Manager management UI.
In most cases, it is sufficient to select a suitable component and
edit its rules table -- no programming is required. In a few cases,
where extra flexibility is required, the rules table supports expressions
and call-back functions, either of which can be used to insert short
bits of Python script code.