Almost, but not quite. The role name cannot be anything you like. It
must be globally unique, and named hierarchically. There is a proposal
in another message of this thread for what this could be, based on a 4
component naming scheme with / separators.
regards
david
On 04/12/2013 19:42, Tiwari, Arvind wrote:
> Thanks David,
>
> Appended line # 119 with my reply. "endpoint" sounds perfect to me.
>
> In a nutshell we are agreeing on following new data model for role-def.
>
> {
> "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)
> "endpoint":"-- endpoint--" (An optional field to indicate the
> interface of the resource (endpoint for service, path for File,....) for
> which the role-def is created.)
> }
> }
> }
>
> If other community members are cool with this, I will start drafting the API
> specs?
>
>
> Regards,
> Arvind
>
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
> Sent: Wednesday, December 04, 2013 11:42 AM
> To: Tiwari, Arvind; Adam Young
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>
>
>
> 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.chadw...@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:ayo...@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.math...@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.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
>>>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
