OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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


Subject: Re: [xacml-dev] Some queries regarding RBAC and XACML Profile fordelegation.


Muhammad Masoom Alam wrote:

>
>>
>> No, it's the other way around:
>>
>> -- First you match the access request against the access policies.
>> -- If there is a permit (which is associated with an issuer), then you
>> MUST generate a _new_ administrative request, and check that against the
>> administrative policies.
>> -- If the result is deny or not applicable for the first access request,
>> then you do not need to generate a second request. (We are still working
>> on the details of deny though, so draft 07 is not fully consistent on
>> this issue.)
>>
>
> oh , now i got you, you mean, Access policies are issued by the Users
> means the Access policies contains Issuer element.
>
> but i am thinking on the other way arround.
>
> Suppose i have normal XACML policies with no Issuer element and
> delegate element i.e. they are normal access policies and dont need
> any further authorization.
> if , an access request got "notApplicable", or "Deny", i will then
> check for the delegation policies (User Issued one) and so as to
> generate an Administrative request and ...
>
>
> Agreed  ?


No, we do not agree. :-)

An access policy is a policy that authorizes access requests. An
adminstrative policy is a policy that matches administrative requests.
When I say "delegation policy", I mean the same thing as "administrative
policy".

An access policy _never_ has a Delegate element by definition. An
administrative policy _always_ has a delegate element by definition.
That is the difference between them.

Whether a policy has an issuer or not has nothing to do with wether it
is an access policy or an administrative policy. Both administrative and
access policies can have an issuer element or not.

The issuer element decides whether the policy is trusted or not. If
there is no issuer element, the policy is trusted. If there is an issuer
element, the policy is not trusted.

If you have an access policy with no issuer element, and it evaluates to
permit, then you can stop and just return to the PEP.

If you have an access policy _with_ an issuer element, and it evaluates
to permit, then you have to generate an administrative request and check
it against the administrative policies.

/Erik




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