Open Stack

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