Hi David,

I am cool with the proposal, just wanted to grad you attention on may question 
which I asked in my last email (which is below)

Q. what if two (or more) endpoints want to have same role_name for a service 
(nova.east.admin, nova.west.admin, nova.north.admin .....)? 

(Can we think of adding an optional endpoint_id attribute in role data model to 
allow such role, which is also needed to envision endpoint scoped tokens for 
our use case)

{
     "role": {
      "id": "76e72a",
      "domain_id" = "--id--",    (optional, if present, role is named by 
specific domain)
      "project_id" = "--id--",    (optional, if present, role is named by 
project)
      "service_id" = "--id--",    (optional, if present, role is named by 
service)
      "endpoint_id" = "--id--",    (optional, if present, role is named by 
service)
      "name": "---role_name---",  (must be unique when combined with domain, 
project and service ids)
      "scope": {"id": "---id---", (resource_id)
         "type": "service | file | domain etc.",
         "endpoint":"---endpoint---"
       }
    }
 }

For Adam's question " We are not linking role names to service id." (email 
attached)
AT: These attributes are all optional and will not stop anyone how don't want 
to included service_id or (any other attribute) for role name uniqueness. So in 
particular deployment want to keep just the role name unique, this model will 
not restrict you.

Thoughts? 



Thanks,
Arvind



-----Original Message-----
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Tuesday, December 10, 2013 1:30 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for 
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

How about the following which clearly separates naming and scoping
constraints

 {
     "role": {
      "id": "76e72a",
      "domain_id" = "--id--",    (optional, if present, role is named by 
specific domain)
      "project_id" = "--id--",    (optional, if present, role is named by 
project)
      "service_id" = "--id--",    (optional, if present, role is named by 
service)
      "name": "---role_name---",  (must be unique when combined with domain, 
project and service ids)
      "scope": {"id": "---id---", (resource_id)
         "type": "service | file | domain etc.",
         "endpoint":"---endpoint---"
       }
    }
 }

regards

David
--- Begin Message ---

On 12/09/2013 05:31 PM, Tiwari, Arvind wrote:
> I think that make sense, how does below data model looks?
>
> {
>     "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)
>    "service_id" = "--id--"    (optional)
>     }
>   }

We are not linking role names to service id.

>
> Q. what if two (or more) endpoints want to have same role_name for a service 
> (nova.east.admin, nova.west.admin, nova.north.admin .....)?
>
> Regards,
> Arvind
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
> Sent: Monday, December 09, 2013 3:15 PM
> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for 
> usage questions)
> Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>
> 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:ayo...@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.math...@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.chadw...@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.math...@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:ayo...@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.math...@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.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


--- End Message ---
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to