| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
既存のOracleデプロイメントにOpenSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、これをソリューションとして引き続きサポートします。また、Access Managerで使用するために、既存のOpenSSOエージェントを登録することもできます。
この章では、Access Manager 11.1.2で使用するためにレガシー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に移行するためのOracle提供のツールおよびプロセスの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイドを参照してください。 |
各OpenSSOエージェントは、アプリケーションに対するリクエストを捕捉することで、これらのアプリケーションへのアクセスを制限します。プロビジョニング後、OpenSSOエージェントはOpenSSOサーバーのかわりにOAMサーバーを使用するようになります。
|
注意: OpenSSOエージェントを、OpenSSOサーバーではなく、OAMサーバーで使用するには、Access Managerに登録する必要があります。 |
プロビジョニング後、OpenSSOエージェントはOpenSSOサーバーのかわりにOAMサーバーを使用するようになります。アプリケーションへの制限付きアクセスは、それらのアプリケーションへのリクエストを捕捉することで実現します。OAMサーバーは、エージェントとOAMサーバー間の通信を可能にするOpenSSOプロキシを提供し、エージェント保護のアプリケーションに対するSSOを円滑化します。
OAMサーバーは、エージェントとOAMサーバー間の通信を可能にするOpenSSOプロキシを提供し、エージェント保護のアプリケーションに対するSSOを円滑化します。登録済のOpenSSOエージェントを使用すると、Access Managerは、表23-1に示した機能(認証機能および認可機能のサブセット)を提供します。
表23-1 機能: Access Managerを使用するOpenSSOエージェント
|
エージェント認証 |
ユーザー認証 |
|
ユーザー・シングル・サインオン |
ユーザー・シングル・ログアウト |
|
エージェントが混在する場合のSSO (OpenSSOエージェントとWebGateエージェント) |
ユーザー認可 |
|
自己およびサブツリー・モードの検索 |
ポリシー条件(アイデンティティ、LDAPフィルタ、セッション属性、IP範囲、一時的) |
|
ユーザー・プロファイル属性の取得 |
RESTリクエストまたはレスポンスによる一元化されたエージェント構成 |
|
エージェント・プロファイル、ポリシー、ユーザー・ストア、認証ストアの移行 |
移行評価ツール |
詳細な情報は、次を参照してください:
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
|
関連項目: Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイド |
OpenSSOポリシー移行
OpenSSOポリシーは、OpenSSOデプロイメントで使用可能なアーティファクトに基づいて、Access Managerの認証および認可ポリシーにマップされます。表23-2は、ポリシー移行時にOpenSSOとAccess Managerとの間で実行されるマッピングの概要を示しています。
表23-2 OpenSSOポリシー移行
| 番号 | OpenSSO | Access Manager |
|---|---|---|
|
1 |
ポリシー・レルム |
ポリシー・ドメイン |
|
2 |
ポリシー |
認証および認可ポリシー |
|
3 |
リソース |
リソースとホスト識別子 |
|
4 |
アクション |
指定なし(デフォルトでは「GET」のみ) |
|
5 |
サブジェクト |
認可ポリシーのアイデンティティ条件 |
|
6 |
条件 |
認証スキームと認可条件 |
|
7 |
レスポンス・プロバイダ |
ポリシー・レスポンス |
OpenSSO移行時のアプリケーション・ドメインの作成
既存のAccess Managerアプリケーション・ドメインおよびポリシーがOpenSSOポリシー・ドメインと一致しない場合、Access Managerに新しいアプリケーション・ドメインが作成されます。作成されたアプリケーション・ドメインはOpenSSOレルムに対応します。各レルム(OpenSSOの最上位レルムとサブレベル・レルム)について、アプリケーション・ドメインがAccess Managerに作成されます。
既存のすべてのアプリケーション・ドメインがOpenSSOポリシー・ドメインと比較されます。既存のすべてのポリシーに対してポリシー名がチェックされます。同じ名前のポリシーが存在する場合、エラーが発生します。それ以外の場合は、Access Managerに新しいポリシーが作成されます。
|
注意: OpenSSOポリシーの参照ポリシーは移行されません。 |
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コンソールにも表示されます。
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には作成されません。ただし、このようなことが発生するのは非常に稀です。
Access Managerは、表23-3に示すOpenSSOエージェントと処理をサポートしています。
表23-3 OpenSSOのAccess Managerへの依存
| コンポーネント | 説明 |
|---|---|
|
OpenSSOエージェント |
自己認証によって信頼性を確立するには、OpenSSOエージェントがAccess Managerに登録されていなければなりません。OAMサーバーは次の処理を行います。
このエージェント・セッションには有効期限がないので、エージェントはOAMサーバーとの信頼性を継続して維持することができます。 エージェント登録は有効または無効にすることができます。無効にすると、エージェントは応答しなくなります。 複数のOpenSSOエージェントが一元化された同じ構成を共有できます(必要時、集中型構成モードで登録されている場合)。その場合でも、各エージェントには独自の一意のセッションおよびセッションIDがあります。エージェント登録では、登録ごとの「許容されるエージェント・セッションの最大数」を構成できます。 エージェントのセッションが期限切れになるかどうかを定義する、セッション・タイムアウト・プロパティが存在する場合もあります。 関連項目: |
|
OpenSSOプロキシ |
このOracle提供のプロキシは、Access Manager 11.1.2にバンドルされ、ともにインストールされます。OpenSSOプロキシは、OpenSSOエージェントとOAMサーバーとの間の通信を可能にします。OpenSSOプロキシは、認証、認可、SSOに関するすべてのOpenSSOエージェントのリクエストとレスポンスを処理します。OpenSSOプロキシは、プロトコル・バインディングとメッセージ(リクエストまたはレスポンス)変換機能を提供します。 |
|
プロトコル・バインディング・レイヤー |
このOracle提供のフレームワークは、エージェント固有のプロトコル処理と認証プロトコル・メッセージのマッピングを実行します。また、このフレームワークは、受信したプロトコル固有のリクエストをプロトコルに依存しないリクエストにアンマーシャリングしたり、プロトコルに依存しないレスポンスをプロトコル固有のレスポンスにマーシャリングします。 |
|
パートナおよびトラスト・ストア |
OpenSSOエージェントの一元化された構成を格納します。Access Managerのパートナおよびトラスト・ストアは、エージェントIDとエージェント・パスワードに関するGET APIを提供することで、エージェント認証もサポートします。 |
|
OpenSSOアプリケーション・ドメイン |
OpenSSOエージェントの登録時に「ポリシーの自動作成」オプションを使用することで、自動的に生成できます。 |
|
Cookie |
エンド・ユーザーの持つ有効なCookieは次のとおりです。
|
|
保護されたリソースの認可ポリシー |
認可ポリシーは次の条件を使用して設定します。
|
|
SSOコントローラ |
機能コンポーネント(SSOエンジンや認証エンジンなど)を呼び出すことでプロトコル・リクエストを実行します。 |
|
SSOエンジン |
オンライン・セッション時に、エンタープライズおよび同レベルのドメイン・サインオンとシングル・ログアウト(SLO)を提供します。 セッション・ライフサイクルを管理します。有効なセッション内のすべてのリライイング・パーティ間のログアウトを編成することで、グローバル・ログアウトを実行します。トークン処理エンジンと通信して、有効なエンジンを作成し、ユーザーを永続化します。 |
|
セッション管理エンジン |
ユーザーおよび管理者が開始するタイムアウト・ベースのイベントのサポートによって、セッションおよびトークン・コンテキストの情報を管理します。SSOエンジンは、セッション管理エンジン機能を使用してセッションを管理します。
注意: Oracle Access Managementコンソールを使用してOpenSSOエージェント・セッションを表示または管理することはできません。必要に応じて、OpenSSOエンジン・コントローラ・レイヤーが適切なセッション管理インタフェースを呼び出します。セッション・マネージャはエージェント・セッション・キャッシュ・マネージャを内部的に呼び出し、エージェント・セッション用の分散キャッシュを管理します。 登録されたOpenSSOエージェントごとに一意のセッションが作成され、これがエージェントとOAMサーバー間の信頼メカニズムとなります。一意のセッションIDには、ユーザー・リクエストを処理する前にOAMサーバーによって検証する必要のあるエージェント・トークンとして、セッション検証やユーザー認可などに関するすべてのXML/HTTPリクエストが付随しています。 デフォルトでは、エージェント・セッションには有効期限がありません。エージェント・セッションはメモリー内のセッション・キャッシュに格納されます。OAMサーバーを再起動する場合、エージェント・セッションを保持する必要はありません。 エージェント・セッションはOAMサーバーに存在しており、一意のエージェント・セッションIDが使用可能な形式でエージェントに戻されます。エージェント・セッションは、「無効」(未認証)と「有効」(認証済)の2つの状態をサポートしています。OAMサーバーが正常に通信できるのは、「有効」なセッション状態のエージェントに対してのみです。 |
|
トークン処理エンジン |
トークン発行および検証プロトコル・リクエストに応じて、トークン生成とトークン検証を実行します。デフォルト機能では、ユーザー名、SAML、およびX509トークンを管理(発行、検証、更新、キャンセル)します。デフォルトでサポートされているすぐ使用可能なセキュリティ・トークン・タイプの範囲を超えて、カスタム・トークンを処理できるように機能を拡張することもできます。 |
|
Oracle Access Managementコンソール |
管理者はコンソールを使用して次の処理を行います。
|
|
リモート登録ユーティリティ |
管理者はリモート登録ユーティリティを使用して、エージェントをプロビジョニングし、集中型モードでエージェントが使用する構成ファイルを生成することができます。エージェントは必要なすべての構成情報のコピーを持っているので、このためにOAMサーバーにアクセスすることはありません。 注意: OpenSSOエージェント・プロファイルをAccess Managerに移行する場合、ローカライズ・モードと集中モードの両方がサポートされます。 |
|
WLSTコマンド |
管理者はWLSTコマンドを使用して次の処理を行うことができます。
関連項目: 「移行されるアーティファクト: OpenSSO」。 |
OAMサーバーには、OpenSSOエージェントとの通信を処理するOpenSSOプロキシが組み込まれているため、OpenSSOサーバーとの相互運用性が簡単になります。たとえば、OpenSSOポリシー・エージェントとOAMサーバーとの間でのシングル・サインオン(SSO)とシングル・サインアウト(SLO)があげられます。相互運用性は、エンドユーザー認証でHTML/HTTP認証リクエストを(HTTPリダイレクトとして)参照し、エンドユーザー・セッションの検証でXML/HTTP SSOリクエストを参照することによって、実現されます。
図23-1は、OpenSSOとAccess Managerが含まれるデプロイメントを示しています。OpenSSOエージェントは、Web/Java EEコンテナおよび保護されているリソースとともに存在します。OpenSSOサーバーは、別のホストに存在します。
表23-4は、Access ManagerとOpenSSOエージェント間のSSO処理についての説明です。
表23-4 Access ManagerによるOpenSSOの処理
| 機能 | 説明 |
|---|---|
|
OpenSSOエージェント認証 |
ユーザー認証の前に、OpenSSOエージェントが認証されて有効なエージェント・セッションが確立されます。 OpenSSOエージェントは、OAMサーバーに対してOpenSSOプロキシ経由で自身を認証します。 OpenSSOエージェント認証(エージェントがOpenSSOプロキシに対して自身を認証)は、エージェント・タイプに基づいて次のように行われます。 J2EEエージェント: エージェント・コンテナ起動時。 Webエージェント: Webサーバーに対する最初のユーザー認証リクエストによる。
エージェントが認証されると、有効なエージェント・セッションが作成されます。エージェント認証の後に生成されるキーは、パートナおよびトラスト・ストアに格納されます。 |
|
SSOユーザー・ログインおよび認証 |
エージェントがOAMサーバーにより認証された後、ユーザー・リクエストがOAMサーバーにより認証されます。SSOはその後、エージェントにより保護されているリソースにアクセスする認証済ユーザーに提供されます。 OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを確認します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。 ユーザー・ログイン
|
|
エンド・ユーザー・セッションの検証 |
OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉します。 エンド・ユーザー・セッションの検証
|
|
Webエージェント・タイプのユーザー・プロファイル属性の取得 |
ユーザーがログインに成功して、有効なセッションが作成されると、OpenSSOエージェントは、セッションIDを渡すことによって、ユーザー・プロファイル属性をリクエストできます。OpenSSOプロキシ・レイヤーは、このリクエストを受信し、OpenSSOセッションID拡張からOAMセッションIDをフェッチする必要があります。OpenSSO Webエージェントは、これらのリクエストにポリシー・サービスURLを使用します。 OpenSSOプロキシは、これらの属性をフェッチしてセッションIDをOAMサーバーに渡します(OAMサーバーはレスポンス・フレームワークを使用してユーザー・プロファイル属性をフェッチし、データをOpenSSOプロキシに返します)。 |
|
J2EEエージェント・タイプのユーザー・プロファイル属性の取得 |
OpenSSO J2EEエージェントは、jax-rpcコールを使用して、ユーザー・プロファイル属性を取得します。フローは、Webエージェント・タイプの場合のこれらのプロパティを取得するフローと同様です。 |
|
ユーザー・シングル・ログアウト |
|
|
SSOエージェント・ログアウト |
Access Managerは、OpenSSOエージェントから送信されたシングル・ログアウト・リクエストを処理します。 注意: ユーザーは、他のエージェント(たとえば、WebゲートやMOD_OSSO)によって保護されているリソースからログアウトする必要があります。マルチドメイン環境以外では、エージェント・ログアウトは必要ありません。
|
|
OpenSSOエージェントのトークン生成 |
Access Managerは、OpenSSOエージェント用に生成され、OpenSSOエージェントによって使用されるトークンを処理します。 |
|
ロギング |
OAMサーバー・ログ・コンポーネントを使用して、次のイベントに対するエンド・ユーザー・アクセス実施中のイベントを追跡できます。
|
|
監査 |
OAMサーバー監査コンポーネントを使用して、次を実行します。
|
|
ポーリング |
ポーリングはサポートされていません。セッション破棄通知のみが、OpenSSOプロキシでサポートされています。 |
既存のOpenSSOエージェントをAccess Managerに移行する場合も、新しいOpenSSOエージェントを登録する場合も、Oracle Access Managementコンソールを使用すると、OpenSSOエージェントの管理と登録が一元化できます。
図23-2に、「新規OpenSSOエージェント」ページを示します。管理者は新しいOpenSSOエージェントを登録する際に、このページで情報を入力します。
表23-5では、「新規OpenSSOエージェント」ページの要素について説明します。
表23-5 「新規OpenSSOエージェント」ページの要素
| 要素 | 説明 |
|---|---|
|
エージェント・タイプ |
OpenSSOエージェント・タイプは次のどちらかです。
注: どちらのエージェント・タイプも、同時にSSOのみを選択した場合は、アクセスが保護されます。 |
|
エージェント名 |
このエージェントの一意の名前。 |
|
パスワード パスワードの再入力 * |
このOpenSSOエージェントの必須かつ一意のパスワードで、この登録プロセス中に割り当てられています。このエントリは不明瞭化された形式で、コンソール、oam-config.xml、OpenSSOAgentBootstrap.propertiesに表示されます。 登録されたエージェントがOAMサーバーに接続すると、ユーザーはパスワードの入力を求められます。パスワードにより、認証時に認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。 |
|
ホスト識別子 |
OpenSSOエージェントのホストおよびポートを識別する名前。 デフォルト: エージェント名 関連項目: 「仮想Webホスティングについて」 |
|
ベースURL |
OpenSSOエージェントがインストールされているコンピュータのプロトコル、ホストおよびポート。 たとえば、http://host.example.domain.com:port or https://example.domain.com:portなどです。 |
|
ポリシーの自動作成 |
エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。エージェント名は、デフォルトで、アプリケーション・ドメイン名として使用されます。 デフォルト: 有効 関連項目: 「生成されるアーティファクト: OpenSSO」。 注意: Access Managerのアプリケーション・ドメインは、OpenSSOのレルムに対応します。アプリケーション・ドメインおよびポリシーがすでに存在する場合、単純に新しいリソースをそれに追加できます。このオプションを解除(チェックなし)すると、アプリケーション・ドメインやポリシーは自動的に生成されません。 |
OpenSSOエージェントのプロパティ
OpenSSOエージェントのプロパティは、次のファイルに格納されます。これらのファイルは、エージェントの登録時と構成の変更時に更新され、実行時に使用されます。
OpenSSOAgentBootstrap.properties
OpenSSOAgentConfiguration.properties
これらのファイルは、コンソール・ホスト(AdminServer)に格納されているため、表23-6に示すように、OpenSSOエージェントの/configディレクトリに再配置する必要があります。
表23-6 OpenSSOアーティファクトの再配置
| AdminServer | OpenSSOエージェントの/configディレクトリ |
|---|---|
|
$MW_HOME/Oracle_IDM1/oam/server/rreg/client/rreg/output |
$Policy-Agent-base/AgentInstance-Dir/config/ |
Open SSOエージェント用に生成されるアプリケーション・ドメインの詳細は、「生成されるアーティファクト: OpenSSO」を参照してください。
この項では、拡張されたOpenSSOエージェント・ページについて説明します。このページは、Oracle Access Managementコンソールを使用してエージェントを管理するときに利用できます。
登録時には、プロセスを簡潔にするために、使用可能なパラメータのうち少数のサブセットのみが表示されます。Oracle Access Managementコンソールとリモート登録ユーティリティのどちらを使用してエージェントを登録していても、コンソールで完全なエージェントの構成ページを表示できます。デフォルト値は、このページに最初の登録後に移入され、エージェントのページを開いたときに表示されます(図23-3を参照)。
J2EEエージェント登録ページの情報は、Webエージェントの詳細とほぼ同じです。J2EEエージェント登録ページを図23-4に示します。
拡張されたOpenSSOエージェント登録ページのすべての要素については、表23-7で説明しています。
表23-7 拡張されたOpenSSOエージェント登録の要素
| 要素 | 説明 |
|---|---|
|
ステータス |
このエージェント登録の状態: 「有効」または「無効」。 デフォルト: 有効 |
|
フィルタ・モード J2EEエージェント・タイプのみ |
エージェント・フィルタは、保護されているアプリケーション内にインストールされています。セキュリティ・ポリシーの施行を円滑化し、保護されているアプリケーション内のすべてのリソースへのアクセスを制御します。J2EEエージェントによって保護されるすべてのアプリケーションのデプロイメント・ディスクリプタを、エージェント・フィルタを使用するように変更する必要があります。この設定が行われていないアプリケーションは、J2EEエージェントによって保護されず、エージェント・レルムがインストールされているデプロイメント・コンテナにデプロイされた場合は正常に動作しなかったり使用できなくなったりする可能性があります。 J2EEエージェントの場合、フィルタ・モードに、SSO_ONLYまたはURL_Policyのどちらかのオプションを選択して設定する必要があります。 デフォルト: URL_Policy
プロセスの概要: 認証のみ(SSO_ONLY J2EEフィルタ・モード)
プロセスの概要: URL_Policy J2EEフィルタ・モードによる認証および認可
注: フィルタ・モードとして「なし」、J2EE_Policy、「すべて」はサポートされていません。 関連項目: 「OpenSSOエージェント登録パラメータの理解」。 |
|
セッション・タイムアウト秒数(ユーザー) |
矢印をクリックして期間を指定します。この期間を経過すると、セッションはタイムアウトして、ユーザーは再認証が必要になります。 デフォルト: 0 |
|
Cookie名 |
OpenSSO cookieのデフォルト名は次のとおりです。 デフォルト: iPlanetDirectoryPro |
|
Cookieセパレータ |
Cookieとして同じ属性の複数の値を設定する場合にセパレータとして使用する文字を定義します。たとえば、パイプ記号「|」を使用できます。 デフォルト: |
|
Cookieのエンコードの有効化 J2EEエージェント・タイプのみ |
Cookieのエンコードを有効にするかどうかを指定します。 デフォルト: 有効 |
|
SSOのみ Webエージェント・タイプのみ |
OpenSSOエージェントが、ブートストラップし、Access Managerによって提供されるOpenSSOプロキシを介してOAMサーバーで認証できるようにします。 エンド・ユーザーがOpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスすると、OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。 認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定して、ユーザーを元の保護されているアプリケーションまたはリソースにリダイレクトします。 有効なOpenSSOセッションを取得した認証済ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してセッションを検証します。 エンド・ユーザーは、Access Managerの認証ポリシーに基づいてアクセスを取得します。 |
|
URL |
|
|
ログインURL |
ログインURLを入力します。このURLには、適切なプロトコル(HTTPまたはHTTPS)、ホスト、ドメインおよびポートを次の形式で指定する必要があります。
http://example.domain.com:port
デフォルト: 注意: ポート番号はオプションです。 |
|
ログアウトURL |
ログアウトURLは、ログアウト・ハンドラをトリガーします。これにより、Access Managerで保護されているリソースにユーザーが次回アクセスする際に再認証が必要になります。 ログアウトURLを入力する場合、適切なプロトコル(HTTPまたはHTTPS)、ホスト、ドメインおよびポートを指定する必要があります。例:
http://example.domain.com:port/opensso/UI/Logout
デフォルト: http://oamhost:port/opensso/UI/Logout 注意: ポート番号はオプションです。ユーザーは、他のエージェント(たとえば、WebゲートやMOD_OSSO)によって保護されているリソースからログアウトする必要があります。マルチドメイン環境以外では、エージェント・ログアウトは必要ありません。 |
|
ポリシーを強制しないURL Webエージェント・タイプのみ |
このリストに入力するURLはポリシーを強制しません。これはパブリックURLと同等であり、保護されておらず、すべてのユーザーがアクセスできます。 |
|
アクセス拒否URI |
ユーザーが、リクエストしたリソースへのアクセスが拒否された場合にリダイレクトされるURI。WebエージェントおよびJ2EEエージェントのどちらでも使用可能ですが、それぞれ次の形式で指定する必要があります。 Webエージェント(完全なURL): http://host:port/context/accessDeniedURL.html J2EEエージェント(相対URI): /context/accessDeniedURL.htm デフォルト: (空白) |
|
監査 |
|
|
デバッグ・レベル J2EEエージェント・タイプのみ |
設定されている場合、OAMサーバーは次のメッセージをログに記録します。
デフォルト: エラー |
|
デバッグ・ディレクトリ J2EEエージェント・タイプのみ |
OAMサーバーの次の監査ログを格納するファイルシステム・ディレクトリ・パス。
|
|
デバッグ・ファイル Webエージェント・タイプのみ |
ローカル・コンポーネントのイベント・ロギング・ファイルのファイルシステム・ディレクトリ・パスを定義します。 デフォルト: |
|
ローカル・ログ・ファイル |
ローカル・コンポーネントのイベント・ロギング・ファイルのファイルシステム・ディレクトリ・パスを定義します。 デフォルト: |
|
ユーザー・マッピング |
|
|
マッピング・モード |
デフォルト: User_ID |
|
ユーザー・アイデンティティ |
デフォルト: ユーザーID |
|
ユーザー属性名 |
デフォルト: |
|
属性マッピング |
属性取得は、アプリケーションが使用するHTTPリクエスト内ユーザー属性をフェッチおよび設定します。 次の「属性マッピング」パネルが用意されています。
フェッチ・モード: 一部のアプリケーションは、ユーザー・リクエストを適切に処理するために、なんらかの形でユーザー固有のプロファイル情報が存在することを前提としています。ユーザーがプロファイル属性、レスポンス属性またはセッション属性で「フェッチ・モード」を指定すると、エージェントは様々な形のユーザーのプロファイルからこれらの属性を取得できます。
デフォルト: なし |
|
プロファイル属性 |
ユーザー・プロファイル情報は、現在の認証済ユーザーに固有の名前で移入できます。例: フェッチ・モード: REQUEST_ATTRIBUTE 名前(マップ・キー): cn 値: CUSTOM-Common-Name 名前(マップ・キー): mail 値: CUSTOM-Email デフォルト: データなし |
|
レスポンス属性 |
ポリシー・レスポンス属性をフェッチし、ポリシー・レスポンス属性プロパティにモードを割り当て、現在の認証済ユーザーに固有の名前で移入するポリシー・レスポンス属性をマッピングすることによって、ユーザー固有情報を取得します。 フェッチ・モード: REQUEST_ATTRIBUTE 名前(マップ・キー): cn 値: CUSTOM-Common-Name 名前(マップ・キー): mail 値: CUSTOM-Email_Addr デフォルト: データなし |
|
セッション属性 |
OAMサーバーによって保持されるセッション・オブジェクトの属性。これらはセッション検証レスポンスの一部としてエージェントに送信されます。 フェッチ・モード: REQUEST_ATTRIBUTE 名前(マップ・キー): UserToken 値: CUSTOM-userid デフォルト: データなし |
|
その他 |
大部分のエージェント・プロパティは、ホットスワップ可能です。構成プロパティを変更すると、予期しない結果が発生する可能性があります。ホットスワップ可能なプロパティは即時に有効になります。そのため、誤りも即時に実装されます。大部分のエージェント・プロパティは、Oracle Access Managementコンソールで構成するために最も便利な形式で提示されます。ただし、この形式は、OpenSSOAgentBootstrap.propertiesファイルでは使用されていません。 リスト・プロパティ: 一部のプロパティは、プロパティ名を表すキー、リストで値が指定されるたびに1ずつ増える(0から始まる)正数、および値で構成されるリストとして指定されます。例: com.sun.identity.agents.config.notenforced.uri[0]=/agentsample/public/* com.sun.identity.agents.config.notenforced.uri[1]=/agentsample/images/* com.sun.identity.agents.config.notenforced.uri[2]=/agentsample/index.html マップ構成: 一部のプロパティは、プロパティ名を表すキー、マップで使用できる参照キーを形成する名前文字列、およびマップで名前に関連付けられている値で構成されるマップ構成として指定されます。例: com.sun.identity.agents.config.filter.mode[app1]=ALL com.sun.identity.agents.config.filter.mode[app2]=SSO_ONLY 注: 特定の構成キーに特定の名前を指定するエントリは、構成内で1つのみ指定できます。特定の構成キーで同じ<名前>のエントリが複数存在する場合、その中のいずれか1つの値のみがシステムにロードされ、それ以外の値は破棄されます。 アプリケーション固有のプロパティ: 一部のプロパティは、特定のアプリケーション向けに構成できます。エージェントは、構成ファイルで定義することによって、同じプロパティでアプリケーションごとに異なる値を使用できます。アプリケーション固有の構成プロパティは、マップ構成のルールおよび構文に従って記述する必要があります。次の単一プロパティの設定例は、ルート・コンテキストおよびコンテキスト/Portalにデプロイされているアプリケーションを除くアプリケーションでは、プロパティのデフォルト値がvalue3に設定されることを示しています。 com.sun.identity.agents.config.example[Portal] = value1 com.sun.identity.agents.config.example[DefaultWebApp] = value2 com.sun.identity.agents.config.example = value3 グローバル・プロパティ: 特定のアプリケーション向けに構成されていないプロパティは、デプロイメント・コンテナ上のすべてのアプリケーションに適用されます。そのようなプロパティは、グローバル・プロパティと呼ばれます。 シリアル番号: 自動的に割り当てられます。 名前: 次のいずれかを選択します。 値: 選択した名前に対する適切な値を入力します。 注: OpenSSOエージェント構成のホットスワップを有効にするには、openssoエージェントが、OAMサーバー上のOpenSSOプロキシでエージェントのプロファイルの「その他」プロパティ・セクションに次のプロパティがあり、エージェント・サーバーが再起動されることを確認します。 J2eeエージェント: Webエージェント:
サポート対象外、Webエージェント: |
|
関連項目: |
|
|
要素 |
説明 |
|
関連項目: |
表23-5「「新規OpenSSOエージェント」ページの要素」 |
|
ステータス |
このエージェント登録の状態: 「有効」または「無効」。 デフォルト: 有効 |
|
フィルタ・モード J2EEエージェント・タイプのみ |
エージェント・フィルタは、保護されているアプリケーション内にインストールされています。セキュリティ・ポリシーの施行を円滑化し、保護されているアプリケーション内のすべてのリソースへのアクセスを制御します。J2EEエージェントによって保護されるすべてのアプリケーションのデプロイメント・ディスクリプタを、エージェント・フィルタを使用するように変更する必要があります。この設定が行われていないアプリケーションは、J2EEエージェントによって保護されず、エージェント・レルムがインストールされているデプロイメント・コンテナにデプロイされた場合は正常に動作しなかったり使用できなくなったりする可能性があります。 J2EEエージェントの場合、フィルタ・モードに、SSO_ONLYまたはURL_Policyのどちらかのオプションを選択して設定する必要があります。 デフォルト: URL_Policy
プロセスの概要: 認証のみ(SSO_ONLY J2EEフィルタ・モード)
プロセスの概要: URL_Policy J2EEフィルタ・モードによる認証および認可
注: フィルタ・モードとして「なし」、J2EE_Policy、「すべて」はサポートされていません。 関連項目: 「OpenSSOエージェント登録パラメータの理解」。 |
このトピックの内容は次のとおりです。
Oracle Access Management管理者の資格証明を持つユーザーは、Oracle提供のツールを使用してOpenSSO環境を分析および移行することも、ここで説明するようにOracle Access Managementコンソールを使用して手動でOpenSSOエージェントをプロビジョニングすることもできます。
登録手順は、OpenSSOエージェント・タイプとしてWebまたはJ2EEのどちらを選択した場合も同じです。OpenSSOエージェントは、デプロイする前に登録できます。有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagementコンソールによりOpenSSOエージェントを登録できます。
|
注意: 新しいOpenSSOエージェントを作成する場合、サポートされているのは集中構成モードのみです。 |
エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、エージェントがフィルタ・モードとしてSSOのみを使用しているかぎり、動作を継続します。
前提条件
少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。エージェントを次の説明に従ってインストールします。
Oracle Sun OpenSSOエンタープライズ・ポリシー・エージェント3.0 Webエージェント・ユーザーズ・ガイド
Oracle Sun OpenSSOエンタープライズ・ポリシー・エージェント3.0 J2EEエージェント・ユーザーズ・ガイド
コンソールを使用してOpenSSOエージェントを登録するには:
Oracle Access Managementコンソールで「新規OpenSSOエージェント」リンクをクリックします。
または、「システム構成」タブの「Access Manager」セクションで「SSOエージェント」ノード、「OpenSSOエージェント」ノードを開き、右上隅のどちらかのOpenSSOエージェントの作成ボタンをクリックします。
「新規OpenSSOエージェント」ページで必須詳細情報(*付き)を入力します(表23-5)。
「ポリシーの自動作成」ボックスが選択されていることを確認します(または、新しいアプリケーション・ドメインが必要ない場合にはボックスの選択を解除してこの機能を無効にします)。
「適用」をクリックして、登録を送信します(または登録を送信せずにページを閉じます)。
「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。
ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。
コンソール・ホスト(AdminServer)からOpenSSOエージェントのブートストラップ・ファイルおよび構成ファイルをエージェント・ホストWebサーバーにコピーします。
| OpenSSOプロパティ・ファイルのコピー元 | パス | |
|---|---|---|
| コピー元: AdminServer (コンソール)ホスト | $DOMAIN_HOME/output/$Agent_Name/
|
|
| OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。 | 例: $WebTier_MW_HOME/Oracle_WT1/instances1/config/OHS/ohs1/config/ |
エージェントをホストしているOAMサーバーを再起動します。
必要に応じて、次のトピックに進みます。
次の手順は、編集(表示、変更または削除)するOpenSSOエージェントのタイプがJ2EEまたはWebのどちらの場合も同じです。有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して、登録済のエージェントのあらゆる設定を変更できます。
変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをOpenSSOエージェントの構成領域にコピーする必要はありません。アーティファクトは、エージェント名、パスワードまたはセキュリティ・モードが変更された場合にのみ、OpenSSOエージェント・ディレクトリ・パスにコピーする必要があります。
|
注意: エージェントの登録を削除すると、登録のみが削除されるため(関連付けられているホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント・インスタンス自身は削除されません)、同じエージェントが必要になった場合に再登録する必要はありません。ただし、アプリケーション・ドメインおよびその内容を削除すると、「アプリケーション・ドメインおよびその内容の削除」で説明するように、エージェント登録を含むすべての参照オブジェクトが削除されます。 |
前提条件
エージェントは登録済であり、Oracle Access Managementコンソールでその登録を表示可能である必要があります。AdminServerおよび1つのOAMサーバーが稼働している必要があります。
登録詳細を表示または変更(または登録を削除)するには:
「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。
「OpenSSOエージェント」ノードを開き、「検索」ページを表示します。
登録を検索します。フォームに(「エージェント名」または「エージェント・タイプ」、またはその両方を)入力するか、単純に「検索」ボタンをクリックします。
登録を開きます。結果表のエージェント名をクリックしてページを開きます。
既存の詳細を変更します。
必要に応じてエージェントの詳細を追加または変更します(表23-5)。
「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます。
OpenSSOエージェント構成ファイルは、エージェント名、パスワードまたはセキュリティ・モードが変更された場合にのみコピーします。
OpenSSOエージェント登録を削除します。これにより、エージェント・インスタンス自体は削除されず、コンソールから登録ページのみが削除されます。
エージェントの登録ページが開いている場合は閉じます。
希望するエージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。
エージェント名がナビゲーション・ツリーにないことを確認します。
エージェントをホストしているOAMサーバーを再起動します。
この項では、オラクル社提供のツールoamregを使用したリモート登録について簡単に説明します。この項の内容は、次のとおりです。
各OpenSSOエージェントは、アプリケーションに対するリクエストを捕捉することで、これらのアプリケーションへのアクセスを制限します。OpenSSOエージェント・プロビジョニングとは、OpenSSOエージェントをAccess Managerに登録するプロセスです。
inbandとoutofbandのどちらのリモート登録モードにも、表23-8に示した入力引数を含むリクエスト・ファイルが必要になります。
表23-8 リモート登録用のOpenSSOリクエスト・ファイル
| テンプレートの対象 | 説明 |
|---|---|
|
OpenSSOエージェントの登録 |
$OAM_REG_HOME/input/OpenSSORequest.xml |
|
$OAM_REG_HOME/input/OpenSSORequest_short.xml 短縮リクエストでoamregを実行する場合、拡張リクエスト内のみにある要素に対しては、デフォルト値が自動的に適用されます。 |
|
|
その他のテンプレート |
|
|
エージェントの更新: |
$OAM_REG_HOME/input/OpenSSOUpdateAgentRequest.xml 関連項目: 「エージェントのリモート更新」 |
|
ポリシーの作成: エージェントを登録せずに新しいホスト識別子とアプリケーション・ドメインを作成 |
$OAM_REG_HOME/input/CreatePolicyRequest.xml |
|
ポリシーの更新: 既存のホスト識別子と、(エージェント登録に関連付けられていない)アプリケーション・ドメイン |
$OAM_REG_HOME/input/UpdatePolicyRequest.xml |
OpenSSOエージェントのリモート登録では、次の処理が自動的に行われます。
Oracle Access Managementコンソール用のエージェント・ページの作成
アプリケーションを保護するためのアプリケーション・ドメインと基本ポリシーの作成
エージェントが実行時に使用する、クライアント上のOpenSSOプロパティ・ファイルの作成
OpenSSOエージェントのリクエスト・テンプレートの要素については、表23-9を参照してください。特に明記しないかぎり、短縮版と拡張版の両方のリクエスト・ファイル内にすべての要素が存在します。
表23-9 OpenSSOエージェントのリモート登録リクエスト
| 要素 | 説明 | 例 |
|---|---|---|
|
<serverAddress> <agentName> <hostIdentifier> <agentBaseUrl> <autoCreatePolicy> <applicationDomain> <virtualhost> |
すべてのリモート登録リクエスト・テンプレートに共通の要素。 |
表16-8「リモート登録リクエストの共通要素」を参照してください。 |
|
<agentType> |
J2EEまたはWebタイプのOpenSSOエージェントのどちらかを選択します。 |
<agentType>WEB</agentType>
|
|
パスワード パスワードの再入力 * |
このOpenSSOエージェントの必須かつ一意のパスワードで、この登録プロセス中に割り当てられています。このエントリは不明瞭化された形式で、コンソール、oam-config.xml、OpenSSOAgentBootstrap.propertiesに表示されます。 登録されたエージェントがOAM SServerに接続すると、ユーザーはパスワードを入力するよう求められます。パスワードにより、認証時に認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。 |
リモート登録時にパスワードを入力するように求められます。これはテンプレートには表示されません。 |
|
拡張されたOpenSSOテンプレートのみ |
||
|
<agentDebugDir> |
<debug>をtrueに設定すると、記録されたエージェント・メッセージへのディレクトリ・パスを構成できます。 デフォルト: なし |
<agentDebugDir>/scratch/debug</agentDebugDir>
|
|
<agentAuditDir> |
OAMサーバーから次の監査ログへのディレクトリ・パスを定義します。
|
<agentAuditDir>/scratch/audit</agentAuditDir>
|
|
<agentAuditFileName> |
監査ログ・ファイル名を定義します。 |
<agentAuditFileName>audit.log</agentAuditFileName>
|
|
<debug> |
デフォルト: false |
<debug>false</debug>
|
|
<cookieName> |
Cookieの名前。OpenSSOプロキシがセッションの検証をトリガーした後に、エージェントがこのCookieを検出します。 エンド・ユーザーの持つ有効なCookieは次のとおりです。
|
<cookieName>iPlanetDirectoryPro</cookieName>
|
|
<accessDeniedUrl> |
アクセスが拒否された場合、ユーザーはこのURLにリダイレクトされます。 |
<accessDeniedUrl></accessDeniedUrl> |
|
<protectedAuthnScheme> |
認証ポリシーで使用する認証スキームを指定します。 アップグレード済の環境の場合、新しく登録するOSSOエージェントの保護されたリソース・ポリシーには、SSOCoExistMigrateSchemeを使用してください。 |
<protectedAuthnScheme></protectedAuthnScheme> |
この項では、OpenSSOのブートストラップ構成マッピングについて説明します。
表23-10 J2EEリクエスト・ファイルのプロパティ・ファイルに対するマッピング
| プロパティ名 | デフォルト値 | 値の例 |
|---|---|---|
|
com.iplanet.am.naming.url |
入力XMLより<serverAddress>/opensso/namingservice |
http://example.com:7575/opensso/namingservice |
|
com.sun.identity.agents.app.username |
入力XMLより<agentName> |
<Agent registration ID> |
|
com.iplanet.am.service.secret |
入力XMLより<agentPassword> 注: これは入力XMLファイルの一部としては収集されるのではなく、リモート登録ツールにより入力を求められます。 |
<Encrypted Agent registration ID password> |
|
com.iplanet.services.debug.directory |
入力XMLより<agentDebugDir> |
/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/debug |
|
com.sun.identity.agents.config.local.logfile |
入力XMLより<agentAuditDir>/<agentAuditFileName> |
/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/audit/amAgent_example_com_7676.log |
|
com.sun.identity.agents.config.organization.name |
入力XMLより<realmName> 注: これは、入力XMLファイルから収集する<hostIdentifier>の値です。明示的に指定していない場合は、デフォルトで<agentName>とみなされます。 |
|
|
com.sun.identity.agents.config.profilename |
入力XMLより<agentName> |
<Agent registration ID> |
|
リモート登録ファイルに含まれないプロパティ |
||
|
com.iplanet.am.naming.url |
N/A |
N/A |
|
com.sun.identity.agents.config.service.resolver |
N/A |
N/A |
|
com.sun.services.debug.mergeall |
N/A |
N/A |
|
com.sun.identity.agents.config.lock.enable |
FALSE N/A |
N/A |
|
am.encryption.pwd |
N/A |
N/A |
表23-11に、Webエージェント・リクエスト・ファイルとプロパティ・ファイルの間のマッピングを示します。
表23-11 Webリクエスト・ファイルのプロパティ・ファイルに対するマッピング
| プロパティ名 | デフォルト値 | 値の例 |
|---|---|---|
|
com.iplanet.am.naming.url |
入力XMLより<serverAddress>/<serverAddress>/opensso/namingservice |
http://example.com:7575/opensso/namingservice |
|
com.sun.identity.agents.config.username |
入力XMLより<agentName> |
<Agent profile ID> |
|
com.sun.identity.agents.config.password |
入力XMLより<agentPassword> 注: これは入力XMLファイルの一部としては収集されるのではなく、リモート登録ツールにより入力を求められます。 |
<Encrypted Agent registration ID password> |
|
com.iplanet.services.debug.directory |
入力XMLより<agentDebugDir> |
/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/debug |
|
com.sun.identity.agents.config.local.logfile |
入力XMLより<agentAuditDir>/<agentAuditFileName> |
/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/audit/amAgent_redsky_red_iplanet_com_7676.log |
|
com.sun.identity.agents.config.organization.name |
入力XMLより<realmName> 注意: これは、入力XMLから収集する<hostIdentifier>の値です。ステータス: オープン、固定またはクローズ済 |
|
|
com.sun.identity.agents.config.profilename |
入力XMLより<agentName> |
この項では、OpenSSOエージェントの帯域内リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、ここで説明する別の章を参照してください。
前提条件
タスクの概要: リモート登録を実行する帯域内の管理者
登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。
$ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
エージェントとアプリケーション・ドメインに対して一意の値で入力ファイルを作成します(「リモート登録リクエストの作成」を参照)。
登録ツールを実行してエージェントを構成し、リソースに対するデフォルトのアプリケーション・ドメインを作成して、更新したエージェント構成ファイルをコピーします(「帯域内リモート登録の実行」を参照)。
コピー元: コンソール・ホスト(AdminServer)
/rreg/output/Agent_Name/
OpenSSOAgentBootstrap.properties
OpenSSOAgentConfiguration.properties
OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。例:
構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。
アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証およびアクセスの検証」を参照してください)。
この項では、OpenSSOエージェントの帯域外リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、ここで説明する別の章を参照してください。
前提条件
タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)
帯域外の管理者の手順: 特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。
登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。
$ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインに一意の値を入力します(「リモート登録リクエストの作成」を参照してください)。
$OAM_REG_HOME/input/OpenSSORequest.xml
選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。
帯域内の管理者の手順:
登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。
$ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
登録ツールで帯域外の開始リクエストを使用してエージェントを登録し、帯域外の管理者に戻すレスポンスおよびネイティブ・エージェントの構成ファイルを作成します。「帯域外リモート登録の実行」を参照してください。
opensso_Response.xmlは、帯域外の管理者が手順3で使用するために生成されます。
OpenSSOプロパティ・ファイルは、帯域外の管理者がOSSOモジュールをブートストラップできるように変更します。
帯域外の管理者: レスポンス・ファイルと登録ツールを使用して、アーティファクトをファイル・システムの適切なディレクトリにコピーします。
opensso_Response.xml。
opensso....propertiesファイル
帯域内の管理者: 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。
帯域外の管理者の手順: いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。
この項では、「エージェントのリモート更新の概要」で説明したリモート登録テンプレートとモードを使用して、OSSOエージェントを更新、検証および削除する方法について説明します。
更新リクエスト・ファイルを使用して、具体的な値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。
表23-12 OpenSSOリモート登録とリモート更新の相違点
| 相違点 | 要素 |
|---|---|
|
追加 |
変更を追跡する、<startDate>yyyy_mm_dd</startDate>要素 |
|
追加 |
agent_base_url_portを指定する<homeUrl>要素 |
|
省略 |
<hostidentifier> |
|
省略 |
<agentbaseURL> |
OAM 10gエージェント登録をリモート更新するには
「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
エージェントの更新:
OAMUpdateAgentRequest.xmlテンプレートを使用して、更新リクエストを作成します。
エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:
./bin/oamreg.sh agentUpdate input/OpenSSOUpdateAgentRequest.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
エージェント・ホストのOpenSSOAgentBootstrapとOpenSSOAgentConfiguration.propertiesファイルを再配置します。
再配置元AdminServer (コンソール)ホスト: /rreg/output/Agent_Name/
OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。例:
このエージェントをホストするOAMサーバーを再起動します。
エージェントの検証:
エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:
./bin/oamreg.sh agentValidate agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
エージェントの削除:
エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:
./bin/oamreg.sh agentDelete agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
成功: 画面のメッセージを確認します。
AgentDeleteプロセスは正常に完了しました。
Access Managerを使用するレガシーOpenSSOエージェントの追加情報は、表23-13を参照してください。
表23-13 このガイドに記載されたOpenSSOのその他の情報
| トピック | ロケーション |
|---|---|
|
コンポーネントのロガー |
表8-3「Oracle Access Managementのサーバー側コンポーネントのロガー」 |
|
DMSコンソール内のOpenSSOメトリック |
|
|
セッションの管理 |
第17章「Access Managerセッションのメンテナンス」 |
|
アーティファクト |
|
