Re: [xacml] Re: Call for Obligations

[Anil Saldhana <Anil.Saldhana@redhat.com>]

Thanks a lot for the clarification, Anne. :)

I do not see a mention of a relationship between a PAP and a PEP 
anywhere in the current artifacts of the group.  I only see a 
relationship between PAP and PDP.  My understanding has been that PEP 
has a relationship to a context handler and/or PDP.  Only the PDP has a 
direct relationship to a PAP. Could you clarify this bit for me, please? 

I am thinking of scenarios where a PDP is external to where the PEP is 
hosted. In this case, you cannot assume that the PAP will coexist with 
the PEP.

The logging was just an example of where a PEP may be unable to perform 
an obligation. If it has no direct effect on the final authorization 
decision, I am fine and I will rest my case. :)

Anne Anderson wrote:
> The semantics of a particular Obligation are completely between the 
> Policy Administration Point and the PEP.  The PAP could define a 
> particular Obligation "TryToLog" as meaning: "Make a best effort to 
> log, but it is not an error if unable to do so".
>
> Anne
>
> Anil Saldhana wrote:
>
>> I understand that obligation means obligation. :)
>>
>> Anil Saldhana wrote:
>>
>>> My use cases in mind are the following(please correct me wherever my 
>>> understanding is wrong):
>>> a) Legitimate authorization request arrives at the PEP. PEP invokes 
>>> the PDP. PDP comes back with 'PERMIT' and a set of obligations. PEP 
>>> is unable to fulfill 1 or more obligations. PEP issues an error. 
>>> What happened to the legitimate request?
>>> b) PDP issues a 'PERMIT' with a logging obligation. PEP does not 
>>> want to log because performance considerations have been put forward 
>>> and logging is low priority for the PEP. PEP issues an error.
>>>
>>> These are the use cases that I feel that obligations can have an 
>>> optional tag such that PEP can be spec compliant in ignoring them.
>>>
>>> sampo@symlabs.com wrote:
>>>
>>>> Anil Saldhana writes:
>>>>
>>>>> 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:
>>>>
>>>>
>>>> How is an Obligation an obligation if it is optional?
>>>> Perhaps better wording would be qualified or alternate obligations,
>>>> e.g. either you MUST log or you MUST validate a digital
>>>> signature (which MUST be present and valid).
>>>> Cheers,
>>>> --Sampo
>>>>
>>>>> 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).
>>>>
>>>> __________________________________________________________________
>>>> Sym  | Sampo Kellomaki  ______| Identity Architect, Federated SSO
>>>> ____ | +351-918.731.007 ______| Liberty ID-WSF DirectoryScript
>>>> labs | skype: sampo.kellomaki | LDAP SOAP PlainDoc Crypto C Perl
>>>
>>>
>>
>

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