Aserto: Developer API for permissions and RBAC

This is probably a pretty stupid question, or at least based on some misconception of mine about this space. But I don't really understand how permissions as a service or API can work efficiently.

If I request a single resource, of course this can work if I ask a second API on whether the request is allowed or not. But if I query a database for a list of items, to add access control I need to modify the database query. I can't just filter after the fact, it's too easy to cause pathological performance issues there e.g. if the user has only access to a very small subset of a large list of results. How does this work with a separate access control API that can't directly modify the database query?

Great question. There are two scenarios that are relevant for authorization:

1. Gating the operation (whether it's retrieving a single resource, or creating / updating / deleting a resource). In this scenario, the application does need to call the authorizer before performing the operation on the resource, but the relationship between the authorizer and the application is at "arms length".

2. Filtering a list of resources. In this scenario, the authorization system can help you by running what in OPA is known as a "partial evaluation", which returns an abstract syntax tree. Your code would then walk that tree and insert the proper where clauses (if you're talking to a SQL back-end). As you mentioned, by necessity, your application needs to work more closely with the authorizer.

There are at least two startups which are re-implementing something like zanzibar. In my experience, RBAC is too simplistic for even not so advanced apps. For example, with RBAC alone you can't express «User X can edit object Y», if object Y is one of many objects in a collection. Zanzibar – and any system building on top of tuples (subject, relation, object) – can express that quite intuitively.

That's indeed why authorization is a harder problem than authentication - because much of it is domain-specific.

Still, there are many things an authorization system can help with. For example, the service/organization affiliation of the user is easily expressed as a set of attributes / properties / roles on the user. If that's stored in a central directory, and the authorizer has a cached copy, you can use this context as part of your policy for making authorization decisions.

Lifting the authorization policy into a central repo allows you to consolidate authorization logic, and also enables separation of concerns. SecOps can evolve the authorization policy of the application without having to ask developers to revisit the logic in all the places it exists. In fact, we have customers that have their secops team deploy new versions of the authorization policy without having to redeploy the application.

Another example is having front-end code that can dynamically render component state (visible or enabled) based on the same authorization rules that the back-end / API uses. We have nice examples of this in our "peoplefinder" demo [0], which you can launch as a quickstart [1].

[0] https://github.com/aserto-demo/peoplefinder

[1] https://www.aserto.com/quickstarts

This goes straight to the core of what makes authorization in complex applications such a challenge. You hit the nail on the head when you say that authorization in inseparable from each application's unique circumstances.

At the most abstract level, an authorization decision is an answer to the question "is an identity (user, service, computer, etc.) allowed to perform an action on a resource?".

Each one of these constituents (identity, action, and resource) may include contextual information that is unique to the application at hand. Aserto gives you the ability to imbue each one with the necessary information.

Identities are stored in a directory where they can be enriched with arbitrary data. Roles, teams, attributes, and anything else that is directly tied to an identity whose actions need to be authorized.

Relevant information about the resource being accessed is collected by the application and sent as part of the authorization call.

Then there are the authorization policies that receive identity and resource information and make decisions.

There can be multiple ways to model an application's authorization scheme. In your example it sounds like the user (identity) is a care giver and the "resource" is patient data. If users belong to numerous care teams and their membership in them is highly dynamic, your application may perform the FHIR query to retrieve the identities of the the patient's care team prior to the authorization call and include that information in the resource context.

The policy can then make decision based on whether or not the acting identity is a member of the team, as well as any other relevant information (e.g. are they the patient's primary care giver or a specialist?).

There are many advantages to keeping authorization policies separate from application logic. Change management, provenance, and testability are a few.

Having a single place where all authorization policies are defined allows us to reason more deeply about the behavior of our applications.