In the previous posts, we covered the advantages of dynamic AuthZ and the benefits of ABAC. We found that static authorizations don’t offer as much security and scalability as we would like to have – authorizations don’t automatically change when an employee changes roles, leaving organizations wide open to the possibility of access creep, employee theft, and other negative outcomes. This post covers how in addition to being less effective, group-based systems are error-prone and don’t really reflect what the user can do.
Groups Are Old School
It’s true that traditionally, security groups are the most common way used to authorize access to data and actions. But what is truly their role? How do they operate? Security groups, or security roles act as a link, an intermediate between the users and the data, information or actions. They do not directly reflect what a user can actually do or see.
For example: we want developers to access development data, and managers to access management data. So we create one group for developers and another for managers, and assign the users accordingly. But who is responsible for ensuring that the development group can only access development documents? And that the management group can access only management data? What happens if a development manager, who is assigned to both groups, accidentally places an “Employee Management Assessment” document in the development folder?
When using group based access, the responsibility is diverted. The IAM team usually connects users to groups, but the data and activities this group can access is under the responsibility of the application or the business owner. In practice, users often receive access to too many resources that they do not need and are prevented from receiving access to specific resources and tools that they do need.
Firstly – it leads to many errors and, secondly – it does not scale.
Reverting to the developer example: Whenever that developer joins a new project, they need to be assigned to a new set of documents, tools, and permissions. In addition, access to their previous set of tools etc will probably need to be revoked. This may be manageable if there are only a few developers in the organization, but what happens in places with hundreds or thousands of employees? The IAM team will spend a large and unnecessary amount of time unpacking and reassigning permissions even if only a single employee changes roles.
Resource-based access allows you to connect users to the data they are entitled to access. Without a middle man, without giving away responsibility, without any unknown stages which could lead to potential errors.
For example, in resource-based access, access can be granted based on the matching project identifier for both user and document. It can also be based on the the user’s role in the project, with access determined according to project stage – Project A is in review stage, so its data is accessible to all reviewers that are assigned to this project.
Resource-based access enables direct connection and accurate visibility to what a user can see and do.
PlainID facilitates connecting digital identities to their data, actions and resources. Moreover, PlainID’s advanced AuthZ platform lets IAM teams gradually transform existing group level access into fine-grained resource based access.
For more information on how you can easily change from your existing group-based authorization into a scalable resource-based system, contact PlainID today: