| Oracle® Fusion Middleware Oracle WebLogic Server のセキュリティ 11g リリース 1 (10.3.1) B55516-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 Security について』の以下の節を参照してください。
ここでは以下について説明します。
SAML によるシングル サインオンを有効にするには、以下の手順に従って、WebLogic Server をソース サイトまたは送り先サイトとしてコンフィグレーションします。
WebLogic Server インスタンスをソース サイトとしてコンフィグレーションするには、次の手順に従います。
使用するセキュリティ レルムで、SAML 資格マッピング プロバイダ V2 を作成してコンフィグレーションします。
レルム内でソース サイトとして機能するサーバ インスタンスのフェデレーション サービスをコンフィグレーションします。
生成される SAML アサーションのリライイング パーティを作成し、コンフィグレーションします。
ソース サイトへの接続に SSL 証明書を使用するようにリライイング パーティを設定する場合は、SAML 資格マッピング プロバイダの証明書レジストリにそれらの証明書を追加します。
WebLogic Server インスタンスを送り先サイトとしてコンフィグレーションするには、次の手順に従います。
使用するセキュリティ レルムで、SAML ID アサーション プロバイダ V2 を作成してコンフィグレーションします。
レルム内で送り先サイトとして機能するサーバ インスタンスのフェデレーション サービスをコンフィグレーションします。
消費される SAML アサーションのアサーティング パーティを作成し、コンフィグレーションします。
送り先サイトの SSL 証明書を、SAML ID アサーション プロバイダが保持する証明書レジストリに登録することによって、信頼を確立します。
以下の節では、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 ソース サイト] ページ) を使用してアクセスします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SAML ソース サービスのコンフィグレーション」を参照してください。
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 アサーションを生成する方法をコンフィグレーションするか、フェデレーション サービス ソース サイトのコンフィグレーションで設定されたデフォルトを使用してアサーションを生成します。
リライイング パーティは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッパー｜SAMLCredentialMapperName｜管理｜リライイング パーティ] ページでコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「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() メソッドに渡されるプロパティをコンフィグレーションできます。これらの属性は、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 送り先サイトの属性は以下のようにコンフィグレーションします。
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() メソッドに渡されるプロパティをコンフィグレーションできます。これらの属性は、Administration Console の [環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 1.1 送り先サイト] ページでコンフィグレーションできます。
SAML アサーティング パーティは、信頼性のある SAML 認証局 (SAML アサーションの形式でセキュリティ情報をアサートする権限を持つエンティティ) です。アサーティング パーティは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜資格マッパー｜SAMLCredentialMapperName｜管理｜アサーティング パーティ] ページでコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SAML 1.1 アサーティング パーティの作成」および「SAML 1.1 アサーティング パーティのコンフィグレーション」を参照してください。
WebLogic Scripting Tool を使用してアサーティング パーティをコンフィグレーションすることもできます。「WLST を使用したリライイング パーティとアサーティング パーティのコンフィグレーション」を参照してください。
SAML アサーティング パーティをコンフィグレーションするときに、SAML SSO 用としてアーティファクト プロファイルまたは POST プロファイルのサポートを指定できます。代わりに、Web サービス セキュリティ用として WSS/Holder-of-Key プロファイルまたは WSS/Sender-Vouches プロファイルをサポートするアサーティング パーティをコンフィグレーションすることもできます。
SAML パートナ (リライイング パーティとアサーティング パーティ) はレジストリに保持されます。WebLogic Administration Console または 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 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 または 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。
公開サイトの 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SAML 2.0 の全般的なサービスのコンフィグレーション」を参照してください。
フェデレーション パートナが必要とするローカル サイト情報 (ローカル サイトの連絡先情報、エンティティ ID、公開サイトの URL、TLS/SSL クライアント認証が必要かどうかなど) は、Administration Console の [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 または Administration Console ([環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 2.0 ID プロバイダ] ページ) を使用してアクセスします。
以降の節では、このコンフィグレーション タスクについて簡単に説明します。コンフィグレーションの詳しい手順については、Oracle Fusion Middleware Oracle WebLogic Server の 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 インタフェースを使用してプログラム的にアクセスできます。
サービス プロバイダ パートナをコンフィグレーションする詳しい手順については、Oracle Fusion Middleware Oracle WebLogic Server の 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 シングル サインオン用のサービス プロバイダ パートナを作成してコンフィグレーションするには、次の手順に従います。
[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 または Administration Console ([環境｜サーバ｜ServerName｜コンフィグレーション｜フェデレーション サービス｜SAML 2.0 サービス プロバイダ] ページ) を使用してアクセスします。
以降の節では、SAML 2.0 サービス プロバイダ サイトの属性のコンフィグレーションについて簡単に説明します。これらのコンフィグレーションの詳しい手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「SAML 2.0 サービス プロバイダ サービスのコンフィグレーション」を参照してください。
Administration Console の [フェデレーション サービス｜SAML 2.0 サービス プロバイダ] ページで [有効] 属性を true に設定すると、WebLogic Server インスタンスをサービス プロバイダ サイトとして機能させることができます。
ドキュメントに署名が必要かどうか設定するため、必要に応じて以下の属性を有効にします。
ID プロバイダ パートナに送る認証リクエストに署名が必要かどうか
ID プロバイダ パートナから受け取るアサーションに署名が必要かどうか
必要に応じて、認証リクエスト キャッシュの以下の属性を有効にします。
最大キャッシュ サイズ。
認証リクエストのタイムアウト値。この値を指定することで、格納された認証リクエストが期限切れになるまでの期間を設定できます。
サービス プロバイダ サービスのエンドポイントで使用できるすべてのバインディング タイプ (POST およびアーティファクト) を有効にすることをお勧めします。必要に応じて、優先するバインディング タイプを指定することもできます。
SAML 2.0 ID プロバイダ パートナは、サービス プロバイダ サイトによって消費される SAML 2.0 アサーションを生成するエンティティです。ID プロバイダ パートナは、Administration Console の [セキュリティ レルム｜RealmName｜プロバイダ｜認証｜SAML2IdentityAsserterName｜管理] ページでコンフィグレーションします。
このコンソール ページで設定できる属性には、以降の各節で示す Java インタフェースを使用してプログラム的にアクセスできます。
ID プロバイダ パートナをコンフィグレーションする詳しい手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「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 パートナのコンフィグレーションに使用する 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 インタフェースを使用して操作できます。
サービス プロバイダ パートナをコンフィグレーションするときには、[アサーション コンシューマ サービス エンドポイント] タブにサービス プロバイダ パートナの 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 サーブレット セッションがデフォルトのクッキー名 JSESSIONID で作成されます。アサーションの処理が正常に完了すると、ACS によってユーザのリクエストが対象 Web アプリケーションにリダイレクトされます。ここで、対象 Web アプリケーションにおいて JSESSIONID 以外のクッキー名が使用されていると、サブジェクトの ID が対象 Web アプリケーションに伝播されません。そのため、サーブレット コンテナではユーザが認証されていないかのように処理され、結果として認証リクエストが発行されます。
このような状況を回避するため、SAML 2.0 ベースのシングル サインオン用にコンフィグレーションされたドメインで Web アプリケーションをデプロイする際は、デフォルトのクッキー名を変更しないようにしてください。
ログインに関しては、以下の 2 つの制限に留意してください。これらはクラスタ環境ではまれにしか発生しませんが、発生するとシングル サインオン セッションが失敗する可能性があります。
ID プロバイダのシングル サインオン サービスは、認証リクエストを受け取ると、ユーザを認証するためにそのリクエストをログイン アプリケーションにリダイレクトします。ログイン アプリケーションは、シングル サインオン サービスと同じクラスタ ノードで実行する必要があります。そうしないと、認証が成功しても、ID プロバイダで SAML 2.0 アサーションを生成することができません。
通常の状況においてはログイン アプリケーションをシングル サインオン サービスと同じノードで実行するため、認証リクエストがドメイン内の別のノードで実行されているログイン アプリケーションにリダイレクトされる可能性は非常に低いといえます。しかし、ログイン アプリケーションをホストするクラスタ ノードとは別のノードによって認証リクエストがリダイレクトされると、このような状況が発生する可能性があります。こうした状況は、基本認証でデフォルトのログイン URI が使用されるように ID プロバイダをコンフィグレーションすることで確実に回避できます。
SAML 2.0 アサーション コンシューマ サービス (ACS) は、アサーションを正常に消費すると、アサーションによって表現されたサブジェクトをログインさせます。次に ACS は、ユーザ リクエストを対象 Web アプリケーションにリダイレクトします。通常、対象アプリケーションは ACS と同じノードで実行されています。しかしまれなケースとして、ユーザ リクエストのリダイレクト先となる対象アプリケーションが、ログインが発生した ACS をホストするクラスタ ノードとは別のノードで実行されていることがあります。このような状況が発生すると、アサーションによって表現された ID が対象アプリケーションのノードに伝播されません。その結果、シングル サインオン プロセスが再試行されるか、アクセスが拒否されます。
通常は対象アプリケーションは ACS と同じノードで実行されるため、このような状況は非常にまれにしか発生しません。
