OAuth 認証¶

Denodo では、ユーザーの認証と認可に OAuth 2.0 プロトコルをサポートしています。OAuth はオープン標準のプロトコルであり、これを使用することで、クライアントアプリケーションがユーザーアカウントのパスワードを送信することなく、Denodo にアクセスできるようになります。Denodo では、次の場合に OAuth をサポートしています。

Virtual DataPort の JDBC インターフェイスと ODBC インターフェイス。つまり、Denodo JDBC ドライバーまたは Denodo ODBC ドライバーを使って Virtual DataPort に接続するクライアントアプリケーションが OAuth 認証を使用できます。
Virtual DataPort から公開されている REST および SOAP の Web サービス。クライアントアプリケーションで OAuth 認証の使用が必須となるように、これらの Web サービスを構成することができます。

Denodo JDBC ドライバーでは、ユーザーの認証と認可に OAuth 2.0 プロトコルをサポートしています。OAuth はオープン標準のプロトコルであり、これを使用することで、クライアントアプリケーションがユーザーアカウントのパスワードを送信することなく、Denodo にアクセスできるようになります。

OAuth 2.0 サービス (この場合は Virtual DataPort) にリクエストを送信するアプリケーションは、リクエストに アクセストークン を入れる必要があります。このアクセストークンは、アプリケーションが 認可サーバー から取得する必要があります。標準 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 では、同名のロールがないスコープを無視します。

トークンのいずれかのスコープと同名のロールがない場合、リクエストは失敗します。

OAuth 認証による REST および SOAP の Web サービスへの接続¶

Virtual DataPort で OAuth 認証を有効にすると、Virtual DataPort の REST および SOAP の Web サービスで OAuth 認証が必須となるように構成できます。その場合、これらのサービスに接続するクライアントアプリケーションでは、次のことを行う必要があります。

ID プロバイダーからアクセストークンを取得します。
このトークンを、次のようにリクエストの HTTP ヘッダー「Bearer」に付加します。

GET /server/customer360/invoice
Host: https://denodo-server.acme.com
Authorization: Bearer ey1QiOiJsIiJZnl0aESUzI1NiIKVng1dCI6Ikci5HVEZ2ZELCJhJ0eXAiObGstV1Q...

JDBC および ODBC を使用した OAuth 認証での接続¶

Virtual DataPort で OAuth 認証を有効にすると、クライアントアプリケーションは、Denodo JDBC ドライバーまたは Denodo ODBC ドライバーを使用して OAuth 認証で Virtual DataPort に接続できます。

Denodo では、OAuth を使用して Denodo に接続する経路を 2 つ用意しています。どちらを選ぶかによって、接続の構成方法が異なります。

経路 #1: クライアントアプリケーションが OAuth トークンを提供する

クライアントアプリケーションは、OAuth アクセストークンを取得し、それをドライバーに渡します。その後、ドライバーはユーザー/パスワードの代わりにこのトークンを使用して、Virtual DataPort に接続します。

この経路は、Virtual DataPort に接続するためのアクセストークンを取得する機能を持つクライアントアプリケーションで使用することを想定したものです。このクライアントアプリケーションは、このアクセストークンを自身のため、またはアプリケーションのエンドユーザーのために取得できます。

経路 #2: ドライバーがユーザーの代わりに OAuth トークンを取得する

クライアントアプリケーションに OAuth トークンを取得する機能がない場合、組織の ID プロバイダーが Resource Owner Password Credentials という OAuth フローをサポートしていれば、ドライバーがアプリケーションに代わってトークンを取得することができます。

この場合、ID プロバイダーに関する情報を使って接続を構成できます。その情報は、ID プロバイダーにトークンをリクエストするための URL、ID プロバイダーに登録したアプリケーションのクライアント ID とクライアントシークレットなどです。

JDBC で接続する場合は、この情報をドライバープロパティに設定します。

ODBC で接続する場合は、この情報を DSN に設定するか、DSN のない接続の場合は接続プロパティに設定します。

この場合、クライアントアプリケーションが接続を開こうとするとき、ドライバーが ID プロバイダーに対して OAuth トークンをリクエストし、そのトークンを使って接続を確立します。

PostgreSQL の ODBC ドライバーを使って Virtual DataPort に接続するクライアントアプリケーションは OAuth 認証を使用できません。この機能は、PostgreSQL ODBC ドライバーではなく、Denodo ODBC ドライバーに含まれているためです。

その他の情報

JDBC ドライバーを使用して OAuth で接続する方法は、「 OAuth 認証を使用した Virtual DataPort への接続」(開発者ガイド) を参照してください。どちらの経路でも定義する必要のあるパラメータを説明しています。

ODBC ドライバーを使って接続する場合は、次を参照してください。

Windows での ODBC ドライバーの構成 (開発者ガイド): Windows で ODBC DSN とクライアントアプリケーションを作成する場合
Linux とその他の UNIX での ODBC ドライバーの構成 (開発者ガイド): Linux で ODBC DSN とクライアントアプリケーションを作成する場合
DSN レスコネクションの作成 (開発者ガイド): DSN のない接続を作成する場合

その他の考慮すべき事項

OAuth 認証を有効にしても、他の認証メカニズムが無効になることはありません。つまり、Kerberos 認証も有効にすると、クライアントアプリケーションは接続する際に、ユーザーとパスワードを使用することも、OAuth を使用することも、Kerberos を使用することもできます。

Virtual DataPort ユーザーのロールの作成¶

ユーザーが OAuth 認証で Virtual DataPort に接続できるようにするには、次のことを行う必要があります。

Virtual DataPort にロールを作成し、それに適切な権限を付与します。

必要なユーザーのタイプごとにロールを作成します。たとえば、Denodo の管理者、プロジェクト X の管理者、プロジェクト Y の管理者、開発者などのタイプがあります。Denodo の管理者のロールには、ロール「serveradmin」を付与し、プロジェクト X の管理者のロールには、このプロジェクトのデータベースに対する ADMIN 権限を付与するなどとなります。
組織の ID プロバイダーで、作成したロールと同名のグループを作成し、ユーザーを該当するグループに追加します。

以下に例を示します。

Virtual DataPort で、ロール「denodo_administrator_production」を作成し、本番サーバーで、このロールにロール「serveradmin」を付与します。
ID プロバイダーで、グループ「denodo_administrator_production」を作成し、このグループに該当するユーザーを追加します。

ユーザーにロール「serveradmin」、「assignprivileges」、またはデフォルトロールのいずれかを付与する場合に、グループをそれらと同じ名前で ID プロバイダーに作成して、そのグループにユーザーを追加することはできません。

たとえば、ID プロバイダーに「serveradmin」というグループを作成し、このグループにユーザーを追加した場合、このユーザーが Virtual DataPort にログインすると、ユーザーにはこのロールがありません。これは、ユーザーがログインしたときに、ID プロバイダーで割り当てられた、「デフォルトロール」と同じ名前のグループを Virtual DataPort が無視するためです。

この動作は、Denodo の管理者のみがユーザーに管理権限を付与するようにするためです。そうしなければ、ID プロバイダーの管理者が、Denodo の管理者の承認を得ずに、ユーザーに対して特別な権限を付与する可能性があります。

上記を終えたら、次のセクションに進み、Denodo サーバーの構成方法を確認してください。