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 Bravura Security Fabric 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:

  1. Workforce IAM to manage the access of employees and contractors.
  2. Partner portal IAM (B2B), to delegate administration of users to administrators in each organization.
  3. Higher education IAM, to manage the access of students, faculty, staff and alumni.
  4. Healthcare delivery IAM, to manage the access of doctors, nurses, clinicians, support and administrative staff in hospitals.
  5. Password management, for most organizations.
  6. Privileged access management, also for most organizations.

Doubtless there are other patterns, but the above set is an excellent start and fits 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 most organizations.

  • 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 up front.

  • 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 Bravura Identity 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.

Bravura Identity combines two approaches to policy definition, to meet these objectives:

Built-in policies:

Some kinds of policies are applicable to all deployments, so are built into Bravura Identity.

  1. 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.
  2. 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 Bravura Identity 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:

  1. Setting default values for request attributes.
  2. Validating user-entered form inputs.
  3. Computing request attributes.
  4. Routing requests to appropriate authorizers and implementers.
  5. Identifying dependencies between entitlements and either blocking requests where they are not met or automatically adding missing items to requests.
  6. 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.
  7. 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 an Bravura Identity deployment is quite different than selecting authorizers in a Hitachi ID Bravura Privilege 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 Bravura Identity 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.

Components are upgradeable without human intervention. Hitachi ID ships code with each new release that reads the configuration of previous component versions and writes it to new policy tables, with adjustments made to new policy table structure if and as required.

Components are also suitable for integration with an external revision control system, such as Git. Components can be exported into JSON files and committed to a repository. They can later be imported into the same or another application instance, optionally with modifications made automatically to reflect differences between development, test and production environments.