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.
Yoichi
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 it differently.
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 library.)
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.
Regards, --Paul On 19/04/2010, at 10:26 PM, Farrukh Najmi wrote: Hi all,
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.
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com
|