OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for


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

________________________________

	From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] 
	Sent: Monday, April 19, 2010 07:26
	To: xacml-users@lists.oasis-open.org
	Subject: Re: [xacml-users] retrieving a list or query filter of
resources the caller is authorized for
	
	
	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.
	



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]