This article explores important considerations for implementing IdM systems such as implementation processes, role-based access management model, and existing IAM services for processing and managing user access.
How to form the concept of the project
Let us start with the basic questions that arise at the initial stage of cooperation between the IdM vendor and the customer.
What is the scope of the IdM system implementation project? Should it be as extensive as possible, carry more value but assume a long implementation timeline, or should we focus on the most important tasks that involve rapid implementation?
The scope should demonstrate to the customer the future value of the IdM system implementation. We are talking not only about the top management of the company and employees of the department who are direct recipients of the final solution but also about other departments. Implementation costs are borne by the entire company, so the effect should be clearly visible to all people; otherwise, full personnel involvement can hardly be achieved.
To participate in the implementation, employees of the customer who are not related to IT and information security need to be interested and motivated. The vendor should show them the benefits that they will receive after the implementation of the project. For example, it is advised to include in the project’s automation opportunity of routine operations that are currently being performed in manual mode. This way, the effect of IdM implementation will be more noticeable.
Also, we must not forget that a user friendly web portal, the ability to build clear reports, and other visual aspects are important parts of the implementation. When defining the scope, it is impossible to consider only the technical parts of the project.
The first stage of implementation should include a small number of systems that provide maximum value for the customer. Initial small coverage of the core systems will bring enough benefits to users and administrators.
What IdM implementation approaches are the most promising
How much should the customer and the vendor formalize the implementation parameters? Do you need a strict technical assignment, or is a flexible approach acceptable? How to reconcile the need for changes discovered in the process of project implementation with the initially defined financial and technical parameters?
According to experts, a flexible approach to implementation requires a high level of trust between the vendor and the customer. It is very important to clearly define the project’s boundaries so that it does not turn into an uncontrollable and endless process. You need to clearly define and fix the final goal for the customer and labor costs for the vendor. One of the options is to conduct an agile session/meeting before finalizing a contract in order to determine all technical parameters more accurately.
The implementation process should not be vague for the customer, regular meetings are needed where the parties could discuss the status of the project. Such involvement of the customer representatives will allow them to influence the course of work and will allow the vendor to adjust to a certain extent the expectations of the other party.
When working on the technical requirements and specifications, the vendor must constantly keep the dialogue with the customer and be ready for changes. Usually, it is good to break the implementation process into stages to provide the project with the necessary flexibility without losing sight of the ultimate goal.
A clear technical assignment is needed at the first stage. It is needed to participate in the competitive bidding process and form an initial “scope” that will show the customer the key benefits of your solution. In the future, as trust between parties grows and customer engagement increases, you can try and use informal cooperation.
Method of work can also be determined through a pilot project, during which the customer and the vendor can get to know each other better.
Once again, it is important to emphasize the importance of customer involvement. The client’s team should not remain an outside observer of the implementation process, since they will have to manage the ongoing maintenance of the system.
Is it possible to implement an IdM system without a ready-made role model?
Are there any chances of successful IdM implementation if the customer does not have a developed role model? Is it possible to automate chaos? Is it possible to build the role model during implementation?
Some experts advise starting with a description of the main HR functions – hiring, firing, moving around. This will ensure a good and speedy start for IdM implementation. Further development of the role model and the description of all the business processes can be performed as the project progresses.
Creating a complete role model will require a lot of resources and can significantly increase the time and cost of a project. In addition, the role model often becomes outdated the day after it is agreed upon. There is little point in fixing it at the beginning of implementation. Sometimes it can be convenient to build the role model around the ready-made IdM toolkit, which will allow you to always keep the role model up to date.
How to build a role model
How should the process for defining roles be structured? Should this process be based on historical data and analysis (Role Mining) or business insights obtained through executive surveys, job descriptions, and other tools?
Actually, the best results are obtained by the symbiosis of several methods. Historical data provides insight into the current access matrix, while executive surveys provide insight into how it fits the company’s rights management goals and objectives. Existing permissions on the level of departments and individual employees should be discussed with the owners of business processes in order to cut off unnecessary privileges and, possibly, add new roles.
In order to avoid misunderstandings between the vendor and the customer, it is recommended to negotiate in advance at what stage, by whom, and at whose expense the role model will be created. Role Mining is not a magic button that will help eliminate all the problems, but only a starting point for building a role model.
It is also important to understand how deep the vendor can dive into role management and where the project boundaries lie. For example, should its scope include setting up roles in SAP or another system used by the customer?
The success of the project depends on how well the customer’s employees are trained to create a role model. It is also important to understand that there is no universal method for building a role model. What works for a bank will not work for a manufacturing company. The size of the organization also plays an important role – the smaller the business is, the easier it is to build a role model.
Client side
How are the portals for processing requests organized? Which toolkit is better to use for this built-in IdM tool (like the IT Shop module) or an IT service management (ITSM) portal that the customer has already implemented to process user requests?
These questions can be approached from the point of view of user convenience. If the company has a well-developed service desk (toolkit for working with user requests), which receives requests from disparate systems, then it may be better to integrate the functions of the IdM portal there. When there is no such tool, it makes more sense to use a separate IdM web interface. The process of access granting in Identity Manager can go in two ways:
- Built-in IdM system algorithms.
- Built-in algorithms of the external system (not necessarily of the service desk level) with the transfer of the final result to IdM.
It often happens that it is more convenient for the vendor to use the IT Shop, which is part of the Identity Manager, since this way, the vendor can independently develop this portal and be confident in its functions. On the other hand, if the customer has already built an ecosystem of his business processes around a specific service desk, then it is hard to transfer it to the portal of the IdM system.
Of course, it is more convenient for users to have a single service for processing requests; therefore, implementing it through IdM, you may have to duplicate some of the ITSM functions.
The implementation of the portal for processing requests using the IdM system allows you to link the processes associated with access to the events of the HR system, for example, the reassignment of the responsible person in case of dismissal.
Publishing an IT Shop on the Internet makes sense only if business executives regularly need to access these coordination tools. Ordinary users do not need such an opportunity. The only thing that an employee may need from the outside is to reset the password; other access issues when working remotely are solved using a VPN. Another aspect of this problem is the external user registration portal. Make sure to protect it from attackers as phishing, web injects, redirects and other hacker tricks are on the rise. It makes sense to make it as a separate, protected replica of the general interface with limited functions.
Integration
What are the nuances of connecting IdM systems with other solutions used by the customer? Should synchronization with the HR system be event-driven or done with regular intervals or in real-time?
Often, regular synchronization is not much different from event-based synchronization, since events are also piled onto the stack, which is processed at a specified frequency. It is technically possible to implement event-based synchronization in real-time. Still, the use of a queue makes it more convenient to handle numerous user requests, which often happens in large organizations. The less often HR events are processed, the less the risk of transferring an unfinished operation to the IdM system.
Of course, there may be some urgent events (for example, an unplanned dismissal of an employee) that need to be communicated to IdM promptly. For this purpose, there is a specific user blocking option. Customers often want everything to be in real-time; it is possible to explain that they do not need it.
The frequency of contacting the HR system by the IdM system should be set for each organization separately. One of the factors is the load on the HR system. In practice, there are examples of using an intermediate database, which collects information from several systems, for later uploading to IdM.
Continuing the topic of linking IdM with other systems, it is necessary to touch upon the issue of implementing risk and compliance management functions. Such projects are rare. If the customer has already implemented a GRC system, he will most likely refuse to transfer its functions to IdM.
When it comes to integration with other solutions, such as SSO or PAM systems, a properly designed IdM can facilitate the implementation of such solutions. If the customer has not yet implemented SSO or PAM, then it is reasonable to build an architecture for two solutions together and implement them one at a time.
Conclusion
Here are three main advantages of implementing an IdM system. They can be used as a justification for the need for such a solution for the customer.
- Reducing the cost of administering access rights by automating routine operations.
- Quick employee onboarding, reduction of downtime associated with registration of a new employee.
- Increased security by reducing risks (unnecessary rights, access rights left after employee dismissal, etc.).
