SecAdmin

[John Vines <jo...@ugov.gov>]

One point that has been brought to my attention is that the administration
of users and their authorizations brings difficulties to development. There
are situations where you trust a user to create users, modify their
privileges, and drop users, but not to manage a users authorizations.
After talking to someone, the idea of a Secadmin was brought to my
attention. We should split the administration space into two areas. The
Grant privilege is still the root for granting Secadmin and for modifying
authorizations. Secadmin should be the necessary privilege for managing
users besides their authorizations. This allows a user who's trust enough
to create users but not trusted enough to grant access to the various
levels of data.

I'm opening up this as a discussion for dev to hear the communities
thoughts and hash out details prior to ticket creation. Ideally these
changes will get rolled into my branch for ACCUMULO-259, to be implemented
in Accumulo 1.5.

John

Re: SecAdmin

[William Slacum <ws...@gmail.com>]

Depending on what kind of interfaces you want to support, you could
use something similar to CAS. A Ruby implementation can be found at
http://code.google.com/p/rubycas-server/ .

On Fri, Jul 6, 2012 at 10:23 AM, Adam Fuchs <af...@apache.org> wrote:
> One thought I had on this is that once we make authorization and
> authentication pluggable, all of these concerns can be offloaded to
> whatever system implements the back-end. The basic authentication and
> authorization that we provide out of the box does not necessarily need to
> have the most advanced configuration features. Perhaps we should keep it
> simple, like it is now? Is there another project onto which we can heap
> these requirements?
>
> Adam
>
>
> On Mon, Jul 2, 2012 at 4:46 PM, John Vines <jo...@ugov.gov> wrote:
>
>> One point that has been brought to my attention is that the administration
>> of users and their authorizations brings difficulties to development. There
>> are situations where you trust a user to create users, modify their
>> privileges, and drop users, but not to manage a users authorizations.
>> After talking to someone, the idea of a Secadmin was brought to my
>> attention. We should split the administration space into two areas. The
>> Grant privilege is still the root for granting Secadmin and for modifying
>> authorizations. Secadmin should be the necessary privilege for managing
>> users besides their authorizations. This allows a user who's trust enough
>> to create users but not trusted enough to grant access to the various
>> levels of data.
>>
>> I'm opening up this as a discussion for dev to hear the communities
>> thoughts and hash out details prior to ticket creation. Ideally these
>> changes will get rolled into my branch for ACCUMULO-259, to be implemented
>> in Accumulo 1.5.
>>
>> John
>>

Re: SecAdmin

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

One thought I had on this is that once we make authorization and
authentication pluggable, all of these concerns can be offloaded to
whatever system implements the back-end. The basic authentication and
authorization that we provide out of the box does not necessarily need to
have the most advanced configuration features. Perhaps we should keep it
simple, like it is now? Is there another project onto which we can heap
these requirements?

Adam


On Mon, Jul 2, 2012 at 4:46 PM, John Vines <jo...@ugov.gov> wrote:

> One point that has been brought to my attention is that the administration
> of users and their authorizations brings difficulties to development. There
> are situations where you trust a user to create users, modify their
> privileges, and drop users, but not to manage a users authorizations.
> After talking to someone, the idea of a Secadmin was brought to my
> attention. We should split the administration space into two areas. The
> Grant privilege is still the root for granting Secadmin and for modifying
> authorizations. Secadmin should be the necessary privilege for managing
> users besides their authorizations. This allows a user who's trust enough
> to create users but not trusted enough to grant access to the various
> levels of data.
>
> I'm opening up this as a discussion for dev to hear the communities
> thoughts and hash out details prior to ticket creation. Ideally these
> changes will get rolled into my branch for ACCUMULO-259, to be implemented
> in Accumulo 1.5.
>
> John
>