USER MANUALS

Web サービスの認証

REST または SOAP Web サービスへのアクセスは、その認証方法を構成することによって保護できます。REST と SOAP Web サービスは、使用可能な認証方法は同じですが、SOAP Web サービスは Web Services Security protocol (WS-Security) もサポートしています。

サービスの認証方法を選択することに加えて、Denodo Web コンテナーで SSL/TLS を有効にして、Web サービスが転送するデータを暗号化することを検討してください。その方法については、『インストールガイド』の「 組み込み Apache Tomcat での HTTPS の有効化 」を参照してください。

SOAP および REST Web サービスでサポートされている認証方法

認証

方法

SOAP Web サービスで使用可能

REST Web サービスで使用可能

Web サービスの資格情報を使用

Web サービスのクライアントの資格情報を使用

HTTP Basic

dot

dot

dot

HTTP Basic with VDP

dot

dot

dot

HTTP Digest

dot

dot

dot

HTTP SPNEGO (Kerberos)

dot

dot

dot

OAuth 2.0 および OpenID

dot

dot

dot

SAML 2.0

dot

dot

WSS Basic

dot

dot

WSS Basic with VDP

dot

dot

WSS Digest

dot

dot

REST Web サービスは、認証方法に関係なく、ユーザーの偽装 (下記の「 ユーザーの偽装 」を参照) をサポートします。

HTTP Basic

HTTP Basic は、プレーンテキストとして渡された資格情報を使用する基本 HTTP 認証 [HTTP-AUTH] です。

すべてのユーザーは、このサービスにアクセスするための資格情報として、Login フィールドと Password フィールドの値を使用します。

HTTP Basic with VDP

HTTP Basic with VDP は、Virtual DataPort ユーザーの資格情報を使用する基本 HTTP 認証です。つまり、Web サービスはそのクライアントが使用する資格情報を使用して Virtual DataPort に接続します。

[Accepted user(s)] リスト (ユーザー名のコンマ区切りリスト) にユーザー名が含まれるユーザーのみがサービスにアクセスできます。このリストが空の場合、Web サービスはすべての Virtual DataPort ユーザーを受け入れます。

他の認証方法とは異なり、この方法では、公開されているビューにアクセスする権限をユーザーに付与する必要があります。

HTTP Digest

HTTP Digest アクセス認証。「 HTTP Authentication: Basic and Digest Access Authentication. 」を参照してください。

HTTP SPNEGO (Kerberos)

Kerberos-SPNEGO 認証を機能させるには、サービスにリクエストを送信するクライアントが Virtual DataPort サーバーと同じドメインにログインする必要があります。

この認証方法は、Virtual DataPort サーバーで Kerberos 認証が有効な場合にのみ使用できます。これを有効にする方法については、「 Kerberos 認証 」で説明しています。

Kerberos-SPNEGO を使用するように Internet Explorer と Mozilla Firefox を構成する方法については、 この記事 の「Client Configuration」で説明しています。Google Chrome の場合は特別な構成は必要ありません。

この認証を使用するサービスにブラウザーから接続する場合、ユーザーが資格情報を入力する必要はなく、ブラウザーがシステムから Kerberos チケットを取得して、リクエストと一緒に送信します。ブラウザーからユーザーの資格情報をリクエストされた場合、それはブラウザーが Kerberos 認証を使用するように正しく構成されていないか、または認証エラーが発生したことを意味します。

OAuth 2.0 および OpenID

Web サービスでこれらの認証方法を使用するには、最初に Virtual DataPort サーバー上で OAuth 認証を有効にする必要があります。この方法については、「 OAuth 認証 」で説明しています。OAuth 2.0 をグローバルにセットアップしたら、それを REST Web サービスで有効にできます。

OpenID は、OAuth 2.0 を拡張したものです。Denodo は、JSON Web Tokens (JWT) を受け入れるように構成されている場合、つまり、サーバーの OAuth 2.0 構成で [Use JWT] オプションが選択されている場合に OpenID をサポートします。

OAuth 認証を使用する REST Web サービスでは、 パススルー認証 を使用するデータソースからデータを取得するビューを公開しないでください。これらのビューに対するリクエストは失敗します。なぜなら、アプリケーションが OAuth 認証を使用してリクエストを送信する際、ユーザーおよびパスワードは送信されないからです。代わりに OAuth アクセストークン が送信されますが、OAuth アクセストークンからユーザーとパスワードを取得してデータソースに渡すことはできません。

SAML 2.0

Virtual DataPort から公開された REST Web サービスは、SAML (Security Assertion Markup Language) 2.0 認証、特に「HTTP POST バインド」で ID プロバイダーによって開始される「Web ブラウザー SSO プロファイル」をサポートします。

Denodo Web サービスはステートレスであり、セッションをサポートしないため、クライアントアプリケーションはリクエストのたびに新しいアサーションを取得する必要があります。

重要

SAML 認証を使用する REST Web サービスを公開する前に、[Server configuration] ダイアログでサーバーのグローバル SAML 設定をセットアップする必要があります。その方法については、「 SAML 認証 」で説明しています。SAML をグローバルにセットアップしたら、それを REST Web サービスで有効にできます。

実行時に、SAML 認証を使用する REST Web サービスにクライアントがリクエストを送信すると、サーバーは SAML プロトコルを使用してユーザーを認証します。

次に、[Server configuration] ダイアログ > [Server authentication] > [SAML] の LDAP 設定を使用して、ユーザーのロールを取得します。取得したロールによって、ユーザーにクエリの実行を許可するかどうかを決定します。

認証方法として SAML 2.0 を選択する場合、[Service provider ID] に値を入力します。これは、ID プロバイダー (IdP) でこの Web サービスをサービスプロバイダーとして識別するための文字列です。

ブラウザーから、およびクライアントアプリケーションからプログラムによって SAML 認証を使用するサービスを呼び出す方法については、「 SAML 認証を使用して Web サービスを呼び出す方法 」で説明しています。

SAML 認証を使用する REST Web サービスでは、 パススルー認証 を使用するデータソースからデータを取得するビューを公開しないでください。これらのビューに対するリクエストは失敗します。なぜなら、アプリケーションが SAML 認証を使用してリクエストを送信する際、ユーザーおよびパスワードは送信されないからです。代わりに SAML アサーション が送信されますが、SAML アサーションからユーザーとパスワードを取得してデータソースに渡すことはできません。

ユーザーの偽装

REST Web サービスは、選択されている認証方法に関係なく、ユーザーの偽装をサポートします。つまり、クライアントアプリケーションは、その通常の資格情報を使用して REST Web サービスに接続して、別のユーザーの代わりにリクエストを実行できます。

ユーザーを偽装するには、以下の条件を満たす必要があります。

  1. Web サービスへのリクエストに HTTP ヘッダー Impersonate-User を含める必要があります。このヘッダーの値は、偽装するユーザーアカウントです。

  2. ロール impersonator を持つユーザーアカウントで Web サービスがデプロイされている必要があります。

    Administration Tool から Web サービスをデプロイする場合、このロールを持つユーザーが実行するか、または [Deploy Web Service] ダイアログ ([Deploy] をクリックすると表示されるダイアログ) で、このロールを持つユーザーを選択する必要があります。

    プログラムから (つまり DEPLOY WEBSERVICE ステートメントを使用して) Web サービスをデプロイする場合、パラメータ LOGIN の値はこのロールを持つユーザーである必要があります。

例

以下のことを想定します。

  • Virtual DataPort で、名前が「denodo_svc_project_1」で、ロール「impersonator」を持つサービスアカウントを作成します。

  • 「HTTP Basic with VDP」認証を使用する REST Web サービスを作成します。

  • サービスをデプロイするダイアログでアカウント「denodo_svc_project_1」を選択して、そのパスワードを入力します。

この Web サービスに接続するクライアントアプリケーションは、以下のことを実行する必要があります。

  1. ユーザー「denodo_svc_project_1」の資格情報を提供します。リクエストが別のユーザーを偽装しているかどうかに関係なく、サービスは同じ方法で資格情報を検証します。

  2. 任意で、クライアントアプリケーションが別のユーザーを偽装する場合、HTTP ヘッダー Impersonate-User: <user to impersonate> をリクエストに追加する必要があります。以下に例を示します。

    Impersonate-User: jsmith

    リクエストにこのヘッダーが存在しない場合、サービスは通常どおりに動作するので、リクエストは「denodo_svc_project_1」に付与されている権限で実行されます。

このヘッダーが付いたリクエストを受信したサービスは、以下のことを実行します。

  1. ユーザー「denodo_svc_project_1」として Virtual DataPort とのコネクションを開くか、または Web サービスのコネクションプールにあるコネクションを再利用します。

  2. このコネクションで、ユーザー「jsmith」の代わりにセッションを作成してクエリを実行します。

  3. セッションを終了します (コネクションは開いたままです)。

ユーザーの偽装には、以下の意味があります。

  • ユーザー「denodo_svc_project_1」は、Web サービスが属するデータベースに対する CONNECT 権限を持つ必要がありますが、他の権限は必要ありません。

  • ユーザー「jsmith」は、このリクエストを実行するための適切な権限が必要です。つまり、実行エンジンは、ユーザー「jsmith」に付与されている権限や行の制限などを適用します。

  • Denodo Monitoring Tool のデータや他の監視データには、ユーザー「denodo_svc_project_1」が開いたコネクションが記録され、クエリはユーザー「jsmith」によって実行されます。

重要

ロール「impersonator」を持つユーザーは、認証を使用しない Web サービスを公開しては なりません 。この Web サービスの存在を知っていれば、資格情報を一切知らなくても、このヘッダーと偽装するユーザー名を追加するだけで、誰でも任意のユーザーを偽装することができます。

注

  • REST Web サービスからユーザーを偽装している場合、パススルーセッション資格情報を使用するデータソースに対してクエリを実行すると失敗します。なぜなら、Web サービスも実行エンジンもユーザーのパスワードを知らないからです。

  • デフォルト構成では、REST Web サービスは Virtual DataPort へのコネクションのプールを作成して、リクエストごとにコネクションを開かなくても済むようにします。ユーザーを偽装した場合、このプールは引き続き使用されます。なぜなら、サービスは既存のコネクション上にセッションを作成するからです。

  • ユーザーを偽装する機能は REST Web サービスで利用できます。SOAP Web サービスや RESTful Web サービスでは利用できません。

Add feedback