[itsronenh]

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.

[claytongulick]

I totally get the benefits, the part I'm struggling with is the real-world details.

Like, the amount of effort it would be to put in application logic in order to determine attributes that would then be put on to the profile would be more than that which would be required to just have auth native in the code.

Then there's the problem of keeping those attributes in sync with the application as things change.

Then there's the problem of debugging when things go wrong - instead of being able to inspect the application state and determine the issue, now I have two places and different processes for issue resolution.

I'm not talking about this in a hypothetical sense - I've tried this before. All sort of declarative rule based systems, and integration with Auth0 with attributes stored as part of the Auth0 profile, etc...

After doing it and balancing the benefits, I've found that having well-architected code base with auth as a separate concern, but embedded within the native code (as a separate class/service/module/etc... is more effective and less work with better performance characteristics.

Obviously this doesn't apply to every situation, I can think of several scenarios where third-part auth would work very well, I just don't run into them a lot.