Let's say I have a collection transactions and a policy that grants read access to a transaction within that collection for users with the role user, if the user's department is the same as the on of the record.
The Problem: If I access single resources I have no problem checking access per resource. But if I want to enumerate/ list the whole collection I would need to check each and every item in the collection which is not efficient (especially if you amount of entries is "high").
It would be more efficient, if the PDP could return the information to the PEP that the list of entries needs to be filtered by the department (and the PEP could pass this on to the underlying data store).
I thought about using obligations for this but as far as I can see they should not contain AuthZ relevant information.
So how can this be tackled?
You bring up an excellent point. XACML was designed for what I would call transactional authorization i.e. authorization a specific transaction or flow. For instance:
The challenge is when you want to control access to a large or even an unknown number of items. In that case, you could (in theory) just send a large number of requests. You could even leverage the Multiple Decision Profile of XACML which allows you to create requests such as:
You then get back as many answers as you had MDP elements in the request. You can even do a matrix e.g.
However, it still does not scale that well (it can go up to the thousands but hardly millions) and it won't work in pagination scenarios and when you do not know how many items you have. It does not work in pagination because imagine you retrieve 10 items (via pagination) that you will display and then you authorize each one. You run the risk of having less than 10 items on your page which breaks the user experience.
In your question, you allude to using obligations and advice. That is an option but you are right about the drawback. It hides authZ semantics inside the advice and it makes the single case harder. This is what your policy would become
This puts a lot of work on the Policy Enforcement Point (PEP).
So what's the alternative?
Axiomatics (which - disclaimer - is where I work) came up with a new API on top of the PDP that lets you query policies in an open-ended way called the Reverse Query. Here is a developer post on the topic.
Rather than sending in a full-blown XACML requests, you send in a partial request (an open-ended question) e.g.
The request can be as generic or as specific as need be. The following are all valid requests:
The response will be a set of filter expressions computed from the policies that must be met.
Given the policy previously stated
Possible answers would be
The requests in the example aforementioned focus on Alice. You could have focused on the resource (medical record) instead or even the action. You get to choose.