[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Quality of Service (aka Parameterized Decisions) UseBlurb
Erik Rissanen wrote: > This is similar to a requirement we have been discussing in our work > with network based defense. I some cases we would like to differentiate > between regular permissions and "emergency" permission, so that the use > of the latter would be logged in a special manner and audited more > thoroughly than other accesses. The logging requirement can easily be > expressed in an obligation, but if there is both a regular permission > and an emergency permission for the same access, we would like the > regular permission to take over so that no special auditing will be done. i have been reading tim's generalization model and i think this could be solved, as can some of the other scenarios i presented. in this case something like this might work (*very* loose syntax ;o): <Conclusions> <TrueConclusion> <Access>Permit</Access> <Ordered-Or> <Constraint> access-control-xacml-3.0-access-constraintId-1 </Constraint> <Constraint> access-control-xacml-3.0-access-constraintId-2 </Constraint> </Ordered-Or> </TrueConclusion> </Conclusions> where the addition [my doing] of some sort of boolean logic mechanism to tim's 'truth' construct would allow one to create a policy that had any number of (ordered) alternatives should an initial Access/Constraint result not be enforceable by the PEP. in the sample above you have, "if the inputs yield True, enforce Permit with Constraint1; if that is not possible enforce Permit with Constraint2." make sense? personally i am pretty excited at the possibilities that tim's 'truth' construct introduces. heck, if i understand it correctly we can explicitly define the behaviors of the whole 'permit-preferred', 'deny-preferred' models and do away with the [cumbersome] definitions we have now. b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]