| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.0.1） B31699-01 |
|
 戻る |
 次へ |
この章は、予期されるシステム動作およびOracle Access Manager 10g（10.1.4.0.1）と以前のリリースとの変更点をまとめたものです。この章には、変更のない動作はほとんど含まれていません。次のカテゴリに分けて説明します。
|
注意: Oracle Access Manager 10g（10.1.4.0.1）の動作については、クイック・リファレンス表（および新機能の概要）が『Oracle Access Manager概要』に記載されています。また、「製品およびコンポーネントの名前の変更」も参照してください。 |
リリース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」タブを参照してください。
https://metalink.oracle.com
MetaLinkを使用する手順
https://metalink.oracle.comにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Application Server」を選択し、「Submit」をクリックします。
サポートが終了したコンポーネントとサード・パーティ製品については、「終了したサポート」にクイック・リファレンス表が記載されています。
コンポーネントをアップグレードすると、以前のプラグインなどとの下位互換性が自動的に備わります。ただし、以前のコンポーネントとの下位互換性が備わらないコンポーネントもあります。表4-1に、その概要と追加情報の参照先を示します。
表4-1 Oracle Access Managerコンポーネントの下位互換性
| コンポーネント | 下位互換性への自動対応 | 詳細の参照先 |
|---|---|---|
|
Identity Serverをアップグレードすると、以前のカスタム・プラグインとの下位互換性が自動的に備わります。 アップグレード後の環境に10g（10.1.4.0.1）のIdentity Serverを追加する場合は、以前のカスタム・プラグインと下位互換にするためのフラグを手動で設定する必要があります。 アップグレードしたIdentity Serverには、以前のWebPassインスタンスとの下位互換性はありません。 |
|
|
|
以前のIdentity Serverをすべてアップグレードしたら、以前のWebPassインスタンスもすべてアップグレードする必要があります。 以前のWebPassインスタンスには、10g（10.1.4.0.1）のIdentity Server（またはPolicy Manager）との互換性がありません。 アップグレード後の環境に10g（10.1.4.0.1）のWebPassインスタンスをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebPassインスタンスには、以前のIdentity Server（またはPolicy Manager）との互換性はありません。 |
|
|
|
スキーマとデータおよびすべてのIDシステム・コンポーネントをアップグレードしたら、以前のPolicy Managerもすべてアップグレードする必要があります。 |
|
|
|
以前のAccess Serverをアップグレードすると、以前のカスタム・プラグインおよび以前のWebGateとの下位互換性が自動的に備わります。 ただし、アップグレード環境に10g（10.1.4.0.1）のAccess Serverを追加する場合は、下位互換にするフラグを設定する必要があります。 以前のAccess Serverには、10g（10.1.4.0.1）のWebGateとの互換性はありません。 |
||
|
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされた10g（10.1.4.0.1）のAccess Serverと共存できます。 アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のAccess Serverとの互換性はありません。 アップグレード後の環境に10g（10.1.4.0.1）のAccess Serverを追加する場合は、以前のWebGateと下位互換にするためのフラグを設定する必要があります。 |
「保持される項目」で説明したように、Oracle Access Manager 10g（10.1.4.0.1）では、以前のインストールで実行されたカスタマイズが保持されます。ただし、表4-2に示すように、カスタマイズした項目を以前の環境からアップグレード環境にアップグレードする、すなわち組み込むための手動タスクを実行する必要がある場合がいくつかあります。詳細は、「カスタマイズのアップグレード計画」を参照してください。
表4-2 カスタマイズをアップグレードするために実行する必要のある手動タスク
動作の説明を探すためにすべてのマニュアルを調べずに済むよう、この章には、前述の各表に加えて、Oracle Access Manager 10g（10.1.4.0.1）で予期される動作がまとめられています。
この項では、以前のIDシステムとアクセス・システムに共通していた動作について説明します。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）をインストールする場合は、管理タスクのデフォルトとして使用する言語（ロケール）を選択します。IDシステム・コンソール、アクセス・システム・コンソールおよびPolicy Managerの管理情報は、インストールした管理者用の言語でのみ表示されます。以前のリリースでは、言語のドロップダウン・リストがシステム・コンソールの右上隅に表示されていました。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）にアップグレードした後に、監査およびレポート環境が正常に動作することを保証するために実行する必要のあるステップについては、次の監査およびアクセス・レポートに関するトピックを参照してください。
また、IDシステム・コンソールで監査ポリシーを構成するときは、すべての監査レコードに対してプロファイル属性のリストを指定できます。プロファイル属性（「フルネーム」、「従業員番号」、「部門番号」など）は、監査されるアクション/イベント（「検索」、「プロファイルの表示」、「プロファイルの変更」など）を実行するユーザーに固有です。プロファイル属性は、アクションやイベントを実行しているユーザーを識別しやすくするためのものです。
|
警告: チャレンジ・フレーズまたはレスポンス属性の公開を回避するために、監査のプロファイル属性としてこれらを選択しないことをお薦めします。チャレンジ・フレーズまたはレスポンスをプロファイル属性として追加すると、これらは独自のエンコード形式で監査されます。 |
ldifde.exeツールのライセンスの問題のため削除されました。ADAMのスキーマは手動で更新してください。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
7.0より前のリリースからアップグレードする場合は、Access Manager SDKおよびOracle Access Manager APIを使用して作成したC++プログラムを、アップグレードの後で再コンパイルする必要があります。詳細は、次を参照してください。
10g（10.1.4.0.1）Identity Serverは、以前のAccess Serverのキャッシュをフラッシュできません。この問題を解決するには、Access Serverを10g（10.1.4.0.1）にアップグレードする必要があります。
詳細は、「Access Serverの下位互換性」を参照してください。
ディレクトリ・サーバーとOracle Access Managerサーバー、およびディレクトリ・サーバーとPolicy Managerとの間の通信は、オープン（セキュリティなし）にするか、またはSecure Sockets Layer（SSL）を使用できます。SSL対応の場合は、サード・パーティの認証局から提供されるBase64形式の署名者の証明書（ルート認証局（CA）証明書）を要求します。
Webクライアント間（WebPassとIdentity Server間、Policy ManagerとWebPass間、およびAccess ServerとWebGate間）の通信用には、3つのトランスポート・セキュリティ・モードが用意されています。これらのセキュリティ・モードとは、「オープン」、「シンプル」（Oracle付属）、および「証明書」（サード・パーティCA）です。
シンプル・モードと証明書モードでは、Oracle Access ManagerのコンポーネントはX.509デジタル証明書のみを使用します。この機能では、標準cert-decodeプラグインが証明書をデコードし、証明書情報を標準credential_mapping認証プラグインに渡す証明書認証がWebGateとAccess Server間で行われます。
オラクル社とサード・パーティ・ベンダーはどちらも、ローカライズされた証明書を、コンポーネントとディレクトリ・サーバー間の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のカスタム・プラグインを再コンパイルする必要があります。これには、IDイベント・プラグインと、カスタム認証および認可プラグインも含まれます。
詳細は、次を参照してください。
|
警告: オペレーティング・システムに付属のコンパイラがある場合でも、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の以前の構成によって、アップグレードになんらかの影響が出る場合があります。
IDシステム接続プール: 影響はありません。データベース・インスタンス・プロファイルで指定した「最初の接続数」および「最大接続数」は保持され、以前と同様に機能します。
リリース6.5より前のアクセス・システム接続プール: UserDB.lstおよびUserDBFailover.lstの「最初の接続数」および「最大接続数」の値は保持されません。アクセス・システム・コンポーネントをアップグレードした後は、新規に作成されたディレクトリ・サーバー・プロファイルのデータベース・インスタンス・プロファイルの値を確認することをお薦めします。
NDS: NDSディレクトリ・サーバーへの同時認証リクエストの場合は、システム・コンソールを使用して、接続プールのサイズを、ユーザー・ディレクトリ・プロファイルのデフォルト（1）より大きい値に設定することをお薦めします。
「ディレクトリ・サーバーのフェイルオーバー」も参照してください。
Oracle Access Managerには、管理者がアクセス・コンポーネントとIDコンポーネントを構成するために使用できるコンソール・ベースのコマンドライン・ツールが用意されています。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）を使用してイメージを参照する必要があります。
|
注意: アップグレードの際、以前のインストールで作成されたスタイル関連ディレクトリは保存されますが移行されず、名前変更された（バックアップ）ソース・ディレクトリに格納されます。IDシステムをアップグレードした後、カスタマイズされたスタイルを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以外のキャラクタ・セットを使用したデータが含まれることがあります。詳細は、「監査およびアクセス・レポート」を参照してください。
次のようにIDシステムとアクセス・システム間で形式が異なる場合があります。
IDシステム: 10g（10.1.4.0.1）のIDシステムでは、日付の形式は最新のリリースと同じであり、国際化されていません（たとえば、「診断」ページや「チケット情報」ページなど）。ただし、IDシステムのメッセージ・カタログから取得される月の名前は、ブラウザで指定されているロケールで表示されます。
『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、以前のリリースと同様に、日付の順序の形式（MM/DD/YYYYとDD/MM/YYYYなど）は、IDシステム・コンソールでオブジェクト・クラス属性を変更することで構成できます。「チケット情報」ページの日付は、globalparams.xmlファイルのobDateTypeパラメータで指定されている形式で表示されます。週日の名前は、IDシステム内のどこにも出現しません。
アクセス・システム: 10g（10.1.4.0.1）のAccess Systemでは、月の名前、日付順序の形式（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）の一部としても利用可能）と同じままです。 |
これらが動作する例は、Access Serverの「診断」ページ、Policy Managerで作成されたアクセス・ポリシーの「認可ルール」の下にある「タイミング条件」ページ、「アクセス・システム・コンソール」の「システム管理」タブにある「レポートの管理」ページ、およびアクセス・システム・コンソールの「システム管理」タブにある「同期レコードの管理」ページに表示されます。
Oracle Access Manager 10g（10.1.4.0.1）では、アドレス/identity/oblix/index.htmlおよび/access/oblix/index.htmlには、1つの静的なHTMLページだけが存在できます。
これらの静的な製品ページでは、この場所にIdentity ServerとAccess Serverをインストールした際に選択されたデフォルトの管理者用言語が常に使用されます。リリース6.5以降、製品は複数のLatin-1言語（フランス語、ドイツ語）をサポートしています。製品ページのデフォルトの動作は、以前のリリースと同じままです。
「HTMLページ」も参照してください。
リリース5.2以降、IDシステムにはディレクトリ・プロファイルとデータベース・インスタンスが導入されました。リリース6.5以降、アクセス・システムは、ユーザー・データへのアクセスに対するディレクトリ・プロファイルとデータベース・インスタンスの使用を部分的に開始しました。ディレクトリ・プロファイルは、アクセス・システムの以前のリリースで使用されていたUserDB.lst、GroupDB.lst、UserDBFailover.lst、GroupDBFailover.lstの各構成ファイルのかわリに使用されます。
ディレクトリ・プロファイル（ディレクトリ・サーバー・プロファイルとも呼ばれます）には、同じネームスペースを共有する1つ以上のディレクトリ・サーバーに対する接続情報、および読取り、書込み、検索などに関する操作要件が含まれています。接続情報には、名前、適用されるドメインまたはネームスペース、ディレクトリ・タイプ、および操作のセットが含まれます。
各ディレクトリ・プロファイルには、複数のプライマリおよびセカンダリのデータベース・インスタンスを指定できます。各データベース・インスタンス・プロファイルは、1つのディレクトリ・サーバーへの接続情報（接続プール情報など）を表します。
ディレクトリ・プロファイルは、Identity Server、Policy ManagerまたはAccess Serverをインストールして新しいディレクトリ・サーバー接続情報を指定するたびに自動的に作成されます。ロード・バランシングおよびフェイルオーバーのために追加のディレクトリ・サーバー・プロファイルを作成できます。
以前のPolicy ManagerまたはAccess Serverをアップグレードする場合は、リリース6.5への段階的アップグレードの際に、新しいディレクトリ・プロファイルが作成されたことを示すメッセージが表示されます。「DB Profiles created.」というメッセージは、このディレクトリ・サーバー・プロファイルを指しています。アクセス・システムの新しいディレクトリ・プロファイルを作成すると、以前の構成ファイルの接続プール値が保持されないことがあります。アップグレードの終了後、新規に作成したディレクトリ・プロファイルのデータベース・インスタンス・プロファイルでこれらの値を確認する必要があります。「接続プールの詳細」も参照してください。
Oracle Access Managerの以前のバージョンでは、ディレクトリ接続情報はXML構成ファイルによってのみ管理されていました。最近のリリースでは、IDシステム・コンソールおよびアクセス・システム・コンソールの「ディレクトリ・プロファイル」ページを使用するインタフェースを通して、この情報を管理できます。ただし、構成データとポリシー・データの一部は、依然としてXMLファイルによって管理されています。「ディレクトリ・プロファイルとデータベース・インスタンス・プロファイル」も参照してください。
Identity Serverのフェイルオーバー構成は、リリース5.2以降、システム・コンソールのディレクトリ・サーバー・プロファイルに格納されています。リリース6.5以降は、次に示すとおりです。
マスター・ディレクトリ・サーバーとフェイルオーバー・ディレクトリ・サーバーに関するディレクトリ・サーバー・プロファイルが作成されるようになりました。
構成されているすべてのプライマリ（およびセカンダリ）ディレクトリ・サーバーごとに1つのデータベース・インスタンス・プロファイルを作成するために、特定の構成ファイルにあるディレクトリ・サーバー情報が使用されるようになりました。
たとえば、リリース6.5への段階的アップグレード中に、Access Serverのディレクトリ・プロファイルが自動的に作成され、次に示すいくつかの以前の構成ファイルに置き換えられます。
Policy Managerに対するディレクトリ・サーバー・プロファイルを作成する場合、ディレクトリ・サーバー資格証明はPolicyManager_install_dir/access/oblix/config/userDB.lstから読み取られます。
|
注意: 構成ツリーがユーザー・ディレクトリ・サーバー内でユーザー・ノードの下にある場合、構成ディレクトリ・プロファイルは作成されません。ノードの下にない場合、構成ディレクトリ・プロファイルはPolicyManager_install_dir/oblix/config/ldap/configdb.lstからのディレクトリ・サーバー情報を使用して作成され、Policy Manager専用としてマークされます。 |
Policy Managerフェイルオーバー・サーバー用に使用されるプロファイルが作成されなくなります。リリース6.1では、ポリシー・ツリーが別のディレクトリ・サーバー上にある場合に、ポリシー・データのプロファイルが用意されていました。
Access Serverがデータのアップグレード後に複数のディレクトリ・サーバーに対応できるようになりました。
アップグレード後に以前のリリースでのフェイルオーバー構成が意図したとおりに動作するかどうかを確認するには、次の項目を参照してください。
「メッセージ・ファイルとパラメータ・ファイル」で説明されているように、以前の.lstファイルが.xmlファイルに変換されます。「接続プールの詳細」も参照してください。
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: Access Serverのインストール時に作成されます。
OracleAccessManager\identity: Identity Serverのインストール時に作成されます。
OracleAccessManager\webcomponent: Oracle Access Manager Webコンポーネント（WebPass、Access Manager、WebGate）のインストール時に作成されます。
リリース6.5から10g（10.1.4.0.1）をインストールすると、言語ディレクトリが作成され、その下にはインストールされた各言語の名前が付いたサブディレクトリが追加されます（このサブディレクトリには、カスタマイズ可能な各種アプリケーション用の.XMLメッセージ・カタログ・ファイルが含まれます）。
詳細は、付録A「Oracle Access Managerディレクトリ構造の変更点」を参照してください。
以前のリリースの製品と同様に、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がアクセス・システム・コンポーネントで使用される暗号化スキームになりました。IDシステムは、ロスト・パスワード管理レスポンスに対して引き続き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概要』に概説されており、マニュアル・セット全体でも説明されています。
各IDシステム・アプリケーション（User Manager、Group Manager、Org. Managerなど）により、アプリケーション内の各ページのHTMLが生成されます。アクセス・システム・コンポーネント（Policy Managerや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サーバーのこのような設定を無効にすることをお薦めします。 |
「デフォルトの製品ページ」も参照してください。
6.5より前のリリースでは、Oracle Access Managerのメッセージは各アプリケーション向けのXMLファイルで制御され、アプリケーション固有のディレクトリに格納されていました。次に例を示します。
IdentityServer_install_dir/identity/oblix/apps/appname/bin/appnamemsg.xml
ここで、IdentityServer_install_dirはIdentity Serverがインストールされているディレクトリで、appnameは次に示すように特定のアプリケーションに対応しています。
groupservcenter: Group Manager
objservcenter: Organization Manager
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のメッセージ・カタログとパラメータ・カタログが使用されます。
インストールまたはアップグレードの後にわかるように、一部の製品名とコンポーネント名が変更されます。アップグレードの間に、以前の製品名、コンポーネント名および機能名が新しい名前に変更されます。たとえば、10g（10.1.4.0.1）では、デフォルトのポリシー・ドメインはIdentityドメインおよびAccessドメインであり、デフォルトの認証スキームはOracle Access and Identity、AD Forest用のOracle Access and Identityおよび匿名です。アップグレードにより、以前の名前が新規の名前に置き換えられます。
いくつかの機能名が、アクセス・システムとIDシステムの間で統一された名詞句として修正されました。AMサービスのステータスという呼称がPolicy Manager APIサポート・モードに変更されました。詳細は、「製品およびコンポーネントの名前の変更」を参照してください。
インストールおよび構成の際に管理者が割り当てた名前は、アップグレードの間保持されます（変更されません）。したがって、サービスに「COREid Identity Server」または「NetPoint Identity Server」と名前を付けた場合、これらの名前はアップグレード環境でも変わりません。以前の認証スキームとポリシー・ドメインも、アップグレード時に保持され、変更されません。「保持される項目」も参照してください。
リリース6.5より前は、2つの異なるディレクトリに格納されるポリシー・データとユーザー・データに対するネームスペースは、一意である必要がありました。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および共通管理ガイド』を参照してください。
以前のWebPassインスタンスには、10g（10.1.4.0.1）のIdentity Server（またはPolicy Manager）との互換性がありません。以前のIdentity Serverをすべてアップグレードしたら、以前のWebPassインスタンスもすべてアップグレードする必要があります。このルールの例外は、この目的で追加するマスターIDシステムを使用してスキーマとデータをアップグレードする場合です。詳細は、第II部「スキーマおよびデータのアップグレード」を参照してください。
アップグレード後の環境に10g（10.1.4.0.1）のWebPassインスタンスをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebPassインスタンスには、以前のIdentity Server（またはPolicy Manager）との互換性はありません。
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされたAccess Serverと共存できます。アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のAccess Serverとの互換性はありません。詳細は、「WebGate」を参照してください。
アップグレード後の環境に10g（10.1.4.0.1）のAccess Serverを追加する場合は、以前のWebGateと下位互換にするためのフラグを設定する必要があります。詳細は、「Access Serverの下位互換性」を参照してください。
この項では、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カスタマイズ・ガイド』を参照してください。
次のディレクトリ内の機密に関わるデータをブラウザから直接表示できないようにするために、セキュリティに関連した変更が実施されました。
/access（またはidentity）/oblix/config/*.*にある構成ファイル
/access（またはidentity）/oblix/log/*.*ディレクトリにあるログ・ファイル
importantnotes.txtファイルは削除され、このファイルに記述されていた情報は、『Oracle Access Managerインストレーション・ガイド』の付録に記載されています。
Webサーバー構成ファイルのグローバリゼーションとUTF-8サポートについては変更されていません。
この項では、10g（10.1.4.0.1）へのアップグレード後における、以前のIDシステムの動作との変更点と予期される動作について説明します。内容は次のとおりです。
以前のリリースでは、チャレンジ・フレーズ属性とレスポンス属性を「ユーザー・プロファイル」ページの異なるパネルに配置できました。ただし、10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性を同じパネルにのみ配置できます。10g（10.1.4.0.1）では、チャレンジ・フレーズとレスポンスがパネル上で連続して構成されなくても、隣接して表示されます。
パネルにチャレンジ属性のみが含まれる場合、チャレンジ属性は「ユーザー・プロファイル」ページにレスポンスなしで表示されます。パネルがレスポンスのみ（チャレンジ属性がない）を含む場合は、レスポンスは「ユーザー・プロファイル」ページにはまったく表示されません。単一パネルへのこれらの隣接表示の詳細は、「単一パネルへのチャレンジ属性とレスポンス属性の配置」を参照してください。
また、この機能のためにIdentityXMLも変更されました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
10g（10.1.4.0.1）以降、Identity ServerはUTF-8エンコーディングを使用し、プラグイン・データはUTF-8データを含みます。以前のプラグインは、Latin-1エンコーディングでデータを送受信します。
以前のIdentity Serverをアップグレードすると、以前のカスタム・プラグインとの下位互換性が自動的に備わります。この場合、以前のプラグインとの下位互換性を確保するため、新規フラグ（encoding）がoblixpppcatalog.lstファイルに自動的に追加されます。下位互換性のあるIdentity Serverは、以前のプラグインにLatin-1エンコーディングでのデータの送信を継続します。
詳細は、次項「IDシステムのイベント・プラグイン」の下位互換性についての説明を参照してください。「キャッシュのフラッシュ」も参照してください。アップグレードしたIdentity Serverには、以前のWebPassインスタンスとの下位互換性はありません。
IDイベント・プラグインAPIはIdentity Serverと一緒にインストールされる標準コンポーネントです。これを使用すると、カスタム・ビジネス・ロジックを実行するための独自の小さいアプリケーション（アクションと呼ばれます）を作成し、外部システムと統合することで、IDシステムの機能を拡張できます。アクションは、IDシステムによって特定のデータを利用できるようにされた後、データを変更したり、イベントの結果に影響を与えたりすることが許可されます。
10g（10.1.4.0.1）以降、Identity ServerはUTF-8エンコーディングを使用し、プラグイン・データはUTF-8データを含みます。また、SolarisおよびLinuxでは、「プラグイン」で説明されているように、GCC v3.3.2 C++コンパイラを使用してリリース7より前のプラグインを再コンパイルする必要があります。
以前のリリースでは、IDイベント・プラグインにデータを送信する際、Latin-1エンコーディングを使用していました。アップグレード後の環境でも、以前のリリースのIDイベント・プラグインでは現在もLatin-1エンコーディングが使用されます。場合によっては、UTF-8エンコーディングを使用するように以前のカスタム・プラグインを設計変更する必要があります。ただし、10g（10.1.4.0.1）Identity Serverと以前のプラグインとの通信が必要になる場合もあります。
以前のIdentity Serverを10g（10.1.4.0.1）にアップグレードすると、以前のIDイベント・プラグインとの下位互換性が自動的に備わります。アップグレード中に、新しいフラグ（encoding）がoblixpppcatalog.lstファイルに追加されます。下位互換性のあるIdentity Serverは、引き続きLatin-1エンコーディングで以前のプラグインにデータを送信し、以前のプラグインはLatin-1エンコーディングでデータを受送信します。プラグイン側のデータ・エンコーディングには変更はありません。
アップグレードされた環境に10g（10.1.4.0.1）のIdentity Serverを新しく追加する場合は、Identity Serverの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フラグの設定が不要になります。 |
IDイベント・プラグインAPIの一般的な用途には、パスワード検証、統合およびプロビジョニングがあります。たとえば、IDイベントAPIを使用するパスワード管理イベント用にイベント・ハンドラを作成し、Oracle Access Managerのパスワード・ポリシー機能に追加できます。また、各登録ワークフロー・インスタンスの有効化ステップに対するイベント・ハンドラを作成することもできます。このイベント・ハンドラの作成目的は、RDBMSベンダーのAPIを使用してリモート・データベースを更新したり、要求されている形式で一意の文字列を生成し、IDシステムに渡してuid属性値として使用することです。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アクションは、開発者が作成し、Oracle Access Manager管理者が特定のイベントに対するレスポンスとして実行されるよう構成した外部ロジック（イベント・ハンドラとも呼ばれます）の1つの単位です。アクションでは、外部コンポーネントにアクセスせずにタスクを実行したり、利用可能な任意のメカニズムを使用してWebサービス、RDBMSサービス、ERPアプリケーションなどサード・パーティのアプリケーションとリソースにアクセスできます。アクションとイベントを関連付けるには、oblixpppcatalog.lstファイルを使用します。Identity Serverは起動時に、アクションを伴うイベントが記載されたカタログを読み取ります。イベントが発生すると、サーバーはそのイベントに関連付けられているアクションを実行します。
IDイベント・プラグインAPIには次の3種類のアクションがあります。
LIBアクション: Identity Serverがコールする共有ライブラリ（Windowsシステムの場合はDLL）内の関数です。アクションは、動的にロードされると、Identity Serverと同じプロセス空間で実行され、サーバーに格納されているデータ・オブジェクトにAPI関数を介して直接アクセスします。Identity Serverからライブラリに、プラグイン・データを含むC++オブジェクトが送信されます。
MANAGEDLIBアクション: Windowsシステムに専用の機能です。Microsoft Intermediate Language（MIL）コンパイラが用意されている.NET言語で作成されます。MIL命令はネイティブのマシン命令にコンパイルされて動的メモリーに格納されてから、Microsoft .NET Common Language Runtime（CLR）で実行されます。MANAGEDLIBアクションはLIBアクションと類似していますが、管理コードの利点も持ち合せています。Identity Serverからライブラリに、プラグイン・データを含むC++オブジェクトが送信されます。
EXECアクション: 固有のプロセス空間で実行されるスタンドアロン実行可能プログラムです。Identity Serverとの通信は、入力では起動パラメータとXMLストリームに限定され、出力ではXMLストリームと終了ステータス・コードに限定されます。また、アクションでは、LDAP IDイベント・プラグインなど他のAPIも使用できます。
イベントとは、IDシステム内の状態の変更です。イベントの例には、リクエストが受け取られてアプリケーション（User Managerの参照プログラムなど）にまもなく引き渡される場合、アプリケーション（Group Managerの検索プログラムなど）から結果が生成された場合、ユーザーがパスワード・リセットの試行中にチャレンジ・レスポンスを入力した場合、アプリケーション（Organization Managerなど）のプロファイル・ページの属性が変更された場合、または企業ITグループによる承認の待ち状態にあったワークフロー・チケットが承認された場合があります。
最も頻繁に使用されるイベント・タイプは、ペアで生成される前処理イベントと後処理イベントです。それぞれのアプリケーション（User Manager、Group ManagerまたはOrganization Manager）には、アプリケーション内の各ページのHTMLを生成するプログラム（参照、検索など）がいくつか含まれています。各プログラムによって前述のイベント・ペアが認識されます。前処理イベントは、プログラムがページの作成を開始する前に生成され、リクエストがプログラムに到達する前にイベント・ハンドラによって処理されるようにします。後処理イベントは、プログラムがページを作成してからHTMLページでユーザーに応答するまでの間に生成されます。また、後処理イベントは、リクエストの処理結果をイベント・ハンドラが処理できるようにします。
ブラウザを介さずにアプリケーションとやり取りするためのプログラムを作成することもできます。IdentityXMLは、ユーザーがブラウザからIDシステム・アプリケーションにアクセスする際に実行できるアクションを実行するためのプログラム・インタフェースです。IdentityXMLを使用すると、単純なアクションとマルチステップのワークフローを処理して、ユーザー、グループおよび組織のオブジェクト・プロファイルを変更できます。また、外部アプリケーションは、IdentityXMLを使用してIDシステムの機能にアクセスできるようになります。
リリース6.5では、IdentityXMLリクエストの構文が一部変更されました。以前の構文も問題なく動作します。新規構文については、『Oracle Access Manager開発者ガイド』を参照してください。
10g（10.1.4.0.1）では、XMLページ、SOAP/IdentityXMLリクエスト、および実行可能ファイルに送信されるIDイベント・プラグイン・データに対しては、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レスポンスはUTF-8エンコーディングでのみ発行されます。
また、チャレンジ・フレーズとレスポンス・フレーズの変更に対応するための変更が、10g（10.1.4.0.1）でIdentityXMLに加えられました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アプレットは、Webページとともにユーザーに送信される小さなプログラムです。Javaアプレットは対話型のアニメーションや即時計算の他、ユーザー・リクエストをサーバーに返送する必要のない単純なタスクも実行します。
以前のリリースでは、製品にインストールおよび構成されている言語が一覧表示されるドロップダウン・リストがIDシステム・コンソールにありました。ユーザーがこのリストで言語を変更した場合は、アプレットと他のページが、選択された言語で表示されました。たとえば、英語ロケールで作業中のユーザーがヨーロッパ言語で表示されたアプレットを使用するには、単にドロップダウン・リストから該当する言語を選択するのみで済みました。ただし、このモデルはヨーロッパ言語にしか十分に機能しませんでした。
このモデルに日本語などのマルチバイト言語が導入されたため、マルチバイト・キャラクタ・セットが正しく表示されるようになりました。また、言語リストがIDシステム・コンソールから取り除かれました。英語ロケールを使用するユーザーは、マルチバイト言語でアプレットを表示することはできません。アプレットをマルチバイト言語で使用するには、ユーザーのマシンのロケールを同じ言語に設定する必要があります。
|
注意: JDK1.1.7のJavaアプレットについては既知の制限があります。Oracle Access Manager 10g（10.1.4.0.1）では、非ASCIIデータを使用するアプレットは、ネイティブにエンコードされたオペレーティング・システムを実行するマシンでのみ適切に表示できます。ブラウザのエンコーディングを設定しても機能しません。 |
ユーザーの作業に影響を及ぼすJavaScriptの変更はありません。
Identity Serverは各種機能（属性変更、ワークフロー、コンテナ制限など）に関するメール通知を送信します。メールに使用できる書式には、テキストのみ、リッチHTML、およびMHTML（HTMLなどのドキュメントの集合をMIMEでカプセル化したもの）があります。メールの送信では、非同期モードと同期モードの両方がサポートされます。Identity Serverは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
以前のリリースでは、IDシステム・アプリケーション（User Manager、Group ManagerおよびOrganization Manager）で検索を実行するときには、3文字以上入力する必要がありました。10g（10.1.4.0.1）では、必要な最少文字数はありません。デフォルトでは、文字を入力しなくてもかまいません。以前のリリースと同様に、oblixadminparams.xmlのsearchStringMinimumLengthパラメータを設定することで、ユーザーが検索フィールドに入力する必要のある最低文字数を制御して、ユーザーが検索条件を絞り込むのを助けることができます。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ワークフローを使用して、IDシステムのビジネス・プロセスをモデル化することができます。以前のリリースでは、ワークフローを使用して、証明書の発行、取消し、更新を行うことができました。しかし、この機能はサポートされなくなっています。
Oracle IDプロトコル（以前のNetPoint IDプロトコルまたはCOREid IDプロトコル）は、Identity Serverと関連するWebPassインスタンスの間の通信を容易にします。グローバリゼーションに関してプロトコルは変更されていません。「Oracle Accessプロトコル（OAP）への更新」も参照してください。
IDシステムを使用して、パスワードを制限するためのポリシーを定義できます。このポリシーは次の項目からなり、実行時に強制されます。
パスワードの最小長
大文字の最小数
小文字の最小数
非英数字文字の最小数
その他
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）のIdentity Serverは、以前の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ライブラリは別のディレクトリに格納されます。
詳細は、「カスタム・アイテムとそのアップグレードの概要」を参照してください。
この項目では、アクセス・システムの以前の動作について説明します。10g（10.1.4.0.1）へのアップグレード後に予期される動作を中心に説明します。内容は次のとおりです。
10g（10.1.4.0.1）よりも前のリリースでは、Cookieの暗号化および復号化はWebGate/AccessGateによって処理されました。ただし、現在はCookieの暗号化および復号化はAccess Serverによって処理されます。このため、以前のAccess Serverには、10g（10.1.4.0.1）のWebGateとの互換性はありません。「暗号化スキーム」も参照してください。
Oracle Access Manager 10g（10.1.4.0.1）以降、Access ServerではUTF-8エンコーディングが使用され、プラグイン・データにUTF-8データが含まれるようになります。以前のプラグインは、Latin-1エンコーディングでデータを送受信します。
以前のAccess Serverをアップグレードすると、以前のカスタム・プラグインおよび以前のWebGateとの下位互換性が自動的に備わります。この場合、新規パラメータ"IsBackwardCompatible" Value="true"がAccess Serverのglobalparams.xmlファイルに自動的に設定されます。これによって下位互換性が提供され、Access Serverは以前のカスタム認証および認可プラグインへのLatin-1エンコーディングでのデータの送信（および受信）を継続できます（以前のカスタム・プラグインは、Latin-1エンコーディングでデータを設定します）。また、Access Serverは、Cookieの暗号化および復号化を継続する、以前のWebGateおよびカスタムAccessGateとの下位互換性を維持します。
|
注意: アップグレードした環境に新規の10g（10.1.4.0.1）のAccess Serverを追加する場合は、 |
詳細は、「カスタム認証および認可プラグインとそのインタフェース」および「Oracle Accessプロトコル（OAP）への更新」を参照してください。
Access Manager SDK（以前のAccess Server SDK）は、サポートされている各開発プラットフォーム用に単純なカスタムAccessGateサーブレットやアプリケーションを作成するために必要となるドキュメント、リソースおよびサンプル・コードをすべて提供するオプション・コンポーネントです。AccessGateは、Access Serverクライアント（エージェント）であり、Oracle Access Managerによって保護されたLDAPドメイン内にあるリソースへのアクセスに対するユーザー・リクエストを処理します。ユーザー・リクエストを処理するためのコードは、プラグインに埋め込むことも、スタンドアロンのアプリケーションとして作成することもできます。
Access Manager SDKをインストールしたら、Access Manager API（以前のAccess Server API）を使用して、サポートされている4種類の開発言語（Java、C、C++およびC#（.NET））のうちのいずれかでカスタムAccessGateコードを記述できます。4種類の実装は、それぞれプラットフォーム固有の機能を利用してAPIを実装していますが、機能的には同じです。
カスタムAccessGateコードを記述するための開発言語インタフェースとして4種類の実装のうちのいずれかを選択できますが、『Oracle Access Manager開発者ガイド』で説明されているように、記述したコードは、このAPIを構成するC++バイナリとやり取りします。
10g（10.1.4.0.1）のCおよびC++ Access Manager APIを使用してカスタムAccessGateを開発すると、データが自動的に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）のAccess ServerとC# AccessGateは、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）のAccess ServerとAccessGateでは、自動的にUTF-8エンコーディングが使用されます。
|
注意: 10g（10.1.4.0.1）のAccess Manager SDKおよび10g（10.1.4.0.1）のカスタムAccessGateは、以前のAccess Server、Access Manager SDK、およびAccessGateとの間に下位互換性がありません。ただし、以前のAccessGateは、下位互換性を有効にした10g（10.1.4.0.1）のAccess Serverとともに使用できます。「Oracle Accessプロトコル（OAP）への更新」も参照してください。 |
カスタムAccessGate（および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）にあるいくつかの変更点、下位互換性、考慮事項について次に説明します。
認証とは、保護されたリソースにアクセスしようとしているユーザーが本人の主張するとおりの人物であるかどうかを判別するプロセスのことです。認可とは、認証されたユーザーが保護されたリソースへのアクセス権限を持っているかどうかを判定するプロセスのことです。Access Serverは認証管理と認可管理の両方を使用して、保護するリソースへのアクセスを制限し、認証および認可プラグインと対話するように定義されたインタフェースを提供します。
標準の認証および認可プラグインを使用することも、Oracle Access Managerの認証プラグインAPIおよび認可プラグインAPIを使用して独自のカスタム・プラグインを作成することもできます。各カスタム・プラグインは、適切なインタフェース（認証または認可）を実装します。プラグインに応じて、Access Serverとプラグインの間で関連情報を受け渡しするためのインタフェースが有効になります。このインタフェースのメソッドによってデータが解析されます。
10g（10.1.4.0.1）より前のCに対する認証プラグインAPIおよび認可プラグインAPIは、Access Serverとカスタム・プラグインの間で交換されるデータに、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）のAccess Serverと以前のプラグインとの通信が必要になる場合もあります。
以前のリリースから10g（10.1.4.0.1）にアップグレードしたAccess Serverには、自動的に下位互換性が備わります。ただし、アップグレード環境に10g（10.1.4.0.1）のAccess Serverを追加する場合は、下位互換性を手動で設定する必要があります。詳細は、「Access Serverの下位互換性」を参照してください。
この項では、Oracle Access Managerの認証および認可プラグインについて概説します。
認証は認証ルールで管理されます。認証ルールでは、認証スキームが使用されます。認証スキームは、1つ以上のプラグインを使用してユーザーが示す資格証明をテストします。標準の認証プラグインがAccess Serverインストールには付属していますが、独自のカスタム・プラグインを認証プラグインAPIで作成することもできます。
認可は、デフォルトのルール・セットの一部である、ドメインのリソースを保護する方法を指定している認可条件式を含むポリシー・ドメインによって管理されます。認可条件式は、複数の認可ルールを組み合せて作成します。ルールを作成する際には、認可スキームを組み入れます。アクセス・システムによって提供される認可スキームを使用することも、認可プラグインAPIを使用して作成されるカスタム・プラグインを含む1つ以上のカスタム認可スキームを構成することもできます。
リリース6.5では、Access ServerおよびPolicy Managerに対するディレクトリ・サーバー・プロファイルのサポートが導入されました。7.xより前の任意のリリースからのPolicy Managerのアップグレードにおいて、新しいディレクトリ・サーバー・プロファイルが自動的に追加されます。ただし、「最初の接続数」と「最大接続数」の値は、Policy Managerのアップグレードでは保持されません。
アップグレードを行った後、新しいディレクトリ・サーバー・プロファイルが正しく作成されたこと、およびアクセス・システムのディレクトリ・サーバー・プロファイルのロード・バランシングとフェイルオーバーの設定が意図したとおりに構成されていることを、確認して検証することをお薦めします。
詳細は、「ディレクトリ・プロファイルとデータベース・インスタンス・プロファイル」を参照してください。
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のログイン資格証明に使用します。 |
以前のリリースでは、このパラメータのデフォルト値は100000に設定されていました。ただし、Oracle Access Manager 10g（10.1.4.0.1）では、このデフォルト値が10000に変更されました。このパラメータを確認するには、アクセス・システム・コンソールで、「アクセス・システム構成」タブの「Access Server構成」機能を参照してください。「Access Serverの詳細」ページを確認します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
Oracle Accessプロトコル（以前のNetPointまたはCOREid Accessプロトコル）を使用すると、ユーザーの認証と認可の間に、アクセス・システム・コンポーネント間での通信が可能になります。WebGateとAccessGateには、認証および認可に必要なユーザー情報（ログイン名、パスワード、ヘッダーなど）が格納されます。データは、シリアライズされてAccess Serverに送信された後で、デシリアライズされます。Access Serverにより、結果がAccess Clientに返送されます。
以前の製品リリースでは、送受信されるデータにはLatin-1エンコーディングが使用されていました。10g（10.1.4.0.1）では、UTF-8エンコーディングが使用されます。10g（10.1.4.0.1）のAccess Serverでグローバリゼーションと共有シークレット生成の両方を行えるように、更新されたOracle Accessプロトコルが付属するようになりました。
10g（10.1.4.0.1）の新規インストールでは、何もアクションを実行する必要はありません。この最新のOracle Accessプロトコルが、Access Serverと関連WebGate/AccessGate間や、Access Serverと標準/カスタムの新しい認証および認可プラグイン間のすべての通信に使用されます。
アップグレード環境では、Access Serverの下位互換性を実現するには、「Access Serverの下位互換性」の手順を実行する必要があります。
「Oracle IDプロトコル（OIP）」も参照してください。
すべてのIDシステム・コンポーネントをアップグレードした後、以前のPolicy Manager（以前のAccess Managerコンポーネント）もすべてアップグレードする必要があります。
アクセス・システムでは、Policy Managerグラフィカル・ユーザー・インタフェース（GUI）に実装されている大部分の機能に対しては、プログラムによるアクセスも用意しています。なお、Policy Manager API（以前のアクセス管理API）を使用すると、ポリシー・ドメインとその内容を作成して管理したり、カスタム・アプリケーションによるAccess Serverの認証、認可および監査の各サービスへのアクセスを可能にすることができます。以前のリリースと同様に、10g（10.1.4.0.1）Policy Manager 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およびカスタムAccessGateで行われていました。10g（10.1.4.0.1）では、共有シークレットは引き続きディレクトリ・サーバーに格納されますが、Cookieの暗号化と復号化がAccess Serverで行われるようになりました。このため、WebGateとAccessGateには、共有シークレット・キーが不要になりました。
ユーザー・セッションの間に共有シークレットを変更した場合、ユーザーを再認証する必要はありません。Cookieが古い共有シークレットを使用して復号化されている場合、このCookieは、リフレッシュされると、新しい共有シークレットを使用して暗号化されます。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
Access Serverの詳細は、「Access Serverの下位互換性」を参照してください。WebGateの詳細は、「WebGate」を参照してください。「暗号化スキーム」も参照してください。
ObSSOCookieを設定した後で、認証アクションを実行させることができます。通常、認証アクションは、認証が処理された後で、ObSSOCookieが設定される前にトリガーされます。しかし、複雑な環境では、ユーザーがリソースを含むページにリダイレクトされる前に、ObSSOCookieを設定できます。この場合、これらのイベントがトリガーされるように認証スキームを構成できます。『Oracle Access Managerアクセス管理ガイド』も参照してください。
リリース6.1.1、6.5および7.xのWebGateは、アップグレードされたAccess Serverと共存できます。アップグレード後の環境に10g（10.1.4.0.1）のWebGateをインストールすることもできます。ただし、10g（10.1.4.0.1）のWebGateには、以前のAccess Serverとの互換性はありません。
以前のリリースに含まれていたWebGateStatic.lstファイルは廃止されました。かわりに、10g（10.1.4.0.1）WebGateでは、『Oracle Access Managerアクセス管理ガイド』で説明されているように、「IPValidation」や「IPValidationException」などのパラメータを構成するためにアクセス・システム・コンソールを使用します。
10g（10.1.4.0.1）よりも前のリリースでは、Cookieの暗号化および復号化はWebGate/AccessGateによって処理されました。これに対して、10g（10.1.4.0.1）からは、Cookieの暗号化と復号化はAccess Serverで処理されます。
10g（10.1.4.0.1）のWebGateとAccessGateが同じコード・ベースを共有するように、WebGateのコードが書きなおされました。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
以前のWebGateは、10g（10.1.4.0.1）のAccess Serverと共存できる場合でも、すべてアップグレードすることをお薦めします。複数の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/AccessGateが含まれるアップグレード後の環境に10g（10.1.4.0.1）のAccess Serverをインストールした場合は、Access Serverに対して下位互換性を手動で構成する必要があります。詳細は、「Access Serverの下位互換性」を参照してください。
