When designing an activity-based authorization system, how should additional conditional checks be handled?
For example, I have the following authority:
VIEW_COMPANY_TRANSACTIONS
which allows the user to hit the endpoint
GET /company/{companyName}/transactions
However, what if my authority VIEW_COMPANY_TRANSACTIONS has other restrictions based on the activity parameters that in fact make the authority effectively VIEW_COMPANY_TRANSACTIONS(companyName=company_a). I don't want to encode that information into the authority system, and end up with the following new authority:
VIEW_COMPANY_TRANSACTIONS_FOR_COMPANY_A
The above authority seems to mix up the filtering of the views and the authority itself which makes everything somewhat tedious and inflexible.
In another example, I have the following authority:
APPROVE_TRANSACTION
which allows the user to hit the endpoint:
POST /company/{companyName}/transactions/{id}/approvals
But what if the approval can only be done if the transaction.amount < maxAmount in which case, it's even harder to encode this into a new hardcoded authority.
Note that these authorities may also be included in a JWT token, so they must somewhat transferable as well.
What's the best way to design such a system? Any tips?