[openstack-dev] [keystone] Service scoped role definition
David Chadwick
d.w.chadwick at kent.ac.uk
Mon Dec 9 22:15:00 UTC 2013
Hi Arvind
this is still mixing up two separate concepts: naming and policy
constraints. Scope is a policy constraint but in the proposal below is
also part of the unique naming of the role. The fields making up both
concepts need to be separate (e.g. what if 2 different roles from the
same domain and project applied to two different scopes but it just so
happened that the ids of the two resources were the same? They would end
up still having the same unique name.)
I would therefore add "service_id" = "--id--" (optional)
after project_id. This can assure that (composite) role names (keys) are
unique
regards
David
On 09/12/2013 20:36, Tiwari, Arvind wrote:
> Hi David,
>
> I have updated the ether pad with below comments.
>
> Regards,
> Arvind
>
>
>
> "Another alternative is to change role name into role display name, indicating that the string is only to be used in GUIs, is not guaranteed to be unique, is set by the role creator, can be any string in any character set, and is not used by the system anywhere (AT1). Only role ID is used by the system, in policy evaluation, in user-role assignments, in permission-role assignments etc. (AT2)"
>
> AT1 -
> 1. Display name proposal does not seems to work because, we cannot enforce service (e.g. Nova, Swift) to use role_id to define their policy.
> AT2 -
> 1. Using role_id for policy evaluation is doable but it will be an enormous impact on token data structure, policy etc...., which won't be acceptable to community.
> 2. permission-role assignments goes with policy file which is again not acceptable due to same reason as #1.
> 3. user-role (or group-role) assignments uses the role_id, so there won't be any change.
>
> I think we should consider composite key to make the role entity unique and keep having duplicate role_names in system. Something as below
>
> {
> "role": {
> "id": "76e72a",
> "name": "---role_name---", (resource name spaced name e.g. nova.east.admin)
> "scope": {
> "id": "---id---", (resource_id)
> "type": "service | file | domain etc.",
> "endpoint":"---endpoint---"
> }
> "domain_id" = "--id--", (optional)
> "project_id" = "--id--" (optional)
> }
> }
> Fields name, scope.id, domain_id and project_id makes the composite key.
>
>
>
> -----Original Message-----
> From: Adam Young [mailto:ayoung at redhat.com]
> Sent: Monday, December 09, 2013 1:28 PM
> To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)
> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang
> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>
> On 12/09/2013 03:04 PM, David Chadwick wrote:
>>
>> On 09/12/2013 19:37, Adam Young wrote:
>>> On 12/06/2013 04:44 AM, David Chadwick wrote:
>>>> Another alternative is to change role name into role display name,
>>>> indicating that the string is only to be used in GUIs, is not guaranteed
>>>> to be unique, is set by the role creator, can be any string in any
>>>> character set, and is not used by the system anywhere. Only role ID is
>>>> used by the system, in policy evaluation, in user-role assignments, in
>>>> permission-role assignments etc.
>>> That will make policy much harder to read. I'd recommend that the role
>>> name continue to be the "good" name, for both UI and for policy
>>> enforcement.
>> in which case all role names must be unique
>>
>> David
>
> Hat is my understanding, yes, and I think that your proposal covers
> that. A role name for policy will be the full name, for example
> "domain/project/role" in the 3 portion version you posted.
>
>>
>>>
>>>
>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>> On 05/12/2013 16:21, Tiwari, Arvind wrote:
>>>>> Hi David,
>>>>>
>>>>> Let me capture these details in ether pad. I will drop an email after
>>>>> adding these details in etherpad.
>>>>>
>>>>> Thanks,
>>>>> Arvind
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
>>>>> Sent: Thursday, December 05, 2013 4:15 AM
>>>>> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List
>>>>> (not for usage questions)
>>>>> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang
>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>>>>>
>>>>> Hi Arvind
>>>>>
>>>>> we are making good progress, but what I dont like about your proposal
>>>>> below is that the role name is not unique. There can be multiple roles
>>>>> with the same name, but different IDs, and different scopes. I dont like
>>>>> this, and I think it would be confusing to users/administrators. I think
>>>>> the role names should be different as well. This is not difficult to
>>>>> engineer if the names are hierarchically structured based on the name of
>>>>> the role creator. The creator might be owner of the resource that is
>>>>> being scoped, but it need not necessarily be. Assuming it was, then in
>>>>> your examples below we might have role names of NovaEast.admin and
>>>>> NovaWest.admin. Since these are strings, policies can be easily adapted
>>>>> to match on NovaWest.admin instead of admin.
>>>>>
>>>>> regards
>>>>>
>>>>> david
>>>>>
>>>>> On 04/12/2013 17:21, Tiwari, Arvind wrote:
>>>>>> Hi Adam,
>>>>>>
>>>>>> I have added my comments in line.
>>>>>>
>>>>>> As per my request yesterday and David's proposal, following role-def
>>>>>> data model is looks generic enough and seems innovative to
>>>>>> accommodate future extensions.
>>>>>>
>>>>>> {
>>>>>> "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)
>>>>>> "interface":"--interface--" (We are still need working on
>>>>>> this field. My idea of this optional field is to indicate the
>>>>>> interface of the resource (endpoint for service, path for File,....)
>>>>>> for which the role-def is created and can be
>>>>>> empty.)
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Based on above data model two admin roles for nova for two separate
>>>>>> region wd be as below
>>>>>>
>>>>>> {
>>>>>> "role": {
>>>>>> "id": "76e71a",
>>>>>> "name": "admin",
>>>>>> "scope": {
>>>>>> "id": "110", (suppose 110 is Nova serviceId)
>>>>>> "interface": "1101", (suppose 1101 is Nova region East
>>>>>> endpointId)
>>>>>> "type": "service"
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> {
>>>>>> "role": {
>>>>>> "id": "76e72a",
>>>>>> "name": "admin",
>>>>>> "scope": {
>>>>>> "id": "110",
>>>>>> "interface": "1102",(suppose 1102 is Nova region West
>>>>>> endpointId)
>>>>>> "type": "service"
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> This way we can keep role-assignments abstracted from resource on
>>>>>> which the assignment is created. This also open doors to have
>>>>>> service and/or endpoint scoped token as I mentioned in
>>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq.
>>>>>>
>>>>>> David, I have updated
>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition line
>>>>>> #118 explaining the rationale behind the field.
>>>>>> I wd also appreciate your vision on
>>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support
>>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Arvind
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Adam Young [mailto:ayoung at redhat.com]
>>>>>> Sent: Tuesday, December 03, 2013 6:52 PM
>>>>>> 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
>>>>>>
>>>>>> I've been thinking about your comment that "nested roles are confusing"
>>>>>> AT: Thanks for considering my comment about nested role-def.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> AT: It seems this approach is not going to help, service rename
>>>>>> would impact all the role-def for a particular service. And we are
>>>>>> back to the same problem.
>>>>>>
>>>>>> 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?
>>>>>> AT: It is defiantly clearer but it will create same problems as what
>>>>>> we are trying to fix.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>
More information about the OpenStack-dev
mailing list