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 http://gravatar.com/ctubbsii On Mon, Feb 16, 2015 at 5:39 PM, Srikanth Viswanathan <[email protected]> wrote: > 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 >
