30.3 Access Manager 11.1.2と10gの比較

この項では、Access ManagerおよびOSSOの10gアーキテクチャとの比較について説明します。

次のトピックが含まれます。

30.3.1 Access Manager 11gと10gの比較

Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11g(ユーザー・セルフサービス、セルフ登録、ワークフロー機能、動的グループ管理、委任されたアイデンティティ管理を含む)に移管されたという点で、10gとは異なります。

Access Manager 10gは、認証レベルが同じかより低いターゲット・リソースへのアクセスに必要なユーザー・アイデンティティおよびセッションの情報を含む単一のセッションcookie (ObSSOCookie)を使用して、シングル・サインオンをサポートしていました。ObSSOCookieは、グローバル共有の秘密キーを使用して暗号化、復号化され、秘密キーの値はディレクトリ・サーバーに格納されていました。ObSSOCookieは、ユーザー・アイデンティティを検証して保護されたリソースへのアクセスを許可または却下するために、アクセス・システム・コンポーネントによって消費されていました。

可能性のあるセキュリティ・ギャップを埋めるには、Access Manager 11gには、既存のAccess Manager 10gポリシー強制エージェント(Webゲート)とOSSO 10gエージェント(mod_osso)との下位互換性を維持するための新しいサーバー側コンポーネントが用意されています。新しいAccess Manager 11g Webゲートは10g Webゲートの強化バージョンで、シングル・サインオン(SSO)ソリューションのためにエージェントごとの秘密キーをサポートしています。したがって、Cookieリプレイ型の攻撃が阻止されます。11g Webゲートは、すべて同じレベルで信頼されます。つまり、Webゲート固有のCookieが設定され、それを使用しても、他のWebゲートで保護されたアプリケーションにユーザーの代理でアクセスすることはできません。

特に明記しないかぎり、「Webゲート」という用語は、そのまますぐに使用できるWebゲートまたはカスタムのアクセス・クライアントの両方を指します。

Access Manager 11gでは、Oracle Coherenceの技術を使用して、分散されて集中化された信頼のできるセッション管理が可能です。

表30-2は、Access Manager 11gと10gの比較を示しています。

Access Manager 11gで変更された名前のリストは、次を参照してください。

「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。

表30-2 比較: Access Manager 11g対10g

機能	Access Manager 11g	10g
エージェント	エージェント: Webゲート、アクセス・クライアント、OpenSSO、OSSO (mod_osso)およびIAMSuiteAgent ノート: 9つの管理者言語がサポートされています。	リソースWebゲート(RWG) 認証Webゲート(AWG) アクセス・ゲートアクセス・サーバーポリシー・マネージャアイデンティティ・システムノート: 9つの管理者言語がサポートされています。
サーバー側のコンポーネント	OAMサーバー(WebLogic管理対象サーバーにインストール) セキュリティ・トークン・サービスとIdentity FederationはOAMサーバーで実行されます。	アクセス・サーバーポリシー・マネージャアイデンティティ・サーバー
コンソール	Oracle Access Managementコンソール	アクセス・システム・コンソールアイデンティティ・システム・コンソール
インターネット上での情報交換の保護に使用されるプロトコル。	エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS 11g Webゲートでは、エージェント・キーを使用して情報交換が保護されます。 -関連項目: 暗号化キー	プレーン・テキストでの10gエージェントの情報交換は保護されません。
暗号化キー	11g WebGateとOAMサーバー間で共有されるエージェントごとの秘密キー1つ OAMサーバー・キー1つ(サーバー登録時に生成) ノート: 登録されたmod_ossoエージェントごとに1つのキーが生成され、使用されます。	すべての10g Webゲートが使用するAccess Managerデプロイメントごとに1つのグローバル共有秘密キー
キー・ストレージ	エージェント側: エージェントごとのキーは、ローカルでウォレット・ファイルのOracleシークレット・ストアに格納されます。 OAMサーバー側: エージェントごとのキーとサーバー・キーは、サーバー側の資格証明ストアに格納されます。セキュリティ・トークン・サービス	ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(WebGateに対してはアクセス不可)
Cookie	ホストベースの認証Cookie。表1-2を参照してください。	認証とセッション管理の両方について、すべてのWebゲート (AWGを含む)に対して1つのドメイン・ベースのObSSOCookie
暗号化 / 復号化(暗号化されたデータを元の形式に変換するプロセス)	クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。 WebGateは、エージェント・キーを使用してobrareq.cgiを暗号化します。ノート: obrareq.cgiは、WebGateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。 OAMサーバーは、リクエストを復号化して認証し、セッションを作成してサーバーcookieを設定します。また、OAMサーバーはエージェントの認証トークン(エージェント・キーを使用して暗号化)を生成し、セッション・トークン(cookieベースのセッション管理を使用する場合)や認証トークン、その他のパラメータを使用してそれをobrar.cgiにパックしてから、エージェント・キーを使用してobrar.cgiを暗号化します。ノート: obrar.cgiは、OAMサーバーからWebゲートにリダイレクトされた認証レスポンス文字列です。 WebGateはobrar.cgiを復号化して、認証トークンを抽出し、ホスト・ベースのcookieを設定します。	トークンの生成/暗号化、および検証/復号化は、アクセス・サーバーに委任されます。 obrareq.cgiとobrar.cgiはどちらも暗号化されずに送信され、セキュリティは基礎となるHTTP(S)トランスポートに依存します。
セッション管理	「アクティブなサーバー側セッションの管理」を参照してください。	単一のドメインがサポートされています。マルチドメイン: あるドメイン上でユーザーがアイドル状態のままタイムアウトし、認証のWebゲートではタイムアウトしていない場合、AWG Cookieはまだ有効です(再認証は必要ありません)。更新されたタイムアウトとともに新しいCookieが生成されます。
クライアントIP	このクライアントIPを保守管理して、それをホスト・ベースのOAMAuthnCookieに含めます。	元のクライアントIPをObSSOCookieの中に含めます。 IPの検証が構成されている場合、後の認証や認可リクエストでCookieが提示されたときは、この元のクライアントIPが提示者のIPと比較されます。一致しない場合は拒否されます。
レスポンス・トークンの再生防止	レスポンス・トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をobrareq.cgiに含めて、それをobrar.cgiにコピーします。	該当なし
複数のネットワーク・ドメインのサポート	ネットワーク間ドメインの設定不要なシングル・サインオン。複数のネットワーク・ドメインをサポートする場合は、Oracle Federationを使用することをお薦めします。	独自の複数のネットワーク・ドメインSSO機能が、Oracle Identity Federationより前から存在します。これが10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録すればこのサポートを引き続き受けられます。単一のドメインがサポートされています。一度ユーザーがあるWebGateからログオフすると、ドメインのcookieはクリアされて、ユーザーはドメイン全体からログオフしたと見なされます。マルチドメインSSOは、チェーン化されたカスタマイズ済のログアウト・ページを通してサポートできます。
集中ログアウト	`logOutUrls` (10g Webゲートの構成パラメータ)は保持されています。10g logout.htmlには、Access Manager 11g固有の詳細情報が必要です。 11g WebGateには次の新しいパラメータが追加されています。 `ログアウト・リダイレクトURL` `Logout Callback URL` `Logout Target URL` 「11g Webゲートの集中ログアウト構成」を参照してください。次を参照してください。	10g WebゲートとAccess Manager 11gを併用する場合、logout.htmlでは特定の詳細が必要です。「11g Webゲートの集中ログアウト構成」を参照してください。単一のドメインがサポートされています。一度ユーザーがあるWebGateからログオフすると、ドメインのcookieはクリアされて、ユーザーはドメイン全体からログオフしたと見なされます。マルチドメインSSOは、チェーン化されたカスタマイズ済のログアウト・ページを通してサポートできます。

30.3.2 Access Manager 11gと10gのポリシー・モデルの比較

明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。

Access Manager 10gは、ポリシー・ドメイン内のポリシーに基づく認証と認可を提供します。アクセス・サーバーへのWebゲート問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合、Access Manager 10gのデフォルト動作ではアクセスが許可されていました。

表30-3は、Access Manager 11gポリシー・モデルと10gモデルを比較しています。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。対照的に、Access Manager 10gのデフォルトの動作では、リソースがアクセスを明示的に指定するルールやポリシーによって保護されていない場合に、アクセスが許可されていました。

表30-3 Access Manager 11gと10gのポリシー・モデルの比較

ポリシーの要素	11gポリシー・モデル	10gポリシー・モデル
ポリシー・オーサリング	Oracle Access Managementコンソール	ポリシー・マネージャ
ポリシー・ストア	データベース	LDAPディレクトリ・サーバー
ドメイン	アプリケーション・ドメイン	ポリシー・ドメイン
リソース	URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。機能が制限された次のパターン一致 '*'および'...'がサポートされます。リソースをドメイン間で一意にする必要はありません。 HTTP URLの問合せ文字列保護。各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。リソースは、「保護」、「非保護」または「除外」として指定されます。カスタム・リソース・タイプが許可されます。	URL接頭辞がドメインに定義されます。次のパターン一致: { } * … リソースをドメイン間で一意にする必要はありません。 URL問合せ文字列の内容またはHTTP操作(あるいはその両方)に基づいて、httpリソースを保護できます。 HTTP以外のリソース・タイプおよび操作を定義できます。
ホスト識別子	ホスト識別子はポリシーの外部で定義され、HTTPリソースの定義中に使用されます。ホスト識別子は、HTTPリソースの定義において必須です。	ホスト識別子はポリシーの外部で定義され、HTTPリソースの定義中に使用されます。 HTTPリソースの定義において、システムに定義済のホスト識別子がなくなるまでは、ホスト識別子は必須ではありません。
認証ポリシー	認証ポリシーには、リソース、成功レスポンスおよび認証スキームが含まれます。認可ポリシーには、成功レスポンスと時間ベース、IPベースおよびユーザーベースの条件も含めることができます。 1つの認証ポリシーおよび認可ポリシーのみをリソースに関連付けることができます。認証および認可ポリシーを成功または失敗で評価できます。クエリー・ビルダーおよびLDAPフィルタのサポート(特定の表示タイプの属性に基づく一致を取得する場合など)はありません。アプリケーション・ドメインにデフォルト・ポリシーの概念はありません。ただし、決められた範囲内のデフォルト・ポリシーとして使用できるリソースのポリシー/…/*を定義できます。トークン発行ポリシーは、リソースおよびユーザー・ベースまたはパートナに基づく条件を使用して定義できます。「トークン発行ポリシーのページ」を参照してください。	認証ポリシーは単純で、認証スキーム・ベースのルールのみを含みます。 1つのリソースを一連の認可ポリシーに関連付けることができます。これらのポリシーの評価は、必要に応じて論理演算子を使用してセット内のポリシーをまとめた式に基づくことができます。また、1つのリソースを複数の認証ポリシーおよび認可ポリシー・セットに関連付けることもできます。ただし、1つのセットにのみ適用されます。認可ポリシーは、成功、失敗または未確定に評価できます。 LDAPフィルタを使用して、ユーザーを指定できます。デフォルトの認証ポリシーおよび認可ポリシー・セットをポリシー・ドメインに定義できます。ドメインでランタイム・リソースに適用される他のポリシーが存在しない場合にのみ、このポリシーが適用されます。トークン発行ポリシーのサポートはありません。
認証スキーム	認証スキームはグローバルに定義され、共有されます(認証ポリシー内から参照できます)。信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。ノート: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。関連項目:	認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。
認可ポリシー	1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。関連項目: 「ルール」(この表で後述) 「特定のリソースに対する認証ポリシーの定義」を参照してください。	リソースを保護するには、1つ以上の条件を含んだ認可ルールを定義します。また、1つ以上の認可ルール使用する認可条件式を構成します。ポリシー・ドメイン(およびポリシー)には、それぞれ1つの認可条件式のみを含めることができます。
トークン発行ポリシー	生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。関連項目: 「トークン発行ポリシーのページ」。	該当なし
レスポンス	すべてのポリシー・タイプで使用可能。認証および認可の成功レスポンスをポリシー内に定義できます。これらはポリシーの評価後に適用されます。 Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。 URLリダイレクトを設定できます。レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。	認証および認可レスポンスを成功、失敗および未確定イベントでポリシー内に定義できます。これらはポリシーの評価後にコール元に戻されます。 HTTP_HEADERおよびCookieベースの変数を設定できます。認証および認可ポリシー評価の成功および失敗イベントにリダイレクトURLを設定できます。レスポンス値には、リテラル文字列およびユーザー属性値のリストを含めることができます。
Cookie	関連項目: 表21-6 および「ユーザー・ログイン時のシングル・サインオンCookie」	関連項目: 表21-6 および「ユーザー・ログイン時のシングル・サインオンCookie」
問合せ文字列ベースのHTTPリソース定義	アクセス・ポリシーでサポートされています。表25-1を参照してください。	このポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。
ルール	認可ポリシーとトークン発行ポリシーのみで利用可能です。各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。ルールは、次で説明されている認可条件を参照します。関連項目: 「認可ポリシー・ルールおよび条件の概要」	ポリシーは(いくつかのポリシー要素の中で)認証ルールを使用して定義します。認可ルールの概要は次のとおりです。ポリシーの外部で定義され(ただし、スコープはポリシー・ドメイン内)、ポリシー内で参照されます。 2箇所に出現: 1)ドメインのデフォルト・ルールの内容および2)ポリシー定義内各ルールは、誰(どのユーアー、グループまたはIP4アドレス)がアクセスを許可または拒否されるか、およびそのルールが適用される期間を指定します。また、許可を拒否よりも優先するかどうかの条件も指定できます。
条件	認可ポリシーとトークン発行ポリシーのみで利用可能です。各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。条件は、ルールの外部で宣言され、ルール内から参照されます。関連項目: 「認可ポリシー・ルールおよび条件の概要」	該当なし