| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.2.1.3.0) E90347-06 |
|
 前 |
 次 |
複数のWebLogic ServerインスタンスでSAML 2.0サービスを実行する場合は、そのサービスを構成する前に、一定のステップを実行する必要があります。その後、WebLogic Serverインスタンスをサービス・プロバイダまたはアイデンティティ・プロバイダとして構成できます。
ここでは、SAML 2.0サービスを構成する主なステップを示します。
SAML 2.0サービスを、ドメイン内の複数のWebLogic Serverインスタンスで実行する可能性があるかどうかを検討します。その可能性がある場合は、次の手順に従います。
RDBMSセキュリティ・ストアを構成するドメインを作成します。
本番環境のSAML 2.0セキュリティ・プロバイダは、RDBMSセキュリティ・ストアを必要とします。これは、それらが管理するデータを、データを共有するすべてのWebLogic Serverインスタンスの間で同期できるようにするためです。
なお、RDBMSセキュリティ・ストアを使用するドメインを作成するかわりに、既存のドメインをアップグレードすることはお薦めできません。RDBMSセキュリティ・ストアを使用する場合は、ドメインの作成時にRDBMSセキュリティ・ストアを構成する必要があります。RDBMSセキュリティ・ストアを使用したいドメインが作成済みである場合は、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。
RDBMSセキュリティ・ストアの管理を参照してください。
すべてのSAML 2.0サービスが、各WebLogic Serverインスタンスでまったく同じように構成されていることを確認します。SAML 2.0サービスをクラスタ内で構成する場合は、クラスタ内の各管理対象サーバーを個別に構成する必要があります。
「SAML 2.0におけるWebアプリケーション・デプロイメントの考慮事項」に説明されている内容を確認してください。
SAML 2.0 IDプロバイダ・サイトを構成する場合は、次の手順に従います。
セキュリティ・レルムで、SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成して構成します。
SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0全般サービスをまったく同じように構成します。
SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0 IDプロバイダ・サービスをまったく同じように構成します。
サイトについて記述したメタデータ・ファイルを公開し、サービス・プロバイダ・パートナに手動で配布します。
サービス・プロバイダ・パートナを作成して構成します。
SAML 2.0サービス・プロバイダ・サイトを構成する場合は、次の手順に従います。
セキュリティ・レルムで、SAML 2.0 IDアサーション・プロバイダのインスタンスを作成して構成します。
仮想ユーザーがSAMLでログインすることを許可している場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。「SAML認証プロバイダの構成」を参照してください。
SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0全般サービスをまったく同じように構成します。
SAML 2.0サービスを実行するドメイン内の各WebLogic Serverインスタンスで、SAML 2.0サービス・プロバイダ・サービスをまったく同じように構成します。
サイトについて記述したメタデータ・ファイルを公開し、IDプロバイダ・パートナに手動で配布します。
IDプロバイダ・パートナを作成して構成します。
これ以降の節では、これらのステップについて詳しく説明します。
ノート:
WebLogic Serverのこのリリースでは、SAML 2.0実装は、リクエストおよびレスポンスの署名のデフォルトとしてSHA2署名アルゴリズムを使用します。下位互換性に必要な場合、Javaシステム・プロパティのcom.bea.common.security.saml2.useSHA1SigAlgorithmをtrueに設定して、SHA1署名アルゴリズムを使用できます。これを行うには、WebLogic Serverを起動するJavaコマンドで次のオプションを指定します。
-Dcom.bea.common.security.saml2.useSHA1SigAlgorithm=true
WebLogic Serverのこのリリースでは、SAML2.0実装は有効期限が切れているか、SAML署名でまだ有効になっていない証明書を使用しなくなりました。これらの証明書を使用できるようにするには、Javaシステム・プロパティのcom.bea.common.security.saml2.allowExpiredCertsをtrueに設定します。たとえば、WebLogic Serverを起動するJavaコマンドで次のオプションを指定します。
-Dcom.bea.common.security.saml2.allowExpiredCerts=true
SAML 2.0実装では、SAMLレスポンスでHttpServletResponse URLリライティングを使用しません。このため、SAMLレスポンスにJSESSIONIDは追加されず、その結果、SAML 2.0は、Cookieをサポートしないブラウザでは使用できません。
HttpServletResponse URL再書込みを有効にするには、Javaシステム・プロパティcom.bea.common.security.saml2.enableURLRewritingをtrueに設定します。たとえば、WebLogic Serverを起動するJavaコマンドで次のオプションを指定します。
-Dcom.bea.common.security.saml2.enableURLRewriting=true
WebLogic ServerインスタンスをSAML 2.0サービス・プロバイダとして構成するにせよ、SAML 2.0アイデンティティ・プロバイダとして構成するにせよ、WebLogic Scripting ToolまたはWebLogic Server管理コンソールを使用してサーバーのSAML 2.0全般サービスを構成する必要があります。WebLogic ServerインスタンスのSAML 2.0全般サービスの構成は、SingleSignOnServicesMBeanで制御します。
SingleSignOnServicesMBeanには、WebLogic Scripting ToolまたはWebLogic Server管理コンソール(「環境」→「サーバー」→「ServerName」→「構成」→「フェデレーション・サービス」→「SAML 2.0全般」ページ)を使用してアクセスします。
ノート:
SAML 2.0全般サービスを構成するには、その前にSAML 2.0 IDアサーション・プロバイダまたはSAML 2.0資格証明マッピング・プロバイダを構成し、サーバー・インスタンスを再起動する必要があります。
以下の節では、SAML 2.0全般サービスについて説明します。
SAML 2.0全般サービスとしては、以下のような項目を構成します。
レプリケーションされたキャッシュを有効にするかどうか。
クラスタを構成する場合のように、ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを構成する場合には、レプリケーションされたキャッシュを有効にする必要があります。レプリケーションされたキャッシュを使用すると、SAML 2.0セキュリティ・プロバイダ(SAML 2.0 IDアサーション・プロバイダとSAML 2.0資格証明マッピング・プロバイダのどちらか、または両方)で管理しているデータを、サーバー・インスタンス間で共有して同期させることができます。
本番環境のSAML 2.0セキュリティ・プロバイダは、RDBMSセキュリティ・ストアを必要とします。これは、それらが管理するデータを、データを共有するすべてのWebLogic Serverインスタンスの間で同期できるようにするためです。(開発環境のみの場合は、SAML 2.0セキュリティ・プロバイダでセキュリティ・ストアとしてLDAPを使用します)。
その場合は、SAML 2.0サービスを構成する前に、RDBMSセキュリティ・ストアを使用するように構成されたドメインを作成する必要があります。RDBMSセキュリティ・ストアの管理を参照してください。
ローカル・サイトに関する情報。
サイト情報は、主にSAMLフェデレーション内のビジネス・パートナに提供して共有するためのものです。サイト情報には、ローカル・サイトの担当者の連絡先、組織名、組織のURLなどが含まれます。
公開サイトのURL
公開サイトのURLには、様々なSAML 2.0サービスのエンドポイントURLを構築するために使用するベースURLを指定します。このURLにはサーバーを外部から認識できるホスト名とポートを指定する必要がありますが、これらはローカルでサーバーにアクセスする場合に使用するホスト名やポートとは異なる可能性があります。たとえば、SAML 2.0サービスをクラスタ内で構成する場合のホスト名とポートは、クラスタ内の管理対象サーバーにクライアント・リクエストを配信するロード・バランサまたはプロキシ・サーバーに相当します。
公開サイトのURLには、/saml2を付加する必要があります。たとえば:
https://www.avitek.com:7001/avitek-domain/aviserver/saml2
エンティティID
エンティティIDは人間が読取れる形式の文字列で、サイトをフェデレーション内の他のパートナ・サイトと区別するために使用します。SAML 2.0サービスでは、パートナがアサーションを生成または消費する必要がある場合に、そのアサーションに対応するパートナを特定するプロセスにおいてこのエンティティIDを使用します。
受信者チェックを有効にするかどうか。
有効にした場合、認証のリクエストやレスポンスの受信者は、HTTPリクエスト内のURLに一致しなければなりません。
アーティファクト解決サービスでの呼出しにTLS/SSLクライアント認証を必要とするかどうか。有効にした場合、パートナへの送信時にSAMLアーティファクトが暗号化されます。
トランスポート層セキュリティ・キーストアの別名とパスワード。これらの値は、パートナに対する送信の保護に使用します。
パートナがローカル・サイトのHTTPSバインディングを呼び出す際に、基本認証クライアントの認証を必要とするかどうか。
この設定を有効にした場合、クライアントのユーザー名とパスワードも指定する必要があります。これらの資格証明は、公開するメタデータ・ファイルに格納され、これをフェデレーション・パートナと共有することになります。
パートナから受け取るSAMLアーティファクトのリクエストに署名を必要とするかどうか。
SAMLアーティファクト・キャッシュの構成設定。
フェデレーション・パートナに送信するドキュメント(認証のリクエストやレスポンス)に署名する際のキーが格納されているキーストアの別名とパスワード。
SAML 2.0全般サービスの構成のステップについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0の全般サービスの構成に関する項を参照してください。
フェデレーション・パートナが必要とするローカル・サイト情報(ローカル・サイトの連絡先情報、エンティティID、公開サイトのURL、TLS/SSLクライアント認証が必要かどうかなど)は、管理コンソールの「SAML 2.0全般」ページで「メタデータの公開」をクリックすることでメタデータ・ファイルとして公開できます。
メタデータ・ファイルを公開する際には、ローカル・マシンの既存のディレクトリ(ファイルの作成が可能なディレクトリ)を指定します。WebLogic Serverには、メタデータ・ファイルをフェデレーション・パートナに配布する手段は実装されていません。ただし、暗号化された電子メール、セキュアFTPなど、電子的なドキュメントを安全に転送できる一般的な方法で配布して構いません。
メタデータ・ファイルに関しては、以下の点に留意してください。
メタデータ・ファイルを公開する前に、ドメイン内のWebLogic Serverインスタンスが果たすSAML 2.0機能として、IDプロバイダ・サービスやサービス・プロバイダ・サービスを構成する必要があります。
メタデータ・ファイルには、フェデレーション・パートナが必要とするこれらのSAML 2.0サービスの構成データが含まれています。パートナはこれらのデータを使用することで、署名用証明書のインポート、サイトのSAML 2.0サービス・エンドポイントの特定、サイトのサービスに接続するための適切なバインディング・タイプの選択など、様々な処理にかかる手間を大幅に省くことができます。
サイトが一部のパートナに対してサービス・プロバイダとして機能し、残りのパートナに対してはIDプロバイダとして機能する場合も、フェデレーション・パートナと共有しているメタデータ・ファイルのバージョンを1つに限定する必要があります。メタデータ・ファイルのバージョンを1つに限定することで、パートナの構成設定との互換性がなくなる事態を避けることができます。
ローカル・サイトのSAML 2.0構成を変更する場合は、メタデータ・ファイルを更新する必要があります。メタデータ・ファイルはパートナと共有しているため、SAML 2.0構成を変更する頻度を最小限に抑えることで、変更に伴いパートナがレジストリを更新する頻度も抑えることができます。
フェデレーション・パートナからメタデータ・ファイルを受け取った場合は、SAML 2.0サービスが構成されているドメイン内のすべてのノードからアクセスできる場所に格納します。パートナの作成時には、パートナのメタデータ・ファイルの内容をパートナ・レジストリに反映します。
メタデータ・ファイルは、com.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して操作できます。
WebLogic Serverインスタンスに対してSAML 2.0アイデンティティ・プロバイダ・サービスを構成する前に、まずセキュリティ・レルムでSAML 2.0資格証明マッピング・プロバイダ・インスタンスを構成し、次にSAML 2.0全般サービスを構成する必要があります。これらの前提条件を実行した後、WebLogic Scripting Tool (WLST)を使用するか、WebLogic Server管理コンソールからSAML 2.0アイデンティティ・プロバイダ・サービスを構成します。
この節では、以下の内容について説明します。
使用するセキュリティ・レルムで、SAML 2.0資格証明マッピング・プロバイダのインスタンスを作成します。SAML 2.0資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 2.0用のSAML 2.0資格証明マッピング・プロバイダの構成」を参照してください。
SAML 2.0資格証明マッピング・プロバイダは、SAML認証局として構成します。以下のような属性を指定します。
発行者URI
名前修飾子
生成するSAML 2.0アサーションの有効期間属性
名前マッパー・クラス名
アサーションに格納するIDが属すグループを特定するための属性情報をアサーションに含めるかどうか
SAML 2.0資格証明マッピング・プロバイダを構成したら、「SAML 2.0全般サービスの構成」に従ってSAML 2.0全般サービスを構成します。
SAML 2.0 IDプロバイダ・サイトとしてのWebLogic Serverインスタンスの構成は、SingleSignOnServicesMBeanによって制御されます。SingleSignOnServicesMBeanには、WebLogic Scripting ToolまたはWebLogic Server管理コンソール(「環境」→「サーバー」→「ServerName」→「構成」→「フェデレーション・サービス」→「SAML 2.0アイデンティティ・プロバイダ」ページ)を使用してアクセスします。
次の項では、この構成タスクについて簡単に説明します。これらのタスクの実行方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 IDプロバイダ・サービスの構成に関する項を参照してください。
管理コンソールの「SAML 2.0 IDプロバイダ」ページで「有効」属性をtrueに設定すると、WebLogic ServerインスタンスをIDプロバイダ・サイトとして機能させることができます。
必要に応じ、カスタム・ログインWebアプリケーションを使用してIDプロバイダ・サイトのユーザーを認証できます。カスタム・ログインWebアプリケーションを構成するには、「ログインのカスタマイズ」属性を有効にし、WebアプリケーションのURLを指定します。
IDプロバイダ・サービスのエンドポイントで使用できるすべてのバインディング・タイプ(POST、リダイレクト、およびアーティファクト)を有効にすることをお薦めします。必要に応じて、優先するバインディング・タイプを選択することもできます。
SAML 2.0全般サービスとIDプロバイダ・サービスを構成したら、サイトのメタデータ・ファイルを公開してフェデレーション・パートナに配布します。詳細は、「メタデータ・ファイルの公開と配布」を参照してください。
SAML 2.0サービス・プロバイダ・パートナは、IDプロバイダ・サイトによって生成されたSAML 2.0アサーションを消費するエンティティです。サービス・プロバイダ・パートナは、WebLogic Server管理コンソールの「セキュリティ・レルム」→「RealmName」→「「プロバイダ」→資格証明マッパー→「SAML2CredentialMapperName」→「管理」ページで構成します。
このコンソール・ページで設定できる属性には、以降の各節で示すJavaインタフェースを使用してプログラム的にアクセスできます。
サービス・プロバイダ・パートナを構成する詳しいステップについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成に関する項を参照してください。Webシングル・サインオン・パートナを構成する際に利用できるサイト情報、署名用証明書、サービス・エンドポイント情報については、「パートナ・サイト、証明書、サービス・エンドポイント情報の表示」を参照してください。
この項には次のトピックが含まれます:
Webシングル・サインオン用のサービス・プロバイダ・パートナを構成する前に、暗号化された電子メール、セキュアFTPなど、信頼性の高い安全な方法で、パートナのSAML 2.0メタデータ・ファイルを取得する必要があります。パートナのSAML 2.0メタデータ・ファイルには、パートナ・サイトおよびバインディング・サポートについて記述されており、パートナの証明書やキー、SAML 2.0サービス・エンドポイントなど、様々な情報が含まれています。パートナのメタデータ・ファイルは、SAML 2.0用に構成されているドメイン内の各ノードからアクセスできる場所に格納します。
SAML 2.0メタデータ・ファイルの詳細は、「メタデータ・ファイルの公開と配布」を参照してください。
Webシングル・サインオン用のサービス・プロバイダ・パートナを作成して構成するには:
WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して構成できます。
パートナ構成ページの「全般」タブでは、このサービス・プロバイダ・パートナのためだけに生成するSAML 2.0アサーションの以下の属性も、必要に応じて構成できます。
サービス・プロバイダの名前マッパー・クラス名
このセキュリティ・レルム内に構成されているSAML 2.0資格証明マッピング・プロバイダのデフォルトのユーザー名マッパー・クラスをオーバーライドするJavaクラスです。
存続時間属性
存続時間属性には、このパートナ用に生成されたアサーションが有効な期間を指定します。これらの属性を指定することで、期限切れのアサーションが使用されるのを防ぐことができます。
アサーションに含める属性情報を生成するかどうか
有効にすると、対応するユーザーが属すグループが、SAML 2.0資格証明マッピング・プロバイダによってアサーションの属性として追加されます。
このパートナに送信するアサーションを使用後直ちに破棄する必要があるかどうか
このパートナ用に生成するアサーションにこのサーバーの署名用証明書を含めるかどうか
WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.SPPartner Javaインタフェースを使用して構成できます。
サービス・プロバイダ・パートナの構成ページの「全般」タブでは、このパートナと交換する以下のドキュメントの署名方法を指定できます。
アサーション
この属性は、com.bea.security.saml2.providers.registry.SPPartnerインタフェースを使用して操作できます。
認証リクエスト
この属性は、com.bea.security.saml2.providers.registry.WebSSOSPPartnerインタフェースを使用して操作できます。
アーティファクト・リクエスト
この属性は、com.bea.security.saml2.providers.registry.WebSSOPartnerインタフェースを使用して操作できます。
このパートナが署名付きアサーションしか受け付けないかどうかを指定する属性と、認証リクエストに署名する必要があるかどうかを指定する属性は読取り専用で、パートナのメタデータ・ファイルから抽出されます。
サービス・プロバイダ・パートナの構成ページの「全般」タブでは、必要に応じて以下を構成することもできます。
SAMLアーティファクトをこのサービス・プロバイダ・パートナにHTTP POSTバインディングで配信するかどうか。配信する場合は、SAMLアーティファクトを送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURIも指定します。
リクエストやレスポンス・メッセージをPOSTバインディングで送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURI。
これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。
このパートナとのドキュメントの交換をより安全に行うため、サービス・プロバイダ・パートナがローカル・サイトのバインディングに接続する際の基本認証で使用するクライアントのユーザー名とパスワードを指定することもできます。この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースで利用できます。
SAML 2.0サービス・プロバイダ・サイトを構成する前提条件として、セキュリティ・レルムでSAML 2.0アイデンティティ・アサーション・プロバイダ・インスタンスを構成してから、SAML 2.0全般サービスを構成する必要があります。仮想ユーザーを有効にする場合、必要に応じてSAML認証プロバイダを構成できます。これらの前提条件を満たした後、WebLogic Scripting Tool (WLST)またはWebLogic Server管理コンソールを使用してSAML 2.0サービス・プロバイダ・サービスを構成します。
ノート:
「session-descriptor」で説明しているように、Cookieパス要素によりセッション追跡Cookieパスが定義されます。この要素を設定しない場合、デフォルトは「/」(スラッシュ)です。デフォルト値では、WebLogic Serverで指定されているすべてのURLにブラウザがCookieを送信します。
WebLogic ServerのSAML 2.0サービス・プロバイダではCookieパスは「/」(スラッシュ)にする必要があります。Cookieパスでこれ以外の値を設定すると、SSOではSAML 2.0サービス・プロバイダで失敗します。
この節では、以下の内容について説明します。
セキュリティ・レルムで、SAML 2.0 IDアサーション・プロバイダのインスタンスを作成します。SAML 2.0 IDアサーション・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。SAML 2.0 IDアサーション・プロバイダでは、以下のような属性を指定します。
レプリケーションされたキャッシュを有効にするかどうか
SAML 2.0 IDプロバイダ・サービスをドメイン内の複数のサーバー・インスタンスに構成する場合は、この属性を有効にする必要があります。
SAML 2.0アサーションのデフォルトの名前マッパー・クラスをオーバーライドするカスタム名前マッパー
このセキュリティ・プロバイダの詳細は、「SAML 2.0用のSAML 2.0 IDアサーション・プロバイダの構成」を参照してください。
仮想ユーザーを有効にする予定がある場合や、IDプロバイダ・パートナから受け取るアサーションに含まれる属性文を消費する予定がある場合は、SAML認証プロバイダのインスタンスを作成して構成する必要があります。「SAML認証プロバイダの構成」を参照してください。
SAML 2.0 IDアサーション・プロバイダを構成し、必要に応じてSAML認証プロバイダを構成したら、「SAML 2.0全般サービスの構成」に従ってSAML 2.0全般サービスを構成します。
SAML 2.0サービス・プロバイダ・サイトとしてのWebLogic Serverインスタンスの構成は、SingleSignOnServicesMBeanによって制御されます。SingleSignOnServicesMBeanには、WebLogic Scripting ToolまたはWebLogic Server管理コンソール(「環境」→「サーバー」→「ServerName」→「構成」→「フェデレーション・サービス」→「SAML 2.0サービス・プロバイダ」ページ)を使用してアクセスします。
次の項では、SAML 2.0サービス・プロバイダ・サイトの属性の構成について簡単に説明します。これらの構成タスクの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0サービス・プロバイダ・サービスの構成に関する項を参照してください。
この項には次のトピックが含まれます:
管理コンソールの「フェデレーション・サービス: SAML 2.0サービス・プロバイダ」ページで「有効」属性をtrueに設定すると、WebLogic Serverインスタンスをサービス・プロバイダ・サイトとして機能させることができます。
ドキュメントに署名が必要かどうか設定するため、必要に応じて以下の属性を有効にします。
IDプロバイダ・パートナに送る認証リクエストに署名が必要かどうか
IDプロバイダ・パートナから受け取るアサーションに署名が必要かどうか
必要に応じて、認証リクエスト・キャッシュの以下の属性を有効にします。
最大キャッシュ・サイズ
認証リクエストのタイムアウト値。この値を指定することで、格納された認証リクエストが期限切れになるまでの期間を設定できます。
サービス・プロバイダ・サービスのエンドポイントで使用できるすべてのバインディング・タイプ(POSTおよびアーティファクト)を有効にすることをお薦めします。必要に応じて、優先するバインディング・タイプを指定することもできます。
SAML 2.0 IDプロバイダ・パートナは、サービス・プロバイダ・サイトによって消費されるSAML 2.0アサーションを生成するエンティティです。IDプロバイダ・パートナは、WebLogic Server管理コンソールの「セキュリティ・レルム」→「RealmName」→「プロバイダ」→「認証」→「SAML2IdentityAsserterName」→「管理」ページで構成します。
このコンソール・ページで設定できる属性には、以降の各節で示すJavaインタフェースを使用してプログラム的にアクセスできます。
サービス・プロバイダ・パートナを構成する詳しいステップについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成に関する項を参照してください。
Webシングル・サインオン・パートナを構成する際に利用できるサイト情報、署名用証明書、サービス・エンドポイント情報については、「パートナ・サイト、証明書、サービス・エンドポイント情報の表示」を参照してください。
以降の節では、IDプロバイダ・パートナの構成タスクについて簡単に説明します。
Webシングル・サインオン用のIDプロバイダ・パートナを構成する前に、暗号化された電子メール、セキュアFTPなど、信頼性の高い安全な方法で、パートナのSAML 2.0メタデータ・ファイルを取得する必要があります。パートナのメタデータ・ファイルには、パートナ・サイトおよびバインディング・サポートについて記述されており、パートナの証明書やキーをはじめ、様々な情報が含まれています。パートナのメタデータ・ファイルは、SAML 2.0用に構成されているドメイン内の各ノードからアクセスできる場所に格納します。
SAML 2.0メタデータ・ファイルの詳細は、「メタデータ・ファイルの公開と配布」を参照してください。
IDプロバイダ・パートナを作成し、Webシングル・サインオンのための対話を有効にするには:
「SAML 2.0 IDアサーション・プロバイダ」ページの「管理」タブで、パートナの名前とメタデータ・ファイルを指定します。
パートナ構成ページの「全般」タブで、パートナとWebLogic Serverインスタンスの間の対話を有効にします。
WebLogic Serverでは、これらの属性をcom.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して構成できます。
必要に応じて、このIDプロバイダ・パートナの以下の属性を構成します。このパートナ用に生成される認証リクエストの属性と、このパートナから受け取るアサーションの属性があります。
IDプロバイダの名前マッパー・クラス名。
このセキュリティ・レルム内に構成されているSAML 2.0 IDアサーション・プロバイダのデフォルトのユーザー名マッパー・クラスをオーバーライドするカスタムJavaクラスです。指定したカスタム・クラスは、このパートナから受け取るアサーションに含まれるIDにのみ使用されます。
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。
このパートナから受け取るアサーションに含まれているIDを、セキュリティ・レルム内の仮想ユーザーにマップするかどうか。
ノート:
この属性を使用するには、レルムにSAML認証プロバイダを構成する必要があります。
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。
このパートナから受け取るアサーションに含まれている属性情報を消費するかどうか。
この属性を有効にすると、SAML 2.0 IDアサーション・プロバイダによってアサーションから属性情報が抽出されます。この情報は、SAML認証プロバイダ(セキュリティ・レルムに構成されていなければなりません)との連携によって、対応するユーザーが属すセキュリティ・レルム内のグループを特定するために使用します。
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Javaインタフェースを使用して操作できます。
このIDプロバイダ・パートナに送る認証リクエストに署名が必要かどうか。これは、パートナのメタデータ・ファイルから抽出される読取り専用の属性です。
この属性は、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して操作できます。
このIDプロバイダ・パートナから受け取るSAMLアーティファクト・リクエストに署名が必要かどうか。
この属性は、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して操作できます。
未認証のユーザーによって呼び出された場合に、そのユーザーを認証できるIDプロバイダ・パートナにユーザー・リクエストをリダイレクトするURIのセットを指定できます。
ノート:
1つまたは複数のリダイレクトURIを構成する場合は、それらにもセキュリティ・ポリシーを設定するようにしてください。設定しないとWebコンテナによるユーザーの認証が行われないため、ユーザーのリクエストがIDプロバイダ・パートナにリダイレクトされません。
WebLogic Serverでは、この属性をcom.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースを使用して構成できます。
サービス・プロバイダ・パートナの構成ページの「全般」タブでは、必要に応じて以下を構成することもできます。
SAMLアーティファクトをこのサービス・プロバイダ・パートナにHTTP POSTメソッドで配信するかどうか。配信する場合は、SAMLアーティファクトを送信するためのHTTP POSTフォームを生成するカスタムWebアプリケーションのURIも指定します。
このIDプロバイダ・パートナにPOSTバインディングのSAMLレスポンスを伝送するためのPOST形式を生成するカスタムWebアプリケーションのURL。
このIDプロバイダ・パートナにアーティファクト・バインディングのSAMLレスポンスを伝送するためのPOST形式を生成するカスタムWebアプリケーションのURL。
これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。
このパートナとのドキュメントの交換をより安全に行うため、IDプロバイダ・パートナがローカル・サイトのバインディングに接続する際の基本認証で使用するクライアントのユーザー名とパスワードを指定することもできます。この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースで利用できます。
SAML 2.0パートナを構成する際、WebLogic Server管理コンソールに表示されるパートナ構成ページには、パートナに関する追加情報を表示および構成するためのタブが含まれています。
「サイト」タブには、サービス・プロバイダ・パートナに関する情報が表示されます。これは、パートナのメタデータ・ファイルから抽出されたものです。このタブのデータは読取り専用です。
WebLogic Serverでは、パートナ・サイト情報用にcom.bea.security.saml2.providers.registry.MetadataPartner Javaインタフェースが提供されています。
「シングル・サインオン署名用証明書」タブには、サービス・プロバイダ・パートナの署名用証明書の詳細が表示されます。これもまた、パートナのメタデータ・ファイルから抽出されたものです。このタブのデータは読取り専用です。
これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースを使用して操作できます。
「トランスポート層クライアント証明書」タブには、パートナのトランスポート層クライアント証明書が表示されます。この証明書は、必要に応じて「ファイルからの証明書のインポート」をクリックしてインポートできます。
この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Javaインタフェースを使用して操作できます。
サービス・プロバイダ・パートナを構成するときには、「アサーション・コンシューマ・サービス・エンドポイント」タブにサービス・プロバイダ・パートナのACSエンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOSPPartner Javaインタフェースでも利用できます。
サービス・プロバイダ・パートナを構成するときには、「シングル・サインオン・サービス・エンドポイント」タブにIDプロバイダ・パートナのシングル・サインオン・サービス・エンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Javaインタフェースでも利用できます。
「アーティファクト解決サービス・エンドポイント」タブには、パートナのARSエンドポイントが表示されます。このデータは、com.bea.security.saml2.providers.registry.WebSSOPartner Javaインタフェースでも利用できます。
クラスタ環境においてSAMLベースのSSOのためのWebアプリケーションをデプロイする際は、SAMLベースのシングル・サインオンが失敗することのないよう、一定の考慮事項に注意してください。
デプロイメント記述子ファイルで以下の要素を使用する場合は、下記の推奨事項を検討してください。
relogin-enabled
cookie-name
この項には次のトピックが含まれます:
Webアプリケーションにログインしたユーザーが認可されていないリソースにアクセスしようとすると、HTTP FORBIDDEN (403)レスポンスが生成されます。これは、Webアプリケーションの標準的な動作です。しかしWebLogic Serverでは、以前のリリースとの後方互換性を確保するため、weblogic.xmlデプロイメント記述子ファイルのrelogin-enabled要素を使用して、アクセス失敗のレスポンスが生成されると認証がリクエストされるようになっています。状況によっては、これが原因でSAML 2.0ベースのWebシングル・サインオンが失敗する可能性があります。
通常、SAML 2.0アサーション・コンシューマ・サービス(ACS)は、ユーザーをアプリケーションにログインさせた後、ユーザー・リクエストをターゲットWebアプリケーションにリダイレクトします。しかし、そのWebアプリケーションでSAML 2.0シングル・サインオンが有効になっていてCLIENT-CERT認証で保護されている場合に、relogin-enabledデプロイメント記述子要素がtrueに設定されていると、ユーザーの認証リクエストが繰返し発行されて無限ループが発生するおそれがあります。ユーザーがWebアプリケーションにログインした後に認可されていないリソースにアクセスしようとすると、FORBIDDENメッセージが生成されずに新しい認証リクエストが生成されるため、別のSAML 2.0ベースのWebシングル・サインオンが試行されてループが発生します。
CLIENT-CERT認証で保護されているWebアプリケーションでこのような状況が発生するのを回避するには、Webアプリケーションのrelogin-enabledデプロイメント記述子要素を削除するかfalseに設定します。これにより、Webアプリケーションの標準的な認証動作になります。
アサーション・コンシューマ・サービスがアサーションに含まれているサブジェクトをログインさせると、HTTPサーブレット・セッションがデフォルトのCookie名JSESSIONIDで作成されます。アサーションの処理が正常に完了すると、ACSによってユーザーのリクエストがターゲットWebアプリケーションにリダイレクトされます。ここで、ターゲットWebアプリケーションにおいてJSESSIONID以外のCookie名が使用されていると、サブジェクトのIDがターゲットWebアプリケーションに伝播されません。そのため、サーブレット・コンテナではユーザーが認証されていないかのように処理され、結果として認証リクエストが発行されます。
このような状況を回避するため、SAML 2.0ベースのシングル・サインオン用に構成されたドメインでWebアプリケーションをデプロイする際は、デフォルトのCookie名を変更しないようにしてください。
ログインに関しては、以下の2つの制限に留意してください。これらはクラスタ環境ではまれにしか発生しませんが、発生するとシングル・サインオン・セッションが失敗する可能性があります。
IDプロバイダのシングル・サインオン・サービスは、認証リクエストを受け取ると、ユーザーを認証するためにそのリクエストをログイン・アプリケーションにリダイレクトします。ログイン・アプリケーションは、シングル・サインオン・サービスと同じクラスタ・ノードで実行する必要があります。そうしないと、認証が成功しても、IDプロバイダでSAML 2.0アサーションを生成することができません。
通常の状況においてはログイン・アプリケーションをシングル・サインオン・サービスと同じノードで実行するため、認証リクエストがドメイン内の別のノードで実行されているログイン・アプリケーションにリダイレクトされる可能性は非常に低いといえます。しかし、ログイン・アプリケーションをホストするクラスタ・ノードとは別のノードによって認証リクエストがリダイレクトされると、このような状況が発生する可能性があります。こうした状況は、基本認証でデフォルトのログインURIが使用されるようにIDプロバイダを構成することで確実に回避できます。
SAML 2.0アサーション・コンシューマ・サービス(ACS)は、アサーションを正常に消費すると、アサーションによって表現されたサブジェクトをログインさせます。次にACSは、ユーザー・リクエストをターゲット・アプリケーションにリダイレクトします。通常、ターゲット・アプリケーションはACSと同じノードで実行されています。しかしまれなケースとして、ユーザー・リクエストのリダイレクト先となるターゲット・アプリケーションが、ログインが発生したACSをホストするクラスタ・ノードとは別のノードで実行されていることがあります。このような状況が発生すると、アサーションによって表現されたIDがターゲット・アプリケーションのノードに伝播されません。その結果、シングル・サインオン・プロセスが再試行されるか、アクセスが拒否されます。
通常はターゲット・アプリケーションはACSと同じノードで実行されるため、このような状況は非常にまれにしか発生しません。
SAML 2.0サービス・プロバイダ・サービスを構成する場合、強制認証とパッシブ属性の両方を有効にすると、WebLogic Serverが検出できない無効な構成となります。これらの属性がどちらも有効な場合に非認証ユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成され、シングル・サインオン・セッションが失敗します。
WebLogic ServerではSAMLログアウトがサポートされないため、「強制認証」属性の効果がない点に注意してください。ユーザーがIDプロバイダ・サイトですでに認証され、「強制認証」が有効な場合でも、そのユーザーは、IDプロバイダ・サイトで再認証が強制されることはありません。
