WebLogic リソースのセキュリティ
|
 |
 |
|
この章では、WebLogic Server に含まれるリソースのタイプを説明します。
WebLogic リソースは階層化されています。このため、セキュリティ ロールとセキュリティ ポリシーは自由なレベルで定義できます。たとえば、エンタープライズ アプリケーション (EAR) 全体、複数の EJB を含むエンタープライズ JavaBean (EJB) JAR、その JAR 内の特定の EJB、その EJB 内の単一のメソッドなどに対してセキュリティ ロールとセキュリティ ポリシーを定義できます。
管理リソースは、ユーザによる管理タスクの実行を可能にする WebLogic リソースのタイプです。管理リソースの例としては、WebLogic Server Administration Console、weblogic.Admin ツール、MBean API などがあります。
管理リソースは制限されています。現在は、WebLogic Server Administration Console を使用した、管理リソースに対するユーザ ロックアウト操作のみが提供されています。この操作は WebLogic Server 6.x との互換性を提供し、セキュリティ要件を満たしたユーザによって、アカウントがロックアウトされているユーザのロック解除を行うことができます。ユーザ ロックアウトの詳細については、『WebLogic Security の管理』の「ユーザ アカウントの保護」を参照してください。
アプリケーション リソースは、EAR (エンタープライズ アプリケーション アーカイブ) ファイルとしてパッケージ化されるエンタープライズ アプリケーションを表す WebLogic リソースです。他のタイプの WebLogic リソースとは異なり、アプリケーション リソースの階層は、階層ではなく、格納のメカニズムです。エンタープライズ アプリケーションを構成する複数の WebLogic リソース (EJB リソース、URL リソース、および Web サービス リソースなど) を保護する場合に、アプリケーション リソースを保護します。つまり、エンタープライズ アプリケーションを保護することによって、そのアプリケーション内のすべての 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 プログラマーズ ガイド』の「アクセス制御のコンフィグレーション」を参照してください。
Java Database Connectivity (JDBC) リソースは、JDBC に関連する特定の WebLogic リソースのタイプです。JDBC データベースへのアクセスを保護するには、すべての接続プール (グループとして)、個々の接続プール、およびマルチプールに対してセキュリティ ロールとセキュリティ ポリシーを作成できます。個々の接続プールを保護する場合には、その接続プールに対するすべての操作を保護するか、または以下の操作のいずれか 1 つを保護するかを選択できます。
admin - JDBCConnectionPoolRuntimeMBean の clearStatementCache、destroy、disableDroppingUsers、disableFreezingUsers、enable、forceDestroy、forceShutdown、forceSuspend、getProperties、poolExists、resume、shutdown、shutdownHard、shutdownSoft、および suspend の各メソッドが管理操作として呼び出されます。reserve - アプリケーションは、接続プールを指すデータ ソースをルックアップし、getConnection を呼び出すことによって、接続プール内の接続を予約します。注意 :reserve パーミッションを与えるとユーザは接続に対してベンダ固有の操作を実行できるようになります。データベース ベンダによっては、こうした操作の一部がデータベースのセキュリティに影響する場合があります。
shrink - 現在予約されている接続の最大数または初期サイズに接続プールを縮小します。reset - すべての物理的なデータベース接続を停止し、再確立することで、データベース接続プールをリセットします。これにより、接続プール内にある各接続の statement キャッシュもクリアされます。リセットは、正常に実行されている接続プールに対してのみ実行できます。注意 :セキュリティ ポリシーを使用して、マルチプール内の接続プールへのアクセスを制御している場合は、アクセス チェックが JDBC リソース階層の両方のレベルで行われます (まずマルチプール レベルで行われ、次に個々の接続プール レベルで行われます)。すべてのタイプの WebLogic リソースと同じように、こうした二重チェックを行うことで、セキュリティ ポリシーによる最も厳しいアクセス制御を確実に行うことができます。
注意 :Oracle ユーザの場合、Oracle 仮想プライベート データベース (Oracle Virtual Private Database : VPD) を使用して JDBC リソースへのアクセスも制御できます。詳細については、「WebLogic Server でのサードパーティ ドライバの使い方」の「Oracle 仮想プライベート データベースによるプログラミング」を参照してください。
Java Message Service (JMS) リソースは、JMS に関連する特定の WebLogic リソースのタイプです。JMS 送り先を保護するには、グループとしてすべての送り先 (JMS キューおよび JMS トピック) に対して、または JMS サーバ上の個々の送り先 (JMS キューおよび JMS トピック) に対してセキュリティ ロールとセキュリティ ポリシーを作成します。JMS サーバ上の特定の送り先を保護する場合は、その送り先のすべての操作を保護するか、以下の操作の 1 つを保護できます。
send - キューまたはトピックにメッセージを送信するために必要です。メッセージング ブリッジだけでなく、MessageProducer.send()、QueueSender.send()、および TopicPublisher.publish() の各メソッドの呼び出しも含まれています。receive - キューまたはトピックでコンシューマを作成するために必要です。メッセージング ブリッジおよびメッセージ駆動型 Bean に加えて、Session.createConsumer()、Session.createDurableSubscriber()、QueueSession.createReceiver()、TopicSession.createSubscriber()、TopicSession.createDurableSubscriber()、Connection.createConnectionConsumer()、Connection.createDurableConnectionConsumer()、QueueConnection.createConnectionConsumer()、TopicConnection.createConnectionConsumer()、および TopicConnection.createDurableConnectionConsumer() の各メソッドの呼び出しも含まれています。browse - QueueBrowser インタフェースを使用してキューのメッセージを表示するために必要です。
JNDI は、Lightweight Directory Access Protocol (LDAP) や Domain Name System (DNS) など、既存のさまざまなネーミング サービスに対する共通インタフェースを提供します。これらのネーミング サービスは、バインディングのセットを管理します。名前はバインディングによってオブジェクトに関連付けられるので、オブジェクトを名前でルックアップできるようになります。したがって、JNDI を使用すると、分散アプリケーションのコンポーネントが互いを検索できます。
JNDI は、特定のネーミング サービスまたはディレクトリ サービスの実装とは無関係です。JNDI では、複数の方法で、さまざまな新しいサービスや既存のサービスにアクセスできます。このサポートでは、標準サービス プロバイダ インタフェース (SPI) 規約を使用して JNDI フレームワークに任意のサービス プロバイダ実装をプラグインできます。
Java Naming and Directory Interface (JNDI) リソースは、業界標準の JNDI SPI を使用して、異種のエンタープライズ ネーミング サービスおよびディレクトリ サービスを接続できるようにする特定の WebLogic リソースのタイプです。JNDI ツリーへのアクセスを保護するには、JNDI ツリー全体に対して、またはそのツリーの個々のブランチに対してセキュリティ ロールとセキュリティ ポリシーを作成します。すべての操作を保護するか、以下の操作の 1 つを保護することができます。
modify - アプリケーションで JNDI ツリーを何らかの方法で修正 (つまり追加、削除、変更) するときには、現在のユーザに必ず修正のパーミッションが必要です。bind()、rebind()、createSubContext()、destroySubContext()、および unbind() の各メソッドが含まれています。lookup - アプリケーションで JNDI ツリーのオブジェクトをルックアップするときには、現在のユーザにルックアップのパーミッションが必要です。lookup() メソッドおよび lookupLink() メソッドが含まれています。 list - アプリケーションで JNDI のコンテキストの内容をリストするときには、現在のユーザにリストを実行するパーミッションが必要です。list() メソッドおよび listBindings() メソッドが含まれています。
多くのエンジニアリング チームでは、システム管理の責任が複数のロールに明確に割り当てられています。アプリケーションまたはモジュールをデプロイするパーミッションは 1 人か 2 人のチーム メンバーにしか付与しないが、サーバ コンフィグレーションを参照するパーミッションはチーム メンバー全員に付与する、というような設定がプロジェクトごとに行われます。「セキュリティ ポリシー」で説明するように、WebLogic Server では、管理者がセキュリティ ポリシーで WebLogic リソースを保護できるようにすることでこの責任の割り当てがサポートされます。通常、それらのセキュリティ ポリシーは、ユーザまたはユーザのグループに特定のセキュリティ ロールが付与されるかどうかということに基づきます。
サーバ リソースは、WebLogic Server サーバ インスタンスの実行状態を管理するアクティビティを保護するために使用される特殊なタイプの WebLogic リソースです。サーバ リソースを保護するには、グループとしてのすべての WebLogic Server インスタンス (サーバ) または個別のサーバでセキュリティ ポリシーおよびセキュリティ ロールを作成します。特定のサーバを保護する場合は、そのサーバのすべての操作を保護するか、以下の操作の 1 つを保護できます。
boot - WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) を起動しようとするユーザには、そのためのパーミッションが必要です。このアクションは通常、コマンドラインでの java weblogic.Server コマンドの呼び出し、コンフィグレーションされている起動スクリプト (java weblogic.Server コマンドを呼び出す)、または WebLogic Server インスタンスのリモート起動を可能にするノード マネージャの機能を通じて開始されます。weblogic.Admin SHUTDOWN または FORCESHUTDOWN コマンドを通じて開始されます。lock - 動作している WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) への追加のログイン (特権のある管理アクションを目的とした以外のログイン) を禁止しようとするユーザには、そのためのパーミッションが必要です。このアクションは通常、Administration Console または weblogic.Admin LOCK コマンドを通じて開始されます。unlock - 動作している WebLogic Server インスタンス (管理サーバまたは管理対象サーバ) への特権のないログインを有効にし直そうとするユーザには、そのためのパーミッションが必要です。このアクションは通常、Administration Console または weblogic.Admin UNLOCK コマンドを通じて開始されます。 他のタイプの WebLogic リソースと同じように、サーバ リソースとその操作はセキュリティ ポリシーで保護されます。ただし、サーバのコンフィグレーションは MBean のセットを通じてエクスポーズされるので、サーバ リソースでは、管理者が MBean にアクセスする方法に影響する補足的な保護も利用します。
以下の節では、サーバ リソースの階層化されたセキュリティ方式について詳しく説明します。
他のタイプの WebLogic リソースと同じように、サーバ リソースは、WebLogic Server Administration Console を使用してセキュリティ ポリシーで保護されます。
具体的にいうと、サーバ リソースはすべて、Admin と Operator の各デフォルト グローバル セキュリティ ロールの両方に基づくデフォルト セキュリティ ポリシーを継承します。「デフォルト グローバル ロール」で説明するように、Admin と Operator の各グローバル ロールには、管理者が Administration Console や weblogic.Admin コマンドなどの管理インタフェースと対話するときに必要な特定の特権が付与されています。これらのデフォルト グローバル ロールは、デフォルトのグループに基づいています (「デフォルト グループの関連付け」を参照)。そのため、サーバ リソースにアクセスする必要のある管理者は、デフォルト グループ Administrators または Operators のいずれかのメンバーでなければなりません。
注意 :WebLogic Server では 4 つのデフォルト グローバル ロールが 4 つのデフォルト グループに付与されているので、これらのグループのいずれかにユーザを追加すると、そのユーザにはグローバル ロールが自動的に付与されます。
警告 :サーバ リソースのデフォルト セキュリティ ポリシーを変更して、それらの制約をさらに厳しくしないでください。既存のセキュリティ ロールの一部を削除すると、WebLogic Server の動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト セキュリティ ポリシーにより多くを含めることはできます (たとえば、新しいセキュリティ ロールを追加するなど)。
各タイプの WebLogic リソース (サーバ リソースを含む) では、weblogic.security.spi.Resource インタフェース (サーバ リソースでは weblogic.security.service.ServerResource クラス) の独自の実装を通じてその操作がエクスポーズされます。そのため、ServerResource クラスは、「サーバ リソースのセキュリティ ポリシー」で説明されているセキュリティ ポリシーによって実際に保護されているエンティティです。
WebLogic Server では、サーバ リソースのコンフィグレーションは MBean のセットを通じてエクスポーズされます。したがって、ServerResource クラスが保護するアクションは基底 MBean の属性および操作に対応しています。たとえば、Resource インタフェースの start() メソッドは、ServerRuntime MBean の start 操作に直接マップされます。
サーバ リソースのコンフィグレーションをエクスポーズする MBean は、4 つのデフォルト グローバル ロールのいずれか 1 つを使用して保護されます。このような保護は、そのサーバ リソースのセキュリティ ポリシーとは別のものであり、WebLogic Security サービスによって提供されるコンフィグレーションできない保護です。そのため、サーバ リソースを保護するための独自のグローバル ロールを作成できるだけでなく、いずれかのデフォルト グローバル ロールが付与されているユーザのみがサーバのコンフィグレーションを表示または変更できます。
管理者がサーバ リソースと対話しようとすると、WebLogic Security サービスによって、以下のことが行われます。
つまり、リクエストを成功させるためには、ユーザはこれらの両方のセキュリティ方式に合格する必要があります。図 2-1 に、サーバ リソースのセキュリティ ポリシーが基底の MBean のセキュリティ ロールベースの保護と相互に作用するしくみを示します。
MBean の保護によって付与される特権は不変なので、一貫性を確保するようにセキュリティ ポリシーを維持する必要があります (詳細については、「一貫性のあるセキュリティ方式の維持」を参照)。
この例では、あるサーバ リソースが、階層化されたセキュリティ方式によってどのように保護されるかを示します。
ユーザ名 JDoe の管理者が myserver というサーバを起動しようとしています。この管理ユーザ (JDoe) は、デフォルトで Admin グローバル セキュリティ ロールが付与されている、デフォルト グループ Administrators のメンバーです。ユーザ対グループとグループ対セキュリティ ロールのコンフィグレーションは、このガイドの別の節で説明しているように WebLogic Server Administration Console を使用して設定します。
サーバを起動するにはさまざまな MBean との対話が必要であり、また MBean の保護は WebLogic Security サービスによって提供されるコンフィグレーションできない保護なので、そうした操作を実行するユーザには、Admin デフォルト グローバル ロールまたは Operator デフォルト グローバル ロールが付与されている必要があります。たとえば、表 4-5 には、Server MBean および ServerRuntime MBean (start 操作を持つ MBean) へのアクセスはこれらのデフォルト セキュリティ ロールのユーザのみに付与されている特権であることが示されています。管理ユーザ (JDoe) はデフォルト グループ Administrators のメンバーなので、Admin グローバル セキュリティ ロールも付与されており、その結果、サーバ リソースに対する二重セキュリティ方式の最初のパート要件を満たします。
図 2-2 のポリシー エディタ ページに示されているように、 myserver のデフォルト セキュリティ ポリシー (ナビゲーション ツリーで myserver を右クリックすると表示される [セキュリティ ポリシーを定義...] オプションを選択すると表示される) では、Admin グローバル ロールまたは Operator グローバル ロールが付与されているユーザがサーバ リソースと対話できます。管理ユーザ (JDoe) はデフォルト グループ Administrators のメンバーなので、Admin グローバル セキュリティ ロールも付与されており、その結果、サーバ リソースに対する階層化されたセキュリティ方式の 2 番目のパート要件を満たします。
図 2-2 myserver サーバのデフォルト セキュリティ ポリシー
注意 : 管理ユーザ (JDoe) が Operators グループのメンバーであった場合でも、Operator デフォルト グローバル ロールが付与されているので、二重セキュリティ方式の両方のパート要件を満たすことになります。
図 2-2、myserver サーバのデフォルト セキュリティ ポリシーに示されているページの詳細については、「セキュリティ ポリシーの構成要素 : ポリシー条件、式、およびポリシー文」を参照してください。
グループ、グローバル ロール、サーバ リソースのセキュリティ ポリシー、および MBean の保護は、WebLogic Server のデフォルトのコンフィグレーションでは、相互に連携して一貫性のあるセキュリティ方式を確立しています。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定を変更する場合は、MBean の保護およびサーバ リソースのセキュリティ ポリシーの両方によるユーザの認証を妨げないよう注意してください。
たとえば、WebLogic Server Administration Console を使用して、あるユーザを Operator グローバル ロールに追加したのに、サーバ リソースに定義されているセキュリティ ポリシーで Operator グローバル ロールを使用できない場合、そのユーザは起動および停止シーケンスで使用する MBean 操作を呼び出すことはできますが、サーバを起動または停止するためのサーバ リソースの操作は使用できません。同様に、Administration Console を使用して、サーバ リソースのセキュリティ ポリシーから Operator グローバル ロールを削除した場合、Operator グローバル ロールを付与されたユーザは MBean の操作を呼び出すことはできますが、サーバ リソースを呼び出すことはできません。デフォルト グローバル ロールによる MBean の保護は WebLogic Security サービスの一部であり、現在はコンフィグレーションできないため、このような結果になります。
MBean の保護とセキュリティ ポリシーを同期させるには、セキュリティ ポリシーの作成時または変更時に以下のアクションを行うことを考慮してください。
Admin グローバル ロールのアクセス権をサーバ リソースに付与する。Operator グローバル ロールを使用する。 Operator グローバル ロール、またはこのデフォルト グローバル ロール内にネストされたセキュリティ ロールが使用できない場合、WebLogic Security サービスで問題が発生する場合があります。
Deployer グローバル ロールを使用する。セキュリティ ポリシーの詳細については、「セキュリティ ポリシーの操作」を参照してください。
WebLogic Server インスタンス (サーバ) を起動および停止するには、weblogic.Server コマンドを使用する方法とノード マネージャを使用する方法があります。weblogic.Server コマンドとノード マネージャでは基底のコンポーネントが異なるため、これら 2 つのコマンドでは異なる認可方法が使用されます。
以下の節では、サーバを起動および停止するパーミッションについて詳しく説明します。
weblogic.Server コマンド (管理サーバと管理対象サーバの両方の起動に使用可能) では、サーバ リソースのセキュリティ ポリシーで保護されたメソッドが呼び出されます。このコマンドを使用するには、サーバ リソースのセキュリティ ポリシーの要件を満たす必要があります。
weblogic.Server の引数の中には MBean の属性を設定するものもあります。ただし、これらの引数ではサーバが実行中の状態 (RUNNING) になる前に MBean を変更するので、MBean の保護ではなく、サーバ リソースのセキュリティ ポリシーによって認可されます。たとえば、Operator グローバル ロールに属するユーザは -Dweblogic.ListenPort 引数を使用してサーバのデフォルトのリスン ポートを変更できますが、WebLogic Server インスタンスが実行中の状態になると、このユーザはリスン ポートの値を変更できません。
weblogic.Server の詳細については、『WebLogic Server コマンド リファレンス』の「weblogic.Server コマンドライン リファレンス」を参照してください。
ノード マネージャを使用すると、MBean とサーバ リソースのセキュリティ ポリシーの両方を使用してリモート サーバを起動できます。
リモート WebLogic Server インスタンスのホスト マシン上にノード マネージャがコンフィグレーションされている場合、デフォルトで Admin グローバル ロールまたは Operator グローバル ロールに属するユーザはノード マネージャを使用してリモート サーバを起動できます。
ノード マネージャの詳細については、『WebLogic Server のコンフィグレーションと管理』の「ノード マネージャのコンフィグレーション、起動、および停止」を参照してください。
WebLogic Server インスタンスの停止においても MBean とサーバ リソースのセキュリティ ポリシーの両方が関与します。ユーザが停止コマンドを発行すると、サーバではまず、MBean の保護によってそのユーザに Admin または Operator グローバル ロールが付与されているかどうかが確認されます。続いて、MBean 操作の実行後、サーバ リソースのセキュリティ ポリシーによって、そのユーザがサーバを停止する権限を持っているかどうかを判別します。
WebLogic Server インスタンス停止の詳細については、『WebLogic Server のコンフィグレーションと管理』の「サーバの起動と停止 : クイック リファレンス」を参照してください。
URL (Web) リソースは、Web アプリケーションに関連する特定の WebLogic リソースのタイプです。Web アプリケーションを保護するには、WAR (Web アプリケーション アーカイブ) ファイルに対して、またはサーブレットや JSP などの Web アプリケーションの個々のコンポーネントに対してセキュリティ ロールとセキュリティ ポリシーを作成します。EJB (エンタープライズ JavaBean) リソースは、EJB に関連する特定の WebLogic リソースのタイプです。EJB を保護するには、EJB JAR、EJB JAR 内の個々の EJB、または EJB 上の個々のメソッドに対してセキュリティ ロールとセキュリティ ポリシーを作成します。
Java 2 Enterprise Edition (J2EE) プラットフォームはデプロイメント記述子で Web アプリケーションおよび EJB のセキュリティを標準化しているので、WebLogic Server はこの標準メカニズムを WebLogic Security サービスに統合して、URL リソースおよび EJB リソースを保護する方法を選択できるようにしています。どの方法を選択するかによって、リソースを保護するための手順が変わり、WebLogic Server Administration Console で必要な前提となる設定が異なります。詳細については、それぞれ「URL リソースおよび EJB リソースを保護する方法」および「URL リソースおよび EJB リソースを保護するための前提条件」を参照してください。
注意 :このガイドで説明されている EJB リソースに対する手順は、メッセージ駆動型 Bean (MDB) にも適用できます。
以下の節では、URL (Web) リソースおよび EJB (エンタープライズ JavaBean) リソースを保護する異なった方法について詳しく説明します。
Administration Console を使用して URL リソースおよび EJB リソースを保護する方法の主な利点は、セキュリティ管理が統合されていることです。組織的なセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル ユーザ インタフェースから、すべてのセキュリティ コンフィグレーションを変更できます。ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーは、すべて Administration Console を使用して定義できます。結果として、更新されたセキュリティ要件に基づく変更のプロセスが効率的になります。
すべてのタイプの WebLogic リソースをこの方法で保護できます。このため、このガイドで説明する WebLogic リソースの保護手順は、特に Administration Console のユーザに向けて書かれています。
J2EE デプロイメント記述子と WebLogic デプロイメント記述子を使用して URL リソースおよび EJB リソースを保護する方法の主な利点は、Web アプリケーションと EJB に宣言的なセキュリティを追加するための一般的かつ標準的な方法であることです。多くの企業にとって一般的な方法でもあります。この手法を使用する場合、セキュリティ ロールとセキュリティ ポリシーは web.xml、weblogic.xml、ejb-jar.xml、weblogic-ejb-jar.xml デプロイメント記述子に指定されます。
注意 :WebLogic Server 7.0 サービスパック 2 では、<externally-defined> という特別なタグが導入されました。このタグを使用すると、セキュリティ ロール マッピングをデプロイメント記述子または Administration Console のどちらで定義するかをロールごとに指定できます。このタグは、非推奨となった <global-role> タグに代わるものです。URL リソースまたは EJB リソースでこのタグを使用する方法の詳細については、『WebLogic Security プログラマーズ ガイド』の「externally-defined」 (weblogic.xml デプロイメント記述子) または「externally-defined」 (weblogic-ejb-jar.xml デプロイメント記述子) をそれぞれ参照してください。
デプロイメント記述子を使用する方法では、URL リソースおよび EJB リソースのみを保護できます。デプロイメント記述子の使い方については、『WebLogic Security プログラマーズ ガイド』の「Web アプリケーションでの宣言によるセキュリティの使用」および「EJB での宣言によるセキュリティの使用」の節をそれぞれ参照してください。
現在デプロイメント記述子を使用して URL リソースと EJB リソースを保護している企業では、WebLogic Server Administration Console の統合されたセキュリティ管理機能を利用することもできます。このような場合、Web アプリケーション モジュールまたは EJB モジュールの初回のデプロイ時に、既存のデプロイメント記述子からセキュリティ コンフィグレーションをコピーするように Administration Console に指示することができます。セキュリティ コンフィグレーションをロール マッピング プロバイダと認可プロバイダのデータベースにコピーしたら、以降のセキュリティ ロールとセキュリティ ポリシーに対する更新は Administration Console を使用して行う必要があります。また、この組み合わせた方法を使用して、URL リソースおよび EJB リソースのセキュリティ コンフィグレーションを、デプロイメント記述子で指定されている状態に再初期化することもできます。
警告 :組み合わせた方法を使用する場合、URL リソースおよび EJB リソースのセキュリティ コンフィグレーションがオーバーライドされる可能性があります。したがって、組み合わせた方法を使用する場合は、Web アプリケーションおよび EJB の適切なセキュリティ コンフィグレーションが設定されていることを確認する必要があります。詳細については、「URL リソースおよび EJB リソースを保護するための前提条件」を参照してください。
組み合わせた方法の詳細については、「チュートリアル 19 : セキュリティ コンフィグレーションのコピーと再初期化」を参照してください。
WebLogic Server Administration Console またはデプロイメント記述子のどちらを使用して URL リソースおよび EJB リソースを保護する場合でも、WebLogic Server の重要な 2 つの設定 ([ロールとポリシーのチェック対象] と [今後の再デプロイの設定]) について理解しておく必要があります。これらの設定を理解していないと、セキュリティ コンフィグレーションが不適切なものになったり、失われたりすることがあります。
URL リソースおよび EJB リソースの保護に進む前に、以下の節に目を通してください。
パフォーマンスを制御するために、WebLogic Server Administration Console では WebLogic Security サービスがセキュリティ チェックを実行する方法を指定する必要があります。この指定には、図 2-3 で示されている [ロールとポリシーのチェック対象] ドロップダウン メニューを使用します。
図 2-3 Administration Console : [セキュリティ｜レルム｜myrealm｜全般]
[ロールとポリシーのチェック対象] 設定が [デプロイメント記述子で保護された Web アプリケーションと EJB] の場合、WebLogic Security サービスは、関連付けられているデプロイメント記述子でセキュリティが指定されている URL (Web) リソースおよび EJB リソースに対してのみセキュリティ チェックを実行します。これは [ロールとポリシーのチェック対象] 設定のデフォルトです。
[ロールとポリシーのチェック対象] 設定が [すべての Web アプリケーションと EJB] の場合、WebLogic Security サービスは、すべての URL (Web) リソースおよび EJB リソースに対して、そのデプロイメント記述子にセキュリティ設定があるかどうかに関係なく、セキュリティ チェックを実行します。[ロールとポリシーのチェック対象] ドロップダウン メニューの値を [すべての Web アプリケーションと EJB] に変更した場合は、Web アプリケーション モジュールまたは EJB モジュールが再デプロイされたときに WebLogic Security サービスが実行する処理を指定する必要があります。詳細については、「WebLogic リソースを再デプロイするときの処理」を参照してください。
注意 :[ロールとポリシーのチェック対象] 設定は、それが設定されている WebLogic Server ドメインのすべての WebLogic Server インスタンス (サーバ) に対して有効です。
fullyDelegateAuthorization フラグ (WebLogic Server の起動時に設定するコマンドライン引数) を使用すると、URL (Web) リソースおよび EJB リソースでのセキュリティ チェックの実行方法を指定することもできます。fullyDelegateAuthorization フラグの値を false に設定すると、WebLogic Security サービスは、関連するデプロイメント記述子でセキュリティが指定されている URL リソースと EJB リソースに対してのみ、セキュリティ チェックを実行します。
fullyDelegateAuthorization フラグは以下の 3 つの方法のいずれかで設定できます。
-Dweblogic.security.fullyDelegateAuthorization = boolean_value
boolean_value は true または false であり、WebLogic Server インスタンスを起動するたびにコマンドラインで入力します。
注意 :管理サーバと管理対象サーバの両方で fullyDelegateAuthorization フラグが同じように設定されているようにしてください。
![Administration Console : [セキュリティ｜レルム｜myrealm｜全般]](wwimages/flag.gif "Administration Console : [セキュリティ｜レルム｜myrealm｜全般]")
startWLS スクリプト (WL_HOME\server\bin ディレクトリにある) を編集します。 -Dweblogic.security.fullyDelegateAuthorization = boolean_value
boolean_value は true または false です。WebLogic Server インスタンスを起動するたびにフラグを設定する必要がなくなるため、こちらの方が効率的です。しかし、この設定はインストール先のすべての WebLogic Server ドメインに適用されることに注意してください。
JAVA_OPTIONS セクションに次を含むように、startWebLogic スクリプト (WL_HOME\user_projects\domains\mydomain ディレクトリにある。mydomain は作成した WebLogic Server ドメインの名前) を編集します。 注意 :ノード マネージャを使用して管理対象サーバを起動する場合は、上記の起動スクリプトは使用されません。そのため、WebLogic Server Administration Console を使用して fullyDelegateAuthorization フラグを設定する必要があります。
[ロールとポリシーのチェック対象] ドロップダウン メニューで、WebLogic Security サービスによるセキュリティ チェックの方法を [すべての Web アプリケーションと EJB] に設定した場合は、URL (Web) リソースおよび EJB リソースを保護する方法も指定する必要があります (詳細については、「URL リソースおよび EJB リソースを保護する方法」を参照)。この指定には、図 2-3 で示されている [今後の再デプロイの設定] ドロップダウン メニューを使用します。
[今後の再デプロイの設定] ドロップダウン メニューの値は、以下のとおり設定します。
web.xml、weblogic.xml、ejb-jar.xml、および weblogic-ejb-jar.xml ファイル) のみを使用して URL (Web) リソースおよび EJB リソースを保護するには、[デプロイメント記述子のロールとポリシーを初期化] を選択し、『WebLogic Security プログラマーズ ガイド』の「Web アプリケーションでの宣言によるセキュリティの使用」および「EJB での宣言によるセキュリティの使用」の節をそれぞれ参照してください。警告 :[今後の再デプロイの設定] の設定の切り替えは危険であり、セキュリティ コンフィグレーションが不適切になったり失われたりするおそれがあります。この設定を切り替える必要がある場合 (特に「Administration Console とデプロイメント記述子を使用する」で説明する状況の場合) は、「組み合わせた方法による URL リソースと EJB リソースの保護」の手順に慎重に従ってください。
[ロールとポリシーのチェック対象] と [今後の再デプロイの設定] の設定を変更するには、次の手順に従います。
表 2-1 に、[ロールとポリシーのチェック対象] と [今後の再デプロイの設定] の設定値を組み合わせて WebLogic Security サービスの動作を指定する方法を示します。
「URL リソースおよび EJB リソースを保護する方法」で説明したように、WebLogic Server Administration Console による方法と J2EE/WebLogic デプロイメント記述子による方法を組み合わせて使用できます。これには通常 2 つの理由があります。
組み合わせた方法を他の目的で使用することはお勧めしません。以下の節に進む前に、「URL リソースおよび EJB リソースを保護するための前提条件」に目を通してください。
以下の節では、組み合わせた方法を使用して URL リソースおよび EJB リソースを保護する手順について説明します。
これらのタスクを実行する前に、「チュートリアル 19 : セキュリティ コンフィグレーションのコピーと再初期化」にも目を通しておいてください。
この手順は、現在 J2EE および WebLogic デプロイメント記述子を使用して URL (Web) および EJB (エンタープライズ JavaBean) リソースを保護しており、今後は WebLogic Server Administration Console だけを使用する予定の管理者を対象としています。セキュリティ コンフィグレーションをデプロイメント記述子と Administration Console の両方で管理することはお勧めしません。
警告 :組み合わせた方法を使用する場合、URL リソースおよび EJB リソースのセキュリティ コンフィグレーションがオーバーライドされる可能性があります。したがって、適切なセキュリティ コンフィグレーションが設定されていることを確認する必要があります。データの消失を防ぎ、URL リソースおよび EJB リソースが適切に保護されるように、以下の手順には慎重に従ってください。
URL リソースまたは EJB リソースのセキュリティ コンフィグレーションをコピーして、以後 WebLogic Server Administration Console で変更を行うようにするには、次の手順に従います。
すべての URL (Web) リソースおよび EJB リソースに対して WebLogic Security サービスによるセキュリティ チェックを実行するように WebLogic Server に指示します。「セキュリティ ロールとセキュリティ ポリシーをチェックする方法」を参照してください。
注意 : [ロールとポリシーのチェック対象] ドロップダウン メニューの値として [すべての Web アプリケーションと EJB] がすでに選択されている場合は、手順 4 に進みます。
リソースをデプロイするたびに、URL (Web) リソースおよび EJB リソースのセキュリティをデプロイメント記述子からコンフィグレーション済みの認可プロバイダとロール マッピング プロバイダのデータベースにコピーするよう WebLogic Server に指示します。「WebLogic リソースを再デプロイするときの処理」を参照してください。
注意 :手順 3 で [ロールとポリシーのチェック対象] ドロップダウン メニューの値を変更する必要がなかった場合は、サーバを再起動せずに手順 7 に進みます。
Web アプリケーション モジュールおよび EJB モジュールをデプロイする手順については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
コピーしたセキュリティ ポリシーを検証するには、表 2-2 の適切なカラムに示された手順に従います。
コピーしたセキュリティ ポリシーを検証するには、表 2-3 の適切なカラムに示された手順に従います。
警告 :この手順は確実に完了する必要があります。この設定を元に戻さないと、Web アプリケーション モジュールおよび EJB モジュールの再デプロイ時に、セキュリティ コンフィグレーションに一貫性がなくなるおそれがあります。このため、サーバを再起動する前に、必ずこの手順を実行してください。この手順を実行しない場合または実行が不完全の場合は、ポリシー エディタ ページの次回ロード時に、次のメッセージが表示されます。
以下の情報は正しくない可能性があります。正確な情報が表示されていることを確認するには、WebLogic リソースを削除して再デプロイする必要があります。
Administration Console を使用して URL (Web) リソースおよび EJB リソースのセキュリティを設定することを WebLogic Server に指定します。「WebLogic リソースを再デプロイするときの処理」を参照してください。
「グローバル ロールの変更」と「セキュリティ ポリシーの操作」に示す手順に従って、URL リソースまたは EJB リソースのセキュリティ ロールとセキュリティ ポリシーを変更します。
URL (Web) リソースおよび EJB (エンタープライズ JavaBean) リソースのセキュリティ コンフィグレーションをデプロイメント記述子に指定されている元の状態に再初期化するには、次の手順に従います。
すべての URL (Web) リソースおよび EJB リソースに対して WebLogic Security サービスによるセキュリティ チェックを実行するように WebLogic Server に指示します。「セキュリティ ロールとセキュリティ ポリシーをチェックする方法」を参照してください。
リソースをデプロイするたびに、URL (Web) リソースおよび EJB リソースのセキュリティをデプロイメント記述子からコンフィグレーション済みの認可プロバイダとロール マッピング プロバイダのデータベースにコピーするよう WebLogic Server に指示します。「WebLogic リソースを再デプロイするときの処理」を参照してください。
Web アプリケーション モジュールおよび EJB モジュールをデプロイする手順については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
再初期化したセキュリティ ポリシーとセキュリティ ロールを検証するには、表 2-2 および表 2-3 のそれぞれの適切なカラムに示された手順に従います。
警告 :この手順は確実に完了する必要があります。この設定を元に戻さないと、Web アプリケーション モジュールおよび EJB モジュールの再デプロイ時に、セキュリティ コンフィグレーションに一貫性がなくなるおそれがあります。このため、サーバを再起動する前に、必ずこの手順を実行してください。この手順を実行しない場合または実行が不完全の場合は、ポリシー エディタ ページの次回ロード時に、次のメッセージが表示されます。
以下の情報は正しくない可能性があります。正確な情報が表示されていることを確認するには、WebLogic リソースを削除して再デプロイする必要があります。
Administration Console を使用して URL (Web) リソースおよび EJB リソースのセキュリティを設定することを WebLogic Server に指定します。「セキュリティ ロールとセキュリティ ポリシーをチェックする方法」を参照してください。
「グローバル ロールの変更」と「セキュリティ ポリシーの操作」に示す手順に従って、URL (Web) リソースまたは EJB リソースのセキュリティ ロールとセキュリティ ポリシーを変更します。
WebLogic Web サービスは、通常、web-services.xml という追加のデプロイメント記述子を含む、特殊なタイプの Web アプリケーションを格納しているエンタープライズ アプリケーションとしてパッケージ化されています。Web サービスが Java クラスを使用して実装されている場合、Web アプリケーション WAR ファイルには Java クラス ファイルが格納されます。Web サービスがステートレス セッション EJB を使用して実装されている場合、エンタープライズ アプリケーション EAR ファイルには対応する EJB JAR ファイルが格納されます。
注意 :Web サービスが Java クラスのみを使用して実装されている場合、Web サービスはスタンドアロンの Web アプリケーション WAR ファイルとしてもパッケージ化できます。ただし、Web サービスのこのタイプのパッケージ化はまれです。通常 Web サービスは EAR ファイルとしてパッケージ化されます。
Web サービス リソースは、Web サービスに関連する特定の WebLogic リソースのタイプです。Web サービスを保護するには、以下のものに対してセキュリティ ロールとセキュリティ ポリシーを作成します。
WebLogic Web サービスの詳細については、『WebLogic Web サービス プログラマーズ ガイド』を参照してください。
|
|
|