| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.3) B61617-01 |
|
 前 |
 次 |
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フレームワークによるシングル・サインオン」
ここでは以下について説明します。
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は、アサーティング・パーティの構成でも指定されます。
署名用の証明書を追加します。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フォーム」属性に設定します。
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アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ)です。アサーティング・パーティは、管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→資格証明マッパー→「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パートナ(リライイング・パーティとアサーティング・パーティ)はレジストリに保持されます。WebLogic管理コンソールまたはWebLogic Scripting Toolを使用してSAMLパートナを構成できます。次の例では、WLSTをオンライン・モードで使用して2つのリライイング・パーティを構成する方法を示します。
例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 1.1資格証明マッピング・プロバイダ・バージョン2を使用してソース・サイトを構成し、WebLogic Server以外のプラットフォームで実装されるサード・パーティのSAMLリライイング・パーティを構成する場合、WebLogic Serverで生成されるSAMLアサーションは、構成されたサード・パーティのSAMLリライイング・パーティで必要な属性をすべてサポートするわけではありません。この場合、アサーションの予想される属性が使用できないため、リライイング・パーティはアサーティング・パーティと連動できません。
サード・パーティのSAMLリライイング・パーティで必要な特定のSAML 1.1アサーション属性にサブジェクトをマップするカスタムSAML名マッパーを作成するには、WebLogic Serverで提供されるSAMLCredentialAttributeMapperインタフェースを実装します。SAMLCredentialAttributeMapperの詳細は、Oracle Fusion Middleware Oracle WebLogic Server APIリファレンスで入手できます。
次の項では、カスタムSAML名マッパーを作成する方法について説明します。
SAMLCredentialAttributeMapperインタフェースのカスタム実装を作成するには、次の操作を行う必要があります。
次のクラスを使用して、アサーションの属性データを記述します。
SAMLCredentialNameMapperインタフェースを実装します。SAMLCredentialAttributeMapperインタフェースとSAMLCredentialNameMapperインタフェースは、どちらも同じ実装内に存在する必要があります。
SAMLCredentialNameMapperインタフェースを実装すると、WebLogic Server管理コンソールを使用して、このSAMLCredentialAttributeMapperインスタンスのクラス名にNameMapperClassName属性を設定できます。
SAML資格証明マッピング・プロバイダ・バージョン2の「ユーザー名マッパーのクラス名」属性を使用して、アクティブなセキュリティ・レルムでカスタムSAML名マッパーを構成します。
SAMLNameMapperInfoクラスに追加された2つのメソッドを使用して、SAMLアサーションに書き込まれる認証メソッド属性を取得および設定します。
「コンソールでカスタムSAMLCredentialAttributeMapperクラスを使用可能にする」で説明するように、SAML資格証明マッピング・プロバイダ・バージョン2に構成するデフォルト名マッパーのクラス名は、そのプロバイダのデフォルトとして使用されます。ただし、SAML資格証明マッピング・プロバイダ・バージョン2に構成されるリライイング・パーティの一部または全部に固有の名前マッパーのクラス名をオプションで設定できます。この方法で名前マッパーのクラス名を設定すると、デフォルト値がオーバーライドされます。構成されたSAMLリライイング・パーティで異なる属性が必要な場合、複数のSAMLCredentialAttributeMapper実装を作成できます。
この項では、カスタムSAML名マッパー実装の作成時に使用する必要がある新しいクラス、インタフェース、およびメソッドについて説明します。コード例については、「カスタムSAMLCredentialAttributeMapperクラスの例」を参照してください。
例7-3は、SAMLAttributeStatementInfoクラスのメソッドと引数を示しています。埋め込まれているコメントにより、追加情報とコンテキストが提供されます。
例7-3 SAMLAttributeStatementInfoクラスの記述
/**
* A class that represents the attributes of an AttributeStatement
* in a SAML Assertion
*/
class SAMLAttributeStatementInfo {
/**
* Constructs a SAMLAttributeStatementInfo with
* no attributes. The SAMLAttributeStatementInfo
* represents a empty SAMLAttributeStatement. It is
* expected that SAMLAttributeInfo elements will be
* added to this instance.
*
Public SAMLAttributeStatementInfo();
/**
* Constructs a SAMLAttributeStatementInfo containing multiple
* SAMLAttributeInfo elements. The SAMLAttributeStatementInfo
* represents a SAML AttributeStatement with multiple Attributes.
*
*
* @param data SAMLAttributeInfo
*/
public SAMLAttributeStatementInfo(Collection data);
/**
* returns a Collection of SAMLAttributeInfo elements. The
* collection represents the Attributes contained by
* a single AttributeStatement of a SAML Assertion
*
* The returned Collection is immutable and may be empty.
*
* @return Collection
*/
public Collection getAttributeInfo();
/**
* adds a Collection of SAMLAttributeInfo instances to
* this SAMLAttributeStatementInfo instance, to the
* end of the existing list, in the order that the
* param Collection iterates through the Collection.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param data
*
*/
public void setAttributeInfo(Collection data);
/**
* Adds a single SAMLAttributeInfo instance to this
* SAMLAttributeStatementInfo instance, at the end of
* the existing list.
*
* See SAMLAttributeInfo(String, String, Collection)
* for information on parameter handling.
*
* @param info
*/
public void addAttributeInfo(SAMLAttributeInfo info);
例7-4は、SAMLAttributeInfoクラスのメソッドと引数を示しています。埋め込まれているコメントにより、追加情報とコンテキストが提供されます。
例7-4 SAMLAttributeInfoクラスの記述
/**
* A class that represents a single Attribute of a SAML Assertion
* AttributeStatement.
*/
class SAMLAttributeInfo {
/**
* Constructs a SAMLAttributeInfo instance with all null fields
*/
public SAMLAttributeInfo();
/**
* Constructs a SAMLAttributeInfo instance representing the SAML 1.1
* Attribute fields
*
* null elements of the Collection are ignored.
* Elements with null 'name' or 'namespace' fields
* are ignored; the resulting SAMLAttributeInfo will not
* be included in a created SAMLAssertion. Null
* attribute values are added as the empty string (ie, “”).
* @param name String
* @param namespace String
* @param values Collection of String values
*/
public SAMLAttributeInfo(String name, String namespace, Collection values;
/**
* Constructs a SAMLAttributeInfo instance representing the attribute fields
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String
* @param namespace String
* @param value String
*/
public SAMLAttributeInfo(String name, String namespace, String value);
/**
* sets the name and namespace of this attribute
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param name String, cannot be null
* @param namespace String, cannot be null
*/
public void setAttributeName(String name, String namespace);
/**
* returns the name of this attribute.
* @return String
*/
public String getAttributeName();
/**
* returns a String representing this attribute's namespace
* @return String
*/
public String getAttributeNamespace();
/**
* sets a Collection of Strings representing this attribute's values
* an empty collection adds no values to this instance, collection elements
* that are null are added as empty strings.
*
* @param values Collection
*/
public void setAttributeValues(Collection values);
/**
* adds a single String value to the end
* of this instance's Collection of elements
* See SAMLAttributeInfo(String, String, Collection) for
* information on parameter handling.
*
* @param value String
*/
public void addAttributeValue(String value);
/**
* returns a Collection of Strings representing this
* attribute's values, in the order they were added.
* If this attribute has no values, the returned
* value is null.
*
* @return Collection
*/
public Collection getAttributeValues();
}
SAML資格証明マッピング・プロバイダ・バージョン2は、カスタムSAML名マッパーが属性マッピング・インタフェースの実装であるかどうかを判断します。属性マッピング・インタフェースの実装の場合、属性マッピング・インタフェースのメソッドを呼び出し、生成されたSAMLアサーションに書き込むサブジェクトの値を取得します。実装で属性マッピング・インタフェースをサポートしない場合、属性マッピングはそのまま省略されます。
SAML資格証明マッピング・プロバイダ・バージョン2は、カスタム属性マッパーから取得された属性の名前や値を検証しません。属性の名前と値は次のように扱われます。
属性の名前とネームスペースがNULL以外の属性はSAMLアサーションに書き込まれます。
属性の名前やネームスペースがNULLの属性は無視され、同じコレクションの以降の属性は通常どおり処理されます。
値がNULLの属性は、値が""のSAMLAttributeInfoインスタンスに書き込まれます。結果として作成されるSAMLアサーションは、文字列<AttributeValue></AttributeValue>として書き込まれます。
例7-5 SAMLCredentialAttributeMapperインタフェースの記述
/**
* Interface used to perform mapping of Subject to SAMLAssertions
* attributes.
* <p>
* To specify an instance of this interface to be used by the SAML
* Credential Mapper, set the <tt>NameMapperClassName</tt> attribute.
* <p>
* Classes implementing this interface must have a public no-arg
* constructor and must be in the system classpath.
*
* @author Copyright (c) 2008 by BEA Systems, Inc. All Rights Reserved.
*/
public interface SAMLCredentialAttributeMapper
{
/**
* Maps a <code>Subject</code> to a set of values used to construct a
* <code>SAMLAttributeStatementInfo</code> element for a SAML assertion.
* The returned <code>Collection</code> contains
* SAMLAttributeStatementInfo elements, each element
* of which will be used to
* construct a SAML <code>AttributeStatement</code> element for the SAML
* assertion.
*
* @param subject The <code>Subject</code> that should be mapped.
* @param handler The <code>ContextHandler</code> passed to the SAML
* Credential Mapper.
*
* @return A <code>Collection</code> of SAMLAttributeStatementInfo
* instances,or <code>null</code> if no mapping is made.
*/
public Collection mapAttributes(Subject subject, ContextHandler handler);
SAMLCredentialNameMapperは、SAMLNameMapperInfoクラスに対して新しいメソッドを呼び出し、SAMLアサーションに書き込まれる認証メソッド属性を取得および設定します。
例7-6に新しいメソッドを示します。埋め込まれているコメントにより、追加情報とコンテキストが提供されます。
例7-6 SAMLNameMapperInfoクラスの記述
public class SAMLNameMapperInfo
{
[ existing definition ]
/**
* Called by the SAML Credential Name Mapper implementation to set
* the authentication method attribute to be written to the SAML Assertion.
* See SAML 1.1 Assertions and Protocols, Section 7.1 for possible
* values returned.
*
* @param value the Authentication Method
*/
public void setAuthenticationMethod(String value);
/**
* Called by the SAML Credential Mapper to retrive the authentication
* method attribute to be written to the SAML Assertion. See SAML 1.1
* Assertions and Protocols, Section 7.1 for possible values returned.
*
* @return the Authentication Method
*/
public String getAuthenticationMethod();
例7-7は、SAMLCredentialNameMapperインタフェースとSAMLCredentialAttributeMapperインタフェースの実装例を示しています。
SAMLCredentialNameMapperの実装例は、サブジェクトに格納されているユーザーとグループの情報をマップし、実SAMLCredentialAttributeMapperの実装例は、ContextHandlerに格納されている属性情報をマップします。
この例では、ContextHandlerでの属性の配置方法は示されていません。
SAMLCredentialAttributeMapperを実装して、ContextHandler以外のサブジェクトに格納されている情報をマップする点に注意してください。
埋め込まれているコメントにより、追加情報とコンテキストが提供されます。
例7-7 カスタムSAMLCredentialAttributeMapperクラスの例の記述
import java.util.ArrayList;
import java.util.Collection;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.security.providers.saml.SAMLAttributeStatementInfo;
import weblogic.security.providers.saml.SAMLAttributeInfo;
import weblogic.security.providers.saml.SAMLCredentialNameMapper;
import weblogic.security.providers.saml.SAMLCredentialAttributeMapper;
import weblogic.security.providers.saml.SAMLNameMapperInfo;
import weblogic.security.service.ContextHandler;
import weblogic.security.service.ContextElement;
import weblogic.security.spi.WLSGroup;
import weblogic.security.spi.WLSUser;
/**
* @exclude
*
* The <code>CustomSAMLAttributeMapperImpl</code> class implements
* name and attribute mapping for the SAML Credential Mapper.
*
* @author Copyright (c) 2004 by BEA Systems, Inc. All Rights Reserved.
*/
public class CustomSAMLAttributeMapperImpl implements
SAMLCredentialNameMapper,SAMLCredentialAttributeMapper
{
/**
* Your logging code here
*/
private final static String defaultAuthMethod =
"urn:oasis:names:tc:SAML:1.0:am:unspecified";
private final static String SAML_CONTEXT_ATTRIBUTE_NAME =
"com.bea.contextelement.saml.context.attribute.name";
private String nameQualifier = null;
private String authMethod = defaultAuthMethod;
public CustomSAMLAttributeMapperImpl()
{
// make constructor public
}
/**
* Set the name qualifier value
*/
public synchronized void setNameQualifier(String nameQualifier) {
this.nameQualifier = nameQualifier;
}
/**
* Map a <code>Subject</code> and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/
public SAMLNameMapperInfo mapSubject(Subject subject, ContextHandler handler) {
// Provider checks for null Subject...
Set subjects = subject.getPrincipals(WLSUser.class);
Set groups = subject.getPrincipals(WLSGroup.class);
String userName = null;
if (subjects == null || subjects.size() == 0) {
yourlogcode("mapSubject: No valid WLSUser principals
found in Subject, returning null");
return null;
}
if (groups == null || groups.size() == 0) {
yourlogcode("mapSubject: No valid WLSGroup pricipals
found in Subject, continuing");
}
if (subjects.size() != 1) {
yourlogcode("mapSubject: More than one WLSUser
principal found in Subject, taking first user only");
}
userName = ((WLSUser)subjects.iterator().next()).getName();
if (userName == null || userName.equals("")) {
yourlogcode("mapSubject: Username string is null or
empty, returning null");
return null;
}
// Return mapping information...
yourlogcode("mapSubject: Mapped subject: qualifier: " +
nameQualifier + ", name: " + userName + ", groups: " + groups);
return new SAMLNameMapperInfo(nameQualifier, userName,
groups);
}
/**
* Map a <code>String</code> subject name and return mapped user and group
* info as a <code>SAMLNameMapperInfo</code> object.
*/
public SAMLNameMapperInfo mapName(String name, ContextHandler handler) {
yourlogcode("mapName: Mapped name: qualifier: " +
nameQualifier + ", name: " + name);
return new SAMLNameMapperInfo(nameQualifier, name, null);
}
/**
* Returns the SAML AttributeName for group information.
*
* @return The AttributeName.
*/
public String getGroupAttrName() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAME;
}
/**
* Returns the SAML AttributeNamespace for group information.
*
* @return The AttributeNamespace.
*/
public String getGroupAttrNamespace() {
return SAMLNameMapperInfo.BEA_GROUP_ATTR_NAMESPACE;
}
/**
* set the auth method.
* @param method String
*/
public void setAuthenticationMethod(String method)
{
if (method != null)
authMethod = method;
}
/**
* get the auth method
* @return method String
*/
public String getAuthenticationMethod()
{
return authMethod;
}
/**
* maps a Subject/Context to a Collection of SAMLAttributeStatementInfo
* instances.
*
* @return <code>Collection</code>
*/
public Collection mapAttributes(Subject subject, ContextHandler handler)
{
yourlogcode("mapAttributes: Subject: "+subject.toString()+",
ContextHandler: "+handler.toString());
Object element = handler.getValue(SAML_CONTEXT_ATTRIBUTE_NAME);
yourlogcode("mapAttributes: got element from ContextHandler");
yourlogcode("mapAttributes: element is a:"+element.getClass().getName());
TestAttribute[] tas = (TestAttribute[])element;
/*
* loop through all test attributes and write a SAMLAttributeStatementInfo
* for each one.
*/
ArrayList statementList = new ArrayList();
for (int k = 0; k < tas.length; k++)
{
ArrayList al = null;
String[] values = tas[k].getValues();
if (values != null)
{
al = new ArrayList();
for (int i = 0; i < values.length; i++)
if (values[i] != null)
al.add(values[i]);
else al.add("");
}
SAMLAttributeInfo ai = new SAMLAttributeInfo(tas[k].getName(),
tas[k].getNamespace(), al);
SAMLAttributeStatementInfo asi = new
SAMLAttributeStatementInfo();
asi.addAttributeInfo(ai);
statementList.add(asi);
}
return statementList;
}
}
SAML資格証明マッピング・プロバイダ・バージョン2で該当のSAMLCredentialAttributeMapperインスタンスを使用するには、WebLogic Server管理コンソールを使用して、該当のSAMLCredentialAttributeMapperインスタンスのクラス名に既存のNameMapperClassName属性を設定します。
つまり、名前マッパーのクラス名属性のコンソール制御を使用して、アクティブなセキュリティ・レルムでSAMLCredentialAttributeMapperのクラス名を指定します。
ユーザー名マッパーのクラス名属性は、次のいずれかの方法で構成できます。
SAML資格証明マッピング・プロバイダ・バージョン2に対して一度構成します。
1つ以上のリライイング・パーティに対して個別に構成します。
SAML資格証明マッピング・プロバイダ・バージョン2に対して構成し、さらにリライイング・パーティに対して個別に構成します。
WebLogic SAML資格証明マッピング・プロバイダ・バージョン2でカスタム・ユーザー名マッパーを使用するには、次の操作を行います。
まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
「セキュリティ・レルム」ページで、構成するレルムの名前を選択します(TestRealmなど)。
「プロバイダ」→「資格証明マッピング」を展開し、SAML資格証明マッピング・プロバイダ・バージョン2の名前を選択します。
「プロバイダ固有」タブを選択します。
「デフォルト名前マッパーのクラス名」フィールドに、SAMLCredentialAttributeMapper実装のクラス名を入力します。
クラス名はCLASSPATH内にある必要があります。
「保存」をクリックします。
「チェンジ・センター」で、「変更のアクティブ化」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
すべての変更がすぐに反映されるわけではありません。再起動が必要な場合もあります。
SAMLリライイング・パーティを構成する場合、そのリライイング・パーティに固有の名前マッパー・クラスをオプションで設定できます。これにより、デフォルト名前マッパーのクラス名に対してここで設定したデフォルト値がオーバーライドされます。
管理コンソールで名前マッパーのクラス名を設定する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ユーザー名マッパーの構成に関する項を参照してください。
ここでは以下について説明します。
ここでは、SAML 2.0サービスを構成する主な手順を示します。
SAML 2.0サービスを、ドメイン内の複数のWebLogic Serverインスタンスで実行する可能性があるかどうかを検討します。その可能性がある場合は、次の手順に従います。
RDBMSセキュリティ・ストアを構成するドメインを作成します。
RDBMSセキュリティ・ストアを使用すると、SAML 2.0セキュリティ・プロバイダで管理するデータを、それらを共有するすべての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プロバイダ・パートナを作成して構成します。
これ以降の節では、これらの手順について詳しく説明します。
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セキュリティ・ストアを使用するように構成されたドメインを作成する必要があります。詳細については、「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プロバイダ・サイトで再認証が強制されることはありません。
