Re: [xacml] Open issue 66

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

Yes, to respond to this specific "part 1" only, it is true that in this 
particular example it works very well. The policy is simple enough that 
there is a single attribute which can be returned by the PDP. If the PEP 
would provide the missing attribute, then the response would be a Permit.

(BTW, if you prefer to discuss resource attributes, that is good with 
me. I agree that they are perhaps more interesting since they might be 
more difficult to handle in practice.)

If I continue beyond "Part 1" into the discussion which you follow up with.

1. For the sake of argument, let's assume that the PDP can return one or 
more attributes as "missing".

2. Then let's assume that, as you say, the policy author puts an 
attribute in the policy, and the PEP has not provided the attribute to 
the PDP. Let's say that the attribute has id 
"http://www.tts-esss.com/pieka/UUUU/3";.

3. The PEP will get a response saying that attribute 
http://www.tts-esss.com/pieka/UUUU/3 is missing.

So your question is what should the PEP do? (If I understand you correctly)

It is quite clear to me that if the PEP does not know about this 
attribute in some form, either directly by itself, or it can look it up 
in some kind of discovery service, then there is nothing it can do. One 
cannot expect systems integration to happen by itself. One cannot expect 
that a policy author can fill in any attribute in a policy and then it 
would work all by itself.

So my question then is, what do you think should happen in this stage? 
Are you looking for a form of general purpose attribute discovery 
service? That might be an interesting thing to work on.

Maybe I don't understand the use case really. But as far as I see it 
right now, it's not going to work because:

1. In general it is not possible to tell which attribute is missing.

2. Even if it is possible to tell which attribute is missing, one cannot 
expect a PEP find the missing attribute by itself if it doesn't already 
know about it.

There just is no way around the fact that if an attribute appears in a 
policy, then either the PEP or the context handler has to be aware of 
the attribute in some form, or it won't work. The expected requests from 
the PEP and the context handler configuration form a contract which 
defines the vocabulary available to policy authors.

But maybe you are talking about lazy fetching of attributes? I do think 
that there is much value in lazy fetching of attributes. Let's say that 
the http://www.tts-esss.com/pieka/UUUU/3 attribute is available in some 
external source and the PEP or context handler is aware of it, but the 
attribute is not needed every time and it is expensive to retrieve. In 
this case it may be desirable to set up the system so that the attribute 
is retrieved only when it is needed by the policies.

This use case is supported by the context handler abstraction. The 
context handler is something which can be used by the PDP to retrieve 
attributes when they are needed on a particular evaluation path, so that 
early fetching is avoided. But "missing attributes" to the PEP is not 
going to work.

Anyway, I have a feeling that I don't understand what you are looking 
for, so I welcome more discussion. :-)

Best regards,
Erik

Rich.Levinson wrote:
> 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 </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.
>
> 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