Designing authorization is fundamentally a challenge. Not only do you have to understand your problem and domain fully but you also need to understand the limits of your tools. If you get either wrong - or maybe just not as correct as you should - you get catastrophic consequences.
In general, you have two approaches:
On one hand, you can go deep into every single resource in your system and manage access individually. While it works, it requires entries for every single entity+user in your system making your authorization policies massive, cumbersome, and slow.
On the other hand, you can build authorization policies built on roles and logical structures that use relationships to link to individual resources without explicit assignment.
With Pangea AuthZ’s Inherited Permissions, we can get the best of both worlds. We can start from overarching roles and relationships and have them apply down entire logical structures to resources automatically.
Inherited Permissions in Practice
When we’re working with an app like Google Drive for our organization, we’d likely start with simple department-level permissions for folders. Our Marketing Team has access to the Marketing folder and likewise for other groups.
As our organization grows and the Marketing Team rolls out different initiatives, they’ll add folders for each within their folder. Because our permissions are inherited, the team has the same access to those folders. Then as those initiatives split into stages, they’ll add more folders within those. Because our permissions are inherited, the team has the same access to those folders.
To build this policy within Pangea AuthZ, it takes two steps:
First, we add a relation. In this case, we have a folder Resource Type and note that it can have a parent of another folder:
Second, we add Inherited Permissions so a user who has edit access to the parent folder has edit access to this folder and likewise for read access:
And this inheritance works recursively so we can have a folder structure grow deeper over time and we don’t have to update permissions.
Note: Since these changes are within the policy - not the check requests via the API - your downstream applications that leverage AuthZ do not need to change. This continues to keep your authorization policy separate from your authorization enforcement.
Inherited Permissions in Code
For example, first we’ll create the resource types, relationships, and inherited permissions noted above. Then we’ll want to create an owner role with read permissions to a folder. We’ll do each of those tasks once.
Then we’ll create a folder called Marketing and within it we’ll have folders for Budget and Website. Within the Website folder, we’ll have folders for Assets and Content. We’ll only need to change this structure as we add or delete folders and files.
Our final step is assigning a user to our role. We’ll update these tuples regularly as people join or leave projects, our team grows, or we start new projects.
You can see all of the relevant API calls to create these relationships here.
Now we perform a check at any level. At the “Marketing” folder,, user “Keith” was explicitly assigned so we expect this to result in “Allowed” and it does:
curl -sSLX POST 'https://authz.aws.us.pangea.cloud/v1/check' \
-H "Authorization: Bearer TOKEN" \
-H 'Content-Type: application/json' \
-d '{"subject":{"type":"user","id":"Keith"},
"action":"read",
"resource":{"type":"folder","id":"Marketing"}}'
Then we can jump two levels deeper and check the “Assets” folder within the Website folder which is within the Marketing folder:
curl -sSLX POST 'https://authz.aws.us.pangea.cloud/v1/check' \
-H "Authorization: Bearer TOKEN" \
-H 'Content-Type: application/json' \
-d '{"subject":{"type":"user","id":"Keith"},
"action":"read",
"resource":{"type":"folder","id":"Assets"}}'
Finally, if we want to understand the reasoning, we can turn on debug and see the details. The full details are in the Gist, but in short, the logic works as follows:
Does Keith have read access to the Assets folder? Not sure, check parent
Does Keith have read access to its parent (Website) folder? Not sure, check parent
Does Keith have read access to its parent (Marketing) folder? Not sure, check role
Is Keith an owner of the Marketing folder? Yes.
And then the logic flows back up to mark each step as Yes.
Next Steps for Pangea
With Inherited Permissions, you can evolve into more complex authorization policies as your own use cases grow without having to rearchitect your implementation. Again, since Inherited Permissions are within the policy side of AuthZ - as opposed to the enforcement side - your downstream application doesn’t need to change.
Going forward, we’re working to go deeper with Pangea’s Threat Intelligence services to enable more robust and powerful capabilities leveraging IP addresses, geography, user context, or authentication context. Keep an eye out for how to leverage those capabilities to keep your apps and organization safe.
And if you’d like to talk, explore, or scheme on your AuthZ schema, let us know.
