Automated processes to create and revoke access
Automatic provisioning of new hires: from HR to first login
- 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.
- 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.
New user experience
First login for new contractor
- A newly hired contractor signs in by answering security questions based on PII data (driver's license, mother's maiden name, date of birth, etc.).
- A random PIN may also be sent to the user's phone or personal e-mail address.
- Once authenticated, the user must complete a profile of security questions / answers.
- The user resets his own password -- there was never a known, shared password value.
- The user may be asked to review and accept policy documents at first login.
- Eliminate the need for predictable initial password.
- Capture security questions at first login.
- Get new users to read and accept policy documents.
Sheduling and deferring deactivation
Authorizing scheduled termination
- Approval of a change to a user's scheduled termination date is handled by an HR user.
- In this example, three HR users were invited but any one of them can do the job -- increasing process reliability and shortening time to completion.
- Who is invited to approve a change is determined by policy.
- Policy is based on relationships between requester, recipient and authorizer.
- A random subset of a users (e.g., members of an HR group) can be chosen.
- A further subset of invited users may be sufficient to approve.
- Invitations go out via e-mail, with responses via authenticated, secure, encrypted web form.
Manually scheduling access deactivation
- A manager schedules termination/deactivation for one of his subordinates.
- Members of the HR department are invited to approve the change.
- Scheduled events, such as deactivation, are modeled using a date attribute in the user's profile.
- Access controls determine who can see this date, who can request a change and who must approve a change.
- In this example, a user's manager and anyone in HR can see/edit this date, but the user cannot. If the manager requests a change, HR must approve it. Conversely, if HR requests a change, the manager will be asked to approve it.
- Once the request is approved and stored in the user's profile, other processes take care of the deactivation process. The workflow component is simply for setting this date.
Self-service via UI and client OS integration
A user updates his own contact information
- An employee logs into Hitachi ID Identity Manager and updates his own contact information.
- The request is automatically approved.
- Routine changes, for example to personal contact information, can be moved from a help desk call to a self-service model.
- Access controls determine who can see and who can modify what in whose profile. In this case, self-service update of contact information is allowed.
- Security policy also determines what authorization is required before a change request is completed. In this case, none.
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.
- 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
- A request for group membership is routed to the group's owner for approval.
- 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
- The user signs out, signs back in and can access the folder which previously caused an "Access Denied" error.
- 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”
- 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.
- 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.
Access reviews and remediation
Review list of subordinates, certify that they still need logins
- Certify that a list of users are still employed by the organization and each of them still reports to the manager performing the review.
- 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
- Review a list of users in a security group.
- Approve most, revoke one.
- 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
- Review a list of users who have been assigned a role.
- Approve most, remove the role from one.
- 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 approved exceptions to segregation of duties (SoD) policies
- 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.
- 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 owner reviews a list of users with access to his application as well as their entitlements (groups) within that application.
- Review of application access by application owner.
- Review includes fine-grained entitlements.
- Organize data by user or by login ID/group.