| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.4) B61617-02 |
|
 前 |
 次 |
Security Assertion Markup Language (SAML)を使用すると、WebLogic Serverドメインで実行されているWebアプリケーションまたはWebサービスと、Webブラウザまたはその他のHTTPクライアントの間でクロス・プラットフォーム認証を実行できます。WebLogic ServerではSAMLに基づくシングル・サインオン(SSO)がサポートされています。シングル・サインオン(SSO)構成に参加する1つのサイトでユーザーが認証されると、SSO構成の他のサイトでも自動的に認証されるので、別個にログインする必要がありません。
以下の節では、Security Assertion Markup Language (SAML)バージョン1.1および2.0に基づく認証を使用して、Webブラウザまたはその他のHTTPクライアントによるシングル・サインオン(SSO)を設定する方法について説明します。
|
注意: SAML 2.0 SSO用に構成されたWebLogic Serverインスタンスと、SAML 1.1用に構成されたインスタンスの間で、リクエストを送受信することはできません。 |
SAMLベースのシングル・サインオンの概要については、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』の次のトピックを参照してください。
「SAML (Security Assertion Markup Language)」
「SAMLの使用によるWebブラウザとHTTPクライアント」
「WebLogic Securityフレームワークによるシングル・サインオン」
ホワイト・ペーパー「WebLogic Server 9.2におけるSAMLを使用したシングル・サインオンの構成」(http://www.oracle.com/technology/pub/articles/dev2arch/2006/12/sso-with-saml.html)は、2種類のWebLogicドメインで稼働しているJava EE Webアプリケーション間のシングル・サインオン機能の構成に関するステップ・バイ・ステップの手順を提供します。シングル・サインオン用のSAML構成は、WebLogic Server 9.2管理コンソールを使用してプログラミングを組み込まずに実行されます。また、このチュートリアルでは、シングル・サインオン処理中のWebLogicコンテナ、セキュリティ・プロバイダ、およびセキュリティ・フレームワーク間の基本的な相互作用を簡単に紹介します。
以前のバージョンのWebLogic Serverに基づいていますが、このチュートリアルは独自のSAML実装を開発する際に有用なリソースとなります。
ここでは以下について説明します。
サードパーティのSAMLリライイング・パーティによって要求される固有のSAML 1.1アサーション属性に件名をマッピングするカスタムSAML名前マッパーを作成する方法に関する詳細は、前述の項で説明されるトピックに加え、『Oracle WebLogic Serverセキュリティのプログラミング』の非WebLogic SAML 1.1リライイング・パーティ用アサーションの作成に関する項を参照してください。
SAMLによるシングル・サインオンを有効にするには、以下の手順に従って、WebLogic Serverをソース・サイトまたは宛先サイトとして構成します。
WebLogic Serverインスタンスをソース・サイトとして構成するには、次の主な手順を実行します:
使用するセキュリティ・レルムで、SAML資格証明マッピング・プロバイダV2を作成して構成します。
レルム内でソース・サイトとして機能するサーバー・インスタンスのフェデレーション・サービスを構成します。
生成されるSAMLアサーションのリライイング・パーティを作成し、構成します。
ソース・サイトへの接続にSSL証明書を使用するようにリライイング・パーティを設定する場合は、SAML資格証明マッピング・プロバイダの証明書レジストリにそれらの証明書を追加します。
以下の節では、WebLogic ServerインスタンスをSAML 1.1ソース・サイトとして構成する方法について説明します。
使用するセキュリティ・レルムで、SAML資格証明マッピング・プロバイダV2のインスタンスを作成します。SAML資格証明マッピング・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 1.1用のSAML資格証明マッピング・プロバイダの構成」を参照してください。
SAML資格証明マッピング・プロバイダをSAML認証局として構成するには、「発行者URI」、「名前修飾子」などの属性を設定します。
SAML 1.1ソース・サイトとしてのWebLogic Serverインスタンスの構成は、FederationServicesMBeanによって制御されます。FederationServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」→「サーバー」→「サーバー名」→「構成」→「フェデレーション・サービス」→「SAML 1.1ソース・サイト」ページ)を使用してアクセスします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1ソース・サービスの構成に関する項を参照してください。
SAMLソース・サイトの属性は以下のように構成します。
SAMLソース・サイトを有効にします。Source Site Enabled (「ソース・サイトを有効化」)をtrueに設定して、WebLogic ServerインスタンスがSAMLソース・サイトとして動作するようにします。
ソース・サイトのURLとサービスURIを設定します。SAMLソース・サイトのURLを設定します。これは、サイト間転送サービスおよびアサーション検索サービスをホストするURLです。ソース・サイトURLは、ソースIDとして16進数およびBase64でエンコードされます。ブラウザ/アーティファクト・プロファイルのSAMLアサーティング・パーティを構成するときに、このエンコードされたソースIDを指定します。
サイト間転送サービスおよびアサーション取得サービス(ブラウザ/アーティファクト・プロファイルをサポートするため)のURIを指定します(リライイング・パーティの構成時にもサイト間転送サービスURIを指定できます)。
デフォルトURIのFederationServicesMBean.IntersiteTransferURIsの値は、表7-1に示されています。
表7-1 サイト間転送URI
| デフォルトURI値 | 説明 |
|---|---|
|
/samlits_ba/its |
BASIC認証、POSTまたはアーティファクト・プロファイル |
|
/samlits_ba/its/post |
BASIC認証、POSTプロファイル |
|
/samlits_ba/its/artifact |
BASIC認証、アーティファクト・プロファイル |
|
/samlits_cc/its |
クライアント証明書認証、POSTまたはアーティファクト・プロファイル |
|
/samlits_cc/its/post |
クライアント証明書認証、POSTプロファイル |
|
/samlits_cc/its/artifact |
クライアント証明書認証、アーティファクト・プロファイル |
サイト間転送URIテキスト・ボックスを使用すると、デフォルト値をそのまま使用するか、または選択内容に応じて値を変更できます。各URIにはアプリケーション・コンテキストが含まれ、後には/its、/its/post、または/its/artifactが続きます。提供されるアプリケーション・コンテキストは、/samlits_ba (BASIC認証)または/samlits_cc (クライアント証明書認証)です。必要に応じて、/yourapplication/itsなどのアプリケーション固有のコンテキストも指定できますが、たいていの場合はデフォルトが最も使いやすい構成オプションです。
これらのURIを/samlits_ba/itsに指定し、リダイレクトが発生してソース・サイト上のユーザー・セッションがタイムアウトした場合、BASIC認証ダイアログが表示されます。かわりにFORMダイアログを使用する場合、URIは、ユーザーを認証して実際のITS URIに転送するカスタムWebアプリケーションを示します。
署名用の証明書を追加します。SAMLソース・サイトでは、アサーションの署名に使用する信頼性のある証明書が必要になります。キーストアにこの証明書を追加して、この証明書へのアクセスに使用される資格証明(別名とパスワード)を入力します。署名用の別名とパスワードが指定されていない場合、デフォルトではサーバーのSSL IDキー/証明書が使用されます。
アサーション検索サービス用のSSLを構成します。FederationServicesMBean.arsRequiresSSLをtrueに設定することで、アサーション検索サービスへのすべてのアクセスでSSLを使用するようにできます。arsRequiresSSLとARSRequiresTwoWaySSLの両方をtrueに設定することで、アサーション検索サービスに対する双方向SSL認証を要求できます。
SAMLリライイング・パーティは、SAMLソース・サイトによって生成されるSAMLアサーションの情報によって変わるエンティティです。WebLogic Serverで各リライイング・パーティに対し別個にSAMLアサーションを生成する方法を構成するか、フェデレーション・サービス・ソース・サイトの構成で設定されたデフォルトを使用してアサーションを生成します。
リライイング・パーティは、管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→資格証明マッパー→「SAMLCredentialMapperName」→「管理」→「リライイング・パーティ」ページで構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1リライイング・パーティの作成に関する項とSAML 1.1リライイング・パーティの構成に関する項を参照してください。
WebLogic Scripting Toolを使用してリライイング・パーティを構成できます。「WLSTを使用したリライイング・パーティとアサーティング・パーティの構成」を参照してください。
SAMLリライイング・パーティを構成するときに、SAML SSO用としてアーティファクト・プロファイルまたはPOSTプロファイルのサポートを指定できます。かわりに、Webサービス・セキュリティ用としてWSS/Holder-of-KeyプロファイルまたはWSS/Sender-Vouchesプロファイルをサポートするリライイング・パーティを構成することもできます。SAML宛先サイトがサポートするプロファイルのサポートを構成してください。
POSTプロファイルをサポートする場合は、必要に応じて、リライイング・パーティのPOSTプロファイル・アサーションで使用するフォームを作成し、そのパス名を「POSTフォーム」属性に設定します。
各SAMLリライイング・パーティに対して、宛先サイトへのリダイレクト時にACS URLに付加される1つまたは複数の問合せパラメータを任意で構成できます。POSTプロファイルの場合、用時にこデフォルトのPOSTフォームの使れらのパラメータがフォーム変数として組み込まれます。カスタムPOSTフォームの使用中は、パラメータは名前と値のマップとして使用可能になりますが、フォームがPOSTされるデータにパラメータが含まれるように作成される場合と、そうでない場合があります。
別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、リライイング・パーティACSパラメータのSAMLアサーティング・パーティのID (APID)を設定します。
ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。つまり、ACSはアサーティング・パーティID (APID)をリクエスト受信時のパラメータとして検索し、これを使用して他の処理を実行する前に構成を参照します。
また、APIDパラメータを使用すると、ブラウザSSOのターゲットURLパラメータを指定する必要がなくなります。ターゲットURLはWebサービスの構成に使用されます。
WebLogic Serverでは、単純なアサーション・ストアを使用して、生成されるアサーションの永続性を保持します。このアサーション・ストアを、weblogic.security.providers.saml.AssertionStoreV2を実装するカスタム・アサーション・ストア・クラスに置き換えることができます。FederationServicesMBean.AssertionStoreClassName属性を使用して、デフォルトのクラスではなく、カスタム・アサーション・ストア・クラスを使用するようにWebLogic Serverを構成します。FederationServicesMBean.AssertionStoreProperties属性を使用して、カスタム・アサーション・ストア・クラスのinitStore()メソッドに渡されるプロパティを構成できます。これらの属性は、管理コンソールの「環境: サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1ソース・サイト」ページで構成します。
以下の節では、WebLogic ServerをSAML宛先サイトとして構成する方法について説明します。
使用するセキュリティ・レルムで、SAML IDアサーション・プロバイダV2のインスタンスを作成し、構成します。SAML IDアサーション・プロバイダは、デフォルト・セキュリティ・レルムの一部ではありません。「SAML 1.1用のSAML IDアサーション・プロバイダの構成」を参照してください。
WebLogicをSAML宛先サイトとして構成する前に、まず使用するセキュリティ・レルムで、SAML IDアサーション・プロバイダV2のインスタンスを作成する必要があります。SAML宛先サイトとしてのWebLogic Serverインスタンスの構成はFederationServicesMBeanによって制御されます。FederationServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境: サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1宛先サイト」ページ)を使用してアクセスします。
SAML宛先サイトの属性は以下のように構成します。
SAMLアサーション・コンシューマ・サービスのURIを設定します。これは、ソース・サイトからアサーションを受信するURLです。これにより、宛先サイトはアサーションを使用してユーザーを認証できます。アサーション・コンシューマURIは、リライイング・パーティの構成でも指定されます。
FederationServicesMBean.acsRequiresSSLをtrueに設定することで、アサーション・コンシューマ・サービスへのすべてのアクセスでSSLを使用するように設定できます。
SSLクライアントIDは、アーティファクト・プロファイルのソース・サイトでARSにアクセスするために使用します。キーストアにこの証明書を追加して、この証明書へのアクセスに使用される資格証明(別名とパスワード)を入力します。
必要に応じて、各POSTプロファイル・アサーションの使用を1回のみに設定できます。アサーションの使い捨てポリシーをサポートできるように、WebLogic Serverには使用済みのアサーションのキャッシュが保持されています。このアサーション・キャッシュを、weblogic.security.providers.saml.SAMLUsedAssertionCacheを実装するカスタム・アサーション・キャッシュ・クラスに置き換えられます。FederationServicesMBean.SAMLUsedAssertionCache属性を使用して、デフォルトのクラスではなく、カスタム・アサーション・キャッシュ・クラスを使用するようにWebLogic Serverを構成します。FederationServicesMBean.UsedAssertionCacheProperties属性を使用して、カスタム・アサーション・キャッシュ・クラスのinitCache()メソッドに渡されるプロパティを構成できます。これらの属性は、管理コンソールの「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 1.1宛先サイト」ページで構成できます。
SAMLアサーティング・パーティとは、信頼できるSAMLオーソリティです(SAMLアサーションの形式でセキュリティ情報を厳格にアサートできるエンティティ)。
アサーティング・パーティは、管理コンソールの「セキュリティ・レルム」>RealmName>「プロバイダ」>「認証」>SAMLIdentityAsserterV2>「管理」:「アサーティング・パーティ」ページで構成します。『Oracle WebLogic Server管理コンソール・ヘルプ』のSAML 1.1アサーティング・パーティの作成に関する項およびSAML 1.1アサーティング・パーティの構成に関する項を参照してください。
WebLogic Scripting Toolを使用してアサーティング・パーティを構成できます。「WLSTを使用したリライイング・パーティとアサーティング・パーティの構成」を参照してください。
SAMLアサーティング・パーティを構成するときに、SAML SSO用としてアーティファクト・プロファイルまたはPOSTプロファイルのサポートを指定できます。かわりに、Webサービス・セキュリティ用としてWSS/Holder-of-KeyプロファイルまたはWSS/Sender-Vouchesプロファイルをサポートするアサーティング・パーティを構成することもできます。
各SAMLアサーティング・パーティでは、ソース・サイトにリダイレクトするときに追加されるゼロ以上のオプション問合せパラメータを構成します。
別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、アサーティング・パーティITSパラメータのSAMLリライイング・パーティのID (RPID)を設定する必要があります。
ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。つまり、ITSはRPIDをリクエスト受信時のパラメータとして検索し、これを使用して他の処理を実行する前に構成を参照します。
また、RPIDパラメータを使用すると、WebLogic Server対WebLogic ServerブラウザSSO構成専用にターゲットURLパラメータを指定する必要がなくなります。ターゲットURLはWebサービスの構成に使用されます。
SAMLパートナ(リライイング・パーティとアサーティング・パーティ)はレジストリに保持されます。WebLogic管理コンソールまたはWebLogic Scripting Toolを使用してSAMLパートナを構成できます。次の例では、WLSTをオンライン・モードで使用して2つのリライイング・パーティを構成する方法を示します。
この例では、リライイング・パーティのアサーション・コンシューマ・サービス・パラメータでSAMLアサーティング・パーティID(APID)を設定することに注意します。別のWebLogic Serverインスタンスと通信するWebLogic ServerブラウザSSO構成の場合、リライイング・パーティACSパラメータのSAMLアサーティング・パーティIDを設定する必要があります(アサーティング・パーティITSパラメータのSAMLリライイング・パーティID (RPID)も設定します)。
APIDは、WebLogic Server対WebLogic ServerブラウザSSO構成にのみ必要になります。ブラウザ・プロファイル構成が機能するためにV2プロバイダとこのパラメータの併用が必要です。
例7-1 WLSTを使用したリライイング・パーティの作成
connect('weblogic','weblogic','t3://localhost:7001')
rlm=cmo.getSecurityConfiguration().getDefaultRealm()
cm=rlm.lookupCredentialMapper('samlv2cm')
rp=cm.newRelyingParty()
rp.setDescription('test post profile')
rp.setProfile('Browser/POST')
rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')
rp.setAssertionConsumerParams(array(['APID=ap_00001'],String))
rp.setSignedAssertions(true)
rp.setEnabled(true)
cm.addRelyingParty(rp)
rp=cm.newRelyingParty()
rp.setDescription('test artifact profile')
rp.setProfile('Browser/Artifact')
rp.setAssertionConsumerURL('http://domain.example.com:7001/saml_destination/acs')
rp.setAssertionConsumerParams(array(['APID=ap_00002'],String))
rp.setARSUsername('foo')
rp.setARSPassword('bar')
rp.setSSLClientCertAlias('demoidentity')
rp.setEnabled(true)
cm.addRelyingParty(rp)
disconnect()
exit()
次の例では、既存のアサーティング・パーティを編集する方法を示します。この例では、アサーティング・パーティIDを使用してアサーティング・パーティを取得し、アサーション検索URLを設定しています。
例7-2 WLSTを使用したアサーティング・パーティの編集
connect('weblogic','weblogic','t3://localhost:7001')
rlm=cmo.getSecurityConfiguration().getDefaultRealm()
ia=rlm.lookupAuthenticationProvider('samlv2ia')
ap=ia.getAssertingParty('ap_00002')
ap.setAssertionRetrievalURL('https://hostname:7002/samlars/ars')
ia.updateAssertingParty(ap)
disconnect()
exit()
ここでは以下について説明します。
ここでは、SAML 2.0サービスを構成する主な手順を示します。
SAML 2.0サービスを、ドメイン内の複数のWebLogic Serverインスタンスで実行する可能性があるかどうかを検討します。その可能性がある場合は、次の手順に従います。
RDBMSセキュリティ・ストアを構成するドメインを作成します。
RDBMSセキュリティ・ストアを使用すると、SAML 2.0セキュリティ・プロバイダで管理するデータを、それらを共有するすべてのWebLogic Serverインスタンスの間で同期させることができます。
なお、RDBMSセキュリティ・ストアを使用するドメインを作成するかわりに、既存のドメインをアップグレードすることはお薦めできません。RDBMSセキュリティ・ストアを使用する場合は、ドメインの作成時にRDBMSセキュリティ・ストアを構成する必要があります。RDBMSセキュリティ・ストアを使用したいドメインが作成済みである場合は、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。
詳細については、第10章「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プロバイダ・パートナを作成して構成します。
これ以降の節では、これらの手順について詳しく説明します。
SAML 2.0全般サービスは、WebLogic Serverインスタンスに構成するSAML 2.0の用途に関わらず(つまり、サービス・プロバイダまたはIDプロバイダのどちらとして使用する場合でも)構成する必要があります。WebLogic ServerインスタンスのSAML 2.0全般サービスの構成は、SingleSignOnServicesMBeanで制御します。SingleSignOnServicesMBeanには、WebLogic Scripting Toolまたは管理コンソール(「環境」>「サーバー」>「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資格証明マッピング・プロバイダのどちらか、または両方)で管理しているデータを、サーバー・インスタンス間で共有して同期させることができます。
なお、レプリケーションされたキャッシュを有効にする場合は、RDBMSセキュリティ・ストアを使用することを強くお薦めします。その場合は、SAML 2.0サービスを構成する前に、RDBMSセキュリティ・ストアを使用するように構成されたドメインを作成する必要があります。詳細については、第10章「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サービス・エンド・ポイントの特定、サイトのサービスに接続するための適切なバインディング・タイプの選択など、様々な処理にかかる手間を大幅に省くことができます。
フェデレーション・パートナと共有するメタデータ・ファイルのバージョンは1つに限定する必要があります。この制約は、サイトが一部のパートナに対してサービス・プロバイダとして機能し、残りのパートナに対してはIDプロバイダとして機能する場合にも適用されます。メタデータ・ファイルのバージョンを1つに限定することで、パートナの構成設定との互換性がなくなる事態を避けることができます。
ローカル・サイトのSAML 2.0構成を変更する場合は、メタデータ・ファイルを更新する必要があります。メタデータ・ファイルはパートナと共有しているため、SAML 2.0構成を変更する頻度を最小限に抑えることで、変更に伴いパートナがレジストリを更新する頻度も抑えることができます。
フェデレーション・パートナからメタデータ・ファイルを受け取った場合は、SAML 2.0サービスが構成されているドメイン内のすべてのノードからアクセスできる場所に格納します。パートナの作成時には、パートナのメタデータ・ファイルの内容をパートナ・レジストリに反映します。
メタデータ・ファイルは、com.bea.security.saml2.providers.registry.Partner Javaインタフェースを使用して操作できます。
この節では、以下の内容について説明します。
使用するセキュリティ・レルムで、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または管理コンソール(「環境」>「サーバー」>「ServerName」>「構成」>「フェデレーション・サービス」>「SAML 2.0 IDプロバイダ」ページ)を使用してアクセスします。
次の項では、この構成タスクについて簡単に説明します。構成の詳しい手順については、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アサーションを消費するエンティティです。サービス・プロバイダ・パートナは、管理コンソールの「セキュリティ・レルム」>「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シングル・サインオン用のサービス・プロバイダ・パートナを作成して構成するには:
「SAML 2.0資格証明マッピング・プロバイダ」ページの「管理」タブで、パートナの名前とメタデータ・ファイルを指定します。
パートナ構成ページの「全般」タブで、パートナとWebLogic Serverインスタンスの間の対話を有効にします。
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 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または管理コンソール(「環境」>「サーバー」>「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プロバイダ・パートナは、管理コンソールの「セキュリティ・レルム」>「RealmName」>「プロバイダ」>「認証」>「SAML2IdentityAsserterName」>「管理」ページで構成します。
このコンソール・ページで設定できる属性には、以降の各節で示すJavaインタフェースを使用してプログラム的にアクセスできます。
サービス・プロバイダ・パートナを構成する詳しい手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 2.0 Webシングル・サインオンIDプロバイダ・パートナの作成に関する項を参照してください。
Webシングル・サインオン・パートナを構成する際に利用できるサイト情報、署名用証明書、サービス・エンド・ポイント情報の詳細は、「パートナ・サイト、証明書、サービス・エンド・ポイント情報の表示」を参照してください。
以降の節では、IDプロバイダ・パートナの構成タスクについて簡単に説明します。
Webシングル・サインオン用のIDプロバイダ・パートナを構成する前に、暗号化された電子メール、セキュアFTPなど、信頼性の高い安全な方法で、パートナのSAML 2.0メタデータ・ファイルを取得する必要があります。パートナのSAMLメタデータ・ファイルには、パートナ・サイトおよびバインディング・サポートについて記述されており、パートナの証明書やキーをはじめ、様々な情報が含まれています。パートナのメタデータ・ファイルは、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では、パートナ・サイト情報用に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は、ユーザー・リクエストをターゲットWebアプリケーションにリダイレクトします。通常、ターゲット・アプリケーションはACSと同じノードで実行されています。しかしまれなケースとして、ユーザー・リクエストのリダイレクト先となるターゲット・アプリケーションが、ログインが発生したACSをホストするクラスタ・ノードとは別のノードで実行されていることがあります。このような状況が発生すると、アサーションによって表現されたIDがターゲット・アプリケーションのノードに伝播されません。その結果、シングル・サインオン・プロセスが再試行されるか、アクセスが拒否されます。
通常はターゲット・アプリケーションはACSと同じノードで実行されるため、このような状況は非常にまれにしか発生しません。
SAML 2.0サービス・プロバイダ・サービスを構成する場合、強制認証とパッシブ属性の両方を有効にすると、WebLogic Serverが検出できない無効な構成となります。これらの属性がどちらも有効な場合に非認証ユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成され、シングル・サインオン・セッションが失敗します。
WebLogic ServerではSAMLログアウトがサポートされないため、「強制認証」属性の効果がない点に注意してください。ユーザーがIDプロバイダ・サイトですでに認証され、「強制認証」が有効な場合でも、そのユーザーは、IDプロバイダ・サイトで再認証が強制されることはありません。
目的のServerDebug構成属性をtrueに設定すると、SSO用のSAMLを使用するWebアプリケーションのデバッグを有効にできます。WebLogic Serverは、次の項で説明されるように、デバッグを実行するための様々な方法を提供します。
表7-2および表7-3では、SAML 1.1および2.0用のWebLogic Serverで提供される登録済のデバッグ・スコープと属性をリストして説明しています。
表7-2 SAML 1.1デバッグ・スコープおよび属性
| スコープ | 属性 | 説明 |
|---|---|---|
weblogic.security.saml.atn |
DebugSecuritySAMLAtn |
SAML 1.1認証プロバイダ処理に関する情報を出力します。 |
weblogic.security.saml.credmap |
DebugSecuritySAMLCredMap |
SAML 1.1資格証明マッピング・プロバイダ処理に関する情報を出力します。 |
weblogic.security.saml.lib |
DebugSecuritySAMLLib |
SAML 1.1ライブラリ処理に関する情報を出力します。 |
weblogic.security.saml.service |
DebugSecuritySAMLService |
SAML 1.1 SSOプロファイル・サービスに関する情報を出力します。 |
表7-3 SAML 2.0デバッグ・スコープおよび属性
| スコープ | 属性 | 説明 |
|---|---|---|
weblogic.security.saml2.atn |
DebugSecuritySAML2Atn |
SAML 2.0認証プロバイダ処理に関する情報を出力します。 |
weblogic.security.saml2.credmap |
DebugSecuritySAML2CredMap |
SAML 2.0資格証明マッピング・プロバイダ処理に関する情報を出力します。 |
weblogic.security.saml2.lib |
DebugSecuritySAML2Lib |
SAML 2.0ライブラリ処理に関する情報を出力します。 |
weblogic.security.saml2.service |
DebugSecuritySAML2Service |
SAML 2.0 SSOプロファイル・サービスに関する情報を出力します。 |
デバッグ・スコープまたは属性は、WebLogic Serverサーバーを起動するコマンドのオプションとして受け渡すことによって有効化できます。属性ごとのSAMLデバッグの有効化に使用できるコマンド・ライン・オプションは、表7-4にリストされています。
表7-4 SAMLデバッグのコマンドライン・オプション
| SAMLバージョン | デバッグに使用可能なコマンドライン・オプション |
|---|---|
|
SAML 1.1 |
-Dweblogic.debug.DebugSecuritySAMLAtn=true -Dweblogic.debug.DebugSecuritySAMLCredMap=true -Dweblogic.debug.DebugSecuritySAMLLib=true -Dweblogic.debug.DebugSecuritySAMLService=true |
|
SAML 2.0 |
-Dweblogic.debug.DebugSecuritySAML2Atn=true -Dweblogic.debug.DebugSecuritySAML2CredMap=true -Dweblogic.debug.DebugSecuritySAML2Lib=true -Dweblogic.debug.DebugSecuritySAML2Service=true |
SAMLデバッグを有効化するためにこの方法は静的なもので、サーバー起動時にのみ使用可能です。
WebLogic Server管理コンソールを使用してSAMLデバッグを構成するには、次の手順を完了させます。
まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします(「チェンジ・センターの使用」を参照)。
管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。
「サーバーの概要」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。
「デバッグ」をクリックします。
weblogicを展開します。
securityを展開します。
次のとおりにSAMLデバッグを有効化します。
すべてのSAML 1.1属性を網羅するSAML 1.1デバッグ・スコープを有効化するには、samlを選択して「有効化」をクリックします。
1つ以上の個別のSAML 1.1デバッグ属性を有効化するには、samlを展開し、目的の属性のスコープを展開し、目的の個別のSAML 1.1属性を選択して、「有効化」をクリックします。たとえば、samlを展開し、atnを展開し、DebugSecuritySAMLAtn属性を選択してSAML 1.0認証処理をデバッグします。
すべてのSAML 2.0属性を網羅するSAML 2.0デバッグ・スコープを有効化するには、saml2を選択して「有効化」をクリックします。
1つ以上の個別のSAML 2.0デバッグ属性を有効化するには、saml2を展開し、目的の属性のスコープを展開し、目的の個別のSAML 2.0属性を選択して、「有効化」をクリックします。たとえば、saml2を展開し、credmapを展開し、DebugSecuritySAML2Credmap属性を選択してSAML 2.0資格証明マッピング・プロバイダ処理をデバッグします。
各登録済SAMLデバッグ属性の説明は、SAMLデバッグ・スコープおよび属性についてに関する項を参照してください。
これらの変更をアクティブ化するには、管理コンソールのチェンジ・センターで、「変更のアクティブ化」 (チェンジ・センターの使用に関する項を参照)をクリックします。
SAMLデバッグ・スコープおよび属性への変更はただちに実行され、再起動する必要はありません。SAMLデバッグを有効化/無効化するための管理コンソールの使用は動的で、サーバーの稼働中に使用できます。詳細は、『Oracle WebLogic Server管理コンソール・ヘルプ』のデバッグ設定の定義に関する項を参照してください。
WebLogic Scripting Tool (WLST)を使用してSAMLデバッグ属性を構成できます。たとえば、次のコマンドはdebug.pyというデバッグ属性の設定用プログラムを実行します。
java weblogic.WLST debug.py
debug.pyプログラムには、属性DebugSecuritySAMLAtnのデバッグを有効化する次のコードが含まれます。
user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugSecuritySAMLAtn','true')
save()
activate()
JavaからWLSTを使用することができます。次の例は、DebugSecuritySAMLAtnデバッグ属性を設定するJavaプログラムのソース・ファイルを示します。
import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();
interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugSecuritySAMLAtn','true')");
interpreter.exec("save()");
interpreter.exec("activate()");
} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}
WLSTの使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。
有効化されたデバッグ属性に対応するメッセージは、サーバー・ログ・ファイルに送信されます。任意で、WebLogic Serverを起動するためのコマンドのLogMBean上でStdoutSeverity=Debug属性を受け渡すことによって、デバッグ・メッセージを標準出力に送信することも可能です。たとえば、-Dweblogic.log.StdoutSeverity=Debugがあります。
詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のメッセージの出力およびロギングに関する項を参照してください。
