Open Stack

Hi Henry

On 21/11/2012 19:59, Henry Nash wrote:
> Hi
>
> I have been working, with others, on a set of blueprints (some already
> discussed on this list) that enhance the definition and use of domains
> to make Openstack more successful and acceptable to enterprise customers
> (both when being hosted by a openstack-based cloud provider as well as
> for private clouds).  I would welcome comments/suggestions:
>
> *Optional private name spaces for domains*.  The initial draft of this
> proposal has been discussed here before, but I have now added details of
> the proposed changes :
> https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces

I fully support your spec for domain-name-spaces from a conceptual 
perspective. It makes eminent sense. Concerning the implementation 
details, I am more agnostic. Have you considered for example, that 
usernames, projects etc. that have private names, could be simply 
converted into global names by prefixing them (or suffixing them) with 
the global domain name, without creating an extra "domain_name" 
parameter on the APIs. Would that work? Eduroam for example uses a 
similar scheme, by allowing local usernames to be used for 
authentication when you are logging in to the local site/domain, but you 
must use username at dns.name when logging in to a remote site (where 
dns.name is the DNS name of your domain).


>
> *Token scoping to a domain*.  More easily enabling the operation of
> domain-wide admin roles:
> https://blueprints.launchpad.net/keystone/+spec/domain-scoping

No comments on this spec for now

>
> *Domain role assignment.*  Providing more flexibility in terms of what
> the current functionality means to assign a role to a user-domain pair:
> https://blueprints.launchpad.net/keystone/+spec/domain-role-assignment

I would like to open up this whole discussion to "how is RBAC or ABAC to 
be used in general" ie. how are roles to be assigned, how are 
permissions to be granted etc. It seems that you are only addressing one 
small aspect of a much larger discussion in your current document.

One could consider for example that roles can have global or local 
names, just like usernames and projects can have in your first blueprint 
above. What follows from this would be

i) if a role has a globally unique name it can potentially give 
privileged access to all resources in all domains on all clouds (rather 
like the dollar gives me access to resources all over the world)

ii) if a role has a local name then it can only give privileged access 
to resources that are within the same name space as itself.

iii) a local role can be converted into a global role by prefixing it 
with the name of its name space

Another issue to consider is, why are users restricted to only accessing 
resources within their own tenant? This is a needless restriction, and 
will cause us problems when we come to delegation of authority. A user 
with a globally unique role should potentially have access to all 
resources in all tenants (subject to the policy of the cloud service 
provider).

Perhaps if we try to take a more global look at the current RBAC 
mechanism we can specify a less restrictive, conceptually simpler, ABAC 
scheme that is a superset of the current restrictive RBAC scheme. And 
then try to migrate towards this

regards

David

>
> Henry
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>