Geekly Articles each Day
📜 ⬆️ ⬇️

We introduce IdM. View from the implementation engineer


Earlier we talked about what IdM is, why it is needed , how to financially substantiate its implementation , etc. Today we will talk about what pitfalls may arise during the implementation of the system, and how to get around them and not get yourself a lot of cones. Suppose we know that in our company there are some problems that we could and would like to solve using IdM. The solution to these problems in our company is economically justified, since it will seriously relieve the IT department, increase the performance indicators of the company as a whole by saving time and resources needed to prepare the workspace for new employees, and coordinating and managing the powers of the old ones. And IS employees after the introduction of IdM will be in the seventh heaven, generating a ton of various reports on the button, which greatly simplify their lives when conducting security audits, to the delight of themselves and management. And the decision was made - “Take!”.

We formulate functional requirements


The first thing to do is draw up a document called “Functional Requirements”. I think the importance of the availability and literacy of the contents of this document is beyond doubt. Ideally, he should be ready before choosing a specific solution. It is clear that during the pilot testing and during the pre-sale events many times, different people were discussed and explained what needed to be done. Nevertheless, the scope of the project should be clearly defined and fixed on paper. Functional requirements are a kind of starting point from which mutual understanding will be built between all participants in the process both from the customer and the contractor.

The required system functionality must be logically and financially justified, implemented and consistent with its capabilities. In essence, this is a top-level description of business processes that need to be automated through the implementation of IdM.
')
Consider a simple example for clarity. Imagine that you need to automate the following personnel processes:


In the Functional Requirements for the New Employee Acceptance process, it is worth writing the following: the system reads information about the new employee from the personnel system, creates an account in Active Directory (AD), assigns the groups required by position, creates an account in CRM, assigns a profile and roles in accordance with official duties.

There is no need to enter there the requirement to brew coffee to the CEO when he enters the office. This is not an IdM functionality, although with an API, the coffee maker is realizable too :)

We draw a diagram of the interaction of system components


At this stage, in addition to the actually automated processes, the main integrable systems are identified, the interested departments are identified, the global IdM place in the internal information environment of the enterprise is pretended. The resources needed to support IdM are also determined, the scope of the project becomes visible, the stages and dates of implementation are approximately determined.

So, we realized that for the implementation of these automated processes in the first stage, you need to integrate with only three systems:


You need to immediately imagine the interaction scheme of the components of the future system.

As you can see, IdM is at the center, and this is no coincidence. After implementation, IdM will be the “alpha and omega” that contains all the relevant information about the company’s employees, all their accounts in IdM-integrated systems and what roles, groups and authorities employees should have in these systems. It is thanks to the "tentacles" of IdM that penetrate all the systems connected with it that the transfer of Ivanov Sergey Petrovich from the accounting department to the legal department of the company automatically registered in the personnel information system will automatically change the groups and attributes of his account in AD and change his roles and profiles in other company systems, with the automatic launch of all the necessary approval and notification processes. But all this will work only when all the components of the system are well and correctly integrated with each other. And to make this happen, I repeat, you need to carefully think through and design everything.

With this baggage we go out for a purchase.

So, the IdM solution has been selected, the implementing contractor has been determined, licenses have been purchased, work has been paid for, and it is time to implement it. We will talk further about how to make sure that all good undertakings do not die, without really being born.

We create a project team and do a pre-project survey


The first thing to do immediately after buying IdM (apart from the solemn raising of the glass for the deal) is to create a project team. Yes, the project team on the part of the customer must be. The success of the whole event depends on its composition. It should include representatives of all interested departments that have the necessary and sufficient powers to quickly resolve various issues of a predominantly technical nature that arise during implementation.

Next comes the time of the pre-design survey - the most important stage, requiring a great immersion in the design activities primarily from the customer.

Here, the very necessary and sufficient powers of the participants of the customer’s project team will be required to collect and provide the contractor with all the necessary information about the internal structure of the company's processes. It is about the internal structure of the company's processes! Each automated process described in the Functional Requirements needs to be thoroughly investigated from start to finish. Who carries out the initial collection of information, its composition and format, in which system the information is entered, in which it is transmitted, how, by which protocols, using which software? Who needs this information for further activities, and in what form they need it, where there should be traces of the operations performed ... In a word, everything, everything, everything that relates to each investigated process.

We write TK


At the output of the pre-project survey, another document important from the point of view of implementation (even more important than the Functional requirements) should be obtained - the Terms of Reference (TOR). What should be in it? It is important not to miss anything and carefully think through everything. Because the omission of small and seemingly insignificant nuances can result in big problems during implementation.

In this regard, when designing an implementation solution in TK, the first thing to do is to thoroughly work out the automated processes themselves. Almost the same as in the Functional requirements, but in more detail, with specifics, covering the entire life cycle of the information coming into the input of each process until it comes out.

For example, the personnel process. Admission of a new employee in the ToR will look like this:

  1. An HR clerk enters information about a new employee into the 1C: ZUP HR system. It fills out the following fields without fail: ... (it is listed which ones).
  2. IdM receives data about a new employee from the personnel system 1C: ZUP, determines the position and unit of the new employee. Creates a new employee profile in IdM. The login is formed according to such and such rules, the password according to such and such. The login information for the new employee’s password is sent there and there via such communication channels (indicate where IdM gets the address from).
  3. IdM automatically creates an account in AD with the attributes (list) in the directory (OU - Organization Unit) corresponding to the new employee’s unit. The login is formed according to such and such rules, the password according to such and such. The data on the login and password of the new employee is sent there and there via such communication channels (indicate where IdM gets the addressee from, and the parameters of the communication channel).
  4. The created AD account is placed in groups (we list or indicate "according to the role model"). The role model will also need to be thought out and described in a ToR in a separate chapter. The appointment of such groups is carried out in agreement with those persons (we list). The system generates notifications on the assignment of authority to a new employee (we specify the recipient identification algorithm; separately describe the approval routes), as well as reminders to the coordinator about the need to coordinate the application (we specify the recipient identification algorithms, the beginning, end and frequency of reminders).
  5. After creating an account in AD, IdM initiates the creation of an Exchange mailbox for the new employee. Information about the new mailbox is stored in IdM and displayed on the employee’s card.

In approximately the same vein, we describe the interaction of the system with CRM ...

Thus, during the consideration of automated processes in this way, the object model of each system, the composition of the attributes of each type of object becomes clear, a picture of the movement and transformation of data between the attributes of various objects is formed. Also, connections between objects become visible, additional processes are revealed, such as maintaining data consistency in all systems.

A simple example: when changing the name of the employee in the personnel system, his name must change in the profiles of all other systems connected to IdM. But it may not change, because in some systems the name is simply not stored.

An example is more complicated: the requirement is that the AD account of a new employee must be created in the OU corresponding to his unit. The question arises, what to do if a new unit is established in the personnel system, but it has not yet been created in AD? Thus, a separate process of reproducing the organizational structure stored in the personnel system in AD is revealed, which is also worth describing in the ToR.

Integrates with systems


As you can see, the formation of TK is an iterative process. After defining the objects and actions that need to be performed with them, it becomes clear the set of functions that must be implemented in the connector to the integrated system. And then we smoothly approached another important stage of IdM implementation - the actual integration with systems . In truth, this stage can be very painful for both the IdM integrator and the company in whose infrastructure IdM is being implemented.

So that nothing bad happens, you need to understand a few general principles that apply when integrating various software products. First, you need to understand the importance of having an API in an integrated system to integrate with IdM. Connector and API are two different things. If the integrator says that he has connectors to various systems or is ready to write a connector to any system, this does not mean that the integration problem is completely resolved and the client company does not need to do anything about this.

I will explain with an example. In order to connect a power plant with an iron in order to heat the latter in order to fulfill its known functions, it is necessary that the power station has a socket and the iron has a plug. Socket and plug. 2 things. Not alone. Using an outlet on the side of the power plant and a plug on the side of the iron, the iron is integrated with the power system. In the case of IdM integration with any other system, 2 things are also needed: a connector on the IdM side and an API on the system side. It is important! Otherwise, various unpleasant incidents may occur. The purpose of the connector is only to receive the necessary data from the system in the form in which it sends them, and transfer them to IdM in the form in which IdM can receive them. The same connector does in the opposite direction: it receives a command and a data set from IdM in the form in which IdM issues them, and transfers all this to the system in the form in which the system understands what it needs to do. BUT! The system should, in principle, be able to produce the data necessary for IdM and perform the necessary commands to work in tandem with IdM. This is the main purpose of the API - to provide an interface that IdM can act on with a connector to perform various operations on the system.

Usually, even before the sale of IdM, a conscientious integrator focuses on the need for the customer to provide an API for all systems connected to IdM and reports the requirements for the implementation of these APIs. This is essentially an enumeration of functions with input and output parameters. For example:


That is, an API is a set of functions that are needed to interact with IdM. The problem is that part of these functions in the system may not be implemented in the right form at all. Just because this was not yet necessary. Part can be implemented, but as a complex, multi-level, step-by-step process. For example, in one domestic banking automated system, creating a user account is preceded by filling out three different directories with a bunch of auxiliary attributes and flags. Or, some functions can be implemented in a simple form, but not published, that is, functions cannot be used from the outside. So the API is designed to solve all these problems. APIs are functions that perform the operations necessary for the integration of an integrated system with IdM, in the correct, correctly working form, published for their external call. So that any software engineer who does not know the internal kitchen of the system itself can use them and easily do what is needed.

Further, customers usually have a question that causes a nagging toothache for the IdM implementation engineer: why can't the IdM integrator implement the API to the system on its own?

Imagine a complex enterprise management system, in which user rights management must now be implemented using IdM. Vendor wrote this system since the 90s. Over a long life, its architecture has changed four times. The user rights management subsystem could not keep up with the rapid development of the functional of the system itself and was implemented by several generations of programmers according to their not always logical and reasonable understanding according to the principle of “how to figure it out”, that is, in a crutch way. There is no need to talk about documenting all this action. At the moment, everything is somehow working. The vendor’s employees climb into the old code of their system with reluctance and apprehension only in case of urgent need to edit some terrible bug, baptizing three times and sprinkling the monitor with holy water, overlaid with tambourines, so God forbid not to break any crutch, so that everything does not fall .



And now the customer company using this magical product has come the golden time to implement IdM. API requirements provided, no API. The customer doesn't care who writes the API. He banged his fist on the table with the words “I’m crying huge millions, do it” and left the meeting, deliberately slamming the door. The vendor of magic software also doesn't care. He’s not going to do anything for free, but they forgot to put money into the budget for the implementation of the API for vivid rainbow dreams about how everything will be cool after the introduction of IdM. At the same time, the contract is signed, “the money has been paid”, and the wild leapfrog begins.

Poor Pasha-programmer, an employee of IdM’s integrator, is trying to convulsively understand what squats must be done to get normal reactions from the system. It studies public sources, stingy, outdated documentation, understands the source code of an unknown system and breaks the vendor’s phones. After a couple of weeks of ordeals, he realizes that squats are not enough, bouncing is needed, and even somersaults, and not the fact that this will help either ... And after a month, a connector appears, some kind of one, more or less working. Slightly malfunctions, well, how it happened. Poor Pasha-programmer on the staff of the integrator turned gray while writing it. The magic system is integrated, but the problem is that the accounts are not created very correctly, and the system administrator must manually “roll back” the account to the working state. Passwords change every other time, and the “lucky” Marina Ivanovna from accounting keeps blocking her account. Employees of the "business" flood technical support with vicious complaints: "How long ???", "Impossible to work!", "Do as it was ..." At first, the customer demands to fix everything and hits the table with a slipper so that it reaches the already bald-headed Pasha programmer. Then, due to frequent failures and growing dissatisfaction of business units, the integration of IdM with the magic system is abolished.

And what will you do here? Who is guilty? If not a system vendor, then who should sort out all the chaos that he has done from directories, functions, plates, triggers, flags and crutches? IdM integrator? How does he know how to correctly implement a function in a system that a vendor cannot figure out? And if it can, then for some considerable money? Yes, I am now thickening up colors; there are exceptions when the system is not very complex, and you can integrate with it without a special API. But be reasonable. If the goal is to avoid unnecessary problems, help the business grow and make a profit (which, in my opinion, is the main goal of the IT department in any company) and enjoy the smooth operation of all systems, think about ways to integrate with the systems. Put in the budget the necessary costs for the study of integration opportunities and the competent implementation of the missing components. Avaricious pays twice, or even thrice. Save in the end Pasha-programmer: D. He's almost bald. And do not forget to consolidate the methods of integration in TK!



We build a role model of the company


I would also like to draw special attention to the formation of the role model of the company . The fact is that each system has its own exclusive set of so-called "authoritative" entities - objects that provide user privileges in the system. All kinds of groups, roles, profiles, purposes, directories, privileges, types of operations, etc. can be attributed to this category of objects ... Granulation of rights can be very deep, as a result we get an immensely huge number of managed objects. For example, some security groups in AD can be several hundred, or even thousands. In some financial management systems, each user can be assigned exclusive rights to each account out of a million contained in the chart of accounts. And if we integrate with SAP? The number of atomic rights can be measured in hundreds of thousands and even millions.

In addition, hierarchical nesting and complex relationships between different types of authorized entities can be supported in the system. This in itself draws on a separate study of the possibilities of managing user rights in the system. Therefore, before designing the implementation of IdM in your home, it is imperative, based on the objectives of the project, to determine which rights and at what level of granularity you are going to manage through IdM. The main thing is to stop in time. In everything there must be necessity and sufficiency. If you want to manage separate user rights for each account in the system, get ready for the appropriate amount of work to coordinate and revoke user rights with each change in the chart of accounts.

When working on a role model, you must determine:


In the dry residue


Well, perhaps it's time to round off. There is much more that I would like to talk about: on the differentiation of access rights, on the quality of test environments, and on ways to ensure fault tolerance. There is only one conclusion: high-quality development of the solution at the design stage is 50% of the success of the entire enterprise. Early documentation of such requirements will help to implement automation of all processes with minimal costs and losses in the form in which you need it, and not in the way the integrator sees in his mind. This will significantly speed up the IdM configuration process, make the program logic transparent at the stage of its operation and support.

Do not be shy and most importantly do not be lazy to understand everything. And we will help you with this.

Posted by Maria Tyurina, Solar inRights Implementation Engineer

Source: https://habr.com/ru/post/461181/

More articles:


All Articles