Re: Custom authorisation

[Christopher <ct...@apache.org>]

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 <mh...@gmail.com> 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
>

Re: Custom authorisation

[Geoffry Roberts <th...@gmail.com>]

I'll chime in and say I have been longing for better A&A for Accumulo.  I
think an implementation of the existing A&A interfaces is the way to go.
Christopher is quite right in that such a thing would be a major
investment, but in this day and age I think it's worthwhile.

On Mon, Jun 11, 2018 at 6:14 PM, Christopher <ct...@apache.org> wrote:

> 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 <mh...@gmail.com> 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
>>
>


-- 
There are ways and there are ways,

Geoffry Roberts