The system of separation of access rights in a web application - part 1, theory
At the moment, my small team of two people is busy developing a CMS. I imagine about how many of them already exist, but I want to make my contribution.
Below I want to share thoughts about the system of separation of access rights in the CMS. It seems to be very original and interesting.
Thinking about implementation, I set the following goals:
As a result, I came to the conclusion that the most suitable analogue is the mandatory system of access to files in unix. The one that is 777. :) Naturally amended for web orientation - instead of directories, we will have categories, instead of files, different web objects, etc. Everything below.
')
In the most general approximation - the system will store a table that will contain the identifiers of all objects, and access rights to them.
Technical problems (for example, the heterogeneity of object keys, the use of the system at the discretion of the developer), as well as optimization, will be discussed later. While we go on the strategy.
Each object will have an owner-user, an owner-group and a number that will describe what to do with this object. In unix-systems, this number contains 3 digits to describe the rights
We will have one more digit:
Now for the more interesting. In the operating system, as a rule, there is enough control over all three operations - reading, writing, execution. Plus a couple of extra flags.
Our situation is more complicated - there may be many other operations that need to be controlled. The description of the read / write / execute rights is not enough. For example, on a website with ads, the user can change his ad, but can not upload photos to it. This opportunity opens after payment. Or the ability to download the attached files - it must also be controlled.
It turns out that, unlike the OS, where only three operations — we have the number of these operations — are potentially unlimited. There are many of them, and in addition, they can vary from application to application. And yet this is a beautiful solution.
Each digit can be divided into upper bytes - the most standard operations for all objects, as well as some part reserved for the future. And the lower bytes that the application itself can determine. If he certainly does not have enough standard.
Necessities in flags as in unix I do not see, since flags of flags only add bit depth when needed. Our flags will be in the access mask itself (I hope this term is appropriate).
In the end, let's say for the article, we get an access mask, which will look like this:
What this means and to whom, what is permitted - I think it is clear from the figure.
In each group - two subgroups. The first subgroup of 4 bits - reserved for the most standard. The second subgroup is defined separately by each module. We have, for example, there will be described the possibility of placing files.
In the database, this mask will be recorded as the number 3 633 352 832.
In the example, the bit depth is 32 bits — the data type is INT. This is for example. In real life, I’ll probably use the BIGINT size of 64 bits. Accordingly, all groups and subgroups will be 2 times larger.
As I assume to use - when attempting to access an object - the module will have to request access rights to the object. The system will pull this number out of the database, parse the bits and return the module in some beautiful form. Suppose in the form of a conveniently processed array. Then the module should act as it should.
The number of entries in the rights table will grow straight from the number of objects in the system. In principle, this is tolerable, but you can make it even more beautiful - select the standard mask for modules. And in the table to write objects only with non-standard rights - the number of records will be reduced by an order.
You can not force developers to use this system. But, when using it, they will receive the following advantages:
everything is done - take it and use it;
less chance to make a mistake in the code;
the user will have one universal and familiar interface for all modules and their objects.
The use of this system, by the way, does not exclude other methods of access control. Such as access lists.
If the community likes the article, the article “The system of separation of access rights in the web application - practice” will appear. :)
PS In the theory of security is not very strong - correct, if wrong where in terms.
PPS I did not see such a system on the web, although it is possible somewhere far away, and maybe even close - it is there. If so, post a link.
PPPS The first post on Habr - possible "childish" errors, point to them - I will quickly correct.
UPDATE : Now a blog post about CMS and on the main page of habr. Thanks, habrareyudi! :)
Special thanks to mexxv for karma for moving the post and metamorph for the link to a good article ideologically very close to me.
I was glad in my blog to get on the main habr. I do not publish infu there yet, I'm afraid he will not stand the habr effect - you need to prepare in advance. :)
And now in the case. Comments helped to understand the main problem of the proposed system - flexibility is still not enough. Need more. Maybe using a hybrid with an ACL, maybe due to a lot of inheritance. I will try to bring all the deliberate results to tomorrow.
UPDATE : mephius says that the idea proposed by me with seasoning from ALC works on a mega-cool site .
By the way, I earned the first habrainvayt. :)))
Below I want to share thoughts about the system of separation of access rights in the CMS. It seems to be very original and interesting.
Thinking about implementation, I set the following goals:
- uniform API for all modules;
- easy and convenient for developers;
- easy and convenient for users;
- acceptable speed and amount of data;
- flexibility of opportunity.
As a result, I came to the conclusion that the most suitable analogue is the mandatory system of access to files in unix. The one that is 777. :) Naturally amended for web orientation - instead of directories, we will have categories, instead of files, different web objects, etc. Everything below.
')
In the most general approximation - the system will store a table that will contain the identifiers of all objects, and access rights to them.
Technical problems (for example, the heterogeneity of object keys, the use of the system at the discretion of the developer), as well as optimization, will be discussed later. While we go on the strategy.
Each object will have an owner-user, an owner-group and a number that will describe what to do with this object. In unix-systems, this number contains 3 digits to describe the rights
- owner - user;
- owner - group;
- other users.
We will have one more digit:
- owner - user;
- owner - group;
- other registered users;
- other unregistered users.
Now for the more interesting. In the operating system, as a rule, there is enough control over all three operations - reading, writing, execution. Plus a couple of extra flags.
Our situation is more complicated - there may be many other operations that need to be controlled. The description of the read / write / execute rights is not enough. For example, on a website with ads, the user can change his ad, but can not upload photos to it. This opportunity opens after payment. Or the ability to download the attached files - it must also be controlled.
It turns out that, unlike the OS, where only three operations — we have the number of these operations — are potentially unlimited. There are many of them, and in addition, they can vary from application to application. And yet this is a beautiful solution.
Each digit can be divided into upper bytes - the most standard operations for all objects, as well as some part reserved for the future. And the lower bytes that the application itself can determine. If he certainly does not have enough standard.
Necessities in flags as in unix I do not see, since flags of flags only add bit depth when needed. Our flags will be in the access mask itself (I hope this term is appropriate).
In the end, let's say for the article, we get an access mask, which will look like this:
What this means and to whom, what is permitted - I think it is clear from the figure.
In each group - two subgroups. The first subgroup of 4 bits - reserved for the most standard. The second subgroup is defined separately by each module. We have, for example, there will be described the possibility of placing files.
In the database, this mask will be recorded as the number 3 633 352 832.
In the example, the bit depth is 32 bits — the data type is INT. This is for example. In real life, I’ll probably use the BIGINT size of 64 bits. Accordingly, all groups and subgroups will be 2 times larger.
As I assume to use - when attempting to access an object - the module will have to request access rights to the object. The system will pull this number out of the database, parse the bits and return the module in some beautiful form. Suppose in the form of a conveniently processed array. Then the module should act as it should.
The number of entries in the rights table will grow straight from the number of objects in the system. In principle, this is tolerable, but you can make it even more beautiful - select the standard mask for modules. And in the table to write objects only with non-standard rights - the number of records will be reduced by an order.
You can not force developers to use this system. But, when using it, they will receive the following advantages:
everything is done - take it and use it;
less chance to make a mistake in the code;
the user will have one universal and familiar interface for all modules and their objects.
The use of this system, by the way, does not exclude other methods of access control. Such as access lists.
If the community likes the article, the article “The system of separation of access rights in the web application - practice” will appear. :)
PS In the theory of security is not very strong - correct, if wrong where in terms.
PPS I did not see such a system on the web, although it is possible somewhere far away, and maybe even close - it is there. If so, post a link.
PPPS The first post on Habr - possible "childish" errors, point to them - I will quickly correct.
UPDATE : Now a blog post about CMS and on the main page of habr. Thanks, habrareyudi! :)
Special thanks to mexxv for karma for moving the post and metamorph for the link to a good article ideologically very close to me.
I was glad in my blog to get on the main habr. I do not publish infu there yet, I'm afraid he will not stand the habr effect - you need to prepare in advance. :)
And now in the case. Comments helped to understand the main problem of the proposed system - flexibility is still not enough. Need more. Maybe using a hybrid with an ACL, maybe due to a lot of inheritance. I will try to bring all the deliberate results to tomorrow.
UPDATE : mephius says that the idea proposed by me with seasoning from ALC works on a mega-cool site .
By the way, I earned the first habrainvayt. :)))
Source: https://habr.com/ru/post/51231/
All Articles