[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: undefined
No, with my proposal, the senior role only needs to know the junior roles it *immediately* includes. It does not need to know the even more junior roles that those include, since the normal XACML PDP processing rules follow nested roles. It is much easier (and more realistic) to manage what *immediate* junior roles a senior role should include that to try to manage the *entire chain* of senior roles that include each junior role. Having more senior roles control which junior roles they include fits the hierarchical model better than having junior roles control the entire chain of senior roles that include them. Anne On 21 May, Aleksey Studnev writes: Re: Fw: undefined > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com> > To: Anne.Anderson@Sun.COM > Cc: XACML TC <xacml@lists.oasis-open.org> > Subject: Re: Fw: undefined > Date: Fri, 21 May 2004 18:02:04 +0400 > > Anne, > > your idea is that requirement to senior role to know all junior roles is > better than > junior role knowing all senior roles? > > Aleksey > > > > > Anne Anderson <Anne.Anderson@Sun.COM> > 05/21/2004 05:48 PM > Please respond to > Anne.Anderson@Sun.COM > > > To > Aleksey Studnev <Aleksey_Studnev@exigengroup.com> > cc > XACML TC <xacml@lists.oasis-open.org> > Subject > Re: Fw: undefined > > > > > > > Aleksey, > > The proposal you describe requires the administrator (or the > policy generation system) of each junior role to "know" each > senior role that includes it. That is not scalable to large > distributed systems of roles. To use your words, "This opens > another door for inconsistent policies where these statements are > wrongly expressed." > > No tool or administrator can know which senior roles include each > junior role unless the tool is keeping a global index of all the > policies that is updated every time a policy is changed. > > Having the tool manage only a single <PolicySet> at a time seems > to me to be a big plus in simplicity and scalability. > > Anne > > On 20 May, Aleksey Studnev writes: Fw: undefined > > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com> > > To: Anne.Anderson@Sun.COM > > Subject: Fw: undefined > > Date: Thu, 20 May 2004 23:21:54 +0400 > > > > Anne, > > > > sorry for mistake, i of course reversed the hierarchy. It should look > like: > > > > <PolicySet> > > <Policy> > > <Target> > > ResourceAttributeDesignator "role" = AttributeValue "Manager" > > </Target> > > <Rule Effect="Permit"> > > <Target> > > SubjectAttributeDesignator > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Aleksey" > > ActionAttributeDesignator "action-id" = AttributeValue "enable" > > </Target> > > </Rule> > > </Policy> > > > > <Policy> > > <Target> > > ResourceAttributeDesignator "role" = AttributeValue "Employee" > > </Target> > > <Rule Effect="Permit"> > > <Target> > > SubjectAttributeDesignator > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Kill > Bill" > > ActionAttributeDesignator "action-id" = AttributeValue "enable" > > </Target> > > </Rule> > > <Rule Effect="Permit"> > > <Target> > > SubjectAttributeDesignator "role-id" == AttributeValue "Manager" > > ActionAttributeDesignator "action-id" == AttributeValue "grant" > > </Target> > > </Rule> > > </Policy> > > > > </PolicySet> > > > > Here Aleksey is Manager and "Kill Bill" is Employee. > > > > Regards, > > > > Aleksey > > > > > > Anne, > > > > lets take that old example with Aleksey Manager. What i propose is to > roles assignment policy like: > > > > > > <Policy> > > <Target> > > ResourceAttributeDesignator "role" = AttributeValue "Manager" > > </Target> > > <Rule Effect="Permit"> > > <Target> > > SubjectAttributeDesignator > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Aleksey" > > ActionAttributeDesignator "action-id" = AttributeValue "enable" > > </Target> > > </Rule> > > <Rule Effect="Permit"> > > <Target> > > SubjectAttributeDesignator "role-id" == AttributeValue "Employee" > > ActionAttributeDesignator "action-id" == AttributeValue "grant" > > </Target> > > </Rule> > > </Policy> > > > > So Aleksey will be granted role attributes "Employee" and "Manager". > > Role policies remains "as is". > > Reference ( to "Employee" Permission Policy Set) to be removed from > "Manager" permission policy set. > > > > Regards, > > > > Aleksey > > -- > 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">your idea is that requirement to senior > role to know all junior roles is better than </font> > <br><font size=2 face="sans-serif">junior role knowing all senior roles?</font> > <br> > <br><font size=2 face="sans-serif">Aleksey</font> > <br> > <br> > <br> > <br> > <table width=100%> > <tr valign=top> > <td><font size=1 face="sans-serif"><b>Anne Anderson <Anne.Anderson@Sun.COM></b> > </font> > <p><font size=1 face="sans-serif">05/21/2004 05:48 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> > <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 <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 TC <xacml@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: Fw: undefined</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><font size=2><tt>Aleksey,<br> > <br> > The proposal you describe requires the administrator (or the<br> > policy generation system) of each junior role to "know" each<br> > senior role that includes it. That is not scalable to large<br> > distributed systems of roles. To use your words, "This opens<br> > another door for inconsistent policies where these statements are<br> > wrongly expressed."<br> > <br> > No tool or administrator can know which senior roles include each<br> > junior role unless the tool is keeping a global index of all the<br> > policies that is updated every time a policy is changed.<br> > <br> > Having the tool manage only a single <PolicySet> at a time seems<br> > to me to be a big plus in simplicity and scalability.<br> > <br> > Anne<br> > <br> > On 20 May, Aleksey Studnev writes: Fw: undefined<br> > > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com><br> > > To: Anne.Anderson@Sun.COM<br> > > Subject: Fw: undefined<br> > > Date: Thu, 20 May 2004 23:21:54 +0400<br> > > <br> > > Anne,<br> > > <br> > > sorry for mistake, i of course reversed the hierarchy. It should > look like:<br> > > <br> > > <PolicySet><br> > > <Policy><br> > > <Target><br> > > ResourceAttributeDesignator "role" = AttributeValue > "Manager"<br> > > </Target><br> > > <Rule Effect="Permit"><br> > > <Target><br> > > SubjectAttributeDesignator "urn:oasis:names:xacml:2.0:subject:subject-id" > = AttributeValue "Aleksey"<br> > > ActionAttributeDesignator "action-id" = AttributeValue > "enable"<br> > > </Target><br> > > </Rule><br> > > </Policy><br> > > <br> > > <Policy><br> > > <Target><br> > > ResourceAttributeDesignator "role" = AttributeValue > "Employee"<br> > > </Target><br> > > <Rule Effect="Permit"><br> > > <Target><br> > > SubjectAttributeDesignator "urn:oasis:names:xacml:2.0:subject:subject-id" > = AttributeValue "Kill Bill"<br> > > ActionAttributeDesignator "action-id" = AttributeValue > "enable"<br> > > </Target><br> > > </Rule><br> > > <Rule Effect="Permit"><br> > > <Target><br> > > SubjectAttributeDesignator "role-id" == AttributeValue > "Manager"<br> > > ActionAttributeDesignator "action-id" == AttributeValue > "grant"<br> > > </Target><br> > > </Rule><br> > > </Policy><br> > > <br> > > </PolicySet><br> > > <br> > > Here Aleksey is Manager and "Kill Bill" is Employee.<br> > > <br> > > Regards,<br> > > <br> > > Aleksey<br> > > <br> > > <br> > > Anne,<br> > > <br> > > lets take that old example with Aleksey Manager. What i propose is > to roles assignment policy like:<br> > > <br> > > <br> > > <Policy><br> > > <Target><br> > > ResourceAttributeDesignator "role" = AttributeValue > "Manager"<br> > > </Target><br> > > <Rule Effect="Permit"><br> > > <Target><br> > > SubjectAttributeDesignator "urn:oasis:names:xacml:2.0:subject:subject-id" > = AttributeValue "Aleksey"<br> > > ActionAttributeDesignator "action-id" = AttributeValue > "enable"<br> > > </Target><br> > > </Rule><br> > > <Rule Effect="Permit"><br> > > <Target><br> > > SubjectAttributeDesignator "role-id" == AttributeValue > "Employee"<br> > > ActionAttributeDesignator "action-id" == AttributeValue > "grant"<br> > > </Target><br> > > </Rule><br> > > </Policy><br> > > <br> > > So Aleksey will be granted role attributes "Employee" and > "Manager".<br> > > Role policies remains "as is".<br> > > Reference ( to "Employee" Permission Policy Set) to be > removed from "Manager" permission policy set.<br> > > <br> > > Regards,<br> > > <br> > > Aleksey<br> > <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]