Re: [xacml] Quality of Service (aka Parameterized Decisions) UseBlurb

MHonArc v2.5.0b2 -->


















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [xacml] Quality of Service (aka Parameterized Decisions) UseBlurb




From: Bill Parducci <>
To: xacml <>
Date: Thu, 10 Feb 2005 07:06:42 -0800






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