Open Stack

On 01/23/2013 03:14 PM, David Chadwick wrote:
> 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?

I am a little uncomfortable with limiting the term attribute to things 
that could be held in this table.  There are attributes of the user 
object that should be in the user table, and so forth.

I would agree that assign a user a role in some grouping, whether 
workflow or organizational, is an attribute assignment.  Selecting which 
attributes can be used for authorization purposes is part of what 
Keystone does, and the dominant attribute for authN is named roles.   I 
think this maps fairly cleanly to your attribute model.

Users, Groups and projects are owned by a domain.  This is an attribute 
hierarchy.  We just define it to be a very shallow one.



>
> 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