Automated processes to create and revoke access

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).

Automatic provisioning of new hires: from HR to first login


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.

New user experience

First login for new contractor


Content:

  • 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.

Key concepts:

  • Eliminate the need for predictable initial password.
  • Capture security questions at first login.
  • Get new users to read and accept policy documents.

Scheduling and deferring deactivation

Authorizing scheduled termination


Content:

  • 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.

Key concepts:

  • 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


Content:

  • A manager schedules termination/deactivation for one of his subordinates.
  • Members of the HR department are invited to approve the change.

Key concepts:

  • 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


Content:

  • An employee logs into Hitachi ID Identity Manager and updates his own contact information.
  • The request is automatically approved.

Key concepts:

  • 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


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.

Access reviews and remediation

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 approved exceptions 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.