<div dir="ltr"><div>Hi Christian, </div><div><br></div><div>There were changes proposed recently that documented this behavior [1] [2], but they haven't been merged yet.</div><div><br></div><div>You're using v2.0, correct? </div><div><br></div><div>The v2.0 API enforces policy/context at the controller layer [3], which calls assert_admin. By the looks of it, assert_admin is hardcoded to check for the 'admin_required' rule [4]. This is probably why you're seeing it work when you add the '_member_' role to the 'admin_required' rule, but not when you add '_member_' to the policy of the call. </div><div><br></div><div>Version 3 does this a little bit differently, which uses a different mechanism than 'assert_admin' for enforcing policy [5]. It doesn't look like the filterprotected method uses the hard coded check that lives in assert_admin [6]. The behavior you're looking for might be different between v2.0 and v3. Given that it's hard coded to look for the 'admin_required' rule in v2.0, and not in v3. </div><div><br></div><div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/123862/3" target="_blank">https://review.openstack.org/#/c/123862/3</a></div><div>[2] <a href="https://review.openstack.org/#/c/124638/" target="_blank">https://review.openstack.org/#/c/124638/</a></div><div>[3] <a href="https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L36-L39">https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L36-L39</a></div><div>[4] <a href="https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/wsgi.py#L301">https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/wsgi.py#L301</a></div><div>[5] <a href="https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L226">https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L226</a></div><div>[6] <a href="https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/controller.py#L169">https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/controller.py#L169</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 11:08 AM, Fischer, Matt <span dir="ltr"><<a href="mailto:matthew.fischer@twcable.com" target="_blank">matthew.fischer@twcable.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/26/15, 8:46 AM, "Christian Berendt" <<a href="mailto:berendt@b1-systems.de">berendt@b1-systems.de</a>> wrote:<br>
<br>
>On 01/26/2015 04:02 PM, Fischer, Matt wrote:<br>
>> Is there any reason that the user can¹t just run keystone catalog which<br>
>> does not require admin permissions?<br>
><br>
>Matt, this is just an example. We tried it with different list methods<br>
>and it is also not working.<br>
><br>
>We read your blog post about the topic<br>
>(<a href="http://www.mattfischer.com/blog/?p=524" target="_blank">http://www.mattfischer.com/blog/?p=524</a>) and it is working for us for<br>
>services like Neutron or Nova. But not for Keystone.<br>
><br>
>Christian.<br>
<br>
<br>
Christian,<br>
<br>
I discussed this with the keystone folks this morning and it looks like<br>
there are some internal checks for admin that are causing this. One of the<br>
keystone team will be following-up with more details.<br>
<br>
<br>
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br></div>