Re: [xacml] Comments on xacml-profile-hierarchical-resources draft

[Anne Anderson <Anne.Anderson@Sun.COM>]

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