Re: [xacml-comment] Public Comment

[Anne Anderson <Anne.Anderson@Sun.COM>]

Aleksey,

Thank you for reviewing the document, and for your comments.  My
responses are inserted below following each comment.

On 18 May, comment-form@oasis-open.org writes: [xacml-comment] Public Comment
 > I have comments to a Draft 01 for RBAC implementation over
 > XACML (cs-xacml-rbac-profile-01)
 > 
 > Comment 1:
 > 
 > Section 4.2 Hierarchical RBAC propose to model role hierarchy
 > as (cite) "including a <PolicySetIdReference> to the
 > Permission <PolicySet> associated with one role inside the
 > 
 > Permission <PolicySet> associated with another role.
 > 
 > XACML profile does not cover the full semantics of role
 > hierarchy however. XACML profile does not fully cover the part
 > of RBAC that senior role inherits permissions of junior role
 > (explained below). XACML profile does not cover at all the
 > second part that junior role inherits all users from senior
 > part.
 > 
 > There are several issues i see in this approach.
 > 
 > 1) It is very hard to reverse-model role hierarchy from XACML
 > profile in this way. So managing policy in terms of role
 > hierarchy is lost. XACML profile gets only flat roles with
 > permissions.
 > 
 > 2) XACML profile does not cover the second part that junior
 > role inherits all users from senior part
 > 
 > 3) Some applications (say, J2EE security) uses methods such as
 > isUserInRole(). XACML profile will not correctly work with the
 > policy. (Is user is granted senior role,he will not be in
 > junior role.)
 > 
 > 4) Senior role must inherit all permissions from junior
 > role. If XACML profile models roles as resources, then senior
 > role must have permission for junior role as well. XACML
 > profile does not grant it.
 > 
 > What i can propose as a solution to this issue is to change
 > specification of Role hierarchy as:
 > 
 > Model role hierarchy as including a Rule granting junior role
 > to the Permission <PolicySet> associated with senior role. As
 > far as i can see this resolves all above mentioned issues
 > because it explicitly states that senior role is granted
 > junior role permission and (as consequense) all permissions
 > related to it.

One source of confusion may be that XACML RBAC policies do not
define which Subjects have which "role" Attribute values.  That
function is performed by an Attribute Authority.  An Attribute
Authority can use XACML policies to decide exactly which Subjects
are allowed to get which role Attribute values, but those
policies are different from the policies used by the PDP in
making RBAC decisions.

If I understand your comment correctly, however, I believe it
arises from a misunderstanding of how XACML RBAC works.  A senior
role DOES inherit all permissions of a junior role, and a junior
role DOES inherit all users from the senior role.

The following example illustrates how this works.

Assume senior role "Manager" can "approve" a "Purchase Order".
Assume junior role "Employee" can "write" a "Purchase Order".
Assume "Manager" is supposed to inherit all permissions of the
junior role "Employee".  There will be 4 PolicySets:

1. "Manager" Role PolicySet:

   <PolicySet PolicySetId="ManagerRolePolicySet" CombiningAlg="permit-overrides">
     <Target>
       SubjectAttributeDesignator "role" = AttributeValue "Manager"
     </Target>
     <PolicySetIdReference "ManagerPermissionPolicySet"/>
   </PolicySet>

2. "Employee" Role PolicySet

   <PolicySet PolicySetId="EmployeeRolePolicySet" CombiningAlg="permit-overrides">
     <Target>
       SubjectAttributeDesignator "role" = AttributeValue "Employee"
     </Target>
     <PolicySetIdReference "EmployeePermissionPolicySet"/>
   </PolicySet>

3. "Manager" Permission PolicySet

   <PolicySet PolicySetId="ManagerPermissionPolicySet" CombiningAlg="permit-overrides">
     <Target>Any</Target>
     <Policy PolicyId="Manager role permissions" CombiningAlg="permit-overrides">
       <Rule Effect="Permit">
         <Condition FunctionId="and">
          ResourceAttributeDesignator "resource-id" == AttributeValue "Purchase Order"
          ActionAttributeDesignator "action-id" == AttributeValue "approve"
         </Condition>
       </Rule>
     </Policy>
     <PolicySetIdReference "EmployeePermissionPolicySet">
   </PolicySet>

4. "Employee" Permission PolicySet
        
   <PolicySet PolicySetId="EmployeePermissionPolicySet" CombiningAlg="permit-overrides">
     <Target>Any</Target>
     <Policy PolicyId="Employee role permissions" CombiningAlg="permit-overrides">
       <Rule Effect="Permit">
         <Condition FunctionId="and">
          ResourceAttributeDesignator "resource-id" == AttributeValue "Purchase Order"
          ActionAttributeDesignator "action-id" == AttributeValue "write"
         </Condition>
       </Rule>
     </Policy>
   </PolicySet>

Let "Aleksey" be a Subject with a "role" Attribute of "Manager"
who submits a request to "write" a "Purchase Order".

In order for this request to return "Permit" according to the
rules of hierarchical RBAC, the Manager role will have to inherit
the "write" permission that is only explicitly associated with
the junior "Employee" role, and the junior "Employee" role will
have to inherit a user who has only the "Manager" role.

The evaluation process is:

1. The PDP tests this request against the two Role PolicySets.
   Only the Target of the "Manager" Role PolicySet applies.  So
   the PDP evaluates the rest of the "ManagerRolePolicySet",
   which is a reference to the "ManagerPermissionPolicySet".
2. The PDP evaluates the "ManagerPermissionPolicySet".  This
   PolicySet is applicable, since its <Target> is Any, so the PDP
   evaluates the rest of the "ManagerPermissionPolicySet".
3. The PDP evaluates the first Policy in the
   "ManagerPermissionPolicySet".  This Policy is not applicable,
   since the "action-id" of the request does not match.
4. The PDP evaluates the PolicySetIdReference to
   "EmployeePermissionPolicySet".
5. The "EmployeePermissionPolicySet" is applicable, since its
   <Target> is Any, so the PDP evaluates the rest of the
   "EmployeePermissionPolicySet".
6. The PDP evaluates the first Policy in the
   "EmployeePermissionPolicySet".  This returns Permit", since
   the resource-id of the request matches the required value of
   "Purchase Order" and the action-id of the request matches the
   required value of "write".

So the PDP returns "Permit".

Thus, the "Manager" role has inherited the permissions (write a
purchase order) of the junior role, and the junior role has
inherited the user (Aleksey) of the senior role.

 > Comment2:
 > 
 > XACML profile makes RBAC possible only when using multiple
 > PolicySet's. This makes a construct very complicated. Even
 > Java 2 security makes hierarchical RBAC withing one file with
 > much less exporessive power. I see the following issues here:
 > 
 > 1) The construct is too complicated for managing. I hardly
 > believe that administrator may manage RBAC policies in terms
 > of XACML, he rather will prefer doing that in terms of roles
 > themselves.
 > 
 > 2) It is one-way. I want to make one-to-one relatiuon between
 > RBAC semantics and XACML semantics.
 > 
 > 
 > 
 > I am not completely sure how to resolve issue 2, but this is
 > my impression.

For a user trying to read these policies, I agree, it is a lot of
element types to digest.  For a policy generation tool or policy
analysis tool, however, I think using multiple <PolicySet>
elements is not complicated at all.  The procedure for
constructing the <PolicySet> elements is very simple: 1) There is
exactly one Role Policy Set and one Permission Policy Set for
each defined role.  2) Each Role Policy Set contains a Target
that applies only to subjects having its associated role
Attribute, and a single PolicySetIdReference to the role's
associated PermissionPolicySet.  3) Each Permission Policy Set
applies to any subject and contains whatever Policies, Rules, and
predicates are needed to define the permissions associated with
its role - this is standard XACML except that "Subject" is not
constrained.  4) In addition, if the role is senior to any other
roles, the role's Permission Policy Set contains a
PolicySetIdReference to the Permission Policy Set for each junior
role.

The advantage is that this construct allows the use of all
XACML's flexibility and expressiveness in defining what someone
possessing a given "role" Attribue can do, all within the
standard rules for evaluating XACML policies.  It also allows
roles to be made hierarchical at a later time by changing only
the Permission Policy Set of the newly senior role.

Note that there is a new RBAC draft out for review that has very
minor changes to the original.  The only substantive change is
that it recommends use of a specific AttributeId for containing
"role" values.  This new draft is attached to
http://lists.oasis-open.org/archives/xacml/200405/msg00070.html

Several university teams and at least one major commercial
enterprise are successfully doing projects using XACML RBAC.
Other commercial and government organizations are designing
projects that will use XACML RBAC.

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692