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

[Yoichi Takayama <takayama.yoichi@gmail.com>]

On 19/04/2010, at 1:48 AM, Oleg Gryb wrote:

> 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. 

"Extracting" in what way and what do you want to extract exactly, and where from? 

Presumably from a result of a function which returns a bag?

It seems that you want to have a loop structure in the Policies and use this "index" value for later use. If that is the case, I don't recall XACML having any loop structure in it syntax. So, of course, the Policies are not of a programming language and not built to achieve things in that way.

As Paul was saying, normally you should rather have a reference valuable in the Policy and compare it with what the Bag contains. That function must have a "loop" logic within itself.

I don't see any way to extract each value out of a bag, of course. Since the Policy has no loop logic structure in the rest of the grammar, however, there is no need to extract values from a bag and iterate though it later. I don't agree or disagree with this choice of the XACML language design, but I see that it is how the XACML designers defined things.

I was faced with situations where I felt there should be a bit more functions of my disposal to achieve things more easily, but yet have not found a situation where I could not achieve things by using XACML grammar alone.

If this interpretation is wrong, you need to spell out your case as Paul was saying.


> 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". 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. 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.

AssociativeAdvice is yet intended for different purpose. The decision was already made about the user Action.

As Paul was saying that "What can this user do?" is a different question altogether from "Can this user do this?". You are asking for information BEFORE any Action has been committed.

We often discussed among ourselves that it may be possible that the XACML Policies may compile into some rule engine or rule store for efficiency (If there are many Policies, parsing them may take time). If that is possible, you can ask your type of question to the rule engine or rule store direct in pre-processor for PEP or separate from PEP.

> 
> Yet another thing that I don't understand in your message is "off-the-shell" PIP and PAP. How can it be, considering that PIP might be very specific to custom data store and data store types (LDAP, DB, ActiveDir, file system, etc.)?
> 

What I mean is that, like Sun's XACML library, a PIP can be made of a standard part and plugins. The standard part is off-the-shelf. It implements some internal interface between it and the PEP and PDP, and between it and the plugins. Since the XACML standard does not define the interfaces, this is totally implementation dependent. (It defines the interface between PEP and PDP).

Each plugin understands how to get a particular Attribute, i.e. where to get it, how to get it, and whether there is a need for converting some value to an Attribute.

Yoichi