Hitachi ID Identity Manager includes a request portal, intended for users to accomplish a variety of functions:

  • Users can manage their own credentials -- choosing new passwords and PINs for integrated systems and applications, populating security questions, etc.
  • Self-service profile updates:
    • Making corrections to identity attributes.
    • Entering information such as home contact information.
    • Requesting organizational changes, such as transfers to a new location, department or manager.
    • Name changes.
    • Scheduling leaves of absence.
    • Scheduled deactivation.
  • Access requests for themselves or on behalf of others:
    • Group membership.
    • Role assignment.
    • Login IDs on systems or applications.
    • Access to shares, folders, SharePoint sites or other resources.
    • Onboarding (e.g., for contractors or other non-SoR users).
    • Urgent termination.
  • Group management:
    • Create new groups on target systems.
    • Modify groups (change description, owner, metadata, etc.).
    • Manipulate group membership (add/remove one or more accounts or child groups).
    • Delete no-longer-needed groups.
  • Request management:
    • Delegate authority, temporarily or permanently.
    • Approve, delegate or reject requests.
    • Withdraw previously submitted requests.
    • Monitor and manage the request queue.
  • White pages / directory search:
    • Find another user by entering their name, department, manager, etc.
    • Browse the org-chart structure.

This portal is completely policy driven. For example, what options a user gets, what other users he can find or make requests on behalf of and what identity information one user can see in another's profile is controlled by rules. Rules may be simple roles ("all users with attribute X and membership in group Y can perform action Z"). More powerful rules are based on relationships ("user A can request operation B in relation to user C if user A is in group G and users A and B are in the same department.")

Requests submitted through this portal are subject to validation logic (e.g., rules such as "is the city in the user's address consistent with the state or province?") and to approvals. Requests are routed to zero or more authorizers, where approval by some or all of the assigned users is required. The choice of authorizers is likewise policy based, via rules that match on the requester, recipient and operations.

Watch a Movie

Windows “Access Denied” dialog leading to group membership request


  • A user is guided through the access request process.
  • The video starts with the user encountering a Windows "Access Denied" error dialog.
  • The user is guided to a request to for membership in the appropriate Active Directory security group.

Key concepts:

  • Users frequently need access to new shares, folders, etc. but they don't understand access control lists (ACLs) or security groups.
  • To attain high user adoption for self-service security entitlement management, it is important to implement a system which allows for this gap in users' knowledge.