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 では、同名のロールがないスコープを無視します。
トークンのいずれかのスコープと同名のロールがない場合、リクエストは失敗します。
Session attribute mapping: 認証されたユーザーから取得する Oauth トークン属性とユーザーセッションに追加される属性の間にマッピングを定義できます。Virtual DataPort 上の名前は Session Attribute 列で表され、トークンでの名前は Authentication Attribute で指定されます。
LDAP からロールを取得する場合、以下のようになります。
Global LDAP:ユーザーセッションには、「 Virtual DataPort サーバーに対するグローバル LDAP 認証の有効化 」に示す構成で定義した属性マッピングも含まれます。
Custom LDAP:Virtual DataPort は、このセクションで定義されているマッピングで使用される属性を、カスタム LDAP でも検索します。
どちらの場合も、LDAP から得られるマッピングと OAuth トークンから得られるマッピングが同一である場合、トークンから得られる値が使用されます。
たとえば、OAuth トークンに department 属性がある場合、 user_department 属性へのマッピングを作成でき、この属性は Virtual DataPort でユーザーセッションに追加されます。user_department 属性には、 GETVAR などの関数からアクセスできるほか、 グローバルセキュリティポリシー からセッション属性対象者としてアクセスできます。
LDAP サーバー (Active Directory など) からユーザーのロールを取得するために OAuth 認証を構成している場合、OAuth 認証を使用してログインするユーザーは、 LDAP ロールキャッシュ 機能の影響を受けます。
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 サーバーの構成方法を確認してください。