WebLogic Server のセキュリティ
|
 |
 |
|
WebLogic Server には、数多くの認証セキュリティ プロバイダが組み込まれています。基本的に、ほとんどの認証プロバイダは同じように動作します。ユーザ名とパスワードの資格ペアが指定されると、認証プロバイダはそのデータ ストアから対応するユーザを見つけ出そうとします。これらの認証プロバイダの主な違いは、使用するデータ ストアの種類にあります (使用可能な LDAP サーバの 1 つ、SQL データベース、またはその他のデータ ストア)。ユーザ名とパスワードをベースとしたセキュリティ プロバイダの他にも、WebLogic Server には ID アサーション認証プロバイダが組み込まれています。ID アサーション認証プロバイダは、ユーザ名とパスワードのペアではなく証明書またはセキュリティ トークンを資格として使用します。
以下の節では、WebLogic Server で提供されている認証セキュリティ プロバイダをコンフィグレーションする方法について説明します。
認証とは、ユーザおよびシステム プロセスの ID を証明または検証するプロセスです。認証にはまた、必要に応じて、身元情報を記憶したり、転送したり、さまざまなシステム コンポーネントの利用に供する働きもあります。
WebLogic Server のセキュリティ アーキテクチャでサポートされているのは、証明書に基づく認証 (WebLogic Server を直接用いる)、HTTP 証明書に基づく認証 (外部の Web サーバを介して行う)、境界に基づく認証 (Web サーバ、ファイアウォール、VPN)、および複数のセキュリティ トークン タイプ/プロトコルに基づく認証です。
認証は、認証プロバイダによって実行されます。WebLogic Server には、以下のタイプの認証プロバイダが用意されています。
各セキュリティ レルムには、少なくとも 1 つの認証プロバイダがコンフィグレーションされている必要があります。WebLogic Security フレームワークは、さまざまな要素から成る認証向けに、複数の認証プロバイダ (したがって、複数の LoginModule) をサポートするように設計されています。そのため、複数の認証プロバイダを使用できます。また、1 つのセキュリティ レルムで複数のタイプの認証プロバイダを使用できます。たとえば、網膜スキャンに基づく認証とユーザ名/パスワードに基づく認証の両方を使用してシステムにアクセスする場合、2 つの認証プロバイダをコンフィグレーションします。
複数の認証プロバイダをコンフィグレーションする方法は、認証プロセスの全体的な結果に影響します。認証プロバイダ間にログインの依存関係を設定し、プロバイダ間のシングル サインオンを可能にするには、各認証プロバイダの JAAS 制御フラグをコンフィグレーションします。「JAAS 制御フラグ オプションの設定」を参照してください。
認証プロバイダは、セキュリティ レルムでコンフィグレーションされた順序で呼び出されます。したがって、認証プロバイダをコンフィグレーションする際は注意してください。WebLogic Administration Console を使用すると、コンフィグレーション済みの認証プロバイダの順序を再設定して、それらが呼び出される順序を変更できます。「認証プロバイダの順序の変更」を参照してください。
複数の認証プロバイダをコンフィグレーションする場合、各認証プロバイダの JAAS 制御フラグを使用して、ログイン シーケンスにおける認証プロバイダの使用方法を制御します。JAAS 制御フラグは、WebLogic Administration Console で設定できます。Administration Console オンライン ヘルプの「JAAS 制御フラグの設定」を参照してください。また、WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用して、認証プロバイダの JAAS 制御フラグを設定することもできます。
JAAS の [制御フラグ] の値は次のように定義されます。
既存のセキュリティ レルムにさらに認証プロバイダを追加する場合、[制御フラグ] はデフォルトで [OPTIONAL] に設定されます。必要に応じて、認証プロバイダが認証シーケンス内で適切に機能するように、[制御フラグ] の設定を変更してください。
WebLogic Server が複数の認証プロバイダを呼び出す順序は、認証プロセスの全体的な結果に影響します。[認証プロバイダ] テーブルには、呼び出された順序で認証プロバイダが表示されます。デフォルトでは、認証プロバイダはコンフィグレーションされた順序で呼び出されます。Administration Console を使用すると、認証プロバイダの順序を変更できます。認証プロバイダが WebLogic Server によって呼び出される順序と Administration Console に表示される順序を変更するには、Administration Console の [セキュリティ レルム : プロバイダ : 認証] ページの [並べ替え] ボタンを使用します。
詳細については、Administration Console オンライン ヘルプの「認証プロバイダの順番の変更」を参照してください。
WebLogic 認証プロバイダは、WebLogic Server の組み込み LDAP サーバを使用してユーザおよびグループ メンバシップ情報を格納します。このプロバイダを使用すると、ユーザとグループ メンバシップを編集、表示、および管理できます。デフォルトによって、WebLogic 認証プロバイダのコンフィグレーション オプションの大部分が定義されています。WebLogic 認証プロバイダをコンフィグレーションする必要があるのは、新しいセキュリティ レルムを作成するときだけです。ただし、以下の点に注意してください。
DefaultAuthenticator という名前でコンフィグレーションされています。
WebLogic Server には、以下の LDAP 認証プロバイダが用意されています。
これらの LDAP 認証プロバイダは、それぞれ基本的に同じように動作して、ユーザおよびグループ情報を外部の LDAP サーバに格納します。主な相違点は、それぞれが対応する LDAP サーバ用の一般的なディレクトリ スキーマに合わせてコンフィグレーションされていることです。
WebLogic Server は、特定の LDAP サーバをサポートおよび証明しません。LDAP v2 または v3 準拠のすべての LDAP サーバは WebLogic Server と正常に連係します。以下の LDAP ディレクトリ サーバについてはテスト済みです。
LDAP 認証プロバイダを使用して他の LDAP サーバにアクセスすることもできます。ただし、LDAP 認証プロバイダ (LDAPAuthenticator) を使用するか、または定義済みの LDAP プロバイダを選択してカスタマイズする必要があります。「他の LDAP サーバへのアクセス」を参照してください。
LDAP 認証プロバイダは、いくつかの手順でコンフィグレーションします。手順は次のとおりです。
LDAP 認証プロバイダがセキュリティ レルムにコンフィグレーションされている唯一の認証プロバイダの場合、Admin ロールを持たなければ、WebLogic Server を起動して LDAP ディレクトリ内のユーザまたはグループを使用することができません。LDAP ディレクトリで、次のいずれかを行います。
Admin ロールに Administrators グループが含まれています。LDAP ディレクトリに Administrators グループを作成します。WebLogic Server を起動する LDAP ユーザがこのグループに含まれていることを確認します。 Active Directory LDAP ディレクトリには、Administrators というデフォルト グループが存在します。WebLogic Server を起動するユーザを Administrators グループに追加し、[グループ ベース DN] を定義して Administrators グループが見つかるようにします。
Administrators グループを作成しない場合 (LDAP ディレクトリが別の目的で Administrators グループを使用する場合など)、LDAP ディレクトリに新しいグループを作成 (または既存のグループを使用) して、WebLogic Server を起動するユーザをそのグループに追加します。次に、WebLogic Administration Console で、そのグループに Admin ロールを割り当てます。このリリースの WebLogic Server の LDAP 認証プロバイダは、SunONE (iPlanet)、Active Directory、Open LDAP、および Novell NDS の LDAP サーバと容易に連携動作します。また、LDAP 認証プロバイダを使用すると、他のタイプの LDAP サーバにアクセスできます。LDAP 認証プロバイダ (LDAPAuthenticator) または新しい LDAP サーバに対応した既存の LDAP プロバイダを選択し、その LDAP サーバのディレクトリ スキーマと他の属性に合わせて既存のコンフィグレーションをカスタマイズします。
複数の LDAP サーバと連携する LDAP プロバイダをコンフィグレーションし、1 つの LDAP サーバが利用できない場合のフェイルオーバを有効にできます。[ホスト] 属性 (Administration Console のこの LDAP 認証プロバイダ用の [コンフィグレーション : プロバイダ固有] ページ) を使用して、別の LDAP サーバの名前を指定します。各ホスト名は、末尾のカンマやポート番号が入ってもかまいません。また、LDAP 認証プロバイダ用の [パラレル接続遅延] および [接続タイムアウト] 属性を設定します。
以下の例は、LDAP 認証プロバイダの LDAP フェイルオーバがコンフィグレーションされている場合のシナリオを示しています。
次のシナリオでは、LDAP 認証プロバイダの [ホスト] 属性に、directory.knowledge.com:1050、people.catalog.com、199.254.1.2 という 3 つのサーバがコンフィグレーションされています。これらの LDAP サーバのステータスは次のとおりです。
WebLogic Server は directory.knowledge.com に接続しようとします。10 秒後、接続の試行はタイムアウトになり、WebLogic Server は次に指定されているホスト (people.catalog.com) に接続しようとします。WebLogic Server は、この接続の LDAP サーバとして people.catalog.com を使用します。
次のシナリオでは、WebLogic Server は directory.knowledge.com に接続しようとします。1 秒後 ([パラレル接続遅延] 属性で指定)、接続の試行はタイムアウトになり、WebLogic Server は指定された次のホスト (people.catalog.com) と directory.knowledge.com に同時に接続しようとします。people.catalog.com への接続が成功した場合、WebLogic Server はこの接続の LDAP サーバとして people.catalog.com を使用します。WebLogic Server は、people.catalog.com との接続が成功した後に directory.knowledge.com への接続を取り消します。
WebLogic 認証プロバイダと LDAP 認証プロバイダのパフォーマンスは、以下の方法で向上させることができます。
tokenGroups オプションを使用してグループ メンバシップのルックアップを実行するようににコンフィグレーションする。tokenGroups オプションは、完全にフラット化されたユーザのグループ メンバシップをシステム ID (SID) 値の配列として保持しています。この SID 値は Active Directory において特別な索引付けがされており、これによりルックアップの応答が高速になります。以下の節では、これらの最適化を実装する方法について説明します。
WebLogic 認証プロバイダと LDAP 認証プロバイダ用のグループ メンバシップ キャッシュを最適化するには、以下の属性を設定します (Administration Console の LDAP 認証プロバイダの [コンフィグレーション] の [プロバイダ固有] および [パフォーマンス] ページ)。
WebLogic 認証プロバイダまたは LDAP 認証プロバイダのパフォーマンスを向上させるために、必要に応じて、WebLogic プリンシパル検証プロバイダによって使用されるキャッシュの設定を大きくすることができます。WebLogic プリンシパル検証プロバイダによって使用されるプリンシパル検証プロバイダ キャッシュは、署名された WLSAbstractPrincipal をキャッシュします。プリンシパル検証プロバイダ キャッシュを最適化するには、使用しているセキュリティ レルム用のこれらの属性を設定します (Administration Console の該当セキュリティ レルムの [コンフィグレーション : パフォーマンス] ページ)。
Active Directory 認証プロバイダが tokenGroups オプションを使用するようにコンフィグレーションするには、以下の属性を設定します (Administration Console の Active Directory 認証プロバイダの [コンフィグレーション : プロバイダ固有] ページ)。
tokenGroups ルックアップ アルゴリズムを使用するかどうかを指定します。デフォルトでは、このオプションは有効ではありません。注意 : tokenGroups オプションへのアクセスが必要になります (つまり、LDAP ディレクトリにアクセスするユーザには tokenGroups オプションの読み込み特権が必要になり、tokenGroups オプションはユーザ オブジェクトのスキーマになければなりません)。
WebLogic Server では、RDBMS 認証プロバイダはユーザ名/パスワード ベースの認証プロバイダであり、ユーザ、パスワード、およびグループ情報のデータ ストアとして (LDAP ディレクトリではなく) リレーショナル データベースを使用します。WebLogic Server には、以下の RDBMS 認証プロバイダが用意されています。
RDBMS 認証プロバイダのセキュリティ レルムへの追加については、Administration Console オンライン ヘルプの「認証および ID アサーション プロバイダのコンフィグレーション」を参照してください。RDBMS 認証プロバイダのインスタンスを作成したら、Administration Console の RDBMS 認証プロバイダの [コンフィグレーション : プロバイダ固有] ページでそのインスタンスをコンフィグレーションします。
上記の 3 種類の RDBMS 認証プロバイダには、以下のコンフィグレーション オプションがあります。
[データ ソース名] では、データベースに接続するための WebLogic Server データ ソースを指定します。
[グループ メンバシップ検索] および [グループ メンバシップ検索の最大レベル] 属性では、再帰的なグループ メンバシップ検索を制限付きか無制限のどちらにするか、および制限付きにした場合、検索するグループ メンバシップ レベルの数を指定します。たとえば、[グループ メンバシップ検索] を limited に、[グループ メンバシップ検索の最大レベル] を 0 に設定した場合、RDBMS 認証プロバイダはユーザが直接メンバーであるグループだけを検索します。グループ メンバシップ検索の最大レベルを指定すると、認証中に実行される DBMS クエリの数が減少する場合があるので、特定のシナリオで認証のパフォーマンスが大幅に向上します。しかし、グループ メンバシップ検索レベルを制限するのは、必要なグループ メンバシップがその検索レベル制限の範囲内にあることが確認できている場合のみにしてください。
グループ階層ルックアップの結果をキャッシュすることによって、RDBMS 認証プロバイダのパフォーマンスを向上させることができます。このキャッシュを使用すると、RDBMS 認証プロバイダがデータベースにアクセスする頻度を下げることができます。このキャッシュの使い方、サイズ、および期間をコンフィグレーションするには、Administration Console にある認証プロバイダの [パフォーマンス] ページを使用します。詳細については、Administration Console オンライン ヘルプの「SQL 認証プロバイダ : パフォーマンス」を参照してください。
SQL 認証プロバイダのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「SQL 認証プロバイダ : パフォーマンス」を参照してください。「一般的な RDBMS 認証プロバイダ属性」で説明する属性の他にも、SQL 認証プロバイダには以下のコンフィグレーション可能な属性があります。
以下の属性によって、RDBMS 認証プロバイダとその基盤データベースがパスワードを処理する方法を指定します。
残りの属性では、認証プロバイダがデータベース内のユーザ名、パスワード、およびグループ情報にアクセスして編集するために使用する SQL 文を指定します。SQL 文属性のデフォルト値は、データベース スキーマに次のテーブルが含まれていることを前提としたものです。
SQL 文によって参照されるテーブルは、データベースに存在しなければなりません。認証プロバイダによってテーブルは作成されません。これらの属性は、使用するデータベースのスキーマに合わせて変更できます。しかし、データベース スキーマがこのデフォルト スキーマと根本的に異なる場合、代わりにカスタム DBMS 認証プロバイダを使用できます。
読み込み専用 SQL 認証プロバイダのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「読み込み専用 SQL 認証プロバイダ : プロバイダ固有」を参照してください。「一般的な RDBMS 認証プロバイダ属性」で説明する属性の他にも、読み込み専用 SQL 認証プロバイダのコンフィグレーション可能な属性には、データベース内のユーザ名、パスワード、およびグループ情報のリストを取得する SQL 文を指定する属性があります。これらの属性は、使用するデータベースのスキーマに合わせて変更できます。
カスタム DBMS 認証プロバイダは、他の RDBMS 認証プロバイダと同様、ユーザ、パスワード、およびグループ情報のデータ ストアとしてリレーショナル データベースを使用します。このプロバイダは、使用するデータベース スキーマが SQL 認証プロバイダで必要な SQL スキーマと一致しない場合に使用します。「一般的な RDBMS 認証プロバイダ属性」で説明する属性の他にも、カスタム DBMS 認証プロバイダには以下のコンフィグレーション可能な属性があります。
カスタム DBMS 認証プロバイダでは、weblogic.security.providers.authentication.CustomDBMSAuthenticatorPlugin インタフェースを実装するプラグイン クラスを作成する必要があります。このクラスは CLASSPATH に存在しなくてはならず、カスタム DBMS 認証プロバイダの [プラグイン クラス名] 属性に指定しなければなりません。必要な場合、[プラグインのプロパティ] 属性を使用して、プラグイン クラスによって定義されるプロパティ値を指定します。
Windows NT 認証プロバイダは、Windows NT ドメイン用に定義されたユーザ アカウント情報を使用してユーザとグループを認証し、Windows NT のユーザとグループを WebLogic Administration Console に表示します。
Windows NT 認証プロバイダを使用するには、WebLogic Administration Console で Windows NT 認証プロバイダを作成します。ほとんどの場合、この認証プロバイダのコンフィグレーションでは何も行う必要はありません。ただし、Windows NT ドメインのコンフィグレーションによっては、Windows NT 認証プロバイダと Windows NT ドメインの対話方法を制御する属性を設定します。
Windows NT ドメインのユーザ名には、いくつかの形式があります。サインオンするときに使用するユーザ名の形式に合わせて、Windows NT 認証プロバイダをコンフィグレーションする必要があります。単純なユーザ名には、ドメイン名は入りません (smith など)。複合ユーザ名は、ユーザ名とドメイン名の組み合わせです (domain\smith や smith@domain など)。
ローカル マシンが Microsoft ドメインの一部でない場合、ドメイン コントローラ リストの変更は必要ありません。スタンドアロン マシンでは、認証を受けるユーザとグループはそのマシンのみで定義されます。
ローカル マシンが Microsoft ドメインの一部であり、ローカルドメインのドメイン コントローラである場合、ドメイン コントローラ リストを変更する必要はありません。この場合、ローカル マシンとローカル ドメインで定義されているユーザは同じなので、デフォルトのドメイン コントローラ設定を使用できます。
ローカル マシンが Microsoft ドメインの一部であるが、ローカル ドメインのドメイン コントローラではない場合、単純ユーザ名はローカル マシンまたはドメインのいずれかで発見されます。この場合は、以下のことを考慮します。
いずれかの質問の答えが「はい」の場合、DomainControllers 属性を DOMAIN に設定します。
信頼性のあるドメインが複数ある場合、DomainControllers 属性を DOMAIN に設定し、ドメイン コントローラ リストを指定する必要が生じる場合があります。これは、以下の場合に行います。
smith@domain や domain\Smith ではなく smith など) でサインオンする場合。いずれかの質問の回答が「はい」の場合、DomainControllers 属性を LIST に設定し、使用する信頼性のあるドメインのドメイン コントローラ名を DomainControllerList に指定します。また、ローカル マシンとローカル ドメイン コントローラの明示的な名前を使用するかどうか、またはそれらのリストでプレースホルダを使用するかどうかも検討します。使用できるプレースホルダは以下のとおりです。
LogonType 属性の適切な値は、認証できるユーザの Windows NT ログオン権限によって異なります。
interactive を使用する。network に変更する。Windows NT ドメインのユーザには、上記の権限のいずれかを割り当てる必要があります。このようにしない場合、Windows NT 認証プロバイダはユーザを認証できません。
UPN 型のユーザ名の形式は、user@domain です。@ 記号を含むが UPN 名ではないユーザ名を Windows NT 認証プロバイダがどのように扱うかは、mapUPNNames 属性を使用してコンフィグレーションします。
UPN ユーザ名以外に、@ 記号を含むユーザ名が Windows NT ドメインとローカル マシンに存在しない場合、mapUPNNames 属性のデフォルト値である FIRST を使用できます。しかし、この値を ALWAYS に変更することによって、認証の失敗の検出時間を短縮できる場合があります。これは特に、長いドメイン コントローラ リストを指定した場合に効果的です。
Windows NT ドメインで、@ 記号を含む UPN 以外のユーザ名が存在する場合、次のように設定します。
mapUPNNames 属性を FIRST に設定する。mapUPNNames 属性を LAST に設定する。mapUPNNames 属性を NEVER に設定する。
境界認証を使用する場合、ID アサーション プロバイダを使用する必要があります。境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します (これは単純認証とは対照的です。単純認証では、WebLogic Server がユーザ名とパスワードを通じて信頼を確立します)。ID アサーション プロバイダは、トークンを検証し、そのトークンの妥当性と信頼性を確立するために必要なアクションを実行します。各 ID アサーション プロバイダは、1 つまたは複数のトークン フォーマットをサポートします。
WebLogic Server には、以下の新しい ID アサーション プロバイダが組み込まれています。
セキュリティ レルム内では複数の ID アサーション プロバイダをコンフィグレーションできますが、これらは必須ではありません。ID アサーション プロバイダでは複数のトークン タイプをサポートできますが、一度にアクティブになるのは ID アサーション プロバイダごとに 1 つのトークン タイプだけです。アクティブなトークンの種類は、[一般] ページの [アクティブな種類] フィールドで定義します。WebLogic ID アサーション プロバイダは、X509 証明書と CORBA Common Secure Interoperability バージョン 2 (CSI v2) を使用する ID アサーションをサポートしています。CSI v2 ID アサーションを使用する場合、[信頼性のあるクライアントのプリンシパル] フィールドでクライアント プリンシパルのリストを定義します。
セキュリティ レルムに複数の ID アサーション プロバイダをコンフィグレーションした場合、すべての ID アサーション プロバイダで同じトークン タイプをサポートできます。ただし、トークンは一度に 1 つのプロバイダのみに対してアクティブにできます。
セキュリティ レルムで WebLogic ID アサーション プロバイダを使用する場合、ユーザ名マッパーを使用して、ID アサーション プロバイダで認証されるトークンをセキュリティ レルム内のユーザにマップすることもできます。ユーザ名マッパーのコンフィグレーションの詳細については、「WebLogic 資格マッピング プロバイダのコンフィグレーション」を参照してください。
Web アプリケーションの認証タイプが CLIENT-CERT に設定されている場合、WebLogic Server の Web アプリケーション コンテナは、リクエスト ヘッダおよびクッキーからの値に対して ID アサーションを実行します。ヘッダ名またはクッキー名が、コンフィグレーションされている ID アサーション プロバイダのアクティブなトークン タイプに一致していれば、値はプロバイダに渡されます。
[詳細] ページの [Base64 でのデコーディングが必要] では、リクエスト ヘッダ値またはクッキー値を ID アサーション プロバイダへ送信する前に、その値を Base 64 でデコードするかどうかを指定します。この設定はデフォルトでは下位互換性のために有効になっていますが、ほとんどの ID アサーション プロバイダでは、このオプションは無効化されます。
詳細については、Administration Console オンライン ヘルプの「認証および ID アサーション プロバイダのコンフィグレーション」を参照してください。また、以下の節を参照してください。
LDAP X509 ID アサーション プロバイダは、X509 証明書を受け取り、その証明書に関連付けられたユーザの LDAP オブジェクトをルックアップして、LDAP オブジェクトの証明書が提示された証明書と一致することを確認し、LDAP オブジェクトからユーザの名前を取得します。
LDAP X509 ID アサーション プロバイダは、以下のように機能します。
通常、LDAP X509 ID アサーション プロバイダを使用する場合は、LDAP サーバを使用する LDAP 認証プロバイダもコンフィグレーションする必要があります。認証プロバイダは、ユーザが存在していることを確認し、そのユーザが属するグループを特定します。両方のプロバイダが、同じ LDAP サーバと通信できるように適切にコンフィグレーションされていることを確認してください。
LDAP X509 ID アサーション プロバイダを使用するには、以下の手順に従います。
証明書のサブジェクト DN と、LDAP サーバ内におけるそのユーザのオブジェクトの場所の間には、相関性が必要です。ユーザの LDAP オブジェクトには、サブジェクトで使用される証明書およびユーザ名のコンフィグレーション情報も含まれている必要があります。
ネゴシエート ID アサーション プロバイダを使用すると、Microsoft 社製のクライアントでシングル サインオン (single sign-on : SSO) を利用できます。この ID アサーション プロバイダでは、SPNEGO (Simple and Protected Negotiate) のトークンをデコードして Kerberos のトークンを取得し、その Kerberos トークンを検証した後で WebLogic ユーザにマップします。ネゴシエート ID アサーション プロバイダは、Kerberos を介した GSS のセキュリティ コンテキストの受け入れに Java GSS (Generic Security Service) API (Application Programming Interface) を利用します。
ネゴシエート ID アサーション プロバイダは、WebLogic Security フレームワークに定義されているようにセキュリティ サービス プロバイダ インタフェース (Security Service Provider Interface : SSPI) の実装であり、クライアントをその SPNEGO トークンに基づいて認証するのに必要なロジックを提供します。
ネゴシエート ID アサーション プロバイダのセキュリティ レルムへの追加については、Administration Console オンライン ヘルプの「認証および ID アサーション プロバイダのコンフィグレーション」を参照してください。ネゴシエート ID アサーション プロバイダを Microsoft クライアント SSO と一緒に使用する方法については、「Microsoft のクライアントに対するシングル サインオンのコンフィグレーション」を参照してください。
SAML ID アサーション プロバイダは、SAML セキュリティ アサーションのコンシューマとして機能します。これにより、WebLogic Server はシングル サインオン用に SAML を使用するための送り先サイトとして機能できます。SAML ID アサーション プロバイダは、署名をチェックし、保持する証明書レジストリ内の証明書の信頼性を検証することによって、SAML 1.1 アサーションを検証します。信頼されていれば、アサーションに含まれる AuthenticationStatement に基づいて ID がアサートされます。SAML ID アサーション プロバイダは、SAML アサーション コンシューマ サービスとしてコンフィグレーションできます。また、SAML ID アサーション プロバイダは、アサーションが以前に使用されていないことを確認します。
ここでは、SAML ID アサーション プロバイダの以下の側面のコンフィグレーションについて説明します。
SAML ID アサーション プロバイダを SAML シングル サインオン コンフィグレーションで使用する方法については、「Web ブラウザと HTTP クライアントによるシングル サインオンのコンフィグレーション」を参照してください。WebLogic Server での SAML のサポートの概要については、『WebLogic Security について』の「Security Assertion Markup Language (SAML)」を参照してください。
SAML ID アサーション プロバイダをコンフィグレーションして、POST プロファイル、アーティファクト プロファイル、またはその両方をサポートできます。
POST プロファイルのサポートをコンフィグレーションするには、次の手順に従います。
アーティファクト プロファイルのサポートをコンフィグレーションするには、[アーティファクトを有効化] 属性を設定します。
アサーション コンシューマ URI 属性では、SAML ID アサーション プロバイダが、受信するアサーションをリスンする URI を指定します。これらの URI は、アサーション コンシューマ サービス (ACS) を提供します。また、SAML 送り先サイトをコンフィグレーションすると、認証されないユーザをリモート SAML ソース サイトに転送して、アクセスしようとした特定の URI に基づいて認証を行うようにできます。これらの SAML ソース サイトは、SAML ID アサーション プロバイダのソース サイト転送属性でコンフィグレーションします。SAML ソース サイト転送は、キー=値というフォーマットの Java 仕様プロパティでコンフィグレーションします。コード リスト 5-1 に例を示します。
コード リスト 5-1 ソース サイト転送のコンフィグレーションの例
Redirects=mypost,myart
mypost.TargetURI=/targets/PostTarget.jsp
mypost.RedirectURL=https://www.source_site.com:7002/samlits_ba/post
myart.TargetURI=/targets/ArtTarget.jsp
myart.RedirectURL=https://www.source_site.com:7002/samlits_ba/artifact
SAML ID アサーション プロバイダをコンフィグレーションして、アサーションの使用を 1 度だけに制限できます。そのためには、Administration Console で次の手順に従います。
SAML ID アサーション プロバイダは、信頼性のある証明書のレジストリを保持します。証明書を受け取ると、このレジストリ内の証明書と照らし合わせて検証します。このレジストリの証明書は、以下の目的で使用されます。
アサーションまたは POST プロファイル応答オブジェクトに署名するか、別サイトの ARS に SSL で接続する場合、サーバの SSL 証明書を使用して署名とクライアント認証を行います。
Administration Console を使用して、信頼性のある証明書を証明書レジストリに追加できます。
管理ページで、レジストリの証明書を追加、削除、および表示します。
SAML ID アサーション プロバイダの [アサーションのコンフィグレーション] 属性で、アサーションがどのように消費されるかをコンフィグレーションできます。アサーションのコンフィグレーションには、キー=値というフォーマットの Java 仕様プロパティを使用します。キーの形式は assertionName.propertyName です。
コード リスト 5-2 は、消費されるアサーションのコンフィグレーションの例です。この例には、mypost という POST プロファイル アサーションと myart というアーティファクト プロファイル アサーションが含まれています。
コード リスト 5-2 消費されるアサーションのコンフィグレーション
Assertions=mypost,myart
mypost.AssertionType=bearer
mypost.Target=http://www.destination_site.com:7001/targets/PostTarget.jsp
mypost.IssuerURI=http://www.source_site.com/issuer
mypost.ProcessGroups=true
myart.AssertionType=artifact
myart.Target=http://www.destination_site.com:7001/targets/Art*
myart.IssuerURI=http://www.source_site.com/issuer
myart.SourceIdHex=63A678A290A3DBADBA9F1E51135E225049FA5BB0
myart.RetrievalURL=https://www.source_site.com:7003/samlars/ars
HTTP リクエストが送信されたときに、ID アサーションに使用できる一致が複数存在する場合があります。一方、ID アサーション プロバイダが一度に消費できるのはアクティブなトークン タイプのうちの 1 つだけです。つまり、一度の呼び出しで一連のトークンを消費できる方法は提供されていません。したがって WebLogic Server に含まれるサーブレットでは、ID アサーションを実行するために複数のトークンから 1 つを選択する必要があります。選択は次の順序で行われます。
WL-Proxy-Client-<TOKEN> という形式の名前を持つヘッダ。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つ。たとえば、デフォルト セキュリティ レルムの ID アサーション プロバイダがアクティブなトークンとして FOO および BAR というトークンを持つようにコンフィグレーションされている場合 (次の例では、HTTP リクエストには ID アサーションに関連するものはアクティブなトークン タイプ以外、何も含まれていないものとする)、ID アサーションは次のように実行されます。
FOO ヘッダを持つリクエストが双方向 SSL 接続を使用して受信される場合、X.509 が ID アサーションに使用されます。FOO ヘッダを持ち、WL-Proxy-Client-BAR ヘッダを持つリクエストが受信される場合、BAR トークンが ID アサーションに使用されます。FOO ヘッダを持ち、BAR クッキーを持つリクエストが受信される場合、FOO トークンが ID アサーションに使用されます。同じレベルの複数のトークン間の順序付けは定義されていません。そのため、次のようになります。
FOO ヘッダを持ち、BAR ヘッダを持つリクエストが受信される場合、FOO トークンまたは BAR トークンのいずれかが ID アサーションに使用されますが、どちらが使用されるかは指定されていません。FOO クッキーを持ち、BAR クッキーを持つリクエストが受信される場合、FOO トークンまたは BAR トークンのいずれかが ID アサーションに使用されますが、どちらが使用されるかは指定されていません。(X.509 証明書または他のタイプのトークンで) ID アサーション プロバイダを使用する場合、サブジェクト (ID やそのセキュリティ関連のオプションを含む 1 つのエンティティの関連情報のグループ) はサーバ内にキャッシュされます。これで、<run-as> タグのあるサーブレットおよび EJB メソッドや、HTTPSession で ID アサーションが使用されるがキャッシュはされない他の場面 (XML ドキュメントの署名や暗号化など) のパフォーマンスが大幅に向上します。
注意 : キャッシングは、セマンティクスに違反することがあります。
このキャッシュ内の項目の存続期間を変更するには、-Dweblogic.security.identityAssertionTTL コマンドライン引数を使用してサブジェクトがキャッシュに存在できる最大秒数を設定します。このコマンドライン引数のデフォルトは 300 秒 (5 分) です。コマンドライン引数に指定できる値は次のとおりです。
ID アサーションのパフォーマンスを向上させるには、このコマンドライン引数により大きな値を指定します。ID アサーションのパフォーマンスが上がるにつれて、ID アサーション プロバイダはコンフィグレーションされている認証プロバイダの変化に反応しなくなります。たとえば、ユーザのグループの変更はサブジェクトがキャッシュからフラッシュされて再作成されるまで反映されません。このコマンドライン引数でより小さい値を指定すると、認証変更の反応は良くなりますが、パフォーマンスは低下します。
WebLogic Server は、双方向 SSL 接続を確立するときに Web ブラウザまたは Java クライアントのデジタル証明書を確認します。ただし、デジタル証明書は Web ブラウザまたは Java クライアントを WebLogic Server セキュリティ レルムのユーザとしては認識しません。Web ブラウザまたは Java クライアントがセキュリティ ポリシーで保護された WebLogic Server リソースを要求すると、WebLogic Server は Web ブラウザまたは Java クライアントに ID を持つように要求します。WebLogic ID アサーション プロバイダは、Web ブラウザまたは Java クライアントのデジタル証明書を WebLogic Server セキュリティ レルムのユーザにマッピングするユーザ名マッパーを有効にできるようにします。
ユーザ名マッパーは、weblogic.security.providers.authentication.UserNameMapper インタフェースの実装でなければなりません。このインタフェースは、必要に応じた方式に従って、トークンを WebLogic Server のユーザ名にマップします。デフォルトでは、WebLogic Server は weblogic.security.providers.authentication.UserNameMapper インタフェースのデフォルトの実装が提供されます。また、独自の実装を記述することもできます。
WebLogic ID アサーション プロバイダは、以下の ID アサーション トークン タイプについて、ユーザ名マッパーを呼び出します。
デフォルトのユーザ名マッパーは、デジタル証明書または識別名のサブジェクト DN を使用して、WebLogic Server セキュリティ レルムの適切なユーザにマッピングします。たとえば、サブジェクト DN の電子メール属性 (smith@example.com) にあるユーザを、WebLogic Server セキュリティ レルムのユーザ (smith) にマッピングするように、ユーザ名マッパーをコンフィグレーションできます。この情報を定義するには、WebLogic ID アサーション プロバイダの [デフォルト ユーザ名マッパーの属性の種類] と [デフォルト ユーザ名マッパーの属性の区切り記号] を使用します。
C、CN、E、L、O、OU、S および STREET です。詳細については、Administration Console オンライン ヘルプの「ユーザ名マッパーのコンフィグレーション」を参照してください。
カスタム ユーザ名マッパーを記述して、必要に応じた方式に従ってトークンを WebLogic Server のユーザ名にマップすることもできます。カスタム ユーザ名マッパーは、weblogic.security.providers.authentication.UserNameMapper インタフェースの実装でなければなりません。次に、WebLogic ID アサーション プロバイダの [ユーザ名マッパーのクラス名] 属性を使用して、カスタム ユーザ名マッパーをアクティブなセキュリティ レルムでコンフィグレーションします。
詳細については、Administration Console オンライン ヘルプの「カスタム ユーザ名マッパーのコンフィグレーション」を参照してください。
|
|
|