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

Yoichi, Paul,

There are few points that I want to comment on:

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

F(Bag-of-string, Expr) = String

Expr is a XACML expression (actually it was a variable ref in my case) evaluated to an integer that represents a string index in a bag
Bag-of-string - is a bag of strings
String - returned value, which is the string with the index provided by Expr

I'm not sure what other details I can provide, except that I didn't make up the example, I needed it to return a message from a policy.

I'll try to generalize that "rigidness" problem. XACML defines expressions and variables just like any programming language, but it stops short from making expressions commonly available everywhere and suggests using static (or literal) content instead.

 AttributeValueType can't have expressions (e.g. variable references) inside. It means that constructs like AttributeAssignment that is used to define Obligations can't not contain expressions that will be interpreted by a PDP engine. It means that content that I can put to obligation is very much static. If you don't believe me, here is yet another simple puzzle:

You've assigned a value to a variable Var1 somewhere in a Policy: 

      <VariableDefinition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; VariableId="Var1" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">

Now try to return the value of this variable in an Obligation. I would be surprised if you can.
It's very good that you've mentioned loops. I was thinking about them too and would like to have them in XACML, otherwise simple cases can easily become complicated.

2. It's good that AssociatedAdvice was introduced in XACML 3.0, but  can I put an expression to AssociatedAdvice that will be interpreted by a PDP before a response is sent back to a client? The second qs: why it was named as an "advice"? Can't we have it more generic by calling it DecisionDetails and allowing any details that might be related to a decision? Advice is just one particular case, right? 

3. Returning to ambiguity of semantics, let us look at Farrukh's reasoning:


Yes, Farruck, in this interpretation it doesn't make too much sense, but you've missed in my initial message the fact that Resource is actually a domain (or set of resources if you wish). In this interpretation you could return a Deny if a subject doesn't have any access to any resource in a domain and Permit otherwise. In the latter case you would need to build your name->value map as follows:



I don't see any contradiction with the spec if you interpret it this way. You can put the details to that "AssociatedAdvice" field  and this is yet another reason to rename it to  DecisionDetails. I also completely agree with Paul who was saying that if a client is required to send ALL resources to get permissions to some of them, it might be problematic becuase you don't want all users to know about existence of all resources on the system. It just can empower a potential attacker to further hack the authz system in which case knowing that a resource with a certain name exists is a big aid for him (it's a very common finding in many security assessments).

But again, we're moving essential part of authorization from Policies that are formalized well (more or less) to PEP and PIP that are not formalized at all, if adopt the proposed solution. Probably Rich's proposal will help with solving this particular case.

----- Original Message ----
From: Yoichi Takayama <takayama.yoichi@gmail.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>; Ralf Lorenz <rol@mms-dresden.de>; xacml-users@lists.oasis-open.org
Sent: Sun, April 18, 2010 6:09:38 PM
Subject: Re: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

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.


To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org


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