[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] The new advice "obligation"
Anil Saldhana wrote: > Erik Rissanen wrote: >> All, >> >> During the call yesterday we decided to introduce a new "type of >> obligation", perhaps called <Advice>. >> >> I have two things to say. >> >> 1. Here is a syntax which we could consider: >> >> <Advice AdviceId="urn:...." AppliesTo="Permit"> >> <AttributeAssignment>.....</> >> </Advice> >> >> Any other ideas for naming it? >> > Erik, provide some context to the naming, please. :) Like this: <Policy> .... <Advice AdviceId="urn:...." AppliesTo="Permit"> <AttributeAssignment>.....</> </Advice> </Policy> >> 2. Should it be possible to have this apply to NotApplicable as well, >> not just Permit/Deny? >> >> I am asking since a customer of mine wanted to use obligations on >> NotApplicable to return a reason for why access was not allowed. >> >> I haven't thought it through properly yet, but it seems like a good >> idea. Typically I would expect policies to list stuff that is >> allowed, with perhaps some exceptions which deny. In general it's a >> good principle for security design to "enumerate goodness", rather >> than to try to list everything which is bad/dangerous. If one does >> so, if a policy does not match, it would be NotApplicable, not Deny, >> so it would not be possible to return advice about what did not >> match. If we don't allow advice on NotApplicable, then policy writers >> need to refactor their policies to return Deny instead of >> NotApplicable when they do not match. >> >> Refactoring like that gives a fundamentally different "architecture" >> for the policies. Now we will have policies which say "Deny" on >> things they do not apply to, and policies which apply say "Permit". >> This forces the user to use a permit-overrides algorithm, which >> further limits how policies can be structured. Essentially the policy >> writer is forced to work with Permit/Deny only, and NotApplicable is >> not something he can use in his policies. > Essentially, you are sending a debug info back via the obligation? > You missed these attributes in your request for your receipt of NA. Well, I wouldn't call it debug info. It would be insufficient for any real debugging. It's more about giving particular advice to the end user in a specific, limited context. See the XACML interop policies for one example where itis done with a FulfillOn="Deny" obligation in refactored policies. Regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]