On Tue, Nov 10, 2015 at 10:53:46AM -0500, Adam Young wrote: > On 11/10/2015 05:08 AM, Henry Nash wrote: > >Steve, > > > >Currently, your best option is to use something similar to the > >policy.v3cloudsample.json, where you basically “bless” a project (or domain) > >as being the “cloud admin project/domain”. Having a role on that gives you > >super-powers. The only trouble with this right now is that you have to > >paste the ID of your blessed project/domain into the policy file (you only > >have to do that once, of course) - basically you replace the > >“admin_domain_id” with the ID of your blessed project/domain. > > > >What we are considering for Mitaka is make this a bit more friendly, so you > >don’t have to modify the policy file - rather you define your “blessed > >project” in your config file, and tokens that are issue on this blessed > >project will have an extra attribute (e.g. “is_admin_project”), which your > >policy file can check for. > > Henry is using a bitof the British tendency toward understatement here. Let > me make this more explicit: > > We are going to add a value to the Keystone token validation response that > will indicate that the proejct is an admin project. Use that. Don't develop > something for Mitaka that does not use that.
Henry and Adam, many thanks for the information. I'll follow the spec referenced by Adam and hopefully we can look to make use of the new scheme when it's implemented - happy to help out with some testing when you think it's ready for us to try. Thanks! Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
