Workforce IAM Project Planning

Workforce IAM / Identity Governance projects require an equal blend of technical and business skills. Before embarking on a 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 and related topics 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

Indicate the primary drivers for this project

DriverY/NComments
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:

The drivers for your project will help determine which of the sections below are relevant for your project.

Describe the user population (Number of users by type of user) that will be managed by the IAM solution

  • Employees ___
  • Contractor / other temporary workers ___
  • B2B / B2C Users ___
  • Number of concurrent users ___

This information will be used to determine sizing for your production environment.

User Lifecycle management

To implement user life cycle management, we need to start by answering the following questions:

  • Where will user information come from?
  • What access should each user get and how will the access be determined?
  • How will position changes or transfers be handled?
  • How should terminations be handled?
  • Will people be able to request access and if so, how will the approval process work?

The sections below will help define answers to these and other questions in sufficient detail so that the IAM project implementation team can utilize this information.

Authoritative source(s)

"Authoritative sources" or "systems of record" are applications that are the issuing source of a type of information. For example, in a corporate IAM solution, the human resources (HR) system is often the authoritative source for employee information. The HR information maybe augmented with information from other applications which are considered to be authoritative for a set of attributes that not found in the HR system.

For each type of user (employees, contractors, customers, etc), list the authoritative source

Example:

Type of userAuthoritative sourceIntegration methodFrequency
EmployeesWorkdayOpenIAM Workday connectorSynchronize nightly
ContractorsManager initiated formOpenIAM Self-service new user request formOn-demand
CustomersSelf-registration processOpenIAM Self-registration formOn-demand

The table above describes where information for each type of user will come from. It also indicates how OpenIAM will be used to capture this information.

For each authoritative source in the list above, provide a list attributes and their meaning so that they can be correctly imported into OpenIaM. Some of these attributes will be used by OpenIAM during the provisioning process to update downstream systems. Other attributes may not be used directly, but instead they will be used to derive new attributes such as: loginId, email address, and OU placement. The implementation team will use this information to:

  • Map selected attributes to OpenIAM objects and store them in the OpenIAM database
  • Use these attributes in automated provisioning processes

Application Name: Workday

Field NameField Type / DescriptionMaps to OpenIAM attribute
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 array 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

Life cycle events

Life cycle events can be broken down into Joiners, Movers, and Leavers (JML). The sections below describe the information that will be needed for each.

Joiners ( New hire process)

Provide a high level overview of how the new hire workflow 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 addressed sufficiently:

For each type of user (ie. employees, contractors, admin accounts, service accounts, etc)

  • Define rules for common attributes such as account id, email address, etc. which will be leveraged across applications. The example below describes a set of rules for generating email address:
An email address is made up of first name + "." last name + "@domain.com"(john.smith@mycorp.com)
Email addresses must but unique and never be reused
If an email address already exists, then add an increment by a counter to the last name till it in unique. For example:(john.smith2@mycorp.com)
  • For employees, with a future hire date, define when OpenIAM should provision the account and when they should become active.
  • 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?
  • How should systems without connectors be handled? Should a request be created in a ticket system or will a workflow be started in OpenIAM to support this case?
  • Are there attributes that need to be sent back to the authoritative source? For example, if email is computed in another system, then it maybe necessary to push this attribute back to the HR system.
  • How are rehires to be handled?
  • Notifications which need to be sent and their text

The diagram below provides an example of how the information captured above can be complemented with a diagram which provides an overview. Joiner process

In this simple example, we see the following process:

  • Joiner is detected
  • Birthright access is computed
  • For each application, the system will determine if a connector is available or not
    • If a connector is available, then automatically provision the access
    • If a connector is not available, then create a ticket in the ticket system so that a helpdesk agent provision the access

Each implementation is different this process is just an example. You will need to define your own process

Movers ( position changes )

Provide a high level overview of how the position change workflow will process data from the authoritative source for each type of user. Positions changes usually refer to changes in title, manager, and department; you are not limited to these attributes. If a change in one or more of these attributes associated with position change occurs, then OpenIAM will determine that its position change and start the position change workflows.

As defined in the joiners flow, define details related to desired behavior in a position change. Consider the following to start the process:

  • Which attributes from your source system should be monitored for position changes

  • Describe the overall flow of how position changes should occur

  • Consider cases where an employee does not have a manager for a period of time; ie. the manager leaves the firm

  • Notifications which must be sent out and their text

  • Describe the overall position change process as shown in the example below:

Mover process

In the example, we see the following process:

  • Position change is detected
  • Birthright access that was granted is revoked
  • New birthright access is computed and provisioned
  • The new manager is notified of the transfer. They will be asked to review the employees current access (individual access certification)
  • Manager will request the access that is not needed for their job but is not defined in the birthright access rules.

You will need to define a process to support transfers that aligns with your organization.

Leavers (Terminations)

Provide an overview of the leaver processes as you did for the other cases above. Leavers user cases include several variations and they should be considered if they are relevant for your organization. These include:

  • Graceful termination where a person leaves (asks to leave) with a notice period and access revocation is handled at the end of their last day.
  • Emergency termination
  • Leave of absence, Leave with pay, Leave without pay, etc.
  • Legal hold (Access is disable, but not revoked to allow for investigations)

As part of the leaver process, you should consider the following:

  • How should accounts be terminated?; ie. End-dated, disabled, removed completely, etc. (this may vary based on the application)
  • Notifications which should be sent out
  • Can accounts, email addresses be reused?

Leaver process

In the example we see the following:

  • Leaver is detected
  • Users current access is computed
  • For each application, the system will determine if a connector is available or not
    • If a connector is available, then automatically revoke access
    • If a connector is not available, then create a ticket in the ticket system so that a helpdesk agent can revoke access Each organization is different and the details of the process is vary. As such, you should consider the following:
  • Should you revoke access immediately or disable access first and then after a period of time, delete the access
  • Are identities and email values preserved to prevent reuse
  • Are there application specific rules which need to be addressed such as in Active Directory where some organizations move users to a disabled OU.

Target applications

The applications which OpenIAM manages from an Identity perspective are called Managed Systems (aka Target applications). In these applications, OpenIAM will perform operations such as creating new users, setting entitlements, resetting passwords, terminating users, etc. Using the table shown below, create list of each target application.

Application NameNumber of Instances / TenantsType of applicationIs AD integrated?Connector NameImport User + entitlement from application to OpenIAM
[COTS] / [Custom] / [SaaS][Yes] / [No][Connector name] / [Requires connector development][Yes] / [No]

The table above provides a reference to the number of applications which need to be integrated and the overall integration effort.

For each of the applications listed above, we need to do the following:

  • Define how existing user and entitlement information should be imported into OpenIAM. This step is critical in the build of the IAM solution. It provides a picture of the access that people have today and it allows the provisioning rules to take this information into account.
  • Describe each field which will need to be managed by OpenIAM and how we will provision users to these applications to support the joiners, movers, leavers processes described above.

The sections below will aid in defining the overall provisioning process and related rules.

TopicDescription
Import user and entitlement information from applicationsif identity information exists in your applications, its important to import that information into OpenIAM to create a complete profile of a user's access.
Define provisioning rules for each applicationThe provisioning rules define how OpenIAM will process each attribute in the system that it is provisioning too.
Define business rolesBusiness roles provide access to collection of applications and entitlements based on a set on inclusion criteria. If your project plans to implement role based provisioning, then at least some of the business roles should be defined upfront.
Define birthright accessAccess which can be granted automatically based on some criteria, without an approval process is birthright access. Birthright access should be defined as it will be an important part of the automated provisioning process.

Request / Approval

if you plan to provide your users with the ability to request access for entitlements from the self-service portal, then both the structure of the service catalog and workflows should be defined. The following should be considered as part of this process.

Define service catalog structure

Define how the catalog should be organized? While OpenIAM provides a default categorization structure, it should be modified to align with your organization. OpenIAM supports 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

Similar to the lists created earlier for automated provisioning, create a list which shows the applications, where they will appear in the catalog, and if there are approver. The file structure shown below is supported by a synchronization script shown in the developer guide. If you have many applications, this will save your time.

Column nameDescription
MANAGED_SYSTEM_NAMEName as it will defined in OpenIAM
DESCRIPTIONUser friendly description of this application or service
IS_MANUALY - if a connector does not exist. N - if a connector does exist
IS_ACTIVEY - Configuration is available for use. N - configuration disabled and no tasks will be processed for this application.
IS_VISIBLEY - Application is visible in the catalog. N - application is not visible in the catalog.
PARTICIPATE_IN_ACCESSCERTIFICATIONY - Application is available for use in access certification. N - application is not available for use in access certification
CONNECTOR_NAMEName of the OpenIAM connector which will be used with this configuration
URLURL of the application, service or tenant.
PORTPort this application is listening on.
CATEGORY_NAMECategory under which the application should be listed in the service catalog.
PERMISSIONS_LISTPermissions which will be used with this application. Example: READ, WRITE, EXECUTE. These can be unique to this application
APPLICATION_OWNER_TYPEType of application owner: User or Group
APPLICATION_OWNERName of the application owner
APPLICATION_ADMIN_TYPEType of application admin : User or Group
APPLICATION_ADMINName of the application owner
APPROVER1_TYPEType of first approver: Supervisor, application owner, application admin, entitlement owner, specified user group
APPROVER1Name of the first approver if its a user or group.
APPROVER2_TYPEType of second approver: Supervisor, application owner, application admin, entitlement owner, specified user group
APPROVER2Name of the second approver if its a user or group.
APPROVER3_TYPEType of third approver: Supervisor, application owner, application admin, entitlement owner, specified user group
APPROVER3Name of the third approver if its a user or group.

User access reviews

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.
  • How often should the review be performed.
  • Based on the answers for the first set of questions, you should consider the following:
    • 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
  • If you are using Active Directory, do you need to enable password synch from AD to other applications?

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