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:

Built-in policies:

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

  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 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:

  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 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.