| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
前 |
次 |
既存のOracleAS SSO 10gリリース(10.1.2.0.2)をOracleAS SSO 10gリリース(10.1.4.3.0)を経由してOracle Access Manager 11gにアップグレードできます。この章では、Oracle Access Manager 11g SSOを使用するためにOracleAS 10g SSO (OSSO)をアップグレードするときに提供される共存について説明します。内容は、次のとおりです。
アップグレード手順については、『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』を参照してください。
「アップグレード」という用語は、Oracle製品のバージョンおよびテクノロジ間の移動を指すときに使用します。たとえば、OC4JからOracle WebLogic Serverへの移動はアップグレード、OracleAS 10g SSOからOAM 11g SSOへの移動もアップグレードになります。
|
注意: 「移行」という用語は、Oracle以外のテクノロジ・スタックからOracleのテクノロジ・スタックへの移動に使用します。 |
Oracleが提供するアップグレード・アシスタントは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーム情報を入力として受け入れ、構成されたパートナ・アプリケーションを目的のOracle Access Manager 11g SSOへ転送します。
|
関連項目: Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド |
通常のOSSOデプロイメントには、フロントエンド・ロード・バランサを含むOSSOが多数含まれます。クラスタ内のすべてのOSSOサーバーには同じバックエンド・ストアが含まれます。ロード・バランサは認証要求をクラスタ内のOSSOサーバーにルーティングします。
共存には、OAM 11gとOSSO 10gが同じバックエンド・ユーザー・アイデンティティ・ストアであるOracle Internet Directory(OID)を使用することが必要です。OAM 11gは1つのOSSOサーバーまたはOSSOサーバーのクラスタと共存します。動的リダイレクトはOSSO 10gおよびOAM 11gにより保護されているアプリケーションの予想通りに動作する必要があります。
アップグレード・プロセス中に、OSSO 10gに登録されたパートナ・アプリケーションは関連するOracle HTTP Server Agent、対応するホスト識別子、およびその他の詳細とともにOAM 11gに転送されます。OAM 11gは既存のOSSO 10gサーバーのフロントエンド・ロード・バランサに追加されます。
|
注意: 既存のOSSO 10g構成に、直接マップできない、即時利用可能な構成が含まれている場合、自動的なアップグレード・プロセスの終了後に、管理者はこれらを手動で転送する必要があります。 |
アップグレード後、OAM 11gは1つのOSSOサーバーまたはOSSOサーバーのクラスタと共存します。既存のパートナ・アプリケーション(Portal、Forms、ReportsおよびDiscovererなど)はSSOプロバイダとしてOracle Access Manager 11gの使用を開始します。ロード・バランサはOAMサーバーへの認証要求の一部をルーティングし、残りは既存のOSSO 10gサーバーによりサービスが継続されます。ユーザーがOSSO 10gまたはOAM 11gサーバーのいずれかにより認証されると、再認証を必要とせずにパートナ・アプリケーションにアクセスできます。
詳細は、「アップグレード前および後のトポロジおよび認証の例」を参照してください。
この項の内容は次のとおりです。
通常のOSSO設定には、フロントエンド・ロード・バランサのあるOSSOが多数含まれます。クラスタ内のすべてのOSSOサーバーには同じバックエンド・ユーザー・アイデンティティ・ストアがあります。図A-1に示すように、ロード・バランサは認証要求をクラスタ内のOSSOサーバーにルーティングします。
図A-2に、OHS(パートナ)が保護されているアプリケーションのフロントエンドとなっている簡単な状況を示します。OHS(OSSO)はOC4J OSSOアプリケーション・サーバー・ホストを保護するフロントエンド・プロキシWebサーバーです。これは内側にOSSO OC4Jサーバーがある場合にのみ必要です。
アップグレード後、環境はOracle Access Manager 11gを認証用に使用するように構成されます。
OAM 11gへのアップグレードは、新しいOAM 11gサーバーのインストールと、このOAMサーバーへのパートナ・アプリケーションの転送から開始します。
既存のOSSOサーバーの1つが停止されます。OAM 11gサーバーは停止したOSSOサーバーを置き換え、ロード・バランサは新しく追加されたOAM 11gサーバーへの認証要求のルーティングを開始します(残りのOSSO 10gサーバーへの認証要求のルーティングは継続します)。
|
注意: 時間の経過とともに各OSSO 10gサーバーはOAM 11gサーバーに置き換えられる必要があります。 |
アップグレードされたOSSOの設定を図A-3に示します。
ユーザーがパートナ・アプリケーションにシングル・サインオンでアクセスできるようにするために、OAM 11gは認証ユーザーとしてOSSOサーバーにより認証されたユーザーを受け入れます。また、OAM 11gがユーザーを検証する場合、OSSOサーバーが理解できる適切なcookieも設定します。OSSOサーバーは再度ユーザーを検証する必要はありません。
ユーザーがOSSO 10gまたはOAM 11gのいずれかにより認証されると、いずれかのサーバーにより保護されているすべてのパートナ・アプリケーションにアクセスできます。OAM 11gおよびOSSO 10gはシングル・サインオンを実現するために適切なcookieを設定します。
OAM 11gは各要求に対するセッションを作成し、そのセッションIDを含むcookieを設定します。このcookieにより表されるセッションには、その他の詳細の中の認証されたユーザーのJAASサブジェクトが含まれます。
|
注意: OSSO 10gでは、サーバーはログイン・ユーザーに関する情報を含むホストcookieを設定します。 |
詳細は、次を参照してください。
アップグレード後の観点からすると、Oracle Access Manager 11gは認証のために使用されます。OSSO 10gサーバーのフロントエンドとなっているOracle HTTP Serverは、Oracle Access Manager 11gがインストールされているOracle WebLogic Serverを指します。つまり次のことを表しています。
OHSパートナ: mod_ossoはプロキシ経由で認証のために11g OAMサーバーに要求をリダイレクトします。
プロキシ: mod_wlはmod_oc4jを置き換えます。mod_wlにより、Oracle HTTP Server側で何も変更することなく、シングル・サインオンを動作させることができます。
図A-4に、mod_oc4jを置き換えるmod_wlを含むアップグレード後のトポロジを示します。
この例では、以前mod_oc4jを含んでいたプロキシ・サーバーが完全に消去されています。10g OSSOサーバーのフロントエンドとなっているOracle HTTP Serverは、Oracle Access Manager 11gがインストールされているOracle WebLogic Serverを直接指します。
図A-5に、ほとんどのデプロイメントで使用している、このトポロジを示します。
この項の内容は次のとおりです。
図A-6に、OAM 11gとOracleAS 10g SSOが共存するアップグレードされた環境での、OAM 11g SSOによる認証を示します。詳細は、図の後に説明します。
処理の概要: パートナ・アプリケーション間のシングル・サインオン
ユーザーはOSSO 10gからOAM 11gにアップグレードされたパートナ・アプリケーションにアクセスします。
ロード・バランサはユーザーの認証要求をOSSO 10gサーバーにルーティングし、そこでログイン・ページが提供されます。認証が正常に終了すると、OAMはSSO cookieを設定し、それに従ってセッション情報を更新します。cookieには、このcookieが有効であるためにOSSO cookieも存在する必要があることを示すフラグが含まれます。
ユーザーがOSSO 10gにより保護されているアプリケーションを使用し、OSSO 10g cookieがすでにブラウザに設定されている場合、ユーザーは資格証明を要求されず、アプリケーションにアクセスできます。
OAM 11gおよびOSSO 10gの両方のcookieは一致している必要があります。OSSO 10g cookieで更新されたセッション情報は、OAM 11g cookieと同期している必要があり、逆も同様です。
図A-6に示すように、ユーザーはパートナ・アプリケーションにアクセスし、ユーザーの認証要求はロード・バランサによりOSSO 10gにルーティングされます。ここで、OSSOサーバーはログイン・ページを表示し、ユーザーの資格証明を収集および検証後、OSSO cookieのみがユーザーのブラウザに設定されます。
処理の概要: アップグレード後のOSSO 10g認証
ユーザーがOAM 11gサーバーにより保護されているパートナ・アプリケーションにアクセスする場合、OAMサーバーはログイン・ページを表示する前に、まず有効なOSSO cookieがすでに存在するかどうかをチェックする必要があります。
有効なOSSO cookieがすでに存在する場合、OAM 11gサーバーはOSSO cookieからOAM 11g SSO cookieを作成する必要があります。OAMサーバー構成には、共存モードが有効かそうでないかを示すフラグがあります。共存モードが有効な場合、OAMサーバーはOAM 11gサーバーのSSO Cookieとともに存在するOSSO cookieを探します。このフラグは構成で手動でオンにした後にサーバーを再起動するか、または、WLSTコマンドを使用して共存フラグをオンおよびオフにできます。
ユーザーがパートナ・アプリケーションからログアウトして、ログアウト・リクエストが10g OSSOサーバーにルーティングされると、OSSOサーバーはOSSO cookieを削除します。共存が有効で、10g SSOおよび11g OAMサーバーの両方がロードバランサの背後にある場合、パートナ情報はすべてのサーバー(10g OSSOまたは11g OAMサーバー)で共有されます。そのため、パートナ・アプリケーションを含むサーバー(10gまたは11g)のいずれかと関連付けることは正しくありません。アップグレード中に、すべてのパートナ情報も11g OAMサーバーに移行されます。
OSSO Cookieが削除された後、ユーザーが保護されているアプリケーションにアクセスしようとして、その要求がOAM 11gサーバーに到達した場合、OAMサーバーのSSO Cookieのみが見つかります。構成での共存フラグから、設定が共存モードになっていることをサーバーが認識します。共存モードでは、OSSO cookieはOAM11gサーバーCookieが有効であるために存在している必要があります。したがって、ログイン・ページがスローされ、ユーザーは検証を求められます。
OAM 11gサーバーはOSSOおよびOAM cookieの両方のセッション情報が必ず一致するようにする必要があります。
この項の内容は次のとおりです。
次の各項目で、転送されたOSSO 10gの詳細をOracle Access Managerコンソールで探す際に役立つ情報を提供します。
OSSO 10gを使用するパートナ・アプリケーションのサンプルの詳細を示し、OSSO 10g構成とOracle Access Manager 11g用のアップグレードされた構成を比較できます。
表A-1に、OracleAS 10g OSSOにより保護されているアプリケーションを示します。
表A-1 OSSO 10gにより保護されているパートナ・アプリケーション
| アプリケーション名 | ホスト | Oracleホーム |
|---|---|---|
|
oid1_ad2003_lowenthal.vm |
ad2003.lowenthal.vm |
C:\oracle\oid |
|
portal1_ad2003_lowenthal.vm |
ad2003.lowenthal.vm |
C:\oracle\portal |
|
Oracle Portal(ポータル) |
ad2003.lowenthal.vm |
C:\oracle\portal |
各アプリケーションのOSSO 10g構成詳細には、管理者が割り当てた次のものが含まれます。
名前
ホームページURL
成功URL
ログアウトURL
サーバーにより許可されたアプリケーションへのログインの日付範囲
OSSO 10g構成には次のものも含まれます。
一意のアプリケーションID
認証の要求時にパートナにより使用されるアプリケーション・トークン
アプリケーションの識別のためにOSSOサーバーが使用する暗号化鍵
ログインURL
シングル・ログアウトURL
OracleAS 10g SSOデプロイメントの各アプリケーション(表A-1)に対し、Oracle HTTP Serverインスタンスがあります。各OHSインスタンスはアプリケーションに由来する名前のOSSOエージェントとして転送します。Oracle Access Managerコンソールで、ナビゲーション・ツリーの「エージェント」ノードの「システム構成」タブで、転送された各OSSOエージェントの構成を探すことができます。
このトピックの図で、表A-1で識別されるアプリケーションに対する転送されたOSSOエージェント構成を示します。生成された各エージェント構成は、それを保護するアプリケーションとして名前が付けられます。
10gアプリケーションIDはOAM 11gのエージェント構成に記録されませんが、次に示すほとんどの構成詳細は含まれていて、同じままです。
サイト・トークン: アプリケーション・トークンです。
ログインURL
シングル・ログアウトURL
成功URL
失敗URL
開始日
図A-8にOSSO 10gにより保護されているアプリケーション用に生成されたエージェント構成を示します。詳細は自動化されたアップグレード処理中にOSSO 10g Oracle Internet Directoryから導出されました。
図A-9に、OracleAS 10g SSO (OSSO)により保護されている2番目のアプリケーションに対する転送された構成を示します。
図A-10に、OracleAS 10g SSO (OSSO)により保護されている3番目のアプリケーションに対する転送されたOSSOエージェント構成を示します。
図A-11は、転送されたホスト識別子を示します。使用されるアプリケーション・ドメイン名であるという理由で、これにはmigratedSSOPartnersという名前が付けられています。詳細は自動化された転送処理中にOSSO 10g Oracle Internet Directoryから導出されました。
図A-12に、転送およびリソースの定義中に作成されたアプリケーション・ドメインを示します。詳細は自動化された転送処理中にOSSO 10g Oracle Internet Directoryから導出されました。
アプリケーション・ドメインおよびリソース定義の両方にmigratedSSOPartnersという名前が付けられます。
図A-13に、アプリケーション・ドメインmigratedSSOPartnersのProtected Resource Policyという名前の認証ポリシーを示します。
デフォルトのOAM 11g認証スキームLDAPSchemeが使用されます。
次の手順を使用して、Oracle Access Manager 11gを使用してアップグレードされた環境で、シングル・サインオンが発生していることを確認できます。
「Oracle Access Managerにより保護されるリソースを含むアップグレード後のSSOの検証」の手順を実行して、OAM 11gにより保護されるリソースがOAM 11gを介してアクセスされていることを確認します。
SSOがOracle Access Manager 11gとともに動作することを確認する手順
10g OSSOサーバーをホストしているコンピュータのOracle HTTP Serverを停止します。
11g OAMサーバーを再起動します。
Oracle Access Managerコンソールで、次のことを行います。
システム構成、エージェント: アップグレードした10gパートナ・アプリケーションに適切なエージェント構成が含まれていることを確認します。
ポリシー構成、共有コンポーネント:新しいホスト識別子の定義migratedssopartnersが作成されたことを確認します。
ポリシー構成、アプリケーション・ドメイン:
新しいアプリケーション・ドメインmigratedssopartnersが作成されたことを確認します。
新しいアプリケーション・ドメインで、migratedssopartners用のリソースが存在することを確認します。
新しいアプリケーション・ドメインで、認証ポリシーProtected Resource Policyが適切なホスト識別子で存在することを確認します。
パートナ・アプリケーションにアクセスし、認証がOracle Access Manager 11gを介して発生することを確認します(11g用のログイン・フォームを確認)。
次の手順を行います。
成功: 「OSSOにより保護されるリソースを含むアップグレード後のSSOの検証」を使用して続行します。
不成功: 必要なすべての手順が完了しているかどうかを確認します。
次の手順を使用して、OSSO 10gにより保護されるリソースおよびOracle Access Manager 11gにより保護されるリソースを含む環境でのアップグレード後に、シングル・サインオンが発生していることを確認できます。
OSSOにより保護されるリソースを含むアップグレード後のSSOの確認手順
OAMにより保護されるリソース: 「Oracle Access Managerにより保護されるリソースを含むアップグレード後のSSOの検証」の手順を実行して、OAM 11gにより保護されるリソースがOAM 11gを介してアクセスされていることを確認します。
OSSOにより保護されるリソース: 次の手順を実行して、OSSOにより保護されるリソースがOSSO 10gを介してアクセスされていることを確認します。
OAMサーバーを停止します。
10g OSSOサーバーをホストしているコンピュータでOracle HTTP Serverを再起動します。
OSSOにより保護されるリソースにアクセスして、10g OSSOサーバーが認証されていることを確認します(10g OSSOログイン・ページ)。
OAMサーバーを再起動します。
