Yes, that's certainly one option. You could develop a Query Service Layer which wraps Accumulo's API, implements its own authorization policy, and then uses a singular set of credentials to authenticate to Accumulo.
Personally, I call this the "Database User" approach, since it is a common strategy when using traditional relational databases where a set of database credentials are stored in an application's own configuration somewhere, and the application implements its own security policies within the application which are separate from the database credentials. Another option is to make use of Accumulo's "pluggable" Authentication and Authorization interfaces and to provide your own implementation on your class path. See: https://accumulo.apache.org/1.7/accumulo_user_manual.html#_pluggable_security https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_authenticator https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_authorizor https://accumulo.apache.org/1.7/accumulo_user_manual.html#_instance_security_permissionhandler Note: this is an advanced feature, and it may require substantial investment to develop and maintain a secure implementation suitable for your situation. On Thu, May 24, 2018 at 11:36 AM mhd wrk <[email protected]> wrote: > Hi, > > What are the best practices for Accumulo to implement a custom > authorisation module where user authorisations assigned dynamically based > on different attributes like time, location and ... > > Is implementing "Query Services Layer > <https://accumulo.apache.org/1.7/accumulo_user_manual.html#_query_services_layer>" > recommended for power users who access Accumulo for large data analysis via > clients like Spark? > > Thanks, > Mohammad >
