[openstack-dev] [keystone] domain admin role query

Dolph Mathews dolph.mathews at gmail.com
Thu Dec 12 17:25:18 UTC 2013


On Thu, Dec 12, 2013 at 8:50 AM, Adam Young <ayoung at 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.mathews at 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 <jamielennox at 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" <ravivsn at gmail.com>
>>>> To: "OpenStack Development Mailing List" <openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/948e73cf/attachment.html>


More information about the OpenStack-dev mailing list