[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml][model] XML Acess Control use case for policy, rule,applicability
The following is a use case of the XML access control (target resource is XML instance). I assume here that an access request consists of a principal, a target XML file name, a target element name (XPath), and an action. An example of the access request: (Alice, medicalRecord.xml, /chemotherapy, read) The target resource specification might be concatinated by "/" (I use this notation in the following specifications): (Alice, medicalRecord.xml/chemotherapy, read) The policy I want to specify here is: 1. In the target resource classification, applicability is specified using the DTD name of the requested XML file. 2. In the policy, each rule consists of XPath expression and principal name. For example, the policy below means that "doctor can read <chemotherapy> and <drug> element of any XML instance that is based on medicalRecord.dtd" and "nurse can read <drug> element of any XML instance that is based on medicalRecord.dtd". The external function "xpath" returns "true" or "false" depending on the target element name specified in the access request. I use the syntax of ver 0.8 here. <target resourceClssification="medicalRecord.dtd" resourceAction="read"/> <policy> <or> <and> <extFunc name="xpath" value="/rec:patient/rec:chemotherapy"/> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">doctor</value> </equal> </and> <and> <extFunc name="xpath" value="/rec:patient/rec:drug"/> <or> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">nurse</value> </equal> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">doctor</value> </equal> </or> </and> </or> </policy> For example, if the access request is (Bob, medicalRecord.xml/chemotherapy, read) and Bob is a doctor, then the access decision is "grant". If the access request is (Alice, medicalRecord.xml/chemotherapy, read) and Alice is a nurse, then the access decision is "deny". If the access request is (Alice, contract.xml/companyName, read), then the decision is Indeterminate because contract.xml is not medicalRecord.dtd. I show a different specification here. It does not have the body of the policy. If the access request that matches the target applicability test, it automatically means "grant" here. <target resourceClassification ="medicalRecord.dtd/rec:patient/rec:chemotherapy" subjectClassification="doctor" resourceAction="read/> <policy> <true/> </policy> <target resourceClassification="medicalRecord.dtd/rec:patient/rec:drug" subjectClassification="doctor" resourceAction="read/> <policy> <true/> </policy> <target resourceClassification="medicalRecord.dtd/rec:patient/rec:drug" subjectClassification="nurse" resourceAction="read/> <policy> <true/> </policy> Finally, I show another specification of "triple" oriented syntax based on my extension model proposal. <target resourceClssification="medicalRecord.dtd" resourceAction="read"/> <policy> <grant> <rule> <resource> <extFunc name="xpath" value="/rec:patient/rec:chemotherapy"/> </resource> <principal> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">doctor</value> </equal> </principal> <preCondition/> </rule> <rule> <resource> <extFunc name="xpath" value="/rec:patient/rec:drug"/> </resource> <principal> <or> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">doctor</value> </equal> <equal> <valueRef attributeName="saml:NameIdentifier/Name"/> <value xsi:type="string">nurse</value> </equal> </or> </principal> <preCondition/> </rule> </grant> </policy> <grant> element explicitly specify that the semantics of the rules are bound to grant/deny semantics as we have discussed. Each rule under <policy> element is connected disjunctively. <resource> and <principal> specify the condition on resource and the condition on principal, respectively. Those conditions and <preCondition> expression are conjunctively connected. In <preCondition> element, policy writer can write any Boolean expression as the current specification (no expression in this example though) Best regards, Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC