[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue#66: XACML-Core 2.0,3.0 Missing attributes may be underspecified
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 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. CHAMPION: Rich Status: OPEN |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]