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

Reply via email to