| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章のアクティビティは、スキーマとデータ、アイデンティティ・システム・コンポーネント、アクセス・システム・コンポーネント、統合コンポーネント、SDKおよびカスタマイズのアップグレードが完了した後に実行する必要があります。特に明記されていない場合、この章に記載されている内容はどちらのアップグレード・メソッドにも同様に適用されます。内容は次のとおりです。
アップグレード後、アイデンティティ・システム・コンソールやアプリケーションにアクセスして、これらが使用可能であることを検証するタスクを実行することをお薦めします。これらのタスクの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
|
注意: 停止時間ゼロのアップグレード・メソッドを使用している場合、これらのタスクは、スキーマ、データ、クローン・システムおよび元のシステムのアップグレード後に実行します。詳細は、「環境の正常な動作の検証」を参照してください。 |
アップグレードで影響を受けるCOREidシステムのアプリケーションと機能を特定し、これらをテストする計画を作成します。
アイデンティティ・サーバー・サービスとWebPassのWebサーバー・インスタンスが稼働することを確認します。
適切なURLを指定して、ブラウザからアイデンティティ・システム・コンソールに移動します。次に例を示します。
http://hostname:port/identity/oblix
ここで、hostnameはWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはアイデンティティ・システム・コンソールに接続します。
Oracle Access Managerのランディング・ページが表示されます。
ランディング・ページが表示されない場合: 情報を正確に指定したかどうかを確認します。付録Gのトラブルシューティングのヒントを参照してください。
次に示すタスクを実行して操作を検証し、各自のテスト計画を参考として使用します。
「アイデンティティ・システム・コンソール」→「システム構成」→「ディレクトリ・プロファイル」→link_to_this_profileを選択して、このアイデンティティ・サーバーのディレクトリ・サーバー・プロファイルを表示します。
ユーザー・マネージャ、グループ・マネージャ、組織マネージャで、パネルを設定します。
ユーザー・マネージャでオブジェクトベースの検索ベースを設定します。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、アクセス制御を設定します。
ワークフロー定義を作成します。
メール・サーバーやセッション設定などのオプションを構成します。
アクセス・システムのスキーマとデータが正常にアップグレードできたことを検証するために、次のステップのいずれかを完了してください。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
|
注意: 停止時間ゼロのアップグレード・メソッドを使用している場合、これらのタスクは、スキーマ、データ、クローン・システムおよび元のシステムのアップグレード後に実行します。詳細は、「環境の正常な動作の検証」を参照してください。 |
アップグレードで影響を受けるアクセス・システムの機能を特定し、これらをテストする計画を作成します。
ポリシー・マネージャのWebサーバー、およびWebPassのWebサーバーのインスタンスが実行されていることを確認します。
適切なURLを指定して、ブラウザからアクセス・システム・コンソールに移動します。次に例を示します。
http://hostname:port/access/oblix
ここで、hostnameはWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはアクセス・システム・コンソールに接続します。
Oracle Access Managerのランディング・ページが表示されます。
ランディング・ページが表示されない場合: 情報を正確に指定したかどうかを確認します。付録Gのトラブルシューティングのヒントを参照してください。
ポリシー・マネージャまたはアクセス・システム・コンソールに、マスター管理者としてログインします。
次のタスクを実行し、各自のテスト計画を参照してアクセス・システムが適切に動作していることを確認します。具体的には次のとおりです。
スキームに対応するリンクをクリックして認証スキームの構成詳細を表示すること。
ポリシー・ドメインを定義または変更すること。
アクセス・システム・コンソールの内容を表示すること。
保護されたリソースにアクセスし、ログインの動作を確認すること。
通常どおりログアウトします。
停止時間ゼロのアップグレードを実行した場合やインプレース・アップグレード時にユーザー・データのオンザフライ移行を停止しなかった場合は、この項をスキップしてください。
インプレース・アップグレードを実行した場合、および次の場合にのみ、ここで示す手順を使用してユーザー・データのオンザフライ移行を再実行します。
第5章の説明に従って、ユーザー・データの即時（オンザフライ）移行を一時停止した場合。ユーザー・データのオンザフライ移行を停止しなかった場合は、この手順をスキップしてください。
アップグレードしたデプロイが予定どおりに動作することを検証し、以前のリリースへのロールバックが不要であることを検証した後。
次の手順では、チャレンジとレスポンスに使用される属性を、タブ・レベルとオブジェクト・クラス・レベルの両方で再構成する必要があります。
|
注意: 停止時間ゼロのアップグレード・メソッドを使用してアップグレードを実行した場合、このアクティビティはスキップしてください。 |
タブ・レベル: 「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、次のようにタブ・レベルで再構成します。
アイデンティティ・システム・コンソールをクリックして、「ユーザー・マネージャ構成」→「タブ」をクリックします。
リストから「従業員」を選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストからチャレンジに使用される属性を選択し、「セマンティク型」を「チャレンジ」に、「表示タイプ」を「単一行テキスト」に設定して、「保存」をクリックします。
「属性」リストからレスポンスに使用される属性を選択し、「セマンティク型」を「レスポンス」に、「表示タイプ」を「パスワード」に設定して、「保存」をクリックします。
「完了」をクリックします。
オブジェクト・クラス・レベル: 「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、次のようにオブジェクト・クラス・レベルで再構成します。
アイデンティティ・システム・コンソールをクリックして、「共通構成」→「オブジェクト・クラス」をクリックします。
リストから人オブジェクト・クラスを選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストからチャレンジに使用される属性を選択し、「セマンティク型」を「チャレンジ」に、「表示タイプ」を「単一行テキスト」に設定して、「保存」をクリックします。
「属性」リストからレスポンスに使用される属性を選択し、「セマンティク型」を「レスポンス」に、「表示タイプ」を「パスワード」に設定して、「保存」をクリックします。
「完了」をクリックします。
oblixConfig（LDAPディレクトリ・サーバーの構成データのルート・ノード）のobVer属性を次のように10.1.4.0に設定します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
作成されるLDIFファイルの形式は次のとおりです。これはNetscape Directory Serverの場合の例です。
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 10.1.4.0
アップグレードしたアイデンティティ・サーバーとアクセス・サーバーをすべて再起動します。
アクセス・システムのアップグレードに使用したメソッドを問わず、ディレクトリ・サーバーに格納されたポリシー・データへの書込み権限をアクセス・サーバーに与えるため、管理者は一時ディレクトリ・プロファイルを作成しました。この一時ディレクトリ・プロファイルは、アクセス・サーバーがWebGatestatic.lstファイルに含まれる構成情報を収集し、WebGateのアップグレード時にディレクトリ・サーバーを更新する際に必要でした。
|
注意: 使用環境内の以前のWebGateがすべてアップグレードされ、動作検証が完了するまではこのタスクを実行しないでください。 |
以前のWebGateをすべてアップグレードし、アップグレードしたWebGateが正常に動作することを確認した後は、この一時ディレクトリ・サーバー・プロファイルを削除できます。
アクセス・コンソールで、「システム構成」タブをクリックします。
「サーバー設定」をクリックします。
「LDAPディレクトリ・サーバー・プロファイルの構成」セクションで、削除するプロファイルのチェック・ボックスをクリックします。
「削除」をクリックします。
以前のすべてのカスタム・プラグインおよびWebGateのアップグレードが正常に完了し、下位互換性が不要になった場合、次の「下位互換性の回復」に進みます。
使用したアップグレード・メソッドを問わず、以前のアイデンティティ・サーバーおよびアクセス・サーバーのアップグレードの際は、以前のカスタム・プラグイン（およびWebGate、アクセス・ゲート）との下位互換性が自動的に有効になっていました。
以前のプラグイン、WebGateおよびアクセス・ゲートをすべてアップグレードし、システム全体のアップグレードが正常に完了したことを確認した後、下位互換性を無効にする（回復する）ことをお薦めします。
下位互換性を回復するために必要なステップは、下位互換性を手動で有効化した手順と類似しています。詳細は、次を参照してください。
カスタム・アイデンティティ・プラグインがUTF-8をサポートするように拡張した後は、この手順のステップを使用環境内の各アイデンティティ・サーバーで実行します。このステップは、下位互換性を手動で有効にした場合も、自動的に有効になった場合も共通です。
アイデンティティ・システムのカスタマイズをすべてアップグレードします（第12章を参照）。
アップグレードされたすべてのアイデンティティ・システムのカスタマイズを再デプロイし、意図したとおりに動作していることを確認します。
IdentityServer_install_dir\identity\oblix\apps\common\bin\oblixpppcatalog.lstにあるアイデンティティ・サーバーのoblixpppcatalog.lstファイルを探して開きます。
ApiVersionフラグ（存在する場合）の後でエンコーディング・フラグをLatin-1からencodingに設定し、Latin-1データに対する下位互換性を確立します。次に例を示します。
変更前:
userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;Latin-1
変更後:
userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;encoding
必要に応じて、このファイルのエントリに対して同じ処理を繰り返します。
ファイルを保存します。
アイデンティティ・サーバー・サービスを再起動します。
アップグレードした環境でアイデンティティ・サーバーごとに下位互換性の回復手順を繰り返します。
カスタム・アクセス・システムのプラグインがUTF-8をサポートするように設計が変更されたことを確認し、すべてのWebGateおよびアクセス・ゲートが正常にアップグレードされた後は、下位互換性は不要です。この場合、すべてのアクセス・サーバーのglobalparams.xmlファイルにおいて、"IsBackwardCompatible" Value="false"と手動で設定することをお薦めします。
下位互換性が自動的に有効になった場合も、手動で有効にした場合も、使用環境内のすべてのアクセス・サーバーに対してこの手順を実行してください。
アクセス・システムのカスタマイズをすべてアップグレードします（第13章を参照）。
アップグレードされたすべてのアクセス・システム・カスタマイズを再デプロイし、意図したとおりに動作していることを確認します。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xmlにあるアクセス・サーバーのglobalparams.xmlファイルを探して開きます。
"IsBackwardCompatible" Value="false"を設定します。具体的には次のとおりです。
<SimpleList
<NameValPair
ParamName="IsBackwardCompatible"
Value="false">
</NameValPair>
</SimpleList>
ファイルを保存します。
アクセス・サーバー・サービスを再起動します。
アップグレードした環境でアクセス・サーバーごとに手順を繰り返します。
