xacml — archive

[Anne Anderson <anne.anderson@sun.com>]

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