Open Stack

Hi

At the design summit we have had a number of discussions on how to complete the reseller functionality (original spec: https://review.openstack.org/#/c/139824 <https://review.openstack.org/#/c/139824>). We all agreed that we should split the implementation into:

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.

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.

The second part of this has undergone some intensive analysis over the last few days - here’s a summary of what we looked at:

This alternative proposal was intended to work like this;

1) The Cloud provider would create a domain for the reseller.
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

A number of issues come out of this:

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:
- CRUD of customer specific roles (which would be the analogy of what we had been calling domain specific roles)
- 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)
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!)

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.)

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)

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.

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:

- 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.
- 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. 

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:

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.
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)!
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)

Given all the above, I actually believe the original concept of nested projects acting as domains is the right one, with the following restrictions:

- 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)
- projects acting as domains can’t receive inherited assignments

If it would help, I’d be happy to produce new specs that make the above clear.

Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151030/ec745968/attachment.html>