28.1 OpenSSO、エージェント、移行および共存の概要

OpenSSOは、Sun Access Management、Federation Management、Web Services Security製品のオープン・ソース・バージョンです。

各OpenSSOエージェントは、アプリケーションをホストするコンテナ(Oracle WebLogic Server、JBoss、Apacheなど)にプラグインされるフィルタです。OpenSSOエージェントは、Webゲート、アクセス・クライアントまたはOSSOエージェントと共存できます。Oracleは、既存のOpenSSOエージェント、プロファイルおよびポリシーをAccess Managerに移行するために使用できるOpenSSO評価ツールおよびOpenSSO移行ツールを提供しています。

OpenSSoエージェント	Access Manager
エージェント認証	ユーザー認証
ユーザー・シングル・サインオン	ユーザー・シングル・ログアウト
エージェントが混在する場合のSSO (OpenSSOエージェントとWebGateエージェント)	ユーザー認可
自己およびサブツリー・モードの検索	ポリシー条件(アイデンティティ、LDAPフィルタ、セッション属性、IP範囲、一時的)
ユーザー・プロファイル属性の取得	RESTリクエストまたはレスポンスによる一元化されたエージェント構成
エージェント・プロファイル、ポリシー、ユーザー・ストア、認証ストアの移行	移行評価ツール

28.1.1 OpenSSOとAccess Managerの間の移行と共存について

Access Managerは、OpenSSOからAccess Managerへのアップグレード・ツールを使用して移行した、既存のOpenSSOサーバー・デプロイメントとの共存をサポートしています。

OpenSSOからAccess Managerへのアップグレードでは、次のトピックに示す要件を満たすOpenSSO検出エージェントとポリシー・マッピング・ロジックが使用されます。

Access ManagerおよびOpenSSOのシステム要件とサポートされたプラットフォームについては、次のサイトにあるOracle IdentityとAccess Managementのマトリックスを参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

28.1.1.1 OpenSSOポリシー移行

OpenSSOポリシーは、OpenSSOデプロイメントで使用可能なアーティファクトに基づいて、Access Managerの認証および認可ポリシーにマップされます。

表28-2は、ポリシー移行時にOpenSSOとAccess Managerとの間で実行されるマッピングの概要を示しています。

番号	OpenSSO	Access Manager
1	ポリシー・レルム	ポリシー・ドメイン
2	ポリシー	認証および認可ポリシー
3	リソース	リソースとホスト識別子
4	アクション	指定なし(デフォルトでは「GET」のみ)
5	サブジェクト	認可ポリシーのアイデンティティ条件
6	条件	認証スキームと認可条件
7	レスポンス・プロバイダ	ポリシー・レスポンス

28.1.1.2 OpenSSO移行時のアプリケーション・ドメインの作成

既存のAccess Managerアプリケーション・ドメインおよびポリシーがOpenSSOポリシー・ドメインと一致しない場合、Access Managerに新しいアプリケーション・ドメインが作成されます。

作成されたアプリケーション・ドメインはOpenSSOレルムに対応します。各レルム(OpenSSOの最上位レルムとサブレベル・レルム)について、アプリケーション・ドメインがAccess Managerに作成されます。

既存のすべてのアプリケーション・ドメインがOpenSSOポリシー・ドメインと比較されます。既存のすべてのポリシーに対してポリシー名がチェックされます。同じ名前のポリシーが存在する場合、エラーが発生します。それ以外の場合は、Access Managerに新しいポリシーが作成されます。

ノート:

OpenSSOポリシーの参照ポリシーは移行されません。

28.1.1.3 OpenSSO認証ポリシー移行

有効なルールと条件を含むOpenSSOポリシーは、Access Manager認証ポリシーに移行されます。これは、新規ポリシーが作成されるか既存のポリシーが更新されるかのどちらかです。

ポリシーの作成時には、OpenSSOポリシー・ルールのhost:port情報を使用して、ホスト識別子とアプリケーション・ドメインへの正確なリソースURL (またはURI)が作成されます。

ノート:

ルールのないアーティファクトを含むOpenSSOポリシーは有効なポリシーではありません。

条件付きのポリシーは、OpenSSOに対して有効です。ただし、これらはAccess Managerのデフォルトの認証ポリシーに基づいて移行されます。IPまたは一時条件のあるポリシーは、Access Manager認可ポリシー条件に移行することができます。

OpenSSOポリシーが非参照ポリシーの場合、作成されるAccess Manager認証ポリシーには、対応するOpenSSOからの認証モジュール、ホスト識別子、OpenSSOポリシーからのリソースによる認証スキームが含まれます。Access Manager認可ポリシーでは、対応するOpenSSOの制約とサブジェクトが設定されます。

制限: (同じアプリケーション・ドメインまたはレルム内のいずれかのポリシーに)リソースがすでに存在している場合、認証ポリシーの作成には例外が発生します。リソースが別のポリシーによってすでに保護されている(ホスト識別子の下にすでに存在している)場合、同じリソースに対して新しいポリシーを作成すると、例外が発生します。この新しいポリシーは作成されません。エラーはログ・ファイルに記録され、Oracle Access Managementコンソールにも表示されます。

28.1.1.4 Access Managerでのホスト識別子の作成

Access Manager内では、OpenSSOによる一意のhost:portの組合せ1つに対して1つのホスト識別子が作成されます。

各レルムの各ポリシー・ルールからすべてのhost:portを取得する必要があります。これにより、一意のhost:portの組合せと同じ数だけhostIdentifierが作成されます。

最上位レルム: デフォルトでは、OpenSSOには最上位レルム(/)は1つしかありません。その他のレルムはすべて、この最上位レルムの下に作成できます。理論的には、Access Managerでホスト識別子を作成するhost:portの組合せはすべて最上位レルムに含まれることになります。

サブ・レルム: サブ・レルム内のポリシー・ルールにあるhost:portの組合せは、最上位レルムの下に作成される参照ポリシー内のhost:portに依存します。参照ポリシー内のhost:portは、最上位レルムの他の非参照ポリシー内のhost:portによるものとはかぎりません(さらに、参照ポリシーは移行に適していません)。したがって、サブ・レルムのポリシーにあるhost:portは、移行に適している最上位レルムのポリシーにあるhost:portとは異なる場合があるため、各レルムのポリシーのhost:portが確認されます。

制限: OpenSSOでは、同じリソースを保護するためにルールは同じであるものの認証スキームが異なる2つ(以上)のポリシーが存在する場合、1つだけ(最初に出現したもの)をAccess Managerに移行できます。それ以外は無視され、Access Managerには作成されません。ただし、このようなことが発生するのは非常に稀です。

28.1.2 OpenSSOエージェントのAccess Managerへの依存

Oracle Access Managerでは、OpenSSOエージェントと処理をサポートしています。

OpenSSO用のOAMコンポーネントの概要を表28-3に示します。

表28-3 OpenSSOのAccess Managerへの依存

コンポーネント	説明
OpenSSOエージェント	自己認証によって信頼性を確立するには、OpenSSOエージェントがAccess Managerに登録されていなければなりません。OAMサーバーは次の処理を行います。提供された資格証明によってエージェントを認証します。エージェントのセッションを作成します。この情報をキャッシュに保存して、グループ/クラスタ内の任意のサーバーがエージェントからの次のリクエストを処理できるようにします。セッション識別子をエージェントに渡し、その後の相互作用中にこれをOAMサーバーに提示できるようにします。このエージェント・セッションには有効期限がないので、エージェントはOAMサーバーとの信頼性を継続して維持することができます。エージェント登録は有効または無効にすることができます。無効にすると、エージェントは応答しなくなります。複数のOpenSSOエージェントが一元化された同じ構成を共有できます(必要時、集中型構成モードで登録されている場合)。その場合でも、各エージェントには独自の一意のセッションおよびセッションIDがあります。エージェント登録では、登録ごとの「許容されるエージェント・セッションの最大数」を構成できます。エージェントのセッションが期限切れになるかどうかを定義する、セッション・タイムアウト・プロパティが存在する場合もあります。関連項目: 「コンソールを使用したOpenSSOエージェントの登録および管理」「資格証明コレクションおよびログインの理解」
OpenSSOプロキシ	このOracle提供のプロキシは、Access Manager 11.1.2にバンドルされ、ともにインストールされます。OpenSSOプロキシは、OpenSSOエージェントとOAMサーバーとの間の通信を可能にします。OpenSSOプロキシは、認証、認可、SSOに関するすべてのOpenSSOエージェントのリクエストとレスポンスを処理します。OpenSSOプロキシは、プロトコル・バインディングとメッセージ(リクエストまたはレスポンス)変換機能を提供します。関連項目: 「OpenSSOエージェントとAccess Manager間の実行時の処理」。
プロトコル・バインディング・レイヤー	このOracle提供のフレームワークは、エージェント固有のプロトコル処理と認証プロトコル・メッセージのマッピングを実行します。また、このフレームワークは、受信したプロトコル固有のリクエストをプロトコルに依存しないリクエストにアンマーシャリングしたり、プロトコルに依存しないレスポンスをプロトコル固有のレスポンスにマーシャリングします。
パートナおよびトラスト・ストア	OpenSSOエージェントの一元化された構成を格納します。Access Managerのパートナおよびトラスト・ストアは、エージェントIDとエージェント・パスワードに関するGET APIを提供することで、エージェント認証もサポートします。
OpenSSOアプリケーション・ドメイン	OpenSSOエージェントの登録時に「ポリシーの自動作成」オプションを使用することで、自動的に生成できます。
Cookie	エンド・ユーザーの持つ有効なCookieは次のとおりです。 OAM_ID cookie (エージェント認証後のエンド・セッションを表します)。次を参照してください。 OpenSSO Cookie (OpenSSOプロキシがセッションの検証をトリガーした後に、エージェントがこのCookieを検出します)。OpenSSO cookieのデフォルト名は次のとおりです。 iPlanetDirectoryPro
保護されたリソースの認可ポリシー	認可ポリシーは次の条件を使用して設定します。「IP範囲」条件: 指定した範囲のIPアドレスのみにアクセスできるようにします。「一時的」条件: 指定した期間のみアクセスできるようにします。「アイデンティティ」条件: 構成済のアイデンティティ(ユーザーまたはグループ)のみが保護されたリソースにアクセスできるようにします。「LDAPフィルタ」条件: フィルタ条件を満たす場合のみアクセスできるようにします。セッション属性条件: セッションのセッション属性が必要な値で構成されている場合のみ、アクセスできるようにします。ネームスペースのリクエスト、ユーザー、セッションの属性条件: 属性が必要な値で構成されている場合のみアクセスできるようにします。
SSOコントローラ	機能コンポーネント(SSOエンジンや認証エンジンなど)を呼び出すことでプロトコル・リクエストを実行します。
SSOエンジン	オンライン・セッション時に、エンタープライズおよび同レベルのドメイン・サインオンとシングル・ログアウト(SLO)を提供します。セッション・ライフサイクルを管理します。有効なセッション内のすべてのリライイング・パーティ間のログアウトを編成することで、グローバル・ログアウトを実行します。トークン処理エンジンと通信して、有効なエンジンを作成し、ユーザーを永続化します。
セッション管理エンジン	ユーザーおよび管理者が開始するタイムアウト・ベースのイベントのサポートによって、セッションおよびトークン・コンテキストの情報を管理します。SSOエンジンは、セッション管理エンジン機能を使用してセッションを管理します。セッション作成セッションの読取りセッションの更新セッションの削除セッションの検証セッションIDの取得作成時間の設定/取得有効期限時間の設定/取得最終アクセス時間の設定/取得セッション状態の設定/取得セッションのパージノート: Oracle Access Managementコンソールを使用してOpenSSOエージェント・セッションを表示または管理することはできません。必要に応じて、OpenSSOエンジン・コントローラ・レイヤーが適切なセッション管理インタフェースを呼び出します。セッション・マネージャはエージェント・セッション・キャッシュ・マネージャを内部的に呼び出し、エージェント・セッション用の分散キャッシュを管理します。登録されたOpenSSOエージェントごとに一意のセッションが作成され、これがエージェントとOAMサーバー間の信頼メカニズムとなります。一意のセッションIDには、ユーザー・リクエストを処理する前にOAMサーバーによって検証する必要のあるエージェント・トークンとして、セッション検証やユーザー認可などに関するすべてのXML/HTTPリクエストが付随しています。デフォルトでは、エージェント・セッションには有効期限がありません。エージェント・セッションはメモリー内のセッション・キャッシュに格納されます。OAMサーバーを再起動する場合、エージェント・セッションを保持する必要はありません。エージェント・セッションはOAMサーバーに存在しており、一意のエージェント・セッションIDが使用可能な形式でエージェントに戻されます。エージェント・セッションは、「無効」(未認証)と「有効」(認証済)の2つの状態をサポートしています。OAMサーバーが正常に通信できるのは、「有効」なセッション状態のエージェントに対してのみです。
トークン処理エンジン	トークン発行および検証プロトコル・リクエストに応じて、トークン生成とトークン検証を実行します。デフォルト機能では、ユーザー名、SAML、およびX509トークンを管理(発行、検証、更新、キャンセル)します。デフォルトでサポートされているすぐ使用可能なセキュリティ・トークン・タイプの範囲を超えて、カスタム・トークンを処理できるように機能を拡張することもできます。
Oracle Access Managementコンソール	管理者はコンソールを使用して次の処理を行います。 OpenSSOエージェントのプロビジョニング/登録。保護されているリソースに対するアプリケーション・ドメイン、認証および認可ポリシーの管理。
リモート登録ユーティリティ	管理者はリモート登録ユーティリティを使用して、エージェントをプロビジョニングし、集中型モードでエージェントが使用する構成ファイルを生成することができます。エージェントは必要なすべての構成情報のコピーを持っているので、このためにOAMサーバーにアクセスすることはありません。ノート: OpenSSOエージェント・プロファイルをAccess Managerに移行する場合、ローカライズ・モードと集中モードの両方がサポートされます。
WLSTコマンド	管理者はWLSTコマンドを使用して次の処理を行うことができます。 OpenSSOエージェントのOAMサーバーへの移行。関連項目: 「移行されるアーティファクト: OpenSSO」。