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"

bill parducci wrote:
> On Dec 18, 2008, at 11:56 PM, Erik Rissanen wrote:
>> 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.
> Does this mean that all Policies not applicable to a decision would 
> return an Obligation? Taken one step further with the TC's current 
> decision re: Obligations, that all Rules that are not applicable will 
> return Obligations?

What I mean is that if a PolicySet/Policy/Rule contains an <Advice 
AppliesTo="NotApplicable">, then it would be returned to the PEP if that 
policy was processed by the PDP and the final decision is NotApplicable 
(and to be more precise, that particular NotApplicable was "pushed up" 
all the way through combination).

> Also, NotApplicable and "not allowed" are not explicitly correlated, 
> since the latter is defined as a "Deny", so I am not sure I understand 
> the use case fully. Are they looking for the logic behind each 
> decision to be passed to the PEP? (Which could be unwieldy if the 
> answer to my first question is yes :)

They want to put markers in parts of the policies, which they want to 
show to the users if the final decision is NotApplicable. The markers 
would give advice to the user about what was wrong with the access 
request and the reason to why no policy applied to the request.


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