| Oracle® Fusion Middleware Oracle Enterprise Scheduler開発者ガイド 11g リリース1 (11.1.1.6.2) B66615-02 |
|
 前 |
この章では、リソースに対するアクセス制御およびジョブ実行に対するアプリケーション・アイデンティティ伝播を提供する、Oracle Enterprise Schedulerセキュリティのセキュリティ機能について説明します。
Oracle Enterprise Schedulerセキュリティには、次のことが含まれています。
MetadataServiceに対する保護された操作。MetadataPermissionによって保護され、これにより、メタデータのアクセス制御が行われます。メタデータ・オブジェクトに対するアクセス制御。権限を持つユーザーのみが、ジョブの作成、削除および更新と、メタデータのスケジュールを行うことができます。詳細は、第18.1.1項「Oracle Enterprise Schedulerのメタデータ・アクセス制御」を参照してください。
アプリケーション・アイデンティティの使用のサポート。アプリケーション・アイデンティティを使用すると、発行元ユーザーに割り当てられている権限よりも高い権限を必要とするジョブを完了するために、権限を昇格できます。詳細は、第18.1.2項「Oracle Enterprise Schedulerのジョブ実行のセキュリティ」を参照してください。
設計時に、メタデータ作成者は、どのジョブ機能がどのメタデータ・オブジェクトにアクセスできるかを決定する必要があります。これは、各メタデータ・オブジェクトを1つ以上のロールに関連付けて、各ロールに1つ以上のアクションを指定することによって表します。図18-1に、メタデータのセキュリティのサマリーを示します。
ジョブの発行中、ジョブ・リクエストを発行する権限を持つユーザーは、発行元ユーザーと呼ばれます。リクエストの実行時、すべてのユーザーのJavaコード(前処理、後処理、Javaジョブ、置換など)は、すべてのロールと資格証明が保持された状態で、発行元ユーザーとして実行されます。
ただし、ジョブ・メタデータにSYS_RUNAS_APPLICAITONIDを指定すると、ジョブは、昇格された権限のアプリケーションIDで実行されます。詳細は、第18.5項「Oracle Enterprise Schedulerジョブに対する権限の昇格」を参照してください。
ユーザーがRuntimeServiceまたはMetadataServiceを使用してOracle Enterprise Schedulerサービスにアクセスすると、ユーザーのアイデンティティが取得され、Oracle Enterprise Schedulerによって、リソース(メタデータ・オブジェクトなど)にアクセスするために必要な権限がこのユーザーにあるかどうかが確認されます。たとえば、teller1という名前のユーザーがgetJobDefinitionをコールしてメタデータ・オブジェクトcalculateFeesにアクセスする必要がある場合、Oracle Enterprise Schedulerでは、オブジェクトを返す前に、メタデータ・オブジェクトcalculateFeesに対するREAD権限がteller1にあることを確認します。
設計時に、メタデータ作成者は、どのジョブ機能がどのメタデータ・オブジェクトにアクセスできるかを決定する必要があります。これは、各メタデータ・オブジェクトを1つ以上のロールに関連付けて、各ロールに1つ以上のアクションを指定することによって表します。
メタデータのロール割当てには、次の2つのオプションがあります。
Oracle JDeveloperツールのOracle ADF Securityウィザードの使用
Oracle JDeveloper Oracle Enterprise Schedulerのアドインであるメタデータ・ページの使用
Oracle JDeveloperのADFセキュリティ・ウィザードにより、使用するロールが作成されますが、ロールは、ロールをメタデータ・オブジェクトに登録する前に作成する必要があります。
これらの手順では、Oracle Enterprise Schedulerを使用したアプリケーションに対する最小の検証されたセキュリティ設定について説明します。
次の手順に従って、作業用のjps-config.xmlおよび一部移入されたjazn-data.xmlを作成します。これらの手順を使用して、JPSで使用するサーブレットを構成します。
ADFセキュリティ・ウィザードを使用してセキュリティを有効にする手順は、次のとおりです。
Oracle JDeveloperでアプリケーションを開き、「アプリケーション」メニューから「保護」を選択します。
ドロップダウン・リストから、「ADFセキュリティの構成」を選択します。「ADFセキュリティの構成」ウィザードが表示されます。
「ADFセキュリティの有効化」ページで、「ADF認証および認可」または「ADF認証」のいずれかを選択して、「次へ」をクリックします。
「認証タイプの選択」ページで、「HTTP Basic認証」または「フォームベース認証」のいずれかを選択して、「次へ」をクリックします。
「自動ポリシー付与の有効化」ページで、「自動付与の有効化」領域から適切なオプションを選択して、「次へ」をクリックします。
「認証されたようこそページを指定」で必要に応じてオプションを選択し、「次へ」をクリックします。
「サマリー」ページでオプションを検証して、「終了」をクリックします。
「セキュリティ・インフラストラクチャが作成されました」ダイアログで、「OK」をクリックします。
次に、セキュリティを有効にしてjazn-data.xmlがアプリケーション・デプロイメントに含まれていることを確認するには、アプリケーションのEARファイルをアセンブル後、次の手順を実行します。詳細は、第5.6.3項「Oracle Enterprise Schedulerサンプル・アプリケーションのEARファイルをアセンブルする方法」を参照してください。
セキュリティ関連ファイルがEARファイルに含まれていることを確認する手順は、次のとおりです。
Oracle JDeveloperで、「アプリケーション」→「アプリケーションのプロパティ」を選択します。
「アプリケーションのプロパティ」ページのナビゲータで、「デプロイメント」を選択します。
「デプロイメント・プロファイル」領域で、EARファイルのデプロイメント・ディスクリプタを選択します。たとえば、サンプル・アプリケーションの詳細は、第5.6.3項「Oracle Enterprise Schedulerサンプル・アプリケーションのEARファイルをアセンブルする方法」を参照してください。
「編集」をクリックします。これにより、「EARデプロイメント・プロファイルのプロパティの編集」ページが表示されます。
「EARデプロイメント・プロファイルのプロパティの編集」ページで、「ファイル・グループ」→「アプリケーション・ディスクリプタ」→「フィルタ」を展開します。
「フィルタ」領域で「ファイル」タブを選択します。
ファイルjazn-data.xml、jps-config.xmlおよびweblogic-application.xmlが、META-INFフォルダで選択されていることを確認します。
「OK」をクリックしてディスクリプタを保存します。
ロールは、Oracle Enterprise Schedulerセキュリティで使用する前に、定義する必要があります。定義できるロールには、次の2つのタイプがあります。
エンタープライズ・ロール: これらは、Oracle WebLogic Serverコンソール、WLSTスクリプト、またはOracle JDeveloperのADFセキュリティ・ウィザードを使用して、Oracle WebLogic Serverで直接定義します。
アプリケーション・ロール: これらはjazn-data.xmlファイルで定義するか、またはADFセキュリティ・ウィザードを使用して定義できます。
プリンシパル・セキュリティを定義する手順は、次のとおりです。
Oracle JDeveloperでアプリケーションを開き、「アプリケーション・ナビゲータ」で「アプリケーション・リソース」を展開します。
「アプリケーション・リソース」領域で、「ディスクリプタ」および「META-INF」を展開します。
META-INFで、ダブルクリックしてjazn-data.xmlを開きます。
jazn-data.xmlが表示されているページで、「概要」タブを選択します。「概要」タブが表示されない場合には、jazn-data.xmlを閉じてから再度開くようにしてください。
「アプリケーション・ロール...」(「ユーザーとロールの管理」)をクリックします。
「JPSアイデンティティとポリシー・ストアの編集」ページのナビゲータで、「アイデンティティ・ストア」および「jazn.com」を展開します。
ナビゲータで、「ロール」を選択して「追加...」をクリックします。これにより、「ロールの追加」ダイアログが表示されます。
「ロールの追加」ダイアログで、「名前」フィールドに名前を入力します。
「OK」をクリックします。
「JPSアイデンティティとポリシー・ストアの編集」ページのナビゲータで、「アプリケーション・ポリシー・ストア」を選択します。アプリケーションと同じ名前のサブ要素がある場合には次の手順に進み、ない場合には次を実行します:
「アプリケーション・ポリシー・ストア」を選択します。
「新規...」をクリックします。これにより、「アプリケーション・ポリシーの作成」ダイアログが表示されます。
「アプリケーションの作成」ダイアログの「表示名」フィールドに、アプリケーション名が含まれている必要があります。
「OK」をクリックして、デフォルトの表示名をそのまま使用します。
「JPSアイデンティティとポリシー・ストアの編集」ページのナビゲータで、「アプリケーション・ポリシー・ストア」および「アプリケーション名」を展開します。
ナビゲータで、「アプリケーション・ロール」を選択します。これにより、「アプリケーション・ロール」ページが表示されます。
「アプリケーション・ロール」ページで「追加...」をクリックして、ロールを追加します。正しく機能させるには、「メンバー・ロール」タブでエンタープライズ・ロールを追加することにより、少なくとも1つのエンタープライズ・ロールをアプリケーション・ロールにマップする必要があります。
「OK」をクリックします。
すべてのメタデータへのアクセスは、権限によって制御されています。適切なアイデンティティによるアクセスを確実にするには、適切な権限を与える必要があります。ほとんどのメタデータの権限付与は、Oracle Enterprise Scheduler Oracle JDeveloperのアドインを使用して行われると想定されています。
最初に、「ファイル」→「新規」→「ビジネス層」→「エンタープライズ・スケジューラ・メタデータ」を使用して、必要な任意のOracle Enterprise Schedulerメタデータをアプリケーションに作成します。メタデータの作成の詳細は、第5.5項「Oracle Enterprise Schedulerサンプル・アプリケーションのメタデータの作成」を参照してください。
Oracle JDeveloperを使用すると、セキュリティ権限をOracle Enterprise Schedulerのメタデータ・オブジェクトに追加できます。
Oracle Enterprise Schedulerのメタデータ・オブジェクトを保護する手順は、次のとおりです。
任意のOracle Enterprise Schedulerのメタデータ・オブジェクトに対して「エディタ」ページを開きます。
「アクセス制御」領域で、「追加」をクリックして新規アクセス制御項目を追加します。
「アクセス制御の追加」ダイアログで、ドロップダウン・リストから「ロール」を選択します。これにより、アクセス権限を付与するロールが選択されます。
リストの「読取り」、「実行」、「更新」または「削除」から1つ以上のアクションを選択します。
「OK」をクリックします。これにより、図18-2に示すように、更新されたロールが表示されます。
必要な数のロールに対して繰り返します。
ワイルドカードを使用する場合など、権限の明示的な作成が必要となる場合があります。これらの手順は、ADFセキュリティ・ウィザードを使用して権限を設定する方法を示しています。
これらの手順では、すでにアプリケーション・ロールを作成済であると想定していることに注意してください。
ADFセキュリティ・ウィザードを使用して権限を指定する手順は、次のとおりです。
アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを開きます。
図18-3に示すように、「ディスクリプタ」および「META-INF」を展開します。
jazn-data.xmlをダブルクリックしてファイルを開きます。jazn-data.xmlのエディタ・パネルで「概要」タブを選択し、「アプリケーション・ロール...」(「ユーザーとロールの管理」)をクリックします。これにより、「JPSアイデンティティとポリシー・ストア」ダイアログが表示されます。「概要」タブが表示されない場合には、jazn-data.xmlを閉じてから再度開くようにしてください。
ナビゲータのJPSアイデンティティとポリシー・ストア・ダイアログで、「アプリケーション・ポリシー・ストア」を展開します。
「アプリケーション-名前」を展開して、「アプリケーション・ロール」を選択します。
「新規」をクリックします。
この付与に対して使用する表示名を入力して、「OK」をクリックします。
「プリンシパル」タブを選択して、「追加...」をクリックします。
付与を受けるアプリケーション・ロールの名前を入力します(この名前は作成したロール名のいずれかである必要があります)。「クラス」フィールドはそのままにしておきます。
「OK」をクリックします。
「プリンシパル」タブで選択した新規ロールについて、「タイプ」がroleとなっていることを確認します。
「権限」タブを選択して、「追加...」をクリックします。
「名前」フィールドには、権限の文字列全体、またはワイルドカードとともに文字列の一部を入力します(例として、表18-1を参照してください)。「クラス」フィールドで、oracle.as.scheduler.security.MetadataPermissionと入力します。「OK」をクリックします。
「権限」タブで選択した新しい権限を使用して、「アクション」フィールドに必要なアクションを入力します。
「OK」をクリックして付与を保存します。
|
注意: 必要に応じて、次の回避策を使用します。
|
表18-1 Oracle ADFを使用したセキュリティの権限付与のサンプル
| 名前 | アクション | 結果 |
|---|---|---|
|
|
|
単一のメタデータ・アイテムに対してリクエストを発行する機能を付与します。 |
|
|
|
/mypackage/subpackageに新しい任意のメタデータ・アイテムを作成して実行する機能を付与します。 |
|
|
|
非定型発行権限を付与します。 |
|
|
|
制限のない権限を付与します。 |
メタデータに対する付与は、クラスoracle.as.scheduler. security.MetadataPermissionに含まれています。権限の名前またはターゲットはパッケージ、メタデータ・オブジェクト・タイプおよび保護されているメタデータ・オブジェクトの名前に基づいており、この識別子はMetdataObjectId#toPermissionString()から取得できます。
表18-2に、付与に対するアクションを示します。表記法<Type>は、すべてのメタデータ・オブジェクト・タイプに対するプレースホルダです。たとえば、get<Type>()は、メソッドgetJobDefinition()、getJobType()、getJobSet()を参照しています。
表18-2 メタデータのセキュリティに対する付与アクション
| アクション | 適用 | メタデータ関数 |
|---|---|---|
|
|
|
get<Type>()、query<Type>() |
|
|
|
submitRequest() |
|
|
|
add<Type>() |
|
|
|
update<Type>() |
|
|
|
delete<Type>() |
非定型リクエストを発行する場合は、EXECUTEとCREATEの両方のアクションについて、完全なワイルドカード(*)権限を持つことができます。つまり、特定のMetadataObjectIdsなしでsubmitRequest()を使用して非定型リクエストを発行する場合は、EXECUTEおよびCREATEのアクションを使用して、完全なワイルドカード(*)の権限を付与できます。
ユーザー・アプリケーションによってMetdataServiceまたはRuntimeServiceメソッドがコールされるたびに、Oracle Enterprise Schedulerでは、メソッドによってアクセスされるメタデータに対する権限について、現在のサブジェクトを確認します。たとえば、リクエストを発行するには、発行に関連付けられるジョブ定義やジョブ・セットのメタデータ・オブジェクトに対するEXECUTE権限が必要です。updateJobDefinition()をコールするなど、メタデータを変更するメソッドには、UPDATE権限が必要となります。
問合せを除くすべてのMetadataServiceメソッドでは、ユーザーが権限のないメタデータ・オブジェクトにアクセスしようとすると、例外がスローされます。
MetadataService問合せメソッドの場合には動作が異なります。ユーザーが問合せを実行すると、Oracle Enterprise Schedulerにより、READ権限のあるメタデータ・オブジェクトのみが返されます。これにより、メタデータ・オブジェクトに対して権限がないユーザーはすべての問合せについて空のリストを受信しますが、このユーザーには権限がないため、スローされた例外は表示されません。
SystemProperty.USER_NAMEの値は発行時に上書きされるため、ユーザーが発行時にSystemProperty.USER_NAMEを使用して、アイデンティティを偽装することはできません。
Oracle Enterprise Scheduler Webサービスの保護の詳細は、第11.9項「Oracle Enterprise Scheduler Webサービスの保護」を参照してください。
PL/SQLジョブでは、ess_runtimeパッケージのAPIをコールするときに、データのセキュリティ・チェックを行いません。
ユーザーがOracle Enterprise SchedulerサービスにRuntimeServiceまたはMetadataServiceインタフェースを使用してアクセスする場合、メソッドをコールしているユーザーのアイデンティティが取得されます。特定のリソース(メタデータ・オブジェクトなど)へのアクセスに必要な権限がユーザーにあるかどうかを確認するために、このアイデンティティが使用されます。たとえば、ユーザーteller1がメソッドgetJobDefinitionをメタデータ・オブジェクトcaclulateFeesに対してコールする場合、Oracle Enterprise Schedulerでは、オブジェクトを返す前に、メタデータ・オブジェクトcaclulateFeesに対する読取り権限がteller1にあることを確認します。
コール元のアイデンティティは、ユーザーによってリクエストされたジョブの実行にも使用されます。たとえば、ユーザーteller1がメソッドsubmitRequest()をJavaジョブに対してコールする場合、リクエストされたジョブはteller1の下で実行され、そのユーザーに対して割り当てられたロールおよび資格証明はすべて保持されます。
Oracle Enterprise Schedulerでは、アプリケーション・アイデンティティの使用がサポートされています。アプリケーション・アイデンティティを使用すると、発行元ユーザーに割り当てられている権限よりも高い権限を必要とするジョブを完了するために、権限を昇格できます。
Oracle Platform Securityポリシー・ストアは、認可ポリシーのリポジトリとして機能します。認可ポリシーは実行時にJava仮想マシンにロードされ、認可に関する決定を行うために使用されます。認可ポリシーは、アプリケーション・ロールの階層、エンタープライズ・ロールのアプリケーション・ロールへのマッピングおよびアプリケーション・ロールへの権限付与で構成されています。アプリケーション・ロールを階層的にすることもできます。
認可ポリシーに加えて、Oracle Platform Securityポリシー・ストアには、これらの認可ポリシーを保持するのに役立つ管理構成(関連するリソース・タイプを含むリソース・カタログ、権限セット、ロール・カテゴリなど)も格納されます。認可ポリシーおよび管理コンポーネントは、アプリケーションにスコープされています。これは、アプリケーション・ストライプと呼ばれます。
アプリケーション・ストライプとは、JAASポリシーのコレクションのことで、それが関連付けられたアプリケーションに適用可能です。購入した時点で、1つのアプリケーション・ストライプが1つのOracle Java EEアプリケーションにマップされています。Oracle Platform Securityでは、複数のJava EEアプリケーションの1つのアプリケーション・ストライプに対するマッピングもサポートされています。アプリケーションID文字列によって、1つまたは複数のアプリケーションの名前が識別されます。
Oracle Enterprise Schedulerを使用すると、applicationStripe名を指定して、JPSポリシー・コンテキストIDにマッピングできます。アプリケーションをホストする複数のOracle Enterprise Schedulerを単一のポリシー・コンテキストに割り当てることができます。
アプリケーションをホストするOracle Enterprise Schedulerを特定のapplicationStripeに対して構成する手順は、次のとおりです。
ejb-jar.xmlファイルを開きます。
message-driven要素で、値applicationStripeを含むactivation-config-properties要素を追加します。
jpsinterceptor-class要素で、JpsInterceptorを構成します。
<message-driven>要素の下にあるapplicationStripe値が、<interceptor>要素の下にあるapplication.name値と必ず一致するようにしてください。
例18-1に、ポリシー・コンテキストESS_FUNCTIONAL_TEST_APP_STRIPEに対するapplicationStripe構成を示します。
例18-1 applicationStripeおよびJpsInterceptorの構成
<ejb-jar>
....
<enterprise-beans>
<message-driven>
<ejb-name>ESSAppEndpoint</ejb-name>
<ejb-class>oracle.as.scheduler.ejb.EssAppEndpointBean</ejb-class>
<activation-config>
....
<activation-config-property>
<activation-config-property-name>applicationStripe</activation-config-property-name>
<activation-config-property-value>ESS_FUNCTIONAL_TESTS_APP_
STRIPE</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
.....
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</env-entry-value>
<injection-target>
<injection-target-class>oracle.security.jps.ee.ejb.JpsInterceptor
</injection-target-class>
<injection-target-name>application_name</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
</interceptors>
</ejb-jar>
アプリケーションにWebモジュールが含まれている場合、web.xmlファイルで、WebモジュールJpsFilterによって同じapplicationStripeが使用されるように構成します。例18-2に、コード・サンプルを示します。
例18-2 web.xmlでのWebモジュールの構成
<web-app>
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
...
<init-param>
<param-name>application.name</param-name>
<param-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</param-value>
</init-param>
</filter>
</web-app>
設計時には、アプリケーション・ストライプは次のものとして表されます。
jazn-data.xmlファイルの<policystore>要素の下の<application>要素
ノードcn=<Weblogic.domain.name>,cn=JPSContext,cn=<root.node>の下のノード(cn=ATGDemo,cn=base_domain,cn=JPSContext,cn=MY_Nodeなど)
