Skip to main content

Roles and Rules - Hitachi ID Identity Manager

(1) Hitachi ID Identity Manager can create login accounts using templates and roles:

  • Rather than requiring an administrator to provide every parameter when creating a new account on a target system, Identity Manager can copy all relevant parameters from a template account. In effect, Identity Manager implements a "clone user" operation.

  • Note that not every user object on every target system can or should be cloned. Requiring Hitachi ID Systems customer administrators to name the accounts which should be available as templates ensures that users whose profiles have accumulated excess entitlements over time are not cloned.

  • Change requests, automated processes or updates initiated by administrators may specify attributes that override those copied from the template. For example, a new account may be created by copying a model account but overriding the employee number, phone number, e-mail address, login ID, directory OU, home directory server, mail server, etc.

  • Attributes may be entered by a user or administrator (e.g., phone number), may be validated by a plug-in that implements business logic (e.g., building code) or may be assigned by a plug-in that implements business logic (e.g., login ID, directory OU, e-mail address). Plug-ins embody business rules and may be as simple or as complex as required.

  • Template accounts and membership in security groups can be collected into named sets called roles. This allows requests to specify whole sets of entitlements, rather than individual accounts and groups, should be granted or revoked. This simplifies the UI for business users, who may not have a clear, technically accurate idea of what entitlements to ask for.

  • Roles may be functional -- i.e., encapsulating all the entitlements needed by a given class of user.

  • Roles may also be application-oriented -- i.e., encapsulating a commonly used set of entitlements within one or more applications.

  • Functional roles are appropriate for large groups of users with identical business responsibilities.

  • Functional roles are also an excellent baseline for all users. For example, a functional role may be defined for "basic network and e-mail access."

  • Application-oriented or technical roles are appropriate for users whose requirements are relatively unique.

  • Roles can be nested, to simplify definition of complex sets of entitlements. For example, functional roles can and typically should be composed of application roles, which in turn encapsulate fine-grained entitlements on target systems.

  • Change requests may include adding or removing roles, adding or removing accounts, adding or removing group memberships and updating profile attributes.

(2) Identity Manager does not require that users be classified into roles.

Identity Manager can be configured to compare users' actual security entitlements on target systems to the entitlements that their assigned roles predict and to automatically make adjustments to bring users into compliance. This process is called RBAC enforcement.

RBAC enforcement is not a mandatory component of Identity Manager and indeed the scope of enforcement can be controlled at multiple levels:

  1. Users can be enabled/disabled for enforcement.
  2. Roles can be enabled/disabled for enforcement.
  3. Entitlements (i.e., accounts on target systems and security groups whose membership is managed by Identity Manager can be enabled/disabled for enforcement).
  4. The number of users whose profiles are subjected to enforcement per day can be capped.

These mechanisms allow Hitachi ID Systems customers to use RBAC enforcement -- or not -- based on the appropriateness of this mechanism to their environment. In general, we have found that RBAC enforcement is manageable for large numbers of users with identical needs (e.g., point of sale, retail, etc.) and to small numbers of high-risk users (e.g., finance/budget) but not usually cost-effective for other, unique, back-office user populations.

Attributes can be attached to templates, groups and roles in Identity Manager, to make them easier to find. For example, these resources can be classified by type and location and automatically assigned, filtered on search results, etc. accordingly.

In order to ensure that the numbers of templates and roles are manageable, Identity Manager supports request attributes, which override the detailed attributes of templates and roles.

Request attributes may be entered by users and are in general validated and filled out by plug-in programs, written to implement Hitachi ID Systems customer-specific business logic. These plug-in programs can be thought of as implementing rules.

The combination of roles and rules can be best explained using an example:

  • A manager hires a new employee and uses Identity Manager to request systems access.

  • The request includes:
    • Identity attributes, including the new employee's name, department code, job code, employee number, telephone number and office address.
    • A role, specifying basic network and e-mail access.
    • An additional template account, specifying a particular type of access in an engineering application.
    • An initial password.

  • A plug-in program uses business rules to assign a globally-unique, standards-compliant login ID to the new employee.

  • Another plug-in program uses business rules to validate that the department code, job code, employee number and telephone number are all appropriately formatted and mutually consistent. It also assigns:
    • A directory OU based on the department code
    • A file server name based on the building and floor components of the office address
    • A mail server name based on the same parameters

  • A final plug-in program is run, applying further business rules to identify appropriate authorizers for the request. For example, the plug-in can use reporting lines in an HR application to find a sufficiently empowered manager that the first manager reports to.

  • Identity Manager workflow then follows the request through an approval process -- e-mail invitations and authenticated, secure web replies.

  • Once approved, the request is passed to connector programs, which create login accounts on applications and directories, set up a home directory with appropriate privileges and initial content to the new user, set up a mail directory, etc.

  • When all of the operations in a request have been completed, a confirmation e-mail and a welcome e-mail are sent to the manager, to forward to the new employee.
page top page top