| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
 前 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
前 |
この付録では、OPSSの構成および使用時に発生する可能性のある一般的な問題と、それらの解決方法について説明します。
次の項目が含まれます。
この項では、様々なセキュリティ・エラーの診断と解決に利用できるツールについて説明します。次の項目が含まれます。
Fusion Middleware Controlでは、フォルトの管理、分離または解釈に役立つ可能性がある場合は、ロギングのサポートが明示的に提示されます。
次の各項では、Oracle WebLogic Serverでサポートされている様々なログ・ファイルとOPSSロガーを紹介し、Fusion Middleware ControlおよびWLSTコマンドでロガー・レベルの構成と設定、およびログ・ファイルの検索と表示を行う方法について説明します。
ドメイン内の各サーバー・インスタンスは、そのサブシステムとアプリケーションで発生した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 WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する説明を参照してください。
Oracle WebLogicフレームワークについては、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。
ロギング・サービスの詳細は、『Oracle WebLogic ServerにデプロイされたアプリケーションへのWebLogicロギング・サービスの追加』を参照してください。
Oracle Fusion Middlewareへのログインの詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。
OPSSでは、実行時の認可の失敗をトラブルシューティングするのに役立つ2つのロガーを提供しています。
この2つのロガーは、他のOPSSロガーと同様に、有効と無効を動的に切り替えることができます。つまり、Oracle WebLogic Application Serverを停止して再起動する必要はありません。ロガーのプロパティを設定する方法の詳細は、「Fusion Middleware Controlを使用したロガーの管理」を参照してください。通常、ロガーのレベルはTRACE:32に設定されます。
追加のロガーの詳細は、「その他のOPSSロガー」を参照してください。
ロガーoracle.security.jps.util.JpsAuthは、メソッドcheckPermissionの起動とリターンをログに記録し、ログ・ファイルの次のスニペットは、ログ・ファイル内のこのメソッドに対する開始境界と終了境界を示しています。
[SRC_CLASS: oracle.security.jps.util.JpsAuth] [APP: JeeScenarioApp] [SRC_METHOD: Entering checkPermission] ENTRY (oracle.security.jps.ResourcePermission resourceType=TaskFlowResourceType,resourceName=ResourceNameX read) [SRC_CLASS: oracle.security.jps.util.JpsAuth] [APP: JeeScenarioApp] [SRC_METHOD: Exiting checkPermission] RETURN java.security.AccessControlException: access denied (oracle.security.jps.ResourcePermission resourceType=TaskFlowResourceType,resourceName=ResourceNameX read)
次のスニペットは、成功した場合の認可ログを示しています。
[JpsAuth] Check Permission
PolicyContext: [JeeScenarioApp]
Resource/Target: [getSubjectFromDomainCombiner]
Action:[null]
Permission Class: [javax.security.auth.AuthPermission]
Result: [SUCCEEDED]
Subject: [null]
Evaluator: [SM]
次のスニペットは、失敗した場合の認可ログを示しています。
[JpsAuth] Check Permission
PolicyContext: [JeeScenarioApp]
Resource/Target: [resourceType=TaskFlowResourceType,resourceName=ResourceNameX]
Action:[read]
Permission Class: [oracle.security.jps.ResourcePermission]
Result: [FAILED]
Evaluator: [ACC]
Failed
ロガーoracle.security.jps.trace.loggerは、アプリケーション・ロール、パーミッション、ターゲット、プリンシパルおよび付与されたポリシーと拒否されたポリシーに関する情報をログに記録します。このロガーを有効にすると、出力が大きくなる可能性があるため、単一使用ケースのデバッグにのみ使用することをお薦めします。具体的には、このロガーは次のものを記録します。
認可リクエストに関する次の情報。エンタープライズ・ロールに付与されたアプリケーション・ロール、すべての拒否と付与、パーミッション・クラス名、パーミッション・ターゲットおよびプリンシパル名。
ロールにプリンシパルが追加されたときなどの、メンバー・キャッシュの更新。キーワード: 「プリンシパル:」、「挿入されたロール:」。
情報を管理するロール。キーワード: 「アプリケーション内:」、「プリンシパルのクエリー・ストア:」、「ダイレクト・アプリケーション・ロールの数:」。
メソッドgetPermissionsに対するコール。
migrateSecurityStoreなどのオフラインWLSTコマンドの使用時には、次のシステム・プロパティを指定してJVMを起動することにより、OPSSロガーを有効にできます。
-Dwlst.offline.log -Dwlst.offline.log.priority
これらのプロパティを次のように設定します。
wlst.offiline.logには、<filename>、stdout、sterrまたはdisableのいずれかの値を指定できます。このプロパティを明示的に設定しなかった場合、ログ・ファイルは、デフォルトでディレクトリ$MW_HOME/logsに作成されます。
wlst.offline.log.priorityには、OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL、debug、info、warn、errorまたはfatalのいずれかの値を指定できます。
認可ロガーに加えて、OPSSは次のロガーを提供します。
oracle.jps.commonは、OPSS JpsFilterおよびOPSS JpsInterceptorに関する問題の診断を可能にします。
oracle.jps.deploymentは、アプリケーションのデプロイ時に、アプリケーションとパッケージ化されたOPSSアーティファクトに関する問題の診断を可能にします。キーワード:「移行」。
oracle.jps.openazは、PEP APIコールに関する問題の診断を可能にします。oracle.jps.openaz.levelをFINESTに設定すると、送信されたリクエストに関する情報(アイデンティティ、リソース、アクション、コンテキスト)および認可結果が記録されます。
OPSSユーザーおよびロールAPIコールを追跡するには、oracle.idm.userroleapiロガーをTRACE:32に設定します。
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コンポーネント |
第J.1.1.7.3項を参照してください。 |
第J.1.1.7.3項を参照してください。 |
|
起動クラス監査ローダー |
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章「ログ・ファイルと診断データの管理」を参照してください。
|
監査診断メッセージは、エラー・メッセージとトレース・メッセージという2つのタイプに分類できます。
すべてのエラー・メッセージには、IAU-XXXという番号が付けられます。これらのメッセージについては、考えられる原因とエラーへの対処方法が記載されたエラー・メッセージ・ガイドを参照してください。
これに対し、トレース・メッセージは、実行されているコンポーネントの詳細情報を示すためのものです。メッセージの性質に応じて、なんらかの処置が必要になることもあります。
OPMNで管理されるシステム・コンポーネントの監査ログを構成できます。
auditconfig.xml構成ファイルを使用して、コンポーネントの監査ログを書き込むログ・ディレクトリの場所を指定できます。LogsDirectory要素を使用して、監査ログの場所を指定します。次の例では、ログは/tmp/audit/auditlogsにあります。
<LogsDirectory> <MaxFileSize></MaxFileSize> <Location>/tmp/audit/auditlogs</Location> </LogsDirectory>
Fusion Middleware Controlには、ログ情報を管理するためのページがいくつか用意されています。このツールを使用して、次の操作を実行できます。
ログのレベルとローテーションなど、ログ・ファイルの属性を構成します。
ドメイン内にあるすべてのログ・ファイルのコンテンツを検索し、メッセージID別またはタイプ別に問合せ結果をグループ分けします。
コンテキストまたは期間により特定のエラーとその他のエラーの相関を分析します。
ログ・ファイルの一部または問合せ結果を複数のフォーマットのいずれかでダウンロードします。
この項では、ログ・ファイルの構成方法について簡単に説明します。前述の他の機能についても、第J.1.3項「セキュリティ・エラーの解決」に簡単な説明があります。
これらの各項のすべての詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルと診断データの管理に関する説明を参照してください。
Fusion Middleware Controlを使用してログ・ファイルを構成するには、次の手順を実行します。
「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。このページを使用して、永続ロガーとアクティブなランタイム・ロガーの両方に対するログ・レベルを構成できます。
必要なログ出力に対するログ・ファイル・エントリをクリックして、そのファイルに対する現在のパラメータ設定を示すページを表示します。
このページで、行を選択し、「構成の編集」ボタンをクリックして、「ログ・ファイルの編集」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、ログ・レベルやローテーション・ポリシーなどの様々なパラメータを設定できます。通常は、ロガー・レベルをTRACE:32に設定します。
Fusion Middleware Controlでロガーが表示されないように指定するには、次の手順を実行します。
「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。
「ログ・レベル」タブの「表示」プルダウンから、「永続ログ・レベル状態のログ出力」を選択します。
ページ下部の「ログ出力の指定」領域で、ロガー名を入力し、「Oracle Diagnostic Loggingレベル(Javaレベル)」・プルダウンからロガーのレベルを選択します。
次の呼出しのように、setLoggerLevelスクリプトを使用してロガーを管理できます。
setLogLevel(logger="oracle.idm.userroleapi", level="TRACE:32", addLogger=1, persist=1)
デバッグ出力を増やすには、Oracle WebLogic Serverを起動するスクリプトに次のシステム・プロパティを設定して、サーバーを再起動します。
認可プロセス中のデバッグ出力を取得するには、「認可プロセスのデバッグ」の項で説明しているいずれかのシステム・プロパティを設定してください。
サーバー起動時に渡すことができ、セキュリティ問題のデバッグに役立つ可能性のあるその他の2つのシステム・プロパティを、次に示します。
-DDebugOPSSPolicyLoading、OPSSポリシー・プロバイダの進行状況と設定を監視するフラグ。
-Djava.security.debug=policy、ファイル・システム内の保存場所、付与されるパーミッション、および署名付きコードに使用される証明書など、解析したポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。
|
注意: ロギング出力を高く設定すると、特にファイルのロード時に、スタック状態のスレッドが多数レポートされる可能性があります。この状況を避けるには、Oracle WebLogic Serverでスレッドをスタックとしてマークするために使用するタイムアウト値を、より高い値に変更します。 サーバーを再起動せずにシステム・プロパティを設定することはできません。システム・プロパティを設定するには、管理者は |
次のシステム・プロパティのみを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に設定されています。
この項では、各種基準に基づく認可プロセスのデバッグに役立ついくつかのその他のシステム・プロパティの使用について説明します。特に次のシステム・プロパティについて説明します。
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回のみ設定可能です。
一致では、大文字と小文字は区別されません(一致が適用される場合)。
前述のシステム・プロパティのロギングを有効にするには、次のようにします。
必要なシステム・プロパティを設定します。
JVMを停止します。
JVMを再起動します。
ロガーoracle.security.jps.dbg.loggerをTRACE:32に設定します。ロガーの設定方法の詳細は、「Fusion Middleware Controlを使用したロガーの管理」を参照してください。
デバッグするシナリオを実行します。
ログ出力を調べます。前述のいずれかのプロパティの設定によるメッセージ出力を見つけるには、ログ・ファイル内でキーワード[oracle.security.jps.dbg.logger]を検索します。
次の例では、前述のシステム・プロパティの一般的な設定を示しています。
部分文字列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も設定しません。
エラーが発生したときに、そのエラーを解決する一般的な方法はありません。そのため、ヒントを検索し、できればエラーの原因を分離して理解するまで、多くの場合複数の仮定に従う必要があります。この目的を達成するために、この項では、ログ情報を検索して解釈し、最も一般的なセキュリティ・エラーを解決する方法について説明します。この項の内容は次のとおりです。
エラーを分離して解決するには、ログ・エラー出力を理解することが重要です。ここでは、診断ログ・ファイルの内容を詳しく調べ、このファイルに記録されているエラーに関して得られる情報について説明します。この場合、実際の例を使用して説明するのが最も効果的です。
次の例は、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エラー・コードのリストについては、エラー・メッセージの第41章を参照してください。
[oracle.jps.admin]
ロガー・カテゴリを識別します。oracle.jpsのサブカテゴリ(前述のadminなど)は、発生したエラーの種類を示します。これには次の機能が含まれます。
common - 一般的なエラー。
upgrade - アップグレード・エラー。
config - 構成エラー。
deployment - デプロイ・エラー。
authentication - Java SEアプリケーションのみのログイン・モジュール・エラー。
idmgmt - アイデンティティ・ストア・エラー。
credstore - 資格証明ストア・エラー。
authorization - 実行時のポリシー・ストア・エラー。
policymgmt - ポリシー・ストア管理エラー。
admin - JMXエラーおよびWLSTエラー。
[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
発生した例外とその理由を識別します。
ドメイン内のすべてのログ・ファイルのコンテンツで検索を開始するには、「ドメイン」→「ログ」→「ログ・メッセージの表示」を選択して、「ログ・メッセージ」ページを表示します。
このページには、検索問合せを指定するために選択できる複数のパラメータがあります。具体的には、次の操作が可能です。
適切な「日付範囲」を選択することで、メッセージが発行される期間を選択できます。
「メッセージ・タイプ」ボックスのいずれかを選択することで、特定の重大度エラーを含むメッセージを表示できます。
「メッセージ」メニューから項目を選択し、その横にあるボックスに文字列を入力することで、さらなる制約を満たすメッセージを表示できます。たとえば、文字列exceptionを含むメッセージに対してのみ問合せを行うことができます。
「フィールドの追加」ボタンをクリックし、選択肢のいずれかを選択することによって、新たな問合せフィールドを追加できます。たとえば、「ホスト」フィールドを追加し、特定の文字列を先頭文字として指定した問合せ(「次で始まる」フィールドに入力)などを実行できます。
これらのパラメータを設定して、「検索」をクリックすると、問合せの結果がこのページに表示されます。問合せの結果は、「表示」メニューから項目を選択することで、メッセージ・タイプ別、メッセージ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 #
この項では、次の問題について説明します。
ファイルベースのストアから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)再関連付けを再実行します。
現象4 - 監査ストアが再関連付けされていない
リリース11gR1 (11.1.1.6.0)では、Fusion Middleware Control Enterprise Manager (EM)コンソールを使用してセキュリティ・ストアを再関連付けした場合、ほとんどのストア(ポリシー・ストア、資格証明ストアなど)が移動されましたが、監査ストアは移動されませんでした。これは、監査ストアでは、WLSTコマンドreassociateSecurityStoreを使用した再関連付けのみがサポートされ、コンソールを使用した再関連付けがサポートされていないためです。
診断4
リリース11gR1 (11.1.1.6.0)からリリース12c (12.1.2)への移行がEnterprise Managerを使用して行われた場合、監査リポジトリはファイルベースのまま残ります。次の解決策を使用すると、すべてのセキュリティ・ストア・データをLDAP/DBに移動して、監査を有効にできます。
解決策4
元の環境で、WLSTコマンドreassociateSecurityStoreを異なるjpsrootノードで実行します。これによって、OIDディレクトリ間の再関連付けが行われ、既存の任意のデータも新しいノードに移行されます。この動作を行った場合、監査データはファイル・ベースではなくなり、jps-configに新規ノードが含まれます。
この項では、LDAPサーバーへの再関連付けに失敗する理由について説明します。
現象
セキュリティ・ストアのLDAPリポジトリへの再関連付けに失敗すると、AdminServerログに、次のようなエラーがレポートされます。
[2011-02-09T07:01:13.884-05:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid: [ACTIVE].ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 41050d66ef2ec40b:-4c1fb689:12e06cc7b6c:-8000-00000000000001e1,0] Schema seeding failed, check the server type of the given ldap url.[[
oracle.security.jps.JpsException: Error Modifying JPS Schema, Record: dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113894.7.2.2 NAME 'orclContainer' SUP ( top ) MUS
T ( cn ) MAY ( orclVersion $ orclServiceType ) )
-
: [LDAP: error code 32 - No Such Object]:cn=schema
診断
「LDAP: error code 32」のエラーは、再関連付けターゲットLDAPリポジトリのスキーマがサポートされていない、つまりターゲットLDAPリポジトリのバージョンが、OPSSでサポートされているLDAPストアのいずれでもないことを示しています。
解決策
ターゲットLDAPリポジトリをサポートされているLDAPストアのいずれかに更新して、再関連付けを再度実行します。LDAP OIDストアのバージョンは、10.1.4.3以上であることが必要です。サポートされているバージョンのリストは、第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用方法」を参照してください。
現象
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サーバーで適切なスキーマがシードされていないと、システムは予期したとおりに動作しません。
再関連付けの際にスキーマが必ずシードされるようにするには、次の手順に従います。
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
この項では、アプリケーション・デプロイ時のポリシーの自動移行が失敗する理由について説明します。アプリケーションのデプロイは、ポリシーの移行に失敗しても、成功する場合があることに注意してください。
|
注意: この項で説明されている自動移行に失敗する理由が、ドメイン・ストアの再関連付けを行う際にも、同様の失敗につながる可能性があります。 |
移行に関連する失敗については、「ポリシー・ストアのバージョンの非互換性」も参照してください。
現象
デプロイ時にポリシーを自動的に移行するように、アプリケーションが構成されています。アプリケーションのデプロイは成功しますが、デプロイされていたサーバーに対応する診断ファイルに、次のようなメッセージが出力されます。
[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ファイルで適切に定義されていることを確認します。参照されたロール名が、前述の例のように一致しない場合、移行は失敗します。
この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。この項の内容は次のとおりです。
この項では、ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗する可能性がある理由について説明します。
現象
ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗し、出力されるエラー・メッセージに次の内容が含まれます。
java.lang.IllegalArgumentException: null KeyStore name
診断
この問題の原因の1つは、ドメイン内の認証プロバイダのリストに、LDAP認証プロバイダが含まれていないことです。
|
重要: OPSSを使用するすべてのドメインで、このリストのいずれかのLDAP認証プロバイダが必須です。 |
解決策
サーバーを起動できず、LDAP認証プロバイダが欠落しているため、次の手順に従って、手動で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>
サーバーを再起動します。
サーバーが再起動して稼働したら、次の手順を実行します。
OID LDAP認証プロバイダに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 Security Managerを使用したWebLogicリソースの保護の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。
|
注意: Printing Security Managerは、Javaセキュリティ・マネージャに対するWebLogicサーバーの拡張機能です。Printing Security Managerを使用して、Javaセキュリティ・マネージャの下で実行されているJavaアプリケーションで必要なすべてのパーミッションを識別できます。必要なパーミッションを一度に1つずつ識別するJavaセキュリティ・マネージャとは異なり、Printing Security Managerは、必要なパーミッションのすべてを自動的に識別します。 |
この項では、Oracle WebLogic Serverの起動に失敗する2つの理由について説明します。
現象1
ドメイン・ディレクトリ${domain.home}/config/fmwconfigはNFSマウントされたパーティション上にあり、サーバーの起動時に次のようなエラー・メッセージが記録されます。
JPS-01050: Opening of wallet based credential store failed. Reason java.io.IOException: PKI-02002: Unable to open the wallet. Check password.
さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、次のメッセージが記録されます。
java.io.IOException: No locks available.
|
注意:
|
診断1
OPSSではファイルベースのストアでのセキュリティ・アーティファクトの管理時にファイルのロックが必要であるため、エラー・メッセージNo locks availableはドメイン・ディレクトリがNFSマウントされているファイル・システムでファイルのロックがサポートされていないことを示しています。
解決策1
次の手順のいずれかを実行して、サーバーを再起動します。
NFS v3からNFS v4にアップグレードします。
nolockオプションを有効にしてリモート・ファイル・システムをマウントします。
${domain.home}/config/fmwconfig内のファイルをローカル記憶域に移動します。
現象2
ウォレット操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにして(前述の注意を参照)サーバーを再度起動すると、ファイル・パーミッション・エラーが記録されます。
診断2
ウォレット操作により、/tmpフォルダに一時ファイルを作成して使用できるようにします。パターン/tmp/*pki*と一致するすべてのファイルは、サーバーを起動したユーザーが所有する必要があります。ファイル・パーミッション・エラー・メッセージは、そのパターンと一致するファイルの一部が適切なユーザーにより所有されていないことを示しています。
解決策2
サーバーを起動しているユーザーにより所有されていない、パターン/tmp/*pki*と一致するファイルを削除し、サーバーを再起動します。
現象3
この現象は前述の現象2と同様ですが、解決策が異なります。ウォレット操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにして(前述の注意を参照)サーバーを再度起動すると、ファイル・パーミッション・エラーが記録されます。
診断3
サーバーの起動は、ドメインをインストールしたユーザーと同じOSユーザーにより実行される必要があります。インストーラが属するOSグループのメンバーでも、別のメンバーによりサーバーが起動された場合は失敗します。
解決策3
ドメインをインストールしたOSユーザーを使用してサーバーを再起動します。
この項では、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.
特定のサーバーの起動の失敗の根本原因を調べるには、そのサーバーのログ・ファイルをチェックし、記録されたスタック・トレースを確認します。エラーの特定の詳細は、「セキュリティ・エラーの診断」を参照してください。
サーバーが起動に失敗する理由を次にいくつか示します。
構成ファイルのパスの指定に誤りがあります。
構成ファイルにデフォルトのコンテンツが欠落しています。
XMLパーサーが利用不能です。
システム・ポリシーに指定されたコード・ソースURLに誤りがあります。この状況は、次の文字列を含む例外がログに記録されていることで識別されます。
java.net.MalformedURLException: unknown protocol.
解決策
次に、前述の各原因に対する解決策について説明します。
システム・パラメータoracle.security.jps.configに正しいパスが指定されていることを確認します。
-Doracle.security.jps.config=<full-path-to-jps-config.xml>
フルパスの指定時には、特殊文字(バックスラッシュや空白文字など)は正しくエスケープ処理する必要がある点に注意してください。指定内容に誤りがないか確認する方法の1つとして、なんらかのコマンドラインでそのフルパスを使用してみます。
構成ファイルには、デフォルトのコンテキストが含まれている必要があります。デフォルトのコンテキストの例は、<jpsContext>を参照してください。
使用システムでXMLパーサーが利用できることと、クラスパスにXMLパーサーのJARファイルが含まれていることを確認します。
次の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>を参照してください。
この項では、サーバーが起動フェーズを完了する前にパーミッション・チェックが失敗する理由について説明します。
現象
サーバーの起動前に認可チェックが失敗します。サーバーの起動が完了すると、次のような行が出力されます。
<WebLogicServer> <BEA-000365> <Server state changed to STARTING>
診断
サーバーのステータスがSTARTINGに変わる前のパーミッション・チェック・エラーは、通常、そのパーミッション・チェックに必要な認可サービスがリクエスト時に完全に初期化されていなかったことを示します。
解決策
この問題を回避するには、次の手順を実行します。
weblogic.policyファイルを編集して、適切な権限付与を追加します。
次の2つのシステム・プロパティを設定してOracle WebLogic Serverを起動します。
java.security.policyをweblogic.policyファイルの場所に設定します。
jps.policystore.hybrid.modeをtrueに設定します。
この項では、次の問題について説明します。
この項では、コードソースの付与に関する問題の解決方法について説明します。
現象
アプリケーションで、セキュリティ管理操作を使用するための認可が拒否され、次のような例外がログに記録されます。
java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=oracle.patching,keyName=FUSION_APPS_PATCH_WLS_ADMIN-KEY read)
ログに記録されたエラーの詳細から、アプリケーションがアクセスに失敗した操作がわかります。
診断
アプリケーション・コードが次のいずれかの操作にアクセスする必要がある場合は、コードソースへの付与が必要です。
ポリシー管理
資格証明管理
キー管理
監査管理
|
注意: コードソースの付与はシステム・ポリシーであり、アプリケーション・ポリシーにパッケージ化することはできません。 |
解決策
前述のような実行時の失敗を解決するには、次の手順を実行します。
エラーを調べ、ランタイム・システムによって確認されたコードソースURLを特定します。
URL情報が利用できない場合は、該当する特定の管理対象サーバーと管理サーバーで次のロガーを有効にして、失敗を再現します。
setLogLevel(target="serverName", logger="oracle.security.jps.util.JpsAuth", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.trace.logger", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.dbg.logger", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.internal.policystore.JavaPolicyProvider", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.jps.common", level="TRACE:32", persist=1);
|
注意: ログ・ファイルで、コードソースはJARファイルの絶対パスで指定されますが、URLは環境変数を基準として指定されます。 |
具体的なコードソースが特定されたら、構成済の付与をセキュリティ・ストアで表示し、適切なパーミッション、ターゲットおよびアクションが実際に指定されていることを確認します。
付与を表示するには、第10.2項「Fusion Middleware Controlを使用したポリシーの管理」の説明に従ってFusion Middleware Controlを使用するか、またはWSLTオンライン・コマンドlistCodeSourcePermissionsを使用します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
セキュリティ・ストアの付与がランタイム・エラーのデータと一致しない場合は、Fusion Middleware ControlまたはWSLTオンライン・コマンドgrantPermissionを使用して、付与を変更します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
|
注意: 権限が付与されたブロック内でコードを実行する必要がある場合は、そのブロック内で実行されていることを確認します。 |
この項では、エンタープライズ・ユーザーまたはロール(グループ)へのパーミッションの付与または取消に失敗する、よくある理由について説明します。
現象
ドメイン認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに対して、権限付与で定義されたパーミッションが付与または取り消されません。
診断
この問題は、(ドメイン認証プロバイダに)格納されている名前と、(ユーザーがアクティブに入力したか、プログラムによって取得された)指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致の例として、格納されているユーザー名がJdOEで、指定されたユーザー名がjdoeである場合があげられます。
解決策
この問題を解決するには、次の2つの方法があります。
1つ目の解決策としては、ドメインに使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列(格納されているものと指定されたもの)に、(大文字小文字関係なく)同じ順序の文字が含まれているかぎり、この設定により、対応する文字の大文字小文字が異なっている場合でも、サブジェクトに入力されたユーザー名が、ドメイン認証プロバイダに存在するユーザー名に一致することが保証されます。したがって、この設定が機能している場合、JdOEというユーザー名とjdoeというユーザー名は一致します。
ドメイン認証プロバイダのプロパティを設定するには、次の手順に従います。
管理コンソールを使用して認証プロバイダの構成ページに移動します。たとえば、デフォルトの認証プロバイダを使用している場合は、「レルム」→「myrealm」→「プロバイダ」→「DefaultAuthenticator」を選択して、DefaultAuthenticatorページに移動します。
「プロバイダ固有」タブを選択します。
プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。
サーバーを再起動します。
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()); |
この項では、認可チェックが失敗する理由について説明します。
現象
アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。
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を変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、ロール)を更新して、新しいデータでも予期したとおりに機能するようにする必要があります。
この項では、Java SEアプリケーションで権限付与を適切にコーディングする方法を説明します。ここ説明している問題はJava EEアプリケーションの問題ではありませんが、高い移植性を実現するために、この解決策をJava EEアプリケーションでも使用することをお薦めします。
現象
アプリケーションで権限の作成時に、アプリケーション・コードに次のようなコードが存在します。
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が使用されています。
|
注意: この同じ問題が、 |
この項では、12c HA (高可用性)ドメインでアプリケーション・ポリシーが適用されなくなる順序と、その解決方法について説明します。
現象
次の順序によって、例外がスローされます。
12c HA環境で、ドメイン管理サーバーかドメイン管理対象サーバーのいずれか(一方のみ)に対して、(アプリケーション・ポリシーとパッケージ化された)カスタム・アプリケーションをデプロイします。
アプリケーションをアンデプロイします。
手順1でデプロイしたサーバーとは異なるサーバーに、アプリケーションを再デプロイします。
前述の手順3の結果、例外が発生し、アプリケーション・ポリシーは有効になりません。この問題は、12c HAドメインでのみ検出されます。
診断
この問題は、ドメイン・サーバーでキャッシュが同期化されていないことが原因で発生します(様々なサーバーが個別のJVM (Java Virtual Machine)で実行されていることに注意してください)。
たとえば、HAドメインにサーバーA (管理サーバー)、サーバーB (管理対象サーバー)およびサーバーC (管理対象サーバー)の3つのサーバーがあるとします。さらに、アプリケーションが最初にドメイン管理サーバー(サーバーA)にデプロイされた後、3つのサーバーすべてが再起動されたとすると、(ポリシーがセキュリティ・ストアから読み込まれて)サーバーA、BおよびCのキャッシュが初期化され、同期化されます。
アプリケーションが(サーバーAから)アンデプロイされると、サーバーAのキャッシュは消去されますが、サーバーBおよびCのキャッシュは消去されません。また、アプリケーションが(たとえばサーバーBに)再デプロイされた場合は、キャッシュが同期しなくなり、例外がスローされます(これは、ポリシー・オブジェクトがすでに存在するためです)。
解決策
この問題の回避策は次のとおりです。
前述の手順2の後、手順3の前に、HAドメインのすべてのサーバーを再起動します。この手順を加えた手順によって、HAドメインのすべてのサーバーでキャッシュが同期化されるため、アプリケーション・ポリシーが予期したとおりに表示されます。
この項では、次の問題について説明します。
この項では、組込みのLDAP認証プロバイダへの接続に失敗する場合に多く見られる理由について説明します。
現象
クライアント・アプリケーションがユーザーおよびロールAPIを介して組込みのLDAP認証プロバイダに問合せをリクエストするために使用される接続は、接続プールに格納され、維持されます。デフォルトおよび出荷時の状態では、このプールは、JNDIプールとしてファイルjps-config.xmlに指定されています。
このプールの同時接続数が、LDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続中の場合は「ソケットがクローズされました」という例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。
診断
この制限を超えないようにするには、LDAPサービスで許容する最大同時接続数をアプリケーションのニーズに合わせて調整する必要があります。このしきい値はきめ細かく調整する必要があります。最大値が小さすぎると十分でなく(その結果、前述の例外が発生します)、最大値が大きすぎると、DoS攻撃のリスクが生じる場合があります。適切な最大値は、アプリケーションと、そのアプリケーションで使用する特定のLDAPサービスに依存します。
解決策
この問題の解決方法として次の2つの選択肢があります。
その認証プロバイダで許容する最大同時接続数を増やします。
アプリケーションで使用している認証プロバイダがWebLogic組込みのLDAP認証プロバイダである場合は、ファイルDomainName/servers/MyServerName/data/ldap/conf/vde.propを編集してプロパティvde.quota.max.conpersubjectの値をデフォルトの100から200などの他の値に増やします。
アプリケーションでその他の認証プロバイダを使用している場合は、その認証プロバイダのドキュメントで最大値の変更方法を確認してください。
ファイルDomainName/config/fmwconfig/jps-config.xmlを編集して、プロパティCONNECTION_POOL_CLASSを認証プロバイダのサーバー・インスタンスから削除します(デフォルトでは、このプロパティの値はoracle.security.idm.providers.stdldap.JNDIPoolになっています)。
注意点として、(a)これらの設定は相互排他的ではなく、両方実行することも可能なことと、(b)どちらの場合も変更を有効化するにはサーバーを再起動する必要があることに留意してください。
この項では、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認可のテスト」ボタンを使用してください。通常は、このテストにより、間違って指定されたパラメータを見つけることができます。 |
この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。
現象
アプリケーションが、ドメイン資格証明ストアからの資格証明データの取得に失敗し、(次に示すような行を含む)エラー・メッセージがログに記録されます(角カッコ内のテキストには、特定の失敗に固有の情報が記述されます)。
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を使用してパーミッションを指定するには、第10.2項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。
WLSTコマンドを使用してパーミッションを指定するには、第10.3項「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>
この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。
現象
実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。
<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;
...
前述の権限付与の例では、読取り操作のみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。
この項では、ポリシーと資格証明の再関連付けを行うときに匿名SSL接続を確立できない、よくある理由について説明します。
現象
Fusion Middleware Controlを使用してOracle Internet Directoryサーバーによるファイルベースのポリシーおよび資格証明とLDAPベースの記憶域の再関連付けを行う際の手順として、LDAPサーバーへの匿名SSL接続をテストします(具体的には、「LDAPのテスト」ボタンを使用します)。その結果、このテストに失敗します。
診断
ターゲットLDAPサーバーがOracle WebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。
解決策
LDAPサーバーへの接続を確立するには、LDAPサーバー上であらかじめ一部の構成を行っておく必要があります。詳細は、第9.2.1項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。
さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このポートを使用してLDAPサーバーを構成しなかった場合、接続は失敗します。
指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。通常、このポートの設定はLDAPサーバーの管理者が行います。
この項では、Oracle Business IntelligenceをOracle Fusion Middlewareセキュリティのレポート作成ツールとして使用した場合に多く見られる問題とその解決策について説明します。次のトピックが含まれます:
Oracle Business IntelligenceでOracle Fusion Middleware監査フレームワークのレポートを表示するには、適切な監査テンプレートを使用する必要があります。
詳細は、第C.2項を参照してください。
Oracle Business Intelligence Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、Oracle Fusion Middleware監査フレームワークのレポートに問題が発生することがあります。
この問題を防止するには、Oracle Business Intelligence Publisherとデータベースが、同じタイムゾーンにインストールされていることを確認します。
この項では、次の問題について説明します。
この項では、属性のカタログ化が必要な理由について説明します。
現象
ポリシー・ストアの検索中に、次のような例外が発生します。
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をポリシー・ストアの検索のフィルタとして使用するには事前にこの属性をカタログ化する必要があることを示しています。
解決策
検索フィルタで使用するOracle Internet Directoryの属性は、索引を作成したうえでカタログ化する必要があります。索引作成やカタログ化は通常は必須ではありませんが、OPSS関連の属性の場合は必須です。属性の索引作成およびカタログ化は、WLSTコマンドreassociateSecurityStoreによって自動的に実行されます。
属性のカタログの管理と属性の索引が作成済であることの確認の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。
属性を手動でカタログ化するには、次に示すように、ldapmodifyコマンドを使用します。
>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>
たとえば、属性createtimestampとmodifytimestampをカタログ化するには、次のようなLDIFファイルを使用します。
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: modifytimestamp orclindexedattribute: createtimestamp
索引を作成する必要があるOracle Internet Directory属性のリストは次のとおりです。
OrclJpsAllResourcKeyword OrclJpsAllResourceActionKeyword OrclJpsEncodedAttributes OrclJpsExtensionType OrclJpsResourceConverter OrclJpsResourceMatchingAlg OrclJpsResourceMatchingAlgorithm OrclJpsResourceNameExpression OrclJpsRoleType orcOesAppAttributes orclASInstanceName orclFarmName orclJPSObjGUID orclJavaApplicationEntityRef orclJpsPolicyDomainName orclJpsResourceActionsetMembers orclJpsResourceExpression orclJpsResourceLocalityRef orclJpsResourceMatcherJavaclass orclJpsResourceName orclJpsResourceTypeActionAttrs orclJpsResourceTypeActionNames orclJpsResourceTypeName orclJpsResourceTypeProviderName orclJpsResourceTypeResourceAttrs orclJpsRoleCategory orclJpsRoleMemberExpression orclJpsSuperResourceType orclOESActCollectionName orclOESActCollectionRfs orclOESActionAttributes orclOESActionConstraint orclOESAlgorithmJavaClass orclOESAllResourceType orclOESAllowAdviceRef orclOESAllowObligationRef orclOESAttributeCategory orclOESAttributeCollectionHandlerFunctionName orclOESAttributeCollectionHandlerPackageName orclOESAttributeCollectionHandlerSchemaName orclOESAttributeCollectionName orclOESAttributeDataType orclOESAttributeIssuer orclOESAttributeNamespace orclOESAttributeType orclOESCombinerParameter orclOESConditionExpression orclOESDSColumnAttrs orclOESDSPrimKey orclOESDataSourceCtrnt orclOESDataSourceName orclOESDataSourceType orclOESDefaultPolSetRef orclOESDenyAdviceRef orclOESDenyObligationRef orclOESDistributionEndTime orclOESDistributionID orclOESDistributionIssuer orclOESDistributionMessage orclOESDistributionPercentComplete orclOESDistributionStartTime orclOESEffect orclOESEnvAttributes orclOESEnvConstraint orclOESExecutionFrequency orclOESExpression orclOESFunctionCategory orclOESFunctionClass orclOESFunctionParameters orclOESFunctionReturnType orclOESIsSensitive orclOESIsSingleValued orclOESMatchInfo orclOESMaxDelegationDepth orclOESObligationFulfillOn orclOESPDPAddress orclOESPDPConfigurationID orclOESPDPInstanceName orclOESPDPStatusSuccess orclOESPIPType orclOESPolicyCategory orclOESPolicyCombinerParameter orclOESPolicyCombiningAlgorithmRef orclOESPolicyDefaults orclOESPolicyExtension orclOESPolicyIssuer orclOESPolicyRef orclOESPolicyRuleOrder orclOESPolicyRuleRef orclOESPolicySetCategory orclOESPolicySetDefaults orclOESPolicySetRef orclOESPolicySetType orclOESPolicyType orclOESPolicyVersion orclOESPresenceRequired orclOESPrincConstraint orclOESPrincipalAttributes orclOESResConstraint orclOESResTypeCategory orclOESResourceAttributes orclOESResourceHirchyType orclOESResourceNameDelim orclOESResourceParentName orclOESRoleMapping orclOESRuleCombinerParameter orclOESRuleCombiningAlgorithmRef orclOESSQLExpression orclOESSetCombinerParameter orclOESSetMemberOrder orclOESTargetExpression orclOESXMLExpression orclassignedpermissions orclassignedroles orcldistributionversion orcljazncodebase orcljaznjavaclass orcljaznpermissionactions orcljaznpermissionresourceref orcljaznpermissionsigner orcljaznpermissiontarget orcljaznpermissiontargetexpr orcljaznprincipal orcljaznsigner orcljpsRuleCombiningAlgorithmRef orcljpsactionsdelim orcljpsassignee orclrolescope
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
この項では、次の問題について説明します。
この項では、サーバーによって例外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バイナリのバージョンよりも新しいことを示しています。OPSSバイナリの11.1.1.4.0はそれよりも新しいバージョンのポリシー・ストアを使用できません。
OPSSバイナリでこのような非互換性が発生するシナリオには、次の3つがあります。
シナリオ1
Domain1とDomain2は同じポリシー・ストアを指しています。Domain1、Domain2およびポリシー・ストアのバージョンはいずれも11.1.1.3.0です。
Domain1のバイナリを11.1.1.4.0にアップグレードします。
ポリシー・ストアを11.1.1.4.0にアップグレードします(コマンドupgradeOPSSを使用)。
Domain2を再び起動すると、そのバージョンとポリシー・ストアのバージョンが非互換になります。
シナリオ2
Domain1と、このドメインが指しているポリシー・ストアのバージョンはどちらも11.1.1.3.0です。
ポリシー・ストアを11.1.1.4.0ポリシー・ストアにアップグレードしようとすると、失敗します。移行した場合、バージョンの非互換性が発生するためです。
移行は、OPSSバイナリとポリシー・ストアのバージョンが一致している場合にのみ可能です。
シナリオ3
11.1.1.3.0のDomain1で、join引数を指定したコマンドreassociateSecurityStoreを使用して、11.1.1.4.0のポリシー・ストア(別のドメインにあるもの)を結合しようとします。
この操作は失敗します。この共有によってバージョンの非互換性が発生するためです。
再関連付けは、OPSSバイナリとポリシー・ストアのバージョンが一致している場合にのみ可能です。
解決策
これらの3つのシナリオすべてに対処する解決策として、次のいずれかを使用できます。
ドメインのOPSSバイナリを更新して、そのドメインが指しているポリシー・ストアのバージョンと一致させます。
ドメインのポリシー・ストアの再関連付けを実行し、そのドメインのOPSSバイナリのバージョンと同じかそれより古いバージョンのポリシー・ストアに関連付けます。
この項では、OPSSセキュリティ・ストアの移行中にPolicyStoreIncompatibleVersionException例外が発生する理由について説明します。「バイナリとポリシー・ストアのバージョンの非互換性」も参照してください。
前述の例外は、移行元のストアのバージョンが移行先のストアのバージョンよりも高く、バージョンの組合せが無効であることを示しています。移行は、移行元のバージョンが移行先のバージョンよりも高くない場合にのみ実行されます。
回避策は、移行先のストアのバージョンを移行元のストアのバージョンと互換性のあるバージョンにアップグレードすることです。
この項では、次の問題について説明します。
この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。
現象
実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。
[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つのパーミッション・クラスを共有する場合、システム・クラス・パスにそのクラスを含めてください。
この項では、DBベースのOPSSセキュリティ・ストアで、ポリシーSQL操作が失敗する場合の理由について説明します。
現象
ポリシー操作の実行中に、Oracleデータベースは次のような警告を発行します。
"ORA-1652: unable to extend temp segment by 128 in tablespace"
診断
このエラーの理由は、操作により使用される一時表が一杯である、つまり、使用できる空きブロックがこれ以上ないことです。
解決策
この問題を解決するには、次の手順を実行します。
次のコマンドを使用して、一時表のサイズを4096Mに拡張します。
ALTER TABLESPACE "<TEMP_TABLESPACE_NAME>" ADD TEMPFILE '<data_file_name>' size 4096M
管理サーバーを再起動します。
Oracle Internet Directory 11.1.1.6.0を使用したセキュリティ・ストアを持つドメインでは、次のようなLDAP例外が発生します。
[LDAP: error code 53 - OID-5018: Cataloging for attr orcljpsextensiontype is already in progress.]:cn=catalogs
レポートされた属性(前述のサンプルではorcljpsextensiontype)に相違がある可能性がありますが、解決策は同じで、つまり、Oracle Internet Directory 11.1.1.6.0のBug 13782459を修正するパッチを適用します。Oracle Internet Directoryのパッチの一覧は、第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用」を参照してください。
この項では、ユーザーおよびロールAPIでドメイン認証プロバイダのデータへのアクセスに失敗する理由をいくつか説明します。
現象
ユーザーおよびロールAPIで、構成された認証プロバイダのデータへのアクセスに失敗します。
診断1
OPSSユーザーおよびロールAPIでは、ドメイン内で最初に構成されたLDAP認証プロバイダのデータにのみアクセスできます。このような認証プロバイダが少なくとも1つ、ドメイン内に存在する必要があります。その認証プロバイダにターゲット・ユーザーが存在しない場合、そのユーザーが他のドメイン認証プロバイダに存在しても、APIではその最初のLDAP認証プロバイダへのアクセスに失敗します。
解決策1
この存在していないユーザーを最初のLDAP認証プロバイダに入力するか、またはドメイン内のLDAP認証プロバイダのリストの順序を並べ替えます。
診断2
ドメイン内で最初に構成されたLDAP認証プロバイダに、APIが失敗した際のターゲット・ユーザーが存在すると仮定します。
デフォルトでは、ユーザーおよびロールAPIでは、属性uidを使用してLDAP認証プロバイダでユーザー検索を実行します。らかの理由で、LDAPで入力したユーザーにこの属性が欠落している場合、ユーザーおよびロールAPIは失敗します。
解決策2
最初のLDAP認証プロバイダのすべてのユーザーに、属性uidが設定されていることを確認します。
|
注意: Java SEアプリケーションを開発する場合のみ、ユーザーおよびロールAPIでデフォルト( <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap"> ... <property name="username.attr" value="mail"/> <property name="user.login.attr" value="mail"/> ... </serviceInstance> 指定したスクリプトを使用してプロバイダ・インスタンスにプロパティを追加するには、第E.1項「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。 |
この項では、ポリシーに使用する文字に関する問題をいくつか説明します。この項の内容は次のとおりです。
ポリシー・ストアが、LDAPベースのOracle Internet Directory 10.1.4.3リポジトリの場合、RFC 2252/2253フィルタで*、(、)または\を使用すると、エラー53 (DSAによる操作拒否)が発生します。このエラーを解決するには、バグ番号7711351用のパッチをOracle Internet Directory 10.1.4.3に適用します。
この項で説明する問題は、XMLポリシー・ストアにのみ関連します。つまり、LDAPベースのポリシー・ストアには適用されません。
ここで問題となる文字は次のとおりです。
< " & $ ? * , / \ ` : ( ) î ' % + { }
これらの文字は、ファイルベースのポリシー・ストアを使用する場合には、アプリケーション・ロール名に使用しないことをお薦めします。
たとえばロールを作成するために、これらのいずれかの文字の使用が必要になった場合は、正常な結果が返されるように、ApplicationPolicy.searchAppRoles()などのAPIポリシー・ストア・メソッドへの入力でそれらの文字をエスケープ処理します。
たとえば、アプリケーション・ロールにappRoleî$という名前を付けた場合、ポリシー・ストアで一致を検索するにはApplicationPolicy.searchAppRoles("appRole\\î\\$")のように入力する必要があります。
または、このようにエスケープ処理した特殊文字を使用せずに、次のように検索式にワイルド・カードを使用して、アプリケーション・ロールとの一致が得られるようにすることもできます。
ApplicationPolicy.searchAppRoles("appRole*")
アプリケーション・ロール名は、空白以外の印刷可能な文字列です。つまり、アプリケーション・ロール名は、英数字(ASCIIまたはUnicode)と、空白以外のその他の印刷可能文字(アンダースコアや大カッコなど)で構成することができます。このルールはサポートされている3種類の記憶域XML、LDAPおよびDBのすべてに適用されます。
ファイルベースのポリシー・ストアでは、<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>
この項では、無効な鍵サイズの例外を取得する理由をいくつか説明します。
現象
「java.security.InvalidKeyException: Illegal key size」というメッセージの例外がログに記録されます。
java.security.InvalidKeyException: Illegal key size
診断1
ドメインの作成時に、OPSSはキーストア・サービスを使用して、セキュリティ・ストア・データの暗号化に使用されるAES対称鍵を作成します。OPSSは、最初に256ビットの鍵を生成しようとします。これがサポートされていない場合は、192ビットの鍵の生成を試行しますが、それもサポートされていない場合は、128ビットの鍵を作成します。128ビットの鍵がサポートされていない場合は、前述の例外がスローされます。
診断2
(Java EEアプリケーションとSEアプリケーションの両方で)OPSSの起動時に、実行時のJDKでAESアルゴリズムがサポートされていないためにOPSS暗号化鍵が読取り不可能な場合、またはドメインがプロビジョニングされた鍵サイズがJDKでサポートされているサイズと異なる場合、前述の例外がスローされます。
解決策
前述の問題の一般的な解決策として、JDKにJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesをインストールし、ドメインの作成またはOPSSの起動を再試行します。
My Oracle Support(以前のMetaLink)(http://myoraclesupport.oracle.com)でより多くの解決策を参照できます。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。
