OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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:

  <Advice AdviceId="urn:...." AppliesTo="Permit">

>> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]