<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 9, 2018 at 2:42 AM, Adrian Turjak <span dir="ltr"><<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sooo to follow up from the discussion last night partly with Lance and<br>
Adam, I'm still not exactly sure what difference, if any, there is<br>
between a domain scoped role assignment, and a project scoped role<br>
assignment. And... It appears stuff breaks when you used both, or either<br>
actually (more on that further down).<br>
<br>
My problem/confusion was why the following exists or is possible:<br>
<a href="http://paste.openstack.org/show/695978/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/695978/</a><br>
The amusing part, I now can't remove the above role assignments. They<br>
throw a 500:<br>
<a href="http://paste.openstack.org/show/696013/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/696013/</a><br>
The error itself being:<br>
<a href="http://paste.openstack.org/show/695994/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/695994/</a></blockquote><div><br><br><br><br></div><div>This is a bug. It looks like the one() assumes there is only every one record that comes back that matches, and this matches multiple. <br><br></div><div>A 500 is never appropriate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Then lets look at just project scope:<br>
<a href="http://paste.openstack.org/show/696007/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/696007/</a><br>
I can't seem to do 'include_names' on the project scoped role<br>
assignment, but effective works since it doesn't include the project. I<br>
have a feeling the error is because keystone isn't including projects<br>
with is_domain when doing the names mapping.<br></blockquote><div><br></div><div>Probably correct. Bug on this, too.<br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So... going a little further, does domain scope still act like project<br>
scope in regards to effective roles:<br>
<a href="http://paste.openstack.org/show/695992/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/695992/</a><br>
The answer is yes. But again, this is domain scope, not project scope<br>
which still results in project scope down the tree. Although here<br>
'include_names' works, this time because keystone internally is directly<br>
checking for is_domain I assume.<br></blockquote><div><br></div><div>Interesting. That might have been a "works as designed" with the idea that assigning a role on a domain that is inherited is used by anything underneath it. It actually makes sense, as domains can't nest, so this may be intentional syntactic sugar on top of the format I used:<br><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also worth mentioning that the following works (and maybe shouldn't?):<br>
<a href="http://paste.openstack.org/show/696006/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/696006/</a><br>
Alice has a role on a 'project' that isn't part of her domain. I can't<br>
add her to a project that isn't in her domain... but I can add her to<br>
another domain? That surely isn't expected behavior...<br>
<br></blockquote><div>That is a typo. You added an additional character at the end of the ID:<br><br><pre>86a8b3dc1b8844fd8c2af8dd50cc21386</pre><pre>86a8b3dc1b8844fd8c2af8dd50cc2138</pre></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Weird broken stuff aside, I'm still not seeing a difference between<br>
domain/project role assignment scope on a project that is a domain. Is<br>
there a difference that I'm missing, and where is such a difference used?<br>
<br>
Looking at the blog post Adam linked<br>
(<a href="https://adam.younglogic.com/2018/02/openstack-hmt-cloudforms/" rel="noreferrer" target="_blank">https://adam.younglogic.com/<wbr>2018/02/openstack-hmt-<wbr>cloudforms/</a>), he<br>
isn't really making use of domain scope, just project scope on a<br>
domain, and inheritance down the tree, which is indeed a valid and<br>
useful case, but again, not domain scope assignment. Although domain<br>
scope on the same project would probably (as we see above) achieve the<br>
same result.<br>
<br>
Then looking at the policy he linked:<br>
<a href="http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n52" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/keystone/tree/etc/<wbr>policy.v3cloudsample.json#n52</a><br>
"identity:list_projects": "rule:cloud_admin or<br>
rule:admin_and_matching_<wbr>domain_id",<br>
- "cloud_admin": "role:admin and (is_admin_project:True or<br>
domain_id:admin_domain_id)",<br>
- "admin_and_matching_domain_id"<wbr>: "rule:admin_required and<br>
domain_id:%(domain_id)s",<br>
- "admin_required": "role:admin",<br>
<br>
I can't exactly see how it also uses domain scope. It still seems to be<br>
project scope focused.<br>
<br></blockquote><div>It is subtle. domain_id:admin_domain_id Means that the token has a domain_id, which means it is a domain scoped token.<br><br><br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So my question then is why on the role assignment object do we<br>
distinguish between a domain/project when it comes to scope when a<br>
domain IS a project, and clearly things break when you set both.<br>
<br>
Can we make it so the following works (a hypothetical example):<br>
<a href="http://paste.openstack.org/show/696010/" rel="noreferrer" target="_blank">http://paste.openstack.org/<wbr>show/696010/</a><br>
At which point the whole idea of 'domain' scope on a role assignment<br>
goes away since and is exactly the same thing as project scope, and also<br>
the potential database 500 issues goes away since... there isn't more<br>
than 1 row. We can then start phasing out the domain scope stuff and<br>
hiding it away unless someone is explicitly still looking for it.<br>
<br>
Because in reality, right now I think we only have project scope, and<br>
system scope. Domain scope == project scope and we should probably make<br>
that clear because obviously the code base is confused on that matter. :P<br></blockquote><div><br><br></div><div>I'd love it if Domains went away and we only had projects. We'd have to find a way to implement such that people using domains today don't get broken.<br></div><div>We could also add a 3 value toggle on the inheritance: none, children_only, both to get it down to a single entry.that would be an implementation detail that the end users would not see.<br><br><br></div><div>The one potential benefit to domain ,which is not used today, is to say: this applies to all of the projects inside this domain. Each project knows both its parent and its domain, so it is a way to jump levels of the tree.<br></div><div><br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>