accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: User authorizations in accumulo
Date Mon, 16 Feb 2015 22:56:42 GMT
I think part of your question pertains to the differences between ABAC
(attribute-based access controls) and RBAC (role-based access controls).

In both A1 and A2, you're thinking in terms of RBAC. The only real
differences is whether you want to have one additional role, or repurpose
the existing ones. However, Accumulo's data visibilities are more like
ABAC. Of course, you can use whatever method works for you, but the intent
is more ABAC than RBAC.

The main pitfall with RBAC is that roles and users change, and data is
complex and large and you don't want to re-write it when things change.
However, attributes are properties of the data itself, upon which you can
make access decisions. These attributes should be things that don't
change... they are inherent to the data (ideal).

To think in terms of ABAC, the main question to ask is "What properties of
this data element will determine who can access it?". For example, does it
contain personal information or medical history? Does it contain usernames
and email addresses? What is it about this data that makes it worth
protecting? Does it need to be protected? I think that's mainly what John
Vines' talk was about (the differences between RBAC and ABAC).

If RBAC is more appropriate for your data, I'd probably go with A1, because
it's easier to implement and maintain. The biggest drawback is that you
require additional storage space to store the additional role in each
visibility. Because of some internal optimizations, if you go this route,
I'd recommend making this role a prefix, rather than a suffix
"SUPERUSER|(restOfVisibility)" vs. "(restOfVisibility)|SUPERUSER".

Christopher L Tubbs II

On Mon, Feb 16, 2015 at 5:39 PM, Srikanth Viswanathan <>

> Hello,
> I'm using Accumulo to store raw and value-added data and expose this
> data to a small number of end users. During ingestion, the system will
> connect to accumulo as a single accumulo user called, say, "ingestor".
> This user will first store data, and then later in the ingestion
> pipeline read the same data back to add value and write the
> value-added data back. End-users will connect as themselves (i.e.,
> individual accumulo accounts) to read the data.
> The questions I am facing are:
> Q1. How to manage the read authorizations for the ingestor?
> Q2. How to ensure data in accumulo is never orphaned due to current
> users lacking authorizations to read certain columns?
> It seems to me that I have two options, both of which will solve both
> my problems above:
> A1. Grant the ingestor a single authorization and store the data with
> labels that allow the ingestor access via this label. e.g.,
> "ingestor|(foo_end_user_group|bar_end_user_group)". By doing this, I
> don't have to maintain special authorization logic for the ingestor,
> and I can also fall back on it to read data that might otherwise be
> orphaned.
> A2.  Store only the end user groups in the visibility labels
> ("foo_end_user_group|bar_end_user_group"), and
> force the ingestion user to obtain all group authorizations needed in
> order to read the data. This will require special logic to update the
> ingestor's authorizations when a new authorization is added to the
> system.
> A1 seems simpler to me, but I heard John Vines discourage this in his
> talk at the 2014 Accumulo Summit.  Doesn't the user in either case see
> the same set of data (i.e., "everything"). What then are the potential
> pitfalls of A1 compared to A2?
> Thank you!
> Srikanth Viswanathan

View raw message