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


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]