Hitachi ID Identity Express: Workforce Edition is a reference implementation of Hitachi ID Identity Manager and Hitachi ID Password Manager, designed to automate changes to identities, entitlements and credentials of a workforce, typically consisting of employees and contractors.

Identity Express: Workforce Edition includes the following baseline integrations:

  1. A SQL database that acts as a source of record for employees.
  2. A second SQL database that provides personally identifying information about users (mother's maiden name, driver's license, SSN/SIN, etc.). Note that these two can be views into the same database if required.
  3. A single Active Directory domain.
  4. A single Exchange mail domain, with multiple mail servers.
  5. A set of filesystems where home directories are managed.

Substitutions for the above integrations are possible, at the expense of somewhat longer implementation effort.

Additions to the above integrations are almost always provided -- the above set is simply the minimum required set of integrations, without which many processes break down.

Building on these integrations, Hitachi ID Identity Express automates an extensive list of business processes, including:

  1. Onboarding new users:
    1. Based on their appearance in the system of record (HR driven for employees).
    2. Based on requests entered into the Hitachi ID Identity and Access Management Suite request portal, typically managers asking for access on behalf of new contractors and vendors.
  2. A sophisticated and secure process for setting initial passwords for new users and for "day 1" user profile activation:
    1. Newly created accounts are assigned random passwords, which are discarded by the system.
    2. New users can sign into the system from the login prompt of a Windows computer using a "password reset" UI element.
    3. New users enter their identifier (provided via message to personal e-mail or via communication to the new user's manager) and are prompted to (a) answer a series of personal questions (PII data captured during onboarding) and/or (b) enter a random PIN that was sent to their mobile phone.
    4. New users are then walked through the following enrollment process:
      1. Fill in a profile of security questions for future use (PII is only used once).
      2. Read and accept one or more corporate policy documents (acceptable use policy, HR policies, etc.).
      3. Select an initial password for the user's AD and any other accounts.
    5. The new user then shuts down the kiosk-mode web browser through which all these "day 1" activities took place and can sign into their PC normally, with their AD login ID and newly chosen password.
  3. Scheduled access deactivation, in the same manner as above, including:
    1. Advance warning to the user's manager, offering an opportunity to move the scheduled termination date.
    2. Disabling access (but not deleting anything) on the termination date.
    3. A "re-enable" request form for managers who failed to defer termination in advance, but who need to do so after the fact.
    4. Archiving, including of home directories, mail folders, moving the user to a new OU, removing all group memberships and attaching new (e.g., "disabled users") group memberships, some number of days after deactivation.
    5. Deletion of accounts (but not identities inside Hitachi ID Suite) at some later still date.
  4. Urgent deactivation for all user types, where required.
  5. Rehire detection, so that when an attempt is made to onboard a "new" user who actually matches the identity of an old user:
    1. The request is blocked.
    2. If the old user profile was marked as "do not allow back," the process is terminated.
    3. If the old user profile was marked as "allow to return," a reactivation process is initiated instead.
  6. Leave of absence, triggered by both the SoR and by the request portal, on both departure and return dates.
  7. Access certification of user identities, manager/subordinate relationships and entitlements, both periodically and triggered by events such as user transfers.
  8. Portal requests and approvals for transfers, reorgs and relocations, including automatically triggered certification, reassignment of mail folders and home directories (if relocated), approval by new manager (if transferred), move to a new directory OU (if appropriate), etc.
  9. Self-service and delegated requests to update identity and contact information.
  10. Self-service and delegated requests for new entitlements, such as requests for group membership, for share/folder access and for SharePoint site/library access.
  11. Use of the system as a corporate white pages directory, with access controls limiting what one user can see of and request on behalf of another user. These access controls depend on how the requester and recipient users are related, rather than merely on the role of the requester.
  12. Password management includes:
    1. Managed collection (i.e., automated invitations and reminders, sent at a controlled pace) for security question data from users.
    2. Password expiration early warning.
    3. Password synchronization (if more than just a single AD domain is integrated), triggered both by native Windows password changes and the Hitachi ID Suite web UI.
    4. Self-service password reset, accessed via web browser or PC login prompt and authenticated using security questions and/or SMS/PIN to the user's mobile phone.
  13. Support for photographs of users as an identity attribute (URL to JPG).
  14. Many built-in reports.

The objective of Identity Express is to minimize initial and ongoing configuration of the Identity and access management (IAM) system -- which lowers cost and reduces time to deploy.

All functionality in Identity Express is configured through policy tables. For example, a table defines how identity attributes are to be validated and (re)formatted. Another table specifies how change requests entered into the Hitachi ID Suite portal are to be routed to authorizers. Additional tables provide rules to look up values for OU, home directory path, mail server and volume, etc. Other tables specify actions and time intervals for various parts of the access deactivation process.

The identity schema and managed entitlements are fully configurable, via the product administration web UI.