<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi<div class=""><br class=""></div><div class="">At the design summit we have had a number of discussions on how to complete the reseller functionality (original spec: <a href="https://review.openstack.org/#/c/139824" class="">https://review.openstack.org/#/c/139824</a>). We all agreed that we should split the implementation into:</div><div class=""><br class=""></div><div class="">1) Refactor the way domains are stored, so that they are actually projects with the “is_domain” attribute. At the end of this phase, all top level projects would be acting as domains. The domain API is not removed, but references the appropriate project.</div><div class=""><br class=""></div><div class="">2) Investigate alternatives to the original proposal of using nested projects acting as a domain to model the reseller use case. One proposed alternative was to try and use federated mapping to provide isolation between customers within a reseller.</div><div class=""><br class=""></div><div class="">The second part of this has undergone some intensive analysis over the last few days - here’s a summary of what we looked at:</div><div class=""><br class=""></div><div class="">This alternative proposal was intended to work like this;</div><div class=""><br class=""></div><div class="">1) The Cloud provider would create a domain for the reseller.</div><div class="">2) The reseller would on-board their customers by creating IdPs and the mapping rules, that would land a given customer’s users into a customer specific project or tree of projects, within the reseller's domain</div><div class=""><br class=""></div><div class="">A number of issues come out of this:</div><div class=""><br class=""></div><div class="">a) Most serious, is how we provide sufficient isolation between the customers - the key being ensuing that admin actions that a customer needs to carry out can be protected by generic policy files rules that would be written by the cloud provider without any knowledge of the specific reseller and their customers. Things that immediately seem hard in this area:</div><div class="">- CRUD of customer specific roles (which would be the analogy of what we had been calling domain specific roles)</div><div class="">- CRUD of the mapping rules for the customers IdPs (i.e. a customer’s admin would want to be able to change what groups/assignments would be used against attributes in the IdP’s assertion)</div><div class="">One could imagine doing the above by having some kind of “special project” for each customer (although one could say that this is no different than that "special project” being a project with the “is_domain” flag!)</div><div class=""><br class=""></div><div class="">b) Today, at least, all project names within a domain must be unique - which would be overly restrictive in this case (since all customer projects of the reseller are in the same domain). So we’d need to move to the "project name must be unique within it’s parent” model - which we have discussed before (and solve the issues with referring to project by name etc.)</div><div class=""><br class=""></div><div class="">c) This solution really only works for one level of reseller (which would probably be OK for now, although is a concern for the future)</div><div class=""><br class=""></div><div class="">d) This solution only works if all a reseller's customers are ready to use a federated model, i.e. it won’t work if they want to use their corporate LDAP. With support of LDAP via the Apache plugin that would help - but I think the issue is more a customer operating model, rather than technically can you federate with their LDAP.</div><div class=""><br class=""></div><div class="">After discussing this with a few of the other cores (including Morgan), it was agreed that you really should use a domain per customer to ensure we have the correct isolation. But perhaps we could just create all the domains at the top level (i.e. avoiding the need for nested domains)? Analysis of this throws up some few additional issues:</div><div class=""><br class=""></div><div class="">- How is it that we maintain some kind of link/ownership/breadcrumb-trail from a customer domain back to their reseller? We might need this to, for instance, ensure that reseller A can only see their own customers' domains, and not those of reseller B. Interestingly, this linkage did exist in the solution when each customer had a special project in the reseller’s domain.</div><div class="">- At some point in the future, we probably won’t want the domain names to be all globally unique - rather you would want them unique within the reseller. Probably not an issue to start, but eventually this might become a problem. It’s not clear how you would provide such a restriction with the domain names at the top level. </div><div class=""><br class=""></div><div class="">It is possible we could somehow use role assignments to provide the above - but this seems tenuous at best. This leads us all the way back to the original proposal of nested projects acting as domains. This was designed to solve the problems above. However, i think there are a couple of reasons why this solution has seemed so complicated and concerning:</div><div class=""><br class=""></div><div class="">i) Trying to implement this in one go meant changing multiple concepts at once - doing this in two phases (as discussed) solves most of these issues.</div><div class="">ii) The original discussions on nested domains where all very general and theoretical. I don’t think it had been explained well enough, that the ONLY thing that was trying to be achieved with the nesting of projects acting as domains for reseller was the idea of ownership & segregation. We shouldn’t allow/attempt any of the other things that come with project hierarchies (e.g. inherited role assignments etc.). These restrictions were actually in the spec and the code, but were not, perhaps, made sufficiently clear. We really just want domains with back links (which is what the parent_id attribute in each of these domains gets us)!</div><div class="">iii) There is no additional API required to support this (other than removing the restriction that a project acting as a domain can’t have a parent)</div><div class=""><br class=""></div><div class="">Given all the above, I actually believe the original concept of nested projects acting as domains is the right one, with the following restrictions:</div><div class=""><br class=""></div><div class="">- The parent of a project acting as a domain is always another project acting as a domain (or if no parent, it’s a top level domain)</div><div class="">- projects acting as domains can’t receive inherited assignments</div><div class=""><br class=""></div><div class="">If it would help, I’d be happy to produce new specs that make the above clear.</div><div class=""><br class=""></div><div class="">Henry</div><div class=""><br class=""></div></body></html>