Authentication and authorization rank among the top priorities for application developers today. While they’re often used interchangeably, they actually represent two very different things. Yet in order to ensure a secure and seamless experience for users, both must work in concert.
To illustrate the distinction between authentication and authorization, I often use the example of taking your family to Disneyland. Authentication is like the front gate where upon arrival you show your ticket and ID to the gatekeeper who checks to confirm that you are who you say you are—much like when you log onto an application in which the authentication system checks your username and password to validate your identity.
Authorization is what happens once you’re past the front gate. Your ticket may have a “Fast Pass” that allows you to skip waiting lines, or your kids might have different tickets meant only for certain rides. These authorization (or access control) measures govern “what you can do” after you are authenticated. In an organizational context, this is akin to having the right permissions to access certain files or programs.
Of course, managing authorization for an enterprise application is far more complex and nuanced than the example shared above. Perhaps you need to grant access to a resource on a temporary basis and only to a select subgroup of users. Or maybe there are certain resources that should only be available to individuals under specific conditions, such as being part of a project team or working in a particular department.
RBAC and ABAC
Which is why over the past two decades we’ve seen the introduction and adoption of a number of different access control models. First-generation authorization models like mandatory access controls prioritized a one-size-fits-all approach over fine-grained access controls. However, in the modern enterprise, where access rights to certain applications, systems, or resources might need to be granted or revoked on a daily basis, it became evident that more dynamic solutions were necessary. This led to the development of more modern authorization models such as role-based access control (RBAC) and later, attribute-based access control (ABAC).
RBAC simplified access management by assigning permissions to roles rather than to individual users. In a corporate environment, roles like “manager,” “accountant,” or “IT technician” come with predefined access rights, streamlining the process of granting or revoking access as employees assume different roles or responsibilities. ABAC took this a step further by incorporating a wider range of attributes (such as user location, time of access, and type of device used) in administering access decisions.
However, while ABAC offers both a high degree of granularity and flexibility, it is also cumbersome to manage, as it requires the definition and ongoing maintenance of numerous and constantly shifting attributes and policies. This complexity has in turn led to an assortment of administrative challenges, especially in large-scale environments where the sheer number of attributes and rules, and the relationships between them, can quickly become an overwhelming burden.
ReBAC enters the chat
Relationship-based access control, or ReBAC, offers a more flexible option for software developers to add fine-grained authorization to applications and resources. Based on Google’s Zanzibar framework, ReBAC considers the relationships between entities (like users, resources, and groups) to govern access. It provides a more context-aware approach to access control compared to RBAC or ABAC, making it particularly well-suited for complex environments where relationships and interactions are prioritized in determining who should and should not be granted access.
For instance, consider a typical hospital that’s staffed by a wide range of individuals and roles—from hospital administrators, doctors, and nurses to lab technicians, security guards, and janitors. While all of these individuals might be granted front door access, that doesn’t mean that they all possess the same authorization rights. Moreover, just because a doctor might have the authority to review detailed patient records it doesn’t necessarily mean they should have access to the privileged information in every patient—just the ones under their care while they are being provided care by the institution.
Under a ReBAC model, when a doctor is assigned to a patient, they are granted access to that patient’s medical records. This access can be dynamically revoked when that patient is no longer in the doctor’s care. Similarly, a nurse in the same system might have different access rights, limited to the patients they’re directly involved with. This agility ensures that healthcare professionals have the necessary information to provide care while maintaining strict patient privacy that adheres to regulatory requirements.
ReBAC also allows for a more detailed and precise management of user permissions compared to traditional access control models, which is achieved by focusing on the nature, context, and attributes of the relationships between various entities (like users, resources, and data). However, while ReBAC offers a promising way forward, it’s not without its own challenges.
Implementation guidelines for ReBAC
Implementing and managing a ReBAC system can be a complex undertaking, especially in large organizations where relationships and interdependencies are numerous and constantly evolving. If you’re planning to implement ReBAC, consider these three guidelines.
Focus on the initial definition
Before dipping your toes in the ReBAC pool, it’s essential to invest the time up front in order to gain a full understanding of the various relationships that exist within your organization. This includes mapping out in detail how users relate to each other, to resources, and to the organization as a whole. Understanding and communicating these dynamics is crucial for defining effective access control policies. Establishing these initial definitions will play a critical role in determining not only how ReBAC is initially implemented but how it might evolve over time.
Start small to secure quick wins
Before rolling out ReBAC across an entire organization, it’s best to start with a small implementation or pilot program that will allow for the testing of the system in a controlled environment. For example, consider testing ReBAC initially in the human resources (HR) department, which typically have well-defined and stable relationships, such as those between HR managers, employees, and confidential data. In this context, ReBAC can manage access to sensitive employee information, such as personal details, performance reviews, and payroll data. Such an approach helps in identifying potential issues, fine-tuning policies, and understanding the practical implications of the system without overwhelming the staff or disrupting major organizational processes.
Develop, test, and refine policies
As part of a small-scale rollout, it’s essential to ensure that the policies being implemented are being regularly tested and refined based on stakeholder feedback, and that they accurately reflect the desired access controls based on relationships. Policies also should be tested using various hypothetical scenarios to assess their effectiveness and practicality. This might include scenarios like role changes, department transfers, or changes in project teams, ensuring that such policies grant appropriate access in each scenario and that any changes in relationships will result in an immediate update in access rights. It’s also important to recognize that policy development and testing is an iterative process and that as the organization evolves and new types of relationships emerge, the policies will need to be revisited and updated to remain effective and relevant.
No matter where you are in your authentication and authorization journey, it’s essential to stay informed about evolving security models like ReBAC, as they offer more nuanced and adaptable approaches to protect your resources and data in today’s digital landscape.
Rishi Bhargava is the co-founder of Descope, a drag-and-drop customer authentication and identity management platform.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.