[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Open issue 66
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 underspecifiedI 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:
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.
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.
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: 48C76772.3060402@axiomatics.com" type="cite">All, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]