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.
A name attribute was simply not included because it's not applicable to the current policy.json approach. 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): https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation https://blueprints.launchpad.net/keystone/+spec/token-scoped-endpoint 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). > JSON policies of my own For OpenStack services or non-OpenStack services? -Dolph On Fri, Mar 8, 2013 at 11:49 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) <mark.m.mil...@hp.com> wrote: > Hello,**** > > ** ** > > 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? > **** > > ** ** > > Regards,**** > > ** ** > > Mark Miller**** > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
