|I don't see a problem with it.|
That is almost exactly what happens with XACML multiple question Query. Although XACML does things differently than ebXML, it does it alike.
For example, a system may have an Action called "List", which asks for a list of all metadata about some topic specified e.g. in a digital repository search. This may issue an XACML Query with multiple Actions and multiple Resources.
XACML Query returns multiple Permitted and Denied Decisions for Actions x Resources combinations, because some items may be authorised for Read only for metadata, READ for actual Resource, WRITE for create/delete/update if the user owns the Resource or a librarian. It is a common Use Case that some Resources demand that even the metadata or the names of the Resource (i.e. the existence of it) should be hidden.
Depending on the Resources and the interfaces, the system will display only relevant items on the list with indication of what Action(s) the user may take on the Resources.
This is a common problem.
Only that XACML does not distinguish READ and WRITE to impose the authorisation decision before or after the Action. It applies the Decision for the Action before that Action takes place.
To me, it does not make sense to read the Resource first and then Deny to give it to the user if we knew that the Resources was to be Denied to the user before the system was to READ the Resource. It does an Action the results of which is not going to be used.
On 20/04/2010, at 1:21 AM, Tyson, Paul H wrote:
Farrukh brings up a different problem. This might be what the original
post was talking about, but I understood the original problem was to
return all the permissions (actions+resources) for a subject in a
domain. Farrukh interprets the use case differently. It's possible
this is what the original post was describing. If so, we must analyze
A list of attribute values about things is not the same as the
collection of things represented in the list. If the things to be
controlled are "documents", it does not necessarily follow that the
titles, dates, and authors of those documents are also controlled in the
same way as the documents themselves.
There may be good reasons why you would not want to show inaccessible
items on a list, but it is important to understand the reasons so that
you solve the right problem in the best way. If it is just for
convenience (shortening the list for the user), that is not really an
access control problem. If certain users should not even know that a
document exists (by seeing its metadata in a list), that is an access
control problem. Your ruleset should cover not only the documents
themselves, but controlled metadata about the documents as well. (There
are cases where you want metadata to be freely accessible, but you want
to control access to the documents themselves--such as a subscription
It is sometimes OK in practice to ignore the distinction between
resource and metadata, and implement a solution such as Farrukh
described in the ebXML domain. But you should be aware that you are
using rules and decisions about resources to control metadata about
those resources--essentially this is an additional, hidden rule.
This analysis does not help solve the potential performance problem of
filtering a list by making multiple requests from a XACML PDP. Rich
Levinson has discussed (in another response) using regular expression
matching on resource IDs to accomplish this efficiently.
There are further opportunities to develop workable solutions for
handling lists of metadata about controlled resources using XACML.
On 19/04/2010, at 10:26 PM, Farrukh Najmi wrote:
I am not quite understanding the issue here. So please forgive me if my response below if missing the point.
The use case being discussed "filtering resources based on read access permission"
is exactly one of the use cases for the OASIS ebXML RegRep standard which uses XACML 2.0 for access control of its
managed resources. An implementation simply processes a QueryRequest and fetches database objects based upon the
details specified for the query in teh QueryRequest. Before returning the matches resources in the QueryResponse the server
performs an XACML accession decision for each resource matched by the query. If access to the resource is not permitted then the server
simply filters out the resource from the response. The resources it ultimately returns are a subset of the originally matched resources
filtered based on access control decisions.
So while, WRITE requests (e.g. Create/Update/Delete) in contrast do their access control decision *before* writing to the database,
READ requests do their access control decision *after* reading from (querying) the database.
This has been working very nicely for the ebXML RegRep standard and its implementations and we have not found anything lacking in XACML.
Please let me know if I am misunderstanding the issue.