By Ashwin Bhaskar, Senior Software Engineer at NextLabs
In the first part of the blog Series, we discussed the importance of ABAC (Attributes Based Access Control) as a way to augment traditional RBAC (Role Based Access Controls) for field level security.
Let us now analyze how we can go about implementing field level security using a combination of RBAC and ABAC approaches.
First, let us consider an example of a Multi-National Company with offices in the US, Europe and China manufacturing ITAR-classified products
Then, let us assume the Company has a policy which allows the Basic Data of a Material to be viewed by any “Head of Quality Assurance (QA) Department” world-wide, but other Data (non-basic data) of an ITAR-classified Material can be viewed ONLY by a Head of QA who is a US Citizen and operating in a US location. In this example, some of the fields will need to be hidden from users that do not meet the citizenship and location requirements criteria.
Note that in this example, in addition to the role of the user (Head of QA), the citizenship of the USER and his location, also has to be considered before certain data of ITAR-classified Materials can be displayed.
In the traditional Implementation under RBAC, what would an enterprise do to address this issue?
Typically an enterprise implementing the old RBAC model would create roles for the ‘Head QA’ for Different Countries, then another set of roles for the citizenship of the user and assign both to the Material Master Authorization object, then configure the permitted views /fields. Note that the concept of “location” of user at the time of access cannot be supported.
Notwithstanding the lack of “location” support, a roles-based approach cannot scale and becomes cumbersome to maintain in an enterprise with a large user-population. Additionally, if there is a change in the policy that allows authorized exceptions, the modifications must be made to all objects created to address the policy.
Now, let us consider the Combination of an RBAC and ABAC approach, which simplifies implementation.
In this hybrid approach, we would create one role for the ‘Head of QA’. This would be common to all the Head of QA across the company world-wide. Other attributes such as Company Codes, Offices, and Citizenship are individual attributes of the USER. And, Location can be treated as a dynamic attribute.
In ABAC, the attributes of this USER can be made available for the evaluation of access controls and field security.
Ideally, the Behavior of the Views/Fields should be evaluated based on the Runtime Attributes of the USER trying to access the transactions, in this case the Material Master.
When we think about designing a field level security solution for controlling Data access, there are three high levels of attributes that would decide the behavior of the Screen objects.
1) Identity – eg Roles, Citizenship, Skill Level
2) Context – eg Location, Type of Device
3) Content – eg ITAR-classified, Trade Secret
The paradigm shift in this model is that, the behavior of the fields/Views of the Business Objects are not controlled only by roles , but by 3 Sets of Attributes , providing us a much finer and more granular control to Business object data . This approach is more scalable and can support dynamic changes.
In the Next Blog I shall explore how to implement Field Level Security with the Attributes based approach using the NextLabs Entitlement Manager for SAP as an example. If you have questions or comments, please share.