accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: kerberos auth, getDelegationToken
Date Sat, 06 Jun 2015 18:19:31 GMT
Make sure you read the JavaDoc on DelegationToken:

<snip>
Obtain a delegation token by calling {@link 
SecurityOperations#getDelegationToken(org.apache.accumulo.core.client.admin.DelegationTokenConfig)}
</snip>

You cannot create a usable DelegationToken as the client itself.

Anyways, DelegationTokens are only relevant in cases where the client 
Kerberos credentials are unavailable. The most common case is running 
MapReduce jobs. If you are just interacting with Accumulo through the 
Java API, the KerberosToken is all you need to use.

The user-manual likely just needs to be updated. I believe the 
DelegationTokenConfig was added after I wrote the initial documentation.

Xu (Simon) Chen wrote:
> Hi folks,
>
> The latest kerberos doc seems to indicate that getDelegationToken can be
> called without any parameters:
> https://github.com/apache/accumulo/blob/1.7/docs/src/main/asciidoc/chapters/kerberos.txt#L410
>
> Yet the source code indicates a DelegationTokenConfig object must be
> passed in:
> https://github.com/apache/accumulo/blob/1.7/core/src/main/java/org/apache/accumulo/core/client/admin/SecurityOperations.java#L359
>
> Any ideas on how I should construct the DelegationTokenConfig object?
>
> For context, I've been trying to get geomesa to work on my accumulo 1.7
> with kerberos turned on. Right now, the code is somewhat tied to
> password auth:
> https://github.com/locationtech/geomesa/blob/rc7_a1.7_h2.5/geomesa-core/src/main/scala/org/locationtech/geomesa/core/data/AccumuloDataStoreFactory.scala#L177
> My thought is that I should get a KerberosToken first, and then try
> generate a DelegationToken, which is passed back for later interactions
> between geomesa and accumulo.
>
> Thanks.
> -Simon

Mime
View raw message