Open Stack

Hi David,

The biggest problems in my opinion are, 

1. We are overloading and adding extra complexities on role name to maintain the generalization for role-def data model. 
2. Name spacing the role name is not going to resolve all the issues listed in BP.
3. All the namespaces are derived from mutable string  (domain name, project name, service name etc...) which makes the role name fragile.

I think it is time to break generic role-def data model to accommodate more specialized use cases.


Thanks,
Arvind

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] 
Sent: Wednesday, December 04, 2013 10:41 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)
Cc: Henry Nash; dolph.mathews at gmail.com
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

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?

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
>