On 06/02/2016 11:36 AM, Shawn McKinney wrote:
On Jun 2, 2016, at 10:03 AM, Adam Young <[email protected]> wrote:
To do all of this right, however, requires a degree of introspection that we do not have
in OpenStack. Trove needs to ask Nova "I want to do X, what role do I need?"
and there is no where in the system today that this information lives.
So, while we could make something that works for service users as the problem
is defined by Nova today, that would be, in a word, bad. We need something
that works for the larger OpenStack ecosystem, to include less trusted third
party services, and still deal with the long running tasks.
Hello,
If openstack supported RBAC (ANSI INCITS 359) you would be able to call
(something like) this API:
List<String> permissionRoles(Permission perm) throws SecurityException
Return a list of type String of all roles that have granted a particular
permission.
RBAC Review APIs:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html
One of the advantages of pursuing published standards, you enjoy support for
requirements across a broad spectrum of requirements, and perhaps for things
you didn’t know was needed (at design time).
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.
Hope this helps,
Shawn
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev