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] Re: Call for Obligations


Anil,

Anil Saldhana wrote:

> 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 relationship is in the semantics of policies and their variables 
(Attributes, values, Obligations), not in a physical interface or 
location dependency between a PEP and a PEP.

A PDP knows only about Attribute identifiers, generic DataTypes, and 
generic values - it knows nothing about the meanings of those Attributes 
and values.  A standard XAMCL PDP could handle policies from many 
sources, possibly based on different authorization models, and could use 
those policies to evaluate decision requests from PEPs associated with 
multiple types of resources.

When a PEP makes use of [i.e. is configured to use] a given PDP, the PEP 
is assuming that the PDP is supplied with policies by a PAP responsible 
for issuing policies related to the resource with which the PEP is 
associated.  Both the developer of a resource's PEP, and the developer 
of the PAP that will provision that PEP's PDP must know the 
authorization model for protection of the PEP's resources, the meanings 
of the Attributes and values that the PEP is expected to supply, and the 
meaning and values of Obligations that the policies used by the PDP may 
return.

Regards,
Anne

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

-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA


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