| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
前 |
次 |
この章では、OPSSを使用するがOracle Application Development Framework (Oracle ADF)セキュリティを使用しないJava EEアプリケーションにお薦めの構成およびパッケージ化について説明します。
この章では、次の各項についても説明します。
次のセキュリティ関連のファイルは、開発、デプロイおよび実行時にJava EEアプリケーションで関係します。
DOMAIN_HOME/config/fmwconfig/jps-config.xml
DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml
jazn-data.xml (アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにパッケージ化)
cwallet.sso (アプリケーションEARファイルにパッケージ化)
web.xml (アプリケーションEARファイルにパッケージ化)
weblogic-application.xml (アプリケーションEARファイルにパッケージ化)
次の各トピックには、Java EEアプリケーションでの認証の開発に関する情報が記載されています。
『Oracle WebLogic Serverセキュリティの理解』の認証に関する項
『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次の各項
「Webアプリケーションの保護」
JavaクライアントでのJAAS認証の使用
JavaクライアントでのSSL認証の使用
JAAS認証の開発環境
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』
「認証プロバイダ」
「アイデンティティ・アサーション・プロバイダ」
「サーブレット認証フィルタ」
カスタム認証プロバイダの開発方法
ログイン・モジュールに関する項
OPSSログイン・モジュールは、Java EEアプリケーションおよびJava SEアプリケーションでのプログラムによるユーザー認証とアサーションをサポートしており、このログイン・モジュールのコールに使用するAPIはJava EEアプリケーションとJava SEアプリケーションの両方に共通します。Oracle WebLogic Serverは、WebLogic Serverセキュリティ・プロバイダにユーザー認証とアサーションを委託します。
この項で説明している構成は、Oracle JDeveloperの外で(OPSSと統合されている) Java EEアプリケーションをパッケージ化または構成する場合にのみ必要です。
OPSSでは、Javaサーブレット用にJpsFilterフィルタが、Enterprise JavaBeans (EJB)用にJpsInterceptorインターセプタが用意されています。フィルタは、Webアプリケーション・アーカイブ(WAR)ファイルにパックされるweb.xmlファイルで構成します。インターセプタは、JARファイルにパックされるejb-jar.xmlファイルで構成します。
OPSSには、web.xmlファイルで、アプリケーションMBeanがアクセスするストライプを構成する手段も用意されています。
すぐに使用できる状態では、フィルタはデフォルトのパラメータ値で設定されているため、デプロイメント記述子で構成する必要はありません。しかし、デフォルト値とは異なる値が必要な場合は、手動で構成する必要があります。インターセプタは手動で構成する必要があります。
フィルタおよびインターセプタの構成に使用するパラメータの説明は、次の各項を参照してください。
アプリケーション・ストライプは、必要に応じてアプリケーションのweb.xmlファイルで指定しますが、適用可能なポリシー・セットを決定するために実行時に使用されます。指定しない場合は、アプリケーションID(アプリケーション名が含まれる)にデフォルト設定されます。
アプリケーション・ストライプを設定するには、application.nameパラメータを使用します。この設定はオプションで、大文字と小文字が区別されます。指定しない場合は、アプリケーションの名前にデフォルト設定されます。
アプリケーション・ストライプを指定するには、web.xmlでfilter要素またはcontext-param要素を構成します。
<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>stripeid</param-value> </init-param> </filter>
<context-param> <description>JPS custom stripe id</description> <param-name>application.name</param-name> <param-value>stripeid</param-value> </context-param>
アプリケーションにセキュリティ・ストアにアクセスするアプリケーションMBeanが含まれ、アプリケーションの名前がそのMBeanがアクセスするストライプの名前と異なる場合は、前述と同様にcontext-param構成を使用してストライプ名を指定する必要があります。
その他の例
次の例では、web.xmlでのMyServlet1サーブレットとMyServlet2サーブレットの構成を示します。同じWARファイル内のサーブレットが同じポリシー・ストライプを使用している点に注意してください。
<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>MyAppName</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet1</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet2</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
次の例では、ejb-jar.xmlファイルでのMyAppNameアプリケーション・ストライプおよびJpsInterceptorインターセプタの構成と、MyEjbへのそのインターセプタのバインドを示します。
<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>MyAppName</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>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>.
サブジェクトにアプリケーション・ロールを追加するは、add.application.rolesパラメータをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。アプリケーション・ロールのプリンシパル・クラスは、oracle.security.jps.service.policystore.ApplicationRoleクラスです。
匿名ユーザーの使用を有効にするには、enable.anonymousをtrueに設定します。無効にするには、falseに設定します。デフォルト値はtrueです。
サブジェクトから匿名ロールを削除するには、remove.anonymous.roleをtrueに設定します。保持するには、falseに設定します。デフォルト値はfalseです。
匿名ユーザーおよびロールの名前とプリンシパル・クラスは、次のとおりです。
anonymous oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl anonymous-role oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
次の例では、web.xmlファイルでの匿名ユーザーおよびロールの設定と、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>enable.anonymous</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>remove.anonymous.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
次の例では、ejb-jar.xmlファイルでのremove.anonymous.roleの設定と、MyEjbによるインターセプタの使用方法を示します。
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>remove.anonymous.role</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>remove_anonymous_role/injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
サブジェクトに認証ロールを追加するは、add.authenticated.roleプロパティをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。
認証ロールの名前とプリンシパル・クラスは、次のとおりです。
authenticated-role oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl
次の例では、web.xmlファイルでのadd.authenticated.roleプロパティの構成と、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>add.authenticated.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
JAASモードを設定するには、次の値のいずれかを指定してoracle.security.jps.jaas.modeパラメータを使用します。
doAs doAsPrivileged off undefined subjectOnly
デフォルト値はdoAsPrivilegedです。
次の例では、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>oracle.security.jps.jaas.mode</param-name>
<param-value>doAs</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
次の例では、doAsの設定とJpsInterceptorインターセプタの使用方法を示します。
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>oracle.security.jps.jaas.mode</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>doAs</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>oracle_security_jps_jaas_mode
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
次の要件は、JpsInterceptorパラメータの指定すべてに適用されます。
env-entry-type要素にパラメータ・タイプを指定する必要があります。
インターセプタのクラスと同じクラス(injection-target-class要素に指定)を特定するinjection-target要素を指定する必要があります。injection-target-name要素には、ドットをアンダースコアに置換した文字列として名前を再度書き込む必要があります。
インターセプタのクラスを参照することで、EJBへのインターセプタのバインドを指定する必要があります。
次の表に、フィルタおよびインターセプタのパラメータを示します。
表23-1 JpsFilterおよびJpsInterceptorのパラメータ
| パラメータ名 | 値 | デフォルト | 機能 | 注意 |
|---|---|---|---|---|
|
application.name |
任意の有効な文字列。この値では大文字と小文字が区別されます。 |
アプリケーションの名前。 |
JavaサーブレットまたはEJBによって使用されるポリシーのサブセットを指定します。 |
複数のJavaサーブレットまたはEJBで同じポリシーのサブセットにアクセスするかどうかを指定する必要があります。 |
|
add.application.roles |
|
|
アプリケーション・ロールをサブジェクトに追加します。 |
アプリケーション・ロールをサブジェクトに追加しない場合は |
|
enable.anonymous |
|
|
サブジェクトで匿名ユーザーを有効にします。 |
|
|
remove.anonymous.role |
|
|
認証後にサブジェクトから匿名ロールを削除します。 |
Javaサーブレットの場合にのみ使用可能です。EJBの場合、匿名ロールはサブジェクトから削除されます。 |
|
add.authenticated.role |
|
|
サブジェクトへの認証ロールの追加を許可します。 |
認証ロールをサブジェクトに追加しない場合は |
|
oracle.security.jps.jaas.mode |
doAsPrivileged doAs Off undefined subjectOnly |
doAsPrivileged |
JAASモードを設定します。 |
アプリケーション・ロールのメンバーに指定するクラスは、アプリケーション・ロールのクラスまたは次のいずれかにする必要があります。
weblogic.security.principal.WLSUserImpl weblogic.security.principal.WLSGroupImpl
次の例では、ロールの指定でのApplicationRoleクラスとWLSGroupImplクラスの使用方法を示します。
<app-role>
<name>app_monitor</name>
<display-name>application role monitor</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>app_operator</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>Developers</name>
</member>
</members>
</app-role>
アプリケーション・ロール名では、大文字と小文字は区別されません。エンタープライズ・ユーザーおよびグループの名前では、大文字と小文字が区別されます。
この項では、カスタムのポリシーおよび資格証明を使用するJavaサーブレットおよびEJBのパッケージ化要件について説明します。
アプリケーション・ポリシーは、jazn-data.xmlファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。
Javaサーブレットは、web.xml構成ファイルが含まれるWARファイルにパッケージ化されます。EJBは、ejb-jar.xml構成ファイルが含まれるWARファイルにパッケージ化されます。WARファイルでは、フィルタ(サーブレットの場合)またはインターセプタ(EJBの場合)の構成を対応する構成ファイルに含める必要があります。
次のパッケージ要件は、web.xmlファイルでのJavaサーブレットとフィルタの構成について述べていますが、ejb-jar.xmlファイルでのEJBとインターセプタの構成にも適用されます。
アプリケーションは、1つのEARファイルにパッケージ化する必要があります。
EARファイルには、アプリケーションのポリシーおよびロールを指定するMETA-INF/jazn-data.xmlファイルが1つのみ含まれている必要があります。
EARファイルには、1つ以上のWARファイルを含めることができます。
EARファイル内の各WARファイルまたはJARファイルには、JpsFilterフィルタを構成するweb.xmlファイルが1つのみ含まれ、このような構成はすべてのEARファイル内で同一である必要があります。
cwallet.ssoファイル内のコンポーネント資格証明は、EARファイルにパッケージ化できます。
コンポーネントで、他のコンポーネントとは異なるフィルタ構成が必要な場合は、別個のEARファイルにパッケージ化して別々にデプロイする必要があります。
アプリケーション・ポリシーは、jazn-data.xmlファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。
WARファイルで1つのコンポーネントに対して特定のポリシーを指定するには、そのコンポーネントを独自のjazn-data.xmlファイルとともに別個のEARファイルにパッケージ化する必要があります。他のポリシー・パッケージの組合せはサポートされていないため、jazn-data.xml以外のポリシー・ファイルは無視されます。
アプリケーション資格証明は、cwallet.ssoファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。
WARファイルで1つのコンポーネントに対して特定の資格証明を指定するには、そのコンポーネントを独自のcwallet.ssoファイルとともに別個のEARファイルにパッケージ化する必要があります。他の資格証明パッケージの組合せはサポートされていないため、cwallet.ssoファイル以外の資格証明ファイルは無視されます。
次の各項では、アプリケーションのデプロイ時にJava EEアプリケーションとともにパッケージ化されるポリシーおよび資格証明の移行の制御方法について説明します。
デプロイ時のアプリケーション・ポリシーの移行は、META-INF/weblogic-application.xmlファイルで指定するパラメータを使用して制御します。Fusion Middleware Controlを使用してアプリケーションを管理しない場合は、このような構成を手動で入力する必要があります。
システム・プロパティjps.deployment.handler.disabledをtrueに設定し、weblogic-application.xmlファイルでの個別の設定に関係なく、すべてのアプリケーションに対してデプロイ時のポリシーおよび資格証明の移行を無効にします。
管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ポリシーおよび資格証明が含まれているアプリケーションをデプロイする場合は、管理対象サーバーと管理サーバーによって管理されているデータが最終的に同期しないため、ライフ・サイクル・リスナーを使用してデプロイ時の移行を制御しないでください。かわりに、migrateSecurityStoreコマンドを使用して、ポリシーおよび資格証明をセキュリティ・ストアに移行します。
ポリシーの移行および削除を構成するパラメータは、次のとおりです。
移行
リスナー
プリンシパルの検証
移行のターゲット(アプリケーション・ストライプ)
次の例で構成されているこのパラメータでは、セキュリティ・ストアにポリシーを移行してマージするのか、上書きするのかを指定します。
<wls:application-param> <wls:param-name>jps.policystore.migration</wls:param-name> <wls:param-value>Option</wls:param-value> </wls:application-param>
Optionは、MERGE、OVERWRITEまたはOFFを表します。
移行しない場合は、OFFに設定します。ポリシーをマージして移行する場合は、MERGEに設定します。ターゲット・ストアでポリシーを上書きして移行する場合は、OVERWRITEに設定します。デフォルト値はMERGEです。
次の例で構成されているこのパラメータでは、ポリシーの移行先であるターゲット・ストライプを指定します。
<wls:application-param> <wls:param-name>jps.policystore.applicationid</wls:param-name> <wls:param-value>myApplicationStripe</wls:param-value> </wls:application-param>
値には、有効な任意の文字列を指定できます。指定しない場合は、WebLogic Serverにより、application_name#version形式を使用してアプリケーション名およびバージョンに基づいてストライプ名が作成されます。
このパラメータの値は、JpsFilterフィルタ用に(web.xmlで)またはJpsInterceptorインスペクタ用に(ejb-jar.xmlで)指定されるapplication.nameパラメータの値に一致する必要があります。
weblogic-application.xmlファイルから読み取られた値はデプロイ時に使用されます。web.xmlファイルまたはejb-jar.xmlファイルから読み取られた値は実行時に使用されます。
次の例で構成されているこのパラメータでは、エンタープライズ・ユーザーまたはグループへのアプリケーション・ロールのマッピングなど、エンタープライズ・ユーザーまたはグループへの参照の移行を除外するかどうかを指定します。そのため、アプリケーション・ポリシーのみの移行が可能となり、エンタープライズ・ユーザーまたはグループへのアプリケーション・ロールのマッピングは無視されます。
<wls:application-param> <wls:param-name>jps.apppolicy.idstoreartifact.migration</wls:param-name> <wls:param-value>Option</wls:param-value> </wls:application-param>
Optionは、trueまたはfalseを表します。エンタープライズ・ユーザーまたはグループを参照するアーティファクトの移行を除外する場合は、falseに設定します。それ以外の場合は、trueに設定します。指定しない場合は、デフォルトのtrueに設定されます。
|
注意: このパラメータをfalseに設定してアプリケーションをデプロイした後、アプリケーションをドメイン内で使用する前に、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはOracle WebLogic Server管理コンソールを使用してアプリケーション・ロールをエンタープライズ・グループまたはユーザーにマップします。 |
次の例では、アプリケーションEARファイルにパッケージ化され、ポリシーが記述されているjazn-data.xmlファイルを示します。system-jazn-data.xmlファイルは、アプリケーション・ポリシーの移行先となるファイル・セキュリティ・ストアを表しています。jps.apppolicy.idstoreartifact.migrationパラメータがfalseであることを前提としています。
<!-- Example 1: app role applicationDeveloperRole in jazn-data.xml that references
the enterprise group developers -->
<app-role>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<!-- app role applicationDeveloperRole in system-jazn-data.xml after migration: notice how the role developers has been excluded -->
<app-role>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<guid>CB3633A0D0E811DDBF08952E56E4544A</guid>
<class>weblogic.security.principal.WLSGroupImpl</class>
</app-role>
<!-- Example 2: app role viewerApplicationRole in jazn-data.xml makes reference
to the anonymous role -->
<app-role>
<name>viewerApplicationRole</name>
<display-name>viewerApplicationRole</display-name>
<class>weblogic.security.principal.WLSGroupImpl</class>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
</class>
<name>anonymous-role</name>
</member>
</members>
</app-role>
<!-- app role viewerApplicationRole in system-jazn-data.xml after migration:
notice that references to the anonymous role are never excluded -->
<app-role>
<name>viewerApplicationRole</name>
<display-name>viewerApplicationRole</display-name>
<guid>CB3D86A0D0E811DDBF08952E56E4544A</guid>
<class>weblogic.security.principal.WLSGroupImpl</class>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
</class>
<name>anonymous-role</name>
</member>
</members>
</app-role>
次の例で構成されているこのパラメータでは、アプリケーションのアンデプロイ時にポリシーを削除するかどうかを指定します。
<wls:application-param> <wls:param-name>jps.policystore.removal</wls:param-name> <wls:param-value>OFF</wls:param-value> </wls:application-param>
ポリシーを削除しない場合は、OFFに設定します。設定しない場合、ポリシーは削除されます。デフォルトでは、アプリケーションのアンデプロイ時にポリシーは削除されません。
複数のアプリケーションで同じアプリケーション・ストライプを共有し、その中の1つをアンデプロイする場合には、この設定の使用を検討しますが、特定のアプリケーションについてjps.plicystore.ramovalをOFFに設定するには、アプリケーションのデプロイ時に、アプリケーション・ストライプを他のアプリケーションと共有して使用するかどうか把握しておく必要があります。
次の例で構成されているこのパラメータでは、デプロイ時または再デプロイ時にシステム・ポリシーおよびアプリケーション・ポリシーでプリンシパルをチェックするかどうかを指定します。
<wls:application-param> <wls:param-name>jps.policystore.migration.validate.principal</wls:param-name> <wls:param-value>option</wls:param-value> </wls:application-param>
optionは、trueまたはfalseを表します。
エンタープライズ・ユーザーおよびグループを検証する場合は、trueに設定します。プリンシパルが(アプリケーション・ポリシーまたはシステム・ポリシーで)アイデンティティ・ストアにないエンタープライズ・ユーザーまたはグループを参照している場合、警告がログに記録され、続行されます。チェックをスキップする場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。検証の警告は、サーバー・ログに記録されます。
次の例で構成されているこのパラメータでは、リスナー・クラスを指定します。
<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>
次の各項では、推奨事項と一般的なシナリオで必要な設定について説明します。
次の推奨事項は、ポリシーと資格証明の両方の移行に適用されます。
次の各項で説明されていない値の設定はお薦めしません。
アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つにデプロイする際にのみ、移行することを選択します。残りのデプロイでは、ポリシーおよび資格証明を移行しないことを選択します。これにより、ポリシーおよび資格証明は確実にアプリケーション・ストアからストアに1回のみ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。
デプロイ時にセキュリティ・データを移行する代替方法として、migrateSecurityStore WLSTコマンドを使用してポリシーおよび資格証明を移行することもできます。このコマンドの詳細は、第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。
アプリケーションでポリシーおよび資格証明がパッケージ化され、複数のサーバーにデプロイされる場合、$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlポリシー・ファイルが更新されるように管理サーバーを含める必要があります。
次の表に、移行をスキップするための設定を示します。
表23-2 ポリシーの移行をスキップするための設定
| デプロイ時にまたは再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
OFF |
ドメイン・ポリシーをそのまま保持する場合はポリシーの移行をスキップしますが、初めてアプリケーションをデプロイする場合はポリシーを移行します。
次の表に、ターゲット・ストアにないポリシーのみを移行するための設定を示します。
表23-3 ポリシーをマージして移行するための設定
| デプロイ時にまたは再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
MERGE |
|
jps.policystore.applicationid |
オプション。デフォルトはJavaサーブレット名またはEJB名です。 |
|
jps.apppolicy.idstoreartifact.migration |
オプション。エンタープライズ・アーティファクトを参照するポリシーの移行を除外する場合は |
|
jps.policystore.migration.validate.principal |
オプション。アプリケーションおよびシステム・ポリシーでエンタープライズ・ユーザーおよびロールを検証する場合は、 |
ポリシーが(前回のアンデプロイから)変更されるか、新しいポリシーを追加する場合は、再デプロイ時にマージによるポリシーの移行を選択します。
次の表に、一致するターゲット・ポリシーを上書きしてポリシーをすべて移行するための設定を示します。
表23-4 上書きによりポリシーを移行するための設定
| デプロイ時にまたは再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
OVERWRITE |
|
jps.policystore.migration.validate.principal |
オプション。アプリケーションおよびシステム・ポリシーでエンタープライズ・ユーザーおよびロールを検証する場合は、 |
すべてのポリシーを新しいポリシーで置き換える場合は、再デプロイ時に上書きによるポリシーの移行を選択します。
アンデプロイ時にはアプリケーション・ポリシーのみを削除できます。システム・ポリシーは削除されません。次の表に、アンデプロイ時にアプリケーション・ポリシーを削除するための設定を示します。
表23-5 ポリシーを削除するための設定
| アンデプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.removal |
設定しない(デフォルト) |
アンデプロイ時にポリシーが削除されるストライプは、デプロイ時または再デプロイ時に指定したストライプによって決まります。元のものとは異なるストライプを指定してアプリケーションを再デプロイすると、元のストライプのポリシーは削除されません。
次の表に、アプリケーションのアンデプロイ時にポリシーの削除を無効にするための設定を示します。
表23-6 ポリシーの削除を無効にするための設定
| アンデプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.removal |
OFF |
削除されるデータと削除されないデータ
ポリシーを自動的に移行および削除するように構成されているmyAppアプリケーションを考えてみます。次の(アプリケーションのjazn-data.xmlファイルの)例では、アプリケーションのデプロイ時に移行されるポリシーとアプリケーションのアンデプロイ時に削除されないポリシーを示します。
<jazn-data>
<policy-store>
<applications>
<!-- The contents of the following element application is migrated
to the element policy-store in domain system-jazn-data.xml;
when myApp is undeployed with EM, it is removed from security store -->
<application>
<name>myApp</name>
<app-roles>
<app-role>
<class>oracle.security.jps.service.policystore.SomeRole</class>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<members>
<member>
<class>oracle.security.somePath.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>applicationDeveloperRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>loadPolicy</name>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
<!-- The following codesource grant is migrated to the element
jazn-policy in domain system-jazn-data.xml; when myApp is undeployed
with FMC, it is not removed from security store -->
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/Foo.ear/-</url>
</codesource>
</grantee>
<permissions>
<permission> <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=*,keyName=*</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</jazn-data>
次の表に、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーを移行するための設定を示します。MERGEまたはOVERWRITEの操作は、アプリケーション・ポリシーがセキュリティ・ストアにまだ存在していない場合にのみ実行されます。
表23-7 静的デプロイメントでポリシーを移行するための設定
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
MERGEまたはOVERWRITE |
次の表に、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーの移行をスキップするための設定を示します。
ファイル資格証明ストアはcwallet.ssoファイルです。このファイルの場所は、jps-config.xmlファイルで<serviceInstance>要素を使用して指定します。
<serviceInstance name="credstore" provider="credstoressp"> <property name="location" value="myCredStorePath"/> </serviceInstance>
|
関連項目: 『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項 『Oracle Fusion Middlewareの管理』の「キーストア、ウォレットおよび証明書の管理」 |
デプロイ時のアプリケーション資格証明の移行は、META-INF/weblogic-application.xmlファイルで指定するパラメータを使用して制御します。Fusion Middleware Controlを使用してアプリケーションを管理しない場合は、このような構成を手動で入力する必要があります。
システム・プロパティjps.deployment.handler.disabledをtrueに設定し、weblogic-application.xmlアプリケーション・ファイルの設定に関係なく、すべてのアプリケーションに対してデプロイ時のポリシーおよび資格証明の移行を無効にします。
管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ポリシーおよび資格証明がパッケージ化されているアプリケーションをデプロイする場合は、管理対象サーバーと管理サーバーによって管理されているデータが最終的に同期しないため、ライフ・サイクル・リスナーを使用してデプロイ時の移行を制御しないでください。かわりに、migrateSecurityStoreコマンドを使用して、ポリシーおよび資格証明をセキュリティ・ストアに移行します。このコマンドの詳細は、第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。
資格証明の移行および削除を構成するパラメータは、次のとおりです。
次の例で構成されているこのパラメータでは、セキュリティ・ストアで資格証明を移行してマージするのか、上書きするのかを指定します。
<wls:application-param> <wls:param-name>jps.credstore.migration</wls:param-name> <wls:param-value>Option</wls:param-value> </wls:application-param>
Optionは、MERGE、OVERWRITEまたはOFFを表します。
移行しない場合は、OFFに設定します。資格証明をマージして移行する場合は、MERGEに設定します。資格証明を上書きして移行する場合は、OVERWRITEに設定します。デフォルト値はMERGEです。
次の各項では、推奨事項と一般的なシナリオで必要な設定について説明します。
アプリケーションのアンデプロイ時に、アプリケーション資格証明は削除されません。
次の表に、移行しないための設定を示します。
次の表に、ターゲット・ストアにない資格証明のみの移行に必要な設定を示します。
次の各項では、system-jazn-data.xmlファイルの<permission>要素内の<class>、<name>および<actions>の各要素で使用する値について説明します。
ポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。
セキュリティ・ストアのパーミッション・クラスは、次のとおりです。
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
特定のアプリケーションにパーミッションが適用される場合は、対応するname要素に対して次のパターンを使用します。appStripeNameでは、特定のアプリケーションを指定します。
context=APPLICATION,name=appStripeName
パーミッションがすべてのアプリケーションに適用される場合、次の名前パターンを使用します。
context=APPLICATION,name=*
パーミッションがすべてのアプリケーションおよびシステム・ポリシーに適用される場合、次の名前パターンを使用します。
context=SYTEM
actions要素で使用できる値は、次のとおりです(*は任意のアクションを表します)。
* createPolicy getConfiguredApplications getSystemPolicy getApplicationPolicy createApplicationPolicy deleteApplicationPolicy grant revoke createAppRole alterAppRole removeAppRole addPrincipalToAppRole removePrincipalFromAppRole hasPermission containsAppRole
次の例では、ポリシーを作成する権限付与と実行時チェックを実行する権限付与を示します。
grant {
permission oracle.security.jps.service.policystore.PolicyStoreAccessPermission
"context=APPLICATION,name=*", "*";
permission oracle.security.jps.service.policystore.PolicyStoreAccessPermission
"context=SYSTEM,adminresource=ApplicationPolicy,instancename=*", "*"; oracle.security.jps.JpsPermission "AppSecurityContext.setApplicationID.*";
};
grant codebase "file:${opss.lib.location}/-" { permission java.security.AllPermission;
};
資格証明ストアのパーミッション・クラスは、oracle.security.jps.service.credstore.CredentialAccessPermissionクラスです。
マップとそのマップ内の特定のキーにパーミッションが適用される場合は、対応するname要素に対して次のパターンを使用します。myMapおよびmyKeyでは、特定の資格証明を指定します。
context=SYSTEM,mapName=myMap,keyName=myKey
マップとそのマップ内のすべてのキーにパーミッションが適用される場合は、次のパターンを使用します。myMapでは、特定のマップを指定します。
context=SYSTEM,mapName=myMap,keyName=*
actions要素で使用できる値は、次のとおりです(*は任意のアクションを表します)。
* read write update delete
汎用パーミッション・クラスは、oracle.security.jps.JpsPermissionクラスです。
oracle.security.jps.callback.IdentityCallbackコールバック・インスタンスによって実行されたアサーションにパーミッションが適用される場合は、対応する<name>要素に対して次のパターンを使用します。
IdentityAssertion
actions要素で使用できる唯一の値は、executeです。
ドメイン・リポジトリへの接続およびアクセスに必要な資格証明は、cwallet.ssoファイルに指定し、jps-config.xmlファイルで構成します。このような資格証明は、ブートストラップ資格証明と呼ばれ、常にファイルで保持されます。
ブートストラップ資格証明は、bootstrap_credstore_contextというコンテキストで構成されます。
<serviceInstances>
...
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>
...
</serviceInstances>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
cwallet.ssoファイルは、bootstrapディレクトリにあることを前提としています。
bootstrap.security.principal.keyプロパティとbootstrap.security.principal.mapプロパティでは、ブートストラップのマップおよびキーを指定します。
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> ... <property value="bootstrapKey" name="bootstrap.security.principal.key"/> ... </serviceInstance>
bootstrap.security.principal.mapプロパティを指定しないと、デフォルトのBOOTSTRAP_JPSに設定されます。
ブートストラップ資格証明を変更または追加するには、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のmodifyBootStrapCredentialに関する項およびaddBootStrapCredentialに関する項を参照してください。
