Great post! When starting a green field project, how would you approach the choice between the two options? Are there specific use cases in which one would be preferable over the other?
That's been my experience too. In addition to attracting new engineers that want to contribute to open source, it's an opportunity to showcase your organization's (hopefully good) coding practices to candidates.
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.
Aserto takes a hybrid approach. It runs a hosted control plane where you configure your user-directory, authorization policies, etc. But the authorization logic itself can run alongside the application that uses it, ensuring high availability and low latency.
I agree with most, if not all, the points raised in the post. I'm curious how people deal with:
1. Organizing knowledge. Too often I've seen a lot of well-written and well-intended information thrown into a shared cloud drive or wiki to rot and grow stale. You end up with multiple, sometimes contradicting documents about the same topic, finding what you're looking for is difficult, and before you know it people revert to tribal knowledge and slack DMs to find out what they need.
2. A writing culture can penalize and demoralize non-native speakers whose writing skills may not be as strong as their peers. I've worked with brilliant individuals who felt like they're perceived as "stupid" because their language skills weren't as polished.
Can the tool push policies to other OCI registries like docker hub or the GitHub registry? I mean, it's nice to have a dedicated registry for OPA policies but are there alternatives?
A little ray of sunshine this morning. I'm not a physicist and have no idea how close this technology is to powering our electric grids, but it seems like humanity's best chance for a carbon-free future.