Business Alignment

Many organizations are made up of a huge number of varying identity types: employees, technical identities, contractors, devices, and end users. If all these identities were each managed one-by-one, it would not only take a huge amount of time, effort, and resources to get under control, but also would likely result in errors along the way. A best practice is to group identities based on their job function (roles), where they work (context), or other traits that link identities that require similar access. However, it can still be challenging to align the business under common terminology, philosophies, and technology to make this happen.

As part of Omada IdentityPROCESS+, an identity governance framework focusing on best practice processes, there are several key components to Business Alignment that are critical to follow best practices so as to ensure that business efficiency is optimized, security is tight, and compliance is met.

Why Business Alignment is important

Managing Business Alignment

The business alignment process area reduces the complexity of onboarding and managing employee access rights using roles, policies, and contexts with predefined access rights to which employees can be assigned. The defined policies and contexts can be designed to accurately model and reflect the business structure in the IGA solution.

Overall, this allows organizations to optimize their IGA deployment and achieve quick wins early in the lifecycle of the project due to increased user adoption.

Creating roles, contexts, and policies aligned to the business simplifies identity and access management.

Business Alignment starts with the definition of roles which are lists of access requirements for users who have the same or very similar jobs. If there are multiple employees in an organization that have the same role – such as sales managers and helpdesk support agents – defining roles makes it easier to get them up and running when they join the company.

The business alignment processes enable assignment policies to be defined which automatically assign a set of rights to individuals if they meet certain criteria. For example, this could be access to a file share for all people in a certain department, or for access to printers for all employees located on the third floor. Assignment policies can be set with a specific start and end date to limit access which will keep the company secure and compliant.

Like roles, contexts make managing groups of users with similar access requirements easier as they can be treated as a single entity. However, they are different to roles because the individuals being managed do not necessarily have the same job function but have a common business interest. For example, a group of employees working in a manufacturing production line may all need access to the same production database even though they perform different roles. In this case, the different job functions would all be part of the “manufacturing plant workers” context. Contexts allow companies to model and govern complex situations such as matrix management structures or organizations where employees are associated with multiple departments.

The Business Alignment process area includes the following process groups and sub-processes:

1. Manage role
   • Create, modify, or terminate role
2. Manage policy
   • Create, modify, or terminate assignment policies
   • Create, modify, or terminate constraint policies
3. Management context
   • Create, modify, terminate, request and approve, prolong, and remove context assignments

The three process groups are further explained below.

Process Group: Manage Role

Enables organizations to quickly and easily assign a set of access rights to new users with the same job roles.

Create, Modify, or Terminate Roles

Assigning access rights to users manually is time-consuming, tedious and prone to human error. By creating a set of access rights (a “role”) for a common job function and using it many times, organizations increase efficiency and reduce the likelihood of mistakes that result in security and compliance risk.

Process description. The manage role processes which include create role, modify role, and terminate role allow administrators to manage descriptions of access requirements for users who have the same or very similar jobs. When a new employee joins the company and is assigned a role, access is automatically provisioned to all the systems they need to perform their job. For example, all sales personnel should be granted access to the company’s CRM system, e-mail system, expense, and travel application, so instead of being granted the access individually they are all granted when a new sales employee joins the organization.

In addition, roles can be modified over time to match new business requirements such as new applications being introduced for a certain job and can also be terminated when they are no longer required.

Best practice IGA system functionality. Access requirements that are required to meet business needs for each job function are defined using the create new roles process. Roles are defined to match organization structures, business locations, business processes, or control procedures. They are defined in conjunction with relevant legislation, regulatory demands, and company security policies. Once defined, the roles are created in the IGA system and assigned to new employees based on their job description in the HR system when they join the company or when they move to a new job function.

If there is a change in the business need represented by the role, such as a new application being introduced or a new regulation, then the modify roles process is used to update role definitions.

When the business need is no longer relevant, the terminate roles process is used to remove a role from the IGA system.

Technical process flow:

1.  The administrator creates roles based on attributes such as job titles
2.  The IGA system determines whether each identity matches the role
3.  Associated access rights will be provisioned to identities matched up to the specific role

Process Group: Manage Policy

Enables organizations to quickly and easily assign a set of access rights to users who meet a set of criteria and to create and manage access constraint policies.

Create, Modify, or Terminate Policy

Setting up individual access rights for users that meet certain criteria – such as users in a department who need access to confidential data – is inefficient and potentially error-prone. Establishing procedures to automate assignments based on policies not only improves efficiency, but also decreases the security and compliance risks due to incorrect access rights assignments.

Process description. The assignment policy processes which include create assignment policy, modify assignment policy, and terminate assignment policy, manage the policies giving access rights to users matching certain business criteria that results in them needing access to business systems and data.

Unlike roles, which use the employees’ job titles to assign access rights, assignment policies depend on matching identity characteristics. Any identity that falls into the identity filter set in the assignment policy will be granted the associated access rights. For example, a manager based in the US would be granted access to the company’s US-based expense management system whereas their European counterpart would be granted access to the equivalent European system.

Best practice IGA system functionality. The administrator sets up an identity filter and creates a new assignment policy using the create new assignment policy process. Any identities that match the filter criteria are automatically given the access rights defined in the assignment policy. Any changes in the business requirements can be reflected using the modify assignment policy process.

If an assignment policy is removed using the terminate assignment policy process, then any access rights that were set up by it will be removed. It is important that the consequences of the terminate assignment policy process are considered before it is used as end users may be left without access to applications that are critical for them to do their job.

Technical process flow:

1.  The administrator creates the assignment policy which includes when the policy is valid as well as the filter defining the identities, contexts, and account types that should be included. The assignment policy also includes a list of resources that should be allocated to identities matching the filter
2.  A new calculation is performed to determine which identities should receive new access rights
3.  New access rights are provisioned for the identities in scope

Create New, Modify, And Terminate Constraint Policies

Organizations need to establish safeguards to prevent end users being granted access to multiple systems that could enable them to commit fraudulent activities. If this is not possible due to, for example, not having enough employees in a department to split activities, then a complete audit trail needs to be in place, so risk associated with allowing a potentially toxic combination can be justified.

Process description. The manage constraint policy processes are used to create, modify, and delete constraint policies such as separation of duty (SoD). These policies are checked each time a user submits a self-service access request, or an automated assignment is made. If there is a policy violation, then the access is not granted, and the issue is escalated to managers, to determine an appropriate resolution.

Best practice IGA system functionality. The process is used to set up access restriction combinations based on business processes or resources. Such constraints prevent access being granted to systems that could be used to carry out fraudulent activities. If a potentially toxic access combination is detected, the new access rights will not be granted, and the issue will be escalated using a predefined workflow, so a resolution can be found. The resolution could involve a manager rejecting or approving access to a system with an appropriate justification as to why the constraint has been manually overridden. The modify constraint policy and terminate constraint policy processes change and delete the constraint policies to reflect business requirements.

Technical process flow:

1.  The administrator creates a constraint policy and defines either a toxic business process, resource, or attribute combination
2.  A new calculation is performed each time there is a potential change to access rights for an identity
3. If no constraint policy violation is calculated, then the access is provisioned
4. If there is a constraint policy violation, the access is not provisioned, and the request is escalated for further action

Process Group: Manage Context

Enables organizations to quickly and easily assign a set of access rights to users who share the same business situation and access needs.

Create, Modify, or Terminate Context

When users have equal access requirements due to being in the same business situation, contexts allow administrators to manage them as a single entity when assigning access rights rather than inefficiently working on them individually.

Process description. The manage context processes which include create, modify, terminate, request and approve, prolong, and remove context allow administrators to manage the grouping together of users with the same access requirements. These logical groupings can be based on any business situation such as all employees located in a single location or all employees working on a single customer project. Context groups make it easy for organizations to manage user access rights as changes can be made at the context level which is then cascaded to all context members.

Unlike roles which are based on a user’s job title, contexts allow greater flexibility as any user can be added if required.

Best practice IGA system functionality. Administrators create a context using the create new context process. Once created, a user can request membership of the context and, if the request is approved by the context owner, be granted all its access rights. These actions are carried out using the request and approve context assignment. Administrators can use existing data fields such as the location of an employee or can create their own and use it as context. Each context can have one or more owners who are responsible for managing those who are assigned to the context.

Context owners can also modify the context assignment or delete it as required.

Technical process flow:

1.  A business context is created by the context owner
2.  A user requests access to join a business context
3.  The context owner receives a work item to evaluate the membership request
4.  The request is either approved resulting in the user joining the context or rejected resulting in the request being discarded

Process Stakeholders

Within IGA processes, it is critical that multiple stakeholders are aligned and working together. For Business Alignment, the following teams must be involved.

1. Human Resources (HR)
   • Ensure consistency of job titles in the HR (or other) system
2. IGA Team
   • Create roles, policies, and contexts once they are defined by the Line Managers
3. Line Managers
   • Help determine different roles within teams, as well as policies and contexts, across the wider organization
   • Work with HR to ensure consistent job titles within their departments
4. Business System Owners
   • Work with their peers and Line Managers to define toxic access combinations so that constraint policies can be defined
   • Classify resources and define approval requirements for access requests per resources/systems they own
5. End Users
   • End users do not have any direct involvement in the business alignment process. However, they are the ultimate beneficiaries as the alignment helps the IGA team and line managers to grant access to them quicker and easier

Key Best Practice Recommendations

Below are a set of key best practice recommendations that should be taken into consideration when implementing the Business Alignment processes in IdentityPROCESS+.

Roles

Establish role governance process and board or function

To successfully use a role-based model to grant access rights to individuals, it is necessary to have a well-defined set of roles. This is a challenge for many organizations as this task does not always belong to the IGA project. If an organization has decided to use a role-based approach to grant access, but the role model is not sufficiently developed, the IGA project will be delayed until it is in place. In addition, it is important that the role model is not too complex as this makes defining separation of duty rules difficult.

Ensure that role names are understandable by end users

To speed up the process of granting access rights, roles need to be clearly named so that employees can find the right role to match their requirements without having to call the help desk for support.

Create roles that support compliance requirements

Organizations need to ensure that the roles they have defined can easily fit into a compliance matrix without making it too extensive and complex. Too many diverse roles introduce unnecessary complexity which makes compliance management difficult.

Constraints

Define constraints at the role or business process level

Constraints between roles should be defined at a role level or a business process level as this allows organizations to maintain a good oversight and understanding of potential violations. Constraints should be defined in business terms rather than in technical language so that the relevant departments, such as finance or legal, can ensure that the requirements have been defined correctly.

Contexts

Ensure that access rights associated with contexts are removed when a user is no longer associated with it or when it is deleted

Users are granted access rights when they are assigned to a context. It is highly recommended that these access rights are automatically revoked when the user is no longer assigned to the context. For example, if a user is assigned to a short-term project and granted access rights accordingly, their access rights should be revoked automatically when they are no longer working on the project. This ensures compliance and security regarding the access to the project’s business systems. In addition, if the context is removed from the IGA system, then all access rights that were granted to users because of being associated with that context should also be removed.

Summary

Business alignment processes make it easier for organizations to manage users by allowing them to be grouped into groups based on either the jobs they do (roles), the common parts of their jobs such as belonging to the same project group, or based on certain attributes that they share such as belonging to the same department.

Being able to manage users based on certain criteria not only improves the efficiency of the IT department as they no longer need to create access rights for employees individually, but it also increases security and compliance as specific access rights can be defined centrally once and adopted by all users with the same requirements.