Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB