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.
Indicate the primary drivers for this project
|Automate user life cycle management|
|Compliance or regulatory requirements|
|Reduce operational costs|
|Improved end-user experience and responsiveness|
|Replace current IAM solution|
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 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
|Type of user||Authoritative source||Integration method||Frequency|
|Employees||Workday||OpenIAM Workday connector||Synchronize nightly|
|Contractors||Manager initiated form||OpenIAM Self-service new user request form||On-demand|
|Customers||Self-registration process||OpenIAM Self-registration form||On-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 Name||Field Type / Description||Maps to OpenIAM attribute|
|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 array 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|
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"(email@example.com)Email addresses must but unique and never be reusedIf an email address already exists, then add an increment by a counter to the last name till it in unique. For example:(firstname.lastname@example.org)
- 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. 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:
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.
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?
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.
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 Name||Number of Instances / Tenants||Type of application||Is AD integrated?||Connector Name||Import 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.
|Import user and entitlement information from applications||if 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 application||The provisioning rules define how OpenIAM will process each attribute in the system that it is provisioning too.|
|Define business roles||Business 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 access||Access 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
- Sales and Marketing
- Network services
- Shared folders
- 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.
|MANAGED_SYSTEM_NAME||Name as it will defined in OpenIAM|
|DESCRIPTION||User friendly description of this application or service|
|IS_MANUAL||Y - if a connector does not exist. N - if a connector does exist|
|IS_ACTIVE||Y - Configuration is available for use. N - configuration disabled and no tasks will be processed for this application.|
|IS_VISIBLE||Y - Application is visible in the catalog. N - application is not visible in the catalog.|
|PARTICIPATE_IN_ACCESSCERTIFICATION||Y - Application is available for use in access certification. N - application is not available for use in access certification|
|CONNECTOR_NAME||Name of the OpenIAM connector which will be used with this configuration|
|URL||URL of the application, service or tenant.|
|PORT||Port this application is listening on.|
|CATEGORY_NAME||Category under which the application should be listed in the service catalog.|
|PERMISSIONS_LIST||Permissions which will be used with this application. Example: READ, WRITE, EXECUTE. These can be unique to this application|
|APPLICATION_OWNER_TYPE||Type of application owner: User or Group|
|APPLICATION_OWNER||Name of the application owner|
|APPLICATION_ADMIN_TYPE||Type of application admin : User or Group|
|APPLICATION_ADMIN||Name of the application owner|
|APPROVER1_TYPE||Type of first approver: Supervisor, application owner, application admin, entitlement owner, specified user group|
|APPROVER1||Name of the first approver if its a user or group.|
|APPROVER2_TYPE||Type of second approver: Supervisor, application owner, application admin, entitlement owner, specified user group|
|APPROVER2||Name of the second approver if its a user or group.|
|APPROVER3_TYPE||Type of third approver: Supervisor, application owner, application admin, entitlement owner, specified user group|
|APPROVER3||Name 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
- 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
- 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 Name||SSO protocol supported||Who can access these application||Which attributes should be passed to the application|
|Salesforce.com||SAML 2||Role: Sales Manager|