[jira] [Commented] (CASSANDRA-8303) Create a capability limitation framework

["Jonathan Shook (JIRA)" <ji...@apache.org>]

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

Jonathan Shook commented on CASSANDRA-8303:
-------------------------------------------

I am concerned that we are creating more complexity through pedantry here. Let me explain...
I know this is late in coming, but I'm going to explain my position anyway.

The idea that a user would be authorized for an operation does not depend on it being on specific data. There is no hard and fast rule that says you must not use authorization to control access to types of actions. From the general perspective, that is what authorization is about. It is simply a mechanism to answer the question "Is the current user allowed to do ____?" This is not strictly limited to accessing specific data, but may also be used to limit access to specific types of actions which are not data-specific. To assert that it is is to ignore lots of established practice across a great number of systems. Authorization is a general concept which needs to be applied in a conceptually useful and idiomatic way for each system.

There is a variety of approaches in the wild for how to structure permissions. Some of them assume no access with exclusions in the form of grants. Some do the opposite. My favorite is the 3-state logic used by the postfix MTA (thank you, Venema!) which allows for a very plugable system. In this system, a chain of evaluators is used, and each may grant, deny, or indicate "I don't know, ask the next one".. And all you have to do to establish a default is put a static grant or deny at the end of the evaluator chain. So, this is a bit non-sequitor, but the point is to illustrate the variety and flexibility of "authorization" systems out there. A competing concern for the flexibility of these system is always how easy they are to understand and use. That feeds directly into my next point.

I don't understand why we would want to create two semantically distinct interfaces for users when we are really talking about a basic authentication problem. Group or individual, data-oriented or command-oriented. Once you've made the user pay the price of entry to use the authentication system, you're going to tell them that they have to learn a different system to do "capability limiting" because we decided to name it and treat it differently? I think this is a case of accidental complexity in the name of separation of concerns, when in fact they are not really separate concerns.
 
You can't completely separate the mechanisms of authorization, group membership, and capabilities. They may have cleanly defined APIs, but if you look at the implementation details of CASSANDRA-7653, saying that they are logically separate would be a half-truth at best. Indeed, the authentication data has been pulled up to be visible and owned by the group management logic. You simply can't have group authentication without authentication. How they are mapped together is another matter. I would assert that authenticating individuals and mapping them via groups would probably be cleaner, but the mechanisms would still need to be inextricably linked at some layer.

>From a security perspective, limiting commands is every bit a part of managing system availability in a security and continuation sense as other forms of authentication+authorization. Think about DOS attacks and what it means to prevent them via command restrictions. It's just that some of the commands are data-specific, and some are not. You simply can not have a proper and separate subsystem for limiting commands without mostly reinventing the wheel around authentication and authorization.

So, regardless of how it's implemented, I don't think we should be trying to designate "authorization" and "limiting allowed commands" as different concerns from the user's perspective. If you subscribe to that mindset, any notion that they would be implemented as rigidly isolated subsystems would be a reason for concern. I'm all for keeping the implemention clean and composable. I just don't want to see us shoot ourselves in the foot because we are forcing separation when there is conceptual, logical, and mechanical affinity.

I uncomfortable with the suggestion under "What does this buy us?, #5" that this would simply be vetoed if it weren't done the way suggested above. Was that meant to be a qualification of how this ticket can move forward?


> Create a capability limitation framework
> ----------------------------------------
>
>                 Key: CASSANDRA-8303
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Anupam Arora
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.x
>
>
> In addition to our current Auth framework that acts as a white list, and regulates access to data, functions, and roles, it would be beneficial to have a different, capability limitation framework, that would be orthogonal to Auth, and would act as a blacklist.
> Example uses:
> - take away the ability to TRUNCATE from all users but the admin (TRUNCATE itself would still require MODIFY permission)
> - take away the ability to use ALLOW FILTERING from all users but Spark/Hadoop (SELECT would still require SELECT permission)
> - take away the ability to use UNLOGGED BATCH from everyone (the operation itself would still require MODIFY permission)
> - take away the ability to use certain consistency levels (make certain tables LWT-only for all users, for example)
> Original description:
> Please provide a "strict mode" option in cassandra that will kick out any CQL queries that are expensive, e.g. any query with ALLOWS FILTERING, multi-partition queries, secondary index queries, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)