accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <>
Subject Re: AccumuloToken
Date Mon, 28 Jan 2013 17:13:19 GMT

On Mon, Jan 28, 2013 at 10:18 AM, Eric Newton <> wrote:

> I'm having some problems with AccumuloToken.  Christopher has already
> brought it up in IRC, and I agree.  I'm putting it out on the list for a
> more inclusive discussion.
> I don't like exposing thrift as the serialization mechanism.  In
> particular, this just hurts my eyes:
> public interface AccumuloToken
> <T extends TBase<?,?>, F extends TFieldIdEnum> extends TBase<T, F>,
> Destroyable {
> ...
> }
> Is there some reason this is not just:
> public interface AccumuloToken extends Writable, Destroyable {
> ...
> }
> I've switched this in my local development environment and it seems to work
> just fine.

This works because the tokens we provide still implement TBase, and the
Thrift serdes still work. I forgot, but agree that we should try to keep
thrift out of the client api. I'm refactoring it now to keep cruft of the
client end.

> I don't like the class name.  Is there some reason why Accumulo isn't just
> assumed and we call this Token or Credential, or even SecurityToken?
I can rename it to SecurityToken as part of the refactoring.

> I don't like the rest of the code being littered with deprecation warnings.
>  If we're not willing to switch the code over to The New Way, why should we
> expect our users?
We need to keep the AuthInfo floating around for API compatibility. As much
as I would love to kill them with fire, this kills api compatibility
between versions.

> Are there not some security implications of dynamic class loading for
> authorization when the class name is specified *by the remote caller*?
The security class is not specified by the remote caller, it's instantiated
from the configuration xml files. All the client does is provide a token
and it's up to the implementation to accept/reject it. I simply provided a
mechanism for the client to get a hint as to what type of token is expected.

> And I know a punched the Proxy in at the last second, but is there
> something we should do with security to avoid changes to this new API?
Like with the CLI and shell, the proxy only supports UserPassTokens. This
should cover a large majority of use cases, but you never know. However,
the great part about extensibility is it allows individuals to do what they
need to do if it reaches outside the common cases. In the worse case, they
can wrap whatever token they need into UserPass to fit their needs, but in
an ideal world we should be able to work with these. However, with the last
minute of the proxy, I'm afraid I do not have the time or knowledge of the
proxy to get that support in for 1.5.

> -Eric

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message