cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nirmal Ranganathan (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1237) Store AccessLevels externally to IAuthenticator
Date Tue, 17 Aug 2010 20:08:19 GMT


Nirmal Ranganathan commented on CASSANDRA-1237:

Here's some probable use cases for Authz:
* User A / Group B -> read/write KS1, KS2: read KS3
* User C / Group D -> create/rename/drop KS/CF
* User E -> read/write KS1-CF1, KS1-CF2: read KS1-CF3
* Admin -> add/modify/delete Users/groups/permissions

> Store AccessLevels externally to IAuthenticator
> -----------------------------------------------
>                 Key: CASSANDRA-1237
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Stu Hood
>            Assignee: Stu Hood
>             Fix For: 0.8
>         Attachments: 0001-Consolidate-KSMetaData-mutations-into-copy-methods.patch, 0002-Thrift-and-Avro-interface-changes.patch,
0003-Add-user-and-group-access-maps-to-Keyspace-metadata.patch, 0004-Remove-AccessLevel-return-value-from-login-and-retur.patch,
sample-usage.patch, simple-jaas-authenticator.patch
> Currently, the concept of authentication (proving the identity of a user) is mixed up
with permissions (determining whether a user is able to create/read/write databases). Rather
than determining the permissions that a user has, the IAuthenticator should only be capable
of authenticating a user, and permissions (specifically, an AccessLevel) should be stored
consistently by Cassandra.
> EDIT: Adding summary
> ----
> In summary, there appear to be 3 distinct options for how to move forward with authorization.
Remember that this ticket is about disconnecting authorization (permissions) from authentication
(user/group identification), and its goal is to leave authentication pluggable.
> Options:
> # Leave authentication and authorization in the same interface. If we choose this option,
this ticket is invalid, and CASSANDRA-1271 and CASSANDRA-1320 will add-to/improve IAuthenticator
> ** Pros:
> *** Least change
> ** Cons:
> *** Very little actually implemented by Cassandra: burden is on the backend implementors
> *** Each combination of authz and authc backends would require a new implementation (PAM
for authc + permissions keyspace for authz, for instance), causing an explosion of implementations
> # Separate out a pluggable IAuthority interface to implement authorization
> ## IAuthenticator interface would be called at login time to determine user/groups membership
> ## IAuthority would be called at operation time with the user/groups determined earlier,
and the required permission for the operation
> ** Pros:
> *** Provides the cleanest separation of concerns
> *** Allows plugability for permissions
> ** Cons:
> *** Pluggability of permissions gains limited benefit
> *** IAuthority would need to support callbacks for keyspace/cf creation and removal to
keep existing keyspaces in sync with their permissions (although technically, option 1 suffers
from this as well)
> # Separate authorization, but do not make it pluggable
> ** This option is implemented by the existing patchset by attaching permissions to metadata,
but could have an alternative implementation that stores permissions in a permissions keyspace.
> ** Pros:
> *** Cassandra controls the scalability of authorization, and can ensure it does not become
a bottleneck
> ** Cons:
> *** Would need to support callbacks for user creation and removal to keep existing users
in sync with their permissions

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message