OAuth 認証¶
Denodo は、認証を必要とする Web サービス REST および SOAP を公開できます。サポートされている認証プロトコルの 1 つは OAuth 2.0 です。
OAuth 2.0 サービスにリクエストを送信するアプリケーションは、リクエストに アクセストークン を含める必要があります。このアクセストークンは、アプリケーションが 認可サーバー から取得する必要があります。 標準 OAuth 2.0 では、リソースサーバー (この場合は Denodo サーバー) がアクセストークンを検証してそれらのトークンからメタ情報を取得するためのプロトコルを定義しません。その溝を埋めるために、コミュニティによっていくつかのアプローチが考案されています。Denodo はそのうち次の 2 つをサポートしています。
OAuth 2.0 クライアントの認証および認可付与のための JSON Web Token (JWT) プロファイル 。このアプローチでは、アプリケーションによって送信されたアクセストークンに、リクエストの実行に必要なアクセス権を付与するために検証する必要のあるシグネチャが含まれています。トークンの検証後、トークンで定義された「スコープ」が取得されます。
OAuth 2.0 トークンイントロスペクション 。この方法では、リソースサーバー (この場合は Denodo サーバー) が、クライアントアプリケーションによって送信されたアクセストークンを、 イントロスペクションエンドポイント に送信します。このエンドポイントは、アクセストークンが有効かどうかを示す JSON ドキュメントと、トークンの「スコープ」を含む、トークンに関するメタ情報を返します。OAuth 2.0 認証を使用するように構成された Denodo Web サービスにクライアントがリクエストを送信するたびに、Denodo サーバーはリクエストをこのデータソースに送信します。
どちらのアプローチも目的は同じです。
アクセストークンが有効であり、期限が切れていないかどうかを確認する。
トークンに含まれる「スコープ」の名前を取得する。トークンのスコープは、標準に従い、 スペースで区切られた、大文字と小文字を区別する文字列です。この文字列は、認可サーバーによって定義されます。
Denodo の場合、スコープはロールの名前です。Denodo はトークンのスコープを取得すると、同じ名前のロールを取得し、これらのロールに付与された権限でリクエストを実行します。
Denodo では、同名のロールがないスコープを無視します。
トークンのいずれかのスコープと同名のロールがない場合、リクエストは失敗します。
Virtual DataPort ユーザーのロールの作成¶
Web サービスで OAuth 認証を使用するには、以下のいずれかを実行する必要があります。
アクセストークンに含まれるスコープと同名の、適切なロールを作成します。
または、スコープが Denodo で定義済みのロールと同名になるように、組織の ID マネージャーを構成します。
ロールには、他の権限に加え、「接続」権限を付与する必要があります。
上記を終えたら、次のセクションに進み、Denodo サーバーの構成方法を確認してください。