Open Stack

It seems to me that rather than asking for piecemeal extensions to the
current RBAC model, such as the addition of groups, domains, scoping 
etc. we first need a model of the access control system that we want to 
implement (eventually). Without a comprehensive access control model we 
will simply end up patching bits of spaghetti to the existing system 
until we will end with an unspecified model and/or a system that no-one 
really understands, which will lead to access control "holes" through 
which attackers can easily penetrate (and which might be difficult to 
fix). So I would call first and foremost for a comprehensive access 
control model to be documented in a blueprint before any further 
"enhancements" are made to the code base - regardless of the perceived 
urgency of each enhancement. It is critically important for a security 
system, that people (especially administrators) can understand it, so 
that they can manage it effectively. The more bolt ons and add ons that 
are made without a clear description of what the overall model is, the 
more difficult it will be for administrators to correctly administer.

regards

David

On 29/11/2012 08:21, Henry Nash wrote:
> Hi
>
> One of the requests from the summit was for allowing the scoping of a
> token to multiple projects, and this is being worked on for Grizzly.
> However, I would like us to re-visit (or maybe just re-clarify) this
> requirement - whilst also considering the option of scoping to a
> domain (see blueprint at :
> https://blueprints.launchpad.net/keystone/+spec/domain-scoping).
>
> Now the whole point of scoping to anything, is to make it possible
> (and in some cases easier) to execute operations on the granularity
> that you have "scoped to". It seems to me that now we have a domain
> as the logical container for users and projects, clearly one of the
> common usages will be operations that want to look at all the
> projects (or some aspect of projects) in a domain - hence the idea of
> scoping to a domain.  This would provide a somewhat simpler, both
> request & response, than an appropriately scoped token than an
> arbitrary list of projects (where you end up returning a nested set
> of projects and their domains in the response, for example).
> Further, if we had this, would we really need the ability to scope to
> multiple projects from different domains (which is technically the
> request on the table right now)?  Remember, scoping is defining the
> access rights - just allowing a suitable granularity of scope for
> upcoming operations - so you only really need a complex scope if the
> you have some operation that needs to carried out across that complex
> set of objects.  Are there such a set of operations that people have
> in mind?
>
> I raise this so that we just look at whether there is some
> simplification to the expansion of ability to scoping, before we go
> too far.
>
> Henry
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>