Workforce IAM Project Planning
Workforce IAM / Identity Governance projects require an equal blend of technical and business skills. Before embarking on the project, its important to define the business requirements and objectives in sufficient detail for the implementation team. Failure to do so can result in project overruns and failure. The section below provides a framework to aid in the requirements definition and planning of your project.
IAM projects are not trivial undertakings. They require time and sufficient planning. This framework represents a starting point. The requirements process should be iterative and involve the appropriate team members.
Describe the primary drivers for this project
- Automate user life cycle management ____
- Compliance or regulatory requirements ____
- Reduce operational costs ____
- Improved security ____
- Improved end-user experience and responsiveness ____
- Replace current IAM solution
- Other: ____
Describe the type of users and the number of users that will be managed by the IAM solution. If the number of concurrent users is available, describe that as well. This information will help in determining sizing information along with other information below.
- Employees ___
- Contractor / other temporary workers ___
- B2B / B2C Users ___
Number of concurrent user sessions ___
User Lifecycle management
The following questions are related to user life cycle management and will form the foundation of the project.
For each type of user, list below the authoritative source application Example:
- Workday is the source for Employee
- Active Directory is the source for all non-employees
For each application in the above list, describe how OpenIAM will integrate with the system Example:
- Workday : OpenIAM provides a connector
- [some custom source]: Connector will need to be developed using the applications REST API
- [some other source]: CSV file will be generated nightly.
For application in the above list, create a matrix as shown below, to represent the fields which must be imported to OpenIAM. Details should be provided for each attribute as they will be used to create the rules to process this information in OpenIAM.
Application Name: Workday
|Field Name||Field Type / Description|
|workerID||Unique Employee Id|
|Contingent_Worker_ID||Unique ID for temporary workers|
|hireDate||Date a person is hired; not your start date|
|terminationDate||Date a person's employment ends|
|preferredNameFormatted||An employee's preferred name; ie. Michael -> Mike|
|lastName||Employee's last name|
|firstName||Employee's first name|
|jobData1||String containing position information. jobData = Position ID, jobData = PositionTitle, jobData = Position start date, jobData = Position end date|
|firstDayOfWork||First day of work|
|phoneData1||Work phone number|
Target applications are applications which will be managed by OpenIAM. In these applications, OpenIAM will perform operations such as creating new users, setting entitlements, resetting passwords, etc.
List each application which will be managed by OpenIAM as shown below providing the request information
|Application Name||Number of Instances / Tenants||Type of application||Connector availability||Import User + entitlement from application to OpenIAM|
|[COTS] / [Custom]||[Yes] / [No] / [Requires connector development]||[Yes] / [No]|
For each application in the above list, complete the matrix below Along with the application name, its import to know how the value should be generated. The example below uses a subset of attribute found in Active Directory .
Application Name: Active Directory
|Field Name||Description||Rules to generate value|
|sAMAccountName||User identity||Limited to 20 characters. First 19 Characters of Last name + first letter of first name. If its not unique, then 18 characters of last + first character of first name + numeric value which is incremented by 1. Example: smithw, smithw2, etc.|
|EmailAddress||Email address||Firstname + "." + lastname + "@mycompany.com". If the email already exists, then Firstname + "." + lastname + "2" + "@mycompany.com"|
For each application in the above list, define birthright access if appropriate.
Example 1: Application Name: My Business App
|Job Title||Organization / Division / Department||Access|
|Accounts Payable Clerk||Finance||Grant membership to Role: View - Invoice|
|Senior Manager||Finance||Grant membership to Role(s): View - Invoice, View - Approvals|
Example 2: Application Name: Active Directory
|Job Title||Organization / Division / Department||Access|
|Accounts Payable Clerk||Finance||Grant membership to group: CN=Finance,OU=Groups,DC=openiam,DC=net|
If users will be able to request access to the above applications from the self-service portal, then define an approval-flow for each application
Approval flows can be defined at either the application or entitlement level. Often, it is most practical to define the approval flow at the application level and then override that flow at the entitlement level. An example of an approval is:
- First approver: Manager
- Second approver: Application Owner
Joiners ( New hire process)
Provide a high level overview of how the new hire process will process data from the Authoritative source as well as how each type of user will be processed.
As part of the description ensure that the following are being addresses sufficient:
- Future hires - these are employees which have a start date in the future. When should OpenIAM provision the account and when should it be activating the account for these employees?
- How should credentials be delivered for new employees?
- Should temporary credentials be sent to the manager to be shared with the employee?
- Should there a first time claim process to allow the end user to activate their account without involving anyone?
- For non-birthright access, how will the access be granted?
- Will the manager create a request for access?
- The end-user will create this requests?
- Both? If so, detail it this process further.
- Should notifications be sent to another system? (sometimes a ticket is created in ticket system to initiate ordering of hardware, badges,etc.)
- How are rehires to be handled?
If there are application specific rules, which have not yet been defined, then define them for each relevant application.
Movers ( position changes )
First define attribute which should be monitored to determine if a position / transfer is occurring. Common attributes include: Job Code, Title, Department. If changes in one of these attributes occur, then OpenIAM will determine that its position change. Next define what should happen during a position change.
An example of common behavior for a position change is described below:
- OpenIAM calculate new birthright access based on the new position
- OpenIAM revokes previously granted birthright access that is no longer needed. Access granted using request/approval is not revoked at this point
- OpenIAM provisions birthright access which is needed for the new position
- OpenIAM starts a workflow and notifies the new manager that a transfer is occurring and requests the manager to review and approve the non-birthright access that the employee currently has
- Manager logs into OpenIAM and views the request.
- Approves valid access
- Revokes access that is no longer necessary
- Manager then creates a new request for access that the employee will need for their new position which is outside of the birthright rules.
While describing terminations, consider the following cases:
- Person leaves the company with a notice period and access is revoked at the end of their last date
- Emergency termination
- Leave of absence
- Legal hold (Access is disable, but not revoked to allow for investigations)
Describe for each application what should happen do each of the above termination related activities
For example, the termination rule for Active Directory, may look like this:
At the end of the employee's last Date, do the following:
- Disable the account
- Remove all group membership
- Move the account the following OU : OU=disabled-users,DC=openiam,DC=net
30 Days after the employee's last date, do the following:
- Delete the account
Request / Approval
if you plan to provide your users with request/approval functionality, then it too must be defined. You will need to consider the following:
Define service catalog structure. Define how the catalog be organized? OpenIAM provides a nested categorization structure so that users can easily find their applications. Example of a categorization structure is shown below.
- Enterprise applications
- Sales and Marketing
- Network services
- Shared folders
- Directory services
Define applications or services for each category above.
For each application which will be listed in the catalog, indicate the source of data This list is similar to the one created above for automated provisioning. Since all customers may not implement automated provisioning, its important to define the scope and functionality of the catalog.
|Application Name||Source of Data||Approval flow|
|Mycustom App||CSV File||First approver: Manager, Second approver: Entitlement owner|
Its important to note that if data will be imported from a CSV file, the time should be allocated in your project to:
- Import the CSV file ( List of entitlements and a list of Users + entitlements )
- Create the import scripts to process the file being shared
- validate the data
- Possibly address any orphans
For applications which do not have a connector, we should also consider the following:
- Approval flow
- Who will provision access once a request is approved?
- Who will revoke access when access is revoked or a user is terminated?
User access reviews (aka Access Certification)
To implement user access reviews, you should consider the following:
- Do you need to review all access that a user has or only a specific set of applications.
- User based review
- Determine which users needs to be reviewed and how often
- Define the review flow for these users
- Each set of users with a common review flow can be included in one campaign
- Determine which applications need to reviewed and how often
- For each application that is to be reviewed determine
- Should all entitlements be reviewed or only a select set of entitlements
- Define the review flow for each application
- Application which have a common review flow, can be grouped together into a single campaign
- User based review
- Determine who the user access review manager (UAR manager) should be for each campaign. The UAR manager is the person responsible for overview the completion of the reviewing and extracting the reports for auditors
Passwords - Forgot password and Self-service
If you Self-service password reset will be offered to users via OpenIAM, then you should the following:
- Define your password policy
- Password composition
- How often it needs to changed
- Define what options will be available to user to support forgot password
- Challenge questions
- One-time link over e-mail
- One-time passcode over SMS
Signing into OpenIAM
Determine how users will sign into OpenIAM. For example, if you already have an IdP like Google or Azure, will OpenIAM be a service provider to the IdP? If users will be signing into OpenIAM directly, then you should define at a minimum, the authentication policy for:
- Self service portal
- Admin console
Single Sign On
If OpenIAM will be the IdP and users will be able to SSO to their applications from OpenIAM, then define create a matrix like the one shown below:
|Application Name||SSO protocol supported||Who can access these application||Which attributes should be passed to the application|
|Salesforce.com||SAML 2||Role: Sales Manager|
Define what a person can do in OpenIAM
The self-service portal offer a broad range of functionality. You may not want to expose all functionality to all people. To manage, this you should consider defining a roles matrix as shown below.
|OpenIAM Menu Option||End User Role||Role 2||Role 3|
|- My approvals|
|- Request history|
|- Request administration|
|- Manage user|
|- Access profiles|
|- New user|
|- New user - no approver|
|- Bulk upload|
|- Change password|
|- Change password extended|
|- Challenge response|
|- Directory lookup|
|- My Devices|
|- My Sessions|
|- Edit your profile|
|- View My Access|
|- View Direct Reports|