You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andor Molnar (Jira)" <ji...@apache.org> on 2022/08/31 08:28:00 UTC

[jira] [Updated] (HBASE-26667) Integrate user-experience for hbase-client

     [ 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)