complement in security label expression?

[Rob Nichols <ro...@robnet.com>]

What I understand from the documentation for 1.4 is that the security label expressions support AND, OR, and Grouping, but do not support NOT.  Is this planned for a future release?  Would there be opposition to adding complement to the expressions?


Our use case involves a hierarchy of roles, and the ability to exclude one sub group.  For concretness, say we have a label that is Group.  Say we also have labels Group1, Group2, etc...  We would occationally add sub groups, like Group5, Group6 after the data is populated.  The authorization would include both "Group" and the subgroupd ("Group1").  The label expression for a cell might be "(Group & !Group1)".


Should we handle this some other way?  Have I misunderstood the documentation?  Should I begin working on adding complement to the expressions?


Thanks,
Rob

Re: complement in security label expression?

[Rob Nichols <ro...@robnet.com>]

Hey Adam, thanks for the reply.  

Your caution to decouple labels from policy is certainly valuable, and much appreciated.

Here's a toy that mimics our situation.  Say we are a large retail company, with lots of stores in many cities.  In some sense, two stores in the same metropolitan area compete with each other for the same customers.  Two stores in different areas are not really competitors.  New stores are added, and existing stores are closed, but a store rarely changes cities.  Let's say we want each store to see their own data, as well as data from any store that is not a competitor, but not be able to see data from competitive stores.

My first thought was that the labels might be store numbers and metro areas.  If store 123 located in City-State sold an item, the transaction record would carry the expression "123 | !City-State".  When someone from a store does a query, the authorization labels would be the store number and city-state name.  Of course, this does couple labels with the policy of determining "competitive."  (Not to mention that metropolitan areas change over time.)

Your "Dr. Bob" example suggests that store number alone would be a better label since it does nothing more than describe the data.  The policy of identifying competitive stores would happen outside of accumulo when setting up the authorization labels for a user.  That makes good sense.  In this situation we could authorize every store that is outside of the metro area, but excluding stores in the same ares would be a shorter list.

I will start digging into the code to add complement to the expression syntax.  We are just getting started with accumulo, so it will be a while before I have a test environment setup.

Thanks again for your feedback.  Would love more if you have additional thoughts about any of this.

Thanks,
Rob

On Saturday, September 1, 2012 at 9:13 PM, Adam Fuchs wrote:

> Hi Rob,
> 
> I think that a complement operator would fit naturally into Accumulo's cell-level security mechanism. The computation wouldn't be any harder, and the language wouldn't be significantly more complex. This would be a great project for you to take on. Please let us know if you need any guidance on how to approach it.
> 
> The main reason why it isn't in there yet is because we haven't found a direct need for it. I would caution you to avoid coupling policy too closely with the data labels, since policy tends to change over time and isn't necessarily directly correlated with the data being labeled. Try to keep your labels as close to a description of the data as possible. For example, if you are labeling my medical records, you would want to label them with something like (AdamsMedicalRecord) rather than (DoctorBob). The policy in this domain applied to my doctor would give Dr. Bob access to the attribute/role "AdamsMedicalRecord". Obviously, this is a toy example, but the more policy you can apply by changing which users have access to which labels rather than complicating the set of labels with policy elements, the better.
> 
> I would love to see more details on your particular attribute scheme. If you can share those here I'm sure they would be very helpful to the community, and then we can also comment on whether they make sense.
> 
> Cheers,
> Adam
> 
> 
> On Sat, Sep 1, 2012 at 1:57 PM, Rob Nichols <ro...@robnet.com> wrote:
>> What I understand from the documentation for 1.4 is that the security label expressions support AND, OR, and Grouping, but do not support NOT.  Is this planned for a future release?  Would there be opposition to adding complement to the expressions?
>> 
>> 
>> Our use case involves a hierarchy of roles, and the ability to exclude one sub group.  For concretness, say we have a label that is Group.  Say we also have labels Group1, Group2, etc...  We would occationally add sub groups, like Group5, Group6 after the data is populated.  The authorization would include both "Group" and the subgroupd ("Group1").  The label expression for a cell might be "(Group & !Group1)".
>> 
>> 
>> Should we handle this some other way?  Have I misunderstood the documentation?  Should I begin working on adding complement to the expressions?
>> 
>> 
>> Thanks,
>> Rob
> 

Re: complement in security label expression?

[Adam Fuchs <af...@apache.org>]

Hi Rob,

I think that a complement operator would fit naturally into Accumulo's
cell-level security mechanism. The computation wouldn't be any harder, and
the language wouldn't be significantly more complex. This would be a great
project for you to take on. Please let us know if you need any guidance on
how to approach it.

The main reason why it isn't in there yet is because we haven't found a
direct need for it. I would caution you to avoid coupling policy too
closely with the data labels, since policy tends to change over time and
isn't necessarily directly correlated with the data being labeled. Try to
keep your labels as close to a description of the data as possible. For
example, if you are labeling my medical records, you would want to label
them with something like (AdamsMedicalRecord) rather than (DoctorBob). The
policy in this domain applied to my doctor would give Dr. Bob access to the
attribute/role "AdamsMedicalRecord". Obviously, this is a toy example, but
the more policy you can apply by changing which users have access to which
labels rather than complicating the set of labels with policy elements, the
better.

I would love to see more details on your particular attribute scheme. If
you can share those here I'm sure they would be very helpful to the
community, and then we can also comment on whether they make sense.

Cheers,
Adam


On Sat, Sep 1, 2012 at 1:57 PM, Rob Nichols <ro...@robnet.com> wrote:

> What I understand from the documentation for 1.4 is that the security
> label expressions support AND, OR, and Grouping, but do not support NOT.
>  Is this planned for a future release?  Would there be opposition to adding
> complement to the expressions?
>
>
> Our use case involves a hierarchy of roles, and the ability to exclude one
> sub group.  For concretness, say we have a label that is Group.  Say we
> also have labels Group1, Group2, etc...  We would occationally add sub
> groups, like Group5, Group6 after the data is populated.  The authorization
> would include both "Group" and the subgroupd ("Group1").  The label
> expression for a cell might be "(Group & !Group1)".
>
>
> Should we handle this some other way?  Have I misunderstood the
> documentation?  Should I begin working on adding complement to the
> expressions?
>
>
> Thanks,
> Rob