<div dir="ltr">Mark,<div><br></div><div style>In quantum we already perform property based checking to some extent (don't know about glance however, which has a fairly different model from what I gather).</div><div style>
We rely on a check for validating attributes within a resource - for instance we can prevent non-admin users from manipulating the "shared" and "router:external" attributes on networks.</div><div style>
<br></div><div style>What we would like to here is to extend this check to go further and inspect the content of structured attributes - like enable_snat which is a sub-attribute of the 'external_gateway_info' attribute. However, I'm glad to see that you agree this is a valid question for authZ in Openstack projects.</div>
<div style><br></div><div style>To get to Peter's point, role:xxxx rules are the ones which wil be enforced at the end. Before enforcing one of such rules, we need another rule that it's triggered when some conditions on the API requests are met.</div>
<div style><br></div><div style>Salvatore</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 May 2013 00:35, Mark Washenberger <span dir="ltr"><<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Salvatore,<div><br></div><div>We are looking at implementing a similar feature in glance. It is an open question to me whether or not this level of authz specification can live in the policy engine at all. But it definitely seems to be a valid use case to me (i.e. I couldn't agree with your solution #1.) </div>

<div><br></div><div>Blueprint: <a href="https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection" target="_blank">https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection</a></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote"><div><div class="h5">On Tue, Apr 30, 2013 at 4:09 PM, Mellquist, Peter <span dir="ltr"><<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">






<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Salvatore,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Have you considered using the Keystone ‘role’ for this? For example, for this service you might have two roles, a ‘user’ and ‘admin’ role. When the Keystone
 middleware validates the request, e.g. token, the service will be able to access the role and if it is ‘admin’ then additional attributes could then be included in the response.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Peter.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Salvatore Orlando [mailto:<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>]
<br>
<b>Sent:</b> Tuesday, April 30, 2013 3:57 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] A (probably) interesting authZ question<u></u><u></u></span></p>
</div><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I am sending this to a broader audience since recently for a patch on openstack-network we've come across a peculiar authZ problem, which might have been already solved in some other project.<u></u><u></u></p>


</div>
<div>
<p class="MsoNormal">Basically some API resources have composite attributes, ie: attributes whose value is a dict.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">In some case there might be a need to authorize access to such attributes.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For instance, in this specific case we have:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"router" : {<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">   <... some router stuff ..><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">   "external_gateway_info" : {<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">        "network_id": "some_uuid",<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">        "enable_snat": "true"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">   }<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">   < .. some more router stuff ... ><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">}<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">and we would like to say that the policy for setting enable_snat must be rule:admin_only.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">there are several options, among which:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1) this way of doing authZ does not make sense at all. authZ should be enforced on resources not single attributes<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2) If the particular attribute comes from some specific extension, instead of policing access one should be allowed to turn administratively on/off the extension itself<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3) We should have a rule check for sub-attributes (like FieldCheck in quantum/policy.py).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4) The enable_snat attribute should be moved to the first-level resource, and authZ checked as with any other attribute<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">any opinion on the subject would be greatly appreciated.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Salvatore<u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>

<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>