[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] MAD conceptual model
Attached version has a few corrections and clarifications. --Paul > -----Original Message----- > From: Tyson, Paul H > Sent: Friday, October 16, 2009 09:59 > To: xacml@lists.oasis-open.org > Subject: [xacml] 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 Mutliple profile.
Paul Tyson, 2009-10-16
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, perform the following steps
3-7.
3. 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 descendant 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.)
5. Group the resulting <Attributes> elements by @Category.
6. 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.
7. 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]