[jira] [Comment Edited] (CASSANDRA-7653) Add role based access control to Cassandra

["Mike Adamson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080753#comment-14080753 ] 

Mike Adamson edited comment on CASSANDRA-7653 at 7/31/14 11:16 AM:
-------------------------------------------------------------------

h3. Role Based Access Control In Cassandra
The purpose of this comment is to define the changes made to the authentication and authorization models to support role based authorization in the attached 7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they can be granted to a user. Roles can be granted to users and other roles. When a role is granted to a user or other role (grantee) the grantee receives the permissions that have been granted to the role. When a role is revoked from a user or other role (revokee) the revokee loses the permissions that have been granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE <rolename>
New statement to add a role to the system. The role is added to the *system_auth.roles* table.
h6. DROP ROLE <rolename>
New statement to remove a role from the system. The role is removed from the *system_auth.roles* table, any grants using the role are removed from the *system_auth.granted_roles* table and any permissions granted to it are removed from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE <rolename> | USER <username>]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE <rolename> - of a specific role (the caller must be a superuser)
* OF USER <username> - of a specific user (any user if the caller is a superuser otherwise must be the same name as the caller)

If *NORECURSIVE* option is given then only direct grants to the grantee are listed. The default is to list roles recursively.

h6. GRANT <permission> ON <resource> TO \[\[USER] <username> | ROLE <rolename>]
Extension of existing statement to grant permissions to a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.
h6. REVOKE <permission> ON <resource> FROM \[\[USER] <username> | ROLE <rolename>]
Extension of existing statement to revoke permissions from a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.
h6. LIST <permissionOrAll> \[ON <resource>] \[OF \[\[USER] <username> | ROLE <rolename>] \[NORECURSIVE]
Extension of existing statement to list the permissions of a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.

h4. Interface Changes
To support role the IRoleMapper and IRoleBasedAuthorizer interfaces have been added to support the granting of roles and the granting of permissions to roles. 
h4. Schema Changes
Existing auth tables are not being changed for this story but the following new tables are being added:
h6. system_auth.roles
{noformat}
CREATE TABLE system_auth.roles(role text, PRIMARY KEY(role))
{noformat}
h6. system_auth.granted_roles
{noformat}
CREATE TABLE system_auth.granted_roles(grantee text, type text,role text,PRIMARY KEY((grantee, type), role))
{noformat}
h6. system_auth.role_permissions
{noformat}
CREATE TABLE system_auth.role_permissions(role text, resource text, permissions set<text>, PRIMARY KEY(role, resource))
{noformat}


was (Author: mikea):
h3. Role Based Authorization In Cassandra
The purpose of this comment is to define the changes made to the authentication and authorization models to support role based authorization in the attached 7653.patch
h4. Overview
Roles will be able to have permissions granted to then in the same way as they can be granted to a user. Roles can be granted to users and other roles. When a role is granted to a user or other role (grantee) the grantee receives the permissions that have been granted to the role. When a role is revoked from a user or other role (revokee) the revokee loses the permissions that have been granted to the role.
h4. CQL3 Grammar Changes
The following grammar changes to CQL3 are needed to support roles:
h6. CREATE ROLE <rolename>
New statement to add a role to the system. The role is added to the *system_auth.roles* table.
h6. DROP ROLE <rolename>
New statement to remove a role from the system. The role is removed from the *system_auth.roles* table, any grants using the role are removed from the *system_auth.granted_roles* table and any permissions granted to it are removed from the *system_auth.role_permissions* table. 
h6. LIST ROLES \[OF \[ROLE <rolename> | USER <username>]] \[NORECURSIVE]
New to statement to list:
* No options:
** superuser - all the roles in the system (*system_auth.roles* table).
** non-superuser - all the roles available to the user
* OF ROLE <rolename> - of a specific role (the caller must be a superuser)
* OF USER <username> - of a specific user (any user if the caller is a superuser otherwise must be the same name as the caller)

If *NORECURSIVE* option is given then only direct grants to the grantee are listed. The default is to list roles recursively.

h6. GRANT <permission> ON <resource> TO \[\[USER] <username> | ROLE <rolename>]
Extension of existing statement to grant permissions to a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.
h6. REVOKE <permission> ON <resource> FROM \[\[USER] <username> | ROLE <rolename>]
Extension of existing statement to revoke permissions from a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.
h6. LIST <permissionOrAll> \[ON <resource>] \[OF \[\[USER] <username> | ROLE <rolename>] \[NORECURSIVE]
Extension of existing statement to list the permissions of a role. Backward compatibility is maintained by making the *USER* part of the syntax optional.

h4. Interface Changes
To support role the IRoleMapper and IRoleBasedAuthorizer interfaces have been added to support the granting of roles and the granting of permissions to roles. 
h4. Schema Changes
Existing auth tables are not being changed for this story but the following new tables are being added:
h6. system_auth.roles
{noformat}
CREATE TABLE system_auth.roles(role text, PRIMARY KEY(role))
{noformat}
h6. system_auth.granted_roles
{noformat}
CREATE TABLE system_auth.granted_roles(grantee text, type text,role text,PRIMARY KEY((grantee, type), role))
{noformat}
h6. system_auth.role_permissions
{noformat}
CREATE TABLE system_auth.role_permissions(role text, resource text, permissions set<text>, PRIMARY KEY(role, resource))
{noformat}

> Add role based access control to Cassandra
> ------------------------------------------
>
>                 Key: CASSANDRA-7653
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7653
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Mike Adamson
>             Fix For: 3.0
>
>         Attachments: 7653.patch
>
>
> The current authentication model supports granting permissions to individual users. While this is OK for small or medium organizations wanting to implement authorization, it does not work well in large organizations because of the overhead of having to maintain the permissions for each user.
> Introducing roles into the authentication model would sets of permissions to be controlled in one place and then the role granted to users. Roles should also be able to be granted to other roles to allow hierarchical sets of permissions to be built up.



--
This message was sent by Atlassian JIRA
(v6.2#6252)