<div dir="ltr">Hi,<div><br></div><div style>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.</div>
<div style>Basically some API resources have composite attributes, ie: attributes whose value is a dict.<br></div><div style>In some case there might be a need to authorize access to such attributes.</div><div style><br></div>
<div style>For instance, in this specific case we have:</div><div style><br></div><div style>"router" : {</div><div style>   <... some router stuff ..></div><div style>   "external_gateway_info" : {</div>
<div style>        "network_id": "some_uuid",</div><div style>        "enable_snat": "true"</div><div style>   }</div><div style>   < .. some more router stuff ... ></div><div style>
}</div><div style><br></div><div style>and we would like to say that the policy for setting enable_snat must be rule:admin_only.</div><div style>there are several options, among which:</div><div style><br></div><div style>
1) this way of doing authZ does not make sense at all. authZ should be enforced on resources not single attributes</div><div style>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</div>
<div style>3) We should have a rule check for sub-attributes (like FieldCheck in quantum/policy.py).</div><div style>4) The enable_snat attribute should be moved to the first-level resource, and authZ checked as with any other attribute</div>
<div style><br></div><div style>any opinion on the subject would be greatly appreciated.</div><div style><br></div><div style>Regards,</div><div style>Salvatore</div></div>