Every year the park of information systems of companies grows more and more, with it the tasks of managing, controlling and delimiting employees' access rights to information resources are becoming more complex with it. The presence in the market of solutions that partially overlap each other’s functionality provides fertile ground for new and new debates. How should the access control system be implemented - through integration with ITSM or the implementation of a separate IGA solution?

There are several reasons for disputes. Firstly, traditionally in companies access to corporate systems is managed by IT, however with the growth of staff and information security maturity new risks are opening up for the company. Among them, and the provision of redundant access rights, and the cost of interrupting business processes caused by the late access. As a result, it is not always obvious who should solve these tasks: IT or IS?
Secondly, if even in a company there is no division into IT and IB services, it is often just not clear which solution can close the necessary functionality for the company, which will be more convenient for administrators and ordinary employees.
')
So, there are two approaches to solving the problem:
- expand the ITSM toolkit and use its application system in conjunction with the IGA;
- use IGA as a single solution and employee self-service portal.
There is no definitive answer to the question, what is better. When making a decision, it should be understood that typical IGA / IdM specialize in automating access to key information resources of a company and perform a number of related functions. Conversely, the ITSM toolkit performs a wide range of requests for manual maintenance of system users, but does not have the ability to perform IGA functions. We will talk about the advantages and pitfalls of each of the options and try to help orient yourself with what suits your company.
Integration approach
When talking about the integration approach, it should be clarified immediately that there are generally two integration schemes for IGA and ITSM:
- ITSM system as a frontend.
- IGA system as a frontend.
ITSM system as frontend
Business challenge: a single entry point for any user requests to IT.
Implemented by embedding the application form for access to the ITSM system.
ITSM system development (form development) and availability of API (SOAP web-service or REST) in IGA system is required.
Possible options for implementation:
- Free text input form with the application clarification by the administrator directly in the IGA system. It does not require serious improvement, but it is extremely inconvenient to use.
- Formation of a full-fledged application in ITSM with the subsequent coordination in the IGA.
Pros - automate the formation of applications in the IGA.
Cons - requires full integration with the paging directories and receiving the status of the application from the IGA for display in ITSM. Reconciliation is done at IGA, and therefore ITSM is not a single entry point for terminators. They have to use frontend IdM for matching. - Formation and approval of the application in ITSM with the subsequent execution in IGA.
Pros - ease of implementation, a single entry point for all users (including and matching).
Cons - difficulties in the implementation of the coordination, tied to the content of the application. You need to build a route based on the information in ITSM, which may not be there. - ITSM implements the formation of an application, after which the application is imported into the IGA, and the approval route is formed there. In ITSM, reconciliation tasks are initiated and negotiation / rejection / delegation operations are initiated in the ITSM interface, but actually performed in the IGA via the API. The most difficult to integrate, but the most user-friendly option.
IGA system as frontend
Business tasks:
- In some organizations, according to the internal regulations, all changes in the IT infrastructure should be reflected as tasks in the ITSM system.
- Use ITSM to implement additional stages of application execution (for example, preparing the workplace) and to control access to systems for which no connector development is planned - at this stage or in general (due to the small number of users, lack of expediency, etc.).
- IGA becomes the single entry point for any access control claims.
- Provides a gradual increase in the number of connected to the IGA systems, while the application system is introduced immediately for all.
- The IGA stores information about user access in all systems of the company, even for those that are not connected at this stage or planned at all.
- The timely termination of user access in unmanaged systems is ensured when the user leaves or goes on vacation.
Implementation
Applications are generated and agreed in the IGA system, after which the generated requests for changes in access permissions are exported to the ITSM system. They can be grouped into one ticket containing multiple requests.
Requests that can be made by the connector are executed, after which the tickets in ITSM are closed.
Requests that cannot be made by the connector (or there is no connector) are awaiting execution by administrators in ITSM. When a ticket status changes in ITSM, the request is automatically closed in IGA. The administrator can enter important information in the ticket fields when it is closed, which means the need for back synchronization in the IGA.
With all this, the development of functionality will require changes in the two systems.
In addition, the ITSM class systems have some fundamental limitations:
- The inability to see the entire business process as a whole, including HR events (important when conducting audits and investigating information security incidents).
- The difficulty of determining the real-time execution of the business process of providing access.
- Limited ability to determine the basis for issuing certain rights to company employees.
- Lack of audit capability.
It should be understood that in the case of the implementation of an integration solution, it will be much more difficult to maintain or change, since there will be a need to involve two development teams, which means to coordinate the two TK, synchronize their work, budget the work in both teams. In deciding this side of the issue should not be overlooked.
On the other side of the scale there is a problem for the user: when choosing the appropriate integration option, he now needs to enter at least 2 systems or more (as a rule, the company also has a corporate EDMS). For company executives, this becomes a big enough headache. Users and IT-employees constantly ask: “Why is this necessary? Let's do all the new functionality in ITSM! ”At the same time, in many companies applications are accepted by mail / through a call center, and a fairly low percentage of users work with ITSM directly through the interface.
In our practice, there were companies where there is no own IGA interface, there is functionality as an engine, and it is really tied to application systems. However, the possibilities for changing the PSU (for example, the calculation of matching non-obvious algorithms) in ITSM are very limited.
IGA as a single solution
The obvious advantage of using only the IGA to build a user rights management system is that it automatically saves us from all the difficulties that inevitably arise when integrating with an external system.
The presence of a built-in workflow greatly facilitates auditing and allows you to see the reasons for issuing certain rights in a single window. This reduces the costs of searching and preparing information for audits and internal investigations of information security incidents, providing a holistic picture of rights in a single interface.
If the classic IdM functionality can be successfully implemented in conjunction with ITSM, then integration with IGA (in particular, the implementation of functionality to change the resource management processes and organizational structures) will require so much effort that it is actually on the verge of economic feasibility.
In fact, with the introduction of IGA in the company there is a whole range of new processes. When using the system, not only the capabilities for requesting authority should be available, but also a variety of additional services, such as:
Role | Services |
Employee
| - Current / Historical Access Reports
- Functional access request "like that guy"
- Temporary Access Requests
- Group applications
- SoD Functionality
|
Matching
| - The ability to coordinate all applications with one click or split them into parts
- Convenient analytical tools
|
IS officer
| - Ability to suspend / revoke access
- Obtaining the necessary historical data for official investigation
|
On the one hand, all these interfaces are not very complex. On the other hand, in classic ITSM, it is possible to implement fairly simple operations, but it is rather difficult to implement the gluing or splitting of applications in ITSM. What are the options here?
- We are engaged in the substitution of concepts and, speaking of integration, we simply forward the interfaces to approximately the same ITSM console. But such an approach can hardly be called full integration.
- If we start a full-fledged integration, we are faced with a number of complex tasks such as expanding the database in ITSM itself, customizing processes, etc. At the output, we get integration with IGA at the level of execution and waiting for answers, because the mechanisms themselves remain in the IGA. In addition, these works will have to be carried out in two information systems.
At the same time, business users are increasingly meeting who, although they are far from the IT world, use the IGA capabilities with interest, build momentum and use analytical tools. This means that sooner or later people will have to be sent to another interface.
So, is it possible to create applications in ITSM? Yes, it is possible, and it is quite simple. But any advanced functionality, including the coordination of applications, is better implemented in the IGA system, designed to solve these problems.
I will try to draw parallels with our real life: imagine that you are a student, study and work. To be on time everywhere, you drive around the city on your own motorcycle. It's really great, you are completely satisfied with this type of transport - quickly, easily and economically. Time passes, and now yesterday's student has grown up and got married, a child appears, and the question arises: how to move around with a new composition? Of course, you can buy a motorcycle stroller and close the requirement for transporting a child, but you must admit, such a solution can hardly be called optimal. So, it is required to acquire a car of the corresponding class.
Sight from the IB
It is also worth reflecting the view on the dilemma from the point of view of information security officers:
- Any IGA system allows you to compare the access rights that are agreed upon and actually available to the employee. To transfer this functionality to ITSM is extremely difficult. How will this look like for a safe person? In one system, he will have to look at where the employee has access, and in the other who, when and on what basis, has issued this access.
- The use of an additional integration corporate system may be associated with the risks of data substitution / distortion, unauthorized access.
- IGA is in itself a closed program, to which it is possible to impose certain requirements on integrity, limited access to the database, encryption, etc. These requirements can be extremely complex and not applicable to ITSM.
So, a small checklist instead of the conclusion:
Integration approach | IGA centralized system |
✓ Static, well-established organizational structure of the company.
✓ A classic IdM solution has already been implemented.
✓ Resources are available to implement and support the integration solution.
✓ Company regulations require that all changes in the IT infrastructure be displayed as tasks in the ITSM system.
✓ A single entry point is required for any user requests to IT.
| ✓ A dynamic company changing the CAW (you need to be able to painlessly reflect or change any schemes for approving applications).
✓ Requires functionality typical of IGA class systems (resource management processes and HSE, SoD).
✓ It is important to have convenient analytical tools.
✓ Frequent audits.
✓ There are requirements for system integrity.
✓ The company has control over the timing of the execution of applications.
|