Scope of the 11.0 release
The Hitachi ID Suite 11.0 release includes all Hitachi ID products:
- Hitachi ID Identity Manager -- User provisioning, RBAC, SoD and access certification.
- Hitachi ID Password Manager -- Self service management of passwords, PINs and encryption keys.
- Hitachi ID Privileged Access Manager -- Secure administrator and service accounts.
These products can be deployed separately or together, in the following combinations:
- Identity Manager alone.
Note: this includes Hitachi ID Group Manager and Hitachi ID Access Certifier.
- Password Manager alone.
Note: this includes Hitachi ID Telephone Password Manager.
- Identity Manager and Password Manager in a shared instance.
- Privileged Access Manager alone.
- Group Manager -- a subset of Identity Manager strictly for group management.
Other combinations are technically possible but not actively tested.
What's new in 11.0
- Enhancements across the entire Hitachi ID Suite:
- Real-time monitoring of Active Directory for changes, to avoid
the need for batch-oriented auto-discovery on this target
- This makes it practical to integrate AD domains with millions of accounts.
- By shrinking the time required to discover accounts and groups on AD, more time is made available for discovery on other systems. This makes it practical to run auto-discovery on all other integrations every hour or two, for example.
- Support for extracting and archiving audit or historical data,
such as logs or request history. Using this, policy can be defined
to determine when to archive and when to delete records, to
prevent an explosion of retained data and consequent storage
and performance problems.
- A built-in Security Assertions Markup Language (SAML) service provider (SP) , suitable for integration with federated
access systems or strong authentication platforms.
- A REST API, suitable for searching for objects in Hitachi ID Suite
and for submitting pre-defined requests into the workflow queue.
- Please see (2) for details about
- Real-time monitoring of Active Directory for changes, to avoid the need for batch-oriented auto-discovery on this target system type:
- Identity Manager:
- Full lifecycle management of group objects across all
integrated target system types. This includes:
- Expiry dates on group objects.
- Groups with maximum membership.
- Groups whose members are automatically-assigned.
- Groups with membership set via a request/approval process.
- White-list and black-list members in groups whose membership is calculated.
- Attributes are assignable to the linkage between accounts or
users on the one hand and entitlements on the other. This will
enable simpler representation of when, where and why the entitlement
was first assigned or discovered and when it is scheduled
to be revoked.
- A resource browser and editor, where authorized staff can
search for and add meta data to managed groups. This will be
extended to roles, groups, SoD policies and other object types in
- Please see (3) for details about
improvements in IM in 11.0.
- Full lifecycle management of group objects across all integrated target system types. This includes:
- Privileged Access Manager:
- Analytical reports for the SSH web of trust, for example to
identify accounts which are directly or indirectly trusted
by many other accounts, and so represent elevated risk, or
accounts which directly or indirectly trust many other accounts,
so are not well secured.
- Access disclosure via extensions to the Microsoft Edge browser
(previous releases supported Firefox, Chrome and Internet Explorer,
as Edge had no support for browser extensions).
- The ability to terminate an active privileged login session
in real time, from the UI used to watch activity in that session
(previously a separate UI was used to disconnect active sessions).
- Please see (4) for details about
improvements in PAM in 11.0.
- Analytical reports for the SSH web of trust, for example to identify accounts which are directly or indirectly trusted by many other accounts, and so represent elevated risk, or accounts which directly or indirectly trust many other accounts, so are not well secured.
- Password Manager:
- When a user signs into Password Manager, a policy based on their identity, group memberships, location, device type, time of day, etc. determines whether and for how long to sustain their session. This makes it possible, for example, to offer low risk users single sign-on while higher risk users or logins from high risk locations require fresh authentication on every access attempt.
- The ability to update locally cached passwords after a
successful web-accessed password change, when the user
accesses Password Manager using the Edge web browser. This was not
possible before as it requires a browser extension, which Edge
did not support until recently.
- Please see (5) for details about
improvements in PM in 11.0.
Hitachi ID Suite 11.0 screen shots
Identity Manager - Group lifecycle management
Until the 11.0 release, Identity Manager could assign users to groups and remove users from groups, but not really manage the lifecycle of group objects themselves. Moreover, group membership changes were mainly made from the perspective of the user -- i.e., select the user and add/remove groups.
Starting with 11.0, Identity Manager can manage the lifecycle of group objects, including create/delete of group objects and management of metadata about groups -- i.e., attributes that are mapped to target systems plus attributes that exist only within its own database. Group membership can be managed both from the perspective of the user profile and from the perspective of the group.
All of this is managed through a new "Groups app:"
- Users access the groups app either as members or owners of groups.
- Users can search for or browse through a list of available groups.
- The app is used to submit change requests:
- Add or remove group members (i.e., accounts attached to groups).
- Manage parent / child relationships (i.e., groups within groups).
- Create new groups or deactivate existing ones.
- Set and manage attributes of groups.
- Users can apply the same set of changes to multiple groups at once:
- Example: add 5 users to each of 8 groups.
- Example: set the same risk score across multiple groups.
All changes are routed through the Identity Manager workflow manager which may calculate additional variables and invite stake-holders to approve changes prior to completing requests.
As with previous releases, groups can have either calculated or requested membership. Groups that require both are created using nesting -- i.e., a parent group is set to include requested members plus a child group with calculated membership.
Groups with requested members can have their membership reviewed and individual members (accounts or child groups) certified or revoked, immediately or at a later date.
Groups with calculated members can specify white-lists (i.e., users who are assigned to the group even if they fail to satisfy inclusion criteria) or black-lists (i.e., users who are not made members, even if they satisfy inclusion criteria). Both of these features, and automatically assigned membership in general, are handled via user classes.
Group membership management can be changed from the perspective of either the member users or the assigned groups:
- From the group perspective, multiple members (accounts or child groups) can be added or removed at once. A group can also be added to or removed from the membership of parent groups using the request mechanism.
- From the user perspective, multiple groups can be assigned or revoked at once.
A user browsing through a list of groups he owns
Using a request form to add member-accounts to (a) selected group(s)
Advanced search used to add members based on criteria
Managing parent/child relationships with a request form
Single sign-on policy
Single sign-on -- i.e., whether the Hitachi ID Suite will prompt users to re-authenticate if they attempt to access the system repeatedly in a short period of time, depends on policy. For example, subsequent login prompts may be suppressed if the initial login was from an internal user, connecting from the on-site private network, using a corporate managed endpoint, during normal work hours and if that user's access rights do not represent elevated risk (HR, executive, systems administrators, etc.). On the other hand, connections outside of normal hours, or from a personal device, or by a high risk user might require fresh authentication on every interaction with the Hitachi ID Suite portal.
Configuring session persistence is done with policy, as illustrated below:
Session persistence (SSO) policy
Most mature software deployments move through development, testing and production environments. In theory, these environments are identical and migration is easy. In practice, it is too costly to build identical environments so there are major differences between these environments.
When environments diverge, migration between them can be hard. After exporting a configuration from one environment and importing it into another, many manual changes must be made, to make the system work in the new environment. This manual adjustment process can be time consuming, costly and error prone. This can significantly impact the total cost of deployment, as every migration is more time consuming and error prone than it should be (in an ideal world).
Hitachi ID Suite can can export and import system configuration into JSON files. Environment files encapsulate these configurations and identify differences between development, test and production. A single set of files is then used to capture the configuration of the system, including all all variation across environments. When importing these files into a new environment, the product administrator specifies which environment is being activated, and the various adjustments are made automatically.
Formal modeling of differences between environments simplifies migrations, reduces time spent, lowers cost and eliminates errors.
Defining variances between environments