[openstack-dev] [keystone] design summit outcomes

Dolph Mathews dolph.mathews at gmail.com
Wed Nov 13 18:07:47 UTC 2013

On Wed, Nov 13, 2013 at 11:00 AM, David Chadwick <d.w.chadwick at kent.ac.uk>wrote:

> Hi Dolph
> I have one comment concerning Refactoring:
> role assignment tables in SQL backend should be unified into a SQL table
> which lacks referential integrity
> I am not quite sure what this means, but I did suggest creating an
> attribute definition table that would include the definitions of all
> Keystone authz attributes such as role, domain, project as well as identity
> attributes such as location, group, email address etc. Definitions would
> include such things as: delegatable or not, for keystone authz or not (see
> below). Once this table has been defined, then all user role assignments
> can be collapsed into one table (no need for separate role, domain tables
> etc) with the assigned attribute pointing to the entry in the definition
> table.
> Was this what your bullet point was referring to, or was it something
> different?

I intended to leave the specific implementation details out of this
document (they're already captured in the relevant etherpad), but yes --
that would be an improvement on the current table that fits the one liner
in the gist. The additional features (such as "delegatable") would require
a subsequent discussion / change.

> Here is a strawman proposal
> 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)
> Type: (authz or identity)
> Delegatable: [Yes|No]
> Values: [string|integer|Boolean]
> Now when you assign a role, domain, location, email address or any other
> attribute to a user a single assignment table can be used such as:
> Table name: Attribute Assignment
> id: the unique primary key of this assignment
> UserID: id of user this attribute is assigned to
> AttributeID: id of attribute from above table
> Value: the value of the assigned attribute
> you dont need to change the existing APIs and procedure calls, as they can
> be re-written to access the new tables.
> regards
> David
> On 13/11/2013 16:04, Dolph Mathews wrote:
>> I guarantee there's a few things I'm forgetting, but this is my
>> collection of things we discussed at the summit and determined to be
>> good things to pursue during the icehouse timeframe. The contents
>> represent a high level mix of etherpad conclusions and hallway meetings.
>> https://gist.github.com/dolph/7366031
>> Corrections and amendments appreciated - thanks!
>> -Dolph
>> _______________________________________________
>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/d55d9843/attachment.html>

More information about the OpenStack-dev mailing list