About the domestic bicycle industry – an access control system for a low-code platform

When looking for a solution to this problem, we started from the chosen approach to implementation, according to which each patch is not only a cover for workflow sections, but also an agent in related information systems. This will allow you to get access in a single window not only to those processes that are covered by the patches of the platform, but also to those adjacent to them, implemented in other systems. Access can be realized in the following ways:

1. Calling api methods of related systems;

2. Direct reading/writing from/to the database of related systems;

3. Access to the functionality of related systems by placing links to their user interfaces on a single desktop while maintaining external user sessions.

Also, as an access option, it is possible to replace obsolete sections of the processes of adjacent systems with shreds.

So, the first thing we have to design is the optimal structure for storing information about access rights, which allows us to bring data similar in purpose from other systems to it. At the same time, the structure should allow a relatively fast search through it.

We looked at several fairly different implementations (options ACLsharing-based access), and eventually came up with the following rather abstract structure:

1. Hierarchical directory of subjects. The subject can be a group or an individual user.

2. Hierarchical directory of objects. An object can be a section, a form, a form component, an api method, a record, a field.

3. Directory of possible actions on objects. Defined for each type of object.

4. Table of rules for subjects’ access to actions on objects. It also contains the priority of the rule.

Initially, the entire system is closed, there are only allowing rules.

Subject and object hierarchies are needed to facilitate the process of assigning rights and to avoid data duplication. If child nodes do not need different permissions than their parents, data is stored only for the upper levels.

We also provided the possibility of breaking the inheritance of rights for objects by specifying the appropriate attribute – to isolate the rule from its parents within the priority.

Rule precedence is necessary for some cases, for example, if we want to give permission to the admin to the very root, and do not want child nodes to be able to ignore these rules.

When an actor tries to perform an action, rights are searched and calculated at different priority levels. At each priority are all the rules in the hierarchy, from the object in question, up to the inheritance break. From the objects of rules collected by hierarchy, the ones that are appropriate in terms of subjectivity and type of action are selected. The next step is to sum up all the permissions that the actor can obtain for the action type in question.

End users and platform designers should be able to delegate rights to objects manually or automatically by creating new rules. For rules created manually, the author must be stored – in order to be able to cancel the delegation of rights in case of, for example, an error.

To simplify the process of implementing this system into work, it is necessary to develop:

1. a mechanism for importing data about subjects from ActiveDirectory and similar authentication systems.

2. interface for quick filling of the object directory both from the platform itself and from available related systems.

In total, in order to obtain all the functions necessary for the user in one window, it is necessary to supplement everything listed with a mechanism for obtaining and applying data from user sessions of related systems. The data will be used for automatic authorization when following a link from the desktop to external interfaces or calling an api.

We will talk about ways to ensure the information security of this structure in one of the following articles.