<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 8:50 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.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 class=""><div class="h5">On 12/11/2013 10:11 PM, Paul Belanger 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">
On 13-12-11 11:18 AM, Lyle, David 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">
+1 on moving the domain admin role rules to the default policy.json<br>
<br>
-David Lyle<br>
<br>
From: Dolph Mathews [mailto:<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.<u></u>com</a>]<br>
Sent: Wednesday, December 11, 2013 9:04 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [keystone] domain admin role query<br>
<br>
<br>
On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox <<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>> wrote:<br>
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.<br>
<br>
A better example of policies are in the file etc/policy.v3cloudsample.json. In there you will see the rule for create_project is:<br>
<br>
"identity:create_project": "rule:admin_required and domain_id:%(project.domain_id)<u></u>s",<br>
<br>
as opposed to (in policy.json):<br>
<br>
"identity:create_project": "rule:admin_required",<br>
<br>
This is what you are looking for to scope the admin role to a domain.<br>
<br>
We need to start moving the rules from policy.v3cloudsample.json to the default policy.json =)<br>
<br>
<br>
Jamie<br>
<br>
----- Original Message -----<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">
From: "Ravi Chunduru" <<a href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>><br>
To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>><br>
Sent: Wednesday, 11 December, 2013 11:23:15 AM<br>
Subject: [openstack-dev] [keystone] domain admin role query<br>
<br>
Hi,<br>
I am trying out Keystone V3 APIs and domains.<br>
I created an domain, created a project in that domain, created an user in<br>
that domain and project.<br>
Next, gave an admin role for that user in that domain.<br>
<br>
I am assuming that user is now admin to that domain.<br>
Now, I got a scoped token with that user, domain and project. With that<br>
token, I tried to create a new project in that domain. It worked.<br>
<br>
But, using the same token, I could also create a new project in a 'default'<br>
domain too. I expected it should throw authentication error. Is it a bug?<br>
<br>
Thanks,<br>
-- <br>
Ravi<br>
<br>
</blockquote></blockquote>
<br>
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.<br>
</blockquote></div></div>
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.<br>
<br>
open a bug for the problem, and describe what you did step by step?<div class="im"><br>
<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">
<br>
Any chance we can create a 2nd domain using 'admin_domain_id' via keystone-manage sync_db?<br></blockquote></div></blockquote><div><br></div><div>I totally forgot about this piece -- this is just another incarnation of this bug at the domain level which we should avoid furthering:</div>
<div><br></div><div> <a href="https://bugs.launchpad.net/keystone/+bug/968696">https://bugs.launchpad.net/keystone/+bug/968696</a></div><div><br></div><div>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).</div>
<div> </div><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 class="im"><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">
<br>
</blockquote>
<br>
<br></div><div class=""><div class="h5">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>