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

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

> -----Original Message-----
> From: Oleg Gryb [mailto:oleg_gryb@yahoo.com] 
> Sent: Sunday, April 18, 2010 10:49
> To: Yoichi Takayama
> Cc: Tyson, Paul H; Ralf Lorenz; xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] retrieving a list or query filter 
> of resources the caller is authorized for
> 
> Yoichi,
> Here is a very simple example of what I call "rigidness":
> 
> I need to extract a string from a bag using a XACML 
> expression as an index. It's a trivial task in any 
> programming language, but try to do it in XACML.

Can you explain this problem better?  Depending on the context, it seems
like you could do it with the XACML "string-equal" function or one of
the "any-of*" family of functions.

> 
> 
> Let us look at Ralf's use case  again. In essence, it looks 
> like a very simple authz related functionality: "give me a 
> list of all permission for a subject". 

The "simple" or "basic" access control problem is of the form, "Can
subject S access resource R?", and I cannot imagine any problem of that
type which cannot be handled by XACML.

> It seems to me that 
> the only solution that was suggested here was to send all 
> 2000 resources in a PDP request each time when this decision 
> needed. That solution looks inefficient to me. 

"Give me a list of permissions for a subject" is a different type of
problem--one of analysis or summary.  In Ralf's use case it is
apparently a necessary stage to providing real access control at
runtime, because the system does not provide an access control point at
which a decision on an individual subject and resource can be requested.

There is no doubt that by "pre-cooking" all possible authorization
decisions into "roles" or "permissions" you can achieve optimum runtime
performance, because these can be executed by bitmap masking or SQL
query filters.  But you sacrifice some flexibility, transparency, and
provability.

I suggested how you can use a XACML PDP and ruleset to derive a set of
pre-cooked decisions that could be fed into some native system of access
control.  That this approach is inelegant and possibly
resource-intensive is because it is using XACML in a way that it wasn't
really designed for.  However, it will guarantee that actual runtime
decisions (of the form, "Can S see R?") conform to your ruleset.

> More 
> reasonable solution could be probably achived by using that 
> new "AssociateAdvice" constract in XACML 3.0, but in this 
> case you'll need to do "a lot" (see my definition of "a lot" 
> in the message to Paul) of coding in PIP and PEP.

Advice is supposed to be "extra information about a decision", not "how
to make a decision".  Using Advice in this way would make the PEP do
some of the duty of the PDP, with possible undesirable consequences.

Regards,
--Paul