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

[Oleg Gryb <oleg_gryb@yahoo.com>]

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. 


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.


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




----- 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: Fri, April 16, 2010 8:31:28 PM
Subject: Re: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

Hi Oleg,

By no means, I am involved in compiling XACML specification. I am merely a implementor and the user of XACML. So, whatever I say is my personal view and opinion.

(A)

I forgot that the Obligation element can be used when the Decision is not Permit. My apologies on that.

However , my understanding is he Obligation describes what a PEP should do AFTER dealing with the Decision. First, process the Decision. Second, handle the Obligation.

1) Regardless whether the Decision is Permit or Deny, the intention of the Obligation does not seem to be for passing on what Action(s) the Subject(s) may or may not do on what Resource(s). The Permit or Deny is already decided, then the Obligation is something else to do after that.

2) The current XACML does not provide computer-readable syntax to pass-on some Attributes or instructions about what Action(s) the Subject(s) may or may not do on what Resource(s) or what the Obligation should do if such information is passed.

XACML is designed to query one Query on Subject(s), Action(s) and Resources(s), and return a Response with the Decision(s).

What you are trying to do is what PEP should do BEFORE asking about Permit or Deny, to formulate a proper Query.


(B)

When we were implementing a system based on XACML, it was a common situation that the question about what Action(s) the Subject(s) may or may not do on what Resource(s) was often raised. So, I am not a stranger to the programming or architecture design problem that you describe.

It is my opinion that you can always design a system that does not have to ask this kind of question, i.e. a single question expecting complex or multiple answers. If you have to ask that sort of question, you may be designing a system (or the human interface or the workflow) in a wrong way. I think that this is also what Paul is trying to say.


(C)

To me, it seems that you can do it with the standard XACML multi-quetion Query.

To ask what Action(s) the Subject(s) may or may not do on what Resource(s), you can use the standard XACML multi-question Query. The PEP must use two separate lists of Actions and Resources. The Query can be made with multiple questions using Action vs. Resource combinations from the lists . The Response from the PDP (Decisions) can be used to construct the outcome, i.e. what Action(s) the Subject(s) may or may not do on what Resource(s). 

In this case, "what Action" or "what Resource" is already known. "What the Subject(s) can do?" is translated and broken down to "Can the Subject(s) do this on that?".

This, however, requires a signal to the PEP (or its pre-processor) that it is not going to ask whether the user can proceed to "do this" or "go there", but rather ask about making a list of what Actions and Resources are Permitted or Denied. 

Imagine that you have to make your own framework that can achieve the same thing. If you are asking "What are permitted for this USER?", somewhere down the line your system would be asking, e.g. "Can this USER do READ on resource X?" or "Can this USER do WRITE on resource Y?", anyway. XACML is providing a framework to do this sort of thing at the PEP level, i.e. Query formulation (or its pre-processor).

(4)

Say, it is a multi-Decision Response, does it qualify as your "Decision Details"? If it does, you do not need any new "field" in the XACML Response.

(5)

To allow flexibilities with which XACML Policies are used in various systems, what exactly PEP does is not rigidly defined in XACML specifications. So, I don't see that this is a limitation of XACM but a built-in feature that allows the implementors to implement custom extensions or each suitable solution.

(6) 

I do not understand your statement that "XACML Policies are very rigid and lacking dynamics ...". XACML Policies are equivalent of writing controlling logics in any programming language, the purpose of which is to provide a data structure that can produce permissions based on logics and built with a modular structure, i.e. combinations of smaller logical fragments (sub-Policies).

What you are trying to say may be that the XACML framework seems to be inflexible in terms of what you would like to achieve, because it does not seem to be possible to adopt it to supply functionalities that are required by the system design of your choice.

PDP, PIP, PAP, and the Policy Store can be off-the-shelf. However, I still do not see (or expect) any XACML library that can be used without your providing an appropriate PEP. This is because a PEP is normally very tightly tied with what your system does, i.e. what Actions and Resources are dealt with. Since these can't be generalised in a standard, it is left out as implementation-dependant. I think that this is quite acceptable at this time.


(7)

In all, the XACML is merely a rule engine (based on Policies and Attributes) and the access control (i.e. PEP) is in a different domain. XACML is not a total solution for access control as a whole. So, expected work there is just acceptable, neither more nor less of many adopter expectations, I believe.

The good thing about XACML is that it seeks a uniform solution to handle authentication and authorisation based on Attributes and other related building blocks, providing SAML, XACML, etc. related standards.


(8)

Many discussions and arguments on this list seem to be arising from lack of understanding, confusion or misunderstanding about how to use or adopt XACML. Not purely from what it should be or what it should be able to do from legitimate footing. So, in my opinion, the fact that there are many "discussions" on this list should be discounted. Not all deserve a proper credit to qualify as pointing to potential deficiency or flaw of XACML.

Yoichi


On 17/04/2010, at 1:36 AM, Oleg Gryb wrote:

> Yoichi,
> 
> I could see two problems here:
> 
> 1. We've already discussed this in the past and some were saying that it's OK to use obligations like "Show Authz Error Details" in the case when a decision is "Deny". Difference in opinions means that use of oblogations is not defined well.
> 2. If Oblogations should not be used this way then what alternative do we have? I would suggest to add a field to a PDP response that is not of static type. It should be a XACML expression. Call it whatever you want, e.g. "Decision Details".
> 
> Ralf's use case provoked me to express some thoughts that you might not agree with,  but,  I think, they are important for somebody who tries to use XACML in their business applications: 
> 
> 1. XACML - is not a complete, ready to use authorization solution, it's rather a brick, maybe even a corner stone, in your authz solution.
> 2. XACML practical value is very limited in many cases without PIP and PEP that are defined at conceptual level only.
> 3. In many cases you need to do a lot of plumbing around PEP and PIP to meet your business requirements.
> 4. XACML Policies are very rigid and lack dynamics of a programming language, thus you need to write your custom code somewhere else (e.g. in PEP and PIP services).
> 
> 
> Thanks,
> Oleg.
> 
> 
> ----- 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: Fri, April 16, 2010 12:28:26 AM
> Subject: Re: [xacml-users] retrieving a list or query filter of resources the caller is authorized for
> 
> It is my understanding that the Obligation is not to be used that way.
> 
> It is to define enforceable or un-enforceable condition of use.
> 
> That is sent to the execution system to act upon AFTER a PDP has passed the Decision Permit. (Obviously, in other Decisions, the Obligation is not used).
> 
> How the Obligation is handled is not defined in XACML itself. So, maybe we can say that it is at the liberty of Obligation implementor and the execution system implementor. I think that an example was like; the user interface displays a dialog to ask the user to tick "I agree with these terms and conditions" and press OK (or disagree and cancel). 
> 
> In another case; if it required that the user is a member of a certain subscription or rights etc., the system may be able to check those attributes transparently. That is beyond XACML.
> 
> This takes place only when the resource is about to be consumed by the end user.
> 
> Yoichi
> 
> On 16/04/2010, at 2:12 AM, Oleg Gryb wrote:
> 
>> Paul, 
>> 
>> Multiple profile is defined and implemented by some engines in XACML 2.0 as well.
>> 
>> Ralf,
>> Here is a solution that you might want to consider, but I'm not sure how pure it is from XACML point of view. Try to use obligation concept: the XAML resource in your solution should be a domain, not 2000 resources. The Obligation should be: "Show a list of all resources that this subject has access to". It's just an idea: I did something like that when was trying to implement "Display Authz Error Details" obligation. It was not easy, but doable. The policy might be complicated though with such an approach.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
> 
> 
> 


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