On Authorization and Implementation of Access Control Models

There are dozens of implementations of authorization mechanisms. When there are complex requirements dictated by business processes, authorization mechanisms may often be implemented incorrectly or, at least, not optimally. The reason for that, in my opinion, is the low attention of both the customer and developers to this aspect in the initial stages of the project and, at the same time, insufficient assessment of the impact of necessary requirements.

What is Authorization?

From the point of view of any information system, authorization is the decision-making process on providing access to resources to the subject based on specific knowledge about it. By this moment, the subject, as a rule, should already be identified (You need to know who he is.) and authenticated (His identity is confirmed.)

Problems

Let's see what types of authorization requirements exist, why it is extremely important to consider them initially when designing a system, and why it's important not to postpone it for the future. There are usually two sources of authorization requirements in a corporate information system. These are business requirements and security requirements. A business owner wants to keep secrets and provide permissions to users in accordance with their function in the business process, and security wants to ensure the least privilege approach for each user and also to audit the access. Let’s take, for example, a hypothetical contract approval process of a large company. Business owners will probably have the following requirements to the authorization process:

1. A user who is not related to a specific contract should not see it in the system.
2. The author of the contract should see the contract at all stages.
3. A user with a grade of at least 10 has the right to create a contract.
4. The approving party must see the contract, starting with the receipt of it and up.
5. Heads of departments should see the contracts of their units down the hierarchy.
6. The author of the contract and the head of the unit have the right to withdraw the contract at any stage of the approval process.
7. The management of the head office should see the documents of all branch offices.
8. The user who created the contract should not have the right to approve it.

From the security perspective, we may have the following requirements:

1. Know who has access to a specific contract.
2. Know who had access to a specific contract at a given time.
3. Deprive the user of access to previously available documents when changing his job duties.

Let’s see why all these requirements are quite problematic:

• They are not stable. The probability of their change, even in the short term, is very high.
• They are cross-running. Their implementation affects all layers, from database design to UI.
• The authorization mechanism is strongly connected with business logic.
• They affect performance.

Possible Solutions

The already created access control models may help in solving many problems: MAC - mandatory access control. The subject’s access to the object is determined by its access level. The subject’s access level should not be lower than the level of secrecy of the object. DAC - discretionary access control. The subject’s access to the object is determined by the presence of the subject in the object’s access-control list (ACL). RBAC - role-based access control. The access of the subject to the object is determined by the presence of the role that contains permissions corresponding to the requested access. ABAC - attribute-based access control. The subject’s access to the object is determined dynamically based on an analysis of policies that take into account the values ​​of the attributes of the subject, object, and environment. This also includes PBAC, RAdAC, CBAC. It is highly recommended to use all access control models in their original form without reinventing the wheel. Quite often, in complex information systems, a combination of models is used. For example, the ACL + RBAC combination is popular when a role is included in an access list. However, the correct use of ready-made models is also not an easy task because a lot of people cannot choose the right model, separate it from business logic and achieve an acceptable performance of the authorization mechanism. To implement the requirements stated above in the “Problems” section, at first glance, I would choose the PBAC + ACL combination. The requirements could be implemented as follows:  

	Business requirements	Solutions
1	A user who is not related to a specific contract should not see it in the system.	ACL is not perfect, but it's the optimal solution here, since it is quite difficult to determine the user's role in the business process without writing it to a list at the time of involvement.
2	The author of the contract should see the contract at all stages.	This requirement can be implemented by PBAC or ACL, but I consider the ACL to be optimal since in this case, it will be easier to implement requirement #3 from the security section.
3	A user with a grade of at least 10 has the right to create a contract.	This is a policy (PBAC), no other options here.
4	The approving party must see the contract, starting with the receipt of it and up.	ACL will be optimal.
5	Heads of departments should see the contracts of their units down the hierarchy.	This is a great task for PBAC, but it can reduce the read performance, and requirements #1 and #2 from information security will require additional efforts, so you should carefully think about the exact implementation.
6	The author of the contract and the head of the unit have the right to withdraw the contract at any stage of the approval process.	PBAC will do just fine.
7	The management of the head office should see the documents of all branches	PBAC, with the same restrictions as in clause 5.
8	The user who created the contract should not have the right to approve it	This requirement could be met with PBAC, but this should not be done. This is the case where authorization conflicts with business logic, and in such situations, the priority should be given to business logic.

  The listed security requirements can be implemented using ACL, but we implement business requirements #5 and #7 using PBAC. So, to implement the security requirements #1 and #2, you will have to add a journal or a similar mechanism because, for all its beauty, dynamic rules are poorly audited:  

	Security requirements	Solutions
1	Know who has access to a specific contract.	General journal for ACL and PBAC
2	Know who had access to a specific contract at a given time.	General Journal for ACL and PBAC
3	Deprive the user of access to previously available documents when changing his job duties.	ACL

Conclusion

Authorization is an undeservedly neglected topic, both in publications and directly during the development process. Two-factor authentication via SMS can be implemented even by a junior specialist; however, correctly implemented authorization in the corporate system is a nontrivial task even for seniors and architects.

---

Image

About the Author: David Balaban is a cybersecurity professional writing for malwarefox.com. His key competencies include malware analysis, online privacy, and software testing. Additionally, he does his best to stay current with the e-threat landscape and keep tabs on the evolution of computer viruses. With 13 years of experience under his belt, David knows how security works and how important it is to maintain privacy on the Internet. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.