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: Re: Fw: alternative "isCallerInRole" implementation


Aleksey,

I am still trying to understand your RBAC model.  I believe use
of RBAC in your model requires two steps:

1) Ask the PDP if the Subject has a given role enabled.  There is
   a collection of policies that answers this question, and this
   collection supports hierarchies of roles.

2) Using the given role now as a Subject Attribute, ask if the
   Subject has permission to do some particular action on some
   particular resource.  The collection of policies for answering
   this question is not hierarchical, so you have to ask the
   question using the right role value.

Is this correct?

Anne

On 24 May, Aleksey Studnev writes: Fw: alternative "isCallerInRole" implementation
 > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
 > To: Anne.Anderson@Sun.COM
 > Subject: Fw: alternative "isCallerInRole" implementation
 > Date: Mon, 24 May 2004 20:08:27 +0400
 > 
 > Two notes i would like to add...
 > 
 > 1) Only attribute finder extension not enough for this, however. Probably 
 > PEP needs to extend a role attribute type and implement Function for 
 > matching roles. Function when matching attribute role to subject 
 > "inactive" role. If it matches the role becomes "active" for this subject 
 > and the function returns match.
 > 
 > 2) Conflicting roles are described in RBAC profile. User does not manage 
 > roles by himself, instead, user is requesting a resource access and as a 
 > result, requesting a role from policy. If granted, then this role becoming 
 > active. User typically does not control roles manually.
 > So this results in an architecture when PEP resolves roles at time when 
 > resource access is requested. Before that PEP can not assign any role to 
 > user.
 > 
 > Regards,
 >  Aleksey
 > 
 > ----- Forwarded by Aleksey Studnev/MOW/Exigen on 05/24/2004 08:01 PM -----
 > 
 > Aleksey Studnev/MOW/Exigen
 > 05/24/2004 07:09 PM
 > 
 > To
 > Anne.Anderson@Sun.COM
 > cc
 > 
 > Subject
 > re: alternative "isCallerInRole" implementation
 > 
 > 
 > 
 > 
 > 
 > Anne,
 > 
 > i assume that PEP, or more specifically, an attribute finder of PEP knows 
 > that Subject's role attribute is a permission and must be requested from 
 > PDP as permission for specific "role" resource. As far as i understand, 
 > this procedure follows RBAC profile as described in section "Assigning and 
 > Enabling Role Attributes (nonnormative)".
 > 
 > This is the way how role assignment works - when request is coming to PDP, 
 > no Subject role attribute exist in Subject, because roles are permissions 
 > and are modeled as Subject attributes only as a way to suite XACML 
 > semantics. There is no way to determine what roles are to request before 
 > hand.
 > 
 > Attribute finder requests PDP for findAttribute() when attribute is a 
 > role. These are assumptions i had when describing procedure.
 > 
 > Regards,
 >  Aleksey
 > 
 > 
 > 
 > Anne Anderson <Anne.Anderson@Sun.COM> 
 > 05/24/2004 05:43 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: alternative "isCallerInRole" implementation
 > 
 > 
 > 
 > 
 > 
 > 
 > On 24 May, Aleksey Studnev writes: Re: Fw: undefined
 >  > i followed the model of roles in your profile which assumes that "role" 
 > 
 >  > attributes of Subject are permissions
 >  > for the resource.
 >  > Following this, when PEP makes execution of the request it does not 
 > store 
 >  > any attributes for roles in subject - it rather
 >  > request them as permission for specific resource. In this extent my 
 >  > example follows your model defined in profile.
 >  > So far the sequence will be:
 >  > 1) Submit request 
 >  >  <Request>
 >  >      <Subject>subject-id = AttributeValue "Anne"</Subject>
 >  >      <Resource>role = AttributeValue "Employee"</Resource>
 >  >      <Action>action-id = AttributeValue "enable"</Action>
 >  >   </Request>
 >  > 2) PDP looks in policy and finds:
 >  >    <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>
 >  > 3) Policy checks for "urn:oasis:names:xacml:2.0:subject:subject-id" = 
 >  > AttributeValue "Kill   Bill" and this does not match.
 > 
 > So far, right.
 > 
 >  > 4) Policy checks for "role-id" == AttributeValue "Manager" in Subject 
 >  > which is done throught permission check
 >  > (is role granted)
 > 
 > And this does not match, so the second <Rule> is not applicable.
 > The PDP now stops and returns "NotApplicable" because all
 > <Policy> elements have been evaluated, and none was applicable.
 > 
 > The PDP does not "grant" the "Manager" role-id.  The PDP does not
 > "do" actions - they are just strings that it interprets according
 > to its matching rules.  The PDP does not understand the word
 > "grant" and does not "grant" that role for any further
 > evaluation.
 > 
 > You could possibly implement a PDP that did understand "grant",
 > but that is not currently part of the XACML specification.  I
 > think you would quickly run into problems, however.  Your model
 > seems to be that if the PDP encounters an "action" that matches a
 > distinguished value "grant", and all other attributes match, then
 > the Target resource should be effectively substituted for the
 > original resource in the Request, and evaluation would start
 > over.  For starters, this would require XACML to evaluate <Rule>
 > elements in a <Policy> where the <Target> of the <Policy> did not
 > match - XACML currently says do not evaluate a <Policy> if the
 > <Target> does not match.  I think that is only the start of the
 > problems you will run into.
 > 
 > The XACML TC is working on a model for delegation that might do
 > something like what you want, but it is a very hard problem.
 > 
 >  > 5) Policy finds rules
 >  >   <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 
 > "Superuser"
 >  >       ActionAttributeDesignator "action-id" == AttributeValue "grant"
 >  >      </Target>
 >  >     </Rule>
 >  >    </Policy>
 >  > 6) Policy checks for SubjectAttributeDesignator 
 >  >   "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue 
 >  > "Aleksey" and this does not match
 >  > 7) Policy checks for SubjectAttributeDesignator "role-id" == 
 >  > AttributeValue "Superuser" and this is permission check
 >  > 8)  Policy finds rules and they match due to SubjectAttributeDesignator 
 > 
 >  > urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Anne"
 >  > 
 >  > PEP of course must be implemented in the way that it is aware that role 
 > 
 >  > attributes in Subject are permissions
 >  > and should be requested.
 > 
 > I don't understand what you mean.  The PEP received a request for
 > "isCallerInRole("Anne","employee"), so it sent the following
 > request to the PDP:
 > 
 >     <Request>
 >        <Subject>..Anne..</Subject>
 >        <Resource>..employee..</Resource>
 >        <Action>..grant..</Action>
 >     </Request>
 > 
 > Is that what you meant by "it is aware that role attributes in
 > Subject are permissions and should be requested"?
 > 
 > With your set of policies, interpreted according to the XACML
 > specification, the PEP gets back a response of "NotApplicable".
 > 
 > Anne
 > 
 >  > Regards,
 >  > Aleksey
 >  > 
 >  > 
 >  > 
 >  > 
 >  > Anne Anderson <Anne.Anderson@Sun.COM> 
 >  > 05/21/2004 10:35 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
 >  > 
 >  > 
 >  > 
 >  > 
 >  > 
 >  > 
 >  > Your example does not work.  What request would I submit in order
 >  > to find out whether isCallerInRole("Anne","employee"), if "Anne"
 >  > has role "Superuser"?
 >  > 
 >  > If I submit following:
 >  > 
 >  >   <Request>
 >  >      <Subject>subject-id = AttributeValue "Anne"</Subject>
 >  >      <Resource>role = AttributeValue "Employee"</Resource>
 >  >      <Action>action-id = AttributeValue "enable"</Action>
 >  >   </Request>
 >  > 
 >  > I do not get any Rule that returns "Permit".
 >  > 
 >  > You seem to be trying to do delegation, where XACML does not yet
 >  > support delegation (we are discussing it).
 >  > 
 >  > Anne
 >  > 
 >  > On 21 May, Aleksey Studnev writes: Re: Fw: undefined
 >  >  > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
 >  >  > To: Anne.Anderson@Sun.COM
 >  >  > Subject: Re: Fw: undefined
 >  >  > Date: Fri, 21 May 2004 18:47:53 +0400
 >  >  > 
 >  >  > Anne,
 >  >  > 
 >  >  > in this sense ("*immediately* issue") we are on the same page. With 
 > my 
 >  >  > proposal you only need
 >  >  > to include immedeate roles as well. I will add another role 
 > (Superuser 
 >  >  > which is senior to Manager) to demonstrate that:
 >  >  > 
 >  >  > <PolicySet>
 >  >  > <Policy>
 >  >  >   <Target>
 >  >  >    ResourceAttributeDesignator "role" = AttributeValue "Superuser"
 >  >  >   </Target>
 >  >  >   <Rule Effect="Permit">
 >  >  >    <Target>
 >  >  >     SubjectAttributeDesignator 
 >  >  > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue 
 > "Anne"
 >  >  >     ActionAttributeDesignator "action-id" = AttributeValue "enable"
 >  >  >    </Target>
 >  >  >   </Rule>
 >  >  >  </Policy>
 >  >  > 
 >  >  > <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 
 > "Superuser"
 >  >  >     ActionAttributeDesignator "action-id" == AttributeValue "grant"
 >  >  >    </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>
 > -- 
 > 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">Two notes i would like to add...</font>
 > <br>
 > <br><font size=2 face="sans-serif">1) Only attribute finder extension not
 > enough for this, however. Probably PEP needs to extend a role attribute
 > type and implement Function for matching roles. Function when matching
 > attribute role to subject &quot;inactive&quot; role. If it matches the
 > role becomes &quot;active&quot; for this subject and the function returns
 > match.</font>
 > <br>
 > <br><font size=2 face="sans-serif">2) Conflicting roles are described in
 > RBAC profile. User does not manage roles by himself, instead, user is requesting
 > a resource access and as a result, requesting a role from policy. If granted,
 > then this role becoming active. User typically does not control roles manually.</font>
 > <br><font size=2 face="sans-serif">So this results in an architecture when
 > PEP resolves roles at time when resource access is requested. Before that
 > PEP can not assign any role to user.</font>
 > <br>
 > <br><font size=2 face="sans-serif">Regards,<br>
 >  Aleksey</font>
 > <br>
 > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Aleksey
 > Studnev/MOW/Exigen on 05/24/2004 08:01 PM -----</font>
 > <br>
 > <table width=100%>
 > <tr valign=top>
 > <td width=40%><font size=1 face="sans-serif"><b>Aleksey Studnev/MOW/Exigen</b></font>
 > <p><font size=1 face="sans-serif">05/24/2004 07:09 PM</font>
 > <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">Anne.Anderson@Sun.COM</font>
 > <tr>
 > <td>
 > <div align=right><font size=1 face="sans-serif">cc</font></div>
 > <td valign=top>
 > <tr>
 > <td>
 > <div align=right><font size=1 face="sans-serif">Subject</font></div>
 > <td valign=top><font size=1 face="sans-serif">re: alternative &quot;isCallerInRole&quot;
 > implementation</font><a href=Notes:///882569C2006FC602/FDE795BAD5B0E8BE4225695000451E36/2DFFFFBA5D1D218388256E9E004B72B5>Link</a></table>
 > <br>
 > <table>
 > <tr valign=top>
 > <td>
 > <td></table>
 > <br></table>
 > <br>
 > <br><font size=2 face="sans-serif">Anne,</font>
 > <br>
 > <br><font size=2 face="sans-serif">i assume that PEP, or more specifically,
 > an attribute finder of PEP knows that Subject's role attribute is a permission
 > and must be requested from PDP as permission for specific &quot;role&quot;
 > resource. As far as i understand, this procedure follows RBAC profile as
 > described in section &quot;Assigning and Enabling Role Attributes (nonnormative)&quot;.</font>
 > <br>
 > <br><font size=2 face="sans-serif">This is the way how role assignment
 > works - when request is coming to PDP, no Subject role attribute exist
 > in Subject, because roles are permissions and are modeled as Subject attributes
 > only as a way to suite XACML semantics. There is no way to determine what
 > roles are to request before hand.</font>
 > <br>
 > <br><font size=2 face="sans-serif">Attribute finder requests PDP for findAttribute()
 > when attribute is a role. These are assumptions i had when describing procedure.</font>
 > <br>
 > <br><font size=2 face="sans-serif">Regards,<br>
 >  Aleksey</font>
 > <br>
 > <br>
 > <br>
 > <table width=100%>
 > <tr valign=top>
 > <td><font size=1 face="sans-serif"><b>Anne Anderson &lt;Anne.Anderson@Sun.COM&gt;</b>
 > </font>
 > <p><font size=1 face="sans-serif">05/24/2004 05:43 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 &lt;Aleksey_Studnev@exigengroup.com&gt;</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 &lt;xacml@lists.oasis-open.org&gt;</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: alternative &quot;isCallerInRole&quot;
 > implementation</font></table>
 > <br>
 > <table>
 > <tr valign=top>
 > <td>
 > <td></table>
 > <br></table>
 > <br>
 > <br>
 > <br><font size=2><tt>On 24 May, Aleksey Studnev writes: Re: Fw: undefined<br>
 >  &gt; i followed the model of roles in your profile which assumes that
 > &quot;role&quot; <br>
 >  &gt; attributes of Subject are permissions<br>
 >  &gt; for the resource.<br>
 >  &gt; Following this, when PEP makes execution of the request it does not
 > store <br>
 >  &gt; any attributes for roles in subject - it rather<br>
 >  &gt; request them as permission for specific resource. In this extent
 > my <br>
 >  &gt; example follows your model defined in profile.<br>
 >  &gt; So far the sequence will be:<br>
 >  &gt; 1) Submit request <br>
 >  &gt; &nbsp;&lt;Request&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Subject&gt;subject-id = AttributeValue &quot;Anne&quot;&lt;/Subject&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Resource&gt;role = AttributeValue &quot;Employee&quot;&lt;/Resource&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Action&gt;action-id = AttributeValue &quot;enable&quot;&lt;/Action&gt;<br>
 >  &gt; &nbsp; &lt;/Request&gt;<br>
 >  &gt; 2) PDP looks in policy and finds:<br>
 >  &gt; &nbsp; &nbsp;&lt;Policy&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;ResourceAttributeDesignator &quot;role&quot;
 > = AttributeValue &quot;Employee&quot;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; SubjectAttributeDesignator <br>
 >  &gt; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot; = AttributeValue
 > &quot;Kill <br>
 >  &gt; Bill&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;ActionAttributeDesignator &quot;action-id&quot;
 > = AttributeValue &quot;enable&quot;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp;&lt;/Rule&gt;<br>
 >  &gt; &nbsp; &nbsp;&lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; SubjectAttributeDesignator &quot;role-id&quot;
 > == AttributeValue &quot;Manager&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > == AttributeValue &quot;grant&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp; &nbsp;&lt;/Policy&gt;<br>
 >  &gt; 3) Policy checks for &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot;
 > = <br>
 >  &gt; AttributeValue &quot;Kill &nbsp; Bill&quot; and this does not match.<br>
 > <br>
 > So far, right.<br>
 > <br>
 >  &gt; 4) Policy checks for &quot;role-id&quot; == AttributeValue &quot;Manager&quot;
 > in Subject <br>
 >  &gt; which is done throught permission check<br>
 >  &gt; (is role granted)<br>
 > <br>
 > And this does not match, so the second &lt;Rule&gt; is not applicable.<br>
 > The PDP now stops and returns &quot;NotApplicable&quot; because all<br>
 > &lt;Policy&gt; elements have been evaluated, and none was applicable.<br>
 > <br>
 > The PDP does not &quot;grant&quot; the &quot;Manager&quot; role-id. &nbsp;The
 > PDP does not<br>
 > &quot;do&quot; actions - they are just strings that it interprets according<br>
 > to its matching rules. &nbsp;The PDP does not understand the word<br>
 > &quot;grant&quot; and does not &quot;grant&quot; that role for any further<br>
 > evaluation.<br>
 > <br>
 > You could possibly implement a PDP that did understand &quot;grant&quot;,<br>
 > but that is not currently part of the XACML specification. &nbsp;I<br>
 > think you would quickly run into problems, however. &nbsp;Your model<br>
 > seems to be that if the PDP encounters an &quot;action&quot; that matches
 > a<br>
 > distinguished value &quot;grant&quot;, and all other attributes match,
 > then<br>
 > the Target resource should be effectively substituted for the<br>
 > original resource in the Request, and evaluation would start<br>
 > over. &nbsp;For starters, this would require XACML to evaluate &lt;Rule&gt;<br>
 > elements in a &lt;Policy&gt; where the &lt;Target&gt; of the &lt;Policy&gt;
 > did not<br>
 > match - XACML currently says do not evaluate a &lt;Policy&gt; if the<br>
 > &lt;Target&gt; does not match. &nbsp;I think that is only the start of
 > the<br>
 > problems you will run into.<br>
 > <br>
 > The XACML TC is working on a model for delegation that might do<br>
 > something like what you want, but it is a very hard problem.<br>
 > <br>
 >  &gt; 5) Policy finds rules<br>
 >  &gt; &nbsp; &lt;Policy&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;ResourceAttributeDesignator &quot;role&quot;
 > = AttributeValue &quot;Manager&quot;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; SubjectAttributeDesignator <br>
 >  &gt; &nbsp; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot; =
 > AttributeValue <br>
 >  &gt; &quot;Aleksey&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > = AttributeValue &quot;enable&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; SubjectAttributeDesignator &quot;role-id&quot;
 > == AttributeValue &quot;Superuser&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > == AttributeValue &quot;grant&quot;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp; &nbsp;&lt;/Policy&gt;<br>
 >  &gt; 6) Policy checks for SubjectAttributeDesignator <br>
 >  &gt; &nbsp; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot; =
 > AttributeValue <br>
 >  &gt; &quot;Aleksey&quot; and this does not match<br>
 >  &gt; 7) Policy checks for SubjectAttributeDesignator &quot;role-id&quot;
 > == <br>
 >  &gt; AttributeValue &quot;Superuser&quot; and this is permission check<br>
 >  &gt; 8) &nbsp;Policy finds rules and they match due to &nbsp; &nbsp;SubjectAttributeDesignator
 > <br>
 >  &gt; urn:oasis:names:xacml:2.0:subject:subject-id&quot; = AttributeValue
 > &quot;Anne&quot;<br>
 >  &gt; <br>
 >  &gt; PEP of course must be implemented in the way that it is aware that
 > role <br>
 >  &gt; attributes in Subject are permissions<br>
 >  &gt; and should be requested.<br>
 > <br>
 > I don't understand what you mean. &nbsp;The PEP received a request for<br>
 > &quot;isCallerInRole(&quot;Anne&quot;,&quot;employee&quot;), so it sent
 > the following<br>
 > request to the PDP:<br>
 > <br>
 >  &nbsp; &nbsp;&lt;Request&gt;<br>
 >  &nbsp; &nbsp; &nbsp; &lt;Subject&gt;..Anne..&lt;/Subject&gt;<br>
 >  &nbsp; &nbsp; &nbsp; &lt;Resource&gt;..employee..&lt;/Resource&gt;<br>
 >  &nbsp; &nbsp; &nbsp; &lt;Action&gt;..grant..&lt;/Action&gt;<br>
 >  &nbsp; &nbsp;&lt;/Request&gt;<br>
 > <br>
 > Is that what you meant by &quot;it is aware that role attributes in<br>
 > Subject are permissions and should be requested&quot;?<br>
 > <br>
 > With your set of policies, interpreted according to the XACML<br>
 > specification, the PEP gets back a response of &quot;NotApplicable&quot;.<br>
 > <br>
 > Anne<br>
 > <br>
 >  &gt; Regards,<br>
 >  &gt; Aleksey<br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; Anne Anderson &lt;Anne.Anderson@Sun.COM&gt; <br>
 >  &gt; 05/21/2004 10:35 PM<br>
 >  &gt; Please respond to<br>
 >  &gt; Anne.Anderson@Sun.COM<br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; To<br>
 >  &gt; Aleksey Studnev &lt;Aleksey_Studnev@exigengroup.com&gt;<br>
 >  &gt; cc<br>
 >  &gt; XACML TC &lt;xacml@lists.oasis-open.org&gt;<br>
 >  &gt; Subject<br>
 >  &gt; Re: Fw: undefined<br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; <br>
 >  &gt; Your example does not work. &nbsp;What request would I submit in
 > order<br>
 >  &gt; to find out whether isCallerInRole(&quot;Anne&quot;,&quot;employee&quot;),
 > if &quot;Anne&quot;<br>
 >  &gt; has role &quot;Superuser&quot;?<br>
 >  &gt; <br>
 >  &gt; If I submit following:<br>
 >  &gt; <br>
 >  &gt; &nbsp; &lt;Request&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Subject&gt;subject-id = AttributeValue &quot;Anne&quot;&lt;/Subject&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Resource&gt;role = AttributeValue &quot;Employee&quot;&lt;/Resource&gt;<br>
 >  &gt; &nbsp; &nbsp; &nbsp;&lt;Action&gt;action-id = AttributeValue &quot;enable&quot;&lt;/Action&gt;<br>
 >  &gt; &nbsp; &lt;/Request&gt;<br>
 >  &gt; <br>
 >  &gt; I do not get any Rule that returns &quot;Permit&quot;.<br>
 >  &gt; <br>
 >  &gt; You seem to be trying to do delegation, where XACML does not yet<br>
 >  &gt; support delegation (we are discussing it).<br>
 >  &gt; <br>
 >  &gt; Anne<br>
 >  &gt; <br>
 >  &gt; On 21 May, Aleksey Studnev writes: Re: Fw: undefined<br>
 >  &gt; &nbsp;&gt; From: Aleksey Studnev &lt;Aleksey_Studnev@exigengroup.com&gt;<br>
 >  &gt; &nbsp;&gt; To: Anne.Anderson@Sun.COM<br>
 >  &gt; &nbsp;&gt; Subject: Re: Fw: undefined<br>
 >  &gt; &nbsp;&gt; Date: Fri, 21 May 2004 18:47:53 +0400<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; Anne,<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; in this sense (&quot;*immediately* issue&quot;) we are
 > on the same page. With my <br>
 >  &gt; &nbsp;&gt; proposal you only need<br>
 >  &gt; &nbsp;&gt; to include immedeate roles as well. I will add another
 > role (Superuser <br>
 >  &gt; &nbsp;&gt; which is senior to Manager) to demonstrate that:<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; &lt;PolicySet&gt;<br>
 >  &gt; &nbsp;&gt; &lt;Policy&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;ResourceAttributeDesignator &quot;role&quot;
 > = AttributeValue &quot;Superuser&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; SubjectAttributeDesignator <br>
 >  &gt; &nbsp;&gt; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot;
 > = AttributeValue &quot;Anne&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > = AttributeValue &quot;enable&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp;&lt;/Policy&gt;<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; &lt;Policy&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;ResourceAttributeDesignator &quot;role&quot;
 > = AttributeValue &quot;Manager&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; SubjectAttributeDesignator <br>
 >  &gt; &nbsp;&gt; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot;
 > = AttributeValue <br>
 >  &gt; &quot;Aleksey&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > = AttributeValue &quot;enable&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; SubjectAttributeDesignator &quot;role-id&quot;
 > == AttributeValue &quot;Superuser&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > == AttributeValue &quot;grant&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp;&lt;/Policy&gt;<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; &nbsp;&lt;Policy&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;ResourceAttributeDesignator &quot;role&quot;
 > = AttributeValue &quot;Employee&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; SubjectAttributeDesignator <br>
 >  &gt; &nbsp;&gt; &quot;urn:oasis:names:xacml:2.0:subject:subject-id&quot;
 > = AttributeValue &quot;Kill <br>
 >  &gt; &nbsp;&gt; Bill&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > = AttributeValue &quot;enable&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;Rule Effect=&quot;Permit&quot;&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; SubjectAttributeDesignator &quot;role-id&quot;
 > == AttributeValue &quot;Manager&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp; ActionAttributeDesignator &quot;action-id&quot;
 > == AttributeValue &quot;grant&quot;<br>
 >  &gt; &nbsp;&gt; &nbsp; &nbsp;&lt;/Target&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp; &lt;/Rule&gt;<br>
 >  &gt; &nbsp;&gt; &nbsp;&lt;/Policy&gt;<br>
 >  &gt; &nbsp;&gt; <br>
 >  &gt; &nbsp;&gt; &nbsp;&lt;/PolicySet&gt;<br>
 > -- <br>
 > Anne H. Anderson &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Email: Anne.Anderson@Sun.COM<br>
 > Sun Microsystems Laboratories<br>
 > 1 Network Drive,UBUR02-311 &nbsp; &nbsp; Tel: 781/442-0928<br>
 > Burlington, MA 01803-0902 USA &nbsp;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]