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:[email protected]]
Sent: Tuesday, December 10, 2013 1:30 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; [email protected]; 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:[email protected]]
> Sent: Monday, December 09, 2013 3:15 PM
> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
> usage questions)
> Cc: Henry Nash; [email protected]; 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:[email protected]]
>> Sent: Monday, December 09, 2013 1:28 PM
>> To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not
>> for usage questions)
>> Cc: Henry Nash; [email protected]; 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:[email protected]]
>>>>>> Sent: Thursday, December 05, 2013 4:15 AM
>>>>>> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List
>>>>>> (not for usage questions)
>>>>>> Cc: Henry Nash; [email protected]; 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:[email protected]]
>>>>>>> Sent: Tuesday, December 03, 2013 6:52 PM
>>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List (not for
>>>>>>> usage questions)
>>>>>>> Cc: Henry Nash; [email protected]; 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:[email protected]]
>>>>>>>> Sent: Monday, November 25, 2013 12:12 PM
>>>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List
>>>>>>>> Cc: Henry Nash; [email protected]; [email protected]; 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
>>>>>>>> [email protected]
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--- End Message ---
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
