[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. /Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]