On 09/12/2013 19:37, Adam Young wrote: > On 12/06/2013 04:44 AM, David Chadwick wrote: >> 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. > > That will make policy much harder to read. I'd recommend that the role > name continue to be the "good" name, for both UI and for policy > enforcement.
in which case all role names must be unique David > > > > >> >> 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