Problems of access control based on the access list in ECM systems

In this article we will discuss the most boring interesting in IT - about software architecture, namely, about one of its most important parts - security.

We define the terms

By software, I will understand primarily the ECM system, and we will consider security only in terms of access control to the objects of the domain.

Little ECM

MS SharePoint, Alfresco are all ECM systems. In order not to consider some spherical ECM in vacuum on the one hand, and at the same time not to limit the article to some existing solution, we will invent our own simple ECM system.
')

Little about the subject area

So, let our ECM system work in the field of ensuring the workflow of some organization. The courier brought a letter from the tax to the secretary’s girl, and she brought it back to the system so that the accountant could look and generate an answer (of course, also through the system).

The head came up with a new idea of ​​optimization - and also into the system, to discuss with the approximate. May holidays coming soon? The girl secretary issues an order on non-working days. And also through the system so that everyone can see.

Slightly more formal

As can be seen above, our system works with documents, some of which come “outside” the organization, must be registered in the system and considered by the right people, some are created in the organization itself and intended for internal use, another part is also created in the organization itself, but is intended to be sent outward at some stage in their life.

Distribution of access to instances

If you look at the example above more closely, it is clear that the letter from the girl secretary about the May holidays, as well as the idea of ​​the boss about optimizing someone, are all “internal” documents intended only for the employees of the organization. But something hints that these two documents have a slightly different circle of persons allowed to view and change them. Thus, very soon we come to the conclusion that, for seemingly of the same type of domain objects, it is required to differentiate access to different instances differently .

Access Control List

So, we smoothly arrive at this data structure:



It seems that everything at once became good - now for each object of the subject area, it is possible for individual users of the system to assign different rights. But the problem immediately arises: the secretary girl yells that:

• for her to register (create) in the system a new document (object) is required to register a bunch of people in the access list, especially if the document is intended for all employees
• she began to create documents in the system also for the boss, because he stated that “the system is shit and he will not work in it”

Default Access List

We strain the cerebellum and come up with such a solution:



We find some classifying attribute for our objects, select it into a separate entity, start the “Default Access List” on it and organize the formation of the access list of our object when it is created on the basis of the default access list of this very classification feature.

The girl secretary has fallen behind, but she is screaming, infected, admin, and he complains about this:

• After the next idea of ​​the authorities to optimize someone in the organization, the admin needs to go through all the created documents with his hands and remove the optimized employee from there with his hands
• Of course, for this admin, we had to add the default access for all types of our documents to the list, which is bad - after all, the admin can also be optimized ...

Group of users

We solve the problem as follows:



We give the opportunity to unite users of the system into groups, which can also be specified both in the object access list and in the default access list. Groups can combine both users and other groups.

Admin behind us behind the secretary girl, because User groups were created in the system, and user groups were added to the default access. The admin simply deleted / added users from groups and no longer had access to all system documents.

But all the others screamed sharply, because the system began to slow down.

The fact is that there is a very reasonable requirement in the system, which is that if the user can NOT read the rights document, then he should not know about it at all , which means that the results of searches for objects in the system should be filtered based on the rights user

Of course, the programmers of our system are literate and do filtering at the database level, but still for this they had to use complex recursive queries (we remember that our users can belong to groups, and groups to other groups).

TreeSupport

What to do? We vaguely recall what we were taught at the institute and implement the mechanism for expanding the hierarchical structure into a flat one. This mechanism has its name, unfortunately, I did not remember it. Let's call it TreeSupport:



The rules for forming the TreeSupport table are as follows:

• For each Security Subject in the table, an entry is created where Parent = Child = this security subject
• For each Group, as many records are created as it has nested users or groups (recursively down to the bottom), in which
  Parent = group, Child = nested group or user

Example:

Hierarchical structure:

• User 1
• Group 1
  
  • User 2
  • Group 2
    
    • User 3
  
  

TreeSupport

Parent	Child
User 1	User 1
Group 1	Group 1
Group 2	Group 2
User 3	User 3
Group 1	User 2
Group 1	Group 2
Group 1	User 3
Group 2	User 3

Implemented? Hooray! Now the filtering of objects in the search happens with us quickly - for one join, something like this:

select Id from Object o join ACL a on o.Id = a.ObjectId join TreeSupport t on t.ParentId = a.SecuritySubjectId where t.ChildId = < > and a.CanRead = 1 

True, at the price of the fact that it has become more difficult to change our hierarchical structure of users and groups — we need to update TreeSupport. Well at least she rarely changes.

While our system is simple and unpretentious - approximately with such a structure of a security guard on the basis of an access list you can live. BUT, life, it is more difficult and very soon you can face a number of problems, the solution of which is not so trivial. Below I will describe these very problems, and my solution in the next article . Also I will be just happy to hear your opinion.

Problem 1 - Dependent access lists

In real life, domain objects, each with its own access list, are often used together as part of a business process.

I will give examples: the contract and acts under this contract, the incoming document and the document that was created in response (outgoing). When working with such objects, it is necessary to realize the requirement that if a user has access to object A, then he must also have access to object B. associated with him. Moreover, the situation is aggravated by the fact that user access to object B will often be rights is not equal to access to the object A.

Problem 2 - Delegation of Authority

Or another scenario - the user is the head and he has alternates. Therefore, all objects to which he has access must automatically be available to his deputies with the same or with limited rights.

Problem 3 - Providing access to a large number of objects

A very frequent situation when a user worked, worked with the system for a couple of years, appeared on the access list, for example, in 100k objects, and then ... left.

Another person has been appointed in his place and now he must have access to the same objects as the one who left. In order to provide him with access to the same objects - we have to start a long process consisting in enumerating all the objects and modifying their access list (taking into account dependent objects, substitutes, etc.).

Often this process takes a very long time. And in some scenarios - unacceptably long.

Manual edit access list

And finally, a comment about the idea that directly suggests itself - but let's just make the user edit the access list himself. So - it does not work.

Access list - this is the thing that 99% of the time working with the system should be hidden from the user. Therefore, all modifications of access lists when implementing typical scenarios of working with the system should occur automatically. And the architectural solutions behind the solution of the above problems absolutely should not affect the filtering speed of objects during searches and should have minimal impact on the speed of performing operations on objects and lists of objects (including large ones).

As I wrote above, I will be just happy to hear your thoughts on how to solve these problems.

UPD : Next article