この章では、Oracle ADFセキュリティを使用せずにOPSSを使用するJavaEEアプリケーションで推奨する手動による構成とパッケージ化について説明します。ただし、一部のトピックは、Oracle ADFアプリケーションにも当てはまります。
ここで示す情報は、Oracle JDeveloper環境の外部でJavaEEアプリケーションの構成とパッケージ化を行う開発者を対象としています。
この章の内容は次のとおりです。
開発時、デプロイ時、実行時およびデプロイ後のアプリケーション管理に関係するファイルは、次のとおりです。
$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ファイル内)
この情報を使用する前に、使用されているコンテキストに精通しておくことを強くお薦めします。詳細は、第14章「Oracle Platform Security Servicesを使用したセキュアなアプリケーションの開発の概要」を参照してください。
注意: Oracle ADFアプリケーションに必要なサーブレット・フィルタ(JpsFilter )およびEJBインターセプタ(JpsInterceptor )の構成は、Oracle JDeveloperによって自動的に挿入されます。
この項で説明する構成を手動で入力するのは、OPSSを使用するJavaEEアプリケーションのパッケージ化または構成を該当する環境の外部で実行する場合のみです。 |
サーブレット・フィルタJpsFilter
とEJBインターセプタJpsInterceptor
は、OPSSによって提供されます。前者はWARファイルでパッケージ化されるファイルweb.xml
で、後者はJARファイルでパッケージ化されるファイルejb-jar.xml
で構成されます。
いずれの場合も、同じパラメータ・セットの構成で、サーブレットの機能またはEnterprise Java Bean(EJB)の次の機能をカスタマイズすることができます。
アプリケーション名(アプリケーション・ストライプと呼ぶ方がふさわしく、アプリケーションのweb.xml
ファイル内で指定することも可能)は、適用可能なポリシー・セットを決定するために、実行時に使用されます。アプリケーション・ストライプは、指定しない場合、アプリケーションID(アプリケーション名が含まれる)がデフォルト値として使用されます。
アプリケーション・ストライプは、ポリシー・ストア内でポリシーのサブセットを定義します。該当するポリシーのサブセットを使用するアプリケーションは、該当するアプリケーション名と同じ文字列を使用して、そのアプリケーション・ストライプを定義します。そのため、ドメイン・ポリシー・ストア内では、様々なアプリケーションで同じポリシーのサブセットを使用できます。
匿名ロールと認証ロールの機能は、「匿名ユーザーとロール」および「認証ロール」の項で説明します。
サーブレットでは、要素<filter-mapping>
でフィルタの使用を指定します。このような要素は、サーブレットごと、フィルタごとに1つ必要です。
EJBでは、要素<interceptor-binding>
でインターセプタの使用を指定します。このような要素は、EJBごと、インターセプタごとに1つ必要です。詳細は、「インターセプタ構成構文」を参照してください。
使用可能なパラメータの概要は、「フィルタおよびインターセプタ・パラメータの概要」を参照してください。
この値は、次のパラメータで制御します。
application.name
このパラメータの指定はオプションです。指定しない場合、デフォルトでデプロイされるアプリケーションの名前になります。その値は、アプリケーションで使用するポリシー・ストア内のポリシーのサブセットを定義します。
サーブレットの場合および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に設定します。デフォルト値はfalseです。
サブジェクトから匿名ロールを削除するには2番目のプロパティをtrueに設定し、保持するにはfalseに設定します。デフォルト値はtrueです。匿名ユーザーおよび匿名ロールは、通常は認証後に削除し、認証後に保持するのは特殊な場合のみです。
匿名ユーザーのデフォルト名とプリンシパル・クラスは、次のとおりです。
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
の動作を制御する方法の詳細は、第18.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によって使用されるパラメータの説明をまとめたものです。
表15-1 JpsFilterおよびJpsInterceptorパラメータの概要
パラメータ名 | 値 | デフォルト | 機能 | 注意 |
---|---|---|---|---|
application.name |
任意の有効な文字列 |
デプロイされるアプリケーションの名前 |
サーブレットまたはEJBによって使用されるポリシーのサブセットを指定する。 |
ドメイン・ポリシー・ストア内の同じポリシーのサブセットをいくつかのサーブレットまたはEJBで共有する場合は、指定する必要があります。 |
add.application.roles |
TRUEまたはFALSE |
TRUE |
アプリケーション・ロールをサブジェクトに追加する。 |
TRUEがデフォルトなので、(FALSEに)設定する必要があるのは、アプリケーションがアプリケーション・ロールをサブジェクトに追加しない場合のみです。 |
enable.anonymous |
TRUEまたはFALSE |
FALSE |
匿名サブジェクトを有効または無効にする。 |
匿名ユーザーおよび匿名ロールでのサブジェクトの作成を許可するよう作成するには、TRUEに設定します。 |
remove.anonymous.role |
TRUEまたはFALSE |
TRUE |
認証後にサブジェクトのアプリケーション・ロールを保持または削除する。 |
サーブレットの場合にのみ使用可能です。EJBの場合、匿名ロールは常にサブジェクトから削除されます。 |
add.authenticated.role |
TRUEまたはFALSE |
TRUE |
サブジェクト内で認証ロールの追加を許可する。 |
TRUEがデフォルト値なので、(FALSEに)設定する必要があるのは、認証ロールをサブジェクトに含めない場合のみです。 |
oracle.security.jps.jaas.mode |
doAsPrivileged doAs off undefined subjectOnly |
doAsPrivileged |
JAASモードを設定する。 |
注意: Oracle JDeveloperを使用している場合、このツールによって適切なクラスが選択されます。したがって、次に説明する構成は、ポリシーがOracle JDeveloper環境外で入力された場合にのみ必要です。 |
アプリケーション・ロールのメンバー内で指定されるクラスは、他のアプリケーション・ロールのクラスか、次のいずれかにする必要があります。
weblogic.security.principal.WLSUserImpl weblogic.security.principal.WLSGroupImpl
次のコード断片は、エンタープライズ・グループの指定におけるこれらのクラスの使用を示しています(太字の部分)。
重要: アプリケーション・ロール名では、大文字小文字が区別されません(次のサンプルのapp_operator など)。
エンタープライズ・ユーザーおよびグループ名では、大文字小文字が区別されます(次のサンプルの 大文字小文字の区別に関する情報は、第I.6項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。 |
<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>
この項では、Oracle WebLogic管理コンソールを使用してデプロイされるWARファイル内の(カスタム・ポリシーおよび資格証明を使用する)サーブレットまたは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ファイル内にあるすべてのweb.xml ファイルのすべてのJpsFilter 構成は、同じ構成にする必要があります。JpsInterceptor にも同じ制約が適用されます。 |
JpsFilterおよびJpsInterceptorの詳細は、「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
カスタムのポリシーおよび資格証明を使用するJavaEEアプリケーションに対するパッケージ化の要件と前提条件は、次のとおりです。
デプロイされるアプリケーションは、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環境の外部で開発されたJavaEEアプリケーションのために開発者が手動で実行するいくつかの構成について説明します。この項の内容は、次のとおりです。
ポリシーの移行は、移行動作を制御する2つのリスナーを構成するいくつかのプロパティによって制御されます。また、再デプロイのシナリオをサポートするには、アプリケーション・マニフェストのバージョニングが必要です。
ファイルMETA-INF/weblogic-application.xml
でバージョニングを除くすべてのパラメータが構成され、ファイルMETA-INF/MANIFEST.MF
でバージョニングが構成されます。
アプリケーションのデプロイ時にポリシーの移行を制御するパラメータは、次のとおりです。
移行
リスナー
バージョニング
プリンシパルの検証
移行のターゲット(アプリケーション・ストライプ)
前述の各パラメータの構成と機能を、次に説明します。
注意: Fusion Middleware Controlでは、アプリケーションのデプロイ、再デプロイまたはアンデプロイの際に、これらのパラメータのほとんどを設定できます。詳細は、第7.2.1項「Fusion Middleware Controlを使用したJavaEEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。次に説明する構成は、Fusion Middleware Controlを使用しないでアプリケーションを管理する場合にのみ、手動で入力する必要があります。 管理サーバーが稼動しているコンピュータとは異なるコンピュータで稼動している管理対象サーバーに、ファイルベース・ストアを使用するアプリケーションをデプロイする場合は、リスナーを使用しないでください。使用した場合、管理対象サーバーと管理サーバーによって管理されているデータが一致せず、セキュリティが期待どおりに機能しない場合があります。リスナーを使用するかわりにWLSTコマンド |
このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアに存在する一致するポリシーをマージするのか上書きするのかを指定します。
これは、次のコード断片に示すように構成されます。
<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に設定すると、移行が行われ、既存のポリシーが上書きされます。
注意: このプロパティを指定しない場合、次のようになります。
|
このパラメータでは、ポリシーの移行先であるターゲット・ストライプを指定します。
これは、次のコード断片に示すように構成されます。
<wls:application-param> <wls:param-name>jps.policystore.applicationid</wls:param-name> <wls:param-value>myApplicationStripe</wls:param-value> </wls:application-param>
任意の有効な文字列をこのパラメータの値に設定できます。このパラメータの値を指定しない場合は、アプリケーション名とバージョン、すなわちapplication_name#versionに基づいて、Oracle WebLogic Serverがストライプ名を選択します。
このパラメータの値は、JpsServletに対して指定されているapplication.name
の値(ファイルweb.xml
内)またはJpsInterceptorに対して指定されているapplication.name
の値(ファイルejb-jar.xml
内)に一致している必要があります。詳細は、「アプリケーション名(ストライプ)」を参照してください。
weblogic-application.xml
から選択された値はデプロイ時に使用され、web.xml
またはejb-jar.xml
から選択された値は実行時に使用されます。
JpsApplicationLifecycleListener
このパラメータは常に、次のコード断片で示すように設定する必要があります。
<wls:listener> <wls:listener-class> oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener </wls:listener-class> </wls:listener>
JpsAppVersionLifecycleListener
このパラメータは、アンデプロイ時のポリシーの削除および再デプロイ時のポリシーの上書きを制御します。
これは、次のコード断片のように設定します。
<wls:listener> <wls:listener-class> oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener </wls:listener-class> </wls:listener>
このパラメータは、アンデプロイ時のポリシーの削除および再デプロイ時のポリシーの上書きを制御します。設定しない場合、アプリケーションのアンデプロイ時、アプリケーション・ポリシーが削除されません。
これは、EARファイルのファイルMETA-INF/MANIFEST.MF
内で、次のコード断片内の太字のように設定します。
Manifest-Version: 1.0
Created-By: 1.5.0_14 (Sun Microsystems Inc.)
Weblogic-Application-Version: V1.0
バージョン文字列(前述の例ではV1.0)には、任意の文字列を設定できます。実際の値は重要ではありませんが、アプリケーションの開発者は通常、変更履歴に基づくバージョン情報を使用します。
jps.apppolicy.idstoreartifact.migration
このパラメータでは、エンタープライズ・ユーザーまたはグループに対するアプリケーション・ロールやパーミッションの付与など、エンタープライズ・ユーザーまたはグループへの参照の移行をポリシーの移行から除外するかどうかを指定します。そのため、アプリケーション・ポリシーのみの移行が可能となり、有効にすると、エンタープライズ・グループまたはユーザーへのアプリケーション・ロールのマッピングが、移行時に無視されます。
これは、次のコード断片に示すように構成されます。
<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>
このパラメータでは、アンデプロイ時にポリシーの削除を実行しないかどうかを指定します。
これは、次のコード断片に示すように構成されます。
<wls:application-param> <wls:param-name>jps.policystore.removal</wls:param-name> <wls:param-value>OFF</wls:param-value> </wls:application-param>
設定する場合は、このパラメータの値をOFFにする必要があります。デフォルトでは、このパラメータは設定されません。
OFFに設定した場合、ポリシーは削除されません。設定しない場合、ポリシーは削除されます。
同一のアプリケーション・ストライプを複数のアプリケーションで共有する場合は、前述の設定を考慮する必要があります。アプリケーションのアンデプロイ時は、他のアプリケーションが共通のポリシー・セットを使用している可能性があるため、アプリケーション・ポリシーを削除しないよう選択します。
注意: 特定のアプリケーションに対してこのパラメータをOFFに設定する場合は、アプリケーションのデプロイ時にアプリケーション・ストライプが他のアプリケーションにより共有されているかどうかを認識しておく必要があります。 |
jps.policystore.migration.validate.principal
このパラメータでは、デプロイ時または再デプロイ時に、システムおよびアプリケーションのポリシー内のプリンシパルをチェックするかどうかを指定します。
これは、次のコード断片に示すように構成されます。
<wls:application-param> <wls:param-name>jps.policystore.migration.validate.principal</wls:param-name> <wls:param-value>TRUEorFALSE</wls:param-value> </wls:application-param>
設定する場合は、このパラメータの値をTRUEまたはFALSEにする必要があります。
TRUEに設定すると、エンタープライズ・ユーザーおよびグループの妥当性がシステムによってチェックされます。(アプリケーションまたはシステム・ポリシー内の)プリンシパルがアイデンティティ・ストアにないエンタープライズ・ユーザーまたはグループを参照した場合は、警告が発行されます。FALSEに設定すると、このチェックがスキップされます。
このパラメータを設定しなかった場合のデフォルト値は、FALSEです。
検証エラーはサーバー・ログに記録されます。検証エラーが発生しても、操作は終了されません。
この項では、アプリケーション・ポリシーの管理時に次のような動作を実行するのに必要な設定について説明します。
予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。詳細は、「推奨事項」を参照してください。
どの動作も、Fusion Middleware Controlによるアプリケーションのデプロイ時、再デプロイ時またはアンデプロイ時に、Fusion Middleware Controlで指定できます。
次のマトリクスに、移行を行わない設定を2つ示します。
表15-2 ポリシーの移行をスキップするための設定
設定1: デプロイ時または再デプロイ時に有効 | 設定2: 再デプロイ時に有効 | |
---|---|---|
JpsApplicationLifecycleListener |
設定する |
設定する |
JpsAppVersionLifecycleListener |
該当なし |
設定しない |
jps.policystore.migration |
OFF |
該当なし |
ポリシーをそのまま維持する場合は通常、再デプロイ時に、ポリシーの移行をスキップします。ただし、アプリケーションを初めてデプロイする場合は常に、ポリシーの移行を行います。
次のマトリクスは、ターゲット・ストアにないポリシーのみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。
表15-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が設定されます。 |
ポリシーが変更され、これを既存のポリシーに追加する場合は通常、再デプロイ時にマージによるポリシーの移行を選択します。
次のマトリクスは、一致するターゲット・ポリシーを上書きして全ポリシーを移行する設定を示しています(オプション・パラメータは大カッコで囲んであります)。
表15-4 上書きによりポリシーを移行するための設定
再デプロイ時に有効 | |
---|---|
JpsApplicationLifecycleListener |
設定する |
JpsAppVersionLifecycleListener |
設定する |
jps.policystore.migration |
OVERWRITE |
アプリケーション・マニフェストのバージョニング |
設定する |
[jps.policystore.migration.validate.principal] |
アプリケーションおよびシステムのポリシーでエンタープライズ・ユーザーおよびロールを検証するにはTRUE、検証しない場合はFALSEに設定する。指定しなかった場合は、デフォルトのFALSEが設定されます。 |
新しいポリシー・セットで既存のポリシーを置き換える場合は通常、再デプロイ時に上書きによるポリシーの移行を選択します。オプション・パラメータjps.policy.migration.validate.principal
は、必要な場合、手動で設定する必要があります。
システム・ポリシー内でコード・ソースの付与が削除されないため、アンデプロイ時のアプリケーション・ポリシーの削除は制限されています。詳細は、「削除されるデータと削除されないデータ」を参照してください。
次のマトリクスは、アンデプロイ時にポリシーを削除する設定を示しています。
表15-5 ポリシーを削除するための設定
アンデプロイ時に有効 | |
---|---|
JpsApplicationLifecycleListener |
設定する |
JpsAppVersionLifecycleListener |
設定する |
アプリケーション・マニフェストのバージョニング |
設定する |
jps.policystore.removal |
設定しない(デフォルト) |
次のマトリクスは、アンデプロイ時にアプリケーション・ポリシーを削除しない設定を示しています。
表15-6 ポリシーを削除しないための設定
アンデプロイ時に有効 | |
---|---|
JpsApplicationLifecycleListener |
設定する |
JpsAppVersionLifecycleListener |
設定する |
アプリケーション・マニフェストのバージョニング |
設定する |
jps.policystore.removal |
OFF |
注意: 特定のアプリケーションに対してこのパラメータを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 code-based 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>
内のデータはすべて、アンデプロイ時に自動的に削除できません。
次の推奨事項を覚えておいてください。
LDAPベースのポリシー・ストアを使用し、アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つに対してのみ移行を行うよう選択します。残りのデプロイでは、ポリシーを移行しないよう選択します。これにより、ポリシーはアプリケーション・ストアからドメイン・ポリシー・ストアに一度だけ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。
同じアプリケーションで同一のノードに対するポリシーの移行を複数回(たとえば異なる管理対象サーバー上で)試行すると、ポリシーの移行が失敗する場合があります。別の方法として、WLSTコマンド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
で構成されます。
資格証明の移行を制御するパラメータは、jps.credstore.migrationです。リスナーは、JpsApplicationLifecycleListener - Credentialsです。
このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアに存在する一致する資格証明をマージするのか上書きするのかを指定します。
これは、次のコード断片に示すように構成されます。
<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value>behaviorValue</wls:param-value>
</wls:application-param>
設定する場合、このパラメータの値は、MERGE、OVERWRITE、OFFのいずれかである必要があります。値OVERWRITEは、サーバーが開発モードで稼動している場合にのみ使用できます。
設定しない場合、資格証明の移行はオプションMERGEを使用して行われます。
JpsApplicationLifecycleListener - Credentials
このリスナーは、次のコード断片のように指定します。
<wls:listener> <wls:listener-class> oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener </wls:listener-class> </wls:listener>
この項では、アプリケーション資格証明の移行時に次のような動作を実行するのに必要な手動設定について説明します。
予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。
移行のターゲットがLDAPベースの資格証明ストアの場合、アプリケーションは1つの管理対象サーバーまたはクラスタにのみデプロイしてください。そうしないと、アプリケーション資格証明が予期したとおりに動作しない場合があります。
注意: 資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。 |
次のマトリクスは、移行を行わない設定を示しています。
次のマトリクスは、ターゲット・ストアにない資格証明のみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。
この操作は、WebLogicサーバーが開発モードで稼動している場合にのみ有効です。次のマトリクスは、一致するターゲットの資格証明を上書きしてすべての資格証明を移行する設定を示しています。
パーミッションのコンポーネントを、system-jazn-data.xml
ファイルの次のスニペットで示します。
<grant> <grantee> <codesource> <url>file:/path/foo.jar</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
になります。
WLSTコマンドを使用してブートストラップ資格証明を変更するには、第9.5.2.5項「modifyBootStrapCredential」を参照してください。
アイデンティティ・データは、WLSTコマンドmigrateSecurityStore
を使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このコマンドはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFile
で渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
後述のコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力すると、応答が即座に表示されます。スクリプト・モードの場合、コマンドはテキスト・ファイル(ファイル名拡張子は.py)に記述されるので、シェル・スクリプトのディレクティブのように入力なしで実行できます。
重要: シェル内でセキュリティ関連のWLSTコマンドを起動する前に、次のサンプルで説明するように、wlst.sh スクリプトを実行する必要があります。
> sh $ORACLE_HOME/common/bin/wlst.sh これにより、必要なJARがクラスパスに確実に追加されるようになります。新しいシェル内で上のコマンドを実行しないと、WLSTコマンドが使用できない状態になります。 オンライン・コマンドを実行する前に、次のようにサーバーに接続します。 >java weblogic.WLST >connect(' |
スクリプト・モードおよびインタラクティブ・モードの構文
アイデンティティを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore -type idStore -configFile jpsConfigFileLocation -src srcJpsContext -dst dstJpsContext [-dstLdifFile LdifFileLocation]
migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])
引数(dstLdifFile
以外はすべて必須)の意味は次のとおりです。
configFile
では、構成ファイルjps-config.xml
の位置を、このコマンドを実行するディレクトリを基準とした相対パスで指定します。
src
では、引数configFile
で渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。
dst
では、引数configFile
で渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアには、XMLベースのストアまたはOracle Internet Directoryサーバーで支援されるLDAPベースのストアを指定できます。それ以外のストアは移行先としてサポートされていません。
dstLdifFile
では、LDIFファイルを作成する場所を指定します。移行先がLDAPベースのOracle Internet Directoryストアである場合にのみ必要です。LDIFファイルはLDAPサーバーにはインポートされません。
src
およびdst
で渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。
次の例は、いくつかのサービスとプロパティの構成を示すjps-config.xml
ファイル全体です。これらのサービスおよびプロパティはJavaEEアプリケーションにもJavaSEアプリケーションにも適用されます。
<?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>