| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章は、予期されるシステム動作およびOracle Access Manager 10g（10.1.4.0.1）と以前のリリースとの変更点をまとめたものです。10g（10.1.4.0.1）の動作と製品の変更点に加え、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能な拡張機能があります。特に明記されていない場合、リリース10g（10.1.4.0.1）およびリリース10g（10.1.4.2.0）は同様に機能します。この章には、変更のない動作はほとんど含まれていません。
この章の内容は次のとおりです。
|
注意: Oracle Access Manager 10g（10.1.4.0.1）の動作については、クイック・リファレンス表（および新機能の概要）が『Oracle Access Manager概要』に記載されています。また、「製品およびコンポーネントの名前の変更」も参照してください。10g（10.1.4.0.1）は、10.1.4シリーズのOracle Access Managerリリースを示します。10.1.4シリーズには、ベースの10g（10.1.4.0.1）インストールおよび10.1.4.2.0パッチ・セットを含むインストールがあります。最新のパッチ・セットで使用可能な拡張機能の概要は、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)を参照してください。 |
リリース7.0.4（Oracle Application Server 10gリリース2（10.1.2）の一部としても利用可能）と10g（10.1.4.0.1）の間では、プラットフォーム・サポートに大きな変更はありません。ただし、7.0.4より前のリリースと10g（10.1.4.0.1）の間には大きなサポートの差異があります。
最新のサポート情報は、次のサイトの「Certify」タブを参照してください。
http://metalink.oracle.com
https://metalink.oracle.comのMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
サポートが終了したコンポーネントとサード・パーティ製品については、「終了したサポート」にクイック・リファレンス表が記載されています。
Oracle Access Manager 10g（10.1.4.0.1）は、パッチ・セットではなくメジャー・リリースです。Oracle Access Manager 10g（10.1.4.2.0）はパッチ・セットです（リリース10.1.4パッチ・セット1（10.1.4.2.0）とも呼ばれます）。パッチ・セットは、十分にテストされ統合された製品の修正を提供するメカニズムです。
パッチ・セットには、新機能が組み込まれる場合があります。たとえば、リリース10.1.4パッチ・セット1（10.1.4.2.0）では、停止時間ゼロのアップグレード・メソッドに必要なツールが提供されます。10g（10.1.4.2.0）で使用可能な拡張機能の詳細は、「リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能な拡張機能」を参照してください。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の説明に従って、最新のパッチ・セットを適用することをお薦めします。ただし、適用する前に次の考慮事項を検討してください。
Oracle Access Manager 10g（10.1.4.0.1）をインストールしてリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用すると、そのコンポーネント・インスタンスは10g（10.1.4.0.1）であるとみなされます。この場合、後続のパッチ・セットを適用する前に、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除する必要があります。
10g（10.1.4.0.1）パッケージを使用して新しい10g（10.1.4.0.1）インスタンスをインストールしてから、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。
インプレース・メソッドを使用してOracle Access Manager 10g（10.1.4.0.1）にアップグレードする場合、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。この場合、コンポーネント・インスタンスはリリース10g（10.1.4.0.1）であるとみなされます。将来のパッチ・セットをインストールする前に、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除する必要があります。
インプレース・アップグレード後に、新しい10g（10.1.4.0.1）インスタンスをインストールして環境を拡張してから、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。
停止時間ゼロのアップグレード・メソッドを使用してアップグレードする場合、Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能なツールを使用します。これらのツールを入手するには、アップグレード前に10g（10.1.4.0.1）コンポーネントのライブラリおよびファイルを抽出して、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。アップグレード後のインスタンスはリリース10g（10.1.4.2.0）であるとみなされます。この場合、後続のパッチ・セットを適用する前に、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除できません。
停止時間ゼロのアップグレードを行う前に環境を拡張するには、第VI部の説明に従い、以前のインスタンスを追加してからアップグレードします。ただし、リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。
リリース10.1.4パッチ・セット1（10.1.4.2.0）に組み込まれている機能の詳細は、「リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能な拡張機能」を参照してください。
次の手順では、リリース10.1.4パッチ・セット1（10.1.4.2.0）の入手方法を説明します。後続のパッチ・セットが入手可能な場合があります。常に最新のパッチ・セットを適用することをお薦めします。
リリース10.1.4パッチ・セット1（10.1.4.2.0）を入手する手順
次のようにOracle MetaLinkのWebサイトにアクセスして、リリース10.1.4パッチ・セット1（10.1.4.2.0）を入手します。
https://metalink.oracle.comのMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Patches & Updates」タブをクリックします。
「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
「Latest Oracle Server/Tools Patchsets」ラベルの下にある「Oracle Oblix COREid」をダブルクリックします。
ページ下部の表から、10g（10.1.4.0.1）の最新のパッチ・セットを探して選択します。たとえば、リリース10.1.4パッチ・セット1（10.1.4.2.0）を入手するには「5957301」を選択します。
「Platform or Language」リストから、デプロイに適切なプラットフォームを選択して「Download」をクリックします。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)に記載された手順を使用して、パッチ・セットの適用前に環境を準備します。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)に記載された手順に従って、10g（10.1.4.0.1）の各コンポーネント・インスタンスにリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)にある適用後のタスクを実行して、使用環境が適切に動作するかどうかを確認します。
それぞれの環境で使用されたアップグレード・メソッドに該当する条件に従って、アップグレードした環境を管理することをお薦めします。次に考慮事項を示します。
10g（10.1.4.0.1）パッケージを使用してインプレース・アップグレードを実行してから、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。アップグレード後にこの環境を拡張するには、新しい10g（10.1.4.0.1）インスタンスを追加して、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。
停止時間ゼロのアップグレードを実行してアップグレード前に環境を拡張するには、第VI部の説明に従って以前のインスタンスを追加します。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。10g（10.1.4.0.1）パッケージを追加してリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用すると、「最新のパッチ・セットの入手」で説明したように後続のパッチに影響があります。
使用するメソッドを問わず、コンポーネントをアップグレードすると、以前のプラグインやほとんどのコンポーネントとの下位互換性が自動的に有効になりますただし、以前のコンポーネントとの下位互換性が備わらないコンポーネントもあります。表4-1に、その概要と追加情報の参照先を示します。
表4-1 Oracle Access Managerコンポーネントの下位互換性
| コンポーネント | 下位互換性への自動対応 | 詳細の参照先 |
|---|---|---|
|
アイデンティティ・サーバーをアップグレードすると、以前のカスタム・プラグインとの下位互換性が自動的に備わります。 インプレース・アップグレード後に10g（10.1.4.0.1）のアイデンティティ・サーバーを追加する場合は、以前のカスタム・プラグインと下位互換にするためのフラグを手動で設定する必要があります。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。 アップグレードしたアイデンティティ・サーバーには、以前のWebPassインスタンスとの下位互換性はありません。 アイデンティティ・サーバーではOblixOrgPersonのobVer属性の値を使用して、ロスト・パスワード管理用のチャレンジ属性とレスポンス属性の複数の値からなるユーザー・データの移行をサポートします。 |
|
|
|
以前のアイデンティティ・サーバーをすべてアップグレードしたら、以前のWebPassインスタンスもすべてアップグレードする必要があります。 以前のWebPassインスタンスには、10g（10.1.4.0.1）のアイデンティティ・サーバー（またはポリシー・マネージャ）との互換性がありません。 アップグレード後の環境に10g（10.1.4.0.1）のWebPassインスタンスをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebPassインスタンスには、以前のアイデンティティ・サーバー（またはポリシー・マネージャ）との互換性はありません。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。 |
|
|
|
スキーマとデータおよびすべてのアイデンティティ・システム・コンポーネントをアップグレードしたら、以前のポリシー・マネージャもすべてアップグレードする必要があります。 |
|
|
|
以前のアクセス・サーバーをアップグレードすると、以前のカスタム・プラグインおよび以前のWebGateとの下位互換性が自動的に備わります。 ただし、アップグレード環境に10g（10.1.4.0.1）のアクセス・サーバーを追加する場合は、下位互換にするフラグを設定する必要があります。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。 以前のアクセス・サーバーには、10g（10.1.4.0.1）のWebGateとの互換性はありません。 アクセス・サーバーではOblixOrgPersonのobVer属性を使用して、ロスト・パスワード管理用のチャレンジ属性とレスポンス属性の複数の値からなるユーザー・データの移行をサポートします。 |
|
|
|
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされた10g（10.1.4.0.1）のアクセス・サーバーと共存できます。 アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のアクセス・サーバーとの互換性はありません。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。 アップグレード後の環境に10g（10.1.4.0.1）のアクセス・サーバーを追加する場合は、以前のWebGateと下位互換にするためのフラグを設定する必要があります。 |
|
「保持される項目」で説明したように、Oracle Access Manager 10g（10.1.4.0.1）では、以前のインストールで実行されたカスタマイズが保持されます。ただし、表4-2に示すように、カスタマイズした項目を以前の環境からアップグレード環境にアップグレードする、すなわち組み込むための手動タスクを実行する必要がある場合がいくつかあります。詳細は、「カスタマイズのアップグレード計画」を参照してください。
表4-2 カスタマイズをアップグレードするために実行する必要のある手動タスク
Oracle Access Manager 10g（10.1.4.0.1）には、以前のリリース（6.1.1、6.5または7.x）を10g（10.1.4.0.1）にアップグレードする際にプラットフォームをSolarisからLinuxに切り替える手法があります。詳細は、付録Bを参照してください。リリース10.1.4パッチ・セット1（10.1.4.2.0）では、停止時間ゼロのアップグレードの実行に必要なツールが提供されます。停止時間ゼロのアップグレードの詳細は、第15章を参照してください。
動作の説明を探すためにすべてのマニュアルを調べずに済むよう、この章には、前述の各表に加えて、Oracle Access Manager 10g（10.1.4.0.1）で予期される動作がまとめられています。
この項では、以前のアイデンティティ・システムとアクセス・システムに共通していた動作について説明します。10g（10.1.4.0.1）へのアップグレード後の、以前の動作との変更点および予期される動作を中心に説明します。内容は次のとおりです。
以前の製品リリースでは、エンドユーザーおよび管理者に対するメッセージは、英語のみで提供されていました。リリース6.5以降、特定のLatin-1言語（フランス語とドイツ語）に対する言語パックを通して、翻訳可能なメッセージのサポートが提供されるようになりました。Oracle Access Manager 10g（10.1.4.0.1）では、『Oracle Access Manager概要』で説明されているように、約10種類の管理者用言語と20種類以上のエンドユーザー用言語がサポートされています。
Oracle付属の言語パックをインストールした後、使用するすべての言語を有効にしてから、属性、タブおよびパネルの表示名を入力して、インストールした言語を使用するOracle Access Managerを構成する必要があります。アップグレード後に複数の言語をインストールして有効にする方法の詳細は、『Oracle Access Managerインストレーション・ガイド』と『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
10g（10.1.4.0.1）にアップグレードするかまたは10g（10.1.4.0.1）をインストールする場合は、管理タスクのデフォルトとして使用する言語（ロケール）を選択します。アイデンティティ・システム・コンソール、アクセス・システム・コンソールおよびポリシー・マネージャの管理情報は、インストールした管理者用の言語でのみ表示されます。以前のリリースでは、言語のドロップダウン・リストがシステム・コンソールの右上隅に表示されていました。10g（10.1.4.0.1）から、このリストがなくなりました。言語を選択する唯一の方法は、ユーザーまたは管理者のコンピュータのブラウザの設定を変更することです。管理ページを（ブラウザで選択された言語に基づいた）任意のユーザー言語でリクエストすると、管理ページが、製品のインストール（またはアップグレード）時にデフォルト管理者言語として選択された言語で表示されます。
Oracle Access Managerスタイルシートでのメッセージは言語に依存します。リリース6.5のマルチ言語機能以降、メッセージはスタイルシートから離れて、msgctlg.xsl（JavaScriptファイルの場合はmsgctlg.js）で変数として別に定義されるようになっています。さらに、各スタイルシートに対しては対応する言語固有のシン・ラッパーがIdentityServer_install_dir\identity\oblix\lang\langTag\style0に格納されています。\style0内の各ラッパーに対しては、メインの言語非依存スタイルシートがIdentityServer_install_dir\identity\oblix\lang\sharedに格納されています。この新しいシン・ラッパーの目的は、言語非依存スタイルシートのテンプレートの主要な機能を、スタイルシートの言語固有メッセージから分離することです。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
詳細は、「コンソール・ベースのコマンドライン・インタフェース」を参照してください。
Crystal Reportsパッケージは、Oracle Access Managerパッケージと一緒には提供されなくなりました。この製品はベンダーから入手する必要があります。
Oracle Access Manager 10g（10.1.4.0.1）は、Unicode規格をサポートしています。Oracle Access Manager 10g（10.1.4.0.1）で使用可能な言語をすべてサポートするために、監査およびレポートの表の定義が変更されました。既存のデータベース・インスタンスや表の単純なアップグレードや変更はサポートされていないため、それらの処理を行うと、既存データが永久的に切り捨てられ、失われます。詳細は、「監査およびアクセス・レポート」を参照してください。
Oracle Access Managerコンポーネントを10g（10.1.4.0.1）にアップグレードした後に、監査およびレポート環境が正常に動作することを保証するために実行する必要のあるステップについては、次の監査およびアクセス・レポートに関するトピックを参照してください。
また、アイデンティティ・システム・コンソールで監査ポリシーを構成するときは、すべての監査レコードに対してプロファイル属性のリストを指定できます。プロファイル属性（「フルネーム」、「従業員番号」、「部門番号」など）は、監査されるアクション/イベント（「検索」、「プロファイルの表示」、「プロファイルの変更」など）を実行するユーザーに固有です。プロファイル属性は、アクションやイベントを実行しているユーザーを識別しやすくするためのものです。
|
警告: チャレンジ・フレーズまたはレスポンス属性の公開を回避するために、監査のプロファイル属性としてこれらを選択しないことをお薦めします。チャレンジ・フレーズまたはレスポンスをプロファイル属性として追加すると、これらは独自のエンコード形式で監査されます。 |
リリース10.1.4パッチ・セット1（10.1.4.2.0）の拡張機能を使用すると、ユーザーはパスワードの変更後に自動ログインできます。自動ログインを構成するには、変更パスワード・リダイレクトURLにSTLogin=%applySTLogin%をパラメータとして含める必要があります。ユーザーをログインさせる変更パスワード・リダイレクトURLの例を次に示します。
/http://hostname:portnumber/identity/oblix/apps/lost_password_mgmt/bin/lost_password_mgmt.cgi? program=redirectforchangepwd&login=%login%%userid%&backURL=% HostTarget%%RESOURCE%&STLogin=%applySTLogin%&target=top
フォーム・ベース認証スキームでこれを実装するには、ユーザー名の資格証明パラメータを第1トークンとして指定し、パスワードの資格証明パラメータを第2トークンとして指定してから、その他の資格証明パラメータを指定して、チャレンジ・パラメータcredsを構成する必要があります。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ldifde.exeツールのライセンスの問題のため削除されました。ADAMのスキーマは手動で更新してください。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
7.0より前のリリースからアップグレードする場合は、Access Manager SDKおよびOracle Access Manager APIを使用して作成したC++プログラムを、アップグレードの後で再コンパイルする必要があります。詳細は、次を参照してください。
10g（10.1.4.0.1）アイデンティティ・サーバーは、以前のアクセス・サーバーのキャッシュをフラッシュできません。この問題を解決するには、アクセス・サーバーを10g（10.1.4.0.1）にアップグレードする必要があります。
詳細は、「アクセス・サーバーの下位互換性」を参照してください。
ディレクトリ・サーバーとOracle Access Managerサーバー、およびディレクトリ・サーバーとポリシー・マネージャとの間の通信は、オープン（セキュリティなし）にするか、またはSecure Sockets Layer（SSL）を使用できます。SSL対応の場合は、サード・パーティの認証局から提供されるBase64形式の署名者の証明書（ルート認証局（CA）証明書）を要求します。
Webクライアント間（WebPassとアイデンティティ・サーバー間、ポリシー・マネージャとWebPass間、およびアクセス・サーバーとWebGate間）の通信用には、3つのトランスポート・セキュリティ・モードが用意されています。これらのセキュリティ・モードとは、「オープン」、「シンプル」（Oracle付属）、および「証明書」（サード・パーティCA）です。
簡易モードと証明書モードでは、Oracle Access ManagerのコンポーネントはX.509デジタル証明書のみを使用します。この機能では、標準cert-decodeプラグインが証明書をデコードし、証明書情報を標準credential_mapping認証プラグインに渡す証明書認証がWebGateとアクセス・サーバー間で行われます。
オラクル社とサード・パーティ・ベンダーはどちらも、ローカライズされた証明書を、コンポーネントとディレクトリ・サーバー間のLDAP SSL通信に対してのみでなく、「証明書」モードでインストールされたOracle Access Managerコンポーネントに対しても提供します。10g（10.1.4.0.1）でのローカライズとUTF-8のサポートにより、「電子メール」と「国」（x509標準に基づく）を除くすべてのフィールドに非ASCIIテキストを含むローカライズされた証明書を、要求して追加することができます。ローカライズされた証明書を受け取ったら、『Oracle Access Manager IDおよび共通管理ガイド』で説明されているいずれかのOracle Access Managerコマンドライン・ツールを使用して、ローカライズされた証明書をインストールする必要があります。サーバー上で言語が英語でないオペレーティング・システムが動作している場合は、『Oracle Access Managerインストレーション・ガイド』の説明に従って、Oracle National Language SupportのNLS_LANG環境変数とCOREID_NLS_LANG環境変数の一方または両方を設定して、自動サーバー・ロケール検出機能を変更できます。Oracle Access Managerは自動的にサーバー・ロケールを検出して使用するため、これらの環境変数の設定はオプションです。
Oracle Access Manager 7.0（Oracle Application Server 10gリリース2（10.1.2）の一部としても利用可能）以降、LDAP SSL証明書のデフォルトの証明書ストアの形式および名前がcert7.dbからcert8.dbに変わっています。10g（10.1.4.0.1）にアップグレードするときは、古い証明書ストア（cert7.db）が使用されます。Oracle Access Manager 10g（10.1.4.0.1）は、cert7.db（アップグレードされた環境）とcert8.db（新規インストール）の両方の証明書ストアで動作します。アップグレード後に新規の証明書ストアを手動で生成する必要はありません。ただし、証明書ストアの形式および名前をcert8.dbに自動的に変更するconfigureAAAServer、setup_oisまたはsetup_accessmanagerユーティリティを使用して証明書を追加、変更または削除すると、常に新規の証明書ストアの生成が透過的に行われます。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Access Managerリリース7.0以降、それより前のコンパイラ・リリースで発生していたマルチスレッドの問題に対処するため、SolarisおよびLinuxでのコンポーネントはGCC v3.3.2 C++コンパイラを使用してコンパイルされます。つまり、アップグレードした後は、GCC v3.3.2 C++コンパイラを使用して、リリース5.xまたは6.xのカスタム・プラグインを再コンパイルする必要があります。これには、アイデンティティ・イベント・プラグインと、カスタム認証および認可プラグインも含まれます。
詳細は、次を参照してください。
|
警告: オペレーティング・システムに付属のコンパイラがある場合でも、GCC v3.3.2コンパイラを使用する必要があります。 |
以前のバージョンのOracle Access Managerは、一部の情報（ディレクトリ接続情報やWebGateパラメータを含むがこれに限定されない）を、XMLおよびLSTの構成ファイルのみで管理していました。10g（10.1.4.0.1）のOracle Access Managerでは、このような情報を管理するためにグラフィカル・ユーザー・インタフェース（GUI）を使用できるようになりました。「ディレクトリ・サーバーの接続の詳細」と「WebGate」も参照してください。
Oracle Access Managerリリース7.0以降、接続プールはシステム全体でのフェイルオーバーのサポートに統合されました。ディレクトリ接続プールは、ディレクトリのタイプに依存しません。
使用される各ディレクトリ・サーバーに対するOracle Access Managerの以前の構成によって、アップグレードになんらかの影響が出る場合があります。
アイデンティティ・システム接続プール: 影響はありません。データベース・インスタンス・プロファイルで指定した「最初の接続数」および「最大接続数」は保持され、以前と同様に機能します。
リリース6.5より前のアクセス・システム接続プール: UserDB.lstおよびUserDBFailover.lstの「最初の接続数」および「最大接続数」の値は保持されません。アクセス・システム・コンポーネントをアップグレードした後は、新規に作成されたディレクトリ・サーバー・プロファイルのデータベース・インスタンス・プロファイルの値を確認することをお薦めします。
NDS: NDSディレクトリ・サーバーへの同時認証リクエストの場合は、システム・コンソールを使用して、接続プールのサイズを、ユーザー・ディレクトリ・プロファイルのデフォルト（1）より大きい値に設定することをお薦めします。
「ディレクトリ・サーバーのフェイルオーバー」も参照してください。
Oracle Access Managerには、管理者がアクセス・コンポーネントとアイデンティティ・コンポーネントを構成するために使用できるコンソール・ベースのコマンドライン・ツールが用意されています。10g（10.1.4.0.1）コマンドライン・ツールは、サーバーのロケールを自動的に検出して処理に使用します。オプションで、環境変数COREID_NLS_LANGとNLS_LANGの一方または両方を設定して、自動検出をオフに切り替え、サーバーのロケールより優先させることができます。
英語でないオペレーティング・システムでコマンドライン・インタフェースを正しく動作させるには、『Oracle Access Managerインストレーション・ガイド』の説明に従って、マスター管理者がいくつかのタスクを実行する必要があります。
製品のデフォルト・スタイルシートは、オラクル社によって、改善点を反映するために定期的に更新されます。アップグレードされる機能は、最新の\style0ディレクトリと\sharedディレクトリにあるスタイルシート・ファイルに一部依存します。
カスタマイズされた.XSLスタイル・ファイル、イメージ、およびJavaScriptファイルは、アップグレードの際には移行されません。カスタマイズされたイメージ、JavaScriptファイルおよびスタイルシートが以前のOracle Access Managerインストールに含まれている場合は、これらを10g（10.1.4.0.1）で使用するための手動処理が必要です。Oracle Access Managerのデフォルトのクラシック・スタイル以外のスタイルを使用する場合は、10g（10.1.4.0.1）のスタイルシート、イメージおよびJavaScriptファイルに対して変更内容を手動で反映する必要があります。
Oracle Access Manager 6.5以降、カスタマイズを言語とスタイルに非依存にするため、2つの変数（$gifPathNameおよびjsPathName）を使用してイメージを参照する必要があります。
|
注意: アップグレードの際、以前のインストールで作成されたスタイル関連ディレクトリは保存されますが移行されず、名前変更された（バックアップ）ソース・ディレクトリに格納されます。アイデンティティ・システムをアップグレードした後、カスタマイズされたスタイルを10g（10.1.4.0.1）で使用するための手動処理を行う必要があります。「6.5より前のリリースからのカスタマイズの組込み」を参照してください。 |
Oracle Access Managerリリース6.5以降、複数の言語をサポートするため、JavaScript、スタイルシートおよびイメージの場所が変更されました。リリース6.5で導入されたディレクトリ構造が、10g（10.1.4.0.1）でも引き続き使用されています。
以前のリリースでは、Latin-1キャラクタ・セットが使用されていました。10g（10.1.4.0.1）のOracle Access Managerでは、Unicodeキャラクタ・セットと代表的な言語のキャラクタ・セット（中国語、日本語、アラビア語など）をサポートしています。
新しいインストールでは、データベースに対してUnicodeキャラクタ・セットを選択することをお薦めします。以前のインストールを10g（10.1.4.0.1）にアップグレードする場合は、データベース・キャラクタ・セットをUnicodeに変更する必要があります。
Latin-1キャラクタ・セットを使用していた以前のリリースでは、監査およびレポートに関する表の列はvarchar型で十分でした。10g（10.1.4.0.1）の監査レコードには、Latin-1以外のキャラクタ・セットを使用したデータが含まれることがあります。詳細は、「監査およびアクセス・レポート」を参照してください。
次のようにアイデンティティ・システムとアクセス・システム間で形式が異なる場合があります。
アイデンティティ・システム: 10g（10.1.4.0.1）のアイデンティティ・システムでは、日付の形式は最新のリリースと同じであり、国際化されていません（たとえば、「診断」ページや「チケット情報」ページなど）。ただし、アイデンティティ・システムのメッセージ・カタログから取得される月の名前は、ブラウザで指定されているロケールで表示されます。
『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、以前のリリースと同様に、日付の順序の形式（MM/DD/YYYYとDD/MM/YYYYなど）は、アイデンティティ・システム・コンソールでオブジェクト・クラス属性を変更することで構成できます。「チケット情報」ページの日付は、globalparams.xmlファイルのobDateTypeパラメータで指定されている形式で表示されます。週日の名前は、アイデンティティ・システム内のどこにも出現しません。
アクセス・システム: 10g（10.1.4.0.1）のアクセス・システムでは、月の名前、日付順序の形式（MM/DD/YYYYかDD/MM/YYYYか）、および週日の名前は、ブラウザに対して指定されているロケールに従って表示されます。アクセス・システムでは、月および週日の名前はメッセージ・カタログ・ファイルからは取得されません。次の情報がロケール間で異なる場合があります。
アクセス・システムの日付形式: 日付形式は、アクセス・システム側でのみ国際化されているため、ブラウザ側ではブラウザに指定されているロケールで表示されます。たとえば、インドでは日付形式が通常DD/MM/YYYYで表示されます。一方、米国では日付形式が通常MM/DD/YYYYで表示されます。
アクセス・システムの月の名前: 以前のリリースでは、月の名前は、サーバーにある言語固有のメッセージ・カタログを使用して表示されていました。これは、ユーザーには月の名前がサーバーのロケールで表示されていたことを意味します。10g（10.1.4.0.1）アクセス・システムでは、月の名前にユーザーのブラウザのロケールが反映されます。
|
注意: 月の名前および週日の名前（フルネームと略称の両方）はglobalmsg.xmlファイルから削除されました。タイム・ゾーンの場所がoblixadminmsg.xmlとpolicyservcenmsg.xmlから削除されました。これらのファイルは\AccessServer_install_dir\access\oblix\lang\en-usにあります。 |
アクセス・システムの週日の名前: 以前のリリースでは、週日の名前は、月の名前と同様に、サーバーのロケールにある言語固有のメッセージ・カタログから取得されていました。アクセス・システム10g（10.1.4.0.1）では、週日の名前にユーザーのブラウザで指定されたロケールが反映されます。
アクセス・システムのタイムゾーン・リスト: 以前のリリースでは、ロケーション/市区町村の名前がグリニッジ標準時（GMT）との時差と一緒に表示されていました。ただし、夏時間ルールが存在するためにロケーションと時差の組合せは静的でありませんでした。
10g（10.1.4.0.1）のタイムゾーン・リストには、協定世界時（UTC）+/-00:00〜12:00の形式で表される時差のみが表示されます。たとえば、UTC-00:00、UTC+01:00、UTC-03:30のように表示されます。
|
注意: Universal Time Coordinated（UTC）はCoordinated Universal TimeやUniversal Coordinated Timeと称されることもあります。これらはすべてUTCと略され、世界各地に共通した標準時間を表します（標準時間はかつてグリニッジ標準時（GMT）や世界時間のことを指していましたが、この呼称は今でも広く残っています）。UTCは、地球の子午線に沿った平均太陽時を表します。時間の形式は前回のリリース（7.0、Oracle Application Server 10gリリース2（10.1.2）の一部としても利用可能）と同じままです。 |
これらが動作する例は、アクセス・サーバーの「診断」ページ、ポリシー・マネージャで作成されたアクセス・ポリシーの「認可ルール」の下にある「タイミング条件」ページ、「アクセス・システム・コンソール」の「システム管理」タブにある「レポートの管理」ページ、およびアクセス・システム・コンソールの「システム管理」タブにある「同期レコードの管理」ページに表示されます。
Oracle Access Manager 10g（10.1.4.0.1）では、アドレス/identity/oblix/index.htmlおよび/access/oblix/index.htmlには、1つの静的なHTMLページだけが存在できます。
これらの静的な製品ページでは、この場所にアイデンティティ・サーバーとアクセス・サーバーをインストールした際に選択されたデフォルトの管理者用言語が常に使用されます。リリース6.5以降、製品は複数のLatin-1言語（フランス語、ドイツ語）をサポートしています。製品ページのデフォルトの動作は、以前のリリースと同じままです。
「HTMLページ」も参照してください。
リリース10.1.4パッチ・セット1（10.1.4.2.0）には、クロスサイト・スクリプティングとSQLインジェクションを検出して処理する拡張機能があります。これらの拡張機能により、Oracle Access Managerのユーザー・アプリケーションや管理コンソールへの悪質なデータ・エントリが防止されます。
リリース10.1.4パッチ・セット1（10.1.4.2.0）には、アイデンティティ・サーバーおよびアクセス・サーバーの新しい診断ツールがあります。これは、Oracleサポート・サービス担当者と連携して問題に対処する際に役立ちます。
この診断ツールを使用すると、次の操作を行えます。
コンポーネントの構成および動作に関する検出困難な情報を取得します。
コア・ダンプ直前のイベントを自動的に取得します。
アイデンティティ・システムまたはアクセス・システムのイベントのスタック・トレースを手動で取得します。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
リリース5.2以降、アイデンティティ・システムにはディレクトリ・プロファイルとデータベース・インスタンスが導入されました。リリース6.5以降、アクセス・システムは、ユーザー・データへのアクセスに対するディレクトリ・プロファイルとデータベース・インスタンスの使用を部分的に開始しました。ディレクトリ・プロファイルは、アクセス・システムの以前のリリースで使用されていたUserDB.lst、GroupDB.lst、UserDBFailover.lst、GroupDBFailover.lstの各構成ファイルのかわリに使用されます。
ディレクトリ・プロファイル（ディレクトリ・サーバー・プロファイルとも呼ばれます）には、同じネームスペースを共有する1つ以上のディレクトリ・サーバーに対する接続情報、および読取り、書込み、検索などに関する操作要件が含まれています。接続情報には、名前、適用されるドメインまたはネームスペース、ディレクトリ・タイプ、および操作のセットが含まれます。
各ディレクトリ・プロファイルには、複数のプライマリおよびセカンダリのデータベース・インスタンスを指定できます。各データベース・インスタンス・プロファイルは、1つのディレクトリ・サーバーへの接続情報（接続プール情報など）を表します。
ディレクトリ・プロファイルは、アイデンティティ・サーバー、ポリシー・マネージャまたはアクセス・サーバーをインストールして新しいディレクトリ・サーバー接続情報を指定するたびに自動的に作成されます。ロード・バランシングおよびフェイルオーバーのために追加のディレクトリ・サーバー・プロファイルを作成できます。
以前のポリシー・マネージャまたはアクセス・サーバーをアップグレードする場合は、リリース6.5への段階的アップグレードの際に、新しいディレクトリ・プロファイルが作成されたことを示すメッセージが表示されます。「DB Profiles created.」というメッセージは、このディレクトリ・サーバー・プロファイルを指しています。アクセス・システムの新しいディレクトリ・プロファイルを作成すると、以前の構成ファイルの接続プール値が保持できません。アップグレードの終了後、新規に作成したディレクトリ・プロファイルのデータベース・インスタンス・プロファイルでこれらの値を確認する必要があります。「接続プールの詳細」も参照してください。
Oracle Access Managerの以前のバージョンでは、ディレクトリ接続情報はXML構成ファイルによってのみ管理されていました。最近のリリースでは、アイデンティティ・システム・コンソールおよびアクセス・システム・コンソールの「ディレクトリ・プロファイル」ページを使用するインタフェースを通して、この情報を管理できます。ただし、構成データとポリシー・データの一部は、依然としてXMLファイルによって管理されています。「ディレクトリ・プロファイルとデータベース・インスタンス・プロファイル」も参照してください。
アイデンティティ・サーバーのフェイルオーバー構成は、リリース5.2以降、システム・コンソールのディレクトリ・サーバー・プロファイルに格納されています。リリース6.5以降は、次に示すとおりです。
マスター・ディレクトリ・サーバーとフェイルオーバー・ディレクトリ・サーバーに関するディレクトリ・サーバー・プロファイルが作成されるようになりました。
構成されているすべてのプライマリ（およびセカンダリ）ディレクトリ・サーバーごとに1つのデータベース・インスタンス・プロファイルを作成するために、特定の構成ファイルにあるディレクトリ・サーバー情報が使用されるようになりました。
たとえば、リリース6.5への段階的アップグレード中に、アクセス・サーバーのディレクトリ・プロファイルが自動的に作成され、次に示すいくつかの以前の構成ファイルに置き換えられます。
ポリシー・マネージャに対するディレクトリ・サーバー・プロファイルを作成する場合、ディレクトリ・サーバー資格証明はPolicyManager_install_dir/access/oblix/config/userDB.lstから読み取られます。
|
注意: 構成ツリーがユーザー・ディレクトリ・サーバー内でユーザー・ノードの下にある場合、構成ディレクトリ・プロファイルは作成されません。ノードの下にない場合、構成ディレクトリ・プロファイルはPolicyManager_install_dir/oblix/config/ldap/configdb.lstからのディレクトリ・サーバー情報を使用して作成され、ポリシー・マネージャ専用としてマークされます。 |
ポリシー・マネージャ・フェイルオーバー・サーバー用に使用されるプロファイルが作成されなくなります。リリース6.1では、ポリシー・ツリーが別のディレクトリ・サーバー上にある場合に、ポリシー・データのプロファイルが用意されていました。
アクセス・サーバーがデータのアップグレード後に複数のディレクトリ・サーバーに対応できるようになりました。
アップグレード後に以前のリリースでのフェイルオーバー構成が意図したとおりに動作するかどうかを確認するには、次の項目を参照してください。
「メッセージ・ファイルとパラメータ・ファイル」で説明されているように、以前の.lstファイルが.xmlファイルに変換されます。「接続プールの詳細」も参照してください。
リリース10.1.4パッチ・セット1（10.1.4.2.0）の拡張機能では、LDAPOperationTimeoutという名前の新しいパラメータがglobalparams.xmlにあります。これは、コンポーネントがセカンダリ・サーバー（構成されている場合）にフェイルオーバーする前に、アイデンティティ・サーバー、アクセス・サーバーまたはポリシー・マネージャが、検索結果の単一エントリについてディレクトリ・サーバーからのレスポンスを待機する時間を設定します。
globalparams.xmlのheartbeat_ldap_connection_timeout_in_millisパラメータにより、ディレクトリ・サーバーとの接続を確立する時間制限が決まります。この時間制限に達すると、アイデンティティ・サーバーおよびアクセス・サーバーは別のディレクトリ・サーバーとの接続の確立を開始します。このパラメータを使用すると、アイデンティティ・サーバーやアクセス・サーバーがディレクトリ・サーバーの停止時間をプロアクティブに確認でき、ディレクトリ・サービス・リクエストの着信とその後のTCPタイムアウトがない場合でもフェイルオーバーが有効になります。
詳細は、『Oracle Access Managerデプロイメント・ガイド』のフェイルオーバーに関する章と、『Oracle Access Managerカスタマイズ・ガイド』のパラメータ・ファイルに関する付録を参照してください。
10g（10.1.4.0.1）のディレクトリ・サーバー・インタフェースは、UTF-8エンコーディングを使用してデータの読取り、処理および格納を行います。以前のリリースもこれと同じ方法で動作していました。そのため、アップグレード後の環境に影響はありません。Oracle Access Managerは以前のリリースでもディレクトリ・サーバー通信にUTF-8エンコーディングを使用していました。
英語が唯一の言語となっていたため、リリース6.5より前の製品には言語関連ディレクトリが含まれていませんでした。10g（10.1.4.0.1）のコンポーネントをインストールするときは、最上位レベルのディレクトリの名前を自由に設定できます。インストール中に、Oracle Access Managerでは、ユーザーが割り当てたディレクトリ名に対して、インストールされたコンポーネントの種類を識別するための識別子を付加します。たとえば、最上位構造は次のようになります。
OracleAccessManager\access: アクセス・サーバーのインストール時に作成されます。
OracleAccessManager\identity: アイデンティティ・サーバーのインストール時に作成されます。
OracleAccessManager\webcomponent: Oracle Access Manager Webコンポーネント（WebPass、Access Manager、WebGate）のインストール時に作成されます。
リリース6.5から10g（10.1.4.0.1）をインストールすると、言語ディレクトリが作成され、その下にはインストールされた各言語の名前が付いたサブディレクトリが追加されます（このサブディレクトリには、カスタマイズ可能な各種アプリケーション用の.XMLメッセージ・カタログ・ファイルが含まれます）。
詳細は、付録Aを参照してください。
以前のリリースの製品と同様に、10g（10.1.4.0.1）でも、ドメイン名およびUniform Resource Identifier（URI）に対してASCII文字をサポートしています。URIの最も一般的な形式はWebページのアドレスです（URIのサブセットの1つがUniform Resource LocatorまたはURLとして知られています）。
Oracle Access Manager 10g（10.1.4.0.1）では、ドメイン名、Uniform Resource Identifierおよびその拡張サブセットであるURLのいずれに対しても、代表的言語のキャラクタ・セットがサポートされていません（すなわち、国際化されたドメイン名や国際化されたリソースIDがありません）。
Oracle Access Managerリリース7以降では、AESがアクセス・システム・コンポーネントで使用される暗号化スキームになりました。アイデンティティ・システムは、ロスト・パスワード管理レスポンスに対して引き続きRC6暗号化を使用します。
共有シークレット暗号化アルゴリズムは、すべての暗号化Cookieに影響を与える、Oracle Access Manager全体に対しての設定です。たとえば、ObSSOCookieは共有シークレットと呼ばれる構成可能な暗号化キー（鍵）を使用して暗号化されます。
リリース6.xで使用される共有シークレット鍵では、RC6暗号化スキームが推奨されていました。（RC6暗号化はOracle Access Manager 10g（10.1.4.0.1）で非推奨となり、将来のリリースではサポートされなくなります。）
AESは、リリース7.0で新規に導入された暗号化スキームであり、10g（10.1.4.0.1）でも引き続き使用されます。AESはデフォルトの暗号化スキームになります。
以前のWebGateが組み込まれている環境では、最も初期の暗号化アルゴリズムを使用する必要があります。
詳細は、「共有シークレット」、および『Oracle Access Managerアクセス管理ガイド』の暗号化スキームの設定に関する項を参照してください。
Oracle Access Managerリリース7では、接続プール内の接続の数が指定されているしきい値レベルを下回った場合のセカンダリ・ディレクトリ・サーバーへの即時フェイルオーバーを容易にする、ハートビート・ポーリング・メカニズムが導入されました。さらに、優先される接続がリカバリされるとただちに、フェイルバック・メカニズムによって容易にセカンダリ・ディレクトリ・サーバーからプライマリ・サーバーに戻すことができます。
ハートビート機能は、すべてのプライマリ・ディレクトリ・サーバー接続を定期的にポーリングし、ディレクトリ・サービス（および暗黙的にネットワーク）の可用性を検証します。ポーリング間隔を構成するには、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、システム・コンソール内のディレクトリ・プロファイルごとに「スリープ時間（秒）」パラメータを設定します。
ホストに到達できない場合、このホストへのこれ以降の接続は、以前に使用されたTCPのタイムアウト時間ではなく、指定されたスリープ時間の間、ブロックされます。
globalparams.xmlの新規のheartbeat_ldap_connection_timeout_in_millisパラメータにより、接続を確立するタイムアウト間隔が決まります。このパラメータのデフォルト値は4000（4秒）です。『Oracle Access Managerデプロイメント・ガイド』を参照してください。
ディレクトリ・サービスが使用できない場合、ハートビート・メカニズムはただちにセカンダリ・ディレクトリ・サーバーへのフェイルオーバーを開始します。したがって、フェイルオーバーは、ディレクトリ・サービス・リクエストの受信とその後のTCPタイムアウトによってトリガーされることなく実行できます。
エンタープライズ・ネットワークのパフォーマンスが低下している場合、ハートビート機能は異常警報をトリガーし、すでに確立されている接続を切断できます。したがって、globalparams.xmlのheartbeat_enabledパラメータを使用することで、現在のネットワーク状態に対応してハートビート・メカニズムをアクティブ化または非アクティブ化することができます。デフォルトでは、ハートビート機能はアクティブになっています。
以前のリリースと同様に、ファイル名とパス名にはASCII文字のみがサポートされます。
|
注意: すべてのファイルおよびパス名は英語の文字のみで指定してください。ファイルおよびパス名に、国際文字は使用できません。 |
Webベースのグラフィカル・ユーザー・インタフェースを改善してわかりやすくするために、いくつかの変更が行われました。これらの変更は、『Oracle Access Manager概要』に概説されており、マニュアル・セット全体でも説明されています。
各アイデンティティ・システム・アプリケーション（ユーザー・マネージャ、グループ・マネージャ、組織マネージャなど）により、アプリケーション内の各ページのHTMLが生成されます。アクセス・システム・コンポーネント（ポリシー・マネージャやWebGateなど）でもHTMLページが生成されます。以前のリリースでは、HTMLページを生成して表示する場合にLatin-1キャラクタ・セットのスーパーセットを使用していました。
10g（10.1.4.0.1）では、Oracle Access Managerによって生成されるすべてのHTMLページはUTF-8エンコーディングを使用します。このエンコーディングは、Content-TypeのHTTPヘッダーとMETAタグを使用してWebブラウザに通知されます。
Unicode版のフォントを使用すると、サポートされているすべてのブラウザ上でUTF-8エンコーディングが正しく表示されます。サポートされているブラウザについては、『Oracle Access Managerインストレーション・ガイド』を参照してください。
いくつかのWebサーバー（Apacheなど）では、管理者はHTTPヘッダーであるContent-Typeを使用してデフォルトのエンコーディングを指定できます。ただし、Webサーバーの設定に別のキャラクタ・エンコーディングが指定されていると、Oracle Access ManagerのHTMLページが正しく表示されません。
|
注意: 不正な動作を防止するために、Webサーバーのこのような設定を無効にすることをお薦めします。 |
「デフォルトの製品ページ」も参照してください。
リリース10.1.4パッチ・セット1（10.1.4.2.0）には、ModifyLDAPBindPasswordという形式の拡張機能があります。このコマンドを使用すると、Oracle Access Managerコンポーネントと通信するディレクトリ・サーバーに対するLDAPバインドのパスワードを、Oracle Access Manager構成ファイルで定期的に更新できます。
ModifyLDAPBindPasswordコマンドを使用する場合、サーバーの再起動や設定の再実行を行わずにLDAPバインドのパスワードをリセットできます。
詳細は、『Oracle Access Managerデプロイメント・ガイド』のシステムの再構成に関する章を参照してください。
6.5より前のリリースでは、Oracle Access Managerのメッセージは各アプリケーション向けのXMLファイルで制御され、アプリケーション固有のディレクトリに格納されていました。次に例を示します。
IdentityServer_install_dir/identity/oblix/apps/appname/bin/appnamemsg.xml
ここで、IdentityServer_install_dirはアイデンティティ・サーバーがインストールされているディレクトリで、appnameは次に示すように特定のアプリケーションに対応しています。
10g（10.1.4.0.1）では、これらのメッセージ・ファイルは、言語固有のディレクトリに配置されるようになりました。たとえば、IdentityServer_install_dir/identity/oblix/lang/langTag /oblixbasemsg.xmlなどです。
また、以前のリリースでは、パラメータ・カタログとメッセージ・カタログが.xmlおよび.lst（独自仕様）の形式のファイル内に混在していました。たとえば、アクセス・システムとSNMPエージェントのメッセージとパラメータが.LSTファイルに格納されていました。.lstファイルは、必要上、.xmlに変換されていました。
Oracle Access Manager10g（10.1.4.0.1）へのアップグレード時には、以前のメッセージ・カタログとパラメータ・カタログのカスタマイズが自動的に保持されます。また、.lstファイルがXML形式に変換されます。
|
注意: アップグレード中は、メッセージが英語で表示されます。 |
Oracle Access Manager 10g（10.1.4.0.1）の新規インストールには、パラメータ・カタログとメッセージ・カタログの.xmlファイルが含まれています。このルールの例外には、Oracle Access Manager 10g（10.1.4.0.1）へのアップグレードの間に使用されるファイル（形式が独自仕様の.lstのまま変わらないois_520_to_600_msg.lstなど）があります。10g（10.1.4.0.1）アップグレード・ツールでは、.lstのメッセージ・カタログとパラメータ・カタログが使用されます。
リリース10.1.4パッチ・セット1（10.1.4.2.0）には、新規パラメータMigrateUserDataTo1014がglobalparams.xmlファイルにあります。このパラメータは、第15章で説明する停止時間ゼロのアップグレード・メソッドを使用してアップグレードする場合にのみ有効です。これは、停止時間ゼロのアップグレード・メソッドでアップグレードした後、ユーザーの最初のログイン時にアイデンティティ・サーバーとアクセス・サーバーで使用されます。
このユーザー・データの移行は、ユーザー・データのオンザフライ移行とも呼ばれます。この移行は、ディレクトリ・サーバーのユーザー（人）・エントリ（OblixOrgPerson）のobVer属性に影響を与えます。また、ロスト・パスワード管理用のチャレンジ属性とレスポンス属性にも影響があります。チャレンジ属性とレスポンス属性の複数の値は、Oracle Access Manager 10g（10.1.4.0.1）で導入されました。その他に、ユーザーの最初のログイン時に移行されるユーザー・データ属性はありません。
globalparams.xmlファイルのMigrateUserDataTo1014で可能な値は次の2つです。
true: 値がtrueの場合、ユーザー（ユーザーまたは管理者を問わず）の最初のログイン時にそのユーザーのロスト・パスワード管理のチャレンジ・パラメータが自動的に移行されます。
次の状況では、この値はデフォルトでtrueに設定されます。
Oracle Access Manager 10g（10.1.4.0.1）をインストールしてからリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した場合。この場合、コンポーネントのインスタンスはOracle Access Manager 10g（10.1.4.0.1）になります。
Oracle Access Manager 10g（10.1.4.0.1）へのインプレース・アップグレードを実行してからリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した場合。この場合、コンポーネントのインスタンスはOracle Access Manager 10g（10.1.4.0.1）になります。
false: 値がfalseの場合、ユーザーの最初のログイン時にそのユーザーのロスト・パスワード管理のチャレンジ・パラメータは自動的に移行されません。
この値は、停止時間ゼロのアップグレード・メソッドを使用してアップグレードする場合のみ、デフォルトでfalseに設定されます。停止時間ゼロのアップグレードでは、Oracle Access Manager 10g（10.1.4.0.1）をインストールしてからリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した後、アップグレードを完了します。この場合、コンポーネントはOracle Access Manager 10.1.4.2.0にアップグレードされます。
停止時間ゼロのアップグレードを完了し、アップグレードが成功したことを確認したら、10.1.4.2.0の各アイデンティティ・サーバーおよびアクセス・サーバーのglobalparams.xmlファイルでパラメータMigrateUserDataTo1014の値をtrueに変更する必要があります。globalparams.xmlの変更は自動的に伝播されません。最初の箇条書きで示したように、値がtrueの場合、ユーザーの最初のログイン時にそのユーザーのロスト・パスワード管理のチャレンジ・パラメータが自動的に移行されます。
globalparams.xmlファイルは、次のディレクトリにあります。
IdentityServer_install_dir/identity/oblix/apps/common/bin
WebPass_install_dir/Webcomponent/identity/oblix/apps/common/bin
PolicyManager_install_dir/Webcomponent/access/oblix/apps/common/bin
AccessServer_install_dir/access/oblix/apps/common/bin
パラメータMigrateUserDataTo1014は、10.1.4.2.0のアイデンティティ・サーバーおよびアクセス・サーバーでのみ使用されます。通常、globalparams.xmlファイルのパラメータはすべてのコンポーネントに対して同じものもあれば、一部のコンポーネントにのみ固有のものもあります。globalparams.xmlファイルの内容の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
以前のリリースでは、アイデンティティ・システム・アプリケーションで検索を実行するときには、3文字以上入力する必要がありました。10g（10.1.4.0.1）では、必要な最小文字数はありません。以前のリリースのように、ユーザーが検索フィールドに入力する必要がある最低文字数を制御できます。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
以前のリリースのロスト・パスワード管理機能では、単一のチャレンジおよびレスポンスのみがサポートされていました。ユーザー・エントリのチャレンジ・フレーズ属性とレスポンス属性には単一の値のみが使用されていました。次に例を示します。
ChallengeAttribute: what is your name?
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name)
以前のリリースでは、ディレクトリ・サーバーのユーザー（人）・エントリ（OblixOrgPersonなど）のobVer属性は、情報提供のみを目的として現行リリースを表していました。
Oracle Access Manager 10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性で複数の値がサポートされ、これらの値はエンコード形式で使用されます（@n#が複数の値を区切るデリミタとして使用されます）。次に例を示します。
ChallengeAttribute: what is your name?@1#what is your school name?@2#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#SGschool@2#)
ChallengeAttribute: what is your name?@1#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#)
|
注意: 複数の値を区切るデリミタ@n#のnは、チャレンジまたはレスポンスの数を表します。Oracle Access Manager 10g（10.1.4.0.1）では、チャレンジおよびレスポンスの値が単一の場合でもエンコード形式が使用されます。 |
Oracle Access Manager 10g（10.1.4.0.1）では、ユーザー・エントリ（OblixOrgPerson）でobVer属性が使用され、ロスト・パスワード管理用のチャレンジ・フレーズ属性とレスポンス属性のエンコーディングを示します。詳細は、「obVer属性の変更」を参照してください。
インストールまたはアップグレードの後にわかるように、一部の製品名とコンポーネント名が変更されます。アップグレードの間に、以前の製品名、コンポーネント名および機能名が新しい名前に変更されます。たとえば、10g（10.1.4.0.1）では、デフォルトのポリシー・ドメインはIdentityドメインおよびAccessドメインであり、デフォルトの認証スキームはOracle Access and Identity、AD Forest用のOracle Access and Identityおよび匿名です。アップグレードにより、以前の名前が新規の名前に置き換えられます。
いくつかの機能名が、アクセス・システムとアイデンティティ・システムの間で統一された名詞句として修正されました。AMサービスのステータスという呼称がポリシー・マネージャAPIサポート・モードに変更されました。詳細は、「製品およびコンポーネントの名前の変更」を参照してください。
インストールおよび構成の際に管理者が割り当てた名前は、アップグレードの間保持されます（変更されません）。したがって、サービスに「COREid Identity Server」または「NetPoint Identity Server」と名前を付けた場合、これらの名前はアップグレード環境でも変わりません。以前の認証スキームとポリシー・ドメインも、アップグレード時に保持され、変更されません。「保持される項目」も参照してください。
リリース6.5より前は、2つの異なるディレクトリに格納されるポリシー・データとユーザー・データに対するネームスペースは、一意である必要がありました。10g（10.1.4.0.1）へのアップグレードの際、マルチ言語機能を使用できるようにするためには、この一意性を確認する必要があります。
詳細は、「ディレクトリ接続情報用の一意のネームスペースの構成」を参照してください。
Oracle Access Managerの現行リリースを特定するobVer属性は、数あるOracle Access Managerスキーマ・オブジェクトのクラス記述の属性の1つです。たとえば、obVer属性はoblixPanel、oblixConfig、oblixLocation、oblixMetaAttribute、oblixEnumおよびOblixOrgPersonなどの一部です。
リリース10g（10.1.4.0.1）まで、obVer属性は情報提供のみを目的としていました。しかし、リリース10g（10.1.4.0.1）以降では、obVer属性がアイデンティティ・サーバーおよびアクセス・サーバーで使用され、ロスト・パスワード管理に使用するチャレンジ・フレーズ属性やレスポンス属性での複数の値のエンコーディングをサポートします。この場合、Oracle Access Manager 10g（10.1.4.0.1）は次のクラスのobVer属性を読み取ります。
oblixConfigクラス: 構造化クラスは、Oracle Access Manager構成データのコンテナ・ノードを定義します。
oblixConfigにはobVer属性が常に存在し、COREidまたはOracle Access Managerのリリースを表します。
OblixOrgPersonクラス: Oracle Access Managerの個人情報と、構造化された人オブジェクト・クラスとして構成されたクラスを関連付けるために使用する補助クラス。
OblixOrgPersonでは、obVerが存在する場合と存在しない場合があります。obVerがユーザー・エントリに存在しない場合、その値は10.1.4.0より小さいとみなされます。
Oracle Access Manager 10g（10.1.4.0.1）では、OblixOrgPersonクラスのobVer値が次のように使用されます。
obVerの値が10.1.4.0より小さい場合、チャレンジ・フレーズとレスポンスの値は単一であり、エンコーディングは使用されません。次に例を示します。
ChallengeAttribute: what is your name?
ResponseAttribute: xxxxxxxx (encrypted form of Ramakrishna)
obVerの値が10.1.4.0以上の場合、チャレンジ・フレーズ属性とレスポンス属性はエンコードされます（@n#が複数の値を区切るデリミタとして使用されます。nはチャレンジまたはレスポンスの数です）。次に例を示します。
ChallengeAttribute: what is your name?@1#what is your school name?@2#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#SGschool@2#)
ChallengeAttribute: what is your name?@1#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#
以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする場合、oblixツリーに格納されている構成データは自動的に移行され、obVer属性の値は10.1.4.0に変わります。ただし、ユーザー・データはアップグレード後の最初のログインまで移行されません。つまり、ユーザー・データ（OblixOrgPersonクラス）のobVer属性の値は10.1.4.0より小さいまま変わりません。この場合、ユーザー・データは最初のログイン時に移行され、次のようになります。
既存のチャレンジ・フレーズおよびレスポンスの値はエンコードされます（@1#が既存の値に自動的に付加されます）。
ユーザー・データ（OblixOrgPersonクラス）のobVer属性の値は、oblixツリーのルート・ノード（oblixConfig）にある移行後の構成データのobVer属性の値に設定されます。
|
注意: 10g（10.1.4.0.1）にアップグレードした後、ユーザーが最初にログインするときに、そのユーザー・エントリはすぐに移行されます。そのユーザーの既存のチャレンジおよびレスポンスの値はエンコードされ（@1#が末尾に付加され）、obVer属性の値は10.1.4.0に変わります。ただし、以前のリリースをリストアする場合、ロールバック・プロセスではこれらの変更は元に戻りません。以前のリリースにロールバックしても、OblixOrgPersonクラスのユーザー・エントリのobVer値は10.1.4.0のまま変わらず、チャレンジおよびレスポンスの値はエンコード形式のままです。インプレース・アップグレード時のユーザー・データの即時移行（オンザフライ移行とも呼ばれる）を一時的に停止するには、「最初のログイン時のユーザー・データのオンザフライ移行の一時停止」を参照してください。この操作は、停止時間ゼロのアップグレードでは必要ありません。 |
チャレンジ・フレーズ属性とレスポンス属性の複数の値については、「チャレンジ・フレーズ属性とレスポンス属性の複数の値」を参照してください。
このリリースには、パスワード・ポリシーとパスワード管理の拡張機能があります。ユーザーはパスワードに指定できる最大文字数と最小文字数を構成できます。ロスト・パスワード管理では、チャレンジとレスポンスによる複数のペアを設定し、複数のスタイルシートを作成して、ユーザーのロスト・パスワード管理に関するその他の操作を構成できます。パスワードのリセット後、最初にリクエストされたページにユーザーをリダイレクトすることもできます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Access Manager 10g（10.1.4.0.1）では、ユーザー・エントリ（OblixOrgPerson）でobVer属性の値が使用され、チャレンジ・フレーズ属性とレスポンス属性のエンコーディングを表します。この場合、以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする際に影響があります。
10g（10.1.4.0.1）では、サーバーを再起動しないでロギング・フレームワークを再構成できます。そのためには、管理者が次の各コンポーネントに対するロギング構成を手動で更新する必要があります。
ロギング・パラメータに対する変更は、1分以内に有効になります。変更を行ったサーバーを再起動する必要はありません。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
サポートされるプラットフォームおよびサード・パーティのバージョンについて、いくつか変更がありました。プラットフォームのサポートに関する詳細は、https://metalink.oracle.comの「Certify」タブで確認できるようになりました。
ディレクトリ・サーバーのSSLモードを構成する場合は、サーバー認証のみサポートされます。クライアント証明書はサポートされていません。Oracle Access Managerは、サーバー証明書を、製品の設定の際にインポートされたルートCA証明書と比較して検証します。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Access Manager 10g（10.1.4.0.1）には、以前のリリース（6.1.1、6.5または7.x）を10g（10.1.4.0.1）にアップグレードする際にプラットフォームをSolarisからLinuxに切り替える手法があります。詳細は、付録Bを参照してください。
リリース10.1.4パッチ・セット1（10.1.4.2.0）では、停止時間ゼロのアップグレードの実行に必要なツールが提供されます。
以前のWebPassインスタンスには、10g（10.1.4.0.1）のアイデンティティ・サーバー（またはポリシー・マネージャ）との互換性がありません。以前のアイデンティティ・サーバーをすべてアップグレードしたら、以前のWebPassインスタンスもすべてアップグレードする必要があります。このルールの例外は、この目的で追加するマスター・アイデンティティ・システムを使用してスキーマとデータをアップグレードする場合です。インプレース・アップグレードの詳細は、第II部を参照してください。
アップグレード後の環境に10g（10.1.4.0.1）のWebPassインスタンスをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebPassインスタンスには、以前のアイデンティティ・サーバー（またはポリシー・マネージャ）との互換性はありません。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされたアクセス・サーバーと共存できます。アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のアクセス・サーバーとの互換性はありません。詳細は、「WebGate」を参照してください。
アップグレード後の環境に10g（10.1.4.0.1）のアクセス・サーバーを追加する場合は、以前のWebGateと下位互換にするためのフラグを設定する必要があります。詳細は、「アクセス・サーバーの下位互換性」を参照してください。
次のディレクトリ内の機密に関わるデータをブラウザから直接表示できないようにするために、セキュリティに関連した変更が実施されました。
/access（またはidentity）/oblix/config/*.*にある構成ファイル
/access（またはidentity）/oblix/log/*.*ディレクトリにあるログ・ファイル
importantnotes.txtファイルは削除され、このファイルに記述されていた情報は、『Oracle Access Managerインストレーション・ガイド』の付録に記載されています。
Webサーバー構成ファイルのグローバリゼーションとUTF-8サポートについては変更されていません。
リリース10.1.4パッチ・セット1（10.1.4.2.0）の拡張機能を使用すると、コア・ダンプが発生した場合に、Oracle Access Managerでログ・ファイルにスタック・トレースを書き込むことができます。この機能を有効にするには、ロギングのレベルを最小にします。スタック・トレース情報を含むログ・ファイルは、問題に関するレポートとともにOracleに送信できます。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のトラブルシューティングに関する付録を参照してください。
この項では、XMLメッセージ・カタログ・ファイル、XMLパラメータ・カタログ・ファイルおよびXSLスタイルシート・ファイルに表示されるエンコーディング・スキームとこれらのファイルをカスタマイズする場合に指定する内容について説明します。「複数の言語の取得と使用」も参照してください。
ISO-8859-1エンコーディング: 英語のみのテキストの場合、ISO-8859-1エンコーディングとUTF-8エンコーディング間に違いはありません。このため、英語のXMLメッセージとXSLファイル用のエンコーディング・スキームとしてISO-8859-1がそのまま使用されます。次の例は、英語ディレクトリ（\lang\en-us）にあるXMLメッセージ・ファイル（auditmsg.xml）を示しています。
\IdentityServer_install_dir\identity\oblix\lang\en-us\auditmsg.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <MessageCtlg xmlns="http://www.oblix.com" CtlgName="auditmsg">
...
|
注意: 以前の製品リリースに含まれているXMLファイルでは引き続きencoding="ISO-8859-1"を指定できますが、XMLに変換された以前のLSTファイルではUTF-8エンコーディングが使用されます。「メッセージ・ファイルとパラメータ・ファイル」も参照してください。 |
次の例では、XSLスタイルシート・ラッパー（style.xsl）を示します。これは、いずれの言語ディレクトリ（英語: \lang\en-us、ドイツ語: \lang\de-de、日本語: \lang\ja-jpなど）を使用する場合でも使用されます。これらのファイル間の唯一の違いは、この例の最終行にあるlangtag項目での言語指定です（言語によって異なります）。
\IdentityServer_install_dir\identity\oblix\lang\langtag\style0\style.xsl
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <!-- Copyright (c) 1996-2005, Oracle All Rights Reserved. -->
- <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:oblix="http://www.oblix.com/">
<xsl:variable name="styleName">style0/</xsl:variable>
<xsl:variable name="localeName">langtag</xsl:variable>
...
UTF-8エンコーディング: 英語以外の言語のために、XMLメッセージ・ファイルではエンコーディングがUTF-8に設定されています。ISO-8859-1エンコーディングでは、すべての言語のすべての文字を表現できません。次に示すサンプル・ファイルはドイツ語ディレクトリ\IdentityServer_install_dir\identity\oblix\lang\de-de\auditmsg.xmlからの引用です。
<?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns:oblix="http://www.oblix.com" CtlgName=""> <Message MsgTag="ExAuditInitHandler">ExçêpäìÖÑExç ÖççürrêdÖçç ìÑì ähêä AüdìäAü MÖdülêMÖ ìÑìäìàlìzàäìÖÑìÑìäì. ThêT êxçêpäìÖÑêxç säàçksä ìsì: %1.</Message> ...
このエンコーディング・スキームは世界共通であるため、英語ディレクトリ（\lang\en-us）内でも一部のファイルでUTF-8エンコーディングが指定されています。たとえば、英語版のdata_types.xmlを次に示します。
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns="http://www.oblix.com" CtlgName="data_types.xml"> <Message MsgTag="OB_BIN">Binary</Message> <Message MsgTag="OB_DN">Distinguished Name</Message> <Message MsgTag="OB_TEL">Telephone</Message> ...
他の言語ディレクトリでのこのファイルの例として、ドイツ語版を示します。
<?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns:oblix="http://www.oblix.com" CtlgName=""> <Message MsgTag="OB_BIN">BìÑàryBì</Message> <Message MsgTag="OB_DN">DìsäìÑgüìshêdDìsä NàmêN</Message> <Message MsgTag="OB_TEL">TêlêphÖÑêTêl</Message> ...
|
注意: XMLファイルとXSLファイルをカスタマイズする場合は、encoding="ISO-8859-1"またはencoding="UTF-8"のどちらかを選択できます。いずれの場合でも、Oracle Access ManagerのXMLパーサーは正確な処理を行うためにファイルからエンコーディング・タグを読み取ります。 |
XSLスタイルシートとラッパー・ファイルの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。「XSLProcessorパラメータ」も参照してください。
この項では、10g（10.1.4.0.1）へのアップグレード後における、以前のアイデンティティ・システムの動作との変更点と予期される動作について説明します。内容は次のとおりです。
以前のリリースでは、チャレンジ・フレーズ属性とレスポンス属性を「ユーザー・プロファイル」ページの異なるパネルに配置できました。ただし、10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性を同じパネルにのみ配置できます。10g（10.1.4.0.1）では、チャレンジ・フレーズとレスポンスがパネル上で連続して構成されなくても、隣接して表示されます。
パネルにチャレンジ属性のみが含まれる場合、チャレンジ属性は「ユーザー・プロファイル」ページにレスポンスなしで表示されます。パネルがレスポンスのみ（チャレンジ属性がない）を含む場合は、レスポンスは「ユーザー・プロファイル」ページにはまったく表示されません。単一パネルへのこれらの隣接表示の詳細は、「単一パネルへのチャレンジ属性とレスポンス属性の配置」を参照してください。
また、この機能のためにIdentityXMLも変更されました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
10g（10.1.4.0.1）以降、アイデンティティ・サーバーはUTF-8エンコーディングを使用し、プラグイン・データはUTF-8データを含みます。以前のプラグインは、Latin-1エンコーディングでデータを送受信します。
以前のアイデンティティ・サーバーをアップグレードすると、以前のカスタム・プラグインとの下位互換性が自動的に備わります。この場合、以前のプラグインとの下位互換性を確保するため、新規フラグ（encoding）がoblixpppcatalog.lstファイルに自動的に追加されます。下位互換性のあるアイデンティティ・サーバーは、以前のプラグインにLatin-1エンコーディングでのデータの送信を継続します。
詳細は、次項「アイデンティティ・システムのイベント・プラグイン」の下位互換性についての説明を参照してください。「キャッシュのフラッシュ」も参照してください。アップグレードしたアイデンティティ・サーバーには、以前のWebPassインスタンスとの下位互換性はありません。
アイデンティティ・イベント・プラグインAPIはアイデンティティ・サーバーと一緒にインストールされる標準コンポーネントです。これを使用すると、カスタム・ビジネス・ロジックを実行するための独自の小さいアプリケーション（アクションと呼ばれます）を作成し、外部システムと統合することで、アイデンティティ・システムの機能を拡張できます。アクションは、アイデンティティ・システムによって特定のデータを利用できるようにされた後、データを変更したり、イベントの結果に影響を与えたりすることが許可されます。
10g（10.1.4.0.1）以降、アイデンティティ・サーバーはUTF-8エンコーディングを使用し、プラグイン・データはUTF-8データを含みます。また、SolarisおよびLinuxでは、「プラグイン」で説明されているように、GCC v3.3.2 C++コンパイラを使用してリリース7より前のプラグインを再コンパイルする必要があります。
以前のリリースでは、アイデンティティ・イベント・プラグインにデータを送信する際、Latin-1エンコーディングを使用していました。アップグレード後の環境でも、以前のリリースのアイデンティティ・イベント・プラグインでは現在もLatin-1エンコーディングが使用されます。場合によっては、UTF-8エンコーディングを使用するように以前のカスタム・プラグインを設計変更する必要があります。ただし、10g（10.1.4.0.1）アイデンティティ・サーバーと以前のプラグインとの通信が必要になる場合もあります。
以前のアイデンティティ・サーバーを10g（10.1.4.0.1）にアップグレードすると、以前のアイデンティティ・イベント・プラグインとの下位互換性が自動的に備わります。アップグレード中に、新しいフラグ（encoding）がoblixpppcatalog.lstファイルに追加されます。下位互換性のあるアイデンティティ・サーバーは、引き続きLatin-1エンコーディングで以前のプラグインにデータを送信し、以前のプラグインはLatin-1エンコーディングでデータを受送信します。プラグイン側のデータ・エンコーディングには変更はありません。
アップグレードされた環境に10g（10.1.4.0.1）のアイデンティティ・サーバーを新しく追加する場合は、アイデンティティ・サーバーのoblixpppcatalog.lstのencodingフラグを手動で設定し、以前のプラグインおよびインタフェースとの通信を有効にする必要があります。
このカタログの格納場所はIdentityServer_install_dir\oblix\apps\common\bin\oblixpppcatalog.lstです。このカタログには、イベント・ハンドラ・エントリおよびこれらのエントリと各種イベントとのマッピングが含まれています。これらのエントリの形式は次のとおりです。
actionName;exectype;netpointparam1,...;path;execparam,...;apiVersion;encoding;
次のサンプル行は、エンコーディング・フラグを使用してLatin-1プラグインとの下位互換性を実現する方法を示しています。
userservcenter_view_post;lib;;..\..\..\unsupported\ppp\ppp_dll
\ppp_dll.dll;PostProcessingTest;Latin-1;
|
注意: カタログ・ファイルにおいて、encodingフラグは、イベント・ハンドラで使用するイベントAPIのバージョンを設定するapiVersionフラグと似ています。カタログ・ファイル内で説明されているように、apiVersionはイベントAPIに対する下位互換性の設定に使用できます。たとえば、apiVersionをpreNP60に設定すると、Oracle Access Manager v60より前のバージョン用のAPIの構文とLatin-1エンコーディングがデフォルトで使用されます。この場合は、encodingフラグの設定が不要になります。 |
アイデンティティ・イベント・プラグインAPIの一般的な用途には、パスワード検証、統合およびプロビジョニングがあります。たとえば、アイデンティティ・イベントAPIを使用するパスワード管理イベント用にイベント・ハンドラを作成し、Oracle Access Managerのパスワード・ポリシー機能に追加できます。また、各登録ワークフロー・インスタンスの有効化ステップに対するイベント・ハンドラを作成することもできます。このイベント・ハンドラの作成目的は、RDBMSベンダーのAPIを使用してリモート・データベースを更新したり、要求されている形式で一意の文字列を生成し、アイデンティティ・システムに渡してuid属性値として使用することです。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アクションは、開発者が作成し、Oracle Access Manager管理者が特定のイベントに対するレスポンスとして実行されるよう構成した外部ロジック（イベント・ハンドラとも呼ばれます）の1つの単位です。アクションでは、外部コンポーネントにアクセスせずにタスクを実行したり、利用可能な任意のメカニズムを使用してWebサービス、RDBMSサービス、ERPアプリケーションなどサード・パーティのアプリケーションとリソースにアクセスできます。アクションとイベントを関連付けるには、oblixpppcatalog.lstファイルを使用します。アイデンティティ・サーバーは起動時に、アクションを伴うイベントが記載されたカタログを読み取ります。イベントが発生すると、サーバーはそのイベントに関連付けられているアクションを実行します。
アイデンティティ・イベント・プラグインAPIには次の3種類のアクションがあります。
LIBアクション: アイデンティティ・サーバーがコールする共有ライブラリ（Windowsシステムの場合はDLL）内の関数です。アクションは、動的にロードされると、アイデンティティ・サーバーと同じプロセス空間で実行され、サーバーに格納されているデータ・オブジェクトにAPI関数を介して直接アクセスします。アイデンティティ・サーバーからライブラリに、プラグイン・データを含むC++オブジェクトが送信されます。
MANAGEDLIBアクション: Windowsシステムに専用の機能です。Microsoft Intermediate Language（MIL）コンパイラが用意されている.NET言語で作成されます。MIL命令はネイティブのマシン命令にコンパイルされて動的メモリーに格納されてから、Microsoft .NET Common Language Runtime（CLR）で実行されます。MANAGEDLIBアクションはLIBアクションと類似していますが、管理コードの利点も持ち合せています。アイデンティティ・サーバーからライブラリに、プラグイン・データを含むC++オブジェクトが送信されます。
EXECアクション: 固有のプロセス空間で実行されるスタンドアロン実行可能プログラムです。アイデンティティ・サーバーとの通信は、入力では起動パラメータとXMLストリームに限定され、出力ではXMLストリームと終了ステータス・コードに限定されます。また、アクションでは、LDAPアイデンティティ・イベント・プラグインなど他のAPIも使用できます。
イベントとは、アイデンティティ・システム内の状態の変更です。イベントの例には、リクエストが受け取られてアプリケーション（ユーザー・マネージャの参照プログラムなど）にまもなく引き渡される場合、アプリケーション（グループ・マネージャの検索プログラムなど）から結果が生成された場合、ユーザーがパスワード・リセットの試行中にチャレンジ・レスポンスを入力した場合、アプリケーション（組織マネージャなど）のプロファイル・ページの属性が変更された場合、または企業ITグループによる承認の待ち状態にあったワークフロー・チケットが承認された場合があります。
最も頻繁に使用されるイベント・タイプは、ペアで生成される前処理イベントと後処理イベントです。それぞれのアプリケーション（ユーザー・マネージャ、グループ・マネージャまたは組織マネージャ）には、アプリケーション内の各ページのHTMLを生成するプログラム（参照、検索など）がいくつか含まれています。各プログラムによって前述のイベント・ペアが認識されます。前処理イベントは、プログラムがページの作成を開始する前に生成され、リクエストがプログラムに到達する前にイベント・ハンドラによって処理されるようにします。後処理イベントは、プログラムがページを作成してからHTMLページでユーザーに応答するまでの間に生成されます。また、後処理イベントは、リクエストの処理結果をイベント・ハンドラが処理できるようにします。
ブラウザを介さずにアプリケーションとやり取りするためのプログラムを作成することもできます。IdentityXMLは、ユーザーがブラウザからアイデンティティ・システム・アプリケーションにアクセスする際に実行できるアクションを実行するためのプログラム・インタフェースです。IdentityXMLを使用すると、単純なアクションとマルチステップのワークフローを処理して、ユーザー、グループおよび組織のオブジェクト・プロファイルを変更できます。また、外部アプリケーションは、IdentityXMLを使用してアイデンティティ・システムの機能にアクセスできるようになります。
リリース6.5では、IdentityXMLリクエストの構文が一部変更されました。以前の構文も問題なく動作します。新規構文については、『Oracle Access Manager開発者ガイド』を参照してください。
10g（10.1.4.0.1）では、XMLページ、SOAP/IdentityXMLリクエスト、および実行可能ファイルに送信されるアイデンティティ・イベント・プラグイン・データに対しては、UTF-8エンコーディングが使用されます。以前のリリースでは、ISO-8859-1エンコーディング（別称Latin-1）が使用されていました。
下位互換性を実現するために、10g（10.1.4.0.1）はIdentityXMLリクエストに対してISO-8859-1とUTF-8の両方のエンコーディングをサポートしています。ディスクにXMLドキュメントを書き込む場合、ISO-8859-1とUTF-8の両方のエンコーディングがサポートされます。IdentityXMLレスポンスは、リクエストと同じエンコーディング形式で発行されます。したがって、リクエストでLatin-1エンコーディング（encoding="ISO-8859-1"）が使用される場合はレスポンスでもLatin-1エンコーディングが使用され、リクエストでUTF-8エンコーディングが使用される場合はレスポンスでもUTF-8エンコーディングが使用されます。
|
注意: 新しい10g（10.1.4.0.1）インストールではencoding="UTF-8"を使用することをお薦めします。アップグレードした環境では、下位互換性を確保するためにencoding="ISO-8859-1"を使用することをお薦めします。 |
IdentityXMLリクエストでencoding="ISO-8859-1"が使用され、そのレスポンスにLatin-1キャラクタ・セット以外の文字が使用される場合、そのような文字を含むレスポンスは文字化けします。たとえば、あるリクエストでencoding="ISO-8859-1"が使用され、そのレスポンスに日本語またはアラビア語の文字が含まれる場合、これらの文字はレスポンス内で文字化けします。
また、チャレンジ・フレーズとレスポンス・フレーズの変更に対応するための変更が、10g（10.1.4.0.1）でIdentityXMLに加えられました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アプレットは、Webページとともにユーザーに送信される小さなプログラムです。Javaアプレットは対話型のアニメーションや即時計算の他、ユーザー・リクエストをサーバーに返送する必要のない単純なタスクも実行します。
以前のリリースでは、製品にインストールおよび構成されている言語が一覧表示されるドロップダウン・リストがアイデンティティ・システム・コンソールにありました。ユーザーがこのリストで言語を変更した場合は、アプレットと他のページが、選択された言語で表示されました。たとえば、英語ロケールで作業中のユーザーがヨーロッパ言語で表示されたアプレットを使用するには、単にドロップダウン・リストから該当する言語を選択するのみで済みました。ただし、このモデルはヨーロッパ言語にしか十分に機能しませんでした。
このモデルに日本語などのマルチバイト言語が導入されたため、マルチバイト・キャラクタ・セットが正しく表示されるようになりました。また、言語リストがアイデンティティ・システム・コンソールから取り除かれました。英語ロケールを使用するユーザーは、マルチバイト言語でアプレットを表示することはできません。アプレットをマルチバイト言語で使用するには、ユーザーのコンピュータのロケールを同じ言語に設定する必要があります。
|
注意: JDK1.1.7のJavaアプレットについては既知の制限があります。Oracle Access Manager 10g（10.1.4.0.1）では、非ASCIIデータを使用するアプレットは、ネイティブにエンコードされたオペレーティング・システムを実行するコンピュータでのみ適切に表示できます。ブラウザのエンコーディングを設定しても機能しません。 |
ユーザーの作業に影響を及ぼすJavaScriptの変更はありません。
リリース10.1.4パッチ・セット1（10.1.4.2.0）では、静的グループが大きすぎる場合（メンバーが10,000を超える場合など）、globalparams.xmlのLargeStaticGroupsパラメータを使用して、そのグループのデフォルトの評価メソッドを変更できます。このパラメータの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
この機能を使用する場合、アイデンティティ・システムの構成に適切な変更を加えて、変更したグループのサブグループが意図したとおりに検索および評価されるかどうかを確認する必要があります。詳細は、『Oracle Access Managerデプロイメント・ガイド』のパフォーマンスのチューニングに関する章を参照してください。
アイデンティティ・サーバーは各種機能（属性変更、ワークフロー、コンテナ制限など）に関するメール通知を送信します。メールに使用できる書式には、テキストのみ、リッチHTML、およびMHTML（HTMLなどのドキュメントの集合をMIMEでカプセル化したもの）があります。メールの送信では、非同期モードと同期モードの両方がサポートされます。アイデンティティ・サーバーはSMTPプロトコルを使用してメール・サーバーと直接通信します。
以前のリリースでは、エンコーディング対象の文字の大部分がASCIIキャラクタ・セットに含まれている場合の推奨標準となるISO-8859-1（Latin-1）Qエンコーディングが、ヘッダー・メッセージに使用されていました。10g（10.1.4.0.1）では、UTF-8（Base64）Bエンコーディングが使用されます。
非MHTMLメール・メッセージのMIMEヘッダーは次のとおりに設定されます。
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
Content-Transfer-Encoding: 8bit
以前のリリースでは、アイデンティティ・システム・アプリケーション（ユーザー・マネージャ、グループ・マネージャおよび組織マネージャ）で検索を実行するときには、3文字以上入力する必要がありました。10g（10.1.4.0.1）では、必要な最小文字数はありません。デフォルトでは、文字を入力しなくてもかまいません。以前のリリースと同様に、oblixadminparams.xmlのsearchStringMinimumLengthパラメータを設定することで、ユーザーが検索フィールドに入力する必要のある最低文字数を制御して、ユーザーが検索条件を絞り込むのを助けることができます。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ワークフローを使用して、アイデンティティ・システムのビジネス・プロセスをモデル化することができます。以前のリリースでは、ワークフローを使用して、証明書の発行、取消し、更新を行うことができました。しかし、この機能はサポートされなくなっています。
Oracle Identityプロトコル（以前のNetPointアイデンティティ・プロトコルまたはCOREidアイデンティティ・プロトコル）は、アイデンティティ・サーバーと関連するWebPassインスタンスの間の通信を容易にします。グローバリゼーションに関してプロトコルは変更されていません。「Oracle Accessプロトコル（OAP）への更新」も参照してください。
アイデンティティ・システムを使用して、パスワードを制限するためのポリシーを定義できます。このポリシーは次の項目からなり、実行時に強制されます。
パスワードの最小長
大文字の最小数
小文字の最小数
非英数字文字の最小数
その他
10g（10.1.4.0.1）の場合、パスワード・ポリシーでは国際化された文字がサポートされます。
以前のリリースでは、ポリシーの制約を強制する場合、パスワード・ポリシーはLatin1文字でのみ動作しました。パスワード管理ランタイムには変更はありません。
Webページのアドレスは一般にUniform Resource Locator（URL）と呼ばれており、Uniform Resource Identifier（URI）のサブセットになります。10g（10.1.4.0.1）では、URI問合せ文字列のデータのエンコーディングがLatin-1（以前のリリース）からUTF-8に変更されました。
10g（10.1.4.0.1）の新規インストールでは、この変更は透過的に行われます。ただし、インストール内にある以前のPortal Insertsを10g（10.1.4.0.1）にアップグレードした場合は、変更する必要があります。環境を10g（10.1.4.0.1）にアップグレードした後で、以前のPortal Insertsにおける問合せ文字列のエンコーディングをLatin-1からUTF-8に変更する必要があります。
HTTP標準には、ブラウザで問合せ文字列のエンコーディングを指定するメカニズムが用意されていません。Oracle Access Manager 10g（10.1.4.0.1）では、問合せ文字列のエンコーディングを検出できないため、エンコーディングがUTF-8であるとみなします。10g（10.1.4.0.1）のアイデンティティ・サーバーは、以前のPortal InsertsのLatin-1データを処理できません。
|
注意: 環境を10g（10.1.4.0.1）にアップグレードした後で、以前のPortal Insertsにおける問合せ文字列のエンコーディングをLatin-1からUTF-8に変更する必要があります。 |
リリース6.5より前は、PresentationXMLライブラリは2つのディレクトリで提供され、ファイルの使用方法に応じて分散されていました。たとえば、デフォルトのOracle Access Managerクラシック・スタイルを定義するスタイルシートは、ファイル・システムのディレクトリ\IdentityServer_install_dir\identity\oblix\apps\AppNameのフラット・ファイルで保持されていました。リリース6.5に始まり10g（10.1.4.0.1）でも、PresentationXMLライブラリは別のディレクトリに格納されます。
詳細は、「カスタム・アイテムとそのアップグレードの概要」を参照してください。
ユーザー・マネージャ、グループ・マネージャ、および組織マネージャでは、検索結果の表で列ヘッダー（「フルネーム」など）をクリックすると、ロケールに基づく大/小文字を区別しない方法を使用して、検索結果がソートされます。
Oracle Access Managerでは、IdentityXMLを使用してWebサービスを実装するサンプル・コードが提供されるようになりました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
リリース10.1.4パッチ・セット1（10.1.4.2.0）にはIdentityXMLを使用する場合の拡張機能があります。リリース10.1.4パッチ・セット1（10.1.4.2.0）では、globalparams.xmlファイルのXSLProcessorパラメータは、ページを生成する際に使用するプロセッサを表します。正式にサポートされる値はdefaultのみです。これは、XDKプロセッサを使用する必要があることを示します。値XALANまたはDGXTはテスト目的で使用できます。
詳細は、『Oracle Access Managerカスタマイズ・ガイド』の構成パラメータに関する付録を参照してください。「XMLカタログとXSLスタイルシートのエンコーディング」も参照してください。
この項目では、アクセス・システムの以前の動作について説明します。10g（10.1.4.0.1）へのアップグレード後に予期される動作を中心に説明します。内容は次のとおりです。
10g（10.1.4.0.1）よりも前のリリースでは、Cookieの暗号化および復号化はWebGate/アクセス・ゲートによって処理されました。ただし、現在はCookieの暗号化および復号化はアクセス・サーバーによって処理されます。このため、以前のアクセス・サーバーには、10g（10.1.4.0.1）のWebGateとの互換性はありません。「暗号化スキーム」も参照してください。
Oracle Access Manager 10g（10.1.4.0.1）以降、アクセス・サーバーではUTF-8エンコーディングが使用され、プラグイン・データにUTF-8データが含まれるようになります。以前のプラグインは、Latin-1エンコーディングでデータを送受信します。
以前のアクセス・サーバーをアップグレードすると、以前のカスタム・プラグインおよび以前のWebGateとの下位互換性が自動的に備わります。この場合、新規パラメータ"IsBackwardCompatible" Value="true"がアクセス・サーバーのglobalparams.xmlファイルに自動的に設定されます。これによって下位互換性が提供され、アクセス・サーバーは以前のカスタム認証および認可プラグインへのLatin-1エンコーディングでのデータの送信（および受信）を継続できます（以前のカスタム・プラグインは、Latin-1エンコーディングでデータを設定します）。また、アクセス・サーバーは、Cookieの暗号化および復号化を継続する、以前のWebGateおよびカスタム・アクセス・ゲートとの下位互換性を維持します。
|
注意: アップグレードした環境に新規の10g（10.1.4.0.1）のアクセス・サーバーを追加する場合は、 |
詳細は、「カスタム認証および認可プラグインとそのインタフェース」および「Oracle Accessプロトコル（OAP）への更新」を参照してください。
Access Manager SDK（以前のアクセス・サーバーSDK）は、サポートされている各開発プラットフォーム用に単純なカスタム・アクセス・ゲート・サーブレットやアプリケーションを作成するために必要となるドキュメント、リソースおよびサンプル・コードをすべて提供するオプション・コンポーネントです。アクセス・ゲートは、アクセス・サーバー・クライアント（エージェント）であり、Oracle Access Managerによって保護されたLDAPドメイン内にあるリソースへのアクセスに対するユーザー・リクエストを処理します。ユーザー・リクエストを処理するためのコードは、プラグインに埋め込むことも、スタンドアロンのアプリケーションとして作成することもできます。
Access Manager SDKをインストールしたら、Access Manager API（以前のアクセス・サーバーAPI）を使用して、サポートされている4種類の開発言語（Java、C、C++およびC#（.NET））のうちのいずれかでカスタム・アクセス・ゲート・コードを記述できます。4種類の実装は、それぞれプラットフォーム固有の機能を利用してAPIを実装していますが、機能的には同じです。
カスタム・アクセス・ゲート・コードを記述するための開発言語インタフェースとして4種類の実装のうちのいずれかを選択できますが、『Oracle Access Manager開発者ガイド』で説明されているように、記述したコードは、このAPIを構成するC++バイナリとやり取りします。
10g（10.1.4.0.1）のCおよびC++ Access Manager APIを使用してカスタム・アクセス・ゲートを開発すると、データが自動的にUTF-8エンコーディングで送受信されます。以前のリリースでは、Latin-1エンコーディングでデータが送受信されていました。
Access Manager APIのC#（.NET）マネージド コード実装について、10g（10.1.4.0.1）では外部的な変更は行われていません。このC# .NET実装の内部では、UTF-16エンコーディング（以前のOracle Access ManagerリリースではLatin-1に変換されていました）が使用されています。10g（10.1.4.0.1）のアクセス・サーバーとC#アクセス・ゲートは、UTF-8エンコーディングを自動的に使用します。
Access Manager APIのJavaインタフェースおよびJava実装について、10g（10.1.4.0.1）では外部的な変更は行われていません。JNIのコールは、UTF-16でエンコードされたJava文字列オブジェクトを使用します。以前のOracle Access Managerリリースでは、このデータがLatin-1に変換されていました。10g（10.1.4.0.1）のアクセス・サーバーとアクセス・ゲートでは、自動的にUTF-8エンコーディングが使用されます。
|
注意: 10g（10.1.4.0.1）のAccess Manager SDKおよび10g（10.1.4.0.1）のカスタム・アクセス・ゲートは、以前のアクセス・サーバー、Access Manager SDK、およびアクセス・ゲートとの間に下位互換性がありません。ただし、以前のアクセス・ゲートは、下位互換性を有効にした10g（10.1.4.0.1）のアクセス・サーバーとともに使用できます。「Oracle Accessプロトコル（OAP）への更新」も参照してください。 |
カスタム・アクセス・ゲート（およびWebGate）では、Cookieの暗号化と復号化が行われなくなりました。このため、これらのコンポーネントには、共有シークレット・キーは不要になりました。
10g（10.1.4.0.1）では、認証スキームを変更するとき、先に認証スキームを無効にする必要はなくなりました。また、10g（10.1.4.0.1）では、1回のセッションではなく一定の期間ユーザーがログインできるよう、認証スキームを構成できます。
リリース6.1.1では、認可ルールが特定のアクセス・ポリシーに関連付けられていました。リリース6.5以降、認可ルールは（「認可ルール」という名前の）別のタブにグループ化されるようになりました。
アップグレード中に、認可ルールの名前が「認可ルール」タブに移動されます。また、認可ルールの名前は、その認可ルールが属しているポリシーの名前の後にその認可ルールの名前を付加したものになります（PolicyName_AuthorizationRuleName）。アップグレード後の認可ルールの識別および処理の詳細は、「リリース6.1.1の認可ルールとアクセス・ポリシーの関連付け」を参照してください。
また、リリース7.xでは、未確定という認可の状態が新しく導入されました（認可の成功および失敗とは別の状態）。以前のインストールに認可失敗のリダイレクトが含まれていた場合は、明確な拒否ルールを指定し、認可ルールの「一般」タブにある「許可を優先」を「はい」に変更する手順をアップグレード後に実行する必要があります。詳細は、「6.1.1からのアップグレード後に認可失敗のリダイレクトが正しく行われるようにするための作業」を参照してください。
10g（10.1.4.0.1）にあるいくつかの変更点、下位互換性、考慮事項について次に説明します。
認証とは、保護されたリソースにアクセスしようとしているユーザーが本人の主張するとおりの人物であるかどうかを判別するプロセスのことです。認可とは、認証されたユーザーが保護されたリソースへのアクセス権限を持っているかどうかを判定するプロセスのことです。アクセス・サーバーは認証管理と認可管理の両方を使用して、保護するリソースへのアクセスを制限し、認証および認可プラグインと対話するように定義されたインタフェースを提供します。
標準の認証および認可プラグインを使用することも、Oracle Access Managerの認証プラグインAPIおよび認可プラグインAPIを使用して独自のカスタム・プラグインを作成することもできます。各カスタム・プラグインは、適切なインタフェース（認証または認可）を実装します。プラグインに応じて、アクセス・サーバーとプラグインの間で関連情報を受け渡しするためのインタフェースが有効になります。このインタフェースのメソッドによってデータが解析されます。
10g（10.1.4.0.1）より前のCに対する認証プラグインAPIおよび認可プラグインAPIは、アクセス・サーバーとカスタム・プラグインの間で交換されるデータに、Latin-1エンコーディングを使用していました。ただし、10g（10.1.4.0.1）では、Cに対する認証プラグインAPIおよび認可プラグインAPIは、プラグインの処理に対してUTF-8エンコーディングを使用します。
.NET（マネージド コード）プラグインに対しては変更はありません。以前のOracle Access Managerリリースと同じAPIインタフェースが引き続き使用されます。
場合によっては、UTF-8エンコーディングを使用するように以前のカスタム・プラグインを設計変更する必要があります。とはいえ、10g（10.1.4.0.1）のアクセス・サーバーと以前のプラグインとの通信が必要になる場合もあります。
以前のリリースから10g（10.1.4.0.1）にアップグレードしたアクセス・サーバーには、自動的に下位互換性が備わります。ただし、アップグレード環境に10g（10.1.4.0.1）のアクセス・サーバーを追加する場合は、下位互換性を手動で設定する必要があります。詳細は、「アクセス・サーバーの下位互換性」を参照してください。
この項では、Oracle Access Managerの認証および認可プラグインについて概説します。
認証は認証ルールで管理されます。認証ルールでは、認証スキームが使用されます。認証スキームは、1つ以上のプラグインを使用してユーザーが示す資格証明をテストします。標準の認証プラグインがアクセス・サーバー・インストールには付属していますが、独自のカスタム・プラグインを認証プラグインAPIで作成することもできます。
認可は、デフォルトのルール・セットの一部である、ドメインのリソースを保護する方法を指定している認可条件式を含むポリシー・ドメインによって管理されます。認可条件式は、複数の認可ルールを組み合せて作成します。ルールを作成する際には、認可スキームを組み入れます。アクセス・システムによって提供される認可スキームを使用することも、認可プラグインAPIを使用して作成されるカスタム・プラグインを含む1つ以上のカスタム認可スキームを構成することもできます。
リリース6.5では、アクセス・サーバーおよびポリシー・マネージャに対するディレクトリ・サーバー・プロファイルのサポートが導入されました。7.xより前の任意のリリースからのポリシー・マネージャのアップグレードにおいて、新しいディレクトリ・サーバー・プロファイルが自動的に追加されます。ただし、「最初の接続数」と「最大接続数」の値は、ポリシー・マネージャのアップグレードでは保持されません。
アップグレードを行った後、新しいディレクトリ・サーバー・プロファイルが正しく作成されたこと、およびアクセス・システムのディレクトリ・サーバー・プロファイルのロード・バランシングとフェイルオーバーの設定が意図したとおりに構成されていることを、確認して検証することをお薦めします。
詳細は、「ディレクトリ・プロファイルとデータベース・インスタンス・プロファイル」を参照してください。
10g（10.1.4.0.1）のWebGateは、UTF-8エンコーディングでのみ入力データを受け付けます。結果として、10g（10.1.4.0.1）では、フォーム・ベース認証で非ASCIIのログイン資格証明（ユーザー名/パスワード）がサポートされます。フォーム・ベース認証を10g（10.1.4.0.1）WebGateで使用するには、ログイン・フォームのキャラクタ・セット・エンコーディングをUTF-8に設定する必要があります。
アップグレード後にログイン・フォームのエンコーディングをUTF-8に設定するには、「フォーム・ベース認証のアップグレード」を参照してください。
|
注意: Basic認証は、非ASCIIのログイン資格証明では失敗します。非ASCIIのログイン資格証明には、フォーム・ベース認証を使用してください。Basic認証は、ASCIIのログイン資格証明に使用します。 |
WebGateで保護されるコンピュータ上のリソースの偽装を構成する他に、ネットワーク上の他のリソースにも偽装を拡張できます。これは、クライアントへの委任偽装レベルの割当てと呼ばれるもので、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能です。
詳細は、『Oracle Access Manager統合ガイド』のWindowsの偽装に関する章を参照してください。
以前のリリースでは、このパラメータのデフォルト値は100000に設定されていました。ただし、Oracle Access Manager 10g（10.1.4.0.1）では、このデフォルト値が10000に変更されました。このパラメータを確認するには、アクセス・システム・コンソールで、「アクセス・システム構成」タブの「アクセス・サーバー構成」機能を参照してください。「アクセス・サーバーの詳細」ページを確認します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
Oracle Accessプロトコル（以前のNetPointまたはCOREid Accessプロトコル）を使用すると、ユーザーの認証と認可の間に、アクセス・システム・コンポーネント間での通信が可能になります。WebGateとアクセス・ゲートには、認証および認可に必要なユーザー情報（ログイン名、パスワード、ヘッダーなど）が格納されます。データは、シリアライズされてアクセス・サーバーに送信された後で、デシリアライズされます。アクセス・サーバーにより、結果がAccess Clientに返送されます。
以前の製品リリースでは、送受信されるデータにはLatin-1エンコーディングが使用されていました。10g（10.1.4.0.1）では、UTF-8エンコーディングが使用されます。10g（10.1.4.0.1）のアクセス・サーバーでグローバリゼーションと共有シークレット生成の両方を行えるように、更新されたOracle Accessプロトコルが付属するようになりました。
10g（10.1.4.0.1）の新規インストールでは、何もアクションを実行する必要はありません。この最新のOracle Accessプロトコルが、アクセス・サーバーと関連WebGate/アクセス・ゲート間や、アクセス・サーバーと標準/カスタムの新しい認証および認可プラグイン間のすべての通信に使用されます。
アップグレード環境では、アクセス・サーバーの下位互換性を実現するには、「アクセス・サーバーの下位互換性」の手順を実行する必要があります。
「Oracle Identityプロトコル（OIP）」も参照してください。
すべてのアイデンティティ・システム・コンポーネントをアップグレードした後、以前のポリシー・マネージャ（以前のAccess Managerコンポーネント）もすべてアップグレードする必要があります。
アクセス・システムでは、ポリシー・マネージャ・グラフィカル・ユーザー・インタフェース（GUI）に実装されている大部分の機能に対しては、プログラムによるアクセスも用意しています。なお、ポリシー・マネージャAPI（以前のアクセス管理API）を使用すると、ポリシー・ドメインとその内容を作成して管理したり、カスタム・アプリケーションによるアクセス・サーバーの認証、認可および監査の各サービスへのアクセスを可能にすることができます。以前のリリースと同様に、10g（10.1.4.0.1）ポリシー・マネージャAPIは、クラスに対するJava、CおよびC#（.NETマネージド コード）のバインドを提供します。
以前のリリースでは、ObAMMasterAuditRule_getEscapeCharacterにより監査エスケープ文字が返されました。
Oracle Access Manager 10g（10.1.4.0.1）では、次のようになりました。
C言語のAPIでは、ObAMMasterAuditRule_getEscapeCharacterが残っており、引き続き使用できます。ただし、監査のエスケープ文字はASCII文字でなければならず、それ以外の場合は戻り値が正しくありません。その場合は、新しいAPIを使用するようにCコードを変更する必要があります。
Javaクライアントでは、ObAMMasterAuditRule_getEscapeCharacterは正しく動作し、監査エスケープ文字がASCII文字ではない場合でも引き続き使用できます。
C言語のAPIでは、新しくObAMMasterAuditRule_getUTF8EscapeCharacterが追加され、UTF-8でエンコードされた監査エスケープ文字に対するポインタを返します。
このWebGate構成パラメータは今回のリリースから必須になったため、WebGateを追加するとき（アクセス・システム・コンソールで「アクセス・システム構成」、「新規Access Gateの追加」の順に選択）には必ず適切な値を構成する必要があります。この構成は、WebGateのインストール前に必ず行ってください。
「優先HTTPホスト」パラメータは、ユーザーが保護されたWebサーバーへのアクセスを試みるときに、すべてのHTTPリクエストでのホスト名の指定方法を定義します。HTTPリクエスト内のホスト名は、このフィールドに入力した値に変換されます（ユーザーがHTTPリクエストでホスト名を定義した方法に関係なく）。この保護対策により、ハッカーが悪質なHTTPリクエストを作成してWebGateを迂回できないようになります。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
以前のリリースでは、共有シークレットがディレクトリ・サーバーに格納され、Cookieの暗号化と復号化がWebGateおよびカスタム・アクセス・ゲートで行われていました。10g（10.1.4.0.1）では、共有シークレットは引き続きディレクトリ・サーバーに格納されますが、Cookieの暗号化と復号化がアクセス・サーバーで行われるようになりました。このため、WebGateとアクセス・ゲートには、共有シークレット・キーが不要になりました。
ユーザー・セッションの間に共有シークレットを変更した場合、ユーザーを再認証する必要はありません。Cookieが古い共有シークレットを使用して復号化されている場合、このCookieは、リフレッシュされると、新しい共有シークレットを使用して暗号化されます。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
アクセス・サーバーの詳細は、「アクセス・サーバーの下位互換性」を参照してください。WebGateの詳細は、「WebGate」を参照してください。「暗号化スキーム」も参照してください。
ObSSOCookieを設定した後で、認証アクションを実行させることができます。通常、認証アクションは、認証が処理された後で、ObSSOCookieが設定される前にトリガーされます。しかし、複雑な環境では、ユーザーがリソースを含むページにリダイレクトされる前に、ObSSOCookieを設定できます。この場合、これらのイベントがトリガーされるように認証スキームを構成できます。『Oracle Access Managerアクセス管理ガイド』も参照してください。
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされたアクセス・サーバーと共存できます。アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のアクセス・サーバーとの互換性はありません。
以前のリリースに含まれていたWebGateStatic.lstファイルは廃止されました。かわりに、10g（10.1.4.0.1）WebGateでは、『Oracle Access Managerアクセス管理ガイド』で説明されているように、「IPValidation」や「IPValidationException」などのパラメータを構成するためにアクセス・システム・コンソールを使用します。
10g（10.1.4.0.1）よりも前のリリースでは、Cookieの暗号化および復号化はWebGate/アクセス・ゲートによって処理されました。これに対して、10g（10.1.4.0.1）からは、Cookieの暗号化と復号化はアクセス・サーバーで処理されます。
10g（10.1.4.0.1）のWebGateとアクセス・ゲートが同じコード・ベースを共有するように、WebGateのコードが書きなおされました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
以前のWebGateは、10g（10.1.4.0.1）のアクセス・サーバーと共存できる場合でも、すべてアップグレードすることをお薦めします。複数のWebGateリリースが混在する環境では、以前のWebGateに対応する暗号化スキームを使用してください。次に例を示します。
リリース5.xと10g（10.1.4.0.1）のWebGateが同じシステムに共存する場合は、RC4を暗号化スキームとして使用します。
リリース6.xと10g（10.1.4.0.1）のWebGateが同じシステムに共存する場合は、RC6を暗号化スキームとして使用します。
リリース7.0と10g（10.1.4.0.1）のWebGateのみが同じシステムに共存する場合は、AES暗号化スキームを使用します。
前述のように、以前のWebGate/アクセス・ゲートが含まれるアップグレード後の環境に10g（10.1.4.0.1）のアクセス・サーバーをインストールした場合は、アクセス・サーバーに対して下位互換性を手動で構成する必要があります。詳細は、「アクセス・サーバーの下位互換性」を参照してください。リリース10.1.4パッチ・セット1（10.1.4.2.0）パッケージを使用して新しいインスタンスをインストールすることはできません。
Oracle Access Manager 10g（10.1.4.2.0）では、いくつかの主要機能に対する追加機能が提供されています。次の表は、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能な追加機能をまとめたものです。
表4-3 リリース10.1.4パッチ・セット1（10.1.4.2.0）の新機能
| 機能の説明 | 詳細 |
|---|---|
|
ドキュメント: デプロイの概要とバックアップおよびリカバリの計画 |
Oracle Access Managerの様々なデプロイ計画やシナリオを説明する新しい章が追加されています。詳細は、『Oracle Access Managerデプロイメント・ガイド』のデプロイのシナリオに関する章を参照してください。 Oracle Access Managerのインストールに関する様々なバックアップやリカバリの計画を概説する新しい章が追加されています。詳細は、『Oracle Access Managerデプロイメント・ガイド』のバックアップおよびリカバリの計画に関する章を参照してください。 |
|
停止時間ゼロのアップグレード・メソッド |
Oracle Access Managerユーザーに対してサービスを停止することなく、アップグレードを実行できるようになりました。停止時間ゼロのアップグレード・メソッドは、インプレース・アップグレードの代替方法として提供されます。 第VI部で、停止時間ゼロのアップグレードの実行方法を説明しています。 |
|
停止時間ゼロのメソッドの使用時にユーザー・データの自動移行を停止するアップグレード・パラメータ |
停止時間ゼロのアップグレード時に、globalparams.xmlファイルの新規パラメータ 「最初のログイン時のユーザー・データの移行」を参照してください。 |
|
SolarisプラットフォームからLinuxプラットフォームへの切替えを伴うアップグレード |
付録Bでは、10g（10.1.4.0.1）へのアップグレードと同時にプラットフォームをSolarisからLinuxに切り替える方法を説明します。停止時間ゼロのアップグレード・メソッドを使用する場合、このタスクは実行できません。 |
|
LDAPバインドのパスワードを更新する機能 |
Oracle Access Managerコンポーネントと通信するディレクトリ・サーバーのLDAPバインドのパスワードを定期的に更新する必要があります。たとえば、政府規制に準拠するようにLDAPバインドのパスワードを更新できます。 LDAPバインドのパスワードを更新する機能はこのリリースで追加されました。 詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 以前のリリースでは、LDAPバインドのパスワードを更新した後に設定を再実行する必要がありました。このリリースでは、設定の再実行は不要です。 |
|
クライアントへの委任偽装レベルの割当て |
WebGateで保護されるコンピュータ上のリソースの偽装を構成する他に、ネットワーク上の他のリソースにも偽装を拡張できます。これは、クライアントへの委任偽装レベルの割当てと呼ばれます。 詳細は、『Oracle Access Manager統合ガイド』のWindowsの偽装に関する章を参照してください。 |
|
IdentityXMLの新規構成パラメータ |
IdentityXMLを使用する場合、globalparams.xmlファイルの 詳細は、『Oracle Access Managerカスタマイズ・ガイド』の構成パラメータに関する付録を参照してください。 |
|
xslファイルの拡張機能 |
一部のxslファイルが拡張され、JavaScript関連の修正や大規模グループ関連の多くの修正がサポートされています。このようなxslファイルは、10.1.4.2.0パッチ・セットを適用すると使用できます。 詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用後に実行する手順については、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)を参照してください。 |
|
外部コンポーネントの各種コールによる消費時間のログの記録 |
外部コンポーネントの各種コールによる消費時間の詳細を示すログを生成できるようになりました。この情報を使用すると、特定のコンポーネントに対するリクエストが、予定よりも長い時間を要しているかを評価する際にさらに便利です。 詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
グループ・パフォーマンスの改善 |
大規模な静的グループ（メンバーが10,000を超えるグループなど）の場合、そのグループに関連する操作が原因でメモリーが急増する可能性があります。 このリリースでは、グループ・パフォーマンスが改善されています。ただし、それでも大規模な静的グループがパフォーマンスに影響を与えることが判明した場合、globalparams.xmlの 大規模なグループのパフォーマンスを改善するために実行できる複数のアクションが追加されています。 詳細は、『Oracle Access Managerデプロイメント・ガイド』のパフォーマンスのチューニングに関する章を参照してください。 |
|
Oracleの即時クライアント・バイナリ |
Oracleの即時クライアント・バイナリが、アイデンティティ・サーバーおよびアクセス・サーバーに付属しています。このため、データベースを監査する場合、バイナリをホストするコンピュータで10.1.0.5 ORACLE_HOMEが不要になりました。 |
|
NLSライブラリおよびデータ・ファイル |
環境変数がORACLE_HOMEまたはORA_NLS10に設定されている場合でも、あるいはサード・パーティのWebコンポーネントが、Oracle Access Managerで使用されるものとは異なるバージョンのNLSライブラリとデータ・ファイルを参照している場合でも、Oracle Access Managerコンポーネントはoracle_access_manager_component_install_dirからNLSデータ・ファイルを選択します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。 |
|
応答なしのサーバーに対してWebGateが実行する再試行回数の制限 |
WebGateとアクセス・サーバー間のタイムアウトしきい値は、WebGateがアクセス・サーバーに接続できないと判断して新しい接続でリクエストを試行するまでにWebGateがアクセス・サーバーの応答を待機する時間（秒単位）を指定します。ただし、アクセス・サーバーによるリクエストの処理がタイムアウトしきい値の値よりも長い時間を要する場合、WebGateはそのリクエストを破棄して新しい接続でリクエストを再試行します。接続プールの設定によって異なりますが、接続プールから返される新しい接続は、同じアクセス・サーバーに対するものである可能性があることに注意してください。また、他のアクセス・サーバーによるリクエストの処理がしきい値で許可された時間よりも長い時間を要する場合もあります。このような場合、WebGateはアクセス・サーバーが停止するまでリクエストの再試行を続ける可能性があります。 応答なしのサーバーに対してWebGateが実行する再試行回数の制限は、パラメータ 詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
|
優先HTTPホスト |
Oracle Access Manager 10.1.4.0.1では、「優先HTTPホスト」フィールドが必要となりました。このため、仮想ホスティングをサポートする環境に関する問題が発生していました。 10g（10.1.4.2.0）では、仮想ホストをサポートするために、「優先HTTPホスト」の値をHOST_HTTP_HEADER（ほとんどのWebホストの場合）またはSERVER_NAME（Apacheのみ）に設定します。IISの場合、追加の構成が必要です。 詳細は、『Oracle Access Managerアクセス管理ガイド』のアクセス・サーバーとアクセス・ゲートの構成に関する章を参照してください。 |
|
新規診断ツール |
アクセス・サーバーおよびアイデンティティ・サーバーには、Oracleサポート・サービス担当者と連携して問題に対処する際に役立つ新しい診断ツールがあります。 この診断ツールを使用すると、次の操作を行えます。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
ログ・ファイルの拡張機能 |
オペレーティング・システムのエラー情報がログに記録されるようになりました。たとえば、リスナー・スレッドの作成に失敗した場合、GetLastError()で返されるエラー・コードがログ・ファイルに追加されます。 |
|
構成可能になったwebpass.xmlファイルのポーリング追跡リフレッシュ・パラメータ |
複数のアイデンティティ・サーバーを設定したり、WebPassを変更したりする場合、管理者はwebpass.xmlファイルのPollTrackingRefreshIntervalを構成できるようになりました。この間隔は秒単位で構成する必要があります。複数のアイデンティティ・サーバーを設定したり、WebPassインスタンスを変更したりする場合に影響があります。 詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
パスワード変更後のユーザーの自動ログインが可能 |
自動ログインを構成するには、変更パスワード・リダイレクトURLに ユーザーをログインさせる変更パスワード・リダイレクトURLの例を次に示します。 /http://machinename:portnumber/identity/oblix/apps/lost_password_mgmt/bin/lost_password_mgmt.cgi? program=redirectforchangepwd&login=%login%%userid%&backURL=% HostTarget%%RESOURCE% &STLogin=%applySTLogin%&target=top フォーム・ベース認証スキームでこれを実装するには、ユーザー名の資格証明パラメータを第1トークンとして指定し、パスワードの資格証明パラメータを第2トークンとして指定してから、その他の資格証明パラメータを指定して、チャレンジ・パラメータ 詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
ログ・ファイルへのスタック・トレースの書込み |
Oracle Access Managerでコア・ダンプが発生した場合、ログ・ファイルにスタック・トレースを書き込めるようになりました。この機能を有効にするには、ロギングのレベルを最小にします。 スタック・トレース情報を含むログ・ファイルは、問題に関するレポートとともにOracleに送信できます。 詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のトラブルシューティングに関する付録を参照してください。 |
|
ディレクトリ・サーバーのフェイルオーバーの新規パラメータ |
globalparams.xmlの新規パラメータ globalparams.xmlの 詳細は、『Oracle Access Managerデプロイメント・ガイド』のフェイルオーバーに関する章と、『Oracle Access Managerカスタマイズ・ガイド』のパラメータ・ファイルに関する付録を参照してください。 |
|
構成ファイルでのLDAPバインドのパスワードのリセット |
Oracle Access Managerコンポーネントと通信するディレクトリ・サーバーのLDAPバインドのパスワードを定期的に更新する必要があります。 詳細は、『Oracle Access Managerデプロイメント・ガイド』のシステムの再構成に関する章を参照してください。 |
|
特定の操作に対するディレクトリ・サーバーの検索の最小化 |
以前のリリースでは、ポリシー・マネージャで大量のポリシー・ドメインやURLの接頭辞を作成する際に長い時間を要していました。このリリースでは、このような操作についてディレクトリ・サーバーへの検索が最小化されたため、パフォーマンスが向上しました。 |
|
クライアントへの委任偽装レベルの割当て |
WebGateで保護されるコンピュータ上のリソースの偽装を構成する他に、ネットワーク上の他のリソースにも偽装を拡張できます。これは、クライアントへの委任偽装レベルの割当てと呼ばれます。 偽装に関する情報は、『Oracle Access Managerアクセス管理ガイド』から『Oracle Access Manager統合ガイド』に移動しています。 詳細は、『Oracle Access Manager統合ガイド』の偽装の構成に関する章を参照してください。 |
|
リリース10.1.4パッチ・セット1（10.1.4.2.0）: 統合サポートにSharePoint Office Server 2007が含まれます。詳細は、『Oracle Access Manager統合ガイド』のSharePointとの統合に関する章を参照してください。 SAP NetWeaverとの統合サポートが提供されます。詳細は、『Oracle Access Manager統合ガイド』のSAPとの統合に関する章を参照してください。 マルチドメインのActive Directory環境におけるSiebelとの統合サポートが提供されます。詳細は、『Oracle Access Manager統合ガイド』のSiebelとの統合に関する章を参照してください。 Weblogic 9.2との統合サポートが提供されます。詳細は、『Oracle Access Manager統合ガイド』のWebLogicとの統合に関する章を参照してください。 WebSphere 6.1との統合サポートが提供されます。詳細は、『Oracle Access Manager統合ガイド』のWebSphereとの統合に関する章を参照してください。 |
