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
