Open Stack

On 12/04/2013 04:08 AM, David Chadwick wrote:
> I am happy with this as far as it goes. I would like to see it being
> made more general, where domains, services and projects can also own and
> name roles
Domains should be OK, but services would confuse the matter.  You'd have 
to end up with something like LDAP

role=  domain=default,service=glance

vs

role=  domain=default,project=glance

unless we have unambiguous implicit ordering, we'll need to make it 
explicit, which is messy.

I'd rather do:

One segment: globally defined roles.  These could also be considered 
roles defined in the default domain.
Two segments service defined roles in the default domain
Three Segments, service defined roles from non-default domain

To do domain scoped roles we could do something like:

domX//admin


But It seems confusing.

Perhaps a better approach for project roles is to have the rule that the 
default domain can show up as an empty string.  Thus, project scoped 
roles from the default domain  would be:

\glance\admin

and from a non default domain

domX\glance\admin







>
> regards
>
> David
>
>
> On 04/12/2013 01:51, Adam Young wrote:
>> I've been thinking about your comment that "nested roles are confusing"
>>
>>
>> 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.
>>
>>
>>
>> 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?
>>
>>
>>
>> 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