Open Stack

Hi Henry

so why dont we start by discussing/listing/recording the limitations in 
the current RBAC system as a first step.

Here is my initial list which I am sure you can supplement.
BTW, is there a wiki page where we could create a standing document 
listing these limitations, so that they can be ticked off once solutions 
have been implemented (or added to when new ones are discovered?)

1. Roles have to be global and cannot be locally created by a cloud service
2. Roles only comprise a value, whereas in general you need type/value 
pairs for authorisation (sometimes this is called parameterised roles in 
the literature).
3. The current system limits the user to having to be a particular 
tenant, so this cannot be called a "pure" RBAC system, since more than 
roles control access.
4. There is no role-mapping capability which is needed for scalability, 
flexibility and federation. This is referred to in the literature as 
separating organisation roles from workflow roles
5. The current system does not support delegation of authority whereby a 
role holder can delegate a role to another user.

That's an initial first draft

regards

David


On 22/11/2012 18:07, Henry Nash wrote:
> Hi David,
>
> So on the idea of using suffix/prefixes for user and domain names to remove the need to add a parameter to the API - I did think about that for a while.  Since it is only the one API (the authentication by username/password) that requires the parameter and that there is no equivalent of "local site login" as in your example, I am not sure the concatenation of the strings buys us much.  I also thought about a system when the domain name is automatically added/stripped from user/project names - but in the end this seems fraught with the usual problems that such schemes have.  I think it is also important that we are clear about can and cannot be used as a unique tag by the users of keystone.
>
> On your more general comment on a wider discussion on RBAC & ABAC should be used, I think that is a good idea.  I think we need to discuss a few things, e.g.:
>
> 1) We have RBAC now, similar to many such systems.  How much more extensible do we need to make it?
> 2) Is ABAC our eventual destination?  I actually think it should be.  But what does that mean?  a) As a replacement for RBAC (i.e. since you should be able to implement any RBAC scheme within a broader ABAC implementation).  Or b) is it to stand alongside RBAC (i.e. a cloud provider could chose which they use)?  If we were designing from a clean sheet of paper, then a) might be the obvious answer - but of course we're not.  It might still be the right path, but we'd have to handle the migration very carefully and as well as really understand what happens to the existing APIs.
>
> I think 2) will take some serious discussion - but I'm all for it.  However, we can't ignore 1).  There are restrictions today in our RBAC that will prevent enterprises using Openstack OTB (Out of The Box), some listed in these blueprints as well as others like the one on "groups of users".  I think we need to keep pushing such improvements forward (we all want market share for Openstack), while keeping an eye to make sure we can sensibly represent them in ABAC form in the future.  A good example is indeed that  groups of users blueprint (https://blueprints.launchpad.net/keystone/+spec/user-groups).  This is really about allowing the creation of local (i.e. to the domain) organizational role/attributes (I happen to call it a group) that can be mapped to global roles (since that's all we support today as roles are shared secrets between services and keystone).
>
> Henry
>
> On 22 Nov 2012, at 13:00, David Chadwick wrote:
>
>> 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
>>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>