Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo, mail # dev - Re: AccumuloToken


+
John Vines 2013-01-28, 19:52
+
Eric Newton 2013-01-28, 15:18
+
John Vines 2013-01-28, 17:13
+
Eric Newton 2013-01-28, 19:17
+
Christopher 2013-01-28, 20:14
+
John Vines 2013-01-28, 19:35
Copy link to this message
-
Re: AccumuloToken
Keith Turner 2013-01-28, 18:23
On Mon, Jan 28, 2013 at 12:13 PM, John Vines <[EMAIL PROTECTED]> wrote:
> inline-
>
>
> On Mon, Jan 28, 2013 at 10:18 AM, Eric Newton <[EMAIL PROTECTED]> 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.

I can take a look at this.  We are not going to be adding any new
features for 1.5.   But I think we should certainly intergrate the
exiting new features to form a cohesive whole.  I have one idea for
this. I will post it on the ticket.

>
>
>> -Eric
>>