RBAC support in Craton

User stories for RBAC in Craton include the following:

* An operator can configure parts of the cloud in one region, including defining new devices/resources. But she cannot do so in another region, even though it is in the same project.

* A developer should be able to define a workflow, and run it in a test environment. But to preserve separation of duties, the developer cannot run the workflow against the production cloud.

* An adminstrator should be able to approve, then configure a workflow such that it can run in a specified production cloud, along with any necessary variables, for certain regions.

* An operator can run an audit workflow against devices in regions the workflow is permitted to run in. Another operator may be delegated to run a remediation workflow to correct the audit problems.

* Reading and writing configuration can be controlled by the name of the key, including both a prefix and an arbitrary regex pattern.

The above stories expect a separation of duties can be supported as desired; a user may wear all three of the developer, admin, and op hats in the above stories, but these may also be apply to different users, and different parts of a given cloud.

To support the stories, let's start with (more or less) traditional RBAC. We have the following definitions:

**Principals** include users and workflows. Users may be defined by Keystone, or by Craton directly.

**Resources** includes inventory, workflows definitions, and principals, as well as any configuration variables. (Targets in oslo.policy; but targets are also used in defining rules...)

**Roles** represent the various ways Craton is used, including inventory configuration; defining workflows; and running workflows. All such roles in Craton use the ``fleet:`` kind, for direct integration with Oslo policy management. (This is a bit of abuse of terminology, given that oslo.policy calls these targets in defining rules... but see above.)

A **role assignment** is the triple (resource, principal, role).

In addition, Craton will define a number of stock rules in its ``policy.json`` to combine Keystone roles with Craton's roles, as desired; as well as other productions necessary to get the desired logic with respect to any authorization checks as ultimately called by the ``authorize`` method on ``Enforcer`` objects.

With that in mind, we have the following implicit requirement:

*Implementation should not require duplication of the fleet management hierarchy outside of the Craton SQL database, and especially not into a text file. Naively, we can readily model the above usage of the hierarchy scope through suitable production rules in ``policy.json``.*

However, this naive approach is useful for understanding how Craton can combine its approach with oslo.policy as well as other sources of roles, including Keystone: what is stored in the database is for a given resource is exactly what we could have stored in a text file.

To support these stories, and the above requirement, Craton will use the following:

**Scoped role assignments**. Roles can be assigned to a given resource; and any resource in its scope also gets this role. The combination of such roles is performed by a union-all operation. Such scoped roles resemble Microsoft Active Directory's regular scoped roles.

**Specific roles for Craton**. These include standard managing CRUD ops (list, create, get, delete, update), as well as specifics for running workflows (audit, remediate).

**Regex roles**. Rather than fully specifying a role, it can match resources by their name using a regex. (Effectively such roles are really the enumeration of all regex productions...) Something like the following should work: ``fleet:set_/^some-prefix/``, where we are using the standard forward slashes to mark regex literals.

**Label roles**. Example: having the role ``fleet:audit_label_service:compute`` enables running an audit workflow on devices labeled ``service:compute``. This can be considered a further refinement of the scoping provided, and can possibly implement what Active Directory calls exclusive scoped roles, in conjunction with additional production rules.

A preliminary implementation of the SQLAlchemy modeling of scoped role assignments, including the implementation of the union-all algorithm for scoping via an object's ``resolution_order``, can be found in https://gist.github.com/jimbaker/6a4fd7e07a16a318a45d7d1d96819040