Re: [xacml-comment] Features for XACMLv3

[Oleksandr Otenko <oleksandr.otenko@oracle.com>]

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

> I understand that there are many security models which are stateful, 
> but I think the XACML core should stay stateless. Stateful security 
> models can be handled by a separate state repository which exposes the 
> state in the form of attributes. Maybe such state repositories could 
> be standardized in the future, but I have other concerns about XACML 
> before that.
>
> Best regards,
> Erik
>
> David Chadwick wrote:
>> Hi Erik
>>
>> responses in line
>>
>> Erik Rissanen wrote:
>>> David,
>>>
>>> Thanks for the suggestions.
>>>
>>> However, I don't think the first suggestion is a good idea. The second
>>> seems better motivated, but I have concerns about how it can be
>>> implemented. I think there is a better alternative.
>>>
>>> See inline for details.
>>>
>>> David Chadwick wrote:
>>>> Dear XACML WG
>>>>
>>>> The EC FW7 TAS3 project (www.tas3.eu) is a user of the XACMLv2
>>>> specification. We note that it is missing a couple of features that we
>>>> will find useful, and wondered if they can be added to XACMLv3.
>>>>
>>>> The missing features are as follows
>>>>
>>>> i) the ability to make a "just checking" request to a PDP, for example
>>>> when preparing a workflow. Such requests allow checking whether
>>>> permissions are sufficient to perform a service call, without actually
>>>> performing the call. The reason why it is important for the PDP to
>>>> know that this is a "just checking" call rather than an access request
>>>> call, are several, including:
>>>> a) the PDP may be logging access requests and this should not be
>>>> logged as an access request in the audit trail
>>>
>>> Accesses should be logged at the PEP, not at the PDP. The PDP does not
>>> enforce access, it only "advices" the PEP as to what the PEP should do.
>>> The PEP invoking the PDP should know that it is only "testing", so it
>>> can avoid logging the access.
>>
>> I dont believe that logging requests should be purely a PEP issue. 
>> You can build a policy engine that will log requests made to it, so 
>> that policy writers can see if the policy decisions accord with what 
>> they think they should be. Thus the PDP seems a more natural place to 
>> log the returned decisions than in the PEP. But I agree with you that 
>> the PEP knows what it is doing and therefore it should take the 
>> primary responsibility for recording its purposes for making an 
>> access request, in which case the PDP can log all accesses regardless 
>> of the purpose.
>>
>>
>>>
>>>> b) the PDP may support separation of duties or other state based
>>>> access control decision making. The "just checking" request should not
>>>> change the internal state of the PDP, whereas an access request could.
>>>
>>> XACML is stateless, so I don't agree with this. Any state should be
>>> handled by the PEP, which would know that it was only a test request.
>>
>>
>> Is it a policy of the XACML group that an XACML PDP should always be 
>> stateless? The concept of state and "retained ADI" has been in the 
>> ISO 10181-3 access control model for over ten years. I thought 
>> building a stateless XACML PDP was simply a pragmatic short term 
>> solution that had been taken by the first implementers, since it is 
>> much easier than building a state based one. Am I wrong on this? 
>> Obviously I have not participated in your group's discussions so I 
>> dont know what your policy is about this.
>>
>> However, one can argue that the PEP does not need to know if the PDP 
>> is state based or not, or what the policy is, but the returned 
>> decisions would often be different for the same request, if the PDP 
>> retained state or did not (e.g. consider a policy which says three 
>> failed logins then obligation "suspend user's account". Or consider 
>> withdrawing money from an ATM machine when the policy has a daily 
>> limit or does not have a daily limit. The application does not need 
>> to know about this, its a policy issue, but the result will be 
>> different for different policies).
>>
>> So I would be interested to learn what the groups policy is about 
>> state based PDPs.
>>
>>
>>>
>>>> c) the PEP may or may not want obligations to be returned on a just
>>>> checking request, depending upon whether it checks the obligations as
>>>> well. If it does not, then it would improve performance to not return
>>>> the obligations.
>>>
>>> The performance gain from not having to return obligations in this case
>>> would be negligible. I would not like to add a specific feature in the
>>> spec just for this reason.
>>
>> I agree. This on its own is insufficient. I think that the state 
>> reason is far more important.
>>
>>
>>>
>>>> ii) the ability for the PDP to return the set of attributes from the
>>>> request context that were used in the rule for the decision that was
>>>> returned. In previous messages I have given Erik the rationale for why
>>>> this is needed (e.g. a returned obligation performs some action based
>>>> on the role of the accessor, but the request context contained several
>>>> irrelevant roles that were not used in the decision making).
>>>
>>> The problem with this suggestion is that it is difficult to define what
>>> is meant by "that were used". Would this include any attribute which 
>>> was
>>> in any way referenced by the policies? 
>>
>> I think its quite clear. When the policy decision is grant (in the 
>> case of deny overrules) or deny (if grant overrules) (ignore not 
>> applicable and indeterminate since the PDP could not reach a 
>> decision) then at least one rule must have given this result. So you 
>> return the attributes from only those rules (usually just one) that 
>> returned the result that is returned to the user.
>>
>>
>> In that case you would get lots
>>> of irrelevant attributes in your result since the PDP may contain
>>> policies about different resources and users, meaning that many 
>>> policies
>>> would not match. 
>>
>> this is clearly not the semantics that are required.
>>
>> You would also get attributes listed which were not
>>> part on the request, since the fact that some attribute was missing
>>> could have been decisive.
>>
>> But missing attributes would ensure that the rule did not fire, so 
>> the attributes from this rule would not be included in the result.
>>
>> What we want to know are the attributes that caused the rule or rules 
>> to fire that gave the returned result.
>>
>>
>>>
>>> I think your use case is better handled by introducing dynamic
>>> parameters to obligations.
>>
>> this is an OK idea anyway, regardless of the above, and is orthogonal 
>> to the above (although it does solve the particular use case that we 
>> have).
>>
>>
>> thanks for suggesting this. However it does mean that a PDP will now 
>> have to look inside obligations and previously it did not have to. So 
>> this will slow down decision making.
>>
>> regards
>>
>> David
>>
>>
>>>
>>> Currently obligations contain only static attribute assignments. If we
>>> would change the schema so we also allow an Expression in the
>>> obligation, the content of the obligation which is returned could be
>>> dynamically generated and you could select the correct role into it in
>>> your policy.
>>>
>>> I am cross posting this to the TC mailing list. I think it would be a
>>> good idea to allow dynamic obligations in 3.0. I suspect it would solve
>>> the issue John was talking about on the last call, and it would solve
>>> David's use case. And I think it would be a very useful feature in
>>> general, with little cost since a PDP implementation has to be able to
>>> evaluate expressions anyway.
>>>
>>> Best regards,
>>> Erik
>>>
>>>
>>
>
>