RE: [xacml] [model] New Issue: applicability

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: RE: [xacml] [model] New Issue: applicability

Hi Anne,

Your example is interesting -- and realistic -- but I don't think it forces us into either of your proposed resolutions below.  As you correctly stated, the specific policy you gave as an example is only designed to cover a subset of the approval requests.  But the current syntax already allows this.

Consider an expanded version of your example (which is even more realistic).  The real policy regarding "approval" of an employee_status_change_form will require a number of things.  For example, certain mandatory fields must be filled in (such as the name and employee number of the person that this change form is about), the effective date (i.e., the date this change is to take effect) must be greater than or equal to the date the change form is signed, and the signer title is either a director or, if the status_change is "terminate" and the age is >= 50, a VP.  Anyway, you get the picture:  there are lots of rules about what will make the form acceptable for the "approval" action.

So, the policy is written something like this:

[same target as you have below]
<policy>

    <and>

        <present> employee_status_change_form/employee_name     </present>

        <present> employee_status_change_form/employee_number </present>

        <greaterOrEqual>
                employee_status_change_form/date
                currentDate()
        </greaterOrEqual>

        <or>

            <and>
                <equal>
                        employee_status_change_form/status_change
                        "terminate"
                </equal>
                <greaterOrEqual>
                        employee_status_change_form/age
                        "50"
                </greaterOrEqual>
                <equal>
                        employee_status_change_form/signer_title
                        "VP"
                </equal>
            </and>

            <and>
                <not>
                    <and>
                        <equal>
                                employee_status_change_form/status_change
                                "terminate"
                        </equal>
                        <greaterOrEqual>
                                employee_status_change_form/age
                                "50"
                        </greaterOrEqual>
                    </and>
                </not>
                <equal>
                        employee_status_change_form/signer_title
                        "Director"
                </equal>
            </and>

        </or>

    </and>

</policy>

I've left out some syntax (especially <valueRef> and <value> elements) to make the presentation clearer.  The point is that a subset of the overall policy is written as a subset (whether it is explicitly included or simply referenced).  There should be no conflict with applicability.  I don't think that we need to change the <target> syntax, or add <if>, <then>, and <grant> elements to the <policy> syntax, to achieve what you're looking for.

Carlisle.

----------
From:   Anne Anderson[SMTP:Anne.Anderson@Sun.com]
Sent:   Tuesday, January 29, 2002 2:46 PM
To:     XACML TC
Subject:        [xacml] [model] New Issue: applicability

I don't know if this belongs under "Rules", "Applicable Policy",
or "Syntax", but it is the issue I raised at the end of the
Policy Model conference call on 28 Jan.

ISSUE: In <applicablePolicy>, the <target> element is not as
fine-grained as the <policy> element, so <target> can indicate
that policies are applicable where they should not be.

EXAMPLE: Sun's Human Resources Dept. generates a policy that
firing (terminating) an employee who is over age 50 requires the
signature of a VP on the termination request
(employee_status_change_form).

<applicablePolicy ...>
    <target resourceClassification="sun:employee_status_change_form">
        <saml:Action>"approve"</Action>
    </target>
    <policy>
        <and>
            <equal>
                <valueRef>
                    sun:employee_status_change_form/Action
                </valueRef>
                <value>
                    "terminate"
                </value>
            </equal>
            <greaterOrEqual>
                <valueRef>
                    sun:employee_status_change_form/Employee_Age
                </valueRef>
                <value>
                    "50"
                </value>
            </greaterOrEqual>
            <equal>
                <valueRef>
                    Resource/employee_status_change_form/Signer_Title
                </valueRef>
                <value>
                    "VP"
                </value>
            </equal>
        </and>
    </policy>
</applicablePolicy>

Every approval request where the resource is a
sun:employee_status_change_form will select this policy for
evaluation.

The <policy> will return TRUE only if the Action field in the
form is "terminate" AND the Employee_Age field is greater than or
equal to "50" AND the Signer_Title field is "VP".

This means all other approval requests will return FALSE.

Assuming this <applicablePolicy> is the base policy, With our
current semantics, this means that all other approval requests
will return DENY-ACCESS.  Yet the policy was only designed to
cover a particular subset of approval requests.

SOME POSSIBLE RESOLUTIONS:
1. Allow <target> to contain optional arbitrary boolean
   conditions, in addition to resourceClassification and
   subject.  In this case, the <greaterOrEqual> test would be
   moved up into the <target> element.  We could document that
   policies that require such conditions may not be indexed
   efficiently.

2. Allow <policy> element to return a value of NOT-APPLICABLE.

   One possible syntax:

   Add an "applicability test" syntax to <policy>.  In the
   example syntax below, I have stolen Simon's <grant> element
   name because there are some similarities.  A <grant> element
   has the semantics that "if the <if> predicate is FALSE, then
   the <grant> returns NOT-APPLICABLE.  Otherwise, the <grant>
   returns the result of the <then> predicate.

    <policy>
        <grant>
            <if>
                <and>
                    <equal>
                        <valueRef>
                            sun:employee_status_change_form/Action
                        </valueRef>
                        <value>
                            "terminate"
                        </value>
                    </equal>
                    <greaterOrEqual>
                        <valueRef>
                            sun:employee_status_change_form/Employee_Age
                        </valueRef>
                        <value>
                            "50"
                        </value>
                    </greaterOrEqual>
                </and>
            </if>
            <then>
                <equal>
                    <valueRef>
                        Resource/employee_status_change_form/Signer_Title
                    </valueRef>
                    <value>
                        "VP"
                    </value>
                </equal>
            </then>
        </grant>
    </policy>

    We could allow multiple <grant> elements, with <policy>
    returning the result of the first <grant> element whose <if>
    predicate is TRUE.  If none of the <if> elements is TRUE,
    then the <policy> would return NOT-APPLICABLE.

--
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>