この章では、Oracle ADFセキュリティを使用せずにOPSSを使用するJava EEアプリケーションでお薦めする手動による構成とパッケージ化について説明します。ただし、一部のトピックは、Oracle ADFアプリケーションにも当てはまります。
Java SEアプリケーションの情報は、第22章「OPSSを使用するためのJava SEアプリケーションの構成」を参照してください。
ここで示す情報は、Oracle JDeveloper環境の外部でJava EEアプリケーションを構成し、パッケージ化する開発者を対象としています。また、アサートされたユーザーとして実行に使用できるAPIについても説明します。
この章の内容は次のとおりです。
開発時、デプロイ時、実行時およびデプロイ後のアプリケーション管理に関係するファイルは、次のとおりです。
次にあげるドキュメントでは、Java EEアプリケーションの認証開発について説明します。
Oracle WebLogic Serverにおける認証の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティについて』の第3章にある認証に関する項を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』
第3章「Webアプリケーションの保護」
第4章「Java ClientでのJAAS認証の使用」
第5章「Java ClientでのSSL認証の使用」
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』
第4章「認証プロバイダ」
第5章「IDアサーション・プロバイダ」
第13章「サーブレットの認証フィルタ」
Java EEアプリケーション内のカスタム・モジュールは、認証プロバイダでラップする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムの認証プロバイダの開発方法に関する項を参照してください。
Java EEアプリケーションで使用されるログイン・モジュールについては、次のドキュメントを参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の第4章にあるログイン・モジュールに関する項
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』の第4章にあるJAAS認証の開発環境に関する項
すべてのOPSS API javadocへのリンクについては、第H.1項「OPSS APIリファレンス」を参照してください。
OPSSはサーブレット・フィルタJpsFilter
とEJBインターセプタJpsInterceptor
を備えています。前者はWARファイルでパッケージ化されるファイルweb.xml
で構成され、後者はJARファイルでパッケージ化されるファイルejb-jar.xml
で構成されます。アプリケーションMBeanがアクセスするストライプをファイルweb.xml
で構成する方法も、OPSSによって提供されます。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。
これらはいずれもWebLogicとWebSphereで利用可能です。利用できる構成は、次に示すように、サーバー・プラットフォームに応じてやや異なります。
WebLogicでは、JpsFilterはデフォルトのパラメータ値で自動的に設定され、そのまますぐに使用できるため、デプロイメント・ディスクリプタで明示的に構成する必要はありません。デフォルト値以外の値を設定する場合にのみ手動構成が必要です。JpsInterceptorは手動で構成する必要があります。
WebSphereでは、JpsFilterとJpsInterceptorをいずれも手動で構成する必要があります。
注意: Oracle ADFアプリケーションに必要なサーブレット・フィルタ( この項で説明している手動による構成は、次で説明しているOPSS機能をOracle JDeveloper環境の外部で使用してJava EEアプリケーションをパッケージ化または構成する場合にのみ必要です。 |
OPSSでは、MBeanが使用するアプリケーション・ストライプの指定が可能です。詳細は、「アプリケーション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 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=SYTEM
対応する要素<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.4項「modifyBootStrapCredential」および第10.5.5項「addBootStrapCredential」を参照してください。
アイデンティティ・データは、OPSSスクリプトmigrateSecurityStore
を使用してソース・リポジトリからターゲットLDAPリポジトリに移行できます。詳細は、第6.6.1.1項「migrateSecurityStoreを使用したアイデンティティの移行」を参照してください。
次の例は、いくつかのサービスとプロパティの構成を示す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://myHost.com:1234" 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://myHost.com:1234" 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>
多くの場合、アプリケーションは、ユーザーが操作を実行したようにアクションを実行する、つまり、実行操作を起動する必要があります。OPSSでは、アサートされたユーザーのサブジェクトを使用して、ユーザーが実行したようなアプリケーション・ロジックの実行をJava EEアプリケーションおよびJava SEアプリケーションに許可することにより、この問題を解決します。この機能は、OPSSクラスSubjectSecurity
でカプセル化され、WebLogicおよびWebSphere両方のプラットフォームでサポートされています。
この項の内容は次のとおりです。
プログラミング課題の解決にSubjectSecurity
クラスを使用できる例をいくつか次に示します。
UC1 - スケジューラはジョブの送信と実行を可能にします。通常これらのジョブは一度に送信され何回かに分けて実行されるため、ユーザーのアイデンティティをアサートし、ユーザーのセキュリティ・コンテキストでスケジュールされたジョブを実行する必要があります。
UC2 - スケジュールされたジョブはエンティティBeanにより実行され、さらに、ジョブを完了するためにその他のエンティティBeanをコールする場合があります。ジョブを完了するためのすべてのコードは、ユーザーのセキュリティ・コンテキストで実行する必要があるため、このコンテキストはパスをコールことにより、エンティティBean間で伝播される必要があります。
UC3 - スケジュールされたジョブを実行するパーミッションは、ユーザーのアプリケーション・ロールに基づいています。この場合は、エンティティBean間のコード・パスにかかわらず、ユーザーのセキュリティ・コンテキストはユーザーに付与されたアプリケーション・ロールを認識する必要があります。
UC4 - 認証されていないユーザーがジョブを送信する場合は、ジョブ・メタデータは匿名ユーザーを保持する必要があります。その結果、ジョブは匿名ユーザーにより実行される必要があります。
UC5 - アプリケーションで実行するMBeanは、MBeanサーバー経由でUIから起動されます。MBean操作は、特定のユーザーとして実行する必要のある一連の診断テストを起動します。
UC6 - ユーザー・アイデンティティはユーザー・アサーションAPIによりアサートされており、該当のユーザーとして操作を実行するために使用できるユーザーのセキュリティ・コンテキストを作成します。
SubjectSecurity
APIにより、事前計算されたサブジェクトが使用可能な場合(ユースケースUC6と同じ)、またはユーザーが最初にアサートされる必要がある場合は、ユーザーはコードを実行できます。アプリケーションのセキュリティ・コンテキストが設定されていない場合は、SubjectSecurity
APIを使用する前に、アプリケーションはアプリケーションのIDを次のように設定する必要があります。
AppSecurityContext.setApplicationID(applicationID)
たとえば、ユースケースUC1、UC2、UC3、およびUC5と同様のシステムMbeanの場合は、アプリケーションIDをsetApplicationID
に設定する必要があります。アプリケーションのセキュリティ・コンテキストが設定されている場合は、setApplicationID
に対するコールはオプションです。
SubjectSecurity
クラスを使用する場合の一般的な推奨事項を次に示します。
サブジェクトをすでに取得しており、サブジェクトを使用して操作を実行する場合は、SubjectSecurity.getActionExecutor(subject)
を使用します。サブジェクトの取得方法によって、次のケースがあります。
コンテナ認証が実行され、SubjectUtil.getCurrentSubject()
を使用してサブジェクトが取得された場合は、サブジェクトはコンテナ・セキュリティおよびOPSSセキュリティとともに動作し、アプリケーション・ロールが検討されます。
JpsLoginModuleFactory
を使用し、プログラム認証を介してサブジェクトが取得された場合は、サブジェクトはコンテナ・セキュリティおよびOPSSセキュリティとともに動作します。
ユーザー名のみが使用可能で、そのユーザーとして操作を実行する場合は、SubjectSecurity.getActionExecutor(userName)
を使用します。このメソッドでは、アイデンティティ・アサーションを含む権限の操作を実行します。必要なパーミッションを得るためのコードのコールを要求してこれらの操作を起動します。このため、このメソッドを使用するアプリケーションでは、次のようなコードベースのパーミッションが必要です。
<grant> <grantee> <codesource> <url>file:${domain.home}/servers/${weblogic.Name}/myApp.ear/-</url> </codesource> </grantee> <permissions> <permission> <class>oracle.security.jps.JpsPermission</class> <name>IdentityAssertion</name> <actions>execute</actions> </permission> </permissions> </grant>
<url>
は、メソッドをコールするコードの場所を指定します。
ActionExecutor.execute(PrivilegedAction)
は、ユーザーのJAASサブジェクトおよびアプリケーションのPrivilegedAction
を使用してSubject.doAs()
を呼び出します。
SubjectSecurity.executeAs(Subject subject, PrivilegedAction<T> action)
を使用して、アクションを即時に実行します。
SubjectSecurity.executeAs(Subject subject, PrivilegedExceptionAction<T> action)
を使用して、アクションを即時に実行します。このメソッドは、getActionExecutor(subject)
を使用してアクション・エグゼキュータを取得し、アクションを実行します。
次のサンプル・コードは、SubjectSecurity
APIを使用し、jdoe
という名前のアサートされたユーザーとして実行することを示しています。
// get a SubjectSecurity instance final SubjectSecurity subjectSecurity = SubjectSecurity.getInstance(); String username = "jdoe"; // create ActionExecutor with subjectSecurity getActionExecutor(String username) ActionExecutor executor = AccessController.doPrivileged(new PrivilegedExceptionAction<ActionExecutor>() { public ActionExecutor run() throws AssertionException { return subjectSecurity.getActionExecutor(username); } }, null); // When OPSS subjects are available, // create ActionExecutor with SubjectSecurity getActionExecutor(Subject subject) Subject opssSubject = SubjectUtil.getCurrentSubject(); ActionExecutor ececutor = subjectSecurity.getActionExecutor(opssSubject); //run privilegedAction PrivilegedAction action = new MyPrivilegedAction(); executor.execute(action); //run PrivilegedExceptionAction PrivilegedExceptionAction exceptionAction = new MyPrivilegedExceptionAction(); try { executor.execute(exceptionAction); } catch (PrivilegedActionException e) { // handle PrivilegedActionException }