Rationale for standardized IAM implementations
Hitachi ID Systems offers multiple editions of Hitachi ID Identity Express -- each of which is a reference implementation of the Hitachi ID Identity and Access Management Suite for a specific type of organization and feature set.
The objective of Identity Express is to minimize the time, cost and risk of identity and access management (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 recommends discarding old, inefficient processes, adopting best practices and implementing a full set of IAM processes in just a few days. Identity Express can reduce the total cost of IAM system deployment by 80% to 90%.
Identity Express does not limit the functionality deployed by organizations. Rather, an organization starts with Identity Express to achieve positive results quickly and then prioritizes what product features and integrations, which may not yet be incorporated into Identity Express configuration, to deploy next.
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, each edition of Identity Express applies to a class of organizations, which have near-identical requirements and would benefit from a shared implementation.
Hitachi ID has identified a number of such patterns, including:
- Workforce IAM 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 Hitachi ID 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 Identity Manager administration web portal.
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. For example, they might differ in IAM for a workforce as compared to IAM for partners or for students in a college. Policies where the strategy varies between different deployment styles 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 publishes pre-built components. Multiple components often perform the same function, but using different approaches, so the appropriate component must be chosen for a given deployment. 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 workforce IAM 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.