On 13-12-08 12:07 AM, Lyle, David wrote:
The set domain context functionality is for operators (admins) to refine the
context that they are working in/viewing. Admins can limit the scope of
identity visibility to one domain, rather than having to sort through the
exhaustive lists of projects, users, and groups.
If you are adding multiple users with the admin role, they will still have
visibility across domains. They will be able to see all instances, volumes,
networks, etc. Currently, the domain scoping is only implemented for the
identity management panel group. The intention is to extend the scoping to
services beyond keystone as well. But even once that's implemented, any user
with the admin role will be able to view/modify any instance, volume, network,
etc., via the CLI.
The functionality you are looking for is a way to view things as a domain
admin. The domain admin role does not explicitly exist in OpenStack. It needs
to, but does not. If implemented, a user with domain admin capabilities would
not have the admin role and see entities in their domain much like what is seen
in the current project dashboard. There are several Horizon blueprints in
Icehouse to add RBAC support for the integrated services and consolidate the
project and admin dashboards. Once those are implemented, then creating a
domain admin role and modifying the policy.json files Horizon uses would allow
the behavior you desire -- assuming you are using a policy.json file for
keystone that also supports a domain admin role. This will look very much like
the identity management panel group does today when the domain context is set.
-David Lyle
-----Original Message-----
From: Paul Belanger [mailto:paul.belan...@polybeacon.com]
Sent: Saturday, December 07, 2013 7:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [horizon] Purpose of SetDomainContext /
UnsetDomainContext button
Greetings,
I recently enabled multi-domain support on my dashboard and noticed a
new domain context button. I was actually surprised to see I had to
manually toggle the functionality to set the domain context, hiding
domain foo resources from domain bar.
My question is simple, what is the purpose of this functionality? For
me, if I setup admins in 2 different domains, I don't want them to
actually see the resources of the other, asking them to click said
button seems to defeat the purpose.
Right now, I am attempting to setup a configuration file settings that
will force the domain_context to be setup on login, hence hiding
external domain resources by default.
But like I asked, trying to better understand the use case of the
current functionality.
Correct,
I am in-fact trying to get 'domain admins' setup using horizon. Right
now I've been struggling to get the policy.v3cloudsample.json[1] to
properly work in keysone, let alone horizon.
Because I was struggling with that, I was next focusing on the 'domain
context' functionality in horizon to see if I could limit functionality.
[1]
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev