USER MANUALS

HTTP パス

HTTP リクエストをサーバーに送信することによってデータを取得する必要がある場合は HTTP パスを使用します。

HTTP パスを使用すると、HTTP メソッドの GET、PUT、POST、DELETE、または PATH のいずれかを使用してリクエストを送信できます。

POST 、 PUT 、または PATH のリクエストの本文にパラメータを追加するには、以下の 2 つの方法があります。

  1. URL parameters: URL に存在するクエリパラメータが URL から削除され、HTML フォームの値としてリクエストの本文に置かれて送信されます。HTTP リクエストの Content-type ヘッダーは application/x-www-form-urlencoded になります。

    たとえば、実行時の URL が http://acme/customer?first_name=John&last_name=Smith である場合、Virtual DataPort サーバーから HTTP リクエストが http://acme/customer (クエリパラメータなし) に送信され、そのリクエストの本文が first_name=John&last_name=Smith になります。

  2. Post body: このオプションの下にあるテキスト領域の内容が HTTP リクエストの本文に設定されて送信されます。[Content type] ボックスに、本文の内容種別を入力します。

データを取得するために送信される HTTP リクエストにヘッダーを追加するには、[HTTP headers] をクリックします。[HTTP Headers] ダイアログで [New] をクリックして、ヘッダーの名前と値を入力します。

HTTP パスの以下のエレメントには、補間変数を使用できます (補間変数については、「 補間変数によるパスなどの値 」を参照)。

  1. URL: 1 つまたは複数の補間変数を指定できます。たとえば、 https://acme.com/department?id=@{department_id} とします。

  2. HTTP headers: 名前とその値として補間変数を指定できます。

  3. POST body: 1 つまたは複数の補間変数を指定できます。データソースにクエリを実行するときに、POST リクエスト、および実行時に本文に設定する必要がある 1 つまたは複数の値を送信する場合に、このエレメントが便利です。たとえば、POST リクエストの本文が以下のとおりであるとします。

    <employee_info>
   <last_name>@last_name</last_name>
   <first_name>@first_name</first_name>
</employee_info>
HTTP POST request with XML Body with an interpolation variable

XML 本文に補間変数を使用した HTTP POST リクエスト

この XML には、文字列 @first_name と @last_name が記述されています。文字 @ は、first_name と last_name が補間変数であることを示します。このデータソースにクエリを実行したときに、文字列の @first_name と @last_name が値で置き換えられます。

このデータソースから基本ビューを作成した場合、そのビューには department_id、last_name、および first_name の 3 つの追加フィールドが存在します。このビューに対するクエリでは、WHERE 句でこれらのフィールドの値を必ず指定する必要があります。

たとえば、クエリが以下のようであるとします。

SELECT *
FROM view
WHERE department_id = 2 AND first_name = 'John' AND last_name = 'Smith'

Virtual DataPort サーバーからは、以下の本文を設定したリクエストが https://acme.com/department?id=@{department_id} に送信されます。

<employee_info>
    <last_name>Smith</last_name>
    <first_name>John<first_name>
</employee_info>

このデータソースから作成された基本ビューを指定しているにもかかわらず、これら 3 つのフィールドの値を指定していないクエリは失敗します。

注釈

補間変数の名前を構成していない文字 @、{、および } はエスケープする必要があります。これらの文字をエスケープするには、文字 を使用します。文字 はその文字自体でエスケープします (例: \)。以下に例を示します。

<employee_info_request>
  <department_name>department \@1 \{ACCT\}</department_name>
</employee_info_request>

[Load file] を使用してリクエストの本文を読み込んだ場合、これらの文字はすべて管理ツールによって自動的にエスケープされます。

補間変数を使用すると、Web サーバーに対する HTTP リクエストが静的でなくなり、クエリごとに変更できるという利点があります。

HTTP パスの定義に補間変数を使用している場合は、[Test connection] をクリックしたときに補間変数の値を指定する必要があります。このデータソースから基本ビューを作成するときも同様の指定が必要です。変数の値を入力するダイアログが、以下のように管理ツールによって表示されます。

Providing the value of an interpolation variable for an HTTP path

HTTP パスにある補間変数の値の指定

各変数の値を URL のクエリパラメータの値として使用する場合は、このダイアログで [URI parameter] チェックボックスをチェックします。このようにチェックすると、それに応じて変数の値がエスケープされます。チェックしていない場合、変数が URL の一部であっても、その値は URL の他の部分と同じようにエスケープされます。たとえば、URL が http://acme/recipe?name=@dish の場合、変数 dish の値を指定するときに [URI parameter] チェックボックスをチェックしたとします。 dish の値が Mac&Cheese だとすると、Virtual DataPort サーバーからは http://acme/recipe?name=Mac%26cheese にリクエストが送信されます。& は %26 で置き換えられることによって正しくエンコードされています。 dish の値を指定するときに [URI parameter] をチェックしていなければ、URL は http://acme/recipe?name=Mac&cheese となり、この場合は正しく処理されません。この URI には Mac の後に & があるため、Web サーバーでは cheese が別のクエリパラメータとして扱われるからです。

補間変数がパスの URL の一部ではない場合、[URI parameter] チェックボックスのチェックをはずしたままにします。


[Check certificates] チェックボックスは、以下のどちらかのシナリオに該当する場合にチェックします。

  • サービスが SSL/TLS (https で始まる URL) を使用していて、そのサービスが提示する証明書が、Denodo Platform に属する Java Virtual Machine (JVM) によって信頼されている証明機関 (CA) から発行されたものであることを Virtual DataPort で検証する場合。この検証は、このサービスとのコネクションを確立するたびに実行されます。

    このサービスが提示する証明書が信頼できる CA によって発行されたものではない場合、または自己署名された証明書ではあるものの、Virtual DataPort で検証を必要とする場合、JVM の信頼できる証明書のリストにその証明書をインポートします。その手順については、『インストールガイド』の「 Importing the Certificates of Data Sources (SSL Connections) 」を参照してください。

  • また、サービスが SSL クライアント認証を必要とする場合も、このチェックボックスをチェックします。

このチェックボックスのチェックをはずすと、以下の 2 つの影響があります。

  1. Virtual DataPort では、サービスから提示された証明書を、その発行元を確認せずに受け入れます。

  2. サービスが SSL クライアント認証を要求する場合、すべてのリクエストは失敗します。

[Proxy] タブでは、このデータソースのプロキシ構成を設定できるほか、Virtual DataPort サーバーの [Default] 構成を使用することもできます (「 HTTP プロキシのデフォルト構成 」を参照)。

HTTP パスでの認証

HTTP コネクションでは、以下の認証方法がサポートされています。

[Pass-through session credentials] チェックボックス ([Basic]、[Digest]、[NTLM]、および [SPNEGO (Kerberos)] の各認証方法で選択可能) をチェックしている場合、このデータソースを扱うクエリをクライアントが実行する際に、サービスにリクエストを送信するために使用される資格情報は、[Login] フィールドと [Password] フィールドの資格情報ではなく、クエリを実行したユーザーの資格情報です。このオプションをチェックしている場合、[Login] フィールドと [Password] フィールドの資格情報が使用されるのは、このデータソースから基本ビューを作成し、サービスにリクエストを送信して、URL の出力を分析する場合のみです。

認証方法が [SPNEGO (Kerberos)] で、[Pass-through session credentials] をチェックしている場合の Virtual DataPort の動作の詳細については、「 SPNEGO (Kerberos) 」を参照してください。

警告

パススルー資格情報が有効なデータソースを使用するビューに対してキャッシュを有効にする場合は注意が必要です。このような場合に発生することが考えられる問題については、付録「 データソースをパススルー資格情報を使用して構成する場合の検討事項 」を参照してください。

相互認証

SSL/TLS 通信 (たとえば https を使用) を確立する際、クライアント (この場合は Denodo) は、サービスが使用する証明書が証明機関 (CA) によって署名されているかどうかを確認することによって、サービスの身元を確認します。「相互認証」 (別名「双方向 SSL/TLS」) を使用する場合でも、クライアント (この場合は Denodo サーバー) は、認証に証明書を使用し、ユーザー名とパスワードや OAuth トークンは使用しません。

この機能を使用するには、サービスにアクセスするための秘密キーを保持するキーストアファイルが必要です。このファイルは、PKCS#12 形式または Java キーストア (JKS) 形式とする必要があります。

HTTP ルートでこの認証方法を有効にするには、以下の手順に従います。

  1. [Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。

  2. [Authentication] リストで [Mutual (two-way SSL)] を選択します。

  3. [Certificate password] に、秘密キーを保持するファイルのパスワードを入力します。

  4. [Load certificate] をクリックして、秘密キーを保持するファイルを選択します。

    証明書が有効であれば、証明書の発行者、証明書の有効期限などが表示されます。

注釈

サービスから送信された証明書を Virtual DataPort で検証する場合は、[Configuration] タブで [Check certificates] を選択します。この検証に適合するには、このサービスが使用する証明書が証明機関 (CA) によって署名されている必要があります。証明書に CA による署名がない場合は、その証明書を Denodo サーバーの TrustStore にインポートする必要があります。そのようにしないと通信が失敗します。

Mutual Authentication wizard

相互認証ウィザード

OAuth 認証

OAuth は、サードパーティアプリケーション (この場合は Virtual DataPort) がリソース所有者の代わりにサーバー上のリソースにアクセスできるようにする認可フレームワークです。

その主な利点は、サードパーティアプリケーションから各自のデータへのアクセスを認可するために、各自のユーザー名とパスワードをサードパーティアプリケーションに伝達する必要がないことにあります。

以下のサブセクションでは、OAuth 1.0a 認証または OAuth 2.0 認証を使用してサービスに接続するうえで必要な資格情報を容易に取得できるようにするウィザードの使用方法について説明します。

注釈

Virtual DataPort でデータソースを作成する前に、アクセス先のサービスに Virtual DataPort をアプリケーションとして登録する必要があります。

注釈

OAuth 認証を通じて利用する同一サービスからデータを取得するビューが複数必要な場合、そのサービスに作成するデータソースを 1 つのみとして、そこからすべてのビューを作成することが推奨されます。何らかの時点で OAuth 資格情報が変更されても、1 つのデータソースの資格情報を変更するだけで済むからです。このようにするには、URL に補間変数を使用したデータソースを作成します (http://service.com/@OBJECT_TYPE/ <http://service.com/@OBJECT_TYPE/>)。

OAuth 1.0a

ここでは、OAuth 1.0a 認証を使用するサービスからデータを取得するように「HTTP クライアント」ルートを構成する手順について説明します。管理ツールには、OAuth 1.0a 資格情報を容易に取得できるようにする OAuth 1.0a 資格情報ウィザードが用意されています。

以下の手順に従います。

  1. [Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。

  2. [Authentication] リストで [OAuth 1.0a] を選択します。

  3. サービスから提供される クライアント ID と クライアント共有シークレット を入力します。

  4. 署名方法を選択します。最も広く使用されている署名は HMAC-SHA1 なので、通常はそれを選択することが適切です。

  5. アクセストークン と アクセストークンシークレット をすでに入手している場合、下にあるボックスにそれらを入力して [Ok] をクリックします。

    これらのトークンを入手していない場合、[launch the OAuth 1.0a credentials...] をクリックして、トークン取得を支援するウィザードを開きます。

OAuth 1.0a credentials wizard

OAuth 1.0a 資格情報ウィザード

  1. [Temporary credential request URL]、[Resource owner authorization URL]、および [Token request URL] に適切な値を入力します。

    アクセス先のサービスのドキュメントには、これらの詳細が記載されている必要があります。

  2. [Callback URL] を選択します。ウィザードの手順 2 に進むと、ブラウザで URL を開く必要があります。この URL をブラウザで指定すると、Virtual DataPort によるデータへのアクセスを認可するためのページが表示されます。先に進むと 確認コード を取得できます。Virtual DataPort では、この確認コードを使用して HTTP リクエストをサービスに送信します。その応答に アクセストークン と アクセストークンシークレット が含まれています。

    [Callback URL] では、サービスから 確認コード を返す方法を指定します。

    注釈

    サービスによっては、オプションを自由に選択できないことがあります。また、特定のリダイレクト URL の使用が求められる場合もあれば、oob などの特定のオプションのみを使用できる場合もあります。

    1. oob: このオプションを選択すると、認証プロセスの後でブラウザに 確認コード を表示することが、ウィザードからサービスに要求されます。

    2. 2 番目または 3 番目のオプションを選択すると、それぞれの URL にブラウザがリダイレクトされ、そこにパラメータ code が追加されます。このパラメータの値が 確認コード です。

      デフォルトの URL (http://localhost:9090/oauth/1.0a/callbackURL.jsp) は、Denodo Platform に組み込まれている Apache Tomcat に存在する JSP を 参照 しています。そこでは、パラメータ code の値がボックスに表示されるので、容易にコピーできます。

      別のコールバック URL を指定する必要がある場合、その URL からパラメータ code の値を手動で抽出する必要があります。

  3. [Generate the authorization URL] をクリックします。Virtual DataPort から 一時トークン が要求され、それを使用して 認可 URL が生成されます。

  4. [Open URL] をクリックします。ブラウザを起動していない場合は、URL をコピーして手動でブラウザを開きます。

    この URL で、サービスからデータを取得する操作を Virtual DataPort サーバーに認可する必要があります。

  5. データへのアクセスを Virtual DataPort に認可すると、サービスから 確認コード が返されます。このコードを [Paste the verification code] テキストフィールドに入力します。

    [Callback URL] で [oob] を選択していた場合は、確認コードの値を入力する必要があります。デフォルトの URL を選択していた場合は、確認コードをコピーしてこのボックスに貼り付けることができます。

  6. [Obtain the OAuth 1.0a credentials] をクリックします。Virtual DataPort サーバーは、入力されたすべての詳細情報と 確認コード を使用して、OAuth トークンを要求します。

  7. [Ok] をクリックしてウィザードを閉じます。

    ウィザードによって [OAuth access token] と [OAuth access token secret] の各テキスト領域に値が入力されます。

  1. [Ok] をクリックして [Edit HTTP Connection] ダイアログを閉じます。つづいて、[Save] をクリックするとデータソースが作成されます。

このウィザードを単独で使用するには、管理ツールの [Tools] > [OAuth credentials wizards] メニューで [OAuth 1.0a wizard] をクリックします。

OAuth 資格情報を入力パラメータとするカスタムラッパーを使用する場合は、このウィザードを使用する必要があります。

OAuth 2.0

ここでは、OAuth 2.0 認証を使用するサービスからデータを取得するように「HTTP クライアント」ルートを構成する手順について説明します。管理ツールには、OAuth 2.0 資格情報を容易に取得できるようにする OAuth 2.0 資格情報ウィザードが用意されています。

管理ツールには、OAuth 2.0 資格情報を容易に取得できるようにする OAuth 2.0 資格情報ウィザードが用意されています。

Configuring OAuth 2.0 authentication for a data source

データソースでの OAuth 2.0 認証の構成

以下の手順に従います。

  1. [Edit HTTP connection] ダイアログで [Authentication] タブをクリックします。

  2. [Authentication] リストで [OAuth 2.0] を選択します。

  3. [Authentication grant] で適切なオプションを選択します。

    1. Authorization code grant: サービスに登録しているユーザー名とパスワードを入力する必要がないことから、これが最も安全なオプションです。取得する必要があるのは「アクセストークン」と「更新トークン」のみであり、どちらもこのダイアログのウィザードを使用して取得できます。この付与方法には、(サービスにもよりますが) 通常はこのデータソースで実行できる操作を制限できるという利点もあります (データへの読み込みアクセスのみ許可するなど)。また、アクセストークンや更新トークンが侵害された場合、このサービスのユーザーアカウントのパスワードを変更しなくても、それらのトークンを無効にすることができます。

    2. [Resource owner password credentials]

    3. [Client credentials grant]

    この 2 番目と 3 番目のオプションは、アクセストークンも更新トークンも取得する必要がないので、1 番目のオプションより構成が簡単ですが、1 番目のオプションにあるような利点は得られません。

    使用可能なオプションについては、このサービスのドキュメントを参照してください。

    これらのオプションの詳細については「 RFC 6749 - The OAuth 2.0 Authorization Framework 」を参照してください。

  4. [Client identifier] と [Client secret] に、サービスから提供された情報を入力します。

  5. [Resource owner password credentials] を選択した場合のみ、[User identifier] と [User password] を入力します。

  6. [Authentication method used by the authorization servers] のいずれかのオプションを選択します。これは、Virtual DataPort から新しい OAuth アクセストークンを要求する際にユーザーの資格情報をサービスに送信する方法を制御します。以下のオプションがあります。

    1. Include the client credentials in the body of the request: リクエスト本文のパラメータ client_id および client_secret として資格情報を追加します。

    2. Send client credentials using the HTTP Basic authentication scheme: HTTP リクエストの Authentication ヘッダーで資格情報を送信します。

    これら 2 つのオプションについては、OAuth 2.0 仕様 (RFC 6749 - The OAuth 2.0 Authorization Framework) の「2.3.1. Client Password」を参照してください。

    1 番目のオプションのほうが広く使用されていますが、サービスによっては 2 番目のオプションを必要とするものがあります。

  1. すでに OAuth アクセストークンを入手している場合、それを [Access token] ボックスに入力し、[Request signing method] で適切なオプションを選択します。更新トークンも入手している場合は、それを [Refresh token] ボックスに入力します。トークンのエンドポイント URL の値を [Token endpoint URL] に入力し、アクセストークンの有効期間 (秒数) がわかっている場合はその値も入力します。

    アクセストークンが未入手で、データソースにアクセストークンを保存しておくのではなく、実行時にアクセストークンを指定する場合は、[Access token value is an interpolation variable] をチェックして、その下のボックスにトークンの補間変数の名前を入力します。実行時には、このデータソースの基本ビューに対して実行するクエリで、この補間変数の値を指定する必要があります。この値が、データソースへの接続で使用するアクセストークンになります。OAuth 2.0 認証を要求するソースであっても、その仕様を全面的には実装していない場合に、このオプションが効果的です。この場合は、このトークンを取得して基本ビューに渡すストアドプロシージャを開発するという方法もあります。

    アクセストークンが未入手で、データソースからトークンを入手する場合は、[launch the OAuth 2.0 credentials...] をクリックして、トークンを容易に入手できるようにするウィザードを開きます。

OAuth 2.0 credentials wizard

OAuth 2.0 資格情報ウィザード

  1. [Token endpoint URL] を入力します。

  2. [Authorization code grant] を選択した場合のみ、[Authorization server URL] を入力します。

  3. [Authorization code grant] を選択した場合のみ、[Redirect URI] を選択します。このウィザードの手順 2 に進むと、ブラウザで URL を開く必要があります。この URL をブラウザで指定すると、Virtual DataPort によるデータへのアクセスを認可するためのページが表示されます。

    先に進むと、サービスによって [Redirect URI] の URI にブラウザがリダイレクトされ、そこにいくつかのパラメータが追加されます。Virtual DataPort では、これらのパラメータの値を使用して、HTTP リクエストをサービスに送信します。その応答に アクセストークン が含まれるほか、 更新トークン が付随することもあります。

  4. 追加するスコープごとに image5 ボタンをクリックして、その名前を入力します。

    スコープは、サービスで定義される「権限」であり、アプリケーションが要求できるデータを制御します。

    たとえば、Twitter ではさまざまなスコープが定義されています。このウィザードで要求したスコープによっては、Virtual DataPort でユーザーのツイートを取得できますが、ユーザーの代わりに新しいツイートを送信することはできません。

前のダイアログで [Authorization code grant] を選択している場合は、この後の手順の e. から h. までのみを実行します。

  1. 通常、[Set the "state" request] パラメータは選択したままでかまいません。ただし、OAuth 資格情報の取得プロセスが失敗した場合は、このパラメータを選択することがサービスで許可されていることを確認します。

  2. [Generate the authorization URL] をクリックします。

    Virtual DataPort によって、指定したすべてのパラメータを使用して URL が生成されます。

  3. [Open URL] をクリックします。

    ブラウザを起動していない場合は、URL をコピーして手動でブラウザを開きます。

    この URL で、サービスからデータを取得する操作を Virtual DataPort サーバーに認可する必要があります。

  4. アプリケーションを認可すると、サービスによってリダイレクトされます。このリダイレクト先の URL を手順 3 のテキストフィールドに貼り付けます。

  5. [Obtain the OAuth 2.0 credentials] をクリックします。

    Virtual DataPort サーバーから、入力したすべての詳細情報、および前の手順で貼り付けた URL のパラメータを使用して OAuth 資格情報が要求されます。

  6. [Ok] をクリックしてウィザードを閉じます。

    ウィザードによって、サービスから返された情報がテキスト領域とテキストフィールドに入力されます。

    すべてのサービスが 更新トークン を提供するわけではないので、このテキスト領域が空になることも考えられます。

  1. [Request signing method] を選択します。Virtual DataPort は、 アクセストークン を使用して各リクエストに署名する必要があります。通常は、すべての OAuth サービスで、["Authorization" request header] を使用できます。これは、特殊な HTTP ヘッダーをリクエストに追加する方法です。この方法をサポートしていないサービスについては、以下に示すように、標準で定義されている他の方法を選択できます。

    1. Form-encoded body parameter: リクエストの本文でトークンを送信します (HTTP の POST リクエストでのみ使用可能)。

    2. URL query parameter ("access_token"): URL のパラメータ access_token でトークンを送信します。

    3. URL custom query parameter: "access_token" とは別の名前のクエリパラメータとしてトークンを追加します。

  2. アクセストークンが未入手で、データソースにアクセストークンを保存しておくのではなく、実行時にアクセストークンを指定する場合は、[Refresh token value is an interpolation variable] をチェックして、その下のボックスにトークンの補間変数の名前を入力します。実行時には、このデータソースの基本ビューに対して実行するクエリで、この補間変数の値を指定する必要があります。必要に応じ、この値を使用してアクセストークンが更新されます。OAuth 2.0 認証を要求するソースであっても、その仕様を全面的には実装していない場合に、このオプションが効果的です。この場合は、このトークンを取得して基本ビューに渡すストアドプロシージャを開発するという方法もあります。

  3. OAuth 2.0 認証を使用する REST API の中には、クライアントによる追加のパラメータの送信が必要になるものがあります。[Extra parameters of the refresh token requests] をクリックしてパラメータを追加してください。Denodo によって、パラメータが以下のどちらかのリクエストに追加されます。

    1. アクセストークンを初めて取得するリクエストで送信。[OAuth Credentials Wizard] で [Obtain the OAuth 2.0 credentials] をクリックしたときに生成される URL にパラメータを追加します。

    2. データソースがアクセストークンを更新するリクエストで送信。現在のアクセストークンが期限切れとなった場合、データソースは更新トークンを使用して新しいアクセストークンを取得する必要があります。

    たとえば、クラウド上の Microsoft サービスに OAuth 2.0 認証を使用して接続する場合、パラメータ resource を追加する必要があるでしょう。その値は接続先アプリケーションの ID とします。これは、この API による要件です。

    このダイアログで、パラメータの値の横にある [Encrypted] チェックボックスをチェックした場合、データソースはこの値を暗号化した状態で保管します。

  4. [Ok] をクリックして [Edit HTTP Connection] ダイアログを閉じます。つづいて、[Save] をクリックするとデータソースが作成されます。

通常、OAuth 2.0 資格情報ウィザードを起動するには、[Create JSON data source] ダイアログまたは [Create XML data source] ダイアログを使用します。ただし、管理ツールの [Tools] > [OAuth credentials wizards] メニューで [OAuth 2.0 wizard] をクリックすることで、このウィザードを単独で使用することもできます。

OAuth 資格情報を入力パラメータとするカスタムラッパーを使用する場合は、このウィザードを使用する必要があります。

SPNEGO (Kerberos)

データソースの認証方法が SPNEGO (Kerberos) である場合、Virtual DataPort では Kerberos チケットを使用して、サービスに送信する HTTP リクエストに認証ヘッダーを追加します。

[Pass-through session credentials] チェックボックスをチェックしていない場合、Virtual DataPort サーバーでは、[Login] ボックスと [Password] ボックスの値を使用してキー配布センター (KDC) に接続し、Kerberos サービスチケットを要求します。

[Pass-through session credentials] チェックボックスをチェックしている場合、Virtual DataPort は、このデータソースを扱うクエリを実行するクライアントの代わりに、クライアントの資格情報を使用して Kerberos サービスチケットを取得します。Virtual DataPort の正確な動作は、クライアントが使用する認証方法によって次のように異なります。

  1. クライアントが Kerberos 認証を使用して Virtual DataPort サーバーに接続する場合: Virtual DataPort サーバーは、クエリを実行するクライアントの代わりに、このクライアントが Virtual DataPort サーバーとのコネクションを開いたときに取得した TGT (ticket-granting ticket) を使用してキー配布センター (KDC) にサービスチケットを要求します。取得したサービスチケットを使用して、サービスに送信する HTTP リクエストに認証ヘッダーを追加します。

  2. クライアントが標準の認証を使用して Virtual DataPort サーバーに接続する場合: Virtual DataPort サーバーは、クエリを実行するクライアントのユーザー名とパスワードを使用して KDC にサービスチケットを要求します。そのときは、以下の点が考慮されます。

    1. Virtual DataPort サーバーが Windows で動作していても、そのホストが Windows ドメインに属していない場合は、『インストールガイド』の「 <no title> 」の説明に従って、java.security.krb5.realm と java.security.krb5.kdc の 2 つのシステムプロパティを定義します。

    2. Virtual DataPort サーバーが Linux で動作している場合は、システムに krb5.ini ファイルが必要です。このファイルがシステムに存在するかどうかを確認する手順の詳細については、『インストールガイド』の「 Kerberos 認証用の krb5 ファイルの提供 」を参照してください。