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
