Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド

11g リリース1 (11.1.1)

B62265-02(原本部品番号:E15478-06)

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

新機能

- パッチ・セット1の新機能

- リリース11gリリース1 (11.1.1)

- 製品およびコンポーネントの名前の変更

第I部 Oracle Access Manager with Oracle Security Token Serviceの概要

1 Oracle製品の概要

- Oracle Access Managerの概要

- Oracle Access Managerのアーキテクチャの概要

- Oracle Access Managerのデプロイメント・タイプとインストールの概要

- デプロイメントのタイプとOAM

- Oracle Access Managementのインストール後のタスクについて

- インストールとアップグレードの比較

- Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

- Oracle Access Manager 11gの機能拡張

- 11gで使用できないOracle Access Manager 10gの機能

- Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

- Oracle Security Token Serviceの概要

- Oracle Security Token Serviceの主な用語と概要

- Oracle Access Managerを使用するOracle Security Token Serviceについて

- 統合されたOracle Web Services Managerについて

- Oracle Security Token Serviceのアーキテクチャについて

- Oracle Security Token Serviceのデプロイメントについて

- 一元化されたトークン認証局のデプロイメント

- ファイアウォールの背後でのトークンのデプロイメント

- WebサービスSSOのデプロイメント

- インストール・オプションについて

- 単一WLSドメインのOracle Security Token Serviceクラスタ

- Webサーバー・プロキシによるエンドポイントの露出

- リクエスタおよびリライイング・パーティと他のOracle WS-Trustベース・クライアントとの間の相互運用性

- Oracle Security Token Serviceインストールの概要

- インストール後のタスク: Oracle Security Token Service

- Oracle Security Token Serviceの管理について

2 本書の概要

- 本書の概要

- 第I部: Oracle製品の概要

- 第II部: 共通のタスク

- 共通の管理およびナビゲーションの基礎

- サービス、証明書検証、および共通設定の管理

- データ・ソース

- OAM Serverのインスタンスおよびコンソール

- Oracle Access Managerのセッション管理

- 第III部: Oracle Access Managerの設定

- Access Managerの設定

- シングル・サインオン・エージェント

- 第IV部: シングル・サインオン、Oracle Access Managerポリシー、およびテスト

- シングル・サインオン

- Oracle Access Managerのポリシー・モデルおよび共有ポリシー・コンポーネント

- Oracle Access Managerのポリシー・モデル、アプリケーション・ドメインおよびポリシー

- 接続性およびポリシーのテスト

- Oracle Access Manager 11gの集中ログアウト

- 第V部: Oracle Security Token Service

- 第VI部: 共通のロギング、監査、パフォーマンス監視

- コンポーネント・イベント・メッセージのロギング

- Webgateイベント・メッセージのロギング

- 共通監査フレームワーク

- Oracle Access Managerコンソールのパフォーマンス・メトリック

- Fusion Middleware Controlのパフォーマンス・メトリック

- 第VII部: OAM 11gでのOAM 10g Webgateの使用

- OAM 11gでのOAM 10g Webgateのプロビジョニング

- Apache v2ベースのWebサーバー(OHSとIHS)のための10g Webgateの構成

- IIS Webサーバーのための10g Webgateの構成

- ISAサーバーのための10g Webgateの構成

- OAM 10g WebgateのためのLotus Dominoの構成

- 第VIII部: 付録

- 共存: OracleAS SSO 10gにおけるOAM 11g SSOとOAM 10g SSOの比較

- OAM 11gのテスト(ソース)から本番環境(ターゲット)への移行

- Oracle ADFアプリケーションとの統合

- OAM 10g Webgateの国際化とマルチバイト・データ・サポート

- 安全な通信と証明書の管理

- OAM用カスタムWebLogic Scripting Toolのコマンド

- IPv6クライアント用OAM 11g

- デプロイメント固有ページの作成

- トラブルシューティング

第II部 共通タスクに対するコンソールの使用

3 共通の管理およびナビゲーションの基礎

- 前提条件

- 管理者について

- Oracle Access Managerコンソールのログインとサインアウト

- Oracle Access Managerコンソールへのログイン

- Oracle Access Managerコンソールからのサインアウト

- Oracle Access Managerコンソールおよびコントロールの概要

- コンソールのレイアウトおよびコントロール

- 「ようこそ」ページとショートカット

- 機能レベルのタブとコントロール

- コンテンツのページおよびページ・コントロール

- ページの要素

- コンソールでのコントロールの選択

- ポリシー構成およびシステム構成のタブの概要

- 「システム構成」タブについて

- 「ポリシー構成」タブについて

- コンソールでの構成詳細の表示

- コンソールを使用した検索の実行

- コンソールを使用したポリシー要素検索の実行

- ポリシー構成検索コントロールについて

- ポリシー要素の検索

- システム構成要素に対する検索の絞込み

- オンライン・ヘルプの使用

- コマンドライン・ツール

- ロギング、監査、パフォーマンスのモニタリング

4 サービス、証明書検証および共通設定の管理

- 前提条件

- 共通構成要素の概要

- 使用可能なサービスの有効化または無効化

- 共通設定の管理

- 「共通設定」ページについて

- 共通設定の管理

- 共通のコヒーレンス設定の表示

- グローバル証明書検証および失効の管理

- 証明書検証および失効リストについて

- 証明書失効リスト(CRL)の管理

- 証明書検証の管理

- CDPの構成

5 共通データ・ソースの管理

- 前提条件

- 共通データ・ソースの管理の概要

- ユーザー・アイデンティティ・ストアについて

- 複数のアイデンティティ・ストア

- ポリシーおよびセッション・データベース・ストアについて

- Oracle Access Manager構成データ・ファイルについて

- Oracle Access Managerセキュリティ・キーおよび組込みJavaキーストアについて

- Oracle Security Token Serviceキーストアについて

- ユーザー・アイデンティティ・ストアの管理

- ユーザー・アイデンティティ・ストアの登録ページについて

- 新規ユーザー・アイデンティティ・ストアの登録

- ユーザー・アイデンティティ・ストア登録の表示または編集

- ユーザー・アイデンティティ・ストア登録の削除

- デフォルト・ストアおよびシステム・ストアの設定

- デフォルト・ストアおよびシステム・ストアの設定について

- デフォルト・ストアおよびシステム・ストアの定義

- 管理者ロールの管理

- 管理者ロールの管理について

- 管理者ロールの管理

- コンソールを使用したポリシー・データベースの管理

- Oracle Access Managerのデータベース・デプロイメントについて

- セッション・データの個別データベースの構成

6 共通のOAMサーバー登録の管理

- 前提条件

- OAMサーバー登録および管理の概要

- OAM 11gとOAM 10gのサーバー側の違いについて

- 個々のOAMサーバー登録について

- 埋込みプロキシ・サーバーおよび下位互換性について

- OSSOとの組合せにおけるOAM 11g SSOと古いOAM 10g SSOについて

- OAMサーバーとWebgate間の通信について

- 個々のOAMサーバー登録の管理

- OAMサーバー登録のページについて

- 「OAMプロキシ」ページ

- 個々のサーバーの「コヒーレンス」ページ

- 新しいOAMサーバー・インスタンスの登録

- 個々のOAMサーバーおよびプロキシ設定の表示または編集

- 個々のサーバー登録の削除

7 セッションの管理

- 前提条件

- ユーザー・セッションとセッション管理の概要

- ユーザー・セッションのライフサイクルについて

- Oracle Coherenceとセッション管理

- ユーザー・セッションのライフサイクル設定の構成

- 共通セッションのライフサイクル設定ページについて

- 共通セッションのライフサイクル設定の表示または変更

- アクティブ・ユーザー・セッションの管理

- セッション管理ページについて

- アクティブ・ユーザー・セッションの管理

- セッション管理操作の検証

- セキュリティ

- セキュアHTTPSプロトコル

- コヒーレンス

- データベースの永続性

第III部 Oracle Access Managerの設定管理

8 Access Managerの設定の構成

- 前提条件

- Access Managerの設定の概要

- Access Managerのロード・バランシングとセキュア・エラー・モードの管理

- Access Managerのロード・バランシング設定とセキュア・エラー・モードについて

- OAMサーバーのロード・バランシングとセキュア・エラー・モードの管理

- SSOトークンとIPの検証の管理

- Access ManagerのSSOトークンとIPの検証の設定について

- SSOトークンとIPの検証の管理

- OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

- 簡易および証明書モードのトランスポート・セキュリティについて

- セキュア・サーバー通信の共通OAMプロキシ・ページについて

- OAMプロキシの簡易または証明書設定の表示または編集

- 実行時のポリシー評価キャッシュの管理

- 実行時のポリシー評価キャッシュについて

- 実行時のポリシー評価キャッシュの管理

- 認証モジュールの管理

- デフォルト認証モジュールおよびページについて

- Kerberos認証モジュール

- LDAP認証モジュール

- X509認証モジュール

- 既存のタイプの新しい認証モジュールの作成

- 認証モジュールの表示または編集

- 認証モジュールの削除

- カスタム認証モジュールの作成

- カスタム認証モジュールの作成について

- カスタム認証モジュールのプラグインについて

- カスタム認証モジュールの作成

9 コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録

- 前提条件

- ポリシーの強制エージェントの概要

- ポリシーの強制エージェントについて

- 事前登録されたIAMSuiteAgentについて

- パートナ(エージェントおよびアプリケーション)の登録について

- ファイル・システム変更および登録されたエージェントのアーティファクトについて

- コンソールを使用したOAMエージェントの登録および管理

- Webgate登録の作成と編集について

- ユーザー定義のWebgateパラメータについて

- Webgate用IPアドレスの検証について

- OAMエージェント登録の検索

- Webgateまたはプログラム・アクセス・クライアントの登録

- OAMエージェント登録の表示または編集

- Webgate登録の削除

- 10gおよび11g Webgateキャッシュのチューニング

- Webgateキャッシュの概要

- コンポーネント間のネットワーク・トラフィックの削減

- Webgateのポーリング頻度の変更

- コンソールを使用したOSSOエージェントの登録および管理

- OSSOエージェントおよびOSSOプロキシについて

- 「OSSOエージェントの作成」ページについて

- OSSOエージェント(mod_osso)登録の検索の絞込み

- OSSOエージェント(mod_osso)の登録

- OSSOエージェント(mod_osso)の登録の表示または編集

- OSSOエージェント(mod_osso)の削除

10 パートナ(エージェントおよびアプリケーション)のリモート登録

- 前提条件

- リモート・パートナの登録の概要

- 帯域内リモート登録について

- 帯域外リモート登録について

- キーの使用、生成、プロビジョニングおよび格納について

- リモート登録ツールについて

- リモート登録のリクエスト・ファイルについて

- OSSOリモート登録リクエスト

- 短い簡易化されたOAMリモート登録リクエスト

- リモート登録リクエストの共通要素

- リモート登録リクエストのOSSO固有の要素

- 完全なOAMリモート登録リクエスト

- 帯域外登録レスポンスについて

- 登録ツールの取得および設定

- 登録リクエストの作成

- 帯域内リモート登録の実行

- 帯域外リモート登録の実行

- リモート登録およびリソース保護の検証

- リモート登録の検証

- リモート登録後の認証、リソース保護およびアクセスの検証

- リモート管理モードの概要

- リモート・エージェント管理モードについて

- OSSOUpdateAgentRequest.xml

- OAM11GUpdateAgentRequest.xml

- OAMUpdateAgentRequest.xml

- リモート・アプリケーション・ドメイン管理モードについて

- ポリシー作成のリクエスト・ファイルについて

- ポリシー更新のリクエスト・ファイルについて

- <rregApplicationDomain>要素について

- エージェントのリモート管理

- リモート・エージェント更新の実行

- リモート・エージェント検証の実行

- リモート・エージェント削除の実行

- エージェントを使用しないアプリケーション・ドメインの作成または更新

第IV部 Oracle Access ManagerのSSO、ポリシーおよびテストの管理

11 OAMポリシー・モデルおよびシングル・サインオンの概要

- 前提条件

- OAM 11gポリシー・モデルとOAM 10gモデルの比較

- OAM 11gポリシー・モデルの概要

- リソース・タイプについて

- ホスト識別子について

- 認証、スキームおよびモジュールについて

- 認証スキームおよびモジュールについて

- 認証イベントのロギングおよび監査

- アプリケーション・ドメインおよびポリシーについて

- リソースおよびリソース定義について

- 認証ポリシー、レスポンスおよびリソースについて

- 認証ポリシー、リソース、制約およびレスポンスについて

- OAMシングル・サインオンの構成の概要

- SSOコンポーネントの概要

- シングル・サインオンのコンポーネントについて

- ユーザー・ログイン時のシングル・サインオンCookieについて

- シングル・サインオンCookieについて

- 11g OAM WebgateのOAMAuthnCookie

- 10g OAM WebgateのObSSOCookie

- OAM_REQのCookie

- mod_osso Cookie

- OAM 11gシングル・サインオンの実装タイプの概要

- アプリケーションのSSO

- OAM 11gを使用したシングル・サインオン

- ネットワーク間ドメインおよびOracle Access Manager 11g

- OAM 11g SSO処理の概要

- SSOログイン処理について

- ログイン

- セルフサービス・プロビジョニング・アプリケーションを使用したログイン

- Oracle ADFセキュリティを使用したアプリケーションのログインおよび自動ログイン

- OAMエージェントを使用したSSOログイン処理について

- OSSOエージェント(mod_osso)を使用したSSOログイン処理について

- 混在リリース・エージェントを使用したシングル・サインオン処理について

12 ポリシー・コンポーネントの管理

- 前提条件

- ポリシー・コンポーネント管理の概要

- リソース・タイプの管理

- リソース・タイプおよびその使用について

- リソース・タイプ・ページについて

- 特定のリソース・タイプの検索

- ホスト識別子の管理

- ホスト識別子について

- ホスト識別子の使用方法

- ホスト識別子のガイドライン

- ホスト識別子のバリエーション

- 仮想Webホスティングについて

- リバース・プロキシの背後へのWebgateの配置

- Apache以外のWebサーバーの仮想ホストの構成

- 仮想ホスト、ディレクトリまたはファイルとのApache用Webgateの関連付け

- ホスト識別子ページについて

- ホスト識別子の作成

- ホスト識別子定義の検索

- ホスト識別子定義の表示または編集

- ホスト識別子定義の削除

- 認証スキームの管理

- 認証スキーム・ページについて

- 事前構成済認証スキーム

- チャレンジ・メソッドについて

- 認証スキームのチャレンジ・パラメータについて

- 認証モジュールについて

- マルチレベル認証について

- 認証スキームの作成

- 認証スキームの検索

- 認証スキームの表示または編集

- 認証スキームの削除

- 暗号化Cookieのチャレンジ・パラメータの構成

- 暗号化CookieのssoCookieチャレンジ・パラメータについて

- 暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

- 暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

13 リソースを保護してSSOを有効化するポリシーの管理

- 前提条件

- アプリケーション・ドメインの作成の概要

- 自動的なアプリケーション・ドメインの作成について

- 手動のアプリケーション・ドメインの作成について

- アプリケーション・ドメインおよびポリシーの詳細分析

- アプリケーション・ドメインの一般詳細

- 生成されたアプリケーション・ドメインのデフォルトのリソース

- 生成されたアプリケーション・ドメインのデフォルトの認証ポリシー

- 生成されたアプリケーション・ドメインのデフォルトの認可ポリシー

- トークン発行ポリシーについて

- コンソールを使用したアプリケーション・ドメインの管理

- アプリケーション・ドメイン・ページについて

- 新しいアプリケーション・ドメインの手動作成

- アプリケーション・ドメインの検索

- アプリケーション・ドメインの表示または編集

- アプリケーション・ドメインおよびその内容の削除

- ポリシーで使用するリソース定義の追加および管理

- アプリケーション・ドメインのリソース定義ページについて

- リソース定義のリソース・タイプについて

- リソース定義のホスト識別子について

- リソースURLについて

- ランタイム・リソース評価について

- アプリケーション・ドメインへのリソース定義の追加

- リソース定義の検索

- 特定のリソース定義の検索について

- 特定のリソース定義の検索

- アプリケーション・ドメインのリソース定義の表示または編集

- アプリケーション・ドメインからのリソース定義の削除

- 特定のリソースの認証ポリシーの定義

- 認証ポリシー・ページについて

- 認証ポリシーのリソースについて

- 認証ポリシーおよびリソースの追加

- 認証ポリシーの検索

- 認証ポリシーの表示または編集

- 認証ポリシーの削除

- 特定のリソースの認可ポリシーの定義

- 特定のリソースの認可ポリシーについて

- 認可ポリシーおよび特定のリソースの追加

- 認可ポリシーの検索

- 認可ポリシーおよびリソースの表示または編集

- 認可ポリシーの削除

- SSOのポリシー・レスポンスの概要

- SSOの認証および認可ポリシー・レスポンスについて

- ポリシー・レスポンスの言語について

- ポリシー・レスポンスのネームスペースおよび変数名について

- SSOのポリシー・レスポンスの構築について

- 単純なレスポンス

- 複合的および複雑なレスポンス

- ポリシー・レスポンス処理について

- SSOのポリシー・レスポンスの追加および管理

- SSOのポリシー・レスポンスの追加

- SSOのポリシー・レスポンスの表示、編集または削除

- 認可制約の概要

- 許可または拒否タイプ制約について

- 制約のユーザーおよびグループの分類について

- 制約に基づく認可レスポンスのガイドライン

- 制約および一般的な認可ポリシーの詳細について

- 「制約の追加」ウィンドウについて

- アイデンティティ・クラス制約について

- IP4Rangeクラス制約について

- 一時的クラス制約について

- 認可ポリシー制約の定義

- アイデンティティ・クラス制約の定義

- IP4Rangeクラス制約の定義

- 一時的クラス制約の定義

- 認可ポリシー制約の表示、編集または削除

- アプリケーション・ドメインの認証および認可の検証

- 例: 事前シード済のIAM Suiteアプリケーション・ドメインおよびポリシー

14 アクセス・テスターを使用した接続性とポリシーの検証

- 前提条件

- OAM 11gアクセス・テスターの概要

- OAMエージェントとサーバーの相互運用性について

- アクセス・テスターのセキュリティと処理について

- アクセス・テスター・モードと管理者の対話操作について

- アクセス・テスターのインストールと起動

- アクセス・テスターのインストール

- アクセス・テスターでサポートされているシステム・プロパティについて

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

- アクセス・テスターのコマンドライン・モードについて

- システム・プロパティを指定してアクセス・テスターを開始

- アクセス・テスター・コンソールとナビゲーションの概要

- アクセス・テスターのメニューとコマンド・ボタン

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- アクセス・テスターとOAMサーバー間の接続の確立

- 「接続」パネルについて

- アクセス・テスターとOAMサーバーの接続

- アクセス・テスター・コンソールからリソース保護を検証

- 保護リソースのURIパネルについて

- リソース保護の検証

- アクセス・テスター・コンソールからユーザー認証をテスト

- 「ユーザー・アイデンティティ」パネルについて

- ユーザー資格証明による認証のテスト

- アクセス・テスター・コンソールからユーザー認可をテスト

- リクエスト待機時間の監視

- テスト・ケースおよびスクリプトの作成と管理

- テスト・ケースとテスト・スクリプトについて

- テスト・ケースの取得

- 入力テスト・スクリプトの作成

- 入力テスト・スクリプトの作成について

- 入力テスト・スクリプトの作成

- 入力テスト・スクリプトのパーソナライズ

- テスト・スクリプトのカスタマイズについて

- テスト・スクリプトのカスタマイズ

- テスト・スクリプトの実行

- テスト・スクリプトの実行について

- テスト・スクリプトの実行

- スクリプト、ログ・ファイル、および統計の評価

- テスト結果の評価について

- 保存された接続構成ファイルについて

- 作成された入力テスト・スクリプトについて

- テスト実行結果が格納されたターゲット出力ファイルについて

- 統計ドキュメントについて

- 実行ログについて

15 OAM 11gの集中ログアウトの構成

- 前提条件

- OAM 11gの集中ログアウトの概要

- OAM 11gエージェントおよびサーバー使用時の集中ログアウトについて

- OAM 10gエージェントとOAM 11gサーバー使用時の集中ログアウトについて

- IAMSuiteAgent使用時の集中ログアウトについて

- OSSOエージェント(mod_OSSO)とOAM 11g使用時の集中ログアウトについて

- Oracle ADFセキュリティを使用するアプリケーションでの集中ログアウトについて

- OAM 11gサーバー使用時の11g Webgateの集中ログアウト構成

- 11g Webgateの集中ログアウト構成について

- 11g Webgateの集中ログアウト構成

- IAMSuiteAgentの集中ログアウト構成

- OAM 11gサーバー使用時の10g Webgateの集中ログアウト構成

- OAM 11gサーバー使用時の10g Webgateの集中ログアウト処理について

- OAM 11gサーバー使用時のOAM 10gエージェントの集中ログアウト・スクリプトについて

- OAM 11g使用時の10g Webgateの集中ログアウト構成

- Oracle ADFコード・アプリケーションの集中ログアウト構成

- Oracle ADF標準に従ってコーディングされたアプリケーションの集中ログアウト処理について

- OAM 11g使用時のADFコード・アプリケーションの集中ログアウト構成

- ログアウト時のカスタムmod_osso Cookieの削除

- グローバル・サインオンと集中ログアウトの検証

- グローバル・サインオンの確認

- 様々なエージェント・タイプを使用したグローバル・サインオンの検証

- 集中ログアウトの監視

第V部 Oracle Security Token Service

16 Oracle Security Token Serviceの実装シナリオ

- 前提条件

- 一般的なトークン・エコシステム

- シナリオ: OAMトークンを使用したアイデンティティ伝播

- コンポーネント処理: OAMトークンを使用したアイデンティティ伝播

- RST属性とランタイム処理

- 構成要件: OAMトークンを使用したアイデンティティ伝播

- 実装のテスト

- シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

- ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

- ユーザー名トークンを使用したアイデンティティ伝播のRST属性および処理

- 構成要件: ユーザー名トークンを使用したアイデンティティ伝播

17 Oracle Security Token Serviceの設定値と設定の管理

- 前提条件

- Oracle Security Token Service構成の概要

- インストール後の構成

- サーバーとOracle Security Token Serviceについて

- Oracle Security Token Serviceクライアントについて

- エージェントとOracle Security Token Serviceについて

- Oracle Security Token Serviceエンドポイントとポリシーについて

- Oracle Security Token Serviceの有効化および無効化

- Oracle Security Token ServiceとOracle Access Managerコンソールについて

- Oracle Security Token Service管理者について

- Oracle Security Token Serviceへのログインおよびサインアウトについて

- Oracle Security Token Serviceのサービスの有効化について

- Oracle Security Token Serviceのサービスの有効化および無効化

- Oracle Access Managerコンソールを使用したセキュリティ・トークン・サービスの設定の定義

- 「セキュリティ・トークン・サービスの設定」について

- 「セキュリティ・トークン・サービスの設定」の管理

- Oracle WSMエージェントのためのWSSポリシーの使用および管理

- Webサービス・セキュリティ・ポリシーの使用および変更

- Oracle Security Token ServiceのためのWSSポリシーの管理: クラスパス

- Oracle Security Token ServiceのためのWSSポリシーの管理: Oracle WSM Policy Manager

- WSSプロトコル通信のためのOWSMの構成

- Oracle Security Token ServiceのOracle WSMエージェントのWS-Securityポリシーについて

- Oracle WSMキーストア・パスワードの取得

- Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出

- Oracle WSMキーストアへの信頼できる証明書の追加

- Oracle WSMキーストア内の信頼できる証明書の検証

- WSS KerberosポリシーのためのOracle WSMエージェントの構成

- Oracle Security Token Serviceポリシーの管理および移行

- Oracle Security Token Serviceポリシーの管理および移行について

- Oracle Security Token Serviceポリシーの管理

- Oracle Security Token Serviceポリシーの移行

- Oracle Security Token Serviceメッセージのロギングの概要

- Oracle Security Token Serviceの監査の概要

- Oracle Security Token Service監査レコードの格納について

- 監査レポートおよびOracle Business Intelligence Publisherについて

- 監査ログについて

- Oracle Security Token Service管理イベントとランタイム・イベントの監査

- すべてのイベントに共通の監査レコード・コンテンツについて

- 監査可能なOracle Security Token Service管理イベント

- 監査可能なOracle Security Token Serviceランタイム・イベント

18 Oracle Security Token Serviceの証明書と鍵の管理

- 前提条件

- Oracle Security Token Serviceの証明書と鍵の概要

- キーストアとOracle Security Token Serviceについて

- Oracle Web Services Managerのキーストア(default-keystore.jks)について

- リクエスタ証明書のOPSSキーストアの使用について

- Oracle Security Token Serviceの暗号化/署名鍵の管理

- システム・キーストア(.oamkeystore)・パスワードの取得

- システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

- 新しいエントリの追加

- 署名鍵を使用するためのSAML発行テンプレートの構成

- デフォルトの暗号化鍵の設定

- Oracle Security Token Service証明書の抽出

- 証明書取得サービスの使用

- WS-Trust通信のパートナ・キーの管理

- パートナ証明書について

- 実行時のリライイング・パーティの証明書のダウンロードについて

- パートナの署名証明書または暗号化証明書の設定

- 証明書検証の管理

- 信頼アンカー・ストア(amtruststore)のパスワードの取得

- 信頼アンカー・ストア(amtruststore)の管理

- 証明書失効リストの管理

- Oracle Security Token Serviceのカスタム信頼アンカー・ストアの使用

19 テンプレート、エンドポイントおよびポリシーの管理

- 前提条件

- 概要

- 既存のテンプレートの検索

- テンプレートの検索コントロールについて

- テンプレートの検索

- トークン発行テンプレートの管理

- トークン発行テンプレートの管理について

- トークン発行テンプレートの管理

- トークン検証テンプレートの管理

- トークン検証テンプレートの管理について

- トークン検証テンプレートの管理

- Oracle Security Token Serviceエンドポイントの管理

- エンドポイントの管理について

- エンドポイントの管理

- Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理

- トークン発行ポリシーについて

- トークン発行ポリシーおよび制約の管理について

- トークン発行ポリシーおよび制約の管理

- TokenServiceRPタイプのリソースの管理

- Oracle Access Manager内のTokenServiceRPタイプのリソースの管理について

- アプリケーション・ドメイン内のTokenServiceRPタイプのリソースの管理

20 Token Serviceパートナとパートナ・プロファイルの管理

- 前提条件

- Token Serviceパートナとパートナ・プロファイルの概要

- Token Serviceパートナについて

- パートナ・プロファイルについて

- パートナおよびプロファイル・データについて

- Token Serviceパートナの管理

- Token Serviceパートナの管理について

- Token Serviceパートナの管理

- パートナ検索の絞込み

- Token Serviceパートナ・プロファイルの管理

- パートナ・プロファイルの管理について

- Token Serviceパートナ・プロファイルの管理

- プロファイル検索の絞込み

21 Oracle Security Token Servicesのトラブルシューティング

- 認可の問題

- エンドポイントの問題

- マッピング操作の問題

第VI部 共通のロギング、監査、パフォーマンス・モニタリング

22 コンポーネント・イベント・メッセージのロギング

- 前提条件

- コンポーネント・イベント・メッセージのロギングの概要

- コンポーネント・ロガーについて

- サンプル・ロガーとログ・ハンドラ定義

- ロギング・レベルについて

- Oracle Access Managerのロギング構成

- Oracle Access Managerのロガー・レベルの変更

- Oracle Access Manager固有のロガーとログ・ハンドラの追加

- Oracle Security Token Serviceのロギング構成

- Oracle Security Token Serviceのロギング構成

- Oracle Security Token Serviceのログ・レベルとログ詳細の定義

- ランタイム・イベント・ロギング構成の検証

23 Webgateイベント・メッセージのロギング

- ロギング、ログ・レベルおよびログ出力について

- ログ・レベルについて

- ログ出力について

- ログ構成ファイルのパスおよび内容について

- ログ構成ファイルのパスおよび名前

- ログ構成ファイルの内容

- ファイルに対する変更が有効化した場合

- ログ・ファイル内のコメントについて

- ファイルまたはシステム・ファイルへのログ出力の送信について

- ログ構成ファイルの構造およびパラメータ

- ログ構成ファイルのヘッダー

- 最初の複合リスト

- 単純なリストおよびロギングしきい値

- 2番目の複合リストおよびログ・ハンドラ

- モジュール固有のロギングのリスト

- フィルタ・リスト

- XML要素の順序について

- ロギング・レベルのアクティブ化および抑制について

- ログ・ハンドラの優先順位について

- 必須のログ・ハンドラ構成パラメータ

- デフォルトのログ構成ファイルの設定

- デフォルトのログ構成ファイルの設定の説明

- 異なるデータのタイプへの異なるしきい値レベルの構成

- MODULE_CONFIGセクションについて

- ログ構成ファイルのモジュール固有ロギング・セクションの場所

- ログを記録できるモジュールのリスト

- 機能またはモジュールに対するログ・レベルしきい値の構成

- 機密属性のフィルタ処理

24 管理イベントおよびランタイム・イベントの監査

- 前提条件

- 監査の概要

- Oracle Access Managerの監査構成について

- Oracle Access Manager監査記録ストレージについて

- 監査レポートおよびOracle Business Intelligence Publisherについて

- 監査ログについて

- 監査可能なOracle Access Managerイベント

- 監査可能なOracle Access Manager管理イベント

- 監査可能なOAMランタイム・イベント

- 認証イベントの監査について

- Oracle Access Manager with Oracle Security Token Serviceの監査の設定

- 監査データベース・ストアの設定

- Oracle Business Intelligence Publisher EEの準備

- Oracle Access Managerコンソールでの監査構成セクションについて

- Oracle Access Managerの共通監査設定の追加、表示、または編集

- Oracle Access Managerの監査とレポートの検証

25 Oracle Access Managerコンソールを使用したパフォーマンスの監視

- パフォーマンス・モニタリングの概要

- コンソールを使用したサーバー・パフォーマンス・メトリックの監視

- サーバー・インスタンス・パフォーマンスの監視

- サーバー・メトリックの確認

- SSOエージェント・パフォーマンス・メトリックの監視

- SSOエージェント・パフォーマンス・メトリックの監視

- OAMエージェント・メトリックの確認

- OSSOエージェント・メトリックの確認

- OXMプロキシ・パフォーマンス・チューニング・パラメータ

- OAMプロキシ・メトリックについて

- OAMプロキシ・サーバーのチューニング・パラメータ

26 Fusion Middleware Controlによるパフォーマンスおよびログの監視

- 前提条件

- Fusion Middleware Controlの概要

- Fusion Middleware Controlへのログインとログアウト

- Fusion Middleware Controlのログイン・ページについて

- Fusion Middleware Controlへのログイン

- Fusion Middleware Controlからのログアウト

- Fusion Middleware Controlでのメニューとページの表示

- Fusion Middleware Controlの「ファーム」ページについて

- Fusion Middleware Controlのコンテキスト・メニューとページについて

- Fusion Middleware Controlでのコンテキスト・メニューとターゲット詳細の表示

- Fusion Middleware Controlでのパフォーマンスの表示

- Fusion Middleware Controlの「パフォーマンス概要」ページについて

- Access Managerコンポーネント・ページ

- セキュリティ・トークン・サービス・コンポーネント・ページ

- 「メトリック・パレット」と「パフォーマンス・サマリー」ページについて

- Fusion Middleware Controlのパフォーマンス・メトリックの表示

- コンポーネント固有のパフォーマンス詳細の表示

- Fusion Middleware Controlでのログ・レベル変更の管理

- 動的なログ・レベルの変更について

- Fusion Middleware Controlを使用した動的なログ・レベルの設定

- Fusion Middleware Controlによるログ・ファイル構成の管理

- ログ・ファイルの構成について

- Fusion Middleware Controlを使用したログ・ファイル構成の管理

- Fusion Middleware Controlでのログ・メッセージの表示

- ログ・メッセージの検索、表示およびエクスポートについて

- Fusion Middleware Controlによるログ・メッセージの表示

- Fusion Middleware ControlでのMBeanの表示

- システムMBeanブラウザについて

- MBeanの管理

- Fusion Middleware Controlでのファーム・ルーティング・トポロジの表示

- ルーティング・トポロジについて

- Fusion Middleware Controlを使用したルーティング・トポロジの表示

第VII部 Oracle Access Manager 11gでの10g Webgateの使用

27 OAM 11gでのOAM 10g Webgateの管理

- 前提条件

- OAM 11g用のOAM 10gエージェントの紹介

- IAMSuiteAgentのOAM 10g Webgateへの置換について

- レガシーOAM 10gデプロイメントとWebgateについて

- OAM 11gで使用する新規OAM 10g Webgateのインストールについて

- OAM 11gでの10g Webgateのプロビジョニング

- OAM 11g用の最新のOAM 10g Webgateの検索とインストール

- OAM 11gで使用する新規10g Webgateのインストールの準備

- OAM 11gで使用する10g Webgateの検索とダウンロード

- Webgate 10gのインストールの開始

- トランスポート・セキュリティ・モードの指定

- セキュアな通信のための証明書のリクエストまたはインストール

- Webgateの構成詳細の指定

- Webgate Webサーバー構成の更新

- Webサーバーの手動構成

- Webgateのインストール終了

- アーティファクトと証明書のインストール

- Webgateのインストールの確認

- OAM 11gでの10g Webgateの集中ログアウトの構成

- IAMSuiteAgentのOAM 10g Webgateへの置換

- IAMSuiteAgentを10g Webgateに入れ替えるためのプロビジョニング

- IAMSuiteAgentを置換する10g Webgateのインストール

- WebLogicサーバー・プラグインの更新

- OAM/OIM統合用のAutoLoginホスト識別子の確認

- WebLogic用OAMセキュリティ・プロバイダの構成

- セキュリティ・プロバイダについて

- 10g Webgate用のセキュリティ・プロバイダの設定

- IAMSuiteAgentの無効化

- 検証

- WebLogicコンテナへのアプリケーションのデプロイメント

- OAM 11gデプロイメントからの10g Webgateの削除

28 Apache、OHS、IHSの10g Webgate用の構成

- 前提条件

- Oracle HTTP ServerとOracle Access Managerについて

- ApacheおよびIHS v2 Webgateを使用したOracle Access Managerについて

- Apache HTTP Serverについて

- IBM HTTP Serverについて

- ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて

- Apache v2アーキテクチャとOracle Access Managerについて

- Oracle HTTP Server、IHS、Apache v2 Webサーバーの要件

- IHS2 Webサーバーの要件

- ApacheおよびIHS v2リバース・プロキシ・サーバーの要件

- Apache v2 Webサーバーの要件

- Webサーバーの準備

- IHS v2 Webサーバーの準備

- IHS v2インストール用ホストの準備

- IBM HTTP Server v2のインストール

- SSL機能の設定

- セキュアな仮想ホストの起動

- Linux上でのApacheおよびOracle HTTP Server Webサーバー

- LinuxおよびWindowsプラットフォームでのOracle HTTP Server Webサーバーの準備

- Oracle HTTP Serverのクライアント証明書の設定

- UNIX上でのApache v2 Webサーバーの準備

- AIX上でのApache v2 SSL Webサーバーの準備

- Windows上でのApache v2 Webサーバーの準備

- Apache v2およびIHS v2のリバース・プロキシの起動

- Apache v2 Webサーバーのリバース・プロキシの起動

- IHS v2 Webサーバーのリバース・プロキシの起動

- Oracle Access Manager Webgate用のhttpd.conf更新の検証

- Webgateの詳細検証

- 言語エンコーディングの検証

- Oracle Access Manager Webgate用のOracle HTTP Serverのチューニング

- OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング

- Oracle HTTP Server/Apache Preforkモジュールのチューニング

- Oracle HTTP Server/Apache MPMモジュールのチューニング

- カーネル・パラメータのチューニング

- Oracle HTTP Server Webサーバーの起動と停止

- Oracle Access Manager Webgate用のApache/IHS v2のチューニング

- アンインストール後のWebサーバー構成変更の削除

- 役立つ情報

29 10g Webgate用のIIS Webサーバーの構成

- 前提条件

- IIS WebサーバーでのWebgateのガイドライン

- ISAPI Webgateのガイドライン

- IIS v7対応Webgate

- IIS v6対応Webgate

- 1つのIIS 6インスタンスに対する複数のWebgate

- IIS 7対応Webgateのインストールの前提条件

- IIS 7対応10g Webgateのインストールの前提条件

- IIS 7対応32ビットWebgateのインストールの前提条件

- Windows 2008でのIIS 7 Webサーバー構成の更新

- IISでのWebgateインストールの完了

- IIS Webサーバーでのクライアント証明書認証の有効化

- ISAPIフィルタの並替え

- POSTデータのパススルー機能の有効化

- ISAPI Webgate 10.1.4.2.3について

- POSTデータのパススルー機能について

- パススルーの実装: ワーカー・プロセス分離モードのIIS 6.0

- IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルーの実装

- デフォルト・サイトが設定されていない場合のWebサイトの保護

- 1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

- 複数のWebgateシナリオにおける各IIS 7 Webgateのインストール

- 複数のIIS 7 Webgateに対する偽装DLLの設定

- 複数のIIS 7 Webgateに対するクライアント認証の有効化

- パススルー機能のためのIIS 7 Webgateの構成

- IIS 7 Webgateのインストールの確認

- 1つのIIS 6インスタンスに対する複数のWebgateのインストールと構成

- 複数のWebgateシナリオにおける各Webgateのインストール

- 複数のWebgateに対する偽装DLLの設定

- 複数のWebgateに対するSSLとクライアント認証の有効化

- 複数のWebgateのインストールの確認

- 64ビットWebgateインストールの終了

- アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証の設定

- クライアント証明書認証の設定

- IISへのWebgateのインストールの確認

- IIS Webサーバーの起動、停止および再起動

- アンインストール前のWebサーバー構成変更の削除

30 10g Webgate用のISAサーバーの構成

- 前提条件

- Oracle Access ManagerおよびISAサーバーについて

- 互換性とプラットフォームのサポート

- ISAサーバー用のWebgateのインストールおよび構成

- ISAサーバーでのWebgateのインストール

- /accessディレクトリの権限の変更

- ISAPI Webgate用のISAサーバーの構成

- Oracle Access ManagerプラグインのISAサーバーWebフィルタとしての登録

- ISA WebフィルタのISAファイアウォール・ポリシーの構成

- ISAPIフィルタの並替え

- ISAサーバーの起動、停止および再起動

- ISAサーバーのWebgateをアンインストールする前のOracle Access Managerフィルタの削除

31 10g Webgate用のLotus Domino Webサーバーの構成

- 前提条件

- Domino Webサーバーのインストール

- 最初のDomino Webサーバーの設定

- Domino Webサーバーの起動

- SSLの有効化(オプション)

- Dominoセキュリティ(DSAPI)フィルタのインストール

- Webgateインストールの完了

第VIII部 付録

A 共存の概要: OAM 11gとOSSO 10g

- 前提条件

- アップグレードとOracleAS 10g SSOとの共存の概要

- アップグレード前および後のトポロジおよび認証の例

- アップグレード前のOSSO 10gトポロジについて

- フロントエンド・プロキシ・サーバー上のmod_oc4jを含む1つのOSSO 10g

- アップグレード後のトポロジと共存について

- アップグレード後: mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

- アップグレード後: プロキシ・サーバーなし

- アップグレード後のOAM 11gとの共存の検証の概要

- アップグレード後のSSOについて

- アップグレード後のOSSO 10g認証について

- アップグレード後の共存の検証

- アップグレード後の登録とポリシーの検証

- OSSO 10gを使用して保護されているパートナ・アプリケーションの例

- ポリシー施行エージェントの詳細

- 共有コンポーネント: migratedSSOPartnersのホスト識別子

- migratedSSOPartnersアプリケーション・ドメインのリソース

- migratedSSOPartnersアプリケーション・ドメインの認証ポリシー

- Oracle Access Managerにより保護されているリソースを含むアップグレード後のSSOの検証

- OSSOにより保護されているリソースを含むアップグレード後のSSOの検証

B OAM 11gのソース環境からターゲット環境への移行

- 前提条件

- 移行の概要

- デプロイメント・タイプについて

- Oracle Access Managerデータについて

- 共通の移行タスクについて

- 新しいターゲット環境と既存のターゲット環境の比較について

- 移行の方法とツールの概要

- Oracle Access Managerソース・データを伝播する方法について

- OSSOパートナのあるOAMインスタンスから別のインスタンスへの移行について

- ターゲット・ユーザー・アイデンティティ・ストアの構成とデータの移行について

- ポリシー競合解決について

- 各アプリケーション・ドメインの依存関係の構築について

- 移行の計画

- 移行方法の選択

- ソースとターゲット環境間に相違がない

- デプロイメント・インベントリの作成

- バックアップ方針およびリカバリ方針の作成

- テストの作成

- 変更伝播について

- スケジュールと通知

- Oracle Access Manager 11gデータの移行

- Oracle Access Manager 11gソース・データのエクスポート

- Oracle Access Managerデータのターゲットへのインポート

C Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合

- Oracle Platform Security ServicesおよびOracle Application Developer Frameworkの概要

- Oracle Platform Security Servicesシングル・サインオン・フレームワーク

- Oracle Application Developer Framework

- Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したOAM 11gとWebアプリケーションの統合

- OAM 11g用のSSO構成の例

- SSOプロバイダ構成詳細

- 実行時のアプリケーションドリブン認証の確認

D OAM 10g Webgateの国際化とマルチバイト・データ・サポート

- 国際化とマルチバイト・データ・サポートの概要

- Oracle Access Managerでローカライズされたメッセージの言語

- 双方向言語サポート

- UTF-8エンコーディング

E Oracle Access Manager 11gとの安全な通信

- 前提条件

- OAM 11gサーバーとWebgate間の安全な通信の概要

- 証明書、認証局および暗号化鍵について

- セキュリティ・モードおよびX509Scheme認証について

- Importcertツールについて

- 証明書モードのOAMテスターのクライアント・キーストア生成

- OAM 11gの証明書モード通信の構成

- 証明書モードの暗号化およびファイルについて

- OAMサーバー用の証明書リクエストおよび秘密鍵の生成

- OAMキーストア別名およびパスワードの取得

- 信頼できる、署名された証明書チェーンをキーストアへインポート

- 証明書詳細をAccess Manager設定に追加

- Webgate用の秘密鍵および証明書リクエストの生成

- 証明書を使用するようにWebgateを更新

- OAM 11gの簡易モード通信の構成

- 簡易モード、暗号化および鍵について

- 簡易モード用のグローバル・パスフレーズの取得

- 簡易モード用Webgate登録の更新

- 簡易モード構成の検証

F 管理者用のカスタムWLSTコマンドの概要

- 前提条件

- WebLogic Scripting Toolコマンドの概要

- WLSTコマンド・サマリー: Oracle Access Manager

- WLSTコマンド・サマリー: Oracle Security Token Service

- WLSTコマンドの実行

- WLSTシェルの開始とログイン

- 高可用性環境でのリクエスト・キャッシュ・タイプの変更

G IPv6クライアント用のOAM 11gの構成

- 前提条件

- Oracle Access Manager 11gおよびIPv6の概要

- OAM 11gでのIPv6とチャレンジ・リダイレクトの構成

- 考慮事項

- IPv6の構成: OAM 11gおよびWebgate用の別個のプロキシ

H デプロイメント固有ページの作成

- シングル・サインオン・サーバーでのデプロイメント固有ページの使用方法

- パスワード変更ページの動作

- パスワードが失効している場合

- パスワードが間もなく失効する場合

- 猶予ログインが有効

- パスワード変更の強制

- デプロイメント固有ページの記述方法

- ログイン・ページのパラメータ

- パスワードを忘れた場合

- パスワード変更ページのパラメータ

- シングル・サインオフ・ページのパラメータ

- 外部アプリケーション・ログイン・ページのパラメータ

- ページのエラー・コード

- ログイン・ページのエラー・コード

- ログイン後のメッセージ

- パスワード変更ページのエラー・コード

- 外部アプリケーション・ログイン変更ページのエラー・コード

- グローバリゼーション・サポートの追加

- ページに表示する言語の決定

- Accept-Languageヘッダーを使用したページの決定

- ページ・ロジックを使用した言語の決定

- ページのレンダリング

- デプロイメント固有ページに関するガイドライン

- デプロイメント固有ページのインストール

- policy.propertiesを使用したログイン・ページ、シングル・サインオフ・ページおよびパスワード変更ページのインストール

- policy.propertiesを使用したワイヤレスのログイン・ページとパスワード変更ページのインストール

- policy.propertiesを使用した外部アプリケーション・ログイン・ページのインストール

- デプロイメント固有ページの例

- カスタム・クラスの使用

- 外部アプリケーションの追加

I トラブルシューティング

- OAM 11gのトラブルシューティングの概要

- システム分析と問題例について

- LDAPサーバーまたはアイデンティティ・ストアの問題について

- OAMサーバーまたはホストの問題について

- エージェント側の構成およびロードの問題について

- 実行時データベース(監査またはセッション・データ)の問題について

- 変更の伝播またはアクティブ化の問題について

- ポリシー・ストア・データベースの問題について

- Oracle Access Manager Consoleの状態が矛盾している

- WebLogic Serverのインストール時に不正なJavaパスが指定されると管理サーバーが起動しない

- エージェント名が一意ではない

- アプリケーションURLの要件

- 認証の問題

- 匿名認証の問題

- X.509保護リソースおよびシングル・サインオフ

- 認可の問題

- 認証LDAPまたはデータベースにアクセスできない

- 構成が見つからない

- ...の構成が存在しない

- 部分トリガーが見つからない

- サービス攻撃の拒否

- OAMサーバーを負荷でクラッシュしないようにする

- ネットワーク遅延に対する補償

- OAMサーバーを大量のHTTPリクエストから守る

- 新しくインストールしたOAM 10g Webgateでのデプロイメント

- OAM 10g Webgateでの認証の問題

- OAM 10g Webgateでのログアウトの問題

- OAM 11gの初期化およびパフォーマンスの問題の診断

- 初期化の問題の診断

- パフォーマンスの問題の診断

- メモリー不足の問題のヒープ・ダンプを使用した診断

- IIS WebサーバーでのWindowsのチャレンジ/レスポンス認証の無効化

- UserIdentityStore1タイプを変更すると管理者がロックアウトされる可能性がある

- IIS Webサーバーの問題

- フォーム認証またはパススルーが動作しない

- IISおよび一般Webコンポーネントのガイドライン

- IIS v6 Webサーバーの問題

- ページが表示されないエラー

- IIS DLLの削除および再インストール

- jpsロガー・クラスのインスタンス化警告が認証時にログに記録される

- 言語と翻訳

- 自動生成された説明が翻訳されない

- ロケール、言語、およびOracle Access Managerコンソール・ログイン・ページ

- コンソールがきれいに表示されない

- 保護されたページへのログインの失敗

- OAMメトリック永続性タイマーIllegalStateException: SafeCluster

- 部分的なクラスタ障害および断続的なログインおよびログアウト障害

- 登録の問題

- Rowkeyに主キー属性がないエラー

- SELinuxの問題

- セッションの問題

- セッション偽装がデフォルトでは有効になっていない

- Oracle Identity Federationと統合されたOracle Access Managerとのセッション

- SSLとオープンな通信の比較

- 起動の問題

- OAMサーバー・クロックの同期化

- Coherenceの使用

- エラーの検証

- Webサーバーの問題

- Apache Webサーバー上のサーバー障害

- HP-UX上のApache v2

- Red Hat Enterprise Linux 4にバンドルされたApache v2

- Security-Enhanced LinuxにバンドルされたApache v2

- Webgateのmpm_worker_moduleを使用したUNIX上のApache v2

- Domino Webサーバーの問題

- エラー、アクセスの消失および予期しない動作

- ISA Webサーバーの既知の問題

- LinuxThreadsでOracle HTTP Serverが開始しない

- Linux Red Hat 4上でOracle HTTP Server Webgateが初期化されない

- Oracle HTTP Server Web Server構成ファイルの問題

- IIS v6 Webサーバーの問題

- Sun Webサーバーの開始時のPCLOSEエラー

- IIS DLLの削除および再インストール

- Windowsネイティブ認証

索引

例一覧

- 10-1 OSSORequest.xml

- 10-2 サンプルの簡易リクエスト: OAMRequest_short.xml

- 14-1 接続構成ファイル

- 14-2 生成された入力テストスクリプト

- 14-3 テストの実行中に生成された出力ファイル

- 14-4 統計ドキュメントの例

- 14-5 実行ログ

- 15-1 logout.htmlのスクリプト

- 16-1 交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン

- 16-2 OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス

- 22-1 Oracle Access Managerロガーとログ・ハンドラの構成

- 23-1 コメントのあるデフォルトのログ構成ファイル

- 23-2 グローバル設定を含む単純なリスト(oblog_config_wg.xmlファイルの最初の複合リスト)

- 23-3 FILTER_LISTによるログ・ファイル内の機密属性のマスキング

- 23-4 有効な名前/値リスト

- 23-5 別の有効な名前/値リスト

- 23-6 名前/値リストの開始タグ

- 23-7 名前/値リストの開始タグ

- 23-8 埋込みコメントなしのデフォルトのログ構成ファイル

- 27-1 mod_wl_ohs.confでの10g Webgate用の更新

- C-1 OAM 11g用のSSO構成の例

図一覧

- 1-1 Oracle Access Manager 11gのコンポーネントおよびサービス

- 1-2 Oracle Access Manager 11gのコンポーネントの分散

- 1-3 Oracle STSのアーキテクチャ

- 1-4 Oracle STSのトークン・サポート

- 1-5 一元化された認証局でのトークン変換

- 1-6 ファイアウォールの背後でのトークンの変換

- 1-7 WebサービスSSO

- 3-1 Oracle Access Manager 11gの「ログイン」ページ

- 3-2 右上にあるサインアウトのリンク

- 3-3 Oracle Access Managerコンソールの「ようこそ」ページ

- 3-4 メニューおよびツール・バーがあるナビゲーション・ツリーの例

- 3-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー

- 3-6 「表示」メニュー

- 3-7 「アクション」メニュー

- 3-8 開いているページのタブおよびページ・コントロール

- 3-9 「システム構成」タブ(折りたたみ済および完全に展開済)

- 3-10 「ポリシー構成」、「共有コンポーネント」、折りたたんだ「アプリケーション・ドメイン」

- 4-1 ナビゲーション・ツリーの「共通構成」ノード

- 4-2 「使用可能なサービス」ページ

- 4-3 「共通設定」ページ(折りたたんだ表示)

- 4-4 共通のコヒーレンス設定

- 4-5 グローバル証明書検証のOCSP/CDP設定

- 4-6 「証明書失効リスト」ダイアログ・ボックス

- 5-1 デフォルト・ストアの完了した登録

- 5-2 システム・ストアの完了した登録

- 5-3 新しいデフォルト・ストアおよびシステム・ストアのオプション

- 5-4 デフォルト・ストアの指定

- 5-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア

- 5-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録

- 5-7 システム管理者ロールの追加

- 6-1 「プロキシ」タブが表示されたOAMサーバー登録ページ

- 6-2 「コヒーレンス」ページと個々のOAMサーバーの値

- 7-1 セッション・データとOracle Coherenceのロール

- 7-2 セッション詳細: 「共通設定」ページ

- 7-3 共通構成: 「セッション管理」ページ

- 8-1 Access Managerの設定

- 8-2 「Access Managerの設定」: 「ロード・バランサ」

- 8-3 「Access Managerの設定」: 「SSO」

- 8-4 共通ポリシー評価キャッシュ

- 8-5 事前構成済Kerberos認証モジュール

- 8-6 事前構成済LDAP認証モジュール

- 8-7 事前構成済X509認証モジュール

- 8-8 「カスタム認証モジュール」ノードと「一般」サブタブ

- 8-9 ステップの追加とプラグインの関連付け

- 8-10 「カスタム認証モジュール」の「ステップ」サブタブと「詳細」セクション

- 8-11 「カスタム認証モジュール」の「ステップ編成」サブタブ

- 8-12 KerberosPlugin

- 8-13 デフォルトのKerberosPluginステップと詳細

- 8-14 デフォルトのKerberosPluginステップと編成

- 8-15 LDAPPlugin

- 8-16 デフォルトのLDAPPluginステップと詳細

- 8-17 LDAPpluginのステップのデフォルト編成

- 8-18 X509Plugin

- 8-19 X509Pluginのデフォルト・ステップと詳細

- 8-20 X509Pluginのステップのデフォルト編成

- 9-1 WebLogic管理コンソールでのIAMSuiteAgent構成

- 9-2 IAMSuiteAgentの特性

- 9-3 IAMSuiteAgentによって保護されるリソース

- 9-4 「OAM 11g Webゲートの作成」ページ

- 9-5 「OAM 10G Webゲートの作成」ページ

- 9-6 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ

- 9-7 拡張されたOAM 10g Webgate登録ページ

- 9-8 Webgateの「検索」コントロールとエージェント作成ボタン

- 9-9 「OSSOエージェントの作成」ページ

- 9-10 「OSSOエージェント」ページと「確認」ウィンドウ

- 10-1 キーの生成

- 10-2 OSSOUpdateAgentRequest.xml

- 10-3 OAM11GUpdateAgentRequest.xml

- 10-4 OAMUpdateAgentRequest.xml

- 10-5 CreatePolicyRequest.xml

- 10-6 UpdatePolicyRequest.xml

- 10-7 アプリケーション・ドメインのリモート管理要素

- 11-1 Oracle Access Manager 11gポリシー・モデルおよび共有コンポーネント

- 11-2 OAMエージェントを使用したSSOログイン処理

- 11-3 OSSOエージェントを使用したSSOログイン処理

- 12-1 ポリシー・コンポーネント: アプリケーション・ドメインとの関係

- 12-2 デフォルトのwl_authenリソース・タイプ定義

- 12-3 TokenServiceRP

- 12-4 「ホスト識別子」ページ

- 12-5 デフォルトのLDAPSchemeページ

- 13-1 OAMポリシー・モデルのアプリケーション固有のコンポーネント

- 13-2 エージェント登録時に生成された新規アプリケーション・ドメイン

- 13-3 生成されたアプリケーション・ドメインのデフォルトのリソース定義

- 13-4 保護されたリソースのデフォルト認証ポリシー

- 13-5 リソースを保護するデフォルト認可ポリシー

- 13-6 新しいアプリケーション・ドメインの一般的なページ

- 13-7 アプリケーション・ドメインのナビゲーション・ツリー

- 13-8 アプリケーション・ドメインの「リソース」ページ

- 13-9 アプリケーション・ドメイン内でのリソース定義の検索

- 13-10 アプリケーション・ドメイン内のリソース定義の検索結果表

- 13-11 認証ポリシー: IAM Suiteアプリケーション・ドメイン

- 13-12 「認可ポリシー」ページ: IAM Suiteアプリケーション・ドメイン

- 13-13 コンソールの認可ポリシー・レスポンス

- 13-14 単純なレスポンスのサンプル

- 13-15 サンプルの複雑なレスポンス

- 13-16 「認可ポリシー」ページの一般詳細

- 13-17 「制約の追加」ウィンドウ

- 13-18 「認可ポリシー」ページの制約コンテナ

- 13-19 アイデンティティ・クラス制約の詳細: 「選択したユーザーとグループ」表

- 13-20 アイデンティティ・クラスの「ユーザー移入エントリの追加」ウィンドウ

- 13-21 「選択したユーザーとグループ」ウィンドウ

- 13-22 IP4Rangeクラス制約

- 13-23 一時制約クラスの詳細ページ

- 13-24 OAM Admin Console Policy、スキームおよびリソース

- 13-25 Protected HigherLevel Policy、LDAPSchemeおよびリソース

- 13-26 Protected LowerLevel Policy、認証スキームおよびリソース

- 13-27 Public Policy、匿名スキームおよびリソース

- 13-28 IAM Suite認可ポリシー

- 13-29 IAM Suiteトークン発行ポリシーおよびリソースURL

- 14-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性

- 14-2 アクセス・テスターのユーザー操作

- 14-3 アクセス・テスター・コンソール

- 14-4 アクセス・テスターの「サーバー接続」パネル

- 14-5 アクセス・テスターの保護されたリソースURIパネル

- 14-6 アクセス・テスターの「ユーザー・アイデンティティ」パネル

- 14-7 テスト・ケースのワークフロー

- 16-1 一般的なトークン・エコシステム

- 16-2 OAMトークンを使用したアイデンティティ伝播

- 16-3 アイデンティティ伝播中のプロセス・フロー

- 16-4 アイデンティティ伝播のデプロイメント

- 16-5 アイデンティティ伝播処理

- 16-6 必要なv1.0 WebLogic Server Identity Assertion Provider

- 16-7 IAP-OSTSの詳細

- 16-8 LDAPプロバイダ: IAP-DSEE

- 16-9 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア

- 16-10 アイデンティティ伝播のトークン発行ポリシー

- 16-11 Webgateによるアイデンティティ・アサーションの認証ポリシー

- 16-12 アイデンティティ・アサーションの/wssuserエンドポイント

- 16-13 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア

- 16-14 アイデンティティ伝播のトークン発行ポリシー

- 16-15 アイデンティティ・アサーションの/wss11userエンドポイント

- 17-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート

- 17-2 WS-Security 1.0および1.1ポリシー

- 17-3 有効になっているOracle Access Manager with Oracle Security Token Service

- 17-4 「セキュリティ・トークン・サービスの設定」ページ

- 19-1 検証テンプレートの検索コントロール

- 19-2 発行テンプレートの検索コントロール

- 19-3 発行テンプレート: 一般詳細とデフォルト

- 19-4 発行プロパティ: ユーザー名トークン・タイプ

- 19-5 発行プロパティ: SAMLトークン・タイプ

- 19-6 「セキュリティ」の詳細: SAMLトークン

- 19-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト

- 19-8 新規検証テンプレート: 「一般」の「認証の詳細」

- 19-9 トークン・マッピング: SAML2 WS-Security検証テンプレート

- 19-10 トークン・マッピング: username-wstrust-validation-template

- 19-11 トークン・マッピング: x509-wss-validation-template

- 19-12 「エンドポイント」ページ

- 19-13 IAM Suiteのトークン発行ポリシーとリソースURL

- 19-14 「トークン発行ポリシー」および「制約」

- 19-15 事前定義されたリソース・タイプ: TokenServiceRP

- 19-16 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP

- 20-1 「新規リクエスタ・パートナ」ページ

- 20-2 定義済のリクエスタ・パートナ

- 20-3 パートナの検索コントロール

- 20-4 リクエスタ・プロファイル: 一般

- 20-5 リクエスタ・プロファイル: トークンと属性

- 20-6 リライイング・パーティ・プロファイルの「トークンと属性」

- 20-7 トークンと属性: 発行局

- 20-8 発行局プロファイル: 「トークン・マッピング」タブ

- 20-9 プロファイルの検索ページ: リクエスタ

- 23-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化

- 24-1 データベースによる監査アーキテクチャ

- 24-2 共通設定: 監査構成

- 25-1 「サーバー・プロセス概要」ページ

- 25-2 「セッション操作」の「モニター」ページ

- 25-3 「サーバー操作」の「モニター」ページ

- 25-4 「OAMエージェント」の「モニター」ページ

- 25-5 OAMエージェントのモニタリング特性

- 25-6 デタッチされたOAM 10gエージェント接続の表

- 25-7 デタッチされたOAM 10gエージェント操作概要の表

- 25-8 デタッチされたOAM 10gエージェント操作詳細の表

- 25-9 デタッチされたOAM 10gエージェント情報の表

- 25-10 OSSO 10gエージェントの「モニター」ページの「操作の詳細」

- 25-11 デタッチされたOSSO 10gのエージェント・モニタリング・プロセスの概要表

- 25-12 デタッチされたOSSO 10gエージェント情報表

- 26-1 Fusion Middleware Control (AS-Control)のデプロイメント・アーキテクチャ

- 26-2 Fusion Middleware Controlのログイン・ページとヘルプ・トピック

- 26-3 Fusion Middleware ControlのOAM「ファーム」ページ

- 26-4 Fusion Middleware Control内のファーム・ナビゲーション・ツリー

- 26-5 Fusion Middleware Controlの「ノード情報」ページ

- 26-6 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー

- 26-7 「アプリケーション・デプロイメント」メニュー

- 26-8 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー

- 26-9 「Oracle Access Managerクラスタ」ページ

- 26-10 Oracle Access Managerサーバー・ページの「主要なメトリック」

- 26-11 クラスタの集約されたAccess Managerコンポーネント・メトリック

- 26-12 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック

- 26-13 クラスタの集約されたSTSコンポーネント・メトリック

- 26-14 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック

- 26-15 「パフォーマンス・サマリー」コマンド

- 26-16 「メトリック・パレット」を表示した「パフォーマンス・サマリー」ページ

- 26-17 「ログ構成」タブのOracle Access Managerログ・レベル

- 26-18 Oracle Security Token Serviceのログ・レベル

- 26-19 ログ・ファイルの構成ページ

- 26-20 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ

- 26-21 「システムMBeanブラウザ」と「属性」タブ

- 26-22 コンテキスト・メニューが表示された状態のルーティング・トポロジ

- A-1 アップグレード前のOSSO 10gトポロジ

- A-2 アップグレード前のフロントエンド・プロキシのあるOSSO 10gの例

- A-3 アップグレード後のOSSO 10gトポロジ

- A-4 mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

- A-5 プロキシ・サーバーなしの一般的なトポロジ

- A-6 共存処理

- A-7 共存とOSSO 10g認証

- A-8 1つのアプリケーションに由来する名前が付けられたOSSOエージェント構成

- A-9 2番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成

- A-10 3番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成

- A-11 migratedSSOPartnersのホスト識別子

- A-12 migratedSSOPartnersアプリケーション・ドメインのリソース

- A-13 migratedSSOPartnersアプリケーション・ドメインの認証ポリシー

- B-1 ソースおよびターゲット処理

- B-2 各アプリケーション・ドメインの依存関係

- E-1 OAMサーバーとWebgateの通信チャネル

- G-1 OAM 11gでのIPv6とチャレンジ・リダイレクトの構成

表一覧

- 1-1 デプロイメント・タイプ

- 1-2 Oracle Access Manager 11gの機能拡張

- 1-3 Oracle Access Manager 11gで使用できないOAM 10gの機能

- 1-4 比較: OAM 11g、OAM 10g、OSSO 10g

- 1-5 Oracle Security Token Serviceの用語

- 1-6 Oracle Security Token Service 11gのインフラストラクチャ

- 1-7 統合されたOracle Web Services Manager

- 2-1 OAM 11g共存のサマリー

- 3-1 LDAPグループから管理者へのロール・マッピング

- 3-2 「ようこそ」ページとショートカット

- 3-3 機能タブと説明

- 3-4 ツール・バーのコマンド・ボタン

- 3-5 「表示」メニュー・コマンドの説明

- 3-6 システム構成、「アクション」メニュー、コマンドの説明

- 3-7 開いているページのコントロール

- 3-8 ページ要素と説明

- 3-9 選択タスクとコントロール

- 3-10 「ポリシー構成」サブタブ

- 3-11 ポリシー構成検索コントロール

- 3-12 共通のシステム構成検索コントロール

- 4-1 ナビゲーション・ツリーの「共通構成」ノード

- 4-2 共通設定

- 4-3 共通のコヒーレンス設定

- 5-1 Oracle Access Manager 11g、10gおよびOSSOのキーの比較

- 5-2 ユーザー・アイデンティティ・ストアの要素

- 6-1 サマリー: OAM 11g、OAM 10gおよびOSSO 10gのサーバー側の違い

- 6-2 OAMサーバー・インスタンスの設定

- 6-3 個別のOAMサーバーのOAMプロキシ設定

- 6-4 個別のOAMサーバーのデフォルトのCoherence設定

- 7-1 共通セッション設定

- 7-2 セッション管理のコントロールと結果表

- 8-1 Access Managerの設定

- 8-2 「Access Managerの設定」: 「ロード・バランサ」

- 8-3 外部エラー・コード、トリガー条件、推奨メッセージ

- 8-4 「Access Managerの設定」: 「SSO」

- 8-5 サマリー: 簡易モードと証明書モード

- 8-6 サーバー共通のOAMプロキシ・セキュア通信の設定

- 8-7 ポリシー評価キャッシュ

- 8-8 Kerberos認証モジュールの定義

- 8-9 LDAP認証モジュールの定義

- 8-10 X509認証モジュールの定義

- 8-11 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション

- 8-12 「ステップ編成」サブタブ

- 8-13 X509の「ステップの詳細」: 証明書から抽出する属性

- 9-1 OAM 11gのエージェント

- 9-2 エージェント・タイプの比較および違い

- 9-3 IAMSuiteAgent、11g Webgate、10g Webgateの比較

- 9-4 OAM 10g WebgateとOAM 11g Webgateの作成ページ

- 9-5 展開されたOAM 11gおよび10g Webgateの要素とデフォルト

- 9-6 ユーザー定義のWebgateパラメータ

- 9-7 OAMエージェントの「検索」コントロール

- 9-8 Webgateキャッシュ

- 9-9 「OSSOエージェントの作成」ページの要素

- 9-10 展開されたOSSOエージェントの要素

- 10-1 リモート登録のリクエスト・ファイル

- 10-2 リモート登録のサンプル・コマンド

- 10-3 リモート登録の結果

- 10-4 リモート登録リクエストに共通の要素

- 10-5 リモート登録リクエストのOSSO固有の要素

- 10-6 完全なリモート登録リクエストに共通の要素

- 10-7 リモート登録に必要な変数

- 10-8 リモート・エージェントとポリシーの更新

- 10-9 リモート・アプリケーション・ドメイン管理モード

- 10-10 <rregApplicationDomain>リモート管理テンプレートの要素

- 11-1 OAM 11gポリシー・モデルとOAM 10gの比較

- 11-2 ホスト識別子の例

- 11-3 OAM 11g SSOおよびOSSO 10gコンポーネントの概要

- 11-4 SSO Cookie

- 12-1 リソース・タイプの定義

- 12-2 ホスト識別子の定義

- 12-3 認証スキームの定義

- 12-4 事前構成済認証スキーム

- 12-5 事前構成済スキームのチャレンジ・パラメータ

- 12-6 暗号化Cookieのチャレンジ・パラメータ

- 13-1 リソース定義の要素

- 13-2 HTTPリソースのサンプルのURL値

- 13-3 .jspのリソースURL

- 13-4 リソース評価の結果

- 13-5 アプリケーション・ドメイン内のリソースの検索要素

- 13-6 認証ポリシーの要素および説明

- 13-7 認可ポリシーの要素および説明

- 13-8 レスポンス要素

- 13-9 シングル・サインオンのネームスペース・リクエスト変数

- 13-10 シングル・サインオンのネームスペース・セッション変数

- 13-11 ネームスペース・ユーザー変数

- 13-12 単純なレスポンスおよび説明

- 13-13 複雑なレスポンス

- 13-14 認可ポリシーの一般詳細

- 13-15 「制約の追加」ウィンドウの要素

- 13-16 アイデンティティ・クラス制約の詳細

- 13-17 一時制約クラスの詳細

- 14-1 テスター・コンソール・モードとコマンドライン・モードを使用したユーザー操作

- 14-2 アクセス・テスターでサポートされているシステム・プロパティ

- 14-3 アクセス・テスターのコンソール・パネル

- 14-4 アクセス・テスター・パネルのコマンド・ボタン

- 14-5 その他のアクセス・テスター・ボタン

- 14-6 アクセス・テスターのメニュー

- 14-7 接続パネルの情報

- 14-8 保護リソースURIパネルのフィールドとコントロール

- 14-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール

- 14-10 アクセス・テスターの取得リクエスト・オプション

- 14-11 スクリプト作成コマンド

- 14-12 テスト・スクリプト制御パラメータ

- 14-13 テスト・スクリプト実行コマンド

- 14-14 統計ドキュメントの不一致結果の理由

- 15-1 集中ログアウトの状況

- 15-2 OAM 11g Webgate登録のログアウト要素

- 15-3 end_urlパラメータ指定の例

- 17-1 メッセージ・レベルのセキュリティが不要な場合のポリシー・トランスポート・セキュリティ

- 17-2 セキュリティ・トークン・サービスの設定

- 17-3 WSS KerberosポリシーのためのOracle WSM以外のクライアントの構成

- 17-4 Oracle Security Token Serviceの構成管理操作

- 17-5 Oracle Security Token Service固有のランタイム・イベント

- 18-1 実行時に使用されるOSTS公開鍵

- 18-2 Oracle Access Manager with Oracle Security Token Serviceのキーストア

- 18-3 キーストアMbean

- 18-4 WS-Trust通信のパートナ・キー

- 18-5 Oracle Security Token Serviceの証明書検証の条件

- 18-6 証明書検証が成功するための要件

- 19-1 テンプレート検索コントロール

- 19-2 発行テンプレートの要件

- 19-3 発行テンプレート: 一般詳細

- 19-4 発行プロパティ: ユーザー名トークン・タイプ

- 19-5 発行プロパティ: SAMLトークン・タイプ

- 19-6 「セキュリティ」の詳細: SAMLトークン

- 19-7 発行テンプレート: 属性マッピング、SAMLトークン

- 19-8 検証テンプレートのプロトコル

- 19-9 新規検証テンプレート: 一般詳細

- 19-10 新規検証テンプレート: 認証の詳細

- 19-11 新規検証テンプレート: トークン・マッピング

- 19-12 「エンドポイント」ページ

- 19-13 「制約」タブ: トークン発行ポリシー

- 20-1 Oracle Security Token Serviceパートナの要素

- 20-2 プロファイル: 一般

- 20-3 リクエスタ・プロファイル: トークンと属性

- 20-4 リライイング・パーティ・プロファイルの要件

- 20-5 「トークンと属性」要素: 発行局

- 20-6 発行局の「トークン・マッピング」要素

- 22-1 Oracle Access Managerサーバー側コンポーネント

- 22-2 Oracle Access Manager共有サービス・エンジン・コンポーネント

- 22-3 Oracle Access Manager基盤APIコンポーネント

- 22-4 ODLレベルとJavaレベルの対応

- 22-5 Oracle Security Token Serviceロガー

- 23-1 ロギング・レベル

- 23-2 コンポーネントのログ構成ファイル名

- 23-3 ログ・ライター

- 23-4 最初の複合リストのグローバル・パラメータ

- 23-5 ロギングがアクティブかどうかを決定する要因

- 23-6 必須のログ構成ファイル・パラメータ

- 23-7 ログ・データ・ファイル構成パラメータ

- 23-8 モジュール固有ロギングしきい値に構成できるParamNameの値

- 24-1 Oracle Access Manager管理監査イベント

- 24-2 OAMランタイム監査イベント

- 24-3 監査構成要素

- 25-1 OAMプロキシ・メトリック

- 25-2 OAMプロキシのチューニング・パラメータ

- 26-1 「ファーム」ページのセクション

- 26-2 選択したノードとターゲットに対して表示されるページ

- 26-3 Fusion Middleware Controlの「パフォーマンス概要」のサマリー

- 26-4 Access Managerコンポーネント・メトリック

- 26-5 STSコンポーネント固有のメトリック

- 26-6 「パフォーマンス・サマリー」ページのステータスとコントロール

- 26-7 OAMで使用可能なログとFusion Middleware Controlの機能

- 26-8 「ログ構成」ページの「ログ・レベル」タブ

- 26-9 ログ・ファイル要素

- 26-10 Fusion Middleware ControlのOAMログ・メッセージ検索コントロール

- 26-11 システムMBeanブラウザ

- 26-12

- 26-13 システムMBeanブラウザ

- 26-14 ファーム・トポロジ

- 27-1 OAM 10g Webgateのインストールの比較

- 27-2 OAM 11gで使用する新しい10g Webgateのインストールの準備

- 29-1 IIS 7 Webgate Windows Server 2008

- A-1 OSSO 10gにより保護されているパートナ・アプリケーション

- B-1 デプロイメント・タイプ

- B-2 データの新しいターゲット環境への移行と既存のターゲット環境への移行の違い

- B-3 完全レプリケーション

- B-4 差分レプリケーション

- B-5 パートナおよびポリシーのエクスポート・コマンド

- B-6 パートナ、ポリシー、および差分のインポート・コマンド

- C-1 addOAMSSOProviderコマンドライン引数

- D-1 Oracle Access Managerでローカライズされたメッセージの言語

- E-1 importcertコマンドの構文

- F-1 OAM用WLSTコマンドの動作モード

- F-2 WLST Oracle Access Managerコマンド

- F-3 WLSTコマンド: Oracle Security Token Service

- H-1 シングル・サインオン・サーバーによりログイン・ページに送信されるログイン・ページ・パラメータ

- H-2 ページからシングル・サインオン・サーバーに送信されるログイン・ページのパラメータ

- H-3 ページに送信されるパスワード変更パラメータ

- H-4 ページにより送信されるパスワード変更ページのパラメータ

- H-5 シングル・サインオフ・ページに送信されるパラメータ

- H-6 外部アプリケーション・ログイン・ページに送信されるパラメータ

- H-7 「外部アプリケーション・ログイン」ページがアプリケーションに送信するパラメータ

- H-8 ログイン・ページのエラー・コード

- H-9 ログイン後のメッセージ

- H-10 パスワード変更ページのエラー・コード

- H-11 外部アプリケーション・ログイン・ページのエラー・コード

- H-12 外部アプリケーション・ログイン

- H-13 認証方式

- H-14 追加フィールド

Oracle® Fusion Middleware

Oracle Access Manager with Oracle Security Token Service管理者ガイド

11g リリース1 (11.1.1)

B62265-02(原本部品番号:E15478-06)

2011年8月

共通の設定、エージェント、シングル・サインオンのポリシーおよびトークンの管理方法を説明します。

Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1)

B62265-02

Copyright © 2000, 2011 Oracle and/or its affiliates.All rights reserved.

原本著者: Gail Flanegin

原本協力著者: Damien Carru

原本協力者: Patricia Fuzesy, Satish Madawand, Neelima Jadhav, Charles Wesley, Harshal X Shaw, Jeremy Banford, Rey Ong, Ramana Turlapati, Deepak Ramakrishnan, Vadim Lander, Vamsi Motokuru, David Goldsmith, Vishal Parashar, Carlos Subi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

このガイドは、Oracle Access Manager with Oracle Security Token Serviceを使用した日々の管理やポリシー構成のタスクについての情報を提供します。

対象読者

このマニュアルは、次の概念に詳しい管理者を対象としています。

- Oracle WebLogic Serverの概念および管理

- LDAPサーバーの概念および管理

- データベースの概念および管理(ポリシーとセッション管理データについて)

- Webサーバーの概念および管理

- Webgateおよびmod_ossoエージェント

- 監査、ロギング、およびモニタリングの概念

- セキュリティ・トークンの概念

- ポリシー・ストアの統合、アイデンティティ・ストア、およびOracle Identity ManagementとOISの知識が必要になることがあります。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

JAWS(Windowsのスクリーン・リーダー)は、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかしJAWSは括弧だけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

聴覚に障害があるお客様のOracleサポート・サービスへのアクセス

Oracleサポート・サービスに連絡するために、電気通信リレー・サービス(TRS)を使用して、1.800.223.1711でOracle Supportに電話してください。Oracleサポート・サービスのエンジニアは、技術的な問題を処理し、Oracleサービス要求処理に応じてカスタマ・サポートを提供します。TRSの詳細は、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照し、電話番号の一覧については、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 11gリリース1(11.1.1)のドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Access Manager 11gリリース1(11.1.1)リリース・ノート

- 『Oracle Fusion Middlewareパッチ適用ガイド』—ご使用のOracle Fusion Middlewareソフトウェアにパッチを適用して最新のバージョンにするために必要となる様々なツールおよびプロセスについて説明します。

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』 — 初回のOracle Access Manager 11gデプロイメントでのOracle Universal InstallerおよびWebLogic構成ウィザードの使用法について説明します。Oracle Access Manager 11g WebGatesのインストールについても解説します。

- 『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』—Oracle Access Manager with Oracle Security Token Serviceの構成およびポリシーの管理方法について説明します。

- 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』—カスタム・アプリケーションおよびプラグインを諸機能にプラグラムで記述する方法や非Webベースのリソースを保護するカスタム・アクセス・クライアントを作成する方法について説明します。

- 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』—その他のOracleおよびサード・パーティ製品と実行するためにOracle Access Managerを設定する方法について説明します。

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』

- 『Oracle Fusion Middleware Java EEアップグレード・ガイド』—10gで使用可能なJava EE環境のタイプ、およびこれらの環境をOracle Fusion Middleware 11gにアップグレードする手順についての情報です。

- 『Oracle Fusion Middleware管理者ガイド』—Oracle Fusion Middlewareの管理方法、たとえばポートの変更やアプリケーションのデプロイ、Oracle Fusion Middlewareのバックアップおよびリカバリの方法について説明します。また、このガイドではテスト環境から本番環境へのデータの移行方法についても説明します。

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』—Oracle Access Manager 10g SSO(OAM 11g SSOに置き換わりました)ソリューションのデプロイについて説明します。

- 『Oracle Application Server Single Sign-On管理者ガイド』—OracleAS Single Sign-Onをmod_ossoと使用してWebアプリケーションへのアクセスを保護するための詳細です。

- 『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』—デプロイメントを段階的に示すガイドです。

- Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス—「インフラストラクチャ・セキュリティのカスタムWLSTコマンド」の章に、カスタマイズされたOracle Access Managerコマンドに関する項が記載されています。

- 『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』—Webサービスを管理および保護する方法について説明します。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

新機能

この項では、Oracle Access Manager 11gリリース1(11.1.1)パッチ・セット1の新機能について説明します。

パッチ・セット1の新機能

パッチ・セット1では、次のトピックで説明する、新機能および拡張機能を提供します。

- 管理コンソールの拡張機能

- 認証プラグインの拡張機能

- 問合せ文字列ベースのHTTPリソース定義

- 除外されたリソース・リスト

- 「セッション検索」および「セッション管理」の拡張機能

- 複数のアイデンティティ・ストアのサポート

- OAMテスターの拡張機能

- Oracle Secure Token Service

- Oracle Access Manager SDK、カスタム認証プラグイン、カスタム・トークン

- リモート登録の拡張機能

- Webgateの拡張機能

管理コンソールの拡張機能

「システム構成」タブは、3つの新しいセクションに分割されました。

- 共通構成

- Access Managerの設定

- セキュリティ・トークン・サービスの設定

関連項目:

- 第3章「共通の管理およびナビゲーションの基礎」

- 第4章「サービス、証明書検証および共通設定の管理」

- 第8章「Access Managerの設定の構成」

- 第17章「Oracle Security Token Serviceの設定値と設定の管理」

認証プラグインの拡張機能

認証は、1つ以上のプラグインに基づく特定の認証スキームによって制御されており、ユーザーがリソースへのアクセス試行時に入力した資格証明をテストします。プラグインはOAMサーバーのインストールで提供される標準セットから入手するか、独自のJava Developerでカスタム・プラグインを作成できます。

関連項目:

- 「認証モジュールの管理」

- 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』

問合せ文字列ベースのHTTPリソース定義

ポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。

関連項目:

- 表13-1「リソース定義の要素」

除外されたリソース・リスト

Oracle Access Managerでは、特定のリソースをパブリック(OAMエージェントによって保護されない)で維持するためのサポートを提供しています。

関連項目:

- 表10-6「完全なリモート登録リクエストに共通の要素」

- 表13-1「リソース定義の要素」

「セッション検索」および「セッション管理」の拡張機能

ユーザー・セッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部です。これらは「共通設定」ページに移動しました。

関連項目:
共通セッションのライフサイクル設定ページについて

認証されたクライアントはセッション操作を管理できます。

関連項目:
表7-1「共通セッション設定」: 「管理操作の許可」パラメータの詳細

アクティブ・セッションのデータベース永続性: ローカルおよび分散キャッシュに加えて、構成済データベース・セッション・ストアにアクティブ・セッションを永続化できます。すべての管理対象サーバーが停止している場合でも、セッションは保持されます。

関連項目:
表7-1「共通セッション設定」: アクティブ・セッションのデータベース永続性パラメータの詳細

Oracle Access Managerでは、拡張されたセッション検索コントロールを提供しており、これによってフィルタ条件に基づいた問合せを作成できます。

関連項目:
表7-2「セッション管理のコントロールと結果表」

複数のアイデンティティ・ストアのサポート

複数のユーザー・アイデンティティ・ストアがサポートされています。

- システム・ストアとして指定されたユーザー・アイデンティティ・ストアのみが、Oracle Access Managerコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。

- OAMに保護されたリソースにアクセスしようとするユーザーは、デフォルトのユーザー・アイデンティティ・ストアとしてマークされたストアのみでなく、任意のストアに対して認証できます。

- Oracle Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。トークン発行ポリシーにユーザーの制約を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルトのユーザー・アイデンティティ・ストアである必要があります。

関連項目:
「ユーザー・アイデンティティ・ストアについて」

OAMテスターの拡張機能

このリリースでは、クライアント証明書およびルート証明書を持つストアで必要となる、CERTモード接続がサポートされています。両方のストアをIMPORTCERTツールを使用して生成できます。また、OAMテスターはマルチスレッド・モードで同時テストを実行することも可能で、ポリシー・サーバーのストレス・テストの実施に使用できます。テストはコマンドライン・モードでのみ実行され、入力構成ファイルによってスレッド数および実行する必要がある各スレッドの反復数が指定されます。各スレッドは、ポリシー・サーバーへの専用接続をオープンし、指定した入力スクリプトを指定した反復数で実行します。

関連項目:
「アクセス・テスターを使用した接続性とポリシーの検証」

Oracle Secure Token Service

Oracle Security Token ServiceはOracle Access Managerでデプロイすると、サービスとしてアクティブ化できます。

Oracle Security Token Serviceは、現在のセキュリティ・インフラストラクチャに基盤を提供し、トークンの取得、更新、取消しに使用する、一貫性があり、効率化されたモデルを容易にします。これはプロトコルおよびセキュリティ・インフラストラクチャに依存しません。

Oracle Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介ならびに安全なアイデンティティ伝播およびトークン交換を可能にします。Oracle Security Token Serviceは、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために必要なセキュリティおよびアイデンティティ・サービスとしてデプロイできます。

関連項目:

- 第16章「Oracle Security Token Serviceの実装シナリオ」

- 第17章「Oracle Security Token Serviceの設定値と設定の管理」

- 第18章「Oracle Security Token Serviceの証明書と鍵の管理」

- 第19章「テンプレート、エンドポイントおよびポリシーの管理」

- 第20章「Token Serviceパートナとパートナ・プロファイルの管理」

- 第21章「Oracle Security Token Serviceのトラブルシューティング」

Oracle Access Manager SDK、カスタム認証プラグイン、カスタム・トークン

Oracle Access Manager 11g Access SDKは、プラットフォーム独立パッケージで、オラクル社によって様々なエンタープライズ・プラットフォーム(32ビット・モードおよび64ビット・モードの両方を使用)とハードウェアの組合せが認定されています。JDKバージョンで提供されており、Oracle Fusion Middlewareアプリケーション間でサポートされています。

Oracle Access Manager 11gでは、認証プラグイン・インタフェースおよびSDKツールが提供されており、これによりカスタマイズされた認証モジュール(プラグイン)を構築して個々の要件を備えた即時利用可能な機能に橋渡しします。

Oracle Security Token Serviceに設定せずに検証や発行に使用できるトークンが含まれていない場合には、独自の検証および発行モジュール・クラスを記述できます。

関連項目:

- 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』

- Oracle Security Token Service Java APIリファレンス

- Oracle Access Manager Access SDK Java APIリファレンス

- Oracle Access Manager拡張Java APIリファレンス

リモート登録の拡張機能

リモート登録ツールでは、管理者およびアプリケーションのデプロイ担当者がOracle Access Managerによる保護のためのアプリケーションをリモートで登録できます。リモート登録ツールoamregへの拡張機能は、Webgate登録への拡張機能に反映されています。特定の変更がリモート登録の実行で使用するテンプレートに対して加えられました。エージェントをリモートで管理する新しいモードが使用可能です。パスワードを取得する新しいオプションを使用できます。

関連項目:

- 表10-1「リモート登録のリクエスト・ファイル」

- 表10-2「リモート登録のサンプル・コマンド」: -nopromptオプションの詳細

- 「リモート登録リクエスト・ファイルについて」

- 表10-6「完全なリモート登録リクエストに共通の要素」: virtualhostとhostportVariationsパラメータ、excludedresourcesListパラメータ、allowManagementOperationsパラメータ、cachePragmaHeaderとcacheControlHeaderパラメータ、ipValidationExceptionsパラメータなどの詳細

- 「リモート管理モードの概要」

- 「エージェントのリモート管理」

- 「エージェントを使用しないアプリケーション・ドメインの作成または更新」

Webgateの拡張機能

Webgateは、認可でチェックされず、パススルーのみが許可されていることが必要な例外リストからリソースをキャッシュします。

関連項目:
表9-5「展開されたOAM 11gおよび10g Webgateの要素とデフォルト」

特定のユーザー定義パラメータをWebgate登録ページに実装できます。

関連項目:
「ユーザー定義のWebgateパラメータについて」

セッション管理の操作を呼び出せるのは、権限のあるエージェントのみです。エージェント権限機能で、エージェントごとのセッション操作のプロビジョニングを有効にできます。

関連項目:
表9-5「展開されたOAM 11gおよび10g Webgateの要素とデフォルト」

Webgateと認証時のクライアントIPアドレスを持たないアクセス・クライアントの間のシングル・サインオンを構成できます。

関連項目:
「Webgate用IPアドレスの検証について」

ブラウザのキャッシュを制御する設定についてのみ、Webgateを構成できます。

関連項目:
「展開されたOAM 11gおよび10gエージェントの要素とデフォルト」: 次に関する詳細

- キャッシュ・プラグマ・ヘッダー

- キャッシュ制御ヘッダー

エージェントの検索中に、正確な名前がわからない場合には、検索文字列にワイルドカード(*)を使用できます。

関連項目:
「OAMエージェント登録の検索」

リリース11gリリース1 (11.1.1)

全体の概要は第2章「本書の概要」、製品およびコンポーネントの名前の変更は次のトピックを参照してください。

製品およびコンポーネントの名前の変更

元の製品名Oblix NetPointはOracle Access Managerに変更され、7.xリリースはOracle Application Server 10gリリース2 (10.1.2)の一部としてオラクル社から入手可能でした。次の表に示すとおり、Oracle Access Manager 10.1.4でもいくつかの製品およびコンポーネントの名前が変更されましたが、Oracle Access Manager 11gではより多くの変更があります。

OAM 10g

OAM 11g

デプロイメント

スタンドアロン・サーバー

コンテナでデプロイ

コンポーネント名

アクセス・サーバー
ポリシー・マネージャ

Webgate

アクセス・ゲート

アイデンティティ・サーバー

Webパス

OAMサーバー
OAM管理コンソール

Webgate

アクセス・クライアント

なし

なし

エージェント

Webgate
アクセス・ゲート

Webgate (OAMエージェントも同様)
アクセス・クライアント(OAMエージェントも同様)

コンソール名

ポリシー・マネージャ
アイデンティティ・システム・コンソール

アクセス・システム・コンソール

OAM管理コンソール
なし

なし

ディレクトリ・プロファイル

ディレクトリ・プロファイル

ユーザー・アイデンティティ・ストア

アイデンティティ管理

アイデンティティ・サーバー

アイデンティティに依存しない(Oracle Identity Manager 11gがデフォルトで使用されます)

管理者

マスター管理者
マスター・アイデンティティ管理者

マスター・アクセス管理者

委任管理者

管理者
なし

なし

なし

エージェントおよびパートナ・アプリケーションの登録

なし

Oracle Access Managerコンソール
リモート登録ツールにより、デフォルトのセキュリティ・ポリシーを使用して、自動化されたエージェント登録とアプリケーション・ドメインの作成が行われます。

OAM 10gフォームに基づく認証スキーム、ポリシー・ドメイン、アクセス・ポリシー、シングル・サインオンのためのIDアサーション用Webgateプロファイルの自動作成

OAMCfgTool
プラットフォームに依存しないツールとスクリプト

oamreg
OAMエージェント(10gおよび11g Webgateとアクセス・クライアント)、アプリケーション・ドメイン、SSOのデフォルト・ポリシーのリモート登録。

構成ストア

LDAP

XMLファイル

ポリシー・ストア

LDAP

XMLファイルまたはRDBMS

ポリシー・モデル

オープン(デフォルト許可)

クローズ(デフォルト却下)

ポリシー・ドメイン

ポリシー・ドメイン

アプリケーション・ドメイン

セッション管理

ステートレスでcookieに格納

ステートフルでサーバーに格納

LDAPに対する認証

LDAPによりシステム全体で定義

認証スキームでLDAPにより定義

リソース・タイプ

リソース・タイプ

リソース・タイプ

リソース

リソース

リソース

ホスト識別子

ホスト識別子

ホスト識別子

認証

認証
認証スキーム

認証プラグイン

認証ルール

認証
認証スキーム

認証モジュール

認証ポリシー

認可

認可
認可ルール

認可条件式

認可
制約

認可ポリシー

アクション

アクション

レスポンス

ソフトウェア開発キット

Access Manager SDK

Access Manager SDK

アクセス・プロトコル

NetPoint Accessプロトコル(NAP)

Oracle Accessプロトコル(OAP)

アクセス・プロトコルのポート番号

6021

5575(Internet Assigned Numbers Authority(IANA)により割り当て)

第I部

Oracle Access Manager with Oracle Security Token Serviceの概要

このマニュアルの第I部では、Oracle Access Manager with Oracle Security Token Serviceの概要を説明します。

第I部は次の章で構成されます。

- 第1章「Oracle製品の概要」

- 第2章「本書の概要」

1 Oracle製品の概要

この章では、Oracle Access Manager 11gおよびOracle Security Token Serviceの高度な概要ならびに詳細情報へのリンクを提供します。この章には次の項が含まれます。

- Oracle Access Managerの概要

- Oracle Security Token Serviceの概要

Oracle Access Managerの概要

Oracle Access Manager 11gは、全面的なWeb周辺のセキュリティ機能を提供します。これにはWebシングル・サインオン、認証および認可、ポリシー管理、監査などが含まれます。

シングル・サインオン(SSO)は、ユーザーやユーザーのグループが、認証後に複数のアプリケーションにアクセスできるようにします。SSOにより、サインオンを何度も要求されるということがなくなります。Oracle Access Manager 11gは、Oracle Fusion Middleware 11gのシングル・サインオン・ソリューションです。Oracle Access Manager 11gは、このマニュアルの説明にあるように単独で動作する他、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の説明にあるようにOracle Access Manager認証プロバイダとともに動作します。

Oracle Access Manager 11gはJavaプラットフォームのEnterprise Edition(Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Identity Managementスタックのすべての既存のアクセス・テクノロジは、Oracle Access Manager 11gに集約されています。

Webサーバー、アプリケーション・サーバーまたは任意のサード・パーティ・アプリケーションは、Webgateにより、またはOracle Access Managerにエージェントとして登録されたmod_ossoインスタンスにより保護する必要があります。ポリシーを施行するために、エージェントはHTTPリクエストのフィルタとして機能します。Oracle Access Managerでは、管理者が認証および認可のポリシーを定義できます。

注意:
Webgateは、様々なWebサーバーのためにOracleが製品の一部として提供するエージェントです。Access Manager SDKを使用して作成されたカスタムのアクセス・クライアントは、Web以外のアプリケーションで使用できます。明記されている場合を除いて、このマニュアルの情報はどちらにも同じように該当します。

OAM 11gや現在Oracle ADF SecurityおよびOPSS SSOフレームワークを使用する任意のWebアプリケーションと統合することもできます。詳細は、付録Cを参照してください。

この項の残りの部分では、次のトピックを説明します。

- Oracle Access Managerのアーキテクチャの概要

- Oracle Access Managerのデプロイメント・タイプとインストールの概要

- Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

「Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較」で説明しているように、Oracle Access Manager 11g、Oracle Access Manager 10gおよびOSSO 10gの間にはいくつかの重要な違いがあります。

Oracle Access Managerのアーキテクチャの概要

このトピックでは、Oracle WebLogicサーバー上に存在し、Oracle Fusion Middlewareアクセス管理アーキテクチャの一部であるOracle Access Manager 11gの概要を説明します。

既存のソリューションとの下位互換性および共存が提供される一方で、Oracle Access Manager 11gでは次の旧テクノロジが置換および集約されます。

- Oracle Access Manager 10g

- Oracle Application Server SSO(OSSO)10g

図1-1に、基本的なOracle Access Manager 11gのコンポーネントおよびサービスを示します。プロトコル互換性フレームワークは、OAM Webgate、mod_ossoエージェント、Access Managerソフトウェア開発キット(SDK)を使用して作成されたカスタムのアクセス・クライアントとインタフェースします。

図1-1 Oracle Access Manager 11gのコンポーネントおよびサービス

「図1-1 Oracle Access Manager 11gのコンポーネントおよびサービス」の説明

図1-2は、Oracle Access Managerコンポーネントの分散を示します。

図1-2 Oracle Access Manager 11gのコンポーネントの分散

「図1-2 Oracle Access Manager 11gのコンポーネントの分散」の説明

Oracle Access Managerコンソールは、Oracle WebLogic Administration Server (AdminServerとも呼ばれます)に備わっています。OAMランタイム・インスタンスをホストするWebLogic管理対象サーバーは、OAMサーバーとして知られています。

共有情報は次の項目で構成されます。

- エージェントおよびサーバー構成データ

- Oracle Access Managerポリシー

- ユーザー・セッション・データはすべてのOAMサーバーで共有されます。

Oracle Access Managerのデプロイメント・タイプとインストールの概要

この項では、OAMのデプロイメントおよびインストールの簡単な概要を説明します。

- デプロイメントのタイプとOAM

- Oracle Access Managementのインストール後のタスクについて

デプロイメントのタイプとOAM

表1-1では、企業内のデプロイメントのタイプについて説明しますが、これらの名前は企業によって異なる可能性があります。

表1-1 デプロイメント・タイプ

デプロイメント・タイプ

説明

開発デプロイメント

理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限

QAデプロイメント

通常、テスト用に使用される、比較的小さな共有されたデプロイ

本番前デプロイメント

通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント

本番デプロイメント

日常的に企業内で完全に共有および使用可能

初回のインストールおよび構成のときに、新しいWebLogic Serverドメインを作成(または既存のドメインを拡張)して、OAMサーバー、データベース・スキーマ、オプションのWebLogic管理対象サーバー、クラスタ、埋込みLDAPサーバーを定義します。

関連項目:
『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』ガイドの「Oracle WebLogic Serverドメインの理解」の章で、Oracle WebLogic Server管理ドメインについて説明しています。

デプロイメントのサイズやタイプに関係なく、新しいWebLogic Serverドメインでは、Oracle Fusion Middleware構成ウィザードを使用して、次のOAM関連コンポーネントがデプロイされます。

- WebLogic管理サーバー

- WebLogic管理サーバーにデプロイされたOracle Access Managerコンソール

- Oracle Access ManagementのWebLogic管理対象サーバー

- 管理対象サーバーにデプロイされたアプリケーション

注意:
既存のWebLogic Serverドメインでは、WebLogic管理サーバーはすでにインストールされて動作の準備ができています。

Oracle Fusion Middleware構成ウィザードを使用する際、アプリケーション・ドメインのメタデータを設定するためにDBを使用した構成テンプレートが選択されました。Repository Creation Utility(RCU)を使用して、OAM固有のスキーマによりデータベースを拡張する必要があります。構成ウィザードを実行した後に、初回のAdminServer起動でポリシー・ストアのブートストラップが発生します。詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

デフォルトの埋込みLDAPは、OAM 11gの基本ユーザー・アイデンティティ・ストアとして設定されます。

認可時にOAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用するために、Javaキーストアが設定されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップも発生します。

Oracle Access Managementのインストール後のタスクについて

初回のデプロイメント中、Oracle Access ManagerコンソールとWebLogic Server管理コンソールの両方にサインインするときに、WebLogic管理者のユーザーとパスワードが設定されます。「管理者について」で説明しているとおり、Oracle Access Management (Oracle Access ManagerおよびOracle Security Token Service)に対して別の管理者を割り当てることができます。

Oracle Access Management管理者は、Oracle Access Managerコンソールにログインしてこれを使用し、次に示す内容を管理できます。

- ユーザー・アイデンティティ・ストア

- OAMサーバー登録

- パートナ(エージェントおよびパートナ・アプリケーション)登録

- リソースを保護するためのアプリケーション・ドメインおよびポリシー

- ユーザー・セッション

- 共通サーバー・プロパティ

- 「Oracle Security Token Serviceの概要」で紹介しているOracle Security Token Serviceの設定および構成

インストールとアップグレードの比較

Oracle Fusion Middleware Supported System Configurationsのドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDK、Oracle Identity Management 11gに関連するサード・パーティ製品の動作保証の情報があります。Oracle Fusion Middleware Supported System Configurationsのドキュメントは、Oracle Technology Network(OTN)Webサイトで検索すれば見ることができます。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

インストールの後、新しいWebLogic Serverドメインまたは既存のWebLogic ServerドメインでOracle Access Managerを構成できます。Oracle Fusion Middleware構成ウィザードを使用して、次のコンポーネントが新しいドメインにデプロイされます。

- WebLogic管理サーバー

- WebLogic管理サーバー(OAM管理サーバー、または単にAdminServerということもあります)上にデプロイされたOracle Access Managerコンソール

- Oracle Access Managerの管理対象サーバー

- 管理対象サーバーにデプロイされたアプリケーション

関連項目:

- 『Oracle Fusion Middlewareパッチ適用ガイド』のOracle IdentityおよびAccess Managementの11.1.1.3.0から11.1.1.5.0へのパッチ適用に関する項

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

OracleAS 10g SSOのデプロイメントは、Oracle Access Manager 11g SSOを使用するようにアップグレードできます。OAM 11gでOSSOエージェントをアップグレードしてプロビジョニングした後は、認証はOAM 11g認証ポリシーに基づきます。ただし、OAMエージェント(Webgate/アクセス・クライアント)のみがOAM 11g認可ポリシーを使用します。時間が経つにつれて、アップグレードされた環境にあるすべてのmod_ossoエージェントをWebgateと置換してOAM 11g認可ポリシーを使用できるようにする必要があります。

アップグレード後の共存の詳細は、次を参照してください。

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』(B56245-01)

- 付録A「共存の概要: OAM 11gとOSSO 10g」

Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

ここでは、次の内容について説明します。

- Oracle Access Manager 11gの機能拡張

- 11gで使用できないOracle Access Manager 10gの機能

- Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

Oracle Access Manager 11gの機能拡張

Oracle Access Manager 11gには、Oracle Access Manager 10gにはなかった重要な機能拡張がいくつか含まれています。機能拡張の一覧は、表1-2にあります。

関連項目:
新機能

表1-2 Oracle Access Manager 11gの機能拡張

Oracle Access Manager 11gの新機能

- プラットフォーム・サポート: Oracle WebLogic Server Application Serverプラットフォームおよびサーバーの移植性は、サポートされているOracle WebLogic Serverを実行するすべてのプラットフォームで利用できます。

- インストール: Oracle Universal Installerを使用した簡単なOracle Access Managerのインストール、およびWebLogic構成ウィザードを使用した初回のデプロイメントについては、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明しています。

- 下位互換性: エージェントのリリース混在のサポート: Oracle Access Manager 10gエージェント(Webgateとアクセス・クライアント)およびSSOのためのOracleAS 10g SSOエージェント(mod_osso)の登録と使用がサポートされています。第9章、第10章を参照してください。

- アップグレードおよび共存: 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』の説明にあるように、既存のOSSOデプロイメントをアップグレードするユーティリティが用意されています。OSSOをアップグレードした後の共存については、付録Aで紹介します。

OracleAS 10g SSOパートナ・アプリケーション、OSSO 10gで保護されたアプリケーションおよびOAM 10g Webgateで保護されたアプリケーションに対するシングル・サインオンの組込みサポート。第IV部を参照してください。

エージェントごとの共有秘密鍵は、Cookieの暗号化と説明をエージェントに移すことにより、セキュリティとパフォーマンスを向上させます。第9章および第11章を参照してください。

ユーザーおよびグループ情報の埋込みLDAPについては、第5章で説明しています。

ポリシーのデータベース・ストレージを可能にするOracle Entitlement Server MicroSMとの統合。第5章を参照してください。

- このガイドの全編にわたって説明されているユーザビリティおよびライフサイクルの改善

- 充実した直観的なグラフィカル・ユーザー・インタフェースが、このガイドの全編で示されています。

OAM 10g Access Testerは新しいOAM 11g Access Testerに置き換えられ、Oracle Access Managerポリシーの評価が簡単になりました。第14章を参照してください。

セッション管理機能については、第7章で説明しています。

- Webgateの最大ユーザー・セッションのタイムアウトは、ホストのCookieを使用してWebgateでサポートされるようになりました。表1-4「比較: OAM 11g、OAM 10g、OSSO 10g」を参照してください。

- Webgateのアイドル・セッション・タイムアウトは、Oracle Coherenceベースのセッション管理エンジンによってメモリー内のステートを使用してサポートされるようになりました。

第24章で説明しているように、イベントは、基礎となるOracle Fusion Middleware共通監査フレームワークを使用して監査できます。

Windowsのネイティブ認証は、OSSOエージェントまたはOAMエージェントにより保護されたアプリケーションでサポートされています。詳細は、Oracle Fusion Middleware統合ガイド for Oracle Access Managerを参照してください。

カスタム認証プラグインの作成に必要な拡張性フレームワーク。詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。

複雑なポリシー構成(複数のルールのAND、ORセマンティク)

偽装のサポート

関連項目:
「11gで使用できないOracle Access Manager 10gの機能」

11gで使用できないOracle Access Manager 10gの機能

Oracle Access Manager 10gには、Oracle Access Manager 11gに含まれていない機能がいくつかあります。表1-3に概要を示します。

表1-3 Oracle Access Manager 11gで使用できないOAM 10gの機能

使用不可またはサポートされていない機能

カスタム認可プラグインの作成に必要な拡張性フレームワーク

アプリケーション・ドメイン・レベルで委任された管理

LDAPフィルタに基づく認可およびレスポンスの計算

mod_ossoで保護されたリソースの認可

アイデンティティ・サーバー、Webパス、アイデンティティ・システム・コンソール、ユーザー・マネージャ、グループ・マネージャ、組織マネージャ。Oracle Fusion Middleware Identity Managerにより置換されました。

Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較

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

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

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

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

特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。

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

表1-4では、Oracle Access Manager 11g、OAM 10g、OracleAS SSO 10gの比較を示します。Oracle Access Manager 11gでの名称変更のリストについては、「製品とコンポーネントの名称変更」を参照してください。

表1-4 比較: OAM 11g、OAM 10g、OSSO 10g

OAM 11g

OAM 10g

OSSO 10g

アーキテクチャ・コンポーネント

- エージェント: Webgate、アクセス・クライアント、mod_ossoおよびIAMSuiteAgent

- OAMサーバー

- (WebLogic管理サーバーにインストールされた)Oracle Access Managerコンソール

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

- リソースWebgate (RWG)

- 認証Webgate (AWG)

- アクセス・ゲート

- アクセス・サーバー

- ポリシー・マネージャ

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

- mod_osso(パートナ)

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

Cookie

ホストベースの認証Cookie

- 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>
注意: 有効なOAMAuthnCookieがセッションに必要です。

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

- OAMサーバーに1つ: OAM_ID

- 認証とセッション管理の両方について、Webgate(AWGを含む)に対してドメイン・ベースのObSSOCookie

- ホストベースの認証Cookie
パートナごとに1つ: OHS-host-port

OSSOサーバーに1つ: (OAM 11gでは適用されません)

- 有効な場合(OAM 11gとの相互運用性のため)、グローバルな非アクティブのタイムアウト(GITO)に対してドメイン・レベルのセッションCookie

暗号化キー

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

- WebgateとOAMサーバー間で共有されるエージェントの秘密鍵ごとに1つ

- 1つのOAMサーバー・キー

すべてのWebgateに1つのグローバル共有秘密鍵

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

- OSSOサーバー固有のキー

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

キー・ストレージ

- エージェント側: エージェント固有のキーがOracle Secret Storeにローカルに格納されます。

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

ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可)

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

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

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

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

1. Webgateは、エージェント・キーを使用してobrareq.cgiを暗号化します。
注意: obrareq.cgiは、WebgateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

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

3. また、OAMサーバーはエージェントの認証トークン(エージェント・キーを使用して暗号化)を生成し、セッション・トークン(cookieベースのセッション管理を使用する場合)や認証トークン、その他のパラメータを使用してそれをobrar.cgiにパックしてから、エージェント・キーを使用してobrar.cgiを暗号化します。
注意: obrar.cgiは、OAM 11gサーバーからWebgateにリダイレクトされた認証レスポンス文字列です。

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

- トークンの生成/暗号化、および検証/復号化は、アクセス・サーバーに委任されます。

- obrareq.cgiとobrar.cgiはどちらも暗号化されずに送信され、セキュリティは基礎となるHTTP(S)トランスポートに依存します。

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

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

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

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

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

セッション管理

- OAM 10gのセッション・アイドル・タイムアウトの動作は、11gセッション管理エンジン(SME)によりサポートされています。セッションのステートは、メモリーに保持されます。

- 単一のドメインがサポートされています。
マルチドメイン: ユーザーがあるドメイン上でアイドルのままタイムアウトし、認証のWebgateではタイムアウトしていない場合、AWG Cookieはまだ有効であり、再認証は必要ありません。新しいCookieが更新されたタイムアウトとともに生成されます。

- グローバルな非アクティブのタイムアウト(GITO)のドメイン・レベルのcookieによって、単一のドメインがサポートされます。
マルチドメインSSO: ユーザーがあるドメインにログインして、別のドメインに移動する場合、そのユーザーは最初のドメインからはアイドルと見なされます。元のドメインでアイドルによりタイムアウトすると、ユーザーは元のドメインでさ再び認証を受ける必要があります。

クライアントIP

- このClientIPを保守管理して、それをホスト・ベースのOAMAuthnCookieに含めます。

- 元のclientIPをObSSOCookieの中に含めます。
IPの検証が構成されている場合、後の認証や認可リクエストでcookieが提示されたときは、この元のclientIPが提示者のIPと比較されます。

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

- 元のclientIPをホストのcookie内に含めます。
後の認証リクエストでCookieが示される場合、元のクライアントIPとプレゼンタのIPが比較されます。

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

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

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

なし

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

一元化されたログアウト

- logOutUrls (OAM 10g Webgateの構成パラメータ)は保持されています。

- 次の新しい11g Webgateパラメータが提供されています。

logoutRedirectUrl
logoutCallbackUrl

ログアウト・ターゲットURL

詳細は、第15章を参照してください。

- 単一のドメインがサポートされています。
一度ユーザーがあるWebgateからログオフすると、ドメインのCookieは消去されて、ユーザーはドメイン全体からログオフしたと見なされます。

- マルチドメインSSOは、チェーン化されたカスタマイズ済のログアウト・ページを通してサポートできます。

OSSOサーバーのcookieには、パートナIDのリストが含まれます。

ユーザーがあるパートナ・アプリケーションからログオフすると、次の処理が行われます。

1. OSSOサーバーがログアウトURLのリストを取得します。

2. OSSOサーバーは自身のcookieを消去します。

3. OSSOサーバーはカスタマイズされたJSPページ(OSSOサーバー上でホストされる)にリダイレクトし、リクエストにあるログアウトURLのリストを渡します。

4. JSPページは、チェック・マークのイメージ・タグをいくつか含むログアウトURLを読み込み、読み込みの結果として、mod_ossoインスタンスのcookieが消去されます。

Oracle Security Token Serviceの概要

Oracle Security Token Serviceは、Oracle Access Managerとともにデプロイし、サービスとしてアクティブ化する必要があります。

関連項目:

- 『Oracle Fusion Middlewareパッチ適用ガイド』のOracle IdentityおよびAccess Managementの11.1.1.3.0から11.1.1.5.0へのパッチ適用に関する項

- 「Oracle Security Token Serviceの有効化および無効化」

- 第V部「Oracle Security Token Service」

Oracle Security Token Serviceは、トークンの取得、更新および取消のためのモデルにおいて、プロトコルやセキュリティ・インフラストラクチャに依存せず、その一貫性と効率性を促進するための基盤を現在のセキュリティ・インフラストラクチャに提供します。

Oracle Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介ならびに安全なアイデンティティ伝播およびトークン交換を可能にします。Oracle Security Token Serviceは、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために必要なセキュリティおよびアイデンティティ・サービスとしてデプロイできます。

Oracle Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Oracle Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を委任します。

Oracle Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Oracle Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。

Oracle Security Token Service (Oracle STS)はOracle Identity Federation (OIF)を拡張します。これにより、SAML、WS-Federation、LibertyまたはOpenIDなどの各種フェデレーション・プロトコルを介して、異なるセキュリティ・ドメインにまたがる、または管理境界を越えたリソースにアクセスするためにWebブラウザ経由で訪れるユーザーに対して、フェデレーテッド・シングル・サインオン(SSO)およびシングル・ログアウト(SLO)が円滑化されます。

セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているセキュリティ・トークン・サービス(STS)から取得できます。相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSTSを信頼している必要があります。

今日のIT環境には数多くのタイプのセキュリティ・トークンがあり、そのほとんどがWebアプリケーションのSSOおよびアプリケーション・セッション管理を容易にするブラウザCookieを基にしています。その他のトークンには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。

詳細は、次のトピックを参照してください。

- Oracle Security Token Serviceの主な用語と概要

- Oracle Access Managerを使用するOracle Security Token Serviceについて

- 統合されたOracle Web Services Managerについて

- Oracle Security Token Serviceのアーキテクチャについて

- Oracle Security Token Serviceのデプロイメントについて

- Oracle Security Token Serviceの管理について

Oracle Security Token Serviceの主な用語と概要

表1-5 Oracle Security Token Serviceの一般的な用語の識別

表1-5 Oracle Security Token Serviceの用語

用語

説明

セキュリティ・トークン

メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。

サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。

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

サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Oracle Security Token Serviceはその一例です。

セキュア・トークン・サービス

様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。

このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。

信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密鍵を使用して署名され、その署名は送信者の公開鍵を使用して検証されます。

リクエスト・セキュリティ・トークン(RST)

セキュリティ・トークンのリクエスト。

リクエスト・セキュリティ・トークン・レスポンス(RSTR)

セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Oracle Security Token Serviceにより生成されたレスポンス。

代理(OBO)

OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。

- トークンのOnBehalfOf要素で表された外部エンティティ。

ActAs

ActAs RSTは、複合的な委任を必要とします。発行されたトークンの最終受信者が、(クライアントのみでなく)委任チェーン全体を検査できます。ActAs RSTは、リクエスタが必要としているトークンに、次の異なるエンティティに関する要求が含まれているをことを示します。

- リクエスタ

- トークンのActAs要素で表された外部エンティティ。

トークン交換

あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、Oracle Security Token Serviceを使用して着信トークンとサービスが必要とするトークンを交換します。

WS-Security

Web Services Security(WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。

WS-Securityで使用される最も一般的なセキュリティ・トークンは、Username、X.509証明書、SAMLアサーション、およびKerberosチケットです(すべてがOracle Web Service Managerによりサポートされています)。

WS-Securityには、タイプの異なるバイナリとXMLのセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。

WS-*仕様は、多くの場合、互いに依存しています。たとえば、WS-Policyは、WS-Securityとともに使用されます。WS-*仕様は、非WS-*仕様も利用します。たとえば、WS-Securityは、XML暗号化およびXML署名を使用します。

WS-Securityでは、SAMLアサーションのみ使用されます。プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。

注意: WS-Security、WS-Trust、WS-Policyは、Organization for the Advancement of Structured Information Standards (OASIS)またはWorld Wide Web Consortium (W3C)などの標準化団体に移管されています。

WS-Trust

Web Services Trust Language (WS-Trust)は、WS-Securityの安全なメッセージング・メカニズムを使用して信頼関係を円滑化する仕様です。

WS-Trustは、アプリケーションが信頼されたSOAPメッセージの交換を構成できるようにするリクエスト・プロトコルおよびレスポンス・プロトコルを定義します。信頼は、セキュリティ・トークンの交換および仲介によって示されます。

WS-Securityのみを使用したメッセージ交換では、交換に関与する両当事者がセキュリティ情報の共有のために使用する必要があるセキュリティ・トークンのタイプについて事前に合意していることを前提としています。両当事者間にそうした合意がない場合でも、結果的に、メッセージを交換する前に信頼を確立する必要があります。SOAP/WS-Securityベースのメッセージを交換する両当事者間の信頼は、WS-Trust仕様を実装することにより確立されます。

WS-Policy

Web Services Policy (WS-Policy)。WS-Securityとともに、WS-Policyは、Oracle Fusion Middlewareセキュリティのもう1つの主要な業界標準です。

WS-Policyは、WS-Securityとともに使用されます。Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義できます。WS-Policyフレームワークを使用すると、Oracle Web Services ManagerなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。

ポリシーは、Webサービスの機能または要件を表す1つ以上のポリシー・アサーションとして表されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストを暗号化することを規定できます。同様に、ポリシー・アサーションでは、Webサービスで許容できる最大メッセージ・サイズを定義できます。

証明書

Oracle Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Oracle Security Token ServiceをホストするOAMサーバーは一意に識別されます。

キーストア

Oracle Security Token Serviceのキーストアに含まれるものを次に示します。

- システム・キーストア

- 信頼キーストア

- パートナ・キーストア

関連項目: 第18章「Oracle Security Token Serviceの証明書と鍵の管理」

ユーザー名トークン(UNT)

リクエスタをそのユーザー名で識別し、オプションでパスワード(または共有シークレットもしくはパスワードに相当するもの)を使用してそのアイデンティティを認証します。ユーザー名トークンを使用する場合は、そのユーザーをデフォルトのユーザー・アイデンティティ・ストアで構成する必要があります。

X.509証明書

受信当事者に公開鍵を送信するために設計された署名付きデータ構造。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。

証明書は、Verisignなどの認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密鍵で署名します。CAは、公開鍵が含まれる独自の証明書を発行します。

各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。

Security Assertion Markup Language (SAML)

SAMLアサーション

XMLドキュメントを使用してインターネット上でセキュリティ情報を共有するオープン・フレームワーク。SAMLにより提供されるものを次に示します。

- 認証および認可の情報を定義するアサーション。

- 必要なアサーションの要求(SAMLリクエスト)および取得(SAMLレスポンス)を行うプロトコル。

- SAMLプロトコルを業界標準のトランスポート(HTTPなど)およびメッセージング・フレームワーク(SOAPなど)に組み込む方法を定義するバインディング。

- 特定のユースケースをサポートするために、SAMLプロトコルおよびバインディングを組み合せる方法を定義するプロファイル。

WS-Securityでは、SAMLアサーションのみ使用されます。ただし、プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。

SAMLアサーションには、次の3つのタイプの文が含まれます。

- 認証文: サブジェクトの認証の成功時、認証局により発行されます。サブジェクトSが手段Mによって時間Tに認証されたことをアサートします。

- 属性文: ポリシーに基づいて属性認証局により発行されます。サブジェクトSが、値a、bなどを持つ属性A、Bなどに関連付けられていることをアサートします。

- 認可決定文(SAML 2.0では非推奨で、現在はXACMLでサポートされています): サブジェクトSによる(ファイル、アプリケーション、Webサービスなどの)リソースRに対する(読取り、書込みなどの)アクションAのための証拠Eに基づくリクエストを許可するかどうかを決定する認証局によって発行されます。

Kerberos

クロス・プラットフォーム認証のシングル・サインオン・システム。Kerberosプロトコルを使用すると、共有の秘密鍵(対称鍵)に依存する2つのエンティティ間で相互認証を実行できます。Kerberos認証では、クライアント、サーバーの他、それらを仲介するための、鍵配布センター(KDC)と呼ばれる信頼された当事者が必要になります。その他必要なものを次に示します。

- プリンシパル: ユーザーのアイデンティティ(ユーザーにプリンシパルが割り当てられます)、またはKerberosサービスを提供するアプリケーションのアイデンティティ。

- レルムとはKerberosサーバー環境のことで、EXAMPLE.COM(表記規則により大文字で表現)などのドメイン名とすることも可能です。各Kerberosレルムには、少なくとも1つのWebサービス・セキュリティKDCがあります。

WS-SecurityのKerberos Token Profileを使用すると、ビジネス・パートナがサービス指向アーキテクチャ(SOA)でKerberosトークンを使用できるようになります。

Oracle Access Managerを使用するOracle Security Token Serviceについて

Oracle Security Token ServiceはOracle Access Managerに準拠し、Oracle Access Managerと共存します(トークンをリクエストするWebクライアントのプライマリ・オーセンティケータとしてOracle Access Managerを使用)。

Oracle Security Token Serviceは、Oracle Access Manager 11gとともに管理対象サーバー上にインストールします。各管理対象サーバーは、通信チャネルをオープンするためにOracle Access Managerに登録する必要があります。Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。Oracle Security Token Serviceは、サード・パーティのセキュリティ・トークン・サービスと相互運用します。

Oracle Security Token Serviceでは、Oracle Web Services Managerエージェントが使用されます。Webgateは、アイデンティティ伝播用のエージェントとして使用されます。Webgateは、通信チャネルをオープンするためにOracle Access Manager 11gに登録する必要があります。

Oracle Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびOracle Access Manager 11g管理モデルが利用されます。さらに、Oracle Security Token Serviceは、Oracle Access Managerコンソールと統合され、統一的で一貫性のある管理エクスペリエンスを提供します。

Oracle Security Token Serviceでは、診断、監視、監査および高可用性のためのフレームワーク、ガイドラインおよび手法について、Oracle Access Manager 11gで使用されているものと同じものが採用されています。詳細は、第VI部「共通のロギング、監査、パフォーマンス・モニタリング」を参照してください。

Oracle Security Token Serviceの処理。

- STS監査イベントを統合

- Oracle Access ManagerコンソールおよびWLSTスクリプトにおいて、使用可能なOracle Security Token Serviceメソッドを公開してパートナのデータを管理

- Oracle Security Token Serviceのユースケースおよび構成モデルに固有の検証操作を実行

Oracle Security Token Service 11gのインフラストラクチャは、表1-6で説明します。

表1-6 Oracle Security Token Service 11gのインフラストラクチャ

コンポーネント

説明

デフォルト信頼キーストア

署名/暗号化に使用されるOracle Security Token Serviceの秘密鍵は、Oracle Access Managerで使用される共通キーストアに格納されます。Oracle Security Token ServiceおよびOracle Access Managerでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Oracle Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。

トークン・セキュリティ・キー・ペアは、Oracle Access Manager/Oracle Security Token Serviceキーストアに移入されます。

注意: OSTSのデプロイメントにおいてOracle WSMエージェントをWS_Trustクライアントとして使用する場合は、Oracle WSMエージェントのキーストアとOSTS/OAMのキーストアを別にすることをお薦めします。この2つをマージしないでください。その他の場合は、キーストアへのアクセスをOPSSにより認可されたすべてのモジュールに対してOAM/OSTSの鍵を使用可能なため、OAMの鍵にアクセスできます。

関連項目: 「Oracle Security Token Serviceキーストアについて」。

デフォルトのユーザー・アイデンティティ・ストア

Oracle Security Token Serviceは、Oracle Access Managerコンソールの「システム構成」の「共通構成」セクションで構成されたユーザー・アイデンティティ・ストアに対してユーザーを認証およびマッピングします。Oracle Security Token Serviceは、着信トークンをデフォルト・ユーザー・アイデンティティ・ストアのユーザー・レコードおよびユーザー属性にマッピングし、これがOracle Access ManagerとOracle Security Token Serviceの両方と連動します。

関連項目: 「デフォルト・ストアおよびシステム・ストアの設定について」。

証明書

Oracle Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Oracle Security Token ServiceをホストするOAMサーバーは一意に識別されます。

- Oracle Security Token Serviceで使用される鍵と証明書はインストール中に生成されます。サブジェクトと発行者のフィールドは、ホスト名にリンクされます。これは、Oracle Security Token Serviceで使用される署名鍵、暗号化鍵および証明書の他、OSTSを保護するOWSMエージェントで使用される鍵/証明書にも適用されます。OWSMエージェントは、OSTSとの通信に使用可能な、認定されたWS-Trustクライアントです。

- SAML発行者の設定は、ローカル・コンピュータのホスト名を参照するために構成します。

これにより、暗号化のデータおよび識別子に関して、2つのサーバーが同一ではないことが確認されます。サード・パーティ・モジュールにより一方のサーバーに付与された信頼は、識別子と暗号キーが異なるため、他方のサーバーには付与されません。同一の鍵、同一の識別子がない場合、認可ポリシーは拒否モードです。

Oracle Coherence

Oracle Security Token Serviceは、Oracle Coherenceモジュールと統合され、Oracle Security Token Serviceのすべての物理インスタンス間でWS-Trustのランタイム・データが格納および共有されます。UserNameToken Nonceは、Coherenceストアに格納されます。この実装では、Oracle Security Token Service以外では一般的ではない次の要件がサポートされます。

- タイムアウト・レコードのクリーン・アップ

- レコードの生存を数分に制限(30未満)

統合されたOracle Web Services Managerについて

11gリリースにおいて、Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WSMエージェント機能とともにOracle WebLogic Serverに統合されています。表1-7では、これらのコンポーネントについて説明します。

関連項目:
「Oracle Access Managerセキュリティ・キーおよび組込みJavaキーストアについて」

表1-7 統合されたOracle Web Services Manager

コンポーネント

説明

Javaキーストア(JKS)

クライアントのX.509トークンで必要な署名と暗号化鍵を格納するために必要です。JKSは、Sun社により定義された独自のキーストア・フォーマットです。信頼できる証明書ならびに公開鍵および秘密鍵はキーストアに格納されます。鍵と証明書をJKSで作成し管理するには、keytoolユーティリティを使用します。鍵は、認証やデータ整合性などの様々な目的に使用されます。

クライアントとWebサーバーが、同じドメインにあり、同じキーストアにアクセス可能な場合は、同じ秘密/公開鍵のペアを共有できます。

- クライアントは、秘密鍵orakeyを使用してリクエスト・メッセージの署名を裏書きし、公開鍵orakeyを使用して対称鍵を暗号化できます。

- 次に、Webサービスが公開鍵orakeyを使用して裏書きを検証し、秘密鍵orakeyを使用して対称鍵を復号化します。

ポリシー・インターセプタ

Oracle Fusion Middleware 11gでは、Oracle WSMエージェントは、セキュリティおよび管理ポリシー・インターセプタによって管理されます。ポリシー・インターセプタは、信頼できるメッセージング、管理、アドレッシング、セキュリティおよびメッセージ転送最適化メカニズム(MTOM)を含むポリシーを施行します。Oracle WSMエージェントは、ポリシー・インターセプタ・パイプラインを使用してポリシーの施行を管理します。

リリース10gと11gの違いを含むOracle Web Services Managerの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

Oracle WSMエージェント

OWSMエージェントは、OSTSとの通信に使用可能な、認定されたWS-Trustクライアントです。OWSMエージェントは、メッセージ保護のみのために(WSポリシーを公開するため、およびインバウンドおよびアウトバウンドのWSメッセージに対してメッセージ保護を施行するために)、Oracle Security Token Serviceにより埋め込まれ、使用されます。Oracle Security Token Serviceは、トークン検証/リクエスト認証を実行します。

- Oracle Security Token Serviceに埋め込まれたOracle WSMエージェントは、認証機能が無効化され、「メッセージ保護のみ」のモードで使用されます。このように、着信トークンの認証に関連したすべての側面は、Oracle Security Token Serviceのみによって実行されます。

- Oracle WSMは、Oracle Security Token Serviceが各ポリシーに宣言する必要がある構成オーバーライドを使用して認証の無効化をサポートします。
例外: KerberosトークンはOracle WSMにより処理され、Oracle Security Token Serviceはアイデンティティのみをマッピングすることに関与します。

- OWSMエージェントは、OSTSとの通信に使用可能な、認定されたWS-Trustクライアントの1つです。他のサード・パーティWS-Trustクライアントを使用して、OSTSと相互作用させることも可能です。

注意: 埋込みとは、OSTSが使用するWebLogic Server上でJRFレイヤーの一部としてOWSMエージェントが使用可能であることを意味します。

メッセージ/トークンの保護

Oracle Security Token Service/Oracle Access Managerは、それぞれのキーストアおよび信頼ストアを管理します。

Oracle WSMがOracle Security Token Serviceのメッセージ保護を施行するために、OWSMのキーストアがその自己署名付き証明書でシードされ、それに対応する鍵のパスワードがCSFに格納されます。これはOSTSキーストアと連携しません。

注意: 反対に、Oracle WSMは、Oracle Access Manager/Oracle Security Token Serviceがメッセージ保護に関連する鍵をOPSSキーストアに格納することを必要とします。クライアントがSKI、Thumbprintなどのスキームを使用してその証明書を参照する場合、Oracle WSMには、クライアント証明書がOPSSキーストアにあることが必要です。

トークン署名鍵

Oracle Security Token Serviceでは、トークン署名鍵に関して厳しい要件があり、クライアントとリライイング・パーティとの間の信頼を仲介するためにトークン署名鍵が使用されます。したがって、この鍵は、Oracle Security Token Serviceのみがアクセス可能な排他的パーティションに格納する必要があります。

セキュリティ・キー・ペア

Oracle Security Token Serviceは、発行されたトークンのセキュリティおよびメッセージ・セキュリティのために別々の鍵ペアを作成することで、トークン署名鍵のセキュリティを提供し、Oracle WSMエージェントがOracle Access Manager/Oracle Security Token Serviceキーストアと連携する必要性を排除します。

- メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。

- トークン・セキュリティ・キー・ペアは、Oracle Access Manager/Oracle Security Token Serviceキーストアに移入されます。

OPSSキーストア

メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。クライアントが(Webサービス・リクエストの一部として受信した証明書トークンではなく)SKIなどの参照スキームを使用する特別な場合、Oracle Security Token Serviceは、要求当事者の証明書をOPSSキーストアに移入します。これは一般的なシナリオではありません。Oracle Security Token Serviceには、OPSSキーストアに対して鍵を手動でプロビジョニングして機能させることについて、用意されている手順もあります。

Oracle Security Token Serviceのアーキテクチャについて

Oracle STSは、WS-Trustプロトコルをサポートする一元化されたトークン・サービスで、セキュリティ・トークンの発行および交換ならびに信頼関係の確立のために、WS-Security仕様に対する拡張機能を定義します。Oracle STSは、Webサービス・エンドポイントとしてホストされ、WSCとWSPとの間におけるセキュリティに基づく相互作用を調整します。Oracle STSとのすべての通信は、図1-3に示すように、WS_Trustクライアントを介して発生します。

図1-3 Oracle STSのアーキテクチャ

「図1-3 Oracle STSのアーキテクチャ」の説明

WSCがWSPにコールすると、WSCは、Oracle STSにより発行されたセキュリティ・トークンの提示が必要であることを示すWS-Securityポリシーを取得します。ポリシーにはOracle STSの場所が含まれ、WSCは、その場所を使用してOracle STSにコンタクトし、WSPに要求されたトークンを取得します(あるいは、WSPが自ら許容できるセキュリティ・メカニズムをSecurity Token Serviceに登録し、着信SOAPリクエストの検証前に、Security Token Serviceに確認してそのセキュリティ・メカニズムを決定することもできます)。認証されたWSC (エンド・ユーザーまたはアプリケーションのアイデンティティを確証する資格証明を保持)は、WSPにアクセスするためにトークンをリクエストし、Security Token Serviceは、資格証明を検証し、それに応えて、WSCが認証済である証拠を提供するセキュリティ・トークンを発行します。WSCはセキュリティ・トークンをWSPに提示し、WSPは信頼できるセキュリティ・トークン・サービスによってトークンが発行されたことを検証します。

図1-4では、Oracle STSのトークン・サポート・マトリックスを示します。

図1-4 Oracle STSのトークン・サポート

「図1-4 Oracle STSのトークン・サポート」の説明

Oracle Security Token Serviceのデプロイメントについて

この項では、いくつかの異なるデプロイメント・オプションを紹介するために次のトピックを説明します。

- 一元化されたトークン認証局のデプロイメント

- ファイアウォールの背後でのトークンのデプロイメント

- WebサービスSSOのデプロイメント

関連項目:
「シナリオ: OAMトークンを使用したアイデンティティ伝播」

一元化されたトークン認証局のデプロイメント

Web SSOとWebサービス・セキュリティ層との間におけるセキュリティ統合のためのトークン交換は、Webアプリケーションが内部または外部のWebサービスをコールする場合のデプロイメントにおいて需要があります。

そうした応用の一例は、内部ポータルをパートナまたは同一会社内の別組織により提供されている外部Webサービスと統合する場合です。ポータルは、サービスに安全にアクセスする方法を必要とします。

この場合のセキュリティ統合の難しさは、Web SSO層とWS層がユーザー認証に異なるメソッドを使用するという事実に起因します。Web SSO環境において、Webアプリケーションは、ユーザーを認証するために、WACにより発行されたセッション・トークン(SMSESSION、OBSSO)、SAMLアサーションまたは独自のトークンを受け入れることができます。

WS*セキュリティ層はまた、様々な(標準および独自の)トークンを使用し、多くの場合、2つの層の間での統合を実現するために、トークンのローカル変換が必要となります。ほとんどの場合、変換を実行するWSは、トークンを分解するために、トークンを発行した認証局(Oracle Adaptive Access Manager)にコンタクトする必要があり、その後にトークンを変換できるようになります。このため、各WSサービスは、WACシステムを使用して信頼を維持する必要があります。これは複数の信頼リンクを維持することが必要になる複雑なもので、あまり安全ではありません。

図1-5に示すように、Oracle Security Token Serviceの導入により、一元化された認証局でトークンの変換を行うことが可能です。

図1-5 一元化された認証局でのトークン変換

「図1-5 一元化された認証局でのトークン変換」の説明

ファイアウォールの背後でのトークンのデプロイメント

アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleおよびカスタム・アプリケーションとのWACシステムの統合では、(1)独自のベンダーAPI (SMエージェントAPIやASDK)をコールすることによる、あるトークン認証局(OAMやSiteMinderなど)により発行されたトークンの分解、および(2)アプリケーションがその内部ビジネス・ロジックのために必要とする新しいトークン形式(PSFT、Siebel)の構成のために、ほぼ必ず広範なコーディングが必要となります。

そうした変換は、アプリケーションのコーディングにより処理されることが多く、そのコードがDMZにある複数のアプリケーション・インスタンス上でデプロイされた場合に、ユーザー名やパスワードがさらされるといったリスクの要因となります。

セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。Oracle Security Token Serviceの導入により、この状況は大幅に改善されます。図1-6に示すように、Oracle Security Token Serviceは一元化されたトークン認証局の役割を担い、ファイアウォールの背後でトークン変換を実行します。

図1-6 ファイアウォールの背後でのトークンの変換

「図1-6 ファイアウォールの背後でのトークンの変換」の説明

アプリケーション1およびアプリケーション2は、Oracle Access Managerにより保護されています。アプリケーション2は、その内部ビジネス・ロジックのために別のタイプのトークンに依存しています。このアプリケーションには、OBSSOトークンをユーザー名トークンと交換するためにOracle Security Token Serviceにコンタクトするクライアント側コネクタがあります。Oracle Security Token Serviceは、OBSSOトークンを分解するためにOracle Access Managerに依存しており、アプリケーション2が必要とする新しいトークンを生成します。

ここでは同一の認証局(Oracle Access Manager)が両方の操作(OBSSOトークンの構成および分解)を実行するため、より安全です。アプリケーション側でトークンを分解する必要はありません。

WebサービスSSOのデプロイメント

Web SSOと同様に、WebサービスSSOは便利な機能です。その違いは、Web SSOでは、その機能から恩恵を受ける当事者はユーザーであるという点です。WS環境では、次のようになります。

- Web SSO: ユーザーが恩恵を受けます。

- WebサービスSSO: セキュリティ管理者が恩恵を受けます。

WebサービスSSOでは、異なるWebサービスに異なるトークン要件があり、それが頻繁に変更されます。Oracle Security Token Serviceに交換を外在させると、アプリケーションが目的のトークンおよび現在保持しているトークンを単純に供給できるようになります。Oracle Security Token Serviceは、リクエストされた各サービスのトークン・タイプを決定することを引き受けます。

1つ以上のWebサービスでその認証要件が変更されても、Oracle Security Token Serviceは、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。

図1-7に、WebサービスSSOを示します。

図1-7 WebサービスSSO

「図1-7 WebサービスSSO」の説明

インストール・オプションについて

この項では、様々なインストール・オプションの簡単な概要として次のトピックを説明します。

- 単一WLSドメインのOracle Security Token Serviceクラスタ

- Webサーバー・プロキシによるエンドポイントの露出

- Oracle Security Token Serviceインストールの概要

- インストール後のタスク: Oracle Security Token Service

単一WLSドメインのOracle Security Token Serviceクラスタ

単一のWebLogicドメイン内にある様々な管理対象サーバーでデプロイされたOracle Security Token Serviceインスタンスの間でクラスタリングを利用できます。このデプロイメント・トポロジでは、ロード・バランサにより高可用性機能が円滑化されます。デフォルトでは、Oracle Access ManagerとOracle Security Token Serviceが同一の管理対象サーバーに共存します。ただし、Oracle Security Token Serviceはデフォルトで無効になっており、これを使用できるようにするには、手動で有効化する必要があります。

このデプロイメント・トポロジでは、次に示すことを行うことになります。

- スイート・インストーラを使用してOracle Security Token Serviceの複数のインスタンスをデプロイします。

- ロード・バランサをデプロイして高可用性に加えてOracle Security Token Serviceクラスタのフロントでのフェイルオーバー・シナリオをサポートします。

詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

Webサーバー・プロキシによるエンドポイントの露出

このインストール・オプションでは、リクエスタおよびリライイング・パーティとサード・パーティSTSサーバーとの間に相互運用性がもたらされます。実行時に、Oracle Security Token Serviceは、OPSS WS-Trustプロバイダを使用して、サード・パーティ・セキュリティ・トークン・サーバーのリクエスタおよびリライイング・パーティとの相互運用をサポートします。たとえば、サード・パーティ・セキュリティ・トークン・サービスが有効なSAMLアサーションを作成し、Oracle Security Token Serviceがそれを使用できます。

リクエスタおよびリライイング・パーティと他のOracle WS-Trustベース・クライアントとの間の相互運用性

リクエスタとリライイング・パーティのためのすべての実行時シナリオは、WLSClient、MetroClientおよびOracle Web Services Manager (Oracle WSM)を含む、他のOracle WS-Trustクライアントによりサポートされています。

WS-Trustバインディングを介した場合のみ、すべてのWebサービス・クライアントがOracle Security Token Serviceでサポートされます。

Oracle Security Token Serviceインストールの概要

Oracle Access ManagerとOracle Security Token Serviceは、1つのEARファイルから一緒にインストールされます。Oracle Access ManagerとOracle Security Token Serviceは、1つのWebLogicドメイン内にある同一の管理対象サーバー上にデプロイされます。

Oracle WSMエージェントは、様々な暗号化操作のためにキーストアを使用します。それらのタスクのために、Oracle WSMエージェントは、Oracle WSMのタスク用に構成されたキーストアを使用します。インストール中、Oracle WSMキーストアが構成されていない場合にインストーラが行うことを次に示します。

- $DOMAIN_HOME/config/fmwconfigフォルダに新しいキーストアを作成します(デフォルト名は、default-keystore.jks)

- 署名および暗号化の操作のためにOWSMにより使用されるキー・エントリを、対応する証明書付きで作成します。このキー・エントリは、OWSMキーストア内のorakey別名の下に格納されます

- キー・エントリおよびキーストアのパスワードをCSFに格納します

キーストアにアクセスするために、場合によっては必要となることを次に示します。

- 必要に応じて、署名証明書または暗号化証明書を抽出してクライアントに配布します

- 署名または暗号化のキー・エントリを更新または置換します

- 信頼できる証明書を追加します

詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

インストール後のタスク: Oracle Security Token Service

Oracle Access ManagerをOracle Security Token Serviceとともにホストするすべてのサーバーは、Oracle Access Managerに登録する必要があります。これはインストール中に自動的に、またはインストール後に手動で行うことができます。

Oracle Access Managerコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。

Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。これにはこれまでに扱った次のトピックが含まれます。

情報はマニュアル全体から探すようにしてください。第V部「Oracle Security Token Service」のOracle Security Token Serviceの詳細には、特に注意してください。

Oracle Security Token Serviceの管理について

1つのデフォルトLDAPグループ、WebLogic Serverの「Administrators」グループがデフォルトで設定されます。

初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。管理者は、Oracle Access Managerコンソール(およびWebLogic Server管理コンソール)にログインして使用できます。

詳細は、第3章「共通の管理およびナビゲーションの基礎」を参照してください。

2 本書の概要

この章では、本書の概要および詳細情報を確認できる章へのリンクについて説明します。この章には次の項が含まれます。

- 本書の概要

- 第I部: Oracle製品の概要

- 第II部: 共通のタスク

- 第III部: Oracle Access Managerの設定

- 第IV部: シングル・サインオン、Oracle Access Managerポリシー、およびテスト

- 第V部: Oracle Security Token Service

- 第VI部: 共通のロギング、監査、パフォーマンス監視

- 第VII部: OAM 11gでのOAM 10g Webgateの使用

- 第VIII部: 付録

本書の概要

このマニュアルでは、管理者がOAM 11gのコンポーネントやポリシーを1つ以上のWebLogic管理ドメイン内で管理する上で役立つ情報を提供しています。

各WebLogic Serverのドメインは、論理的に関連するOracle WebLogic Serverリソースのグループです。WebLogic管理ドメインには、Administration Serverという特殊なOracle WebLogic Serverインスタンスが含まれています。このドメインは通常、管理対象サーバーという追加のOracle WebLogic Serverインスタンスを含み、WebアプリケーションとWebサービスがここにデプロイされます。

次の各項では、このマニュアルの部および章を順に紹介します。

第I部: Oracle製品の概要

このマニュアルの第I部では、このマニュアルで説明する製品ならびにOracle Access ManagerおよびOracle Security Token Serviceに共通のシステム管理タスクを紹介します。次の章が含まれます。

- 第1章「Oracle製品の概要」

- 第2章「本書の概要」

第II部: 共通のタスク

Oracle Access Managerの管理タスクは、日常的および定期的なシステム管理、ポリシーの作成および管理、セッション管理、診断、ならびにトラブルシューティングを中心に編成できます。当初、管理者の定義に使用するLDAPグループは、Oracle Access ManagerとWebLogicの間で変わりません。同様に、Oracle Access ManagerコンソールとWebLogic Server管理コンソールの両方へのログインに、同じ資格証明を使用します。Oracle Access Manager管理者のLDAPグループは変更できます。

この項では、このガイドの第II部の情報を紹介し、次のトピックについて説明します。

- 共通の管理およびナビゲーションの基礎

- サービス、証明書検証、および共通設定の管理

- 共通データ・ソースの管理

- 共通のOAMサーバー登録の管理

- セッションの管理

共通の管理およびナビゲーションの基礎

管理者は次を使用します。

- Oracle Access Managerのシステム構成ならびにセキュリティの要素およびポリシーを登録および管理するためのOracle Access Managerコンソール。
Oracle Access Managerコンソールならびに最も一般的な機能およびタスクの概要は、第3章「共通の管理およびナビゲーションの基礎」を参照してください。

注意:
カスタム管理コマンドライン・ツール(WebLogic Scripting Tool、別名WLST)は、このガイドに適宜記載のある特定の機能セットについて、Oracle Access Managerコンソールに代わる選択肢となります。

- WebLogic Server管理コンソールを使用して、WebLogic Serverドメイン内のデプロイされたOAMサーバーのサーバー構成サマリー(クラスタ、マシン、ステート、状態、リスナー・ポート)を参照したり、これらのサーバー上でSSLの起動、再開、一時停止、停止、または再起動を行います。
WebLogic Serverの管理コンソールの詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。

- コマンドライン入力用のカスタムOracle Access Manager WebLogic Scripting Tool

- エージェントおよびアプリケーション・ドメインを登録するためのリモート登録ツール

サービス、証明書の検証、および共通設定の管理

第4章では、Oracle Access ManagerとOracle Security Token Serviceの両方に共通するプロパティにナビゲートして構成する方法を説明します。この章には次のトピックが含まれます。

- 共通構成要素の概要

- 使用可能なサービスの有効化および無効化

- 共通設定の管理

- グローバル証明書の検証および取消の管理

データ・ソース

「データ・ソース」という用語はJava Database Connectivity(JDBC)のもので、Oracle Access Managerにおいてユーザー・アイデンティティ・ストアのコレクションまたはポリシーのデータベースを指すときに使用します。

Oracle Access Manager 11gは、通常エンタープライズにインストールされるデータ・ソースのタイプをいくつかサポートしています。各データ・ソースは、様々な情報タイプのストレージ・コンテナです。

注意:
Oracle Access Managerの構成データは、XMLファイルoam_config.xmlに格納されます。変更にはOracle Access ManagerコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。このファイルは編集しないでください。

ユーザーが保護されたリソースにアクセスを試みるときに認証を有効にするには(また、許可の際に許可を受けたユーザーのみがリソースにアクセスできるようにするには)、データ・ソースをOracle Access Manager 11gに登録する必要があります。

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明している初回のデプロイメント・プロセス中に、Oracle Access Manager 11gに対してデータ・ソースをインストールして登録する必要があります。

- ユーザー・アイデンティティ・ストア: 一元化されたLDAPストレージで、ユーザー指向の集計データが系統だって維持管理されます。

注意:
Oracle Access Manager 11gにはアイデンティティ・サービスは含まれず、ネイティブのユーザーやグループ、ロール・ストアはありません。

デフォルトでは、Oracle Access Manager 11gは、WebLogic Serverドメインの埋込みLDAPをユーザー・アイデンティティ・ストアとして使用します。ただし、数多くの他の外部LDAPリポジトリをユーザー・アイデンティティ・ストアとして登録することも可能です。この場合、管理者ロールおよびユーザーを含むシステム・ストアとして1つのストアを指定する必要があります。

- データベース: コンテンツのアクセスや管理、更新が簡単となるように、整理されて格納された情報のコレクション。
ポリシー・ストア: Oracle Access Manager 11gのポリシー・データは、Oracle Access Manager固有のスキーマで拡張されたデータベースに格納してOracle Access Manager 11gに登録する必要があります。

セッション・ストア: デフォルトでは、Oracle Access Managerのセッション・データはポリシー・ストア(データベース)に移行されたメモリー内のキャッシュに格納されます。また、第5章に説明するように、セッション・データに個別のデータベースを持つこともできます。セッションの詳細は、第7章を参照してください。

監査ストア: 監査データは、ファイルまたは個別のデータベース(ポリシー・ストアのデータベース以外)に格納できます。監査の詳細は、第24章「管理イベントおよびランタイム・イベントの監査」を参照してください。

- JavaキーストアはOracle Access Manager 11gに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成されるセキュリティ・キーの格納に使用されます。それぞれのOracle Access ManagerおよびOSSOエージェントは、他のエージェントが読むことのできない秘密鍵を持っています。また、Oracle Coherenceベースのセッション管理トラフィックを暗号化するキーもあります。ただし、キーストアは不可視であり、管理や変更はできません。

注意:
キーのパスワードは資格証明ストアに格納されます。

Oracle Access Managerでは、Oracle Access Managerコンソールからユーザー・アイデンティティ・ストアの詳細を管理(登録、表示、変更または削除)できます。詳細は、第5章「共通データ・ソースの管理」を参照してください。

関連項目:
付録F「管理者用のカスタムWLSTコマンドの概要」では、ユーザー・アイデンティティ・ストアの構成を作成、編集または表示するためのカスタムWLSTコマンドを紹介します。

OAM Serverのインスタンスおよびコンソール

OAMサーバーは、Oracle Access Manager release 10gではアクセス・サーバーと呼ばれていました。OAMサーバーは、Oracle WebLogic管理対象サーバー上にデプロイされたOracle Access Manager 11gの実行時インスタンスを提供します。登録されたエージェントは、OAMサーバーと通信します。

注意:
管理者はWebLogic Serverのドメインを拡張して、必要があればOAMサーバーを追加できます。これについては、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明しています。

Oracle Access Managerコンソールは、OAMリリース10gではポリシー・マネージャと呼ばれていました。Oracle Access Managerコンソールは、WebLogic管理サーバーと同じコンピュータにインストールして実行する必要があるJava EEアプリケーションです。WebLogic管理サーバーで実行する他の重要なアプリケーションには、WebLogic Server管理コンソールとFusion Middleware Control用のEnterprise Managerがあります。

注意:
Oracle Access Managerコンソールは、OAM管理サーバーと呼ばれることもあります。ただし、これはWebLogic管理対象サーバー上にデプロイされたOAMサーバーと同類ではありません。

いくつかのグローバル設定はすべてのサービスで共有されており、Oracle Access Managerコンソールを使用して管理できます。第4章「サービス、証明書検証、および共通設定の管理」を参照してください。

第6章「共通のOAMサーバー登録の管理」で説明しているように、Oracle Access Managerコンソールを使用してサーバー登録を管理できます。

Access Managerの操作に固有の設定は、第8章「Access Managerの設定の構成」で説明します。

注意:
次のいずれかを使用してOAMサーバーの実行時に新しい管理対象サーバー・インスタンスを追加できます。

- WebLogic Server管理コンソール(第6章「共通のOAMサーバー登録の管理」で説明しているように、OAMサーバー・インスタンスの手動登録が必要です)

- WebLogic構成ウィザード

- Oracle Access Manager用のカスタムOracle WebLogic Scripting Tool (WLST)コマンド

最後の2つの方法では、Oracle Access Managerコンソールに表示されるOAMサーバー・インスタンスが自動的に登録され、他に必要な手順はありません。

関連項目:
付録F「管理者用のカスタムWLSTコマンドの概要」では、サーバー構成を管理するためのカスタムWLSTコマンドを紹介します。

Oracle Access Manager 11gサーバーは、様々なポリシー強制エージェントと互換性があります。詳細は、「シングル・サインオン・エージェント」を参照してください。

Oracle Access Managerのセッション管理

OAM 11gの場合、セッション管理とは、ユーザーまたは管理者が発端となったイベントやタイムアウトに基づくイベントをサポートすることでユーザー・セッションの情報を管理するプロセスを指します。

管理者は、Oracle Access Manager 11gセッションのライフサイクル設定を構成できます。セッション・ストレージのデータベースは、まずOracle Access Manager構成を使用して構成されます。

- メモリー内のセッション・ストア: Oracle Coherenceの埋込み技術を使用して、分散されたキャッシュに低データ・アクセスの待機時間を提供し、分散されたキャッシュ(およびデータベース・ポリシー・ストア)間でデータを透過的に移動します。

- データベース・セッション・ストア: 非常に大きなデプロイメント(数十万の同時ログイン)のための、耐故障性とスケーラビリティを提供します。この場合、OAM固有のスキーマを使用して拡張されたデータベース・ポリシーおよびセッション・データ・ストアを使用する必要があります。

詳細は、第7章「セッションの管理」を参照してください。

第III部: Oracle Access Managerの設定

この項では、このマニュアルの第III部の内容について説明します。

- Access Managerの設定

- シングル・サインオン・エージェント

Access Managerの設定

「システム構成」タブの「Access Managerの設定」セクションには、Access Managerのサービスの操作に固有の設定が数多く用意されています。

この章(第8章)では、Access Managerに固有の次の設定を説明します。

- 「Access Managerの設定」の概要

- Access Managerロード・バランシング設定の管理

- SSOトークンとIPの検証の管理

- OAMプロキシの簡易モードおよび証明書モードのセキュリティのためのアクセス・プロトコルの管理

- 実行時のポリシー評価キャッシュの管理

- 認証モジュールの管理

シングル・サインオン・エージェント

シングル・サインオン・エージェント(ポリシー施行エージェントまたは単純にエージェントとも呼ばれます)は、アクセス・クライアントとして機能する任意のフロントエンドのエンティティで、エンタープライズ・アプリケーション間でシングル・サインオンを可能にします。

保護されたリソースへのアクセスを安全にするには、Webサーバーやアプリケーション・サーバー、サード・パーティアプリケーションを登録済のポリシー強制エージェントに関連付ける必要があります。エージェントはHTTPリクエストのフィルタとして機能し、アプリケーションが存在するWebサーバーをホストするコンピュータ上にインストールする必要があります。

個々のエージェントは、エージェントとOAMサーバー間で必要な信頼を設定するためにOracle Access Manager 11gに登録する必要があります。登録されたエージェントは、認証タスクをOAMサーバーに委任します。

Oracle Access Manager 11gは、次のタイプのエージェントをサポートします(組合せは任意)。

- OAMエージェント: Webgateはこのタイプのエージェントです。これはアクセス・クライアントとして機能するWebサーバー・プラグインです。Webgateは、WebリソースのHTTPリクエストを捕捉して、認証および認可のためにOAMサーバーに転送します。

- Webgate 11g: 個別にインストールする必要があります。Oracle Access Manager 11gへの登録後、Webgateは、Oracle Access Manager 11gのサービスと直接通信します。プロキシは使用されません。

- Webgate 10g: 個別にインストールする必要があります。Oracle Access Manager 11gへの登録後、登録された10g Webgateは、ブリッジとして機能するJava EEベースのOAMプロキシを介して、Oracle Access Manager 11gのサービスと通信します。
IAMSuiteAgent: このJavaエージェントは、アイデンティティ管理ドメインのリソースに対してSSOによる保護を提供するために、追加設定なしでインストールおよび登録されます。また、エージェントのoamsso_logoutアプリケーションが構成されて、WebLogic(およびOAM)のAdminServerとすべての管理対象サーバーにデプロイされます。このエージェントは、Oracle Access Manager 11gのポリシーを施行するため、OAM 10gエージェントとして実行されます。旧IDMDomainAgentはこのエージェントに置換されます。

IDMDomainAgent: この旧Javaエージェントは、IAMSuiteAgentに置換されます。Oracle Access Manager 11gパッチ・セットの適用後、IDMDomainAgentおよびそのコンパニオン・アプリケーション・ドメインは廃止されます。

- アクセス・クライアント: Access Managerソフトウェア開発キット(SDK)を使用して作成されたカスタム・プログラムのアクセス・クライアント。アクセス・クライアントは、Webリソースおよび非Webリソースを保護できます。

- OSSOエージェント(mod_osso 10g): Oracle Access Managerに登録された後、OSSO 10gエージェントはOSSOプロキシを介して直接Oracle Access Manager 11gサービスと通信します。
OSSOプロキシは、Oracle Access Manager 11gへのアップグレード時に既存のOSSOエージェントをサポートします。OSSOプロキシは、OSSOエージェントからのリクエストを処理して、OSSOプロトコルをOracle Access Manager 11g認証サービスのプロトコルに変換します。

次の方法とツールを使用して、エージェントをOracle Access Manager 11gに登録できます。

- Oracle Access Managerコンソール: 第9章の説明のとおりに、OAMエージェントおよびOSSOエージェントを登録して管理します。

- リモート登録: 第10章の説明のとおりに、Oracle提供のコマンドライン・ツールを使用します。

- プログラムによるエージェント登録: コンソールまたはリモート登録ツールを使用したOAMエージェントおよびOSSOエージェントの登録と同じです。第9章および第10章を参照してください。

既存の10g Oracle Access ManagerまたはOSSOのデプロイメントから可能な処理を次に示します。

- 第27章の説明のとおりに、10g WebgateとOracle Access Manager 11gをプロビジョニングできます。

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』の説明のとおりに、OracleAS 10g SSO (OSSO)をアップグレードできます。付録AのOracle Access Manager 11gサーバーとの共存の説明を参照してください。

関連項目:
「共存: OracleAS SSO 10gにおけるOAM 11g SSOとOAM 10g SSOの比較」

第IV部: シングル・サインオン、Oracle Access Managerポリシー、およびテスト

この項では、このガイドの第IV部の情報を紹介し、次のトピックについて説明します。

- シングル・サインオン

- Oracle Access Managerのポリシー・モデルおよび共有ポリシー・コンポーネント

- Oracle Access Managerのポリシー・モデル、アプリケーション・ドメインおよびポリシー

- 接続性およびポリシーのテスト

- Oracle Access Manager 11gの集中ログアウト

シングル・サインオン

シングル・サインオン(SSO)は、ユーザーが一度の認証で複数の保護されたリソース(Webページやアプリケーション)にアクセスできるようにするプロセスです。

Oracle Access Manager 11gは、パートナ・ネットワークのIdentity Federationやサービス指向アーキテクチャ(SOA)のようなSSOアーキテクチャをひとつにまとめます。Oracle Access Manager 11gは、複数のプロトコルで一貫したサービスを提供する共通のSSOエンジンを介して、シングル・サインオン(SSO)を提供します。

認証タスクをOracle Access Manager 11gに委任するには、エージェントが依存する相手とともに存在し、Oracle Access Manager 11gに登録されている必要があります。エージェントを登録すると、エージェントとOracle Access Manager 11g SSOとの間で必要な信頼メカニズムが設定されます。

注意:
Oracle Access ManagerコンソールおよびWebLogicコンテナにデプロイされた他のOracle Identity Managementコンソールのシングル・サインオンは、事前登録されたIAMSuiteAgentとコンパニオン・アプリケーション・ドメイン(IAMSuite)を使用して有効化されます。コンソールをこれ以上構成する必要はありません。

シングル・サインオンは様々な方法で実装できます。

- シングル・ネットワーク・ドメインSSO: 単一のネットワーク・ドメイン(たとえばmycompany.comなど)内のリソースに対してOracle Access Manager 11gのシングル・サインオンを設定できます。これには、単一のネットワーク・ドメイン内にある複数のWebLogic管理ドメインに属するリソースの保護が含まれます。

- 複数のネットワーク・ドメインSSO: Oracle Access Manager 11gでは、これは標準の機能です。11g Webgateのみを使用している場合、システム内のすべてのCookieはホスト・ベースです。ただし、すべてのドメインを管理する必要があります。一部のドメインが外部のエンティティ(Oracle Access Managerのデプロイメントの一部ではないもの)により制御される場合、Oracle Identity Federationを使用することをお薦めします。詳細は、Oracle Fusion Middleware管理者ガイド for Oracle Identity Federationを参照してください。

- 複数のWebLogic ServerドメインSSO: WebLogic Serverインスタンスの基本的な管理の単位は、ドメインとして知られています。様々なシステム管理者の責任、アプリケーションの境界またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義できます。ただし、クラスタ内のすべての管理対象サーバーが同じWebLogic Serverドメインに存在する必要があります。

- エージェントのリリースが混在するSSO: Oracle Access Manager 11gでは、登録されたOracle Access Manager 11gおよびOAM 10gのエージェント(新規のWebgate、プログラムによるアクセス・クライアント、およびOSSOエージェント(mod_osso 10g))がシームレスにサポートされ、それらを任意の組合せで使用できます。

関連項目:

- 「OAM Serverのインスタンスおよびコンソール」

- 「シングル・サインオン・エージェント」

- 第11章「OAMポリシー・モデルおよびシングル・サインオンの概要」

Oracle Access Managerのポリシー・モデルおよび共有ポリシー・コンポーネント

Oracle Access Manager 11gポリシー・モデルは、アプリケーション・ドメインのコンテキスト内で認証と認可の両方のサービスを提供します。

注意:
Oracle Access Manager 10gは、ポリシー・ドメインのコンテキスト内で認証と認可のサービスを提供します。OracleAS SSO 10gは認証のみ提供します。

Oracle Access Manager 11gポリシー・モデルでは、次のコンポーネントが共有され、どんなアプリケーション・ドメイン内でも構成して使用できます。

- リソース・タイプ: 保護するリソースのタイプと関連の動作を定義します。デフォルトのリソース・タイプはHTTPです。ただし、管理者はアプリケーション・ドメイン内の特定のリソースに適用可能なhttp以外のリソース・タイプを定義できます。アクセス・テスターは、HTTPリソースについてのみポリシーの強制を評価するときに使用できます。

- ホスト識別子: 管理者が指定の定義内にすべての可能なホスト名のバリエーションを含められるようにして、Webサーバー・ホストの識別を簡略化します。リソースをアプリケーション・ドメインに追加する際、管理者は指定された定義のいずれかを選択してからリソースのURLを指定できます。
仮想Webホスティング: 単一のサーバーでユニークなサブディレクトリに解決する複数のドメイン名とIPアドレスのサポートを有効にします。同じホストが、複数のNICカード(IPベース)または同じIPに解決する複数の名前(たとえば、abc.comとdef.com)に基づいて、サービスを受ける複数のサイトを持つことができます。

- 認証スキーム: 認証レベル、チャレンジ・メソッド、リダイレクトURL、基底にある認証モジュールを識別して、ユーザー認証を実行します。認証ポリシーをアプリケーション・ドメインに追加する際、管理者は指定のリソースとともに使用する指定された認証スキームのいずれかと、成功および失敗のURLを選択できます。

ポリシー・モデルと共有コンポーネントの詳細は、第12章「ポリシー・コンポーネントの管理」を参照してください。

Oracle Access Managerのポリシー・モデル、アプリケーション・ドメインおよびポリシー

アプリケーション・ドメインは、Oracle Access Manager 11gポリシー・モデルの最上位の構造です。各アプリケーション・ドメインでは、リソースまたはリソースのセットに対する論理コンテナと、特定のリソースにアクセスできるユーザーを示す、関連付けられたポリシーが提供されます。各アプリケーション・ドメイン内では、特定の共有コンポーネントが使用されます。

注意:
セキュリティ強化のため、Oracle Access Manager 11gのデフォルトの動作では、リソースがアクセスを明示的に許可するポリシーによって保護されていない場合に、アクセスが拒否されます。対照的に、Oracle Access Manager 10gのデフォルトの動作では、リソースがアクセスを明示的に拒否するルールやポリシーによって保護されていない場合に、アクセスが許可されていました。
Oracle Access Manager 10gでは、ポリシー・ドメインのコンテキスト内において認証および認可が提供されていました。対照的に、OracleAS SSO 10gは認証のみを提供します。

各Oracle Access Manager 11gアプリケーション・ドメインには次の要素が含まれます。

- リソース
アプリケーション・ドメインの各リソース定義には、リソース・タイプ、ホスト識別子(HTTPリソースの場合のみ)、特定のリソースへのURLが必要です。アプリケーション・ドメインには必要なだけリソース定義を持つことができます。

- 認証ポリシーおよび特定のリソースへのレスポンス
それぞれの認証ポリシーには、一意の名前、ひとつの認証スキーム、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソース、認証が成功した後に適用される管理者が定義したレスポンスが含まれます。

注意:
認証または認可の成功と失敗に指定されたOAM 11gポリシーのレスポンスに応じて、エンド・ユーザー特定のURLにリダイレクトされたり、ユーザー情報がヘッダー変数やcookieの値を通じて他のアプリケーションに渡されることがあります。

- 認可ポリシー、制約、および特定のリソースへのレスポンス
それぞれの認可ポリシーには、一意の名前、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソースが含まれます。さらに、管理者は認可が成功するために満たす必要がある特定の制約(条件)と、認可が成功した後で適用されるレスポンスを定義できます。

注意:
Oracle Access Manager 10gでは、管理者が定義した認可条件式(1つ以上の認可ルールを含む)の評価に応じて、認可アクションがとられるようになっています。

- トークン発行ポリシーおよび特定のリソースに対する制約
トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してトークンを発行する際に従うルールを定義します。

詳細は、第19章「テンプレート、エンドポイントおよびポリシーの管理」を参照してください。

ポリシー・モデルおよびアプリケーション・ドメインの詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。

接続性およびポリシーのテスト

オラクル社は、Oracle Access Manager 10gアクセス・テスターの機能に代わる移植可能なスタンドアロンのJavaアプリケーションを提供します。Oracle Access Manager 11gアクセス・テスターは、OAMサーバーに接続する登録済のエージェントをシミュレートします。スクリプトによる実行では、コマンドライン処理が可能です。スクリプトを記録および再生して、様々な機能の出力を取得できます。暗号化された接続および複数のサーバー接続がサポートされています。

アクセス・テスターを使用して、サーバー接続のエージェントのトラブルシューティングを行えます。この他、リクエストおよびレスポンスのセマンティクとアクセス・ポリシーの設計のオンザフライでのテストも可能です。

詳細は、第14章「アクセス・テスターを使用した接続性とポリシーの検証」を参照してください。

Oracle Access Manager 11gの集中ログアウト

Oracle Access Manager 11gは、ユーザー・セッションに単一のログアウト(グローバル・ログアウト)を提供します。Oracle Access Managerでは、単一のログアウトはアクティブなユーザー・セッションを終了するプロセスを意味します。

詳細は、第15章「OAM 11gの集中ログアウトの構成」を参照してください。

第V部: Oracle Security Token Service

この項では、管理者がOracle Access Managerで使用できるOracle Security Token Servicesを管理する際に役に立つ情報を提供します。

- 第16章「Oracle Security Token Serviceの実装シナリオ」

- 第17章「Oracle Security Token Serviceの設定値と設定の管理」

- 第18章「Oracle Security Token Serviceの証明書と鍵の管理」

- 第19章「テンプレート、エンドポイントおよびポリシーの管理」

- 第20章「Token Serviceパートナとパートナ・プロファイルの管理」

- 第21章「Oracle Security Token Serviceのトラブルシューティング」

第VI部: 共通のロギング、監査、パフォーマンス監視

この項では、このガイドの第VI部の情報を紹介し、次のトピックについて説明します。

- コンポーネント・イベント・メッセージのロギング

- Webgateイベント・メッセージのロギング

- 共通監査フレームワーク

- Oracle Access Managerコンソールのパフォーマンス・メトリック

- Fusion Middleware Controlのパフォーマンス・メトリック

コンポーネント・イベント・メッセージのロギング

ロギングは、重要なコンポーネント・イベントを取得するためにコンポーネントがファイルにメッセージを書き込むメカニズムです。それぞれのOracle Access Managerコンポーネント・インスタンスは、プロセスとステートの情報をログ・ファイルに書き込みます。

ロギングを構成して、様々な詳細レベルで情報を提供できます。たとえば、エラー、状態の情報を加えたエラー、またはデバッグ・トレースのレベルのエラー、状態およびその他の情報を記録できます。また、ログから機密情報を削除することもできます。詳細は、第22章「コンポーネント・イベント・メッセージのロギング」を参照してください。

また、カスタムのOracle WebLogic Scripting Tool (WLST)コマンドを使用して、OAMのロギング・レベルを変更することもできます。

関連項目:
付録F「管理者用のカスタムWLSTコマンドの概要」では、OAMロギング・レベルを変更するためのカスタムWLSTコマンドについて紹介します。

Webgateイベント・メッセージのロギング

各Webgateインスタンス(10gおよび11g Webgateの両方)は、プロセスおよび状態に関する情報をログ・ファイルに書き込むことができます。ログは、様々なレベルの粒度で情報を提供するように設定できます。たとえば、エラーの記録、エラーおよび状態情報の記録、またはエラーと状態に加えてデバッグ・トレース・レベルのその他の情報を記録することもできます。また、ログから機密情報を削除することもできます。

詳細は、第23章「Webgateイベント・メッセージのロギング」を参照してください。

共通監査フレームワーク

Oracle Access Manager 11gでは、監査とは管理や認証、ランタイム・イベントに関連する、確認に固有の情報を収集するプロセスを指します。監査は、ポリシー、ユーザー・アクセス・コントロールおよびリスク管理手順への準拠を評価する上で役に立ちます。

注意:
監査は、すべてのOracle Access Manager 11gコンポーネントで利用できるわけではありません。ただし、ロギングはすべてのOAMコンポーネントで使用できます。

イベントは、基礎となるOracle Fusion Middlewareの共通監査フレームワークを使用して監査されます。このフレームワークは、データベース監査ストアを使用して、監査フレームワークにスケーラビリティと高可用性を提供します。データベースには監査スキーマを含める必要があります。

注意:
Oracle Fusion Middleware共通監査フレームワークのデータベース監査ストアは、OAMポリシーやセッション・データを含まず、Oracle Access Managerコンソールからは構成されません。

管理者は、Oracle Access Managerコンソールを使用して特定の監査パラメータを制御および指定できます。Oracle Access Manager監査構成は、ファイルoam-config.xmlに記録されます。イベント構成(レベルへのイベントのマッピング)は、component_events.xmlで発生します。監査レコードには、特定の要件を満たすために構成できるアイテムのシーケンスが含まれます。

注意:
変更にはOracle Access ManagerコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。oam_config.xmlは編集しないでください。

Oracle Access Managerには、そのまますぐに使用できるサンプル監査レポートがいくつか用意されており、これらのレポートにはOracle Business Intelligence Publisherでアクセスできます。また、Oracle Business Intelligence Publisherを使用して、独自のカスタム監査レポートを作成することもできます。

詳細は、第24章「管理イベントおよびランタイム・イベントの監査」を参照してください。

Oracle Access Managerコンソールのパフォーマンス・メトリック

パフォーマンス・メトリックは、特定のイベントを完了する際にコンポーネントのメモリー内で収集できます。特定のエリアで使用された時間をモニターしたり、特定の発生や状態の変更を追跡できます。

管理者のみがOracle Access Managerコンソールのモニタリング・コマンドを使用して、Oracle Access Manager 11gのパフォーマンスを監視できます。

詳細は、第25章「Oracle Access Managerコンソールを使用したパフォーマンスの監視」を参照してください。

Fusion Middleware Controlのパフォーマンス・メトリック

ライブで動的なOAMパフォーマンス・メトリックは、Fusion Middleware Controlで参照できます。

詳細は、第26章「Fusion Middleware Controlによるパフォーマンスおよびログの監視」を参照してください。

第VII部: OAM 11gでのOAM 10g Webgateの使用

この項では、このガイドの第VII部の情報を紹介し、次のトピックについて説明します。

- OAM 11gでのOAM 10g Webgateのプロビジョニング

- Apache v2ベースのWebサーバー(OHSとIHS)のための10g Webgateの構成

- IIS Webサーバーのための10g Webgateの構成

- ISAサーバーのための10g Webgateの構成

- OAM 10g WebgateのためのLotus Dominoの構成

OAM 11gでのOAM 10g Webgateのプロビジョニング

OAM 10g WebgateをインストールしてOAM 11gと使用するために必要なすべての事項は、第27章「OAM 11gでのOAM 10g Webgateの管理」で説明します。

Apache v2ベースのWebサーバー(OHSとIHS)のための10g Webgateの構成

OAM 11gと使用するOAM 10g WebgateのためのApache v2ベースのWebサーバー(OHSとIHS)のインストールおよび構成の詳細は、第28章「Apache、OHS、IHSの10g Webgate用の構成」で説明します。

IIS Webサーバーのための10g Webgateの構成

OAM 11gと使用するOAM 10g WebgateのためのIIS Webサーバーのインストールおよび構成の詳細は、第29章「10g Webgate用のIIS Webサーバーの構成」で説明します。

ISAサーバーのための10g Webgateの構成

OAM 11gと使用するOAM 10g WebgateのためのISAサーバーの構成に必要なすべての事項は、第30章「10g Webgate用のISAサーバーの構成」で説明します。

OAM 10g WebgateのためのLotus Dominoの構成

OAM 10g WebgateおよびOAM 11gと使用するためのLotus Dominoのインストールおよび構成に必要なすべての事項は、第31章「10g Webgate用のLotus Domino Webサーバーの構成」で説明します。

第VIII部: 付録

この項では、このガイドの第VIII部の情報を紹介し、次のトピックについて説明します。

- 共存: OracleAS SSO 10gにおけるOAM 11g SSOとOAM 10g SSOの比較

- OAM 11gのテスト(ソース)から本番環境(ターゲット)への移行

- Oracle ADFアプリケーションとの統合

- OAM 10g Webgateの国際化とマルチバイト・データ・サポート

- 安全な通信と証明書の管理

- OAM用カスタムWebLogic Scripting Toolのコマンド

- IPv6クライアント用OAM 11g

- トラブルシューティング

共存: OracleAS SSO 10gにおけるOAM 11g SSOとOAM 10g SSOの比較

表2-1では、出発点が異なるケースにおいて、OAM 11gを使用するいくつかの方法を示します。

表2-1 OAM 11g共存のサマリー

所有内容

OAM 11g SSOを使用するための条件

OSSO 10gが統合されたOAM 10g

付録Aで紹介しているように、OSSOのデプロイメントをOAM 11gにアップグレードできます。

Oracle HTTP Server以外のWebサーバー

次の詳細は、第27章を参照してください。

- OAM 11g用の最新のOAM 10g Webgateの検索とインストール:

- OAM 11gでの10g Webgateのプロビジョニング

- OAM 11gでの10g Webgateの集中ログアウトの構成

OracleAS 10g SSO(OSSO)

.

オラクル社が提供するアップグレード・アシスタントを使用します。これは既存のOracleAS 10g SSOサーバー構成をスキャンして、10g OSSOのポリシー・プロパティ・ファイルおよびスキーマ情報を入力として受け入れ、構成されたパートナ・アプリケーションを目的地であるOracle Access Manager 11g SSOに組み込みます。

アップグレード・アシスタントおよびアップグレード後のタスクを実行した後、既存のパートナ・アプリケーション(ポータル、フォーム、レポート、Discoverer)はOSSOではなく、OAMをSSOプロバイダとして使用します。

注意: 既存のmod_ossoモジュールおよびOracleAS 10g SSOサーバー・パートナは、OAMサーバーおよびOAM 11g SSOとシームレスに動作できます。ただし、やがてすべてのmod_ossoモジュールは、OAM 11g認証ポリシーの使用を可能にするため、OAMエージェントと置き換える必要があります。

アップグレード後のOAM 11gとOSSO 10gサーバーの共存の概要は、付録Aを参照してください。

OAM 11gのテスト(ソース)から本番環境(ターゲット)への移行

OAM 11gは、デプロイメント間の構成データの転送を合理化します。たとえば、小さいテスト環境から大規模な本番用デプロイメント(またはその逆)というような場合です。

詳細は、付録B「OAM 11gのソース環境からターゲット環境への移行」を参照してください。

Oracle ADFアプリケーションとの統合

Oracle Application Developer Framework(ADF)とOracle ADF標準にコード化されたアプリケーションは、OPSS SSOフレームワークとのインタフェースです。Oracle Platform Security Services(OPSS)のシングル・サインオン・フレームワークは、あるドメインのアプリケーションをシングル・サインオン(SSO)ソリューションと統合する方法を提供します。

ユーザー認証のために、Oracle ADFセキュリティを使用するWebアプリケーションおよびOPSS SSOフレームワークを、Oracle Access Manager 11g SSOのセキュリティ・プロバイダと統合できます。詳細は、付録C「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合」を参照してください。

OAM 10g Webgateの国際化とマルチバイト・データ・サポート

付録D「OAM 10g Webgateの国際化とマルチバイト・データのサポート」では、国際化とマルチバイト・データのサポートに関する情報を提供します。

安全な通信と証明書の管理

Oracle Access Manager 11gを使用すると、資格証明の収集はHTTP(S)チャネルを使用して行われます。認可は、NetPoint Access Protocol (NAP)チャネル(Oracle Access Manager Protocol (OAP)チャネルとも呼ばれます)を介して行われます。

HTTP(S)チャネル: HTTP(S)チャネル全体の通信にsecure sockets layer(SSL)を有効にして、資格情報の転送とセキュリティ・トークンの交換を可能にすることをお薦めします。両方の機能で、証明書による署名と暗号化が必要です。

Oracle Access Manager 11gは、Webgateを含むすべてのOracle Access Managerコンポーネントで使用される証明書を管理する中央のコンポーネントとなります。

NAPチャネル: OAPチャネルとも呼ばれます。簡易モード(Oracleが署名した証明書)または証明書モード(外部の認証局)を使用して、認可中にWebgateとOAMサーバーとの間の通信を保護することをお薦めします。オラクル社では、署名済の証明書を持っているときに使用可能な、証明書のインポート・ユーティリティを用意しています。詳細は、付録E「Oracle Access Manager 11gとの安全な通信」を参照してください。関連項目:

注意:
Oracle Access Manager 11gは、自分で署名した証明書を使用するお客様へのサポートも提供しています。

OAM用カスタムWebLogic Scripting Toolのコマンド

管理者のみがカスタムWebLogic Scripting Tool (WLST)コマンドを使用して、特定の構成タスクを実行できます。

詳細は、付録F「管理者用のカスタムWLSTコマンドの概要」を参照してください。

IPv6クライアント用OAM 11g

Oracle Access Managerは、インターネット・プロトコル・バージョン4(IPv4)をサポートしています。Oracle Fusion Middlewareは、インターネット・プロトコル・バージョン4(IPv4)およびインターネット・プロトコル・バージョン6(IPv6)をサポートしています。IPv6は、mod_wl_ohsプラグインを使用したOracle HTTP Serverで使用できます。

詳細は、付録G「IPv6クライアント用のOAM 11gの構成」を参照してください。

デプロイメント固有ページの作成

Oracle Application Serverシングル・サインオンでは、デプロイメントに固有のログイン、パスワード変更、およびシングル・サインオン・サーバーによるシングル・サインオフ・ページを統合するためのフレームワークが提供されます。つまり、UIのルック・アンド・フィールおよびグローバリゼーション要件に合わせてこれらのページを調整できます。

詳細は、付録H「デプロイメント固有ページの作成」を参照してください。

トラブルシューティング

ヒントおよびトラブルシューティングの情報については、付録I「トラブルシューティング」を参照してください。

第II部

共通タスクに対するコンソールの使用

第II部では、Oracle Access ManagerおよびOracle Security Token Serviceの共通システム構成詳細の管理について説明します。

第II部は、次の章で構成されています。

- 第3章「共通の管理およびナビゲーションの基礎」

- 第4章「サービス、証明書検証および共通設定の管理」

- 第5章「共通データ・ソースの管理」

- 第6章「共通OAMサーバー登録の管理」

- 第7章「セッションの管理」

3 共通の管理およびナビゲーションの基礎

この章では、Oracle Access Managerコンソールのログインとナビゲーションに必要な最初の手順について説明します。この章には次のトピックが含まれます。

- 前提条件

- 管理者について

- Oracle Access Managerコンソールのログインとサインアウト

- Oracle Access Managerコンソールおよびコントロールの概要

- ポリシー構成およびシステム構成のタブの概要

- コンソールでの構成詳細の表示

- コンソールを使用した検索の実行

- オンライン・ヘルプの使用

- コマンドライン・ツール

- ロギング、監査、パフォーマンスのモニタリング

警告:

AdminServerを初めて開始するときには、12～15分など、非常に長い時間を要する場合があります。このプロセスを中断または終了しないでください。startWebLogic.cmd (Windows; startWebLogic.sh)をなんらかの理由(誤って、またはシステム・クラッシュや再起動など)で停止した場合、ポリシー・データが破損する可能性があります。このような場合にはドメインを削除および再作成し、RCUを再実行してOAMスキーマを作成する必要があります。

前提条件

このマニュアルのすべてのタスクは、Oracle Access Manager 11gが『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従ってデプロイされていることが前提です。

注意:
Oracle Access Managerコンソールには、WebLogic管理サーバーが実行されているときにアクセスできます。Oracle Access ManagerコンソールがWebgateで保護されている場合は、OAMサーバーが実行中であることが必要です。

この章のタスクを開始する前に、次のことを行ってください。

- 「Oracle Access Managerコンソールおよびコントロールの概要」で説明されているように、Oracle Access Managerコンソールについて理解してください。

- 基本ユーザーのアイデンティティ・ストアに定義された管理LDAPグループを検証してください。

注意:
デフォルトのLDAPグループ"Administrators"は、「管理者について」で説明されているように、Oracle Fusion Middleware構成ウィザードを使用した初回のデプロイメント時に設定されます。

管理者について

単一のデフォルトLDAPグループであるWebLogic Serverの"Administrators"グループが、デフォルトのユーザー・アイデンティティ・ストア(組込みLDAP)内に設定されます。初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。これらの資格証明によって、次へのアクセス権が付与されます。

- WebLogic Server管理コンソール

- Oracle Access Manager (Oracle Security Token Serviceを伴う)

- リモート登録管理ツール

- WebLogic Scripting Tool(WLST)

- カスタマイズされたOracle Access Manager WLSTコマンド

関連項目:
付録F「管理者用カスタムWLSTコマンドの概要」

表3-1は、Oracle Access ManagerとWebLogicで認識される管理者ロール、および共通のデフォルト・システム・ユーザー・アイデンティティ・ストアでロールがマッピングされる先のデフォルトのLDAPグループを示します。

表3-1 LDAPグループから管理者へのロール・マッピング

管理者ロール

説明およびLDAPグループ

管理者のロール

基本ユーザー・アイデンティティ・ストア内で定義されるLDAPグループで、ユーザーに完全なシステムおよびポリシー構成の権限を付与します。

デフォルトのグループ = 管理者

注意: 異なるLDAPグループを指定すると、WebLogic管理者がOracle Security Token Serviceにログインしたり、管理コマンドライン・ツールを使用できなくなります。

最初は管理者ユーザーは、初回構成時に設定されたWebLogic管理者の資格証明を使用してOracle Access Managerコンソールにログインする必要があります。ただし、企業によっては、Oracle Access Manager with Oracle Security Token Service管理を担当するユーザーとWebLogic管理を担当するユーザーに別の管理者グループが必要になることがあります。詳細は、「管理者ロールの管理」を参照してください。

注意:
構成の同時更新はサポートされていません。どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。複数の管理者が更新を同時に実行すると、Oracle Access Managerコンソールのシステム構成が一貫性のない状態になります。

Oracle Access Managerコンソールのログインとサインアウト

Oracle Access Managerコンソールは、Oracle Access Manager with Oracle Security Token Serviceへの管理アクセスを提供します。この項では、Oracle Access Managerコンソールのログインとサインアウトの方法を説明します。

注意:
1つのURLから複数のコンソールにアクセスするためにOracle Identity Navigatorをインストールしている場合、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。

この項の内容は次のとおりです。

- Oracle Access Managerコンソールへのログイン

- Oracle Access Managerコンソールからのサインアウト

Oracle Access Managerコンソールへのログイン

Oracle Access Managerコンソールのログイン・ページを図3-1に示します。

図3-1 Oracle Access Manager 11gの「ログイン」ページ

「図3-1 Oracle Access Manager 11gの「ログイン」ページ」の説明

注意:
ログインに正しい管理資格情報を使用するようにしてください。最初は管理者のLDAPグループは、WebLogic Server管理コンソールに定義されたLDAPグループと同じ("Administrators")で、共通のデフォルト・システム・ユーザー・アイデンティティ・ストアはWebLogic組込みLDAPです。

Oracle Access Managerコンソールにログインする手順

1. ブラウザ・ウィンドウで、適切なプロトコル(HTTPまたはHTTPS)を使用してOracle Access ManagerコンソールのURLを入力します。次に例を示します。

https://hostname:port/oamconsole/

サンプルのURLは次のようになっています。

- HTTPSは、Webサーバーが戻すユーザー・ページ・リクエストを暗号化および復号化できるように、Secure Socket Layer(SSL)を持ったHypertext Transfer Protocol(HTTP)を表します。

- hostnameは、Oracle Access Managerコンソールをホストするコンピュータの完全修飾ドメイン名です。

- portは、Oracle Access Managerコンソールの指定されたバインド・ポートを指します(これはWebLogic Server管理コンソールのバインド・ポートと同じです)。

- /oamconsole/は、Oracle Access Managerコンソールの「ログイン」ページを指します。

2. 「ログイン」ページで、Oracle Access Managerコンソール管理者の資格証明を入力します。次に例を示します。
ユーザー名: Admin_login_id

パスワード: Admin_password

3. 「ログイン」ボタンをクリックするか、[Enter]キーを押します。

4. 次の作業を実行します。

- 成功した場合: 「ポリシー構成」タブおよび「システム構成」タブが左側に、「ようこそ」ページが右側に表示されます。「ポリシー構成およびシステム構成のタブの概要」の説明にあるようにコンソールを操作するか、自分でタスクの実行を開始してください。

- 失敗した場合: もう一度ログインして、共通のデフォルト・システム・ユーザー・アイデンティティ・ストアで管理者に指定したとおりに情報を入力したことを確認します。

関連項目:
「管理者について」

Oracle Access Managerコンソールからのサインアウト

「サインアウト」リンクは、図3-2のようにOracle Access Managerコンソールの右上の隅に表示されます。セッションを終了するには、「サインアウト」リンクを選択します。サインアウトする前に、ブラウザのウィンドウを閉じることをお薦めします。

図3-2 右上にあるサインアウトのリンク

「図3-2 右上にあるサインアウトのリンク」の説明

Oracle Access Managerコンソールからサインアウトする手順

1. コンソール右上の「サインアウト」リンクをクリックします。

2. ブラウザ・ウィンドウを閉じます。

Oracle Access Managerコンソールおよびコントロールの概要

Oracle Access Managerコンソールは、機能レベルおよびページ・レベルのタブとコントロールを提供するWebベースのプログラムです。この項では、Oracle Access Managerコンソールの概要を説明します。

Oracle Access Managerコンソールは、管理者が必要とするシステムやポリシー構成管理の機能を提供します。ブラウザ・ウィンドウに、Oracle Access ManagerコンソールのURLを入力できます。

https://hostname:port/oamconsole

サンプルのURLでは、hostnameはOracle Access Managerコンソールをホストするコンピュータを、portはコンソールのホストがリスニングするHTTPポートの番号、/oamconsoleは「ログイン」ページを指します。

注意:
構成の同時更新はサポートされていません。どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。複数の管理者が更新を同時に実行すると、Oracle Access Managerコンソールのシステム構成が一貫性のない状態になります。

この項では、Oracle Access Managerコンソールの概要を簡単に説明します。

- コンソールのレイアウトおよびコントロール

- ページの要素

- コンソールでのコントロールの選択

コンソールのレイアウトおよびコントロール

図3-3は、ログインの直後に表示されるOracle Access Managerコンソールの様子を示します。

図3-3 Oracle Access Managerコンソールの「ようこそ」ページ

「図3-3 Oracle Access Managerコンソールの「ようこそ」ページ」の説明

Oracle Access Managerコンソールには、検索コントロールの左上に指定機能のタブ、ナビゲーション・ツリーの上にメニューとツール・バーがあります。開いているページは右側に表示されます。現在は「ようこそ」ページが開いています。

次の各項目で詳細情報を提供します。

- 「ようこそ」ページとショートカット

- 機能レベルのタブとコントロール

- コンテンツのページおよびページ・コントロール

関連項目:
「コンソールでのコントロールの選択」

「ようこそ」ページとショートカット

最初は「ようこそ」ページはコンソールの右側で、開いてアクティブな状態です。「ようこそ」ページのセクションには、特定の機能の簡単な説明や、表3-2にあるように特定のタスクをすぐに開始するための1つまたは複数のショートカット(選択可能なリンク)が含まれます。

表3-2 「ようこそ」ページとショートカット

「ようこそ」ページのショートカット・セクション

説明

「構成」ショートカット・パネルの各選択項目の詳細は、次のトピックを参照してください。

- 「使用可能なサービスの有効化または無効化」

- 「共通設定の管理」

- 第8章「Access Manager設定の構成」

- 第17章「Oracle Security Token Serviceの設定値と設定の管理」

新規..をクリックして、新しいエージェント作成ページを開きます。詳細は、「「システム構成」タブについて」を参照してください。

「新規アプリケーション・ドメイン」をクリックして、新しい「アプリケーション・ドメイン」ページを開きます。詳細は、「「ポリシー構成」タブについて」を参照してください。

新規...をクリックして、適切な詳細を入力できる新しいページを開きます。詳細は、第V部「Oracle Security Token Service」を参照してください。

機能レベルのタブとコントロール

表3-3は、Oracle Access Managerコンソールの機能レベルのタブを示します。

表3-3 機能タブと説明

機能タブ名

説明

ポリシー構成

共有コンポーネントおよびアプリケーション・ドメインの定義にアクセスできます。コンソールに入ると、このタブがアクティブで、関連のナビゲーション・ツリーが画面左側に表示されます。

詳細は、「「ポリシー構成」タブについて」を参照してください。

システム構成

注意: これは、コンソールに入るときにはアクティブ・タブではありません。

ここに示すように、システム・レベル定義にアクセスできます。

詳細は、「「システム構成」タブについて」を参照してください。

次の各項目で特定のコントロールについて詳細情報を提供します。

- ナビゲーション・ツリー

- メニューおよびツール・バー

- 「表示」メニュー

- 「アクション」メニュー

関連項目:
「コンソールでのコントロールの選択」

ナビゲーション・ツリー

アクティブな構成タブのナビゲーション・ツリーが、コンソールの左側に表示されます。指定されたノードはグループを識別し、その下で処理を行う個々のインスタンスを選択できます。

「ポリシー構成」タブおよび「システム構成」タブのナビゲーション・ツリーのノードを、図3-4に示します。各ナビゲーション・ツリーの上のメニューおよびツール・バーを確認してください。

図3-4 メニューおよびツール・バーがあるナビゲーション・ツリーの例

「図3-4 メニューおよびツール・バーがあるナビゲーション・ツリーの例」の説明

関連項目:

- 「システム構成」タブについて

- 「ポリシー構成」タブについて

メニューおよびツール・バー

メニューは、ナビゲーション・ツリーで選択された項目に処理を行うときに使用可能なコマンドを提供します。ほとんどのメニュー・コマンドは、すばやいアクセスのためにツール・バーのコマンド・ボタンとしても提供されています。コンソールの各ナビゲーション・ツリーの上にメニューおよびツール・バーが表示されます。

表示しているタブまたはサブタブに応じて、異なる集合のメニューおよびコマンド・ボタンが使用可能になります。さらに、コンソール内のいくつかの構成ページには、メニューおよびツール・バーを提供する表が含まれます。図3-5。

図3-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー

「図3-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー」の説明

関連する機能が使用可能な場合、コマンド・ボタンはフル・カラーで表示されます。機能が使用できない場合は、コマンド・ボタン(またはメニュー項目)はグレー表示されます。たとえば、ノードを開いて、選択した登録または定義を編集または削除できます。表3-4は、ツール・バーの各コマンド・ボタンの説明です。いくつかのボタンのみが使用可能です。

表3-4 ツール・バーのコマンド・ボタン

ボタン

定義

説明

作成

ナビゲーション・ツリーの選択したノードの下に新しいページが開き、ここに情報を入力して、選択したタイプの新しい構成を追加できます。新しいページは、アクティブなページとしてナビゲーション・ツリーの右側に開きます。

これは、サーバー・インスタンスや特定のエージェント・タイプ、ユーザー・アイデンティティ・ストア、非HTTPリソース・タイプまたはホスト識別子、アプリケーション・ドメインの下など、新しい構成を追加できるときに使用可能です。

別の方法として、表3-6にあるように、「アクション」メニューの「作成」コマンドを使用することもできます。

開く

ナビゲーション・ツリー内の選択したインスタンスを開きます。

編集

表示または変更のために、ナビゲーション・ツリーで選択したインスタンスを開きます。構成ページは、アクティブなページとしてナビゲーション・ツリーの右側に開きます。

または、インスタンス名をダブルクリックすれば、ページを編集用に表示できます。

削除

選択した構成を削除します。削除された構成はナビゲーション・ツリーから除去されて、システムでアクセスできなくなります。たとえば、エージェント構成を削除すると、そのエージェントは登録解除されて使用できません。

別の方法として、表3-6にあるように、「アクション」メニューの「削除」コマンドを使用することもできます。

更新

WebブラウザでWebページを更新するときと同じように、ナビゲーション・ツリーを更新します。

複製

ナビゲーション・ツリーに選択した構成のコピー("オリジナルのコピー"という名前)を作成します。コピーはすぐに編集できるように、アクティブなページとして開きます。多くのフィールドに情報が記入済です。

例外: オブジェクト(たとえば、ポリシー名やリソースのURLパターン)の一意の識別子を構成するフィールドは、自動的に入力されません。

注意: 複製は普通と同じように編集して保存します。サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managerおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。

デタッチ

選択した項目(たとえば、構成ページの結果表など)を分割して、1ページ全面に単独で表示します。

注意: デタッチされた表を表示している場合は、このボタンをクリックしてそれを対応するページに添付し直して、標準のページ表示に戻すことができます。

ツール・バーのボタンとして使用可能なコマンドのほとんどは、メニューでも使用可能です。

関連項目:

- 「表示」メニュー

- 「アクション」メニュー

「表示」メニュー

図3-6は、「表示」メニューを示し、これは「ポリシー構成」および「システム構成」タブの両方で使用できます。

図3-6 「表示」メニュー

「図3-6 表示メニュー」の説明

使用できない項目(ナビゲーション・ツリーの選択時に使用できないもの)はグレー表示されます。「表示」メニューのコマンドの説明は、表3-5にあります。

表3-5 「表示」メニュー・コマンドの説明

コマンド

説明

展開

ナビゲーション・ツリーで選択したノードのアイテムをすぐに表示します。これによって構成ページが開いたり、アクティブにはなりません。

または、ナビゲーション・ツリーのノードの横にあるアイコンをクリックします。

折りたたむ

ナビゲーション・ツリーで選択したノードにあるすべてをすぐに非表示にします。これによってページが閉じたり、開いたりはしません。

または、ナビゲーション・ツリーのノードの横にあるアイコンをクリックします。

下をすべて開く

選択したノードにあるすべてを、すぐに表示します。たとえば、「アプリケーション・ドメイン」をクリックして、「下をすべて開く」をクリックすると、すべてのアプリケーション・ドメインが表示されます。

下をすべて閉じる

選択したノードをすぐに閉じて、その内容を非表示にします。これによってページが閉じたり、開いたりはしません。

すべて開く

ナビゲーション・ツリーのすべてのノードとインスタンスを、すぐに表示します。開いているページには何も影響はありません。

すべて閉じる

ナビゲーション・ツリーのすべてのノードとインスタンスを、すぐに非表示にします。開いているページには何も影響はありません。

最初までスクロール [Ctrl] + [Home]

ナビゲーション・ツリーまたは結果表の最初の項目を検索、表示します。

最後までスクロール [Ctrl] + [End]

ナビゲーション・ツリーまたは結果表の最後の項目を検索、表示します。

「アクション」メニュー

このメニューは、「システム構成」タブがアクティブなときのみ使用可能です。図3-6は「アクション」メニューを示し、これはナビゲーション・ツリーの選択されたインスタンスに対する適切なコマンドを提供します。たとえば、ナビゲーション・ツリーでアイデンティティ・ストア・インスタンスを選択している場合、「アクション」メニューのコマンドの1つを使用して、共通プロパティ・ページを開いて表示または編集できます。

図3-7 「アクション」メニュー

「図3-7 「アクション」メニュー」の説明

このメニューの特定のコマンドは、ツール・バーのコマンド・ボタンから使用できる機能を反映しています。使用できない項目(ナビゲーション・ツリーの選択時に使用できないもの)はグレー表示されます。「アクション」メニューのコマンドの説明は、表3-6にあります。

表3-6 システム構成、「アクション」メニュー、コマンドの説明

コマンド

説明

開く

ナビゲーション・ツリーで選択したインスタンスの構成ページを開きます。ナビゲーション・ツリーでノードが選択されている場合は、これは使用できません。

または、ナビゲーション・ツリーでインスタンス名をダブルクリックすると、ページが開きます。

作成

新しいページがアクティブになり、それに情報を入力して新しい構成を定義できます。

別の方法として、表3-4にあるように、ツール・バーの「作成」ボタンをクリックすることもできます。

モニター・メニュー

ナビゲーション・ツリーで選択したエージェントのモニタリング・ページを表示します。詳細は、第25章を参照してください。

共通プロパティを開く

「OAMサーバー共通プロパティ」ページを開き、すべてのOAMサーバーで共有される様々な機能構成を提供します。これは、システム・インスタンスがナビゲーション・ツリーで選択されているときのみ使用可能です。

削除

選択されたインスタンスの登録を削除します。削除された登録はナビゲーション・ツリーから除去されて、システムでアクセスできなくなります。たとえば、エージェント登録を削除すると、そのエージェントは登録解除されて使用できません。

別の方法として、表3-4にあるように、ツール・バーの「削除」ボタンをクリックすることもできます。

コンテンツのページおよびページ・コントロール

「ようこそ」ページと同じように、開いているページはすべてコンソールの右側に表示されます。

アクティブなコンテンツ・ページが表示され、関連の設定を追加したり、表示や変更可能な作業領域となります。名前の付いたタブは、書類フォルダのタブのように開いている各ページを識別します。アクティブなページのタブは白です。

各構成タブ(「ポリシー構成」タブまたは「システム構成」タブ)に、最大10ページを同時に開くことができます。現在アクティブな構成タブの開いているページで、名前の付いたタブのみが表示されます。

アクティブなページのみが表示され、開いている他のページの名前付きタブが1行に収まる限り含まれます。名前の付いたタブをクリックすると、対応するページをアクティブにできます。開いているページの名前付きタブが1行に入りきらない場合、ポインタが提供され、それを使用して非表示のページから選択したり開くことができます。図3-8は、同時に開かれている複数のページを示します。各ページの名前付きタブと、非表示のページにアクセスする(またはアクティブなページや複数のページを閉じる)ためのコントロールが示されています。

図3-8 開いているページのタブおよびページ・コントロール

「図3-8 開いているページのタブおよびページ・コントロール」の説明

各ページは一度のみ表示されます。同じページを何度も開こうとしても、警告は表示されません。ただし、そのページは一度だけしか表示されません。

注意:
同じ項目のページを2回以上開く場合、警告は表示されません。

開いているページで使用できるコントロールは、表3-7に記載されています。

関連項目:
「コンソールでのコントロールの選択」

表3-7 開いているページのコントロール

ページ・コントロール

定義

説明

非表示のページのリストを表示します。

すべてのタブを同時に見ることができないときに、ポインタをクリックすると、非表示のページのリストを見ることができます。

アクティブなページを閉じます。

このボタンをクリックすると、アクティブなページが閉じます。

注意: 「適用」をクリックする前にページを閉じると、警告なしにすべての変更や追加が破棄されます。変更は失われます。これを使用すれば、保持したくない変更をキャンセルできます。

複数のページを閉じます。

- このボタンをクリックすると、複数の開いているページが閉じられます。

- 表示されるダイアログ・ボックスで、閉じる各ページ名の横にあるボックスをクリックします。

- アクションを完了するには、「OK」をクリックします。

注意: 「適用」をクリックする前にページを閉じると、警告なしにすべての変更や追加が破棄されます。変更は失われます。これを使用すれば、保持したくない変更をキャンセルできます。

ページの要素

コンソールのページには、表3-8にあるグラフィカル・ユーザー・インタフェースの要素が1つ以上含まれます。コンソールの各要素の例は、図3-8を参照するか、コンソールにログインして確認してください。

表3-8 ページの要素と説明

ページ要素

説明

名前付きタブ

コンソール右側の開いている各ページを識別します。また、関連する下位レベルの設定も表示されます。詳細は、図3-2を参照してください。

ページ・コントロール

1つまたは複数のページを閉じることができます。表3-7を参照してください。

「適用」ボタン

ページへの変更や追加を送信します。

名前の付いたテキスト・ボックス

キーボードを使用して、名前の付いたフィールドに適切な詳細を入力可能にします。

「オプション」ボタン

いくつかのオブジェクトから1つを選択できます。たとえば、オプション・ボタンをクリックして、状態(有効または無効)やセキュリティ・モード(オープン、簡易、証明書)を定義できます。

表

現在の仕様や新しい仕様のスペースを表示します。テーブルには、ページ・レベルやオプションのボタンに依存しない独立したコマンド・ボタンがあります。

テーブルのコマンド・ボタン

次のことが可能です。

新しい行または定義を表に追加します。

選択した行または定義を表から削除します。

ドロップダウン・リスト

特定のページで(および検索コントロールの一部として)選択メニューを提供します。リストされた項目から1つを選択できます。

コンソールでのコントロールの選択

この項では、ナビゲーション・ツリーで目的のノードやインスタンスを選択する方法と、コンソールでのコマンドやページ・コントロールの選択について説明します。通常の選択のガイドラインが適用されます。

表3-9は、選択肢とコントロールについて説明します。

表3-9 選択タスクとコントロール

タスク

コントロール

説明

ノードを展開する

ナビゲーション・ツリーで目的のノードの横にある展開ボタン(>)をクリックすると、その中にあるノードやインスタンスが表示されます。

ノードを閉じる

ナビゲーション・ツリーで目的のノードの横にある閉じるボタン(V)をクリックすると、その下にあるノードやインスタンスが非表示になります。

「表示」メニューの表示

マウス・ボタンを右クリック

ナビゲーション・ツリーで希望するノードを右クリックすると、ポップアップの「表示」メニューが表示されます。

アクティブ化

マウス・ボタンをクリック

クリックして次の必要な項目をアクティブ化します。

- 「機能」タブ: システム構成、ポリシー構成、参照、検索

- 表示または変更のために関連する低レベルの設定を表示する、ページ上の名前付きタブ: 「リソース」や「レスポンス」など。

- ページを表示(アクティブ化)するための名前付きページ・タブ

- ページに情報を入力するためのテキスト・フィールド

- ページ・コントロール(表3-7に記載されている閉じるボタンやすべてを閉じるボタン)

開く

マウス・ボタンをダブルクリック

またはフォルダを開くアイコン

インスタンス名をダブルクリックすると、構成ページが開きます。たとえば、次の特定項目をダブルクリックします。

- リソース・タイプ名

- ホスト識別子の定義名

- 認証のスキーム名

- アプリケーション・ドメインのリソース名

- アプリケーション・ドメインの認証ポリシー名

- アプリケーション・ドメインの認可ポリシー名

- エージェント・インスタンス名

- サーバー・インスタンス名

- ユーザー・アイデンティティ・ストアのインスタンス名

- データベースのインスタンス名

- 認証モジュール名

- システム・ユーティリティ名

ハイライト

カーソルをドラッグ

ハイライトするには、ボックスのテキストに沿ってカーソルをドラッグします。

選択

マウス・ボタンをクリック

処理を行いたい項目をクリックします。たとえば、次の必要な項目をクリックします。

- アイコン、ノード、またはナビゲーション・ツリーのインスタンス名(共有コンポーネントは一例です)

- 「検索」ボタン: 指定した条件に基づいて検索を開始します。

- ナビゲーション・ツリーで選択した項目に処理を行うためのメニュー名およびコマンド

- ただちにアクションを実行するためのコマンド・ボタン
メニューおよびツール・バーのボタン(表3-4)

ページを閉じるボタン(表3-7)

- ページまたは表のコマンド・ボタン:
「適用」: アクティブなページで追加や変更を送信します。

表やセクションのボタン(表3-8)

新しい行の追加。

選択した行の削除。

- リンク: ヘルプ、およびサインアウトは例です。

ポリシー構成およびシステム構成のタブの概要

この項では、主要なOracle Access Managerの機能を簡単に説明します。

- 「システム構成」タブについて

- 「ポリシー構成」タブについて

「システム構成」タブについて

Oracle Access Managerコンソールでは、白いタブがアクティブです。この項では、次の3つの独立したセクションを提供する「システム構成」タブを説明します。

- 共通構成

- Access Managerの設定

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

各セクションは、関連するナビゲーション・ツリーの上に独立したメニューおよびツール・バーを提供するため、個別に表示および使用できます。

「アクション」メニューは「システム構成」タブとともに使用する場合のみ使用可能であり、「表示」メニューは常に使用可能です。アクティブなページが右側に表示されます。図3-9は、完全に折りたたんだ形および完全に展開した形の両方の「システム構成」タブを示します。

図3-9 「システム構成」タブ(折りたたみ済および完全に展開済)

「図3-9 「システム構成」タブ(折りたたみ済および完全に展開済)」の説明

システム構成の詳細は、次を参照してください。

- 第II部「共通タスクに対するコンソールの使用」

- 第III部「Oracle Access Manager設定管理」

- 第V部「Oracle Security Token Service」

「ポリシー構成」タブについて

Oracle Access Managerコンソールの「ポリシー構成」タブは、管理者に認証ポリシー、認可ポリシーおよび共有SSOコンポーネントへのアクセス権を提供します。

「参照」サブタブは、ナビゲーション・ツリーを表示します。「検索」サブタブは、ポリシー要素の検索結果を表示します。

図3-10の表示は、「共有コンポーネント」および「認証スキーム」の下にある第1レベルの項目の一覧です。

図3-10 「ポリシー構成」、「共有コンポーネント」、折りたたんだ「アプリケーション・ドメイン」

「図3-10 「ポリシー構成」、「共有コンポーネント」、折りたたんだ「アプリケーション・ドメイン」」の説明

表3-10は「ポリシー構成」サブタブを示します。

表3-10 「ポリシー構成」サブタブ

サブタブ

説明

参照

「ポリシー構成」タブの「参照」サブタブは、アクティブな構成タブ(ポリシーまたはシステム)に関連するノードおよびインスタンスにアクセスできる、ナビゲーション・ツリーを表示します。このタブは、コンソールに入るときにアクティブです。

検索結果

「ポリシー構成」タブの「検索」サブタブは、最新の検索結果へのアクセスを提供します。「参照」タブと「検索結果」タブの上に検索のコントロールが表示されます。

詳細は、「コンソールを使用した検索の実行」を参照してください。

コンソールのコマンド・ボタンやページ・コントロール、メニュー項目のナビゲーションと選択については、「コンソールのレイアウトおよびコントロール」を参照してください。

また、「表示」メニューにあるコマンドを使用して、ナビゲーション・ツリーで選択したノードを展開したり、すべてのノードを同時に展開することもできます。たとえば、「表示」メニューから「すべて開く」をクリックすると、すべてのノードと関連のインスタンスが同時に表示されます。

関連項目:
第VI部「共通のロギング、監査、パフォーマンス・モニタリング」

コンソールでの構成詳細の表示

管理者は、個々のエージェント、サーバー・インスタンス、データ・ソース、共有コンポーネントおよびアプリケーション・ドメインの構成詳細を、Oracle Access Managerコンソールから表示できます。

この例では、OAMエージェント(Webgate)の構成詳細を表示します。ただし、同様の手順を使用して、サーバー・インスタンスやデータ・ソース、アプリケーション・ドメイン、共有コンポーネントの構成詳細を見ることができます。

または、OAM用のカスタムWLSTコマンドを使用して、エージェントやサーバー詳細を閲覧できます。

関連項目:
付録F「管理者用カスタムWLSTコマンドの概要」

コンソールを使用して構成詳細を表示する手順

1. Oracle Access Managerコンソールに移動し、通常どおりログインします。次に例を示します。

https://hostname:port/oamconsole

サンプルのURLでは、hostnameはOracle Access Managerコンソールをホストするコンピュータを、portはコンソールのホストがリスニングするHTTPポートの番号を指し、/oamconsoleはOracle Access Managerコンソールを識別します。

2. システム構成:

1. 「システム構成」タブをクリックします。

2. ナビゲーション・ツリーで、リストから目的のセクション名をクリックします。
共通構成
Access Managerの設定
セキュリティ・トークン・サービスの設定

3. 展開: 目的のノードの横にある展開アイコンをクリックします(または「表示」メニューからすべて展開をクリックします)。

4. インスタンスを開く: 構成を表示する目的のインスタンス名をダブルクリックします。

3. ポリシー構成:

1. 「ポリシー構成」タブ(コンソールに入るときデフォルトで使用可能です)をクリックします。

2. 展開: 目的のノードの横にある展開アイコンをクリックします(または「表示」メニューからすべて展開をクリックします)。

3. インスタンスを開く: 構成を表示する目的のインスタンス名をダブルクリックします。

4. ページを参照して、関心のある特定の詳細があれば記録します。

5. 右上隅のXコントロールをクリックして、ページを閉じます。

コンソールを使用した検索の実行

Oracle Access Managerコンソールでは、ポリシー要素とシステム・インスタンス(エージェントなど)に対して個別の検索コントロールが提供されます。この項では、ポリシー構成検索コントロールのみを説明します。

- コンソールを使用したポリシー要素検索の実行

- システム構成要素に対する検索の絞込み

コンソールを使用したポリシー要素検索の実行

ここでは、次の内容について説明します。

- ポリシー構成検索コントロールについて

- ポリシー要素の検索

ポリシー構成検索コントロールについて

ポリシー構成要素を検索するとき、検索する項目の正確な名前がわからない場合は、検索文字列にワイルド・カードを使用できます。検索結果表から、開いて表示または編集する項目を選択できます。

注意:
検索対象の正確な名前がわからない場合は、ワイルドカード(*)文字を使用できます。ただし、検索基準の大文字は、検索する項目の大文字と一致する必要があります。

ポリシー構成検索基準は保存できません。「システム構成」タブを選択して「ポリシー構成」タブに戻ると、検索フィールドおよび結果表は空になっています。

ポリシー構成検索コントロールの説明は、表3-11にあります。

表3-11 ポリシー構成検索コントロール

検索コントロール

説明

ポリシー構成の「検索」メニューから、検索を定義する項目を選択するか、単に「すべて」を選択します(デフォルト)。

テキスト・フィールドに、検索するインスタンスの名前を入力します(または検索文字列に名前の一部とワイルド・カード(*)を入力します)。

「検索」ボタンをクリックして、操作を開始します。

検索結果を表示するには、「検索」サブタブをクリックします。

結果表の名前をダブルクリックして、項目を開いて表示または編集します。

または、結果表の名前をクリックしてツール・バーのコマンド・ボタンをクリックします。

表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。

「表示」メニュー項目を選択して、結果表の表示を変更します。

注意: 「システム構成」タブをクリックすると、ポリシー構成検索フィールドおよび結果表がクリアされます。

ポリシー要素の検索

このトピックでは、Oracle Access Managerコンソールを使用してポリシー要素の検索を実行する方法を説明します。

注意:
検索文字列でワイルドカード(*)を使用できます。

次の例で、検索は特定のホスト識別子に対して実行されます。

ポリシー要素を検索する手順

1. 「ポリシー構成」タブをアクティブ化します。

2. 検索タイプのリストから、タイプを選択して検索を定義します。次に例を示します。

Host Identifiers

3. テキスト・フィールドに、検索するインスタンスの名前(または名前の一部とワイルド・カード)を入力します。次に例を示します。

my*

4. 「検索」ボタンをクリックして、操作を開始します。

5. 「検索結果」タブから結果表の名前をクリックし、次のようにします。

- 編集: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックして、インスタンスを削除し、「確認」ウィンドウが表示されたら削除を確認します。

- デタッチ: 表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. 完了してナビゲーション・ツリーに戻るには、「参照」タブをクリックします。

システム構成要素に対する検索の絞込み

この項では、Oracle Access Managerコンソールを使用して様々なシステム構成要素を作成または管理する際に使用する、いくつかの検索コントロールを説明します。

- OAMエージェント

- OSSOエージェント

- STSテンプレート

- STSパートナ

- STSプロファイル

表3-12に、そのような検索の絞込みに使用できる共通のコントロールを示します。コントロールのタイプは共通ですが、リストにある実際の選択は検索している特定の項目に適用されます。

関連項目:
このガイドの、関連するコンポーネント管理トピックとともに記載されている個別の検索トピック。

表3-12 共通のシステム構成検索コントロール

要素

説明

一致

「すべて」を選択して、指定のすべてに一致するテンプレートを検索します。

「任意」を選択して、少なくとも1つの指定に一致するテンプレートを検索します。

検索操作リスト

検索を絞り込むために選択する操作のリスト。

説明

オプションの説明フィールドを使用して検索を絞り込みます。

検索

フォームの基準を使用して検索機能を開始します。

リセット

デフォルトのみで「検索」フォームをリセットします。

フィールドの追加

表示: STSテンプレート用

検索基準として追加できる追加項目のリスト。一部のコンポーネントでは使用できません。

「検索結果」表

この表で後述するように、検索しているコンポーネントおよび「表示」メニューの選択項目に基づいて、検索結果を項目別にします。

「アクション」メニュー

表示: 検証テンプレート用のアクション

結果表の選択項目で実行できる次の機能を提供します。

注意: 「アクション」メニューの機能は、結果表の上のコマンド・ボタンをミラー化します。次に例を示します。

- 新規 ... テンプレート: 「検索」ページの上にある新規 ... テンプレート・ボタンをクリックするか、メニューから新規 ... テンプレートを選択するか、表の上にある「+」ボタンをクリックします。

- 編集: 結果表の名前をクリックするか、「アクション」メニューから「編集」を選択するか、結果表の上にある「編集」(鉛筆)コマンド・ボタンをクリックします。

- 類似作成: 表の目的の行を選択し、「アクション」メニューから「類似作成」を選択するか、表の上にある「類似作成」コマンド・ボタンをクリックします。

- 削除: 結果表の目的の行を選択し、「アクション」メニューから「削除」を選択するか、表の上にある「削除」(X)コマンド・ボタンをクリックします。

「表示」メニュー

結果表に表示する情報を識別できるリスト。

結果表にリストされる項目の順序を定義するために選択できるコントロール:

- 昇順

- 降順

システム構成ターゲットの検索を絞り込む手順

1. 「システム構成」タブをアクティブ化して、目的のセクションを展開します。

- 共通構成

- Access Managerの設定

- セキュリティ・トークン・サービスの設定

2. セクション内で、目的のノードを展開し、「検索」ページを表示するターミナル・ノードを開きます。

3. 検索: 目的のコントロールを選択して検索基準を入力し、「検索」ボタンをクリックします。

4. 「検索結果」表で、次のようにします。

- 編集または表示: ツール・バーの「編集」コマンド・ボタンをクリックし、編集可能な構成ページを表示します。

- 削除: インスタンスを削除するために表の上にある「削除」(X)ボタンをクリックし、「確認」ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表の再構成: 「表示」メニュー項目(表3-12)を選択して、結果表の表示を変更します。

5. 完了したら変更を適用します(またはページを閉じます)。

オンライン・ヘルプの使用

Oracle Access Managerコンソールを使用中はいつでも、ページの上にある「ヘルプ」リンクをクリックして詳細を確認できます。オンライン・ヘルプのトピックは、このマニュアルのオンライン版の情報にリンクしています。

オンライン・ヘルプのトピックは、このマニュアルのオンライン版の情報にリンクしています。オンライン・ヘルプの手順は、簡単な概要の後に手順そのものが続きます。

一般的に、Oracle Access Managerコンソールの「ヘルプ」を選択すると表示されるトピックは、英語と日本語のみで表示されます。オンライン・ヘルプは、9つのADMIN言語には翻訳されていません。

「ようこそ」タブをクリックすると、実行可能なアクションを説明したトピックのリストを表示できます。特定のヘルプ・トピックについては、次の手順を使用してください。

特定のヘルプ・トピックを検索する手順

1. Oracle Access Managerコンソールから、タブまたはナビゲーション・ツリーの名前付きノードをクリックします。

2. コンソールの右上隅にある「ヘルプ」をクリックします。

3. 新しいウィンドウに表示されるページを確認して、次のリンクのどれかを選択して次を実行します。

- 詳細 — このリンクをクリックして、詳細を表示します。

- 方法 — このリンクをクリックして、ヘルプ検索に関連するタスクの実行手順を表示します。

- 目次 — 左の「ヘルプ」ペインで、コンテンツを展開してすべてのヘルプ・トピックおよびオンライン・マニュアルのトピックすべてを表示します。

- 検索 — 検索ウィンドウが表示され、そこでヘルプの検索条件を入力できます。

4. 必要に応じて次のボタンをクリックします。

- 表示 — 表示オプションのセットを表示します。

- 矢印 — 前のページに戻ったり、次のページへ移動します。

- 「プリンタ」アイコン — ページを印刷します。

- 「エンベロープ」アイコン — ページを電子メールで送信します。

コマンドライン・ツール

コンソールではなく、キーボードを使用して様々なタスクを実行するために、コマンドライン・ツールがいくつか用意されています。これらのコマンドを使用した後は、コンソールで構成が使用できます。

- リモート登録ツールのoamregを使用すると、OAMエージェントおよびOSSOエージェント(mod_osso)のリモート登録、およびデフォルトのアプリケーション・ドメインの作成が可能です。

関連項目:
第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

- アップグレード・アシスタント(UA)を使用すると、OSSO 10gの構成をOracle Access Manager 11gに転送できます。

関連項目:

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド

- Oracle WebLogic Scripting Tool (WLST)には、Oracle Access Managerコンソールで実行可能なタスクについて、数多くのカスタムOAMコマンドラインの選択肢が用意されています。

関連項目:
付録F「管理者用カスタムWLSTコマンドの概要」

ロギング、監査、パフォーマンスのモニタリング

ロギング・メカニズムを使用して、重要なOracle Access Manager 11gコンポーネント・イベントを取得できます。ロギングとは、Oracle Access Manager 11gコンポーネントがメッセージをファイルに書き込むメカニズムです。これらのメッセージは、異なる詳細レベルで記録できます。

Oracle Access Manager、Oracle Security Token ServiceおよびOracle Fusion Middlewareの監査機能は、説明責任を果たすための手段と、「誰がいつ何をしたか」というタイプの質問への回答を提供します。

Oracle Access Managerは、Oracle Dynamic Monitoring Systems (DMS)を使用し、OAMサーバーおよび登録されたOAMエージェントについてアプリケーション固有のパフォーマンス情報を測定します。

管理者は、Oracle Fusion Middleware Controlを使用して、Oracle Access ManagerおよびOracle Security Token Serviceについてのパフォーマンスおよびログ・メッセージをモニターできます。

詳細は、第VI部「共通のロギング、監査、パフォーマンス・モニタリング」を参照してください。

- 第22章「コンポーネント・イベント・メッセージのロギング」

- 第23章「Webgateイベント・メッセージのロギング」

- 第24章「管理イベントとランタイム・イベントの監査」

- 第25章「Oracle Access Managerコンソールを使用したパフォーマンスのモニタリング」

- 第26章「Fusion Middleware Controlによるパフォーマンスおよびログの監視」

4 サービス、証明書検証および共通設定の管理

この章では、Oracle Access ManagerとOracle Security Token Serviceの両方に共通のプロパティのナビゲート方法および構成方法を説明します。この章には次のトピックが含まれます。

- 共通構成要素の概要

- 使用可能なサービスの有効化または無効化

- 共通設定の管理

- グローバル証明書検証および失効の管理

前提条件

第3章「共通の管理およびナビゲーションの基礎」

共通構成要素の概要

この項では、ドメイン内のすべてのOAMサーバーおよびサービスによって共有される共通のシステム構成要素の概要を示します。図4-1は、「システム構成」ナビゲーション・ツリーの「共通構成」セクションを示します。

図4-1 ナビゲーション・ツリーの「共通構成」ノード

「図4-1 ナビゲーション・ツリーの「共通構成」ノード」の説明

表4-1は、スイート内のすべてのサービスに適用される共通構成要素を説明しており、それぞれの詳細を確認できます。

表4-1 ナビゲーション・ツリーの「共通構成」ノード

ノード

説明

使用可能なサービス

すべてのサービスにアクセスできます。

関連項目: 「使用可能なサービスの有効化または無効化」

共通設定

セッションの存続期間、Oracle Coherence、監査構成、デフォルトおよびシステム・アイデンティティ・ストアを含む、スイート内のすべてのサービスに適用されるプロパティおよび設定を提供します。

関連項目: 「共通設定の管理」

サーバー・インスタンス

すべての登録されているOAMサーバー・インスタンスにアクセスできます。

関連項目: 第6章「共通のOAMサーバー登録の管理」

セッション管理

ユーザー・セッション管理操作にアクセスできます。

関連項目: 第7章「セッションの管理」

証明書検証

証明書失効リストおよびOCSP/CDP設定にアクセスできます。

関連項目: 「グローバル証明書検証および失効の管理」

データ・ソース

Oracle Access ManagerおよびOracle Security Token Serviceの登録済ユーザー・アイデンティティ・ストアにアクセスできます。

関連項目: 第5章「共通データ・ソースの管理」

プラグイン

Oracle Access Manager with Oracle Security Token Serviceの認証機能を拡張するためのカスタム・プラグインにアクセスできます。

関連項目: 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』

使用可能なサービスの有効化および無効化

デフォルトでは、インストール時にOracle Security Token Serviceは無効化されているため、ここで説明されているように有効化してからOracle Security Token Serviceを使用する必要があります。

図4-2は、「共通構成」セクションの「使用可能なサービス」ページを示します。このページは、サービスのステータスを表示し、サービスを有効化または無効化するコントロールを提供します。

図4-2 「使用可能なサービス」ページ

「図4-2 「使用可能なサービス」ページ」の説明

サービス名の横にある「ステータス」フィールドの緑のチェック・マークは、サービスが有効であることを示します。中に線がある赤の円は、該当するサービスが無効であることを示します。

Oracle Security Token Serviceが有効か、無効かにかかわらず、Oracle Access Manager (OAM)は有効であることが必要です。Oracle Access ManagerはOracle Security Token Serviceを必要としません。しかし、Oracle Security Token Serviceを使用するにはOracle Access Managerが有効である必要があります。

前提条件

AdminServerが稼動している必要があります。

Oracle Access Managerコンソールのログインとサインアウト

使用可能なサービスを有効化または無効化する手順

1. 通常どおり、Oracle Access Managerコンソールにログインします。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから「使用可能なサービス」をクリックします。

3. サービスの有効化: 目的のサービス名の横にある「有効化」をクリックします(または「ステータス」のチェック・マークが緑であることを確認します)。

4. サービスの無効化: 目的のサービス名の横にある「無効化」をクリックします(または「ステータス」のチェック・マークが赤であることを確認します)。

共通設定の管理

共通設定は、すべてのOAMサーバー・インスタンスおよびサービスに適用されます。ここでは、次の内容について説明します。

- 「共通設定」ページについて

- 共通設定の管理

「共通設定」ページについて

共通設定は、スイート内のすべてのサービスに適用されます。図4-3は、「共通設定」ページの名前付きセクションを示し、これらを展開すると関連する要素および値を表示できます。

図4-3 「共通設定」ページ(折りたたんだ表示)

「図4-3 「共通設定」ページ(折りたたんだ表示)」の説明

OAM管理者は、表4-2で説明されているように、単一のサービスのみでなくスイート全体で使用されるパラメータを制御および指定できます。

表4-2 共通設定

タブ名

説明

セッション

セッション管理とは、ユーザー・セッションのライフサイクル要件を管理するプロセスと、グローバル・ログアウトを可能にするためのセッション・イベントの通知を指します。エンティティのセッションのログアウトでログアウトがすべてのエンティティに伝播していることを確認するには、OSSOエージェント(mod_osso)のグローバル・ログアウトが必要です。

関連項目: 「共通設定の管理」。

コヒーレンス

すべてのOAMサーバーで共有される共通のOracle Coherence設定は、個々のOAMサーバーの設定とは異なります。ただし、どちらの場合でも、Oracleサポートの指示がない限りは、これらの設定を調整しないことをお薦めします。

関連項目: 「共通設定の管理」。

監査構成

Oracle Access Managerは、多数の管理イベントおよび実行時イベントの監査、統一されたロギングおよび例外処理、すべての監査イベントの診断をサポートしています。Oracle Access Manager監査構成は、oam-config.xmlに記録されます。

関連項目: 「共通設定の管理」。

デフォルトおよびシステム・アイデンティティ・ストア

このセクションは、デフォルト・アイデンティティおよびシステム・ストアを識別し、これは同じ(または異なる)ものになる場合があります。

関連項目: 「共通設定の管理」。

関連項目:
すべてのOAMコンポーネントに共通の他の操作の詳細:

- 第22章「コンポーネント・イベント・メッセージのロギング」

- 第25章「Oracle Access Managerコンソールを使用したパフォーマンスのモニタリング」

共通設定の管理

有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行して、「共通設定」ページの表示および変更の実行ができます。それぞれの主な手順には、このマニュアル内に記載されている詳細への参照が含まれています。

前提条件

OAMサーバーが稼動している必要があります。

共通設定を管理する手順

1. 「システム構成」タブから、「共通構成」セクションを展開し、ナビゲーション・ツリーの「共通設定」をダブルクリックします。

2. セッション:

1. 「共通設定」ページで「セッション」セクションを展開します。

2. 必要に応じて、各リストの横にある矢印キーをクリックしてセッションのライフサイクル設定を増減させます。
セッションの存続期間
アイドル・タイムアウト
1ユーザー当たりの最大セッション数

3. ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します(または選択を解除してデータベース永続性を無効化します)。

4. 「適用」をクリックして変更を送信します。

5. 関連項目: 第7章「セッションの管理」。

3. コヒーレンス: 「共通のコヒーレンス設定の表示」を参照してください。

4. 監査構成:

1. 「監査構成」セクションを開きます。

2. 「監査構成」セクションで、使用環境の詳細を正しく入力します。
最大ログ・ディレクトリ・サイズ
最大ログ・ファイル・サイズ
監査から特定のユーザーを含めるためのフィルタ設定(「ユーザー」表の
上にある「+」ボタンをクリックしてフィールドに値を入力します)

3. 「適用」をクリックして「監査構成」を送信します(または変更を適用しないでページを閉じます)。

4. 関連項目: 第24章「管理イベントとランタイム・イベントの監査」。

5. デフォルトおよびシステム・アイデンティティ・ストア:

1. 「デフォルトおよびシステム・アイデンティティ・ストア」セクションを展開します。

2. システム・ストア(またはデフォルト・ストア)の名前をクリックし、構成ページを表示します。

3. 詳細は、「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

共通のコヒーレンス設定の表示

図4-4は、「コヒーレンス」セクションを展開した「共通設定」ページを示します。

注意:
Oracleサポートの支援なしにこれらの設定を変更しないことをお薦めします。

図4-4 共通のコヒーレンス設定

「図4-4 共通のコヒーレンス設定」の説明

表4-3は、これらの設定について説明します。

表4-3 共通のコヒーレンス設定

要素

説明

ポート

1から65535の範囲の値を指定できます。

クラスタ・アドレス

224.1.255.0から239.255.255.255の値が許可されます。

存続時間

0から255の値がサポートされます。

クラスタ・ポート

1から65535の範囲の値を指定できます。

共通のコヒーレンス設定を表示する手順

1. 「システム構成」タブから「共通構成」セクションを展開し、「共通設定」をダブルクリックします。

2. 「共通設定」ページで「コヒーレンス」セクションを展開します。

3. 終了する場合はページを閉じます。

グローバル証明書の検証および取消の管理

ここでは、次の内容について説明します。

- 証明書検証および失効リストについて

- 証明書失効リスト(CRL)の管理

- 証明書検証の管理

- CDPの構成

証明書検証および失効リストについて

Oracle Access Managerは、オンライン証明書ステータス・プロトコル(OCSP)を使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーとそのステータスを通知されるクライアント・アプリケーションの間の通信構文を指定します。

OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。

証明書検証モジュールはOSTSによって使用され、次を使用してX.509トークンを検証し、証明書が失効しているかどうかにかかわらず必要かどうかを検証します。

- 証明書失効リスト(CRL)

- Online Certificate Status Protocol

- CRL配布ポイント拡張(CDP拡張)

証明書失効リスト(CRL)は、公開鍵インフラストラクチャを使用する場合のネットワーク内のサーバーへのアクセスを保守する一般的な方法です。CRLは、デジタル証明書ステータスとペアになったサブスクライバのリストです。失効した証明書は理由とともにリストされます。証明書発行の日付および発行したエンティティも含まれます。さらに、各リストには次のリリースの提示日が含まれます。潜在的ユーザーがサーバーにアクセスしようとすると、サーバーはその特定のユーザーのCRLエントリに基づいてアクセスを許可または拒否します。

図4-5は、コンソールのグローバル証明書検証のOCSP/CDP設定を示します。

図4-5 グローバル証明書検証のOCSP/CDP設定

「図4-5 グローバル証明書検証のOCSP/CDP設定」の説明

図4-6は、コンソールを使用したCA CRLの追加を示します。

図4-6 「証明書失効リスト」ダイアログ・ボックス

「図4-6 「証明書失効リスト」ダイアログ・ボックス」の説明

証明書失効リスト(CRL)の管理

OAM管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。これは、連続したデータ保護の有効化および現在のCA証明書失効リストのインポートによって実現されます。

関連項目:
「証明書検証および失効リストについて」

前提条件

CA証明書失効リスト(CA CRL)をインポートできるようにします。

証明書失効リストを管理する手順

1. Oracle Access Managerコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開き、次のようにします。

1. 「有効」ボックスが選択されていることを確認します。

2. 追加: 「追加」ボタンをクリックし、CRLファイルを参照して選択し、「インポート」をクリックします。

3. 削除: 表内のリスト名をクリックし、「削除」(x)ボタンをクリックし、確認が表示されたら確認します。

4. 構成を保存します。

3. CRLを検索します。

1. 表を確認します。

2. 例による問合せを有効化し、表のヘッダー・フィールドにフィルタ文字列を入力します。

4. 「証明書検証の管理」に進みます。

証明書検証の管理

OAM管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。これは、オンライン証明書ステータス・プロトコルを有効化することによって実現されます。

関連項目:
「証明書検証および失効リストについて」

前提条件

CA証明書失効リスト(CA CRL)をインポートできるようにします。

証明書検証を管理する手順

1. Oracle Access Managerコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開きます。

1. 「有効」ボックスが選択されていることを確認します。

2. 構成を保存します。

3. OCSP/CDPノードを開きます。

1. OCSPを有効化します。

2. OCSPサービスのURLを入力します。

3. OCSPサービスのサブジェクトDNを入力します。

4. この構成を保存します。

5. 「CDPの構成」に進みます。

CDPの構成

OAM管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。

関連項目:
「証明書検証および失効リストについて」

CDPを構成する手順

1. Oracle Access Managerコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開きます。

1. 「有効」ボックスが選択されていることを確認します。

2. 構成を保存します。

3. OCSP/CDPノードを開きます。

1. CDPを有効化します。

2. この構成を保存します。

5 共通データ・ソースの管理

この章では、Oracle Access Managementコンソールでデータ・ソースを登録および管理する手順について説明します。この章には次のトピックが含まれます。

注意:
特に明記しないかぎり、この章の情報は、Oracle Access Managerを単体で使用している場合もOracle Security Token Serviceとともに使用している場合も同じです。

- 前提条件

- 共通データ・ソースの管理の概要

- ユーザー・アイデンティティ・ストアの管理

- デフォルト・ストアおよびシステム・ストアの設定

- コンソールを使用したポリシー・データベースの管理

前提条件

この項では、この章のタスクの要件を明らかにします。この章のタスクを開始する前に、次のトピックを確認してください。

- 共通データ・ソースの管理の概要

- ユーザー・アイデンティティ・ストアの管理

共通データ・ソースの管理の概要

次のトピックに記載されているように、Oracle Access Manager with Oracle Security Token Serviceでは様々なタイプのデータを管理する必要があります。

- ユーザー・アイデンティティ・ストアについて

- ポリシーおよびセッション・データベース・ストアについて

- Oracle Access Manager構成データ・ファイルについて

- Oracle Access Managerセキュリティ・キーおよび組込みJavaキーストアについて

- Oracle Security Token Serviceキーストアについて

関連項目:

- 第7章: Oracle Coherenceを使用してメモリー内に格納され、Oracle Databaseに伝播されたセッション・データの詳細

- 第24章: 監査ファイルまたは個別のOracle Database(ポリシー・ストアではなく)に格納された監査データの詳細

ユーザー・アイデンティティ・ストアについて

ユーザー・アイデンティティ・ストアは一元化されたLDAPストアで、管理者およびユーザー指向の集計データが系統だって維持管理されます。

- システム・ストアとして指定されたユーザー・アイデンティティ・ストアのみが、Oracle Access Managerコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。

- OAMに保護されたリソースにアクセスしようとするユーザーは、デフォルトのユーザー・アイデンティティ・ストアとしてマークされたストアのみでなく、任意のストアに対して認証できます。

- Oracle Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。トークン発行ポリシーにユーザーの制約を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルトのユーザー・アイデンティティ・ストアである必要があります。

注意:
Oracle Access Managerコンソールを使用する管理者は、システム・ストアに存在する必要があります。OAMに保護されたリソースにアクセスしようとするユーザーは、指定されたデフォルトのストアのみでなく、任意のストアに対して認証できます。Oracle Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。

リモート・ユーザー・ストアをシステム・ストアとして定義すると、OAMAdminConsoleSchemeを変更して、同じリモート・ユーザー・ストア(システム・ストア)を参照するLDAP認証モジュールを使用する必要があります。

Oracle Access Managerコンソールでは、ユーザー・アイデンティティ・ストアの登録は、「データソース」ノード(「システム構成」タブの「共通構成」セクション)の下にまとめられています。管理者は、Oracle Access ManagerコンソールまたはOAM 11gのカスタムWLSTコマンドを使用して、ユーザー・アイデンティティ・ストア登録の登録、表示、変更および削除が可能です。

Oracle Fusion Middleware構成ウィザードを使用した初回のWebLogic Serverドメイン構成時に、埋込みLDAPが唯一のユーザー・アイデンティティ・ストアとして構成されます。

注意:
埋込みLDAPは、ユーザーが10,000人未満のときにパフォーマンスが最も良くなります。ユーザーがこれより多い場合は、別のエンタープライズLDAPサーバーを考慮してください。

埋込みLDAP内では、"weblogic"がデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。

関連項目:
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』 部品番号

複数のアイデンティティ・ストア

管理者は、Oracle Access Manager with Oracle Security Token Serviceのユーザー・アイデンティティ・ストアを複数インストールできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。ただし、管理者ログインはシステム・アイデンティティ・ストアに対してのみ発生します。複数のアイデンティティ・ストアが登録されている場合、管理者は次を定義する必要があります。

- 管理ログインのシステム・ストア

- 移行中およびOracle Security Token Serviceの使用中に関与するデフォルトのユーザー・ストア

外部LDAPリポジトリは、次の場合に使用するユーザー、ロールおよびグループ・メンバーシップ情報を提供できます。

- 認証中にポリシーを評価する場合

- ポリシー内の認可制約に対するアイデンティティを評価する場合

- 認可ポリシーごとの制約のアイデンティティを検索するために、LDAPを使用する場合

Oracle Access Managerでのユーザー・アイデンティティ・ストアの登録は、OAMサーバーとの接続を提供するために必要です。アイデンティティ・ストアを登録した後、管理者はそれを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。

Oracle Access Managerは、各ユーザー移入およびアイデンティティ・ドメインとしてディレクトリに対処します。各アイデンティティ・ドメインは、単に構成済アイデンティティ・ストア名にマップします。

元のOracle Access Manager 11gリリースでは、ユーザーは単純なユーザー名/IDフィールドを使用して内部および外部の両方で識別されました。複数のアイデンティティ・レルムをサポートするには、ユーザーまたはグループのレルム間表現、またはアイデンティティ・ストア内に存在するエンティティが必要です。この表現は、正規識別子と呼ばれますが、Oracle Access Managerの様々なランタイムおよび管理コンポーネントに対する一意の識別子として機能します。

- 外部表現: アイデンティティ・ドメイン情報とともに単純なユーザー名を修飾します。
たとえば、Oracle Access Managerコンソールでユーザー名をリストする表には、それぞれのユーザーのアイデンティティ・ドメインを表示する列が含まれます。アイデンティティ・ドメインはアイデンティティ・ストア名にマップします。ユーザー情報を表示するすべての機能コンポーネント(コンソール、ポリシー、レスポンス、ロギング、セッション管理、監査など)は、アイデンティティ・ドメイン情報の場合と同様に修飾を開始します。

- 内部表現: 曖昧性解消をサポートするために、OAMは完全修飾名を格納および使用します(またはコンポジット・キーを形成するために両方のフィールドをそのまま使用します)。
たとえば、セッション管理エンジンはコンポジットを格納する必要をなくすためにこのようにしています。どちらの場合も、完全修飾名は表示されません。

認可ポリシー管理

認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Oracle Access Manager認可ポリシーのアイデンティティ制約コンポーネントのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。

ランタイム

認証および認可は、ポリシー・ランタイム・コンポーネントに基づきます。OAMIdentityは、認証されたユーザーおよびそのユーザーがメンバーとなっているグループ(存在する場合)のランタイム表現です。ポリシー評価中、OAMIdentity内の情報は、認可ポリシーのアイデンティティ制約の一部として格納されているものと照合されます。ドメインは、トークン内の名前修飾子としてアサートされます。

OAMプロキシの場合、既存のOAM_REMOTE_USERヘッダーに加えて、2番目のOAM_IDENTITY_DOMAINヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。

セッション

セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。

監査およびロギング

ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。

関連項目:

- 「ユーザー・アイデンティティ・ストアの登録ページについて」

- 「管理者ロールの管理」

- 「デフォルト・ストアおよびシステム・ストアの設定」

- 付録F「管理者用カスタムWLSTコマンドの概要」

ポリシーおよびセッション・データベース・ストアについて

OAM 11gでは、OAMポリシー・データおよび(オプションで)OAMユーザー・セッション・データを格納するためにデータベースを必要とします。

ポリシー・データベースは、ベンダーの指示に従ってインストールし、RCUを使用してOAM固有のスキーマで拡張する必要があります(『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください)。Oracle Access Managerをデータベース・ポリシー・ストアの構成テンプレートとともに実行すると、OAM 11gポリシーとセッション・データを格納するデータベースが自動的に準備されます。

データベースは、Oracle WebLogic Serverドメインでの初回の構成時に、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Manager 11gに対して指定されます。

注意:
OAM 11gデプロイメントは、最大で1つのポリシーと1つのセッション・ストアを持つことができます。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。

次のデータが管理されます。

- 認証モジュール、スキーム、アプリケーション・ドメイン、認証および認可ポリシーを含むポリシー・データ。

- 分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ
管理者はOAM固有のスキーマでデータベースを拡張する必要があります。

注意:
本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。

関連項目:
「コンソールを使用したポリシー・データベースの管理」

Oracle Access Manager構成データ・ファイルについて

Oracle Access Managerには、OAM関連のシステム構成データをすべて含むXMLファイル(oam-config.xml)が用意されています。各OAMサーバーには、最新の構成XMLファイルのローカル・コピーが1つあります。

サーバーとエージェントの登録を含むOracle Access Managerデプロイメント構成に加えられたすべての変更は、oam-config.xmlファイルに格納されて、自動的に各OAMサーバーに伝播されます。

注意:
oam-config.xmlファイルは編集しないでください。変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。

高可用性環境でフェイルオーバーが構成されているかどうかに関係なく、すべてのOAMサーバーには常に最新のoam-config.xmlファイルがあります。

Oracle Access Managerセキュリティ・キーおよび組込みJavaキーストアについて

推奨のキーストア・フォーマットはJKS(Javaキーストア)です。Javaキーストアは水面下でOracle Access Manager 11gに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。次に例を示します。

- それぞれのOracle Access ManagerおよびOSSOエージェントは、他のエージェントが読むことのできない秘密鍵を持っています。

- Oracle Coherenceベースのセッション管理トラフィックを暗号化するキーがあります。

- エージェントとパートナ(アプリケーション)の登録時に、SSO Cookie(Webgateおよびmod_osso cookieの場合はObSSOCookie)の暗号化および復号化に使用されるキーが生成されます。

表5-1は、Oracle Access Manager 11g、10gおよびOSSO 10gによって生成された暗号化キーの比較と、それぞれの格納場所を簡単に説明しています。

表5-1 Oracle Access Manager 11g、10gおよびOSSOのキーの比較

OAM 11g

OAM 10g

OSSO 10g

暗号化キー

- WebgateとOAMサーバー間で共有されるエージェントの秘密鍵ごとに1つ

- 1つのOAMサーバー・キー

- 11g Webgate: OAMAuthnCookie

- 10g Webgate: ObSSOCookie

すべてのOAM Webgateに対してグローバルで共有される秘密鍵が1つ

- mod_ossoとOSSOサーバー間で共有されるパートナごとに1つのキー

- OSSOサーバー自身のキー

- GITOドメインcookieに設定されたOSSOごとにグローバル・キー1つ

キー・ストレージ

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

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

ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可)

- mod_osso側: 曖昧な構成ファイルにローカルで格納されるパートナ・キーおよびGITOグローバル・キー

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

注意:
キーストアはコンソールからは使用できず、表示や管理、変更はできません。

Oracle Security Token Serviceキーストアについて

Oracle Access Manager with Oracle Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。

- OAMサーバー・インスタンスに関連付けられたキーおよび証明書のシステム・キーストア

- OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するために使用されるキーおよび証明書の信頼キーストア

- パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のパートナ・キーストア。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。

- 証明書失効リスト(CRL)は、CRLベースの証明書失効確認の実行中に、Oracle Access Manager/Oracle Security Token Serviceサーバー・インスタンスによって使用されます。

次のファイルは、JMXフレームワークによってドメイン内のすべての管理対象サーバー間で配布されます。

- システム・キーストア: .oamkeystore

- 信頼キーストア: amtruststore

- パートナ・キーストア: .oamkeystore

- CRL: amcrl.jar

Oracle WSMエージェント・キーストア: Oracle WSMエージェントの機能は、WSポリシーの公開と、インバウンドおよびアウトバウンドWSメッセージにおけるメッセージ保護の施行のためにOracle Security Token Serviceで使用できます。Oracle WSMでは、システムおよびパートナ・キーおよび証明書用に、JKSタイプの別のキーストアが必要です。デフォルト名はdefault-keystore.jksであり、jps-config.xmlで指定されます。

注意:
Oracle WSMエージェント・キーストアとOAM/OSTSキーストアを常に別にしておくことをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Oracle Access Managerキーがアクセスされる可能性があります。

関連項目:
第18章「Oracle Security Token Serviceの証明書と鍵の管理」

ユーザー・アイデンティティ・ストアの管理

この項では、OAM 11g管理コンソールを使用してユーザー・アイデンティティ・ストアの登録を管理する上で必要な手順を説明します。

- ユーザー・アイデンティティ・ストアの登録ページについて

- 新規ユーザー・アイデンティティ・ストアの登録

- ユーザー・アイデンティティ・ストア登録の表示または編集

- ユーザー・アイデンティティ・ストア登録の削除

関連項目:
「デフォルト・ストアおよびシステム・ストアの設定」

ユーザー・アイデンティティ・ストアの登録ページについて

このトピックでは、「システム構成」タブの下の様々なユーザー・アイデンティティ・ストアの設定について説明します。

図5-1に、完了した登録のページを示します。「ユーザー・アイデンティティ・ストアの作成」ページも同様ですが、デフォルトの「接続の詳細」値以外は空です。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。

図5-1 デフォルト・ストアの完了した登録

「図5-1 デフォルト・ストアの完了した登録」の説明

ページ上のアスタリスク(*)は必須の設定です。表5-2は、タイプ別の各要素を示します。

表5-2 ユーザー・アイデンティティ・ストアの要素

要素

説明

ストア名

この登録の一意の名称。名称は最大30文字までを使用できます。

ストア・タイプ

サポートされているすべてのLDAPプロバイダのリスト。ここから選択できます。

説明

オプション。

SSLの有効化

このボックスをクリックして選択すると、ディレクトリ・サーバーとOAMサーバーの間でSSLが有効であることを示します。

場所と資格証明

ロケーション

パート番号を含むLDAPホストのURL。Oracle Access Manager 11gは、フェイルオーバー機能で複数のLDAP URLをサポートします。アイデンティティ・アサーション・プロバイダは、LDAP URLが表示される順序に基づいて次のLDAP URLにフェイルオーバーします。

「ロケーション」フィールドにURL値を指定している場合、ldap://またはldaps://(SSL_NO_AUTHをサポート)を指定する必要はありません。たとえば、次のように入力します。

localhost:7001

注意: サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managerおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。

バインドDN

接続プールのユーザーDNで、これを介して他のすべてのBINDが発生します。ユーザーおよびグループ・ベースのDNには、適切な読み取りおよび検索の権限を持つ管理者以外のユーザーをお薦めします。

例:

uid=amldapuser,ou=people,o=org

パスワード

プリンシパルのパスワードで、セキュリティのために暗号化されます。

ユーザーとグループ

ユーザー名属性

ユーザー名を識別する属性。

例:

uid

ユーザー検索ベース

ディレクトリ情報ツリー(DIT)のノード。この下にユーザー・データが格納され、すべてのユーザー・データ検索の最も高いベースとなります。

例:

ou=people,ou=myrealm,dc=base_domain

ユーザー・フィルタのオブジェクト・クラス

ユーザー・オブジェクト・クラス名のカンマ区切りリストで、ユーザーの検索結果に含めるオブジェクト・クラス。例: userやperson

グループ名属性

グループ名を識別する属性。

デフォルト: cn

グループ検索ベース

現在はuniquemember属性を持つ静的グループのみがサポートされています。

ディレクトリ情報ツリー(DIT)のノード。この下にグループ・データが格納され、すべてのグループ・データ検索の最も高いベースとなります。

例:

ou=groups,ou=myrealm,dc=base_domain

グループ・フィルタ・クラス

グループ・オブジェクト・クラスのカンマ区切りリストで、グループの検索結果に含めるオブジェクト・クラス。例: groups、groupOfNamesなど。

グループ・キャッシュの有効化(サイズ)

グループ・キャッシュのブーリアン値: trueまたはfalse

デフォルト: true

グループ・キャッシュ・サイズ

グループ・キャッシュ・サイズの整数

デフォルト: 10000

グループ・キャッシュTTL(秒)

グループ・キャッシュ要素、存続時間の整数(秒)。

デフォルト: 0

接続の詳細

最小プール・サイズ

接続プールに設定される最小サイズ。

デフォルト: 10

最大プール・サイズ

接続プールに設定される最大サイズ。

デフォルト: 50

待機タイムアウト

完全に利用されているプールで、接続リクエストがタイムアウトするまでの時間(秒)。

デフォルト: 120

非アクティブのタイムアウト

完全に利用されているプールのイベントで、接続リクエストがタイムアウトするまで非アクティブになることができる時間(秒)。

結果タイム・リミット(秒)

接続プールでのLDAPの検索およびバインド操作のタイム・リミット(秒)。

デフォルト: 0

再試行回数

接続の失敗があったときに、接続を再試行する回数。

デフォルト: 3

参照ポリシー

次の値のいずれかです。

- follow: LDAP検索時に参照に従います(デフォルト)

- ignore: LDAP検索時に参照エントリを無視します

- throw: ReferralExceptionの結果。コンポーネント・ユーザーが取得できます。

図5-2に、システム・ストアの完了した登録ページを表示されるとおりに示します。「アクセス・システム管理者」ロールがリストされています。定義済のシステム・ストアおよびストア自体内のみで、管理者ロールを追加または削除できます。

図5-2 システム・ストアの完了した登録

「図5-2 システム・ストアの完了した登録」の説明

関連項目:
ユーザーの分類の詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」

新規ユーザー・アイデンティティ・ストアの登録

有効な管理者の資格証明を持つユーザーは、この手順を利用して、管理者コンソールにより新しいユーザー・アイデンティティ・ストアを登録できます。

アイデンティティ・ストアを登録した後、それを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。アクセス・ポリシーの認可制約でも参照できます。

関連項目:

- 「ユーザー・アイデンティティ・ストアの登録ページについて」

- 「デフォルト・ストアおよびシステム・ストアの設定」

前提条件

登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。

新しいユーザー・アイデンティティ・ストアの定義を登録する手順

1. 「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。

2. 「ユーザー・アイデンティティ・ストア」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。

3. デプロイメントに適した値をフォームに入力し(表5-2)、「適用」をクリックして登録を送信します。

4. 接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。

5. 登録ページを閉じて、次の作業を実行します。

6. 管理者の追加: 「管理者ロールの管理」を参照してください。

1. ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。

2. 「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。

3. 「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。

4. 「適用」をクリックします。

7. デフォルト・ストアの設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

8. 「適用」をクリックして登録を送信してから、ページを閉じます。

9. このストアを使用するには、1つまたは複数の認証モジュールを構成します。詳細は「認証モジュール」にあります。

ユーザー・アイデンティティ・ストア登録の表示または編集

有効な管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。

前提条件

登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。

ユーザー・アイデンティティ・ストアの閲覧または変更の手順

1. 「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。

2. 「ユーザー・アイデンティティ・ストア」ノードを展開します。

3. 希望するユーザー・アイデンティティ・ストアの登録名をダブルクリックします。

4. 必要に応じて値を変更します(表5-2を参照)。

5. 「適用」をクリックして、登録を更新します(または変更を適用しないでページを閉じます)。

6. 接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。

7. デフォルト・ストアとして設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

8. 管理者ロールの管理: 「管理者ロールの管理」を参照してください。

9. 完了したらページを閉じます。

ユーザー・アイデンティティ・ストア登録の削除

有効な管理者の資格証明を持つユーザーは、この手順を利用して、管理者コンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。

注意:
デフォルト・ユーザー・アイデンティティ・ストアまたはシステム・ストアの登録は削除できません。

セカンダリ・ユーザー・アイデンティティ・ストア登録の削除の手順

1. 削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。

2. 「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。

3. 「ユーザー・アイデンティティ・ストア」ノードを展開します。

4. オプション: 目的のインスタンス名をダブルクリックして、削除する対象である(およびデフォルトでない)ことを確認してから、ページを閉じます。

5. 希望するインスタンス名をクリックしてから、ツール・バーで「削除」ボタンをクリックします。

6. 「確認」ウィンドウで「削除」ボタンをクリックします(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。

7. 定義がナビゲーション・ツリーにないことを確認します。

デフォルト・ストアおよびシステム・ストアの設定

この項には、次の項目が含まれます。

- デフォルト・ストアおよびシステム・ストアの設定について

- デフォルト・ストアおよびシステム・ストアの定義

デフォルト・ストアおよびシステム・ストアの設定について

アイデンティティ・ストア登録の後、新規ストアをデフォルト・ストアまたはシステム・ストア(あるいはその両方)として指定できます。

- デフォルト・ストア: Oracle Security Token Serviceによって使用され、パッチ適用時には移行目的で使用されます。

- システム・ストア: アイデンティティ管理ドメイン全体のアクセス・システム管理者ロールのグループ/ユーザーが含まれ、これに対してOAMAdminConsoleSchemeポイントによってLDAP認証モジュールが使用されます。

注意:
管理者ログインは、OAMAdminConsoleSchemeによって使用されるLDAP認証モジュールもそのシステム・ストアを使用する場合のみ機能します。システム・ストアを変更すると、アイデンティティ管理ドメイン全体に影響を与えます。別のストアをリモート・ストアとして設定する場合、ロックアウトを避けるためにOAMAdminConsoleSchemeも変更してください。

図5-4は、新しいユーザー・アイデンティティ・ストア登録を追加した直後に表示されるデフォルト・ストアおよびシステム・ストアのオプションを示します。

図5-3 新しいデフォルト・ストアおよびシステム・ストアのオプション

「図5-3 新しいデフォルト・ストアおよびシステム・ストアのオプション」の説明

図5-4は、デフォルト・ストアを表示したときの登録ページを示します。

図5-4 デフォルト・ストアの指定

「図5-4 デフォルト・ストアの指定」の説明

システム・ストアの指定を適用するとすぐに、アクセス・システム管理者ロールを追加するように要求されます(「管理者ロールの管理」を参照してください)。また、OAMAdminConsoleSchemeによって使用されるLDAPモジュールがシステム・ストアを参照するようにする必要もあります。

図5-5に示されているように、「共通設定」ページから「デフォルトおよびシステム・アイデンティティ・ストア」にアクセスすることもできます。

図5-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア

「図5-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア」の説明

デフォルト・ストアおよびシステム・ストアの定義

管理者の資格証明を持つユーザーは、次の手順を使用してデフォルト・ストアおよびシステム・ストアの指定を定義または変更できます。

関連項目:
ユーザー・アイデンティティ・ストアの管理

デフォルト・ストアおよびシステム・ストアを定義する手順

1. Oracle Access Managerコンソールから、次を開きます。
「システム構成」タブ
「共通構成」セクション
「データソース」ノード
「ユーザー・アイデンティティ・ストア」ノード

2. システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。

1. システム・ストアにするストア名をダブルクリックし、登録ページを開きます。

2. 「システム・ストアとして設定」の横にあるボックスを選択します(ドメイン全体の認証および認可操作用)。

3. 「適用」をクリックして指定を送信します。

4. 管理者の追加: 「管理者ロールの管理」を参照してください。

5. 認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。「認証モジュールの管理」を参照してください。

3. デフォルト・ストアの設定: このストアは、パッチ適用時の移行目的にのみ使用します。

1. デフォルト・ストアにするストア名をダブルクリックし、登録ページを開きます。

2. 「デフォルト・ストアとして設定」の横にあるボックスを選択し、このLDAPストアを設定します(移行用)。

3. 認証モジュール: OAMAdminConsoleSchemeのLDAPモジュールがこのストアを参照しないことを確認します。「認証モジュールの管理」を参照してください。

4. 登録ページを閉じて、次の作業を実行します。

管理者ロールの管理

ここでは、次の内容について説明します。

- 管理者ロールの管理について

- 管理者ロールの管理

管理者ロールの管理について

管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がIAMSuiteAgentによって使用されており、そのシステム・ストアも使用する場合にのみ機能します。

デフォルトでは、Oracle Access Manager with Oracle Security Token Serviceの管理者ロールは、WebLogic管理者ロール(Administrators)と同じです。ただし、企業によっては、Oracle Access Managerを担当するユーザーとOracle Security Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。

すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、図5-6に示すように「アクセス・システム管理者」セクションがページ上に開きます。

図5-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録

「図5-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録」の説明

ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図5-7 システム管理者ロールの追加に、使用するページおよびコントロールを示します。

図5-7 システム管理者ロールの追加

「図5-7 システム管理者ロールの追加」の説明

管理者ロールの管理

次の手順では、システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要がある管理者ロールの定義または削除方法を説明します。

前提条件

デフォルト・ストアおよびシステム・ストアの設定

システム・ストアの管理者ロールを追加または削除する手順

1. OAMの指定されたシステムLDAPストアで次のようにします。

1. 管理者に使用する目的のLDAPグループを定義します。

2. 管理者グループが、グループ検索ベースで使用可能なことを確認します。

2. システム・ストア登録の検索: 次の手順を実行します(またはシステム・ストアとして指定する、「データソース」ノード内の異なるシステム・ストアを検索します)。

1. Oracle Access Managerコンソールの「ようこそ」ページから、「構成」パネルの「共通設定」をクリックします。

2. 「デフォルトおよびシステム・アイデンティティ・ストア」セクションを必要に応じてスクロールおよび展開します。

3. システム・ストアの名前をクリックし、構成ページを表示します。

3. ユーザー・ロールの追加:

1. 「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。

2. 「タイプ」リストの「ユーザー」を選択し、「検索」ボタンをクリックします。

3. 結果リスト内で目的のユーザーをクリックし、「選択済の追加」ボタンをクリックします。

4. 必要に応じて繰り返し、目的の管理者ユーザー・ロールを追加します。

5. 「適用」をクリックしてユーザー・ロールを送信します。

4. グループ・ロールの追加:

1. 「アクセス・システム管理者」表の上にある「追加」(+)ボタンをクリックして、「システム管理者ロールの追加」ダイアログ・ボックスを表示します。

2. 「タイプ」リストの「グループ」を選択し、「検索」ボタンをクリックします。

3. 結果リスト内で目的のグループをクリックし、「選択済の追加」ボタンをクリックします。

4. 必要に応じて繰り返し、目的の管理者グループ・ロールを追加します。

5. 「適用」をクリックしてグループ・ロールを送信します。

5. 管理者ロールの削除:

1. 「アクセス・システム管理者」表で、削除するユーザーまたはグループを含む行をクリックします。

2. 表の上にある「削除」(x)ボタンをクリックします。

3. 確認するメッセージが表示されたら確認します。

4. 「適用」をクリックして削除を送信します。

6. 「認証モジュールの管理」の説明に従って、システム・ストアを使用する認証モジュールを修正します(新しいストアである場合)。

7. 新しいロールのテスト: ブラウザのウィンドウを閉じてから、再び開きます。

1. Oracle Access Managerコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。

2. Oracle Access Managerコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。

3. 新しい管理者ロールを使用してログインし、この試みが成功することを確認します。

コンソールを使用したポリシー・データベースの管理

この項には次のトピックが含まれます。

- Oracle Access Managerのデータベース・デプロイメントについて

- セッション・データの個別データベースの構成

Oracle Access Managerのデータベース・デプロイメントについて

Oracleではポリシー・ストアとして単一のデータベースが必要ですが、これはセッション・データの格納にも使用できます。データベースをセッション・ストアとして使用すると、スケーラビリティおよびフォールトトレランス性が増します(すべてのサーバーをダウンさせる電源イベントに対して)。1つのポリシー・データベースと1つのセッション・データベースまで持つことができます。

WebLogic構成ウィザードを使用した初回のデプロイメント中に、次のデータベース詳細が要求されます。

- データベース・ログインIDとパスワード

- データベース・サービス名と場所

WebLogic構成ウィザードを使用すると、データベースへの接続をテストできます。また、データベースはOAMに登録されます。

基本的なスキーマの作成は、RCUが起動されたときに発生します。RCUは、OAM 11gのデータを受け入れるためにデータベースを準備します。Oracle Access Managerをデータベース・ポリシー・ストアの構成テンプレートとともに実行すると、OAM 11gポリシーとセッション・データを格納するデータベースが自動的に準備されます。実際のOAMポリシー要素は、Oracle Access Managerコンソールがデプロイされて初めてWebLogic AdminServerが起動されたときに作成されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

注意:
OAMと使用するポリシー・ストアとして、1つのデータベースのみを登録できます。OAMには、ドメイン・ホームに読取り専用のoam-policy.xmlファイルが含まれています。このファイルは直接編集しないでください。変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。

セッション・データの個別データベースの構成

Oracle Access Manager 11gには"oamDS"というデータ・ソースが含まれており、これはOAMスキーマで拡張されたデータベース・インスタンスに対して構成されます。あらかじめ定義された次のJava Naming and Directory Interface(JNDI)名が、データ・ソースを参照するためにOAMサーバーにより使用されます。

jdbc/oamds (used by both the policy layer and session layer to access database)

次の手順を使用して、WebLogic管理コンソールを使用して個別のセッション・データのデータベース・インスタンスを作成できます。Oracle Access Managerコンソールでは、この処理はサポートされていません。

注意:
このまれなケースについては、手順2fの説明に従ってoam-config.xmlを慎重に編集することをお薦めします。

セッション・データ用に独立したデータベースを作成、使用する手順

1. セッション・データのデータベースをインストールおよび構成して、RCUをOAM固有のスキーマとともに使用し、セッション・データ・ストアとしてデータベースを設定します。

2. セッション・データに新しいデータ・ソース・インスタンスを作成します。

1. WebLogic管理コンソールからは、「ドメイン構造」パネルでドメイン名、「サービス」ノードを展開します。

2. JDBC、データ・ソースを展開します。

3. JNDI名jdbc/oamsessionというデータ・ソースを作成します。

4. 変更を保存します。

5. 次の手順でのデータ損失を防ぐために、OAMサーバーとAdminServerを停止します。

6. oam-config.xmlで、DataSourceName属性の値を編集して、手順1で構成したものにします。たとえば次のようになります。

domain-home/config/fmwconfig/oam-config.xml

変更前:

<Setting Name="SmeDb" Type="htf:map">
<Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
com:2001/AM</Setting>
<Setting Name="Principal" Type="xsd:string">amuser</Setting>
<Setting Name="Password" Type="xsd:string">password</Setting>
<Setting Name="DataSourceName" Type="xsd:string">jdbc/oamds</Setting>
</Setting>

変更後:

<Setting Name="SmeDb" Type="htf:map">
<Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
com:2001/AM</Setting>
<Setting Name="Principal" Type="xsd:string">amuser</Setting>
<Setting Name="Password" Type="xsd:string">password</Setting>
<Setting Name="DataSourceName" Type="xsd:string">jdbc/oamsession</Setting>
</Setting>

3. AdminServerとOAMサーバーを再起動します。

6 共通のOAMサーバー登録の管理

この章では、Oracle Access Managerコンソールを使用してOAMサーバー・インスタンスの登録をプロビジョニングおよび管理する方法を説明します。

トピックは次のとおりです。

- 前提条件

- OAMサーバー登録および管理の概要

- 個々のOAMサーバー登録の管理

前提条件

次の環境的な考慮事項が満たされていることを確認してください。

- Oracle WebLogic Server管理コンソールまたはWLSTコマンドを使用して、新しい管理対象サーバーがドメインに追加されている。

- 必要に応じて、Oracle JRFテンプレートが管理対象サーバー(またはクラスタ)に適用されている。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。

「OAMサーバー登録および管理の概要」に目を通すことをお薦めします。

注意:
特に指定のないかぎり、Oracle Access Managerのみを使用している場合も、Oracle Security Token Serviceとともに使用している場合も情報は同じです。

OAMサーバー登録および管理の概要

この項の次のトピックでは、Oracle Access Managerサーバー・インスタンスの登録と管理について説明します。

- OAM 11gとOAM 10gのサーバー側の違いについて

- 個々のOAMサーバー登録について

- 埋込みプロキシ・サーバーおよび下位互換性について

- OSSOとの組合せにおけるOAM 11g SSOと古いOAM 10g SSOについて

- OAMサーバーとWebgate間の通信について

OAM 11gとOAM 10gのサーバー側の違いについて

表6-1は、Oracle Access Manager 11g、OAM 10gおよびOracleAS SSO 10gのサーバー側の違いの概要を示します(表1-2の全体的な比較から抽出)。

表6-1 サマリー: OAM 11g、OAM 10gおよびOSSO 10gのサーバー側の違い

OAM 11g

OAM 10g

OSSO 10g

サーバー側のコンポーネント

- OAMサーバー(WebLogic管理対象サーバーにインストール)
OAMサーバー上で実行されるOracle Security Token Service

- (WebLogic管理サーバーにインストールされた)Oracle Access Managerコンソール

- アクセス・サーバー

- ポリシー・マネージャ

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

暗号化キー

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

- WebgateとOAMサーバー間で共有されるエージェントの秘密鍵ごとに1つ(エージェント登録時に生成)

- OAMサーバー・キー1つ(サーバー登録時に生成)

Webgateごとにグローバル共有秘密鍵1つ

- mod_ossoとOSSOサーバー間で共有されるパートナごとに1つのキー

- OSSOサーバー自身のキー

- GITOドメインcookieに設定されたOSSOごとにグローバル・キー1つ

キー・ストレージ

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

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

- Oracle Security Token Service

ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可)

- mod_osso側: 曖昧な構成ファイルにローカルで格納されるパートナ・キーおよびGITOグローバル・キー

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

個々のOAMサーバー登録について

管理者は、1つ以上の管理対象サーバーをOracle Access Manager with Oracle Security Token ServiceのWebLogic Serverドメインに追加できます。

WebLogic構成ウィザードを使用するときに、OAMサーバーは自動的に登録されます。ただし、構成ウィザードを使用しない場合は、通信チャネルを開くためにOAMサーバーを手動で登録する必要があります。

注意:
Oracle Access ManagerとOracle Security Token Serviceについて、サーバー登録に違いはありません。

または、OAM用のカスタムWLSTコマンドを使用して、サーバー登録を表示、編集または削除できます。すべての変更は自動的にOracle Access Managerコンソールおよびクラスタ内のすべてのOAMサーバーに伝播されます。

関連項目:
付録F「管理者用カスタムWLSTコマンドの概要」

OAMサーバーのみがOracle Access Manager 11gに登録されます。WebLogic管理サーバー上のOracle Access Managerコンソールは、自身には登録されません。

OAMサーバーの登録方法に関係なく、詳細(つまり、登録)はOracle Access Managerコンソールの「システム構成」タブの下にまとめられ、Oracle Access Managerコンソール内のOAMサーバー登録の詳細には次が含まれます。

- サーバー名、ホスト、ポート

- プロキシ: レガシー・アクセス・サーバーとして実行され、通信のセキュリティ・モードを定義します。詳細は、次を参照してください。

- 埋込みプロキシ・サーバーおよび下位互換性について

- OSSOとの組合せにおけるOAM 11g SSOと古いOAM 10g SSOについて

- OAMサーバーとWebgate間の通信について

- Oracle Coherence: セッション・データを含む様々なOAMサービスに分散されたキャッシュを提供します。

管理者は特定のインスタンス登録を検索し、新しくインストールされたOAMサーバーを登録して、Oracle Access Managerコンソールを使用してサーバー登録を表示、変更または削除できます。詳細は、「OAMサーバー登録のページについて」を参照してください。

埋込みプロキシ・サーバーおよび下位互換性について

Oracle Access Manager 11gのサーバー側コンポーネントは、既存のOracle Access Manager 10gポリシー強制エージェント(OAM 10G Webgateおよびアクセス・クライアント)およびOracleAS SSO 10g mod_osso (11gでOSSOエージェントと呼ばれる)との下位互換性を保持します。

レガシーOAM 10g SSO: OAMプロキシは複数のアクセス・クライアントから同時にリクエストを受け入れることができ、すべてのWebgateおよびアクセス・ゲートがOracle Access Manager 11gサービスとやり取りできるようにします。詳細は、「「OAMプロキシ」ページ」を参照してください。

関連項目:
「OSSOとの組合せにおけるOAM 11g SSOと古いOAM 10g SSOについて」

レガシーOracleAS 10g (OSSO): 統合されたOSSOプロキシは、OAM 11g使用時のOSSOエージェントを使用した認証中に、トークン生成およびトークン・リクエストに応じた検証を処理します。OSSOプロキシに構成は必要ありません。第9章および第10章の説明に従って、OSSOエージェントをOAM 11gに登録するのみです。

OSSOとの組合せにおけるOAM 11g SSOと古いOAM 10g SSOについて

OAM 10gがOracleAS(OSSO)10gに統合されて使用されている古いデプロイメントがある場合、OAM 11g SSOを使用するようにOracleAS SSOをアップグレードできます。

OAM 11gを使用するようにOSSOをアップグレードした後、OAM 10g WebgateをOAM 11g SSOの同じデプロイメントと動作させることができます。この場合は、必要に応じてOAMプロキシがOAM 10g AccessサーバーまたはOAM 11gサービスのどちらかにリクエストを転送します。

OAM 10g ObSSOCookieは、暗号化されたセッション・ベースのシングル・サインオンcookieで、ユーザーの認証が成功すると生成されます。OAM 10g ObSSOCookieはユーザー・アイデンティティ・ストア情報を格納し、必要があればユーザーはそれをキャッシュ化できます。

統合されたOAMプロキシは、10g ObSSOCookieのAES暗号化アルゴリズムをサポートして、リリース10g Webgateとの下位互換性を可能にします。10g Accessサーバーは、OAM 11gプロキシによって作成されたcookieを復号化できます(その逆も可)。これによって、OAM 11gが認証を実行し、OAM 10gが認可を行えるようになります(その逆も可)。

注意:
OAMプロキシによって作成されたOAM 11g ObSSOCookieは、Oracle Access Manager 10gアクセス・サーバーによって作成されたObSSOCookieと互換性があります。

詳細は、「「OAMプロキシ」ページ」を参照してください。

OAMサーバーとWebgate間の通信について

OAPチャネルの通信モードには次のものがあります。

- オープン: 通信のセキュリティがデプロイメントで問題にならない場合、この暗号化されていないモードを使用してください。

- 簡易: 認証局(CA)を自分で管理せずに証明書パスワードをプレーン・テキスとして送信するなど、セキュリティ上の考慮事項がある場合に、このオラクル社が署名する証明書モードを使用します。

- 証明書: OAMサーバーとWebgateで異なる証明書を使用し、信頼できるサード・パーティの認証局にアクセスがある場合に、これを使用します。

個々のOAMサーバー登録で、セキュリティ・モードは「プロキシ」タブで定義されます。この詳細は「OAMサーバー登録のページについて」にあります。

「簡易」と「証明書」のモードには次が必要です。

- すべてのOAMサーバーとWebgateに共通のセキュリティ・パスワード(「OAMプロキシの「簡易」および「証明書」モード・セキュリティのアクセス・プロトコルの管理」を参照してください)。

- 適切に署名されたX.509デジタル証明書(付録E「Oracle Access Manager 11gとの安全な通信」を参照してください)。

少なくとも1つのOAMサーバー・インスタンスが、エージェント登録時にエージェントと同じモードで実行中である必要があります。そうでなければ、エージェント登録が失敗します。ただし、エージェント登録の後に、OAMサーバーの通信モードは変更できます。エージェントとサーバー間の通信は、WebgateモードがOAMサーバーのモードと同じか、またはそれ以上であれば続けて機能します。エージェント・モードは高くでも問題ありませんが、低くすることはできません。たとえば、OAMサーバーのモードがオープンの場合、エージェントは3つのモードのどれでも通信できます。OAMサーバー・モードが簡易の場合、エージェントは簡易または証明書を使用できます。OAMサーバー・モードが簡易の場合、エージェントは証明書モードを使用する必要があります。

関連項目:
付録E「Oracle Access Manager 11gとの安全な通信」

個々のOAMサーバー登録の管理

この項では、Oracle Access Managerコンソールを使用して、OAMサーバー・インスタンスを登録および管理する方法を説明します。次の項目について説明します。

- OAMサーバー登録のページについて

- 新しいOAMサーバー・インスタンスの登録

- 個々のOAMサーバーおよびプロキシ設定の表示または編集

- 個々のサーバー登録の削除

OAMサーバー登録のページについて

有効な管理者の資格証明を持つユーザーは、Oracle Access Managerコンソールを使用して、新しくインストールされた管理対象サーバー(OAMサーバー・インスタンス)を登録したり、既存のOAMサーバー登録を変更できます。

または、OAM用のカスタムWLSTコマンドを使用して、OAMサーバー・インスタンスを登録および管理できます。変更はOracle Access Managerコンソールに反映されて、クラスタ内のすべてのOAMサーバーに自動的に伝播されます。

関連項目:
付録F「管理者用カスタムWLSTコマンドの概要」

図6-1は、Oracle Access Managerコンソールから見た一般的なOAMサーバーの登録ページを示します。

図6-1 「プロキシ」タブが表示されたOAMサーバー登録ページ

「図6-1 「プロキシ」タブが表示されたOAMサーバー登録ページ」の説明

個々のサーバー登録設定の説明は、表6-2にあります。

表6-2 OAMサーバー・インスタンスの設定

要素

定義

サーバー名

このサーバー・インスタンス名を識別する名称。WebLogic Serverドメインの初回デプロイメント時に定義されています。

ホスト

サーバー・インスタンスをホストするコンピュータのフルDNS名(またはIPアドレス)。例: host2.domain.com。

ポート

このサーバーが通信(リスニングと応答)するポート。

デフォルト: 5575

注意: SSLと管理対象サーバーの開いているポートがどちらも有効な場合、管理対象サーバーはデフォルトでSSLポートに設定されます。SSL以外のポートを使用することが必要な場合、認証スキームの資格証明コレクタURLを、プロトコルおよび非SSLポートとして'http'をポイントする絶対URLに設定する必要があります。

関連項目: 付録E「Oracle Access Manager 11gとの安全な通信」

プロキシ

「「OAMプロキシ」ページ」を参照してください。

コヒーレンス

「個々のサーバーの「コヒーレンス」ページ」を参照してください。

関連項目:
「個々のOAMサーバー登録の管理」

「OAMプロキシ」ページ

統合されたプロキシ・サーバー(OAMプロキシ)が、Oracle Access Manager(OAMサーバー)の各管理対象サーバーとともにインストールされます。OAMプロキシはレガシー・アクセス・サーバーとして使用され、OAM 11gに登録されたOAM 10gエージェントの下位互換性を提供します。エージェントは新しくインストールするか、OAM 10g SSOデプロイメント内で現在動作中でもかまいません。

それぞれのOAMプロキシ・インスタンスには、異なるポートが必要です。プロキシは、アプリケーションが起動するとリスニングを開始します。登録されたアクセス・クライアントは、プロキシとすぐに通信できます。

OAMプロキシは、構成と実行時のイベントを両方処理します。それぞれのOAMプロキシは、複数のアクセス・クライアントからのリクエストを同時に受け入れることができます。各OAMプロキシによって、OAMアクセス・クライアントはOracle Access Manager 11gサービスとやり取りが可能になります。内容は次のとおりです。

- 10g (10.1.4.3) Webgate

- 10g (10.1.4.2.0) Webgate

- 10g (10.1.4.0.1) Webgate

- 11g Webgate(プロキシ不要)

注意:
アクセス・クライアントについては、OAM 11gは認証と認可の機能のみを提供します。アクセス・クライアントによるポリシーの変更はサポートされていません。

OAMプロキシ設定は、表6-3の詳細から構成されます。

表6-3 個別のOAMサーバーのOAMプロキシ設定

OAMプロキシ設定

タイプ

値

ポート

int(整数)

このOAMプロキシ・インスタンスがリスニングする一意のポート。

プロキシ・サーバーID

OAMプロキシ(およびこのOAMサーバー・インスタンス)が存在するコンピュータの識別子。DNSホスト名が推奨ですが、有効かつ適切な任意の文字列を使用できます。

モード

OAMプロキシのOAMチャネル・トランスポート・セキュリティは、次のいずれかを使用できます(エージェント・モードは登録時に一致する必要があり、登録後に上げることができます)。

- オープン: 暗号化なし。

- 簡易: OAMエージェントとOAMサーバー間で渡されるデータは、OAMの自己署名証明書を使用して暗号化されます。
「簡易」モードを指定する前に、グローバル・パスフレーズを指定する必要があります。

- 証明書: OAMエージェントとOAMサーバー間のデータは、認証局(CA)が署名したX.509証明書を使用して暗号化されます。
注意: 「証明書」モードを指定する前に、信頼できるサード・パーティの認証局から署名済証明書を取得する必要があります。

注意: 「簡易」および「証明書」のトランスポート・セキュリティ・モードは、「OAMサーバー共通プロパティ」の「OAMプロキシ」タブで定義された情報により制御されます(「OAMプロキシの「簡易」および「証明書」モード・セキュリティのアクセス・プロトコルの管理」を参照してください)。

関連項目: 「簡易」および「証明書」トランスポート・セキュリティ・モードを構成する場合は、付録E。

OAMプロキシ・ロギング: Oracle Access Manager 11gコンポーネントは、他のOracle Fusion Middleware 11gコンポーネントと同じロギング・インフラストラクチャを使用します(第24章を参照してください)。しかし、OAMプロキシはロギングにApache log4jを使用します。

個々のサーバーの「コヒーレンス」ページ

Coherenceは、信頼性があり、スケーラビリティの高いピアツーピア・クラスタリング・プロトコルの上に、レプリケートおよび分散(パーティション)されたデータ管理およびキャッシング・サービスを提供します。Coherenceには単一障害点がなく、サーバーが動作不能になった場合やネットワークから切断された場合に、クラスタ化データ管理サービスを自動的および透過的にフェイルオーバーおよび再分散します。

新しいサーバーが追加されたり、障害の起きたサーバーが再起動されると、サーバーは自動的にクラスタに加わってCoherenceはサービスをそのサーバーにフェイルバックして、クラスタ・ロードを透過的に再分散します。Coherenceには、サーバーが自己修復できるようにするネットワーク・レベルの耐故障性機能と透過的なソフト再起動の機能があります。

Coherenceモジュールは、図6-1に示すように、値と個々のサーバー・インスタンスのタイプから構成されます。

図6-2 「コヒーレンス」ページと個々のOAMサーバーの値

「図6-2 「コヒーレンス」ページと個々のOAMサーバーの値」の説明

警告:

Oracleサポートから指示がない限り、個々のサーバーのOracle Coherenceの設定を変更しないようお薦めします。

表6-4 個別のOAMサーバーのデフォルトのCoherence設定

Coherenceモジュール

エントリのタイプ

説明とデフォルト値

LogLevel

文字列

OAMサーバー・イベントのCoherenceログ・レベル(0から9)。

LogPort

int(整数)

WebLogic Serverでロギングを行うCoherenceのニスニング・ポート。

LogLimit

文字列

Coherenceのログ制限

Coherenceのロギング: WebLogic Serverログにのみ表示されます。Oracle CoherenceのログからOracle Access Managerのログへの橋渡しはありません。Oracle Fusion Middleware 11gロギング・インフラストラクチャの詳細は、第22章を参照してください。

新しいOAMサーバー・インスタンスの登録

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managerコンソールを使用して新しい管理対象サーバー(OAMサーバー)のインスタンスを登録できます。

注意:
エージェントと通信するには、それぞれのOAMサーバーが登録されている必要があります。

前提条件

新しい管理対象サーバーのインスタンスが、Oracle WebLogic Serverドメインで構成され、まだ起動されていない状態である必要があります。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

- 「OAMサーバー登録のページについて」

OAMサーバー・インスタンスの登録の手順

1. 新しい管理対象サーバー・インスタンスをOracle WebLogic Serverドメインにインストールして構成し、このインスタンスを起動しないでください。

2. 通常どおり、Oracle Access Managerコンソールにログインします。

3. 「サーバー構成」タブの「共通構成」セクションから「サーバー・インスタンス」をクリックし、ツール・バーの上にある「作成」ボタンをクリックして新しいページを開きます。

4. 「作成: OAMサーバー」ページで、表6-2のとおりにインスタンスの詳細を入力します。

- サーバー名

- ホスト

- ポート

5. プロキシ: このOAMプロキシ・インスタンスの詳細を入力または選択します。詳細は表6-3にあります。

- ポート

- プロキシ・サーバーID

- モード(オープン、簡易、証明書)

関連項目:
付録E if (「簡易」または「証明書」モードを使用する場合)

6. Coherence: Oracleサポートから指示がない限り、個々のサーバー・インスタンスのOracle Coherenceの設定を変更しないようお薦めします。

関連項目:
「Coherenceの使用」

7. 構成を送信するには「適用」をクリックます。構成はナビゲーション・ツリーに表示されます。または、変更を適用せずにページを閉じてください。

8. 新しく登録したサーバーを起動します。

個々のOAMサーバーおよびプロキシ設定の表示または編集

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managerコンソールを使用して個々のサーバー・インスタンスの設定を表示または変更できます。たとえば、リスニング・ポートやプロキシ通信のトランスポート・セキュリティ・モードの変更が必要になる場合があります。

変更はすぐにOracle Access Managerコンソールに表示され、クラスタ内のすべてのOAMサーバーに伝播されます。

関連項目:

- 「OAMサーバー登録のページについて」

- 付録F「管理者用カスタムWLSTコマンドの概要」

- 『Oracle Fusion Middleware管理者ガイド』のアイデンティティ管理の新しい本番環境への移動に関する項

サーバー・インスタンスの登録を表示または変更する手順

1. 「システム構成」タブの「共通構成」セクションから、ナビゲーション・ツリーで「サーバー・インスタンス」ノードをクリックして展開します。

2. 希望するインスタンス名をダブルクリックして構成を表示し、次の作業を実行します。

- 表示のみ: 詳細の閲覧が終わったら、ページを閉じます。

- 変更: 残りの手順を実行して、構成を編集します。

3. 「OAMサーバー」ページで、表6-2に従ってインスタンスの詳細を変更します。

4. プロキシ: 表6-3に従ってこのOAMプロキシ・インスタンスの詳細を変更します。

関連項目:
付録E if (「簡易」または「証明書」モードを使用する場合)

5. Coherence: Oracleサポートから指示がない限り、個々のサーバー・インスタンスのOracle Coherenceの設定を変更しないようお薦めします。

関連項目:
「Coherenceの使用」

6. 「適用」をクリックして、変更を送信します(または変更を適用しないでページを閉じます)。

個々のサーバー登録の削除

有効な管理者の資格証明を持つユーザーは、次のタスクを実行してサーバー登録を削除できます。削除すると、OAMサーバーが無効になります。

前提条件

新しいOAMサーバー・インスタンスの登録

サーバー登録を削除する手順

1. 「システム構成」タブの「共通構成」セクションから、ナビゲーション・ツリーで「サーバー・インスタンス」ノードをクリックして展開します。

2. 希望するインスタンス名をダブルクリックして詳細を確認してから、ページを閉じます。

3. 希望するインスタンス名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

4. インスタンスがナビゲーション・ツリーから削除されたことを確認します。

5. WebLogic Server管理consoleからインスタンスを削除して、サーバー・インスタンスの削除を完了します。
あとは管理対象サーバー・ホスト上のノード・マネージャが自動的に処理します。

7 セッションの管理

この章では、セッション管理の概念とOracle Access Manager 11gでの手順について説明します。この章の内容は次のとおりです。

- 前提条件

- ユーザー・セッションとセッション管理の概要

- ユーザー・セッションのライフサイクル設定の構成

- アクティブ・ユーザー・セッションの管理

- セッション管理操作の検証

- セキュリティ

前提条件

この章のタスクを行うには次のことを確認または理解する必要があります。

- 「ユーザー・セッションとセッション管理の概要」の確認

- 第6章「共通のOAMサーバー登録の管理」の理解

- 第3章「共通の管理およびナビゲーションの基礎」の理解

ユーザー・セッションとセッション管理の概要

一般的に、ユーザーがWebサイトにアクセスすることをセッションと呼びます。Oracle Access Manager 11gでは、ユーザーはOracle Access Managerの認証サービスを通じて認証を受け、Oracle Access Managerに保護されたリソースにアクセスしなければなりません。

Oracle Access Manager 11gのセッション管理とはユーザー・セッションのライフサイクル要件を管理し、セッション・イベントを通知してグローバル・ログアウトを有効にするプロセスを言い、

Oracle Access Manager 11gのセッション管理エンジン(Session Management Engine: SME)は、セッション・イベントと通知のコントローラとして動作するSSOエンジンとのインタフェースを取ります。SMEサービスはユーザー・セッション・データの自動生成、更新、および管理を可能にし、管理者によるセッション・ライフサイクルの構成、および特定アクティブ・セッションの検索と削除を可能にします。

注意:
ユーザーは、同じセッションの間、登録されたOAMエージェントとOSSOエージェントの両方に保護されたリソースにアクセスできます。

Oracle Access Managerのインストールと構成の際には、セッション・データ・ストレージを選択する必要があります。クラスタ内のすべてのサーバーには同じストレージ・メカニズムが適用されますが、これはインストール後に変更できます。

セッション・データは、待機時間、可用性、およびリソース消費のバランスを取るために複数の層に保存されます。これには次のものが含まれます。

- 管理されている各Oracle Access Managerサーバーのローカルのメモリー内キャッシュ
このキャッシュには、アクティブ・サーバー・リクエストに使用するセッション・データが格納されます。現在使用されていないデータを迅速に排除するために短いTTLが使用されます。

- 管理されているすべてのOracle Access Managerサーバーによって共有される分散メモリー内キャッシュ
このキャッシュには、Oracle Coherenceによる管理のためにシリアル化されたセッション・データが格納されます。Coherenceを使用すれば、エージェントがコンタクトしてセッション関連のアクセス・リクエストを行うことのできるすべての管理サーバーで、セッション・データを使用できます。また、Coherenceは実行中のサーバー間でこのデータを複製して、フォールトトレランス性を提供します。分散キャッシュ内のエントリは、TTLではなく、マシンごとに適用される全体的なキャッシュ・メモリー・サイズに基づいて排除されます。

最大キャッシュ・メモリー・サイズに達すると、次のどちらのアクションが取られます。

- セッション・ストアが有効になると、スペースを確保するために分散キャッシュからエントリが排除されます。これらのエントリはデータベース内には存在しており、必要な場合は分散キャッシュに呼び戻すことができます。

- セッション・ストアが有効になっていない場合は、フォールバック・メカニズムとしてローカル・マシン上のフラット・ファイルにエントリが書き込まれます。このファイル内のエントリ数がそのアクティブ・セッション合計数のパーセンテージとともに増えるに従い、パフォーマンスは低下していきます。

注意:
ユーザーがログアウトした時、またはセッションが期限切れとなった時は、メモリ内ストアからセッション・データが自動的に削除されます。詳細は「ユーザー・セッションのライフサイクルについて」を参照してください。

- OAM 11gでは、OAMポリシー・データと(オプションで)OAMユーザー・セッション・データを保存するためのデータベースが必要です。このデータベースは、(何十万という同時ログインが行われるような)非常に大きなデプロイメントにフォールトトレランス性とスケーラビリティを提供します。
セッション・ストアには、セッション変更ごとに最新のデータが書き込まれます(ステップアップ認証はセッション変更の一例です)。これは非同期で行われるので、セッションの作成や更新を伴うリクエストの待機時間に影響しません。セッション・データは不意の電源異常時にも使用できます。

OAMセッション・データを保存するには、OAM固有のスキーマによってデータベース・セッション・ストアを開く必要があります。

- OAMの固有スキーマによってRCUを使用し、ポリシー・ストアまたはセッション・データ・ストアとしてデータベースを設定します。

- データベース・ポリシー・ストア構成テンプレートとともにOracle Access Managerを使用してOAMを有効にし、ポリシー・ストアおよびセッション・データ・ストアとしてデータベースを使用します。

Oracle Access Manager 11gはOracle Coherenceを使用して分散キャッシュのデータ・アクセス待機時間を短縮し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細は、「Oracle Coherenceとセッション管理」を参照してください。

管理者はユーザー・セッション・ライフサイクルを構成して、ユーザー・セッションの最大持続時間、ユーザーが再認証を必要とするまでの非活動時間、各ユーザーの持つアクティブ・セッションの最大数を定義できます。セッションの期限切れを設定すれば、ユーザーのログイン時とログアウト時にのみサーバーから認識できるOSSOエージェント(mod_osso)との相互運用性を有効にできます。詳細は、「ユーザー・セッションのライフサイクル設定の構成」を参照してください。

各セッションは固有のものであり、同じユーザーの別のセッションと区別するために、ユーザーIDとセッションIDによって識別されます。管理者は、特定のユーザーもしくはすべてのユーザーの1つまたは複数のアクティブ・セッションを特定して、削除できます。たとえば、開いているセッションの数が多過ぎるユーザーは、改めてセッションを開始できるように、管理者に連絡してそのセッションの一部または全てを削除するよう求めることができます。詳細は、「アクティブ・ユーザー・セッションの管理」を参照してください。

Oracle Access Manager 11gは、Tangosol Coherenceを使用して分散インストレーション内のセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagerコンソールとOAMサーバーの間の状態変更を通信します。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。OAM 11gの特定のコンポーネント間にファイアウォールが存在する場合、Coherenceによって使用される対応したUDPポートが開いている必要があります。そうでない場合、OAM 11gが正しく機能しない可能性があります。詳細は、「Coherenceの使用」を参照してください。

ユーザー・セッションのライフサイクルについて

ユーザー・セッションのライフサイクル設定は、Oracle Access Managerコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理のためのオプションは含まれていません。

ユーザー・セッションのライフサイクルとは、ユーザー・セッションの開始から終了までのユーザー・アクティビティの時間を言います。セッション・ライフサイクルの状態には次のものがあります。

- アクティブ: ユーザーがOracle Access Managerによって認証されるとセッションが開始されます。ユーザーがOracle Access Managerに保護されたコンテンツをリクエストし、なおかつセッションの期限が切れない限り、セッションはアクティブ状態に維持されます。

- 非アクティブ: セッション・ライフサイクル構成の「アイドル・タイムアウト」属性によって定義された時間にわたってユーザーがOAM保護コンテンツにアクセスしないと、そのセッションは非アクティブになります。

- 期限切れ: セッション持続時間が、「セッションの存続期間」属性によって定義された時間を超えました。

定められた「アイドル・タイムアウト」時間にわたってユーザーが何もしないと、アクティブ・セッションは非アクティブになります。セッション継続時間が定められた「セッションの存続期間」を超えると、そのセッションは期限切れとなります。

セッション管理エンジンは、非アクティブ・セッションのリストを維持します。アクティブ・セッションが非アクティブになるか期限切れになると、ユーザーは再認証をしなければなりません。期限切れとなったセッションのデータは自動的にメモリー内キャッシュ(またはオプションのSMEデータベース)から削除されます。管理者が削除できるのはアクティブ・ユーザー・セッションのデータのみです。

OSSO GITOのサポート: 特別な場合には、OAM 11gサーバーで使用する複数タイプのエージェント(mod_ossoとWebgate)が関係するタイムアウトをサポートするためのGITO Cookieが必要です。これが有効になっている時に(editGITOValues WLSTコマンドを使用)ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの－その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。切断された状態でセッションが稼動しているとしても、アイドル・タイムアウトは適切な形で適用されます(mod_ossoリクエストが実行されてもWebgateによって行われることはなく、サーバーから見るとそのセッションはアイドル・アウトしているように見えます)。

注意:
セッション管理エンジンは、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。詳細は「mod_osso Cookie」を参照してください。

OAMエージェントに対するユーザー・セッションのライフサイクル設定は、Oracle Access Managerコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理のためのオプションは含まれていません。

Oracle Coherenceとセッション管理

この項では、メモリー内キャッシュとSMEセッション・データ・ストアとして構成されたデータベースによるセッション管理において、組み込みのOracle Coherenceデータ管理およびキャッシング・サービスを使用する方法を説明します。

注意:
OAMサーバー間で共通のセッション状態を維持するには、Coherenceインフラストラクチャのクラスタ・メンバーをネットワーク接続する必要があります。ネットワーク・コンポーネントに障害が発生した時にもOAMセッション・データの共通性を必要とするデプロイメントには、冗長ネットワーキング・インフラストラクチャを使用することをお薦めします。

Oracle Coherenceは、セッション・データを複製してクラスタ内のすべての管理サーバーに分散します。クライアントはセッション・データの場所を意識せずに処理を行うことができます。Oracle Coherenceのトラフィックは自動的に暗号化されます。セッション管理エンジンは、必要に応じて他のOracle Access Managerコンポーネントにセッション・オブジェクトを開示します。データ待機時間を補正してオブジェクトのシリアル化とネットワーク転送を考慮に入れるために、キャッシュは、短命のセッション・オブジェクトを使用時に保持しておくためのニア・キャッシュとして構成されています。

注意:
Oracle Coherenceのトラフィックは自動的に暗号化されます。

Oracle Coherenceはフェイルオーバーとリコンシリエーションも行います。たとえば、1つの管理サーバーに障害が発生した場合、Oracle Coherenceは障害発生サーバーのデータを、他の管理サーバー・ホストの分散メモリー内キャッシュへ自動的に分散します。

図7-1に、組込みのOracle Coherenceによるセッション・データの保存を示します。説明は図の下のリンクをクリックしてください。

注意:
Oracle Access Managerコンソールは、WebLogic AdminServerに存在するアプリケーションです。セッション・データはAdminServerには保存されません。Oracle Access Managerコンソールからセッション管理操作を行うには、OAMサーバーが稼動している必要があります。

図7-1 セッション・データとOracle Coherenceのロール

「図7-1 セッション・データとOracle Coherenceのロール」の説明

プロセス概要: 認証成功後のSSOセッション・データの保存

1. セッションが作成されてセッションIDが割り当てられ、分散メモリー内キャッシュにセッション・データが保存されます。リソースをホストするコンピュータ(この例では管理サーバー1)上に、ローカルのメモリー内キャッシュにコピーを短期間保持しておくことができます。

2. 間もなく、ローカルのメモリー内キャッシュはセッション・データを同じホスト上の分散メモリ内キャッシュへ転送します。

注意:
分散メモリー内キャッシュの割当てメモリー・スペースが足りない場合は最も古いセッションがキャッシュから排除され、データベースが構成されている場合はそこに保存されます。セッション管理エンジンが分散セッション・ストアのみを使用するように構成されている場合、セッションはフラット・ファイル内に置かれます。

3. セッションが変わると、Oracle CoherenceはOAMサーバー(この例では管理サーバー2)の分散キャッシュ内にあるセッションデータを更新して複製し、分散します

注意:
同じセッション・データは2つのホスト(オリジナル・ホストと他の1つ)にのみ保存されます。

4. オプションのデータベース・ストアを使用している場合、Oracle Coherenceはそのデータベース・ストアにもオリジナル・ホストのセッション・データを分散します。

注意:
データベース・ストアにはオリジナル・ホストのセッション・データのみが書き込まれます。

5. 新しいリソース・リクエストが行われて、リソースをホストしているコンピュータ(この例では管理サーバー3)のローカルのメモリー内キャッシュにセッション・データが保存されます。

6. 間もなく、ローカルのメモリー内キャッシュはセッション・データを同じホスト(この例では管理サーバー3)上の分散メモリー内キャッシュへ転送します。

7. セッションが変わると、Oracle CoherenceはOAMサーバー(管理サーバー2とオプションのSMEデータ・ストア)の分散キャッシュ内にあるセッションデータを更新して複製し、分散します。

注意:
同じセッション・データは2つのホスト(オリジナル・ホストと他の1つ)にのみ保存されます。データベース・ストアにはオリジナル・ホストのセッション・データのみが書き込まれます。

8. OAMエージェントによって使用されるものと同じアクティブ・セッション内でOSSOに保護されたリソースをユーザーがリクエストする場合がありますが、OSSOユーザーのログインおよびログアウトのみがOAMサーバーによって認識されます。エージェント間の共存を有効にできます。

注意:
ユーザーは、OAMに保護されたリソースで作業をしながら、OSSOに保護されたリソースにアクセスできます。OAMに保護されたリソースを放置すると、アイドル・セッション・タイムアウトとなることがあります。しかし、ユーザーがOAM保護されたリソースに戻ると、Oracle CoherenceはOSSOエージェントでの作業時間に対してOAMエージェント・セッションの休止時間のリコンシリエーションを行い、グローバル・ログアウトができるようにします。

ユーザー・セッションのライフサイクル設定の構成

この項の内容は次のとおりです。

- 共通セッションのライフサイクル設定ページについて

- 共通セッションのライフサイクル設定の表示または変更

共通セッションのライフサイクル設定ページについて

ユーザー・セッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部です。図7-2は、「共通設定」ページの構成可能なライフサイクル属性を示しています。

図7-2 セッション詳細: 「共通設定」ページ

「図7-2 セッション詳細: 「共通設定」ページ」の説明

表7-1に、共通セッションのライフサイクル設定およびそのデフォルトを示します。セッションは切断モードで動作させることができます(たとえばmod_osso)。したがって、セッション規則を確立する構成の変更は、新しいセッションのみに適用されます。変更をただちに適用する必要がある場合は既存のセッションを終了し、ユーザーには新規則に適合するセッションを新たに作成させることをお薦めします。

表7-1 共通セッション設定

設定

説明

セッションのライフタイム

ユーザーの認証セッションが有効な状態に維持される時間(分)。ライフタイムに達すると、そのセッションは期限切れとなります。

デフォルト = 480分

このタイムアウト設定を無効にするには、値0を指定します。-2147483648から2147483647の任意の値が許可されます。

注意: 期限切れセッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。

アイドル・タイムアウト

ユーザーの認証セッションが、Oracle Access Managerに保護されたリソースにアクセスすることなく有効な状態に維持される時間(分)。これよりも長い時間アイドル状態が続くと、ユーザーは再認証を求められます。

デフォルト = 15分

このタイムアウト設定を無効にするには、値0を指定します。-2147483648から2147483647の任意の値が許可されます。

注意: 非アクティブ・セッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。

1ユーザーの最大セッション数

各ユーザーが同時に持つことのできるセッションの数。すべてのユーザーに対する複数セッション制限を構成するには、この設定を使用します。

0から2147483647の任意の値が許可されます。

アクティブ・セッションのデータベース永続性が有効

ローカルおよび分散キャッシュに加えて、構成済データベース・セッション・ストアにアクティブ・セッションを永続化します。すべての管理対象サーバーが停止している場合でも、セッションは保持されます。

デフォルト = 有効(選択)

使用する環境でこの必要がない場合、またはデータベースを考慮したサイズでデプロイメントを実行する場合、チェック・ボックスの選択を解除し、すべてのOAMサーバーを再起動してこの機能を無効にします。

共通セッションのライフサイクル設定の表示または変更

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、Oracle Access Managerコンソールによる共通セッションのライフサイクル設定を変更できます。

関連項目:
共通セッションのライフサイクル設定ページについて

共通セッションのライフサイクル設定を表示または変更する方法

1. 「システム構成」タブから「共通構成」セクションを展開し、「共通設定」をダブルクリックします。

2. 「共通設定」ページで「セッション」セクションを展開します。

3. 必要に応じて、各リストの横にある矢印キーをクリックしてセッションのライフサイクル設定を増減させます(表7-1)。

- セッションのライフタイム

- アイドル・タイムアウト

- 1ユーザーの最大セッション数

4. ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します。

5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

6. 終了したらページを閉じます。

7. 「アクティブ・ユーザー・セッションの管理」へ進んでください。

アクティブ・ユーザー・セッションの管理

「セッション管理」ページには、管理者がフィルタ条件に基づいて問合せを作成し、検索基準を後で使用するために保存し、検索をさらに絞り込むために問合せフォームにフィールドを追加できる検索コントロールが用意されています。

データベース・ストア構成で、セッションがデータベースには存在するがキャッシュには存在しない場合があります。セッション検索はシステム・タイムスタンプに基づきます。データベースに対して、タイムスタンプよりも先に更新されたセッションの問合せが行われます(書込み遅延を差し引いて)。キャッシュに対しては、このタイムスタンプよりも後に更新されたセッションの問合せが行われます。キャッシュおよびデータベースで検出された結果のデータがマージされます。重複した結果が存在する場合、キャッシュ・データが優先されます。検索操作に詳細パフォーマンス・メトリックが生成されます。

この項では、1ユーザーまたは全ユーザーの1つまたは複数のセッションを特定し、削除する方法を説明します。ここでは、次の情報が提供されます。

- セッション管理ページについて

- アクティブ・ユーザー・セッションの管理

セッション管理ページについて

図7-3に、「システム構成」タブの「共通構成」セクションにある「セッション管理」ページを示します。詳細は、図の後に説明します。

図7-3 共通構成: 「セッション管理」ページ

「図7-3 共通構成: 「セッション管理」ページ」の説明

表7-2では、フィルタ条件に基づいて問合せを作成できる「セッション管理」ページおよび検索コントロールについて説明します。

表7-2 セッション管理のコントロールと結果表

名前

説明

すべてのユーザー・セッションを削除

すべてのユーザーのアクティブ・セッションを削除するには、このコマンド・ボタンを選択します。

注意: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

保存済の検索

再使用のために以前保存した検索基準をリストします。検索基準を保存すると次のようなリストが常に使用可能になります。

パーソナライズを選択すると、次のウィンドウで新しい選択を行うことによって保存済検索基準の動作を変更できます。

一致、すべて、任意

検索中に、指定した条件のいずれかに一致させるか、またはすべてに一致させることができます。

注意: リソースがAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

ユーザーID

特定のユーザーIDをフィールドに入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。

検索を支援する次のリストが使用可能です。

クライアントIPアドレス

クライアントIPアドレスを入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。ユーザーID検索およびクライアントIPアドレス検索を支援する同じリストが使用可能です。

検索

このボタンをクリックすると、フォームの基準に基づいて検索が開始されます。

リセット

このボタンをクリックすると、フォームのすべての基準がクリアされます。

保存

このボタンをクリックすると、検索基準の再使用を有効にする検索操作が開始されます。次のウィンドウが開きます。

1. 後で選択するときに「保存済の検索」リストに表示する名前を入力します。

2. この検索をデフォルトとして設定します(またはチェック・ボックスの選択を解除します)。

3. この検索が自動的に実行されるように設定します(またはチェック・ボックスの選択を解除します)。

4. 結果のレイアウトを保存します(またはチェック・ボックスの選択を解除します)。

5. 「OK」をクリックします。

フィールドの追加

検索フォームに別のフィールドを追加できます。支援する次のリストが使用可能です。

1. 「フィールドの追加」ボタンをクリックします。

2. リスト内の項目をクリックしてフォームに追加し、「保存」をクリックします。

項目を追加した後、検索を支援するリストが使用可能になります。たとえば、雇用および時間ベースの選択には、次のリストが用意されています。

表示

結果表の上にある「表示」メニューからコマンドを選択して、表を構成します。次のコマンドを使用できます。

- 列: 表内の特定の詳細を表示または非表示にできる次のオプションを含むメニューを表示します。

- デタッチ: 結果の表を展開してフルスクリーン表示にします。

- アタッチ: 「セッション管理」ページの表示に戻ります。

- 列の並替え: 結果表のセッション・データを含む列の新しい配列を指定します。

削除

結果表から選択した項目を削除するには、このコマンド・ボタンを選択します。

注意: セッション検索基準が一般的なものである場合(たとえば、ワイルドカード(*)のみを使用する場合など)、大きなセッション・リストからセッションを削除する際に制限があります。セッション検索基準を十分に細分化することによって比較的小さな結果セット(理想的には20以下)を取得することをお薦めします。

付記: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

デタッチ

結果の表を展開してフルページ表示にするには、このボタンをクリックします。

注意: 表がすでにデタッチされてフルページ表示になっている状態で「デタッチ」をクリックすると、「セッション管理」ページに戻ります。

結果表(名前なし)

特定ユーザーのアクティブ・セッションを検索後、表に結果が表示されます。この表には次の詳細が含まれます。

- セッションID: OAMが作成したセッションのID。

- ユーザーID:

- 偽装:

- 作成時間: セッションが作成された日付と時刻。

- 最終アクセス: セッションに対する最後のアクセスの日付と時刻。

- クライアントIP: 指定したユーザーのIPアドレス。

- IDストア

- インパーソネータ

アクティブ・ユーザー・セッションの管理

有効な管理者の資格証明を持つユーザーは、次の手順に示す情報を利用して、検索結果表の構成、特定ユーザーのアクティブ・セッションの特定、特定ユーザーの1つ以上のセッションの削除、またはすべてのユーザーのすべてのセッションの削除を実行できます。

リソースがAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

関連項目:
セッション管理ページについて

必要のないステップはスキップしてください。

前提条件

OAMサーバーが実行中でなければなりません。

アクティブ・セッションの特定と管理

1. 「システム構成」タブの「共通構成」セクションから「セッション管理」ノードを開きます。
「ユーザー名」フィールドと結果表を含む「セッション管理」の「検索」ページが表示されます。

2. フィールドの追加: 「フィールドの追加」リストから、目的のフィールド名を選択します(表7-2)。

3. 演算子の選択: 選択した検索フィールドの演算子のリストを開き、目的の関数を選択します。

4. セッションの検索:

1. 目的の問合せフィールドで、基準を入力します(ワイルド・カード(*)の使用は任意)。

2. 「検索」ボタンをクリックして、基準のいずれかまたはすべてに一致するセッションを探します。

3. 結果表を確認します。

4. 必要に応じて繰り返し、検索を絞り込みます。

5. 結果表の構成: 「表示」メニューの機能を使用して、目的の結果表を作成します。

6. セッションの削除:

1. 結果表で、削除する1つ以上のセッションをクリックします。

2. 「削除」(x)ボタンをクリックして選択したセッションを削除します。

3. 「はい」をクリックして選択したセッションの削除を確定します(または「いいえ」をクリックして削除を取り消します)。

4. 必要に応じてユーザーに通知します。

7. すべてのユーザーのセッションの削除:

1. 右上隅にある「すべてのユーザー・セッションを削除」ボタンをクリックします。

2. 確認を求めるメッセージが表示されたら「はい」をクリックします。

8. 終了したら「セッション管理」ページを閉じます。

9. 「セッション管理操作の検証」に進みます。

セッション管理操作の検証

次の手順を使用してセッション管理操作を検証します。

セッション管理の検証方法

1. ブラウザからリソースにアクセスします。

2. 「アクティブ・ユーザー・セッションの管理」の説明に従い、Oracle Access Managerコンソールでユーザー・セッションが存在することを検証します。

3. 複数セッション:

1. (Cookieを削除した)別のブラウザから別のリソースへアクセスします。

2. ステップ2を繰り返して2つのセッションが存在することを確認します。

4. Oracle Access Managerコンソールですべてのユーザー・セッションを削除し(「アクティブ・ユーザー・セッションの管理」のステップ7)、アクティブ・ユーザー・セッションが削除されていることを確認します。

5. 再認証:

1. ステップ2のブラウザから、別のリソースへのアクセスを試みます。

2. 資格証明が要求されることを確認します。

6. データベースにセッション・データが作成されることを確認:

1. ステップ2のブラウザから、別のリソースへのアクセスを試みます。

2. 資格証明が要求されることを確認します。

7. データベースにセッション・データが作成されることを確認:

1. ステップ4を繰返してすべてのユーザー・セッションを削除します。

2. OAMユーザーとしてデータベースに接続し、下に示す問合せを実行して表示結果を取得します。

SQL> select * from oam_session

3. 次の結果が得られることを確認します。

1 row selected

4. ステップ2のブラウザから、別のリソースへのアクセスを試みます。

5. OAMユーザーとしてデータベースに接続し、下に示す問合せを実行します。

SQL> select * from oam_session

6. 次のようなデータが1行表示されることを確認します。

no rows selected

7. OAM_SESSION_ATTRIBUTESから行を選択して、そのユーザーのデータが存在することを確認します。

8. セッション管理のロギングの最適化:

1. 次のパスから使用プラットフォームのWLSTを起動します。次に例を示します。

MW_HOME/oracle_common/common/bin/wlst.sh

2. WLSTに接続してログインします。

3. domainRuntime()とsetLogLevel(target="oam_server1",logger="oracle.oam.engine.session",level="FINEST",addLogger=1)を実行します。

4. ファイル<domainhome>/servers/oam_server1/logs/oam_server1-diagnostic.logの内容を追跡確認します。

5. セッション操作を実行します。

6. セッション管理エンジンとセッション・ストア・モジュールのログ・メッセージを表示します。

7. ステップcを繰り返して「SEVERE」レベルに設定し、操作を実行してログ・メッセージを表示します。

セキュリティ

この項では、Oracle Access Manager 11gのセッション・セキュリティについて説明します。

- セキュアHTTPSプロトコル

- コヒーレンス

- データベースの永続性

セキュアHTTPSプロトコル

Oracle Access Manager 11gは、プロキシによるIPアドレス・チェックを提供することでセッションの固定化防止に役立ちます。セッションの固定化防止をさらに強化するには、セキュアHTTPSプロトコルを使用してください。

コヒーレンス

メモリー内ではデータは暗号化されませんが、転送時は保護されます。Coherenceは、様々なサーバー上の異なるOAMインスタンス間の通信を行います。この通信のセキュリティは次の2つの方法によって確保されます。

- Coherenceが前もってID確認されたホスト間の通信のみをサポートします。
これは一定のIPアドレス範囲として行うか、特定のホスト名によって行います。OAM構成ファイルには、通信に参加するサーバーのエントリが含まれています。起動時にはこの情報がCoherenceに提供され、認可されたサーバーのみが通信に参加するようにします。

- Coherenceは、すべての通信に適用されるネットワーク・フィルターをサポートしています。カスタム・フィルタをプラグインすれば、必要な特性を持つフィルタリングを行うことができます。
OAMは、インスタンス間で行われるすべての通信が共通鍵で暗号化/解読されるようにするカスタム・フィルタを備えています。この128ビット鍵はJCEKSで使用でき、インストール時に作成されます。

詳細はOracle Coherenceのドキュメントを参照してください。

データベースの永続性

このセッション管理エンジンはデータを暗号化しません。

セッション管理エンジンは、セッション・データをデータベースに書き込む際に暗号化を行いません。

懸念がある場合は、Oracle Advanced Securityなどを使用してデータベース内の暗号化を行ってください。

表7-1に説明されているように、「アクティブ・セッションのデータベース永続性が有効」がOracle Access Managerコンソールに表示されます。

第III部

Oracle Access Managerの設定管理

第III部では、低レベルのOracle Access Manager構成の管理について説明します。

第III部は、次の章で構成されています。

- 第8章「Access Managerの設定の構成」

- 第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

8 Access Managerの設定の構成

この章では、Access Manager固有の設定について説明します。この章は、次のトピックで構成されています。

- 前提条件

- Access Managerの設定の概要

- Access Managerのロード・バランシングとセキュア・エラー・モードの管理

- SSOトークンとIPの検証の管理

- OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

- 実行時のポリシー評価キャッシュの管理

- 認証モジュールの管理

- カスタム認証モジュールの作成

前提条件

この項では、この章のタスクの要件を明らかにします。この章のタスクを開始する前に、次のトピックを確認してください。

- 第3章「共通の管理およびナビゲーションの基礎」

- 第6章「共通OAMサーバー登録の管理」

「Access Managerの設定」の概要

「システム構成」タブの「Access Managerの設定」セクションには、Access Managerのサービスの操作に固有の設定が数多く用意されています。

図8-1 Access Managerの設定

「図8-1 Access Managerの設定」の説明

表8-1 Access Managerの設定

設定

参照先

ロード・バランシング

Access Managerのロード・バランシングとセキュア・エラー・モードの管理

SSO

SSOトークンとIPの検証の管理

アクセス・プロトコル

OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

ポリシー

実行時のポリシー評価キャッシュの管理

Access Managerのロード・バランシングとセキュア・エラー・モードの管理

ここでは、次の内容について説明します。

- Access Managerのロード・バランシング設定とセキュア・エラー・モードについて

- OAMサーバーのロード・バランシングとセキュア・エラー・モードの管理

Access Managerのロード・バランシング設定とセキュア・エラー・モードについて

図8-3に、「Access Managerの設定」ページの「ロード・バランシング」の設定セクションを示します。これは従来、「SSOエンジン」設定の一部でした。SSOエンジンはユーザー・セッションのコントローラです。設定はグローバルで、WebLogic管理ドメインのすべてのOAMサーバーに共通です。表8-4で、各要素とその使用方法を説明します。

図8-2 「Access Managerの設定」: 「ロード・バランサ」

「図8-2 「Access Managerの設定」: 「ロード・バランサ」」の説明

表8-2 「Access Managerの設定」: 「ロード・バランサ」

要素

説明

OAMサーバー・ホスト

OAMがインストールされるコンピュータの名前。

OAMサーバー・ポート

ホストがリスニングするポート。1から65535の範囲の値を指定できます。

OAMサーバー・プロトコル

HTTPまたはHTTPSです。

関連項目: 「セキュリティ・モードおよびX509Scheme認証について」

サーバー・エラー・モード

ここで選択する設定によって、操作が失敗したとき(ユーザー名またはパスワードが無効、サーバー・エラー(LDAPサーバーへの接続が切れている)など)にOAMサーバーによって返されるエラー・メッセージの性質や、エラー・コードが決まります。

次のいずれかの設定を選択し、カスタム・ログイン・ページのエラー・メッセージと各セキュリティ・レベルを構成します。

- セキュア: セキュリティが最も高い設定。汎用的なエラー・メッセージのみを表示し、エラーの内部的な理由はほとんど何も示されません。

- 外部: 推奨レベル。

- 内部: セキュリティ・レベルが最も低い設定。

- Osso10g: OSSO 10gと互換です。アップグレードした環境で、整合性のために必要な場合があります。

表8-3に、エラー・コード、トリガー条件、推奨のメッセージを示します。これらのエラー・コードはサーバー・エラー・モードに基づいており、公開されません。

表8-3 外部エラー・コード、トリガー条件、推奨メッセージ

外部エラー・コード

トリガー条件

推奨される表示メッセージ

OAM-1

許可される回数未満ですがログイン試行が無効です。

指定したユーザー名またはパスワードが正しくありません

OAM-2

許可される回数未満ですがログイン試行が無効です。

指定したユーザー名またはパスワードが正しくありません

OAM-3

送信された資格証明の処理がなんらかの理由で失敗しました。たとえば、WNAモードでSPENGOトークンが受信されない場合などです。

内部エラー。

OAM-4

なんらかの理由で認証例外が発生しました。

システム・エラーです。システム管理者に連絡してください。

OAM-5

特定の条件が原因で(たとえば、無効な試行回数を超過)ユーザー・アカウントがロックされています。

OIM統合。パスワードの検証後、「エラー」ページに連絡先詳細が表示されます。

ユーザー・アカウントがロックされているか、無効です。

システム管理者に連絡してください。

OAM-5

特定の条件が原因で(たとえば、無効な試行回数を超過)ユーザー・アカウントがロックされています。

OIM統合なしのOID: パスワードの検証後、「エラー」ページに連絡先詳細が表示されます。

ユーザー・アカウントがロックされているか、無効です。

システム管理者に連絡してください。

OAM-5

ユーザー・アカウントが無効です。

ユーザー・アカウントがロックされているか、無効です。

システム管理者に連絡してください。

OAM-6

ユーザーが許可される最大セッション数を超えました。これは構成可能な属性です。

ユーザーはすでにセッションの最大許容数に達しました。ログインを再試行する前に、既存のセッションの1つをクローズしてください。

OAM-7

失敗の原因はいくつか考えられます。セキュリティ上の理由により、正確な理由はユーザー・レベルに伝播されません。次に例を示します。

- リクエストIDが失われた可能性がある場合

- 証明書が正しく取得されていない場合

特定のメッセージが伝播されていない場合、デフォルトのエラー・メッセージが表示されます。

システム・エラーです。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。

OAMサーバーのロード・バランシングとセキュア・エラー・モードの管理

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagerコンソールでAccess Managerのロード・バランシング設定を変更できます。

関連項目:
「Access Managerのロード・バランシング設定とセキュア・エラー・モードについて」

共通のロード・バランシング仕様を表示または編集する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「Access Managerの設定」を開いてページを表示します。

2. 「Access Managerの設定」ページで、ロード・バランシングのセクションを展開します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: 残りの手順を実行して、構成を編集します。

3. 表8-2の詳細に基づいて、デプロイメントの必要に応じて、設定を編集します。

4. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. 「SSOトークンとIPの検証の管理」に進みます。

SSOトークンとIPの検証の管理

ここでは、次の内容について説明します。

- Access ManagerのSSOトークンとIPの検証の設定について

- SSOトークンとIPの検証の管理

Access ManagerのSSOトークンとIPの検証の設定について

図8-3に、「Access Managerの設定」ページのシングル・サインオン(SSO)の部分を示します。表8-4で、各要素とその使用方法を説明します。

図8-3 「Access Managerの設定」: 「SSO」

「図8-3 「Access Managerの設定」: 「SSO」」の説明

表8-4 「Access Managerの設定」: 「SSO」

要素

説明

IPの検証

Webgateに固有で、クライアントのIPアドレスがシングル・サインオン用に生成されたObSSOCookieに格納されているIPアドレスと同じかどうかを決定するために使用されます。

IP検証を有効にする場合はボックスを選択します。

IP検証を無効にする場合はボックスの選択を解除します。

SSOトークン・バージョン

リストからSSOトークン・バージョンを選択します。

SSOトークンとIPの検証の管理

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagerコンソールでAccess Managerのロード・バランシング設定を変更できます。

関連項目:
「Access Managerのロード・バランシング設定とセキュア・エラー・モードについて」

Access ManagerのSSO仕様を表示または編集する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「Access Managerの設定」を開いてページを表示します。

2. 「Access Managerの設定」ページで、「SSO」セクションを展開します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: 残りの手順を実行して、構成を編集します。

3. 表8-4の詳細に基づいて、デプロイメントの必要に応じて、設定を編集します。

4. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. 「OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理」に進みます。

OAMプロキシの簡易モードおよび証明書モードのセキュリティのためのアクセス・プロトコルの管理

この項の内容は次のとおりです。

- 簡易および証明書モードのトランスポート・セキュリティについて

- セキュア・サーバー通信の共通OAMプロキシ・ページについて

- OAMプロキシの簡易または証明書設定の表示または編集

簡易および証明書モードのトランスポート・セキュリティについて

表8-5は、簡易モードと証明書モードの共通点を示します。

関連項目:
付録E「Oracle Access Manager 11gとの安全な通信」

表8-5 サマリー: 簡易モードと証明書モード

アーティファクトまたはプロセス

簡易モード

証明書モード

オープン・モード

X.509デジタル証明書のみ。

X

X

なし

OAMエージェントとOAMサーバー間の通信は、Transport Layer Security、RFC 2246(TLS v1)を使用して暗号化されます。

X

X

なし

それぞれの公開鍵に対して、Oracle Access Managerがファイルに格納する対応する秘密鍵があります。

aaa_key.pem

openSSLにより生成

aaa_key.pem

CAにより生成

なし

プライバシ強化メール(PEM)フォーマットの署名された証明書

openSSLにより生成されるaaa_cert.pem

CAにより生成されるaaa_cert.pem

なし

OAMサーバーの構成中に、使用するモードに応じて、秘密鍵をグローバル・パスフレーズまたはPEMフォーマット詳細で保護します。OAMサーバーまたはWebgateで秘密鍵を使用するには、正しいパスフレーズが必要です。

最小限に暗号化されたファイルに格納されるグローバル・パスフレーズ:

- password.xml

PEMフォーマット:

- キーストア別名

- KEYSTOREStoreキー別名のパスワード

なし

OAMエージェントまたはOAMサーバーの登録中に、通信モードがOracle Access Managerコンソールに伝播されます。

それぞれのWebgateおよびOAMサーバー・インスタンスについて同じパスフレーズ。

それぞれのWebgateおよびOAMサーバー・インスタンスについて異なるパスフレーズ。

なし

Webgateの証明書リクエストによって、証明書リクエスト・ファイルが生成されます。これを、OAMサーバーにより信頼されているルートCAに送信する必要があります。

ルートCAは、Webgate証明書を返します。この証明書は、Webgateのインストール中またはインストール後にインストールできます。

cacert.pem

Oracle提供のopenSSL認証局により署名された証明書リクエスト

aaa_req.pem

使用する認証局により署名された証明書リクエスト

なし

DESアルゴリズムを使用して秘密鍵を暗号化します。次に例を示します。

openssl rsa -in aaa_key.pem -passin pass: -out aaa_key.pem -passout pass: passphrase -des

なし

X

なし

エージェント・キー・パスワード

なし

「証明書」セキュリティ・モードでエージェントの登録中にパスワードを入力します(表9-4)。

なし

エージェント登録時に、ObAccessClient.xmlが次の場所に生成されます。

$DOMAIN_HOME/output/$Agent_Name/

ObAccessClient.xml

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/config/OHS/ohs1/webgate/config

条件:
11gWebgate_instance_dir=Oracle_Home/instance/instance1

10g Webgateの場合: $Webgate_install_dir/oblix/lib

ObAccessClient.xml

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

ObAccessClient.xml

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

エージェント登録時に、password.xmlが次の場所に生成されます。

$DOMAIN_HOME/output/$Agent_Name/

関連項目: 付録E

password.xml

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

password.xml

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

なし

エージェント登録時に、aaa_key.pemが次の場所に生成されます。

$DOMAIN_HOME/output/$Agent_Name/

関連項目: 付録E

aaa_key.pem

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

aaa_key.pem

次の場所にコピーします。

11g Webgateの場合: 11gWebgate_instance_dir/

10g Webgateの場合: $Webgate_install_dir/

なし

セキュア・サーバー通信の共通OAMプロキシ・ページについて

表8-6は、簡易または証明書モードの構成に必要な設定を示します。

表8-6 サーバー共通のOAMプロキシ・セキュア通信の設定

モード

説明

簡易モード構成

OAMが署名したX.509証明書を使用した通信のグローバル・パスフレーズ。これは、初回のOAMサーバーのインストール時に設定されます。

管理者はこのパスフレーズを編集して、既存のすべてのOAMエージェントがそれを使用するように再構成できます。この説明は、「OAMプロキシの簡易または証明書設定の表示または編集」にあります。

証明書モード構成

外部の認証局により署名された証明書モードのX.509証明書が存在するキーKEYSTOREStoreに必要な詳細。

- PEMキーストア別名

- PEMキーストア別名パスワード

注意: これらは初回のOAMサーバーのインストール時に設定されます。証明書は、JDKに付属の証明書のインポート・ユーティリティかキーツールを使用してインポートできます。

管理者は、別名とパスワードを編集して、既存のすべてのOAMエージェントがそれを使用するように再構成できます。この説明は、「OAMプロキシの簡易または証明書設定の表示または編集」にあります。

OAMプロキシの簡易または証明書設定の表示または編集

管理者はこの手順を使用して、共通OAMプロキシの設定を確認または変更できます。

関連項目:

- 「コンソールを使用したOAMエージェントの登録および管理」

- 付録E「Oracle Access Manager 11gとの安全な通信」

OAMプロキシの簡易または証明書モード設定を表示あるいは編集する手順

1. 「システム構成」タブの「Access Managerの設定」セクションで、「Access Managerの設定」ページを開きます。

2. ページの「アクセス・プロトコル」セクションを、必要に応じて展開します。

3. 簡易モードの場合: OAMが署名したX.509証明書を使用する場合は、「グローバル・パスフレーズ」を追加または変更します。

4. 証明書モードの構成: 次の詳細を指定します。

- PEMキーストア別名

- PEMキーストア別名パスワード

5. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

6. 必要に応じてエージェント登録ページを更新してアーティファクトを再生成し、第9章または第10章の説明に従って初期のアーティファクトを置き換えます。

実行時のポリシー評価キャッシュの管理

この項では次の内容について説明します。

- 実行時のポリシー評価キャッシュについて

- 実行時のポリシー評価キャッシュの管理

関連項目:
「実行時のリソース評価について」

実行時のポリシー評価キャッシュについて

図8-4に、「Access Managerの設定」ページの「ポリシー」セクションを示します。このセクションには、「リソース一致キャッシュ」と「認可結果キャッシュ」の設定項目があり、この設定は実行時のポリシー評価に使用されます。

図8-4 共通ポリシー評価キャッシュ

「図8-4 共通ポリシー評価キャッシュ」の説明

表8-7は、すべてのサーバーおよびリクエストに適用されるこれらのグローバル設定の概要を示します。

表8-7 ポリシー評価キャッシュ

要素

説明

リソース一致キャッシュ

リクエストされたURLと、そのURLに適用されるリソース・パターンを保持するポリシー間のマッピングをキャッシュ化します。

デフォルト値:

- 最大サイズは100000で、ゼロでキャッシュが無効になります。

- 存続時間(秒) 3600。ゼロは存続時間が無効になります。

認可結果キャッシュ

リクエストされたURLおよびユーザーのポリシー決定をキャッシュ化します。

デフォルト値:

- 最大サイズは100000で、ゼロでキャッシュが無効になります。

- ユーザー当たりの最大サイズは100で、ゼロでキャッシュが無効になります。

- 存続時間(秒) 3600。ゼロは存続時間が無効になります。

関連項目: 「10gおよび11g Webgateキャッシュのチューニング」

実行時のポリシー評価キャッシュの管理

管理者はこの手順を使用して、Access Managerのポリシー評価キャッシュを管理できます。

関連項目:
「高可用性環境におけるリクエスト・キャッシュ・タイプの変更」

実行時の共通ポリシー評価キャッシュ設定を管理する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「Access Managerの設定」をダブルクリックしてページを開きます。

2. 「Access Managerの設定」ページで、「ポリシー」セクションを展開します。

3. リソース一致キャッシュ: 詳細を指定して「適用」をクリックします(表8-7)。

4. 認可結果キャッシュ: 詳細を指定して「適用」をクリックします(表8-7)。

5. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

認証モジュールの管理

Oracle Access Manager 11gでは、各認証スキームに認証モジュールが必要です。この項では、事前構成済の認証モジュールと、管理者がカスタム・モジュールを定義する方法について説明します。内容は次のとおりです。

- デフォルト認証モジュールおよびページについて

- 既存のタイプの新しい認証モジュールの作成

- 認証モジュールの表示または編集

- 認証モジュールの削除

デフォルト認証モジュールおよびページについて

Oracle Access Managerコンソールでは、「システム構成」タブで事前構成済認証モジュールが他のシステムレベル・コンポーネントとともに編成されます。

次の事前構成済認証モジュール・タイプのみが認証スキームで許可されます。ただし、既存のタイプの新しいモジュールを作成して認証スキームで使用できます。詳細は、次を参照してください。

- Kerberos認証モジュール

- LDAP認証モジュール

- X509認証モジュール

関連項目:

- 「カスタム認証モジュールのプラグインについて」

- 「チャレンジ・メソッドについて」

- 「認証モジュールについて」

- カスタム認証モジュールとプラグインの詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』

Kerberos認証モジュール

事前構成済Kerberos認証モジュールを図8-5に示します。詳細は、図の後に説明します。

図8-5 事前構成済Kerberos認証モジュール

「図8-5 事前構成済Kerberos認証モジュール」の説明

表8-8は、Kerberos認証モジュールの定義を示しています。既存の事前構成済Kerberos認証モジュールを使用するか、独自のモジュールを作成できます。

表8-8 Kerberos認証モジュールの定義

要素

説明

名前

大文字および小文字の英字、数値および空白を使用できるこのモジュールの一意のID。

キー・タブ・ファイル

キー配布センター(KDC)の認証に必要となる、ホストのキーの暗号化されたローカルのディスク上のコピーへのパス。たとえば、/etc/krb5.keytabなどです。

KDCは、リクエストしているユーザーを認証し、ユーザーにリクエストされたサービスのアクセスが認可されていることを確認します。認証されたユーザーがすべての所定の条件を満たしている場合、KDCはサーバー・キーに基づくアクセスを許可するチケットを発行します。クライアントはチケットを受け取り、適切なサーバーに送信します。サーバーは、送信されたチケットを確認し、送信したユーザーにアクセス権を付与できます。

キー・タブ・ファイルは、rootによってのみ読取り可能であること、およびマシンのローカル・ディスク上に存在することが必要です。バックアップ・データへのアクセスが、マシンのrootパスワード自体へのアクセスと同じくらい厳密に保護されていないかぎり、バックアップの一部にはできません。

プリンシパル

ホストのキータブの生成を有効化するKerberosデータベースのプリンシパルのHTTPホストを識別します。

KRB構成ファイル

Kerberosインストールの特定の側面を制御する構成ファイルのパスを識別します。krb5.confファイルは、Kerberosを実行している各UNIXコードの/etcディレクトリに存在する必要があります。

krb5.confには、Kerberos V5ライブラリに必要な構成情報が含まれます(デフォルトのKerberosレルムおよび既知のレルムのKerberosキー配布センターの場所)。

LDAP認証モジュール

事前構成済LDAP認証モジュールを図8-5に示します。詳細は、図の後に説明します。

図8-6 事前構成済LDAP認証モジュール

「図8-6 事前構成済LDAP認証モジュール」の説明

表8-9は、LDAP認証モジュールの要素を示しています。同じ要素と値がLDAPNoPasswordAuthnModuleでも使用されます。

表8-9 LDAP認証モジュールの定義

要素

説明

名前

このモジュールの一意の名前。

ユーザー・アイデンティティ・ストア

このモジュールの認証に必要なユーザー資格証明を含むプライマリ・ユーザー・アイデンティティ・ストア。LDAPストアをOAM 11gに登録して、このリストに表示する必要があります。

関連項目: 「ユーザー・アイデンティティ・ストアの管理」

インストール時には、ユーザー・アイデンティティ・ストアは1つのみで、それがシステム・ストアでもあります。アイデンティティ・ストアを追加し、別のストアをシステム・ストアとして指定する場合には、必ずそのシステム・ストアを参照するようにLDAPモジュールを変更してください。OAMAdminConsoleScheme (認証スキーム)は、管理者ロールと資格証明をLDAPモジュールに依存します。変更する場合:

関連項目: 「デフォルト・ストアおよびシステム・ストアの設定」

X509認証モジュール

Oracle Access Managerは、デフォルトとして事前定義済X509認証モジュールを用意しています。管理者は、新しいX509認証モジュールも作成できます。暗号化の表現のX.509は、シングル・サインオン(SSO)に使用されるデジタル公開鍵証明書の標準です。X.509では、特に公開鍵証明書、証明書失効リストおよび属性証明書の標準形式を指定します。

X.509デジタル証明書を使用すると、証明書を発行する認証局(CA)の厳密な階層システムを取得できます。X.509システムで、CAは、特定の識別名または電子メール・アドレスやDNSエントリなどの代替名に公開鍵をバインドする証明書を発行します。

企業のPKIシステムで使用できるように、企業の信頼されたルート証明書をすべての従業員に配布できます。SSL証明書をすぐに使用できるように、特定のWebブラウザは、事前インストールされたルート証明書を用意しています。

Oracle Access Managerは、オンライン証明書ステータス・プロトコル(OCSP)インターネット・プロトコルを使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーおよびそのステータスを通知されるクライアント・アプリケーション間で使用される通信構文を指定します。

ユーザーがサーバーにアクセスしようとすると、OCSPによって証明書ステータス情報に対するリクエストが送信されます。OCSPは、特定のネットワーク・ホストが特定の時間に特定の証明書を使用していたことをリクエスタに公開します。サーバーは、現在、期限切れまたは不明のレスポンスを戻します。OCSPは、期限が切れた証明書を使用するユーザーに更新前の指定された期間にサーバーにアクセスできる構成可能な猶予期間を与えます。

OCSPメッセージはASN.1で暗号化され、HTTPで一般的に転送されます。OCSPのリクエストおよびレスポンス特性では、OCSPサーバーを参照する場合に「OCSP応答者」という用語を使用します。Oracle Access Managerを使用する場合、Oracle Access ManagerコンソールをホストするコンピュータはOCSP応答者です。

OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。

図8-7 事前構成済X509認証モジュール

「図8-7 事前構成済X509認証モジュール」の説明

表8-10は、X509認証モジュールの要件を示しています。

表8-10 X509認証モジュールの定義

要素

説明

名前

一意の名前でこのモジュール定義を識別します。

一致するLDAP属性

特定の「X509証明書属性」値に対して検索されるLDAP識別名属性を定義します。

たとえば、証明書のサブジェクトEMAILがxyz@abc.comで、それがLDAP属性の"mail"に一致する必要がある場合、LDAP問合せは、xyz@abc.com (cn)という値を持つ"mail"属性をLDAPから検索する必要があります。

X509証明書属性

公開鍵のバインドに使用される証明書属性を定義します(サブジェクト内の属性、証明書から抽出される発行者スコープ。たとえば、subject.DN、issuer.DN、subject.EMAIL)。

証明書検証有効

X.509証明書の検証を有効化(選択されていない場合は無効化)します。

OCSP有効

オンライン証明書ステータス・プロトコルを有効化(選択されていない場合は無効化)します。

注意: 「OCSP有効」を選択した場合のみ、OCSPサーバー別名、OCSP応答者URLおよびOCSP応答者タイムアウトが必要です。

OCSPサーバー別名

.oamkeystoreファイルのCA証明書を指すOSCSP応答者の別名--別名およびOSCSP応答者インスタンスの実際のインスタンス名またはIPアドレスのマッピング。

OCSP応答者URL

オンライン証明書ステータス・プロトコル応答者のURLを入力します。

OCSP応答者タイムアウト

証明書の更新前の限定された期間にOAMサーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。

既存のタイプの新しい認証モジュールの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存のタイプの新しい認証モジュールを作成できます。テンプレートとして使用する事前構成済モジュールは複製できません。

注意:
認証モジュールは、アクセス・ポリシーにおける認証スキームのコア・コンポーネントです。各認証モジュールが、適切なアイデンティティ・ストアを参照するようにしてください。
システム・ストアを変更する場合、新しく指定したシステム・ストアを参照するようにLDAP認証モジュールも変更する必要があります。

前提条件

デフォルト認証モジュールおよびページについて

関連項目:
カスタム・プラグイン用の認証モジュールを作成する場合は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』

既存のタイプの新しい認証モジュールを作成する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「認証モジュール」ノードを展開します。

2. 「認証モジュール」ノードで目的のモジュール・タイプをクリックします。

- LDAP認証モジュール

- Kerberos認証モジュール

- X509認証モジュール

3. ツール・バーの「作成」ボタンをクリックします。

4. 新しい認証モジュールの詳細を追加します。

- LDAP: 表8-9を参照してください。

- Kerberos: 表8-8を参照してください。

- X509: 表8-10と表8-13を参照してください。

5. 「適用」をクリックして新しい定義を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

6. ナビゲーション・ツリーでエントリを確認し、終了する場合はページを閉じます。

7. 「認証スキームの管理」の手順に従って、認証モジュールを1つ以上の認証スキームに追加します。

認証モジュールの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証モジュールを変更できます。これには、既存のモジュール名の変更および他の属性の変更が含まれます。

前提条件

別の認証モジュールを使用するには、変更されるモジュールを参照する各認証スキームを変更します。

関連項目:
デフォルト認証モジュールおよびページについて

認証モジュールを検索、表示または編集する手順

1. このモジュールを参照する各認証スキームの別の認証モジュールに変更します。

2. 「システム構成」タブの「Access Managerの設定」セクションから、次のノードを展開します。

1. 「認証モジュール」ノード

2. モジュール・タイプ・ノードを拡張します。

3. 目的のモジュール名をダブルクリックして、構成を表示します。

4. オプション: 表示の確認のみであれば、ページを閉じます。

5. 認証モジュール・ページで、必要に応じて情報を変更します。

- Kerberosモジュール: 表8-8を参照してください。

- LDAPモジュール: 表8-9を参照してください。

- X509モジュール: 表8-10と表8-13を参照してください。

6. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

7. 「認証スキームの管理」の手順に従って、更新された認証モジュールを認証スキームに追加します。

認証モジュールの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証モジュールを削除できます。

次の手順は、カスタム認証モジュールと標準認証モジュールのどちらを削除する場合でも同じです。

前提条件

削除するモジュールを参照している各認証スキームで、別の認証モジュールを指定します。

認証モジュールを削除するには、次の手順を実行します。

1. このモジュールを参照する各認証スキームでは、別の認証モジュールを指定します。

2. 「システム構成」タブの「Access Managerの設定」セクションから、次のノードを展開します。

1. 「認証モジュール」ノード

2. モジュール・タイプ・ノードを拡張します。

3. オプション: モジュール名をダブルクリックして構成を表示し、ウィンドウを閉じます。

4. 目的のモジュール名をクリックし、「削除」ボタンをクリックします。

5. 削除を確認します(またはモジュールを保持する確認ウィンドウを閉じます)。

カスタム認証モジュールの作成

ここでは、次の内容について説明します。

- カスタム認証モジュールの作成について

- カスタム認証モジュールのプラグインについて

- カスタム認証モジュールの作成

カスタム認証モジュールの作成について

各カスタム認証モジュールには、次のタイプの情報が必要です。

- 一般

- ステップ

- ステップ編成

図8-8に、「システム構成」ツリーの「Access Managerの設定」にある「カスタム認証モジュール」を示します。モジュールの情報を入力する3つのサブタブも表示されています。

図8-8 「カスタム認証モジュール」ノードと「一般」サブタブ

「図8-8 「カスタム認証モジュール」ノードと「一般」サブタブ」の説明

「一般」サブタブには、モジュールの「名前」と説明(オプション)のためのフィールドがあります。名前は、最大60文字で指定できます。オプションの説明は250文字までです。

新規のステップを追加するときには、次のダイアログ・ボックスが表示されます。ここで入力する情報を使用して、表と、ページの「詳細」セクションにデータが移入されます。

図8-9 ステップの追加とプラグインの関連付け

「図8-9 ステップの追加とプラグインの関連付け」の説明

表8-11では、新規ステップの追加に必要な情報について説明します。

表8-11 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション

要素

説明

ステップ名

ステップを追加するときに入力する一意の名前。

説明

ステップを追加するときにオプションで入力する、このステップの説明。

プラグイン名

ステップを追加するときに選択するプラグイン名。

ステップの詳細

結果表で選択したステップの詳細と、プラグインを追加するときに設定されるプラグインの構成詳細。次で説明されているとおり、選択するプラグインによって異なります。

図8-10は、カスタム認証モジュールの「ステップ」サブタブと「詳細」セクションを示しています。ステップを追加するとき、表に表示されるデータはありません。1つ以上のステップを追加すると、表と「詳細」セクションにデータが移入されます。

図8-10 「カスタム認証モジュール」の「ステップ」サブタブと「詳細」セクション

「図8-10 「カスタム認証モジュール」の「ステップ」サブタブと「詳細」セクション」の説明

図8-11は、カスタム認証モジュールの「ステップ編成」サブタブを示しています。このサブタブには、定義された各ステップ(および各操作条件に対して選択したアクション)の情報が移入されます。

図8-11 「カスタム認証モジュール」の「ステップ編成」サブタブ

「図8-11 「カスタム認証モジュール」の「ステップ編成」サブタブ」の説明

表8-12では、「ステップ編成」サブタブの要素について説明します。OnSuccess、OnFailure、OnErrorで選択できるリストの項目は次のとおりです。

- success

- failure

- StepName (モジュールの任意のモジュールを、操作条件のアクションとして選択できます)

表8-12 「ステップ編成」サブタブ

要素

説明

初期手順

リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。

名前

追加された各ステップが、追加するときに入力した名前別にリストされます。

説明

ステップを追加するときにオプションで入力した、このステップの説明。

OnSuccess

このステップの操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。

- success

- failure

- StepName

OnFailure

このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。

- success

- failure

- StepName

OnError

このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。

- success

- failure

- StepName

カスタム認証モジュールのプラグインについて

Oracle Access Manager 11gには、独自のカスタム認証モジュールを作成し、認証スキームに割り当てることができるマルチステップの認証モジュールにそれを編成するときに使用できるカスタム認証モジュール・プラグインが、いくつか用意されています。各モジュールは、独立したユーザー・アイデンティティ・ストアを参照できます。

- KerberosPlugin

- LDAPPlugin

- X509Plugin

KerberosPlugin

図8-12は、Oracle Access Manager 11gにバンドルされているKerberosPluginを示しています。これはリソースを暗号化された「チケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。

図8-12 KerberosPlugin

「図8-12 KerberosPlugin」の説明

図8-13は、デフォルトのステップと詳細を示しています。図8-14は、ステップの編成と条件を示しています。

図8-13 デフォルトのKerberosPluginステップと詳細

「図8-13 デフォルトのKerberosPluginステップと詳細」の説明

図8-14 デフォルトのKerberosPluginステップと編成

「図8-14 デフォルトのKerberosPluginステップと編成」の説明

LDAPPlugin

図8-15は、Oracle Access Manager 11gにバンドルされているLDAPPluginを示しています。デフォルトでは、図8-16のようにLDAPPluginには2つのステップがあります。図8-17は、LDAPpluginのステップのデフォルト編成を示しています。

図8-15 LDAPPlugin

「図8-15 LDAPPlugin」の説明

図8-16 デフォルトのLDAPPluginステップと詳細

「図8-16 デフォルトのLDAPPluginステップと詳細」の説明

図8-17 LDAPpluginのステップのデフォルト編成

「図8-17 LDAPpluginのステップのデフォルト編成」の説明

X509Plugin

図8-18は、Oracle Access Manager 11gにバンドルされているX509Pluginを示しています。X509PluginはLDAPPluginと似ていますが、LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示すプロパティが追加されています。図8-19は、このプラグインのデフォルトのステップと詳細を示しています。図8-20は、X509Pluginのステップのデフォルト編成を示しています。

図8-18 X509Plugin

「図8-18 X509Plugin」の説明

図8-19 X509Pluginのデフォルト・ステップと詳細

「図8-19 X509Pluginのデフォルト・ステップと詳細」の説明

表8-13に、X509のサブジェクトの「ステップの詳細」値と代替名をリストします。

表8-13 X509の「ステップの詳細」: 証明書から抽出する属性

issuer.D

サブジェクト

subject.

EDIPI

注意: EDIPIはElectronic Data Interchange Personal Identifierの略です。

subjectAltName.

OTHER_NAME (FASC-N)

注意: FASC-NはFederal Agency Smart Credential Numberの略です。

subjectAltName.

RFC822_NAME

subjectAltName.

UNIFORM_RESOURCE_IDENTIFIER

図8-20 X509Pluginのステップのデフォルト編成

「図8-20 X509Pluginのステップのデフォルト編成」の説明

例: OCSPを使用したユーザー証明書の検証

この例では、オンライン証明書ステータス・プロトコル(OCSP)としてOpenSSLを使用してユーザー証明書を検証する方法を説明します。

1. 「既存のタイプの新しい認証モジュールの作成」の説明に従って、新規のX509認証モジュールを作成します。

2. 次のように、カスタムのX509プラグインを作成します(「カスタム認証モジュールの作成」も参照)。
「システム構成」、「Access Managerの設定」、「カスタム認証モジュール」

「一般」タブ:

1. 名前: CustomX509Plugin。

2. 説明: X509のプラグイン。

「ステップ」タブ:

1. 「+」をクリックしてプラグインを追加します。

2. 「名前」、「説明」を設定し、「X509CredentialExtractor」プラグインを選択します。

ステップの詳細:

1. 「+」をクリックしてプラグインを追加し、「名前」、「説明」を設定して「X509CredentialExtractor」プラグインを選択します。

2. 「X509CredentialExtractor」プラグイン: KEY_IS_CERT_VALIDATION_ENABLEDを"true"に設定します。

3. この属性で抽出される証明書属性KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT(デフォルトでは、この値はsubject.CNに設定されます)。表8-13を参照してください。

4. 「Save」ボタンをクリックします。

プラグインの追加:

1. 「+」をクリックしてプラグインを追加します。

2. 「名前」、「説明」を設定し、「X509CredentialExtractor」プラグインを選択します。

ステップの詳細:

1. ステップの詳細: KEY_IDENTITY_STORE_REFは、必要なアイデンティティ・ストアに設定する必要があります。

2. KEY_LDAP_FILTER属性にLDAPフィルタを追加します。次に例を示します。

(&(uid=
Unknown macro: {subject.CN}
)(mail=
Unknown macro: {subject.E}
))

3. 必要な場合は、KEY_SEARCH_BASE_URL属性にユーザー検索ベースを追加します。

4. 「Save」ボタンをクリックします。

ステップ編成:

1. 最初のステップ: ドロップダウンから「X509CredentialPlugin」ステップを選択します。

2. 成功時: 「X509CredentialPlugin」ステップで、ドロップから「UserIdentificationPlugin」ステップを選択します。

3. 成功時: 「UserIdentificationPlugin」ステップで、ドロップダウンからsuccessステップを選択します。

4. 失敗時: 「X509CredentialPlugin」と「UserIdentificationPlugin」のステップでfailureを選択します。

5. エラー発生時: 「X509CredentialPlugin」と「UserIdentificationPlugin」のステップでfailureを選択します。

6. 「適用」ボタンをクリックし、プラグインが正常に作成されたことを示す確認ウィンドウを確認します。

3. OCSPを使用して、「証明書検証」と「証明書失効」に証明書検証モジュールを設定します。

関連項目:
「グローバル証明書の検証および取消の管理」

1. Oracle Access Managerコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効」リスト・セクションで、「有効」ボックスが選択されていることを確認し、「保存」をクリックします。

3. 「OCSP/CDP」セクションでOCSPを有効にし、OCSPのURLと、OCSPサーバーの証明書のサブジェクトを入力し、「保存」をクリックします。

4. コマンドラインでJavaのkeytoolアプリケーションを使用し、信頼できる証明書のエントリとして$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアに信頼できる証明書をインポートします。

注意:
初期状態ではキーストアは空です。パスワードは、Java keytoolアプリケーションを最初に使用するときに設定されます。

カスタム認証モジュールの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、1つ以上の認証プラグインを使用するカスタム認証モジュールを作成できます。

前提条件

モジュールに関連付けられているユーザー・アイデンティティ・ストアが実行中であり、必要なユーザー移入が含まれていることを確認します。

関連項目:
「例: OCSPを使用したユーザー証明書の検証」

バンドルされているプラグインを使用してカスタム認証モジュールを作成する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「認証モジュール」ノードを展開します。

2. 新規作成:

1. 「カスタム認証モジュール」ノードをクリックします。

2. 「作成」(+)ボタンをクリックします。

3. 一般的な情報の追加: 「名前」と、オプションの「説明」。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。
「適用」をクリックして一般情報を保存します。

3. ステップの追加:

1. 「ステップ」サブタブをクリックします。

2. 「ステップ」表の上にある「追加」(+)ボタンをクリックします。

3. 「新規ステップの追加」ダイアログ・ボックスで、一意の「ステップ名」と、オプションで「説明」を入力します。

4. 目的のプラグイン名を参照して選択し、「OK」をクリックします。

5. 結果表の情報を確認します。

6. モジュールに必要なすべてのプラグインがリストされるまで、bからeを繰り返して他のステップを追加します。

4. 各ステップの「詳細」の構成: 必要なパラメータに適切な値を使用します(表8-11と表8-13)。

1. 表でステップ名をクリックすると、必要な詳細が表示されます。

2. 必要な詳細に適切な値を入力します。

3. 「Save」ボタンをクリックします。

4. aからdを繰り返し、各ステップを適切に構成します。

5. ステップで割り当てるユーザー・アイデンティティ・ストアに、ユーザーがプロビジョニングされていることを確認します。

5. ステップの編成: 表8-12を参照して、次の手順を実行します。

1. 「ステップ編成」サブタブをクリックします。

2. 「最初のステップ」リストで、使用する最初のステップの名前を選択します。

3. 表でステップ名を選択します。

4. 「OnSuccess」リストから、条件(successまたはfailure)またはステップ名を選択します。

5. 「OnFailure」リストから必要な条件またはステップ名を選択します。

6. 「OnError」リストから必要な条件またはステップ名を選択します。

7. cからeを繰り返し、このモジュールの各プラグインの操作を編成します。

8. 編成を確認します。

6. 方針の検証の開始: 「適用」をクリックして、編成方針の検証を開始します。

- 方針が正常な場合: 編成方針が適用され、認証スキームにモジュールを追加できるようになります。ステップ9と10を続行します。

- 方針が無効な場合: 「エラー」ボックスで「OK」をクリックし、OnSuccess、OnFailure、OnErrorの方針を編集(プラグインを追加または削除)して問題を修正します。方針が成功するまでこの手順を繰り返します。

7. ナビゲーション・ツリーで新しいカスタム認証モジュールがリストされていることを確認し、終わったらページを閉じます。

8. これで、認証スキームでカスタム・モジュールを使用する準備ができました。

9 コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録

登録されたポリシー強制エージェントのみが、OAM 11gの認証および認可サービスと通信できます。管理者は、保護するパートナ・アプリケーションをホスティングするコンピュータに存在するエージェントを登録する必要があります。パートナ・アプリケーションとは、認証機能をSSOプロバイダ(Oracle Access Manager 11g)に委任して、複数のリソースにアクセスする際にユーザーが再度認証しなくて済むようにするものです。

この章では、Oracle Access Managerコンソールを使用したエージェント登録および管理の実行を中心に説明します。この章には次のトピックが含まれます。

- 前提条件

- ポリシーの強制エージェントの概要

- コンソールを使用したOAMエージェントの登録および管理

- 10gおよび11g Webgateキャッシュのチューニング

- コンソールを使用したOSSOエージェントの登録および管理

注意:
コマンドラインを使用してパートナを登録するには、第10章を参照してください。

前提条件

この章のタスクを実行する前に、Oracle Access Managerコンソールと管理対象OAMサーバーが実行中であることを確認してください。

この章にあるタスクのナレッジ・ベースの要件は、次のとおりです。

- 「ポリシーの強制エージェントの概要」を見直してください。

- OAM 10g Webgateを登録する場合は、第27章「OAM 10g WebgateとOAM 11gの管理」を確認してください。

ポリシーの強制エージェントの概要

この項では、アクセス・クライアント(ポリシー強制エージェント)と、エージェントとOracle Access Manager 11g SSO間の信頼メカニズムを設定するために必要な登録プロセスの情報を提供します。

- ポリシーの強制エージェントについて

- 事前登録されたIAMSuiteAgentについて

- パートナ(エージェントおよびアプリケーション)の登録について

- ファイル・システム変更および登録されたエージェントのアーティファクトについて

ポリシーの強制エージェントについて

Oracle Access Manager 11gでは、それぞれのポリシー強制エージェントはHTTPリクエストのフィルタとして機能します。デプロイメントには次のエージェントを任意の組合せで含めることができます。

- OAMエージェント:

- OAM 11G Webgate

- OAM 10G Webgate

- プログラム・アクセス・クライアント

- OSSOエージェント: mod_ossoは、中央のOSSOサーバーでユーザーを認証する(引き続き)OracleAS 10gシングル・サインオン(OSSO)ソリューションの一部です。
10g mod_ossoをエージェントとして登録した後、OAM 11gはリソースに定義されたOAMポリシーに関連付けられた認証スキームに基づいて、mod_ossoにユーザーのためのリダイレクトURLを渡します。

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

特に明記しないかぎり、OAMエージェントの詳細はWebgateとアクセス・クライアントに同様に適用されます。

- Webgateは設定不要のアクセス・クライアントです。このWebサーバーのアクセス・クライアントは、WebリソースのHTTPリクエストを捕捉して、これらをOAM 11gサーバーに転送します。様々なWebサーバーのWebgateは、Oracle Access Managerに同梱されています。

- 非Webアプリケーションと併用するように作成されるカスタム・アクセス・クライアントは、別途ソフトウェア開発キット(SDK)を使用して、ユーザーまたはオラクル社が開発する必要があります。アクセス・クライアントは、ユーザーやアプリケーションからのWebおよびWeb以外(非HTTP)のリソースに対するリクエストを処理します。

表9-1は、OAM 11gのすべてのエージェントに関する情報を示します。

表9-1 OAM 11gのエージェント

エージェント

説明

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

OAM 11gに登録された後、mod_ossoモジュールは次の処理を行います。

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

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

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

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

11g Webgate

OAM 11gへのインストールと登録が終わった後、11g WebgateはOAMプロキシを使用してOracle Access Manager 11gサービスと通信し、リクエストを"掃除"して、すべてのエージェントに同じように応答します。

11gアクセス・クライアント(OAM 11g Access SDKで作成されたもの)も登録できます。

10g Webgate

インストールおよび登録の後、OAM 10g Webgateはブリッジとして機能するJavaベースのOAMプロキシを通じてOracle Access Manager 11gサービスと直接通信します。OAM 10G Webgateには、次のものが含まれます。

- OAM 11gに新しくインストールされた10g Webgate。第27章で説明されているとおり、Oracle HTTP Server以外のWebサーバーをサポートできます。

- 現在OAM 10gとともに動作し、OSSOと組み合せられているレガシー10g Webgate。詳細は10g Oracle Access Manager統合ガイドに記載されています。

- SSO用のアイデンティティ・アサーション・プロバイダ(IAP)として構成されているレガシー10g Webgate (OAM 10gとともにWebLogicコンテナベースのセキュリティを使用するアプリケーション用。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照)。

- Oracle ADFセキュリティとOPSS SSOフレームワーク用にコードが記述されたWebアプリケーションと現在ともに動作しているレガシー10g Webgate。詳細は付録Cに記載されています。

- レガシー10g Java AccessGates。

この表の「IAMSuiteAgent」も参照してください。

アクセス・クライアント

認証と認可のみがアクセス・クライアント用です(ポリシー変更は対象外です)。

IAMSuiteAgent

IAMスイート・エージェントは、IAMコンソール・スイートにシングル・サインオン機能を提供します。IAMスイート・エージェントとその付属アプリケーション・ドメイン(IAMSuite)は、以前のIDMドメイン・エージェントとその付属アプリケーション・ドメインにかわるものです。

関連項目: 「事前登録されたIAMSuiteAgentについて」

表9-2は、OAM 11gと互換性のあるエージェント・タイプの比較、およびOAM 11gと以前のエージェントとの違いを説明しています(列ごとに記載)。

関連項目:

- 第11章: SSOとCookieの詳細

表9-2 エージェント・タイプの比較および違い

OAM 11g

OAM 10g

OSSO 10g

使用可能なSSOエージェント

OAMエージェント

- 11g Webgate

- 10g Webgate

- IAMSuiteAgent

- プログラム・アクセス・クライアント

OSSOエージェント

- 10g mod_osso(パートナ)

Webgateとアクセス・ゲート

- リソースWebgate (RWG)

- 認証Webgate (AWG)

OAM 10gの場合、WebgateのインストールにはWebサーバーの構成が含まれていました。

- mod_osso

リモート登録ツール

oamregツールを使用して、OAM 11gにOAM 10gおよび11gのエージェントを登録します。

<OAM_HOME>/oam/server/rreg/ client/rreg/bin/oamreg

OAM 10gに該当するものはありません。

oamregツールを使用して、OAM 11gにOSSOエージェントを登録します。

注意: OAM 11g以前はリモート登録に該当するものはありませんでした。

ログイン・フォーム

/oam/pages/css/login_page.css

10g Webgateで同梱され使用されたログイン・フォームは、OAM 11gには適していません。

変更なし

logout.html

10gおよび11gのエージェントのログアウトの構成の詳細は、第15章を参照してください。

10g WebgateとOAM 11gを併用する場合、logout.htmlでは特定の詳細が必要です。第15章を参照してください。

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

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

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

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

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

OAMには、Oracle Identity Federationより前から存在する独自の複数ネットワーク・ドメインSSO機能があります。これがOAM 10gデプロイメントに実装されている場合、OAM 10gエージェントをOAM 11gに登録すればこのサポートを引き続き受けられます。

暗号化キー

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

- 11g WebgateとOAMサーバー間で共有されるエージェントごとの秘密鍵1つ

- 1つのOAMサーバー・キー

注意: 登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成され、使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

OAMデプロイメントごとにグローバルで共有される秘密鍵が1つあり、これがすべてのWebgateで使用されます。

- mod_ossoとOSSOサーバー間で共有されるパートナごとに1つのキー

- OSSOサーバー自身のキー

- GITOドメインcookieに設定されたOSSOごとにグローバル・キー1つ

キー・ストレージ

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

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

ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可)

- mod_osso側: 曖昧な構成ファイルにローカルで格納されるパートナ・キーおよびGITOグローバル・キー

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

管理者はOracle Access Managerコンソールまたはリモート登録ツールを使用して、次のことを実行できます。

- 新しくインストールされたOAM 11g Webgateの登録

- OAM 11gと使用するためのレガシー(または新しくインストールされた)OAM 10 Webgateのプロビジョニング。詳細は第27章に記載されています。

- OSSO 10gエージェント(mod_osso)の登録

- 注意:
『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』の説明のとおりに、OracleAS 10g SSOをアップグレードできます。アップグレード中に、OSSOエージェントがOAM 11gに登録されます。付録A「共存の概要: OAM 11gとOSSO 10g」を参照してください。

事前登録されたIAMSuiteAgentについて

このエージェントと、付属アプリケーション・ドメイン(第13章を参照)は、パッチ・セット・リリースで使用できます。これらの定義は変更しないことをお薦めします。

注意:
従来のIDMDomainAgentは、このパッチ・セットでは利用できません。パッチ・セットの適用後は、アーティファクトとして残ります。ただし、内容はすべて削除されます。

IAMSuiteAgentは、IDM管理コンソールにシングル・サインオン機能を提供します。IAMSuiteAgentは、Oracle Access Manager 11g Serverのインストールと構成の一部としてインストールされ、事前構成されています。

IAMSuiteAgentは、ドメイン全体のエージェントです。

- 一度デプロイされると、IAMSuiteAgentはドメイン内のすべてのサーバーにインストールされます。

- 無効にしないかぎり、WebLogicアプリケーション・サーバーに入ってくるすべてのリクエストは、IAMSuiteAgentによって評価および処理されます。

- 構成の詳細は、Oracle Access Managerコンソールの「10g Webゲート」ノード(「ポリシー構成」タブ)の下にあります。

特定のIAMSuiteAgent構成の要素はWebLogic管理コンソール(「セキュリティ・プロバイダ」セクション)に、その他の要素はOracle Access Managerコンソールにあります。

WebLogic管理コンソール、「セキュリティ・プロバイダ」の設定

WebLogic管理コンソールの「セキュリティ・プロバイダ」セクションには、ブートストラップ構成パラメータが5つあります。

これらは変更せずに保持することをお薦めしますが、次のパラメータのいずれかを変更することが必要な場合があります。

- プライマリOAMサーバー: この値は、実際のOAMサーバーの情報で置き換えることができます。複数のホストがIDMドメインの一部である場合は、デフォルト値(localhost:5575)を実際のOAMサーバーの情報で置き換えます。エージェント・パスワード: デフォルトでは、パスワードはありません。ただし、NetPoint (現在はOracle) Access Protocol (NAPまたはOAP)を介してOAMサーバーにIAMSuiteAgent接続するときのパスワードを確立する場合には、ここで追加できます。

図9-1は、IAMSuiteAgentのデフォルトの「セキュリティ・プロバイダ」の設定を示します。

図9-1 WebLogic管理コンソールでのIAMSuiteAgent構成

「図9-1 WebLogic管理コンソールでのIAMSuiteAgent構成」の説明

Oracle Access Managerコンソール、IAMSuiteAgentの登録

IAMSuiteAgentの登録ページには、他のOAMエージェント登録ページと同様、エージェントに関する詳細が表示されます。

- セキュリティ・モード: IAMSuiteAgentで使用できるセキュリティ・モードは「オープン」のみです。これは変更できません。

- 優先ホスト: IAMSuiteAgentはあらかじめ構成されたホストで、このエージェントで必要です。

注意:
ここのアクセス・クライアント・パスワードは、WebLogic管理コンソールのエージェント・パスワードと一致する必要があります。エージェント・パスワードを変更した場合、アクセス・クライアント・パスワードも変更する必要があります。

図9-2に、「IAMSuiteAgent」ページを示します。「ユーザー定義パラメータ」は、WebLogicサーバーのコンテナ・ポリシーにフォール・バックする動作を通知し、ログアウトのためのリダイレクトURLを提供します。

図9-2 IAMSuiteAgentの特性

「図9-2 IAMSuiteAgentの特性」の説明

表9-3は、IAMSuiteAgent、11g Webgate、10g Webgateの3つの違いを示しています。すべての要素は、表9-5「展開されたOAM 11gおよび10g Webgateエージェントの要素とデフォルト」に記載されています。

表9-3 IAMSuiteAgent、11g Webgate、10g Webgateの比較

要素

11g Webgate

10g Webgate

IAMSuiteAgent

プライマリCookieドメイン

なし

×

×

トークンの有効期間

×

なし

なし

優先ホスト

×

×

×

ログアウトURL

×

×

×

ログアウト・コールバックURL

×

なし

なし

ログアウト・リダイレクトURL

×

なし

なし

ログアウト・ターゲットURL

×

なし

なし

キャッシュ・プラグマ・ヘッダー

キャッシュ制御ヘッダー

×

×

×

×

×

×

ユーザー定義パラメータ

proxySSLHeaderVar=IS_SSL
URLInUTF8Format=true
client_request_retry_attempts=1
inactiveReconfigPeriod=10

proxySSLHeaderVar=IS_SSL
URLInUTF8Format=true

client_request_retry_attempts=1
inactiveReconfigPeriod=10

fallbackToContainerPolicy=true
logoutRedirectUrl=http://hostname.domain.com:14100/oam/server/logout
protectWebXmlSecuredPagesOnly=true

保護されていない場合に拒否

×

×

×

図9-3は、IAMSuiteAgentによって保護されるリソースと、正確な認証ポリシーおよび認可ポリシーを示しています。追加や変更は一切行わないことをお薦めします。WebLogic管理コンソール(/console)は保護されています。

図9-3 IAMSuiteAgentによって保護されるリソース

「図9-3 IAMSuiteAgentによって保護されるリソース」の説明

第27章「OAM 10g WebgateとOAM 11gの管理」で説明されているとおり、このエージェントは10g Webgateに置換できます。

パートナ(エージェントおよびアプリケーション)の登録について

登録されたポリシー強制エージェントのみがOAMサーバーと通信でき、保護されたリソースにユーザーがアクセスを試みるときに情報を処理します。

管理者は、保護するアプリケーションをホスティングするコンピュータに存在するOAMエージェントまたはOSSOエージェントを登録する必要があります。アプリケーション・ドメインとデフォルトのポリシーを自動的に作成することで、エージェントの登録にパートナの登録を含めることができます。

登録の後、エージェントの詳細がOracle Access Managerコンソールに表示され、クラスタ内のすべての管理対象サーバーに伝播されます。エージェント登録時にポリシーを自動作成するよう選択した場合、パートナ・アプリケーションに登録されたアプリケーション・ドメインとポリシーを表示、管理することもできます。

注意:
エージェントの登録は、「パートナ・アプリケーションの登録」または「パートナ・アプリケーションのOAMへの登録」ともいいます。

登録時に、エージェントは自身が保護するアプリケーションと同じWebサーバー上にあると想定されます。ただし、エージェントがプロキシWebサーバー上にあったり、アプリケーションが異なるホスト上にあることも可能です。

エージェント登録時:

- エージェントごとに1つのキーが生成され、クライアント・ホスト上のローカル・ウォレット・ファイルを介してWebgateから、サーバー側ではJavaキーストアを介してOAMサーバーからそれぞれアクセス可能になります。
エージェント固有のキーは、クライアント・マシン上の保護されたローカル・ストレージを介してWebgateからアクセス可能であることが必要です。表9-2を参照してください。

- キーは、登録時にパートナ(アプリケーション)に対して生成されます。(10g Webgateを除きます)。

- OAMアプリケーション・ドメインが作成されて、エージェントにちなんだ名称が付けられ、デフォルトの認証および認可ポリシーが移入されます。新しいアプリケーション・ドメインは、登録中にエージェントに対して指定されたものと同じホスト識別子を使用します。アプリケーション・ドメインの詳細は、第13章を参照してください。

登録の後、エージェントはWebサイトにアクセスする試みをモニターし、リクエストを完了する前にOAMサーバーを使用して認証および認可サービスを提供できます。管理者は、Oracle Access ManagerコンソールまたはカスタムのOAM 11g用WLSTコマンドを使用して、登録されたエージェントの表示、変更および削除が可能です。

詳細は、次を参照してください。

- コンソールを使用したOAMエージェントの登録および管理

- コンソールを使用したOSSOエージェントの登録および管理

関連項目:

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

- 第27章「OAM 11gによるOAM 10g Webgateの管理」

- 付録F「管理者用カスタムWLSTコマンドの概要」

ファイル・システム変更および登録されたエージェントのアーティファクトについて

Oracle Access Managerコンソールを使用してエージェントを登録すると、Oracle Access Managerコンソール・ホストに、エージェントのためのファイル・システム・ディレクトリが新規作成されます。

<MW_HOME>/user_projects/domains/<domain_name>/output/<agent_name>

この新しいディレクトリには、エージェントのインストール・ディレクトリにコピーする必要がある、登録済エージェントに生成されたファイルが格納されます。

11g Webgate/アクセス・クライアント: 生成されたファイルをWebgate_instance_dir/webgate/config (たとえば、WebTier_Middleware_Home/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config)にコピー

10g Webgate/アクセス・クライアント: 生成されたファイルをWebgate_install_dir/access/oblix/libにコピー

mod_osso: 生成されたファイルをOHS_webserver_dir/oracle/product /11.1.1/as_1/instances/instance1/config/OHS/ohs1/osso/にコピー

生成されたファイルには次が含まれます。

- ObAccessClient.xml (Webgateの場合)
事前登録されたIAMSuiteAgentは、ブートストラップや構成にObAccessClient.xmlを使用しません。

OAM 10gでは、configureWebgateツールの実行時にエージェント側でObAccessClient.xmlが生成されていました。Oracle Access Managerコンソールまたはリモート登録ツールを使用して、ObAccessClient.xmlを作成できます。

- cwallet.sso(トランスポート・セキュリティ・モードに関係なく11g Webgateの場合)

- 安全な通信のための証明書とパスワード(必要な場合)。たとえば、password.xmlファイルやaaa_cert.pem、aaa_key.pemファイルなど。

注意:
11g Webgateの登録を編集するときに、モードがオープンから証明書、あるいは簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェント・キー・パスワードを編集しても、新しいpassword.xmlは生成されません。

- osso.confファイル(OSSOエージェントの場合)

Webgateの起動前に、ObAccessClientファイルを、生成元の場所からWebgateインスタンスをホストするコンピュータ上のWebgateのインストール先ディレクトリにコピーします。

Webgateの実行時に、定期的な更新チェックの際に変更が発見されると、ObAccessClientファイルが自動的に更新されます。

最小限に暗号化されたファイルに格納される簡易モードのグローバル・パスフレーズ: password.xml

証明書モード:

- PEMキーストア別名

- PEMキーストア別名パスワード

コンソールを使用したOAMエージェントの登録および管理

この項では、Oracle Access Managerコンソールを使用してOAMエージェントを管理する方法について説明します。この項の内容は次のとおりです。

- Webgate登録の作成と編集について

- ユーザー定義のWebgateパラメータについて

- Webgate用IPアドレスの検証について

- OAMエージェント登録の検索

- Webgateまたはプログラム・アクセス・クライアントの登録

- OAMエージェント登録の表示または編集

- Webgate登録の削除

関連項目:
必要に応じて次の章を参照してください。

- 第27章「OAM 11gによるOAM 10g Webgateの管理」

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

- 付録E「Oracle Access Manager 11gとの安全な通信」

Webgate登録の作成と編集について

OAM nng Webゲートの作成ページでは、登録を合理化するために最小限の情報が要求されます。アスタリスク(*)は必須の詳細です。図9-4に示す11g Webgateのページと、図9-5に示す「OAM 10G Webゲートの作成」ページを比較してください。

図9-4 「OAM 11g Webゲートの作成」ページ

「図9-4 「OAM 11g Webゲートの作成」ページ」の説明

OAM 11g Webgateと10g Webgateのどちらを登録する場合でも、図9-5に示すように、最初に要求される情報はほぼ同じです。

図9-5 「OAM 10G Webゲートの作成」ページ

「図9-5 「OAM 10G Webゲートの作成」ページ」の説明

表9-4は、10g Webgateと11g Webgateの作成ページを示しています。

表9-4 OAM 10g WebgateとOAM 11g Webgateの作成ページ

OAMエージェントの要素

説明

名前

このエージェント登録を一意に識別できる名前。ほとんどの場合、Webgateに使用されるWebサーバーをホストするコンピュータ名です。

各エージェント登録を一意に識別する名前が推奨されます。ただし、次のことに注意してください。

- エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければOracle Access Managerによってポリシーが作成されます。

- ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

ベースURL

オプション

WebgateのWebサーバーがインストールされるコンピュータのホストおよびポート。たとえば、http://my_host:port or https://my_host:portとなります。ポート番号はオプションです。

注意: 特定のベースURLは、一度のみ登録できます。このベースURLからWebgateがインストールされているWebサーバー・ドメイン(<hostidentifier>要素で指定)へのマッピングは、1対1です。ただし、1つのドメインが複数のベースURLを持つことができます。

アクセス・クライアント・パスワード

オプション

このWebgateのオプションかつ一意のパスワードで、この登録プロセス中に割り当てられています。

登録されたWebgateがOAM 11gサーバーに接続するときは、認可されていないWebgateがOAM 11gサーバーに接続してポリシー情報を取得しないように、認証にこのパスワードが使用されます。

セキュリティ

エージェントおよびOAMサーバー間の通信トランスポート・セキュリティのレベル(OAMサーバーに指定されたレベルと一致する必要があります)

- オープン: トランスポート・セキュリティを使用しません。

- 簡易: 動的に生成されるセッション鍵を使用する、SSL v3/TLS v1.0のセキュア・トランスポート。

- 証明書: サーバー側のx.509証明書を使用したSSL v3/TLS v1.0のセキュアなトランスポート。このオプションを選択すると、「エージェント・キー・パスワード」を入力するフィールドが表示されます。
エージェント・キー・パスワード: 秘密鍵ファイル(aaa_key.pem)は、DESアルゴリズムを使用して暗号化されます。エージェント・キー・パスワードは、不明瞭化された形式でpassword.xmlに保存され、サーバーがpassword.xmlを生成する際に必要とされます。ただし、このパスワードはサーバーでは保持されません。11g Webgateの登録を編集するときに、モードがオープンから証明書、あるいは簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェント・キー・パスワードを編集しても、新しいpassword.xmlは生成されません。

注意: 簡易モードと証明書モード、DESアルゴリズムを使用した秘密鍵の暗号化の詳細は、付録Eを参照してください。

ホスト識別子

この識別子はWebサーバー・ホストを表します。

関連項目: 「仮想Webホスティングについて」

ユーザー定義パラメータ

特定のWebgateの動作を有効にするために入力できるパラメータ。

関連項目: 「ユーザー定義のWebgateパラメータについて」

仮想ホスト

複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールした場合は、「仮想ホスト」の横にあるボックスを選択します。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。

関連項目: 「仮想Webホスティングについて」

ポリシーの自動作成

エージェントの登録時に、認証と認可のポリシーを自動的に作成できます。このオプションは、デフォルトでチェック(有効)されています。

デフォルト: 有効

注意: ドメインおよびポリシーをすでに登録している場合、新しいリソースを追加できます。このオプションを解除(チェックなし)すると、アプリケーション・ドメインやポリシーは自動的に生成されません。

IPの検証

「IPの検証」の横にあるボックスを選択し、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。「IPの検証例外」ボックスに、検証から除外するIPアドレスを標準的なアドレス表記(例: 10.20.30.123)で入力します。

これを有効にした場合は、ObSSOCookieに格納されているIPアドレスがクライアントのIPアドレスに一致する必要があります。一致しない場合はCookieが拒否され、ユーザーは再認証が必要になります。

デフォルト: 無効

関連項目: 「Webgate用IPアドレスの検証について」

エージェント・キー・パスワード

このパスフレーズは、証明書モードの通信でのみ要求され、簡易モードと証明書モードでWebgateとOAMサーバーとの間のSSL通信に使用する秘密鍵を暗号化する際に使用されます。

注意: 「エージェント・キー・パスワード」は、この表で既出の「アクセス・クライアント・パスワード」とは関係ありません。

簡易モード: このモードの場合、エージェント・キー・パスワードはグローバル・パスフレーズであり、クライアントとサーバーの両方で同じであることが必要です。OAMサーバーをこの構成にすると、エージェント登録の際にパスワードを取得できます。ただし管理者は、エージェント登録の際に生成されるpassword.xmlファイルをクライアント側にコピーする必要があります。

証明書モード:: このモードの場合、エージェント・キーはグローバルではないため、クライアントとサーバーで同じである必要はありません。管理者は、エージェント登録時のpassword.xmlファイルの生成を有効にし、password.xmlファイルがエージェント側にコピーされるように、エージェント・キー・パスワードを入力する必要があります。証明書を生成するには、openSSLや他のサード・パーティ製ツールでこのパスワードを使用して秘密鍵(SSLに使用する)を暗号化し、aaa_key.pem内に格納する必要があります。実行時には、Webgateがこのキーをpassword.xmlから取得し、aaa_key.pemのキーを復号化します。

- キーが暗号化されている場合、Webgateは内部的にコールバック機能を呼び出してパスワードを取得します。

- キーが暗号化されていてpassword.xmlが存在しない場合、WebgateはOAMサーバーとの接続を確立できません。

- キーが暗号化されていない場合、password.xmlの読取りは試行されません。

詳細は、付録Eを参照してください。

リソース・リスト

保護されているリソース(URI)リスト

保護されているアプリケーションのURI: /myapp/loginなど。保護されているアプリケーションの各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。

デフォルト: 2つのリソースがデフォルトで保護されます。

/.../*
/

デフォルトは、複数のディレクトリにまたがるゼロまたは複数の中間レベル内にある任意の文字シーケンスに一致します。

関連項目: 「リソースのURLについて」

パブリック・リソース(URI)リスト

それぞれのパブリック・アプリケーションは、パブリック・リソース・リストの表の新しい行で指定する必要があります。

フィールドを追加して、パブリック・アプリケーションとリソースのURI値を入力してください。それぞれのURIは、パブリック・リソース・リストの表の新しい行で指定する必要があります。

Webgate登録を合理化するために、追加の要素は非表示になりデフォルト値が適用されます。コンソールでWebgate登録ページを表示または編集する際には、図9-6のようにすべての要素と値が表示されます。ほとんどの要素はリモート登録ツールを使用して定義する場合と同じですが、第10章で説明されているとおり、OAMテンプレートが拡張されます。

図9-6 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ

「図9-6 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ」の説明

図9-7 拡張されたOAM 10g Webgate登録ページ

「図9-7 拡張されたOAM 10g Webgate登録ページ」の説明

表9-5は、展開された登録の要素をまとめています。ここに表示された追加設定は、OAMプロキシにより使用されます。ObAccessClient.xmlは、ここに記載されているようにOracle Access Managerコンソールを使用するか、または第10章にあるようにリモート登録ツールを使用するかにかかわらず、エージェントの登録後に値が移入されます。

表9-5 展開されたOAM 11gおよび10g Webgateの要素とデフォルト

OAMエージェントの要素

説明

名前

このWebgate登録の名前。

アクセス・クライアント・パスワード

オプションで一意のOAMエージェントのパスワード。エージェントがOAMサーバーに接続する場合、サーバーに対して自身を認証するときにこのパスワードを使用します。これによって、認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。

プライマリCookieドメイン

10g Webgateのみ

このパラメータは、OAMエージェントがデプロイされるWebサーバー・ドメインを記述します。たとえば、acompany.comなどです。

Webサーバーでシングル・サインオンを有効にするために、cookieドメインを構成する必要があります。特に、シングル・サインオンを構成する対象のWebサーバーには、同じプライマリCookieドメインの値が必要です。OAMエージェントは、ObSSOCookie認証cookieを作成するためにこのパラメータを使用します。

このパラメータは、Cookieドメインに参加してObSSOCookieを受信および更新する機能を持つWebサーバーを定義します。このCookieドメインはObSSOCookieの移入に使用されず、ObSSOCookieの有効なドメインおよびObSSOCookieの内容を承認および変更する機能を持つWebサーバーを定義します。

デフォルト: 登録中にクライアント側のドメインを決定できる場合、プライマリCookieドメインがその値で移入されます。ただし、ドメインが見つからない場合、値が存在しないのでWebgateはホストベースのCookieを使用します。

注意: ドメイン名が一般的なほど、シングル・サインオンの実装が包括的になります。たとえば、b.comをプライマリcookieドメインに指定した場合、ユーザーはb.comとa.b.com上のリソースに対してシングル・サインオンを実行できるようになります。しかし、a.b.comをプライマリcookieドメインに指定すると、ユーザーはb.com上のリソースをリクエストする場合、再び認証しなければならなくなります。

状態

Oracle Access Managerコンソールでのみ設定

OAMエージェントが有効か無効かを指定します。

デフォルト = 有効

最大キャッシュ要素

キャッシュに保持される要素数。キャッシュは次のとおりです。

- 認証スキームに対するリソース: このキャッシュは、リソース(URL)に関する情報を保持します。そのURLが保護されているかどうか、そして保護されている場合は保護に使用されている認証スキームもその情報に含まれます。

- (11g Webgateのみ)認可ポリシーに対するリソース: このキャッシュは、リソースとそれに関連する認可ポリシーに関する情報を保持します。このキャッシュには、特定の認証スキームIDの認証スキーム情報が格納されます。

この設定の値は、これらのキャッシュの要素の最大合計カウントを参照します。

デフォルト = 100000

キャッシュ・タイムアウト(秒)

キャッシュされた情報が使用も参照もされないとき、Webgateのキャッシュ(認証スキームに対するリソース、認証スキーム、11g Webgateのみの認可ポリシーに対するリソース)にその情報が残る時間。

デフォルト = 1800(秒)

ユーザー定義パラメータ

11g Webgateのみ

- 認可結果キャッシュの最大要素: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するユーザー・セッションの認可結果に関する情報を保持します。たとえば、次のように指定します。

maxAuthorizationResultCacheElems=10000

デフォルト = 100000

- 認可結果のキャッシュ・タイムアウト: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するユーザー・セッションの認可結果に関する情報を保持します。たとえば、次のように指定します。

authorizationResultCacheTimeout=60

指定されない場合のデフォルト = 15(秒)

関連項目: 「ユーザー定義のWebgateパラメータについて」、「10gおよび11g Webgateキャッシュのチューニング」

トークンの有効期間

11g Webgateのみ

エージェント・トークン(11g WebgateのOAMAuthnCookieの内容)の有効な最大時間。

デフォルト = 3600(秒)

注意: OAM 10g Webgateの場合、「トークンの有効期間」を設定するには、「Cookieセッション時間」を使用してください。

最大接続数

このOAMエージェントがOAMサーバーと確立できる最大接続数。この数値は、実際にこのエージェントと関連付けられる接続数と同じか、それ以上でなければなりません。

デフォルト = 1

最大セッション時間

アクティビティにかかわりなく、ユーザーの認証セッションが有効でいられる最長時間を秒単位で表す。このセッション時間が満了した場合、ユーザーは認証のための情報を提示するよう再要求されます。これは、強制ログアウトです。

デフォルト = 24(時間)

値0を指定すると、このタイムアウト設定は無効になります。

フェイルオーバーしきい値

このOAMエージェントが、接続をセカンダリOAMサーバーに開くポイントを表す数値。

デフォルト = 1

たとえば、このフィールドに30と入力して、プライマリOAMサーバーへの接続数が29の場合、このOAMエージェントはセカンダリOAMサーバーへの接続を開きます。

AAAタイムアウトしきい値

OAMサーバーからの応答を待つ時間(秒)。このパラメータが設定されている場合、デフォルトのTCP/IPタイムアウトではなく、アプリケーションのTCP/IPタイムアウトとして使用されます。

デフォルト = -1(デフォルトのネットワークTCP/IPタイムアウトが使用されます)

このパラメータの標準的な値は、30から60秒です。非常に小さい値に設定すると、OAMサーバーからレスポンスを受信する前にソケット接続がクローズし、エラーが生じる可能性があります。

たとえば、OAMエージェントが1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーに通信するように構成されているとします。ネットワークのワイヤーがプライマリOAMサーバーから引き抜かれた場合、OAMエージェントはプライマリOAMサーバーへの接続がないことを知るために、TCP/IPタイムアウトの間だけ待ちます。Webgateは、プライマリOAMサーバーから順に、使用可能なサーバーに対して接続の再確立を試行します。このときも、接続が確立可能かどうかを判断するために、OAMエージェントはTCP/IPタイムアウトの間だけ待機します。確立できない場合は、リストの次のサーバーに対して接続を試行します。別のOAMサーバー(プライマリまたはセカンダリ)への接続が確立できる場合、リクエストは再ルーティングされます。ただし、これには必要以上の時間がかかる可能性があります。

新しい接続を検索する際、OAMエージェントは使用可能なサーバーのリストを、構成で指定した順に確認します。プライマリOAMサーバーが1つとセカンダリOAMサーバーが1つずつ指定されていて、プライマリOAMサーバーの接続がタイムアウトした場合、OAMエージェントはまだプライマリOAMサーバーを先に試します。結果的に、OAMエージェントはOAMサーバー・タイムアウトのしきい値設定の2倍を超える期間だけ、リクエストをOAMサーバーに送信できません。

OAMサーバーがリクエストにサービスを提供するのに、タイムアウトのしきい値よりも長い時間がかかる場合、OAMエージェントはリクエストを放棄して、新しい接続でそのリクエストをやり直します。接続プールから返された新しい接続は、接続プールの設定に応じて、同じOAMサーバーへのものとなることがあります。また、しきい値で指定された時間よりも、他のOAMサーバーがリクエストの処理に時間がかかることもあります。この場合、OAMエージェントはOAMサーバーが停止するまで、リクエストを引き続き再試行できます。

アイドル・セッション・タイムアウト

10g Webgateのみ

デフォルト: 3600

リリース7.0.4のWebgateは、独自のアイドル・セッション・タイムアウトのみを強制していました。

10.1.4.0.1 Webgateは、トークンが訪問したすべてのWebgateの中で、最も制限の多いタイムアウト値を強制しました。

10g(10.1.4.3)では、この要素のデフォルトとして、7.0.4の動作が復活しました。

idleSessionTimeoutLogicを設定する手順

- leastComponentIdleTimeoutのデフォルト値は、アイドル・セッション・タイムアウトの施行に最も制限されているタイムアウト値を使用するようWebgateに指示します。

- currentComponentIdleTimeoutの値は、アイドル・セッション・タイムアウトの施行に現在のWebgateのタイムアウト値を使用するようWebgateに指示します。

優先ホスト

ユーザーが保護されたWebサーバーにアクセスしようとしたときに、すべてのHTTPリクエストでホスト名がどう表示されるかを指定します。HTTPリクエストのホスト名は、ユーザーのHTTPリクエストでの定義に関係なく、このフィールドへの入力値に変換されます。

優先ホストの機能によって、ホストの識別子がホスト識別子リストに含まれていない場合に間違って作成される可能性があるセキュリティ・ホールを防止します。ただし、仮想Webホスティングでは使用できません。仮想ホスティングの場合、ホスト識別子の機能を使用する必要があります。

デフォルトは(Webgate登録の)名前です。

ログアウトURL

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Oracle Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

- 一致する場合、Webgateログアウト・ハンドラが起動します。

- また、ログアウトURLが構成されていなければ、リクエストURLに"logout"があるかどうかがチェックされ、見つかった場合("logout.gif"と"logout.jpg"を除く)、ログアウト・ハンドラがトリガーされます。

デフォルト =

注意: これは、最初のログアウトをトリガーするために使用される標準OAM 10g Webgate構成パラメータです。

関連項目: 第15章: OAM 11gに登録されたOAM 10g Webgateでのログアウトの構成に必要なその他の手順

11g Webgateのみのその他のログアウト

OAM 11g Webgateシングル・サインオフの動作については、特定のログアウト要素と値によって、集中ログアウトURL、コールバックURLおよびend_URLへのリダイレクトが自動化されます。これは、カスタマイズされたローカルのログアウト・ページからのみ、10g Webgateのシングル・サインオンを置き換えます。

ログアウト・コールバックURL

11g Webgateのみ

コールバック中にCookieを消去するoam_logout_successのURL。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。たとえば、次のようになります。

デフォルト = /oam_logout_success

host:portを持つ完全なURLフォーマットを使用できます。この場合、OAM 11gサーバーはコールバックURLを再構築せずに、直接コールバックします。

リクエストURLがログアウト・コールバックURLに一致したとき、Webgateは自身のcookieを消去してレスポンスで.gifイメージをストリーミングします。これはOSSOエージェントの動作に似ています。

Webgateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ(end_url=http://host:port/...")として記録され、ログアウト後にOAM 11gサーバーがリダイレクトする先のページになります。

他のOAM 11gサービスは、サーバー上の中央のログアウト・ページをサポートします。end_urlは、OPSSが統合されたアプリケーションから渡されるターゲットURLの問合せパラメータに依存します。

ログアウト・リダイレクトURL

11g Webgateのみ

このパラメータはエージェントの登録完了後に自動的に格納されます。デフォルトでは、これはデフォルト・ポートが14200のOAMサーバー・ホスト名に基づいて決定されます。たとえば、次のようになります。

デフォルト = http://OAMServer_host:14200/oam/server/logout

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはOAMAuthnCookie_<host:port>_<random number>を削除し、Oracle Access Managerに保護されたリソースにユーザーが再アクセスした時に改めて認証を要求します。

関連項目: 第15章、「OAM 11gサーバーによる11g Webgateの一元化されたログアウトの構成」

ログアウト・ターゲットURL

11g Webgateのみ

この値は、ログアウト中にOPSSアプリケーションがWebgateに渡す問合せパラメータの名称です。問合せパラメータは、ログアウト完了後に移動するページのターゲットURLを指定します。

デフォルト: end_url

関連項目: 第15章、「OAM 11gサーバーによる11g Webgateの一元化されたログアウトの構成」

ユーザー定義パラメータ

特定のWebgateの動作を有効にするために入力できるパラメータ。

デフォルト:

proxySSLHeaderVar=IS_SSL
URLInUTF8Format=true
client_request_retry_attempts=1
inactiveReconfigPeriod=10

関連項目: 「ユーザー定義のWebgateパラメータについて」

スリープ時間

OAMサーバーでディレクトリ・サーバーとの接続を確認する頻度(秒)。たとえば、この値を60秒に設定した場合、OAMサーバーは起動した時点から60秒ごとにその接続をチェックします。

デフォルト: 60(秒)

キャッシュ・プラグマ・ヘッダー

キャッシュ制御ヘッダー

Webgateのみ(アクセス・クライアントを除く)

この設定は、Webgateのみに適用して、ブラウザのキャッシュを制御します。

デフォルトでは、どちらのパラメータもキャッシュなしに設定されます。これにより、WebgateによるWebサーバー・アプリケーションおよびユーザー・ブラウザのデータのキャッシュが防止されます。

ただし、サイトがWebgateで保護されている場合、これはPDFファイルのダウンロードやレポート・ファイルの保存など、特定の操作にとって妨げとなることがあります。

Webgateが異なるレベルで使用するAccess Manager SDKキャッシュを設定できます。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlの14.9項を参照してください。

すべてのキャッシュ・レスポンス・ディレクティブが許可されます。たとえば、PDFファイルのダウンロードを許可するには、両方のキャッシュの値をpublicに設定する必要があります。

デフォルト: キャッシュなし

関連項目: 「10gおよび11g Webgateキャッシュのチューニング」

IPの検証

「IPの検証」の横にあるボックスを選択し、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。「IPの検証例外」ボックスに、検証から除外するIPアドレスを標準的なアドレス表記(例: 10.20.30.123)で入力します。

これを有効にした場合は、ObSSOCookieに格納されているIPアドレスがクライアントのIPアドレスに一致する必要があります。一致しない場合はCookieが拒否され、ユーザーは再認証が必要になります。

デフォルト: 無効

関連項目: 「Webgate用IPアドレスの検証について」

保護されていない場合に拒否

Webgateのみ(アクセス・クライアントを除く)

「保護されていない場合に拒否」は有効にすることをお薦めします。

この要素を有効にすると、ルールまたはポリシーでアクセスが明示的に許可されていないすべてのリソースへのアクセスが拒否されます。WebgateがOAMサーバーに問い合せる回数を制限できるため、大規模またはアクセスの多いアプリケーション・ドメインのパフォーマンスを向上させることができます。

- 11g Webgateの場合: 常に有効で変更できません。

- 10g Webgateの場合: 無効にできます。

重要: 「保護されていない場合に拒否」は、「ホスト識別子」および「優先ホスト」をオーバーライドします。「保護されていない場合に拒否」は有効にすることをお薦めします。有効にしない場合、複数のホスト識別子、仮想ホストおよびその他の複雑な構成を持つ大規模なインストールで、セキュリティ・ホールが発生する可能性があります。

管理操作の許可

このエージェント権限機能で、次のようなエージェントごとのセッション操作のプロビジョニングを有効にできます。

- セッションの停止

- セッションの列挙

- 既存のセッションに対する属性の追加または更新

- 特定のセッションIDまたは読取りセッションのすべての属性のリスト

デフォルト: 無効

注意: セッション管理の操作を呼び出せるのは、権限のあるエージェントのみです。このパラメータを有効にすると、セッション管理のリクエスト(上のリスト)がOAMサーバーによって処理されます。無効にすると、エージェントに対してこのリクエストは拒否されます。

プライマリ・サーバー・リスト

このエージェントのプライマリ・サーバー・リストを識別します。デフォルトは、OAMサーバーに基づきます。

- サーバー名

- ホスト名

- ホスト・ポート

- 最大数(このWebgateがOAMサーバーと確立する最大接続数。WebgateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。

セカンダリ・サーバー・リスト

このエージェントのセカンダリOAMサーバーの詳細を識別します。手動で指定する必要があります。

- サーバー名

- ホスト名

- ホスト・ポート

- 最大数(このWebgateがOAMサーバーと確立する最大接続数。WebgateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。

ユーザー定義のWebgateパラメータについて

ユーザー定義パラメータを実装するには、表9-6に示すように、Webgate登録ページで入力する必要があります。

関連項目:
「表10-6 完全なリモート登録リクエストに共通の要素」: リモート登録リクエストでのユーザー定義のWebgateパラメータの詳細。

表9-6 ユーザー定義のWebgateパラメータ

パラメータ

説明

UrlInUTF8Format=true

Oracle HTTP Server 2を使用する環境では、このパラメータをtrueに設定してラテン1および他のキャラクタ・セットを表示する必要があります。

ProxySSLHeaderVar=IS_SSL

Webgateがリバース・プロキシの背後にあり、クライアントとリバース・プロキシの間でSSLが構成されており、リバース・プロキシとWebサーバーの間で非SSLが構成されている場合に使用します。これにより、URLがhttpではなくhttpsとして格納されます。プロキシを使用すると、クライアント接続にSSLと非SSLのどちらを使用するかを示すカスタム・ヘッダー変数を設定して、URLがhttps形式で格納されます。

ProxySSLHeaderVarパラメータの値はプロキシが設定する必要のあるヘッダー変数の名前を定義します。ヘッダー変数の値は"ssl"または"nonssl"である必要があります。

ヘッダー変数が設定されていない場合、SSL状態は現在のWebサーバーのSSL状態によって決まります。

デフォルト: IS_SSL

client_request_retry_attempts=1

WebgateとOAMサーバーのタイムアウトしきい値は、接続不可能とみなして新しい接続のリクエストを試みるまでの、WebgateがOAMサーバーを待機する時間(秒単位)を指定します。

OAMサーバーがリクエストを処理する時間がタイムアウトしきい値を超える場合、Webgateはそのリクエストを破棄し、新規接続でリクエストを再試行します。

デフォルト: 1

注意: 接続プールから返された新しい接続は、接続プールの設定に応じて、同じOAMサーバーへのものとなることがあります。また、別のOAMサーバーでも、リクエストの処理に必要な時間が、タイムアウトしきい値に指定された時間よりも長くなる可能性があります。場合によっては、OAMサーバーが停止するまで、Webgateによる再試行が続行する可能性があります。client_request_retry_attemptsパラメータを使用すると、応答しないサーバーに対するWebgateの再試行の回数を制限できます。

InactiveReconfigPeriod=10

Webgate更新スレッドは、Webgateがアクティブなとき1分間隔で共有シークレットをOAMサーバーから読み取ります。OAMサーバーは、共有シークレットを独自のキャッシュ(OAMサーバー・キャッシュ)に入れて戻します。

デフォルト: 10(分)

関連項目: 「Webgateのポーリング頻度の変更」

fallbackToContainerPolicy=true

IAMSuiteAgentに使用されます。falseに設定すると、リソースへのユーザー・アクセスが拒否され、HTTPレスポンス・コード403が返されます。

trueに設定すると、リクエストはコンテナまで到達し、コンテナで構成されているポリシー(J2EEの認証/認可に関係する)を使用してユーザーにアクセス権を付与または拒否します。

デフォルト: true

logoutRedirectUrl=

http://host.domain.com:14100/oam/server/logout

protectWebXmlSecuredPagesOnly=true

IAMSuiteAgentに使用されます。ユーザーが認証されると、後続のすべてのリクエストに対してこのパラメータを使用し、エージェントで着信リクエストの検証が必要かどうかが決定されます。設定によって次のようになります。

false: エージェントは常に着信リクエストを検証します。

true: デフォルト。着信リクエストを検証するかどうか、次のようにエージェントが決定します。

- アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されている場合、エージェントは着信リクエストを検証します。

- アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されていない場合、エージェントは着信リクエストを検証しません。かわりに、リクエストをそのままアプリケーションまで通過させます。

SSODomains

Oracle Access Managerのインストールで、obrar.cgiのリダイレクト送信を制御する正規のWebサーバーを指定します。値ごとに1つ以上のWebサーバーを記述します。ドメイン名と、すべてのインストールのWebサーバーを対象にするワイルドカードのIPアドレスを使用すると、比較的短いリストになります。

関連項目: 「SSODomainsパラメータについて」

maxAuthorizationResultCacheElems

認可結果キャッシュの最大要素: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するユーザー・セッションの認可結果に関する情報を保持します。次に例を示します。

maxAuthorizationResultCacheElems=10000

デフォルト = 100000

関連項目: 「10gおよび11g Webgateキャッシュのチューニング」

authorizationResultCacheTimeout

認可結果のキャッシュ・タイムアウト: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するユーザー・セッションの認可結果に関する情報を保持します。次に例を示します。

authorizationResultCacheTimeout=60

指定されない場合のデフォルト = 15(秒)

関連項目: 「10gおよび11g Webgateキャッシュのチューニング」

SSODomainsパラメータについて

セキュリティ・リスクを完全に緩和するために、すべてのWebgate登録にはユーザー定義のSSODomainsパラメータを適用することをお薦めします。

このパラメータを指定しない場合、ホストは常に一致します(従来のWebgateの動作と同じ)。

SSODomainsが指定されているが空の場合、ホストは一致しません。これにより、Webgateがobrareq.cgiリクエストを処理しないように指定できます。認証サーバー(認証スキームのチャレンジ・リダイレクトURLで指定される)として使用しないすべてのWebgateに対し、この設定が推奨されます。

構文

ssoDomains = ssoDomainSpec | ssoDomains ssoDomainSpec
ssoDomainsSpec = domainSpec | ipSpec
domainSpec = domain[:port]
domain = domainName | domainName.domain
domainName = usual_DNS_name
ipSpec = ipPart.ipPart,ipPart,ipPart[:port]
ipPart = ipComponent | ipWildCard
ipComponent = usual_IPaddress_component
ipWildCard = *
port = 12345

ガイドライン:

domainName = 通常のDNS名、英数字と'-'、"_'、など。

ipComponent = 通常のIPアドレス構成要素、1桁から3桁

ipWildCard = "*"

port = 通常のポート番号、1桁から5桁

SSODomainsパラメータのspecは、それぞれ次のとおりです。

- specにポートがある場合、specはホスト・ポートに一致する必要があります。ホストに明示的なホストがない場合、デフォルト(HTTPは80、HTTPSは443)が使用されます。

- ホストがIPアドレスで、specがipSpecの場合、左から右にホストとspecの各ipPortに一致します。ipSpecのワイルドカード(*)は、対応するホストのすべての値に一致します。たとえば130.35.*.*と指定すると、130.35.12.45には一致しますが、130.36.12.45には一致しません。

- ホストがDNS名で、specがdomainSpecの場合、specがすべて一致するまで左から右にホストとspecの各domainNameに一致します。たとえばcompany.comと指定すると、target.company.comとtarget.us.company.comには一致しますが、www.badsite.comには一致しません。

- specがホストに、またはテストされたすべてのspecに一致するまで続けます。

obrareq.cgiのURLの右側のパラメータは、(通常)ユーザーの元のターゲットURLから取得されます。ホストは、完全修飾ドメイン名(優先フォーム)、IPアドレス、または部分修飾あるいは未修飾のドメイン名として指定できます。SSODomainsのspecは、使用される可能性があるホスト形式を考慮する必要があり、したがってIPアドレスとドメイン名の必要性を考慮する必要があります。部分修飾または未修飾のドメイン名もdomainSpecsとして指定できます。

ターゲットWebgateに「優先HTTPホスト」を構成すると、SSODomainsパラメータでホスト名のあらゆるバリエーションを網羅する必要がなくなります。ターゲットWebgateにSSODomainsも構成する場合(Webgateが認証に使用されないように、ドメインは避けることが推奨されます)、(パッチを適用した)ターゲットWebgateは、obrareq.cgiのURLの右側のパラメータに優先ホストを使用します。その結果、認証側のWebgateのSSODomainは、優先ホストのドメインのみを網羅すればよいことになります。

望ましい方針としては、SSODomainsの指定に、構成済の各Webgateに定義されているプライマリHTTP Cookieドメインを含めることが考えられ、理論的にはそのドメインのすべてのWebサーバーでObSSOCookieが使用可能になります。

obrareq.cgiリクエストの右側のパラメータがSSODomainsのどのspecとも一致しない場合、Webgateは次のエラーを返します。

Bad Oracle NetPoint Request
The URL /obrareq.cgi is reserved for use by Oracle NetPoint and has been
used with incorrect parameters.

Webgateは、右側のパラメータおよびSSODomains値とともに、受信された/obrareq.cgi URLのrhパラメータを、WebgateのSSODomainsパラメータには使用できませんという警告をログに記録します。これは、何者か、たとえば攻撃者がobrareq.cgi URLを悪用している、あるいは正規のobrareq.cgiリダイレクトがSSODomainsパラメータによって正しく網羅されていないことを意味します。

Webgate用IPアドレスの検証について

IPアドレス検証はWebgate固有です。クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。IPValidationパラメータは、IPアドレスの検証のオンとオフを切り替えます。IPValidationがtrueの場合は、ObSSOCookieに格納されているIPアドレスがクライアントのIPアドレスに一致する必要があり、一致しない場合はCookieが拒否されてユーザーは再認証が必要になります。デフォルトでは、IPValidationはtrueです。

「IPValidation」パラメータは、一部のWebアプリケーションで問題の原因となる場合があります。たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、ObSSOCookieを使用するシングル・サインオンの妨げになります。

注意:
「IPValidationException」パラメータには、この検証プロセスの対象として例外となるIPアドレスをリストします。

「IPValidation」がtrueの場合は、IPアドレスを「IPValidationException」リストと比較できます。そのアドレスが例外リストにある場合、そのアドレスはCookieに格納されたIPアドレスと一致しなくてもよくなります。IPアドレスは、必要な数だけ追加できます。これらのアドレスは、クライアントの実際のIPアドレスであり、obSSOCookieに格納されたIPアドレスではありません。ObSSOCookieに格納されているアドレスは、そのCookieが例外IPアドレスのいずれかから発行されたものである場合、アクセス・システムにより検証を受けなくて済みます。たとえば、CookieのIPアドレスがリバース・プロキシ用のアドレスである場合に、「IPValidationException」パラメータのIPアドレスを使用できます。

Webgateと認証時のクライアントIPアドレスを持たないアクセス・クライアントの間のシングル・サインオンを構成するには、IP検証オプションを明示的に無効にできます(「IPValidation」をfalseに設定)。「IPValidation」パラメータをfalseに設定すると、ブラウザまたはクライアントのIPアドレスは、ObSSOCookieの構成要素として使用されなくなります。ただし、IP検証は、可能なかぎり有効にしておくことをお薦めします。

OAMエージェント登録の検索

図9-8に、OAMエージェント(Webgate)の「検索」コントロール、デフォルト、および空の「検索結果」表を示します。このページから、新しいOAM 11g Webgate登録または10g Webgate登録の作成、あるいは特定のWebgateやWebgateのグループ(たとえば、すべての11g Webgate)の検索ができます。

図9-8 Webgateの「検索」コントロールとエージェント作成ボタン

「図9-8 Webgateの「検索」コントロールとエージェント作成ボタン」の説明

正確な名前がわからない場合には、検索文字列にワイルドカード(*)を使用できます。「検索結果」表で名前を選択すると、登録ページが開いて表示または編集が可能になります。

このページで使用できるコントロールは、表9-7のとおりです。

表9-7 OAMエージェントの「検索」コントロール

コントロール

説明

11g Webゲートの作成

クリックすると、新規11g Webgateの登録ページが開きます。

10g Webゲートの作成

クリックすると、新規10g Webgateの登録ページが開きます。

名前

登録ページで定義されているとおりの名前(または名前の一部とワイルドカード(*))を入力します。たとえば「a*」と入力すると、結果表で「Agent_WebGate_AccessDebugNew」が返されます。

バージョン

Webgateのバージョンを選択して、検索と結果を絞り込みます。

- 11g

- 10g

優先ホスト

HTTPリクエストで使用されるとおりのホスト名の全体(または一部とワイルドカード(*))を入力します。たとえば「iam*」と入力すると、結果表で「IAMSuiteAgent」が返されます。

状態

Webgateのバージョンを選択して、検索と結果を絞り込みます。

- 有効

- 無効

プライマリ・サーバー

プライマリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。

セカンダリ・サーバー

セカンダリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。

前提条件

Webgateは、Oracle Access Manager 11gの登録されたエージェントであることが必要です。

OAMエージェント登録を検索する手順

1. 「システム構成」タブで、「Access Managerの設定」セクションに進みます。

2. 「SSOエージェント」ノードを展開し、「OAMエージェント」ノードをダブルクリックします。

3. 有効なすべてを検索する場合: 「バージョン」で「すべて」、「状態」で「すべて」を選択し、「検索」ボタンをクリックします。

4. バージョンを検索する場合: 「エージェントのバージョン」リストから「10g」または「11g」を選択し、検索を定義します。

5. 名前を検索する場合: テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。

my_OAM_Agent

6. 「検索」ボタンをクリックして、検索を開始します。

7. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集または表示: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- デタッチ: 表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

8. 完了したら変更を適用します(またはページを閉じます)。

Webgateまたはプログラム・アクセス・クライアントの登録

Webgateは、インストールする前に登録できます。プログラム・アクセス・クライアントは、Webgateと同じように登録できます。有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagerコンソールによりOAMエージェントを登録できます。

関連項目:

- Webgate登録の作成と編集について

- OAM 11gでの10g Webgateのプロビジョニング

注意:
エージェント登録時には、少なくとも1つのOAMサーバー・インスタンスが、エージェントと同じモードで実行中である必要があります。そうでなければ、エージェント登録が失敗します。

エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、Webgateモードが少なくともOAMサーバー・モードと同じレベル以上のときに動作を継続します。付録Eを参照してください。

前提条件

少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。

Webgateまたはプログラム・アクセス・クライアントを登録する手順

1. Oracle Access Managerコンソールの「ようこそ」ページから、「SSOエージェント」パネルで次のいずれかをクリックして、新しいページを開きます。

- 新規OAM 11gエージェント

- 新規OAM 10gエージェント(第27章も参照)

または、「システム構成」タブの「Access Managerの設定」セクションから「SSOエージェント」ノードを展開し、「OAMエージェント」ノードをダブルクリックして、右上隅にある目的のWebgate作成ボタンをクリックします。

2. 「OAMエージェントの作成」ページで、必要な詳細(*の付いたもの)を入力して、このOAMエージェントを登録します(表9-4)。

3. 保護されているリソース・リスト: この表では、表9-4にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。

4. パブリック・リソース・リスト: この表では、表9-4にあるように、パブリックにする(保護しない)個々のリソースのURLを入力します。

5. 「ポリシーの自動作成」ボックスが選択されていることを確認します(または、新しいアプリケーション・ドメインが必要ない場合にはボックスの選択を解除してこの機能を無効にします)。

6. 「適用」をクリックして、登録を送信します(または変更を適用しないでページを閉じます)。

7. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

8. ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。

注意:
OAM 10g Webgateをプロビジョニングする場合、現時点ではステップ9をスキップして第27章に進みます。

9. 次の手順を実行して、アーティファクトをWebgateのインストール先ディレクトリにコピーします(またはWebgateをインストールしてから、これらのアーティファクトをコピーします)。

1. Oracle Access Managerコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml(およびすべての証明書アーティファクト)を検索します。次に例を示します。
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml

2. OAMエージェントのホストで、アーティファクトを(次のWebgateディレクトリ・パスに)コピーします。次に例を示します。
11g Webgate/アクセス・クライアント: 11gWebgate_instance_dir/webgate/config/ObAccessClient.xml
(たとえば、WebTier_Middleware_Home/Oracle_WT1/instances1/config/
OHS/ohs1/webgate/config/ObAccessClient.xml)

10g Webgate/アクセス・クライアント: $Webgate_install_dir/oblix/lib/ObAccessClient.xml

3. 第IV部「Oracle Access ManagerのSSO、ポリシーおよびテストの管理」に進みます。

OAMエージェント登録の表示または編集

この手順は、Webgateとアクセス・クライアント登録のどちらを編集する場合でも同じです。有効な管理者の資格証明を持つユーザーは、次の手順で説明するとおり、Oracle Access Managerコンソールを使用して、登録済のOAMエージェントのあらゆる設定を変更できます。たとえば、タイムアウトのしきい値やOAMプロキシで使用される他の設定を変更する場合などです。

変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをWebgateの構成領域にコピーする必要はありません。

注意:
アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にのみ、Webgateディレクトリ・パスにコピーする必要があります。

前提条件

エージェントがOracle Access Managerコンソールに登録されて、使用可能であることが必要です。

関連項目:

- OAMエージェント登録の検索

- Webgate登録の作成と編集について

登録されたWebgateの詳細を表示または変更する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「SSOエージェント」ノードを展開します。

1. 「OAMエージェント」ノード名をダブルクリックして、「検索」ページを表示します。

2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

3. 結果表でエージェント名をクリックし、ページを開きます。

2. 必要に応じて、エージェントの詳細とプライマリまたはセカンダリのサーバー詳細を変更します(表9-5)。

3. ユーザー定義パラメータ: 必要に応じて変更します(表9-6)。

4. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

5. 必要があれば、次の手順を実行してアーティファクトをコピーします。

注意:
アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にのみ、Webgateディレクトリ・パスにコピーする必要があります。OAM 10g Webgateをプロビジョニングする場合は、第27章を参照してください。

1. Oracle Access Managerコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml(およびすべての証明書アーティファクト)を検索します。たとえば、次のようにします。
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml

2. OAMエージェントのホストで、アーティファクトを(次のWebgateディレクトリ・パスに)コピーします。たとえば、次のようにします。
11g Webgate/アクセス・クライアント: 11gWebgate_instance_dir/webgate/config/ObAccessClient.xml
(たとえば、WebTier_Middleware_Home/Oracle_WT1/instances1/config/
OHS/ohs1/webgate/config/ObAccessClient.xml)

10g Webgate/アクセス・クライアント: $Webgate_install_dir/oblix/lib/ObAccessClient.xml

3. 第IV部「Oracle Access ManagerのSSO、ポリシーおよびテストの管理」に進みます。

4. 必要に応じて、付録E「Oracle Access Manager 11gとの安全な通信」を参照してください。

Webgate登録の削除

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access Managerコンソールにより登録されたOAMエージェントを削除できます。

注意:
エージェントの登録を削除すると、登録(関連のホスト識別子、アプリケーション・ドメイン、リソース、エージェント自身を含みません)のみが削除されます。

関連項目:

- OAMエージェント登録の検索

- Webgate登録の作成と編集について

- OAM 11gデプロイメントからの10g Webgateの削除(第27章)

前提条件

このエージェントに関連するアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていることや、削除可能なことを確認します。

OAMエージェントの登録を削除する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「SSOエージェント」ノードを展開します。

1. 「OAMエージェント」ノードをダブルクリックして、「検索」ページを表示します。

2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

2. オプション: 結果表でエージェント名をクリックしてページを開き、これが削除するエージェントであることを確認してページを閉じます。

3. 希望するエージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

4. エージェント名がナビゲーション・ツリーにないことを確認します。

5. Webgateインスタンスの削除: 次の手順を実行すると同時に、必要があれば「OAM 11gデプロイメントからの10g Webgateの削除」を参照してください。

1. Webサーバーを停止します。

2. 次のディレクトリ・パスに用意されているユーティリティを使用して、Webgateソフトウェアを削除します。
$Webgate_install_dir/oui/bin

Windows: setup.exe -d
Unix: runInstaller -d

3. Webgateのアップデート前のhttpd.confバージョンに戻します。たとえば、次のようにします。
コピー内容: httpd.conf.ORIG

コピー先: httpd.conf

4. Webサーバーを再起動します。

5. エージェントのホストで、Webgateのインスタンス・ディレクトリを手動で削除します。たとえば、次のようにします。
11g Webgate/アクセス・クライアントの場合:

11gWebgate_instance_dir/webgate/config/ObAccessClient.xml

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/
webgate/

10g Webgate/アクセス・クライアントの場合:
$Webgate_install_dir/oblix/lib/ObAccessClient.xml

10gおよび11g Webgateキャッシュのチューニング

ここでは、次の内容について説明します。

- Webgateキャッシュの概要

- コンポーネント間のネットワーク・トラフィックの削減

- Webgateのポーリング頻度の変更

関連項目:
「OAMエージェント・メトリックの確認」

Webgateキャッシュの概要

Webgateは、パフォーマンスの向上を図るためにリソース、認証、認可に関する様々な情報をキャッシュします。キャッシュされた情報を使用することで、11gサーバーに何度もアクセスして同じ情報をリクエストすることが回避されます。表9-8に示すのは、Webgateがこのような情報を保持するために使用するキャッシュです。

表9-8 Webgateキャッシュ

キャッシュ・タイプ

説明

認証スキームに対するリソース

このキャッシュは、使用される認証スキームに関する情報を保持します。

デフォルト: 100000要素

関連項目: 「キャッシュの最大要素数のチューニング」、「キャッシュのタイムアウト値のチューニング」

認証スキーム

このキャッシュは、使用される認証スキームに関する情報を保持します。

デフォルト: 25要素

通常、「認証スキーム」のキャッシュ要素に必要なメモリーは、1要素ごとに2KB未満です。

関連項目: 「キャッシュのタイムアウト値のチューニング」

認可ポリシーに対するリソース

11g Webgateのみ

このキャッシュは、アクセスするリソースと、関連する認可ポリシーに関する情報を保持します。

デフォルト: 100000要素

関連項目: 「キャッシュの最大要素数のチューニング」、「キャッシュのタイムアウト値のチューニング」

認可結果

11g Webgateのみ

このキャッシュは、ユーザー・セッションに関連する認可に関する情報を保持します。

デフォルト: 1000要素

関連項目: 「認可結果キャッシュのチューニング」、「認可結果キャッシュのタイムアウトのチューニング」

関連項目:
「11g Webgateの診断ページについて」

11g Webgateの診断ページについて

このページには、現在有効なキャッシュ構成パラメータについて役に立つ情報が表示されます。また、キャッシュされた要素数、現在までのヒット数とミス数、個々のキャッシュの現在のメモリー使用状況など、キャッシュについてのランタイム情報も表示されます。このページには、次のURLでアクセスします。

http://webserver:port/ohs/modules/webgate.cgi?progid=1

注意:
Webgateのパラメータに対する変更がWebgate上に反映されるのは、次の構成のリフレッシュ後です。11gエージェントの場合、構成がリフレッシュされるデフォルトの間隔は10分です。

キャッシュの最大要素数のチューニング

デフォルトでは、認証スキームに対するリソースと認可ポリシーに対するリソースのキャッシュは100000要素を格納するように作成されます。通常、これらのキャッシュの要素に必要なメモリーは、1要素ごとに1KB未満です。そのため、各キャッシュの要素数が100000とすると、キャッシュに必要な通常のメモリーはそれぞれ100000KB(100MB)となります。

メモリー要件と実際のデプロイメント、使用するWebサーバー、アプリケーションで一意なURLの数を考慮して、キャッシュされる要素の最大数を増減した方がよい場合があります。

注意:
必要に応じて「最大キャッシュ要素」のパラメータ値を変更してください。この値を-1に設定すると、すべてのWebgateキャッシュが無効になります。

10gと11gのどちらのWebgateでも、キャッシュされる要素の最大数をチューニングするには、「最大キャッシュ要素」のパラメータを変更します。このパラメータを更新するには、Webgateの再起動が必要です。

1. Oracle Access Managerコンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。

2. 必要に応じて「最大キャッシュ要素」のパラメータを設定します。

3. WebgateのWebサーバーを再起動します。

認可結果キャッシュのチューニング

デフォルトでは、認可結果キャッシュは1000要素を格納するように作成されます。認可結果キャッシュの要素には、ユーザー・セッション識別子、認可ポリシー識別子、処理されたポリシー・レスポンスなど関連する認可結果が格納されます。したがって、認可結果キャッシュの要素は大きくなり、通常でも1要素ごとに2KBのメモリーを必要とします。

メモリー要件と、実際のデプロイメントにおける同時ユーザー・セッション数を考慮して、キャッシュされる要素の数を増やした方がよい場合があります。

1. Oracle Access Managerコンソールで、必要な11g Webgate登録ページを探して開きます。

2. 「ユーザー定義パラメータ」で、必要に応じてmaxAuthorizationResultCacheElemsを追加または更新します。

3. WebgateのWebサーバーを再起動します。

キャッシュのタイムアウト値のチューニング

デフォルトでは、次のキャッシュはタイムアウト値を1800秒つまり30分に設定して作成されます。

- 認証スキームに対するリソース

- 認証スキーム

- 認可ポリシーに対するリソース

これらのキャッシュの要素は失効時間付きで格納され、失効するとキャッシュが強制的にフラッシュされます。

デプロイメントにおける認証スキーム、認証ポリシーおよび認可ポリシーに対する更新頻度を考慮して、デフォルトのタイムアウト値を増減した方がよい場合があります。

1. Oracle Access Managerコンソールで、必要な10gまたは11gのWebgate登録ページを探して開きます。

2. 必要に応じて「キャッシュ・タイムアウト」のパラメータを設定します。

3. WebgateのWebサーバーを再起動します。

認可結果キャッシュのタイムアウトのチューニング

デフォルトでは、認可結果キャッシュのタイムアウト値は15秒に設定されます。認可結果キャッシュの要素は失効時間付きで格納され、失効すると強制的にフラッシュされます。タイムアウト値を低くすると、認可結果は短時間だけキャッシュされるようになります。

ユーザー・セッションの平均時間と、ユーザー・セッションが作成される頻度を考慮して、デフォルトのタイムアウト値を変更した方がよい場合があります。他のキャッシュおよびパラメータとは異なり、このパラメータを更新する際にWebgateの再起動は不要です。更新された値は11g Webgateによって動的に取得され、すぐに適用されます。

注意:
authorizationResultCacheTimeoutを0に設定すると、認可キャッシュが無効になります。

1. Oracle Access Managerコンソールで、必要な11g Webgate登録ページを探して開きます。

2. 「ユーザー定義パラメータ」で、必要に応じてauthorizationResultCacheTimeoutを追加または更新します。

3. WebgateのWebサーバーを再起動します。

コンポーネント間のネットワーク・トラフィックの削減

WebgateによるOAMサーバー構成のポーリングを使用すると、WebgateとOAMサーバーの間でも、Oracle Access Managerの登録済データ・ストアとOAMサーバーとの間でも通信量が削減されます。

手順の概要: WebgateによるOAMサーバー構成のポーリング

1. Webgateが非アクティブな状態が60秒続くと、その構成情報に対するポーリングの頻度を低下させます。
ポーリング頻度は、パラメータInactiveReconfigPeriodによって決まります。これは、Webgate構成ページで設定されるユーザー定義のパラメータです。InactiveReconfigPeriodの値は分で指定します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し実行するようになります。

2. 起動時には、Webgateはブートストラップ構成をチェックし、重要なパラメータが変更されているかどうかを確認します。
これによって、ほとんどの場合再初期化プロセスが不要になり、OAMサーバーからの一時的なロードが削減されます。

3. Webgate構成およびアクセス・クライアント構成は、OAMサーバーにキャッシュされます。
デフォルトのキャッシュ・タイムアウトは59秒です。これは、Apache以外のアクセス・クライアントではシステム動作になんら影響を与えません。Apache WebサーバーでWebgateを使用する場合は、ディレクトリ・サーバーに対する不要なヒットが回避されます。キャッシュのパラメータは、Webgate登録ページで設定できます。

- 「最大キャッシュ要素」は、キャッシュの最大数を設定します(デフォルトは9999)。

- 「キャッシュ・タイムアウト」は、キャッシュ内の任意の要素の最大存続期間を決定します(デフォルト値は59秒です)。

WebgateとOAMサーバー間およびOAMサーバーとデータベース間のオフタイム・ネットワーク・トラフィックを削減する方法は2つあります。

- Webgate構成およびアクセス・クライアント構成のOAMサーバー・キャッシュのデフォルト構成キャッシュ・タイムアウトの変更(ステップ3で説明)

- Webgateによる構成情報ポーリング頻度の変更(次項で説明)

Webgateのポーリング頻度の変更

WebgateとOAMサーバーの間、およびOAMサーバーとデータベースの間のオフタイム・ネットワーク・トラフィックを削減する方法の1つは、InactiveReconfigPeriodパラメータを使用してWebgateのポーリング頻度を変更することです。

デフォルト値は1分です。Webgateが非アクティブな状態(たとえば、認証リクエストが処理されないなど)が60秒を超えて続くと、構成情報に対するポーリングの頻度が低下します。Webgateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回ずつ繰り返し再開するようになります。

- -2に設定すると、Webgateはポーリングを行いません。

- 0より大きい値に設定すると、指定した間隔でポーリングが実行されます。

- -1に設定し、Webgateの非アクティブな状態が1分間続くと、Webgateはポーリングを停止します。Webgateがアクティブな状態に戻ると、構成ポーリングが再開されます。

たとえば、OAMサーバーにより、共有シークレットの値がディレクトリから10分間隔で読み取られ、キャッシュに格納されて、Webgateに戻されます。アイドル状態で、Webgateは、InactiveReconfigPeriod値を使用してOAMサーバーから共有シークレットを読み取ります。この値が設定されていない場合、更新された共有シークレットの値が10分後に戻されますが、Webgateは、1分間隔で共有シークレット(構成)の値についてOAMサーバーをポーリングします。

構成ポーリング頻度を変更する手順

1. 「OAMエージェント登録の検索」の手順に従って、目的のWebgate登録ページを検索します。

2. Webgate登録ページで、ユーザー定義パラメータとしてInactiveReconfigPeriodパラメータを追加します。

3. InactiveReconfigPeriodには、値を分単位で指定します。

4. Webgate登録ページに変更を適用します。

コンソールを使用したOSSOエージェントの登録および管理

この項では、Oracle Access Managerコンソールを使用したOSSOエージェント登録(mod_osso)の管理方法について説明します。詳細は、次の項目を参照してください。

- OSSOエージェントおよびOSSOプロキシについて

- 「OSSOエージェントの作成」ページについて

- OSSOエージェント(mod_osso)登録の検索の絞込み

- OSSOエージェント(mod_osso)の登録

- OSSOエージェント(mod_osso)の登録の表示または編集

- OSSOエージェント(mod_osso)の削除

OSSOエージェントおよびOSSOプロキシについて

OSSOエージェントとは、OSSOサーバーのパートナ・アプリケーションとして機能し、リソースを保護するOracle HTTP Server上にデプロイされた任意のmod_ossoモジュールです。

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

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

説明

SSOログイン

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

SSOログアウト

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

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

OSSOプロキシは、OSSOプロトコルをOracle Access Manager 11gサービスのプロトコルに変換します。

「OSSOエージェントの作成」ページについて

このトピックでは、Oracle Access Managerコンソールを使用したOSSOエージェントの登録について説明します。

注意:
OSSOエージェントを登録する前に、Oracle HTTP Serverがクライアント・コンピュータ上にインストールされて、mod_ossoにWebサーバーが構成済であることを確認してください。

図9-9に、Oracle Access Managerコンソールの「システム構成」タブにある「OSSOエージェントの作成」ページを示します。

図9-9 「OSSOエージェントの作成」ページ

「図9-9 「OSSOエージェントの作成」ページ」の説明

「OSSOエージェントの作成」ページでは、必要な情報にアスタリスク(*)で印が付けられています。表9-9は、新しいエージェントを登録する際に指定できる必須およびオプションの詳細を示します。

表9-9 「OSSOエージェントの作成」ページの要素

要素

説明

名前

このmod_ossoエージェントを識別する名称。

トークン・バージョン

トークンのデフォルト・バージョンは3.0です。次のオプションを使用できます。

- 1.2

- 1.4

- 3.0

ベースURL

OSSOエージェントで必須です。

必要なプロトコル、ホスト、およびエージェントのWebサーバーがインストールされるコンピューターのポート。たとえば、http://host.example.domain.com:port or https://example.domain.com:portなどです。

注意: ホストとポートは、展開された登録のデフォルトとして使用されます。表9-10を参照してください。

管理者ID

このmod_ossoインスタンスの管理者のログインID(オプション)。たとえば、SiteAdminなどです。

管理者情報

このmod_ossoインスタンスの管理者の詳細(オプション)。たとえば、アプリケーション管理者などです。

ホスト識別子

ホスト識別子は、エージェント名に基づいて自動的に入力されます。

ポリシーの自動作成

エージェントの登録時に、認証と認可のポリシーを自動的に作成できます。このオプションは、デフォルトでチェック(有効)されています。

OSSOプロキシには、汎用のURL(/.../*)を持ったリソースを含み、LDAPスキーム(デフォルト)に基づくポリシーに保護されているアプリケーション・ドメインが必要です。サーバー側で汎用のURLが使用されるのは、このためです。

デフォルト: 有効

注意: ドメインおよびポリシーをすでに登録している場合、新しいリソースを追加できます。このオプションを解除(選択解除)すると、アプリケーション・ドメインやポリシーは自動的に生成されません。

エージェントの登録を合理化するため、いくつかの要素は非表示にされ、コンソールで登録時にはデフォルト値が使用されます。エージェントの登録ページをOracle Access Managerコンソールで表示すると、すべての要素と値が表示されます。

図9-10は、コンソールで表示した場合のエージェント・ページ全体を示します。「確認」ウィンドウはそのまま表示されます。指定された詳細のすべてとデフォルト値が表示されます。

図9-10 「OSSOエージェント」ページと「確認」ウィンドウ

「図9-10 「OSSOエージェント」ページ」および「確認」ウィンドウ」の説明

表9-10は、OSSOエージェントで使用される展開済の要素とデフォルトの概要を示します。

表9-10 展開されたOSSOエージェントの要素

要素

説明

サイト・トークン

認証をリクエストする際にパートナにより使用されるアプリケーション・トークン。これは編集できません。

成功URL

認証が成功したときに使用されるリダイレクトURL。デフォルトでは、ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_successが使用されます。次に例を示します。

デフォルト: http://example.domain.com:7001/osso_login_success

失敗URL

認証が失敗したときに使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_failureが使用されます。

デフォルト: http://example.domain.com:7001/osso_login_failure

開始日

アプリケーションへのログインがサーバーにより許可される第1日目の年月日。

デフォルト: エージェントの登録日。

ホームURL

認証後にホーム・ページとして使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。

デフォルト: http://example.domain.com:7001

ログアウトURL

ログアウトするときに使用されるリダイレクトURL。これは、ユーザーをサーバー上のグローバル・ログアウト・ページにリダイレクトします: osso_logout_success。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。

デフォルト: http://example.domain.com:7001/osso_logout_success

関連項目: 「一元化されたOAM 11gのログアウトの概要」。

OSSOエージェント(mod_osso)登録の検索の絞込み

「OSSOエージェント」ノードを初めて開くと、「検索」フォームが表示されます。「結果」表に、すべてのOSSOエージェントがリストされます。結果が多すぎて目的のものをすぐに見つけられない場合には、コントロールを使用して検索を絞り込むことができます。

注意:
「検索」ページの最上部に、「OSSOエージェントの作成」ボタンがあります。

OSSOエージェントの検索を絞り込む要素は、登録時に割り当てられた「エージェント名」、またはシステムによって割り当てられる「エージェントID」の2つのみです。

前提条件

OSSOエージェントがOracle Access Manager管理コンソールに登録されて、使用可能であることが必要です。

OSSOエージェント登録を検索する手順

1. 「システム構成」タブで、「Access Manager」セクションに進みます。

2. 「SSOエージェント」ノードを展開し、「OSSOエージェント」ノードを開きます。

3. 「名前」フィールドに、検索の基準を入力します(ワイルドカード(*)の使用は任意)。次に例を示します。

my*

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」表で、次のようにします。

- 編集または表示: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- デタッチ: 表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. 終了したら変更を適用します(またはページを閉じます)。

OSSOエージェント(mod_osso)の登録

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access ManagerコンソールによりOSSOエージェントを登録できます。

前提条件

Oracle HTTP Serverがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。

関連項目:

- 「OSSOエージェントの作成」ページについて

- リモート・コマンドライン・ツールの使用について詳しくは、第10章

OSSOエージェントを登録する手順

1. Oracle Access Managerコンソールの「ようこそ」ページから、「エージェント構成」パネルで次のリンクをクリックして、新しいページを開きます。

- OSSOエージェントの追加

または、「システム構成」タブから、「エージェント」ノードと「OSSOエージェント」ノードを展開し、ツール・バーの「作成」ボタンをクリックします。

2. ツール・バーで「作成」ボタンをクリックします。

3. 「OSSOエージェントの作成」ページで、表9-9にある必要な詳細を入力します。

- 名前

- ベースURL

4. 必要な「トークン・バージョン」を選択し、必要な場合にはオプションの詳細を入力します(表9-9)。

5. 「適用」をクリックして、登録を送信します(または変更を適用しないでページを閉じます)。

6. 「確認」ウィンドウで、生成されたアーティファクトのパスを確認し、ウィンドウを閉じます。次に例を示します。

Artifacts are generated in following location : /.../base_domain/output/OSSO1

7. 更新されたosso.confファイルをOSSOエージェントのホストにコピーします。

1. Oracle Access Managerコンソールのホストで、更新されたOSSOエージェントのosso.confファイルを検索します。次に例を示します。
$DOMAIN_HOME/output/$Agent_Name/osso.conf

2. OSSOエージェントのホストで、osso.confをmod_ossoディレクトリ・パスにコピーします。
$OHS_dir/osso.conf

たとえば、WebTier_Middleware_Home/Oracle_WT1/instances1/config/
OHS/ohs1/config/osso.conf
などです。

3. OSSOをホストするOAMサーバーを再起動します。

8. 第IV部「Oracle Access ManagerのSSO、ポリシーおよびテストの管理」に進みます。

OSSOエージェント(mod_osso)の登録の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順で説明するとおり、Oracle Access Managerコンソールを使用して、登録済のOSSOエージェントのあらゆる設定を変更できます。たとえば、終了日を変更したり、管理者の情報を追加する場合があります。

前提条件

Oracle HTTP Serverがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。

関連項目:

- OSSOエージェント(mod_osso)登録の検索の絞込み

- 「OSSOエージェントの作成」ページについて

OSSOエージェント登録の閲覧または変更の手順

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。

2. 「OSSOエージェント」ノードをダブルクリックします。

3. エージェントの検索: 「OSSOエージェント(mod_osso)登録の検索の絞込み」

4. 「検索結果」表で目的のエージェント名をクリックし、登録ページを開きます。

5. 登録ページで、必要に応じて詳細を表示または変更します(表9-9および表9-10)。

6. 「適用」をクリックして変更を送信し(または変更を適用せずにページを閉じます)、「確認」ウィンドウを閉じます。

7. 更新されたosso.confファイルをOSSOエージェントのホストにコピーします。

1. Oracle Access Managerコンソールのホストで、更新されたOSSOエージェントのosso.confファイルを検索します。次に例を示します。
$DOMAIN_HOME/output/$Agent_Name/osso.conf

2. OSSOエージェントのホストで、osso.confをmod_ossoディレクトリ・パスにコピーします。
$OHS_dir/osso.conf

たとえば、WebTier_Middleware_Home/Oracle_WT1/instances1/config/
OHS/ohs1/config/osso.conf
などです。

3. OSSOエージェントをホストしているOAMサーバーを再起動し、第IV部「Oracle Access ManagerのSSO、ポリシー、およびテストの管理」に進みます。

OSSOエージェント(mod_osso)の削除

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access Managerコンソールにより登録されたOSSOエージェントを削除できます。

注意:
エージェントの登録を削除すると、登録(関連のホスト識別子、アプリケーション・ドメイン、リソース、エージェント・インスタンス自身を含みません)のみが削除されます。

前提条件

このエージェントに関連するアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていることや、削除可能なことを確認します。

関連項目:
OSSOエージェント(mod_osso)登録の検索の絞込み

OSSOエージェントの登録を削除する手順

1. 「システム構成」タブの「Access Managerの設定」セクションから、「SSOエージェント」ノードを展開し、「OSSOエージェント」ノードを開きます。

2. 「検索」をクリックし、目的の名前を選択します(または、必要に応じて検索を絞り込みます)。

3. オプション: 希望する名前をダブルクリックして、登録ページを表示します。これが削除するエージェントであることを確認し、ページを閉じます。

4. エージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

10 パートナ(エージェントおよびアプリケーション)のリモート登録

Oracle Access Manager 11gには、パートナ登録を効率化するコマンドライン・ユーティリティが用意されています。ネットワーク内の管理者はリモート登録ツールを使用して、テンプレートでWebgateパラメータおよび値を指定できます。ネットワーク外の管理者は、ネットワーク内の管理者に情報を提供するユーティリティを使用できます。

この章では、コマンドライン・ユーティリティを使用したパートナ登録の実行を中心に説明します。この章の内容は次のとおりです。

- 前提条件

- リモート・パートナ登録の概要

- 登録ツールの取得および設定

- 登録リクエストの作成

- 帯域内リモート登録の実行

- 帯域外リモート登録の実行

- リモート登録およびリソース保護の検証

- リモート管理モードの概要

- エージェントのリモート管理

- エージェントを使用しないアプリケーション・ドメインの作成または更新

前提条件

この章のタスクを実行する前に、Oracle Access Managerコンソールと管理対象OAMサーバーが稼動していることを確認してください。

関連項目:
第27章: Oracle Access Manager 11gで10g Webgateを登録および使用する方法

リモート・パートナ登録の概要

Oracle Access Manager認証および認可サービスと通信するには、サポートされているポリシー施行エージェントをOracle Access Manager 11gに登録する必要があります。パートナ・アプリケーション(認証機能をOracle Access Manager SSOプロバイダに委任して複数のリソースのアクセス時のユーザーの再認証を省略するアプリケーション)も登録する必要があります。

Oracle Access Manager 11gでアプリケーションを保護するには、Oracle Access Managerコンソールに登録されたOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)と、特定の認証ポリシーおよび認可ポリシーでアプリケーションを保護するように構成されているアプリケーション・ドメインが必要です。

次のコマンドライン登録機能がサポートされています。

- 次の管理者によるアプリケーション・ドメインのセキュアな登録および作成

- 帯域内の管理者(エージェントをホストするWebサーバーを管理するネットワーク内の管理者)
帯域内の管理者は、登録タスクに登録ツールまたはOracle Access Managerコンソールを使用できます。この章では、コマンドライン登録に焦点を当てています。

- 帯域外の管理者(ネットワーク外の管理者)
ネットワーク外の管理者は、登録リクエストをネットワーク内の管理者に送信する必要があります。リクエストを処理した後、帯域内の管理者は、ファイルを使用して環境を構成する帯域外の管理者に必要なファイルを戻します。

- パートナ・アプリケーションごとの対称キーの生成
登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

- レガシー・システムと下位互換性のある以前のOracle Access Manager WebgateおよびOSSOエージェントの登録が用意されています。詳細は、Oracle Technology Networkの動作保証マトリックスを参照してください。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

次のリストの機能はサポートされていません。

- キーおよびエージェント情報の永続性

- Oracle Access Manager内部コンポーネントで使用されるキーの生成

- エージェント情報を読み取るAPIサポート

詳細は、次の項を参照してください。

- 帯域内リモート登録について

- 帯域外リモート登録について

- キーの使用、生成、プロビジョニングおよび格納について

- リモート登録ツールについて

- リモート登録のリクエスト・ファイルについて

- 帯域外登録レスポンスについて

帯域内リモート登録について

登録ツールを使用してパートナ・アプリケーションをプロビジョニングする帯域内のWebサーバーの管理者タスクの概要は、次のとおりです。リソースを保護するOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)の使用の有無に関係なく、タスクは同じです。

注意:
mod_ossoは、認証にOracleASアプリケーションを提供するOracle HTTP Serverモジュールです。ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onで保護されるアプリケーションを有効化してユーザー名およびパスワードのかわりにHTTPヘッダーを受け入れるOracle HTTP Serverにこのモジュールが存在します。これらのヘッダーの値がmod_osso Cookieに格納されます。

mod_ossoモジュールは、パートナ・アプリケーションの統合に以前のリリースのOracleAS Single Sign-Onで使用されたシングル・サインオンSDKに置き換わります。アプリケーション・サーバーに格納されるmod_ossoは、シングル・サインオン・サーバーの唯一のパートナ・アプリケーションとして認証プロセスを簡易化します。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。ユーザーの認証後、mod_ossoは、ユーザーの認可にアプリケーションで使用される可能性のある単純なヘッダー値を送信します。

- ユーザー名

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

- 言語および地域

この概要の「管理者」という用語は、Oracle Access Managerに登録されるデフォルト・システム・ユーザーのアイデンティティ・ストアの管理者に指定されるLDAPグループの一部であるネットワーク内のユーザーを示します。

タスクの概要: リモート登録を実行する帯域内の管理者

1. Oracle Access Manager 11gリリース1(11.1.1)登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。

2. エージェントおよびアプリケーション・ドメインの一意の値で入力ファイルを更新します(「登録リクエストの作成」を参照してください)。

3. 登録ツールを実行してエージェントを構成し、リソースのデフォルトのアプリケーション・ドメインを作成します(「帯域内リモート登録の実行」を参照してください)。

4. 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。

帯域外リモート登録について

帯域外登録という用語は、帯域内および帯域外の管理者の両方の調整およびアクションを含む手動登録を示します。

タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)

1. 帯域外の管理者は、特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。

- Oracle Access Manager 11g登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。

- テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインの一意の値を入力します(「登録リクエストの作成」を参照してください)。

- 選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。

2. 帯域内の管理者の手順

- Oracle Access Manager 11g登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。

- 登録ツールで帯域外の開始リクエストを使用してエージェントをプロビジョニングし、次のファイルを作成して帯域外の管理者に戻します。次のファイルの詳細は、「帯域内リモート登録の実行」を参照してください。

- agentName_Response.xmlは帯域外の管理者用に生成され、手順3で使用されます。

- Webgateエージェントには、帯域外の管理者が使用してWebgateをブートストラップできる変更されたObAccessClient.xmlファイル(および11g Webgateのcwallet.ssoファイル)が作成されます。
SSOウォレットの作成は、OAM 10gエージェントやOSSOエージェントではなくOAM 11g Webgateにのみ適用されます。

- OSSOエージェントには、帯域外の管理者がOSSOモジュールをブートストラップするために変更されたosso.confファイルが作成されます。

3. 帯域外の管理者は、agentName_Response.xmlファイルと一緒に登録ツールを使用し、エージェント構成および他の生成されたアーティファクトを適切なファイル・システム・ディレクトリにコピーします。

4. 帯域内の管理者は、構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. 帯域外の管理者は、いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。

キーの使用、生成、プロビジョニングおよび格納について

登録方式(Oracle Access Managerコンソールおよびリモート登録)にかかわらず、各登録エージェントに対称キーがあります。

mod_ossoまたはOAMエージェントの保護の有無に関係なく、各アプリケーションに対称キーがあります。登録ツールにより、このキーが生成されます。必要に応じて取得できるように、アプリケーションのマッピング、キーおよびエージェント・タイプがシステム構成に格納されます。

キーの使用

各Webgateエージェントには、エージェントおよびOAM 11gサーバー間で共有される独自の秘密鍵があります。1つのWebgateが損なわれても、他のWebgateは影響を受けません。概要は次のとおりです。

- ホストベースのWebgate固有のOAMAuthnCookie_<host:port>_<random number>を暗号化/復号化します。

- WebgateおよびOAM 11gサーバー間でリダイレクトされるデータを暗号化/復号化します。

キーの生成

図10-1は、使用方式(Oracle Access Managerコンソールおよびリモート登録)に関係なくエージェントの登録時に自動的に発生するキーの生成プロセスを示しています。エージェントごとに1つの対称キーがあります。

図10-1 キーの生成

「図10-1 キーの生成」の説明

キーのアクセス可能性およびプロビジョニング

エージェント固有の各キーは、クライアント・マシン上の保護されたローカル・ストレージを介して、対応するWebgateからアクセスできる必要があります。暗号化キーは、データ・ストアには格納されません。かわりに、JavaキーストアまたはCSFリポジトリのエントリへの別名が格納され、パートナと信頼管理APIは、リクエストされた時点で実際のキーを取得します。エージェント固有の秘密鍵には、次の特徴があります。

- リモート登録中にプロビジョニングされます(帯域内モードまたは帯域外モード)。

- 各エージェントを一意に識別できるように一意の値が設定されます。

- エージェントにセキュアに配布されます(帯域内モードのワイヤまたは帯域外モードの個別のセキュアなチャネルを使用)。

- SSOウォレットのOracle Secret Storeに保存されます。SSOウォレットの作成は、OAM 10gエージェントやOSSOエージェントではなくOAM 11g Webgateにのみ適用されます。

注意:
Oracle Secret Storeは、プレーン・テキストではないOracle Wallet内の秘密鍵および他のセキュリティ関連の秘密情報を統合するコンテナです。SSOウォレットは、基礎となるファイル・システムのセキュリティに基づいてデータを保護します。このウォレットを開く場合、パスワードは必要ありません。SSOウォレットのセキュリティは、オペレーティング・システムおよびファイル権限によって異なります。

- パートナ登録の完了時に自動ログインの編集可能なSSOウォレットのOracle Secret Storeに保存されます。

キーの格納

エージェント・キーを含むSSOウォレットをWebgate_instance_dir/webgate/config(WebTier_Middleware_Home/Oracle_WT1/instancesなど)のObAccessClient.xmlを含むディレクトリのcwallet.ssoに格納する必要があります。

SSOウォレットにユーザー・パスワードは不要で、適切なファイル権限(700)またはWindowsのレジストリで保護する必要があります。

リモート登録ツールについて

この項では、登録ツールの概要、要件、使用方法および結果について説明します。

ロケーション

登録ツールoamregは、次の場所にあります。

<OAM_HOME>/oam/server/rreg/client/RREG.tar.gz

エージェントをホストしているコンピュータでRREG.tar.gzを解凍した後、登録ツールoamregは次のパスに格納されます。

<OAM_HOME>/oam/server/rreg/client/rreg/bin/oamreg

プラットフォーム

oamregのパス

Linux

/rreg/bin/oamreg.sh

Windows

\rreg\bin\oamreg.bat

要件

スクリプトを使用する前に、この項の説明に従ってスクリプト内に2つの環境変数を設定する必要があります。

環境変数

説明

OAM_REG_HOME

後に/rregが付けられるRREG.tarが展開されたディレクトリ。
<OAM_HOME>/oam/server/rreg/client/rreg

JAVA_HOME

Javaがクライアント・コンピュータに格納されているロケーション。たとえば、WLS_HOME/Middleware/jdk160_11などです。
注意: JAVA_HOMEはJDK 1.6を参照する必要があります。

また、登録リクエストのいくつかのタグを変更する必要があります。詳細は、「リモート登録リクエスト・ファイルについて」を参照してください。

登録管理者

ユーザーは、プライマリ・ユーザー・アイデンティティ・ストアの管理者のロールに対してマップされるグループの一部になることができます。詳細は、表5-2「ユーザー・アイデンティティ・ストア要素」を参照してください。

リモート登録モードおよびリクエスト・ファイル

スクリプトを実行するコマンドには、次の2つの引数が必要です。

- モード: inbandまたはoutofband

- input/file: 入力ファイル(*request.xmlまたはagentName_Response.xml)への絶対パス、またはOAM_REG_HOMEの値に対する相対パス。
優先ロケーションは、前述の「要件」表で説明されているとおり、$OAM_REG_HOME/inputです。

エージェント・タイプおよび関連付けられるリクエスト・ファイル

inbandとoutofbandのどちらのモードも、次のようにinput引数を使用するリクエスト・ファイルを使用します(前述の「要件」表を参照)。

表10-1 リモート登録のリクエスト・ファイル

エージェント・タイプ

リクエスト・ファイル

10g Webgate

$OAM_REG_HOME/input/OAMRequest_short.xml

$OAM_REG_HOME/input/OAMRequest.xml

$OAM_REG_HOME/input/OAMUpdateAgentRequest.xml

11g Webgate

$OAM_REG_HOME/input/OAM11GRequest.xml

$OAM_REG_HOME/input/OAM11GRequest_short.xml

$OAM_REG_HOME/input/OAM11GUpdateAgentRequest.xml

OSSOエージェント(mod_osso)

$OAM_REG_HOME/input/OSSORequest.xml

$OAM_REG_HOME/input/OSSOUpdateAgentRequest.xml

エージェントを登録せずに新しいホスト識別子とアプリケーション・ドメインを作成

$OAM_REG_HOME/input/CreatePolicyRequest.xml

関連項目: 「エージェントのリモート管理」

既存のホスト識別子と、エージェント登録に関連付けられていないアプリケーション・ドメインを更新

$OAM_REG_HOME/input/UpdatePolicyRequest.xml

関連項目: 「エージェントのリモート管理」

関連項目:

- 「リモート登録リクエスト・ファイルについて」

- 「リモート管理モードの概要」

- 「リモート・アプリケーション・ドメイン管理モードについて」

生成されたファイル

outofbandモードで、帯域内の管理者は帯域外の管理者が送信した開始リクエスト・ファイルを使用し、追加処理のために生成されたagentName_Response.xmlファイルを帯域外の管理者に戻します。帯域外の管理者は、エージェント構成ファイルを生成する入力としてagentName_Response.xmlと一緒にリモート登録ツールを実行します。

関連項目:
「帯域外登録レスポンスについて」

サンプルのリモート登録コマンドおよび結果

表10-2に示したサンプルのコマンドでは、ツールのロケーションをLinuxシステムの$OAM_REG_HOME (前述の「要件」表)と想定しています。

表10-2 リモート登録のサンプル・コマンド

コマンド・タイプ

サンプル(Linux)

帯域内の管理者の帯域内リクエスト

./bin/oamreg.sh inband input/*Request.xml

帯域内の管理者によって送信されたリクエスト

./bin/oamreg.sh outofband input/starting_request.xml

帯域外の管理者の戻されたレスポンス

./bin/oamreg.sh outofband input/agentName_Response.xml

[prompt_flag] value: [-noprompt]

オプション。-nopromptを使用すると、oamregはプロンプト(パスワードなど)を待ちません。かわりに、これらの値は入力ファイルから、またはechoコマンドを使用してコマンドライン自体から取得されます。

OAM_REG_HOMEロケーションからの例

(echo username; echo password; echo webgate_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt config.file

(echo username; echo password; echo webgate_password; echo httpscert_trust_prompt;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo webgate_password; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo webgate_password; echo httpscert_trust_prompt; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

「エージェントのリモート管理」

スクリプトの起動後、管理者はユーザー名およびパスワードを求められます(表10-2で説明した-nopromptを使用する場合を除く)。スクリプトの実行後、成功または失敗のメッセージが通知されます。入力ファイルおよび登録ツールを実行しているモードに基づいて、表10-3に示されている結果を予期できます。

表10-3 リモート登録の結果

サーバー側の結果

クライアント側の結果

- oam-config.xmlファイルには、*Request.xmlファイルの<agentName>タグに基づく新しく登録されたエージェントのエントリが含まれます。

- サーバーのoam-policy.xmlファイルには、次の新しいエントリが含まれます。
リソースを保護するアプリケーション・ドメインが作成され、*Request.xmlファイルの<agentName>タグのエージェントに基づく名前が付けられます。

帯域内のクライアント側の結果

エージェント固有の構成ファイルが生成され、*Request.xmlファイルの<agentName>タグに基づくディレクトリ(RREG_Home/output/agentName/など)に格納されます。生成された構成ファイルを以前のエージェント構成ファイルと置き換える必要があります。

次のいずれかを適用します。

- OSSOエージェント用に変更されたosso.conf

- 11g Webgate: cwallet.sso

- OAMエージェント: OAM Webgate用に変更されたObAccessClient.xml
登録中に作成された適切な固有の構成出力ファイルをエージェントがインストールされた場所にコピーする必要があります。

11g Webgate/アクセス・クライアント: ObAccessClient.xml (およびcwallet.sso)をWebgate_instance_dir/webgate/config (たとえば、WebTier_Middleware_Home/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate /config)にコピーします。

10g Webgate/アクセス・クライアント: ObAccessClient.xmlをWebgate_install_dir/webgate/configにコピーします。

mod_ossoの場合、osso.confファイルをOHS_webserver_install_dir/oracle/product/11.1.1/as_1/instances/instance1/config/OHS/ohs1/ osso/にコピーします。

- OAMエージェント: Password.xmlファイルおよび簡易モードまたは証明書モードの証明書ファイルも生成されるので、コピーする必要があります。

帯域外のクライアント側の結果: 使用する入力ファイル(開始リクエストまたは生成されたagentName_Response.xmlファイル)に応じて、次の結果が発生します。

- input/starting_Request.xml: 帯域外の管理者によって作成され、<agentName>タグに基づくレスポンス・ファイル(agentName_Response.xml)を生成する帯域内の管理者によって使用されます。任意の方法により、レスポンス・ファイルが帯域外の管理者に送信されます。

- input/agentName_Response.xml: 帯域外の管理者に送信され、レスポンス・ファイルの<agentName>タグに基づくディレクトリにエージェント固有の構成ファイルを作成するために使用されます。次に例を示します。
OSSOエージェント用に変更されたosso.conf

11g Webgate用のcwallet.sso

OAMエージェント(Webgate)用に変更されたObAccessClient.xml

登録中に作成された適切な固有の構成出力ファイルをエージェントがインストールされた場所にコピーする必要があります。

11g Webgate/アクセス・クライアント: ObAccessClient.xmlをWebgate_instance_dir/webgate/config (たとえば、WebTier_Middleware_Home/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config)にコピーします。

10g Webgate/アクセス・クライアント: ObAccessClient.xmlをWebgate_install_dir/webgate/configにコピーします。

mod_ossoの場合、osso.confファイルをOHS_webserver_dir/oracle/product/11.1.1/as_1/instances/instance1/config/OHS/ohs1/osso/にコピーします。

関連項目:

- 「帯域内リモート登録の実行」

- 「帯域外リモート登録の実行」

- 「エージェントのリモート管理」

リモート登録のリクエスト・ファイルについて

この項では、登録ツールと一緒に使用できる登録リクエスト・ファイルおよび共通の要素について説明します。

- OSSOリモート登録リクエスト

- 短い簡易化されたOAMリモート登録リクエスト

- リモート登録リクエストの共通要素

- 完全なOAMリモート登録リクエスト

関連項目:
「リモート管理モードの概要」

OSSOリモート登録リクエスト

例10-1は、登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)と一緒に使用するOSSO登録リクエストの更新バージョンを示しています。太字でハイライト表示されている情報をmod_ossoエージェント用に変更する必要があります。ただし、他のすべてのフィールドはデフォルト値を使用できます。

関連項目:
「リモート登録リクエストの共通要素」

例10-1 OSSORequest.xml

...
<OSSORegRequest>
<serverAddress>http://{oam_admin_server_host}:{oam_admin_server_port}
<http://%7boam_admin_server_host%7d:%7boam_admin_server_port%7d>
</serverAddress>
<hostIdentifier>RREG_HostId</hostIdentifier>
<agentName>RREG_OSSO</agentName>
<agentBaseUrl>http://{web_server_host}:{web_server_port}
<http://%7bweb_server_host%7d:%7bweb_server_port%7d>
</agentBaseUrl>
<applicationDomain>RREG_OSSO</applicationDomain>
<autoCreatePolicy>true</autoCreatePolicy>
<ssoServerVersion>v3.0</ssoServerVersion>
<oracleHomePath>$ORACLE_HOME</oracleHomePath>
<virtualHost></virtualHost>
<updateMode></updateMode>
<adminInfo></adminInfo>
<adminId></adminId>
<logoutUrl></logoutUrl>
<failureUrl></failureUrl>
</OSSORegRequest>

短い簡易化されたOAMリモート登録リクエスト

例10-2は、エージェント登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)と一緒に使用する短いOAM登録リクエストの更新されたサンプルを示しています。OAM 10g WebgateとOAM 11g Webgateの短いOAMリモート登録リクエストの唯一の違いは、次のコンテナです。

- OAMRegRequest

- OAM11GRegRequest

注意:
短いOAMリモート登録リクエストはOAM 10g WebgateとOAM 11g Webgateでほとんど同じですが、使用しているWebgateリリースに適切なテンプレートをコピーしてください。

例10-2では、太字でハイライト表示されている情報のみ、環境に応じた値に変更する必要があります。このファイルの他のすべてのフィールドには、デフォルト値を使用できます。oamregを実行する場合、完全なOAMリモート登録リクエストに存在する可能性のある他のすべてのエージェント定義に対して、デフォルト値が自動的に提供されます。

例10-2 サンプルの簡易リクエスト: OAMRequest_short.xml

<OAMRegRequest>
.
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>RREG_HostId11G</hostIdentifier>
<agentName>Remote_Reg_OAM</agentName>
<protectedResourcesList>
<resource>/</resource>
<resource>/.../*</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/public/index.html</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/excluded/index.html</resource>
</excludedResourcesList>
</OAMRegRequest>

リモート登録リクエストの共通要素

特に指定のないかぎり、表10-4は、すべてのリクエスト・ファイル内のグローバル要素を示します。

表10-4 リモート登録リクエストに共通の要素

要素

説明

例

<serverAddress>

ホストおよびポートを含むOracle Access Managerコンソールの実行中のインスタンスを参照します。

<serverAddress>http://{oam_admin_ser
ver_host}:{oam_admin_server_port}
</serverAddress>

<agentName>

OAM(管理)サーバーのエージェントの一意の識別子を定義します。

各エージェント登録を一意に識別する名前が推奨されます。ただし、次のことに注意してください。

- エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければOracle Access Managerによってポリシーが作成されます。

- ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

<agentName>RREG_OAM</agentName>

<hostIdentifier>

この識別子は、Webサーバー・ホストを表します。OAMエージェント名の値を指定すると、フィールドに自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合、登録中にエラーが発生します。

注意: <hostIdentifier>タグを指定する場合、環境に応じて値を変更する必要があります。登録中にデフォルト値を使用するには、<hostIdentifier>タグを省略します。

同じ名前のホスト識別子がすでに存在する場合、新しいエージェントのWebサーバーのhost:port(指定されている場合)が既存のホスト識別子に追加されます。

<hostIdentifier>RREG_HostId11G
</hostIdentifier>

リモート登録リクエストのOSSO固有の要素

表10-5は、OSSO固有のリモート登録要素を示しています。

表10-5 リモート登録リクエストのOSSO固有の要素

要素

説明

例

<OracleHomePath>

mod_ossoエージェントへのファイル・システム・ディレクトリの絶対パス。

<oracleHomePath>
$ORACLE_HOME
</oracleHomePath>

<virtualHost>

デフォルト: 指定なし

<virtualHost></virtualHost>

<updateMode>

デフォルト: 指定なし

<updateMode></updateMode>

<adminInfo>

このmod_ossoインスタンスのオプションの管理者詳細。たとえば、アプリケーション管理者などです。

デフォルト: 指定なし>

<adminInfo></adminInfo>

<adminId>

このmod_ossoインスタンスのIDのオプションの管理者ログ。たとえば、SiteAdminなどです。

デフォルト: 指定なし>

<adminId></adminId>

<logoutUrl>

リモート登録中の消費のためのログアウトURLを含めます。

デフォルト: 指定なし>

<logoutUrl>logout1.html</logoutUrl>

<failureUrl>

リモート登録中の消費のための失敗URLを含めます。

デフォルト: 指定なし>

<failureUrl>failure1.html</failureUrl>

完全なOAMリモート登録リクエスト

表10-6は、表10-4の短いバージョンのリクエストに含まれる情報に加えて、完全なOAMリモート登録リクエストの個々の要素の情報を示しています。

- OAM11gRequest.xml (11g Webgate)

- OAMRequest.xml (10g Webgate)

注意:
特に明記しないかぎり、各要素が10gおよび11g Webgateリクエストに表示されます。要素名は、コンソールの要素名と多少異なる場合があります。

表10-6 完全なリモート登録リクエストに共通の要素

要素

説明

例

<agentBaseUrl>

エージェントで保護するコンピュータのWebサーバーのhost:portを定義します。保護するすべてのURLがhttp://host:portのように指定する必要があるこのベースURLと相対的になります。

注意: 各agentBaseUrlを一度のみ登録できます。エージェントのベースURLからWebgateがインストールされるWebサーバー・ドメイン(<hostIdentifier>要素で指定)への1対1マッピングが存在します。ただし、指定されたドメインからエージェントのベースURLへの1対多マッピングが存在します(1つのドメインに複数のエージェントのベースURLを使用できます)。

<agentBaseUrl>http://{web_server_
host):(web_server_port}
</agentBaseUrl>

<virtualhost>

これが仮想ホストかどうかを指定します。

値: trueまたはfalse

デフォルト: false

関連項目: 「仮想Webホスティングについて」

<virtualhost>false<virtualhost>

<hostportVariations>

特定のホストのバリエーションをすべて指定します。

登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、OAMはリソースを保護するポリシーを適用できます。

関連項目: 「ホスト識別子について」

<hostPortVariationsList>
<host>host1</host>
<port>7777</port>
</hostPortVariations>
<host>host2</host>
<port>7778</port>
</hostPortVariations>
</hostPortVariationsList>

<applicationDomain>

指定されたエージェント名に基づくアプリケーション・ドメインの名前を定義します(表10-4を参照してください)。

<applicationDomain>RREG_OAM11G
</applicationDomain>

<autoCreatePolicy>

OAM 11g短縮バージョンにはなし

エージェントの登録時に、認証と認可のポリシーを自動的に作成できます。デフォルトで、このオプションが選択(有効化)されます。

デフォルト: true(有効)

注意: ドメインおよびポリシーをすでに登録している場合、新しいリソースを追加できます。このオプションを消去(選択解除)すると、アプリケーション・ドメインまたはポリシーが自動的に生成されません。

<autoCreatePolicy>true
</autoCreatePolicy>

<protectedResourcesList>

認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlの相対パスにする必要があります。

<protectedResourcesList>
<resource>/</resource>
<resource>/.../*</resource>
</protectedResourcesList>

<publicResourcesList>

公開する(OAMエージェントで保護しない)リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。

<publicResourcesList>
<resource>/public/index.html
</resource>
</publicResourcesList>

<excludedresourcesList>

公開する(OAMエージェントで保護されない)HTTPタイプ・リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。

HTTPリソース・タイプのみが除外できます。通常は、セキュリティの影響を受けにくく、認証や認可、レスポンス処理、セッション管理、監査を必要としない画像(*.jpg、*.png)などのファイル。除外されたリソースは、コンソール内のユーザー定義ポリシーには追加できません。

関連項目: 除外されるリソース・リストの詳細は、表13-1「リソース定義要素」

<excludedresourcesList>
<resource>/excluded/index.html
</resource>
</excludedresourcesList>

<primaryCookieDomain>

10gリクエストのみ

OAMRequest.xml(10g Webgate用)では、優先HTTPホストとして<hostIdentifier>も使用されます。

acompany.comなどのOAM 10gエージェントがデプロイされるWebサーバー・ドメイン(クライアント・ドメイン)を示します。

Cookieドメインを構成して、Webサーバー間のシングル・サインオンを有効にする必要があります。具体的には、シングル・サインオンを構成するWebサーバーに同じプライマリCookieドメイン値を使用する必要があります。OAMエージェントは、このパラメータを使用してObSSOCookie認証Cookieを作成します。

このパラメータは、Cookieドメインに参加してObSSOCookieを受信および更新する機能を持つWebサーバーを定義します。このCookieドメインはObSSOCookieの移入に使用されず、ObSSOCookieの有効なドメインおよびObSSOCookieの内容を承認および変更する機能を持つWebサーバーを定義します。

デフォルト: 登録中にクライアント側のドメインを決定できる場合、プライマリCookieドメインがその値で移入されます。ただし、ドメインが見つからない場合、値が存在しないのでWebgateはホストベースのCookieを使用します。

注意: ドメイン名が一般的なほど、シングル・サインオンの実装が包括的になります。たとえば、プライマリCookieドメインにb.comを指定すると、ユーザーはb.comおよびa.b.comのリソースのシングル・サインオンを実行できます。ただし、プライマリCookieドメインにa.b.comを指定すると、ユーザーはb.comのリソースのリクエスト時に再認証を行う必要があります。

<primaryCookieDomain>{client_domain}
</primaryCookieDomain>

<maxCacheElems>

キャッシュに保持される要素の数。キャッシュ要素は次のとおりです。

- URL: URLキャッシュは、URLに関する情報を保持します。そのURLが保護されているかどうか、そして保護されている場合は使用されている認証スキームもその情報に含まれます。

- 認証スキーム: このキャッシュは、特定の認証スキームIDに対する認証スキーム情報を格納します。

この設定の値は、これらの両方のキャッシュの要素の統合された最大数を示します。

デフォルト = 100000

<maxCacheElems>100000
</maxCacheElems>

<cacheTimeout>

キャッシュされた情報が使用および参照されない場合にOAMエージェント・キャッシュに保持される時間。

デフォルト = 1800(秒)

<cacheTimeout>1800</cacheTimeout>

<tokenValidityPeriod>

11gリクエストのみ

エージェント・トークン(11g WebgateのOAMAuthnCookieの内容)の有効な最大時間。

デフォルト = 3600(秒)

<tokenValidityPeriod>3600
</tokenValidityPeriod>

<cookieSessionTime>

10gリクエストのみ

アクティビティに関係なくユーザーの認証セッションが有効な秒単位の最大時間。このセッション時間の終了時に、ユーザーは再認証を要求されます。これは強制ログアウトになります。

デフォルト = 3600(秒)

0(ゼロ)を指定すると、このタイムアウト設定が無効になります。

<cookieSessionTime>3600
</cookieSessionTime>

<maxConnections>

このOAMエージェントとOAMサーバーで確立できる接続の最大数。この数値は、このエージェントに実際に関連付けられる接続の数以上にする必要があります。

デフォルト = 1

<maxConnections>1</maxConnections>

<maxSessionTime>

WebgateおよびOAMサーバー間の接続に使用される時間単位の最大期間。

デフォルト = 24(時間)

0(ゼロ)を指定すると、このタイムアウト設定が無効になります。

<maxSessionTime>24</maxSessionTime>

<ssoServerVersion>

SSOトークン・バージョン値。

- v3.0: OAM 11gサーバーとmod_osso間で交換されるトークンを暗号化するためにAES暗号化標準を使用するほとんどのセキュアなトークン。これがデフォルト値になります。OSSO 10.1.4.3パッチセットでサポートされました。

- v1.4: OSSO 10.1.4.3パッチセット以前のOSSO 10gでサポートされます。DES暗号化標準を使用します。

- v1.2: OSSO 10.1.4.0.1の前のOSSOパートナ間で交換されるトークンのバージョンでした。DESを使用します。

<ssoServerVersion> >...</ssoServerVersion> >

<idleSessionTimeout>

10gリクエストのみ

アクセス・ゲートで保護されたリソースにアクセスしないでユーザーの認証セッションを保持する秒単位の時間。

デフォルト = 3600

0(ゼロ)を指定すると、このタイムアウト設定が無効になります。

<idleSessionTimeout>3600>
</idleSessionTimeout

<failoverThreshold>

このOAMエージェントがセカンダリOAMサーバーの接続を開くポイントを表す数値。

デフォルト = 1

たとえば、このフィールドに30と入力し、プライマリOAMサーバーの接続数が29の場合、このOAMエージェントはセカンダリOAMサーバーの接続を開きます。

<failoverThreshold>1
</failoverThreshold>

<aaaTimeoutThreshold>-

OAMサーバーからのレスポンスを待機する数値(秒単位)。このパラメータが設定されると、デフォルトのTCP/IPタイムアウトではなくアプリケーションのTCP/IPタイムアウトとして使用されます。

デフォルト = -1(デフォルトのネットワークのTCP/IPタイムアウトが使用されます)

このパラメータの一般的な値は、30から60秒です。非常に低い値を設定すると、アクセス・サーバーからリプライを受け取る前にソケット接続がクローズしてエラーが発生する可能性があります。

WaitForFailoverパラメータおよびaaaTimeoutThresholdには、同じ値を使用する必要があります。

関連項目: このパラメータの詳細は、表9-5を参照してください。

<aaaTimeoutThreshold>-1
</aaaTimeoutThreshold>

<sleepFor>

アクセス・サーバーでディレクトリ・サーバーとの接続を確認する頻度。たとえば、60秒の値を設定すると、アクセス・サーバーが起動してから60秒間隔で接続を確認します。

<sleepFor>60</sleepFor>

<debug>

デバッグをオンまたはオフにします。

デフォルト: false(オフ)

<debug>false</debug>

<セキュリティ>

エージェントおよびOAMサーバー間の通信トランスポート・セキュリティのレベル(OAMサーバーに指定されたレベルと一致する必要があります)

- オープン: トランスポート・セキュリティを使用しません。

- 簡易: 動的に生成されるセッション鍵を使用する、SSL v3/TLS v1.0のセキュア・トランスポート。

- 証明書: サーバー側のx.509証明書を使用したSSL v3/TLS v1.0のセキュアなトランスポート。

注意: 詳細は、付録Eを参照してください。

<security>open</security

<denyOnNotProtected>

ルールまたはポリシーでアクセスが明示的に許可されないすべてのリソースのアクセスを拒否します。

11g Webgateの登録では常に有効化されており、変更できません。

10g Webgate登録ページで、これを無効にできます。

有効な場合、匿名認証方式を作成して、匿名アクセス・ポリシーを使用した内容へのアクセスを許可する必要があります。

<denyOnNotProtected>1
</denyOnNotProtected>

<allowManagementOperations>

このエージェント権限機能で、次のようなエージェントごとのセッション操作のプロビジョニングを有効にできます。

- セッションの停止

- セッションの列挙

- 既存のセッションに対する属性の追加または更新

- 特定のセッションIDまたは読取りセッションのすべての属性のリスト

デフォルト: false

注意: セッション管理の操作を呼び出せるのは、権限のあるエージェントのみです。このパラメータを有効にすると、セッション管理のリクエスト(上のリスト)がOAMサーバーによって処理されます。無効にすると、エージェントに対してこのリクエストは拒否されます。

<allowManagementOperations> false/<allowManagementOperations>

<cachePragmaHeader>

<cacheControlHeader>

この設定は、Webgateのみに適用して、ブラウザのキャッシュを制御します。

デフォルトでは、どちらもキャッシュなしに設定されます。これにより、WebgateによるWebサーバー・アプリケーションおよびユーザー・ブラウザのデータのキャッシュが防止されます。

ただし、サイトがWebgateで保護されている場合、これはPDFファイルのダウンロードやレポート・ファイルの保存など、特定の操作にとって妨げとなることがあります。

Webgateが異なるレベルで使用するAccess Manager SDKキャッシュを設定できます。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlの14.9項を参照してください。

すべてのcache-response-directiveが許可されます。たとえば、両方のキャッシュ値をパブリックに設定してPDFファイルのダウンロードを許可する必要がある場合があります。

<cachePragmaHeader>no-cache
</cachePragmaHeader>

<cacheControlHeader>no-cache
</cacheControlHeader>

<ipValidation>

IPアドレス検証はWebgateに固有のもので、シングル・サインオン用に生成されるObSSOCookie(10g Webgate)またはOAMAuthnCookie(11g Webgate)に格納されるIPアドレスとクライアントのIPアドレスを同じにするかどうかを決定するために使用されます。

<ipValidation>0</ipValidation>

<ipValidationExceptions>

IPアドレス検証の例外。

<ipValidationExceptions>
<ipAddress>10,11,11,11</ipAddress>
<ipAddress>10,11,11,12</ipAddress>
<ipAddress>10,11,11,13</ipAddress>
</ipValidationExceptions>

<logOutUrls>

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Oracle Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

- 一致する場合、Webgateログアウト・ハンドラが起動します。

- ログアウトURLが構成されていない場合、「ログアウト」のリクエストURLが確認され、見つかった場合(「logout.gif」および「logout.jpg」を除く)にもログアウト・ハンドラが起動します。

注意: これは、最初のログアウトをトリガーするために使用される標準OAM 10g Webgate構成パラメータです。

関連項目: OAM 11gに登録されるOAM 10g Webgateのログアウトを構成する手順は、第15章を参照してください。

<logOutUrls>
<url>/logout1.html</url>
<url>/logout2.html</url>
</logOutUrls>

<logoutCallbackUrl>

11gリクエストのみ

コールバック中にCookieを消去するoam_logout_successのURL。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。次に例を示します。

/oam_logout_success

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAM 11gサーバーは、コールバックURLを再構築することなく直接コールバックします。

関連項目: OAM 11g Webgateのログアウトを構成する手順は、第15章を参照してください。

<logoutCallbackUrl>/oam_logout_success
</logoutCallbackUrl>

<logoutTargetUrlParamName>

11gリクエストのみ

ログアウト中にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前の値。問合せパラメータには、ログアウトの完了後のランディング・ページのターゲットURLを指定します。

デフォルト: end_url

注意: jps-config.xmlのparam.logout.targeturlによって、end_url値が構成されます。

関連項目: OAM 11g Webgateのログアウトを構成する手順は、第15章を参照してください。

<logoutTargetUrlParamName>end_url
</logoutTargetUrlParamName>

ユーザー定義パラメータの名前

説明

- リモート登録リクエスト・ファイルの構成にのみ使用できます。

- 各パラメータに指定できる値は1つのみです。

- Oracle Access Managerコンソールを使用してユーザー定義パラメータを設定することはできません。

例

<userDefinedParameters>
<userDefinedParam>
<name>...</name>
<value>...</value>
</userDefinedParam>

MaxPostDataLength

POSTデータの長さを決定します。

100未満の値を設定しないことをお薦めします。デフォルトまたは指定された範囲を超える値をこのパラメータに設定すると、POSTデータの長さがデフォルト・サイズの0.75MBに制限されます。

デフォルト: 750000

関連項目: WebgateのIIS Webサーバーの構成の詳細は、第29章を参照してください。

<name>MaxPostDataLength</name>
<value>750000</value>

maxSessionTimeUnits

MaxSessionTimeパラメータをデフォルト(時間単位)のかわりに分数で解釈できます。

一部のファイアウォールは、特定の期間またはアイドル時間にOAMサーバー接続を強制的に切断します。ファイアウォールのタイムアウト設定を変更できない場合、maxSessionTimeUnitsを使用できます。最大クライアント・セッション時間の値を小さくすると、アクセス・クライアントがOAMサーバーの接続を閉じてから再度開く頻度が増えるため、ネットワーク・トラフィックが増加します。そのため、ファイアウォール設定の制限内でできるだけ高いmaxSessionTimeUnits値を指定する必要があります。

デフォルト: hours

使用可能な値: minutes

<name>maxSessionTimeUnits</name>
<value>hours</value>

RetainDownstreamPostData

このユーザー定義パラメータを追加して値をtrueに設定すると、Apache 2.0またはApache 2.2のWebgateでPOSTデータをダウンストリーム・アプリケーションから読み取ることができない場合に発生する問題が解決します。これは、passthroughチャレンジ・パラメータを使用するフォーム・ベース認証スキームと「問合せ文字列変数」オプションを使用するポリシーに影響を与えます。

デフォルト: false

<name>RetainDownstreamPostData
</name>
<value>false</value>

useIISBuiltinAuthentication

エージェントがインストールされているOAMサーバーでMicrosoft PassportまたはIntegrated Windows Authenticationを使用する場合は、trueに設定します。これはIISのみに使用され、Webgateが他のタイプのWebサーバーにインストールされている場合には無視されます。

デフォルト: false

<name>useIISBuiltinAuthentication
</name>
<value>false</value>

idleSessionTimeoutLogic

10g Webgateのみ

リリース7.0.4のWebgateは、独自のアイドル・セッション・タイムアウトのみを強制していました。

10.1.4.0.1 Webgateは、トークンが訪問したすべてのWebgateの中で、最も制限の多いタイムアウト値を強制しました。

10g(10.1.4.3)では、この要素のデフォルトが7.0.4の動作に戻りました。

idleSessionTimeoutLogicを設定する手順

- leastComponentIdleTimeoutのデフォルト値は、アイドル・セッション・タイムアウトの施行に最も制限されているタイムアウト値を使用するようWebgateに指示します。

- currentComponentIdleTimeoutの値は、アイドル・セッション・タイムアウトの施行に現在のWebgateのタイムアウト値を使用するようWebgateに指示します。

name>idleSessionTimeoutLogic
</name>
<value>leastComponentIdleTimeout
</value>

URLInUTF8Format

Oracle HTTP Server 2を使用する環境では、このパラメータをtrueに設定してラテン1および他のキャラクタ・セットを表示する必要があります。

デフォルト: true

<name>URLInUTF8Format</name>
<value>true</value>

inactiveReconfigPeriod

共有シークレットは、10g Webgateにのみ適用されます。

構成は、11g Webgateにのみ適用されます。

アイドル状態で、Webgateは、InactiveReconfigPeriod値を使用してOAMサーバーから共有シークレット(構成)を読み取ります。この値が設定されていない場合、更新された共有シークレット(構成)の値が10分後に戻されますが、Webgateは、1分間隔で共有シークレット(構成)の値についてOAMサーバーをポーリングします。

デフォルト: 10(分)

<name>inactiveReconfigPeriod</name>
<value>10</value>

WaitForFailover

10g Webgateのみ

下位互換性の目的でのみ使用され、このパラメータはaaaTimeoutThresholdに置き換えられています。

WaitForFailoverパラメータおよびaaaTimeoutThresholdパラメータは、WebgateおよびOAMサーバー間のTCP/IPタイムアウトを制御します。デフォルト値の-1は、ネットワークのデフォルトTCP/IPタイムアウト値を使用することを意味します。

WaitForFailoverパラメータおよびaaaTimeoutThresholdには、同じ値を使用する必要があります。

<name>WaitForFailover</name>
<value>-1</value>

proxySSLHeaderVar

このパラメータは、Webgateがリバース・プロキシの背後にあり、クライアントとリバース・プロキシの間でSSLが構成されており、リバース・プロキシとWebサーバーの間で非SSLが構成されている場合に使用します。これにより、URLがHTTPではなくHTTPSとして格納されます。プロキシを使用すると、クライアント接続にSSLと非SSLのどちらを使用するかを示すカスタム・ヘッダー変数を設定して、URLがhttps形式で格納されます。ProxySSLHeaderVarパラメータの値はプロキシが設定する必要のあるヘッダー変数の名前を定義します。ヘッダー変数の値は"ssl"または"nonssl"であることが必要です。ヘッダー変数が設定されていない場合、SSL状態は現在のWebサーバーのSSL状態によって決まります。

デフォルト: IS_SSL

<name>proxySSLHeaderVar</name>
<value>IS_SSL</value>

client_request_retry_attempts

WebgateとOAMサーバーのタイムアウトしきい値は、接続不可能とみなして新しい接続のリクエストを試みるまでの、WebgateがOAMサーバーを待機する時間(秒単位)を指定します。

これは、10gおよび11g Webgate (OAMエージェント)とOAM 11gの接続で同じです。

OAMサーバーでリクエストの処理に要する時間が、タイムアウトしきい値の値よりも長い場合、OAMエージェントはリクエストを中止して新しい接続のリクエストを再試行します。

接続プール設定によっては、接続プールから戻される新しい接続が同じOAMサーバーの接続になる場合があります。OAMエージェントは、使用可能な場合にプライマリOAMサーバーを最初に試行し、使用可能な場合にセカンダリOAMサーバーを次に試行します。

また、他のOAMサーバーでは、タイムアウトしきい値で指定された時間よりもリクエストの処理時間が多く必要になる場合があります。場合によっては、OAMサーバーが停止するまで、OAMエージェントがリクエストを再試行することがあります。

OAMエージェントがclient_request_retry_attemptsパラメータを使用して応答しないサーバーに実行する再試行の回数の制限を構成できます。

値を-1に設定する(または何も設定しない)と、再試行が無制限に許可されます。

<name>client_request_retry_attempts
</name>
<value>1</value>

ContentLengthFor401Response

すべての401レスポンスのContent-Lengthを設定するには、次のユーザー定義パラメータおよび値を追加します。ContentLengthFor401Response 0。

ゼロ(0)は、使用できる唯一の値です。他の値は無視されます。このパラメータおよび値を使用しないと、コンテンツおよびコンテンツ長が一致しないことがあります。これにより、ブラウザにデータが表示されない場合やエラー・メッセージが表示される場合があります。

<name>ContentLengthFor401Response
</name>
<value>0</value>

SUN61HttpProtocolVersion

SUN v6.1 Webサーバーでは、POSTデータを読み取った後にリダイレクトの問題が発生する場合があります。keepAlive(HTTP/1.1)プロトコルを使用して接続している場合、データが正しくフラッシュされません。そのため、リダイレクションが連続して機能しない場合があります。

1.0の値を割り当てると、SUN 6.1 Webサーバーで強制的にHTTP/1.0プロトコルを使用できます。

デフォルト: 1.0

1.0以外の値は無視されます。

<name>SUN61HttpProtocolVersion
</name>
<value>1.0</value>

UseWebgateExtForPassthrough

このIIS Webサーバー固有のパラメータは、ワーカー・プロセス分離モードのIIS v6およびv7でのみ使用されます。

デフォルト: false

ワーカー・プロセス分離モードで実行しているIISバージョン6.xおよびIIS 7.xでは、次の場合に値をtrueに設定します。

- パススルー機能の実行

- フォーム・ログイン(フォーム・ログイン・アクションが/access/oblix/apps/webgate/bin/webgate.dll以外の場合)

注意: ISAPIフィルタとして構成する以外に、ISAPI拡張機能としてwebgate.dllを構成する必要もあります。第29章を参照してください。

付記: IIS 5.0分離モードで実行されているIIS 5.0またはIIS6.0の場合、このパラメータを定義しないでください(またはfalseに設定してください)。この場合、postgate.dllをISAPIフィルタとして構成し、パススルー機能を実行する必要があります。詳細は、「POSTデータのパススルー機能の有効化」を参照してください。

<name>UseWebgateExtForPassthrough
</name>
<value>false</value>

syncOperationMode

デフォルト: false

<name>syncOperationMode</name>
<value>false</value>

filterOAMAuthnCookie

11gリクエストのみ

trueに設定すると、OAMAuthnCookieが常にフィルタ処理され、ダウンストリーム・アプリケーションにアクセスできなくなります。

デフォルト: true

<name>filterOAMAuthnCookie</name>
<value>true</value>

帯域外登録レスポンスについて

リクエストされた操作の実行後、帯域内の管理者は、追加処理のために次のファイルを帯域外の管理者に送信します。

- 帯域外の管理者がそのまま使用する必要があるagentName_Response.xml。
agentName_Response.xmlを開いたり編集したりしないことが推奨されているため、表示されません。

- 帯域外の管理者がWebサーバーの更新に使用する必要がある固有のWebサーバー構成ファイル。

登録ツールの取得および設定

オペレーティング・システムのoamregスクリプトを取得および更新するには、次の手順を使用できます。

Windowsの場合: oamreg.bat

Linuxの場合: oamreg.sh

登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを更新します。

注意:
最新のバンドル・パッチを適用し、再度RREG.tar.gzを解凍して、最新のツールとファイル・リリースを使用することをお薦めします。

リモート登録には、JAVA_HOMEおよびOAM_REG_HOMの2つの変数が必要です(表10-7を参照してください)。

表10-7 リモート登録に必要な変数

ロケーション

変数

説明

クライアント側

JAVA_HOME

環境にすでに設定されている$JAVA_HOMEに基づくコンピュータのJDK 1.6の場所。

OAM_REG_HOME

絶対表記したRREG HOMEのファイルの場所(RREG.tarを展開したディレクトリに/rregを続けた位置で、かつスクリプトが置かれている場所のすぐ上のディレクトリ)。

たとえば、次のようになります。

<OAM_HOME>/oam/server/rreg/client/rreg

IM_ORACLE_HOMEがMW_HOME/Oracle_IDMの場合:

export OAM_REG_HOME=MW_HOME/Oracle_IDM/oam/server/rreg

rregフォルダの場所(RREG.tar.gzの場所ではなく)

JAVA_HOME

環境にすでに設定されている$JAVA_HOMEに基づきます。

OAM_REG_HOME

インストール中にスクリプトにすでに設定されています。

関連項目:
「リモート登録ツールについて」

環境変数を使用してツールを取得し、スクリプトを更新する手順

1. 次のパスのRREG.tar.gzファイルを探します。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. RREG.tar.gzファイルを解凍すると、必須のツールとテンプレートを含むディレクトリが/clientの下に作成されます。

3. oamregスクリプト(.../rreg/client/rreg/bin)で、環境変数を次のように設定します。

1. JAVA_HOMEをJDK 1.6に設定します(表10-7)。

2. OAM_REG_HOMEを、環境変数に基づいてexploded_dir_for_RREG.tar/rregに設定します(クライアント側またはサーバー側、表10-7)。

4. 「登録リクエストの作成」に進みます。

登録リクエストの作成

登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを作成するには、次の手順を使用できます。

関連項目:

- 「リモート登録ツールについて」

- 「リモート登録リクエスト・ファイルについて」

登録リクエストを作成するには、次の手順を実行します。

1. 登録するエージェントに必要な*Request*.xml入力ファイルを探します(表10-1)。

ORACLE_HOME/oam/server/rreg/input

2. リクエスト・ファイルを新しい名前でコピーします。次に例を示します。
コピー元: OAMRequest.xml
コピー先: myagent_request.xml

3. リクエスト・ファイルで、このエージェントの詳細を反映する情報および保護するリソースを変更します(表10-4および表10-6)。

4. 次に進みます。

- 帯域内リモート登録の実行

- 帯域外リモート登録の実行

帯域内リモート登録の実行

この項では、帯域内リモート登録の実行に使用できる手順を説明します。

前提条件

- 登録ツールの取得および設定

- 登録リクエストの作成

ネットワーク内のリモート登録を実行するには、次の手順を使用できます。

注意:
この場合、ネットワーク内の管理者は、すべてのタスクを実行します。リソースを保護するOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)の使用の有無に関係なく、タスクは同じです。

この例は、Linuxシステムの短い登録リクエストを使用したOAMエージェントの登録を示しています。または、Oracle Access Managerコンソールを使用してエージェントを登録し、アプリケーション・ドメインを追加できます(第9章および第13章を参照してください)。

帯域内リモート登録を実行するには、次の手順を実行します。

1. エージェントをホストしているコンピュータで、登録コマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
./bin/oamreg.sh inband input/myagent_request.xml

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
帯域内登録プロセスが正常に完了しました。

固有の構成ファイルの場所が出力フォルダに作成されます。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

4. 出力フォルダのエージェント用に作成した固有の構成ファイルのObAccessClient.xmlを確認し、まだ置換されていない場合は以前のエージェント構成ファイルを置換します。

5. エージェント登録を完了します。このエージェント登録を完了するには、次の手順を実行します。

関連項目:
第27章「OAM 11gによるOAM 10g Webgateの管理」

1. ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml

11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)、次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1/
config/OHS/ohs1/webgate/config

2. OAMエージェントをホストしている管理対象サーバーを再起動します。

6. 「リモート登録およびリソース保護の検証」に進みます。

帯域外リモート登録の実行

この項では、ネットワーク内外の管理者が連携してリモート・エージェントを登録し、デフォルトのアプリケーション・ドメインを設定してリソースを保護する手順を説明します。

前提条件

- 登録ツールの取得および設定

- 登録リクエストの作成

注意:
この場合、帯域内の管理者および帯域外の管理者は、異なるタスクを実行します。エージェント・タイプ(OAMエージェントまたはOSSOエージェント(mod_osso))にかかわらず、タスクは同じです。

次の手順は、LinuxシステムのみにOAMエージェントを登録する手順を示しています。

- 帯域内は、ネットワーク内のWebサーバー管理者が実行するタスクを示します。

- 帯域外は、ネットワーク外のWebサーバー管理者が実行するタスクを示します。

帯域外リモート登録を実行するには、次の手順を実行します。

1. 帯域外の管理者: starting_request.xmlファイルを作成して、処理するために帯域内の管理者に送信します(「登録リクエストの作成」を参照してください)。

WLS_Home/Middleware/Oracle_IDM1/oam/server/rreg/client/rreg/output/agentName/starting_request.xml

2. 帯域内の管理者の手順:

1. 登録コマンドを実行し、入力ファイルとして帯域外の管理者のstarting_request.xmlを指定します。次に例を示します。
./bin/oamreg.sh outofband input/starting_request.xml

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージを参照して確認します。
成功: 登録プロセスが正常に完了しました。

Response.xmlの場所が入力フォルダに作成されます。

入力フォルダは、RREG.tar.gzが展開されている場所(/rreg/input/AgentName/)にあります。

4. 他のアーティファクトとともにagentName_Response.xmlファイルを帯域外の管理者に戻します。次に例を示します。
agentName_Response.xml

3. 帯域外の管理者: 次のように環境を更新します。

1. エージェントをホストしているコンピュータで、リモート登録コマンドを実行し、入力ファイルとして受け取ったagentName_Response.xmlを指定します。次に例を示します。
./bin/oamreg.sh outofband input/agentName_Response.xml

ObAccessClient.xmlおよびcwallet.sso(11gエージェント用)が出力フォルダ/rreg/output/AgentName/に生成されます。

2. ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml

11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)。次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1/
config/OHS/ohs1/webgate/config

3. OAMエージェントをホストしているWebサーバーを再起動します。

4. 「リモート登録およびリソース保護の検証」に進みます。

リモート登録およびリソース保護の検証

この項の内容は次のとおりです。

- リモート登録の検証

- リモート登録後の認証、リソース保護およびアクセスの検証

リモート登録の検証

エージェント・タイプに関係なくエージェントおよびアプリケーションの登録を検証するガイドとして、次の手順を使用できます。

Oracle Access Managerコンソールを使用してタスクを実行するには、帯域内の管理者であることが必要です。帯域外の管理者は、リモートの認証およびアクセスをテストする必要があります。

関連項目:

- 第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」

- 第13章「リソースを保護してSSOを有効化するポリシーの管理」

エージェントおよびアプリケーション登録を検証するには、次の手順を実行します。

1. エージェント登録: Oracle Access Managerコンソールの「システム構成」タブのエージェント詳細を確認します(第9章を参照してください)。

- OAMエージェント: WebgateとOAMサーバー間の通信をブートストラップするために変更されたObAccessClient.xmlがWebgateインストール・ディレクトリにあることを確認します。
Webgate_install_dir\access\

- OSSOエージェント: 変更されたosso.confがエージェントのWebサーバーと同じディレクトリにあることを確認します。これを使用して、OSSOエージェントとOAMサーバー間の通信をブートストラップします。

2. 共有コンポーネント、ホスト識別子: ホスト識別子がOracle Access Managerコンソールに定義されていることを確認します。

3. アプリケーション・ドメイン: 「ポリシー構成」タブで、登録されたエージェントに基づいて名付けられた新しいデフォルトのアプリケーション・ドメインがあることを確認します。

4. アプリケーション・ドメインのリソースは、ホスト識別子に関連付けられます。

5. 「リモート登録後の認証、リソース保護およびアクセスの検証」に進みます。

リモート登録後の認証、リソース保護およびアクセスの検証

登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。

ここでの手順は、登録、認証および認可が適切に構成および動作していることを確認するいくつかの方法を示しています。手順は、OAMエージェント(Webgate)およびOSSOエージェント(mod_osso)でほとんど同じです。

帯域外の管理者がこれらの検証を行うことをお薦めします。

登録後に認証およびアクセスを確認するには、次の手順を実行します。

1. 登録されたOAMエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。

http://myWebserverHost.us.abc.com:8100/resource1.html

2. ログイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「ログイン」をクリックします。

3. OAM固有のCookieがブラウザ・セッションに作成されていることを確認します。次に例を示します。
ObSSOCookie

Set-Cookie:
ObSSOCookie=GGVEuvjmrMe%2FhbItbjT24CBmJo1eCIfDIwQ1atdGdnY4mt6kmdSekSFeAAFvFrZZZ
xDfvpkfS3ZLZFbaZU2rAn0YYUM3JUWVYkYFwB%2BBK7V4x%2FeuYHj%2B8gwOyxhNYFna3iSx1MSZBE
y51KTBfsDYOiw6R%2BCxUhOO8uZDTYHI3s0c7AQSyrEiQTuUV3nv1omaFZlk1GuZa4J7ycaGbIUyqwX
rM0cKuBJNd6sX1LiRj9HofYQsvUV7ToqeAOpDS7z9qs5LhqU5Vq60bBn12DTX6zNX6Lcc0L5tVwvh7%
2BnOAkz2%2BoDkLs%2BBTkeGcB3ppgC9;httponly; path=/; domain=.us.oracle.com;

OAM_ID Cookie

Set-Cookie:
OAM_ID=v1.0~0~E1EBBC9846E09857060A68E79AEEB608~AA79FC43C695162B6CDE3738F40E94DA
6408D58B879AC3B467EBBD4800743C899843672B3511141FFABCF58B2CDCB700C83CC734A913625
7C4ABDA6913C9EF5A4E05C5D03D3514F2FECACD02F1C1B9314D76B4A68CB7A8BE42AEB09AFB98B8
EB; path=/; HttpOnly

4. 次の作業を実行します。

- 成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。詳細な検証については、手順5から12に進みます。

- 失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。

- ログイン・エラー: 有効なユーザーIDおよびパスワードが入力されていることを確認します。

- 使用不能なリソース: リソースが使用できることを確認します。

- 不正なリダイレクトURL: Oracle Access ManagerコンソールのリダイレクトURLを確認します。

5. ユーザー・バリエーション: ユーザー・バリエーションで手順1から4を再実行して、適切な動作(認可ユーザーの成功または未認可ユーザーの失敗)を確認します。

6. リクエストの取消し: 部分的なログインを実行し、「取消」をクリックしてリソースにアクセスしていないことを確認します。

7. 変更された認証URL: 手順1から5を実行して適切なレスポンスを確認する場合、ほとんど同じ認証URLを入力します。たとえば、1文字をURL文字列に追加します。

8. 更新されたリソース: 次の手順を実行して、リソースにアクセスできることを確認します。次に例を示します。
元のリソース: /abc/test.html

更新されたリソース: /abc/xyz/test.html

Oracle WebLogic Serverを再起動しない場合

- 更新されたリソースにアクセスし、ユーザーが認証を求められ、リソースにアクセスできることを確認します。

- 元のリソースにアクセスし、リソースにアクセス可能で、ユーザーが認証を求められていないことを確認します。

9. 様々なURLパターン: 手順1から5を実行する場合、様々なURLパターンの認証を確認します。

10. 新しい認証スキーム: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。

- 異なる認証スキームを使用する新しい認証ポリシーを追加します。

- 新しいポリシーを使用して、リソースを保護します。

- Oracle WebLogic Serverを再起動しないで、手順1から4を実行します。

関連項目:
第13章「リソースを保護してSSOを有効化するポリシーの管理」

11. CGIリソース・ヘッダー変数およびCookie: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。

- 新しい認証ポリシーを追加してCommon Gateway Interface(CGI)リソースを保護し、「認証に成功しました」のレスポンスを設定します。

- 新しいポリシーを使用して、リソースを保護します。

- CGIリソースにアクセスします。

- CGIデータ・ダンプでレスポンスに対して構成されたヘッダー値を確認します。

12. エージェントの無効化: WebgateがObAccessClient.xmlで無効な場合、次の手順を実行して、アクセス可能性および認証を検証します(Webgateは、oam-config.xmlから有効な値を選択する必要があります)。

- エージェント(OAMエージェント(Webgate)またはOSSOエージェント(mod_osso))を無効化します。WebサーバーおよびOAMサーバーを起動します。OAMエージェントで保護されたアプリケーションにアクセスして、認証が求められていることを確認します。

リモート管理モードの概要

ここでは、次の内容について説明します。

- リモート・エージェント管理モードについて

- リモート・アプリケーション・ドメイン管理モードについて

- <rregApplicationDomain>要素について

リモート・エージェント管理モードについて

いくつかのリモート管理モードで、管理者は既存のエージェント登録を更新、検証または削除できます。表10-8に、リモート・エージェント管理モードを示します。コマンドのパラメータには、モード、入力*Request.xmlファイル(OAM_REG_HOMEに対する相対パス、入力*Request.xmlファイルの優先ロケーション)が含まれます。

./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value

表10-8 リモート・エージェントとポリシーの更新

モードおよび入力ファイル

説明および構文

agentUpdateモード

OSSOUpdateAgentRequest.xml

OAM11GUpdateAgentRequest.xml

OAMUpdateAgentRequest.xml

管理者がエージェント属性を更新できます。

./bin/oamreg.sh agentUpdate input/OAM11GUpdateAgentRequest.xml

agentValidateモード

入力ファイルは不要です。

エージェントがOracle Access Manager 11gですでにプロビジョニングされているかどうかを検証します。

./bin/oamreg.sh agentValidate agentname

agentDeleteモード

入力ファイルは不要です。

管理者がエージェント登録を削除できます。

./bin/oamreg.sh agentDelete agentname

agentUpdateモードのテンプレートについては、次の項を参照してください。

- OSSOUpdateAgentRequest.xml

- OAM11GUpdateAgentRequest.xml

- OAMUpdateAgentRequest.xml

OSSOUpdateAgentRequest.xml

OSSOUpdateAgentRequest.xmlを使用して、特定の値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。

- 変更を追跡する<startDate>yyyy_mm_dd</startDate>要素があります。

- agent_base_url_portを指定する<homeUrl>要素があります。

- <hostidentifier>要素が省略されます。

- <agentbaseURL>要素が省略されます。

関連項目:
要素と値の詳細は、表10-5「リモート登録リクエストのOSSO固有の要素」

図10-2は、OSSOエージェントの更新テンプレートを示しています。

図10-2 OSSOUpdateAgentRequest.xml

「図10-2 OSSOUpdateAgentRequest.xml」の説明

OAM11GUpdateAgentRequest.xml

OAM11GUpdateAgentRequest.xmlを使用して、特定のエージェント更新値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。

- <ipValidation>要素がありますが、<ipValidationExceptions>は省略されます。

- <authCreatePolicy>と、アプリケーション・ドメイン関連の要素が省略されます。

- <hostidentifier>、<virtualhost>、<hostportVariations>の各要素が省略されます。

- <agentbaseURL>要素が省略されます。

- <ssoServerVersion>要素が省略されます。

- <idleSessionTimeout>要素が省略されます。

関連項目:

- 表10-10「<rregApplicationDomain>リモート管理テンプレートの要素」

- 要素と値の詳細は、表10-6「完全なリモート登録リクエストに共通の要素」

図10-2は、OAM 11gエージェントの更新テンプレートを示しています。

図10-3 OAM11GUpdateAgentRequest.xml

「図10-3 OAM11GUpdateAgentRequest.xml」の説明

OAMUpdateAgentRequest.xml

OAMUpdateAgentRequest.xmlを使用して、特定のOAM 10gエージェント更新値をリモート登録ツールoamregに渡します。この更新テンプレートと元のOAM 10gエージェント登録テンプレートの主な違いは、更新テンプレートの次の点にあります。

- <ipValidation>要素がありますが、<ipValidationExceptions>は省略されます。

- <authCreatePolicy>と、アプリケーション・ドメイン関連の要素が省略されます。

- <hostidentifier>、<virtualhost>、<hostportVariations>の各要素が省略されます。

- <agentbaseURL>要素が省略されます。

- <ssoServerVersion>要素が省略されます。

- <idleSessionTimeout>要素が省略されます。

関連項目:

- 表10-10「<rregApplicationDomain>リモート管理テンプレートの要素」

- 要素と値の詳細は、表10-6「完全なリモート登録リクエストに共通の要素」

図10-4は、OAM 10gエージェントのOAMUpdateAgentRequest.xmlを示しています。

図10-4 OAMUpdateAgentRequest.xml

「図10-4 OAMUpdateAgentRequest.xml」の説明

リモート・アプリケーション・ドメイン管理モードについて

Oracle Access Manager 11gには、エージェントを登録または変更せずにアプリケーション・ドメインを管理する2つのモードがあります。

注意:
リモート・アプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。アプリケーション・ドメイン管理の削除は、アプリケーション・ドメインのリモート削除をサポートしていません。アプリケーション・ドメインの削除は手動のタスクであり、Oracle Access Managerコンソールを使用して実行する必要があります。

表10-9に、リモート・アプリケーション・ドメイン管理のモードを示します。ここでもコマンドのパラメータには、モード、OAM_REG_HOMEに対する相対パスを使用する入力*Request.xmlファイル、入力ファイルの優先ロケーションが含まれます。

./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value

表10-9 リモート・アプリケーション・ドメイン管理モード

モード

説明

policyCreate

CreatePolicyRequest.xml

管理者が、エージェントを登録せずにホスト識別子とアプリケーション・ドメインを作成できます。

./bin/oamreg.sh policyCreate input/CreatePolicyRequest.xml

次の機能があります。

- アプリケーション・ドメインの作成

- デフォルトの保護リソース、パブリック・リソース、除外リソースの作成

- ホスト・ポート・バリエーション・リストの作成

- ポリシーの作成

- 問合せ文字列があるリソースの作成

policyUpdate

UpdatePolicyRequest.xml

管理者が、エージェントを更新せずに既存のホスト識別子とアプリケーション・ドメインを更新できます。

./bin/oamreg.sh policyUpdate input/UpdatePolicyRequest.xml

次の機能があります。

- アプリケーション・ドメインの更新

- デフォルトの保護リソース、パブリック・リソース、除外リソースの更新

- ホスト・ポート・バリエーション・リストの更新

- ポリシーの更新

- 問合せ文字列があるリソースの更新

[prompt_flag] value: [-noprompt]

オプション。-nopromptフラグを使用すると、oamregはechoおよびpipeを使用してsystem.inから入力を読み取り、データを渡すことができます。

OAM_REG_HOMEロケーションからの例

(echo username; echo password; echo webgate_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt component.oam.conf

(echo username; echo password; echo webgate_password; echo httpscert_trust_prompt;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo webgate_password; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo webgate_password; echo httpscert_trust_prompt; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

component.oam.config_file

オプション。リモート登録は、URIリストを引数に持つ構成ファイルを受け取ります。component.oam.config_fileには、任意の数の保護URIまたはパブリックURIを含むファイルへのフルパスを定義します。このファイルでは次の構文および形式が使用されていることを確認します。

- 少なくとも1つの保護URIが必要です。

- 1ファイルごとに1つの製品ファミリーのみ指定できます。

- コメントは'#'で始めます。

- キーワード'public_uris': このキーワードに続いて、パブリックURIを1行ごとにリストします。

- キーワード'protected_uris': このキーワードに続いて、保護されるURIを1行ごとにリストします。

注意: 次の形式を使用して、保護ポリシーに対して認証スキームを構成できます(ポリシー名と認証スキーム名はタブ文字で区切る必要があります)。

<Policy Name> 'tab' <Authentication Scheme Name>

次に例を示します。

########################
protected_uris
########################
protected policy1 Basic Over LDAP
/finance/protected1/*
/finance/protected2/*

protected policy2 Client Certificate
/finance/protected3/.../{*.js,*.png,*.gif}

########################
public_uris
########################
/finance/public
/finance/test1/public

詳細は、次を参照してください。

- ポリシー作成のリクエスト・ファイルについて

- ポリシー更新のリクエスト・ファイルについて

- <rregApplicationDomain>要素について

ポリシー作成のリクエスト・ファイルについて

policyCreateモードとCreatePolicyRequest.xmlを使用すると、エージェント登録を作成または更新することなく、次のように情報を作成できます。

- 複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を作成します。

- アプリケーション・ドメインを作成します。

- 複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。

- カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを作成します。

CreatePolicyRequest.xmlファイルのパラメータの一部は新規であり、エージェント登録XMLファイル全体には含まれず、元のエージェント登録ファイルの特定の要素を使用して作成または更新されます。ただし、同じ要素もあります。CreatePolicyRequest.xml固有の主な違いは、次のとおりです。

- 認証および認可のポリシーおよびリソースの要素があります。

- <agentName>要素または関連する要素はありません。

図10-5に、CreatePolicyRequest.xmlを示します。

関連項目:
「<rregApplicationDomain>要素について」

図10-5 CreatePolicyRequest.xml

「図10-5 CreatePolicyRequest.xml」の説明

前述のとおり、CreatePolicyRequest.xmlファイルと、エージェント登録XMLファイル全体には、同じパラメータが多数存在します。CreatePolicyRequest.xmlファイルには、認証および認可のポリシーおよびリソースの要素があります(<agentName>要素はない)。

ポリシー更新のリクエスト・ファイルについて

図10-6に、CreatePolicyRequest.xmlとほぼ同一の、UpdatePolicyRequest.xmlを示します。

図10-6 UpdatePolicyRequest.xml

「図10-6 UpdatePolicyRequest.xml」の説明

UpdatePolicyRequest.xmlにはCreatePolicyRequest.xmlと同じ要素がありますが、<protectedAuthnScheme>要素のみ例外です。UpdatePolicyRequest.xmlを使用して、管理者は次の操作が可能です。

- 複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を更新します。

- アプリケーション・ドメインを更新します。

- 複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。

- カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを更新します。

- 次を含む、カスタマイズしたポリシーを作成します。

- ポリシーの表示名

- ポリシーの説明

- 認証スキーム(認証ポリシーのみ)およびポリシーに関連付けられるリソースのサブセット

<rregApplicationDomain>要素について

この項では、図10-7に示すアプリケーション・ドメインに固有のリモート管理要素について説明します。これらはCreatePolicyRequest.xmlファイルとUpdatePolicyRequest.xmlファイルにあり、説明は表10-10のとおりです。

図10-7 アプリケーション・ドメインのリモート管理要素

「図10-7 アプリケーション・ドメインのリモート管理要素」の説明

関連項目:
リモート登録とリモート管理に共通する要素については、「表10-6 完全なリモート登録リクエストに共通の要素」

表10-10 <rregApplicationDomain>リモート管理テンプレートの要素

リモート管理テンプレートの要素" width="100%">

要素

説明

例

<rregAuthenticationPolicies>
<rregAuthenticationPolicy>

認証ポリシーの名前と説明を指定します(新規作成または既存ポリシーの更新時に使用)。

<rregAuthenticationPolicies>
<rregAuthenticationPolicy>
<name>AuthenticationPolicy1</name>
<description>Authentication policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>

<authnSchemeName>

認証ポリシーで使用する認証スキームを指定します。

<rregAuthenticationPolicies>
.
.
authnSchemeName>LDAPScheme
</authnSchemeName>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>

<uriList>

認証ポリシーを使用する認証を必要とするリソースを識別します。

<rregAuthenticationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>

<rregAuthorizationPolicies>
<rregAuthorizationPolicy>

認可ポリシーの名前と説明を指定します(新規作成または既存ポリシーの更新時に使用)。

<rregAuthorizationPolicies>
<rregAuthorizationPolicy>
<name>AuthorizationPolicy1</name>
<description>Authorization policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies>

<uriList>

認可ポリシーを使用する認可を必要とするリソースを識別します。

<rregAuthorizationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies>

エージェントのリモート管理

ここでは、次の内容について説明します。

- リモート・エージェント更新の実行

- リモート・エージェント検証の実行

- リモート・エージェント削除の実行

リモート・エージェント更新の実行

前提条件

「リモート・エージェント管理モードについて」を確認してください。

エージェント登録をリモートで更新する手順

1. 「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. 次のいずれかのテンプレートを使用して更新リクエストを作成します。

- OSSOUpdateAgentRequest.xmlOSSOUpdateAgentRequest.xml

- OAM11GUpdateAgentRequest.xml

- OAMUpdateAgentRequest.xml

3. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。

./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml

4. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

5. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
agentUpdateプロセスは正常に完了しました。

固有の構成ファイルの場所が出力フォルダに作成されます。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

6. 出力フォルダのエージェント用に作成した固有の構成ファイルのObAccessClient.xmlを確認し、まだ置換されていない場合は以前のエージェント構成ファイルを置換します。

7. エージェント登録の完了: OAMエージェント登録を完了するには、次の手順を実行します。

関連項目:

- 第27章「OAM 11gによるOAM 10g Webgateの管理」

1. ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml

11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)、次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1/
config/OHS/ohs1/webgate/config

2. OAMエージェントをホストしている管理対象サーバーを再起動します。

リモート・エージェント検証の実行

前提条件

「リモート・エージェント管理モードについて」を確認してください。

エージェント登録をリモートで検証する手順

1. 「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントをホストしているコンピュータで、agentValidateモードで次のコマンドを実行します。次に例を示します。

./bin/oamreg.sh agentValidate agentname

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
AgentValidationプロセスは正常に完了しました。

固有の構成ファイルの場所が出力フォルダに作成されます。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

リモート・エージェント削除の実行

前提条件

「リモート・エージェント管理モードについて」を確認してください。

エージェント登録をリモートで削除する手順

1. 「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントをホストしているコンピュータで、agentDeleteモードで次のコマンドを実行します。次に例を示します。

./bin/oamreg.sh agentDelete agentname

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
AgentDeleteプロセスは正常に完了しました。

エージェントを使用しないアプリケーション・ドメインの作成または更新

前提条件

「リモート・アプリケーション・ドメイン管理モードについて」を確認してください。

エージェントを使用しないアプリケーション・ドメインを作成または更新する手順

1. 「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. 次のいずれかのテンプレートを使用してポリシー更新リクエストを作成します。

- ポリシー作成リクエスト・ファイル

- ポリシー更新リクエスト・ファイル

3. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
作成する場合:

./bin/oamreg.sh policyCreate input/CreatePolicyRequest.xml

更新する場合:

./bin/oamreg.sh policyUpdate input/UpdatePolicyRequest.xml

4. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

5. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
agentUpdateプロセスは正常に完了しました。

固有の構成ファイルの場所: ...が出力フォルダ...に作成されました。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

第IV部

Oracle Access ManagerのSSO、ポリシーおよびテストの管理

第III部は、Oracle Access Managerを使用したシングル・サインオン(SSO)およびOracle Access Managerポリシーとログアウトの構成方法の理解に役立つ情報を提供します。シングル・サインオン接続およびポリシーのテストも説明します。

第III部は、次の章で構成されています。

- 第11章「OAMポリシー・モデルおよびシングル・サインオンの概要」

- 第12章「ポリシー・コンポーネントの管理」

- 第13章「リソースを保護してSSOを有効化するポリシーの管理」

- 第14章「アクセス・テスターを使用した接続とポリシーの検証」

- 第15章「OAM 11gの集中ログアウトの構成」

11 OAMポリシー・モデルおよびシングル・サインオンの概要

ログインは、ユーザーの認証および目的のアプリケーションへのアクセスを取得するアクションです。シングル・サインオン(SSO)はOracle Access Managerによって有効化されるので、追加または別のログインで同じユーザー・セッションの実行中に他のアプリケーションにアクセスする必要がなくなります。

この章では、ポリシーおよびそれらに必要なコンポーネントを開発する前の基盤を構築するOracle Access Manager 11gシングル・サインオンの概要を示します。この章の内容は次のとおりです。

- 前提条件

- OAM 11gポリシー・モデルとOAM 10gモデルの比較

- OAM 11gポリシー・モデルの概要

- OAMシングル・サインオンの構成の概要

- SSOコンポーネントの概要

- OAM 11gシングル・サインオンの実装タイプの概要

- OAM 11g SSO処理の概要

注意:
特に指定のないかぎり、この章の情報は、OAMエージェントおよびOSSOエージェントで同じです。
シングル・ログアウトの詳細は、第15章「OAM 11gの集中管理ログアウトの構成」を参照してください。

前提条件

少なくとも2つの登録されたエージェントを含む完全に機能するOracle Access Manager 11gシステムが必要です。

この項では、この章のタスクのナレッジ・ベースの要件を示します。

- エージェント登録フォームの詳細は、第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」を参照してください。

OAM 11gポリシー・モデルとOAM 10gモデルの比較

Oracle Access Manager 11gは、Oracle Access ManagerおよびOSSO 10gのポリシー・モデルを簡易性、柔軟性および今後の成長経路を提供する単一のモデルに抽出します。

表11-1は、OAM 11gポリシー・モデルと他のモデルを比較しています。

表11-1 OAM 11gポリシー・モデルとOAM 10gの比較

ポリシーの要素

OAM 11gポリシー・モデル

OAM 10gポリシー・モデル

ポリシー・オーサリング

Oracle Access Managerコンソール

OAMポリシー・マネージャ

ポリシー・ストア

データベース

LDAPディレクトリ・サーバー

ドメイン

アプリケーション・ドメイン

ポリシー・ドメイン

リソース

1. URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。

2. 機能が制限された次のパターン一致
' * 'および'...'がサポートされます。

3. リソースをドメイン間で一意にする必要はありません。

4. HTTP URLの問合せ文字列保護。

5. 各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。

6. 特定の操作を定義することなく、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。

7. リソースは、「保護」、「非保護」または「除外」として指定されます。

1. URL接頭辞がドメインに定義されます。

2. 次のパターン一致
{ } * …

3. リソースをドメイン間で一意にする必要はありません。

4. URL問合せ文字列の内容またはHTTP操作(あるいはその両方)に基づいて、httpリソースを保護できます。

5. HTTP以外のリソース・タイプおよび操作を定義できます。

ホスト識別子

1. ホスト識別子はポリシーの外部で定義され、HTTPリソースの定義中に使用されます。

2. ホスト識別子は、HTTPリソースの定義において必須です。

1. ホスト識別子はポリシーの外部で定義され、HTTPリソースの定義中に使用されます。

2. HTTPリソースの定義において、システムに定義済のホスト識別子がなくなるまでは、ホスト識別子は必須ではありません。

ポリシー

1. 認証ポリシーには、リソース、成功レスポンスおよび認証スキームが含まれます。

2. 認可ポリシーには、成功レスポンスと時間ベース、IPベースおよびユーザーベースの制約も含めることができます。

3. 1つの認証ポリシーおよび認可ポリシーのみをリソースに関連付けることができます。

4. 認証および認可ポリシーを成功または失敗で評価できます。

5. クエリー・ビルダーおよびLDAPフィルタのサポート(特定の表示タイプの属性に基づく一致を取得する場合など)はありません。

6. アプリケーション・ドメインにデフォルト・ポリシーの概念はありません。ただし、決められた範囲内のデフォルト・ポリシーとして使用できるリソースのポリシー/…/*を定義できます。

7. トークン発行ポリシーは、リソースおよびユーザー・ベースまたはパートナに基づく制約を使用して定義できます。「トークン発行ポリシーについて」を参照してください。

1. 認証ポリシーは単純で、認証スキーム・ベースのルールのみを含みます。

2. 1つのリソースを一連の認可ポリシーに関連付けることができます。これらのポリシーの評価は、必要に応じて論理演算子を使用してセット内のポリシーをまとめた式に基づくことができます。
また、1つのリソースを複数の認証ポリシーおよび認可ポリシー・セットに関連付けることもできます。ただし、1つのセットにのみ適用されます。

3. 認可ポリシーは、成功、失敗または未確定に評価できます。

4. LDAPフィルタを使用して、ユーザーを指定できます。

5. デフォルトの認証ポリシーおよび認可ポリシー・セットをポリシー・ドメインに定義できます。ドメインでランタイム・リソースに適用される他のポリシーが存在しない場合にのみ、このポリシーが適用されます。

6. トークン発行ポリシーのサポートはありません。

レスポンス

1. 認証および認可の成功レスポンスをポリシー内に定義できます。これらはポリシーの評価後に適用されます。

2. Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。

3. URLリダイレクトを設定できます。

4. レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。

1. 認証および認可レスポンスを成功、失敗および未確定イベントでポリシー内に定義できます。これらはポリシーの評価後にコール元に戻されます。

2. HTTP_HEADERおよびCookieベースの変数を設定できます。

3. 認証および認可ポリシー評価の成功および失敗イベントにリダイレクトURLを設定できます。

4. レスポンス値には、リテラル文字列およびユーザー属性値のリストを含めることができます。

認証スキーム

認証スキームはグローバルに定義され、認証ポリシー内で参照できます。

信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。

注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表12-3「認証スキームの定義」を参照してください。

認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。

Cookie

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」

問合せ文字列ベースのHTTPリソース定義

アクセス・ポリシーでサポートされています。

ポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。

ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。

関連項目: 表13-1「リソース定義の要素」

OAM 11gポリシー・モデルの概要

この項では、Oracle Access Manager 11gポリシー・モデルおよびそのグローバル共有コンポーネントを説明します。

Oracle Access Manager 11gポリシー・モデルは、OAMアプリケーション・ドメインのコンテキスト内で認証および認可サービスをサポートします。ポリシー・モデルは、全体のシステム構成の一部である外部ユーザー・アイデンティティ・ストアおよび認証モジュールに基づいています。

注意:
以前のリリースのOracle Access Managerでは、OAMポリシー・ドメインのコンテキスト内で認証および認可サービスを提供していました。OracleAS SSO 10gは認証のみ提供します。

図11-1は、Oracle Access Manager 11gのポリシー・モデル内の様々な要素を示しています。

関連項目:
「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」

図11-1 Oracle Access Manager 11gポリシー・モデルおよび共有コンポーネント

「図11-1 Oracle Access Manager 11gポリシー・モデルおよび共有コンポーネント」の説明

アプリケーション・ドメインおよびポリシー

Oracle Access Manager 11gポリシー・モデルの最上位レベルの構造は、OAMアプリケーション・ドメインです。各アプリケーション・ドメインは、リソースおよびアクセス可能なユーザーを指示する関連付けられた認証および認可ポリシーの論理コンテナを提供します。

アプリケーション・ドメインのサイズおよび数は、管理者が個々のアプリケーション・リソースまたは必要に応じてその他の論理グループに基づいて決定できます。アプリケーション・ドメインは、エージェント登録時に自動的に作成されます。また、管理者はアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを追加することにより、同じエージェントを使用して複数のアプリケーション・ドメインを保護できます。詳細は、次の項目を参照してください。

- アプリケーション・ドメインおよびポリシーについて

- リソースおよびリソース定義について

- 認証ポリシー、レスポンスおよびリソースについて

- 認可ポリシー、リソース、制約およびレスポンスについて

関連項目:

- 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」

共有ポリシー・コンポーネント

1つ以上のアプリケーション・ドメインで使用できるグローバル・ポリシー・コンポーネント。次の各項目で詳細情報を提供します。

- リソース・タイプについて

- ホスト識別子について

- 認証、スキームおよびモジュールについて

リソース・タイプについて

リソース・タイプは、保護されるリソースの種類を示します。

単一のリソース・タイプを使用して、各リソースを定義します。ただし、リソース・タイプを使用して任意の数のリソースを定義できます。

保護するリソースをアプリケーション・ドメインに追加する前に、*their*リソース・タイプを定義する必要があります。管理者は通常デフォルトのリソース・タイプHTTPを使用しますが、HTTP以外のタイプを定義できます。

リソース・タイプおよび管理の詳細は、「リソース・タイプの管理」を参照してください。

関連項目:

- 「TokenServiceRPタイプのリソースの管理」

ホスト識別子について

ホストに複数の名前を指定できます。OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。

表11-2は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。

表11-2 ホスト識別子の例

ホスト識別子

説明

hrportal.intranet.company.com

従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。

hr-sf-02.intranet.company.com

直接アクセスできるアプリケーションをホストする単一のマシン。

hrportal.company.com

以前の従業員の福利厚生や企業年金情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。

OAMを使用すると、すべての使用可能なバリエーションが一緒に格納されます。管理者は、ホストの正規の名前およびユーザーがホストを表現できる他のすべての名前を入力します。リストのアドレスに送信されるリクエストは、公式のホスト名にマップされます。

ホスト識別子はエージェントの登録中に自動的に作成され、新しいアプリケーション・ドメインのリソース定義とデフォルトの認証および認可ポリシーをシードするために使用されます。また、管理者は1つ以上のアプリケーション・ドメインで使用されるホスト識別子の定義を作成できます。

アプリケーション・ドメインの認証および認可ポリシーは、ホスト識別子に基づいてリソースを保護します。ホスト識別子を使用して実行時にリソースまたはアプリケーションを識別し、設計時にアプリケーション・リソースのポリシーを作成できます。

詳細は、「ホスト識別子について」を参照してください。

関連項目:
エージェントおよびアプリケーションの登録の詳細は、次の章を参照してください。

- 第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

認証、スキームおよびモジュールについて

認証は、ユーザーを証明するプロセスです。Oracle Access Managerを使用したユーザーのアイデンティティの認証は、事前定義セットのプロセスを実行したユーザーのデジタル・アイデンティティの確認を示します。

1つの認証スキームにのみ、各認証ポリシーを割り当てることができます。ただし、1つの認証スキームを複数の認証ポリシーに割り当てることができます。

1つの認証ポリシーにより、多くのリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。

次の項を参照してください。

- 認証スキームおよびモジュールについて

- 認証イベントのロギングおよび監査

認証スキームおよびモジュールについて

OAMを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールに基づいています。

認証スキーム: ユーザーの認証に必要なチャレンジ・メカニズム、信頼レベルおよび基礎となる認証モジュールを定義する名前の付いたコンポーネント。このスキームに関する一般的な情報も含まれています。認証スキームはグローバルに定義されるため、少人数のセキュリティ管理者が一貫性のあるセキュアな方法で定義できます。Oracle Access Manager 11gには、いくつかの認証スキームがデフォルトで提供されています。

認証モジュール: 認証スキームの実行可能な最小の単位。いくつかの事前定義モジュールが用意されています。各モジュールには、標準プラグインが含まれます。認証モジュールは、準拠する正確な手順および資格証明にユーザーを要求する方法を決定します。これらのモジュールの詳細は、「認証モジュールの管理」を参照してください。

詳細は、「認証スキームの管理」を参照してください。

マルチレベル認証: Oracle Access Manager 11gを使用すると、管理者は異なる認証レベルを別の認証スキームに割り当てて、任意のアプリケーションを保護するスキームを選択できます。機密性の高いアプリケーションにユーザー証明書、機密性の低いアプリケーションにユーザー名およびパスワードが必要になる場合があります。たとえば、レベル2として定義されたBasic Over LDAP認証スキームがあるリソースへのアクセス権を付与されているユーザーは、それ以下のレベルのスキームがある他のリソースにアクセスできます。これに対して、ユーザーがより厳格な認証チャレンジ(レベル5のクライアント証明書と呼ばれるスキームなど)のあるリソースにアクセスしようとする場合には、再認証を受けることが必要です。

Windows固有の認証: 統合されたWindows固有の認証がOSSOおよびWebgateで保護されたアプリケーションでサポートされます(『Oracle Fusion Middleware Oracle Access Manager統合ガイド』を参照してください)。

他の認証タイプ: 次のようなOracle Fusion Middlewareアプリケーションに必要な認証機能がサポートされます。

- 一般的にユーザー名およびパスワードを使用して証明書を使用しない弱い認証

- サード・パーティのセルフサービス・ユーザー・プロビジョニングの自動ログイン

- ユーザー・コンテキスト情報のHTTPヘッダー・サポート。たとえば、ホスト識別子を使用してリソースのホスト・コンテキストを作成します。これは、異なるコンピュータで同じURLパスを使用するリソースを追加する場合に役立ちます。

2つのWebGateの異なる認証スキームを使用する場合、ユーザーは再認証なしで高い認証スキームから低い認証スキームに移行できますが、低い認証スキームから高い認証スキームには移行できません。

注意:
シングル・サインオンの実行中、ユーザーの認証テストに成功する場合がありますが、2番目または3番目のリソースにアクセスすると認可テストに失敗する場合があります。ドメインの各リソースに一意の認可ポリシーが存在する場合があります。

Oracle Access Manager11gを使用した認証スキームの構成および使用の詳細は、「認証スキームの管理」を参照してください。

認証イベントのロギングおよび監査

管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。認証するユーザーに関して収集される情報は、次のとおりです。

- IPアドレス

- ユーザー・ログインID

- アクセス時間

ロギング(または監査)中、ユーザー情報およびユーザー機密属性は記録されません。誤用を避けるためにセキュアなデータ(ユーザー・パスワードなど)が削除されます。

関連項目:

- 第22章「コンポーネント・イベント・メッセージのロギング」

- 第24章「管理および実行時イベントの監査」

認証中にいくつかのモニタリングおよび診断メトリックが収集されます。詳細は、第25章「Oracle Access Managerコンソールを使用したパフォーマンスの監視」を参照してください。

アプリケーション・ドメインおよびポリシーについて

明示的にアクセスを許可するポリシーでリソースが保護されない場合、OAM 11gのデフォルトの動作でアクセスが拒否されます。一方で、明示的にアクセスを指定したルールまたはポリシーでリソースが保護されなかった場合、OAM 10gのデフォルトの動作でアクセスが許可されていました。

Oracle Access Manager 11gポリシー・モデルを使用すると、特定のリソースのアクセスを認可される認証ユーザーと認可されないユーザーを区別するアプリケーション・ドメインを定義する場合にリソースにアクセスできるユーザーを制御できます。

ブラウザへのURLの入力、アプリケーションの実行、他の外部ビジネス・ロジックの呼出しなど、ユーザーがアプリケーション・ドメインで保護されるリソースにアクセス可能ないくつかの方法があります。ユーザーがアプリケーション・ドメインで保護されるリソースへのアクセスをリクエストすると、認証および認可のドメインのポリシーに応じてリクエストが評価されます。

アプリケーション・ドメインは、柔軟な方法でリソースおよびポリシーを論理的にグループ化します。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。アプリケーション・ドメインは、相互に階層の関係がありません。

アプリケーション・ドメイン内で、各リソースを制御するポリシーとともに特定のリソースが識別されます。認証および認可ポリシーには、成功した評価に適用される管理者が構成するレスポンスが含まれます。認可ポリシーには、評価の実行方法を定義する管理者が構成する制約が含まれます。

各アプリケーション・ドメインには、一意の名前を使用する必要があります(簡単な説明はオプションです)。管理者がリソースおよびポリシーを定義できるリソース・コンテナおよびポリシー・コンテナで各ドメインがシードされます。

リソースおよびリソース定義について

リソースは、サーバーに格納されて多くのユーザーがアクセスできるドキュメント、エンティティまたは内容の一部を表します。クライアントは、特定のプロトコル(HTTPやHTTPSなど)を使用してサーバーと通信し、既存のリソース・タイプで定義されているリソースをリクエストします。

注意:
ページの内容の一部を保護するには、Oracle Entitlements Serverの使用をお薦めします。

Oracle Access Managerを使用する場合、リソース定義がアプリケーション・ドメイン内に作成されます。各リソースがURLパスとして定義されます。各HTTPリソース・タイプをホスト識別子に関連付ける必要があります。ただし、HTTP以外のリソース・タイプ(HTTP以外のリソース)は、ホスト識別子ではなく特定の名前と関連付けられます。

注意:
アプリケーション・ドメイン内で定義されたリソースのみ、アプリケーション・ドメインに定義されたポリシーに関連付けることができます。

詳細は、「ポリシーで使用するリソース定義の追加および管理」を参照してください。

認証ポリシー、レスポンスおよびリソースについて

認証は、ユーザーを証明するプロセスです。ユーザーを認証するため、Oracle Access Managerは、ユーザーのブラウザに認証資格証明のリクエストをチャレンジ形式で示します。チャレンジは、チャレンジ・メソッドと呼ばれます。

管理者は、アプリケーション・ドメイン内に1つ以上の認証ポリシーを作成して、特定のリソースをそのドメイン内に適用できます。

注意:
エージェント・タイプに関係なく、認証がOAM 11g認証ポリシーによって行われます。

認証ポリシーの評価

認証ポリシーでは、指定されたリソースのアクセスを提供する必要があるユーザーの認証に使用される認証方式を指定します。ポリシーは、リソース・アクセスを保護する方法を定義します。

ポリシーが評価された後、次の2つの標準アクションが実行されます。

- 結果が戻されます。

- リクエストしたURL(成功した場合の許可)または一般エラー・ページのURL(失敗した場合の拒否)のいずれかの結果に基づく内容がユーザーに示されます。
結果は、ポリシーごとに上書きできます。

SSOのポリシー・レスポンス

管理者が定義するポリシー・レスポンスは、前述の内容以外に実行されるオプションのアクションを宣言します。ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、特定の順序でURLにリダイレクトすることでアプリケーションのデータの経路を提供していたOAM 10gよりも堅牢で柔軟性が高くなります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。

注意:
管理者がポリシー・レスポンスを構成し、同じアプリケーション・ドメイン内で定義される特定のリソースに適用する必要があります。

詳細は、「アプリケーション・ドメインおよびポリシーの詳細分析」を参照してください。

認可ポリシー、リソース、制約およびレスポンスについて

認可は、ユーザーにリクエストしたリソースのアクセス権があるかどうかを決定するプロセスです。

管理者は、1つ以上の認可ポリシーを作成して、リソースにアクセスできるサブジェクトまたはアイデンティティの条件を指定できます。ユーザーは、データの表示やポリシーで保護されたアプリケーション・プログラムを実行できます。リクエストしたリソースがアプリケーション・ドメインに属し、リクエストしたリソースを特定の認可ポリシーでそのドメイン内で扱う必要があります。

注意:
OracleAS SSO 10gでは認可を実行しません。OSSOエージェントはOAM 11g認可ポリシーを使用しません。

SSOの認可レスポンス

管理者が定義するポリシー・レスポンスは、前述の内容以外に実行されるオプションのアクションを宣言します。ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、特定の順序でURLにリダイレクトすることでアプリケーションのデータの経路を提供していたOAM 10gよりも堅牢で柔軟性が高くなります。

詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。

認可制約

認可制約は、リソースのリクエストのコンテキストに基づいて特定のリソースのアクセスを付与または拒否するルールです。認可制約により、リクエストに対する認可の成功または失敗が決定されます。

管理者は、認可ポリシーに割り当てられるリソースに適用される制約を定義する必要があります。詳細は、「認可制約の概要」を参照してください。

認可ポリシーの評価

認可ポリシーの評価は、成功(許可)または失敗(拒否)の2つの結果のいずれかになります。ポリシー評価のデータが不十分な場合、常に結果が失敗になります。たとえば、アクセスを許可する前にユーザーがグループのメンバーであることを制約で確認しますが、グループがLDAPに実際に存在しない場合は失敗の結果になります。

詳細は、「特定のリソースの認可ポリシーの定義」を参照してください。

OAMシングル・サインオンの構成の概要

OAM 11g SSOの概要を説明するため、次のタスクの概要にOAM 11gを使用したシングル・サインオンの構成方法および特定のタスクに関連する追加情報の場所をまとめます。

タスクの概要: OAM 11gを使用したシングル・サインオンの構成

1. 次の項を確認してください。

- OAM 11gポリシー・モデルとOAM 10gモデルの比較

- OAM 11gポリシー・モデルの概要

- SSOコンポーネントの概要

- OAM 11gシングル・サインオンの実装タイプの概要

- OAM 11g SSO処理の概要

2. アプリケーションのドキュメントを使用して、各パートナ・アプリケーションのシングル・サインオン・ログアウトURLを構成します。

3. 保護するアプリケーションをホストしている各WebサーバーのOAMポリシー施行エージェントをインストールします。

- 第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

注意:
OAM 11gでエージェントを登録すると、基本ポリシーでシードされるデフォルトのホスト識別子およびアプリケーション・ドメインが自動的に作成されます。

4. 「リソース・タイプの管理」の手順に従って、使用できる目的のリソース・タイプを確認します(またはリソース・タイプを作成します)。

5. 次の項の手順に従って、適切な認証モジュールおよびスキームを使用していることを確認します。

- 「認証モジュールの管理」

- 「認証スキームの管理」

6. 「ホスト識別子の管理」の手順に従って、エージェントに基づく名前が付けられたホスト識別子の定義が自動的に作成された(またはホスト識別子の定義を作成した)ことを確認します。

7. 第13章「リソースを保護してSSOを有効化するポリシーの管理」の手順に従って、リソース定義を追加し、アプリケーション・ドメインのOAM 11gポリシーを構成します。

関連項目:
必要に応じて次のトピックを参照してください。

- 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」

- 「TokenServiceRPタイプのリソースの管理」

8. 「SSOエンジン」を構成します(「SSOトークンとIPの検証の管理」を参照してください)。

9. 「グローバル・サインオンおよび集中管理ログアウトの検証」の手順に従って、構成を検証します。

SSOコンポーネントの概要

この項では、Oracle Access Manager 11gを使用するシングル・サインオンの簡単な概要を説明します。内容は次のとおりです。

- シングル・サインオン・コンポーネントについて

- ユーザー・ログイン時のシングル・サインオンCookieについて

- シングル・サインオンCookieについて

シングル・サインオン・コンポーネントについて

この項では、シングル・サインオンのOracle Access Manager 11gポリシーを実装および施行する主要コンポーネントを説明します。

表11-3に、主要なシングル・サインオン・コンポーネントをまとめます。

表11-3 OAM 11g SSOおよびOSSO 10gコンポーネントの概要

コンポーネントの説明

OAM 11g

OSSO 10g

サーバー

注意: 管理外ユーザーは、SSOログイン・ページを戻すパートナ・アプリケーションのURLを入力して、シングル・サインオン・サーバーに最初にアクセスします。関連項目: 「OAM 11g SSO処理の概要」

- OAMサーバー

- WebLogic管理サーバーにインストールされるOracle Access Managerコンソール

注意: 管理ユーザーは、https://host:port/oamconsoleのURLを入力して、コンソールのホームページにアクセスできます。関連項目: 「Oracle Access Managerコンソールのログインおよびサインアウト」

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

関連項目: 『Oracle Application Server Single Sign-On管理者ガイド』

プロキシ

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

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

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

ポリシー施行エージェント

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

- 11g OAMエージェント(Webgate)

- 10g OAMエージェント(Webgate/アクセス・クライアント)

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

- mod_osso(パートナ)
注意: mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。

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

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

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

ポリシー・ストア

データベース

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

パートナ・アプリケーション

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

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

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

注意: OAM 11gでmod_ossoを登録した後、mod_ossoは認証をOAMに委任します。

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

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

SSOエンジン

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

OAMエージェントを使用する場合

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

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

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

パートナ・キー

- 11gエージェントの登録中、エージェントのパートナ・キーが生成され、OAMサーバーとも共有されます。
キーは、SSO Cookieの暗号化および復号化に使用されます。

- 10gエージェントの登録中、グローバル共有秘密鍵がすべてのOAM 11g(すべてのWebgateおよびOAMサーバー)で生成されます。

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

サーバー・キー

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

- OSSOサーバー固有のキー

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

キーの格納

- エージェント側: エージェント固有のキーがOracle Secret Storeにローカルに格納されます。

- OAM 11gサーバー側: エージェント固有のキーおよびサーバー・キーがサーバー側のJavaキーストアに格納されます。

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

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

Cookie

関連項目: 「シングル・サインオンCookieについて」

ホストベースの認証Cookie

- 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>
注意: 有効なOAMAuthnCookieがセッションに必要です。

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

- OAMサーバーに1つ: OAM_ID

- ホストベースの認証Cookie
パートナごとに1つ: OHS-host-port

OSSOサーバーに1つ: (OAM 11gでは適用されません)

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

ポリシー

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

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

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

クライアントIP

- このクライアント・エージェントを保持し、ホストベースCookieの11g Webgate用のOAMAuthnCookie(または10g Webgate用のObSSOCookie)に使用します。

- ホストCookie内の元のクライアント・エージェントを含めます。
後の認証リクエストでCookieが示される場合、元のクライアントIPとプレゼンタのIPが比較されます。

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

関連項目:
「OAM 11g SSO処理の概要」

ユーザー・ログイン時のシングル・サインオンCookieについて

表11-4は、ユーザー・ログインの実行中に設定または消去できるCookieを示しています。

表11-4 SSO Cookie

ユーザー・ログインで設定されるSSO Cookie

設定元

説明

OAM_ID Cookie

OAM 11gサーバー

OAMサーバーでのみ認識されるキーで保護されます。

ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。

- Cookieが存在しない場合、ユーザー認証が開始されます。認証に成功した後、ユーザー・コンテキストおよびトークンがSSOエンジンによって設定されます。Cookieは、グローバル・ユーザーID(GUID)、作成時間およびアイドル・タイムアウトの詳細で設定されます。Cookieの情報はSSOサーバー・キーで暗号化され、SSOエンジンでのみ復号化できます。

- Cookieが存在する場合、Cookieが復号化され、サインインのフローが認証されたユーザーで終了します。

OAMAuthnCookie

11g Webgate

アクセスする各11g Webgateによって設定されます。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。有効なOAMAuthnCookieがセッションに必要です。

注意: 異なる11g Webgateで保護されるアプリケーションにユーザーがアクセスする場合、複数のOAMAuthnCookieを使用します。「11g OAM WebgateのOAMAuthnCookie」を参照してください。

ObSSOCookie

10g Webgate

10g Webgateにアクセスする場合のみ、10g WebgateのドメインベースCookieが設定されます。OAMサーバーでのみ認識されるキーで保護されます。すべてのWebgateに対して1つのグローバル共有秘密鍵です。

注意: このCookieは、OAM 11gと古いエージェント間の下位互換性および相互運用性を有効化します。

OAM_REQ

OAM 11gサーバー

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

OAMRequestContext

11g Webgate

11g Webgateによって設定または消去される一時的なCookie。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。

注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

OHS-host-port

Oracle HTTP Server

Oracle HTTP Server(OHS)でOSSOエージェント(mod_osso)にアクセスする場合のみ設定されます。mod_ossoエージェントおよびOAMサーバーで認識されるキーで保護されます。「mod_osso Cookie」を参照してください。

注意: このCookieは、OAM 11gと古いエージェント間の下位互換性および相互運用性を有効化します。

GITO Cookie

OAM 11gサーバー

OSSO 10gおよびOAM 11gの間の下位互換性および相互運用性を提供します。このCookieはOAMサーバーによって作成され、OAMサーバーまたはmod_ossoエージェントによってアクセスまたは変更されます。

認証および認可ポリシーの構成の詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。

シングル・サインオンCookieについて

- 11g OAM WebgateのOAMAuthnCookie

- 10g OAM WebgateのObSSOCookie

- OAM_REQのCookie

- mod_osso Cookie

11g OAM WebgateのOAMAuthnCookie

認証の成功後にOAMサーバーから受け取った認証トークンを使用して各11g Webgateで設定された1つのOAMAuthnCookie_<host:port>_<random number>があります。有効なOAMAuthnCookieがセッションに必要です。

SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーおよびWebgate間の通信について」を参照してください。

Cookieの有効期間: 11g WebgateおよびOAMAuthnCookieでは、有効なトークン(またはCookie)時間を制御する「tokenValidityPeriod」パラメータで有効期間が管理されます。

このキーは、11g WebgateおよびSSOエンジンで識別され、OAMAuthnCookieの暗号化に使用されます。SSOエンジン・キー(SSOエンジンでのみ識別)は、OAM_ID OAMサーバーCookieの暗号化に使用されます。

次に説明するObSSOCookieと似ています。

10g OAM WebgateのObSSOCookie

Oracle Access Manager 11gは、10g Webgateで保護されるリソースにアクセスする各ユーザーまたはアプリケーションのキーベースCookieのObSSOCookieを設定します。エージェントの登録中にキーが設定され、エージェントおよびSSOエンジンで識別されます(両方で共有されます)。このキーは、OAMサーバー(またはSSOエンジン)キーとは異なります。

ObSSOcookieを削除すると10g Webgateからユーザーがログアウトするので、アクセス・システムで保護されるリソースを次にリクエストするときにユーザーの再認証が必要になります。

Webgateでは、認証が成功すると、ユーザーのブラウザにObSSOCookieを送信します。すると、このCookieが、今度は、それ以下のレベルの認証を必要とする他の保護リソースに対する認証メカニズムとして機能します。ユーザーがブラウザまたは別のリソースへのアクセスをリクエストすると、リクエストがOAMサーバーに送信されます。ユーザーがログインして、ObSSOCookieが設定されます。OAMサーバーは、ObSSOCookieを含むURLを使用したセッション・トークンを生成します。認可資格証明を供給するようユーザーに要求せずにCookieが以降の認可に使用されることで、シングル・サインオンが機能します。

Cookieが生成されると、Cookieの一部が暗号化されたセッション・トークンとして使用されます。シングル・サインオンCookieには、ユーザー名やパスワードなどのユーザー資格証明は含まれていません。

SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーおよびWebgate間の通信について」を参照してください。

Cookieの有効期間: 管理者は、OAMエージェント登録の目的のCookieセッション時間を指定できます。詳細は、「コンソールを使用したOAMエージェントの登録および管理」を参照してください。

OAM_REQのCookie

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用してリクエスト・キャッシュ・タイプをBASICからCOOKIEに変更する必要があります。

注意:
Oracle共通ホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

関連項目:

- 「WLSTコマンドの実行」

- 表11-4「SSO Cookie」

mod_osso Cookie

mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onで保護されるアプリケーションを有効化してユーザー名およびパスワードのかわりにHTTPヘッダーを受け入れるOracle HTTP Serverにこのモジュールが存在します。これらのヘッダーの値がmod_osso Cookieに格納されます。

アプリケーション・サーバーに格納されるmod_ossoは、シングル・サインオン・サーバーの唯一のパートナ・アプリケーションとして認証プロセスを簡易化します。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。ユーザーの認証後、mod_ossoは、ユーザーの認可にアプリケーションで使用される可能性のある単純なヘッダー値を送信します。

GITO Cookie: 複数のタイプのエージェント(mod_ossoおよびWebgate)がOAM 11gで動作している場合のタイムアウトをサポートする特別な状況に必要です。サーバー側のセッション・マネージャは、セッションの検証中に有効期間およびタイムアウトのCookieの妥当性を確認できます。エンティティのセッションのログアウトでログアウトがすべてのエンティティに伝播していることを確認するには、OSSOエージェント(mod_osso)のグローバル・ログアウトが必要です。

ユーザーがOSSO 10gで認証される場合、OSSOサーバーはGITO Cookieを設定します。パートナCookie(OHS Cookie)が設定されると、OHSはサーバーのリクエストをルーティングしません。かわりに、OHSはアクセスごとにGITO Cookieを暗号化し、最後のアクティビティのタイムスタンプを更新します。リクエストの処理中に、現在の時間がGITOタイムアウト(最終アクティビティ時間 + GITOタイムアウト)を超えたことをパートナが検出すると、リクエストが強制認証モードでOSSO 10gに送信されます。リクエストが強制認証モードでOSSOサーバーに達すると、サーバーはSSO_ID Cookieを無視して、新しいリクエストとして資格証明のユーザーを要求します。認証に成功した後、SSO_IDおよびGITO Cookieが更新されます。

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスに従ってeditGITOValues WLSTコマンドを使用すると有効になります。

OssoSecureCookiesディレクティブ: OssoSecureCookiesディレクティブを追加して、すべてのCookieのSecureフラグを設定します。これにより、HTTPSで保護された接続のCookieのみの送信がブラウザに通知されます。mod_osso構成(mod_osso.conf)のこのディレクティブの例は、次のとおりです。

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoSecureCookies on
OssoConfigFile osso/osso.conf
<Location /j2ee/webapp>
require valid-user
AuthType Basic
</Location>
</IfModule>

詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。

OAM 11gシングル・サインオンの実装タイプの概要

この項では、様々なシングル・サインオンの実装タイプの次の内容を説明します。

- アプリケーションのSSO

- OAM 11gを使用したシングル・サインオン

- ネットワーク間ドメインおよびOracle Access Manager 11g

アプリケーションのSSO

Oracle Access Managerにより、管理者は、ユーザーの資格証明が一度確認されてからユーザーが実行する各アプリケーションに提供される信頼網を構築できます。これらの資格証明を使用すると、固有のメカニズムによるユーザーの再認証をアプリケーションで実行する必要がありません。

アプリケーションのシングル・サインオンにより、Oracle Access Managerで認証されたユーザーは再認証を実行することなくアプリケーションにアクセスできます。

ユーザーの資格証明を送信するには2つの方法があります。

- Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。

- ヘッダー変数の使用: エージェントのリクエストで設定され、アプリケーションで参照できるHTTPヘッダー。

注意:
両方のフォームで、管理者はポリシー内の適切なレスポンスを入力する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。

ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、OAM 11gに登録されたエージェントで保護されるWebサーバーにのみ適用できます。OAMで保護されないWebサーバーでホストされているリダイレクトURLがポリシーに含まれる場合、ヘッダー・レスポンスは適用されません。

たとえば、ユーザーを認証する場合、ポータル索引ページにリダイレクトすることがあります。

http://mycompany.com/authnsuccess.htm

認証に失敗すると、認証アクションによってユーザーがエラー・ページまたは自己登録スクリプトにリダイレクトされる場合があります。

http://mycompany.com/authnfail.htm

OAM 11gを使用したシングル・サインオン

この項では、OAM 11gを使用したシングル・サインオン処理を説明します。

関連項目:
「OAM 11g SSO処理の概要」

Oracle Access Managerは、Oracle Identity Federation以前の独自の複数のネットワーク・ドメインSSO機能を提供します。これがOAM 10gデプロイメントで実装される場合、OAM 11gにOAM 10gエージェントを登録してこのサポートを継続できます。

混在リリース・エージェントを使用したSSO

Oracle Access Manager 11gにエージェントを登録した後、OAMサーバーは、OAM 10g、11gエージェントおよび10g OSSOエージェント(mod_osso)の任意の組合せのシームレスなサポートを提供します。

リバース・プロキシSSO

シングル・サインオン構成のリバース・プロキシを使用する場合、IPvalidationパラメータをfalseに設定するか、Webgate登録でプロキシIPアドレスをIPValidationExceptionsリストに追加してください。その他の場合は、リバース・プロキシによってクライアントのIPアドレスは隠されます。

認証に成功した後、リバース・プロキシが10g Webgate ObSSOCookieをOracle WebLogicに渡さない場合があります。この問題を回避するため、Oracle WebLogicでリバース・プロキシを使用するときは、Basic Over LDAPではなくフォーム・ベース認証を使用してください。11g Webgateでは、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie(デフォルトはtrue))を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。Cookieを渡す場合は、パラメータをfalseに設定します。

複数のWebLogicサーバー・ドメインSSO

OAM 11gは、複数のWebLogic管理ドメインのSSOをサポートします。様々なシステム管理者の責任、アプリケーションの境界またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義できます。一方で、1つのドメインを使用して、すべてのWebLogic Server管理アクティビティを集中管理できます。

注意:
クラスタ内の管理対象サーバーはすべて、同じドメイン内にある必要があり、クラスタを複数のドメインにまたがって分割することはできません。ドメイン内の管理対象サーバーはすべて、同じバージョンのOracle WebLogic Serverソフトウェアを実行していることが必要です。管理サーバーは、ドメイン内の管理対象サーバーと同じバージョンか、それ以降のサービス・パックを実行できます。

WebLogic管理ドメインには、次の2つの基本タイプがあります。

- 管理対象サーバーを使用するドメイン: 単純な本番環境は、アプリケーションをホストする複数の管理対象サーバーを使用するドメイン、および管理操作を実行する管理サーバーで構成できます。この構成では、アプリケーションおよびリソースは個々の管理対象サーバーにデプロイされ、同様に、アプリケーションにアクセスするクライアントは個々の管理対象サーバーに接続します。
向上したアプリケーションのパフォーマンス、スループットまたは可用性を必要とする本番環境では、クラスタとして2つ以上の管理対象サーバーを構成する場合があります。クラスタリングにより、複数の管理対象サーバーをホスト・アプリケーションおよびリソースの1つの単位として操作できます。スタンドアロン管理対象サーバーおよびクラスタ管理対象サーバーの違いの詳細は、管理対象サーバーおよびクラスタ管理対象サーバーを参照してください。

- スタンドアロンWebLogic Serverドメイン: 開発およびテスト環境では、本番ドメインのサーバーから個別に単一のアプリケーションおよびサーバーをデプロイできます。この場合、管理サーバーとして動作し開発中のアプリケーションもホストする単一のサーバー・インスタンスを構成する単純なドメインをデプロイできます。WebLogic Serverでインストールできるexamplesドメインは、スタンドアロンWebLogic Serverドメインの例です。

クラスタ内の管理対象サーバーはすべて、同じドメイン内にある必要があり、クラスタを複数のドメインにまたがって分割することはできません。ドメイン内の管理対象サーバーはすべて、同じバージョンのOracle WebLogic Serverソフトウェアを実行していることが必要です。管理サーバーは、ドメイン内の管理対象サーバーと同じバージョンか、それ以降のサービス・パックを実行できます。

各ドメインの構成は個別の構成ファイル(config.xml)に保存され、このファイルは他のファイル(ログ、セキュリティ・ファイルなど)とともに管理サーバーに保存されます。管理サーバーを使用して構成タスクを実行する場合、ユーザーが加えた変更は、その管理サーバーで管理されているドメインにのみ適用されます。別のドメインを管理するには、そのドメインの管理サーバーを使用します。この理由から、1つのドメインのサーバー・インスタンス、アプリケーションおよびリソースは、別のドメインのサーバー、アプリケーションおよびリソースからは独立して扱う必要があります。構成タスクやデプロイメント・タスクを複数のドメインで同時に実行することはできません。

各ドメインには、管理アクティビティを実行する固有の管理サーバーが必要です。Oracle Access Managerコンソールを使用して管理およびモニタリング・タスクを実行すると、ドメインを切り替えることができますが、実行時に異なる管理サーバーに接続します。

複数のドメインを作成した場合、各ドメインは固有のデータベース・スキーマを参照する必要があります。ドメイン間で構成されたリソースまたはサブシステムを共有できません。たとえば、1つのドメインにJDBCデータ・ソースを作成する場合、別のドメインの管理対象サーバーまたはクラスタで使用できません。かわりに、2番目のドメインに類似するデータ・ソースを作成する必要があります。さらに、2つ以上のシステム・リソースに同じ名前を使用できません。

ネットワーク間ドメインおよびOracle Access Manager 11g

OAM 10gとは異なり、OAM 11gは、即時利用可能なネットワーク間ドメインのシングル・サインオンをサポートします。OAM 11gのシングル・サインオフの実行中、次の処理が実行されます。

- 11g OAMサーバーによって設定されるSSO Cookieは、ネットワーク・ドメイン間で動作するホストCookieです。Webgateは、スタンドアロン・エージェントCookieを消去し、セッションを消去するためにOAM 11gサーバーにリダイレクトします。

- スタンドアロン・エージェントCookieを使用しないOAM 10g Webgateの場合、リダイレクトを必要としないサーバー側でのみログアウトが発生します。

- スタンドアロン・エージェントCookieをサポートする11g WebgateおよびOSSOエージェントの場合、エージェント・ログアウト・コールバックURLがパラレルにコールされます。セッションでアクセスするエージェントおよび複数のドメインのエージェントは、ブラウザでサポートされる同時接続の数に応じてすべてパラレルにコールされます。

注意:
標準ベースのマルチプロトコルのネットワーク間ドメインのシングル・サインオンには、Oracle Identity Federationをお薦めします。

OAM 11g SSO処理の概要

この項の内容は次のとおりです。

- SSOログイン処理について

- OAMエージェントを使用したSSOログイン処理について

- OSSOエージェント(mod_osso)を使用したSSOログイン処理について

- 混在リリース・エージェントを使用したシングル・サインオン処理について

SSOログイン処理について

シングル・サインオンのログインおよびログアウト処理は、ユーザーが有効かどうかおよびユーザーの状態が有効または無効かを決定します(ユーザーまたはユーザー・セッションが最初に期限切れになる場合)。セッション管理サポートでは、ユーザー・セッション・コンテキストおよびユーザー・トークンを検索、保持および消去します。

次の各項目で詳細情報を提供します。

- ログイン

- セルフサービス・プロビジョニング・アプリケーションを使用したログイン

- Oracle ADF Securityを使用したアプリケーションのログインおよび自動ログイン

ログイン

ユーザーが保護されたリソースに最初にアクセスする場合、リソースの認証スキームおよびレベルに基づいて資格証明が求められます(通常はユーザーIDおよびパスワードが必要です)。

誤ったユーザーIDまたはパスワードが入力されると、認証に失敗します。この場合、ユーザーは認証されずに、資格証明の別のプロンプトが表示されます。

認証に成功すると、認可ポリシーの確認が実行され、このユーザーに特定のリソースのアクセスが認可されていることを確認します。認可に成功すると、情報がアプリケーションに渡されます。セッションが期限切れになるか、高い認証レベルでリソースをリクエストするまで、ユーザーはサインインを再度求められません。

セルフサービス・プロビジョニング・アプリケーションを使用したログイン

プロビジョニングは、Oracle Access Managerのセッションを作成しません。新しいユーザーがセルフサービス・プロビジョニング・アプリケーションを使用してアカウントを作成すると、アプリケーションにアクセスする場合にユーザーIDおよびパスワードを再度求められます。

保護されたアプリケーションがユーザーの資格証明をリクエストするOracle Access Manager 11gに向けられます。たとえば、Oracle Identity ManagerがOAM 11gで保護されている場合、ユーザー・リクエストが資格証明を入力するリクエストが実行されるOracle Access Managerにリダイレクトされます。

Oracle ADF Securityを使用したアプリケーションのログインおよび自動ログイン

Oracle Platform Security Services(OPSS)は、Oracle WebLogic Serverの内部セキュリティ・フレームワークで構成されます。Oracle WebLogic Serverでは、Oracle Application Development Framework(Oracle ADF)セキュリティを使用し、Oracle Access Manager 11g SSOと統合して、ユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。

詳細は、付録C「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合」を参照してください。

OAMエージェントを使用したSSOログイン処理について

Oracle Access Managerは、アイデンティティの確認に顧客が指定した認証方式で各ユーザーを認証し、ユーザー・アイデンティティ・ストアに格納された情報を利用します。Oracle Access Manager認証では、いくつかの認証方式および様々な認証レベルをサポートします。機密性の程度が異なるリソースは、より厳しい認証方式に対応する高いレベルの認証を要求することで保護できます。

ユーザーが保護されたアプリケーションにアクセスしようとすると、SSO Cookieの有無を確認するOAMがリクエストを受け取ります。

ユーザーを認証してユーザー・コンテキストおよびトークンを設定した後、OAMはSSO Cookieを設定して、SSOエンジンでのみ復号化できるSSOサーバー・キーでCookieを暗号化します。

認証の成功および失敗に応じて指定されるアクション(OAM 11gのレスポンス)によっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。

認可ポリシーおよび確認結果に基づいて、リクエストした内容へのユーザーのアクセスが許可または拒否されます。ユーザーのアクセスが拒否されると、Webgate登録で管理者が指定した別のURLにリダイレクトされます。

図11-2は、ポリシーの評価、ユーザーのアイデンティティの検証、保護されたリソースへのユーザーの認可および保護されたリソースの使用に含まれるプロセスを示しています。この例は、OAMエージェントのフロー(Webgate/アクセス・クライアント10gまたはWebgate 11g)を示しています。11g Webgateでは、少しのバリエーションがあります。

図11-2 OAMエージェントを使用したSSOログイン処理

「図11-2 OAMエージェントを使用したSSOログイン処理」の説明

プロセスの概要: OAMエージェントを使用したSSOログイン処理

1. ユーザーは、リソースをリクエストします。

2. Webgateは、ポリシーを評価するためにリクエストをOAMに送信します。

3. OAM

- SSO Cookieの有無を確認します。

- ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。

4. OAMサーバーは、決定をログに記録して戻します。

5. Webgateは、次のように応答します。

1. 保護されていないリソース: リソースがユーザーに提供されます。

2. 保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。

認証ポリシーに基づくログイン・フォームが提供されます。

認証処理が開始されます。

6. ユーザーは資格証明を送信します。

7. OAMは資格証明を確認します。

8. OAMはセッションを開始し、次のホストベースCookieを作成します。

- パートナごとに1つ: 認証に成功した後にOAMサーバーから受け取った認証トークンを使用して11g Webgateで設定されるOAMAuthnCookie(10g Webgateで設定されるObSSOCookie)。
注意: 有効なCookieがセッションに必要です。

- OAMサーバーに1つ: OAM_ID

9. OAMは成功または失敗をログに記録します。

10. 資格証明コレクタがWebgateにリダイレクトされ、認可処理が開始されます。

11. Webgateは、ポリシーの検索、ポリシーとユーザーのアイデンティティの比較および認可のユーザー・レベルの決定をOAMに求めます。

12. OAMはポリシーの決定をログに記録し、セッションCookieを確認します。

13. OAMサーバーは認可ポリシーを評価し、結果をキャッシュします。

14. OAMサーバーは、決定をログに記録して戻します。

15. Webgateは、次のように応答します。

- 認可ポリシーでアクセスを許可すると、目的の内容またはアプリケーションがユーザーに提供されます。

- 認可ポリシーでアクセスを拒否すると、管理者が決定した別のURLにユーザーがリダイレクトされます。

OSSOエージェント(mod_osso)を使用したSSOログイン処理について

登録されたOSSOエージェント(mod_osso)を使用したSSOログイン処理は、Webgateを使用したログイン処理と似ています。ただし、mod_ossoは、OAM 11g認証ポリシーを使用した認証のみを提供します。

注意:
mod_ossoは、固有の認可またはOAM 11gポリシーを使用した認可をサポートしません。

図11-3は、mod_ossoおよびOAM 11gを使用したログイン処理を示しています。

図11-3 OSSOエージェントを使用したSSOログイン処理

「図11-3 OSSOエージェントを使用したSSOログイン処理」の説明

プロセスの概要: OSSOエージェントを使用したSSOログイン処理

1. ユーザーは、リソースをリクエストします。

2. mod_ossoは、ポリシーを評価するためにリクエストをOAMに送信します。

3. OAM

- SSO Cookieの有無を確認します。

- ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。

4. OAMサーバーは、決定をログに記録して戻します。

5. mod_ossoは、次のように応答します。

1. 保護されていないリソース: リソースがユーザーに提供されます。

2. 保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。

認証ポリシーに基づくログイン・フォームが提供されます。

認証処理が開始されます。

6. ユーザーは資格証明を送信します。

7. OAMは資格証明を確認します。

8. OAMはセッションを開始し、認証トークンをアプリケーションに渡して、次のCookieを作成します。

- パートナごとに1つ: OHS_host_port

- OAMサーバーに1つ: OAM_ID

- グローバル非アクティビティ・タイムアウト: ドメインレベルCookieのGITO

9. OAMは成功または失敗をログに記録します。

10. 資格証明コレクタは、ユーザーの認可にアプリケーションCABで使用できる単純なヘッダー値を送信するmod_ossoにリダイレクトされます。

11. 認証に成功すると、リソースが提供され、OHS-host-port Cookieが設定されます。

混在リリース・エージェントを使用したシングル・サインオン処理について

OAM 11gサーバーは、エージェントのタイプまたはリリースに関係なく類似したSSOランタイム処理を提供します。

12 ポリシー・コンポーネントの管理

共有ポリシー・コンポーネントをOAMポリシーで使用できます。この章では、管理者によるポリシー・コンポーネントの管理方法について説明します。

この章の内容は次のとおりです。

- 前提条件

- ポリシー・コンポーネント管理の概要

- リソース・タイプの管理

- ホスト識別子の管理

- 認証スキームの管理

- 暗号化Cookieのチャレンジ・パラメータの構成

前提条件

Oracle Access Managerコンソールおよび少なくとも1つのOAMサーバーがWebLogicサーバー・ドメインにインストールおよび実行されている必要があります。

この章のアクティビティを実行する前に、次の内容を確認することをお薦めします。

- ポリシー・モデルおよびコンポーネントの詳細は、「OAM 11gポリシー・モデルの概要」を参照してください。

- 現在のポリシー・モデルと他のモデルの比較を確認するには、「OAM 11gポリシー・モデルとOAM 10gモデルの比較」を参照してください。

- Oracle Access Managerコンソールおよびコントロールの詳細は、第3章「共通の管理およびナビゲーションの基礎」を参照してください。

ポリシー・コンポーネント管理の概要

この項では、Oracle Access Manager 11gポリシー・モデルおよびそのグローバル・コンポーネントを説明します。

Oracle Access Manager 11gポリシー・モデルは、OAMアプリケーション・ドメインのコンテキスト内で認証および認可サービスを提供します。ポリシー・モデルは、全体のシステム構成の一部である外部ユーザー・アイデンティティ・ストアおよび認証モジュールに基づいています。

注意:
以前のリリースのOracle Access Managerでは、OAMポリシー・ドメインのコンテキスト内で認証および認可サービスを提供していました。OracleAS SSO 10gは認証のみ提供します。

図12-1は、Oracle Access Manager 11gのポリシー・モデル内の異なる要素を示しています。Oracle Access Manager 11gポリシー・モデルの最上位レベルの構造は、OAMアプリケーション・ドメインです。図の後に詳細があります。

図12-1 ポリシー・コンポーネント: アプリケーション・ドメインとの関係

「図12-1 ポリシー・コンポーネント: アプリケーション・ドメインとの関係」の説明

ポリシー・コンポーネント: アプリケーション・ドメインで使用できるグローバル認証スキーム、リソース・タイプおよびホスト識別子。ポリシー・コンポーネントの管理については、この章全体で説明します。

アプリケーション・ドメイン: リソース(または一連のリソース)および特定のリソースにアクセス可能なユーザーを指示する関連付けられた認証および認可ポリシーの論理コンテナ。アプリケーション・ドメインのサイズおよび数は、管理者に依存します。詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。

リソース・タイプの管理

この項の内容は次のとおりです。

- リソース・タイプおよびその使用について

- リソース・タイプ・ページについて

- 特定のリソース・タイプの検索

リソース・タイプおよびその使用について

リソースをアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択して、特定のURLを入力する必要があります。

Oracle Access Manager 11g (11.1.1.5)では、リソース・タイプを作成/編集/削除するコマンド・ボタンは無効です。Oracle提供のリソース・タイプには、次が含まれます。HTTPタイプ・リソースには、ホスト識別子を含めます。HTTP以外のリソース・タイプには、次のタイプ名を使用します。

- HTTP

- TokenServiceRP

- wl_authen

HTTP: デフォルトのリソース・タイプがHTTPおよびHTTPSプロトコルと一緒に使用されます。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されたポリシーがすべての操作に適用されます。

HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。

wl_authen: WebLogic認証スキームを表すリソース。wl_authenというHTTP以外のリソース・タイプをWebLogicコンテナでデプロイされたリソースとともに使用できます。wl_authenリソース・タイプには、カスタム・アクセス・クライアントが必要です。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。

TokenServiceRP: トークン・サービスのリライイング・パーティを表すリソース。

HTTP以外のリソース・タイプに関連付けられたホスト識別子はありません。HTTP以外のリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。

リソース・タイプ・ページについて

Oracle Access Managerコンソールでは、図12-2に示すように、「ポリシー構成」タブでリソース・タイプが他のコンポーネントとともに編成されます。左側のナビゲーション・ツリーは、インターネット・プロトコルのHTTPおよびWebLogicコンテナにデプロイされたリソースのwl_authenの2つのデフォルトのリソース・タイプを示しています。

図12-2 デフォルトのwl_authenリソース・タイプ定義

「図12-2 デフォルトのwl_authenリソース・タイプ定義」の説明

HTTPリソース・タイプは、Oracle Access Manager 11gで保護されたWebアプリケーションに使用されます。

wl_authenリソース・タイプは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で示すように、Oracle Access Manager 11gおよび次のOAM認証プロバイダ構成のいずれかと組み合せたFusion Middlewareアプリケーション・シナリオで使用されます。

- オーセンティケータ

- Oracle Web Services Managerを使用するアイデンティティ・アサータ

図12-3で説明するように、TokenServiceRPリソース・タイプはトークン・サービス・リライイング・パーティを表すために使用されます。詳細は、「TokenServiceRPタイプのリソースの管理」を参照してください。

図12-3 TokenServiceRP

「図12-3 TokenServiceRP」の説明

表12-1は、各リソース・タイプ定義の要素を示しています。

表12-1 リソース・タイプの定義

要素

説明

名前

必須。最大30文字の英数字の一意の名前。

注意: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。

説明

オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。

たとえば、WebLogic認証スキームを表すリソースなどです。

次に、リソース・タイプの作成、変更および削除方法を説明します。

特定のリソース・タイプの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用してHTTP以外のリソース・タイプを検索できます。

関連項目:
コンソールを使用したポリシー要素検索の実行

リソース・タイプを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「リソース・タイプ」を選択し、検索するリソース・タイプの名前を(ワイルド・カード(*)の使用は任意)入力して、「検索」をクリックします。次に例を示します。

h*

または、目的のアプリケーション・ドメインに移動して、「リソース」ノードを開いてドメインのコントロールを表示し、リストからリソース・タイプを選択してから「検索」をクリックします。

3. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集または表示: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

4. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

ホスト識別子の管理

この項では、ホスト識別子とその使用方法およびホスト識別子の作成、変更または削除方法を説明します。次に内容を示します。

- ホスト識別子について

- 仮想Webホスティングについて

- ホスト識別子ページについて

- ホスト識別子の作成

- ホスト識別子定義の検索

- ホスト識別子定義の表示または編集

- ホスト識別子定義の削除

ホスト識別子について

ポリシーは、コンピュータ・ホストのリソースを保護します。Oracle Access Manager内で、ホスト識別子を使用してコンピュータ・ホストを個別に指定します。

定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。

登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、OAMはリソースを保護するポリシーを適用できます。

Oracle Access Managerコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。

詳細は、次の項を参照してください。

- ホスト識別子の使用方法

- ホスト識別子のガイドライン

- ホスト識別子のバリエーション

ホスト識別子の使用方法

設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(HTTP)またはタイプ(HTTP以外)を使用して、リソースをスコープします。この組合せにより、Oracle Access Managerで一意に識別されます。

注意:
各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。

実行時の使用方法

実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のいずれかの方法でWebサーバー・ホスト情報を取得します。

- 仮想Webホスティング・サポートに優先ホスト・パラメータが構成されている場合(「仮想Webホスティングについて」を参照してください)、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。

- 優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。

これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。

たとえば、aseng-wikiにアクセスするユーザーは、次の内容を入力します。

http://corp-wiki.uk.mycompany.com/mywikipage

この「mywikipage」はリソースURLで、「corp-wiki.uk.mycompany.com」はホストです。このホストおよびポート(ポートは80)を照合して、ホスト識別子を示します。

優先ホスト

通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_nameに設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホスティングについて」を参照してください。

ホストの認証および認証スキームのチャレンジ・リダイレクト

ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。

注意:
認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。

ホスト識別子のガイドライン

各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。

- 各ホスト名を一意にする必要があります。

- 各ホスト名:ポート・ペアを一意にする必要があります。

- 各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。

- 各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。

- ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。

- 各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。

詳細は、「ホスト識別子のバリエーション」を参照してください。

ホスト識別子のバリエーション

すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。Oracle Access Managerで保護する各Webサイトまたは仮想Webサイトにホスト識別子を構成する必要があります。

Oracle Access Managerに対するWebサーバー・ホストの識別には、たとえば、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。Webサーバー・ホストのアドレス指定方法の例を次に示します。

- site.com

- site.com:80

- www.site.com

- www.site.com:80

- 216.200.159.58

- 216.200.159.58:80

仮想Webホスティングについて

複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールできます。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。

注意:
この情報は、11gおよび10g Webgateで共通です。

多くのWebサーバーに対する仮想Webホスティング機能を使用すると、複数のドメイン名およびIPアドレスをサポートでき、各サーバーが単一の仮想サーバー上にある一意の各サブディレクトリに解決されます。たとえば、それぞれ独自のドメイン名と一意のサイト・コンテンツを持つabc.comとdef.comを、同じ仮想サーバー上でホストできます。名前ベースまたはIPベースの仮想ホスティングが可能です。

仮想ホストは、複数のNICカード(IPベース)または複数の名前(同じIPを解決するabc.comやdef.comなど)に基づいて使用される複数のサイトが同じホストに存在する状況を示します。

次に示すように、OAMサーバーのリバース・プロキシとして動作するOHSサーバーに構成される2つの仮想ホストが存在するケースを検討します。

- 1つの仮想ホストが双方向SSLモードで構成されています。

- 1つの仮想ホストが非SSLモードで構成されています。

異なる認証スキームで保護される2つのリソースとアプリケーション・ドメインがあると仮定します。

- /resource1は、チャレンジURL(資格証明コレクションURLを定義するため)のhttps://sslvhost:port/を使用するX509Schemeで保護されます。
ユーザーが/resource1にアクセスすると、認証用のSSLポートのOHSサーバーにリダイレクトされ、X.509証明書を求められます。

- /resource2は、チャレンジ・リダイレクトのhttp://host:port/を使用する2番目の仮想ホストのLDAPSchemeで保護されます。
ユーザーが/resource2にアクセスすると、非SSLモード(または必要に応じて一方向SSLモード)の2番目の仮想ホストにリダイレクトされます。LDAP認証のログイン・フォームが表示されます。

注意:
10g mod_ossoを使用したX.509およびフォーム認証がデプロイメントでサポートされます。ただし、1つのSSOサーバーにのみ、mod_ossoを構成できます。この場合、エージェントは、非SSL仮想ホストのOracle Access Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。

リバース・プロキシの背後へのWebgateの配置

OAM 10g Webgateは、OAM 11gのリバース・プロキシとともに使用できます。この項では、この方針の長所と短所について説明します。

長所:

- リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。
これは、Oracle Access Managerによってサポートされないプラットフォームにも当てはまります。様々なプラットフォーム上(Windows XPやLinuxなど)で、異なるタイプのWebサーバー(iPlanetやApacheなど)が使用されていても、これらのサーバー上のすべてのコンテンツを保護できます。リバース・プロキシはサポートされていないWebサーバーに対する回避策となり、サポートされていないWebサーバーやWebgateをサポートしないプラットフォーム(MacOSなど)用に独自のアクセス・クライアントを記述する必要がなくなります。

- リバース・プロキシを使用することで、アーキテクチャが柔軟になります。
リバース・プロキシを使用すると、イントラネットで使用可能なアプリケーションをデプロイしてエクストラネットに公開できるようになります。また、エクストラネットで使用可能なアプリケーションをイントラネットに公開することもできます。これらのことは、すでにデプロイされているアプリケーションを変更することなく行うことができます。

- リバース・プロキシに1つのWebgateをインストールするのみで、各Webサーバー上にインストールする必要がなくなります。
これによって、管理ポイントが単一になり、システムの管理が容易になります。他のWebサーバーにフットプリントを確保しなくても、リバース・プロキシを経由することで、すべてのWebサーバーのセキュリティを管理できます。

短所: プロキシ使用の主な短所は、設定時に必要な作業が増えることです。リバース・プロキシの背後にあるWebサーバーにWebgateをデプロイする場合は、次の構成要件を満たす必要があります。

- 認証にリバース・プロキシを使用するすべてのWebサーバーが、リバース・プロキシからのリクエストのみを受け付けるようにします。
また、このWebサーバーにデプロイされたWebgateを、Webgateのフロントエンドであるリバース・プロキシ・サーバーからのリクエストに対してIP検証を施行しないように構成する必要もあります。これは、IP検証リストに、リバース・プロキシ・サーバー(1つまたは複数)の既知のIPアドレスを構成することによって行います。WebgateのIP検証を無効にする方法でも同じ結果が得られますが、セキュリティ上のリスクがあるためにお薦めできません。通常は、サーバーにACL文を追加することによって、Webサーバーがリバース・プロキシからのリクエストのみを受け付けるように構成します。これにより、ユーザーがリバース・プロキシをバイパスして制限付きコンテンツに直接アクセスしないようにします。

- Policy Managerに構成された仮想ホストを更新し、アクセス・システムがリバース・プロキシに送信されたリクエストを捕捉できるようにします。

- バックエンド・システムを直接ポイントするURLをユーザーが入力してプロキシを迂回することを防止します。
この問題の発生を防止するには、Webサーバーのアクセス制御リストまたはファイアウォール・フィルタを使用します。

- すべてのユーザー・リクエストがプロキシによって処理されるため、負荷を処理するのに十分な数のプロキシ・サーバーをデプロイする必要があります。

- 既存のすべてのURLをリバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。
このため、リンク切れなどを防ぐため、絶対パスによるHTMLリンクを防止するためのコンテンツの検査および書換えを実行するようにリバース・プロキシを構成することが必要になる場合がよくあります。これはほとんどのリバース・プロキシで可能であり、またアクセス・システムとは無関係に構成できます。

- フロントエンド・アプリーケーションに対して公開するURLリンクには相対URL(../../sub-path/resource)のみを使用し、絶対URL(http://hostname.domain:[port]/path/resource)は使用しないことをお薦めします。
絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。

Apache以外のWebサーバーの仮想ホストの構成

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。たとえば、次に示すように、ユーザーがURLに文字列myweb2を入力したとします。

http://myweb2

Webサーバーで、いずれかのWebサイトのホスト名がmyweb2であれば、その一致する仮想サイトでリクエストが処理されます。

展開された10g Webgate登録ページの「優先ホスト」フィールドで、次のように入力します。

HOST_HTTP_HEADER

IIS仮想ホスティング: IISコンソールから、各仮想Webサイトを構成して次のフィールドを含める必要があります。

- ホスト・ヘッダー名

- IPアドレス

- ポート

関連項目:

- http://www.simpledns.com/kb.aspx?kbid=1149

- http://support.microsoft.com/kb/q190008/

仮想ホスト、ディレクトリまたはファイルとのApache用Webgateの関連付け

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。

注意:
Apacheベースのサーバー以外のホストでは、SERVER_NAMEという値はサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。
「ServerName」ディレクティブは、hostNameとともに明示的に7777に設定する必要があります。これは「Listen」ディレクティブが正しく設定されているかどうかには関係ありません。サーバーは、自己識別のためにこの値を明示的に要求する場合がありますが、通常は自動的に自己識別が可能です。

シングル・サインオンでApacheベースのリバース・プロキシを使用する場合、Webサーバーの構成ファイル(httpd.configなど)でApacheサーバーで実行するWebサイトを指定します。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。Oracle Access Managerをロードする際のhttpd.configファイル内への参照は、特定のサイト、仮想ホスト、ディレクトリまたは個別ファイルに関連した参照のみを行うように制限できます。

Webgateを特定のターゲットに関連付けるには、次のディレクティブをhttp.confファイルに移動します。

AuthType Oblix
require valid-user

これらのディレクティブを、ApacheがリクエストのたびにWebgateを使用するように指示するブロックの中に置きます。また、これらのディレクティブを、Webgateがコールされるタイミングを制限するブロックに移動することもできます。次に、LocationMatchディレクティブを、VirtualHostディレクティブの後に置く例をあげます。

DocumentRoot /usr/local/apache/htdocs/myserver
ServerName myserver.example.net
AuthType Oblix
require valid-user

前述のLocationMatchブロックを次のようにVirtualHostディレクティブの後に移動すると、Webgateはその仮想ホストに対してのみ動作します。LocationMatchブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。

ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
ProxyRequests On
SSLEngine on
SSLCACertificateFile Z:/Apps/sslcert_myapps_ptcweb32/intermediateca.cer
SSLCertificateFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.cer
SSLCertificateKeyFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.key
ErrorLog logs/proxysite1_log
CustomLog logs/proxysite1_log common
ProxyPass /https://apps.example.com/
ProxyPassReverse /https://apps.example.com/
ProxyPass /bkcentral https://apps.example.com/bkcentral
ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
ProxyPass /NR https://apps.example.com/NR
ProxyPassReverse /NR https://apps.example.com/NR

AuthType Oblix
require valid-user

#*** BEGIN Oracle Access Manager Webgate Specific ****

LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebgateInstalldir Z:/apps/Oracle/WebComponent/access
WebgateMode PEER

SetHandler obwebgateerr

SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none

SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK

ホスト識別子ページについて

Oracle Access Managerコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。

管理者はコンソールを使用して、ホスト識別子を作成および管理できます。Oracle Access Managerコンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。

図12-4は、コンソールの通常のホスト識別子構成ページを示しています。ここでは、ホストの正規の名前およびユーザーが同じホストを表現できる他のすべての名前を入力します。

注意:
各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。

図12-4 「ホスト識別子」ページ

「図12-4 「ホスト識別子」ページ」の説明

表12-2は、ホスト識別子の定義を示しています。

表12-2 ホスト識別子の定義

プロパティ

説明

名前

この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。

説明

この構成の使用を示す200文字までのオプションの説明。

操作

- ホスト名: ユーザーがアプリケーションにアクセスする場合に使用する可能性のある様々なホスト名または組合せのリスト。
関連項目: 「ホスト識別子のバリエーション」および「ホスト識別子のガイドライン」

- ポート: 各ホストまたは組合せで使用されるWebサーバー・ポート

ホスト識別子の作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を手動で作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。エージェントの登録時に「ポリシーの自動作成」を選択すると、この作業は自動的に実行されます。

注意:
テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。

関連項目:

- 「ホスト識別子について」

- 「仮想Webホスティングについて」

ホスト識別子を手動で作成するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」を拡張します。

2. 「ホスト識別子」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。
または、「ホスト識別子」ノードを拡張して、テンプレートとして使用する定義の名前をダブルクリックし、「複製」ボタンをクリックしてcopyofnameという名前のコピーを作成します。

3. 「ホスト識別子」ページで、次の内容を入力します。

1. 名前

2. 説明

3. 操作: 「操作」リストのホスト名およびポート・バリエーションを追加(または削除)します。
追加: プラス記号(+)をクリックして、新しいホスト名およびポートの組合せを入力します。

削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。

4. 必要に応じて手順3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。

5. 「適用」をクリックして新しい定義を送信します(または変更を適用しないでページを閉じます)。

6. 確認ウィンドウを閉じて、新しい定義がナビゲーション・ツリーにリストされていることを確認します。

ホスト識別子定義の検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定のホスト識別子を検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

ホスト識別子を検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「ホスト識別子」を選択して、検索を定義します。

3. テキスト・フィールドに検索条件を(ワイルド・カード(*)の使用は任意)入力します。次に例を示します。

my_h*

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集または表示: ツール・バーの「編集」ボタンをクリック(または結果表内の名前をダブルクリック)して、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

ホスト識別子定義の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を変更できます。これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。

前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン

注意:
設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。

関連項目:
「ホスト識別子ページについて」

ホスト識別子を表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

1. 「共有コンポーネント」ノード

2. 「ホスト識別子」ノード

2. 目的の定義名をダブルクリックします。

3. 「ホスト識別子」ページを表示し、必要に応じて情報を変更します(表12-2を参照してください)。

1. 名前

2. 説明

3. 操作: 「操作」リストのホスト名およびポート・バリエーションを追加または削除します。
プラス記号(+)をクリックして、新しいホスト名およびポートの組合せを追加します。

既存のホスト名をクリックし、「削除」ボタンをクリックして削除します。

4. 必要に応じて手順3cを繰り返して、バリエーションを追加または削除します。

5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

6. 確認ウィンドウを閉じて、終了する場合はページを閉じます。

ホスト識別子定義の削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の全体の定義を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。

前提条件

アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、ホスト識別子を使用するアプリケーション・ドメインのリソース定義を最初に変更する必要があります。

関連項目:
既存の定義から単一のホスト識別子を削除する場合は、「ホスト識別子定義の表示または編集」を参照してください。

ホスト識別子を削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

1. 「共有コンポーネント」ノード

2. 「ホスト識別子」ノード

2. オプション: リストで、目的の名前をダブルクリックして定義を表示し、ページを閉じます。

3. ナビゲーション・ツリーで、目的の定義名をクリックします。

4. ツール・バーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。

5. ナビゲーション・ツリーを確認して、定義が削除されたことを確認します。

認証スキームの管理

この項の内容は次のとおりです。

- 認証スキーム・ページについて

- 認証スキームの作成

- 認証スキームの表示または編集

- 認証スキームの検索

- 認証スキームの削除

認証スキーム・ページについて

リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームには、定義済の認証モジュール(「認証モジュールの管理」に示すような標準またはカスタムのモジュール)も含まれている必要があります。

コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインは、デフォルト・スキームとして設定される認証スキームを使用するポリシーでシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。

新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerberosSchemeというスキームをコピーする場合、コピー名はcopyofKerberosSchemeになります。

すべての認証スキームには、異なる値を使用した同じ要素が含まれます。図12-5は、例としてデフォルトのLDAPSchemeページを示しています。「認証スキーム」ナビゲーション・ツリーは、提供される他のデフォルト・スキームを示しています。

図12-5 デフォルトのLDAPSchemeページ

「図12-5 デフォルトのLDAPSchemeページ」の説明

表12-3は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。

表12-3 認証スキームの定義

要素

説明

名前

ナビゲーション・ツリーに表示されるこのスキームの一意の名前。

関連項目: 「事前構成済認証スキーム」

説明

このスキームの使用を示す200文字までのオプションの説明。

認証レベル

認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。

信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。

注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表13-1「リソース定義の要素」を参照してください。

注意: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ以下の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。

関連項目: 「マルチレベル認証について」

デフォルト

「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。

チャレンジ・メソッド

次の選択可能な項目から1つのチャレンジ・メソッドを選択する必要があります。

- フォーム

- Basic(LDAP)

- X509(証明書)

- WNA(Windows固有の認証)

- なし

- DAP

- OAM10g

関連項目: 「チャレンジ・メソッドについて」

チャレンジ・リダイレクトURL

処理するためにユーザー・リクエストを別のサーバーにリダイレクトする場合の「チャレンジ・リダイレクト」フィールドに指定されたサーバーのURL。

関連項目: 「ホスト識別子について」

認証モジュール

ユーザーに資格証明を要求するために使用する事前構成済認証モジュール。

- LDAP(「LDAP認証モジュール」ノードの下)

- LDAPNoPasswordAuthModule

- Kerberosプラグイン(「認証モジュール」の「カスタム認証モジュール」の下)

- LDAPプラグイン(「認証モジュール」の「カスタム認証モジュール」の下)

- X509プラグイン(「X509認証モジュール」ノードの下)

「認証モジュールの管理」も参照してください。

チャレンジ・パラメータ

サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータについて」を参照してください。

フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム

フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、これらの追加要素が含まれます。他のスキームは、変更する必要がないデフォルトを使用します。

チャレンジURL

資格証明コレクションのために資格証明コレクタがリダイレクトするURL。

フォーム・ベースの即時利用可能な認証スキーム(LDAPSchemeおよびLDAPNoPasswordValidationScheme)の場合、デフォルトのチャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。

コンテキスト・タイプ

次の使用可能な値に基づいて資格証明コレクタの最後のURLを作成するために使用されます。

- デフォルト: コンテキスト値を使用して、資格証明コレクションのために送信する最後のURLを作成します。たとえば、チャレンジURLが「/pages/login.jsp」、コンテキスト値が/oamの場合、サーバーが資格証明コレクションのために「/oam/pages/login.jsp」に送信します。

- customWar: カスタマイズされた資格証明コレクタ・ページ「customlogin.jsp」が同じドメイン内のWARファイル(コンテキスト・ルートの「custom」を使用)にデプロイされる場合、資格証明の収集にこの値を使用する必要があります。資格証明を収集するためにサーバーがWebアプリケーション・ページ「/custom/customlogin.jsp」に送信するには、次の値を設定します。
challenge_url = "/customlogin.jsp"
contextType="customWar"
contextValue="/contextroot of custom application"

- customHtml: カスタムHTML資格証明コレクタ・ページ。アプリケーションにアクセスできる場所にこのファイルを配置できます。サーバーがhtmlファイルを読み取ってページをレンダリングするために提供されるカスタム・サーブレットに送信するには、次の値を設定します。
challenge_url = "/CustomReadServlet"
contextType="customHtml"
contextValue="html file location"

- 外部: ログイン・ページが外部の場合、アプリケーションにアクセスできる場所にファイルを配置できます。資格証明コレクションのためにサーバーがチャレンジURL(外部資格証明コレクタ・ページの完全修飾URL)にリダイレクトするには、次の値を設定します。ユーザー名およびパスワードが外部フォーム(HTMLまたはjsp)で収集され、OAMサーバーに送信されます。
challenge_url = "/http://host:port/externallogin.jsp"
contextType="external"
contextValue=Not applicable
関連項目: 「カスタム・ログイン・ページについて」

コンテキスト値

資格証明コレクタの最後のURLを作成するために使用されます。デフォルト値は/oamです。

カスタム・ログイン・ページについて

フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、表12-3の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。

- カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Oracle Access Managerは、2つのフィールドを使用した認証フォームのみサポートします。

- CustomWarおよび外部コンテキスト・タイプでは、次の2つのタスクを実行するカスタム・ログイン・ページ内のロジックが必要になります。

- Oracle Access Managerサーバーから受け取ったページにリクエストIDを送信します。たとえば、String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">などです。

- OAMサーバーにエンド・ポイント「/oam/server/auth_cred_submit」を戻します。たとえば、<form action="/oam/server/auth_cred_submit">または「http://oamserverhost:port/oam/server/auth_cred_submit」などです。

詳細は、次の各項を参照してください。

- 事前構成済認証スキーム

- チャレンジ・メソッドについて

- 認証モジュールについて

- マルチレベル認証について

事前構成済認証スキーム

表12-4は、Oracle Access Manager 11gで使用できる事前構成済認証スキームおよびそれぞれの固有の詳細を示しています。チャレンジ・パラメータの詳細は、表12-5を参照してください。

表12-4 事前構成済認証スキーム

スキーム名

指定

目的

AnonymousScheme

認証レベル: 0
チャレンジ・メソッド: なし
認証モジュール: AnonymousModule

特定のOracle Access Manager URLを保護されていない状態のままにするため、ユーザーは要求なしでURLにアクセスできます。ユーザーが要求されないので、資格証明を入力する必要はありません。

注意: 認証レベル0は、公開ページに使用されます。カスタム認証スキームにレベル0を使用しないことをお薦めします。

付記: リソースがAnonymousSchemeによって保護されている場合、セッション検索では表示されません。

BasicScheme

認証レベル: 1
チャレンジ・メソッド: Basic
認証モジュール: LDAP

ほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

BasicSessionlessScheme

認証レベル: 1
チャレンジ・メソッド: Basic
認証モジュール: LDAP

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

チャレンジ・パラメータ: CookieLessMode=true

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

FAAuthScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP
コンテキスト: customWar
コンテキスト値: /fusion_apps

Fusion Applicationsを保護します。

KerbScheme

認証レベル: 2
チャレンジ・メソッド: WNA
認証モジュール: Kerberos

Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。

LDAPNoPasswordValidationScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAPNoPasswordAuthModule

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

注意: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。

この表の後半の「OAM10gScheme」も参照してください。

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。

WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

LDAPScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。

OAAMAdvanced

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: 外部

外部コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの完全な統合が必要な場合、この認証スキームが使用されます。Webgateは、パートナのフロント・エンド処理を行う必要があります。

OAAMBasic

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

デフォルト・コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの基本統合が必要な場合、このスキームを使用する必要があります。ここでは、OTPなどの拡張機能はサポートされません。エージェントとしてmod_ossoを使用する場合、統合機能のようになります。

チャレンジ・パラメータ:

oaamPostAuth=true

oaamPreAuth=true

OAM10gScheme

認証レベル: 2
チャレンジ・メソッド: OAM10G
認証モジュール: LDAPNoPasswordAuthModule

注意: チャレンジ・メカニズムのOAM10Gは、DAP(アサータ)メカニズムと似ています。特にOSSOとOAM10gが共存する場合にOAM10gメカニズムを使用するので、他のスキームで使用しないでください。

この表の前半の「LDAPNoPasswordValidationScheme」も参照してください。

OAM 10gとの統合および共存を容易にします。共存モードでは、OAM 10gがオーセンティケータ、OAM 11gがアサータです。

このスキームは、新しいチャレンジ・メカニズムOAM10Gを使用します。

OAMAdminConsoleScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

OAM管理コンソールの認証スキーム。

OIFScheme

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: DAP

コンテキスト・タイプ: 外部

このスキームは、認証をOIFに委任します。その後にOAMサーバーによってアサートされるトークンをOIFが戻します。

委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。

チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner

OIMScheme

認証レベル: 1
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

デフォルト・コンテキスト・タイプでOracle Identity Manager関連リソースを保護します。

注意: OAMおよびOIMを統合する場合、OAMは、次のいずれかが検出された場合にユーザーの認証レベルをダウングレードします。

パスワード期限切れ
強制的なパスワードの変更
未実行のチャレンジ設定

このため、ユーザーがリダイレクトされるアイデンティティ管理(OIM)ページの必要な操作を実行した後にのみ、ユーザーはページにアクセスできます。

レベル1の場合、必要な操作の公開ページおよびOIMページにのみアクセスできます。

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

TAPScheme

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: DAP

コンテキスト・タイプ: 外部

IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」でIDM製品リソースにTAPSchemeを使用するには、「認証スキーム」の変更に加えて、次の構成を行う必要があります。

1. IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」から、IAMSuiteAgent:/oamTAPAuthenticateを削除します。

2. IAM Suiteアプリケーション・ドメインで、LDAPSchemeを使用する新しい認証ポリシーを作成します。

3. 新規作成したポリシーを使用して、IAMSuiteAgent:/oamTAPAuthenticateを保護します。

チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName

X509Scheme

認証レベル: 2
チャレンジ・メソッド: X509
認証モジュール: X509

この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。

チャレンジ・メソッドについて

認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。Oracle Access Manager 11gは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。

- フォーム

- Basic

- X509

- WNA

- なし

- DAP

- OAM10G

フォーム

この認証チャレンジは、ユーザー資格証明のために1つ以上のテキスト入力フィールドを含むHTMLフォームを使用します。通常のフォームベース・チャレンジで、ユーザーはフォームの2つのテキスト・ボックスにユーザー名とパスワードを入力します。最も一般的な資格証明の選択はユーザー名とパスワードですが、ユーザー名、パスワード、ドメインなどの任意のユーザー属性を使用できます。

「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。OAMおよびOSSOエージェントは、フォーム・データを捕捉および処理します。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。

注意:
このチャレンジ・メソッドは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。

次のような理由でフォームベースの認証チャレンジを使用できます。

- 一貫性のあるユーザー操作性: フォームベースのログインおよび標準化されたログインを使用すると、ログインおよびログアウト機能のユーザー操作性がブラウザ間で一貫して実現します。

- カスタム・フォーム: 認証プロセスで組織のルック・アンド・フィールを適用できます。
たとえば、Basic認証で使用される標準のユーザー名およびパスワード・ウィンドウのかわりに、カスタム・フォームに企業ロゴおよびようこそメッセージを含めることができます。

- 追加情報: ログイン時に追加情報を収集できます。

- 追加機能: 紛失したパスワードを管理するページのリンクなど、ログイン手順とともに追加機能を提供できます。

Basic

この組込みのWebサーバー・チャレンジ・メカニズムは、ユーザーにログインIDおよびパスワードの入力を要求します。提供された資格証明は、LDAPディレクトリ・サーバーのユーザー定義と比較されます。

注意:
Basicチャレンジは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。

X509

X509証明書チャレンジ・メソッドを使用する場合、認証を実行するには、エージェントを通じてOAMサーバーに送信するSSLを介したX.509デジタル証明書をユーザーのブラウザで指定する必要があります。

注意:
X509は、X509Schemeのチャレンジ・メソッドです。ユーザーの組織は、証明書の取得方法を決定できます。

認証するX.509クライアント証明書の妥当性を確認するには、OAMプロキシおよびOAMサーバーで使用されるキーストアの信頼されたCAに対してX.509クライアント証明書を確認する必要があります。

OAM 11gに関連付けられているユーザー・アイデンティティ・ストアに対して、X.509証明書の次の属性を検証できます。

- SubjectDN

- SubjectUniqueID

- Mail

- CN

ユーザー・エントリを取得するには、X509認証モジュールで検証されるX.509証明書の属性名および検索が起動するLDAP属性を取得します。予期される結果は、基準と一致する1つのユーザー・エントリです。検索でユーザー・エントリが戻らない場合または複数のエントリが戻る場合、認証に失敗します。認証スキーム・パラメータはoam-policy.xmlにあります。

注意:
X509認証の場合、管理者はリバース・プロキシとしてOracle HTTP Server(またはwl-proxyプラグインを使用するサーバー)を構成する必要があります。Oracle HTTP Serverを双方向SSLモードで構成して、認証するX.509証明書を取得する必要があります。CRL検証にもOracle HTTP Serverを構成できます。

オンライン証明書ステータス・プロトコル(OCSP)機能も提供されます。X.509証明書ベースの認証に渡される証明書は、OCSPリクエストを使用して検証します。管理者は、1つ以上のOCSPサーバーと通信するシステムを構成して、証明書ステータスを取得できます。

OCSP応答者URLのX509認証モジュール構成は、OCSP検証を実行するかどうかを示します。指定されている場合、値は、OCSPを使用してX.509クライアント証明書を検証するURLを示します。値がない場合、OCSP検証はありません。

WNA

Active DirectoryのWindows固有の認証およびKerberos認証モジュールを使用します。

注意:
KerbSchemeは、WNAチャレンジ・メソッドおよびKerberos認証モジュールに基づいています。

関連項目:
統合のWindows固有の認証の詳細は、『Oracle Fusion Middleware Oracle Access Manager統合ガイド』を参照してください。

なし

なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。保護しないOracle Access Manager固有のURLにアクセスできるAnonymousScheme認証スキームで使用されます。

DAP

新しい委任認証プロトコル(DAP)チャレンジ・メソッドは、DAP認証モジュールおよび外部コンテキスト・タイプを使用したOIFScheme(Oracle Identity Federation統合)に必要になります(表12-3を参照してください)。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、OAMが受け取ったトークンのアサーションを実行します。

DAPModuleは新しいアサーション・モジュールですが、このアプリケーションに特化され、Oracle Access Managerコンソールの認証モジュールのリストに表示されません。この統合により、OSSO 10gはOAM11gに置き換えられますが、Oracle Identity Federation側からの変更はありません。

DAPチャレンジ・メカニズムは、認証をサード・パーティ(この場合はOracle Identity Federation)に委任します。challenge_urlは、Oracle Identity FederationサーバーのURLを指しています。リソースがこのスキームで保護される場合、OAMサーバーが資格証明コレクションのためにOracle Identity FederationサーバーURLにリダイレクトします。この場合、OAMサーバーは、資格証明の収集または検証を実行しません。Oracle Identity Federationは、資格証明を収集し、ユーザー・アイデンティティ・ストアに対してユーザーを認証して、ユーザー名を構成するアサーション・トークンをOAMサーバーに戻します。Oracle Access Managerは、このトークンを受信および復号化し、OAMのデフォルト・アイデンティティ・ストアでユーザーが有効かどうかを確認します。ユーザーが有効な場合、OAMはリソースのアクセス権を付与します。

DAPTokenは、OAMおよびOIF間で共有されるキーで暗号化および復号化します。DAPTokenは、OAM側から作成されます。

Oracle Identity Federation管理EMコンソールは、OAM 11gおよびOIF間の通信の保護に使用される暗号化鍵を含むキーストアを生成する方法を提供します。OAMは、OIFストアで生成されたキーストアの場所を特定し、キーを取得してOAM側に格納するWLSTコマンド(registerOIFDAPPartner)を提供します。

OAM10G

このチャレンジ・メソッドは、OSSO 10g統合クラシック・アプリケーション(PortalやDiscoなど)も含むドメインを保護するOAM 10gを使用している場合の信頼性を高めるため、LDAPNoPasswordAuthModuleを使用したOAM10gSchemeに必要です。この新しいメカニズムは、OAM 10g共存のために作成されます。

OAM10Gが常に認証/認可プロバイダとして動作するように、OSSO10GはWebgateを通じてOAM10Gで保護されます。

統合の促進: OSSO 10g統合クラシック・アプリケーションをアサータとしてのみ動作するOAM 11gにアップグレードできます。OAM 11gは、mod_ossoで使用できるトークンを作成して、これらのアプリケーションへのアクセスを実現します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAM 10gアクセス・サーバーに対して構成されたOAM 11gサーバーのフロント・エンド処理を行うWebgateがあります。

設定: リソースにアクセスする場合、Webgateはリクエストを捕捉し、認証するためにOAM 10gアクセス・サーバーに送信します。OAM 10gは、資格証明を収集し、アイデンティティ・ストアに対して検証し、ヘッダー変数(OAM_REMOTE_USER)としてユーザー名を設定します。リクエストは、OAM10gSchemeを使用してヘッダー変数のユーザー名を検索するOAM 11gサーバーに移動します。OAM 11gは、ヘッダー変数を取得し、プライマリ・アイデンティティ・ストアに対してユーザーの存在をアサートします。存在する場合、必要なCookie(OAM_ID)が生成され、リソースにリダイレクトされます。

認証スキームのチャレンジ・パラメータについて

チャレンジ・パラメータは、Webgateおよび資格証明コレクタ・モジュールによって使用および解釈される短いテキスト文字列で、その値で示された方法で動作します。

次のデフォルトのチャレンジ・パラメータの例では、使用するCookieでHttpOnlyプロパティを使用するようにWebgateで解釈されます。

ssoCookie=httponly

表12-5は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。スキーム自体の詳細は、表12-4を参照してください。

表12-5 事前構成済スキームのチャレンジ・パラメータ

事前構成済スキーム

チャレンジ・パラメータ

BasicSessionlessScheme

CookieLessMode=true

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

OAAMBasic

oaamPostAuth=true

oaamPreAuth=true

OAAM関連のリソースを保護します。これらのパラメータは、OAAMとの基本統合が必要な場合に使用します。

OIFScheme

TAPPartnerId=OIFDAPPartner

このスキームは、認証をOracle Identity Federationに委任し、その後にOAMサーバーによってアサートされるトークンをFederationが戻します。

TapScheme

TAPPartnerId=TAPPartnerName

認証モジュールについて

Oracle Access Manager 11gでは、各認証スキームに認証モジュールが必要です。管理者は、既存のタイプの新しい認証モジュールを作成できます。ただし、すぐに利用するためにいくつかのデフォルトの認証モジュールを使用できます。

- LDAP: LDAPディレクトリ・サーバーに格納されたユーザー定義にリソースをリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。

- LDAPNoPasswordAuthModule

- カスタム認証モジュール: このモジュールのタイプは、Oracle Access ManagerのJava API拡張認証機能を使用して開発されたカスタム・プラグインに依存しています。このモジュールのタイプでは、1つ以上のカスタム・プラグインを使用できます。複数のプラグインを使用する場合、認証機能を実行するように各プラグインを組織化し、それが成功か失敗かによって、別の認証プラグインをコールします。

関連項目:

- 「カスタム認証モジュールの作成」

- 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』: プラグインの開発とデプロイ、カスタム認証モジュールおよびカスタム・モジュールを使用するスキームの詳細

マルチレベル認証について

各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。

- LDAPScheme authLevel=1

- KerbScheme authLevel=2

注意:
マルチレベル認証は、X.509証明書の認証に影響を与えず、X.509証明書の認証を否定または変更しません。

SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。特定のレベルのユーザーの認証に成功した後、ユーザーは、1つ以上のアプリケーション・ドメインで保護された1つ以上のリソースにアクセスできます。ただし、アプリケーション・ドメインで使用される認証スキームは、同じレベル(または下位のレベル)にする必要があります。ユーザーが現在のSSOトークンのレベルを超える認証レベルで保護されたリソースにアクセスする場合、再認証されます。ステップアップ認証の場合、高いレベルで示されるチャレンジに失敗しても、ユーザーは現在のレベルのアクセスを維持します。これは「追加認証」です。

注意:
レベル3のリソースへのアクセスを認証されているユーザーは、3以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。

Oracle Access Manager 11gポリシーにより、同じアプリケーションの異なるリソースを別の認証レベルで保護できます。ただし、mod_ossoプラグインは、異なる信頼レベルの同じアプリケーションの2つのリソースをサポートしません。

注意:
mod_ossoは、認証をOAMに委任します。mod_ossoで保護されたリソースをOAM認証レベルで保護することをお薦めします。

その場合、アプリケーションはそのレベルを適用し、再認証するために動的ディレクティブをmod_ossoに送信する必要があります。動的ディレクティブを受信すると、適切なレベルで再認証するためにmod_ossoがOracle Access Managerにリダイレクトします。

詳細は、次の項を参照してください。

- エージェントおよびマルチレベル認証について

- OAMエージェントによる不十分な認証レベルの検出

- OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー

エージェントおよびマルチレベル認証について

登録されたエージェントは、次に示すように認証レベルを検出します。

- mod_ossoは、動的ディレクティブから認証レベルを検出します(「OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー」を参照してください)。

- OAMエージェントは、OAMサーバーから不十分なレベルのエラー・メッセージを受け取ります(「OAMエージェントによる不十分な認証レベルの検出」を参照してください)。

両方のエージェント・タイプでユーザーがOAMサーバーにリダイレクトされ、再認証されます。リソースのポリシーに構成された認証スキームのレベルに応じて、チャレンジが示されます。

OAMエージェントによる不十分な認証レベルの検出

ユーザーが高いレベルの認証スキームで保護されるリソースをリクエストすると、次のプロセスが発生します。

プロセスの概要: OAMエージェントによる不十分なユーザー・セッション・レベルの検出

1. OAMエージェントはリクエストをOAMプロキシに送信し、保護されたリソースのスキーム詳細を取得します。

2. OAMエージェントは、セッション情報のリクエストをOAMプロキシに送信します。

3. OAMプロキシは、認証されたレベルのObSSOCookieを含むObSSOCookieの詳細を戻します。

4. OAMエージェントは、ObSSOCookieのレベルを認証スキームのレベルと比較します。

- 不十分な場合、エージェントは認証プロセスを再起動します。

- 十分な場合、アクセス権が付与されます。

サーバー側で認証レベルの確認は行われません。

OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー

OAMエージェントとは対照的に、ホスト(または仮想ホスト)のmod_ossoで保護されたすべてのリソースが同じレベルで保護されます。

mod_ossoでは、ユーザーがレベル2でmod_ossoホスト(または仮想ホスト)ですでに認証され、レベル3で別のmod_ossoで保護されたホスト(または仮想ホスト)にアクセスする場合にマルチレベル認証が適用されます。

プロセスの概要: OSSOエージェントのマルチレベル認証フロー

1. ユーザーは、レベル2のhost1のmod_ossoで保護されたリソースにアクセスします。

2. OSSOエージェントはリクエストをOAMプロキシに送信し、保護されたリソースの認証スキーム詳細を取得します。

3. SSOサーバーのOAM_ID Cookieおよびhost1のホスト・ベースCookie「HOST_port」が設定され、認証レベル情報が格納されます。

4. 認証後、ユーザーは、高いレベルの認証で保護されるhost2のリソースにアクセスします。

5. host2の最初のアクセスなので、認証するためにユーザーがOAMサーバーにリダイレクトされます。

6. OAMサーバー(OSSOプロキシ)は、host2のリソースのアクセスに不十分なレベルのOAM_ID Cookieを受け取ります。

- レベルが不十分な場合、OAMサーバー(OSSOプロキシ)は再認証を要求します。

- レベルが十分な場合、アクセス権が付与されます。

認証スキームの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインで使用される新しい認証スキームを追加できます。

前提条件

認証モジュールを定義して使用可能にする必要があります。

関連項目:
「認証スキーム・ページについて」

認証スキームを作成するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」ノードを拡張します。

2. 「認証スキーム」ノードをクリックし、ツール・バーの「作成」ボタンをクリックします。

3. 新しい「認証スキーム」ページに入力します(表12-3)。

1. 名前

2. 説明

3. 認証レベル

4. チャレンジ・メソッド

5. チャレンジ・リダイレクトURL

6. 認証モジュール

7. チャレンジ・パラメータ

8. チャレンジURL

4. 「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

7. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

認証スキームの検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定の認証スキームを検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

認証スキームを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「認証スキーム」を選択して、検索を定義します。

3. テキスト・フィールドに目的のスキーム名を(ワイルドカード(*)の使用は任意)入力します。次に例を示します。

OA*

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

認証スキームの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを表示または変更できます。

関連項目:
「認証スキーム・ページについて」

認証スキームを表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

1. 「共有コンポーネント」ノード

2. 「認証スキーム」ノード

2. 表示または変更するスキームの名前をダブルクリックします。

3. 編集:

1. 「認証スキーム」ページで、必要に応じて値を変更します(表12-3)。

2. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

3. 確認ウィンドウを閉じます。

4. デフォルトとして設定: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

5. 終了する場合はページを閉じます。

認証スキームの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを削除できます。

前提条件

この認証スキームを使用してアプリケーション・ドメインを確認し、異なるスキームを指定します。

関連項目:
「認証スキーム・ページについて」

認証スキームを削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

1. 「共有コンポーネント」ノード

2. 「認証スキーム」ノード

2. オプション: スキームの名前をダブルクリックして削除対象のスキームを確認し、ページを閉じます。

3. ナビゲーション・ツリーで、スキームの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。

4. 削除を確認します(または確認ウィンドウを閉じます)。

5. ナビゲーション・ツリーで、インスタンスが削除されていることを確認します。

暗号化Cookieのチャレンジ・パラメータの構成

ここでは、次の内容について説明します。

- 暗号化CookieのssoCookieチャレンジ・パラメータについて

- 暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

- 暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

暗号化CookieのssoCookieチャレンジ・パラメータについて

OAMサーバーCookie(OAM_ID)に加えて、Oracle Access Managerは暗号化Cookieを使用してシングル・サインオンを実装します。

- 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>
注意: 有効なOAMAuthnCookieがセッションに必要です。

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

Oracle Access Managerには、Webgateによる暗号化Cookieのフラグの設定方法を制御するために任意の認証スキーム内で使用できる、ssoCookieチャレンジ・パラメータが用意されています。次に例を示します。

- 暗号化Cookieの保護: 暗号化CookieがSSL接続を介してのみ送信され、暗号化CookieがセキュアでないWebサーバーに返信されないようにできます。

- 暗号化Cookieの永続性: ユーザーが、単一のセッションではなく、一定期間ログインできるようにします。Cookieの永続機能は、Internet ExplorerおよびMozillaブラウザと連動します。

パラメータと値の構文には、Webgateのリリースによって次のようなわずかな違いがあります。

11g Webgate ssoCookie=

10g Webgate ssoCookie:

複数の値は、セミコロン(;)で区切る必要があります。次に例を示します。

11g Webgate ssoCookie=<value1>;<value2>;...

10g Webgate ssoCookie:<value1>;<value2>>;...

次の例は、暗号化CookieがSSL接続を介してのみ送信され、クライアント側スクリプトによって暗号化Cookieにアクセスできるように指定しています。

11g Webgate ssoCookie=Secure;disablehttponly

10g Webgate ssoCookie:Secure;disablehttponly

注意:
チャレンジ・パラメータの値では大/小文字を区別します。ssoCookieのCおよびSecureのSは大文字で入力してください。

表12-5は、Webgateがシングル・サインオンの暗号化Cookieのフラグを設定する方法を制御する、特定のチャレンジ・パラメータを示しています。

表12-6 暗号化Cookieのチャレンジ・パラメータ

11g WebgateとOAMAuthnCookieの構文

10g WebgateとObSSOCookieの構文

説明

ssoCookie=

ssoCookie:

暗号化Cookieのフラグを制御するパラメータ。

ssoCookie=httponly

ssoCookie:httponly

暗号化Cookieが、JavaScriptなどのクライアント側スクリプトにアクセスできないようにします。

デフォルト: 有効

ssoCookie=disablehttponly

ssoCookie:disablehttponly

httponly機能を明示的に無効にすると、暗号化Cookieがクライアント側スクリプトにアクセスできるようになります。

明示的に無効にした場合、有効にするにはデフォルト値(httponly)を使用する必要があります。

ssoCookie=Secure

ssoCookie:Secure

HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。

ssoCookie=max-age=time-in-seconds

ssoCookie:max-age=time-in-seconds

Internet ExplorerおよびMozillaブラウザで、単一セッション用のものではなく、永続的なCookieを作成します。

Cookieが期限切れになるまでの時間間隔を秒単位で指定します。たとえば、Cookieを30日(2592000秒)で期限切れにするには、次のように設定します。

max-age=2592000

暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

「チャレンジ・パラメータ」では大/小文字を区別します。ssoCookieのCおよびSecureのSは大文字で入力してください。

関連項目:
「暗号化CookieのssoCookieチャレンジ・パラメータについて」

暗号化Cookieを保護する手順は次のとおりです。

1. 「認証スキームの作成」で説明されているように、認証スキームを作成します。

2. 「チャレンジ・パラメータ」フィールドで、次のように指定して暗号化Cookieを保護します。
11g Webgate ssoCookie=Secure

10g Webgate ssoCookie:Secure

3. 付録Eに示すように、OAMサーバーとクライアント(OAMエージェント)が、アクセス・プロトコル・チャネルを介してセキュアに通信していることを確認します。

暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

「チャレンジ・パラメータ」では大/小文字を区別します。ssoCookieのCは大文字で入力してください。

関連項目:
「暗号化CookieのssoCookieチャレンジ・パラメータについて」

暗号化Cookieの永続性を定義する手順は次のとおりです。

1. 「認証スキームの作成」で説明されているように、認証スキームを定義します。

2. このスキームのチャレンジ・パラメータに次の内容を追加します。
11g Webgate ssoCookie=max-age=time-in-seconds

10g Webgate ssoCookie:max-age=time-in-seconds

13 リソースを保護してSSOを有効化するポリシーの管理

この章では、ポリシーの作成および管理方法を説明し、これらのポリシーを制御するリソースを確認します。この章では、タスクに対するOracle Access Managerコンソールの使用に焦点を当て、次の内容を説明します。

- 前提条件

- アプリケーション・ドメインの作成の概要

- アプリケーション・ドメインおよびポリシーの詳細分析

- コンソールを使用したアプリケーション・ドメインの管理

- ポリシーで使用するリソース定義の追加および管理

- 特定のリソースの認証ポリシーの定義

- 特定のリソースの認可ポリシーの定義

- SSOのポリシー・レスポンスの概要

- SSOのポリシー・レスポンスの追加および管理

- 認可制約の概要

- 認可ポリシー制約の定義

- アプリケーション・ドメインの認証および認可の検証

- 例: 事前シード済のIAM Suiteアプリケーション・ドメインおよびポリシー

前提条件

OAMポリシー・モデルおよびシングル・サインオンの概要は、第11章を確認してください。

この章のタスクのシステム・レベル要件は次のとおりです。

- Oracle Access Manager 11gを操作できる必要があります。

- 保護されたリソースにアクセスできるユーザーおよびグループがOAM 11gに関連付けられたユーザー・アイデンティティ・ストアにすでに作成されている必要があります。

- ポリシー施行エージェントを登録する必要があります(第9章を参照してください)。

- アプリケーション・ドメインで使用する共有コンポーネントを定義する必要があります(第12章を参照してください)。

アプリケーション・ドメインの作成の概要

この項の内容は次のとおりです。

- 自動的なアプリケーション・ドメインの作成について

- 手動のアプリケーション・ドメインの作成について

自動的なアプリケーション・ドメインの作成について

OAM 11gにポリシー施行エージェントを登録すると、ポリシーを自動的に作成できます。エージェントに指定された詳細に基づいて、アプリケーション・ドメインおよびホスト識別子が自動的に作成されます。ドメインは、デフォルトのリソースとデフォルトの認証および認可ポリシーでシードされます。

各アプリケーション・ドメインは、特定のホストの単一のアプリケーションを表すリソースの集合です。構成可能な認証および認可ポリシーを使用して、ドメインのリソースへのアクセスを許可または拒否できます。

エージェントの登録中、エージェントが保護するアプリケーションと同じWebサーバーにあると仮定します。ただし、エージェントをプロキシWebサーバー、アプリケーションを異なるホストに配置できます。

注意:
IAMSuiteAgentは、アプリケーション・ドメイン(IAMSuite)を提供してOracle Fusion Middlewareコンソールなどを保護する事前登録されたJavaエージェント・フィルタです。

詳細は、「アプリケーション・ドメインおよびポリシーの詳細分析」を参照してください。

手動のアプリケーション・ドメインの作成について

新しいアプリケーションが既存のエージェントの背後に配置される場合、管理者は、個別のアプリケーション・ドメインおよびポリシーまたは既存のアプリケーション・ドメインおよびポリシーで保護するかどうかを決定する必要があります。

管理者は、同じWebサーバーに存在して様々な方法で相互に密接に関連付けられている場合でも、リソースの異なるアプリケーション・ドメインを定義できます。たとえば、管理者は、財務アプリケーションおよび売掛金勘定アプリケーションの単一のアプリケーション・ドメインを作成するか、それぞれに異なるアプリケーション・ドメインを使用できます。

注意:
新しいリソースをアプリケーション・ドメインに追加する前に、リソースが既存のアプリケーションおよびポリシーに属するかどうかまたは固有の特定のポリシーを使用する新しいアプリケーションとして定義するかどうかを検討します。

次のタスクの概要では、新しいアプリケーション・ドメインを手動で作成するために実行する必要がある手順について説明します。

注意:
タスク3から6を実行すると、管理者は既存のアプリケーション・ドメインを管理できます。

タスクの概要: アプリケーション・ドメインの手動の作成

1. 「アプリケーション・ドメインおよびポリシーの詳細分析」を確認します。

2. アプリケーション・ドメインの登録を開始します(「新しいアプリケーション・ドメインの手動作成」を参照してください)。

3. 1つ以上のリソース定義をドメインに追加し、「保護」、「非保護」または「除外」として設定します(「ポリシーで使用するリソース定義の追加および管理」を参照してください)。

4. ドメインの1つ以上の認証ポリシーを構成します(「特定のリソースの認証ポリシーの定義」を参照してください)。

5. ドメインの1つ以上の認可ポリシーを構成します(「特定のリソースの認可ポリシーの定義」を参照してください)。

6. 1つ以上のSSOレスポンスをポリシーに定義します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

7. 1つ以上の認可制約を定義します(「認可ポリシー制約の定義」を参照してください)。

8. 必要に応じて、「トークン発行ポリシー」を定義します(「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」を参照してください)。

9. 「SSO」設定を構成します(「SSOトークンとIPの検証の管理」を参照してください)。

10. ドメインの操作を検証します(「アプリケーション・ドメインの認証および認可の検証」を参照してください)。

アプリケーション・ドメインおよびポリシーの詳細分析

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

注意:
アクセス・サーバーへのWebgate問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合、OAM 10gのデフォルトの動作ではアクセスが許可されていました。

OAM 11gを使用する場合、管理者は、特定のリソースのアクセスを認可される認証ユーザーおよび認可されないユーザーを区別するポリシーを定義して、リソースにアクセス可能なユーザーを制御します。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。アプリケーション・ドメインは、相互に階層の関係がありません。

図13-1は、Oracle Access Manager 11gポリシー・モデルのアプリケーション・ドメイン固有のコンポーネントを示しています。

図13-1 OAMポリシー・モデルのアプリケーション固有のコンポーネント

「図13-1 OAMポリシー・モデルのアプリケーション固有のコンポーネント」の説明

エージェントの登録中に自動的に作成されるアプリケーション・ドメインは、エージェントに基づく名前が付けられ、エージェント名に基づいてデフォルトのリソースおよびデフォルトのポリシー(認証および認可)でシードされます。最初は、すべてのリソースがデフォルトの認証および認可ポリシーで保護され、「トークン発行ポリシー」は定義されていません(コンテナは空です)。アプリケーション・ドメインを作成した後、そのドメインにリソース定義を追加できるようになり、その後特定のポリシーにリソースを追加できます。

エージェントの登録に使用されるOracle Access Managerコンソールまたはリモート登録ツールにかかわらず、次の内容のとおり、アプリケーション・ドメインの要素は同じです。

- アプリケーション・ドメインの一般詳細

- 生成されたアプリケーション・ドメインのデフォルトのリソース

- 生成されたアプリケーション・ドメインのデフォルトの認証ポリシー

- 生成されたアプリケーション・ドメインのデフォルトの認可ポリシー

関連項目:
トークン発行ポリシーの詳細は、「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」を参照してください。

アプリケーション・ドメインの一般詳細

図13-2に、エージェント登録時に自動的に作成されるアプリケーション・ドメインを示します。アプリケーション・ドメイン名は「アプリケーション・ドメイン」ノードのナビゲーション・ツリーにハイライト表示され、「アプリケーション・ドメイン」ページには名前と説明が示されています。

図13-2 エージェント登録時に生成された新規アプリケーション・ドメイン

「図13-2 エージェント登録時に生成された新規アプリケーション・ドメイン」の説明

ナビゲーション・ツリーのアプリケーション・ドメイン名の下にデフォルトのリソース定義およびポリシーがあります。

管理者はアプリケーション・ドメインを変更して、リソースの追加およびポリシー、レスポンスおよび認可制約の定義を実行できます。

生成されたアプリケーション・ドメインのデフォルトのリソース

図13-3に、自動生成機能を使用した場合に生成されたアプリケーション・ドメインのデフォルトのリソースを示します。ホスト識別子は、登録中に指定されたエージェント名と一致します。デフォルトのリソース・タイプはHTTPですが、デフォルトのリソースURLは/および/.../*です。

図13-3 生成されたアプリケーション・ドメインのデフォルトのリソース定義

「図13-3 生成されたアプリケーション・ドメインのデフォルトのリソース定義」の説明

アプリケーション・ドメインに追加されたリソースのリストから、このポリシーにリソースを追加できます。HTTPリソース定義により、問合せ文字列の入力が有効化されます。この問合せ文字列に含めることができるのはベースURLのみで、ベースURLでは一連のURLを示すオプションのパターン一致特殊文字を使用できます。また、問合せ文字列で検索して、特定のリソースを探すこともできます。「検索」ページの「作成」ボタンを使用すると、新規リソース定義を開始できます。

関連項目:
「ポリシーで使用するリソース定義の追加および管理」

生成されたアプリケーション・ドメインのデフォルトの認証ポリシー

1つの認証ポリシーでのみ、各リソースを保護できます。管理者がアプリケーション・ドメインを手動で作成する場合、すべてのポリシーを手動で作成する必要もあります。ただし、たとえばエージェント登録時にアプリケーションが自動的に生成されると、「Protected Resource Policy」が自動的に作成されます。

「Protected Resource Policy」を図13-4に示します。説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加して保護します。と示されています。このデフォルト・ポリシーでは、デフォルト認証スキーム(この場合はLDAPScheme認証スキーム)が使用されています。保護されているリソースは、HostIdentifier/.../*として「リソース」タブで識別されます。管理者は、認証スキームの変更、成功URLと失敗URLの指定、他のリソースの追加および認証レスポンスの定義を実行できます。

認証ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。

注意:
最初は、すべてのリソースが保護されます。成功および失敗URLとレスポンスを手動で追加する必要があり、デフォルト値は提供されません。

図13-4 保護されたリソースのデフォルト認証ポリシー

「図13-4 保護されたリソースのデフォルト認証ポリシー」の説明

認証のパブリック・リソース・ポリシー: 2つ目の認証ポリシーも作成され、デフォルトの認証としてAnonymousSchemeが使用されます。管理者に対する説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加してすべてのアクセスを許可します。と示されています。

注意:
このパブリック・リソース・ポリシーは、最初はいずれのリソースも保護しません。

関連項目:
「SSOのポリシー・レスポンスの概要」

生成されたアプリケーション・ドメインのデフォルトの認可ポリシー

1つの認可ポリシーでのみ、各リソースを保護できます。アプリケーション・ドメインを手動で作成する管理者は、すべてのポリシーを手動で作成する必要があります。ただし、たとえばエージェント登録時にアプリケーションが自動的に生成されると、次の認可ポリシーが自動的に生成されます。

- 認証ポリシー: Protected Resource Policy

- 認可ポリシー: Protected Resource Policy

注意:
最初は、すべてのリソースが保護され、アクセスが拒否されます。成功および失敗URLと制約およびレスポンスを手動で追加する必要があり、デフォルト値は提供されません。

認可の「Protected Resource Policy」を図13-5に示します。説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加して保護します。と示されています。保護されているリソースは、HostIdentifier/.../*として「リソース」タブで識別されます。管理者は、成功URLと失敗URLの指定、他のリソースの追加および認可制約およびレスポンスの定義を実行できます。

図13-5 リソースを保護するデフォルト認可ポリシー

「図13-5 リソースを保護するデフォルト認可ポリシー」の説明

前のリリースでは、2つ目の認可ポリシー(パブリック)も作成されましたが、最初はいずれのリソースも保護していませんでした。パッチ・セット1から、この2つ目のポリシーは設定されなくなりました。

関連項目:

- 「SSOのポリシー・レスポンスの概要」

- 「認可制約の概要」

トークン発行ポリシーについて

デフォルトで、エージェント登録時に生成されるアプリケーション・ドメインには、「トークン発行ポリシー」のコンテナのみが表示されています。

このポリシー・タイプ、リソースおよび考えられる制約の詳細は、次を参照してください。

- 「TokenServiceRPタイプのリソースの管理」

- 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」

コンソールを使用したアプリケーション・ドメインの管理

この項の内容は次のとおりです。

- アプリケーション・ドメイン・ページについて

- 新しいアプリケーション・ドメインの手動作成

- アプリケーション・ドメインの検索

- アプリケーション・ドメインの表示または編集

- アプリケーション・ドメインおよびその内容の削除

アプリケーション・ドメイン・ページについて

アプリケーション・ドメインの管理には、一般的な設定およびリソース関連設定と認証および認可ポリシーの追加、変更、コピーまたは削除が含まれます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、AppDom3というアプリケーション・ドメインをコピーする場合、コピー名はcopy of AppDom3になります。コピーされたドメインの他のすべての設定は、コピーに保持されます。

Oracle Access Managerコンソールを使用してアプリケーション・ドメインを作成または編集する場合、いくつかのページが呼び出されます。最初は、図13-6に示されているフォームに一般詳細(名前およびオプションの説明)を追加します。

図13-6 新しいアプリケーション・ドメインの一般的なページ

「図13-6 新しいアプリケーション・ドメインの一般的なページ」の説明

各アプリケーション・ドメインには、エージェント名と一致する一意の名前を使用する必要があります。新しいアプリケーション・ドメインの名前とオプションの説明を適用した後、アプリケーション・ドメインが作成され、名前が「ポリシー構成」タブのナビゲーション・ツリーの「アプリケーション・ドメイン」ノードに追加されます。リストには、コンテナのフラット・リストとしてすべてのアプリケーション・ドメイン名が含まれます。

「アプリケーション・ドメイン」ノードを拡張して、新しいドメインを含むすべてのドメインを明らかにできます。図13-7に、「アプリケーション・ドメイン」のナビゲーション・ツリーおよびドメインのリソース・ポリシーに関連するコンテナを示します。

図13-7 アプリケーション・ドメインのナビゲーション・ツリー

「図13-7 アプリケーション・ドメインのナビゲーション・ツリー」の説明

ナビゲーション・ツリーのドメイン名を選択すると、この章の他の項に示されているように個々の要素を追加、変更または削除できます。

新しいアプリケーション・ドメインの手動作成

有効な管理者の資格証明を持つユーザーは、次のタスクを実行してOracle Access Managerコンソールでアプリケーション・ドメインを手動で作成できます。

注意:
第9章および第10章で説明するように、アプリケーション・ドメインはエージェント登録時に自動的に生成できます。

アプリケーション・ドメインを手動で作成し、リソースおよびポリシーを手動で追加して、同じエージェントを使用して複数のアプリケーションを保護できます。

前提条件

新しいアプリケーション・ドメインが必要かどうか、またはリソースを既存のアプリケーション・ドメインに追加できるかどうかを決定します。

注意:
テンプレートとして使用する既存のドメインを複製し、コピーを編集して一意の識別子(リソース名およびリソースURL)を定義できます(「アプリケーション・ドメインの表示または編集」を参照してください)。

関連項目:
「アプリケーション・ドメインの作成の概要」

新しいアプリケーション・ドメインを作成するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「アプリケーション・ドメイン」ノードをクリックして、ツール・バーの「作成」コマンド・ボタンをクリックします。
または、「ようこそ」ページの「ポリシー」パネルで、「新規アプリケーション・ドメイン」をクリックして新しいページを開きます。

2. 新しいアプリケーション・ドメイン・ページで、ドメインの一意の名前およびオプションの説明を追加して、「適用」をクリックして確認ウィンドウを閉じます。

3. ツール・バーの「リフレッシュ」ボタンをクリックして、新しいアプリケーション・ドメインがナビゲーション・ツリーに表示されていることを確認します。

4. ナビゲーション・ツリーで、新しいアプリケーション・ドメインを拡張して、次のノードを表示および管理します。

- リソース: 「ポリシーで使用するリソース定義の追加および管理」を参照してください。

- 認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。

- 認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。

- トークン発行ポリシー: 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」を参照してください。

アプリケーション・ドメインの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメインを検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

アプリケーション・ドメインを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化します。

2. 検索タイプ・リストから「アプリケーション・ドメイン」を選択して、検索を定義します。

3. テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。

my_App_Domain_Name

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

アプリケーション・ドメインの表示または編集

有効な管理者の資格証明を持つユーザーは、次のタスクを実行してOracle Access Managerコンソールでアプリケーション・ドメイン(リソース、ポリシー、制約およびレスポンスを含む)を表示または変更できます。

注意:
テンプレートとして使用する既存のドメインを複製し、コピーを編集して一意の識別子(リソース名およびリソースURL)を定義できます。

類似するアプリケーションを同じアプリケーション・ドメインにグループ化することをお薦めします。アプリケーション・ドメインを編集する場合、異なるアプリケーションが同じドメインを使用していることに注意してください。説明およびドメイン名の編集がサポートされます。

アプリケーション・ドメインおよびその内容を表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. 次の各ノードを拡張して、次の特定の内容を追加、表示、変更または削除します。

- リソース: 「ポリシーで使用するリソース定義の追加および管理」を参照してください。

- 認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。

- 認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。

- トークン発行ポリシー: 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」を参照してください。

3. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

アプリケーション・ドメインおよびその内容の削除

有効な管理者の資格証明を持つユーザーは、次のタスクを実行してOracle Access Managerコンソールでアプリケーション・ドメイン(リソース、ポリシー、制約およびレスポンスを含む)を削除できます。

前提条件

削除するドメインのリソースが保護するために別のアプリケーション・ドメインに配置されていることを確認します。

アプリケーション・ドメインを削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーで、「アプリケーション・ドメイン」ノードを展開します。

2. ナビゲーション・ツリーで、アプリケーション・ドメイン名を開いて確認します。

3. アプリケーション・ドメインを選択して、ツール・バーの「削除」ボタンをクリックします。

4. 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

5. ナビゲーション・ツリーで、アプリケーション・ドメインが削除されていることを確認します。

ポリシーで使用するリソース定義の追加および管理

リソースの保護には、特定のリソース定義を含むアプリケーション・ドメインが必要です。OAMでは、次のような非HTTP/HTTPSベースのリソースおよびHTTP/HTTPSベースのリソースを含む様々なタイプのリソースを保護できます。

- すべての外部Webサイト

- Webサイトの特定のページ

- パートナ・ポータル

- 部品注文アプリケーション

- 請求書アプリケーション

- 多くの国の企業のWebサーバーの福利厚生加入アプリケーション

この項の内容は次のとおりです。

- アプリケーション・ドメインのリソース定義ページについて

- リソース定義の検索

- アプリケーション・ドメインへのリソース定義の追加

- アプリケーション・ドメインのリソース定義の表示または編集

- アプリケーション・ドメインからのリソース定義の削除

アプリケーション・ドメインのリソース定義ページについて

アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のリソース・タイプおよびサーバーに格納されて多くのユーザーがアクセスできるドキュメントまたはエンティティを識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。

各リソースがアプリケーション・ドメインで個別に定義されます。明示的に「除外」とマークされていないリソースがポリシーに関連付けられていない場合、一致するポリシーがないため、すべてのユーザーのアクセスが拒否されます。

図13-8は、新しい「リソース」定義ページを示しています。

図13-8 アプリケーション・ドメインの「リソース」ページ

「図13-8 アプリケーション・ドメインの「リソース」ページ」の説明

表13-1は、リソース定義を構成する要素を示しています。

表13-1 リソース定義の要素

要素

説明

タイプ

HTTPタイプがデフォルトです。HTTPまたはHTTPSプロトコルを使用してアクセスするリソースを扱います。特定のリソースを制御するポリシーがすべての操作に適用されます。

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明しているように、Fusion Middlewareアプリケーション・シナリオではwl_authenリソース・タイプが使用されます。

「リソース・タイプの管理」も参照してください。

「TokenServiceRPタイプのリソースの管理」で説明するように、TokenServiceRPリソース・タイプはトークン・サービス・リライイング・パーティを表すために使用されます。

説明

このリソースのオプションの一意の説明。

ホスト識別子

共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。

注意: リソース定義を構成するホスト識別子およびURL文字列の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。

関連項目: 「ホスト識別子の管理」

リソースURL

「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URLとして、URL値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。

内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。

- 最下位の終端レベルのパスにのみ、アスタリスク(*)を使用できます。アスタリスクは、0(ゼロ)個以上の文字と一致します。

- 終端レベルを除く任意のレベルのパスに省略記号(…)を使用できます。省略記号は、0(ゼロ)個以上の一連の中間レベルを表します。

表13-2も参照してください。

問合せ文字列

ポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。次のフォーマットが許可されます。

サポート対象: フル・リテラル問合せ文字列の一致に基づくリソース保護。入力問合せ文字列全体に一致する単一の問合せ文字列パターン(問合せ文字列の一部のみに一致(選択された名前値のペア)とは異なります)。次に例を示します。

status=active&adminrole=*

次の追加機能を持つ標準のフリー・フォーム文字列として指定された問合せ文字列パターン。

- オプション: 0(ゼロ)個以上の文字と一致する特殊文字(*)が、実行時問合せ文字列の名前のセットに適用されます。

- URLベース・パス・パターンが同じで問合せ文字列パターンが異なる2つのリソース定義が存在できます。これらの2つは独立しており、別個のリソースです。たとえば、次の定義はすべて有効で、同時に存在できます。

/foo
/foo?bar=true
/foo?bar=false

問合せ文字列は、フォーマットや文字に関する制限がないフリー・フォームです。問合せ文字列をキー/値ペアとして指定する必要はありません。

実行時、HTTP GET要求の一部である問合せ文字列のみが処理されます。問合せ文字列パターンはHTTP POSTデータには適用されません。

リソース一致(実行時):

- ベースURLパスが一致し、次に問合せ文字列が一致します。

- 一致する問合せ文字列を含む複数のリソース・パターン: 最善一致は、トークンの数('*'で区切られるパターン)および各位置のトークンの長さに基づいて決まります。まず、より長いトークンを持つパターン、次により多くのトークンが含まれるパターンの順で優先されます。(トークンの数が同じで各位置の長さも同じ一致パターンがある場合、その一致は失敗します。)

競合:

- スーパー・セット: 入力リソース定義に、ポリシー・ストア内の既存のリソース定義のパターンのスーパー・セットである一連の名前値問合せ文字列パターンが含まれています。

- 重複: 入力リソース仕様に、ポリシー・ストア内の既存のリソース定義の一連のパターンと重複する一連の名前値問合せ文字列パターンが含まれています。

注意: OAMエージェントでは、リモート登録ツール(oamreg)が問合せ文字列ベースのHTTPリソース定義を受け入れ、これらのリソースのアクセスを保護するために関連するポリシー・オブジェクトを生成します。ポリシー・プロビジョニング中に競合が発生した場合、競合のないリソースのポリシーのみがプロビジョニングされます。この機能は10g OSSOエージェント・ベースのパートナおよびアプリケーションには適用されません。OSSOエージェントには、リソースごとに認証スキームを施行する機能はありません。かわりに、単一の認証スキームがアプリケーションの全リソースに適用されます。

保護レベル

適切な保護レベルを次のオプションから選択します。

- 保護(デフォルト)
保護されているリソースは、様々な認証スキーム(LDAPなど)を使用する保護レベル認証ポリシーに関連付けられます。

認可ポリシーは保護されているリソースに対して許可されます。

レスポンス、制約、監査およびセッション管理は、リソースを保護するポリシーを使用して保護されているリソースに対して有効化されます。

- 非保護
保護されていないリソースは、様々な認証スキーム(LDAPなど)を使用する非保護レベル認証ポリシー(レベル0)に関連付けられます。

認可ポリシーは保護されていないリソースに対して許可されますが、このようなアクセスを許可するための基本ポリシーが必要です。ただし、制約およびレスポンスが含まれる複雑なポリシーは不適切です。

レスポンス、制約および監査は、リソースを保護するポリシーを使用して保護されていないリソースに対して有効化されます。セッション管理のみが有効化されていません。保護されていないリソースにアクセスすると、WebgateからのOAMサーバー・チェックが引き起こされます(監査可能)。

- 除外(パブリック)
HTTPリソース・タイプのみが除外できます。通常はイメージ(*.jpg, *.png)などのセキュリティの区別がないファイルで、保護レベルが「除外」のリソースでは、認証、認可、レスポンス処理、セッション管理および監査に対するOAMサーバー・チェックは必要ありません。除外されたリソースは、コンソール内のユーザー定義ポリシーには追加できません。

除外されたリソースへのアクセスを許可している間、WebgateはOAMサーバーにコンタクトしないため、アクセスは監査されません。最も標準的なリソース検証が、除外されたリソースに適用されます。ただし、リソースをポリシーに追加するときに、除外されたリソースはリストに表示されていません。

リソースに関連付けられた認証または認可はありません。

注意: リソース保護レベルが「保護」から「除外」に変更され、そのリソースに対するポリシーが存在する場合、リソースとポリシーとの関連付けを解除するまで、変更は失敗します。

認証ポリシー

指定したリソース保護レベルに基づく認証ポリシーのリストが使用可能になりました。このドメイン内にあり、指定した保護レベルに一致するポリシーのみがリストされます。

認可ポリシー

ドメインで定義された認可ポリシーのリストが使用可能になり、そこから選択できるようになりました。

表13-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURLについて」を参照してください。

表13-2 HTTPリソースのサンプルのURL値

リソース

サンプルのURL値

ディレクトリ

- /mydirectory

- /mydirectory/projects

- /mydirectory/*

ページ

- /mydirectory/projects/index.html

- /mydirectory/projects/*.html

- /mydirectory/.../*.html

- /.../*.html

Webアプリケーション

- /mydirectory/projects/myexe.exe

- /mydirectory/projects/*.exe

- /mydirectory/.../*.exe

- /.../*.exe

リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。認証および認可ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストに表示されるので、ポリシーに含める1つ以上のリソースを選択できます。

リソース定義の詳細は、次の各項を参照してください。

- リソース定義のリソース・タイプについて

- リソース定義のホスト識別子について

- リソースURLについて

- ランタイム・リソース評価について

リソース定義のリソース・タイプについて

リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。

HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。

HTTP以外のリソース・タイプに名前が付けられ、URLに関連付けられません。HTTP以外のタイプのリソース定義を追加する場合、管理者は「リソースURL」フィールドにタイプの名前を入力する必要があります。

リソース定義のホスト識別子について

管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを確認します。

注意:
HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。

ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。

すべての定義されたホスト識別子が「リソース」ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。

OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。

リソースURLについて

自動的なアプリケーション・ドメインの生成中、すべてのリソースが保護されるURL接頭辞が定義されます。リソースは線形で階層ではありません。リソースの定義は、完全なURLとして扱われます。

注意:
非HTTPリソース・タイプに関連付けられるホスト識別子はありません。

管理機能は、特定のリソースURLを使用して、アプリケーション・ドメインの個々のリソースを識別します。個々のリソースURLをドメイン間で一意にする必要はありません。ただし、リソースURL、問合せ文字列およびホスト識別子の組合せをドメイン間で一意にする必要があります。

HTTPタイプのリソースは、パスを表す単一の相対URL文字列として表現されます。文字列は、「/」文字で区切られた一連の階層レベルで構成されます。内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。

URL接頭辞

ポリシー・モデルはリソース接頭辞をサポートしません。ポリシーが/mydirectory/projects/に定義されている場合、そのURLにのみ適用されます(/mydirectory/projects/index.htmlなどには適用されません)。つまり、ポリシーの継承はありません。同じ接頭辞文字列を使用したすべてのリソースのポリシーが必要な場合、特殊文字(/mydirectory/projects/.../*などの3つのピリオド...(省略記号)または*(アスタリスク))を使用してリソースを定義できます。

URLパターン

管理者は、詳細なURLパターンを作成して、リソースのネームスペースの詳細な部分を指定できます。

機能が制限された次の2つのパターンでのみ、パターン照合が実行されます。

… *

3つのピリオド(省略記号)は、スラッシュ(/)で囲まれた1つ以上の文字の連続に一致します。0(ゼロ)個以上の一連の中間レベルを表し、複数のディレクトリにまたがることを可能にします。省略記号(...)は、任意のURLに1回のみ、終端レベルを除く任意のレベルのパスに使用できます。省略記号は、該当するドメイン内のすべてのリソースを保護する働きがあります。

* (アスタリスク)は、最下位の終端レベルのパスにのみ使用できます。0(ゼロ)または1つ以上の文字に相当します。URLパターン内のすべての文字は対応するURLパス内の文字に正確に一致する必要がありますが、次の2つの例外があります。

- パターンの最後の/*は、以降の一連の文字と一致します。

- パターン*拡張子は、名前が付いた拡張子で終わるファイル名と一致します。

注意:
他のワイルド・カードはサポートされていません。パターンの他の位置のアスタリスクはワイルド・カードではありません。

たとえば、次のURLパターンなどです。

/.../update.html

次のリソースと一致します。

/humanresources/benefits/update.html
/corporate/news/update.html
update.html

表13-3は、単一のアプリケーション・ドメイン内の多くのリソース定義を示しています。ホスト識別子およびリソースURLに従って、アルファベット順で編成されます。

表13-3 .jspのリソースURL

リソースURL

適切か

/bank/accounts/*

はい

/bank/accounts/*.jsp

はい

/bank/accounts/checking

はい

/bank/.../checking.jsp

はい

/.../*.jsp

はい

/bank/accounts/checking*.jsp

いいえ

/bank/accounts/c*.jsp

いいえ

/bank/.../accounts/def.gif

いいえ

ランタイム・リソース評価について

リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。

関連項目:
「ランタイム・ポリシー評価キャッシュの管理」

プロセスの概要: リソースの評価

1. ユーザーは、リクエストしたリソースのURLを指定します。

2. ホスト識別子およびURLに基づいて、OAMはURLパターンを含む完全修飾URLを作成します。

3. OAMは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。

- 一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。

- リクエスタのアクセスが許可されると、リソースがユーザーに提供されます。

表13-4は、可能性のある結果を示しています。

表13-4 リソース評価の結果

結果

説明

最善一致

最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。

一致なし

一致なしの場合、デフォルトの評価結果はFAILUREです。評価されたポリシーの種類によっては、認証が実行されなかったり、リソースのアクセス権が付与されなかったりすることを意味する場合があります。

検索メカニズムの例

- 生成されたアプリケーション・ドメインのデフォルトのリソースURLは、使用可能な最大範囲の内容を定義します(すべてのディレクトリと次のディレクトリ)。
/.../*

- パターン/.../index.htmlは、次のURLと一致します。

/index.html
/oracle/index.html
/oracle/sales/index.html
index.html

たとえばxyzindex.htmlには一致しません。

- /oracle/.../*.htmlは、次のURLと一致します。

/oracle/index.html
/oracle/sales/order.html
and so on

リソース・スコープの例

- 次のリソース定義のリソース・スコープ(アスタリスクを含む)
/mybank/…/*

「/mybank/」という接頭辞が付いたすべてのURLを含みます。

- 次のリソース定義のリソース・スコープ(定義に特殊文字を含まない)
/mybank/account.html

1つのURL「/mybank/account.html」のみ含みます。

アプリケーション・ドメインへのリソース定義の追加

有効な管理者の資格証明を持つユーザーは、次の手順を使用して保護するリソース定義を対応するアプリケーション・ドメインに追加できます。

注意:
無効なホスト識別子の値を指定すると、失敗する場合があります。チャレンジURLが無効であることを示すエラーが通知されます。

前提条件

共有コンポーネントとしてリソース・タイプを定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。

関連項目:
「アプリケーション・ドメインのリソース定義ページについて」

リソース定義をアプリケーション・ドメインに追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. アプリケーション・ドメイン内で、「リソース」ノードを開きます。

3. 「検索」ページの右上隅にある「新規リソース」ボタンをクリックします。

4. リソース定義ページで、次の手順を実行します。

1. 単一のリソースの詳細を選択または入力します(表13-1)。
タイプ
説明(オプション)
ホスト識別子
リソースURL
問合せ文字列
保護レベル
認証ポリシー(レベルが「保護」の場合)
認可ポリシー(レベルが「保護」で認可ポリシーが選択されている場合)

2. 「適用」をクリックして、このリソースをアプリケーション・ドメインに追加します。

3. この手順を繰り返して、他のリソースをこのアプリケーション・ドメインに追加します。

5. 次の項の手順に従って、リソースを特定のポリシーに追加します。

- 特定のリソースの認証ポリシーの定義

- 特定のリソースの認可ポリシーの定義

- Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理

リソース定義の検索

この項の内容は次のとおりです。

- 特定のリソース定義の検索について

- 特定のリソース定義の検索

特定のリソース定義の検索について

図13-9は、アプリケーション・ドメイン内のリソース定義のデフォルトの検索要素および検索結果の表を示しています。

図13-9 アプリケーション・ドメイン内でのリソース定義の検索

「図13-9 アプリケーション・ドメイン内でのリソース定義の検索」の説明

デフォルトを使用して「検索」ボタンをクリックするか、リソースを探すために表13-0に示す情報を必要に応じてできるだけ多く、またはできるだけ少なく指定して検索を絞り込みます。

表13-5 アプリケーション・ドメイン内のリソースの検索要素

検索要素

説明

リソース・タイプ

定義されたリソース・タイプのリストから選択できます。空白にしておくこともできます。

デフォルト値: HTTP

ホスト識別子

必要に応じて、ホスト識別子をここに入力します。ここは空白のままにできます。

デフォルト値: 空白

リソースURL

必要に応じて、リソースURLを入力します。ここは空白のままにできます。

デフォルト値: 空白

問合せ文字列

リソースの問合せ文字列を入力するか、空白のままにします。アプリケーション・ドメインへの追加時にリソースの問合せ文字列が定義された場合は、この要素を検索条件に含めることができます。

デフォルト値: 空白

認証ポリシー

アプリケーション・ドメインの定義された認証ポリシーのリストが表示されます。1つ選択するか、空白のままにします。

デフォルト値: 空白

認可ポリシー

アプリケーション・ドメインの定義された認可ポリシーのリストが表示されます。1つ選択するか、空白のままにします。

デフォルト値: 空白

「リセット」をクリックしてフォームをクリアするか、「検索」をクリックして検索を開始します。結果表を例13-0に示します。リストされている各リソースには、ドメインへの追加時に指定したすべての要素が含まれています。表では「アクション」メニューおよび「表示」メニューを使用できます。また、「作成」コマンド・ボタンをクリックして、このドメインに新規リソース定義を追加することもできます。

図13-10 アプリケーション・ドメイン内のリソース定義の検索結果表

「図13-10 アプリケーション・ドメイン内のリソース定義の検索結果表」の説明

特定のリソース定義の検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のリソース定義を検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

リソース定義を検索する手順は次のとおりです。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. 「リソース」ノードを開いて、関連する検索条件および検索結果表を表示します。

3. 必要に応じて検索条件を入力し(表13-0)、「検索」ボタンをクリックします。

4. 「検索結果」表で、必要なリソース定義をクリックします。

- アクション: 「アクション」メニュー項目を選択して、ドメインに新規リソースを作成するか、表で選択したリソースを編集または削除します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

- 編集: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

5. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

アプリケーション・ドメインのリソース定義の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメイン内のリソース定義を変更できます。

注意:
ポリシーに関連付けられているリソースの保護レベルが「保護」から「除外」に変更された場合、その変更は失敗します。まずポリシーからリソースを削除してから、変更を加えて、リソースをポリシーに追加してください。

前提条件

目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。

関連項目:
「アプリケーション・ドメインのリソース定義ページについて」

アプリケーション・ドメインのリソース定義を表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「アプリケーション・ドメイン」ノード
目的のドメイン

2. 「リソース定義の検索」で説明したように、リソースを検索します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: 必要に応じて定義を変更して、「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

アプリケーション・ドメインからのリソース定義の削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインからリソースを削除できます。

前提条件

削除するリソース定義がポリシーで使用されないことを確認します。

アプリケーション・ドメインからリソース定義を削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. 「リソース定義の検索」で説明したように、リソースを検索します。

3. オプション: 目的のリソース定義をダブルクリックして削除対象であることを確認し、ページを閉じます。

4. 目的のリソース定義の名前をクリックして、ツール・バーの「削除」ボタンをクリックします。

5. 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

6. 必要に応じてこの手順を繰り返して、アプリケーション・ドメインの他のリソースを削除します。

特定のリソースの認証ポリシーの定義

1つの認証ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認証ポリシーの変更、新しいポリシーの追加および認証ポリシーへのリソースの割当てを開始できます。

自動的に生成されたアプリケーション・ドメインでは、次の認証ポリシーがデフォルトとしてシードされ、管理者のタスクを効率化できます。

- 保護されているリソース

- パブリック・リソース

関連項目:
「アプリケーション・ドメインおよびポリシーの詳細分析」

この項の内容は次のとおりです。

- 認証ポリシー・ページについて

- 認証ポリシーおよびリソースの追加

- 認証ポリシーの検索

- 認証ポリシーの表示または編集

- 認証ポリシーの削除

認証ポリシー・ページについて

管理者は、認証ポリシーを使用して特定のリソースを保護できます。認証ポリシーは、ポリシーで制御されたリソースの唯一の認証方式を提供します。

各認証ポリシーにより、Oracle Access Managerの十分な信頼レベルを提供してリクエストを実行するユーザーにアクセス権を付与するために実行する必要がある検証のタイプが定義されます。

認証ポリシーはローカルです。単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。

図13-11は、アプリケーション・ドメイン内の「認証ポリシー」ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。この例は、IAM Suiteアプリケーション・ドメインのものです。

図13-11 認証ポリシー: IAM Suiteアプリケーション・ドメイン

「図13-11 認証ポリシー: IAM Suiteアプリケーション・ドメイン」の説明

表13-6は、認証ポリシーの要素を示しています。IAM Suiteアプリケーション・ドメインが例として示されています。

表13-6 認証ポリシーの要素および説明

要素

説明

名前

ナビゲーション・ツリーの識別子として使用される一意の名前。

説明

認証ポリシーを説明するオプションの一意のテキスト。

認証スキーム

ユーザー認証のためにポリシーで使用される単一の事前定義された認証スキーム。関連項目: 詳細は、「認証スキームの管理」を参照してください。

成功URL

認証の成功時に使用されるリダイレクトURL。

失敗URL

認証の失敗時に使用されるリダイレクトURL。

IDアサーション

エンド・ユーザー(およびそのOAMセッション)を表すOracle Access Managerから発行されたトークンのID伝播ユースケース・シナリオで必要です。

IDアサーション・トークンは、正常に認証された後に生成され、レスポンス(名前が"OAM_IDENTITY_ASSERTION"で値がSAMLトークンというHTTPヘッダー)として返されます。

OAM 11gによって保護されているWebアプリケーションであるOracle Security Token Serviceクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、クライアントはOracle Security Token Serviceから、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。

IDプロバイダ(Oracle Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

IDアサーション・トークン・コンシューマ(Oracle Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

関連項目: 「シナリオ: OAMトークンを使用したアイデンティティ伝播」

リソース

リストから選択されたリソースのURL。リストされているURLは、以前にアプリケーション・ドメインに追加されました。認証ポリシーで保護する1つ以上のリソースを追加できます。リソース定義は、ポリシーに含める前にアプリケーション・ドメイン内に存在する必要があります。

関連項目: 「認証ポリシーのリソースについて」

レスポンス

Webエージェントで実行される必須処理(認証後のアクション)。認証に成功すると、保護されたアプリケーションをホストするアプリケーション・サーバーは、これらのレスポンスに基づいてユーザー・アイデンティティをアサートできる必要があります。認証に失敗すると、ブラウザはリクエストを事前構成されたURLにリダイレクトします。

関連項目: 「SSOのポリシー・レスポンスの概要」

認証ポリシーのリソースについて

認証ポリシーで保護する1つ以上のリソースを追加できます。認証ポリシー・ページの「リソース」タブには、リソースURLを入力できる表が用意されています。アプリケーション・ドメイン内の定義されたリソースから選択できるリストも用意されています。

リソースを追加するには、「+」ボタンをクリックして、リストから選択します。リソースを削除するには、「リソース」表から名前を選択して、表の「削除」ボタンをクリックします。

認証ポリシーおよびリソースの追加

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証ポリシーおよびリソースをアプリケーション・ドメインに追加できます。認証ポリシーの事前構成された認証スキームまたはカスタム認証スキームを使用できます。

関連項目:

- 「認証ポリシー・ページについて」

- 「認証スキームの管理」

前提条件

ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。

特定のリソースの認証ポリシーを追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. ナビゲーション・ツリーで、「認証ポリシー」をクリックし、次に「作成」ボタンをクリックして、新しいページを開きます。

3. 次の一般的なポリシーの詳細を追加します。

- 名前

- 認証スキーム

4. 次のグローバル・ポリシーの要素および仕様を追加します(表13-6)。

- 説明(オプション)

- 成功URL

- 失敗URL

- IDアサーション

5. リソースを追加します。

- 認証ポリシー・ページの「リソース」タブをクリックします。

- タブの「追加」ボタンをクリックします。

- リストからURLを選択します。

- 必要に応じてこれらの手順を繰り返して、リソースを追加します。

6. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

7. ポリシーのレスポンスを追加します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

8. 終了する場合はページを閉じます。

認証ポリシーの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認証ポリシーを検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

アプリケーション・ドメインの認証ポリシーを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化します。

2. 検索タイプ・リストから「認証ポリシー」を選択して、検索を定義します。

3. テキスト・フィールドで、検索するポリシーの正確な名前を入力します。次に例を示します。

my_AuthNPolicy

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

認証ポリシーの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインの認証ポリシーを変更できます。これには、認証スキームの変更、リソースやレスポンスの追加または削除および成功または失敗URLの変更が含まれます。

関連項目:
「認証ポリシー・ページについて」

認証ポリシーを表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認証ポリシー

2. 目的の認証ポリシー名をダブルクリックします。
認証ポリシーが開いて、「リソース」タブを使用できます。

3. 一般的なポリシー要素は次のとおりです。

- 名前

- 認証スキーム

4. グローバル・ポリシー要素: 必要に応じて編集します(表13-6を参照してください)。

- 説明

- 成功URL

- 失敗URL

- Oracle Security Token ServiceのIDアサーション

5. リソース: 「リソース」タブをクリックして、必要に応じて次のタスクを実行します。

- 追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。

- 削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。

6. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

7. レスポンス: レスポンスを表示または編集します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

8. 終了する場合はページを閉じます。

認証ポリシーの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインから認証ポリシーを削除できます。

ポリシーを削除する場合、すべてのリソース定義がアプリケーション・ドメイン内に残ります。ただし、ポリシーおよびすべてのレスポンスが削除されます。

関連項目:
「認証ポリシー・ページについて」

次の手順は、全体のポリシーの削除方法を示しています。ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。

認証ポリシーを削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認証ポリシー

2. オプション: 目的のポリシー名をダブルクリックして内容を確認し、ページを閉じます。

3. すべてのレスポンスを削除します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

4. ナビゲーション・ツリーで、認証ポリシーの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。

5. 確認ウィンドウで、確認して「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

6. このポリシーで制御されたリソースが別のポリシーに追加されていることを確認します。

特定のリソースの認可ポリシーの定義

1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。

自動的に生成されるアプリケーション・ドメインでは、デフォルトとして次の認可ポリシーがシードされます。

- 保護されているリソース

- パブリック・リソース

関連項目:
「アプリケーション・ドメインおよびポリシーの詳細分析」

リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認可ポリシーの変更、新しいポリシーの追加および認可ポリシーへのリソースの追加を開始できます。この項の内容は次のとおりです。

- 特定のリソースの認可ポリシーについて

- 認可ポリシーおよび特定のリソースの追加

- 認可ポリシーの検索

- 認可ポリシーおよびリソースの表示または編集

- 認可ポリシーの削除

特定のリソースの認可ポリシーについて

管理者は、認証されたユーザーまたは環境の属性に基づいて、1つ以上のリソースへのアクセスを保護する認可ポリシーを作成できます。認可ポリシーは、ポリシーに含まれるリソースの唯一の認可保護を提供します。

認可ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。

単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。

図13-12は、アプリケーション・ドメイン内の認可ポリシー・ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。IAM Suiteアプリケーション・ドメインが例として示されています。

図13-12 「認可ポリシー」ページ: IAM Suiteアプリケーション・ドメイン

「図13-12 「認可ポリシー」ページ: IAM Suiteアプリケーション・ドメイン」の説明

表13-7は、認可ポリシーの要素を示しています。ドメインに関係なく要素は同じで、詳細のみ異なります。IAM Suiteアプリケーション・ドメインが例として示されています。

表13-7 認可ポリシーの要素および説明

要素

説明

名前

ナビゲーション・ツリーの識別子として使用される一意の名前。

説明

認可ポリシーを説明するオプションの一意のテキスト。

成功URL

認可の成功時に使用されるリダイレクトURL。

失敗URL

認可の失敗時に使用されるリダイレクトURL。

暗黙的な制約の使用

アクセスを許可(または拒否)します。認可ポリシーで設定して、特定のクラスの認可制約がない場合のアクセスを許可します。

デフォルト: 選択(有効)

「認可制約の概要」も参照してください。

IDアサーション

エンド・ユーザー(およびそのOAMセッション)を表すOAMから発行されたトークンのID伝播ユースケース・シナリオで必要です。

OAM 11gによって保護されているWebアプリケーションであるOSTSクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、クライアントはOSTSから、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。

IDプロバイダ(Oracle Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

IDアサーション・トークン・コンシューマ(Oracle Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

関連項目: 「シナリオ: OAMトークンを使用したアイデンティティ伝播」

「リソース」タブ

認可ポリシーで保護される1つ以上の事前定義されたリソースURL。

「制約」タブ

「認可制約の概要」も参照してください。

「レスポンス」タブ

「SSOのポリシー・レスポンスの概要」も参照してください。

認可ポリシーおよび特定のリソースの追加

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーをアプリケーション・ドメインに追加できます。

前提条件

ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。

関連項目:
「特定のリソースの認可ポリシーについて」

認可ポリシーおよびリソースを追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン

2. ナビゲーション・ツリーで、「認可ポリシー」をクリックし、次に「作成」ボタンをクリックします。

3. 認可ポリシーの一意の名前を入力します。

4. グローバル・ポリシー要素: 固有の詳細を入力します(表13-7を参照してください)。

- 説明(オプション)

- 成功URL

- 失敗URL

- 暗黙的な制約の使用

- Oracle Security Token ServiceのIDアサーション

5. リソース

- 「リソース」タブで、「追加」ボタンをクリックします。

- 提供されたリストから、リソースURLをクリックします。

- これらの手順を繰り返して、リソースをポリシーに追加します。

6. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

7. 制約: 認可制約を追加します(「認可ポリシー制約の定義」を参照してください)。

8. レスポンス: SSOのレスポンスを追加または編集します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

9. 終了する場合はページを閉じます。

認可ポリシーの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認可ポリシーを検索できます。

関連項目:
「ポリシー構成検索コントロールについて」

認可ポリシーを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化します。

2. 検索タイプ・リストから「認証ポリシー」を選択して、検索を定義します。

3. テキスト・フィールドで、検索するポリシーの正確な名前を入力します。次に例を示します。

my_AuthZPolicy

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

認可ポリシーおよびリソースの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメイン内の認可ポリシーを表示または変更できます。

関連項目:
「特定のリソースの認可ポリシーについて」

認可ポリシーを表示または編集するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. 目的のポリシー名をダブルクリックして、詳細を表示します。

3. グローバル要素: 必要に応じて編集します(表13-7を参照してください)。

- 説明(オプション)

- 成功URL

- 失敗URL

- 暗黙的な制約の使用

- Oracle Security Token ServiceのIDアサーション

4. リソース: 「リソース」タブをクリックして、必要に応じて次のタスクを実行します。

- 追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。

- 削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。

5. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

6. 制約: これらの制約を表示または編集します(「認可ポリシー制約の表示、編集または削除」を参照してください)。

7. レスポンス: これらのレスポンスを表示または編集します(「SSOのポリシー・レスポンスの表示、編集または削除」を参照してください)。

8. 終了する場合はページを閉じます。

認可ポリシーの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーまたはポリシー内のリソースを削除できます。

全体のポリシーを削除する場合、すべてのリソース定義がアプリケーション・ドメイン内に残ります。ただし、アクセスを制御する認可ポリシー、制約およびレスポンスが削除されます。

注意:
ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。

関連項目:
「特定のリソースの認可ポリシーについて」

前提条件

ポリシーを削除する前または後に、ポリシーで制御されたリソースを別の認可ポリシーに割り当てます。

認可ポリシーを削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. オプション: ポリシー名をダブルクリックして内容を確認し、終了したらページを閉じます。

3. ポリシー名をクリックし、ツール・バーの「削除」ボタンをクリックします。

4. 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

5. ポリシーがナビゲーション・ツリーにリストされていないことを確認します。

SSOのポリシー・レスポンスの概要

各ポリシーは、1つ以上の認証または認可レスポンスあるいはその両方をオプションで含むことができます。レスポンスは、Webエージェントで実行される後処理のアクション(必須処理)です。

注意:
トークン発行ポリシーにはレスポンスがありません。

この項の内容は次のとおりです。

- SSOの認証および認可ポリシー・レスポンスについて

- ポリシー・レスポンスの言語について

- ポリシー・レスポンスのネームスペースおよび変数名について

- SSOのポリシー・レスポンスの構築について

- ポリシー・レスポンス処理について

SSOの認証および認可ポリシー・レスポンスについて

管理者は、認証または認可が成功した後に実行する必要があるアクションを宣言するレスポンスを定義できます。認証および認可データがクライアント(通常はWebエージェント)に戻されます。

ポリシー・レスポンスにより、情報をセッションまたはアプリケーションに挿入し、SSOを有効化するために後で情報を抽出できます。たとえば、アイデンティティ・マッピングを顧客アプリケーションに挿入するか、エージェントまたはアプリケーションでアクションを実行できます。

認証または認可の成功および失敗に応じて指定されるレスポンスによっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。

注意:
OAM 10gでは、特定の順序のURLのリダイレクトでのみ、アプリケーションのデータの経路を提供しました。

デフォルトのレスポンスは提供されません。図13-13は、Oracle Access Managerコンソールの管理者に定義された認可ポリシー・レスポンスを示しています。認可レスポンスは、認可制約と組み合せて操作できます。

図13-13 コンソールの認可ポリシー・レスポンス

「図13-13 コンソールの認可ポリシー・レスポンス」の説明

各レスポンスは、2つの入力(タイプおよび式)と1つの出力(評価された式の値)で構成されます。式は、式を処理する場合の値の構築方法を宣言します。レスポンス・タイプは、値文字列を使用して実行するアクションの形式を定義します。

- 認証ポリシーは、ユーザーのアイデンティティを決定します。各認証ポリシーには、認証スキームおよびレスポンス(式)が必要です。

- 認可ポリシーは、リソースへのユーザーのアクセス権を付与するかどうかを決定します。各認可ポリシーには、認可制約およびレスポンス(式)が必要です。

管理者は、表13-8で説明されているとおり、Oracle Access Managerコンソールのレスポンスを設定します。

表13-8 レスポンス要素

要素

説明

名前

このレスポンスと同じメカニズム(タイプ)を使用する他のレスポンスを区別する一意の名前。

タイプ

レスポンスを伝達するために使用されるメカニズム。値文字列を使用して実行するアクションの形式。

- HEADER(ヘッダー変数): 定義された値を使用して実行するアクション(事前定義されたHTTPヘッダー名を使用したユーザーIDのアサーションなど)を指示するダウンストリーム・アプリケーションのHTTPリクエスト・ヘッダーを設定します。

- SESSION: 定義されたセッション変数名および値に基づいて、シングル・サインオンを有効化するためにクライアントがユーザー・セッション内の属性を設定します。

- COOKIE: 通常はWebエージェントによって設定される認証セッションCookie内の変数名および値を設定して、シングル・サインオンを有効化します。
Cookieなしモードの場合、WebgateからCookieを格納するWebキャッシュが現在使用されています。ただし、Cookieなしモードの場合、エンド・アプリケーションでCookieにアクセスしてCookieを使用できません。

値

変数として設定されるレスポンスの式。

詳細は、「ポリシー・レスポンスの言語について」を参照してください。

ポリシー・レスポンスの言語について

次の2つの主な構造とともに非常に小規模なドメイン固有言語(DSL)を使用して、OAM 11g認証および認可レスポンスを定義します。

- リテラル文字列: This is a valid expressionなどです。

- 変数の参照

- ドル記号の接頭辞($)を使用して宣言します。

- ネームスペース$namespace.var_nameでスコープされます。

注意:
変数に$ns.name.attribute属性が含まれる場合があります。

ポリシー・レスポンスのネームスペースおよび変数名について

ネームスペース・メカニズムを使用すると、次の変数タイプでシングル・サインオンが有効化します。

- リクエスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報

- セッション: ユーザー・セッションの詳細

- ユーザー: ユーザーの詳細(ユーザーID、グループおよび属性情報)

詳細は、次の表を参照してください。

- 表13-9「シングル・サインオンのネームスペース・リクエスト変数」

- 表13-10「シングル・サインオンのネームスペース・セッション変数」

- 表13-11「ネームスペース・ユーザー変数」

表13-9 シングル・サインオンのネームスペース・リクエスト変数

ネームスペース

説明

agent_id

リクエストしているエージェントの名前

client_ip

ユーザー・ブラウザのIPアドレス

policy_appdomain

リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前

policy_res

リクエストに一致するリソース・ホストIDおよびURLパターン

res_policy

リクエストに一致する特定のポリシーの名前

res_host

リクエストしたリソースのホスト名

res_port

リクエストしたリソースのポート番号

res_type

リクエストしたリソースのタイプ

res_url

リクエストしたリソースURL

表13-10 シングル・サインオンのネームスペース・セッション変数

ネームスペース

説明

attr

名前が変数属性として渡される任意のセッション属性の参照。前のリクエストでセッション・レスポンスを実行することで、値がセッションにバインドされています。

authn_level

セッションの現在の認証レベル

authn_scheme

現在の認証レベルを実現するために実行される認証スキームの名前

count

セッションにバインドされたユーザーのセッション数

creation

セッションの作成時間

expiration

セッションの有効期間

表13-11 ネームスペース・ユーザー変数

ネームスペース

説明

attr

名前が変数属性として渡される任意のLDAP属性の参照。

groups

ユーザーのグループ・メンバーシップのカンマ区切りリスト

userid

ユーザーID

user.id_domain

ユーザーのアイデンティティ・ドメイン(基本的にアイデンティティ・ストアと同じ)

guid

アイデンティティ・ストアでユーザー・エントリを特定する一意の識別子

SSOのポリシー・レスポンスの構築について

この項の内容は次のとおりです。

- 単純なレスポンス

- 複合的および複雑なレスポンス

単純なレスポンス

レスポンス・タイプとネームスペースおよび変数を決定した後、Oracle Access Managerコンソールでレスポンス属性を入力します。図13-14に示すように、単純なレスポンスはいくつかの認可レスポンスのいずれかのようになります。

図13-14 単純なレスポンスのサンプル

「図13-14 単純なレスポンスのサンプル」の説明

単純なレスポンスはスタンドアロンです。それぞれの先頭にドル記号($)が付けられ、変数値とドット(.)で区切られるネームスペースがその後に付けられます。次に例を示します。

$namespace1.var1

表13-12は、いくつかの単純なレスポンスおよびそれぞれに戻される内容の説明を示しています。

表13-12 単純なレスポンスおよび説明

名前

タイプ

値(単純な$ネームスペース.変数)

戻される環境変数および値

oam_literal

ヘッダー

これはレスポンス文字列です。

HTTP_OAM_LITERAL これはレスポンス文字列です。

oam_sessioncount

ヘッダー

$session.count

HTTP_OAM_SESSIONCOUNT 整数

oam_userid

ヘッダー

$user.userid

HTTP_OAM_USERID 名前

oam_ipaddress

ヘッダー

$request.client_ip

HTTP_OAM_IPADDRESS nnn.nn.nn.nnn

複合的および複雑なレスポンス

複合的または複雑なポリシー・レスポンスを作成する場合、管理者は、中括弧{}を使用してリテラルおよび変数を任意に結合して式を構築できます。コロン(:)はセパレータとして使用されます。次に例を示します。

${namespace1.var1}:${namespace2.var2}

リテラル文字列(LS): ${namespace1.var1}:${namespace2.var2}

LS: ${namespace1.var1}, LS:${namespace2.var2}

図13-15は、管理者によって定義されるいくつかの複雑なレスポンスを示しています。すべてがヘッダー・タイプ・レスポンスで、ダウンストリーム・アプリケーションで利用されるHTTPリクエストのヘッダー変数の値が設定されます。

図13-15 サンプルの複雑なレスポンス

「図13-15 サンプルの複雑なレスポンス」の説明

表13-13は、図13-15のような複雑なレスポンスを示しています。

表13-13 複雑なレスポンス

名前

値

戻される環境変数および値

oam_resinfo

ランタイム・リソース: ${request.res_host}:${request.res_port}${request.res_url}

HTTP_OAM_RESINFO

ランタイム・リソース: myhost.domain.com:1234/cgi-bin/myres3

oam_clientinfo

ランタイム・クライアント: エージェントID: ${request.agent_id}、ブラウザIP: $request.client_ip

HTTP_OAM_CLIENTINFO

ランタイム・クライアント: エージェントID: RREG_OAM、ブラウザIP: 123.45.67.891

oam_userinfo

${user.userid}のグループ: ${user.groups}、説明: ${user.attr.description}

HTTP_OAM_USERINFO

WebLogicのグループ: 管理者、説明: このユーザーはデフォルトの管理者です。

oam_sessioninfo

セッションの作成/有効期間/数: ${session.creation}/${session.expiration}/${session.count}

HTTP_OAM_SESSIONINFO

セッションの作成/有効期間/数: Tue Feb 23 17:47:42 PST 2011/Wed Feb 24 01:47:42 PST 2011/7

oam_app_user

$user.userid

HTTP_OAM_USERID 名前

詳細は、「ポリシー・レスポンス処理について」を参照してください。

ポリシー・レスポンス処理について

ポリシー・レスポンス処理は、認証レスポンスを再実行する認可リクエストの実行中に発生します。変数の参照に適切な値が入力され、すべての変数に値が設定されて認可値で一貫して設定できることを確認します。

一連の手順を実行して、レスポンスの式を処理します。

- スキャナ/トークナイザ

- パーサー

- インタープリタ
解釈中、値の変数の参照が解決します。処理後の結果は単純な文字列値で、エージェントに伝播されるか、将来の使用に備えてセッション内に保存されます。

最初の適用される認可リクエストの認可レスポンスとともに認証の成功レスポンスが保存され、“再実行”されます。

認可レスポンスの式は、式の評価(成功、失敗または未確定)に応じて実行されるアクションを作成します。

注意:
OAM 10gでは、認証Webgate構成内と同じ動作を示します。これは10g WebgateとともにOAM 11gを使用する場合も同様で、10g Webgateは常に認証用Webgateとして機能するOAM 11g資格証明コレクタに転送されます。

変数を参照すると、値または次の内容が戻されます。

- 変数が設定されていない場合、NOT FOUNDが戻されます。

- 変数がnull値に設定されている場合、NULLが戻されます。

注意:
次のレスポンスを確認します。

- ヘッダー

- セッション

- Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。

処理のないパススルー

処理しないでパススルーを実行する必要がある値は、\を使用して識別できます。次に例を示します。

\$1000

値$1000の結果が戻される値に表示されます。

SSOのポリシー・レスポンスの追加および管理

ポリシーおよびレスポンスを使用してシングル・サインオンを有効化し、他のディレクティブを上書きできます。この項のアクティビティを開始する前に、「SSOのポリシー・レスポンスの概要」を確認してください。

特に指定のないかぎり、この項の情報が認証および認可レスポンスに同等に適用されます。

- SSOのポリシー・レスポンスの追加

- SSOのポリシー・レスポンスの表示、編集または削除

SSOのポリシー・レスポンスの追加

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを追加できます。

前提条件

認可レスポンスを作成する前に認可制約を分析して、レスポンスによって適切なアクションが実行されることを確認します。既存の認証または認可ポリシーを使用するアプリケーション・ドメインが必要です。

関連項目:
「SSOのポリシー・レスポンスの概要」

ポリシー・レスポンスを追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー(または認証ポリシー)

2. 目的のポリシー名をダブルクリックして、ページを開きます。

3. 「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックします。

- 「名前」フィールドに、このレスポンスの一意の名前を入力します。

- 「タイプ」リストから、レスポンス・タイプ(セッション、ヘッダーまたはCookie)を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。たとえば、$namespace1.var1などです。

関連項目:
「ポリシー・レスポンスのネームスペースおよび変数名について」

- 必要に応じて繰り返します。

4. 「適用」をクリックして、確認ウィンドウを閉じます。

5. 終了する場合はページを閉じます。

6. 定義に基づいて、次のレスポンスを確認します。

- ヘッダー

- セッション

- Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。

SSOのポリシー・レスポンスの表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを表示または編集できます。

前提条件

既存の認証または認可ポリシーを使用するアプリケーション・ドメインが必要です。

関連項目:
「SSOのポリシー・レスポンスの概要」

ポリシー・レスポンスを表示、変更または削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー(または認証ポリシー)

2. 目的のポリシー名をダブルクリックして、ページを開きます。

3. レスポンス: 「レスポンス」タブをクリックして、必要に応じて先に進みます。

- レスポンスを追加します(「SSOのポリシー・レスポンスの追加」を参照してください)。

- 編集: 目的のレスポンスの名前、タイプまたは値をクリックして、必要に応じて編集して「適用」をクリックします。

- 削除: 目的のレスポンスをクリックして、「レスポンス」表の「削除」ボタンをクリックします。

4. レスポンス: 次のようにレスポンスを編集します。

1. 「レスポンス」タブをクリックします。

2. 目的のレスポンスの名前、タイプまたは値をクリックします。

3. 目的の変更を実行します。

4. 必要に応じて繰り返し、終了したら「適用」をクリックします。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 終了する場合はページを閉じます。

7. 定義に基づいて、次のレスポンスを確認します。

- ヘッダー

- セッション

- Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。

認可制約の概要

アプリケーション・ドメインの特定の認可ポリシー内のすべてのリソースに認可制約を適用するには、管理者が認可制約を指定する必要があります。

認可制約は、リソースのリクエストのコンテキストに基づいて特定のリソースのアクセスを付与または拒否するルールです。認可制約は、クライアントのリクエストに応答する前に満たす必要がある必須処理(要件)を定義します。

制約の評価により、認可ポリシーを着信リクエストに適用するかどうかが決定されます。認証に成功した後、適切な必須処理が有効になり、定義された認可レスポンスと連携して動作します。着信リクエストごとに、認可ポリシーによって制約が存在するかどうかが決定されます。認可中に制約が評価されます。

許可または拒否タイプの制約

各認可ポリシーは、リクエストしたリソースのアクセスを付与または拒否するかどうかを決定する1つ以上の認可制約を含むことができます。

認可制約は次のとおりです。

- 保護されたリソースへのアクセスを認可されるユーザーを指定する許可タイプの条件。

- 保護されたリソースへのアクセスを拒否されるユーザーを明示的に指定する拒否タイプの条件。

注意:
特定のポリシー内の制約を定義する場合、1つの結果(許可または拒否)のみが許可されます。

制約クラス

異なる制約クラスを使用すると、同じ認可ポリシー内に異なる制約を構成できます。たとえば、次の目的で制約を構成できます。

- 保護されたリソースのアクセスを許可または拒否するユーザーまたはユーザー・グループの識別。

- 保護されたリソースのアクセスを許可または拒否するIPアドレスの範囲の指定。

注意:
ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。

- 制約を適用する期間を定義する時間の設定。

ここでは、次の内容について説明します。

- 許可または拒否タイプ制約について

- 制約のユーザーおよびグループの分類について

- 制約および一般的な認可ポリシーの詳細について

- 「制約の追加」ウィンドウについて

- アイデンティティ・クラス制約について

- IP4Rangeクラス制約について

- 一時的クラス制約について

許可または拒否タイプ制約について

各認可制約により、許可または拒否タイプの結果を含むことができます。「暗黙的な制約の使用」オプションを認可ポリシーに設定して、認可制約がない場合のアクセスを許可できます。

アクセスの許可条件がユーザーに適用されない場合、ユーザーがポリシーの対象外となり、デフォルトでリクエストしたリソースへのユーザーのアクセスが拒否されます。

注意:
制約が定義されていない場合および「暗黙的な制約の使用」が有効ではない場合、アクセスが拒否されます。

制約のユーザーおよびグループの分類について

ユーザーおよびグループを分析して明示的にアクセスを許可または拒否するユーザーを決定する場合、ポリシーおよび制約に同じ情報を使用することをお薦めします。たとえば、特定のユーザー・グループ(アイデンティティ・クラス)に制約される認可ポリシーがある場合、特定の時間(一時的クラス)に制約される認可ポリシーがある可能性があります。

注意:
任意の条件でアクセスを拒否されるユーザーについては気にしないでください。制約が適用されない場合、デフォルトでアクセスが拒否されます。

ユーザーを分類する場合、ユーザーおよびユーザー・グループを異なる条件が適用されるグループに分割することをお薦めします。たとえば、制約を使用して、ユーザーがリソースにアクセスできる時間やリクエストを実行する必要があるコンピュータなどを決定できます。

マーケティング・グループのユーザーが特定のプロジェクト・グループに属し、人事管理グループのユーザーもプロジェクト・グループに属する場合などの一部のユーザーが複数のカテゴリに該当する場合、両方のカテゴリにユーザーを配置します。ユーザーは、2つの制約の条件を満たす必要があります。

制約に基づく認可レスポンスのガイドライン

制約クラスごとに、認可されたユーザーに発生するレスポンス・アクションを検討します。たとえば、戻されたユーザー・プロファイル情報を次のように下流のアプリケーションに渡すこともできます。

- ユーザーが認可されている場合、アプリケーションでカスタマイズされたメッセージをユーザーに表示できるように、ユーザーの共通名(cn)を別のアプリケーションに渡すことができます。

- ユーザーが認可されていない場合、セキュリティ目的でユーザーの情報を戻すこともできます。

制約および一般的な認可ポリシーの詳細について

図13-16に示すように、すべての制約定義が一般的な認可ポリシーの詳細とともに適用されます。

図13-16 「認可ポリシー」ページの一般詳細

「図13-16 「認可ポリシー」ページの一般詳細」の説明

表13-14は、共通の認可ポリシーの一般詳細を示しています。

表13-14 認可ポリシーの一般詳細

要素

説明

名前

ナビゲーション・ツリーの識別子として使用される一意の名前。

説明

認可ポリシーを説明するオプションの一意のテキスト。

成功URL

認可の成功時に使用されるリダイレクトURL。

失敗URL

認可の失敗時に使用されるリダイレクトURL。

暗黙的な制約の使用

アクセスを許可(または拒否)します。認可ポリシーで設定して、特定のクラスの認可制約がない場合のアクセスを許可します。

デフォルト: 選択(有効)

IDアサーション

エンド・ユーザー(およびそのOAMセッション)を表すOAMから発行されたトークンのID伝播ユースケース・シナリオで必要です。

OAM 11gによって保護されているWebアプリケーションであるOSTSクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、クライアントはOSTSから、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。

IDプロバイダ(Oracle Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

IDアサーション・トークン・コンシューマ(Oracle Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

関連項目: 「シナリオ: OAMトークンを使用したアイデンティティ伝播」

「制約の追加」ウィンドウについて

管理者が制約を認可ポリシーに追加すると、制約の名前、クラスおよび結果タイプを取得する図13-17のウィンドウが表示されます。送信されると、この情報を使用して、管理者が指定する必要がある制約詳細のコンテナを作成します。

図13-17 「制約の追加」ウィンドウ

「図13-17 「制約の追加」ウィンドウ」の説明

表13-15は、「制約の追加」ウィンドウ要素を示しています。

表13-15 「制約の追加」ウィンドウの要素

要素

説明

名前

この制約の一意の名前。

クラス

1つのクラス(アイデンティティ、IP4範囲または一時的)のみを指定できます。

タイプ

結果タイプ: アクセスを許可または拒否します。

選択済の追加

このボタンをクリックして、制約コンテナの作成を開始します。

一般的な詳細を指定した後、図13-18に示すように、制約コンテナがポリシー・ページに追加および表示されます。ここでは、名前、クラスおよびタイプが表示されます。ただし、ウィンドウ・コントロール(図の赤い円)により、管理者は選択された制約の詳細を指定できるウィンドウを開くことができます。

図13-18 「認可ポリシー」ページの制約コンテナ

「図13-18 「認可ポリシー」ページの制約コンテナ」の説明

次の項に示すように、制約の詳細は選択された制約クラスに固有です。

- アイデンティティ・クラス制約について

- IP4Rangeクラス制約について

- 一時的クラス制約について

アイデンティティ・クラス制約について

アイデンティティ制約クラスを使用する場合、管理者はユーザー移入を制約に追加する必要があります。制約コンテナを開いた後、定義されたユーザー移入が表示されます。他の制約のように、アイデンティティ制約および一時制約と組み合せてこれを使用できます。

ユーザー移入が指定されない場合、図13-20のような画面が表示されます。

図13-19 アイデンティティ・クラス制約の詳細: 「選択したユーザーとグループ」表

「図13-19 アイデンティティ・クラス制約の詳細: 「選択したユーザーとグループ」表」の説明

図13-20は、「選択したユーザーとグループ」表の「追加」ボタンをクリックすると表示される「ユーザー移入エントリの追加」ウィンドウを示しています。この表でいくつかの移入(ユーザー、グループまたはすべて)から選択できます。

図13-20 アイデンティティ・クラスの「ユーザー移入エントリの追加」ウィンドウ

「図13-20 アイデンティティ・クラスの「ユーザー移入エントリの追加」ウィンドウ」の説明

表13-16は、「ユーザー移入エントリの追加」要素を示しています。

表13-16 アイデンティティ・クラス制約の詳細

要素

説明

検索

使用可能な検索タイプのリスト: ユーザー、グループまたはすべて

テキスト・フィールド

特定のユーザーまたはグループの名前を入力して、矢印ボタンをクリックします。

結果表

選択する検索結果を表示します。

選択済の追加

結果表から制約詳細ページに選択したユーザーまたはグループを追加します。

1つ以上の移入を選択した後に「選択済の追加」ボタンをクリックすると、図13-21のような画面が表示されます。

図13-21 「選択したユーザーとグループ」ウィンドウ

「図13-21 「選択したユーザーとグループ」ウィンドウ」の説明

制約としてこれらの詳細を保存するには、詳細ページの右上の「保存」ボタンをクリックします。

関連項目:
「アイデンティティ・クラス制約の定義」

IP4Rangeクラス制約について

IP4Range制約クラスを使用する場合、管理者は、アクセスを許可または拒否するIPアドレスの範囲を追加する必要があります。他の制約のように、アイデンティティ制約および一時制約と組み合せてこれを使用できます。

図13-22に示すように、999.999.999.999形式で各IPアドレスを指定する必要があります。

図13-22 IP4Rangeクラス制約

「図13-22 IP4Rangeクラス制約」の説明

関連項目:
「IP4Rangeクラス制約の定義」

一時的クラス制約について

一時制約クラスを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の制約のように、アイデンティティ制約およびIP4Range制約と組み合せてこれを使用できます。

図13-20では何も選択されていませんが、デフォルトですべての曜日が有効です。

図13-23 一時制約クラスの詳細ページ

「図13-23 一時制約クラスの詳細ページ」の説明

グリニッジ標準時(GMT)の24時間制に基づくHH:MM:SS(時間、分、秒)形式で期間を指定する必要があります。深夜は00:00:00(開始)に指定します。24:59:59で1日が終了します。

表13-17 一時制約クラスの詳細

要素

説明

タイプ

結果タイプ: アクセスを許可または拒否します。

開始時間

注意: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。

この制約が開始される時間、分および秒を指定します。

注意: 時間はグリニッジ標準時(GMT)に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。

終了時間

この制約が終了する時間、分および秒を指定します。

日

このポリシーがアクティブな日を指定します。

デフォルト: すべての日(ただし、ここでは選択されていません。)

このページを閉じる前に、詳細を保存します。

関連項目:
「一時的クラス制約の定義」

認可ポリシー制約の定義

この項の内容は次のとおりです。

- アイデンティティ・クラス制約の定義

- IP4Rangeクラス制約の定義

- 一時的クラス制約の定義

- 認可ポリシー制約の表示、編集または削除

アイデンティティ・クラス制約の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアイデンティティ・クラス制約をアプリケーション・ドメインに追加できます。

注意:
別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。

前提条件

アプリケーション・ドメインがすでに存在する必要があります。

関連項目:
「アイデンティティ・クラス制約について」

アイデンティティ・クラス制約を認可ポリシーに追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. 目的のポリシー名をダブルクリックして、ページを開きます(または、ツール・バーの「編集」コマンド・ボタンをクリックします)。

3. 「制約」タブをクリックします。

4. 「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウ(表13-15)を表示します。

- 「名前」フィールドに、この制約の一意の名前を入力します。

- 「クラス」リストから、制約タイプとして「アイデンティティ」を選択します。

- 「タイプ」の横のオプション・ボタン(「許可」または「拒否」)をクリックします。

- 「制約の追加」ウィンドウの「選択済の追加」をクリックします。

- 表の新しい制約をハイライト表示して、詳細表の「追加」ボタンをクリックします。

- ユーザー移入エントリの追加: 「ユーザー」、「グループ」または「すべて」を選択します。目的の検索基準を入力して、目的の結果を選択し、「選択済の追加」をクリックします。

- 詳細ウィンドウをスクロールして定義を確認し、「保存」をクリックします。

- 必要に応じて繰り返します。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 終了する場合はページを閉じます。

7. 制約を確認します。

IP4Rangeクラス制約の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用してIP4範囲クラス制約をアプリケーション・ドメインに追加できます。

注意:
ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。

前提条件

アプリケーション・ドメインが存在する必要があります。

注意:
別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。

関連項目:
「IP4Rangeクラス制約について」

IP4範囲クラス制約を認可ポリシーに追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. 目的のポリシー名をダブルクリックして、ページを開きます。

3. 「制約」タブをクリックします。

4. 「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウ(表13-15)を表示します。

- 「名前」フィールドに、この制約の一意の名前を入力します。

- 「クラス」リストから「IP4範囲」を選択します。

- 「タイプ」の横のオプション・ボタン(「許可」または「拒否」)をクリックします。

- 「制約の追加」ウィンドウの「選択済の追加」をクリックします。

5. 目的のIPアドレス範囲を追加します(表13-16を参照してください)。

- 「開始」フィールドに範囲の開始を入力します。

- 「終了」フィールドに範囲の終了を入力します。

- 「タイプ」の横のオプション・ボタン(「許可」または「拒否」)をクリックします。

- 「保存」をクリックします。

6. 「適用」をクリックして、確認ウィンドウを閉じます。

7. IP4範囲制約を確認します。

一時的クラス制約の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して一時的クラス制約をアプリケーション・ドメインに追加できます。

注意:
別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。

前提条件

アプリケーション・ドメインが存在する必要があります。

関連項目:
「一時的クラス制約について」

一時的クラス制約を認可ポリシーに追加するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. 目的のポリシー名をダブルクリックして、ページを開きます。

3. 「制約」タブをクリックします。

4. 「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウを表示します。

- 「名前」フィールドに、この制約の一意の名前を入力します。

- 「クラス」リストから、「一時的」を選択します(表13-15を参照してください)。

- 「タイプ」の横のオプション・ボタン(「許可」または「拒否」)をクリックします。

- 「制約の追加」ウィンドウの「選択済の追加」をクリックします。

5. 一時的な詳細の追加(表13-17): 制約の名前をダブルクリックして、詳細パネルを拡張します。

- 制約タイプの横のオプション・ボタン(「許可」または「拒否」)をクリックします。

- 開始時間を入力します。

- 終了時間を入力します。

- この制約を適用する曜日をクリックします(またはすべてを空白にして毎日を指定します)。

- 「保存」をクリックします。

- 必要に応じて繰り返します。

6. 「適用」をクリックして、確認ウィンドウを閉じます。

7. 一時制約を確認します。

認可ポリシー制約の表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアイデンティティ・クラス制約をアプリケーション・ドメインに追加できます。

前提条件

アプリケーション・ドメインおよび認可ポリシーがすでに存在します。

関連項目:
「認可制約の概要」

認可ポリシーの制約を表示、編集または削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー

2. 目的のポリシー名をダブルクリックして、ページを開きます。

3. 「制約」タブをクリックします。

4. 制約詳細の表示: 制約名を含む行をクリックして、下部のパネルの詳細を表示します。

5. 制約の編集: 制約名を含む行をクリックして、次の項に従って詳細を変更およびすぐに保存します。

- 「アイデンティティ・クラス制約の定義」

- 「IP4Rangeクラス制約の定義」

- 「一時的クラス制約の定義」

6. 制約の削除: 削除する制約をクリックして、「制約」タブの「削除」ボタンをクリックします。

7. 「適用」をクリックして、確認ウィンドウを閉じます。

8. 終了する場合はページを閉じます。

9. リソースにアクセスして結果を評価して、制約を確認します。

アプリケーション・ドメインの認証および認可の検証

ここでの手順は、エージェント登録と認証および認可ポリシーを操作できることを確認するいくつかの方法を示しています。手順は、OAMエージェントおよびOSSOエージェント(mod_osso)でほとんど同じです。ただし、OSSOエージェントは認証ポリシーのみ使用し、認可ポリシーは使用しません。

前提条件

- アクセス権を付与されるユーザーおよびグループは、OAM 11gに登録されるプライマリLDAPユーザー・アイデンティティ・ストアに存在する必要があります。

- OAM 11gで操作するためにエージェントを登録する必要があります。登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。

- アプリケーション・ドメイン、認証ポリシーおよび認可ポリシーを構成する必要があります。

関連項目:
第14章「アクセス・テスターを使用した接続とポリシーの検証」

認証およびアクセスを確認するには、次の手順を実行します。

1. Webブラウザを使用すると、登録されたエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。

http://myWebserverHost.us.abc.com:8100/resource1.html

2. ログイン・ページにリダイレクトしていることを確認します。

3. サインイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「サインイン」をクリックします。

4. リソースにリダイレクトしていることを確認し、次の作業を実行します。

- 成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。

- 失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。

- 失敗した認証: 有効な資格証明を使用して再度サインインします。

- URL...のアクセスの拒否: このリソースのアクセスにこのユーザーIDが認可されていません。

- 使用不能なリソース: リソースが使用できることを確認します。

- 不正なリダイレクトURL: Oracle Access ManagerコンソールのリダイレクトURLを確認します。

例: 事前シード済のIAM Suiteアプリケーション・ドメインおよびポリシー

IAM Suite認証ポリシー、スキームおよびリソース

次の図は、IAM Suiteアプリケーション・ドメインの認証ポリシーを示しています。

- 図13-24「OAM Admin Console Policy、スキームおよびリソース」

- 図13-25「Protected HigherLevel Policy、LDAPSchemeおよびリソース」

- 図13-26「Protected LowerLevel Policy、認証スキームおよびリソース」

- 図13-27「Public Policy、匿名スキームおよびリソース」

図13-24 OAM Admin Console Policy、スキームおよびリソース

「図13-24 OAM Admin Console Policy、スキームおよびリソース」の説明

図13-25 Protected HigherLevel Policy、LDAPSchemeおよびリソース

「図13-25 Protected HigherLevel Policy、LDAPSchemeおよびリソース」の説明

図13-26 Protected LowerLevel Policy、認証スキームおよびリソース

「図13-26 Protected LowerLevel Policy、認証スキームおよびリソース」の説明

図13-27 Public Policy、匿名スキームおよびリソース

「図13-27 Public Policy、匿名スキームおよびリソース」の説明

IAM Suite認可ポリシー

図13-28は、IAM Suiteアプリケーション・ドメインの認可ポリシーを示しています。明示的な制約またはレスポンスはありません。「暗黙的な制約の使用」がデフォルトで選択されており、特定のクラスの認可制約がない場合のアクセスを許可します。定義された明示的な制約はありません。

図13-28 IAM Suite認可ポリシー

「図13-28 IAM Suite認可ポリシー」の説明

IAM Suiteトークン発行ポリシー

図13-29は、IAM Suiteアプリケーション・ドメインのIAM Suiteトークン発行ポリシーを示しています。「暗黙的な制約の使用」がデフォルトで選択されており、特定のクラスの認可制約がない場合のアクセスを許可します。定義された明示的な制約はありません。

図13-29 IAM Suiteトークン発行ポリシーおよびリソースURL

「図13-29 IAM Suiteトークン発行ポリシーおよびリソースURL」の説明

関連項目:
トークン発行ポリシーの詳細は、「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」を参照してください。

14 アクセス・テスターを使用した接続性とポリシーの検証

Oracle Access Managerのアクセス・テスターを使用することにより、ITの専門家や管理者は、登録されたOAMエージェントとOAM 11gサーバーの連携をシミュレートして、エージェント接続に関わる問題のトラブルシュートを容易にしたり、ポリシー定義をテストできます。この章では、Oracle Access Managerのアクセス・テスターとその使用法の概要を示します。内容は次のとおりです。

- 前提条件

- OAM 11gアクセス・テスターの概要

- アクセス・テスターのインストールと起動

- アクセス・テスター・コンソールとナビゲーションの概要

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

前提条件

この章に示すタスクを実行するには、次の前提条件を満たす必要があります。

- Oracle Access ManagerコンソールおよびOAMサーバーが実行中であることを確認します。

- 第13章の説明に従い、1つまたは複数のリソースのアプリケーション・ドメインとポリシーを確認します。

OAM 11gアクセス・テスターの概要

アクセス・テスターは移植可能なスタンドアロンのJavaアプリケーションで、Oracle Access Manager 11gに同梱されています。アクセス・テスターは、個々のIT専門家や管理者とOAMサーバー間の機能的なインタフェースを提供します。

IT専門家はアクセス・テスターを使用して接続を検証し、物理的デプロイメントのトラブルシュートを行うことができます。アプリケーション管理者は、アクセス・テスターを使用してポリシーを迅速に検証できます。この章で言う「管理者」とは、アクセス・テスターを使用する人物を表します。

アクセス・テスターは、OAMサーバーへのネットワーク接続を持つ任意のコンピュータから使用できます。また、グラフィカル・ユーザー・インタフェース(この章ではテスター・コンソールと呼びます)とコマンドライン・インタフェースの両方を使用できます。コマンドライン・モードを使用すれば、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。

実際のエージェントのように見せることによって、アクセス・テスターはポリシー構成設計やトラブルシューティングを助け、場合によってはOAMサーバーの応答性に関するトラブルシューティングに使用することもできます。アクセス・テスターを使用するときは実際のエンド・ユーザーのように振る舞う必要がありますが、アクセス・テスターが実際にエンド・ユーザーと通信することはありません。

アクセス・テスターを使用するには、Oracle Access Manager 11gによって保護されるアプリケーションまたはリソースの認証ポリシーと認可ポリシーを理解し、管理する必要があります。

アクセス・テスターを使用すれば次のことが可能です。

- エミュレート用のOAMサーバーに送信するリクエストの構成。エミュレート用OAMサーバーは、実際のエージェントが本番環境のOAMサーバーに送る内容をエミュレートします。

- リクエストをOAMサーバーに送信し、実際のエージェントが受信する応答と同じ応答を受信。アクセス・テスターはOAMアクセス・プロトコル(OAP)APIを使用し、OAMチャネルを介して、OAMサーバーの一部として実行中のOAMプロキシにリクエストを送信します。OAMサーバーはこのリクエストを処理してレスポンスを返します。

- サーバー・レスポンスの処理と表示。

- 実際のエージェントによるレスポンスの取り扱いと同様に処理を続行。たとえば、Webgateがリソースは証明書認証スキームによって保護されていると判断した場合、Webgateはhttp SSL接続からエンド・ユーザーの証明書を取得する必要があります。
証明書認証スキームの場合、アクセス・テスターにはエンド・ユーザーの資格証明として使用される証明書を参照させなければなりません。

先に挙げた機能を実行してエージェントをシミュレートすることに加えて、アクセス・テスターによって次の操作を行うことができます。

- 予定しているポリシー変更のパフォーマンス特性の確認

- 認証リクエストと認可リクエストの待機時間の追跡

- OAMサーバーのストレス・テストを実施してユーザー負荷に関連するローパフォーマンス・ウォーターマークまたはハイパフォーマンス・ウォーターマークを確立し、バックエンド・ハードウェアのサイズを決定

- コマンドライン・モードのみで複数の同時テスト(マルチスレッド・モード)を実行することにより、ポリシー・サーバーのストレス・テストを実施します。

- 継続的にパォーマンス・メトリックの確立と測定を行い、求められていた成果を検証

基本的な動作中、アクセス・テスターはサーバー・レスポンスに関して何の判定も行わず、そのレスポンスの可否判定も行いません(たとえばリソースXが保護されているかどうか、あるいはユーザーYがリソースXへのアクセスを認可されているかどうかなど)。アクセス・テスターを操作するときは、特定のレスポンスが適切なものかどうかを決定するポリシー構成に注意する必要があります。

アクセス・テスターは、複数の個別リクエストをグループ化してテスト・スクリプトにまとめ、それをOAMサーバーに送って処理することを可能にする拡張機能を備えています。このようなテスト実行の出力はアクセス・テスターで取得し、「確認済の」応答を含む同様ドキュメントとの比較に使用できます。このように、アクセス・テスターは、ポリシー構成の誤変更検出用の自動化テストに使用できます。

また、アクセス・テスターには、ポリシー・サーバーのストレス・テストを実施する目的でマルチスレッド機能が提供されています。マルチスレッドによる方法では、ポリシー・サーバーに接続する仮想テスト・クライアントの数、および各仮想クライアントでテスト・スクリプトを実行する反復回数を特定します。これにより、ポリシー・サーバーのストレス・テストを実施できます。

詳細は、この章の次の説明を参照してください。

- OAMエージェントとサーバーの相互運用性について

- アクセス・テスターのセキュリティと処理について

- アクセス・テスター・モードと管理者の対話操作について

OAMエージェントとサーバーの相互運用性について

OAMアーキテクチャにおける2つの主要なアクター・タイプは、ポリシー・サーバー(OAMサーバー)とOAMポリシー強制エージェント(Webgateまたはアクセス・クライアント)です。セキュリティ分野においてはエージェントがポリシー強制点(PEP)を表し、OAMサーバーがポリシー決定点(PDP)を表します。

- エージェントはhttpベース・アプリケーションなどのリソースのセキュリティを確保するゲートキーパーの役割を果たし、そのリソースにアクセスしようとするユーザーとのすべての対話操作を管理します。これは、ポリシー・サーバー(OAMサーバー)に保持されているアクセス制御ポリシーに従って実現されます。

- OAMサーバーの役割は、エージェントに対してポリシー・サービス、アイデンティティ・サービス、およびセッション・サービスを提供してアプリケーション・リソースに対する適切なセキュリティを確保し、ユーザーの認証と認可を行って、ユーザーセッションを管理することです。

この中核的なOAM製品アーキテクチャは、エージェントとOAMサーバー間の相互動作を支配する次のようなやり取りを中心に展開します。相互運用性と重要な決定点を明らかにするために、ユーザーがリソースに関するリクエストを行う際のOAMエージェントとOAMサーバー間の標準的な相互動作を図14-1に示します。

図14-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性

「図14-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性」の説明

次の概要では、OAMエージェントとOAMサーバー間で行われる処理を説明します。テストの際は管理者がエンド・ユーザーの役割を果たしながら、アクセス・テスターがエージェントをエミュレートしてOAMサーバーと通信を行います。

プロセス概要: OAMエージェントとOAMサーバーの相互運用性

1. サーバ接続の確立: 登録OAMエージェントがOAMサーバーに接続します。

2. ユーザーがリソースへのアクセスをリクエストします。

3. リソース保護の検証: エージェントがOAMサーバーにリクエストを送って、リソースが保護されているかどうかを判断します。
保護されている場合: OAMサーバーは必要な資格証明のタイプで応答します。

4. ユーザー資格証明: ユーザー・アイデンティティが確立されると、監査およびSSOのための追跡とアプリケーションへの伝達が可能になります。このため、エージェントはユーザーに対して資格証明を求めます。

5. ユーザー資格証明の認証: エージェントは、提供されたユーザー資格証明を検証のためOAMサーバーに送ります。
認証の成功: エージェントはリソース・リクエストをOAMサーバーに送ります。

6. リソースへのユーザー・アクセスを認可: エージェントはまず、認可ポリシーの検証のためにOAMサーバーへアクセス・リクエストを送ることによって、リソースへのユーザーのアクセスを認めるかどうかを判定しなければなりません。

7. エージェントは、ポリシー応答に基づいてアクセスを認可または拒否します。

アクセス・テスターのセキュリティと処理について

この項では、セキュアな通信、接続、保存、入力、ロギングおよび分析に関する情報を説明します。

セキュアな通信: アクセス・テスターは、OAMサーバーとの通信について、オープン接続モード、簡易接続モードまたは証明書接続モードに対応しています。

- オープン・モード: 物理的接続に対するセキュリティがありません。

- 簡易モード: 組込み証明書を使用して物理的接続を暗号化します。簡易モードでは、OAMサーバー用に構成されたグローバル・パス・フレーズの入力を求められます。

- 証明書モード: フィールド提供の証明書を使用して物理的接続を暗号化します。アクセス・テスターの証明書モードでは、次を実行する必要があります。

- 証明書モードの通信用にエージェント(既存または新規)を構成します。

- エミュレートするエージェントの証明書を取得します。

アクセス・テスターの証明書モードでは、提供されたPEM(BASE64-コード化ASCII)証明書(aaa_trust.pem、aaa_key.pem、aaa_cert.pem)からimportcertツールを使用して作成した2つのJKSキーストアが必要です。

- トラスト・ストア(ルートCA証明書を持つJKSキーストアが含まれるファイル)が必要です。

- キーストア(エージェントの秘密鍵および証明書を持つJKSキーストアが含まれるファイル)が必要です。

- エージェント証明書を持つキーストアの暗号化には、キーストア・パスワードを使用します。

関連項目:

- 付録E「Oracle Access Manager 11gとの安全な通信」: OAMサーバーおよびクライアント(Webgate)用の簡易モード構成および証明書モード構成の詳細

- 「アクセス・テスターのコンソールおよびナビゲーションの概要」

接続: アクセス・テスターは、テスターが構成ファイルとテスト・ケースに保存するすべてのパスワード型の値を暗号化します。プールに有効な接続が含まれているかどうかがアクセス・テスターで検証されます。OAPの(ログアウトをシミュレートする)ユーザー・セッションを削除するためのキャッシュ・フラッシュ・リクエストが(帯域外接続ではなく)確立された接続を介して送信されます。すでに確立された接続を使用することにより、パフォーマンスが向上します。

永続的な保存: アクセス・テスターは、アクセス・テスターを次回起動するまで永続的に保存しておく必要のある複数のデータ構造を管理します。次の種類の情報については、XMLファイルベースで保存が行われます。

- アプリケーション再起動時のデータ入力をできるだけ少なくするための構成データ(OamTestConfiguration)

- 取得されたテスト・ケースで構成されるテスト・スクリプト(OamTestScriptCase)

- テスト実行の実行メトリックを表わす統計データ(OamTestStats)

入力、ロギングおよび分析用のXMLファイル: アクセス・テスターでは、単一のXMLスキーマを使用して、生成したすべてのXMLドキュメントを定義します。テスト・スクリプトを処理するためにアクセス・テスターを実行すると、次のXMLファイルが生成されます。

- 構成スクリプト: config.xmlは、アクセス・テスター内でSave Configurationコマンドを使用して作成される出力ファイルです。このドキュメントの名前は、コマンド・ライン・モードで実行中のアクセス・テスターに正しい接続情報を提供するために入力スクリプト内で使用されます。詳細は「保存された接続構成ファイルについて」を参照してください。

- 入力スクリプト: script.xmlは、1つまたは複数のテスト・ケースを取得後にアクセス・テスターによって作成されるスクリプトです。詳細は「作成された入力テスト・スクリプトについて」を参照してください。

- ターゲット出力スクリプト: アクセス・テスターをコマンド・ライン・モードで実行して入力スクリプトを指定すると、oamtest_target.xmlが作成されます。詳細は「テスト実行結果が格納されたターゲット出力ファイルについて」を参照してください。例: -Dscript.scriptfile="script.xml" -jar oamtest.jar

- 統計: oamtest_stats.xmlは出力スクリプトとともに作成されます。詳細は「統計ドキュメントについて」を参照してください。

- 実行ログ: lamtest_log.logは出力スクリプトとともに作成されます。詳細は「実行ログについて」を参照してください。

その他の詳細は「アクセス・テスター・モードと管理者の対話操作について」を参照してください。

アクセス・テスター・モードと管理者の対話操作について

この項では、モード、対話操作およびアクセス・テスターの起動と実行に必要なjarファイルについて説明します。

コンソール: アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行うことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。

コマンドラインおよびスクリプト: アクセス・テスターでコマンドラインを使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成できます。

起動および実行時JARファイル: アクセス・テスターでは、アプリケーションの起動に使用するメインjarのoamtest.jarと同じディレクトリにnap-api.jarを置く必要があります。

対話操作: アクセス・テスター実行のために選択したモードにかかわらず、ユーザーとアクセス・テスターの主な対話操作には次の操作が含まれます。

- リクエストの発行と結果の表示
リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。

- テスト・スクリプトの管理
テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後になんらかの自動分析を行うことができます

- OAMサーバー接続の管理
サーバー接続情報を含むアプリケーション設定を管理できます。

コンソール・モード操作とコマンドライン・モード操作の両方おける情報の流れを図14-2に示します。詳細は、図の後に説明します。より高度な操作としては、テスト・スクリプトの作成と実行があります。

注意:
コマンドライン・モードを使用すると、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。アクセス・テスターは、読取り専用モードで使用可能な「確認済(Known Good)」の入力テスト・スクリプトを変更せずにテスト実行を構成する制御メカニズムを公開しています。

図14-2 アクセス・テスターのユーザー操作

「図14-2 アクセス・テスターのユーザー操作」の説明

テスター・コンソール・モード操作とコマンドライン・モード操作の両方における情報の処理フローを表14-1に示します。

表14-1 テスター・コンソール・モードとコマンドライン・モードを使用したユーザー操作

テスター・コンソール・モード

コマンドライン・モード

ユーザーはコマンド・ラインからアクセス・テスターを開始します。

コマンドライン・モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。

セキュアな通信用の証明書モード: キーストアは、以前に保存された構成情報が格納されているOamTestConfiguration.xmlファイルで指定されます。

ユーザーが前に保存されたOamTestConfiguration.xmlファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、テスター・コンソールを使用して手動でデータを入力することもできます。

アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。

ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。

入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。

リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。

リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。

アクセス・テスターはテスト完了時に次のものを作成します。

- 結果のスクリプト

- 一致しない応答に関する情報を含む実行統計のファイル

- 処理フローの詳細を示すログ・ファイル

アクセス・テスターはスクリプト完了時に次のものを作成します。

- 結果のスクリプト

- 一致しないレスポンスに関する情報を含む実行統計のファイル

- 処理フローの詳細を示すログ・ファイル

必要に応じてユーザーがステップを繰り返して検証を終了させます。

必要に応じてユーザーがステップを繰り返して検証を終了させます。

証明書モードでは、必要なキーストアを特定するように要求されます。

証明書モードでは、キーストアは、以前に保存された構成情報が格納されているXMLファイルで指定されます。

次ではアクセス・テスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。

タスクの概要: OAM 11gの接続とポリシーのテストには次のタスクが含まれます。

1. 次のトピックを確認してください。

- アクセス・テスターのインストールと起動

- アクセス・テスター・コンソールとナビゲーションの概要

2. 「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行してデータを取り込みます。

3. 「テスト・ケースおよびスクリプトの作成と管理」へ進みます。

アクセス・テスターのインストールと起動

アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できる2つのjarファイルで構成されます。この項では、テストを実行するコンピュータにアクセス・テスターのjarファイルをコピーするなど、アクセス・テスターのインストール方法を説明します。テスト入力用に選択したモードがテスター・コンソール・モードかコマンドライン・モードかにかかわらず、アクセス・テスターはコマンドラインから開始する必要があります。この項の内容は次のとおりです。

- アクセス・テスターのインストール

- アクセス・テスターでサポートされているシステム・プロパティについて

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

アクセス・テスターのインストール

このトピックでは、どのコンピュータでも使えるようにアクセス・テスターをインストールする方法を説明します。インストール終後は、いつでもアクセス・テスターを使用できます。特別なセットアップは必要ありません。

アクセス・テスターのインストール方法

1. テスターを実行するコンピュータにJDK/JRE 6が含まれていることを確認します。たとえば、次のようにJavaをテストできます。

java -version

前述のコマンドは次に示す情報を返します。

java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)

2. OAMサーバーをホストしているコンピュータ上で、アクセス・テスターのJarファイルを探してコピーします。次に例を示します。

Oracle_HOME/oam/server/tester/oamtest.jar
Oracle_HOME/oam/server/tester/nap-api.jar

3. アクセス・テスタを実行しようとするコンピュータ上の同じディレクトリ内に、jarファイルのコピーを保存します。

4. 証明書モード: OAMサーバーの通信モードが「証明書」の場合、アクセス・テスターを実行するコンピュータに、Oracle Access Managerコンソールのエージェント登録ページで定義されているものと同じキーストアが含まれていることを確認してください。第9章を参照してください。

5. 使用する環境と要件に応じて、次の作業を実行します。

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始するの手順に従えば、手動でリクエストを実行できます。

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

- テスト・スクリプトの実行の手順に従えば、「確認済(Known Good)」のポリシー構成に従って作成され、「確認済」としてマークされたテスト・スクリプトを使用できます。

アクセス・テスターでサポートされているシステム・プロパティについて

アクセス・テスターでは、プレゼンテーションやテストの特定側面に使用できるいくつかの構成オプションを選択できます。これらのオプションは、サポートされているすべてのシステム・プロパティを示した表14-2に示すように、起動時にJavaの-Dメカニズムを使用して指定します。

表14-2 アクセス・テスターでサポートされているシステム・プロパティ

プロパティ

アクセス・テスター・モード

説明とコマンド構文

log.traceconnfile

テスター・コンソール・モードおよびコマンドライン・モード

指定ファイル名への接続詳細を記録します。

-Dlog.traceconnfile="<file-name>"

display.fontname

テスター・コンソール・モード

指定フォントでアクセス・テスターを開始します。これは、表示解像度の違の補正に有効です。

- Ddisplay.fontname ="<font-name>"

display.fontsize

テスター・コンソール・モード

指定フォント・サイズでアクセス・テスターを開始します。これは、表示解像度の違いの補正に有効です。

- Ddisplay.fontsize ="<font-size>"

display.usesystem

テスター・コンソール・モード

デフォルトのフォント名とフォント・サイズ(ダイアログ・フォント、サイズ10)でアクセス・テスターを開始します。

- Ddisplay.usesystem

script.scriptfile

コマンドライン・モード

コマンドライン・モードでスクリプト<file-name>を実行します。

-Dscript.scriptfile="<file-name>"

control.configfile

コマンドライン・モード

接続情報を含む構成XMLファイルへの絶対パスが格納されている、スクリプトの「configfile」属性を上書きします。アクセス・テスターはこの構成ファイルを使用して、「接続」要素によって示されたポリシー・サーバーへの接続を確立します。

-Dcontrol.config="<file-name>"

control.testname

コマンドライン・モード

出力スクリプト・ファイル、統計ファイルおよびログ・ファイルの命名に使用するテスト・シリーズの名前を表す文字列が格納されている、スクリプトの制御要素の「testname」属性を上書きします。出力ログ・ファイルは<testname>_<testnumber>で始まります。

-Dcontrol.testname="<String>"

control.testnumber

コマンドライン・モード

出力スクリプト・ファイル、統計ファイル、およびログ・ファイルの命名に使用する制御番号を指定します。出力ログ・ファイルは<testname>_<testnumber>で始まります。

-Dcontrol.testnumber="<String>".

自動生成される文字列は現在のローカル時刻に基づく7桁の数値ですが(分数を示す2文字+秒数を示す2文字＋1/100秒を示す3文字)、ファイル名に使用できるものであれば任意の文字列を使用して制御番号を表わすことができます。

control.ignorecontent

コマンドライン・モード

スクリプトの「制御」要素の「ignorecontet」属性を上書きします。この要素は、アクセス・テスターがオリジナルのテスト・ケースと現在の結果における「コンテンツ」の違いを無視する必要があることを示します。

-Dcontrol.testname="true|false"

control.displayiterationstats

コマンドライン・モード

テスト実行を反復するたびに中間統計を表示するかどうかを制御します。

-Dcontrol.displayiterationstats="true|false"

control.loopback

コマンドライン・モード

確認済のスクリプトを基準にアクセス・テスターの内部的な性能低下をテストするために、アクセス・テスターをループバック・モードで実行します。アクセス・テスターのユニット・テストに使用します。

-Dcontrol.loopback="true"

テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

グラフィカル・ユーザー・インタフェースを通じて手動でリクエストを行って(結果を取り込み)リアルタイム応答を表示するには、テスター・コンソール・モードでテスターを開始します。テスター・コンソール・モードでもいくつかのシステム・プロパティを使用できますが、この手順ではすべて省略します。

jarファイルはデフォルトの開始クラスを定義します(クラス名を指定する必要はありません)。oamtest.jarと同じディレクトリ内にnap-api.jarが存在することを確認してください。

関連項目:

- アクセス・テスターでサポートされているシステム・プロパティについて

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

システム・プロパティを使用せずにコンソール・モードでシステム・テスターを開始する方法

1. アクセス・テスターのjarファイルが置かれたディレクトリで、次のコマンドを入力します。

java -jar oamtest.jar

2. oamtestコマンドライン・ツールで使用可能なすべてのオプションを一覧表示するには、-helpオプションを使用します。

java -jar oamtest.jar -help

3. 詳細は次のいずれかのトピックを参照してください。

- アクセス・テスター・コンソールとナビゲーションの概要

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

この項は次のトピックに分割されています。

- アクセス・テスターのコマンドライン・モードについて

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

アクセス・テスターのコマンドライン・モードについて

テスト・スクリプトを実行したりアクセス・テスターの動作をカスタマイズしたりするには、コマンドライン・モードでテスターを開始し、Javaの-Dオプションを使用してシステム・プロパティを含めなければなりません。

関連項目:
アクセス・テスターでサポートされているシステム・プロパティについて

コマンドライン・モードでアクセス・テスターを実行すると、アクセス・テスターは、テスト実行管理のためのシェル・スクリプトで使用できる完了コードを返します。コンソール・モードでアクセス・テスターを実行するときは、アクセス・テスターによって返されるコードに従う必要はありません。

特定のテスト・ケースを実行するためにアクセス・テスターをラップするシェル・スクリプトは、アクセス・テスターによって伝達される終了コードを認識し、これに従って動作できる必要があります。コマンドライン・モードでは、アクセス・テスターはSystem.Exit (N)を使用して終了します(Nは次のいずれかのコードになります)。

- 0は、不一致なしですべてのテスト・ケースが正常に終了したことを示します。これには、入力スクリプト内にテスト・ケースが定義されていない状況も含まれます。

- 3は、少なくとも1つの不一致ですべてのテスト・ケースが正常に終了したことを示します。

- 1は、エラーによってアクセス・テスターを実行できなかったこと、またはテスト・ケースを完了できなかったことを示します。これには、入力スクリプトが指定されていない、入力スクリプトを読み込めない、サーバー接続を確立できない、ターゲット・スクリプトを作成できないという状態が含まれます。

これらの終了コードは、アクセス・テスターを使用して特定のテスト・ケースを実行するために作成されたシェル・スクリプト(Bourneシェルの$?)によって取得できます。

システム・プロパティを指定してアクセス・テスターを開始

次の手順を使用してコマンドライン・モードでアクセス・テスターを開始し、Javaの-Dメカニズムを使用して任意の数の構成オプションを指定します。

関連項目:
アクセス・テスターでサポートされているシステム・プロパティについて

システム・プロパティを指定してアクセス・テスターを開始する方法、またはコマンドライン・モードで開始する方法

1. アクセス・テスターのjarファイルが置かれたディレクトリで、使用環境に合った適切なシステム・プロパティを指定してコマンドを入力します。次に例を示します。

java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true"
-jar oamtest.jar

2. 開始後は、次のいずれかのトピックを参照してください。

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

アクセス・テスター・コンソールとナビゲーションの概要

この項では、アクセス・テスター・コンソール、ナビゲーション、およびコントロールの概要を示します。

固定サイズのアクセス・テスター・コンソールを図14-3に示します。コンソール・モードでアクセス・テスターを開始した場合、ユーザーはこのウィンドウを通じてアプリケーションとの対話操作を行うことができます。このウィンドウのサイズを変更することはできません。詳細は図の後の説明を参照してください。

図14-3 アクセス・テスター・コンソール

「図14-3 アクセス・テスター・コンソール」の説明

メイン・ウィンドウの最上部にあるメニュー・バーにはメニュー名が表示されています。メニュー・バーの下にはツール・バーがあります。ツール・バー内にボタンで表示されているすべてのコマンドは、メニュー・コマンドとして選択することもできます。アクセス・テスター・コンソールは、表14-3に示すように4つのパネルに分割されています。

表14-3 アクセス・テスターのコンソール・パネル

パネル名

説明

サーバー接続

OAMサーバー(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)との接続を確立するために必要な情報を入力するためのフィールドと、「接続」ボタンがあります。

「アクセス・テスターとOAMサーバー間の接続の確立」も参照してください。

保護リソースのURI

保護状態を検証する必要のあるリソースに関する情報が表示されます。リソース検証サーバー・リクエストを送信するには、「検証」ボタンを使用します。

「アクセス・テスター・コンソールからリソース保護を検証」も参照してください。

ユーザー・アイデンティティ

資格証明を認証する必要のあるユーザーに関する情報が表示されます。「ユーザーの認証」サーバー・リクエストの送信には「認証」ボタンを使用します。

「アクセス・テスター・コンソールからユーザー認証をテスト」も参照してください。

ステータス・メッセージ

ユーザーのリクエストに対してアプリケーションが表示するメッセージで構成された、スクロール可能なステータス・メッセージ・エリアが表示されます。ユーザーの認可サーバー・リクエストの送信には認可ボタンを使用します。

「リクエスト待機時間の監視」も参照してください。

テキスト・フィールドでは、右クリックによる「編集」メニューの表示、およびマウスとカーソルによるドラッグアンドドロップ操作が可能です。

OAMサーバーにテスト・リクエストを送信するために使用する4つのプライマリ・ボタンがあります。それぞれのボタンは、表14-4に示す指定アクションを開始するためのトリガーとして働きます。

表14-4 アクセス・テスター・パネルのコマンド・ボタン

パネル・ボタン

説明

接続

接続情報を送信して接続を開始します。

検証

保護リソースのURIパネルに入力された情報を送信して、保護の検証を開始します。

認証

「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認証の確認を開始します。

認可

「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認可の確認を開始します。

関連項目:
アクセス・テスターのメニューとコマンド・ボタン

アクセス・テスターのメニューとコマンド・ボタン

アクセス・テスターのその他のボタンとその使用方法を表14-5に示します。ボタンの上にカーソルを合わせると、そのボタンに関するヒントが表示されます。

表14-5 その他のアクセス・テスター・ボタン

コマンド・ボタン

説明

XMLファイル(デフォルトはconfig.xml)に保存された接続構成の詳細をロードします。

このボタンをクリックすると、コンソール内の情報をリフレッシュできます。

接続構成の詳細をファイル(デフォルト名はconfig.xml)に保存します。このドキュメントの名前は、コマンド・ライン・モードで実行中のアクセス・テスターに正しい接続情報を提供するために、入力スクリプトに追加できます。

コンソールの最も下にある「保存」コマンド・ボタンは、「ステータス・メッセージ」パネルの内容をログ・ファイルに保存します。

アイコンを含むパネル上のフィールドをクリアします。ツール・バーのボタンを使用すると、接続がすでに確立されている場合は接続フィールドを除くすべてのフィールドがクリアされます。

最後に指定されたリクエストを取得し、これに対してOAMサーバーから受信したレスポンスとともに取得キューに入れます。リクエストとレスポンスを組み合わせてテスト・ケースが作成されます。

コンソールの最も下にある取得キューのステータスが更新されて、キュー内のテスト・ケースの数が反映されます。

取得キューの内容は保存でき、「テスト」メニューのスクリプト作成コマンドまたはコマンド・ボタンを使用して、複数のテスト・ケースを含むテスト・スクリプトを作成できます。

現在取得キューに置かれているあらゆるテスト・ケースを含むテスト・スクリプトを作成して、キューをクリアするかどうかの確認を行います。キューは、すべてのテスト・ケースが取得されてテスト・スクリプトに保存されるまでクリアしないでください。

現在のOAMサーバーに対してテスト・スクリプトを実行します。「ステータス」メッセージ・ウィンドウには、スクリプトが各テスト・ケースへ進むのに合わせて実行ステータスが表示されます。

コピーされたURIを解析後にクリップボードからインポートし、URIパネルのフィールドに表示します。

パスワードをクリア・テキストで表示するダイアログを表示します。

アクセス・テスターには表14-6に示すメニューがあります。すべてのメニュー項目にはニーモニックがあり、これはALTキーを押すことによって開くことができます(Wondowsシステム上)。また、各メニュー・コマンドに対して定義されたCTRLキーと<文字キー>の組み合わせを使用して、コマンド・アクセラレータ(キーボード・ショートカット)を利用することもできます。

表14-6 アクセス・テスターのメニュー

メニュー名

メニュー・コマンド

ファイル

- 構成を開く

- 構成の保存

- 終了

注意: データ入力量をできるだけ少なくするために、「構成の保存」メニューと構成を開くメニュー(およびツール・バーのコマンド・ボタン)を使用して、特定の接続、URI、およびアイデンティティ情報をファイルに保存したりファイルから読み取ることができます。したがって、複数構成の管理が極めて容易になります。また、コマンドライン・モードでアクセス・テスターを使用してテスト・スクリプトを実行するときは、構成ファイルをアクセス・テスターへの入力として使用できます。

編集

フィールドに対して使用できる標準編集コマンドを提供します。

- 切取り

- コピー

- 貼付け

- すべてのフィールドをクリア

- 保存したURLからURIフィールドをインポート

テスト

- 最後の"..."リクエストを取得(たとえば最後の"認可"リクエストを取得)

- テスト・スクリプトを保存

- テスト・スクリプトを実行

注意: これらの機能を使用し、最後のリクエストと応答を取得してテスト・ケースを作成できます。これらのテスト・ケースは、テスト・スクリプトに保存して後で実行できます。

ヘルプ

使用状況情報を表示するAboutコマンドです。

アクセス・テスター・コンソールによる接続性とポリシーのテスト

この項では、アクセス・テスターをOAMサーバーとともにコンソール・モードで使用して、クイック・スポット・チェックを行う方法を説明します。

エージェントとOAMサーバー間の接続のスポット・チェックやトラブルシューティングを行うと、エージェントがOAMサーバーと通信できるかどうかの評価に役立ちますが、これは、アップグレードや製品移行を行った後は特に有効です。また、エージェントやOAMサーバーによるリソース保護のスポット・チェックやトラブルシューティングを行うと、アプリケーション・ライフサイクルの間にポリシー構成のエンドツーエンド・テストを作成する際に役立ちます。

次に、実行するタスクおよびシーケンスの概要と、各タスクの詳細について参照する必要がある箇所を示します。

注意:
ユーザーは、それぞれのリクエストとレスポンスのペアを取得してテスト・ケースを作成し、そのテスト・ケースをスクリプト・ファイルに保存して後で実行できます。詳細は「テスト・ケースおよびスクリプトの作成と管理」を参照してください。

タスクの概要: アクセス・テスター・コンソールからスポット・チェックを行う。

1. 「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。

2. 「アクセス・テスターとOAMサーバー間の接続の確立」の説明に従って、「サーバー接続」パネルに関連詳細事項を入力します。

3. 「アクセス・テスター・コンソールからリソース保護を検証」の説明に従って、保護リソースのURIペインに詳細を入力またはインポートします。

4. 「アクセス・テスター・コンソールからユーザー認証をテスト」の説明に従って、「ユーザー・アイデンティティ」パネルに関連詳細事項を入力します。

5. 認証が正常に終了したら、「アクセス・テスター・コンソールからユーザー認可をテスト」の説明に従って「ユーザー・アイデンティティ」パネルの認可をクリックします。

6. 「リクエスト待機時間の監視」の説明に従って、リクエストの待機時間をチェックします。

アクセス・テスターとOAMサーバー間の接続の確立

OAMサーバーにリクエストを送信するには、アクセス・テスターとサーバ間の通信を確立しなければなりません。この項では、その接続を確立する方法を説明します。

- 「接続」パネルについて

- アクセス・テスターとOAMサーバーの接続

「接続」パネルについて

エミュレートしようとしているOAMサーバーとエージェントに関する必要情報をアクセス・テスターの「接続」パネルに入力して、「接続」ボタンをクリックします。テスターが接続を開始して、「ステータス・メッセージ」パネルにステータスを表示します。接続が確立されると、その接続がその後のすべての操作に使用されます。

注意:
接続が確立されると、アクセス・テスター・コンソールを再起動するまでその接続を変更することはできません。

「サーバー接続」パネルとコントロールを図14-4に示します。このパネルには、OAMサーバーのプロキシ・ポートへの接続の確立に必要な情報が含まれています。

図14-4 アクセス・テスターの「サーバー接続」パネル

「図14-4 アクセス・テスターのサーバー接続パネル」の説明

接続の確立に必要な情報を表14-7に示します。この値は、Oracle Access Managerコンソールの「システム構成」タブから取得されます。

表14-7 接続パネルの情報

フィールド

説明

IPアドレス

このテスト・セットにおけるプライマリおよびセカンダリOAMプロキシのIPアドレスをリスニングします。

注意: 入力するのはプライムOAMプロキシの値のみにすることをお薦めします。セカンダリOAMプロキシが必要なのは、プライマリOAMサーバーとセカンダリOAMサーバー間のフェイルオーバーをテストする場合に限られます。ただし、OAP APIがプライマリOAMサーバーとセカンダリOAMサーバー間のロード・バランシングをサポートしている場合は、セカンダリ・サーバーをより実用的に利用できます。

ポート

プライマリおよびセカンダリOAMサーバーのポート番号を入力します。

最大接続数

アクセス・テスターが使用する物理的接続(TCP)ソケットの最大数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。

注意: デフォルト値の1を使用することをお薦めします。

最小接続数

アクセス・テスターが使用する物理的接続(TCP)ソケットの最小数です。アクセス・テスターはシングル・スレッド・エージェントをエミュレートします。

注意: デフォルト値の1を使用することをお薦めします。

タイムアウト

接続の確立、あるいはOAMサーバーからのレスポンス受信のためにアクセス・テスターが待機する時間(ミリ秒)です。

注意: デフォルト値の使用をお薦めします。

モード

エミュレートするエージェントに指定された通信セキュリティのレベル。

- オープン: このモードでは特別な構成は必要ありません。

- 簡易: OAMサーバー用に設定されたグローバル・パス・フレーズのフィールドを表示します。関連項目: 「簡易モード用のグローバル・パスフレーズの取得」

- 証明書: 次を要求するダイアログを開く証明書の構成...ボタンを表示します。
トラスト・ストア(ルート・ストア別名): ルートCA証明書を持つJKSキーストアが含まれるファイル。

キー・ストア: エージェントの秘密鍵および証明書を持つJKSキーストアが含まれるファイル。現在、接続の暗号化にはエージェント証明書が使用され、エージェントIDは使用されていません。

キー・ストア・パスワード: エージェント証明書を持つキーストアの暗号化に使用するパスワード。

関連項目: 「アクセス・テスターのセキュリティと処理について」および「証明書モードのOAMテスターのクライアント・キーストア生成」

エージェントID

テスターがシミュレートするOAMエージェントのアイデンティティを入力します。

エージェント・パスワード

テスターがシミュレートするOAMエージェントのパスワードが設定されている場合は、そのパスワードを入力します。

エージェント・パスワードの横にある「?」をクリックしてヘルプを表示します。

「接続」ボタンの横の緑色のチェック・マークは、「はい」のレスポンスを示し、この場合は接続が確立されています。ステータス・メッセージパネルにも接続に関する「はい」のレスポンスが表示されます。

「接続」ボタンの横の赤の円は、「いいえ」のレスポンスを示し、この場合、接続は存在しません。ステータス・メッセージパネルにも接続に関する「いいえ」のレスポンスが表示されます。

情報を入力して接続を確立した後は、詳細を構成ファイルに保存して後で再利用できます。

関連項目:
アクセス・テスターとOAMサーバー間の接続の確立

アクセス・テスターとOAMサーバーの接続

次の手順を使用してOAMサーバーの接続の詳細を送信します。

注意:
証明書モードでは、付録E「Oracle Access Manager 11gとの安全な通信」に示すように生成されたキーストアの存在が必要です。

前提条件

アクセス・テスターのインストールと起動

関連項目:
「接続」パネルについて

アクセス・テスターとOAMサーバー間の接続のテスト方法

1. 「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。

2. 「サーバー接続」パネル(表14-7)で、次の情報を入力します。

- プライマリおよびセカンダリOAMプロキシの詳細

- タイムアウト時間

- 通信暗号化モード

- エージェントの詳細

3. 「接続」ボタンをクリックします。

4. 「接続」ボタンの横に、接続の確立を示す緑色のチェック・マークが表示されていることを確認します。

5. 「ステータス・メッセージ」パネルに「はい」のレスポンスが表示されていることを確認します。
成功しない場合: OAMサーバーへの接続に問題がある場合は、すべての接続情報(必要に応じて、IPアドレスとポート、エージェント名とパスワード、接続モードおよび関連する証明書とパスワード)を正しく入力したことを確認してください。

まだ接続を確立できない場合は、トレース接続コマンド・モードを使用してアクセス・テスター・コンソールを起動し、接続ログ内の詳細を確認します。また、OAMサーバーの管理者にポリシー・サーバー・ログの確認を依頼します。

アクセス・テスター・コンソールからリソース保護を検証

ユーザーがリソースにアクセスできるようにするには、まず、リソースが保護されていることをエージェントが確認する必要があります。次の説明に従い、ユーザーがアクセス・テスターを使用してエージェントの役を演じ、指定されたURIが保護されているかどうかをOAMサーバーに検証させて応答をアクセス・テスターに伝達させます。

- 保護リソースのURIパネルについて

- リソース保護の検証

保護リソースのURIパネルについて

検証しようとするリソースに関する必要情報をアクセス・テスターの保護リソースのURIパネルに入力し、「検証」ボタンをクリックします。

データ入力量をできるだけ小さくするために、長いURIをブラウザからコピーして、URIのインポートコマンド・ボタンをクリックしてインポートできます。テスターがクリップボードに保存されたURIを解析して、アクセス・テスターのURIフィールドに入力します。

リソースが保護されていることを検証するためにURI詳細を入力するパネルを図14-5に示します。これらのURIフィールドを組み合わせるとRFC表記に従った書式になります。例: http://oam_server1:7777/index.html

図14-5 アクセス・テスターの保護リソースのURIパネル

「図14-5 アクセス・テスターの保護リソースのURIパネル」の説明

この評価を行うために必要な情報を表14-8に示します。

表14-8 保護リソースURIパネルのフィールドとコントロール

フィールドまたはコントロール

説明

スキーム

リソースに指定された通信セキュリティに応じてhttpまたはhttpsを入力します。

注意: アクセス・テスターはhttpまたはhttpsリソースのみをサポートします。アクセス・テスターを使用して、http以外のカスタム・リソースを保護するポリシーをテストすることはできません。

ホスト

リソースの有効なホスト名を入力します。

注意: アクセス・テスター内に指定された<host:port>の組合せは、Oracle Access Managerコンソールにおけるホスト識別子の組合せと一致している必要があります。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。

ポート

URIに対する有効ポートを入力します。

注意: アクセス・テスター内に指定された<host:port>の組み合わせは、OAM管理サーバー内に定義されたホスト識別子の組み合わせと一致していなければなりません。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。

リソース

URIのリソース部分を入力します(たとえば/index.htm)。このリソースは、Oracle Access Managerコンソールで認証および認可ポリシーに対して定義されたリソースと一致している必要があります。

注意: 保護されている場合、ここに入力したリソース識別子は、Oracle Access Managerコンソールで認可ポリシーに指定された識別子と一致している必要があります。

クリップボードに保存されたURIを解析してインポートするには、このボタンをクリックします。

操作

アクセス・テスターに示されたリストから、URIの操作部分を選択します。ただし、OAMサーバーはアクションの違いを認識しません。したがって、ここは「取得 」のままにしておいても問題ありません。

認証スキームを取得

保護リソースのセキュリティ保証に使用する認証スキームについて、その詳細を返すようOAMサーバーに要求するには、このチェック・ボックスを選択します。URIが保護されている場合、この情報は「ステータス・メッセージ」パネルに表示されます。

検証

「検証」ボタンをクリックしてOAMサーバーにリクエストを送信します。レスポンスを受信すると、アクセス・テスターはそのレスポンスを「ステータス・メッセージ」パネルに表示します。

「検証」ボタンの横に表示される緑色のチェック・マークは、「はい」のレスポンスを示し、この場合、リソースは保護されています。ステータス・メッセージパネルにはリソースのリダイレクトURLが表示される他、資格証明が必要とされることも表示されます。

注意: 認証スキームを取得ボックスを選択した場合は、「ステータス・メッセージ」パネルにもこのリソースを保護する認証スキームの名前とレベルが表示されます。

「検証」ボタンの横に表示される赤の円は、リソースが保護されていないことを示します。「ステータス・メッセージ」パネルにも「いいえ」のレスポンスが表示されます。

ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。

関連項目:

- アクセス・テスター・コンソールからリソース保護を検証

- テスト・ケースおよびスクリプトの作成と管理

リソース保護の検証

次の手順を使用してリソース情報をOAMサーバーに送信し、「ステータス・メッセージ」パネルでレスポンスを検証します。

前提条件

アクセス・テスターとOAMサーバー間の接続の確立

関連項目:
保護リソースのURIパネルについて

リソースが保護されていることを確認する方法

1. アクセス・テスターの保護リソースのURIパネルで、自身のリソース情報を入力またはインポートします(表14-8)。

2. 「検証」ボタンをクリックしてリクエストを送信します。

3. リソースの保護方法や保護レベルといったリソース関連のデータを含め、アクセス・テスターの出力を確認します。

4. 「検証」ボタンの横に、リソースが保護されていることを示す緑色のチェック・マークが表示されていることを確認します。

5. 「ステータス・メッセージ」パネルで、リダイレクトURL、認証スキーム、および資格証明が必要とされることを確認します。

6. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。

7. 次のいずれかの方法を使用し、データ入力とサーバーの処理をできるだけ少なくするためにURIを保存しておきます。

8. 「アクセス・テスター・コンソールからユーザー認証をテスト」に進んでください。

アクセス・テスター・コンソールからユーザー認証をテスト

この項の内容は次のとおりです。

- 「ユーザー・アイデンティティ」パネルについて

- ユーザー資格証明による認証のテスト

「ユーザー・アイデンティティ」パネルについて

ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められた認証ポリシーに基づいてユーザーのアイデンティティを検証する必要があります。アクセス・テスターを使用すれば、ユーザーがエージェントの役を演じて、保護リソースに対する特定のユーザーIDをOAMサーバーに認証させることができます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。

テスト評価に必要な情報を入力するアクセス・テスター・パネルを図14-6に示します。

図14-6 アクセス・テスターの「ユーザー・アイデンティティ」パネル

「図14-6 アクセス・テスターのユーザー・アイデンティティパネル」の説明

入力が必要な情報を表14-9に示します。

表14-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール

フィールドまたはコントロール

説明

IPアドレス

ユーザー資格証明の検証を行うユーザーのIPアドレスを入力します。OAMサーバーと通信するすべてのエージェントがエンド・ユーザーのIPアドレスを送信します。

デフォルト: 入力されるIPアドレスは、アクセス・テスターを実行するコンピュータに属するものです。

実際のユーザーのIPアドレスを必要とするポリシーをテストするには、デフォルトのIPアドレスを実際のIPアドレスに置き換えてください。

ユーザー名

資格証明の検証対象となる個人のユーザーIDを入力します。

注意: 資格証明を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはそのユーザー名フィールドとパスワード・フィールドを有効または無効にします。同様に、ユーザーのX509証明書を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはその証明書フィールドを有効または無効にします。

パスワード

資格証明の検証対象となる個人のパスワードを入力します。

?

ポップアップ・ウィンドウ内にクリア・テキストでパスワードを表示するには、このボタンをクリックします。

ユーザー資格証明ストア

資格証明を認証する必要のあるユーザーのX.509証明書を格納するPEMフォーマットのファイルです。

X509認証スキームによってURIが保護されている場合、テスターは、ユーザー名/パスワードではなく、またはユーザー名/パスワードに加えて、PEMフォーマットのX509証明書を資格証明として使用します。OAMサーバーでのセキュリティ・ポリシーの構成によっては、X509証明書が認証に使用される場合もあります。

注意: 証明書ベースの認証を機能させるには、CA証明書とSSLキーストア証明書を使用してOAMサーバーを正しく構成する必要があります。OAM 11gサーバーとWebgate間の通信のセキュリティ確保の詳細は、付録Eを参照してください。

...

ユーザー証明書ストア・パスのファイル・システムを表示するには、このボタンをクリックします。

認証

OAMサーバーにリクエストを送信して「ステータス・メッセージ」パネルでレスポンスを探すには、「認証」ボタンをクリックします。

注意: 提供される資格証明のタイプ(ユーザー名/パスワードまたはX.509証明書)は、URIを保護している認証スキームの要件と一致していなければなりません。

注意: 証明書ベースの認証では、付録Eに示すように、証明書を使用してOAMサーバー・デプロイメントを正しく構成する必要があります。

認可

ユーザーの資格証明の検証後に認可ボタンをクリックすれば、リソースに対するリクエストをOAMサーバーに送信できます。レスポンスについては「ステータス・メッセージ」パネルを確認してください。

このリクエストは、アイデンティティ・パネルで定義されたユーザーが、「URI」パネルで定義されたリソースにアクセスできるかどうかを決定するために、「URI」およびアイデンティティ・パネルで収集した情報をOAMサーバーに送信します。サーバーは「はい」(ユーザーはリソースにアクセスできます)または「いいえ」(ユーザーはリソースにアクセスできません)を返します。OAMサーバーからは、実際のエージェントならば正常に処理するアクション(レスポンス)などの追加情報が返される場合があります。

「認証」ボタンの横に表示される緑色のチェック・マークは認証が成功したことを示します。「ステータス・メッセージ」パネルにも認証が成功したことを示す「はい」のレスポンスが表示される他、ユーザーDNとセッションIDも示されます。

認可ボタンの横に表示される緑色のチェック・マークは認可が成功したことを示します。「ステータス・メッセージ」パネルにも認可が成功したことを示す「はい」のレスポンスが表示され、アプリケーション・ドメインの詳細も示されます。

「認証」ボタンの横に表示される赤の円は認証が失敗したことを示します。「ステータス・メッセージ」パネルにも認証に失敗したことを示す「いいえ」のレスポンスが表示されます。

認可ボタンの横に表示される赤の円は認可が失敗したことを示します。「ステータス・メッセージ」パネルにも認可にしっぱししたことを示す「いいえ」のレスポンスが表示されます。

ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。

関連項目:

- アクセス・テスター・コンソールからユーザー認証をテスト

- テスト・ケースおよびスクリプトの作成と管理

ユーザー資格証明による認証のテスト

次の手順を使用してエンド・ユーザーの資格証明をOAMサーバーに送信し、認証を検証します。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。

前提条件

コンソールに保持されたURI情報でアクセス・テスター・コンソールからリソース保護を検証します。

関連項目:
「ユーザー・アイデンティティ」パネルについて

ユーザー資格証明による認証のテスト方法

1. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認証対象のユーザーに関する情報を入力します(表14-9)。

2. 「認証」ボタンをクリックしてリクエストを送信します。

3. 「認証」ボタンの横に、ユーザーが認証されたことを示す緑色のチェック・マークが表示されていることを確認します。
認証できない場合: 正しいユーザーIDとパスワードを入力したことを確認し、再度認証を試みてください。また、第7章の説明に従い、終了させる必要のあるアクティブ・ユーザー・セッションの有無をOracle Access Managerコンソールで確認してください。

4. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。

5. URIとユーザー・アイデンティティ情報を保持して、「アクセス・テスター・コンソールからユーザー認可をテスト」へ進んでください。

アクセス・テスター・コンソールからユーザー認可をテスト

ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められたポリシーに基づいてユーザーの権限を検証する必要があります。アクセス・テスターを使用してユーザーがエージェントとしての役割を演じ、認証されたユーザー・アイデンティティにリソースへのアクセスを認可できるかどうかをOAMサーバーに検証させることができます。

次の手順を使用して、認証済エンド・ユーザーのリソースへのアクセス認可を検証します。このポリシー評価の際には、関係するすべての認可上の制約とレスポンスが考慮されます。

前提条件

コンソールに保持されたすべての情報でアクセス・テスター・コンソールからユーザー認証をテストします。

関連項目:
「ユーザー・アイデンティティ」パネルについて

注意:
アクセス・テスターから保護リソースのURIが確認されてユーザーのアイデンティティが認証されれば、それ以外の情報は必要ありません。認可ボタンをクリックしてリクエストを送信してください。ただし、リソースが別のものに変更された場合は改めてシーケンスを開始して検証を行い、次いで認証と認可を行う必要があります。

ユーザー認可のテスト方法

1. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、ユーザーが認証されていることを確認します(表14-9)。

2. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認可ボタンをクリックします。

3. 認可ボタンの横に、ユーザーが認可されたことを示す緑色のチェック・マークが表示されていることを確認します。
成功しない場合: Oracle Access Managerコンソールを使用して認可ポリシーを確認します。

4. 「ステータス・メッセージ」パネルで、テスト実行に関する詳細を確認します。

5. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。

6. 次の項目へ進みます。

- リクエスト待機時間の監視

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

リクエスト待機時間の監視

OAMサーバーのパフォーマンスを理解するには、OAMサーバーがエージェントから渡されるリクエストをどの程度の効率で処理しているかを知る必要があります。サーバーのメトリックを明らかにする方法は数多くありますが、エージェントの立場からサーバーのパフォーマンスを明らかにするのが有効な場合もあります。これは、アクセス・テスターを使用して次の手順により行うことができます。

前提条件

アクセス・テスターのインストールと起動

タスクの概要: リクエスト待機時間の監視には次のタスクが含まれます。

1. リソース保護の検証

2. アクセス・テスター・コンソールからユーザー認証をテスト

3. アクセス・テスター・コンソールからユーザー認可をテスト

4. 次に示す実行ログファイル内、およびテスト実行中に生成されるその他のファイル内の待機時間情報を確認します。次に例を示します。

...
[2/3/10 11:03 PM][info] Summary statistics
[2/3/10 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms
[2/3/10 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms
[2/3/10 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms
[2/3/10 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms
...

5. 次の項目へ進みます。

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

テスト・ケースおよびスクリプトの作成と管理

テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行う上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。

これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行うことは、ポリシー構成の質の低下を明らかにする助けとなります。

この項では、テスト管理を行うために必要な情報を次に示すトピックの中で示します。

- テスト・ケースとテスト・スクリプトについて

- テスト・ケースの取得

- 入力テスト・スクリプトの作成

- 入力テスト・スクリプトのパーソナライズ

- テスト・スクリプトの実行

テスト・ケースとテスト・スクリプトについて

テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。様々なデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。

取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較できます。古い結果が「確認済(Known Good)」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。

テスト・ケースのワークフローを図14-7に示します。

図14-7 テスト・ケースのワークフロー

「図14-7 テスト・ケースのワークフロー」の説明

タスクの概要: テスト・ケースの作成と管理

アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行うことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存できます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行うことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。

テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド・ラインからそのスクリプトを実行できます。

テスト・ケースの取得

それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信してレスポンスを受信した後に、取得キューに保存できます。テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に、個々のテスト・ケースを必要なだけ取得できます。例として、個別に取得する必要がある3つのテスト・ケースの概要を次に示します。

- 検証のリクエストと応答

- 認証のリクエストと応答

- 認可のリクエストと応答

表14-10に、取得オプションの場所を示します。

表14-10 アクセス・テスターの取得リクエスト・オプション

ロケーション

説明

「テスト」メニュー

最後の"..."リクエストを取得

「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。

ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。

取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。

1つまたは複数のテスト・ケースを取得する方法

1. 「アクセス・テスター・コンソールからの接続性とポリシーのテスト」の説明に従い、アクセス・テスターからリクエストを発行します。

2. 応答を受信したら、ツール・バーの「最後の"..."リクエストを取得」コマンド・ボタンをクリックします(または「テスト」メニューから同じオプションを選択)。

3. 「ステータス・メッセージ」パネルで取得を確認し、さらにコンソールの最も下に表示される取得キューのテスト・ケース数を確認します。

4. ステップ1、2、3を繰り返して、テスト・スクリプトに必要な各テスト・ケースをキュー内に取得します。

5. 「入力テスト・スクリプトの作成」へ進みます。

入力テスト・スクリプトの作成

テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。

アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理できます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアできます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行われます。

注意:
取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。

入力テスト・スクリプトの作成について

アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理できます。これらのスクリプトは次の規則に従わなければなりません。

- オペレータまたはシステムによるリプレイが可能

- 異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能

- 「確認済(Known Good)」の結果に対するテスト実行結果の比較が可能

スクリプト作成コマンドの場所を次に示します。

表14-11 スクリプト作成コマンド

コマンドの場所

説明

「テスト」メニュー

スクリプト作成

「テスト」メニューからスクリプト作成を選択して、取得したテスト・ケースを含むスクリプトの作成をを開始します。

ツール・バーからスクリプト作成コマンド・ボタンを選択して、取得したテスト・ケースを含むスクリプトの作成をを開始します。スクリプトの名前を指定または選択すると、取得キューをクリアするかどうかの確認が行われます。取得キューは、テスト・ケースがすべてスクリプトに保存されるまでクリアしないでください。

入力テスト・スクリプトの作成

前提条件

テスト・ケースの取得

取得したテスト・ケースを含むテスト・スクリプトの作成方法

1. 「テスト・ケースの取得」の説明に従い、スクリプトに含めたいリクエストを実行して取得します。

2. ツール・バーのスクリプト作成コマンド・ボタンをクリックして(または「テスト」メニューから同じオプションを選択して)、取得したすべてのテスト・ケースを含めます。

3. 新しいダイアログ・ボックスで新しいXMLスクリプト・ファイルの名前を選択または入力し、「保存」をクリックします。

4. 既存ファイルに上書きする場合は「はい」をクリックします(または「いいえ」をクリックしてウィンドウを閉じ、新しいファイル名を入力)。

5. 「警告の保存」ダイアログ・ボックスで「いいえ」をクリックして取得キューをそのまま維持し、スクリプトへのテスト・ケースの追加を継続します(または「はい」をクリックしてすべてのテスト・ケースのキューをクリア)。

6. アクセス・テスターを終了する前にテスト・スクリプトの場所を確認します。

7. 次に示すようにスクリプトの作成者、作成時期、作成理由などの詳細を含め、テスト・スクリプトをパーソナライズします。

入力テスト・スクリプトのパーソナライズ

この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。

- テスト・スクリプトのカスタマイズについて

- テスト・スクリプトのカスタマイズ

テスト・スクリプトのカスタマイズについて

スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使用してスクリプトをカスタマイズする場合もあります。

アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンドライン「制御」パラメータを使用できます (テスト名やテスト番号など)。これにより、「確認済(Known Good)」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表14-12に示します。

表14-12 テスト・スクリプト制御パラメータ

制御パラメータ

説明

ignorecontent=true

オリジナルのOAMサーバー応答と最新の応答を比較する際に、ユースケースの「コンテンツ」セクションの違いを無視します。デフォルトでは「コンテンツ」セクションを比較します。このパラメータは、コマンドライン・モードで実行するときはコマンドライン・プロパティで上書きできます。

デフォルト: false(「コンテンツ」セクションを比較)

値: trueまたはfalse

コマンドライン・モードでは、ignorecontent=trueを使用して入力スクリプトの制御セクションの指定値を上書きしてください。

testname="oamtest"

前の項に示したように、「結果バンドル」のファイル名に加える接頭辞を指定します。

コマンドライン・モードでは、Testname=nameを使用して「制御」セクションの指定値を上書きしてください。

configfile="config.xml"

アクセス・テスターによって過去に作成された構成XMLファイルへの絶対パスを指定します。

コマンドライン・モードでは、このファイルは、サーバー接続を確立するための接続詳細の場所を特定するためにアクセス・テスターが使用します。

numthreads="1"

複数のテスト・スクリプトのコピーを実行するために、アクセス・テスターによって開始されるスレッド(仮想クライアント)の数を示します。スレッドごとにポリシー・サーバーへの固有の接続プールが開きます。この機能はポリシー・サーバーのストレス・テストが目的で、コマンドライン・モードでのみ使用できます。

デフォルト: 1

GUIモードでテスト・スクリプトを実行する場合、スレッドの数は無視され、1つのスレッドのみが開始されてテスト・スクリプトを1回実行します。

numiterations="1"

アクセス・テスターが実行する繰返し回数を示します。この機能はポリシー・サーバーのストレス・テストおよび寿命テストが目的で、コマンドライン・モードでのみ使用できます。

デフォルト: 1

テスト・スクリプトのカスタマイズ

前提条件

入力テスト・スクリプトの作成

テスト・スクリプトのカスタマイズ方法

1. アクセス・テスターで作成したテスト・スクリプトを探して開きます。

2. スクリプトをカスタマイズまたはパーソナライズするために必要な詳細を追加します。

3. ファイルを保存して「テスト・スクリプトの実行」へ進みます。

テスト・スクリプトの実行

「確認済(Known Good)」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済」としてマークしたら、コンソールを使用してそれぞれのテストを手動で指定するのではなく、スクリプトを使用してアクセス・テスターを作動させることが重要です。この項の内容は次のとおりです。

- テスト・スクリプトの実行について

- テスト・スクリプトの実行

テスト・スクリプトの実行について

テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行できます。自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンドライン・モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。

注意:
.bat(Windows)や.sh(Unix)などのスクリプトは、コマンドライン・モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンドラインを使用して実行できます。

テスト・スクリプトを実行するためのコマンドを表14-13に示します。

表14-13 テスト・スクリプト実行コマンド

ロケーション

説明

「テスト」メニュー

スクリプト実行

保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、「テスト」メニューからスクリプト実行コマンドを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。

保存したテスト・スクリプトを現在のポリシー・サーバーに対して実行するには、ツール・バーからスクリプト実行コマンド・ボタンを選択します。「ステータス・メッセージ」パネルには、スクリプトの進行に伴って実行ステータスが表示されます。

コマンドライン・モード

.bat(Windows)や.sh(Unix)などのスクリプトは、コマンドライン・モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンドラインを使用して実行できます。

テスト実行時のアクセス・テスターの動作について次に概要を示します。コマンドライン・モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。

プロセスの概要: テスト・スクリプト実行時のアクセス・テスターの動作

1. アクセス・テスターが入力xmlファイルをロードします。
コマンドライン・モードでは、アクセス・テスターは入力テスト・スクリプトの「制御」要素内で定義された構成XMLファイルを開きます。

2. アクセス・テスターは、コンソールの「サーバー接続」パネル内の情報を使用してプライマリおよびセカンダリのOAMプロキシに接続します。
コマンドライン・モードでは、構成XMLファイル内の「接続」要素内の情報を使用します。

3. コマンドライン・モードでは、アクセス・テスターは入力スクリプトXMLファイルの「制御」要素をチェックして、コマンドラインで上書きされたものがないことを確認します(コマンドラインの値が優先されます)。

4. アクセス・テスターは、オリジナル・テスト・ケースのそれぞれについて次の処理を行います。

1. 新しいターゲット・テスト・ケースを作成します。

2. OAMサーバーにオリジナル・リクエストを送信してレスポンスを収集します。

3. 次の比較を行います。
新しいレスポンスとオリジナルのレスポンスを比較します。

レスポンス・コードを比較して、新しいターゲット・テスト・ケースのレスポンス・コードがオリジナル・テスト・ケースと異なる場合は、そのターゲット・テスト・ケースを「不一致(mismatced)」としてマークします。たとえば、オリジナル検証へのレスポンスが「はい」で新しい検証へのレスポンスが「いいえ」の場合は、不一致としてマークされます。

レスポンス・コードが同じで「ignorecontent」制御パラメータが「false」の場合、アクセス・テスターは「コンテンツ」を比較します(認証スキームの名前や各リクエスト後に記録される認可後のアクション)。「コンテンツ」セクションが異なる場合、新しいターゲット・テスト・ケースは「不一致」としてマークされます。

4. 新しい経過時間を収集してそれをターゲット・ユースケースに保存します。

5. 最後のサーバー・リクエストのすべての状態、およびオリジナル・テスト・ケースと同じ固有ID(UUID)を含む新しいターゲット・テスト・ケースを作成します。

6. ターゲット・テスト・ケースの統計値(リクエスト・タイプ、経過時間、不一致など)を使用して内部統計表を更新します。

5. すべての入力テスト・ケースが終了すると、アクセス・テスターは次の処理を行います。

1. 結果のサマリーを表示します。

2. testnameとtestnumberを取得して組み合わせ、「結果バンドル」(<testname>_<testnumber>で始まる名前を持つ3つのファイル)の名前を作成します。

注意:
テスト名とテスト番号のコマンドライン・パラメータを指定することにより、シェル・スクリプトを使用してバンドルの作成を自動化できます。

コマンドライン・パラメータからtestnameを取得します。コマンドラインで指定されていない場合は、入力スクリプトの「制御」ブロックにあるtestname要素を使用します。

コマンドライン・パラメータからtestnumberを取得します。指定されていない場合のtestnumberのデフォルトは、現在のローカル時刻に基づく7文字の数値文字列(分数を表す2文字、秒数を表す2文字、1/100秒を表す3文字)となります。

3. 「結果バンドル」、つまり<testname>_<testnumber>で始まる名前の3つのファイルを作成します。
ターゲットXMLスクリプトには新しいテスト・ケースが格納されます: <testname>_<testnumber_results.xml

統計XMLファイルには、テスト実行全体のサマリーと詳細、および「不一致(mismathed)」とマークされたテスト・ケースが格納されます: <testname>_<testnumber_stats.xml

「ステータス・メッセージ」パネルの情報が格納される実行ログ・ファイル: <testname>_<testnumber_log.log.

4. マルチスレッド・モードで実行する場合、統計XMLファイルと実行ログ・ファイルのみが生成されます。

5. コマンドライン・モードでは、「アクセス・テスターのコマンドライン・モードについて」に示すようにアクセス・テスターは終了コードで終了します。

テスト・スクリプトの実行

前提条件

入力テスト・スクリプトの作成

テスト・スクリプトの実行方法

1. 「入力テスト・スクリプトの作成」に示すように、アクセス・テスターを終了する前に保存テスト・スクリプトの場所を確認します。

2. 次のいずれかの方法を使用し、処理のためにテスト・スクリプトを送信します。

- アクセス・テスター・コンソールでツール・バーからスクリプト実行コマンド・ボタンを選択して(または「テスト」メニューのスクリプト作成を選択して)プロンプトに従い、スクリプトの実行に合わせて「ステータス・メッセージ」パネルに表示されるメッセージを確認します。

- コマンドラインから、希望のシステム・プロパティが指定されたテスト・スクリプトを指定します。「コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する」を参照してください。

java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true"
-jar oamtest.jar

3. 「スクリプト、ログ・ファイル、および統計の評価」に示すように、ログ・ファイルと出力ファイルを確認し、新たに作成された結果と入力スクリプトから取得した結果をアクセス・テスターが比較した後で、追加的な分析を行います。

スクリプト、ログ・ファイル、および統計の評価

この項の内容は次のとおりです。

- テスト結果の評価について

- 保存された接続構成ファイルについて

- 作成された入力テスト・スクリプトについて

- テスト実行結果が格納されたターゲット出力ファイルについて

- 統計ドキュメントについて

- 実行ログについて

テスト結果の評価について

テスト実行終了時には、3つのドキュメントからなる「結果バンドル」が作成されます。

- ターゲット・スクリプト: 新しいテスト・ケースが格納されたXMLドキュメント

注意:
アクセス・テスターがマルチスレッド・モードで実行するように構成されている場合、ターゲット・スクリプトは作成されません。

- 実行ログ: スクリプト実行時に表示されたメッセージが格納されたテキストファイル

- 実行統計: テスト・メトリックと不一致要素のリストが格納されたXMLドキュメント

オリジナル・スクリプトとターゲット・スクリプト内にあるテスト・ケースの一致ペアは、テスト・ケースIDを共有しています。このIDは、オリジナル・スクリプトとターゲット・スクリプト内の個々のテスト・ケースの比較を可能にするUUID(中略)で表わされます。詳細は「作成された入力テスト・スクリプトについて」を参照してください。

統計ドキュメントにはサマリー統計と詳細統計、および一致しなかったテスト・ケースのリストが格納されます。詳細統計は、さらに詳しい分析や結果履歴の記録に使用できます。サマリー統計はテスト実行の終了時に表示されるものと同じ統計で、テスト実行の結果を迅速に評価するために使用できます。統計ドキュメント内に作成される不一致テスト・ケースのリストには、表14-14に示すように、不一致をトリガーしたテスト・ケースIDと不一致の理由が含まれています。

表14-14 統計ドキュメントの不一致結果の理由

不一致の理由

説明

結果

OAMサーバーのレスポンス・コード(「はい」と「いいえ」)が異なるためテスト・ケースが一致しませんでした。

コンテンツ

OAMサーバーによって返された特定データの値が異なるためテスト・ケースが一致しませんでした。不一致をトリガーした最後のテスト実行時の特定値が含まれます。

保存された接続構成ファイルについて

これは、「ファイル」メニューの「構成を保存」コマンドを使用して保存した出力ファイルで、デフォルトのファイル名はconfig.xmlです。この接続構成ファイルには、アクセス・テスター・コンソールのサーバー接続パネルで指定された詳細が格納されています。

注意:
次のトピックに示すように、入力テスト・スクリプト・ファイルも作成されます。構成ファイル名は、アクセス・テスターをコマンドライン・モードで実行した時に接続ファイル内に定義された接続情報を取得できるようにするために、入力テスト・スクリプト内で使用されます。

例14-1 接続構成ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestconfig xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<connection timeout="30000" minnconn="1" mode="open">
<agent password="00030d05101b050c42" name="agent1"/>
<keystore rootstore="" keystore_password="" keystore=""
global_passphrase=""/>
<primary>
<server maxconn="1" port="2100" addr="oam_server1"/>
</primary>
<secondary>
<server maxconn="1" port="0" addr=""/>
</secondary>
</connection>
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>admin1</id>
<password>00030d05101b050c42</password>
<certstore></certstore>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</oamtestconfig>

作成された入力テスト・スクリプトについて

入力テスト・スクリプトは、アクセス・テスターを使用してユーザー固有のテスト・ケースを取得することによって作成されます。「制御」要素の「configfile」属性は、OAMサーバーとの接続確立用にコマンドライン・モードで使用する接続構成ファイルを指定するために、作成後に更新されます。

例14-2 生成された入力テストスクリプト

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Manually generated using agent 'agent1'"
createdon="2010-02-03T22:28:00.468-05:00" createdby="test_user"/>
<control numthreads="1" numiterations="1" ignorecontent="false"
testname="samplerun1" configfile="config.xml"/>
<cases numcases="4">
<case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0">
<request code="Validate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="984" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content>
<line type="auth.scheme.id">LDAPScheme</line>
<line type="auth.scheme.level">2</line>
<line type="auth.scheme.required.creds">2</line>
<line type="auth.scheme.redirect.url">http://dadvmh0172.us.oracle.com:14100/oam/server/</line>
</content>
</response>
</case>
<case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a">
<request code="Authenticate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<certstore></certstore>
<ipaddr>192.168.1.8</ipaddr>
</identity>
</request>
<response elapsed="187" code="Yes">
<comment></comment>
<status>Major code: 10(CredentialsAccepted) Minor code:
2(NoCode)</status>
<content>
<line type="user.dn">cn=weblogic,dc=us,dc=oracle,dc=com</line>
</content>
</response>
</case>
<case uuid="84fe9b06-86d1-47df-a399-6311990743c3">
<request code="Authorize">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<certstore></certstore>
<ipaddr>192.168.1.8</ipaddr>
</identity>
</request>
<response elapsed="188" code="Yes">
<comment></comment>
<status>Major code: 8(Allow) Minor code: 2(NoCode)</status>
<content/>
</response>
</case>
<case uuid="61579e47-5532-42c3-bbc7-a00828256bf4">
<request code="Validate">
<uri getauthscheme="false">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="172" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content/>
</response>
</case>
</cases>
</oamtestscript>

テスト実行結果が格納されたターゲット出力ファイルについて

この例は、コマンドライン・モードでアクセス・テスターを実行して、取得した4つのテスト・ケースを実行するための入力としてscript.xmlファイルを指定することにより作成されたものです。

Dscript.scriptfile="script.xml" -jar oamtest.jar

例14-3の様々なセクションに注意してください。実行ログに示すようにこのテスト実行では不一致が見つからず、4つのリクエストのすべてが一致していることが示されています。

例14-3 テスト実行中に生成された出力ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent 'agent1'"
createdon="2010-02-03T23:03:02.171-05:00" createdby="test_user"/>
<control numthreads="1" numiterations="1" ignorecontent="false"
testname="oamtest" configfile=""/>
<cases numcases="4">
<case uuid="465a4fda-d814-4ab7-b81b-f3f1cd72bbc0">
<request code="Validate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="969" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content>
<line type="auth.scheme.id">LDAPScheme</line>
<line type="auth.scheme.level">2</line>
<line type="auth.scheme.required.creds">2</line>
<line type="auth.scheme.redirect.url">http://dadvmh0172.us.oracle.com:14100/oam/server/
</line>
</content>
</response>
</case>
<case uuid="009b44e3-1a94-4bfc-a0c3-84a38a9e0f2a">
<request code="Authenticate">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<certstore></certstore>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</request>
<response elapsed="187" code="Yes">
<comment></comment>
<status>Major code: 10(CredentialsAccepted) Minor code:
2(NoCode)</status>
<content>
<line type="user.dn">cn=weblogic,dc=us,dc=oracle,dc=com</line>
</content>
</response>
</case>
<case uuid="84fe9b06-86d1-47df-a399-6311990743c3">
<request code="Authorize">
<uri getauthscheme="true">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
<identity>
<id>weblogic</id>
<password>00030d05101b050c42</password>
<certstore></certstore>
<ipaddr>111.222.3.4</ipaddr>
</identity>
</request>
<response elapsed="172" code="Yes">
<comment></comment>
<status>Major code: 8(Allow) Minor code: 2(NoCode)</status>
<content/>
</response>
</case>
<case uuid="61579e47-5532-42c3-bbc7-a00828256bf4">
<request code="Validate">
<uri getauthscheme="false">
<scheme>http</scheme>
<host>oam_server1</host>
<port>7777</port>
<resource>/index.html</resource>
<operation>Get</operation>
</uri>
</request>
<response elapsed="171" code="Yes">
<comment></comment>
<status>Major code: 4(ResrcOpProtected) Minor code:
2(NoCode)</status>
<content/>
</response>
</case>
</cases>
</oamtestscript>

統計ドキュメントについて

統計ファイル(_stats.xml)は、実行ログに示されたテスト実行時にターゲット出力スクリプトとともに作成されます。script.xmlファイルは、取得した4つのテスト・ケースを実行するための入力として使用されます。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。

サンプル統計ドキュメントを例14-4に示します。この実行の統計は様々なセクションに示されており、これらと過去の「確認済(Known Good)」の統計と比較できます。

例14-4 統計ドキュメントの例

A sample statistics document is shown here. Notice,
<oamteststats xmlns="http://xmlns.oracle.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent
'agent1'" createdon="2010-02-03T23:03:02.171-05:00" createdby="test_user"/>
<summary>
<total>
<nummatched>4</nummatched>
<numtotal>4</numtotal>
<avgelapsedsource>238</avgelapsedsource
<avgelapsedtarget>232</avgelapsedtarget>
</total>
<validate>
<nummatched>2</nummatched>
<numtotal>2</numtotal>
<avgelapsedsource>578</avgelapsedsource>
<avgelapsedtarget>570</avgelapsedtarget>
</validate>
<authenticate>
<nummatched>1</nummatched>
<numtotal>1</numtotal>
<avgelapsedsource>187</avgelapsedsource>
<avgelapsedtarget>187</avgelapsedtarget>
</authenticate>
<authorize>
<nummatched>1</nummatched>
<numtotal>1</numtotal>
<avgelapsedsource>188</avgelapsedsource>
<avgelapsedtarget>172</avgelapsedtarget>
</authorize>
<summary>
<detail>
<source>
<validate>
<yes>2</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>1156</elapsed>
</validate>
<authenticate>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>187</elapsed>
</authenticate>
<authorize>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>188</elapsed>
</authorize>
</source>
<target>
<validate>
<yes>2</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>1140</elapsed>
</validate>
<authenticate>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>187</elapsed>
</authenticate>
<authorize>
<yes>1</yes>
<no>0</no>
<error>0</error>
<mismatch>0</mismatch>
<elapsed>172</elapsed>
</authorize>
<target>
</detail>
<mismatch numcases="0"/>
</oamteststats>

実行ログについて

このサンプル実行ログは、テスト実行時に4つのテスト・ケースを実行するscript.xmlを使用して、ターゲット出力スクリプトとともに作成されたものです。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。

この例を見ると、アクセス・テスターの「ステータス・メッセージ」パネルに表示される情報と同じ情報で構成されていることが分かります。テスト・ケース、テスト名、接続構成ファイル、エージェント名、接続ステータス、リクエスト評価ステータス、認証スキーム、リダイレクトURL、求められる資格証明、認証ステータスとユーザーDN、セッションID、認証ステータス、検証ステータス、サマリー統計などを確認してください。また、この実行によってターゲット・スクリプトと統計ドキュメントが作成されていることにも注意してください。

例14-5 実行ログ

[2/3/10 11:02 PM][info] Setting up to run script 'script.xml'
[2/3/10 11:02 PM][info] Loading test cases and control parameters from script
[2/3/10 11:02 PM][info] Loaded 4 cases
[2/3/10 11:02 PM][info] Control data for this test run:
[2/3/10 11:02 PM][info] Test name : 'samplerun1'
[2/3/10 11:02 PM][info] Configuration file : 'config.xml'
[2/3/10 11:02 PM][info] Ignore content : 'false'
[2/3/10 11:02 PM][info] Loading server configuration from file
[2/3/10 11:02 PM][info] Loaded server configuration
[2/3/10 11:02 PM][info] Connecting to server as agent 'oam_agent1'
[2/3/10 11:03 PM][info][request] Connect : Yes
...
[2/3/10 11:03 PM][info] Test 'samplerun1' will process 4 cases
[2/3/10 11:03 PM][info][request] Validate : Yes
[2/3/10 11:03 PM][info] Authentication scheme : LDAPScheme, level : 2
[2/3/10 11:03 PM][info] Redirect URL :
http://oam_server1.us.company.com:2100/server/
[2/3/10 11:03 PM][info] Credentials expected: 0x01 (password)
[2/3/10 11:03 PM][info][request] Authenticate : Yes
[2/3/10 11:03 PM][info] User DN : cn=admin1,dc=us,dc=company,dc=com
[2/3/10 11:03 PM][info] Session ID : -1
[2/3/10 11:03 PM][info][request] Authorize : Yes
[2/3/10 11:03 PM][info][request] Validate : Yes
[2/3/10 11:03 PM][info] Summary statistics
[2/3/10 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms
[2/3/10 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms
[2/3/10 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms
[2/3/10 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms
[2/3/10 11:03 PM][info] Generated target script 'samplerun1_0302171__target.xml'
[2/3/10 11:03 PM][info] Generated statistics log 'samplerun1_0302171__stats.xml'

15 OAM 11gの集中ログアウトの構成

エージェントが異なれば、ログアウトの実行ステップも異なります。Oracle Access Manager 11gのログアウトは、この章に説明する方法で行うことをお薦めします。

この章の内容は次のとおりです。

- 前提条件

- OAM 11gの集中ログアウトの概要

- OAM 11gサーバー使用時の11g Webgateの集中ログアウト構成

- IAMSuiteAgentの集中ログアウト構成

- OAM 11gサーバー使用時の10g Webgateの集中ログアウト構成

- Oracle ADFコード・アプリケーションの集中ログアウト構成

- ログアウト時のカスタムmod_osso Cookieの削除

- グローバル・サインオンと集中ログアウトの検証

注意:
ログアウトには、カスタム・ログアウト・スクリプトではなくOracle Access Managerが提供するログアウト・メカニズムを使用することをお薦めします。

前提条件

この章に示すタスクを実行するには、次の前提条件を満たす必要があります。

- OAM 11gによってエージェントが構成され登録されたWebサーバー上に、パートナ・アプリケーションがデプロイされていなければなりません。

- サポートされている任意のサーバーおよびプラットフォーム上で次のいずれかのエージェントが実行され、OAM 11gがプロビジョニングされていなければなりません。

- OAM 11gサーバー使用のOAM 11g Webgate

- OAM 11gサーバー使用のIAMSuiteAgent

- OAM 11gサーバー使用のOAM 10g Webgate

- OAM 10gサーバー使用のOAM 10g Webgate

- OSSOエージェント(mod_osso)

- ポリシーは、OAM 11gアプリケーション・ドメイン内のリソースを保護するように構成しなければなりません。

OAM 11gの集中ログアウトの概要

Oracle Access Manager 11gでは、ユーザー・セッションで集中ログアウト(グローバル・ログアウトとも呼ばれます)を行うことができます。OAMでは、アクティブ・ユーザー・セッションを終了させるプロセスを集中ログアウトと呼びます。

集中ログアウトを行うということは次のことを意味します。

- アプリケーションが、SSO環境で使用する固有のログアウト・ページを提供することはできません。

- アプリケーションは、OAM Webgate Administratorが指定するログアウトURLを参照する値でログアウト・リンクを構成できるようにする必要があります。

注意:
アプリケーションでADF認証サーブレットを使用することをお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。

表15-1に、集中ログアウトが行われる状況を示します。

表15-1 集中ログアウトの状況

明示的

クライアントの状態が無効化されてセッションが終了。リソースに再度アクセスしようとする場合、クライアントは再認証を行わなければなりません。

- ユーザーがログアウトした時

- 管理者がセッションを終了させた時

- アイデンティティ側の変化に基づいてセッションが終了された時

暗黙的

定められたセッション・タイムアウト時間内にユーザー・アクティビティがなかった場合、そのユーザーは自動的にログアウトされてパートナにリダイレクトされ、新しいセッションIDが付与されて資格証明のために新しいプロンプトが表示されます。これは、リソースに対して低レベルの認証が構成されていない場合に実行されます。

OAM 11gの場合、logout.htmlにサーバー・ログアウトへの明示的なリダイレクトが指定されていないかぎり、10g Webgateが単にログアウトURLに遭遇しただけではユーザーはログアウトされません。OAM 11g Webgateは、サーバー・ログアウトへユーザーをリダイレクトします。

ログアウトURLが見つかり、Cookieが削除された場合(10g WebgateのObSSOcookie、11g WebgateのOAMAuthnCookie):Webgateがユーザーをログアウトさせて再認証を要求します。

注意:
パートナ・アプリケーションと異なり、外部アプリケーション(Yahoo!Mailなど)はOAMに認証を委任せず、ログアウト制御をOAMシングル・サインオン・サーバーに引き渡すこともしません。これらのアプリケーションのログアウトはユーザーの責任となります。

この項の内容は次のとおりです。

- OAM 11gエージェントおよびサーバー使用時の集中ログアウトについて

- OAM 10gエージェントとOAM 11gサーバー使用時の集中ログアウトについて

- IAMSuiteAgent使用時の集中ログアウトについて

- OSSOエージェント(mod_OSSO)とOAM 11g使用時の集中ログアウトについて

- Oracle ADFセキュリティを使用するアプリケーションでの集中ログアウトについて

OAM 11gエージェントおよびサーバー使用時の集中ログアウトについて

この項では、アプリケーションを保護するOAM 11g Webgateで行われるサインアウト処理について説明します。

一般的に、OAM 11gサーバー使用時の集中ログアウトの際には、SSOエンジンがユーザー・セッションの有無を問う要求を受け取ります。セッション管理エンジンはユーザー・セッションを参照し、ユーザー・セッションが存在するという応答をします。SSOエンジンはユーザー・セッション削除要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。SSOエンジンはユーザー・セッション削除完了レスポンスを送信します。

ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはパートナ・アプリケーションのクライアント側状態を削除します。詳細は、「OAM 11gサーバー使用時の11g Webgateの集中ログアウト構成」を参照してください。

OAM 10gエージェントとOAM 11gサーバー使用時の集中ログアウトについて

次のプロセス概要では、標準的なSSOエンジンとセッション管理エンジンによる集中ログアウト時の処理を要約して示します。

登録されたOAM 10g Webgateに対して構成されたlogout.htmlファイルがアプリケーションによって起動されると、ログアウトが開始されます。

一般的に、OAM 10g Webgate使用時の集中ログアウトの際には、SSOエンジンがユーザー・セッションの有無を問う要求を受け取ります。セッション管理エンジンはユーザー・セッションを参照し、ユーザー・セッションが存在するという応答をします。SSOエンジンはユーザー・セッション削除要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。SSOエンジンはユーザー・セッション削除完了レスポンスを送信します。

ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはパートナ・アプリケーションのクライアント側状態を削除します。詳細は、「OAM 11gサーバー使用時の10g Webgateの集中ログアウト構成」を参照してください。

IAMSuiteAgent使用時の集中ログアウトについて

IAMSuiteAgentはドメイン全体を対象とするエージェントで、IDM管理コンソールに単一のサインオン機能を提供します。IAMSuiteAgentは、Oracle Access Manager 11g Serverのインストールと構成の一部としてインストールされ、事前構成されています。

詳細は、「IAMSuiteAgentの集中ログアウト構成」を参照してください。

OSSOエージェント(mod_OSSO)とOAM 11g使用時の集中ログアウトについて

OSSOエージェント(mod_osso 10g)では、パートナ・アプリケーションはログアウト制御もOAMシングル・サインオン・サーバーに引き渡します。ユーザーが1つのパートナ・アプリケーションをログアウトすると、そのユーザーは自動的に他のすべてのパートナ・アプリケーションをログアウトします。

注意:
OSSOエージェントを使用する既存アプリケーションのログアウトURL構成に変更を加える必要はありません。

プロセス概要: mod_ossoによる集中ログアウト

1. パートナ・アプリケーションで「ログアウト」をクリックすると、ログアウト用のページが表示されます。

2. ユーザーが正常にサインオフすると、集中ログアウト・ページにリストされた各アプリケーションのアプリケーション名の横にチェック・マークが表示されます。

3. アプリケーション名の横に壊れたイメージが表示された場合は、ログアウトが正常に行われなかったことを示します。

4. セッション内でアクティブにされたすべてのアプリケーションにチェック・マークが表示されると、「戻る」をクリックすればログアウトを開始したアプリケーションに戻ることができます。

5. ログアウト時にカスタムmod_ossoエージェントCookieを削除します。

Oracle ADFセキュリティを使用するアプリケーションでの集中ログアウトについて

Oracle Application Development Framework(Oracle ADF)セキュリティとOracle Platform Security Services(OPSS)は、Oracle WebLogic Serverのセキュリティ・フレームワークで構成されています。Oracle WebLogic Server上では、Oracle ADFセキュリティを使用するWebアプリケーション、Oracle Access Manager 11g SSOと統合化されたWebアプリケーション、およびユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。

この状況でユーザーは、作業中の任意のアプリケーションをログアウトすることにより、シングル・サインオン・セッションを終了させてすべてのアクティブ・パートナ・アプリケーションを同時にログアウトできます。

詳細は、「OAM 11g使用時のADFコード・アプリケーションの集中ログアウト構成」を参照してください。

OAM 11gサーバー使用時の11g Webgateの集中ログアウト構成

この項の内容は次のとおりです。

- 11g Webgateの集中ログアウト構成について

- 11g Webgateの集中ログアウト構成

11g Webgateの集中ログアウト構成について

OAM 11g Webgate登録ページのいくつかの要素は、OAM 11g Webgateの集中ログアウトを可能にします。登録後はObAccessClient.xmlファイルに表15-2の情報が格納されます。

表15-2 OAM 11g Webgate登録のログアウト要素

要素

説明

ログアウトURL

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Oracle Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

- 一致する場合、Webgateログアウト・ハンドラが起動します。

- ログアウトURLが構成されていない場合、「ログアウト」のリクエストURLが確認され、見つかった場合(「logout.gif」および「logout.jpg」を除く)にもログアウト・ハンドラが起動します。

Default = [](未設定)

注意: これは、最初のログアウトをトリガーするために使用される標準OAM 10g Webgate構成パラメータです。

11g Webgateのみのその他のログアウト

OAM 11g Webgateシングル・サインオフの動作については、次の要素と値によって、集中ログアウトURL、コールバックURLおよびエンドURLへのリダイレクトが自動化されます。これは、カスタマイズされたローカル・ログアウト・ページを使用した場合のみ、10g Webgateシングル・サインオフのかわりに使用されます。

ログアウト・コールバックURL

コールバック中にCookieを消去するoam_logout_successのURL。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。次に例を示します。

デフォルト = /oam_logout_success

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAM 11gサーバーは、コールバックURLを再構築することなく直接コールバックします。

リクエストURLがログアウト・コールバックURLに一致したとき、Webgateは自身のcookieを消去してレスポンスで.gifイメージをストリーミングします。これはOSSOエージェントの動作に似ています。

Webgateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ(end_url=http://host:port/...")として記録され、ログアウト後にOAM 11gサーバーがリダイレクトする先のページになります。

他のOAM 11gサービスは、サーバー上の集中ログアウト・ページをサポートします。end_urlは、OPSS組み込みアプリケーションから渡されるターゲットURL問合せパラメータに依存しています。

ログアウト・リダイレクトURL

このパラメータはエージェントの登録完了後に自動的に格納されます。デフォルトでは、これはデフォルト・ポートが14200のOAMサーバー・ホスト名に基づいて決定されます。たとえば:

デフォルト = http://OAMServer_host:14200/oam/server/logout

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはOAMAuthnCookie_<host:port>_<random number>を削除し、Oracle Access Managerに保護されたリソースにユーザーが再アクセスした時に改めて認証を要求します。

- Webgateログアウト・ハンドラがトリガーされると、このハンドラはログアウト・リダイレクトURLパラメータに指定された集中ログアウト・ページにリダイレクトします(ログアウト・リダイレクトURLパラメータが指定されている場合)。

- ログアウト・リダイレクトURLはエージェント登録後に移入されるので、このURLが構成されていないとは考えられません。10gの動作がトリガーされた場合は、別のページにリダイレクトせずにローカル・ログアウト・ページを表示します。ローカル・ログアウト・ページでは、カスタマイズされたスクリプトを使用して集中ログアウト・ページにリダイレクトが可能で、必要な場合は追加的なサード・パーティのCookieを削除できます。

ログアウト・ターゲットURL

この値は、ログアウト時にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。

デフォルト: end_url

注意: end_urlの値はparam.logout.targeturl in jps-config.xmlを使用して設定します。

- ログアウト・ターゲットURLが設定されている場合、Webgateはログアウト・リクエストの問合せパラメータで渡された値を探し、それをOAMサーバーへのリダイレクトURL内のend_url問合せパラメータとして渡します。

- ログアウト・ターゲットURLが設定されていない場合、Webgateはデフォルト名「end_url」を探し、そのend_url問合せパラメータを一緒に渡します。

OAM 11gに対する11g Webgateのログアウトを構成するには、logoutCallbackUrlが必要です。11gエージェントの集中ログアウトはCookieを「loggedout」から空の状態にし、(空状態やログアウトされた状態のCookieのままにせずに)ログアウト時にOAMAuthnCookie_<host:port>_<random number> Cookieを期限切れにしてこれを明示的に削除します。

OAM 11g Webgateと10g Webgateはごく一部が異なるだけで、11gは「logoutCallbackUrl」のURI部分のみを照合します。

SSOエンジンはOAMサーバー上の集中ログアウト・ページをサポートし、次の処理を行います。

- ログアウト時に11g Webgateの「logoutCallbackUrl」をコールバックします。

- ログアウト後に「end_url」(問合せパラメータとして渡される)へランディングします。

Webgateパラメータ「logoutCallbackUrl」は構成可能です(たとえば/oam_logout_successとして)。host:portのないURIフォーマットを使用することをお薦めします。この場合OAM Serverは、オリジナル・リクエストのhost:portに基づいて完全なURLを動的に作成し、そこへコールバックします。

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAM 11gサーバーは、コールバックURLを再構築することなく直接コールバックします。

OAMサーバーはCookieを「loggedout」から空の状態に設定し、このCookieを空状態やログアウトされた状態のままにせずに、ログアウト時に期限切れにして明示的に削除します。

詳細は「11g Webgateの集中ログアウト構成」を参照してください。

11g Webgateの集中ログアウト構成

OAM 11g Webgateの登録時には、次の手順を使用してOAM 11g使用時のログアウトを構成してください。

11g Webgateの集中ログアウト構成方法

1. 登録の方法を選択します。

- 第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」

- 第10章「パートナ(エージェントおよびアプリケーション)のリモート登録」

2. エージェント登録の作成や編集を行うときは、使用環境に適したログアウト値を含めてください(表15-2)。

注意:
LogOutUrlパラメータがすでに(「/oamsso/logout.html」以外の値によって)11g Webgate用に構成されている場合は、「/oamsso/logout.html」もLogOutUrlパラメータの一部として存在することを確認します。

- ログアウトURL

- ログアウト・コールバックURL

- ログアウト・リダイレクトURL

- ログアウト・ターゲットURL

3. 通常どおりエージェント登録を終了させます。

4. 「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。

IAMSuiteAgentの集中ログアウト構成

IAMSuiteAgentは、OAM 11gサーバーに対して集中ログアウトを行うために必要なログアウト・パラメータによって事前構成されています。IAMSuiteAgentは10g Webgateに似ていますが、構成の必要があるlogout.htmlページがありません。かわりに、IAMSuiteAgentにはデプロイ済のアプリケーション(oamsso_logout)が同梱されており、エージェントはこれを使用してログアウトします。

IAMSuiteAgentのログアウト機能を使用するには、IAMSuiteAgentを使用するサーバー上にoamsso_logoutアプリケーションがデプロイされている必要があります。最初のインストール時には、このアプリケーションはAdminServerとOAMサーバーに追加されます。ただし、このアプリケーションのターゲット・サーバーを更新して、IAMSuiteAgentを使用しているすべてのサーバーを含めることが必要です。

IAMSuiteAgentのログアウトの構成手順

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン」→「デプロイメント」→「oamsso_logout」→「ターゲット」へナビゲートします。

3. IAMSuiteAgentが有効でログアウトが実行されるすべてのサーバーを選択します。たとえば、oim_server、oaam_admin、oaam_serverなどです。

4. 「保存」をクリックします。

OAM 11gサーバー使用時の10g Webgateの集中ログアウト構成

この項の内容は次のとおりです。

- OAM 11gサーバー使用時の10g Webgateの集中ログアウト処理について

- OAM 11gサーバー使用時のOAM 10gエージェントの集中ログアウト・スクリプトについて

- OAM 11g使用時の10g Webgateの集中ログアウト構成

OAM 11gサーバー使用時の10g Webgateの集中ログアウト処理について

次のプロセス概要では、OAM 11gの集中ログアウト・プロセスを要約して示しますが、このプロセスが発生するのは、保護機能を果たすOAM 10g Webgateが構成されたWebサーバー上にアプリケーションがデプロイされた時です。

ログアウトは、登録されたOAMエージェント(この場合は10g Webgate)に対して構成されたlogout.htmlファイルがアプリケーションによって起動されると開始されます。

プロセス概要: OAM 11gサーバー使用時のWebgate 10gの集中ログアウト

1. アプリケーションが、OAM 10g Webgateに対して構成されたlogout.htmlファイルを起動します。
アプリケーションはend_urlも問合せ文字列としてlogout.htmlに渡します。end_urlパラメータはURIまたはURLとすることができます。次に例を示します。

/oamsso/logout.html?end_url=/welcome.html
or
/oamsso/logout.html?end_url=http://my.site.com/welcome.html

2. WebgateはそのドメインのObSSOCookieを削除して、logout.htmlスクリプトをロードします。

3. end_urlパラメータにhost:portが含まれていない場合、logout.htmlスクリプトはローカル・サーバーのhost:portを取得してend_urlパラメータをURLとして構成します。次に例を示します。

http://serverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html

4. logout.html内のロジックがOAMサーバーにリダイレクトします。次に例を示します。

http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html

5. OAMサーバーが次のようにログアウトを実行します。

1. サーバー側のユーザーに関連付けられたセッション情報をクリーン・アップします。

2. end_urlを確認して、コールバックURLを含むページをユーザーのブラウザに送信します。

注意:
ログアウト・コールバックURLは、「Webgate登録の作成と編集について」に示すように、拡張OAMエージェント登録ページで指定します。

3. コールバック・ページから、各Webgateの特定URIに対して新しいリクエストが開始されます。このリクエストが特定ドメインの特定Webgateに届くと、そのドメインのObSSOCookieは消去されます。

4. ユーザーは、ログアウト・スクリプト内のend_urlにリダイレクトされます。ただし、end_urlパラメータがない場合はOAMサーバーによって適切なメッセージが送信されます。

詳細は、「OAM 11gサーバー使用時のOAM 10gエージェントの集中ログアウトスクリプトについて」を参照してください。

OAM 11gサーバー使用時のOAM 10gエージェントの集中ログアウト・スクリプトについて

OAM 10g Webgateでは、シングルおよびマルチ両方のDNSドメイン集中ログアウト処理にlogout.htmlスクリプトが必要です。logout.htmlは、実際にログアウトを行うJavaScriptsをアクティブにします。

注意:
OAM 11g Webgateではlogout.htmlスクリプトを使用しないかわりに、「OAM 11gサーバー使用時の11g Webgateの集中ログアウト構成」に示すようにエージェント登録をさらに詳細に構成する必要があります。

例15-1は、ユーザー固有の環境に合わせて一定の行を編集することによりテンプレートとして使用できる、logout.htmlスクリプトです(編集の必要性についてはスクリプトの最上部に記述されています)。たとえば、SERVER_LOGOUTURLを変更する必要があります。この例の後に追加的情報を示します。

例15-1 logout.htmlのスクリプト

<html>
<head>
<script language="javascript" type="text/javascript">
///////////////////////////////////////////////////////////////////////////////
//Before using, you need to change the values of:
//a. "oamserverhost" to point to the host where the OAM 11g Server is running.
//b. "port" to point to the port where the OAM 11g Server is running.
///////////////////////////////////////////////////////////////////////////////
var SERVER_LOGOUTURL = "http://oamserverhost:port/oam/server/logout";
///////////////////////////////////////////////////////////////////////////////

function handleLogout() {

//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);
var newQueryString = "";

//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;

if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
for (var i=0; i<params.length; i++) {
if (i == 0)
newQueryString = "?";

if (i > 0)
newQueryString = newQueryString + "&";

par = params[i].split("=");

//prepare a new query string, if the end_url value needs to be changed
newQueryString = newQueryString + (par[0]);
newQueryString = newQueryString + "=";
val = par[1];

if ("end_url" == par[0]) {
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (val.substring(0,1) == "/" || val.substring(0,1) == "%") {
//modify the query string now
val = webServerProtocol + "//" + webServerHostPort + val;
}
}
newQueryString = newQueryString + val;
}
}
//redirect the user to this URL
window.location.href = SERVER_LOGOUTURL + newQueryString;
}
</script>
</head>

<body onLoad="handleLogout();">

</body>
</html>

プロセス概要: logout.htmlのロジック

1. 着信リクエストからホストとポートを取得します。

2. 問合せ文字列からend_urlパラメータを取得します。
end_urlパラメータがURLでない場合は、logout.htmlスクリプトがタスク1のホストとポートを使用してURLを作成します。「logout.html内のend_urlパラメータのガイドライン」を参照してください。

3. OAMサーバーのログアウトURL(SERVER_LOGOUTURL)へのリダイレクト。例: http://myoamserver/host:port/oam/server/logout

- プロセス2で作成したend_urlを問合せ文字列として使用。

- 問合せ文字列内の他のすべての問合せ文字列パラメータを保存。

logout.html内のend_urlパラメータのガイドライン

end_urlパラメータはURIまたはURLとすることができます。

- end_url問合せ文字列がホストとポートを持たないURIの場合、logout.htmlは、logout.htmlがホストされるWebサーバーのホストとポートを決定することによってURLを作成しなければなりません。次に例を示します。

http://myoamserverhost:port/oam/server/logout?end_url=http://my
.site.com/welcome.html

- end_urlパラメータがホストとポートを持つURLである場合、logout.htmlスクリプトは、URLを作成しなおすことなくそのURLをそのまま渡します。

注意:
ADFアプリケーションは、「Oracle ADFコード・アプリケーションの集中ログアウト構成」に示すように、ログアウト後にユーザーをどこへリダイレクトするかを示すend_urlパラメータを渡す必要があります。

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

logout.html内のログアウト・リンク指定方法を表15-3に示します。

表15-3 end_urlパラメータ指定の例

内容

end_urlの値の例

URI

/oamsso/logout.html?end_url=<someUri>

例:

/oamsso/logout.html?end_url=/welcome.html

URL

/oamsso/logout.html?end_url=<someUrl>

例:

/oamsso/logout.html?end_url=http://my.site.com/welcome.html

OAM 11g使用時の10g Webgateの集中ログアウト構成

次の手順では、OAM 11g使用時の10g Webgateの集中ログアウト構成方法を示します。

注意:
オプションのタスクや、マルチDNSドメインのログアウトのみに必要なタスクは識別されているので、必要な場合以外はスキップできます。

第27章「OAM 11g使用時のOAM 10g Webgateの管理」には、WebLogic Serverドメイン内にアプリケーションをデプロイするためのステップを含む、簡単な手順が示されています。

タスクの概要: 10g Webgateの集中ログアウトの構成

1. デフォルトのログアウト・ページ(logout.html)を作成し、Webgateインストール・ディレクトリ上でそのページを使用できるようにします。

1. 例15-1「logout.htmlスクリプト」に基づき、Webgate用のlogout.htmlを作成および編集します。

2. 作成または編集したlogout.htmlスクリプトを次のディレクトリ・パスに保存します。

Webgate_install_dir/oamsso/logout.html

注意:
logout.htmlを他の場所に置く場合は、エージェント登録時にログアウト・リンクを正しく指定してlogout.htmlファイルの正しい場所を参照するようにしてください。

3. 必要に応じて次のステップを実行します。

2. 次のように、それぞれのリソースWebgateに対してLogOutUrlパラメータが構成されていることを確認します。

注意:
LogOutUrlパラメータがすでに「/oamsso/logout.html」以外の値によって10g Webgate用に構成されている場合は、「/oamsso/logout.html」もLogOutUrlパラメータの一部として存在することを確認します。

1. <callBackUri>が「logOutUrls」の一部として2つ目の値になっていることを確認します。

2. 2つの値がカンマで区切られていることを確認します: "/oamsso/logout.html, <CallbackUri>"

3. logout.html(ステップ1)が、この集中ログアウトURI(OAM 11gサーバーの/oam/server/logout)へユーザーをリダイレクトすることを確認します。

4. オプション: 「logout.html内のend_urlパラメータのガイドライン」に示すように、アプリケーションが、ログアウト後にユーザーがリダイレクトされる場所を示すend_urlパラメータを渡せるようにします。

5. マルチDNSドメイン: SSO用に構成されたマルチDNSドメインがある場合は、次のステップを実行します。

注意:
ログアウト・コールバックURLは各Webgateに固有のものにできますが、各Webgateに対してコールバックURLを作成するには、OAMサーバーに対して各ドメインの各Webgateのホストとポートを指定するだけで十分です。ログアウト・コールバックURLが参照するファイルは、Webgateのインストール・ディレクトリにあるlogout.htmlスクリプトとは異なるものであることが必要です。

1. <CallbackUri>を、各リソースWebgate上のlogOutUrlsパラメータの2つ目の値として構成します。
<CallbackUri>は、ドメイン内のobssocookieを消去するためのリクエストを送る必要があるWebgate上の場所です。<CallbackUri>をlogout.htmlとすることはできません。

2. ファイルが、<CallbackUri>で示される場所(通常はlogout.htmlと同じ場所)にある各Webサーバー上に物理的に存在することを確認します。
たとえば、logout.htmlと同じ場所にlogout.pngという名前のファイルを構成する場合、logout.pngの<CallbackUri>の値は次のようにする必要があります。

/oamsso/logout.png

6. 10g Webgateを構成したOHS Webサーバー構成ファイルhttpd.confを確認し、次の行が存在する場合には削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

Oracle ADFコード・アプリケーションの集中ログアウト構成

Oracle Access Manager SSOソリューションは、Oracle ADF標準およびOPSS SSOフレームワークに従ってコーディングされたアプリケーションに使用できます。OAM 11gでログアウトを実行するように構成されたADFコード・アプリケーションは、/oamsso/logout.htmlリソースにリダイレクトします。IAMSuiteAgentはリクエストのインターセプトと処理を行い、セッションをクリーン・アップし、集中ログアウトにリダイレクトして(OAMサーバーにより実行)再びend_urlにリダイレクトします。

関連項目:
Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド

注意:
ADFアプリケーションの場合は、追加的な構成ステップが1つのみ必要です(OPSS用にOAMSSOProviderを構成)。

タスクの概要: OAM 11gによるADFアプリケーションの保護

1. 次のどちらかを使用してADFコード・アプリケーションを保護します。

- 11g Webgate

- 10g Webgate

2. ADFコード・アプリケーション用に追加的な構成ステップを1つ実行します: 「OAM 11g使用時のADFコード・アプリケーションの集中ログアウト構成」の説明に従ってOAMSSOProviderを構成してください。

3. 選択したWebgateのバージョンに合わせてログアウト構成ステップを実行します。

この項には次の項目が含まれていますが、Oracle ADF標準およびOPSS SSOフレームワークに従ってコーディングされたアプリケーションを使用しない場合はスキップできます。

- Oracle ADF標準に従ってコーディングされたアプリケーションの集中ログアウト処理について

- OAM 11g使用時のADFコード・アプリケーションの集中ログアウト構成

Oracle ADF標準に従ってコーディングされたアプリケーションの集中ログアウト処理について

ADFコード・アプリケーションとは、ADFと完全に統合化されたアプリケーション、またはADF認証サーブレットのみを使用してOPSSとの統合化を図るアプリケーションを言います。

この場合、ログアウトは、ADFアプリケーションがログアウトURIを呼び出した時に開始されます。次のプロセスは、Oracle ADF標準に従ってコーディングされたアプリケーションのOAM 11g集中ログアウト・プロセスの概要です。

プロセス概要: 10g Webgate使用時のADFアプリケーションの集中ログアウト

1. ADFアプリケーションは次のURIを呼び出します。

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

end_urlパラメータは、ログアウト後にアプリケーションが制御を戻すURIを指定します。

2. ADFは構成済のOPSS SSOプロバイダ(この場合はOAM)を起動し、ログアウトURIにリクエストをリダイレクトすることによって、構成済のログアウトURIにログアウト機能を委任します。end_urlの値は問合せ文字列としてログアウトURIに渡されます。例: /oamsso/logout.html?end_url=<end_uri>

3. ログアウトURIは、アプリケーションのフロントエンド処理を行うWebgateに呼び出されます。

4. 10g Webgateはそのドメイン用のObSSOCookieを削除して、logout.htmlスクリプトをロードします。

5. end_urlパラメータにhost:portが含まれていない場合、logout.htmlスクリプトはローカル・サーバーのhost:portを取得してend_urlパラメータをURLとして構成します。次に例を示します。

http://serverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html

6. logout.html内のロジックがOAMサーバーにリダイレクトします。次に例を示します。

http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html

7. OAMサーバーが次のようにログアウトを実行します。

1. サーバー側のユーザーに関連付けられたセッション情報をクリーン・アップします。

2. end_urlを確認して、コールバックURLを含むページをユーザーのブラウザに送信します。

注意:
表15-2に示すように、ログアウト・コールバックURLは、展開された(短縮されていない)OAMエージェント登録で指定されます。

3. コールバック・ページから、各Webgateの特定URIに対して新しいリクエストが開始されます。このリクエストが特定ドメインの特定Webgateに届くと、そのドメインのObSSOCookieは消去されます。

4. ユーザーは、ログアウト・スクリプト内のend_urlにリダイレクトされます。ただし、end_urlパラメータがない場合はOAMサーバーによって適切なメッセージが送信されます。

OAM 11g使用時のADFコード・アプリケーションの集中ログアウト構成

次の手順は10g Webgateのログアウト構成と同様ですが、ADFコード・アプリケーション用のステップが含まれています。ADFコード・アプリケーションでは、ログアウト処理後にユーザーをどこへリダイレクトするかを明らかにするためにend_urlの値を送らなければなりません。ただしADFコード・アプリケーションでは、アプリケーションが次のURIを呼び出した時にログアウトが行われます。

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

注意:
Applcore f/wは前述のURLのトリガーを容易にでき、ADFアプリケーションはこれを利用することができます。

この手順の一部のステップにはWebLogic Scripting Tool(WLST)が必要で(Linuxではwlst.sh、Windowsではwlst.cmd)、これはWLST_install_dirから呼び出す必要があります。

関連項目:

- 付録C、「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合化」

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスのカスタムWLSTコマンドの使用に関する項

ADFコード・アプリケーションの集中ログアウト構成方法

1. 管理者にエージェントで構成されたlogout.htmlスクリプトの場所を確認します。それには、次の手順を実行する必要があります。

2. 次のように、OAM用のOPSSをSSOプロバイダとして構成し、WebLogic管理ドメインのjps-config.xmlを更新します。

1. Oracle ADFセキュリティを使用してOracle WebLogic ServerとWebアプリケーションをホストしているコンピュータ上で、Oracle JRF WLSTスクリプトの場所を確認します。次に例を示します。

cd $ORACLE_HOME/oracle_common/common/bin

2. Oracle WebLogic Serverをホストしているコンピュータに接続し、管理者IDとパスワード、およびWebLogic AdminServerのホストとポートを入力します。

wls:/> /connect('admin_ID', 'admin_pw', 'hostname:port'

たとえば、Oracle WebLogic Administration Serverホストは、ポート7001を使用するlocalhostとすることができます。ただし、実際に使用している環境では異なることもあります。

3. 管理者にエージェントで構成されたlogout.htmlスクリプトの場所を確認します。
ステップdでは、管理者の提供する値を使用する必要があります。ここで、logouturiの値はログアウト・スクリプト/logout.htmlのURIです。この値は「logout」で始めるか(logout.gifとlogout.jpgは例外)、管理者が構成した別の値にすることもできます。

4. ADF認証用のloginuriとlogouturiを入力します(エージェントによって構成されたlogout.htmlスクリプトの場所)。ホストとポートは必要ありません。

wls:/>addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")

ここで、loginuri=/${app.context}/adfAuthentication、logouturivalはログアウト・スクリプト/logout.htmlのURIです。logouturlは「logout」で始めるか(logout.gifとlogout.jpgは例外)、管理者が構成した別の値にすることもできます。

3. 必須: 次に示すように、ADFアプリケーションは、ログアウト後にユーザーをどこへリダイレクトするかを示すend_urlパラメータを渡さなければなりません。
end_urlパラメータにhost:portが含まれていない場合、logout.htmlスクリプトはローカル・サーバーのhost:portを取得してend_urlパラメータをURLとして構成します。次に例を示します。

http://serverhost:port/oam/server/logout?end_url=http://serverhost:port/
welcome.html

4. OAM 11g Webgate: 「11g Webgateの集中ログアウト構成」の手順を実行します。

5. OAM 10g Webgate: 「OAM 11g使用時の10g Webgateの集中ログアウト構成」の手順を実行します。

関連項目:
Oracle Access Manager 11gのIDアサーションのプロバイダ設定の詳細は、「シナリオ: OAMトークンを使用したアイデンティティ伝播」

ログアウト時のカスタムmod_osso Cookieの削除

ユーザーのログアウト時、認証レスポンス設定によってOAMサーバーで設定されたカスタムCookieの一部が削除されない場合があります。ただし、oam-config.xmlを編集して、ユーザーがOAMからログアウトするときに、認証中に設定されたカスタムCookieを削除するようにOAMサーバーを構成できます。たとえば、Oracle E-Business Suiteと統合している場合、アプリケーションでORASSO_AUTH_HINT Cookieが設定され、CookieNamesリストに含まれている必要があります(UCM Cookieなど)。

構文(PluginClass" Type=...)の下:

<Setting Name="CookieDelMap" Type="htf:map">
<Setting Name="CookieNames" Type="xsd:string">COOKIE_NAME</Setting>
</Setting>

次の手順に従ってCookieDelMap要素を編集し、ユーザーのログアウト時に削除するCookieNamesを単独の値として、またはカスタムCookieのカンマ区切りリストとして追加します。この手順では、oam-config.xmlファイル・バージョンを増分して、変更をすべての管理対象サーバーに再起動なしで伝播する方法も説明しています。

注意:
作業は慎重に行ってください。通常、oam-config.xmlファイルは編集しないことをお薦めしています。これは数少ない例外です。

ログアウト時にカスタムmod_osso Cookieを削除する手順

1. DOMAIN_HOME/config/fmwconfig/oam-config.xmlをバックアップします。

2. oam-config.xmlで、CookieDelMap要素およびCookieNamesを追加(または編集)します。次に例を示します。

<Setting Name="ResponsePluginSetting" Type="htf:map">
<Setting Name="PluginClass" Type=... </Settings>
<Setting Name="CookieDelMap" Type="htf:map">
<Setting Name="CookieNames" Type="xsd:string">ORASSO_AUTH_HINT
</Setting>
</Setting>
</Setting>

3. 構成バージョン: 次に示すように、Version xsd:integerをこの例の最終行の値まで増分します(既存の値(ここでは25) + 1)。
次に例を示します。

<Setting Name="Version" Type="xsd:integer">
<Setting xmlns="http://www.w3.org/2001/XMLSchema"
Name="NGAMConfiguration" Type="htf:map:>
<Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
<Setting Name="Version" Type="xsd:integer">25</Setting>
</Setting>

4. ファイルを保存します。

グローバル・サインオンと集中ログアウトの検証

この項の内容は次のとおりです。

- グローバル・サインオンの確認

- 様々なエージェント・タイプを使用したグローバル・サインオンの検証

- 集中ログアウトの監視

グローバル・サインオンの確認

シングル・サインオンによるグローバル・ログインの監視には次の手順を使用します。

前提条件

- エージェントとサーバーがOAM 11gによって登録され、実行されていなければなりません。

- OAM 11gアプリケーション・ドメイン内で、SSOを制御するリソースとポリシーを定義しなければなりません。

グローバル・サインオンの監視方法

1. 保護されたリソースのURLをブラウザに入力し、正しい資格証明を使用してサインインします。

2. 他の保護リソースのURLを入力して、再認証を求められないことを確認します。

様々なエージェント・タイプを使用したグローバル・サインオンの検証

次の手順を使用して、同じ認証レベルを持つ様々なアプリケーションとエージェントによるシングル・サインオンによるグローバル・ログインを監視します。

たとえば、次の場所に次のパートナがあるものとします。

- OSSOパートナ、http://host1.example.com:7777/private/index.html、mod_ossoを使用して保護

- Webgateパートナ、http://host2.example.com:8888/mydomain/finance/index.html、OAMエージェントを使用して保護

同じブラウザ・セッション内で、1回のサインインにより、どちらかのエージェントによって保護されたすべてのアプリケーションにアクセスできます。

前提条件

- エージェントとサーバーがOAM 11gによって登録され、実行されていなければなりません。

- OAM 11gアプリケーション・ドメイン内でリソースとポリシーを定義しなければなりません。

- どちらのパートナも、同じ認証レベルで保護されていなければなりません。

- この章の説明に従ってシングル・サインオンが構成されていなければなりません。

様々なエージェント・タイプによるグローバル・サインオンの監視方法

1. OSSOエージェントに保護されたアプリケーション:

1. ブラウザから、OSSOで保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 保護されたリソースを使用できることを確認します。

4. 同じブラウザ・セッションを維持して、ステップ2に進みます。

2. 同じブラウザ・セッション、OAMエージェントに保護されたアプリケーション:

1. ステップ1と同じブラウザ・セッションで、OAMエージェントに保護されたリソースのURLを入力します。

2. 保護されたリソースを使用できることと、ログイン・ページが表示されないことを確認します。

3. ブラウザ・セッションをログアウトします。

4. 新しいブラウザ・セッション、OAMエージェントに保護されたアプリケーション:

1. 新しいブラウザ・セッションで、OAMに保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 保護されたリソースを使用できることを確認します。

4. 同じブラウザ・セッションを維持して、ステップ5に進みます。

5. 同じブラウザ・セッション、OSSOエージェントに保護されたアプリケーション:

1. ステップ4と同じブラウザ・セッションで、OSSOエージェントに保護されたリソースのURLを入力します。

2. 保護されたリソースを使用できることと、ログイン・ページが表示されないことを確認します。

集中ログアウトの監視

次の手順を使用して集中ログアウトを監視します。

- OAMエージェントの場合はログアウトURLがサーバーへのリダイレクトを行い、その後の要求によってCookieが特定されないようにCookieが消去されて無効化されます。

- mod_ossoの場合は、各エージェントがそのCookieを破棄します。ログアウトURLがサーバー上のグローバル・ログアウト・ページへのリダイレクトを行い、各パートナがそのサーバーにCookieを送ります。

前提条件

- エージェントが登録されて実行されていなければなりません。

- リソースはOAM 11gアプリケーション・ドメインによって保護されていなければなりません。

- シングル・サインオンは、OAM 11gアプリケーション・ドメイン内で、認証と認可のためのポリシーと応答によって構成されていなければなりません。

集中ログアウトの監視方法

1. 1つのアプリケーション:

1. ブラウザから、保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 保護されたリソースを使用できることを確認します。

4. 新しいブラウザ・タブまたはウィンドウを開いて同じリソースにアクセスし、2回目のアクセス時に新たなログインが要求されないことを確認します。

5. 1つのタブからログアウトします。

6. もう一度そのリソースにアクセスして、ログイン・ページが表示されることを確認します。

2. 2つのアプリケーション:

1. ブラウザから、保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 新しいタブまたはウィンドウで、別の保護されたアプリケーションにアクセスし、2つ目のアプリケーションで新たなログインを要求されないことを確認します。

4. 1つ目のアプリケーションからログアウトします。

5. 2つ目のアプリケーションにアクセスして、ログイン・ページが表示されることを確認します。

第V部

Oracle Security Token Service

この項では、管理者がOracle Access Managerで使用できるOracle Security Token Servicesを管理する際に役に立つ情報を提供します。

第V部の内容は次のとおりです。

- 第16章「Oracle Security Token Serviceの実装シナリオ」

- 第17章「Oracle Security Token Serviceの設定値と設定の管理」

- 第18章「Oracle Security Token Serviceの証明書と鍵の管理」

- 第19章「テンプレート、エンドポイントおよびポリシーの管理」

- 第20章「Token Serviceパートナとパートナ・プロファイルの管理」

- 第21章「Oracle Security Token Serviceのトラブルシューティング」

16 Oracle Security Token Serviceの実装シナリオ

この章では、Oracle Security Token Serviceの実装シナリオおよび処理シナリオをいくつか示します。シナリオの詳細に関係なく、構成タスクとトークン処理の両方に多数の類似点があります。この章の内容は次のとおりです。

- 前提条件

- 一般的なトークン・エコシステム

- シナリオ: OAMトークンを使用したアイデンティティ伝播

- シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

前提条件

「Oracle Security Token Serviceの概要」

一般的なトークン・エコシステム

ここで取り上げる抽象モデルは、このようなモデルをサポートするためにOracle Security Token Serviceに設定されている要件を示すために役立ちます。

ここでは、セキュリティ・トークン・エコシステムという語句を使用して、セキュリティ・トークンが使用される一般的な環境を表します。このような環境では、環境に必要なセキュリティ・モデルに基づいて、セキュリティ・トークンを使用してブローカ・トラストやシングル・サインオンなどの最終目標を達成できます。ここに示すように、環境およびセキュリティ・トークンのタイプに関係なく、いくつかの側面はすべてのモデルに共通しています。

図16-1に、トークン発行局、トークン・リクエスタ、トークン・コンシューマ、セキュリティ・トークンなどを含む一般的なトークン・エコシステムを示します。

図16-1 一般的なトークン・エコシステム

「図16-1 一般的なトークン・エコシステム」の説明

アクターとプロセスの概要: 一般的なトークン・エコシステム

1. トークン・リクエスタは、トークン発行局にセキュリティ・トークンをリクエストします。
このセキュリティ・トークンは、サービス・プロバイダ(セキュリティ・トークンを受け入れるトークン・コンシューマ)が提供するサービスと通信し、サービスへのアクセスをリクエストする必要があります。

- トークン・リクエスタは、トークン発行局のパートナである可能性があります(通常はトークン発行局に登録されます)。

- トークン・リクエスタは、エンド・ユーザーである可能性があります(通常はトークン発行局には登録されません)。

2. トークン発行局(OAM、OSTSなど)は、次のようにセキュリティ・トークン・リクエストを受信および処理し、セキュリティ・トークンを返します。

- 入力資格証明を認証します。

- 特定のトークン・コンシューマのセキュリティ・トークンのリクエストを認可されているトークン・リクエスタを指定するトークン発行ポリシーに基づいて、セキュリティ・トークン・リクエストを認可します。

3. トークン・コンシューマ(通常はサービス・プロバイダ)。

- セキュリティ・トークンをサービス・リクエストの一部として受け入れ、入力セキュリティ・トークンの有効性に基づいてサービスを提供します。

- トークン発行局を使用して入力セキュリティ・トークンを検証します。

注意:
トークン・コンシューマは通常、トークン発行局の登録済パートナです。トークン・コンシューマはリライイング・パーティとも呼ばれます。これは、トークン・リクエスタ認証のためにトークン発行局を信頼し、依存しているためです。トークン・コンシューマ(リライイング・パーティ・パートナ)は、Webアプリケーション(OAMの場合、OSTSがトークン発行局)またはSTSリライイング・パーティWebサービスです。

シナリオ: OAMトークンを使用したアイデンティティ伝播

これは、ユーザーのアイデンティティ情報をWebアプリケーションからWebサービス・プロバイダに伝播する必要があるデプロイメントです。Webサービス・プロバイダは、Webアプリケーションと同じセキュリティ・ドメインに存在することも、別のセキュリティ・ドメインに存在することもできます。

図16-2 OAMトークンを使用したアイデンティティ伝播

「図16-2 OAMトークンを使用したアイデンティティ伝播」の説明

アイデンティティ伝播とは、元のユーザー・コンテキストを元のセキュリティ層またはドメイン境界の外側で表示できるようになることです。ユーザー・セキュリティ・コンテキストは、ステップアップ認証、認可、監査/内部アプリケーション固有のビジネス・ロジックなど、層またはドメイン固有のセキュリティ・ニーズをサポートするために、異なるセキュリティ層またはドメインに伝播されます。

ID伝播は、最初のノードで確立されたアイデンティティ・コンテキストを後続のノードに伝播するときに、そのアイデンティティのコンテキストでリクエストをさらに処理できるようにするために、リクエストの分散処理で発生すると言われています。

ID伝播は複数の方法で実行できます。IDプロバイダがIDアサーションのトラスト・ブローカとして機能する、ブローカ・トラスト・モデルに基づく方法があります。ここで説明する内容は、このモデルに関連しています。

図16-3に、ブローカ・トラスト・モデルのID伝播シナリオを示します。このシナリオでは、ユーザー向けアプリケーションがエンド・ユーザーのコンテキストでバックエンド・サービス・アプリケーションによる処理を要求する必要があります。ID伝播の主な側面を明らかにするために、エンド・ユーザー、アプリケーションおよびバックエンド・サービス・アプリケーション間の他のすべての相互作用および関係の詳細は無視されます。

図16-3 アイデンティティ伝播中のプロセス・フロー

「図16-3 アイデンティティ伝播中のプロセス・フロー」の説明

アクターとプロセスの概要: アイデンティティ伝播

1. IDアサーション・トークン・リクエスタ(エンド・ユーザー向けアプリケーション)は、エンド・ユーザーへのアクセス時に、アイデンティティ・プロバイダの認証およびIDアサーション・トークンをリクエストします。

注意:
IDアサーション・トークン・リクエスタの例には、OAMで保護されるWebアプリケーションがあります。IDアサーション・トークン・リクエストは、暗黙的な場合もあれば、IDプロバイダのポリシーから導かれる場合もあります。

2. IDプロバイダ(Oracle Security Token Service)はリクエストを処理し、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

3. IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

4. IDアサーション・トークン・コンシューマ(Oracle Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

詳細は、次のトピックを参照してください。

- コンポーネント処理: OAMトークンを使用したアイデンティティ伝播

- RST属性とランタイム処理

- 構成要件: OAMトークンを使用したアイデンティティ伝播

コンポーネント処理: OAMトークンを使用したアイデンティティ伝播

図16-4に、Oracle Security Token ServiceとOracle Access Managerを使用したアイデンティティ伝播の一般的なデプロイメント・トポロジを示します。

図16-4 アイデンティティ伝播のデプロイメント

「図16-4 アイデンティティ伝播のデプロイメント」の説明

図16-5に、Oracle Security Token ServiceとOracle Access Managerを使用したアイデンティティ伝播の処理を示します。詳細は、図の後に説明します。

図16-5 アイデンティティ伝播処理

「図16-5 アイデンティティ伝播処理」の説明

プロセスの概要: アイデンティティ伝播のコンポーネント相互作用

1. ユーザーが保護されたリソースにアクセスを試みます。

2. Webgateはリソースを保護しており、認証および認可のためにOracle Access Managerにリクエストを送信します。

3. Oracle Access Managerでは、このWebgateアプリケーション・ドメイン用に構成されたポリシーを使用してユーザーが認証されます。レスポンス・タイプ「IDENTITY_ASSERTION」がこのWebgate用に構成されていることを確認し、IDアサーション・トークンも生成します。

4. Oracle Access ManagerはWebgateに認証およびIDアサーションを送信します。

5. Webgateでは、レスポンスを処理し、IDアサーション・トークンをヘッダー(WebgateがインストールされているOHS)に設定した後、リソースをホストするWLSにリクエストをリダイレクトします。

6. IAP (WebLogic Server上のOracle Access Manager Identity Asserter)では、OAM_IDENTITY_ASSERTIONヘッダーが設定されていることを確認し、ヘッダーを処理した後、IDアサーション・トークンをサブジェクトのプライベートな資格証明(OamIdentity)に設定します。

7. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザーのサブジェクトからIDアサーション・トークンを取得し、そのIDアサーション・トークンを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してOSTSに送信します。

8. Oracle Security Token ServiceではOBOトークン内のIDアサーション・トークンを確認し、Oracle Access Managerライブラリを使用してOracle Access Managerに検証/認証リクエストを送信します。

9. Oracle Access ManagerではIDアサーション・トークンを検証および認証した後、Oracle Security Token Serviceにレスポンス(ユーザー・アイデンティティ)を送信します。

10. Oracle Security Token Serviceではこのユーザー・アイデンティティを使用して、ポリシー評価、トークン発行などの処理がさらに行われます。その後、リクエスト・セキュリティ・トークン・レスポンスが生成されます。

11. Oracle Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

RST属性とランタイム処理

次の属性を持つ着信リクエスト・セキュリティ・トークン(RST)の場合、リクエストを処理し、トークンを発行するようにOracle Security Token Serviceを構成する必要があります。

OAMトークンを使用したアイデンティティ伝播のRST属性

- SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。

- SOAP本体にはWS-Trust RSTメッセージが含まれています。

- RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにOAM ID伝播トークンが含まれています。OnBelahfOf要素に含まれるトークンはBinarySecrityTokenで、テキスト値はOAMセッション伝播トークンのBase 64エンコード・フォーマット、ValueType属性はhttp://xmlns.oracle.com/am/2010/11/token/session-propagation、EncodingType属性はhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-security-1.0#Base64Binaryです。

- RSTには、リライイング・パーティWebサービスのエンドポイントを示すURLを保持するAppliesToフィールドが含まれている可能性があります。

- RSTには、返す必要があるトークンのタイプを保持するTokenTypeフィールドが含まれている可能性があります。

- RSTには、SAMLアサーションに対称証明鍵が必要な場合にSecretKeyを作成するときに使用されるランダム・データを保持するEntropyフィールドが含まれている可能性があります。

- RSTには、SAMLアサーションの非対称証明鍵として使用される証明書または公開鍵を保持するUseKeyフィールドが含まれている可能性がありますが、このフィールドはOSTSでは無視されます。

プロセスの概要: OAMトークンを使用したアイデンティティ伝播

1. クライアントは次の方法でリクエストを準備します。

1. SOAPメッセージを作成します。

2. クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

3. WS-Trust RSTメッセージを作成します。

4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

5. SOAP本体にRSTメッセージを含めます。

2. クライアントはOSTS、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをOSTS WSS検証テンプレートにマップします。

3. OSTSでは着信リクエストが処理されます。

4. OSTSは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

1. ユーザー名トークンのフォーマットを検証します。

2. ユーザー名トークンに含まれる資格証明とOSTSパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

3. リクエスタ・パートナを確認した後、OSTSはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

5. OSTSでは、OnBehalfOfフィールドに存在するトークンが検証されます。

1. OnBehalfOfフィールドに存在するトークンのタイプを判断します。

2. OAMトークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

3. OAMトークンのフォーマットおよびOAMトークンを検証し、トークンをユーザーにマップします。

4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

6. OSTSではAppliesToフィールドが検査されます。

- 存在する場合、OSTSはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、OSTSはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、OSTSはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

- 存在しない場合、OSTSはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

7. OSTSではTokenTypeフィールドが検査されます。

- 存在する場合、OSTSはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

- 存在しない場合、OSTSはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

8. OSTSでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

9. OSTSではトークンが作成されます。

- 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

- 発行されるトークンがSAMLタイプの場合、OSTSサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

10. OSTSでは、クライアントが処理するレスポンスが作成されます。

1. WS-Trust RSTRCを作成します。

2. 返されたトークンを追加します。

3. 必要に応じて証明鍵を追加します。

構成要件: OAMトークンを使用したアイデンティティ伝播

このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。

- 構成の概要: OAMトークンを使用したアイデンティティ伝播

- WebLogic Server Identity Assertion Provider

- Oracle Access Manager Identity Asserterの詳細

- LDAP認証プロバイダの詳細

- デフォルト・アイデンティティ・ストアの構成

- トークン発行ポリシー

- Webgateによるアイデンティティ・アサーションの認証ポリシー

- エンドポイントの構成

- 発行テンプレートの構成

- パートナ構成: リクエスタ

- パートナ・プロファイル: リライイング・パーティ

- パートナ・プロファイル: リクエスタ

- WS-TRUSTの検証テンプレート

- Cookieおよびヘッダー(切捨て)

- クライアントによって送信されるリクエスタ・セキュリティ・トークン(切捨て)

- OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)

構成の概要: OAMトークンを使用したアイデンティティ伝播

アイデンティティ伝播の環境と実装タスクの概要を次に示します。

- クライアントとして機能するカスタム・アプリケーション・モジュールでは、次の処理が行われます。

- HTTPリクエストからのOAMセッション伝播トークンの取得

- Oracle Security Token ServiceサーバーへのWS-Trustリクエストの送信(OAMセッション伝播トークンをOnBehalfOf要素として使用)

- Webgateで保護され、WS-TrustリクエストをOracle Security Token Serviceに送信するクライアントWebアプリケーションを起動するWebアプリケーション

- OSTSサーバーのURL: http://yourhost.domain.com:14100/sts/<endpoint>

注意:
<endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

- Webアプリケーションを保護するWebgateを備えたOHS 11g
WebLogic Serverにデプロイされたアプリケーションを保護するために、Webgate (11gまたは10g)をプロビジョニング(登録)します。OAMSuiteアプリケーション・ドメインは事前に送信され、OAM 11gとともに配布されます。このアプリケーション・ドメイン(または別の既存のアプリケーション・ドメイン)を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。

OHSサーバーmod_wl_ohs.conf内のWebgateのリバース・プロキシ・マッピングを次に示します。

アイデンティティ伝播のトークン処理を実装するには、次のOracle Security Token Service構成が必要です。

- 1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

- 1つの発行テンプレート

- 1つのWS-Trust検証テンプレート

- OSTSエンドポイント

- ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Oracle Security Token ServiceにはLDAPサーバーが必要です。
目的のLDAPサーバーが、Oracle Security Token Serviceを備えたOracle Access Managerのデフォルト・アイデンティティ・ストアとして構成されていることを確認します。

WebLogic Server Identity Assertion Provider

アイデンティティ・アサーション・プロバイダjarをデプロイします。Oracle Access Manager Identity Asserterは、Oracle Fusion Middlewareがインストールされている次のパスで使用できます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovider.war

oamauthenticationprovider.warを次の場所にコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

図16-6に、このシナリオに必要なWebLogic Server Identity Assertion Providerを示します。

図16-6 必要なv1.0 WebLogic Server Identity Assertion Provider

「図16-6 必要なv1.0 WebLogic Server Identity Assertion Provider」の説明

Oracle Access Manager Identity Asserterの詳細

IAP-OSTSアイデンティティ・アサータを最初に設定してから、REQUIRED Controlフラグを使用して設定する必要があります。OAM_REMOTE_USER1のSSOヘッダー名を使用して、「Active Types」をObSSOCookieおよびOAM_REMOTE_USERとして設定する必要があります。

図16-7に構成を示します。

図16-7 IAP-OSTSの詳細

「図16-7 IAP-OSTSの詳細」の説明

LDAP認証プロバイダの詳細

OPTIONAL JAASフラグを使用してLDAPのオーセンティケータを作成します。これは、OAMトークンを提供するOracle Access Managerのデフォルト・システム・ストアを指します。

図16-8では、これを説明しています。

図16-8 LDAPプロバイダ: IAP-DSEE

「図16-8 LDAPプロバイダ: IAP-DSEE」の説明

デフォルト・アイデンティティ・ストアの構成

図16-9に、Oracle Access Managerコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。

図16-9 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア

「図16-9 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア」の説明

トークン発行ポリシー

図16-10に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

図16-10 アイデンティティ伝播のトークン発行ポリシー

「図16-10 アイデンティティ伝播のトークン発行ポリシー」の説明

Webgateによるアイデンティティ・アサーションの認証ポリシー

IAM Suiteアプリケーション・ドメイン内の認証ポリシーで「IDアサーション」ボックスが選択されていることを確認します。これにより、図16-10に示すように、Webgateは保護されたリソースのアイデンティティ・アサーションを実行できます。

図16-11 Webgateによるアイデンティティ・アサーションの認証ポリシー

「図16-11 Webgateによるアイデンティティ・アサーションの認証ポリシー」の説明

エンドポイントの構成

図16-12に示すように、/wss10userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。

図16-12 アイデンティティ・アサーションの/wssuserエンドポイント

「図16-12 アイデンティティ・アサーションの/wssuserエンドポイント」の説明

発行テンプレートの構成

発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。

- 名前: iap-issuance-template

- 説明: カスタム発行テンプレート

- トークン・タイプ: SAML 2.0

- 署名鍵ID: osts_signing

- 説明: カスタム発行テンプレート

パートナ構成: リクエスタ

次のように、OAMトークンを使用してアイデンティティ伝播用の新しいリクエスタ・パートナ構成を作成します。

- パートナ名: iap-request-partner

- リクエスタ・タイプ: STS_REQUESTER

- パートナ・プロファイル: iap-requestor-profile

- 説明: カスタム・リクエスタ

- 信頼

- ユーザー名トークン認証

- ユーザー名 <Webサービス・クライアントで使用されるユーザー名を入力>

- パスワード <Webサービス・クライアントで使用されるパスワードを入力>

- パスワードの確認 <Webサービス・クライアントで使用されるパスワードを入力>

- アイデンティティ属性の値:

- httpbasicusername

- sslclientcertdn

パートナ・プロファイル: リライイング・パーティ

次のように、アイデンティティ伝播の新しいリライイング・パーティ・プロファイルを作成します。

- プロファイルID: iap-relyingparty-profile

- 説明: iap-issuance-template

- デフォルト・トークン・タイプ: SAML 2.0

- デフォルト・テンプレート: iap-issuance-template

パートナ・プロファイル: リクエスタ

次のように、アイデンティティ伝播の新しいリクエスタ・プロファイルを作成します。

- プロファイルID: iap-requestor-profile

- 説明: iap-requestor-profileパートナ・プロファイル

- デフォルト・リライイング・パーティ・プロファイル: iap-relyingparty-profile

WS-TRUSTの検証テンプレート

検証テンプレートには、アイデンティティ伝播用の次の構成が必要です。

- 検証テンプレート名: iap_wstrust_validation_template

- 説明: iap_wstrust_validation_template

- トークン・プロトコル: WS-Trust

- トークン・タイプ: OAM

- タイムスタンプの存続期間:

これで、OAMトークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

実装のテスト

構成の完了後、リソースにアクセスし、実装が正しく動作していることを確認できます。

Webgateでは、認証の成功時にユーザーの既存のセッションがない場合、OAM Serverにリダイレクトする必要があり、ユーザーはSTSサーバーによって送信されるRSTおよびRSTRを表示できることが必要です。

Cookieおよびヘッダー(切捨て)

クライアントによって送信されるリクエスト・セキュリティ・トークン(切捨て)

クライアントによって送信されるセキュリティ・トークンの(切り捨てられた)リクエストを次に示します。

OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)

OSTSサーバーによって送信されるRSTへの(切り捨てられた)レスポンスを次に示します。

シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

ここでは、次の内容について説明します。

- ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

- ユーザー名トークンを使用したアイデンティティ伝播のRST属性および処理

- 構成要件: ユーザー名トークンを使用したアイデンティティ伝播

ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

プロセスの概要: アイデンティティ伝播のコンポーネント相互作用

1. ユーザーが保護されたリソースにアクセスを試みます。

2. ユーザーが認証されます。

3. WebLogicコンテナでは、ユーザーのアイデンティティがこのセッションのサブジェクトに設定されます。

4. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザー・サブジェクトからユーザーのアイデンティティを取得し、そのアイデンティティを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してOSTSに送信します。

5. Oracle Security Token Serviceでは、Webサービス・クライアントをリクエスタ・パートナとして認証します。

6. Oracle Security Token ServiceではOBOトークン内にユーザー名トークンが表示され、ユーザーのアイデンティティがLDAP内のユーザー・レコードにマップされます。

7. その後、Oracle Security Token Serviceではリクエスト・セキュリティ・トークン・レスポンスが生成されます。

8. Oracle Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

ユーザー名トークンを使用したアイデンティティ伝播のRST属性および処理

次の属性を持つ着信リクエスト・セキュリティ・トークン(RST)の場合、リクエストを処理し、トークンを発行するようにOracle Security Token Serviceを構成する必要があります。

ユーザー名トークンを使用したアイデンティティ伝播のRST属性

- SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。

- SOAP本体にはWS-Trust RSTメッセージが含まれています。

- RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにユーザー名トークンが含まれています。

- RSTには、リライイング・パーティWebサービスのエンドポイントを示すURLを保持するAppliesToフィールドが含まれている可能性があります。

- RSTには、返す必要があるトークンのタイプを保持するTokenTypeフィールドが含まれている可能性があります。

- RSTには、SAMLアサーションに対称証明鍵が必要な場合にSecretKeyを作成するときに使用されるランダム・データを保持するEntropyフィールドが含まれている可能性があります。

- RSTには、SAMLアサーションの非対称証明鍵として使用される証明書または公開鍵を保持するUseKeyフィールドが含まれている可能性がありますが、このフィールドはOracle Security Token Serviceでは無視されます。

プロセスの概要: OAMトークンを使用したアイデンティティ伝播

1. クライアントは次の方法でリクエストを準備します。

- SOAPメッセージを作成します。

- クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

- WS-Trust RSTメッセージを作成します。

- ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むユーザー名トークンを作成します。

- SOAP本体にRSTメッセージを含めます。

2. クライアントはOracle Security Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをOracle Security Token Service WSS検証テンプレートにマップします。

3. Oracle Security Token Serviceでは着信リクエストが処理されます。

4. Oracle Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

- ユーザー名トークンのフォーマットを検証します。

- ユーザー名トークンに含まれる資格証明とOracle Security Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

- リクエスタ・パートナを確認した後、Oracle Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

5. Oracle Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。

- OnBehalfOfフィールドに存在するトークンのタイプを判断します。

- ユーザー名トークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

- ユーザー名トークンを検証し、トークンをユーザーにマップします。

6. Oracle Security Token ServiceではAppliesToフィールドが検査されます。

- 存在する場合、Oracle Security Token Serviceはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、Oracle Security Token Serviceはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、Oracle Security Token Serviceはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

- 存在しない場合、Oracle Security Token Serviceはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

7. Oracle Security Token ServiceではTokenTypeフィールドが検査されます。

- 存在する場合、Oracle Security Token Serviceはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

- 存在しない場合、Oracle Security Token Serviceはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

8. Oracle Security Token Serviceでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

9. Oracle Security Token Serviceではトークンが作成されます。

- 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

- 発行されるトークンがSAMLタイプの場合、Oracle Security Token ServiceサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

10. Oracle Security Token Serviceでは、クライアントが処理するレスポンスが作成されます。

- WS-Trust RSTRCを作成します。

- 返されたトークンを追加します。

- 必要に応じて証明鍵を追加します。

構成要件: ユーザー名トークンを使用したアイデンティティ伝播

このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。

- 構成の概要: ユーザー名トークンを使用したアイデンティティ伝播

- デフォルト・アイデンティティ・ストアの構成

- トークン発行ポリシー

- エンドポイントの構成

- 発行テンプレートの構成

- パートナ構成: リクエスタ

- パートナ・プロファイル: リライイング・パーティ

- パートナ・プロファイル: リクエスタ

- WS-TRUSTの検証テンプレート

- 例16-1、「交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン」

- 例16-2、「OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス」

構成の概要: ユーザー名トークンを使用したアイデンティティ伝播

アイデンティティ伝播の環境と実装タスクの概要を次に示します。

- ユーザーがリクエストするWebアプリケーション。このWebアプリケーションはユーザーを認証した後、リモートWebサービス・プロバイダへのSOAPメッセージの送信を試行します。そのSOAP交換の一部として、WS-SecurityクライアントはWebサービス・プロバイダのWS-Securityポリシーをダウンロードし、Oracle Security Token Serviceに接続してWebサービス・プロバイダがリクエストしたトークンを取得し、Webサービス・プロバイダにSOAPメッセージを含むセキュリティ・トークンを送信します。

- OSTSサーバーのURL: http://yourhost.domain.com:14100/sts/<endpoint>

注意:
<endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

アイデンティティ伝播のトークン処理を実装するには、次のOracle Security Token Service構成が必要です。

- 1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

- 1つの発行テンプレート

- 1つのWS-Trust検証テンプレート

- Oracle Security Token Serviceのエンドポイント

- ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Oracle Security Token ServiceにはLDAPサーバーが必要です。

- 目的のLDAPサーバーが、Oracle Security Token Serviceを備えたOracle Access Managerのデフォルト・アイデンティティ・ストアとして構成されていることを確認します。

デフォルト・アイデンティティ・ストアの構成

図16-13に、Oracle Access Managerコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。

図16-13 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア

「図16-13 Oracle Access Managerに定義されているデフォルト・アイデンティティ・ストア」の説明

トークン発行ポリシー

図16-14に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

図16-14 アイデンティティ伝播のトークン発行ポリシー

「図16-14 アイデンティティ伝播のトークン発行ポリシー」の説明

エンドポイントの構成

図16-15に示すように、/wss11userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。

図16-15 アイデンティティ・アサーションの/wss11userエンドポイント

「図16-15 アイデンティティ・アサーションの/wss11userエンドポイント」の説明

発行テンプレートの構成

発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。

- 名前: saml-issuance-template

- 説明: SAML発行テンプレート

- トークン・タイプ: SAML 2.0

- 署名鍵ID: osts_signing

パートナ構成: リクエスタ

次のように、OAMトークンを使用してアイデンティティ伝播用の新しいリクエスタ・パートナ構成を作成します。

- パートナ名: requester-partner

- パートナ・タイプ: リクエスタ

- パートナ・プロファイル: requester-profile

- 説明: リクエスタ

- 信頼

- ユーザー名トークン認証

- ユーザー名 <Webサービス・クライアントで使用されるユーザー名を入力>

- パスワード <Webサービス・クライアントで使用されるパスワードを入力>

- パスワードの確認 <Webサービス・クライアントで使用されるパスワードを入力>

- アイデンティティ属性の値:

- httpbasicusername

- sslclientcertdn

パートナ・プロファイル: リライイング・パーティ

次のように、アイデンティティ伝播の新しいリライイング・パーティ・プロファイルを作成します。

- プロファイルID: relying-party-profile

- 説明: リライイング・パーティ・プロファイル

- デフォルト・トークン・タイプ: SAML 2.0

- 発行テンプレート: SAML 2.0のiap-issuance-template

パートナ・プロファイル: リクエスタ

次のように、アイデンティティ伝播の新しいリクエスタ・プロファイルを作成します。

- プロファイルID: requester-profile

- 説明: リクエスタ・パートナ・プロファイル

- デフォルト・リライイング・パーティ・プロファイル: relying-party-profile

WS-TRUSTの検証テンプレート

検証テンプレートには、アイデンティティ伝播用の次の構成が必要です。

- 検証テンプレート名: username_wstrust_validation_template

- 説明: ユーザー名WS-Trustテンプレート

- トークン・プロトコル: WS-Trus

- トークン・タイプ: ユーザー名

- タイムスタンプの存続期間: 600

- 資格証明検証の有効化: 選択解除

- トークン・マッピング:

- トークンの宛先ユーザーのマップ: 選択

- 簡易ユーザー・マッピングの有効化: 選択

- データストア属性: uid

これで、ユーザー名トークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

例16-1 交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン

これは、クライアントによって送信されるセキュリティ・トークンのリクエストです。

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
<SOAP-ENV:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken><wsse:Username>requester-test</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcome1</wsse:Password></wsse:UsernameToken></wsse:Security>
<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action></SOAP-ENV:Header>
<SOAP-ENV:Body><wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:OnBehalfOf>
<wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Username>user-alice</wsse:Username>
</wsse:UsernameToken></wst:OnBehalfOf></wst:RequestSecurityToken></SOAP-ENV:Body></SOAP-ENV:Envelope>

例16-2 OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス

これは、OSTSサーバーによって送信されるRSTへのレスポンスです。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
</env:Header><env:Body><wst:RequestSecurityTokenResponseCollection xmlns:ns6="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wst:RequestSecurityTokenResponse><wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:RequestedSecurityToken><saml:Assertion AssertionID="id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-" IssueInstant="2011-04-22T18:48:05Z" Issuer="adc2110618.us.oracle.com" MajorVersion="1" MinorVersion="1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Conditions NotBefore="2011-04-22T18:48:05Z" NotOnOrAfter="2011-04-22T19:48:05Z"/><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user-alice@oracle.com</saml:NameIdentifier><saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation>
</saml:Subject><saml:Attribute AttributeName="sn" AttributeNamespace="urn:oracle:security:fed:attrnamespace"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">user-alice-last</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement><dsig:Signature><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>1GF2ZT9h+gs8sxyO+/yG/N6jxk8=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo>
<dsig:SignatureValue>InZVb5aRM5+KKI1VqXg9HiIgLjKyGm0VkD6sMJ/8SIbFbbxuNm7Mnky5W35p2P0c5bCPRx02uzLEE4KhLkyM2GsLsVaDNkRztGMphQW/Mcg7DprJIEyR2OYMYDOQSipa/k2K98C4zO/RNivo1KvyJsd6a3h6CBHwoO1RKip039w=</dsig:SignatureValue>
<dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIIB/DCCAWWgAwIBAgIBCjANBgkqhkiG9w0BAQQFADAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wHhcNMTEwNDE5MTUxNTI2WhcNMjEwNDE2MTUxNTI2WjAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnSxVc86TGcwewieaueIVG33C3Qouve6HuJxHsoM8cRRkJcmv+0auyvDLJfYAEOfHo5OsF4+za11iNPln9ZFaOjUy/Y8JC0kSVxatgU36RveIrpOJvp978Oa6IlMNUtdFf8q3TrsizspE2hnbLY+0SMofgnAPcJEKPxkd6b0b0ZAgMBAAGjQDA+MAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/BAUDAwfYADAdBgNVHQ4EFgQU47ZqWHgTOmZO67uw4YzsbrRMNOswDQYJKoZIhvcNAQEEBQADgYEAH0QIHaLMN/7hD2VP0SLOCtNdEmY5IqLY1CDW+GpUZZ9e+MCgE/rvr34566D9Q8lvET6T9u+sg3h+hSkb3gE4a4wgShH/V7nfHzx8ZntlxccvCZK6ePVDMt0Lfj2iVnE7IJxou4bO0w0m9DrvyKop7ncnSEzaVpxIZgCDo7+8Zdw=</dsig:X509Certificate>
</dsig:X509Data></dsig:KeyInfo></dsig:Signature></saml:Assertion></wst:RequestedSecurityToken><wst:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedAttachedReference>
<wst:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedUnattachedReference>
<wst:Lifetime><wsu:Created>2011-04-22T18:48:05Z</wsu:Created><wsu:Expires>2011-04-22T19:48:05Z</wsu:Expires></wst:Lifetime></wst:RequestSecurityTokenResponse></wst:RequestSecurityTokenResponseCollection></env:Body></env:Envelope>

17 Oracle Security Token Serviceの設定値と設定の管理

この章では、Oracle Security Token Serviceエンドポイントの保護に含まれるコンポーネントを管理する方法について説明します。この章は、次の項目で構成されています。

- 前提条件

- Oracle Security Token Service構成の概要

- Oracle Security Token Serviceの有効化および無効化

- Oracle Access Managerコンソールを使用したセキュリティ・トークン・サービスの設定の定義

- Oracle WSMエージェントのためのWSSポリシーの使用および管理

- WSSプロトコル通信のためのOWSMの構成

- Oracle Security Token Serviceポリシーの管理および移行

- Oracle Security Token Serviceメッセージのロギングの概要

- Oracle Security Token Serviceの監査の概要

- Oracle Security Token Service管理イベントとランタイム・イベントの監査

前提条件

この項では、この章のタスクの要件を明らかにします。

この章のタスクを開始する前に、次のトピックを確認してください。

- 「Oracle Security Token Serviceの概要」

- 第3章「共通の管理およびナビゲーションの基礎」

- 第6章「共通OAMサーバー登録の管理」

Oracle Security Token Service構成の概要

Oracle Security Token Serviceは、Oracle Access Manager 11gと共存するWebサービスです。Oracle Security Token Serviceは、いくつかのOracle Access Managerコンポーネントを起動して、セキュリティ・トークンを検証および発行します。通常、Webクライアントはユーザー名トークンやX.509トークンのようなセキュリティ・トークンを提供することで、Oracle Security Token Serviceを使用してSAMLなどのアウトバウンド・トークンを要求できます。

Oracle Security Token ServiceはOracle Access Managerコンソールと統合され、統一された一貫性のある管理機能を提供します。Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。

Oracle Security Token Serviceは次のものを提供します。

- トークン:

- 検証トークン: 標準トークン(ユーザー名、X.509、Kerberos、SAML 1.1/2.0)およびカスタム・トークンOnBehalfOfユースケース(統合エンジンを介したOAMセッションID伝播トークンおよびカスタム・トークン)では、OAM sessionID伝播トークンおよびカスタム・トークン(ユーザー名、X.509、SAML 1.1/2.0)とともに次の標準トークンもサポートされています。

- 発行トークン: 統合エンジンを介した標準トークン(ユーザー名、SAML 1.1/2.0)およびカスタム・トークン

- 構成による発行および検証

- 複数の層およびドメインにまたがるアイデンティティ伝播による高度な監査

- 統合された共有プラットフォーム・サービスは、内部サービス(Oracle Access Manager SSO、Federation、Oracle Web Services Manager)および外部サービスと対話します。

ここでは、次の内容について説明します。

- インストール後の構成

- サーバーとOracle Security Token Serviceについて

- Oracle Security Token Serviceクライアントについて

- エージェントとOracle Security Token Serviceについて

関連項目:
『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』

インストール後の構成

インストールおよびサーバーの起動後、OAMサーバー上のOracle Access Managerコンソールにアクセスできます。たとえば、OAMサーバーのURLがhttp://machine:14100/oamの場合、次のものにアクセスできます。

- Oracle Access Managerコンソール: http://machine:7001/oamconsole

- Oracle Security Token Service: http://machine:14100/sts/wss11user?wsdl: デフォルトで使用できる/sts/wss11userエンドポイントのWSDLを表示して、OSTSが正しくインストールされていることを確認します。
デフォルトではOSTSは無効になっているため、すべてのランタイム機能およびWebサービス・エンドポイントも無効になっています。そのエンドポイントにアクセスするには、Oracle Access Managerコンソールを使用してまずOSTSを有効にする必要があります。その後、エンドポイントにアクセスできるようになります。

インストール後の構成には次の概要に示すタスクが含まれており、詳細が記載されているこのマニュアル内の他の項を参照しています。

タスクの概要: Oracle Security Token Serviceの構成に必要なもの

1. サーバー側の構成: 次のタスクにOracle Access Managerコンソールを使用します。

1. サービス有効化: 「Oracle Security Token Serviceのサービスの有効化および無効化」

2. 設定の構成: 「「セキュリティ・トークン・サービスの設定」の管理」

3. エンドポイント登録: 「エンドポイントの管理」

4. トークン発行テンプレート構成: 「トークン発行テンプレートの管理」

5. トークン検証テンプレート構成: 「トークン検証テンプレートの管理」

6. パートナ・プロファイル作成: 「Token Serviceパートナ・プロファイルの管理」

7. パートナ構成: 「Token Serviceパートナの管理」

8. 特定のリライイング・パーティに対してOSTSを使用してトークンを発行するための認可ルールを定義するトークン発行ポリシー: 「Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理」

2. 次の項の説明に従って、Oracle WSMエージェントとの相互作用を設定します。

1. Oracle WSMエージェントのためのWSSポリシーの使用および管理

2. WSSプロトコル通信のためのOWSMの構成

3. 「Oracle Security Token Serviceメッセージのロギングの概要」の説明に従って、メッセージ・ロギングを設定します。

4. 「Oracle Security Token Service管理イベントとランタイム・イベントの監査」の説明に従って、イベント監査を構成します。

5. ライフサイクル管理の構成

1. 項目1cの説明に従って、Oracle Security Token Serviceトラスト・エンドポイントを登録します。

2. 「Token Serviceパートナの管理」の説明に従って、リクエスタまたはリライイング・パートナをOracle Security Token Serviceに登録します。

3. 第26章「Fusion Middleware Controlを使用したパフォーマンスおよびログの監視」の説明に従って、パフォーマンスを監視します。

サーバーとOracle Security Token Serviceについて

Oracle Access Manager 11gでは、すべてのOracle Security Token ServiceインスタンスはOAMサーバー(管理対象サーバーとも呼ばれる)上にインストールされます。各サーバーをOracle Access Managerに登録する必要があります。

Oracle Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびOracle Access Manager 11g管理モデルが利用されます。

Oracle Security Token ServiceではWeb Services Securityプロトコル1.0および1.1がサポートされており、次のトークン(Security SOAPヘッダーに存在する場合)が処理されます。

- ユーザー名トークン(UNT)

- SAML 1.1またはSAML 2.0アサーション

- Kerberos

- X.509

注意:
第6章「OAMサーバー登録の管理」の説明に従って、Oracle Access Manager with Oracle Security Token Serviceをホストする管理対象サーバーを、Oracle Access Managerに登録する必要があります。

サード・パーティのサーバー: Oracle Security Token Serviceは、サード・パーティのセキュリティ・トークン・サーバーと相互運用できます。たとえば、サード・パーティのセキュリティ・トークン・サービスでは、Oracle Security Token Serviceで使用できる有効なSecurity Assertion Markup Language (SAML)アサーションを作成できます。

Oracle Security Token Serviceクライアントについて

Oracle Security Token Serviceは、様々なOracleクライアント(Oracle Web Services Managerクライアント)またはサード・パーティ・クライアント(MicrosoftおよびIBM)にサービスを提供します。

Oracle WSMクライアント: Oracle Web Services Managerクライアント・バインディングは、Oracle Web Services Managerの担当です(このマニュアルの範囲外)。詳細は、「WSS KerberosポリシーのためのOracle WSMエージェントの構成」を参照してください。

関連項目:
『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のWS-Trustポリシーと構成手順に関する項

サード・パーティ・クライアント: Oracle WSMクライアントとサーバーの間でセキュアなキー交換が必要です。単に、Oracle Security Token Service証明書をクライアントにインポートします。

SOAPの相互作用中に、WS-Securityプロトコルでは、OSTSエンドポイントを保護するOWSMエージェントによるWSS操作に使用される署名/暗号化証明書を信頼することをクライアントに要求する場合があります。その場合、OSTS管理者はWSS操作に使用されるOSTS OWSM署名/暗号化証明書を抽出し、WSクライアントに提供する必要があります。詳細は、「Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出」を参照してください。

エージェントとOracle Security Token Serviceについて

Oracle Web Services Managerはエージェントを介して通信します。このトピックでは、Oracle Security Token Serviceを操作するエージェントについて説明します。

Oracle WSMエージェント: Oracle Web Services Manager (Oracle WSM)エージェントはOracle Security Token Serviceと統合されます。このエージェントは、Oracle Security Token Service Webサービス・エンドポイントに対してWebサービス・セキュリティ・サポートを提供します。

- Oracle Security Token ServiceのWebサービス・エンドポイントの保護

- SOAPメッセージをリライイング・パーティに送信するためのWS-Securityサポートの提供。そのプロセスの一部として、OWSMクライアントはOracle Security Token Serviceとの相互作用により、リライイング・パーティに表示されるセキュリティ・トークンを取得します。

- トークン取得およびトークン検証のためのOracle Security Token Serviceとの相互作用

Oracle Security Token Serviceでは、Oracle Web Services Manager (Oracle WSM)エージェントによるトークン取得およびトークン検証がサポートされています。Oracle Web Services Managerエージェントでは、インバウンドまたはアウトバウンド・セキュリティ・ポリシー施行の一部としてOracle Security Token Serviceを使用する必要はありません。Oracle Web Services Managerクライアント・バインディングは、Oracle Web Services Manager管理者の担当です。

Oracle WSMエージェントは、Oracle Security Token Serviceとクライアントの間のSOAP通信チャネルのメッセージを保護するために、Oracle Security Token Serviceで使用されます。Oracle WSMエージェントでは、WSSクライアントの証明書を検証するときに、関連する信頼できる証明書を含むOPSSキーストア(デフォルトでは$DOMAIN_HOME/config/fmwconfigディレクトリにあるdefault-keystore.jksキーストア)がキャッシュされます。その後、キーストアの内容またはキーストア名を変更する場合は、Oracle Enterprise Manager Fusion Middleware Control、WebLogic ServerコンソールまたはNodeManagerを使用して管理対象サーバーを再起動する必要があります。

Oracle Security Token Serviceで使用できるOracle WSMエージェントは、次のタスクを実行するために、Oracle Security Token Serviceエンドポイントを保護するように構成する必要があります。

- リクエストの復号化(必要な場合)

- リクエストに表示されるデジタル証明書の検証

- リクエストのデジタル署名を作成するために使用される証明書の検証(署名が秘密鍵で作成された場合)

- SOAPヘッダー内のX.509トークンの検証(存在する場合)

- SOAPヘッダー内のKerberosトークンの検証(存在する場合)

- 送信レスポンスの署名(必要な場合)

- 送信レスポンスの暗号化(必要な場合)

Oracle WSMエージェント・キーストア: Oracle WSMエージェントでは、様々な暗号化操作にキーストアが使用されます。これらの操作では、Oracle WSMエージェントはOracle WSMタスク用に構成されたキーストアを使用します。

OAM Webgate: Oracle Security Token Serviceでは、OAM 11gセッション伝播トークンにWebgateが使用されます。このアイデンティティ伝播のユースケースは、より高度なものです。WebLogic Serverおよび一部のカスタム統合でアイデンティティ・アサーション・プロバイダを必要とします。

関連項目:

- 第16章「Oracle Security Token Serviceの実装シナリオ」

- 第16章「Oracle Security Token Serviceの実装シナリオ」

- 「Oracle Web Services Managerのキーストア(default-keystore.jks)について」

Oracle Security Token Serviceエンドポイントとポリシーについて

エンドポイントを追加すると、Oracle Security Token Serviceエンドポイントと関連付けるポリシーURIおよび検証テンプレートのリストから選択できるようになります。デフォルトでは、Oracle Security Token Serviceは図17-1に示すエンドポイントで構成されています。

図17-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート

「図17-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート」の説明

ORAPROVIDERはOracle WSMエージェントと統合されており、クライアントとOracle Security Token Serviceの間で交換されているSOAPメッセージ上でWebサービス・セキュリティをサポートします。Oracle Security Token ServiceはWebサービスのORAPROVIDERを利用して、次の処理を行います。

- Web Servicesエンドポイントの動的な公開

- SOAPメッセージを処理するためのOracle Security Token Serviceの起動

- 各WSエンドポイントのWSDLファイルの公開

Oracle WSMエージェントWSSポリシー・ストア: Oracle WSMエージェントでは、リポジトリで必要なWebサービス・セキュリティ(WSS)ポリシーを取得する必要があります。Oracle Security Token Serviceでは2つのタイプのリポジトリがサポートされています。

- WSSポリシーを含むJARファイル: WLSドメインがクラスパス用に構成されている場合に使用されます。

- Oracle WSM Policy Manager: SOAデプロイメントから使用できます。

関連項目:

- 「WSSプロトコル通信のためのOWSMの構成」

- Oracle Security Token ServiceのためのWebサービス・セキュリティ・ポリシーの管理

- 『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』: Oracle Security Token Serviceのポリシーの詳細

ポリシー・アサーション: 即時利用可能です。Oracle Security Token Serviceでは、Webサービス・セキュリティ: SOAPメッセージ・セキュリティおよびWS-Trustのコンテキストでメッセージを保護する方法を示すために、WS-Policyフレームワークで使用するセキュリティ・ポリシー・アサーションのセットを提供しています。

- Oracle Security Token Serviceでは、セキュリティ・ポリシー・ファイルをデプロイ済のWSDLにアタッチすることで、関連するセキュリティ・ポリシー・ファイルをパブリックに使用できるようになります。

- Oracle Security Token Serviceランタイムでは、WS-Security暗号化およびデジタル署名操作のためにjps-config.xmlで定義されているキーストアに格納された秘密鍵とX.509証明書のペアが使用されます。

次の段落および表では、Oracle Security Token ServiceおよびOracle WSMエージェントで即時に利用できるポリシーを示します。

メッセージ・レベルのセキュリティが不要: メッセージ・レベルのセキュリティが不要な場合は、名前にmessage_protectionが指定されていないOracle Security Token Serviceポリシーを使用します。これは、WS-Security SOAPヘッダーのトークンに含まれる資格証明を使用してユーザーを認証します。Fusion Applicationsトークンに含まれる資格証明は、検証テンプレートに指定されているルールに基づいてマップされます。プレーン・テキストとダイジェスト・メカニズムの両方がサポートされています。

メッセージ・レベルのセキュリティが不要な場合のトランスポート・セキュリティ: クライアント・アプリケーションとWebLogicサーバーの両方が相互に資格証明を提示する双方向のSSLを構成できます。コアWebLogic Serverセキュリティの双方向または一方向のSSLを構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。表17-1に説明されているポリシーを使用します。

表17-1 メッセージ・レベルのセキュリティが不要な場合のポリシー・トランスポート・セキュリティ

ポリシー

説明

sts/wss_username_token_over_ssl_service_policy

WS-Security SOAPヘッダーのUNTトークンに含まれる資格証明を使用してユーザーをマップします。UNTトークンに含まれる資格証明は、検証テンプレートに指定されているルールに基づいてマップされます。プレーン・テキストおよびダイジェストの両方のメカニズムがサポートされます。このポリシーは、トランスポート・プロトコルによりSSLメッセージ保護が提供されることを検証します。

sts/wss_saml_token_over_ssl_service_policy

sts/wss_saml20_token_over_ssl_service_policy

WS-Security SOAPヘッダーのSAML SVトークンに含まれる資格証明を使用してユーザーをマップします。SAMLトークンに含まれる資格証明は、検証テンプレートに指定されているルールに基づいてマップされます。このポリシーは、トランスポート・プロトコルによりSSLメッセージ保護が提供されることを検証します。

sts/wss_saml_token_bearer_over_ssl_service_policy

sts/wss_saml20_token_bearer_over_ssl_service

WS-Security SOAPヘッダーの、確認メソッドがBearerのSAMLトークンに含まれる資格証明を使用してユーザーをマップします。SAMLトークンに含まれる資格証明は、検証テンプレートに指定されているルールに基づいてマップされます。このポリシーは、トランスポート・プロトコルによりSSLメッセージ保護が提供されることを検証します。

sts/wss_sts_issued_saml_bearer_token_over_ssl_service_policy

WS-Security 1.0および1.1ポリシーの相互運用性: WS-Security 1.0または1.1 (認証要件および資格証明の可用性により異なる)との相互運用性が必要な場合は、図17-2のポリシーを使用します。強力なセキュリティ要件がある場合は、WS-Security 1.1ポリシーを使用します。

図17-2 WS-Security 1.0および1.1ポリシー

「図17-2 WS-Security 1.0および1.1ポリシー」の説明

関連項目:
「Oracle WSMエージェントのためのWSSポリシーの使用および管理」

タスクの概要: WS-Sポリシーの使用および変更

1. 「Oracle Access Managerコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. 「エンドポイント」ノードから、「Oracle Security Token Serviceエンドポイントの管理」の説明に従って、保護されるエンドポイントを検索または作成します。

3. 「ポリシーURI」リストから、次の説明に従って、エンドポイントを保護するための特定のWS Securityポリシーを選択します。

- Oracle Security Token ServiceのためのWSSポリシーの管理: クラスパス

- Oracle Security Token ServiceのためのWSSポリシーの管理: Oracle WSM Policy Manager

Oracle Security Token Serviceの有効化および無効化

このトピックの内容は次のとおりです。

- Oracle Security Token ServiceとOracle Access Managerコンソールについて

- Oracle Security Token Serviceのサービスの有効化について

- Oracle Security Token Serviceのサービスの有効化および無効化

Oracle Security Token ServiceとOracle Access Managerコンソールについて

Oracle Access Managerコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。

Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。これには、このマニュアルの第II部で説明する次の一般的なタスクが含まれています。

- 共通のOAMサーバーとプロキシ情報の登録および管理

- 共通のデフォルト・ユーザー・アイデンティティ・ストアの登録および管理

- WSS処理に使用されるOWSMキーストアとは異なるOAMキーストアの構成

- 証明書の検証と失効

Oracle Access Managerコンソールを使用すると、管理者は次のOracle Security Token Service固有のタスクを実行できます。

- 検証トークン・テンプレートの管理: 検証テンプレートには、Webサービス・セキュリティ/WSTrustトークンを検証し、デフォルト・ユーザー・アイデンティティ・ストア内のリクエスタ・パートナまたはユーザー・レコードにマップするための構成プロパティが含まれています。

- 発行テンプレートの管理: 発行テンプレートには、トークンの作成方法に関するルールが含まれています。

- パートナ・データの管理: パートナは、OSTSが信頼しているパートナを表します。OSTSは、リクエスタ、リライイング・パーティおよび発行局の3つのタイプのパートナを定義します。各パートナ・エントリは、パートナ・プロファイルに関連付けられます。パートナ・エントリには、パートナを一意に識別するための署名証明書および暗号化証明書と識別子が含まれています。

- パートナ・プロファイルの管理: パートナ・プロファイルには、パートナのセットに共通の構成プロパティが含まれています。

- 要求マッピング

- トークン・タイプの定義

- トークン・タイプに対して定義される発行および検証テンプレート

- 発行局(その他のSTS)の検証テンプレート・ルールの上書き

- Oracle Security Token Serviceエンドポイントの管理

- トークン発行ポリシーの管理(リクエスタ・パートナがリクエストで参照されるリライイング・パーティに基づいてトークンをリクエストできるかどうかを判断するために評価される認可ポリシー)

- Oracle Security Token Serviceのグローバル設定

- カスタム・トークン

Oracle Security Token Service管理者について

Oracle Access Managerコンソールへの管理アクセス権を持つユーザーには、Oracle Security Token Servicesへのアクセス権があります。

最初は管理者ユーザーは、初回構成時に設定されたWebLogic管理者の資格証明を使用してOracle Access Managerコンソールにログインする必要があります。ただし、企業によっては、Oracle Access Managerを担当するユーザーとOracle Security Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。

Oracle Security Token Serviceへのログインおよびサインアウトについて

Oracle Security Token ServiceをOracle Access Managerとともに使用する場合、Oracle Access Managerコンソールへのログインとサインアウトは同じです。

関連項目:
次のトピックについては、第3章を参照してください。

- Oracle Access Managerコンソールへのログイン

- Oracle Access Managerコンソールからのサインアウト

Oracle Security Token Serviceのサービスの有効化について

Oracle Security Token Serviceを使用するには、図17-3に示すように、Oracle Security Token ServiceとOracle Access Managerの両方を有効にする必要があります。デフォルトでは、Oracle Security Token Serviceは無効になっているため、有効にする必要があります。

図17-3 有効になっているOracle Access Manager with Oracle Security Token Service

「図17-3 有効になっているOracle Access Manager with Oracle Security Token Service」の説明

サービス名の横にある「ステータス」フィールドの緑のチェック・マークは、サービスが有効であることを示します。中に線がある赤の円は、該当するサービスが無効であることを示します。

Oracle Security Token Serviceのサービスの有効化および無効化

前提条件

Oracle Access Managerサービスを有効にする必要があります。

Oracle Security Token Serviceを有効または無効にする手順

1. 通常どおり、Oracle Access Managerコンソールにログインします。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから「使用可能なサービス」をクリックします。

3. OSTSの有効化: Oracle Security Token Serviceの横で、「有効」をクリック(または「ステータス」チェック・マークが緑になっていることを確認)し、Oracle Access Manager Serviceも有効になっていることを確認します。

4. OSTSの無効化: Oracle Security Token Serviceの横で、「無効」をクリック(または「ステータス」チェック・マークが赤になっていることを確認)します。

Oracle Access Managerコンソールを使用したセキュリティ・トークン・サービスの設定の定義

この項の内容は次のとおりです。

- 「セキュリティ・トークン・サービスの設定」について

- 「セキュリティ・トークン・サービスの設定」の管理

「セキュリティ・トークン・サービスの設定」について

「セキュリティ・トークン・サービスの設定」は、「システム構成」タブの「セキュリティ・トークン・サービス」セクションから表示または変更できます。これらの設定を図17-4に示します。

図17-4 「セキュリティ・トークン・サービスの設定」ページ

「図17-4 「セキュリティ・トークン・サービスの設定」ページ」の説明

表17-2に、「セキュリティ・トークン・サービスの設定」ページの要素を示します。

表17-2 セキュリティ・トークン・サービスの設定

要素

説明

パートナ識別属性

「パートナ」ページの「アイデンティティ属性」表で使用できる必要がある、デフォルトで使用可能な属性以外の属性をリストするフィールド。これらの属性を使用すると、属性の値を着信リクエストに含まれる値と照合することでパートナを識別できます。

リクエスタがOracle Security Token ServiceにWS-Trustリクエストを送信すると、サーバーはリクエスタのアイデンティティを含む着信トークンを、Oracle Security Token Serviceパートナ・ストアのパートナ・エントリにマップできます。

そのために、Oracle Security Token Serviceでは検証テンプレートで構成されているマッピング設定を使用し、トークン・データをパートナ・アイデンティティ属性と照合することで参照を実行して、トークン・データをパートナ・エントリにマップします。

デフォルトでは、各リクエスタ・パートナには、ユーザー名、HTTP Basicユーザー名、SSLクライアント証明書DNの3つのアイデンティティ属性が含まれています。

リクエスタ・パートナ・エントリごとに設定できる追加のアイデンティティ属性を定義できます。

このセクションでは、新しい属性を設定できます。新しい属性を定義すると、その属性は「リクエスタ・パートナ」エントリ・セクションで使用可能になり、WSS検証テンプレートのマッピング・ルールで使用できます。

カスタム信頼アンカー・ファイル

デフォルトでは、Oracle Access ManagerおよびOracle Security Token Serviceでは、X.509トークンの検証時、またはSAMLアサーション署名で使用される証明書の検証時に、Oracle Security Token Serviceによる証明書検証に使用される信頼アンカーを含むデフォルトの$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアが使用されます。

必要に応じて、Oracle Security Token Serviceの操作および検証にのみ使用される信頼アンカーを含む特定の信頼アンカー・ファイルを使用するように、Oracle Security Token Serviceを構成できます。この場合、このフィールドには使用するJKSキーストアの場所を指定する必要があります。

次の点に注意してください。

- カスタム信頼アンカー・キーストアを使用する場合、クラスタ全体に自動的に複製されることはありません。複製を管理する必要があります。

- ほとんどの場合、デフォルトのOracle Access ManagerおよびOracle Security Token Service信頼アンカーで十分です。

関連項目: 第18章「Oracle Security Token Serviceの証明書と鍵の管理」

デフォルト暗号化テンプレート

Oracle Security Token Service暗号化用のデフォルト・テンプレートを選択できるリストを次に示します。

- osts_encryption

- osts_signing

関連項目: 「デフォルトの暗号化鍵の設定」

プロキシ

アウトバウンド接続のプロパティ、HTTPプロキシ設定: このセクションを使用して、オプションで実行時にリライイング・パーティのWS-Secポリシーを取得する場合、送信HTTP接続にプロキシを使用するようにOracle Security Token Serviceを構成します。

- 有効: このボックスが選択されている場合、プロキシ機能が有効になっており、リライイング・パーティのWS-Securityポリシーを取得するときに使用されます。このボックスが選択されていない場合、プロキシ機能は無効になっており、関連するフィールドにアクセスして編集することはできません。

- ホスト: プロキシ・ホスト名。

- ポート: プロキシ・ポート番号。デフォルトは8080です。

- 非プロキシ・ホスト: プロキシを使用しないホストのリスト。複数のホストを区切るには、「;」を使用します。

- ユーザー名: プロキシに接続するときに使用するユーザー名。

- パスワード: プロキシに接続するときに使用するパスワード。

キーストア

ロケーション: Oracle Security Token Serviceのインストール時に設定されたアクティブなキーストアのパス。

キーストア表には、表内のテンプレートごとに次の情報が含まれており、各テンプレートは、デフォルト暗号化テンプレートとして使用できます。

- テンプレートID: キーストアにアクセスできるテンプレートの名前。

- 別名: テンプレートの別名を識別します。テンプレートを追加するときに、リストされている別名から選択できます。次に例を示します。

- パスワード: 選択した別名のパスワード。

- 説明: オプション。

キーストア・セクションでは、OAM/OSTSキーストア($DOMAIN_HOME/config/fmwconfig/.oamkeystore、JCEKSタイプ)にあるキー・エントリが定義されます。

エントリが定義されると、そのエントリを(SAML発行テンプレートのように)他のOracle Security Token Serviceテンプレートで使用できます。

「セキュリティ・トークン・サービスの設定」の管理

有効な管理者の資格証明を持つユーザーは、この手順を使用して、「セキュリティ・トークン・サービスの設定」を確認または変更できます。

前提条件

Oracle Access Manager ServiceとOracle Security Token Serviceの両方が有効になっている必要があります。

「セキュリティ・トークン・サービスの設定」を表示または編集する手順

1. 通常どおり、Oracle Access Managerコンソールにログインします。

https://hostname:port/oamconsole/

2. 「システム構成」タブから「セキュリティ・トークン・サービス」セクションを開きます。

3. 「セキュリティ・トークン・サービスの設定」をダブルクリックします。

4. 「セキュリティ・トークン・サービスの設定」ページで、次の情報を表示(または変更)します(表17-2を参照)。

- パートナ識別属性

- カスタム信頼アンカー・ファイル

- 「プロキシ」の詳細

5. キーストア表: 新しい暗号化テンプレートを表示、追加または削除します。

6. 「適用」をクリックし、変更を送信します(または、「元に戻す」をクリックして変更を取り消します)。

7. 終了したらページを閉じます。

Oracle WSMエージェントのためのWSSポリシーの使用および管理

既存のWebサービス・セキュリティ・ポリシーを使用して、Oracle Security Token Service Web Serviceエンドポイントを保護できます。次に例を示します。

- クラスパス・モード: このモードでは、$ORACLE_IDM_HOME/oam/server/policy/sts-policies.jarに定義されている既存のWebサービス・セキュリティ・ポリシーが使用されます。

- SOAデプロイメント: SOAデプロイメントから使用できる、Oracle WSM Policy Managerに定義されているポリシーが使用されます。

この項では、次の各トピックでOracle Security Token ServiceのWebサービス・セキュリティ・ポリシーを管理する方法を説明します。

- Webサービス・セキュリティ・ポリシーの使用および変更

- Oracle Security Token ServiceのためのWSSポリシーの管理: クラスパス

- Oracle Security Token ServiceのためのWSSポリシーの管理: Oracle WSM Policy Manager

Webサービス・セキュリティ・ポリシーの使用および変更

この項では、Oracle Security Token Service WSエンドポイントの保護に使用されるWS-Securityポリシー、およびこれらのポリシーの変更方法を説明します。Oracleが提供するWS-Securityポリシーは、ほとんどのユースケースに対応している必要があります。

関連項目:

- 「Oracle Security Token Serviceエンドポイントとポリシーについて」

- 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のWebサービスへのポリシーのアタッチに関する項

Oracle Security Token ServiceのためのWSSポリシーの管理: クラスパス

事前定義済のOracle Web Services Managerポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して構成します。WSSポリシーのクラスパス・モードの場合、OWSMエージェントはクラスパスにあるsts-policies.jarからポリシーを取得します。

SOAがWebLogic Serverドメインにデプロイされていない場合、Oracle Security Token ServiceインストーラではWSSポリシーのクラスパス・モード用にWebLogic Serverドメインが構成されます。WLSドメインがクラスパス用に構成されるときに使用されるWSSポリシーを含むJARファイルは、次の場所にあります。

$IDM_ORACLE_HOME/oam/server/policy/sts-policies.jar

ご使用の環境がクラスパス・モードの場合は、管理者が次のタスクを実行してsts-policies.jarがクラスパスにあることを確認します。

関連項目:

- 「Oracle Security Token Serviceエンドポイントとポリシーについて」

- 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』の事前定義済のOracle WSMポリシーとアサーション・テンプレートに関する項

タスクの概要: Oracle Security Token ServiceのためのWSSポリシーの管理: クラスパス

1. OWSMアサーション・テンプレートを定義します。

2. 必要に応じて、次の作業を実行します。

- OWSMポリシーの変更

- ポリシーの定義(OWSMアサーション・テンプレートを使用)

3. sts-policies.jarファイルでアサーション・テンプレートおよびポリシーをバンドルします。

META-INF/assertiontemplates/oracle of the $IDM_ORACLE_HOME/oam/server/policy/
sts-policies.jar

4. sts-policies.jarが次のパスにあることを確認して、「ポリシーURI」ドロップダウン・リストで使用できるようにポリシーURIを有効にします。

$IDM_ORACLE_HOME/oam/server/policy/sts-policies.jar

5. Oracle Security Token Serviceを実行している管理対象サーバーを再起動します。

6. OAM管理コンソールに移動し、Oracle Security Token Serviceエンドポイントを構成します。

Oracle Security Token ServiceのためのWSSポリシーの管理: Oracle WSM Policy Manager

Oracle WSM Policy Managerは、Oracle Fusion Middleware WebサービスおよびSOAアプリケーションのセキュリティの根幹です。Oracle WSM Policy Managerがポリシー・フレームワークを管理する方法の詳細は、『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のOracle WSMポリシー・フレームワークの理解に関する項を参照してください。

設計時に、Oracle JDeveloperなど好みのIDEを使用して、プログラムによってアプリケーションにOracle WSMポリシーおよびWebLogic Webサービス・ポリシーを添付します。また、デプロイ時に、SOAコンポジット、ADFおよびWebCenterアプリケーションにはOracle Enterprise Manager Fusion Middleware Controlを使用し、WebLogic Webサービス(Java EE)にはWebLogic Server管理コンソールを使用して、ポリシーを添付します。

システム管理者は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle WSMで次のことを実行できます。

- Oracle WSM Policy Managerを使用して、ポリシーを一元的に定義。

- Oracle WSMのセキュリティおよび管理ポリシーを実行時にローカルで実行。

ご使用の環境がOWSM Policy Managerと統合されている場合は、次のタスクを実行し、Oracle Web Services Managerを使用してセキュリティ・トークン・サービスの設定のWSSポリシーを追加または変更します。

注意:
管理者は、Oracle Enterprise Manager Fusion Middleware ControlからOracle WSMのすべての機能にアクセスできます。

関連項目:
『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』

- 第II部、「基本管理」

- 第III部、「高度な管理」

タスクの概要: Oracle Security Token ServiceのためのWSSポリシーの管理: OWSM Policy Manager

1. OWSM Policy Managerから、目的のポリシーを探して開きます。

2. 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』を参照して、必要に応じてポリシーを変更します。

3. Oracle Security Token Serviceを実行しているすべての管理対象サーバーを再起動します。

4. 「WSSプロトコル通信のためのOWSMの構成」に進みます。

WSSプロトコル通信のためのOWSMの構成

この項では、Oracle Security Token Serviceに組み込まれているWS-SecクライアントとOracle WSMエージェントの間の通信を構成する方法を説明します。

Oracle WSMエージェントはOracle Security Token ServiceのWebサービス・エンドポイントを保護し、WSSプロトコル交換をサポートします。クライアントがOracle WSMエージェントと正常に通信するためには、次のことが必要です。

- クライアントは、Oracle WSMエージェントで使用される署名証明書および暗号化証明書を認識する必要があります(そのためには、Oracle Security Token Serviceに組み込まれているOWSMエージェントで使用される署名証明書および暗号化証明書を抽出して配布する必要があります)。

- Oracle WSMエージェントは、ポリシーに応じてクライアントで使用される署名証明書を認識する必要があります(そのためには、Oracle WSMエージェントの信頼できる証明書としてクライアントの証明書を追加する必要があります)。

タスクの概要: Oracle WSMエージェントとの通信の構成

1. 「Oracle Security Token ServiceのOracle WSMエージェントのWS-Securityポリシーについて」を参照

2. Oracle WSMキーストア・パスワードの取得

3. Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出

4. Oracle WSMキーストアへの信頼できる証明書の追加

5. Oracle WSMキーストア内の信頼できる証明書の検証

6. WSS KerberosポリシーのためのOracle WSMエージェントの構成

関連項目:
第18章「Oracle Security Token Serviceの証明書と鍵の管理」

Oracle Security Token ServiceのOracle WSMエージェントのWS-Securityポリシーについて

Oracle WSMエージェントでは、リポジトリで必要なWeb Services Security (WSS)ポリシーを取得する必要があります。Oracle Access Managerでは、Oracle Security Token Serviceに対して次の2つのタイプのリポジトリがサポートされています。

- WSSポリシーを含むJARファイル: WLSドメインがクラスパス用に構成されている場合に使用されます。必要なJARファイルは$IDM_ORACLE_HOME/oam/server/policy/ sts-policies.jarにあります。

- SOAデプロイメントから使用できるOracle WSM Policy Manager

Oracle Security Token Serviceのインストール時に、インストーラにより、Oracle Web Services Manager Policy Managerが存在し、WebLogicセキュリティ・ドメインにデプロイされているかどうかが検出されます。

- WebLogicセキュリティ・ドメインにデプロイされていない場合、インストーラでは、Webサービス・セキュリティ・ポリシー・クラスパス・モード用にWebLogicセキュリティ・ドメインが構成されます。このモードでは、WSMエージェントによりJARファイルからポリシーが取得されます。

- 存在する場合、インストーラはOracle Web Services Manager Policy Managerに接続し、Oracle Security Token Serviceエンドポイントの保護に使用されるポリシーをアップロードします。

関連項目:
「ポリシーおよびセッション・データベース・ストアについて」: OAMポリシー・データ(オプション)およびOAMユーザー・セッション・データに対するOAM 11gの必須データベースの詳細

Oracle WSMキーストア・パスワードの取得

管理者は、特定のアクティビティに対してCSFからキーストア・パスワードおよびキー・エントリ・パスワードを取得する必要があります。それ以外の場合、キーストアまたはキー・エントリを変更することはできません。キーストアへのアクセス権があると、次のことが必要になる場合があります。

- クライアントに配布するための署名/暗号化証明書の抽出(必要な場合)

- 署名/暗号化キー・エントリの更新または置換

- 信頼できる証明書を追加します

次の手順により、Oracle WSMキーストアおよびキー・エントリの保護に使用されるパスワードが表示されます。

Oracle WSMキーストア・パスワードを取得する手順

1. WSLTスクリプト環境を入力します。

2. connect()コマンドを使用してWebLogic Server AdminServerに接続します。

3. AdminServerに接続情報を提供することにより、コマンドlistCred(map="OAM_STORE", key="jks")を実行します。

4. パスワードを書き留めます。

5. 「Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出」に進みます。

Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出

SOAPの相互作用中に、WS-Securityプロトコルでは、OSTSエンドポイントを保護するOWSMエージェントによるWSS操作に使用される署名/暗号化証明書を信頼することをクライアントに要求する場合があります。その場合、OSTS管理者はWSS操作に使用されるOSTS OWSM署名/暗号化証明書を抽出し、WSクライアントに提供する必要があります。

管理者は、WSS暗号操作のためにOracle Security Token Serviceで使用される署名証明書および暗号化証明書をエクスポートする必要があります。次の手順は、この操作の実行方法を示しています。

- $DOMAIN_HOMEをDomainディレクトリへのパスに置換

- CERT_FILEを、証明書が保存されるファイルの場所に置換

パスワードの入力を求められたら、[Enter]キーを押します。

前提条件

Oracle WSMキーストア・パスワードの取得

署名証明書および暗号化証明書をエクスポートする手順

1. keytoolを探します。

2. 次のコマンドを実行します。

keytool -exportcert -keystore $DOMAIN_HOME/config/fmwconfig/default-keystore.j
ks -storetype JKS -alias orakey -file $CERT_FILE

3. プロンプトが表示されたら、前の項で取得したキーストア・パスワードを入力します。

4. 「Oracle WSMキーストアへの信頼できる証明書の追加」に進みます。

Oracle WSMキーストアへの信頼できる証明書の追加

WSS暗号操作のためにOWSMキーストアに信頼できる証明書を追加する手順

- 次の手順でコマンドを実行

- $DOMAIN_HOMEをDomainディレクトリへのパスに置換

- $TRUSTED_CERT_FILEを、信頼できる証明書を含むファイルの場所に置換

- TRUSTED_CERT_ALIASを、信頼できる証明書が格納される別名に置換

パスワードの入力を求められた場合は、以前に取得したOWSMキーストアのパスワードを入力します。

前提条件

Oracle WSMキーストア・パスワードの取得

管理者は、インポートする証明書を持っている必要があります。

Oracle WSMキーストアに信頼できる証明書を追加する手順

1. keytoolを探します。

2. 次のコマンドを実行します。

keytool -importcert -trustcacerts -keystore $DOMAIN_HOME/config/fmwconfig/de
fault-keystore.jks -storetype JKS -alias $TRUSTED_CERT_ALIAS -file $TRUSTED_
CERT_ALIAS

3. 画面のメッセージを確認し、要求された場合はパスワードを入力します。

4. 「Oracle WSMキーストア内の信頼できる証明書の検証」に進みます。

Oracle WSMキーストア内の信頼できる証明書の検証

Oracle WSMエージェントが証明書検証を実行する場合、Oracle WSMタスク用に構成されたキーストアを使用し、キーストアに含まれる信頼できる証明書エントリに対して証明書を検証します。これらの操作では、OWSMキーストアでの信頼できる証明書エントリ(証明書自体または発行者の証明書)の追加が必要な場合があります。

SOAPリクエスタを受信すると、Oracle WSMエージェントはメッセージを保護するためにリクエストを処理します。手順の一部では、着信メッセージが次の場合に証明書検証操作が行われます。

- タイプがWSS 1.0で、秘密鍵で作成されたデジタル証明書を含み、証明書が存在しない場合。この場合、次のようになります。
処置: Oracle WSMキーストアには署名証明書を含める必要があります。

- タイプがWSS 1.0で、秘密鍵で作成されたデジタル証明書を含み、証明書が存在する場合。
処置: Oracle WSMキーストアには、署名証明書または署名証明書の発行者の証明書を含める必要があります。

- タイプがWSS 1.1で、秘密鍵で作成されたデジタル証明書を含み、証明書が存在しない場合。
処置: Oracle WSMキーストアには署名証明書を含める必要があります。

- タイプがWSS 1.1で、秘密鍵で作成されたデジタル証明書を含み、証明書が存在する場合。この場合、OWSMキーストアには署名証明書または署名証明書の発行者の証明書を含める必要があります。
処置: Oracle WSMキーストアには、署名証明書または署名証明書の発行者の証明書を含める必要があります。

関連項目:
第18章「Oracle Security Token Serviceの証明書と鍵の管理」

WSS KerberosポリシーのためのOracle WSMエージェントの構成

Oracle Security Token Serviceは、様々なOracleクライアント(Oracle Web Services Managerクライアント)またはサード・パーティ・クライアント(MicrosoftおよびIBM)にサービスを提供します。Oracle WSMエージェントは、着信リクエストに対してメッセージ保護のみを実行します(認証は実行しません)。Oracle WSMエージェントでは、OPSSアイデンティティ・ストア内のユーザー・レコードへの着信Kerberosチケットのマップは試行されません。

Oracle WSMがWSS Kerberosポリシーを使用してOracle Security Token Serviceとやり取りするクライアントの場合、『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のOracle WSM Kerberos全体の設定に関する項が適用されます。

ただし、クライアントがOracle WSMではない場合は表17-3を参照し、クライアントの構成方法に関する項、およびKerberosチケットで参照されるユーザーの認証に関する項は無視してください。

表17-3 WSS KerberosポリシーのためのOracle WSM以外のクライアントの構成

Oracle以外のクライアントに対して実行するタスク

Oracle以外のクライアントに対してスキップするタスク

KDCの構成

MIT Kerberos KDCの初期化および起動

プリンシパルの作成

正しいKDCを使用するためのWebサービス・クライアントの構成

Webサービス・クライアントでのサービス・プリンシパル名の設定

設計時のWebサービス・クライアントでのサービス・プリンシパル名の設定

正しいKDCを使用するためのWebサービスの構成

Enterprise Managerでの正しいkeytabファイルの使用方法

keytabファイルの抽出とエクスポート

keytabファイルを使用するためのkrb5ログイン・モジュールの変更

サービス・プリンシパルに対応するユーザーの認証

Webサービス・クライアントのチケット・キャッシュの作成

Active DirectoryのKerberosおよびメッセージ保護との使用

Webサービス・クライアントの設定

ユーザー・アカウントの作成

Keytabファイルの作成

サービス・プリンシパル名の設定

Webサービスの設定

Oracle Security Token Serviceポリシーの管理および移行

ここでは、次の内容について説明します。

- Oracle Security Token Serviceポリシーの管理および移行について

- Oracle Security Token Serviceポリシーの管理

- Oracle Security Token Serviceポリシーの移行

Oracle Security Token Serviceポリシーの管理および移行について

Oracle Security Token Serviceでは、sts-policies.jarファイル内のエンドポイントのポリシーがパッケージ化されます。このjarは、WLS_HOMEの下の次の場所($WL_HOME/Oracle_IDM1など)にコピーされます。

$DW_HOME/oam/server/policy

sts-policies.jarには、JARの次の場所にstspolicies.propファイルが含まれています。

META-INF/policies/sts/

このファイルは、ポリシーを宛先リポジトリに移行するときにサーバーがJARエントリをプログラムによって読み取れるように、ディレクトリにパッケージ化されたすべてのポリシーをファイル名としてリストします。

注意:
移行の前に、必要に応じてポリシーおよびstspolicies.propを更新してください。

Oracle Security Token Serviceポリシーの管理

次の手順は、ポリシー更新の様々なシナリオを示しています。

タスクの概要: ポリシーおよびstspolicies.propの更新

1. sts-policies jarへのポリシーの追加: 新しいjarを作成する前に、この新しいポリシー・ファイル名を含めるように、META-INF/policies/sts/にあるstspolicies.propファイルも更新する必要があります。

2. sts-policies jarからのポリシーの削除: ファイルMETA-INF/policies/sts/stspolicies.propからエントリも削除する必要があります。

3. 既存のポリシー・ファイル名の更新: META-INF/policies/sts/にあるポリシー・ファイルの名前を変更するときに、META-INF/policies/sts/stspolicies.propファイル内の対応するエントリも更新する必要があります。

4. 既存のポリシー内容の更新: ファイル名を変更せずにポリシー・ファイルの内容を更新する場合、その他の処理を実行する必要はありません。

Oracle Security Token Serviceポリシーの移行

インストール時に、Oracle Security Token Serviceがインストールされるドメイン内にSOAがデプロイされているかどうかを確認するために、チェックが行われます。

- SOAがインストールされていない場合、Oracle WSMプロトコルはクラスパスに設定され、クラスパス上のJARからポリシーが読み込まれます。

関連項目:
「Oracle WSMエージェントのためのWSSポリシーの使用および管理」

- SOAがドメイン内に存在する場合、Oracle Security Token Serviceはsts-policies.jarからポリシーを読み取り、Oracle WSM MbeansをコールすることでOracle WSM PMリポジトリに移行します。

- Oracle Security Token Serviceの後、同じドメイン内にSOAがインストールされる場合、次のようにSOAとOracle Security Token Serviceの間のスムーズな操作が保証されます。

- Oracle WSMプロトコルを「remote」に設定する必要があります。

- Oracle WSMが提供するツールを使用して、Oracle Security Token Serviceポリシーをsts-policies jarからOracle WSM PMリポジトリに移行する必要があります。

Oracle Security Token Serviceメッセージのロギングの概要

ロギングは、コンポーネントがファイルにメッセージを書き込むためのメカニズムです。管理者は、ロギング・メカニズムを使用して重要なコンポーネント・イベントを取得できます。Oracle Access Manager 11gのコンポーネントは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとガイドラインを使用しています。これはjava.util.loggingパッケージを使用して行いますが、このパッケージは標準的なもので、すべてのJava環境で使用できます。ロギング・システムはフラット・ファイルにのみ出力を書き出します。Oracle Databaseインスタンスへのロギングはサポートされていません。

ロギングの構成とログ・ファイルの検索がこの項の焦点です。ログ・ファイルの情報を使用した問題診断については、このマニュアルでは取り上げません。

ログ・メッセージは問題の診断に使用されます。ロギング・インフラストラクチャは、Oracle Access Managerコンポーネントからのメッセージを記録します。管理者は、ロガーの定義対象となる各Oracle Access Managerコンポーネントに対してログ・レベルを指定することにより、メッセージ内の記録情報量を制御します。

注意:
一般に、ユーザーは、問題診断のためにOracleテクニカル・サポートへ送るファイルを作成するためにロギングを有効にします。ログ・メッセージに関するドキュメントはありません。場合によっては、ログ・ファイルを参照することによってユーザー自身で問題を診断できることもあります。

デフォルトでは、すべてのOracle Access Managerコンポーネントのログ・レベルが通知レベルになっています。「エラー」レベルでのロギングで生成される出力は少量ですが、他のログ・レベルではロギング出力が大量になることがあり、その場合はOAMのパフォーマンスに影響します。本番環境では、通常はロギングを無効にするか、ロギング出力量が少くなるようなレベル(たとえばエラー・レベル)に設定します。

Oracle Access Manager with Oracle Security Token Serviceは、WebLogicコンテナのロギング・デフォルトを使用します。

- ロギング・ファイル: DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

- ロギング構成ファイル: ロギング・レベルと、ロギングのためのその他の構成情報を提供します。このファイルは次のパスに保存されます: DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

Oracle Security Token Serviceの監査の概要

Oracle Access Manager with Oracle Security Token ServiceとOracle Fusion Middleware 11gの監査機能は、説明責任を果たすための手段と、「誰がいつ何をしたか」というタイプの質問への回答を提供します。監査データは、ダッシュボードの作成、履歴データの集計、およびリスクの評価に使用できます。記録された監査データを分析すれば、コンプライアンス担当者がコンプライアンス方針を定期的に確認できます。

この項では、監査可能なOracle Security Token Service管理イベントとランタイム・イベントを説明します。Oracle Security Token Serviceの共通監査設定を構成すること、および設定した監査構成の検証がこの章の主題です。ただし、監査データの分析と監査についてはこのマニュアルでは取り上げません。

Oracle Access Manager with Oracle Security Token Serviceは、Oracle Fusion Middlewareの共通監査フレームワークを使用し、大量のユーザー・ランタイム・イベントおよび管理イベント(システムへの変更)の監査を支援します。Oracle Fusion Middlewareの共通監査フレームワークを使用すれば、ロギングと例外を一様な形で取り扱い、すべての監査イベントの診断を行うことができます。

監査機能は有効または無効のどちらに設定しておくことも可能ですが、本番環境では有効にしておくのが普通です。監査による性能への影響は最小限に抑えられており、監査によって得られた情報は有用です(業務に不可欠な場合もあります)。

Oracle Access Manager with Oracle Security Token Serviceは、1人のユーザーまたはユーザーのセットに対してデータ・キャプチャを有効にする、Oracle Access Managerコンソールで設定される構成パラメータに基づいています。

監査データは、集中管理された1つのOracle Databaseインスタンスや、フラットファイルに書き込むことができます。監査記録の保存場所にかかわらず、記録には、特定の要件に合わせて構成することのできる一連の項目が含まれています。監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。

Oracle Access Manager with Oracle Security Token Serviceは、あらかじめ設定されたコンプライアンス・レポートを提供するOracle Business Intelligence Publisherと統合できます。

Oracle Security Token Service監査レコードの格納について

Oracle Access Manager with Oracle Security Token Serviceは、共通監査フレームワークでサポートされている様々なターゲットに監査レコードを書き込むように構成できます。

- ローカル・フラット・ファイル: デフォルトでは、Oracle Access Manager with Oracle Security Token Serviceは監査データをファイルに記録します。

- 中央データベース: 本番環境においては、共通監査フレームワークのスケーラビリティと高可用性を実現するために、データベース監査ストアを使用することをお薦めします。監査データは累積的なもので、その量は時間とともに増大します。これは監査データ専用のデータベースとして、他のアプリケーションは使用しないようにするのが理想です。

- プラットフォーム固有のログ(LinuxのSyslogおよびWindowsのイベント・ログ)

- Audit Vault

監査記録用の恒久的ストアとしてのデータベースに切り替えるには、まず、リポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・スキーマを作成する必要があります。RCUは、データベースに監査記録を格納するために必要なスキーマを使用して、そのデータベース・ストアをシードします。スキーマ作成後にデータベースの構成を設定するには次の操作が必要です。

- 作成した監査スキーマを参照するデータ・ソースの作成

- そのデータ・ソースを参照する監査ストアの設定

関連項目:

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 監査データベース・ストアの設定

- 「Oracle Access Manager内の共通監査設定の追加、表示または編集」

監査レポートおよびOracle Business Intelligence Publisherについて

データベース監査ストア内のデータは、Oracle Business Intelligence Publisherであらかじめ定義されたレポートを通じて表示されます。これらのレポートを使用すれば、ユーザー名、時間範囲、アプリケーション・タイプ、実行コンテキスト識別子(ECID)などの様々な基準に基づいて、監査データをドリルダウンできます。

Oracle Access Managerには、そのまますぐに使用できるサンプル監査レポートがいくつか用意されており、これらのレポートにはOracle Business Intelligence Publisherでアクセスできます。また、Oracle Business Intelligence Publisherを使用して、独自のカスタム監査レポートを作成することもできます。

関連項目:
「監査レポートおよびOracle Business Intelligence Publisherについて」

監査ログについて

監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。監査ログ・ファイルには、Date、Time、Initiator、EventType、EventStatus、MessageText、ECID、RID ContextFields、SessionId、TargetComponentType、ApplicationName、EventCategoryなどを含むいくつかのフィールドが記録されます。

関連項目:
『Oracle Fusion Middlewareセキュリティ・ガイド』の監査の構成と管理に関する章に含まれる監査ログ関連項目

Oracle Security Token Service管理イベントとランタイム・イベントの監査

Oracle Security Token Serviceには、特定のイベント・タイプおよび監査対象イベントを定義する独立した監査構成ファイル(component_events.xml)が用意されています。

ここでは、次の内容について説明します。

- すべてのイベントに共通の監査レコード・コンテンツについて

- 監査可能なOracle Security Token Service管理イベント

- 監査可能なOracle Security Token Serviceランタイム・イベント

すべてのイベントに共通の監査レコード・コンテンツについて

次のデータは、監査されるイベントまたはイベント・タイプに関係なく、各監査レコードに含まれています。

- イベントの日付と時刻

- イベントを開始するクライアントのIPアドレス

- クライアント・アイデンティティ

- イベントの処理時間

監査可能なOracle Security Token Service管理イベント

Oracle Security Token Service管理イベントは、component_events.xmlに定義されているいくつかの構成管理操作に分類されます。詳細は、表17-4を参照してください。

関連項目:
「Oracle Access Manager with Oracle Security Token Serviceの監査の設定」

表17-4 Oracle Security Token Serviceの構成管理操作

OSTSの構成管理操作

説明

共通属性

- OldSettings: 変更が適用される前の、以前の設定を表す文字列。

- NewSettings: 新しい設定を表す文字列。

- TemplateID: 作成、更新または削除されている検証テンプレートまたは発行テンプレートのID。

- ProfileID: 作成、更新または削除されているパートナ・プロファイルのID。

- PartnerID: 作成、更新または削除されているパートナのID。

- SettingsID: 作成、更新または削除されている汎用設定のID。

検証テンプレートの作成

CreateValidationTemplateで参照される検証テンプレートの作成に関して記録される監査イベント。

属性:

- TemplateID

- NewSettings

検証テンプレートの更新

UpdateValidationTemplateで参照される検証テンプレートの更新に関して記録される監査イベント。

属性:

- TemplateID

- OldSettings

- NewSettings

検証テンプレートの削除

DeleteValidationTemplateで参照される検証テンプレートの削除イベントに関して記録される監査イベント。

属性:

- TemplateID

- OldSettings

発行テンプレートの作成

CreateIssuanceTemplateで参照される発行テンプレートの作成に関して記録される監査イベント。

属性:

- TemplateID

- NewSettings

発行テンプレートの更新

UpdateIssuanceTemplateで参照される発行テンプレートの更新に関して記録される監査イベント。

属性:

- TemplateID

- OldSettings

- NewSettings

発行テンプレートの削除

DeleteIssuanceTemplateで参照される発行テンプレートの削除イベントに関して記録される監査イベント。

属性:

- TemplateID

- OldSettings

パートナ・プロファイルの作成

CreatePartnerProfileで参照されるパートナ・プロファイルの作成に関して記録される監査イベント。

属性:

- ProfileID

- NewSettings

パートナ・プロファイルの更新

UpdatePartnerProfileで参照されるパートナ・プロファイルの更新に関して記録される監査イベント。

属性:

- ProfileID

- OldSettings

- NewSettings

パートナ・プロファイルの削除

DeletePartnerProfileで参照されるパートナ・プロファイルの削除イベントに関して記録される監査イベント。

属性:

- ProfileID

- OldSettings

パートナの作成

CreatePartnerで参照されるパートナ・プロファイルの作成に関して記録される監査イベント。

属性:

- PartnerID

- NewSettings

パートナの更新

UpdatePartnerで参照されるパートナ・プロファイルの更新に関して記録される監査イベント。

属性:

- PartnerID

- OldSettings

- NewSettings

パートナの削除

DeletePartnerで参照されるパートナ・プロファイルの削除イベントに関して記録される監査イベント。

属性:

- PartnerID

- OldSettings

汎用管理作成

GenericAdminCreationで参照される汎用作成管理操作に関して記録される監査イベント。

属性:

- SettingsID

- NewSettings

汎用管理更新

GenericAdminUpdateで参照される汎用更新管理操作の更新に関して記録される監査イベント。

属性:

- SettingsID

- OldSettings

- NewSettings

汎用管理削除

GenericAdminDeletionで参照される汎用削除管理操作に関して記録される監査イベント。

属性:

- SettingsID

- OldSettings

監査可能なOracle Security Token Serviceランタイム・イベント

トークン操作のためのOracle Security Token Service固有のランタイム・イベントはcomponent_events.xmlに定義されています。詳細は、表17-5を参照してください。

表17-5 Oracle Security Token Service固有のランタイム・イベント

トークン操作

説明

共通属性

- Requester: RSTの送信によってリクエストしたユーザー

- RelyingParty: トークンが作成されるユーザー

- UserID: エンド・ユーザー・アイデンティティ

- TokenType: SAML11、SAML20、ユーザー名、X.509、Kerberos、OAMまたはカスタム

- Token: トークンのXML値

- TokenContext: トークン操作のために渡されるコンテキスト・データ

- Message: 着信または送信メッセージのXML表現

着信メッセージ

OutgoingMessageで参照されるOracle Security Token Serviceが受信する着信RSTRメッセージ。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Message

送信メッセージ

IncomingMessageで参照されるOracle Security Token Serviceが受信する送信RSTRメッセージ。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Message

トークン検証

TokenValidationで参照されるOracle Security Token Service内のトークン検証の監査イベント。ステータス属性は、検証操作が成功したかどうかを示します。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Token

- TokenType

- TokenContext

- ステータス

トークン生成

TokenGenerationで参照されるOracle Security Token Service内のトークン生成の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Token

- TokenType

- TokenContext

- UserID

LDAPユーザー認証

LDAPUserAuthenticationで参照されるLDAPディレクトリでのローカル・ユーザー認証の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- UserID

- ステータス

汎用ランタイム操作

GenericRuntimeOperationで参照されるOracle Security Token Serviceによって実行される汎用操作の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- OperationType: 操作のタイプ

- OperationData: 操作のコンテキストを表す文字列

18 Oracle Security Token Serviceの証明書と鍵の管理

この章の内容は次のとおりです。

- 前提条件

- Oracle Security Token Serviceの証明書と鍵の概要

- Oracle Security Token Serviceの暗号化/署名鍵の管理

- WS-Trust通信のパートナ・キーの管理

- 証明書検証の管理

前提条件

「Oracle Security Token Serviceの有効化および無効化」の説明に従って、Oracle Access ManagerサービスとOracle Security Token Serviceサービスの両方が実行されている必要があります。

Oracle Security Token Serviceの証明書と鍵の概要

この項では、Oracle Security Token Serviceに使用される証明書と鍵について説明します。

「証明書、認証局および暗号化鍵について」で説明されているとおり、公開鍵インフラストラクチャにより、デジタル証明書はWebベースのトランザクションの資格証明を確立します。

実行時の公開鍵: 実行時に公開鍵インフラストラクチャの資格証明が使用される独自のケースがあります。たとえば、(OWSMエージェントを使用した)リクエスタとOracle Security Token Serviceとの間のWebサービス・セキュリティ(WSS)プロトコル通信のときなどです。表18-1も参照してください。

表18-1 実行時に使用されるOSTS公開鍵

Oracle Security Token Serviceでの処理

説明

SAMLアサーションの発行

- Oracle Security Token Serviceの署名アサーションは、STSグローバル設定に定義されている鍵を使用します。

- Oracle Security Token Serviceは、タイプが公開鍵のHolder-of-Key確認メソッドの証明鍵としてリクエスタの署名証明書を使用します。

- Oracle Security Token Serviceは、タイプが秘密鍵のHolder-of-Key確認メソッドの秘密証明鍵を暗号化するためにリライイング・パーティの暗号化証明書を使用します。

- Oracle Security Token Serviceは、タイプが秘密鍵のHolder-of-Key確認メソッドのRSTR内の秘密証明/エントリを暗号化するためにリクエスタの暗号化証明書を使用します。

トークンの発行

- Oracle Security Token Serviceではリライイング・パーティの暗号化証明書を使用して、送信トークンを暗号化します。

SAMLアサーションの検証

- Oracle Security Token Serviceでは発行局の署名証明書を使用して、着信SAMLアサーションの署名を検証します。

Webサービス・セキュリティ(WSS)プロトコル通信の使用

(OWSMエージェントを使用した)リクエスタとOracle Security Token Serviceの間の通信

キーストアとOracle Security Token Serviceについて

Oracle Access Manager with Oracle Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。

表18-2に、これらの詳細を示します。表の後に説明が続きます。

表18-2 Oracle Access Manager with Oracle Security Token Serviceのキーストア

キーストア

説明

システム・キーストア

OAM Serverインスタンスに関連付けられた鍵および証明書のコンテナ(署名および暗号化のためのOAM秘密鍵とOracle Security Token Service秘密鍵)。

JCEKSタイプのシステム・キーストア.oamkeystoreのみが存在する可能性があります。

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

表17-2「セキュリティ・トークン・サービスの設定」で説明されているとおり、Oracle Access Managerコンソールを使用して証明書別名とパスワードを構成できます。

信頼キーストア

クライアントが提示する証明書を検証するには、信頼キーストアを使用します。

$DOMAIN_HOME/config/fmwconfig/amtruststore

amtruststoreはインストール時に作成され、少なくとも1つの信頼できるアンカーを含める必要があります。

信頼キーストアは、JREのkeytoolアプリケーションを使用して管理されます。Oracle Security Token Serviceではカスタム信頼キーストアを使用できます。

証明書失効リスト(CRL)

証明書失効情報リストは、ファイルシステム上のZIPアーカイブに格納されます。これは、CRLベースの証明書失効チェックを実行するときにOracle Access Manager/Oracle Security Token Serviceサーバー・インスタンスで使用されます。amcrl.jarにはDERフォーマットのCRLファイルが含まれています。

$DOMAIN_HOME/config/fmwconfig/amcrl.jar

OAM Serverでは、キーストアおよびCRL Zipファイルの通知リスナーが定義されます。これらのファイルを変更すると、Oracle Access Manager with Oracle Security Token Serviceでは、再起動しなくてもキーストア/crl-zipが実行時にリロードされます。

「証明書失効リスト(CRL)」で説明されているとおり、amcrl.jarはインストールによって作成され、Oracle Access Managerコンソールを使用して変更できます。

表18-3のファイルは、JMXフレームワークによってドメイン内のすべての管理対象サーバーに配布されます。$DOMAIN_HOME/config/fmwconfig /mbeansディレクトリでは、ファイルを管理し、ファイルをドメイン全体に伝播する必要があることを識別するために、MBeanを示すファイルごとに登録mbeans.xmlが定義されます。

表18-3 キーストアMbean

キーストア

Mbeanと説明

システム・キーストア: .oamkeystore

.oamkeystoreの構成は、JREのkeytoolアプリケーションを使用して実行されます。

信頼キーストア: .amtruststore

amtruststoreの構成は、JREのkeytoolアプリケーションを使用して実行されます。

CRL: amcrl.jar

CRL MBean: CRLの管理に使用できます。

トークン・セキュリティの鍵ペアは、Oracle Access ManagerとOracle Security Token Serviceで共有される共通のキーストアに移入されます。これにより、Oracle Web Services Managerエージェントは共通キーストアと相互作用する必要がなくなります。

「システム・キーストア(.oamkeystore)パスワードの取得」で説明されているとおり、WLSTコマンドを使用してキーストアおよびamtruststoreのパスワードを取得できます。

Oracle Web Services Managerのキーストア(default-keystore.jks)について

このトピックでは、システムおよびパートナのキーと証明書を追加するためにOracle WSMエージェントで必要なJKSタイプのキーストアについて説明します。

Oracle Security Token ServiceでOracle WSMエージェント機能を使用してWSポリシーを公開し、インバウンドおよびアウトバウンドWSメッセージのメッセージを保護できます。Oracle WSMでは、個別のキーストアにシステムおよびパートナのキーと証明書が含まれている必要があります。

Oracle WSMエージェントは、様々な暗号化操作のためにキーストアを使用します。これらのタスクの場合、Oracle Web Services Manager AgentではOracle Web Services Managerタスク用に構成されたキーストア(OWSM秘密鍵とOWSM信頼証明書を含む)が使用されます。OPSSモジュールでは、証明書の検証操作のためにOracle Web Services Managerで使用されるキーストア・サービスが公開され、$DOMAIN_HOME/config/fmwconfig/jps-config.xmlにはキーストア・サービス用の設定が追加されます。デフォルト名はdefault-keystore.jksであり、jps-config.xmlで指定されます。

Oracle WSMエージェント・キーストアとOracle Access ManagerおよびOracle Security Token Serviceキーストアは常に異なるものにすることをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Oracle Access Managerキーがアクセスされる可能性があります。

注意:
Oracle WSMエージェント・キーストアとOAM/OSTSキーストアを常に別にしておくことをお薦めします。

インストール中、Oracle WSMキーストアが構成されていない場合にインストーラが行うことを次に示します。

- $DOMAIN_HOME/config/fmwconfigフォルダでの新しいキーストアの作成(デフォルト名はdefault-keystore.jks)

- 署名および暗号化操作のためにOWSMで使用される、対応する証明書を持つキー・エントリの作成。このキー・エントリは、orakey別名の下のOWSMキーストアに格納されます。

- CSF内のキーストアおよびキー・エントリのパスワードの格納

キーストアにアクセスするために、場合によっては必要となることを次に示します。

- クライアントに配布するための署名/暗号化証明書の抽出(必要な場合)

- 署名/暗号化キー・エントリの更新または置換

- 信頼できる証明書の追加

関連項目:

- 「WSSプロトコル通信のためのOWSMの構成」

リクエスタ証明書のOPSSキーストアの使用について

(Webサービス・リクエストの一部として受信される証明書トークンとは対照的に)クライアントがSKIなどの参照スキームを使用する特別な場合、リクエスタの証明書をOPSSキーストアに移入する必要があります。これは、キーをOPSSキーストアに手動でプロビジョニングする必要がある、一般的ではないシナリオです。

詳細は、「エージェントとOracle Security Token Serviceについて」を参照してください。

Oracle Security Token Serviceの暗号化/署名鍵の管理

Oracle Security Token Serviceでは、鍵を使用して次の処理が行われます。

- 送信アサーションの署名

- WSSプロトコルで処理されないRSTメッセージに含まれる着信XML暗号化データ(トークン、エントロピなど)の復号化

Oracle Security Token Serviceでは、暗号化証明書および署名証明書の格納に次のキーストアが使用されます。

DOMAIN_HOME/config/fmwconfig/.oamkeystore

タスクの概要: Oracle Security Token Serviceのキーの管理

1. システム・キーストア(.oamkeystore)・パスワードの取得

2. システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

3. Oracle Security Token Service証明書の抽出

関連項目:
「WSSプロトコル通信のためのOWSMの構成」

システム・キーストア(.oamkeystore)・パスワードの取得

次の手順を使用すると、キーストアおよびキー・エントリを保護するパスワードを表示できます。

キーストアがIM/OAM/OSTSインストーラによって作成および構成された場合、キーストア・パスワードおよびキー・エントリ・パスワードをCSFから取得する必要があります。それ以外の場合、管理者はキーストアまたはキー・エントリを変更できません。

システム・キーストア(.oamkeystore)・パスワードを取得する手順

1. WSLTスクリプト環境を入力します。

2. connect()コマンドを使用してWebLogic Server AdminServerに接続します。

3. AdminServerに接続情報を提供することにより、コマンドlistCred(map="OAM_STORE", key="jks")を実行します。

4. パスワードを書き留めます。

システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

管理者は、次の手順を使用して、新しいキー・エントリを作成および追加するkeytoolコマンドを使用してシステム・キーストア(.oamkeystore)に新しいキー・エントリを追加できます。エントリを追加した後、アサーションの署名および着信メッセージの復号化に使用できるように、エントリをOracle Security Token Serviceの構成画面で定義する必要があります。

このトピックでは、新しいエントリを追加する次の手順により、SAMLアサーションの署名、またはWSSに含まれないXML暗号化データの復号化を実行します。

- 新しいエントリの追加

- 署名鍵を使用するためのSAML発行テンプレートの構成

- デフォルトの暗号化鍵の設定

新しいエントリの追加

前提条件

システム・キーストア(.oamkeystore)・パスワードの取得

新しいエントリを構成する手順

1. keytoolを探します。

2. 次のコマンドを実行します。

keytool -importcert -trustcacerts -keystore $DOMAIN_HOME/config/fmwconfig/de
fault-keystore.jks -storetype JKS -alias $TRUSTED_CERT_ALIAS -file $TRUSTED_
CERT_ALIAS

3. 画面のメッセージを確認します。

4. 必要に応じて次の手順に進みます。

- 「署名鍵を使用するためのSAML発行テンプレートの構成」(必要な場合)

- 「デフォルトの暗号化鍵の設定」(必要な場合)

署名鍵を使用するためのSAML発行テンプレートの構成

有効な管理者の資格証明を持つユーザーは、署名鍵を使用するように既存のテンプレートを編集する場合に、この手順をガイドとして使用できます。

関連項目:

- トークン発行テンプレートの管理について

- 既存のテンプレートの検索

署名鍵を使用するようにSAML発行テンプレートを構成する手順

1. 既存のトークン発行テンプレートのリストを表示します。
Oracle Access Managerコンソール
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート

2. 新しい鍵を使用するSAML発行テンプレートを検索して開きます。たとえば、saml11-issuance-templateなどです。

3. SAML発行テンプレートページで、「セキュリティ」タブをクリックします。

4. 「セキュリティ」タブの「署名と暗号化」セクションで、「アサーションの署名」をクリックします。

5. 「署名キーストア・アクセス・テンプレートID」リストから、署名キーストア・エントリとして「キーID」を選択します。

6. ページの上部にある「適用」ボタンをクリックしてこの情報を保存します。

7. 必要に応じて、「デフォルトの暗号化鍵の設定」に進みます。

デフォルトの暗号化鍵の設定

有効な管理者の資格証明を持つユーザーは、署名鍵を使用するように既存のテンプレートを編集する場合に、この手順をガイドとして使用できます。

関連項目:
「「セキュリティ・トークン・サービスの設定」について」

デフォルトの暗号化鍵を設定する手順

1. 「セキュリティ・トークン・サービスの設定」ページに移動します。
Oracle Access Managerコンソール
システム構成
セキュリティ・トークン・サービス
セキュリティ・トークン・サービスの設定

2. 「デフォルト暗号化テンプレート」リストから、新しいキー・エントリを選択します。

3. ページの上部にある「適用」ボタンをクリックしてこの情報を保存します。

4. 「デフォルトの暗号化鍵の設定」に進みます。

Oracle Security Token Service証明書の抽出

場合によっては、SAML署名操作またはXML暗号化操作に使用されるOracle Security Token Serviceキーを配布する必要があります。

- Oracle Security Token Serviceにより発行されたSAMLアサーションを検証するために、リライイング・パーティがOracle Security Token Service署名鍵にアクセスする必要がある場合

- トークンをOracle Security Token Service Server用に暗号化する必要がある場合

SAML署名操作またはXML暗号化操作のためにOracle Security Token Serviceで使用されるキー・エントリの証明書を配布するには、(「システム構成」>「セキュリティ・トークン・サービス」>「セキュリティ・トークン・サービスの設定」セクションにリストされる)キーIDおよび優先エンコーディング(derとpem)を指定して、証明書取得サービスを使用します。詳細は、「証明書取得サービスの使用」を参照してください。

証明書取得サービスの使用

証明書取得サービスを使用する手順

1. (「Oracle Access Managerコンソール」の「システム構成」タブ、「セキュリティ・トークン・サービス」セクション、「セキュリティ・トークン・サービスの設定」にリストされる)証明書を取得するエントリのキーIDを取得します。

2. URLを作成します。たとえば、http(s)://osts-hostname:osts-port/sts/servlet/samlcert?id=<KEYID>&encoding=<ENCODING>などを作成し、次のものを指定します。

- エントリのキーIDを保持するID

- 証明書が返されるフォーマットを表すエンコーディング。使用可能な値はpem (PEMフォーマット)またはder (DERフォーマット)です(オプション、デフォルト値はpem)。

3. ブラウザに返された証明書を確認します。

WS-Trust通信のパートナ・キーの管理

この項の内容は次のとおりです。

- パートナ証明書について

- 実行時のリライイング・パーティの証明書のダウンロードについて

- パートナの署名証明書または暗号化証明書の設定

パートナ証明書について

WS-Trustメッセージの処理中に、Oracle Security Token Serviceではパートナ証明書を使用することが必要となる場合があります。表18-4に示すように、必要な証明書は状況によって異なります。

表18-4 WS-Trust通信のパートナ・キー

OSTSサーバーによる発行が必要となった場合

サーバーによる処理

リライイング・パーティ用に暗号化されたSAMLアサーションの発行

リライイング・パーティの暗号化証明書を使用して、送信トークンを暗号化します。

Holder of Key/非対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リクエスタ・パートナの署名証明書をアサーションに含まれる証明鍵として使用します。

注意: 署名に使用されたSOAPヘッダー内のX.509バイナリ・セキュリティ・トークンを参照するUseKey要素がWS-Trust RSTに含まれている場合、Oracle Security Token Serviceではこの証明書を証明鍵として使用できます。

Holder of Key/対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リライイング・パーティの暗号化証明書を使用して、アサーションに含まれる秘密証明鍵を暗号化します。

Holder of Key/対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リクエスタ、秘密またはサーバー・エントロピのRSTRで暗号化できます。

この場合、サーバーは次の処理を行います。

- リクエスタの暗号化証明書を使用して秘密を暗号化(秘密がサーバー・エントロピのみを使用して生成された場合)

- またはサーバー・エントロピを使用してRSTR内の秘密を暗号化(秘密がクライアントおよびサーバー・エントロピから導出された場合)

注意: 署名に使用されたSOAPヘッダー内のX.509バイナリ・セキュリティ・トークンを参照するProofEncryption要素がWS-Trust RSTに含まれている場合、Oracle Security Token Serviceではこの証明書を使用して、クライアントに返された秘密またはエントロピを暗号化できます。

着信SAMLアサーションの検証

発行局の署名証明書を使用して、アサーションに存在するXMLデジタル署名を検証します。

実行時のリライイング・パーティの証明書のダウンロードについて

Oracle Security Token Serviceは実行時に、RSTのAppliesToフィールドにリストされるサービスのリライイング・パーティWSSポリシーをダウンロードできます。Oracle Security Token Serviceがリライイング・パーティのWS-Secポリシーをダウンロードするように構成されている場合は、Oracle Security Token Serviceがリライイング・パーティに接続できるように、必要に応じてプロキシ設定が正しく入力されていることを確認します。

リライイング・パーティ・パートナ・プロファイルがそのように構成されている場合、Oracle Security Token Serviceに対してサービスからWS-Secポリシーをダウンロードするように指示されます。その後、Oracle Security Token Serviceではポリシーに存在する証明書を抽出し、必要に応じて暗号化操作に使用します。また、次の点にも注意が必要です。

- Oracle Security Token Serviceがリライイング・パーティに対して暗号化されたSAMLアサーションを発行する場合、サーバーではリライイング・パーティのWS-Secポリシーからダウンロードされた証明書を使用して送信トークンが暗号化されます。

- Oracle Security Token ServiceがHolder of Key/対称タイプのサブジェクト確認を使用してSAMLアサーションを発行する場合、Oracle Security Token Serviceではリライイング・パーティのWS-Secポリシーからダウンロードされた証明書を使用して、アサーションに含まれる秘密証明鍵が暗号化されます。

リライイング・パーティ・パートナ・プロファイルが実行時に証明書をダウンロードするように構成するには、「パートナの署名証明書または暗号化証明書の設定」を参照してください。

パートナの署名証明書または暗号化証明書の設定

パートナの署名証明書または暗号化証明書を設定するには、次の操作を実行します。

または、WLSTパートナ・コマンドを使用して、特定のパートナの署名証明書または暗号化証明書を設定します。

前提条件

表18-4「WS-Trust通信のパートナ・キー」を確認します。

パートナの証明書を設定する手順

1. 「Oracle Access Managerコンソール」の「システム構成」タブの「セキュリティ・トークン・サービス」セクションで、「パートナ」ノードを展開します。

2. 「パートナ」ノード内で、「リクエスタ」(または、「リライイング・パーティ」または「発行局」(表18-4を参照))を展開します。

3. 証明書を設定する必要があるパートナを検索して開きます(または作成します)。

4. 必要に応じて「パートナ」設定を編集(「Token Serviceパートナの管理」を参照)し、「保存」をクリックします。

5. 暗号化証明書: 「参照」ボタンをクリックし、暗号化証明書を検索して選択します。

6. 署名証明書: 「参照」ボタンをクリックし、署名明書を検索して選択します。

7. 情報を保存してページを閉じます。

8. 「証明書検証の管理」に進みます。

証明書検証の管理

この項では、証明書検証の管理について説明します。証明書検証の条件は、表18-5で説明されています。

表18-5 Oracle Security Token Serviceの証明書検証の条件

OSTSによって証明書が検証される場合...

検証されるセキュリティ・トークンは次のタイプのいずれかです。

- X.509

- X.509v3

- PKCS#7

SAMLアサーションを検証する必要があります。

OSTSはSAML発行局の署名証明書を検証するように構成されます。

検証が成功するための要件を表18-6に示します。

表18-6 証明書検証が成功するための要件

証明書が次の状態であること

方法...

信頼できるアンカーにリンクされていること:

- 信頼できるアンカーになる

- または発行者を信頼できるアンカーにする

取り消されていないこと:

- 信頼できるアンカーになる

- または発行者を信頼できるアンカーにする

証明書の取消ステータスは、次のものを確認することで判断できます。

- 管理者によってアップロードされたCRLのリスト

- OCSPサーバー

- CRL配布ポイント

証明書検証には信頼アンカー・ストア(.amtruststore)が必要です。このストアおよび検証を管理する手順については、次のトピックで説明します。

- 信頼アンカー・ストア(amtruststore)のパスワードの取得

- 信頼アンカー・ストア(amtruststore)の管理

- 証明書失効リストの管理

- Oracle Security Token Serviceのカスタム信頼アンカー・ストアの使用

信頼アンカー・ストア(amtruststore)のパスワードの取得

信頼アンカー・キーストアのパスワードをCSFから取得する必要があります。それ以外の場合、管理者はキーストアを変更できません。ストアは次の場所にあります。

$DOMAIN_HOME/config/fmwconfig/amtruststore

ストアのパスワードを取得するには、次の操作を実行します。これにより、信頼アンカー・キーストアの保護に使用されるパスワードが表示されます。

- WSLTスクリプト環境を入力します。

- WLS管理サーバーに接続情報を提供することにより、コマンドlistCred(map="OAM_STORE", key="jks")を実行します。

信頼アンカー・ストアのパスワードを取得する手順

1. WSLTスクリプト環境を入力します。

2. connect()コマンドを使用してWebLogic Server AdminServerに接続します。

3. AdminServerに接続情報を提供することにより、コマンドlistCred(map="OAM_STORE", key="jks")を実行します。

4. 画面のメッセージを確認してパスワードを書き留めます。

5. 「信頼アンカー・ストア(amtruststore)の管理」に進みます。

信頼アンカー・ストア(amtruststore)の管理

信頼アンカー・キーストアは、keytoolコマンドを使用して管理されます。キーストアに追加された証明書は、証明書検証モジュールによって検出されます。

注意:
通知はJMX通知フレームワークを使用して実行されますが、通知のリフレッシュ時間(デフォルトでは60秒)に応じて時間を要する場合があります。

前提条件

信頼アンカー・ストア(amtruststore)のパスワードの取得

信頼アンカー・ストア(amtruststore)を管理する手順

1. keytoolを探します。

2. 次のコマンドを実行します。

keytool -keystore $DOMAIN_HOME/config/fmwconfig/amtruststore
-storetype JKS -alias orakey -file $CERT_FILE

3. 画面のメッセージを確認し、要求された場合はパスワードを入力します。

4. 「証明書失効リストの管理」に進みます。

証明書失効リストの管理

Oracle Security Token ServiceおよびOracle Access Managerでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Oracle Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。

この項では、証明書の失効ステータスを確認し、次の操作を実行するために証明書失効リスト(CRL)を追加または削除する方法を説明します。

関連項目:
「グローバル証明書の検証および取消の管理」

前提条件

証明書失効リストをインポート可能な状態にします。

タスクの概要: 証明書検証および失効リストの管理

1. Oracle Access Managerコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト(CRL)の管理」を参照してください。

3. 「証明書検証の管理」を参照してください。

4. 「CDPの構成」を参照してください。

Oracle Security Token Serviceのカスタム信頼アンカー・ストアの使用

オプションで、特定のデプロイメントにOracle Access Managerの信頼アンカーとは別の信頼アンカーのセットが必要な場合、別のキーストアをOracle Security Token Serviceの信頼できる証明書ストアとして構成できます。これを実行するには、管理者が次のタスクを実行しておく必要があります。

注意:
カスタム信頼アンカー・ストアの使用は、ほとんどの顧客に不要なオプション機能です。

タスクの概要: 信頼できる証明書のカスタム・キーストアのデプロイ

1. $DOMAIN_HOME/config/fmwconfigディレクトリにJKSキーストアを作成します。

2. 「Oracle Access Managerコンソール」の「セキュリティ・トークン・サービスの設定」ページで、新しい信頼ストアのフルパス名を入力し、変更を適用します。

3. Oracle Access Manager with Oracle Security Token Serviceがデプロイされているドメインで、管理者がカスタム信頼アンカー・キーストアをすべてのサーバーに手動で伝播する必要があります。

19 テンプレート、エンドポイントおよびポリシーの管理

この章では、Oracle Security Token Serviceの次の情報を提供します。

- 前提条件

- 概要

- 既存のテンプレートの検索

- トークン発行テンプレートの管理

- トークン検証テンプレートの管理

- Oracle Security Token Serviceエンドポイントの管理

- Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理

- TokenServiceRPタイプのリソースの管理

前提条件

「Oracle Security Token Serviceの有効化および無効化」の説明に従って、Oracle Access ManagerサービスとOracle Security Token Serviceサービスの両方が実行されている必要があります。

概要

Oracle Security Token Serviceでは、ポリシーに基づいてリソースへのアクセスを定義するアプリケーション・ドメインを定義することで、WSPにアクセスするユーザーの制御がサポートされています。アプリケーション・ドメインは、WSPに基づいてセキュリティ・トークンをリクエストできるユーザーを決定する認可ルールとともにWebサービスを識別します。

次の機能は信頼発行ポリシーによって確立されており、このポリシーは、「Oracle Access Managerコンソール」の「ポリシー構成」タブにある「アプリケーション・ドメイン」を介して管理できます。

- リライイング・パーティまたはWebサービス・プロバイダを表すTokenServiceRPタイプのリソース。

- タイプがTokenServiceRPのリソースのセットに対してポリシーを定義するトークン発行ポリシー。

- ポリシーにリストされてるリソースのトークンの発行を許可または拒否されるクライアントのアイデンティティを定義する制約。クライアントは、リクエスタ・パートナまたはデフォルト・アイデンティティ・ストアからのユーザーです。

Oracle Security Token Serviceでは、Oracle Security Token Serviceにより発行されるセキュリティ・トークンのコンシューマになるリモートWebサービス・プロバイダを表す、リライイング・パーティ・パートナの作成がサポートされています。

WS-Trustリクエストに指定されているWS-AddressingエンドポイントがOracle Security Token Serviceリライイング・パーティ・パートナにマップされるように、リライイング・パーティ・パートナごとに、パートナにマップされるURLを定義できます。

実行時に、クライアントがトークンの発行を要求すると、Oracle Security Token Serviceでは信頼発行ポリシーを評価し、トークンを発行できるかどうかを判断します。

- クライアントはリクエスタ・パートナまたはエンド・ユーザーとして識別されます。

- WS-TrustリクエストにAppliesTo要素が存在し、リライイング・パーティ・パートナにマップされた場合、信頼発行ポリシー評価のTokenServiceRPリソースはOracle Security Token Serviceリライイング・パートナのパートナIDになります。

- WS-TrustリクエストにAppliesTo要素が存在し、リライイング・パーティ・パートナにマップできなかった場合、信頼発行ポリシー評価のTokenServiceRPリソースはOAM Suiteアプリケーション・ドメインに定義されているUnknownRPになります。

- WS-TrustリクエストにAppliesTo要素がない場合、信頼発行ポリシー評価のTokenServiceRPリソースはOAM Suiteアプリケーション・ドメインに定義されているMissingRPになります。

Oracle Security Token Serviceでは、(少なくとも)次の項目がリクエストを処理し、着信リクエスト(RST)に基づいてトークンを発行する必要があります。

- エンドポイント

- 1つの発行テンプレート

- 1つの検証テンプレート

- トークンを含む1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

注意:
パートナのプロビジョニングが必要な場合があります。

ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、その後そのレコードを使用して送信トークンを移入するために、Oracle Security Token ServiceにはLDAPサーバーが必要です。パートナが使用可能になる前に、移入が必要な場合があります。

既存のテンプレートの検索

「トークン検証テンプレート」または「トークン発行テンプレート」ノードを開くと、検索結果の表に定義済のすべてのテンプレート名が表示されます。特定のテンプレートまたはテンプレートのセットを迅速に検索するために、検索コントロールを使用できます。

この項では、検索の絞込みに使用できるコントロールについて説明します。このコントロールは、トークン検証テンプレートとトークン発行テンプレートのどちらを検索する場合も類似しています。内容は次のとおりです。

- テンプレートの検索コントロールについて

- テンプレートの検索

テンプレートの検索コントロールについて

次の図は、多くの類似点がある検索ページを示しています。

- 図19-1「検証テンプレートの検索コントロール」

- 図19-2「発行テンプレートの検索コントロール」

図19-1 検証テンプレートの検索コントロール

「図19-1 検証テンプレートの検索コントロール」の説明

図19-2 発行テンプレートの検索コントロール

「図19-2 発行テンプレートの検索コントロール」の説明

表19-1に、テンプレート検索の絞込みに使用できるコントロールを示します。特に明記しないかぎり、すべての要素を検証テンプレートと発行テンプレートの両方の検索に使用できます。

表19-1 テンプレート検索コントロール

要素

説明

一致

「すべて」を選択して、指定のすべてに一致するテンプレートを検索します。

「任意」を選択して、少なくとも1つの指定に一致するテンプレートを検索します。

検索操作リスト

検索を絞り込むために選択する操作のリスト。

...テンプレート名

リストから操作を選択し、検索の絞込みに役立つ情報をフィールドに入力します。

説明

オプションの説明フィールドを使用して検索を絞り込みます。

トークン・プロトコル

検証テンプレートのみ

リストされているプロトコルからトークン・プロトコルを選択します。

- WS-Trust

- WS-Security

トークン・タイプ

トークン・タイプを選択します。標準とカスタムの両方のトークン・タイプがあります。

- ユーザー名: 消費および作成

- X.509: 消費

- SAML: 消費および作成

- OAM 11g: OBO (代理)フィールドを使用する消費

- Kerberos: 消費

- カスタム: OBO (代理)フィールドを使用する消費および作成

検索

フォームの基準を使用して検索機能を開始します。

リセット

デフォルトのみで「検索」フォームをリセットします。

フィールドの追加

検索基準として追加できる追加項目のリスト。

「検索結果」表

この表の後半に説明されているように、「表示」メニューの選択内容に基づいて検索の結果を項目化します。

「アクション」メニュー

表示: 検証テンプレート用のアクション

結果表の選択項目で実行できる次の機能を提供します。

注意: 「アクション」メニューの機能は、結果表の上のコマンド・ボタンをミラー化します。次に例を示します。

- 新規 ... テンプレート: 「検索」ページの上にある新規 ... テンプレート・ボタンをクリックするか、メニューから新規 ... テンプレートを選択するか、表の上にある「+」ボタンをクリックします。

- 編集: 結果表の名前をクリックするか、「アクション」メニューから「編集」を選択するか、結果表の上にある「編集」(鉛筆)コマンド・ボタンをクリックします。

- 類似作成: 表の目的の行を選択し、「アクション」メニューから「類似作成」を選択するか、表の上にある「類似作成」コマンド・ボタンをクリックします。

- 削除: 結果表の目的の行を選択し、「アクション」メニューから「削除」を選択するか、表の上にある「削除」(X)コマンド・ボタンをクリックします。

「表示」メニュー

検証テンプレートのみ

結果表に表示する情報を識別できるリスト。

「表示」メニュー

発行テンプレートのみ

結果表に表示する情報を識別できるリスト。

結果表にリストされる項目の順序を定義するために選択できるコントロール:

- 昇順

- 降順

テンプレートの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、特定のテンプレートまたはテンプレートのセットを検索するために検索コントロールを使用できます。たとえば、特定のトークン・タイプのすべてのテンプレートを検索するには、単にそのトークンのタイプを選択します。特定のトークン・タイプおよび名前のすべてのテンプレートに検索を絞り込むことができます。

これらの手順を実行する場合、必要に応じてできるだけ多く、またはできるだけ少なく情報を入力します。該当しない手順はスキップしてください。

関連項目:
「テンプレートの検索コントロールについて」

テンプレートを検索する手順

1. 「システム構成」タブから「Secure Token Serviceの設定」セクションを展開します。

2. ナビゲーション・ツリーで、目的の「テンプレート」ノードをダブルクリックします。たとえば、「トークン検証テンプレート」など。

3. 検索条件を編集します(表19-1)。次に例を示します。

- 一致: 「すべて」

- 名前: 「次を含む」、em

- トークン・タイプ: 「次と等しい」、ユーザー名

4. 「検索」をクリックして結果を確認します。

トークン発行テンプレートの管理

発行テンプレートには、トークンの作成方法に関するルールが含まれており、トークン・タイプに固有のものです。発行テンプレートはそれぞれ署名および暗号化を示しており、トークンの一部として送信される属性名、値マッピングおよびフィルタリング設定も含まれています。

この項の内容は次のとおりです。

- トークン発行テンプレートの管理について

- トークン発行テンプレートの管理

トークン発行テンプレートの管理について

トークン発行テンプレートはそれぞれ、トークンの構築方法を示しています。つまり、トークンの構築時に使用される署名または暗号化を示しています。各トークン発行テンプレートでは、送信トークンに含まれる属性に適用される属性マッピングおよびフィルタリング・ルールも定義されます。ただし、発行テンプレートには、送信トークンで送信される属性はリストされません。これはリライイング・パーティ・パートナ・プロファイルで定義されます。

トークン発行テンプレートには、選択したトークン・タイプに応じて異なる点の詳細が表示されます。表19-2に、詳細が記載されている場所を示します。

表19-2 発行テンプレートの要件

トピック

図および表

一般詳細

図19-3、表19-3

発行プロパティ: ユーザー名トークン

図19-4、表19-4

発行プロパティ: SAMLトークン

図19-5、表19-6

セキュリティ: SAMLトークン

図19-6、表19-6

属性マッピング: SAMLトークン

図19-9、表19-7

一般詳細

図19-3に、デフォルトが表示されている状態の「新規発行テンプレート」ページを示します。特に明記しないかぎり、「一般情報」は、選択するトークン・タイプドを問わず同じです。詳細は、表19-3を参照してください。「一般情報」を入力して「保存」をクリックした後、テンプレート名またはトークン・タイプに戻って編集することはできません。

図19-3 発行テンプレート: 一般詳細とデフォルト

「図19-3 発行テンプレート: 一般詳細とデフォルト」の説明

表19-3 発行テンプレート: 一般詳細

要素

説明

発行テンプレート名

このテンプレートの一意の名前を入力します。

説明

オプション。

トークン・タイプ

リストされているタイプから標準(または、ある場合はカスタム)のトークン・タイプを選択します。

SAML、ユーザー名およびカスタムのトークン・タイプ

暗号化されたトークンの送信

クリックしてトークン暗号化を有効にします。

トークン暗号化アルゴリズム

トークン暗号化が有効になっている場合は、リストされているアルゴリズムから「トークン暗号化アルゴリズム」を選択します。

発行プロパティ: ユーザー名トークン・タイプ

トークン・タイプがユーザー名の場合、ユーザー名トークン・タイプ・テンプレートには図19-4に示す発行プロパティが必要です。

図19-4 発行プロパティ: ユーザー名トークン・タイプ

「図19-4 発行プロパティ: ユーザー名トークン・タイプ」の説明

表19-4に、ユーザー名トークン・タイプの発行プロパティを示します。

表19-4 発行プロパティ: ユーザー名トークン・タイプ

要素

説明

名前識別子ユーザー属性

ユーザー名トークンへのUsername要素の移入に使用される属性。

名前識別子ユーザー属性ストア

ユーザー属性ストア・タイプを選択します。

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

パスワード属性

ユーザー名トークンへのPassword要素の移入に使用される属性。

パスワード属性ストア

パスワード属性ストア・タイプを選択します。

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

Nonceを含める

ランダム・データからなるNonceをユーザー名トークンに含めるかどうかを示します。

デフォルト: 無効

タイムスタンプを含める

Created要素をユーザー名トークンに含めるかどうかを示します。

デフォルト: 無効

発行プロパティ: SAMLトークン・タイプ

SAML 1.1および2.0トークン・タイプには、図19-5に示す発行プロパティが必要です。

注意:
これらのプロパティは、ユーザー名トークン・タイプのプロパティとは異なります。

図19-5 発行プロパティ: SAMLトークン・タイプ

「図19-5 発行プロパティ: SAMLトークン・タイプ」の説明

表19-5に、すべての発行プロパティをトークン・タイプ別に示します。発行プロパティが必要なのは、SAMLトークン・タイプのみです。

表19-5 発行プロパティ: SAMLトークン・タイプ

要素

説明

アサーション発行者

アサーションの発行者を表す識別子を指定します。この文字列は、このOracle Security Token Serviceをアサーションの発行者として表すために使用されます。

名前識別子フォーマット

リストからフォーマットを選択した後、テキスト・フィールドに詳細を入力します。

名前識別子修飾子

「名前識別子修飾子」として設定される文字列を含みます。

名前識別子ユーザー属性

名前識別子の値の移入に使用される属性を参照します。

名前識別子ユーザー属性ストア

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

認証文を含める

SAML認証文をアサーションに含めるかどうかを示します。

デフォルト: 無効

注意: このタイプの文を含めるには認証操作が必要です。着信トークンに一部の認証データが含まれ、そのデータが検証される場合、認証文が含まれます(たとえば、着信SAMLアサーションに認証文が含まれるか、ユーザー名トークンに検証済の資格証明が含まれます)。

属性文を含める

SAML属性文を送信アサーションに含めるかどうかを示します。

このタイプの文が含まれるのは、このフラグがtrueに設定され、少なくとも1つの属性が送信アサーションに含まれる場合のみです。

デフォルト: 有効

注意: RP PPは、送信トークンに含める必要がある属性を決定します。

有効期間

トークンが有効な時間の長さ(秒)を指定します。

デフォルト: 3600(秒)

「セキュリティ」の詳細: SAMLトークン

図19-6および表19-6に示すように、SAMLトークン・タイプにのみ「セキュリティ」の詳細が必要です。

図19-6 「セキュリティ」の詳細: SAMLトークン

「図19-6 「セキュリティ」の詳細: SAMLトークン」の説明

表19-6 「セキュリティ」の詳細: SAMLトークン

要素

説明

署名と暗号化

「署名キーストア・アクセス・テンプレートID」フィールドで参照されるキーを使用して、アサーションに署名するかどうかを示します。

アサーションの署名

アサーションに署名証明書が含まれるかどうかを示します。

デフォルト: 有効

署名に証明書を含める

デフォルト: 有効

署名キーストア・アクセス・テンプレートID

この発行テンプレートで作成されたアサーションに署名するために使用されるキーを参照します。キー・テンプレートは、「セキュリティ・トークン・サービスの設定」セクションで定義されます。

サブジェクト確認

デフォルト・サブジェクト確認メソッド

リクエスタがWS-Trustリクエストでメソッドを指定しなかった場合、デフォルトで使用される「サブジェクト確認メソッド」を示します。可能な値は次のとおりです。

- ベアラー

- 「公開鍵」を使用するHolder of Key

- 「対称鍵」を使用するHolder of Key

- 送信者保証

Holder-of-Key対称鍵の計算

デフォルト: 有効

Holder of Key対称鍵データの秘密鍵の作成時に、Oracle Security Token Serviceでランダム・データが生成されるかどうかを示します。

- trueの場合、クライアントによってエントロピが指定されなければ、サーバーによって秘密鍵が生成されます。それ以外の場合は、クライアントおよびサーバーのエントロピから鍵が導出されます。

- falseの場合、クライアント・エントロピが秘密鍵として使用されます。

RSTR証明トークンの暗号化

WS-Trustレスポンス内のリクエスタにサーバー・エントロピまたは秘密鍵を返すときに、「サブジェクト確認メソッド」が対称鍵付きHolder of Keyの場合、証明トークンを暗号化する必要があるかどうかを示します。

デフォルト: 無効

Holder-of-Key対称鍵生成アルゴリズム

「サブジェクト確認メソッド」が「対称鍵」を使用するHolder of Keyの場合、秘密鍵の作成に使用する対称鍵生成アルゴリズムを示します。

属性マッピング: SAMLトークン

トークン・タイプがSAML 1.1または2.0の場合、アサーションに含まれる属性に適用される属性マッピングおよびフィルタ・ルールを定義できます。

3種類のルールがあります。

- 属性のローカル名を別の値に変更できる属性名マッピング。たとえば、givennameをfirstnameに変更できます。

- 属性のローカル値を別の値に変換できる属性値マッピング。たとえば、PresidentをCEOに変更できます。

- 属性のローカル値をフィルタ処理して送信アサーションに含まれないようにする属性値フィルタリング。たとえば、削除されるセンシティブ属性値もあれば、発行される属性値もあります。

関連項目:
図19-9および表19-11のトークン・マッピング属性。

表19-7 発行テンプレート: 属性マッピング、SAMLトークン

要素

説明

属性名マッピング

属性のローカル名とアサーション内のこの属性の参照に使用される名前の間のオプション・マッピングを定義します。

マッピングはオプションです。属性にマッピングが定義されていない場合は、属性のローカル名が使用され、ネームスペースがurn:oracle:security:fed:attrnamespace (SAML 1.1アサーションの場合)に設定されるか、またはフォーマットがurn:oasis:names:tc:SAML:2.0:attrname-format:basic (SAML 2.0アサーションの場合)に設定されます。

- 外部属性: アサーションに表示される属性の外部名を含みます。

- ローカル属性: 属性のローカル名を含みます。

- フォーマットまたはネームスペース: オプションのフォーマットまたはネームスペースを含みます。存在しない場合、ネームスペースがurn:oracle:security:fed:attrnamespace (SAML 1.1アサーションの場合)に設定されるか、またはフォーマットがurn:oasis:names:tc:SAML:2.0:attrname-format:basic (SAML 2.0アサーションの場合)に設定されます。

属性値マッピング

アサーションに含まれる属性の、オプションの値マッピングを定義します。

注意: この属性値マッピングは、属性名マッピングに適用されます。属性の属性マッピングを定義するには、まずその属性の属性名マッピングを定義する必要があります。

- 外部属性: ローカル属性値が「ローカル属性」/「ローカルNULL」フィールドと一致する場合、アサーションに含める値が含まれます。

- ローカル属性: 属性のローカル値を含みます。

- 外部NULL: アサーションに含まれる値をnullにするかどうか、属性のローカル値が「ローカル属性」/「ローカルNULL」フィールドと一致するかどうかを示します。

- ローカルNULL: nullのローカル値を表します。

- 大/小文字区別なし: 属性値を「ローカル属性」フィールドと比較するときに、Oracle Security Token Serviceで大/小文字が区別されるかどうかを示します。

属性値フィルタ

アサーションに含まれる属性の、オプションの値フィルタリングを定義します。

注意: この属性値フィルタリングは、属性名マッピングに適用されます。属性の属性フィルタリングを定義するには、まずその属性の属性名マッピングを定義する必要があります。

- 条件: 属性値がフィルタ処理されるかどうかを判断する式に関連付けられた条件を含みます。使用可能な値は、「属性値の条件フィルタ」で説明されています。

- 式: フィルタリング・ルールの評価に使用されるデータを含みます。

- 大/小文字区別なし: 属性値を式フィールドと比較するときに、Oracle Security Token Serviceで大/小文字が区別されるかどうかを示します。

属性値の条件フィルタ

このオプションの値フィルタリングは属性名マッピングに適用され、アサーションに含まれます。属性の属性フィルタリングを定義するには、まずその属性の属性名マッピングを定義する必要があります。「条件」は、属性値がフィルタ処理されるかどうかを判断する式に関連付けられます。使用可能な「条件」の値は次のとおりです。

- regexp: 式には正規表現が含まれ、trueと評価された場合、属性値がフィルタ処理されます。

- equals: 属性値が式フィールドに含まれるデータと一致する場合、属性値はフィルタ処理されます。

- not-equals: 属性値が式フィールドに含まれるデータと一致しない場合、属性値はフィルタ処理されます。

- not-equals: 属性値が式フィールドに含まれるデータと一致しない場合、属性値はフィルタ処理されます。

- endswith: 属性値が式フィールドに含まれるデータで終了する場合、属性値はフィルタ処理されます。

- contains: 式フィールドに含まれるデータが属性値に出現する場合、属性値はフィルタ処理されます。

- not-contains: 式フィールドに含まれるデータが属性値に出現しない場合、属性値はフィルタ処理されます。

- equals-null: 属性値がnullの場合、フィルタ処理されます。

- not-equals-null: 属性値がnull以外の場合、フィルタ処理されます。

トークン発行テンプレートの管理

有効な管理者の資格証明を持つユーザーは、新しいトークン発行テンプレートを開発する(または既存のテンプレートを編集する)場合に、この手順をガイドとして使用できます。該当しない手順はスキップしてください。

次の手順では、Security Assertion Markup Language (SAML)トークンの新しいトークン発行テンプレートを作成する方法を説明します。

前提条件

目的のLDAPアイデンティティ・ストアがOracle Access Managerに登録され、デフォルト・アイデンティティ・ストアとして構成されていることを確認します。

関連項目:

- トークン発行テンプレートの管理について

- 既存のテンプレートの検索

新しいトークン発行テンプレートを作成する手順

1. 既存のトークン発行テンプレートのリストを表示します。
Oracle Access Managerコンソール
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート

2. 新しいトークン発行テンプレート:

1. 右上隅の「新規発行テンプレート」ボタンをクリックします(または、「検索結果」表の上にある「追加」(+)コマンドをクリックします)。

2. 一般: このテンプレートの一般情報を定義し、次のものを表示します。
表19-3「発行テンプレート: 一般詳細」

3. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

4. ユーザー名トークン・タイプ: このテンプレートの発行パラメータを定義し、次のものを表示します。
表19-4「発行プロパティ: ユーザー名トークン・タイプ」

5. SAMLトークン・タイプ: このテンプレートのパラメータを定義し、次のものを表示します。
表19-5「発行プロパティ: SAMLトークン・タイプ」

表19-6「「セキュリティ」の詳細: SAMLトークン」

表19-7「発行テンプレート: 属性マッピング、SAMLトークン」

6. 「適用」をクリックします(または保存せずに「元に戻す」をクリックします)。

7. 定義を閉じます。

3. 既存のテンプレートの検索: 「システム構成」タブの「セキュリティ・トークン・サービス」セクションから次の手順を実行します。

1. すべて検索: 「トークン発行テンプレート」ノードをダブルクリックし、結果表を確認します。

2. 検索の絞込み: 検索条件(表19-1)を指定し、「検索」ボタンをクリックして結果表を確認します。

3. 検索フォームのリセット: 「リセット」ボタンをクリックします。

4. テンプレートの編集: 作成した保存済のページから編集を開始します。
または、ステップ3を使用して目的のテンプレートを検索し、「検索結果」表の名前をクリックして定義を表示します。

1. 必要に応じて詳細を編集します。

2. ページの上部にある「適用」ボタンをクリックし、変更を送信します(または「元に戻す」をクリックして変更を取り消します)。

5. テンプレートの削除:

1. 「検索結果」表の目的の名前をクリックし、削除する項目を選択します。

2. 「アクション」メニューの「削除」をクリックします(または、表の上にある「削除」(X)コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

トークン検証テンプレートの管理

検証テンプレートを使用して、着信トークンを検証したり、オプションでリクエスタ・パートナまたはユーザー・レコードに着信トークンをマップします。

- OnBehalfOfユースケースの場合、WS-Trust検証テンプレートが存在する必要があります。

- アサーションを検証するためには、発行局パートナ・プロファイルが存在する必要があります。

Oracle Security Token Serviceエンドポイントは、WSSヘッダー内のトークンを検証する方法、およびトークンとバインディング・データをリクエスタにマップする方法を示すWSS検証テンプレートにリンクされます。

この項の内容は次のとおりです。

- トークン検証テンプレートの管理について

- トークン検証テンプレートの管理

トークン検証テンプレートの管理について

Oracle Security Token Serviceエンドポイントは常に、リクエストをリクエスタ・エントリまたはユーザーにマップする方法を示すWS-Security検証テンプレートでマップされます。

- マッピングが必要で一致が見つからない場合、処理は失敗します。

- マッピングが不要な場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。

- どちらの場合も、リクエスタ・パートナ・プロファイルが取得されます。

- ユーザー・レコードへのマッピングが実行される場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。

- リクエスタ・パートナ・エントリへのマッピングが実行される場合は、このパートナのリクエスタ・パートナ・プロファイルが使用されます。

検証テンプレートによってトークン検証ルールが決定されます。

- 着信トークンを検証およびマップするかどうか。

- マッピングが有効な場合に使用されるマッピング・ルール。

表19-8に示すように、検証テンプレートはトークン・タイプおよびプロトコルに固有です。

表19-8 検証テンプレートのプロトコル

プロトコル

説明

WS-Security

WS-Securityトークンのみを検証:

- 使用可能なマッピング・アクション: アクションなし、パートナへのバインディング・データのマップ、パートナへの着信トークンのマップ、ユーザーへの着信トークンのマップ、パートナへのバインディング・データのマップ、ユーザーへの着信トークンのマップ

- サポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、なし。

トークン・プロトコルをWS-TrustからWS-Securityに切り替えても、「トークン・タイプ」リストのオプションは変更されません。ただし、必要な「デフォルト・パートナ・プロファイル」リストが表示され、ここからWS-Securityのプロファイルの1つを選択する必要があります。

WS-Trust

RST (リクエスト)のOBO (代理)フィールドに含まれるトークンのみを検証:

- 使用可能なマッピング・アクション: なし、ユーザーへの着信トークンのマップ

- サポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、OAM、カスタム。

検証テンプレートのマッピング・ルールは、着信トークンからのデータを使用して、ユーザーまたはパートナへの着信データのマップ方法を決定します。

- ユーザー名トークンのユーザー名

- KerberosトークンのユーザーID

- SAMLトークンの名前IDおよび属性

- X.509トークンのDNコンポーネント

- カスタムからの属性

マッピングは次のように実行されます。

- 簡易マッピング: ある着信属性をユーザー・レコード属性と照合

- 複雑なLDAP問合せ: 着信データのプレースホルダを含むLDAP問合せ(例: (&(sn=%lastname%)(mail=%email%))

- SAMLトークンの名前IDマッピング表

図19-7に、「新規検証テンプレート」ページのデフォルトの一般詳細を示します。

図19-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト

「図19-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト」の説明

表19-9に、「新規検証テンプレート」の「一般」ページの要素を示します。

表19-9 新規検証テンプレート: 一般詳細

要素

説明

戻る

前のページに戻るには、このボタンをクリックします。

次

次のページに進むには、このボタンをクリックします。

取消

ページを閉じるには、このボタンをクリックします。

検証テンプレート名

このテンプレート用に選択する名前。次に例を示します。

email-wstrust-valid-temp

説明

オプション。

トークン・プロトコル

作成される検証テンプレートのタイプ。タイプは次のいずれかになります。

- WS-Trust: このテンプレートは、WS-TrustリクエストのOnBehalfOf要素に含まれるトークンを検証およびマップするために使用されます。

- WS-Security: このテンプレートは、着信メッセージのSecurity SOAPヘッダーにあるトークンを検証およびマップするために使用されます。

トークン・タイプ

このテンプレートに使用するトークン・タイプを選択するインバウンド・トークン・タイプのリスト。トークン・タイプのオプションはプロトコル・タイプによって異なります。

- WS-Trust: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、OAM、カスタム

- WS-Security: SAML 1.1、SAML 2.0、ユーザー名、X,509、Kerberos、なし

デフォルト・パートナ・プロファイル

WS-Security検証テンプレートにのみ適用されます。

着信リクエストがリクエスタ・パートナにマップされない場合、使用するデフォルトのリクエスタ・パートナ・プロファイルを参照します。たとえば、かわりにリクエストがユーザーにマップされる場合などです。

リクエスタ・パートナ・プロファイルには、リクエスト処理中に使用される設定が含まれています。着信リクエストがリクエスタ・パートナにマップされた場合、そのリクエスタのパートナ・プロファイルが取得され、リクエスタ・パートナ・プロファイルとして使用されます。

タイムスタンプの存続期間

ユーザー名およびSAML検証テンプレートにのみ適用されます。トークンの有効性を決定します(ユーザー名トークンの場合は、作成された瞬間を示すCreated要素が含まれている場合のみ)。

デフォルト: 1000(秒)

認証の詳細

ユーザー名トークン検証テンプレートに固有です。

資格証明検証の有効化

ユーザー名トークンに含まれる資格証明を使用して検証を有効にするには、このボックスを選択します。

有効にすると、Oracle Security Token Serviceでは、指定された検証ソースを使用して、ユーザー名トークンに含まれるusernameおよびpassword要素が検証されます。

注意: ユーザー名トークンのWS-Securityプロファイルに定義されているパスワード・ダイジェストは、このリリースではサポートされていません。

関連項目: 表19-10「新規検証テンプレート: 認証の詳細」

図19-8に、「資格証明検証の有効化」を選択し、そのページの「認証の詳細」セクションにデフォルト値が表示されている状態の「一般」詳細ページを示します。これは、ユーザー名トークン検証に固有です。

図19-8 新規検証テンプレート: 「一般」の「認証の詳細」

「図19-8 新規検証テンプレート: 「一般」の「認証の詳細」」の説明

表19-10に、「資格証明検証の有効化」を選択した場合に使用できる認証関連の詳細を示します。

表19-10 新規検証テンプレート: 認証の詳細

要素

説明

検証ソース

資格証明検証ソースを選択できるリスト

ユーザー名トークンに含まれる資格証明を検証する場合、次に示す4つのタイプの検証ソースがあります。

- LDAP: 資格証明の検証にはスタンドアロンLDAPサーバーが使用されます。接続情報を入力する必要があります。

- 組込みLDAP: 資格証明の検証には、WebLogicサーバーに組み込まれたLDAPサーバーが使用されます。情報を入力する必要はありません。

- UserStore: 資格証明の検証には、「共通構成」->「データソース」で構成されているデフォルトのユーザー・アイデンティティ・ストアが使用されます。この検証テンプレート画面で情報を入力する必要はありません。

- パートナ: 資格証明は、「リクエスタ・パートナ」エントリに入力されたユーザー名/パスワード情報に対して検証されます。
注意: 選択した場合、「トークン・マッピング」構成セクションが無効になります。これは、資格証明の検証操作後にトークンがリクエスタ・パートナにマップされているためです。

LDAP URL

LDAPサーバーのURL。

管理者ユーザー

LDAPサーバーの参照に使用されるアカウントのユーザー名。

管理者パスワード

LDAPサーバーの参照に使用されるアカウントのパスワード。

ベースDN

ユーザー・レコードの参照時に使用される基本検索DN。

HAの有効化

LDAPサーバーがHAモードで、前にロード・バランサがあるかどうかを示します。

個人オブジェクト・クラス

ユーザー・レコードに関連付けられた個人オブジェクト・クラス。

一意のID

ユーザーの一意の識別子データを含むユーザー・レコードの属性。ほとんどの場合、「資格証明ID」フィールドと同じです。

資格証明ID

ユーザー名データを含むユーザー・レコードの属性。このフィールドは、ユーザー名に基づいてユーザー・レコードを参照するために使用されます。

最大接続数

開いている同時LDAP接続の最大数。

デフォルト: 40

接続待機タイムアウト

新しい接続を開くときに待機する最大時間。

デフォルト: 5(秒)

接続の非アクティブのタイムアウト

LDAP接続を閉じるまでの非アクティブの最大時間。

デフォルト: 300(秒)

接続の読込みのタイムアウト

開いている同時LDAP接続の最大数。

デフォルト: 10(秒)

トークン・マッピング

「トークン・マッピング」セクションは次の内容を示します。

- 着信トークンをマップする必要があるかどうか。

- 着信トークンをマップする必要があるかどうか、実行されるマッピングの種類。たとえば、ユーザーへのトークンのマッピング、パートナへのトークンのマッピングなどです。

- マッピングの実行方法。たとえば、パートナ/ユーザー属性へのトークン属性のマッピング、複数のトークン属性を含むLDAP問合せの使用などです。

マッピング・ルールは、着信データをユーザーまたはパートナにマップする方法を決定します。着信トークンの次のデータが使用されます。

- UNTのユーザー名

- KerberosのユーザーID

- SAMLの名前IDおよび属性

- X.509のDNコンポーネント

- カスタムからの属性

マッピングは次のものを使用して実行されます。

- 簡易マッピング: ある着信属性をユーザー・レコード属性と照合

- 複雑なLDAP問合せ: 着信データのプレースホルダを含むLDAP問合せ。例: (&(sn=%lastname%)(mail=%email%))

- SAMLの名前IDマッピング表

新しい検証テンプレートのトークン・マッピングの例を次に示します。

- 図19-9「トークン・マッピング: SAML2 WS-Security検証テンプレート」

- 図19-10「トークン・マッピング: username-wstrust-validation-template」

- 図19-11「トークン・マッピング: x509-wss-validation-template」

図19-9は、名前IDフォーマットに基づいて、一致する属性を持つユーザー・レコードと名前ID値を照合することでユーザー・レコードにトークンをマップするためにOracle Security Token Serviceに必要なマッピング構成設定を示しています。

- 「トークンの宛先ユーザーのマップ」の有効化

- 簡易ユーザー・マッピングの有効化

- 属性ベース・ユーザー・マッピングの無効化

図19-9 トークン・マッピング: SAML2 WS-Security検証テンプレート

「図19-9 トークン・マッピング: SAML2 WS-Security検証テンプレート」の説明

図19-10に、一致するuidを持つユーザー・レコードとユーザー名トークンのusername要素を照合することでユーザー・レコードにトークンをマップするためにOracle Security Token Serviceに必要なマッピング構成設定を示します。必要な設定は次のとおりです。

- 「トークンの宛先ユーザーのマップ」の有効化

- 簡易ユーザー・マッピングの有効化

- データストア属性: 「uid」に設定

- 属性ベース・ユーザー・マッピングの無効化

図19-10 トークン・マッピング: username-wstrust-validation-template

「図19-10 トークン・マッピング: username-wstrust-validation-template」の説明

図19-11に、SSLクライアント証明書DN識別属性が一致するリクエスタ・パートナと証明書の「サブジェクトDN」を照合することでリクエスタ・パートナ・エントリにトークンをマップするためにOracle Security Token Serviceに必要なマッピング構成設定を示します。必要な設定は次のとおりです。

- トークンの宛先パートナのマップ

- 簡易ユーザー・マッピングの無効化

- 属性ベース・ユーザー・マッピングの無効化

- 簡易パートナ・マッピングの有効化

図19-11 トークン・マッピング: x509-wss-validation-template

「図19-11 トークン・マッピング: x509-wss-validation-template」の説明

すべての要素がすべてのトークン・タイプおよびトークン・プロトコルに適用されるわけではありません。定義する必要がある要素は異なります。

表19-11に、検証テンプレートのトークン・マッピング要素を示します。

表19-11 新規検証テンプレート: トークン・マッピング

要素

説明

トークンのマップ先

WS-Security検証テンプレート: 「トークンのマップ先」リスト

- <empty>: トークン・マッピング操作は行われません

- トークンの宛先パートナのマップ: トークンはリクエスタ・パートナにマップされます

- トークンの宛先ユーザーのマップとバインディング・データの宛先パートナのマップ: トークンはユーザーにマップされ、バインディング・データ(SSLクライアント証明書DN、HTTP Basic認証ユーザー名など)を使用して、HTTPリクエストがリクエスタ・パートナにマップされます。

- トークンの宛先ユーザーのマップ: トークンはユーザーにマップされます。

- - - - - - - - - -

WS-Trust検証テンプレート: トークンの宛先ユーザーのマップ

有効にする場合はボックスを選択します(無効にする場合は選択を解除します)。

簡易ユーザー・マッピングの有効化

簡易ユーザー・マッピングでは、単一のトークン属性を使用して、単一のユーザー・レコード属性と照合することで、着信トークンをユーザー・レコードにマップします。

WS-Security検証テンプレート: ユーザー名、SAMLアサーション、KerberosおよびX.509のみ。

WS-Trust検証テンプレート: ユーザー名、SAMLアサーション、Kerberos、X.509、OAMおよびカスタム・トークン。この検証テンプレートのトークン・タイプによって、レイアウトは異なります。

ユーザー名トークン:

- データストア属性は、ユーザー名トークンのusername要素と照合されるユーザー・レコード属性を参照します。

SAMLアサーション:

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

Kerberos:

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。「ユーザー・トークン属性」を指定するには、事前に移入された属性(「Kerberosプリンシパル」、「Kerberosプリンシパル・プライマリ」または「Kerberosプリンシパル・ドメインなし」)の1つを選択するか、特定の値を入力します。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

X.509:

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。「ユーザー・トークン属性」を指定するには、事前に移入された属性(「サブジェクトDN」、「共通名」、「国名」、「都道府県名」、「地方名」、「組織名」、「組織単位名」または「ドメイン・コンポーネント」)のいずれかを選択するか、特定の値(###を大文字のX.500コンポーネント名に置換することでSTS_X509_###に設定可能、たとえば、STS_X509_CNは証明書サブジェクトの共通名コンポーネントを参照)を入力します。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

OAM

- データストア属性は、ユーザー名トークンのusername要素と照合されるユーザー・レコード属性を参照します。デフォルトの「ユーザー・アイデンティティ・ストア」に定義されているユーザーID属性であることが必要です。

カスタム:

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。使用可能な値は、カスタム・トークン検証モジュールによって返される属性の名前です。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

ユーザー名識別子マッピングの有効化

有効な場合、次のものを定義します。

WSSおよびWS-Trust検証テンプレートには、「名前識別子」マッピング設定の同じセクションが含まれます。

名前IDユーザー・マッピング操作では、名前IDフォーマットに基づいて名前ID値を単一のユーザー・レコード属性にマップすることで、着信SAMLアサーションをユーザーにマップします。

有効な場合、OSTSでは名前IDフォーマットが評価され、ユーザー・レコード属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるユーザー・レコード属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。

マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でユーザー・レコード属性を設定します。

属性ベース・ユーザー・マッピングの有効化

WSS検証テンプレート: ユーザー名、SAMLアサーション、KerberosおよびX.509のみ。

WS-Trust検証テンプレート: ユーザー名、SAMLアサーション、Kerberos、X.509およびカスタム・トークンのみ。

属性ベース・ユーザー・マッピング操作では、LDAP問合せおよびトークン属性を使用することで、着信トークンをユーザー・レコードにマップします。LDAP問合せのフォーマットによりマッピング・ルールが定義され、使用するトークン属性が、パーセント(%)文字で囲まれた名前によって指定されます。たとえば、2つのトークン属性(firstnameおよびlastname)に基づいてトークンをマップするLDAP問合せは、(&(sn=%lastname)(givenname=%firstname%))のようになります。

使用可能なトークン属性は、トークン・タイプによって異なります。

ユーザー名トークン

- STS_SUBJECT_IDは、ユーザー名トークンのusername要素を含む使用可能な唯一のトークン属性です。

SAMLアサーション

- STS_SUBJECT_IDには名前ID値が含まれます。

- STS_NAMEID_FORMATには名前IDフォーマットが含まれます。

- STS_NAMEID_QUALIFIERには名前ID修飾子が含まれます。

- STS_SAML_ASSERTION_ISSUERにはアサーションの発行者が含まれます。

- アサーションのAttributeStatementに含まれる属性

Kerberos

- STS_KERBEROS_PRINCIPAL_SHORTには「Kerberosプリンシパル」属性が含まれます。

- STS_KERBEROS_PRINCIPAL_FULLには「Kerberosプリンシパル・プライマリ」属性が含まれます。

- STS_KERBEROS_PRINCIPAL_NODOMAINには「Kerberosプリンシパル・ドメインなし」属性が含まれます。

X.509

- STS_SUBJECT_IDには「サブジェクトDN」が含まれます。

- STS_X509_CNには「共通名」が含まれます。

- STS_X509_Cには「国名」が含まれます。

- STS_X509_STには「都道府県名」が含まれます。

- STS_X509_Lには「地方名」が含まれます。

- STS_X509_Oには「組織名」が含まれます。

- STS_X509_OUには「組織単位名」が含まれます。

- STS_X509_DCには「ドメイン・コンポーネント」が含まれます。

カスタム・トークン

- 使用可能な値は、カスタム・トークン検証モジュールによって返される属性の名前です。

簡易パートナ・マッピングの有効化

WSS検証テンプレートおよび次のトークン・タイプの場合のみ: ユーザー名、SAMLアサーション、KerberosおよびX.509。

簡易パートナ・マッピング操作では、単一のトークン属性を使用して、パートナ識別属性と照合することで、着信トークンをパートナ・リクエスタにマップします。

この検証テンプレートのトークン・タイプによって、レイアウトは異なります。

ユーザー名トークン

- パートナ・データストア属性は、ユーザー名トークンのusername要素と照合されるパートナ識別属性を参照します。

SAMLアサーション

- パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。

- パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。

Kerberos

- パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。「パートナ・トークン属性」を指定するには、事前に移入された属性(「Kerberosプリンシパル」、「Kerberosプリンシパル・プライマリ」または「Kerberosプリンシパル・ドメインなし」)の1つを選択するか、特定の値を入力します。

- パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。

X.509

- パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。「パートナ・トークン属性」を指定するには、事前に移入された属性(「サブジェクトDN」、「共通名」、「国名」、「都道府県名」、「地方名」、「組織名」、「組織単位名」または「ドメイン・コンポーネント」)のいずれかを選択するか、特定の値(###を大文字のX.500コンポーネント名に置換することでSTS_X509_###に設定可能、たとえば、STS_X509_CNは証明書サブジェクトの共通名コンポーネントを参照)を入力します。

- パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。

パートナ名識別子マッピングの有効化

有効な場合、WSS検証テンプレートおよびSAMLトークン・タイプについてのみ次のものを定義します。

名前IDユーザー・マッピング操作では、名前IDフォーマットに基づいて名前ID値を単一のリクエスタ・パートナ識別属性にマップすることで、着信SAMLアサーションをユーザーにマップします。

有効な場合、Oracle Security Token Serviceでは名前IDフォーマットが評価され、パートナ識別属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるリクエスタ・パートナ識別属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の「追加」ボタンをクリックし、カスタムURIを入力します。

マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でリクエスタ・パートナ識別属性を設定します。

トークン検証テンプレートの管理

これはサーバー側の構成です。デフォルトの「トークン検証テンプレート」が存在します。有効な管理者の資格証明を持つユーザーは、この項の手順を使用して、トークン検証テンプレートを追加、検索、編集または削除できます。不要な手順はスキップしてください。

Oracle Security Token Serviceエンドポイントを、次のものを示すWSセキュリティ検証テンプレートにリンクする必要があります。

- Webservice Securityヘッダー内のトークンを検証する方法

- トークンおよびバインディング・データをリクエスタにマップする方法

ここに示す情報は、次のものを検証するときに適用できます。

- SOAPヘッダーに含まれる、次のタイプのWS-Securityトークン: ユーザー名、SAML 1.1、SAML 2.0、X.509およびKerberos。

- WS-TrustリクエストのOnBehalfOf要素またはValidateTarget要素に含まれる、次のタイプのWS-Trustトークン: ユーザー名、SAML 1.1、SAML 2.0、X.509、Kerberos、OAMセッション伝播トークンおよびカスタム・トークン。

次の手順では、次の特定のパラメータを入力するいくつかの例を示します。また、カッコ()内には簡単な解釈も示します。たとえば、名前(ユーザー名トークン): email-wstrust-valid-tempなどです。値は使用する環境によって異なります。

前提条件

関連項目:

- 「トークン検証テンプレートの管理について」

- 「既存のテンプレートの検索」

トークン検証テンプレートを管理する手順

1. 既存のトークン検証テンプレートのリストを表示します。
Oracle Access Managerコンソール
システム構成
セキュリティ・トークン・サービス
トークン検証テンプレート

2. 新しいトークン検証テンプレート:

1. 右上隅の「新規検証テンプレート」ボタンをクリックします(または、「検索結果」表の上にある「追加」(+)コマンドをクリックします)。

2. 一般: このテンプレートのパラメータ(表19-9)を定義します。次に例を示します。
名前(ユーザー名トークン): email-wstrust-valid-temp
トークン・プロトコル(トークン・プロトコルのWS-Security): Webservice
トークン・タイプ(ユーザー名): email
デフォルト・パートナ・プロファイル: requester-profile

3. 認証: 必要に応じてこのテンプレートの資格証明検証を有効にし、詳細を示します(表19-10)。トークン・タイプがユーザー名の場合、必要に応じてこのテンプレートの資格証明検証を有効にし、詳細を示します。

4. トークン・マッピング: トークン・タイプに基づいてこのテンプレートのプリファレンスを指定します(表19-11)。

5. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

6. 定義を閉じます(またはステップ4の説明に従って定義を編集します)。

3. 既存のテンプレートの検索: 「システム構成」タブの「セキュリティ・トークン・サービス」セクションから次の手順を実行します。

1. すべて検索: 「トークン検証テンプレート」ノードをダブルクリックし、結果表を確認します。

2. 検索結果の絞込み: 検索条件(表19-1)を指定し、「検索」ボタンをクリックして結果表を確認します。

3. 検索フォームのリセット: 「リセット」ボタンをクリックします。

4. テンプレートの編集: 作成した保存済のページから編集を開始します。
または、ステップ3を使用して目的のテンプレートを検索し、「検索結果」表の名前をクリックして定義を表示します。

1. 必要に応じてテンプレート定義を編集します。

2. ページの上部にある「適用」ボタンをクリックし、変更を送信します(または「元に戻す」をクリックして変更を取り消します)。

5. 新しいトークン検証テンプレートの削除:

1. 「検索結果」表の目的の名前をクリックし、削除する項目を選択します。

2. 「アクション」メニューの「削除」をクリックします(または、表の上にある「削除」(X)コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

Oracle Security Token Serviceエンドポイントの管理

エンドポイントは、クライアントがSOAPを介してWS-Trustリクエストを送信できるOracle Security Token Serviceによって公開されるWebサービスです。エンドポイントの特徴は次のとおりです。

- WS Securityポリシーで保護されます。

- セキュリティ・トークンの検証方法およびマップ方法を示すWSS検証テンプレートにバインドされます。

- トークン・タイプ、つまりWSS検証テンプレートで指定したタイプに固有です。

注意:
エンドポイントを保護するWS-Securityポリシーは、エンドポイントにバインドされたWSS検証テンプレートと互換性があることが必要です。

エンドポイントは、Oracle Security Token Serviceによって公開され、OWSMエージェントによって保護されるWebサービス・エンドポイントです。エンドポイントは次のものにバインドされます。

- メッセージ保護およびセキュリティ・トークンの観点からWSS要件を決定するWS-Securityポリシー。

- リクエストの処理方法およびセキュリティ・トークンの検証方法を示すWSS検証テンプレート。

この項の内容は次のとおりです。

- エンドポイントの管理について

- エンドポイントの管理

エンドポイントの管理について

図19-12に示すように、Oracle Security Token Serviceエンドポイントの定義は3つのカテゴリで構成されています。

図19-12 「エンドポイント」ページ

「図19-12 「エンドポイント」ページ」の説明

表19-12に、エンドポイントに必要なカテゴリを示します。

表19-12 「エンドポイント」ページ

要素

説明

エンドポイントURI

エンドポイントへのパス。Oracle Security Token ServiceベースURLと相対的です。Oracle Security Token ServiceベースURLは/stsです。

ポリシーURI

Oracle WSMポリシーのリストから、このエンドポイントの保護に使用するものを選択します。

OAM管理者は、使用可能なリストに新しいカスタム・ポリシーを追加できます。この新たに作成された「ポリシーURI」をエンドポイント表リストに表示するには、次のwlstコマンドを使用してowsmpoliciesマップを更新します。

putStringProperty("/stsglobal/owsmpolicies/<index>", "<newcustom_policypath>)

次に例を示します。

putStringProperty("/stsglobal/owsmpolicies/31", "sts/newcustom_policy")

「検証テンプレート」のID

このエンドポイントで使用する名前を識別するために、検証テンプレート名のリストから選択します。

エンドポイントが作成されると、その削除は可能ですが、定義を編集することはできません。

エンドポイントの管理

有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行してエンドポイントを追加、編集または削除できます。

前提条件

参照するトークン検証テンプレートの作成

エンドポイントを作成または削除する手順

1. 「Oracle Access Managerコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. 「エンドポイント」ノードをダブルクリックして、既存のエンドポイントのリストを表示します。

3. 新規エンドポイント: 表19-12を参照してください。

1. 表の上にある「追加」(+)ボタンをクリックします(または「アクション」メニューから「新規エンドポイント」を選択します)。

2. 新しい「エンドポイントURI」を入力します。

3. このエンドポイントを保護するOracle WSMポリシーの1つを選択します。

4. このエンドポイントで使用する「検証テンプレート」を選択します。

5. 「適用」をクリックし、定義を送信して確認ウィンドウを閉じます(または「元に戻す」をクリックし、定義を送信せずにページを閉じます)。

6. ページを閉じます。

4. エンドポイントの削除:

1. 「エンドポイント」表の行を強調表示し、「削除」(X)ボタンをクリックします(または「アクション」メニューから「選択項目の削除」を選択します)。

2. 削除を確認します(または削除を取り消します)。

Oracle Access Managerを使用したトークン発行ポリシーおよび制約の管理

ここでは、次の内容について説明します。

- トークン発行ポリシーについて

- トークン発行ポリシーおよび制約の管理について

- トークン発行ポリシーおよび制約の管理

トークン発行ポリシーについて

トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してトークンを発行する際に従うルールを定義します。リクエスタが存在しない場合、(OBOトークンまたはWSSトークンで表される)ユーザーがリライイング・パーティにアクセスしようとしていると想定されます。

トークンを発行する場合、Oracle Security Token Serviceはそのトークンが作成されるリライイング・パーティを判断し、クライアントがそのリライイング・パーティへのトークンのリクエストを認可されているかどうかを評価します。トークンを発行するために、操作に含まれるリソース、および場合によっては制約を使用してトークン発行ポリシーを作成する必要があります。実行時にポリシー評価が成功すると、トークンが発行されます。

IAM Suiteトークン発行ポリシー

図19-13に、IAM Suiteアプリケーション・ドメインのIAM Suiteトークン発行ポリシーを示します。「暗黙的な制約の使用」がデフォルトで選択されており、特定のクラスの認可制約がない場合のアクセスを許可します。デフォルトでは、明示的な制約は定義されていません。

図19-13 IAM Suiteのトークン発行ポリシーとリソースURL

「図19-13 IAM Suiteのトークン発行ポリシーとリソースURL」の説明

このトークン発行ポリシーに制約を追加できます。

トークン発行ポリシーおよび制約の管理について

トークン発行ポリシーを使用すると、管理者はポリシーに対して「許可」および「拒否」制約を定義できます。各トークン発行ポリシーは、リクエストしたリソースのアクセスを付与または拒否するかどうかを決定する1つ以上の制約を含むことができます。

- 保護されたリソースへのアクセスを認可されるユーザーを指定する許可タイプの条件。
「制約」にリストされているパートナおよびユーザーのみがアクセス権を付与され、他のユーザーはリソースへのアクセスを拒否されます。

- 保護されたリソースへのアクセスを拒否されるユーザーを明示的に指定する拒否タイプの条件。
「制約」にリストされているパートナおよびユーザーのみがアクセスを拒否され、他のユーザーはリソースへのアクセス権を付与されます。

注意:
ユーザー制約を追加すると、ユーザーが選択に使用できるアイデンティティ・ストアがリストから選択されます。デフォルトのユーザー・アイデンティティ・ストアを選択したことを確認します。これは、Oracle Security Token Serviceでのみ使用されるアイデンティティ・ストアです。

トークン発行ポリシーと制約の管理は、認可ポリシーと制約の管理に似ています。図19-4に、トークン発行ポリシーの「制約」タブを示します。

図19-14 「トークン発行ポリシー」および「制約」

「図19-14 「トークン発行ポリシー」および「制約」」の説明

表19-13に、「トークン発行ポリシー」および「制約」の要件を示します。

表19-13 「制約」タブ: トークン発行ポリシー

要素

説明

名前

このトークン発行ポリシーの一意の名前。

説明

オプション。

暗黙的な制約の使用

デフォルトで有効になっており、特定のクラスの認可制約がない場合のアクセスを許可します。

「制約」タブ

名前

この制約の一意の名前。新しい制約を追加するときに割り当てます。名前を入力するダイアログ・ボックスが開きます。

クラス

トークン発行ポリシー制約にはトークン・リクエスタ・アイデンティティのみ許可されています。これは「制約の追加」ダイアログ・ボックスで選択します。

タイプ

「条件」を選択します。

- 許可: 保護されたリソースへのアクセスを認可されるユーザーを指定します。

- 拒否: 保護されたリソースへのアクセスを拒否されるユーザーを明示的に指定します。

選択したユーザーとグループ

追加

次の移入から選択します。

- アイデンティティの追加: 選択すると「検索」ウィンドウが開き、「ストア名」を設定できます。「エンティティ・タイプ」(「すべて」、「ユーザー」または「グループ」)を選択し、「エンティティ名」を指定します。その後、リストされた結果から1つ以上を選択し、「選択済の追加」をクリックして制約を移入します。

- パートナの追加: 選択すると、制約を移入する特定のパートナを検索できる「検索」ウィンドウが開きます。検索条件を入力(または、すべてのパートナを検索する場合はフィールドの横の矢印キーをクリック)した後、1つ以上の結果を選択し、「選択済の追加」をクリックして制約を移入します。

エンティティ名

選択した「ユーザー・アイデンティティ・ストア」に定義されている、ユーザーまたはグループの名前。

エンティティ・タイプ

制約にアイデンティティを追加するために検索中に検索するエンティティのタイプ: 「ユーザー」または「グループ」

ストア名

制約を移入するユーザーまたはグループを検索する、「ユーザー・アイデンティティ・ストア」の名前を選択します。Oracle Security Token Serviceではデフォルトのアイデンティティ・ストアのみを使用することに注意してください。

トークン発行ポリシーおよび制約の管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用してトークン発行ポリシーおよび制約をアプリケーション・ドメインに追加できます。このポリシーにリソースを追加するときに、UnknownRPおよびMissingRPリソースを追加できます。

前提条件

アプリケーション・ドメインがすでに存在する必要があります。

注意:
IAM Suiteアプリケーション・ドメインにトークン発行ポリシーを追加できます。

トークン発行ポリシーおよび制約を管理する手順

1. 次のように「アプリケーション・ドメイン」を開きます。
Oracle Access Managerコンソール
ポリシー構成
アプリケーション・ドメイン
目的のドメイン
トークン発行ポリシー

2. トークン発行ポリシーの追加:

1. 「アプリケーション・ドメイン」ツリーで、「トークン発行ポリシー」ノードをクリックし、「追加」(+)ボタンをクリックして新しいページを開きます。

2. 「トークン発行ポリシー」ページで、一意の名前とオプションの説明を入力します。

3. 「リソース」タブで、「追加」(+)ボタンをクリックし、リストされたリソースから目的のリソースを選択します。たとえば、「TokenServiceRP:URL」です。

4. この新しいリソースに割り当てる「トークン発行ポリシー」を選択します。

5. ページの上部にある「適用」ボタンをクリックし、変更を送信します(または「元に戻す」をクリックして変更を取り消します)。

6. 関連項目: 「トークン発行ポリシーおよび制約の管理」

3. ポリシーへの制約の追加:

1. 「制約」タブをクリックし、「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウを表示します。

2. ダイアログ・ボックスにこの制約の一意の名前を入力します。

3. 「クラス」リストから「トークン・リクエスタ・アイデンティティ」を選択します。

4. 「許可」または「拒否」条件を選択します。

5. 「選択済の追加」をクリックします。

4. 制約の追加の詳細:

1. 制約名をクリックして「制約: 詳細」を表示します。

2. 「追加」ボタンをクリックし、「アイデンティティの追加」または「パートナの追加」を選択します。

3. パートナの追加: 検索条件を入力(または、すべてのパートナを検索する場合はフィールドの横の矢印キーをクリック)した後、1つ以上の結果を選択し、「選択済の追加」をクリックして制約を移入します。

4. アイデンティティの追加: 「検索」ウィンドウで「ストア名」を設定し、「エンティティ・タイプ」(「すべて」、「ユーザー」または「グループ」)を選択して、「エンティティ名」を指定します。1つ以上の結果を選択し、「選択済の追加」をクリックして制約を移入します。

5. ページの上部にある「適用」ボタンをクリックし、ポリシーおよび制約を送信します。

5. アプリケーション・ドメイン内のTokenServiceRPリソースの検索(または追加): 「TokenServiceRPタイプのリソースの管理」を参照してください。

TokenServiceRPタイプのリソースの管理

トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してトークンを発行する際に従うルールを定義します。

トークンを発行する場合、Oracle Security Token Serviceはそのトークンが作成されるリライイング・パーティを判断し、クライアントがそのリライイング・パーティへのトークンのリクエストを認可されているかどうかを評価します。

注意:
トークンを発行するために、操作に含まれるリソース、および場合によっては制約を使用してトークン発行ポリシーを作成する必要があります。実行時にポリシー評価が成功すると、トークンが発行されます。

ポリシー内のリソースには次のものがあります。

- リライイング・パーティ・パートナIDに基づいたTokenServiceRPタイプのリソース。

- 既存のUnknownRPリソース。Oracle Security Token Serviceで、WS-TrustリクエストのAppliesTo要素で参照されるサービスURLをOracle Security Token Serviceリライイング・パーティ・パートナ・エントリにマップできない場合に必要なリソースです。

- 既存のMissingRPリソース。WS-TrustリクエストのAppliesTo要素が存在しない場合に必要なリソースです。

注意:
MissingRPとUnknownRPはどちらもIAM Suiteアプリケーション・ドメインに定義されています。

TokenServiceRPタイプのリソース(図19-15)は、Oracle Security Token Serviceパートナ・ストアに定義されているOracle Security Token Serviceリライイング・パーティ・パートナを表します。

図19-15 事前定義されたリソース・タイプ: TokenServiceRP

「図19-15 事前定義されたリソース・タイプ: TokenServiceRP」の説明

TokenServiceRPタイプのリソースはトークン発行ポリシーで使用されます。このポリシーは、Oracle Security Token Serviceが実行時にトークンを発行するときに評価されます。

詳細は、次を参照してください。

- Oracle Access Manager内のTokenServiceRPタイプのリソースの管理について

- アプリケーション・ドメイン内のTokenServiceRPタイプのリソースの管理

Oracle Access Manager内のTokenServiceRPタイプのリソースの管理について

ドメイン内の特定のタイプのリソースを検索するには、アプリケーション・ドメインの検索コントロールを使用します。図19-16に、IAM Suiteリソースの検索コントロールを示します。リソース・タイプTokenServiceRPは検索条件です。「検索結果」表に、アプリケーション・ドメイン内のこのタイプのリソースをすべてリストします。

図19-16 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP

「図19-16 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP」の説明

このドメイン内のTokenServiceRPリソースには、前述のとおり、即時利用可能な状態で提供されるリソースが含まれています。

- UnknownRPリソース

- MissingRPリソース

アプリケーション・ドメイン内のTokenServiceRPタイプのリソースの管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用してTokenServiceRPリソースをアプリケーション・ドメインに追加できます。

注意:

- RSTにAppliesToが存在し、リクエスタをマップできなかった場合は、TokenServiceRP:UnknownRPリソースを使用します。

- AppliesToが存在しない場合は、TokenServiceRP:MissingRPを使用し、それ以外の場合は該当するリソースを選択します。

関連項目:
「Oracle Access Manager内のTokenServiceRPタイプのリソースの管理について」

TokenServiceRPリソースを管理する手順

1. 次のように「アプリケーション・ドメイン」を開きます。
Oracle Access Managerコンソール
ポリシー構成
アプリケーション・ドメイン
目的のドメイン

2. アプリケーション・ドメインへのTokenServiceRPリソースの追加:

1. アプリケーション・ドメインの「検索」ページの「新規リソース」ボタンをクリックします。

2. 「リソース・タイプ」を「TokenServiceRP」と指定します。

3. トークン発行ポリシーが定義されるリライイング・パーティIDである「リソースURL」を入力します。

4. ページの上部にある「適用」ボタンをクリックし、これを送信して確認ウィンドウを閉じます。

5. 関連項目:「アプリケーション・ドメインへのリソース定義の追加」

3. TokenServiceRPリソースの検索:

1. 「リソース」ノードを開いて検索コントロールを表示します。

2. 「リソース・タイプ」リストから「TokenServiceRP」を選択し、「検索」をクリックします。

3. 「検索結果」表を確認し、名前をクリックしてリソース定義を開きます。

20 Token Serviceパートナとパートナ・プロファイルの管理

この章には、Token Serviceパートナとパートナ・プロファイルの管理について説明する次のトピックが用意されています。

- 前提条件

- Token Serviceパートナとパートナ・プロファイルの概要

- Token Serviceパートナの管理

- Token Serviceパートナ・プロファイルの管理

前提条件

「Oracle Security Token Serviceの概要」

第16章「Oracle Security Token Serviceの実装シナリオ」

Oracle Access Managerコンソールを使用して実行できるタスクは、次のものを使用して実行することもできます。

関連項目:
『Oracle Fusion Middleware WebLogic Scripting Tool Command Reference』

Token Serviceパートナとパートナ・プロファイルの概要

ここでは、次の内容について説明します。

- Token Serviceパートナについて

- パートナ・プロファイルについて

- パートナおよびプロファイル・データについて

Token Serviceパートナについて

Token Serviceパートナは、STSサーバーで信頼されているパートナを表します。次の3つのタイプのパートナがあります。

- リクエスタ。トークンを発行または検証するためにOracle Security Token Serviceと直接相互作用するWebサービス・クライアントを表します。

- リライイング・パーティ。Oracle Security Token Serviceサーバーによって発行されるトークンの受信者になるWebサービス・プロバイダを参照します。

- 発行局。アサーション発行者を表します。アサーションを検証する場合、発行者はOracle Security Token Service内の既知の発行局パートナ・エントリであることが必要です。

セキュリティ・トークン・サービスでは2つのタイプのクライアントと相互作用できます。

- Webサービス・クライアント・モジュール。Oracle Security Token Service内のリクエスタ・パートナ(通常はSOAPクライアント)として定義されます。

- エンド・ユーザー。リクエスタ・パートナとして定義されるのではなく、ユーザー・アイデンティティ・ストアに存在する可能性があります。

パートナ・プロファイルについて

パートナ・プロファイルには、パートナのセットに共通の構成プロパティが含まれており、各パートナ・エントリはパートナ・プロファイルに関連付けられます。パートナと同様に、パートナ・プロファイルには3つのタイプ(リクエスタ、リライイング・パーティおよび発行局パートナ・プロファイル)があります。

パートナおよびプロファイル・データについて

パートナ・エントリには次の情報が含まれます。

- 署名証明書と暗号化証明書

- パートナ名、一意の識別子および説明

- パートナ・プロファイルへの参照

- リクエスタの場合、ユーザー名トークン資格証明、および着信データをリクエスタにマップするために使用されるID文字列も含まれます。

パートナ・プロファイル・エントリには、プロファイルのタイプに応じて次の情報が含まれます。

- リクエスタ

- 要求マッピング

- OnBehalfOf要素に存在するトークンの検証に使用されるWS-Trust検証テンプレート

- リライイング・パーティ

- RPに送信される属性

- 使用される発行テンプレート

- 発行局

- 属性名/値マッピングの設定

- パートナ/ユーザーへの着信トークンのマップに使用される特定のマッピング・アクション・ルール

Token Serviceパートナの管理

この項の内容は次のとおりです。

- Token Serviceパートナの管理について

- Token Serviceパートナの管理

- パートナ検索の絞込み

Token Serviceパートナの管理について

新しいパートナの作成を選択した場合、選択した特定のパートナ・タイプの新しいページが表示されます。図20-1に、「Oracle Access Managerコンソール」の「新規リクエスタ・パートナ」ページを示します。このページにはすべての「パートナ」要素が含まれます。

図20-1 「新規リクエスタ・パートナ」ページ

「図20-1 「新規リクエスタ・パートナ」ページ」の説明

ほとんどの要素(名前、説明およびこのパートナが信頼されているかどうか)はすべてのパートナに共通ですが、特定の要素は特定のパートナ・タイプによって決まります。次に例を示します。

- リクエスタ・パートナ: 暗号化証明書と署名証明書を指定できます。

- リライイング・パーティ・パートナ: 暗号化証明書のみ指定できます。

- 発行局パートナ: 署名証明書のみ指定できます。

表20-1に、Oracle Security Token Serviceパートナの要素を示します。特に明記しないかぎり、すべての要素がすべてのパートナ・タイプに適用されます。

表20-1 Oracle Security Token Serviceパートナの要素

要素

説明

パートナ名

このパートナの名前を入力します。

パートナ・タイプ

編集不可の記述で、作成または編集しているパートナのタイプに応じて異なります。

- リクエスタ

- リライイング・パーティ

- 発行局

パートナ・プロファイル

選択したパートナ・タイプについてリストされたプロファイルから選択します。

説明

オプション。

信頼

パートナが信頼されているかどうかを示すには、このボックスを選択します。選択しない場合、Oracle Security Token Serviceサーバーでは、リクエストにそのようなエントリが含まれるときにエラーが報告されません。

証明書のロード

要求された証明書を参照してアップロードしますが、これはパートナ・タイプによって異なります。

- 暗号化証明書と署名証明書

- 暗号化証明書

- 署名証明書

ユーザー名トークン認証

リクエスタのみ

ユーザー名トークン認証の次のものについて値を入力できます。

- ユーザー名

- パスワード

- パスワードの確認

新規リクエスタ・パートナのアイデンティティ属性を「セキュリティ・トークン・サービスの設定」セクションで定義し、リクエスタ・パートナの「アイデンティティ属性」表に表示できます。

注意: ユーザー名とパスワードのデータは、ユーザー名トークンの資格証明を検証するために使用されます。ユーザー名を使用したリクエスタ・パートナへの着信トークンのマップのみにデータが使用される場合、ユーザー名のみを入力し、パスワードを入力しないこともできます。

アイデンティティ属性

リクエスタのみ

実行時にOracle Security Token Serviceでは、セクションに定義されたデータを使用して、着信リクエストをリクエスタ・パートナ・エントリにマップします。次のものが使用されます。

- SSLクライアント証明書のサブジェクトDN(存在する場合)、HTTP Basic認証ユーザー名などのトークン・データまたはバインディング・データ。

- 各リクエスタ・パートナ・エントリに存在するアイデンティティ属性。

新しいマッピングを「リライイング・パーティ・パートナ」セクションにhttp://relying.party.test.com/testing.serviceのように追加できます。実行時にOracle Security Token ServiceサーバーではそのURLを使用して、WS-Trustリクエストに含まれるAppliesToサービス・ロケーションをリライイング・パーティ・パートナにマップします。

リソースURL

リライイング・パーティのみ

表のリソース・パターン列にリソースURLを入力し、その横に説明を入力します。次に例を示します。

パターン:

http://relying.party.test.com/testing/service

表にリストされるリソースURLは、WS-Trustリクエストからこのリライイング・パーティ・パートナにAppliesToロケーション要素をマップするときに使用されます。

AppliesToロケーション値は、このリライイング・パーティ・パートナにマップされます。

- リソースURLはAppliesToロケーション値と完全に一致します。たとえば、AppliesToロケーションがhttp://relying.party.test.com/testing/serviceの場合、リソースURLもhttp://relying.party.test.com/testing/serviceです。

- または、リソースURLがAppliesToロケーション値の親です。たとえば、AppliesToロケーションはhttp://relying.party.test.com/testing/serviceで、リソースURLはhttp://relying.party.test.com/testing、またはリソースURLはhttp://relying.party.test.com/です。

図20-2に、入力する「リクエスタ・パートナ」ページを示します。

図20-2 定義済のリクエスタ・パートナ

「図20-2 定義済のリクエスタ・パートナ」の説明

Token Serviceパートナの管理

有効な管理者の資格証明を持つユーザーは、次の手順に従って、Oracle Access Managerコンソールを使用してトークン・サービス・パートナを作成、検索、編集または削除できます。

前提条件

作成されるパートナのタイプのパートナ・プロファイルが存在する必要があります。

Token Serviceパートナを管理する手順

1. 「Oracle Access Managerコンソール」から次のものを開きます。
「システム構成」タブ
「セキュリティ・トークン・サービス」セクション
「パートナ」ノード

2. 「パートナ」ノードで、目的のパートナ・タイプをダブルクリックし、必要に応じて次の手順に進みます。

- リクエスタ

- リライイング・パーティ

- 発行局

3. 新規パートナ:

1. 新規パートナ・タイプボタンをクリックして、定義に使用する新しいページを表示します。

2. 選択したパートナ・タイプの一般情報(表20-1)を入力します。

3. 信頼: クリックして選択します(これが信頼できるパートナではない場合は、空白のままにします)。

4. 証明書: 必要な証明書をロードします。

5. リライイング・パーティ: 必要に応じてリソースURLを入力します。

6. リクエスタ: 必要に応じてユーザー名トークン資格証明を入力します。

7. 「保存」をクリックして送信(または「取消」をクリックしてページを閉じます)し、確認ウィンドウを閉じます。

4. パートナ検索の絞込み: 「パートナ検索の絞込み」

1. ステップ1および2を実行します。

2. 問合せを定義し、「検索」ボタンをクリックします。

3. 「検索結果」表で、表示、編集または削除するパートナの名前をクリックします。

5. パートナの編集:

1. 「検索結果」表で、編集するパートナの名前をクリックし、「編集」ボタンをクリックします(または「アクション」メニューから「編集」を選択します)。

2. パートナ情報に必要な変更を加えます(表20-1)。

3. 「適用」をクリックして変更を送信(または「元に戻す」をクリックして変更を取り消します)し、確認ウィンドウを閉じます。

6. パートナの削除: 必要に応じて、検索コントロールを使用して問合せを絞り込んで送信します。

1. 「検索結果」表で、削除するパートナを含む行を強調表示します。

2. 「削除」(X)ボタンをクリック(または「アクション」メニューから「選択項目の削除」を選択します)し、確認ウィンドウを閉じます。

パートナ検索の絞込み

他のシステム構成コンポーネントと同様に、「パートナ」ノードを開くと、すべてのパートナ・タイプ・ノードが使用可能になります。特定の「パートナ」ノードを選択すると、関連する検索コントロールと「検索結果」表が使用可能になります。

図20-3にリクエスタ・パートナを示します。結果は他のパートナ・タイプの結果とは異なります。

図20-3 パートナの検索コントロール

「図20-3 パートナの検索コントロール」の説明

「検索」ページから「検索結果」表の名前を選択するか、コントロールを使用して検索を絞り込み、特定のパートナまたは特定の特性を持つパートナを検索します。

Token Serviceパートナ・プロファイルの管理

この項では、Token Serviceパートナ・プロファイルに関する情報を示します。

- パートナ・プロファイルの管理について

- Token Serviceパートナ・プロファイルの管理

- プロファイル検索の絞込み

パートナ・プロファイルの管理について

図20-4に、「一般」タブと「トークンと属性」タブの両方が表示されている、入力が完了した「リクエスタ・プロファイル」ページを示します。

図20-4 リクエスタ・プロファイル: 一般

「図20-4 リクエスタ・プロファイル: 一般」の説明

表20-2に、すべてのプロファイル・タイプの「一般」要素を示します。

表20-2 プロファイル: 一般

要素

説明

プロファイルID

このプロファイルに対する一意の識別子。

説明

オプション。

プロファイル・タイプ

プロファイルのタイプ(編集不可): 「リクエスタ」、「リライイング・パーティ」または「発行局」になります。

デフォルト・リライイング・パーティ・プロファイル

リクエスタ・パートナ・プロファイルのみ

WS-Trustリクエストがリライイング・パーティを参照しない(AppliesTo要素が存在しないなど)か、AppliesTo要素を既知のリライイング・パーティ・パートナ・プロファイルにマップできなかった場合、使用するリライイング・パートナ・プロファイルを参照します。

デフォルトとして使用するリライイング・パーティ・プロファイルを選択し、必要に応じて次の特性を有効または無効にします。

- 欠落している要求に対してエラーを返す
発行されたトークンにクライアントがリクエストした要求が含まれていない場合、Oracle Security Token Serviceはエラーを返します。

リライイング・パーティ・パートナ・プロファイルでは発行されたトークンに含めることができる属性/要求のリストが定義されるため、クライアントがリクエストした一部の要求が返されない可能性があります。

- マップされていない要求を許可
WS-Trustリクエストにリストされる要求は、「トークンと属性」セクションを使用してローカル属性にマップするために、翻訳される言語で指定されます。

このフラグは、翻訳できない要求をそのまま参照するかどうかを示します。これにより、クライアントによってリクエストされる要求を制御できます。

発行するデフォルト・トークン

リライイング・パーティのみ

この表は、このプロファイルにリンクされたリライイング・パーティのトークンの発行に使用する発行テンプレートを示します。

このプロファイルのデフォルトとしてトークン・タイプを選択します。

- SAML 1.1

- SAML 2.0

- ユーザー名

- カスタム

ポリシーをトークンに関連付けるには、「ポリシーのダウンロード」の横にあるボックスを選択します。選択した場合、Oracle Security Token Serviceでは実行時に、RST内のAppliesTo要素で参照されるリライイング・パーティのWS-Securityポリシーがダウンロードされます。存在する場合、Oracle Security Token ServiceではそのURLを使用してポリシーをダウンロードした後、ポリシーに存在する情報に基づいて返すトークンのタイプを決定します。

リクエスタ・プロファイル: トークンと属性

図20-5に、「トークンと属性」タブおよびリクエスタ・プロファイルに付随する表を示します。「トークン・タイプ構成」セクションは、トークン・タイプに基づいてWS-TrustリクエストのOnBelhalfOf要素に含まれるトークンの検証に使用するWS-Trust検証テンプレートを示します。このセクションでは、クライアントによってリクエストされるWS-Trust要求とローカル属性名の間のマッピングが定義されます。

図20-5 リクエスタ・プロファイル: トークンと属性

「図20-5 リクエスタ・プロファイル: トークンと属性」の説明

表20-3に、リクエスタ・プロファイルの「トークンと属性」要素およびコントロールを示します。

表20-3 リクエスタ・プロファイル: トークンと属性

要素

説明

トークン・タイプ構成

表の上の「+」をクリックして次のダイアログ・ボックスを表示した後、各リストから1つずつ選択します。

「トークン・タイプ」リストには、サポートされている(およびカスタム)デプロイ済のトークン・タイプがすべて表示されます。

「検証テンプレート」リストには、現在定義されているすべてのWS-Trust検証テンプレートが含まれています。

属性名マッピング

この表は、OSTSが名前およびオプションの「フォーマット/ネームスペース」で表される要求をローカル属性にマップする方法を定義します。

Oracle Security Token ServiceではInfocard要求言語がサポートされています。Infocard要求をローカル属性に変換するには、「着信属性」に要求名、「ローカル属性」にローカル名が含まれるマッピングを定義する必要があります(「フォーマット/ネームスペース」列は空になります)。

たとえば、あるマッピングは次のようになります。

- 着信属性: surname

- ローカル属性: sn

別のマッピングは次のようになります。

- 着信属性: givenname

- ローカル属性: givenname

別のマッピングは次のようになります。

- 着信属性: emailaddress

- ローカル属性: mail

リライイング・パーティ・プロファイル: トークンと属性

図20-6に、リライイング・パーティ・プロファイルに対して定義されている「トークンと属性」を示します。この項により、管理者はこのプロファイルに関連付けられたリライイング・パーティのトークンの発行に使用される発行テンプレートを定義できます。

また、発行済のトークンに含まれる属性(名前別)、その属性のソース、クライアントがリクエストした場合のみ属性を発行済トークンに含めるか、または常に含めるかもリストされます。

このページでは、リライイング・パーティ・プロファイルにはトークン・タイプ以外に発行テンプレートも必要です。また、属性タイプは他のプロファイルとは異なります。

図20-6 リライイング・パーティ・プロファイルの「トークンと属性」

「図20-6 リライイング・パーティ・プロファイルの「トークンと属性」」の説明

表20-4に、リライイング・パーティ・プロファイルに必要な要素を示します。

表20-4 リライイング・パーティ・プロファイルの要件

要素

説明

トークン・タイプ構成

表の上の「+」をクリックして次のダイアログ・ボックスを表示した後、各リストから1つずつ選択します。

「トークン・タイプ」リストには、サポートされている(およびカスタム)デプロイ済のトークン・タイプがすべて表示されます。

「発行テンプレート」リストには、現在定義されているすべての発行テンプレートが表示されます。

属性

発行済トークンに含まれる属性は、次のとおりです。

- 属性名: 属性の名前を示します。

- ストア・タイプ: 属性のソースを示します。
ユーザーストア: 属性値を取得するためにLDAPユーザー・レコードが使用されるデフォルトのユーザー・アイデンティティ・ストア。

着信トークン: 属性は着信トークンの要素を参照します。

静的: 値は「値」フィールドに指定されます。

- トークンに含める: 属性を常に発行済トークンに含めるかどうかを示します。選択を解除すると、クライアントがこの属性をリクエストした場合のみ属性が含まれます。

- 暗号化: 属性を暗号化するかどうかを示します。
注意: SAML 2.0でのみサポートされます。また、リライイング・パーティ・パートナ・エントリで暗号化証明書を設定するか、WS-Trustリクエストに暗号化証明書が存在する必要があります。

- 値: 「ストア・タイプ」が静的値の場合に使用される値を含みます。

関連項目: 「リライイング・パーティ・プロファイルの属性」

リライイング・パーティ・プロファイルの属性

属性を定義するときに、次のものを指定できます。

- 属性ソース: ユーザー・ストア(LDAP)、着信トークン・データまたは静的値。

- クライアントがリクエストした場合のみトークンに属性を含めるか、またはすべてのトークンに属性を含めるか。

- 属性を暗号化するかどうか(SAML 2.0のみ、リライイング・パーティの暗号化証明書が必要)。

- これが静的属性の場合は属性の値。

例: LDAPから取得されたmail属性をすべての送信トークンに含める場合

- 属性名: mail

- ストア・タイプ: ユーザーストア

- トークンに含める: 選択

- 暗号化: 選択解除

- 値: 空

例: 着信ユーザー名トークンのusername要素をすべての送信トークンに含める場合

- 属性名: STS_SUBJECT_ID

- ストア・タイプ: 着信トークン

- トークンに含める: 選択

- 暗号化: 選択解除

- 値: 空

例: 静的属性をすべての送信トークンに含める場合

- 属性名: rp-version

- ストア・タイプ: 静的

- トークンに含める: 選択

- 暗号化: 選択解除

- 値: 2.0

着信トークン・データから次の属性を使用できます。名前で参照されるSAML属性も、着信トークン・データとして使用できます。

STS_SUBJECT_ID

サブジェクト識別子(ユーザー名トークンの場合はユーザー名、SAMLアサーションの場合は名前ID値、X.509証明書の場合はサブジェクトDN)を含みます。

STS_NAMEID_FORMAT

SAML名前IDフォーマットを含みます。

STS_NAMEID_QUALIFIER

SAML名前IDフォーマットを含みます。

STS_SPNAME_QUALIFIER

SAML名前ID修飾子を含みます。

STS_SP_PROVIDED_ID

SAML名前ID SP修飾子を含みます。

STS_SESSION_INDEX

セッション索引を含みます。

STS_AUTHENTICATION_INSTANT

認証インスタントを含みます(ユーザー名トークン資格証明の検証の場合はcurrent after、SAMLアサーションの場合は認証文から、X.509検証の場合はcurrent、Kerberos検証の場合はcurrent、OAMセッション伝播トークンの場合は認証インスタント)。

STS_AUTHENTICATION_TIMEOUT

設定されている場合、セッションの有効期間を含みます(存在する場合、SAMLアサーションおよびOAMセッション伝播トークンに適用されます)。

STS_X509_CN

X.509証明書のサブジェクトDNのCNコンポーネントを含みます。

STS_X509_OU

X.509証明書のサブジェクトDNのOUコンポーネントを含みます。

STS_X509_O

X.509証明書のサブジェクトDNのOコンポーネントを含みます。

STS_X509_L

X.509証明書のサブジェクトDNのLコンポーネントを含みます。

STS_X509_ST

X.509証明書のサブジェクトDNのSTコンポーネントを含みます。

STS_X509_C

X.509証明書のサブジェクトDNのCコンポーネントを含みます。

STS_X509_DC

X.509証明書のサブジェクトDNのDCコンポーネントを含みます。

STS_X509_*

X.509証明書のサブジェクトDNの*で識別されるコンポーネントを含みます。

STS_X509_VERSION

X.509証明書のversion属性を含みます。

STS_X509_ISSUER_X500_PRINCIPAL_NAME

X.509証明書の発行者DNを含みます。

STS_X509_NOT_AFTER

X.509証明書のnot after属性を含みます。

STS_X509_NOT_BEFORE

X.509証明書のnot before属性を含みます。

STS_X509_SUBJECT_X500_PRINCIPAL_NAME

X.509証明書のサブジェクトDNを含みます。

STS_X509_SUBJECT_ALTERNATIVE_NAMES

X.509証明書のサブジェクト代替名拡張値を含みます。

STS_X509_SERIAL_NUMBER

X.509証明書のシリアル番号を含みます。

STS_OAM_LAST_ACCESS_TIME

OAMセッション伝播トークンの最終アクセス時間を含みます。

STS_OAM_LAST_UPDATE_TIME

OAMセッション伝播トークンの最終更新時間を含みます。

STS_OAM_CREATION_TIME

OAMセッション伝播トークンの作成時間を含みます。

STS_KERBEROS_PRINCIPAL_SHORT

KerberosトークンのPrincipal Short値を含みます。

STS_KERBEROS_PRINCIPAL_FULL

KerberosトークンのPrincipal Full値を含みます。

STS_KERBEROS_PRINCIPAL_NODOMAIN

KerberosトークンのPrincipal No Domain値を含みます。

STS_SAML_ASSERTION_ID

SAMLアサーションのAssertionIDを含みます。

STS_SAML_SUBJECT_DNS

SAMLアサーションのサブジェクトDNS属性を含みます。

STS_SAML_SUBJECT_IP_ADDRESS

SAMLアサーションのサブジェクトIPアドレス属性を含みます。

STS_SAML_ASSERTION_ISSUER

SAMLアサーションの発行者を含みます。

STS_SAML_AUTHN_INSTANT

SAMLアサーションの認証インスタントを含みます。

STS_SAML_AUTHN_METHOD

SAMLアサーションの認証方式を含みます。

発行局プロファイル: トークンと属性

発行局パートナ・プロファイルでは、異なる発行局パートナに共通の設定が定義されます。

図20-7に示すように、「トークンと属性」セクションを使用すると、管理者は属性の名前および値をローカル名および値に変換するために使用されるマッピング・ルールを定義できます。

図20-7 トークンと属性: 発行局

「図20-7 トークンと属性: 発行局」の説明

表20-5に、発行局の「トークンと属性」要素を示します。トークンから属性を抽出するときに、アサーションに含まれる属性に適用される属性マッピング・ルールを定義できます。2つのルールのセットがあります。

- SAML属性の名前をローカル名に変換できる属性名マッピング(たとえば、firstnameをgivennameに変換できます)。

- SAML属性の値をローカル値に変換できる属性名マッピング(たとえば、PresidentをCEOに変換できます)。

表20-5 「トークンと属性」要素: 発行局

要素

説明

属性名マッピング

SAML属性の名前と属性のローカル名の間のオプション・マッピングを定義します。

マッピングはオプションです。属性にマッピングが定義されていない場合は、SAML属性名が使用されます。

- 着信属性: アサーションに表示される属性の外部名を含みます。

- ローカル属性: 属性のローカル名を含みます。

- フォーマットまたはネームスペース: オプションのフォーマットまたはネームスペースを含みます。存在しない場合、マッピングのためのネームスペース値はurn:oracle:security:fed:attrnamespace (SAML 1.1アサーションの場合)に設定されるか、またはマッピングのためのフォーマット値はurn:oasis:names:tc:SAML:2.0:attrname-format:basic (SAML 2.0アサーションの場合)と想定されます。

値マッピング

SAML属性のオプションの値マッピングを定義します。これは、必要に応じて属性値をローカル値に変換する方法を示します。

注意: この属性値マッピングは、属性名マッピングに適用されます。属性の属性マッピングを定義するには、まずその属性の属性名マッピングを定義する必要があります。

- 外部値: SAML属性の値を含みます。

- ローカル値: SAML属性値が「外部属性」/「ローカルNULL」フィールドと一致する場合に設定されるローカル値を含みます。

- 外部NULL: nullのSAML属性値を表します。

- ローカルNULL: SAML属性値が「外部属性」/「ローカルNULL」フィールドと一致する場合、ローカル値をnullにするかどうかを示します。

- 大/小文字区別なし: 属性値を「ローカル属性」フィールドと比較するときに、Oracle Security Token Serviceで大/小文字が区別されるかどうかを示します。

発行局プロファイル: トークン・マッピング

図20-8に示すように、「トークン・マッピング」タブを使用すると、管理者はSAML検証テンプレートに定義されているマッピング・ルールを、発行局パートナ・プロファイルに定義されているマッピング・ルールでオーバーライドできます。このように、Oracle Security Token Serviceはアサーション発行者のセットに固有のルールに基づいてSAMLアサーションをマップできます。表20-5に、発行局の「トークン・マッピング」要素を示します。

図20-8 発行局プロファイル: 「トークン・マッピング」タブ

表20-6 発行局の「トークン・マッピング」要素

要素

説明

トークン・マッピングのオーバーライド

このセクションに定義されているマッピング・ルールが、アサーションの処理に使用されるSAML検証テンプレートにリストされているマッピング・ルールをオーバーライドするかどうかを示します。これにより、OSTSはアサーション発行者に固有のマッピング・ルールを使用できます。trueの場合、すべてのマッピング・ルールがこのセクションにリストされている設定でオーバーライドされます。

簡易ユーザー・マッピングのオーバーライド

簡易ユーザー・マッピングでは、単一のトークン属性を使用して、単一のユーザー・レコード属性と照合することで、着信トークンをユーザー・レコードにマップします。

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

ユーザー名識別子マッピングのオーバーライド

有効な場合、名前IDユーザー・マッピング操作を定義します。この操作では、名前IDフォーマットに基づいて名前ID値を単一のユーザー・レコード属性にマップすることで、着信SAMLアサーションをユーザーにマップします。

有効な場合、Oracle Security Token Serviceでは名前IDフォーマットが評価され、ユーザー・レコード属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるユーザー・レコード属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

- カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。

- マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でユーザー・レコード属性を設定します。

属性ベース・ユーザー・マッピングのオーバーライド

属性ベース・ユーザー・マッピング操作では、LDAP問合せおよびトークン属性を使用することで、着信トークンをユーザー・レコードにマップします。

LDAP問合せのフォーマットによりマッピング・ルールが定義され、使用するトークン属性が指定されます。トークン属性は%文字で囲みます。たとえば、2つのトークン属性(firstnameおよびlastname)に基づいてトークンをマップするLDAP問合せは次のようになります。

(&(sn=%lastname)(givenname=%firstname%))

STS_SUBJECT_IDには名前ID値が含まれます。

STS_NAMEID_FORMATには名前IDフォーマットが含まれます。

STS_NAMEID_QUALIFIERには名前ID修飾子が含まれます。

STS_SAML_ASSERTION_ISSUERにはアサーションの発行者が含まれます。

アサーションのAttributeStatementに含まれる属性

簡易パートナ・マッピングのオーバーライド

簡易パートナ・マッピング操作では、単一のトークン属性を使用して、パートナ識別属性と照合することで、着信トークンをパートナ・リクエスタにマップします。

- パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。

- パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。

パートナ名識別子マッピングのオーバーライド

有効な場合、名前IDユーザー・マッピング操作では、名前IDフォーマットに基づいて名前ID値を単一のリクエスタ・パートナ識別属性にマップすることで、着信SAMLアサーションをユーザーにマップします。

有効な場合、OSTSでは名前IDフォーマットが評価され、パートナ識別属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるリクエスタ・パートナ識別属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

- カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。

- マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でリクエスタ・パートナ識別属性を設定します。

Token Serviceパートナ・プロファイルの管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、トークン・サービス・パートナ・プロファイルを作成、検索、表示、編集または削除できます。

前提条件

リクエスタ・パートナ・プロファイルの前提条件は、次のとおりです。

- デフォルト・リライイング・パートナ・プロファイルを定義するために、リライイング・パートナ・プロファイルが存在する必要があります。

- OnBehalfOf要素に存在するトークンの検証に使用されるテンプレートを設定するために、WS-Trust検証テンプレートが存在する必要があります。

リライイング・パートナ・プロファイルの前提条件は、次のとおりです。

- トークン発行操作に使用するテンプレートを構成するために、発行テンプレートが存在する必要があります。

発行局パートナ・プロファイルの前提条件はありません。

パートナ・プロファイルを作成、検索、編集または削除する手順

1. 「Oracle Access Managerコンソール」から次のものを開きます。
「システム構成」タブ
「セキュリティ・トークン・サービス」セクション
「パートナ・プロファイル」ノード

2. 「パートナ・プロファイル」ノードで、目的のプロファイル・タイプをダブルクリックし、必要に応じて次の手順に進みます。

- リクエスタ・プロファイル

- リライイング・パーティ・プロファイル

- 発行局プロファイル

3. 新規プロファイル:

1. 新規プロファイル・タイプボタンをクリックして、定義に使用する新しいページを表示します。

2. 選択したプロファイル・タイプの一般情報(表20-2)を入力し、「次」ボタンをクリックします。

3. トークンと属性: 適切な表を使用して、選択したプロファイル・タイプの詳細を指定します。
リクエスタ・プロファイル: 表20-3

リライイング・パーティ・プロファイル: 表20-4

発行局プロファイル: 表20-5

4. 「保存」をクリックして送信(または「取消」をクリックしてページを閉じます)し、確認ウィンドウを閉じます。

4. プロファイル検索の絞込み: 「プロファイル検索の絞込み」

1. ステップ1および2を実行します。

2. 問合せを定義し、「検索」ボタンをクリックします。

3. 「検索結果」表で、表示、編集または削除するパートナの名前をクリックします。

5. プロファイルの編集:

1. 「検索結果」表で、編集するプロファイルの名前をクリックし、「編集」ボタンをクリックします(または「アクション」メニューから「編集」を選択します)。

2. パートナ情報に必要な変更を加えます。
リクエスタ・プロファイル: 表20-3

リライイング・パーティ・プロファイル: 表20-4

発行局プロファイル: 表20-5

3. 「適用」をクリックして変更を送信(または「元に戻す」をクリックして変更を取り消します)し、確認ウィンドウを閉じます。

6. プロファイルの削除: プロファイルを削除するには、プロファイルが他の場所で参照されていない状態にする必要があります。
リクエスタ・パートナ・プロファイルを削除するには、次のことが必要です。

- リクエスタ・パートナがプロファイルを参照していないこと。

- WS-Security検証テンプレートがプロファイルを参照していないこと。

リライイング・パーティ・パートナ・プロファイルを削除するには、次のことが必要です。

- リライイング・パーティ・パートナがプロファイルを参照していないこと。

- リクエスタ・パートナ・プロファイルがプロファイルを参照していないこと。

発行局パートナ・プロファイルを削除するには、次のことが必要です。

- 発行局パートナがプロファイルを参照していないこと。

これらの前提条件が満たされている場合は、次の作業を実行します。

1. 「検索結果」表で、削除するプロファイルを含む行を強調表示します。

2. 「削除」(X)ボタンをクリック(または「アクション」メニューから「選択項目の削除」を選択します)し、確認ウィンドウを閉じます。

プロファイル検索の絞込み

パートナ定義と同様に、「パートナ・プロファイル」ノードを開くと、すべての「パートナ・プロファイル」ノードが使用可能になります。特定のタイプの「パートナ・プロファイル」ノードを選択すると、関連する検索コントロールと「検索結果」表が使用可能になります。

図20-3に、一般的なプロファイルの検索ページを示します。これはリクエスタ・プロファイルの場合です。ただし、コントロールはすべて同じです。異なるプロファイル・タイプでは結果のみが異なります。

図20-9 プロファイルの検索ページ: リクエスタ

「図20-9 プロファイルの検索ページ: リクエスタ」の説明

「検索」ページから「検索結果」表の名前を選択してプロファイルを表示または編集するか、コントロールを使用して検索を絞り込み、特定のプロファイルまたは特定の特性を持つプロファイルを検索します。

21 Oracle Security Token Servicesのトラブルシューティング

この章では、Oracle Security Token Serviceのトラブルシューティングに関するヒントを提供します。

- 認可の問題

- エンドポイントの問題

- マッピング操作の問題

認可の問題

問題: トークンの発行操作中に認可に失敗しました

WS-Trustリクエストの発行操作中に、Oracle Security Token Serviceがエラーを返します。

エラー・メッセージ

ログに表示される可能性があるエラー・メッセージのサンプルを次に示します。

<Error> <oracle.security.fed.controller.ApplicationController> <STS-12064> <Exception: {0}
oracle.security.fed.event.EventException: oracle.security.fed.event.EventException: Authorization Failure for Relying Party=%RELYING_PARTY_ID%, Requester=%REQUESTER_ID% and User=%USER_ID%

この場合:

- %RELYING_PARTY_ID%はリライイング・パーティ・パートナIDを示します。

- WS-TrustリクエストにAppliesTo要素が含まれていない場合、%RELYING_PARTY_ID%はMissingRPに設定されます。

- WS-TrustリクエストにAppliesTo要素が含まれ、リライイング・パーティ・パートナにマップできなかった場合、%RELYING_PARTY_ID%はUnknownRPに設定されます。

- WS-TrustリクエストにAppliesTo要素が含まれ、リライイング・パーティ・パートナにマップされた場合、%RELYING_PARTY_ID%はリライイング・パーティ・パートナIDに設定されます。

- 着信リクエストがリクエスタ・パートナにマップされた場合、%REQUESTER_ID%はリクエスタ・パートナIDに設定されます。%REQUESTER_ID%がnullではない場合、現在のアイデンティティ制約に対してトークン発行ポリシーを評価するときに使用されます。

- 着信リクエストがユーザー・レコードにマップされた場合、%USER_ID%はユーザーIDに設定されます。%USER_ID%がnullではなく、%REQUESTER_ID%がnullの場合、現在のアイデンティティ制約に対してトークン発行ポリシーを評価するときに使用されます。

問題

トークン発行ポリシーの評価に失敗した理由は、次のいずれかです。

- %RELYING_PARTY_ID%を参照するTokenServiceRPリソースが定義されておらず、トークン発行ポリシーに割り当てられていません。この場合、%RELYING_PARTY_ID%を参照するTokenServiceRPリソースを作成し、トークン発行ポリシーに割り当てます。

- %RELYING_PARTY_ID%を参照するTokenServiceRPリソースが存在し、トークン発行ポリシーに割り当てられていますが、ポリシーに満たされていない制約があります。この場合、ポリシー・ルールを確認します。ポリシーが正しい場合、クライアントはトークンをリクエストできません。それ以外の場合は、クライアントのアイデンティティを含むようにポリシー/制約を更新します。

エンドポイントの問題

問題: エンドポイントが見つかりません

OAM/OSTSコンソールを介して追加されたOracle Security Token Serviceエンドポイントにアクセスすると、WSDLポリシーを取得するときにページが存在しないか、エンドポイントが存在しないことを示すエラーがサーバーに返されます。

エラー・メッセージ

表示される可能性があるエラー・メッセージは次のとおりです。

- WSDLポリシーを取得するときに、404 HTTPエラー・コードが返されます。

- WS-Trustリクエストを送信するときに、エラーが報告されます。

<Error> <oracle.webservices.service> <OWS-04115> <An error occurred for port: PortableProvider: oracle.j2ee.ws.server.EndpointNotFoundException: /PATH.>

解決策

Oracle Security Token Serviceアプリケーションがデプロイされていますが、有効になっていません。Oracle Security Token Serviceを有効にするには、次の操作を実行します。

1. OAM管理コンソールに移動します。

2. 「システム構成」に移動し、「共通構成」、「使用可能なサービス」の順に選択します。

3. Oracle Security Token Serviceを有効にします。

Oracle Security Token Serviceで変更が検出され、エンドポイントが公開されます。再起動は不要です。

マッピング操作の問題

問題: AppliesTo要素をリライイング・パーティ・パートナにマップできません

Oracle Security Token ServiceでWebサービス・プロバイダを参照するAppliesTo要素を使用してWS-Trustリクエストを処理する場合、サーバーでは、パートナ・エントリに定義されているリソースURLを使用して、AppliesTo要素に含まれるロケーションをOracle Security Token Serviceリライイング・パーティ・パートナにマップしようと試みます。そのようなマッピングが失敗した場合、サーバーでは、操作が失敗したこと、および使用されたAppliesToアドレスを示す情報メッセージがログに記録されます。

エラー・メッセージ

エラー・メッセージのサンプルを次に示します。

[2011-04-22T15:08:12.632-07:00] [oam_server1] [NOTIFICATION] [STS-15542]
[oracle.security.fed.eventhandler.sts.creation.v13.CreateV13TokenEventHandler] [tid: [ACTIVE].ExecuteThread: '0' for
queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid:
f00aacae2d3f3ded:125005ed:12f7f412274:-8000-0000000000000016,0] [WEBSERVICE_PORT.name: wssuser-port] [APP:
oam_server] [J2EE_MODULE.name: sts] [WEBSERVICE.name: wssuser-serviceSoap12] [J2EE_APP.name: oam_server] The mapping
of the AppliesTo element from the WS-Trust Request to a Relying Party Partner failed: could not map
http://relying.party.test.com/testing/service

解決策

AppliesToロケーションをリライイング・パーティ・パートナにマップする必要がある場合は、リソースURLが次のように正しく定義されるようにパートナ設定を確認する必要があります。

- AppliesToアドレスと完全に一致

- AppliesToアドレスの親
たとえば、AppliesToアドレスがhttp://relying.party.test.com/testing/serviceの場合、親はhttp://relying.party.test.com/testing/またはhttp://relying.party.test.com/になります。どちらの場合も、AppliesToロケーションはそのリソースURLが定義されているリライイング・パーティ・パートナにマップされます。

注意:
このメッセージは通知レベルで記録されるため、OSTSで記録されるようにするには、Notification:1レベルを含むように、適切なロギング・レベルを設定する必要があります。

場合によっては、AppliesToアドレスをリライイング・パーティ・パートナに正しくマップできないと、次の理由によりエラーが発生します。

- 認証評価の失敗

- Oracle Security Token Serviceで、リライイング・パーティ・パートナに属している証明書を取得できない。

第VI部

共通のロギング、監査、パフォーマンス・モニタリング

第VI部では、Oracle Access ManagerおよびOracle Security Token Serviceのロギング、監査、およびパフォーマンス・モニタリングを行う際に役立つ情報を提供します。

第VI部の内容は次のとおりです。

- 第22章「コンポーネント・イベント・メッセージのロギング」

- 第23章「Webgateイベント・メッセージのロギング」

- 第24章「管理イベントとランタイム・イベントの監査」

- 第25章「Oracle Access Managerコンソールを使用したパフォーマンスのモニタリング」

- 第26章「Fusion Middleware Controlによるパフォーマンスおよびログの監視」

22 コンポーネント・イベント・メッセージのロギング

ロギングは、コンポーネントがファイルにメッセージを書き込むためのメカニズムです。管理者は、ロギング・メカニズムを使用して重要なコンポーネント・イベントを取得できます。Oracle Access ManagerおよびOracle Security Token Serviceのコンポーネントは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとガイドラインを使用しています。これはjava.util.loggingパッケージを使用して行いますが、このパッケージは標準的なもので、すべてのJava環境で使用できます。ロギング・システムはフラット・ファイルにのみ出力を書き出します。Oracle Databaseインスタンスへのロギングはサポートされていません。

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

ロギングの構成とログ・ファイルの検索がこの章の焦点です。ログ・ファイルの情報を使用した問題診断については、このマニュアルでは取り上げません。

注意:
特に明記しないかぎり、この章の情報は、Oracle Access Managerを単体で使用している場合もOracle Security Token Serviceとともに使用している場合も同じです。

この章の内容は次のとおりです。

- 前提条件

- コンポーネント・イベント・メッセージのロギングの概要

- Oracle Access Managerのロギング構成

- Oracle Security Token Serviceのロギング構成

- ランタイム・イベント・ロギング構成の検証

前提条件

この章のタスクを実行する前に、Oracle Access Managerコンソールと管理対象OAMサーバーが実行中であることを確認してください。

第6章「共通のOAMサーバー登録の管理」を確認することをお薦めします。

コンポーネント・イベント・メッセージのロギングの概要

ロギング・インフラストラクチャは、問題診断に使用できるメッセージを記録します。Oracle Security Token ServiceはJ2EE Webアプリケーションであり、Oracle Access Manager J2EEアプリケーションの一部になります。どちらもOJDLをロギング目的に使用します。Oracle Security Token Serviceは、パートナとの対話操作をタイムスタンプとともに取得します。管理者はメッセージに記録される情報の量を、ロガーが定義される各コンポーネントのログ・レベルを指定することにより制御します。

注意:
一般に、ユーザーは、問題診断のためにOracleテクニカル・サポートへ送るファイルを作成するためにロギングを有効にします。ログ・メッセージに関するドキュメントはありません。場合によっては、ログ・ファイルを参照することによってユーザー自身で問題を診断できることもあります。

Oracle Access ManagerおよびOracle Security Token Serviceは、次のWebLogicコンテナのロギング・デフォルトを使用します。

- ロギング構成ファイル: ロギング・レベルと、ロギングのためのその他の構成情報を提供します。このファイルは次のパスに保存されます: DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

- Oracle Access Managerログ・ファイル: DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

注意:
デフォルトでは、Oracle Security Token Serviceメッセージは管理対象サーバー・ログ・ファイルに記録されます。ただし、便宜上、「Oracle Security Token Serviceのロギング構成」で説明しているとおり、logging.xmlを編集してOracle Security Token Service情報を別のログ・ファイルに記録するようにできます。

次のイベントは自動的に記録されます。

- OAMサーバー・イベント(管理されたランタイム・サーバー)

- 管理イベント(コンソールを使用した構成変更に対して生成)

デフォルトでは、すべてのOracle Access ManagerおよびOracle Security Token Serviceコンポーネントのログ・レベルは通知レベルです。「エラー」レベルでのロギングで生成される出力は少量ですが、他のログ・レベルではロギング出力が大量になることがあり、その場合はパフォーマンスに影響します。本番環境では、通常はロギングを無効にするか、ロギング出力量が少くなるようなレベル(たとえばエラー・レベル)に設定します。

詳細は、次を参照してください。

- コンポーネント・ロガーについて

- サンプル・ロガーとログ・ハンドラ定義

- ロギング・レベルについて

関連項目:

- 第26章: Fusion Middleware Controlを使用してログを構成および表示する方法の詳細

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のロギング情報

コンポーネント・ロガーについて

この項では、Oracle Security Token ServiceとOracle Access Managerの両方のコンポーネント・ロガーを説明します。これらには違いがあります。

Oracle Security Token Serviceにあるロガーは、oracle.security.fedの1つのみです。詳細は、「Oracle Security Token Serviceのロギング構成」を参照してください。

次の表に示すように、それぞれのOracle Access Managerコンポーネントには対応するロガー名が関連付けられています。

- 表22-1「Oracle Access Managerサーバー側コンポーネント」

- 表22-2「Oracle Access Manager共有サービス・エンジン・コンポーネント」

- 表22-3「Oracle Access Manager基盤APIコンポーネント」

表22-1 Oracle Access Managerサーバー側コンポーネント

コンポーネント名

OAMロガー名

プロトコル・バインディング

oracle.oam.binding

SSOコントローラ

oracle.oam.controller.sso

OAMプロキシ

oracle.oam.proxy.oam

OSSOプロキシ

oracle.oam.proxy.osso

資格証明コレクタ

oracle.oam.credcollector

パートナのリモート登録

oracle.oam.engine.remotereg

Oracle Access Managerコンソール

oracle.oam.admin.console

管理サービス構成

oracle.oam.admin.service.config

診断とモニタリング

oracle.oam.diag

表22-2 Oracle Access Manager共有サービス・エンジン・コンポーネント

コンポーネント名

OAMロガー名

認証エンジン

oracle.oam.engine.authn

ポリシー・サービス・エンジン

oracle.oam.engine.policy

セッション管理エンジン

oracle.oam.engine.session

トークン・エンジン

oracle.oam.engine.token

SSOエンジン

oracle.oam.engine.sso

PartnerTrustMetadataエンジン

oracle.oam.engine.ptmetadata

認可エンジン

oracle.oam.engine.authz

表22-3 Oracle Access Manager基盤APIコンポーネント

コンポーネント名

OAMロガー名

セッション・アクセス

oracle.oam.session.access

セッション・アクセス実行

oracle.oam.session.accessimpl

ポリシー・アクセス

oracle.oam.policy.access

サンプル・ロガーとログ・ハンドラ定義

このトピックでは、Oracle Access Managerの例のみを示します。Oracle Security Token Serviceにあるのは、「Oracle Security Token Serviceのロギング構成」で説明しているように、ロガーとログ・ハンドラそれぞれ1つずつのみです。

例22-1は、logging.xmlファイルでのOracle Access Managerロガーとログ・ハンドラの構成を示します。

例22-1 Oracle Access Managerロガーとログ・ハンドラの構成

<logging_configuration>

<log_handlers>
<log_handler name='oam-handler' class='oracle.core.ojdl.logging.
ODLHandlerFactory'>
<property name='path' value='oam/diagnostic'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>
</log_handlers>

<loggers>
<logger name='oracle.security.am' level='NOTIFICATION:1'>
<handler name='oam-handler'/>
...
</logger>
</loggers>

</logging_configuration>

関連項目:
Java EEアプリケーション・ロギングの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の付録I、I.1.1項を参照してください。

ロギング・レベルについて

この項の内容は、Oracle Access ManagerとOracle Security Token Serviceに同様に適用されます。

ロガーにより出力されるデータの量はロガーのレベルによって制御され、レベルが高くなるほどより多くの情報が記録されます。ロガーのレベルは、logging.xmlファイルの中で<logger>要素により、次の書式で指定されます。

<logger name="loggerName" level="notifLevel"/>

ここで、loggerNameはロガー名であり(「コンポーネント・ロガーについて」を参照)、notifLevelはODLメッセージ・レベルとJavaメッセージ・レベルのどちらかです。

表22-4に、ODLメッセージ・レベルとJavaメッセージ・レベルの対応を昇順に示します。

表22-4 ODLレベルとJavaレベルの対応

ODLメッセージ・レベル

Javaメッセージ・レベル

INCIDENT_ERROR:1

SEVERE.intValue()+100

ERROR:1

SEVERE(例外を記録)

WARNING:1

WARNING(例外を記録)

NOTIFICATION:1

INFO(デフォルト)

NOTIFICATION:16

CONFIG

NOTIFICATION:32

INFOとCONFIG

TRACE:1

FINE(状況によっては本番環境に推奨)

TRACE:16

FINER(本番環境には推奨しない)

TRACE:32

FINEST(本番環境には推奨しない)

前述に挙げられていない他のJavaレベル値は(つまり、SEVERE.intValue()+100からFINESTまでの範囲にないもの)、ODLレベルのUNKNOWNに相当します。

注意:
メッセージを最も詳細レベルで記録するフィルタをoracle.security.fedパッケージおよびサブパッケージ(Oracle Security Token Serviceのクラス)に定義すると、サーバーを再起動した後でOracle Security Token ServiceによるOAMサーバーのログが表示されます。詳細は、「Oracle Security Token Serviceのロギング構成」を参照してください。

Oracle Access Managerのロギング構成

この項では、Oracle Access Managerのみのタスクを説明します。

関連項目:
「Oracle Security Token Serviceのロギング構成」

ロガー・レベルの変更に使用できるグラフィカル・ユーザー・インタフェースはありません。使用できるのはWLSTコマンドのみです。ここでは、次の内容について説明します。

- Oracle Access Managerのロガー・レベルの変更

- Oracle Access Manager固有のロガーとログ・ハンドラの追加

Oracle Access Managerのロガー・レベルの変更

管理者は、次に示す手順に従い、Oracle Access Manager用のカスタムWLSTコマンドを使用してロガーの設定を変更できます。実際のデプロイメントと選択肢は、説明と異なることがあります。

注意:
WLSTコマンドhelp("fmw diagnostics")を使用してください。

関連項目:
付録F「管理者用のカスタムWLSTコマンドの概要」

OAMロガー・レベルの変更方法

1. OAMサーバーが稼動中であることを確認します。

2. Oracle Access Manager用のカスタムWLSTスクリプトを取得します。次に例を示します。

<ORACLE_HOME>/common/bin/wlst.sh

3. WebLogic Serverに接続してWebLogic管理者としてログインします。次に例を示します。

sh wlst.sh wls:/offline> connect adminID password

4. OAMサーバーで使用可能なロガーをリストします。次に例を示します。

wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_
server1")

ここで、pattern=はoam.controllerコンポーネントを表し、target=は希望のOAMサーバー(登録時に指定されたもの)を表します。

5. このOAMサーバーに関連付けられているOracle Access Managerロガーのリストを表示します。次に例を示します。

Logger                                      | Level
--------------------------------------------+-----------------
oracle.oam                                  | <Inherited>
oracle.oam.admin.foundation.configuration   | <Inherited>
oracle.oam.agent-default                    | <Inherited>
oracle.oam.audit                            | <Inherited>
oracle.oam.binding                          | <Inherited>
oracle.oam.commonutil                       | <Inherited>
oracle.oam.config                           | <Inherited>
oracle.oam.controller                       | <Inherited>
oracle.oam.default                          | <Inherited>
oracle.oam.diagnostic                       | <Inherited>
oracle.oam.engine.authn                     | <Inherited>
oracle.oam.engine.authz                     | <Inherited>
oracle.oam.engine.policy                    | <Inherited>
oracle.oam.foundation.access                | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.user.identity.provider           | <Inherited>

6. 自身の要求に基づいてログ・レベルを変更します。たとえば、このシーケンスは、oam.controllerのログ・レベルを永続性のないTRACE:32に変更します。

wls:/base_domain/serverConfig> domainRuntime()
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam.controller",
level="TRACE:32", persist="0", target="oam_server1")

7. ステップ4を繰り返して再びロガーをリストし、ログ・レベルの変更を確認します。次に例を示します。

wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_
server1")

Logger                                      | Level
--------------------------------------------+-----------------
oracle.oam                                  | <Inherited>
oracle.oam.admin.foundation.configuration   | <Inherited>
oracle.oam.agent-default                    | <Inherited>
oracle.oam.audit                            | <Inherited>
oracle.oam.binding                          | <Inherited>
oracle.oam.commonutil                       | <Inherited>
oracle.oam.config                           | <Inherited>
oracle.oam.controller                       | TRACE:32
oracle.oam.default                          | <Inherited>
oracle.oam.diagnostic                       | <Inherited>
oracle.oam.engine.authn                     | <Inherited>
oracle.oam.engine.authz                     | <Inherited>
oracle.oam.engine.policy                    | <Inherited>
oracle.oam.foundation.access                | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.idm                              | <Inherited>
oracle.oam.user.identity.provider           | <Inherited>

8. 生成されたログ・ファイルを検証して、コントローラがTRACE:32レベルでロギングされていることを確認します。

DOMAIN_HOME/server/SERVER_INSTNCE_NAME/logs/

9. 「ランタイム・イベント・ロギング構成の検証」へ進みます。

Oracle Access Manager固有のロガーとログ・ハンドラの追加

管理者は、次の手順を使用してログ・ファイルのパスと必要な属性を指定できます。

次の手順では、ターゲットのOAMサーバー、ローテーション期間と保持期間、ログ・ファイルのパス、ハンドラ、およびロガーを確認します。実際のデプロイメントと選択肢は、説明と異なることがあります。

注意:
より詳しい内容を知るには、WLSTコマンドhelp("fmw diagnostics")を使用してください。

次の条件に合致する場合はステップ1から3をスキップしてください。

- OAMサーバーが稼動している

- WLSTスクリプトがある

- すでにサーバーに接続してログインしている

関連項目:
Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

OAMロガー、レベル、およびログ・ハンドラの指定方法

1. OAMサーバーが稼動中であることを確認します。

2. WLSTスクリプトを取得します。次に例を示します。

<ORACLE_HOME>/common/bin/wlst.sh

3. WebLogic Serverに接続してWebLogic管理者としてログインします。次に例を示します。

sh wlst.sh wls:/offline> connect

4. Oracle Access ManagerロガーとOAMサーバーのレベルを追加します。次に例を示します。

wls:/base_domain/serverConfig> domainRuntime()
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam",
level="WARNING", persist="0", target="oam_server1")

5. カスタム・ログ・ハンドラを追加して、それにOracle Access Managerロガーを関連付けます。次に例を示します。

wls:/base_domain/domainRuntime> configureLogHandler(name="oam-log-handler",
target="oam_server1", rotationFrequency="daily", retentionPeriod="week", path="${domain.home}/oamlogs" , maxFileSize ="10485760", maxLogSize = "104857600", addHandler="true", handlerType="oracle.core.ojdl.logging
.ODLHandlerFactory", addToLogger="oracle.oam")

wls:/base_domain/domainRuntime>configureLogHandler(name="oam-log-handler",
addProperty="true", propertyName="supplementalAttributes", propertyValue=
"OAM.USER, OAM.COMPONENT", target="oam_server1")

6. DOMAIN_HOME/oamlogsディレクトリの中のすべてのログを確認します。

DOMAIN_HOME/oamlogs/

Oracle Security Token Serviceのロギング構成

デフォルトでは、Oracle Security Token ServiceメッセージはOAMサーバーのログ・ファイルに記録されます。Fusion Middleware Controlでログを表示および構成できます。ただし、ここで説明するように、logging.xmlを編集してOracle Security Token Service情報を別のログ・ファイルに記録することもできます。

関係するファイルには次のものがあります。

- ロギング構成ファイル: ロガー名と、ロギング用のその他の構成情報を提供します。このファイルは、DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xmlに保存されます。

- Oracle Security Token Serviceログ・ファイル: たとえば、DOMAIN_HOME/ostslogs/SERVER-NAME-diagnostics.logです。

Oracle Security Token Serviceでは、ログ・ハンドラがOracle Access Managerのように分類されません。そのかわりに、Oracle Security Token Serviceのログ・レベルに影響を及ぼすロガーが1つのみあります。表22-5では、WLSTコマンドで必要となるこのロガーの詳細を示します。

表22-5 Oracle Security Token Serviceロガー

コンポーネント名

ログ出力名

ログ・ハンドラ名

ログ・クラス

Oracle Security Token Service

oracle.security.fed

sts-handler

class='oracle.core.ojdl.logging.ODLHandlerFactory'

詳細は、次の項目を参照してください。

- Oracle Security Token Serviceのロギング構成

- Oracle Security Token Serviceのログ・レベルとログ詳細の定義

関連項目:

- 第26章: Fusion Middleware Controlを使用してログを構成および表示する方法の詳細

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のロギング情報

Oracle Security Token Serviceのロギング構成

管理者は、次の手順を使用してOracle Security Token Serviceログ・メッセージをOAM Serverメッセージ・ログから切り離すことができます。

Oracle Security Token Serviceのロギングを構成する方法

1. 次のlogging.xmlを見つけて開きます。DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

2. 次のように追加して、Oracle Security Token Serviceの独立したメッセージ・ログを作成します。

<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHand
lerFactory'>
<property name='path' value='sts/log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>

<logger name='oracle.security.fed' level='TRACE:32'>
<handler name='sts-handler'/>
</logger>

3. ファイルを保存します。

4. 「Oracle Security Token Serviceのログ・レベルとログ詳細の定義」に進みます。

Oracle Security Token Serviceのログ・レベルとログ詳細の定義

管理者は、ここでの説明に従い、Oracle Access Manager用のカスタムWLSTコマンドを使用してOracle Security Token Serviceのロガー設定を変更できます。この場合は、Oracle Security Token Serviceログ・メッセージ専用の独立した出力ファイルを指定します。

このOracle Security Token Serviceロギングの手順例は、Oracle Access Managerの場合の手順とほとんど同じです。ただしいくつかの違いがあります。実際のデプロイメントの選択肢は、説明と異なることがあります。

注意:
WLSTコマンドhelp("fmw diagnostics")を使用してください。

次の条件に合致する場合はステップ1から3をスキップしてください。

- OAMサーバーが稼動している

- WLSTスクリプトがある

- すでにサーバーに接続してログインしている

関連項目:
付録F「管理者用のカスタムWLSTコマンドの概要」

Oracle Security Token Serviceのロガー・レベルとログ・ファイルを変更する方法

1. OAMサーバーが稼動中であることを確認します。

2. Oracle Access Manager用のカスタムWLSTスクリプトを取得します。

<ORACLE_HOME>/common/bin/wlst.sh

3. WebLogic Serverに接続してWebLogic管理者としてログインします。次に例を示します。

sh wlst.sh wls:/offline> connect adminID password

4. oracle.security.fedのログ・レベルを、自身の要求に基づいて変更します。たとえば、このシーケンスは、ログ・レベルを永続性のないWARNINGに変更します。

wls:/base_domain/serverConfig> domainRuntime()
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.security.fed",
level="WARNING", persist="0", target="oam_server1")

5. ターゲットのOAMサーバーの他に、ローテーション期間と保持期間、ログ・ファイルのパス、ハンドラ、およびロガーを指定します。次に例を示します。

wls:/base_domain/domainRuntime> configureLogHandler(name="osts-log-handler",
target="oam_server1", rotationFrequency="daily", retentionPeriod="week",
path="${domain.home}/ostslogs", maxFileSize ="10485760", maxLogSize
="104857600", addHandler="true",handlerType="oracle.core.ojdl.logging.ODL
HandlerFactory", addToLogger="oracle.security.fed")

6. 生成されたログ・ファイルを検証して、コントローラがWARNINGレベルでロギングされていることを確認します。

DOMAIN_HOME/ostslogs/SERVER-NAME-diagnostics.log

7. 「ランタイム・イベント・ロギング構成の検証」へ進みます。

ランタイム・イベント・ロギング構成の検証

次の手順を使用して、ランタイム・イベントのロギング構成をテストできます。

前提条件

- この章に示すWLSTコマンドを使用してロギングを構成します。

- エージェントとサーバーが稼動していることを確認します。

- 第13章、「リソースを保護してSSOを有効化するポリシーの管理」に従い、リソースを保護するためにアプリケーション・ドメインを構成します。

ランタイム・イベント・ロギングの検証方法

1. ブラウザで、保護されたリソースへのURLを入力し、無効な資格証明を使用してサインインします。

2. 正しい資格証明を使用して再度サインインします。

3. 物理サーバー上で、次のパスに生成されるすべてのログを検証します。

DOMAIN_HOME/oamlogs/
DOMAIN_HOME/ostslogs/SERVER-NAME-diagnostics.log

4. ログ・ファイルを開いて最後のエントリを探し、認証の失敗と成功を確認します。

23 Webgateイベント・メッセージのロギング

各Webgateインスタンス(10gおよび11g Webgateの両方)は、プロセスおよび状態に関する情報をログ・ファイルに書き込むことができます。ログは、様々なレベルの粒度で情報を提供するように設定できます。たとえば、エラーの記録、エラーおよび状態情報の記録、またはエラーと状態に加えてデバッグ・トレース・レベルのその他の情報を記録することもできます。また、ログから機密情報を削除することもできます。

注意:
特に明記しないかぎり、この項のすべての情報は10gと11gのWebgateに同様に適用されます。たとえば、ログ構成oblog_config_wg.xmlの場所は11gでは変更されましたが、ファイルの内容と他の詳細はほとんど変更されていません。

この章の内容は次のとおりです。

- ロギング、ログ・レベルおよびログ出力について

- ログ構成ファイルのパスおよび内容について

- ファイルまたはシステム・ファイルへのログ出力の送信について

- ログ構成ファイルの構造およびパラメータ

- ロギング・レベルのアクティブ化および抑制について

- 必須のログ・ハンドラ構成パラメータ

- 異なるデータのタイプへの異なるしきい値レベルの構成

- 機密属性のフィルタ処理

ロギング、ログ・レベルおよびログ出力について

ロギング機能により、システムのパフォーマンスおよび状態を分析し、問題をトラブルシューティングできます。

次のコンポーネントの個別のWebgateインスタンスのロギングを構成できます。

- 10g Webgate

- 11g Webgate

- カスタム・アクセス・クライアント(Access Manager SDK)

コンポーネント・インスタンスの異なる機能領域に対して別々のロギング・レベルを構成できます。たとえば、LDAPアクティビティのデバッグ・データを取得して、それ以外のすべてのコンポーネント・アクティビティではエラー・レベルのデータのみを記録できます。また、コンポーネントが処理する各リクエストで要する時間を記録し、異なるレベルのログ・データを別々の宛先に送信できます。たとえば、エラー情報をファイルに送信し、その他のログ・データをシステム・ログに送信できます。

機密情報の保護: Oracle Access Managerでは、ユーザーの機密情報が処理されます。サイトによって異なりますが、ユーザー・パスワード、誕生日、社会保障番号、ロスト・パスワード・リクエストに対するセキュリティ上の質問と回答などが含まれます。セキュリティ番号や保護の対象とするその他の情報も機密データに含めることができます。機密情報は、特定のロギング・レベルで取得されます。現在は、ログ・ファイルの機密情報をフィルタ処理できます(「機密属性のフィルタ処理」を参照してください)。

ロギングの構成: Webgateとともに格納される構成ファイルを編集して、ロギングを構成します。「ログ構成ファイルのパスおよび内容について」を参照してください。

ロギング・レベル: 様々なレベルで、ロギングをリクエストできます。最上位レベルは「致命的」で、最下位レベルは「トレース」です。詳細は、「ログ・レベルについて」を参照してください。

ログ出力先: ログ構成ファイルでは、ログ・ライターと呼ばれるパラメータがログ出力の宛先を決定します。詳細は、「ファイルまたはシステム・ファイルへのログ出力の送信について」を参照してください。ログ・ライターまたはログ・レベルを識別して、ログ出力の完全な定義を作成します。この完全な定義はログ・ハンドラと呼ばれます。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

この後の項では、次の項目について説明します。

- ログ・レベルについて

- ログ出力について

ログ・レベルについて

ロギング・レベルは、ログ・データ・ファイルに書き込まれるデータの量を決定します。各ロギング・レベルは累積的で、上位のレベルで生成されたすべてのデータが各レベルに含まれます。たとえば、エラー・ログには、致命的ログで生成されたすべてのデータに加えて、エラー・カテゴリに固有のイベントが含まれます。

表23-5にレベルを示します。デフォルトのログ・レベルは警告(LOGLEVEL_ WARNING)です。

表23-1 ロギング・レベル

レベル

レポートされるイベント数

説明

LOGLEVEL_ FATAL

> 60

クリティカル・エラーを記録します。一般に、これらのイベントは、コンポーネントの終了の原因になります。

システム障害が発生した場合は、致命的レベルのメッセージが常にログ・ファイルにフラッシュされます。

LOGLEVEL_ ERROR

> 960

コンポーネントが使用できないなど、修正処理を必要とする可能性のあるイベントを記録します。エラー・ログは、別のコンポーネントへの接続失敗など、一時的または自己修正可能な問題に対して生成されることもあります。

LOGLEVEL_ WARNING

> 1200

将来のある時点でエラーを引き起こす、または修正処理を必要とする可能性のある問題を記録します。

LOGLEVEL_ INFO

> 400

コンポーネントの初期化中など、コンポーネントの完了したアクションまたは現在の状態を記録します。

LOGLEVEL_ DEBUG1

> 400

デバッグ情報を記録します。通常は、このレベルの情報は開発者にとってのみ意味があります。

LOGLEVEL_ DEBUG2

> 100

詳細なデバッグ情報を記録します。このレベルは、Debug1ログ・レベルを補強します。通常は、このレベルの情報は開発者にとってのみ意味があります。

LOGLEVEL_ DEBUG3

> 900

大量のデバッグ情報またはコードの高コスト部分に関連するデータをログ・ファイルに記録します。このレベルは、タイト・ループやパフォーマンスに敏感なファンクションのデバッグに役立ちます。通常は、このログ・レベルの情報は開発者にとってのみ意味があります。

これらのログには、機密情報が含まれる場合があります。

LOGLEVEL_ TRACE

> 900 Oracle Access Manager API

> 150サード・パーティAPI

このログ・レベルは、コード・パス実行のトレースまたはパフォーマンス・メトリックの取得に使用されます。この情報は、各コンポーネント・ファンクションのエントリ・ポイントおよび終了ポイントで取得されます。通常は、このログ・レベルの情報は開発者にとってのみ意味があります。

これらのログには、機密情報が含まれる場合があります。

LOGLEVEL_ ALL

> 5000

このレベルには、その他のレベルすべてのイベントおよび状態がすべて含まれます。

複合リスト: 隣接していないレベルからログ・データを収集し、異なるレベルのログ・データを別々の宛先に送信できます。たとえば、致命的ログをシステム・ログに送信し、エラー・ログをファイルに書き込めます。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

しきい値: グローバル・カットオフまたはしきい値を構成して、ログ構成ファイルのLOG_THRESHOLD_LEVELパラメータでロギングできます。デフォルトでは、ログ・ハンドラの構成済レベルがカットオフを超えると、ログ・データは収集されません。LOG_THRESHOLD_LEVELパラメータがログ・ハンドラで構成されたレベルに優先するため、構成済レベルにかかわらず、ログが書込みに失敗する場合があります。ログ構成ファイルのMODULE_CONFIGセクションのみがグローバルしきい値をオーバーライドします。詳細は、「単純なリストおよびロギングしきい値」を参照してください。

オーバーライド: グローバル・ロギングしきい値に対する機能固有またはモジュール固有のオーバーライドを、MODULE_CONFIGパラメータに指定します。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

注意:
「トレース」および「デバッグ3」レベルのログには、機密情報が含まれる場合があります。機密情報の詳細は、「機密属性のフィルタ処理」を参照してください。

ログ出力について

ログ出力ファイルの各行は、特定の構造に従います。行は、日付およびタイム・スタンプで始まり、次にリクエストを処理するスレッド、ログが記録された機能またはモジュールの名前とログ・レベルが続きます。

次に、ログ出力ファイルの最も左の列のスナップショットを示します。

2007/06/01@00:50:56.859000    5932  2672  DB_RUNTIME     DEBUG3
2007/06/01@00:50:56.859000    5932  2672  DB_RUNTIME     TRACE
2007/06/01@00:50:56.859000    5932  2672  LDAP           DEBUG1
2007/06/01@00:50:56.859000    5932  2672  LDAP           TRACE
2007/06/01@00:50:56.859000    5932  2672  LDAP           TRACE

リグ・レベルの右の2つの列は内的コード参照で、無視できます。次に、この列の例を示します。

0x00000205   ldap_connection_mngr.cpp:212

内的参照列の右に、「コールされた機能」または「戻された機能」などのこのログ・レベルに割り当てられたログ・メッセージがあり、次に示すような機能の名前が続きます。

"Function called"   _CallName^ldap_init

ログ・メッセージおよび機能名の後に、次の例に示すように、処理の間隔、機能が実行されるアドレス領域または状態の情報などの追加情報が続く場合があります。

"Connection health check result"   Server^dlsun4072   Port^389   Server Priority^1     Connection available^true

"Function entered"    _TraceName^ConnectionWatcherThread::CheckPrimaries

"Function exited"     _TraceName^ConnectionWatcherThread::CheckPrimaries TraceDuration^0.000028

"Connection Pool Status in ValidateConnections()    "NumLivePrimaryConnections^1 Maximum Connections^1     UpConnections^1     Failover Threshold^1     Max Session Time^0    SleepFor^60

機密情報を保護して、ロギング操作の出力に含まれないようにする方法は、「機密属性のフィルタ処理」を参照してください。

関連項目:
「ログ構成ファイルの内容」

ログ構成ファイルのパスおよび内容について

ログ構成ファイルoblog_config_wg.xmlは、Webgateロギング(oblogs)の構成詳細を指定するために使用します。

プレーン・テキスト・エディタで編集するXMLベースのログ・ファイル内のWebgateログ出力を制御するパラメータを構成します。これらのファイルに対する変更は、即時に有効になります。

この後の項では、次の項目について説明します。

- ログ構成ファイルのパスおよび名前

- ログ構成ファイルの内容

ログ構成ファイルのパスおよび名前

デフォルトでは、Webgateロギングは有効であり、oblogsがOracle HTTP Server (OHS)インスタンス診断ディレクトリinstance1/diagnostics/logs/OHS/ohs1/に生成されます。

各Webgateインスタンスにはログ構成ファイル(oblog_config_wg.xml)があり、ここでログ出力内に記録するデータのタイプを定義します。ログ構成ファイルはログ出力ファイルとは異なります。ログ出力ファイルの詳細は、「ログ出力について」を参照してください。

oblog_config_wg.xmlファイルは、Webgateロギングを編集して構成すると更新されます。たとえば、新しいログしきい値レベルの設定、ログ・ファイル名の変更、またはいくつかのモジュールに関連するログのフィルタリングなどをした場合です。

ログ構成ファイルoblog_config_wg.xmlは、ご使用のWebgateバージョンに応じて次の場所に存在します。

10g Webgate: Webgate_install_dir\oblix\config

11g Webgate: Webgate/Oracle_Home under webgate/ohs/config and Instance_Home/webgate/config (以降はロギング構成時に使用)。

同じoblog_config_wg.xmlファイルは、Webgateインスタンスが作成されるとWebgateインスタンス・ディレクトリにコピーされます。Instance_Homeでは、このファイルはwebgate/configにあります。

注意:
このファイルのパスは変更しないでください。複数のインスタンスをインストールすると、インスタンスごとにログ構成ファイルがインストールされます。ロギングを構成するときは、Instance_Homeの下のoblog_config_wg.xmlを更新する必要があります。

インストール後は、oblog_config_wg.xmlとoblog_config_wg_original.xmlの両方に、編集のガイドとして役立つコメントが含まれます。

表23-2にログ構成ファイルの名前をリストします。名前を変更しないでください。

表23-2 コンポーネントのログ構成ファイル名

コンポーネント

ログ構成ファイル名

Webgate

oblog_config_wg.xml

Access Manager SDK (カスタム・アクセス・クライアント)

oblog_config.xml

重要:
いずれのロギング構成ファイルについても、デフォルトのパスまたは名前を変更しないでください。

oblog_config_wg.xmlファイルの編集では、ファイルを更新した後も有効なXMLであることが明確であれば、任意のテキスト・エディタを使用できます。ファイルの更新後、変更は約60秒で有効になります。

ログ構成ファイルの内容

ログ構成ファイルは次の項目を制御します。

- コンポーネントでログに記録される内容

- データの送信先

- 特定の場合のみ、ログで使用される書込みバッファのサイズ

- ログ・ファイル・ローテーション間隔

ログ構成ファイルにはテキスト・エディタで編集できるXML文が含まれます。

ファイルに対する変更が有効化した場合

ウォッチャ・スレッドは、ログ構成ファイルに対する変更を60秒ごとに取得し、その変更を有効にします。サーバーを再起動する必要はありません。

ログ・ファイル内のコメントについて

デフォルトの各ログ構成ファイルには、ファイルの編集に役立つコメントが含まれます。

関連項目:
ご使用のシステムのログ構成ファイル。

コメントのあるデフォルト構成ファイルをここに示します。

コメントは、1つ以上の行にまたがる場合があります。コメントは次のように表示されます。

<!--NetPoint Logging Configuration File                            -->
<!--                                                               -->
<!--Changes to this file will be automatically taken into  effect  -->
<!--in one minute. This does not require any server restart.       -->

例23-1に、コメントのある典型的なログ構成ファイルを示します。例23-8に、コメントのない典型的なログ構成ファイルを示します。

例23-1 コメントのあるデフォルトのログ構成ファイル

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!--============================================================   -->
<!--============================================================   -->
<!--NetPoint Logging Configuration File                            -->
<!--                                                               -->
<!--Changes to this file will be automatically taken into  effect  -->
<!--in one minute. This does not require any server restart.       -->
<!--                                                               -->
<!--============================================================   -->
<!--============================================================   -->
<!--Set the Log Threshold                                          -->
<!---->
<!--The log Threshold determines the amount of information to log. -->
<!--Selecting a lower level of logging includes the information    -->
<!--logged at the higher levels. For example, LOGLEVEL_ERROR       -->
<!--includes the information collected at LOGLEVEL_FATAL.          -->
<!---->
<!--Choices are:                                                   -->
<!--LOGLEVEL_FATAL - serious error, possibly a program halt.       -->
<!--LOGLEVEL_ERROR - a transient or self-correcting problem.       -->
<!--LOGLEVEL_WARNING - a problem that does not cause an error.     -->
<!--LOGLEVEL_INFO - reports the current state of the component.    -->
<!--LOGLEVEL_DEBUG1 - basic debugging information.                 -->
<!--LOGLEVEL_DEBUG2 - advanced debugging information.              -->
<!--LOGLEVEL_DEBUG3 - logs performance-sensitive code.             -->
<!--LOGLEVEL_TRACE - used when you need to trace the code path     -->
<!--execution or capture metrics. Includes all previous levels.    -->
<!--                                                               -->
<!--If you do not specify a threshold, the default is WARNING.     -->
<!--                                                               -->
<!--In addition to specifying a threshold, you need to specify     -->
<!--if changes that you make to the logging configuration in       -->
<!--the NetPoint GUI overwrite the settings in this file. The      -->
<!--AutoSync parameter accomplishes this. This parameter takes a   -->
<!--value of True or False. If set to True, changes made in the    -->
<!--GUI overwrite changes in this config file. If False, changes   -->
<!--made in the GUI are only in effect until the server is         -->
<!--stopped or restarted, after which the settings in this file    -->
<!--overwrite the GUI settings. The default is True.               -->
<!--                                                               -->
<!--                                                               -->
<CompoundList xmlns="http://www.oblix.com" ListName="logframework.xml.staging">
<SimpleList>
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
<NameValPair ParamName="AUTOSYNC" Value="True" />
<!-- SECURE_LOGGING flag can be used to turn on/off Secure Logging -->   <!-- feature. By defalut this feature is tunred on.                -->
<NameValPair ParamName="SECURE_LOGGING" Value="On" />
<!-- In addition to specifying a log threshold, you need to       -->
<!-- configure log level for which Secure Logging should be       -->
<!-- applicable.Choices for this can be used same as that of      -->
<!-- LOG_THRESHOLD_LEVEL. Secure log threshold can be set using   -->
<!-- LOG_SECURITY_THRESHOLD_LEVEL flag. Default value for Secure  -->
<!-- log threshold is TRACE.                                    -->
<NameValPair ParamName="LOG_SECURITY_THRESHOLD_LEVEL"
Value="LOGLEVEL_TRACE" />
<!-- LOG_SECURITY_ESCAPE_CHARS is used to configure escape sequence -->
<!-- characters. This can be used to avoid additional information   -->
<!-- getting overwritten due to Secure Logging mechanism. Currently -->
<!-- following characters have been identified as escape sequence.  -->
<!-- Configuring inappropriate characters may lead to sensitive     -->
<!-- information being unmasked.                                    -->
<NameValPair ParamName="LOG_SECURITY_ESCAPE_CHARS" Value="),]" />
<!-- LOG_SECURITY_MASK_LENGTH is used to specify default masking    -->
<!-- length if none is specified in FILTER_LIST.                    -->
<!-- Default value for LOG_SECURITY_MASK_LENGTH is 300.             -->
<NameValPair ParamName="LOG_SECURITY_MASK_LENGTH" Value="300" /   >
</SimpleList>
<!--                                                               -->
<!--                                                               -->
<!--============================================================   -->
<!--============================================================   -->
<!--Configure the Log Level                                        -->
<!--                                                               -->
<!--                                                               -->
<!--To configure a log level, you specify a name for the           -->
<!--configuration (for instance, MyErrorLog1) and                  -->
<!--the log level that you are configuring. You can create         -->
<!--more than one configuration per log level if you want          -->
<!--to output to more than one destination. You can output to      -->
<!--the system log or to a file, as specified on                   -->
<!--the LOG_WRITER parameter. The value for the LOG_WRITER         -->
<!--parameter may only be SysLogWriter, FileLogWriter or           -->
<!--MPFileLogWriter. The MPFileLogWriter is a multi-process safe   -->
<!--FileLogWriter. It should be used to log in webcomponents i.e   -->
<!--Webgate loaded on multiprocess     -->
<!--webservers like Apache and IPlanet(UNIX)                       -->
<!--                                                               -->
<!--If you do not specify an output destination, the default is    -->
<!--SysLogWriter.                                                  -->
<!--                                                               -->
<!--If outputting to a file, you also specify a file name and      -->
<!--other parameters. Default parameter values are:                -->
<!--FILE_NAME: <installdir>/oblix/log/oblog.log                    -->
<!--BUFFER_SIZE: 32767 (number of bytes)                           -->
<!--MAX_ROTATION_SIZE: 5242880 (bytes, equivalent to 5MB)          -->
<!--MAX_ROTATION_TIME: 86400 (seconds, equivalent to one day)      -->
<!--                                                               -->
<!--Configuring the log level does not ensure that the data is     -->
<!--actually collected. Data collection for a log is               -->
<!--determined by the LOG_THRESHOLD_LEVEL parameter, above,        -->
<!--and the LOG_STATUS parameter in the log configuration.         -->
<!--                                                               -->
<!--If you do not provide a LOG_STATUS, the default for            -->
<!--LOGLEVEL_FATAL, LOGLEVEL_ERROR, and LOGLEVEL_WARNING,          -->
<!--is On.                                                         -->
<!---->
<!--This file contains several sample configurations that are      -->
<!--enclosed in comments. To use them, remove the comments.        -->
<!--                                                               -->
<CompoundList xmlns="http://www.oblix.com" ListName="LOG_CONFIG">
<!--Write all FATAL logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogFatal2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<!--Write all logs to the Oracle log file.                     -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogAll2File">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ALL" />
<NameValPair ParamName="LOG_WRITER" Value="FileLogWriter" />
<NameValPair ParamName="FILE_NAME" Value="oblog.log" />
<!-- Buffer up to 64 KB (expressed in bytes) of log entries before         flushing to the file.     -->
<NameValPair ParamName="BUFFER_SIZE" Value="65535" />
<!--Rotate the log file once it exceeds 50 MB (expressed in bytes). -->
<NameValPair ParamName="MAX_ROTATION_SIZE" Value="52428800" />
<!--Rotate the log file after 24 hours (expressed in seconds). -->
<NameValPair ParamName="MAX_ROTATION_TIME" Value="86400" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
</CompoundList>
<!--  List of values that can be specified in the module config      -->
<!--                                                                 -->
<!--  On - Uses loglevel set in the loglevel threshold               -->
<!--  Off - No information is logged                                 -->
<!--  LOGLEVEL_FATAL - serious error, possibly a program halt.       -->
<!--  LOGLEVEL_ERROR - a transient or self-correcting problem.       -->
<!--  LOGLEVEL_WARNING - a problem that does not cause an error.     -->
<!--  LOGLEVEL_INFO - reports the current state of the component.    -->
<!--  LOGLEVEL_DEBUG1 - basic debugging information.                 -->
<!--  LOGLEVEL_DEBUG2 - advanced debugging information.              -->
<!--  LOGLEVEL_DEBUG3 - logs performance-sensitive code.             -->
<!--  LOGLEVEL_TRACE - used when you need to trace the code path     -->
<!--  execution or capture metrics. Includes all previous levels.    -->
<!--                                                                 -->
<!--  List of modules that can be specified in the module config     -->
<!--                                                                 -->
<!--  ALL_MODULES - Applies to all log modules                       -->
<!--  Specific module name - Applies to specific module              -->
<!--                                                                 -->
<!--                                                                 -->
<!--    <ValNameList                                                 -->
<!--        xmlns="http://www.oblix.com"                             -->
<!--        ListName="MODULE_CONFIG">                                -->
<!--        <NameValPair                                             -->
<!--            ParamName="CONNECTIVITY"                             -->
<!--            Value="LOGLEVEL_TRACE"></NameValPair>                -->
<!--    </ValNameList>                                               --><!--   <!--FILTER_LIST is used to maintain list of attributes which need         -->
<!-- to be treated as sensitive and hence will be filtered out from   -->
<!-- from logs. FILTER_LIST consist of all attribute names along      -->
<!-- with corresponding masking lengths.There should be separate      -->
<!-- entry in the list for the display name of the attribute          -->
<!-- identified as sensitive. All attributes configured are case      -->
<!-- sensitive i.e. if we configured sensitive attribute homePhone    -->
<!-- as HomePhone then it will not get filtered out from logs.        -->
<!-- By default four attributes (password, Password, response and     -->
<!-- Response) are configured as sensitive                            -->
<!-- A sample configuration is shown below                            -->

<!-- <ValNameList                                                    -->
<!--    xmlns="http://www.oblix.com"                                 -->
<!--    ListName="FILTER_LIST">                                      -->
<!--    <NameValPair                                                 -->
<!--      ParamName="password"                                       -->
<!--      Value="40"></NameValPair>                                  -->
<!--    <NameValPair                                                 -->
<!--      ParamName="Password"                                       -->
<!--      Value="40"></NameValPair>                                  -->
<!--    <NameValPair                                                 -->
<!--      ParamName="response"                                       -->
<!--      Value="40"></NameValPair>                                  -->
<!--     <NameValPair                                                -->
<!--      ParamName="Response"                                       -->
<!--      Value="40"></NameValPair>                                  -->
<!--    <NameValPair                                                 -->
<!--      ParamName="homePhone"                                      -->
<!--      Value="40"></NameValPair>                                  -->
<!--  </ValNameList>                                                 -->
<ValNameList xmlns="http://www.oblix.com" ListName="FILTER_LIST">
<NameValPair ParamName="password" Value="40" />
<NameValPair ParamName="Password" Value="40" />
<NameValPair ParamName="passwd" Value="40" />
<NameValPair ParamName="Passwd" Value="40" />
<NameValPair ParamName="response" Value="40" />
<NameValPair ParamName="Response" Value="40" />
</ValNameList>
</CompoundList>

ファイルまたはシステム・ファイルへのログ出力の送信について

ログ出力を送信先へ送信するには、ログ・ライターを構成します。ログ・ライターはログ出力を次のうちの一方または両方に送信することも、いずれにも送信しないようにすることもできます。

- ログ・ファイル
このファイルは、コンポーネントのルート・インストール・ディレクトリの下にあります。

- コンポーネントに対するホストのシステム・ファイル
複数のコンポーネントが同じホストに存在する場合、すべてのコンポーネントがそのホスト上のシステム・ログ・ファイルにデータを送信します。

特定のレベルのログまたは異なるレベルのログを、複数のタイプのログ・ライターに送信できます。たとえば、致命的データをシステム・ログに送信し、トレース・データをファイルに送信できます。または、致命的データをシステム・ログとファイルの両方に送信できます。

ログ・ハンドラ定義にあるLOG_WRITERパラメータを使用して、ログ構成ファイル内のログ・ライターを定義します。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

ログ・ライターについて、表23-3で説明します。

表23-3 ログ・ライター

ライター

説明

SysLogWriter

ログに記録されるコンポーネントをホストするコンピュータのシステム・ログ・ファイルにデータを送信します。通常、システム・ログ・ファイルには、複数のアプリケーションおよびホスト・オペレーティング・システムによるイベント情報が含まれます。

Windowsマシンの場合、これは「マイ コンピュータ」、「管理」、「イベント ビューア」、「アプリケーション」にあるアプリケーション・ログ・ファイルです。

UNIXプラットフォームの場合、システム・ログ・ファイルの名前と場所は、システム管理者のコンピュータとプリファレンスに応じて異なります。ファイルの場所は、コンピュータの管理者に確認してください。

デフォルトのログ構成ファイルは、致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログ・ファイルに送信します。

FileLogWriter

このライターは、OAMサーバーまたはその他のシングルプロセス・アプリケーションのログ・データをディスク・ファイルに保存する場合にお薦めします。

FileLogWriterは、ログ・ファイルを開き、おおよそのファイル・サイズ制限またはファイル・ローテーション間隔に達するまでディスク書込み用にファイルを開いたままにします。複数のプロセスが同じログ・ファイルに書き込む必要のある状況では、このログ・ライターをお薦めしません。このような状況では、MPFileLogWriterを使用してください。

MPFileLogWriter

このライターは、FileLogWriterに似ていますが、データをファイルに書き込むたびにログ・ファイルを開いて閉じる点が異なります。これにより、複数のプロセスが順番にファイルに書き込むことができます。ただし、これによってパフォーマンスが大幅に低下します。

MPFileLogWriterは、マルチプロセスWebサーバー(Apacheなど)またはSolarisバージョンのiPlanet Webサーバーにインストールされているアクセス・クライアントなど、マルチプロセス・アプリケーションに関連するプロセスの一部で、FileLogWriterがロギング・データの記録に失敗する場合にのみ使用することをお薦めします。

ログ構成ファイルの構造およびパラメータ

ログ構成ファイルは標準形式に準拠します。パラメータの編集や、ログ・ハンドラ定義と呼ばれる特定のセクションの追加または除去はできますが、ログ構成ファイルの基礎となる形式の変更はできません。

デフォルトのログ構成ファイルのリストは、例23-1または例23-8を参照してください。

この後の項では、次の項目について説明します。

- ログ構成ファイルのヘッダー

- 最初の複合リスト

- 単純なリストおよびロギングしきい値

- 2番目の複合リストおよびログ・ハンドラ

- モジュール固有のロギングのリスト

- フィルタ・リスト

- XML要素の順序について

ログ構成ファイルのヘッダー

ログ構成ファイルの先頭には、XMLファイル・ヘッダーがあります。

<?xml version="1.0" encoding="ISO-8859-1" ?>

ヘッダーは次の目的で使用します。

- ヘッダーは、関連するXMLバージョン(常に1.0)を宣言します。

- また、エンコーディング形式(常にISO-8559-1)を宣言します。

最初の複合リスト

ヘッダーの後に、次のように区切られた最初の複合リストが続きます。

<CompoundList xmlns="http://www.oblix.com" ListName="logframework.xml.staging">
. . .
</CompoundList>

最初の複合リストの構造は次のとおりです。

- 複合リスト開始タグは、xmlnsパラメータ内のログ構成ファイルの関連XMLネームスペースを示します。

- また、複合リスト開始タグは、ListNameパラメータ内の複合リストの名前を指定します。

- 複合リスト終了タグは、ファイルの最後の近くで発生します。
この複合リストは、すべての構成情報を区切ります。

単純なリストおよびロギングしきい値

最初の複合リスト開始タグの後に、次のように、単純なリストでロギングのグローバル・デフォルトを設定します。

<SimpleList>
. . .
</SimpleList>

単純なリストの開始タグと終了タグとの間は、次のように構成します。

表23-4 最初の複合リストのグローバル・パラメータ

パラメータ

説明

LOG_LEVEL_THRESHOLD

デフォルトのロギングしきい値を設定します。

デフォルト値: LOGLEVEL_WARNING

使用可能な値: 「ログ・レベルについて」に記載されているログ・レベルを参照してください。

グローバルしきい値により、特定のレベルおよびより一般的なレベルのログを収集し、下位レベルのログが収集されるのを防ぐことができます。このしきい値は、モジュール固有のしきい値でオーバーライドされます。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

SECURE_LOGGING

セキュア・ロギングのメカニズムを動的に有効化または無効化します。サーバーやコンポーネントを再起動する必要はありません。

デフォルト値: On

使用可能な値: OnまたはOff

LOG_SECURITY_THRESHOLD_LEVEL

セキュア・ロギングが有効なログしきい値を示します。

デフォルト値: LOGLEVEL_TRACE

使用可能な値: 「ログ・レベルについて」に記載されているログ・レベルを参照してください。

注意: LOG_THRESHOLD_LEVELとLOG_SECURITY_THRESHOLD_LEVELが同じか、互いに一貫性があることを確認してください。たとえば、LOG_THRESHOLD_LEVELがLOGLEVEL_TRACEに設定されており、LOG_SECURITY_THRESHOLD_LEVELがLOGLEVEL_WARNINGに設定されている場合、セキュア・ロギングはLOGLEVEL_WARNING以上に適用されますが、LOGLEVEL_TRACEには適用されません。

LOG_SECURITY_ESCAPE_CHARS

セキュア・ロギングのメカニズムによって追加の情報が上書きされるのを防ぐための、エスケープ・シーケンス文字を構成します。カンマ区切りリストを使用します。

デフォルト値: ),]

使用可能な値: 文字のみ

注意: デフォルト値を推奨します。不適切な文字を構成すると、機密情報がマスキングされない可能性があります。

LOG_SECURITY_MASK_LENGTH

FILTER_LISTで指定されていない場合に、デフォルトのマスキングの長さを指定します。

デフォルト値: 300

使用可能な値: 正の整数

注意: FILTER_LISTは、2番目の複合リスト(ログ・ハンドラ)の後に表示されます。詳細は、「機密属性のフィルタ処理」を参照してください。

例23-2は、oblog_config_wg.xmlファイルの最初の複合リストに表示されるグローバル設定を含む単純なリストを示しています。

例23-2 グローバル設定を含む単純なリスト(oblog_config_wg.xmlファイルの最初の複合リスト)

<SimpleList>
<NameValPair
ParamName="LOG_THRESHOLD_LEVEL"
Value="LOGLEVEL_WARNING">
</NameValPair>
<NameValPair
ParamName="AUTOSYNC"
Value="True">
</NameValPair>
<NameValPair
ParamName="SECURE_LOGGING"
Value="On">
</NameValPair>
<NameValPair
ParamName="LOG_SECURITY_THRESHOLD_LEVEL"
Value="LOGLEVEL_TRACE">
</NameValPair>
<NameValPair
ParamName="LOG_SECURITY_ESCAPE_CHARS"
Value="),]">
</NameValPair>
<NameValPair
ParamName="LOG_SECURITY_MASK_LENGTH"
Value="300">
</NameValPair>
</SimpleList>

2番目の複合リストおよびログ・ハンドラ

グローバル設定を含む単純なリストの後と最初の複合リストの開始タグおよび終了タグの間に、追加の複合リストを指定します。この複合リストには、ログ・ハンドラ定義が含まれます。このリストの開始タグおよび終了タグは次のとおりです。

<CompoundList xmlns="http://www.oblix.com" ListName="LOG_CONFIG">
. . .
</CompoundList>

この複合リスト・タグは、次のように構成されます。

- 複合リスト開始タグ内で、xmlnsパラメータは関連XMLネームスペースを示します。

- また、開始タグでは、リストの名前をListNameパラメータに指定します。
通常、このリストの名前はLOG_CONFIGです。

ログ・ハンドラの複合リストの開始タグと終了タグとの間に、1つ以上のValNameList要素を指定します。各ValNameList要素には、ログ・ハンドラ定義が含まれます。この要素の各インスタンスの開始と終了は、次のとおりです。

<ValNameList xmlns="http://www.oblix.com" ListName="Unique_Name">
. . .
</ValNameList>

ValNameList要素は次のように構成されます。

- 開始タグは、関連XMLネームスペースをxmlnsパラメータに設定します。

- また、開始タグは、ログ・ハンドラの名前をListNameパラメータに設定します。

ValNameListの開始タグと終了タグとの間に、ログ・ハンドラを構成します。ログ・ハンドラ定義には、3つの必須NameValPair要素が含まれます。

- 最初のNameValPair要素は、ログ・ハンドラのロギング・レベルを定義します。
この要素にはParamName="LOG_LEVEL"文が含まれ、その値は次のように表23-1の予約名です。

<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />

- 2番目のNameValPair要素は、ログ出力の宛先を定義します。
この要素にはParamName="LOG_WRITER"文が含まれ、その値は次のように表23-3の予約名です。

<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />

- 3番目のNameValPair要素は、ログ・ハンドラのオンとオフを切り替えます。
この要素にはParamName="LOG_STATUS"文が含まれ、次のように、OnまたはOffの値を伴います。

<NameValPair ParamName="LOG_STATUS" Value="On" />

最後に、ValNameListの開始タグと閉じタグ内で、FileLogWriterまたはMPFileLogWriterをログ・ライターとして指定すると、次のうちの一部またはすべてを追加するか、いずれも追加しないようにできます。詳細は、表23-7を参照してください。

- 宛先ファイル名

<NameValPair ParamName="FILE_NAME" Value="oblog.log" />

- バッファ・サイズ

<NameValPair ParamName="BUFFER_SIZE" Value="65535" />

- 新しいログ・ファイルが生成される時期を決定するファイル・サイズ

<NameValPair ParamName="MAX_ROTATION_SIZE" Value="52428800" />

- 新しいログ・ファイルが生成される間隔を決定する時間(分)

<NameValPair ParamName="MAX_ROTATION_TIME" Value="86400" />

モジュール固有のロギングのリスト

ログ・ハンドラを区切る複合リスト終了タグの後および最初の複合リストの終了タグの前に、モジュール固有のロギング・パラメータを追加できます。

詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

フィルタ・リスト

モジュール固有のロギング・パラメータの後で、ログ・ファイルからフィルタ除去する必要がある機密情報がフィルタ・リストにより識別されます。たとえば、パスワードとパスワードを忘れた場合の応答は、ログ・ファイルからフィルタで除去する必要がある機密情報です。

FILTER_LISTパラメータに関連付けられている名前と値の各ペアは、ログへの書込みの前にチェックする単語やフレーズの名前、およびその単語またはフレーズのマスキングの長さを指定します。ロギング時には、その単語またはフレーズがマスキングされ、ログ・ファイルから削除されます。

つまり、ロギング時には、Oracle Access Managerはマスキングされる値が属性、表示名またはそれ以外のもの(プレーン・テキスト)のいずれであるかを認識しません。セキュア・ロギングは、FILTER_LISTに追加された単語またはフレーズを検索し、検出されたそれらの単語やフレーズの後に続くすべてのデータをマスキングすることで実行されます。たとえば、次のような文があるとします。

\csabuild\coreid1014\np_common\db\ldap\util\ldap_util3.cpp:3107 "ldap_parse_result
of Simple Bind"           ld handle^0x0779FA00       result^0x09FB0088
bind^cn=orcladmin        LDAP bind operation status code^0          Additional
error message^ freeit^0 parse_rc^0

セキュア・ロギングを有効にしてFILTER_LISTに(属性でも表示名でもない)"bind"を追加すると、FILTER_LIST内の単語(ここではbind)に続くすべてのデータがマスキングされます。この例の場合、ログの内容は次のように表示されます。

\csabuild\coreid1014\np_common\db\ldap\util\ldap_util3.cpp:3107 "ldap_parse_result
of Simple Bind"           ld handle^0x0779FA00       result^0x09FB0088
bind^cn=orcladmin        LDAP bind**********  status code^0          Additional
error message^ freeit^0 parse_rc^0

すべての属性は大/小文字が区別されます。たとえば、属性の表示名としてPasswordではなくpasswordと入力した場合、Passwordはフィルタ処理されません。デフォルトでは、password、Password、responseおよびResponseの4つの属性が、フィルタ・リスト内で常に構成されています。

デフォルトのマスキングの長さは40で、これら4つのデフォルト属性に対して個々に指定されています。デフォルト属性のデフォルトのマスキングの長さは、必要に応じて変更できます。フィルタ・リストにその他の属性を追加する場合は、マスキングの長さとして、より大きい値が必要になる可能性があります(例: 300)。

デフォルトのフィルタ・リストを例23-3に示します。

例23-3 FILTER_LISTによるログ・ファイル内の機密属性のマスキング

<ValNameList>
xmlns="http://www.oblix.com"
ListName="FILTER_LIST">
<NameValPair
ParamName="password"
Value="40"></NameValPair>
<NameValPair
ParamName="Password"
Value="40"></NameValPair>
<NameValPair
ParamName="passwd"
Value="40"></NameValPair>
<NameValPair
ParamName="Passwd"
Value="40"></NameValPair>
<NameValPair
ParamName="response"
Value="40"></NameValPair>
<NameValPair
ParamName="Response"
Value="40"></NameValPair>
</SimpleList>

フィルタ・リストに別の属性を追加する場合は、表示名および属性名をディレクトリ・サーバーに含める必要があります。

XML要素の順序について

XMLを使用する場合、要素自体が変更されず、最初に囲まれていたタグ内に含まれているかぎり、リスト内で並列の要素を任意の順序で指定できます。たとえば、例23-4と例23-5のリストは同等です。

例23-4 有効な名前/値リスト

<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>

例23-5 別の有効な名前/値リスト

<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys">   <NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />   <NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" />   <NameValPair ParamName="LOG_STATUS" Value="On" /></ValNameList>

同様に、ある特定のタグ内の属性(常にタグの山カッコ内の最初の要素である必要があるタグ名を除く)は、変更されておらず、最初に囲まれていたタグ要素内にあるかぎり、並べ替えることができます。例23-6と例23-7の名前/値リストの開始タグは同等です。

例23-6 名前/値リストの開始タグ

<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys">

例23-7 名前/値リストの開始タグ

<ValNameList ListName="LogError2Sys" xmlns="http://www.example.com">

ロギング・レベルのアクティブ化および抑制について

様々な要因により、ロギングが特定のログ・ハンドラに対してアクティブかどうかが決まります。表23-5に、これらの要因をリストします。

表23-5 ロギングがアクティブかどうかを決定する要因

要因

重要度

説明

LOG_ THRESHOLD_ LEVEL

プライマリ

このパラメータは、ロギングのカットオフを設定します。しきい値よりも詳細なログ・レベルは抑制されます。有効なログ・レベルは、表23-1を参照してください。

MODULE_CONFIGパラメータを使用して、ログを記録できる項目のサブセットに対してこのパラメータをオーバーライドできます。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

MODULE_CONFIG

プライマリ

このパラメータは、グローバル・ロギングしきい値のモジュール固有のオーバーライドを設定します。

詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

LOG_STATUS

セカンダリ

このパラメータは、ロギングしきい値またはモジュール固有のオーバーライドで上書きされないかぎり、ロギングのオンとオフを切り替えます。

ログ・ハンドラの物理的な位置

セカンダリ

「ログ・ハンドラの優先順位について」を参照してください。

ログ・ハンドラの優先順位について

ログ構成ファイルに単一のログ・レベルに対して最大3つのログ・ハンドラ定義を構成できます。特定のログ・レベルの出力を、表23-3で説明される3つの各ログ・ライターに送信する場合は、3つの異なるログ・ハンドラが必要です。

異なるLOG_STATUS設定をこれらのログ・ハンドラに設定する場合、ログ構成ファイルの物理的な終わりに最も近いログ・ハンドラ定義の設定が、同一のログ・レベルの他のログ・ハンドラ定義のステータスを設定します。たとえば、「エラー」ログ・レベルの最初の2つのログ・ハンドラに対してLOG_STATUSをOffに設定できますが、構成ファイル内の3番目の最後のログ・ハンドラに対してLOG_STATUSをOnに設定すると、ロギングは3つのハンドラすべてに対して行われます。

LOG_STATUS設定は、そのレベルが現在のLOG_THRESHOLD_LEVELよりもきめ細かい場合には、無意味になります。この場合、しきい値がモジュール固有のしきい値でオーバーライドされないかぎり、ロギングはこのレベルでアクティブ化されません。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

必須のログ・ハンドラ構成パラメータ

各ログ・ハンドラ定義には、最低でも、表23-6にリストする5つのパラメータが含まれます。

表23-6 必須のログ構成ファイル・パラメータ

パラメータ

コメント

xmlns

このパラメータはValNameList開始タグ内で指定されます。

現在のリストの関連XMLネームスペースを指定し、ある特定のロギング構成ファイル内のすべてのログ・ハンドラ定義に対して同一です。次に例を示します。

http://www.example.com

ListName

このパラメータはValNameList開始タグ内で指定されます。可能な場合はデフォルト名を使用します。

新規のログ・ハンドラ定義の作成の際、他のログ・ハンドラと間違えることのない憶えやすい名前を選択してください。次に例を示します。

WarningsAndAboveToSyslogは、致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログ・ファイルに送信します。

WarningsOnlyToFileLog128KBufferは、警告レベルのメッセージを128KBバッファに従ってディスク・ファイルに送信します。

TraceOnlyToMPRotateDailyはメッセージをトレース・レベルのみからマルチプロセス・ファイル・ライターへ送信し、マルチプロセス・ファイル・ライターはファイルをディスクへ書き込むたびに開いて閉じます。このファイルは、置換時のファイルのサイズには関係なく、新しい(空の)ファイルで毎日置換されます。

LOG_LEVEL

これにより、ログ・レベルが指定されます。詳細は、表23-1を参照してください。

デフォルトのロギング構成ファイルは、「致命的」、「エラー」、「警告」の3つのレベルのロギングをアクティブにします。

LOG_WRITER

このログ・ライターのログ出力の宛先を指定します。詳細は、表23-3を参照してください。

デフォルトのログ構成ファイルは、出力をシステム・ログとロギングを行っているコンポーネントのログ・データ・ファイルの両方に送信します。

LOG_STATUS

このパラメータは、ログ・ハンドラを「オン」または「オフ」にします。

LOG_WRITERパラメータの値としてFileLogWriterまたはMPFileLogWriterを指定した場合は、表23-7の4つのパラメータが意味を持ちます。

表23-7 ログ・データ・ファイル構成パラメータ

パラメータ

説明

デフォルト

FILE_ NAME

必須です。FileLogWriterまたはMPFileLogWriterのみに使用します。ログ・データが書き込まれるファイルの名前と場所です。

ファイル名に絶対パスを付加して、次のデフォルトの場所以外に格納できます。

Webgate_install_dir\oblix\logs

component_install_dirは、システム・イベントをロギングするコンポーネントのルート・インストール・ディレクトリです。

出力をFileLogWriterまたはMPFileLogWriterに送信する複数のログ・ハンドラ定義を作成した場合は、各ケースに一意のファイル名を指定して、複数のハンドラが同じファイルに書込みを試行しないようにします。この注意事項は、SysLogWriterにアクセスしているログ・ハンドラには適用されません。

oblog.log

BUFFER_SIZE

オプション。これは、ログ・ファイルに書き込まれるログ・データのバッファのサイズ(バイト単位)です。

バッファ値をゼロ(0)または負の数に設定した場合、デフォルト値が使用されます。バッファせずにログ・ファイルを即座に書き込む場合、5などの小さい値に設定します。システムに障害がある場合、小さいバッファ・サイズを設定することをお薦めします。

65535

(64KB)

MAX_ ROTATION_ SIZE

オプション。ログ・ファイルがこのサイズ(バイト単位)に達すると、タイムスタンプがファイル名に追加されます。たとえば、"oblog.log"は"oblog.log1081303126"になります。新しいデータは、元の名前のファイルに書き込まれます。

52428800

(512KB)

MAX_ ROTATION_ TIME

オプション。最大ローテーション・サイズに達したかどうかにかかわらず、ログ・ファイル名が変更される時間間隔(秒単位)です。

ローテーション時間によってファイルがいつローテーションされるかが決定する場合、ログ・ファイルに追加される数値はローテーション間隔の秒数だけ異なります。たとえば、oblog.log.1081389526とoblog.log.1081303126には86,400 (24時間を秒で表した数値)の差があります。これは、ログ構成ファイルで設定されたローテーション間隔です。

86400

(1日の秒数)

デフォルトのログ構成ファイルの設定

各コンポーネントとともにインストールされるログ構成ファイルは、ログに記録されるイベントの階層の上位3つのレベル(「致命的」、「エラー」および「警告」)のみアクティブにし、すべてのログ出力をシステム・ログに送信ます。

Windowsコンピュータでは、「マイ コンピュータ」、「管理」、「イベント ビューア」、「アプリケーション」にナビゲートすることで、ロギングしているコンポーネントをホストするコンピュータのシステム・ログを表示できます。ログに記録されるコンポーネントのシステム・イベント・エントリは、オペレーティング・システムおよびOracle Access Manager以外のアプリケーションに対してレポートされるシステム・イベントに散在します。

SolarisおよびLinux環境の場合、システム・ログの場所はシステム構成ファイルに記録されますが、このシステム構成ファイルの細目はコンピュータごとに異なる場合があります。このシステム・ファイルやシステム・ログの名前と場所については、システム・ログを調べるコンポーネントのホストとなるコンピュータの所有者に相談してください。

例23-8に、デフォルトのログ構成ファイルを示します。ここでは、ファイル構造を明らかにするためにコメントを削除してあります。

例23-8 埋込みコメントなしのデフォルトのログ構成ファイル

<?xml version="1.0" encoding="utf-8"?>
<CompoundList
xmlns="http://www.oblix.com
ListName="oblog_config_wg.xml.staging">
<SimpleList>
<NameValPair
ParamName="LOG_THRESHOLD_LEVEL"
Value="LOGLEVEL_WARNING"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="AUTOSYNC"
Value="True"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="SECURE_LOGGING"
Value="On"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="LOG_SECURITY_THRESHOLD_LEVEL"
Value="LOGLEVEL_TRACE"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="LOG_SECURITY_ESCAPE_CHARS"
Value="),]"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="LOG_SECURITY_MASK_LENGTH"
Value="300"></NameValPair>
</SimpleList>
<CompoundList
xmlns="http://www.oblix.com"
ListName="LOG_CONFIG">
<ValNameList
xmlns="http://www.oblix.com"
ListName="LogFatal2Sys">
<NameValPair
ParamName="LOG_LEVEL"
Value="LOGLEVEL_FATAL"></NameValPair>
<NameValPair
ParamName="LOG_WRITER"
Value="SysLogWriter"></NameValPair>
<NameValPair
ParamName="LOG_STATUS"
Value="On"></NameValPair>
</ValNameList>
<ValNameList
xmlns="http://www.oblix.com"
ListName="LogAll2File">
<NameValPair
ParamName="LOG_LEVEL"
Value="LOGLEVEL_ALL"></NameValPair>
<NameValPair
ParamName="LOG_WRITER"
Value="FileLogWriter"></NameValPair>
<NameValPair
ParamName="FILE_NAME"
Value="oblog.log"></NameValPair>
<NameValPair
ParamName="BUFFER_SIZE"
Value="65535"></NameValPair>
<NameValPair
ParamName="MAX_ROTATION_SIZE"
Value="52428800"></NameValPair>
<NameValPair
ParamName="MAX_ROTATION_TIME"
Value="86400"></NameValPair>
<NameValPair
ParamName="LOG_STATUS"
Value="On"></NameValPair>
</ValNameList>
</CompoundList>
<ValNameList
xmlns="http://www.oblix.com"
ListName="FILTER_LIST">
<NameValPair
ParamName="password"
Value="40"></NameValPair>
<NameValPair
ParamName="Password"
Value="40"></NameValPair>
<NameValPair
ParamName="passwd"
Value="40"></NameValPair>
<NameValPair
ParamName="Passwd"
Value="40"></NameValPair>
<NameValPair
ParamName="response"
Value="40"></NameValPair>
<NameValPair
ParamName="Response"
Value="40"></NameValPair>
</ValNameList>
</CompoundList>

デフォルトのログ構成ファイルの設定の説明

デフォルトの構成ファイルは致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログとoblog.logというログ・データ・ファイルの両方に送信します。

ファイルの上部近くにある単純なリストは、次のパラメータを設定します。

- これはLOG_THRESHOLD_LEVELをWarningに設定します。
しきい値は警告よりもきめ細かいレベルのロギングを抑制します。このしきい値はオーバーライドできます。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

ネストした複合リストには、4つのログ・ハンドラ定義が含まれます。

- LogFatal2Sysという名前の最初のログ・ハンドラ定義は、ロギング・レベルをFatalに設定し、LOG_STATUSをOnに設定します。
しきい値レベルは警告で、致命的よりもきめ細かいため、この定義は有効になりません。LOG_WRITERパラメータで指定されたように、ログ出力はシステム・ログに書き込まれます。

- LogError2Sysログ・ハンドラ定義は、エラー・レベル・メッセージをシステム・ログに送信します。
エラーは現在のしきい値レベル(警告)より前にあるため、この定義が有効になります。

- LogWarning2Sys定義は、警告レベル出力をシステム・ログに送信します。
前の2つのログ・ハンドラ定義と同様に、この定義は現在のLOG_THRESHOLD_LEVELパラメータによってオーバーライドされません。

- 最後のログ・ハンドラ定義であるLogAll2Fileは、すべてのログ・レベルの出力をoblog.logというディスク・ファイルに送信します。
LOG_THRESHOLD_LEVELパラメータを警告に設定すると、「致命的」、「エラー」および「警告」レベルの出力のみがこのログ・データ・ファイルに記録されます。LogAll2Fileからの出力はFileLogWriterに送信されるため、ファイル名、バッファ・サイズ、ローテーション・サイズおよびローテーション間隔を制御するパラメータはすべて有効になります。

図23-1は、デフォルトのログ構成ファイルでのログレベルのアクティブ化を示します。

図23-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化

「図23-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化」の説明

異なるデータのタイプへの異なるしきい値レベルの構成

問題の診断では、コンポーネントが実行するすべての操作の詳細なログを必要としない場合があります。たとえば、アイデンティティ・サーバーがそのディレクトリに送信するリクエストの応答時間の遅れを診断する場合、LDAP操作の詳細ログを必要とし、それ以外タイプの操作は詳細でなくても構いません。

リリース10.1.4.2では、Oracle Access Managerで一部のコンポーネントの詳細なログを生成し、他のコンポーネントでは簡潔なログを生成するまたはログを生成しないように、モジュール固有または機能固有のしきい値レベルをログ構成ファイルで構成できます。

モジュール固有ロギングしきい値は、oblog_config_wg.xmlファイルのMODULE_CONFIGセクションで構成します。MODULE_CONFIGセクションは、このファイルの単純なリストのセクション内のLOG_THRESHOLD_LEVELで指定するグローバルのデフォルトをオーバーライドします。

この後の項では、次の項目について説明します。

- MODULE_CONFIGセクションについて

- 機能またはモジュールに対するログ・レベルしきい値の構成

MODULE_CONFIGセクションについて

「ログ構成ファイルの構造およびパラメータ」で説明されているように、ログ構成ファイルでグローバル・ロギングしきい値を構成します。次に、グローバル設定LOG_THRESHOLD_LEVELの例を示します。

<SimpleList>
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
. . .
</SimpleList>

グローバルしきい値に加えて、構成ファイルには、機能固有またはモジュール固有のログしきい値を定義するValNameListを含めることができます。常に、このリストの名前はMODULE_CONFIGです。ログ構成ファイルで許可されるのはこのリストの1つのインスタンスのみで、リストの情報はファイル内に定義されるすべてのログに適用されます。リリース10.1.4.2では、デフォルトのログ構成ファイルにはMODULE_CONFIGリストのコマンドのサンプルが含まれます。

MODULE_CONFIGリストの各項目は、次の例に示すように、モジュールのロギング・レベルを設定します。

<ValNameList xmlns="http://www.oblix.com" ListName="MODULE_CONFIG">
<NameValPair ParamName="LDAP" Value="LOGLEVEL_TRACE"></NameValPair>    <NameValPair ParamName="DB_RUNTIME" Value="LOGLEVEL_TRACE"></NameValPair></ValNameList>

このセクションの要素を次に示します。

- ValNameListタグは、モジュール固有ロギングしきい値を区切ります。

- 1つのNameValPairタグが、特定の各モジュール固有ロギングしきい値を区切ります。

- ParamNameパラメータは、モジュールまたは機能の名前を設定します。
使用可能な値のリストは、表23-8を参照してください。

- Valueパラメータは、ParanNameパラメータの値として指定したモジュールのロギングしきい値を設定します。
表23-1に、Valueパラメータで使用可能な値を示します。これらの値に加えて、値をONに設定するとモジュールのロギングを有効にし、値をOFFに設定すると特定のモジュールのロギングを無効にできます。

ログ構成ファイルのモジュール固有ロギング・セクションの場所

ログ構成ファイルの終了近く、ログ・ハンドラの複合リストの終了タグの後およびファイル内の最初の複合リストの終了タグの前に、モジュール固有しきい値セクションを追加します。

このセクションには、モジュール固有ロギング・セクションの例が含まれます。詳細は、「モジュール固有しきい値を構成する手順」を参照してください。

ログを記録できるモジュールのリスト

表23-8に、MODULE_CONFIGリスト内でParamNameパラメータに指定できる値のリストの一部を示します。

表23-8 モジュール固有ロギングしきい値に構成できるParamNameの値

ParamName値

このパラメータで設定するロギングしきい値

AAA_ACTIONS

OAMサーバーのポリシーの一部として構成された起動されるアクションのロギングしきい値を設定します。

<ValNameList xmlns="http://www.oblix.com"
ListName="MODULE_CONFIG">
<NameValPair Paramname="AAA_ACTIONS" Value="OFF">
</NameValPair>

AAA_AMENGINE

Access Managerエンジンで実行されたアクティビティのロギングしきい値を設定します。

AAA_ISRESRCOPPROT

リソース操作が保護されるかどうかの決定に関連するすべてのOAMサーバー・アクティビティのロギングしきい値を設定します。

ACCESS_CLIENT

アクセス・クライアントまたはWebgateで実行される操作のロギングしきい値を設定します。

ACCESS_GATE

アクセス・クライアントで実行される操作のロギングしきい値を設定します。

ACCESS_SDK

Access Manager SDKインタフェースで実行された操作のロギングしきい値を設定します。

詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。

ACCESS_SERVER

OAMサーバーで実行される操作のロギングしきい値を設定します。

AM_SDK

Access Manager SDKのロギングしきい値を設定します。

詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。

AUDIT

監査のロギングしきい値を設定します。

詳細は、第24章を参照してください。

AUTHENTICATION

ユーザー認証操作のロギングしきい値を設定します。

AUTHN_MGMT

認証スキーム管理のロギングしきい値を設定します。

AUTHN_PLUGIN

認証プラグインで実行された操作のロギングしきい値を設定します。

AUTHORIZATION

ユーザー認可操作のロギングしきい値を設定します。

AUTHZ_MGMT

認可スキーム管理のロギングしきい値を設定します。

AUTHZ_PLUGIN

認可プラグイン操作のロギングしきい値を設定します。

CACHE

キャッシュ管理およびキャッシュ上の操作のロギングしきい値を設定します。

CONN_MGMT

接続管理のロギングしきい値を設定します。

CONN_RUNTIME

接続ランタイムのロギングしきい値を設定します。

CONNECTIVITY

クライアントとサーバー間の接続性およびメッセージのロギングしきい値を設定します。

DB_CONFIGURATION

データ・ストア・インタフェース・レイヤー構成のロギングしきい値を設定します。

DB_RUNTIME

データ・ストア・インタフェース・レイヤーのランタイムのロギングしきい値を設定します。

DIAGNOSTIC_FRAMEWORK

診断フレームワークのロギングしきい値を設定します。

GROUPDB

ディレクトリ内のグループ・マネージャ・データのアクセスをロギングするしきい値を設定します。

GROUP_MGR

グループ・マネージャ操作をロギングするしきい値を設定します。

HTTP_REQ

HTTPリクエスト処理をロギングするしきい値を設定します。

IDXML

IDXML操作をロギングするしきい値を設定します。

詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。

LDAP

LDAP SDKのロギングしきい値を設定します。次に例を示します。

<ValNameList xmlns="http://www.oblix.com"
ListName="MODULE_CONFIG">
<NameValPair Paramname="LDAP" Value="LOGLEVEL_TRACE">
</NameValPair>

NET

ネットワークAPIのロギングしきい値を設定します。

OBMYGROUPS

ObMyGroups処理のロギングしきい値を設定します。これは、検索を開始した人物がメンバーであるグループの検索を表します。

OIS_CLIENT

Identityクライアントのロギングしきい値を設定します。

POLICY_MGMT

ポリシーおよびポリシー・ドメイン管理のロギングしきい値を設定します。

PPP

アイデンティティ・イベントAPIプラグイン操作のロギングしきい値を設定します。

詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。

QUERY_BUILDER

クエリー・ビルダー操作のロギングしきい値を設定します。

SECURITY

セキュリティおよび暗号化ライブラリのロギングしきい値を設定します。

SELECTOR

セレクタ操作のロギングしきい値を設定します。

SERVER

サーバー・インフラストラクチャのロギングしきい値を設定します。

SSOTOKEN

シングル・サインオン・トークン管理。

UTILS

ユーティリティ・クラスのロギングしきい値を設定します。

WEB

Webサーバー・プラグイン・インタフェースのロギングしきい値を設定します。

XML

XMLインフラストラクチャのロギングしきい値を設定します。

機能またはモジュールに対するログ・レベルしきい値の構成

次の手順では、機能固有またはモジュール固有のログ・レベルしきい値を構成する方法について説明します。

モジュール固有しきい値を構成する手順

1. 次の場所にあるログ構成ファイルを開きます。
Webgate_install_dir\identity|access\oblix\config

2. MODULE_CONFIGにListNameが指定されたValNameListセクションがこのファイル内に存在していない場合、次のようなセクションを作成します。

<ValNameList xmlns="http://www.oblix.com" ListName="MODULE_CONFIG">
</ValNameList>

ログ・ハンドラ定義を含むコンポーネント・リストの終了タグの後に、このリストを置きます。終了タグの直後にコメントがある場合、コメントの後にリストを置きます。

3. 新しいValNameList要素の開始タグと終了タグとの間に、1つ以上のNameValPair要素を構成します。
この要素は、ParamNameパラメータとValueパラメータで構成されます。ParamNameパラメータで指定できるモジュールについては、表23-8を参照してください。値は表23-1を参照するか、OnまたはOffの値を指定できます。次に、例を示します。

<NameValPair ParamName="LDAP" Value="LOGLEVEL_TRACE"></NameValPair>

ValNameList内に複数のValNamePair要素を指定できます。

完全なモジュール固有ロギングしきい値セクションは、次に示す例で太字で表示されています。

<!--  ============================================================   --><!--  Configure the Log Level                                        -->
. . .
<CompoundList xmlns="http://www.oblix.com" ListName="LOG_CONFIG">

<!-- Write all FATAL logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogFatal2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL">
</NameValPair>
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter">
</NameValPair>
<NameValPair ParamName="LOG_STATUS" Value="On">
</NameValPair>
</ValNameList>
. . .
</CompoundList>
<!--  List of values that can be specified in the module config      -->
<!--                                                                 -->
<!--  On - Uses loglevel set in the loglevel threshold               -->
<!--  Off - No information is logged                                 -->
<!--  LOGLEVEL_FATAL - serious error, possibly a program halt.       -->
<!--  LOGLEVEL_ERROR - a transient or self-correcting problem.       -->
<!--  LOGLEVEL_WARNING - a problem that does not cause an error.     -->
<!--  LOGLEVEL_INFO - reports the current state of the component.    -->
<!--  LOGLEVEL_DEBUG1 - basic debugging information.                 -->
<!--  LOGLEVEL_DEBUG2 - advanced debugging information.              -->
<!--  LOGLEVEL_DEBUG3 - logs performance-sensitive code.             -->
<!--  LOGLEVEL_TRACE - used when you need to trace the code path     -->
<!--  execution or capture metrics. Includes all previous levels.    -->
<!--                                                                 -->
<!--  List of modules that can be specified in the module config     -->
<!--                                                                 -->
<!--  ALL_MODULES - Applies to all log modules                       -->
<!--  Specific module name - Applies to specific module              -->
<!--                                                                 -->
<!--                                                                 -->
<!--    <ValNameList                                                 -->
<!--        xmlns="http://www.oblix.com"                             -->
<!--        ListName="MODULE_CONFIG">                                -->
<!--        <NameValPair                                             -->
<!--            ParamName="CONNECTIVITY"                             -->
<!--            Value="LOGLEVEL_TRACE"></NameValPair>                -->
<!--    </ValNameList>                                               -->

<ValNameList xmlns="http://www.oblix.com" ListName="MODULE_CONFIG">
<NameValPair ParamName="LDAP" Value="LOGLEVEL_TRACE"></NameValPair>
<NameValPair ParamName="DB_RUNTIME" Value="LOGLEVEL_TRACE">
</NameValPair>
</ValNameList>

</CompoundList>

機密属性のフィルタ処理

前述のように、セキュア・ロギングをアクティブ化してデフォルトのフィルタ・リストを拡張すると、ログ・ファイルの機密情報をマスキングできます。

フィルタ・リストに別の属性を追加する場合は、表示名および属性名をディレクトリ・サーバーに含める必要があります。次の手順では、このタスクの実行方法を説明します。この例では、ユーザーの自宅電話番号(表示名はHome Phone、属性名はhomePhone)をフィルタ処理します。実際には、任意の属性をフィルタ処理できます。

注意:
FILTER_LISTに値を追加するごとに、セキュア・ロギングの使用にかかるランタイム・コストが増加します。

ランタイム・コストを抑えるために、FILTER_LISTの使用を最適化することをお薦めします。たとえば、ParamNameの2つのバリエーション(User PasswordとuserPassword)を追加するかわりに、1つのみを使用できます。ParamNameとしてPasswordを使用すると、User Password、userPassword、およびPasswordで終わるその他の単語がマスキングされます。また、FILTER_LISTにHome PhoneとhomePhoneの両方を含めるかわりに、Phoneのみを使用できます。

関連項目:

- 「ロギング、ログ・レベルおよびログ出力について」

- 「単純なリストおよびロギングしきい値」

- 「フィルタ・リスト」

- 「デフォルトのログ構成ファイルの設定」

フィルタ・リストに機密属性を追加する手順

1. ログ構成ファイルをテキスト・エディタで開きます。
Webgate_install_dir\identity|access\oblix\config\oblog_config_wg.xml

2. oblog_config_wg.xmlで、次の操作を行います。

1. セキュア・ロギングがアクティブであることを確認します。次に例を示します。

<SimpleList>
<NameValPair
ParamName="SECURE_LOGGING"
Value="On"></NameValPair>
</SimpleList>

2. ファイルの最後にあるFILTER_LISTを探します。次に例を示します。

<ValNameList xmlns="http://www.oblix.com" ListName="FILTER_LIST">
<NameValPair ParamName="password" Value="40" />
<NameValPair ParamName="Password" Value="40" />
<NameValPair ParamName="response" Value="40" />
<NameValPair ParamName="Response" Value="40" />
</ValNameList>

3. マスキングする表示名とマスキングの長さの値を追加し、属性とマスキングの長さの値を追加します。次に例を示します。

<NameValPair ParamName="Home Phone" Value="300" />
<NameValPair ParamName="homePhone" Value="300" />

注意:
テスト用に、LOG_THRESHOLD_LEVELおよびLOG_SECURITY_THRESHOLD_LEVELをTRACEに設定します。ステップ6aを参照してください。

4. LOG_THRESHOLD_LEVELとLOG_SECURITY_THRESHOLD_LEVELが同じレベルである、または互いに一貫性があることを確認します(表23-4を参照してください)。次に例を示します。

<SimpleList>
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
</SimpleList>
...
<SimpleList>
<NameValPair ParamName="LOG_SECURITY_THRESHOLD_LEVEL" Value="LOGLEVEL_
WARNING" />
</SimpleList>

5. oblog_config_wg.xmlファイルを保存します。

3. ユーザー・パスワードのフィルタ処理: 次の手順を実行し、「フィルタ・リスト」を参照します。
oblog_config_wg.xmlのフィルタ・リストに表示名User Passwordおよび対応する属性を追加し、それぞれのマスキングの長さを設定します。次に例を示します。

<ValNameList xmlns="http://www.oblix.com" ListName="FILTER_LIST">
...
<NameValPair ParamName="User Password" Value="40" />
<NameValPair ParamName="userPassword" Value="40" />
</ValNameList>

4. 次の手順で、セキュア・ロギングおよび機密情報のフィルタ処理をテストします。

1. oblog_config_wg.xmlファイルで、LOG_THRESHOLD_LEVELおよびLOG_SECURITY_THRESHOLD_LEVELをTRACEに設定します。

<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_TRACE" />
...
<NameValPair ParamName="LOG_SECURITY_THRESHOLD_LEVEL" Value="LOGLEVEL_
TRACE" />

2. セキュア・ロギングを構成したコンポーネントに関係するタスクを実行します。次に例を示します。
リソースへのアクセス

ユーザーのプロファイルで属性の値を表示または変更します。フィルタ処理する属性がhomePhoneの場合はHome Phoneです。

3. 次のoblogをチェックし、フィルタ処理した属性値が***********のように文字列でマスキングされていることを確認します。
Webgate_install_dir/access/oblix/log/oblog.log

4. oblog_config_wg.xmlファイルでLOG_THRESHOLD_LEVELおよびLOG_SECURITY_THRESHOLD_LEVELを企業の目的に合ったレベルにリセットします。

5. 必要に応じて、oblog_config_wg.xmlファイルでフィルタ処理する属性のマスキングの長さを調整します。次に例を示します。

<NameValPair ParamName="Home Phone" Value="340" />
<NameValPair ParamName="homePhone" Value="340"/>

5. デプロイ内の、1つ以上のマスキング対象属性を含むコンポーネントごとに、手順1から6を繰り返します。

24 管理イベントおよびランタイム・イベントの監査

Oracle Access Manager、Oracle Security Token ServiceおよびOracle Fusion Middlewareの監査機能は、説明責任を果たすための手段と、「誰がいつ何をしたか」というタイプの質問への回答を提供します。監査データは、ダッシュボードの作成、履歴データの集計、およびリスクの評価に使用できます。記録された監査データを分析すれば、コンプライアンス担当者がコンプライアンス方針を定期的に確認できます。

この章では、Oracle Access ManagerおよびOracle Security Token Serviceの監査可能な管理イベントとランタイム・イベントについて説明します。共通監査設定の構成および設定した監査構成の検証がこの章の主題です。監査データの分析と監査についてはこの章では取り上げません。

注意:
特に明記しないかぎり、この章の情報は、Oracle Access Managerを単体で使用している場合もOracle Security Token Serviceとともに使用している場合も同じです。

この章の内容は次のとおりです。

- 前提条件

- 監査の概要

- 監査可能なOracle Access Managerイベント

- Oracle Access Manager with Oracle Security Token Serviceの監査の設定

- Oracle Access Managerの監査とレポートの検証

前提条件

この項ではこの章に示すタスクの要件を明らかにします。「監査の概要」を確認してください。

監査の概要

現在では多くのビジネスにおいて、アイデンティティ情報や、アプリケーションおよびデバイスへのユーザー・アクセスを監査できることが求められます。コンプライアンス監査は、企業が法的要件を満たしていることを確認する助けとなります—例としては、Sarbanes-Oxley ActやHealth Insurance Portability and Accountability Act(HIPAA)の2つが挙げられます。

Oracle Access ManagerおよびOracle Security Token Serviceは、Oracle Fusion Middlewareの共通監査フレームワークを使用し、大量のユーザー認証イベントと認可イベント、および管理イベント(システムへの変更)の監査を支援します。Oracle Fusion Middlewareの共通監査フレームワークを使用すれば、ロギングと例外を一様な形で取り扱い、すべての監査イベントの診断を行うことができます。

監査機能は有効または無効のどちらに設定しておくことも可能ですが、本番環境では有効にしておくのが普通です。監査による性能への影響は最小限に抑えられており、監査によって得られた情報は有用です(業務に不可欠な場合もあります)。

注意:
Oracle Access Manager 10gの監査はOAMポリシーに基づいていました。しかしOracle Access ManagerおよびOracle Security Token Serviceでの監査は、ユーザーまたはユーザー・グループのデータ取得を可能にするOracle Access Managerコンソールで設定した構成パラメータに基づいています。

監査データは、集中管理された1つのOracle Databaseインスタンスや、フラットファイルに書き込むことができます。監査記録の保存場所にかかわらず、記録には、特定の要件に合わせて構成することのできる一連の項目が含まれています。監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。

Oracle Access Managerは、あらかじめ設定されたコンプライアンス・レポートを提供するOracle Business Intelligence Publisherと統合化できます。

この項では、Oracle Access Managerによる監査について次の項目ごとにその概要を示します。

- Oracle Access Managerの監査構成について

- Oracle Access Manager監査記録ストレージについて

- 監査レポートおよびOracle Business Intelligence Publisherについて

- 監査ログについて

関連項目:

- 「Oracle Security Token Serviceの監査の概要」

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middlewareの監査フレームワークの概要」

Oracle Access Managerの監査構成について

管理者は、Oracle Access Managerコンソールを使用して一定の監査パラメータを制御します。この監査構成は、ファイルoam-config.xmlに記録されます。その他の監査構成は、共通管理フレームワークを通じて設定する必要があります。

注意:
監査構成はoam-config.xmlの一部です。Fusion Middleware Controlを使用してOAM管理ポリシーを構成することはできません。Oracle Access Managerは、監査構成でJPSインフラストラクチャを使用しません。Oracle Access Manager監査用のWebLogic Scripting Tool (WLST)コマンドはありません。

Oracle Access Managerコンソール内では、ログ・ファイルとログ・ディレクトリの最大サイズを設定できます。監査ポリシー(Oracle Access Managerではフィルタ・プリセットと呼ばれます)は、特定のコンポーネントについて監査フレームワークによって取得されるイベントのタイプを宣言します。

関連項目:

- 「監査可能なOracle Access Managerイベント」

- 「監査可能なOracle Security Token Service管理イベント」

- 「監査可能なOracle Security Token Serviceランタイム・イベント」

Oracle Access Manager監査記録ストレージについて

デフォルトでは、Oracle Access Managerは監査データをファイルに記録します。しかし、管理者は、監査データをデータベースに記録するように構成を変更できます。書式は異なりますが、監査データの内容はフラット・ファイルの場合もデータベースの場合も同じです。

データベース・ロギングは、Oracle Fusion Middlewareの全製品について共通監査フレームワークを実行します。その利点は、プラットフォーム・レベルで監査機能が共通化されることです。

注意:
本番環境において望ましいモードは、監査データ専用のスタンドアロンRDBMSデータベースに監査記録を書き込むことです。

本番環境においては、共通監査フレームワークのスケーラビリティと高可用性を実現するために、データベース監査ストアを使用することをお薦めします。監査データは累積的なもので、その量は時間とともに増大します。これは監査データ専用のデータベースとして、他のアプリケーションは使用しないようにするのが理想です。

監査記録用の恒久的ストアとしてのデータベースに切り替えるには、まず、リポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・スキーマを作成する必要があります。RCUは、データベースに監査記録を格納するために必要なスキーマを使用して、そのデータベース・ストアをシードします。スキーマ作成後にデータベースの構成を設定するには次の操作が必要です。

- 作成した監査スキーマを参照するデータ・ソースの作成

- そのデータ・ソースを参照する監査ストアの設定

図24-1は、サポート対象データベースを使用した監査アーキテクチャの簡略図です。Oracle Fusion Middleware監査フレームワークの監査ログ表用スキーマはリポジトリ作成ユーティリティ(RCU)によって提供されます。このユーティリティは、データベースに情報をログする前に起動している必要があります。

図24-1 データベースによる監査アーキテクチャ

「図24-1 データベースによる監査アーキテクチャ」の説明

関連項目:

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 監査データベース・ストアの設定

独立した監査ローダー・プロセスがフラット・ログ・ファイルを読み込んで、Oracleデータベースのログ表にレコードを挿入します。管理者は、監査ストアを使用することにより、Oracle Business Intelligence Publisherの様々な既製レポートを使用して監査データを表示できます。

監査レポートおよびOracle Business Intelligence Publisherについて

データベース監査ストア内のデータは、Oracle Business Intelligence Publisherであらかじめ定義されたレポートを通じて表示されます。これらのレポートを使用すれば、ユーザー名、時間範囲、アプリケーション・タイプ、実行コンテキスト識別子(ECID)などの様々な基準に基づいて、監査データをドリルダウンできます。

Oracle Access Managerには、そのまますぐに使用できるサンプル監査レポートがいくつか用意されており、これらのレポートにはOracle Business Intelligence Publisherでアクセスできます。また、Oracle Business Intelligence Publisherを使用してユーザー固有のカスタム監査レポートを作成することもできます。

Oracle BI Enterprise Edition(Oracle BI EE)は、スケーラブルで効率的な問合せおよび分析用サーバ、非定型問合せおよび分析ツール、インタラクティブ・ダッシュボード、プロアクティブ・インテリジェンスやアラート、リアルタイム予測インテリジェンス、企業用レポート・エンジンなどを含む企業用ビジネス・インテリジェンス・ツールとインフラストラクチャの包括的なセットです。

Oracle Business Intelligence Enterprise Editionのコンポーネントは、共通のサービス指向アーキテクチャ、データ・アクセス・サービス、分析および計算インフラストラクチャ、メタデータ管理サービス、セマンティック・ビジネス・モデル、セキュリティ・モデルとユーザー・プリファレンス、および管理ツールを共有しています。Oracle Business Intelligence Enterprise Editionは、データソースに合わせて最適化された分析生成、最適化されたデータ・アクセス、高度な計算、インテリジェント・キャッシング・サービス、およびクラスタリングなどによるスケーラビリティとパフォーマンスを備えています。

関連項目:
『Oracle Fusion Middlewareセキュリティ・ガイド』の「監査分析とレポートの使用」

Oracel Access Managerの監査レポートとともに使用するOracle BI EEの準備方法の概要については、「Oracle Business Intelligence Publisher EEの準備」を参照してください。

監査ログについて

監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。監査ログ・ファイルには、Date、Time、Initiator、EventType、EventStatus、MessageText、ECID、RID ContextFields、SessionId、TargetComponentType、ApplicationName、EventCategoryなどを含むいくつかのフィールドが記録されます。

関連項目:
『Oracle Fusion Middlewareセキュリティ・ガイド』の監査の構成と管理に関する章に含まれる監査ログ関連項目

監査可能なOracle Access Managerイベント

この項の内容は次のとおりです。

- 監査可能なOracle Access Manager管理イベント

- 監査可能なOAMランタイム・イベント

- 認証イベントの監査について

関連項目:

- 「Oracle Security Token Service管理イベントとランタイム・イベントの監査」

監査可能なOracle Access Manager管理イベント

管理イベントとは、Oracle Access Managerコンソール使用時に作成されるイベントです。

監査可能なOracle Access Manager固有の管理イベントと、これらのイベントが取得する内容の詳細を表24-1に示します。このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。

注意:
Oracle Access Manager 11gの管理者は、「OAMサーバー共通プロパティ」ページの「監査構成」タブでフィルタ・プリセットを選択することによって、記録される情報の量とタイプを制御します。
各フィルタ・プリセットの監査可能イベントは、読取専用のcomponent_events.xmlファイル内に指定されています。Oracle Access Manager 11gでは、このファイルの編集やカスタマイズはサポートされていません。

表24-1 Oracle Access Manager管理監査イベント

管理イベント

含まれるイベント・データ

Oracle Access Managerコンソールのログインの成功/失敗

- ユーザー名

- リモートIP

- ロール

認証ポリシーの作成

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

認証ポリシーの変更

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

- 古いポリシー名

- 古い認証スキームの詳細

- 古いリソースの詳細

認証ポリシーの削除

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

リソースの作成

- リソース名

- URI

- 操作

- リソース・タイプ

リソースの変更

- リソース名

- URI

- 操作

- リソース・タイプ

- 古いリソース名

- 古いURI

- 古い操作

リソースの削除

- リソース名

- URI

- 操作

- リソース・タイプ

認証スキームの作成

- スキーム名

- 認証モジュール

- レベル

認証スキームの変更

- スキーム名

- 認証モジュール

- レベル

- 古いスキーム名

- 古い認証モジュール

- 古いレベル

認証スキームの削除

- スキーム名

- 認証モジュール

- レベル

レスポンスの作成

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

レスポンスの変更

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

- 古いレスポンス名

- 古いレスポンス・キー

- 古いデータ・ソース

レスポンスの削除

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

パートナの追加

- パートナ名

- パートナID

- パートナURL

- ログアウトURL

パートナの変更

- パートナ名

- パートナID

- パートナURL

- ログアウトURL

- 古いパートナ名

- 古いパートナURL

- 古いログアウトURL

パートナの削除

- パートナ名

- パートナID

- パートナURL

- ログアウトURL

制約の作成

- 制約名

- 制約タイプ

- 制約データ

制約の変更

- 制約名

- 制約タイプ

- 制約データ

- 古い制約名

- 古い制約タイプ

- 古い制約データ

制約の削除

- 制約名

- 制約タイプ

- 制約データ

サーバー・ドメインの作成

- ドメイン名

サーバー・ドメインの変更

- ドメイン名

- 古いドメイン名

サーバー・ドメインの削除

- ドメイン名

サーバーの構成変更

- 新しい詳細

- 古い詳細

- インスタンス名

- ホスト名

- アプリケーション名

- ユーザー名

- リモートID

- ロール

- 日付と時刻

監査可能なOAMランタイム・イベント

ランタイム・イベントは、Oracle Access Managerのコンポーネント・エンジンが互いに連携動作する時に生成される一部のイベントによって作成されるイベントです。

生成時に監査可能なランタイム・イベントと、それらのイベントが取得する内容の詳細を表24-2に示します。このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。

注意:
OAM 11gの管理者は、「OAMサーバー共通プロパティ」ページの「監査構成」タブでフィルタ・プリセットを選択することによって、記録される情報の量とタイプを制御します。
各フィルタ・プリセットの監査可能イベントは、読取専用のcomponent_events.xmlファイル内に指定されています。OAM 11gでは、このファイルをカスタマイズしたり編集したりすることはできません。

表24-2 OAMランタイム監査イベント

ランタイム・イベント

発生時期

含まれるイベント詳細

認証の試行

ユーザーが保護されたリソースにアクセスしようとして、SSDサーバーにリクエストが到着した時。このイベントの後には、資格証明の送信と認証の成功または失敗の各イベントが発生します。

- リモートIP

- リソースID

- パートナID

- リソースID

- 認証スキームID

- 認証ポリシーID

認証の成功

クライアントが資格証明を送信して資格証明の検証に成功した時。

- リモートIP

- ユーザー名

- ユーザーDN

- リソースID

- 認証スキームID

- 認証ポリシーID

- パートナID

認証の失敗

クライアントが資格証明を送信して資格証明の検証に失敗した時。

- リモートIP

- ユーザー名

- ユーザーDN

- リソースID

- 認証スキームID

- 失敗エラー・コード

- 再試行回数

- 認証ポリシーID

- パートナID

セッションの作成

認証成功時。

- SSOセッションID

- ユーザー名

- ユーザーDN

- リモートIP

- リソースID

- 認証スキームID

- 認証ポリシーID

セッションを破棄

認証成功時。

- SSOセッションID

- ユーザー名

- ユーザーDN

- パートナID

ログインの成功

クライアントがログイン手順を完了して、それがエージェントに転送された時。

- リモートIP

- ユーザー名

- ユーザーDN

- 認証レベル

- リソースID

- 認証スキームID

- 認証ポリシーID

- パートナID

ログインの失敗

クライアントがログインに失敗した時。このイベントは、認められている認証の再試行にすべて失敗した場合、またはアカウントがロックされた場合のみ発生します。

- リモートIP

- ユーザー名

- 認証レベル

- リソースID

- 認証スキームID

- 認証ポリシーID

- パートナID

ログアウトの成功

クライアントがログアウト手順を完了して、それがエージェントに転送された時。

- リモートIP

- ユーザーDN

- 認証レベル

- SSOセッションID

- パートナID

ログアウトの失敗

クライアントがログアウトに失敗した時。

- リモートIP

- ユーザーDN

- SSOセッションID

- 失敗の詳細

- パートナID

資格証明コレクション

クライアントが資格証明コレクション・ページにリダイレクトされた時。

- リモートIP

- リソース名

- リソースID

- 認証スキームID

- 認証ポリシーID

資格証明の送信

クライアントが資格証明を送信した時。

- リモートIP

- ユーザー名

- リソースID

- 認証スキームID

- 認証ポリシーID

認可の成功

クライアントがリソースへのアクセスを認可された時。

- リモートIP

- ユーザーDN

- リソースID

- 認可ポリシーID

認可の失敗

クライアントがリソースへのアクセスを認可されなかった時。

- リモートIP

- ユーザーDN

- リソースID

- 認可ポリシーID

サーバーの起動

サーバーが起動した時。

- 日付と時刻

- インスタンス名

- ホスト名

- アプリケーション名

- ユーザー名

サーバーの停止

サーバーが停止した時。

- 日付と時刻

- インスタンス名

- ホスト名

- アプリケーション名

- ユーザー名

認証イベントの監査について

認証中にイベントを監査することは、管理者がシステム内のセキュリティ上の弱点を精査する助けとなります。認証を要求しているユーザーやブルート・フォース攻撃に関する情報を、ファイル・システムやバックエンド・データベースに保存できます。

認証時の監査のために管理者が構成できるイベントには次のようなものがあります。

- 認証の成功

- 認証の失敗

- 認証ポリシー・データの作成、変更、削除、または表示

認証されるユーザーに関する情報には次のものが含まれます。

- IPアドレス

- ブラウザ・タイプ

- ユーザー・ログインID

- アクセスの時間

注意:
ユーザー・パスワードなどの取り扱いに注意を要するユーザー属性の監査、ログイング、またはトレースは避けることをお薦めします。

Oracle Access Manager with Oracle Security Token Serviceの監査の設定

次の概要には、監査を実行できるようにするために事前に実行しておく必要があるタスクのリストを示します。

関連項目:
「Oracle Security Token Service管理イベントとランタイム・イベントの監査」

タスクの概要: Oracle Access Managerの監査設定には次のタスクが含まれます。

1. 「監査データベース・ストアの設定」に示す監査データ・ストアの設定。

2. 「Oracle Business Intelligence Publisher EEの準備」に示す監査レポート発行の設定。

3. 次で説明されているように、Oracle Access Managerコンソールで監査構成を編集します。

- Oracle Access Managerコンソールでの監査構成セクションについて

- Oracle Access Managerの共通監査設定の追加、表示、または編集

4. 監査が記述されたとおりに機能していることを確認します。「Oracle Access Managerの監査とレポートの検証」を参照してください。

監査データベース・ストアの設定

この項では、監査データベースを作成し、リポジトリ作成ユーティリテ(RCU)を使用してそのスキーマを拡張するために必要なタスクの概要を示します。監査データをデータベースに保存するよう選択した場合、Oracle Access Managerのイベントを監査できるようにするにはこのタスクが必要になります。

関連項目:

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査ストアの管理に関する詳細

- 『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』

タスクの概要: データベース監査ストアの作成

1. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の説明に従い、監査データベース(バージョン11.1.0.7以降)を作成します。

2. 『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のRCUを使用した監査スキーマの作成に関する項に従い、データベースに対してOracleリポジトリ作成ユーティリテ(RCU)を実行します。

3. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査データ・ソースの設定に関する項に従い、監査ローダーの監査データ・ソースを設定し、それをOAMサーバー用に構成します。

- WebLogic Server用のJava EE監査ローダー構成を使用

- 前述のステップ2で設定したデータベースを参照するデータソースjdbc/AuditDBのJNDI名を使用

4. ドメイン・ファイル(DOMAIN_HOME/config/fmwconfig/jps-config.xml)に指定されたサービス・インスタンス内で、プロパティaudit.loader.repositoryTypeの値をDBに変更することによって、データベース監査を有効にします。次に例を示します。

<serviceInstance name="audit" provider="audit.provider">
<property name="audit.filterPreset" value="None"/>
<property name="audit.maxDirSize" value ="0"/>
<property name="audit.maxFileSize" value ="104857600"/>
<property name="audit.loader.jndi" value="jdbc/AuditDB"/>
<property name="audit.loader.interval" value="15" />
<property name="audit.loader.repositoryType" value="DB" />
</serviceInstance>

5. WebLogic Serverを再起動します。

6. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のJavaコンポーネント用のデータベース監査ストアの構成に関する項に従い、監査ローダーがOAMサーバー用に構成されていることと、そのローダーが適切なデータベースを参照していることを確認します。

7. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のバスストップ・ファイルのチューニングに関する項に従い、バスストップ・ファイルのメンテナンスを行います。

Oracle Business Intelligence Publisher EEの準備

Oracle Business Intelligence Publisher Enterprise Edition(EE)をOracle Access Managerの監査レポートとともに使用するには、次の手順に従って準備する必要があります。

関連項目:

- 『Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition』

- 『Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition』

- 『Oracle Fusion Middlewareユーザーズ・ガイド for Oracle Business Intelligence Enterprise Edition』

タスクの概要: Oracle BI Publisherの準備

1. 『Oracle Business Intelligence Enterprise Edition Installation and Upgrade Guide』に従ってOracle BI Publisherをインストールします。

2. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Business Intelligence PublisherでのOracle Reportsの設定に関する項に従い、タスクを実行します。

- AuditReportTemplate.jarをReportsフォルダ内に解凍します。

- 監査データ・ソースののJNDI接続、または監査データベースのJDBC接続を設定します。

3. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査レポート・テンプレートの設定に関する項の説明に従い、監査レポート・テンプレートを設定します。

4. 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査レポート・フィルタの設定に関する項の説明に従い、監査レポート・フィルタを設定します。

5. 次のパスからレポートを表示します: Reports/Oracle_Fusion_Middleware_Audit reports

Oracle Access Managerコンソールでの監査構成セクションについて

Oracle Access Manager内では、特定の「監査構成」設定には「システム構成」の「共通設定」でアクセスできます。データベースに対して監査を行うときは、これらの設定は必要ありません。図24-2は、「共通設定」ページの「監査構成」セクションを示しています。

図24-2 共通設定: 監査構成

「図24-2 共通設定: 監査構成」の説明

「監査中」セクションには、「ログ・ディレクトリ」、「フィルタ設定」、および「監査構成」の「ユーザー」に対する設定が表示されます。

注意:
実際のログ・ディレクトリは、Oracle Access Managerコンソールを使用して構成できません。これは、共通監査フレームワークの監査ローダーのデフォルト・ディレクトリです。このディレクトリの変更は監査ローダーに影響が及ぶため、サポートされません。

「監査構成」ページの要素を表24-3に示します。

表24-3 監査構成要素

要素

説明

最大ディレクトリ・サイズ

監査出力ファイルが格納されるディレクトリの最大サイズ(MB)。たとえば最大ファイル・サイズが10であるとすると、このパラメータの値を100にした場合はそのディレクトリに最大10個のファイルを格納できることになります。最大ディレクトリ・サイズに達すると、監査ロギングは停止します。

たとえば値を100とすると、ファイル・サイズが10MBの場合は最大10ファイルと指定したことになります。サイズがこの値を超えると、監査ログ・ファイルの作成は停止します。

これは、構成ファイルjps-config.xmlに記述されたmax.DirSizeプロパティを使用して構成されます。このプロパティは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明されているとおり、Javaコンポーネントのバスストップ・ディレクトリの最大サイズを制御します。

最大ファイル・サイズ

監査ログ・ファイルの最大サイズ(MB)。ファイルのサイズが最大サイズに達すると、新しいログ・ファイルが作成されます。たとえば値を10に指定すると、ファイル・サイズが10MBに達した時点でファイル・ローテーションが指示されます。

これは、構成ファイルjps-config.xmlに記述されたmax.fileSizeプロパティを使用して構成されます。このプロパティは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明されているとおり、Javaコンポーネントのバスストップ・ファイルの最大サイズを制御します。

フィルタ有効

イベント・フィルタリングを有効にするにはこのボックスを選択します。

フィルタ・プリセット

フィルタを有効にした時にログに記録される情報の量とタイプを定義します。デフォルト値は「低」です。

- 「すべて」: 監査可能なすべてのOAMイベントを取得して記録します。

- 「低」: 監査可能なOAMイベントの特定セットを取得して記録します。

- 「中」: 「低」設定の対象となるイベントと他のいくつかの監査可能OAMイベントを取得して記録します。

- 「なし」: OAMイベントの取得と記録を行いません。

各フィルタ・プリセットのイベントは、読取専用のcomponent_events.xmlファイル内に指定されています。OAM 11gでは、このファイルをカスタマイズしたり編集したりすることはできません。指定されたフィルタ・プリセットに監査対象として構成された項目のみが監査可能です。

ユーザー

フィルタが有効になった時のみアクションが含められるユーザーのリストを指定します。特別なユーザーのアクションは、フィルタ・プリセットにかかわらずすべて監査されます。管理者は、この表の特別なユーザーを追加、削除、または編集できます。

Oracle Access Managerの共通監査設定の追加、表示、または編集

次の手順では、OAMサーバー共通監査構成の設定を追加、表示または編集する方法を示します。

Oracle Access Managerコンソールでの監査構成の表示または編集方法

1. 「システム構成」タブから、「共通構成」セクションを展開し、ナビゲーション・ツリーの「共通設定」をダブルクリックします。

2. 「監査構成」セクションで、使用環境の詳細を正しく入力します(表24-3)。

- 最大ログ・ディレクトリ・サイズ

- 最大ログ・ファイル・サイズ

- 監査から特定のユーザーを含めるためのフィルタ設定。「ユーザー」表の上の「追加」(+)ボタンをクリックしてフィールドに値を入力します。

3. 「適用」をクリックして「監査構成」を送信します(または変更を適用しないでページを閉じます)。

4. AdminServerおよびOAMサーバーを、変更が適用された後で再起動します。

Oracle Access Managerの監査とレポートの検証

次の手順を使用して、ランタイム・イベントの監査構成をテストできます。

前提条件

- この章の説明に従ってサーバーの共通監査パラメータを設定します。

- エージェントとサーバーが稼動していることを確認します。

- 第13章、「リソースを保護してSSOを有効化するポリシーの管理」に従い、リソースを保護するためにアプリケーション・ドメインを構成します。

- 「Oracle Business Intelligence Publisher EEの準備」の説明に従い、BI EE Publisherを準備します。

OAM 11g監査構成の検証

1. ブラウザで、保護されたリソースへのURLを入力し、無効な資格証明を使用してサインインします。

2. 正しい資格証明を使用して再度サインインします。

3. Oracle BI EEにサインインします。次に例を示します。
http://host:port/xmlpserver

ここで、hostはコンピュータをホストするOracle BI Publisher、portはBI Publisherのリスニング・ポート、xmlpserverはBI Publisherのログイン・ページです。

4. Oracle BI Publisher Enterpriseで、希望するOracle Access Managerレポートを探します。次に例を示します。
下に示すように、「共有フォルダ」→「Oracle_Fusion_Middleware_Audit」→「Component_Specific」→「Oracle Access Manager」をクリックして希望のレポートを選択します。

5. 目的の分析を実行するか、必要に応じて監査構成を編集します。

/Middleware_home/user_projects/domains/base_domain/servers/oam_server1/logs/
auditlogs/OAM/

6. 自社のポリシーに従って監査ログのアーカイブと管理を行います。

25 Oracle Access Managerコンソールを使用したパフォーマンスの監視

パフォーマンス・メトリックを表示するための方法がいくつかあります。この章では、Oracle Access Managerコンソールの使用に重点を置いて、次のトピックを扱います。

- パフォーマンス・モニタリングの概要

- コンソールを使用したサーバー・パフォーマンス・メトリックの監視

- SSOエージェント・パフォーマンス・メトリックの監視

- OXMプロキシ・パフォーマンス・チューニング・パラメータ

関連項目:

- 第26章: Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Access Managerパフォーマンス・メトリックの監視

パフォーマンス・モニタリングの概要

Oracle Access Managerは、Oracle Dynamic Monitoring Systems (DMS)を使用し、OAMサーバーおよび登録されたOAMエージェントについてアプリケーション固有のパフォーマンス情報を測定します。

メトリック収集は、コンポーネントが特定のイベントについてメモリに情報を収集するためのメカニズムです。これらのイベントに基づいて、特定の領域内で経過した時間をモニターしたり、特定の発生事象や状態変化を追跡できます。これらのメトリックはメモリ内にのみ保存されますが、たとえばEM、dmsSpy、dmsDumpなど、これらを取り出して表示するためのメカニズムもいくつかあります。

dmsSpyは、WebLogicアプリケーション・サーバーの一部であるFusion Middlewareツールです。dmsSpyは、WebLogicアプリケーション・サーバー・インスタンスに固有なDMSロー・データを表示します。表示される情報は名詞タイプによって分類され(Oracle Access Manager 11gではOAMS.OAM_ prefix)、Weblogicアプリケーション・サーバー・インスタンスで実行中のすべてのDMSインストゥルメント・アプリケーションに関するメトリックが含まれます。Weblogicインスタンスのメトリックを参照するには、http://hostname:port/dms/にアクセスしてください。次に例を示します。

http://adc1234:7001/dms/

関連項目:

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のDMSによるアプリケーションのインストゥルメントの詳細

管理者は、「システム構成」タブで「アクション」メニューの「モニタリング」コマンドを使用して、Oracle Access Manager 11gのパフォーマンスを監視できます。

コンソールを使用したサーバー・パフォーマンス・メトリックの監視

ここでは、次の内容について説明します。

- サーバー・インスタンス・パフォーマンスの監視

- サーバー・メトリックの確認

サーバー・インスタンス・パフォーマンスの監視

有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して、Oracle Access Managerコンソールを使用した様々なパフォーマンス・メトリックを表示できます。

前提条件

サーバーが稼動している必要があります。

Oracle Access Managerコンソールを使用してパフォーマンスを監視する方法

1. 「システム構成」タブに移動します。

2. サーバー・インスタンス:

1. 「共通構成」セクションから、監視するサーバー・インスタンスの名前を見つけて選択します。

2. 「アクション」メニューから「モニター」メニューをクリックします。

3. 目的のサブタブをクリックして、選択したサーバー・インスタンスの結果を表示します。
サーバー・プロセス概要
セッション操作
サーバー操作
OAMエージェント

4. 「サーバー・メトリックの確認」に進みます。

3. OSSOエージェント: 表示されたインスタンス・ページ上に結果が表示されます。

- プロセスの概要

- 操作の詳細

サーバー・メトリックの確認

このトピックでは、ナビゲーション・ツリーでサーバー・インスタンスが選択されており、「システム構成」タブで「アクション」メニューの「モニタリング」メニュー・コマンドを選択すると表示されるサーバー・メトリックについて説明します。

図25-1は、サーバー・プロセスページを示します。

図25-1 「サーバー・プロセス概要」ページ

「図25-1 「サーバー・プロセス概要」ページ」の説明

「サーバー・プロセス概要」では、次のOAMサーバー・パフォーマンス・メトリックを提供します。

- 認可プロセス

- 認可リクエスト

- 認可プロセス失敗

- 認可プロセス成功

- 認証前プロセス失敗

- 認証前プロセス成功

図25-2は、「セッション操作」の「モニター」ページを示します。

図25-2 「セッション操作」の「モニター」ページ

「図25-2 「セッション操作」の「モニター」ページ」の説明

「セッション操作」のパフォーマンス・メトリックには、次のものが含まれます。

- セッション検証チェック

- セッション作成

- セッション破棄

- クライアント・セッション削除

図25-3は、「サーバー操作」の「モニター」ページを示します。

図25-3 「サーバー操作」の「モニター」ページ

「図25-3 「サーバー操作」の「モニター」ページ」の説明

「サーバー操作」のパフォーマンス・メトリックには、次のものが含まれます。

- 認証ポリシー・レスポンス成功

- 認証スキーム・レスポンス成功

- 認証ポリシー・レスポンス

- 認可

- リソース保護対象の統計

図25-4は、エージェントの「モニター」ページを示します。

図25-4 「OAMエージェント」の「モニター」ページ

「図25-4 「OAMエージェント」の「モニター」ページ」の説明

「OAMエージェント」のパフォーマンス・メトリックには、次のものが含まれます。

- 名前

- ステータス

- バージョン

SSOエージェント・パフォーマンス・メトリックの監視

この項では、様々なコンポーネントのメトリックの確認方法と、チューニングが必要かどうかの判断方法を説明します。内容は次のとおりです。

- SSOエージェント・パフォーマンス・メトリックの監視

- OAMエージェント・メトリックの確認

- OSSOエージェント・メトリックの確認

SSOエージェント・パフォーマンス・メトリックの監視

有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して、Oracle Access Managerコンソールを使用した様々なSSOエージェント・パフォーマンス・メトリックを表示できます。

前提条件

サーバーおよびエージェントが稼動している必要があります。

Oracle Access Managerコンソールを使用してSSOエージェント・パフォーマンスを監視する方法

1. 「システム構成」タブの「Access Managerの設定」セクションに移動します。

2. 「SSOエージェント」ノードを開いてから、目的のエージェント・タイプ・ノードを開きます。

- OAMエージェント

- OSSOエージェント

3. オープン・ノードのコントロールを使用して、監視するエージェントを検索します。

4. 「検索結果」表で、監視するエージェントを含んでいる行をハイライト表示します。

5. 必要に応じて先に進みます。

- OAMエージェント・メトリックの確認

- OSSOエージェント・メトリックの確認

OAMエージェント・メトリックの確認

図25-5は、OAMエージェントのモニタリング特性を示します。

関連項目:
「10gおよび11g Webgateキャッシュのチューニング」

図25-5 OAMエージェントのモニタリング特性

「図25-5 OAMエージェントのモニタリング特性」の説明

次の図は、デタッチされた表を示します。

- 図25-6「デタッチされたOAM 10gエージェント接続の表」

- 図25-7「デタッチされたOAM 10gエージェント操作概要の表」

- 図25-8「デタッチされたOAM 10gエージェント操作詳細の表」

- 図25-9「デタッチされたOAM 10gエージェント情報の表」

図25-6 デタッチされたOAM 10gエージェント接続の表

「図25-6 デタッチされたOAM 10gエージェント接続の表」の説明

図25-7 デタッチされたOAM 10gエージェント操作概要の表

「図25-7 デタッチされたOAM 10gエージェント操作概要の表」の説明

図25-8 デタッチされたOAM 10gエージェント操作詳細の表

「図25-8 デタッチされたOAM 10gエージェント操作詳細の表」の説明

図25-9 デタッチされたOAM 10gエージェント情報の表

「図25-9 デタッチされたOAM 10gエージェント情報の表」の説明

OSSOエージェント・メトリックの確認

ナビゲーション・ツリーでOSSOエージェントが選択されており、「アクション」メニューで「モニター・メニュー」を選択すると、次のメトリック・ページが使用可能になります。

- 図25-10「OSSO 10gエージェントの「モニター」ページの「操作の詳細」

- 図25-11「デタッチされたOSSO 10gエージェント・モニタリング・プロセスの概要表」

- 図25-12「デタッチされたOSSO 10gエージェント情報表」

図25-10 OSSO 10gエージェントの「モニター」ページの「操作の詳細」

「図25-10 OSSO 10gエージェントの「モニター」ページの「操作の詳細」」の説明

図25-11は、デタッチされたOSSO 10gエージェント・モニタリング・プロセスの概要表を示します。

図25-11 デタッチされたOSSO 10gエージェント・モニタリング・プロセスの概要表

「図25-11 デタッチされたOSSO 10gエージェント・モニタリング・プロセスの概要表」の説明

図25-12は、デタッチされたOSSO 10gエージェント情報表を示します。

図25-12 デタッチされたOSSO 10gエージェント情報表

「図25-12 デタッチされたOSSO 10gエージェント情報表」の説明

OXMプロキシ・パフォーマンス・チューニング・パラメータ

OAMプロキシのパフォーマンスは、Java EEコンテナ管理コンソールを通じてその構成を変更することによってチューニングできます。Java EEコンテナ管理者とOAM管理者の両方が、パフォーマンスのチューニングを実行できます。

ここでは、次の内容について説明します。

- OAMプロキシ・メトリックについて

- OAMプロキシ・サーバーのチューニング・パラメータ

OAMプロキシ・メトリックについて

OAMプロキシは、Oracle Access Manager 10gのアクセス・サーバーと同じスループット、あるいは匹敵するスループットを実現します。スループットとは、1秒間に処理されるリクエスト数を言います。待機時間とは、特定のリクエストを処理するために必要な時間を言います。WebgateとOAMサーバーの間にプロキシを導入することによる待機時間の増加は20%未満です。

表25-1 OAMプロキシ・メトリック

メトリック

説明

handshakes.active

ハンドシェイクを行うアクティブ・スレッドの数

handshakes.avg

初期ハンドシェイクの実行に要した平均時間

handshakes.completed

初期ハンドシェイクが実行された回数

handshakes.maxTime

初期ハンドシェイクの実行に要した最大時間

handshakes.minTime

初期ハンドシェイクの実行に要した最小時間

handshakes.time

初期ハンドシェイクの実行に要した合計時間

failedHandshakes.count

失敗したハンドシェイク数

peerCompatibilityFailures.count

ピア互換性チェック失敗の発生回数

openSecurityMode.count

オープン・セキュリティ・モード・ハンドシェイクの発生回数

simpleSecurityMode.count

シンプル・セキュリティ・モード・ハンドシェイクの発生回数

SSLSecurityMode.count

SSLセキュリティ・モード・ハンドシェイクの発生回数

negotiateSecurityMode.active

セキュリティ・モード・ネゴシエーションを実行中のアクティブ・スレッド数

OAMプロキシ・サーバーのチューニング・パラメータ

OAMプロキシのチューニング・パラメータを表25-2に示します。

表25-2 OAMプロキシのチューニング・パラメータ

目的

パラメータ

タイプ

値

説明

スロットル

MaxGlobalBufferSize

注意: プロキシ・サーバーは、リソースを使用できないことによってクラッシュが発生するのを避けるために、指定時間当たりのリクエスト数が一定値を超えないように制限(スロットル)できます。

このような場合は、クライアントが一時的にそのリクエストを他のサーバーに回す必要があることを示すステータス・コードが返されます。

整数

すべての接続に対するメッセージ・キューの最大メモリ(KB)。この値を超えると、OAMプロキシは接続に関するリクエストをそれ以上受け付けなくなります。0または0未満の数が指定されると、このパラメータは使用されません。

サービス拒否攻撃

ConnectionValidationInterval

整数

120

サービス拒否攻撃に関して定期的に接続の検証を行う際の時間間隔(秒)

BacklogQueue

整数

50

バックログ・キューの最大長さ

MaxNAPHandShakeTime

整数

100

クライアント同士がNAPシェイクハンドを完了させるまでに使用できる最大時間(ミリ秒)。ある接続を介したNAPシェイクハンドがこの時間内に完了しなかった場合、その接続は悪意あるものとしてマークされます。

26 Fusion Middleware Controlによるパフォーマンスおよびログの監視

この章では、Oracle Fusion Middleware Controlを使用してOracle Access ManagerおよびOracle Security Token Serviceのパフォーマンスおよびログ・メッセージを監視する方法を説明します。この章では、管理者がFusion Middleware Controlから実行できる一般的なタスクを中心に説明しており、ここに示す内容は、『Oracle Fusion Middleware管理者ガイド』の詳細に代わるものではありません。

注意:
特に明記しないかぎり、この章の情報は、Oracle Access Managerを単体で使用している場合もOracle Security Token Serviceとともに使用している場合も同じです。

この章の内容は次のとおりです。

- 前提条件

- Fusion Middleware Controlの概要

- Fusion Middleware Controlへのログインとログアウト

- Fusion Middleware Controlでのメニューとページの表示

- Fusion Middleware Controlでのパフォーマンスの表示

- Fusion Middleware Controlでのログ・レベル変更の管理

- Fusion Middleware ControlでのMBeanの表示

- Fusion Middleware Controlでのファーム・ルーティング・トポロジの表示

前提条件

Oracle Fusion Middleware Controlは、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド 11g リリース1(11.1.1)』の説明に従い、WebLogic管理サーバー上のOracle Access Manager 11gを使用してデプロイする必要があります。

Fusion Middleware Controlの概要

Fusion Middleware Control内では、情報はOracle Access Manager with Oracle Security Token Service(および他の製品)のライブ・セッション中に動的に更新されます。

Fusion Middleware Controlは、様々なパフォーマンス・データと管理機能を個別にWebベースのページにまとめます。これにより、管理者は重要なモニタリング・データや最も一般的に使用される管理機能をWebブラウザから容易に見つけることができます。

注意:
Enterprise Manager Grid Controlは別途ライセンスされる製品で、Fusion Middleware Controlにはない追加的機能(主に、履歴確認や傾向分析のためのデータを収集して保存する機能)を備えています。

Oracle Access Manager 11gは、WebLogicコンテナを使用するJava EEアプリケーションとしてデプロイされます。高可用性とフェイルオーバーを実現するために、Oracle Access Manager with Oracle Security Token Serviceは、通常はWebLogicのクラスタ環境でデプロイされます。

WebLogic Serverドメインは複数のクラスタを持つことができます。クラスタ化されたすべてのコンポーネントのモニタリング統計とパフォーマンス統計を得るには、コンポジット・ターゲットが必要です。このターゲットは、メンバー・インスタンスのステータス、および合計ロード・パフォーマンス・メトリックとレスポンス・パフォーマンス・メトリックを提供します。Oracle Access Manager with Oracle Security Token Serviceに公開されるメトリックに加えて、Java EEアプリケーションやコンポジットJava EEアプリケーションでも一般的なパフォーマンス・メトリックを使用できます。

Fusion Middleware Controlは、図26-1に示すようにWebLogic管理サーバー上のOracle Access Manager 11gを使用してデプロイする必要があります。

図26-1 Fusion Middleware Control (AS-Control)のデプロイメント・アーキテクチャ

「図26-1 Fusion Middleware Control (AS-Control)のデプロイメント・アーキテクチャ」の説明

Oracle Access Manager with Oracle Security Token ServiceターゲットでのFusion Middleware Controlの使用は、Oracle Access Manager内のOracle Dynamic Monitoring Systemsインストゥルメンテーションによる場合のみサポートされます。このインストゥルメンテーションは次を提供するために使用されます。

- パフォーマンスの概要とドリルダウン

- ログ・メッセージの検索と動的なログ・レベルの変更

- ルーティング・トポロジの概要

- MBeanブラウザ

- Oracle Access Manager with Oracle Security Token Service用のコンポーネント・レベルおよびクラスタ・レベルのメトリック

Fusion Middleware Controlへのログインとログアウト

この項の内容は次のとおりです。

- Fusion Middleware Controlの「ファーム」ページについて

- Fusion Middleware Controlへのログイン

- Fusion Middleware Controlからのログアウト

Fusion Middleware Controlのログイン・ページについて

Fusion Middleware Controlのログイン・ページには、ユーザー名とパスワードを入力するためのフィールドがあります。Fusion Middleware Controlのログイン・ページの下部には複数のトピックが表示されており、クリックすると追加的な情報が表示されます。このログイン・ページを図26-2に示します。

図26-2 Fusion Middleware Controlのログイン・ページとヘルプ・トピック

「図26-2 Fusion Middleware Controlのログイン・ページとヘルプ・トピック」の説明

Fusion Middleware Controlへのログイン

このタスクを実行できるのはFusion Middleware Controlの管理者に限られます。

関連項目:
Fusion Middleware Controlの基礎的な使用方法については『Oracle Fusion Middleware管理者ガイド』

Fusion Middleware Controlへのログイン方法

1. ブラウザ・ウィンドウで、Fusion Middleware ControlのURLを入力します。次に例を示します。

http://host.domain.com:8888/em/

2. 操作性の拡張や新機能についての情報を得るには、ログイン・ページの下側にあるトピックを開いて内容を表示します。

3. Fusion Middleware Control管理者としてログインします。

4. 必要に応じて、Oracle Access Manager 11gを含んだファームを選択してください。

5. ヘルプ: OAM「ファーム」ページの「ファーム・リソース・センター」で希望のトピックを選択すると(あるいはページの右上にある「ヘルプ」をクリックすると)、より詳しい説明が表示されます。

6. 表示や構成の詳細は、この章の該当トピックを参照してください。

Fusion Middleware Controlからのログアウト

次の手順を使用して、Fusion Middleware Controlからサインアウトできます。

Fusion Middleware Controlからのログアウト方法

1. Fusion Middleware Controlの右上隅にある「ログアウト」リンクをクリックします。

2. ブラウザ・ウィンドウを閉じます。

Fusion Middleware Controlでのメニューとページの表示

この項では、Oracle Access Manager with Oracle Security Token Serviceに関する次のトピックを説明します。

- Fusion Middleware Controlの「ファーム」ページについて

- Fusion Middleware Controlのコンテキスト・メニューとページについて

- Fusion Middleware Controlでのコンテキスト・メニューとターゲット詳細の表示

関連項目:
Fusion Middleware Controlの基礎的な使用方法については『Oracle Fusion Middleware管理者ガイド』

Fusion Middleware Controlの「ファーム」ページについて

図26-3は、Fusion Middleware ControlのOracle Access Managerファーム・ページを示します。それぞれの「ファーム」ページには同様の情報が含まれています。ファーム・リソース・センターを使用すれば、ただちにオンライン情報にアクセスできます。

図26-3 Fusion Middleware ControlのOAM「ファーム」ページ

「図26-3 Fusion Middleware ControlのOAM「ファーム」ページ」の説明

「ファーム」ページの各セクションについては表26-1に示します。

表26-1 「ファーム」ページのセクション

「ファーム」ページのセクション

説明

デプロイメント

ファーム内のこのセクションには、アプリケーション・デプロイメントのそれぞれの内部アプリケーションのステータスとターゲットが表示されます。

「デプロイメント」セクション内(またはナビゲーション・ツリー内)のリンクをクリックすると、詳細を示すページが表示されます。

Fusion Middleware

ファーム内のこのセクションには、次におけるサーバー・インスタンスのステータス、ホスト、およびCPU使用状況が表示されます。

- WebLogic Serverドメイン

- Identity and Access

ページ上(またはナビゲーション・ツリー内)のリンクをクリックすると、より詳しいサマリーを含むページが表示されます。

ファーム・リソース・センター

次のカテゴリの大量のオンライン情報が含まれています。

- Fusion Middleware Controlの使用を開始する上で有効な情報

- Fusion Middleware Controlを使用する管理者タスク

- その他のリソース

リソース・センターのリソース内にあるリンクをクリックすると、選択した項目に関する情報が表示されます。オンラインで得られる情報は量が多いので、ここではこれらの詳細は繰り返すことはしません。

図26-4に示すようなページの左側にあるナビゲーション・ツリーを使用することにより、現在表示しているページに関係なく、操作対象となる特定のインスタンス(ターゲット)を選ぶことができます。実際に使用している環境で表示されるターゲット名は、ここに示すものとは異なります。

図26-4 Fusion Middleware Controlのファーム・ナビゲーション・ツリー

「図26-4 Fusion Middleware Controlのファーム・ナビゲーション・ツリー」の説明

詳細は「Fusion Middleware Controlへのログイン」を参照してください。

関連項目:
「Fusion Middleware Controlでのメニューとページの表示」

Fusion Middleware Controlのコンテキスト・メニューとページについて

Oracle Access Manager with Oracle Security Token Serviceでは、Fusion Middleware Controlのファーム詳細は、ナビゲーション・ツリー内で次のノードに分割されます。

- アプリケーション・デプロイメント

- 内部アプリケーション(ログアウト・ページと、OAM AdminServerインスタンスおよびOAM Serverインスタンスのその他の詳細を含む)

- WebLogic Serverドメイン(OAMファームを含むWebLogic Serverの詳細)

- Identity and Access(Oracle Access Managerクラスタまたは個々のOracle Access Managerサーバー・インスタンスを含み、この中にOracle Security Token Serviceが含まれます)

ナビゲーション・ツリーのノードをクリックすると、図26-5(アプリケーション・デプロイメントをクリックした場合)に示すように、個々のリンクと、ターゲット、タイプ、およびフルネームが記述された情報ページが表示されます。

図26-5 Fusion Middleware Controlの「ノード情報」ページ

「図26-5 Fusion Middleware Controlのノード情報ページ」の説明

(ナビゲーション・ツリー上またはページ上で)インスタンス(ターゲット)名をクリックすると、コンテキスト・メニューと詳細サマリー・ページが表示されます。ナビゲーション・ツリー内の「内部アプリケーション」ターゲットはハイライト表示され、右側に同じ名前のページが表示されます。ページ最上部のターゲット名の下にはコンテキスト・メニューが、図26-6のように表示されます。

図26-6 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー

「図26-6 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー」の説明

「アプリケーション・デプロイメント」メニューを図26-7に示します。

図26-7 「アプリケーション・デプロイメント」メニュー

「図26-7 「アプリケーション・デプロイメント」メニュー」の説明

WebLogic Serverドメイン: 対応するメニューが開いた状態のWebLogic Serverドメイン・ページを図26-8に示します。左下隅には、オンライン・ドキュメントへのリンクが表示されたOracle WebLogic Serverドメインのリソース・センターがあります。このページは、ファーム・ランディング・ページによく似ています。

図26-8 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー

「図26-8 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー」の説明

WebLogic Serverのドメイン・ノード内でターゲット名を選択すると、ターゲット・サマリー・ページが表示されます。このページは、図26-6に示すアプリケーション・デプロイメントページによく似ています。

詳細は、Fusion Middleware Controlでのコンテキスト・メニューとターゲット詳細の表示を参照してください。

関連項目:
「Identity and Access」ノードとその関連ページについては「Fusion Middleware Controlでのパフォーマンスの表示」。

Fusion Middleware Controlでのコンテキスト・メニューとターゲット詳細の表示

Fusion Middleware Control管理者は、次の手順を使用して、Oracle Access Manager with Oracle Security Token Serviceのコンテキスト・メニューおよびターゲット・ページを表示できます。

注意:
Oracle Access Managerの「ファーム」ページの「ファーム・リソース・センター」で、希望のトピックを選択すると(あるいはページの右上にある「ヘルプ」をクリックすると)、詳細な説明が表示されます。

関連項目:
Fusion Middleware Controlのコンテキスト・メニューとページについて

コンテキスト・メニューとターゲット情報の表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. Oracle Access Managerを含んだファームを、必要に応じて展開します。

3. 情報ページ: ナビゲーション・ツリーで次のいずれかをクリックすると、関連する情報ページが表示されます。

- アプリケーション・デプロイメント

- WebLogic Serverドメイン

- Identity and Access

4. メニューとサマリー・ページ: (ナビゲーション・ツリーまたは関連ページで)インスタンス名をクリックすると、サマリー・ページとメニューが表示されます(図26-6と図26-7)。

5. Oracle Access Managerクラスタ・ページまたはサーバー・ページ: 「Fusion Middleware Controlでのパフォーマンスの表示」を参照してください。

Fusion Middleware Controlでのパフォーマンスの表示

Fusion Middleware Controlは管理者に次の情報を提供します。

- Oracle Access Manager with Oracle Security Token Serviceのパフォーマンスのクラスタ全体表示

- 重要パフォーマンス・メトリックのサーバーごとのドリルダウン

- パフォーマンス・メトリックを迅速に追加または削除する能力

Fusion Middleware Controlを使用すれば、ライブ・セッションのパフォーマンス・メトリックを様々な書式で表示できます。選択されたノードとターゲット・インスタンスに対するページの概要を表26-2に示します。

表26-2 選択したノードとターゲットに対して表示されるページ

ノード

ターゲット

情報サマリー・ページ

パフォーマンス概要

パフォーマンス・サマリーとメトリック

アプリケーション・デプロイメント

内部アプリケーション

...AdminServer

oamsso_logout(11.1.1.3.0) AdminServer

oamsso_logout(11.1.1.3.0) oam_server

可

可

可

不可

不可

不可

可

可

可

WebLogic Serverドメイン

oam_bd(クラスタ名)

AdminServer

oam_server

可

可

可

不可

不可

不可

不可

可

可

Identity and Access

OAM(Oracle Access Managerクラスタ)

oam_server(Oracle Access Managerサーバー)

不可

不可

可

可

可

可

注意:
Oracle Security Token Serviceパフォーマンスが、Oracle Access Managerクラスタ・ページおよびOracle Access Managerサーバー・ページとともに含まれます。

この項の内容は次のとおりです。

- Fusion Middleware Controlの「パフォーマンス概要」ページについて

- 「メトリック・パレット」と「パフォーマンス・サマリー」ページについて

- Fusion Middleware Controlのパフォーマンス・メトリックの表示

- コンポーネント固有のパフォーマンス詳細の表示

Fusion Middleware Controlの「パフォーマンス概要」ページについて

Oracle Access Manager with Oracle Security Token ServiceのFusion Middleware Controlで「パフォーマンス概要」を使用して、WebLogicクラスタ情報を、個別のOracle Access Managerクラスタおよびサーバー・ターゲットの特定のパフォーマンス・メトリックへ反映できます。

「Oracle Access Managerクラスタ」ページ: 「Identity and Access」の最上位ノードを選択すると、「パフォーマンス概要」を含む「Oracle Access Managerクラスタ」の「デプロイメント」ページが表示されます。図26-9では、「Oracle Access Managerクラスタ」がナビゲーション・ツリーの「Identity and Access」ノードの下で選択されています。図26-9は、「Oracle Access Managerクラスタ」の「デプロイメント」セクションと「パフォーマンス概要」セクションを示します。このページには、トークン発行とトークン検証の表が含まれます。

図26-9 「Oracle Access Managerクラスタ」ページ

「図26-9 「Oracle Access Managerクラスタ」ページ」の説明

OAMサーバー・ページ: OAMサーバー・ターゲット名をナビゲーション・ツリー(または開いているページ)で選択すると、ターゲットの「パフォーマンス概要」が表示されます。OAMサーバー・ページの最上部で、サーバー・インスタンスの「主要なメトリック」のサマリーが「Oracle Access Managerクラスタ」の「デプロイメント」セクションのかわりに表示されます。図26-10は、OAM Serverインスタンスの「主要なメトリック」を示しており、「トークン発行/秒」と「トークン検証/秒」を含みます。「トークン検証」の成功率が含まれます。

図26-10 Oracle Access Managerサーバー・ページの「主要なメトリック」

「図26-10 Oracle Access Managerサーバー・ページの「主要なメトリック」」の説明

表26-3は、Fusion Middleware ControlでのOracle Access Managerクラスタ・インスタンスとOracle Access Managerサーバー・インスタンスの「パフォーマンス概要」の要素を示します。違いはわずかです。

表26-3 Fusion Middleware Controlの「パフォーマンス概要」のサマリー

セクションまたは列名

説明

「Oracle Access Managerクラスタ」メニュー

動的コンテキスト・メニューには、選択したターゲットに関係する機能が含まれています(ナビゲーション・ツリーでターゲットを右クリックしても表示されます)。このメニューは、選択したOracle Access Managerクラスタで使用できます。

「コンポーネント・パフォーマンス」コマンドを使用すると、「Access Manager」メトリックを表示するか、「セキュリティ・トークン・サービス」メトリックを表示するかを選択できます。

関連項目: 「Access Managerコンポーネント・ページ」および「セキュリティ・トークン・サービス・コンポーネント・ページ」。

「デプロイメント」、「Oracle Access Managerクラスタ」ページ

このセクションは、「Oracle Access Managerクラスタ」ページのみで表示されます。クラスタ内の各インスタンスのステータスについて説明します。次の情報が含まれています。

- インスタンス名

- ステータス

- 認証

- 認可

インスタンス名

この列には、クラスタ内の各OAMサーバー・インスタンスの名前が含まれます。次に例を示します。

OAM_server_name

ステータス

この列は、クラスタ内の各OAMサーバー・インスタンスのステータスを、次のいずれかで示します。

- 緑色の上向き矢印(実行中)

- 赤の下向き矢印(停止中)

認証

「認証」列が示す内容:

- 認証/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認証数

- 成功率(成功した認証の割合): クラスタ内の各OAMサーバー・インスタンスの認証成功の割合を表す数値

認可

この列は、クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数を示します。

「認可」列が示す内容:

- 認可/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数

- 成功率(成功した認可の割合): クラスタ内の各OAMサーバー・インスタンスの認可成功の割合を表す数値

Oracle Access Managerの「サーバー・インスタンス」メニュー

動的コンテキスト・メニューには、選択したターゲットに関係する機能が含まれています(ナビゲーション・ツリーでターゲットを右クリックしても表示されます)。このメニューは、選択したOracle Access Managerサーバー・インスタンスで使用できます。

「コンポーネント・パフォーマンス」コマンドを使用すると、特定の「Access Manager」メトリックを表示するか、「セキュリティ・トークン・サービス」メトリックを表示するかを選択できます。

関連項目: 「Access Managerコンポーネント・ページ」および「セキュリティ・トークン・サービス・コンポーネント・ページ」。

「主要なメトリック」、OAMサーバー・ページ

この表には、選択したOAMサーバー・インスタンスのみの統計のサマリーが表示されます。主要なメトリックには、次に示す、Oracle Access ManagerとOracle Security Token Serviceの両方の詳細が含まれます。

- 認証/秒、平均認証待ち時間(ミリ秒)、および成功比率

- 認可/秒、平均認可待ち時間(ミリ秒)、および成功比率

- トークン発行/秒、平均発行待ち時間(ミリ秒)、および成功比率

- トークン検証/秒、平均検証待ち時間(ミリ秒)、および成功比率

「パフォーマンス概要」、OAMクラスタ・ページおよびOAMサーバー・ページ

この項では、Oracle Access Managerの認証および認可操作と、Oracle Security Token Serviceのトークン発行およびトークン検証操作について図示します。「パフォーマンス概要」の「メトリック」は構成できません。メトリック・パレットを使用できるのはパフォーマンス・サマリーのみです。

OAMクラスタまたはOAMサーバー・インスタンスが選択されている場合、「パフォーマンス概要」には次が含まれます。

- 「認証/秒」と「認可/秒」

- 「トークン発行/秒」と「トークン検証/秒」

それぞれの表の座標は次のとおりです。

- 横軸(x軸)方向の座標は時間を表します。

- 縦軸(y軸)方向の座標は、その時間内に発生した指定トランザクションの回数を表します。

表ビュー

「パフォーマンス概要」の右下の「表ビュー」リンクをクリックすると、ポップアップ・ウィンドウ内の列にパフォーマンス情報が表示されます。

LDAPサーバー、OAMクラスタおよびOAMサーバー・ページ

このセクションは、OAMクラスタ・インスタンスまたは単一のOAMサーバー・インスタンスが選択されていると使用可能になります。デフォルトのLDAPユーザー・アイデンティティ・ストアの情報を示します。

- LDAP操作/秒

- LDAP待ち時間(ミリ秒)

- LDAP成功率

「アプリケーション・ドメイン」、OAMクラスタおよびOAMサーバー・ページ

OAMクラスタ・ページおよびOAMサーバー・ページのこのセクションには、認証プロセスおよび認可プロセスで使用されたすべてのアプリケーション・ドメインに関する情報が表示されます。

このセクションの列に表示されるものは、次のとおりです。

- アプリケーション・ドメイン名: リクエストに使用された認証および認可ポリシーを含む各アプリケーション・ドメイン。

- 各アプリケーション・ドメインの「認証/秒」、「認証待ち時間(ミリ秒)」、成功比率(%)

- 各アプリケーション・ドメインの「認可/秒」、「認可待ち時間(ミリ秒)」、成功比率(%)

Access Managerコンポーネント・ページ

Oracle Access ManagerクラスタおよびOracle Access Managerサーバー・インスタンスの両方のメニューにある「コンポーネント・パフォーマンス」コマンドを使用すると、Access Manager固有のメトリックを表示できます。

Oracle Access Managerクラスタ・コンポーネント固有のメトリックは、図26-11で示すように、クラスタ全体で集約されます。表26-4の後に詳細な説明があります。

図26-11 クラスタの集約されたAccess Managerコンポーネント・メトリック

「図26-11 クラスタの集約されたAccess Managerコンポーネント・メトリック」の説明

図26-12は、単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリックを示しています。

図26-12 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック

「図26-12 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック」の説明

表26-4は、Oracle Access Managerのコンポーネント固有のメトリックを示します。

表26-4 Access Managerコンポーネント・メトリック

Access Managerコンポーネント・メトリック

説明

Access Managerクライアント

選択内容(クラスタ・インスタンスまたはサーバー・インスタンス)に基づいて、このページにはクラスタ内でアクティブなすべてのアクセス・クライアントの(または個別のOAMサーバーのアクティブなアクセス・クライアントの)情報が表示されます。この表には次の詳細が含まれます。

- クライアントID

- タイプ

- 認証

- 認可

クライアントID

Oracle Access Managerコンソールのエージェント登録で定義されたエージェント名が表示されます。次に例を示します。

IAMSuiteAgent

タイプ

エージェントのタイプを表示します。次に例を示します。

OAM Webgate

認証

「認証」列が示す内容:

- 認証/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認証数

- 待ち時間(ミリ秒): 認証が遅延したミリ秒数

- 成功率(%): クラスタ内の各OAMサーバー・インスタンスの認証成功の割合を表す数値

認可

「認可」列が示す内容:

- 認可/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数

- 待ち時間(ミリ秒): 認可が遅延したミリ秒数

- 成功率(%): クラスタ内の各OAMサーバー・インスタンスの認可成功の割合を表す数値

セキュリティ・トークン・サービス・コンポーネント・ページ

Oracle Access ManagerクラスタおよびOracle Access Managerサーバー・インスタンスの両方のメニューにある「コンポーネント・パフォーマンス」コマンドを使用すると、セキュリティ・トークン・サービス(STS)固有のメトリックを表示できます。

Oracle Access Managerクラスタでコンポーネント固有のメトリックが、図26-11で示すように集約されています。

図26-13 クラスタの集約されたSTSコンポーネント・メトリック

「図26-13 クラスタの集約されたSTSコンポーネント・メトリック」の説明

図26-11で示したとおり、それぞれ個別のサーバー・インスタンスで、STSコンポーネント固有メトリックも使用可能です。

図26-14 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック

「図26-14 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック」の説明

表26-5では、STSコンポーネント固有のメトリックを説明します。

表26-5 STSコンポーネント固有のメトリック

セキュリティ・トークン・サービス・コンポーネント・メトリック

説明

リクエスタ・パートナ

選択したOAMサーバー・インスタンスの統計サマリー(あるいはクラスタの集約されたサマリー):

- パートナID

- トークン発行

- トークン検証

リクエスタ・パートナIDを選択すると、指定したパートナのみの特定情報を含むリライイング・パーティの詳細が明らかになります。

トークン操作

STSトークン操作のメトリックには、次のものが含まれます。

- トークン・タイプ

- トークン発行: リクエストの合計、リクエスト/秒、平均発行待ち時間(ミリ秒)

- トークン検証: リクエストの合計、リクエスト/秒、平均発行待ち時間(ミリ秒)

「メトリック・パレット」と「パフォーマンス・サマリー」ページについて

「Oracle Access Managerクラスタ」メニューまたはサーバー・メニューの「パフォーマンス・サマリー」コマンドは、選択したターゲットのメトリック・チャートを表示します。

図26-15 「パフォーマンス・サマリー」コマンド

「図26-15 「パフォーマンス・サマリー」コマンド」の説明

「パフォーマンス・サマリー」ページには、選択されたそれぞれのメトリックに対してチャートが表示されます。OAMサーバーの「パフォーマンス・サマリー」ページです。図26-16は、「メトリック・パレット」が開いている「パフォーマンス・サマリー」ページを示しており、ここからメトリックを選択してチャート化できます。積上げチャートでは、同じ時間枠の複数のメトリックを比較したり、時間枠を変更して過去にさかのぼったり、拡大や縮小を容易にできます。

図26-16 「メトリック・パレット」を表示した「パフォーマンス・サマリー」ページ

「図26-16 「メトリック・パレット」を表示した「パフォーマンス・サマリー」ページ」の説明

「パフォーマンス・サマリー」ページで使用できるステータスとコントロールを表26-6に示します。

表26-6 「パフォーマンス・サマリー」ページのステータスとコントロール

ステータスまたはコントロール

説明

過去n分間

ステータスは指定された時間枠に基づくもので、この時間はスライダで調整できます。

すべて

n分間

指定された時間枠。スライダを使用して調整できます。

スライダ

時間枠を調整するために使用するツール。

チャート・セット

保存されたチャートのセットを選択して表示することのできるリスト。

表示

グリッドの追加、チャートの保存、およびページ上の情報を構成することのできるメニュー。

オーバーレイ

同じタイプの別のインスタンスを検索して表示し、これをサマリー内のインスタンスと比較することのできるメニュー。

メトリック・パレット

チャートに表示するパフォーマンス・メトリックを選択することのできるリスト。Oracle Access Manager with Oracle Security Token Service独自の項目がここに表示されます。

左: クラスタの「メトリック・パレット」

右: 単一のOAMサーバーの「メトリック・パレット」

Fusion Middleware Controlのパフォーマンス・メトリックの表示

Fusion Middleware Control管理者は、次の手順を使用して、Oracle Access Manager with Oracle Security Token Serviceの「パフォーマンス・サマリー」に表示されるメトリックを追加または変更できます。

関連項目:

- 「Fusion Middleware Controlの「パフォーマンス概要」ページについて」

- 「「メトリック・パレット」と「パフォーマンス・サマリー」ページについて」

「パフォーマンス・サマリー」に表示されるメトリックの追加または変更方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. パフォーマンス概要:

1. 希望のノードを開いてターゲットを選択します。例:Identity and Access
Identity and Access
oam_server

2. パフォーマンス概要を確認します。

3. パフォーマンス・サマリー:

1. ターゲットを選択します(ステップ1)。

2. コンテキスト・メニューから「パフォーマンス・サマリー」を選択します。

3. 「サマリー」ページを確認します。

4. メトリックの変更:

1. 「パフォーマンス・サマリー」ページから(ステップ2)、「メトリック・パレットの表示」ボタンをクリックします。

2. 「メトリック・パレット」で、ノードを展開してボックスを選択(または選択解除)し、サマリーからメトリックを追加(または削除)します。

3. 更新された「サマリー」ページを確認します。

4. 終了したら、「メトリック・パレットの非表示」をクリックします。

5. チャート・セットの保存:

1. 「パフォーマンス・サマリー」ページの「表示」メニューで、「チャート・セットの保存」をクリックします。

2. 表示されたダイアログ・ボックスでそのチャート固有の名前を入力し、操作を確認して「OK」をクリックします。

3. 終了したら、「メトリック・パレットの非表示」をクリックします。

4. 「サマリー」ページで更新された情報を確認します。

6. オーバーレイ、Oracle Access Managerの追加:

1. 「パフォーマンス・サマリー」ページの「オーバーレイ」メニューで、「別のOracle Access Manager」をクリックします。

2. 「ターゲットの検索と選択」ダイアログでターゲット名とホスト名を入力し、「実行」をクリックします。

3. ターゲット結果の表で希望するターゲット名をクリックし、「選択」を選択します。

4. オーバーレイの表示が終了したら、「オーバーレイ」メニューで「オーバーレイの削除」をクリックします。

7. オーバーレイ、今日と昨日の追加:

1. 「パフォーマンス・サマリー」ページの「オーバーレイ」メニューで、「今日と昨日」をクリックします。

2. オーバーレイの表示が終了したら、「オーバーレイ」メニューで「オーバーレイの削除」をクリックします。

8. テスト:

1. アクセス・テスターを使用して、何回か認証テストと認可テストを実行します(第14章を参照)。

2. Fusion Middleware Controlでパフォーマンス・メトリックを確認します。

コンポーネント固有のパフォーマンス詳細の表示

Fusion Middleware Control管理者は、次の手順を使用して、Oracle Access ManagerとOracle Security Token Serviceのコンポーネント固有パフォーマンス・データを表示および比較できます。

関連項目:

- 「Access Managerコンポーネント・ページ」

- 「Security Token Serviceコンポーネント・ページ」

コンポーネント固有パフォーマンス詳細の表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。次に例を示します。
Identity and Access
oam_server

3. コンテキスト・メニューから、「コンポーネント・パフォーマンス」を選択します。

4. 「Access Manager」(または「セキュリティ・トークン・サービス」)を選択します。

5. STSパートナID: 必要な場合は、詳細について「セキュリティ・トークン・サービス」結果表で「パートナID」を選択します。

6. コンポーネント・パフォーマンス:

1. コンテキスト・メニューから、「コンポーネント・パフォーマンス」を選択します。

2. 「Access Manager」または「セキュリティ・トークン・サービス」のいずれかを選択します。

3. 使用可能な場合は、結果表で項目を選択して詳細を表示します。

7. テスト:

1. アクセス・テスターを使用して、何回か認証テストと認可テストを実行します(第14章を参照)。

2. Fusion Middleware Controlでパフォーマンス・メトリックを確認します。

Fusion Middleware Controlでのログ・レベル変更の管理

Oracle Access Managerのコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを作成します。管理者は、この章の説明に従い、Fusion Middleware Controlを使用してログ・レベルを設定できます。

注意:
この他、第22章に示すように、管理者はカスタムWebLogic Scripting Tool(WLST)コマンドを使用してOAMロガー・レベルを設定できます。

この項には、次の各項目が含まれます。

- 動的なログ・レベルの変更について

- Fusion Middleware Controlを使用した動的なログ・レベルの設定

動的なログ・レベルの変更について

Fusion Middleware Controlを使用すると、管理者はOracle Access Manager with Oracle Security Token Serviceのログ・レベルを動的に変更できます。

表26-7は、使用可能なログとFusion Middleware Controlの機能を示します。

表26-7 OAMで使用可能なログとFusion Middleware Controlの機能

ノード

ターゲット

ログ・メッセージの表示

ログ構成

アプリケーション・デプロイメント

内部アプリケーション

...AdminServer

oamsso_logout(11.1.1.3.0) AdminServer

oamsso_logout(11.1.1.3.0) oam_server

可

可

可

可

可

可

WebLogic Serverドメイン

oam_bd(クラスタ名)

AdminServer

oam_server

可

可

可

不可

可

可

Identity and Access

OAM(Oracle Access Managerクラスタ)

oam_server(Oracle Access Managerサーバー)

不可

可

不可

可

図26-17は、Fusion Middleware Controlの「ログ・レベル」構成ページを示します。「ランタイム・ログ出力」が選択された「表示」で、oracle.oamログ出力名が現在表示されていることに注意してください。Oracle Security Token Serviceでは、Oracle Security Token Serviceのログ・レベルに影響を及ぼすログ出力(oracle.security.fed)が1つのみあります。

図26-17 「ログ構成」タブのOracle Access Managerログ・レベル

「図26-17 「ログ構成」タブのOracle Access Managerログ・レベル」の説明

図26-18 Oracle Security Token Serviceのログ・レベル

「図26-18 Oracle Security Token Serviceのログ・レベル」の説明

「ログ構成」ページの「ログ・レベル」タブを使用すれば、永続ロガーおよびアクティブ・ランタイム・ロガー両方のログ・レベルの構成を設定できます。

- 永続ロガーは構成ファイルに保存され、コンポーネントが起動するとアクティブになります。
これらのロガーのログ・レベルは、コンポーネントを再起動しても維持されます。

- ランタイム・ロガーは実行時に自動的に作成され、特定の機能領域が実行されるとアクティブになります。
たとえばoracle.j2ee.ejb.deployment.Loggerは、EJBモジュールがデプロイされるとアクティブになるランタイム・ロガーです。ランタイム・ロガーのログ・レベルは、コンポーネントを再起動すると変更されます。

表26-8では、ログ・レベルの構成ステータスとオプションを説明します。

表26-8 「ログ構成」ページの「ログ・レベル」タブ

要素

説明

適用

ログ・レベル構成の変更を送信して適用します。変更内容はただちに有効になります。

元に戻す

前のログ・レベル構成を復元します。復元内容はただちに有効になります。

表示

このリストを使用して、ランタイム・ロガーまたは永続的なログ・レベル状態を持つロガーを表示します。

- ランタイム・ログ出力

- 永続的なログ・レベル状態を持つロガー

検索

このリストを使用して、検索しようとするカテゴリを指定します。

表

ログ出力名

検索中に見つかったロガーの名前。リスト内の名前を開いて、最上位ノードの下にあるロガーを表示できます。

Oracle Diagnostic Loggingレベル(Javaレベル)

対応するロガー(c)のロギング・レベルを選択します。

「適用」をクリックして、ポップアップ・ウィンドウに表示される確認メッセージを確認します。

ログ・レベルを更新しています
ランタイム・ロガーのログ・レベルを更新しています
ランタイム・ロガーのログ・レベルの更新に成功しました
ログ・レベルの更新に成功しました

ログ・ファイル

「ログ・ファイル」列の名前をクリックすると「ログ・ファイル」ページが表示されます。このページでは、ログ・メッセージを記録するファイル、ログ・メッセージの書式、ローテーション・ポリシー、その他のロギング・パラメータを作成および編集できます。

関連項目: 「Fusion Middleware Controlによるログ・ファイル構成の管理」

永続ログ・レベル状態

「ログ・ファイル」タブを使用して値の作成または編集を行った時に設定した、特定ロガーの永続的状態を示します。

Fusion Middleware Controlを使用した動的なログ・レベルの設定

Fusion Middleware Control管理者は、次の手順を使用してOracle Access Manager with Oracle Security Token Serviceのログ・レベルを動的に設定できます。

関連項目:
動的なログ・レベルの変更について

注意:
または、第22章で説明したとおり、管理者はカスタムWebLogic Scripting Tool(WLST)コマンドを使用してログ出力レベルを設定できます。

Fusion Middleware Controlでのロギング・レベルの動的設定方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。次に例を示します。
Identity and Access
oam_server

3. 「Oracle Access Manager」コンテキスト・メニューから、「ログ」を選択してから「ログ構成」を選択します。

4. 「ログ・レベル」タブの「表示」リストで、表示するログ出力を選択します。例: ランタイム・ログ出力。

5. 「検索」リストからカテゴリを選択し、検索基準を入力して、検索ボタンをクリックします。例: 「すべてのカテゴリ」の「sts」。

6. 結果表内で必要に応じてノードを開き、内容を表示します。

7. 結果表で、ご使用の環境に合ったログ・レベルを選択してから「適用」(または「元に戻す」)をクリックします。

8. 「Fusion Middleware Controlによるログ・ファイル構成の管理」に進みます。

Fusion Middleware Controlによるログ・ファイル構成の管理

この項では、Oracle Access Manager with Oracle Security Token Serviceに関する次の情報を説明します。

- ログ・ファイルの構成について

- Fusion Middleware Controlを使用したログ・ファイル構成の管理

ログ・ファイルの構成について

ログ・ファイルの構成を図26-18に示します。ログ・メッセージの記録場所、ログ・メッセージの書式、使用するローテーション・ポリシー、ログ・ファイルの構成クラスに応じたその他のパラメータの作成と編集にはこのページを使用します。

図26-19 ログ・ファイルの構成ページ

「図26-19 ログ・ファイルの構成ページ」の説明

表26-9では、Oracle Access Manager with Oracle Security Token Serviceのログ・ファイル構成パラメータを説明します。

表26-9 ログ・ファイル要素

要素

説明

作成

メッセージ記録用の新しいファイルを作成するために未定義フォームを表示するには、このボタンをクリックします。

注意:

- 「ログ・ファイル」はログ・ハンドラの名前です(OAM用のodl-handler)。

- 「ログ・パス」はご使用の環境内のロギング出力ファイルを指していますが、これは変更可能です。

- ユーザー環境内の出力ロギング・ファイルには固有の名前を付けることができます。

類似作成

メッセージ記録用の新しいファイルを作成するために一部定義済のフォームを表示するには、このボタンをクリックします。

構成の編集

選択したログ・ファイル構成の表示と編集には、このボタンを使用します。

構成の表示

選択したログ・ファイル構成の読取専用記述を表示するには、このボタンをクリックします。

表

この表内の情報は、この表内のファイル構成パラメータに基づくものです。

ハンドラ名

ログ・ファイルの作成時に割り当てられたログ・ファイル名です。

ログ・パス

ファイル作成時に割り当てられたファイル・システム・ディレクトリ・パスです。

ログ・ファイル形式

ログ・ファイル作成時に割り当てられたログ・ファイル形式です。

ローテーション・ポリシー

ログ・ファイル作成時に選択されたローテーション・ポリシーです。

Fusion Middleware Controlを使用したログ・ファイル構成の管理

Fusion Middleware Controlの管理者は、次の手順を使用して、ログ・ファイルの作成、構成の編集、または読取専用ログ・ファイル構成の表示を行うことができます。

関連項目:
ログ・ファイルの構成について

Fusion Middleware ControlでOAMのログ・ファイルを管理する方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。次に例を示します。
Identity and Access
oam_server

3. 「Oracle Access Manager」メニューで、「ログ」を選択してから「ログ構成」を選択します。

4. ログ・ファイルの作成: 「ログ・ファイル」タブから(表26-9):

1. 「作成」ボタンをクリックして、新しい「ログ・ファイルの作成」フォームを表示します。

2. このログ・ファイルの名前とファイル・システム・パスを入力します。次に例を示します。
ログ・ファイルoam-odl-handler

ログ・パス・ドメイン/oam_db/servers/oam-server1/log/oam.log

3. 希望のログ・ファイル形式をクリックします。例: ... 「テキスト」

4. ロギング属性を設定します。次に例を示します。
デフォルト属性の使用X

サプリメンタル属性

5. ロガーを関連付けます。例: ルート・ログ出力

6. 「ローテーション・ポリシー」を指定します。例: サイズ・ベース
最大ログ・ファイル・サイズ(MB)10.0

すべてのログ・ファイルの最大サイズ(MB)1000.0

7. 「OK」をクリックして構成を送信します。

5. 類似作成:

1. 「ログ・ファイル」タブで、既存のログ・ファイル名をクリックします。

2. 「類似作成」ボタンをクリックします。

3. 「ログ・ファイルの作成」フォームで、次の情報を入力します。
ログ・ファイル名

ログ・レベル

属性

4. 必要に応じて他の詳細を編集し、「OK」をクリックして構成を送信します。

6. 構成の編集:

1. 「ログ・ファイル」タブで、既存のログ・ファイル名をクリックします。

2. 「構成の編集」ボタンをクリックします。

3. 必要に応じて構成の詳細を変更します。

4. 「OK」をクリックして変更内容を送信します。

7. 構成の表示:

1. 「ログ・ファイル」タブで、既存のログ・ファイル名をクリックします。

2. 「構成の表示」ボタンをクリックします。

3. 内容を確認し、「OK」をクリックして構成ページを閉じます。

8. 「Fusion Middleware Controlでのログ・メッセージの表示」に進みます。

Fusion Middleware Controlでのログ・メッセージの表示

この項の内容は次のとおりです。

- ログ・メッセージの検索、表示およびエクスポートについて

- Fusion Middleware Controlによるログ・メッセージの表示

ログ・メッセージの検索、表示およびエクスポートについて

Fusion Middleware ControlでOracle Access Manager Serverインスタンスのコンテキスト・メニューを使用することによって、管理者は次に関する重要ログ情報の検索、表示、およびエクスポートを行うことができます。

- AdminServerおよびOAMサーバー両方のWebLogic(およびOAM)AdminServerログアウト・ページとOAM SSOログアウト・ページを含むアプリケーション・デプロイメント・ターゲット

- OAMファーム、AdminServer、およびOAMサーバーを含むWebLogicサーバー・ドメイン・ターゲット

- Oracle Access Managerファーム、クラスタ、および個々のOAMサーバーを含むIdentity and Accessターゲット

ログ・ファイルを使用して一般的な問題のトラブルシュートを行うには、次の条件を満たす必要があります。

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明されているとおり、Oracle Fusion Middlewareコンポーネントが使用するOracle Diagnostic Logging(ODL)のフォーマットを理解する

- 適切なレベルの情報を収集するようにログ・ファイルを構成する

- ファーム内の重要ログ情報を検索、表示、エクスポートする

- コンポーネント間でログ・ファイル内のメッセージを相互に関連付けする

図26-20は、Fusion Middleware ControlでのOracle Access Manager with Oracle Security Token Serviceの「ログ・メッセージ」ページを示します。

図26-20 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ

「図26-20 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ」の説明

表26-10はFusion Middleware Controlの「ログ・メッセージ」ページの要素を示しており、これらの要素を使用するとメッセージを探して表示できます。

表26-10 Fusion Middleware ControlのOAMログ・メッセージ検索コントロール

要素

説明

広範囲のターゲット・スコープ

このリストから項目を選択すると、この検索に使用されるターゲットが拡大(または縮小)されます。

- Oracle WebLogic Serverドメイン

- Oracle Access Managerクラスタ

- Oracle WebLogic Server

- Oracle Fusion Middlewareファーム

ターゲット・ログ・ファイル...

ターゲット・スコープに対するすべてのログ・ファイルのリストが表示されます。ユーザーは、このスコープから特定のログ・ファイルを選択して表示またはダウンロードできます。

リフレッシュ・オプション

このリストから項目を選択してリフレッシュ方法を指定します。

- 手動リフレッシュ

- 30秒リフレッシュ

- 1分間リフレッシュ

検索オプション

日付範囲

希望するメッセージのセットが記録される期間。

- 最新
分

時間

日

- 時間間隔
日付範囲

開始日

終了日

メッセージ・タイプ

この検索に適用されるすべてのメッセージ・タイプを選択します。

- インシデント・エラー

- エラー

- 警告

- 通知

- トレース

- 不明

メッセージ

このリストから識別子を選択し、横にある空白フィールドに値を入力して検索基準を変更します。

フィールドの追加

含めることのできる追加検索基準のリストを表示するには、このボタンをクリックします。

検索

特定の基準を使用して検索を開始するには、このボタンをクリックします。

表示オプション

表示

検索結果表の列の表示または並べ替えをするには、このメニューから項目を選択します。

表示

表示するエンティティを選択します。

関連メッセージの表示

このメニューは、検索結果に少なくとも1つのメッセージがリストされていれば使用できます。

メッセージをファイルにエクスポート

検索結果に少なくとも1つのメッセージがリストされていれば使用することのできる表示コマンドのメニュー。次のコマンドから選択できます。

結果の表の列

これらは、「ログ・メッセージ」ページの「表示」メニューでの選択に基づいて決定されます。

メッセージ・エリア

検索結果の表で選択したメッセージの詳細が表示されます。

Fusion Middleware Controlによるログ・メッセージの表示

Fusion Middleware Controlの管理者は、次の手順を使用して、ターゲットのログ・メッセージの表示とダウンロードを行うことができます。この手順は、メッセージの検索、メッセージの表示(または関連メッセージの表示)、1つのログ・ファイル内のすべてのメッセージの表示、およびメッセージのエクスポートまたはダウンロードの方法を説明したものです。

関連項目:
ログ・メッセージの検索、表示およびエクスポートについて

Fusion Middleware Control内でのOAMサーバー・ログ・メッセージの表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。次に例を示します。
Identity and Access
oam_server

3. OAMのコンテキスト・メニューで「ログ」を選択し、さらに「ログ・メッセージの表示」を選択します。

4. 検索(表26-10):

1. 「日付範囲」を指定します。

2. 検索に含めるすべての「メッセージ・タイプ」を選択します。

3. 「メッセージ」内容オプションを決定します。

4. フィールドの追加: メッセージの内容をさらに明確にするための詳細を入力します。

5. 「検索」をクリックして、検索基準に合致するメッセージのリストを表示します。

5. メッセージの表示: 検索結果の表から1つ以上のメッセージをクリックすると、それらがページの下半分に表示されます。

6. 関連の表示: 次のいずれかの方法を使用して検索結果の表を編成します。

1. 時間ごと: 関連メッセージの表示メニューから、「時間ごと」を選択します。

2. ECIDごと: スクリーン上のメッセージの中からECIDをクリックします(または、関連メッセージの表示メニューから「ECID(実行コンテキストID)ごと」を選択します)。

3. 「スコープ」メニューから時間枠を選択します。

7. ログ・ファイル: ファイル内のすべてのメッセージを表示するには、検索結果の表で「ログ・ファイル」列の名前をクリックします。

8. メッセージをファイルにエクスポート

1. 検索結果の表で、1つまたは複数のメッセージを選択します。

2. 「メッセージをファイルにエクスポート」メニューから、希望するエクスポート・フォーマットを選択します。例: Oracle診断ログ・テキスト(.txt)として

3. ダイアログ・ボックスで使用プログラムをクリックし、希望のプログラムを選択します。

4. 開いたプログラムから、新しいパスにファイルを保存します。

9. ダウンロード

1. 検索結果の表で、1つまたは複数のメッセージを選択します。

2. 「ダウンロード」ボタンをクリックします。

3. ダイアログ・ボックスで使用プログラムをクリックし、希望のプログラムを選択します。

4. 開いたプログラムから、新しいパスにファイルを保存します。

10. テスト:

1. アクセス・テスターを使用して、無効なユーザー名を入力して認証を試みます(第14章を参照)。

2. Fusion Middleware Controlでログ・ビューアを開き、エラーを確認します。

3. アクセス・テスターを使用して、無効なパスワードを入力して認証を試みます。

4. Fusion Middleware Controlのログ・ビューアでエラーを確認し、すべての関連ログ・メッセージを表示します。

5. 「Fusion Middleware Controlでのログ・レベル変更の管理」の説明に従い、様々なログ・レベルを使用してこのテストを繰返します。

Fusion Middleware ControlでのMBeanの表示

Javaオブジェクトは、コンピュータを作動させるコードの単位です。それぞれのオブジェクトは特定のクラス、またはクラスのメソッドやプロシージャ、あるいはデータ変数に依存するサブクラスのインスタンスです。Javaプログラミング言語では、管理可能なリソースを表すJavaオブジェクト(アプリケーション、サービス、コンポーネント、またはデバイス)をMBeanと呼びます。

Fusion Middleware Controlでは次のことが可能です。

- 重要なMBeanの「属性」と「操作」に関する情報の表示

- メソッドの起動

この項の内容は次のとおりです。

- システムMBeanブラウザについて

- MBeanの管理

システムMBeanブラウザについて

Fusion Middleware ControlのシステムMBeanブラウザは、表26-11に概要を示す項目の表示に使用できます。

表26-11 システムMBeanブラウザ

ノード

ターゲット

システムMBeanブラウザ

アプリケーション・デプロイメント

内部アプリケーション

...AdminServer

oamsso_logout(11.1.1.3.0) AdminServer

oamsso_logout(11.1.1.3.0) oam_server

可

可

可

WebLogic Serverドメイン

oam_bd(クラスタ名)

AdminServer

oam_server

可

可

可

Identity and Access

OAM(Oracle Access Managerクラスタ)

oam_server(Oracle Access Managerサーバー)

不可

可

注意:
Oracle Security Token Service MBeanは、ここで説明するように使用することもできます。

表26-12は、Oracle Access ManagerおよびOracle Security Token Serviceがドメイン・ランタイム・サーバー(OAMサーバー)のAdminServerにデプロイするMBeanを示しています。

表26-12

MBean

説明

構成サービス

oracle.oam:type=Config

パートナおよび信頼サービス

oracle.oam:type=PATConfig

STS MBean

oracle.sts:type=Config

証明書検証モジュール

これらはCRL管理に使用されます。

oracle.sts:type=CertRevocationListConfig

図26-21では、「システムMBeanブラウザ」および関連の「属性」タブに、Oracle Security Token Service CertRevocationListConfig: oracle.sts:Location=oam_server1,type=CertRevocationListConfigの情報が表示されています。

図26-21 「システムMBeanブラウザ」と「属性」タブ

「図26-21 「システムMBeanブラウザ」と「属性」タブ」の説明

表26-13では、「システムMBeanブラウザ」と関連するタブを詳細に説明します。

表26-13 システムMBeanブラウザ

システムMBeanブラウザ

システムMBeanブラウザ

このセクションの項目を開くと、選択したターゲットのMBeanが表示されます。「アプリケーション定義のMBean」の下に、oracle.oamとoracle.stsがあります。

MBean情報

選択したターゲットのMBeanに関係する「属性」と「操作」の詳細が右側に表示されます。

属性

このタブには、選択したターゲットのMBean属性が表示されます。

操作

このタブには、選択したターゲットのMBean操作が表示されます。

通知

このタブにはMBeanの起動によって生成される通知がリストされます。

コントロール

次のコントロールをこれらのページで使用できます。

- 「名前」リンク: 名前をいずれかのタブでクリックすると、関係するMBeanの詳細が表示されます。

- 「適用」ボタン: 選択したMBean属性値を送信して適用します。

- 「元に戻す」ボタン: 変更後(「適用」のクリック前)に直前のMBean属性値を復元します。

- 「戻る」ボタン: MBean情報のページに戻ります。

- 「呼出し」ボタン: 選択したMBeanおよび値を呼び出します。

Mbeanの管理

Fusion Middleware Control管理者は、次の手順を使用して、Oracle Access ManagerまたはOracle Security Token ServiceのMBeanを表示できます。さらに、値を適用して(または変更を元に戻して)MBeanを起動できます。

Oracle Access ManagerおよびOracle Security Token ServiceのMBeanを表示、編集、または起動する方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。次に例を示します。
Identity and Access
oam_server

3. 「Oracle Access Manager」コンテキスト・メニューから、「システムMBeanブラウザ」を選択します。

4. システムMBeanブラウザ: クラスを開いて、関連する属性と操作を表示するためのMBeanターゲットを選択します。例: oracle.stsまたはoracle.oam

5. MBean属性の管理:

1. 「属性」タブをクリックします。

2. 選択したターゲットに対するMBean属性の名前と記述を確認します。

3. 1つまたは複数の属性の値を編集して「適用」をクリックし、変更を送信します(または「元に戻す」をクリックして変更をキャンセル)。
あるいは、「属性」表で「名前」をクリックして詳細と値を表示し、値を変更して「適用」をクリックします(または「元に戻す」をクリックして変更を取り消します)。

6. MBean操作の管理:

1. 「操作」タブをクリックします。

2. 選択したターゲットに対するそれぞれのMBean操作の名前、記述、パラメータ数、戻り値型を確認します。

3. 「操作」表の名前をクリックして、パラメータ、および関連する名前、記述、型、および値を表示します。

4. 操作する値を編集して「適用」をクリックし、変更を送信します(または「元に戻す」をクリックして変更をキャンセル)。

5. 「呼出し」をクリックしてMBeanを呼び出し、表示されるメッセージを確認します。

Fusion Middleware Controlでのファーム・ルーティング・トポロジの表示

Fusion Middleware Controlを使用すれば、Oracle Access Managerのルーティング・トポロジをグラフィカルに表示できます。

この項の内容は次のとおりです。

- ルーティング・トポロジについて

- Fusion Middleware Controlを使用したルーティング・トポロジの表示

ルーティング・トポロジについて

Fusion Middleware Controlのファーム・ルーティング・トポロジ・ページを図26-22に示します。

図26-22 コンテキスト・メニューが表示された状態のルーティング・トポロジ

「図26-22 コンテキスト・メニューが表示された状態のルーティング・トポロジ」の説明

ファーム・トポロジ・ページのステータスとコントロールを表26-14に示します。

表26-14 ファーム・トポロジ

要素

説明

イメージの保存

イメージを保存します。

印刷

イメージを印刷します。

イメージを拡大縮小します。

検索

値を入力するか「検索」をクリックすると結果が表示されます。

+

トポロジ・ビュー上のインスタンスを開いて詳細を表示します。

ステータス・バー

完全なファーム名とファーム内のターゲット、および実行状態を表示します。トポロジ・ビュー上の個々のインスタンス上にステータスとメトリックをオーバーレイさせることもできます。

Fusion Middleware Controlを使用したルーティング・トポロジの表示

Fusion Middleware Controlの管理者は、次の手順を使用して、OAM 11gを含むファームのルーティング・トポロジを表示できます。

関連項目:
ルーティング・トポロジについて

ファーム・ルーティング・トポロジの表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. ナビゲーション・ツリーでファームを選択します。

3. ナビゲーション・ツリー上のトポロジをクリックします。

4. トポロジ・ブラウザ・ウィンドウでファーム名をクリックし、「OK」をクリックします。

5. スケーリング・ツールを使用して、イメージを拡大または縮小します。

6. トポロジ内のインスタンスを開いて、それぞれの詳細を表示します。

7. 「オーバーレイ」オプションを使用して、インスタンスにステータス情報とメトリック情報を追加します。

8. 「検索」オプションを使用して特定の情報を検索します(表26-14)。

9. 必要に応じ、「印刷」または「保存」をクリックします。

第VII部

Oracle Access Manager 11gでの10g Webgateの使用

Oracle HTTP Server以外のWebサーバー・タイプがある企業では、10g WebgateをインストールしてOracle Access Manager 11gで使用できます。

第VII部の内容は次のとおりです。

- 第27章「OAM 11gによるOAM 10g Webgateの管理」

- 第28章「Apache、OHS、IHSの10g Webgate用の構成」

- 第29章「10g Webgate用のIIS Webサーバーの構成」

- 第30章「10g Webgate用のISAサーバーの構成」

- 第31章「10g Webgate用のLotus Domino Webサーバーの構成」

27 OAM 11gでのOAM 10g Webgateの管理

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』に、Oracle HTTP ServerへのOracle Access Manager 11gの初期デプロイメントについての説明が記載されています。ただし、Oracle HTTP Server以外のWebサーバー・タイプがある企業では、既存のOAM 10g Webgateを使用するか、新規にOAM 10g Webgateをインストールして、OAM 11gで使用できます。また、事前登録済のIAMSuiteAgentから、10g Webgateの使用に切り替えて、Oracle Identity Managementコンソールを保護することもできます。

次の項では、OAM 10g Webgateの新規インスタンスをインストールしてOAM 11gで使用する方法を説明します。

- 前提条件

- OAM 11g用のOAM 10gエージェントの紹介

- OAM 11gでの10g Webgateのプロビジョニング

- OAM 11g用の最新のOAM 10g Webgateの検索とインストール

- OAM 11gでの10g Webgateの集中ログアウトの構成

- IAMSuiteAgentのOAM 10g Webgateへの置換

- WebLogicコンテナへのアプリケーションのデプロイメント

- OAM 11gデプロイメントからの10g Webgateの削除

注意:
OSSO 10gをご使用のお客様: 既存のOracleデプロイメントで、エンタープライズ・ソリューションとしてOSSOを使用されている場合は、Oracle Fusion Middlewareがこれをソリューションとしてサポートし続けます。さらに、第9章で説明されているとおり、既存のOSSO 10g mod_ossoモジュールをOAM 11gのエージェントとしてプロビジョニングすることもできます。

前提条件

Oracle Technology Networkの最新の証明書マトリックスを確認して、ご自身のデプロイメント用の最新のWebgateを検索してください。

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

Oracle Access Managerコンソールが稼動していること、および次の項目を理解していることを確認してください。

- ポリシーの強制エージェントの概要

- この章のOAM 11g用のOAM 10gエージェントの紹介

OAM 11g用のOAM 10gエージェントの紹介

この項の内容は次のとおりです。

- IAMSuiteAgentのOAM 10g Webgateへの置換について

- レガシーOAM 10gデプロイメントとWebgateについて

- OAM 11gで使用する新規OAM 10g Webgateのインストールについて

IAMSuiteAgentのOAM 10g Webgateへの置換について

第9章で説明されているとおり、IAMSuiteAgentはOAM 11gに事前登録済のJavaエージェント・フィルタです。このエージェントはOracle Identity Managementコンソールと、アイデンティティ管理ドメイン内のリソースにSSO保護を提供します。

次の概要はIAMSuiteAgentをOAM 10g Webgateに移動し、Oracle Identity Managementコンソールや、「アイデンティティ管理」ドメイン内のリソースを保護する際に実行する必要があるタスクをまとめたものです。

次の概要に示す各タスクの詳細は、「IAMSuiteAgentのOAM 10g Webgateへの置換」に記載されています。

レガシーOAM 10gデプロイメントとWebgateについて

Oracle Access Manager 11gサーバーは、次を含むOAM 10g Webgateをサポートしています。

- 『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』に記載された、現在OAM 10gで稼動しているレガシー10g Webgate。

- (『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載された、OAM 10gでIAP WebLogicのコンテナベースのセキュリティを使用するアプリケーション用に)SSOのアイデンティティ・アサーション・プロバイダ(IAP)として構成されたレガシー10g Webgate。

- Oracle ADFセキュリティとOPSS SSOフレームワーク用にコードが記述されたWebアプリケーションと現在ともに動作しているレガシー10g Webgate。詳細は付録Cに記載されています。

Oracle Access Managerコンソールまたはリモート登録ツールを使用して、Oracle Access Manager 11g SSOを使用するように、これらのエージェントを登録できます。登録後は、OAM 10g Webgateはブリッジとして機能するJAVAベースのOAMプロキシを使用して、Oracle Access Manager 11gサービスと直接通信できます。

次の概要では、既存のOAM 10g WebgateをOAM 11gで使用するための設定に必要なタスクをまとめています。

タスクの概要: レガシー10g WebgateをOAM 11gで使用できるようにする設定

1. OAM 11gでの10g Webgateのプロビジョニング

2. OAM 11gでの10g Webgateの集中ログアウトの構成

3. オプション: WebLogicコンテナへのアプリケーションのデプロイメント

OAM 11gで使用する新規OAM 10g Webgateのインストールについて

この章で説明しているように、OAM 11gで使用する新規OAM 10g Webgateをインストールできます。OAM 10g Webgateは、いくつかのWebサーバー・プラットフォーム用に提供されています。

インストールおよび登録の後、OAM 10g Webgateはブリッジとして機能するJavaベースのOAMプロキシを通じてOracle Access Manager 11gサービスと直接通信します。

注意:
OAM 11g用に新規OAM 10g Webgateをインストールする場合、最新のWebgateを使用することをお薦めします。また、フェイルオーバーやロード・バランシング用に、複数のWebgateをインストールすることをお薦めしています。

OAM 11gデプロイメントへのOAM 10g Webgateのインストールと、OAM 10gデプロイメントへの10g Webgateのインストールにはいくつかの違いがあります。表27-1に違いをまとめます。

表27-1 OAM 10g Webgateのインストールの比較

OAM 11gデプロイメントへの10g Webgate

OAM 10gデプロイメントへの10g Webgate

1. パッケージ: OAM 10g Webgateのインストール用パッケージは、コア・コンポーネントとは別のメディアおよび仮想メディアにあります。

2. プロビジョニング: インストール前に、「OAM 11gでの10g Webgateのプロビジョニング」で説明されているとおり、OAM 11g用にWebgateのプロビジョニングを行います。

3. OAMサーバーとの関連付け: Webgateの登録中に実施します(タスク2)。

4. インストール: アプリケーションの前(またはFusion Middlewareの場合は、WebLogicサーバーの前)に10g Webgateをインストールします。

5. 言語パック: OAM 11gは10g Webgateの言語パックをサポートしています。

6. Webサーバー構成: OAM 11gで生成されたファイルを、Webgateのインストール・ディレクトリ・パスにコピーして、Webサーバーの構成を更新します。

7. 証明書のインストール: Webgateのインストール・ディレクトリ・パスにファイルをコピーします。

8. フォーム: 10g Webgateで提供されている10gフォームは、OAM 11gサーバーでは使用できません。
OAM 11gサーバーでの10g Webgateの使用方法や範囲は、リソースWebgate(認証用Webgateではなく、転送を行う側)と同様です。10g Webgateと11g OAMサーバーを使用する場合、10g Webgateは常に、認証Webgateのような働きをするOAM 11g資格証明コレクタにリダイレクトします。

9. シングル・ログアウト: 第15章「OAM 11gの集中ログアウトの構成」の情報を使用して構成します。

10. マルチドメイン・サポート: OAM 11gには適用されません。

1. パッケージ: OAM 10g Webgateのインストール用パッケージは、コア・コンポーネントとは別のメディアおよび仮想メディアにあります。

2. プロビジョニング: インストール前に、アクセス・システム・コンソールでWebgateインスタンスを作成します。

3. AAAとの関連付け: インストール前に、アクセス・システム・コンソールで、Webgateをアクセス・サーバーに関連付けます。

4. インストール: 10g Webgateパッケージを使用します。

5. 言語パック: Webgateのインストール中(または後で)10g Webgateの言語パックをインストールできます。

6. Webサーバーの構成: Webgateのインストール中に自動的に行われます(またはWebgateのインストール後に手動でも可能)。

7. 証明書のインストール: Webgateのインストール・ディレクトリ・パスにファイルをコピーしました。

8. フォーム: 10gデプロイメント用に提供されていました。

9. OAM 10gの集中ログアウト。

10. マルチドメイン・サポート: OAM 10g用に構成可能。

次の概要では、この章でOAM 11g用のOAM 10g Webgateのインストールおよび登録タスクについて詳細に説明したトピックを挙げています。OAM 11gを正しく操作するために、すべての手順を完了する必要があります。

タスクの概要: OAM 11g用の10g Webgateのプロビジョニングとインストール

1. OAM 11gでの10g Webgateのプロビジョニング

2. OAM 11gで使用する10g Webgateの検索とダウンロード

3. OAM 11gでの10g Webgateの集中ログアウトの構成

4. オプション: WebLogicコンテナへのアプリケーションのデプロイメント

OAM 11gでの10g Webgateのプロビジョニング

レガシーOAM 10g Webgateがある場合、またはOracle Access Manager 11gで使用する新規10g Webgateインスタンスをインストールする場合、OAM 11gの認証および認可サービスを使用するように、Webgateのプロビジョニングを行う必要があります。

Oracle Access Managerコンソールまたはリモート登録ツールを使用して、このタスクを実行できます。リモート登録ツールでは、テンプレートを使用して、登録前にすべてのWebgateパラメータを指定できます。

次の手順によって、リモート登録ツールを使用してインバンド・モードでのプロビジョニングのウォーク・スルーが行えます。この例では、OAMRequest_short.xmlをテンプレートとして使用してmy-10g-agent1という名前のエージェントを作成し、/.../*の保護と、パブリック・リソース、/public/index.htmlの宣言を行います。実際の値はこれとは異なります。完全な登録テンプレートを使用して、パブリック・リソース、プライベート・リソースおよび除外されたリソースを指定できます。

関連項目:

- 「IAMSuiteAgentのOAM 10g Webgateへの置換」(必要な場合)

- リモート登録ツール、処理、リクエスト・ファイルの詳細は、第10章を参照

- Oracle Access Managerコンソールを使用する場合は、第9章を参照

OAM 11g用の10g Webgateのプロビジョニング手順

1. リモート登録ツールを入手して、環境に合ったスクリプトを設定します。次に例を示します。

1. 次のパスにあるRREG.tar.gzファイルを探します。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. RREG.tar.gzファイルを別な場所に解凍します。例: rreg/bin/oamregなど。

3. oamregスクリプト(oamreg.batまたはoamreg.sh)に、状況(クライアント側またはサーバー側)と 表10-7の情報に応じた次の環境変数を設定します。
OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
JAVA_HOME = Java_location_on_the_computer

2. 登録リクエストを作成します。

1. OAMRequest_short.xmlを探して、新しいファイルにコピーします。次に例を示します。

$OAM_REG_HOME/input/OAMRequest_short.xml/

コピー元: OAMRequest_short.xml

コピー先: my-10g-agent1.xml

2. 環境の詳細情報を含むように、my-10g-agent1.xmlを編集します。次に例を示します。

<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-10g</hostIdentifier>
<agentName>my-10g-agent1</agentName>
<autoCreatePolicy>true</autoCreatePolicy>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
</OAMRegRequest>

関連項目:
「登録リクエストの作成」

3. エージェントのプロビジョニングを行います。次に例を示します。

1. リモート登録スクリプトを探します。
Linuxの場合: rreg/bin/oamreg.sh

Windowsの場合: rreg\bin\oamreg.bat

2. スクリプトが含まれているディレクトリから、インバンド・モードを使用してスクリプトを実行します。次に例を示します。
$ ./bin/oamreg.sh inband input/my-10g-agent1.xml

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: ...

3. プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。

Enter your agent username: userame
Username:  userame
Enter agent password: ********
Do you want to enter a Webgate password?(y/n)
n
iv.     Do you want to import an URIs file?(y/n)
n

4. 最後のメッセージを確認して、登録が成功したことを確かめます。

Inband registration process completed successfully! Output artifacts are
created in the output folder"

4. Oracle Access Managerコンソールにログインして、新規登録を確認します。

1. 「システム構成」タブの「Access Managerの設定」セクションで、次のノードを展開します。
SSOエージェント
OAMエージェント
10gエージェント

2. エージェント名をダブルクリックして、登録ページを表示し、詳細を確認します。
この登録用に新規Webgateをインストールする場合は、インストール中に次の詳細を入力する必要があります。次に例を示します。

エージェント名—Webgateのインストール中にWebgate IDとして入力します。

アクセス・クライアント・パスワード—Webgateのインストール中に、Webgateのパスワードとして入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。

アクセス・サーバー・ホスト名—このWebgateを登録するプライマリOAM 11gサーバーのDNSホスト名を入力します。

3. OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します。

5. プロビジョニングの結果として作成されるObaccessclient.xmlファイルはこの時点では無視してください。

6. アプリケーション・ドメインにリソースを追加します。

7. それぞれの環境で必要に応じて次に進んでください。

- Webgateの終了: OAM 11gでの10g Webgateの集中ログアウトの構成

- 新規Webgate: OAM 11g用の最新のOAM 10g Webgateの検索とインストール

- IAMSuiteAgentのOAM 10g Webgateへの置換

OAM 11g用の最新のOAM 10g Webgateの検索とインストール

OAM 11gで使用する新規OAM 10g Webgateをインストールする場合は、この項の手順を使用します。それ以外の場合は、この項はスキップして「OAM 11gでの10g Webgateの集中ログアウトの構成」に進みます。

タスクの概要: Webgateのインストール

1. OAM 11gで使用する新規10g Webgateのインストールの準備

2. OAM 11gで使用する10g Webgateの検索とダウンロード

3. Webgate 10gのインストールの開始

4. トランスポート・セキュリティ・モードの指定

5. Webgateの構成詳細の指定

6. セキュアな通信のための証明書のリクエストまたはインストール

7. Webgate Webサーバー構成の更新

8. Webgateのインストール終了

9. アーティファクトと証明書のインストール

10. Webgateのインストールの確認

OAM 11gで使用する新規10g Webgateのインストールの準備

表27-2にOAM 10g Webgateのインストール開始前に必要な要件を示します。

表27-2 OAM 11gで使用する新しい10g Webgateのインストールの準備

情報

説明

サポートされている最新のWebgate

OAM 11gでは、サポートされている最新の10g (10.1.4.3) Webgateを必ず使用してください。ただし、該当する10g (10.1.4.3) Webgateが提供されていない場合は、その次に新しいWebgate(10g (10.1.4.2.0)を使用してください。

関連項目: 「OAM 11gで使用する10g Webgateの検索とダウンロード」

インストール場所

次の場所を検討してください。

- アプリケーション・サーバーの前にWebgate。

- WebLogicサーバー・コンテナで管理されたセキュリティを使用するアプリケーション: アプリケーションをデプロイするWebLogicアプリケーション・サーバーの前

ユーザー・アカウント

Webgateのインストールに使用するアカウントは、Webgateを実行するアカウントとは異なります。

- 10g Webgateは、Webサーバーと同じユーザーおよびグループを使用してインストールする必要があります。

- Unix: rootとしてログインしてWebgateをインストールできます。Webサーバー・プロセスをroot以外のユーザーとして実行している場合は、root以外のユーザーを使用してWebgateをインストールできます。

rootレベルとサイト・レベル

- Webgateはrootレベルまたはサイト・レベルでインストールできます。

- 複数の仮想サイトにWebgateをインストールしても、Webgateのインスタンスは1つのみです。

トランスポート・セキュリティ・モード

インストールするエージェントと同じモードを使用するように、1つ以上のOAMサーバーを構成していることを確認します。

付録Eも参照してください

コンピュータ・レベルと仮想Webサーバー・レベル

Webgateは、コンピュータ・レベルまたは仮想Webサーバー・レベルで実行するように構成できます。コンピュータ・レベルと仮想Webサーバー・レベルの両方にインストールしないでください。

Oracle HTTP Server Webサーバー:

Oracle HTTP Server用の10g Webgateは、オープン・ソースApacheに基づいています。Webgateパッケージ名には次が含まれています。

- OHS (Apache v1.3に基づく)

- OHS2 (Apache v2に基づく)

- OHS11g (Apache v2.2に基づき、この章の対象外)

Apache Webサーバー

Oracle Access Manager 11gは、SSLが有効または無効なApacheをサポートするコンポーネント用に単一パッケージを提供しています。

- APACHE2_Webgateは、SSLが有効または無効なv2(およびリバース・プロキシが有効または無効なSolarisおよびLinux)をサポートしています。第28章も参照してください。

- APACHE22_Webgateは、SSLが有効または無効なv2.2(およびリバース・プロキシが有効または無効なSolarisおよびLinux)をサポートしています。第28章も参照してください。

注意: SSL対応の通信用に、Oracle Access ManagerはApache-SSLではなく、mod_sslのApacheのみをサポートしています。mod_sslはApache-SSLから派生した、代替品です。

IBM HTTP Server (IHS) v2 Webサーバー:

IHS2_WebgateはIBM-AIX上でApache v2により稼動しています。Oracle Access Managerは、SSLが有効または無効なIHS v2およびIHS v2リバース・プロキシ・サーバーをサポートしています。

詳細は、第28章を参照してください。

Domino Webサーバー:

OAM 10g WebgateをDomino Webサーバーにインストールする前に、Domino Enterprise Server R5を正しくインストールし、設定しておく必要があります。

関連項目: 第31章「10g Webgate用のLotus Domino Webサーバーの構成」。

IIS Webサーバー

Webgateのインストール前に、IIS Webサーバーがロック・ダウン・モードになっていないことを確認します。これを行わなかった場合、サーバーが再起動され、メタベースが再度初期化され、IISがロック・ダウン後に発生したアクティビティを無視するまで、問題なく稼動しているように見えます。

クライアント証明書認証を使用している場合は、Webgateに対してクライアント証明書を有効にする前に、WebgateをホストするIIS WebサーバーでSSLを有効にする必要があります。

NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータで、簡易または証明書モードでISAPI Webgateをインストールすると仮定します。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。

各IIS仮想Webサーバーには、独自のWebgate.dllファイルを仮想レベルでインストールするか、全サイトに影響を与える1つのWebgateをサイト・レベルでインストールできます。Webgate.dllをサイト・レベルでインストールしてすべての仮想ホストを制御するか、Webgate.dllを1つまたはすべての仮想ホストに対してインストールします。

コンピュータ・レベルでpostgate.dllファイルをインストールする必要もあります。postgate.dllは、「ポステージISAPIフィルタのインストール」で説明しているように、\Webgate_install_dir内にあります。複数インストールすると、このファイルの複数のバージョンが作成され、Oracle Access Managerの動作が異常になることがあります。この場合は、webgate.dllとpostgate.dllが1つずつ存在していることを検証する必要があります。

関連項目: 第29章「10g Webgate用のIIS Webサーバーの構成」

削除: Webgateおよび関連するファイルをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。メタベースを編集するためのツールとして、MetaEditも提供されています。MetaEditはRegeditに似ており、一貫性チェッカーとブラウザ/エディタが含まれています。WebgateをIISから完全に削除するには、MetaEditを使用してメタベースを編集します。

ISAプロキシ・サーバー

ISAプロキシ・サーバー上では、すべてのISAPIフィルタをISAインストール・ディレクトリ内にインストールする必要があります。ISAインストール・ディレクトリ構造内の任意の場所でかまいません。

1. ISAプロキシ・サーバーにWebgateをインストールする前に、次を行います。
次で、一般的なISAPIフィルタをISAの指示と照合します。

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isa/isaisapi_5cq8.asp

内外の通信レイヤーが正しく構成されており、機能していることを確認します。

2. インストール中に、それがISAインストールなのかどうか尋ねられます。次を必ず行います。
尋ねられたら、これがISAプロキシ・サーバーのインストールであることを示します。

Webgateインストール・パスとして、ISAインストール・ディレクトリを指定します。

自動Webサーバー更新機能を使用して、Webgateのインストール中にISAプロキシ・サーバーを更新します。

3. Webgateのインストール後、複数のスクリプトやプロセスをコールしてプログラミング上追加が必要なISAサーバー・フィルタを構成するための、configureISA4webgate.batを検索します。

関連項目: 第30章「10g Webgate用のISAサーバーの構成」

OAM 11gで使用する10g Webgateの検索とダウンロード

必要に応じて、次の手順を使用してOAM 10g Webgateを取得します。ご使用のWebサーバーに適したインストール・パッケージを選択してください。

OAM 10g Webgateを検索およびダウンロードする手順

1. 次のOracle Technology Networkで、最新のOracle Access Manager 10g証明書を確認します。

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

2. 次のOracle Fusion Middleware 11gR1ソフトウェア・ダウンロードに移動します。

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

3. ページの最も上のライセンス契約に同意をクリックします。

4. Access Manager Webgates (10.1.4.3.0)の行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。

5. インストールする10gアクセス・システムの言語パックに、Webgateインストーラを格納します。

6. 「Webgate 10gのインストールの開始」に進みます。

Webgate 10gのインストールの開始

次の手順によって、Webサーバー・タイプに関係なく共通のウォーク・スルーを行います。

インストール・オプションを識別し、自分の環境に合わない場合はスキップできます。Webgateのインストール中は、特定の時点で情報が保存されます。Webgateのインストール処理は必要に応じて取り消すことができます。ただし、Webgateのインストールを知らせるメッセージを受領後にWebgateのインストールを取り消す場合は、コンポーネントのアンインストールが必要です。

注意:
HP-UXおよびAIXシステムでは、-is:tempdirパス・パラメータを使用して、十分な領域があるディレクトリにインストールを指示できます。パスは、十分な領域があるファイル・システムへの絶対パスでなければなりません。

Webgate 10gのインストールの開始手順

1. Webgate 10gをホスティングするコンピュータ上で、Webサーバーの管理者権限のあるユーザーとしてログインします。

2. Webサーバー・インスタンスを停止します。

3. 該当するプラットフォーム、インストール・モード、Webサーバー用のWebgateインストーラを起動します。次に例を示します。
GUIメソッド

Windows— Oracle_Access_Manager10_1_4_3_0_Win32_API_Webgate.exe

コンソール・メソッド

Solaris—./ Oracle_Access_Manager10_1_4_3_0_sparc-s2_API_Webgate

Linux—./ Oracle_Access_Manager10_1_4_3_0_linux_API_Webgate

ここでAPIはWebサーバーで使用するAPI(IIS Webサーバーの場合はISAPIなど)を示します。

4. 次へをクリックして、ようこそ画面を閉じます。

5. 尋ねられたら、管理者の権限を使用して回答します。

6. Webgateのインストール・ディレクトリを指定します。次に例を示します。
\OracleAccessManager\WebComponent\

7. LinuxまたはSolaris: このコンピュータ上のGCCランタイム・ライブラリの場所を指定します。

8. 言語パック—デフォルトのロケールとインストールするその他のロケールを選択して、次へをクリックします。

9. プレゼンテーション・ワークシートにインストール・ディレクトリをまだ記録していない場合は記録し、次へをクリックして続行します。
Webgateのインストールが開始し、数秒間かかることがあります。Windowsシステムでは、Microsoft管理インタフェースの構成を知らせる画面が表示されます。

インストール・プロセスはまだ完了していません。トランスポート・セキュリティ・モードの指定を求められます。この時点では、情報のリストアに戻れません。

10. 必要に応じて、ダウンロード済のGCCライブラリを解凍した場所を指定します。

トランスポート・セキュリティ・モードの指定

少なくとも1つのOAM Server間のトランスポート・セキュリティは一致する必要があります。

関連項目:
付録E

トランスポート・セキュリティ・モードの指定手順

1. Webgate用に、「オープン」、「簡易」または「証明書」を選択します。

2. 次へをクリックします。
ここでWebgate構成の指定を求められます。

3. 指定したトランスポート・セキュリティ・モードに従って進みます。

- 簡易または証明書モード—「セキュアな通信のための証明書のリクエストまたはインストール」に進みます。

- オープン・モード—「Webgate Webサーバー構成の更新」までスキップします。

セキュアな通信のための証明書のリクエストまたはインストール

OAM 11g環境でオープン・モード・トランスポート・セキュリティを使用する場合は、「Webgate Webサーバー構成の更新」までスキップできます。

Webgate証明リクエスト: OAM 11gサーバーに信頼されているルートCAに送信する必要があるリクエスト・ファイル(aaa_req.pem)を生成します。ルートCAは、Webgate用にインストール可能な署名付きの証明書を返します。

リクエストした証明書を\Webgate_install_dir\access\oblix\configディレクトリにコピーし、Webgate Webサーバーを再起動する必要があります。

関連項目:
付録E

Webgate 10g用の証明書をリクエストまたはインストールする手順

1. 証明書をリクエストするのか、インストールするのかを指定し、次へをクリックして続行します。次に例を示します。

- 証明書をリクエストする場合は、手順2に進みます。

- 証明書をインストールする場合は、手順3に進みます。

2. 証明書をリクエストします。

- リクエストされた情報を入力し、次に次へをクリックして、証明書のリクエストをCAに発行します。

- 証明書のファイルの場所が表示された場合は、それを記録します。

- 証明書がある場合ははいをクリックして、手順3から続行します。それ以外の場合は、「Webgate Webサーバー構成の更新」までスキップします。

3. インストール中に証明書をインストールする場合: 次のファイルへの絶対パスを指定して、次へをクリックします。
Webgate_install_dir\access\oblix\config

- cacert.pemはOracleが提供したopenSSL認証局の署名を受けた証明書リクエストです。

- password.xmlには、インストール中に指定されたランダムなグローバル・パスフレーズが不明瞭化された形式で含まれています。これを使用して、他の顧客が同一CAを使用しないようにします。Oracle Access Managerは、OAM AgentとOAM Server間の初期ハンドシェイク中に追加のパスワード・チェックを行います。

- aaa_key.pemには秘密鍵(openSSLによって生成)が含まれています。

- aaa_cert.pemはPEM形式の署名済証明書です。

- 「Webgate Webサーバー構成の更新」に進みます。

Webgateの構成詳細の指定

OAM 11gでのWebgateのプロビジョニングと登録の間に指定した情報を使用して次のタスクを実行します。

Webgateの構成詳細の指定手順

1. アクセス・システム・コンソールで指定した、Webgateに必要な情報を提供します。

- Webgate ID—登録中に指定したエージェント名を入力します。

- Webgateパスワード—登録中にパスワードを指定した場合は、それを入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。

- アクセス・サーバーID—必要な場合は、このWebgateを登録したOAM 11gサーバーを入力するか、選択した任意の名前を使用します。

- アクセス・サーバー・ホスト名—このWebgateを登録するOAM 11gサーバーのDNSホスト名を入力します。

- ポート番号—OAM Proxyプロキシが実行中のポートを入力します。プロビジョニング中にポートを入力しなかった場合のデフォルト・ポートは3004です。

2. 次へをクリックして続行します。

Webgate Webサーバー構成の更新

WebサーバーがWebgateと連動するように構成する必要があります。Oracleはインストール中にWebサーバー構成を自動的に構成することをお薦めします。ただし、自動および手動の両方の更新手順が含まれています。

注意:
Webサーバーの手動構成手順

1. 自動更新に進むかどうかを尋ねられたらいいえをクリックし、次に次へをクリックします。

2. Webgate Webサーバーの手動設定をサポートするために表示される画面を確認し、「Webサーバーの手動構成」を参照します。

3. Webgateインストール画面に戻り、「次へ」をクリックして、「OAM 11gでの10g Webgateのプロビジョニング」に進みます。

Webサーバーの自動構成手順

1. はいをクリックしてWebサーバーの自動更新を行い、次へをクリックします(またはいいえをクリックして「Webサーバーの手動構成」を参照します)。

- ほとんどのWebサーバー—Webサーバー構成ファイルを含むディレクトリの絶対パスを指定します。

- IIS Webサーバー—プロセスがすぐに開始し、1分以内に終了します。詳細は、第29章「10g Webgate用のIIS Webサーバーの構成」を参照してください。
続行する前に特殊な指示がある場合があります。NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。

- Sun Webサーバー—続行する前に、必ずWebサーバー管理コンソールで変更を適用しておいてください。

Webサーバーの構成が更新されたことを知らせる画面が表示されます。

2. 「次へ」をクリックして「Webgateのインストール終了」に進みます。

Webサーバーの手動構成

Webgateのインストール中にWebサーバーの自動更新を取り消した場合は、手動でタスクを実行する必要があります。

注意:
Webgateのインストール中に手動構成プロセスを起動した場合は、次のステップ1をスキップできます。

WebサーバーのWebgateを手動で構成する手順

1. Webブラウザを起動し、必要に応じて次のファイルを開きます。次に例を示します。
\Webgate_install_dir\access\oblix\lang\langTag\docs\config.htm

ここで、\Webgate_install_dirはWebgateがインストールされているディレクトリです。

注意:
64ビットのWebgateインストール中にIISの手動構成を選択した場合は、次のパスで詳細を入手できます。
Webgate_install_dir\access\oblix\lang\en-us\docs\dotnet_isapi.htm

2. サポートされているWebサーバーから選択し、各Webサーバー・タイプに固有のすべての指示に従います。

- Webgateの設定中に修正が必要なファイルのバックアップ・コピーを作成し、やり直しが必要になる場合に備えます。

- Webサーバーが該当するOracle Access Managerファイルを認識できるように、元の設定指示に戻って、すべての指示内容を完了したことを確認します。

注意:
間違ってウィンドウを閉じてしまった場合は、手順1に戻って、該当するリンクを再度クリックします。一部の設定では新しいブラウザ・ウィンドウが開いたり、コマンドウィンドウへの入力が求められることがあります。

3. 「Webgateのインストール終了」に進みます。

Webgateのインストール終了

ReadMe情報に、マニュアルとOracleに関する詳細が記載されています。

注意:
64ビットのIIS Webgateをインストールする場合は、第29章「64ビットWebgateインストールの終了」を参照してください。

Webgateのインストールを終了する手順

1. ReadMeの情報を確認し、次に次へをクリックして閉じます。

2. 終了をクリックして、インストールを終了します。

3. Webサーバーを再起動して構成の更新を反映します。

- IIS Webサーバー: Webgateのインストール後に、net stop iisadminおよびnet start w3svcを使用してメタベースが破損していないことを確認します。

- Security-Enhanced Linux: このプラットフォームにインストールしたばかりのWebgateに対して、chconコマンドを実行します。

4. 必要に応じて次のトピックに進み、次に「アーティファクトと証明書のインストール」に戻ります。

- ネイティブPOSIXスレッド・ライブラリ: NPTLを使用する場合は、Oracle Access ManagerのWebコンポーネントのインストール時に、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。

- Apache2、OHS2、IHS2 Webサーバー: 第28章「Apache、OHS、IHSの10g Webgate用の構成」

- IIS Webサーバー: Webgateのインストール後に、net stop iisadminおよびnet start w3svcを使用してメタベースが破損していないことを確認します。第29章「10g Webgate用のIIS Webサーバーの構成」も参照してください。

- ISA Webサーバー: 第30章「10g Webgate用のISAサーバーの構成」

- Lotus Domino Webサーバー: 第31章「10g Webgate用のLotus Domino Webサーバーの構成」

アーティファクトと証明書のインストール

ObAccessClient.xmlファイルはプロビジョニングで生成されるものの1つです。Webgateのインストール後、このファイルをWebgateインストール・ディレクトリ・パスにコピーする必要があります。Webgateのインストール後に署名済のWebgate 10g証明書を受領した場合、次の手順に従ってインストールできます。

Webgate 10g用のアーティファクト(および証明書)をインストールする手順

1. Webgate 10gのプロビジョニング・アーティファクト(および必要に応じて証明書ファイル)を入手します。次に例を示します。

- ObAccessClient.xml

- password.xml(必要に応じて)

- aaa_key.pem(openSSLによって生成された秘密鍵)。

- aaa_cert.pem(PEM形式の署名済証明書)

2. Webgateホストにファイルをコピー: Webgate_install_dir\access\oblix\config

3. Webgate Webサーバーを再起動します。

Webgateのインストールの確認

WebgateのインストールとWebサーバーの更新後、Webgateの診断を有効にしてWebgateが正しく実行されていることを確認できます。

Webgateの診断確認手順

1. OAM 11gコンポーネントが稼動していること確認します。

2. Webgate診断用に次のURLを指定します。次に例を示します。
ほとんどのWebサーバー—http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1

IIS Webサーバー—http(s)://hostname:port/access/oblix/apps/ webgate/bin/webgate.dll?progid=1

ここで、hostnameはWebgateをホストするコンピュータ名、portはWebサーバー・インスタンスのポート番号です。

3. Webgateの診断ページが表示されます。

- 成功した場合: Webgateの診断ページが表示される場合、Webgateが正常に機能しています。ページを閉じてください。「OAM 11gでの10g Webgateの集中ログアウトの構成」に進みます。

注意:
IAMSuiteAgentをこのWebgateに入れ替える場合は、「WebLogicサーバー・プラグインの更新」に進みます。

- 失敗した場合: 「OAM 11gデプロイメントからの10g Webgateの削除」で説明されているとおり、Webgateをアンインストールして再インストールする必要があります。

OAM 11gでの10g Webgateの集中ログアウトの構成

OAM 10gエージェントは、単一のDNSドメインでのログアウトのサポートを内蔵しています。複数のDNSドメインでのログアウトをサポートするためには、10gエージェントのカスタマイズが必要が必要です。

OAM 11gでは、セッション管理はOAMサーバーで集中的に行われており、異なるDNSドメインのログアウトは標準的にサポートされています。OAM 11g:

- エージェントのObSSOCookieをクリアします

- サーバー内のセッションをクリアします

OAM 11gサーバーおよびOAM 10g Webgateでは、アプリケーションは次のことを行う/oamsso/logout.htmlを常に起動する必要があります。

- ObSSOCookieをログアウト済に設定(Webgate上でのログアウトの起動により)すること、およびend_urlを構成し(URLとして)、サーバー・ログアウトURL(/oam/server/logout)にリダイレクトすること。

ログアウトの詳細は、「OAM 11gでの10g Webgateの集中ログアウトの構成」を参照してください。

IAMSuiteAgentのOAM 10g Webgateへの置換

Oracle Access ManagerおよびOracle Identity Managerは、Oracle Fusion Middleware 11gコンポーネントの一部です。WebLogicサーバー構成ウィザードの初期構成中に、IAMSuiteAgentがIDMドメイン・ホスト識別子およびそのエージェントに指定されたアプリケーション・ドメインとともにOAM 11gに登録されます。

Oracle Fusion MiddlewareはIAMSuiteAgentを使用して、保護されたOracle Identity ManagementコンソールにOAM 11gをそのまま使用します。

コンテナ外のアプリケーションを保護するため、IAMSuiteAgentを10g Webgateに入れ替えることができます(事前登録済のIAMSuiteAgentと同じアプリケーション・ドメインとポリシーを使用して、同じアプリケーション・セットを保護)。

タスクの概要: IAMSuiteAgentのOAM 10g Webgateへの置換

1. IAMSuiteAgentを10g Webgateに入れ替えるためのプロビジョニング

2. IAMSuiteAgentを置換する10g Webgateのインストール

3. WebLogicサーバー・プラグインの更新

4. オプション: OAM/OIM統合用のAutoLoginホスト識別子の確認

5. オプション: WebLogic用のOAMセキュリティ・プロバイダの構成

6. オプション: IAMSuiteAgentの無効化

7. 検証

IAMSuiteAgentを10g Webgateに入れ替えるためのプロビジョニング

プロビジョニングとは、Oracle Access ManagerコンソールにWebgateの登録を作成するプロセスです。次の手順によって、リモート登録ツールを使用してインバンド・モードでのプロビジョニングのウォーク・スルーが行えます。

関連項目:

- リモート登録ツール、処理、リクエスト・ファイルの詳細は、第10章を参照

- Oracle Access Managerコンソールを使用する場合は、第9章を参照

この例では、OAMRequest_short.xmlをテンプレートとして使用して10g4IDMという名前のエージェントを作成し、/.../*の保護と、パブリック・リソース、/public/index.htmlの宣言を行います。実際の値はこれとは異なります。

注意:
入替え用のWebgateでIAM Suiteポリシーを使用するには、IAMSuiteAgentホスト識別子と優先ホストを使用するようにWebgateの登録が構成されていることを確認します。

既存のIAM Suiteポリシーを再利用するために、OAMReqRequest.xml内でIAMSuiteAgentをWebgate登録用のホスト識別子として指定し、IAMSuiteAgentをHostIdentifierとpreferredHostとして設定できます。または、Oracle Access Managerコンソールを使用してエージェントの登録を編集できます。

IAMSuiteAgentを10g Webgateに入れ替えるためのプロビジョニング手順

1. リモート登録ツールを入手して、環境に合ったスクリプトを設定します。次に例を示します。

1. 次のパスにあるRREG.tar.gzファイルを探します。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. RREG.tar.gzファイルを別な場所に解凍します。例: rreg/bin/oamregなど。

3. oamregスクリプトに、状況(クライアント側またはサーバー側)と 表10-7の情報に応じた次の環境変数を設定します。
OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
JAVA_HOME = Java_location_on_the_computer

2. 登録リクエストを作成し、autoCreatePolicyパラメータがFalseに設定されていることを確認します。

1. OAMRequest_short.xmlを探して、新しいファイルにコピーします。次に例を示します。

WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/

コピー元: OAMRequest.xml

コピー先: 10g4IAM.xml

2. 環境の詳細を含むように、10g4IAM.xmlを編集します。たとえば、IAMSuiteAgentから10g Webgateエージェントに変更する場合は、次のようなリクエストになります。

<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>10g4IAM</hostIdentifier>
<agentName>10g4IAM</agentName>
<autoCreatePolicy>false</autoCreatePolicy>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
...retain defaults for remaining elements...
...
...
</OAMRegRequest>

関連項目:
「登録リクエストの作成」

3. エージェントのプロビジョニングを行います。次に例を示します。

1. リモート登録スクリプトを探します。
Linuxの場合: rreg/bin/oamreg.sh

Windowsの場合: rreg\bin\oamreg.bat

2. スクリプトが含まれているディレクトリから、インバンド・モードを使用してスクリプトを実行します。次に例を示します。
$ ./bin/oamreg.sh inband input/10g4IAM.xml

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: ...

3. プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。

Enter your agent username: userame
Username:  userame
Enter agent password: ********
Do you want to enter a Webgate password?(y/n)
n
iv.     Do you want to import an URIs file?(y/n)
n

4. 最後のメッセージを確認して、登録が成功したことを確かめます。

Inband registration process completed successfully! Output artifacts are
created in the output folder"

4. Oracle Access Managerコンソールにログインして、新規登録を確認します。

1. 「システム構成」タブの「Access Managerの設定」セクションで、次のノードを展開します。
SSOエージェント
OAMエージェント
10gエージェント

2. エージェント名をダブルクリックして、登録ページを表示し、詳細を確認します(新規Webgateをインストールする場合は、インストール中に次の詳細を入力する必要があります)。次に例を示します。
エージェント名—Webgateのインストール中にWebgate IDとして入力します。

アクセス・クライアント・パスワード—Webgateのインストール中に、Webgateのパスワードとして入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。

アクセス・サーバー・ホスト名—このWebgateを登録するプライマリOAMサーバーのDNSホスト名を入力します。

3. OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します。

5. プロビジョニングの結果作成されるObAccessClient.xmlファイルは無視してください。

6. 「WebLogicサーバー・プラグインの更新」に進みます。

IAMSuiteAgentを置換する10g Webgateのインストール

プロビジョニング後、IAMSuiteAgentと入れ替えるために10g Webgateをインストールする必要があります。インストール中は、プロビジョニング時と同じWebgateの情報を提供する必要があります。

前提条件

IAMSuiteAgentを10g Webgateに入れ替えるためのプロビジョニング

タスクの概要: Webgateのインストール

1. OAM 11g用の最新のOAM 10g Webgateの検索とインストール

2. IAMSuiteAgentの入替え: 「WebLogicサーバー・プラグインの更新」に進みます。

WebLogicサーバー・プラグインの更新

10g Webgateのプロビジョニングとインストールを行い、IAMSuiteAgentと入れ替えたら、mod_wl_ohs.confファイルに特定の入力をして、Webgate WebサーバーがWebLogicサーバー上のアプリケーションにリクエストを転送するように指示する必要があります。

注意:
WebLogicサーバーのApache用プラグインの汎用名はmod_weblogicです。Oracle HTTP Server 11gの場合は、このプラグインの名前はmod_wl_ohsです(実際のバイナリ名はmod_wl_ohs.soです)。例では実装のための正確な構文を示します。

例27-1は入力サンプルを使用して変更が必要な部分を示します。使用する環境によって入力内容は異なります。

例27-1 mod_wl_ohs.confでの10g Webgate用の更新

<IfModule weblogic_module>
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost hostname.us.sample.com
WebLogicPort    6162
</Location>
<Location apmmconsole>
SetHandler weblogic-handler
WebLogicHost hostname.us.sample.com
WebLogicPort    6162
</Location>
...

</IfModule>

注意:
WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、類似の場所エントリが必要です。

前提条件

IAMSuiteAgentを置換する10g Webgateのインストール

環境に合ったmod WebLogic構成の更新手順

1. 次のパスにあるmod_wl_ohs.confファイルを探します。

<OHS-INSTANCE_HOME>/config/OHS/<INSTANCE_NAME>/mod_wl_ohs.conf

2. WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、Locationエレメントを含むようにファイルを編集します(例27-1を参照)。

3. ファイルを保存します。

4. Webサーバーを再起動します。

5. 必要に応じて次のタスクに進みます。

- OAM/OIM統合用のAutoLoginホスト識別子の確認

- WebLogic用のOAMセキュリティ・プロバイダの構成

OAM/OIM統合用のAutoLoginホスト識別子の確認

このトピックではOracle Access ManagerがOIMと統合されている場合に、Oracle Identity Manager(OIM)の自動ログイン機能を確認(または構成)する方法を説明します。

注意:
Oracle Access Manager 11gをOracle Identity Managerに統合していない場合、この手順は省略します。11g。

Oracle Identity ManagerがOAM 11gに統合されている場合、AutoLogin機能では、IAMSuiteAgentのホスト識別子リスト内に10g Webgate Webサーバーのホスト名とポートが含まれている必要があります。

注意:
10g Webgate Webサーバーの前にロード・バランサがある場合、ステップ3でロード・バランサのホスト名とポートを含む必要があります。

agentBaseUrlパラメータを使用して特定のホスト識別子を更新します。ただし、自動ポリシーの作成がFalseに設定されている場合、リモート登録ユーティリティはアプリケーション・ドメインを作成せず、agentBaseUrlパラメータを参照しません。

次の手順では、Oracle Access Manager/Oracle Identity Manager統合のためにAutoLoginホスト識別子を確認(または構成)する方法を示します。実際の値は異なります。

前提条件

WebLogicサーバー・プラグインの更新

OAM/OIM統合用のAutoLoginホスト識別子の構成手順

1. 「ポリシー構成」タブのナビゲーション・ツリーから、「共有コンポーネント」と「ホスト識別子」ノードを必要に応じて展開し、「IAMSuiteAgent」を選択します。
共有コンポーネント
ホスト識別子
IAMSuiteAgent

2. 操作パネルで、このホスト識別子のすべてのホスト名とポートの組み合わせがリストされていることを確認します。

3. 「操作」パネルで、10g Webgateが構成されている(または構成が予定されている)Webサーバーのホストとポートがリストされていることを確認します。ない場合は、エントリを追加します。

1. 操作パネルの+ボタンをクリックします。

2. ホスト名: 「操作」パネルの「ホスト名」列に、10g Webgate Webサーバーのホスト名を入力します。

3. ポート: 「操作」パネルの「ポート」列に、10g Webgate Webサーバーのポート番号を入力します。

4. ロード・バランサ: 10g Webgate Webサーバーの前にロード・バランサがある場合、「操作」パネルにロード・バランサのホスト名とポートを追加します。

5. ホスト識別子ページの適用をクリックします。

4. 「WebLogic用のOAMセキュリティ・プロバイダの構成」に進みます。

WebLogic用のOAMセキュリティ・プロバイダの構成

この項では、OAM 11gと10g Webgateを使用してシングル・サイン・オンが行えるように、WebLogicセキュリティ・プロバイダを構成する方法を説明します。

注意:
Oracle Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。

OAM 10g Webgate用のセキュリティ・プロバイダの設定の詳細は、次のトピックを参照してください。

- セキュリティ・プロバイダについて

- 10g Webgate用のセキュリティ・プロバイダの設定

セキュリティ・プロバイダについて

IAMSuiteAgentを10g Webgateに入れ替える場合に、Oracle Access Manager 11g SSOの構成を完了するには、WebLogicサーバー・ドメイン内で次のセキュリティ・プロバイダを構成する必要があります。

- OAM Identity Asserter: トークンベースの認証を使用し、OAM SSOヘッダーとトークンをアサートします。

- OID (またはOVD) Authenticator: サブジェクトを作成し、正しいプリンシパルを移入します。
ユーザーが保存されているストアに応じて、Oracle Internet Directory AuthenticatorまたはOracle Virtual Directory Authenticatorのいずれかをプライマリ資格証明オーセンティケータとして構成します。

- デフォルト・オーセンティケータ: このデフォルトWebLogic認証プロバイダによって、ユーザーとグループを、組み込まれたWebLogicサーバーLDAPサーバーという1つの場所で管理できます。Oracle WebLogicサーバーはこのオーセンティケータを使用して、管理ユーザーのログインを行います。

複数の認証プロバイダを構成する場合、各プロバイダにJAAS制御フラグを使用して、ログイン順序での認証プロバイダの使用方法を制御します。たとえば次のJAAS制御フラグ設定を使用できます。

- REQUIRED—認証プロバイダは常に呼び出され、ユーザーは必ずその認証テストに合格する必要があります。認証の成否にかかわらず、プロバイダ・リストの残りの認証が続行されます。OAM Identity Asserterが必要です。

- SUFFICIENT—ユーザーは認証プロバイダの認証テストに合格する必要はありません。認証に合格した場合は、以降の認証プロバイダは実行されません。認証が失敗下場合は、プロバイダ・リストの残りの認証が続行されます。Oracle Internet Directory (またはOracle仮想ディレクトリ)およびデフォルト・オーセンティケータの両方がSUFFICIENTです。

- OPTIONAL—追加の認証プロバイダが既存のセキュリティ・レルムに加わると、デフォルト設定で制御フラグがOPTIONALに設定されます。各認証プロバイダが認証順序で正しく機能するように、制御フラグの設定とプロバイダの順序を変更することが必要な場合があります。
ユーザーは認証プロバイダの認証テストを合格しても、不合格になってもかまいません。ただし、JAAS制御フラグがOPTIONALに設定されたセキュリティ・レルムですべての認証プロバイダが構成されている場合は、ユーザーは構成されたいずれかのプロバイダの認証テストに合格する必要があります。

関連項目:
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項に、すべての認証プロバイダのリストと、ユーザーおよびグループ属性のLDAPスキーマに見合ったOracle Internet Directoryプロバイダの構成詳細が記載されています。

Oracle Access Manager JARは、Oracle Fusion Middleware製品(Oracle Identity Management、Oracle SOA Suite、またはOracle WebCenter)のインストール時に使用可能な認証プロバイダのWARファイルです。Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っています。

- oamAuthnProvider.jar: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのファイルとOracle WebLogic Server 10.3.1以降の認証プロバイダのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web(非HTTP)リソースに対するリクエストを処理するために、カスタムのOracle Access Managerアクセス・ゲートも用意されています。

- oamauthenticationprovider.war: Oracle WebLogicサーバー・コンソールに表示されるプロバイダ・リストを、Oracle Access Managerで使用する必要があるもののみに限定します。
拡張をデプロイする際に、管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更管理プロセスに関与します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server管理コンソールの拡張』を参照してください。

10g Webgate用のセキュリティ・プロバイダの設定

次の手順にはWebLogicサーバー管理コンソールが必要です。この例では、Oracle Internet DirectoryプロバイダをOAM Identity Asserterおよびデフォルト・オーセンティケータで設定する方法を示します。OVDの場合も必要な手順は同じです。

注意:
Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っているので、次の手順1をスキップできます。ただしFusion Middlewareアプリケーションがない場合は、スタンドアロンOracle WebLogicサーバーなので、手順1で説明したようにOracle Technology NetworkからJARおよびWARファイルを入手する必要があります。

前提条件

WebLogicサーバー・プラグインの更新

OAM 11gでのOAM 10g WebgateのためにWebLogicサーバー・ドメインにプロバイダを設定する手順

1. Oracle Fusion Middlewareアプリケーションなし: Obtain the Oracle Access Managerプロバイダを入手します。

1. 次のOracle Technology Networkにログインします。

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webgates (10.1.4.3.0)で、oamAuthnProvider ZIPファイルを検索します。

oamAuthnProvider<version number>.zip

3. oamAuthnProvider.jarを、Oracle WebLogicサーバーをホスティングしているコンピュータの次のパスに解凍し、コピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle Fusion Middlewareアプリケーションがインストールされている場合:

1. 次のパスでoamauthenticationprovider.warを探します。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
der.war

2. 次の場所にoamauthenticationprovider.warをコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

3. WebLogicサーバー管理コンソールにログインして、セキュリティ・レルム、デフォルト・レルム名をクリックし、プロバイダをクリックします。

4. OAM Identity Asserter: 次の手順を実行してこのプロバイダを追加します。

1. 認証をクリックして新規をクリックし、次に名前を入力して、タイプを選択します。
名前: OAM ID Asserter

タイプ: OAMIdentityAsserter

OK

2. 認証プロバイダテーブル内で、新しく追加されたオーセンティケータをクリックします。

3. 共通タブで、制御フラグをREQUIREDに設定して、保存をクリックします。

5. OIDオーセンティケータ: 次の手順を実行してこのプロバイダを追加します。

1. セキュリティ・レルム、デフォルト・レルム名をクリックし、プロバイダをクリックします。

2. 新規をクリックし、次に名前を入力して、タイプを選択します。
名前: OID Authenticator

タイプ: OracleInternetDirectoryAuthenticator

OK

3. 認証プロバイダテーブル内で、新しく追加されたオーセンティケータをクリックします。

4. 設定ページの共通タブで、制御フラグをSUFFICIENTに設定して、保存をクリックします。

5. プロバイダ固有タブをクリックして、環境に合った値を使用して、次のような必要な設定を行います。
ホスト: ご使用のLDAPホスト。例: localhost

ポート: ご使用のLDAPホスト・リスナー・ポート。例: 6050

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin

資格証明: LDAP管理ユーザー・パスワード。

ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。

すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

ユーザー名属性: LDAPディレクトリ内のユーザー名のデフォルト属性として設定。例: uid

グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)

すべてのグループフィルタをデフォルト作業として設定しないでください。

保存します。

6. デフォルト・オーセンティケータ: 次の手順を実行して、Identity Asserterで使用するデフォルト・オーセンティケータを設定します。

1. セキュリティ・レルム、デフォルト・レルム名に移動して、プロバイダをクリックします。

2. 認証をクリックして、DefaultAuthenticatorをクリックし、確認ページを表示します。

3. 共通タブをクリックして制御フラグをSUFFICIENTに設定します。

4. 保存します。

7. プロバイダの並替え:

1. セキュリティ・レルム、デフォルト・レルム名、プロバイダをクリックします。

2. プロバイダがリストされたサマリーページで、並替えボタンをクリックします

3. 認証プロバイダの並替えページで、プロバイダ名を選択し、リストの横にある矢印を使用してプロバイダの並替えを行います。
OAM IDアサーション・プロバイダ: (REQUIRED)

OIDオーセンティケータ(SUFFICIENT)

デフォルト・オーセンティケータ(SUFFICIENT)

4. OKをクリックして変更を保存します

8. 変更のアクティブ化: チェンジ・センターで変更のアクティブ化をクリックします。

9. Oracle WebLogicサーバーを再起動します。

10. 次の作業を実行します。

- 成功した場合: 「IAMSuiteAgentの無効化」に進みます。

- 失敗した場合: すべてのプロバイダが環境に合った仕様になっており、正しい順序で、oamAuthnProvider.jarが「セキュリティ・プロバイダについて」に記載された正しい場所にあることを確認します。

IAMSuiteAgentの無効化

この手順はオプションで、必須ではありません。IDMDomainエージェントは、Webgateが認証を行い、サイレント状態になると検知します。ただし、エージェントを無効にする必要がある場合、エージェントを無効にする必要がある各サーバーに対して、WLSAGENT_DISABLEDシステム・プロパティまたは環境変数をtrueに設定する必要があります。これはAdminServerとOAMサーバーの両方に適用されます。

エージェントの無効化は次の2つの方法のいずれかで行えます。

- WLSAGENT_DISABLEDをtrueに設定するか、

- WLSAGENT_DISABLEDをシステム・プロパティとして渡します

前提条件

必要に応じて WebLogic用のOAMセキュリティ・プロバイダの構成を行います。

IAMSuiteAgentの無効化手順

1. IAMSuiteAgentをホスティングしているコンピュータ上で、次のタスクのいずれかを実行します。

- WLSAGENT_DISABLEDをtrueに設定するか、

setenv WLSAGENT_DISABLED true

- DWLSAGENT_DISABLED=trueをシステム・プロパティとして渡します。

-DWLSAGENT_DISABLED=true

2. Webサーバーを再起動します。

検証

10g Webgateを使用してそれぞれの環境をテストし、IAMSuiteAgentで保護されていたすべてのアプリケーションが、10g Webgateの構成後も保護されていることを確認するようお薦めします。

関連項目:

- 「アプリケーション・ドメインでの認証と認可の検証」

- 第14章「アクセス・テスターを使用した接続とポリシーの検証」

WebLogicコンテナへのアプリケーションのデプロイメント

このトピックの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

この項では、WebLogicコンテナにアプリケーションがある(または将来的に入る)デプロイメントの情報を記載します。

OAM 11gデプロイメントからの10g Webgateの削除

必要に応じて、次の手順を使用してOAM 11gデプロイメントから10g Webgateを削除します。

注意:
エージェントの登録を削除しても、関連付けられたホスト識別子、アプリケーション・ドメイン、リソース、またはエージェント・インスタンスは削除されません。

考慮事項

Webサーバーの構成変更: Webサーバーの構成変更は、Webgateのアンインストール後に手動で元に戻す必要があります。追加内容の詳細は、ご使用のWebサーバーに該当する章を参照してください。

Webgate IISフィルタ: Webgateおよび関連するフィルタをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。詳細は、「OAM 11gデプロイメントからの10g Webgateの削除」を参照してください。

前提条件

このエージェントに関連付けられたアプリケーション・ドメイン、リソース、およびポリシーを評価し、別なエージェントを使用するように構成されているのか、削除できるのかを確認してください。

10g Webgateのアンインストール手順

1. 削除するWebgateのWebサーバーを無効にします。

注意:
Webサーバーを無効にしなかった場合、アンインストールは失敗し、バックアップ・フォルダは削除されません。この場合、バックアップ・フォルダを手動で削除する必要があります。

2. Oracle Access ManagerコンソールのWebgate登録ページで、「状態」オプションの横の「無効」ボックスをクリックしてWebgateを無効化します。

3. 言語パック: インストールされている言語パック(デフォルトの管理者言語(ロケール)として選択されているものを除く)を次のように削除します。

- コンポーネントのアンインストール・ディレクトリ内にある、該当する言語パックを検索します。次に例を示します。
Webgate_install_dir\uninstIdentityLP_fr-fr
\uninstaller.exe

- 言語パック・アンインストーラ・プログラムを実行して、ファイルを削除します。

- このプロセスを繰り返し実行して、関連するコンポーネントから同じ言語パックを削除します。

- Webgate Webサーバーを停止して再起動し、適切な言語サポートを再初期化します。

- このプロセスを繰り返し実行して、各言語パックを削除します(デフォルトの管理者言語(ロケール)として選択されているものを除く)。

4. 次の手順を実行して10g Webgateの構成データを削除します。

- Oracle Access Managerコンポーネントのインスタンスが1つしかない場合は、手順4を完了して削除します。

- コンポーネントのインスタンスが複数ある場合は、手順5も参照してください。

5. 特定のプログラムのアンインストール・プログラムを検索して実行し、Oracle Access Managerファイルを削除します。次に例を示します。
Webgate_install_dir\access\_uninstWebgate\uninstaller.exe

注意:
UNIXシステムではuninstaller.binを使用します

6. 複数のインスタンス: 複数のWebgateインスタンスがあり、そのうちの1つ、またはすべてを削除する場合は、プラットフォーム固有のメソッドを使用する必要があります。

- Windows: 最後のコンポーネントは、プログラムの追加/削除でアンインストールできます。それ以外は、\access \uninstComponentディレクトリからアンインストール・プログラムを実行してアンインストールできます。

- UNIX: 常にuninstaller.binを実行する必要があります。

7. Webサーバー構成に対するOracle Access Manager関連の更新を削除します。特定のWebサーバーに関する詳細は、第28章、第29章、第30章、および第31章を参照してください。

8. Webサーバーを再起動します。

9. 特に再インストールを予定している場合、Webgate_install_dirディレクトリが残っていれば削除します。

28 Apache、OHS、IHSの10g Webgate用の構成

Oracle Access Managerは、Apache v2により稼動するWebサーバー用のWebgateを提供しています。これにはApache、Oracle HTTP ServerおよびIBM HTTP Server (IHS)が含まれています。

この章では3つのWebサーバー・タイプの構成に関して次を含む詳細を説明します。

- Oracle HTTP ServerとOracle Access Managerについて

- ApacheおよびIHS v2 Webgateを使用したOracle Access Managerについて

- Apache v2アーキテクチャとOracle Access Managerについて

- Oracle HTTP Server、IHS、Apache v2 Webサーバーの要件

- Webサーバーの準備

- Apache v2およびIHS v2のリバース・プロキシの起動

- Oracle Access Manager Webgate用のhttpd.conf更新の検証

- Oracle Access Manager Webgate用のOracle HTTP Serverのチューニング

- OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング

- Oracle HTTP Server Webサーバーの起動と停止

- Oracle Access Manager Webgate用のApache/IHS v2のチューニング

- アンインストール後のWebサーバー構成変更の削除

- 役立つ情報

前提条件

Oracle Access Managerコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシーの強制エージェントの概要」

- 「OAM 11gで使用する新規OAM 10g Webgateのインストールについて」

Oracle HTTP ServerとOracle Access Managerについて

Oracle HTTP Server用のOracle Access Manager Webコンポーネント・パッケージ名は、OHSで次のように指定されています。

- Oracle HTTP Server 11gはApache v2.2に基づいており、パッケージ名には次のようにOHS11gが含まれています。
Oracle_Access_Manager10_1_4_3_0_ platform_OHS11g_Webgate

- Oracle HTTP Server 10g R2 (10.1.2)および10g (10.1.3.1.0)は、Apache v1.3およびApache v2.0に基づくパッケージを提供しています。
Apache v2.0ベースのパッケージには次のようにOHS2が含まれています。
Oracle_Access_Manager10_1_4_3_0_platform_OHS2_Webgate

Apache v1.3ベースのパッケージには次のようにOHSが含まれています。
Oracle_Access_Manager10_1_4_3_0_platform_OHS_Webgate

次のOracle HTTP ServerリリースがOracle Access Managerで稼動します。

Oracle HTTP Server 11g: Oracle Access Manager Webgate Oracle HTTP Server 11gは、他のWebサーバー用のWebgateのように使用できます。さらに、このOracle HTTP Server 11g用Webgateは、Oracle Fusion Middleware 11g用にエンタープライズレベルのシングル・サインオンを構成する際の主要コンポーネントです。詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。『Oracle Fusion Middleware HTTP Server管理者ガイド 11gリリース1 (11.1.1)』も参照してください。

Oracle HTTP Server 10g (10.1.3.1.0): 2つのパッケージを提供しています(Apache v1.3ベースとApache v2.0ベース)。WebgateはスタンドアロンのOracle HTTP Serverにインストールできます。Oracleのシングル・サインオンへの統合を可能にするには、OHS2 WebgateをOracle Application Server上にインストールする必要があります。インストール中に、WebgateがOHS2上のモジュールとしてインストールされます。

「Webサーバーの準備」に記載されたOracle HTTP Server Webコンポーネント要件を必ず把握しておいてください。

ApacheおよびIHS v2 Webgateを使用したOracle Access Managerについて

Oracle Access ManagerはOracle HTTP Server以外に、Apache v2 WebサーバーとIBM HTTP Server用のコンポーネントを提供しています。IBM HTTP Server (IHS2)はApache v2のバリエーションです。特段の記載がないかぎり、次の情報は3つすべてに該当します。

- Apache v2.0.5.2 Webgate

- リバース・プロキシをアクティブにした場合は、この機能を含むApache v2.0.48 Webgate。

- リバース・プロキシをアクティブにした場合は、この機能を含む、IBM HTTP Server (IHS2) powered by Apache用Apache v2.0.47 Webgate。

注意:
最新のOracle Access Manager証明書の情報は次を参照してください。

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

各プラットフォームに固有のインストール・パッケージは、プレーンおよびSSL対応の両方のApacheモードをサポートしています。ファイル名の2という番号は、このコンポーネントがApache v2に基づいていることを示しています。次に例を示します。

AIX: Oracle_Access_Manager10_1_4_3_0_power-aix_IHS2_Webgate

Linux: Oracle_Access_Manager10_1_4_3_0_ linux_Apache2_Webgate

Solaris: Oracle_Access_Manager10_1_4_3_0_sparc-s2_Apache2_Webgate

Windows: Oracle_Access_Manager10_1_4_3_0_Win32_APACHE2_Webgate

Oracle Access Managerの以前のリリースには、プレーン・モードとSSL対応モード用に別なプラットフォーム固有のインストール・パッケージが含まれていました。たとえば各プラットフォームに対して、APACHE_WebgateおよびAPACHESSL_Webgateという2つのWebgateファイルが提供されていました。

これらのWebサーバーをサポートするために、Oracle Access Managerコンポーネントには機能的な変更はありません。Oracle Access Managerの認証は、HTTP基本認証、フォーム、またはSSLクライアント証明書を使用して、Webgateを介して行われます。認証済ユーザーによるWebリソースの許可、他のWebサーバーやアプリケーションとの簡易およびマルチドメインSSOもWebgateを介して行われます。

Apache HTTP Serverについて

Apache HTTP Serverは、Apache Software Foundationのオープン・ソースHTTP Webサーバー・プロジェクトです。プロジェクトの目的は、現在のHTTP標準に合った安全で効率のよい、拡張性のあるサーバーおよびHTTPサービスを提供することです。

詳細は、「Apache v2アーキテクチャとOracle Access Managerについて」を参照してください。

IBM HTTP Serverについて

IBM HTTP Server (IHS)はApache v2のバリエーションです。IBM HTTP ServerはThe Apache Groupの開発したソフトウェアに基づいています。IBM HTTP Serverコンポーネントには、OpenSSL Projectが開発したソフトウェアおよびEric Youngが開発したソフトウェアも含まれています。

ApacheアーキテクチャとOracle Access Managerに関する「Apache v2アーキテクチャとOracle Access Managerについて」での説明は、次の点を除きIHSに適用されます。

- IHSの旧バージョンでは、mod_ibm_ldapモジュールを使用するために別なIDSクライアントが必要でした。Apache v2.0.47稼動によるIHSではこれは不要になりました。

- IHS v2.0.47はFIPS 140-2をサポートしています。デフォルト設定ではFIPSサポートは無効になっています。FIPSサポートを有効にするには、SSLFIPSEnableディレクティブをhttpd.confファイルに追加してください。同様に、SSLFIPSDisableディレクティブを使用してFIPSサポートを無効にします。

- AIXでは、IHS v2.0.47をインストールする前に、適切なランタイム・ライブラリがインストールされていることを確認してください。

たとえばAIX 5.1では、IHS v2.0.47のインストール前に、xlC.rte 6.0ランタイム・ライブラリ(例: xlC.rte.6.0.0.0)がインストールされている必要があります。このライブラリは、AIX上でSSLをインストールして、IHS v2と使用するために必要です。次のWebサイトからこのライブラリをダウンロードできます。

http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp

ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて

通常、リバース・プロキシは次の状況で使用されます。

- インターネット・ユーザーに対して、ファイアウォールの裏側にあるサーバーへのアクセスを提供するため

- 複数のバックエンド・ユーザー間のロード・バランシングのため、または低速バックエンド・サーバーにキャッシングを提供するため

- 同じURL領域に複数のサーバーを導入するため

proxy_moduleにより、ApacheおよびIHS powered by Apacheのためにプロキシ/ゲートウェイが実装されます。クライアントに特別な構成は必要なく、リバース・プロキシは通常のWebサーバーのように見えます。クライアントでは、リバース・プロキシのネームスペース内のコンテンツに対して、通常どおりリクエストが作成されます。それらのリクエストの送信先を決定するのはリバース・プロキシです。リバース・プロキシがオリジンであるかのようにコンテンツが返されます。

重要:
proxy_moduleを使用してFTP、CONNECT (SSL用)、HTTP/0.9、HTTP/1.0、およびHTTP/1.1用のプロキシ機能を実装できます。ただし、Webgateではリバース・プロキシ機能のみがサポートされています。

詳細は、「Apache v2 Webサーバーの要件」を参照してください。

Apache v2アーキテクチャとOracle Access Managerについて

Apache v2 Webサーバーは、スレッドセーフのOracle Access Managerライブラリと互換性のある、ハイブリッドのマルチスレッド、マルチプロセス・アーキテクチャを提供します。

重要:
特に明記しないかぎり、ここに示す詳細な説明は、10g Webgate用のApache v2とIHS v2 Webサーバーに同様に適用されます。

標準モジュール・セット以外に、Apache v2 Webサーバーにはコンピュータ上のネットワーク・ポートをバインドし、プロセス・リクエストの受付けと処理を行うマルチプロセス・モジュール(MPM)が含まれています。ApacheまたはIHS v2用のOracle Access Managerコンポーネントをインストールする前に、適切なMPMをサーバーにコンパイルして起動しておく必要があります。

- Windows: Windowsプラットフォームではmpm_winntがデフォルトのMPMです。mpm_winntはApache 1.3で使用されているPOSIXレイヤーではなく、ネイティブ・ネットワーキング機能を使用できます。

- UNIX: UNIXプラットフォームでは、prefork MPMがApache v2 Webサーバー用のデフォルトMPMです。prefork MPMは、Apache v1.3に類似の方法でリクエストを処理する、非スレッドのプレフォークWebサーバーを実装します。

注意:
Webgate用のmpm_worker_moduleを使用してUNIX上でApacheをコンパイルする場合、「Webgate用のmpm_worker_moduleを使用したUNIX上のApache v2」で説明しているとおり、マルチスレッド・サーバー実装中に最適なパフォーマンスを確保するために、Webgateのデフォルトpthreadスタックサイズを最適化する必要があります。

- AIX: AIXプラットフォームでは、worker MPMがIHS v2用のデフォルトMPMです。worker MPMはハイブリッド・マルチプロセス、マルチスレッド・サーバーを実装します。このMPMをを制御するために最も重要なディレクティブは、ThreadsPerChildおよびMaxClientsです。詳細は、「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」を参照してください。

Apache v2 WebサーバーにはApache Portable Runtime (APR)ライブラリが含まれており、プラットフォーム固有の実装へのインタフェースを提供し、プラットフォームに関係なく同一の動作が行われない場合はAPI開発者に事前に通知し、条件付きコンパイルの#lfdefsの必要性をなくします。include/apu_compat.hファイルでは下位互換性がサポートされていますが、Apache v2 APRの使用をお薦めします。

詳細はご使用のApache v2のドキュメントを参照してください。「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」も参照してください。

Apacheアーキテクチャは次の項で説明しているように、別な方法でOracle Access Managerコンポーネントに影響を及ぼします。

IHSおよびApache v2にインストールされているWebgateの場合

- プロセス間で共有するキャッシュはありません。

- 各プロセスがアクセス・サーバーと個別に接続します。したがって、Webgate接続数を制限する必要があります。この問題は、Webサーバーとアクセス・サーバーを実行しているシステムのパフォーマンスにある程度影響を受けます。

注意:
他のWebサーバー用のWebgateを含むインストールで、Apache v2 (および派生製品)用のWebgateを使用できます。
Webgate用のmpm_worker_moduleを使用してUNIX上でApacheをコンパイルする場合、「Webgate用のmpm_worker_moduleを使用したUNIX上のApache v2」で説明しているとおり、マルチスレッド・サーバー実装中に最適なパフォーマンスを確保するために、Webgateのデフォルトpthreadスタックサイズを最適化する必要があります。

ApacheおよびIHS v2 Webサーバーの制限

Apache v2 Webサーバーの制限により、Oracle Access Managerのフォームベースの認証スキーム用に構成されたプラグインは次の場合に変数を渡しません。

- 後処理プログラムによってログイン資格証明を渡すために、オプションのチャレンジ・パラメータ、passthrough:Yesが認証スキームに含まれています。

- フォーム・アクションは受領したすべてのヘッダーと変数のダンプを作成するCGIスクリプトで、この方法はHTTP POSTメソッドを使用して呼び出されます。

例:

<html>
<form name="myloginform" action="/access/...cgi" method="post">

Oracle HTTP Server、IHS、Apache v2 Webサーバーの要件

Oracle Access Manager HTMLページではUTF-8エンコーディングを使用します。Apache、Oracle HTTP Server、およびIBM HTTP Server (IHS)を含むApacheベースのWebサーバーでは、管理者はAddDefaultCharsetディレクティブを使用して、送信されたすべてのHTMLページのデフォルト文字セットを指定できます。このディレクティブは、HTMLページを生成するアプリケーションによって指定された任意の文字を無効にします。AddDefaultCharsetディレクティブがUTF-8以外の文字セットを有効にした場合、Oracle Access Manager HTMLページで文字化けが発生します。

OracleはWebサーバー構成ファイル(httpd.conf)でAddDefaultCharsetディレクティブを次のように指定し、Oracle Access Manager HTMLページが正しく表示されるようにすることをお薦めします。

AddDefaultCharset Off

このディレクティブの詳細は、ご使用のWebサーバーのドキュメントを参照してください。

次のトピックでは注意が必要な追加の詳細情報を提供します。

- IHS2 Webサーバーの要件

- ApacheおよびIHS v2リバース・プロキシ・サーバーの要件

- Apache v2 Webサーバーの要件

IHS2 Webサーバーの要件

ここでは、Oracle Access Managerで使用するIHS v2の特定の要件を説明します。IHS v2では、バイナリを入手するためにソース・コードをコンパイルする必要はありません。ただし、IHS v2 Webサーバーには次の要件が適用されます。

- AIX上でのSSL対応の構成には、xLC.rte.6.0ランタイム・ライブラリが必要です。

- SSL対応の構成には、GSKit7が必要で、これはhttps://techsupport.services.ibm.com/server/aix.fdcからダウンロードできます。

ApacheおよびIHS v2リバース・プロキシ・サーバーの要件

前に説明したproxy_moduleによって、プロキシ/ゲートウェイが実装されます。クライアントは特殊な構成を行う必要はありません。proxy_moduleを使用してFTP、CONNECT (SSL用)、HTTP/0.9、HTTP/1.0、およびHTTP/1.1用のプロキシ機能を実装できますが、特定のOracle Access Manager ApacheおよびIHS v2 Webgateではリバース・プロキシ機能のみがサポートされています。

Apache Webサーバーの場合: Oracle Access Managerでリバース・プロキシ機能を使用するには、configureコマンドにプロキシ・モジュールを含む必要があります。次に例を示します。

--enable-proxy: Apacheプロキシ・モジュール --enable-proxy-connect: ApacheプロキシCONNECTモジュール

--enable-proxy-ftp: ApacheプロキシFTPモジュール

--enable-proxy-http: ApacheプロキシHTTPモジュール

mod_proxyおよびmod_proxy_httpモジュールを、サーバーに動的にロードする必要もあります。リバース・プロキシは、ProxyPassディレクティブを使用して、またはRewriteRuleディレクティブに[P]フラグを使用して起動します。

IHS Webサーバーの場合: IHS Webサーバーのインストール後、次のディレクトリ内のhttpd.confファイルでリバース・プロキシ構成を完了する必要があります。

IHS_install_dir/confディレクトリ

詳細は、「Apache v2およびIHS v2のリバース・プロキシの起動」を参照してください。

Apache v2 Webサーバーの要件

ここでは、Oracle Access Managerで使用するApache v2の特定の要件を説明します。追加の情報はご使用のApacheのドキュメントを参照してください。

PATH変数: UNIXシステムでは、Apache v2のコンパイル前に、PATH変数にgccの場所が含まれている必要があります。ただしSunのCコンパイラの場所は、PATH変数に含まないでください。Windowsシステムでは、コマンドラインツールまたはVisual Studio IDE Workbenchを使用してApacheを構築できます。コマンドラインでの構築では、PATH、INCLUDE、LIB、およびvcvars32バッチ・ファイルで構成可能なその他の変数を環境に反映しておく必要があります。

マルチプロセス・モジュール(MPM): Apache v2では、コンピュータ上のネットワーク・ポートをバインドして、リクエストの受付けと処理のために、デフォルトMPMが各プラットフォーム用に提供されています。Apacheでは同時に複数のMPMを使用することはできません。コンパイル中にMPMが選択されていない場合は、デフォルトがWebサーバーにロードされます。コンパイル中にMPMを起動できます。

mod_ssl: Oracle Access ManagerはSSL対応または非対応の通信機能を備えたApacheをサポートしています。基本のApache Webサーバーはブラウザ接続にSSLを使用せず、HTTPSリクエストに応答しません。SSL対応の通信用に、Oracle Access Managerはmod_ssl付きのApacheのみをサポートしています。SSL固有のOracle Access Manager機能は、Apache-SSLでは使用できません。

mod_sslは暗号化エンジンの提供をOpenSSLに依存しており、mod_sslがOpenSSLライブラリへのインタフェースを提供します。OpenSSLライブラリは、セキュア・ソケット・レイヤーおよびトランスポート・レイヤー・セキュリティ・プロトコルを使用した強力な暗号化を提供しています。

Apacheの旧バージョンでは、mod_sslモジュールを別途ダウンロードして、サーバーにコンパイルする必要がありました。Apache HTTP Server v2モジュールでは、mod_sslがロード可能なモジュールとして提供されており、構成中に有効化できます。

マルチスレッド化: Apache v1.3.27以降でのインストールではマルチスレッド化が必要です。

Dynamic Shared Object (DSO): WebgateにはDSOサポートが必要です。基本のコア・サーバー機能を拡張するApacheモジュールは、Apacheバイナリに固定的に含むために静的にコンパイルするか、再コンパイルなしで実行時にロードするために動的にコンパイルおよび格納できます。Apache v1.3ではmod_soのコンパイルが必要です。Windowsシステム上のApache v2では、mod_soは基本モジュールで常に含まれています。UNIX上のApache v2では、ロードされたコードは通常、共有オブジェクト・ファイルからのものです。

注意:
動的にロードされたApache 1.3モジュールは、Apache v2では直接使用できません。Apache v1.3モジュールを変更して動的にロードするか、Apache v2にコンパイルする必要があります。

mod_perl: mod_perlはPerlプログラミング言語をApache Webサーバーに組み込みます。Perlがなくても、Apache v2の構築とインストールは行えますが、Perlで書かれた一部のサポート・スクリプトが使用できません。

注意:
Apache v.1.3.2xでは、構成中に一部のオペレーティング・システムが追加のオプションを必要としていました。しかしApache v2の構築では、追加の変数を設定する必要はありません。

Webサーバーの準備

Oracle Access Manager Webコンポーネントのインストール用にホスト・コンピュータを準備する方法と手順は、次のタスクの概要で説明しているように具体的なWebサーバーとプラットフォームによって異なります。

Oracle Access Managerでリバース・プロキシ機能を使用するには、「 ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて」で説明しているように、configureコマンドにプロキシ・モジュールを含む必要があります。「Apache v2およびIHS v2のリバース・プロキシの起動」も参照してください。

タスクの概要: Webサーバーの準備とOracle Access Managerのインストール

1. 次で説明しているように、IHS v2 Webサーバーをインストールまたはコンパイルして、Apache v2 Webサーバーをインストールします。

- IHS v2 Webサーバーの準備

- Linux上でのApacheおよびOracle HTTP Server Webサーバー

- LinuxおよびWindowsプラットフォームでのOracle HTTP Server Webサーバーの準備

- Oracle HTTP Serverのクライアント証明書の設定

- UNIX上でのApache v2 Webサーバーの準備

- AIX上でのApache v2 SSL Webサーバーの準備

- Windows上でのApache v2 Webサーバーの準備

2. 必要に応じて、「Apache v2およびIHS v2のリバース・プロキシの起動」の説明に従って、リバース・プロキシ機能を起動します。

3. このガイドでの説明に従って、Oracle Access Managerコンポーネントをインストールします。

4. 「Oracle Access Manager Webgate用のhttpd.conf更新の検証」の説明に従って、Webサーバーの構成を終了します。

5. 必要に応じて次のトピックを参照してください。

- 「Oracle Access Manager Webgate用のOracle HTTP Serverのチューニング」

- 「OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング」

- 「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」

注意:
次のすべての手順では、パス名変数、モジュール、およびオプションは手順を説明するためだけに提供されている例です。ご使用の環境とは異なります。詳細は、ご使用のWebサーバーのドキュメントを参照してください。

IHS v2 Webサーバーの準備

IHS v2 WebサーバーでIHS v2用のWebgateを受け入れて使用できるようにするには、環境や要件に応じて、次の手順の1つ以上を完了する必要があります。

- IHS v2インストール用ホストの準備

- IBM HTTP Server v2のインストール

- SSL機能の設定

- セキュアな仮想ホストの起動

- Apache v2およびIHS v2のリバース・プロキシの起動

該当する手順を完了すると、IHS v2用のWebgateをインストールする準備が整います。

IHS v2インストール用ホストの準備

IHS Webサーバーのインストール前に、この手順を完了してホスト・コンピュータを設定しておく必要があります。詳細は、「IHS2 Webサーバーの要件」および「Apache v2 Webサーバーの要件」を参照してください。

この例ではAIX 5.1へのインストールを示します。ご使用の環境とは異なることがあります。

IHS v2のインストールの準備手順

1. ホスト・コンピュータに、次のサイトからIBM Developer Kit、Java Technology Edition version 1.4をダウンロードしてインストールします。

http://www.ibm.com/java/jdk

IBM Developer KitはWebSphere Application Serverに同梱されており、このサイトからもダウンロードできます。

2. ホスト・コンピュータに、GSKit7ランタイム実行可能ファイルで必要なAIX 5.1用のxlC.rte 6.0ランタイム・ファイルを次のサイトからダウンロードしてインストールします。

https://techsupport.services.ibm.com/server/aix.fdc

3. ホスト・コンピュータで新しいディレクトリを作成し、そこにIBM HTTP Serverのインストール・イメージを解凍します。

4. ホスト・コンピュータに、次のWebサイトからIBM HTTP Serverのインストール・イメージをダウンロードします。
http://www-306.ibm.com/software/webservers/httpservers/

5. ホスト・コンピュータ上の新規ディレクトリに、インストール・イメージを解凍します。
例:

tar -xf IHS.tar

ご使用のオペレーティング・システムに基づき、次のファイルのリストが表示されます。

gskit.sh
setup.jar
gskta.rte (a GSKit runtime executable for AIX)

これで次に説明するインストール手順の準備ができました。

6. 「IBM HTTP Server v2のインストール」に進みます。

IBM HTTP Server v2のインストール

次の手順は一般的なIBM HTTP Webサーバーのインストールを紹介するものです。かわりにサイレント・インストールの実行を選ぶこともできます。その場合は、java -jar setup.jar -silent -options silent.resコマンドで、silent.resファイルを使用します。silent.resテキスト・ファイルを編集することで、サイレント・インストール・オプションをカスタマイズできます。デフォルト設定では、すべてのオプションがTrueに設定されています。オプションを無効にするには、値をFalseに設定します。

Apache v2によって稼動されるIBM HTTP Webサーバーのインストール手順

1. 前の例でコンピュータ上にインストールされたJava Technology Edition version 1.4を指すようにパスを設定します。次に例を示します。

export PATH=$PATH:/usr/java14/java/bin

2. インストール・イメージの圧縮先ディレクトリから、次のコマンドを入力します。

java -jar setup.jar

3. インストールを実行する言語を選択します。
IBM HTTP ServerのInstallShieldウィザードへようこそが表示されます。

4. 次へをクリックしてようこそ画面を閉じます。

5. ディレクトリ名を指定します。次に例を示します。

AIX: /usr/IBMIHS/

6. 次へをクリックして続行します。
一般、カスタム、または開発者向けのインストール・オプションが表示されます。一般的なインストールを選択すると、すべてが含まれたリストとイメージ・サイズが表示されます。カスタム・インストールを選択すると、コンポーネント・リストが表示され、インストールが不要な任意のコンポーネントの横のボックスをクリアできます。

7. 実行するインストール・タイプを選択し、次に次へをクリックします。次に例を示します。

Typical

次のメッセージが表示されます。取消をクリックして、インストールを停止できます。

Installing IBM HTTP Server. Please wait.

次のメッセージも表示されます。取消をクリックして、インベントリの更新を停止できます。

Updating the inventory.

8. 終了をクリックして、インストールを終了します。

9. 次のようにapachectlコマンドを使用して、IHSサーバーを停止し、その後起動します。
例:

IHS2_install_dir/bin
./apachectl stop
./apachectl start

ここで、IHS2_install_dirはIHS v2 Webサーバーをインストールしたディレクトリです。

IHS v2用のWebgateのインストール前または後に、複数のモードでIHS v2 Webサーバーを構成できます。

- SSL機能の設定

- セキュアな仮想ホストの起動

- Apache v2およびIHS v2のリバース・プロキシの起動

SSL機能の設定

SSL機能を設定する必要がある場合は、IHS v2用のWebgateのインストール前または後に次の手順を使用してください。

デフォルト構成ファイルを使用したIHS v2用のSSLの設定手順

1. 次のファイルを検索して開きます。
IHS2_install_dir/conf/httpd.conf

2. SSLEnableディレクティブを指定してSSLを有効にします。

3. Keyfileディレクティブと有効にする任意のSSLディレクティブを指定します。

4. 次のようにIHSサーバーを停止し、その後起動します。次に例を示します。

IHS2_install_dir/bin
./apachectl stop
./apachectl start

ここで、IHS2_install_dirはIHS v2 Webサーバーをインストールしたディレクトリです。

5. 次の手順に進みます。

- セキュアな仮想ホストの起動

- Apache v2およびIHS v2のリバース・プロキシの起動

セキュアな仮想ホストの起動

セキュアな仮想ホストを起動する必要がある場合は、IHS v2用のWebgateのインストール前または後に次の手順を使用してください。

IHS v2のセキュアな仮想ホストの起動手順

1. 次のファイルを検索して開きます。

IHS2_install_dir/conf/httpd.conf

ここで、IHS2_install_dirはIHS v2 Webサーバーをインストールしたディレクトリです。

2. 構成ファイルの仮想ホスト・スタンザでSSLEnableディレクティブを指定し、仮想ホストのSSLを有効にします。
キャッシュ・ディレクティブ以外の任意のディレクティブを、仮想ホスト内で指定できます。

3. Keyfileディレクティブと、その仮想ホストに対して有効にする任意のSSLディレクティブを指定します。

4. confファイル内でLoadModuleディレクティブを使用して、mod_ibm_ssl.soをロードします。

5. 次のようにIHS仮想ホストを停止し、その後起動します。次に例を示します。

IHS2_install_dir/bin
./apachectl stop
./apachectl start

注意:
SSL実装の開始と停止指示は、SSL非対応の実装と同じです。

6. Apache v2およびIHS v2のリバース・プロキシの起動に進んでください。

Linux上でのApacheおよびOracle HTTP Server Webサーバー

Linux上のApacheまたはOracle HTTP ServerにOracle Access Manager Webgateをインストールする場合、Webサーバーを実行しているユーザーとしてインストールするように促されます。httpd.confファイルのUserおよびGroupディレクティブを参照してください。

ベンダーがバンドルしたRed Hat Enterprise Linux 4上のApache v2用にOracle Access Manager Webgateをインストールする場合は、すべてのOracle Access Manager WebgateがWebサーバーのユーザーおよびグループ(デフォルト: apache)用にインストールされていることを確認してください。「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」も参照してください。

注意:
Linux上では、Oracle HTTP Server 11g用のOracle Access Manager WebgateではNPTLのみが使用され、LinuxThreadsライブラリは使用できません。この場合は、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。

LinuxおよびWindowsプラットフォームでのOracle HTTP Server Webサーバーの準備

WindowsおよびLinuxプラットフォーム上のOracle HTTP Server v2用にOracle Access Manager Webgateを使用する場合、PerlモジュールとPHPモジュールの両方を、httpd.conf内でコメント・アウトしておく必要があります。

注意:
Oracle HTTP Server 11gでは、どのプラットフォームでもOracle Access Manager Webgate用のモジュールをコメント・アウトする必要はありません。

Oracle HTTP Serverのクライアント証明書の設定

cert_decodeおよびcredential_mapping認証モジュールを使用する場合、Oracle HTTP Server Webサーバーの構成ファイル内の既存のSSLオプションに、+EarlierEnvVarsおよび+ExportCertDataを追加して、SSL対応のOracle HTTP Serverでクライアント証明書認証スキームが正しく機能することを確認する必要があります。次に例を示します。

credential_mapping:

obMappingBase="o=company,c=us",obMappingFilter=
"(&(objectclass=InetOrgPerson)(mail=%certSubject.E%))"

ssl.confには次を含む必要があります。

SSLOptions +StdEnvVars +ExportCertData +EarlierEnvVars

Oracle HTTP Serverにsslオプションを追加する手順

1. Oracle HTTP Server Webサーバーの構成ファイルを検索し、テキスト・エディタで開きます。次に例を示します。
$ORACLE_INSTANCE/ohs/conf/ssl.conf

2. ssl.confファイル内の既存のSSLオプションに次の情報を追加します。次に例を示します。

SSLOptions +StdEnvVars +ExportCertData +EarlierEnvVars

3. ファイルを保存してWebサーバーを再起動します。

UNIX上でのApache v2 Webサーバーの準備

ここでは、Solaris、UNIX、Linux、およびAIXを含むUNIXプラットフォーム上のでOracle Access Manager用のApache v2 HTTP Webサーバーの準備の概要と手順を説明します。「AIX上でのApache v2 SSL Webサーバーの準備」も参照してください。

Apache v2はプレーンまたはSSL対応で構成、構築、およびインストールできます。Apacheソース・ファイルのダウンロードおよび解凍後、スクリプト(UNIX上のconfigureスクリプト、およびWindows用のmakefile.win makeスクリプト)を使用して、ご使用の環境に合ったソース・ツリーをコンパイルします。

注意:
プラットフォームに関係なく、基本的な要件は同じです。ただし、ここでの以降の説明や手順はUNIXプラットフォームを中心としています。詳細は、「AIX上でのApache v2 SSL Webサーバーの準備」も参照してください。

UNIXプラットフォーム上でApache v2を構成する場合、-prefix=オプションを./configureコマンドに使用して、インストール・ディレクトリ・パスを指定します。構成中に、環境に適したモジュールを有効にできます。たとえば、コンパイルに動的モジュールが含まれている場合は、サーバーに自動的にmod_soが含まれます。ただし、-enable-soオプションをconfigureコマンドに含んで、サーバーがDSOのロードが行えることを確認できます。複数のPerlインタプリタをインストールしている場合は、構成中に正しいインタプリタが選択されるように、-with-perlオプションを含むことができます。

configureコマンドには、mod_sslを有効にして、MPMを起動するためのオプションも含むことができます。構成後、./httpd -lを使用してサーバーにコンパイルされた各モジュールをリストし、選択したMPMを検証できます。

Apacheの構成が終了すると、makeコマンドを使用してApacheパッケージを構成する各種の部品を構築し、構成中に-prefix=オプションで指定したインストール・ディレクトリにパッケージをインストールします。

手順や例については、次の手順とご使用のApacheのドキュメントを参照してください。

- UNIX用のプレーンApache v2の準備手順

- UNIX上のSSL対応Apache v2の準備手順

- Windows用のApache v2の準備手順

- Apache v2およびIHS v2のリバース・プロキシの起動

次の手順では、パス名変数、モジュール、およびオプションは手順を説明するためだけに提供されている例です。ご使用の環境とは異なります。詳細は、ご使用のWebサーバーのドキュメントを参照してください。Apache v2.0.48とv2.0.52では構築手順に違いはありません。

UNIX用のプレーンApache v2の準備手順

1. ご使用の環境が、次の場所にあるApacheのドキュメントに記載された、該当するコンパイラと構築ツールのApache要件を満たしていることを確認してください。

http://httpd.apache.org/docs-2.0/install.html#requirements

注意:
Apache v2およびOracle Access Managerプラグイン用にサポートされているコンパイラ・バージョンについては、既知の制約はありません。Apacheのドキュメントを参照してください。

2. Apacheのドキュメントに記載された、完全な、未修正版のApache HTTP Server v2をダウンロードしてください。次に例を示します。

http://httpd.apache.org/download.cgi

注意:
必要な場合は、必ずPerlをダウンロードしてください。

3. Apacheのドキュメントに記載されているように、tarballからソース・ファイルを解凍(解凍後、untar)します。次に例を示します。

gzip -d httpd-2_0_48.tar.gz
tar -xvf httpd-2_0_48.tar

次の手順をApacheソース・ツリーの構成例として使用できます。Webgate用のmpm_worker_moduleを使用してUNIX上でApacheをコンパイルする場合は、「Webgate用のmpm_worker_moduleを使用したUNIX上のApache v2」を参照してください。

注意:
Oracle Access Managerでリバース・プロキシ機能を使用するには、「 ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて」で説明しているように、configureコマンドにプロキシ・モジュールを含む必要があります。

4. Apacheソースを構築するためには、正しいパスに正しいバージョンのGNU gccライブラリがあることを確認してください。gccライブラリは次のPATHにある必要があります。

export PATH=/usr/local/packages/gcc-3.4.6/bin:$PATH

5. Apacheのドキュメントを使用して、Apacheソース・ツリーを構成し、該当するモジュールを有効化または起動します。次に例を示します。

cd apache_source_dir
./configure --with-mpm=prefork --prefix=apache_install_dir --with-included-apr
./configure --with-mpm=worker --prefix=apache_install_dir --with-included-apr

ここで、apache_source_dirはApacheを解凍したディレクトリで、apache_install_dirはApacheのインストール・ディレクトリです。

6. makeコマンドを使用して構成したApacheパッケージをコンパイルします。次に例を示します。

make

7. --prefix=オプションを使用して、先ほど指定した構成ディレクトリ・パスにApacheパッケージをインストールします。次に例を示します。

make install

8. Apacheのドキュメントの指示を使用してインストールをカスタマイズします。
たとえば、次の基本値を設定するためにhttpd.confのチューニングが必要になる場合があります。

ServerName
User/owner of the WebServer
Group

注意:
全値のリストを表示するには、コマンド./configure --helpを使用します。

9. apache_install_dir/binディレクトリ内のコマンドを使用して、Apache Webサーバーを停止して再起動し、インストールをテストします。次に例を示します。

./apachect1 stop
./apachectl start

10. ご使用の環境に合った次のようなタスクに進みます。

- UNIX上のSSL対応Apache v2の準備手順

- UNIX上でのApache v2 Webサーバーの準備

- Apache v2およびIHS v2のリバース・プロキシの起動

次の手順では、SSL対応のApache v2 WebサーバーをUNIX上で準備する方法を説明します。Apacheのmod_sslはロード可能ですが、このインストールではSSL/TLS用のOpen Sourceツールキットが必要です。また、必要な場合は、必ずPerlをダウンロードしてください。使用しているプラットフォームがAIXの場合は、「AIX上でのApache v2 SSL Webサーバーの準備」で必ず詳細を確認してください。

UNIX上のSSL対応Apache v2の準備手順

1. ご使用の環境が、次の場所にあるApacheのドキュメントに記載された、該当するコンパイラと構築ツールのApache要件を満たしていることを確認してください。

http://httpd.apache.org/docs-2.0/install.html

2. Apacheのドキュメントに記載された、完全な、未修正版のApache HTTP Server v2とOpen Sourceをダウンロードしてください。

http://httpd.apache.org/download.cgi
http://www.openssl.org/

3. Apacheのドキュメントに記載されているように、tarballからソース・ファイルを解凍(解凍後、untar)します。次に例を示します。

gzip -d httpd-2_0_48.tar.gz
tar -xvf httpd-2_0_48.tar
gzip -d openssl-0_9_6f.tar.gz
tar -xvf openssl-0_9_6f.tar

4. Apacheのドキュメントに記載されているように、OpenSSLソース・ツリーを構成します。次に例を示します。

cd openssl_source_dir
./config -fPIC --prefix=openssl_install_dir

ここで、openssl_source_dirはOpenSSLを解凍したディレクトリで、openssl_install_dirは構成済のOpenSSLパッケージのインストール・ディレクトリです。

5. --prefix=オプションを使用して、先ほどmakeコマンドで構成したインストール・ディレクトリにOpenSSLパッケージをコンパイルします。次に例を示します。

make

6. make testコマンドを発行してOpenSSLのサニティ・テストを実行し、必要なツールの正しいバージョンをチェックします。次に例を示します。

make test

7. --prefix=オプションを使用して、先ほど指定した構成ディレクトリ・パスにOpenSSLパッケージをインストールします。次に例を示します。

make install

8. Apacheのドキュメントに記載されているように、Apacheソース・ツリーを構成し、該当するモジュールを有効化または起動します。次に例を示します。

cd apache_source_dir ./configure --prefix=apache_install_dir
--enable-so \ --with-mpm='prefork' --with-perl=perl_interpreter_path \
--with-port=non_ssl_port --enable-ssl \ --with-ssl=openssl_install_dir

ここで、apache_source_dirはApacheを解凍したディレクトリで、apache_install_dirはApacheのインストール・ディレクトリです。そしてopenssl_install_dirは構成済のOpenSSLパッケージをインストールしたディレクトリです。

9. makeコマンドを使用してApache SSL対応パッケージを、--prefix=オプションを使用して構成したインストール・ディレクトリでコンパイルします。次に例を示します。

make install

10. --prefix=オプションを使用して、先ほど指定した構成ディレクトリ・パスにApache SSL対応パッケージをインストールします。次に例を示します。

make install

SSLを有効にするには、openssl_install_dir/bin/にあるopensslツールを使用して、Apache v2サーバー用の証明書を明示的に作成する必要があります。証明書作成コマンドは、Apache v2では機能しません。

11. ご使用のOpenSSLのドキュメントに記載されているように、openssl_install_dir/binディレクトリ内のOpenSSLツールを使用して証明書を作成しますが、その際、共通名は完全に就職されたホスト名である点を忘れないでください。

12. Apacheのドキュメントの指示を使用してインストールをカスタマイズします。

- 次の基本値を設定するために、httpd.confをチューニングします。

ServerName
User/owner of the WebServer
`Group

- 次の基本値を設定するために、ssl.confをチューニングします。

Listen 7000
<VirtualHost _default_:7000>
ServerName ps0733.persistent.co.in:7000
SSLCertificateFile /home/qa/software/ws/apache/
apache-2.0.48_ssl_7000/conf/ssl.crt/server.crt
SSLCertificateKeyFile /home/qa/software/ws/apache/
apache-2.0.48_ssl_7000/conf/ssl.key/server.key

13. apache_install_dir/binディレクトリ内のコマンドを使用して、Apache Webサーバーを停止して再起動し、インストールをテストします。次に例を示します。

./apachectl stop
./apachectl startssl

14. 必要に応じて、Apache v2およびIHS v2のリバース・プロキシの起動に進んでください。

AIX上でのApache v2 SSL Webサーバーの準備

Apache v2 SSL Webサーバーの構築中に、OpenSSLライブラリlibssl.aからの記号がApacheのhttpd実行可能ファイルにエクスポートされます。Oracle Access ManagerがOpenSSLライブラリから必要な記号は次のとおりです。

- SSL_get_peer_certificate( )

- i2d_X509( )

AIXプラットフォーム上でのリンクとバインド中に、未使用または参照されていない記号は削除されます。したがってOracle Access Managerが必要とする2つの記号が、httpd実行可能ファイルには含まれません。

AIX上でのコンパイルにはopenssl-0.9.7dを使用する必要があります(AIX上ではopenssl-0.9.7eはコンパイルしません)。以降の手順はUNIXopenssl-0.9.7dの場合と同じです。

クライアント証明書認証: AIXプラットフォームでクライアント証明書認証を使用している場合は、AIX上でのdlsymの問題に対する次のホット・フィックスが適用されたAIX 5.2 Maintenance Level 4を必ず使用してください。

http://www-1.ibm.com/support/docview.wss?uid=isg1IY63366

Apache v2用のAIXプラットフォームの準備手順

1. ご使用のAIXプラットフォームが、Oracle Access Managerのシステム要件を満たしていることを確認してください。

2. 「 UNIX上でのApache v2 Webサーバーの準備」の詳細を参照し、Apache v2 Webサーバーの構築時には次を行います。

- openssl-0.9.7dを使用してAIX用にWebサーバーをコンパイルします。

- makeコマンドを次のように使用します。

make MFLAGS=EXTRA_LDFLAGS='-Wl,-bE:OpenSSL_Symbols.exp'

ここで、OpenSSL_Symbols.expは必要な2つの記号が含まれたファイルです。記号は次のように、エクスポート・ファイルのみを使用してエクスポートする必要があります。

注意:
次の方法でAIX上に記号をエクスポートしないでください。-bnog: 記号のガベージ・コレクションを抑制 -bexpal: すべての記号のエクスポート -uSymbolName: 特定の記号のエクスポート。

Windows上でのApache v2 Webサーバーの準備

以降では、Windows上のApache v2とUNIX上のApache v2のインストールと構成の違いについて、詳細に説明しています。詳細はご使用のApacheのドキュメントを参照してください。

インストール中: 選択したインストール・ディレクトリを反映するように、Apacheが\confサブディレクトリ内のファイルを構成します。このディレクトリ内のいずれかの構成ファイルが既存の場合、対応するファイルの新規コピーが.ORIGの拡張子で書き込まれます。たとえば、\conf\httpd.conf.ORIGです。

インストール後: \confサブディレクトリ内のファイルを使用して、Apacheが構成されます。これらはUNIXバージョンの構成に使用するものと同じファイルです。ただしいくつかの違いがあります。

\confサブディレクトリの構成ファイルを編集して、環境に合わせてApacheをカスタマイズする必要があります。これらのファイルはインストール中に構成され、htdocsサブディレクトリのドキュメント・サーバーとともに、インストール・ディレクトリのApacheを実行する準備が整います。Apacheの使用開始前に設定する必要があるオプションが多数あります。たとえば、構成ファイルでListenディレクティブを変更するか、現在のユーザー専用にApacheをインストールしないかぎり、Apacheはポート80をリッスンします。

マルチスレッド化: Windows用のApacheはマルチスレッド化されており、これはUNIX上でのApacheの各リクエストに個別のプロセスは使用しないことを意味しています。かわりに、通常は親プロセスとリクエストを処理する子プロセスという、2つのApacheプロセスのみが実行しています。子プロセス内では、各リクエストが個別のスレッドとして処理されます。

UNIX形式の名前: Apacheは内部でUNIX形式の名前を使用します。引数としてファイル名を受け付けるディレクティブは、UNIXファイル名ではなくWindowsファイル名を使用する必要があります。ただし、バック・スラッシュではなく、フォワード・スラッシュを使用する必要があります。ドライブ文字は使用できます。ただし、ドライブ文字を省略する場合は、Apacheの実行可能ファイルのドライブが適用されます。

LoadModuleディレクティブ: Windows用のApacheには、サーバーの再コンパイルを行わなくても、実行時にモジュールをロードする機能が含まれています。Apacheが正しくコンパイルされれば、\Apache2\modulesディレクトリ内にオプションのモジュールがいくつかインストールされます。これらのモジュールやその他のモジュールを起動するには、LoadModuleディレクティブを使用する必要があります。たとえば、statusモジュールを起動するには、次を使用します(access.conf内のステータス起動ディレクティブに加え)。

LoadModule status_moduleモジュール/mod_status.so

UNIXでは、ロードされたコードは通常、共有オブジェクト・ファイル(.soの拡張子)からのもので、Windowsでは.soまたは.dllの拡張子が付いています。

プロセス管理ディレクティブ: これらのディレクティブもWindows上のApacheでは異なります。

エラー・ロギング: Apacheの起動中に、エラーがWindowsイベント・ログに記録され、これがerror.logファイルのバックアップを提供します。詳細はご使用のApacheのドキュメントを参照してください。

Apacheサービス・モニター: ApacheにはApache Service Monitorユーティリティが含まれています。これによって、ネットワーク上の任意のコンピュータ上にあるインストール済のすべてのApacheサービスの状態を表示および管理できます。モニターでApacheサービスを管理するには、最初にサービスをインストール必要があります。ApacheはWindows上のサービスとして実行できます。詳細はご使用のApacheのドキュメントを参照してください。

起動、再起動、シャットダウン: Apacheをサービスとして実行する方法をお薦めします。Apacheサービスは通常、Apache Service MonitorやNET START Apache2およびNET STOP Apache2などのコマンドを使用して起動、再起動、およびシャットダウンします。標準のWindowsサービス管理も使用できます。

apacheコマンドを使用して、コマンドラインからApacheを使用できます。Control-Cを押して停止するまで、Apacheは実行を継続します。インストール中に開始メニューからApacheを実行することもできます。

注意:
Control-Cを押しても、Apacheは現在実行中の操作の終了と正常なクリーンアップを行えません。

Apacheサービス・アカウント: デフォルト設定では、すべてのApacheサービスはシステム・ユーザー(LocalSystemアカウント)として実行するように登録されています。LocalSystemアカウントには、Windowsセキュアなメカニズムによって、ネットワーク権限がありません。ただしLocalSystemアカウントは、ローカルでは広範な特権があります。1つ以上のApacheサービスを実行するための個別アカウント作成の詳細は、ご使用のApacheのドキュメントを参照してください。

Windows用のApache v2の準備手順

1. ご使用の環境が、次の場所にあるApacheのドキュメントに記載されたApache要件を満たしていることを確認してください。

http://httpd.apache.org/docs-2.0/install.html

Windowsでのインストール用に、Apache v2をダウンロード可能なHTTPおよびFTPミラーのリストがオンラインで提供されています。

次の手順を終えたら、.msiの拡張子が付いた、Windows用のApacheバージョンを必ずダウンロードしてください。

2. Apacheのドキュメントに記載された、完全な、未修正版のApache HTTP Server v2(およびOpenSSL)をダウンロードしてください。次に例を示します。

http://httpd.apache.org/download.cgi
http://www.openssl.org/

3. Apacheのドキュメントを参照して、Apache v2をインストールします(ダウンロードした.msiファイルを実行し、要求された情報を提供)。

4. .default.confファイルを検索し、新しい設定を検証し、次に必要に応じて既存の構成を更新します。

5. Apacheをコンソールウィンドウ内で、またはサービスとして起動します。

6. ブラウザを起動し、次のURLを入力してサーバーに接続詞、デフォルト・ページにアクセスします。次に例を示します。

http://localhost/

ようこそページと、Apacheマニュアルへのリンクが表示されるはずです。そうでない場合は、logsサブディレクトリ内のerror.logファイルを確認してください。

基本的なインストールが機能したら、\confサブディレクトリ内のファイルを編集して正しく構成する必要があります。

7. Apacheのドキュメントを参照して、ご使用の環境に合わせてApacheを構成します。

8. カスタマイズされた環境をテストします。

9. 必要に応じて、Apache v2およびIHS v2のリバース・プロキシの起動に進んでください。

Apache v2およびIHS v2のリバース・プロキシの起動

Apache v2およびIHS v2 powered by Apache用のWebgateは、リバース・プロキシ機能を起動している場合に、この機能をサポートします。リバース・プロキシ機能の実装手順は、ご使用の環境によって異なります。

- Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

- Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

Apache v2 Webサーバーのリバース・プロキシの起動

Oracle Access Managerでリバース・プロキシ機能を使用するには、Webサーバーに対するconfigureコマンドにApacheプロキシ・モジュールを含む必要があります。mod_proxyおよびmod_proxy_httpモジュールを、サーバーに動的にロードする必要もあります。リバース・プロキシは、ProxyPassディレクティブを使用して、またはRewriteRuleディレクティブに[P]フラグを使用して起動します。

リバース・プロキシ機能は、ProxyPassディレクティブを使用して、またはRewriteRuleディレクティブに[P]フラグを使用してアクティブにします。リバース・プロキシを構成するためにProxyRequestsを有効にする必要はありません。リバース・プロキシ(ProxyRequests Offを使用したProxyPassディレクティブ)を使用する場合、アクセス制御はそれほど問題になりません。これは、クライアントがコンタクトできるのは具体的に構成したホストのみであるためです。<Proxy>制御ブロックを使用して、プロキシへのアクセスを制御できます。

Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

1. 「ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて」を確認してください。

2. 必要に応じて、Webサーバー用のconfigureコマンドにApacheプロキシ・モジュールを含みます。
例:

--enable-proxy
--enable-proxy-connect
--enable-proxy-ftp
--enable-proxy-http

詳細は、Apacheのドキュメントを参照してください。

3. 次のようにProxyPassディレクティブを使用して、またはRewriteRuleディレクティブに[P]フラグを使用して、リバース・プロキシを起動します。

Reverse Proxy
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar

4. 次のように<Proxy>コントロール・ブロックを使用して、各自のプロキシへのアクセスを制御します。

<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>

5. まだ実施していない場合は、第27章「OAM 11gでのOAM 10g Webgateの管理」の手順を実行します。

IHS v2 Webサーバーのリバース・プロキシの起動

Webサーバーのインストール後に次の手順を使用します。

Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

1. 「ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて」を確認してください。

2. 「IHS v2 Webサーバーの準備」で説明しているように、IHS v2 Webサーバーをインストールします。

3. これらの行を(コメントなしで)次の場所にあるhttpd.confファイルのDynamic Shared Objectセクションに含んで、モジュールをロードします。
IHS_install_dir/conf/httpd.conf

LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule auth_dbm_module modules/mod_auth_dbm.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule cgid_module modules/mod_cgid.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule dir_module modules/mod_dir.so
LoadModule imap_module modules/mod_imap.so
LoadModule actions_module modules/mod_actions.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so

4. IfModule mod_proxy.cタグの下のディレクティブ--次の情報と例を使用して、次の点を確認してください。

- AllowまたはDeny条件が適切にコメント・アウトされていること。
例:

<Proxy *>
Order deny, allow
#    Deny from all
Allow from all
#   Allow from .domain.com
</Proxy>

- 保護するURLが、ProxyPassおよびProxyPassReverseディレクティブの両方に記述されていること。
例:

<IfModule mod_proxy.c>
ProxyRequests Off
ProxyPass /testproxy http://bedford: 8809/testrev/
ProxyPassReverse /testproxy http://bedford: 8809/testrev/
ProxyPass /test2 http://bedford: 8809/testrev/
ProxyPassReverse /test2 http://bedford: 8809/testrev/

5. httpd.confファイルを変更した後で、Webサーバーを再起動します。

6. テスト: プロキシURLにアクセスするには、http://<proxy_host>:80/testproxy/にアクセスします。

注意:

テスト中は、URLの最後にフォワード・スラッシュがあることを確認してください。最後にフォワード・スラッシュがないとリソースにアクセスできないことがあります。

7. リバース・プロキシ・サーバー上でSSLを有効にします。IHSデフォルト・ページのドキュメントを使用します。
たとえば、httpd.confファイルのDSOセクションのサンプルSSL設定は、ibm_ssl_moduleを次のようにロードします。

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

8. 次のディレクティブをhttpd.confファイルに含みます。

SSLEnable
Keyfile /opt/IBMIHS/bin/key.kdb
SSLClientAuth none
SSLProxyEngine on

9. サーバーを再起動します。

10. WebサーバーのURLにアクセスし、ブラウザに証明書が提示されることを確認します。

注意:
前のディレクティブをコメント・アウトしてサーバーを再起動するだけで、Webサーバーをオープン・モードに切り戻せます。

11. key.kdb: key.kdbを生成するには、IHS_install_dir/binディレクトリに提供されているikeymanユーティリティを使用します(できればGUIモードで) 。

注意:
ikeymanユーティリティはgsk7basユーティリティを使用します。ただし、gsk7basにフィックス・パックPQ83048を適用する必要があります。

12. 次の手順を実行します。

- まだ実施していない場合は、第27章「OAM 11gでのOAM 10g Webgateの管理」で説明しているとおり、OAM 11gでの10g Webgateのインストールを完了してください。

- 必要に応じて、この章に戻って、残りのタスクを実行します。

Oracle Access Manager Webgate用のhttpd.conf更新の検証

次の手順を完了して、ApacheまたはIHS v2のhttpd.confファイルに、Oracle Access Manager用のWebサーバー構成の更新が含まれていることを確認するようお薦めします。詳細は、次の項目を参照してください。

- Webgateの詳細検証

- 言語エンコーディングの検証

IHS Webサーバー上のリバース・プロキシ用httpd.confを更新するには、「IHS v2 Webサーバーのリバース・プロキシの起動」を参照してください。Webサーバー用にhttpd.confをカスタマイズするには、ご使用のWebサーバーのドキュメントを参照してください。

Webgateの詳細検証

次の例は、httpd.confファイルのWebgateセクションを示します。環境によって詳細は異なります。この例は、httpd.confでの各種変更を示すためだけに提供されています。

httpd.confのWebgateセクションの検証手順

1. Webgateをホスティングしているコンピュータ上の更新済httpd.confファイルを検索します。

2. httpd.confファイルを開き、使用しているプラットフォームのWebgateをロードするセクションがあることを確認します。
例:

Windowsの場合

#*** BEGIN Oblix NetPoint Webgate Specific ****
<IfModule mod_ssl.c>
LoadModule obWebgateModule "WebGate_install_dir\access\oblix\apps\webgate\bin\webgatessl.d ll"
WebGateInstalldir "WebGate_install_dir"
WebGateMode PEER
</IfModule>
<IfModule !mod_ssl.c>
LoadModule obWebgateModule "WebGate_install_dir\access\oblix\apps\webgate\bin\webgate.dll"
WebGateInstalldir "WebGate_install_dir"
WebGateMode PEER
</IfModule>
<Location "\oberr.cgi">
SetHandler obwebgateerr
</Location>
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
#*** END Oblix NetPoint Webgate Specific ****

UNIXの場合

#*** BEGIN Oblix NetPoint Webgate Specific ****
LoadFile "/home/qa/netpoint/703/c1-copy/wg/access/oblix/lib/libgcc_s.so.1"
LoadFile "/home/qa/netpoint/703/c1-copy/wg/access/oblix/lib/libstdc++.so.5"
<IfModule mod_ssl.c>
LoadModule obWebgateModule "/home/qa/netpoint/703/c1-copy/wg/access/oblix/ apps/webgate/bin/webgatessl.so"
</IfModule>
<IfModule !mod_ssl.c>
LoadModule obWebgateModule "/home/qa/netpoint/703/c1-copy/wg/access/oblix/ apps/webgate/bin/webgate.so"
</IfModule>
WebGateInstalldir "/home/qa/netpoint/703/c1-copy/wg/access"
WebGateMode PEER
<Location /access/oblix/apps/webgate/bin/webgate.cgi>
SetHandler obwebgateerr
</Location>
<Location "/oberr.cgi">
SetHandler obwebgateerr
</Location>
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
#*** END Oblix NetPoint Webgate Specific ****

UNIXの場合の注意点

HP-UX上でApache v2を実行する場合、共有メモリーが機能しない可能性があるので、UserまたはGroupにはnobodyを使用しないでください。かわりにご使用のログイン名をユーザー名に使用し、グループのグループを"Oblix"とします(またはユーザー名を"www"で、グループ名を"others")。HP-UX上の"www"はSolaris上の"nobody"と同じです。

HPUX 11.11上でApache v2を実行する場合、Apache httpd.confファイル内のAcceptMutexディレクティブが"fcntl"に設定されていることを確認してください。このディレクティブがない場合は、httpd.confファイル(AcceptMutex fcntl)に追加します。詳細は、http://issues.apache.org/bugzilla/show_bug.cgi?id=22484)を参照してください。

AIX上のIHSの注意点

#*** BEGIN Oblix NetPoint Webgate Specific ****
LoadModule obWebgateModule DR/oblix/apps/webgate/bin/webgate.so
WebGateInstalldir DR
WebGateMode PEER
<Location "/oberr.cgi">
SetHandler obwebgateerr
</Location>
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
#*** END Oblix NetPoint Webgate Specific ****

1. chmod -r username:groupnameディレクトリ/ファイルを使用してディレクトリまたはファイルのユーザー名およびグループ名を変更します。
この場合は、httpd.confファイル内のUserおよびGroupパラメータも変更する必要があります。

2. 詳細は、「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」を参照して、Apache v2用のOracle Access Managerの実装を終了するために必要な手順を完了してください。

重要:
httpd.confファイルからWebgate関連の変更をクリアする必要がある場合にかぎり、次の手順を使用し、改めてWebgate用のApache v2 Webサーバー構成を完了する必要があります。

httpd.conf更新を新規に開始する手順

1. 元のhttpd.confファイルをリストアして、既存のOracle Access Managerエントリを削除します。

2. 次の方法を使用して、Oracle Access Manager用のhttpd.confファイルを更新します。

- ファイルcomponent_install_dir/access/oblix/lang/LangTag/docs/config.htmを開いて、第27章「OAM 11gでのOAM 10g Webgateの管理」で説明されているとおり、手動での構成を行います。

- または、component_install_dir/access/oblix/tools/setup/InstallTools/ManageHttpConf内のManageHttpConfプログラムをオプションなしで実行して、使用方法に関する指示を出力します。

注意:
httpd.confファイル内にWebgateエントリがある状態でManageHttpConfプログラムを実行すると、エラー・メッセージが表示され、httpd.confファイルは更新されません。

3. 「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」の作業を完了してください。

言語エンコーディングの検証

前述のように、Oracle Access Manager HTMLページではUTF-8エンコーディングを使用します。ApacheベースのWebサーバーでは、管理者はHTMLページを生成しているアプリケーションが指定する文字を無効にするAddDefaultCharsetディレクティブを使用して、送信されるすべてのHTMLページにデフォルトの文字セットを指定できます。AddDefaultCharsetディレクティブがUTF-8以外の文字セットを有効にした場合、Oracle Access Manager HTMLページで文字化けが発生します。

正しい言語エンコーディングの確認手順

1. httpd.confファイルを開きます。

2. AddDefaultCharsetディレクティブを探します。

3. 次のいずれかの作業を完了し、Oracle Access Manager HTMLページのエンコーディングが正しいことを確認します。

- AddDefaultCharsetディレクティブをオフにします。

- または、AddDefaultCharsetディレクティブをコメント・アウトします。

4. httpd.confファイルを保存してWebサーバーを再起動します。

Oracle Access Manager Webgate用のOracle HTTP Serverのチューニング

Oracle HTTP Server用のOracle Access Manager Webコンポーネントをインストールしたら、次の手順を実行する必要があります。

前述のように、Oracle HTTP Server用のOracle Access Manager Webgateをインストールする前に、コンポーネントのインストールを行うユーザーに合わせて、httpd.confファイル内のユーザーとグループを変更する必要があります。

注意:
Linux上では、Oracle HTTP Server 11g用のOracle Access Manager WebgateではNPTLのみが使用され、LinuxThreadsライブラリは使用できません。この場合は、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。

Oracle Access Manager Webgate用のOracle HTTP Serverのチューニング手順

1. 通常通り、opmnをシャットダウンします。

2. opmn.xmlを探して、編集用に開きます。次に例を示します。
$oracle_home/opmn/bin/opmn.xml

3. opmn.xmlファイル内の項目を次のように調整します。

<ias-component id="HTTP_Server">
<process-type id="HTTP_Server" module-id="OHS2">
<environment>
<variable id="TMP" value="/tmp"/>
<variable id="LD_ASSUME_KERNEL" value="2.4.19"/>
</environment>
<module-data>
<category id="start-parameters">
<data id="start-mode" value="ssl-disabled"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>

4. 次のスクリプトを実行して、OPMNの構成をリフレッシュします。

#oracle_home/opmn/bin/opmnctl reload

5. 「Oracle HTTP Server Webサーバーの起動と停止」に従って、Oracle HTTP Server Webを起動します。

OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング

これらのWebサーバー用に、Oracle Access Manager Webgateの特定のチューニング・パラメータを設定することをお薦めします。

この項で説明しているチューニング・パラメータは、Apache v2.0およびOHS11gのhttpd.confファイルで構成されています。

ただしApache v2.2の場合は、次のファイルでチューニングが構成されています。

apache_install_dir/conf/extra/httpd-mpm.conf

apache_install_dir/conf/extra/httpd-default.conf

またApache v2.2では、httpd-mpm.confとhttpd-default.confのエントリは次のようにコメント・アウトは行わないでください。

前:

#Include conf/extra/httpd-mpm.conf
#Include conf/extra/httpd-default.conf

後:

Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-default.conf

それぞれの環境で必要に応じて次に進んでください。

- Oracle HTTP Server/Apache Preforkモジュールのチューニング

- Oracle HTTP Server/Apache MPMモジュールのチューニング

- カーネル・パラメータのチューニング

Oracle HTTP Server/Apache Preforkモジュールのチューニング

次の説明は、Oracle HTTP ServerまたはApache PreforkモジュールでOracle Access Managerを使用する場合の大まかなガイドラインとして使用することをお薦めします。

Timeout 300

KeepAlive On

MaxKeepAliveRequests 500

KeepAliveTimeout 10

StartServers: 5 (最初に起動するプロセスの数; 起動時のみ使用。)

MaxClients: 500 (ピーク時の負荷を処理するための合計プロセス数。ピーク時のリクエスト処理用に作成する子プロセス数を決定します。

ServerLimit: 500 (プロセス存続期間中のMaxClientsの最大構成値。MaxClientsがデフォルトよりも高い値に設定されている場合、ServerLimit値には残りのパラメータより高い値を設定する必要があります。

MinSpareServers、MaxSpareServers: デフォルト値で過度の負荷を処理するための要件を満足できるはずです。操作中は、これらの値によって、親プロセスはリクエスト処理用の子プロセス作成を規制します。

MaxRequestsPerChild: 0 - 各子プロセスに送信するリクエスト数。0はプロセスが失効しないことを示します。

Oracle HTTP Server/Apache MPMモジュールのチューニング

次の説明は、Oracle HTTP ServerまたはApache PreforkモジュールでOracle Access Managerを使用する場合の大まかなガイドラインとして使用することをお薦めします。

Timeout 300

KeepAlive On

MaxKeepAliveRequests 500

KeepAliveTimeout 10

StartServers: 2 (最初に起動するプロセスの数; 起動時のみ使用。)

MaxClients: 500 (ピーク時の負荷を処理するための合計プロセス数。ピーク時のリクエスト処理用に作成する子プロセス数を決定します。

ServerLimit: 25 (プロセス存続期間中のMaxClientsの最大構成値。MaxClientsがデフォルトよりも高い値に設定されている場合、ServerLimit値には残りのパラメータより高い値を設定する必要があります。

MinSpareServers、MaxSpareServers: 25、75。操作中は、これらの値によって、親プロセスはリクエスト処理用の子プロセス作成を規制します。

ThreadsPerChild: 25 (単一のhttpdプロセス内のワーカー・スレッド数。)

MaxRequestsPerChild: 0 (このディレクティブは、各子サーバー・プロセスが処理するリクエスト数の制限を設定します。0の値はプロセスが失効しないことを示します。)

カーネル・パラメータのチューニング

ファイル記述子のソフトおよびハード・リミットのカーネル・パラメータが、高い値に設定されていることを確認することをお薦めします。次に例を示します。

ハード・リミット(rlim_fd_max): 65535

ソフト・リミット(rlim_fd_cur): 65535

リクエスト用にソケットの開閉を行うApacheサーバーでは、ファイル記述子の値を高く設定しておくことを強くお薦めします。

Oracle HTTP Server Webサーバーの起動と停止

Oracle HTTP Server Webサーバーの起動と停止は、すべてのプラットフォーム上のv1.3とv2の両方に共通です。

Oracle HTTP Server Webサーバーの起動手順

1. 次のディレクトリを探して移動します。
$ORACLE_HOME\opmn\bin\

2. コマンドラインから、次のコマンドを入力します。

opmnctl/startproc process-type=HTTP_Server

Oracle HTTP Server Webサーバーの停止手順

1. 次のディレクトリを探して移動します。
$ORACLE_HOME\opmn\bin\

2. コマンドラインから、次のコマンドを入力します。

opmnctl/stopproc process-type=HTTP_Server

Oracle Access Manager Webgate用のApache/IHS v2のチューニング

特に明記しないかぎり、ここに記載された情報はApacheおよびIHS v2 Webgateコンポーネント(プラグインとも呼ばれている)の両方に適用されます。Oracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド10gリリース2 (10.1.2)』を参照してください。

Security-Enhanced LinuxにバンドルされたApache v2: SELinuxでは、Oracle Access Manager Webコンポーネントのインストール後に、より厳格なSELinuxポリシーが設定されたLinuxディストリビューションで、Webサーバーを起動する際に、WebServerログ/コンソールにエラーが報告されます。Webサーバーを再起動する前に、インストールされたWebコンポーネント用の適切なchconコマンドを実行することにより、これらのエラーを防止できます。

関連項目:
「SELinuxの問題」

Apache v2がバンドルされたSELinux対応のLinuxディストリビューション: Security-Enhanced Linux (SELinux)は、アクセス・コントロール・メカニズムの強制自動的に実装します。ご使用のLinuxのドキュメントにも記載されているように、SELinuxポリシーはシステム・デーモン用に、/etc/httpd/conf、/usr/sbin/apachect、および/var/log/(これはほんの一例)などの特定の事前定義済システム・ディレクトリへのアクセスを提供します。

バンドルされたApache Webサーバーを使用してOracle Access Manager Webgateをインストールした場合、ApacheのプロセスがOracle Access Managerのインストール・ファイルにアクセスできるように、特定のポリシーを追加する必要があります。

バンドルされたApache Webサーバーは、context=user_u:system_r:unconfined_tとして定義されたセキュリティ・コンテキストで、ユーザー"apache"として実行されます。その結果、Oracle Access Manager Webgateをいずれかのユーザー・フォルダにインストールすると、Apache Webサーバーは起動しません。

$SELINUX_SRC変数は、SELinuxポリシー・ソース・ディレクトリを示します。デフォルト値は/etc/selinux/targeted/src/policyです。ただし、ご使用の環境とは異なることがあります。ご使用のシステムの実際の値については、必ずシステム管理者にご相談ください。

Oracle Access ManagerのポリシーをRed Hat Enterprise Linux 4にバンドルされたApacheに追加する手順

1. 各Oracle Access Manager Webコンポーネントのインストール後、'root'ユーザーとしてログインします。

2. Webサーバーのユーザーおよびグループ(デフォルト: apache)に対して、すべてのOracle Access Manager Webgateがインストールされていることを確認します。

3. oracle_access_manager.teポリシー・ファイルを$SELINUX_SRC/domains/programs/directoryに作成し、次のルールを追加します。

type oracle_access_manager_t, file_type, sysadmfile;
allow httpd_t oracle_access_manager_t:file { rw_file_perms create rename
link unlink setattr execute };
allow httpd_t oracle_access_manager_t:dir  { rw_dir_perms create append
rename link unlink setattr };

4. oracle_access_manager.fcファイル・コンテキストを$SELINUX_SRC/file_contexts/programに作成し、Oracle Access Manager Webコンポーネントのインストール・ディレクトリを登録します(アイデンティティやアクセスの接尾辞なしで)。次に例を示します。

Oracle_Access_Manager_install_dir(/.*)? system_u:object_r:oracle_access_
manager_t

注意:
WebgateをAccess Managerとは別のディレクトリにインストールする場合、必ずWebgateインストール・ディレクトリを別に登録してください。

5. ポリシー・ファイルを次のようにコンパイルおよびデプロイします。

cd $SELINUX_SRC
make load
Label Oracle Access Manager files
run restorecon -R Oracle_Access_Manager_install_dir (without the identity or access suffix)

Apache v2ディレクティブ: Apache 1.3は複数のHTTPリクエストに同時に対応するために、プロセス・モデルを使用します。これはWebサーバーが採用している、1つのプロセスで同時に複数のリクエストを管理するシングル・プロセス(スレッド)モデルとは異なります。

注意:
Apache v2内のprefork MPMのみがApache v1.3と同様のHTTPリクエスト処理プロセス・モデルを使用しています。その他すべてのMPMでは、Apache v2はハイブリッドのプロセス・スレッド・モデルを使用しています。

Apache v2 Webサーバー構成ファイル(httpd.conf)内のいくつかのディレクティブは、Apache Webサーバーによるワーカー・プロセスの作成や破壊の決定方法に影響を及ぼします。次のパラメータはApache v2 Webサーバーのパフォーマンスに影響を及ぼします。

- ThreadsPerChild: このディレクティブは、各子プロセスが作成するスレッド数を設定します。子プロセスは起動時にこれらのスレッドを作成し、追加作成は行いません。

- 子プロセスが1つしかないmpm_winntのようなMPMを使用している場合、この値には、サーバーの全負荷を処理できるだけの高い値を設定する必要があります。

- 子プロセスが複数あるmpm_workerのようなMPMを使用している場合は、スレッドの合計数がサーバー上の共通負荷を処理できるだけの高い値になっている必要があります。

- MinSpareThreads: この値はmpm_workerのみで使用されます。Oracle Access Managerプラグインの初期化は初回リクエスト時まで延期されるので、このディレクティブを高い値で維持してもわずかな効果しか得られません。それでも、このパラメータをできるだけ高く維持しておくと便利です。

- MaxSpareThreads: この値はmpm_workerのみで使用されます。MaxSpareThreadsの値は、MinSpareThreadsとThreadsPerChildの合計と同じか、それより多い必要があり、そうなっていなければApache HTTP Serverが自動的に修正します。
推奨: 高い値を維持してください。専用サーバーの場合は、これは問題にはなりません。

- MaxSpareServers: Apache v2では、prefork MPMモデルのみで使用されます。サーバーにできるだけ多くの状態を保存するには、MaxSpareServersを高い値に設定してください。この値を最大の255に設定すると、使用可能なすべてのApacheワーカー・プロセスを維持しますが、負荷が低い期間にワーカー・プロセスのリサイクル機会が提供されません。

- MinSpareServers: Apache v2では、prefork MPMモデルのみで使用されます。Oracle Access Managerプラグインの初期化は初回リクエスト時まで延期されるので、MinSpareServersパラメータに高い値を使用してもわずかな効果しか得られません。それでも、このパラメータをできるだけ高く維持しておくと便利です。専用Webサーバー・システムの場合は、これによる負荷はそれほど多くないはずです。

- MaxClients: IHS v2とworker MPMでは、MaxClientsによってクライアントを処理するために利用可能なスレッドの合計数が制限されます。ハイブリッドMPMの場合、デフォルト値は16 (ServerLimit)に25(ThreadsPerChild)の値を乗算したものです。16プロセス以上を必要とする値にMaxClientsを増やすには、ServerLimitも増やす必要があります。

前述のパラメータに適した値は、Access ServerおよびLDAPサーバーを含む、関係しているシステムでの予想負荷とパフォーマンス・クラスによって異なります。

予想負荷が高く、非常に高いパフォーマンスのシステム上では、ワーカー・プロセス数の制限を増やして、Apacheサーバーを再コンパイルできます。これらのシステムは、突然の負荷増加に対応するために、StartServersおよびMinSpareServersパラメータへのパフォーマンスの影響が高くなることがあります。

正しく機能させるために、Access Serverのオペレーティング・システム制限を調整する必要があります。特に、いずれかのAccess Server用に提供されているファイル記述子の最大数をデフォルト値より増やす必要があります。Apacheベースの各WebgateとAccess Serverとの間に複数の接続を構成すると、この制限を即座に超える可能性があります。

詳細はご使用のApacheのドキュメントを参照してください。

アンインストール後のWebサーバー構成変更の削除

インストール中に生じたWebサーバーの構成変更は、Webgateのアンインストール後に手動で削除する必要があります。このタイプの情報は手動で削除する必要があります。

さらに、Webgate用にWebサーバー構成ファイルに対して手動で行った変更もすべて削除する必要があります。各コンポーネントに追加される内容の詳細は、この章の他の項を参照してください。

役立つ情報

Oracle HTTP Serverの詳細は、次のマニュアルを参照してください。

『Oracle HTTP Server管理者ガイド10gリリース2 (10.1.2)』

次のURLには、Apacheリリースとソース・コードの構築の詳細が提供されています。

Apache v2のドキュメント:

http://httpd.apache.org/docs-2.0/

Apache v2のソース・コード:

http://httpd.apache.org/download.cgi

Mod-SSLのドキュメント:

http://httpd.apache.org/docs-2.0/mod/mod_ssl.html

OpenSSLのドキュメント:

http://www.openssl.org/docs/

OpenSSLのソース・コード:

http://www.openssl.org/source/

Apache v2のコンパイルとインストール:

http://httpd.apache.org/docs-2.0/install.html#test

IHS:

http://www-306.ibm.com/software/webservers/httpservers/doc/v2047/manual/readme.html

29 10g Webgate用のIIS Webサーバーの構成

この章では、Microsoft Internet Information Server(Windows環境のIIS Webサーバー)を使用する10.1.4 Webgateの構成時に実行する必要があるアクティビティの概要を説明します。特に明記しないかぎり、この章の情報および手順は32ビットと64ビットのWebgateインストールに同様に適用されます。この項の内容は次のとおりです。

- 前提条件

- IIS WebサーバーでのWebgateのガイドライン

- IIS 7対応Webgateのインストールの前提条件

- Windows 2008でのIIS 7 Webサーバー構成の更新

- IISでのWebgateインストールの完了

- 1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

- 1つのIIS 6インスタンスに対する複数のWebgateのインストールと構成

- 64ビットWebgateインストールの終了

- IISへのWebgateのインストールの確認

- IIS Webサーバーの起動、停止および再起動

- アンインストール前のWebサーバー構成変更の削除

前提条件

Oracle Access Managerコンソールが稼動していること、および次の項目を理解していることを確認してください。

- ポリシーの強制エージェントの概要

- OAM 11gで使用する新規OAM 10g Webgateのインストールについて

IIS WebサーバーでのWebgateのガイドライン

ISAPIは、IIS Webサーバーと通信するWebgateのためのインターネットWebサーバーの拡張機能です。たとえば、IISに対応するOracle Access Manager Webgateをインストールするには、次のパッケージが必要です。

Oracle_Access_Manager10_1_4_3_0_Win32_ISAPI_Webgate

64ビットWebgate: Oracle_Access_Manager10_1_4_3_0_Win64_ISAPI_Webgate.exe

Oracle Access Manager Webgateをインストールするときは、IIS Webサーバーの構成ファイルを更新する必要があります。IIS Webサーバー使用時の構成の更新には、ISAPIフィルタを追加してOracle Access Managerに必要な拡張機能を作成することにより、直接Webサーバーを更新することが含まれます。フィルタは、そのフィルタがインストールされたサイトへのリクエストをすべてリッスンします。フィルタは、IISの機能を強化するために、受信データ・ストリームと送信データ・ストリームの両方を調べて変更できます。ISAPI拡張機能は、IISにより制御されるプロセスへロードされるDLLとして実装されます。ASPやHTMLのページと同様に、IISでは、ファイル・システム内でDLLファイルの仮想的な場所が使用され、IIS提供のURLネームスペースにISAPI拡張機能がマップされます。

IIS Webサーバー構成ファイルは、Oracle Access Manager Webコンポーネントのインストール中に自動的に更新することをお薦めします。自動更新には数分以上かかることがあります。一方、IIS Webサーバー構成ファイルの手動更新は自動更新より時間がかかり、意図しないエラーが発生する場合があります。

詳細なガイドラインは、次を参照してください。

- ISAPI Webgateのガイドライン

- IIS 7対応10g Webgateのインストールの前提条件

- IIS 7対応32ビットWebgateのインストールの前提条件

ISAPI Webgateのガイドライン

Webgateの一般的な準備とインストールの詳細が、ISAPI Webgateに適用されます。加えて、ここでは、IIS Webサーバーに対してインストールされるISAPI Webgate固有のガイドラインを説明します。1つのIIS Webサーバーに対して複数のWebgateをインストールすることが可能で、場合によっては64ビットのWebgateも使用できます。

注意:
特に明記しないかぎり、詳細は32ビットと64ビットのWebgateに同様に適用されます。

ロックダウン・モード: Webgateをインストールする前に、IIS Webサーバーがロックダウン・モードではないことを確認します。ロックダウン・モードの場合は、正常に作動しているように見えても、サーバーがリブートされてメタベースが再初期化されると、IISがロックダウン後に発生したアクティビティを無視するようになります。

権限: IIS Webgateのために/accessディレクトリに関する様々な権限の設定が必要になるのは、NTFSをサポートするファイル・システムにインストールしている場合のみです。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータで、簡易または証明書モードでISAPI Webgateをインストールすると仮定します。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。

仮想ホスト: 各IIS仮想Webサーバーには、独自のWebgate.dllファイルを仮想レベルでインストールするか、全サイトに影響を与える1つのWebgateをサイト・レベルでインストールできます。Webgate.dllをサイト・レベルでインストールしてすべての仮想ホストを制御するか、Webgate.dllを1つまたはすべての仮想ホストに対してインストールします。

postgate.dll: また、場合によってはコンピュータ・レベルにpostgate.dllファイルをインストールする必要もあります。「ポストゲートISAPIフィルタのインストール」で説明しているように、postgate.dllは\Webgate_install_dirにあります。複数インストールすると、このファイルの複数のバージョンが作成され、Oracle Access Managerの動作が異常になることがあります。この場合は、webgate.dllとpostgate.dllが1つずつ存在していることを検証する必要があります。

注意:
postgate.dllは常にサイト・レベルでインストールされます。なんらかの理由でWebgateを再インストールすると、postgate.dllも再インストールされます。この場合、サイト・レベルにはpostgate.dllが1つのみ存在するようにしてください。

Webgate用のWebサーバー構成の更新: 他のOracle Access Manager Webgateの場合と同じく、WebサーバーがWebgateと連動するように構成する必要があります。Oracleはインストール中にWebサーバー構成を自動的に構成することをお薦めします。ただし、「OAM 11gでの10g Webgateのプロビジョニング」で説明されているとおり、自動更新を行わずにWebサーバーを手動で構成することもできます。

FAT32ファイル・システム: Webgateのインストール中に実行する必要がある特別な指示を受け取る場合があります。たとえば、NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示は無視してください。

SSLおよびクライアント証明書認証: IISでクライアント証明書認証を使用している場合は、Webgateに対してクライアント証明書を有効にする前に、WebgateをホストするIIS WebサーバーでSSLを有効にする必要があります。また、様々なフィルタが特定の順序でインストールされていることも確認する必要があります。また、場合によってはISAPIフィルタとしてpostgate.dllをインストールする必要もあります。

Webサーバーのリリース: この章のWebサーバーの詳細は、記載のリリースに適用されます。リリースが示されない場合は、IIS v5とみなすことができます。IIS v6またはIIS v7固有の詳細はリリースが明記されます。

関連項目:

- IIS v7対応Webgate

- IIS v6対応Webgate

32ビットおよび64ビットのWebgate: 特に明記しないかぎり、すべての情報は32ビットと64ビットのWebgateに同様に適用されます。

関連項目:

- IIS v6対応Webgate

- 64ビットWebgateインストールの終了

Webgateの一般的な準備とインストールの詳細: IIS固有のガイドラインはこの章を参照してください。一般的な準備とインストールの詳細は、第27章を参照してください。

Webgateインストールの完了と確認: ISAPI WebgateとIISのバージョンに対応するタスクを実行します。

関連項目:

- IISでのWebgateインストールの完了

- 64ビットWebgateインストールの終了

- IISへのWebgateのインストールの確認

IIS v7対応Webgate

通常、一般的なガイドラインとWebgateのインストール方法は、WebgateをインストールするIISのリリースに関係なく同じです。ただし、IIS v7に対して1つ以上のWebgateをインストールしているときは、次に示す特定のトピックを確認してください。

- IIS 7対応Webgateのインストールの前提条件

- Windows 2008でのIIS 7 Webサーバー構成の更新

- 1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

IIS v6対応Webgate

通常、一般的なガイドラインとWebgateのインストール方法は、WebgateをインストールするIISのリリースに関係なく同じです。ただし、いくつかの点に注意してください。

1つのIIS 6インスタンスに対する複数のWebgate: IIS v6.0では、複数のWebサイトを1つのWebサーバー・インスタンスでホストすることがサポートされており、Oracle Access Manager ISAPI Webgateを使用すると、異なるWebgateを使用する各Webサイトを保護できます。

関連項目:
1つのIIS 6インスタンスに対する複数のWebgate

64ビットIIS v6 Webgate: 第27章の手順を使用して、他のすべての場合のようにインストールを実行します。Webgateのインストール中にWebサーバーの手動構成を選択した場合は、次のパスで詳細を入手できます。

Webgate_install_dir\access\oblix\lang\en-us\docs\dotnet_isapi.htm

WebgateのインストールとIISの構成の後で、「64ビットWebgateインストールの終了」のタスクを実行します。

Webgateの以前のリリースのインストール: これまで、Policy Managerと同じ物理ディレクトリの場所にWebgateをインストールするようお薦めしていました。これには、ポリシー・マネージャとWebgateに対して「access」という名前の仮想ディレクトリ(ポリシー・マネージャとWebgateの物理的な場所へマップ)が必要でした。

注意:
IIS対応のWebgate 10g(10.1.4.3)は、ポリシー・マネージャの場所とは別の任意の場所にインストールできます。

以前にインストールしたWebgateとポリシー・マネージャの組合せがある場合、次の手順でこれらのコンポーネントを分離できます。

以前にインストールしたWebgate/ポリシー・マネージャを分離する手順

1. 以前のWebgateとポリシー・マネージャに適用されたパッチがあればアンインストールします。

2. 以前のポリシー・マネージャとWebgateの組合せをアンインストールします。

3. ポリシー・マネージャ10g(10.1.4.3)をインストールします。

4. 別のディレクトリの場所に、Webgate 10g(10.1.4.3)をインストールします。

1つのIIS 6インスタンスに対する複数のWebgate

特に明記しないかぎり、この項の詳細は32ビットと64ビットのWebgateに同様に適用されます。

IIS v6.0では、複数のWebサイトを1つのWebサーバーでホストすることがサポートされており、Oracle Access Manager ISAPI Webgateを使用すると、異なるWebgateを使用する各Webサイトを保護できます。

注意:
ISAPI Webgateの以前のリリースでは、1つのIIS Webサーバー・インスタンスに対する複数のWebgateはサポートされていませんでした。上位レベルのすべてのWebサイトに1つのWebgateをインストールするか、Webサイト・レベルでWebgateを構成して1つのWebサイトを保護する必要がありました。

IIS 6では、仮想サーバーの実行に使用されるアプリケーション・プールが提供されます。アプリケーション・プールは、ワーカー・プロセスまたはワーカー・プロセスのセットによって処理される1つ以上のURLのグループと考えることができます。アプリケーション・プールは、1つ以上のアプリケーションが1つ以上のワーカー・プロセスのセットにリンクされる構成です。アプリケーション・プールにあるアプリケーションは、ワーカー・プロセスの境界によって他のアプリケーションと切り離されるため、あるアプリケーション・プールのアプリケーションで問題が発生しても、他のアプリケーション・プールのアプリケーションには影響しません。現在、Webgateの各インスタンスは個別のプロセス領域で実行できます。

1つのIIS v6.0 Webサーバー・インスタンス上に複数のWebサイトがある場合、ユーザーのリクエストが正しいWebサイトに到達する必要があります。このためには、次に示す3つの一意の識別子のうち少なくとも1つを使用して、サーバー上の各サイトに一意のIDを構成する必要があります。

- ホスト・ヘッダー名

- IPアドレス

- TCPポート番号

注意:
1つのサーバー上に複数のWebサイトがあり、これらをIPアドレスとポートで識別する場合、複数のWebgateは必要ありません。10.1.4.2.0のリリースから、ApacheおよびIIS 6.0上で仮想ホストが使用できるようになりました。このため、上位レベルにWebgateが1つあれば、IPアドレスが異なっていてもすべてのWebサイトを保護できます。これは、Webサイトごとに異なるホスト識別子を使用して処理されます。

同じIIS Webサーバー・インスタンスの各Webサイトに対してそれぞれWebgateをインストールできます。ただし、手動でいくつかの手順を行う必要があります。

関連項目:
「1つのIIS 6インスタンスに対する複数のWebgateのインストールと構成」

IIS 7対応Webgateのインストールの前提条件

この項では、IIS v7 Webサーバーに対してWebgateをインストールするための前提条件を説明します。内容は次のとおりです。

- IIS 7対応10g Webgateのインストールの前提条件

- IIS 7対応32ビットWebgateのインストールの前提条件

IIS 7対応10g Webgateのインストールの前提条件

次の手順は32ビットと64ビットのWebgateに同様に適用されます。

IIS v7 Webサーバー対応のWebgateでは、<add segment="bin"/>エントリがapplicationHost.configファイルに含まれない場合にかぎり、パススルー機能を有効にせずにフォームベースの認証を使用できます。たとえば、フォームベース認証スキームのアクションとしてaccess/oblix/apps/webgate/bin/webgate.dllがある場合は、<add segment="bin"/>エントリがapplicationHost.configファイルに含まれないことを確認します。このエントリが存在する場合は、次の説明に従って削除する必要があります。

<add segment="bin"/>エントリを探して削除する手順

1. Windows\System32\inetsrv\config and open the applicationHost.configファイルに移動します。

2. <hiddenSegments>モジュールを検索します。

3. エントリ<add segment="bin"/>が存在する場合は削除します。

4. ファイルを保存します。

IIS 7対応32ビットWebgateのインストールの前提条件

次の手順は32ビットWebgateのみに適用されます。

次の手順は、簡易または証明書トランスポート・セキュリティ・モードを使用するためにIIS 7 Webサーバー対応32ビットWebgateを構成する方法です。この構成では、IIS 6管理機能モジュールをインストールする必要があります。

IIS 7対応32ビットWebgateと簡易または証明書セキュリティのためにIIS 6管理機能モジュールを追加する手順

1. 「スタート」メニューから「管理ツール」をクリックし、「Server Manager」をクリックします。

2. 「Server Manager」ツリーで「Roles」を開き、「Web Server (IIS)」をクリックします。

3. 「Web Server (IIS)」ペインの「Role Services」セクションで「Add Role Services」をクリックします。

4. Add Role Servicesウィザードの「Select Role Services」ページで、「Management Tools」の下にある「IIS6 Management Compatibility」をクリックします。

5. 「Confirm Installation Selections」ページで「Install」をクリックします。

6. 「Results」ページで「Close」をクリックします。

Windows 2008でのIIS 7 Webサーバー構成の更新

Oracle Access Manager Webgateインストール時にWebサーバーの自動更新を選択しない場合は、次の手順を表示できます。

ISAPI WebgateのためにWindows 2008でのIIS 7 Webサーバーの構成手順を表示する手順

1. Webgateをインストールするとき、自動Webサーバー更新が必要かどうかを尋ねられたら「いいえ」をクリックします。

1. Webgate用にWebサーバーを手動で設定するのに役立つ情報を新しい画面で読みます。

2. 表示される表の次の項目をクリックして、表示される手順を実行します。

表29-1 IIS 7 Webgate Windows Server 2008

サポート対象サーバーのOS

Microsoft IIS

Windows Server 2008

ISAPI

...

...

2. Windows 2008でIIS 7 Webサーバーを更新する手順を実行したら、Webgateのインストール画面に戻って、Webgateインストールに関する章で説明されているように「次へ」をクリックします。

3. 「IISでのWebgateインストールの完了」に進みます。

IISでのWebgateインストールの完了

特に明記しないかぎり、この項の詳細は32ビットと64ビットのWebgateに同様に適用されます。

関連項目:

必要であれば次の項目を参照してください。

- 64ビットWebgateインストールの終了

- 1つのIIS 6インスタンスに対する複数のWebgateのインストールと構成

IIS v7を使用する場合は、次の項目を参照することをお薦めします。

- Windows 2008でのIIS 7 Webサーバー構成の更新

- 1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

IIS WebサーバーでのWebgateインストールを完了するには、インストール終了後に次のアクティビティを行います。

タスクの概要: IIS Webgateインストールの完了

1. IIS Webサーバーでのクライアント証明書認証の有効化

2. ISAPIフィルタの並替え

3. POSTデータのパススルー機能の有効化

4. デフォルト・サイトが設定されていない場合のWebサイトの保護

IIS Webサーバーでのクライアント証明書認証の有効化

特に明記しないかぎり、この項の詳細は32ビットと64ビットのWebgateに同様に適用されます。

クライアント証明書認証を使用する場合は、IIS WebサーバーでSSLを有効にする必要があります。設定時にクライアント証明書認証を選択した場合は、ISAPIフィルタの1つとしてcert_authn.dllを追加することも必要です。

注意:
この項の手順はIIS v5用の手順です。環境によっては異なることがあります。

IIS WebサーバーでSSLを有効化する手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Information Services」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. デフォルトWebサイト(または適切なWebサイト)を開き、\access\oblix\apps\webgate\binを開きます。

4. cert_authn.dllを右クリックし、「Properties」を選択します。

5. 「Properties」パネルで「File Security」タブを選択します。

6. 「Secure Communications」サブパネルで「Edit」をクリックします。

7. 「Client Certificate Authentication」サブパネルで「Accept Certificates」をクリックし、「OK」をクリックします。

8. cert_authn.dllの「Properties」パネルで「OK」をクリックします。

9. 次の手順、「ISAPIフィルタとしてcert_authn.dllを追加する手順」に進みます。

ISAPIフィルタとしてcert_authn.dllを追加する手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Information Services」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. 適切なWebサイトを右クリックして、「Properties」パネルを表示します。

4. 「ISAPI Filters」タブをクリックして、「Add」ボタンをクリックし、「Filter Properties」パネルを表示します。

5. フィルタ名としてcert_authnと入力します。

6. 「Browse」ボタンをクリックし、次のディレクトリにナビゲートします。
\Webgate_install_dir\access\oblix\apps\webgate\bin

7. cert_authn.dllを実行可能ファイルとして選択します。

8. 「Filter Properties」パネルで「OK」をクリックします。

9. 「ISAPI Filters」パネルで「Apply」をクリックします。

10. 「OK」をクリックします。

11. フィルタが正しい順序で表示されていることを確認します。

ISAPIフィルタの並替え

特に明記しないかぎり、この項の詳細は32ビットと64ビットのWebgateに同様に適用されます。

Webgate ISAPIフィルタが正しい順序で組み込まれるように確認することが重要です。

注意:
このタスクは、IIS Webサーバー・インスタンスごとにインストールするWebgateの数に関係なく同じです。

Webgate ISAPIフィルタを並べ替える手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Information Services」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. Webサイトを右クリックし、「Properties」を選択します。

4. 「Properties」をクリックし、ISAPIフィルタを選択します。

5. 次の.dllファイルが表示されることを確認します。
次に例を示します。

cert_authn.dll webgate.dll

6. 表示されていないフィルタを追加し、必要であれば、フィルタ名を選択して上下の矢印を使用し、手順5の表示のようにフィルタの順序を変更します。

警告:

webgate.dllとpostgate.dllフィルタがそれぞれ1つのみあることを確認します。1つのコンピュータで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにOracle Access Managerの動作に異常が現れる可能性があります。

POSTデータのパススルー機能の有効化

この項では、IIS 6.0のワーカー・プロセス分離モードに関連してWebgateを設定する方法を説明します。また、IIS 5.0分離モードで実行するIIS 6.0のために必要な構成手順も扱います。

注意:
この項は、『Oracle Access Managerインストレーション・ガイド10g』のIIS Webサーバーでのpostgate.dllのインストールに関する項の情報よりも優先されます。IIS 5.0 Webサーバーでは、postgate.dllを使用する既存の機能が引き続きサポートされます。

次の項目について説明します。

- ISAPI Webgate 10.1.4.2.3について

- POSTデータのパススルー機能について

- パススルーの実装: ワーカー・プロセス分離モードのIIS 6.0

- IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルーの実装

ISAPI Webgate 10.1.4.2.3について

ISAPI Webgateリリース10.1.4.2.3以上では、ワーカー・プロセス分離モードで実行するIIS 6.0に対するOracle Access Managerパススルー機能がサポートされています。ISAPI Webgate 10.1.4.2.3は、postgate.dllを使用してIIS 5.0分離モードで実行するIIS 6.0でも稼動します。

注意:
新しい実装または既存の実装でのワーカー・プロセス分離モードの使用をお薦めします。ワーカー・プロセス分離モードはIIS 6.0 Webサーバーのデフォルト設定です。IIS 5.0 Webサーバーでは、(postgate.dllを使用する)既存の機能が引き続きサポートされます。

この項では、IIS 6.0のワーカー・プロセス分離モードに関連してISAPI Webgateリリース10.1.4.2.3を設定する方法を説明します。また、IIS 5.0分離モードで実行するIIS 6.0のために必要な構成手順も示します。この項は、『Oracle Access Managerインストレーション・ガイド』の19-6項(IIS Webサーバーでのpostgate.dllのインストールに関する項)の情報よりも優先されます。

POSTデータのパススルー機能について

Webgate拡張メソッド(Webgateがフォームのアクションの場合)を使用しているとき、IIS Webサーバーでのフォーム・ログイン中は、パススルーのためにPOSTデータが必要です。つまり、IIS Webサーバー上のフォーム認証スキームがパススルー・オプションにより構成され、ログイン・フォームのターゲットがフォームによりポストされたデータを必要とする場合、Webgate拡張メソッド(Webgate DLLがフォームのアクションの場合)は使用できません。かわりに、Webgateのフィルタ・メソッド(フォームのアクションがWebgate DLLでない保護されたURLの場合)を使用する必要があり、IISのバージョンに基づいて、postgate.dllをインストールするか、webgate.dllをISAPI拡張機能として構成する必要があります。

ワーカー・プロセス分離モードのIIS 6.0: パススルー機能を実現するために、webgate.dllをISAPIフィルタおよびISAPI拡張機能としても構成する必要があります。(これは、ISAサーバー統合には適用されません。)パススルー機能は10.1.4.2.3以上のISAPI Webgateでサポートされます。ただし、アクセス・システム・コンソールのWebgate構成プロファイルで、新しいユーザー定義パラメータUseWebGateExtForPassthroughをtrueに設定することも必要です。

IIS 5.0分離モードで実行するIIS 5.0またはIIS 6.0: パススルー機能を実現するためにはpostgate.dllをISAPIフィルタとして構成する必要があります。

パススルーの実装: ワーカー・プロセス分離モードのIIS 6.0

このタスクは次の手順で説明します。

タスクの概要: ワーカー・プロセス分離モードのIIS 6.0 Webサーバーでのパススルー機能の実装

1. 「OAM 11g用の最新OAM 10g Webgateの検索およびインストール」の説明に従ってWebgateをインストールします。

2. 「WebgateプロファイルでのUseWebGateExtForPassthroughパラメータの設定」の説明に従ってパススルーのパラメータを設定します。

3. 「ISAPI拡張機能としてのwebgate.dllの構成」の説明に従ってwebgate.dllを構成します。

WebgateプロファイルでのUseWebGateExtForPassthroughパラメータの設定

ワーカー・プロセス分離モードのIIS 6.0 Webサーバーにパススルー機能を実装するには、Webgateプロファイルで新しいユーザー定義パラメータUseWebGateExtForPassthroughを設定する必要があります。UseWebGateExtForPassthroughをtrueに設定する必要があります。このパラメータをfalseに設定すると、パススルー機能は作動しません。

関連項目:
「IIS Webサーバーの問題」

WebgateプロファイルでUseWebGateExtForPassthroughパラメータを設定する手順

1. アクセス・システム・コンソールを起動して、「アクセス・システム構成」をクリックします。

2. 「アクセス・ゲート構成」をクリックします。

3. Webgateの選択基準を入力し、「実行」をクリックします。

4. 「検索結果」表でWebgate名をクリックします。

5. 「アクセス・ゲートの詳細」の下部にある「変更」をクリックします。

6. 「アクセス・ゲートの変更」ページの「ユーザー定義パラメータ」セクションに次のパラメータと値を入力し、「追加」ボタンをクリックします。
パラメータ: UseWebGateExtForPassthrough

値: true

7. さらにユーザー定義パラメータを追加する場合は「追加」ボタンをクリックします。

8. 「保存」をクリックしてこの情報を保存します。

9. デプロイメント内の各Webgateに対して手順を繰り返します。

10. 「ISAPI拡張機能としてのwebgate.dllの構成」に進みます。

ISAPI拡張機能としてのwebgate.dllの構成

webgate.dllはWebgateインストールに含まれます。次の手順では、webgate.dllをISAPI拡張機能として構成する方法を説明します。ワーカー・プロセス分離モードのIIS 6.0 Webサーバーにパススルー機能を実装する場合も、このタスクを実行する必要があります。

注意:
上位レベルのWebサイトとは別のWebサイト・レベルに複数のwebgate.dllを構成できます。その場合も、Webgateで保護される各Webサイトでwebgate.dllをISAPI拡張機能として構成する必要があります。

ISAPI拡張機能としてwebgate.dllを構成する手順

1. 「websites」に移動して右クリックし、「Properties」を選択します。

2. 「Properties」ダイアログ・ボックスで「Home Directory」タブを選択します。

3. 「Configurations」ボタンをクリックして「Application Configurations」ダイアログ・ボックスを開きます。

4. 「Wild Card Application Maps」で「Inset」ボタンをクリックします。

5. webgate.dllのパスを指定します。次に例を示します。

Webgate_install_dir/access/oblix/apps/webgate/bin/webgate.dll

6. 「verify that file exists」チェック・ボックスを選択解除します。

7. 変更を確認して最終決定します。「OK」をクリックして再び「OK」をクリックします。または、「Apply」をクリックしてから「OK」をクリックします。

8. 「Services」でIIS管理サーバーを停止し、IIS Webサーバーを再起動します。

IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルーの実装

このタスクは次の手順で説明します。

注意:
ワーカー・プロセス分離モードのIIS 6.0 Webサーバーを使用している場合、このタスクは実行しません。

タスクの概要: IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルー機能の実装

1. 第27章「OAM 11gでのOAM 10g Webgateの管理」の説明に従ってWebgateをインストールします。

2. 「IIS 5.0分離モードのIIS 6.0 Webサーバーの設定」の説明に従ってIIS 6.0を設定します。

3. 「ポストゲートISAPIフィルタのインストール」の説明に従ってpostgate.dllをインストールします。

IIS 5.0分離モードのIIS 6.0 Webサーバーの設定

次の情報は10.1.4.2.3 Webgateに対応するように更新されています。

IIS 6.0 Webサーバーが使用されるときに、IIS 5.0分離モードで実行するようにWWWサービスを設定する方法を次の手順で説明します。これはISAPI postgateフィルタで必要です。

IIS 6 WebサーバーでIIS 5.0分離を設定する手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Information Services」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. Webサイトを右クリックし、「Properties」を選択します。

4. 「Web Site Properties」ウィンドウで「Service」タブを選択します。

5. 「Run WWW service in IIS 5.0 Isolation Mode」の横のボックスを選択します。

6. 「OK」をクリックします。

7. 「ポストゲートISAPIフィルタのインストール」に進みます。

ポストゲートISAPIフィルタのインストール

次の情報は10.1.4.2.3 Webgateに対応するように更新されています。

1つのWebgateインストールの場合、次の順序でフィルタをインストールする必要があります。

- ISAPI Webgateフィルタは、sspifiltフィルタの後で、他のフィルタの前にインストールする必要があります。

- postgateフィルタは、Webgateフィルタの前にインストールする必要があります(必要な場合のみ)。

- その他すべてのOracle Access Managerフィルタは最後にインストールできます。

注意:
インストールの前(またはインストールの後)には、フィルタを手動で削除する必要があります。1つのフィルタを複数インストールした場合、新しいフィルタをインストール前に手動で削除できません。

上位レベルのWebサイトとは別のレベルに複数のwebgate.dllを構成できます。ただし、それらは同じpostgate.dllを共有します。1つのコンピュータで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにOracle Access Managerの動作に異常が現れる可能性があります。コンピュータの(上位)Webサイト・レベルに構成できるpostgate.dllは1つのみです。

注意:
1つのIIS Webサーバー・インスタンスに対して複数のWebgateをインストールして構成しているとき、postgate.dllはサポートされません。

次の手順では、1つのWebgateを1つのIIS Webサーバー・インスタンスにインストールしている場合の、postgate ISAPIフィルタのインストールと配置について説明します。

ポストゲートISAPIフィルタをインストールする手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Information Services」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. Webサイトを右クリックし、「Properties」を選択します。

4. 「Web Site Properties」ウィンドウで「ISAPI Filters」タブを選択します。

5. 「Add」ボタンをクリックして、「Filter Properties」パネルを表示します。

6. フィルタ名としてpostgateと入力します。

7. 「Browse」ボタンをクリックし、次のディレクトリにナビゲートします。
\Webgate_install_dir\access\oblix\apps\webgate\bin

8. postgate.dllを実行可能ファイルとして選択します。

9. 「Filter Properties」パネルで「OK」をクリックします。

10. 「ISAPI Filters」パネルで「Apply」をクリックします。

11. 次のようにして、ポストゲートISAPIフィルタの位置を変更します。

1. 必要な場合、「Internet Information Services」コンソールを起動します。

2. ローカル・コンピュータを右クリックし、「All Tasks」、「Restart IIS」を順に選択します。

3. 「Properties」パネルで「ISAPI Filters」タブを選択します。

4. postgateフィルタを選択し、上矢印を使用して、Webgateの前に移動します。
次に例を示します。

postgate.dll webgate.dll

5. IISを再起動します。

注意:
メタベースが破損しないようにするためにnet stop iisadminおよびnet start w3svcの使用を検討します。

デフォルト・サイトが設定されていない場合のWebサイトの保護

特に明記しないかぎり、この項は32ビットと64ビットのWebgateに同様に適用されます。

関連項目:
「アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証の設定」

既定のWebサイトが構成されていないIIS Webサーバー上にWebgateをインストールする場合、インストーラは仮想ディレクトリのアクセスを作成しません。これは、次の手順を使用して手動で実行する必要があります。

Webサイト(デフォルト・サイトではない)の保護の手順

1. 必要に応じて、「Internet Information Services」コンソールを開始します。

2. 保護するWebサイトの名前を選択します。

3. 保護するWebサイトの名前を右クリックして、メニューの「New」→「Virtual Directory」を選択します。

4. 「次へ」をクリックします。

5. 「Alias」としてaccessを選択して、「Next」をクリックします。

6. 「Directory」: /accessディレクトリへの完全パスを入力してから、「Next」をクリックします。
Webgate_install_dir\access

7. 「Read」、「Run Scripts」および「Execute」を選択してから、「Next」をクリックします。

8. 「完了」をクリックします。

9. IISを再起動します。次に例を示します。
「スタート」、「ファイル名を指定して実行」の順に選択します。
net start w3svcと入力します。
「OK」をクリックします。

1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

この項では、同一IIS 7 Webサーバー・インスタンス上の異なるWebサイトに複数のWebgateをインストールして構成する方法を説明します。いくつかの手順は手動で行い、1つのIISインスタンスに1つのWebgateをインストールする際に実行する手順とは異なります。1つのIISインスタンスに対して複数のWebgateをインストールする場合、次のようになります。

- webgate.dllは、デフォルト(上位)Webサーバー・レベルではなく個々のWebサイト・レベルでISAPIフィルタとして構成する必要があります。

- /access仮想ディレクトリは、Webサイト・レベルで、Webgateインストールのそれぞれの/accessディレクトリにマップされます。

複数のWebgateの偽装DLLを構成する場合、オペレーティング・システムとして機能するようにユーザーを構成する必要があります。

タスクの概要: 1つのIIS 7インスタンスに対する複数のWebgateのインストールと構成

1. 複数のWebgateシナリオにおける各IIS 7 Webgateのインストール

2. 複数のIIS 7 Webgateに対する偽装DLLの設定

3. 複数のIIS 7 Webgateに対するクライアント認証の有効化

4. パススルー機能のためのIIS 7 Webgateの構成

5. IIS 7 Webgateのインストールの確認

6. 次のタスクを実行します。このタスクはIIS Webサーバー・インスタンスごとにインストールするWebgateの数に関係なく同じです。

- 「ISAPIフィルタの並替え」

- 「IISへのWebgateのインストールの確認」

関連項目:
「複数のWebgateのインストールの確認」

複数のWebgateシナリオにおける各IIS 7 Webgateのインストール

ISAPI Webgateをインストールした後で、次に説明する手動の手順をいくつか実行します。

デフォルトでは、webgate.dllはホスト名(上位)レベルでISAPIフィルタとして構成されます。複数のWebgateを1つのIIS 7インスタンスに対してインストールしているときは、各Webgateインストールの後で、上位レベルからそれぞれのwebgate.dllを削除して、個々の適切なWebサイトで構成する必要があります。

1つのIIS 7インスタンスに対して複数のWebgateがある場合に各Webgateをインストールする手順

1. 第27章の説明に従ってISAPI 7 Webgateをインストールします。

2. 保護するWebサイトに移動し、次の手順を使用してwebgate.dllをISAPIフィルタとして構成します。

1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 「Connections」ペインでhostnameを選択します。

3. hostnameの「Home」ペインで「ISAPI Filters」をダブルクリックし、Webgate.dllを検索します。存在する場合は選択して、「Action」ペインの「Remove」をクリックします。

4. 「Connection」ペインの「Sites」の下で、Webgateフィルタを構成するWebサイト名をクリックします。

5. 「Home」ペインで「ISAPI Filters」をダブルクリックします。

6. 「Actions」ペインで「Add…」をクリックします。

7. 「Add ISAPI Filter」ダイアログ・ボックスの「Filter name」テキスト・ボックスに、ISAPIフィルタの名前としてWebgateと入力します。

8. 「Executable」ボックスにWebgate ISAPIフィルタ・ファイルのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてWebgate.dll ISAPIフィルタ・ファイルを含むフォルダに移動し、「OK」をクリックします。

Webgate_install_dir\access\oblix\apps\webgate\bin\webgate.dll

3. 仮想ディレクトリの作成:

1. 「Sites」ペインを開き、ISAPIフィルタ(Webgate.dll)を構成したばかりのWebサイトを選択します。

2. 「Action」ペインで「View Virtual Directories」をクリックし、「Add Virtual Directory」を選択します。

3. 「Alias」テキスト・ボックスにaccessを指定し、Webgateのaccessフォルダの物理パスを指定するか、省略記号(...)をクリックしてaccessフォルダに移動して「OK」をクリックします。

Webgate_install_dir\access\

4. これらの変更を保存して適用します。

4. 仮想ディレクトリの権限の設定:

1. 手順3で作成したaccess仮想ディレクトリを選択します。

2. accessの「Home」ペインで「Handler Mappings」をダブルクリックします。「Action」ペインで「Edit Feature Permissions…」を選択します。

3. 「Read」、「Script」および「Execute」の横のボックスを選択してから、「OK」をクリックします。

5. Webgateのディレクトリ権限の設定:

1. エクスプローラで、Webgateインストール・ディレクトリWebgate_install_dir\accessを右クリックし、「プロパティ」を選択します。

2. 「セキュリティ」タブをクリックし、「編集」ボタンをクリックします。

3. ユーザー「IUSR」を追加し、「変更」について「許可」を選択します。

4. ユーザー「IIS_IUSRS」を追加し、「変更」について「許可」を選択します。

5. ユーザー「NETWORK」を追加し、「変更」について「許可」を選択します。

6. ユーザー「NETWORK SERVICE」を追加し、「変更」について「許可」を選択します。

7. グループ「Administrators」では、「変更」について「許可」を選択します。

6. 簡易モードまたは証明書モードのWebgate:

1. ファイル・システムで、Webgate_install_dir\access\oblix\config\password.xmlのpassword.xmlファイルを探して右クリックし、「プロパティ」を選択します。

2. 「セキュリティ」タブをクリックします。

3. 「読み取り」権限の「許可」をユーザー「IUSR」、「NETWORK SERVICE」、「IIS_WPG」、「IIS_IUSRS」に指定します。

7. 上位レベル(hostnameのレベル)にはwebgate.dllがないことを確認します。

8. 次の項目の手順に従い次の一連のタスクを実行します。

1. 「複数のIIS 7 Webgateに対する偽装DLLの設定」

2. 「複数のIIS 7 Webgateに対するクライアント認証の有効化」

9. IISインスタンスに対して次のWebgateをインストールするには、これらの手順を繰り返します。

複数のIIS 7 Webgateに対する偽装DLLの設定

クライアントのアクセス・トークンは偽装トークンとも呼ばれます。偽装トークンでは、クライアント、クライアントのグループおよびクライアントの権限が識別されます。トークン内の情報は、スレッドがクライアントのかわりにリソースへのアクセスをリクエストする際に、アクセス・チェックに使用されます。

アクセス・システムによってユーザーの認証および認可が行われます。ワイルドカード拡張機能のOAMのIISImpersonationExtension.dllは、Webサーバーへの各リクエストのフィルタのように機能します。アクセス・システムでは、「アクセス・ゲート構成」ページの偽装ユーザー名/パスワードを使用して、別のユーザーを偽装する権限を持つ特別なユーザーを構成することでユーザーを指定します。指定されたユーザーにはオペレーティング・システムとして機能する権限が必要です。DLLは、Oracle Access Managerによって認証および認可されたユーザーを偽装し、偽装トークンを生成します。

次の手順を実行し、1つのIIS 7 Webサーバー・インスタンスのWebサイトを保護する各Webgateに偽装DLLを設定します。これは、前述の項のインストール・タスクの直後に行うことも、まとめて一度に実行することもできます。

注意:
このタスクは、1つのIIS Webサーバー・インスタンスの個々のWebサイトを保護する各Webgateに対して実行する必要があります。

個々のWebサイトのIIS 7構成に偽装DLLを追加する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 必要なWebサイトにワイルドカード・スクリプト・マップとしてIISImpersonationExtension.dllを追加します。

1. 接続ペインで「Sites」を開きます。

2. IISImpersonationExtension.dllを追加するWebサイト名をクリックします。

3. 選択したWebサイトの「home」ペインで「Handler Mappings」をダブルクリックします。

4. 「Actions」ペインで「Add Wildcard Script Map」をクリックします。

5. 「Add Wildcard Script Map」ダイアログ・ボックスの「Name」テキスト・ボックスに、dllの名前としてOracle Impersonation Pluginと入力します。

6. 「Executable」ボックスにWebgate IISImpersonationExtension.dllのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてIISImpersonationExtension.dllを含むフォルダに移動し、「OK」をクリックします。

Webgate_install_dir/access/oblix/apps/Webgate/bin/
IISImpersonationExtension.dll

この例ではデフォルトのパスを表しています。この場合、Webgate_install_dirが、該当のWebgateをインストールしたファイル・システムのディレクトリになります。

3. 次の作業を実行します。

- クライアント証明書認証: 「複数のIIS 7 Webgateに対するクライアント認証の有効化」

- 「IIS 7 Webgateのインストールの確認」

複数のIIS 7 Webgateに対するクライアント認証の有効化

このタスクを実行し、1つのIIS 7 Webサーバー・インスタンスのWebサイトを保護する各Webgateに有効なクライアント認証を設定します。これは、偽装DLLを個々のWebサイトに追加した直後に行うことも、まとめて一度に実行することもできます。

注意:
Webgateのクライアント認証を構成する前に、SSLをWebサイトで有効にしておく必要があります。WebサイトをSSL対応にしてから次の手順を実行します。

設定中にクライアント証明書認証を選択する場合、各WebサイトのISAPIフィルタの1つとしてcert_authn.dllを有効にして追加する必要があります。

IIS 7 Webサーバーでcert_authn.dllを有効化する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 接続ペインで「Sites」を開きます。

3. Webサイトを開き、\access\oblix\apps\webgate\binを表示します。

4. binディレクトリを右クリックし、「Switch To Content View」を選択します。

5. cert_authn.dllを右クリックし、ドロップダウン・メニューで「Switch To Feature View」を選択します。

6. cert_authn.dllの「Home」ペインで「SSL Settings」をダブルクリックします。

7. 「SSL Settings」ペインで「Require SSL」チェックボックスを選択し、「Accept from Client Certificates」を選択します。

8. 「Action」ペインで「Apply」を選択します。

9. このホストにインストールしたWebgateのうち、クライアント認証を有効にする各Webgateに対して同じ処理を繰り返します。

10. IIS 7 Webサーバーを再起動します。

11. 次のタスク、「ISAPIフィルタとしてcert_authn.dllを追加する手順」に進みます。

ISAPI v7フィルタとしてcert_authn.dllを追加する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 接続ペインで「Sites」を開きます。

3. cert_authn.dllを追加するWebサイト名をクリックします。

4. 「Home」ペインで「ISAPI Filters」をダブルクリックします。

5. 「Actions」ペインで「Add」をクリックします。

6. 「Add ISAPI Filter」ダイアログ・ボックスの「Filter name」ボックスに、ISAPIフィルタの名前としてOracle Certification Authentication Pluginと入力します。

7. 「Executable」ボックスにWebgate cert_authn.dllのファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてcert_authn.dllを含むフォルダに移動し、「OK」をクリックします。

Webgate_install_dir/access/oblix/apps/Webgate/bin/cert_authn.dll

この例ではデフォルトのパスを表しています。この場合、Webgate_install_dirが、該当のWebgateをインストールしたファイル・システムのディレクトリになります。

8. 「Action」ペインの「View Ordered List」をクリックし、上矢印と下矢印を使用して次のようにフィルタを並べ替えます。
cert_authn.dll
webgate.dll

9. 「Action」ペインで「Apply」を選択します。

10. このホストにインストールしたWebgateのうち、クライアント認証を有効にする各Webgateに対して同じ処理を繰り返します。

11. IIS 7 Webサーバーを再起動します。

12. デプロイメントのニーズに合わせて次の手順に進みます。

- 「パススルー機能のためのIIS 7 Webgateの構成」

パススルー機能のためのIIS 7 Webgateの構成

ここでは、必要なWebサイトにワイルドカード・スクリプト・マップとしてWebgate.dllを追加します。パススルー機能で動作するようにWebgateを構成する際には、WebgateをインストールするWebサイトの物理パスが異なるようにする必要があります。そうしないと、ハンドラ・マッピングの変更が、同じ物理パスを共有するすべてのWebサイトに反映されます。

注意:
物理パスは、Webサイトの作成時に指定するパスです。Webサイトの作成後にこのパスをチェックするには、「Action」ペインで「Basic Settings」をクリックすると、Webサイトの物理パスを示すウィンドウが表示されます。

- Webサイト名をクリックします。

- 「Action」ペインで「Basic Settings」をクリックします。

パススルー機能のためにWebgateを構成する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 接続ペインで「Sites」を開きます。

3. パススルーを有効にするWebサイトの名前をクリックします。

4. 選択したWebサイトの「home」ペインで「Handler Mappings」をダブルクリックします。

5. 「Actions」ペインで「Add Wildcard Script Map」をクリックします。

6. 「Add Wildcard Script Map」ダイアログ・ボックスの「Name」テキスト・ボックスに、ISAPIフィルタの名前としてWebgateと入力します。

7. 「Executable」ボックスにWebgate ISAPIフィルタ・ファイル(Webgate.dll)のファイル・システム・パスを入力するか、省略記号ボタン(...)をクリックしてWebgate.dll ISAPIフィルタ・ファイルを含むフォルダに移動し、「OK」をクリックします。

Webgate_install_dir/access/oblix/apps/Webgate/bin/Webgate.dll

8. アクセス・システム・コンソールで次の操作を実行します。

1. WebGateプロファイルを探して「Modify」をクリックします。

2. 「User Defined Parameters」の下に次のパラメータと値を入力します。
UseWebGateExtForPassthrough

true

3. プロファイルを保存します。

9. このホストにインストールしたWebgateのうち、パススルーを有効にする各Webgateに対して同じ処理を繰り返します。

10. IIS 7 Webサーバーを再起動します。

11. 次のタスク、「IIS 7 Webgateのインストールの確認」に進みます。

IIS 7 Webgateのインストールの確認

IIS 7 Webgateのインストールを確認するには、次の手順を使用します。

IIS 7 Webgateのインストールを確認する手順

1. 次のURLに移動します。

http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1

ここで、hostnameはWebgateをホストするコンピュータ名、portはWebサーバー・インスタンスのポート番号です。

2. Webgateの診断ページが表示されます。

- 成功した場合: Webgateの診断ページが表示される場合、Webgateが正常に機能しています。ページを閉じてください。

- 失敗した場合: Webgateの診断ページが表示されない場合、Webgateが正常に機能していません。この場合、Webgateをアンインストールしてから再インストールする必要があります。Oracle Access Managerの削除の詳細は、『Oracle Access Manager インストレーション・ガイド』の第22章を参照してから、Webgateのインストールに関する章に戻ってください。

1つのIIS 6インスタンスに対する複数のWebgateのインストールと構成

特に明記しないかぎり、この項は32ビットと64ビットのWebgateに同様に適用されます。

関連項目:
「1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成」

この項では、同一IIS Webサーバー・インスタンス上の異なるWebサイトに複数のWebgateをインストールして構成する方法を説明します。いくつかの手順は手動で行い、1つのIISインスタンスに1つのWebgateをインストールする際に実行する手順とは異なります。1つのIISインスタンスに対して複数のWebgateをインストールする場合、次のようになります。

- webgate.dllは、デフォルト(上位)Webサーバー・レベルではなく個々のWebサイト・レベルでISAPIフィルタとして構成する必要があります。

- /access仮想ディレクトリは、Webサイト・レベルで、Webgateインストールのそれぞれの/accessディレクトリにマップされます。

複数のWebgateの偽装DLLを構成する場合、オペレーティング・システムとして機能するようにユーザーを構成する必要があります。

マシンの(上位)Webサイト・レベルに構成できるpostgate.dllは1つのみです。ただし、上位レベルのWebサイトの下に異なるレベルで複数のwebgate.dllを構成できます。1台のマシンで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにOracle Access Managerの動作に異常が現れる可能性があります。

タスクの概要: 1つのIISインスタンスに対する複数のWebgateのインストールと構成

1. 複数のWebgateシナリオにおける各Webgateのインストール

2. 複数のWebgateに対する偽装DLLの設定

3. 複数のWebgateに対するSSLとクライアント認証の有効化

4. 次のタスクを実行します。このタスクはIIS Webサーバー・インスタンスごとにインストールするWebgateの数に関係なく同じです。

- 「ISAPIフィルタの並替え」

- 「IISへのWebgateのインストールの確認」

関連項目:
「複数のWebgateのインストールの確認」

複数のWebgateシナリオにおける各Webgateのインストール

特に明記しないかぎり、この項は32ビットと64ビットのWebgateに同様に適用されます。

ISAPI Webgateをインストールした後で、次に説明する手動の手順をいくつか実行します。

デフォルトでは、webgate.dllはWebサイト(上位)レベルでISAPIフィルタとして構成されます。複数のWebgateを1つのIISインスタンスに対してインストールしているときは、各Webgateインストールの後で、上位レベルからそれぞれのwebgate.dllを削除して、個々の適切なWebサイトで構成する必要があります。

注意:
1台のマシンで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにOracle Access Managerの動作に異常が現れる可能性があります。1つのIIS v6 Webサーバー・インスタンスに対して複数のWebgateが構成されている環境では、postgate.dllはサポートされません。

1つのIISインスタンスに対して複数のWebgateがある場合に各Webgateをインストールする手順

1. 第27章の説明に従ってISAPI Webgateをインストールします。

2. 保護するWebサイトに移動し、次の手順を使用してwebgate.dllをISAPIフィルタとして構成します。

1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 「Web Sites」を右クリックして、「Properties」オプションをクリックします。

3. 「ISAPI filter」タブをクリックしてwebgate.dllのパスを探します。フィルタ内に存在する場合はそれを選択して、Remove」ボタンをクリックします。

4. 「Web Sites」で、保護するWebサイトの名前を右クリックし、「Properties」オプションを選択します。

5. 「ISAPI filter」タブをクリックしてフィルタのDLLを追加します。

6. 次のフィルタを追加し、webgate.dllファイルのパスを指定します。webgateという名前を付けます。

Webgate_install_dir/access/oblix/apps/webgate/bin/webgate.dll

7. これらの変更を保存して適用します。

8. 「Directory Security」タブに移動します。

9. Oracle Access ManagerでこのWebサーバーの認証を行えるように「anonymous access」と「basic authentication」が選択されていることを確認します。

10. これらの変更を保存して適用します。

3. 保護するWebサイト・レベルに移動し、新しくインストールしたWebgate_install_dirを指す/access仮想ディレクトリを次のように作成します。

1. 「Web Sites」で、保護するWebサイトの名前を右クリックします。

2. 「New」を選択して、該当のWebgate_install_dir/accessを指す新しい仮想ディレクトリaccessを作成します。

3. 「Access Permissions」で、「Read」、「Run Scripts」および「Execute」を選択します。

4. これらの変更を保存して適用します。

4. ファイル・システムで、次のようにOracle Access Managerのディレクトリ権限を設定します。

1. ファイル・システムで、Webgate_install_dir\accessを探して右クリックし、「プロパティ」を選択します。

2. 「セキュリティ」タブをクリックします。

3. IUSR_machine_nameユーザーを追加して、「変更」に対して「許可」を選択します。
たとえば、Oracleのmachine_nameとしてIUSR_ORACLEを選択します。

4. IWAM_machine_nameユーザーを追加して、「変更」に対して「許可」を選択します。
たとえば、Oracleのmachine_nameとしてIWAM_ORACLEを選択します。

5. IIS_WPGユーザーを追加して、「変更」に対して「許可」を選択します。

6. NETWORK SERVICEユーザーを追加して、「変更」に対して「許可」を選択します。

7. Administratorsグループで、「変更」に対して「許可」を選択します。

5. 簡易モードまたは証明書モードでWebgateが設定されている場合は、次の手順を実行します。

1. ファイル・システムで、Webgate_install_dir\access\oblix\config\password.xmlのpassword.xmlファイルを探して右クリックし、「プロパティ」を選択します。

2. 「セキュリティ」タブをクリックします。

3. IUSR_machine_name、IWAM_machine_name、IIS_WPG、NETWORK SERVICEユーザーの「読み取り」権限に対して「許可」を選択します。

6. 次の手順を実行して新しいWebサービス拡張機能を追加します。

1. 「Web Service Extensions」を右クリックして、「Add a new Web service extension...」を選択します。

2. 拡張機能名Oracle Webgateを追加します。

3. 「Add」をクリックして拡張機能ファイルのパスを追加し、該当のwebgate.dllのパスを入力します。

Webgate_install_dir\access\access\oblix\apps\webgate\bin\webgate.dll

4. 「OK」をクリックして変更内容を保存します。

5. 「Set extension status to allowed」の横にあるチェック・ボックスを選択します。

6. 「OK」をクリックして変更内容を保存します。

7. 上位のWebサイト・レベル(「Webサイト」)のISAPIフィルタにwebgate.dllがないことを確認します。

8. 次の項目の手順に従い次の一連のタスクを実行します。

1. 「複数のWebgateに対する偽装DLLの設定」

2. 「複数のWebgateに対するSSLとクライアント認証の有効化」

9. IISインスタンスに対して次のWebgateをインストールするには、これらの手順を繰り返します。

複数のWebgateに対する偽装DLLの設定

特に明記しないかぎり、この項は32ビットと64ビットのWebgateおよびIIS v6に同様に適用されます。

クライアントのアクセス・トークンは偽装トークンとも呼ばれます。偽装トークンでは、クライアント、クライアントのグループおよびクライアントの権限が識別されます。トークン内の情報は、スレッドがクライアントのかわりにリソースへのアクセスをリクエストする際に、アクセス・チェックに使用されます。

アクセス・システムによってユーザーの認証および認可が行われます。ワイルドカード拡張機能のOAMのIISImpersonationExtension.dllは、Webサーバーへの各リクエストのフィルタのように機能します。アクセス・システムでは、「アクセス・ゲート構成」ページの偽装ユーザー名/パスワードを使用して、別のユーザーを偽装する権限を持つ特別なユーザーを構成することでユーザーを指定します。指定されたユーザーにはオペレーティング・システムとして機能する権限が必要です。DLLは、Oracle Access Managerによって認証および認可されたユーザーを偽装し、偽装トークンを生成します。

次の手順を実行し、1つのIIS Webサーバー・インスタンスのWebサイトを保護する各Webgateに偽装DLLを設定します。これは、前述の項のインストール・タスクの直後に行うことも、まとめて一度に実行することもできます。

注意:
このタスクは、1つのIIS Webサーバー・インスタンスの個々のWebサイトを保護する各Webgateに対して実行する必要があります。

個々のWebサイトのIIS構成に偽装DLLを追加する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 左側のペインにあるローカル・コンピュータのアイコンの横のプラス・アイコン(+)をクリックしてWebサイトを表示します。

3. 左側のペインで「Web Service Extensions」をクリックします。

4. 右側のペインで「Webgate」をダブルクリックし、「Properties」パネルを開きます。

5. 「Required Files」タブをクリックします。

6. 「Add」をクリックします。

7. 「Path to file」テキスト・ボックスでIISImpersonationExtension.dllのフルパスを入力し、「OK」をクリックします。次に例を示します。

Webgate_install_dir\access\oblix\apps\webgate\bin\IISImpersonationExtension.dll

この例ではデフォルトのパスを表しています。この場合、Webgate_install_dirが、該当のWebgateをインストールしたファイル・システムのディレクトリになります。

8. Webgateのアイコンの横にある「Allow」ボタンがグレー表示されていることを確認します。グレー表示されていれば、dllをWebサービス拡張機能として実行できます。

9. Webサイト名を右クリックして、「Properties」をクリックします。

10. 「Home Directory」タブをクリックし、「Configuration」ボタンをクリックします。

11. ワイルドカードのアプリケーションのマッピングのリスト・ボックスで、IISImpersonationExtension.dllのエントリをクリックして強調表示し、「Edit」をクリックします。

12. ボックスの選択が解除されていないことを確認し、「OK」をクリックします。

13. IIS Webサーバー・インスタンスに対するWebサイトとWebgateのペアごとにこれらの手順を繰り返します。

14. 次の作業を実行します。

- クライアント証明書認証: 「複数のWebgateに対するSSLとクライアント認証の有効化」

- 「複数のWebgateのインストールの確認」

複数のWebgateに対するSSLとクライアント認証の有効化

このタスクを実行し、1つのIIS Webサーバー・インスタンスのWebサイトを保護する各Webgateに有効なクライアント認証を設定します。これは、偽装DLLを個々のWebサイトに追加した直後に行うことも、まとめて一度に実行することもできます。

注意:
特に明記しないかぎり、この項の手順は32ビットと64ビットのWebgateおよびIIS 6に同様に適用されます。

設定中にクライアント証明書認証を選択する場合、各WebサイトのISAPIフィルタの1つとしてcert_authn.dllを追加する必要があります。

IIS v6 WebサーバーでSSLを有効化する手順

1. 必要に応じてインターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. ローカル・コンピュータのアイコンを開き、Webサイトを表示します。

3. 該当するそれぞれのWebサイトを開いてから、\access\oblix\apps\webgate\binを開きます。

4. cert_authn.dllを右クリックして、「Properties」を選択します。

5. 「Properties」パネルで「File Security」タブを選択します。

6. 「Secure Communications」サブパネルで「Edit」をクリックします。

7. 「Client Certificate Authentication」サブパネルで「Accept Certificates」をクリックし、「OK」をクリックします。

8. cert_authn.dllの「Properties」パネルで「OK」をクリックします。

9. このホストにインストールした各Webgateに対して同じ処理を繰り返します。

10. 次のタスク、「ISAPIフィルタとしてcert_authn.dllを追加する手順」に進みます。

ISAPIフィルタとしてcert_authn.dllを追加する手順

1. 必要な場合、「Internet Information Services」コンソールを起動します。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. 適切なWebサイトを右クリックして、「Properties」パネルを表示します。

4. 「ISAPI Filters」タブをクリックして、「Add」ボタンをクリックし、「Filter Properties」パネルを表示します。

5. フィルタ名としてcert_authnと入力します。

6. 「Browse」ボタンをクリックし、次のディレクトリにナビゲートします。
\Webgate_install_dir\access\oblix\apps\webgate\bin

7. cert_authn.dllを実行可能ファイルとして選択します。

8. 「Filter Properties」パネルで「OK」をクリックします。

9. 「ISAPI Filters」パネルで「Apply」をクリックします。

10. 「OK」をクリックします。

11. このホストにインストールした各Webgateに対して同じ処理を繰り返します。

12. フィルタが正しい順序で表示されていることを確認します。

13. 「複数のWebgateのインストールの確認」に進みます。

複数のWebgateのインストールの確認

このタスクは32ビットと64ビットのWebgateおよびIIS v6 Webサーバーに同様に適用されます。

1台のマシンで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにOracle Access Managerの動作に異常が現れる可能性があります。1つのIIS v6 Webサーバー・インスタンスに対して複数のWebgateが構成されている環境では、postgate.dllはサポートされません。

関連項目:

- 「64ビットWebgateインストールの終了」

- 「IISへのWebgateのインストールの確認」

64ビットWebgateインストールの終了

この項では、64ビットWebgateのインストールを完了する方法について説明します。32ビットのWebgateをインストールする場合は、この項をスキップできます。その場合は、かわりに「IISでのWebgateインストールの完了」を参照してください。

このタスクを開始する前に、第27章の情報に従ってWebgateのインストールが完了していることを確認してください。また、該当のWebgateに対応するWebサーバー構成の更新は、Webgateのインストール時に自動で完了させておくか、「IIS v6対応Webgate」の説明に従って手動で完了させておく必要があります。

タスクの概要: 64ビットWebgateのインストールの終了

1. 「アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証の設定」の手順を実行します。

2. 必要に応じて、クライアント証明書を有効化します。「クライアント証明書認証の設定」を参照してください。

3. これらを終了したら、次を実行できます。

- 「IISへのWebgateのインストールの確認」の説明に従って操作を確認します。

- 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』の説明に従ってWindows偽装を実装します。

アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証の設定

特に明記しないかぎり、この項は32ビットと64ビットのWebgateに同様に適用されます。この項では、デフォルトで使用するWebサイトに対するアクセス権限の設定を説明します。

アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証を設定または確認する手順

1. インターネット・サービス・マネージャを起動します。たとえば、「スタート」メニューから「プログラム」→「管理ツール」→「Internet Service Manager」をクリックします。

2. 左側のパネルで、「+」をクリックしてローカル・コンピュータを開きます。

3. クリックして「Web Sites」タブを開きます。

4. 「Default Web Site」(またはデフォルトとして使用しているサイト)を右クリックし、「デフォルト・サイトが設定されていない場合のWebサイトの保護」の説明に従って仮想ディレクトリを作成します。

5. 「Internet Information Services」タブの「Web Sites」を右クリックし、「Properties」をクリックして次の手順を実行します。

1. 「Internet Information Services」タブで「Edit」ボタンをクリックします。

2. 「ISAPI filter」タブを見つけて、次のようにフィルタのDLLを確認(または追加)します。
フィルタがある場合: IIS Webサーバーの構成ファイルを更新してある場合、webgate.dllが正しく配置されています。

フィルタがない場合: Webgate_install_dir\oblix\access\apps\webgate\bin\webgate.dllからwebgate.dllフィルタを追加します。

3. 変更内容を保存して適用します。

4. 「Directory Security」タブをクリックして、「Anonymous Access」と「Basic Authentication」の両方が選択されていることを確認します。
選択されている場合: 手順6に進みます。

選択されていない場合: 「Anonymous Access」と「Basic Authentication」を選択し、これらの変更内容を保存して適用します。

6. 次の作業を実行します。

- 「クライアント証明書認証の設定」(必要に応じて)

- クライアント証明書認証がない場合: IIS Webサーバーを再起動します。

- フィルタの配置: 「ISAPIフィルタの並替え」の手順を実行し、すべてのフィルタが追加されていてその順序が正しいことを確認します。

クライアント証明書認証の設定

このタスクはオプションであり、クライアント証明書認証を使用する場合にのみ実行する必要があります。その場合は、IISとWebgateでSSLを有効にする必要があります。

この項の情報は、「IIS Webサーバーでのクライアント証明書認証の有効化」の詳細のサブセットです。

ISAPIフィルタとしてcert_authn.dllを追加する手順

1. 必要であれば「Internet Information Services」コンソールを起動します(「スタート」→「管理ツール」→「Internet Service Manager」をクリックします)。

2. ローカル・コンピュータを開いて、Webサイトを表示します。

3. 「Default Web Site」(またはデフォルトとして使用しているWebサイト)を右クリックしてから、\access\oblix\apps\webgate\binを開きます。

4. cert_authn.dllを右クリックして「Properties」を選択し、次の操作を実行します。

1. 「Properties」パネルで「File Security」タブを選択します。

2. 「Secure Communications」サブパネルで「Edit」をクリックします。

3. 「Client Certificate Authentication」サブパネルで「Accept Certificates」をクリックし、「OK」をクリックします。

4. 「Secure Communications」パネルで「OK」をクリックします。

5. cert_authn.dllの「Properties」パネルで「OK」をクリックします。

5. 「ISAPI Filters」タブをクリックして、「Add」ボタンをクリックし、「Filter Properties」パネルを表示します。

6. 「ISAPIフィルタの並替え」の説明に従ってフィルタが正しい順序で表示されていることを確認します。

7. 「IISへのWebgateのインストールの確認」に進みます。

IISへのWebgateのインストールの確認

WebgateをインストールしてIIS Webサーバー構成ファイルを更新した後、Webgate診断を使用してWebgateが適切にインストールされていることを確認できます。

注意:
このタスクは、32-bitと64-bitのWebgateの両方で同じです。IIS Webサーバー・インスタンスごとにインストールするWebgateの数にも関係なく同じです。

Webgateのインストールを確認する手順

1. 次のURLに移動します。

http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1

ここで、hostnameはWebgateをホストするコンピュータ名、portはWebサーバー・インスタンスのポート番号です。

2. Webgateの診断ページが表示されます。

- 成功した場合: Webgateの診断ページが表示される場合、Webgateが正常に機能しています。ページを閉じてください。

- 失敗した場合: Webgateの診断ページが表示されない場合、Webgateが正常に機能していません。この場合、Webgateをアンインストールしてから再インストールする必要があります。Oracle Access Managerの削除の詳細は、10g Webgateのインストールに関する第27章の「OAM 11gデプロイメントからの10g Webgateの削除」を参照してください。

IIS Webサーバーの起動、停止および再起動

Oracle Access Manager Webコンポーネントのインストールまたは設定中にIIS Webサーバーの再起動を求められた場合は、画面に表示されるすべての指示に従ってください。また、Webサーバーの起動と停止に適している、net stop iisadminおよびnet start w3svcの使用を検討してください。netコマンドは、インストールに伴いメタベースが破損しないようにするために役立ちます。

アンインストール前のWebサーバー構成変更の削除

この項の情報は32ビットと64ビットのWebgateに同様に適用されます。

インストール中に生じたWebサーバーの構成変更は、Webgateのアンインストール後に手動で元に戻す必要があります。たとえば、IIS Webgateに対してISAPI transfilterがインストールされます。ただし、Webgateをアンインストールしても、これは自動的に削除されません。また、作成されたWebサービス拡張機能およびIDディレクトリへのリンクも削除されません。このタイプの情報は手動で削除する必要があります。これらは、削除する情報の一例であり、すべてではありません。

さらに、Webgate用にWebサーバー構成ファイルに対して手動で行った変更もすべて削除する必要があります。各コンポーネントに追加される内容の詳細は、この章の他の項を参照してください。

Webgateおよび関連するファイルをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。メタベースを編集するためのツールとして、MetaEditも提供されています。MetaEditはRegeditに似ており、一貫性チェッカーとブラウザ/エディタが含まれています。WebgateをIISから完全に削除するには、MetaEditを使用してメタベースを編集します。

30 10g Webgate用のISAサーバーの構成

この章では、Oracle Access Manager ISAPI WebgateとMicrosoft Internet Security and Acceleration Server(ISAサーバー)が連動するように構成する方法を説明します。この項の内容は次のとおりです。

- 前提条件

- Oracle Access ManagerおよびISAサーバーについて

- 互換性とプラットフォームのサポート

- ISAサーバー用のWebgateのインストールおよび構成

- ISAPI Webgate用のISAサーバーの構成

- ISAサーバーの起動、停止および再起動

- ISAサーバーのWebgateをアンインストールする前のOracle Access Managerフィルタの削除

前提条件

Oracle Access Managerコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシーの強制エージェントの概要」

- 「Oracle Access ManagerおよびISAサーバーについて」

Oracle Access ManagerおよびISAサーバーについて

ISAサーバーは、Microsoft社の統合エッジ・セキュリティ・ゲートウェイです。このサーバーは、インターネットベースの脅威からIT環境を保護し、アプリケーションおよびデータへの安全なリモート・アクセスをユーザーに提供するように設計されています。

Webgateは、Oracle Access ManagerのWebサーバー・プラグイン・アクセス・クライアントで、WebリソースへのHTTPリクエストを捕捉して、認証と認可を行うためにアクセス・サーバーに転送します。ISAPIは、ISAサーバー(およびIIS Web サーバー)と通信するWebgateを識別するためにOracle Access Managerで使用されるインターネットWebサーバー拡張機能です。

このWebgateは、Oracle Access Managerの基本およびフォーム(フォームベース)認証スキームの両方を使用するシナリオでISAサーバーと連動することがテストされています。通常どおり、Oracle Access Managerを使用して基本およびフォーム認証スキームとポリシー・ドメインを開発してください。

注意:
Oracle Access Managerのクライアント証明書認証は、ISAサーバーに対してはサポートされていません。

関連項目:
認証管理とポリシー・ドメインの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

ISAサーバーをOracle Access Managerと連動させる方法は、IIS Webサーバーの場合とほぼ同じです。ただし、ISAサーバーでは、ファイアウォールと仮想プライベート・ネットワーク(VPN)の機能が提供されます。

ISAサーバーは、サード・パーティのセキュリティ・フィルタを使用するように構成できます。ISAサーバー使用時の認証および認可にOracle Access Managerセキュリティを適用するには、webgate.dllとpostgate.dllの両方をISAサーバーWebフィルタとして登録する必要があります。アクセス・サーバーへのリクエストがISAサーバーを通過するたびに、webgate.dllとpostgate.dllが要求されます。

次の概要では、実行が必要なタスクと、ISAサーバーでのISAPI Webgateの設定手順に関する項目について説明します。

タスクの概要: ISAサーバーでのISAPI Webgateのインストールと構成

1. 「互換性とプラットフォームのサポート」の確認

2. 「ISAサーバー用のWebgateのインストールおよび構成」

3. 「ISAPI Webgate用のISAサーバーの構成」

4. 次の項で説明されているタスクの実行

1. 「ISAPIフィルタの並替え」

2. 「ISAサーバーのWebgateをアンインストールする前のOracle Access Managerフィルタの削除」

互換性とプラットフォームのサポート

次のURLのOracle Technology Networkから最新の動作保証のマトリクスを入手してください。

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

ISAサーバー用のWebgateのインストールおよび構成

ISAサーバーのインストール後、ISAサーバーと連動させるためにWebgateをインストールするには、次のタスクを実行します。

関連項目:
「互換性とプラットフォームのサポート」

タスクの概要: ISAサーバー用のWebgate構成の実行

1. 「ISAサーバーでのWebgateのインストール」

2. 「/accessディレクトリの権限の変更」

3. 「Oracle Access ManagerプラグインのISAサーバーWebフィルタとしての登録」

ISAサーバーでのWebgateのインストール

ISAサーバーでWebgateをインストールする場合、ISAPI Webgateのインストール先(Webgate_install_dir)を、Microsoft ISAサーバーのインストール先と同じにする必要があります。たとえば、ISAサーバーがC:\Program Files\Microsoft ISA Serverにインストールされている場合、ISAPI Webgateもその同じ場所にインストールする必要があります。

注意:
Webgateのインストール時に、ISAサーバー構成を自動更新しないでください。ISAサーバー構成を自動更新するかどうか確認されたら、「いいえ」を選択してください。

タスクの概要: ISAサーバー用のISAPI Webgateのインストール

1. 次の項目の詳細は第27章を参照してください。これらはご使用の環境に応じて適用されます。

- OAM 11gでの10g Webgateのプロビジョニング

- OAM 11g用の最新のOAM 10g Webgateの検索とインストール

- WebLogicコンテナへのアプリケーションのデプロイ

- OAM 11gでの10g Webgateの集中ログアウトの構成

2. /accessディレクトリの権限の変更

/accessディレクトリの権限の変更

ISAサーバーに対応するISAPI Webgateのインストールと構成が終了したら、\accessサブディレクトリへの権限を変更する必要があります。このサブディレクトリは、ISAサーバー(およびWebgate)のインストール・ディレクトリ内に作成されています。ユーザーNETWORK SERVICEを追加し、NETWORK ADMINISTRATORにフル・コントロール権限を付与する必要があります。

これにより、ISAサーバーがWebgateとアクセス・サーバー.との間の接続を確立できます。特定の構成ファイルをネットワーク管理者に対して読取り可能にする必要があります。NETWORK ADMINISTRATORにフル・コントロールを付与するのはそのためです。

\accessサブディレクトリの権限を変更する手順

1. ファイル・システムで、Webgate_install_dir\accessを右クリックし、「プロパティ」を選択します。

2. 「プロパティ」ウィンドウで「セキュリティ」タブをクリックします。

3. NETWORK SERVICEユーザーを追加し、「許可」を選択して「フル コントロール」を付与します。

4. NETWORK ADMINISTRATORに対して、「フル コントロール」を選択します。

ISAPI Webgate用のISAサーバーの構成

次の項では、ISAサーバーをOracle Access Manager ISAPI Webgateと連動するように構成する方法について説明します。

タスクの概要: ISAサーバー用のWebgate構成の実行

1. 「Oracle Access ManagerプラグインのISAサーバーWebフィルタとしての登録」

2. 「ISA WebフィルタのISAファイアウォール・ポリシーの構成」

Oracle Access ManagerプラグインのISAサーバーWebフィルタとしての登録

ISAPI Webgate権限をリセットしたら、Oracle Access Managerのwebgate.dllおよびpostgate.dllプラグインをISAサーバー内にWebフィルタとして登録する必要があります。Webフィルタは、ISAサーバーのホストを通過するHTTPトラフィックをすべて検査します。条件に適合するリクエストのみが、通過を許可されます。

Oracle Access Manager認証スキームでは、ユーザーへの資格証明のチャレンジ方法、ユーザーが入力した情報のマッピングや検証方法などを定義します。ISAサーバーでは、チャレンジ方法としてフォーム認証または基本認証のどちらかを選択する必要があります。ユーザーが入力した資格証明を、ディレクトリ・サーバーに格納されている対応するユーザー・プロファイルにマッピングするためにチャレンジ・パラメータも指定する必要があります。

注意:
Oracle Access ManagerライブラリがISA Webフィルタとして登録されていないと、Oracle Access Manager認証が失敗する可能性があります。認証スキームのフォームベースのログイン用アクション・パスでwebgate.dllを指定しないでください。かわりに、/accessディレクトリ内のダミー・ファイルへのパスを次のように指定する必要があります。
action= "/access/dummy"

フォームベースの認証の場合、postgate.dllをインストールし、webgate.dllよりも上位に置く必要があります。

次の手順では、Oracle Access ManagerプラグインをISAサーバーに登録する方法を説明します。

注意:
フィルタ登録を元に戻す必要がある場合、次の手順を使用し、regsvr32コマンドに/uオプションを指定します。たとえば、regsvr32 /u ISA_install_dir\access\oblix\apps\webgate\bin\webgate.dllのようになります。

Oracle Access ManagerプラグインをISAサーバーWebフィルタとして登録する手順

1. ISAサーバーのインストール・ディレクトリを探し、そこから次のタスクを実行します。

2. net stop fwsrvを実行し、ISAサーバーを停止します。

3. regsvr32 ISA_install_dir\access\oblix\apps\webgate\bin\webgate.dllを実行し、webgate.dllをISAPI Webフィルタとして登録します。

4. regsvr32 ISA_install_dir\access\oblix\apps\webgate\bin\postgate.dllを実行し、postgate.dllをISAPI Webフィルタとして登録します。

5. net start fwsrvを実行し、ISAサーバーを再起動します。

6. 「ISA WebフィルタのISAファイアウォール・ポリシーの構成」に進みます。

ISA WebフィルタのISAファイアウォール・ポリシーの構成

ユーザーを認証するには、ISAサーバーが認証サーバーと通信可能である必要があります。Oracle Access Managerのwebgate.dllとpostgate.dllをISA Webフィルタとして登録した後、これらのWebフィルタを使用してリソースを保護するようにISAファイアウォール・ポリシー・ルールを構成する必要があります。

Web公開ルールでは、基本的に受信リクエストが適切なWebサーバーにマッピングされます。アクセス・ルールでは、送信元ネットワーク上のクライアントが宛先ネットワーク上のリソースにアクセスする方法を決定します。ISAファイアウォール・ポリシー・ルールでは、ユーザー・セットのクライアント・メンバーシップ(ファイアウォール・クライアント、認証済Webクライアント、仮想プライベート・ネットワーク(VPN)クライアントのいずれか)が必要になります。ISAサーバーは、ISAファイアウォール・ポリシー・ルールに基づいて認証済ユーザーの照合を試みます。

関連項目:
ISAサーバーのドキュメントの、ISAファイアウォール・ポリシーおよびルールの詳細

次の手順では、Oracle Access Managerのwebgate.dllとpostgate.dllをISA Webフィルタとして使用するためにISAファイアウォール・ポリシー・ルールを構成する方法について説明します。

注意:
次の手順を実行した後、認証のリスナーを作成する場合は、「Advanced Properties」の「Allow client authentication over HTTP」を選択します。

Oracle Access Managerの認証および認可を有効にするためのISAポリシーの構成手順

1. 「スタート」メニューから、「すべてのプログラム」→「Microsoft ISA Server」→「ISA Server Management」をクリックします。

2. 「ISA Server Management」コンソールのツリーでこのサーバーの名前を探し、「Firewall Policy」をクリックします。

3. 「Tasks」タブで「Publish Web Sites」をクリックします。

4. 「Web publishing rule name」フィールドにわかりやすいルール名を入力し、「Next」をクリックします。

5. 「Select Rule Action」ページで、「Allow」オプションが選択されていることを確認し、「Next」をクリックします。

6. 「Publishing type」で、「Publish a single Web site or load balancer」オプションが選択されていることを確認し、「Next」をクリックします。

7. 「Server Connection Security」ページで、「Use non-secured connections to connect the published Web server or server farm」をクリックし、「Next」をクリックします。

注意:
セキュアな接続を使用している場合、ISAサーバーで提供されるサーバー接続セキュリティ設定を参照してください。

8. 内部公開の詳細を設定するには、次の手順を実行します。

1. 「Internal site name」ボックスに、Webサーバーの内部的にアクセス可能な名前を入力します。

2. 「Use a computer name or IP address to connect to the published server」チェック・ボックスを選択します。

3. 「Computer name or IP address」ボックスに、Webサーバー・コンピュータの内部的にアクセス可能な完全修飾ドメイン名か、IPアドレスを入力します。

4. 「Next」をクリックします。

9. 「Public name」ボックスで、パブリックにアクセス可能なWebサーバー・コンピュータのドメイン名を入力し、「Next」をクリックします。

10. Webサイトに特定のフォルダを公開するには、次の手順を実行します。

1. 公開されたWebサイトのフルパスを「Web site」ボックスに表示するには、「Path (optional)」ボックスにフォルダ名を入力します。

2. 「Next」をクリックします。

11. Accept requests forリストで、次の操作を実行します。

1. 「This domain name (type below)」をクリックします。

2. 「Public name」ボックスに、Webサイトのパブリックにアクセス可能な完全修飾ドメイン名を入力します。

3. 「Next」をクリックします。

12. 「Web listener」リストで、このWeb公開ルールに使用する「Web listener」をクリックするか、新しいWebリスナーを次のように作成します。

1. 「New」をクリックし、新しいWebリスナーのわかりやすいルール名を入力して、「Next」をクリックします。

2. 「Do not require SSL secured connections with clients」をクリックし、「Next」をクリックします。

3. 「Listen for requests from these networks」リストで、必要なネットワークを選択し、「External」ボックスを選択し、「Next」をクリックします。

4. 「Select how clients will provide credentials to ISA Server」リストで、「No Authentication」をクリックし、「Next」をクリックします。

5. 「Single Sign On Settings」ページで、「Next」をクリックし、「Finish」をクリックします。

13. Authentication Delegation: 「Select the method used by ISA Server to authenticate to the published Web server」リストで次の手順を実行します。

1. 「No Delegation」をクリックします。

2. 「Client Cannot Authenticate Directly」をクリックします。

3. 「Next」をクリックします。
これは、ISAサーバーによって、公開されたWebサーバーへの認証に使用されます。

14. 「User Sets」ページで、次の手順を実行します。

1. 「User Sets」ボックスから「All」(デフォルトのユーザー設定)を選択し、リクエストに適用するルールを設定します。

2. 「Next」をクリックして、「Finish」をクリックします。

15. 「Apply」をクリックしてファイアウォール・ポリシーを更新し、「OK」をクリックします。

16. 該当するポートのみが開き、通過させるトラフィックが許可されていることを確認します。

ISAPIフィルタの並替え

Webgate ISAPIフィルタが正しい順序で組み込まれるように確認することが重要です。postgate.dllはwebgate.dllより前にロードする必要があります。

ISAサーバーのためにWebgate ISAPIフィルタを並べ替える手順

1. 「スタート」メニューから、「すべてのプログラム」→「Microsoft ISA Server」→「ISA Server Management」をクリックします。

2. 「Configuration」を開き、「Add-ins」を選択してWebフィルタを表示します。

3. 「Web-filters」を右クリックし、「Properties」を選択します。

4. 次の.dllファイルが表示されることを確認します。
次に例を示します。

postgate.dll
webgate.dll

5. 表示されていないフィルタを追加し、必要であれば、フィルタ名を選択して上下の矢印を使用し、手順5の表示のようにフィルタの順序を変更します。

警告:

webgate.dllフィルタとpostgate.dllフィルタがそれぞれ1つのみあること、また有効な状態であることを確認します。さらに、postgate.dllがwebgate.dllより高い優先度でインストールされていることを確認します。

ISAサーバーの起動、停止および再起動

Oracle Access Manager Webコンポーネントのインストールまたは設定中にISAサーバーの再起動を求められた場合は、画面に表示されるすべての指示に従ってください。また、ISAサーバーの起動と停止に適している、net stop fwsrvおよびnet start fwsrvの使用を検討してください。netコマンドは、インストールに伴いメタベースが破損しないようにするために役立ちます。

詳細は、ISAサーバーのドキュメントを参照してください。

ISAサーバーのWebgateをアンインストールする前のOracle Access Managerフィルタの削除

ISAサーバーと連動するように構成されたWebgateのアンインストールを計画している場合、最初にOracle Access Managerフィルタの登録を手動で解除してから、Webgateをアンインストールする必要があります。

関連項目:
第27章: Oracle Access Manager 10g Webgateのアンインストールの詳細

Webgateのアンインストールの前にフィルタの登録を解除する手順

1. ISAサーバーを停止します。

2. コマンドラインで次のコマンドを実行して、webgate.dllの登録を解除します。次に例を示します。

regsvr32 /u ISA_install_dir\access\oblix\apps\webgate\bin\webgate.dll

3. コマンドラインで次のコマンドを実行して、postgate.dllの登録を解除します。次に例を示します。

regsvr32 /u ISA_install_dir\access\oblix\apps\webgate\bin\postgate.dll

31 10g Webgate用のLotus Domino Webサーバーの構成

この章では、Webgateと連動させるためのLotus Dominoのインストールと構成に関するヒントを示します。この項の内容は次のとおりです。

- 前提条件

- Domino Webサーバーのインストール

- 最初のDomino Webサーバーの設定

- Domino Webサーバーの起動

- SSLの有効化(オプション)

- Dominoセキュリティ(DSAPI)フィルタのインストール

注意:
この章の情報は、オペレーティング・システム・コマンド、Lotus NotesおよびDomino Webサーバーの知識があることを前提としています。

前提条件

Oracle Access Managerコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシーの強制エージェントの概要」

- 「OAM 11gで使用する新規OAM 10g Webgateのインストールについて」

Domino Webサーバーのインストール

Domino WebサーバーにWebgateをインストールする前に、Domino Enterprise Server R5を適切にインストールして設定しておく必要があります。次ではSolarisを中心に説明します。ただし、一部を変更すれば次の手順を他のUNIXシステムでも使用できます。

注意:
初めてlotus.comからダウンロードする場合は登録する必要があります。

UNIXでDomino Webサーバーをダウンロードする手順

1. 次のURLからLotus Dominoをダウンロードします。
http://www-10.lotus.com/ldd/down.nsf

2. ステージング領域で、ダウンロードしたファイルのuntarを実行します。次に例を示します。
gct@planetearth[/export/users2/gct/temp] 433 : ls C37UUNA.tar

gct@planetearth[/export/users2/gct/temp] 434 : tar xf C37UUNA.tar

gct@planetearth[/export/users2/gct/temp] 435 : ls C37UUNA.tar sol/

Dominoはユーザーrootとしてインストールする必要があります。インストール・スクリプトによって、Lotus Dominoインストール・ディレクトリにリンクするソフト・リンク/opt/lotusが作成されます。

UNIXにDomino Webサーバーをインストールする手順

1. Domino Webサーバーのインストール・スクリプトを実行します。次に例を示します。

gct@planetearth[/export/users2/gct/temp/sol] 441 : su root
Password:
root@planetearth[/export/users2/gct/temp/sol] 1 : ls
install* license.txt script.dat sets/ tools/
root@planetearth[/export/users2/gct/temp/sol] 2 :
root@planetearth[/export/users2/gct/temp/sol] 2 : ./install
========================================================
Domino Server Installation
========================================================
Welcome to the Domino Server Install Program.
Type h for help on how to use this program.
Press TAB to begin the installation.
--------------------------------------------------------
Type h for help
Type e to exit installation
Press TAB to continue to the next screen.
--------------------------------------------------------

設定タイプを選択するように求められます。

2. 設定タイプを選択します。次に例を示します。
Select Setup type: [Domino Enterprise Server]

3. 次の点を考慮してインストールを完了します。次に例を示します。

- デフォルトのプログラム・ディレクトリは/opt/lotusに設定されています。他のディレクトリに上書きすることもできます。たとえば、/export/home/WWW/lotusとします。

- デフォルトのデータ・ディレクトリは/local/notesdata1に設定されています。これも他のディレクトリに上書きできます。たとえば、/export/home/WWW/lotus/data1とします。

- データ・ディレクトリを所有するようにDomino UNIXユーザーを上書きします。デフォルト・ユーザーはnotesに設定されています。これを有効なUNIXユーザーに変更できます。たとえば、gctまたはrootです。

- 「The UNIX user for this directory must be a member of this group」を上書きします。デフォルト・グループはnotesに設定されています。これを有効なUNIXグループ名に変更できます。たとえば、oblixとします。

注意:
次に進む前に、Dominoデータ・ディレクトリを$PATHに含めてください。

最初のDomino Webサーバーの設定

インストールが正常に終了したら、最初のDominoサーバーを設定する必要があります。

最初のDominoサーバーを設定する手順

1. /opt/lotus/bin/http httpsetupを実行します。
デフォルトではDominoはポート8081を使用します。

2. ポート8081がすでに使用されていないことを確認します。

3. ブラウザを起動して、次のURLを入力します。次に例を示します。
http://hostname:8081

4. 画面の指示に従います。次の点に注意してください。

- Webサーバーを取得するためのHTTPを調べます。

- 管理者の指定には姓と名前の両方を使用します。

- 単純なパスワードを作成し、安全な場所に記録します。たとえば、oracleoracleとします。

5. すべてのコマンドは、このDomino Webサーバーに対して構成したUNIXユーザーとして実行します。

警告:

rootとして実行しないでください。

Domino Webサーバーの起動

最初のDomino Webサーバーの設定が正常に終了したら、起動する必要があります。

Dominoサーバーを起動する手順

1. /opt/lotus/bin/serverを実行します。

2. ブラウザを起動して、次のURLを入力します
次に例を示します。

http://hostname:80/names.nsf

ログイン名とパスワードの入力を求められます。

3. 「Server-Server」を選択します。

4. 目的のサーバーを選択します。

5. 「Edit Server」を選択します。

6. 「Ports」→「Internet Ports」を選択し、「Web」をクリックします。

7. TCP/IPポート番号の値を希望のポート番号に変更します。

8. 「Save and Close」をクリックしてすべての変更内容を保存します。

9. /opt/lotus/bin/serverを実行してサーバーを再起動します。

SSLの有効化(オプション)

SSLの有効化はWebgateでは必須ではありません。ただし、WindowsシステムのLotus NotesクライアントからUNIXシステムに送るために、キーリング・ファイル(.kyr)と対応するスタッシュ・ファイル(.sth)を生成する必要がある場合は、次の手順を実行します。

キーリング・ファイルとスタッシュ・ファイルを生成する手順

1. WindowsシステムでLotus Notesクライアントを起動します。
次に例を示します。

「File」→「Databases」を選択し、「Open」をクリックします。

2. 「Server Certificate Admin」を選択します。

3. キー・リング・ファイルを作成します。

4. 証明書リクエストを作成します。

5. 信頼できるルート証明書をキー・リング・ファイルにインストールします。

6. 証明書をキー・リング・ファイルにインストールします。

7. 新たに作成したキーリング・ファイルとスタッシュ・ファイルをWindowsシステムからUNIXコンピュータにコピー(すなわちftp送信)します。

8. 両方のファイルをDominoデータ・ディレクトリに格納します。

SSLを有効化する手順

1. ブラウザを起動して、次のURLを入力します
次に例を示します。

http://hostname:port/names.nsf

ログイン名とパスワードの入力を求められます。

2. 「Server-Server」を選択します。

3. 目的のサーバーを選択します。

4. 「Edit Server」を選択します。

5. 「Ports」→「Internet Ports」を選択し、「Web」をクリックします。

6. 「SSL Key file name」フィールドにキーリング・ファイルの絶対パスを入力します。

7. SSLポート番号の値を希望のポート番号に変更します。

8. SSLポートのステータスを有効にします。

9. クライアント証明書の認証について、「Client Certificate」の「Yes」を選択します。

10. 「Save and Close」をクリックしてすべての変更内容を保存します。

11. Webサーバーを再起動します。
次に例を示します。

/opt/lotus/bin/server

Dominoセキュリティ(DSAPI)フィルタのインストール

DominoセキュリティAPIフィルタ(DSAPI)は、DLLをDomino Webサーバーに登録するための認証方式です。この場合、認証のリクエストが発生すると、Webサーバーは、SSLまたは基本認証を使用するかわりにWebgate DLLをコールしてユーザーを認証します。

Oracle Access Manager DSAPIフィルタを使用する場合、Domino内の認証はオプションです。認証においてデフォルトのWebサーバーではサポートされていない特定の側面を実装できます。

タスクの概要: Webgateとフィルタのインストールの完了

1. WebgateをDomino Webサーバーにインストールする前に、これまで説明したすべての手順を完了してください。

2. 「OAM 11g用の最新OAM 10g Webgateの検索およびインストール」の説明に従って、WebgateのインストールとWebサーバーの更新を実行します。

3. 「Webgateインストールの完了」を参照して、説明されている2つのオプションから1つを選択します。

Webgateインストールの完了

Domino WebサーバーでWebgate DLLを使用できるようにするには、サーバー・ドキュメントの「Internet Protocols」タブの下の「HTTP」タブにある「DSAPI filter file names」フィールドで、認証のためにコールされるようにDLL(DSAPIライブラリ)の名前を編集または入力する必要があります。

注意:
相対パスは、Dominoの実行可能ファイル・ディレクトリに基づきます。DSAPIフィルタ・ライブラリは、イベントを処理するときにこのリストの順にコールされます。

フィルタをインストールするには次の2つの方法があります。

- Webブラウザとnames.nsfを使用(オプション1)

- Lotus NotesワークステーションとAddress Bookを使用(オプション2)

オプション1: names.nsfにアクセスするためにDSAPIフィルタを設定する手順

1. names.nsfのURLに移動してログインします。次に例を示します。

http://hostname:port/names.nsf

2. 「Server-Servers」リンクをクリックします。
Javaアプレットがロードされます。

3. リストからサーバーを選択します。

4. 「Edit Server」リンクをクリックして「Edit」モードにします。

5. 「Internet Protocols」リンクをクリックします。
デフォルトでは「HTTP」タブが選択され、情報が「Edit」モードで表示されます。

6. 「DSAPI filter file names:」でDSAPIを探し、libwebgate.soファイルの絶対パスを入力します。

7. 変更を保存します。

8. Domino httpサーバー・タスクを再起動します。

オプション2: Lotus Notesを介してAddress Bookにアクセスする手順

1. Domino Name and Address bookを開きます。次のように選択します。
「File」→「Database」→「Open」を選択し、「Address Book」をクリックします。

2. サーバー表示に切り替えて、サーバー・ドキュメントを開きます。

3. サーバー・ドキュメントを編集します。

4. 「Internet Protocols」タブをクリックします。
デフォルトでは「HTTP」タブが選択され、情報が「Edit」モードで表示されます。

5. 「DSAPI filter file names:」でDSAPIを探し、libwebgate.soファイルの絶対パスを入力します。

6. 変更を保存します。

7. Domino httpサーバー・タスクを再起動します。

第VIII部

付録

第VIII部では、Oracle Access Manager 11gの日常の管理タスクの範囲以外の情報を説明します。

第VIII部には次の付録が含まれます。

- 付録A「共存の概要: OAM 11gとOSSO 10g」

- 付録B「OAM 11gのソース環境からターゲット環境への移行」

- 付録C「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合」

- 付録D「OAM 10g Webgateの国際化とマルチバイト・データ・サポート」

- 付録E「Oracle Access Manager 11gとの安全な通信」

- 付録F「管理者用カスタムWLSTコマンドの概要」

- 付録G「IPv6クライアント用のOAM 11gの構成」

- 付録H「デプロイメント固有ページの作成」

- 付録I「トラブルシューティング」

A 共存の概要: OAM 11gとOSSO 10g

既存のOracleAS SSO 10gリリース(10.1.2.0.2)をOracleAS SSO 10gリリース(10.1.4.3.0)を経由してOracle Access Manager 11gにアップグレードできます。この章では、Oracle Access Manager 11g SSOを使用するためにOracleAS 10g SSO (OSSO)をアップグレードするときに提供される共存について説明します。内容は、次のとおりです。

- 前提条件

- アップグレードとOracleAS 10g SSOとの共存の概要

- アップグレード前および後のトポロジおよび認証の例

- アップグレード後のOAM 11gとの共存の検証の概要

- アップグレード後の共存の検証

前提条件

アップグレード手順については、『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』を参照してください。

アップグレードとOracleAS 10g SSOとの共存の概要

「アップグレード」という用語は、Oracle製品のバージョンおよびテクノロジ間の移動を指すときに使用します。たとえば、OC4JからOracle WebLogic Serverへの移動はアップグレード、OracleAS 10g SSOからOAM 11g SSOへの移動もアップグレードになります。

注意:
「移行」という用語は、Oracle以外のテクノロジ・スタックからOracleのテクノロジ・スタックへの移動に使用します。

Oracleが提供するアップグレード・アシスタントは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーム情報を入力として受け入れ、構成されたパートナ・アプリケーションを目的のOracle Access Manager 11g SSOへ転送します。

関連項目:
Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド

通常のOSSOデプロイメントには、フロントエンド・ロード・バランサを含むOSSOが多数含まれます。クラスタ内のすべてのOSSOサーバーには同じバックエンド・ストアが含まれます。ロード・バランサは認証要求をクラスタ内のOSSOサーバーにルーティングします。

共存には、OAM 11gとOSSO 10gが同じバックエンド・ユーザー・アイデンティティ・ストアであるOracle Internet Directory(OID)を使用することが必要です。OAM 11gは1つのOSSOサーバーまたはOSSOサーバーのクラスタと共存します。動的リダイレクトはOSSO 10gおよびOAM 11gにより保護されているアプリケーションの予想通りに動作する必要があります。

アップグレード・プロセス中に、OSSO 10gに登録されたパートナ・アプリケーションは関連するOracle HTTP Server Agent、対応するホスト識別子、およびその他の詳細とともにOAM 11gに転送されます。OAM 11gは既存のOSSO 10gサーバーのフロントエンド・ロード・バランサに追加されます。

注意:
既存のOSSO 10g構成に、直接マップできない、即時利用可能な構成が含まれている場合、自動的なアップグレード・プロセスの終了後に、管理者はこれらを手動で転送する必要があります。

アップグレード後、OAM 11gは1つのOSSOサーバーまたはOSSOサーバーのクラスタと共存します。既存のパートナ・アプリケーション(Portal、Forms、ReportsおよびDiscovererなど)はSSOプロバイダとしてOracle Access Manager 11gの使用を開始します。ロード・バランサはOAMサーバーへの認証要求の一部をルーティングし、残りは既存のOSSO 10gサーバーによりサービスが継続されます。ユーザーがOSSO 10gまたはOAM 11gサーバーのいずれかにより認証されると、再認証を必要とせずにパートナ・アプリケーションにアクセスできます。

詳細は、「アップグレード前および後のトポロジおよび認証の例」を参照してください。

アップグレード前および後のトポロジおよび認証の例

この項の内容は次のとおりです。

- アップグレード前のOSSO 10gトポロジについて

- アップグレード後のトポロジと共存について

- フロントエンド・プロキシ・サーバー上のmod_oc4jを含む1つのOSSO 10g

- アップグレード後: mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

- アップグレード後: プロキシ・サーバーなし

関連項目:
「アップグレード後のOAM 11gとの共存の検証の概要」

アップグレード前のOSSO 10gトポロジについて

通常のOSSO設定には、フロントエンド・ロード・バランサのあるOSSOが多数含まれます。クラスタ内のすべてのOSSOサーバーには同じバックエンド・ユーザー・アイデンティティ・ストアがあります。図A-1に示すように、ロード・バランサは認証要求をクラスタ内のOSSOサーバーにルーティングします。

図A-1 アップグレード前のOSSO 10gトポロジ

「図A-1 アップグレード前のOSSO 10gトポロジ」の説明

関連項目:
「フロントエンド・プロキシ・サーバー上のmod_oc4jを含む1つのOSSO 10g」

フロントエンド・プロキシ・サーバー上のmod_oc4jを含む1つのOSSO 10g

図A-2に、OHS(パートナ)が保護されているアプリケーションのフロントエンドとなっている簡単な状況を示します。OHS(OSSO)はOC4J OSSOアプリケーション・サーバー・ホストを保護するフロントエンド・プロキシWebサーバーです。これは内側にOSSO OC4Jサーバーがある場合にのみ必要です。

図A-2 アップグレード前のフロントエンド・プロキシのあるOSSO 10gの例

「図A-2 アップグレード前のフロントエンド・プロキシのあるOSSO 10gの例」の説明

アップグレード後、環境はOracle Access Manager 11gを認証用に使用するように構成されます。

アップグレード後のトポロジと共存について

OAM 11gへのアップグレードは、新しいOAM 11gサーバーのインストールと、このOAMサーバーへのパートナ・アプリケーションの転送から開始します。

既存のOSSOサーバーの1つが停止されます。OAM 11gサーバーは停止したOSSOサーバーを置き換え、ロード・バランサは新しく追加されたOAM 11gサーバーへの認証要求のルーティングを開始します(残りのOSSO 10gサーバーへの認証要求のルーティングは継続します)。

注意:
時間の経過とともに各OSSO 10gサーバーはOAM 11gサーバーに置き換えられる必要があります。

アップグレードされたOSSOの設定を図A-3に示します。

図A-3 アップグレード後のOSSO 10gトポロジ

「図A-3 アップグレード後のOSSO 10gトポロジ」の説明

ユーザーがパートナ・アプリケーションにシングル・サインオンでアクセスできるようにするために、OAM 11gは認証ユーザーとしてOSSOサーバーにより認証されたユーザーを受け入れます。また、OAM 11gがユーザーを検証する場合、OSSOサーバーが理解できる適切なcookieも設定します。OSSOサーバーは再度ユーザーを検証する必要はありません。

ユーザーがOSSO 10gまたはOAM 11gのいずれかにより認証されると、いずれかのサーバーにより保護されているすべてのパートナ・アプリケーションにアクセスできます。OAM 11gおよびOSSO 10gはシングル・サインオンを実現するために適切なcookieを設定します。

関連項目:
「シングル・サインオンのCookieについて」

OAM 11gは各要求に対するセッションを作成し、そのセッションIDを含むcookieを設定します。このcookieにより表されるセッションには、その他の詳細の中の認証されたユーザーのJAASサブジェクトが含まれます。

注意:
OSSO 10gでは、サーバーはログイン・ユーザーに関する情報を含むホストcookieを設定します。

詳細は、次を参照してください。

- アップグレード後: mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

- アップグレード後: プロキシ・サーバーなし

アップグレード後: mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

アップグレード後の観点からすると、Oracle Access Manager 11gは認証のために使用されます。OSSO 10gサーバーのフロントエンドとなっているOracle HTTP Serverは、Oracle Access Manager 11gがインストールされているOracle WebLogic Serverを指します。つまり次のことを表しています。

- OHSパートナ: mod_ossoはプロキシ経由で認証のために11g OAMサーバーに要求をリダイレクトします。

- プロキシ: mod_wlはmod_oc4jを置き換えます。mod_wlにより、Oracle HTTP Server側で何も変更することなく、シングル・サインオンを動作させることができます。

図A-4に、mod_oc4jを置き換えるmod_wlを含むアップグレード後のトポロジを示します。

図A-4 mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え

「図A-4 mod_wlによるプロキシ・サーバー上のmod_oc4jの置き換え」の説明

関連項目:
「アップグレード後: プロキシ・サーバーなし」

アップグレード後: プロキシ・サーバーなし

この例では、以前mod_oc4jを含んでいたプロキシ・サーバーが完全に消去されています。10g OSSOサーバーのフロントエンドとなっているOracle HTTP Serverは、Oracle Access Manager 11gがインストールされているOracle WebLogic Serverを直接指します。

図A-5に、ほとんどのデプロイメントで使用している、このトポロジを示します。

図A-5 プロキシ・サーバーなしの一般的なトポロジ

「図A-5 プロキシ・サーバーなしの一般的なトポロジ」の説明

アップグレード後のOAM 11gとの共存の検証の概要

この項の内容は次のとおりです。

- アップグレード後のSSOについて

- アップグレード後のOSSO 10g認証について

アップグレード後のSSOについて

図A-6に、OAM 11gとOracleAS 10g SSOが共存するアップグレードされた環境での、OAM 11g SSOによる認証を示します。詳細は、図の後に説明します。

図A-6 共存処理

「図A-6 共存処理」の説明

処理の概要: パートナ・アプリケーション間のシングル・サインオン

1. ユーザーはOSSO 10gからOAM 11gにアップグレードされたパートナ・アプリケーションにアクセスします。
ロード・バランサはユーザーの認証要求をOSSO 10gサーバーにルーティングし、そこでログイン・ページが提供されます。認証が正常に終了すると、OAMはSSO cookieを設定し、それに従ってセッション情報を更新します。cookieには、このcookieが有効であるためにOSSO cookieも存在する必要があることを示すフラグが含まれます。

2. ユーザーがOSSO 10gにより保護されているアプリケーションを使用し、OSSO 10g cookieがすでにブラウザに設定されている場合、ユーザーは資格証明を要求されず、アプリケーションにアクセスできます。

3. OAM 11gおよびOSSO 10gの両方のcookieは一致している必要があります。OSSO 10g cookieで更新されたセッション情報は、OAM 11g cookieと同期している必要があり、逆も同様です。

アップグレード後のOSSO 10g認証について

図A-6に示すように、ユーザーはパートナ・アプリケーションにアクセスし、ユーザーの認証要求はロード・バランサによりOSSO 10gにルーティングされます。ここで、OSSOサーバーはログイン・ページを表示し、ユーザーの資格証明を収集および検証後、OSSO cookieのみがユーザーのブラウザに設定されます。

図A-7 共存とOSSO 10g認証

「図A-7 共存とOSSO 10g認証」の説明

処理の概要: アップグレード後のOSSO 10g認証

1. ユーザーがOAM 11gサーバーにより保護されているパートナ・アプリケーションにアクセスする場合、OAMサーバーはログイン・ページを表示する前に、まず有効なOSSO cookieがすでに存在するかどうかをチェックする必要があります。

2. 有効なOSSO cookieがすでに存在する場合、OAM 11gサーバーはOSSO cookieからOAM 11g SSO cookieを作成する必要があります。OAMサーバー構成には、共存モードが有効かそうでないかを示すフラグがあります。共存モードが有効な場合、OAMサーバーはOAM 11gサーバーのSSO Cookieとともに存在するOSSO cookieを探します。このフラグは構成で手動でオンにした後にサーバーを再起動するか、または、WLSTコマンドを使用して共存フラグをオンおよびオフにできます。

3. ユーザーがパートナ・アプリケーションからログアウトして、ログアウト・リクエストが10g OSSOサーバーにルーティングされると、OSSOサーバーはOSSO cookieを削除します。共存が有効で、10g SSOおよび11g OAMサーバーの両方がロードバランサの背後にある場合、パートナ情報はすべてのサーバー(10g OSSOまたは11g OAMサーバー)で共有されます。そのため、パートナ・アプリケーションを含むサーバー(10gまたは11g)のいずれかと関連付けることは正しくありません。アップグレード中に、すべてのパートナ情報も11g OAMサーバーに移行されます。

4. OSSO Cookieが削除された後、ユーザーが保護されているアプリケーションにアクセスしようとして、その要求がOAM 11gサーバーに到達した場合、OAMサーバーのSSO Cookieのみが見つかります。構成での共存フラグから、設定が共存モードになっていることをサーバーが認識します。共存モードでは、OSSO cookieはOAM11gサーバーCookieが有効であるために存在している必要があります。したがって、ログイン・ページがスローされ、ユーザーは検証を求められます。

5. OAM 11gサーバーはOSSOおよびOAM cookieの両方のセッション情報が必ず一致するようにする必要があります。

アップグレード後の共存の検証

この項の内容は次のとおりです。

- アップグレード後の登録とポリシーの検証

- Oracle Access Managerにより保護されているリソースを含むアップグレード後のSSOの検証

- OSSOにより保護されているリソースを含むアップグレード後のSSOの検証

アップグレード後の登録とポリシーの検証

次の各項目で、転送されたOSSO 10gの詳細をOracle Access Managerコンソールで探す際に役立つ情報を提供します。

- OSSO 10gを使用して保護されているパートナ・アプリケーションの例

- ポリシー施行エージェントの詳細

- 共有コンポーネント: migratedSSOPartnersのホスト識別子

- migratedSSOPartnersアプリケーション・ドメインのリソース

- migratedSSOPartnersアプリケーション・ドメインの認証ポリシー

関連項目:
「アップグレード後のOAM 11gとの共存の検証の概要」

OSSO 10gを使用して保護されているパートナ・アプリケーションの例

OSSO 10gを使用するパートナ・アプリケーションのサンプルの詳細を示し、OSSO 10g構成とOracle Access Manager 11g用のアップグレードされた構成を比較できます。

表A-1に、OracleAS 10g OSSOにより保護されているアプリケーションを示します。

表A-1 OSSO 10gにより保護されているパートナ・アプリケーション

アプリケーション名

ホスト

Oracleホーム

oid1_ad2003_lowenthal.vm

ad2003.lowenthal.vm

C:\oracle\oid

portal1_ad2003_lowenthal.vm

ad2003.lowenthal.vm

C:\oracle\portal

Oracle Portal(ポータル)

ad2003.lowenthal.vm

C:\oracle\portal

各アプリケーションのOSSO 10g構成詳細には、管理者が割り当てた次のものが含まれます。

- 名前

- ホームページURL

- 成功URL

- ログアウトURL

- サーバーにより許可されたアプリケーションへのログインの日付範囲

OSSO 10g構成には次のものも含まれます。

- 一意のアプリケーションID

- 認証の要求時にパートナにより使用されるアプリケーション・トークン

- アプリケーションの識別のためにOSSOサーバーが使用する暗号化鍵

- ログインURL

- シングル・ログアウトURL

ポリシー施行エージェントの詳細

OracleAS 10g SSOデプロイメントの各アプリケーション(表A-1)に対し、Oracle HTTP Serverインスタンスがあります。各OHSインスタンスはアプリケーションに由来する名前のOSSOエージェントとして転送します。Oracle Access Managerコンソールで、ナビゲーション・ツリーの「エージェント」ノードの「システム構成」タブで、転送された各OSSOエージェントの構成を探すことができます。

このトピックの図で、表A-1で識別されるアプリケーションに対する転送されたOSSOエージェント構成を示します。生成された各エージェント構成は、それを保護するアプリケーションとして名前が付けられます。

10gアプリケーションIDはOAM 11gのエージェント構成に記録されませんが、次に示すほとんどの構成詳細は含まれていて、同じままです。

- サイト・トークン: アプリケーション・トークンです。

- ログインURL

- シングル・ログアウトURL

- 成功URL

- 失敗URL

- 開始日

図A-8にOSSO 10gにより保護されているアプリケーション用に生成されたエージェント構成を示します。詳細は自動化されたアップグレード処理中にOSSO 10g Oracle Internet Directoryから導出されました。

図A-8 1つのアプリケーションに由来する名前が付けられたOSSOエージェント構成

「図A-8 1つのアプリケーションに由来する名前が付けられたOSSOエージェント構成」の説明

図A-9に、OracleAS 10g SSO (OSSO)により保護されている2番目のアプリケーションに対する転送された構成を示します。

図A-9 2番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成

「図A-9 2番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成」の説明

図A-10に、OracleAS 10g SSO (OSSO)により保護されている3番目のアプリケーションに対する転送されたOSSOエージェント構成を示します。

図A-10 3番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成

「図A-10 3番目のアプリケーションに由来する名前が付けられたOSSOエージェント構成」の説明

共有コンポーネント: migratedSSOPartnersのホスト識別子

図A-11は、転送されたホスト識別子を示します。使用されるアプリケーション・ドメイン名であるという理由で、これにはmigratedSSOPartnersという名前が付けられています。詳細は自動化された転送処理中にOSSO 10g Oracle Internet Directoryから導出されました。

図A-11 migratedSSOPartnersのホスト識別子

「図A-11 migratedSSOPartnersのホスト識別子」の説明

migratedSSOPartnersアプリケーション・ドメインのリソース

図A-12に、転送およびリソースの定義中に作成されたアプリケーション・ドメインを示します。詳細は自動化された転送処理中にOSSO 10g Oracle Internet Directoryから導出されました。

アプリケーション・ドメインおよびリソース定義の両方にmigratedSSOPartnersという名前が付けられます。

図A-12 migratedSSOPartnersアプリケーション・ドメインのリソース

「図A-12 migratedSSOPartnersアプリケーション・ドメインのリソース」の説明

migratedSSOPartnersアプリケーション・ドメインの認証ポリシー

図A-13に、アプリケーション・ドメインmigratedSSOPartnersのProtected Resource Policyという名前の認証ポリシーを示します。

デフォルトのOAM 11g認証スキームLDAPSchemeが使用されます。

図A-13 migratedSSOPartnersアプリケーション・ドメインの認証ポリシー

「図A-13 migratedSSOPartnersアプリケーション・ドメインの認証ポリシー」の説明

Oracle Access Managerにより保護されているリソースを含むアップグレード後のSSOの検証

次の手順を使用して、Oracle Access Manager 11gを使用してアップグレードされた環境で、シングル・サインオンが発生していることを確認できます。

「Oracle Access Managerにより保護されるリソースを含むアップグレード後のSSOの検証」の手順を実行して、OAM 11gにより保護されるリソースがOAM 11gを介してアクセスされていることを確認します。

SSOがOracle Access Manager 11gとともに動作することを確認する手順

1. 10g OSSOサーバーをホストしているコンピュータのOracle HTTP Serverを停止します。

2. 11g OAMサーバーを再起動します。

3. Oracle Access Managerコンソールで、次のことを行います。

- システム構成、エージェント: アップグレードした10gパートナ・アプリケーションに適切なエージェント構成が含まれていることを確認します。

- ポリシー構成、共有コンポーネント:新しいホスト識別子の定義migratedssopartnersが作成されたことを確認します。

- ポリシー構成、アプリケーション・ドメイン:

- 新しいアプリケーション・ドメインmigratedssopartnersが作成されたことを確認します。

- 新しいアプリケーション・ドメインで、migratedssopartners用のリソースが存在することを確認します。

- 新しいアプリケーション・ドメインで、認証ポリシーProtected Resource Policyが適切なホスト識別子で存在することを確認します。

4. パートナ・アプリケーションにアクセスし、認証がOracle Access Manager 11gを介して発生することを確認します(11g用のログイン・フォームを確認)。

5. 次の手順を行います。

- 成功: 「OSSOにより保護されるリソースを含むアップグレード後のSSOの検証」を使用して続行します。

- 不成功: 必要なすべての手順が完了しているかどうかを確認します。

OSSOにより保護されているリソースを含むアップグレード後のSSOの検証

次の手順を使用して、OSSO 10gにより保護されるリソースおよびOracle Access Manager 11gにより保護されるリソースを含む環境でのアップグレード後に、シングル・サインオンが発生していることを確認できます。

OSSOにより保護されるリソースを含むアップグレード後のSSOの確認手順

1. OAMにより保護されるリソース: 「Oracle Access Managerにより保護されるリソースを含むアップグレード後のSSOの検証」の手順を実行して、OAM 11gにより保護されるリソースがOAM 11gを介してアクセスされていることを確認します。

2. OSSOにより保護されるリソース: 次の手順を実行して、OSSOにより保護されるリソースがOSSO 10gを介してアクセスされていることを確認します。

1. OAMサーバーを停止します。

2. 10g OSSOサーバーをホストしているコンピュータでOracle HTTP Serverを再起動します。

3. OSSOにより保護されるリソースにアクセスして、10g OSSOサーバーが認証されていることを確認します(10g OSSOログイン・ページ)。

3. OAMサーバーを再起動します。

B OAM 11gのソース環境からターゲット環境への移行

この章では、既存の、プロビジョニングされたOracle Access Manager 11g (ソース)環境からレプリカ(ターゲット)のOracle Access Manager 11g環境を作成する場合について説明します。この方法は、テストしたロールアウトのアップグレードに使用できます。

この情報は、使用するソースがテスト環境か本番環境かに関係なく適用されます。この章には次のトピックが含まれます。

- 前提条件

- 移行の概要

- 移行の方法とツールの概要

- 移行の計画

- Oracle Access Manager 11gデータの移行

前提条件

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従い、ターゲット・コンポーネントをインストールおよび構成します。

関連項目:
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

移行の概要

ここでは、次の内容について説明します。

- デプロイメント・タイプについて

- Oracle Access Managerデータについて

- 共通の移行タスクについて

- 新しいターゲット環境と既存のターゲット環境の比較について

デプロイメント・タイプについて

表B-1で、顧客の企業内のデプロイメント・タイプについて説明します。デプロイメント・タイプの名前は企業によって異なる可能性があります。

表B-1 デプロイメント・タイプ

デプロイメント・タイプ

説明

開発デプロイメント

理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限

QAデプロイメント

通常、テスト用に使用される、比較的小さな共有されたデプロイ

本番前デプロイメント

通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント

本番デプロイメント

日常的に企業内で完全に共有および使用可能

Oracle Access Managerデータについて

各デプロイメント内で、Oracle Access Manager 11gの構成データはファイルに保存されますが、Oracle Access Manager 11gのポリシー・データはデータベースに保存されます。ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。

ポリシー構成側では、各アプリケーション・ドメインは次の共有コンポーネントを使用して構築されます。

- 認証モジュール

- 認証スキーム(1つの認証モジュールを含む)

- ホスト識別子

- リソース

システム構成側では、保護する必要があるのはエージェント、ホスト・リソース、またはパートナ・アプリケーションです。エージェントは、OAMエージェント(Webgateまたはアクセス・クライアント)である場合も、OSSOエージェントである場合もあります。各エージェントはホストされたリソースを保護するOAM 11gに登録される必要があります。エージェントの登録はレプリケーション時に自動的に行われ、さらに次のことも行われます。

- エージェントとその特有の構成パラメータの定義

- 指定されたリソースのアプリケーション・ドメインの作成

- パートナ・アプリケーションのデフォルトの認証スキームでの認証ポリシーの作成

- 指定されたリソースの認証ポリシーの作成

- パートナ・アプリケーションの対象鍵の生成

ソース環境からターゲット環境へのポリシーおよびパートナ情報の移行は、ソース環境のAdminServerでMBeanを登録することで行われます。クライアントは、パートナおよびポリシー情報をソース・サーバーからフェッチしてターゲット・サーバーへ適用するために使用されます。

次の概要で、ポリシーおよびパートナ情報をソースOAMサーバーからターゲットへ移行するために実行する必要がある一般的なタスクの範囲を示します。

注意事項:

- Oracle Security Token Service: パートナおよびポリシーのみが移行されます。他のサーバー・アーティファクト(パートナ・プロファイル、検証/発行テンプレート)は移行されません。

- Oracle Access ManagerおよびOracle Security Token Service: キーストアおよび信頼アンカー移行は、手動で行う必要があります。

共通の移行タスクについて

次のタスクは、一般にはソースからターゲットへの移行に含まれます。タスク1は、この章で説明します。残りのトピックは、実際の移行(タスク8)も含め、『Oracle Fusion Middleware管理者ガイド』で説明します。

タスク概要: ターゲット環境への移行には、通常は次の作業が含まれます。

1. 移行の計画

2. ターゲット環境の準備

3. ターゲット環境でのデータベースのインストール

4. Middlewareホームおよびバイナリ・ファイルの移行

5. Javaコンポーネントの構成の移行

6. システム・コンポーネントの構成の移行

7. コンポーネントのユーザー、グループ、セキュリティ・ポリシーおよび資格証明ストアの構成

8. Oracle Fusion Middlewareコンポーネントの移行(Oracle Access Manager with Oracle Security Token Serviceを含む)

新しいターゲット環境と既存のターゲット環境の比較について

Oracle Access ManagerおよびOracle Identity ManagerはOracle Fusion Middleware 11gのコンポーネントです。

Oracle Access Manager 11gの移行は、より大きな作業の中の一部です。アイデンティティ管理環境全体をソースからターゲットに移動するのに必要なタスクの範囲における違いを、表B-2に示します。

表B-2 データの新しいターゲット環境への移行と既存のターゲット環境への移行の違い

新しいターゲット環境

既存のターゲット環境

この例では、ソース環境の既存のアイデンティティ管理コンポーネントを、まだ存在しない新しいターゲット環境に移行します。

これには次のタスクが必要です(タスク1は必須ですが、他のタスクはデプロイメントに基づいて必要になります)。すべては、『Oracle Fusion Middleware管理者ガイド』で詳細に説明しています。

この例では、ソースのセキュリティ関連の構成を保持しながら、1つまたは複数のアプリケーションをソースから既存の環境のターゲットに移動します。

これにはアプリケーション固有のデータおよび増分変更をソースからターゲットに移行することが必要であり、詳細は『Oracle Fusion Middleware管理者ガイド』で説明しています。

1. データベース、Middlewareホーム、およびドメイン構成を新しいターゲット環境へコピーします

2. Oracle Internet Directoryを新しいターゲット環境に移動します

3. Oracle Virtual Directoryを新しいターゲット環境に移動します

4. Oracle Directory Integration Platformを新しいターゲット・システムに移動します

5. Oracle Access Manager 11gを新しいターゲット環境へ、「Oracle Access Manager 11gデータの移行」の説明に従って移動します

6. Oracle Access Manager 10gを新しいターゲット環境に移動します

7. Oracle Identity Federationを新しいターゲット環境に移動します

8. Oracle Adaptive Access Managerを新しいターゲット環境に移動します

9. Oracle Identity Navigatorを新しいターゲット環境に移動します

10. Oracle Identity Managerを新しいターゲット環境に移動します

11. 監査ポリシーを新しいターゲット環境に移動します

12. Oracle Platform Securityを新しいターゲット環境に移動します

13. Oracle Web Services Managerを新しいターゲット環境に移動します

1. Oracle Internet Directoryを既存のターゲット環境に移動します

2. Oracle Access Manager 11gを既存のターゲット環境へ、「Oracle Access Manager 11gデータの移行」の説明に従って移動します

3. Oracle Access Manager 10gを既存のターゲット環境に移動します

4. Oracle Identity Federationを既存のターゲット環境に移動します

5. Oracle Adaptive Access Managerを既存のターゲット環境に移動します

6. Oracle Identity Managerを既存のターゲット環境に移動します

7. Oracle Identity Navigatorを既存のターゲット環境に移動します

8. Oracle Platform Securityを既存のターゲット環境に移動します

9. Oracle Web Services Managerを既存のターゲット環境に移動します

移行の方法とツールの概要

この項では、Oracle Security Token Serviceを使用したOracle Access Manager 11gを移行するための方法とツールの概要を説明します。

関連項目:
Fusion Middlewareレプリケーション・ツールおよび方法の詳細は、『Oracle Fusion Middleware管理者ガイド』の手順「アイデンティティ管理の新しい本番環境への移行」のタスク5「Oracle Access Manager 11gの新しい本番環境への移行」を参照してください。

- Oracle Access Managerソース・データを伝播する方法について

- OSSOパートナのあるOAMインスタンスから別のインスタンスへの移行について

- ターゲット・ユーザー・アイデンティティ・ストアの構成とデータの移行について

Oracle Access Managerソース・データを伝播する方法について

ソース・データを伝播するには、データ(ソースのユーザーおよびグループ、アイデンティティ・ストアおよびポリシー・ストア、資格証明)をエクスポートしてからターゲットにインポートする必要があります。新しい環境に固有の情報(たとえばホスト名またはポート)の変更も必要になる場合があります。

注意:
エージェントはレプリケーション時に再登録されます。エージェントを再登録する必要はありません。

プロビジョニングされたOracle Access Manager 11gソース環境のデータをレプリケートするときは、次に示すいずれかの方法を使用できます。これらの方法には、Oracle Security Token Serviceのパートナおよびポリシーが含まれます。OAMパートナおよびエージェントのプライマリ・サーバーとセカンダリ・サーバーのリストは、差分移行の場合のみ役に立ちます。

- 完全レプリケーション

- 差分レプリケーション

注意:
完全レプリケーション方法では、ソースをコピーしてターゲットを作成します。ターゲットが存在する場合は、処理中に完全に消去されます。既存のターゲット環境を維持するためには、新しいターゲット環境を作成する必要があります(または、完全移行手順を使用しないでください)。
いずれの方法を選択する場合も、次のことが適用されます。

- Oracle Security Token Service: パートナおよびポリシーのみが移行されます。他のサーバー・アーティファクト(パートナ・プロファイル、検証/発行テンプレート)は移行されません。

- Oracle Access ManagerおよびOracle Security Token Service: キーストアおよび信頼アンカー移行は、手動で行う必要があります。

完全レプリケーション

表B-3は、完全データ・レプリケーション(パートナおよびポリシー)について説明します。手動および自動化されたタスクを実行することで、Oracle Access Manager 11gソース設定をターゲットへレプリケートできます。完全な設定(Oracle Fusion Middleware)レプリケーションについては、『Oracle Fusion Middleware管理者ガイド』を参照してください。

表B-3 完全レプリケーション

要件

手動および自動化されたタスク

不要または処理済

- ユーザー・ストアがすでにターゲットOAMサーバーに構成されています。

- ソースOAMサーバーと通信する同じクライアントおよびパートナもターゲットOAMサーバーと通信します。

次のWLSTコマンドが使用されます。

- Export: ソース・アプリケーション・ドメインおよびポリシーをレプリケートおよびエクスポートします。

- Import:
ソース構成および競合解決プロファイルをターゲットにインポートします。

両方の環境が同じになるように、ポリシーをソースから移行します。

ソースに存在しないターゲット・システムのアプリケーション・ドメインを削除します。

管理者は次のことも行う必要があります。

- ターゲット・システムのスキーマをソース・システムのスキーマで置き換えます。

- パートナ

- クライアント

- OAMサーバー

差分レプリケーション

表B-4で要件および増分転送(差分レプリケーションとも呼ばれる)の処理について説明します。ソースのすべての増分変更はターゲットに転送されます。選択的な転送は必要ありません。

表B-4 差分レプリケーション

要件

タスク

不要または処理済

ソースOAMサーバーに"truth"が含まれています。ソースとターゲット間の競合はソースに基づき解決されています。

管理者はWLSTコマンドを"MigrateAll"フラグを"false"に設定して実行し、変更のみをソースからターゲット・システムへ移動します。

変更されていないポリシー構成は処理されません。

OSSOパートナのあるOAMインスタンスから別のインスタンスへの移行について

Oracle Access Managerは、OAM Serverインスタンス間でのパートナの移行をサポートします。これは、パートナ情報を内部から外部のデプロイメントへコピーするGITシナリオでは必須です。

選択したパートナを移行するとき、パートナIDをソース・システムのoam-config.xmlから取得できます。たとえば、サイト名'TEST_OSSO_AGENT2'のOSSOエージェントのパートナIDが998AF964144D39BC2Fの場合は、次のとおりです。

<Setting Name="998AF964144D39BC2F" Type="htf:map">
<Setting Name="AdminId" Type="xsd:string"></Setting>
<Setting Name="SiteName" Type="xsd:string">TEST_OSSO_AGENT2</Setting>

次のコマンドをWLSTプロンプトから実行できます。

exportSelectedPartners(pathTempOAMPartnerFile="<path where the temporary
file need to be generated>",partnersNameList="998AF964144D39BC2F")

ターゲット・ユーザー・アイデンティティ・ストアの構成とデータの移行について

新しいターゲットへ移動する場合も既存のターゲットへ移動する場合も、Oracle Access Manager 11g AdminServerのMBeanを使用するWebLogic Scripting Tool (WLST)コマンドが提供され、それにより管理者は次のことを行うことができます。

- 必要な場合、ターゲット・ユーザー・アイデンティティ・ストアをソース・ユーザー・アイデンティティ・ストアと一致するように構成します。

- アプリケーション・ドメインおよびポリシー・データ(すべてのまたは選択したドメインおよびポリシーのみ)をレプリケートおよび移動します。

- ソースとターゲット・システム間のIDの競合を解決する方法を記述した競合解決プロファイルを(自動的に)提供します。

エクスポートは、アプリケーション・ドメインおよびパートナ情報を一時ダンプ・ファイルにレプリケートしてエクスポートします。この機密情報を保護するために、ダンプ・ファイルを使用してキーストアが生成されます。キーストア内のキーを使用してダンプ・ファイルを暗号化します。

表B-5に、エクスポートするパートナをホストするソースOAMサーバー上で実行する、エクスポート・モード・コマンドの情報を示します。

表B-5 パートナおよびポリシーのエクスポート・コマンド

コマンド

説明

例

exportPartners()

パートナのエクスポートにより、すべてのパートナ情報を含むオブジェクトが、各パートナのキーとともに作成されます。

このコマンドはパラメータとして一時oam-partnersファイルへのパスを受け取ります。

exportPartners(pathTempOAMPartnerFile=' <pathTempOAMPartnerFile>)

exportPolicy()

アプリケーション・ドメインおよびポリシー・データをソースからエクスポートします。OAMアプリケーション・ドメインはすべての依存関係とともにエクスポートされます。

このコマンドはパラメータとして一時oam-policyファイルへのパスを受け取ります。

exportPolicy(pathTempOAMPolicyFile=' <pathTempOAMPolicyFile >')

インポートにより、キーストア内のキーを使用して生成されたダンプ・ファイルの暗号解除が行われ、ダンプ・ファイルの内容がターゲットOAMサーバーにインポートされます。表B-6の説明に従い、パートナ、ポリシーまたはポリシーの差異をインポートできます。インポート・コマンドはターゲットOAMサーバーで実行されます。

表B-6 パートナ、ポリシー、および差分のインポート・コマンド

コマンド

説明

例

importPartners()

キーストア内のキーを使用してパートナ・データを暗号解除してインポートします。

このコマンドはパラメータとしてエクスポート操作中に作成された一時oam-partnersファイルへのパスを入力として受け取ります。

importPartners (pathTempOAMPartnerFile=' <pathTempOAMPartnerFile>')

importPolicy()

アプリケーション・ドメインおよびポリシー・データを暗号解除してインポートします。

注意: このコマンドはターゲット上のすべてのポリシー・データを上書きします。

このコマンドはエクスポート操作中に作成された一時oam-policyファイルへのパスを入力として受け取ります。

importPolicy(pathTempOAMPolicyFile=' <pathTempOAMPolicyFile >')

importPolicyDelta()

ターゲット上の変更されていないポリシー・データを上書きすることなく、ソースからターゲットOAMサーバーへの変更のみを暗号解除します。

注意: このコマンドは変更されたポリシー・データのみをターゲットに書き込みます。

このコマンドはエクスポート操作中に作成された一時oam-policyファイルへのパスを入力として受け取ります。

importPolicyDelta(pathTempOAMPolicyFile=' <pathTempOAMPolicyFile >'

関連項目:
Oracle Access Manager 11gデータの移行

図B-1に、ソースとターゲット・システム間に発生する処理を示します。

図B-1 ソースおよびターゲット処理

「図B-1 ソースおよびターゲット処理」の説明

ポリシー競合解決について

ポリシー競合は、処理中に自動的に解決されます。データの移行中、ソース・システムが唯一の真のソースであると見なされます。ソースとターゲット間で検出された競合は処理中に解決される必要があります。

各アプリケーション・ドメインの依存関係の構築について

OAM 11gアプリケーション・ドメインを移行する前に、移行する各アプリケーション・ドメインに対して依存関係を構築する必要があります。

依存関係は図B-2に示すように表すことができます。

図B-2 各アプリケーション・ドメインの依存関係

「図B-2 各アプリケーション・ドメインの依存関係」の説明

図B-2に示す依存関係の例では、アプリケーション・ドメインが3つの認証ポリシーと2つのリソースから構成されています。各認証ポリシーは認証スキームで構成され、各認証スキームには認証モジュールが構成されています。このサンプルのアプリケーション・ドメインは2つのリソース(各リソースはホスト識別子およびリソースURLとして定義されている)に適用されます。

アプリケーション・ドメインのデータを移行するには、共有コンポーネント(モジュール、スキームおよびホスト識別子)を最初に移行する必要があります(まだ移行されていない場合)。共有コンポーネントのデータ移行に続いて、アプリケーション・ドメイン・データを移行します。

移行の計画

計画と準備は、方針が成功するための重要な要素です。

この項では、移行を成功させるために、作成する必要のあるインベントリ項目と計画の考慮点について説明します。

- 移行方法の選択

- ソースとターゲット環境間に相違がない

- デプロイメント・インベントリの作成

- バックアップ方針およびリカバリ方針の作成

- テストの作成

- 変更伝播について

- スケジュールと通知

移行方法の選択

「Oracle Access Managerソース・データを伝播する方法について」の内容を確認して、最も適した方法を選択してください。

関連項目:
『Oracle Fusion Middleware管理者ガイド』の手順「アイデンティティ管理の新しい本番環境への移行」のタスク5「Oracle Access Manager 11gの新しい本番環境への移行」

ソースとターゲット環境間に相違がない

Oracle Access Manager構成データをソースからターゲットに転送するときに、次に示す、2つの環境間の相違のタイプに必ず注意してください。

- OAMサーバー・インスタンスの名前および実装詳細

- エージェントが指すOAMサーバーへの変更を含む、OAMエージェント(Webgateおよびアクセス・クライアント)の名前および実装詳細

- エージェントが指すOAMサーバーへの変更を含む、OSSOエージェント(mod_osso)の名前および実装詳細

- ホスト識別子の定義

- チャレンジ・リダイレクト・パラメータを含む、認証スキーマの定義

- 認証ポリシー、制約、レスポンスおよびリソースの定義

- 認証および認可ポリシーに定義されたすべてのリダイレクトURLを含む、アプリケーション・ドメインの定義

デプロイメント・インベントリの作成

転送アクティビティを開始する前に、既存のOracle Access Manager 11g Release 1(11.1.1)デプロイメントのインベントリを取得することをお薦めします。既存のインストール・レコードから詳細を収集、またはデプロイメントから直接新しい情報を収集できます。

バックアップ方針およびリカバリ方針の作成

転送前にデータをバックアップし、必要な場合は転送後にバックアップをリストアすることをお薦めします。

テストの作成

転送前にデータの正確性を確認するために、ソース・デプロイメントにおける構成を評価する特定のテストを作成することをお薦めします。

転送後、ターゲット・デプロイメントで同じテストを使用して、すべてが予想通りに動作することを確認できます。

変更伝播について

すべての変更はOracle Access Managerコンソールに反映され、クラスタの各OAMサーバーへ、エージェント登録も含めて自動的に伝播されます。

1つのOAMサーバーと1つのOracle Access Managerコンソールが異なるコンピュータで実行されている場合、変更は管理されたランタイムOAMサーバーに伝播されます。

スケジュールと通知

移動を開始する前に、特定の転送期間をスケジューリングし、他の管理者に、その担当するデプロイメントでの計画されたアクティビティについて通知することを強くお薦めします。

Oracle Access Manager 11gデータの移行

この項は次のトピックに分かれており、これらのトピックは、プロビジョニングされたOracle Access Manager 11gデプロイメントをレプリケートする手順にも含まれています。

- Oracle Access Manager 11gソース・データのエクスポート

- Oracle Access Managerデータのターゲットへのインポート

Oracle Access Manager 11gソース・データのエクスポート

次の手順を必要に応じて使用して、パートナおよびポリシー・データをソース環境からエクスポートします。

前提条件

移行の計画

関連項目:

- ターゲット・ユーザー・アイデンティティ・ストアの構成とデータの移行について

- 『Oracle Fusion Middleware管理者ガイド』

ソース・データをエクスポートする手順

1. パートナ・データのエクスポート: OAM 11gパートナをホストしているソースOAMサーバーで、自分の一時OAMパートナ・ファイルへのパスを使用して次のコマンドを実行します。次に例を示します。

exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>>')

2. ポリシー・データのエクスポート: OAM 11gポリシー・データをホストしているソースOAMサーバーで、自分の一時OAMポリシー・ファイルへのパスを使用して次のコマンドを実行します。次に例を示します。

exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

3. パートナおよびポリシー・データをホストしている各ソースOAMサーバーで繰り返します。

Oracle Access Managerデータのターゲットへのインポート

次の手順を必要に応じて使用して、パートナおよびポリシー・データをソース環境からインポートします。

前提条件

Oracle Access Manager 11gソース・データのエクスポート

関連項目:

- ターゲット・ユーザー・アイデンティティ・ストアの構成とデータの移行について

- 『Oracle Fusion Middleware管理者ガイド』

データをターゲットにインポートする手順

1. パートナ・データのインポート: ターゲットOAMサーバーで、一時ソース・パートナ・ファイルへのパスを使用して次のコマンドを実行します。次に例を示します。

importPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>>')

2. 全ポリシー・データのインポート: ターゲットOAMサーバーで、一時ソース・ポリシー・ファイルへのパスを使用して次のコマンドを実行します。次に例を示します。

importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

3. ポリシー差分のみのインポート: ターゲットOAMサーバーで、一時ソース・ポリシー・ファイルへのパスを使用して次のコマンドを実行します。次に例を示します。

importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

4. パートナおよびポリシー・データをホストしている各ソースOAMサーバーで繰り返します。

C Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合

この章では、同じアイデンティティ管理ドメイン内でのOracle ADFアプリケーションとOracle Access Manager 11gの統合に役立つ情報を提供します。

この章の内容は次のとおりです。

- Oracle Platform Security ServicesおよびOracle Application Developer Frameworkの概要

- Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したOAM 11gとWebアプリケーションの統合

- 実行時のアプリケーションドリブン認証の確認

Oracle Platform Security ServicesおよびOracle Application Developer Frameworkの概要

この項の内容は次のとおりです。

- Oracle Platform Security Servicesシングル・サインオン・フレームワーク

- Oracle Application Developer Framework

Oracle Platform Security Servicesシングル・サインオン・フレームワーク

シングル・サインオン(SSO)ソリューションでは、アプリケーションがユーザーにログインおよびログアウトする標準の方法を提供する必要があります。認証が正常に終了すると、SSOサービスがユーザーを適切なURLにリダイレクトします。

Oracle Platform Security Services(OPSS)SSO FrameworkはSSOソリューションを使用してドメイン内のアプリケーションを統合する方法を提供します。特に、ログイン、自動ログインおよびログアウトを処理する、SSO製品全体のAPIの共通セットをアプリケーションに提供します。

Oracle Application Developer Framework(ADF)とOracle ADF標準にコード化されたアプリケーションは、OPSS SSOフレームワークとのインタフェースです。Oracle ADFの詳細は、「Oracle Application Developer Framework」を参照してください。

Oracle Access Manager SSOソリューションは即時利用可能で、Oracle ADF標準にコード化されたアプリケーションとOPSS SSOフレームワークに次のものを提供します。

- ログイン(アプリケーションドリブン): 認証を必要とするセキュアなアーティファクトの一部にアクセスするときに、アプリケーションは認証を起動し、ユーザーをリダイレクトして適切なソリューションにより認証されるようにします。

- 自動ログイン: アプリケーションに最初にアクセスするユーザーは、アカウントをアプリケーション(Oracle Identity Managerなど)に匿名で登録します。正常に登録されると、ユーザーは認証URLにリダイレクトされます。またユーザーは要求されることなく自動的にログインできます。

- グローバル・ログアウト: ユーザーがアプリケーションからログアウトすると、そのログアウトはソリューションにより有効になっているその他のアプリケーション全体に伝播します。

注意:
OPSS SSOフレームワークはマルチレベル認証をサポートしていません。

SSOソリューションおよびOracle Access Manager 10gソリューションの選択の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の第11章「Oracle Fusion Middlewareにおけるシングル・サインオンの構成」を参照してください。

Oracle Application Developer Framework

Oracle Application Development Frameworkは、Java EE標準およびオープン・ソース・テクノロジで構築され、サービス指向アプリケーションの実装を単純化および迅速化する、エンドツーエンドのアプリケーション・フレームワークです。

ADFアプリケーションのデプロイおよび管理に必要な開発および実行時環境は、その他のJava EEアプリケーションに必要な環境にいろいろな意味で似ています。

一般的なJava EE環境と、Oracle ADFアプリケーションをサポートする環境との違いは、Oracle ADFランタイム・ライブラリが使用できるかどうかです。

- Oracle Fusion Middleware 11gでは、デフォルトでOracle WebLogic Server domainにOracle ADFランタイム・ライブラリは含まれません。しかし、オプションでJavaランタイム・ファイル(JRF)を含むようにドメインを構成または拡張できます。Oracle ADFランタイム・ライブラリはJRFコンポーネントの一部として含まれます。
Oracle WebLogic ServerドメインはJavaランタイム・ファイル(JRF)ドメイン・テンプレートを使用して拡張され、必要なOracle ADFライブラリおよびその他の重要なOracle特有のテクノロジを含むようにできます。

- Oracle Application Server 10gでは、OC4Jの各インスタンスはOracle ADFアプリケーションをサポートするのに必要なOracle ADFランタイム・ライブラリを自動的に提供しました。

10gで使用可能なJava EE環境の種類、それらの環境をOracle Fusion Middleware 11gにアップグレードする手順の詳細は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』を参照してください。

Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したOAM 11gとWebアプリケーションの統合

この項では、Oracle ADFセキュリティおよびOPSS SSOフレームワークを使用するWebアプリケーションと、ユーザー認証用のOracle Access Manager 11g SSOセキュリティ・プロバイダの統合方法について説明します。

Webアプリケーションを実行する前に、Oracle Access Managerセキュリティ・プロバイダ用にアプリケーションのターゲットOracle WebLogic Server上にドメイン・レベルのjps-config.xmlファイルを構成する必要があります。

ドメイン・レベルのjps-config.xmlファイルは次のパスにあり、デプロイされたアプリケーションのjps-config.xmlファイルと混同しないようにします。

domain_home/config/fmwconfig/jps-config.xml

注意:
ドメイン・レベルのjps-config.xmlファイルを、デプロイされたアプリケーションのjps-config.xmlファイルと混同しないようにします。

Oracle JRF WLSTスクリプトを使用して、Webアプリケーションのデプロイ前または後のいずれでも、ドメイン・レベルのjps-config.xmlファイルを構成できます。Oracle JRF WLSTスクリプトの名前は次のようになります。

Linux: wlst.sh

Windows: wlst.cmd

Oracle JRF WLSTスクリプトはJDev経由で実行している場合は、次のパスで使用できます。

$JDEV_HOME/oracle_common/common/bin/

スタンドアロンJRF WebLogicインストールの場合、パスは次のようになります。

$Middleware_home/oracle_common/wlst

注意:
Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files(JRF)のWLSTを実行しているときは、$JDEV_HOME/wlserver_10.3/common/binの下のWLSTスクリプトを使用しないでください。

コマンド構文

addOAMSSOProvider(loginuri, logouturi, autologinuri)

表C-1はaddOAMSSOProviderコマンドラインの各引数に必要な値を定義します。addOAMSSOProvider

表C-1 addOAMSSOProviderコマンドライン引数

引数

定義

loginuri

ログイン・ページのUIRを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、"/<context-root>/adfAuthentication"を'loginuri'パラメータに指定する必要があります。手順を示します。

1. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

2. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

3. OAMには'loginuri'の値を保護するポリシーが存在する必要があります。たとえば、"/<context-root>/adfAuthenticationです。

4. ADFがこのURIにリダイレクトする場合、OAMはログイン・ページ(このURIに対しOAMに設定された認証スキームによる)を表示します。

logouturi

ログアウト・ページのUIRを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、logouturiを第15章のログアウト・ガイドラインに基づいて構成する必要があります。その場合

- 11g Webgateでは、logouturiの値は11g Webgateの管理者から検索される必要があります。

- 10g Webgateでは、logouturiの値は"/oamsso/logout.htmlである必要があります。

autologinuri

自動ログイン・ページのUIRを指定します

Oracle ADF Securityが有効なFusion Webアプリケーション用にドメイン・レベルjps-config.xmlを構成する手順は、より大きなタスクの一部です。コマンド構文を除き、すべてのタスクはOracle Access Manager 10gと11gとで同じです。

関連項目:

- Oracle Access Manager 10g SSOプロバイダを含むすべてのタスクについては、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の章「Oracle Fusion Middlewareにおけるシングル・サインオンの構成」を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・コマンド」

Oracle Access Manager 10g SSOを含むすべてのタスクについては、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の章「Oracle Fusion Middlewareにおけるシングル・サインオンの構成」を参照してください。

- OAM 11g用のSSO構成の例

- SSOプロバイダ構成詳細

OAM 11g用のSSO構成の例

付録C「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合」の手順に従い入力されたSSOサービス構成は、ファイルjps-config.xmlに書き込まれます。指定するデータは次のとおりです。

- 特定のSSOサービス

- 自動ログインおよび自動ログアウトURI

- 認証レベル

- 選択したSSOサービスにより戻されるURLに含まれる問合せパラメータ

- トークン生成に適した設定

次に示すjps-config.xmlファイルの一部は、OAM 11g SSOプロバイダの構成を示します。いくつかの値は実際の内容に対するプレースホルダにすぎません。使用する構成では実装用の値を含む必要があります。

関連項目:
「SSOプロバイダ構成詳細」

例C-1 OAM 11g用のSSO構成の例

<propertySets>
<propertySet name = "props.auth.url">
<property name = "login.url.BASIC" value = "http://host:port/oam_login.cgi?level=BASIC"/>
<property name = "login.url.FORM" value = "http://host:port/oam_login.cgi?level=FORM"/>
<property name = "login.url.DIGEST" value = "http://host:port/oam_login.cgi?level= DIGEST"/>
<property name = "autologin.url" value = " http://host:port/obrar.cgi"/>
<property name = "logout.url" value = "http://host:port/logout.cgi"/>
<property name = "param.login.successurl"  value = "successurl"/>
<property name = "param.login.cancelurl"   value = "cancelurl"/>
<property name = "param.autologin.targeturl" value = "redirectto"/>
<property name = "param.autologin.token"   value = "cookie"/>
<property name = "param.logout.targeturl"   value = "targeturl"/>
</propertySet>

<propertySet name="props.auth.uri">
<property name="login.url.BASIC" value="/${app.context}/adfauthentication?level=BASIC" />
<property name="login.url.FORM" value="/${app.context}/adfauthentication?level=FORM" />
<property name="login.url.DIGEST" value="/${app.context}/adfauthentication?level=DIGEST" />
<property name="autologin.url" value="/obrar.cgi" />
<property name="logout.url" value="/${oamsso/logout.html" />
</propertySet>

<propertySet name = "props.auth.level">
<property name = "level.anonymous" value = "0"/>
<property name = "level.BASIC"    value = "1"/>
<property name = "level.FORM"    value = "2"/>
<property name = "level.DIGEST"   value = "3"/>
</propertySet>
<propertySets>

<serviceProviders>
<serviceProvider name = "sso.provider"
class = "oracle.security.jps.internal.sso.SsoServiceProvider"
type = "SSO">
<description>SSO service provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name = "sso" provider = "sso.provider">
<propertySetRef ref = "props.auth.url"/>
<propertySetRef ref = "props.auth.level"/>
<property name = "default.auth.level" value = "2"/>
<property name = "token.type" value = "OAMSSOToken"/>
<property name = "token.provider.class" value = "oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default = "default">
<jpsContext name = "default">
<serviceInstanceRef ref = "sso"/>
</jpsContext>
</jpsContexts>

SSOプロバイダ構成詳細

次の重要な点に注意してください。

- すべてのSSOプロバイダは、少なくともFORMログイン用のURIをプロパティlogin.url.FORMで定義する必要があります。値はURLである必要はありません。

- アプリケーションで自動登録ページのURIまたはURLがサポートされている場合は、それをプロパティautologin.urlで指定する必要があります。

- SSOソリューションでグローバル・ログアウトのURIまたはURLがサポートされている場合は、それをプロパティlogout.urlで指定する必要があります。OAMソリューションではグローバル・ログアウトがサポートされています。

- 例C-1に示す次のプロパティはオプションです。

- param.login.successurl

- param.login.cancelurl

- param.autologin.targeturl

- param.login.token

- param.logout.targeturl

- プロパティ・セットprops.auth.uri内の値などのURI仕様における変数app.contextは、Oracle Access Managerソリューションとの統合時にADFアプリケーションに対してのみ使用できます。

- プロパティ・セットprops.auth.levelは必須です。

- props.auth.urlへの参照は必須です。

- SSOプロバイダのサービス・インスタンス内のプロパティsso.provider.classは、固有のSSOソリューションを実装するクラスの完全修飾名です。
OAMソリューションの場合、提供されているクラス名はoracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImplです。

- SSOプロバイダのサービス・インスタンス内のプロパティ名default.auth.levelは例C-1に示すように"2"に設定する必要があります。

- SSOプロバイダのサービス・インスタンス内のプロパティ token.typeが必要です。
このトークンのタイプは、正常な認証後にSSOプロバイダが発行するHTTPリクエストのトークン・セットを特定します。2回目以降は、このトークンがSSOプロバイダで使用されるので、ユーザーの再認証が不要となり、ユーザーのサインオンが引き続き有効となります。OAMソリューションの場合、例C-1に示されているとおり、トークン・タイプをOAMSSOTokenとします。

- SSOプロバイダのサービス・インスタンス内のプロパティtoken.provider.classは、トークン・クラスの完全修飾名で、プロバイダ固有です。

- 自己登録ロジックを実装し、自己登録が正常に終了した後はユーザーを自動ログインさせるアプリケーションは、OPSS autoLogin APIをコールする必要があります。そしてこのコールを許可するには、アプリケーションにクラスJpsPermissionを含むCredentialMappingという名前のコード・ソース権限を付与する必要があります。
次に示すファイルsystem-jazn-data.xmlの一部は、アプリケーションMyAppへのこの権限の仕様を示します。

<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/MyApp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>CredentialMapping</name>
</permission>
</permissions>
</grant>

実行時のアプリケーションドリブン認証の確認

この章でこれまでに述べたように、これは認証を起動し、ユーザーをリダイレクトして、適切なソリューションで認証されるようにするアプリケーションです。たとえば、認証が必要なセキュアなアーティファクトの一部にユーザーがアクセスしているとアプリケーションが判断すると、この場合はOracle Access Manager 11g SSOを使用して、アプリケーションドリブン認証が起動されます。

実行時にアプリケーションドリブン認証を確認する手順

1. Oracle ADFフレームワークに基づくアプリケーションを作成します。

2. 「Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したOAM 11gとWebアプリケーションの統合」の説明に従い、Oracle Access Manager SSO Securityプロバイダを構成します。

3. 保護されたフィールドにアクセスし、アプリケーションが認証を起動することを確認します。

D OAM 10g Webgateの国際化とマルチバイト・データ・サポート

ここに記載する情報は、OAM 10g Webgateを使用している場合に対象となる可能性があります。

- 国際化とマルチバイト・データ・サポートの概要

国際化とマルチバイト・データ・サポートの概要

Oracle Access Manager 11gは、変更を加えずにどこでも同時にアクセスおよび実行が可能で、ユーザーの母国語とロケール設定でコンテンツを表示する、多言語アプリケーションとソフトウェア製品を提供します。

ロケールとは、システムまたはプログラムが稼働する言語的および文化的な環境のことです。ロケールと関連付けられたデータは、特定の言語および国に対応する言語的および文化的な要件に基づいて、日付、時刻、数値、通貨などの書式設定と解釈に対するサポートを提供します。

Oracle製品のグローバリゼーションは、国際化とローカリゼーションを含む2つの部分からなるプロセスです。国際化(時々"I - 18文字 -N"を意味するI18Nと略される)では、ソフトウェア製品およびアプリケーションが、あらゆるサポートしているオペレーティング・システムが(サポートしている言語で)実行し、US以外のキーボードまたはその他の国固有のハードウェアを装備したコンピュータ上で使用できる必要があります。Oracleアプリケーションは、言語文字列に対してハードコードされた依存性を持たないので、他の製品の非USバージョンと相互動作できます。Oracleアプリケーションは分散環境でマルチバイト文字と差異を処理でき、ユーザーの要求するロケールを検知することもできます。Oracle Access Managerはこれらの要件を満たし、Unicode規格4.0に準拠しています。

ローカライズには個別のファイル・テキストの翻訳が含まれます。Oracle Access Managerを含むOracle製品では、データの書式設定、照合、通貨、日付、時刻およびテキストの方向(右から左または左から右)など、ユーザーの地域の表記規則に従った方法で情報が表示されます。

詳細は、次を参照してください。

- Oracle Access Managerでローカライズされたメッセージの言語

- 双方向言語サポート

- UTF-8エンコーディング

Oracle Access Managerでローカライズされたメッセージの言語

翻訳可能な情報は、エンド・ユーザー情報(すべてのユーザーがアクセス可能)と管理情報(管理者権限を持つユーザー用)の2種類に分類できます。Oracle Access Manager 10.1.4を言語パックなしでインストールすると、英語が管理者およびエンドユーザーのデフォルトの言語になります。10.1.4をOracle提供の言語パックを使用してインストールすると、管理用アクティビティのデフォルトとして使用する言語を選択できます。インストール時に選択するデフォルトの管理者言語に関係なく、英語は常にインストールされます。

注意:
新機能の結果としてマイナー・リリース(10g(10.1.4.2.0)および10g(10.1.4.3))に追加されたメッセージは翻訳されていない可能性があり、英語のみで表示される場合があります。

Oracle Access Manager 10.1.4では、エンド・ユーザーに対して静的アプリケーション・データ(エラー・メッセージ、およびタブ、パネル、プロパティの表示名など)を表D-1で識別されるエンド・ユーザー言語で表示できます。管理情報は、表D-1にリストされた管理者言語でのみ表示できます。管理ページが他の言語で要求された場合は(ブラウザの設定により)、製品のインストール時にデフォルトとして選択されている言語がページを表示するために使用されます。

表D-1 Oracle Access Managerでローカライズされたメッセージの言語

インストール・ディレクトリに対する言語タグ

エンド・ユーザー情報

管理者

en-us

英語

英語

ar-ar

アラビア語

pt-br

ポルトガル語(ブラジル)

ポルトガル語(ブラジル)

fr-ca

フランス語(カナダ)

フランス語(カナダ)

cs-cs

チェコ語

da-dk

デンマーク語

nl-nl

オランダ語

fi-fi

フィンランド語

fr-fr

フランス語

フランス語

de-de

ドイツ語

ドイツ語

el-gr

ギリシャ語

he-il

ヘブライ語

hu-hu

ハンガリー語

it-it

イタリア語

イタリア語

ja-jp

日本語

日本語

ko-kr

韓国語

韓国語

es-mx

スペイン語(南米)

スペイン語(南米)

no-no

ノルウェー語

pl-pl

ポーランド語

pt-pt

ポルトガル語

ro-ro

ルーマニア語

ru-ru

ロシア語

zh-cn

簡体字中国語

簡体字中国語

sk-sk

スロバキア語

es-es

スペイン語(スペイン)

スペイン語

sv-sv

スウェーデン語

th-th

タイ語

zh-tw

繁体字中国語

繁体字中国語

tr-tr

トルコ語

双方向言語サポート

ほとんどの欧米言語は左から右(LTR)、ページの上から下へ書かれます。東アジア言語は通常上から下へ、ページの右から左へ(RTL)へ書かれますが、多くの場合、欧米言語から翻訳された技術書は例外です。

ヘブライ語やアラビア語などの一部の言語は、大部分は右から左へ書かれて読まれます。アラビア語およびヘブライ語では数字の方向は逆になります。テキストは右から左へ書かれますが、ヨーロッパ言語やその他のLTR言語と同様に、文中の数字は左から右へ書かれ、最上位桁が左になります。

LTR言語がRTL言語と混在する場合、ドキュメントまたはコンテンツ全体は双方向と見なされます。Oracle Access Managerは双方向言語をサポートできます。ホスト・コンピュータ上のブラウザが双方向言語を使用するように構成されていれば、Oracle Access Managerはそれを適切に処理します。

注意:
双方向言語サポートを必要とする管理言語はありません。

複数の言語および双方向言語のサポートを提供するために、Oracle Access Manager 10.1.4はエンコード用にUnicode規格をサポートします。

注意:
書く方向は文字のエンコードに影響を与えません。書く方向にかかわらず、データは画面に表示される順序ではなく、論理的な順序、つまり言語を入力するユーザーが使用する順序で保存されます。

UTF-8エンコーディング

新しく10.1.4をインストールした場合も、古いインストールをOracle Access Manager 10.1.4にアップグレードした場合も、UTF-8エンコーディングおよびサポートが自動的に提供されます。環境を変更する必要はありません。以前のリリースと同様に、ディレクトリ・サーバーのデータはUTF-8エンコーディングを使用して格納されます。

注意:
ディレクトリ・データはすべてUTF-8形式です。Oracle Access Managerはディレクトリ内のデータ型の混在をサポートしません。

E Oracle Access Manager 11gとの安全な通信

この付録では、OAM 11gサーバーおよびクライアント(OAMエージェント)がアクセス・プロトコル・チャネルを介して安全に通信できるようにするために必要な情報と手順について説明します。この章の内容は次のとおりです。

- 前提条件

- OAM 11gサーバーとWebgate間の安全な通信の概要

- 証明書モードのOAMテスターのクライアント・キーストア生成

- OAM 11gの証明書モード通信の構成

- OAM 11gの簡易モード通信の構成

前提条件

OAMサーバーが実行中であることを確認してください。

OAM 11gサーバーとWebgate間の安全な通信の概要

OAMサーバーとクライアント(Webgate)間の通信を保護するということは、コンポーネント登録ページ内のNAP (OAPとも呼びます)チャネルに対してトランスポート・セキュリティ・モードを定義することを意味します。チャネルのセキュリティ・レベルは、次のいずれかに指定されます。

- オープン: 暗号化されていない通信
オープン・モードでは、WebgateとOAMサーバー間で認証または暗号化は行われません。WebgateはOAMサーバーのアイデンティティの証明を要求せず、OAMサーバーはすべてのWebgateからの接続を受け入れます。オープン・モードは、通信のセキュリティがデプロイメントで問題にならない場合に使用します。

- 簡易: Oracleにより発行された公開鍵証明書を使用したSecure Sockets Layer(SSL)プロトコルによる暗号化された通信
簡易モードは、プレーン・テキストでパスワードを送信したくないといったセキュリティ上の懸念があるものの、独自の認証局(CA)を管理しない場合に使用します。この場合、OAM 11gサーバーおよびWebgateはOracle CAにより発行および署名された同じ証明書を使用します。詳細は、「簡易モード、暗号化および鍵について」を参照してください。

- 証明書: 信頼されているサード・パーティ認証局(CA)により発行された公開鍵を使用したSSLによる暗号化された通信。
証明書モードは、OAM 11gサーバーとWebgateで異なる証明書を使用し、信頼されているサード・パーティCAにアクセスできる場合に使用します。このモードでは、DESアルゴリズムを使用して秘密鍵を暗号化する必要があります。Oracle Access ManagerコンポーネントはPEM形式でのX.509デジタル証明書のみを使用します。PEMとはプライバシ強化メールのことであり、パスフレーズが必要です。PEM(プライバシ強化メール)形式は秘密鍵、デジタル証明書、および信頼されている認証局(CA)に適しています。望ましいキーストア形式はJKS(Java KeyStore)形式です。詳細は、「証明書モードの暗号化およびファイルについて」を参照してください。

関連項目:
「証明書、認証局および暗号化鍵について」

図E-1に、ユーザー認証および認可中にOAMサーバーおよびWebgateにより使用される通信チャネルを示します。

図E-1 OAMサーバーとWebgateの通信チャネル

「図E-1 OAMサーバーとWebgateの通信チャネル」の説明

プロセスの概要: 認証および認可

1. リクエストはWebgateにより捕捉されます。

2. 認証(資格証明の集合)がHTTPチャネルを通じて発生します。

3. OAMエージェントのみ(mod_ossoでない)で認証がNAPチャネルを通じて発生します。

Secure Sockets Layer(SSL)プロトコルを使用することで、HTTP(HTTPS)チャネルを通じた傍受と介入者攻撃の成功を防ぐことができます。SSLプロトコルはほとんどのWebサーバー製品およびWebブラウザの一部として含まれます。SSLはデジタル証明書を含む、効果および秘密鍵暗号化システムを使用します。Webサーバーまたはディレクトリ・サーバーに対するSSL通信の有効化についての詳細は、ベンダーのドキュメントを参照してください。

PEM(プライバシ強化メール)形式(BASE64エンコードASCII)は秘密鍵、デジタル証明書、および信頼されている認証局(CA)に適しています。OAMサーバーにとっての望ましいキーストア形式はJCEKSで、OAMクライアントの場合はJKS (Java KeyStore)形式です。Oracle Access Managerコンポーネントは、DER (バイナリ形式の証明書)形式のみのX.509デジタル証明書を使用します。

詳細は、次を参照してください。

- 証明書、認証局および暗号化鍵について

- セキュリティ・モードおよびX509Scheme認証について

- Importcertツールについて

証明書、認証局および暗号化鍵について

公開鍵インフラストラクチャにより、デジタル証明書は次のものに基づきWebベースのトランザクションの資格証明を確立します。

- 証明書の所有者の名前

- 証明書のシリアル番号

- 証明書の有効期限

- 証明書の所有者の公開鍵のコピー、これはメッセージおよびデジタル署名の暗号化に使用されます

- 証明書を発行する認証局のデジタル署名が提供されて、受信者はその証明書が本物であることを確認できます

デジタル証明書はレジストリに格納でき、そこから認証ユーザーが他のユーザーの公開鍵を検索できます。

暗号化では、公開鍵は暗号化キーとして使用される、指定した認証局により提供された値です。公開鍵を使用するためのシステムは公開鍵インフラストラクチャ(PKI)と呼ばれます。公開鍵インフラストラクチャの一部として、認証局は登録局(RA)に問い合せてデジタル証明書のリクエスタにより提供された情報を検証します。RAがリクエスタの情報を検証すると、CAは証明書を発行できます。

秘密鍵は公開鍵から導出できます。公開鍵および秘密鍵の組合せは非対称暗号と呼ばれ、メッセージおよびデジタル署名を効果的に暗号化するのに使用できます。

関連項目:

- 「証明書モードの暗号化およびファイルについて」

- 「簡易モードの暗号化および鍵について」

セキュリティ・モードおよびX509Scheme認証について

管理者はOAMサーバー構成で指定したトランスポート経由でのみOAMサーバーにアクセス可能にする必要があります。OAMサーバー構成は、サーバーのエンド・ポイントとロード・バランサまたは逆プロキシのアカウントを定義します。OAMサーバーにHTTPとHTTPSの両方でアクセス可能な場合、すべてのリクエスト(いずれのトランスポート経由でも)が受け入れられます。

ユーザーがX509以外の認証スキームによるSSLでOAMサーバーと接続(およびログアウト)できるようにするためには、指定したサーバー・ポートをCLIENT CERTSを必要とするように構成しないでください。

X509認証スキーム(X509Scheme)では、OAMサーバーSSLポートはサーバー・ポートと異なっていて、クライアント証明書を必要とするよう構成されている必要があります。X509Schemeを使用していると、X509モジュールは資格証明コレクションの後にコールされます。X509SchemeはX509チャレンジ・メソッドとX509認証モジュールを必要とします。資格証明コレクタへの完全修飾URLをX509Scheme内のチャレンジURLとして指定する必要があります。たとえば、https://<oam_server>:<ssl_port>/oam/CredCollectServlet/X509です。

注意:
相対的なチャレンジURLをX509Schemeで指定した場合、OAMサーバーは指定したサーバー・ポート/ホスト/ポートを使用してX509資格証明コレクタの完全修飾URLを構築します。ただし、この構成は動作しません。

関連項目:
「SSOトークンとIPの検証の管理」

Importcertツールについて

管理者はOracleが提供するimportcertツールを、キーストア、キーおよび証明書に関連した様々な手順で使用します。表E-1は、importcertコマンドの構文を示しています。

表E-1 importcertコマンドの構文

オプション

説明

keystore

このコマンドを、既存の(または新規)キーストアのパスで続けます。次に例を示します。

/scratch/.oamkeystore
or
/scratch/clientKey.jks

privatekeyfile

このオプションを、秘密鍵のパスで続けます。次に例を示します。

/scratch/aaa_key.der

signedcertfile

このオプションを、署名済証明書のパスで続けます。次に例を示します。

/scratch/aaa_cert.der

alias

このオプションを、キーストア・エントリ別名で続けます。genkeystoreで必要です。

alias

storetype

このオプションを、キーストア・タイプで続けます。デフォルトでは、ストア・タイプはJCEKS (OAMサーバー・キーストア)です。次に例を示します。

サーバー・キーストア.oamkeystoreのタイプは次のようになります。

JCEKS

クライアント・キーストア/scratch/clientTrustStore.jksおよび/scratch/clientKey.jksを使用できます。どちらも、次のタイプになります。

JKS

genkeystore

このフラグは、OAMクライアント証明書を生成する場合に必要です。クライアントでは、別名および別名パスワードのパラメータが表示されません。しかし、importcertツールはキーストア・パスワードを別名パスワードとして設定します。

次の内容を指定します。

Yes or No

Yesは、証明書を新しいキーストアにインポートします。

Noは、証明書を既存のキーストアにインポートします。

OAMサーバーの場合の例

- java -cp importcert.jar
oracle.security.am.common.tools.importcerts.CertificateImport -keystore <path to .oamkeystore> -privatekeyfile <path to aaa_key.der> -signedcertfile  <path to aaa_cert.der> -alias oam.certmode -aliaspassword <password> -storetype <JCEKS> genkeystore <yes>

キーストア・パスワードと別名パスワードを、求められたら入力します。

OAMクライアントの場合の例

関連項目: 「証明書モードのOAMテスターのクライアント・キーストア生成」

- java -cp importcert.jar
oracle.security.am.common.tools.importcerts.CertificateImport -keystore <path to clientkey.JKS> -privatekeyfile <path to aaa_key.der> -signedcertfile  <path to aaa_cert.der> -storetype <JKS> genkeystore <yes>

キーストア・パスワードを、求められたら入力します。

証明書モードのOAMテスターのクライアント・キーストア生成

この項は、証明書モードのOAMテスターで使用するJKSキーストアを生成する場合のみ必要になります。それ以外の場合は、次の項に進んでください。この項ではimportcertコマンドを使用して、インポートした信頼できる証明書チェーンを含むための、証明書モードのOAMテスター用のクライアント・キーストアを生成する方法を説明します。

関連項目:
「Importcertツールについて」

証明書モードのOAMテスター用のクライアント・キーストアを生成する手順

1. ImportCertツールを使用して、JKSキーストア(-privatekeyfileおよび-signedcertfileにより指定されたファイル名)を作成します。次に例を示します。

- java -cp importcert.jar
oracle.security.am.common.tools.importcerts.CertificateImport -keystore <Keystore path> -privatekeyfile <Private key file> -signedcertfile  <Signed certificate file> path -storetype <JKS> genkeystore <yes>

キーストア・パスワードを、求められたら入力します。

2. それぞれの環境に応じて次の手順を実行します。

- OAM 11gの証明書モード通信の構成

- OAM 11gの簡易モード通信の構成

3. キーストアの削除: 次のコマンドを使用して、JKSキーストアを削除します。次に例を示します。

keytool -delete -alias <alias> -keystore  <path to clientkey.JKS> -storetype <JKS>

キーストア・パスワードを、求められたら入力します。

OAM 11gの証明書モード通信の構成

この項では、OAM 11gの証明書モード通信の構成方法について説明します。

次のタスクは証明書モードにのみ適用されます。簡易モードでは、バンドルされたOAM-CA署名付き証明書が使用されて、次のタスクのほとんどは必要ありません。

タスク概要: OAMサーバーの証明書の追加には次のものが含まれます。

1. 次の内容の確認:

- 「OAM 11gサーバーとWebgate間の安全な通信の概要」

- 「証明書モードの暗号化およびファイルについて」

2. OAMサーバー用の証明書リクエストおよび秘密鍵の生成

3. OAMキーストア別名およびパスワードの取得

4. 信頼できる、署名された証明書チェーンをキーストアへインポート

5. 証明書詳細をAccess Manager設定に追加

6. Webgate用の秘密鍵および証明書リクエストの生成

7. 証明書を使用するようにWebgateを更新

証明書モードの暗号化およびファイルについて

Webgateの証明書リクエストによって、リクエスト・ファイルaaa_req.pemが生成されます。これを、OAMサーバーにより信頼されているルートCAに送信する必要があります。ルートCAは証明書を戻し、その後、10g Webgateのインストール中または後のいずれかでインストールできます(11g Webgateの場合、Webgateのインストールおよび構成後にWebgateインスタンス領域に手動でコピーする必要があります)。

- aaa_key.pem (Webgateキー・ファイルの予約名。変更できません)

- aaa_cert.pem (Webgate証明書ファイルの予約名。変更できません)

- aaa_chain.pem (Webgate側のCA証明書の予約名)

証明書モードでのコンポーネントのインストール中に、外部CAから取得した証明書が存在するかどうかを尋ねられます。証明書をまだ所有していない場合、リクエストできます。証明書を受領するまでは、Webgateを簡易モードで構成できます。ただし、証明書が発行されインストールされるまで、OAMデプロイメントは完了できません。

WebgateをOAMエージェントとして登録するときに証明書モードを選択すると、エージェント・キー・パスワードを入力するフィールドが表示されます。11g Webgateの登録を編集するときに、モードがオープンから証明書、あるいは簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェント・キー・パスワードを編集しても、新しいpassword.xmlは生成されません。

証明書リクエストを作成し、CAに送信する必要があります。証明書が戻されると、それをOAMサーバーにインポート(またはWebgateにコピー)する必要があります。

OAMサーバー用の証明書リクエストおよび秘密鍵の生成

次の手順を使用して、秘密鍵、証明書およびOAMサーバーのCA証明書を取得します。

注意:
10gと11gの登録間の一貫性を保つための認証ツールはopenSSLです。証明書およびキーをPEM形式で生成するには、他のツールではなくopenSSLを使用することをお薦めします。

OAM 11gサーバーの秘密鍵および証明書を取得する手順

1. 次のような証明書リクエスト(aaa_req.pem)および秘密鍵(aaa_key.pem)の両方を生成します。

–OpenSSL req –new –keyout aaa_key.pem –out aaa_req.pem –utf8
-nodes -config openssl_silent_ohs11g.cnf

2. 証明書リクエスト(aaa_req.pem)と信頼されているCAに送信します。

3. base64でのCA証明書をaaa_chain.pemとしてダウンロードします。

4. base64およびDER形式の両方での証明書をaaa_cert.pemおよびaaa_cert.derとしてダウンロードします。

5. 次のようにパスワードを使用して秘密鍵(aaa_key.pem)を暗号化します。

openssl rsa -in aaa_key.pem -passin pass: -out aaa_key.pem -passout pass:
******** -des

6. 「OAMキーストア別名およびパスワードの取得」に進みます。

OAMキーストア別名およびパスワードの取得

有効な管理者証明書を持つユーザーは、次のタスクを実行して、認証に使用される指定キーストア内の証明書の別名と、証明書のインポートに必要なパスワードを取得できます。

OAMキーストア・パスワードを取得する手順

1. Oracle Access Managerコンソールが実行中であることを確認してください。

2. Oracle Access Managerコンソールをホストしているコンピュータで、キーストア・パスワードの取得時に使用するOAMインストール・パスのWebLogic Scripting Toolを探します。次に例を示します。
$ORACLE_IDM/common/bin/

ここで、$ORACLE_IDMはOAM 11gのベース・インストール・ディレクトリで、/common/binはスクリプト・ツールが置かれているパスです。

3. WebLogic Scripting Toolを開始します。

·/ wlst.sh

4. WLSTシェルで、接続するコマンドを入力してからリクエスト情報を入力します。次に例を示します。

wls:/offline> connect()
Please enter your username [weblogic] :
Please enter your password [welcome1] :
Please enter your server URL [t3://localhost:7001] :
wls:/base_domain/serverConfig>

5. 次のコマンドを入力して、場所を読取り専用のdomainRuntimeツリーに変更します(ヘルプを表示するにはhelp(domainRuntime)を使用します)。次に例を示します。

wls:/OAM_AC> domainRuntime()

6. 次のコマンドを入力して、OAMキーストアの証明書をリストします。次に例を示します。

wls:/OAM_AC/domainruntime> listCred(map="OAM_STORE",key="jks")

ここで、OAM_STOREはOAMキーストアの名前を示します。

7. 表示されるOAMキーストアのパスワードは、証明書のインポートに必要なため、最新の注意を払ってください。

8. 「信頼できる、署名された証明書チェーンをキーストアへインポート」に進みます。

信頼できる、署名された証明書チェーンをキーストアへインポート

Oracleが提供するimportcertツールは、既存の秘密鍵、署名済証明書(公開鍵)ファイルを指定のキーストア形式であるJKS (クライアント・キーストア形式)またはJCEKS (OAMサーバー・キーストア形式、たとえば .oamkeystore)へインポートするために使用します。

Oracle Access Manager 11gに関連付けられたキーストアはPKCS8 DER形式の証明書のみを受け入れます。

- PEM形式の証明書が認証局(CA)によって署名されている場合、次の手順はOracle Access Manager 11gに付属しているimportcertを使用してこれらの証明書を変換した後にインポートする方法を説明します。

- PEM形式の証明書がない場合は、証明書リクエストを作成してCAで署名を受けた後で、次の手順を開始してください。

次にJDKバージョン6のkeytoolを使用するための手順を示します。異なるバージョンのkeytoolの場合、そのJDKバージョンのドキュメントを参照してください。

注意:
keytoolユーティリティを使用する場合、デフォルトの鍵ペア生成アルゴリズムはデジタル署名アルゴリズム(DSA)です。ただし、OAMおよびWebLogic ServerはDSAをサポートしないので、別の鍵ペア生成および署名アルゴリズムを指定する必要があります。

前提条件

OAMキーストア別名およびパスワードの取得

信頼できる証明書チェーンをキーストアにインポートする手順

1. 次のパスでOAM 11gのキーストアを探します。

$MW_HOME/jdk160_18/bin/keytool

2. importcert.zipを解凍して、次のパスでReadMeファイルを探します。

$ORACLE_IDM/oam/server/tools/importcert/README

3. aaa_chain.pem: テキスト・エディタを使用してaaa_chain.pemファイルを変更して、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除してからそのファイルを保存します。

----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----

4. 次のコマンドと環境に応じた詳細を使用して、信頼された証明書チェーンをインポートします。次に例を示します。

keytool -importcert -file aaa_chain.pem -trustcacerts -storepass <password>
-keystore <$ORACLE_HOME>\user_projects\domains\$DOMAIN\config\fmwconfig\
.oamkeystore -storetype JCEKS

5. 証明書を信頼するかどうか尋ねられたら、「yes」と入力します。

6. aaa_cert.pem:

1. TextPadを使用してaaa_certn.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、そのファイルを新しい場所に保管して元のファイルを保持します。次に例を示します。

----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----

2. 次のコマンドを入力して署名された証明書(aaa_cert.pem)を、openSSLまたは他のツールを使用してDER形式に変換します。次に例を示します。

openssl x509 -in aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER

7. aaa_key.pem:

1. aaa_key.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、そのファイルを新しい場所に保管して元のファイルを保持します。次に例を示します。

----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----

2. 次のコマンドを入力して秘密鍵(aaa_key.pem)を、openSSLまたは他のツールを使用してDER形式に変換します。次に例を示します。

openssl pkcs8 -topk8 -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der
-outform DER

8. キーストアに署名付きDER形式の証明書をインポートします。次に例を示します。

1. 環境に応じた次のコマンドライン引数および詳細を使用してaaa_key.derをインポートします。次に例を示します。
c:\Middleware\idm_home\oam\server\tools\importcert

- java -cp importcert.jar
oracle.security.am.common.tools.importcerts.CertificateImport
-keystore <> -privatekeyfile <path> -signedcertfile  <path>
-alias [ -storetype <> genkeystore <> -help]

注意:
キーストア・パスワードと別名パスワードを、求められたら入力します。Windowsシステムでは、コロン(:)のかわりにセミコロン(;)をコマンドラインで使用してください。

9. 「証明書詳細をAccess Manager設定に追加」に進みます。

証明書詳細をAccess Manager設定に追加

証明書をキーストアにインポートした後で、先ほど指定した別名およびパスワードを、Oracle Access ManagerコンソールでAccess Manager設定構成に、ここでの説明に従って追加する必要があります。

注意:
簡易モードには明示的な構成は必要なく、OAM 11gでは即時可能な状態で提供されます。

前提条件

信頼できる、署名された証明書チェーンをキーストアへインポート

関連項目:

- 「OAMプロキシの簡易および証明書モードのアクセス・プロトコルの管理のセキュリティ」

証明書詳細をAccess Manager設定に追加する手順

1. Oracle Access Managerコンソールで、「システム構成」タブをクリックします。

2. 「システム構成」タブの「Access Managerの設定」セクションで、「Access Managerの設定」ページを開きます。

3. ページの「アクセス・プロトコル」セクションを、必要に応じて展開します。

4. 前の手順で取得した別名および別名パスワード詳細を入力します。次に例を示します。
証明書モード構成

PEMキーストア別名: my_keystore_alias

PEMキーストア別名のパスワード: my_keystore_alias_pw

5. 「適用」をクリックして構成を保存します。

6. ページを閉じます。

7. OAMサーバー登録ページを開き、「プロキシ」タブをクリックし、プロキシ・モードを「証明書」に変更して「適用」をクリックします。

8. OAMサーバーを再起動します。

9. 「Webgate用の秘密鍵および証明書リクエストの生成」に進みます。

Webgate用の秘密鍵および証明書リクエストの生成

次の手順を使用して、秘密鍵、証明書およびWebgateのCA証明書を取得します。

注意:
10gと11gの登録間の一貫性を保つための認証ツールはopenSSLです。証明書およびキーをPEM形式で生成するには、他のツールではなくopenSSLを使用することをお薦めします。

Webgateの秘密鍵および証明書を取得する手順

1. 次のような証明書リクエスト(aaa_req.pem)および秘密鍵(aaa_key.pem)の両方を生成します。

openssl req -new -keyout aaa_key.pem -out aaa_req.pem -utf8 -nodes

2. 証明書リクエスト(aaa_req.pem)を信頼されているCAに送信します。

3. base64でのCA証明書をaaa_chain.pemとしてダウンロードします。

4. base64形式での証明書をformat as aaa_cert.pemとしてダウンロードします。

5. 次のようにパスワードを使用して秘密鍵(aaa_key.pem)を暗号化します。

openssl rsa -in aaa_key.pem -passin pass: -out aaa_key.pem -passout pass:
******** -des

6. 「証明書を使用するようにWebgateを更新」に進みます。

証明書を使用するようにWebgateを更新

すべての通信モード(オープン、簡易または証明書)で、エージェント登録はOracle Access Managerコンソールから更新する必要があります。

OAMエージェントの登録時に証明書モードを選択すると、エージェント・キー・パスワードを入力するフィールドが表示されます。11g Webgateの登録を編集するときに、モードがオープンから証明書、あるいは簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェント・キー・パスワードを編集しても、新しいpassword.xmlは生成されません。

前提条件

証明書詳細をAccess Manager設定に追加

Webgateエージェント登録の通信モードを更新する手順

1. 「システム構成」タブの「Access Managerの設定」セクションで、「SSOエージェント」ノードを展開して「OAMエージェント」を展開します。

2. 「検索」ページで、検索基準を定義して目的のエージェント登録を開きます(「OAMエージェント登録の検索」を参照してください)。

3. エージェントの登録ページで「セキュリティ」オプションを探して「証明書」(または「簡易」)をクリックします。

4. 証明書モード: 「Webgateの秘密鍵および証明書リクエストの生成」のステップ5の指定に従いエージェント・キー・パスワードを入力します。

5. 「適用」をクリックして変更を送信します。

6. 更新したWebgateファイルを、次のようにコピーします。
11g Webgate:

ObAccessClient.xml
cwallet.sso (11g Webgateのみ)
password.xml

- コピー元: $IDM_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $OHS_INSTANCE_HOME/config/OHS/ohs2/webgate/config

10g Webgate: ObAccessClient.xml

- コピー元: $WLS_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $Webgate_install_dir/oblix/lib

10g Webgate: password.xml

- コピー元: $WLS_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $Webgate_install_dir/oblix/config

7. 「OAMサーバー用の証明書リクエストおよび秘密鍵の生成」時に作成された次のファイルをコピーします。
11g Webgate:

- 元:
aaa_key.pem: Webgate11g_home/webgate/ohs/tools/openssl
aaa_cert.pem: これがCAからの受取り後に保存された場所
aaa_chain.pem: これがCAからの受取り後に保存された場所

- コピー先: OHS_INSTANCE_HOME/config/OHS/ohs2/webgate/config

10g Webgate:

- 元:
aaa_key.pem: 秘密鍵ファイルが生成された場所
aaa_cert.pem: これがCAからの受取り後に保存された場所
aaa_chain.pem: これがCAからの受取り後に保存された場所

- コピー先: $Webgate_install_dir/oblix/config

8. OAMサーバーおよびOracle HTTP Serverインスタンスを再起動します。

OAM 11gの簡易モード通信の構成

トランスポート・セキュリティ通信モードはOAMのインストール中に選択されます。簡易モードのとき、インストーラは最初にランダムなグローバル・パスフレーズを生成しますが、これは後で必要に応じて編集できます。

OAMエージェントまたは新しいOAMサーバーを登録するときにモードを指定できます。しかし、グローバル・パスフレーズの変更には、簡易モードを使用するすべてのエージェントと新しいグローバル・パスフレーズの再構成が必要です。

エージェントの登録中に、少なくとも1つのOAMサーバー・インスタンスがエージェントと同じモードで実行していることが必要です。それ以外の場合、登録は失敗します。ただし、エージェントの登録後、OAMサーバーの通信モードを変更できます。

注意:
エージェントとサーバー間の通信は、WebgateモードがOAMサーバー・モードと同じか、またはそれ以上であれば動作します。

エージェント・モードは高くても問題ありませんが、低くしないでください。最高レベルのセキュリティは「証明書」モードで、最も低いのは「オープン」モードです。

証明書」モード、「簡易」モード、「オープン」モード

この項では、簡易モード通信の構成に必要な情報を提供します。

タスク概要: OAM 11gの簡易モード通信の構成には次のことが含まれます

1. 次の内容の確認:

- 「簡易モードの暗号化および鍵について」

- 「Importcertツールについて」

2. 簡易モード用のグローバル・パスフレーズの取得

3. 簡易モード用Webgate登録の更新

4. 簡易モード構成の検証

簡易モード、暗号化および鍵について

簡易モード暗号化の場合、Oracle Access Managerには認証局がその固有の秘密鍵とともに含まれ、すべてのWebgateおよびOAMサーバーにインストールされます。インストール中に、OAMサーバーの秘密鍵-公開鍵のペアが生成され、保存されます。OAMエージェントのインストールでも同様にOracle認証局がインストールされます。

インストーラは最初にランダムなグローバル・パスフレーズを生成しますが、これは必要に応じて編集または表示できます。エージェントがSIMPLE(簡易)モードで登録されていると、次のクライアント証明書が生成され、クライアントにより使用されます。

- aaa_key.pem: 秘密鍵が含まれています

- aaa_cert.pem: 署名された証明書

- password.xml: ランダムなグローバル・パスフレーズが不明瞭化された形式で含まれています

注意:
グローバル・パスフレーズを変更すると、「簡易」モードですでに構成されているすべてのエージェントの再構成が必要になります。

簡易モード用のグローバル・パスフレーズの取得

Oracle Access Managerは「簡易」モード用のランダムなグローバル・パスフレーズを、インストール中に生成します。次の手順では、このパスワードを取得する方法を説明します。

「簡易」モード通信用のランダムなグローバル・パスフレーズを取得する手順

1. Oracle Access Managerコンソールが実行中であることを確認します。

2. Oracle Access Managerコンソールをホストしているコンピュータで、次のパスにあるWebLogic Scripting Toolを探します。次に例を示します。

$Oracle_IDM/common/bin

ここで、$Oracle_IDMはOracle Access Managerのベース・インストール・ディレクトリで、/common/binはスクリプト・ツールが置かれているパスです。

3. WebLogic Scripting Toolを起動します。次に、UNIXシステムの例を示します。

./ wlst.sh

4. WLSTシェルで、接続するコマンドを入力してからリクエスト情報を入力します。次に例を示します。

wls:/offline> connect()
Please enter your username [weblogic] :
Please enter your password [weblogic] :
Please enter your server URL [t3://localhost:7001] :
wls:/base_domain/serverConfig>

5. 次のコマンドを入力して、場所を読取り専用のdomainRuntimeツリーに変更します(ヘルプを表示するにはhelp(domainRuntime)を使用します)。次に例を示します。

wls:/OAM_AC>domainRuntime()

6. 次のコマンドを入力して、グローバル・パスフレーズを表示します。次に例を示します。

wls:/OAM_AC> displaySimpleModeGlobalPassphrase()

7. 「簡易モード用Webgate登録の更新」に進みます。

簡易モード用Webgate登録の更新

簡易セキュリティ・モード用に生成されたアーティファクトはグローバル・パスフレーズを使用し、変更はWebgateに伝播される必要があります。Webgate登録を削除し、再登録する(簡易モードの指定およびポリシーの自動生成の無効化)か、またはここで説明されているとおり、Webgate登録を編集してからアーティファクトをコピーできます。

関連項目:

- 「コンソールを使用したOAMエージェントの登録および管理」

簡易モード用Webgate登録を更新する手順

1. 「システム構成」タブの「Access Managerの設定」セクションで、「SSOエージェント」ノードを展開して「OAMエージェント」を展開します。

2. 「検索」ページで、検索基準を定義して目的のエージェント登録を開きます(「OAMエージェント登録の検索」を参照してください)。

3. 登録ページで「セキュリティ」オプションを探して「簡易」をクリックします。

4. 「適用」をクリックして変更を送信します。

5. 更新したWebgateファイルを、次のようにコピーします。
11g Webgate:

ObAccessClient.xml
cwallet.sso (11g Webgateのみ)
password.xml

- コピー元: $WLS_DOMAIN_HOME/output/AGENT_NAME (OAM AdminServerがインストールされているWebLogicドメイン・ホーム)

- コピー先: $OHS_INSTANCE_HOME/config/OHS/ohs2/webgate/config

10g Webgate: ObAccessClient.xml

- コピー元: $WLS_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $Webgate_install_dir/oblix/lib

10g Webgate: password.xml

- コピー元: $WLS_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $Webgate_install_dir/oblix/config

6. 次のファイルを、Webgateリリースでの指示に従ってコピーします。
aaa_key.pem
aaa_cert.pem

11g Webgate:

- コピー元: $IDM_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $OHS_INSTANCE_HOME/config/OHS/ohs2/webgate/webgate/config/simple

10g Webgate:

- コピー元: $IDM_DOMAIN_HOME/output/AGENT_NAME

- コピー先: $Webgate_install_dir/oblix/config/simple

7. OAMサーバーおよびOracle HTTP Serverインスタンスを再起動します。

簡易モード構成の検証

簡易モードへの変更をインスタンス化するためにWebサーバーを再起動する必要があります。次にその結果を検証できます。

簡易モードの変更を検証する手順

1. コマンドライン・ウィンドウからWebサーバーを再起動します。次に例を示します。

d:\middleware\ohs_home\instances\ohs_webgate11g\bin
opmnctl stopall
opmnctl startall

2. ブラウザ・ウィンドウで、簡易モードを使用してWebgateにより保護されているリソースへのURLを入力します。

3. 求められたら、ログイン資格証明を入力します。

4. リソースが実行中であることを確認してください。

F 管理者用のカスタムWLSTコマンドの概要

特定の管理タスクに対し、WebLogic Scripting Tool (WLST)はOracle Access Managerコンソールのかわりに使用できるカスタム・コマンドを提供します。この付録では管理者用のWLSTコマンドの概要を説明します。ただし各コマンドの詳細は、このマニュアルの範囲外です。

この付録の各項目には次のものが含まれます。

- 前提条件

- WebLogic Scripting Toolコマンドの概要

- WLSTコマンド・サマリー: Oracle Access Manager

- WLSTコマンド・サマリー: Oracle Security Token Service

- WLSTコマンドの実行

前提条件

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの情報をよく理解してください。

WebLogic Scripting Toolコマンドの概要

OAM用カスタムWLSTコマンドを使用して、OAMシステム構成を設定および管理できるのは管理者のみです。

WebLogic Scripting ToolはOracle Access Managerコンソールと同じ基本レイヤーを共有します。Oracle Access ManagerおよびOracle Security Token Service用WLSTはORACLE_IDM内で使用できます。

注意:
インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用するには、Oracle共通のホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

OAM WLSTコマンドは次のパスのoamWlstCmd.pyファイルで定義されます。

<ORACLE_IDM>/common/wlst

oamWlstCmd.pyファイルは次で使用可能なjarファイルを表します。

<Oracle_IDM>/oam/server/lib/jmx
<Oracle_IDM>/oam/server/lib/wlst

ほとんどのOAM用WLSTコマンドはオンラインおよびオフライン・モードの両方で動作します。動作モードを表F-1に示します。

表F-1 OAM用WLSTコマンドの動作モード

オンライン・モード

オフライン・モード

WebLogic AdminServerで実行しているMbeanサーバーに接続

メソッドの起動がWLSTシェルでローカルに発生

Mbeanサーバーがリモートで実行可能

必須入力としてOAM Domain Homeが必要

サーバーで実行されるOAM WLST Mbeanメソッドを起動

なし

OAM WLST Mbeansは実行結果をWLSTコマンドに戻します。

なし

WLSTコマンド・サマリー: Oracle Access Manager

表F-2に示すWLSTコマンドを使用して、メトリックやデプロイメント・トポロジの表示、Oracle Access Managerサーバーおよびエージェント構成の管理だけでなく、Oracle Access Manager(OAM)関連のコンポーネント(認可プロバイダ、アイデンティティ・アサータ、SSOプロバイダなど)を管理します。

関連項目:
Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・カスタムWLSTコマンド」のOracle Access Managerコマンドに関する項

表F-2 WLST Oracle Access Managerコマンド

使用するコマンド

目的

使用するWLSTの動作モード

listOAMAuthnProviderParams

Oracle Access Managerの認証またはアイデンティティ・アサーション・プロバイダ用のパラメータ・セットをリストします。

オンライン

createOAMIdentityAsserter

新しいアイデンティティ・アサータを作成します。

オンライン

updateOAMIdentityAsserter

既存のアイデンティティ・アサータを更新します。

オンライン

createOAMAuthenticator

新しい認証者を作成します。

オンライン

deleteOAMAuthnProvider

既存の認証プロバイダを削除します。

オンライン

updateOAMAuthenticator

既存の認証者を更新します。

オンライン

addOAMSSOProvider

新しいSSOプロバイダを追加します。

オンライン

displayTopology

デプロイされたOracle Access Manager Serverの詳細をリストします。

オンライン

オフライン

displayOamServer

Oracle Access Manager Server構成詳細を表示します。

オンライン

オフライン

createOamServer

Oracle Access Manager Server構成のエントリを作成します。

オンライン

オフライン

editOamServer

Oracle Access Manager Server構成のエントリを編集します。

オンライン

オフライン

deleteOamServer

名前付きOracle Access Manager Server構成を削除します。

オンライン

オフライン

displayOssoAgent

OSSOエージェント構成詳細を表示します。

オンライン

オフライン

editOssoAgent

OSSOエージェント構成詳細を編集します。

オンライン

オフライン

deleteOssoAgent

名前付きOSSOエージェント構成を削除します。

オンライン

オフライン

displayWebgateAgent

10g Webgateエージェント構成詳細を表示します。

オンライン

オフライン

editWebgateAgent

10g Webgateエージェント登録詳細を編集します。

オンライン

オフライン

deleteWebgateAgent

名前付き10g Webgateエージェント構成を削除します。

オンライン

オフライン

changeLoggerSetting

ロガー設定を変更します。

オンライン

オフライン

changeConfigDataEncryptionKey

構成データ暗号化鍵を再生成し、データを再暗号化します。

オンライン

オフライン

displayUserIdentityStore

ユーザー・アイデンティティ・ストア登録を表示します。

オンライン

オフライン

editUserIdentityStore

ユーザー・アイデンティティ・ストア登録を編集します。

オンライン

オフライン

createUserIdentityStore

ユーザー・アイデンティティ・ストア登録を作成します。

注意: roleAppdAdminは、マルチストア・サポートの一環として削除されます。WLSTは制限されており、システム・ストアとしてストアを設定できません。

オンライン

オフライン

deleteUserIdentityStore

ユーザー・アイデンティティ・ストア登録を削除します。

オンライン

オフライン

configRequestCacheType

SSOサーバー・リクエスト・キャッシュ・タイプを構成します。

オンライン

オフライン

displayRequestCacheType

SSOサーバー・リクエスト・キャッシュ・タイプ・エントリを表示します。

オンライン

exportPolicy

Oracle Access Managerポリシー・データをテスト(ソース)からOracle Access Managerの中間ファイルにエクスポートします。

オンライン

importPolicy

Oracle Access Managerポリシー・データをOracle Access Managerの指定したファイルからインポートします。

オンライン

importPolicyDelta

Oracle Access Managerポリシーの変更をOracle Access Managerの指定したファイルからインポートします。

オンライン

exportPartners

Oracle Access ManagerパートナをソースからOracle Access Manager Serverの指定した中間ファイルにエクスポートします。

オンライン

importPartners

Oracle Access ManagerパートナをOracle Access Managerの指定した中間ファイルからインポートします。

オンライン

configureOAAM

Oracle Access Manager-Oracle Adaptive Access Manager基本統合を構成します。

オンライン

registerOIFDAPPartner

Oracle Identity Federationを委任認証プロトコル(DAP)パートナとして登録します。

オンライン

オフライン

enableCoexistMode

共存モードを有効にします。

オンライン

disableCoexistMode

共存モードを無効にします。

オンライン

editGITOValues

GITO構成パラメータを編集します。

オンライン

オフライン

editWebgate11gAgent

11g Webgate登録を編集します。

オンライン

deleteWebgate11gAgent

11g Webgateエージェント登録を削除します。

オンライン

オフライン

displayWebgate11gAgent

11g Webgateエージェント登録を表示します。

オンライン

オフライン

displayOAMMetrics

OAMサーバーのメトリックを表示します。

オンライン

updateOIMHostPort

Oracle Access Managerとの統合時にOracle Identity Manager構成を更新します。

オンライン

オフライン

configureOIM

Oracle Access Managerとの統合時にOracle Identity Managerに特有のエージェント登録を作成します。

オンライン

updateOSSOResponseCookieConfig

OSSOプロキシ・レスポンスCookie設定を更新します。

オンライン

オフライン

deleteOSSOResponseCookieConfig

OSSOプロキシ・レスポンスCookie設定を削除します。

オンライン

オフライン

displaySimpleModeGlobalPassphrase

システム構成から簡易モードのグローバル・パスフレーズをプレーン・テキストで表示します。

オンライン

exportSelectedPartners

選択したOAMパートナを、指定した中間OAMファイルへエクスポートします。

オンライン

migrateArtifacts

入力アーティファクト・ファイルに基づいてアーティファクトを移行します。

オンライン

registerThirdPartyTAPPartner

サード・パーティを信頼できる認証プロトコル(TAP)パートナとして登録します。

オンライン

WLSTコマンド・サマリー: Oracle Security Token Service

表F-3に示すWLSTコマンドを使用して、Oracle Security Token Service関連コンポーネントを管理します。

関連項目:
Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・カスタムWLSTコマンド」のOracle Security Token Serviceコマンドに関する項

表F-3 WLSTコマンド: Oracle Security Token Service

使用するコマンド

目的

使用するWLSTの動作モード

putBooleanProperty

putBooleanProperty("/stsglobal/ignoreunsupportedelements", "true")

RSTに存在する、サポートされていないWS-Trust要素を無視します。

デフォルト: true

注意: 値falseは、サポートされていないWS-Trust要素がRSTに存在する場合にエラーを返します。

オンライン

パートナのコマンド

getPartner

パートナおよび印刷結果を取得します。

オンライン

getAllRequesterPartners

リクエスタ・パートナの名前を取得します。

オンライン

getAllRelyingPartyPartners

すべての依存側パートナの名前を取得します。

オンライン

getAllIssuingAuthorityPartners

すべての発行認証局パートナの名前を取得します。

オンライン

isPartnerPresent

OSTSを問い合せて、パートナがパートナ・ストアに存在するかどうかを調べます。

オンライン

createPartner

新規パートナ・エントリを作成します。

オンライン

updatePartner

既存のパートナ・エントリを、指定された情報に基づいて更新します。

オンライン

deletePartner

パートナ・エントリを削除します。

オンライン

getPartnerUsernameTokenUsername

パートナのユーザー名値を取得します。

オンライン

getPartnerUsernameTokenPassword

パートナのパスワード値を取得します。

オンライン

setPartnerUsernameTokenCredential

パートナ・エントリのユーザー名およびパスワードの値を設定します。

オンライン

deletePartnerUsernameTokenCredential

ユーザー名およびパスワードの値をパートナ・エントリから削除します。

オンライン

getPartnerSigningCert

パートナのBase64 encoded署名済証明書を取得します。

オンライン

getPartnerEncryptionCert

パートナのBase64 encoded暗号化証明書を取得します。

オンライン

setPartnerSigningCert

署名証明書をパートナ・エントリへアップロードします。

オンライン

setPartnerEncryptionCert

暗号化証明書をパートナ・エントリへアップロードします。

オンライン

deletePartnerSigningCert

署名証明書をパートナ・エントリから削除します。

オンライン

オフライン

deletePartnerEncryptionCert

暗号化証明書をパートナ・エントリから削除します。

オンライン

オフライン

getPartnerAllIdentityAttributes

トークンをリクエスタ・パートナにマップするために使用されるすべてのアイデンティティ・マッピング属性を取得して表示します。

オンライン

オフライン

getPartnerIdentityAttribute

アイデンティティ・マッピング属性を取得して表示します。

オンライン

オフライン

setPartnerIdentityAttribute

リクエスタ・パートナのアイデンティティ・マッピング属性を設定します。

オンライン

オフライン

deletePartnerIdentityAttribute

リクエスタ・パートナのアイデンティティ・マッピング属性を削除します。

オンライン

オフライン

依存側パートナ・マッピングのコマンド

getAllWSPrefixAndPartnerMappings

すべてのWS接頭辞を取得して表示します。

オンライン

オフライン

getWSPrefixAndPartnerMapping

指定されたwsprefixパラメータにマップされた依存側パートナを取得して表示します。

オンライン

オフライン

createWSPrefixAndPartnerMapping

依存側への新規WS接頭辞マッピングを作成します。

オンライン

オフライン

deleteWSPrefixAndPartnerMapping

依存側への既存のWS接頭辞マッピングを削除します。

オンライン

オフライン

パートナ・プロファイルのコマンド

getAllPartnerProfiles

すべての既存パートナ・プロファイルの名前を取得します。

オンライン

getPartnerProfile

パートナ・プロファイル構成データを取得します。

オンライン

createRequesterPartnerProfile

新しいリクエスタ・パートナ・プロファイルをデフォルト構成データで作成します。

オンライン

createRelyingPartyPartnerProfile

新しい依存側パートナ・プロファイルをデフォルト構成データで作成します。

オンライン

createIssuingAuthorityPartnerProfile

新しい発行認証局パートナ・プロファイルをデフォルト構成データで作成します。

オンライン

deletePartnerProfile

既存のパートナ・プロファイルを削除します。

オンライン

発行テンプレートのコマンド

getAllIssuanceTemplates

すべての既存発行テンプレートの名前を取得します。

オンライン

オフライン

getIssuanceTemplate

特定の発行テンプレートの構成データを取得します。

オンライン

createIssuanceTemplate

新しい発行テンプレートをデフォルト構成データで作成します。

オンライン

deleteIssuanceTemplate

既存の発行テンプレートを削除します。

オンライン

オフライン

検証テンプレートのコマンド

getAllValidationTemplates

すべての既存検証テンプレートの名前を取得します。

オンライン

オフライン

getValidationTemplate

特定の検証テンプレートの構成データを取得します。

オンライン

オフライン

createWSSValidationTemplate

新しいWSセキュリティ検証テンプレートをデフォルト構成データで作成します。

オンライン

オフライン

createWSTrustValidationTemplate

新しいWS-Trust検証テンプレートをデフォルト構成データで作成します。

オンライン

オフライン

deleteValidationTemplate

既存の発行テンプレートを削除します。

オンライン

オフライン

WLSTコマンドの実行

管理者は、Oracle Access ManagerまたはOracle Security Token Service操作用のWLSTコマンドを使用するためのガイドとして、次の手順を使用できます。これにはいくつかの操作が含まれています。

関連項目:
Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・カスタムWLSTコマンド」

- WLSTシェルの開始とログイン

- 高可用性環境でのリクエスト・キャッシュ・タイプの変更

WLSTシェルの開始とログイン

WLSTシェルを開始するときには、一般的な情報用の次の手順を使用します。

OAM操作用のWLSTコマンドを実行する手順

1. OAM AdminServerが実行中であることを確認します。

2. 次のコマンドを実行してWLST用の環境を設定します。

DOMAIN_HOME/bin/setDomainEnv.sh

3. ORACLE_HOMEパスである<Oracle_IDM>/common/binに移動します。

4. 適切なコマンドを実行してWLSTシェルに入ります。

Linux: wlst.sh
Windows: wlst.cmd

5. 必要に応じてhelpコマンドを実行します。help('oam')で使用可能なOAM WLSTコマンドをリストします。

注意:
"help('oamap')"コマンドと"help('oamapsso')"コマンドを使用して、追加コマンドを表示することもできます。

OAM WLST: help('oam')
Specific Command: wlst.cmd

6. ドメインに接続します。次に例を示します。

wls:/base_domain/serverConfig> connect()

7. WebLogic管理ユーザー名およびパスワードを入力し、次の形式管理サーバーのURLを入力します。

Please enter your username
Please enter your password
Please enter your server URL : t3://OAMHOST1.mycompany.com:7001
wls:/base_domain/serverConfig>

8. オフライン・モード: 'domainHome'を入力としてコマンドに指定します。

9. オンライン・モード: コマンド'connect ()'を使用してMbeanサーバーに接続します。

10. 詳細は、Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・カスタムWLSTコマンド」を参照してください。

高可用性環境でのリクエスト・キャッシュ・タイプの変更

高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用して、リクエスト・キャッシュ・タイプをBASICからCOOKIEへ変更する必要があります。

関連項目:

- 「ランタイム・ポリシー評価キャッシュの管理」

- 表11-4 SSO CookieのOAM_REQ cookie

高可用性環境でリクエスト・キャッシュ・タイプを変更する手順

1. 「WLSTシェルの開始とログイン」の記述に従って、WLSTシェルにログインし、ドメインに接続します。

2. 次のコマンドを実行し、高可用性デプロイメント用のリクエスト・キャッシュ・タイプをCOOKIEとして構成します。

wls:/base_domain/serverConfig> configRequestCacheType(type="COOKIE")

3. 次のコマンドを使用して、実行したコマンドを検証します。

wls:/base_domain/serverConfig> displayRequestCacheType()

4. OAMサーバーを再起動します。

G IPv6クライアント用のOAM 11gの構成

Oracle Access Manager 11gおよびその依存関係の間の内部通信ではInternet Protocol Version 4(IPv4)が使用されます。しかし、外部通信はOracle HTTP Serverとmod_wl_ohsプラグインを使用するIPv6でサポートされます。

この付録の内容は次のとおりです。

- 前提条件

- Oracle Access Manager 11gおよびIPv6の概要

- IPv6の構成: OAM 11gおよびWebgate用の別個のプロキシ

前提条件

Oracle Access ManagerをIPv6クライアントとともに使用する方法にかかわらず、ここでのアクティビティを開始する前に、次のタスクを完了する必要があります。

- Oracle HTTP Serverインスタンスは逆プロキシとして動作するようにWebサーバーにインストールされる必要があります(10gおよび11g Webgateに必要)。

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従い、Oracle Access Managerをインストールする必要があります。

関連項目:

- IPv6クライアント用のOAM 10g Webgateの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のネットワーク構成の変更の章のIPV6の使用に関する項を参照してください。

- 『Oracle HTTP Server管理者ガイド』

Oracle Access Manager 11gおよびIPv6の概要

いくつかある機能の中で、IPv6はIPv4(32ビット)よりも大きなアドレス領域をサポートし、Web上でアドレス可能なコンピュータ数を指数関数的に増加させます。IPv6はOracle HTTP Serverとmod_wl_ohsプラグインとともに有効になります。

OAMサーバーとWebgate (10gおよび11g)は、IPv4のみに使用します。しかし、IPv6クライアントはIPv4/IPv6二重スタック・ホスト上の逆プロキシを介して、IPv4でWebgateにアクセスできます。

注意:
逆プロキシ・サーバーを設定することで、IPv6をサポートするクライアントとともにOracle Access Manager 11gが動作するように構成できます。

IPV4/IPV6でのOAMのサポートされるトポロジの概要を次のリストに示します。

トポロジ

- Webgate 10gまたはWebgate 11gとIPv4プロトコル・ホスト上の保護されたアプリケーション

- 二重スタック・ホスト上のOHS逆プロキシ

- IPv6プロトコル・ホスト上のクライアント

- OAMサーバー・プロキシ

IPv6クライアントはWebgate 10gまたはWebgate 11gに、OHSリバース・プロキシを介してアクセスできます。

注意:
OAMサーバーが実行していない場合、WebLogic管理コンソールへのログインは正常に終了します。しかし、OAMサーバーが実行している場合、アイデンティティ・ストアが初期化されていないため、WebLogic管理コンソールへのログインはOAMサーバーにリダイレクトされ、認証は失敗します。アイデンティティ・ストア用のIPV6はまだサポートされていません。

詳細は、次を参照してください。

- OAM 11gでのIPv6とチャレンジ・リダイレクトの構成

- 考慮事項

OAM 10g Webgateの構成を含む、サポートされるすべてのトポロジについては、『Oracle Fusion Middleware管理者ガイド』のネットワーク構成の変更の章のIPV6の使用に関する項を参照してください。

OAM 11gでのIPv6とチャレンジ・リダイレクトの構成

図G-1は、1つのIPv6からIPv4へのプロキシ(構成されたホストmyssohostおよびmyapphostは、別個のプロキシを使用できる)を使用した構成を示します。

OAM 11gでは、仮想ホスト名はIPアドレスではなくホスト名として指定する必要があります(myapphost.foo.comなど)。リダイレクト・ホスト名(例: myssohost.foo.com)も、IPアドレスではなく、ホスト名として指定する必要があります。IPv6アドレスはWebgate登録には指定できません。

注意:
OAM 11gでは、WebgateまたはリソースWebgateの認証の概念は存在しません。そのかわりに、11g Webgateまたは10g Webgateのいずれであっても、リダイレクト先は常にOAMサーバーです。

図G-1 OAM 11gでのIPv6とチャレンジ・リダイレクトの構成

「図G-1 OAM 11g用のIPv6の構成とチャレンジ・リダイレクト」の説明

図G-1に示すように、IPv6ネットワークはIPv6/IPv4プロキシと通信し、次にOracle HTTP ServerとIPv4を使用して通信します。Webgate、Oracle Access Manager ServerおよびOracle WebLogic Serverとアイデンティティ・アサータは、すべてIPV4を使用して互いに通信します。

IPv6ネットワーク上のブラウザからIPv6サーバー・ホスト(myapphost.foo.com)へのアプリケーションにアクセスし、IPv6 myssohost.foo.comへのリダイレクトによりログインできるようにする必要があります。

考慮事項

次の考慮事項が目的の使用シナリオに適用されます。

- IP検証はデフォルトでは機能しません。IP検証を有効にするには、Oracle Access Managerコンソールで、プロキシ・サーバーのIPアドレスをWebgateのIPValidationExceptionパラメータの値として追加する必要があります。

関連項目:
「OAM 11gでのシングル・サインオン」

- IPアドレスベースの認可は、すべてのリクエストがその目的で動作していない1つのIP(プロキシIP)を経由するため、動作しません。

- ipValidationExceptionはIPValidationがオンの場合(パラメータ"ipValidation"=1)に必要です。しかし、このパラメータはOracle Access Managerコンソールまたはリモート登録ツールのいずれを使用しても追加できません。そのかわりに、プロキシのIPをoam-config.xmlファイル内のプロキシの単一値のユーザー定義パラメータとして追加する必要があります。

IPv6の構成: OAM 11gおよびWebgate用の別個のプロキシ

OAM 10gでは、リソースWebgate構成(リダイレクトする)と認証Webgate構成が提供されました。OAM 11g資格証明コレクタはOAM 10g認証Webgateの機能を置き換えて実行します。

注意:
OAM 11gでは、10g Webgateは常に、以前の"認証"Webgateのような働きをするOAM 11g資格証明コレクタにリダイレクトします。

この構成では複数のプロキシがあります。たとえば、OAMサーバーに個別のプロキシがあり、Webgateには別のプロキシがあります。

IPv6ホストへのログイン・リダイレクトを含む、IPv4ネットワーク上のブラウザから直接IPv4サーバー・ホスト名へのアプリケーションにアクセスできます。次に例を示します。

Webgateはhttp://myapphostv4.foo.com/にあります
OAMサーバーはhttp://myssohostv4.foo.comにあります

myapphostv4.foo.comに使用するプロキシはmyapphost.foo.comにする必要があります
myssohostv4.foo.comに使用するプロキシはmyssohost.comにする必要があります

注意:
IPv6プロキシ名をWebgate登録の優先HTTPホストとして使用することはできません。

OAM 11gでは、Webgate (11gまたは10g)は常にobrareq.cgiにリダイレクトするため、ProxyRequestsパラメータは"On"であることが必要です。このディレクティブによりプロキシはフォワード・プロキシとして動作します。

優先httpホストはWebgateをホストしているWebサーバーのhost:portに設定される必要があります(またはWebgateをホストしているWebサーバーが仮想ホスト用に構成されている場合はSERVER_NAME)。

IPValidationがONの場合、IPValidationExceptionがプロキシに対し追加される必要があります。

逆プロキシが構成されてSSL終了を実行する場合、ユーザー定義のWebgate proxySSLHeaderVarパラメータがリモート登録中に定義される必要があります。「表10-4 リモート登録リクエストの共通の要素」で説明しているとおり、このパラメータはWebgateが逆プロキシの背後に置かれている場合に使用されます。proxySSLHeaderVarパラメータの値はプロキシが設定する必要のあるヘッダー変数の名前を定義します。ヘッダー変数の値は"ssl"または"nonssl"である必要があります。ヘッダー変数が設定されていない場合、SSL状態は現在のWebサーバーのSSL状態によって決まります。構文は次のとおりです。

<name>proxySSLHeaderVar</name>
<value>IS_SSL</value>

ロード・バランシング・ルーター(逆プロキシWebサーバー)の設定を変更し、IS_SSL値をsslに設定するHTTPヘッダー文字列を挿入します。たとえば、F5ロード・バランサ、拡張プロキシ設定で、HTTPヘッダー文字列IS_SSL:sslを追加します。

次の手順で、OHS_hostおよびOHS_portはWebgate用に構成された実際のOracle HTTP Serverのホスト名およびポートです。ご使用の環境に適した値を使用するようにしてください。実際の値はこれとは異なります。

前提条件

逆プロキシ用のOHS Webサーバーをインストールおよび構成します。プロキシごとに別のWebサーバー・インスタンスがあることを確認します。

OAM 11gおよびWebgate用に別個のプロキシを使用するIPv6を構成する手順

1. OAM 11gサーバーおよびWebgateへのmod_proxyの有効化: Oracle HTTP Server 11gリリース1 (11.1.1)または複数のプロキシ用の別のサーバー)を次のように構成します。

1. 次のコマンドを使用して、対応するプロキシ・インスタンス用のOracle HTTP Serverを停止します。

opmnctl stopproc ias-component=<OHS instance name>

2. OHSインスタンスの次のファイルを、対応するプロキシ用に編集します。

UNIX: ORACLE_INSTANCE/config/OHS/ohs_name1/httpd.conf
Windows: ORACLE_INSTANCE\config\OHS\ohs_name1\httpd.conf

3. OAM 11gサーバーへのプロキシ: 環境に応じて次の情報をhttpd.confファイルに追加してmod_proxyを有効にします。次に例を示します。

<IfModule mod_proxy.c>
ProxyRequests On
ProxyPreserveHost On

ProxyPass / http://<oam_server_host:port>/
ProxyPassReverse / http://<oam_server_host:port>/
</IfModule>

4. 11g Webgateへの逆プロキシ: 次のように環境に応じた情報をhttpd.confファイルに追加してmod_proxyを有効にします。

<IfModule mod_proxy.c>
ProxyRequests On
ProxyPreserveHost On

ProxyPass / http://<webgate_OHS_host:port>/
ProxyPassReverse / http://<webgate_OHS_host:port>/
</IfModule>

5. 次のコマンドを使用してOracle HTTP Serverを再起動します。

opmnctl startproc ias-component=<OHS instance name>

2. 認証スキームで、チャレンジ・リダイレクトURLをttp://<oam_server_proxy_host:port>/oam/serverに変更します。

3. 各Webgateの優先HTTPホストを、WebgateをホストしているWebサーバーのhost:portに(またはWebgateをホストしているWebサーバーが仮想ホスティング用に構成されている場合はSERVER_NAMEに)設定してください。

注意:
リモート登録中に*Request.xml入力の適切なフィールドを使用して、または次に示すようなOracle Access Managerコンソールを使用して、優先HTTPホストを指定できます。「リモート登録リクエスト・ファイルについて」も参照してください。

1. Oracle Access Managerコンソールにログインします。次に例を示します。

http://hostname:port/oamconsole

2. 「システム構成」、「Access Managerの設定」、「SSOエージェント」、「OAMエージェント」をクリックします。

3. 「検索結果」表でエージェントを見つけてその名前をクリックして、登録ページを表示します。

4. 優先HTTPホスト: このWebgate用に構成されているOracle HTTP Server Webサーバーの名前です。たとえば、Webgateがmyapphostv4.foo.comにデプロイされている場合、myapphostv4.foo.comを優先HTTPホストとして使用する必要があります。

関連項目:

- 「リモート登録リクエスト・ファイルについて」

- 「仮想Webホスティングについて」

5. 「適用」をクリックします。

4. 各Webgateに対して手順を繰り返し、このWebgate用に構成されているOracle HTTP Server Webサーバーの名前を指定します。

5. IPValidationException: IPValidationがOn(パラメータ"ipValidation"=1)の場合、プロキシのIPをoam-config.xmlファイル内のプロキシの単一値のユーザー定義パラメータとして追加する必要があります。

1. すべてのOAMサーバーおよびAdminServerを停止します。

2. 次のパスでoam-config.xmlを見つけます。
<WLS_DOMAIN_HOME>/config/fmwconfig/oamconfig.xml

3. 次の情報を入力します。

<Setting Name="ipValidationExceptions"Type="xsd:string"> 10.1.1.1</Setting>

4. ファイルを保存します。

5. OAMサーバーおよびAdminServerを再起動します。

6. 逆プロキシが構成されてSSL終了を実行する場合、Webgateのユーザー定義のproxySSLHeaderVarパラメータが定義される必要があります(デフォルトは"IS_SSL")。ロード・バランシング・ルーター(逆プロキシWebサーバー)の設定を変更し、IS_SSL値をsslに設定するHTTPヘッダー文字列を挿入します。たとえば、F5ロード・バランサ、拡張プロキシ設定で、HTTPヘッダー文字列IS_SSL:sslを追加します。

H デプロイメント固有ページの作成

Oracle Application Serverシングル・サインオンでは、デプロイメントに固有のログイン、パスワード変更、およびシングル・サインオン・サーバーによるシングル・サインオフ・ページを統合するためのフレームワークが提供されます。つまり、UIのルック・アンド・フィールおよびグローバリゼーション要件に合わせてこれらのページを調整できます。

JavaServer (JSP)ページを使用することをお薦めします。他のWebテクノロジでは、結果に矛盾が生じる可能性があります。PLSQLページはサポートされていません。製品にサンプル・ページが付属しています。Oracle Application Server Single Sign-On製品には、Oracle Application Serverでのテスト用のサンプル・ページが付属しています。

この章には次のトピックが含まれます。

- シングル・サインオン・サーバーでのデプロイメント固有ページの使用方法

- デプロイメント固有ページの記述方法

- ページのエラー・コード

- グローバリゼーション・サポートの追加

- デプロイメント固有ページに関するガイドライン

- デプロイメント固有ページのインストール

- デプロイメント固有ページの例

- 外部アプリケーションの追加

シングル・サインオン・サーバーでのデプロイメント固有ページの使用方法

シングル・サインオン・ページを使用可能にするプロセスは、次のようにまとめることができます。

1. ユーザーはパートナ・アプリケーションをリクエストし、シングル・サインオン・サーバーへリダイレクトされます。

2. ユーザーが認証されない場合、シングル・サインオン・サーバーはユーザーをサンプル・ログイン・ページかデプロイメント固有ページへリダイレクトします。このリダイレクトの一環として、表H-1に示すパラメータがサーバーからページに渡されます。

3. ユーザーはログイン・ページを実行します。これにより、表H-2に示すパラメータが次の認証URLに渡されます。

http://sso_host:sso_port/sso/auth

または

https://sso_host:sso_ssl_port/sso/auth

これらのパラメータのうち少なくとも2つ(ssousername、password)が変更可能なフィールドとしてページに表示されます。

4. ユーザーのパスワードの有効期限がすぐに切れるように設定されておらず、シングル・サインオン・サーバーがユーザー名とパスワードを正常に検証すると、このユーザーをアプリケーションの成功URLへリダイレクトします。認証が失敗すると、サーバーはユーザーを再びログイン・ページへリダイレクトして、エラー・メッセージを表示します。

5. ユーザー・パスワードの有効期限が近い場合は、ログイン・ページではなく、パスワード変更ページが表示されます。また、デプロイメント固有のパスワード変更ページを使用するようにサーバーが構成されている場合、ユーザーはこのページのURLにリダイレクトされ、表H-3に示すパラメータがページに渡されます。

注意:
ステップ5で、ディレクトリ管理者がユーザーにパスワードを変更するよう強制している場合、パスワード有効期限にかかわらず、同じ条件が適用されます。

ユーザーはパスワード変更ページを実行し、古いパスワード、新しいパスワード、確認用の新しいパスワードを入力します。このページは、表H-4に記載されているパラメータをパスワード変更URLへ渡します。

http://sso_host:sso_port/sso/ChangePwdServlet

または

https://sso_host:sso_ssl_port/sso/ChangePwdServlet

エラーが発生すると、シングル・サインオン・サーバーはユーザーをパスワード変更ページへリダイレクトして、エラー・メッセージを表示します。エラーが発生する可能性がある状況の詳細な説明は、「パスワード変更ページの動作」を参照してください。

パスワード変更に成功すると、ユーザーは認証リクエストのトリガーとなったパートナ・アプリケーションURLへリダイレクトされます。

6. ユーザーがシングル・サインオン・セッションを終了するには、作業中のパートナ・アプリケーションで「ログアウト」をクリックします。これにより、アプリケーションのログアウトURLが同時にコールされ、ユーザーはアクセスしたすべてのアプリケーションからログアウトされ、シングル・サインオン・セッションが終了します。

7. ユーザーはシングル・サインオン・サーバーへリダイレクトされ、そこでシングル・サインオフ・ページが表示されます。サーバーがデプロイメント固有ページを使用するように構成されている場合は、ユーザーをこのページのURLにリダイレクトし、表H-5に記載されているパラメータをこのページに渡します。

8. ユーザーはシングル・サインオフ・ページで「戻る」をクリックすると、ログアウトを開始したアプリケーションに戻ることができます。

注意:
パスワード変更ページを使用してパスワードを変更できるのは、パスワードの有効期限が近い場合のみです。Oracle Delegated Administration ServicesのUIを使用すると、いつでもパスワードを変更できます。このトピックの詳細は、「パスワード変更ページの動作」を参照してください。

パスワード変更ページの動作

パスワードの有効期限が切れている場合や期限切れが近いときにユーザーがログインしようとすると、サーバーは次のように動作します。

パスワードが失効している場合

パスワードの失効を表す画面が表示されます。ユーザーは、ディレクトリ管理者に連絡してパスワードのリセットを依頼する必要があります。

パスワードが間もなく失効する場合

ログイン・ページにエラー・メッセージが表示されます。ユーザーはページを取り消すか、あるいはパスワードを変更できます。いずれの場合でも、パスワードの変更ページが表示されないときと同じように認証が行われます。

猶予ログインが有効

猶予ログイン期間がディレクトリで構成されている場合、ユーザーのパスワードが期限切れになるとパスワード変更ページがユーザーに表示されます。このページを取り消すか、パスワードを変更するオプションがあります。どちらの場合も、認証の手順はユーザーのパスワードが有効であるときと同じです。

パスワード変更の強制

この機能は、管理者によるパスワードのリセット後にパスワードの変更をユーザーに要求します。パスワード変更強制を有効にするには、ディレクトリ・エントリcn=pwdpolicyentry,cn=common,cn=products,cn=OracleContext,dc=default_identity_management_realmでpwdMustChange属性を設定します。このためには、コマンドライン・ツールldapmodifyを使用します。TRUEに設定すると、パスワード変更の強制機能が有効になります。FALSEに設定すると、無効になります。ツールの実行方法については、『Oracle Internet Directory管理者ガイド』の章「パスワード・ポリシー」を参照してください。

デプロイメント固有ページの記述方法

ログイン・ページ、パスワード変更ページおよびシングル・サインオフ・ページのURLでは、これらのページが正常に機能するために、以降の表に示すパラメータを受け入れる必要があります。

この項には次のトピックが含まれます。

- ログイン・ページのパラメータ

- パスワードを忘れた場合

- パスワード変更ページのパラメータ

- シングル・サインオフ・ページのパラメータ

ログイン・ページのパラメータ

ログイン・ページのURLでは、表H-1に示すパラメータを受け入れる必要があります。

表H-1 シングル・サインオン・サーバーによりログイン・ページに送信されるログイン・ページ・パラメータ

パラメータ

説明

site2pstoretoken

ログイン処理用の認証リクエスト・トークンが含まれています。

ssousername

ユーザー名が含まれています。

p_error_code

エラー・コードが文字列の形式で含まれています。認証中にエラーが発生したときに渡されます。

p_cancel_url

「取消」(このボタンがログイン・ページに存在する場合)をユーザーがクリックしたときのリダイレクト先URLが含まれています。このURLは、ログインが開始されたパートナ・アプリケーションのホームURLを指しています。

locale

ユーザーの言語設定です(オプション)。ISO形式にする必要があります。たとえば、フランス語の場合はfr-frです。このパラメータの詳細は、「グローバリゼーション・サポートの追加」を参照してください。

ログイン・ページでは、表H-2に示すパラメータを次の認証URLに渡す必要があります。

http://sso_host:sso_port/sso/auth

表H-2 ページからシングル・サインオン・サーバーに送信されるログイン・ページのパラメータ

パラメータ

説明

site2pstoretoken

ログイン処理用のリダイレクトURL情報が含まれています。

ssousername

ユーザー名が含まれています。UTF-8 encodedであることが必要です。

password

ユーザーによって入力されたパスワードが含まれています。UTF-8 encodedであることが必要です。

subscribername

レルムが有効な場合のサブスクライバ・ニックネームです。UTF-8 encodedであることが必要です。

注意: このフィールドがログイン・ページで必要なのは、シングル・サインオン・サーバーで複数のレルムが有効な場合のみです。

locale

ユーザーの言語設定です(オプション)。ISO形式にする必要があります。たとえば、フランス語の場合はfr-frです。このパラメータの詳細は、「グローバリゼーション・サポートの追加」を参照してください。

v

ページ・バージョンが含まれています。これは推奨ですが、オプションです。パラメータが渡される場合、その値はv1.4であることが必要です。

ログイン・ページには、パラメータ名ssousernameのテキスト・フィールドとパラメータ名passwordのパスワード・フィールドの少なくとも2つが必要です。値は、認証URLに渡されます。ログイン・ページには、site2pstoretokenも非表示パラメータとして含まれている必要があります。このパラメータはログインURLに送信される必要があります。

これらのパラメータを送信する他に、ログイン・ページはp_error_codeの指定に従って適切なエラー・メッセージを表示し、ユーザーが「取消」をクリックするとp_cancel_urlへリダイレクトする必要があります。

パスワードを忘れた場合

ログイン・ページを作成するときは、ユーザーがパスワードをリセットできるようにするリンクを構成できます。このURLでOracle Delegated Administration Servicesのホーム・ページに進むことも、あるいはOracle Delegated Administration Services内の「パスワードを忘れた場合」リンクに進むこともできます。「パスワードを忘れた場合」リンクをクリックしたユーザーには、質問が与えられます。ユーザーはこの質問に正しく答えないと、パスワードをリセットできません。

Oracle Delegated Administration Servicesは、通常はOracleAS Single Sign-Onと同じコンピュータで、次の形式のURLによってアクセスできます。

http://sso_host:sso_port/oiddas/

「パスワードを忘れた場合」リンクを使用してパスワードをリセットする方法の詳細は、『Oracle Identity Management委任管理ガイド』の章「Oracle Internet Directoryセルフサービス・コンソール」を参照してください。

パスワード変更ページのパラメータ

パスワード変更ページのURLでは、表H-3に示すパラメータを受け入れる必要があります。

注意:
GITデプロイメントでは、パートナ・ログアウト・フローがp_done_urlで問合せパラメータを必要とするとき、このパラメータをURLエンコーディングして、Oracle Access Managerログアウト・サーブレットがこれらをOracle Access Managerパラメータであると解釈するのでなく、1つのp_done_urlの要素であると解釈するようにする必要があります。

表H-3 ページに送信されるパスワード変更パラメータ

パラメータ

説明

p_username

ページのどこかに表示されるユーザー名が含まれています。

p_subscribername

ホスティングが有効な場合のサブスクライバ・ニックネームです。

注意: このフィールドは、ログイン・ページで必須です。

p_error_code

前回のパスワード変更時にエラーが発生していた場合、文字列形式のエラー・コードが含まれます。

p_done_url

パスワードが保存された後に戻る適切なページのURLが含まれます。

site2pstoretoken

パスワードの期限が切れたか期限が切れようとしている場合に/sso/authログインURLで必要になるsite2pstoretokenが含まれています。

p_pwd_is_exp

パスワードの期限が切れたのか、それとも期限が切れようとしているのかを示すフラグ値が含まれています。値はWARNかFORCEのいずれかです。関連するエラー・コードは、表H-8を参照してください。

locale

ユーザーの言語設定です(オプション)。ISO形式にする必要があります。たとえば、フランス語の場合はfr-frです。このパラメータの詳細は、「グローバリゼーション・サポートの追加」を参照してください。

パスワード変更ページは、表H-4に示すパラメータを、パスワード変更URLに渡す必要があります。

http://sso_host:sso_port/sso/ChangePwdServlet

表H-4 ページにより送信されるパスワード変更ページのパラメータ

パラメータ

説明

p_username

ページのどこかに表示されるユーザー名が含まれています。パスワード変更ページから、非表示フィールドとして送信する必要があります。UTF-8 encodedであることが必要です。

p_old_password

ユーザーの古いパスワードが含まれています。UTF-8 encodedであることが必要です。

p_new_password

ユーザーの新しいパスワードが含まれています。UTF-8 encodedであることが必要です。

p_new_password_confirm

ユーザーの新しい確認パスワードが含まれています。UTF-8 encodedであることが必要です。

p_done_url

パスワードが保存された後に戻る適切なページのURLが含まれます。

p_pwd_is_exp

パスワードの期限が切れたのか、それとも期限が切れようとしているのかを示すフラグ値が含まれています。値はWARNかFORCEのいずれかです。関連するエラー・コードは、表H-8を参照してください。

site2pstoretoken

ログイン処理用のリダイレクトURL情報が含まれています。

p_action

変更をコミットします。値はOK(コミット)とCANCEL(無視)のいずれかであることが必要です。

p_subscribername

ページのどこかに表示されるユーザー名が含まれています。

p_request

ユーザーによりリクエストされた保護URLです。

locale

ユーザーの言語設定です(オプション)。ISO形式にする必要があります。たとえば、フランス語はfr-frです。

「グローバリゼーション・サポートの追加」を参照してください。

パスワード変更ページには、少なくともp_old_password、p_new_passwordおよびp_new_password_confirmの3つのパスワード・フィールドが必要です。パスワード変更ページはこれらのフィールドをパスワード変更URLへ送信します。

パスワード変更ページは、p_done_urlも非表示パラメータとしてパスワード変更URLへ送信します。さらに、p_error_codeの値に応じてエラー・メッセージを表示する必要があります。

シングル・サインオフ・ページのパラメータ

シングル・サインオフ・ページのURLでは、表H-5に示すパラメータを受け入れる必要があります。

表H-5 シングル・サインオフ・ページに送信されるパラメータ

パラメータ

説明

p_app_name[1. . .n]

ページに表示されるアプリケーション名が含まれています。変数nは、シングル・サインオフに参加しているパートナ・アプリケーションの数です。

p_app_logout_url[1. . .n]

アプリケーション・ログアウトURLが含まれています。変数nは、シングル・サインオフに参加しているパートナ・アプリケーションの数です。

p_done_url

戻りURLが含まれています。このURLはユーザーを、ユーザーがログアウトを開始したアプリケーションに戻します。

locale

ISO形式でのユーザーの言語設定です。ログイン時にユーザーが同じ値を渡さない場合にのみ、送信されます。

外部アプリケーション・ログイン・ページのパラメータ

外部アプリケーション・ログイン・ページのURLでは、表H-6に示すパラメータを受け入れる必要があります。

表H-6 外部アプリケーション・ログイン・ページに送信されるパラメータ

パラメータ

説明

ID

外部アプリケーションIDです。このIDは、「外部アプリケーション管理」ページに表示されます。OracleAS Single Sign-Onで構成される外部アプリケーションごとに、固有のIDが生成されます。このIDは、外部アプリケーションに関連する表の中で主キーとなります。外部アプリケーションのログイン・ページは、このIDを外部アプリケーションに戻す必要があります。

p_app_name

ページに表示されるアプリケーション名が含まれています。これは、外部アプリケーションがOracleAS Single Sign-Onで構成されたときに指定される外部アプリケーションの名前です。

extappfieldname1..9

予備フィールド名です。各外部アプリケーションは、関連する予備フィールドを9個まで持つことができます。これらのフィールドは、可視にも不可視にもできます。可視フィールドは外部アプリケーションのログイン・ページに表示され、ユーザーはこのフィールドのデフォルト値を変更できます。不可視フィールドの値も外部アプリケーションに送信されますが、ユーザーはその値を変更できません。たとえば、ログイン・フィールド、パスワード・フィールドおよびロケール・フィールドがあるアプリケーションでは、FRの値を持つLOという名前のフィールドを追加できます。詳細は、「外部アプリケーションの追加」を参照してください。

extappfieldvalue1..9

予備フィールドの値です。

extappfielddisplay1..9

予備フィールドの可視性です(trueまたはfalse)。フィールドがユーザーに可視であり変更可能か(true)、あるいはフィールドの値が固定値か(false)を決定します。

mode

このパラメータはカスタム・ログイン・ページに渡される場合と、渡されない場合があります。ログイン・ページに渡す場合は、値をmodifyに設定して送信する必要があります。この場合、データベース内のユーザーの資格証明を更新するためにポータルから外部アプリケーション・ログイン・ページがコールされたことを、シングル・サインオン・アプリケーション・コントローラに示します。

p_error_code

前回のパスワード変更時にエラーが発生していた場合、文字列形式のエラー・コードが含まれます。

done

ユーザーの資格証明が更新された後のレスポンスのリダイレクト先URLです。これは、modifyモードで使用されます。

このページは、表H-7に示しているパラメータを、POSTメソッドを使用して外部アプリケーション・ログイン・コントローラに送信できる必要があります。

表H-7 「外部アプリケーション・ログイン」ページがアプリケーションに送信するパラメータ

パラメータ

説明

ID

外部アプリケーションIDです。

p_app_username

アプリケーションにログインしている個人のユーザー名が含まれています。

p_app_pwd

ユーザーが送信するパスワードです。

p_remember_credentials

アプリケーションのユーザー名およびパスワードをデータベースに保存する必要があるかどうかを、外部アプリケーション・ログイン・コントローラに示すフラグ。

extappfieldname1..9

予備フィールド名です。詳細は、表H–6を参照してください。

extappfieldvalue1..9

予備フィールドの値です。

extappfielddisplay1..9

予備フィールドの可視性です(true/false)。詳細は、表H–6を参照してください。

p_change_password

外部アプリケーション・ログイン・コントローラに対して、モードをchange passwordに設定するかどうかを示すtrue/falseフラグです。

mode

このパラメータはカスタム・ログイン・ページに渡される場合と、渡されない場合があります。ログイン・ページに渡す場合は、値をmodifyに設定して送信する必要があります。この場合、データベース内のユーザーの資格証明を更新するためにポータルから外部アプリケーション・ログイン・ページがコールされたことを、シングル・サインオン・アプリケーション・コントローラに示します。

done

ユーザーの資格証明が更新された後のレスポンスのリダイレクト先URLです。

ページのエラー・コード

ログインおよびパスワード変更ページのURLでは、これらのページが正しく機能するために、以降の表に示すプロセス・エラーを受け入れる必要があります。

ログイン・ページのエラー・コード

ログイン・ページは、表H-8に示すエラー・コードを処理する必要があります。

表H-8 ログイン・ページのエラー・コード

p_error_codeの値

対応するメッセージと説明

acct_lock_err

説明: ユーザーは何度もログインに失敗しました。

メッセージ: 「アカウントがロックされています。システム管理者に通知してください。」

pwd_exp_err

説明: ユーザーのパスワードはすでに期限切れです。

メッセージ: 「パスワードが期限切れです。管理者に連絡して、パスワードをリセットしてください。」

null_uname_pwd_err

説明: ユーザーはユーザー名フィールドを空白のままにしました。

メッセージ: 「有効なユーザー名を入力してください。」

auth_fail_exception

説明: 認証に失敗しました。

メッセージ: 「認証に失敗しました。再試行してください。」

null_password_err

説明: ユーザーはパスワード・フィールドを空白のままにしました。

メッセージ: 「ログイン・パスワードを入力する必要があります。」

sso_forced_auth

説明: アプリケーションは認証を必要としています。

メッセージ: 「アクセスしようとしているアプリケーションに以前サインインしている場合でも、再度サインインする必要があります。」

unexpected_exception

説明: 予期しないエラーが認証中に発生しました。

メッセージ: 「予期しないエラーが発生しました。再試行してください。」

unexp_err

説明: 予期しないエラーです。

「予期しないエラーが発生しました。管理者に通知してください。」

internal_server_err

説明: 内部サーバー・エラーのレポートです。

メッセージ: 「内部サーバー・エラーです。管理者に通知してください。」

internal_server_try_again_err

説明: 再試行のプロンプト付きの内部サーバー・エラーのレポートです。

メッセージ: 「内部サーバー・エラーです。操作を再試行してください。」

internal_server_try_later_err

説明: 後での実行のプロンプト付きの内部サーバー・エラーのレポートです。

メッセージ: 「内部サーバー・エラーです。後で操作を実行してください。」

gito_err

説明: 非アクティブのタイムアウトです。ユーザーは再度ログインする必要があります。

メッセージ: 「シングル・サインオン・セッションが期限切れになっています。セキュリティのため、一定の時間操作がないとセッションは期限切れになります。再度サインインしてください。」

cert_auth_err

説明: 証明書サインオンに失敗しました。ユーザーは証明書が有効であることを確認するか、または管理者に連絡する必要があります。

メッセージ: 「証明書ベースのサインインに失敗しました。証明書が有効であるか確認してください。有効でない場合はシステム管理者に連絡してください。

session_exp_error

説明: シングル・サインオン・セッションのタイムリミットに達しました。

メッセージ: 「シングル・サインオン・セッションが期限切れになっています。セキュリティのため、指定された時間が経過するとセッションは期限切れになります。再度サインインしてください。」

userid_mismatch

説明: 強制認証中に提示されたユーザーIDは、現在のシングル・サインオン・セッションのユーザーIDと一致しません。

メッセージ: 「認証用に送信されたユーザー名は、既存のシングル・サインオン・セッションに存在するユーザー名と一致しません。」

ログイン後のメッセージ

表H-9に示すメッセージは、ユーザー認証の後に表示されます。これらのメッセージはログイン・ページによって処理されますが、パスワード変更ページによって表示される場合もあります。

表H-9 ログイン後のメッセージ

p_error_codeの値

対応するメッセージと説明

pwd_expiry_warn_err

説明: ユーザーのパスワードはまもなく期限切れになります。

メッセージ: 「パスワードがもうすぐ期限切れになります。変更してください。」

pwd_force_change_err

説明: ユーザーのパスワードが期限切れです。変更する必要があります。

メッセージ: 「続行する前にパスワードを変更する必要があります。」

pwd_grace_login_err

説明: ユーザーのパスワードは期限切れですが、猶予期間が有効であるためリセットできます。

メッセージ: 「パスワードが期限切れです。ログインの猶予期間です。パスワードを変更してください。」

パスワード変更ページのエラー・コード

パスワード変更ページは、表H-10に示すエラー・コードを処理する必要があります。

表H-10 パスワード変更ページのエラー・コード

p_error_codeの値

対応するエラー

confirm_pwd_fail_txt

古いパスワードと新しいパスワードは一致しません。

null_new_pwd_err

ユーザーは新しいパスワードを入力しませんでした。

null_old_pwd_err

ユーザーは古いパスワードを入力しませんでした。

pwd_expiry_warn_err

パスワードの有効期限が近づいています。

pwd_force_change_err

パスワードを変更しないと、ユーザーは先に進めません。

pwd_grace_login_err

パスワードは期限が切れましたが、猶予ログインが認められています。

account_deactivated_err

ユーザー・アカウントが無効です。

acct_lock_err

ユーザー・アカウントはロックされています。

pwd_illegal_value

パスワードに不正な値が含まれています。

pwd_in_history_err

パスワードはパスワード履歴の中にあります。

pwd_min_length_err

パスワードは最小長の要件を満たしていません。

pwd_numeric

パスワードは数字の要件を満たしていません。

外部アプリケーション・ログイン変更ページのエラー・コード

外部アプリケーション・ログイン・ページは、表H-11に示すエラー・コードを処理する必要があります。

表H-11 外部アプリケーション・ログイン・ページのエラー・コード

p_error_codeの値

対応するエラー

eapp_name_null

ユーザーIDがありません。

eapp_pwd_null

パスワードがありません。

ext_app_not_found

外部アプリケーションが見つかりません。

グローバリゼーション・サポートの追加

OracleAS Single Sign-Onフレームワークにより、デプロイメント固有ページを各々のデプロイメントのニーズに合わせてグローバル化できます。どの言語でページで表示するかを決めるとき、様々な方針を採ることができます。2つの方針を次の項で示します。

サポートされている言語コードの全リストは、次のURLで『Oracle Application Serverグローバリゼーション・ガイド』の付録Aを参照してください。

http://otn.oracle.co.jp/document/

このURLで表示されたページから、OracleAS Single Sign-Onのマニュアルへのリンクをクリックし、適切なリリースのライブラリを表示する「ライブラリの表示」リンクをクリックします。

ページに表示する言語の決定

この項では、「HTTP Accept-Language」ヘッダーとデプロイメント・ページ・ロジックのいずれかを使用して表示言語を選択する方法を説明します。

Accept-Languageヘッダーを使用したページの決定

ブラウザでエンド・ユーザーは、Webコンテンツを表示する際の言語(ロケール)を決定できます。ブラウザはユーザーが選択した言語をサーバーへ、HTTP Accept-Languageヘッダーの形式で送信します。デプロイメント固有ページのロジックはこのヘッダーを調べ、それに応じてこのページをレンダリングする必要があります。シングル・サインオン・サーバーでは、このページを受け取ると、Accept-Languageヘッダーの値を読み取り、ユーザーのアイデンティティの伝播時にその値をパートナ・アプリケーションへ送信します。多くのパートナ・アプリケーションでは、ユーザーがこのヘッダーをオーバーライドできますが、シングル・サインオフ・ページはサインオン時に確立された言語で表示される点に注意してください。このため、すべてのパートナ・アプリケーションで同じセッション言語が使用されます。

Accept-Languageヘッダーは、言語設定を決定するための推奨メカニズムです。この方法の主な利点は、エンド・ユーザーが他のWebサイトを閲覧している間に、言語をすでに設定している可能性が高いということです。そのため、これらのページとシングル・サインオンのページ間で閲覧の一貫性が保たれます。

ページ・ロジックを使用した言語の決定

前の項で説明した方法をお薦めしますが、ブラウザで設定された言語を拡張(またはオーバーライド)するメカニズムに基づいてグローバリゼーションを実装することもできます。たとえば、次のいずれかの方法があります。

- ログイン・ページに言語一覧を表示し、ユーザーが選択できるようにします。ユーザーの便宜を考慮して、永続Cookieを設定してこの選択を永続的なものにすることもできます。

- 言語を1つ設定して、ページをレンダリングします。この方法は、ユーザーが単一言語で入力することがわかっている場合に適しています。

- 集中管理されたアプリケーション・リポジトリまたはディレクトリから言語設定を取得します。ユーザー設定項目、システム設定項目、構成データの集中管理されたストアは、言語を格納するのに最適です。

ページのロジックを使用して言語を設定する場合、ページではこの情報をシングル・サインオン・サーバーに伝播する必要があります。サーバーは、この情報をパートナ・アプリケーションに伝播する必要があります。最終的には、一貫性のあるグローバリゼーションが保たれます。ページでは、ログイン・フォームのlocaleパラメータ(表H-2)を使用して、ISO-639形式で言語を渡す必要があります。多くのサイトには、ISO-639の2文字言語コードの全一覧があります。次のサイトにもこの一覧があります。

http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt

次のサイトには、ISO-3166の2文字国コードの全一覧があります。

http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

注意:
localeパラメータがシングル・サインオン・サーバーに渡されると(表H-1)、パラメータ値はmod_ossoへ送られます。mod_ossoはこの値をHTTP Accept-Languageヘッダーの先頭に追加してから、ヘッダーをパートナ・アプリケーションに渡します。

ページのレンダリング

エンド・ユーザーのロケールが決定されると、デプロイメント固有ページでは対応する翻訳文字列を使用して、ページをレンダリングする必要があります。これらの文字列の格納方法および取得方法については、『Oracle Application Server グローバリゼーション・ガイド』のロケール認識に関する章を参照してください。Java開発に関する標準的なドキュメントも参照してください。次に2つのリンクを示します。

- Javaの国際化ガイド:

http://java.sun.com/j2se/1.4.2/docs/guide/intl/index.html

- Javaドキュメントの一般的なリンク:

http://java.sun.com/j2se/1.4.2/docs

デプロイメント固有ページに関するガイドライン

デプロイメント固有ページを実装する場合は、次のガイドラインに従ってください。

- ログイン・ページとパスワード変更ページは、SSLで保護することをお薦めします。

- ログイン・ページとパスワード変更ページでは、クロスサイト・スクリプティング攻撃に備えてコーディングする必要があります。

- ログイン・ページとパスワード変更ページでは、自動埋込みとキャッシュをoffに設定する必要があります。これにより、ユーザーの資格証明がブラウザに保存されたり、キャッシュされる恐れはなくなります。AutoCompleteタグの例を次に示します。

<FORM NAME="foo" AutoComplete="off" METHOD="POST" ACTION="bar">

- オラクル社では、無認可のアクセスに対して警告するバナーを表示するように、ログイン・ページを構成することをお薦めします。たとえば、次のような文章を使用できます。

Unauthorized use of this site is prohibited and may subject you to civil and criminal prosecution.

- シングル・サインオン・サーバーをホスティングするコンピュータに、ログイン・ページおよびパスワード変更ページをデプロイします。これにより、これらのページの不正なバージョンを簡単に検出できます。

デプロイメント固有ページのインストール

policy.propertiesファイルを使用して、デプロイメント固有のログイン・ページとパスワード変更ページをインストールします。

policy.propertiesを使用したログイン・ページ、シングル・サインオフ・ページおよびパスワード変更ページのインストール

ログイン・ページ、シングル・サインオフ・ページおよびパスワード変更ページを構成できます。

独自のログイン・ページ、シングル・サインオフ・ページおよびパスワード変更ページをインストールする手順

1. ORACLE_HOME/sso/conf/policy.propertiesのパラメータを編集します。次の例に示す値を、ログイン・ページ、ログアウト・ページ、およびパスワード変更ページへのパスと置き換えます。

#Deployment login page link
loginPageUrl = /sso/pages/login.jsp
logoutPageUrl = /sso/pages/logout.jsp

#Deployment change password page link
chgPasswordPageUrl = /sso/pages/password.jsp

2. シングル・サインオン・サーバーを再起動します。

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

policy.propertiesを使用したワイヤレスのログイン・ページとパスワード変更ページのインストール

OracleAS Wirelessのフレームワークでは、デプロイメント固有のワイヤレスのログイン・ページとパスワード変更ページを統合できます。これらのページのインストール手順は、標準ページのインストール手順と同様です(前述の項を参照)。

ワイヤレスのログイン・ページとパスワード変更ページをインストールする手順

1. ORACLE_HOME/sso/conf/policy.propertiesを開きます。

2. 次のパラメータを編集または追加します。

#Wireless login page link
wirelessLoginPageUrl = wireless_login_page_url
wirelessChgPasswordPageUrl = change_password_page_URL

3. シングル・サインオン・サーバーを再起動します。

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

policy.propertiesを使用した外部アプリケーション・ログイン・ページのインストール

ユーザーがサード・パーティのアプリケーションにログインするときに表示されるログイン・ページを構成できます。

サード・パーティ・アプリケーションのログイン・ページを構成する手順

1. ログイン・ページが「ログイン・ページのパラメータ」および「ページ・エラー・コード」に示すページ・パラメータおよびページ・エラー・コードを受け入れることを確認します。

2. ログイン・ページを構成したら、ORACLE_HOME/sso/conf/policy.propertiesのextAppLoginPageUrlパラメータを編集し、次の例に示すパスをログイン・ページのパスに置き換えます。

extAppLoginPageUrl = /sso/pages/ealogin.jsp
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

3. 必要に応じて、アプリケーション・ページを構成できます。

4. シングル・サインオン・サーバーを再起動します。

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

デプロイメント固有ページの例

ipassample.jarファイルには、login-ex.jsp、password-ex.jsp、signoff-ex.jspの各ファイルが含まれています。これらのファイルを、デプロイメントに合わせてカスタマイズできます。これらのファイルを使用する場合は、次のようにします。次に示すコマンドを使用してファイルを取り出します。

ORACLE_HOME/jdk/bin/jar -xvf ORACLE_HOME/sso/lib/ipassample.jar

カスタム・クラスの使用

一般に、カスタマイズしたデプロイメント固有ページは、OC4J_SECURITYによって使用されている現在のバージョンのコンポーネント・クラスで動作する必要があります。カスタム・アプリケーションで、特定のクラスの別のバージョンを使用する必要がある場合は、そのクラスをOC4J_SECURITYインスタンスではなく、別のOC4Jインスタンスにデプロイすることが必要です。

たとえば、OC4J_SECURITYで使用されるバージョンと競合するカスタムlog4jクラスを使用する必要のあるデプロイメントでは、そのカスタム・クラスを含むローカルのlog4j jarファイルを使用する別のOC4J_SECURITYインスタンスを起動します。

警告:

OC4J_SECURITYで使用されるクラスをカスタム・バージョンに置き換えると、OracleAS Single Sign-Onや他のOracle Application Serverコンポーネントが使用できなくなる場合があります。

外部アプリケーションの追加

「シングル・サインオン・サーバー管理」ページで「外部アプリケーション管理」リンクをクリックし、「外部アプリケーションの追加」リンクをクリックすると、「外部アプリケーションの追加」ページが表示されます。このページには、次の見出しとフィールドが含まれています。

表H-12 外部アプリケーション・ログイン

フィールド

説明

アプリケーション名

外部アプリケーションを識別する名前を入力します。これは、外部アプリケーションのデフォルト名です。

ログインURL

外部アプリケーションのHTMLログイン・ページを認証するための送信先URLを入力します。次のログインURLの場合の例: Yahoo!Mail

http://login.yahoo.com/config/login?6p4f5s403j3h0

ユーザー名/IDフィールド名

外部アプリケーションのHTMLログイン・フォームのユーザー名またはユーザーIDフィールドを識別する用語を入力します。この用語は、ログイン・フォームのHTMLソースで確認できます。(この後の手順の例を参照してください)。このフィールドは、Basic認証を使用している場合は適用されません。

パスワード・フィールド名

外部アプリケーションのHTMLログイン・フォームのパスワード・フィールドを識別する用語を入力します。この用語は、ログイン・フォームのHTMLソースで確認できます。(この後の手順の例を参照してください)。このフィールドは、Basic認証を使用している場合は適用されません。

表H-13 認証方式

フィールド

説明

使用する認証タイプ

プルダウン・メニューから、アプリケーションで使用するフォーム送信方法を選択します。これは、ブラウザがメッセージ・データを送信する方法を示します。この文字列は、ログイン・フォームのHTMLソースで確認できます。次の3つの方法のいずれかを選択します。

POST: シングル・サインオン・サーバーにデータを転送し、ログイン資格証明をフォームの本文内で送信します。

GET: ページ・リクエストをサーバーに送信し、ログイン資格証明をログインURLの一部として発行します。

Basic認証: アプリケーションURL内のログイン資格証明を送信します。この送信は、HTTP Basic認証で保護されます。

注意:

- Basic認証で使用するポップアップ・ウィンドウは、Windows XPのサービス・パック2ではデフォルトでブロックされます。このサービス・パックを使用する場合、シングル・サインオン用ログイン・ページのウィンドウを表示するよう、ブラウザ設定を再構成してください。これには、Internet Explorerの「ツール」メニューにある「ポップアップ ブロック」を使用します。
他のブラウザおよびブラウザ・プラグインでも、ポップアップのブロックが可能です。Mozillaはこれらの1つです。これらのブラウザによってシングル・サインオンのログイン・ページがブロックされないようにしてください。

- Internet Explorer 5.0以上を使用する場合、外部アプリケーションでBasic認証が機能しないことがあります。このバージョンのInternet Explorerには、Microsoft MS04-004 Cumulative Security Update (832894)が含まれます。対処方法は、次のサイトを参照してください。

http://support.microsoft.com

表H-14 追加フィールド

フィールド

説明

フィールド名

ログイン時にユーザー入力を要求するフィールドをHTMLログイン・フォームに追加した場合は、そのフィールドの名前を入力します。このフィールドは、Basic認証を使用している場合は適用されません。

フィールド値

対応するフィールド名のデフォルト値を入力します(該当する場合)。このフィールドは、Basic認証を使用している場合は適用されません。

外部アプリケーションを追加する手順

1. 「外部アプリケーション管理」ページから、「外部アプリケーションの追加」を選択します。
「外部アプリケーションの追加」ページが表示されます。

2. 「外部アプリケーション・ログイン」フィールドに、外部アプリケーション名とHTMLログイン・フォームの送信先URLを入力します。Basic認証を使用する場合は、保護されたURLを入力します。

3. アプリケーションでHTTP POST認証またはHTTP GET認証が使用されている場合は、「ユーザー名/IDフィールド名」フィールドに、HTMLログイン・フォームのユーザー名またはユーザーIDフィールドを識別する用語を入力します。
この名前は、ログイン・フォームのHTMLソースで確認できます。

アプリケーションでBasic認証方式が使用されている場合は、「ユーザー名/IDフィールド名」フィールドを空にします。

4. アプリケーションでHTTP POST認証またはHTTP GET認証が使用されている場合は、「パスワード・フィールド名」フィールドに、アプリケーションのパスワード・フィールドを識別する用語を入力します。
ログイン・フォームのHTMLソースを参照してください。

アプリケーションでBasic認証方式が使用されている場合は、「パスワード・フィールド名」フィールドを空にします。

5. ログイン時にユーザー入力を要求するフィールドをHTMLログイン・フォームに追加した場合は、「追加フィールド」フィールドに、そのフィールドの名前とデフォルト値を入力します。
アプリケーションでBasic認証方式が使用されている場合は、これらのフィールドを空にします。

6. HTMLログイン・フォームでユーザーが追加フィールドのデフォルト値を変更できるようにする場合は、「ユーザーに表示」チェック・ボックスを選択します。

7. 「OK」をクリックします。新しい外部アプリケーションが、「外部アプリケーション管理」ページの「外部アプリケーションの編集/削除」ヘッダーの下に、他の外部アプリケーションとともに表示されます。

8. アプリケーションのリンクをクリックして、ログインをテストします。

次の例に示す値のソースの使用対象は、Yahoo!Mailです。

<form method=post action="http://login.yahoo.com/config/login?6p4f5s403j3h0" autocomplete=off name=a>
...
<td><input name=login size=20 maxlength=32></td>
....
<td><input name=passwd type=password size=20 maxlength=32></td>
...
<input type=checkbox name=".persistent" value="Y" >Remember my ID & password
...
</form>

ソースには次の値が示されています。

- ログインURL:

http://login.yahoo.com/config/login?6p4f5s403j3h0

- ユーザー名/IDフィールド名: login

- パスワード・フィールド名: passwd

- 使用する認証タイプ: POST

- フィールド名: .persistent Y

- フィールド値: [off]

注意:
AS中間層のホスト名を変更する場合は、この中間層で外部アプリケーションの「ログインURL」フィールドを手動で更新する必要があります。この変更は、次の項で説明する「外部アプリケーションの編集」ページで行います。

I トラブルシューティング

この章ではトラブルシューティングのヒントについて説明します。

- OAM 11gのトラブルシューティングの概要

- Oracle Access Manager Consoleの状態が矛盾している

- WebLogic Serverのインストール時に不正なJavaパスが指定されると管理サーバーが起動しない

- エージェント名が一意ではない

- アプリケーションURLの要件

- 認証の問題

- 認可の問題

- 認証LDAPまたはデータベースにアクセスできない

- 構成が見つからない

- 部分トリガーが見つからない

- サービス攻撃の拒否

- 新しくインストールしたOAM 10g Webgateでのデプロイメント

- IIS WebサーバーでのWindowsのチャレンジ/レスポンス認証の無効化

- UserIdentityStore1タイプを変更すると管理者がロックアウトされる可能性がある

- IIS Webサーバーの問題

- jpsロガー・クラスのインスタンス化警告が認証時にログに記録される

- 言語と翻訳

- 保護されたページへのログインの失敗

- OAMメトリック永続性タイマーIllegalStateException: SafeCluster

- 部分的なクラスタ障害および断続的なログインおよびログアウト障害

- 登録の問題

- Rowkeyに主キー属性がないエラー

- SELinuxの問題

- セッションの問題

- SSLとオープンな通信の比較

- 起動の問題

- OAMサーバー・クロックの同期化

- Coherenceの使用

- エラーの検証

- Webサーバーの問題

- Windowsネイティブ認証

OAM 11gのトラブルシューティングの概要

OAMはビジネス・クリティカルなシステムで、停止時間によりビジネスに高いコストが生じる可能性があります。システム分析の目標は、迅速な問題の切り分けおよび原因の修正です。これにはシステムの全体像と、使用中のシステムを監視し、コンポーネントをさらに大きな視野と関連付けるツールが必要です。

管理者による迅速な診断を支援するために、この項では次の項目を提供します。

- システム分析と問題例について

- LDAPサーバーまたはアイデンティティ・ストアの問題について

- OAMサーバーまたはホストの問題について

- エージェント側の構成およびロードの問題について

- 実行時データベース(監査またはセッション・データ)の問題について

- 変更の伝播またはアクティブ化の問題について

- ポリシー・ストア・データベースの問題について

システム分析と問題例について

システム分析には、製品の動作、失敗の可能性、起こりうる例、およびその影響または観測可能な問題の理解が含まれます。

システムの問題は次の基本的な2つのカテゴリに分類できます。

- 連鎖的で致命的な障害

- 漸進的なパフォーマンスの低下

連鎖的で致命的な障害は次のことが原因で発生する可能性があります。

- LDAPサーバーがロードされて応答しない

- 朝のピーク負荷の開始

- WebgateがプライマリOAMサーバーにリクエストを送信

- Webgateリクエストがタイムアウトで、WebgateがセカンダリOAMサーバーに再試行

漸進的パフォーマンスの低下は、次のように、時間の経過にともなって発生する可能性があります。

- OAMのサイズが変更され、10,000ユーザーおよび500グループ用にロールアウトされた

- 1年の間に、ユーザーおよびグループの数が大幅に増加(たとえば50,000ユーザーおよび250グループ)

もっとも一般的に発生する問題については、次の各項を参照してください。

- システム分析と問題例について

- LDAPサーバーまたはアイデンティティ・ストアの問題について

- OAMサーバーまたはホストの問題について

- エージェント側の構成およびロードの問題について

- 実行時データベース(監査またはセッション・データ)の問題について

- 変更の伝播またはアクティブ化の問題について

- ポリシー・ストア・データベースの問題について

LDAPサーバーまたはアイデンティティ・ストアの問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

- 症状: 動作が遅い

- 症状: サービスがすべて失われる

症状: 動作が遅い

- ユーザーの操作性の悪化

- エージェントのタイムアウトによる再試行

原因

- OAM以外の負荷がOAMの操作に影響を与える可能性がある

- ピーク負荷の漸進的増加によるキャパシティの問題

症状: サービスがすべて失われる

原因

- すべてのLDAPサーバーの停止

- ロード・バランサの古い接続のタイムアウト

診断

1. LDAPサーバーを停止します。

2. ブラウザを再起動します。

3. 保護されたサイトにアクセスしてみます。

4. 第22章(または第26章)の説明に従い、OAMサーバー・ログ・ファイルでエラーを確認します。

5. Oracle Access Managerコンソールにアクセスしてみます。

6. WebLogic AdminServerログ・ファイルでエラーを確認します。

7. LDAPサーバーを再度立ち上げます。

8. 保護されたアプリケーションに再度アクセスしてみます。

9. Oracle Access Managerコンソールに再度アクセスしてみます。

10. 環境に応じた要件に基づき問題を修正します。

OAMサーバーまたはホストの問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

- 症状: キャパシティの問題

- 症状: ホスト上の他のサービスとの衝突

症状: キャパシティの問題

- 動作の遅さによるユーザーの操作性の悪化

- エージェントのタイムアウトと再試行は余分な負荷となる可能性がある

原因

- CPUサイクル

- メモリの問題

症状: ホスト上の他のサービスとの衝突

- 動作の遅さによるユーザーの操作性の悪化

- エージェントのタイムアウトと再試行は余分な負荷となる可能性がある

原因

- CPUサイクルの競合

- メモリの競合

- ファイルシステムが満杯

診断: OAMサーバー

1. OAMサーバーを停止します

2. Webgateまたは保護されたリソースmod_ossoにアクセスしてみます

3. OAMサーバーを立上げます

4. アクセス・テスターを使用して、第14章の説明に従い認証および認可をテストします。

5. アクセス・テスターを使用しながら、'top'を使用してOAMサーバーのCPUおよびメモリ消費を計算します

6. OAMサーバーのスレッド・ダンプを取得します。

診断: OAM Adminサーバー

1. OAM AdminServerを停止します

2. ブラウザを再起動し、処理の必要がある保護されたリソースにアクセスします。

3. 第10章の説明に従い、リモート登録を使用して新しいパートナを登録します(これは失敗するはずです)。

4. OAM AdminServerを開始します。

エージェント側の構成およびロードの問題について

この項では、エージェントとサーバー間の時間の問題の症状、考えられる原因および診断手順を提供します。

症状: エージェントとサーバーでクロック時間が異なる

- エージェントおよびサーバーの両方で高いCPU使用率

- ユーザーにシステム停止が発生

原因

- エージェントはサーバーが発行したトークンが無効だと判断

- エージェントがトークンの再発行のためサーバーへ戻し続けている

診断

1. 保護されたリソースにアクセスします。

2. 確認: クライアント・アクセスがハングしています。

3. 確認: エージェントおよびサーバーで高いCPU使用率。

実行時データベース(監査またはセッション・データ)の問題について

監査およびセッション機能はどちらも書込み集中型の処理です。ポリシー・データベースは読取り集中型のサービスに対してチューニングできます。

症状

- 監査およびセッション処理が遅い

- OAMサーバー上のファイルシステムが、まだデータベースに書き込まれていない監査データで満杯

- クラスタ内のいずれかのサーバーの障害発生時にメモリ内セッションが消失

原因

- データベースが書込み集中型の処理向けにチューニングされていない

- データベースがメンテナンスにより使用できない

- データベースの容量の問題

診断

1. 監査およびセッション・データを格納するのに使用するデータベースを停止します。

2. 保護されたリソースにアクセスしてみます。

3. 第22章(または第26章)の説明に従い、OAMサーバー・ログ・ファイルでエラーおよび警告メッセージを確認します。

変更の伝播またはアクティブ化の問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

症状

- ポリシーへの変更がすぐに有効にならない

- システム構成への変更がすぐに有効にならない

原因

- サーバーがランタイム・リクエストの処理でビジー状態(CPUの競合)

- コヒーレンス・ネットワークが遅い

診断: 「ポリシー・ストア・データベースの問題について」を参照してください

ポリシー・ストア・データベースの問題について

この項では、ポリシー・データベースの問題の症状、考えられる原因および診断手順を提供します。

症状: ポリシーの変更が許可されず、実行時に影響を及ぼさない

原因

- データベースが使用できない(メンテナンスによる停止)

- データベースの容量の問題

診断

1. OAMポリシーを含むデータベースを停止します。

2. 保護されたリソースにアクセスし、実行時アクセスに影響が及んでいないことを確認します。

3. Oracle Access Managerコンソールにアクセスしてポリシーを編集してから、AdminServerログ・ファイルでエラーを確認します。

Oracle Access Manager Consoleの状態が矛盾している

問題

複数の管理者が更新を同時に実行すると、Oracle Access Managerコンソールのシステム構成が一貫性のない状態になります。

原因

構成の同時更新はサポートされていません。

解決策

どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。

WebLogic Serverのインストール時に不正なJavaパスが指定されると管理サーバーが起動しない

WebLogic Server (wls1035_generic)インストールが、32ビットJava (jdk1.6.0_24)が搭載されたWindows 64ビットでは正常に行われます。setup.exeを実行するとき、インストール・シールドが正常に起動するように64ビットJava (jdk1.6.0_23)のパスを指定する必要があります。

32ビットのJava (jdk1.6.0_24)パスを指定すると、インストール・シールドは起動しません。ただし、config.cmdを\Middleware\Oracle_IDM1\common\binから実行すると、デフォルトでは32ビットJava (jdk1.6.0_24)パスが使用されます。しかしOracle Access Managerのインストールが正常に行われた後で、AdminServerを起動できません。

Windowsホストでは、32ビットのJAVA_HOME (c:\program files (x86)\java\jdkxxx)はstartWeblogic.cmdによって正しく処理されません。SUN_JAVA_HOMEを短い名前のパス(c:\progra~2\java\jdkxxxx)を使用するよう置き換えることをお薦めします。

Windowsの場合、"dir /X"を実行することにより、短い名前を表示できます。

また、短い名前を使用してWindowsのコマンド・シェル変数JAVA_HOMEをパスに設定し、この中でstartWeblogic.cmdを実行することもできます。次に例を示します。

>set JAVA_HOME=c:\progra~2\java\jdkXXX

>startweblogic.cmd

エージェント名が一意ではない

各エージェント登録を一意に識別する名前が推奨されます。ただし、次のことに注意してください。

- エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければOracle Access Managerによってポリシーが作成されます。

- ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

アプリケーションURLの要件

URLで使用可能な文字数は、ブラウザのバージョンに基づいています。

Oracle Access Managerおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。

認証の問題

この項では次の情報を提供します。

- 匿名認証の問題

- X.509保護リソースおよびシングル・サインオフ

匿名認証の問題

問題

チャレンジ・リダイレクトURLはNULLでもかまいませんが、チャレンジ・メソッドにNULLは使用できません。

匿名認証スキームを開いて編集し、チャレンジ・メソッドの値を追加せずに「適用」をクリックすると、次のエラーが表示されることがあります。

Messages for this page are listed below.

* Challenge Method You must make at least one selection.

* Challenge Redirect You must enter a value.

解決策

匿名認証スキームを編集するときは必ずチャレンジ・メソッドとチャレンジ・リダイレクトの両方を含める必要があります。

X.509保護リソースおよびシングル・サインオフ

問題

シングル・サインオフが、X.509認証でリソースにアクセスした後で機能しないことがあります。ユーザーがログアウトURLでログアウトして、同じブラウザでリソースにアクセスしようとすると、認証が行われないことがあります。かわりに、ユーザーは証明書ポップアップを使用した認証を求められます。

これは、いずれのエージェント・タイプでも起こる可能性があります。

解決策

ログアウトURLを実行した後で、ブラウザで「SSL状態のクリア」を次のようにクリックしてから、X.509保護リソースにアクセスします。

ブラウザ・ウィンドウで、「ツール」メニューを開いて「インターネット オプション」をクリックし、「コンテンツ」、「SSL状態のクリア」の順に選択します。

認可の問題

問題: 制約エラー

IPv4範囲または一時的制約を作成または編集するたびに、エラーがoam-server診断ログ・ファイルに記録されます。

.... refreshPolicy specified but no response collector supplied

原因

これは誤ってERRORレベルでログに記録されるメッセージです。メッセージの正しいレベルはINFOです。

認証LDAPまたはデータベースにアクセスできない

認証に使用されるLDAPディレクトリ(またはポリシー・ストアとして定義されているデータベース)が停止またはアクセスできない場合、高負荷またはタイムアウトが原因の可能性があります。このLDAPまたはポリシー・ストアを使用する保護されたリソースへアクセスしようとするとメッセージが表示されます。

解決策

1. 登録されたLDAPまたはデータベースを手動で停止します。

2. 登録されたLDAPまたはデータベースを再起動します。

構成が見つからない

...の構成が存在しない

OAMサーバーをWebLogicサーバー・ドメインに構成する前にOAMサーバーに構成詳細を作成および適用しようとすると、次のことを伝えるメッセージが表示されます。

Configuration does not exist for path
/DeployedComponent/Server/oamServer/Instance/test

For more information, please see the server's error log for
an entry beginning with: Server Exception during PPR, #6.

この問題を解決するには、OAM 11gで構成を登録する前にWebLogic ServerドメインにOAMサーバーを構成する必要があります。

部分トリガーが見つからない

管理サーバー出力で、部分トリガーが見つからないというエラーが表示されることがあり(「ポリシー構成」タブまたは「ホスト識別子」ノードをクリックしたときに選択したノードそれぞれに対して複数回)、そのためナビゲーション・ツリーの他のノードのいずれかをクリックします。

これは機能を妨げるものではありません。

サービス攻撃の拒否

サービス拒否攻撃(DoS攻撃)または分散型サービス拒否攻撃(DDoS攻撃)は、コンピュータのリソースを対象ユーザーが利用できないようにする試みです。よくある1つの攻撃方法では、標的となるマシンを外部からの通信要求で溢れさせてしまいます。これにより、攻撃を受けたマシンは正規のトラフィックに応答できなくなるか、あるいは応答が遅くなり、事実上利用不可能になってしまいます。

サービス拒否攻撃は認証済リクエストと非認証リクエストに分類され、さらに次のように分類されます。

- NAPリクエスト

- HTTPリクエスト

認証済NAPリクエスト

認証済NAPリクエストの場合、OAMサーバーはセッション内でカウンタを使用して、再試行数を制限します。それでもユーザーはエラー・ページにリダイレクトされた後に、同じことを繰り返すことがあります。これによりサーバー・リソースが不必要に消費されて、OAMサーバーが過負荷状態になる可能性があります。

注意:
OAMサーバーが認証済NAPリクエストで過負荷になるのを防ぐため、関連するWebLogic過負荷構成設定を使用します。これにより、OAMサーバーは負荷でクラッシュしないようになります。しかし、これでは正当なユーザーが悪意のあるユーザーと区別されません。

認証済HTTPリクエスト

大量のHTTP認証済リクエストに対しては、WebLogic過負荷構成をmod_securityモジュール設定と組み合せることによって対処できます。

非認証NAPリクエスト

非認証NAPリクエストは、WebLogic MDBプール制限によって対処します。これにより、OAMサーバーに送られてくるNAPリクエスト数が制限されます。

繰り返しますが、これでは正当なユーザーが悪意のあるユーザーと区別されません。

非認証HTTPリクエスト

OAMサーバーのフロントエンドとなるOHSサーバーにmod_securityモジュールを構成することにより、悪意のあるリクエスト(非認証HTTPリクエスト)を拒否できます。

詳細は、次を参照してください。

- OAMサーバーを負荷でクラッシュしないようにする

- ネットワーク遅延に対する補償

- OAMサーバーを大量のHTTPリクエストから守る

OAMサーバーを負荷でクラッシュしないようにする

OAMサーバーに対するリクエスト数が処理可能な量を予想外に上回ると、OAMサーバーはクラッシュすることがあります。

OAMサーバーに対するリクエストの数を制限する手順

1. WebLogicコンソールで、Message Driven Beanプールを使用してOAMサーバーに対するNAPリクエスト数を制限します。
MDBeanはNAPリクエストをサーバー・キューから取り出して、サーバーへ処理のために送ります。MDBeanインスタンスの数を制限することにより、任意の時点に処理されるリクエスト数が制限されます。

2. WebLogicコンソールで、(OAMサーバーに対するリクエスト数を制限するために)使用できるWebLogicワーカー・スレッドの数を構成します。
MDBeanはNAPリクエストをサーバー・キューから取り出して、サーバーへ処理のために送ります。MDBeanインスタンスの数を制限することにより、任意の時点に処理されるリクエスト数が制限されます。

3. WebLogicコンソールで、(OAMサーバーに対するリクエスト数を制限するために)使用できるWebLogicワーカー・スレッドの数を構成します。
『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のスレッド管理に関するトピックを参照してください。

4. WebLogicコンソールで、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の次のトピックに従って、最大着信リクエスト・サイズ、完了メッセージ・タイムアウトを指定し、ファイル記述子の数を設定して、パフォーマンスを最適化します。

- メッセージ・サイズのチューニング

- 完了メッセージ・タイムアウトのチューニング

- ファイル記述子数のチューニング

ネットワーク遅延に対する補償

WebgateがOAMサーバーに認証リクエストを送信する場合を考えます。資格証明が正常に収集および検証された後で、OAMサーバーはセッションおよび関連Cookie (OAM_ID、ObSSOCookie)を作成します。ところがネットワーク遅延のために、OAMサーバーがそれをWebgateへ送信し、それによりWebgateが認証リクエストをOAMサーバーへ再送信する時間により、レスポンスはタイムアウトしてしまいます。OAMサーバーはセッションを認識し、それからObSSOCookieを再作成して、レスポンスをエージェントへ送信します。ネットワーク遅延がまだ続いていると、このサイクルはサーバーとWebgateの間で無限に繰り返します。ユーザーは再度ログインするように求められことがなく、エラー・メッセージも表示されません。

OAMサーバーを大量のHTTPリクエストから守る

ModSecurityは、既存のApacheベースのWebサーバー・インフラストラクチャの一部分としてデプロイできるWebアプリケーション・ファイアウォール(WAF)です。このモジュールを、OAMサーバーのフロントエンドとなるOHSサーバーにプラグインできます。こうすると、Mod_securityモジュールがOAMサーバーをサービス拒否攻撃から守ります。

柔軟なルール・エンジンがModSecurityの中心になります。HTTPトランザクション・データと連携する特殊なプログラミング言語である、ModSecurityルール言語を実装しています。新しい構成ディレクティブはhttpd-guardianスクリプトを使用して、サービス拒否(DoS)攻撃を監視します。デフォルトでは、httpd-guardianは1分間で120個以上、または5分間で360個以上のリクエストを送信するクライアントから防御します。

関連項目:
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/html-multipage/configuration-directives.html#N10689

大量のHTTPリクエストから防御する手順

1. mod_securityモジュールを、OAMサーバーのフロントエンドとなるOHSサーバーに追加します。

2. OHSサーバーの構成で、サービス拒否(DoS)攻撃を監視するhttpd-guardianスクリプトを使用するよう構成ディレクティブを設定します。
構文:

SecGuardianLog |/path/to/httpd-guardian

次に例を示します。

SecGuardianLog |/usr/local/apache/bin/httpd-guardian

新しくインストールしたOAM 10g Webgateでのデプロイメント

OAMサーバーの診断機能を使用してOAMサーバー側でデバッグします。この項には次のトピックが含まれます。

- OAM 10g Webgateでの認証の問題

- OAM 10g Webgateでのログアウトの問題

関連項目:
第15章「OAM 11gの集中ログアウトの構成」

OAM 10g Webgateでの認証の問題

次の方法を使用して、OAM 11gデプロイメントにOAM 10g Webgateを新たにインストールしたときの認証の問題をトラブルシューティングします。

- Internet Explorer HTTPヘッダーまたはFirefox Live HTTPヘッダーのようなhttpヘッダー・トレースを使用して、リクエストが保護されていたことを確認します。

- リクエストが認証のためOAMサーバーに送信されることを確認します。

- GET /oam/server/obrareq.cgi?…..

- ホスト: oam-server:port

OAM 10g Webgateでのログアウトの問題

次の方法を使用して、OAM 11gデプロイメントにOAM 10g Webgateを新たにインストールしたときのログアウトの問題をトラブルシューティングします。

- HTTPヘッダー・トレースを十分に使用します

- 特定のlogout.htmlが10g Webgateのインストール・ディレクトリの/access/oamssoフォルダにコピーされたことを確認します。存在しない場合、「OAM 11gサーバーでの10g Webgateの集中ログアウトの構成」の説明に従い、logout.htmlを作成する必要があります。

- OAM 10g Webgateのhttpd.confを変更して次の行を削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

- Oracle Access Managerコンソールから、LogoutUrlsパラメータ(/oamsso/logout.html)がこのWebgate用に構成されていることを確認します

OAM 11gの初期化およびパフォーマンスの問題の診断

この項は、次の項目を含みます。

- 初期化の問題の診断

- パフォーマンスの問題の診断

- メモリー不足の問題のヒープ・ダンプを使用した診断

初期化の問題の診断

問題

OAMサーバーが起動しない。

解決策

1. OAMサーバーをホストしているコンピュータ上のOAMサーバー・ログ・ファイルを探して確認します。

DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

2. 第22章「コンポーネント・イベント・メッセージのロギング」の説明に従い、このコンピュータのログを有効にします。

DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

3. OAMサーバーを再起動し、動作を監視し、必要ならばログ・ファイルを再度確認します。

パフォーマンスの問題の診断

問題

OAMサーバーの監視により、認証中の待機時間の著しいスパイクが明らかになります。

解決策

1. OAMサーバーをホストしているコンピュータ上のOAMサーバー・ログ・ファイルを探して確認します。

DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

2. 第22章「コンポーネント・イベント・メッセージのロギング」の説明に従い、このコンピュータのログを有効にします。

DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

3. OAMサーバーを再起動し、動作を監視し、必要ならばログ・ファイルを再度確認します。

メモリー不足の問題のヒープ・ダンプを使用した診断

問題

解析および評価のすべての式のデバッグにより、メモリーの増加が原因で、重大なパフォーマンスの負荷が20時間以内に発生し、メモリー不足で50時間以内実行していました。

構成: 2GBヒープ、3分のセッション・タイムアウト、jdbc接続をmin=32 max=200に調整、jdbc接続アイドル・タイムアウト無効、jboプール・サイズmin = 10 & max=150

解決策

比較用のヒープ・ダンプを生成するには、次のコマンドライン・ツールjmap(Sun jvm用)、またはJAVA_HOME/binの下にあるjrcmd(jrockit jvm用)を使用します。

jrockit jvm用

jrcmd pid <command>
/jrockit_160_14_R27.6.5-32/bin/jrcmd 16775 heap_diagnostics
/jrockit_160_14_R27.6.5-32/bin/jrcmd 16775 print_threads
/jrockit_160_14_R27.6.5-32/bin/jrcmd 16775 jrarecording ....

Sun jvm用

jmap -histo <pid>
jmap -dump:live,format=b,file=heap.bin <pid>

IIS WebサーバーでのWindowsのチャレンジ/レスポンス認証の無効化

Windows上のIIS Webサーバーは、IISがインストールされたときのデフォルトであるチャレンジ/レスポンス認証をサポートします。これにより、ユーザーはIISからリソースをリクエストされ、Oracle Access Managerの認証と競合する可能性があるときにドメイン・ログインを使用できます。

たとえば、Internet Explorer(IE)ブラウザから、Oracle Access ManagerによりBasic認証スキームで保護されたIIS上のリソースへの最初のリクエスト時に、IEはドメインとOracle Access Managerにより提供されたユーザー名よびパスワード・ログインを要求するログイン・ダイアログ・ボックスを表示します。

Windowsのチャレンジ/レスポンス認証を無効にする手順

1. IIS用のMicrosoft Management Consoleを起動します。

2. 左側のパネルで「Internet Information Server」の下の「Web Server Host」を選択します。

3. 右クリックして「Properties」を選択します

4. スクロール・ダウンし、「Edit the Master Properties for WWW Service」を選択します。

5. 「Directory Security」タブを選択します。

6. 「Edit Anonymous Access and Authentication Control」を選択します。

7. 使用しているプラットフォームに応じた手順を完了します。
Windows 2000: 「Integrate Windows Authentication」チェック・ボックスの選択を解除します。

8. 「OK」をクリックします。

9. 「Windows IIS properties」画面で「OK」をクリックします。

10. Microsoft Management Consoleを閉じます。

UserIdentityStore1タイプを変更すると管理者がロックアウトされる可能性がある

システム・ストアとして指定されているアイデンティティ・ストアを編集し、ストア・タイプを変更したり(たとえば、組込みLDAPからOIDへ)接続URLを変更しないようにする必要があります。

編集でのストア・タイプ変更を禁止するシステム・ストアとして指定されているアイデンティティ・ストアを変更する必要がある場合は、新規アイデンティティ・ストアを作成してから、この登録を編集してシステム・ストアとしてマークすることをお薦めします。

IIS Webサーバーの問題

次の各項目が役に立ちます。

- フォーム認証またはパススルーが動作しない

- IISおよび一般Webコンポーネントのガイドライン

- IIS v6 Webサーバーの問題

- ページが表示されないエラー

- IIS DLLの削除および再インストール

フォーム認証またはパススルーが動作しない

フォーム認証またはパススルー機能が動作しない場合、問題はWebgateプロファイルの"UseWebGateExtForPassthrough"パラメータがtrueに設定されていないか、webgate.dllがIISのWild Card Application Mappingのように構成されていないかのいずれかである可能性があります。このような場合、Webgateはフォームベース認証により保護されたリソースに対するHTTP "POST"リクエストの認証または認可を実行しません。

解決策: WebgateプロファイルのUseWebGateExtForPassthroughパラメータを値trueで構成し、webgate.dllをWild Card Application Mappingのように構成します。

IISおよび一般Webコンポーネントのガイドライン

Oracle Access Manager WebgatesとIIS Webサーバーのインストール時の一般的なガイドラインを次に示します。

アカウント権限: Oracle Access Managerのインストールを実行するアカウントには管理者権限が必要です。OAMサービスを実行するのに使用するユーザー・アカウントには"サービスとしてログオンする"権限が必要で、これは管理ツール、ローカル・ポリシー、ローカル・ポリシー、ユーザー権限の割当て、サービスとしてログオンを選択して設定できます。

IIS 6 Webサーバー: WWWサービスをIIS 5.0分離モードで実行する必要があります。これはISAPIのpostgateフィルタにより必要です。Oracle Access Managerのインストール中に、これは通常自動的に設定されます。されなかった場合、デフォルトのWebサイトに手動で設定する必要があります。

IIS 7 Webサーバー用Webgate: フォームベース認証をパススルー機能を有効にしないで使用するには(たとえば、"access/oblix/apps/webgate/bin/webgate.dll"はフォームベース認証スキームのアクションです)、エントリ"<add segment="bin"/>"がapplicationHost.configファイルに存在しないようにします。エントリが存在する場合、削除する必要があります。このエントリを確認するには、次の手順を使用します。

- Windows\System32\inetsrv\configに移動してファイルapplicationHost.configを開きます

- <hiddenSegments>モジュールを検索し、もしあればエントリ<add segment="bin"/>を削除します。

Webgate: IIS Webgateのインストール時に、NTFSをサポートするファイル・システムにインストールする場合にのみ、IIS Webgateでは、/accessディレクトリに対する様々な権限の設定が必要です。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータで、簡易または証明書モードでISAPI Webgateをインストールすると仮定します。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。

IIS v6 Webサーバーの問題

IIS 6 Webサーバーでのみ、WWWサービスをIIS 5.0分離モードで実行する必要があり、これはISAPI postgateフィルタの要件です。この例は、32ビットWindowsオペレーティング・システムで実行している32ビットのOracle Access Managerバイナリがある場合に動作します。しかし、IISが32ビット・モードで実行している64ビットWindowsマシンで32ビットpostgate.dllを実行しようとすると問題が発生します。

問題

IISがIIS5.0分離モードで実行している場合、次のメッセージが表示されます。

ISAPIフィルタ'C:\webgate\access\oblix\apps\webgate\bin\webgate.dll'は構成の問題が原因でロードできませんでした。

原因

現在の構成はAMD 64ビット・プロセッサ・アーキテクチャ用に作成されたイメージのロードのみをサポートします。データ・フィールドにはエラー番号が含まれます。

解決策

この問題の詳細は、この種類のプロセッサ・アーキテクチャの不一致のエラーのトラブルシューティング方法も含め、次のWebサイトを参照してください。

http://go.microsoft.com/fwlink/?LinkId=29349

詳細は、次のヘルプとサポート・センターを参照してください。

http://go.microsoft.com/fwlink/events.asp

問題

IIS5は64ビットとして存在することはありません。しかし、64ビットWindowsコンピュータ上でのIIS v6のIIS5互換モードだけは64ビットとして実行します。

原因

次のURLで参照できるドキュメントのとおり、64ビットWindowsでIIS5分離モード32ビットを実行することはアーキテクチャ上不可能です。

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.pu
blic.inetserver.iis&tid=5dd07102-8896-40cc-86cb-809060fa9426&cat=en_US_
02ceb021-bb43-476d-8f8f-6c00a363ccf5&lang=en&cr=US&p=1

http://blogs.msdn.com/david.wang/archive/2005/12/14/HOWTO-Diagnose-one-cause-of-W3
SVC-failing-to-start-with-Win32-Error-193-on-64bit-Windows.aspx

ページが表示されないエラー

パススルー機能用にWebgateを構成した後に表示される、ページが表示できないというエラーは、構成の問題を示しています。

解決策: WebgateプロファイルのUseWebGateExtForPassthroughパラメータを値trueで構成し、webgate.dllをWild Card Application Mappingのように構成します。

IIS DLLの削除および再インストール

Oracle Access ManagerがMicrosoftのIIS Webサーバーで実行している場合、Oracle Access Managerを再インストールするときには次のISAPIフィルタを手動でアンインストールおよび再インストールする必要があります。

- tranfilter.dll

- oblixlock.dll(Webgateがインストール済の場合)

- webgate.dll(Webgateがインストール済の場合)

IIS DLLを削除および再インストールする手順

1. Oracle Access Managerをアンインストールします。

2. 前述のDLLを手動でアンインストールします。

3. Oracle Access Manager.Active Directoryを再インストールします。

4. DLLを手動で再インストールします。

注意:
これらのフィルタは使用しているIISのバージョンにより異なる可能性があります。これらのフィルタが存在しないまたは別のものが存在する場合、存在するフィルタを削除する必要があるかどうかはOracleにお問い合せください。

jpsロガー・クラスのインスタンス化警告が認証時にログに記録される

jpsロガー・クラスのインスタンス化警告が認証時にバックエンドに表示されることがあります。しかしこれは無害な警告で対処する必要はありません。

言語と翻訳

ここでは、次の内容について説明します。

自動生成された説明が翻訳されない

「ポリシー構成」タブの各コンポーネントの自動生成された「説明」は翻訳されません。これは異常ではなく、管理者が「説明」を必要にあわせて変更できるようにします。このような変更に従うため、Oracleによる翻訳が可能になっていません。

ロケール、言語、およびOracle Access Managerコンソール・ログイン・ページ

ブラウザのロケールがサポートされていない場合、Oracle Access Managerコンソールのログイン・ページはサーバー・ロケールで表示されます。つまり、元の英語で表示されます。これは正常な動作です。

- クライアントのロケールがサポートされていない場合、Oracle Access Managerはサーバー・ロケールに戻ります。

- サーバー・ロケールがサポートされていない場合、Oracle Access Managerは英語に戻ります。

ユーザーがサポートされない言語を選択して「Oracle Access Manager SSO」ページに進むと、サーバー・ロケールで表示されます(たとえばドイツ語)。しかし、ログイン後は、すべてのページが英語で表示されます。

英語に戻る手順

「Oracle Access Manager SSO」ページを無効にすると、元のOracle Access Managerログイン・ページも英語に戻ります。

コンソールがきれいに表示されない

リモート登録用に入力されたFusion Applications構成ファイルがUTF-8形式でない場合や、OAMサーバーがUTF-8ロケール(たとえばen_US.utf8)で起動していない場合、Oracle Access Managerコンソールでポリシーおよびリソースが正しく表示されません。

認証ポリシーおよび保護リソースを生成するためにリモート登録ツール用のFusion Applications構成ファイルoamregを作成する場合は、UTF-8エンコーディングを必ず使用してください。また、OAMサーバーをUTF-8ロケールのマシンで起動することも必要です。それ以外の場合、インバンド登録が成功した後にOracle Access Managerコンソールでポリシーとリソースがきれいに表示されない可能性があります。

保護されたページへのログインの失敗

問題

物理的なホストおよびポートを使用してOAMのインストールとページの保護後、OHS物理ホストおよびポートを使用してパートナ・アプリケーションを登録します。保護されているページにアクセスするときに、ログインはユーザーへの資格証明の要求に失敗します。ログ・ファイルに、すべての構成と登録が正しく設定されているにもかかわらず、そのURがは仮想ホストにリダイレクトされたことが示されます。

解決策

Oracle HTTP Server(OHS)物理ホストおよびポートを使用してページを保護する場合、httpd.confから仮想ホスト・ディレクティブを削除します。

OAMメトリック永続性タイマーIllegalStateException: SafeCluster

問題

WebLogic構成ウィザードを使用して2つのコンピュータに1つのOAMサーバー・クラスタを作成し、AdminServerを開始した後で、すべてのサーバーが適切に開始します。停止後、3つ目のサーバーをWebLogicサーバー管理コンソールを使用して追加し、新しい管理対象サーバーを作成してクラスタに追加します。3つ目のサーバーは開始すると実行モードになりますが、いくつかの例外が開始ログに記録されます。

... Exception in thread "OAM Metric Persistence Timer"

解決策

WebLogic管理コンソールでの操作に追加して、Oracle Access Managerコンソールを使用してサーバーを登録し、サーバーが自分自身を識別できるようにする必要があります。

注意:
同じコンピュータに対し2番目のサーバー・インスタンスを追加および登録する場合、すべてのポート番号は異なる必要があります。OAMプロキシ・ポート("ポート"はWebLogicサーバー・コンソールのものと一致する必要があります)とコヒーレンス・ポートです。

サーバー登録の詳細は、「個別のOAMサーバー登録の管理」を参照してください。

部分的なクラスタ障害および断続的なログインおよびログアウト障害

問題

Oracle Access Managerの部分的な停止(クラスタのいくつかのインスタンス、ただしすべてではない)が発生したときに、エンド・ユーザーに断続的なログインおよびログアウト障害が発生することがあります。

回避策

1. デプロイメントからOHSを削除します

2. 各OHSインスタンスがWebLogicサーバー・インスタンスに固定されるようにOHSクラスタを構成します。

3. 正常に動作していないOracle Access ManagerアプリケーションのあるWebLogicサーバー・コンテナは、サービスから削除(停止)してリカバリ時に戻される必要があります。

登録の問題

問題: リモート登録ツールの障害

解決策

エージェント名が一意(まだ存在していない)でAdminServerが実行していることを確認します。

問題: ObAccessClient.xmlファイルが生成されない

解決策

保護されたパブリック・リソースは、'/index.html'の形式の相対URLとして記述される必要があります。リソースの最初が'/'でないと、ObAccessClient.xmlファイルは生成されません。保護されたパブリック・リソースURLを確認し、すべてが"/"で始まるようにしてください。詳細は、「リソースURLについて」を参照してください。

問題: パートナ登録の障害

パートナ登録は、一意のエージェント名を指定しないと失敗する場合があり、このエージェント名は、アプリケーション・ドメインを作成するためにも使用されます。エージェント名とアプリケーション・ドメイン名は同一であることと一意であることが必要です。エージェント名がアプリケーション・ドメイン名と一致しないと、oamreg検証コマンドの使用が失敗する場合があります。

解決策

エージェント名およびアプリケーション・ドメイン名は必ず同じにします。

Rowkeyに主キー属性がないエラー

「リソース・タイプ」タブの「リソース」表の参照中に、次のエラー・メッセージがログに記録されます。

@ <Error>
<oracle.adfinternal.view.faces.model.binding.CurrencyRowKeySet>
@ <BEA-000000> <ADFv: Rowkey does not have any primary key attributes. Rowkey:
oracle.jbo.Key[], table: model.ResTypeVOImpl@620289.>

これは無害で機能を妨げるものではありません。

SELinuxの問題

Oracle Enterprise Linuxに同梱されているSELinux変更は、Linuxカーネル内でLinux Security Modules(LSM)の使用を介して様々なポリシーを提供します。

SELinuxには、Oracle Access Manager Webgateのインストール後、関連するWebサーバーの開始前に、追加の手順の実行が必要です。

問題

より厳密なSELinuxポリシーが存在するLinux配布上のWebサーバーを開始するときに(Oracle Access Manager Webgateのインストール後)、次のエラーがログ/コンソールに記録されることがあります。

OAM 11g Webgate

$Webgate_OH/webgate/ohs/lib/webgate.so: cannot restore segment prot after reloc:
Permission denied.

OAM 10g Webgate

$Webgate_install_dir/access/oblix/apps/webgate/bin/webgate.so: cannot restore segment prot after reloc:
Permission denied.

原因

これらのエラーはファイルのセキュアLinuxセキュリティ・コンテキスト・ポリシーにより報告されます。

解決策

これらのエラーを防ぎ、Webサーバーを開始するには、次のchconコマンドを実行し、各Oracle Access Manager Webコンポーネントのインストール後、関連するWebサーバーの再起動前に、ファイルのセキュリティ・コンテキストを変更します。chconコマンドの詳細は、ご使用のLinuxのドキュメントを参照してください。

1. chcon -t texrel_shlib_t PATH_TO_LIBWEBPLUGINS.SOを実行します。次に例を示します。

chcon -t texrel_shlib_t  /Webgate_install_dir/access/oblix/lib/webgate.so
... and libxmlengine.so

2. chcon -t texrel_shlib_t PATH_TO_LIBWEBGATE.SOを実行します。次に例を示します。

chcon -t texrel_shlib_t  /Webgate_install_dir/access/oblix/apps/webgate/
bin/webgate.so

セッションの問題

この項の内容は次のとおりです。

- セッション偽装がデフォルトでは有効になっていない

- Oracle Identity Federationと統合されたOracle Access Managerとのセッション

セッション偽装がデフォルトでは有効になっていない

セッション偽装はデフォルトでは有効になっていません。oam-config.xmlの値を更新し、oam-config.xmlのバージョンを更新してImpersonationConfigステータスをすべての管理対象サーバーへ、再起動することなく伝播できます。

セッション偽装を有効にする手順

1. DOMAIN_HOME/config/fmwconfig/oam-config.xmlをバックアップします。

2. ImpersonationConfigをtrueに設定します。

<Setting Name="ImpersonationConfig" Type="htf:map">
<Setting Name="EnableImpersonation" Type="xsd:boolean">false</Setting>
</Setting>

3. 構成バージョン: 次に示すように、Version xsd:integerをこの例の最終行の値まで増分します(既存の値(ここでは25) + 1)。
次に例を示します。

<Setting Name="Version" Type="xsd:integer">
<Setting xmlns="http://www.w3.org/2001/XMLSchema"
Name="NGAMConfiguration" Type="htf:map:>
<Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
<Setting Name="Version" Type="xsd:integer">25</Setting>
</Setting>

4. oam-config.xmlを保存します。

Oracle Identity Federationと統合されたOracle Access Managerとのセッション

Oracle Access Manager 11gがOracle Identity Federationと統合されている場合にOracle Access Managerセッション管理機能を使用してセッションをクリアすると、Oracle Access Managerセッションのみがクリアされます(Oracle Identity Federationセッションはクリアされません)。

SSLとオープンな通信の比較

管理対象サーバーのSSLおよびオープン・ポートの両方が有効な場合、管理対象サーバーはデフォルトでSSLポートに設定されます。

SSL以外のポートを使用する必要がある場合、認証スキームの資格証明コレクタのURLは、プロトコルとして'http'およびSSL以外のポートを指す絶対URLに設定する必要があります。

起動の問題

問題: AIXプラットフォームでのAdminServer起動(またはリモート登録ツールの障害)

AdminServerの起動が、次のメッセージを表示して失敗します。

"java.net.SocketException:
No buffer space available".

オペレーティング・システムに設定されたAIXファイル記述子数の構成がかなり高い(ulimit)ためにバッファ・オーバーフローとなり、リモート登録が次のメッセージで失敗します。

ulimit値はアプリケーションに依存しており、アプリケーション・プログラム・データおよびアプリケーション・スタックに排他的に適用されます。オープン・ファイルのデフォルト数設定(2000)は、通常はほとんどのアプリケーションで十分です。この値が低すぎると、ファイルを開く際や接続を確立する際にエラーが発生します。この値はサーバー・プロセスが開けるファイル記述子数を制限するため、値が低すぎると最適なパフォーマンスが損なわれます。AIXオペレーティング・システムでは、デフォルト設定は2000です。

解決策

ulimitファイル記述子限度を大きくすると、パフォーマンスが向上する場合があります。アプリケーションによっては、他の限度を大きくすることが必要になる場合もあります。

1. rootユーザーでログインします。

2. オープン・ファイル限度を10,000ファイルに変更するには、次の手順を実行します。

1. コマンド・ウィンドウを開きます。

2. /etc/security/limitsファイルを探して、AdminServerプロセスを実行するユーザー・アカウントに次の行を追加して編集します。

nofiles =  10000
nofiles_hard = 10000

3. ファイルを保存してAIXを再起動します。

3. コマンド・ウィンドウでTCP_TIMEWAIT間隔を、次のコマンドで状態を15秒に設定して減らします(これによりTCPはクローズした接続を速く解放でき、オープン接続が使用できるリソース数が増えます)。

/usr/sbin/no –o tcp_timewait =1

4. 次のパラメータを、次に示すように256kにチューニングします。

no -a |grep space
tcp_recvspace = 262144
tcp_sendspace = 262144
udp_recvspace = 262144
udp_sendspace = 262144

5. 次のパラメータを、次に示すようにチューニングします。

no -o rfc1323=1
no -o sb_max=4194304

問題: OAMサーバーとの接続を確立できませんでした。サーバーとの接続で例外が発生しました。接続が拒否されました。

原因:

IAMSuiteAgentエージェントはOAMサーバーの前に開始しているため、これはOAMサーバーが実行している管理対象サーバーの正常な予想される動作です。

IAMSuiteAgentはすべてのWebLogicコンテナにデプロイされます。WebLogicコンテナが開始されると、エージェントはOAMサーバーに接続しようとします。接続が失敗すると、このメッセージがログに記録され、エージェントは後続のリクエストで接続を確立しようとします。エージェントが接続に成功すると、このメッセージは表示されなくなります。

解決策

OAMサーバーへの接続が正常に行われないと、構成されている場合は、IAMSuiteAgentはフォールバックし、WebLogicコンテナは保護を処理(ログインを含む)します。

OAMサーバー・クロックの同期化

セッションの状態は依存側にとっての真のソースです。様々なサーバーのシステム・クロックは同期が必要です。

依存側のシステム・クロックは、SMEクロックの同期の範囲外であることがあります。依存側のクロックが次の場合:

- セッション・クロックよりも進んでいる: 依存側の認証のリクエストが作成されアクティブ・セッションIDが戻されます。

- セッション・クロックよりも遅れている: 依存側ヘルプへのイベント通知によりセッションが無効になります。

たとえば、Webサーバー・クロックがサーバー・クロックよりも進んでいる場合、WebgateからOAMサーバーに送信されるリクエストには、OAMサーバーではまだ発生していない時間が含まれます。これによりログイン・イベントが失敗することがあります。簡易または証明書モードで実行している場合、タイムスタンプは同期の範囲外となるか、またはクライアント証明書が無効のように見えることがあります。

注意:
イベント通知の問題を防止するには、すべてのOAMサーバーのクロックをNISTインターネット・タイム・サービスのようなタイム・サービスに同期させるようにします。

正常な処理のために次のことを行います。

- すべてのコンピュータ・クロックが同期しているようにします。許容レベルはありません。たとえば、WebgateクロックがわずかでもOAMサーバー・クロックより進んでいる場合、Webgateにより生成されたCookieは未来のものと見なされ、OAMサーバーで問題を引き起こす可能性があります。

- Webgateが実行している各コンピュータのクロックが、関連するOAMサーバーよりも進んでいないことを確認します。OAMサーバーは最大60秒までWebgateのクロックよりも進んでいる必要があります。

Coherenceの使用

Oracle Access Manager 11gはOracle Coherenceを使用して、分散インストール内でセッション状態を複製します。Coherenceを使用して、Oracle Access ManagerコンソールとOAMサーバーの間の状態変更を通信します。

次の2つの分散デプロイメント・トポロジを考えます。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。OAM 11gの特定のコンポーネント間にファイアウォールが存在する場合、Coherenceによって使用される対応したUDPポートが開いている必要があります。そうでない場合、OAM 11gが正しく機能しない可能性があります。

たとえば、Coherenceが使用するUDPポートは次のようにオープンしている必要があります。

- Oracle Access Managerコンソールはイントラネット内にデプロイされており、OAMサーバーはDMZにデプロイされています。この場合、Coherenceが使用するUDPポートは、DMZとイントラネットの間のファイアウォールでオープンしている必要があります。

- Oracle Access ManagerコンソールとOAMサーバーはDMZのそれぞれ別のセキュリティ・ゾーンにデプロイされており、隣り合う2つのゾーンの間にはファイアウォールが設置されています。この場合、Coherenceが使用するUDPポートは、Oracle Access ManagerコンソールおよびOAMサーバーの1つ以上のインスタンスが実行される、隣り合ったセキュリティ・ゾーンの間のファイアウォールでオープンしている必要があります。

Oracle Access Manager 11gはOracle Coherenceを使用して分散キャッシュのデータ・アクセス待機時間を短縮し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細は、「Oracle Coherenceとセッション管理」を参照してください。

警告:

Oracleサポートからの要求がない限り、Oracle Coherence設定を変更しないことをお薦めします。

表示しているのが個別のサーバー・インスタンスのOracle Coherence設定、またはすべてのOAMサーバーに共通のOracle Coherence詳細のいずれであっても、Oracleサポートからの要求がない限り、Oracle Coherence設定を変更しないことをお薦めします。

Oracle CoherenceのログはWebLogicサーバー・ログにのみ表示されます。Oracle CoherenceのログからOracle Access Managerのログへの橋渡しはありません。

関連項目:
Oracle Coherenceのドキュメント。

エラーの検証

問題: リソースが認証または認可ポリシーに追加されない

認証または認可ポリシーの作成中に、別の認証または認可ポリシーで使用したことのあるリソースを追加する場合、「適用」をクリックするときに検証エラーが表示されます。これは予想通りです。

エラー・ウィンドウで「OK」をクリックすると、別の認証または認可ポリシーで使用されていない有効なリソースを追加することを求められ、そのリソースは追加されず、認可または認証ポリシーは作成されません。

解決策

1. 「適用」をクリックして、「認証ポリシー」または「認可ポリシー」ページを閉じます。

2. ナビゲーション・ツリーでポリシー名を再度クリックし、「編集」をクリックしてページを開き、新しいリソースを追加します。

問題: 検証に失敗 - "description"属性が無効

200文字を超えるオプションの説明を入力すると検証エラーが表示されます。

解決策

オプションの説明の長さは200文字、10行以内にします。

Webサーバーの問題

Webサーバーで次の問題が発生することがあります。

- Apache Webサーバー上のサーバー障害

- HP-UX上のApache v2

- Red Hat Enterprise Linux 4にバンドルされたApache v2

- Security-Enhanced LinuxにバンドルされたApache v2

- Webgateのmpm_worker_moduleを使用したUNIX上のApache v2

- Domino Webサーバーの問題

- エラー、アクセスの消失および予期しない動作

- ISA Webサーバーの既知の問題

- LinuxThreadsでOracle HTTP Serverが開始しない

- Linux Red Hat 4上でOracle HTTP Server Webgateが初期化されない

- Oracle HTTP Server Web Server構成ファイルの問題

- IIS v6 Webサーバーの問題

- Sun Webサーバーの開始時のPCLOSEエラー

- IIS DLLの削除および再インストール

Apache Webサーバー上のサーバー障害

症状: Apache Webサーバーを実行中に、OAMサーバーが次のメッセージを表示して失敗します。

libthread panic: cannot create new lwp
(PID: 9035 LWP 2). stackrace:
ff3424cc
0

この症状は、Apache Webサーバーが多くの自分自身のインスタンスを起動することにより発生することがあります。1つまたは複数のWebgateおよびOAMサーバー間の接続数をサービスするにはもっと多くのインスタンスが必要だとサーバーが判断したときに、これが発生することがあります。

追加のインスタンスはさらに多くの接続を作成し、OAMサーバーによる接続数を超過します。

解決策: MinSpareServers、MaxSpareServers、StartServersおよびMaxClientsパラメータの数を減らします。

OAMサーバーの構成ディレクトリに移動し、http.d構成ファイルを開きます。

推奨するパラメータ設定は次のとおりです。

- MinSpareServers 1

- MaxSpareServers 5

- StartServers 3

- MaxClients 5

HP-UX上のApache v2

HP-UX上でApache v2を実行している場合、共有メモリーが動作できないため、「ユーザー」または「グループ」にnobodyは使用できません。その代わりに、「ユーザー名」にログイン名を、HP-UX上の「グループ名」に使用しているグループを使用します(Solarisでは"www"は"nobody"と同等です)。

HPUX 11.11上でApache v2を実行している場合、Apache httpd.confファイルのAcceptMutexディレクティブがfcntlに設定されていることを確認します。ディレクティブが存在しない場合、httpd.confファイルに追加します(AcceptMutex fcntl)。詳細は、次を参照してください。

http://issues.apache.org/bugzilla/show_bug.cgi?id=22484

Red Hat Enterprise Linux 4にバンドルされたApache v2

ベンダー・バンドルApacheにWebgateをインストールした後、Webサーバーの開始時に次のエラーが発生することがあります。

Error: Cannot load libgcc_s.so.1 library - Permission denied.

解決策: 「Oracle Access Manager Webgate用のApache/IHS v2のチューニング」の説明に従い、Oracle Access Manager Webgate用のSecurity-Enhanced Linux (SELinux)ポリシー・ルールを変更します。

Security-Enhanced LinuxにバンドルされたApache v2

Oracle Access Manager Webコンポーネントのインストール後、より厳密なSELinuxポリシーが存在するLinux配布上のWebサーバーを開始するときに、エラーがWebServerのログ/コンソールに記録されることがあります。Webサーバーを再起動する前に、インストールされたWebコンポーネント用の適切なchconコマンドを実行することにより、これらのエラーを防止できます。

関連項目:
「SELinuxの問題」

Webgateのmpm_worker_moduleを使用したUNIX上のApache v2

次の項目は、UNIX上でWebgate用のApache v2をmpm_worker_moduleを使用してコンパイルする場合にのみ必要です。この場合、UNIX環境用にApacheソースからthread.cファイルを変更する必要があります。この変更を行うことで、Webgateのデフォルトのpthreadスタック・サイズによりマルチスレッド・サーバーの実装中に最適なパフォーマンスが得られるようになります。この変更が行われないと、デフォルトのpthreadスタック・サイズはWebgateに対して十分ではなく、クラッシュしてしまうことがあります。

Apache 2.0はThreadStackSizeオプションをサポートしません。そのため、

- UNIXベースのApache v2.1およびそれ以降では、クライアント接続を処理し、それらの接続の処理を手助けするモジュールを呼び出すスレッドのスタック・サイズ(autodata用)を、ThreadStackSizeディレクティブを使用して設定する必要があります。

- UNIXベースのApache 2では、mpm_worker_moduleの追加およびthread.cファイルの変更の間に互換ソースを使用してスタック・オーバーフローを防止することが最適です。

次の手順は、Apache v2.0のthread.cファイルを変更して、マルチスレッド・サーバーの実装中に最適なパフォーマンスを得るためにWebgateに必要なデフォルトのpthreadスタックサイズを指定する方法を示します。Apache v2.1とThreadStackSizeディレクティブの詳細は、http://httpd.apache.org/docs/2.2/mod/mpm_common.html#threadstacksizeを参照してください。

注意:
次の手順はApache 2.0 Webgateでのみ実行されます。それ以外の場合、デフォルトのpthreadスタック・サイズではWebgateに対して十分ではなく、クラッシュしてしまうことがあります。

UNIX環境でWebgate用のApache v2.0 thread.cファイルを変更する手順

1. thread.cファイルを探します。次に例を示します。

APACHE 2.0.52 source/srclib/apr/threadproc/unix/thread.c

2. 次のコード・セグメントでapr_threadattr_createという名前の関数(apr_threadattr_t **new、apr_pool_t *pool)を探します。

**new,apr_pool_t *pool) in the following code segment:
1-----> apr_status_t stat;
2
3-----> (*new) = (apr_threadattr_t *)apr_pcalloc(pool, sizeof(apr_threadattr_t));
4-----> (*new)->attr = (pthread_attr_t *)apr_pcalloc(pool, sizeof(pthread_attr_t));
5
6-----> if ((*new) == NULL || (*new)->attr == NULL) {
7----->              return APR_ENOMEM;
8-----> }
9
10----->(*new)->pool = pool;
11----->stat = pthread_attr_init((*new)->attr);
12
13-----> if (stat == 0) {
14----->            return APR_SUCCESS;
15-----> }
16----->#ifdef PTHREAD_SETS_ERRNO
17----->stat = errno;
18----->#endif
19
20----->return stat;
21

3. 次のコードを13行目よりも前に追加します。

int stacksize = 1 << 20;
pthread_attr_setstacksize(&(*new)->attr, stacksize);

4. configure、make、make installを実行して、mpm_worker_moduleを使用するApache Webサーバーを設定します。

Domino Webサーバーの問題

認証イベントの失敗: Domino Webサーバーの場合、Oracle Access Managerを介したURLのりダイレクトは、認証タイプがBasic Over LDAPに設定され、リダイレクトされるURLが次のいずれかで示されていると、動作しないことがあります。

同じWebサーバー上に存在する相対パス

または、ホスト識別子文字列の組合せで定義されたコンピュータ名を含む、同じWebサーバー上のフルパス

認証の失敗イベントを解決するには、ホスト識別子グループの下で定義されていないコンピュータ名を使用してリダイレクトされるURLを設定する必要があります。たとえば、コンピュータのIPアドレスです。

この問題はフォームベースの認証タイプでは発生しません。

ヘッダー変数: クライアント証明書認証スキームを使用しているときに、REMOTE_USER以外のヘッダー変数を、Lotus Notes Domino WebサーバーにインストールされたWebgateに渡すことができない場合があります。

たとえば、ヘッダー変数はクライアント証明書認証を発生させるリクエストには設定できません。しかし、その他のすべてのリクエストにはヘッダー変数を設定できます。

詳細は、第31章「10g Webgate用Lotus Domino Webサーバーの構成」を参照してください。

エラー、アクセスの消失および予期しない動作

症状: Webサーバー・インスタンスの作成に使用したものと違うユーザーIDを使用してUNIXにOracle Access Managerをインストールすると、Oracle Access Managerが不安定になることがあります。次のような動作が発生する可能性があります。

- ランダムなバグ・レポート・ページ

- ログ・ファイルへの書込み失敗エラー

- Webページへのアクセスの消失

解決策: chownコマンドを使用してファイルの権限を変更します。Oracle Access Managerディレクトリを、Webサーバー・インスタンスを作成するのに使用したのと同じユーザーIDに変更します。

ISA Webサーバーの既知の問題

WebgateはISAPIの拡張を使用してユーザー拒否エラー・メッセージおよび診断ページを表示します。しかし、ISA 2006は拡張をサポートしていません。そのため、

- ユーザーがWebgateによりアクセス拒否された場合、ユーザーはOracle Access Managerのアクセス拒否エラー・メッセージではなく、ページが表示されないエラー・メッセージを受け取ります。

- 診断URL、http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1は、ISAに対しては動作しません。

LinuxThreadsでOracle HTTP Serverが開始しない

Oracle HTTP ServerにWebgateインスタンスをインストールすると、サーバーが起動しません。これは、Oracle Access Managerで古いLinuxスレッド・モデルを使用しているために発生します。

注意:
Oracle Access Managerの実行時は、デフォルトではLinuxThreadsが使用されます。これは環境変数LD_ASSUME_KERNELが2.4.19に設定されていることが必要です。NPTLをOracle Access Managerとともに使用している場合、LD_ASSUME_KERNELは2.4.19.9に設定しません。

解決策: LinuxThreadsモードを使用している場合、次の手順の説明に従い、ttpd.confファイルのPerlモジュールをコメント・アウトし、LD_ASSUME_KERNEL環境変数を更新して起動します。

LinuxThreadsモードでOracle HTTP Serverの開始の失敗を解決する手順

1. 次の場所にあるhttpd.confファイルのPerlモジュールをコメント・アウトします。
Oracle HTTP Server 11g: ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

Oracle HTTP Server v2: OH$/ohs/conf/httpd.conf

Oracle HTTP Server v1.3: OH$/Apache/Apache/conf/httpd.conf

2. LD_ASSUME_KERNELの値を更新するには、テキスト・エディタで次のファイルを開きます。

OH$/opmn/conf/opm.xml

3. 次の行を探します。

<process-type id="HTTP_Server" module-id="OHS">

4. 前の手順で見つけた行の下に次の情報を追加します。

<environment>
<variable id="LD_ASSUME_KERNEL" value="2.4.19" />
</environment>

5. このファイルを保存します。

6. 次のコマンドを実行して変更を実装します。

opmnctl stopall
opmnctl startall

Linux Red Hat 4上でOracle HTTP Server Webgateが初期化されない

この状況はOracle Access ManagerをLinuxThreadsまたはNPTLのどちらとともに使用していても発生する可能性があります。

症状: Red Hat Enterprise Serverバージョン4.0が2.6.9-34.ELよりも低いカーネル・バージョンで実行しているOracle HTTP Serverにインストールされた場合に、Webgateは初期化に失敗します。バージョン2.6.9-34.ELはRed Hatバージョン4、アップデート3とともに提供されます。

解決策: この問題を防ぐには、Red Hatバージョン4、アップデート3またはそれ以上にアップグレードする必要があります。

Oracle HTTP Server Web Server構成ファイルの問題

問題

Oracle Application Server 10.1.x、OC4Jでは、Webgateのインストール中にhttpd.confファイルが自動的に修正されるときに、破損する可能性があります。

解決策

Webgateのインストール前に、次のコマンドを実行して、httpd.confファイルが上書きされることを防ぎます。

$ORACLE_HOME/dcm/bin/dcmctl updateConfig -ct ohs

IIS v6 Webサーバーの問題

IIS 6 Webサーバーでのみ、WWWサービスをIIS 5.0分離モードで実行する必要があり、これはISAPI postgateフィルタの要件です。この例は、32ビットWindowsオペレーティング・システムで実行している32ビットのOracle Access Managerバイナリがある場合に動作します。しかし、IISが32ビット・モードで実行している64ビットWindowsマシンで32ビットpostgate.dllを実行しようとすると問題が発生します。

問題

IISがIIS5.0分離モードで実行している場合、次のメッセージが表示されます。

ISAPIフィルタ'C:\webgate\access\oblix\apps\webgate\bin\webgate.dll'は構成の問題が原因でロードできませんでした。

原因

現在の構成はAMD 64ビット・プロセッサ・アーキテクチャ用に作成されたイメージのロードのみをサポートします。データ・フィールドにはエラー番号が含まれます。

解決策

この問題の詳細は、この種類のプロセッサ・アーキテクチャの不一致のエラーのトラブルシューティング方法も含め、次のWebサイトを参照してください。

http://go.microsoft.com/fwlink/?LinkId=29349

詳細は、次のヘルプとサポート・センターを参照してください。

http://go.microsoft.com/fwlink/events.asp

問題

IIS5は64ビットとして存在することはありません。しかし、64ビットWindowsコンピュータ上でのIIS v6のIIS5互換モードだけは64ビットとして実行します。

原因

次のURLで参照できるドキュメントのとおり、64ビットWindowsでIIS5分離モード32ビットを実行することはアーキテクチャ上不可能です。

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.pu
blic.inetserver.iis&tid=5dd07102-8896-40cc-86cb-809060fa9426&cat=en_US_
02ceb021-bb43-476d-8f8f-6c00a363ccf5&lang=en&cr=US&p=1

http://blogs.msdn.com/david.wang/archive/2005/12/14/HOWTO-Diagnose-one-cause-of-W3
SVC-failing-to-start-with-Win32-Error-193-on-64bit-Windows.aspx

Sun Webサーバーの開始時のPCLOSEエラー

症状: Sun Webサーバーを開始しようとしたときに、次のようなエラーが発生します。

Unable to start, PCLOSE

解決策: たくさんの問題がこのエラーを引き起こす可能性があります。

- obj.confファイルの構文エラー

- obj.confファイルの先頭のスペース

- Webサーバー・インスタンスの作成に使用したのとは異なるユーザーIDでのOracle Access Managerのインストール

- obj.confファイルの最後にある改行

IIS DLLの削除および再インストール

Oracle Access ManagerがMicrosoftのIIS Webサーバーで実行している場合、Oracle Access Managerを再インストールするときには次のISAPIフィルタを手動でアンインストールおよび再インストールする必要があります。

- tranfilter.dll

- oblixlock.dll(Webgateがインストール済の場合)

- webgate.dll(Webgateがインストール済の場合)

IIS DLLを削除および再インストールする手順

1. Oracle Access Managerをアンインストールします。

2. 前述のDLLを手動でアンインストールします。

3. Oracle Access Manager.Active Directoryを再インストールします。

4. DLLを手動で再インストールします。

注意:
これらのフィルタは使用しているIISのバージョンにより異なる可能性があります。これらのフィルタが存在しないまたは別のものが存在する場合、存在するフィルタを削除する必要があるかどうかはOracleにお問い合せください。

Windowsネイティブ認証

問題

Windowsネイティブ認証の設定後、およびWNA保護ページにアクセスすると、ブラウザはユーザー名またはパスワード(およびその両方)が正しくないことを示すエラーを受け取ることがあります。

原因

Oracle Access Managerが使用するアイデンティティ・ストアがWindows Active Directoryを指していない可能性があります。デフォルトでは、アイデンティティ・ストアは組込みLDAPです。

解決策

1. Oracle Access Managerコンソールで、アイデンティティ・ストアの構成、「システム構成」、「データソース」、「ユーザー・アイデンティティ・ストア」を確認します。

2. LDAPストア設定がActive Directoryを指していることを確認します。

索引

A  B  C  D  E  F  G  H  I  L  M  N  O  P  R  S  T  U  V  W  X

記号

「IIS 7 Webサーバーでcert_authn.dllを有効化する手順」, 29.6.3

A

AAタイムアウトしきい値フィールド, 9.3.1

情報

ディレクトリ・サーバーのホストの変更, G.2

Oracle Enterprise Manager Fusion Middleware Control, 26.2

WebGateインストール, 27.2.3

Access Manager SDK

アクセス・ゲート構成パラメータへの影響, 9.3.1, 10.2.5.5

アクセス・サーバー

キャッシュ, 9.4.2

ロギング, 23.1

ディレクトリとの間のポーリング, 9.4.3

WebGateとの間のポーリング, 9.4.3

アクセス・システム

トランスポート・セキュリティ, 27.4.4

アクセス・ゲート

キャッシュ, 9.3.1

ロギング, 23.1

ユーザー定義パラメータ, 9.3.2

「AccessGateパスワード」フィールド, 9.3.1 アクション

認証の成功または失敗, 13.10.3

AddDefaultCharsetディレクティブ, 28.5 管理

ページ, D.1.1

管理者

言語, D.1.1, D.1.1

管理者言語

削除, 27.8

Apache, 27.4.1

Apache WebGateと特定リソースの関連付け, 12.4.2.3

Apache v2

アーキテクチャ, 28.4

ディレクティブ, 28.12

HTTPサーバー, 28.3.1

制限, 28.4

Portable Runtimeライブラリ, 28.4

APACHE_WebGate, 28.3 APACHESSL_WebGate, 28.3 app.context, C.2.2 アプリケーション・ドメイン

アプリケーション・ドメイン内のシングル・サインオン, 11.3.7

認証, 11.7.2

複数セッションにわたる保持, 12.6.3

認証スキーム

キャッシュ, 9.3.1, 10.2.5.5

時間ベース, 12.6.3

認可, 11.7.2

シングル・サインオンCookie, 使用, 11.5.3.2

自動ログイン, C.1.1 autologin.url, C.2.2

B

Basic認証方式, H.8

C

キャッシュ

アクセス・サーバー, 9.4.2

アクセス・ゲート, 9.3.1

デフォルトのタイムアウト, 9.4.2

InactiveReconfigPeriods, 9.3.2

ObSSOCookie, 6.2.4

「キャッシュ・タイムアウト」フィールド, 9.3.1 CachePragmaHeaderフィールド, 10.2.5.5, 10.2.5.5, 10.2.5.5, 10.2.5.5 証明書モード, 9.3.1, 10.2.5.5, 14.5.1.1 cert_authn.dll, 29.5.2 証明書

アイデンティティ・サーバー, 27.4.5

パスワード変更ページ

動作, H.1.1

エラー・メッセージ, H.3.3, H.3.4

インストール, H.6.1

パラメータ, H.2.3

client_request_retry_attempts, 10.2.5.5 完了

WebGateのインストール

Domino, 31.6.1

IISによるWebGateのインストール, 29.5 ISAサーバーによるWebGateのインストール, 30.4, 30.5 構成データ

削除, 27.8

確認

WebGateインストール, 27.4.10

コンソール・メソッド

WebGate, 27.4.3

Cookie

暗号化セッション・トークン, 11.5.3.2

複数セッションにわたる存続, 12.6.1

プライマリCookieドメイン, 9.3.1, 9.3.1, 10.2.5.5

資格証明の送信, 11.6.1

作成

WebGateインスタンス, 27.4.2

CredentialMapping権限, C.2.2

D

default.auth.level, C.2.2

デプロイメント

インベントリ, B.4.3

デプロイメント・タイプ, 1.1.2.1 デプロイメント固有ページ

例, H.7

グローバリゼーション・サポート, H.4

ガイドライン, H.5, H.5

OracleAS Wirelessに対するサポート, H.6.2

診断

ログ・ファイルでの収集, 23.7.1

ディレクトリ・サーバー・ホスト, G.2 Domino, 27.4.1

Webサーバー, I.31.6

DSAPIフィルタ, 31.6, 31.6.1 動的認証, C.1.1

E

エンド・ユーザー言語, D.1.1

エンド・ユーザー言語, D.1.1

評価

移行前後の変更, B.4.5

既存のOSSO, 27 外部アプリケーション

ログイン・ページ, H.6.3

外部アプリケーション

追加, H.8

認証方式

Basic, H.8

GET, H.8

POST, H.8

F

「フェイルオーバーしきい値」フィールド, 9.3.1

終了

WebGateインストール, 27.4.8

パスワード変更の強制機能, H.1.1.4

G

GET認証方式, H.8

グローバル・ログアウト, C.1.1

グローバリゼーション, 10.2.5.5

グローバリゼーション・サポート

デプロイメント固有ページ, H.4

猶予ログイン, H.1.1.3 GUIメソッド, 27.4.3

WebGate, 27.4.3

H

ヘッダー変数

シングル・サインオン, 11.6.1

情報の受渡し, 2.5.3, 11.7.2, 13.8.1

ProxySSLStateHeader, 9.3.2, 10.2.5.5, G.3

資格証明の設定, 11.6.1

リバース・プロキシの背後のWebGate, 9.3.2, 10.2.5.5, G.3

ホスト識別子

追加, 12.4.4

削除, 12.4.7

変更, 12.4.6

表示, 12.4.5

対DenyOnNotProtected, 9.3.1

ホスト

識別子の構成, 12.4.1.3

I

I18N, D.1

IBM HTTPサーバー, 28.3.2

IHSも参照, 28.3

アイデンティティ・サーバー

証明書のインストール, 27.4.5

ロギング, 23.1

証明書のリクエスト, 27.4.5

IHS, 28.5.1

制限, 28.4

Webサーバー, 28.3.3

IHS v2 Webサーバー, 27.4.1 IIS, 27.4.1

WebGateによるSSL, 29.5.1

WebGate, 27.4.7, 27.4.8, 27.4.10

IIS仮想Webサーバー, 27.4.1, 29.2.1 IIS Webサーバー

ISAPIも参照, 29.2

InactiveReconfigPeriod, 9.4.2 インストール

Domino Security(DSAPI)フィルタ, 31.6

アイデンティティ・サーバー証明書, 27.4.5

WebGate, 27, 27.4

統合Windows認証, 10.2.5.5 インベントリ

デプロイメント, B.4.3

各デプロイメントの詳細, B.4.3

IPアドレスの検証, 9.3.3 ISAプロキシ・サーバー, 27.4.1 ISAサーバー, 30, 30.2 ISAPI, 29.2, 30.2 ISAPI Webgateフィルタ, 29.5.3.4.2 IWA, 10.2.5.5

L

言語パック

削除, 27.8

言語パック, D.1.1 言語タグ, D.1.1 ロケール, D.1 ローカライズ・メッセージ, D.1.1 ロギング

ログ・レベル, 23.4.4

ロギング

概要, 23.1

ログ・ハンドラのアクティブ化, 23.4.4

Buffer_Size, 23.6

構成ファイル, 23.2

変更, 23.2.2

要素の順序, 23.4.7

エントリの評価順序, 23.5.1

構造, 23.4

構成ファイルの構造, 23.4, 23.4 デフォルトの構成ファイル, 23.2.2.2, 23.2.2.2 デフォルトのログ構成ファイル, 23.6.1 ログのデフォルト設定, 23.6.1 ログ出力の送信, 23.4.4 File_Name, 23.6 FileLogWriter, 23.3 グローバル・レベルしきい値, 23.4.3 レベル, 23.5 ListName, 23.6 ログ構成ファイルのパス, 23.2.1 ログ・ファイル・バッファ・サイズ, 23.4.4 ログ・ファイル名, 23.4.4 ログ・ファイル・ローテーション, 23.4.4 ログレベル, 概要, 23.1 ログ・レベル, 各モジュールへのレベルの設定, 23.7 ログ・レベルの表, 23.1.1 ログ出力先, 23.3 ログ・ライター, 23.4.4 ログ・ライター, 23.3 Log_Level, 23.6 Log_Status, 23.5, 23.6 Log_Threshold_Level, 23.5 Log_Writer, 23.6 Max_Rotation_Size, 23.6 Max_Rotation_Time, 23.6 MODULE_CONFIGセクション, 23.7.1 ログ・ファイル内のモジュール, 23.7.1.2 MPFileLogWriter, 23.3 構成ファイル内の要素の順序, 23.4.7 出力, 送信先, 23.3 モジュール固有しきい値, 23.7 モジュール固有しきい値, 構成, 23.7.2 複数の宛先へのログ・データの送信, 23.3 SysLogWriter, 23.3 SolarisおよびLinuxのシステム・ログ, 23.6.1 Windowsのシステム・ログ, 23.6.1 しきい値, 23.7.1 サーバーの再起動が必要な場合, 23.2.2.1 ログ・データの送信先, 23.3 xmlns, 23.6 ログイン・ページ

エラー・メッセージ, H.3.1, H.3.1, H.3.2

インストール, H.6.1

パラメータ, H.2.1, H.2.1

パスワードのリセット機能, H.2.2

ログイン・ページ

外部アプリケーション用, H.6.3

login.url.FORM, C.2.2 ログアウト

強制, 9.3.1

logout.url, C.2.2 Lotus Notes, 31.6.1, I.31.6

M

手動構成

WebGate Webサーバー, 27.3, 27.4.7.1

MaxClients, 28.12 「最大接続数」フィールド, 9.3.1 キャッシュ内の最大要素数フィールド, 9.3.1 最大セッション時間フィールド, 9.3.1 MaxSpareServers, 28.12 MaxSpareThreads, 28.12 Microsoft Passport, 10.2.5.5 MinSpareServers, 28.12 MinSpareThreads, 28.12 mod_ssl, 28.5.3 MODULE_CONFIGセクション, 23.7.1 MPM, 28.4, 28.12 mpm_winnt, 28.4, 28.12 mpm_worker_module, 28.4, 28.4, 28.6.5, I.31.5 複数インスタンス

削除, 27.8

マルチプロセス・モジュール

mpmも参照, 28.4

N

名前の変更, はじめに

名前, 新規, はじめに, はじめに

net start w3svc, 29.5.3.4.2

net stop iisadmin, 29.5.3.4.2

ネットワーク・トラフィック, 9.4.2

アクセス・システム用, 9.4.2

削減, 9.4.2

O

OAMソリューション, 15.6, C.1.1

oamAuthnProvider.jar, 27.6.5.1

oblixlock.dll, 29.5.2

ObSSOCookie, 9.3.1, 9.3.1, 9.3.1, 9.3.1, 9.3.3

キャッシュ, 6.2.4

複数セッションにわたる保持, 12.6.3

OHS2, 10.2.5.5 オープン・モード, 9.3.1, 10.2.5.5, 14.5.1.1 OPSS SSOフレームワーク, 2.9.3, 2.9.3, C.1.1, C.1.1 Oracle Access Manager

保護, 12.5.1.1, 12.5.1.1, 12.5.1.1

非保護, 12.5.1.1

Oracle HTTP Server

OHSも参照, 28.3

Oracle HTTP Server (OHS), I.31.9 Oracle HTTP Server 2, 10.2.5.5 Oracle Platform Security Services, 11.7.1.3, 15.2.5 OracleAS Single Sign-On

外部アプリケーション, H.8

グローバリゼーション・サポート, H.4

OSSO

既存の実装, 27

P

パスワード

変更, H.1.1.2

パスワード変更の強制機能, H.1.1.4

リセット, H.1.1.1, H.2.2

PDFファイル, 9.3.1, 10.2.5.5 Peoxwsuew

Somino

UnixにDomino Webサーバーをインストールする手順, 31.2

パフォーマンス, 9.3.1 計画

成果物, B.4

各デプロイメントの詳細, B.4.3

インベントリ, B.4.3

プラグイン

ロギング, 23.1

ポリシー・ドメイン

ルート, 13.5.1.3

DIT内の最も上にあるURL接頭辞, 13.5.1.3

ポリシー・マネージャ

クロック, I.28

ロギング, 23.1

ポリシー・ドメイン・ルート, 13.5.1.3

POST認証方式, H.8 postgateフィルタ, 29.5.3.4.2 postgate.dll, 29.5.3.4.2

ISAサーバー, 30.2

優先ホスト

対DenyOnNotProtected, 9.3.1

優先HTTPホスト・フィールド, 9.3.1 prefork MPM, 28.4 プライマリCookieドメイン・フィールド, 9.3.1 手順

アクセス・ゲートおよびWebGate

構成ポーリング頻度を変更する手順, 9.4.3

認証

認証スキームに永続Cookieを定義する手順, 12.6.3

Domino

キーリング・ファイルとスタッシュ・ファイルを生成する手順, 31.5

最初のDominoサーバーを設定する手順, 31.3

Dominoサーバーを起動する手順, 31.4

IPv6

認証およびリソースWebGate用に別個のプロキシを使用するIPv6を構成する手順, G.3

ロギング

モジュール固有しきい値を構成する手順, 23.7.2

OHS

OHSの起動の失敗を解決する手順, I.31.9

シングル・サインオン

ObSSOCookieを保護する手順, 12.6.2

Windowsのチャレンジ/レスポンス認証を無効にする手順, I.14 アンインストール

Oracle Access Managerのコンポーネントをアンインストールする手順, 27.8

Webサーバー

IIS DLLを削除および再インストールする手順, I.16.5, I.31.14

WebGate

ISAPIフィルタとしてcert_authn.dllを追加する手順, 29.5.1

IIS v7に対するISAPIフィルタとしてcert_authn.dllを追加する手順, 29.6.3

複数のWebGateによるISAPIフィルタとしてcert_authn.dllを追加する手順, 29.7.3

ISAサーバーのアクセス・サブディレクトリに対する権限を変更する手順, 30.4.2

IIS 7 Webサーバーでcert_authn.dllを有効化する手順, 29.6.3

IISに対するSSLを有効化する手順, 29.5.1

複数のWebGateによるIISに対するSSLを有効化する手順, 29.7.3

インストールを終了する手順, 27.4.8

ポストゲートISAPIフィルタをインストールする手順, 29.5.3.4.2

Webサーバーを手動で構成する手順, 27.4.7.1

Webサーバー構成の手動更新手順, 27.4.7

ISAPIフィルタの順序付け手順, 29.5.2

ISAサーバー用ISAPIフィルタの順序付け手順, 30.5.3

Webサイト(デフォルト・サイトではない)の保護の手順, 29.5.4

構成詳細の指定手順, 27.4.6

Oracle Access ManagerプラグインをISAサーバーWebフィルタとして登録する手順, 30.5.1

IIS 6でIIS 5.0分離を設定する手順, 29.5.3.4.1

トランスポート・セキュリティ・モードの指定手順, 27.4.4

インストールを開始する手順, 27.4.3

ISAサーバー上でWebGateをアンインスト－ルする前にフィルタの登録を解除する手順, 30.7

Webサーバー構成の更新手順, 27.4.7

WebGate 64ビット

IISおよびクライアント証明書認証に対してSSLを有効化する手順, 29.8.2

手順の概要

URLパターンの使用方法, 13.5.1.4

WebGateによるアクセス・サーバー構成のポーリング, 9.4.2

ユーザーがアクセスをリクエストする場合, 11.7.2, 11.7.3

props.auth.level, C.2.2 props.auth.uri, C.2.2 props.auth.url, C.2.2 保護

デフォルト・サイトが設定されていない場合, 29.5.4

proxy_module, 28.3.3 公開鍵, 8.5.1

R

削除

Apache v2 Webサーバー構成, 28.13

構成データ, 27.8

IHS v2 Webサーバー構成, 28.13

IIS Webサーバー構成, 29.11

言語パック, 27.8

複数インスタンス, 27.8

OHS v2 Webサーバー構成, 28.13

Webサーバー構成, 27.8

Webサーバー構成変更, 27.8

レポート・ファイル, 9.3.1, 10.2.5.5 リクエスト証明書

アイデンティティ・サーバー, 27.4.5

リソース

J2EE, 13.5.1

ポリシー・ドメイン・ルート, 13.5.1.3

リソース・タイプ

Cプログラム, 13.5.1

C++プログラム, 13.5.1

CRMアプリケーション, 13.5.1

ディレクトリ, 13.5.1

Enterprise JavaBeans(EJB), 13.5.1

ERPアプリケーション, 13.5.1

Javaプログラム, 13.5.1

JavaServer Pages(JSP), 13.5.1

問合せ文字列, 13.5.1

Webアプリケーション, 13.5.1

Webページ, 13.5.1

再起動

ISAサーバー, 30.6

リバース・プロキシ, 28.3.3

S

「セキュリティ」フィールド, 9.3.1, 9.3.1

セキュリティ・ポリシー, 11.7.2

Security-Enhanced Linux (SELinux), 27.4.8, 28.12, 28.12, 28.12, I.24, I.31.4

共有シークレット

読取りの頻度, 9.3.2

サインオフ・ページ

インストール, H.6.1

簡易モード, 9.3.1, 10.2.5.5, 14.5.1.1 シングル・サインオフ・ページ

インストール, H.6.1

パラメータ, H.2.4, H.2.4, H.2.5

シングル・サインオン

定義, 2.5.1, 11.3.3.1

IPアドレスに関する問題, 9.3.3

ObSSOCookie, 6.2.4

ObSSOCookie, 保護, 12.6.1

ソフトウェア開発キット, 9.2.1 指定

WebGate構成詳細, 27.4.6

WebGateトランスポート・セキュリティ・モード, 27.4.4

SSO

既存の10g SSO, 27

SSOログアウトURL, 9.3.1, 9.3.1, 9.3.1, 10.2.5.5, 10.2.5.5, 15.3.1, 15.3.1, 15.3.1 SSOサービス, C.1.1 SSOサービス構成, C.2.1 sso.provider.class, C.2.2 開始

ISAサーバー, 30.6

「状態」フィールド, 9.3.1 停止

ISAサーバー, 30.6

Sun Webサーバー

WebGate, 27.4.7

T

タスク概要

インスタンスの追加およびWebGateのインストール, 27.2.2, 27.2.3

IIS WebGateのインストール, 29.5

シングル・ドメイン・シングル・サインオンの有効化, 11.4

ISAサーバー上でのISAPI WebGateのインストールおよび構成, 30.2

ISAサーバー用ISAPI WebGateのインストール, 30.4.1

WebGateのインストール手順, 27.4, 27.6.2

ISAサーバー用WebGate構成の実行, 30.4, 30.5

テスト

デプロイメント, B.4.5

移行前後の変更の評価, B.4.5

ThreadsPerChild, 28.12 タイムアウト

WebGateとアクセス・ゲートの接続, 10.2.5.5

token.provider.class, C.2.2 トラフィック, ネットワーク, 9.4.2 翻訳可能な情報, D.1.1 トランスポート・セキュリティ

アクセス・システム, 27.4.4

オプション, 9.3.1, 9.3.1, 10.2.5.5

トラブルシューティング

Apache上のアクセス・サーバーのクラッシュ, I.31.1

ログ・ファイルへの書込み失敗エラー, I.31.7

アクセスの消失, I.31.7

Webページへのアクセスの消失, I.31.7

Sun WebサーバーのPCLOSEエラー, I.31.13

ランダムなバグ・レポート・ページ, I.31.7

IIS DLLの再インストール, I.16.5, I.31.14

Webサーバーの問題, I.31

U

Unicode規格

4.0, D.1

アンインストーラ, 27.8 更新

WebGate Webサーバー構成, 27.4.7

URL

ObSSOCookieを含む, 11.5.3.2

キャッシュでの最大数, 9.3.1, 9.3.1, 9.3.1, 9.3.2, 9.3.2, 10.2.5.5

Oracle Access Manager URL, 非保護, 12.5.1.1

ポリシー・ドメイン・ルートURL, 13.5.1.3

接頭辞, 13.5.1.3

Oracle Access ManagerのURLの保護, 12.5.1.1, 12.5.1.1, 12.5.1.1

SSOログアウトURL, 9.3.1, 9.3.1, 9.3.1, 10.2.5.5, 10.2.5.5, 15.3.1, 15.3.1, 15.3.1

httpsとして格納, 9.3.2, 10.2.5.5

URLInUTF8Format, 10.2.5.5 ユーザー定義パラメータ

client_request_retry_attempts, 10.2.5.5

URLInUTF8Format, 10.2.5.5

UTF-8, 10.2.5.5

V

仮想Webホスティング, 12.4.2

W

Webサーバー

構成変更

削除, 27.8

Webサーバー

構成変更

削除, 27.8

IHS, 28.3.3 Webサーバー・ホスト

識別子の構成, 12.4.1.3

WebGate, 11.7.2, 11.7.3, 27.4.3

アクセス・サーバー・タイムアウトしきい値, 9.3.1

特定の仮想ホスト、ディレクトリまたはファイルとの関連付け, 12.4.2.3

CacheControlHeader, 9.3.1, 10.2.5.5

CachePragmaHeader, 9.3.1, 10.2.5.5

クロック, I.28

構成詳細, 27.4.6

構成のポーリング, 9.4.2

コンソール・メソッド, 27.4.3

インスタンスの作成, 27.4.2

IISに対するSSLの有効化, 29.5.1

ID, 27.4.6

IIS, 27.4.7, 27.4.8, 27.4.10

インストール, 27.4

IPアドレスの検証, 9.3.3

ロギング, 23.1

パスワード, 27.4.6

ポーリング頻度, 9.4.3

ポーリング頻度, 変更, 9.4.3

Sun Webサーバー, 27.4.7

webgate.dll, 29.5.2, 29.5.3.4.2, 30.5.3

ISAサーバー, 30.2

Webパス

ロギング, 23.1

worker MPM, 28.4

X

xlC.rte 6.0ランタイム・ライブラリ, 28.3.2

Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved.