| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic リソースのセキュリティ > WebLogic リソースのタイプ |
|
WebLogic リソースのセキュリティ
|
WebLogic リソースは、基底の WebLogic Server エンティティを表します。これらのエンティティは、セキュリティ ロールとセキュリティ ポリシーを使用して、権限のないアクセスから保護できます。
WebLogic リソースは階層化されています。このため、セキュリティ ロールとセキュリティ ポリシーは自由なレベルで定義できます。 たとえば、エンタープライズ アプリケーション (EAR) 全体、複数の EJB を含むエンタープライズ JavaBean (EJB) JAR、その JAR 内の特定の EJB、その EJB 内の単一のメソッドなどに対してセキュリティ ロールとセキュリティ ポリシーを定義できます。
WebLogic Server のリソースについて以下の節で説明します。
管理リソースは、管理タスクの実行をユーザに許可する WebLogic リソースです。 WebLogic Server Administration Console、weblogic.Admin ツール、および MBean API を保護する場合は、管理リソースを保護します。
管理リソースはスコープを制限されています。 現在、WebLogic Server Administration Console を使用して、管理リソースに対するユーザ ロックアウト操作のみを保護することができます。 この操作は WebLogic Server 6.x と互換性があり、セキュリティ要件を満たすユーザはロックされたアカウントのロックを解除できます。 ユーザ ロックアウトの詳細については、『WebLogic Security の管理』の「ユーザ アカウントの保護」を参照してください。
アプリケーション リソースは、EAR (エンタープライズ アプリケーション アーカイブ) ファイルにパッケージ化されたエンタープライズ アプリケーションを表す WebLogic リソースです。 その他の WebLogic リソースと違い、アプリケーション リソースの階層は格納するための仕組みであり、タイプ別の階層ではありません。 エンタープライズ アプリケーション (たとえば EJB リソース、URL リソース、Web サービス リソース) を構成する複数の WebLogic リソースをまとめて保護する場合は、アプリケーション リソースを保護します。 つまり、エンタープライズ アプリケーションを保護すると、そのアプリケーション内のすべての WebLogic リソースがセキュリティ コンフィグレーションを継承します。
エンタープライズ アプリケーション (EAR) を構成する WebLogic リソースを個別に保護することもできます。 個々の WebLogic リソースのセキュリティ コンフィグレーションは、エンタープライズ アプリケーションから継承されたセキュリティ コンフィグレーションに優先します。
J2EE コネクタは、WebLogic Server などのアプリケーション サーバで EIS (エンタープライズ情報システム) に接続するために使用されるシステムレベルのソフトウェア ドライバです。 BEA では、EIS ベンダおよびサードパーティ アプリケーション開発者が開発し、Sun Microsystems の J2EE プラットフォーム仕様、バージョン 1.3 に準拠しているアプリケーション サーバにデプロイ可能なコネクタをサポートしています。 コネクタ (リソース アダプタとも呼ばれる) には、Java、および必要に応じて EIS との対話に必要なネイティブ コンポーネントが含まれます。
EIS (エンタープライズ情報システム) リソースは、コネクタとして設計された WebLogic リソースです。 EIS へのアクセスを保護するには、すべてのコネクタまたは個々のコネクタに対してセキュリティ ポリシーおよびセキュリティ ロールを作成します。
注意: EIS リソースの保護については、このマニュアルと『WebLogic J2EE コネクタ アーキテクチャ』の「セキュリティ」で取り上げています。
EIS リソースで使用する資格マップの作成手順については、『WebLogic Security の管理』の「エンタープライズ情報システムでのシングル サインオン」を参照してください。
WebLogic jCOM は、WebLogic Server でデプロイされる Java/J2EE オブジェクトと、Microsoft Office 製品ファミリ、Visual Basic オブジェクトおよび C++ オブジェクト、その他のコンポーネント オブジェクト モデル/分散コンポーネント オブジェクト モデル (COM/DCOM 準拠) 環境で使用できる Microsoft ActiveX コンポーネントとの間で双方向アクセスを可能にするソフトウェア ブリッジです。
COM リソースは、Microsoft のフレームワークに従ってプログラム コンポーネント オブジェクトとして設計された WebLogic リソースです。 BEA の双方向 COM-Java (jCOM) ブリッジ ツールを使用してアクセスする COM コンポーネントを保護するには、複数の COM クラスを含むパッケージまたは個々の COM クラスに対してセキュリティ ポリシーおよびセキュリティ ロールを作成します。
注意: COM リソースの保護については、このマニュアルと『WebLogic jCOM プログラマーズ ガイド』の「アクセス制御のコンフィグレーション」で取り上げています。
JDBC (Java Database Connectivity) リソース
JDBC (Java DataBase Connectivity) リソースは、JDBC 関連の WebLogic リソースです。 JDBC アクセスを保護するには、接続プール全体、個々の接続プール、またはマルチプールに対してセキュリティ ポリシーおよびセキュリティ ロールを作成します。 個々の接続プールを保護する場合、接続プールに対するすべての操作を保護する方法と、以下のいずれかの操作を指定する方法があります。
注意: セキュリティ ポリシーでマルチプール内の接続プールへのアクセスを制御する場合、アクセスのチェックは、JDBC リソース階層の 2 つのレベルで実行されます (マルチプールのレベルで 1 回、個々の接続プールのレベルで 1 回)。 こうした二重のチェックをすべてのタイプの WebLogic リソースで実行することで、セキュリティ レベルの高い方のセキュリティ ポリシーがアクセスを制御することになります。
JMS (Java Message Service) リソース
JMS (Java Messaging Service) リソースは、JMS 関連の WebLogic リソースです。 JMS の送り先を保護するには、送り先全体 (JMS キューおよび JMS トピック) または JMS サーバの個々の送り先に対するセキュリティ ポリシーおよびセキュリティ ロールを作成します。 JMS サーバの特定の送り先を保護する場合、送り先に対するすべての操作を保護する方法と、JMS キューに対する送信、検索、または受信操作を指定したり、JMS トピックに対する送信および受信操作を指定したりする方法があります。
JNDI (Java Naming and Directory Interface) リソース
JNDI は、LDAP (Lightweight Directory Access Protocol) や DNS (Domain Name System) など、既存のさまざまなネーミング サービスに対する共通インタフェースを提供します。 これらのネーミング サービスは、名前をオブジェクトに関連付けて、名前でオブジェクトをルックアップできるようにするバインディングを保持します。 JNDI を使用すると、分散アプリケーション内のコンポーネント同士が互いを見つけることができます。
JNDI は、特定のネーミング サービスまたはディレクトリ サービスの実装とは無関係に定義されています。 JNDI では、さまざまな新しいサービスや既存のサービスにアクセスするための多くのメソッドを使用できます。 このサポートでは、標準サービス プロバイダ インタフェース (SPI) 規約を使用して JNDI フレームワークに任意のサービス プロバイダ実装をプラグインできます。
JNDI (Java Naming and Directory Interface) リソースは、業界標準の JNDI SPI を使用して、異種エンタープライズ ネーミング サービスおよびディレクトリ サービスとの接続を可能にする WebLogic リソースです。 JNDI ツリーへのアクセスを保護するには、JNDI ツリー全体またはツリーの個々のブランチに対するセキュリティ ポリシーおよびセキュリティ ロールを作成します。 その際、すべての操作を保護することも、操作をルックアップ、変更、または一覧表示に限定することもできます。
多くのエンジニアリング チームでは、管理責任を複数のロールに分けています。 アプリケーションまたはモジュールをデプロイするパーミッションは 1 人か 2 人のチーム メンバーにしか付与しないが、サーバ コンフィグレーションを参照するパーミッションはチーム メンバー全員に付与する、というような設定がプロジェクトごとに行われます。 セキュリティ ポリシーで説明されているように、WebLogic Server では、管理者だけがセキュリティ ポリシーを使用して WebLogic リソースを保護できるようにすることで、このような責任の分担が可能になります。 一般に、セキュリティ ポリシーはユーザまたはユーザ グループに特定のセキュリティ ロールが付与されているかどうかに基づます。
サーバ リソースは、WebLogic Server のインスタンスに関連する WebLogic リソースです。 このタイプの WebLogic リソースには、サーバの起動、終了、ロック、およびロック解除が含まれているので、ほとんどの管理者が対話する WebLogic リソースとなります。 その他の WebLogic リソースと同様に、サーバ リソースとその操作はセキュリティ ポリシーを使用して保護されます。 ただし、サーバのコンフィグレーションは MBean を通じて公開されるので、管理者が MBean 操作にアクセスする方法に適用する保護措置もサーバ リソースに設定されます。
注意: サーバ リソースの保護については、このマニュアルと『管理者ガイド』の「システム管理操作の保護」で取り上げています。
URL (Web) リソースと EJB (エンタープライズ JavaBean) リソース
URL (Web) リソースは、Web アプリケーションに関連する WebLogic リソースです。 Web アプリケーションを保護するには、WAR (Web アプリケーション アーカイブ) ファイル、または Web アプリケーションの個々のコンポーネント (サーブレットや JSP など) に対するセキュリティ ポリシーおよびセキュリティ ロールを作成します。 EJB (エンタープライズ JavaBean) リソースは、EJB に関連する WebLogic リソースです。 EJB を保護するには、EJB JAR、EJB JAR 内の個々の EJB、または EJB の個々のメソッドに対するセキュリティ ポリシーおよびセキュリティ ロールを作成します。
Java 2 Enterprise Edition (J2EE) プラットフォームは Web アプリケーションおよび EJB のセキュリティをデプロイメント記述子で標準化しているので、WebLogic Server はこの標準メカニズムをセキュリティ サービスに統合して、URL リソースおよび EJB リソースの保護に 2 通りの方法を選択できるようにしています。 選択する方法によって、実行する手順が変わり、WebLogic Server Administration Console で別の事前設定が必要になります。 詳細については、それぞれ URL リソースおよび EJB リソースを保護する方法とURL リソースおよび EJB リソースを保護するための前提条件を参照してください。
注意: このマニュアルで説明されている EJB リソースに関する手順は、メッセージ駆動型 Bean (MDB) にも適用されます。
以下の節では、URL (Web) リソースおよび EJB (エンタープライズ JavaBean) リソースを保護するためのさまざまな方法を詳しく説明します。
WebLogic Server Administration Console を使用する
URL (Web) リソースおよびエンタープライズ JavaBean (EJB) リソースを保護する第 1 の方法は、WebLogic Server Administration Console を使用するものです。この方法の主な利点は、セキュリティ管理が統合されていることです。組織的なセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル ユーザ インタフェースから、すべてのセキュリティ コンフィグレーションを変更できます。ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーは、すべて Administration Console を使用して定義できます。結果として、更新されたセキュリティ要件に基づく変更のプロセスが効率的になります。
Web サービス リソースを除き、すべてのタイプの WebLogic リソースをこの方法で保護できます。このため、このマニュアルで説明する WebLogic リソースの保護手順は、特に Administration Console のユーザに向けて書かれています。
URL リソースおよび EJB リソースを保護する第 2 の方法は、Java 2 Enterprise Edition (J2EE) のデプロイメント記述子と WebLogic デプロイメント記述子を使用するものです。この方法の主な利点は、URL と EJB に宣言的なセキュリティを追加するための一般的かつ標準的な方法であることです。多くの企業にとって一般的な方法でもあります。 この方法の場合、ユーザとグループは WebLogic Server Administration Console で定義できますが、セキュリティ ロールとセキュリティ ポリシーは web.xml、weblogic.xml、ejb-jar.xml、および weblogic-ejb-jar.xml デプロイメント記述子で定義されます。
注意: この方法を使用する場合、デプロイメント記述子はテキスト エディタで編集することも、Administration Console で編集することもできます。 Administration Console の使い方の詳細については、「Web アプリケーション デプロイメント記述子エディタ (war)」および『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「EJB デプロイメント記述子エディタの使用」を参照してください。
WebLogic Server 7.0 SP02 では、<global-role/> という特別なタグが導入されました。このタグを使用すると、セキュリティ ロール マッピングをデプロイメント記述子または Administration Console のどちらで定義するかをロールごとに指定できます。 URL または EJB リソースでのこのタグの使用については、『WebLogic Security プログラマーズ ガイド』の「Web アプリケーションでの <global-role/> タグの使用」と「EJB での <global-role/> タグの使用」をそれぞれ参照してください。
この方法では、URL および EJB リソースのみを保護できます。 デプロイメント記述子の使い方については、『WebLogic Security プログラマーズ ガイド』の「Web アプリケーションでの宣言によるセキュリティの使用」および「EJB での宣言によるセキュリティの使用」を参照してください。
現在デプロイメント記述子を使用して URL リソースと EJB リソースを保護している組織では、WebLogic Server Administration Console の統一されたセキュリティ管理機能を利用することもできます。 このような場合、Web アプリケーションまたは EJB モジュールの初回のデプロイ時に、既存のデプロイメント記述子からセキュリティ コンフィグレーションをコピーするように Administration Console に指示することができます。セキュリティ コンフィグレーションをコピーすると、以降の更新では Administration Console を使用できます。また、この組み合わせた方法を使用して、URL および EJB リソースのセキュリティ コンフィグレーションを、デプロイメント記述子で指定されている状態に再初期化することもできます。
警告: 組み合わせた方法を使用する場合、URL (Web) および EJB リソースのセキュリティ コンフィグレーションはオーバライドされる可能性があります。 したがって、組み合わせた方法を使用する場合は、その Web アプリケーションや EJB の適切なセキュリティ コンフィグレーションが用意されていることを十分に確認する必要があります。 重要な情報については、URL リソースおよび EJB リソースを保護するための前提条件を参照してください。
組み合わせた方法の詳細については、例 : basicauth Web アプリケーションのセキュリティ コンフィグレーションのコピーと再初期化を参照してください。
URL リソースおよび EJB リソースを保護するための前提条件
WebLogic Server Administration Console またはデプロイメント記述子のいずれかを使用して URL および EJB リソースを保護する場合でも、WebLogic Server の重要な 2 つの設定について理解しておく必要があります。これらの設定を理解していないと、セキュリティ コンフィグレーションが不適切なものになったり、失われたりすることがあります。
URL または EJB リソースを保護する前に、以下の節を読んでおいてください。
fullyDelegateAuthorization フラグについて
パフォーマンスを制御するために、WebLogic Server Administration Console では WebLogic Security サービスがセキュリティ チェックを実行する方法を指定する必要があります。 これを指定するには、WebLogic Server の起動時に設定するコマンドライン引数である fullyDelegateAuthorization フラグを使用します。
注意: WebLogic Server 7.0 SP3 では、コマンドライン引数を使用する代わりに、WebLogic Server Administration Console でこの設定を指定できるようになりました。 詳細については、[ロールとポリシーのチェック対象] 設定を参照してください。
fullyDelegateAuthorization フラグの値が false の場合、WebLogic Security サービスは、関連付けられているデプロイメント記述子 (DD) でセキュリティが指定されている URL および EJB リソースに対してのみセキュリティ チェックを実行します。これはデフォルト設定です。
fullyDelegateAuthorization フラグの値が true の場合、WebLogic Security サービスは、すべての URL (Web) および EJB リソースに対して、そのデプロイメント記述子 (DD) にセキュリティ設定があるかどうかに関係なく、セキュリティ チェックを実行します。 fullyDelegateAuthorization フラグの値を true に変更した場合は、Web アプリケーションまたは EJB モジュールが再デプロイされるときに WebLogic Security サービスが実行する処理を指定する必要があります。 詳細については、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについてを参照してください。
注意: fullyDelegateAuthorization フラグは、それが設定されている WebLogic Server インスタンス (サーバ) に対してのみ有効です。 したがって、管理サーバと管理対象サーバの両方で fullyDelegateAuthorization フラグが同じように設定されていることを確認してください。
fullyDelegateAuthorization フラグの変更方法
fullyDelegateAuthorization フラグは以下の 3 つの方法のいずれかで設定できます。
-Dweblogic.security.fullyDelegateAuthorization = boolean_value
boolean_value は true または false です。WebLogic Server インスタンスを起動するたびにフラグを設定する必要がなくなるため、こちらの方が効率的です。ただし、この設定はインストールされているすべての WebLogic Server ドメインに適用されます。
リスト2-1 に、このフラグ (太字) を true に設定した startWLS ファイルの該当箇所を示します。
コード リスト 2-1 startWLS スクリプトのサンプル
@rem Start Server
@echo off
if "%ADMIN_URL%" == "" goto runAdmin
@echo on
"%JAVA_HOME%¥bin¥java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="d:¥bea"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%¥server¥lib¥weblogic.policy"
-Dweblogic.security.fullyDelegateAuthorization=true
weblogic.Server
goto finish
:runAdmin
@echo on
"%JAVA_HOME%¥bin¥java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="d:¥bea"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%¥server¥lib¥weblogic.policy"
-Dweblogic.security.fullyDelegateAuthorization=true
weblogic.Server
:finish
ENDLOCAL
set JAVA_OPTIONS=... -Dweblogic.security.fullyDelegateAuthorization=true
この方法を使用すると、fullyDelegateAuthorization フラグを、インストールされているすべての WebLogic Server ドメインではなくドメインごとに設定できます。
リスト2-2 に、このフラグ (太字) を true に設定した startWebLogic ファイルの該当箇所を示します。
コード リスト 2-2 startWebLogic スクリプトのサンプル
@rem Set JAVA_OPTIONS to the java flags you want to pass to the vm. i.e.:
@rem set JAVA_OPTIONS=-Dweblogic.attribute=value -Djava.attribute=value
set JAVA_OPTIONS=-Dweblogic.security.SSL.trustedCAKeyStore=C:¥bea_sp02_7a¥
weblogic700¥server¥lib¥cacerts
-Dweblogic.security.fullyDelegateAuthorization=true
ノード マネージャを使用して管理対象サーバを起動する場合、上記の起動スクリプトは使用されません。 したがって、WebLogic Server Administration Console を使用して fullyDelegatedAuthorization フラグを設定する必要があります。
フラグを設定するには、サーバに対応する [コンフィグレーション｜リモート スタート] タブをクリックし、[引数] フィールドに次のように指定します。
-Dweblogic.security.fullyDelegatedAuthorization=true
図 2-1 に、このフラグを true に設定した examplesServer ファイルの Administration Console の該当フィールドを示します。
図2-1 examplesServer の [コンフィグレーション｜リモート スタート] タブ
[適用] ボタンをクリックし、サーバを再起動して変更を保存してください。
WebLogic Server 7.0 SP3 より前は、WebLogic Security サービスがセキュリティ チェックを実行する方法を指定するには、fullyDelegateAuthorization フラグの変更方法 で説明されているように、fullyDelegateAuthorzation コマンドライン引数を使用する必要がありました。 WebLogic Server 7.0 SP3 では、[ロールとポリシーのチェック対象] 設定が導入され、WebLogic Server Administration Console で同じ設定を指定できるようになりました。 [ロールとポリシーのチェック対象] ドロップダウン メニューは、[セキュリティ｜レルム] に続いて [myrealm] (または作成したセキュリティ レルムの名前) をクリックした後に表示される [一般] タブにあります。
注意: [ロールとポリシーのチェック対象] 設定は、それが設定されている WebLogic Server ドメイン内のすべての WebLogic Server インスタンス (サーバ) に影響します。
[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについて
fullyDelegateAuthorization フラグを true に設定して、WebLogic Security サービスによるセキュリティ チェックをすべての Web アプリケーションおよび EJB に対して実行する場合は、URL (Web) および EJB リソースを保護する方法も指定する必要があります (詳細についてはURL リソースおよび EJB リソースを保護する方法を参照)。方法を指定するには、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスを使用します。
注意: WebLogic Server 7.0 SP3 では、この設定は、WebLogic Server Administration Console の [デプロイメント記述子のセキュリティ動作] ドロップダウン メニューで行われるようになりました。 [デプロイメント記述子からセキュリティを取得] 値は、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスのチェックをはずすことと等しく、[デプロイメント記述子内のセキュリティ データを無視] 値は、[デプロイメント記述子内のセキュリティ データを無視] チェックボックスをチェックすることと同じです。
[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスは、以下のように設定する必要があります。
警告: [デプロイメント記述子内のセキュリティ データを無視] チェック ボックスの値の切り替えは危険であり、セキュリティ コンフィグレーションが不適切になったり失われたりする場合があります。 この設定を切り替える必要がある場合は (特に2 つの方法を組み合わせるで説明する状態の場合)、組み合わせた方法による URL および EJB リソースの保護の手順に注意深く従ってください。
[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスの設定変更
[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスの値を変更するには、次の手順に従います。
表 2-1 に、fullyDelegateAuthorization と [デプロイメント記述子内のセキュリティ データを無視] の設定値を組み合わせて WebLogic Security サービスの動作を指定する方法を示します。
|
Web アプリケーションまたは EJB モジュールのデプロイ時に、コンフィグレーション済みの認可プロバイダおよびロール マッピング プロバイダのデータベースにデプロイメント記述子のセキュリティ データをコピーするか、または再初期化してから、その他の方法を使用する。 注意: セキュリティ データは、Web アプリケーションまたは EJB モジュールをデプロイするたびにコピー/再初期化される。 |
|||
組み合わせた方法による URL および EJB リソースの保護
URL リソースおよび EJB リソースを保護する方法で説明されているように、WebLogic Server Administration Console による方法と J2EE/WebLogic デプロイメント記述子による方法を組み合わせて使用できます。これには通常 2 つの理由があります。
注意: 組み合わせた方法を他の目的で使用することはお勧めしません。 以下の節に進む前に、URL リソースおよび EJB リソースを保護するための前提条件に目を通してください。
以下の節では、組み合わせた方法を使用して URL および EJB リソースを保護する手順について説明します。
注意: これらのタスクを実行する前に、例 : basicauth Web アプリケーションのセキュリティ コンフィグレーションのコピーと再初期化,に目を通しておいてください。
この手順は、現在 J2EE および WebLogic デプロイメント記述子を使用して URL (Web) およびエンタープライズ JavaBean (EJB) リソースを保護しており、今後は WebLogic Server Administration Console だけを使用する予定の管理者を対象としています。セキュリティ コンフィグレーションをデプロイメント記述子と Administration Console の両方で管理することはお勧めしません。
警告: 組み合わせた方法を使用する場合、URL (Web) および EJB リソースのセキュリティ コンフィグレーションはオーバライドされる可能性があります。したがって、適切なセキュリティ コンフィグレーションが用意されていることを十分に確認する必要があります。 データの消失を防ぎ、URL および EJB リソースが適切に保護されるように、以下の手順には慎重に従ってください。
URL または EJB リソースのセキュリティ コンフィグレーションをコピーして、以後 WebLogic Server Administration Console で変更を行うようにするには、次の手順に従います。
注意: この設定の意味 : すべての URL (Web) および EJB リソースに対して WebLogic Security サービスによるセキュリティ チェックを実行するよう WebLogic Server に指示します。 詳細については、fullyDelegateAuthorization フラグについてを参照してください。
注意: この設定の意味 : リソースをデプロイするたびに、URL (Web) および EJB リソースのセキュリティをデプロイメント記述子からコンフィグレーション済みの認可プロバイダとロール マッピング プロバイダのデータベースにコピーするよう WebLogic Server に指示します。 詳細については、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについてを参照してください。
注意: Web アプリケーションをデプロイする手順については、『WebLogic Server アプリケーションの開発』の「Administration Console を使用した J2EE アプリケーションのデプロイ」を参照してください。
手順 2 : コピーしたセキュリティ ポリシーを検証する (省略可能)
コピーされたセキュリティ ポリシーを検証するには、表 2-2 で該当するカラムの手順に従ってください。
手順 3 : コピーしたセキュリティ ロールを検証する (省略可能)
コピーされたセキュリティ ロールを検証するには、表 2-3 で該当するカラムの手順に従ってください。
手順 4 : [デプロイメント記述子内のセキュリティ データを無視] の設定を元に戻す
警告: この手順は必須です。 この設定を元に戻さないと、Web アプリケーションおよび EJB モジュールを再デプロイした場合に、セキュリティ コンフィグレーションの整合性が失われる可能性があります。このため、サーバを再起動する前に必ずこの手順を実行してください。
注意: この設定の意味 : Administration Console を使用して、Web アプリケーションおよび EJB リソースのセキュリティを設定するように WebLogic Server に指示します。 詳細については、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについてを参照してください。
手順 5 : Administration Console を使用してセキュリティ ロールとセキュリティ ポリシーを変更する (省略可能)
グローバル ロールの変更とセキュリティ ポリシーの変更に示す手順に従って、URL (Web) リソースのセキュリティ ロールおよびセキュリティ ポリシーを変更します。
URL (Web) および EJB リソースのセキュリティ コンフィグレーションをデプロイメント記述子に指定されている元の状態に再初期化するには、次の手順に従います。
手順 1 : 事前設定を変更して WebLogic リソースを再デプロイする
注意: この設定の意味 : すべての URL (Web) および EJB リソースに対して WebLogic Security サービスによるセキュリティ チェックを実行するよう WebLogic Server に指示します。 詳細については、fullyDelegateAuthorization フラグについてを参照してください。
注意: この設定の意味 : リソースをデプロイするたびに、URL (Web) および EJB リソースのセキュリティをデプロイメント記述子からコンフィグレーション済みの認可プロバイダとロール マッピング プロバイダのデータベースにコピーするよう WebLogic Server に指示します。 詳細については、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについてを参照してください。
注意: Web アプリケーションおよび EJB をデプロイする手順については、『WebLogic Server アプリケーションの開発』の「デプロイメント ツールおよび手順」を参照してください。
手順 2 : 再初期化したセキュリティ ポリシーとセキュリティ ロールを検証する (省略可能)
再初期化されたセキュリティ ポリシーおよびセキュリティ ロールを検証するには、表 2-2 または 表 2-3 で該当するカラムの手順に従ってください。
手順 3 : [デプロイメント記述子内のセキュリティ データを無視] の設定を元に戻す
警告: この手順は必須です。 この設定を元に戻さないと、Web アプリケーションおよび EJB を再デプロイした場合に、セキュリティ コンフィグレーションの整合性が失われる可能性があります。このため、サーバを再起動する前に必ずこの手順を実行してください。
注意: この設定の意味 : Administration Console を使用して、Web アプリケーションおよび EJB リソースのセキュリティを設定するように WebLogic Server に指示します。 詳細については、[デプロイメント記述子内のセキュリティ データを無視] チェック ボックスについてを参照してください。
手順 4 : Administration Console を使用してセキュリティ ロールとセキュリティ ポリシーを変更する (省略可能)
グローバル ロールの変更とセキュリティ ポリシーの変更に示す手順に従って、URL (Web) または EJB リソースのセキュリティ ロールおよびセキュリティ ポリシーを変更します。
一般に、WebLogic Web サービスは、web-services.xml というデプロイメント記述子が追加された特別な Web アプリケーションを含むエンタープライズ アプリケーションとしてパッケージ化されます。 Web サービスが Java クラスを実装している場合、Web アプリケーションの WAR ファイルには Java クラス ファイルが含まれます。 Web サービスがステートレス セッション EJB を実装している場合、エンタープライズ アプリケーションの EAR ファイルには対応する EJB JAR ファイルが含まれます。
注意: Web サービスは、1 つの Java クラスだけを実装している場合、スタンドアロン Web アプリケーションの WAR ファイルとしてもパッケージ化できます。 ただし、Web サービスをこのようにパッケージ化することは一般的でなく、通常は、EAR ファイルとしてパッケージ化します。
Web サービス リソースは、Web サービスに関連する WebLogic リソースです。 Web サービスを保護するには、以下を対象としたセキュリティ ポリシーおよびセキュリティ ロールを作成します。
注意: WebLogic Web サービスの保護の詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
