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@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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
