Open Stack

On 12/04/2013 12:40 PM, David Chadwick wrote:
> Hi Adam
>
> I understand your problem: having projects and services which have the
> same name, then the lineage of a role containing this name is not
> deterministically known without some other rule or syntax that can
> differentiate between the two.
>
> Since domains contain projects which contain services then isnt the
> containment hierarchy already known and predetermined? If it is then:
>
> 4 name components mean it is a service specified role
> 3 name components mean it is a project specified role
> 2 name components mean it is a domain specified role
> 1 name component means it is globally named role (from the default domain)
>
> a null string means the default domain or all projects in a domain. You
> would never have null for a service name.
>
> admin means the global admin role
> /admin ditto
> x/admin means the admin of the X domain
> x/y/admin means the admin role for the y project in domain x
> //x/admin means admin for service x from the default domain
> etc.
>
> will that work?
Very clean.  Yes. That will work.

>
> regards
>
> David
>
>
> On 04/12/2013 15:04, Adam Young wrote:
>> 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