On 06/16/2016 02:19 AM, Jamie Lennox wrote:
Thanks everyone for your input.
I generally agree that there is something that doesn't quite feel
right about purely trusting this information to be passed from service
to service, this is why i was keen for outside input and I have been
rethinking the approach.
They really feel like a variation on Trust tokens.
From the service perspective, they are tokens, just not the one the
user originally requested.
The "reservation" as I see it is an implicit trust created by the user
requesting the operation on the initial service.
When the service validates the token, it can get back the, lets call it
a "reserved token" in keeping with the term reservation above. That
token will have a longer life span than the one the user originally
requested, but (likely) fewer roles.
When nova calls glance, and then glance calls Swift, we can again
transition to different reserved tokens if needs be.
To this end i've proposed reservations (a name that doesn't feel
right): https://review.openstack.org/#/c/330329/
At a gut feeling level i'm much happier with the concept. I think it
will allow us to handle the distinction between user->service and
service->service communication much better and has the added bonus of
potentially opening up some policy options in future.
Please let me know of any concerns/thoughts on the new approach.
Once again i've only written the proposal part of the spec as there
will be a lot of details to figure out if we go forward. It is also
fairly rough but it should convey the point.
Thanks
Jamie
On 3 June 2016 at 03:06, Shawn McKinney <smckin...@symas.com
<mailto:smckin...@symas.com>> wrote:
> On Jun 2, 2016, at 10:58 AM, Adam Young <ayo...@redhat.com
<mailto:ayo...@redhat.com>> wrote:
>
> Any senseible RBAC setup would support this, but we are not
using a sensible one, we are using a hand rolled one. Replacing
everything with Fortress implies a complete rewrite of what we do
now. Nuke it from orbit type stuff.
>
> What I would rather focus on is the splitting of the current
policy into two parts:
>
> 1. Scope check done in code
> 2. Role check done in middleware
>
> Role check should be donebased on URL, not on the policy key
like identity:create_user
>
>
> Then, yes, a Fortress style query could be done, or it could be
done by asking the service itself.
Mostly in agreement. I prefer to focus on the model (RBAC) rather
than a specific impl like Fortress. That is to say support the
model and allow the impl to remain pluggable. That way you enable
many vendors to participate in your ecosystem and more important,
one isn’t tied to a specific backend (ldapv3, sql, …)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
