Administration Console オンライン ヘルプ
[セキュリティに関する属性と Administration Console 画面のリファレンス]
このトピックでは、このリリースの WebLogic Server におけるセキュリティのコンフィグレーションと管理について説明します。詳細については、『WebLogic Security の管理』を参照してください。
互換性セキュリティを使用する WebLogic Server デプロイメントのセキュリティのコンフィグレーションと管理については、互換性セキュリティおよび『WebLogic Security の管理』の「互換性セキュリティの使い方」を参照してください。
WebLogic Server のセキュリティのコンフィグレーションと管理を簡素化するために、デフォルトのセキュリティ レルム (myrealm) が用意されています。デフォルトのセキュリティ レルムには、WebLogic の認証、ID アサーション、認可、裁決、ロール マッピング、および資格マッピングの各プロバイダがコンフィグレーションされています。デフォルトのセキュリティ コンフィグレーションを使用する場合、セキュリティ レルムでグループ、ユーザ、およびセキュリティ ロールを定義し、ドメイン内の WebLogic リソースに対するセキュリティ ポリシーを作成するだけで済みます。組み込み LDAP サーバのコンフィグレーションが適切であるかどうかも確認する必要があります。必要に応じて、デフォルト レルムの監査プロバイダをコンフィグレーションできます。
デフォルト セキュリティ コンフィグレーションでは要件が満たされない場合、WebLogic セキュリティ プロバイダとカスタム セキュリティ プロバイダを自由に組み合わせて新しいセキュリティ レルムを作成し、そのセキュリティ レルムをデフォルト セキュリティ レルムとして設定できます。詳細については、新しいセキュリティ レルムのコンフィグレーションを参照してください。
注意: この節は GroupReader セキュリティ サービス プロバイダ インタフェース (SSPI) を実装する認証プロバイダ (WebLogic 認証プロバイダなど) に適用されます。使用する認証プロバイダがこの SSPI を実装していない場合、WebLogic Server Administration Console でユーザを管理することはできません。
グループ名はユニークでなければなりません。 グループとユーザを同じ名前で定義しないでください。 カンマ、タブ、< >、#、|、&、?、( )、{ } は使用しないでください。 グループ名では大文字と小文字を区別します。
グループには大文字で始まる複数形の名前を使用することをお勧めします (たとえば Administrators)。
注意: この節は UserEditor SSPI を実装する認証プロバイダ (WebLogic 認証プロバイダなど) に適用されます。使用する認証プロバイダが UserEditor SSPI を実装していない場合、WebLogic Server Administration Console でユーザを管理することはできません。
ユーザ名はユニークでなければなりません。 グループとユーザを同じ名前で定義しないでください。 カンマ、タブ、< >、#、|、&、?、( )、{ } は使用しないでください。 ユーザ名では大文字と小文字を区別します。
プロダクション環境では、ユーザ名とパスワードの組み合わせとして weblogic
/weblogic
を使用しないでください。
注意: WebLogic 認証プロバイダで定義されているユーザの最小パスワード長は 8 文字です。ただし、パスワードの規則 (文字の種類や長さなど) は認証プロバイダによって異なります。
注意: WebLogic 認証プロバイダで定義されているユーザの最小パスワード長は 8 文字です。ただし、パスワードの規則 (文字の種類や長さなど) は認証プロバイダによって異なります。
WebLogic Server には、ユーザ アカウントを侵入者から保護するための属性セットが用意されています。デフォルトでは、これらの属性は最高の保護レベルに設定されています。システム管理者は、すべての属性を無効にしたり、ユーザ アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザ アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザ アカウントのロック時間を変更したりできます。これらの属性を変更すると、セキュリティ レベルが低下して攻撃を受けやすくなることに注意してください。
[ユーザ ロックアウト] 属性を設定するには、次の手順に従います。
ユーザ アカウントのロックを解除するには、次の手順に従います。
セキュリティ レルム内 (したがって WebLogic Server ドメイン全体) にデプロイされているすべての WebLogic リソースに適用されるセキュリティ ロールはグローバル ロールと呼ばれます。
ここではグローバル ロールの作成手順について説明します。ただし、グローバル ロールの作成手順にはいくつかの段階があり、さまざまなオプションが用意されています。この手順を詳細に理解するには、『WebLogic リソースのセキュリティ』を参照してください。
注意: 大文字で始まる単数の名前を使用することをお勧めします (たとえば SecurityEng)。
注意: セキュリティ ロール名にはスペースや < > 文字を使用しないでください。セキュリティ ロール名では大文字と小文字を区別します。BEA の規約では、すべてのセキュリティ ロール名は単数形です。
注意: [呼び出し側をメンバとするグループは] 条件を使用して式を作成することをお勧めします。グループを使用してセキュリティ ロールを作成すると、そのグループのすべてのメンバー (つまり複数のユーザ) にセキュリティ ロールを付与できます。
[上へ移動] および [下へ移動] ボタンを使用すると、選択したユーザ名またはグループ名の順序を変更できます。[変更] ボタンを使用すると、式の間の選択された and
文と or
文を切り替えることができます。[削除] ボタンを使用すると、選択されたユーザ名またはグループ名が削除されます。
セキュリティ レルムにデプロイされている WebLogic リソースの特定のインスタンス (EJB のメソッドや JNDI ツリーのブランチなど) に適用されるセキュリティ ロールはスコープ ロールと呼ばれます。スコープ ロールの作成手順は、WebLogic リソースのタイプや、セキュリティ ロールのスコープのレベルによって若干異なります。以下の節で説明する適切な手順を使用してください。
WebLogic リソースに対するスコープ ロールの定義方法の詳細については、『WebLogic リソースのセキュリティ』を参照してください。
URL (Web) リソースに対するスコープ ロールを作成するには、次の手順に従います。
注意: セキュリティ ロール名にはスペースや < > 文字を使用しないでください。ロール名では大文字と小文字を区別します。BEA の規約では、すべてのセキュリティ ロール名は単数形です。
注意: [呼び出し側をメンバとするグループは] 条件を使用して式を作成することをお勧めします。グループを使用してセキュリティ ロールを作成すると、そのグループのすべてのメンバー (つまり複数のユーザ) にセキュリティ ロールを付与できます。
[上へ移動] および [下へ移動] ボタンを使用すると、選択したユーザ名またはグループ名の順序を変更できます。[変更] ボタンを使用すると、式の間の選択された and
文と or
文を切り替えることができます。[削除] ボタンを使用すると、選択されたユーザ名またはグループ名が削除されます。
EJB リソースに対するスコープ ロールを作成するには、次の手順に従います。
すべての EJB JAR に対するスコープ ロールを作成するには、[EJB] の上で右マウス ボタンをクリックします。特定の EJB JAR または JAR 内の EJB に対するスコープ ロールを作成するには、[EJB] の横の + 記号をクリックしてから、EJB JAR の名前の上で右マウス ボタンをクリックします。
[Select Roles] ページが表示されます。WebLogic ロール マッピング プロバイダのデータベースに、この WebLogic リソースに対して現在定義されているスコープ ロールがある場合は、このページに表示されます。
注意: セキュリティ ロール名にはスペースや < > 文字を使用しないでください。セキュリティ ロール名では大文字と小文字を区別します。BEA の規約では、すべてのセキュリティ ロール名は単数形です。
注意: [呼び出し側をメンバとするグループは] 条件を使用して式を作成することをお勧めします。グループを使用してセキュリティ ロールを作成すると、そのグループのすべてのメンバー (つまり複数のユーザ) にセキュリティ ロールを付与できます。
[上へ移動] および [下へ移動] ボタンを使用すると、選択したユーザ名またはグループ名の順序を変更できます。[変更] ボタンを使用すると、式の間の選択された and
文と or
文を切り替えることができます。[削除] ボタンを使用すると、選択されたユーザ名またはグループ名が削除されます。
JNDI リソースに対するスコープ ロールを作成するには、次の手順に従います。
[Create Role] ページが表示されます。WebLogic ロール マッピング プロバイダのデータベースに、この WebLogic リソースに対して現在定義されているスコープ ロールがある場合は、このページに表示されます。
注意: セキュリティ ロール名にはスペースや < > 文字を使用しないでください。セキュリティ ロール名では大文字と小文字を区別します。BEA の規約では、すべてのセキュリティ ロール名は単数形です。
注意: [呼び出し側をメンバとするグループは] 条件を使用して式を作成することをお勧めします。グループを使用してセキュリティ ロールを作成すると、そのグループのすべてのメンバー (つまり複数のユーザ) にセキュリティ ロールを付与できます。
[上へ移動] および [下へ移動] ボタンを使用すると、選択したユーザ名またはグループ名の順序を変更できます。[変更] ボタンを使用すると、式の間の選択された and
文と or
文を切り替えることができます。[削除] ボタンを使用すると、選択されたユーザ名またはグループ名が削除されます。
WebLogic Server Administration Console を使用して、Web サービス リソース以外のタイプの WebLogic リソースに対するスコープ ロールを作成できます。ただし、WebLogic Server Administration Console のナビゲーション ツリーでは、すべての WebLogic リソースが [デプロイメント] ノードの下に表示されるわけではありません。また、リソース階層の同じレベルで、どの WebLogic リソース タイプにもスコープ ロールを作成できるとは限りません。たとえば、JDBC 接続プールは [サービス|JDBC] ノードの下に表示されます。また、JMS リソースに対するスコープ ロールは、[サービス|JMS] ノードでのみ作成できます。したがって、このタスクを実行するための手順は多少異なるため、他の WebLogic リソース タイプに対するスコープ ロールを作成するには、前の節で説明した手順を応用する必要があります。
セキュリティ ポリシーは WebLogic リソースを保護するために使用します。セキュリティ ポリシーは、WebLogic リソースと、ユーザ、グループ、またはセキュリティ ロールとの関連付けを定義する際に作成します。また、セキュリティ ポリシーに時間の制約も関連付けることができます。WebLogic リソースは、セキュリティ ポリシーを割り当てられるまで、保護の対象となりません。
セキュリティ ポリシーの作成手順にはいくつかの段階があり、さまざまなオプションが用意されています。この手順を詳細に理解するには、『WebLogic リソースのセキュリティ』を参照してください。
組み込み LDAP サーバには、ユーザ、グループ、グループ メンバーシップ、セキュリティ ロール、セキュリティ ポリシー、および資格マップ情報が格納されます。デフォルトでは、各 WebLogic Server ドメインに、各属性のデフォルト値がコンフィグレーションされている組み込み LDAP サーバが 1 つあります。WebLogic の認証、認可、資格マッピング、およびロール マッピングの各プロバイダでは、データベースとして組み込み LDAP サーバを使用します。新しいセキュリティ レルムでこれらのプロバイダのいずれかを使用する場合は、組み込み LDAP サーバのデフォルト値を変更して、環境に合わせて使用方法を最適化できます。
組み込み LDAP サーバをコンフィグレーションするには、次の手順に従います。
注意: WebLogic セキュリティ プロバイダは、組み込み LDAP サーバにデータを格納します。WebLogic セキュリティ プロバイダを削除しても、組み込み LDAP サーバのセキュリティ データは自動的には削除されません。そのプロバイダを再び使用するときのために、セキュリティ データは組み込み LDAP サーバに残ります。外部 LDAP ブラウザを使用して、組み込み LDAP サーバのセキュリティ データを削除してください。
組み込み LDAP サーバのバックアップをコンフィグレーションするには、次の手順に従います。
新しいセキュリティ レルムをコンフィグレーションするには、次の手順に従います。
[デプロイメント記述子のロールとポリシーを無視]
オプションを選択します。ejb-jar.xml
、weblogic-ejb-jar.xml
、web.xml
、および weblogic.xml
ファイル) だけを使用して URL および EJB リソースを保護するには、[デプロイメント記述子のロールとポリシーを初期化]
オプションを選択します。weblogic-ra.xml
デプロイメント記述子ファイルから組み込み LDAP サーバに資格マップをロードしてから、WebLogic Server Administration Console を使用して、新しい資格マップを作成したり、既存の資格マップを変更したりすることもできます。weblogic-ra.xml
デプロイメント記述子ファイルから組み込み LDAP サーバに情報をロードしても、元のリソース アダプタはそのまま変更されません。したがって、元のリソース アダプタを再デプロイすると (WebLogic Server Administration Console から再デプロイする、ディスク上で変更する、または WebLogic Server を再起動する場合に発生)、weblogic-ra.xml
デプロイメント記述子ファイルからデータが再びインポートされて、資格マッピング情報が失われるおそれがあります。
新しい資格マッピング情報が weblogic-ra.xml
デプロイメント記述子ファイルの古い情報で上書きされないようにするには、[Ignore Security Data in Deployment Descriptors] 属性を有効にします。
注意: 資格マップを組み込み LDAP サーバにロードするには、セキュリティ レルムの資格マッピング プロバイダで、[資格マッピング デプロイメントを有効化] 属性がチェックされている必要があります。詳細については、WebLogic 資格マッピング プロバイダのコンフィグレーションを参照してください。
新しいセキュリティ レルムのコンフィグレーションは、複雑なタスクです。セキュリティ レルムのコンフィグレーションを正しく行わないと、そのセキュリティ レルムをデフォルトのセキュリティ レルムとして設定することができません。WebLogic Server では、セキュリティ レルムのコンフィグレーションを検証して、正しいかどうか確認することができます。
新しいセキュリティ レルムのコンフィグレーションを検証するには、次の手順に従います。
WebLogic Server には、以下のタイプの認証プロバイダが用意されています。
注意: これらの LDAP 認証プロバイダに限定されているわけではありません。サポートされている以外の LDAP サーバを使用するには、使用する LDAP サーバに最も近いデフォルト値を持つ LDAP サーバ タイプを選択して、属性値を適宜変更します。
また、違うタイプの認証技術を提供するカスタム認証プロバイダを使用することもできます。詳細については、カスタム セキュリティ プロバイダのコンフィグレーションを参照してください。
注意: WebLogic Server Administration Console では、WebLogic 認証プロバイダを「Default Authenticator」と呼びます。
各セキュリティ レルムには、少なくとも 1 つの認証プロバイダがコンフィグレーションされている必要があります。WebLogic Security フレームワークは、さまざまな要素から成る認証向けに、複数の認証プロバイダ (したがって、複数の LoginModule) をサポートするように設計されています。そのため、複数の認証プロバイダを使用できます。また、1 つのセキュリティ レルムで複数のタイプの認証プロバイダを使用できます。[制御フラグ] 属性は、各認証プロバイダの LoginModule が認証プロセスでどのように使用されるかを決定します。詳細については、JAAS 制御フラグの設定を参照してください。
認証プロバイダをコンフィグレーションするには、次の手順に従います。
複数の認証プロバイダをコンフィグレーションする場合は、JAAS 制御フラグの設定を参照してください。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、[認証|一般] ページの [制御フラグ] 属性で認証プロバイダの実行順序を決定します。次に、制御フラグ属性の値を示します。
認証プロバイダがコンフィグレーションされる順序は、認証プロバイダの LoginModule が呼び出される順序となります。認証プロバイダの順序はいつでも変更できます。詳細については、認証プロバイダの順序の変更を参照してください。
注意: 複数の認証プロバイダを定義した場合、WebLogic Server を起動するには、[制御フラグ] 属性が [REQUISITE] または [REQUIRED] に設定されているすべての認証プロバイダで、サーバを起動するユーザがユーザとして定義されている必要があります。
WebLogic Server Administration Console では、実際には、セキュリティ プロバイダの作成時に JAAS 制御フラグが [OPTIONAL] に設定されます。 セキュリティ プロバイダの MBean は、デフォルトで [REQUIRED] に設定されます。
注意: WebLogic Server Administration Console では、WebLogic 認証プロバイダを「Default Authenticator」と呼びます。
WebLogic 認証プロバイダは大文字と小文字を区別しません。ユーザ名がユニークであるようにしてください。
WebLogic 認証プロバイダを使用すると、ユーザおよびグループ メンバーシップを編集したり、リストしたり、管理したりすることができます。WebLogic 認証プロバイダのユーザおよびグループ メンバーシップ情報は、組み込み LDAP サーバに格納されます。
WebLogic 認証プロバイダをコンフィグレーションするには、次の手順に従います。
LDAP 認証プロバイダをコンフィグレーションするには、次の手順に従います。
LDAP サーバおよびキャッシング情報を設定するには、次の手順に従います。
デプロイメントをよりセキュアにするために、SSL プロトコルを使用して LDAP サーバと WebLogic Server 間の通信を保護することをお勧めします。
LDAP ディレクトリにおけるユーザの検索方法を指定するには、次の手順に従います。
LDAP ディレクトリにおけるグループの格納方法と検索方法を指定するには、次の手順に従います。
注意: iPlanet 認証プロバイダは、動的グループをサポートしています。動的グループを使用するには、[メンバ] ページで、[動的グループ オブジェクト クラス]、[動的グループ名属性]、および [動的メンバ URL 属性] の各属性を設定する必要があります。
LDAP ディレクトリにおけるグループ メンバーの格納方法と検索方法を指定するには、次の手順に従います。
LDAP 認証プロバイダでコンフィグレーションされている LDAP サーバのフェイルオーバをコンフィグレーションするには、次の手順を行います。
レルム アダプタ認証プロバイダをコンフィグレーションするには、次の手順に従います。
複数の認証プロバイダをコンフィグレーションする方法は、認証プロセスの全体的な結果に影響し、特にさまざまな要素から成る認証では重要となります。認証プロバイダはコンフィグレーションされた順序で呼び出されます。認証プロバイダのテーブルに、コンフィグレーションされた順序で認証プロバイダが表示されます。[コンフィグレーション済み認証プロバイダの並べ替え] リンクをクリックし、プロバイダの順序を変更します。各認証プロバイダの [制御フラグ] 属性の設定によって、認証プロセスの結果が影響されることに注意してください。詳細については、JAAS 制御フラグの設定を参照してください。
注意: WebLogic Server Administration Console では、WebLogic 認可プロバイダを「Default Authorizer」と呼びます。
WebLogic 認可プロバイダをコンフィグレーションするには、次の手順に従います。
WebLogic 資格マッピング プロバイダをコンフィグレーションするには、次の手順に従います。
ロール マッピング プロバイダをコンフィグレーションするには、次の手順に従います。
注意: WebLogic Server Administration Console では、WebLogic ID アサーション プロバイダを「Default Identity Asserter」と呼びます。
WebLogic ID アサーション プロバイダの属性を定義するには、次の手順に従います。
*
) を使用して、すべてのクライアント プリンシパルを指定できます。Web アプリケーションの認証タイプを CLIENT-CERT
に設定した場合、WebLogic Server の Web アプリケーション コンテナは、リクエストのヘッダおよびクッキーの値に対して ID アサーションを実行します。ヘッダ名またはクッキー名が、コンフィグレーションされている ID アサーション プロバイダのアクティブなトークン タイプに一致していれば、値はプロバイダに渡されます。
[Base64Decoding が必要] 属性では、リクエスト ヘッダ値またはクッキー値を ID アサーション プロバイダへ送信する前に、その値を Base 64 でデコードするかどうかを指定します。この設定はデフォルトでは下位互換性のために有効になっていますが、ほとんどの ID アサーション プロバイダでは、この属性は無効化されます。
シングル パス ネゴシエート ID アサーション プロバイダのコンフィグレーションは、以下の手順で行います。
注意: WebLogic Server Administration Console では、WebLogic 裁決プロバイダを「Default Adjudicator」と呼びます。
WebLogic 裁決プロバイダをコンフィグレーションするには、次の手順に従います。
警告: 監査プロバイダを使用すると、数個のイベントのログが記録される場合でも WebLogic Server のパフォーマンスに影響が及びます。
Warning: 新しいセキュリティ レルムを作成する場合、必要に応じて監査プロバイダをコンフィグレーションします。WebLogic Server Administration Console では、WebLogic 監査プロバイダを「Default Auditor」と呼びます。
WebLogic 監査プロバイダをコンフィグレーションするには、次の手順に従います。
カスタム セキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。
セキュリティ プロバイダを削除するには、次の手順に従います。
注意: コンフィグレーション済みのセキュリティ プロバイダを WebLogic Server Administration Console で削除および修正した場合、データベースの手動クリーンアップが必要となる場合があります。
相互 SSL を使用している場合、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.security.providers.authentication.UserNameMapper
インタフェースのデフォルトの実装が提供されます。また、独自の実装を記述することもできます。
WebLogic ID アサーション プロバイダは、以下の ID アサーション トークン タイプについて、ユーザ名マッパーを呼び出します。
デフォルトのユーザ名マッパーは、デジタル証明書または識別名の主体の DN の属性を使用して、WebLogic Server セキュリティ レルムの適切なユーザにマッピングします。たとえば、ユーザ名マッパーを、主体の DN の [E メール] 属性からユーザ (smith@bea.com
) を WebLogic Server セキュリティ レルムのユーザ (smith
) にマッピングするようにコンフィグレーションできます。
デフォルトのユーザ名マッパーを使用するには、次の手順に従います。
カスタム ユーザ名マッパーをインストールするには、次の手順に従います。
新しいセキュリティ レルムを作成する場合、セキュリティ データ (認証、認可、資格マップ、およびロールのデータ) をセキュリティ レルムからファイルにエクスポートし、別のセキュリティ レルムにインポートできます。この機能によって、すべてのセキュリティ データを再作成しなくても、新しいセキュリティ レルムを開発およびテストできます (たとえば、開発セキュリティ レルムをプロダクションに移動するときなど)。エクスポートおよびインポートできるのは、WebLogic のセキュリティ プロバイダのデータのみです。以下の 2 つのオプションが使用できます。
注意: 同じ WebLogic Server リリースのセキュリティ レルムの間でのみ、セキュリティ データをエクスポートおよびインポートできます。
セキュリティ データのエクスポートおよびインポートを行うには、次の手順に従います。
セキュリティ データが正しくインポートされたことを確認するには、次の手順に従います。
異なるセキュリティ レルムのプロバイダ間で、プロバイダ固有のセキュリティ データをエクスポートおよびインポートできます。各プロバイダにサポートされているフォーマット (DefaultAtn、DefaultAtz、DefaultCreds、または DefaultRoles) が表示されます。制約により、データ タイプ (ユーザ、グループ、ロール、および資格マップ) が定義されます。制約は、WebLogic 認証プロバイダでのみ表示されます。ユーザおよびグループ、ユーザのみ、グループのみ、または特定のグループのエクスポートおよびインポートをオプションで選択できるためです。
セキュリティ プロバイダからセキュリティ データをエクスポートおよびインポートするには、次の手順に従います。
デフォルトでは、myrealm がデフォルト セキュリティ レルムとして設定されています。
デフォルト セキュリティ レルムを適切に設定したかどうかを確認するには、次の手順に従います。
J2EE コネクタ アーキテクチャで定義されるリソース アダプタでは、エンタープライズ情報システム (EIS) で定義されるユーザが保護されている WebLogic リソースへのアクセスを要求した場合に、これらのユーザを認証するために必要な資格を取得できます。リソース アダプタをホストする WebLogic Server のコンテナは、資格マップを使って WebLogic リソースに対する適切な一連の資格を取得できます。資格マップでは、WebLogic Server のセキュリティ レルムのユーザと、EIS (Oracle データベース、SQL サーバ、SAP アプリケーションなど) に対するそのユーザの認証に使用される ID (ユーザ名とパスワードの組み合わせ) が関連付けられます。
資格マップは WebLogic Server Administration Console から作成できます。WebLogic 資格マッピング プロバイダを使用する場合、資格マップは組み込み LDAP サーバに格納されます。
weblogic-ra.xml
デプロイメント記述子ファイルの古い情報で上書きされるおそれがあります。デフォルトでは、WebLogic Server は 2 種類のキーストアがコンフィグレーションされています。
DemoIdentity.jks
—WebLogic Server のデモ用のプライベート キーがあります。このキーストアは WebLogic Server の ID を立証します。DemoTrust.jks
—WebLogic Server によって信頼される認証局のリストを格納します。このキーストアは WebLogic Server の信頼性を確立します。これらのキーストアは、BEA_HOME\weblogic710\server\lib
ディレクトリにあります。テストおよび開発においては、このキーストア コンフィグレーションで十分です。以下の手順は、プロダクション用途において ID キーストアおよび信頼キーストアをコンフィグレーションするための手順です。
これらの手順の詳細については、『WebLogic Security の管理』を参照してください。
ID キーストアおよび信頼キーストアの属性を設定するには、次の手順に従います。
BEA_HOME\server\lib
ディレクトリにあるデモ用の ID キーストアおよび信頼キーストア。デフォルトでコンフィグレーションされています。JAVA_HOME\jre\lib\security\cacerts
ディレクトリの cacerts ファイルで定義された、信頼性のある CA。jks
です。jks
です。デフォルトでは、一方向 SSL (サーバが ID をクライアントに渡す) を使用するようにコンフィグレーションされています。よりセキュアな SSL 接続のためには、相互 SSL を使用してください。相互 SSL 接続では、クライアントがサーバの ID および信頼を確認した後、クライアントの ID および信頼をサーバに渡します。サーバは、SSL 接続を完了する前に、クライアントの ID および信頼を確認します。サーバが相互 SSL を使用するかどうかを決定します。
信頼関係は、ある WebLogic Server ドメイン (以下「ドメイン」) のサブジェクト内のプリンシパルがローカル ドメインのプリンシパルとして受け付けられたときに確立されます。2 つのドメインを相互運用する場合、両方のドメインで次の手順を実行します。
WebLogic Server ドメイン間の信頼関係を確立するには、次の手順に従います。
WebLogic Server 6.x ドメインと WebLogic Server 7.0 ドメインを相互運用する場合、WebLogic Server 7.0 ドメインの [資格] 属性を、WebLogic Server 6.x ドメインの system
ユーザのパスワードに変更します。
接続フィルタをコンフィグレーションするには、次の手順に従います。