[
https://issues.apache.org/jira/browse/CASSANDRA-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14256878#comment-14256878
]
Sam Tunnicliffe commented on CASSANDRA-7653:
--------------------------------------------
I've taken another run at this, this time without the consideration of
preserving backwards compatibility in IAuthenticator/IAuthorizer.
https://github.com/beobal/cassandra/compare/7653
The concept of users is replaced by roles and in the postgres style there's no
real differentiation between the two, a user being basically an alias for a
role. As such, grants are made between roles and permissions hierarchies are
enabled. Somewhat distinct from permissions, a role may have a number of
options. Another departure from the previous implementation is that when using
custom auth components there no longer exists the requirement to create
users/roles directly in the database.
h4. CQL Syntax Changes
There are no changes to existing CQL syntax, only additional statements.
{code}
CREATE ROLE [IF NOT EXISTS] <rolename> [WITH PASSWORD <password>]
[SUPERUSER|NOSUPERUSER] [LOGIN|NOLOGIN]
ALTER ROLE <rolename> [WITH PASSWORD <password>] [SUPERUSER|NOSUPERUSER]
[LOGIN|NOLOGIN]
DROP ROLE [IF EXISTS] <rolename>
LIST ROLES [OF <rolename>] [NORECURSIVE]
{code}
The output of {{LIST ROLES}} varies depending on the privileges of the user
running the statement.
Without {{OF <rolename>}} option:
* If executed by a superuser, list all roles in the system
* If executed by a non-superuser, list all roles granted to that user
With {{OF <rolename>}} option:
* If executed by a superuser, list roles granted to for the specific role.
* If executed by a non-superuser, the executing user must be a member of the
specified role (either directly or through inheritence).
The {{NORECURSIVE}} option modifies {{LIST ROLES OF <rolename>}} statements to
include only roles granted directly to the specified role. Memberships acquired
through inheritance are excluded.
For backwards compatibility, {{CREATE USER}}, {{ALTER USER}}, {{DROP USER}} &
{{LIST USERS}} become aliases for the equivalent role-centric statements. In
the case of {{CREATE USER}} & {{ALTER USER}} statements, the role is assumed to
have {{LOGIN}} privilege. So the two following statements are equivalent:
{code}
CREATE USER foo WITH PASSWORD 'bar' NOSUPERUSER
CREATE ROLE foo WITH PASSWORD 'bar' NOSUPERUSER LOGIN
{code}
Accordingly, the {{LOGIN}} & {{NOLOGIN}} options are not permitted with
{{CREATE}} and {{ALTER USER}}.
Granting of roles is straightforward. The default internal implementation will
disallow any grant that introduces a circular relationship.
{code}
GRANT <rolename> TO <rolename>
REVOKE <rolename> FROM <rolename>
{code}
Granting and revoking of permissions to roles is unchanged, except that
conceptually the grantee is now a role, rather than a user.
h4. Code changes
h5. IRoleManager
This is a new entity with responsibility for all aspects of role management,
creation/deletion/modification as well as checking for existence during
modification operations. A number of the functions here are simply the old user
management methods previously part of IAuthenticator.
h5. IAuthenticator
The changes here are twofold: removing responsibility for user (role)
management and making SASL the primary authentication mechanism.
h5. IAuthorizer
Minimal changes to this interface, really it's just the semantics that have
changed slightly.
h4. Schema changes for Internal Implementations
h5. Authentication
As role management is now the solely the responsibility of IRoleManager,
IAuthenticator impls generally (and PasswordAuthenticator specifically) no
longer have the means to modify role info. The benefit to that is the
simplification of IAuthenticator's responsibilities, the downside is potential
coupling between IAuthenticator and IRoleManager implementations. For example,
PasswordAuthenticator no longer maintains its own credentials table, instead it
uses the roles table managed by CassandraAuthorizer.
h5. Role Management
The primary table (roles) here is an extension of the existing users table,
previously managed by PasswordAuthenticator. In addition to superuser status of
a role, the option that determines whether the role has login privileges is
held here along with the an password (if PasswordAuthenticator is enabled).
h5. Authorization
As with IAuthorizer, there are minimal changes to the schema of the table used
by CassandraAuthorizer.
h4. Upgrading
The process for converting auth data during a rolling upgrade is fairly
straightforward. As each node is restarted, it will attempt to convert any data
in the legacy tables into the new schema. Until enough nodes to satisfy the
replication strategy for the system_auth keyspace are upgraded and so have the
new schema, this conversion will fail with the failure being reported in the
system log.
During the upgrade, PasswordAuthenticator, CassandraRoleManager &
CassandraAuthorizer will continue to use the legacy tables, so clients should
experience no disruption (* see below for a caveat). Issuing DCL statements
during upgrade is not supported. Once all nodes are upgraded, an operator with
superuser privileges should drop the legacy tables, which will prompt PA, CRM
and CA to switch over to the new tables without requiring a further rolling
restart.
There is currently an issue with running with a mixed cluster during upgrades.
The python driver seems to have a problem in this scenario which both breaks
cqlsh and makes a dtest problematic. I haven't fully investigated yet, but I'm
pretty sure the problem is on the driver side as the connecting with the
java-driver to a mixed cluster doesn't display the same behaviour (I've
attached 2 smoke tests which demonstrate this). Once the cluster is fully
upgraded, authenticated connections from python function normally again.
h4. Tests
New dtest roles fixture, based on the one mentioned above by Mike:
https://github.com/beobal/cassandra-dtest/commit/5df94a9e9839fe25d67e356b41c59fca60df1dd7
I've also written a dtest for verifying the upgrade process, but it still needs
some work (there's the driver issue and the fact that switching versions in
dtest requires a committed branch in the apache repo). Current wip:
https://github.com/beobal/cassandra-dtest/commit/0a6b16f283d49d008e226e3e0ee2e95da096cbe6
> 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
> Assignee: Sam Tunnicliffe
> 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 allow sets of
> permissions to be controlled in one place as a role 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.3.4#6332)
