OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Hierarhical resources.. part 0.1



Anne and I had a discussion earlier this afternoon about hierarchies, I
went off to a meeting for 2 hours, and I came back to a bunch of email
on the subject :) It sounds like we're mostly in agreement, so I'll try
to summerize the discussion both to make sure that I understand it, and
to help others catch up.

Note that this applies to the kind of hieararchies that we can handle
today, i.e. not XML documents included in the ResourceContent...this
discussion may handle that case too, but I haven't done as much thinking
on that subject.

  1. We like the current scope mechanism, where the PEP can specify a
     scope of Immediate/Children/Descendants, and the context handler
     turns that into one decision request for each resource in the
     hierarchy (returning a single Response that contains at most a
     Result for each decision request).

  2. The PDP should be asked for decisions on all nodes in the 
     hierarchy, not just leaf nodes (in other words, it's the same as
     what 1.x defines).

  3. We want a new resource-ancestors attribute (which can be used
     whether or not the Request specifies a hierarchy) that names the
     ancestors of the resource-id. In the case of a scoped hiearchy,
     each decision request (for each resource in the hierarchy) will
     contain the resource-ancestors attribute for the given resource-id.
     We may want other, similar attributes.

 3a. Naturally, the resource-ancestors attribute is notional.

  4. Since the PEP may know about the hierarchy structure, or may want
     to know only about a subest of a given hierarchy, we want a new
     way to specify multiple Resource sections in the Request, such that
     the context handler acts as in 1, splitting the Request apart and
     giving the PDP a decision request for each resource specified.

 4a. Each Resource section should be able to specify its own
     resource-ancestors attribute in addition to a resource-id. This
     means that there's no bag-of-bags problem.

I think this captures most of the conversation. This has the nice
property of being compatable with with 1.x, and is a fairly simple
mechanism. Do people think I got this (mostly) right?

Here's an example. Assume the hierarchy:

  A -- B1 -- C1
    \- B2 -- C2
          \- C3

When the context handler sees:

<Request>
  ...
  <Resource>
    <Attribute AttributeId="...resource-id" DataType="...anyURI">
      <AttributeValue>A</AttributeValue>
    </Attribute>
    <Attribute AttrbiuteId="...scope" DataType="...string">
      <AttributeValue>Descendants</AttributeValue>
    </Attribute>
  </Resrouce>
  ...
</Request>

it will (effectively) generate 6 different decision requests, each one
the same except that the resource-id attribute is, respectively, each of
the resources in the hiearchy. Also, because the attribute wasn't
supplied directly, the context handler must supply the
attribute-ancestors value for each request. The end product will be a
single Response which may have as many as 6 Results.

Alternately, the Request could have looked like:

<Request>
  ...
  <Resource>
    <Attribute AttributeId="...resource-id" DataType="...anyURI">
      <AttributeValue>A</AttributeValue>
    </Attribute>
  </Resource>
  <Resource>
    <Attribute AttributeId="...resource-id" DataType="...anyURI">
      <AttributeValue>A/B1</AttributeValue>
    </Attribute>
    <Attribute AttributeId="...resource-ancestors" DataType="...anyURI">
      <AttributeValue>A</AttributeValue>
    </Attribute>
  </Resource>
  ...
</Request>

(or something similar), and the context handler will turn this into two
decision requests for the PDP, each with only one Resource section.

I think this captures the discussion thus far (mod some details about
what the actual Request format should look like). Comments?


seth



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]