Workforce Identity projects, which include Identity Governance, require an equal blend of technical and business skills. Before embarking on a project, its important to plan your project. This includes defining 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 in this section provide can provide a framework to aid in the capturing of requirements.

IAM projects are not trivial undertakings. They require time and sufficient planning. This framework represents a place to start. The requirements process should be iterative and involve the appropriate team members. As the process evolves, questions not listed here will arise. These questions should be explored if they are relevant to the business.

Project background

Indicate the primary drivers for this project

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

Describe the user population that will be managed by the IAM solution

• Number of Employees ___
• Number of Contractors / other temporary workers ___
• Number of 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 (Joiners, movers, leavers), we need to start by answering the following questions:

• Where will user information come from? (These will become the authoritative sources of information)
• 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 aid in capturing 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 may be 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:

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

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)

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.

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. Position changes usually refer to changes in a job and can be identified through changes title, job code, manager, or department; you are not limited to these attributes. If a change in one or more of these attributes that are associated with position change occurs, then OpenIAM will 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:

In the example above, 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 use 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?

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, adding/removing entitlements, resetting passwords, terminating users, etc. To define the scope of the integration effort, complete the table below.

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 building out 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 that 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.

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 application upload template is supported by a readily available synchronization script which is also shown in the developer guide. If you have many applications, this will save your time.

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: