<div dir="ltr">I know I'm just making the problem more difficult, but I want to see how policy persistence proposals fit into the future of policy, as it expands to include policies about finer-grained entities than whole service_types.<div>
<br></div><div style>I think the real motivator for me are use cases like Image Sharing. Glance currently has support for sharing an image with another user--you just add the other user's tenant id as a "member" on the image. This approach has advantages and disadvantages</div>
<div style>+ simple and covers 80% of use cases for sharing in some form or another</div><div style>+ its fast, because I can do authorization efficiently by joining the Images table with the Image Members table</div><div style>
- No good way to verify the member tenant id is valid</div><div style>- No good way to be notified when the member tenant is removed</div><div style>- Can't specify permission in terms of a specific user, or a role</div>
<div style>- Can't specify permission on all / a group of images, have to do it individually</div><div style><br></div><div style>But when I look at AWS IAM policy, for say, S3, I see an incredibly rich policy specification. A quick googling did not turn up any articles documenting performance hits that result from applying policies to buckets. Furthermore, it seems like policies get applied pretty quickly without delays or inconsistency*.</div>
<div style><br></div><div style>The holy grail for me would be for us to come up with a policy approach that retains the performance, efficiency, and consistency of storing policies virtually alongside the data the policy effects, but also provides a central place to list and create policies, with appropriate validation of entities like user_ids, tenants, and roles.</div>
<div style><br></div><div style>I'm not trying to say we should only move forward if we can get the holy grail in Havana. But I would love to see proposals that take into consideration their effects on consistency, efficiency, and performance, and acknowledge that policy and fine-grained authz/access-control are pretty much the same problem, even if they ultimately require different solutions.</div>
<div style><br></div><div style>* I'm trying to practice some well-informed speculation here. Please correct me with anecdotes or hard data!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 9:31 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</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">Yes, the API handles serialized policy blobs, so you could use XACML or anything else just as easily.<div>
<span class="HOEnZb"><font color="#888888"><br></font></span><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><div>-Dolph</div></font></span><div><div class="h5">
<br><br><div class="gmail_quote">On Fri, May 3, 2013 at 10:14 AM, Kevin L. Mitchell <span dir="ltr"><<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, 2013-05-03 at 09:20 -0500, Dolph Mathews wrote:<br>
> This API was implemented in keystone in grizzly for centralized policy<br>
> storage:<br>
><br>
><br>
> <a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-policy-post-policies" target="_blank">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-policy-post-policies</a><br>
<br>
</div>Does this support the language-based policies now implemented in<br>
oslo-incubator and used by nova, quantum, and glance?<br>
<div>--<br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>><br>
<br>
<br>
</div><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>
</div></div></blockquote></div><br></div></div></div></div></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>