On Thu, Dec 12, 2013 at 8:50 AM, Adam Young <ayo...@redhat.com> wrote:
> On 12/11/2013 10:11 PM, Paul Belanger wrote: > >> On 13-12-11 11:18 AM, Lyle, David wrote: >> >>> +1 on moving the domain admin role rules to the default policy.json >>> >>> -David Lyle >>> >>> From: Dolph Mathews [mailto:dolph.math...@gmail.com] >>> Sent: Wednesday, December 11, 2013 9:04 AM >>> To: OpenStack Development Mailing List (not for usage questions) >>> Subject: Re: [openstack-dev] [keystone] domain admin role query >>> >>> >>> On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox <jamielen...@redhat.com> >>> wrote: >>> Using the default policies it will simply check for the admin role and >>> not care about the domain that admin is limited to. This is partially a >>> left over from the V2 api when there wasn't domains to worry > about. >>> >>> A better example of policies are in the file >>> etc/policy.v3cloudsample.json. In there you will see the rule for >>> create_project is: >>> >>> "identity:create_project": "rule:admin_required and >>> domain_id:%(project.domain_id)s", >>> >>> as opposed to (in policy.json): >>> >>> "identity:create_project": "rule:admin_required", >>> >>> This is what you are looking for to scope the admin role to a domain. >>> >>> We need to start moving the rules from policy.v3cloudsample.json to the >>> default policy.json =) >>> >>> >>> Jamie >>> >>> ----- Original Message ----- >>> >>>> From: "Ravi Chunduru" <ravi...@gmail.com> >>>> To: "OpenStack Development Mailing List" <openstack-dev@lists. >>>> openstack.org> >>>> Sent: Wednesday, 11 December, 2013 11:23:15 AM >>>> Subject: [openstack-dev] [keystone] domain admin role query >>>> >>>> Hi, >>>> I am trying out Keystone V3 APIs and domains. >>>> I created an domain, created a project in that domain, created an user >>>> in >>>> that domain and project. >>>> Next, gave an admin role for that user in that domain. >>>> >>>> I am assuming that user is now admin to that domain. >>>> Now, I got a scoped token with that user, domain and project. With that >>>> token, I tried to create a new project in that domain. It worked. >>>> >>>> But, using the same token, I could also create a new project in a >>>> 'default' >>>> domain too. I expected it should throw authentication error. Is it a >>>> bug? >>>> >>>> Thanks, >>>> -- >>>> Ravi >>>> >>>> >> One of the issues I had this week while using the >> policy.v3cloudsample.json was I had no easy way of creating a domain with >> the id of 'admin_domain_id'. I basically had to modify the SQL directly to >> do it. >> > You should not have to edit the SQL. You should be able, at a minimum, to > re-enable the ADMIN_TOKEN in the config file to create any object inside of > Keystone. > > open a bug for the problem, and describe what you did step by step? > > > >> Any chance we can create a 2nd domain using 'admin_domain_id' via >> keystone-manage sync_db? >> > I totally forgot about this piece -- this is just another incarnation of this bug at the domain level which we should avoid furthering: https://bugs.launchpad.net/keystone/+bug/968696 But, to answer your question: no. It's intended to be a placeholder in the policy file for an actual domain ID (modify the policy file, don't hack at the SQL backend). > >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev