Re: [openstack-dev] [keystone] Service scoped role definition
In preparation for and input to today's design summit session on
Authorisation at 11.50am, I thought it might be beneficial to remind
folks of the proposed design that was circulated by me at the end of the
long discussion on the format of a scoped role, that was held at the end
of last year on this list. Here it is:
{
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
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
---BeginMessage---
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
Re: [openstack-dev] [keystone] Service scoped role definition
On 12/10/2013 11:42 AM, Tiwari, Arvind wrote:
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)
You are over designing. Services and Endpoints have no business in this
design. That is enforcement, not definition or assignment of the
Roles. We need a clean namespace, and mixing services and endpoints in
there adds no benefit.
{
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
On 12/10/2013 04:26 PM, David Chadwick wrote:
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
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.
Unnecessary. You are basically putting in documentation about how they
are to be enforced, which does not belong there.
Just do the basic: allow for the role naming to be nested under
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort. Please stop
trying to make it more complex than necessary.
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Yes, it is required to address one of public cloud use case where we want
regional service admins and to support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.
Based on our discussion I am going to start API specs and submit for review.
{
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 Concern, You are over designing. Services and Endpoints have no
business in this design. That is enforcement, not definition or assignment of
the Roles. We need a clean namespace, and mixing services and endpoints in
there adds no benefit.
AT: To support following two BPs and these are the basic requirements for
public cloud deployment with Keystone otherwise we are locked. I am asking
for endpoint_id extension in role data model to support endpoint scoped tokens
which you mentioned in IRC around a week back.
1.
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
2. https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.
Thanks.
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Tuesday, December 10, 2013 2:27 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
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
My Comments in line.
Arvind
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Tuesday, December 10, 2013 2:54 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/10/2013 04:26 PM, David Chadwick wrote:
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
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.
Unnecessary. You are basically putting in documentation about how they
are to be enforced, which does not belong there.
Just do the basic: allow for the role naming to be nested under
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort. Please stop
trying to make it more complex than necessary.
AT: We are not putting in documentation but we are trying to come up with
generic role data model so that it will support all (private and public cloud)
of our role needs as explained in BP and extensible.
If you really have a solution for all the problems listed in below BPs, please
draft it and present in detail.
So far, two high level ideas (nested role-def and name space) proposed by you
are not helping which is clear.
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.
I will appreciate and definitely consider them if they will resolve our
problems.
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Ack
On 09/12/2013 15:54, Tiwari, Arvind wrote:
Thanks David,
Let me update the etherpad with this proposal.
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Friday, December 06, 2013 2:44 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
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.
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
Re: [openstack-dev] [keystone] Service scoped role definition
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.
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
Re: [openstack-dev] [keystone] Service scoped role definition
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
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
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
Re: [openstack-dev] [keystone] Service scoped role definition
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
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
Re: [openstack-dev] [keystone] Service scoped role definition
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)
}
}
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
Re: [openstack-dev] [keystone] Service scoped role definition
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.
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
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind On 04/12/2013 19:04, Tiwari, Arvind wrote: Hi David, The biggest problems in my opinion are, 1. We are overloading and adding extra complexities on role name to maintain the generalization for role-def data model. On the contrary, having the same role name with multiple definitions (as in your proposal) is overloading role name. 2. Name spacing the role name is not going to resolve all the issues listed in BP. It is not designed to. Each issue has its own resolution. Hierarchical naming resolves the issue of unique role names, that's all. It allows different entities to create the same role (sub)name that are actually different roles and have different global names. 3.All the namespaces are derived from mutable string (domain name, project name, service name etc...) which makes the role name fragile. So why are role IDs immutable and role names mutable? (ditto project/domain/service IDs and names. What is the rationale for that? Maybe you should not allow the names to change once they have been created. I think it is time to break generic role-def data model to accommodate more specialized use cases. That is counter-intuitive. You dont break a model to accommodate more specialized cases. You enhance the model to take the new functionality into account, and preferably in a backwards compatible way. regards David Thanks, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013 10:41 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Adam I understand your problem: having projects and services which have the same name, then the lineage of a role containing this name is not deterministically known without some other rule or syntax that can differentiate between the two. Since domains contain projects which contain services then isnt the containment hierarchy already known and predetermined? If it is then: 4 name components mean it is a service specified role 3 name components mean it is a project specified role 2 name components mean it is a domain specified role 1 name component means it is globally named role (from the default domain) a null string means the default domain or all projects in a domain. You would never have null for a service name. admin means the global admin role /admin ditto x/admin means the admin of the X domain x/y/admin means the admin role for the y project in domain x //x/admin means admin for service x from the default domain etc. will that work? regards David On 04/12/2013 15:04, Adam Young wrote: On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
Re: [openstack-dev] [keystone] Service scoped role definition
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
Re: [openstack-dev] [keystone] Service scoped role definition
All,
I have captured almost all the email conversation (between Arvind, David and
Adam) in the etherpad (line #54 - 126 ) and moved old conversation under line
#130.
https://etherpad.openstack.org/p/service-scoped-role-definition
In the beginning (line # 1 to 51), I have captured where we are right now and
open questions along with my thoughts.
Please take a look and share your comments/suggestion.
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 5:45 AM
To: Tiwari, Arvind; Adam Young
Cc: OpenStack Development Mailing List (not for usage questions);
dolph.math...@gmail.com
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
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
Re: [openstack-dev] [keystone] Service scoped role definition
I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
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
Re: [openstack-dev] [keystone] Service scoped role definition
On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
Re: [openstack-dev] [keystone] Service scoped role definition
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
Re: [openstack-dev] [keystone] Service scoped role definition
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. I wd also appreciate your thoughts 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: 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
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Adam I understand your problem: having projects and services which have the same name, then the lineage of a role containing this name is not deterministically known without some other rule or syntax that can differentiate between the two. Since domains contain projects which contain services then isnt the containment hierarchy already known and predetermined? If it is then: 4 name components mean it is a service specified role 3 name components mean it is a project specified role 2 name components mean it is a domain specified role 1 name component means it is globally named role (from the default domain) a null string means the default domain or all projects in a domain. You would never have null for a service name. admin means the global admin role /admin ditto x/admin means the admin of the X domain x/y/admin means the admin role for the y project in domain x //x/admin means admin for service x from the default domain etc. will that work? regards David On 04/12/2013 15:04, Adam Young wrote: On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
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
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David, The biggest problems in my opinion are, 1. We are overloading and adding extra complexities on role name to maintain the generalization for role-def data model. 2. Name spacing the role name is not going to resolve all the issues listed in BP. 3. All the namespaces are derived from mutable string (domain name, project name, service name etc...) which makes the role name fragile. I think it is time to break generic role-def data model to accommodate more specialized use cases. Thanks, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013 10:41 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Adam I understand your problem: having projects and services which have the same name, then the lineage of a role containing this name is not deterministically known without some other rule or syntax that can differentiate between the two. Since domains contain projects which contain services then isnt the containment hierarchy already known and predetermined? If it is then: 4 name components mean it is a service specified role 3 name components mean it is a project specified role 2 name components mean it is a domain specified role 1 name component means it is globally named role (from the default domain) a null string means the default domain or all projects in a domain. You would never have null for a service name. admin means the global admin role /admin ditto x/admin means the admin of the X domain x/y/admin means the admin role for the y project in domain x //x/admin means admin for service x from the default domain etc. will that work? regards David On 04/12/2013 15:04, Adam Young wrote: On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
Re: [openstack-dev] [keystone] Service scoped role definition
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
Re: [openstack-dev] [keystone] Service scoped role definition
On 12/04/2013 12:40 PM, David Chadwick wrote: Hi Adam I understand your problem: having projects and services which have the same name, then the lineage of a role containing this name is not deterministically known without some other rule or syntax that can differentiate between the two. Since domains contain projects which contain services then isnt the containment hierarchy already known and predetermined? If it is then: 4 name components mean it is a service specified role 3 name components mean it is a project specified role 2 name components mean it is a domain specified role 1 name component means it is globally named role (from the default domain) a null string means the default domain or all projects in a domain. You would never have null for a service name. admin means the global admin role /admin ditto x/admin means the admin of the X domain x/y/admin means the admin role for the y project in domain x //x/admin means admin for service x from the default domain etc. will that work? Very clean. Yes. That will work. regards David On 04/12/2013 15:04, Adam Young wrote: On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing 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. 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? 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
Re: [openstack-dev] [keystone] Service scoped role definition
I have added a number of comments to this. I have also expanded on the concept of role scoping for your consideration regards David On 02/12/2013 23:21, Tiwari, Arvind wrote: 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
Re: [openstack-dev] [keystone] Service scoped role definition
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
Re: [openstack-dev] [keystone] Service scoped role definition
I've been thinking about your comment that nested roles are confusing 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. 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? 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
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
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind I have added my two-penneth to the latest version. I look forward to your comments regards David On 26/11/2013 23:07, Tiwari, Arvind wrote: 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
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
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
Re: [openstack-dev] [keystone] Service scoped role definition
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
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
Re: [openstack-dev] [keystone] Service scoped role definition
On 11/18/2013 07:01 PM, 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 I made some changes based on our conversations last week. I think they will not surprise you, and I hope they fit in with your understanding of how to implement. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
