1

Based on my coarse reading, ABAC, i.e. attribute based access control, boils down to attach attributes to subjects, resources and other related entities (such as actions to be performed on the resources), and then evaluate a set of boolean valued functions to grant or deny the access.

To be concrete, let's consider XACML.

This is fine when the resource to be accessed is known before it hits the decision engine (PDP, in the case of XACML), e.g. view the mobile number of some account, in which case the attributes of the resource to be accessed probability can be easily retrieved with a single select SQL.

However consider the function of listing one's bank account transaction history, 10 entries per page, let's assume that only the account owner can view this history, and the transaction is stored in the database in a table transaction like:

transaction_id, from_account_id, to_account_id, amount, time_of_transaction

This function, without access control, is usually written with a SQL like this:

select to_account_id, amount, time_of_transaction
from transaction
where from_account_id = $current_user_account_id

The question: How can one express this in XACML? Obviously, the following approach is not practical (due to performance reasons):

  • Attach each transaction in the transaction table with the from_account_id attribute
  • Attach the request (of listing transaction history) with the account_id attribute
  • The decision rule, R, is if from_account_id == account_id then grant else deny
  • The decision engine fetch loops the transaction table, evaluate each row according to R, if granted, then emit the row, util 10 rows are emitted.

I assume that there will be some preprocess step to fetch the transactions first, (without consulting the decision engine), and then consult the decision engine with the fetched transaction, to see if it has access?

Incömplete
  • 853
  • 8
  • 20

1 Answers1

1

What you are referring to is known as 'open-ended' or data-centric authorization i.e.access control on an unknown number (or a large number) of items such as a bank account's transaction history. Typically ABAC (and XACML or ) have a decision model that is transactional (i.e. Can Alice view record #123?)

It's worth noting the policy in XACML/ALFA doesn't change in either scenario. You'd still write something along the lines of:

  • A user can view a transaction history item if the owner is XXX and the date is less than YYY...

What you need to consider is how to ask the question (that goes from the PEP to the PDP). There are 2 ways to do this:

  1. Use the Multiple Decision Profile to bundle your request e.g. Can Alice view items #1, #2, #3...
  2. Use an open-ended request. This is known as partial evaluation or reverse querying. Axiomatics has a product (ARQ) that addresses this use case.

I actually wrote about a similar use case in this SO post.

HTH, David

David Brossard
  • 13,584
  • 6
  • 55
  • 88
  • 1
    Appreciated, I see that you are an editor of the XACML standard, so the answer is pretty authoritative, are the industry happy with these any of these two approaches? are there any better alternatives for this use case? The first one requires you to know in advance which item to ask permission for, this is sometimes recursive - often you want a framework/standard to tell the code which items it should process, i.e. which item to return to the user is defined by some configured policy, not the code. – Incömplete Aug 25 '22 at 01:56
  • 1
    I do not have any experience with the second approach, but it seems to be expensive to implement, basically the code needs to interpret the response and support the retrieval of all kinds of attributes and evaluate them, so basically turning the code into a mini decision engine? – Incömplete Aug 25 '22 at 01:56