[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Comments on xacml-profile-hierarchical-resources draft
On 15 July, Bill Parducci writes: Re: [xacml] Comments on xacml-profile-hierarchical-resources draft > exactly. so at the risk of sounding obtuse, aren't you just using an > existing function to match XPath on <md:PatientName> and <md:Physician> > combining the input with an OR function? (which is how i was thinking > this would be handled in my previous note). how does this introduce the > 'hierarchical resource' mechanics? or more precisely, how does this > affect michiharu's proposal? > > sorry, i but i am missing the connection. this is why i asked the > initial question; it seems to me that 'hierarchical resources' are by > definition something that needs to be treated iteratively. What if the policy also contains a Deny rule denying everyone except the patient access to the <Diagnosis> node alone? In that case, if the request comes in asking for the entire document, the Deny rule that applies to requests for that individual node would not apply, and access to the entire document (including the <Diagnosis> node) would be granted to the physician or an administrator. You can say, "Well, the rule allowing access to the entire document and the rule denying access to just the <Diagnosis> node are inconsistent, and that is the policy writer's problem." Maybe that is what we choose, but it is one of at least 4 choices we could make. The issue is that, since an XML resource could be identified either as an entire document or as a set of nodes, then either a) All policies against every XML resource must be written to apply to both cases, Drawback: two synchronized sets of predicates have to be written for every XML resource. Inappropriate access may be granted if the two sets of predicates are not consistent. b) The Policy Authority and the PEPs would all have to agree to access each particular XML resource only in one way, or Drawback: requires out-of-band agreement for each XML resource. c) Profile mandates that XML resources can only be requested as entire documents unless there is an out-of-band agreement for a given XML resource, Drawback: requires out-of-band agreement for each XML resource for which access to individual nodes is to be allowed (and two synchronized sets of predicates as in a) if both ways of accessing are allowed for that resource). d) Profile mandates that XML resources can only be requested as individual nodes unless there is an out-of-band agreement for a given XML resource. Drawback: requires out-of-band agreement for each XML resource for which access to the entire document is to be allowed (and two synchronized sets of predicates as in a) if both ways of accessing are allowed for that resource). The current Hierarchical Resources Profile specifies d). Seth made the point that there are legitimate cases for wanting to allow access to the entire document, so maybe we don't want to mandate d). But we have to make a choice, and each has some drawbacks. So which do we want: a), b), c), or d)? Anne > thanks > > b > > > Anne Anderson wrote: > > > Request: > > <Subject>subject-id="Anne Anderson"</Subject> > > <Resource>resource-id="http://www.medco.com/patient-records/Record0001.xml" > > <ResourceContent> > > <md:Record> > > <md:PatientName>Anne Anderson</md:PatientName> > > <md:Physician>Dr. Doofus</md:Physician> > > <md:Diagnosis>sick</md:Diagnosis> > > </md:Record> > > </ResourceContent> > > </Resource> > > <Action>action-id="read"</Action> > > > > <Policy PolicyId="Anne's example" CombiningAlgorithm="whatever"> > > <Target> > > <Resource MatchId="anyURI-match"> > > <AttributeValue > > DataType="anyURI">http://www.medco.com/patient-records/Record0001.xml</AttributeValue> > > <ResourceAttributeDesignator > > AttributeId="resource-id" > > DataType="anyURI"/> > > </Resource> > > </Target> > > <Rule Effect="Permit"> > > <Condition FunctionId="or"> > > <Apply FunctionId="string-match"> > > <AttributeSelector > > RequestContextPath="//Resource/ResourceContent/md:Record/md:PatientName/text()" > > DataType="string"/> > > <SubjectAttributeDesignator > > AttributeId="subject-id" > > DataType="string"/> > > </Apply> > > <Apply FunctionId="string-match"> > > <AttributeSelector > > RequestContextPath="//Resource/ResourceContent/md:Record/md:Physician/text()" > > DataType="string"/> > > <SubjectAttributeDesignator > > AttributeId="subject-id" > > DataType="string"/> > > </Apply> > > <Apply FunctionId="string-match"> > > <AttributeValue > > DataType="string">urn:medco:role:Administrator</AttributeValue> > > <SubjectAttributeDesignator > > AttributeId="role" > > DataType="anyURI"/> > > </Apply> > > </Condition> > > </Rule> > > </Policy> > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. > -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]