xacml — archive

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

From: Carlisle Adams <[email protected]>
To: [email protected]
Date: Thu, 31 Jan 2002 17:29:00 -0000

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:[email protected]] 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: [email protected] 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 >