Hitachi ID Systems, Inc.

Hitachi ID Identity Manager screen recordings

Automatic provisioning (scheduled batch process)

Content:

A new employee is added to an HR application.
A batch process is triggered manually (just for demos -- normally it is scheduled).
Accounts for the new user are automatically created on AD and elsewhere.

Key concepts:

Automation is typically a batch process that runs at least once daily.
Business logic determines what to do when user records are added to, removed from or changed on each system of record.
Most suitable for coarse-grained (i.e., hire/fire) changes detected on HR systems.
Can also automate synchronization of identity attributes between systems.

Fill in a form: request access for a new contractor

Content:

This video shows how a manager can request access for a new contractor using a self-service form.

Key concepts:

While employees are normally auto-provisioned based on an HR feed, contractors typically are not.
Validation of the request form and routing to authorizers for approval happens next (separate recordings).

Check status of an open request

Content:

The person who entered a request can check on progress as often as desired.

Key concepts:

In general, every participants to a request -- the requester, recipient and authorizers, can view its current status.
Participants get e-mails with a URL of the status page.

Authorization process using E-mail invitations and web approval

Content:

An authorizer is invited to review and either approve or reject a change request.
Approvals take place via a secure, authenticated web form.

Key concepts:

Multiple authorizers can be invited at the same time.
Approval by N of M people is standard.
Reminders are automatically sent to non-responsive authorizers.
Escalation and delegation can replace non-responsive authorizers.

Reports -- users and accounts

Content:

List of users, with and without identity attributes.
List of accounts on a given system.

Key concepts:

The simplest reports in any IAM system are lists of users and accounts.
Built-in Hitachi ID Identity Manager reports can enumerate users, attributes, accounts, group memberships, roles and more.

Reports -- orphan and dormant accounts

Content:

Shows accounts with no known owner.

Key concepts:

Built-in reports make it easy to find orphan and dormant accounts:
- Orphan users are user profiles with no login accounts.
- Orphan accounts have no known owner.
- Dormant accounts have had no recent login activity.
- Dormant profiles have all-dormant accounts.

Reports -- violations of segregation of duties rules

Content:

Finds users who violate any segregation of duties (SoD) rule.
Finds users whose violation of an SoD rule has been approved.

Key concepts:

SoD reports are a detective control -- i.e,. they find already-existing violations.
There is also a preventive control, embedded in the change request workflow.
SoD violations may be approved, for example if they are a legitimate situation that the policy did not take into account.

Reports -- detailed change history

Content:

Displays all changes made to users, accounts and groups as a result of workflow requests.

Key concepts:

Change requests are retained indefinitely.
Details including what changed, who requested the change and who authorized it are accessible via built-in reports.
Changes detected on target systems (i.e., not initiated by Identity Manager) are also available.

Review list of subordinates, certify that they still need logins

Content:

Certify that a list of users are still employed by the organization and each of them still reports to the manager performing the review.

Key concepts:

The simplest form of access certification asks "do these people still work here, and report to you?"
For each subordinate, the manager can accept (still works for me), revoke (left the organization) or transfer (works for another manager).
This type of review is normally hierarchical -- every manager in the organization is asked to review his or her list of direct reports, in a bottom-up sequence.
This is a good starting point for access certification.

Review group memberships

Content:

Review a list of users in a security group.
Approve most, revoke one.

Key concepts:

Owners of security groups may be periodically invited to review the membership of their groups.
They can either accept or reject every group member.
When a group member is removed, this triggers a workflow request - with an audit trail and possibly further validation and/or approvals - before the user is actually removed from the group.

Review assigned roles

Content:

Review a list of users who have been assigned a role.
Approve most, remove the role from one.

Key concepts:

In principle, any user may be asked to certify role assignment for any list of other users.
By default, a resource's owner is assigned to certify the users who have that resource (the resource is a role in this case).

Review violations to segregation of duties (SoD) policies

Content:

Review a list of users violate an SoD policy.
For each violation, either remove one of the offending security entitlements or create an approved exception.

Key concepts:

SoD rules may be expressed in terms of individual entitlements (accounts, group memberships), roles or both.
SoD violations must be corrected manually, since the system cannot predict which of several conflicting entitlements should be removed and which are appropriate to the user's needs and should be kept.
SoD violations can also be approved, which means that there is a business reason to violate the policy.

Application-centric certification

Content:

Application owner reviews a list of users with access to his application as well as their entitlements (groups) within that application.

Key concepts:

Review of application access by application owner.
Review includes fine-grained entitlements.
Organize data by user or by login ID/group.

Windows access denied dialog leading to group membership request

Content:

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.

Authorization of a request for security group membership

Content:

A request for group membership is routed to the group's owner for approval.

Key concepts:

The default authorizers for changes to membership in a group are the group's owner(s) on Active Directory.
Customer-specific business logic can route requests to other or additional users for approval.
Approval by N of M people, reminders, escalation and delegation are all built-in.

Request approved, user can access the folder

Content:

The user signs out, signs back in and can access the folder which previously caused an "Access Denied" error.

Key concepts:

On Windows, changes to a user's group memberships only take effect when the user signs into his PC.
This means that after the user was added to the group in question, he must sign off and sign back on before he can access the protected share, folder, etc.

Sharepoint Access Denied

Content:

A user tries to access a site in SharePoint.
A user has no access rights.
The error message is modified by Hitachi ID Group Manager.
The user is directed to the appropriate request page on the Hitachi ID Group Manager request portal and requests access to the appropriate SharePoint group for his personal AD account.
Once the request is approved, the user can access the SharePoint site.

Key concepts:

Intercepting "Access Denied" error messages on SharePoint.
Diverting change requests and approvals out of IT and back to business users, who understand the business need for the access.
Reducing security administration IT call volume.