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

前
次

29.1 Access Manager使用時のOSSOエージェントの理解

ここでは、次のトピックについて説明します。

29.1.1 Access Manager使用時のOSSOエージェントについて

mod_ossoモジュールは、シングル・サインオン・サーバーの唯一のアプリケーションとして機能することで、認証プロセスを簡易化するOracle HTTP Serverモジュールです。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。 これにより、OracleAS Single Sign-Onで保護されたアプリケーションは、ユーザーのログイン後に、ユーザー名とパスワードのかわりにHTTPヘッダーを受け入れるようになります。これらのヘッダーの値がmod_osso Cookieに格納されます。

これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。ユーザーの認証後、mod_ossoは、ユーザーの認可にアプリケーションで使用される可能性のある単純なヘッダー値を送信します。

  • ユーザー名

  • ユーザーGUID(グローバル・ユーザー・アイデンティティ)

  • 言語および地域

Access Managerに登録すると、OSSO 10gエージェントは、OSSOプロキシを通じてAccess Manager 11gのサービスと直接通信できるようになります。OSSOプロキシは、Access Managerへのアップグレード時に既存のOSSOエージェントをサポートします。このプロキシは、OSSOエージェントからのリクエストを処理して、OSSOプロトコルをAccess Manager 11g認証サービスのプロトコルに変換します。

OSSOプロキシは、Access ManagerエージェントとOSSOエージェント間の相互運用性をサポートします(OSSOエージェントを使用して、Webゲートまたはアクセス・クライアントのために作成された有効なSSOセッションにアクセスしたり、Webゲートまたはアクセス・クライアントを使用してOSSOエージェントのために作成された有効なSSOセッションにアクセスしたりします)。

OSSOプロキシのサポート対象 説明

SSOログイン

OSSOエージェントからOAMサーバー(およびOSSO固有のトークン)

SSOログアウト

OSSOエージェントからOAMサーバー

OSSOエージェントのリクエストおよびプロトコル

OSSOプロキシは、OSSOプロトコルをAccess Manager用のプロトコルに変換します。

10g mod_ossoをエージェントとして登録した後、Access Managerはリソースに定義されたOAMポリシーに関連付けられた認証スキームに基づいて、mod_ossoにユーザーのためのリダイレクトURLを渡します(表29-1)。

表29-1 Access Manager使用時のOSSOエージェント

OSSOエージェント Access Manager

有効な既存のOracle HTTP Server Cookieを確認

必要に応じてOAMサーバーにリダイレクトし、認証中にディレクトリに連絡します。

OSSOサーバーから移入された暗号化されたユーザー・アイデンティティを復号化

ヘッダーにユーザー属性を設定

29.1.2 Access Manager 11g SSOとOSSO 10gの比較

この項では、Access Manager 11gのシングル・サインオン・ポリシーを実装および施行する主要コンポーネントをOSSO 10gと比較しながら説明します。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。OracleAS SSO 10gは認証のみ提供します。

表29-2に、これらの違いについての概要を示します。

表29-2 11g Access Manager SSOとOSSO 10gコンポーネントの概要

コンポーネントの説明 11g Access Manager OSSO 10g

Oracle Identity Managementインフラストラクチャ

エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。

エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。

エージェント

依存するパーティとともに存在し、認証および認可タスクをOAMサーバーに委任します。

  • 11g OAMエージェント

  • 10g OAMエージェント

  • 10g OSSOエージェント(mod_osso)

  • OpenSSOエージェント

ノート: 9つの管理者言語がサポートされています。

  • mod_osso (パートナ)

    ノート: mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。

サーバー

ノート: 管理ユーザーは、https://host:port/oamconsoleのURLを入力して、コンソールのホームページにアクセスできます。

管理外ユーザーは、SSOログイン・ページを戻すアプリケーションのURLを入力して、シングル・サインオン・サーバーに最初にアクセスします。

  • OAMサーバー

  • Oracle Access Managementコンソール(WebLogic管理サーバーにインストール)

関連項目:

「Oracle Access Managementコンソールの理解」

「資格証明コレクションおよびログインの理解」

  • OracleAS SSOサーバー(OSSOサーバー)

関連項目:

プロキシ

レガシー・システムのサポートを提供します。

  • OAMプロキシは、レガシー・アクセス・サーバーとしてレガシーAccess Manager実装をサポートします。

  • OSSOプロキシは、レガシーOSSOサーバーとしてOSSOエージェントをサポートします。

  • Oracleは、OpenSSOエージェントによって保護されているリソースへのリクエストを処理するOpenSSOプロキシを提供しています。

  • OSSOプロキシは、レガシーOSSOサーバーとしてレガシーSSO実装をサポートします。

コンソール

Oracle Access Managementコンソール

Access Manager 11g以前に同等のコンソールはありません。

インターネット上での情報交換の保護に使用されるプロトコル。

エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS

11g Webゲートでは、エージェント・キーを使用して情報交換が保護されます。

-関連項目: 暗号化キー

該当なし

ポリシー・ストア

データベース

mod_ossoおよびパートナ・アプリケーション

アプリケーション

認証および認可をAccess Managerに委任して登録されたエージェントからヘッダーを受け入れるアプリケーション。

ノート: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。

認証をmod_ossoおよびOracleAS Single Sign-Onサーバーに委任するアプリケーション。

ノート: Access Manager 11gでmod_ossoを登録した後、mod_ossoは認証をOAMに委任します。

mod_ossoモジュールを使用すると、ユーザーのログイン後に認証されたユーザー情報をアプリケーションで受け入れることができます。登録されたOSSOエージェントからヘッダーを受け入れて、再認証を回避します。

アプリケーションは、認証されたユーザーがアプリケーションの使用を認可されているかを判別します。

SSOエンジン

セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。

Access Manager 11gによって登録されたエージェントを使用します。

  • 認証(資格証明コレクション)は、HTTP (HTTPS)チャネルで発生します。

  • 認可は、Oracle Accessプロトコル(OAP)チャネルで発生します。

  • mod_ossoは、認証のみを委任して、HTTPチャネルのみで通信します。

暗号化キー

  • 11gエージェントの登録中、エージェントのキーが生成され、OAMサーバーとも共有されます。

    キーは、SSO Cookieの暗号化および復号化に使用されます。

  • 10gエージェントの登録時、Access Manager 11g全体にわたる(すべてのエージェントとOAMサーバー)グローバル共有秘密キーが生成されます。

  • OSSOエージェントの登録時、mod_ossoとOSSOサーバー間でパートナごとに1つのキーが共有されます。

  • OpenSSOエージェントのホストまたはドメイン・ベースのキーは、エージェント・ホストのブートストラップ・ファイル内にローカルに保存されます。

  • OAMサーバーのインストール中、1つのOAMサーバー・キーが生成されます。

ノート: 登録されたmod_ossoエージェントごとに1つのキーが生成され、使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

  • mod_ossoおよびOSSOサーバー間で共有されるパートナごとの1つのキー

  • OSSOサーバー固有のキー

  • GITOドメインCookieのOSSO設定ごとの1つのグローバル・キー

キー・ストレージ

  • エージェント側: エージェントごとのキーは、ローカルでウォレット・ファイルのOracleシークレット・ストアに格納されます。

  • OAMサーバー側: エージェントごとのキーとサーバー・キーは、サーバー側の資格証明ストアに格納されます。

  • セキュリティ・トークン・サービス

  • mod_osso側: パートナ・キーおよびGITOグローバル・キーが曖昧な構成ファイルにローカルに格納されます。

  • OSSOサーバー側: パートナ・キー、GITOグローバル・キーおよびサーバー・キーがすべてディレクトリ・サーバーに格納されます。

Cookie

関連項目: 表21-6

および

「ユーザー・ログイン時のシングル・サインオンCookie」

ホストベースの認証Cookie:

  • 11g Webgate、エージェントごとに1つ: OAMAuthnCookie_<host:port>_<random number>

  • 10g Webgate、すべての10g Webgateに対してObSSOCookieを1つ。

  • OAMサーバーに1つ: OAM_ID(表21-6)

  • ホストベースの認証Cookie:

    パートナごとに1つ: OHS-host-port

    OSSOサーバーに1つ: (Access Manager 11gの使用なし)

  • 対応している場合、グローバル非アクティビティ・タイムアウト(GITO)のドメインレベルのセッションCookie

ポリシー

登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。

mod_ossoは、Access Manager 11g認証ポリシーのみを使用して、定義されたリソースのアクセスを取得するユーザーを決定します。

mod_ossoは、認証のみを提供します。

クライアントIP

  • このクライアントIPを保守管理して、それをホスト・ベースのOAMAuthnCookieに含めます。

  • 元のクライアントIPをホストのCookie内に含めます。

    後の認証リクエストでCookieが提示されると、元のクライアントIPとプレゼンタのIPが比較されます。

    一致しない場合は拒否されます。

暗号化/復号化(暗号化されたデータを元の形式に変換する)

クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。

  1. Webgateは、エージェント・キーを使用してobrareq.cgiを暗号化します。

    ノート: obrareq.cgiは、WebgateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

  2. OAMサーバーは、リクエストを復号化して認証し、セッションを作成してサーバーcookieを設定します。

  3. また、OAMサーバーはエージェントの認証トークン(エージェント・キーを使用して暗号化)を生成し、セッション・トークン(cookieベースのセッション管理を使用する場合)や認証トークン、その他のパラメータを使用してそれをobrar.cgiにパックしてから、エージェント・キーを使用してobrar.cgiを暗号化します。

    ノート: obrar.cgiは、OAMサーバーからWebgateにリダイレクトされた認証レスポンス文字列です。

  4. Webgateはobrar.cgiを復号化して、認証トークンを抽出し、ホスト・ベースのCookieを設定します。

暗号化はmod_ossoおよびOSSOサーバーの両方で実行されます。

  1. site2pstoreトークン(mod_ossoからサーバーへのリクエスト)は、mod_ossoでパートナ・キーを使用してローカルで暗号化されます。

  2. OSSOサーバーは、site2pstoreトークンを復号化して認証を行い、独自のcookieを生成します。

  3. urlcトークン(OSSOサーバーからmod_ossoへのレスポンス)は、サーバーでパートナ・キーを使用して暗号化されます。

  4. mod_ossoはurlcトークンをローカルで復号化し、独自のフォーマットを使用して再び暗号化してホスト・ベースのcookieに設定します。

セッション管理

  • セッション・アイドル・タイムアウトの動作は、11gセッション管理エンジン(SME)によりサポートされています。

  • グローバルな非アクティブのタイムアウト(GITO)のドメイン・レベルのcookieによって、単一のドメインがサポートされます。

    マルチドメインSSO: ユーザーがあるドメインにログインした後で、別のドメインに移動すると、最初のドメインではアイドル状態と見なされます。元のドメインで、アイドルのタイムアウトになると、そのユーザーは元のドメインで再度認可される必要があります。

レスポンス・トークンの再生防止

  • レスポンス・トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をobrareq.cgiに含めて、それをobrar.cgiにコピーします。

  • トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をsite2pstoreトークンに含めて、それをurlcトークンにコピーします。

複数のネットワーク・ドメインのサポート

Access Manager 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。

この場合は、Oracle Federationを使用することをお薦めします。

該当なし

集中ログアウト

  • logOutUrls (10g Webgateの構成パラメータ)は保持されています。10g logout.htmlには、Access Manager 11g固有の詳細情報が必要です。

  • 11g Webgateには次の新しいパラメータが追加されています。 ログアウト・リダイレクトURL

    Logout Callback URL

    Logout Target URL

「11g Webゲートが関与するセッションの集中ログアウトの構成」を参照してください。

mod_osso (OSSOエージェント)を持つAccess Manager 11gでは変更は必要ありません。

動的ディレクティブを使用するアプリケーションは、mod_osso.confにエントリを必要としません。かわりに、1つまたは複数の動的ディレクティブとして保護がアプリケーションに書き込まれます。

「11g Webゲートが関与するセッションの集中ログアウトの構成」を参照してください。