[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Request Context and presence of Attributes
The handling of "dynamic" attributes is not specified clearly in
the specification. Questions:
1) If a <SubjectAttributeDesignator> refers to a particular
AttributeId, must that AttributeId be present as a <Subject>
<Attribute> in a physical <Request> document?
2) If a <SubjectAttributeDesignator> refers to a particular
AttributeId, when must that <Attribute> value be made
available, and by what entity? If the PEP did not supply a
value for the <Attribute>, is the reference passed to the PIP
at that time the <SubjectAttributeDesignator> is parsed by the
PDP? Is it passed to the PIP at the time the value of the
<SubjectAttributeDesignator> is evaluated by the FunctionId of
which it is a part?
3) Is there some level of evaluation, say a specific <Target> or
<Condition> element, that must be parsed and all referenced
<Attribute>s obtained and stored in the Request context before
the PDP evaluates the <Target> or <Condition>?
I have included the text of Issues that relate to these
questions below.
It was my understanding from the resolutions to the Issues that
the <Request> context was a "notional" document, and that the
<Attribute>s need not exist in a physical XML document at any
time. Referencing <Attribute>s as if they were in such a
physical XML document is an abstraction to separate the PDP from
the PIP and from the various protocols required to locate,
retrieve, and parse various AttributeIds.
But the current text (0.18a) does not match my understanding.
a) Section 3.1, "Data-flow model", Figure 1, "Data-flow diagram",
p. 16, line 514, does not clarify when the data flow between
the context handler and the PIP takes place. Can it take
place at the time the PDP references the Request context?
b) Section 3.1, Data-flow model, Steps 4-8 imply that the
context-handler somehow knows what Attributes will be required
by the applicable policies, and retrieves them all from the
PIP before presenting a complete Request Context document to
the PDP for evaluation.
c) Section 3.2, XACML context, Figure 2 - "XACML context", shows
the xacml Context/Request.xml strictly as an input to the PDP,
implying that it is a static document (or at least a static
representation).
d) Section 7.1, "Missing attributes", 4th paragraph, Lines
2814-2828, paragraph starts with 'If an "Indeterminate"
decision value is returned, ...": this implies that the
process of obtaining "missing attributes" is resolved by an
interchange between the PDP and the PEP, but does not mention
any such resolution by an explicit or implicit interchange
between the PDP and the Context Handler, or between the PDP
and the PIP.
Seth Proctor, who is implementing XACML, does not understand the
"notion" of a "notional" document, or how it would be
implemented. Eve Maler, however, indicated that XPath DOM,
etc. implementations already have to deal with "notional"
documents.
Resolutions of Issues that pertain to this:
Issue 36:
36. [Anne] attribute references and indeterminate results
Long, verbose, religious, tedious thread starts with:
http://lists.oasis-open.org/archives/xacml/200207/msg00071.html
Subsidiary thread (pdp status element):
http://lists.oasis-open.org/archives/xacml/200207/msg00140.html
Some sub-issues and options
Order of evaluation
a. In what order MUST arguments be evaluated
Implementation-dependent unless the function definition
specifies an order. orderedOr and orderedAne are the only
standard functions we have defined that specifies an order.
b. MUST all arguments be evaluated?
No, if a result can be returned without evaluating all. You
could define a custom function that requires evaluating all
arguments, but none of our standard functions does this.
c. MAY all arguments be evaluated, even if not required to reach a
function result?
Yes, but can never change the overall result.
Operational errors (e.g. divide by 0) and missing information
(AttributeDesignator freturns empty set)
a. Reporting of errors via the response obtained while evaluating
a request by PDP:
Reporting by PDP in the Response is optional. PDP MAY include
error information in the Status element of the Response. PEP
must not depend on the PDP supplying this information.
b. Operational errors and missing information are handled as follows
- Standard OR and ORDERED-OR implementation:
Evaluate arguments in any order (or in specified order)
IF (you receive an error or null AttributeDesignator result) {
Go on to next argument evaluation unless all evaluated
IF (you get at least one TRUE) {
return TRUE
} ELSE {
return error (which may be a set of errors)
}
} ELSE IF (you get at least one TRUE) {
return TRUE
} ELSE {
return FALSE
}
- Standard AND and ORDERED-AND implementation:
Evaluate arguments in any order (or in specified order)
IF (you receive an error) {
Go on to next argument evaluation unless all evaluated
IF (you get at least one FALSE) {
return FALSE
} ELSE {
return error (which may be a set of errors)
}
} ELSE IF (you get at least one FALSE) {
return FALSE
} ELSE {
return TRUE
}
- function:present: returns TRUE if argument is
not empty set. Returns FALSE if argument is empty set. If
evaluating argument results in an error, return error.
- function:not returns TRUE if argument is FALSE,
returns FALSE if argument is TRUE. If argument results in an
error, return error.
- Other standard functions: return "error" if any argument is an
error or if an operational error in computing the function
occurs.
- Custom functions must behave like "Other standard functions"
unless specific handling of errors is specified.
c. What is Rule result if Condition evaluates to (exactly same as
table in v15 of specification):
- operational Error?
INDETERMINATE(error=operational error)
- "necessary information not available"?
INDETERMINATE (error=missing information)
- FALSE?
NOT APPLICABLE
- TRUE?
PERMIT or DENY (as specified in rule's Effect)
d. What is Rule result if Target evaluates to FALSE?
NOT APPLICABLE
e. Combining Algorithms must specify how PERMIT, DENY,
INDETERMINATE, and NOT APPLICABLE are handled. Standard
algorithms already do this.
f. If operational errors are reported, how is the type of
error reported?
Reported via Status element in Response
CLOSED: See decisions above.
41. [Anne] Is a "notional" XML document for Request a good idea?
http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [2.]
[Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html
CLOSED: notional XML document is not a problem. In XML,
everything is a virtual document anyway. Note: how to
specify "dynamic" attributes that are not supplied in the
request from the PEP is a separate issue and is still not
completely resolved.
61. [All] Dynamic attributes: how are they referenced and retrieved?
Define a schema for the "static context"? This would be used for
conveying cached attributes in the form of a Request Context
between cooperating PDPs.
CLOSED: Perhaps define such a schema for a later version of XACML.
Dynamic attributes are referenced and retrieved through the
"notional" XACML Request Context regardless of whether they are
supplied by the PEP or retrieved from a PIP.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC