[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New core and multiple resource profile
(bill) >> In conjunction logically yes. In conjunction syntactically within a >> Policy, Nno. The PDP must dictate order, not the Policy(Set) or it >> will not work. > (hal) > Can you elaborate? Why would it not work? (I can think of reasons, I > just want to know yours.) Sure... or at least I can try (my experience with working Obligations is that the things get weird pretty quick :) To begin with there would need to be an unambiguous precedence of Obligations(Category|Families) for the PDP to be able to determine the order of exclusivity as well as the scope of such exclusivity deterministically. For example assume you have Obligations pertaining to encryption. Ob1 says encrypt:3DES, Ob2 says encrypt:blowfish. Both know that encryption must occur as well as that there should only be a single encryption mechanism so they each declare themselves as Exclusive, "Level 1" in priority. What's a PDP to do? Knowing that 3DES and blowfish have any relationship requires some sort of associative categorization/classification. Since I assume we are stepping off into the realm of PDP awareness re: Obligations it seems unrealistic that the Policy is the place for determining that 3DES takes precedence over blowfish and both of them fit into a Category. It seems highly likely that diverse Policies may not know of the existence (or name for that matter) of other, similar Obligation mechanisms. For this reason I think an Obligation need only declare its Name and Category in the Policy and that the PDP maintains the order of precedence, exclusivity, etc. above that. In the example above both Obligations would declare themselves as Category "Encryption" and the PDP would know that there are exclusion rules and the order of precedence for this Category and return the appropriate Obligation to the PEP. Again, this obviously assumes that the PDP will act upon this information. I guess that the case could be made that the PDP continues to blindly collect all of the Obligations--along with the newly added Exclusivity and Precedence information--and pass the whole mess back to the PEP but I believe that is an unworkable solution, one which begs the question of the need for adding this additional information in the Policy in the first place since you would have a Big White Box solution that extends out to the PEP (and you are just as well off using "drinkMagicPotion6" for the Obligation ;) BTW, the concept on a "knowledgeable PDP" is why I think that the PDP meta data should include information pertaining to what the PDP is aware of in terms of Obligations (or if it supports Obligations at all). It seems like it would be a good thing to know if you were PEP in a distributed environment :) b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]