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:[email protected]]
Sent: Monday, November 25, 2013 12:12 PM
To: Tiwari, Arvind; OpenStack Development Mailing List
Cc: Henry Nash; [email protected]; [email protected]; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
I have just added some comments to your blueprint page
regards
David
On 19/11/2013 00:01, Tiwari, Arvind wrote:
Hi,
Based on our discussion in design summit , I have redone the
service_id
binding with roles BP
<https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.
I have added a new BP (link below) along with detailed use case to
support this BP.
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
Below etherpad link has some proposals for Role REST representation
and
pros and cons analysis
https://etherpad.openstack.org/p/service-scoped-role-definition
Please take look and let me know your thoughts.
It would be awesome if we can discuss it in tomorrow's meeting.
Thanks,
Arvind
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
