SAML 構成¶

以下のセクションに入力し、外部 SAML ID プロバイダー (IdP) に対する認証を構成します。

• SAML entity ID: このエンティティ ID により、IdP に対して Solution Manager のインストール環境を一意に識別します。

• Base URL: プラットフォームの Web コンテナーのベース URL。IdP への SAML リクエストで Assertion Consumer Service のベース URL として使用されます。

• SAML signing request:有効な場合、IdP への認可リクエストは Solution Manager のインストール環境によって署名されます。SAML リクエストは、Solution Manager で構成されている 認証資格情報 を使用して署名されます。

• Download XML metadata file: ファイルの場所を指定します。このファイルは、証明書利用者情報と証明書が含まれるメタデータを Solution Manager と IdP との間で交換する際に使用します。このメタデータを使用することで、Solution Manager を IdP にサービスプロバイダーとして追加できます。

  重要

  SAML 構成を保存すると、この XML メタデータは URL https://solution-manager.acme.com:19443/sso/sso-saml/metadata で使用可能になります。組織の ID プロバイダーで XML メタデータ交換用の URL が許可されている場合にこの URL を利用できます。この場合、ID プロバイダーから Solution Manager が実行されているサーバーへの着信接続を許可する必要があります。たとえば、ポート 19443 を開く必要があります。

• Identity provider metadata URL: Solution Manager を IdP にサービスプロバイダーとして追加したら、IdP のメタデータを取得できるようになります。実行時に、サーバーはこの URL から ID プロバイダーの識別子と署名証明書を復元します。

  注釈

  この URL が「https」で、このサービスの SSL 証明書が Verisign や Comodo といった既知の認証局 (CA) によって署名されていない場合、その SSL 証明書をサーバーの トラストストア に追加する必要があります。その方法については、『インストールガイド』の「 データソースの証明書のインポート (SSL/TLS 接続) 」のセクションを参照してください。証明書を追加しておかないと、サーバーがこのサービスに接続した際に、証明書が信頼されていないため、接続が失敗します。

• Extract roles from SAML assertion: このオプションが有効な場合、アサーションから役割が抽出されます。このオプションを選択しない場合は、 LDAP を使用した認証 のグローバル LDAP セクションを、LDAP 検索でユーザーの役割を取得するように構成する必要があります。

• Assertion role field: 役割の抽出に使用する SAML アサーションの属性の名前。たとえば、以下のコードは、controller の役割を表す Group という名前の SAML 属性です。

  <Attribute Name="Group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <AttributeValue>controller</AttributeValue>
  </Attribute>
  

ユーザーの ID が検証されると、外部 ID プロバイダー (IdP) から、 https://server:port/sso/sso-saml/SSO にある SAML エンドポイントに SAML 2.0 標準向け HTTP POST バインド 経由で、アサーションが含まれる認証応答が送信されます。

この変更後に Solution Manager にアクセスすると、ユーザーは自動的に外部 ID プロバイダーに転送されるようになります。

OAuth 構成¶

このセクションに入力し、外部 OAuth プロバイダーに対する認証を構成します。

• Client ID: クライアントアプリケーションの登録プロセス中に生成されるクライアント ID。

• Client secret: アプリケーションの登録プロセス中に生成されるクライアントシークレット。

• User authorization URI: 認証と同意をリクエストします。 認可コード の取得に使用します。

• Access token URI: アクセストークン 用の認可コードを交換します。

• Issuer: トークンを発行する認可サーバーの一意の識別子。

• JWKS URL: アクセストークンの真正性の確認に使用するパブリックサーバーの JSON Web Key (JWK) を取得するための URL。

• Default process URI: アプリケーションのコールバックエンドポイントの相対 URI。ID プロバイダーは、この URI に認可応答を送信します。デフォルトは /sso-oauth/oauth-login です。

  重要

  完全な URL は、 OAuth 認可サーバーに登録されている URL (通常はリダイレクト URI と呼ばれます) に一致する必要があります。たとえば、Solution Manager Web ツールに https://server:port でアクセス可能で、デフォルトプロセス URI が /sso-oauth/oauth-login の場合、リダイレクト URI https://server:port/sso/sso-oauth/oauth-login を登録しておく必要があります。

• Scopes: OAuth 認可サーバーへのリクエストで送信するコンマ区切りのスコープ。OAuth サーバーで許可されているスコープを確認してください。

• Extract roles from token: トークンではリクエストに役割が関連付けられます。これを選択しない場合は、 LDAP を使用した認証 のグローバル LDAP セクションを、LDAP 検索でユーザーの役割を取得するように構成する必要があります。

• Token role field: 役割の抽出に使用されるトークンリクエストの名前。

この変更後に Solution Manager にアクセスすると、ユーザーは自動的に外部 ID プロバイダーに転送されるようになります。

OpenID 構成¶

このセクションに入力し、外部 OpenID プロバイダーに対する認証を構成します。

• Client ID: クライアントアプリケーションの登録プロセス中に生成されるクライアント ID。

• Client secret: アプリケーションの登録プロセス中に生成されるクライアントシークレット。

• User authorization URI: 認証と同意をリクエストします。 認可コード の取得に使用します。

• Access token URI: アクセストークン 用の認可コードを交換します。

• Issuer: トークンを発行する認可サーバーの一意の識別子。

• JWKS URL: アクセストークンの真正性の確認に使用するパブリックサーバーの JSON Web Key (JWK) を取得するための URL。

• Default process URI: アプリケーションのコールバックエンドポイントの相対 URI。ID プロバイダーは、この URI に認可応答を送信します。デフォルトは /sso-openid/openid-login です。

  重要

  完全な URL は、 認可サーバーに登録されている URL (通常はリダイレクト URI と呼ばれます) に一致する必要があります。たとえば、Solution Manager Web ツールに https://server:port でアクセス可能で、デフォルトプロセス URI が /sso-openid/openid-login の場合、リダイレクト URI https://server:port/sso/sso-openid/openid-login を登録しておく必要があります。

• Scopes: 認可サーバーへのリクエストで送信するコンマ区切りのスコープ。たとえば、openid、email、profile、offline_access などです。

• Extract roles from token: トークンではリクエストに役割が関連付けられます。これを選択しない場合は、 LDAP を使用した認証 のグローバル LDAP セクションを、LDAP 検索でユーザーの役割を取得するように構成する必要があります。

• Token role field: 役割の抽出に使用されるトークンリクエストの名前。

この変更後に Solution Manager にアクセスすると、ユーザーは自動的に外部 ID プロバイダーに転送されるようになります。

Kerberos 構成¶

Solution Manager で Kerberos 認証を有効にするには、以下の手順に従って実施してください。

1. 『 Denodo Platform インストールガイド 』の「 Kerberos 認証の設定 」で説明されているインストール後のタスクを実行します。

2. Kerberos レルムが自身のドメインと異なる場合には、 インストールガイド の「 Kerberos レルムに属することなく Kerberos 認証を有効化する 」の説明のように、そのレルムを指定します。

3. Solution Manager Web ツールで Kerberos を有効にします。管理者としてログインして、 [Configuration] メニュー > [Authentication] をクリックします。

   

   Kerberos を構成するためのダイアログ¶

   1. [Enabled] をチェックします。

   2. [Server principal name] ボックスに、 keytab ファイルの作成に使用する「サービスプリンシパル名」 (SPN) を入力します。

      たとえば、次のコマンドを使用して SPN を作成したとします。

      setspn -S HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM CONTOSO.COM\denodo_server
      

      この場合、「 HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM 」と入力します。

   3. [Keytab file] 入力ボックスに、生成した keytab ファイルをアップロードします。

   4. 現在の環境が次のいずれかの状況でない限り、[Kerberos configuration file] 入力ボックスは空のままにしておきます。

      • Solution Manager が実行されているホストが Kerberos レルム (Windows Active Directory ドメインなど) に属して いない 。

      • Solution Manager が実行されているホストが Linux または Unix である。

      • クロスドメインシナリオを使用している。つまり、組織が複数のドメインを使用している。

      現在の環境がこのいずれかの状況にあてはまる場合は、ファイル krb5.conf または krb5.ini をアップロードします。

      通常、krb5 ファイルは Active Directory の管理者が提供できます。すでに Kerberos 認証を使用しているアプリケーションの 1 つを使用して、ファイルが正しいことを確認するようお勧めします。

   5. Kerberos を初めて設定する場合は、問題が生じた場合に備えて [Debug mode] チェックボックスをチェックすることをお勧めします。Kerberos の設定が完了したら、これを無効にして、ログファイルが Kerberos のデバッグメッセージでいっぱいにならないようにします。

      このログを有効にするには、ファイル <DENODO_HOME>/conf/vdp/log4j2.xml を編集して、行 <Loggers> の 直下に 次の行を追加します。

      <Logger name="com.denodo.util.logging.JavaConsoleLogging" level="debug" />
      

      Kerberos デバッグメッセージは、 <DENODO_HOME>/logs/vdp/vdp.log にあります。

4. ブラウザーで Kerberos を構成します 。

この変更後に Solution Manager にアクセスすると、ユーザーは資格情報を入力することなく自動的にログインするようになります。ブラウザーによってシステムの Kerberos 資格情報が送信されるからです。

シングルサインオンでの認証ダイアログ¶