| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
この章では、Oracle ADFセキュリティを使用せずにOPSSを使用するJava EEアプリケーションでお薦めする手動による構成とパッケージ化について説明します。ただし、一部のトピックは、Oracle ADFアプリケーションにも当てはまります。
ここで示す情報は、Oracle JDeveloper環境の外部でJava EEアプリケーションを構成し、パッケージ化する開発者を対象としています。
この章の内容は次のとおりです。
開発時、デプロイ時、実行時およびデプロイ後のアプリケーション管理に関係するファイルは、次のとおりです。
OPSSはサーブレット・フィルタJpsFilterとEJBインターセプタJpsInterceptorを備えています。前者はWARファイルでパッケージ化されるファイルweb.xmlで構成され、後者はJARファイルでパッケージ化されるファイルejb-jar.xmlで構成されます。アプリケーションMbeansがアクセスするストライプをファイルweb.xmlで構成する方法も、OPSSによって提供されます。詳細は、「アプリケーションMbeansのアプリケーション・ストライプの構成」を参照してください。
これらはいずれもWebLogicとWebSphereで利用可能です。利用できる構成は、次に示すように、サーバー・プラットフォームに応じてやや異なります。
WebLogicでは、JpsFilterはデフォルトのパラメータ値で自動的に設定され、そのまますぐに使用できるため、デプロイメント・ディスクリプタで明示的に構成する必要はありません。デフォルト値以外の値を設定する場合にのみ手動構成が必要です。JpsInterceptorは手動で構成する必要があります。
WebSphereでは、JpsFilterとJpsInterceptorをいずれも手動で構成する必要があります。
|
注意: Oracle ADFアプリケーションに必要なサーブレット・フィルタ( この項で説明している手動による構成は、次で説明しているOPSS機能をOracle JDeveloper環境の外部で使用してJava EEアプリケーションをパッケージ化または構成する場合にのみ必要です。 |
OPSSでは、MBeansが使用するアプリケーション・ストライプの指定が可能です。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。
サーブレット・フィルタとEJBインターセプタは同じパラメータ・セットを使用して構成できます。これらのパラメータによって、サーブレットまたはEnterprise Java Bean (EJB)の次の機能をカスタマイズできます。
アプリケーション名(アプリケーション・ストライプと呼ぶ方がふさわしく、アプリケーションのweb.xmlファイル内で指定することも可能)は、適用可能なポリシー・セットを決定するために、実行時に使用されます。アプリケーション・ストライプは、指定しない場合、アプリケーションID(アプリケーション名が含まれる)がデフォルト値として使用されます。
アプリケーション・ストライプでは、ポリシー・ストア内のポリシーのサブセットが定義されます。アプリケーションでそのポリシー・サブセットを使用する場合は、そのアプリケーション名と同じ文字列を使用してアプリケーション・ストライプを定義します。この方法によって、ポリシー・ストア内のポリシーの同じサブセットを複数のアプリケーションで使用できます。
匿名ロールと認証ロールの機能は、「匿名ユーザーとロール」および「認証ロール」の項で説明します。
サーブレットでは、要素<filter-mapping>でフィルタの使用を指定します。このような要素は、サーブレットごと、フィルタごとに1つ必要です。
EJBでは、要素<interceptor-binding>でインターセプタの使用を指定します。このような要素は、EJBごと、インターセプタごとに1つ必要です。詳細は、「インターセプタ構成構文」を参照してください。
使用可能なパラメータの概要は、「フィルタおよびインターセプタ・パラメータの概要」を参照してください。
この値は、次のパラメータで制御します。
application.name
このパラメータの指定はオプションです。指定時には大文字と小文字が区別されます。指定しないと、デフォルトでデプロイするアプリケーションの名前になります。この値によって、そのアプリケーションが使用する、ポリシー・ストア内のポリシーのサブセットが定義されます。
アプリケーション・ストライプを指定する1つの方法は、filter要素内に配置することです。次に例を示します。
<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>
もう1つの指定方法は、context-param要素内に配置することです。次に例を示します。
<context-param> <description>JPS custom stripe id</description> <param-name>application.name</param-name> <param-value>stripeid</param-value> </context-param>
この最後の構成が必要になるのは、アプリケーション・ポリシー・ストアにアクセスするMBeansがアプリケーションに含まれ、アプリケーション名がアプリケーション・ストライプ名と異なる場合です。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。
構成例
サーブレットの場合およびEJBの場合のこのパラメータの構成を、次の2つのサンプルで示します。
web.xmlファイルの次のフラグメントは、後続の認可チェックで正しく評価されるように、フィルタを使用して2つのサーブレット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の設定と、EJB 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>
この例で、インターセプタ構成構文の要件がどのように満たされているかに注意してください。
サブジェクトへのアプリケーション・ロールの追加は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。
add.application.roles
サブジェクトにアプリケーション・ロールを追加するには、このプロパティをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。
アプリケーション・ロールのプリンシパル・クラスは、次のとおりです。
oracle.security.jps.service.policystore.ApplicationRole
サーブレットにおける匿名の使用は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。
enable.anonymous remove.anonymous.role
EJBの場合は、匿名ユーザーおよび匿名ロールの使用が常に有効であるため、前述の2番目のパラメータのみを使用できます。
サーブレットの場合、匿名ユーザーの使用を有効にするには最初のプロパティをtrueに設定し、無効にするにはfalseに設定します。デフォルト値はtrueです。
サブジェクトから匿名ロールを削除するには2番目のプロパティをtrueに設定し、保持するにはfalseに設定します。デフォルト値はfalseです。匿名ユーザーおよび匿名ロールは、通常は認証後に削除し、認証後に保持するのは特殊な場合のみです。
匿名ユーザーのデフォルト名とプリンシパル・クラスは、次のとおりです。
anonymous oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl
匿名ロールのデフォルト名とプリンシパル・クラスは、次のとおりです。
anonymous-role oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
web.xmlファイルの次のフラグメントは、これらのパラメータの設定およびサーブレットMyServletによるフィルタ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ファイルの次のフラグメントは、第2パラメータに対するfalseの設定と、Enterprise Java Bean 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>
次のフラグメントは、プログラム的に匿名サブジェクトおよびサブジェクトの匿名ロールと匿名ユーザーにアクセスする方法を示しています。
import oracle.security.jps.util.SubjectUtil; // The next call returns the anonymous subject javax.security.auth.Subject subj = SubjectUtil.getAnonymousSubject(); // The next call extracts the anonymous role from the subject java.security.Principal p = SubjectUtil.getAnonymousRole(javax.security.auth.Subject subj) // Remove or retain anonymous role ... // The next call extracts the anonymous user from the subject java.security.Principal p = SubjectUtil.getAnonymousUser(javax.security.auth.Subject subj) // Remove or retain anonymous user ...
認証ロールの使用は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。
add.authenticated.role
認証ロールをサブジェクトに追加するにはこのパラメータをtrueに設定し、追加しない場合はfalseに設定します。デフォルト値はtrueです。
認証ロールのデフォルト名とプリンシパル・クラスは、次のとおりです。
authenticated-role oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl
web.xmlファイルの次のフラグメントは、このパラメータの設定およびサーブレットMyServletによるフィルタ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です。これらの値によってメソッドcheckPermissionの動作を制御する方法の詳細は、第20.3.3.1項「メソッドcheckPermissionの使用方法」を参照してください。
このパラメータを使用するサーブレットおよびEJBの構成を、次の2つのサンプルで示します。
web.xmlファイルの次のフラグメントは、このパラメータの設定およびサーブレットMyServletによるフィルタ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>
ejb-jar.xmlファイルの次のフラグメントは、このパラメータに対するdoAsの設定と、Enterprise Java Bean MyEjbによるインターセプタ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>が必要であり、これをインターセプタのクラスと同じクラスに指定する必要があります(要素<injection-target-class>内)。また、ドットをアンダースコアに置換した文字列として再書き込みしたパラメータ名も必要です(要素<injection-target-name>内)。
インターセプタのEJBへのバインディングは、EJB名とインターセプタのクラスによって指定します。つまり、インターセプタは、名前ではなくそのクラスによって参照されます。
次の表は、JpsFilterおよびJpsInterceptorによって使用されるパラメータの説明をまとめたものです。
表21-1 JpsFilterとJpsInterceptorのパラメータの概要
| パラメータ名 | 値 | デフォルト | 機能 | 注意 |
|---|---|---|---|---|
|
application.name |
任意の有効な文字列。値では大文字と小文字が区別されます。 |
デプロイされるアプリケーションの名前 |
サーブレットまたはEJBによって使用されるポリシーのサブセットを指定します。 |
ポリシー・ストア内の同じポリシーのサブセットをいくつかのサーブレットまたはEJBで共有する場合は、指定する必要があります。 |
|
add.application.roles |
TRUEまたはFALSE |
TRUE |
アプリケーション・ロールをサブジェクトに追加します。 |
TRUEがデフォルトなので、(FALSEに)設定する必要があるのは、アプリケーションがアプリケーション・ロールをサブジェクトに追加しない場合のみです。 |
|
enable.anonymous |
TRUEまたはFALSE |
TRUE |
サブジェクトで匿名ユーザーを有効または無効にします。 |
TRUEに設定すると、匿名ユーザーおよび匿名ロールとともにサブジェクトが作成されます。 |
|
remove.anonymous.role |
TRUEまたはFALSE |
FALSE |
認証後にサブジェクトのアプリケーション・ロールを保持または削除します。 |
サーブレットでのみ利用可能です。EJBでは、匿名ロールは常にサブジェクトから削除されます。FALSEに設定すると、匿名ロールが、認証後、サブジェクトで保持され、TRUEに設定すると、認証後、削除されます。 |
|
add.authenticated.role |
TRUEまたはFALSE |
TRUE |
サブジェクト内で認証ロールの追加を許可します。 |
TRUEがデフォルト値なので、(FALSEに)設定する必要があるのは、認証ロールをサブジェクトに含めない場合のみです。 |
|
oracle.security.jps.jaas.mode |
doAsPrivileged doAs Off undefined subjectOnly |
doAsPrivileged |
JAASモードを設定します。 |
アプリケーションが次の条件を満たす場合:
ポリシー・ストアへのアクセスおよび認可チェックを実行するMBeansを含む。
アプリケーション・ストライプ名がアプリケーション名と異なる。
MBeanがドメイン・セキュリティ・ストアのアプリケーション・ストライプにアクセスするために、ファイルweb.xmlのグローバル・パラメータ(またはコンテキスト・パラメータ)application.nameでストライプ名を指定する必要があります。次に例を示します。
<context-param> <description>JPS custom stripe id</description> <param-name>application.name</param-name> <param-value>stripeid</param-value> </context-param>
|
注意: Oracle JDeveloperを使用している場合、このツールによって適切なクラスが選択されます。したがって、次に説明する構成は、ポリシーがOracle JDeveloper環境外で入力された場合にのみ必要です。 |
アプリケーション・ロールのメンバー内で指定されるクラスは、他のアプリケーション・ロールのクラスか、次のいずれかにする必要があります。
weblogic.security.principal.WLSUserImpl weblogic.security.principal.WLSGroupImpl
次のフラグメントは、エンタープライズ・グループの指定におけるこれらのクラスの使用を示しています(太字の部分)。
|
重要: アプリケーション・ロール名では、大文字小文字が区別されません(次のサンプルの エンタープライズ・ユーザーおよびグループ名では、大文字小文字が区別されます(次のサンプルの 大文字小文字の区別に関する情報は、第L.4項「パーミッションの付与または取消の失敗 - 大文字と小文字の不一致」を参照してください。 |
<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>
この項では、WebLogic Application ServerまたはWebSphere Application ServerにデプロイするサーブレットまたはEJB(カスタムのポリシーと資格証明を使用)のパッケージ化要件について説明します。
アプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。
サーブレットは、構成ファイルweb.xmlを含むWARファイルでパッケージ化されます。EJBは、構成ファイルejb-jar.xmlを含むWARファイルでパッケージ化されます。WARファイルでは、フィルタJpsFilter(サーブレット用)またはインターセプタJpsInterceptor(EJB用)の構成を、対応する構成ファイルに含める必要があります。
次の説明は、サーブレットのパッケージ化およびファイルweb.xmlでのJpsFilterの構成を考慮していますが、EJBのパッケージ化およびファイルejb-jar.xmlでのJpsInterceptorの構成にも同等に適用できます。
|
重要: 現在、EARファイル内にあるすべての |
JpsFilterおよびJpsInterceptorの詳細は、「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
カスタムのポリシーおよび資格証明を使用するJava EEアプリケーションに対するパッケージ化の要件と前提条件は、次のとおりです。
デプロイされるアプリケーションは、1つのEARファイルにパッケージ化する必要があります。
EARファイルには、ファイルMETA-INF/jazn-data.xmlが1つ含まれている必要があります。このファイルで、アプリケーションのポリシーおよびロールが指定され、これらはそのEARファイル内のすべてのコンポーネントに同等に適用されます。
EARファイルには、1つ以上のWARファイルを含めることができます。
EARファイル内の各WARまたはJARファイルには、web.xml(またはejb-jar.xml)が1つ含まれている必要があります。ここで、JpsFilter(またはJpsInterceptor)が構成され、すべてのEARファイル内のこのような構成は同一である必要があります。
cwallet.ssoファイル内のコンポーネント資格証明は、EARファイルにパッケージ化できます。これらの資格証明は、Oracle Enterprise Manager Fusion Middleware Controlを使用してアプリケーションをデプロイする際に資格証明ストアに移行できます。
|
注意: コンポーネントで、他のコンポーネントとは異なるフィルタの構成が必要な場合は、別個のEARファイルにパッケージ化してデプロイする必要があります。 |
アプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、ポリシーはEARディレクトリにあるこのXMLファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定のポリシーを指定するには、前述の指定のようにそのコンポーネントを独自のjazn-data.xmlファイルで別個のEARファイルにパッケージ化する必要があります。他のポリシー・パッケージの組合せは、このリリースではサポートされていません。最上位のjazn-data.xml以外のポリシー・ファイルは無視されます。
アプリケーションの資格証明は、cwallet.ssoという名前のファイルで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、資格証明はそのEARディレクトリにあるcwallet.ssoファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定の資格証明を指定するには、前述の指定のようにそのコンポーネントを独自のcwallet.ssoファイルで別個のEARファイルにパッケージ化する必要があります。他の資格証明パッケージの組合せはこのリリースではサポートされていません。最上位のcwallet.sso以外の資格証明ファイルは無視されます。
この項では、Oracle JDeveloper環境の外部で開発されたJava EEアプリケーションのために開発者が手動で実行するいくつかの構成について説明します。この項の内容は次のとおりです。
デプロイでのアプリケーション・ポリシーの移行は、いくつかのパラメータによって制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。
WebSphereでのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
アプリケーションのデプロイまたは再デプロイでポリシーの移行を制御するパラメータおよびアンデプロイでポリシーの削除を制御するパラメータは、次のとおりです。
移行
リスナー
プリンシパルの検証
移行のターゲット(アプリケーション・ストライプ)
前述の各パラメータの構成と機能を、次に説明します。
|
注意: Fusion Middleware Controlでは、アプリケーションのデプロイ、再デプロイまたはアンデプロイの際に、これらのパラメータのほとんどを設定できます。詳細は、第6.2.1項「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。 次に説明する構成は、Fusion Middleware Controlを使用しないでアプリケーションを管理する場合にのみ、手動で入力する必要があります。 管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ファイルベースのストアを使用するアプリケーションをデプロイする場合は、ライフ・サイクル・リスナーを使用しないでください。使用した場合、管理対象サーバーと管理サーバーによって管理されているデータが一致せず、セキュリティが期待どおりに機能しない場合があります。ライフ・サイクル・リスナーを使用するかわりにOPSSスクリプト この注意点は、ファイルベースのストアを使用する場合にのみ適用されます。 |
このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアに存在する一致するポリシーをマージするのか上書きするのかを指定します。
WebLogicでは、次のフラグメントに示すように構成します。
<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のいずれかを表します。
WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
OFFに設定すると、ポリシーの移行が行われません。MERGEに設定すると、移行が行われ、既存のポリシーとマージされます。OVERWRITEに設定すると、移行が行われ、既存のポリシーが上書きされます。デフォルト値(デプロイ時)は、MERGEです。
このパラメータでは、ポリシーの移行先であるターゲット・ストライプを指定します。
WebLogicでは、次のフラグメントに示すように構成します。
<wls:application-param> <wls:param-name>jps.policystore.applicationid</wls:param-name> <wls:param-value>myApplicationStripe</wls:param-value> </wls:application-param>
WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
任意の有効な文字列をこのパラメータの値に設定できます。このパラメータの値を指定しない場合は、アプリケーション名とバージョン、すなわちapplication_name#versionに基づいて、Oracle WebLogic Serverがストライプ名を選択します。
このパラメータの値は、JpsServlet用に(ファイルweb.xmlで)、またはJpsInterceptor用に(ファイルejb-jar.xmlで)指定されているapplication.name値に一致させる必要があります。詳細は、「アプリケーション名(ストライプ)」を参照してください。
weblogic-application.xmlから選択された値はデプロイ時に使用され、web.xmlまたはejb-jar.xmlから選択された値は実行時に使用されます。
JpsApplicationLifecycleListener
このパラメータはWebLogicでのみサポートされています。次のフラグメントに示すように設定する必要があります。
<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>
jps.apppolicy.idstoreartifact.migration
このパラメータはWebLogicでのみサポートされています。このパラメータでは、エンタープライズ・ユーザーまたはグループに対するアプリケーション・ロールやパーミッションの付与など、エンタープライズ・ユーザーまたはグループに対する参照の移行をポリシーの移行から除外するかどうかを指定します。そのため、アプリケーション・ポリシーのみの移行が可能となり、有効にすると、エンタープライズ・グループまたはユーザーへのアプリケーション・ロールのマッピングが、移行時に無視されます。
これは、次のフラグメントに示すように構成されます。
<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に設定してアプリケーションをデプロイする(アプリケーションに固有でないポリシーの移行が除外される)場合、アプリケーションをドメイン内で使用する前に、管理者はFusion Middleware ControlまたはWebLogic管理コンソールを使用してアプリケーション・ロールからエンタープライズ・グループまたはユーザーへのマッピングを実行する必要があります。 この設定により、アプリケーション・ロールに対する管理者の制御がいかに強化されているかに注意してください。 |
次の例は、同じjazn-data.xmlファイルのフラグメントを示しています。アプリケーションEARファイルにパッケージ化されるこのファイルでは、アプリケーションの認可ポリシーを示します。
ファイル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>
このパラメータでは、アンデプロイ時にポリシーの削除を実行しないかどうかを指定します。
WebLogicでは、次のフラグメントに示すように構成します。
<wls:application-param> <wls:param-name>jps.policystore.removal</wls:param-name> <wls:param-value>OFF</wls:param-value> </wls:application-param>
WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
設定する場合は、このパラメータの値をOFFにする必要があります。デフォルトでは、このパラメータは設定されません。
OFFに設定した場合、ポリシーは削除されません。設定しない場合、ポリシーは削除されます。
同一のアプリケーション・ストライプを複数のアプリケーションで共有する場合は、前述の設定を考慮する必要があります。アプリケーションのアンデプロイ時は、他のアプリケーションが共通のポリシー・セットを使用している可能性があるため、アプリケーション・ポリシーを削除しないよう選択します。
|
注意: 特定のアプリケーションに対してこのパラメータをOFFに設定する場合は、そのアプリケーションのデプロイ時にアプリケーション・ストライプを他のアプリケーションと共有するように指定したかどうかを確認しておく必要があります。 |
jps.policystore.migration.validate.principal
このパラメータはWebLogicでのみサポートされています。このパラメータでは、デプロイ時または再デプロイ時に、システムおよびアプリケーションのポリシー内のプリンシパルをチェックするかどうかを指定します。
これは、次のフラグメントに示すように構成されます。
<wls:application-param> <wls:param-name>jps.policystore.migration.validate.principal</wls:param-name> <wls:param-value>TRUE</wls:param-value> </wls:application-param>
設定する場合は、このパラメータの値をTRUEまたはFALSEにする必要があります。
TRUEに設定すると、エンタープライズ・ユーザーおよびグループの妥当性がシステムによってチェックされます。(アプリケーションまたはシステム・ポリシー内の)プリンシパルがアイデンティティ・ストアにないエンタープライズ・ユーザーまたはグループを参照した場合は、警告が発行されます。FALSEに設定すると、このチェックがスキップされます。
このパラメータを設定しなかった場合のデフォルト値は、FALSEです。
検証エラーはサーバー・ログに記録されます。検証エラーが発生しても動作は停止しません。
この項では、アプリケーション・ポリシーの管理時に次のような動作を実行するのに必要な設定について説明します。
予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。詳細は、「推奨事項」を参照してください。
どの動作も、Fusion Middleware Controlによるアプリケーションのデプロイ時、再デプロイ時またはアンデプロイ時に、Fusion Middleware Controlで指定できます。
次のマトリクスは、移行を行わない設定を示しています。
表21-2 ポリシーの移行をスキップするための設定
| デプロイ時または再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
OFF |
通常、ドメイン・ポリシーをそのまま保持する場合はアプリケーションの再デプロイ時にポリシーの移行をスキップしますが、初めてアプリケーションをデプロイするときはポリシーを移行します。
次のマトリクスは、ターゲット・ストアにないポリシーのみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。
表21-3 マージによりポリシーを移行するための設定
| デプロイ時または再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
MERGE |
|
[jps.policystore.applicationid] |
適切な文字列に設定します。デフォルト値はサーブレット名またはEJB名です。 |
|
[jps.apppolicy.idstoreartifact.migration] |
エンタープライズ・アーティファクトを参照するポリシーの移行を除外する場合はFALSE、除外しない場合はTRUEに設定します。デフォルト値はTRUEです。 |
|
[jps.policystore.migration.validate.principal] |
アプリケーション・ポリシーおよびシステム・ポリシーでエンタープライズのユーザーとロールを検証する場合は、TRUEに設定します。それ以外の場合は、FALSEに設定します。指定しなかった場合は、デフォルトのFALSEが設定されます。 |
ポリシーが変更され、これを既存のポリシーに追加する場合は通常、再デプロイ時にマージによるポリシーの移行を選択します。
次のマトリクスは、一致するターゲット・ポリシーを上書きして全ポリシーを移行する設定を示しています(オプション・パラメータは大カッコで囲んであります)。
表21-4 上書きによりポリシーを移行するための設定
| デプロイ時または再デプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
OVERWRITE |
|
[jps.policystore.migration.validate.principal] |
アプリケーション・ポリシーおよびシステム・ポリシーでエンタープライズのユーザーとロールを検証する場合は、TRUEに設定します。それ以外の場合は、FALSEに設定します。指定しなかった場合は、デフォルトのFALSEが設定されます。 |
新しいポリシー・セットで既存のポリシーを置き換える場合は通常、再デプロイ時に上書きによるポリシーの移行を選択します。オプション・パラメータjps.policy.migration.validate.principalは、必要な場合、手動で設定する必要があります。
システム・ポリシー内でコード・ソースの付与が削除されないため、アンデプロイ時のアプリケーション・ポリシーの削除は制限されています。詳細は、「削除されるデータと削除されないデータ」を参照してください。
次のマトリクスは、アンデプロイ時にポリシーを削除する設定を示しています。
表21-5 ポリシーを削除するための設定
| アンデプロイ時に有効 | |
|---|---|
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.removal |
設定しない(デフォルト) |
|
注意: アンデプロイ時に削除するポリシーは、デプロイ時または再デプロイ時にアプリケーションで指定したストライプによって決まります。元のものとは異なるストライプを指定して再デプロイしたアプリケーションでは、元のストライプのポリシーは削除されません。 |
次のマトリクスは、アンデプロイ時にアプリケーション・ポリシーを削除しない設定を示しています。
|
注意: 特定のアプリケーションに対してこのパラメータをOFFに設定する場合は、そのアプリケーションのデプロイ時にアプリケーション・ストライプを他のアプリケーションと共有するように指定したかどうかを確認しておく必要があります。 |
削除されるデータと削除されないデータ
ポリシーの移行と削除が自動的に実行されるように構成されているアプリケーションmyAppを考えます。アプリケーションのjazn-data.xmlファイル(アプリケーションEARファイルにパッケージ化されている)の次のフラグメントは、Fusion Middleware Controlによってアプリケーションがデプロイされるときに移行されるアプリケーション・ポリシーと、Fusion Middleware Controlによってアプリケーションがアンデプロイされるときに削除されるアプリケーション・ポリシーおよび削除されないアプリケーション・ポリシーを示しています。
<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 domain 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 codebase application grant is migrated to the element
jazn-policy in domain system-jazn-data.xml; when myApp is undeployed
with EM, it is not removed from domain 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>
要約すると、削除されるデータに関しては、次の点が重要です。
要素<application>内のデータはすべて、アンデプロイ時に自動的に削除できます。LDAPベースのポリシー・ストアの場合、アプリケーション・スコープの認可ポリシー・データ・ノードはクリーンアップされます。
要素<jazn-policy>内のデータはすべて、アンデプロイ時に自動的に削除できません。
表21-7は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーを移行する設定を示しています。MERGEまたはOVERWRITEの操作は、アプリケーション・ポリシーがドメインにまだ存在していない場合にのみ実行できます。
表21-7 静的デプロイメントでポリシーを移行するための設定
|
JpsApplicationLifecycleListener |
設定する |
|
jps.policystore.migration |
MERGEまたはOVERWRITE |
表21-8は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーの移行をスキップする設定を示しています。
次の推奨事項を覚えておいてください。
LDAPベースのポリシー・ストアを使用し、アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つに対してのみ移行を行うよう選択します。残りのデプロイでは、ポリシーを移行しないよう選択します。これにより、ポリシーはアプリケーション・ストアからポリシー・ストアに一度のみ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。
同じアプリケーションで同一のノードに対するポリシーの移行を複数回(たとえば異なる管理対象サーバー上で)試行すると、ポリシーの移行が失敗する場合があります。別の方法として、OPSSスクリプトmigrateSecurityStoreを使用して、デプロイ・プロセスの外部でポリシー・データをストアに移行することもできます。
ただし、アプリケーションが複数のサーバーにデプロイされ、ポリシー・ストアがファイルベースである場合、移行によってポリシー・ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlを更新するには、デプロイに管理サーバーを含める必要があります。
ウォレットベースの資格証明ストアのコンテンツは、cwallet.ssoという名前のファイルで定義します。ウォレットベースの資格証明ストアはファイルベースの資格証明ストアとも呼ばれます。
ウォレットの作成手順は、『Oracle Fusion Middleware管理者ガイド』のウォレットの一般的な操作に関する項を参照してください。
ファイルcwallet.ssoの場所は、次の例のように、構成ファイルjps-config.xmlの要素<serviceInstance>で指定します。
<serviceInstance name="credstore" provider="credstoressp"> <property name="location" value="myCredStorePath"/> </serviceInstance>
他のタイプの資格証明の格納については、『Oracle Fusion Middleware管理者ガイド』の「キーストローク、ウォレットおよび資格証明の管理」の章を参照してください。
デプロイ時、アプリケーションの資格証明の移行は、いくつかのパラメータで制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。
WebSphereでのこれらのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
資格証明の移行を制御するパラメータは、jps.credstore.migrationです。リスナーは、JpsApplicationLifecycleListener - Credentialsです。
このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアに存在する一致する資格証明をマージするのか上書きするのかを指定します。
WebLogicでは、次のフラグメントに示すように構成します。
<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value>behaviorValue</wls:param-value>
</wls:application-param>
WebSphereでのこのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
設定する場合、このパラメータの値は、MERGE、OVERWRITE、OFFのいずれかである必要があります。値OVERWRITEは、WebLogicのみを対象とし、またこのサーバーが開発モードで稼働している場合にのみ使用できます。
設定しない場合、資格証明の移行はオプションMERGEを使用して行われます。
JpsApplicationLifecycleListener - 資格証明
このリスナーはWebLogicでのみサポートされています。次のフラグメントに示すように構成します。
<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>
この項では、アプリケーション資格証明の移行時に次のような動作を実行するのに必要な手動設定について説明します。
予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。
移行のターゲットがLDAPベースの資格証明ストアの場合、アプリケーションは1つの管理対象サーバーまたはクラスタにのみデプロイしてください。そうしないと、アプリケーション資格証明が予期したとおりに動作しない場合があります。
|
注意: 資格証明は、アプリケーションをアンデプロイしても削除できません。アプリケーションとパッケージ化した時点から資格証明が有効になっている可能性がありますが、そのアプリケーションをアンデプロイしても資格証明は削除されません。 |
次のマトリクスは、移行を行わない設定を示しています。
次のマトリクスは、ターゲット・ストアにない資格証明のみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。
パーミッションのコンポーネントを、system-jazn-data.xmlファイルの次のスニペットで示します。
<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
</class>
<name>context=SYSTEM</name>
<actions>getConfiguredApplications</actions>
</permission>
<permission>
<class>
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
</class>
<name>context=APPLICATION,name=*</name>
<actions>getApplicationPolicy</actions>
</permission>
</permissions>
</grant>
この項では、<permission>内の要素<class>、<name>および<actions>でサポートされている値について説明します。
クラス名:
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
特定のアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。
context=APPLICATION,name=appStripeName
すべてのアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。
context=APPLICATION,name=*
すべてのアプリケーションおよびシステム・ポリシーにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。
context=APPLICATION
対応する要素<actions>で使用できる値のリストを次に示します(*は許可された任意のアクションを表します)。
* createPolicy getConfiguredApplications getSystemPolicy getApplicationPolicy createApplicationPolicy deleteApplicationPolicy grant revoke createAppRole alterAppRole removeAppRole addPrincipalToAppRole removePrincipalFromAppRole hasPermission containsAppRole
クラス名:
oracle.security.jps.service.credstore.CredentialAccessPermission
特定のマップとそのマップ内の特定のキーにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。
context=SYSTEM,mapName=myMap,keyName=myKey
特定のマップとそのマップ内のすべてのキーにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。
context=SYSTEM,mapName=myMap,keyName=*
対応する要素<actions>で使用できる値のリストを次に示します(*は許可された任意のアクションを表します)。
* read write update delete
このトピックは、LDAPベースのストアに対する再関連付けを実行する際にOracle Fusion Middleware Controlを使用しない管理者を対象としています。
管理者がLDAPディレクトリに接続およびアクセスするために必要な資格証明は、cwallet.ssoという別個のファイル(ブートストラップ資格証明)で指定し、ファイルjps-config.xmlで構成する必要があります。これらの資格証明は、LDAP再関連付けプロセスの後に格納されます。ブートストラップ資格証明は常にファイルベースです。
LDAPベースのポリシー・ストアまたは資格証明ストアのすべてのインスタンスでは、次に示すように<jpsContex>要素で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にあると想定されています。
LDAPベースのポリシー・ストアまたは資格証明ストアのインスタンスは、次のLDAPベースのポリシー・ストアのインスタンスに示すように、プロパティ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になります。
OPSSスクリプトを使用してブートストラップ資格証明を変更または追加するには、第10.5.5項「modifyBootStrapCredential」および第10.5.6項「addBootStrapCredential」を参照してください。
アイデンティティ・データは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲットLDAPリポジトリに手動で移行できます。このスクリプトで作成されるLDIFファイルを、(手動で多少の編集を行った後で)LDAPベースのアイデンティティ・ストアにインポートして、移行元の10gまたは11gファイルベースのあらゆるアイデンティティ・ストアで使用できます。
たとえば、このスクリプトを使用して、10.1.xのjazn-data.xmlファイルにあるユーザーおよびロール情報をWebLogic LDIF形式のユーザーおよびロール情報に変換できます。各ユーザーのパスワードを変更した後、このLDIF出力ファイルをWebLogicに組み込まれているLDAPアイデンティティ・ストアにインポートできます(この項の末尾にある注意を参照してください)。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
このスクリプトは、WebLogic Serverではインタラクティブ・モードまたはスクリプト・モードで、WebSphereではインタラクティブ・モードでのみ実行可能です。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。
OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。
スクリプト・モードおよびインタラクティブ・モードの構文
WebLogicにアイデンティティを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]
migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])
WebSphere Application ServerでのOPSS スクリプトの実行の詳細は、次を参照してください
引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。
configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。
srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。
dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。
移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「サポートされているLDAPアイデンティティ・ストアのタイプ」を参照してください。
dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先が組込みLDAPなど、LDAPベースのOracle Internet Directoryストアである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、通常は手動編集が必要です。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
|
重要: 出力LDIFファイルの各ユーザーのパスワードは、実際のユーザー・パスワードではなく、仮の文字列weblogicです。移行先がLDAPベースのOracle Internet Directoryストアの場合、仮の文字列はchangeです。 このため、LDIFファイルをターゲットのLDAPストアにインポートする前に、セキュリティ管理者がこのファイルを編集して、仮のパスワードを実際のパスワードに変更する必要があります。 |
次の例は、いくつかのサービスとプロパティの構成を示すjps-config.xmlファイル全体です。これらのサービスおよびプロパティはJava EEアプリケーションにもJava SEアプリケーションにも適用されます。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"> <property value="off" name="oracle.security.jps.jaas.mode"/> <propertySets> <propertySet name="saml.trusted.issuers.1"> <property value="www.oracle.com" name="name"/> </propertySet> </propertySets> <serviceProviders> <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE"> <description>SecretStore-based CSF Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider" name="idstore.ldap.provider" type="IDENTITY_STORE"> <description>LDAP-based IdentityStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" name="idstore.xml.provider" type="IDENTITY_STORE"> <description>XML-based IdentityStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE"> <description>XML-based PolicyStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider" name="jaas.login.provider" type="LOGIN"> <description>JaasLoginServiceProvider to conf loginMod servInsts</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider" name="keystore.provider" type="KEY_STORE"> <description>PKI Based Keystore Provider</description> <property value="owsm" name="provider.property.name"/> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.audit.AuditProvider" name="audit.provider" type="AUDIT"> <description>Audit Service</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE"/> <serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE"> <property value="OID" name="policystore.type"/> </serviceProvider> </serviceProviders> <serviceInstances> <serviceInstance location="./" provider="credstoressp" name="credstore"> <description>File Based Credential Store Service Instance</description> </serviceInstance> <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap"> <property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/> </serviceInstance> <serviceInstance location="./system-jazn-data.xml" provider="idstore.xml.provider" name="idstore.xml"> <description>File Based Identity Store Service Instance</description> <property value="jazn.com" name="subscriber.name"/> </serviceInstance> <serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml"> <description>File Based Policy Store Service Instance</description> </serviceInstance> <serviceInstance location="./default-keystore.jks" provider="keystore.provider" name="keystore"> <description>Default JPS Keystore Service</description> <property value="JKS" name="keystore.type"/> <property value="oracle.wsm.security" name="keystore.csf.map"/> <property value="keystore-csf-key" name="keystore.pass.csf.key"/> <property value="enc-csf-key" name="keystore.sig.csf.key"/> <property value="enc-csf-key" name="keystore.enc.csf.key"/> </serviceInstance> <serviceInstance provider="audit.provider" name="audit"> <property value="None" name="audit.filterPreset"/> <property value="0" name="audit.maxDirSize"/> <property value="104857600" name="audit.maxFileSize"/> <property value="jdbc/AuditDB" name="audit.loader.jndi"/> <property value="15" name="audit.loader.interval"/> <property value="File" name="audit.loader.repositoryType"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="saml.loginmodule"> <description>SAML Login Module</description> <property value="oracle.security.jps.internal.jaas.module.saml.JpsSAMLLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> <propertySetRef ref="saml.trusted.issuers.1"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="krb5.loginmodule"> <description>Kerberos Login Module</description> <property value="com.sun.security.auth.module.Krb5LoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> <property value="true" name="storeKey"/> <property value="true" name="useKeyTab"/> <property value="true" name="doNotPrompt"/> <property value="./krb5.keytab" name="keyTab"/> <property value="HOST/localhost@EXAMPLE.COM" name="principal"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="digest.authenticator.loginmodule"> <description>Digest Authenticator Login Module</description> <property value="oracle.security.jps.internal.jaas.module.digest.DigestLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="certificate.authenticator.loginmodule"> <description>X509 Certificate Login Module</description> <property value="oracle.security.jps.internal.jaas.module.x509.X509LoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="wss.digest.loginmodule"> <description>WSS Digest Login Module</description> <property value="oracle.security.jps.internal.jaas.module.digest.WSSDigestLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="user.authentication.loginmodule"> <description>User Authentication Login Module</description> <property value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="user.assertion.loginmodule"> <description>User Assertion Login Module</description> <property value="oracle.security.jps.internal.jaas.module.assertion.JpsUserAssertionLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap"> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=wls-jrfServer" name="oracle.security.jps.farm.name"/> <property value="cn=jpsTestNode" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://stadw12.us.oracle.com:3060" name="ldap.url"/> </serviceInstance> <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred"> <property value="./bootstrap" name="location"/> </serviceInstance> <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> <property value="OID" name="policystore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=wls-jrfServer" name="oracle.security.jps.farm.name"/> <property value="cn=jpsTestNode" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://stadw12.us.oracle.com:3060" name="ldap.url"/> </serviceInstance> </serviceInstances> <jpsContexts default="default"> <jpsContext name="default"> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="audit"/> <serviceInstanceRef ref="credstore.ldap"/> <serviceInstanceRef ref="policystore.ldap"/> </jpsContext> <jpsContext name="oracle.security.jps.fmw.authenticator.DigestAuthenticator"> <serviceInstanceRef ref="digest.authenticator.loginmodule"/> </jpsContext> <jpsContext name="X509CertificateAuthentication"> <serviceInstanceRef ref="certificate.authenticator.loginmodule"/> </jpsContext> <jpsContext name="SAML"> <serviceInstanceRef ref="saml.loginmodule"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext> </jpsContexts> </jpsConfig>
