Re: [xacml-dev] Some queries regarding RBAC and XACML Profile for delegation.

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

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.