Open Stack

On 12/09/2013 03:04 PM, David Chadwick wrote:
>
> 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

Hat is my understanding, yes, and I think that your proposal covers 
that.  A role name for policy will be the full name, for example 
"domain/project/role" in the 3 portion version you posted.

>
>>
>>
>>
>>> 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.chadwick at 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.mathews at 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:ayoung at 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.mathews at 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.chadwick at kent.ac.uk]
>>>>>> Sent: Monday, November 25, 2013 12:12 PM
>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List
>>>>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at 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 at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev