All of access control comes down to one fundamental question:
How do we grant the right access to the right things to the right people and systems for the right amount of time?
Every other question addresses an aspect or nuance within that question.
When we launched Pangea AuthZ in May, we focused entirely on Role-based Access Control (RBAC) and Relationship-based Access Control (ReBAC) to serve as a foundation. Roles give you a way to group and label users and their access while relationships introduce concepts like parent-child or ownership to further refine their access. While those are exceptionally powerful and can create a multitude of access control policies, we may need further context on the whom (subject) and the what (resource) to make access control decisions.
Towards that goal, we’re excited to launch our Attribute-based Access Control (ABAC) within AuthZ. This gives you the ability to inject and evaluate attributes at runtime to give more fine-grained control based on the current state of the system and the objects within it. That dynamic access control plus the granular access based on multiple attributes is an extremely powerful system.
At a conceptual level, you can layer additional ABAC requirements on top of your existing Roles and Relationships to be more specific. You can shift from a simpler rule of “an Admin can read files” to a more powerful rule of “an Admin can read files except those marked as HR”.
In practical terms, you extend the check calls with the attributes your rule is based upon and the authorization engine within Pangea handles the rest. The responses do not change so the rest of your code works as is without modification.
For launch, we chose to keep the attributes in the check request as those will serve as the most up to date view of the data without requiring synchronization or cross loading. In future releases, we’ll get more creative connecting Pangea resources to AuthZ rules so your rules and access policies can grow and adapt as our capabilities expand.
If you’re already using AuthZ, visit the Roles & Access screen and you can add an Attribute-based rule. These functions operate as ANDs on top of existing requirements.
If we have a simple structure where projects have tasks, we can have a project_owner who has read access to their own projects and full permissions to all tasks within their projects. It looks something like this:
But we can refine our permission by adding an ABAC requirement to the projects.read permission to limit access to users in the US.
Our rule started as:
a project_owner may read their projects
and transformed into:
a project_owner may read their projects if their country is “US”
And then we can add an additional requirement for tasks to change this rule:
a project_owner may read tasks of their projects
to this rule:
a project_owner may read tasks of their projects if they are an assignee
Using an ABAC rule such as this:
Now when we check the subject’s permissions, we can provide the assignees and confirm they are in that collection.
Within the application, you pass the attributes into the check request and we transparently perform the check and return the result in the same structure as before.
For more information and guides, check out our documentation and how-to guides. Our SDKs already support ABAC so you can get started right now.
Note: All of these rules are applied as AND statements. While OR statements are powerful, they can create numerous paths that become complex to build, understand, and verify for audit and compliance purposes.
If you’re like me, your mind is filled with possibilities. You can build rules based on location, time of day, age of the resource, phases of the moon, how many web shooters you have left and a variety of other things. Remember: For an authorization policy to be useful, you must be able to understand it, design it, implement it, audit it, and finally debug it.
The more fine-grained your policies are, the more flexible and powerful they are but everyone else on your team - and your Security/Compliance teams - must make sense of them too. Be thoughtful in how you apply ABAC in your systems. It is not a solution to every problem but a great refinement to your existing solutions.
Now that we can build additional rules based on attributes, the obvious step is to leverage the other Pangea services. As a first step, we plan to connect AuthZ into our AuthN service so you can reference users and their profile attributes without explicitly requiring them at runtime. From there, interacting with our Vault, File Share, and other services only get more exciting.
As you use more Pangea services to protect your applications and our capabilities grow, your authorization policies also become more powerful.
If you need OR statements or have seen clever implementations, feel free to drop me a note and share - keith.casey@pangea.cloud. I’m always looking for creative approaches, fun ideas, and how to make our products better and more useful to you.
Use Cases
Case Studies
Services
Developers
636 Ramona St, Palo Alto, CA 94301
PrivacyTerms of UseYour Privacy ChoicesContact usPangea is a Sample Vendor for Composable Security APIs in the 2024 App Sec Hype Cycle™ report