[
https://issues.apache.org/jira/browse/CASSANDRA-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1237:
--------------------------------
Description:
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
was:
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.
> 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.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,
> 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.
> 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.
