Select request type:
In most deployments, automation based on an HR data feed is used to on-board employees, but a manual request process is used to provision contractors. In this example, the first step is for the manager to sign in and select a request type -- in this case, hiring a Geologist.
New user profile: identity attributes:
After selecting a request type, the user is prompted to provide details. Continuing with this example, the details are the identifying information about the new user -- name, office location where he will work, home e-mail address, etc. Some of the information was automatically filled in based on the request type.
Set initial password:
With manually-entered requests, we have the opportunity to set (and expire) the user's initial password, as shown here. This eliminates the need to use default or predictable initial passwords and minimizes the number of people who know what the password will be.
Reason for request:
Requests should have a reason. Why are we asking to provision a new contractor? This sort of meta data is associated with the request but not with the user we are creating or modifying. In this example, the meta data is simple, but in more complex scenarios it could include cost codes, authorization codes, deferred start dates, etc.
The final screen allows our requester to review his form -- in the summary format shown here or in detail -- before submitting it. Once the request has been submitted, it will be routed to appropriate decision makers to approve or reject before being completed. Prior to approval, the requester can track its status and can always cancel it.
Reminder to perform a review:
Users are sent e-mail invitations, asking them to perform a review. When they sign into Hitachi ID Access Certifier, they are reminded of any pending activities -- in this case, the same review.
Review list of direct subordinates:
In this screen, a manager has been asked to review a list of his direct subordinates. For each one, he must indicate whether the person still reports to him, still works in the organization, or has left and his/her access should be deactivated. Other kinds of reviews may be of role assignment, accounts, group membership, SoD violations, etc.
Sign off on the review:
A completed review requires an (electronic) signature. This acts as evidence, in the event of an audit, that the review was completed by this certifier at this time/date, with these changes (no changes in this example).