Open Stack

Henry

Whilst I agree we have two concepts, my classification is different to 
yours.

1. Users are assigned various attributes (not granted as in current 
parlance)
2. Some attributes are assigned permissions and some are not (these 
assignments are done by CSPs in policy rules and not by Keystone) So 
some attributes are known to the CSPs and some are not.

The difference in concept is whether the user is assigned an attribute 
that has permissions or one that does not have permissions ie. 
organisational attributes or workflow attributes i.e. not known to the 
CSP or known to the CSP. This to my mind is the fundamental difference.

Currently groups are organisational attributes,
projects and roles are workflow attributes to V3
domains are unknown to V2 but are workflow to V3.
tenants and roles are workflow to V2.

I wish we could move away from the term grants because it is very 
misleading and does have the correct semantics

regards

David


On 23/01/2013 19:58, Henry Nash wrote:
> Adam,
>
> So first off, I think we need to a little careful in the into to this
> (for instance there is no such thing as a grant of a group to a user,
> which you imply), rather today we have two concepts:
>
> membership, of which examples are: - projects, users and groups are
> members of domains - user are members of groups - (as a hangover from
> previous versions) users can be members of tenants, but there is no
> explicit api interface for this anymore
>
> grants, of which examples are: - grant role X to user Y on project Z
> - grant role A to group B on domain C
>
> Now I can imagine some immediate collapsing of some f these, e.g.:
>
> a) You could have a single grant table that had role, actor, target
> as columns that could store all grants (since all IDs are unique) b)
> You could, as discussed, map the legacy user<->tenant membership into
> this same table with the role as "legacy_tenant_membership" or
> something
>
> Beyond that, I think we are in danger of trying de-normalise the
> relationship of various tables into one mega relationship which may
> cause more confusion than it gains.
>
> Just my 2cents
>
> Henry On 23 Jan 2013, at 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' id = sql.Column(sql.String(64),
>> primary_key=True) parent_id = sql.Column(sql.String(64),
>> sql.ForeignKey('collection.id'), nullable=False ) name =
>> sql.Column(sql.String(64), unique=True, nullable=False) description
>> = sql.Column(sql.Text()) enabled = sql.Column(sql.Boolean)
>> power_type = sql.Column(sql.Int)  #use ENUM type if all RDBMS
>> support it
>>
>> 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
>>
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>