[jira] [Commented] (HBASE-6222) Add per-KeyValue Security

["Jerry Chen (JIRA)" <ji...@apache.org>]

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

Jerry Chen commented on HBASE-6222:
-----------------------------------

@Jon

bq. From my point of view, I'd like really like to understand more than just accumulo's implementation – I really care about if accumulo's semantics are 1) intentional and required for accumulo use cases and 2) if applications only use a constrained sets of its capabilities. One specific thing I don't quite understand is the ramifications of having column visibility settings are encoded as part of the key and sort order. This could be equivalent expressions that are no longer equals, and some of somewhat goofy future/past views.  

I looked into the accumulo implementation. And one thing that accumulo want to achieve by making the ColumnVisibility as a part of the column key is that the authorization can be enforced without reading the existing records that may be affected by the current mutation. Because the ColumnVisibility is part of the key, you need to explicitly give the ColumnVisibility to identify/match to the column you are targeting to change (put or delete), and thus VisibilityConstraint check can be performed on the given ColumnVisibility with the user's authorization tokens to make sure the user has been authorized for performing the mutation logically on an existing column, without scanning the existing columns that it may make changes on. HBase and accumulo are at the same situation for this.

There may some other issues to be addressed if something is not part of the key and also not part of the value when multiple versions of a logical column existed. For example, a Put with new Visibility values of the key of {row1, family1:qualifier1} will make an logical changes on all the cells with key {row1, family1:qualifier1}, and thus authorization must be checked over all these affected items (which may with different Visibility values) with the user authorization to see whether the Put can be performed or not. And the deletion gets the same thing to consider when considering DeleteFamily and DeleteColumn which logically affect a lot of columns that may have different Visibility values).

One important change on the client API when the Visibility is part of the column key is the Visibility need to be specified either explicitly or implicitly (such as empty Visibility is used when no Visibility provided in the parameters) when performing Put or Delete mutations. This does seem a little strange at a first glance when comparing with approaches used by traditional database row level authorization such as Oracle Label Security. But the question is do we have other better choices both solve the problem and fit into the current framework?

                
> Add per-KeyValue Security
> -------------------------
>
>                 Key: HBASE-6222
>                 URL: https://issues.apache.org/jira/browse/HBASE-6222
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>            Reporter: stack
>
> Saw an interesting article: http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
> "The  Senate Armed Services Committee version of the fiscal 2013 national defense authorization act (S. 3254) would require DoD agencies to foreswear the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO certifies that there exists either no viable commercial open source database with security features comparable to [Accumulo] (such as the HBase or Cassandra databases)..."
> Not sure what a 'commercial open source database' is, and I'm not sure whats going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security' like Accumulo's, we might put ourselves in the running for federal contributions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira