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"

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

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

Anil Saldhana
Leader, JBoss Security & Identity Management
Red Hat Inc
URL: http://jboss.org/jbosssecurity
BLOG: http://anil-identity.blogspot.com

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