Hi Erik,
I don't think your comments are addressing the specifics that were
raised in the issue, which I am copying below for quick reference.
To summarize the issue:
Part 1. is basically saying that we need some context about the example
in order to look at the details in a consistent manner. Basically,
my reading
of the example is that when rule 1 is evaluated, the Target
determines that
the Rule is applicable, and presumably the Rule is evaluated and it
should
produce an Indeterminate result because there is no Subject
"patient-number"
as required on line 1134 when the Condition is evaluated.
Based on this Rule I expect that the Indeterminate result causes us
to
look at the prescribed processing in section 7.15.3, which says that
a missing-attribute status code could/should be returned.
To me, this provides an excellent example of how a PEP is informed
of what attribute needs to be supplied.
Before I go further into the details, I'd like to get your response to
that.
Also, I'd like to note that while I realize that this issue has been
floating
there for a long time, one reason is that no one has really wanted to
discuss it in detail. Prior responses were more of the nature of there
will be some other mechanism for getting the attribute. In general, when
we are considering attributes that need to come from users or from
resource attributes, I believe there is a non-trivial issue about how
those attributes get brought into the picture. The first problem is
knowing that they are needed. The fact that they are needed is
driven by the existence of an applicable policy that needs it, which
clearly is a state that can come and go as an administrator adds or
removes a particular attribute from the policy.
So, the basic use case here is: an admin creates or changes a policy
and decides to add an attr as part of the policy eval. Given this
change, how does this attr become part of the request.
(Note: I'd actually prefer to focus on resource attrs rather than
subject attrs, but since this particular situation w Rule 1
appeared obvious to me as a typical example, it happened
that the missing attr was subject-based (there is also an
assoc resource attr, but the req mysteriously already had
supplied that one)
My reading of the spec is that 7.15.3 provides a general purpose
mechanism for accomplishing this by returning an identifier specifying
what attr is needed, based on which the PEP and appl can do
whatever they want to get the attr then resubmit the request with
the attribute included.
This seems to me to be pretty essential functionality. Let me know
if you think I am missing some important point here. I will be happy
to help "fix" the spec w the detail I think is needed, but before we
get to that point there needs to be some agreement that changes
are even appropriate.
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. In both the core
spec and the sample messages, the ResourceContent contains the
following:
<ResourceContent>
<md:record
xmlns:md="urn:med:example:schemas:record"
xsi:schemaLocation="urn:med:example:schemas:record
http:www.med.example.com/schemas/record.xsd">
<md:patient>
<md:patientDoB>1992-03-21</md:patientDoB>
<md:patient-number>555555</md:patient-number>
</md:patient>
</md:record>
</ResourceContent>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="xs:string">
<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>
</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.
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>
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>
could be returned requesting these.
Assuming this to be the case, one
question I have is how does the
<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>
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 necessary, in general,
for complex scenarios that require substantive fga attrs.
In these more complex fga scenarios it is likely
that <MissingAttributeDetail>
will be typically needed to collect all the required attributes.
Therefore, I believe some more robust mechanisms, possibly using 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.
Status: OPEN
CHAMPION: Rich
Erik Rissanen wrote:
All,
I propose that issue 66, "Missing attributes may be underspecified", to
be closed without action. The issue has been up there a long time with
no proposals for a solution. In addition to that, I believe it is
technically impossible to provide a solution. The reason someone gets a
not-applicable from the PEP is because "there is no policy which
applies". In general there is no way to describe in the form of
"missing attributes" what the PEP needs to provide for the policy to
apply. Policies can be much too complex for this. In particular, a
policy could be NotApplicable because an attribute is present, for
example. Or it might require that three particular integer attributes
form a pythagorean tripple. How do you express that as "missing
attributes"?!
And we demonstrated in the RSA interop that obligations can be used to
handle simple use cases where some attributes can be expected to be
missing. An obligation can be used to mark the part of the policy which
required an attribute, and the obligation can then be returned by the
PDP if the attribute is missing.
Best regards,
Erik
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
