ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11g リリース1(11.1.1)
B56235-03
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

L Oracle Fusion Middlewareのセキュリティのトラブルシューティング

この付録では、Oracle Enterprise Manager Fusion Middlewareセキュリティを構成および使用する際に発生する可能性のある共通の問題について説明し、その解決方法を紹介します。次の項目が含まれます。

L.1 セキュリティ・エラーの診断

この項では、セキュリティ・エラーを検出して解決する方法について説明します。次の項目が含まれます。

Fusion Middleware Controlでは、発生したフォルトの管理、分離または解釈に役立つ可能性がある場合はいつでも、ロギングのサポートが明示的に提示されます。

L.1.1 ログ・ファイル

この項では、Oracle WebLogic Serverでサポートされている様々なログ・ファイルを紹介し、Fusion Middleware Controlでログ・レベルの構成と設定、およびログ・ファイルの検索と表示を行う方法について説明します。この項の内容は次のとおりです。

L.1.1.1 診断ログ・ファイル

ドメイン内の各サーバー・インスタンスは、そのサブシステムとアプリケーションで発生したOPSSベースのすべての例外を、ローカル・ホスト・コンピュータのファイル・システムにあるサーバー・ログ・ファイルに書き込みます。

デフォルトでは、このログ・ファイルは、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName-diagnostic.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

診断ファイルの完全な名前の例を、いくつか次に示します。DomainName/servers/AdminServer/logs/AdminServer-diagnostic.log00001(管理サーバー・ログ)、DomainName/servers/soa/logs/soa-diagnostic.log00013(管理対象サーバー・ログ)。

すべてのサーバー・インスタンスは、セキュリティ関連のエラーを診断ファイルに出力します。サーバー関連のセキュリティ・エラー(サブジェクトやプリンシパルの問題で発生した例外など)、およびドメイン・セキュリティ・データを移行または再関連付けするときに発生する可能性のあるエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー(アプリケーション固有のポリシーまたは資格証明で発生した例外など)は、対応する管理対象サーバーの診断ログに書き込まれます。

L.1.1.2 一般的なログ・ファイル

Oracle WebLogic Serverでは、診断ログ・ファイルに加えて、ドメイン内の各サーバーおよびトポロジ内の各ドメインに関するその他のログ・ファイルがサポートされています。

デフォルトでは、サーバー・ログ・ファイルは、診断ログ・ファイルと同様に、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。ドメイン・ログ・ファイルは、管理サーバー・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName.logxxxxxおよびdomain.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

サーバー・ログ・ファイルおよびドメイン・ログ・ファイルの完全な名前の例を、いくつか次に示します。DomainName/servers/AdminServer/logs/AdminServer.log00001、DomainName/servers/AdminServer/logs/domain1.log00033。

認証プロバイダまたはその他のドメイン・サービス・プロバイダで発生した例外など、一般的なエラーを探す場合には、サーバーおよびドメインのログ・ファイルを調べます。

ドメイン・ログは、(そのドメイン内のサーバーに対する)サーバー・ログに書き込まれたメッセージと一部重複しており、多数のサーバーを含むドメインでフォルトが発生した場合にサーバーの特定に役立ちます。


注意:

新しいログ・ファイルの生成は、そのローテーション・ポリシーによって決まり、ローテーションは通常、ファイル・サイズによって決まります。そのため、ログ・ファイルが指定されたサイズを超えると、整数の接尾辞が1つ増えた名前を持つ、新しいログ・ファイルが生成されます。

関連ドキュメント

サーバー・ログ・ファイルとドメイン・ログ・ファイルについては、『Oracle Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する項を参照してください。

Oracle WebLogicフレームワークについては、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。

ロギング・サービスの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverロギング・サービスによるアプリケーション・ロギング』を参照してください。

Oracle Fusion Middlewareにおけるロギングのすべての詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』の「ログ・ファイルと診断データの管理」の章を参照してください。

L.1.1.3 監査診断のログ・ファイル

Fusion Middleware監査フレームワークには、いくつかのランタイム・コンポーネントがあります。この項では、これらのコンポーネントの診断ログ・ファイルを紹介し、診断メッセージの解釈方法について説明します。

これらのログ・ファイルは、次の場所にあります。

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

表L-1は、様々な診断ログ・ファイルを示しています。

表L-1 監査診断のログ・ファイル

コンポーネント ログの保存場所 ロガーの構成

監査APIを使用するJava EEコンポーネント

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

監査APIを使用するOPMNコンポーネント

コンポーネントのログ・ファイルを探す方法については、管理者ガイドを参照してください。

ロガーは、OPMNコンポーネントの場所に基づいています。該当するコンポーネント・ガイドを参照してください。

起動クラス監査ローダー

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

OPMN監査ローダー

$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out

java.util.logging.config.fileシステム・プロパティを、OPMN監査ローダーのログ・レベルを含むファイルに設定できます。

構成/プロキシMbeans

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

監査スキーマ・サポート

RCUログの保存場所(デフォルトでは$ORACLE_HOME/rcu/log/): この場所を変更するにはRCU_LOG_LOCATIONを設定します。

RCUログ・レベル(デフォルトではERROR): RCU_LOG_LEVEL - [SEVERE; ERROR; NOTIFICATION; TRACE

L.1.1.3.1 ロガーの構成

Fusion Middleware Controlを使用してoracle.security.audit.loggerを構成できます。

oracle.security.audit.loggerでは、ERRORからTRACEまでの任意のログ・レベルを設定し、ログに記録される情報の量を制御できます。

Fusion Middleware Controlを使用して、これらの診断ファイルを表示することもできます。


関連項目:

次の各項の詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』の第10章「ログ・ファイルと診断データの管理」を参照してください。

  • ロガーの構成手順

  • ドメイン、サーバーおよび各アプリケーションのログ表示に関する詳細

L.1.1.3.2 監査診断の解釈

監査診断メッセージは、エラー・メッセージとトレース・メッセージという2つのタイプに分類できます。

すべてのエラー・メッセージには、IAU-XXXという番号が付けられます。これらのメッセージについては、考えられる原因とエラーへの対処方法が記載されたエラー・メッセージ・ガイドを参照してください。

これに対し、トレース・メッセージは、実行されているコンポーネントの詳細情報を示すためのものです。メッセージの性質に応じて、なんらかの処置が必要になることもあります。

L.1.1.4 Fusion Middleware Controlロギングのサポートの使用

Fusion Middleware Controlには、ログ情報を管理するためのページがいくつか用意されています。このツールを使用して、次の操作を実行できます。

  • ログのレベルとローテーションなど、ログ・ファイルの属性を構成します。

  • ドメイン内にあるすべてのログ・ファイルのコンテンツを検索し、メッセージID別またはタイプ別に問合せ結果をグループ分けします。

  • コンテキストまたは期間により特定のエラーとその他のエラーの相関を分析します。

  • ログ・ファイルの一部または問合せ結果を複数のフォーマットのいずれかでダウンロードします。

この項では、ログ・ファイルの構成方法について簡単に説明します。前述の他の3つの機能についても、第L.1.3項「セキュリティ・エラーの解決」に簡単な説明があります。

これらの各項のすべての詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。

Fusion Middleware Controlを使用してログ・ファイルを構成するには、次の手順を実行します。

  1. 「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。このページを使用して、永続ロガーとアクティブなランタイム・ロガーの両方に対するログ・レベルを構成できます。

  2. 必要なログ出力に対するログ・ファイル・エントリをクリックして、そのファイルに対する現在のパラメータ設定を示すページを表示します。

  3. このページで、行を選択し、「構成の編集」ボタンをクリックして、「ログ・ファイルの編集」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、ログ・レベルやローテーション・ポリシーなどの様々なパラメータを設定できます。

L.1.2 システム・プロパティ

デバッグ出力を増やすには、Oracle WebLogic Serverを起動するスクリプトに次のいずれかのシステム・プロパティを設定して、サーバーを再起動します。

認可プロセス中のデバッグ出力を取得するには、「認可プロセスのデバッグ」の項で説明しているいずれかのシステム・プロパティを設定してください。

サーバー起動時に渡すことができ、セキュリティ問題のデバッグに役立つ可能性のあるその他の2つのシステム・プロパティを、次に示します。

  • -DDebugOPSSPolicyLoading、OPSSポリシー・プロバイダの進行状況と設定を監視するフラグ。

  • -Djava.security.debug=policy、ファイル・システム内の保存場所、付与されるパーミッション、および署名付きコードに使用される証明書など、解析したポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。


注意:

ロギング出力を高く設定すると、特にファイルのロード時に、スタック状態のスレッドが多数レポートされる可能性があります。この状況を避けるには、Oracle WebLogic Serverでスレッドをスタックとしてマークするために使用するタイムアウト値を、より高い値に変更します。

サーバーを再起動せずにシステム・プロパティを設定することはできません。システム・プロパティを設定するには、管理者はsetDomainEnv.shシェル・スクリプトを編集し、そのスクリプト内の環境変数EXTRA_JAVA_PROPERTIESにプロパティを追加する必要があります。

L.1.2.1 jps.auth.debug

次のシステム・プロパティのみをtrueに設定すると仮定します。

-Djps.auth.debug=true

この場合、パーミッション・チェックが失敗すると出力が生成され、次の例に示すような詳細が表示されます。

[JpsAuth] Check Permission
          PolicyContext:        [jps-wls-Demo]
          Resource/Target:      [app.monitor]
          Action:               [read,write]
          Permission Class:     [java.util.PropertyPermission]
          Evaluator:            [ACC]
          Result:               [FAILED] 
Failed ProtectionDomain:ClassLoader=weblogic.servlet.jsp.JspClassLoader@fb111c finder: weblogic.utils.classloaders.CodeGenClassFinder@106bb21 annotation:
CodeSource=file:/C:/MyOracle/domains/base_domain/servers/AdminServer/tmp/_WL_user/jps-wls-Demo/kebqfo/jsp_servlet/test.class
Principals=total 5 of principals(
 1. weblogic.security.principal.WLSUserImpl "duane"
 2. weblogic.security.principal.WLSGroupImpl "employee"
 3. JpsPrincipal: oracle.security.jps.principals.JpsAuthenticatedRoleImpl "authenticated-role"
 4. JpsPrincipal: oracle.security.jps.principals.JpsAnonymousRoleImpl "anonymous-role"
 5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleEmployee")
 Permissions=(
 (java.util.PropertyPermission line.separator read)
 ...
 (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=default,keyName=* read,write))

パーミッション・チェックが成功した場合は、何も出力されません。パーミッション・チェックのメッセージを無効にするには、このプロパティをfalseに設定します。デフォルトで、これはtrueに設定されています。本番環境では、パーミッション・チェック・メッセージの無効化はお薦めしません。

L.1.2.2 jps.auth.debug.verbose

jps.auth.debugとjps.auth.debug.verboseを両方ともtrueに設定すると仮定します。

-Djps.auth.debug=true 
-Djps.auth.debug.verbose=true

この場合、パーミッション・チェックが成功すると出力が生成され、次の例に示すような詳細が表示されます。

[JpsAuth] Check Permission
          PolicyContext:        [jps-wls-Demo]
          Resource/Target:      [app.monitor]
          Action:               [read,write]
          Permission Class:     [java.util.PropertyPermission]
          Result:               [SUCCEEDED]
          Subject:              [total 5 of principals(
 1. weblogic.security.principal.WLSGroupImpl "manager"
 2. weblogic.security.principal.WLSUserImpl "shawn"
 3. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl "authenticated-role" GUID=null DN=null
 4. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl "anonymous-role" GUID=null DN=null
 5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleManager" GUID=null DN=null)]
          Evaluator:            [ACC]

パーミッション・チェックが失敗すると、次のような詳細な情報を記録した出力が生成されます。

JpsAuth] Check Permission
          PolicyContext:        [jps-wls-Demo]
          Resource/Target:      [app.monitor]
          Action:               [read,write]
          Permission Class:     [java.util.PropertyPermission]
          Evaluator:            [ACC]
          Result:               [FAILED]
          Failed ProtectionDomain:ClassLoader=weblogic.servlet.jsp.JspClassLoader@1b7682d finder: weblogic.utils.classloaders.CodeGenClassFinder@7d32cf annotation:
CodeSource=file:/C:/Mydom/domains/domain/servers/AdminServer/jspservlet/test.class
 Principals=total 5 of principals(
 1. weblogic.security.principal.WLSUserImpl "duane"
 2. weblogic.security.principal.WLSGroupImpl "employee"
 3. JpsPrincipal: oracle.security.principals.JpsAuthenticatedRoleImpl "authenticated-role" GUID=null DN=null
 4. JpsPrincipal: oracle.security.principals.JpsAnonymousRoleImpl "anonymous-role" GUID=null DN=null
 5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleEmployee" GUID=null DN=null)
 Permissions=(
 (java.util.PropertyPermission line.separator read)
 ... 
 (java.lang.RuntimePermission stopThread))
 Call Stack: java.security.AccessControlException: access denied (java.util.PropertyPermission app.monitor read,write)
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
 ...
 weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
          ProtectionDomains for class stack:
 Class[0]: class oracle.security.jps.util.JpsAuth$Diagnostic$SMSupport
 ProtectionDomain: ClassLoader=sun.misc.Launcher$AppClassLoader@360be0
 CodeSource=file:/C:/MyOracle/jdeveloper/modules/oracle.jps_11.1.1/jps-api.jar
 Principals=total 0 of principals<no principals>
 Permissions=(
 (java.io.FilePermission \C:\MyOracle\jdeveloper\modules\jps-api.jar read)
 ...
 )
 Class[1]: class oracle.security.jps.util.JpsAuth$Diagnostic$SMSupport

パーミッション・チェックのメッセージを無効にするには、jps.auth.debugとjps.auth.debug.verboseの両方をfalseに設定します。デフォルトで、jps.auth.debug.veboseはfalseに設定されています。

L.1.2.3 認可プロセスのデバッグ

この項では、各種基準に基づく認可プロセスのデバッグに役立ついくつかのシステム・プロパティの使用について説明します。特に次のプロパティについて解説します。

oracle.security.jps.log.for.approle.substring
oracle.security.jps.log.for.permeffect
oracle.security.jps.log.for.permclassname
oracle.security.jps.log.for.permtarget.substring
oracle.security.jps.log.for.enterprise.principalname

これらのプロパティは、次の認可フェーズ中にロギング・メッセージを生成します。

  • フェーズ1 - OPSSサブジェクト計算中にエンタープライズ・ユーザーまたはエンタープライズ・ロールに付与されたアプリケーション・ロール。

  • フェーズ2 - 権限受領者に付与されたパーミッション・インスタンス。

  • フェーズ3 - パーミッション・チェックの結果。つまり、権限が付与されたか、拒否されたか。

次に、前述の各プロパティと、これらが適用されるフェーズについて説明します。

oracle.security.jps.log.for.approle.substring - フェーズ1、2、3の間、指定した部分文字列を含むアプリケーション・ロール名をログに記録します。一致対象の部分文字列を指定しないと、すべてのアプリケーション・ロール名が記録されます。

oracle.security.jps.log.for.permeffect - フェーズ3の間、指定した値に従って、付与された権限または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限が記録されます。

oracle.security.jps.log.for.permclassname - フェーズ2および3の間、指定した名前に完全一致するパーミッション・クラス名をログに記録します。一致対象の名前を指定しないと、すべてのパーミッション・クラス名が記録されます。

oracle.security.jps.log.for.permtarget.substring - フェーズ2および3の間、指定した部分文字列を含むパーミッション・ターゲット名をログに記録します。一致対象の部分文字列を指定しないと、すべてのパーミッション・ターゲットが記録されます。

oracle.security.jps.log.for.enterprise.principalname - フェーズ1、2および3の間、指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)名をログに記録します。一致対象の名前を指定しないと、すべてのプリンシパル名が記録されます。

次の特性は、前述のシステム・プロパティのすべてに該当します。

  • オプションです。

  • 最大で1回のみ設定可能です。

  • 一致では、大文字と小文字は区別されません(一致が適用される場合)。

前述のシステム・プロパティのロギングを有効にするには、次のようにします。

  1. JVMを停止します。

  2. ロガーoracle.security.jps.dbg.loggerをTRACE:32に設定します。

  3. JVMを再起動します。

  4. デバッグするシナリオを実行します。

  5. ログ出力を調べます。前述のいずれかのプロパティの設定によるメッセージ出力を見つけるには、ログ・ファイル内でキーワード[oracle.security.jps.dbg.logger]を検索します。

L.1.2.3.1 使用例

次の例では、前述のシステム・プロパティの一般的な設定を示しています。

  • 部分文字列myAppRoleを含むすべてのアプリケーション・ロール名をログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.approle.substring=myAppRole

  • 拒否されたすべてのパーミッション・チェックをログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.permeffect=deny

  • 付与されたすべてのパーミッション・チェックをログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.permeffect=grant

  • 付与されたか、または拒否されたすべてのパーミッション・チェックをログに記録するには、oracle.security.jps.log.for.permeffectは設定しません。

  • クラス名java.util.PropertyPermissionに完全一致するすべてのパーミッション・チェックをログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.permclassname=java.util.PropertyPermission

  • 部分文字列p.monを含むすべてのターゲット名をログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.permtarget.substring=p.mon

  • プリンシパル名managerに関連するすべての認可をログに記録するには、次の設定を追加します。

    -Doracle.security.jps.log.for.enterprise.principalname=manager

  • 部分文字列に一致するアプリケーション・ロール名または文字列に一致するプリンシパル名をログに記録するには、oracle.security.jps.log.for.approle.substringとoracle.security.jps.log.for.enterprise.principalnameの両方を前述の手順で設定します。

  • すべてのアプリケーション・ロール名とすべてのプリンシパル名をログに記録するには、oracle.security.jps.log.for.approle.substringもoracle.security.jps.log.for.enterprise.principalnameも設定しません。

L.1.3セキュリティ・エラーの解決

エラーが発生したときに、そのエラーを解決する一般的な方法はありません。そのため、ヒントを検索し、できればエラーの原因を分離して理解するまで、多くの場合複数の仮定に従う必要があります。この目的を達成するために、この項では、ログ情報を検索して解釈し、最も一般的なセキュリティ・エラーを解決する方法について説明します。この項の内容は次のとおりです。

L.1.3.1 サンプル・ログ・エントリの理解

エラーを分離して解決するには、ログ・エラー出力を理解することが重要です。ここでは、診断ログ・ファイルの内容を詳しく調べ、このファイルに記録されているエラーに関して得られる情報について説明します。この場合、実際の例を使用して説明するのが最も効果的です。

次の例は、AdminServer-diagnostic.logファイルに記載されたエラーの抜粋です。

[2009-01-07T09:15:02.393-08:00] [AdminServer] [ERROR] [JPS-00004] [oracle.jps.admin] 
[tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]
Unable to add principal to the application role. Reason: Principal
"abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"[[
java.security.PrivilegedActionException:
oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException:
Unable to add principal to the application role. Reason: Principal "abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"
        at java.security.AccessController.doPrivileged(Native Method)
        at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)
        at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addMembersToApplicationRole(JpsApplicationPolicyStoreImpl.java:385)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
…

前述のメッセージの各フィールドの意味は、次のとおりです。

  • [2009-01-07T09:15:02.393-08:00]

    エラーがログに記録された日時を識別します。

  • [AdminServer]

    エラーが発生したサーバーの名前を識別します。

  • [JPS-00004]

    エラー・コードを識別し、発生したエラーの種類に関するヒントを示します。すべてのJPSエラー・コードのリストについては、Oracle Fusion Middlewareエラー・メッセージ・リファレンスの第41章を参照してください。

  • [oracle.jps.admin]

    ロガーのカテゴリを識別します。oracle.jpsのサブカテゴリ(前述のadminなど)は、発生したエラーの種類に対するヒントを与えます。oracle.jpsのサブカテゴリの詳細なリストは、「oracle.jpsのサブカテゴリ」を参照してください。

  • [tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)']

    エラーが発生したスレッドを識別します。

  • [userId: weblogic]

    エラーを生成した操作を実行したユーザーを識別します。

  • [ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]

    実行コンテキストIDを識別します。通常、イベントの順序を関連付けて追跡するために使用します。ecidは、リクエストからWebLogicサーバー、またはOracle Internet Directoryサーバーへのフローなど、プロセスをまたがるフローに関する情報を提供します。

  • Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin

    エラーがログに記録された理由を識別します。

  • java.security.PrivilegedActionException: oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException: Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin

    発生した例外とその理由を識別します。

oracle.jpsのサブカテゴリ

次のリストは、oracle.jpsのサブカテゴリと、各カテゴリで記録されるエラーの種類を示しています。

  • common - 一般的なエラー。

  • config - 構成エラー。

  • deployment - デプロイ・エラー。

  • authentication - JavaSEアプリケーションのみのログイン・モジュール・エラー。

  • idmgmt - アイデンティティ・ストア・エラー。

  • credstore - 資格証明ストア・エラー。

  • authorization - 実行時のポリシー・ストア・エラー。

  • policymgmt - ポリシー・ストア管理エラー。

  • admin - JMXエラーおよびWLSTエラー。

L.1.3.2 Fusion Middleware Controlを使用したログの検索

ドメイン内のすべてのログ・ファイルのコンテンツで検索を開始するには、「ドメイン」→「ログ」→「ログ・メッセージの表示」を選択して、「ログ・メッセージ」ページを表示します。

このページには、検索クエリを指定するために選択できる複数のパラメータがあります。具体的には、次の操作が可能です。

  • 適切な「日付範囲」を選択することで、メッセージが発行される期間を選択できます。

  • 「メッセージ・タイプ」ボックスのいずれかを選択することで、特定の重大度エラーを含むメッセージを表示できます。

  • 「メッセージ」メニューから項目を選択し、その横にあるボックスに文字列を入力することで、さらなる制約を満たすメッセージを表示できます。たとえば、文字列exceptionを含むメッセージに対してのみ問合せを行うことができます。

  • 「フィールドの追加」ボタンをクリックし、選択肢のいずれかを選択することによって、新たな問合せフィールドを追加できます。たとえば、「ホスト」フィールドを追加し、特定の文字列を先頭文字として指定した問合せ(「次で始まる」フィールドに入力)などを実行できます。

これらのパラメータを設定して、「検索」をクリックすると、問合せの結果がこのページに表示されます。問合せの結果は、「表示」メニューから項目を選択することで、メッセージ・タイプ別、メッセージID別、またはメッセージの単純なリストで詳細に表示し直すことができます。さらにこの結果を、ページの右上にあるメニューから項目を選択することで、自動的にリフレッシュすることもできます(デフォルトでは「手動リフレッシュ」に設定)。

検索範囲をドメインを越えたログ・ファイルにまで拡張するには、ページの右上にある「広範囲のターゲット・スコープ」ボタンを使用します。

L.1.3.3 Fusion Middleware Controlを使用したメッセージ・コンテキストの識別

場合によっては、メッセージが発生したコンテキストを知ることが必要になります。たとえば、特定のエラー・メッセージの2分前または2分後に発生したメッセージがわかると役に立つ場合があります。

「関連メッセージの表示」タブにはこの機能があります。この機能を使用する手順は次のとおりです。

  1. 「表示」を「メッセージ」に設定して、問合せの結果を表示します。

  2. 結果の表内でメッセージを選択します。このとき、「関連メッセージの表示」タブおよび「メッセージをファイルにエクスポート」タブが使用可能になっていることに注意してください。たとえば、選択したメッセージのタイムスタンプが、Jan 21, 2009 4:05:00 PM PSTであると仮定します。

  3. 「日付範囲」メニューから「時間間隔」を選択し、「開始日」と「終了日」を入力します。たとえば、開始日としてJan 21, 2009 4:02:00 PM、終了日としてJan 21, 2009 4:07:00 PMを入力できます。

  4. 「関連メッセージの表示」メニューから「時間ごと」を選択すると、選択したメッセージに関連する、指定した期間内のすべてのメッセージが表示されたページが開きます。

  5. 「時間別の関連メッセージ」ページで、ページの右側にある「有効範囲」メニューから項目を選択することで、選択したメッセージの時間前後の時間ウィンドウを変更できます。

L.1.3.4 Fusion Middleware Controlを使用したエラー・リスト・ファイルの生成

別のファイルに表示されたエラーのリストをダウンロードし、転送することが必要になる場合があります(サポート・センターに転送する場合や、記録として残しておく場合など)。

「メッセージのエクスポート」タブが使用可能な場合はいつでも、メニューから項目を選択することで、表示された結果のみを含むファイルを生成できます。生成できるファイルの形式は、プレーン・テキスト、XMLまたはCSVです。

次の例は、このようにして生成されたテキスト・ファイルの抜粋であり、29件のメッセージのうちの最初の部分のみが示されています。

#
#Search Criteria
#        Start Time: 2009-01-21T16:34:41.381-08:00
#        End Time:  2009-01-21T16:39:41.381-08:00
#        Message Types: ERROR, WARNING
 
#Selected Targets List
#        /Farm_base_domain/base_domain/AdminServer:Oracle WebLogic Server
#        /Farm_base_domain/base_domain/AdminServer/DMS Application(11.1.1.1.0):Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/em:Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/wsil-wls:Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/wsm-pm:Application Deployment
#
[2009-01-21T16:34:54.045-08:00] [AdminServer] [WARNING] [] [org.apache.myfaces.trinidad.bean.PropertyKey] [host: stacz39] [nwaddr: 140.87.5.40] [tid: 13] [userId: <anonymous>] [ecid: 0000HvvkgjVE^MT6uBj8EH19TvXj000008,0] [APP: em] [Target: /Farm_base_domain/base_domain/AdminServer/em] [Target Type: Application Deployment] Unserializable value:oracle.sysman.core.view.tgtctls.common.DefaultTreeModel@1fcadd2 for key:UINodePropertyKey[value,17]
…
#
#Number of messages exported: 29
#

L.2 再関連付けの失敗

ファイルベースのストアからLDAPベースのストアへのポリシーおよび資格証明の再関連付けは、いくつかの理由で失敗することがあります。この項では、この操作が失敗する3つの理由について説明します。

現象1- エラー・コード32

再関連付けが失敗し、次のようなエラーが管理サーバー診断ファイルserverName.diagnostic.logに記録されます。

[LDAP: error code 32 - No Such Object]
Authentication to LDAP server ldap://myServer.com:3060 is unsuccessful.

診断1

前述のエラーは、LDAPサーバーのターゲット・ノードにおける問題を識別します。つまり、指定したノードが存在しません。

再関連付けを起動する前に、「JPSルートDN」テキスト・ボックス(「セキュリティ・プロバイダの設定」ページ)で指定したルート・ノードがLDAPディレクトリに存在する必要があります。

解決策1

「JPSルートDN」ボックスに入力したデータが、ターゲットLDAPディレクトリのノードの名前に一致することを確認し、再関連付けを再実行します。

現象2- エラー・コード68

再関連付けが失敗し、次のようなエラーが管理サーバー診断ファイルserverName.diagnostic.logに記録されます。

Authentication to LDAP server ldap://myServer.com:3060 is successful.
Starting to migrate policy store...
Set up security provider reassociation successfully.
Checked and seeded security store schema successfully.
null
[LDAP: error code 68 - Object already exists]:cn=SystemPolicy,cn=domain1,cn=JPSContext,cn=nb_policy
Error occurred while migrating LDAP based policy store.

診断2

前述のエラーは、「WebLogicドメイン名」ボックスで指定された名前が、ターゲットLDAPディレクトリの「JPSルートDN」ノードの子孫(正確には、孫)であることを示しています。

指定するドメインはルート・ノードの子孫であってはなりません。

解決策2

「WebLogicドメイン名」ボックスに入力した名前が、指定された「JPSルートDN」ノードの孫の名前に一致していないことを確認し、再関連付けを再実行します。

現象3

Fusion Middleware Controlを使用して実行された再関連付けが失敗し、次のようなエラーが管理サーバー診断ファイルserverName.diagnostic.logに記録されます。

[2009-01-21T10:09:24.326-08:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid
: [ACTIVE].ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)
'] [userId: weblogic] [ecid: 0000HvuOTpe7q2T6uBADUH19Tpyb000006,0] Unable to rem
ove the principal from the application role. Reason: Principal "Managers" is not
a member of the application role "test-role"[[
java.security.PrivilegedActionException: oracle.security.jps.service.policystore
.PolicyObjectNotFoundException: Unable to remove the principal from the applicat
ion role. Reason: Principal "Managers" is not a member of the application role "
test-role"
       at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl
.addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)...

診断3

前述のエラーは、アプリケーション・ロールtest-roleで発生したなんらかの問題を示しています。この場合、これが問題の根源です。

データを入力し、Fusion Middleware Controlを使用して再関連付けを実行する際、ターゲットLDAPサーバーに接続するために必要なすべての値の入力が完了した直後に、「LDAP認証のテスト」ボタンを使用してください。このテストにより、再関連付けが開始される前に、これらの値を使用したときに発生する可能性のある問題を見つけることができます。

解決策3

この例で、ファイルsystem-jazn-data.xmlを迅速に検査した結果、アプリケーションtest-roleがアプリケーション・ポリシーによって使用されていますが、定義されていなかったことが明らかになりました。次の例はこのファイルの抜粋であり、必要なデータが不足していることを示しています。

<application>
    <name>myApp</name>
        <app-roles>
 <--! test-role should have been defined here -->
        </app-roles>
        <jazn-policy>
            <grant>
                <grantee>
                    <principals>
                       <principal>
                         <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                         <name>test-role</name>
                         <guid>66368900E7E511DD9F62F9ADA4233FE2</guid>
                       </principal>
                     </principals>...

この特定のエラーを解決するには、(a)アプリケーションtest-roleの定義を挿入することでsystem-jazn-data.xmlを修正し、(b)修正したファイルを使用してファイルベースのドメイン・ストアに戻して、(c)再関連付けを再実行します。

L.2.1 再関連付けしたポリシー・ストアのポリシーの欠落

現象

LDAPベースのOracle Internet Directoryポリシー・ストアを使用するようにファイルベースのポリシー・ストアを再関連付けすると、この再関連付けが正常に完了したとレポートされる場合があります。

ところが、実行時にシステムが予期したとおりに動作しません。移行後にシステム・ポリシーに存在するはずの、付与されたコードベースのポリシーが欠落しています。

診断

実行時にサーバーは次のようなスタック・トレースをレポートします。

<BEA-000000> <JspServlet: initialization complete>
####<May 4, 2009 8:32:50 AM PDT> <Error> <HTTP> <ap626atg> <WLS_Spaces>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <> <> <1241451170341> <BEA-101020>
<[ServletContext@20193148[app:webcenter module:/webcenter path:/webcenter
spec-version:2.5]] Servlet failed with Exception
java.security.AccessControlException: access denied
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy)
        at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at
java.security.AccessController.checkPermission(AccessController.java:546)
        at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:348)
        at
oracle.security.jps.util.JpsAuth$Diagnostic.checkPermission(JpsAuth.java:268)
        at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$6.checkPermission(JpsAuth.java:372)
        at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:408)
        at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:431)
        at
oracle.security.jps.internal.policystore.AbstractPolicyStore.checkPolicyStoreAccessPermission(AbstractPolicyStore.java:246)
        at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.getApplicationPolicy(LdapPolicyStore.java:281)
        at
oracle.security.jps.internal.policystore.PolicyUtil.getGrantedAppRoles(PolicyUtil.java:898)
        at
oracle.security.jps.internal.policystore.PolicyUtil.getJpsAppRoles(PolicyUtil.java:1354)
        at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:273)
        at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:270)
        at java.security.AccessController.doPrivileged(Native Method)

パーミッションは次のとおりです。

oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy

これはコード・ベースに付与され、falseと評価されたために認可されません。

解決策

AdminServer診断ログで次のようなメッセージを確認します。

AdminServer-diagnostic.log:[2009-05-28T02:27:52.249-07:00] [AdminServer] [NOTIFICATION] [JPS-00072] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Policy schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0
AdminServer-diagnostic.log:[2009-05-28T02:28:58.012-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Credential store schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0

このタイプのメッセージは、再関連付けの際にスキーマがシードされなかったことを示しています。Oracle Internet Directoryサーバーで適切なスキーマがシードされていないと、システムは予期したとおりに動作しません。

再関連付けの際にスキーマが必ずシードされるようにするには、次の手順に従います。

  1. Oracle Internet Directoryサーバーのcn=OracleSchemaVersionコンテナの下にあるcn=OPSSコンテナを削除します。

  2. このファイルベースのストアを使用しているOPSSポリシー・ストアの正常に動作しているインスタンスを起動します。

  3. このファイルベースのストアをOracle Internet Directoryサーバーに再関連付けします。

AdminServer診断ログで次のメッセージを探して、OPSS LDAPスキーマがLDAPサーバーでシードされたことを確認します。

AdminServer-diagnostic.log:[2009-05-29T07:18:18.002-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-12] [ecid: 0000I61Z0MH0fplp4sm3Ui1A7_Ll00002s,1:5001] [arg: 11.1.1.0.0]  Policy schema version set to 11.1.1.0.0

リリース11g Oracle Internet Directoryサーバーに再関連付けしたスキーマのバージョンは11.1.1.1.0になります。

リリース10.1.4.3 Oracle Internet Directoryサーバーに再関連付けしたスキーマのバージョンは11.1.1.0.0になります。

ポリシー・ストアのスキーマのバージョンは、Oracle Internet Directoryサーバーで次のコンテナによって設定されます。

cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion

同様に、資格証明ストアのスキーマのバージョンは、Oracle Internet Directoryサーバーで次のコンテナによって設定されます。

cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion

L.3 サーバーの起動の失敗

この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。この項の内容は次のとおりです。

L.3.1 必須のLDAP認証プロバイダの欠落

この項では、ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗する可能性がある理由について説明します。

現象

ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗し、出力されるエラー・メッセージに次の内容が含まれます。

java.lang.IllegalArgumentException: null KeyStore name

診断

この問題の原因の1つは、ドメイン内の認証プロバイダのリストに、LDAP認証プロバイダが含まれていないことです。


重要:

OPSSを使用するすべてのドメインで、このリストのいずれかのLDAP認証プロバイダが必須です。

解決策

サーバーを起動できないため、次の手順に従って、手動で1つのLDAP認証プロバイダを追加する必要があります。

  1. ファイルDOMAIN_NAME/config/config.xmlを開きます。

  2. config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダなどの、LDAP認証プロバイダを含めます。

    <realm>
 ...
 <sec:authentication-provider xsi:type="wls:default-authenticatorType"> 
 </sec:authentication-provider>
 ...
</realm>

  3. サーバーを再起動します。

サーバーが再起動して稼働したら、WebLogic管理コンソールを使用して、希望のプロバイダを含むようにプロバイダのリストを変更できますが、少なくとも1つのプロバイダをLDAP認証プロバイダにする必要があります。

この目的のために、次の手順に従って、WebLogic管理コンソールを使用します。

  1. 「新しい認証プロバイダの作成」ページに移動します。

  2. 認証プロバイダ名を入力して、認証プロバイダのタイプ(次に示すLDAPベースのもの)を選択します。

    • ActiveDirectoryAuthenticator

    • DefaultAuthenticator(これは、前述の例で手動で挿入したものです)

    • LDAPAuthenticator

    • LDAPX509IdentityAsserter

    • OpenLDAPAuthenticator

    • OracleInternetDirectoryAuthenticator

    • OracleVirtualDirectoryAuthenticator

L.3.2 管理者アカウントの欠落

この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。

現象

追加設定なしで使用できるデフォルトの認証プロバイダを削除して、Oracle Internet Directory認証プロバイダなどを追加すると、サーバーの起動に失敗します。

診断

追加した認証プロバイダにAdministratorsグループのアカウント・メンバーを入力することを忘れている可能性が高いと考えられます。サーバーでは、1つのドメイン認証プロバイダにこのようなアカウントが存在することが要求されます。このアカウントは、デフォルトの認証プロバイダに常に存在します。

解決策

サーバーを起動できないため、次の手順に従って、削除された1つのLDAP認証プロバイダを手動で追加する必要があります。

  1. ファイルDOMAIN_NAME/config/config.xmlを開きます。

  2. config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダを含めます。

    <realm>
 ...
 <sec:authentication-provider xsi:type="wls:default-authenticatorType"> 
 </sec:authentication-provider>
 ...
</realm>

  3. サーバーを再起動します。

サーバーが再起動して稼働したら、次の手順を実行します。

  1. WebLogic管理コンソールを使用して、Oracle Internet Directory認証プロバイダに、Administratorsグループのメンバーであるアカウントを作成します。

  2. Oracle Internet Directory認証プロバイダのフラグを、SUFFICIENTに設定します。

  3. サーバーを再起動します。デフォルトの認証プロバイダに指定されたAdministratorsグループのアカウントを使用しているので、問題なく起動するはずです。

  4. Oracle Internet Directory認証プロバイダのフラグをREQUIREDに再設定して、デフォルトの認証プロバイダを削除します。これで、Oracle Internet Directory認証プロバイダに作成したAdministratorsグループのアカウントを使用して、サーバーが起動します。

L.3.3 パーミッションの欠落

この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。

現象

システム・プロパティ-Djava.security.managerを使用して、セキュリティ・マネージャを有効にした状態でサーバーを起動すると、起動に失敗します。

診断

この問題が発生する理由の1つは、サーバー起動時にセキュリティ・マネージャを有効にした際、oraclepki.jarでPKI APIへのパーミッションの付与が欠落していることです。

解決策

ファイルweblogic.policyに次のような権限付与が存在することを確認し、存在しない場合は追加します。

grant codeBase "file:${oracle.home}/modules/oracle.pki_${jrf.version}/*" { 
 permission java.security.AllPermission; 
};

デフォルトでは、前述の権限付与が指定されています。セキュリティ・マネージャを有効にした場合、すべてのシステム・リソースへのアクセスに、コードベースのパーミッション付与が要求されることに注意してください。

Java Security Managerを使用したWebLogicリソースの保護のすべての詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。


注意:

Printing Security Managerは、Javaセキュリティ・マネージャに対するWebLogicサーバーの拡張機能です。Printing Security Managerを使用して、Javaセキュリティ・マネージャの下で実行されているJavaアプリケーションで必要なすべてのパーミッションを識別できます。必要なパーミッションを一度に1つずつ識別するJavaセキュリティ・マネージャとは異なり、Printing Security Managerは、必要なパーミッションのすべてを自動的に識別します。

L.3.4 その他の原因

この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。

現象

ポリシー・プロバイダをロードして設定しようとするときに、Oracle WebLogic Serverが起動に失敗し、次のスニペットに似た例外がログに記録されます。

<Mar 30, 2010 3:15:54 PM EDT> <Error> <Security> <BEA-090892> <The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...
<Mar 30, 2010 3:15:54 PM EDT> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...
weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...

診断

サーバーの起動には、構成ファイルjps-config.xmlの定義に基づくポリシー・プロバイダのロードと設定が含まれます。このタスクが正常に終了しないと、Oracle WebLogic Serverは起動に失敗します。前述のサンプルに明らかなように、このタイプの失敗は、サーバーのログで次の文字列によって識別されます。

Exception was thrown when loading or setting the JPSS policy provider.

特定のサーバーの起動の失敗の根本原因を調べるには、そのサーバーのログ・ファイルをチェックし、記録されたスタック・トレースを確認します。エラーの特定の詳細は、「セキュリティ・エラーの診断」を参照してください。

サーバーが起動に失敗する理由を次にいくつか示します。

  1. 構成ファイルのパスの指定に誤りがあります。

  2. 構成ファイルにデフォルトのコンテンツが欠落しています。

  3. XMLパーサーが利用不能です。

  4. システム・ポリシーに指定されたコード・ソースURLに誤りがあります。この状況は、次の文字列を含む例外がログに記録されていることで識別されます。

    java.net.MalformedURLException: unknown protocol.

解決策

次に、前述の各原因に対する解決策について説明します。

  1. システム・パラメータoracle.security.jps.configに正しいパスが指定されていることを確認します。

    -Doracle.security.jps.config=<full-path-to-jps-config.xml>

    フルパスの指定時には、特殊文字(バックスラッシュや空白文字など)は正しくエスケープ処理する必要がある点に注意してください。指定内容に誤りがないか確認する方法の1つとして、なんらかのコマンドラインでそのフルパスを使用してみます。

  2. 構成ファイルには、デフォルトのコンテキストが含まれている必要があります。デフォルトのコンテキストの例は、<jpsContext>を参照してください。

  3. 使用システムでXMLパーサーが利用できることと、クラスパスにXMLパーサーのJARファイルが含まれていることを確認します。

  4. 次の2つのサンプルは、誤ったコード・ソースURLと正しいコード・ソースURLの一般的な例を示しています。

    Sample 1 - Incorrect URL
<grantee>
  <codesource>
     <url>${my.oracle.home}/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>
 
Sample 1 - Corrected URL (in bold)
<grantee>
  <codesource>
     <url>file:/${my.oracle.home}/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>
 
Sample 2 - Incorrect URL
<grantee>
  <codesource>
     <url>c:/myfolder/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>
 
Sample 2 - The corrected URL (in bold) is either one of the following three:
<grantee>
  <codesource>
     <url>file:///c:/myfolder/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>
 
<grantee>
  <codesource>
     <url>file:c:/myfolder/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>
 
<grantee>
  <codesource>
     <url>file:/c:/myfolder/jlib/webcacheua.jar</url> 
   </codesource>
</grantee>

    コード・ソースでのURLの指定構文(システム変数の使用を含む)の詳細は、 <url>を参照してください。

L.4 パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

この項では、エンタープライズ・ユーザーまたはロール(グループ)へのパーミッションの付与または取消に失敗する、よくある理由について説明します。

現象

ドメイン認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに対して、権限付与で定義されたパーミッションが付与または取消されません。

診断

この問題は、(ドメイン認証プロバイダに)格納されている名前と、(ユーザーがアクティブに入力したか、プログラムによって取得された)指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致の例として、格納されているユーザー名がJdOEで、指定されたユーザー名がjdoeである場合が挙げられます。

解決策

この問題を解決するには、次の2つの方法があります。

1つ目の解決策としては、ドメインに使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列(格納されているものと指定されたもの)に、(大文字小文字関係なく)同じ順序の文字が含まれているかぎり、この設定により、対応する文字の大文字小文字が異なっている場合でも、サブジェクトに入力されたユーザー名が、ドメイン認証プロバイダに存在するユーザー名に一致することが保証されます。したがって、この設定が機能している場合、JdOEというユーザー名とjdoeというユーザー名は一致します。

ドメイン認証プロバイダのプロパティを設定するには、次の手順に従います。

  1. 管理コンソールを使用して認証プロバイダの構成ページに移動します。たとえば、デフォルトの認証プロバイダを使用している場合は、「レルム」→「myrealm」→「プロバイダ」→「DefaultAuthenticator」を選択して、DefaultAuthenticatorページに移動します。

  2. 「プロバイダ固有」タブを選択します。

  3. プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。

  4. サーバーを再起動します。

2つ目の解決策では、指定された名前をプログラムによって取得する、つまりユーザー名からプリンシパルを生成する場合を考えます。

正しいユーザーまたはグループ名を取得するには、認証プロバイダに格納されている名前を正確にそのまま渡すか、次のコード・スニペットに示すコール・シーケンスを使用します。

import weblogic.security.principal.WLSGroupImpl;
import weblogic.security.principal.WLSUserImpl;
 
// Set the context
JpsContextFactory ctxFact = JpsContextFactory.getContextFactory();
ServerContextFactory scf = (ServerContextFactory) ctxFact;
JpsContext ctx = scf.getContext(ServerContextFactory.Scope.SYSTEM);
ctx = ctxFact.getContext();

// Set the identity store
IdentityStore identityStore = ctx.getServiceInstance(IdentityStoreService.class).getIdmStore();
 
// In case of a user name, search the user that matches the supplied name
User user = idStore.searchUser(IdentityStore.SEARCH_BY_NAME, suppliedUserName);

// Use the obtained object (user) to obtain the stored user name and create 
// the Principal
String storedUserName = user.getName();
Principal userPrincipal = new WLSUserImpl(storedUserName);
 
// Similarily, in case of a role name, search the role that matches 
// the supplied role name
Role role = identityStore.searchRole(IdentityStore.SEARCH_BY_NAME, suppliedRoleName);
 
// Use the obtained object (role) to obtain the stored role name and create 
// the Principal
String storedRoleName = role.getName();
Principal rolePrincipal = new WLSGroupImpl(storedRoleName);

重要:

ユーザーまたはロールのプリンシパルを作成するときには、次のコールを使用する必要があります。 
Principal userPrincipal = new WLSUserImpl(user.getUserProfile()getName());
Principal rolePrincipal = new WLSGroupImpl(role.getRoleProfile().getName());

または、かわりに次のコールを使用します。

Principal userPrincipal = new WLSUserImpl(user.getName());
Principal rolePrincipal = new WLSGroupImpl(role.getName());

L.5 LDAPサーバーへの接続の失敗

この項では、Oracle Internet Directory LDAPサーバーへの接続が失敗する場合に多く見られる理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。

現象

ソース・リポジトリからターゲットLDAPサーバー・リポジトリへのデータの移行が失敗します。

診断

通常、この種の問題は、ターゲットLDAPサーバーのパラメータ設定が間違っていることが原因です。

Oracle WebLogic Serverのログ・ファイルを調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリ内のログ・ファイルで、<Error>、<Critical>および<Warning>という文字列を検索してください。

エラーを特定して解決する方法の詳細は、第L.1項「セキュリティ・エラーの診断」を参照してください。

解決策

移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。この確認を行うために、LDAPサーバー管理者の支援が必要になる場合があります。


注意:

Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、操作を開始する前に、「LDAP認可のテスト」ボタンを使用してください。通常は、このテストにより、間違って指定されたパラメータを見つけることができます。

L.6 組込みのLDAP認証プロバイダへの接続の失敗

この項では、組込みのLDAP認証プロバイダへの接続に失敗する場合に多く見られる理由について説明します。

現象

クライアント・アプリケーションがユーザーおよびロールAPIを介して組込みのLDAP認証プロバイダに問合せをリクエストするために使用される接続は、接続プールに格納され、維持されます。デフォルトおよび出荷時の状態では、このプールは、JNDIプールとしてファイルjps-config.xmlに指定されています。

このプールの同時接続数が、LDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続中の場合はsocket closed例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。

診断

この制限を超えないようにするには、LDAPサービスで許容する最大同時接続数をアプリケーションのニーズに合わせて調整する必要があります。このしきい値はきめ細かく調整する必要があります。最大値が小さすぎると十分でなく(その結果、前述の例外が発生します)、最大値が大きすぎると、DoS攻撃のリスクが生じる場合があります。適切な最大値は、アプリケーションと、そのアプリケーションで使用する特定のLDAPサービスに依存します。

解決策

この問題の解決方法として次の2つの選択肢があります。

注意点として、(a)これらの設定は相互排他的ではなく、両方実行することも可能なことと、(b)どちらの場合も変更を有効化するにはサーバーを再起動する必要があることに留意してください。

L.7 ユーザーおよびロールAPIの失敗

この項では、ユーザーおよびロールAPIでドメイン認証プロバイダのデータへのアクセスに失敗する理由をいくつか説明します。

現象

ユーザーおよびロールAPIで、構成された認証プロバイダのデータへのアクセスに失敗します。

診断1

OPSSユーザーおよびロールAPIでは、ドメイン内で最初に構成されたLDAP認証プロバイダのデータにのみアクセスできます。このような認証プロバイダが少なくとも1つ、ドメイン内に存在する必要があります。その認証プロバイダにターゲット・ユーザーが存在しない場合、そのユーザーが他のドメイン認証プロバイダに存在しても、APIではその最初のLDAP認証プロバイダへのアクセスに失敗します。

解決策1

この存在していないユーザーを最初のLDAP認証プロバイダに入力するか、またはドメイン内のLDAP認証プロバイダのリストの順序を並べ替えます。

診断2

ドメイン内で最初に構成されたLDAP認証プロバイダに、APIが失敗した際のターゲット・ユーザーが存在すると仮定します。

デフォルトでは、ユーザーおよびロールAPIでは、属性uidを使用してLDAP認証プロバイダでユーザー検索を実行します。らかの理由で、LDAPで入力したユーザーにこの属性が欠落している場合、ユーザーおよびロールAPIは失敗します。

解決策2

最初のLDAP認証プロバイダのすべてのユーザーに、属性uidが設定されていることを確認します。


注意:

J2SEアプリケーションを開発する場合のみ、ユーザーおよびロールAPIでデフォルト(uid)以外の属性(mailなど)を使用してユーザーを検索するには、次のコードにあるように、username.attrプロパティおよびuser.login.attrプロパティを、(jps-config-jse.xmlファイルにある)アイデンティティ・ストアのLDAPプロバイダ・インスタンスで構成する必要があります。 
<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
   ...
   <property name="username.attr" value="mail"/>
   <property name="user.login.attr" value="mail"/>
   ...
</serviceInstance>

指定したスクリプトを使用してプロバイダ・インスタンスにプロパティを追加するには、第E.1項「WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

L.8 ドメイン資格証明ストアのデータへのアクセスの失敗

この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。

現象

アプリケーションが、ドメイン資格証明ストアからの資格証明データの取得に失敗し、(次に示すような行を含む)エラー・メッセージがログに記録されます(角カッコ内のテキストには、特定の失敗に固有の情報が記述されます)。

07/07/26 18:22:22 [JpsAuth] For permisson ( CredentialAccessPermission [target] [actions]), domain that failed: ProtectionDomain
 cs(file:somePath/aWarFile.war/WEB-INF/classes/), []

診断

アプリケーションが資格証明ストアにアクセスして操作(ユーザー・パスワードの取得など)を実行する場合、保護された操作を実行するために、そのコードに適切なパーミッションを付与する必要があります。パーミッションが付与されない場合、前述したようなエラーがアプリケーションで発生します。

解決策

資格証明ストアへのアクセスにアプリケーションが必要とするパーミッションを付与するには、アプリケーションのjazn-data.xmlに適切なCredentialAccessPermissionを含めます。この権限付与は、アプリケーションをデプロイまたは再デプロイするときに有効になります。

Fusion Middleware Controlを使用してパーミッションを指定するには、第9.2項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。

OPSSスクリプトを使用してパーミッションを指定するには、第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」を参照してください。

ファイルjazn-data.xmlの次のフラグメントには、アプリケーションmyApp内のすべてのコードに、フォルダmyAlias内のすべての資格証明を読み取るパーミッションを付与する方法が示されています。

<jazn-data>
    <!--  codebase policy -->
    <jazn-policy>
        <grant>
            <grantee>
                <codesource>
 <!-- This grants applies to all code in the following directory -->
                    <url>${domain.home}/tmp/_WL_user/myApp/-</url>
                </codesource>
            </grantee>
            <permissions>
                <permission>
                    <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<!-- Allow read permission to all credentials under folder MY_MAP -->
                    <name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
                    <actions>read</actions>
                </permission>
            </permissions>
        </grant>
    </jazn-policy>
</jazn-data>

L.9 匿名SSL接続の確立の失敗

この項では、ポリシーと資格証明の再関連付けを行うときに匿名SSL接続を確立できない、よくある理由について説明します。

現象

Fusion Middleware Controlを使用してOracle Internet Directoryサーバーによるファイルベースのポリシーおよび資格証明とLDAPベースの記憶域の再関連付けを行う際の手順として、LDAPサーバーへの匿名SSL接続をテストします(具体的には、LDAPのテストボタンを使用します)。その結果、このテストに失敗します。

診断

ターゲットLDAPサーバーがOracle WebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。

解決策

LDAPサーバーへの接続を確立するには、LDAPサーバー上であらかじめ一部の構成を行っておく必要があります。詳細は、第8.2.2項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このポートを使用してLDAPサーバーを構成しなかった場合、接続は失敗します。

指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。通常、このポートの設定はLDAPサーバーの管理者が行います。

L.10 認可チェックの失敗

この項では、認可チェックが失敗する理由について説明します。

現象

アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。

Servlet failed with Exception oracle.adf.controller.security.AuthorizationException:ADFC-0619:
Authorization check failed: '/StartHere.jspx' 'VIEW'.

診断

このような認可の失敗が発生する理由の1つは、実行時ポリシー・コンテキストと、アプリケーションで使用するポリシー・ストア・ストライプとの間の不一致です。

一方では、アプリケーションで使用するアプリケーション・ストライプ(またはポリシー・ストア内のポリシーのサブセット)が、パラメータapplication.nameを含むファイルweb.xmlに指定されています。このパラメータは、JpsFilterを構成するフィルタ(サーブレットの場合)またはJpsInterceptorを構成するインターセプタ(EJBの場合)内にあります。詳細および例は、「アプリケーション名(ストライプ)」を参照してください。アプリケーション・ストライプが指定されていない(または空白になっている)場合、アプリケーション名に基づいて、アプリケーション・ストライプが取得されます。

もう一方では、アプリケーションで使用する実行時ポリシーが、要素<application.name>を含むファイルsystem-jazn-data.xmlに指定されています。

これらの2つの名前が一致しない場合、または使用するストライプを明示的に指定していない場合、アプリケーションが間違ったポリシー・ストライプにアクセスするため、予期したとおりにアプリケーション・ユーザーを認可できなくなる可能性が高くなります。

解決策

アプリケーション・ストライプを明示的に指定し、そのストライプが、アプリケーションで使用することになっているストライプであることを確認します。ほとんどの場合、(前述したように)これらの2つの異なるファイルに指定された2つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。

L.11 ユーザーによる予期しないパーミッションの取得

この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。

現象

新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。

診断

この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多くの(または少ない)パーミッションを取得する、よくある理由は、ユーザーを削除する前またはユーザー・データを変更する前に、ポリシー・ストアが適切に更新されていないことです。

解決策

ユーザーを削除する前に、ユーザーに付与されていたすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、ロール)を更新して、新しいデータでも予期したとおりに機能するようにする必要があります。

L.12 セキュリティ・アクセス制御の例外

この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。

<Jan 20, 2009 5:45:33 PM PST> <Error> <HTTP> <BEA-101020>
<[weblogic.servlet.internal.WebAppServletContext@140cf52 
- appName: 'Application2', 
name: 'Application2.war', 
context-path: '/Application2', 
spec-version: '2.5'] 
Servlet failed with Exceptionjava.lang.RuntimeException:java.security.AccessControlException:access denied
...

診断

前述のエラーは、コード内のコールに、保護された操作を実行するための十分なパーミッションがないことを意味しています。

解決策

保護された操作を実行するために、コードに十分なパーミッションを付与する必要があります。設定するパーミッションの範囲に応じて、2つの選択肢があります。

1つ目は、アプリケーションのEARファイルまたはWARファイル内のすべてのアプリケーション・コードにパーミッションを付与する方法です。この場合、保護された操作へのコールを、アプリケーション・コードの任意の場所に挿入できます。

2つ目は、JARファイルにのみ権限を付与する方法です。この場合、保護された操作へのコールが、権限が付与されたブロック内部にある必要があります。

これらの解決策をそれぞれ、資格証明ストアへのアクセスを試みるアプリケーションの例によって次に示します。

アプリケーションjazn-data.xmlの次のコードは、資格証明ストアにあるマップMY_MAP内のあらゆるキーをディレクトリBasicAuthにある任意のコードに読み取るためのパーミッションの設定方法を示しています。

<jazn-policy>
   <grant>
       <grantee>
           <codesource>
              <url>file:${domain.home}/servers/_WL_user/BasicAuth/-</url>
           </codesource>
       </grantee>
       <permissions>
           <permission>
             <class>
                 oracle.security.jps.service.credstore.CredentialAccessPermission
             </class>
             <name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
             <actions>read</actions>
          </permission>
      </permissions>
   </grant>
</jazn-policy>

特定のEARファイルまたはWARファイル内のコードにパーミッションを付与する場合、前述のurl指定を次のように変更する必要があります。

<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/.../BasicAuth.ear</url>

前述の両方のケースで、資格証明ストアを読み取るコールを、アプリケーション・コード内の任意の場所に配置できます。

ただし、特定のJARファイル内のコードに対してのみ、パーミッションを付与する場合、前述のurl指定を次のように変更する必要があります。

<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/myJars/Foo.jar</url>

この最後のケースでは、資格証明ストアに対する読取り操作をコールするファイルFoo.jarのコードを、次のコードSnippetに示すように、AccessController.doPrivilegedブロック内に配置する必要があります。

import oracle.security.jps.*;
import oracle.security.jps.service.credstore.*;
 
JpsContextFactory factory = JpsContextFactory.getContextFactory();
JpsContext jpsContext = factory.getContext();
final CredentialStore store = jpsContext.getServiceInstance(CredentialStore.class);
Credential cred = AccessController.doPrivileged(new PrivilegedExceptionAction<PasswordCredential>() {
    public PasswordCredential run() throws JpsException {
        return store.getCredential("MY_MAP", "anyKey");
    }
});
           
PasswordCredential pwdCred = (PasswordCredential)cred;
...

前述の権限付与の例では、読取り操作のみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。

L.13 パーミッション・チェックの失敗

この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。

[JpsAuth] Check Permission
          PolicyContext:        [null]
          Resource/Target:      [test]
          Action:               [null]
          Permission Class:     [com.oracle.permission.SimplePermission]
          Evaluator:            [ACC]
          Result:               [FAILED]
          Failed ProtectionDomain:ClassLoader=weblogic.utils.classloaders.ChangeAwareClassLoader@14061a8 
finder: weblogic.utils.classloaders.CodeGenClassFinder@2dce7a8 
annotation: Application2@Application2.war
CodeSource=file:/scratch/servers/AdminServer/tmp/permission/TestServlet$1.class
Principals=total 0 of principals<no principals>
Permissions=(
(oracle.security.jps.service.credstore.CredentialAccessPermission 
context=SYSTEM,mapName=default,keyName=* read,write)
(java.net.SocketPermission localhost:1024- listen,resolve)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=* getApplicationPolicy)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=SYSTEM getConfiguredApplications)
(com.oracle.permission.SimplePermission *)
...
java.security.AccessControlException: access denied
(com.oracle.permission.SimplePermission test)...

診断

2つ以上のアプリケーションがパーミッション・クラスを共有している場合、そのパーミッション・クラスをシステム・クラス・パスに設定して、そのクラスを一度だけロードする必要があります。そうしないと、クラスをロードする最初のアプリケーションのみがパーミッション・チェックに合格し、その後、同じクラスをロードする他のアプリケーションはパーミッション・チェックに合格せず、前述のようなエラーを出力することがあります。

パーミッション・クラスがパーミッション・コレクション内にあっても(前述の出力例内の太字のテキストを参照)、チェックに合格せず、アクセスが拒否されることに注意してください。これは、その時点で同じ名前のパーミッション・クラスのインスタンスが複数環境に含まれているためです。

解決策

同じドメイン内で実行される2つ以上のアプリケーションが、1つのパーミッション・クラスを共有する場合、システム・クラス・パスにそのクラスを含めてください。

L.14 ポリシーの移行の失敗

この項では、アプリケーション・デプロイ時のポリシーの自動移行が失敗する理由について説明します。アプリケーションのデプロイは、ポリシーの移行に失敗しても、成功する場合があることに注意してください。


注意:

この項で説明されている自動移行に失敗する理由が、ドメイン・ストアの再関連付けを行う際にも、同様の失敗につながる可能性があります。

現象

デプロイ時にポリシーを自動的に移行するように、アプリケーションが構成されています。アプリケーションのデプロイは成功しますが、デプロイされていたサーバーに対応する診断ファイルに、次のようなメッセージが出力されます。

[2009-01-21T13:34:48.144-08:00] [server_soa] [NOTIFICATION] []
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] 
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0] 
Application [JpsJdev#V2.0] is being deployed, start policy migration.

[2009-01-21T13:34:48.770-08:00] [server_soa] [WARNING] [] 
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] 
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0] 
Exception in application policy migration.[[
oracle.security.jps.JpsException: appplication Role: 
test_role not found for the application in the destination policy store
at oracle.utility.destination.apibased.JpsDstPolicy.convertAppPolicyPrincipal
(JpsDstPolicy.java:815)
at oracle.utility.destination.apibased.JpsDstPolicy.clone
(JpsDstPolicy.java:691)...

前述の抜粋はファイルserver_soa-diagnostic.logから取られたものであり、アプリケーションJpsJdevは管理対象サーバーserver_soaにデプロイされたものです。このようなエラーを探すために検索するキー・フレーズが、前述の例で強調表示されていることに注意してください。さらに、このエラーには、例外を引き起こしたアーティファクトであるアプリケーション・ロールtest_roleが記述されています。

診断

アプリケーション・ファイルjazn-data.xmlのこのロールの定義になんらかの間違いがあります。実際に、このファイルの内容を簡単に確認すると、次の抜粋に示されているように、granteeでロールtest_roleが参照されていることがわかります。

<grantee>
   <display-name>myPolicy</display-name>
   <principals>
     <principal>
       <class>oracle.security.jps.service.policystore.ApplicationRole</class>
       <name>test_role</name>
     </principal>
   </principals>
</grantee> ...

しかし、test_roleという名前のアプリケーション・ロールであるはずのものが、誤ってtest_rolleとスペルミスされていました。

<application>
   <name>JpsJdev</name>
   <app-roles>
     <app-role>
       <name>test_rolle</name>
       <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        <members> ...

解決策

アプリケーション・ポリシー内で参照されているすべてのアプリケーション・ロールが、jazn-data.xmlファイルで適切に定義されていることを確認します。参照されたロール名が、前述の例のように一致しない場合、移行は失敗します。

L.15 ポリシーに使用する文字

この項では、ポリシーに使用する文字に関する問題をいくつか説明します。この項の内容は次のとおりです。

L.15.1 Oracle Internet Directory 10.1.4.3での特殊文字の使用

ポリシー・ストアが、LDAPベースのOracle Internet Directory 10.1.4.3リポジトリの場合、RFC 2252/2253フィルタで*、(、)または\を使用すると、エラー53(DSAによる操作拒否)が発生します。このエラーを解決するには、バグ番号7711351用のパッチをOracle Internet Directory 10.1.4.3に適用します。

L.15.2 特定の文字が含まれるXMLポリシー・ストア

この項で説明する問題は、XMLポリシー・ストアにのみ関連します。つまり、LDAPベースのポリシー・ストアには適用されません。

ここで問題となる文字は次のとおりです。

 < "  &  $ ? * , / \ ` :    ( ) ^ ' % +  { }

これらの文字は、ファイルベースのポリシー・ストアを使用する場合には、アプリケーション・ロール名に使用しないことをお薦めします。

たとえばロールを作成するために、これらのいずれかの文字の使用が必要になった場合は、正常な結果が返されるように、ApplicationPolicy.searchAppRoles()などのAPIポリシー・ストア・メソッドへの入力でそれらの文字をエスケープ処理します。

たとえば、アプリケーション・ロールにappRole^$という名前を付けた場合、ポリシー・ストアで一致を検索するはApplicationPolicy.searchAppRoles("appRole\\^\\$")のように入力する必要があります。

または、このようにエスケープ処理した特殊文字を使用せずに、次のように検索式にワイルド・カードを使用して、アプリケーション・ロールとの一致が得られるようにすることもできます。

ApplicationPolicy.searchAppRoles("appRole*")

L.15.3 アプリケーション・ロール名に使用する文字

アプリケーション・ロール名は、空白以外の印刷可能な文字列です。つまり、アプリケーション・ロール名は、英数字(ASCIIまたはUnicode)と、空白以外のその他の印刷可能文字(アンダースコアや大カッコなど)で構成することができます。このルールはサポートされている3種類の記憶域XML、LDAPおよびDBのすべてに適用されます。

L.15.4 XMLポリシー・ストアでの改行文字の欠落

ファイルベースのポリシー・ストアでは、<permission>または<principal>の終了タグと次の開始タグとの間に改行文字が必要です。

次に、正しくない形式と正しい形式の文字列の例を示します。

ポリシー・ストアの正しくない記述例:

<permission>
    <class>java.lang.RuntimePermission</class>
    <name>getClassLoader</name>
 </permission> <permission>
      <class>java.io.FilePermission</class>
      <name>/foo</name>
      <actions>read,write</actions>
 </permission>

ポリシー・ストアの正しい記述例:

<permission>
    <class>java.lang.RuntimePermission</class>
    <name>getClassLoader</name>
</permission>
<permission>
      <class>java.io.FilePermission</class>
      <name>/foo</name>
      <actions>read,write</actions>
</permission>

L.16 J2SEアプリケーションにおけるパーミッションの付与

この項では、J2SEアプリケーションで権限付与を適切にコーディングする方法を説明します。ここ説明している問題はJ2EEアプリケーションの問題ではありませんが、高い移植性を実現するために、この解決策をJ2EEアプリケーションでも使用することをお薦めします。

現象

アプリケーションで権限の作成時に、アプリケーション・コードに次のようなコードが存在します。

Permission p = new FilePermission(resourceName, "write");
PrincipalEntry myPrincipal2 = InfoFactory.newPrincipalEntry("weblogic.security.principal.WLSGroupImpl", enterpriseRoleName2);
ap.grant(new Principal[]{myPrincipal2.getPrincipal()}, null, new Permission[]{p});

ところが、実行時に権限が予期したとおりに適用されません。

診断

簡単な検査で、ポリシー・ストア・リポジトリに次の属性が存在することがわかります。

orcljaznjavaclass=oracle.security.jps.internal.policystore.UnresolvedPrincipal+cn=enterpriseRoleName2

解決策

前述のコード行を次のコード行に置換する必要があります。

Permission p = new FilePermission (resourceName, "write");
PermissionEntry permEntry  = InfoFactory.newPermissionEntry(p.getClassName(), p.getName(),  p.getActions());
ap.grant (new PrincipalEntry[] {myPrincipal2}, null, new PermissionEntry[] {permEntry});

この解決策では、配列Principalのかわりに配列PrincipalEntryが、また配列Permissionのかわりに配列PermissionEntryが使用されています。


注意:

この同じ問題が、Principal[]またはPrincipalEntry[]を受け入れるバリアントをオーバーロードするメソッドrevokeにも適用されます。

L.17 Oracle Business Intelligenceレポート作成のトラブルシューティング

この項では、Oracle Business IntelligenceをOracle Fusion Middlewareセキュリティのレポート作成ツールとして使用した場合に多く見られる問題とその解決策について説明します。次の項目が含まれます。

L.17.1 Oracle Business Intelligence Publisherの監査テンプレート

Oracle Business IntelligenceでOracle Fusion Middleware監査フレームワークのレポートを表示するには、適切な監査テンプレートを使用する必要があります。

詳細は、第13.1.3項「Oracle Business Intelligence PublisherでのOracle Reportsの設定」を参照してください。

L.17.2 Oracle Business Intelligence Publisherのタイムゾーン

Oracle Business Intelligence Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、Oracle Fusion Middleware監査フレームワークのレポートに問題が発生することがあります。

この問題を防止するには、Oracle Business Intelligence Publisherとデータベースが、同じタイムゾーンにインストールされていることを確認します。

L.18 ポリシー・ストアでの属性照合時の検索の失敗

この項では、属性のカタログ化が必要な理由について説明します。

現象

ポリシー・ストアの検索中に、次のような例外が発生します。

oracle.security.jps.service.policystore.PolicyStoreOperationNotAllowedException
javax.naming.OperationNotSupportedException:
[LDAP: error code 53 - Function Not Implemented, search filter attribute orcljpsresourcetypename is not indexed/cataloged];
remaining name 'cn=Permissions,cn=JAASPolicy,cn=IDCCS, cn=sprint6_policy_domain,cn=JPSContext,cn=FusionAppsPolicies'

診断

前述のエラーは、属性orcljpsresourcetypenameをポリシー・ストアの検索のフィルタとして使用するには事前にこの属性をカタログ化する必要があることを示しています。

解決策

orcljpsresourcetypenameなどの属性のカタログ化方法については、第8.8項「Oracle Internet Directoryの属性のカタログ化」を参照してください。

L.19 不明なホスト例外による検索の失敗

LDAP参照用に構成されたActive Directory環境で情報を検索する場合、参照先のホストがActive Directoryサーバーと異なるドメインに存在すると、参照に失敗します。

現象

ユーザーがリソースをリクエストしたときに、ディレクトリでのユーザーのアイデンティティの検証が不可能なためにユーザーのアイデンティティの検証に失敗することがあります。このエラーは、Active Directory環境でユーザーのブラウザがWindows以外のコンピュータで実行されている場合、またはユーザーのブラウザを実行するコンピュータがActive Directoryサーバー・ドメインに含まれていない場合に発生します。

診断

この問題はLDAP参照の追跡が原因で発生することがあります。LDAP参照は、リクエスト対象のオブジェクトが存在するディレクトリ・ツリー・セクションをドメイン・コントローラが保有していないときに発生します。ドメインコントローラは、クライアントを別の宛先に差し向けて、クライアントが別のドメイン・コントローラに対してDNS検索を実行できるようにします。クライアントが参照を追跡するように構成されていれば、検索を続行できます。

ユーザーがWindowsベースのコンピュータを使用している場合、クライアントのドメイン・コントローラとActive Directoryドメイン・コントローラとの間に信頼関係が確立されていないと、LDAP参照に関連する問題が発生することがあります。

解決策

この問題が発生した場合は、Active Directoryホストのアドレスのエントリを次のリストに追加します。

WINDOWS_HOME_DIRECTORY\system32\drivers\etc\hosts

Windows XPの場合、このリストは次の場所にあります。

C:\WINDOWS\system32\drivers\etc\host

Unixベースのシステムの場合は、このエントリを次の形式で/etc/hostsファイルに追加します。

IP_address_of_AD_host AD_host_name

このAD_host_nameは、参照で指定されるホスト名です。例:

123.123.123.123 my2003ad.com

L.20 バイナリとポリシー・ストアのバージョンの非互換性

この項では、サーバーによって例外PolicyStoreIncompatibleVersionExceptionがスローされる理由について説明します。

現象

次のようなエラーがログに記録されるか、サーバーから発行されます。

Oracle.security.jps.service.policystore. PolicyStoreIncompatibleVersionException
JPS-06100: Policy Store version 11.1.1.5.0 and Oracle Platform Security Services
version 11.1.1.4.0 are not compatible.

診断

前述の例は、ドメインのOPSSバイナリ・バージョン(11.1.1.4.0)と、そのドメインで使用しているポリシー・ストアのバージョン(11.1.1.5.0)に互換性がないことを示しています。ポリシー・ストアのバージョンは再関連付け時に確立され、ポリシー・ストアを新しいバージョンにアップグレードするまでそのバージョンが使用されます。

OPSSドメイン・バイナリ・バージョンは、そのドメインで使用しているポリシー・ストアのバージョンに対して下位互換性はありますが、上位互換性はありません。前述のエラーは、ポリシー・ストアのバージョンがOPSSバイナリのバージョンよりも新しいことを示しています。PS3 OPSSバイナリでは、ポリシー・ストアよりも新しいバージョンは使用できません。

OPSSバイナリでこのような非互換性が発生するシナリオには、次の3つがあります。

解決策

これらの3つのシナリオすべてに対処する解決策として、次のいずれかを使用できます。

L.21 追加のヘルプ

My Oracle Support(以前のMetaLink)(http://myoraclesupport.oracle.com)でより多くの解決策を参照できます。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引