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 サーバには、動的グループまたは仮想グループの概念があります。これらは、ユーザとグループのリストで構成されるグループではなく、グループに属するユーザの集合を定義するポリシー文、クエリ、またはコードを格納するグループです。あるグループが動的としてマークされる場合、ユーザはグループ メンバシップへの何らかの変更が有効になる前にログアウトし、ログインし直す必要があります。動的という用語は、グループを定義する方法を指します。WebLogic Server 内でのグループの実行時セマンティクスを指すものではありません。
複数の 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 認証プロバイダの [コンフィグレーション] の [プロバイダ固有] および [パフォーマンス] ページ)。
キャッシュを設定する場合は、以下の点に留意する必要があります。
動的グループでは、メンバー名のリストは表示されません。代わりに、動的グループのメンバシップは、ユーザ属性の一致によって作成されます。動的グループのグループ メンバシップは動的に計算されるため、大規模なグループではパフォーマンスの問題が発生するおそれがあります。iPlanet 認証プロバイダを適切にコンフィグレーションすることで、動的グループが関係する個所のパフォーマンスを向上できます。
iPlanet 認証プロバイダの [ユーザ動的グループ DN 属性] 属性には、ユーザが所属する動的グループの識別名 (DN) を指定する LDAP ユーザ オブジェクトの属性を指定します。この属性が指定されていない場合、WebLogic Server は、動的グループの URL を評価することでユーザがグループのメンバーかどうかを判定します。デフォルトでは [ユーザ動的グループ DN 属性] は null です。[ユーザ動的グループ DN 属性] に他の何らかの値を設定してパフォーマンスを向上させる場合は、iPlanet 認証プロバイダに以下の属性を設定します。
UserDynamicGroupDNAttribute="wlsMemberOf"
DynamicGroupNameAttribute="cn"
DynamicGroupObjectClass=""
DynamicMemberURLAttribute=""
これらの属性を Administration Console で設定するには、次の手順に従います。
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 アサーション プロバイダへ送信する前に、その値を Base64 でデコードするかどうかを指定します。この設定はデフォルトでは下位互換性のために有効になっていますが、ほとんどの 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 アサーション プロバイダがコンフィグレーションされていなければなりません。
WebLogic Server のこのリリースには、2 種類の SAML ID アサーション プロバイダが用意されています。SAML ID アサーション プロバイダ バージョン 2 ではコンフィグレーション オプションが大幅に拡張されており、新しいデプロイメントにはこのバージョンの使用をお勧めします。SAML ID アサーション プロバイダ バージョン 1 は WebLogic Server 9.1 で非推奨になりました。セキュリティ レルムには複数の SAML ID アサーション プロバイダを含むことはできません。また、セキュリティ レルムに SAML ID アサーション プロバイダと SAML 資格マッピング プロバイダの両方が含まれる場合は、両方のバージョンが同じでなければなりません。バージョン 2 の SAML プロバイダと同じセキュリティ レルム内でバージョン 1 の SAML プロバイダを使用しないでください。SAML ID アサーション プロバイダ バージョン 1 のコンフィグレーションについては、WebLogic Server 9.0 マニュアルの「SAML ID アサーション プロバイダのコンフィグレーション」を参照してください。
SAML ID アサーション プロバイダを SAML シングル サインオン コンフィグレーションで使用する方法については、「Web ブラウザと HTTP クライアントによるシングル サインオンのコンフィグレーション」を参照してください。WebLogic Server での SAML のサポートの概要については、『WebLogic Security について』の「SAML (Security Assertion Markup Language)」を参照してください。
WebLogic Server を SAML セキュリティ アサーションのコンシューマとして機能するようにコンフィグレーションする場合には、SAML アサーションが受け付けられるパーティを登録する必要があります。各 SAML アサーティング パーティに対して、使用する SAML プロファイル、そのアサーティング パーティの詳細、そのアサーティング パーティで受信されるアサーションで予想される属性を指定できます。詳細については、以下を参照してください。
SAML ID アサーション プロバイダは、信頼性のある証明書のレジストリを保持します。証明書を受け取ると、このレジストリ内の証明書と照らし合わせて検証します。このレジストリの証明書は、以下の目的で使用されます。
Administration Console を使用して、信頼性のある証明書を証明書レジストリに追加できます。
[管理|証明書] ページで、レジストリの証明書を追加、削除、および表示します。
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 オンライン ヘルプの「カスタム ユーザ名マッパーのコンフィグレーション」を参照してください。