Open Stack

On 11/18/2015 08:42 AM, Raildo Mascena wrote:
>
> ii) Our restriction of “all domain names must be unique” means that 
> one reseller could “squat” on a domain name and prevent anyone else 
> from having a domain of that name.
> This is absolutely true. In reality, however, reseller arrangements 
> will be contractual, so if a cloud provider was really concerned about 
> this, they could legislate against this in the contract with the 
> reseller (e.g. "All the domains you create must be suffixed with your 
> reseller name”). In addition, if we believe that federation will 
> become the dominant auth model, then the physical name of the domain 
> becomes less important.
This is the crux of the matter, and I think the case where we have to 
address things.

If all customers are in a domain called "customers" and under there we 
crete a domain called "IBM" and then the IBM admins create a domain 
named "HP" they have effectively blocked HP from becoming client of our 
cloud.


The fact that a domain name is global and in a flat namespace means that 
we cannot enforce it using the scoped RBAC model.  To put it another 
way,  when a user using a role scoped to a parent domain cretes a child 
domain in a flat namespace, information leaks out of the scope, and 
effectively breaks scoped RBAC.

HTTP solves this very elegantly, and I think we should follow suite.  If 
every domain name in a Keystone server can be represented with a unique, 
nestable URL, we can maintain the scope without polluting the global 
namespace.

if all customers go into the "customer" domain, then IBM is is 
"customer/IBM" and if they create a domain underneath them called HP, we 
can happily take HP's money and give them customer/HP, because the IBM 
domain gets named customers/IBM/HP.

The thing keeping us from implementing this today is the fact that 
domain names can be any string.  If we provide a config option, say 
domain_strict_url, then we can enforce that only domains with names that 
don't have any of the reserved HTTP characters in them can be used as 
domain names.  If this value gets set, and a domain is named 
"adam at THISROCKS!?!?!?"  that domain would be disabled.  This would allow 
deployers to "opt in" to the approach, and to deal with any domains that 
were improperly named prior to enabling nested domains.

This same patterns can be extended to project names, but we could not 
mix and match domains and projects, unless we strictly enforce 
domain-is-a-project.