Open Stack

Hi Adam

at one conceptual level they are all the same, in that they are all user 
attributes. But at another conceptual level they are quite different, 
and this is whether permissions are attached to them or not by cloud 
service providers. Currently groups are not known by CSPs and users do 
not gain any privileges by being a member of a group. They only inherit 
a privilege when the group is mapped to a role (which does have 
privileges assigned to it by policy rules).

In some research papers this is referred to as organisational roles and 
workflow roles, and they should be kept separate for very good reasons 
(which I can enumerate later if you wish). The later have privileges, 
the former only get them by either role mapping or CSPs becoming aware 
of them and adding privileges to them. Groups were added precisely 
because they were organisational roles and required different workflow 
roles and privileges for different cloud services.

What we should be trying to avoid doing is creating all these new tables 
for new types of attribute as it creates a lot of extra work. On my 
reckoning you have doubled the number of special tables for these 
attributes between v2 and v3 as you have gone from tenants and roles in 
V2, to project, groups, domains and roles in V3. This is clearly 
unsustainable as a way forward, when other types of attributes can 
already be envisaged (e.g. location for location based services, age for 
age related services etc.)

So I agree that you should try to have one type of table, say called 
attribute, but with slightly different columns to what you are proposing 
(might I add that this is what we have already done in our attribute 
mapping APIs). The columns I suggest are

Table name = Attribute
id: the unique primary key
Attribute name: (user friendly name e.g. role, domain, etc.)
Attribute Ref: (global id of attribute such as OID or URL, as used by 
SAML and LDAP)
Attribute value: (the value of the attribute e.g. Admin)
Type: (workflow or organisational)

In addition you could have an optional description if you think it is 
necessary and an enabled boolean if for some reason you want to 
deactivate an attribute

I dont see why you need a parent unless you are going to support 
attribute hierarchies. Or maybe it is linked to the local naming of the 
attributes?

On 23/01/2013 19:31, Adam Young wrote:
> As I try and rework "roles mean membership"
> https://review.openstack.org/#/c/20278/  I am struct by the fact that
> the grants calls all are common regardless of whether they are group to
> user, group to domain, or what not.
>
> It seems to me that we could take this abstraction further, and make
> groups, domains, and projects all a single SQL entity called a
> collection, and put it into a single table.  Then, role assignments are
> associations between collections.  Each user would get an entry in the
> collections table as well.
>
> The table would basically be the projects table outline:
>
>      __tablename__ = 'collection'
attribute in my proposal

>      id = sql.Column(sql.String(64), primary_key=True)
same

>      parent_id = sql.Column(sql.String(64),
> sql.ForeignKey('collection.id'), nullable=False )
>      name = sql.Column(sql.String(64), unique=True, nullable=False)
I think this is attribute value in my proposal. There is no need for 
this to by unique. ONly the name/value pair need be unique

>      description = sql.Column(sql.Text())
should be optional

>      enabled = sql.Column(sql.Boolean)
should be optional

>      power_type = sql.Column(sql.Int)  #use ENUM type if all RDBMS
> support it
this is attribute name in my proposal

regards

David


>
> power_type would be 0=user, 1=project,2=domain,3=group
>
> The user  table will still remain.  Think of the groups of type = 0 as
> groups as done in /etc/groups.
>
> I would actually prefer to call this the 'group' table instead of the
> collection table, if we can somehow deconflict the term with the way
> that keystone is presently using group.  I think  "rolegroup" is a
> better term.
>
> This will allow us to come up with other collection types in the future
> without having to write a whole new set of tables. It should reduce
> duplicated code.
>
> Domains will have a null parent_id. Users,  (role)groups, and projects
> will have a domain as their parent.
>
> I don't think this will impact the LDAP backend, except to reinforce
> that the groupings should all be done as groupOfNames.
>
>
> I think this work can be done under the umbrella of 20278
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev