Re: [xacml-dev] Re: XACML Profle for Rights Delegation

["Muhammad Masoom Alam" <Muhammad.alam@uibk.ac.at>]

Dear Erik,

  Currently, in which stage is the standardization of the XACML working 
Draft for Rights Delegation. I mean, is it stable at the moment?. If not, 
how much time and how many changes still be needed to complete it as a 
profile.

Regards,
MA
----- Original Message ----- 
From: "Erik Rissanen" <mirty@sics.se>
To: "Muhammad Masoom Alam" <Muhammad.alam@uibk.ac.at>; 
<xacml-dev@lists.oasis-open.org>
Sent: Friday, September 30, 2005 2:03 PM
Subject: [xacml-dev] Re: XACML Profle for Rights Delegation


> Muhammad Masoom Alam wrote:
>
>> Hi Erik,
>>
>>   I have some confusion regarding the selection of policies by the PDP.
>>
>> First of all, let me define my understanding of policies.
>>   Trusted Access Policies (Policies that does not contain
>> <PolicyIssuer> and <Delegate> Element )
>>    Non-Trusted Access Policies ((Policies that does contain
>> <PolicyIssuer> element but does not contain <Delegate> Element )
>>    Trusted Administration Policies (Policies that does not contain
>> <PolicyIssuer> but does contain <Delegate> Element )
>>    Non-Trusted Administration Policies (Policies that does  contain
>> <PolicyIssuer> and <Delegate> Element )
>>
>>
>> Now, my question is that how PDP will choose a particular  policy.
>> My finding according to the following rule are:
>>
>> Rule 1: "Only owner can delete a resource"  .
>>  Now this rule is expressed through a Trusted Access Policy.
>> There is also a rule:
>> Rule2: "Owner can delegate their access rights to other members
>> provided both are working in the same reseach group"
>>   Now this rule is expressed through Trusted Administration Policy.
>>
>>   Suppose there is an access request by a member to delete a resource
>> who is not the owner of the corresponding resource.
>>
>> First of all , PDP will see in the Trusted Access  Policies which
>> clearly states that in order to delete a resource, the member should
>> be owner (c.f. Rule 1). so it means a Deny Response (what is your
>> opinion ?)
>> Now, PDP will again look for Non-trusted Access Policy i.e. whether
>> some member (resource owner) issued such a policy that some other
>> member (which is not an owner) can delete a resource. suppose there is
>> a Non-Trusted Access policy stating that a member can delete
>> a resource even if he is not the resource owner. Now this has to be
>> confirmed by some Administration Policy. The PDP will look into the
>> Trusted Administration Policy repository first and find a policy (c.f.
>> Rule 2) that owner can delegate access rights to delete a resource.
>> Now there is no need to check Non-trusted Administration Policy.
>>
>>  The point is that there can be two policies stating the same
>> condition but one is trusted and other is non-trusted. My question (or
>> opinion) is that PDP will always check for
>> trusted (Access/Administration) Policy. After that, he will go for Non
>> (Access/Administration) Policy. i.e. if there is a trusted policy,
>> there is no need to make a chain of policy checking.
>
>
> Yes, you are right if you have a permit overrides combining algorithm.
> In that case the combining algorithm does not need to check the
> nontrusted policies. However, the general processing model also supports
> other combining algorithms, so the general processing model descriptions
> says that all policies are checked. It is perfectly fine to optimize
> this away in the case where the end result will be the same anyway.
>
> Erik
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing the 
> XACML OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/xacml-dev/
> Committee homepage: http://www.oasis-open.org/committees/xacml/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>