| Oracle Fusion Middlewareリリース・ノート 11gリリース1(11.1.1) for Microsoft Windows x64 B55938-04 |
|
 前 |
 次 |
| Oracle Fusion Middlewareリリース・ノート 11gリリース1(11.1.1) for Microsoft Windows x64 B55938-04 |
|
前 |
次 |
この章では、次の項でOracle Platform Security Services(OPSS)に関連するトピックについて説明します。
この章に含まれるトピックには次のドキュメントが関連します。
『Oracle Fusion Middlewareセキュリティ・ガイド』
『Oracle Fusion Middlewareセキュリティ概要』
Oracle Fusion Middlewareの管理者ガイド
Oracle Fusion Middleware Authorization Policy Manager管理者ガイド
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
この項では、Oracle Fusion Middleware Audit Frameworkの構成に関する問題について説明します。内容は次のとおりです。
Oracle Enterprise Manager Fusion Middleware ControlではOracle Access Managerはコンポーネントの1つとして表示されますが、Fusion Middleware Controlを使用してOracle Access Managerの監査を構成することはできません。
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で表示できません。情報は英語で表示されます。
この問題は、Oracle Business Intelligence Publisherの今後のリリースで修正される予定です。
Oracle Business Intelligence Publisherにパッケージされている標準監査レポートでは、多数の言語がサポートされます。
不具合のため、翻訳されている場合でも、レポート・タイトルと説明が英語で表示されます。
この問題は、Oracle Business Intelligence Publisherの今後のリリースで修正される予定です。
PS3に対してRCUが実行されると、監査スキーマの作成が完了し、作成のステータスは「success」になります。ただし、RCUによって呼び出されるSTS.sqlスクリプトの表記上の問題が原因でSTS表は作成されません。
表を作成できなかったことを示す情報が見つかるのは、iau.logファイルが調べられたか、作成した表に限定して検索した場合のみです。
この問題のため、リリース11g PS3の完全インストールでは、監査スキーマを作成することを選択し、このスキーマの使用を計画している場合は、STS表が作成されていることを明示的に確認する必要があります。
この問題を解決するには、RCUがPS3に対してすでに実行されているかどうかに応じて、2つのオプションを選択できます。
オプション1
RCUがPS3に対してまだ実行されていない場合、このオプションを使用します。手順は次のとおりです。
次のファイルを開いて編集します。
$RCU_HOME/rcu/integration/iau/scripts/STS.sql
STS.sql内の行番号48のカンマを削除します。
ファイルを保存し、閉じます。
次のファイルを開いて編集します。
$RCU_HOME/rcu/integration/iau/iau.xml
文字列11.1.1.3.0を検索し、これを文字列11.1.1.4.0に置き換えます。
ファイルを保存し、閉じます。
RCUを実行します。
オプション2
RCUがPS3に対してすでに実行されている場合、このオプションを使用します。手順は次のとおりです。
次のファイルを開いて編集します。
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql
STS.sql内の行番号48のカンマを削除します。
ファイルを保存し、閉じます。
STS.sqlをコピーし、これが実行される場所に貼り付けます。
sysdbaとして接続し、次のSQLコマンドを実行します。
sqlplus> connect /as sysdba; sqlplus> alter session set current_schema=audit_schema_user; sqlplus> @@STS.sql audit_schema_user audit_schema_user_Append audit_schema_user_Viewer
audit_schema_userは監査スキーマ・ユーザーの名前に置き換えます。
このノートでは、監査スキーマをPS1またはPS2からPS3にアップグレードする場合(この場合のみ)に適用する際に必要な回避方法について説明します。次の回避方法は、パッチ・セット・アシスタント(PSA)を実行する前に実行する必要があります。
回避方法を実装するには、次の手順を実行します。
コピー
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/sql/scripts/STS.sql
次のように変更します。
$COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/STS.sql
コピーしたファイルを開いて編集します。
行番号48のカンマを削除します。
ファイルを保存し、閉じます。
次のファイルを開いて編集します。
$COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau111134.sql $COMMON_COMPONENTS_HOME/common/sql/iau/upgrade/ iau11114.sql
次の各行を処理します。
行ALTER TABLE OAM ADD IAU_ResourceTemplateName VARCHAR(100);を削除します。
行ALTER TABLE OAM ADD IAU_AdditionalInfo CLOBの直前に次の行を挿入します。
RENAME COLUMN IAU_AdditionalInfo TO IAU_AdditionalInfo_OLD;
編集した両ファイルを保存して閉じます。
この時点で、PSAを使用できるようになります。
11gR1では、XMLをLDAPストアに再関連付けする処理により、末尾の新規行文字\nまたはその等価コード
を使用して、ブートストラップ・キーが作成されます。このキー値は、ファイルjps-config.xmlに書き込まれてウォレットに格納されます。両方の場所で、キー値の末尾には文字\nが含まれます。
同じウォレットを11gR1 PS1で再利用した場合、ブートストラップ・キーの取得時にシステムによって末尾の\n文字が削除されますが、ウォレット内のキー値には末尾の文字が含まれたままになります。リクエストされるキー値と格納されているキー値が一致しなくなるため、この状況はエラーにつながります。
この問題を解決するには、次の手順を行います。
WLSTコマンドmodifyBootStrapCredentialを使用して、末尾に\nを使用せずにウォレットの資格証明を再プロビジョニングします。コマンドの使用方法は、『Oracle Fusion Middlewareセキュリティ・ガイド』の9.5.2.5項を参照してください。
ファイルjps-config.xmlを手動で編集して、末尾の文字
をブートストラップ・キーから削除します。
この問題が発生するのは、前述のシナリオの場合、つまり11gR1のウォレットを11gR1 PS1で再利用した場合のみです。具体的には、11gR1 PS1環境での再関連付けの際は、前述の末尾文字は問題になりません。
同じユーザー名が複数のLDAPリポジトリ内に存在するときに、プロパティ仮想化でLibOVDを使用するよう設定されている場合、この名前に対する問合せが実行されると、ユーザーおよびロールAPIによってこれらの1つのリポジトリのみのデータが戻されます。
LinuxおよびWindowsプラットフォームで、ロケールがfr_FR_iso88591などのUTF8以外のロケールに設定されている場合、OPSSスクリプトlistAppRolesは、予想される文字ではなく、文字「?」を間違って出力する可能性があります。
この項では、次の追加情報、修正情報および新情報を示します。
次の新情報は、19.3.1.2項に属するものです。
即時利用可能な構成では、トークン発行者名およびキー別名はWebLogicサーバー名に基づいていることを前提としています。WebSphereでは、キー別名サーバー名はWebSphereサーバー・ルートに基づいて設定されます。たとえば、サーバー・ルートが$T_WORK/middleware/was_profiles/DefaultTopology/was_as/JrfServerの場合、サーバー名はJrfServerに設定されます。デフォルト値を変更するには、19.3.12項で説明されている手順を使用します。
次のサンプルは、クライアント・アプリケーションを示しています。jps-api.jarファイルおよびOSDT jarsのosdt_ws_sx.jar、osdt_core.jar、osdt_xmlsec.jar、osdt_saml2.jarは、コード・サンプルがコンパイルするクラスパスに含める必要があります。
WebLogicサーバー名をjrfServer_adminとした場合、次のコマンドは、生成されたファイルdefault-keystore.jksによって表される、キーストアの作成を示しています。
この項の情報は新しく、スクリプトを使用したjps-config.xmlファイルのトラスト・サービス構成パラメータの変更方法について説明しています。
パラメータtrust.aliasNameおよびtrust.issuerNameの初期状態の値はWebLogicサーバー名に設定されています。これらの値をデプロイ固有の値に変更するには、次のようなスクリプトを使用します。
import sys
wlsAdmin = 'weblogic'
wlsPwd ='password_value'
wlUrl='t3://localhost:7001'
issuer= 'issuer'
alias = 'alias'
print "OPSS Trust Service provider configuration management script.\n"
instance = 'trust.provider'
name = 'trust.provider.embedded'
cfgProps = HashMap()
cfgProps.put("trust.issuerName", issuer)
cfgProps.put("trust.aliasName", alias)
pm = PortableMap(cfgProps);
connect(wlsAdmin, wlsPwd, wlUrl)
domainRuntime()
params = [instance, name, pm.toCompositeData(None)]
sign = ["java.lang.String", "java.lang.String", "javax.management.openmbean.CompositeData"]
on = ObjectName("com.oracle.jps:type=JpsConfig")
mbs.invoke(on, "updateTrustServiceConfig", params, sign)
mbs.invoke(on, "persist", None, None)
print "Done.\n"
WebSphere Application Serverで、すぐに使用できる構成ファイルjps-config.xmlにアイデンティティ・ストアのプロパティのエントリがありません。インストール後に追加されたアイデンティティ・ストアがLDAPベースのアイデンティティ・ストアである場合、次のプロパティを、アイデンティティ・ストア・サービス・インスタンス要素内のjps-config.xmlファイルに手動で挿入する必要があります。
<property name="CONNECTION_POOL_CLASS"
value="oracle.security.idm.providers.stdldap.JNDIPool"/>
この問題を回避するには、次の手順を行います。
サーバーを停止します。
ファイルwas_profile_dir/config/cells/cell_name/fmwconfig/jps-config.xmlを編集用に開きます。ここでwas_profile_dirおよびcell_nameはシステム上のプロファイルのディレクトリ名とセル名を表します。
欠落したプロパティCONNECTION_POOL_CLASSをアイデンティティ・ストア・サービス・インスタンスの構成に挿入します。
ファイルを保存してサーバーを再起動します。
この項では、Authorization Policy Managerに関する問題について説明します。内容は次のとおりです。
アプリケーション・ロール検索の実行時に
An error has occurred. Please view the logs for details
というメッセージを含むエラーが発生し、(ファイルapm_server1-diagnostic.logに)記録されたエラーに、次のフラグメントのようにPolicyStoreOperatioNotAllowedExceptionが含まれる場合があります。
[2010-03-02T22:06:29.998-08:00] [apm_server1] [ERROR] [] [oracle.security.apm] [tid: [ACTIVE].ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 0000ISYcUY2B1FcpPg1Fid1BXsJn00006W,0] [APP: oracle.security.apm] PolicyStoreException while calling searchAppRole[[ oracle.security.jps.service.policystore.PolicyStoreOperationNotAllowedExceptio n: javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Parent entry not found in the directory.];...
このような場合は、操作を再試行するとエラーなしで実行されます。
Authorization Policy Managerのコンポーネントでは、次のバージョンのInternet Protocolがサポートされます。
Oracle Database (IPv4ホスト上)
Authorization Policy Managerサーバー(IPv4/IPv6デュアルスタック・ホスト上)
クライアント(ブラウザ)(IPv4またはIPv6ホスト上)
WindowsまたはUNIX/Linuxの64ビット・オペレーティング・システムでこの問題を回避するには、次の手順を行います。
パッチに含まれるREADME.TXTファイルの説明に従って、変数ORACLE_HOMEおよびPATHを設定します。
次に示すどちらかの起動でOPatchを実行します。
> OPatch -jre <64-bit java home location> lsinventory > OPatch -jdk <64-bit java home location> lsinventory
正常に実行された場合はOpatch succeededが返されます。それ以外の場合は、渡された場所が有効かどうかを確認します。
ディレクトリをパッチの場所に変更します。
> cd <patch location>
次に示すどちらかの起動でOPatchを実行します。
> OPatch -jre <64-bit java home location> apply > OPatch -jdk <64-bit java home location> apply
この項では、ドキュメントの訂正箇所について説明します。内容は次のとおりです。
この注には、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』(原本部品番号E10043-10)のアイデンティティ・ストア・サービス用SSLに関する項の概要が含まれます。
ドキュメントの更新1
7.5項の最初を、アイデンティティ・ストア・サービスが使用される様々なシナリオを説明するように更新します。
7.5 アイデンティティ・ストア・サービス用SSL
アイデンティティ・ストアとLDAPサーバー間の接続をSSL対応にすることができます。この項では、様々なシナリオで、接続を構成する方法について説明します。次の表を使用して、使用する正しい手順を決定します。
| 仮想化フラグが設定される場合 | ユーザーとロールのAPIが使用中 | アイデンティティ・ディレクトリ・サービスが使用中 |
|---|---|---|
|
virtualize=false (つまり仮想化フラグを設定しない) |
8.2.3項で説明しているように、JSSEパラメータを使用してトラストストアを指定します。 次に例を示します。 -Djavax.net.ssl.trustStore= |
7.5.2項および7.5.3項に示すように、adapters.jksファイルを使用します。 |
|
virtualize=true (つまり、仮想化フラグを設定) |
7.5.2項および7.5.3項に示すように、adapters.jksファイルを使用します。 |
7.5.2項および7.5.3項に示すように、adapters.jksファイルを使用します。 |
ドキュメントの更新2
7.5.4項の情報を削除します。これは必要ありません。
この注には、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』(原本部品番号E10043-10)のロール・カテゴリに関する項で説明されているように、ロール・カテゴリの正しい構成が含まれます。
2.8項に示したjazn-data.xml内の要素<role-category>の構成は、次で置き換えられる必要があります。
<app-roles>
<app-role>
<name>AppRole_READONLY</name>
<display-name>display name</display-name>
<description>description</description>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<extended-attributes>
<attribute>
<name>ROLE_CATEGORY</name>
<values>
<value>RC_READONLY</value>
</values>
</attribute>
</extended-attributes>
</app-role>
</app-roles>
<role-categories>
<role-category>
<name>RC_READONLY</name>
<display-name>RC_READONLY display name</display-name>
<description>RC_READONLY description</description>
</role-category>
</role-categories>
この修正の重要な点は次のとおりです。
ロール・カテゴリのメンバーは<role-category>要素内で構成されませんが、対応するアプリケーション・ロールの要素<extended-attributes>内で構成されます。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の7.5.2項「マルチLDAPシナリオでの一方向SSL」で、libovdconfigコマンドのcreateKeystoreオプションのスペルが間違っています。この項の"createKeyStore"は"createKeystore"です(小文字の's')。
『Oracle Fusion Middlewareセキュリティ概要』(B56236-03)の2.3.5項「ポリシー・ストアおよびポリシーAPI」に、ポリシー・ストアとして機能するLDAPディレクトリとしてOracle Virtual Directoryがリストされています。この記述は間違っています。Oracle Virtual Directoryはポリシー・ストアとしてサポートされていません。
2.3.5項内の箇条書き「LDAPディレクトリ」の下の箇条書き「Oracle Virtual Directory」は削除してください。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』部品番号E10043-12の8.6.2項「スクリプトmigrateSecurityStoreを使用した移行」の後に、次を追加します。
監査メタデータの移行
migrateSecurityStore WLSTコマンドを使用して、監査メタデータをドメイン・セキュリティ・ストアに移行するか、監査メタデータをXMLファイルに移行できます。
次の点に注意してください。
監査メタデータは監査ポリシー定義とは分けられます。(監査ポリシーの移行の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の6.5.3項を参照してください。)
監査メタデータのタイプは、システム定義とコンポーネント定義の2種類あります。
監査メタデータの移行時に、移行先ストアの既存のデータを上書きするか保持するかを選択できます。選択に基づき、後述のように、migrateSecurityStoreは特定のルールに従って、移行先ストアのシステムおよびコンポーネント定義を置き換える方法を決定します。
次の構文を使用して、監査メタデータを移行します。
migrateSecurityStore(type="auditStore", configFile="jps_config_file_location", src="sourceContext", dst="destinationContext" [,overWrite="{true|false}"])
このコマンドを使用して、移行元コンテキスト内に構成された監査サービスのメタデータを移行先コンテキストの監査サービスに移行できます。ソースおよびターゲット・コンテキストの監査メタデータは、XML、LDAPおよびDBベース・ストア内にある可能性があります。
このパラメータは次のとおりです。
configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。通常、この構成ファイルはスクリプトで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。
srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。これはソース・メタデータ・ストアです。
dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。これはターゲット・メタデータ・ストアです。
overWriteはターゲット・ストア内の既存のメタデータを上書きするかどうかを示します。trueは既存のメタデータを上書きし、falseは特定の条件に合致しない限り既存のメタデータを上書きしません。オプションで、デフォルトはfalseです。overWriteフラグは、次のように解釈されます。
システム定義はフラグの値にかかわらず上書きされません。
overwrite=trueの場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。
overwrite=falseの場合、ソースおよびターゲット・ストア内のコンポーネント定義のメジャーおよびマイナー・バージョンが比較されます。メジャー・バージョンが同じで、ソース・コンポーネント定義内のマイナー・バージョンが高い場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。そうでない場合、上書きはスキップされます。
