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
