2

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.