cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1237) Store AccessLevels externally to IAuthenticator
Date Mon, 16 Aug 2010 19:50:17 GMT

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

Stu Hood commented on CASSANDRA-1237:
-------------------------------------

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

> Store AccessLevels externally to IAuthenticator
> -----------------------------------------------
>
>                 Key: CASSANDRA-1237
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1237
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Stu Hood
>            Assignee: Stu Hood
>             Fix For: 0.7.0
>
>         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,
0005-Move-per-thread-state-into-a-ClientState-object-1-pe.patch, 0006-Apply-access.properties-to-keyspaces-during-an-upgra.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.
> The primary goal of this ticket is to separate AccessLevels from IAuthenticators, and
to persist a map of User->AccessLevel along with:
> * EDIT: Separating the addition of 'global scope' permissions into a separate ticket
> * each keyspace, where the AccessLevel continues to have its current meaning
> ----
> In separate tickets, we would like to improve the AccessLevel structure so that it can
store role/permission bits independently, rather than being level based.

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


Mime
View raw message