トークン エクスチェンジャによる検証 - Advanced SQL Engine - Teradata Database

サードパーティ アプリケーションからのJWTログオンを受け入れるようにJWTメカニズムを構成できます。例えば、ユーザーはブラウザからWebアプリにログインします。Webアプリは、ログオンを顧客のIdPに統合します。その後、ユーザーがTeradata Vantageに接続すると、WebアプリはJWTトークンをTeradataサーバーに提供して、ログオンを正常に完了します。

デフォルトでは、この機能は無効になっています。

この機能を有効にするために、2つのIDプロバイダが構成されています。

• 内部IdP(サンプル構成ファイルではping-internalと表記): 内部IdPの場合は、TypeをPing-Federateに、ValidateByTokenExchangeをnoに設定します。

  JWTがこのIdPによって作成されている場合は、トークンを交換しなくても検証を実行できます。この場合、JWTは内部アプリケーションから取得されます。

• 外部IdP(サンプル構成ファイルではkeycloak21と表記): 外部IdPの場合は、Typeをkeycloakに、ValidateByTokenExchangeをyesに設定します。

  JWTがこのIdPによって作成されている場合は、最初にトークン交換が行なわれ、次にトークンが検証されます。

  TdgssUserConfigFile.xmlでは、<TokenExchanger>セクションのRefがping-internalに設定されているため、内部IdP (この場合はIdがping-internalに設定されている)の<IdentityProvider>セクションを指しています。

内部IdPが外部IdPからのJWTトークンを受け入れるようにするには、次の操作を実行します。

1. /opt/teradata/tdat/tdgss/site/TdgssUserConfigFile.xmlのバックアップ コピーを作成し、サイトの標準バックアップ手順に従って保存します。
2. TdgssUserConfigFile.xmlを編集し、内部IdPと外部IdPを構成します。

   <!-- JWT -->
    <!-- To modify JWT mechanism configuration, uncomment this section and edit -->
      <Mechanism Name="JWT">
          <MechanismProperties
              MechanismEnabled="yes"
              DefaultMechanism="no"
   
              JWTDynamicKey="yes"
              JWTTokenExchange="yes"
              JWTClientTlsCACertDir="/etc/ssl/certs"
        />
               
        <TokenExchanger
              Ref="ping-internal"
              ClientId="account"
              ClientSecret="Y2I2OGZkZTctM2FjMC00OWQwLWIzMGUtODJjMGIxNTY2NzAy"
              ClientSecretProtected="yes"
         />
               
         <IdentityProvider
              Id="Keycloak21"
              Url="https://keycloak21/auth/realms/uda"
              Type="keycloak"
              ValidateByTokenExchange="yes"
         />
              
         <IdentityProvider
              Id="ping-internal"
              Url="https://auth.pingone.asia/0cea60dc-0279-4b55-98a1-eca07904733a/as"
              Type="Ping-Federate"
              ValidateByTokenExchange="no"
          />
               
          <UserNameMapping
              Claim="given_name"
              Match="(\w+)"
              DatabaseName="${1}" />
                  
          <UserNameMapping
              Claim="sub"
              Match="(\w+).*.com"
              DatabaseName="${1}" />
                  
          <UserNameMapping
              Claim="preferred_username"
              Match="(\w+)@(\w+).com"
              DatabaseName="${1}" />
                  
      </Mechanism>
   

   <TokenExchanger>セクションのプロパティは次のとおりです。

   プロパティ	説明
   Ref	構成された内部IDプロバイダを指します。Refは、JWTの外部発行者のURLを取得するために使用されます。
   ClientId	トークン交換中に使用されるゲートウェイのID。
   ClientSecret	ゲートウェイ クライアントのシークレット パスワード。 ClientSecretProtectedがyesに設定されている場合、ClientSecretは暗号化されて保存されます。
   ClientSecretProtected	ゲートウェイ クライアント シークレットがパスワードで保護されているかどうかを判別します。 デフォルトでは、この値はyesです。

   <IdentityProvider>セクションのプロパティは次のとおりです。

   プロパティ	説明
   ValidateByTokenExchange	このIDプロバイダから取得されたJWTを検証するためにトークン交換を実行する必要があるかどうかを示すフラグ。 有効値はYesまたはNoです。 デフォルトではNoに設定されています。
   [オプション]SubjectIssuer	外部IdP (アクセス トークンの発行者)を内部IdPに登録する場合に使用する別名。 Ping-Federateが内部IdPである場合、このパラメータはオプションです。 Keycloakが内部IdPの場合は、SubjectIssuerが必要です。
   Id	構成ファイル内のIdPを一意に識別します。
   Url	IdPのURL。TDGSSは、このURLからREST API呼び出しを実行して、必要なURLと、発行者、JWK URIなどの他の情報を取得できます。 このURLは、<GlobalValues>セクションのIdpUrlには関係しません。 セキュアなhttps URLを使用する必要があります。
   Type	IDプロバイダのタイプ。値の例は、Ping-Federate、keycloak、vantage-keycloak、azuread、okta、およびauth0です。

   IDプロバイダごとに異なる形式でユーザー名が提供される場合があります。ユーザー名に予測されるパターンは<UserNameMapping>で提供されるため、JWTはペイロードからユーザー名を抽出できます。

   <UserNameMapping>セクションのプロパティは次のとおりです。

   プロパティ	説明
   Claim	クレームは、特にユーザーに関する情報を含むペイロードの一部です。
   Match	クレームが一致するパターン。例えば、クレームにsub (サブジェクト)が含まれている場合は、このsubがパターンによって解析されるため、有効なデータベース ユーザー名を抽出できます。
   DatabaseName	抽出され、ユーザーのデータベース ログオン ユーザー名として使用されるクレームの一部。

   ユーザー名のマッピングの詳細については、ユーザー名のマッピングを参照してください。

3. JWTClientTlsCACertDirで指定された場所にCA証明書を配置します。このディレクトリは通常は次の場所にあります。/opt/teradata/tdat/tdgss/site/ssl/cacerts
4. 構成が正しいことを確認します。
   1. tdgsstestcfgを実行して新しい構成が正しいか検証します。構成ファイルの更新を含む新しいシェルで、テスト環境が起動します。

      /opt/teradata/tdgss/bin/tdgsstestcfg

   2. tdgssauthツールを使用して構成をテストします。

      tdgssauth -m JWT -a token=JWT_from_IdP

      ここで、JWT_from_IdPはTdgssUserConfigFile.xmlで構成したIdPです。コマンドを複数回実行して、構成されている各IdPの構成をテストできます。

   3. テスト シェルを終了します。

      exit

   4. 構成が正しくなるまで、編集とテストを続行します。
5. 次を実行します:

   /opt/teradata/tdgss/bin/run_tdgssconfig

6. run_tdgssconfigがTPAリセットが必要なことを示している場合は、次の操作を実行します。

   tpareset -f “use updated TDGSSCONFIG GDO”