Open Stack

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.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
>