[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]