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


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

Reply via email to