プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11g リリース2 (11.1.2.3) for All Platforms
E61950-08
目次へ移動
目次

前
次

28.2 OpenSSOエージェントとAccess Manager間の実行時の処理

OAMサーバーには、OpenSSOエージェントとの通信を処理するOpenSSOプロキシが組み込まれているため、OpenSSOサーバーとの相互運用性が簡単になります。

たとえば、OpenSSOポリシー・エージェントとOAMサーバーとの間でのシングル・サインオン(SSO)とシングル・サインアウト(SLO)があげられます。相互運用性は、エンドユーザー認証でHTML/HTTP認証リクエストを(HTTPリダイレクトとして)参照し、エンドユーザー・セッションの検証でXML/HTTP SSOリクエストを参照することによって、実現されます。

図28-1は、OpenSSOとAccess Managerが含まれるデプロイメントを示しています。OpenSSOエージェントは、Web/Java EEコンテナおよび保護されているリソースとともに存在します。OpenSSOサーバーは、別のホストに存在します。

図28-1 OpenSSOとAccess Managerが含まれる一般的なデプロイメント

図28-1の説明が続きます
「図28-1 OpenSSOとAccess Managerが含まれる一般的なデプロイメント」の説明

表28-4は、Access ManagerとOpenSSOエージェント間のSSO処理についての説明です。

表28-4 Access ManagerによるOpenSSOの処理

機能 説明

OpenSSOエージェント認証

ユーザー認証の前に、OpenSSOエージェントが認証されて有効なエージェント・セッションが確立されます。

OpenSSOエージェントは、OAMサーバーに対してOpenSSOプロキシ経由で自身を認証します。

OpenSSOエージェント認証(エージェントがOpenSSOプロキシに対して自身を認証)は、エージェント・タイプに基づいて次のように行われます。

  • J2EEエージェント: エージェント・コンテナ起動時。
  • Webエージェント: Webサーバーに対する最初のユーザー認証リクエストによる。
  1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースにアクセスするリクエストを送信します。

  2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるために次のようにOAMサーバーにリダイレクトします。

    • J2EEエージェント: エージェント・コンテナ起動時。
    • Webエージェント: Webサーバーに対する最初のユーザー認証リクエストによる。
  3. エージェントは、ネーミング・リクエストをプロキシに送信し、他のすべてのサービスURL (認証サービス、セッション・サービスなど)をフェッチします。

  4. エージェントは、xml認証リクエストを認証サービス・エンドポイントでの資格証明(ステップ3でネーミング・リクエストにより取得)とともにプロキシに送信します。

  5. プロキシは、エージェント認証モジュールに対してエージェントを認証し、プロキシ・レイヤー自体に無期限セッションを作成します。

  6. プロキシは、httpを介して、認証xmlレスポンスをエージェント・セッション詳細とともにエージェントに送信します。

エージェントが認証されると、有効なエージェント・セッションが作成されます。エージェント認証の後に生成されるキーは、パートナおよびトラスト・ストアに格納されます。

SSOユーザー・ログインおよび認証

エージェントがOAMサーバーにより認証された後、ユーザー・リクエストがOAMサーバーにより認証されます。SSOはその後、エージェントにより保護されているリソースにアクセスする認証済ユーザーに提供されます。

OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを検証します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。

ユーザー・ログイン

  1. OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉します。OpenSSOエージェントは、ユーザーがOpenSSO Cookieを持っているかどうかをチェックします。持っていない場合、OpenSSOエージェントは、ユーザーを認証サービスを得るためにOpenSSOプロキシにリダイレクトします。OpenSSOプロキシは、リクエストされたリソースURLおよびエージェントIDを捕捉します。

  2. OpenSSOプロキシのOpenSSOログイン・イベントは、コア・ログイン・イベントで処理できるように、このリクエストをラップします。OpenSSOログイン・イベントは、リソースURLおよびエージェントIDをコア・ログイン・イベントに渡します。

  3. コア・ログイン・イベントが実行され、リクエスト・オブジェクトにOAM_ID Cookieが含まれるかどうかをチェックします。そうである場合、OAMサーバーは、OAM_ID Cookieで表されるセッションが有効なセッションかどうかをチェックします。

  4. OAM_ID Cookieで表されるセッションが有効な場合、コア・ログ・イベントからログイン・レスポンス・イベントが返されます。これはOpenSSOログイン・イベントでラップされ、OpenSSOログイン・レスポンス・ハンドラに渡されます。コア・ログイン・イベントは、検証されたセッションの識別子を返します。

  5. OpenSSOログイン・レスポンス・ハンドラ(OpenSSOプロキシに含まれます)は、OpenSSOエージェントが理解できる形式でOpenSSOセッション識別子を作成し、OAMセッション識別子を使用して拡張します。OpenSSO Cookieが作成され、ユーザーのブラウザに設定されます。このCookieにはOpenSSOセッション識別子が含まれます。

エンド・ユーザー・セッションの検証

OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉します。

エンド・ユーザー・セッションの検証

  1. OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉し、OpenSSO Cookieを検出します。

  2. OpenSSOエージェントは、このOpenSSO Cookieを検証するためのXML/HTTPリクエストを作成します。このXMLリクエストには、アプリケーション/エージェント・トークンIDおよびセッションIDが含まれます。このリクエストは、OpenSSOプロキシ・レイヤーに届きます。

  3. OpenSSOプロキシはリクエストに関連付けられたアプリケーション・トークンを取得し、アプリケーション・トークンをOAMサーバーを使用して検証します。

  4. OAMサーバーは、トークンを検証し、レスポンスをOpenSSOプロキシに送信します。

  5. アプリケーション・トークンが無効な場合、OpenSSOプロキシはそのことをOpenSSOエージェントに通知し、OpenSSOエージェントは有効なアプリケーション・トークンを取得するためにエージェント認証フローを開始します。

  6. アプリケーション・トークンが有効な場合、OpenSSOプロキシはOpenSSO Cookieを復号化して、OpenSSOセッションIDをフェッチし、OpenSSOセッションIDに拡張として格納されているOAMセッションIDを取得します。

  7. OpenSSOプロキシは、セッション検証フローをトリガーします。

  8. OAMセッションIDで表されるセッションが有効な場合、OpenSSOプロキシはそのことをエージェントに通知し、保護されているアプリケーションがユーザーに表示されます。このセッション検証では、セッション・データを、セッション検証イベント・レスポンスの出力としてプロキシ・レイヤーに返します。

  9. セッションが無効な場合、OAMサーバーが認証フローを開始し、ユーザー資格証明を収集してユーザーを検証します。

Webエージェント・タイプのユーザー・プロファイル属性の取得

ユーザーがログインに成功して、有効なセッションが作成されると、OpenSSOエージェントは、セッションIDを渡すことによって、ユーザー・プロファイル属性をリクエストできます。OpenSSOプロキシ・レイヤーは、このリクエストを受信し、OpenSSOセッションID拡張からOAMセッションIDをフェッチする必要があります。OpenSSO Webエージェントは、これらのリクエストにポリシー・サービスURLを使用します。

OpenSSOプロキシは、これらの属性をフェッチしてセッションIDをOAMサーバーに渡します(OAMサーバーはレスポンス・フレームワークを使用してユーザー・プロファイル属性をフェッチし、データをOpenSSOプロキシに返します)。

J2EEエージェント・タイプのユーザー・プロファイル属性の取得

OpenSSO J2EEエージェントは、jax-rpcコールを使用して、ユーザー・プロファイル属性を取得します。フローは、Webエージェント・タイプの場合のこれらのプロパティを取得するフローと同様です。

ユーザー・シングル・ログアウト

  1. OpenSSOプロキシは、ユーザー・ログアウト・リクエストを受信すると、ユーザーをOAMログアウトURLに転送します。

  2. OpenSSOプロキシはOpenSSO Cookieを復号化して、OpenSSOセッション識別子をフェッチし、そこからOAMセッションIDをフェッチします。OpenSSOプロキシは、ログアウト・リクエストをOAMセッションIDとともに、OpenSSOログアウト・イベントを介して、コントローラに送信します。

  3. コア・ログアウト・イベントが実行され、コントローラ・コールによりセッションが存在することをSSOエンジンに確認します。セッションが存在する場合、OAM_ID Cookieが削除され、グローバル・ログアウトが実行されます。

  4. SSOエンジンは、セッションがクリアされたことを示すレスポンスをコントローラに返します。

  5. コントローラは、プロキシにトークン・クリア・リクエストを送信します。

  6. プロキシは、トークン・クリア・リクエストを、OpenSSOログアウト・レスポンス・ハンドラを介して、エージェントに送信します。

SSOエージェント・ログアウト

Access Managerは、OpenSSOエージェントから送信されたシングル・ログアウト・リクエストを処理します。

ノート: ユーザーは、他のエージェント(たとえば、WebゲートやMOD_OSSO)によって保護されているリソースからログアウトする必要があります。マルチドメイン環境以外では、エージェント・ログアウトは必要ありません。

  1. OpenSSOエージェントは、OpenSSOプロキシにログアウトをリクエストします。

  2. プロキシは、リクエストからアプリケーション・トークンをフェッチし、リクエストが認証済エージェントから送信されていることを検証します。

  3. Openssoエージェント・ログアウトは、独立したエージェント・セッション管理モジュールでセッションが作成されるため、プロキシ内部で処理されます。

  4. 復号化されたトークンがOpenSSOプロキシに返されます。OpenSSOトークンが存在しない場合、ステップ2と3は行われません。

  5. OpenSSOプロキシのOpenSSOログイン・イベントは、コア・ログイン・イベントで処理できるように、このリクエストをラップします。

  6. コア・ログイン・イベントが実行され、リクエストをコントローラを介してSSOエンジンに転送し、ユーザーを認証します。認証されたユーザーのための新しいセッションが作成されます。

  7. コア・ログ・イベントからログイン・レスポンス・イベントが返されます。これはOpenSSOログイン・イベントでラップされ、OpenSSOログイン・レスポンス・ハンドラに渡されます。

  8. OpenSSOログイン・レスポンス・ハンドラは、レスポンスをOpenSSOエージェントに送信します。

OpenSSOエージェントのトークン生成

Access Managerは、OpenSSOエージェント用に生成され、OpenSSOエージェントによって使用されるトークンを処理します。

ロギング

OAMサーバー・ログ・コンポーネントを使用して、次のイベントに対するエンド・ユーザー・アクセス実施中のイベントを追跡できます。

  • ログイン成功およびログイン失敗イベント

  • ログアウト成功およびログアウト失敗イベント

  • 様々なロギング・レベル(FATAL、ERROR、WARNING、DEBUG、TRACE)のログ・メッセージ。降順でそれぞれが重大度を示しています。

監査

OAMサーバー監査コンポーネントを使用して、次を実行します。

  • ログイン・イベントの監査

  • ログアウト成功イベントの監査

ポーリング

ポーリングはサポートされていません。セッション破棄通知のみが、OpenSSOプロキシでサポートされています。