[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MAD conceptual model
Attached find proposed description of conceptual model for producing single authorization decision requests from a multiple authorization decision (MAD) request. This would replace some content in sections 2.1, 2.2, 2.3. I came up with a few questions and concerns: 1. I still don't like the idea of mutable resource-ids. Either the original request should have something like "resource-selector", or the resulting context should have "decision-node-id" or something. But then the problem is, how does the PEP request the resource-id to be returned (using "IncludeInResult")? We might have to specify some built-in semantics to handle this. 2. This does not specify how the xpathExpression resource-id for individual resources will be constructed. The TC is still discussing whether to specify this, and if so, what the form should be. In any case, it seems necessary to say something about the namespace binding context that will be used for name prefixes. Default might be to use the namespace binding context represented by the union of the contexts in <Content> children, but this is not specified. One way to facilitate regexp matching on xpath strings would be to allow policies and/or requests to specify a namespace binding context. 3. scope=EntireHierarchy is out of place here. Consider moving Section 3 to hierarchical profile. The conceptual model and expected results are different than the other multiple authorization decision modes. The "multiple" processing only takes place internally--a single decision is expected (possibly multiplied by additional subjects or actions). Regards, --Paul
Proposed changes to line 59 WAS: 2 Requests for multiple resources PROPOSED: 2: Requests for multiple authorization decisions lines 61/63 WAS: A single XACML request context MAY represent a request for access to multiple resources, with a separate authorization decision desired for each resource. The syntax and semantics of such requests and responses are specified in this Section. PROPOSED: A single XACML request context MAY represent a request for multiple authorization decisions. The syntax and semantics of such requests and responses are specified in this Section. lines 64/74 WAS: The <Result> elements produced by evaluating a request for access to multiple resources SHALL be identical to those that would be produced from a series of requests, each requesting access to exactly one of the resources. Each such resource is called an Individual Resource. The conceptual request context that corresponds to each <Result> element is called an Individual Resource Request. This mapping of an original request context containing multiple authorization decision requests to Individual Resource Requests, and the corresponding mapping of multiple authorization decisions to multiple <Result> elements in a single response context MAY be performed by the Context Handler described in the non-normative Data-flow model of the core XACML specification [XACML]. This Profile does NOT REQUIRE that the implementation of the evaluation of a request for access to multiple resources conform to the preceding model or that actual Individual Resource Requests be constructed. The Profile REQUIRES only that the <Result> elements SHALL be the same as if the preceding model were used. PROPOSED: The <Result> elements produced by evaluating a request for multiple authorization decisions SHALL be identical to those that would be produced from a series of requests, each requesting a single authorization decision. The conceptual request context that is evaluated to produce each <Result> element is called a Single Authorization Decision Request. The transformation of an original request for multiple authorization decision requests to a series of Single Authorization Decision Requests is described here. 1. For each MultiRequest/RequestReference in the request, create a new request context. Each new request context shall contain a copy of the <Attributes> elements referred to by the <AttributesReference> elements in the <RequestReference>. If there are no <MultiRequest> elements, then use the original request context as input to the following steps. 2. For each resulting request context, replace <Attributes> elements that have @Category="resource" and a child <Attribute> with @AttributeId="scope" with one or more new <Attributes> elements created by the following method: NOTE: An xpath expression to select these elements is: /Request/Attributes[@Category = 'urn:oasis:names:tc:xacml:3.0:attribute-category:resource'] [Attribute[@AttributeId = 'urn:oasis:names:tc:xacml:2.0:resource:scope']] a. If the value of the "scope" attribute is "Immediate", create a deep copy of the <Attributes> element, but omit the "scope" <Attribute> element. b. If the value of the "scope" attribute is "Children", then one new <Attributes> element shall be created for the original resource-id and for each child of the node identified by the original resource-id. The new <Attributes> element corresponding to the original resource-id shall be a deep copy of the original <Attributes> element, except that the "scope" <Attribute> element shall be omitted. The new <Attributes> elements for the children of the original resource-id shall be deep copies of the original <Attributes> element, except that: 1) the "scope" <Attribute> element shall be omitted; 2) the "resource-id" <Attribute> element shall identify the child node; and 3) if the hierarchical resource is described using non-xml hierarchical attributes (see hierarchical profile), the hierarchical attributes shall be adjusted to identify the original resource-id as a parent of the child node. If the resource is represented as XML in the <Content> element of the <Attributes>, the set of individual resource nodes can be selected by applying the following xpath expression to the content XML: original-xpath-resource-id|original-xpath-resource-id/* where "original-xpath-resource-id" is the value of the "resource-id" <Attribute>. c. If the value of the "scope" attribute is "Descendants", then one new <Attributes> element shall be created for the original resource-id and for each descendant of the node identified by the original resource-id. The new <Attributes> element corresponding to the original resource-id shall be a deep copy of the original <Attributes> element, except that the "scope" <Attribute> element shall be omitted. The new <Attributes> elements for the descendants of the original resource-id shall be deep copies of the original <Attributes> element, except that: 1) the "scope" <Attribute> element shall be omitted; 2) the "resource-id" <Attribute> element shall identify the descendant node; and 3) if the hierarchical resource is described using non-xml hierarchical attributes (see hierarchical profile), the hierarchical attributes shall be adjusted to identify the original resource-id as a parent or ancestor of the child node, as appropriate. If the resource is represented as XML in the <Content> element of the <Attributes>, the set of individual resource nodes can be selected by applying the following xpath expression to the content XML: original-xpath-resource-id|original-xpath-resource-id//* where "original-xpath-resource-id" is the value of the "resource-id" <Attribute>. d. If the value of the "scope" attribute is "Xpath-expression", then one new <Attributes> element shall be created for each node selected from the <Content> XML by applying the xpath expression given in the original resource-id. The new <Attributes> elements shall be deep copies of the original <Attributes> element, except that the "scope" <Attribute> element shall be omitted and the "resource-id" <Attribute> element shall identify a single node in the <Content> XML. e. If the value of the "scope" attribute is "EntireHierarchy", then one new <Attributes> element shall be created for each node in the hierarchy described by this <Attributes> element. The new <Attributes> elements shall be deep copies of the original <Attributes> element, except that: 1) the "scope" <Attribute> element shall be omitted; 2) the "resource-id" <Attribute> element shall identify one single node in the hierarchy; and 3) if the hierarchical resource is described using non-xml hierarchical attributes (see hierarchical profile), the hierarchical attributes shall be adjusted to identify the current resource-id, its parents, and its ancestors. If the resource is represented as XML in the <Content> element of the <Attributes>, the set of individual resource nodes can be selected by applying the following xpath expression to the content XML: //* NOTE: Decision requests for "EntireHierarchy" will produce a single <Result> for each resource with scope of "EntireHierarchy". It is necessary to create individual resource <Attributes> elements to describe the process of reaching a decision (see section 3). But, unlike the other scope values that cause multiple results, "EntireHierarchy" causes only one result per hierarchical resource. (However, in combination with multiple actions or subjects, there could be multiple decisions for an entire hierarchy.) 4. Group the resulting <Attributes> elements by @Category. 5. Form the cartesian product of <Attributes> elements in each group, by recursively combining one <Attributes> element from each group with one <Attributes> element from each of the other groups. 6. For each set of <Attributes> elements produced by the preceding step, create a new request context containing just those elements. Each resulting request context will have no more than one <Attributes> element in each category. This Profile does NOT REQUIRE that the implementation of the evaluation of a request for multiple authorization decisions conform to the preceding model or that actual Single Authorization Decision Requests be constructed. The Profile REQUIRES only that the <Result> elements SHALL be the same as if the preceding model were used. lines 75/77 WAS: Three ways of specifying requests for access to multiple resources are described in the following Sections. Each way of specifying requests describes the Individual Resource Requests that correspond to the <Result> elements in the response context. PROPOSED: Three ways of specifying requests for multiple authorization decisions are described in the following Sections.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]