Open Stack

Hi Henry

I dont think the two proposals are incompatible. One table defines the 
attributes, similar to LDAP schema, whilst the other stores the actual 
assignments. I was talking about the former and you the latter in our 
emails. But we did discuss the former in the dev lounge as well

regards

david

On 13/11/2013 17:57, Henry Nash wrote:
> Hi David,
>
> I think that's the wrong table (remembering our conversation!)....the role assignment table(s) in keystone today is part of what you would call a mapper table, they don't define the attributes.  What I think we agreed was rather than taking one giant lead to the all-encompassing mapper table, we would:
>
> - refactor the current 4 tables into 1 that stored assignments (i.e. actor X, has attribute Y, on target z), where today:
>> actor can be user or group
>> attribute is a role
>> target can be project or domain
> - create a first version of the true  mapper table, who's sole job was to map IDP groups into something keystone understands (usually a keystone group, I would suggest)
>
> I think that's we decided......or is the memory fading already....
>
> Henry
> On 13 Nov 2013, at 17:00, 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?
>>
>> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>