Ack On 09/12/2013 15:54, Tiwari, Arvind wrote: > Thanks David, > > Let me update the etherpad with this proposal. > > Arvind > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] > Sent: Friday, December 06, 2013 2:44 AM > To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for > usage questions) > Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang > Subject: Re: [openstack-dev] [keystone] Service scoped role definition > > Another alternative is to change role name into role display name, > indicating that the string is only to be used in GUIs, is not guaranteed > to be unique, is set by the role creator, can be any string in any > character set, and is not used by the system anywhere. Only role ID is > used by the system, in policy evaluation, in user-role assignments, in > permission-role assignments etc. > > regards > > David > > On 05/12/2013 16:21, Tiwari, Arvind wrote: >> Hi David, >> >> Let me capture these details in ether pad. I will drop an email after adding >> these details in etherpad. >> >> Thanks, >> Arvind >> >> -----Original Message----- >> From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] >> Sent: Thursday, December 05, 2013 4:15 AM >> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for >> usage questions) >> Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang >> Subject: Re: [openstack-dev] [keystone] Service scoped role definition >> >> Hi Arvind >> >> we are making good progress, but what I dont like about your proposal >> below is that the role name is not unique. There can be multiple roles >> with the same name, but different IDs, and different scopes. I dont like >> this, and I think it would be confusing to users/administrators. I think >> the role names should be different as well. This is not difficult to >> engineer if the names are hierarchically structured based on the name of >> the role creator. The creator might be owner of the resource that is >> being scoped, but it need not necessarily be. Assuming it was, then in >> your examples below we might have role names of NovaEast.admin and >> NovaWest.admin. Since these are strings, policies can be easily adapted >> to match on NovaWest.admin instead of admin. >> >> regards >> >> david >> >> On 04/12/2013 17:21, Tiwari, Arvind wrote: >>> Hi Adam, >>> >>> I have added my comments in line. >>> >>> As per my request yesterday and David's proposal, following role-def data >>> model is looks generic enough and seems innovative to accommodate future >>> extensions. >>> >>> { >>> "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) >>> "interface":"--interface--" (We are still need working on this >>> field. My idea of this optional field is to indicate the interface of the >>> resource (endpoint for service, path for File,....) for which the role-def >>> is created and can be empty.) >>> } >>> } >>> } >>> >>> Based on above data model two admin roles for nova for two separate region >>> wd be as below >>> >>> { >>> "role": { >>> "id": "76e71a", >>> "name": "admin", >>> "scope": { >>> "id": "110", (suppose 110 is Nova serviceId) >>> "interface": "1101", (suppose 1101 is Nova region East endpointId) >>> "type": "service" >>> } >>> } >>> } >>> >>> { >>> "role": { >>> "id": "76e72a", >>> "name": "admin", >>> "scope": { >>> "id": "110", >>> "interface": "1102",(suppose 1102 is Nova region West endpointId) >>> "type": "service" >>> } >>> } >>> } >>> >>> This way we can keep role-assignments abstracted from resource on which the >>> assignment is created. This also open doors to have service and/or endpoint >>> scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq. >>> >>> David, I have updated >>> https://etherpad.openstack.org/p/service-scoped-role-definition line #118 >>> explaining the rationale behind the field. >>> I wd also appreciate your vision on >>> https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support >>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP. >>> >>> >>> Thanks, >>> Arvind >>> >>> -----Original Message----- >>> From: Adam Young [mailto:ayo...@redhat.com] >>> Sent: Tuesday, December 03, 2013 6:52 PM >>> 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 >>> >>> I've been thinking about your comment that "nested roles are confusing" >>> AT: Thanks for considering my comment about nested role-def. >>> >>> What if we backed off and said the following: >>> >>> >>> "Some role-definitions are owned by services. If a Role definition is >>> owned by a service, in role assignment lists in tokens, those roles we >>> be prefixd by the service name. / is a reserved cahracter and weill be >>> used as the divider between segments of the role definition " >>> >>> That drops arbitrary nesting, and provides a reasonable namespace. Then >>> a role def would look like: >>> >>> "glance/admin" for the admin role on the glance project. >>> >>> AT: It seems this approach is not going to help, service rename would >>> impact all the role-def for a particular service. And we are back to the >>> same problem. >>> >>> In theory, we could add the domain to the namespace, but that seems >>> unwieldy. If we did, a role def would then look like this >>> >>> >>> "default/glance/admin" for the admin role on the glance project. >>> >>> Is that clearer than the nested roles? >>> AT: It is defiantly clearer but it will create same problems as what we are >>> trying to fix. >>> >>> >>> >>> 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 >>>> >>>> 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
