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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


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


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]