CODEWITHSUNDEEP
authorizationaccess-controlxacmlxacml3abac
Claude Falbriard
Claude Falbriard

Reputation: 935

In XACML obligations why is the "fulfillOn" Attribute Reserved for Permit & Deny only?

Wonder why the WSO2 Balana framework at the Obligations statements only accepts fulfillOn argument for "Permit ", or "Deny" conditions, but ignores the "Not applicable" result, which also could be interesting to intercept and document in the logic flow to assist the policy debug process.

In source of Balana ObligationExpression.java we find: 

if("Permit".equals(effect)){
            fulfillOn = Result.DECISION_PERMIT;
        } else if("Deny".equals(effect)){
            fulfillOn = Result.DECISION_DENY;
        } else {
            throw new ParsingException("Invalid FulfillOn : " + effect);
        }

What is your opinion about it, is this logic working correctly?

Upvotes: 0

Views: 256

Answers (1)

David Brossard
David Brossard

Reputation: 13834

This is by spec. The XACML specification only allows obligations and advice to be returned on either of Permit or Deny. You have to keep that in mind when you build your policies. See below and here.

7.18 Obligations and advice

A rule, policy, or policy set may contain one or more obligation or advice expressions. When such a rule, policy, or policy set is evaluated, the obligation or advice expression SHALL be evaluated to an obligation or advice respectively, which SHALL be passed up to the next level of evaluation (the enclosing or referencing policy, policy set, or authorization decision) only if the result of the rule, policy, or policy set being evaluated matches the value of the FulfillOn attribute of the obligation or the AppliesTo attribute of the advice. If any of the attribute assignment expressions in an obligation or advice expression with a matching FulfillOn or AppliesTo attribute evaluates to “Indeterminate”, then the whole rule, policy, or policy set SHALL be “Indeterminate”. If the FulfillOn or AppliesTo attribute does not match the result of the combining algorithm or the rule evaluation, then any indeterminate in an obligation or advice expression has no effect. As a consequence of this procedure, no obligations or advice SHALL be returned to the PEP if the rule, policies, or policy sets from which they are drawn are not evaluated, or if their evaluated result is "Indeterminate" or "NotApplicable", or if the decision resulting from evaluating the rule, policy, or policy set does not match the decision resulting from evaluating an enclosing policy set. If the PDP's evaluation is viewed as a tree of rules, policy sets and policies, each of which returns "Permit" or "Deny", then the set of obligations and advice returned by the PDP to the PEP will include only the obligations and advice associated with those paths where the result at each level of evaluation is the same as the result being returned by the PDP. In situations where any lack of determinism is unacceptable, a deterministic combining algorithm, such as ordered-deny-overrides, should be used. Also see Section 7.2.

Allowing for obligations & advice on NotApplicable would be messy. Imagine the following policy structure:

  • PolicySet Main Policy
    • Policy Allow managers to view documents + obligation A on NotApplicable
    • Policy Allow employees to view documents in their own department + obligation B on NotApplicable
    • Policy Allow publishers to view and publish documents + obligation C on Permit

Imagine the request coming in is:

  • Request: can Alice the publisher publish doc #123?

In your world, the response would (could) be: Permit + obligations A,B,C

It doesn't really make any sense.

Upvotes: 1

Related Questions