Problems of access control based on the access list in ECM systems (part 2)
In my debut article, we step by step designed a model for delineating access to the subject area, taking as an example a fictitious ECM system, which from the simple gradually became not very simple. We faced problems that could not be easily and simply solved within the framework of the model that we had as a result. In this article we will try to correct the situation.Let me remind you the list of problems, with the short we are faced
- Problem 1 - Dependent access lists
- Problem 2 - Delegation of Authority
- Problem 3 - Providing access to a large number of objects
A small theoretical retreat
“There,” as well as “here,” is very fond of inventing bicycles. But "there" for those who like to reinvent the wheel are those who like to count money. Therefore, instead of inventing bicycles "there", they do classification and standardization.
With regard to access control, various access control models are classified according to two “parallel classifications”.
')
MAC (Mandatory Access Control) - if access to objects is configured by the administrator declaratively, but not by the end user of the system.
DAC (Discretionary Access Control) - in that case, if the user himself sets up access to the objects (to those objects of which he is the “owner”)
Multilevel - if the access is configured in relation to a certain “access level”, and the objects are already marked with some sign that determines the necessary access level for working with this object.
Access Matrix - if the access is configured directly between the object and the security subject. A particular case of this model is the subject of our suffering, i.e. access model based on Access Control List (access list). And there is another special case - the access model based on Capabilities. They differ in that the ACL is a list of those who have rights in relation to a single object, and Capabilities (or C-List) is a list of objects with access rights to them in relation to some security subject. comparison 1 (eng) , comparison 2 (eng)
Role-Based Access Control (RBAC) - if the access is configured in relation to user roles, combining the ability to perform various functions of the system with the rights to security objects. There is a standard for this model.
Attribute-Based Access Control (ABAC) - if the access is configured in relation to ... no, not to the attributes of the objects. And in relation to objects with some kind of sign. A typical example of access control on the basis of ABAC: the manager Petrov automatically gets access to any contracts, but only if their Amount is less than 100k.
Against the background of all this, a term such as Access Control Session , which periodically smears RBAC, ABAC, and which, in its free interpretation, means that the security subject may have several privileges, but to perform a specific operation, is still hanging out. only one set is allowed, for which this operation is performed as part of a security session with which it is set and associated.
Now let's see what kind of security models are used for our simple ECM system involved in (reminding) the organization’s workflow (well, you already understand that they will not be there alone).
So:
In general, the hodgepodge.
From all this, I have only two thoughts:
With regard to access control, various access control models are classified according to two “parallel classifications”.
- By who controls access to objects
- Based on what controls access to objects
')
According to the first classification, the model can be called
MAC (Mandatory Access Control) - if access to objects is configured by the administrator declaratively, but not by the end user of the system.
DAC (Discretionary Access Control) - in that case, if the user himself sets up access to the objects (to those objects of which he is the “owner”)
According to the second classification, the model can be called
Multilevel - if the access is configured in relation to a certain “access level”, and the objects are already marked with some sign that determines the necessary access level for working with this object.
Access Matrix - if the access is configured directly between the object and the security subject. A particular case of this model is the subject of our suffering, i.e. access model based on Access Control List (access list). And there is another special case - the access model based on Capabilities. They differ in that the ACL is a list of those who have rights in relation to a single object, and Capabilities (or C-List) is a list of objects with access rights to them in relation to some security subject. comparison 1 (eng) , comparison 2 (eng)
Role-Based Access Control (RBAC) - if the access is configured in relation to user roles, combining the ability to perform various functions of the system with the rights to security objects. There is a standard for this model.
Attribute-Based Access Control (ABAC) - if the access is configured in relation to ... no, not to the attributes of the objects. And in relation to objects with some kind of sign. A typical example of access control on the basis of ABAC: the manager Petrov automatically gets access to any contracts, but only if their Amount is less than 100k.
Against the background of all this, a term such as Access Control Session , which periodically smears RBAC, ABAC, and which, in its free interpretation, means that the security subject may have several privileges, but to perform a specific operation, is still hanging out. only one set is allowed, for which this operation is performed as part of a security session with which it is set and associated.
Now let's see what kind of security models are used for our simple ECM system involved in (reminding) the organization’s workflow (well, you already understand that they will not be there alone).
So:
- The user can customize access to documents, especially if he creates them. Therefore, our access model clearly refers to the DAC.
- The administrator declaratively configures access to documents (recall the default access list), because the user MUST NOT set up access by himself in 99% of use cases (I wrote about this in the first article). Therefore, our access model clearly applies to MAC
- Access is configured based on the access list, so our model refers to the Access Matrix, in particular to the Access Control List
- Such attributes of documents as the “access stamp”, “confidentiality”, which also affect access, climb from the subject area - as a result, our model will also apply to Multilevel . And the distribution of access through the ObjectKind classifying attribute from the first article is of the same type.
- And of course, the role. Where do without them and where are they not? And there will be in our system too and therefore the security model will also apply to RBAC
- And do not forget about the delegation of authority. Because this script requires consideration in our model and Access Control Session
In general, the hodgepodge.
From all this, I have only two thoughts:
- The architect simply has to do everything to minimize the number of access control patterns that the specific system model will support.
- How can I not write bikes, I personally do not understand ...
Basic layout
To correctly solve our above mentioned problems, let us go back a little, to the very first picture
The current schema contains an access list for each domain object.
From the theoretical part, we have already understood approximately what patterns of access control should be supported by our security model.
Therefore, we will increase the degree of abstraction. In an ACL, we will not specify a list of security subjects with their rights, but a list of access models applicable to this object. In this case, the primacy of the ACL model over all others will be supported by the observance of the axiom - we must always be able to access the object calculated solely on the basis of its ACL .
So, we change the scheme as follows.
Hereinafter is the class schema, not the database schema. We will deal with the issues of mapping class classes on the database later ( in the next article ). White closed arrow is inheritance. An open arrow is an association.
As you already understood, the list of access to documents has degenerated into a hierarchical list of supported by the SecurityAspect object — abstract access granting mechanisms. SecurityAspect implemented by us using the Composite pattern.
Please note that I did not specify an intermediate entity for the Composite pattern for many-to-many connections between SecurityAspectComposite and SecurityAspect. In other cases (not related to the Composite pattern) I will indicate such intermediate entities.
I also draw attention to the fact that SecurityAspect does not refer to Object . On the contrary, Object contains a reference to the root SecurityAspect, which will (along with its hierarchy) determine access to this object.
In the future, the root SecurityAspect object (along with its hierarchy) I will call ACL in the old manner.
Users
From the theoretical part (and from our requirements set forth in Problem 2 ), we realized that a system user may have several sets of privileges, and only one set should be active at a time.
A simple example is if a system user can work on his own behalf, on behalf of a boss and on behalf of a very large boss (typical secretary’s work scenario) - the business logic of the system will quickly come up kirdyk, if at any given moment it is not clear on behalf of whom the user is doing other action in the system.
Reflect all this on the diagram.
As we see, each user can have a set of associated Principal , which can form hierarchies (also with the help of the Composite pattern). For clarity, we have introduced specific implementations - Principal for org. organizational structures.
In addition, Session is also present on the diagram, which, in addition to the reference to the user, also refers to the Principal on whose behalf the user is currently working.
Access in the future we will provide not to users , but Principal 's. This makes it easy to implement replacement scenarios (problem 2) .
Direct access to objects
Now let's cross these two schemes and implement direct access to the objects through Principal’s .
We have created a descendant of our SecurityAspect with the name DirectAccess , which has both a list of rights in relation to the object, and a link to the Principal , for which these rights are actually available.
Note that, unlike the data model in the previous article , the rights in this model are not attributes, but are separated into a separate Right entity that is associated with DirectAccess through DirectAccessRights . This will allow us to expand this set of rights in the future without serious consequences.
Roles
As I promised earlier, there will be roles in our system too. We realize
As we can see, a new SecurityAspect has been created with the name Role , which can combine hierarchically other SecurityAspect's (as inherited from SecurityAspectComposite ).
Since roles are most often used for declarative assignment of rights and will not be indicated in the ACL of objects (although our model does not prohibit this), we need to ensure communication between roles and principals. We do this with PrincipalSecurityAspects .
In more detail about the use of roles:
- They can be used both to provide access to system functions and to provide access to system objects.
- In the first case, in our model, the necessary roles will be simply created with the necessary set of rights, not equal to those rights that will be used to access the objects, and these roles will be assigned to Pricipal in PrincipalSecurityAspects
- In the second case, in our model, the roles will also be entered, the PrincipalSecurityAspects will also be assigned to the Principal and, in addition , in the ACL of those objects for which these roles are applicable. The set of rights used in roles in this case can be equal to that used in DirectAccess
The most important:
- In the classic RBAC, in the essence of Role there should be a connection between it and Object through RoleRights
- Since we do not have RBAC, but ACL dominates - this connection is absent and therefore, if necessary, provide access to objects through roles - they must be registered in the ACL of the corresponding objects
Default access
Let's implement the Multilevel security model, i.e. distribution of rights on the basis of any feature of the object. Let it be ObjectKind .
As you can see, ObjectKind has started to have objects that have a classification feature and a new successor from SecurityAspectLeaf (which hints that it cannot contain a hierarchy of other SecurityAspect) has appeared with the name ObjectKindAccess . The connection between it and the Principal is also provided as in the case of Role through PrincipalSecurityAspect .
The most important:
- In the classic Multilevel, the Object entity must be marked with a classifying attribute to distribute rights to it, and that’s all
- Since the ACL is primary for us, for those objects for which the Multilevel model must work, the corresponding SecurityAspect must be registered in the ACL
Dependent access lists
And finally, we still have problem 1 with dependent access lists .
Let me remind you that the objects, each with its own access list, participating in one business process, should often be available to all participants in this process. Those. if a user has access to object A, then he must also have access to object B (usually with a limited set of rights).
We realize
As usual, we created a new successor from SecurityAspectComposite named LinkedAccess .
The trick is that this SecurityAspect will “wrap” the root SecurityAspect of the associated object , thus giving access to all those who have access to it, and to the current object. The rights defined on LinkedAccess through LinkedAccessRights will either restrict the rights of having access to the associated object, or expand their set of rights (depending on the requirements of the business logic).
What's next
In the next article we will deal with mapping of all this on the database, given the mandatory requirement of the first article.
“The architectural solutions behind the solution of the above problems should definitely not affect the filtering speed of objects during searches and should have minimal impact on the speed of performing operations on objects and on lists of objects (including large ones).”
What to read
Design Patterns for Role-Based Access Control
Patterns and Pattern Diagrams for Access Control
Patterns for Session-Based Access Control
Source: https://habr.com/ru/post/278031/
All Articles