SAML 認証¶
Virtual DataPort によって公開されている REST Web サービスは、SAML 認証 (Security Assertion Markup Language) をサポートしています。
実行時に、クライアントが SAML 認証を使用して REST Web サービスにリクエストを送信する場合、サーバーは SAML プロトコルを使用してユーザーを認証します。次にサーバーはこのダイアログの LDAP 設定を使用して、ユーザーのロールを取得し、このユーザーが実行できるクエリを検証します。
REST Web サービスの SAML 認証を有効にする前に、Kerberos 認証またはデータベースの LDAP 認証を有効にする場合と同じ方法で、LDAP 設定を行う必要があります。
Kerberos 認証に対して、または LDAP 認証を使用するデータベースに対してこの操作を行っていない場合は、ユーザーを認証するために組織内で使用される Active Directory または LDAP サーバーを参照する LDAP データソースを作成する必要があります。
そのためには、[Administration] メニュー > [Server configuration] > [Server authentication] をクリックします。次に [SAML] をクリックします。

SAML 認証のグローバル構成¶
ウィザードで以下の詳細を指定します。
Identity provider metadata URL: ID プロバイダーのメタデータの URL。実行時に、サーバーはこの URL から ID プロバイダーの識別子と署名証明書を復元します。
重要
この URL が「https」で、このサービスの SSL 証明書が Verisign や Comodo といった既知の証明機関 (CA) によって署名されていない場合、その SSL 証明書をサーバーの トラストストア に追加する必要があります。その方法については「 データソースの証明書のインポート (SSL/TLS 接続) 」のページを参照してください。証明書を追加しておかないと、サーバーがこのサービスに接続した際に、証明書が信頼されていないため、接続が失敗します。
Service provider URL base: Denodo Web コンテナーの URL。たとえば、https://acme:9443/ (9443 は HTTPS が有効な場合の Denodo Web コンテナーのデフォルトポート。無効な場合は 9090 です)。
Denodo がロードバランサーの背後にあるクラスタで動作している場合は、ロードバランサーの URL を入力します。
Role extraction method: ユーザーのロールは、Active Directory (または別の LDAP サーバー)、あるいはクライアントアプリケーションから送信される SAML アサーションの属性から取得できます。最初のオプションには 2 つの選択肢 [Global LDAP configuration] または [Custom LDAP configuration] があり、2 番目のオプションは [SAML assertion] です。
Global LDAP configuration: [Administration] の [LDAP] タブ > [Server configuration] > [Server authentication] で定義された LDAP 構成を使用します。
Custom LDAP configuration:
Database: LDAP データソースを格納した Virtual DataPort のデータベースを選択します。
LDAP data source: データソースを選択します。
User base: ユーザーを表すノードの検索スコープとして使用される Active Directory のノード。[User base] ボックスの横にある
ボタンをクリックすると、複数の「ユーザーベース」を入力することができます。複数の「ユーザーベース」が存在する場合、サーバーは最初の「ユーザーベース」スコープ内でユーザーのノードを検索します。ユーザーを表すノードが見つからなければ、2 番目の「ユーザーベース」スコープで検索します。それでも見つからなければ、3 番目のスコープを検索します (以降同様)。サーバーがユーザーを表すノードを見つけられなかった場合は、そのユーザーへのアクセスが拒否されます。
Attribute with user name: ユーザーを表すノード内の、ユーザーのユーザー名を含む属性の名前。
User search pattern: サーバーに接続しようとしているユーザーを表すノードを取得するために実行される LDAP クエリの生成に使用されるパターン。
Role base: LDAP サーバーのノード。このデータベースのユーザーが持つことのできるロールを表すノードを検索するためのスコープとして使用されます。[Role base] ボックスの横にある
ボタンをクリックすると、複数の「ロールベース」を入力することができます。「ロール検索」パターンで形成された LDAP クエリは、「ロールベース」スコープごとに実行されます。
Attribute with role name: ロールを表すノード内の、ロールの名前を含む属性の名前。
Role search pattern: ユーザーのロールを表すノードを取得するために実行される LDAP クエリの生成に使用されるパターン。このパターンには、トークン
@{USERDN}
または@{USERLOGIN}
を含める必要があります (両方を含めることはできません)。@{USERDN}
は、このデータベースに接続しようとしているユーザーの識別名に置換されます (例: CN=john,CN=Users,DC=acme,DC=loc)。@{USERLOGIN}
は、このデータベースに接続しようとしているユーザーのログイン名に置換されます (例: john)。
正常にログインしたすべてのユーザーにロール「allusers」の権限を付与するには、[Assign 'allusers' role for every connected user] を選択します。このロールが LDAP サーバーのユーザーに割り当てられていない場合も同様です。
たとえば、特定のデータベースに対する読み取りアクセス権をすべてのユーザーに付与したい場合は、このオプションを選択し、この権限を「allusers」ロールに割り当てます。
このオプションを選択しても、LDAP サーバー内のユーザーに付与されたロールが変更されることはありません。つまり、後からこのチェックボックスのチェックをはずすと、ログインしているユーザーは「allusers」ロールで付与される権限を持たなくなります。
SAML assertion: このオプションを使用すると、ロールは Active Directory ではなく、アサーションから抽出されます。
Assertion role field: アサーションを送信するユーザーのロールを含む、SAML アサーション内のフィールド名。
アサーションによるロールの抽出を使用する SAML 認証の構成¶
ロール情報を含む SAML 属性ステートメントの例¶
No role extraction: このオプションでは、ロールは取得されません。この構成は、LDAP サーバーや SAML アサーションの代わりに Virtual DataPort サーバーでロール割り当てを管理する場合に役立ちます (「 外部ユーザー 」のセクションを参照)。
Session attribute mapping: 認証されたユーザーから取得する SAML 属性とユーザーセッションに追加される属性の間にマッピングを定義できます。Virtual DataPort 上の名前は Session Attribute 列で表され、アサーションでの名前は Authentication Attribute で指定されます。
LDAP からロールを取得する場合、以下のようになります。
Global LDAP:ユーザーセッションには、「 Virtual DataPort サーバーに対するグローバル LDAP 認証の有効化 」に示す構成で定義した属性マッピングも含まれます。
Custom LDAP:Virtual DataPort は、このセクションで定義されているマッピングで使用される属性を、カスタム LDAP でも検索します。
どちらの場合も、LDAP から得られるマッピングとアサーションの属性から得られるマッピングが同一である場合、アサーションから得られる値が使用されます。
たとえば、SAML の tenantid を http://schemas.microsoft.com/identity/claims/tenantid 属性で受信する場合、 saml_tenantid 属性へのマッピングを作成でき、この属性は Virtual DataPort でユーザーセッションに追加されます。saml_tenantid 属性には、 GETVAR などの関数からアクセスできるほか、 グローバルセキュリティポリシー からセッション属性対象者としてアクセスできます。
これらの変更を適用するために再起動する必要はありません。
LDAP サーバー (Active Directory など) からユーザーのロールを取得するために SAML 認証を構成している場合、SAML 認証を使用してログインするユーザーは、 LDAP ロールキャッシュ 機能の影響を受けます。
Virtual DataPort ユーザーのロールの作成¶
ユーザーが SAML 認証で 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 の管理者の承認を得ずに、ユーザーに対して特別な権限を付与する可能性があります。
応答署名の検証¶
デフォルトでは、Virtual DataPort の REST Web サービスは SAML アサーションの署名を要求しません。アサーションが署名されている場合、サービスはその署名を検証しますが、アサーションの署名は必須ではありません。
署名されている SAML アサーションのみを REST サービスで受け付けるようにするには、以下の手順に従います。
VQL シェルから、次のコマンドを実行します。
SET 'com.denodo.vdb.security.SAMLAuthenticator.requireResponseSigned' = 'true';
Virtual DataPort サーバーを再起動して変更を適用します。Web サービスを再デプロイする必要はありません。