<div dir="ltr"><div>In designing the API, the goal was to simply store policy.json files (or any future iterations of it) in any format as a blob in a centralized location (keystone) that could be retrieved by remote services. While discussing the design, it spawned a lot of great questions about how to map policies to services (one policy file per service type? what if you want different policies in different regions, different domains, or on different endpoints of the same service?); so, the interface was kept as simple as possible.<br>
</div><div><br></div><div>A name attribute was simply not included because it's not applicable to the current policy.json approach.</div><div><br></div><div>There are several proposed blueprints that will force us to think about how services (and their endpoints), or at least keystoneclient.middleware.auth_token, are/is aware of their appearance in keystone's service catalog (attributes like service ID, service type, region, endpoint ID, endpoint interface, etc):</div>
<div><br></div><div>  <a href="https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering">https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering</a><br><div class="gmail_extra"><div><div>  <a href="https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation">https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation</a></div>
<div>  <a href="https://blueprints.launchpad.net/keystone/+spec/token-scoped-endpoint">https://blueprints.launchpad.net/keystone/+spec/token-scoped-endpoint</a><br></div><div><br></div><div style>The way centralized policies are consumed by other services will be tied closely into the above conversations & questions. I'm certainly not opposed to name policies that can be consumed by services simply by name; I think that's a perfectly simple solution. However, we also need to consider domain-owned policies and the impact of domain-specific namespacing).</div>
<div style><br></div><div style>> JSON policies of my own</div><div style><br></div><div style>For OpenStack services or non-OpenStack services?</div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 11:49 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) <span dir="ltr"><<a href="mailto:mark.m.miller@hp.com" target="_blank">mark.m.miller@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="">Hello,<u></u><u></u></p>
<p class=""><u></u> <u></u></p>
<p class="">I have been testing  the new Policy APIs and looking at the policy table in the Keystone database.  When I consider the OpenStack services including Keystone, I find that they all use a policy.json file stored on the file system. So my
 question is how is this new Keystone policy feature envisioned to be used? I was thinking of using it to store JSON policies of my own, but the only way to GET a policy file is via the UUID which means that I have to store it somewhere and keep track of it.
 Was there a reason a human readable tag like “policyName” was not included in this new feature?<u></u><u></u></p>
<p class=""><u></u> <u></u></p>
<p class="">Regards,<span class=""><font color="#888888"><u></u><u></u></font></span></p><span class=""><font color="#888888">
<p class=""><u></u> <u></u></p>
<p class="">Mark Miller<u></u><u></u></p>
</font></span></div>
</div>

<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div></div></div>