[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Features for XACMLv3
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. > 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. > 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. > 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? 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. 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. I think your use case is better handled by introducing dynamic parameters to obligations. 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]