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:

> I think we are talking the same thing. For additional managibility, it
> will be much more flexible if we do like this:
>  1. We keep Access policies and Delegation Policies seperate.
>      a. By Access Policies i mean, those policies which does not
> require any further authorization i.e. simply contains no Issuer
> element and can also contain a constraint as well in that case, an access
>            policy can also result  "Deny".

Your use of the word "access policy" is not how anyone else uses it, so
it is very confusing. I suggest that you use the terminology that is in
the profile.

>      b. Where as, Delegation policies can be further divided into
> catogries those directly trusted by the PDP i.e. Administrative one
> and those need further authorizaiton i.e. User Defined.
>           Administrative one can contains constraints.At the moment i
> am considering that the policies issued by the users will not contain
> any constraints. if we allow users to put constraints, it will not be
> of substance since, it is again an athorizaton question i.e. who can
> put constraints and who is not. Also whether it shall be confirmed
> first that the corresponding user is allowed to issue a policy or
> first to evaluate the constraint specified by him.?

There is no problem letting an issuer of a policy add constraints in his
policy. A user that has been authorized to issue a policy, can issue any
subset of the situation in the administrative policy granting him
authority. This is by design. I know of no use case where the issuer
should be prohibited from issuing a strict subset of his authority.

>  2. Now when Access request comes, it will first match the simple
> Access policies (c.f 1a). where as if the result is deny or
> notapplicable , then delegation policies will be checked.

In a general processing model, you would not want to restrict it to only
this, but you can achieve the above by using a permit overrides
combining algorithm and keeping your policy set in the right order.

> This way , it will more manageble Agreed  ? :-)

No, I am sorry, but I don't agree.


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