|
|
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 ベースのシングル サインオンの概要については、『WebLogic Security について』の以下の節を参照してください。
SAML によるシングル サインオンを有効にするには、以下の手順に従って、WebLogic Server をソース サイトまたは送り先サイトとしてコンフィグレーションします。
WebLogic Server インスタンスをソース サイトとしてコンフィグレーションするには、次の手順に従います。
WebLogic Server インスタンスを送り先サイトとしてコンフィグレーションするには、次の手順に従います。
以下の節では、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 または Administration Console ([環境｜サーバ｜ServerName ｜コンフィグレーション｜フェデレーション サービス｜SAML 1.1 ソース サイト] ページ) を使用してアクセスします。Administration Console オンライン ヘルプの「SAML ソース サービスのコンフィグレーション」を参照してください。
SAML ソース サイトの属性は以下のようにコンフィグレーションします。
サイト間転送サービスおよび (ブラウザ/アーティファクト プロファイルをサポートするために) アサーション検索サービスの URI も指定します。これらの URI は、アサーティング パーティのコンフィグレーションでも指定されます。
FederationServicesMBean.arsRequiresSSL を true に設定することで、アサーション検索サービスへのすべてのアクセスで SSL を使用するようにできます。arsRequiresSSL と ARSRequiresTwoWaySSL の両方を true に設定することで、アサーション検索サービスに対する双方向 SSL 認証を要求できます。
SAML リライイング パーティは、SAML ソース サイトによって生成される SAML アサーションの情報によって変わるエンティティです。WebLogic Server で各リライイング パーティに対し別個に SAML アサーションを生成する方法をコンフィグレーションするか、フェデレーション サービス ソース サイトのコンフィグレーションで設定されたデフォルトを使用してアサーションを生成します。
リライイング パーティは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッパー｜SAMLCredentialMapperName｜管理｜リライイング パーティ] ページでコンフィグレーションします。Administration Console オンライン ヘルプの「SAML リライイング パーティの作成」と「SAML リライイング パーティのコンフィグレーション」を参照してください。
WebLogic Scripting Tool を使用してリライイング パーティをコンフィグレーションすることもできます。「WLST を使用したリライイング パーティとアサーティング パーティのコンフィグレーション」を参照してください。
SAML リライイング パーティをコンフィグレーションするときに、SAML SSO 用としてアーティファクト プロファイルまたは POST プロファイルのサポートを指定できます。代わりに、Web サービス セキュリティ用として WSS/Holder-of-Key プロファイルまたは WSS/Sender-Vouches プロファイルをサポートするリライイング パーティをコンフィグレーションすることもできます。SAML 送り先サイトがサポートするプロファイルのサポートをコンフィグレーションしてください。
POST プロファイルをサポートする場合は、必要に応じて、リライイング パーティの POST プロファイル アサーションで使用するフォームを作成し、そのパス名を [POST フォーム] 属性に設定します。
各 SAML リライイング パーティに対して、送り先サイトへのリダイレクト時に ACS URL に付加される 1 つまたは複数のクエリ パラメータ (パートナ ID など) を任意でコンフィグレーションできます。POST プロファイルの場合、デフォルトの POST フォームの使用時にこれらのパラメータがフォーム変数として組み込まれます。カスタム POST フォームを使用する場合、パラメータは名前と値のマップとして使用できますが、そのフォームで POST されるデータにパラメータが含まれる場合とそうでない場合があります。
WebLogic Server では、単純なアサーション ストアを使用して、生成されるアサーションの永続性を保持します。このアサーション ストアを、weblogic.security.providers.saml.AssertionStoreV2 を実装するカスタム アサーション ストア クラスに置き換えることができます。FederationServicesMBean.AssertionStoreClassName 属性を使用して、デフォルトのクラスではなく、カスタム アサーション ストア クラスを使用するように WebLogic Server をコンフィグレーションします。FederationServicesMBean.AssertionStoreProperties 属性を使用して、カスタム アサーション ストア クラスの initStore() メソッドに渡されるプロパティをコンフィグレーションできます。これらの属性は、Administration Console の [環境｜サーバ｜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 または Administration Console ([環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 1.1 送り先サイト] ページ) を使用してアクセスします。
SAML 送り先サイトの属性は以下のようにコンフィグレーションします。
[送り先サイトを有効化] を true に設定して、WebLogic Server インスタンスが SAML 送り先サイトとして動作するようにします。
SAML アサーション コンシューマ サービスの URI を設定します。これは、ソース サイトからアサーションを受信する URL です。これにより、送り先サイトはアサーションを使用してユーザを認証できます。アサーション コンシューマ URI は、リライイング パーティのコンフィグレーションでも指定されます。
FederationServicesMBean.acsRequiresSSL を true に設定することで、アサーション コンシューマ サービスへのすべてのアクセスで SSL を使用するように設定できます。
SAML 送り先サイトでは、POST プロファイル応答の署名に使用される信頼性のある証明書が使用されます。キーストアにこの証明書を追加して、この証明書へのアクセスに使用される資格 (エリアスとパスワード) を入力します。
必要に応じて、各 POST プロファイル アサーションの使用を 1 回のみに設定できます。アサーションの使い捨てポリシーをサポートできるように、WebLogic Server には使用済みのアサーションのキャッシュが保持されています。このアサーション キャッシュを、weblogic.security.providers.saml.SAMLUsedAssertionCache を実装するカスタム アサーション キャッシュ クラスに置き換えられます。FederationServicesMBean.SAMLUsedAssertionCache 属性を使用して、デフォルトのクラスではなく、カスタム アサーション キャッシュ クラスを使用するように WebLogic Server をコンフィグレーションします。FederationServicesMBean.UsedAssertionCacheProperties 属性を使用して、カスタム アサーション キャッシュ クラスの initCache() メソッドに渡されるプロパティをコンフィグレーションできます。これらの属性は、Administration Console の [環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 1.1 送り先サイト] ページ) でコンフィグレーションします。
必要に応じて、SAML 応答の受信者は HTTP リクエスト内の URL に一致しなければならないように設定できます。これを行うには、[POST 受信者チェックを有効化] 属性を設定します。
SAML アサーティング パーティは、信頼性のある SAML 認証局 (SAML アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ) です。アサーティング パーティは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッパー｜SAMLCredentialMapperName｜管理｜アサーティング パーティ] ページでコンフィグレーションします。Administration Console オンライン ヘルプの「SAML アサーティング パーティの作成」と「SAML アサーティング パーティのコンフィグレーション」を参照してください。
WebLogic Scripting Tool を使用してアサーティング パーティをコンフィグレーションすることもできます。「WLST を使用したリライイング パーティとアサーティング パーティのコンフィグレーション」を参照してください。
SAML アサーティング パーティをコンフィグレーションするときに、SAML SSO 用としてアーティファクト プロファイルまたは POST プロファイルのサポートを指定できます。代わりに、Web サービス セキュリティ用として WSS/Holder-of-Key プロファイルまたは WSS/Sender-Vouches プロファイルをサポートするアサーティング パーティをコンフィグレーションすることもできます。
各 SAML アサーティング パーティに対して、ソース サイトへのリダイレクト時に ITS URL に付加されるゼロまたはそれ以上のクエリ パラメータ (パートナ ID など) を任意でコンフィグレーションします。
SAML パートナ (リライイング パーティとアサーティング パーティ) はレジストリに保持されます。WebLogic Administration Console または WebLogic Scripting Tool を使用して SAML パートナをコンフィグレーションできます。次の例では、WLST をオンライン モードで使用して 2 つのリライイング パーティをコンフィグレーションする方法を示します。
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 を設定しています。
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 サービスをコンフィグレーションする主な手順を示します。
RDBMS セキュリティ ストアを使用すると、SAML 2.0 セキュリティ プロバイダで管理するデータを、それらを共有するすべての WebLogic Server インスタンスの間で同期させることができます。
なお、RDBMS セキュリティ ストアを使用するドメインを作成する代わりに、既存のドメインをアップグレードすることはお勧めできません。RDBMS セキュリティ ストアを使用する場合は、ドメインの作成時に RDBMS セキュリティ ストアをコンフィグレーションする必要があります。RDBMS セキュリティ ストアを使用したいドメインが作成済みである場合は、新しいドメインを作成し、そのドメインに既存のセキュリティ レルムを移行してください。
詳細については、「RDBMS セキュリティ ストアの管理」を参照してください。
状況によっては、SAML 認証プロバイダのインスタンスを作成してコンフィグレーションする必要がある場合もあります。
SAML 2.0 全般サービスは、WebLogic Server インスタンスにコンフィグレーションする SAML 2.0 の用途に関わらず (つまり、サービス プロバイダまたは ID プロバイダのどちらとして使用する場合でも) コンフィグレーションする必要があります。WebLogic Server インスタンスの SAML 2.0 全般サービスのコンフィグレーションは、SingleSignOnServicesMBean で制御します。SingleSignOnServicesMBean には、WebLogic Scripting Tool または Administration Console ([環境｜サーバ｜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 には、さまざまな SAML 2.0 サービスのエンドポイント URL を構築するために使用するベース URL を指定します。この URL にはサーバを外部から認識できるホスト名とポートを指定する必要がありますが、これらはローカルでサーバにアクセスする場合に使用するホスト名やポートとは異なる可能性があります。たとえば、SAML 2.0 サービスをクラスタ内でコンフィグレーションする場合のホスト名とポートは、クラスタ内の管理対象サーバにクライアント リクエストを配信するロード バランサまたはプロキシ サーバに相当します。
公開サイトの URL には、/saml2 を付加する必要があります。次に例を示します。
https://www.avitek.com:7001/avitek-domain/aviserver/saml2
エンティティ ID は人間が読み取れる形式の文字列で、サイトをフェデレーション内の他のパートナ サイトと区別するために使用します。SAML 2.0 サービスでは、パートナがアサーションを生成または消費する必要がある場合に、そのアサーションに対応するパートナを特定するプロセスにおいてこのエンティティ ID を使用します。
有効にした場合、認証のリクエストや応答の受信者は、HTTP リクエスト内の URL に一致しなければなりません。
この設定を有効にした場合、クライアントのユーザ名とパスワードも指定する必要があります。これらの資格は、公開するメタデータ ファイルに格納され、これをフェデレーション パートナと共有することになります。
SAML 2.0 全般サービスのコンフィグレーションの手順については、Administration Console オンライン ヘルプの「SAML 2.0 の全般的なサービスのコンフィグレーション」を参照してください。
フェデレーション パートナが必要とするローカル サイト情報 (ローカル サイトの連絡先情報、エンティティ ID、公開サイトの URL、TLS/SSL クライアント認証が必要かどうかなど) は、Administration Console の [SAML 2.0 全般] ページで [メタデータの公開] をクリックすることでメタデータ ファイルとして公開できます。
メタデータ ファイルを公開する際には、ローカル マシンの既存のディレクトリ (ファイルの作成が可能なディレクトリ) を指定します。WebLogic Server には、メタデータ ファイルをフェデレーション パートナに配布する手段は実装されていません。ただし、暗号化された電子メール、セキュア FTP など、電子的なドキュメントを安全に転送できる一般的な方法で配布して構いません。
メタデータ ファイルに関しては、以下の点に留意してください。
メタデータ ファイルには、フェデレーション パートナが必要とするこれらの 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 認証局としてコンフィグレーションします。以下のような属性を指定します。
SAML 2.0 資格マッピング プロバイダをコンフィグレーションしたら、「SAML 2.0 全般サービスのコンフィグレーション」に従って SAML 2.0 全般サービスをコンフィグレーションします。
SAML 2.0 ID プロバイダ サイトとしての WebLogic Server インスタンスのコンフィグレーションは、SingleSignOnServicesMBean によって制御されます。SingleSignOnServicesMBean には、WebLogic Scripting Tool または Administration Console ([環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 2.0 ID プロバイダ] ページ) を使用してアクセスします。
以降の節では、このコンフィグレーション タスクについて簡単に説明します。コンフィグレーションの詳しい手順については、Administration Console オンライン ヘルプの「SAML 2.0 ID プロバイダ サービスのコンフィグレーション」を参照してください。
Administration Console の [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 アサーションを消費するエンティティです。サービス プロバイダ パートナは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッパー｜SAML2CredentialMapperName｜管理] ページでコンフィグレーションします。
このコンソール ページで設定できる属性には、以降の各節で示す Java インタフェースを使用してプログラム的にアクセスできます。
サービス プロバイダ パートナをコンフィグレーションする詳しい手順については、Administration Console オンライン ヘルプの「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 インタフェースを使用して操作できます。
このパートナが署名付きアサーションしか受け付けないかどうかを指定する属性と、認証リクエストに署名する必要があるかどうかを指定する属性は読み取り専用で、パートナのメタデータ ファイルから抽出されます。
サービス プロバイダ パートナのコンフィグレーション ページの [全般] タブでは、必要に応じて以下をコンフィグレーションすることもできます。
これらの属性は、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 用の 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 または Administration Console ([環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 2.0 サービス プロバイダ] ページ) を使用してアクセスします。
以降の節では、SAML 2.0 サービス プロバイダ サイトの属性のコンフィグレーションについて簡単に説明します。これらのコンフィグレーションの詳しい手順については、Administration Console オンライン ヘルプの「SAML 2.0 サービス プロバイダ サービスのコンフィグレーション」を参照してください。
Administration Console の [フェデレーション サービス｜SAML 2.0 サービス プロバイダ] ページで [有効] 属性を true に設定すると、WebLogic Server インスタンスをサービス プロバイダ サイトとして機能させることができます。
ドキュメントに署名が必要かどうか設定するため、必要に応じて以下の属性を有効にします。
必要に応じて、認証リクエスト キャッシュの以下の属性を有効にします。
サービス プロバイダ サービスのエンドポイントで使用できるすべてのバインディング タイプ (POST、リダイレクト、およびアーティファクト) を有効にすることをお勧めします。必要に応じて、優先するバインディング タイプを指定することもできます。
必要に応じて、要求していない認証応答に対象 URL が含まれていなかった場合に、その認証応答を送信するデフォルトの URL を指定します。
SAML 2.0 ID プロバイダ パートナは、サービス プロバイダ サイトによって消費される SAML 2.0 アサーションを生成するエンティティです。ID プロバイダ パートナは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜認証｜SAML2IdentityAsserterName｜管理] ページでコンフィグレーションします。
このコンソール ページで設定できる属性には、以降の各節で示す Java インタフェースを使用してプログラム的にアクセスできます。
サービス プロバイダ パートナをコンフィグレーションする詳しい手順については、Administration Console オンライン ヘルプの「SAML 2.0 Web シングル サインオン ID プロバイダ パートナの作成」を参照してください。
Web シングル サインオン パートナをコンフィグレーションする際に利用できるサイト情報、署名用証明書、サービス エンドポイント情報については、「パートナ サイト、証明書、サービス エンドポイント情報の表示」を参照してください。
以降の節では、ID プロバイダ パートナのコンフィグレーション タスクについて簡単に説明します。
Web シングル サインオン用の ID プロバイダ パートナをコンフィグレーションする前に、暗号化された電子メール、セキュア FTP など、信頼性の高い安全な方法で、パートナの SAML 2.0 メタデータ ファイルを取得する必要があります。パートナの SAML メタデータ ファイルには、パートナ サイトおよびバインディング サポートについて記述されており、パートナの証明書やキーをはじめ、さまざまな情報が含まれています。パートナのメタデータ ファイルは、SAML 2.0 用にコンフィグレーションされているドメイン内の各ノードからアクセスできる場所に格納します。
SAML 2.0 メタデータ ファイルの詳細については、「メタデータ ファイルの公開と配布」を参照してください。
ID プロバイダ パートナを作成し、Web シングル サインオンのための対話を有効にするには、次の手順に従います。
WebLogic Server では、これらの属性を com.bea.security.saml2.providers.registry.Partner Java インタフェースを使用してコンフィグレーションできます。
必要に応じて、この ID プロバイダ パートナの以下の属性をコンフィグレーションします。このパートナ用に生成される認証リクエストの属性と、このパートナから受け取るアサーションの属性があります。
このセキュリティ レルム内にコンフィグレーションされている SAML 2.0 ID アサーション プロバイダのデフォルトのユーザ名マッパー クラスをオーバーライドするカスタム Java クラスです。指定したカスタム クラスは、このパートナから受け取るアサーションに含まれる ID にのみ使用されます。
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Java インタフェースを使用して操作できます。
| 注意 : | この属性を使用するには、レルムに SAML 認証プロバイダをコンフィグレーションする必要があります。 |
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Java インタフェースを使用して操作できます。
この属性を有効にすると、SAML 2.0 ID アサーション プロバイダによってアサーションから属性情報が抽出されます。この情報は、SAML 認証プロバイダ (セキュリティ レルムにコンフィグレーションされていなければならない) との連携によって、対応するユーザが属すセキュリティ レルム内のグループを特定するために使用します。
この属性は、com.bea.security.saml2.providers.registry.IdPPartner Java インタフェースを使用して操作できます。
この属性は、com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java インタフェースを使用して操作できます。
この属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Java インタフェースを使用して操作できます。
未認証のユーザによって呼び出された場合に、そのユーザを認証できる ID プロバイダ パートナにユーザ リクエストをリダイレクトする URI のセットを指定できます。
WebLogic Server では、この属性を com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java インタフェースを使用してコンフィグレーションできます。
サービス プロバイダ パートナのコンフィグレーション ページの [全般] タブでは、必要に応じて以下をコンフィグレーションすることもできます。
これらの属性は、com.bea.security.saml2.providers.registry.WebSSOPartner Java インタフェースを使用して操作できます。
このパートナとのドキュメントの交換をより安全に行うため、ID プロバイダ パートナがローカル サイトのバインディングに接続する際の基本認証で使用するクライアントのユーザ名とパスワードを指定することもできます。この属性は、com.bea.security.saml2.providers.registry.BindingClientPartner Java インタフェースで利用できます。
SAML 2.0 パートナのコンフィグレーションに使用する Administration Console のパートナ コンフィグレーション ページには、パートナに関する以下の追加情報を表示およびコンフィグレーションするためのタブが含まれています。
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 インタフェースを使用して操作できます。
com.bea.security.saml2.providers.registry.WebSSOSPPartner Java インタフェースでも利用できます。com.bea.security.saml2.providers.registry.WebSSOIdPPartner Java インタフェースでも利用できます。com.bea.security.saml2.providers.registry.WebSSOPartner Java インタフェースでも利用できます。
クラスタ環境において SAML ベースの SSO のための Web アプリケーションをデプロイする際は、SAML ベースのシングル サインオンが失敗することのないよう、以下の事項を考慮に入れてください。
デプロイメント記述子ファイルで以下の要素を使用する場合は、下記の推奨事項を検討してください。
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 サーブレット セッションがデフォルトのクッキー名 JSESSIONID で作成されます。アサーションの処理が正常に完了すると、ACS によってユーザのリクエストが対象 Web アプリケーションにリダイレクトされます。ここで、対象 Web アプリケーションにおいて JSESSIONID 以外のクッキー名が使用されていると、サブジェクトの ID が対象 Web アプリケーションに伝播されません。そのため、サーブレット コンテナではユーザが認証されていないかのように処理され、結果として認証リクエストが発行されます。
このような状況を回避するため、SAML 2.0 ベースのシングル サインオン用にコンフィグレーションされたドメインで Web アプリケーションをデプロイする際は、デフォルトのクッキー名を変更しないようにしてください。
ログインに関しては、以下の 2 つの制限に留意してください。これらはクラスタ環境ではまれにしか発生しませんが、発生するとシングル サインオン セッションが失敗する可能性があります。
通常の状況においてはログイン アプリケーションをシングル サインオン サービスと同じノードで実行するため、認証リクエストがドメイン内の別のノードで実行されているログイン アプリケーションにリダイレクトされる可能性は非常に低いといえます。しかし、ログイン アプリケーションをホストするクラスタ ノードとは別のノードによって認証リクエストがリダイレクトされると、このような状況が発生する可能性があります。こうした状況は、基本認証でデフォルトのログイン URI が使用されるように ID プロバイダをコンフィグレーションすることで確実に回避できます。
  
|