Open Stack

On 01/23/2013 03:26 PM, David Chadwick wrote:
> 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
I've been using the term role_assignments.  A role_assignement is an 
attribute that resolves down to the link between a user an an 
organization.  There are role_assignemtns between groups and projects, 
but what we care about at policy time is how those role assignments 
resolve for the user in question.



>
> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev