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



-- 

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