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.

Project background

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.

Authoritative source(s)

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 NameField Type / Description
workerIDUnique Employee Id
Contingent_Worker_IDUnique ID for temporary workers
hireDateDate a person is hired; not your start date
terminationDateDate a person's employment ends
preferredNameFormattedAn employee's preferred name; ie. Michael -> Mike
lastNameEmployee's last name
firstNameEmployee's first name
jobData1String containing position information. jobData[0] = Position ID, jobData[1] = PositionTitle, jobData[5] = Position start date, jobData[7] = Position end date
firstDayOfWorkFirst day of work
phoneData1Work phone number

Target applications

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 NameNumber of Instances / TenantsType of applicationConnector availabilityImport 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 NameDescriptionRules to generate value
sAMAccountNameUser identityLimited 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.
userPrincipalName
cn
dn
givenName
middleName
sn
ExtensionAttribute10
title
EmailAddressEmail addressFirstname + "." + lastname + "@mycompany.com". If the email already exists, then Firstname + "." + lastname + "2" + "@mycompany.com"
memberOf
mobile

For each application in the above list, define birthright access if appropriate.

Example 1: Application Name: My Business App

Job TitleOrganization / Division / DepartmentAccess
Accounts Payable ClerkFinanceGrant membership to Role: View - Invoice
Senior ManagerFinanceGrant membership to Role(s): View - Invoice, View - Approvals

Example 2: Application Name: Active Directory

Job TitleOrganization / Division / DepartmentAccess
Accounts Payable ClerkFinanceGrant 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.

Terminations

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
    • Finance
  • Sales and Marketing
  • Network services
    • Shared folders
    • Storage
  • 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 NameSource of DataApproval flow
Active DirectoryConnector
Mycustom AppCSV FileFirst 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
    • Applications,
      • 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
  • 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 NameSSO protocol supportedWho can access these applicationWhich attributes should be passed to the application
Salesforce.comSAML 2Role: 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 OptionEnd User RoleRole 2Role 3
My Info
My Applications
Request approval
- My approvals
- Request history
- Request administration
Access Management
- Manage user
- Access profiles
- New user
- New user - no approver
- Bulk upload
Self-service center
- Change password
- Change password extended
- Challenge response
- Directory lookup
- My Devices
- My Sessions
- Edit your profile
User Access
- View My Access
- View Direct Reports