[
https://issues.apache.org/jira/browse/HBASE-26667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andor Molnar updated HBASE-26667:
-
Description:
Today, we have two mechanism in order to get the tokens needed to authenticate:
# Kerberos, we rely on a Kerberos ticket being present in a well-known
location (defined by JVM properties) or via programmatic invocation of
UserGroupInformation
# Delegation tokens, we rely on special API to be called (our mapreduce API)
which loads the token into the current UserGroupInformation "context" (the JAAS
PrivilegedAction).
The JWT bearer token approach is very similar to the delegation token
mechanism, but HBase does not generate this JWT (as we do with delegation
tokens). How does a client provide this token to the hbase-client (i.e.
{{ConnectionFactory.getConnection()}} or a {{UserGroupInformation}} call)? We
should be mindful of all of the different "entrypoints" to HBase ({{{}hbase
...{}}} commands, {{java -cp}} commands, Phoenix commands, Spark comands, etc).
Our solution should be effective for all of these approaches and not require
downstream changes.
*Update*
The environment variable approach is done, but I have a new idea which will
support token renewal as well:
Implement a generic JwtTokenProvider interface with a default file-based
provider.
Read the token from a specific file similar to what happens in Kerberos. Token
renewal is not part of this ticket.
was:
Today, we have two mechanism in order to get the tokens needed to authenticate:
# Kerberos, we rely on a Kerberos ticket being present in a well-known
location (defined by JVM properties) or via programmatic invocation of
UserGroupInformation
# Delegation tokens, we rely on special API to be called (our mapreduce API)
which loads the token into the current UserGroupInformation "context" (the JAAS
PrivilegedAction).
The JWT bearer token approach is very similar to the delegation token
mechanism, but HBase does not generate this JWT (as we do with delegation
tokens). How does a client provide this token to the hbase-client (i.e.
{{ConnectionFactory.getConnection()}} or a {{UserGroupInformation}} call)? We
should be mindful of all of the different "entrypoints" to HBase ({{{}hbase
...{}}} commands, {{java -cp}} commands, Phoenix commands, Spark comands, etc).
Our solution should be effective for all of these approaches and not require
downstream changes.
> Integrate user-experience for hbase-client
> --
>
> Key: HBASE-26667
> URL: https://issues.apache.org/jira/browse/HBASE-26667
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: Andor Molnar
>Priority: Major
> Fix For: HBASE-26553
>
>
> Today, we have two mechanism in order to get the tokens needed to
> authenticate:
> # Kerberos, we rely on a Kerberos ticket being present in a well-known
> location (defined by JVM properties) or via programmatic invocation of
> UserGroupInformation
> # Delegation tokens, we rely on special API to be called (our mapreduce API)
> which loads the token into the current UserGroupInformation "context" (the
> JAAS PrivilegedAction).
> The JWT bearer token approach is very similar to the delegation token
> mechanism, but HBase does not generate this JWT (as we do with delegation
> tokens). How does a client provide this token to the hbase-client (i.e.
> {{ConnectionFactory.getConnection()}} or a {{UserGroupInformation}} call)? We
> should be mindful of all of the different "entrypoints" to HBase ({{{}hbase
> ...{}}} commands, {{java -cp}} commands, Phoenix commands, Spark comands,
> etc). Our solution should be effective for all of these approaches and not
> require downstream changes.
> *Update*
> The environment variable approach is done, but I have a new idea which will
> support token renewal as well:
> Implement a generic JwtTokenProvider interface with a default file-based
> provider.
> Read the token from a specific file similar to what happens in Kerberos.
> Token renewal is not part of this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
