Page History

...

The API for management of capabilities will defined in a new interface, ICapabilityManager. As with roles, authn and authz, a default implementation which uses C* tables to persist the capabilities data will be included. The data model for the base capabilities data is described below.

ICapabilityManager is an extension point for third parties to plug in their own implementations. It will define methods to manage restrictions for a role (add, remove, remove all, list), to list all restrictions across all roles, as well as a method to verify whether a set of capabilities required to perform an operation using a specific resource are unrestricted for a particular role.

...

With the optional IF EXISTS/IF NOT EXISTS, attempting creation of an existing restriction or removal of a non-existent restriction is handled silently as a no-op. Without the clause, an invalid request error should be returned. If an invalid role or capability name is supplied, an invalid request error is returned. Part of the validation should also be to verify that the specified capability is applicable for the named resource.  This is mentioned in more detail in the section Initial Set of Capabilities.

Listing restrictions:

List restrictions; to provide query functionality consistent with the equivalent LIST PERMISSIONS & LIST ROLES statements, this has a slightly more complex grammar:

...

Additionally, there must be a means to check at validation time whether a capability referenced in a CREATE/DROP statement is valid in the particular context. Code to validate standard capabilities for existence and for applicability to the named resource will be provided in C* and the checking for non-standard capabilities will be delegated to the ICapabilityManager.

Anchor
data_model data_model

Data Model for Default Implementation

The base restriction data closely resembles the existing system_auth.role_permissions table. Here, each row contains all restrictions for a given role on a given resource.

...

Although the overlap with the permissions system is minimal, creating and removing restrictions clearly requires certain privileges. The initial proposal is that in order to add or remove a restriction, the executing user must have AUTHORIZE permission on the target role, which is consistent with GRANT/REVOKE ROLE. In the usual way, this permission may be held directly or transitively.

Anchor
initial_capabilities initial_capabilities

Initial Set of Capabilities

Of course, this is wide open for discussion but an initial candidate set of capabilities that would meet all the use cases discussed on CASSANDRA-8303 would include:

...