|
|
WebLogic Server には、数多くの認証セキュリティ プロバイダが組み込まれています。ほとんどの認証プロバイダは同じように動作します。ユーザ名とパスワードの資格ペアが指定されると、認証プロバイダはそのデータ ストアから対応するユーザを見つけ出そうとします。これらの認証プロバイダの主な違いは、使用するデータ ストアの種類にあります (使用可能な LDAP サーバの 1 つ、SQL データベース、またはその他のデータ ストア)。ユーザ名とパスワードをベースとしたセキュリティ プロバイダの他にも、WebLogic Server には ID アサーション認証プロバイダが組み込まれています。ID アサーション認証プロバイダは、ユーザ名とパスワードのペアではなく証明書またはセキュリティ トークンを資格として使用します。
以下の節では、WebLogic Server で提供されている認証セキュリティ プロバイダをコンフィグレーションする方法について説明します。
認証とは、ユーザおよびシステム プロセスの ID を証明または検証するプロセスです。認証には、必要に応じて、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 制御フラグを設定することもできます。
既存のセキュリティ レルムにさらに認証プロバイダを追加する場合、[制御フラグ] はデフォルトで [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 認証プロバイダがセキュリティ レルムにコンフィグレーションされている唯一の認証プロバイダの場合、WebLogic Server を起動して LDAP ディレクトリ内のユーザまたはグループを使用するには、Admin ロールを持つ必要があります。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 ロールを割り当てます。
LDAP 認証プロバイダは以下のようにコンフィグレーションします。
このリリースの 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 において特別な索引付けがされており、これによりルックアップの応答が高速になります。「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 文属性のデフォルト値は、データベース スキーマに次のテーブルが含まれていることを前提としたものです。
| 注意 : | 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 Server Administration Console に表示します。
Windows NT 認証プロバイダを使用するには、Administration Console で Windows NT 認証プロバイダを作成します。ほとんどの場合、この認証プロバイダのコンフィグレーションでは何も行う必要はありません。ただし、Windows NT ドメインのコンフィグレーションによっては、Windows NT 認証プロバイダと Windows NT ドメインの対話方法を制御する属性である [ドメイン コントローラ] および [ドメイン コントローラ リスト] を設定します。
Windows NT ドメインのユーザ名には、いくつかの形式があります。サインオンするときに使用するユーザ名の形式に合わせて、Windows NT 認証プロバイダをコンフィグレーションする必要があります。単純なユーザ名には、ドメイン名は入りません (smith など)。複合ユーザ名は、ユーザ名とドメイン名の組み合わせです (domain\smith や smith@domain など)。
ローカル マシンが Microsoft ドメインの一部でない場合、[ドメイン コントローラ] および [ドメイン コントローラ リスト] 属性の変更は必要ありません。スタンドアロン マシンでは、認証を受けるユーザとグループはそのマシンのみで定義されます。
ローカル マシンが Microsoft ドメインの一部であり、ローカル ドメインのドメイン コントローラである場合、[ドメイン コントローラ リスト] 属性の変更は必要ありません。この場合、ローカル マシンとローカル ドメインで定義されているユーザは同じなので、[ドメイン コントローラ] のデフォルトの設定を使用できます。
ローカル マシンが Microsoft ドメインの一部であるが、ローカル ドメインのドメイン コントローラではない場合、単純ユーザ名はローカル マシンまたはドメインのいずれかで発見されます。この場合は、以下のことを考慮します。
いずれかの質問の答えが「はい」の場合、[ドメイン コントローラ] 属性を DOMAIN に設定します。
信頼性のあるドメインが複数ある場合、[ドメイン コントローラ] 属性を LIST に設定し、[ドメイン コントローラ リスト] を指定する必要が生じる場合があります。これは、以下の場合に行います。
このいずれかの場合、[ドメイン コントローラ] 属性を LIST に設定し、使用する信頼性のあるドメインの [ドメイン コントローラ リスト] 属性にドメイン コントローラの名前を指定します。また、ローカル マシンとローカル ドメイン コントローラの明示的な名前を使用するかどうか、またはそれらのリストでプレースホルダを使用するかどうかも検討します。[ドメイン コントローラ リスト] 属性には以下のプレースホルダを使用できます。
Windows NT 認証プロバイダの LogonType 属性の適切な値は、認証できるようにするユーザの Windows NT ログオン権限によって異なります。
Windows NT ドメインのユーザには、上記の権限のいずれかを割り当てる必要があります。このようにしない場合、Windows NT 認証プロバイダはユーザを認証できません。
UPN 型のユーザ名の形式は、user@domain です。@ 記号を含むが UPN 名ではないユーザ名を Windows NT 認証プロバイダがどのように扱うかは、Windows NT 認証プロバイダの mapUPNNames 属性で設定します。
UPN ユーザ名以外に、@ 記号を含むユーザ名が Windows NT ドメインとローカル マシンに存在しない場合、mapUPNNames 属性のデフォルト値である FIRST を使用できます。しかし、この値を ALWAYS に変更することによって、認証の失敗の検出時間を短縮できる場合があります。これは特に、長いドメイン コントローラ リストを指定した場合に効果的です。
Windows NT ドメインで、@ 記号を含む UPN 以外のユーザ名が存在する場合、次のように設定します。
境界認証を使用する場合、ID アサーション プロバイダを使用する必要があります。境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します (これは単純認証とは対照的です。単純認証では、WebLogic Server がユーザ名とパスワードを通じて信頼を確立します)。ID アサーション プロバイダは、トークンを検証し、そのトークンの妥当性と信頼性を確立するために必要なアクションを実行します。各 ID アサーション プロバイダは、1 つまたは複数のトークン フォーマットをサポートします。
WebLogic Server には、以下の新しい ID アサーション プロバイダが組み込まれています。
セキュリティ レルムでは複数の ID アサーション プロバイダをコンフィグレーションできますが、必須ではありません。ID アサーション プロバイダでは複数のトークン タイプをサポートできますが、一度にアクティブになるのは ID アサーション プロバイダごとに 1 つのトークン タイプだけです。Administration Console の [プロバイダ固有] コンフィグレーション ページの [アクティブな種類] フィールドで、アクティブなトークン タイプを定義します。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 つです。| 注意 : | この方法は非推奨で、下位互換性のためだけに使用する必要があります。 |
<TOKEN> という形式の名前を持つヘッダ。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つです。<TOKEN> という形式の名前を持つクッキー。<TOKEN> は、デフォルト セキュリティ レルムの ID アサーション プロバイダに対してコンフィグレーションされているアクティブなトークン タイプの 1 つです。
たとえば、デフォルト セキュリティ レルムの ID アサーション プロバイダがアクティブなトークン タイプとして FOO および BAR というトークンを持つようにコンフィグレーションされている場合 (次の例では、HTTP リクエストには ID アサーションに関連するものはアクティブなトークン タイプ以外、何も含まれていないものとする)、ID アサーションは次のように実行されます。
同じレベルの複数のトークン間の順序付けは定義されていません。そのため、次のようになります。
ID アサーション プロバイダ (X.509 証明書またはその他のトークン) を使用する場合、サブジェクトはサーバにキャッシュされます (サブジェクトとは、単一のエンティティ (個人など) に関連する情報のグループで、ID やそのセキュリティ関連のコンフィグレーション オプションなどが含まれます)。サーバ内にサブジェクトをキャッシュすると、<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 アサーション プロバイダの [デフォルト ユーザ名マッパーの属性の種類] と [デフォルト ユーザ名マッパーの属性の区切り記号] を使用します。
詳細については、Administration Console オンライン ヘルプの「ユーザ名マッパーのコンフィグレーション」を参照してください。
カスタム ユーザ名マッパーを記述して、必要に応じた方式に従ってトークンを WebLogic Server のユーザ名にマップすることもできます。カスタム ユーザ名マッパーは、weblogic.security.providers.authentication.UserNameMapper インタフェースの実装でなければなりません。次に、WebLogic ID アサーション プロバイダの [ユーザ名マッパーのクラス名] 属性を使用して、カスタム ユーザ名マッパーをアクティブなセキュリティ レルムでコンフィグレーションします。
詳細については、Administration Console オンライン ヘルプの「カスタム ユーザ名マッパーのコンフィグレーション」を参照してください。
  
|
