Re: [openstack-dev] [keystone] design summit outcomes
On 11/14/2013 10:03 AM, Steven Hardy wrote: On Wed, Nov 13, 2013 at 10:04:04AM -0600, 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 Looks good, but I have some feedback on items which were discussed (either in the delegation session or in the hallway with ayoung/jlennox), and are high priority for Heat, I don't see these captured in the page above: Delegation: - Need a way to create a secret derived from a trust (natively, not via ec2tokens extension), and it needs to be configurable such that it won't expire, or has a very long expiry time. ayoung mentioned a credential mechanism, but I'm not sure which BP he was referring to, so clarification appreciated. I am not sure this is pointing the right direction. Trusts assume authentication from an separate source, like the token the trustee passes in when executing the trust. Long term credentials should be used in conjunction with a trust, but separate to it. I suspect that there is something that could be done with X509, Trusts, and Token Binding that would make sense here. Something like: 1. Identify client machine 2. Generate new Cert for Client machice (Key stays on client, gets signed by CA) 3. Generate trust, and link trust to new cert. 4. Client machine uses cert and trust to get tokens. Client: - We need a way to get the role-tenant pairs (not just the tenant-less role list) into the request context, so we can correctly scope API requests. I raised this bug: A token is scoped to something; project, domain, whatever. Providing tokens that are scoped wider is somewhat suspect. What you want to do is to query the data from Keystone using an unscoped token. But any token from a user sent back to Keystone (except a trust token) should be able to access this information. Put another way: you need to query the role information for additional requests to Keystone. A token is specifically for proving that you have access to the information to a third party. Since anything that is going to be done with this information is going to be validated by Keystone, it is OK to do it as a query against Keystone itself. So, I think what you want is a way to query all roles for a user on all projects in all domains. This can be done taody doing individual calls (enumerate domains, enumerat projects) which is chatty. If it proves to be a performance bottleneck, we can optimize it into a single call. https://bugs.launchpad.net/python-keystoneclient/+bug/1250982 Related to this thread (reminder - which you said you'd respond to ;): http://lists.openstack.org/pipermail/openstack-dev/2013-November/018201.html This topic came up again today related to tenant-scoped nova flavors: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html Closely related to this bug I think: https://bugs.launchpad.net/keystone/+bug/968696 I'd welcome discussion on how we solve the request-scoping issue openstack-wide, currently I'm thinking we need the role-tenant pairs (and probably role-domain pairs) in the request context, so we can correctly filter in the model_query when querying the DB while servicing the API request. Thanks, Steve ___ 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
Re: [openstack-dev] [keystone] design summit outcomes
On Wed, Nov 13, 2013 at 10:04:04AM -0600, 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 Looks good, but I have some feedback on items which were discussed (either in the delegation session or in the hallway with ayoung/jlennox), and are high priority for Heat, I don't see these captured in the page above: Delegation: - Need a way to create a secret derived from a trust (natively, not via ec2tokens extension), and it needs to be configurable such that it won't expire, or has a very long expiry time. ayoung mentioned a credential mechanism, but I'm not sure which BP he was referring to, so clarification appreciated. Client: - We need a way to get the role-tenant pairs (not just the tenant-less role list) into the request context, so we can correctly scope API requests. I raised this bug: https://bugs.launchpad.net/python-keystoneclient/+bug/1250982 Related to this thread (reminder - which you said you'd respond to ;): http://lists.openstack.org/pipermail/openstack-dev/2013-November/018201.html This topic came up again today related to tenant-scoped nova flavors: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html Closely related to this bug I think: https://bugs.launchpad.net/keystone/+bug/968696 I'd welcome discussion on how we solve the request-scoping issue openstack-wide, currently I'm thinking we need the role-tenant pairs (and probably role-domain pairs) in the request context, so we can correctly filter in the model_query when querying the DB while servicing the API request. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] design summit outcomes
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 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] design summit outcomes
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 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
Re: [openstack-dev] [keystone] design summit outcomes
On Wed, Nov 13, 2013 at 11:00 AM, David Chadwick 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@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 > -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] design summit outcomes
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
