Non-role security?

Question

This is a controversial issue, as I no longer participate in this project, but it continues to bother me. I wonder if anyone has a better idea for future references and general good programming techniques.

A security approach for textbooks is role-based security. Each screen, report, or other task is tied to one or more roles; each user is assigned one or more roles; and then each user can use screens, etc. that correspond to his roles and nothing more. Correctly?

A few years ago, I led a team developing a military technical management system. Each manual had a “technical content manager” responsible for writing or editing it; “fund manager” responsible for tracking copies and sending them; and the "administrative manager" responsible for the budget, and therefore decided how often the book would be reviewed, how many copies would be printed, etc. Of course, in every book there were many people who ordered copies and read them. (Since it was the military, you had to get permission to get books, security permissions and all that.) Usually we didn’t worry about real readers, but about the people at each base who managed the libraries, but this is really not relevant.

So ... these are obvious "roles", but the role was tied to a specific book. One person may be the technical content manager for book A, the administrative manager of book B, and a reader of 50 other books. Therefore, we could not say that the user has a "role". Each user had different roles for each book.

In addition to this, there were more ordinary privileges at the system level: we had several system administrators who were allowed to update something on the system, help services that could see almost any data, but not update, etc.

As a result, I created such a database. (In order not to fall into any of our strange terminology, I will change the names of the fields and tables here, the idea is the same.)

Person (person_id, name, etc.)

Technical_Manual (manual_id, title, admin_manager_person_id, stock_manager_person_id, content_manager_person_id, etc.)

Authorized_Reader (manual_id, person_id, etc.)

User (user_id, admin_role, etc.)

I was not very happy with this scheme, as it meant that security was divided into three tables: a technical table, an authorized_reader table, and a user table. But ... was there a cleaner way we could do this? Any better ideas?

Answer 1

The way I recently did something vague, similar to this, is as follows:

Person (person_id, name, etc) Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc]) Technical_Manual (manual_id, title, etc) Technical_Manual_Role (manual_id, person_id, role_id) 

In addition, in my system, roles are most often the default permission packages, and user permissions for certain actions (Read, Edit, Move, Delete, etc.) can be changed depending on the baseline for their role.

Answer 2

The problem with forcing everything to be installed in the "roles" template is the logistics / volumes / workload to support a complete set of security rules when these rules are very "fine-grained".

By small-scale, I mean the case when in any authorization decision there are many potential factors that determine discrimination, and for each discriminating factor (for example, “the amount of credit used by the client”) there is a potentially large range of “values” (say, there 25 different ranges of the applied loan amount).

Let's say there are three such discriminatory factors, each of which has seven possible meanings (7 different ranges of the loan amount). Then you will need to determine 7 * 7 * 7 = 343 roles. Then, for each individual user of your system, you will have to assign a complete subset of all the roles that the user can perform. If the user has the right to decide on an application for a loan in the amount of 50,000,000, then it is likely (but again, not entirely accurate!) That he also has the right to decide on the application of a loan in the amount of 5.000.000.

This is why, in my project, security-related objects are limited to authentication (user ID) and authentication (usercertificate). There are no provisions for authorization. These issues should be addressed with custom restrictions.

Answer 3

I just wanted to add more from the concept of perspective. Despite the fact that RBAC (role-based access control) seems to be in fashion, there are many models, such as DACs, MACs, that were available to solve the problem of access control for a longer time (RBAC was actually formalized around 1995 year, while other models were much longer and used by the military). As you explained the requirements that I see in using multiple models

• RBAC - used in the case of the "system roles" that you talked about.
• Attribute / Policy Based Access Control - Used for all parts related to the manual.
• MAC - is used to control access to the manuals on the basis of, that is, each manual and user has an associated level of sensitivity, and they must meet based on certain criteria in order to have access.

These models can be expressed using standards such as XACML (and evaluated at runtime using policy implementations) that can describe the policy. For example, in your case, the policy will look like a line

(based on attributes)

Allow everyone to edit the manual if userId = manual.technical_content_manager

Allow "everyone" to send "manual" if userId = manual.stock_manager

(RBAC)

Allow "HelpDesk" "view" "manual information", "manual"

Allow the "Administrator" to "view", "edit", "send" the "manual"

(MAC)

Allow everyone to view the manual if userId.level> = manual.level

Based on the above policy model, it is clear that you need to track the mapping of a user role that can be performed using a table and retrieved at runtime to feed the policy engine at runtime.

Answer 4

I know this may seem a bit ragged, BUT you CAN do something like this:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) where acceptable_roles is a delimited list

Then in your program, separate the delimited list. I am not saying that this is the BEST way, but it WORKS. Although, I don’t know, it would be better for a military application :)

Answer 5

You can use a more authorized, claims-based approach.

there may be some general permissions that each user (i.e., administrator) may or may not have, which can be directly tied to a role. and we will use your table to match the specific user to whom the publications have extended rights, and create complaints for these entries.

therefore, when user authorization is requested, you get a collection of claims, some high-level ones derived from roles and some publication-specific ones obtained from your tables.

Answer 6

Commentary on the chaos reaction:

It seems to me that the roles of the "system level" can correspond to the same scheme, if manual_id for such things can be set to null or some kind of magic value. Yes, I know, some people have a strong aversion to zeros, but it works here. Then there will be one safety table, and everything will be clean.

I had a lot of problems with the three manager fields. We had several queries, such as “What kind of books does Bob carry?” Which required a query with a large OR for all three fields. This meant that we needed three indexes. Later I realized that it would be better to break it down into a separate table. But throwing authorized readers into the same table ... removes a lot. Throw system level material in too and ... I like it. It is easy to ask: "What rights does Mary Jones have?" as well as “Who is eligible for the F-15 Avionics Guide?”, “Who are all our technical content managers?” and etc.