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