| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11gリリース1（11.1.1） B56235-02 |
|
 戻る |
 次へ |
この付録では、Oracle Enterprise Manager Fusion Middlewareセキュリティを構成および使用する際に発生する可能性のある共通の問題について説明し、その解決方法を紹介します。この付録の内容は次のとおりです。
この項では、セキュリティ・エラーを検出して解決する方法について説明します。この項の内容は次のとおりです。
Fusion Middleware Controlでは、発生したフォルトの管理、分離または解釈に役立つ可能性がある場合はいつでも、ロギングのサポートが明示的に提示されます。
この項では、Oracle WebLogic Serverでサポートされている様々なログ・ファイルを紹介し、Fusion Middleware Controlでログ・レベルの構成と設定、およびログ・ファイルの検索と表示を行う方法について説明します。この項の内容は次のとおりです。
ドメイン内の各サーバー・インスタンスは、そのサブシステムとアプリケーションで発生したOPSSベースのすべての例外を、ローカル・ホスト・コンピュータのファイル・システムにあるサーバー・ログ・ファイルに書き込みます。
デフォルトでは、このログ・ファイルは、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName-diagnostic.logxxxxxとなっています。ここで、xxxxxは1〜99999の整数を示します。
診断ファイルの完全な名前の例を、いくつか次に示します。DomainName/servers/AdminServer/logs/AdminServer-diagnostic.log00001（管理サーバー・ログ）、DomainName/servers/soa/logs/soa-diagnostic.log00013（管理対象サーバー・ログ）。
すべてのサーバー・インスタンスは、セキュリティ関連のエラーを診断ファイルに出力します。サーバー関連のセキュリティ・エラー（サブジェクトやプリンシパルの問題で発生した例外など）、およびドメイン・セキュリティ・データを移行または再関連付けするときに発生する可能性のあるエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー（アプリケーション固有のポリシーまたは資格証明で発生した例外など）は、対応する管理対象サーバーの診断ログに書き込まれます。
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 Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する項を参照してください。
Oracle WebLogic Frameworkの詳細は、『Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server』を参照してください。
ロギング・サービスの詳細は、『Oracle Fusion Middleware Using Logging Services for Application Logging for Oracle WebLogic Server』を参照してください。
Oracle Fusion Middlewareのロギングの詳細は、Oracle Fusion Middlewareの管理者ガイドの第10章「ログ・ファイルと診断データの管理」を参照してください。
Fusion Middleware監査フレームワークには、いくつかのランタイム・コンポーネントがあります。この項では、これらのコンポーネントの診断ログ・ファイルを紹介し、診断メッセージの解釈方法について説明します。
これらのログ・ファイルは、次の場所にあります。
DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log
表J-1は、様々な診断ログ・ファイルを示しています。
表J-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 |
Fusion Middleware Controlを使用してoracle.security.audit.loggerを構成できます。
oracle.security.audit.loggerでは、ERRORからTRACEまでの任意のログ・レベルを設定し、ログに記録される情報の量を制御できます。
Fusion Middleware Controlを使用して、これらの診断ファイルを表示することもできます。
|
関連項目: 次のトピックの詳細は、Oracle Fusion Middlewareの管理者ガイドの第10章「ログ・ファイルと診断データの管理」を参照してください。
|
Fusion Middleware Controlには、ログ情報を管理するためのページがいくつか用意されています。このツールを使用して、次の操作を実行できます。
ログのレベルとローテーションなど、ログ・ファイルの属性を構成する。
ドメイン内にあるすべてのログ・ファイルのコンテンツを検索し、メッセージID別またはタイプ別に問合せ結果をグループ分けする。
コンテキストまたは期間により特定のエラーとその他のエラーの相関を分析する。
ログ・ファイルの一部または問合せ結果を複数のフォーマットのいずれかでダウンロードする。
この項では、ログ・ファイルの構成方法について簡単に説明します。前述の他の3つの機能についても、第J.1.3項「セキュリティ・エラーの解決」に簡単な説明があります。
これらのトピックの詳細は、Oracle Fusion Middlewareの管理者ガイドのログ・ファイルと診断データの管理に関する項を参照してください。
Fusion Middleware Controlを使用してログ・ファイルを構成するには、次の手順を実行します。
「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。このページを使用して、永続ログ出力とアクティブなランタイム・ログ出力の両方に対するログ・レベルを構成できます。
必要なログ出力に対するログ・ファイル・エントリをクリックして、そのファイルに対する現在のパラメータ設定を示すページを表示します。
このページで、行を選択し、「構成の編集」ボタンをクリックして、「ログ・ファイルの編集」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、ログ・レベルやローテーション・ポリシーなどの様々なパラメータを設定できます。
デバッグ出力を増やすには、Oracle WebLogic Serverを起動するスクリプトに次のいずれかのシステム・プロパティの設定を追加して、サーバーを再起動します。
サーバー起動時に渡すことができ、セキュリティ問題のデバッグに役立つ可能性のあるその他の2つのシステム・プロパティを、次に示します。
-DDebugOPSSPolicyLoading、OPSSポリシー・プロバイダの進行状況と設定を監視するフラグ。
-Djava.security.debug=policy、ファイル・システム内の保存場所、付与されるパーミッション、および署名付きコードに使用される証明書など、解析したポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。
次のシステム・プロパティのみを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に設定されています。
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に設定されています。
エラーが発生したときに、そのエラーを解決する一般的な方法はありません。そのため、ヒントを検索し、できればエラーの原因を分離して理解するまで、多くの場合複数の仮定に従う必要があります。この目的を達成するために、この項では、ログ情報を検索して解釈し、最も一般的なセキュリティ・エラーを解決する方法について説明します。この項の内容は次のとおりです。
エラーを分離して解決するには、ログ・エラー出力を理解することが重要です。ここでは、診断ログ・ファイルの内容を詳しく調べ、このファイルに記録されているエラーに関して得られる情報について説明します。この場合、実際の例を使用して説明するのが最も効果的です。
次の例は、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 Error Messages Reference』の第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エラー。
ドメイン内のすべてのログ・ファイルのコンテンツで検索を開始するには、「ドメイン」→「ログ」→「ログ・メッセージの表示」を選択し、「ログ・メッセージ」ページを表示します。
このページには、検索クエリを指定するために選択できる複数のパラメータがあります。具体的には、次の操作が可能です。
適切な「日付範囲」を選択することで、メッセージが発行される期間を選択できます。
「メッセージ・タイプ」ボックスのいずれかを選択することで、特定の重大度エラーを含むメッセージを表示できます。
「メッセージ」メニューから項目を選択し、その横にあるボックスに文字列を入力することで、さらなる制約を満たすメッセージを表示できます。たとえば、文字列exceptionを含むメッセージに対してのみ問合せを行うことができます。
「フィールドの追加」ボタンをクリックし、選択肢のいずれかを選択することで、新たな問合せフィールドを追加できます。たとえば、Hostフィールドを追加して、特定の文字列で始まる問合せを入力することができます。
これらのパラメータを設定して、「検索」をクリックすると、問合せの結果がこのページに表示されます。問合せの結果は、「表示」メニューから項目を選択することで、メッセージ・タイプ別、メッセージID別、またはメッセージの単純なリストで詳細に表示し直すことができます。さらにこの結果を、ページの右上にあるメニューから項目を選択することで、自動的にリフレッシュすることもできます（デフォルトでは「手動リフレッシュ」に設定）。
検索範囲をドメインを越えたログ・ファイルにまで拡張するには、ページの右上にある「広範囲のターゲット・スコープ」ボタンを使用します。
場合によっては、メッセージが発生したコンテキストを知ることが必要になります。たとえば、特定のエラー・メッセージの2分前または2分後に発生したメッセージがわかると役に立つ場合があります。
「関連メッセージの表示」タブにはこの機能があります。この機能を使用する手順は次のとおりです。
「表示」を「メッセージ」に設定して、問合せの結果を表示します。
結果の表内でメッセージを選択します。このとき、「関連メッセージの表示」タブおよび「メッセージをファイルにエクスポート」タブが使用可能になっていることに注意してください。たとえば、選択したメッセージのタイムスタンプが、Jan 21, 2009 4:05:00 PM PSTであると仮定します。
「日付範囲」メニューから「時間間隔」を選択し、「開始日」と「終了日」を入力します。たとえば、開始日としてJan 21, 2009 4:02:00 PM、終了日としてJan 21, 2009 4:07:00 PMを入力できます。
「関連メッセージの表示」メニューから「時間ごと」を選択すると、選択したメッセージに関連する、指定した期間内のすべてのメッセージが表示されたページが開きます。
「時間別の関連メッセージ」ページで、ページの右側にある「有効範囲」メニューから項目を選択することで、選択したメッセージの時間前後の時間ウィンドウを変更できます。
別のファイルに表示されたエラーのリストをダウンロードし、転送することが必要になる場合があります（サポート・センターに転送する場合や、記録として残しておく場合など）。
「メッセージのエクスポート」タブが使用可能な場合はいつでも、メニューから項目を選択することで、表示された結果のみを含むファイルを生成できます。生成できるファイルの形式は、プレーン・テキスト、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 #
XMLベースのストアから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）再関連付けを再実行します。
現象
LDAPベースのOracle Internet Directoryポリシー・ストアを使用するようにXMLベースのポリシー・ストアを再関連付けすると、この再関連付けが正常に完了したとレポートされる場合があります。
ところが、実行時にシステムが予期したとおりに動作しません。移行後にシステム・ポリシーに存在するはずの、付与されたコードベースのポリシーが欠落しています。
診断
実行時にサーバーは次のようなスタック・トレースをレポートします。
<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サーバーで適切なスキーマがシードされていないと、システムは予期したとおりに動作しません。
再関連付けの際にスキーマが必ずシードされるようにするには、次の手順に従います。
Oracle Internet Directoryサーバーのcn=OracleSchemaVersionコンテナの下にあるcn=OPSSコンテナを削除します。
このファイルベースのストアを使用しているOPSSポリシー・ストアの正常に動作しているインスタンスを起動します。
このファイルベースのストアを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
この項では、ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗する可能性がある理由について説明します。
現象
ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗し、出力されるエラー・メッセージに次の内容が含まれます。
java.lang.IllegalArgumentException: null KeyStore name
診断
この問題の原因の1つは、ドメイン内の認証プロバイダのリストに、LDAP認証プロバイダが含まれていないことです。
|
重要: OPSSを使用するドメインの場合、このリストにLDAP認証プロバイダが必要です。 |
解決策
サーバーを起動できないため、次の手順に従って、手動で1つのLDAP認証プロバイダを追加する必要があります。
ファイルDOMAIN_NAME/config/config.xmlを開きます。
config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダなどの、LDAP認証プロバイダを含めます。
<realm> ... <sec:authentication-provider xsi:type="wls:default-authenticatorType"> </sec:authentication-provider> ... </realm>
サーバーを再起動します。
サーバーが再起動して稼働したら、WebLogic管理コンソールを使用して、希望のプロバイダを含むようにプロバイダのリストを変更できますが、少なくとも1つのプロバイダをLDAP認証プロバイダにする必要があります。
この目的のために、次の手順に従って、WebLogic管理コンソールを使用します。
「新しい認証プロバイダの作成」ページに移動します。
認証プロバイダ名を入力して、認証プロバイダのタイプ（次に示すLDAPベースのもの）を選択します。
ActiveDirectoryAuthenticator
DefaultAuthenticator（これは、前述の例で手動で挿入したものです）
LDAPAuthenticator
LDAPX509IdentityAsserter
OpenLDAPAuthenticator
OracleInternetDirectoryAuthenticator
OracleVirtualDirectoryAuthenticator
この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。
現象
追加設定なしで使用できるデフォルトの認証プロバイダを削除して、Oracle Internet Directory認証プロバイダなどを追加すると、サーバーの起動に失敗します。
診断
追加した認証プロバイダにAdministratorsグループのアカウント・メンバーを入力することを忘れている可能性が高いと考えられます。サーバーでは、1つのドメイン認証プロバイダにこのようなアカウントが存在することが要求されます。このアカウントは、デフォルトの認証プロバイダに常に存在します。
解決策
サーバーを起動できないため、次の手順に従って、削除された1つのLDAP認証プロバイダを手動で追加する必要があります。
ファイルDOMAIN_NAME/config/config.xmlを開きます。
config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダを含めます。
<realm> ... <sec:authentication-provider xsi:type="wls:default-authenticatorType"> </sec:authentication-provider> ... </realm>
サーバーを再起動します。
サーバーが再起動して稼働したら、次の手順を実行します。
WebLogic管理コンソールを使用して、Oracle Internet Directory認証プロバイダに、Administratorsグループのメンバーであるアカウントを作成します。
Oracle Internet Directory認証プロバイダのフラグを、SUFFICIENTに設定します。
サーバーを再起動します。デフォルトの認証プロバイダに指定されたAdministratorsグループのアカウントを使用しているので、問題なく起動するはずです。
Oracle Internet Directory認証プロバイダのフラグをREQUIREDに再設定して、デフォルトの認証プロバイダを削除します。これで、Oracle Internet Directory認証プロバイダに作成したAdministratorsグループのアカウントを使用して、サーバーが起動します。
この項では、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セキュリティ・マネージャを使用してWebLogicリソースを保護する方法の詳細は、『Oracle Fusion Middleware Programming Security for Oracle WebLogic Server』を参照してください。
|
注意: Printing Security Managerは、Javaセキュリティ・マネージャに対するWebLogicサーバーの拡張機能です。Printing Security Managerを使用して、Javaセキュリティ・マネージャの下で実行されているJavaアプリケーションで必要なすべてのパーミッションを識別します。必要なパーミッションを1つずつ識別するJavaセキュリティ・マネージャとは異なり、Printing Security Managerでは、必要なパーミッションをすべて、操作することなく識別します。 |
この項では、エンタープライズ・ユーザーまたはロール（グループ）へのパーミッションの付与または取消に失敗する、よくある理由について説明します。
現象
ドメイン認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに対して、権限付与で定義されたパーミッションが付与または取消されません。
診断
この問題は、（ドメイン認証プロバイダに）格納されている名前と、（ユーザーがアクティブに入力したか、プログラムによって取得された）指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致の例として、格納されているユーザー名がJdOEで、指定されたユーザー名がjdoeである場合があげられます。
解決策
この問題を解決するには、次の2つの方法があります。
1つ目の解決策としては、ドメインに使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列（格納されているものと指定されたもの）に、（大文字小文字関係なく）同じ順序の文字が含まれているかぎり、この設定により、対応する文字の大文字小文字が異なっている場合でも、サブジェクトに入力されたユーザー名が、ドメイン認証プロバイダに存在するユーザー名に一致することが保証されます。したがって、この設定が機能している場合、JdOEというユーザー名とjdoeというユーザー名は一致します。
ドメイン認証プロバイダのプロパティを設定するには、次の手順に従います。
管理コンソールを使用して、認証プロバイダを構成するページに移動します。たとえば、デフォルトの認証プロバイダを使用する場合、DefaultAuthenticatorページに移動するには、「レルム」→「myrealm」→「プロバイダ」→「DefaultAuthenticator」を選択します。
「プロバイダ固有」タブを選択します。
プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。
サーバーを再起動します。
2つ目の解決策では、指定された名前をプログラムによって取得する、つまりユーザー名からプリンシパルを生成する場合を考えます。
正しいユーザー名またはグループ名を取得するには、その名前を認証プロバイダに格納されているとおりに正確に渡すか、または次のコードSnippetに示されているコールのシーケンスを使用します。
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()); |
この項では、Oracle Internet Directory LDAPサーバーへの接続が失敗する場合に多く見られる理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。
現象
ソース・リポジトリからターゲットLDAPサーバー・リポジトリへのデータの移行が失敗します。
診断
通常、この種の問題は、ターゲットLDAPサーバーのパラメータ設定が間違っていることが原因です。
Oracle WebLogic Serverのログ・ファイルを調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリ内のログ・ファイルで、<Error>、<Critical>および<Warning>という文字列を検索してください。
エラーを特定して解決する方法の詳細は、第J.1項「セキュリティ・エラーの診断」を参照してください。
解決策
移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。この確認を行うために、LDAPサーバー管理者の支援が必要になる場合があります。
|
注意: Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、操作を開始する前に、「LDAP認可のテスト」ボタンを使用してください。通常は、このテストにより、間違って指定されたパラメータを見つけることができます。 |
この項では、ユーザーおよびロール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サービス・プロバイダ・インスタンスの構成」を参照してください。 |
この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。
現象
アプリケーションが、ドメイン資格証明ストアからの資格証明データの取得に失敗し、（次に示すような行を含む）エラー・メッセージがログに記録されます（角カッコ内のテキストには、特定の失敗に固有の情報が記述されます）。
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を使用してパーミッションを指定するには、第7.4.1項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。
WLSTコマンドを使用してパーミッションを指定するには、第7.4.2項「WLSTコマンドを使用したポリシーの管理」を参照してください。
ファイル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>
この項では、ポリシーと資格証明の再関連付けを行うときに匿名SSL接続を確立できない、よくある理由について説明します。
現象
Fusion Middleware Controlを使用してOracle Internet Directoryサーバーによるファイルベースのポリシーおよび資格証明とLDAPベースの記憶域の再関連付けを行う際の手順として、LDAPサーバーへの匿名SSL接続をテストします（具体的には、LDAPのテストボタンを使用します）。その結果、このテストに失敗します。
診断
ターゲットLDAPサーバーがOracle WebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。
解決策
LDAPサーバーへの接続を確立するには、LDAPサーバー上であらかじめ一部の構成を行っておく必要があります。詳細は、第7.1.2項「LDAPベースのポリシー・ストアを使用する場合の前提条件」を参照してください。
さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このポートを使用してLDAPサーバーを構成しなかった場合、接続は失敗します。
指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。通常、このポートの設定はLDAPサーバーの管理者が行います。
この項では、認可チェックが失敗する理由について説明します。
現象
アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。
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つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。
この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。
現象
新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。
診断
この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多くの（または少ない）パーミッションを取得する、よくある理由は、ユーザーを削除する前またはユーザー・データを変更する前に、ポリシー・ストアが適切に更新されていないことです。
解決策
ユーザーを削除する前に、ユーザーに付与されていたすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに継承される可能性があります。
ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー（権限付与、パーミッション、ロール）を更新して、新しいデータでも予期したとおりに機能するようにする必要があります。
この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。
現象
実行時に、アプリケーションが次のようなエラーを出力します（最初の数行のみが表示されています）。
<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の次のコード断片には、ディレクトリBasicAuth内の任意のコードに対する、資格証明ストアのマップMY_MAP内にある任意のキーを読み取るパーミッションを設定する方法が示されています。
<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;
...
前述の権限付与の例では、読取り操作のみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。
この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。
現象
実行時に、アプリケーションが次のようなエラーを出力します（最初の数行のみが表示されています）。
[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つのパーミッション・クラスを共有する場合、システム・クラス・パスにそのクラスを含めてください。
この項では、アプリケーション・デプロイ時のポリシーの自動移行が失敗する理由について説明します。アプリケーションのデプロイは、ポリシーの移行に失敗しても、成功する場合があることに注意してください。
|
注意: この項で説明されている自動移行に失敗する理由が、ドメイン・ストアの再関連付けを行う際にも、同様の失敗につながる可能性があります。 |
現象
デプロイ時にポリシーを自動的に移行するように、アプリケーションが構成されています。アプリケーションのデプロイは成功しますが、デプロイされていたサーバーに対応する診断ファイルに、次のようなメッセージが出力されます。
[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ファイルで適切に定義されていることを確認します。参照されたロール名が、前述の例のように一致しない場合、移行は失敗します。
この項では、ポリシーに使用する文字に関連するいくつかの問題について説明します。
現象
ドメイン・ポリシー・ストアが、LDAPベースのOracle Internet Directory 10.1.4.3リポジトリの場合、RFC 2252/2253フィルタで*、(、)または\を使用すると、エラー53（DSAによる操作拒否）が発生します。
解決策
Oracle Internet Directory 10.1.4.3にBug#7711351のパッチを適用します。
この項で説明する問題は、XMLポリシー・ストアにのみ関連します。つまり、LDAPベースのポリシー・ストアには適用されません。
ここで問題となる文字は次のとおりです。
< " & $ ? * , / \ ` : ( ) ^ ' % + { }
これらの文字は、XMLベースのポリシー・ストアを使用する場合には、アプリケーション・ロール名に使用しないことをお薦めします。
たとえばロールを作成するために、これらのいずれかの文字の使用が必要になった場合は、正常な結果が返されるように、ApplicationPolicy.searchAppRoles()などのAPIポリシー・ストア・メソッドへの入力でそれらの文字をエスケープ処理します。
たとえば、アプリケーション・ロールにappRole^$という名前を付けた場合、ポリシー・ストアで一致を検索するはApplicationPolicy.searchAppRoles("appRole\\^\\$")のように入力する必要があります。
または、このようにエスケープ処理した特殊文字を使用せずに、次のように検索式にワイルド・カードを使用して、アプリケーション・ロールとの一致が得られるようにすることもできます。
ApplicationPolicy.searchAppRoles("appRole*")
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>
この項では、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にも適用されます。 |
この項では、Oracle Business Intelligence PublisherをOracle Fusion Middlewareセキュリティのレポート作成ツールとして使用した場合に多く見られる問題とその解決策について説明します。この項の内容は次のとおりです。
Oracle Business Intelligence PublisherでOracle Fusion Middleware監査フレームワークのレポートを表示するには、適切な監査テンプレートを使用する必要があります。
詳細は、第12.1.3項「Oracle Business Intelligence PublisherでのOracle Reportsの設定」を参照してください。
Oracle Business Intelligence Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、Oracle Fusion Middleware監査フレームワークのレポートに問題が発生することがあります。
この問題を防止するには、Oracle Business Intelligence Publisherとデータベースが、同じタイムゾーンにインストールされていることを確認します。
Oracle Business Intelligence Publisherでパッケージ化された標準の監査レポートでは、管理者が使用する数多くの言語がサポートされます。Oracle Business Intelligence Publisherは、様々なロケールで起動できます。管理者は「プリファレンス」で優先ロケールを設定することによって、選択した言語を起動時に指定できます。
この問題により、Oracle Business Intelligence Publisherを次の3つのロケールのいずれかで起動すると不具合が発生します。
zh_CN（簡体字中国語）
zh_TW（繁体字中国語）
pt_BR（ブラジルのポルトガル語）
これら以外のロケールでは予期したとおりに翻訳されたテキストが表示されますが、これら3つのロケールの言語ではレポートを表示できません（ラベル、ヘッダー、タイトルなどのレポート全体が英語で表示されます）。たとえば、Oracle Business Intelligence Publisherをzh_CNで起動すると、優先ロケールがzh_CNに設定されていても、テキストをzh_CNで表示できません。情報は英語で表示されます。
これに関連して、レポートのタイトルと説明が翻訳されていても英語で表示される問題があります。
My Oracle Support（以前のMetaLink）（http://myoraclesupport.oracle.com）でより多くの解決策を参照できます。問題に対する解決策が見つからない場合は、サービス・リクエストをログ記録できます。
