OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: Re: [xacml-comment] Features for XACMLv3


Hi David,

Yes, keeping the PDP stateless shifts the burden of state to somewhere 
else, but the point is to try to keep an architecture with clear 
separations of concerns. That means that the overall complexity of the 
whole system is less than if we put everything in a single big central 
piece of functionality.

Regards,
Erik

David Chadwick wrote:
> Hi Erik
>
> thanks for proposing a fix to XACMLv3 for the problem.
>
> Its also good that the request/response context changes as little as 
> possible, since in TAS3 we will have at least 3 different types of PDP 
> that will make decisions, and each will support the XACML 
> request/response context, but only one will support XACML policies. I 
> know of several research groups that are using the XACML interface but 
> not the XACML policy.
>
> Concerning state based vs stateless PDPs, the latter actually only 
> shift the burden of managing state elsewhere in the system. I dont 
> think they actually make anything easier from a system's perspective, 
> they only make the PDP easier, and something else more difficult.
>
> regards
>
> David
>
> 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.
>>
>> 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).
>>
>> 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
>>>>
>>>>
>>>
>>
>>
>



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