IdM Implementation: Preparation for Implementation by the Client

In previous articles, we discussed what IdM is, how to determine if your organization needs such a system, what tasks it solves, and how to justify the implementation budget to management. Today, we will talk about the important steps that the organization itself must take to reach the right level of maturity before implementing the IdM system. After all, IdM is intended to automate processes, and it is impossible to automate chaos.

Until a company grows to the size of a large enterprise and accumulates various business systems, it usually does not consider access management. Therefore, the processes for obtaining rights and controlling permissions are unstructured and poorly analyzable. Employees submit access requests as they see fit, the approval process is not formalized, and sometimes it simply doesn't exist. It is impossible to quickly discern what accesses an employee has, who approved them, and on what basis.

Considering that the process of access automation involves two main sides – HR data and the information systems data that need to be integrated, let's look at the steps necessary for a smooth IdM implementation and how to avoid resistance:

1. Analysis of HR processes and optimization of employee database support in HR systems.
2. Analysis of user data and rights, as well as updating access management methods in the target systems planned to be connected to IdM.
3. Organizational activities and involving staff in the preparation process for IdM implementation.

HR Data

The source of HR data in the organization can be one or several. For instance, the organization may have a wide branch network, and each branch may use its own HR database.

First of all, it is necessary to understand what main data about employees is stored in the HR accounting system, what events are recorded, and to assess their completeness and structure.

Often, not all HR events are recorded in the HR source (and even more often, they are recorded untimely and not quite accurately). Here are some typical examples:

• Vacations, their categories, and durations (regular or extended) are not recorded;
• Partial employment is not recorded: for example, while on extended parental leave, an employee can simultaneously work part-time;
• The actual status of a candidate or employee has already changed (hiring/transfers/termination), but the order for this event is issued with a delay;
• An employee is transferred to a new position through termination, while the personnel system does not record information that this is a technical dismissal.

Special attention should also be paid to data quality assessment, as any errors and inaccuracies obtained from a trusted source, such as personnel accounting systems, can later be costly and cause numerous problems when implementing IdM. For instance, HR staff often enter positions into the personnel system in different formats: uppercase and lowercase letters, abbreviations, varying spaces, and so on. As a result, the same position may be recorded in the personnel system in the following variations:

• Senior Manager
• senior manager
• sr. manager
• sr. manager…

It is also common to encounter variations in the spelling of full names:

• Shmelëva Natalia Gennad'evna,
• Shmel'eva Natalia Gennad'ievna…

For further automation, such a mix is unacceptable, especially if these attributes are key identifiers, meaning that the data about the employee and their authority in the systems are matched precisely by the full name.

Additionally, one must not forget the potential presence of namesakes and full namesakes within the company. If there are a thousand employees, such matches may be few; however, if there are 50,000 employees, it can become a critical obstacle to the proper functioning of the IdM system.

In summary, we conclude that the format for entering data into the organization's personnel database must be standardized. Parameters for inputting full names, positions, and departments must be clearly defined. The optimal option is when the HR employee does not manually type in data but selects it from a pre-created directory of department structures and positions using the 'select' function available in the personnel database.

To avoid further synchronization errors and the need for manual correction of discrepancies in reports, the most preferred method of identifying employees is to introduce an ID for each employee of the organization. This identifier will be assigned to every new employee and will appear in both the human resources system and the organization’s information systems as a required attribute of their account. It doesn't matter whether it consists of numbers or letters—what’s important is that it is unique for each employee (for example, many use the employee number). In the future, the introduction of this attribute will significantly ease the linking of employee data in the HR source with their accounts and permissions in the information systems.

So, all steps and mechanisms of human resource accounting will need to be analyzed and organized. It is quite possible that some processes will need to be changed or refined. This is a tedious and meticulous task, but it is necessary; otherwise, the lack of clear and structured data about HR events will lead to errors in their automated processing. In the worst case, unstructured processes will be entirely impossible to automate.

Target Systems

At the next stage, we need to determine how many information systems we want to integrate into the IdM structure, what data about users and their rights are stored in these systems, and how to manage them.

Many organizations believe that once we install an IdM system, configure connectors to target systems, the process will work like magic without any further effort on our part. Unfortunately, this is not how it works. In companies, the landscape of information systems evolves and expands gradually. Each system may have different approaches to access rights management, meaning that various interfaces for access control are configured. In some cases, management occurs through APIs (application programming interfaces), in others through databases using stored procedures, and in some cases, interaction interfaces may not exist at all. It's important to be prepared to reassess many existing processes for managing accounts and rights within the organization's systems: changing data formats, pre-developing interaction interfaces, and allocating resources for these tasks.

Role Model

You will probably encounter the concept of a role model during the selection of an IdM solution provider, as it is one of the key concepts in access rights management. In this model, access to data is provided through roles. A role is a set of accesses that are minimally necessary for an employee in a specific position to carry out their functional responsibilities.

Role-based access management has several undeniable advantages:

• it is simple and efficient to assign the same rights to a large number of employees;
• quick changes to the access of employees who hold the same set of rights;
• elimination of redundant rights and segregation of incompatible permissions for users.

The role matrix is initially constructed separately in each of the organization's systems and then scaled across the entire IT landscape, where global Business Roles are formed from the roles in each system. For example, the Business Role "Accountant" will include several individual roles from each of the information systems used in the company's accounting.

Recently, it is considered a best practice to create a role model during the development stage of applications, databases, and operating systems. However, there are often situations where roles are not configured in the system or simply do not exist. In such cases, the system administrator must input account data into several different files, libraries, and directories that provide the necessary permissions. Using predefined roles allows for granting privileges for a whole range of operations within the system dealing with complex composite data.

Roles in an information system are typically distributed according to positions and departments within the organizational structure but can also be created for specific business processes. For example, in a financial organization, several employees in the settlement department hold the same position—operator. However, within the department, there is also a distribution across individual processes related to different types of operations (external or internal, in various currencies, with different segments of the organization). To provide each business direction within a department with the necessary access in the information system according to its specific needs, it is essential to include permissions in separate functional roles. This will allow for providing a minimally sufficient set of powers without including excessive rights for each activity direction.

Moreover, for large systems with hundreds of roles, thousands of users, and millions of permissions, it is good practice to use a hierarchy of roles and inheritance of privileges. For example, the parent role Administrator will inherit the privileges of the child roles: User and Reader, since the Administrator can perform all the actions that a User and Reader can, plus have additional administrative rights. With the use of a hierarchy, there is no need to repeatedly specify the same rights in multiple roles of one module or system.

In the initial stage, roles can be created in those systems where the possible combinations of access rights are not too extensive, making it manageable to handle a small number of roles. This may include standard rights necessary for all company employees in public systems such as the Active Directory (AD) catalog, email systems, Service Manager, and similar. Subsequently, the role matrices created for information systems can be integrated into a comprehensive role model, combining them into Business Roles.

By using this approach, it will be easy to automate the entire access rights provisioning process based on the roles established in the first stage when implementing the IdM system in the future.

N.B. One should not attempt to include as many systems as possible in the integration right away. Systems with more complex architecture and access rights management structures are best connected to the IdM in a semi-automated mode at the initial stage. This means that based on personnel events, only the automatic generation of access requests should be implemented, which will be sent to an administrator for manual configuration of rights.

Once the first stage is successfully completed, the system’s functionality can be expanded to new advanced business processes, allowing for full automation and scaling by connecting additional information systems.

In other words, to prepare for the implementation of IdM, it is essential to assess the readiness of information systems for the new process and to revise the external interaction interfaces for managing accounts and user rights if such interfaces are lacking. It is also important to work on the phased creation of roles in information systems for comprehensive access management.

Organizational measures

Organizational aspects should not be underestimated. In some cases, they can play a crucial role, as the effectiveness of interaction between departments often determines the outcome of the entire project. For this reason, we usually recommend forming a team within the organization that includes all involved departments. Since this represents an additional burden for individuals, it is important to clearly explain to all participants their roles and significance in the interaction structure in advance. If you can 'sell' the idea of IdM to your colleagues at this stage, many challenges can be avoided later on.

Often, the 'owners' of the IdM implementation project in a company are the information security or IT departments, while the opinions of business units are overlooked. This is a significant mistake, as only they know how and in which business processes each resource is utilized, and who needs access to it and who does not. Therefore, during the preparation phase, it is important to establish that the business owner is responsible for the functional model, based on which user rights (roles) in the information system are developed, as well as for ensuring that these roles remain up to date. The role model is not a static matrix that, once created, can simply be left as is. It is a 'living organism' that must constantly change, update, and evolve in accordance with shifts in the organization's structure and employee functions. Otherwise, either problems arise related to delays in granting access, or security risks emerge associated with excessive access rights, which is even worse.

As is well-known, "too many cooks spoil the broth," therefore a methodology must be developed in the company that describes the architecture of the role model, the interaction, and the responsibilities of specific participants in the process for maintaining its relevance. If the company has many areas of business activity and, consequently, numerous divisions and departments, then for each area (for example, lending, operational work, remote services, compliance, and others) within the process of role-based access management, specific curators must be appointed. Through them, timely information about changes in the department structure and the access rights necessary for each role can be obtained.

It is essential to gain the support of the organization's management to resolve conflicts between departments—participants in the process. Conflicts during the implementation of any new process are inevitable, trust our experience. Therefore, an arbitrator is needed to resolve potential conflicts of interest, so as not to waste time due to misunderstandings and sabotage.

N.B. A good initiative to raise awareness would be training for staff. A detailed study of the functioning of the future process, as well as the role of each participant in it, will minimize the difficulties of transitioning to the new solution.

Checklist

In conclusion, let's summarize the main steps that an organization planning to implement IdM should take:

• organize personnel data;
• introduce a unique identification parameter for each employee;
• assess the readiness of information systems for implementing IdM;
• develop interfaces for interaction with information systems for access management if they are absent, and allocate resources for this work;
• develop and build a role model;
• establish a process for managing the role model and include curators from each business area;
• choose several systems for initial connection to IdM;
• create an effective project team;
• gain the support of the company's management;
• train staff.

The preparation process can be challenging, so if possible, engage consultants.

Implementing an IdM solution is a complex and critical step, and for successful realization, the efforts of each party involved—business unit employees, IT, and information security services—as well as the interaction of the entire team, are important. However, the efforts are worth it: after implementing IdM, the number of incidents related to excessive privileges and unauthorized rights in information systems decreases; employee downtime due to lack of or prolonged waiting for necessary rights disappears; and through automation, labor costs are reduced while productivity of IT and information security services increases.

Source: habr.com