Open Stack

On 04/12/2013 17:28, Tiwari, Arvind wrote:
> Hi David,
> 
> Thanks for your valuable comments.
> 
> I have updated
> https://etherpad.openstack.org/p/service-scoped-role-definition line
> #118 explaining the rationale behind the field.

#119 for my reply

> 
> I wd also appreciate your thoughts on
> https://etherpad.openstack.org/p/1Uiwcbfpxq too,

I have added a comment to the original bug report -
https://bugs.launchpad.net/keystone/+bug/968696

I think you should be going for simplifying Keystone's RBAC model rather
than making it more complex. In essence this would mean that assigning
permissions to roles and users to roles are separate and independent
processes and that roles on creation do not have to have any baggage or
restrictions tied to them. Here are my suggestions:

1. Allow different entities to create roles, and use hierarchical role
naming to maintain global uniqueness and to show which entity created
(owns) the role definition. Creating a role does not imply anything
about a role's subsequent permissions unless a scope field is included
in the definition.

2. When a role is created allow the creator to optionally add a scope
field which will limit the permissions that can be assigned to the role
to the prescribed scope.

3. Permissions will be assigned to roles in policy files by resource
owners. The can assign any permissions to their resources to the role
that they want to, except that they cannot override the scope field (ie.
grant permissions to resources which are out of the role's scope).

4. Remove any linkage of roles to tenants/projects on creation. This is
unnecessary baggage and only complicates the model for no good
functional reason.

regards

David


 which is support
> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
> BP.
> 
> 
> Thanks, Arvind
> 
> -----Original Message----- From: David Chadwick
> [mailto:d.w.chadwick at kent.ac.uk] Sent: Wednesday, December 04, 2013
> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
> for usage questions); Adam Young Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> I have added comments 111 to 122
> 
> david
> 
> On 03/12/2013 23:58, Tiwari, Arvind wrote:
>> Hi David,
>> 
>> I have added my comments underneath line # 97 till line #110, it is
>> mostly aligned with your proposal with some modification.
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> 
>> Thanks for your time, Arvind
>> 
>> 
>> 
>> -----Original Message----- From: Tiwari, Arvind Sent: Monday,
>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development
>> Mailing List (not for usage questions); David Chadwick Subject: Re:
>> [openstack-dev] [keystone] Service scoped role definition
>> 
>> Hi Adam and David,
>> 
>> Thank you so much for all the great comments, seems we are making
>> good progress.
>> 
>> I have replied to your comments and also added some to support my
>> proposal
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> David, I like your suggestion for role-def scoping which can fit in
>> my Plan B and I think Adam is cool with plan B.
>> 
>> Please let me know if David's proposal for role-def scoping is cool
>> for everybody?
>> 
>> 
>> Thanks, Arvind
>> 
>> -----Original Message----- From: Adam Young
>> [mailto:ayoung at redhat.com] Sent: Wednesday, November 27, 2013 8:44
>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for
>> usage questions) Cc: Henry Nash; dolph.mathews at gmail.com; David
>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped
>> role definition
>> 
>> 
>> 
>> 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
>> 
>> Updated.  I made my changes Green.  It isn't easy being green.
>> 
>>> 
>>> 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
>>
>>
>>
>>> 
_______________________________________________
>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>