[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Public Comment
Comment from: Aleksey_Studnev@exigengroup.com
Anne,
i understand that if user request permission _other than permission for role_ then your model works good.
I mean a case if application needs to determine that user granted a role. The real life cases include:
1) J2EE application invokes method isCallerInRole() which is standard J2EE way for application-based access control.
RBAC model implies role hierarchy for this.
2) If application needs entitlement information (say, for UI customization). For example, show or not show UI
controls depending of what user is entitled to
3) If application needs to determine what role(s) user is graned - for audit, monitoring or other purposes.
Regards,
Aleksey
Anne Anderson <Anne.Anderson@Sun.COM>
18.05.2004 12:53 AST
Please respond to Anne.Anderson
To: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
cc: xacml-comment@lists.oasis-open.org
bcc:
Subject: Re: [xacml-comment] Public Comment
On 18 May, Aleksey Studnev writes: Re: [xacml-comment] Public Comment
> 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">
> <Target>any</Target>
> <Rule Effect="Permit">
> <Target>
> SubjectAttributeDesignator "urn:oasis:names:xacml:2.0:subject:role"
> = AttributeValue "Aleksey"
> ResourceAttributeDesignator "role" = AttributeValue "Manager"
> ActionAttributeDesignator "action-id" = AttributeValue "enable"
> </Target>
> </Rule>
> </PolicySet>
>
> 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").
In the XACML model, Aleksey would probably not 'submit a request
to test if he is in role "Employee"'. Instead, here is what
would happen. Note that lots of other implementations and models
are allowed, so this is just one way it might work.
1) Aleksey would submit a request to do a specific task. In this
case, "write" a "Purchase Order". The original request would
include only his authenticated identity subject-id
("Aleksey"), the resource-id ("Purchase Order"), and the
action-id ("write"). These would be submitted by the PEP to
the PDP as an authorization decision request.
2) The PDP's Context Handler would populate an initial XACML
Request Context using these three Attributes.
3) The PDP would evaluate its policy, which would include
evaluating the "ManagerRolePolicySet" and the
"EmployeeRolePolicySet". As part of evaluation, the PDP would
request a Subject "role" Attribute from its Context Handler.
4) Since there is no "role" Attribute already in the Request
Context, the Context Handler would submit an Attribute Query
to its Attribute Authority, asking for "role" Attribute values
for Subject "Aleksey".
5) The Attribute Authority might have this information canned, or
it might consult an XACML policy to see if it is allowed to
"assign" (action-id) "Aleksey" (subject-id) each of the
possible role values (resource-id), and return those for which
it received a response of Permit from its PDP.
6) The Attribute Authority returns an Attribute Response
indicating "Aleksey" has a "role" Attribute with value
"Manager".
7) The Context Handler inserts this new Subject Attribute into
the Request Context and also returns its value to the PDP,
which then uses it in evaluating the policies.
> 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.
That is what a "Profile" is for. If your policy authoring and
management tools implement and conform to the XACML Profile for
Role Based Access Control, then they are not allowed to do that.
> 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. .
Yes, this would be possible. But I thought it was simpler and
more manageable to have one Permission Policy Set per role. If
there are multiple ones, you can always enclose them in a single
umbrella PolicySet.
> Why cant i create a permission policy set inside Role Policy Set policy
> set instead of referencing it?
> This requirement seems a bit artificial.
It is a bit artificial, and could perhaps be loosened. It would
always be possible to replace a reference with an actual embedded
instance so long as the XACML implementation supported locating
such policies.
My reasoning was that not all systems may support references to
Policies or PolicySets that are embedded inside another
PolicySet. If an embedded Permission Policy Set is referenced by
another role's Permission Policy Set, then it might not be as
easily located and instantiated.
I have been suggesting to users who want to experiment with XACML
RBAC using Sun's XACML open source implementation and using the
simple sample Policy Finder Module that they might try putting
all the PolicySets inside a single PolicySet as actual instances.
But even this requires some mods to the sample Policy Finder
Module, I believe.
> 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
> easily.
They could be arbitrarily shared, although I think it is cleaner
to keep them separate. If they are separate, it is easier to
differentiate the roles at a later time if that becomes
desireable.
> 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.
Right, you have to conform to the Profile. It is also possible
to slightly violate any other part of XACML, and it could cause
all sorts of problems. That is just the way the game works.
Anne
> Thanks,
> Aleksey
>
>
>
>
>
> 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
>
>
> 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
>
>
>
> <br><font size=2 face="sans-serif">Anne,</font>
> <br>
> <br><font size=2 face="sans-serif">thanks for the reply,</font>
> <br>
> <br><font size=2 face="sans-serif">About Comment 1: </font>
> <br><font size=2 face="sans-serif">I believe you did not describe the whole
> picture...</font>
> <br><font size=2 face="sans-serif">Lets take your policy about Employee
> and Manager. In addition to policies</font>
> <br><font size=2 face="sans-serif">you provided, you also must specify
> the policy of granting Aleksey's role "Manager". In the original</font>
> <br><font size=2 face="sans-serif">document it is described in the section
> 3.</font>
> <br><font size=2 face="sans-serif">It may look like:</font>
> <br><font size=2><tt> <Policy PolicySetId="GrantUsersRoles"
> CombiningAlg="permit-overrides"></tt></font>
> <br><font size=2><tt> <Target>any</Target><br>
> <Rule Effect="Permit"><br>
> <Target><br>
> SubjectAttributeDesignator "</tt></font><font size=3><tt>urn:oasis:names:xacml:2.0:subject:role</tt></font><font size=2><tt>"
> = AttributeValue "Aleksey"</tt></font>
> <br><font size=2><tt> ResourceAttributeDesignator
> "role" = AttributeValue "Manager"
> <br>
> ActionAttributeDesignator "action-id" =
> AttributeValue "enable" <br>
> </Target><br>
> </Rule><br>
> </PolicySet><br>
> </tt></font>
> <br><font size=2 face="sans-serif">This policy is what system administrators
> are concerned of - granting roles to principals.</font>
> <br>
> <br><font size=2><tt>Let "Aleksey" be a Subject with a "role"
> Attribute of "Manager"<br>
> who submits a request to test if he is in role "Employee".<br>
> </tt></font>
> <br><font size=2><tt>He makes a request on resource with attribute "role"
> = AttributeValue "Employee"</tt></font>
> <br><font size=2><tt>and this request apparently not granted by your policy.
> </tt></font>
> <br><font size=2><tt>Request with attribute "role" = AttributeValue
> "Manager" is granted however. </tt></font>
> <br>
> <br><font size=2><tt>So my understanding that from this example junior
> role "Employee" did not inherit</tt></font>
> <br><font size=2><tt>users (Aleksey) from senior role ("Manager").</tt></font>
> <br>
> <br><font size=2><tt>And this makes the basis concern for issues #2,3,4.</tt></font>
> <br>
> <br><font size=2><tt>About issue #1...if i take your policy example, then
> it is pretty tricky to construct</tt></font>
> <br><font size=2><tt>the role hierarchy. Flexibility of XACML allows me
> to specify any policy content,say for </tt></font>
> <br><font size=2><tt>policy 3. "Manager" Permission PolicySet.
> For example, i can include not reference to </tt></font>
> <br><font size=2><tt>EmployeePermissionPolicySet but the content of policy
> itself. From XACML semantic prospective it did</tt></font>
> <br><font size=2><tt>not change, but for administrator this is a different
> policy.<br>
> </tt></font>
> <br><font size=2 face="sans-serif">About Comment 2 </font>
> <br>
> <br><font size=2><tt>The advantage</tt></font><font size=2 face="sans-serif">
> you mentioned is absolute plus, but i do not quite understand why it leads
> to these design decisions. </font>
> <br><font size=2 face="sans-serif">More specifically:</font>
> <br>
> <br><font size=2 face="sans-serif">1) why you require to use permission
> sets as referenced policies and exaclty in the number of one?</font>
> <br><font size=2 face="sans-serif">Why can't i create 2 policies and reference
> both from the role "Managers"? It does not violate nor RBAC neither
> XACML. . </font>
> <br><font size=2 face="sans-serif">Why cant i create a permission policy
> set inside </font><font size=2><tt>Role Policy Set</tt></font><font size=2 face="sans-serif">
> policy set instead of referencing it?</font>
> <br><font size=2 face="sans-serif">This requirement seems a bit artificial.</font>
> <br>
> <br><font size=2 face="sans-serif">2) you do not mention but imply that
> </font><font size=2><tt>Permission Policy Set</tt></font><font size=2 face="sans-serif">'s
> can not be arbitrary shared between </font><font size=2><tt>Role Policy
> Set</tt></font><font size=2 face="sans-serif">'s. I am not</font>
> <br><font size=2 face="sans-serif">sure that this can be a value for RBAC
> policies (because you can do the same by inheritance), but user can break
> the profile</font>
> <br><font size=2 face="sans-serif">easily.</font>
> <br>
> <br><font size=2 face="sans-serif">3) Reverse engineering from XACML policy
> to RBAC model is complex. Even slight violation of profile (say, as described
> in 1)), and</font>
> <br><font size=2 face="sans-serif">it is close to impossible. Policy authoring
> tool will most likely use RBAC presentation of policy, not XACML (which
> is not human editable).</font>
> <br><font size=2 face="sans-serif">So the possibility to always track role
> assignments and hierarchy is very important.</font>
> <br>
> <br><font size=2><tt><br>
> </tt></font><font size=2 face="sans-serif">Thanks,</font>
> <br><font size=2 face="sans-serif">Aleksey</font>
> <br>
> <br>
> <br>
> <br>
> <table width=100%>
> <tr valign=top>
> <td>
> <td><font size=1 face="sans-serif"><b>Anne Anderson <Anne.Anderson@Sun.COM></b></font>
> <p><font size=1 face="sans-serif">05/18/2004 06:25 PM</font>
> <br><font size=1 face="sans-serif">Please respond to Anne.Anderson</font>
> <td><font size=1 face="Arial"> </font>
> <br><font size=1 face="sans-serif"> To:
> Aleksey_Studnev@exigengroup.com</font>
> <br><font size=1 face="sans-serif"> cc:
> xacml-comment@lists.oasis-open.org</font>
> <br><font size=1 face="sans-serif"> Subject:
> Re: [xacml-comment] Public Comment</font></table>
> <br>
> <br>
> <br><font size=2><tt>Aleksey,<br>
> <br>
> Thank you for reviewing the document, and for your comments. My<br>
> responses are inserted below following each comment.<br>
> <br>
> On 18 May, comment-form@oasis-open.org writes: [xacml-comment] Public Comment<br>
> > I have comments to a Draft 01 for RBAC implementation over<br>
> > XACML (cs-xacml-rbac-profile-01)<br>
> > <br>
> > Comment 1:<br>
> > <br>
> > Section 4.2 Hierarchical RBAC propose to model role hierarchy<br>
> > as (cite) "including a <PolicySetIdReference> to the<br>
> > Permission <PolicySet> associated with one role inside the<br>
> > <br>
> > Permission <PolicySet> associated with another role.<br>
> > <br>
> > XACML profile does not cover the full semantics of role<br>
> > hierarchy however. XACML profile does not fully cover the part<br>
> > of RBAC that senior role inherits permissions of junior role<br>
> > (explained below). XACML profile does not cover at all the<br>
> > second part that junior role inherits all users from senior<br>
> > part.<br>
> > <br>
> > There are several issues i see in this approach.<br>
> > <br>
> > 1) It is very hard to reverse-model role hierarchy from XACML<br>
> > profile in this way. So managing policy in terms of role<br>
> > hierarchy is lost. XACML profile gets only flat roles with<br>
> > permissions.<br>
> > <br>
> > 2) XACML profile does not cover the second part that junior<br>
> > role inherits all users from senior part<br>
> > <br>
> > 3) Some applications (say, J2EE security) uses methods such as<br>
> > isUserInRole(). XACML profile will not correctly work with the<br>
> > policy. (Is user is granted senior role,he will not be in<br>
> > junior role.)<br>
> > <br>
> > 4) Senior role must inherit all permissions from junior<br>
> > role. If XACML profile models roles as resources, then senior<br>
> > role must have permission for junior role as well. XACML<br>
> > profile does not grant it.<br>
> > <br>
> > What i can propose as a solution to this issue is to change<br>
> > specification of Role hierarchy as:<br>
> > <br>
> > Model role hierarchy as including a Rule granting junior role<br>
> > to the Permission <PolicySet> associated with senior role.
> As<br>
> > far as i can see this resolves all above mentioned issues<br>
> > because it explicitly states that senior role is granted<br>
> > junior role permission and (as consequense) all permissions<br>
> > related to it.<br>
> <br>
> One source of confusion may be that XACML RBAC policies do not<br>
> define which Subjects have which "role" Attribute values. That<br>
> function is performed by an Attribute Authority. An Attribute<br>
> Authority can use XACML policies to decide exactly which Subjects<br>
> are allowed to get which role Attribute values, but those<br>
> policies are different from the policies used by the PDP in<br>
> making RBAC decisions.<br>
> <br>
> If I understand your comment correctly, however, I believe it<br>
> arises from a misunderstanding of how XACML RBAC works. A senior<br>
> role DOES inherit all permissions of a junior role, and a junior<br>
> role DOES inherit all users from the senior role.<br>
> <br>
> The following example illustrates how this works.<br>
> <br>
> Assume senior role "Manager" can "approve" a "Purchase
> Order".<br>
> Assume junior role "Employee" can "write" a "Purchase
> Order".<br>
> Assume "Manager" is supposed to inherit all permissions of the<br>
> junior role "Employee". There will be 4 PolicySets:<br>
> <br>
> 1. "Manager" Role PolicySet:<br>
> <br>
> <PolicySet PolicySetId="ManagerRolePolicySet" CombiningAlg="permit-overrides"><br>
> <Target><br>
> SubjectAttributeDesignator "role" = AttributeValue
> "Manager"<br>
> </Target><br>
> <PolicySetIdReference "ManagerPermissionPolicySet"/><br>
> </PolicySet><br>
> <br>
> 2. "Employee" Role PolicySet<br>
> <br>
> <PolicySet PolicySetId="EmployeeRolePolicySet" CombiningAlg="permit-overrides"><br>
> <Target><br>
> SubjectAttributeDesignator "role" = AttributeValue
> "Employee"<br>
> </Target><br>
> <PolicySetIdReference "EmployeePermissionPolicySet"/><br>
> </PolicySet><br>
> <br>
> 3. "Manager" Permission PolicySet<br>
> <br>
> <PolicySet PolicySetId="ManagerPermissionPolicySet"
> CombiningAlg="permit-overrides"><br>
> <Target>Any</Target><br>
> <Policy PolicyId="Manager role permissions"
> CombiningAlg="permit-overrides"><br>
> <Rule Effect="Permit"><br>
> <Condition FunctionId="and"><br>
> ResourceAttributeDesignator "resource-id"
> == AttributeValue "Purchase Order"<br>
> ActionAttributeDesignator "action-id"
> == AttributeValue "approve"<br>
> </Condition><br>
> </Rule><br>
> </Policy><br>
> <PolicySetIdReference "EmployeePermissionPolicySet"><br>
> </PolicySet><br>
> <br>
> 4. "Employee" Permission PolicySet<br>
> <br>
> <PolicySet PolicySetId="EmployeePermissionPolicySet"
> CombiningAlg="permit-overrides"><br>
> <Target>Any</Target><br>
> <Policy PolicyId="Employee role permissions"
> CombiningAlg="permit-overrides"><br>
> <Rule Effect="Permit"><br>
> <Condition FunctionId="and"><br>
> ResourceAttributeDesignator "resource-id"
> == AttributeValue "Purchase Order"<br>
> ActionAttributeDesignator "action-id"
> == AttributeValue "write"<br>
> </Condition><br>
> </Rule><br>
> </Policy><br>
> </PolicySet><br>
> <br>
> Let "Aleksey" be a Subject with a "role" Attribute
> of "Manager"<br>
> who submits a request to "write" a "Purchase Order".<br>
> <br>
> In order for this request to return "Permit" according to the<br>
> rules of hierarchical RBAC, the Manager role will have to inherit<br>
> the "write" permission that is only explicitly associated with<br>
> the junior "Employee" role, and the junior "Employee"
> role will<br>
> have to inherit a user who has only the "Manager" role.<br>
> <br>
> The evaluation process is:<br>
> <br>
> 1. The PDP tests this request against the two Role PolicySets.<br>
> Only the Target of the "Manager" Role PolicySet applies.
> So<br>
> the PDP evaluates the rest of the "ManagerRolePolicySet",<br>
> which is a reference to the "ManagerPermissionPolicySet".<br>
> 2. The PDP evaluates the "ManagerPermissionPolicySet". This<br>
> PolicySet is applicable, since its <Target> is Any, so the
> PDP<br>
> evaluates the rest of the "ManagerPermissionPolicySet".<br>
> 3. The PDP evaluates the first Policy in the<br>
> "ManagerPermissionPolicySet". This Policy is not
> applicable,<br>
> since the "action-id" of the request does not match.<br>
> 4. The PDP evaluates the PolicySetIdReference to<br>
> "EmployeePermissionPolicySet".<br>
> 5. The "EmployeePermissionPolicySet" is applicable, since its<br>
> <Target> is Any, so the PDP evaluates the rest of the<br>
> "EmployeePermissionPolicySet".<br>
> 6. The PDP evaluates the first Policy in the<br>
> "EmployeePermissionPolicySet". This returns Permit",
> since<br>
> the resource-id of the request matches the required value of<br>
> "Purchase Order" and the action-id of the request matches
> the<br>
> required value of "write".<br>
> <br>
> So the PDP returns "Permit".<br>
> <br>
> Thus, the "Manager" role has inherited the permissions (write
> a<br>
> purchase order) of the junior role, and the junior role has<br>
> inherited the user (Aleksey) of the senior role.<br>
> <br>
> > Comment2:<br>
> > <br>
> > XACML profile makes RBAC possible only when using multiple<br>
> > PolicySet's. This makes a construct very complicated. Even<br>
> > Java 2 security makes hierarchical RBAC withing one file with<br>
> > much less exporessive power. I see the following issues here:<br>
> > <br>
> > 1) The construct is too complicated for managing. I hardly<br>
> > believe that administrator may manage RBAC policies in terms<br>
> > of XACML, he rather will prefer doing that in terms of roles<br>
> > themselves.<br>
> > <br>
> > 2) It is one-way. I want to make one-to-one relatiuon between<br>
> > RBAC semantics and XACML semantics.<br>
> > <br>
> > <br>
> > <br>
> > I am not completely sure how to resolve issue 2, but this is<br>
> > my impression.<br>
> <br>
> For a user trying to read these policies, I agree, it is a lot of<br>
> element types to digest. For a policy generation tool or policy<br>
> analysis tool, however, I think using multiple <PolicySet><br>
> elements is not complicated at all. The procedure for<br>
> constructing the <PolicySet> elements is very simple: 1) There is<br>
> exactly one Role Policy Set and one Permission Policy Set for<br>
> each defined role. 2) Each Role Policy Set contains a Target<br>
> that applies only to subjects having its associated role<br>
> Attribute, and a single PolicySetIdReference to the role's<br>
> associated PermissionPolicySet. 3) Each Permission Policy Set<br>
> applies to any subject and contains whatever Policies, Rules, and<br>
> predicates are needed to define the permissions associated with<br>
> its role - this is standard XACML except that "Subject" is not<br>
> constrained. 4) In addition, if the role is senior to any other<br>
> roles, the role's Permission Policy Set contains a<br>
> PolicySetIdReference to the Permission Policy Set for each junior<br>
> role.<br>
> <br>
> The advantage is that this construct allows the use of all<br>
> XACML's flexibility and expressiveness in defining what someone<br>
> possessing a given "role" Attribue can do, all within the<br>
> standard rules for evaluating XACML policies. It also allows<br>
> roles to be made hierarchical at a later time by changing only<br>
> the Permission Policy Set of the newly senior role.<br>
> <br>
> Note that there is a new RBAC draft out for review that has very<br>
> minor changes to the original. The only substantive change is<br>
> that it recommends use of a specific AttributeId for containing<br>
> "role" values. This new draft is attached to<br>
> http://lists.oasis-open.org/archives/xacml/200405/msg00070.html<br>
> <br>
> Several university teams and at least one major commercial<br>
> enterprise are successfully doing projects using XACML RBAC.<br>
> Other commercial and government organizations are designing<br>
> projects that will use XACML RBAC.<br>
> <br>
> Anne Anderson<br>
> -- <br>
> Anne H. Anderson Email: Anne.Anderson@Sun.COM<br>
> Sun Microsystems Laboratories<br>
> 1 Network Drive,UBUR02-311 Tel: 781/442-0928<br>
> Burlington, MA 01803-0902 USA Fax: 781/442-1692<br>
> <br>
> </tt></font>
> <br>
--
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]