In the past we’ve explained how Scopes are NOT Permissions. I’d like to give you a real-world example of why this matters, and how things can be better.

One feature that we have over at Aserto is the ability to integrate with Github: we help you get started with policy-as-code by creating policy repos for you based on our policy templates, complete with Github Actions that provide a CI/CD experience for policies.

Github's authorization model

Part of this integration is authentication and authorization at the Github API level. We do it as documented: we take the user through an OAuth Application flow, where they are asked to allow us to act on their behalf. They accept, and we get an access token with some scopes that we need, like admin:repo_hook, read:org, repo, and user. We check that the scopes are what we asked for, since the user might allow less.

All good so far -- we have everything we need to talk to the Github API. But then we try to do things on behalf of the user. One of these things is setting up a Github Actions Secret for your policy repo, to be used when publishing policies to our Policy Registry whenever Github receives a new tag event on that repo. Obviously, you could set it up yourself, but we want to be nice and do it for you, seamlessly.

But scopes are not permissions...

This is where the user can run into trouble. Even though they gave us all the scopes we asked for, there’s no easy way to tell if the user is allowed to perform the action of creating a webhook or a secret on a repo. This is because the user has various roles assigned to them, in the organization, as part of a team, per repo. In other words, the Github security model is a combination of general scopes like admin:repo_hook, roles that may restrict the set of permissions on a resource, and even resource-specific permissions.

So we can’t tell the user (easily) - “Hey, we can’t set up this repo for you, because you don’t actually have access”. Instead, we have to try and fail. And we hope that the error message we get back makes sense to the user. Or that we can identify the error message, and translate it.

It would be great if you could ask “am I allowed to do this specific thing?”, so we can tell the user exactly what’s wrong. The UX would be better if you don’t have to knowingly walk a user through an error.

Let's fix it!

What we’re building at Aserto brings this capability to you. With Aserto’s decisiontree API, you can evaluate every permission your application defines, in the context of a user and a specific resource, ahead of time. You can build a user experience that exposes only operations that you know will have sufficient access to succeed, so that your user doesn’t have to perform a UI gesture that will fail because your authorization policy prohibits it.

So come check it out and join the beta!