Hi Erik,
The assumption I am making is that the PEP and PDP share a
vocabulary, which presumably can contain a long list of attribute
identifiers.
For any given request, there is no way in advance for the PEP to
know exactly what subset of this vocabulary is required to meet
the needs of this particular request. It is only after the applicable
policies are selected by the PDP based on the initial resource
identification etc that the relevant attributes are identified that
would be required.
For example, in the Rule 1 of Example two, it is only after it is
known by the PDP that Rule 1 is an applicable policy that the
resource element patientDoB is required to evaluate the
request. It would be at this point that this attr would be
identified as missing to the PEP, that the PEP would know
it had to obtain this attr in order to satisfy the request.
In general, there may be all kinds of Subject and Resource
attrs that are required for a particular request. It would,
in general, be prohibitive for a PEP to gather all possible
attrs from all possible sources to supply with every request.
It is my assumption that this list of required attrs is only
known by the PDP determining the applicable policy and
then based on the attrs identified in the various rules, contained
in this dynamically determined applicable policy, if the
Subject is not granted access based on the info supplied,
there may be rules that within that policy that could not
be evaluated because some attrs were missing. The PDP
may at this point return Indeterminate and supply the
list of attrs needed to eval the request.
In a recent email, Hal had a comment on this as well which may
provide further clarification:
http://lists.oasis-open.org/archives/xacml/200702/msg00059.html
"Generally the tradeoff between insuring the necessary data
is present
and avoiding extra costs was judged by the TC to be highly specific to
the environment in which the PEP, context handler and PDP exist. For
this reason the required mechanisms and pattern of interaction have
been
left largely unspecified to date.
There are two features of XACML which are intended to allow
implementations to address this issue to some extent. First, XACML
specifies that the order of evaluation of rules and policies is
unspecified and the evaluation may terminate at any point once the
result can be determined. This allows optimization of processing, but
more importantly it allows the PDP to attempt to determine if access is
allowed using the information that is already on hand.
The second feature is the <MissingAttributeDetail> element in the
Response context. (see section 6.16 of the XACML 2.0 spec) This allows
the PDP to indicate that it could not make a decision because of one or
more missing attribute. I don't know if any implementations actually
make use of this feature.
"
Typical real world use cases can involve accessing external elements
such as
credit scores from attribute providers, or possibly resource attributes
such as
social security number associated with the requested record, etc.
Information
such as this should not be gathered unless it is determined that it is
required
to meet the needs of specific requests which only can be determined when
the applicable policy has been constructed by the PDP.
Let me know if this helps or more clarification required.
Thanks,
Rich
Erik Rissanen wrote:
Rich,
Could you clarify a couple of things about this issue? What do you see
at the intended use of the missing attribute details?
I have always thought that for interoperability, the users of XACML need
to profile XACML. They need to specify the attribute vocabulary which a
PEP must provide in the request and policy writers may refer to.
Do you intend to use the missing attribute details as a substitute for
profiling? That is, policy writers would refer to attributes, and PEP
would dynamically try to find those attributes based on the missing
attribute responses? How would the PEP find missing attributes it has
not been programmed to know about? And if it knows about the attributes,
why did it not provide the attributes in the first place?
Or is it something else you intend? (For instance submitting only a
minimum set of attributes?)
Best regards,
Erik
Rich Levinson wrote:
I have added the following issue to the issues list:
http://wiki.oasis-open.org/xacml/IssuesList
The point of the issue (below) is not to identify trivialities with
the example, but
to use the example as a basis for some general comments more toward
end of the issue description. It seemed to me that using the example
as context would be an effective way to raise the somewhat complex
issues/concerns that are the main point here. (I will be happy to
re-edit the issue if that makes sense after people have had a
chance to look at it).
Thanks,
Rich
66. Missing attributes may be underspecified
I did a somewhat detailed analysis of "Example two" in the core spec
from the point of view of understanding how fine grained authorization
(fga) (applying resource attrs to az decision) was implemented and
came across a number of items that I think need to be addressed
especially in potential interoperability situations. I will put all in
one issue initially, we can decide if it needs to be broken out later.
1. line 1090-91 describing ResourceContent </xacml/ResourceContent>.
In both the core spec and the sample messages, the ResourceContent
</xacml/ResourceContent> contains the following:
* <ResourceContent </xacml/ResourceContent>>
o <md:record xmlns:md="urn:med:example:schemas:record"
+ xsi:schemaLocation="urn:med:example:schemas:record
http:www.med.example.com/schemas/record.xsd">
<http:www.med.example.com/schemas/record.xsd%22%3E>
+ <md:patient>
# <md:patientDoB>1992-03-21</md:patientDoB>
<md:patient-number>555555</md:patient-number>
</md:patient>
</md:record>
</ResourceContent </xacml/IssuesList/ResourceContent>>
<Attribute AttributeId
</xacml/AttributeId>="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType </xacml/DataType>="xs:string">
o <AttributeValue </xacml/AttributeValue>>
+ //med.example.com/records/bart-simpson.xml#
xmlns(md=
http:www.med.example.com/schemas/record.xsd)
xpointer(/md:record/md:patient/md:patientDoB)
</AttributeValue </xacml/IssuesList/AttributeValue>>
</Attribute>
While I recognize that the example itself is not intended to be
perfect, it provides a convenient context for raising the following
questions/issues, especially wrt fga.
1.
If this is a first request from a PEP, why is the PEP supplying
patient-number on line 1056? This looks like a required attr to
evaluate Rule 1 (line 1141), if the requestor is the patient,
but this example the requestor is the physician.
*
The physician-id is supplied in the request (line 1044),
but the only rule it appears in is rule 3 (line 1522).
This rule only allows "write" access (line 1507), so I
expect this request would probably fail as it is currently
set up. i.e. we would need to add a "read" action to rule
3 or add a physician-id test to rule 1.
*
b. Assuming the above request fails, let's consider what might
be done. There was a "read" request issued (line 1072), so that
would mean that rule 1 (line 1182), rule 2 (line 1347), or rule
4 (line 1668) could be applied.
Rule 1 requires a Subject attribute patient-number (line 1134) to
match the patient-number in the requested resource record (line 1141).
Presumably a <MissingAttributeDetail </xacml/MissingAttributeDetail>>
could be returned, somehow identifying these 2 attributes to the PEP.
Rule 2 requires a patientDoB resource attr (line 1297), a
parent-guardian-id subject attr (line 1363), and a parentGuardianId
resource attr (line 1371). Similarly a <MissingAttributeDetail
</xacml/MissingAttributeDetail>> could be returned requesting these.
*
Assuming this to be the case, one question I have is how does
the <MissingAttributesDetail </xacml/MissingAttributesDetail>>
tell the PEP whether the attributes that are missing should be
resubmitted as part of the Subject or as part of the Resource?
This info is provided in the Request from the xml structure,
however, the <MissingAttributeDetail
</xacml/MissingAttributeDetail>> does not have equivalent
structure to make such distinctions.
The above is intended just to give an example of questions that occur
for this particular example, but it is my opinion that it is
symptomatic of a general problem of how PEPs are supposed to know how
to construct the proper RequestContext </xacml/RequestContext>
necessary, in general, for complex scenarios that require substantive
fga attrs.
In these more complex fga scenarios it is likely that
<MissingAttributeDetail </xacml/MissingAttributeDetail>> will be
typically needed to collect all the required attributes. Therefore, I
believe some more robust mechanisms, possibly using
MissingAttributeDetail </xacml/MissingAttributeDetail> as a good
starting point will be needed to adequately define operation in this
area.
In this context as well, it is likely that xpaths are probably not the
way to go since they are only applicable to certain types of resources
(xml-based) and those resource structures are likely to change in
time, and these changes should not percolate into the enterprise
Policy arena. Therefore, mechanisms such as vocabularies should be
recommended usage here with the PEP being responsible for mapping the
vocabulary item to the particular resource physical access path such
as the xpath.
CHAMPION: Rich
Status: *OPEN*
|