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



> 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


David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5


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