Dear Vish,
I completely agree with you. Its like a trade off between getting
re-authenticated (when in a hierarchy user has different roles at different
levels) or parsing the entire hierarchy till the leaf and include all the roles
the user has at each level in the scope.
I am ok with any one (both has some advantages and dis-advantages).
But one point i didn't understand why should we parse the tree above the level
where the user gets authenticated (as you specified in the reply). Like if user
is authenticated at level 3, then do we mean that the roles at level 2 and
level 1 also should be passed?
Why this is needed? I only see either we pass only the role at the level the
user is getting authenticated or pass the roles at the level till the leaf
starting from the level the user is getting authenticated.
Regards,
Vinod Kumar Boppanna
________________________________________
Message: 21
Date: Fri, 14 Feb 2014 10:13:59 -0800
From: Vishvananda Ishaya <vishvana...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Hierarchicical Multitenancy Discussion
Message-ID: <4508b18f-458b-4a3e-ba66-22f9fa47e...@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi Vinod!
I think you can simplify the roles in the hierarchical model by only passing
the roles for the authenticated project and above. All roles are then inherited
down. This means it isn?t necessary to pass a scope along with each role. The
scope is just passed once with the token and the project-admin role (for
example) would be checking to see that the user has the project-admin role and
that the project_id prefix matches.
There is only one case that this doesn?t handle, and that is when the user has
one role (say member) in ProjA and project-admin in ProjA2. If the user is
authenticated to ProjA, he can?t do project-adminy stuff for ProjA2 without
reauthenticating. I think this is a reasonable sacrifice considering how much
easier it would be to just pass the parent roles instead of going through all
of the children.
Vish
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
