OASIS eXtensible Access Control Markup Language (XACML) TC

As we explore ways to create a model for handling more complex Obligation
combinations it will be very helpful to gather Use Cases and/or
descriptions of Obligations that are (or are planned to be) used in the
field. This will help us create Obligation Categories and from that
hopefully develop a model that will be both flexible and deterministic in
combining the slippery little things.

Please post your contributions to the list or email me directly if you
aren't able to post to the list. All input is welcome.

thanks

b

Has there been any work on obligations since xacml v2.0?

Some use cases:
Some of the things that pop up in mind with reference to obligations are:
a) Auditing. (Common use case).
b) Deny further requests on a particular subject if the number of 
unsuccessful authorization requests > n times. (More of a DOS use case). 
- Blacklist a subject.

Priority among ObligationCategoryMembers:
http://wiki.oasis-open.org/xacml/DiscussionOnObligations
In the case of "encrypt" category, what if the PEP is unable to encrypt 
using "3DES" but can do "blowfish"?  I think there is scope for levels 
of priority here with reference to obligation categories for the various 
members.

Optional Obligations:
I am also wondering if there is scope to specify whether a particular 
obligation is required or optional.  The reason is if a particular PEP 
is not able to perform a particular obligation, then it is 
non-reasonable to deny a particular access. A policy writer should be 
able to specify obligations that are mandatory and some that are 
optional(eg: logging for performance purposes).

Sorry if I have been way off-topic.


Bill Parducci wrote:
> As we explore ways to create a model for handling more complex Obligation
> combinations it will be very helpful to gather Use Cases and/or
> descriptions of Obligations that are (or are planned to be) used in the
> field. This will help us create Obligation Categories and from that
> hopefully develop a model that will be both flexible and deterministic in
> combining the slippery little things.
>
> Please post your contributions to the list or email me directly if you
> aren't able to post to the list. All input is welcome.
>
> thanks
>
> b
>   

-- 
Anil Saldhana
JBoss Security & Identity Management
http://labs.jboss.com/portal/jbosssecurity/

> Has there been any work on obligations since xacml v2.0?
>

The majority of work done on Obligations has been summarized on the  
wiki.

> Some use cases:
> Some of the things that pop up in mind with reference to  
> obligations are:
> a) Auditing. (Common use case).
> b) Deny further requests on a particular subject if the number of  
> unsuccessful authorization requests > n times. (More of a DOS use  
> case). - Blacklist a subject.

Can you provide a bit more detail on these? A description of the  
possible Members for each of these and what each should do would be a  
nice start ;)
>
> Priority among ObligationCategoryMembers:
> http://wiki.oasis-open.org/xacml/DiscussionOnObligations
> In the case of "encrypt" category, what if the PEP is unable to  
> encrypt using "3DES" but can do "blowfish"?  I think there is scope  
> for levels of priority here with reference to obligation categories  
> for the various members.
>
In the normative sense, the PDP makes it decision in ignorance of the  
capabilities of the PEP; likewise the PEP is unaware of the  
Obligations the PDP may consider. So, should a PDP render an  
Obligation of "3DES" but the PEP doesn't support it an Error  
condition would result on the PEP. It is theoretically possible for a  
PDP to return and entire Category in sequential order for processing  
by the PEP, but we have not considered such a case (as it would  
require PDP-like actions on the PEP). An interesting idea though.  
Perhaps we should work through the ramifications to see what we come  
up with...

> Optional Obligations:
> I am also wondering if there is scope to specify whether a  
> particular obligation is required or optional.  The reason is if a  
> particular PEP is not able to perform a particular obligation, then  
> it is non-reasonable to deny a particular access. A policy writer  
> should be able to specify obligations that are mandatory and some  
> that are optional(eg: logging for performance purposes).
>
Hmmm... this seems like kind of a weird one: an Obligation that  
doesn't really obligate the PEP do anything. Guess I am going to have  
to pull out the "Show me the Use Case" card :o) since "logging for  
performance purposes" isn't clear to me. Can you elaborate?


> Sorry if I have been way off-topic.

This is good stuff. Lets explore it a bit and see where we end up. I  
think you have introduced some ideas that will make for interesting  
study! Please feel free to start capturing your ideas on the wiki.


b