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