All, I have captured almost all the email conversation (between Arvind, David and Adam) in the etherpad (line #54 - 126 ) and moved old conversation under line #130.
https://etherpad.openstack.org/p/service-scoped-role-definition In the beginning (line # 1 to 51), I have captured where we are right now and open questions along with my thoughts. Please take a look and share your comments/suggestion. Regards, Arvind -----Original Message----- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday, December 05, 2013 5:45 AM To: Tiwari, Arvind; Adam Young Cc: OpenStack Development Mailing List (not for usage questions); dolph.math...@gmail.com Subject: Re: [openstack-dev] [keystone] Service scoped role definition Almost, but not quite. The role name cannot be anything you like. It must be globally unique, and named hierarchically. There is a proposal in another message of this thread for what this could be, based on a 4 component naming scheme with / separators. regards david On 04/12/2013 19:42, Tiwari, Arvind wrote: > Thanks David, > > Appended line # 119 with my reply. "endpoint" sounds perfect to me. > > In a nutshell we are agreeing on following new data model for role-def. > > { > "role": { > "id": "76e72a", > "name": "admin", (you can give whatever name you like) > "scope": { > "id": "---id--", (ID should be 1 to 1 mapped with resource in type and > must be immutable value) > "type": "service | file | domain etc.", (Type can be any type of > resource which explains the scoping context) > "endpoint":"-- endpoint--" (An optional field to indicate the > interface of the resource (endpoint for service, path for File,....) for > which the role-def is created.) > } > } > } > > If other community members are cool with this, I will start drafting the API > specs? > > > Regards, > Arvind > > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] > Sent: Wednesday, December 04, 2013 11:42 AM > To: Tiwari, Arvind; Adam Young > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [keystone] Service scoped role definition > > > > On 04/12/2013 17:28, Tiwari, Arvind wrote: >> Hi David, >> >> Thanks for your valuable comments. >> >> I have updated >> https://etherpad.openstack.org/p/service-scoped-role-definition line >> #118 explaining the rationale behind the field. > > #119 for my reply > >> >> I wd also appreciate your thoughts on >> https://etherpad.openstack.org/p/1Uiwcbfpxq too, > > I have added a comment to the original bug report - > https://bugs.launchpad.net/keystone/+bug/968696 > > I think you should be going for simplifying Keystone's RBAC model rather > than making it more complex. In essence this would mean that assigning > permissions to roles and users to roles are separate and independent > processes and that roles on creation do not have to have any baggage or > restrictions tied to them. Here are my suggestions: > > 1. Allow different entities to create roles, and use hierarchical role > naming to maintain global uniqueness and to show which entity created > (owns) the role definition. Creating a role does not imply anything > about a role's subsequent permissions unless a scope field is included > in the definition. > > 2. When a role is created allow the creator to optionally add a scope > field which will limit the permissions that can be assigned to the role > to the prescribed scope. > > 3. Permissions will be assigned to roles in policy files by resource > owners. The can assign any permissions to their resources to the role > that they want to, except that they cannot override the scope field (ie. > grant permissions to resources which are out of the role's scope). > > 4. Remove any linkage of roles to tenants/projects on creation. This is > unnecessary baggage and only complicates the model for no good > functional reason. > > regards > > David > > > which is support >> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens >> BP. >> >> >> Thanks, Arvind >> >> -----Original Message----- From: David Chadwick >> [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013 >> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not >> for usage questions); Adam Young Subject: Re: [openstack-dev] >> [keystone] Service scoped role definition >> >> I have added comments 111 to 122 >> >> david >> >> On 03/12/2013 23:58, Tiwari, Arvind wrote: >>> Hi David, >>> >>> I have added my comments underneath line # 97 till line #110, it is >>> mostly aligned with your proposal with some modification. >>> >>> https://etherpad.openstack.org/p/service-scoped-role-definition >>> >>> >>> Thanks for your time, Arvind >>> >>> >>> >>> -----Original Message----- From: Tiwari, Arvind Sent: Monday, >>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development >>> Mailing List (not for usage questions); David Chadwick Subject: Re: >>> [openstack-dev] [keystone] Service scoped role definition >>> >>> Hi Adam and David, >>> >>> Thank you so much for all the great comments, seems we are making >>> good progress. >>> >>> I have replied to your comments and also added some to support my >>> proposal >>> >>> https://etherpad.openstack.org/p/service-scoped-role-definition >>> >>> David, I like your suggestion for role-def scoping which can fit in >>> my Plan B and I think Adam is cool with plan B. >>> >>> Please let me know if David's proposal for role-def scoping is cool >>> for everybody? >>> >>> >>> Thanks, Arvind >>> >>> -----Original Message----- From: Adam Young >>> [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44 >>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for >>> usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David >>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped >>> role definition >>> >>> >>> >>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote: >>>> Hi Adam, >>>> >>>> Based on our discussion over IRC, I have updated the below >>>> etherpad with proposal for nested role definition >>> >>> Updated. I made my changes Green. It isn't easy being green. >>> >>>> >>>> https://etherpad.openstack.org/p/service-scoped-role-definition >>>> >>>> Please take a look @ "Proposal (Ayoung) - Nested role >>>> definitions", I am sorry if I could not catch your idea. >>>> >>>> Feel free to update the etherpad. >>>> >>>> Regards, Arvind >>>> >>>> >>>> -----Original Message----- From: Tiwari, Arvind Sent: Tuesday, >>>> November 26, 2013 4:08 PM To: David Chadwick; OpenStack >>>> Development Mailing List Subject: Re: [openstack-dev] [keystone] >>>> Service scoped role definition >>>> >>>> Hi David, >>>> >>>> Thanks for your time and valuable comments. I have replied to >>>> your comments and try to explain why I am advocating to this BP. >>>> >>>> Let me know your thoughts, please feel free to update below >>>> etherpad >>>> https://etherpad.openstack.org/p/service-scoped-role-definition >>>> >>>> Thanks again, Arvind >>>> >>>> -----Original Message----- From: David Chadwick >>>> [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 >>>> 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List >>>> Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, >>>> Guang Subject: Re: [openstack-dev] [keystone] Service scoped role >>>> definition >>>> >>>> Hi Arvind >>>> >>>> I have just added some comments to your blueprint page >>>> >>>> regards >>>> >>>> David >>>> >>>> >>>> On 19/11/2013 00:01, Tiwari, Arvind wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Based on our discussion in design summit , I have redone the >>>>> service_id binding with roles BP >>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>. >>>>> >>>>> > I have added a new BP (link below) along with detailed use case to >>>>> support this BP. >>>>> >>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition >>>>> >>>>> >>>>> > Below etherpad link has some proposals for Role REST representation and >>>>> pros and cons analysis >>>>> >>>>> >>>>> >>>>> https://etherpad.openstack.org/p/service-scoped-role-definition >>>>> >>>>> >>>>> >>>>> >>>>> Please take look and let me know your thoughts. >>>>> >>>>> >>>>> >>>>> It would be awesome if we can discuss it in tomorrow's >>>>> meeting. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Arvind >>>>> >>>> _______________________________________________ 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