[openstack-dev] [Keystone] Domains, Projects, and Groups are all collections
henryn at linux.vnet.ibm.com
Wed Jan 23 19:58:53 UTC 2013
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
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
More information about the OpenStack-dev