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
