[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 for delegation.
Hi Erik, > 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. 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". 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.? 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. This way , it will more manageble Agreed ? :-) Have a nice weekend. Muhammad.