On the surface, roles may seem like a great way to limit access for individual users. But, because of the lack of visibility roles provide, organizations can end up in situations where they now have hundreds of roles per employee. As the number of employees grows, so do the number of roles, making it difficult to find where weak spots lie if an error or data leak occurs.
Enter: Policy-driven authorization.
Policy-driven Authorization can enhance your security by not only limiting role explosion, but also by taking into account: Segregation of duty (SoD) violations, context, scale, and relationships.
Here’s a look at how roles fall short when addressing key access control challenges — and why relying on roles alone can quickly become a limitation.
Segregation of duty (SoD) violations
Let’s say there’s a retail company who has multiple different positions such as a manager, sales manager, a trainee sales manager, and a sales representative.
In this scenario, we’ll pretend that the sales manager could give commission to the sales representative, but sales managers could not give commissions to themselves. Actions like these may seem pretty straightforward, however, it gets complicated when looking at the trainee sales manager role.
This role typically would start from a sales representative meaning that once they get promoted to trainee, they would then have characteristics from both roles. Theoretically then, a trainee sales manager could not only receive a commission themselves, but now also give sales representatives (and even themselves) commissions as well which could give employees the potential to create false data.
A simple policy-driven relationship check could prevent this kind of situation from occurring within your organization — a testament to why roles on their own aren’t enough.
Relationships
In a similar vein, roles are primarily identity-centric meaning that they can only look at the role assignment (i.e this user has the “Manager” role so they can access these records”) they can’t look at the context (time of day, device type, authentication method, etc) around the role.
For example, if you wanted the owner of a document to read something or a doctor could only view the medical record of their patients, that’s a relationship; something about the user that relates them to the resource. A lot of the time, this happens when a user’s email address is the same as the owner field in relation to the doctor example. If you complete this relationship by assigning roles, there would be millions of documents that need roles associated with each one which would lead to millions of roles.
This might not be a problem if there is only one doctor and one patient, however, if this is at a hospital, for example, where hundreds of doctors come in contact with hundreds, maybe even thousands of patients, it would be difficult to manage these roles. This is when role explosion occurs and it can happen within any organization.
Context
As briefly mentioned, roles cannot read into the context surrounding them. This refers to the time of day, device type a user could be accessing from, the authentication method, and more.
For example, customer support is often a 24/7 operation, but individual customer service representatives will come and go as their shift starts and ends. Organizations want to make sure that these representatives can only access certain data during their shifts and not outside of work hours.
A role would not be able to prevent this from happening. They may be able to say “This user has the representative role so they can access this data”, but they would not be able to stop that user from accessing that data at specific times of the day.
Scaling
If an organization were to go about creating relationships by assigning roles as briefly discussed, it would lead to a scaling issue.
To get the level of granularity that you would need if your organization chooses to create relationships this way, you’re only amplifying the instinctual temptation to create yet another role in your IAM system or even your governance system which could create a scenario in which one singular employee has hundreds, thousands or even more roles assigned to them.
Having this many roles for one employee can lead to role explosion making it extremely difficult for your organization to trace back to the root if a problem occurs.
Why you need policy-driven authorization in addition to roles
While roles play an essential part in identity and access management (IAM) systems, they are not a standalone solution for organizational security and efficiency. Issues such as SoD violations, relationship complexities, contextual limitations, and scalability challenges highlight the limitations of role-based approaches.
Without incorporating contextual factors through policy-driven authorization, organizations risk role explosion and security vulnerabilities. Therefore, a more holistic strategy that goes beyond roles is crucial to ensure effective governance, optimized access control, and the prevention of potential pitfalls in scalability and security.
Want to gain more insight on how policy-driven authorization can help limit your risk of role explosion? Watch our webinar where we discuss common questions around authorization or request a demo with our team to talk about your organization’s specific use case.