Group lifecycle management

Hitachi ID Identity Manager supports full lifecycle management of group objects, including:

  1. Discovering all group objects on all target systems.
  2. Capturing and updating metadata about groups -- risk scores, business unit, owner, etc.
  3. Requests to create, move, modify or delete groups across multiple target systems.
  4. Automatically calculating the membership of selected groups.
  5. Requests for group membership, including:
    1. Filtered search of available groups when requesting membership for a user.
    2. Filtered search of available users when initiating a change from selected groups.
    3. The ability to compare user profiles and copy some group memberships from a model to a recipient user.
    4. Recommended groups, based on popularity amongst a user's peers.
  6. Controls over group membership, including maximum size, white lists and black lists.

Group membership management

Identity Manager can manage membership in existing groups and automatically detects new groups, which can subsequently be enabled (manually or automatically) for Identity Manager management.

Group membership management can be driven by multiple processes, including:

  • Calculated membership (typically based on identity attributes);
  • Self-service and delegated requests, with or without approval;
  • Access certification (event-triggered and scheduled);
  • Role based assignment (assign roles, automatically assign/revoke groups in those roles);
  • Segregation of duties policy (between groups, roles, accounts);
  • Out-of-band change detection (followed by alert or undo);
  • Reporting (ad-hoc and scheduled).

Requests for group membership are often difficult for users to articulate. Users want to access a "thing" -- a share, folder, application or screen and may not understand that this access right is linked to a group, or what group is needed.

There are several approaches to helping requesters formulate suitable access requests:

  1. Automation: to the extent possible, automatically assign access rights to users based on available identity attributes and a role model, eliminating the need to submit or approve requests.

  2. Search: help requesters find suitable entitlements by searching on name, description or other metadata.

  3. Filter: limit available entitlements to only those that make sense for a given requester and recipient. Search is easier to use if the set of possible options is as small as possible.

  4. Intercept: wait for users to attempt access (which they are not yet entitled to). Intercept "access denied" error messages and help the user navigate directly from the initial error dialog to an appropriate access request page.

  5. Selective copy: show requesters the differences between an existing user (who has a desired entitlement) and another user (who does not have it yet, but needs it). This is a variant of search where the requester knows who can do something and will be able to select the appropriate entitlement from the short list of differences between a reference user and a recipient.

  6. Recommend: users have peer groups -- i.e., other users who perform similar functions. The Identity and access management (IAM) system can show a requester entitlements that are popular among the peer group of a given user, but that the user in question does not (yet) have. The desired entitlement is very likely in this list.

Group membership changes can also be formulated from the perspective of either users or groups. i.e., "add these users to this group" or "add these groups to this user."


Select groups and apply changes

Groups hierarchy

On systems such as Active Directory or LDAP, groups can contain other groups as members -- i.e., there is a hierarchy of nested groups.

Identity Manager has a correct internal model of nested groups and will automatically discover parent/child relationships between groups. It includes extensive support for managing and applying policies to nested groups:

  1. Requests to change group membership can include requests to add or remove child groups as members in parent groups.
  2. When calculating whether a user qualifies for membership in a user class, if the test is that matching users belong to group A, if (parent) group A includes (child) group B among its members and a user is a member of group B, then the user is considered to be a member of the user class. This works for any depth of nesting.
  3. When evaluating segregation of duties policies, if two groups A and B are mutually exclusive, then users are considered to be in violation if they are members of either group, or of any child groups of A or B, since by being made members of a child group, the user is implicitly a member of A or B.
  4. When performing access certification of group memberships, the reviewer can remove child groups from the parent group being certified.
  5. When requesting membership in a group, a requester can navigate to child groups, rather than requesting membership in the parent. Note that policy can make the parent non-requestable, forcing the requester to navigate down.
  6. When displaying information about a group, its parent and child groups, as well as member accounts and owners, are shown.