Re: [xacml-comment] Features for XACMLv3

[Erik Rissanen <erik@axiomatics.com>]

Hi Oleksandr,

What I meant is that the spec is "easier" to define and deploy. Yes, it 
is true that there are valid reasons for a stateful model since it makes 
modelling easier.

I would say that doing stateful XACML right now is out of scope. We are 
just about to freeze the 3.0 core.

My hunch for the long term future is that state is handled better by 
means of a state module in a profile, rather than extending the current 
core, but I cannot say really that I know since I haven't done any work 
on it. I think a lot of stateful models can be implemented by means of 
state change in attributes.

Doing stateful XACML would probably have to start from reviewing the 
research literature to find a general purpose state model which can 
augment the core.

If you have a lot of knowledge on the topic, I think the TC would 
welcome you to join and contribute to such an effort. After all what 
happens in the TC is very much determined by the members themselves 
willing to make the effort to produce the work. :-)

Regards,
Erik

Oleksandr Otenko wrote:
> Hi Erik,
>
>
> Erik Rissanen wrote:
>> Hi David,
>>
>> I will make a proposal for the TC to change the obligation parameters 
>> to an expression. I don't think the performance issue is a major 
>> concern. It's a cheap operation to test whether the obligation has a 
>> constant parameter of whether it needs to be evaluated. In any case, 
>> this is going to be cheaper than the approach of returning "used 
>> attributes" since you can be more specific in your policy with the 
>> dynamic obligation approach.
>>
>> Regarding state in XACML, my personal opinion is that it is a 
>> strength of the core XACML specification that it is stateless. It 
>> makes many things easier.
>
> Is "it makes many things easier" in the sense "it makes many things 
> easier to model"?
>
> I think stateful security models introduced state on purpose, just 
> because it is hard to model stateful decision-making using a stateless 
> language. State in decision-making basically reflects the fact that 
> the decisions made now depend on other decisions enforced earlier. The 
> domain of such processes is so vast that I am surprised you are proud 
> of keeping them out of the spec indefinitely. I understand it may not 
> be in the scope of XACML right now for other reasons.
>
> Maybe I don't understand the scope of problems XACML got to solve, and 
> the problems out of the scope of XACML.
>
>
>> First, the specification itself becomes simpler since it isn't 
>> "self-modifying", like a stateful approach would be in a sense.
>>
>> Second, something stateless scales much better than a stateful PDP. 
>> If the PDP is stateless you can put up any number of instances to 
>> load balance over without any need of synchronization (except the 
>> policies and any configuration state of course).
>
> Scalability is not important, if you can't model what you want.
>
> Stateless PDP is good for stateless systems, like Web Services. 
> However, I draw your attention that the Web Resources used by the Web 
> Services are stateful, and access to these cannot be adequately 
> modelled using stateless PDPs. Note also that synchronization of PDPs 
> is not the bottleneck in this case, if the stateful Resource requires 
> exclusive ownership for the duration of access.
>
> Is access control to stateful Web Resources out of scope of XACML?
>
>
> Regards,
>
> Alex