[ https://issues.apache.org/jira/browse/CASSANDRA-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1237: -------------------------------- Attachment: v2-0001-Remove-AccessLevel-return-value-from-login-since-aut.patch v2-0004-Add-configuration-for-IAuthority-and-handle-SimpleAu.patch v2-0003-Factor-out-reflection-based-class-construction.patch > 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, > v2-0001-Remove-AccessLevel-return-value-from-login-since-aut.patch, > v2-0003-Factor-out-reflection-based-class-construction.patch, > v2-0004-Add-configuration-for-IAuthority-and-handle-SimpleAu.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.