[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Public Comment. Forwarded message from AnneAnderson.
--- Begin Message ---
- From: Anne Anderson <Anne.Anderson@Sun.COM>
- To: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
- Date: Thu, 20 May 2004 09:53:10 -0400
Aleksey, More specifically, here is what I don't understand about your proposal. If you want to see if subject-id "Aleksey" is in role "associate", when Aleksey only explicitly has a role attribute for role "manager" (but "employee" is junior to "manager" and "associate" is junior to "employee"), what Request do you submit and how does the XACML PDP process it? XACML PDP does not process assignment of attributes to subjects, nor does it process delegation of rights, so I am at a loss as to how your proposal could work. Anne On 20 May, Aleksey Studnev writes: Re: [xacml-comment] Public Comment > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com> > To: Anne.Anderson@Sun.COM > Subject: Re: [xacml-comment] Public Comment > Date: Thu, 20 May 2004 10:25:07 +0400 > > Anne, > > the proposed solution will work, but i notice the drawback of more complex > construct. > Every role is required to define special permission that it is role is > granted. This seems a little > excessive statement, because if role is granted to subject then it is > evidently granted to subject. > Also it opens another door for inconsistent policies where these > statements are wrongly expressed or > for > > Please consider the following solution: > > - To define role hierarchy you include permission for granting junior role > (not permissions of role itself!) in permission set of senior roles. > - You do not reference junior permission set from senior role > > There are at least benefits of this solution over current RBAC profile: > > 1) policy is consistent with RBAC description of inheritance users _and_ > permissions. > It is contrary to the proposed profile where this consustency must be > ensured by extra efforts. > > 2) this solution does not mandate special handling of "permission policy > sets" in a special way. > In some sense current profile uses "permission policy sets" as role > identitifaction which is a wrong approach. If role > can not be identitifed by "permission policy set" then you can not reverse > engineer XACML to RBAC. > > 3) it correctly handles requests such as "IsCallerInRole" with more simple > policy definition than profile. > > Regards, > Aleksey > > > > Anne Anderson <Anne.Anderson@Sun.COM> > 05/19/2004 05:59 PM > Please respond to > Anne.Anderson@Sun.COM > > > To > Aleksey_Studnev@exigengroup.com > cc > xacml-comment@lists.oasis-open.org > Subject > Re: [xacml-comment] Public Comment > > > > > > > On 19 May, comment-form@oasis-open.org writes: [xacml-comment] Public > Comment > > 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. > > Thanks for this explanation. Now I think I understand what you > are looking for. > > When you ask "isCallerInRole(X)", you are basically treating X as > a resource, as in "Does caller have privileges associated with > role X". I think you could model this in XACML RBAC as follows. > > In each Permission Policy Set, where role is "&role-value;X", add > a policy of the following form (or equivalent predicate or > MatchId). The policy creation tool could do this automatically. > > <Policy PolicyId="has:role" PCA="permit-overrides"> > <Rule Effect="Permit"> > <Condition FunctionId="and"> > <Apply FunctionId="anyURI-is-in"> > <AttributeValue DataType="anyURI">&role-value;X</AttributeValue> > <ResourceAttributeDesignator AttributeId="&role;" > DataType="anyURI"/> > </Apply> > <Apply FunctionId="string-is-in"> > <AttributeValue > DataType="string">hasPrivilegesOfRole</AttributeValue> > <ActionAttributeDesignator AttributeId="action-id" > DataType="string"/> > </Apply> > </Condition> > </Rule> > </Policy> > > Now, to ask whether "Aleksey" has role "&role;employee", submit > the following request: > > <Request> > <Subject>subject-id = "Aleksey"</Subject> > <Resource>&role; = "&role-value;employee</Resource> > <Action>action-id = "hasPrivilegesOfRole</Action> > </Request> > > This request should follow the hierarchical role chaining and > give the correct result. > > [Let me know if you need to have this written out in full XACML > XML syntax] > > I haven't thought too much about this, so let me know if you see > anything wrong with it. > > Thanks for the question. It stimulated some interesting thinking > on my part. It may be worth adding this stuff to the XACML > Profile for RBAC. > > Anne > -- > 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 > > Note: When an application calls "isCallerInRole", the application is > then taking on the functions of the access control system. In > the case of associating certain options on a web page with a > role, the application has those options (resources) associated > with the role name, rather than asking the access control system > whether the caller has access to each resource in turn. > > In the case of auditing of role assignments, this should probably > not be done by the application, but by the AttributeAuthority or > as part of the PDP decision making itself. The application, or > the PEP, might want to audit that the caller got access to a > particular resource. > > > > > <br><font size=2 face="sans-serif">Anne,</font> > <br> > <br><font size=2 face="sans-serif">the proposed solution will work, but > i notice the drawback of more complex construct.</font> > <br><font size=2 face="sans-serif">Every role is required to define special > permission that it is role is granted. This seems a little</font> > <br><font size=2 face="sans-serif">excessive statement, because if role > is granted to subject then it is evidently granted to subject.</font> > <br><font size=2 face="sans-serif">Also it opens another door for inconsistent > policies where these statements are wrongly expressed or</font> > <br><font size=2 face="sans-serif">for</font> > <br> > <br><font size=2 face="sans-serif">Please consider the following solution:</font> > <br> > <br><font size=2 face="sans-serif">- To define role hierarchy you include > permission for granting junior role (not permissions of role itself!) in > permission set of senior roles.</font> > <br><font size=2 face="sans-serif">- You do not reference junior permission > set from senior role</font> > <br> > <br><font size=2 face="sans-serif">There are at least benefits of this > solution over current RBAC profile:</font> > <br> > <br><font size=2 face="sans-serif">1) policy is consistent with RBAC description > of inheritance users _and_ permissions. </font> > <br><font size=2 face="sans-serif">It is contrary to the proposed profile > where this consustency must be ensured by extra efforts.</font> > <br> > <br><font size=2 face="sans-serif">2) this solution does not mandate special > handling of "permission policy sets" in a special way. </font> > <br><font size=2 face="sans-serif">In some sense current profile uses "permission > policy sets" as role identitifaction which is a wrong approach. If > role</font> > <br><font size=2 face="sans-serif">can not be identitifed by "permission > policy set" then you can not reverse engineer XACML to RBAC.</font> > <br> > <br><font size=2 face="sans-serif">3) it correctly handles requests such > as "IsCallerInRole" with more simple policy definition than profile.</font> > <br> > <br><font size=2 face="sans-serif">Regards,</font> > <br><font size=2 face="sans-serif">Aleksey</font> > <br> > <br> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>Anne Anderson <Anne.Anderson@Sun.COM></b> > </font> > <p><font size=1 face="sans-serif">05/19/2004 05:59 PM</font> > <table border> > <tr valign=top> > <td bgcolor=white> > <div align=center><font size=1 face="sans-serif">Please respond to<br> > Anne.Anderson@Sun.COM</font></div></table> > <br> > <td width=59%> > <table width=100%> > <tr> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td valign=top><font size=1 face="sans-serif">Aleksey_Studnev@exigengroup.com</font> > <tr> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td valign=top><font size=1 face="sans-serif">xacml-comment@lists.oasis-open.org</font> > <tr> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td valign=top><font size=1 face="sans-serif">Re: [xacml-comment] Public > Comment</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><font size=2><tt>On 19 May, comment-form@oasis-open.org writes: [xacml-comment] > Public Comment<br> > > i understand that if user request permission _other than<br> > > permission for role_ then your model works good.<br> > > <br> > > I mean a case if application needs to determine that user<br> > > granted a role. The real life cases include:<br> > > <br> > > 1) J2EE application invokes method isCallerInRole() which is<br> > > standard J2EE way for application-based access control.<br> > > <br> > > RBAC model implies role hierarchy for this.<br> > > <br> > > 2) If application needs entitlement information (say, for UI<br> > > customization). For example, show or not show UI<br> > > <br> > > controls depending of what user is entitled to<br> > > <br> > > 3) If application needs to determine what role(s) user is<br> > > graned - for audit, monitoring or other purposes.<br> > <br> > Thanks for this explanation. Now I think I understand what you<br> > are looking for.<br> > <br> > When you ask "isCallerInRole(X)", you are basically treating > X as<br> > a resource, as in "Does caller have privileges associated with<br> > role X". I think you could model this in XACML RBAC as follows.<br> > <br> > In each Permission Policy Set, where role is "&role-value;X", > add<br> > a policy of the following form (or equivalent predicate or<br> > MatchId). The policy creation tool could do this automatically.<br> > <br> > <Policy PolicyId="has:role" PCA="permit-overrides"><br> > <Rule Effect="Permit"><br> > <Condition FunctionId="and"><br> > <Apply FunctionId="anyURI-is-in"><br> > <AttributeValue DataType="anyURI">&role-value;X</AttributeValue><br> > <ResourceAttributeDesignator AttributeId="&role;" > DataType="anyURI"/><br> > </Apply><br> > <Apply FunctionId="string-is-in"><br> > <AttributeValue DataType="string">hasPrivilegesOfRole</AttributeValue><br> > <ActionAttributeDesignator AttributeId="action-id" > DataType="string"/><br> > </Apply><br> > </Condition><br> > </Rule><br> > </Policy><br> > <br> > Now, to ask whether "Aleksey" has role "&role;employee", > submit<br> > the following request:<br> > <br> > <Request><br> > <Subject>subject-id = "Aleksey"</Subject><br> > <Resource>&role; = "&role-value;employee</Resource><br> > <Action>action-id = "hasPrivilegesOfRole</Action><br> > </Request><br> > <br> > This request should follow the hierarchical role chaining and<br> > give the correct result.<br> > <br> > [Let me know if you need to have this written out in full XACML<br> > XML syntax]<br> > <br> > I haven't thought too much about this, so let me know if you see<br> > anything wrong with it.<br> > <br> > Thanks for the question. It stimulated some interesting thinking<br> > on my part. It may be worth adding this stuff to the XACML<br> > Profile for RBAC.<br> > <br> > Anne<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> > Note: When an application calls "isCallerInRole", the application > is<br> > then taking on the functions of the access control system. In<br> > the case of associating certain options on a web page with a<br> > role, the application has those options (resources) associated<br> > with the role name, rather than asking the access control system<br> > whether the caller has access to each resource in turn.<br> > <br> > In the case of auditing of role assignments, this should probably<br> > not be done by the application, but by the AttributeAuthority or<br> > as part of the PDP decision making itself. The application, or<br> > the PEP, might want to audit that the caller got access to a<br> > particular resource.<br> > <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--- End Message ---
-- 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]