OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: Public Comment

Comment from: Aleksey_Studnev@exigengroup.mow


thanks for the reply,

About Comment 1: 
I believe you did not describe the whole picture...
Lets take your policy about Employee and Manager. In addition to policies
you provided, you also must specify the policy of granting Aleksey's role "Manager". In the original
document it is described in the section 3.
It may look like:
   <Policy PolicySetId="GrantUsersRoles" CombiningAlg="permit-overrides">
    <Rule Effect="Permit">
       SubjectAttributeDesignator "urn:oasis:names:xacml:2.0:subject:role" = AttributeValue "Aleksey"
       ResourceAttributeDesignator "role" = AttributeValue "Manager"	 
       ActionAttributeDesignator "action-id" = AttributeValue "enable"	 

This policy is what system administrators are concerned of - granting roles to principals.

Let "Aleksey" be a Subject with a "role" Attribute of "Manager"
who submits a request to test if he is in role "Employee".

He makes a request on resource with attribute "role" = AttributeValue "Employee"
and this request apparently not granted by your policy. 
Request with attribute "role" = AttributeValue "Manager" is granted however. 

So my understanding that from this example junior role "Employee" did not inherit
users (Aleksey) from senior role ("Manager").

And this makes the basis concern for issues #2,3,4.

About issue #1...if i take your policy example, then it is pretty tricky to construct
the role hierarchy. Flexibility of XACML allows me to specify any policy content,say for 
policy 3. "Manager" Permission PolicySet. For example, i can include not reference to 
EmployeePermissionPolicySet but the content of policy itself. From XACML semantic prospective it did
not change, but for administrator this is a different policy.

About Comment 2 

The advantage you mentioned is absolute plus, but i do not quite understand why it leads to these design decisions. 
More specifically:

1) why you require to use permission sets as referenced policies and exaclty in the number of one?
Why can't i create 2 policies and reference both from the role "Managers"? It does not violate nor RBAC neither XACML. . 
Why cant i create a permission policy set inside Role Policy Set policy set instead of referencing it?
This requirement seems a bit artificial.

2) you do not mention but imply that Permission Policy Set's can not be arbitrary shared between Role Policy Set's. I am not
sure that this can be a value for RBAC policies (because you can do the same by inheritance), but user can break the profile

3) Reverse engineering from XACML policy to RBAC model is complex. Even slight violation of profile (say, as described in 1)), and
it is close to impossible. Policy authoring tool will most likely use RBAC presentation of policy, not XACML (which is not human editable).
So the possibility to always track role assignments and hierarchy is very important.


	Anne Anderson <Anne.Anderson@Sun.COM>
	05/18/2004 06:25 PM
	Please respond to Anne.Anderson	 
		 To: Aleksey_Studnev@exigengroup.com
		 cc: xacml-comment@lists.oasis-open.org
		 Subject: Re: [xacml-comment] Public Comment


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">
       SubjectAttributeDesignator "role" = AttributeValue "Manager"
     <PolicySetIdReference "ManagerPermissionPolicySet"/>

2. "Employee" Role PolicySet

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

3. "Manager" Permission PolicySet

   <PolicySet PolicySetId="ManagerPermissionPolicySet" CombiningAlg="permit-overrides">
     <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"
     <PolicySetIdReference "EmployeePermissionPolicySet">

4. "Employee" Permission PolicySet
   <PolicySet PolicySetId="EmployeePermissionPolicySet" CombiningAlg="permit-overrides">
     <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"

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
5. The "EmployeePermissionPolicySet" is applicable, since its
   <Target> is Any, so the PDP evaluates the rest of the
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

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

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

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