この章では、リソースに対するアクセス制御およびジョブ実行に対するアプリケーション・アイデンティティ伝播を提供する、Oracle Enterprise Schedulerのセキュリティ機能について説明します。
この章の内容は次のとおりです。
Oracle Enterprise Scheduler Securityでは、アプリケーション・アイデンティティの使用のためにMetadataService
およびサポートにおいて保護された操作が含まれます。
Oracle Enterprise Schedulerセキュリティには、次のことが含まれています。
MetadataService
に対する保護された操作。MetadataPermission
によって保護され、これにより、メタデータのアクセス制御が行われます。メタデータ・オブジェクトに対するアクセス制御。権限を持つユーザーのみが、ジョブの作成、削除および更新と、メタデータのスケジュールを行うことができます。詳細は、「Oracle Enterprise Schedulerのメタデータ・アクセス制御」を参照してください。
アプリケーション・アイデンティティの使用のサポート。アプリケーション・アイデンティティを使用すると、発行元ユーザーに割り当てられている権限よりも高い権限を必要とするジョブを完了するために、権限を昇格できます。詳細は、「Oracle Enterprise Schedulerのジョブ実行のセキュリティ」を参照してください。
設計時に、メタデータ作成者は、どのジョブ機能がどのメタデータ・オブジェクトにアクセスできるかを決定する必要があります。これは、各メタデータ・オブジェクトを1つ以上のロールに関連付けて、各ロールに1つ以上のアクションを指定することによって表します。図23-1に、メタデータのセキュリティのサマリーを示します。
図23-1 Oracle Enterprise Schedulerのデザインタイム・メタデータのセキュリティ
ジョブの発行中、ジョブ・リクエストを発行する権限を持つユーザーは、発行元ユーザーと呼ばれます。リクエストの実行時、すべてのユーザーのJavaコード(前処理、後処理、Javaジョブ、置換など)は、すべてのロールと資格証明が保持された状態で、発行元ユーザーとして実行されます。
ただし、ジョブ・メタデータにSYS_RUNAS_APPLICAITONID
を指定すると、ジョブは、昇格された権限のアプリケーションIDで実行されます。詳細は、「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セキュリティ・ウィザードを使用してセキュリティを有効にする手順は、次のとおりです。
セキュリティを有効にしてjazn-data.xml
がアプリケーション・デプロイメントに含まれていることを確認するには、アプリケーションのEARファイルをアセンブル後、次の手順を実行します。
Oracle JDeveloperで、「アプリケーション」→「アプリケーションのプロパティ」を選択します。
「アプリケーションのプロパティ」ページのナビゲータで、「デプロイメント」を選択します。
「デプロイメント・プロファイル」領域で、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
を閉じてから再度開くようにしてください。
「エンタープライズ・ロール」タブを選択します。
「ロール」リスト内の「追加」ボタンをクリックして、「新しいロールの追加」を選択します。
「名前」フィールドでEssEnterpriseRole
に名前を設定します。
すべてのメタデータへのアクセスは、権限によって制御されています。適切なアイデンティティによるアクセスを確実にするには、適切な権限を与える必要があります。ほとんどのメタデータの権限付与は、Oracle Enterprise Scheduler Oracle JDeveloperのアドインを使用して行われると想定されています。
最初に、「ファイル」→「新規」→「ビジネス層」→「エンタープライズ・スケジューラ・メタデータ」を使用して、必要な任意のOracle Enterprise Schedulerメタデータをアプリケーションに作成します。
Oracle JDeveloperを使用すると、セキュリティ権限をOracle Enterprise Schedulerのメタデータ・オブジェクトに追加できます。
Oracle Enterprise Schedulerのメタデータ・オブジェクトを保護する手順は、次のとおりです。
図23-4 Oracle Enterprise Schedulerメタデータのセキュリティ・ロール
メタデータに対する権限付与は、クラスoracle.as.scheduler
. security.MetadataPermission
に含まれています。権限の名前またはターゲットはパッケージ、メタデータ・オブジェクト・タイプおよび保護されているメタデータ・オブジェクトの名前に基づいており、この識別子はMetdataObjectId#toPermissionString()
から取得できます。
表23-1に、付与に対するアクションを示します。表記法<Type>は、すべてのメタデータ・オブジェクト・タイプに対するプレースホルダです。たとえば、get<Type>()は、メソッドgetJobDefinition()
、getJobType()
、getJobSet()
を参照しています。
表23-1 メタデータのセキュリティに対する付与アクション
アクション | 適用 | メタデータ関数 |
---|---|---|
|
|
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スタンドアロン・データ・セキュリティ実装は、RuntimeDataPermission
クラスを使用する機能セキュリティ権限のチェックに基づきます。
デフォルトで、Oracle Enterprise Schedulerは次のレベルのデータ・セキュリティ施行をサポートします。
ユーザーは、自分が発行するリクエストのみを操作できます。
ユーザーに管理、オペレータまたはモニター・ロールを割り当てることで、リクエストの発行者にかかわらず、すべてのリクエストを表示する権限がユーザーに付与されます。
ユーザーは、自分が発行または実行したリクエストによって生成された出力を表示できます。
デフォルトのデータ・セキュリティ権限を追加または変更する場合、「データ・セキュリティ権限の変更方法」の説明に従って、jazn-data.xml
ファイルを再構成する必要があります。
この項では、「Oracle Enterprise Schedulerのデータ・セキュリティの構成」の説明に従い、即時利用可能なデフォルト設定からジョブ・リクエストのデータ・セキュリティを変更するようにjazn-data.xml
ファイルを構成する方法について説明します。
RuntmeDataPermission
を定義するjazn-data.xml
権限セクションの例を次に示します。
<permission> <name>definition like 'oracle.apps.ess.custom.soa.*',product like "SOA%",PROPERTY1=VALUE1</name> <class>oracle.as.scheduler.security.RuntimeDataPermission</class> <actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions> </permission
前述の例で定義されている権限条件では、ジョブ・リクエストが次の条件と一致した場合、ジョブ・リクエストの詳細およびジョブ・リクエスト出力の読取り権限が付与されます。
そのジョブ定義がパターン: oracle.apps.ess.custom.soa.*
と一致し、
製品フィールドの値がSOAであり、
PROPERTY1
という名前のユーザー定義プロパティが、VALUE1
という値で設定されています。
条件は、<name>
要素で指定され、=および
like
/LIKE
演算子を使用します。%
および*のワイルドカード文字は、like
/LIKE
演算子とともに使用できます。メタデータ・オブジェクト名を指定するフィールド名では%
ワイルドカード文字を使用できませんが、フィールド名が別のデータ(製品など)およびリクエスト・カテゴリを指定している場合使用できます。たとえば、次の例は正しく機能します。
definition LIKE 'oracle.apps.ess.custom.soa.*'
requestCategory LIKE 'EssFineGrained%',workAssignment LIKE'FineGrainedWA%',className LIKE '%BasicJavaJob%'
一方、次のエントリは正しく機能しません。
definition LIKE 'oracle.apps.ess.custom.soa.%'
条件は、次の固有のデリミタ構文を使用したキーと値のペアのセットとして指定されます。
条件内のキーと値のペアは、「,」文字で区切られます。
空白文字は、「,」デリミタの直前または直後には指定できません。
キーと値の条件の値部分は引用符なしとするか、一重引用符または二重引用符で囲むことができます。
同じ要素内で指定されている複数の条件は、論理的にAND演算されるように解釈されます。
同じ権限受領者に2つ以上の権限リソースを定義することで、論理的にOR条件を指定できます。
次のルールが、フィールド名およびreqProp
キーに適用されます。
フィールド名は、RuntimeService.QueryField
のfieldName
で表される値である必要があります。たとえば、QueryField.DEFINITION.fieldName()
のように指定します。
ResultIndex
のリクエスト履歴ビューに同等のフィールドがないため、ResultIndex
をフィールド名として指定できません。リクエスト履歴ビューは、Request_history
表から作成されるデータベース・ビューです。スタンドアロン・データ・セキュリティのSQL問合せは、このビューに対して実行されます。
reqProp
は、Oracle Enterprise Schedulerジョブ・メタデータで、またはリクエスト発行時に定義されるユーザー・プロパティです。たとえば、PARTITION_NAME='SOA'
などです。
表23-2に、有効なフィールド名のリストと、対応するリクエスト履歴ビューの列エントリを示します。
表23-2 条件問合せフィールドと、対応するリクエスト履歴ビューの列エントリ
問合せフィールド | リクエスト履歴ビューの列 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
例23-1に、権限を<permission>
要素でどのように直接指定するかを示します。
例23-2に、権限セットを使用して権限をどのように指定するかを示します。
注意:
<permission-sets>
- <permission-set>
- <member-resources>
- <member-resource>
- <resource-name>
要素で定義される内容は、<resources>
- <resource>
- <name>
要素で定義される内容と同じである必要があります。
例23-1 PL/SQLのリクエスト・テキスト出力
<app-roles> <app-role> <name>riyanu_soa_role</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>riyanu_soa_group</name> <class>weblogic.security.principal.WLSGroupImpl</class> </member> </members> </app-role> </app-roles> <grant> <grantee> <description>Allow soa role to pass through</description> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>riyanu_soa_role</name> </principal> </principals> </grantee> <permissions> <permission> <name>oracle.apps.ess.custom.soa.*</name> <class>oracle.as.scheduler.security.MetadataPermission</class> <actions>READ,EXECUTE,CREATE,DELETE,UPDATE</actions> </permission> <permission> <name>definition like oracle.apps.ess.custom.soa.*, partitionName=SOA_PARTITION,product=SOA</name> <class>oracle.as.scheduler.security.RuntimeDataPermission</class> <actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE, ESS_REQUEST_OUTPUT_READ</actions> </permission> </permissions> </grant>
例23-2 PLSQLのリクエスト・バイナリ出力の例
<app-roles> <app-role> <name>riyanu_soa_role</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>riyanu_soa_group</name> <class>weblogic.security.principal.WLSGroupImpl</class> </member> </members> </app-role> </app-roles> <resource-types> <resource-type> <name>ESSSOAMetadataResourceType</name> <display-name>ESSSOAMetadataResourceType</display-name> <description>ESS SOA Metadata Resource</description> <matcher-class>oracle.as.scheduler.security.MetadataPermission</matcher-class> <actions-delimiter>,</actions-delimiter> <actions>create,read,update,delete,execute</actions> </resource-type> <resource-type> <name>ESSSOARequestResourceType</name> <display-name>ESSSOARequestResourceType</display-name> <description>Resource type for simple ESS request accesscontrol</description> <matcher-class>oracle.as.scheduler.security.RuntimeDataPermission </matcher-class> <actions-delimiter>,</actions-delimiter> <actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE,ESS_REQUEST_CANCEL, ESS_REQUEST_DELETE,ESS_REQUEST_OUTPUT_READ</actions> </resource-type> </resource-types> <resources> <resource> <name>oracle.apps.ess.custom.soa.*</name> <type-name-ref>ESSSOAMetadataResourceType</type-name-ref> <description>All SOA ESS metadata</description> <display-name>All SOA ESS metaddata</display-name> </resource> <resource> <name>definition like "oracle.apps.ess.custom.soa.*", partitionName=SOA_PARTITION,product=SOA</name> <type-name-ref>ESSSOARequestResourceType</type-name-ref> <description>Any ESS Multi request</description> <display-name>Any ESS Multi request</display-name> </resource> </resources> <permission-sets> <permission-set> <name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name> <display-name>Read privilege on all SOA ESS metadata </display-name> <description>Read privilege on all SOA ESS metadata</description> <member-resources> <member-resource> <type-name-ref>ESSSOAMetadataResourceType</type-name-ref> <resource-name>oracle.apps.ess.custom.soa.*</resource-name> <actions>create,read,execute</actions> </member-resource> </member-resources> </permission-set> <permission-set> <name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name> <display-name>All privileges on all ESS Requests</display-name> <description>Allow read, update, cancel, hold, delete all the ESS requests</description> <member-resources> <member-resource> <type-name-ref>ESSSOARequestResourceType</type-name-ref> <resource-name>definition like "oracle.apps.ess.custom.soa.*", partitionName=SOA_PARTITION,product=SOA</resourcename> <actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions> </member-resource> </member-resources> </permission-set> </permission-sets> <jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>riyanu_soa_role</name> </principal> </principals> </grantee> <permission-set-refs> <permission-set-ref> <name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name> </permission-set-ref> <permission-set-ref> <name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name> </permission-set-ref> </permission-set-refs> </grant> </jazn-policy>
Oracle Enterprise Scheduler Webサービスの保護の詳細は、「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に対して構成する手順は、次のとおりです。
例23-3 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>
例23-4 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
など)