Oracle® Fusion Middleware Oracle Access Management管理者ガイド

11gリリース2 (11.1.2)

B69533-02(原本部品番号:E27239-03)

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドの最新情報

- 2012年11月改訂

- 2012年8月改訂

- Oracle Access Management 11.1.2.0.0での製品の拡張機能

- 11.1.2で変更された製品およびコンポーネントの名前

Oracle Access Managementの概要

1 Oracle Access Managementの概要

- 1.1 Oracle Access Managementの概要

- 1.1.1 Oracle Access Managementのインストールについて

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

- 1.2 Oracle Access Management Access Managerの概要

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

- 1.2.2 Access Managerのデプロイメント・タイプの概要

- 1.3 Oracle Access Management Access Manager 11.1.2の概要

- 1.3.1 Access Manager 11.1.2について

- 1.3.2 Access Manager 11gで使用できない機能について

- 1.4 Oracle Access Management Security Token Serviceの概要

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

- 1.4.2 Security Token Serviceについて

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

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

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

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

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

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

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

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

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

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

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

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

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

- 1.5 システム要件と動作保証情報

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

2 Oracle Access Management管理およびナビゲーション・スタート・ガイド

- 2.1 前提条件

- 2.2 デプロイメントでのサーバーの起動と停止

- 2.2.1 ノード・マネージャの開始

- 2.2.2 AdminServerの起動と停止

- 2.2.3 OAMサーバーの起動と停止

- 2.3 Oracle Access Management管理者の概要

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

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

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

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

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

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

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

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

- 2.5.2 ページの要素

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

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

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

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

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

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

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

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

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

3 共通サービスおよび証明書の検証の管理

- 3.1 前提条件

- 3.2 共通構成要素の概要

- 3.3 使用可能なサービスの有効化および無効化

- 3.4 共通設定の管理

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

- 3.4.2 共通設定の管理

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

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

- 3.5.1 証明書検証および失効について

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

- 3.5.3 証明書検証の有効化

- 3.5.4 CRL配布ポイント拡張の構成(CDP)

4 データソースの管理

- 4.1 前提条件

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

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

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

- 4.2.2 ポリシー、パスワード管理およびセッションのデータベース・ストアについて

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

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

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

- 4.2.5.1 Security Token ServiceのOracle WSMエージェント・キーストアについて

- 4.2.6 Identity Federationキーストア

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

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

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

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

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

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

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

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

- 4.5 管理者ロールの管理

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

- 4.5.2 管理者ロールの管理

- 4.6 ポリシーおよびセッション・データベースの管理

- 4.6.1 データベースのデプロイメントについて

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

5 サーバー登録の管理

- 5.1 前提条件

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

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

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

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

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

- 5.2.5 構成変更後のサーバーの再起動について

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

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

- 5.3.1.1 「OAMプロキシ」ページ

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

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

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

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

第III部 共通のロギング、監査、パフォーマンス・モニタリング、およびチューニング

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

- 6.1 前提条件

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

- 6.2.1 コンポーネント・ログ出力について

- 6.2.2 サンプルのログ出力およびログ・ハンドラの定義

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

- 6.3 Access Managerのロギング構成

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

- 6.3.2 Access Manager固有のログ出力とログ・ハンドラの追加

- 6.4 セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成

- 6.4.1 セキュリティ・トークン・サービスまたはIdentity Federationのロギングの構成

- 6.4.2 セキュリティ・トークン・サービスまたはIdentity Federationのログ・レベルおよびログ詳細の定義

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

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

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

- 7.1.1 ログ・レベルについて

- 7.1.2 ログ出力について

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

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

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

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

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

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

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

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

- 7.4.2 最初の複合リスト

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

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

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

- 7.4.6 フィルタ・リスト

- 7.4.7 XML要素の順序について

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

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

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

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

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

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

- 7.7.1 MODULE_CONFIGセクションについて

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

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

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

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

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

- 8.1 前提条件

- 8.2 監査の概要

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

- 8.2.2 監査記録の保存について

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

- 8.2.4 監査ログとデータについて

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

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

- 8.3.2 監査可能なAccess Managerランタイム・イベント

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

- 8.4 監査可能なIdentity Federationイベント

- 8.4.1 Identity Federationのセッション管理イベント

- 8.4.2 Identity Federationのプロトコル・フロー・イベント

- 8.4.3 Identity Federationのサーバー構成イベント

- 8.4.4 Identity Federationのセキュリティ・イベント

- 8.5 監査可能なセキュリティ・トークン・サービス・イベント

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

- 8.5.2 監査可能なセキュリティ・トークン・サービス管理イベント

- 8.5.3 監査可能なセキュリティ・トークン・サービス・ランタイム・イベント

- 8.6 Oracle Access Managementの監査の設定

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

- 8.6.2 Oracle Business Intelligence Publisher EEの準備

- 8.6.3 Oracle Access Managementコンソールを使用した監査構成について

- 8.6.4 監査設定の追加、表示、または編集

- 8.7 監査とレポートの検証

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

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

- 9.2 DMSメトリック表の確認

- 9.3 Oracle Access Managementコンソールを使用したサーバー・メトリックの監視

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

- 9.3.2 Oracle Access Managementコンソールを使用したサーバー・メトリックの確認

- 9.4 Oracle Access Managementコンソールを使用したSSOエージェント・メトリックの監視

- 9.4.1 Oracle Access Managementコンソールを使用したエージェント・メトリックの監視

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

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

- 9.5 OAMプロキシ・メトリックとチューニングの概要

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

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

- 9.6 DMSコンソールによるOpenSSOメトリックの確認

- 9.6.1 OpenSSOプロキシ・イベントとメトリック: サーバー

- 9.6.2 OpenSSOプロキシ・メトリック: エージェント

- 9.6.3 DMSコンソールを使用したOpenSSOメトリックの確認

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

- 10.1 前提条件

- 10.2 Fusion Middleware Controlの概要

- 10.3 Fusion Middleware Controlのログインおよびログアウト

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

- 10.3.2 Fusion Middleware Controlへのログイン

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

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

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

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

- 10.4.3 Fusion Middleware Controlのコンテキスト・メニューおよびターゲット詳細の表示

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 10.9 Fusion Middleware ControlでのMBeanの表示

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

- 10.9.2 MBeanの管理

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

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

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

第IV部 Access Managerの設定とエージェントの管理

11 Access Managerの設定の構成

- 11.1 前提条件

- 11.2 「Access Managerの設定」の概要

- 11.3 ロード・バランシングの管理

- 11.3.1 共通のロード・バランシング設定について

- 11.3.2 OAMサーバーのロード・バランシングの管理

- 11.4 セキュア・エラー・モードの管理

- 11.4.1 OAMサーバー・エラー･モードについて

- 11.4.2 OAMサーバーのセキュア・エラー・モードの管理

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

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

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

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

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

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

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

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

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

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

12 エージェントおよび登録の概要

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

- 12.1.1 エージェント・タイプおよびランタイム処理について

- 12.1.2 外部資格証明コレクタとして構成された11g Webgateについて

- 12.1.3 Mobile and Social用の11g Webgate機能について

- 12.1.4 事前登録済の10g Webgate IAMSuiteAgentについて

- 12.2 エージェント登録の概要

- 12.2.1 エージェントの登録、キーおよびポリシーについて

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

- 12.3 リモート登録の概要

- 12.3.1 帯域内リモート登録の実行について

- 12.3.2 帯域外リモート登録の実行について

- 12.3.3 更新されたエージェント構成ファイルについて

13 OAM 11gエージェントの登録および管理

- 13.1 前提条件

- 13.2 コンソール内のOAMエージェント登録パラメータの理解

- 13.2.1 OAM Webゲートの作成ページとパラメータについて

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

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

- 13.3 コンソールを使用したOAMエージェントの登録

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

- 13.4.1 コンソール内の登録済OAMエージェント構成パラメータの理解

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

- 13.4.3 コンソール内のOAMエージェント登録ページの表示または編集

- 13.4.4 コンソールを使用したOAMエージェント登録の削除

- 13.5 リモート登録ツール、モードおよびプロセスの理解

- 13.5.1 リモート登録コマンドの引数とモードについて

- 13.5.2 リモート登録リクエスト・テンプレート内の共通要素

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

- 13.6 リモート登録テンプレートの理解: OAMエージェント

- 13.6.1 OAMエージェントのリモート登録用パラメータ

- 13.7 OAMエージェントのリモート登録の実行

- 13.7.1 リモート登録ツールの取得および設定

- 13.7.2 リモート登録リクエストの作成

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

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

- 13.8 エージェントのリモート更新の概要

- 13.8.1 リモート・エージェント更新のモードについて

- 13.8.2 リモート 11g OAMエージェント更新のテンプレートについて

- 13.9 エージェントのリモート更新

- 13.9.1 エージェントのリモート更新

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

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

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

- 13.10.1 リモート登録の検証

- 13.10.1.1 Oracle Access Managementコンソールを使用したエージェント登録の検証

- 13.10.1.2 リモート登録後の認証およびアクセスの検証

14 セッションの管理

- 14.1 前提条件

- 14.2 セッションおよびセッション管理の概要

- 14.2.1 Access Managerセッション・セキュリティ

- 14.2.1.1 セキュアHTTPSプロトコル

- 14.2.1.2 Oracle Coherence

- 14.2.1.3 データベースの永続性

- 14.2.2 セッションのライフサイクルについて

- 14.2.3 複数のエージェント・タイプ(OSSOエージェントおよびOAMエージェント)のタイムアウトについて

- 14.2.4 OpenSSOエージェントについて

- 14.2.5 Oracle Coherenceとセッション管理について

- 14.3 セッションのライフサイクル設定の構成

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

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

- 14.4 アクティブ・セッションの管理

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

- 14.4.2 アクティブ・セッションの管理

- 14.5 セッション操作の検証

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

15 Access Managerを使用したシングル・サインオンの概要

- 15.1 Access Managerのシングル・サインオンの概要

- 15.1.1 複数のネットワーク・ドメインのSSO

- 15.1.2 アプリケーションのSSOとAccess Managerについて

- 15.1.3 複数のWebLogic ServerドメインのSSOについて

- 15.1.4 リバース・プロキシのSSOについて

- 15.2 Access Managerのポリシー・モデルの理解

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

- 15.3.1 ポリシーに対するリソース定義について

- 15.3.2 認証ポリシーについて

- 15.3.3 認可ポリシーについて

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

- 15.4 ポリシーの条件およびルールの概要

- 15.5 Access Manager資格証明コレクションおよびログインの概要

- 15.5.1 Access Manager資格証明コレクションについて

- 15.5.2 OAMエージェントとECCを使用するSSOログイン処理について

- 15.5.3 OAMエージェントとDCCを使用するログイン処理について

- 15.5.4 OSSOエージェント(mod_osso)とECCを使用するSSOログイン処理について

- 15.6 SSO Cookieの理解

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

- 15.6.2 シングル・サインオン・サーバーおよびエージェントCookieについて

- 15.6.2.1OAM_ID Cookie

- 15.6.2.2 11g OAM WebgateのOAMAuthnCookie

- 15.6.2.3 10g WebgateのObSSOCookie

- 15.6.2.4 OAM_REQのCookie

- 15.6.2.5 DCCCtxCookie

- 15.6.2.6 mod_osso Cookie

- 15.6.2.7 OpenSSO Cookie (iPlanetDirectoryPro)

- 15.7 シングル・サインオンの構成タスクの概要

16 認証コンポーネントと共有ポリシー・コンポーネントの管理

- 16.1 前提条件

- 16.2 認証コンポーネントと共有ポリシー・コンポーネントの管理の概要

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

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

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

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

- 16.3.4 カスタム・リソース・タイプの作成

- 16.4 ホスト識別子の管理

- 16.4.1 ホスト識別子について

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

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

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

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

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

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

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

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

- 16.4.4 ホスト識別子の作成

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

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

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

- 16.5 認証方式と資格証明コレクタの理解

- 16.5.1 複数の認証方式について

- 16.5.2 埋込み資格証明コレクタと外部資格証明コレクタの比較

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

- 16.6 ネイティブ認証モジュールの管理

- 16.6.1 ネイティブのAccess Manager認証モジュールについて

- 16.6.1.1 ネイティブのKerberos認証モジュール

- 16.6.1.2 ネイティブのLDAP認証モジュール

- 16.6.1.3 ネイティブのX509認証モジュール

- 16.6.2 ネイティブ認証モジュールの表示または編集

- 16.6.3 ネイティブ認証モジュールの削除

- 16.7 プラグイン・ベースのモジュールによるマルチステップ認証の編成

- 16.7.1 単純フォーム認証とマルチファクタ(マルチステップ)認証の比較

- 16.7.2 プラグインとマルチステップ認証モジュールの作成について

- 16.7.3 マルチステップ認証のプラグイン・ベースのモジュールについて

- 16.7.4 SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合

- 16.7.5 プラグイン・ベースのマルチステップ認証モジュールの作成と編成

- 16.8 個別の認証用プラグインのデプロイおよび管理

- 16.8.1 独自の認証プラグインの管理について

- 16.8.2 カスタム・プラグインを使用可能にする手順

- 16.8.3 認証プラグインのアクティブ化ステータスのチェック

- 16.8.4 カスタム認証プラグインの削除

- 16.9 認証スキームの管理

- 16.9.1 認証スキームおよびページについて

- 16.9.1.1 事前構成された認証スキーム

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

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

- 16.9.2 マルチレベル認証およびステップアップ認証の理解

- 16.9.2.1 マルチレベル認証およびステップアップ認証について

- 16.9.2.2 OAMエージェントによる不十分な認証レベルの検出

- 16.9.2.3 10g OSSOエージェントを使用したマルチレベル認証の処理

- 16.9.3 認証スキームの作成

- 16.9.4 認証スキームの検索

- 16.9.5 認証スキームの表示、編集または削除

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

- 16.10.1 暗号化Cookieのためのチャレンジ・パラメータ

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

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

- 16.11 パスワード・ポリシーの理解

- 16.11.1 あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

- 16.11.2 Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

- 16.11.3 資格証明コレクタとパスワード・ポリシーの検証について

- 16.12 グローバル・パスワード・ポリシーの管理

- 16.12.1 グローバル・パスワード・ポリシーの定義

- 16.12.2 パスワード・ポリシー用のデフォルト・ストアの指定

- 16.12.3 デフォルト・ストアへのキー・パスワード属性の追加

- 16.12.3.1 デフォルト・ストア・スキーマの拡張について

- 16.12.3.2 パスワード・ポリシー属性によるデフォルト・ストア・スキーマの拡張

- 16.12.4 パスワードの変更後ユーザー属性を変更するために管理者を追加

- 16.13 パスワード・ポリシー認証の構成

- 16.13.1 パスワード・ポリシー検証認証モジュールの構成

- 16.13.2 PasswordPolicyValidationSchemeの構成

- 16.13.3 ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加

- 16.14 DCC対応の11g Webgateと認証ポリシーの構成

- 16.14.1 DCCの資格証明操作の有効化

- 16.14.2 パスワード・ポリシーのDCCフォームの検索と更新

- 16.14.3 DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加

- 16.15 パスワード・ポリシー構成の完了

- 16.15.1 パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

- 16.15.2 ネイティブLDAPパスワード・ポリシー検証のオーバーライド

- 16.15.3 ECC操作の無効化とDCCの単独使用

- 16.15.4 マルチステップ認証のテスト

17 リソースの保護およびSSOの有効化ポリシーの管理

- 17.1 前提条件

- 17.2 アプリケーション・ドメインおよびポリシーの作成の概要

- 17.2.1 アプリケーション・ドメインおよびポリシーの自動生成について

- 17.2.2 手動によるアプリケーション・ドメインおよびポリシーの作成について

- 17.2.3 ポリシーのリモート作成および更新について

- 17.2.4 アプリケーション・ドメインおよびポリシーの作成または管理について

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

- 17.3.1 アプリケーション・ドメインのページおよびナビゲーションについて

- 17.3.2 アプリケーション・ドメインの「サマリー」ページについて

- 17.3.3 アプリケーション・ドメインのリソース・コンテナについて

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

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

- 17.3.6 トークン発行ポリシー・ページについて

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

- 17.4.1 アプリケーション・ドメインの「サマリー」ページについて

- 17.4.2 コンソールを使用した新しいアプリケーション・ドメインの作成

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

- 17.4.4 Oracle Access Managementコンソールを使用したアプリケーション・ドメインの表示または編集

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

- 17.5 ポリシーに追加するリソース定義の追加および管理

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

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

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

- 17.5.1.3 リソースURL、接頭辞およびパターンについて

- 17.5.1.4 リソース定義の問合せ文字列の名前と値のパラメータについて

- 17.5.1.5 リソース定義のリテラル問合せ文字列について

- 17.5.1.6 実行時のリソース評価について

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

- 17.5.3 リソース定義の検索

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

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

- 17.5.4 リソース定義の表示、編集または削除

- 17.6 特定のリソースに対する認証ポリシーの定義

- 17.6.1 「認証ポリシー」ページについて

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

- 17.6.2 特定のリソース用の認証ポリシーの作成

- 17.6.3 認証ポリシーの検索

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

- 17.6.5 認証ポリシーの削除

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

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

- 17.7.2 認可ポリシーおよび特定のリソースの作成

- 17.7.3 認可ポリシーの検索

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

- 17.7.5 認可ポリシー全体の削除

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

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

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

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

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

- 17.8.4.1 単純なレスポンス

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

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

- 17.8.6 アサーションの要求および処理について

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

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

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

- 17.10 認可ポリシー・ルールおよび条件の概要

- 17.10.1 許可または拒否ルールについて

- 17.10.2 認可ポリシー条件について

- 17.10.3 条件のユーザーおよびグループの分類について

- 17.10.4 条件に基づく認可レスポンスのガイドライン

- 17.11 認可ポリシー条件の定義

- 17.11.1 条件タイプの選択

- 17.11.1.1 条件タイプの選択について

- 17.11.1.2 条件タイプの選択

- 17.11.2 アイデンティティ条件の定義

- 17.11.2.1 アイデンティティ条件について

- 17.11.2.2 アイデンティティ・タイプ条件の指定

- 17.11.3 IP4範囲条件の定義

- 17.11.3.1 IP4範囲条件タイプについて

- 17.11.3.2 IP4範囲条件の定義

- 17.11.4 一時的条件の定義

- 17.11.4.1 一時的条件について

- 17.11.4.2 一時的条件の定義

- 17.11.5 属性条件の定義

- 17.11.5.1 属性条件について

- 17.11.5.2 属性タイプ条件の定義

- 17.11.6 認可ポリシー条件の表示、編集または削除

- 17.12 認可ポリシー・ルールの定義

- 17.12.1 認可ポリシーのルールの定義について

- 17.12.2 式および式ベースのポリシー評価について

- 17.12.2.1 認可ルールの式の評価

- 17.12.3 認可ポリシーのルールの定義

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

- 17.14 ポリシーおよびアプリケーション・ドメインのリモート管理の理解

- 17.14.1 ポリシーのリモート管理について

- 17.14.2 ポリシー作成のリクエスト・テンプレートについて

- 17.14.3 ポリシー更新のリクエスト・テンプレートについて

- 17.14.4 リモート・ポリシー管理およびテンプレートについて

- 17.15 ポリシーおよびアプリケーション・ドメインのリモート管理

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

- 18.1 前提条件

- 18.2 Access Manager 11gのアクセス・テスターの概要

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

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

- 18.2.3 アクセス・テスターのモードおよび管理者の操作について

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

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

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

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

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

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

- 18.3.4.2 システム・プロパティを持つアクセス・テスターの起動

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

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

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

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

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

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

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

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

- 18.5.2.2 リソース保護の検証

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

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

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

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

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

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

- 18.6.1 テスト・ケースおよびテスト・スクリプトについて

- 18.6.2 テスト・ケースの取得

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

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

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

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

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

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

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

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

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

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

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

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

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

- 18.7.4 テスト実行結果を含むターゲット出力ファイルについて

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

- 18.7.6 実行ログについて

19 11g Webgateが関与するセッションの集中ログアウトの構成

- 19.1 前提条件

- 19.2 Access Manager 11gの集中ログアウトの概要

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

- 19.2.2 11g Webgateのログアウト・パラメータ

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

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

- 19.3.2 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

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

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

- 19.4.2 混在するエージェント・タイプを持つグローバル・サインオンの検証

- 19.4.3 集中ログアウトの監視

第VI部 Access Managerを使用したレガシー・エージェントの登録および使用

20 レガシーOpenSSOエージェントの登録および管理

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

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

- 20.1.2 OpenSSOエージェントのAccess Managerへの依存について

- 20.2 OpenSSOエージェントとAccess Manager間の実行時の処理

- 20.3 OpenSSOエージェント登録パラメータの理解

- 20.3.1 OpenSSOエージェント登録パラメータについて

- 20.3.2 拡張されたOpenSSOエージェント・ページとパラメータについて

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

- 20.4.1 Oracle Access Managementコンソールを使用したOpenSSOエージェントの登録

- 20.4.2 コンソールを使用した登録済OpenSSOエージェントの構成および管理

- 20.5 OpenSSOエージェントのリモート登録の実行

- 20.5.1 OpenSSOエージェントのリモート登録用リクエスト・テンプレートの理解

- 20.5.2 OpenSSOブートストラップ構成マッピングの再確認

- 20.5.3 OpenSSOエージェントの帯域内リモート登録の実行

- 20.5.4 OpenSSOエージェントの帯域外リモート登録の実行

- 20.6 登録済OpenSSOエージェントのリモート更新

- 20.6.1 OpenSSOエージェントのリモート更新

- 20.7 その他のOpenSSOエージェントの情報の参照先

21 レガシーOSSOエージェントの登録および管理

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

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

- 21.1.2 Access Manager 11g SSOとOSSO 10gの比較

- 21.2 Oracle Access Managementコンソールを使用したOSSOエージェントの登録

- 21.2.1 OSSOエージェント登録の作成ページとパラメータの理解

- 21.2.2 コンソールを使用したOSSOエージェント(mod_osso)の登録

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

- 21.3.1 コンソール内の拡張されたOSSOエージェント・ページの理解

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

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

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

- 21.4 OSSOエージェントのリモート登録の実行

- 21.4.1 OSSOリモート登録用のリクエスト・テンプレートの理解

- 21.4.2 OSSOエージェントの帯域内リモート登録の実行

- 21.4.3 OSSOエージェントの帯域外リモート登録の実行

- 21.5 登録済OSSOエージェントのリモート更新

- 21.6 Access Manager 11.1.2使用時のOSSOエージェントのログアウト

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

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

- 21.7 その他のOSSOエージェントついての情報の参照先

22 Access Manager 11gを使用する10g Webgateの登録および管理

- 22.1 前提条件

- 22.2 Access Manager 11g用の10g OAMエージェントの概要

- 22.2.1 IAMSuiteAgentについて: Access Managerに登録された事前構成済10g Webgate

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

- 22.2.3 Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて

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

- 22.3 Access Manager 11.1.2と10gの比較

- 22.3.1 Access Manager 11gと10gの比較

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

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

- 22.5 Access Manager 11gを使用した10g Webgateのリモート登録

- 22.6 10g OAMエージェントのリモート管理

- 22.7 Access Manager 11g用の最新の10g Webgateの検索およびインストール

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

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

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

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

- 22.7.5 安全な通信のための証明書の要求またはインストール

- 22.7.6 Webgateの構成詳細の指定

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

- 22.7.7.1 Webサーバーの手動構成

- 22.7.8 Webgateのインストール終了

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

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

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

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

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

- 22.8.3 Access Manager使用時の10g Webgateの集中ログアウト構成

- 22.9 IAMSuiteAgentの10g Webgateへの置換

- 22.9.1 IAMSuiteAgentの入替え用10g Webgateの登録

- 22.9.2 IAMSuiteAgentの入替え用10g Webgateのインストール

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

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

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

- 22.9.5.1 セキュリティ・プロバイダ

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

- 22.9.6 IAMSuiteAgentの無効化

- 22.9.7 検証

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

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

- 23.1 前提条件

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

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

- 23.3.1 Apache HTTP Serverについて

- 23.3.2 IBM HTTP Serverについて

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

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

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

- 23.5.1 IHS2 Webサーバーの要件

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

- 23.5.3 Apache v2 Webサーバーの要件

- 23.6 Webサーバーの準備

- 23.6.1 IHS v2 Webサーバーの準備

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

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

- 23.6.1.3 SSL機能の設定

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

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

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

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

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

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

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

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

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

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

- 23.8 Webgate用のhttpd.conf更新の検証

- 23.8.1 Webgateの詳細検証

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

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

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

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

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

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

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

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

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

- 23.14 役立つ情報

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

- 24.1 前提条件

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

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

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

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

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

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

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

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

- 24.5.3 ISAPIフィルタの並替え

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

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

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

- 25.1 前提条件

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

- 25.2.1 ISAPI Webgateのガイドライン

- 25.2.1.1 IIS v7対応Webgate

- 25.2.1.2 IIS v6対応Webgate

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

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

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

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

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

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

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

- 25.5.2 ISAPIフィルタの並替え

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

- 25.5.3.1 ISAPI Webgate 10.1.4.2.3について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 26.1 前提条件

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

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

- 26.4 Domino Webサーバーの起動

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

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

- 26.6.1 Webgateインストールの完了

第VII部 Oracle Access ManagementのIdentity Federationの管理

27 Oracle Access ManagementでのIdentity Federationの概要

- 27.1 Identity FederationとOracle Access Managementの統合

- 27.1.1 Oracle Access ManagementでのフェデレーテッドSSO

- 27.1.2 Access ManagerとIdentity Federation 11.1.2の併用による利点

- 27.1.3 Access ManagerとIdentity Federation統合の主要な要素

- 27.1.4 主な機能

- 27.1.4.1 動作モード

- 27.1.4.2 サポートされているプロトコル

- 27.1.4.3 サポートされているデータ・ストア

- 27.1.4.4 ユーザー・マッピング

- 27.1.4.5 マルチテナントのサポート

- 27.1.4.6 プラットフォームとの依存関係

- 27.1.5 管理

- 27.2 Oracle Access ManagementコンソールでのIdentity Federationの概要

- 27.3 フェデレーション・サービスの管理

28 Oracle Access Managementコンソールを使用したIdentity Federation用パートナの管理

- 28.1 前提条件

- 28.2 フェデレーション・パートナの管理の概要

- 28.3 フェデレーション用のアイデンティティ・プロバイダ・パートナの管理

- 28.3.1 フェデレーション・アイデンティティ・プロバイダの作成

- 28.3.2 フェデレーションのアイデンティティ・プロバイダの管理

29 Oracle Access Managementコンソールを使用したIdentity Federationの設定の管理

- 29.1 前提条件

- 29.2 Oracle Access Managementコンソールの「フェデレーション設定」の概要

- 29.3 フェデレーションの一般設定の管理

- 29.3.1 フェデレーションの一般設定の管理について

- 29.3.2 フェデレーションの一般設定の管理

- 29.4 Oracle Access Managementコンソールでのフェデレーションのプロキシ設定の管理

- 29.4.1 フェデレーションのプロキシ設定について

- 29.4.2 Identity Federationのプロキシ設定の管理

- 29.5 Oracle Access Managementコンソールでのフェデレーションのキーストア設定の定義

- 29.5.1 Identity Federationのキーストア設定の管理について

- 29.5.2 Identity Federationの暗号化/署名鍵の管理

- 29.5.2.1 システム(.oamkeystore)および信頼(amtruststore)キーストア・パスワードのリセット

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

- 29.6 メタデータのエクスポート

30 Oracle Access Managementコンソールを使用したフェデレーション関連のスキームおよびポリシーの管理

- 30.1 前提条件

- 30.2 Identity FederationとAccess Managerの併用方法の概要

- 30.3 Identity Federation 11gリリース2(11.1.2)の認証スキームおよび認証モジュールの使用

- 30.3.1 スキームFederationSchemeについて

- 30.3.2 モジュールFederationPluginについて

- 30.3.3 11gリリース2のIdentity Federationでの認証の管理

- 30.4 Oracle Identity Federation 11gリリース1の認証スキームおよび認証モジュールの使用

- 30.4.1 スキームOIFSchemeについて

- 30.4.2 モジュールOIFMTLDAPPluginについて

- 30.4.3 Oracle Identity Federationリリース11gR1での認証の管理

- 30.5 Identity Federationで使用するAccess Managerのポリシーの管理

- 30.5.1 Identity Federationのアサーション属性を含むポリシー・レスポンスについて

- 30.5.2 Identity Federationのアサーション属性を含むポリシー・レスポンスの定義

- 30.6 Identity Federationの構成のテスト

- 30.7 デフォルト・アイデンティティ・プロビジョニング・プラグインの使用

- 30.7.1 プロビジョニング・プラグインを使用する理由

- 30.7.2 デフォルト・プロビジョニング・プラグインについて

- 30.7.3 デフォルト・プロビジョニング・プラグインの使用

- 30.7.4 カスタム・プロビジョニング・プラグインへの切替え

- 30.8 アイデンティティ・プロバイダ検出サービスの構成

- 30.8.1 バンドルされたIdP検出サービスの使用

- 30.8.2 カスタムIdP検出サービスの作成

- 30.8.3 IdP検出サービスの使用の無効化

- 30.9 フェデレーション・ユーザー自己登録モジュールの構成

第VIII部 Oracle Access Management Security Token Serviceの管理

31 セキュリティ・トークン・サービスの実装シナリオ

- 31.1 前提条件

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

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

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

- 31.3.2 リクエスト・セキュリティ・トークンの属性と実行時の処理

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

- 31.3.4 実装のテスト

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

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

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

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

32 セキュリティ・トークン・サービスの設定値と設定の管理

- 32.1 前提条件

- 32.2 セキュリティ・トークン・サービス構成の概要

- 32.2.1 インストール後の構成

- 32.2.2 OAMサーバーとセキュリティ・トークン・サービスについて

- 32.2.3セキュリティ・トークン・サービス・クライアントについて

- 32.2.4 エージェントとセキュリティ・トークン・サービスについて

- 32.2.5 セキュリティ・トークン・サービス・エンドポイントとポリシーについて

- 32.3 セキュリティ・トークン・サービスの有効化および無効化

- 32.3.1 セキュリティ・トークン・サービスとOracle Access Managementコンソールについて

- 32.3.1.1 セキュリティ・トークン・サービス管理者について

- 32.3.1.2 セキュリティ・トークン・サービスへのログインおよびサインアウトについて

- 32.3.2 セキュリティ・トークン・サービスのサービスの有効化について

- 32.3.3 セキュリティ・トークン・サービスのサービスの有効化および無効化

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

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

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

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

- 32.5.1 Oracle Workspace Studioポリシーの使用方法と変更方法

- 32.5.2 セキュリティ・トークン・サービスのためのWSSポリシーの管理: クラスパス

- 32.5.3 セキュリティ・トークン・サービスのためのWSSポリシーの管理: Oracle WSM Policy Manager

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

- 32.6.1 セキュリティ・トークン・サービスのOracle WSMエージェントのWS-Securityポリシーについて

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

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

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

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

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

- 32.7 セキュリティ・トークン・サービス・ポリシーの管理および移行

- 32.7.1 セキュリティ・トークン・サービス・ポリシーの管理および移行について

- 32.7.2 セキュリティ・トークン・サービス・ポリシーの管理

- 32.7.3 セキュリティ・トークン・サービス・ポリシーの移行

- 32.8 セキュリティ・トークン・サービス・メッセージのロギングの概要

- 32.9 セキュリティ・トークン・サービスの監査の概要

- 32.9.1 セキュリティ・トークン・サービス監査レコードの格納について

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

- 32.9.3 監査ログについて

- 32.9.4 セキュリティ・トークン・サービス・イベントの監査について

33 セキュリティ・トークン・サービスの証明書と鍵の管理

- 33.1 前提条件

- 33.2 セキュリティ・トークン・サービスの証明書と鍵の概要

- 33.2.1 キーストアとセキュリティ・トークン・サービスについて

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

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

- 33.3 セキュリティ・トークン・サービスの暗号化/署名鍵の管理

- 33.3.1 システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット

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

- 33.3.2.1 新しいエントリの追加

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

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

- 33.3.3 セキュリティ・トークン・サービス証明書の抽出

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

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

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

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

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

- 33.5 証明書検証の管理

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

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

- 33.5.3 セキュリティ・トークン・サービスのカスタム信頼アンカー・ストアの使用方法

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

- 34.1 前提条件

- 34.2 はじめに

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

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

- 34.3.2 テンプレートの検索

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

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

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

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

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

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

- 34.6 セキュリティ・トークン・サービス・エンドポイントの管理

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

- 34.6.2 エンドポイントの管理

- 34.7 トークン発行ポリシー、条件およびルールの管理

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

- 34.7.2 トークン発行条件およびルールの管理について

- 34.7.3 トークン発行ポリシーおよび条件の管理

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

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

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

- 34.9 カスタム・クラスを使用可能にする

- 34.9.1 クラスを使用可能にする処理について

- 34.9.2 カスタム・トークンの検索範囲の絞込みについて

- 34.9.3 カスタム・トークンの管理

- 34.10 セキュリティ・トークン・サービス・カスタム構成の管理

- 34.10.1 検証テンプレートの作成

- 34.10.2 カスタム・トークンの発行テンプレートの作成

- 34.10.3 カスタム・トークンをリクエスタ・プロファイルに追加

- 34.10.4 カスタム・トークンをリライイング・パーティ・プロファイルに追加

- 34.10.5 トークンをリクエスタにマップ

- 34.10.6 /wssuserエンドポイントの作成

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

- 35.1 前提条件

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

- 35.2.1 Token Serviceパートナについて

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

- 35.2.2.1 パートナ・エントリについて

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

- 35.3 Token Serviceパートナの管理

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

- 35.3.2 Token Serviceパートナの管理

- 35.3.3 パートナ検索の絞込み

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

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

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

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

36 セキュリティ・トークン・サービスのトラブルシューティング

- 36.1 認可の問題

- 36.2 エンドポイントの問題

- 36.3 マッピング操作の問題

第IX部 Oracle Access Management Mobile and Socialの管理

37 Mobile and Socialの理解

- 37.1 Mobile and Socialの概要

- 37.1.1 Mobile and Socialのデプロイ

- 37.1.2 Mobile and Socialのインストール

- 37.2 モバイル・サービスの理解

- 37.2.1 認証サービスおよび認可サービスの概要

- 37.2.2 ユーザー・プロファイル・サービスの概要

- 37.2.3 モバイル・シングル・サインオン(SSO)機能の概要

- 37.2.4 Mobile and Socialモバイル・サービス・クライアントSDKの概要

- 37.3 モバイル・サービスのプロセスの理解

- 37.3.1 ユーザー認証によるモバイル・デバイスの登録

- 37.3.2 登録済デバイスによるユーザー認証

- 37.3.3 ユーザー認証のためのRESTコールの使用

- 37.3.4 モバイルのブラウザベースのWebアプリケーションによるユーザーの認証

- 37.4 モバイル・サービスの使用

- 37.4.1 モバイル・クライアント登録エンドポイントの保護

- 37.4.2 資格証明の交換

- 37.4.3 ユーザー・プロファイル・サービスと認可サービスの保護

- 37.4.4 モバイル・サービスとOracle Access Managerの併用

- 37.4.5 モバイル・サービスとOracle Adaptive Access Managerサービスの使用

- 37.5 インターネット・アイデンティティ・サービスの理解

- 37.6 インターネット・アイデンティティ・サービス・プロセスの理解

- 37.6.1 ローカル・アカウントを持つユーザーが返された場合の認証

- 37.6.2 ローカル・アカウントのない新しいユーザーの認証

- 37.6.3 OAuthを使用したアクセス・トークンの取得

- 37.6.4 Access Managerとインターネット・アイデンティティ・サービスによるユーザー認証

- 37.6.5 ユーザーのローカル認証

- 37.7 インターネット・アイデンティティ・サービスの使用

- 37.7.1 インターネット・アイデンティティ・サービスとOracle Access Managerの併用

- 37.7.2 インターネット・アイデンティティ・サービスとモバイル・サービスの使用

- 37.7.3 インターネット・アイデンティティ・サービスSDKの使用

38 モバイル・サービスの構成

- 38.1 モバイル・サービスのGUIのナビゲート

- 38.2 モバイル・サービスの構成の理解

- 38.2.1 サービス・プロバイダについて

- 38.2.2 サービス・プロファイルの理解

- 38.2.3> セキュリティ・ハンドラ・プラグインの理解

- 38.2.4 アプリケーション・プロファイルの理解

- 38.2.5 サービス・ドメインの理解

- 38.3 サービス・プロバイダの定義

- 38.3.1 認証サービス・プロバイダの定義、変更または削除

- 38.3.1.1 認証サービス・プロバイダの作成

- 38.3.1.2 認証サービス・プロバイダの編集または削除

- 38.3.1.3 事前構成済認証サービス・プロバイダの理解

- 38.3.2 認可サービス・プロバイダの定義、変更または削除

- 38.3.2.1 認可サービス・プロバイダの作成

- 38.3.2.2 認可サービス・プロバイダの編集または削除

- 38.3.2.3 事前構成済認可サービス・プロバイダの理解

- 38.3.3 ユーザー・プロファイル・サービス・プロバイダの定義、変更または削除

- 38.3.3.1 ユーザー・プロファイル・サービス・プロバイダの作成

- 38.3.3.2 ユーザー・プロファイル・サービス・プロバイダの編集または削除

- 38.3.3.3 事前構成済ユーザー・プロファイル・サービス・プロバイダの理解

- 38.4 サービス・プロファイルの定義

- 38.4.1 認証サービス・プロファイルの定義、変更および削除

- 38.4.1.1 認証サービス・プロファイルの作成

- 38.4.1.2 認証サービス・プロファイルの編集または削除

- 38.4.2 認可サービス・プロファイルの定義、変更および削除

- 38.4.2.1 認可サービス・プロファイルの作成

- 38.4.2.2 認可サービス・プロファイルの編集または削除

- 38.4.3 ユーザー・プロファイル・サービス・プロファイルの定義、変更および削除

- 38.4.3.1 ユーザー・プロファイル・サービス・プロファイルの作成

- 38.4.3.2 ユーザー・プロファイル・サービス・プロファイルの編集または削除

- 38.5 セキュリティ・ハンドラ・プラグインの定義

- 38.5.1 セキュリティ・ハンドラ・プラグインの作成

- 38.5.2 セキュリティ・ハンドラ・プラグインの編集または削除

- 38.5.3 デバイス・フィンガープリントおよびデバイス・プロファイル属性

- 38.6 アプリケーション・プロファイルの定義

- 38.6.1 アプリケーション・プロファイルの作成

- 38.6.2 アプリケーション・プロファイルの編集または削除

- 38.7 サービス・ドメインの定義

- 38.7.1 サービス・ドメインの作成

- 38.7.2 サービス・ドメインの編集または削除

- 38.8 ジェイルブレーク検出ポリシーの使用

- 38.8.1 新しいジェイルブレーク検出ポリシーの追加

- 38.8.2 ジェイルブレーク検出ポリシーの編集

- 38.9 その他のOracle製品を使用したモバイル・サービスの構成

- 38.9.1 Access Manager用のモバイル・サービスの構成

- 38.9.1.1 簡易モードおよび証明書モードのAccess Managerと連動するモバイル・サービスの構成

- 38.9.1.2 リモートのOracle Access Manager Server 10g用の認証サービス・プロバイダの構成

- 38.9.1.3 リモートのAccess Manager 11gR2またはOracle Access Manager 11gR1 PS1用の認証サービス・プロバイダの構成

- 38.9.2 Oracle Adaptive Access Manager用のモバイル・サービスの構成

- 38.9.2.1 Mobile and SocialのOAAMサポートの理解

- 38.9.2.2 WebLogic管理ドメインの構成

- 38.9.2.3 紛失または盗難デバイス・ルールの設定

- 38.9.2.4 ブラックリストに記載されたデバイスおよびアプリケーションの構成

- 38.9.2.5 モバイル・アプリケーションのOAAMセッションの理解

- 38.9.2.6 OAAM認証のユーザー登録

39 インターネット・アイデンティティ・サービスの構成

- 39.1 インターネット・アイデンティティ・サービスのGUIのナビゲート

- 39.2 インターネット・アイデンティティ・サービスの構成の理解

- 39.2.1 インターネット・アイデンティティ・プロバイダの理解

- 39.2.2 サービス・プロバイダ・インタフェースの理解

- 39.2.3 アプリケーション・プロファイルの理解

- 39.3 インターネット・アイデンティティ・プロバイダの定義

- 39.3.1 インターネット・アイデンティティ・プロバイダの作成

- 39.3.2 インターネット・アイデンティティ・プロバイダの編集または削除

- 39.3.3 OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成

- 39.3.3.1 Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成

- 39.3.3.2 Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成

- 39.3.3.3 LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成

- 39.3.4 インターネット・アイデンティティ・プロバイダのトラブルシューティング

- 39.3.4.1 Facebookとの互換性があるWebLogic Serverの構成

- 39.3.4.2 Facebookとの互換性があるWebLogic Server 10.3.5以前の構成

- 39.4 サービス・プロバイダ・インタフェースの定義

- 39.4.1 サービス・プロバイダ・インタフェースの作成

- 39.4.2 サービス・プロバイダ・インタフェースの編集または削除

- 39.4.3 カスタム・サービス・プロバイダ・インタフェース実装の追加

- 39.5 アプリケーション・プロファイルの定義

- 39.5.1 アプリケーション・プロファイルの作成

- 39.5.2 アプリケーション・プロファイルの編集または削除

- 39.6 インターネット・アイデンティティ・サービスとモバイル・アプリケーションの統合

40 Mobile and Socialシステム設定の構成

- 40.1 Mobile and Social設定インタフェースへのアクセス

- 40.2ロギングおよび監査

- 40.3 Oracle Access Managerを使用するMobile and Socialのデプロイ

- 40.4 テストから本番に移行するスクリプトを実行した後のMobile and Socialの構成

第X部 アイデンティティ・コンテキストの使用

41 アイデンティティ・コンテキストの使用方法

- 41.1 アイデンティティ・コンテキストの概要

- 41.2 アイデンティティ・コンテキストの理解

- 41.3 アイデンティティ・コンテキスト・サービスの操作

- 41.3.1 アイデンティティ・コンテキスト・ディクショナリの使用方法

- 41.3.2 アイデンティティ・コンテキスト・ランタイムの理解

- 41.4 アイデンティティ・コンテキストAPIの使用方法

- 41.5 アイデンティティ・コンテキスト・サービス・コンポーネントの構成

- 41.5.1 Oracle Fusion Middlewareの構成

- 41.5.2 Access Managerの構成

- 41.5.2.1 IDアサーションの構成

- 41.5.2.2 フェデレーション属性の構成

- 41.5.2.3 セッション属性の構成

- 41.5.2.4 アイデンティティ・ストア属性の構成

- 41.5.3 Oracle Adaptive Access Managerの構成

- 41.5.3.1 Oracle Adaptive Access Managerのセットアップ

- 41.5.3.2 OAAM統合のためのAccess Managerの構成

- 41.5.3.3 OAAMによって公開されるアイデンティティ・コンテキスト・データの検証

- 41.5.4 Webサービス・セキュリティ・マネージャの構成

- 41.5.5 Oracle Entitlements Serverの構成

- 41.5.6 Oracle Enterprise Single Sign Onの構成

- 41.5.7 Oracle Access Management Mobile and Socialの構成

- 41.6 アイデンティティ・コンテキストの検証

第IX部 他の製品とAccess Managerとの統合

42 RSA SecurID認証とAccess Managerとの統合

- 42.1 Access ManagerおよびRSA SecurID認証の概要

- 42.2 SecurID認証に必要なコンポーネント

- 42.2.1 バージョンおよびプラットフォームのサポート

- 42.2.2 必要なRSAコンポーネント

- 42.2.2.1 RSA Authentication Manager

- 42.2.2.2 RSA SecurIDトークン

- 42.2.3 インストール要件および構成要件

- 42.3 SecurID認証モード

- 42.3.1 標準SecurID認証

- 42.3.2 SecurID Next Tokencode認証

- 42.3.3 SecurID New PIN認証

- 42.4 RSA SecurID認証用のAccess Managerの構成

43 Windowsネイティブ認証のためのAccess Managerの構成

- 43.1 このリリースの新機能

- 43.2 Access ManagerとWindowsネイティブ認証の概要

- 43.2.1 Access ManagerのWNAログインおよびフォールバック認証

- 43.2.2 サポートされる統合方法

- 43.3 Active Directory/Kerberosトポロジの準備

- 43.4 Oracle固有の前提条件となるタスクの実行

- 43.4.1 Access Managerの操作の確認

- 43.5 Kerberosトークンを返すためのブラウザの有効化

- 43.6 KerberosPluginとOracle Virtual Directoryの統合

- 43.6.1 統合のためのOracle Virtual Directoryの準備

- 43.6.2 WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録

- 43.6.3 Access Manager KerberosPluginおよびOVDを使用した認証の設定

- 43.7 Access Manager KerberosPluginと検索フェイルオーバーの統合

- 43.7.1 Microsoft Active DirectoryインスタンスのAccess Managerへの登録

- 43.7.2 ADGCのためのAccess Manager KerberosPluginの設定

- 43.8 Windowsネイティブ認証のためのAccess Managerの構成

- 43.8.1 Windowsネイティブ認証用の認証スキームの作成

- 43.8.2 Windowsネイティブ認証用のAccess Managerポリシーの構成

- 43.8.3 Access Manager構成ファイルの確認

- 43.9 Access Managerによって保護されたリソースでのWNAの検証

- 43.10 WNA構成のトラブルシューティング

- 43.10.1 Kinitの失敗

- 43.10.2 WNA認証スキームを使用して保護されたリソースにアクセスできない

- 43.10.3 ユーザー・アイデンティティ・ストアがActive Directoryではない

44 JBossとAccess Managerの統合

- 44.1 JBossとAccess Managerの概要

- 44.1.1 Access Manager JBossエージェントによる構成および処理について

- 44.1.2 Access Managerログイン・モジュールによる構成および処理について

- 44.2 統合トポロジ

- 44.2.1 Access Manager JBossエージェントの機能

- 44.2.2 トポロジ: Access ManagerとJBossエージェント

- 44.2.3 トポロジ: Webgateを使用して構成されたWebサーバーの背後のJBossエージェント

- 44.2.4 サンプル統合トポロジ

- 44.3 JBoss統合のための環境の準備

- 44.4 JBoss固有のリソースの保護

- 44.4.1 自動ポリシー作成を使用したJBossエージェントの登録

- 44.4.2 JBossリソース保護のためのカスタム・ポリシーの作成

- 44.5 JBossエージェントによるWebアプリケーションの保護

- 44.5.1 JBossエージェントの構成プロパティの作成

- 44.5.2 認証バルブの構成

- 44.5.3 アプリケーションのweb.xmlファイルへのフィルタのマッピング

- 44.5.4 Access Managerポリシーを使用するためのJBossログイン・モジュールの構成

- 44.6 localhostではなくホスト名にアクセスするためのJBossサーバーの構成

- 44.7 EJBを保護するためのログイン・モジュールの構成

- 44.7.1 EJBを保護するためのサーバーの構成

- 44.7.2 EJBを保護するためのクライアント側の構成

- 44.8 Webサービスへのアクセスを保護するためのログイン・モジュールの構成

- 44.8.1 Webサービスへのアクセスを保護するためのサーバーの構成

- 44.8.2 Webサービスへのアクセスを保護するためのクライアントの構成

- 44.9 JBossエージェントおよびログイン・モジュールのためのロギングの構成

- 44.10 構成の検証

45 Microsoft SharePoint Server 2010とAccess Managerの統合

- 45.1 このリリースの新機能

- 45.2 SharePoint Server 2010との統合の概要

- 45.2.1 Windowsの偽装について

- 45.2.2 この統合でのフォーム・ベースの認証について

- 45.2.3 Windowsの偽装およびSharePoint 2010の統合を使用した認証について

- 45.2.4 Access ManagerとWindowsネイティブ認証について

- 45.3 統合の要件

- 45.3.1 要件の確認

- 45.3.2 必要なAccess Managerのコンポーネント

- 45.3.3 必要なMicrosoftのコンポーネント

- 45.4 SharePoint 2010との統合の準備

- 45.5 Microsoft SharePoint Server 2010との統合

- 45.5.1 Microsoft SharePoint Server 2010での新規Webアプリケーションの作成

- 45.5.2 Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成

- 45.6 Microsoft Windowsの偽装の設定

- 45.6.1 信頼できるユーザー・アカウントの作成

- 45.6.2 信頼できるユーザーへの権限の割当て

- 45.6.3 信頼できるユーザーのWebgateへのバインド

- 45.6.4 偽装レスポンスの認可ポリシーへの追加

- 45.6.5 偽装dllのIISへの追加

- 45.6.6 偽装のテスト

- 45.6.6.1 SharePoint Serverによって保護されていないIIS仮想サイトの作成

- 45.6.6.2 イベント・ビューアを使用した偽装のテスト

- 45.6.6.3 Webページを使用した偽装のテスト

- 45.6.6.4 偽装のネガティブ・テスト

- 45.7 SharePoint Serverの統合の完了

- 45.7.1 IISセキュリティの構成

- 45.8 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

- 45.8.1 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合について

- 45.8.2 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010のためのAccess Managerのインストール

- 45.8.3 LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成

- 45.8.4 SharePoint Webサイトを保護するアプリケーション・ドメインの更新

- 45.8.5 ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成

- 45.8.6 OAMAuthCookieのための認可レスポンスの作成

- 45.8.7 OAMCustomMemebershipProviderの構成およびデプロイ

- 45.8.8 CustomMemeberShipProviderのロギングの有効化

- 45.8.9 ディレクトリ・サーバーが同期化されていることの確認

- 45.8.10 統合のテスト

- 45.9 Officeドキュメントのためのシングル・サインオンの構成

- 45.10 Microsoft SharePoint Server 2010のためのシングル・サインオフの構成

- 45.10.1 SharePoint Server 2010でのカスタム・ログアウトURLの構成

- 45.10.2 偽装を使用したSharePoint Server 2010でのログアウトの構成

- 45.11 Access ManagerとWindowsネイティブ認証の設定

- 45.11.1 Access Manager WNAの設定

- 45.11.2 SharePoint Server 2010を使用したWNAの設定

- 45.11.3 WNAおよびSharePoint Server 2010のためのAccess Managerのインストール

- 45.11.4 WNA実装のテスト

- 45.12 ディレクトリ間のユーザー・プロファイルの同期化

- 45.13 統合のテスト

- 45.13.1 SharePoint Serverの統合のテスト

- 45.13.2 SharePoint Serverの統合のためのシングル・サインオンのテスト

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

- 45.14.1 Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない

第XII部 付録

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

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

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

- A.1.2 Oracle Application Developer Framework

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

- A.2.1 Access Manager用のSSO構成のサンプル

- A.2.2 SSOプロバイダ構成詳細

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

- A.3.1 Oracle ADF標準に準拠してコードが記述されたアプリケーションでの一元化されたログアウト処理について

- A.3.2 Access ManagerでのADFコード化されたアプリケーションの集中ログアウトの構成

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

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

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

- B.1.1ローカライズされたメッセージの言語

- B.1.2 双方向言語のサポート

- B.1.3 UTF-8エンコーディング

C 通信の保護

- C.1 前提条件

- C.2 OAMサーバーとWebgate間の安全な通信の概要

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

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

- C.2.3 Importcertツールについて

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

- C.4 Access Manager用の証明書モード通信の構成

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

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

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

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

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

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

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

- C.5 Access Managerの簡易モード通信の構成

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

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

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

- C.5.4 簡易モード構成の検証

D バンドル、生成および移行されるアーティファクトの確認

- D.1 バンドルされる10g IAMSuiteAgentアーティファクト

- D.1.1 事前登録済の10g IAMSuiteAgent

- D.1.2 IAMSuiteAgentセキュリティ・プロバイダの設定、WebLogic管理コンソール

- D.1.3 IAMSuiteAgent登録

- D.1.4 IAMSuiteAgentで保護されるリソース

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

- D.2 生成されるアーティファクト: OpenSSO

- D.2.1 生成されるOpenSSOAgentAuthPlugin

- D.2.2 生成されるホスト識別子: OpenSSOAgent

- D.2.3 生成されるアプリケーション・ドメイン: OpenSSOAgent

- D.2.4 生成されるリソース: OpenSSOAgent

- D.2.5 生成される認証ポリシー: OpenSSOAgentアプリケーション・ドメイン

- D.2.6 生成される認可ポリシー: OpenSSOAgentアプリケーション・ドメイン

- D.3 移行されるアーティファクト: OpenSSO

- D.3.1 移行されるユーザー・アイデンティティ・ストア: OpenSSO

- D.3.2 移行されるエージェント: OpenSSO

- D.3.3 移行される認証モジュール: OpenSSO

- D.3.4 移行されるホスト識別子: OpenSSO

- D.3.5 移行されるアプリケーション・ドメイン: OpenSSO

- D.3.6 移行されるリソース: OpenSSO

- D.3.7 移行される認証ポリシー: OpenSSO

- D.3.8 移行される認可ポリシー: OpenSSO

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

- E.1 Oracle Access Managementトラブルシューティングの概要

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

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

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

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

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

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

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

- E.2 My Oracle Supportを使用したその他のトラブルシューティング情報

- E.3 管理者のロックアウト

- E.4 Oracle Access Managementコンソールの状態が矛盾している

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

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

- E.7 アプリケーションURL要件

- E.8 認証の問題

- E.8.1 匿名認証の問題

- E.8.2 X.509スキームおよびSSLハンドシェイクの問題

- E.8.2.1 構成の問題

- E.8.2.2 信頼性の問題

- E.8.2.3 証明書検証の問題

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

- E.8.4 X509CredentialExtractor 証明書検証エラー

- E.9 認可の問題

- E.9.1 認可条件のエラー

- E.9.2 LDAP検索フィルタ・テストの結果

- E.9.3 認可ヘッダー・レスポンスの名前

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

- E.11 構成が見つからない

- E.11.1 構成が存在しない...

- E.12 OSSOとAccess Manager間のCo-existence

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

- E.14 DoS攻撃

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

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

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

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

- E.15.1 10g Webgateでの認証の問題

- E.15.2 10g Webgateでのログアウトの問題

- E.16 初期化およびパフォーマンスの問題の診断

- E.16.1 初期化の問題の診断

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

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

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

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

- E.19 IIS Webサーバーの問題

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

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

- E.19.3 IIS v6 Webサーバーの問題

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

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

- E.20 インポートおよびファイル・アップロードの制限

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

- E.22 国際化、言語および翻訳

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

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

- E.22.3 認証の失敗: ASCII以外の文字を含むユーザー

- E.22.4 ASCII以外のエージェント名ではアクセス・テスターが機能しない

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

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

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

- E.25 部分的なクラスタ障害および断続的なログインおよびログアウト障害

- E.26 RSA SecurIDの問題とログ

- E.27 登録の問題

- E.28 Rowkeyに主キー属性がないエラー

- E.29 SELinuxの問題

- E.30 セッションの問題

- E.30.1 セッション偽装がデフォルトでは有効になっていない

- E.30.2 Oracle Identity Federation 11.1.1と統合されたOracle Access Manager 11.1.1とのセッション

- E.31 SSLとオープンな通信の比較

- E.32 起動の問題

- E.33 OAMサーバー・クロックの同期化

- E.34 Coherenceの使用

- E.35 検証エラー

- E.36 Webサーバーの問題

- E.36.1 Apache Webサーバー上のサーバー障害

- E.36.2 HP-UX上のApache v2

- E.36.3 Red Hat Enterprise Linux 4にバンドルされたApache v2

- E.36.4 セキュリティ強化LinuxにバンドルされたApache v2

- E.36.5 Webgateのmpm_worker_moduleを使用したUNIX上のApache v2

- E.36.6 Domino Webサーバーの問題

- E.36.7 エラー、アクセスの消失および予期しない動作

- E.36.8 ISA Webサーバーの既知の問題

- E.36.9 LinuxThreadsでOracle HTTP Serverが開始しない

- E.36.10 Linux Red Hat 4上でOracle HTTP Server Webgateが初期化されない

- E.36.11 Oracle HTTP Server Web Server構成ファイルの問題

- E.36.12 IIS v6 Webサーバーの問題

- E.36.13 Sun Webサーバーの開始時のPCLOSEエラー

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

- E.37 Windowsネイティブ認証

Mobile and Social用語集

索引

例一覧

- 6-1 Access Managerのログ出力とログ・ハンドラの構成

- 7-1 コメントのあるデフォルトのログ構成ファイル

- 7-2 グローバル設定を含む単純なリスト(oblog_config_wg.xmlファイルの最初の複合リスト)

- 7-3 FILTER_LISTによるログ・ファイル内の機密属性のマスキング

- 7-4 有効な名前/値リスト

- 7-5 別の有効な名前/値リスト

- 7-6 名前/値リストの開始タグ

- 7-7 名前/値リストの開始タグ

- 7-8 埋込みコメントなしのデフォルトのログ構成ファイル

- 18-1 接続構成ファイル

- 18-2 生成された入力テストスクリプト

- 18-3 テストの実行中に生成された出力ファイル

- 18-4 統計ドキュメントの例

- 18-5 実行ログ

- 22-1 logout.htmlのスクリプト

- 22-1 mod_wl_ohs.confでの10g Webgate用の更新

- 31-1 交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン

- 31-2 Security Token Serviceによって送信されるリクエスト・セキュリティ・トークン・レスポンス

- 38-1 サンプルのmerge-creds.xml

- 41-1 アイデンティティ・コンテキスト・ディクショナリとの連動

- 41-2 属性サービスにアプリケーションへのアクセス権を付与するためのWLSTの使用方法

- 41-3 アイデンティティ・コンテキスト・ランタイムとの連動

- 41-4 アイデンティティ・コンテキストを作成するカスタム関数

- 45-1 サンプルの.ASPページ・コード

- A-1 Access Manager用のSSO構成のサンプル

図一覧

- 1-1 Oracle Access Managementの概要

- 2-2 Access Manager 11gのコンポーネントおよびサービス

- 1-3 Access Manager 11gのコンポーネントの分散

- 1-4 Oracle STSのアーキテクチャ

- 1-5 Oracle STSのトークン・サポート

- 1-6 一元化された認証局でのトークン変換

- 1-7 ファイアウォールの背後でのトークンの変換

- 1-8 WebサービスSSO

- 2-1 Oracle Access Managementコンソールのデフォルトの「ログイン」ページ

- 2-2 サインアウト・リンク、Oracle Access Managementコンソール

- 2-3 Oracle Access Managementコンソールの「ようこそ」ページ

- 2-4 メニューおよびツール・バーがあるナビゲーション・ツリー

- 2-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー

- 2-6 「表示」メニュー

- 2-7 「アクション」メニュー

- 2-8 「オープン」ページのタブおよびページ・コントロール

- 2-9 OAMエージェントの「検索」ページの例

- 3-1 「システム構成」の「共通構成」ノード

- 3-2 「システム構成」、「使用可能なサービス」ページ(右)

- 3-3 「共通設定」ページ(折りたたんだ表示)

- 3-4 共通のコヒーレンス設定

- 3-5 グローバル証明書検証のOCSP/CDP設定

- 3-6 「証明書失効リスト」ダイアログ・ボックス

- 4-1 ユーザー・アイデンティティ・ストア登録の作成

- 4-2 システム・ストア登録

- 4-3「登録」ページ内の「デフォルトとシステム・ストアのオプション」

- 4-4「登録」ページで指定されたストア

- 4-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア

- 4-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録

- 4-7 システム管理者ロールの追加

- 5-1 「プロキシ」タブが表示されたOAMサーバー登録ページ

- 5-2 コヒーレンス・ページおよび個々のOAMサーバーの値

- 7-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化

- 8-1 データベースによる監査アーキテクチャ

- 8-2 「共通設定」: 「監査構成」

- 9-1 「サーバー・プロセス概要」ページ

- 9-2 OAMサーバー・メトリック: 「セッション操作」の「モニター」ページ

- 9-3 OAMサーバー・メトリック: 「サーバー操作」タブ

- 9-4 OAMサーバー・メトリック: 「OAMエージェント」タブ

- 9-5 OAMエージェント・メトリック: モニタリング特性

- 9-6 OAMエージェント・メトリック: デタッチされた接続性の表

- 9-7 OAMエージェント・メトリック: デタッチされた操作の概要表

- 9-8 OAMエージェント・メトリック: デタッチされた操作の詳細表

- 9-9 OAMエージェント・メトリック: デタッチされた情報の表

- 9-10 OSSOエージェントの「モニター」ページの「操作の詳細」

- 9-11 OSSOエージェント・モニタリング・プロセスの概要表

- 9-12 OSSOエージェント情報の表

- 10-1 Fusion Middleware Control (AS-Control)デプロイメント・アーキテクチャ

- 10-2 Fusion Middleware ControlのOAM「ファーム」ページ

- 10-3 Fusion Middleware Control内のファーム・ナビゲーション・ツリー

- 10-4 Fusion Middleware Control内のノード情報ページ

- 10-5 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー

- 10-6 「アプリケーション・デプロイメント」メニュー

- 10-7 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー

- 10-8 「クラスタ」ページ

- 10-9 サーバー・ページの「主要なメトリック」

- 10-10 クラスタの集約されたAccess Managerコンポーネント・メトリック

- 10-11 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック

- 10-12 クラスタの集約されたSTSコンポーネント・メトリック

- 10-13 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック

- 10-14 「パフォーマンス・サマリー」コマンド

- 10-15 メトリック・パレットを表示した「パフォーマンス・サマリー」ページ

- 10-16 「ログ構成」タブのAccess Managerログ・レベル

- 10-17 セキュリティ・トークン・サービスのログ・レベル

- 10-18 ログ・ファイルの構成ページ

- 10-19 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ

- 10-20 システムMBeanブラウザと「属性」タブ

- 10-21 コンテキスト・メニューが表示された状態のルーティング・トポロジ

- 11-1 Access Managerの設定

- 11-2 「Access Managerの設定」: 「ロード・バランサ」

- 11-3 「Access Managerの設定」: 「サーバー・エラー・モード」

- 11-4 「Access Managerの設定」: 「SSO」

- 11-5 共通ポリシー評価キャッシュ

- 13-1 「OAM 11G Webゲートの作成」ページ

- 13-2 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ

- 13-3 Webゲートの「検索」コントロールと各作成ボタン

- 13-4 キーの生成

- 14-1 セッション・データとOracle Coherenceのロール

- 14-2 セッション詳細: 「共通設定」ページ

- 14-3 共通構成: 「セッション管理」ページ

- 15-1 Access Manager 11gポリシー・モデル

- 15-2 Access Managerの共有ポリシー・コンポーネント

- 15-3 Access Managerポリシーの構造

- 15-4 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン

- 15-5 例: リソースWebゲートとDCC Webゲートの分離デプロイメント

- 15-6 DCCとWebゲートの一体化

- 15-7 OSSOエージェントとECCを使用したSSOログイン処理

- 16-1 デフォルトのHTTPリソース・タイプ定義

- 16-2 デフォルトのリソース・タイプwl_authen

- 16-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ

- 16-4 「ホスト識別子」ページ

- 16-5 ネイティブのKerberos認証モジュール

- 16-6 ネイティブのLDAP認証モジュール

- 16-7 ネイティブのX509認証モジュール

- 16-8 カスタマイズした認証モジュールのAccess Managerプラグイン

- 16-9 カスタム認証モジュールの作成: 「一般」

- 16-10 ステップの追加とプラグインの関連付け

- 16-11 プラグイン・ベースの認証モジュールの「ステップ」と「詳細」

- 16-12 プラグイン・ベースの認証モジュールの「ステップ編成」

- 16-13 Oracle提供のプラグイン・ベースの認証モジュール

- 16-14 KerberosPlugin

- 16-15 デフォルトのKerberosPluginステップと詳細

- 16-16 デフォルトのKerberosPluginステップと編成

- 16-17 LDAPPlugin

- 16-18 デフォルトのLDAPPluginステップと詳細

- 16-19 LDAPpluginのステップのデフォルト編成

- 16-20 X509Plugin

- 16-21 X509Pluginのデフォルト・ステップと詳細

- 16-22 X509Pluginのステップのデフォルト編成

- 16-23 パスワード・ポリシー検証モジュールのプラグイン

- 16-24 「ステップ編成」: パスワード・ポリシー検証プラグイン

- 16-25 「プラグイン」ページ

- 16-26 「プラグインの詳細」: 選択したプラグインのアクティブ化のステータス

- 16-27 デフォルトのLDAPSchemeページ

- 16-28 パスワード・ポリシー構成ページ

- 16-29 新しい管理者が指定されたデフォルト・ストア

- 16-30 パスワード・ポリシー検証認証モジュールと編成済プラグイン

- 16-31 パスワード・ポリシー検証モジュールのステップ編成

- 16-32 ECC PasswordPolicyValidationSchemeの例

- 16-33 パスワード管理のサーバー・エラー・モード

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

- 17-2 「サマリー」タブ: 生成されたアプリケーション・ドメイン

- 17-3 アプリケーション・ドメインのリソースの検索結果

- 17-4 「認証ポリシー」タブ

- 17-5 「認証ポリシー」ページ: 「リソース」および「レスポンス」

- 17-6 「認可ポリシー」ページ

- 17-7 個々の「認可ポリシー」ページ

- 17-8 個々の「認可ポリシー・リソース」タブ

- 17-9 「トークン発行ポリシー」ページ

- 17-10 新しいアプリケーション・ドメインの「サマリー」ページ

- 17-11 アプリケーション・ドメインの新しい「リソース」(定義)ページ

- 17-12 HTTPリソース、問合せ文字列のリソースURLコントロール

- 17-13 アプリケーション・ドメイン内のリソース定義の検索例

- 17-14 アプリケーション・ドメイン内のリソース定義の検索結果例

- 17-15 アプリケーション・ドメインの「認証ポリシー」ページの例

- 17-16 個々の「認証ポリシー」ページの例

- 17-17 個々の「認可ポリシー」ページの例

- 17-18 「認可ポリシー」ページ

- 17-19 コンソールの認可ポリシー・レスポンス

- 17-20 単純なレスポンスのサンプル

- 17-21 複雑なレスポンスの例

- 17-22 個々の認可ポリシーの「条件」タブ

- 17-23 「条件の追加」ウィンドウ

- 17-24 「認可ポリシー」ページの条件コンテナ

- 17-25 「アイデンティティの追加」ウィンドウ

- 17-26 アイデンティティ条件および詳細

- 17-27 「検索フィルタの追加」のコントロール

- 17-28 アイデンティティ条件の詳細

- 17-29 IP4範囲条件

- 17-30 一時的条件タイプの詳細ページ

- 17-31 属性条件のページ

- 17-32 「属性の追加」ダイアログ

- 17-33 認可ポリシーの「ルール」タブ: 簡易モード

- 17-34 「ルール」タブ: ルール・モードの式

- 18-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性

- 18-2 アクセス・テスターのユーザー操作

- 18-3 アクセス・テスター・コンソール

- 18-4 アクセス・テスター内のサーバー接続パネル

- 18-5 アクセス・テスターの保護されたリソースURIパネル

- 18-6 アクセス・テスターの「ユーザー・アイデンティティ」パネル

- 18-7 テスト・ケースのワークフロー

- 20-1 OpenSSOおよびAccess Managerが含まれる一般的なデプロイメント

- 20-2 「新規OpenSSOエージェント」ページ

- 20-3 拡張されたOpenSSO Webエージェント登録ページ

- 20-4 拡張されたOpenSSO J2EEエージェント登録ページ

- 21-1 「OSSOエージェントの作成」ページ

- 21-2 「OSSOエージェント」ページと「確認」ウィンドウ

- 27-1 「使用可能なサービス」ページ

- 28-1 サービスの詳細をメタデータからロードした場合の「新規アイデンティティ・プロバイダ」ページ

- 28-2 サービスの詳細を手動で入力した場合の「新規アイデンティティ・プロバイダ」ページ

- 28-3 アイデンティティ・プロバイダの検索

- 28-4 アイデンティティ・プロバイダの更新

- 29-1 「Identity Federationサービスの設定」ページ

- 29-2 「フェデレーション設定」ページの「一般」セクション

- 29-3 フェデレーションのプロキシ設定

- 29-4 キーストア設定

- 30-1 FederationScheme

- 30-2 FederationPlugin

- 30-3 FederationPluginの編成

- 30-4 FederationSchemeを使用した認証ポリシーの設定

- 30-5 OIFScheme

- 30-6 OIFMTLDAPPlugin

- 30-7 認可ポリシーの「レスポンス」タブ

- 30-8 フェデレーションのレスポンス属性のAuthZポリシーへの追加

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

- 31-2 OAMトークンを使用したアイデンティティ伝播

- 31-3 アイデンティティ伝播中のプロセス・フロー

- 31-4 アイデンティティ伝播のデプロイメント

- 31-5 アイデンティティ伝播処理

- 31-6 必要なv1.0 WebLogic Server Identity Assertion Provider

- 31-7 IAP-Security Token Serviceの詳細

- 31-8 LDAPプロバイダ: IAP-DSEE

- 31-9 Access Managerに定義されているデフォルト・アイデンティティ・ストア

- 31-10 アイデンティティ伝播のトークン発行ポリシー

- 31-11 IDアサーションの/wssuserエンドポイント

- 31-12 Access Managerに定義されているデフォルト・アイデンティティ・ストア

- 31-13 アイデンティティ伝播のトークン発行ポリシー

- 31-14 IDアサーションの/wss11userエンドポイント

- 32-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート

- 32-2 WS-Security 1.0および1.1ポリシー

- 32-3 「使用可能なサービス」パネル

- 32-4 「セキュリティ・トークン・サービス」ページ

- 34-1 検証テンプレートの検索コントロール

- 34-2 発行テンプレートの検索コントロール

- 34-3 発行テンプレート: 一般詳細とデフォルト

- 34-4 発行プロパティ: ユーザー名トークン・タイプ

- 34-5 発行プロパティ: SAMLトークン・タイプ

- 34-6 「セキュリティ」の詳細: SAMLトークン

- 34-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト

- 34-8 新規検証テンプレート: 「一般」の「認証の詳細」

- 34-9 トークン・マッピング: SAML2 WS-Security検証テンプレート

- 34-10 トークン・マッピング: username-wstrust-validation-template

- 34-11 トークン・マッピング: x509-wss-validation-template

- 34-12 「エンドポイント」ページ

- 34-13 「トークン発行ポリシー」および「条件」

- 34-14 事前定義されたリソース・タイプ: TokenServiceRP

- 34-15 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP

- 34-16 新規カスタム・トークン・ページ

- 34-17 カスタム・トークン定義: 電子メール

- 34-18 カスタム・トークン検索ページおよびコントロール

- 34-19 一般的な詳細: email-wstrust-valid-temp

- 34-20 トークン・マッピング: email-wstrust-valid-temp

- 34-21 一般的な詳細: email-issuance-temp

- 34-22 発行プロパティ: email-issuance-temp

- 35-1 「新規リクエスタ・パートナ」ページ

- 35-2 「新規リライイング・パーティ・パートナ」ページ

- 35-3 定義済のリクエスタ・パートナ

- 35-4 パートナの検索コントロール

- 35-5 リクエスタ・プロファイル: 一般

- 35-6 リクエスタ・プロファイル: トークンと属性

- 35-7 リライイング・パーティ・プロファイルの「トークンと属性」

- 35-8 トークンと属性: 発行局

- 35-9 発行局プロファイル: 「トークン・マッピング」タブ

- 35-10 プロファイルの検索ページ: リクエスタ

- 37-1 初回時のデバイス/アプリケーション登録と認証プロセス

- 37-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント

- 37-3 資格証明ストアに有効なアクセス・トークンを持つモバイルSSOエージェント

- 37-4 資格証明ストアに有効なトークンを持たないモバイルSSOエージェント

- 37-5 RESTを使用するユーザー認証

- 37-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証

- 37-7 ローカル・アカウントを持つユーザーが返された場合の認証

- 37-8 ローカル・アカウントのない新しいユーザーの認証

- 37-9 OAuthアイデンティティ・プロバイダによるユーザー認証

- 37-10 Access Managerによるユーザーの認証

- 37-11 ユーザーのローカル認証

- 41-1 エンドツーエンド・アイデンティティ・コンテキスト・プロセス

- 41-2 エンドツーエンド・アイデンティティ・コンテキスト・プロセスのコンポーネント

- 41-3 アイデンティティ・コンテキストのプロセス・フロー

- 41-4 OAM認証プロバイダの構成

- 44-1 JBossアプリケーション・サーバーにデプロイされた様々なクライアント

- 44-2 Oracle HTTP Server Webgateを使用してデプロイされたJBossエージェント

- 44-3 サンプル統合トポロジ

- 45-1 Windowsの偽装のための信頼できるユーザー・アカウントの設定

- 45-2 Windowsの偽装での信頼できるユーザーの権限の構成

- 45-3 偽装モジュールの登録

- 45-4 イベント・ビューアの設定の確認

- 45-5 偽装認証

- C-1 OAMサーバーとWebgateの通信チャネル

- D-1 WebLogic管理コンソールでのIAMSuiteAgent設定

- D-2 IAMSuiteAgent登録

- D-3 IAMSuiteAgentによって保護されるリソース

- D-4 IAMSuite認証ポリシー: OAM管理コンソール・ポリシー

- D-5 保護されるより高度なポリシー: 認証, LDAPスキーム

- D-6 保護されるより低度なポリシー: 認証, OIMスキーム

- D-7 パブリック・ポリシー: 認証, Anonymousスキーム

- D-8 IAM Suite認可ポリシー

- D-9 IAM Suiteのトークン発行ポリシーとリソースURL

- D-10 生成される認証モジュール: OpenSSOAgentAuthPlugin

- D-11 生成されるホスト識別子: OpenSSOAgent

- D-12 生成されるアプリケーション・ドメイン: OpenSSOAgent

- D-13 アプリケーション・ドメイン・リソース: OpenSSOAgent

- D-14 生成される認証ポリシー: OpenSSOAgentアプリケーション・ドメイン

- D-15 生成される認可ポリシー: OpenSSOAgentアプリケーション・ドメイン

- D-16 移行されるユーザー・アイデンティティ・ストア: OpenSSO

- D-17 移行されるエージェント: OpenSSO

- D-18 移行される認証モジュール: OpenSSO

- D-19 移行されるホスト識別子: OpenSSO

- D-20 移行されるアプリケーション・ドメイン: OpenSSO

- D-21 移行されるリソース: OpenSSO

- D-22 移行される認証ポリシー: OpenSSO

- D-23 移行される認可ポリシー2 条件: OpenSSO

- D-24 移行される認可ポリシー2: IP条件詳細

表一覧

- 1-1 Oracle Access Managementのインストール後のタスク

- 1-2 デプロイメント・タイプ

- 1-3 概要: Access Manager 11.1.2

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

- 1-5 Security Token Serviceの用語と概要

- 1-6 Security Token Serviceの用語

- 1-7 Oracle Security Token Service 11gのインフラストラクチャ

- 1-8 統合されたOracle Web Services Manager

- 2-1 LDAPグループから管理者へのロール・マッピング

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

- 2-3 機能タブと説明

- 2-4 ツール・バーのコマンド・ボタン

- 2-5 「表示」メニュー・コマンドの説明

- 2-6 システム構成、「アクション」メニュー、コマンドの説明

- 2-7 開いているページのコントロール

- 2-8 ページ要素と説明

- 2-9 選択タスクとコントロール

- 3-1 「システム構成」: 「共通構成」セクション

- 3-2 共通のサービス

- 3-3 共通設定

- 3-4 共通のコヒーレンス設定

- 4-1 Oracle Access Managementのデータソース

- 4-2 Oracle Access Managementのサービスのデータソース

- 4-3 11.1.2 キーと格納

- 4-4 ユーザー・アイデンティティ・ストアの要素

- 5-1 サーバーの再起動が必要になる条件

- 5-2 OAMサーバー・インスタンス設定

- 5-3 個別のOAMサーバーのOAMプロキシ設定

- 5-4 個別のOAMサーバーのデフォルトのCoherence設定

- 6-1 ロギング・ファイル

- 6-2 ロギングのデフォルト

- 6-3 Oracle Access Managementのサーバー側コンポーネントのログ出力

- 6-4 Oracle Access Management共有サービス・エンジン・コンポーネントのログ出力

- 6-5 Oracle Access Management Foundation APIコンポーネントのログ出力

- 6-6 ODLレベルとJavaレベルの対応

- 6-7 セキュリティ・トークン・サービスとIdentity Federationのログ出力

- 7-1 ロギング・レベル

- 7-2 コンポーネントのログ構成ファイル名

- 7-3 ログ・ライター

- 7-4 最初の複合リストのグローバル・パラメータ

- 7-5 ロギングがアクティブかどうかを決定する要因

- 7-6 必須のログ構成ファイル・パラメータ

- 7-7 ログ・データ・ファイル構成パラメータ

- 7-8 モジュール固有ロギングしきい値に構成できるParamNameの値

- 8-1 Oracle Business Intelligence Enterprise EditionのOAMに関するレポート

- 8-1 Access Manager管理監査イベント

- 8-3 Access Managerランタイム監査イベント

- 8-4 Identity Federationの監査イベントのカテゴリ

- 8-5 Identity Federationのセッション管理イベント

- 8-6 Identity Federationのプロトコル・フロー・イベント

- 8-7 Identity Federationのサーバー構成

- 8-8 Identity Federationのセキュリティ・イベント

- 8-9 セキュリティ・トークン・サービスの構成管理操作

- 8-10 セキュリティ・トークン・サービス固有のランタイム・イベント

- 8-11 監査構成要素

- 9-1 OAMサーバー・メトリック: 「サーバー・プロセス概要」タブ

- 9-2 OAMサーバー・メトリック: 「セッション操作」

- 9-3 OAMサーバー・メトリック: 「サーバー操作」タブ

- 9-4 OAMプロキシ・メトリック

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

- 9-6 OpenSSOプロキシ・サーバー・イベント

- 9-7 OpenSSOプロキシ・メトリック: サーバー

- 9-8 OpenSSOプロキシ・メトリック: エージェント

- 10-1 「ファーム」ページのセクション

- 10-2 選択したノードとターゲットに対して表示されるページ

- 10-3 Fusion Middleware Controlの「パフォーマンス概要」のサマリー

- 10-4 Access Managerコンポーネント・メトリック

- 10-5 STSコンポーネント固有のメトリック

- 10-6 「パフォーマンス・サマリー」ページのステータスとコントロール

- 10-7 OAMで使用可能なログとFusion Middleware Controlの機能

- 10-8 「ログ構成」ページの「ログ・レベル」タブ

- 10-9 ログ・ファイル要素

- 10-10 Fusion Middleware ControlのOAMログ・メッセージ検索コントロール

- 10-11 システムMBeanブラウザ

- 10-12 Access Managerとセキュリティ・トークン・サービスがデプロイするMBeans

- 10-13 システムMBeanブラウザ

- 10-14 ファーム・トポロジ

- 11-1 Access Managerの設定

- 11-2 「Access Managerの設定」: 「ロード・バランサ」

- 11-3 サーバー・エラー・モード

- 11-4 エラーのトリガー条件、モード、メッセージ・コード

- 11-5 外部エラー・コード、トリガー条件、推奨メッセージ

- 11-6 「Access Managerの設定」: 「SSO」

- 11-7 サマリー: 簡易モードと証明書モード

- 11-8 サーバー共通のOAMプロキシ・セキュア通信の設定

- 11-9 ポリシー評価キャッシュ

- 12-1 エージェント・タイプ

- 12-2 エージェントの登録とSSOサポート

- 12-3 Access Managerの実行時の処理の概要

- 12-4 エージェント登録時に生成されるキーとポリシー

- 12-5 エージェント登録に関連付けられるアーティファクト

- 12-6 生成されたアーティファクトのコピー

- 12-7 リモート登録の方法

- 12-8 リモート登録でサポートされない機能

- 12-9 エージェント登録および構成の更新アーティファクト

- 13-1 11gおよび10g OAMエージェントの作成ページ上の要素

- 13-2 ユーザー定義のWebgateパラメータ

- 13-3 拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素

- 13-4 OAMエージェントの「検索」コントロール

- 13-5 oamreg内で設定する環境変数

- 13-6 リモート登録コマンドの引数: モード

- 13-7 リモート登録コマンドのサンプル

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

- 13-9 OAMエージェント用のリモート登録リクエスト・テンプレート

- 13-10 拡張されたOAMエージェントのリモート登録リクエスト内の要素

- 13-11 リモート登録に必要な変数

- 13-12 帯域内の管理者が帯域外の管理者に戻すファイル

- 13-13 リモート・エージェント更新のモードと入力ファイル

- 13-14 相違点: OAMエージェント更新と登録リクエスト

- 14-1 共通セッション設定

- 14-2 セッション管理のコントロールと結果表

- 15-1 概要: SSOのコンポーネント

- 15-2 SSOの実装の概要

- 15-3 Access Managerのグローバルな共有ポリシー・コンポーネント

- 15-4 Access Managerのポリシー・コンポーネント

- 15-5 条件タイプ

- 15-6 Access Managerで保護されたリソースへのログイン処理

- 15-7 DCCデプロイメントのサポート

- 15-8 SSO Cookie

- 16-1 Access Managerのリソース・タイプの10gとの比較

- 16-2 リソース・タイプの定義

- 16-3 ホスト識別子の例

- 16-4 ホスト識別子の定義

- 16-5 DCCとECCの比較

- 16-6 ネイティブ認証モジュール

- 16-7 ネイティブのKerberos認証モジュールの定義

- 16-8 ネイティブのLDAP認証モジュールの定義

- 16-9 X509認証モジュールの定義

- 16-10 単純フォーム認証とマルチステップ認証

- 16-11 「一般」タブ

- 16-12 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション

- 16-13 各種プラグインのパラメータの詳細

- 16-14 「ステップ編成」サブタブ

- 16-15 X509の「ステップの詳細」(KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)

- 16-16 カスタム・プラグインの管理アクション

- 16-17 プラグイン・ステータス表

- 16-18 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例

- 16-19 認証スキームの定義

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

- 16-21 事前構成済スキームのチャレンジ・パラメータ

- 16-22 認証スキームのユーザー定義チャレンジ・パラメータ

- 16-23 10g/11g暗号化Cookieのチャレンジ・パラメータ

- 16-24 資格証明コレクタのパスワード・ページ

- 16-25 パスワード管理フォームと機能

- 16-26 パスワード・ポリシーの要素

- 16-27 認証用の資格証明コレクタと関連フォームの指定

- 16-28 LDAPプロバイダ用のオラクル社提供LDIFのロケーション

- 16-29 パスワード・ポリシーのキー・パスワード属性

- 16-30 ユーザー・パスワード・ステップの詳細

- 17-1 リソース定義の要素

- 17-2 HTTPリソースのサンプルのURL値

- 17-3 リソースURLパターンでサポートされるワイルドカード(優先順)

- 17-4 サンプル・リソースURL

- 17-5 リクエストされたURLのパターン一致

- 17-6 問合せ文字列一致: 例

- 17-7 リソース評価の結果

- 17-8 アプリケーション・ドメイン内のリソースの検索要素

- 17-9 認証ポリシーの要素および説明

- 17-10 認可ポリシーの要素および説明

- 17-11 レスポンス要素

- 17-12 シングル・サインオンのネームスペース・リクエスト変数

- 17-13 シングル・サインオンのネームスペース・セッション変数

- 17-14 ネームスペース・ユーザー変数

- 17-15 単純なレスポンスおよび説明

- 17-16 複雑なレスポンス

- 17-17 新しいOSSOのインストール: 保護されたポリシー・レスポンス(ヘッダー)

- 17-18 認可ポリシーの「条件」タブ

- 17-19 「条件の追加」ウィンドウの要素

- 17-20 「アイデンティティの追加」の要素

- 17-21 「検索フィルタの追加」の要素

- 17-22 Access ManagerのLDAP検索フィルタの例

- 17-23 一時的条件の詳細

- 17-24 属性タイプ条件を必要とするアクセス条件

- 17-25 属性条件の要素

- 17-26 組込みリクエストの属性名

- 17-27 組込みセッションの属性名

- 17-28 属性条件のデータ(条件の集約)

- 17-29 認可ポリシーの「ルール」の要素

- 17-30 式モードの「ルール」タブ

- 17-31 認可ルールの式の演算子

- 17-32 リモート・ポリシー管理のモード、テンプレートおよびフラグ

- 17-33 リモート管理テンプレートの要素

- 18-1 ユーザー操作: テスター・コンソール・モードとコマンドライン・モードの操作

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

- 18-3 アクセス・テスターのコンソール・パネル

- 18-4 アクセス・テスター・パネルのコマンド・ボタン

- 18-5 その他のアクセス・テスター・ボタン

- 18-6 アクセス・テスターのメニュー

- 18-7 接続パネルの情報

- 18-8 保護リソースURIパネルのフィールドとコントロール

- 18-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール

- 18-10 アクセス・テスターの取得リクエスト・オプション

- 18-11 スクリプト作成コマンド

- 18-12 テスト・スクリプト制御パラメータ

- 18-13 テスト・スクリプト実行コマンド

- 18-14 統計ドキュメントの不一致結果の理由

- 19-1 集中ログアウトの状況

- 19-2 登録後のログアウトの詳細(ObAccessClient.xml)

- 20-1 機能: Access Managerを使用するOpenSSOエージェント

- 20-2 OpenSSOポリシー移行

- 20-3 OpenSSOのAccess Managerへの依存

- 20-4 Access ManagerによるOpenSSOの処理

- 20-5 「新規OpenSSOエージェント」ページの要素

- 20-6 OpenSSOアーティファクトの再配置

- 20-7 拡張されたOpenSSOエージェント登録の要素

- 20-8 リモート登録用のOpenSSOリクエスト・ファイル

- 20-9 OpenSSOエージェントのリモート登録リクエスト

- 20-10 J2EEリクエスト・ファイルのプロパティ・ファイルに対するマッピング

- 20-11 Webリクエスト・ファイルのプロパティ・ファイルに対するマッピング

- 20-12 OpenSSOリモート登録とリモート更新の相違点

- 20-13 このガイドに記載されたOpenSSOのその他の情報

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

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

- 21-3 「OSSOエージェントの作成」ページの要素

- 21-4 OSSOアーティファクトの再配置

- 21-5 展開されたOSSOエージェントの要素

- 21-6 リモート登録用のOpenSSOリクエスト・ファイル

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

- 21-8 OSSOリモート登録とリモート更新の相違点

- 21-9 このガイドに記載されたOSSOのその他の情報

- 22-1 10g Webgateのインストールの比較

- 22-2 比較: Access Manager 11g対10g

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

- 22-4 Access Manager 11gで使用する10g Webgateのインストールの準備

- 22-5 end_urlパラメータ指定の例

- 25-1 IIS 7 Webgate Windows Server 2008

- 27-1 サポートされているプロトコル

- 27-2 Oracle Access ManagementコンソールのIdentity Federation構成

- 27-3 Identity FederationとAccess Manager 11gリリース2 (11.1.2)の統合

- 28-1 アイデンティティ・プロバイダ・パートナの設定

- 28-2 Google OpenIDパートナの属性

- 28-3 Yahoo OpenIDパートナの属性

- 28-4 IdPのプロバイダ検索で使用される要素

- 29-1 コンソールの「フェデレーション設定」

- 29-2 フェデレーションの一般設定

- 29-3 フェデレーションのプロキシ設定

- 29-4 フェデレーションのキーストア設定

- 30-1 FederationSchemeの要素の定義

- 30-2 FederationPluginのステップ

- 30-3 FederationPluginの編成

- 30-4 OIFSchemeの定義

- 30-5 OIFMTLDAPPluginのステップ

- 30-6 ポリシー・レスポンスの要素

- 32-1 セキュリティ・トークン・サービスの設定

- 32-2 WSS KerberosポリシーのためのOracle WSM以外のクライアントの構成

- 33-1 実行時に使用されるセキュリティ・トークン・サービスの公開鍵

- 33-2 Access Managerとセキュリティ・トークン・サービスのキーストア

- 33-3 キーストアMbean

- 33-4 WS-Trust通信のパートナ・キー

- 33-5 セキュリティ・トークン・サービスの証明書検証の条件

- 33-6 証明書検証が成功するための要件

- 34-1 検証テンプレートの検索

- 34-2 発行テンプレートの要件

- 34-3 発行テンプレート: 一般詳細

- 34-4 発行プロパティ: ユーザー名トークン・タイプ

- 34-5 発行プロパティ: SAMLトークン・タイプ

- 34-6 「セキュリティ」の詳細: SAMLトークン

- 34-7 発行テンプレート: 属性マッピング、SAMLトークン

- 34-8 検証テンプレートのプロトコル

- 34-9 新規検証テンプレート: 一般詳細

- 34-10 新規検証テンプレート: 認証の詳細

- 34-11 新規検証テンプレート: トークン・マッピング

- 34-12 「エンドポイント」ページ

- 34-13 「条件」タブ: トークン発行ポリシー

- 34-14 新規カスタム・トークン要素

- 34-15 カスタム・トークン検索要素およびコントロール

- 35-1 セキュリティ・トークン・サービス・パートナ

- 35-2 セキュリティ・トークン・サービス・クライアント

- 35-3 セキュリティ・トークン・サービス・パートナ・エントリ

- 35-4 セキュリティ・トークン・サービス・パートナ・プロファイルのデータ

- 35-5 パートナ・タイプのパートナ要素

- 35-6 セキュリティ・トークン・サービス・パートナの要素

- 35-7 プロファイル: 一般

- 35-8 リクエスタ・プロファイル: トークンと属性

- 35-9 リライイング・パーティ・プロファイルの要件

- 35-10 「トークンと属性」要素: 発行局

- 35-11 発行局の「トークン・マッピング」要素

- 37-1 インストールしたコンパニオン・サービスに基づくMobile and Socialの機能

- 37-2 構成済のモバイルおよび非モバイル認証サービス・プロバイダ

- 37-3 Mobile and Social Mobileサービス・クライアントSDKのJava機能およびiOS機能

- 37-4 Mobile and Socialサーバーのトークン要件

- 37-5 Mobile and Socialがネイティブにサポートするアイデンティティ・プロバイダ

- 38-1 Access Manager認証サービス・プロバイダのデフォルト属性

- 38-2 認証サービス・プロバイダのWebゲート・エージェントのデフォルト属性

- 38-3 JWT認証サービス・プロバイダのデフォルト属性

- 38-4 事前構成済の認証サービス・プロバイダ

- 38-1 Access Manager認可サービス・プロバイダのデフォルト属性

- 38-6 認可サービス・プロバイダのWebゲート・エージェントのデフォルト属性

- 38-7 ユーザー・プロファイル・サービス・プロバイダのデフォルト属性の名前と値

- 38-8 認証サービス・プロファイルのデフォルトの一般プロパティ

- 38-9 トークン・サポートおよびURIカテゴリ情報のデフォルトのプロパティ

- 38-10 認可サービス・プロファイルのデフォルトの一般プロパティ

- 38-11 ユーザー・プロファイル・サービス・プロファイルのデフォルトの一般プロパティ

- 38-12 セキュリティ・ハンドラ・プラグインの一般プロパティ

- 38-13 アプリケーション・プロファイルの一般プロパティ

- 38-14 サービス・ドメインの一般プロパティ

- 38-15 アプリケーション・プロファイル選択のプロパティ

- 38-16 サービス・プロファイル選択のプロパティ

- 38-17 ユーザー・プロファイル・サービス保護のプロパティ

- 38-18 認可サービス保護のプロパティ

- 38-19 Access Manager簡易モード構成の必須属性

- 38-20 Mobile and SocialでサポートされるOAAMポリシー

- 38-21 OAAMとMobile and Socialの用語の対応

- 39-1 OpenIDプロトコルの属性

- 39-2 OAuthプロトコルの属性

- 39-3 Googleが返すユーザー属性

- 39-4 Yahooが返すユーザー属性

- 39-5 サービス・プロバイダ・インタフェースのプロパティ

- 40-1 Oracle Access Manager 11gR1 PS1認証サービス・プロバイダ用の属性の設定

- 41-1 アイデンティティ・コンテキスト・スキーマ属性

- 41-2 アイデンティティ・コンテキスト操作のマッピング

- 42-1 RSA機能に対するAccess Managerのサポート

- 42-2 サポートされないRSA機能

- 42-3 インストールおよび構成のガイドライン

- 43-1 サンプル名

- 44-1 JBossエージェントの構成

- 45-1 Access Managerのコンポーネントの要件

- 45-2 この統合のためのMicrosoftの要件

- 45-3 Microsoft SharePoint Server 2010の「Webアプリケーションの作成: {0}」オプション

- 45-4 SharePoint Server 2010のサイト・コレクションをホストするWebアプリケーションの作成

- A-1 addOAMSSOProviderコマンドライン引数

- B-1 ローカライズされたメッセージの言語

- C-1 importcertコマンドの構文

- D-1 IAMSuiteAgentの11gおよび10g Webgateとの比較

Oracle® Fusion Middleware

Oracle Access Management管理者ガイド

11gリリース2 (11.1.2)

B69533-02(原本部品番号:E27239-03)

2012年11月

Oracle Access ManagementサービスのAccess Manager、Identity Federation、セキュリティ・トークン・サービス、Mobile and Socialに関する共通設定、エージェント、シングル・サインオン・ポリシーおよびトークンの管理方法について説明します。

Oracle Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2)

B69533-02

Copyright (C) 2000, 2012, Oracle and/or its affiliates.All rights reserved.

原本著者: Gail Flanegin

原本主協力者:  Michael Teger, Vinaye Misra, Kevin Kessler

原本協力者:  Vadim Lander, Vamsi Motokuru, Damien Carru, Peter Povinec, Weifang Xie, Satish Madawand, Neelima Jadhav, Charles Wesley, Harshal X Shaw, Jeremy Banford, Rey Ong, Ramana Turlapati, Deepak Ramakrishnan, David Goldsmith, Vishal Parashar, Carlos Subi, Patricia Fuzesy

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

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 Managementを使用した日々の管理やポリシー構成のタスクについての情報を提供します。

対象読者

このマニュアルは、以下の概念に詳しい管理者を対象としています。

- 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リリース2(11.1.2)のドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Access Management 11gリリース2(11.1.2)リリース・ノート

- 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』—初回のAccess Manager 11gデプロイメントでのOracle Universal InstallerおよびWebLogic構成ウィザードの使用法について説明します。Access Manager用11g Webゲートのインストールについても解説します。

- 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』—Access Manager、セキュリティ・トークン・サービス、Identity Federation、Mobile and Socialおよびアイデンティティ・コンテキストの構成とポリシーの管理方法について説明します。

- 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』—カスタム・アプリケーションおよびプラグインを諸機能にプラグラムで記述する方法や非Webベースのリソースを保護するカスタム・アクセス・クライアントを作成する方法について説明します。

- 『Oracle Fusion Middleware Java EEアップグレード・ガイド』—10gで使用可能なJava EE環境のタイプ、およびこれらの環境をOracle Fusion Middleware 11gにアップグレードする手順についての情報です。

- Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

- 『Oracle Fusion Middleware管理者ガイド』—保護されたOracle Fusion Middleware環境の管理方法、たとえばポートの変更やアプリケーションのデプロイ、Oracle Fusion Middlewareのバックアップおよびリカバリの方法について説明します。また、このガイドではテスト環境から本番環境へのデータの移行方法についても説明します。

- 『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』—デプロイメントを段階的に示すガイドです。

- 『Oracle Fusion Middleware高可用性ガイド』—管理者や開発者など、高可用性の要件でOracle Fusion Middlewareをデプロイおよび管理することを役割としている方を対象に、高可用性の概要および管理と構成手順について説明します。

- Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス—「インフラストラクチャ・セキュリティのカスタムWLSTコマンド」の章に、カスタマイズされたOracle Access Managementコマンドに関する項が記載されています。

- 『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』—Webサービスを管理および保護する方法について説明します。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドの最新情報

この項では、このマニュアルの変更内容および更新内容について説明します。詳細は次の項を参照してください。

- 2012年11月改訂

- 2012年8月改訂

- Oracle Access Management 11.1.2.0.0での製品の拡張機能

- 11.1.2で変更された製品およびコンポーネントの名前

2012年11月改訂

次の情報を追加または更新しました。

- 第1章: 「システム要件と動作保証情報」を追加しました。

- 以前の「第2章」は削除しました(重複していたため)。このため、以前の章番を変更しました。

- 第3章: パスワード・ポリシーは、ECCに焦点を変更して、その他の認証の詳細とともに第16章に移動しました。

- 第6章: ログ出力の説明を次の項目に追加しました。

- 表6-3「Oracle Access Managementのサーバー側コンポーネントのログ出力」

- 表6-4「Oracle Access Management共有サービス・エンジン・コンポーネントのログ出力」

- 表6-5「Oracle Access Management Foundation APIコンポーネントのログ出力」

- 第12章: 11g OAMエージェント(Webgateおよびアクセス・クライアント)に焦点を変更しました。

- 第13章:

- 11g OAMエージェントのコンソールおよびリモート登録をまとめました。

- 「DCC対応の11g Webgateと認証ポリシーの構成」を第16章に移動しました。

- 第15章:

- 「Access Manager資格証明コレクションおよびログインの概要」を追加しました。

- 第16章: 認証の詳細をその他の共有ポリシー・コンポーネントとともに再配置しました。

- 11g OAMエージェントのコンソールおよびリモート登録をまとめました。

- 「Access Manager資格証明コレクションおよびログインの概要」を追加しました。

- 第3章から「グローバル・パスワード・ポリシー」を移動して、焦点を変更しました。

- 第3章から「DCC対応の11g Webgateと認証ポリシーの構成」を移動しました。

- 第17章:

- 「ポリシーおよびアプリケーション・ドメインのリモート管理の理解」を追加しました。

- 「ポリシーおよびアプリケーション・ドメインのリモート管理」を追加しました。

- 第20章: OpenSSOエージェント登録と管理の詳細をこの章に再配置しました。

- 第20章: OSSOエージェント登録と管理の詳細をこの章に再配置しました。

- 第22章: Access Managerを使用したコンソールおよびリモート登録、更新およびログアウトを含めるために、10g OAMエージェントの詳細を拡充しました。

- 付録A: ログアウト構成の詳細に関連するように再配置しました。

2012年8月改訂

このマニュアルは、報告された問題に対応するために更新されました。全体的な更新内容には、体裁の変更と画面の更新が含まれます。

関連項目:

このリリースでは、次の項目が新規追加または更新されています。

- Oracle Internet DirectoryのサブスクライバDN情報の取得方法の詳細: 表17-17「新しいOSSOのインストール: 保護されたポリシー・レスポンス(ヘッダー)」。

- 表16-13「各種プラグインのパラメータの詳細」

- フェデレーションにOpenID 2.0 IdPパートナを定義する方法の詳細: 第28.3.1項「フェデレーション・アイデンティティ・プロバイダの作成」。

Oracle Access Management 11.1.2.0.0での製品の拡張機能

Oracle Access Management 11.1.2.0.0では、次の各項で説明する、新機能および拡張機能が提供されています。

- アクセス管理サービス

- アクセス・テスター

- 属性タイプ認可条件

- 非推奨

- デタッチされた資格証明コレクション

- 動的マルチファクタ/マルチステップ認証

- アイデンティティ・コンテキスト

- サード・パーティ製品との統合

- アイデンティティ条件でのLDAP検索フィルタ

- SubjectAltName拡張データの利用/複数のOCSPエンドポイントとの統合

- Mobile and Social

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

- OpenSSOのサポート

- パスワード・ポリシー管理

- リソース定義パターンでの問合せ文字列の名前と値のパラメータ

- 非ブラウザ対応WebgateのTokenServiceRPリソース・タイプ

- RESTfulサービス

- 共有秘密鍵: アクセス・クライアントとソフトウェア開発キットの拡張

- Mobile and Socialのトークン発行ポリシー

- パフォーマンスのチューニング

- ユーザー定義パラメータ: 11g Webゲート

アクセス管理サービス

以前の独立したOracle Identity Managementのアクセス製品は、Oracle Access Managementという1つの製品に統合されました。

関連項目:

- 第1章「Oracle Access Managementの概要」

- 第IV部「Access Managerの設定とエージェントの管理」

- 第VII部: Oracle Access ManagementのIdentity Federationの管理

- 第IX部「Oracle Access Management Mobile and Socialの管理」

- 第X部「アイデンティティ・コンテキストの使用」

アクセス・テスター

アクセス・テスターでは、プール内の接続を検証し、キャッシュ・フラッシュ・リクエストにアウト・オブ・バウンド接続を使用することなく、確立済の接続経由でキャッシュ・フラッシュ・リクエスト(SYNC_INFO)を送信できます。

関連項目:

第18章「アクセス・テスターを使用した接続性とポリシーの検証」

属性タイプ認可条件

認可条件によって、動的なセキュリティ・ポリシーを実装できるようになり、この結果としてOracle Access Managementコンソールの「ポリシー構成」インタフェースに変更を加えることができます。

- 認可条件: 以前の制約クラスは、条件タイプとして名前が変更されます。条件には、許可または拒否の指定は含まれていませんが、新しいルールでは、許可または拒否のアクセス・オプションを指定します。

関連項目:

「認可ポリシー・ルールおよび条件の概要」

- 新しい条件タイプ: 属性。

関連項目:

「属性条件について」

- ポリシーで「暗黙的な制約の使用」オプションを使用している場合は置換されます。これにより、特定の条件タイプをインスタンス化することで作成し、ルールを選択することが可能になります。

関連項目:

「認可ポリシー・ルールおよび条件の概要」

非推奨

標準認証モジュール(LDAP、KerberosおよびX509)は、今後のリリースで非推奨の対象になります。標準認可モジュールではなく、ネイティブまたはカスタム・プラグインを使用することをお薦めします。

関連項目:

- 表16-9 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

- カスタム認証プラグインを作成する場合は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

デタッチされた資格証明コレクション

外部資格証明コレクションは、11g Webgate(OAMエージェント)の追加機能です。これは、動的なセキュア・マルチファクタ/マルチステップ認証で必要になります。11g Webgateは、DCCとして使用するように簡単に有効化できます。また、OAMサーバーの埋込み資格証明コレクタ(ECC)を引き続き使用することもできます。

関連項目:

「DCC対応の11g Webgateと認証ポリシーの構成」

動的マルチファクタ/マルチステップ認証

マルチファクタ認証では、ログイン・プロセスで情報をバックエンド認証スキームに数回送信するためにカスタム認証プラグインが必要です。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

関連項目:

- Oracle Fusion Middleware Oracle Access Management開発者ガイド

アイデンティティ・コンテキスト

アイデンティティ・コンテキストにより、Oracle Access Managementプラットフォームに組み込まれているコンテキストに対応したポリシー管理および認可機能を活用できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールおよびグループ)とともに、認証中および認可中に確立される動的データ(強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。

関連項目:

第41章「アイデンティティ・コンテキストの使用」

サード・パーティ製品との統合

Access Managerをサード・パーティ製品に統合する方法の詳細は、以前の『Oracle Fusion Middleware Oracle Access Manager統合ガイド』からこのマニュアルに移動しています。次の統合がサポートされています。

関連項目:

第XI部: 他の製品とAccess Managerとの統合

- 第42章「RSA SecurID認証とAccess Managerとの統合」

- 第43章「Windowsネイティブ認証のためのAccess Managerの構成」

- 第44章「JBossとAccess Managerの統合」

- 第45章「Microsoft SharePoint Server 2010とAccess Managerの統合」

アイデンティティ条件でのLDAP検索フィルタ

Access Manager認証条件では、アイデンティティの許可または拒否の指定で、ユーザー、グループおよびLDAP検索フィルタのリストを使用できます。LDAP検索フィルタによって、対象アイデンティティの移入を簡単に指定できます。アイデンティティ・ストア(ディレクトリ・サーバー)でグループを再編成したり、新しいグループを作成する必要はありません。これにより、Access Manager 11gをOracle Access Manager 10gと同等にすることができます。

関連項目:

「アイデンティティ条件でのLDAP検索フィルタのサポートについて」

SubjectAltName拡張データの利用/複数のOCSPエンドポイントとの統合

Access ManagerのPIV(Personal Identity Verification)カード(米国連邦政府のスマート・カード)サポートは、SubjectaltNameでFASC-NおよびEDIPI属性を使用して、X.509認証の間にユーザーをマップするために使用するものです。複数のOCSPプロバイダはサポートされませんが、OCSP Gatewayを使用するか、OSDT OCSP APIを使用するカスタム認証プラグインを作成することで、複数のOCSPプロバイダに対する検証を行うことができます。

関連項目:

- 「SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合」

Mobile and Social

Mobile and Socialは、保護されているリソースへのアクセスを必要とするユーザーと、それらのリソースを保護するバックエンドのOracle Access ManagementサービスとOracle Identity Managementサービスの間の橋渡しの役割を果たします。Mobile and Socialサービスのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアを更新することなく、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます。

関連項目:

第IX部「Oracle Access Management Mobile and Socialの管理」

複数のアイデンティティ・ストアのサポート

管理者はAccess Managerに複数のユーザー・アイデンティティ・ストアをインストールできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。各認証モジュール(または認証手順内のプラグイン)は、特定のユーザー・アイデンティティ・ストアを使用するように構成できます。

関連項目:

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

- 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

OpenSSOのサポート

Access Managerでは、WebまたはJ2EEコンテナにデプロイされたWebおよびJavaエージェントをサポートします。各OpenSSOエージェントは、アプリケーションをホストするコンテナ(Oracle WebLogic Server、JBoss、Apacheなど)にプラグインされるフィルタです。

Access Managerでは、OpenSSOエージェントによって保護されているリソースへのリクエストを処理するためのOpenSSOプロキシを提供します。オラクル社提供のOpenSSOプロキシによって、エージェントとOAMサーバー間の通信を確立することで、OpenSSOエージェントに保護されたアプリケーションへのシングル・サインオンが容易になります。

関連項目:

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

パスワード・ポリシー管理

Access Managerでは、Oracle Access Managementコンソールを使用してパスワード・ポリシーを管理できます。パスワード・ポリシー検証モジュールを実装すると、グローバル・パスワード・ポリシーがAccess Managerユーザーに適用されます。パスワード・ポリシーはポリシー・ストア内に格納され、Access Managerで保護されたすべてのリソースに適用されます。

関連項目:

- 「グローバル・パスワード・ポリシーの管理」

- 「DCC対応の11g Webgateと認証ポリシーの構成」

リソース定義パターンでの問合せ文字列の名前と値のパラメータ

ポリシー・モデルでは、リソース定義パターンで問合せ文字列の名前と値のパラメータがサポートされます。

関連項目:

- 「リソース定義の問合せ文字列の名前と値のパラメータについて」

非ブラウザ対応WebgateのTokenServiceRPリソース・タイプ

TokenServiceRPタイプのリソースは、トークン・サービス・リライイング・パーティ用であり、これに基づいています(Identity Connectなどの非ブラウザ・クライアントに必要です)。

関連項目:

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

RESTfulサービス

Oracle Access Managementでは、プログラミングによるRESTfulサービスがサポートされています。

関連項目:

Oracle Fusion Middleware Oracle Access Management開発者ガイド

共有秘密鍵: アクセス・クライアントとソフトウェア開発キットの拡張

Access Manager 11g Access Software Developer Kitを使用して開発されたカスタム・アクセス・クライアントでは、エージェント(Webgateまたはアクセス・クライアント)ごとに11g共有秘密鍵のセキュリティ機能がサポートされます。各エージェントには、アクセス・クライアントとOAMサーバー間で、ホストベースのアクセス・クライアント専用OAMAuthnCookieの暗号化および復号化を行うために共有される独自の秘密鍵があります。1つのアクセス・クライアントのセキュリティが破られた場合も、影響はその特定のアクセス・クライアントに限定され、他のアクセス・クライアントには影響しません。

注意:

既存の10g ASDKユーザーには影響はありません。Oblixクラスのラッパーは、10gモードで透過的にアクセス・クライアントのインスタンスを作成するように修正できます。ただし、11g互換モードで実行するには、Oracle Java APIの使用が必要になります。

Access Manager 11gのPure Java ASDKはOracle Java API (oracle.security.am.asdkパッケージ内)およびOblix Java API (com.oblix.accessパッケージ)の両方を提供します。Access Manager 11g Pure Javaアクセス・クライアント:

- Oracle Java APIおよびOracleアクセス・プロトコル・バージョン3またはバージョン4 (Webgateごとに共有秘密鍵1つのセキュリティ機能をサポート)のいずれかを使用したOAMサーバーとの通信

- 10gサーバーとのOblix Java APIおよびOracleアクセス・プロトコル・バージョン3 (SSKPAのサポートなし)のみによる通信

関連項目:

Oracle Fusion Middleware Oracle Access Management開発者ガイド

Mobile and Socialのトークン発行ポリシー

トークン発行ポリシーは、認証と認可を実行するMobile and Socialのクライアントに必要です。

関連項目:

第IX部「Oracle Access Management Mobile and Socialの管理」: Mobile and Social認証サービスの詳細

パフォーマンスのチューニング

各トピックの調査は、デプロイ済のOracle Access Management環境をチューニングして、最適なパフォーマンスと持続性を確保できるように提供されています。

関連項目:

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

ユーザー定義パラメータ: 11g Webゲート

11g Webゲートは、ブラウザ・クライアントを使用します。ただし、非ブラウザ(REST: Representational State Transfer)クライアントがHTTPリソースへのアクセスや、認証および認可の実行を必要とする場合もあります。

関連項目:

- 「Mobile and Social用の11g Webgate機能について」

- 第IX部「Oracle Access Management Mobile and Socialの管理」

- Oracle Fusion Middleware Oracle Access Management開発者ガイド

11.1.2で変更された製品およびコンポーネントの名前

次の表に示すとおり、Oracle Access Managementではいくつかの製品およびコンポーネントの名前が変更されています。

項目

Oracle Access Management 11.1.2

Oracle Access Management 11.1.1

サービス

Access Manager

アイデンティティ・フェデレーション

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

Mobile and Social

アイデンティティ・コンテキスト(常に有効)

Access Manager

なし

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

なし

エージェント

Webゲート(OAMエージェント)

アクセス・クライアント(OAMエージェント)

OSSOエージェント

OpenSSOエージェント

Webゲート(OAMエージェント)

アクセス・クライアント(OAMエージェント)

OSSOエージェント

なし

コンソール名

Oracle Access Managementコンソール

Oracle Access Managerコンソール

管理者

管理者またはOracle Access Management管理者

Oracle Access Manager管理者

エージェントおよびアプリケーション・ドメイン登録

ポリシーの作成

Oracle Access Managementコンソール

エージェント登録、アプリケーション・ドメイン作成をデフォルトのセキュリティ・ポリシーを使用して自動化するためのリモート登録ツール。

Oracle Access Managerコンソール

リモート登録ツール

認可

条件およびルール

制約

第I部

Oracle Access Managementの概要

本書のこの部分では、Oracle Access Managementの概要を説明します。

第I部は以下の章で構成されます。

- 第1章「Oracle Access Managementの概要」

1 Oracle Access Managementの概要

このマニュアルでは、管理者がAccess Managerのコンポーネントやポリシーを1つ以上のWebLogic管理ドメイン内で管理する上で役立つ情報を提供しています。この章では、Oracle Access Managementの概要について説明し、関連情報へのリンクを示します。

この章は次の項で構成されています:

- Oracle Access Managementの概要

- Oracle Access Management Access Managerの概要

- Oracle Access Management Access Manager 11.1.2の概要

- Oracle Access Management Security Token Serviceの概要

- システム要件と動作要件

1.1 Oracle Access Managementの概要

Oracle Access ManagementはJavaプラットフォームのEnterprise Edition(Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、Web周辺のセキュリティ機能を提供する全面的なサービスが含まれています。これにはWebシングル・サインオン、アイデンティティ・コンテキスト、認証および認可、ポリシー管理、テスト、ログイン、監査などが含まれます。

Oracle Access Managementは、セッション管理、アイデンティティ・コンテキスト、リスク分析、監査などの共有プラットフォーム・サービスを利用し、機密情報へのアクセスを制限します。図1-1に示すように、Oracle Identity Managementスタックの多くの既存アクセス技術は、Oracle Access Managementにまとめられています。

図1-1 Oracle Access Managementの概要

Oracle Access Managementでは、リリース11.1.2より、本書で説明されている次のサービスが追加されます。

- Oracle Access Management Access Manager (Access Manager)。「Oracle Access Management Access Managerの概要」を参照してください。

- Oracle Access Managementセキュリティ・トークン・サービス(セキュリティ・トークン・サービス): セキュリティ・ドメイン全体でのサービスへのアクセスや、組織の境界を越えたサービスへのアクセスを容易にする、トークンの検証および生成機能を提供します。サービスは、基本的に、クライアント要求を受信して検証し、要求対象リソースに適切なトークンを生成するトラスト・ブローカとして機能します。詳細は、「Oracle Access Management Security Token Serviceの概要」を参照してください。

- Oracle Access Management Identity Federation (Identity Federation): オープンなフェデレーション・プロトコル標準(SAMLやOpenIDなど)を使用したドメイン間シングル・サインオンのサポートを提供します。リリース11.1.2より、Identity Federationはスタンドアロン製品ではなくなり、Oracle Access Managementに付属し、緊密に統合されています。この新しいOracle Access Managementではユーザー・インタフェースと管理の操作性が改良されています。詳細は、第VII部「Oracle Access ManagementのIdentity Federationの管理」を参照してください。

- Oracle Access Management Mobile and Social (Mobile and Social): 保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアイデンティティ管理サービスおよびアクセス管理サービスの間の新しい中間サービスです。Mobile and Socialは、モバイル・プラットフォームのセキュリティと準拠性を拡張し、FacebookやGoogleなどのソーシャル・アイデンティティ・サービスとの統合を簡単にします。Mobile and SocialのRESTfulはアイデンティティおよびアクセス管理のインフラストラクチャを使用可能にし、主要なモバイル・プラットフォームの専用開発者キットを含んでいます。管理者は、これによりセキュリティ・サービスに簡単にアクセス可能になり、ネイティブおよびモバイル・ブラウザベース・アプリケーションでのシングル・サインオンが可能になります。詳細は、第IX部「Oracle Access Management Mobile and Socialの管理」を参照してください。

- アイデンティティ・コンテキスト: コンテキストを認識するセキュリティ・ポリシー管理を提供し、管理者は、Oracle Identity Managementが提供するセキュリティ・フレームワークを通じて、アプリケーション配信環境で付与されるセキュリティのレベルを制御できます。詳細は、第X部「アイデンティティ・コンテキストの使用」を参照してください。

- OpenSSO 8.0およびSun Access Manager 7.1もOracle Access Management 11.1.2に統合されています。詳細は、次を参照してください。

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

1.1.1 Oracle Access Managementのインストールについて

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

Oracle Fusion Middleware構成ウィザードを使用して、次のコンポーネントが新しいドメインにデプロイされます。

- WebLogic管理サーバー

- WebLogic管理サーバー(OAM管理サーバー、または単にAdminServerということもあります)上にデプロイされたOracle Access Managementコンソール

- Oracle Access Managementの管理対象サーバー

- 管理対象サーバーにデプロイされたアプリケーション

関連項目:

- Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド

OracleAS 10g SSOのデプロイメントは、Oracle Access Management 11g SSOを使用するようにアップグレードできます。OSSOエージェントをアップグレードして登録した後は、認証がAccess Manager 11g認証ポリシーに基づいて実行されます。ただし、OAMエージェント(Webgate/アクセス・クライアント)のみがAccess Manager 11g認可ポリシーを使用します。時間が経つにつれて、アップグレードされた環境にあるすべてのmod_ossoエージェントをWebgateと置換して11g認可ポリシーを使用できるようにする必要があります。

アップグレード後の共存の詳細は、Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイドを参照してください。

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

各WebLogic Serverのドメインは、論理的に関連するOracle WebLogic Serverリソースのグループです。WebLogic管理ドメインには、Administration Serverという特殊なOracle WebLogic Serverインスタンスが含まれています。このドメインは通常、管理対象サーバーという追加のOracle WebLogic Serverインスタンスを含み、WebアプリケーションとWebサービスがここにデプロイされます。

初回のデプロイメント中、Oracle Access ManagementコンソールとWebLogic Server管理コンソールの両方にサインインするときに、WebLogic管理者のユーザーとパスワードが設定されます。「Oracle Access Management管理者の概要」で説明しているとおり、Oracle Access Managementに対して別の管理者を割り当てることができます。

管理者は、次のインストール後タスクのためにOracle Access Managementコンソールにログインして使用できます。

表1-1 Oracle Access Managementのインストール後のタスク

サービス

要件

Access Manager

Access Managerサービスを有効化します。

次の項目を登録します。

- データ・ソース

- OAMサーバー・インスタンス

- Access Managerのエージェント

- リソースを保護するアプリケーション・ドメインおよびポリシー

次の項目を構成します。

- セッションのタイミングなどの共通設定

- 証明書検証

- 共通パスワード・ポリシー

Access Managerの設定を構成します。

アイデンティティ・フェデレーション

Identity Federationサービスを有効化します。

フェデレーション設定を構成します。

アイデンティティ・プロバイダを登録します。

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

セキュリティ・トークン・サービスを有効化します。

セキュリティ・トークン・サービスの設定を構成します。

エンドポイントを登録します。

トークン発行および検証テンプレートを作成します。

パートナ・プロファイルとパートナを登録します。

Mobile and Social

モバイルおよびソーシャル・サービスを有効化します。

モバイルおよびソーシャル・サービスを構成します。

モバイル・サービスを構成します。

インターネット・アイデンティティ・サービス

1.2 Oracle Access Management Access Managerの概要

このセクションでは、Oracle Access Management Access Managerの概要を説明します(以前は、Oracle Access Managerという名前のスタンドアロン製品でした)。

Access Managerシングル・サインオン(SSO)は、ユーザーやユーザーのグループが、認証後に複数のアプリケーションにアクセスできるようにします。SSOにより、サインオンを何度も要求されるということがなくなります。Access Managerは、Oracle Fusion Middleware 11gのシングル・サインオン・ソリューションです。Access Managerは、このマニュアルの説明にあるように単独で動作する他、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の説明にあるようにAccess Manager認証プロバイダとともに動作します。

Webサーバー、アプリケーション・サーバーまたは任意のサード・パーティ・アプリケーションは、Webgateにより、またはAccess Managerにエージェントとして登録されたmod_ossoインスタンスにより保護する必要があります。ポリシーを施行するために、エージェントはHTTPリクエストのフィルタとして機能します。Access Managerでは、管理者が認証および認可のポリシーを定義できます。

注意:

Webgateは、様々なWebサーバーのためにOracleが製品の一部として提供するエージェントです。Access Manager SDKを使用して作成されたカスタムのアクセス・クライアントは、Web以外のアプリケーションで使用できます。明記されている場合を除いて、このマニュアルの情報はどちらにも同じように該当します。

Access Managerや現在Oracle ADF SecurityおよびOPSS SSOフレームワークを使用する任意のWebアプリケーションと統合することもできます。詳細については、付録Cを参照してください。

この項の残りの部分では、次のトピックを説明します。

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

- Access Managerのデプロイメント・タイプの概要

いくつかの重要な内容があります。

関連項目:

Access Manager 11gと10g、OSSO 10gとOpenSSOの間の相違点について:

- Access Manager 11.1.2と10gの比較

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

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

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

このトピックでは、Oracle WebLogicサーバー上に存在し、Oracle Fusion Middlewareアクセス管理アーキテクチャの一部であるAccess Manager 11gの概要を説明します。

既存のソリューションとの下位互換性および共存が提供される一方で、Access Manager 11gでは次の旧テクノロジが置換および集約されます。

- Access Manager 10g

- Oracle Application Server SSO(OSSO)10g

図1-2は、基本的なAccess Manager 11gのコンポーネントおよびサービスを示します。プロトコル互換性フレームワークは、OAM Webgate、mod_ossoエージェント、Access Managerソフトウェア開発キット(SDK)を使用して作成されたカスタムのアクセス・クライアントとインタフェースします。

図2-2 Access Manager 11gのコンポーネントおよびサービス

「図1-2 Access Manager 11gのコンポーネントおよびサービス」の説明

図1-3は、Access Managerコンポーネントの分散を示します。

図1-3 Access Manager 11gのコンポーネントの分散

「図1-3 Access Manager 11gのコンポーネントの分散」の説明

Oracle Access Managementコンソールは、Oracle WebLogic Administration Server (AdminServerとも呼ばれます)に備わっています。OAMランタイム・インスタンスをホストするWebLogic管理対象サーバーは、OAMサーバーとして知られています。

共有情報は次の項目で構成されます。

- エージェントおよびサーバー構成データ

- Access Managerポリシー

- セッション・データはすべてのOAMサーバーで共有されます。

1.2.2 Access Managerのデプロイメント・タイプの概要

表1-2は、エンタープライズ内のデプロイメントのタイプについて説明します。ただし、これらの名前は企業によって異なる可能性があります。

表1-2 デプロイメント・タイプ

デプロイメント・タイプ

説明

開発デプロイメント

理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限

QAデプロイメント

通常、テスト用に使用される、比較的小さな共有されたデプロイ

本番前デプロイメント

通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント

本番デプロイメント

日常的に企業内で完全に共有および使用可能

初回のインストールおよび構成のときに、新しいWebLogic Serverドメインを作成(または既存のドメインを拡張)して、OAMサーバー、データベース・スキーマ、オプションのWebLogic管理対象サーバー、クラスタ、埋込みLDAPを定義します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』ガイドの「Oracle WebLogic Serverドメインの理解」の章で、Oracle WebLogic Server管理ドメインについて説明しています。

WebLogic Serverドメイン: デプロイメントのサイズやタイプに関係なく、Oracle Fusion Middleware構成ウィザードを使用すると、新しいWebLogic Serverドメインに、次のコンポーネントがデプロイされます。

- WebLogic管理サーバー

- WebLogic管理サーバーにデプロイされたOracle Access Managementコンソール

- Oracle Access ManagementサービスのWebLogic管理対象サーバー

- 管理対象サーバーにデプロイされたアプリケーション

注意:

既存のWebLogic Serverドメインでは、WebLogic管理サーバーはすでにインストールされて動作の準備ができています。

ポリシー・ストア: デフォルト・ポリシー・ストアは、デプロイメントや実証を目的としたファイル・ベースのものです。これは、本番環境ではサポートされません。本番環境では、すべてのポリシー操作と構成は、ポリシー・ストアとして構成されたデータベースに対して直接実行されます。

アイデンティティ・ストア: デフォルトの埋込みLDAPは、Access Managerの基本ユーザー・アイデンティティ・ストアとして設定されます。

キーストア: 認可時にOAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用するために、Javaキーストアが設定されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップも発生します。

関連項目:

「ポリシーおよびセッション・データベースの管理」

1.3 Oracle Access Management Access Manager 11.1.2の概要

このトピックの内容は次のとおりです。

- Access Manager 11.1.2について

- Access Manager 11gで使用できない機能について

1.3.1 Access Manager 11.1.2について

表1-3に、Access Manager 11.1.2の概要を示します。11.1.2で変更された名前のリストについては、「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。

表1-3 概要: Access Manager 11.1.2

Access Manager 11g

説明

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

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

ポリシー施行エージェント

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

- 11g OAMエージェント、第13章

- 10g OAMエージェントおよび事前構成済のIAMSuiteAgent(10g OAMエージェント)、第22章

- OpenSSOエージェント、第20章

- 10g OSSOエージェント(mod_osso)、第21章

注意:

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

特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。

エージェントの概要については、第12章を参照してください。

サーバー側のコンポーネント

- OAMサーバー(WebLogic管理対象サーバーにインストール)、

コンソール

Oracle Access Managementコンソールを使用すると、すべてのサービスおよび構成の詳細にアクセスできます。

第2章を参照してください。

インターネットでの情報交換用プロトコル

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

バック・チャンネル・プロトコル: 認証クライアントは、Oracle Accessプロトコル(OAP)の拡張機能を使用してセッションの処理を実行できます。

プロキシ

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

- OAMプロキシは、レガシー・アクセス・サーバーとしてレガシーAccess Manager実装をサポートします。
OAMプロキシの簡易および証明書モードのアクセス・プロトコルの管理のセキュリティ
OAMプロキシ・メトリックとチューニングの概要

- OSSOプロキシは、レガシーOSSOサーバーとしてOSSOエージェントをサポートします。第21章を参照してください。

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

関連項目: 埋込みプロキシ・サーバーおよび下位互換性について

暗号化キー

注意: 登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成され、使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

- 11gエージェントの登録時、11g WebgateとOAMサーバー間で、SSO Cookieの暗号化および復号化用に共有される秘密鍵がエージェントごとに1つ生成されます。第13章を参照してください。

- 10gエージェントの登録時、Access Manager 11g全体にわたる(すべてのエージェントとOAMサーバー)グローバル共有秘密鍵が生成されます。第22章を参照してください。

- OSSOエージェントの登録時、mod_ossoとOSSOサーバー間でパートナごとに1つのキーが共有されます。第21章を参照してください。

- OpenSSOエージェントのホスト・ベースまたはドメイン・ベースのキーは、エージェント・ホストのエージェント・ブートストラップ・ファイル内にローカルに保存されます。第20章を参照してください。

- OAMサーバーの登録時、1つのサーバー・キーが生成されます。

キー・ストレージ

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

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

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

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

1. Webgateは、エージェント・キーを使用してobrareq.cgiを暗号化します。
注意: obrareq.cgiは、WebgateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

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

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

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

ポリシー・ストア

本番環境では、データベースです。実証環境および開発環境では、ファイル・ベースです。詳細は、「ポリシーおよびセッション・データベースの管理」を参照してください。

アプリケーション

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

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

SSOエンジン

セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。Access Manager 11gによって登録されたエージェントを使用します。

- デフォルトの埋込み資格証明コレクタを使用する認証は、HTTP(HTTPS)チャネルを通じて行われます

- オプションの外部資格証明コレクタを使用する認証は、Oracle Accessプロトコル(OAP)チャネルを通じて行われます

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

第15章を参照

セッション管理

- グローバル・セッションの仕様は、すべてのアプリケーション・ドメインおよびリソースに対して有効化されます。さらに、アプリケーション・ドメイン専用セッションのオーバーライドを構成できます。

第14章を参照してください。

ポリシー

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

第17章を参照

クライアントIP

- クライアントの経過時間を管理し、ホストベースCookie OAMAuthnCookie(11g Webgate用)またはObSSOCookie(10g Webgate用)に含めます。

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

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

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

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

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

Cookie

ホストベースの認証Cookie

- 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_host:port_random_number。
注意: 有効なOAMAuthnCookieがセッションに必要です。

- 11g Webgate、一時: OAM_REQのスコープがOAM Serverに指定されます。認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去されるOAM_REQ。OAMサーバーでのみ認識されるキーで保護されます。資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

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

- OAMサーバーに1つ: OAM_ID、スコープがOAM Serverに指定されます。OAM_IDは、ユーザーが資格証明のチャレンジを受けたときにOAMサーバーによって生成され、サーバーへのリダイレクトごとにそのサーバーへ送信されます。

第15章を参照してください。

一元化されたログアウト

- logOutUrls (10g Webgateの構成パラメータ)は保持されています。10g logout.htmlには、Access Manager 11g固有の詳細情報が必要です。第22章を参照してください。

- 11g Webgateには次の新しいパラメータが追加されています。

ログアウト・リダイレクトURL
ログアウト・コールバックURL

ログアウト・ターゲットURL

第19章を参照してください。

1.3.2 Access Manager 11gで使用できない機能について

Access Manager 10gでは、Access Manager 11gに含まれていない、いくつかの機能が提供されています。表1-4に概要を示します。

表1-4 Access Manager 11gで使用できない10gの機能

使用不可またはサポートされていない機能

カスタム認可プラグインの作成に必要な拡張性フレームワーク

アプリケーション・ドメイン・レベルで委任された管理

mod_ossoで保護されたリソースの認可

1.4 Oracle Access Management Security Token Serviceの概要

Security Token Serviceは、Access Managerとともにデプロイし、サービスとしてアクティブ化する必要があります。

関連項目:

- 『Oracle Fusion Middlewareパッチ適用ガイド』のOracle IdentityおよびAccess Managementの11.1.1.3.0から11.1.1.5.0へのパッチ適用に関する項

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

- 第VIII部「Oracle Access Management Security Token Serviceの管理」

Security Token Serviceは、トークンの取得、更新および取消のためのモデルにおいて、プロトコルやセキュリティ・インフラストラクチャに依存せず、その一貫性と効率性を促進するための基盤を現在のセキュリティ・インフラストラクチャに提供します。

Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介ならびに安全なアイデンティティ伝播およびトークン交換を可能にします。Security Token Serviceは、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために必要なセキュリティおよびアイデンティティ・サービスとしてデプロイできます。

Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を委任します。

Security Token Serviceブローカは、Webサービス利用者(WSC)とWebサービス・プロバイダ(WSP)との間において信頼関係があり、セキュリティ・トークンのライフサイクル管理サービスを利用者とプロバイダに提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。Oracle Access Management Security Token ServiceはOracle Access Management Identity Federationを拡張します。これにより、SAML、WS-Federation、LibertyまたはOpenIDなどの各種フェデレーション・プロトコルを介して、異なるセキュリティ・ドメインにまたがる、または管理境界を越えたリソースにアクセスするためにWebブラウザ経由で訪れるユーザーに対して、フェデレーテッド・シングル・サインオン(SSO)およびシングル・ログアウト(SLO)が円滑化されます。

セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているOracle Access Managementセキュリティ・トークン・サービスから取得できます。相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSecurity Token Serviceを信頼している必要があります。

今日のIT環境には数多くのタイプのセキュリティ・トークンがあり、そのほとんどがWebアプリケーションのSSOおよびアプリケーション・セッション管理を容易にするブラウザCookieを基にしています。その他のトークンには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。

詳細は、次のトピックを参照してください。

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

- Security Token Serviceについて

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

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

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

- Security Token Serviceの管理について

1.4.1 Security Token Serviceの主な用語と概要

表1-6は、Security Token Serviceの一般的な用語について説明しています。

表1-5 Security Token Serviceの用語と概要

用語

説明

セキュリティ・トークン

メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。

サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。

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

サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security Token Serviceはその一例です。

セキュア・トークン・サービス

様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。

このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。

信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密鍵を使用して署名され、その署名は送信者の公開鍵を使用して検証されます。

リクエスト・セキュリティ・トークン(RST)

セキュリティ・トークンのリクエスト。

リクエスト・セキュリティ・トークン・レスポンス(RSTR)

セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Security Token Serviceにより生成されたレスポンス。

代理(OBO)

OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。

- トークンのOnBehalfOf要素で表された外部エンティティ。

ActAs

ActAs RSTは、複合的な委任を必要とします。発行されたトークンの最終受信者が、(クライアントのみでなく)委任チェーン全体を検査できます。ActAs RSTは、リクエスタが必要としているトークンに、次の異なるエンティティに関する要求が含まれているをことを示します。

- リクエスタ

- トークンのActAs要素で表された外部エンティティ。

トークン交換

あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、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サービスで許容できる最大メッセージ・サイズを定義できます。

証明書

Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。

キーストア

Security Token Serviceのキーストアに含まれるものを次に示します。

- システム・キーストア

- 信頼キーストア

- パートナ・キーストア

関連項目: 第33章「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トークンを使用できるようになります。

表1-6 セキュリティ・トークン・サービスの用語

用語

説明

セキュリティ・トークン

メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。

サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。

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

サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security Token Serviceはその一例です。

セキュア・トークン・サービス

様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。

このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。

信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密鍵を使用して署名され、その署名は送信者の公開鍵を使用して検証されます。

リクエスト・セキュリティ・トークン(RST)

セキュリティ・トークンのリクエスト。

リクエスト・セキュリティ・トークン・レスポンス(RSTR)

セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Security Token Serviceにより生成されたレスポンス。

代理(OBO)

OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。

- トークンのOnBehalfOf要素で表された外部エンティティ。

ActAs

ActAs RSTは、複合的な委任を必要とします。発行されたトークンの最終受信者が、(クライアントのみでなく)委任チェーン全体を検査できます。ActAs RSTは、リクエスタが必要としているトークンに、次の異なるエンティティに関する要求が含まれているをことを示します。

- リクエスタ

- トークンのActAs要素で表された外部エンティティ。

トークン交換

あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、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サービスで許容できる最大メッセージ・サイズを定義できます。

証明書

Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。

キーストア

Security Token Serviceのキーストアに含まれるものを次に示します。

- システム・キーストア

- 信頼キーストア

- パートナ・キーストア

関連項目: 第33章「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トークンを使用できるようになります。

1.4.2 Security Token Serviceについて

Security Token ServiceはAccess Managerに準拠し、Access Managerと共存します(トークンをリクエストするWebクライアントのプライマリ・オーセンティケータとしてAccess Managerを使用)。

Security Token Serviceは、Oracle Access Management 11gとともに管理対象サーバー上にインストールします。各管理対象サーバーは、通信チャネルをオープンするためにAccess Managerに登録する必要があります。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。Security Token Serviceは、サード・パーティのセキュリティ・トークン・サービスと相互運用します。

Security Token Serviceでは、Oracle Web Services Managerエージェントが使用されます。Webgateは、アイデンティティ伝播用のエージェントとして使用されます。Webgateは、通信チャネルをオープンするためにAccess Manager 11gに登録する必要があります。

Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびAccess Manager 11g管理モデルが利用されます。さらに、Security Token Serviceは、Oracle Access Managementコンソールと統合され、統一的で一貫性のある管理エクスペリエンスを提供します。

Security Token Serviceでは、診断、監視、監査および高可用性のためのフレームワーク、ガイドラインおよび手法について、Oracle Access Management 11gで使用されているものと同じものが採用されています。詳細は、第III部「共通のロギング、監査、パフォーマンス・モニタリングおよびチューニング」を参照してください。

Security Token Serviceは次の処理を実行します。

- STS監査イベントを統合

- Oracle Access ManagementコンソールおよびWLSTスクリプトにおいて、使用可能なSecurity Token Serviceメソッドを公開してパートナのデータを管理

- Security Token Serviceのユースケースおよび構成モデルに固有の検証操作を実行

セキュリティ・トークン・サービス11gのインフラストラクチャは、表1-7で説明します。

表1-7 セキュリティ・トークン・サービス11gのインフラストラクチャ

コンポーネント

説明

デフォルト信頼キーストア

署名/暗号化に使用されるSecurity Token Serviceの秘密鍵は、Access Managerで使用される共通キーストアに格納されます。Security Token ServiceおよびAccess Managerでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。

トークン・セキュリティ・キー・ペアは、Access Manager/Security Token Serviceキーストアに移入されます。

注意: Oracle WSMエージェントをセキュリティ・トークン・サービスの実装でWS_Trustとして使用しているときは、常にOracle WSMエージェント・キーストアとセキュリティ・トークン・サービス/Access Managerキーストアを別々に使用することを強くお薦めします。この2つをマージしないでください。そのようにしないと、Access Manager/Security Token ServiceキーがOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Managerキーがアクセスされる可能性があります。

関連項目: セキュリティ・トークン・サービス・キーストアについて。

デフォルトのユーザー・アイデンティティ・ストア

Security Token Serviceは、Oracle Access Managementコンソールの「システム構成」の「共通構成」セクションで構成されたユーザー・アイデンティティ・ストアに対してユーザーを認証およびマッピングします。Security Token Serviceは、着信トークンをデフォルト・ユーザー・アイデンティティ・ストアのユーザー・レコードおよびユーザー属性にマッピングし、これがAccess ManagerとSecurity Token Serviceの両方と連動します。

関連項目: 「デフォルト・ストアおよびシステム・ストアの設定について」。

証明書

Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。

- Security Token Serviceで使用される鍵と証明書はインストール中に生成されます。サブジェクトと発行者のフィールドは、ホスト名にリンクされます。これは、Security Token Serviceで使用される署名鍵、暗号化鍵および証明書の他、Access Managerを保護するOWSMエージェントで使用される鍵/証明書にも適用されます。OWSMエージェントは、Security Token Serviceとの通信に使用可能な、認定されたWS-Trustクライアントです。

- SAML発行者の設定は、ローカル・コンピュータのホスト名を参照するために構成します。

これにより、暗号化のデータおよび識別子に関して、2つのサーバーが同一ではないことが確認されます。サード・パーティ・モジュールにより一方のサーバーに付与された信頼は、識別子と暗号キーが異なるため、他方のサーバーには付与されません。同一の鍵、同一の識別子がない場合、認可ポリシーは拒否モードです。

Oracle Coherence

Security Token Serviceは、Oracle Coherenceモジュールと統合され、Security Token Serviceのすべての物理インスタンス間でWS-Trustのランタイム・データが格納および共有されます。UserNameToken Nonceは、Coherenceストアに格納されます。この実装では、Security Token Service以外では一般的ではない次の要件がサポートされます。

- タイムアウト・レコードのクリーン・アップ

- レコードの生存を数分に制限(30未満)

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

11gリリースにおいて、Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WSMエージェント機能とともにOracle WebLogic Serverに統合されています。表1-8では、これらのコンポーネントについて説明します。

関連項目:

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

表1-8 統合された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エージェントは、Security Token Serviceとの通信に使用可能な、認定されたWS-Trustクライアントです。OWSMエージェントは、メッセージ保護のみのために(WSポリシーを公開するため、およびインバウンドおよびアウトバウンドのWSメッセージに対してメッセージ保護を施行するために)、Security Token Serviceにより埋め込まれ、使用されます。Security Token Serviceは、トークン検証/リクエスト認証を実行します。

- Security Token Serviceに埋め込まれたOracle WSMエージェントは、認証機能が無効化され、「メッセージ保護のみ」のモードで使用されます。このように、着信トークンの認証に関連したすべての側面は、Security Token Serviceのみによって実行されます。

- Oracle WSMは、Security Token Serviceが各ポリシーに宣言する必要がある構成オーバーライドを使用して認証の無効化をサポートします。
例外: KerberosトークンはOracle WSMにより処理され、Security Token Serviceはアイデンティティのみをマッピングすることに関与します。

- OWSMエージェントは、Security Token Serviceとの通信に使用可能な、認定されたWS-Trustクライアントの1つです。他のサード・パーティWS-Trustクライアントを使用して、Security Token Serviceと相互作用させることも可能です。

注意: 埋込みは、セキュリティ・トークン・サービスが使用するWebLogic ServerのJRFレイヤの一部としてOWSMエージェントが利用可能であることを意味します。

メッセージ/トークンの保護

Security Token Service/Access Managerは、それぞれのキーストアおよび信頼ストアを管理します。

Oracle WSMがSecurity Token Serviceのメッセージ保護を施行するために、OWSMのキーストアがその自己署名付き証明書でシードされ、それに対応する鍵のパスワードがCSFに格納されます。これは、Security Token Serviceキーストアを使用しません。

注意: 反対に、Oracle WSMは、Access Manager/Security Token Serviceがメッセージ保護に関連する鍵をOPSSキーストアに格納することを必要とします。クライアントがSKI、Thumbprintなどのスキームを使用してその証明書を参照する場合、Oracle WSMには、クライアント証明書がOPSSキーストアにあることが必要です。

トークン署名鍵

Security Token Serviceでは、トークン署名鍵に関して厳しい要件があり、クライアントとリライイング・パーティとの間の信頼を仲介するためにトークン署名鍵が使用されます。したがって、この鍵は、Security Token Serviceのみがアクセス可能な排他的パーティションに格納する必要があります。

セキュリティ・キー・ペア

Security Token Serviceは、発行されたトークンのセキュリティおよびメッセージ・セキュリティのために別々の鍵ペアを作成することで、トークン署名鍵のセキュリティを提供し、Oracle WSMエージェントがAccess Manager/Security Token Serviceキーストアと連携する必要性を排除します。

- メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。

- トークン・セキュリティ・キー・ペアは、Access Manager/Security Token Serviceキーストアに移入されます。

OPSSキーストア

メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。クライアントが(Webサービス・リクエストの一部として受信した証明書トークンではなく)SKIなどの参照スキームを使用する特別な場合、Security Token Serviceは、要求当事者の証明書をOPSSキーストアに移入します。これは一般的なシナリオではありません。Security Token Serviceには、OPSSキーストアに対して鍵を手動でプロビジョニングして機能させることについて、用意されている手順もあります。

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

Oracle STSは、WS-Trustプロトコルをサポートする一元化されたトークン・サービスで、セキュリティ・トークンの発行および交換ならびに信頼関係の確立のために、WS-Security仕様に対する拡張機能を定義します。Oracle STSは、Webサービス・エンドポイントとしてホストされ、WSCとWSPとの間におけるセキュリティに基づく相互作用を調整します。Oracle STSとのすべての通信は、図1-4に示すように、WS_Trustクライアントを介して発生します。

図1-4 Oracle STSのアーキテクチャ

「図1-4 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-5では、Oracle STSのトークン・サポート・マトリックスを示します。

図1-5 Oracle STSのトークン・サポート

「図1-5 Oracle STSのトークン・サポート」の説明

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

この項では、いくつかの異なるデプロイメント・オプションを紹介するために次のトピックを説明します。

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

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

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

関連項目:

「シナリオ: Access Managerトークンを使用したアイデンティティ伝播」

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

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-6に示すように、Security Token Serviceの導入により、一元化された認証局でトークンの変換を行うことが可能です。

図1-6 一元化された認証局でのトークン変換

「図1-6 一元化された認証局でのトークン変換」の説明

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

アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleおよびカスタム・アプリケーションとのWACシステムの統合では、(1)独自のベンダーAPI (SMエージェントAPIやASDK)をコールすることによる、あるトークン認証局(OAMやSiteMinderなど)により発行されたトークンの分解、および(2)アプリケーションがその内部ビジネス・ロジックのために必要とする新しいトークン形式(PSFT、Siebel)の構成のために、ほぼ必ず広範なコーディングが必要となります。

そうした変換は、アプリケーションのコーディングにより処理されることが多く、そのコードがDMZにある複数のアプリケーション・インスタンス上でデプロイされた場合に、ユーザー名やパスワードがさらされるといったリスクの要因となります。

セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。Security Token Serviceの導入により、この状況は大幅に改善されます。図1-7に示すように、Security Token Serviceは一元化されたトークン認証局の役割を担い、ファイアウォールの背後でトークン変換を実行します。

図1-7 ファイアウォールの背後でのトークンの変換

「図1-7 ファイアウォールの背後でのトークンの変換」の説明

アプリケーション1およびアプリケーション2は、Access Managerにより保護されています。アプリケーション2は、その内部ビジネス・ロジックのために別のタイプのトークンに依存しています。このアプリケーションには、OBSSOトークンをユーザー名トークンと交換するためにSecurity Token Serviceにコンタクトするクライアント側コネクタがあります。Security Token Serviceは、OBSSOトークンを分解するためにAccess Managerに依存しており、アプリケーション2が必要とする新しいトークンを生成します。

ここでは同一の認証局(Access Manager)が両方の操作(OBSSOトークンの構成および分解)を実行するため、より安全です。アプリケーション側でトークンを分解する必要はありません。

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

Web SSOと同様に、WebサービスSSOは便利な機能です。その違いは、Web SSOでは、その機能から恩恵を受ける当事者はユーザーであるという点です。WS環境では、次のようになります。

- Web SSO: ユーザーが恩恵を受けます。

- WebサービスSSO: セキュリティ管理者が恩恵を受けます。

WebサービスSSOでは、異なるWebサービスに異なるトークン要件があり、それが頻繁に変更されます。Security Token Serviceに交換を外在させると、アプリケーションが目的のトークンおよび現在保持しているトークンを単純に供給できるようになります。Security Token Serviceは、リクエストされた各サービスのトークン・タイプを決定することを引き受けます。

1つ以上のWebサービスでその認証要件が変更されても、Security Token Serviceは、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。

図1-8に、WebサービスSSOを示します。

図1-8 WebサービスSSO

「図1-8 WebサービスSSO」の説明

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

この項では、様々なインストール・オプションの簡単な概要として次のトピックを説明します。

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

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

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

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

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

単一のWebLogicドメイン内にある様々な管理対象サーバーでデプロイされたSecurity Token Serviceインスタンスの間でクラスタリングを利用できます。このデプロイメント・トポロジでは、ロード・バランサにより高可用性機能が円滑化されます。デフォルトでは、Access ManagerとSecurity Token Serviceが同一の管理対象サーバーに共存します。ただし、Security Token Serviceはデフォルトで無効になっており、これを使用できるようにするには、手動で有効化する必要があります。

このデプロイメント・トポロジでは、次に示すことを行うことになります。

- スイート・インストーラを使用してSecurity Token Serviceの複数のインスタンスをデプロイします。

- ロード・バランサをデプロイして高可用性に加えてSecurity Token Serviceクラスタのフロントでのフェイルオーバー・シナリオをサポートします。

詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

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

このインストール・オプションでは、リクエスタおよびリライイング・パーティとサード・パーティSTSサーバーとの間に相互運用性がもたらされます。実行時に、Security Token Serviceは、OPSS WS-Trustプロバイダを使用して、サード・パーティ・セキュリティ・トークン・サーバーのリクエスタおよびリライイング・パーティとの相互運用をサポートします。たとえば、サード・パーティ・セキュリティ・トークン・サービスが有効なSAMLアサーションを作成し、Security Token Serviceがそれを使用できます。

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

リクエスタとリライイング・パーティのためのすべての実行時シナリオは、WLSClient、MetroClientおよびOracle Web Services Manager (Oracle WSM)を含む、他のOracle WS-Trustクライアントによりサポートされています。

WS-Trustバインディングを介した場合のみ、すべてのWebサービス・クライアントがSecurity Token Serviceでサポートされます。

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

Access ManagerとSecurity Token Serviceは、1つのEARファイルから一緒にインストールされます。Access Managerと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 and Access Managementインストレーション・ガイドを参照してください。

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

Security Token Serviceをホストするサーバーは、Access Managerに登録する必要があります。これはインストール中に自動的に、またはインストール後に手動で行うことができます。

Oracle Access Managementコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。

Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。これにはこれまでに扱った次のトピックが含まれます。

情報はマニュアル全体から探すようにしてください。Security Token Serviceサービスの詳細は第VIII部「Oracle Access Management Security Token Serviceの管理」を参照してください。

1.4.7 Security Token Serviceの管理について

1つのLDAPグループ、WebLogic ServerのAdministratorsグループがデフォルトで設定されます。

初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。管理者は、Oracle Access Managementコンソール(およびWebLogic Server管理コンソール)にログインして使用できます。

詳細は、第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」を参照してください。

1.5 システム要件と動作保証情報

ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、Oracle Technology Network(OTN)で、システム要件と動作保証情報のドキュメントを参照してください。

システム要件に関するドキュメントには、ハードウェア要件およびソフトウェア要件、ディスク領域とメモリーの最小要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html

動作要件に関するドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品が記載されています。

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

第II部

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

第II部では、Oracle Access Managementのシステム構成の一般的な管理について詳細に説明します。

第II部は、次の章で構成されています。

- 第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」

- 第3章「共通サービスおよび証明書の検証の管理」

- 第4章「データ・ソースの管理」

- 第5章「サーバー登録の管理」

2 Oracle Access Management管理およびナビゲーション・スタート・ガイド

この章では、Oracle Access Managementコンソールのログインとナビゲーションに必要な最初の手順について説明します。この章の内容は次のとおりです。

- 前提条件

- Oracle Access Management管理者の概要

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

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

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

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

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

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

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

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

2.1 前提条件

このマニュアルのすべてのタスクは、Oracle Access Management 11.1.2がOracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの説明に従ってデプロイされていることが前提です。

本書のタスクを開始する前に、この章の情報を確認してください。

- 「デプロイメントでのサーバーの起動と停止」について学習します。

- 「Oracle Access Managementコンソールおよびコントロールの概要」で説明されているように、Oracle Access Managementコンソールについて理解してください。

- 基本ユーザーのアイデンティティ・ストアに定義された管理LDAPグループを検証してください。

2.2 デプロイメントでのサーバーの起動と停止

Oracle Access Management管理者は、WebLogic Administration Serverの動作時にのみ、WebLogic Administration Server (AdminServer)へデプロイされたOracle Access Managementコンソールにアクセスできます。Oracle Access ManagementコンソールがWebgateで保護されている場合は、OAMサーバーが実行中であることが必要です。また、ノード・マネージャが実行中でなければなりません。

詳細は、次を参照してください。

- ノード・マネージャの起動

- AdminServerの起動と停止

- OAMサーバーの起動と停止

2.2.1 ノード・マネージャの開始

WebLogic管理サーバー(AdminServer)またはOAMサーバーをホストするWebLogic管理対象サーバーを起動または停止するには、あらかじめノード・マネージャが実行されている必要があります。

Oracle Identity Managerをインストールして構成した後で、それをWebLogic管理コンソール (AdminServer) またはOracle Enterprise Manager Fusion Middleware Controlで使用するには、ノード・マネージャを構成する必要があります。この構成は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのノード・マネージャの構成に関する項の説明に従って、1回だけ実行します。

次の起動スクリプトを使用してノード・マネージャを実行します(Oracle WebLogic Administration Serverではこの処理を自動で実行しません)。

$WL_HOME/server/bin/startNodeManager.sh

関連項目:

詳細は、Oracle WebLogic Server管理者ガイドを参照してください。

ノード・マネージャを起動または停止するには

1. WL_HOME/server/binに移動します。

2. 起動スクリプトの有効化: setNMPropsを実行してスタックを起動し、ノード・マネージャに起動スクリプト(StartScriptEnabled=true)の使用を有効化するように指定します。

./setNMProps.sh

3. ノード・マネージャを起動します。

./startNodeManager.sh

2.2.2 AdminServerの起動と停止

AdminServerを初めて開始するときには、12～15分など、非常に長い時間を要する場合があります。このプロセスを中断または終了しないでください。これを行わない場合、ポリシー・データが破損する場合があります。

次の手順は、DOMAIN_HOME/binにあるスクリプトを使用してWebLogic AdminServerを起動および停止する手順を説明しています。

- Unix: startWebLogic.sh or stopWebLogic.sh

- Windows: startWebLogic.cmd or stopWebLogic.cmd

警告:

startWebLogic.cmd (Windows; startWebLogic.shまたはLinuxのstartWebLogic.shコマンド)をなんらかの理由(誤って、またはシステム・クラッシュや再起動など)で停止した場合、ポリシー・データが破損する可能性があります。このような場合にはドメインを削除および再作成し、RCUを再実行してOAMスキーマを作成する必要があります。

AdminServerを起動または停止するには

1. DOMAIN_HOME/binに移動します。

2. AdminServerを起動します。

- Unix: ./startWebLogic.sh

- Windows: run startWebLogic.cmd

3. AdminServerを停止します。

- Unix: ./stopWebLogic.sh

- Windows: run stopWebLogic.cmd

2.2.3 OAMサーバーの起動と停止

コマンド・プロンプト、Oracle WebLogic Server管理コンソールまたはOracle Enterprise Manager Fusion Middleware Controlから、Oracle Access Managementサーバー(OAMサーバー)をホストする管理対象WebLogic Serverのすべての起動および停止操作を実行できます。

次の手順は、DOMAIN_HOME/bin (Unixシステムの場合は.shスクリプト。Windowsシステムの場合は.cmdスクリプト)にあるスクリプトを使用してOAMサーバーを起動および停止する方法を説明しています。

- Unix: startManagedWebLogic.shまたはstopManagedWebLogic.sh

- Windows: startManagedWebLogic.cmdまたはstopManagedWebLogic.cmd

これらの操作には、管理対象サーバーの名前とAdminServer URLの両方が必要です。たとえば、管理対象サーバーがoam_server1と命名され、AdminServer URLがhttp://examplewlsadminhost.example.com:7001の場合、Unixシステムで実行する起動および停止コマンドは次のようになります。

startManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001

stopManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001

OAMサーバーを起動または停止するには

1. DOMAIN_HOME/binに移動します。

2. OAMサーバーを起動します。

- Unix: ./startManagedWebLogic.sh MANAGED_SERVER_NAME ADMIN_SERVER_URL

- Windows: startManagedWebLogic.cmd MANAGED_SERVER_NAME ADMIN_SERVER_URLを実行

3. OAMサーバーを停止します。

- Unix: ./stopManagedWebLogic.sh MANAGED_SERVER_NAME ADMIN_SERVER_URL

- Windows: stopManagedWebLogic.cmd MANAGED_SERVER_NAME ADMIN_SERVER_URLを実行

2.3 Oracle Access Management管理者の概要

単一のデフォルトLDAPグループであるWebLogic ServerのAdministratorsグループが、デフォルトのユーザー・アイデンティティ・ストア(組込みLDAP)内に設定されます。初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。これらの資格証明によって、次へのアクセス権が付与されます。

- Oracle Access Managementコンソール。システム構成、セキュリティ要素およびポリシーの登録や管理に使用します。

- WebLogic Server管理コンソールを使用して、WebLogic Serverドメイン内のデプロイされたOAMサーバーのサーバー構成サマリー(クラスタ、マシン、ステート、状態、リスナー・ポート)を参照したり、これらのサーバー上でSSLの起動、再開、一時停止、停止、または再起動を行います。
WebLogic Serverの管理コンソールの詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。

- カスタム管理コマンドライン・ツール(WebLogic Scripting Tool、別名WLST)。特定の機能セットについては、Oracle Access Managementコンソールのかわりに使用できます。

- リモート登録ツール。エージェント、アプリケーション・ドメインおよびポリシーの登録に使用します。

表2-1は、Oracle Access ManagementとWebLogicで認識される管理者ロール、および共通のデフォルト・システム・ユーザー・アイデンティティ・ストアでロールがマッピングされる先のデフォルトのLDAPグループを示します。

表2-1 LDAPグループから管理者へのロール・マッピング

管理者ロール

説明およびLDAPグループ

管理者のロール

システム・ストアとして指定されたユーザー・アイデンティティ・ストア内で定義されるLDAPグループで、ユーザーに完全なシステム構成およびポリシー構成の権限を付与します。

デフォルトのグループ = 管理者

注意: 異なるLDAPグループを指定すると、WebLogic管理者がOracle Access Managementコンソールにログインしたり、管理コマンドライン・ツールを使用できなくなります。

特に指定がないかぎり、このガイド内の「管理者」という用語は、Oracle Access Management管理者を指します。

最初は管理者ユーザーは、初回構成時に設定されたWebLogic管理者の資格証明を使用してOracle Access Managementコンソールにログインする必要があります。ただし、企業によっては、Oracle Access Management管理を担当するユーザー向けとWebLogic管理を担当するユーザー向けに別々の管理者グループが必要になることがあります。詳細は、「管理者ロールの管理」を参照してください。

注意:

構成の同時更新はサポートされていません。どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。複数の管理者が更新を同時に実行すると、Oracle Access Managementコンソールのシステム構成が一貫性のない状態になります。

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

Oracle Access Managementコンソールは、Oracle Access Managementのサービスおよび構成への管理アクセスを提供します。この項では、Oracle Access Managementコンソールのログインとサインアウトの方法を説明します。

注意:

1つのURLから複数のコンソールにアクセスするためにOracle Identity Navigatorをインストールしている場合、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。

この項の内容は次のとおりです。

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

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

2.4.1 Oracle Access Managementコンソールへのログイン

Oracle Access Managementコンソールへアクセスするときは、WebLogic Server (AdminServer)のホストおよびポートを指定する必要があります。サンプルのURL https://examplewlsadminhost.example.com:7001/oamconsoleの説明は次のとおりです。

- HTTPSは、Webサーバーが戻すユーザー・ページ・リクエストを暗号化および復号化できるように、Secure Socket Layer(SSL)を持ったHypertext Transfer Protocol(HTTP)を表します。

- examplewlsadminhost.example.comは、Oracle Access Managementコンソールをホストするコンピュータの完全修飾ドメイン名です。

- 7001は、Oracle Access Managementコンソールの指定されたバインド・ポートを指します。これはAdminServer (WebLogic Server管理コンソール)のバインド・ポートと同じです。

- /oamconsole/は、Oracle Access Managementコンソールの「ログイン」ページを指します。

注意:

OAMサーバーのホストおよびポートを指定する場合(ODSMコンソールのアクセス時など)、AdminServerが管理対象サーバーにリダイレクトされ、404 Not Foundエラーが発生します。

Oracle Access Managementコンソールのログイン・ページを図2-1に示します。

図2-1 Oracle Access Managementコンソールのデフォルトの「ログイン」ページ

「図2-1 Oracle Access Managementコンソールのデフォルトの「ログイン」ページ」の説明

注意:

ログインに正しい管理資格情報を使用するようにしてください。最初はOracle Access Managementコンソール管理者のLDAPグループは、WebLogic Server管理コンソールに定義されたLDAPグループと同じ(Administrators)で、共通のデフォルト・システム・ユーザー・アイデンティティ・ストアはWebLogic組込みLDAPです。

Oracle Access Managementコンソールにログインする手順

1. ブラウザ・ウィンドウで、適切なプロトコル(HTTPまたはHTTPS)を使用してOracle Access ManagementコンソールのURLを入力します。例:

https://hostname:port/oamconsole/

サンプルのURLは以下のようになっています。

- HTTPSは、Webサーバーが戻すユーザー・ページ・リクエストを暗号化および復号化できるように、Secure Socket Layer(SSL)を持ったHypertext Transfer Protocol(HTTP)を表します。

- hostnameは、Oracle Access Managementコンソールをホストするコンピュータの完全修飾ドメイン名です。

- portは、Oracle Access Managementコンソールの指定されたバインド・ポートを指します。これはAdminServerのバインド・ポートと同じです。

- /oamconsole/は、Oracle Access Managementコンソールの「ログイン」ページを指します。

2. 「ログイン」ページで、Oracle Access Managementコンソール管理者の資格証明を入力します。例:
ユーザー名: Admin_login_id

パスワード: Admin_password

3. 「ログイン」ボタンをクリックするか、[Enter]キーを押します。

4. 次のように先に進みます。

- 成功した場合: 「ポリシー構成」タブおよび「システム構成」タブが左側に、「ようこそ」ページが右側に表示されます。「システム構成およびポリシー構成のタブの概要」の説明にあるようにコンソールを操作するか、自分でタスクの実行を開始してください。

- 失敗した場合: 「管理者のロックアウト」を参照してください。

関連項目:

Oracle Access Management管理者の概要

2.4.2 Oracle Access Managementコンソールからのサインアウト

「サインアウト」リンクは、図2-2のようにOracle Access Managementコンソールの右上の隅に表示されます。セッションを終了するには、「サインアウト」リンクを選択します。サインアウトする前に、ブラウザのウィンドウを閉じることをお薦めします。

図2-2 サインアウト・リンク、Oracle Access Managementコンソール

「図2-2 サインアウト・リンク、Oracle Access Managementコンソール」の説明

Oracle Access Managementコンソールからサインアウトするには

1. コンソール右上の「サインアウト」リンクをクリックします。

2. ブラウザ・ウィンドウを閉じます。

2.5 Oracle Access Managementコンソールおよびコントロールの概要

Oracle Access Managementコンソールは、機能レベルおよびページ・レベルのタブとコントロールを提供するWebベースのプログラムです。この項では、Oracle Access Managementコンソールの概要を説明します。

Oracle Access Managementコンソールは、Oracle Access Management管理者が必要とするシステムやポリシー構成管理の機能を提供します。ブラウザ・ウィンドウに、Oracle Access ManagementコンソールのURLを入力できます。

https://example:port/oamconsole

サンプルのURLでは、hostnameはOracle Access Managementコンソールをホストするコンピュータを、portはコンソールのホストがリスニングするHTTPポートの番号、/oamconsoleは「ログイン」ページを指します。

注意:

構成の同時更新はサポートされていません。どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。複数の管理者が更新を同時に実行すると、Oracle Access Managementコンソールのシステム構成が一貫性のない状態になります。

この項では、Oracle Access Managementコンソールの概要を簡単に説明します。

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

- ページの要素

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

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

図2-3は、ログインの直後に表示されるOracle Access Managementコンソールの様子を示します。

図2-3 Oracle Access Managementコンソールの「ようこそ」ページ

「図2-3 Oracle Access Managementコンソールの「ようこそ」ページ」の説明

Oracle Access Managementコンソールには、検索コントロールの左上に指定機能のタブ、ナビゲーション・ツリーの上にメニューとツール・バーがあります。開いているページは右側に表示されます。現在は「ようこそ」ページが開いています。

次の各項目で詳細情報を提供します。

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

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

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

関連項目:

「コンソールでのコントロールの選択」

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

最初は「ようこそ」ページはコンソールの右側で、開いてアクティブな状態です。「ようこそ」ページのセクションには、特定の機能の簡単な説明や、表2-2にあるように特定のタスクをすぐに開始するための1つまたは複数のショートカット(選択可能なリンク)が含まれます。

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

「ようこそ」ページのショートカット・セクション

説明

「構成」ショートカット・パネルの各選択項目の詳細は、次のトピックを参照してください。

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

- 共通設定の管理

- 第IV部「Access Managerの設定とエージェントの管理」

- 第VIII部「Oracle Access Managementのセキュリティ・トークン・サービスの管理」

- 第VII部「Managing Oracle Access Management Identity Federation」

- 第IX部「Oracle Access Management Mobile and Socialの管理」

新規 ...をクリックして、新しいエージェント作成ページを開きます。

関連項目: 「システム構成のタブについて」

「新規アプリケーション・ドメイン」をクリックして、新しい「アプリケーション・ドメイン」ページを開きます。

関連項目: 「ポリシー構成のタブについて」

新規 ...をクリックして、リクエスタ・パートナまたはリライイング・パーティ・パートナの適切な詳細情報を入力できる新しいページを開きます。詳細は、「第VIII部: Oracle Access Managementのセキュリティ・トークン・サービス」を参照してください。

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

表2-3は、Oracle Access Managementコンソールの機能レベルのタブを示します。

表2-3 機能タブと説明

機能タブ名

説明

ポリシー構成

共有コンポーネントおよびアプリケーション・ドメインの定義にアクセスできます。コンソールに入ると、このタブがアクティブで、関連のナビゲーション・ツリーが画面左側に表示されます。

詳細は、「「ポリシー構成」タブについて」を参照してください。

システム構成

注意: これは、コンソールに入るときにはアクティブ・タブではありません。

ここに示すように、システム・レベル定義にアクセスできます。

詳細は、「「システム構成」タブについて」を参照してください。

次の各項目で特定のコントロールについて詳細情報を提供します。

- ナビゲーション・ツリー

- メニューおよびツール・バー

- 「表示」メニュー

- 「アクション」メニュー

関連項目:

「コンソールでのコントロールの選択」

2.5.1.2.1 ナビゲーション・ツリー

アクティブな構成タブのナビゲーション・ツリーが、コンソールの左側に表示されます。指定されたノードはグループを識別し、その下で処理を行う個々のインスタンスを選択できます。

「ポリシー構成」タブおよび「システム構成」タブのナビゲーション・ツリーのノードを、図2-4に示します。各ナビゲーション・ツリーの上のメニューおよびツール・バーを確認してください。

図2-4 メニューおよびツール・バーがあるナビゲーション・ツリー

「図2-4 メニューおよびツール・バーがあるナビゲーション・ツリー」の説明

関連項目:

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

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

2.5.1.2.2 メニューおよびツール・バー

メニューは、ナビゲーション・ツリーで選択された項目に処理を行うときに使用可能なコマンドを提供します。ほとんどのメニュー・コマンドは、すばやいアクセスのためにツール・バーのコマンド・ボタンとしても提供されています。コンソールの各ナビゲーション・ツリーの上にメニューおよびツール・バーが表示されます。

表示しているタブまたはサブタブに応じて、異なる集合のメニューおよびコマンド・ボタンが使用可能になります。さらに、コンソール内のいくつかの構成ページには、メニューおよびツール・バーを提供する表が含まれます。図2-5。

図2-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー

「図2-5 「共通構成」ナビゲーション・ツリーのメニューとツール・バー」の説明

関連する機能が使用可能な場合、コマンド・ボタンはフル・カラーで表示されます。機能が使用できない場合は、コマンド・ボタン(またはメニュー項目)はグレー表示されます。たとえば、ノードを開いて、選択した登録または定義を編集または削除できます。表2-4は、ツール・バーの各コマンド・ボタンの説明です。いくつかのボタンのみが使用可能です。

表2-4 ツール・バーのコマンド・ボタン

ボタン

定義

説明

作成

ナビゲーション・ツリーの選択したノードの下に新しいページが開き、ここに情報を入力して、選択したタイプの新しい構成を追加できます。新しいページは、アクティブなページとしてナビゲーション・ツリーの右側に開きます。

これは、サーバー・インスタンスや特定のエージェント・タイプ、ユーザー・アイデンティティ・ストア、非HTTPリソース・タイプまたはホスト識別子、アプリケーション・ドメインの下など、新しい構成を追加できるときに使用可能です。

別の方法として、表2-6にあるように、「アクション」メニューの「作成」コマンドを使用することもできます。

開く

ナビゲーション・ツリー内の選択したインスタンスを開きます。

編集

表示または変更のために、ナビゲーション・ツリーで選択したインスタンスを開きます。構成ページは、アクティブなページとしてナビゲーション・ツリーの右側に開きます。

または、インスタンス名をダブルクリックすれば、ページを編集用に表示することができます。

削除

選択した構成を削除します。削除された構成はナビゲーション・ツリーから除去されて、システムでアクセスできなくなります。たとえば、エージェント構成を削除すると、そのエージェントは登録解除されて使用できません。

別の方法として、表2-6にあるように、「アクション」メニューの「削除」コマンドを使用することもできます。

更新

WebブラウザでWebページを更新するときと同じように、ナビゲーション・ツリーを更新します。

デタッチ

選択した項目(たとえば、構成ページの結果表など)を分割して、1ページ全面に単独で表示します。

注意: デタッチされた表を表示している場合は、このボタンをクリックしてそれを対応するページに添付しなおして、標準のページ表示に戻すことができます。

ツール・バーのボタンとして使用可能なコマンドのほとんどは、メニューでも使用可能です。

関連項目:

- 「表示」メニュー

- 「アクション」メニュー

2.5.1.2.3 「表示」メニュー

図2-6は、「表示」メニューを示し、これは「ポリシー構成」および「システム構成」タブの両方で使用できます。

図2-6 「表示」メニュー

「図2-6 「表示」メニュー」の説明

使用できない項目(ナビゲーション・ツリーの選択時に使用できないもの)はグレー表示されます。「表示」メニューのコマンドの説明は、表2-5にあります。

表2-5 「表示」メニュー・コマンドの説明

コマンド

説明

展開

ナビゲーション・ツリーで選択したノードのアイテムをすぐに表示します。これによって構成ページが開いたり、アクティブにはなりません。

または、ナビゲーション・ツリーのノードの横にあるアイコンをクリックします。

下をすべて開く

選択したノードにあるすべてを、すぐに表示します。たとえば、「アプリケーション・ドメイン」をクリックして、「下をすべて開く」をクリックすると、すべてのアプリケーション・ドメインが表示されます。

下をすべて閉じる

選択したノードをすぐに閉じて、その内容を非表示にします。これによってページが閉じたり、開いたりはしません。

すべて開く

ナビゲーション・ツリーのすべてのノードとインスタンスを、すぐに表示します。開いているページには何も影響はありません。

すべて閉じる

ナビゲーション・ツリーのすべてのノードとインスタンスを、すぐに非表示にします。開いているページには何も影響はありません。

最初までスクロール [Ctrl] + [Home]

ナビゲーション・ツリーまたは結果表の最初の項目を検索、表示します。

最後までスクロール [Ctrl] + [End]

ナビゲーション・ツリーまたは結果表の最後の項目を検索、表示します。

2.5.1.2.4 「アクション」メニュー

このメニューは、「システム構成」タブがアクティブなときのみ使用可能です。図2-6は「アクション」メニューを示し、これはナビゲーション・ツリーの選択されたインスタンスに対する適切なコマンドを提供します。たとえば、ナビゲーション・ツリーでアイデンティティ・ストア・インスタンスを選択している場合、「アクション」メニューのコマンドの1つを使用して、インスタンスをモニターできます。

図2-7 「アクション」メニュー

「図2-7 「アクション」メニュー」の説明

このメニューの特定のコマンドは、ツール・バーのコマンド・ボタンから使用できる機能を反映しています。使用できない項目(ナビゲーション・ツリーの選択時に使用できないもの)はグレー表示されます。「アクション」メニューのコマンドの説明は、表2-6にあります。

表2-6 システム構成、「アクション」メニュー、コマンドの説明

コマンド

説明

開く

ナビゲーション・ツリーで選択したインスタンスの構成ページを開きます。ナビゲーション・ツリーでノードが選択されている場合は、これは使用できません。

または、ナビゲーション・ツリーでインスタンス名をダブルクリックすると、ページが開きます。

作成

新しいページがアクティブになり、それに情報を入力して新しい構成を定義できます。

別の方法として、表2-4にあるように、ツール・バーの「作成」(+)ボタンをクリックすることもできます。

モニター・メニュー

監視可能なインスタンスがあるときに使用可能になります。ナビゲーション・ツリーでサーバー・インスタンスが選択されている場合、「モニター・メニュー」を選択して、そのインスタンスの関連情報を表示できます。詳細は、第9章を参照してください。

注意: モニターできないインスタンスを選択しているときは、この項目は無効になります。

共通プロパティを開く

このリリースでは、無効化されています。「システム構成」タブの「共通構成」セクションにある「共通設定」に置き換えられています。

削除

選択されたインスタンスの登録を削除します。削除された登録はナビゲーション・ツリーから除去されて、システムでアクセスできなくなります。たとえば、エージェント登録を削除すると、そのエージェントは登録解除されて使用できません。

別の方法として、表2-4に示すように、ツール・バーの「削除」(x)ボタンをクリックします。

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

「ようこそ」ページと同じように、開いているページはすべてコンソールの右側に表示されます。

アクティブなコンテンツ・ページが表示され、関連の設定を追加したり、表示や変更可能な作業領域となります。名前の付いたタブは、書類フォルダのタブのように開いている各ページを識別します。アクティブなページのタブは白です。

各構成タブ(「ポリシー構成」タブまたは「システム構成」タブ)に、最大10ページを同時に開くことができます。現在アクティブな構成タブの開いているページで、名前の付いたタブのみが表示されます。

アクティブなページのみが表示され、開いている他のページの名前付きタブが1行に収まる限り含まれます。名前の付いたタブをクリックすると、対応するページをアクティブにできます。開いているページの名前付きタブが1行に入りきらない場合、ポインタが提供され、それを使用して非表示のページから選択したり開くことができます。図2-8は、同時に開かれている複数のページを示します。各ページの名前付きタブと、非表示のページにアクセスする(またはアクティブなページや複数のページを閉じる)ためのコントロールが示されています。

図2-8 「オープン」ページのタブおよびページ・コントロール

「図2-8 開いているページのタブおよびページ・コントロール」の説明

各ページは一度だけ表示されます。同じページを何度も開こうとしても、警告は表示されません。ただし、そのページは一度だけしか表示されません。

注意:

同じ項目のページを2回以上開く場合、警告は表示されません。

開いているページで使用できるコントロールは、表2-7に記載されています。

関連項目:

「コンソールでのコントロールの選択」

表2-7 開いているページのコントロール

ページ・コントロール

定義

説明

非表示のページのリストを表示します。

開いているすべてのページを同時に表示できないときには、ポインタをクリックすると、非表示のページのリストが表示されます。

アクティブなページを閉じます。

このボタンをクリックすると、アクティブなページが閉じます。

注: 「適用」をクリックする前にページを閉じると、警告なしにすべての変更や追加が破棄されます。変更は失われます。これを使用すれば、保持したくない変更をキャンセルできます。

複数のページを閉じます。

- このボタンをクリックすると、複数の開いているページが閉じられます。

- 表示されるダイアログ・ボックスで、閉じる各ページ名の横にあるボックスをクリックします。

- アクションを完了するには、「OK」をクリックします。

注: 「適用」をクリックする前にページを閉じると、警告なしにすべての変更や追加が破棄されます。変更は失われます。これを使用すれば、保持したくない変更をキャンセルできます。

2.5.2 ページの要素

コンソールのページには、表2-8にあるグラフィカル・ユーザー・インタフェースの要素が1つ以上含まれます。コンソールの各要素の例は、図2-8を参照するか、コンソールにログインして確認してください。

表2-8 ページの要素と説明

ページ要素

説明

名前付きタブ

コンソール右側の開いている各ページを識別します。また、関連する下位レベルの設定も表示されます。例については、図2-2を参照してください。

ページ・コントロール

1つまたは複数のページを閉じることができます。表2-7を参照してください。

「適用」ボタン

ページへの変更や追加を送信します。

名前の付いたテキスト・ボックス

キーボードを使用して、名前の付いたフィールドに適切な詳細を入力可能にします。

「オプション」ボタン

いくつかのオブジェクトから1つを選択できます。たとえば、オプション・ボタンをクリックして、状態(有効または無効)やセキュリティ・モード(オープン、簡易、証明書)を定義することができます。

表

現在の仕様や新しい仕様のスペースを表示します。テーブルには、ページ・レベルやオプションのボタンに依存しない独立したコマンド・ボタンがあります。

テーブルのコマンド・ボタン

次のことが可能です。

新しい行または定義を表に追加します。

選択した行または定義を表から削除します。

ドロップダウン・リスト

選択メニューを提供するために、特定のページに表示されます。情報が提供されているときには、このメニューから選択できます。

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

この項では、ナビゲーション・ツリーで目的のノードやインスタンスを選択する方法と、コンソールでのコマンドやページ・コントロールの選択について説明します。通常の選択のガイドラインが適用されます。

表2-9は、選択肢とコントロールについて説明します。

表2-9 選択タスクとコントロール

タスク

コントロール

説明

ノードを開く

ナビゲーション・ツリーで目的のノードの横にある展開ボタン(>)をクリックすると、その中にあるノードやインスタンスが表示されます。

ノードを閉じる

ナビゲーション・ツリーで目的のノードの横にある閉じるボタン(V)をクリックすると、その下にあるノードやインスタンスが非表示になります。

「表示」メニューの表示

マウス・ボタンを右クリック

ナビゲーション・ツリーで希望するノードを右クリックすると、ポップアップの「表示」メニューが表示されます。

アクティブ化

マウス・ボタンをクリック

クリックして以下の希望する項目をアクティブ化します。

- 「機能」タブ: システム構成、ポリシー構成、参照、検索

- 表示または変更のために関連する低レベルの設定を表示する、ページ上の名前付きタブ: 「リソース」や「レスポンス」など。

- ページを表示(アクティブ化)するための名前付きページ・タブ

- ページに情報を入力するためのテキスト・フィールド

- ページ・コントロール(表2-7に記載されている閉じるボタンやすべてを閉じるボタン)

開く

項目をクリックして、「開く」コマンド・ボタンを選択

項目をクリックして、「開く」コマンド・ボタンを選択します。

- リソース・タイプ名

- ホスト識別子の定義名

- 認証のスキーム名

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

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

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

- エージェント・インスタンス名

- サーバー・インスタンス名

- ユーザー・アイデンティティ・ストアのインスタンス名

- データベースのインスタンス名

- 認証モジュール名

- システム・ユーティリティ名

ハイライト

カーソルをドラッグ

ハイライトするには、ボックスのテキストに沿ってカーソルをドラッグします。

選択

マウス・ボタンをクリック

処理を行いたい項目をクリックします。たとえば、以下の項目をクリックします。

- アイコン、ノード、またはナビゲーション・ツリーのインスタンス名(共有コンポーネントは一例です)

- 「検索」ボタン: 指定した条件に基づいて検索を開始します。

- ナビゲーション・ツリーで選択した項目に処理を行うためのメニュー名およびコマンド

- 直ちにアクションを実行するためのコマンド・ボタン
メニューおよびツール・バーのボタン(表2-4)

ページを閉じるボタン(表2-7)

- ページまたは表のコマンド・ボタン:
「適用」: アクティブなページで追加や変更を送信します。

表やセクションのボタン(表2-8)

新しい行の追加。

選択した行の削除。

- リンク: ヘルプ、およびサインアウトは例です。

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

アクティブなタブは白く表示されます。「表示」メニューは、常に使用可能です。「アクション」メニューは、「システム構成」タブがアクティブな場合のみ使用可能です。

この項では、次のタブで使用可能なOracle Access Managementの主要な機能を簡単に説明します。

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

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

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

「システム構成」タブには、関連する機能がまとめられたいくつかのセクションがあります。

- 共通構成

- Access Manager

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

- アイデンティティ・フェデレーション

- Mobile and Social

セクション名をクリックすると、ナビゲーション・ツリーが開き、ツリーの上部に付属のメニューとツール・バーが表示されます。

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

Oracle Access Managementコンソールの「ポリシー構成」タブは、管理者に認証ポリシー、認可ポリシーおよび共有シングル・サインオン(SSO)コンポーネントへのアクセス権を提供します。

「参照」サブタブは、ナビゲーション・ツリーを表示します。「検索」サブタブは、ポリシー要素の検索結果を表示します。

コンソールのコマンド・ボタンやページ・コントロール、メニュー項目のナビゲーションと選択については、「コンソールのレイアウトおよびコントロール」を参照してください。

また、「表示」メニューにあるコマンドを使用して、ナビゲーション・ツリーで選択したノードを展開したり、すべてのノードを同時に展開することもできます。たとえば、「表示」メニューから「すべて開く」をクリックすると、すべてのノードと関連のインスタンスが同時に表示されます。

関連項目:

第III部「共通のロギング、監査、パフォーマンス・モニタリングおよびチューニング」

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

Oracle Access Management管理者は、個々のエージェント、サーバー・インスタンス、データ・ソース、共有コンポーネントおよびアプリケーション・ドメインの構成詳細を、Oracle Access Managementコンソールから表示できます。

この例では、OAMエージェント(Webgate)の構成詳細を表示します。ただし、同様の手順を使用して、サーバー・インスタンスやデータ・ソース、アプリケーション・ドメイン、共有コンポーネントの構成詳細を表示できます。

または、カスタムWLSTコマンドを使用して、エージェントやサーバー詳細を閲覧できます。

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

コンソールを使用して構成詳細を表示する手順

1. Oracle Access Managementコンソールに移動し、通常どおりログインします。例:

https://hostname:port/oamconsole

サンプルのURLでは、hostnameはOracle Access Managementコンソールをホストするコンピュータを、portはコンソールのホストがリスニングするHTTPポートの番号を指し、/oamconsoleはOracle Access Managementコンソールを識別します。

2. システムを構成します。

1. 「システム構成」(または「ポリシー構成」)タブをクリックします。

2. ナビゲーション・ツリーで、内容に表示する目的のセクション名をクリックします。例:
Access Manager

3. ノードの展開: 目的のノードの横にある展開アイコンをクリックします(または「表示」メニューから「すべて開く」をクリックします)。

4. ノードを開く: 名前をダブルクリックします(名前をクリックして強調表示し、次にツール・バーのフォルダ・アイコンをクリックします)。

5. 一意のインスタンスを開く: 目的のインスタンス名をダブルクリックして、構成を表示します。またはインスタンスをクリックして、ツール・バーの「編集」ボタン(鉛筆の形をしたアイコン)をクリックします。

6. ページを参照して、関心のある特定の詳細があれば記録します。

7. 右上隅のXコントロールをクリックして、ページを閉じます。

3. ポリシー構成: 「ポリシー構成」タブをクリックしてアクティブにします。「システム構成」タブ内の操作と同じように、ノード、インスタンスおよびページを展開したり、表示したり、開いたり閉じたりします。

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

Oracle Access Managementコンソールには、特定の要素(エージェントやアプリケーション・ドメイン、リソースなど)に対する検索コントロールが用意されています。次に、「検索」ページの例を示します。このページは、OAMエージェントの検索に使用します。

図2-9 OAMエージェントの「検索」ページの例

「検索」ページは、検索対象のエンティティに応じて、それぞれ異なります。どのような検索でも、フィールドを空白のままにすると、すべてが表示されるようになります。また、検索対象の正確な名前がわからない場合は、ワイルドカード(*)文字が使用できます。ただし、検索基準の大文字は、検索する項目の大文字と一致する必要があります。

検索コントロールのいくつかには、検索条件を保存する機能があります。検索結果の表からは、表示や編集のために開く項目を選択できます。

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

Oracle Access Managementコンソールを使用中はいつでも、ページの上にある「ヘルプ」リンクをクリックして詳細を確認できます。オンライン・ヘルプのトピックは、このマニュアルのオンライン版の情報にリンクしています。

一般的に、Oracle Access Managementコンソールの「ヘルプ」を選択すると表示されるトピックは、英語と日本語のみで表示されます。オンライン・ヘルプは、9つのADMIN言語には翻訳されていません。

「ようこそ」タブをクリックすると、実行可能なアクションを説明したトピックのリストを表示することができます。特定のヘルプ・トピックについては、以下の手順を使用してください。

特定のヘルプ・トピックを検索する手順

1. Oracle Access Managementコンソールから、タブまたはナビゲーション・ツリーの名前付きノードをクリックします。

2. コンソールの右上隅にある「ヘルプ」をクリックします。

3. 新しいウィンドウに表示されるページを確認して、以下のリンクのどれかを選択して以下を実行します。

- 詳細 — このリンクをクリックして、詳細を表示します。

- 方法 — このリンクをクリックして、ヘルプ検索に関連するタスクの実行手順を表示します。

- 目次 — 左の「ヘルプ」ペインで、コンテンツを展開してすべてのヘルプ・トピックおよびオンライン・マニュアルのトピックすべてを表示します。

- 検索 — 検索ウィンドウが表示され、そこでヘルプの検索条件を入力できます。

4. 必要に応じて以下のボタンをクリックします。

- 表示 — 表示オプションのセットを表示します。

- 矢印 — 前のページに戻ったり、次のページへ移動します。

- 「プリンタ」アイコン — ページを印刷します。

- 「エンベロープ」アイコン — ページを電子メールで送信します。

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

コンソールではなく、キーボードを使用して様々なタスクを実行するために、コマンドライン・ツールがいくつか用意されています。これらのコマンドを使用した後は、コンソールで構成が使用できます。

- リモート登録ツールのoamregを使用すると、エージェントのリモート登録、およびデフォルトのアプリケーション・ドメインの作成が可能です。

関連項目:

第13章「OAM 11gエージェントの登録および管理」

- アップグレード・アシスタント(UA)を使用すると、OSSO 10gの構成をOracle Access Managementに転送できます。

関連項目:

- Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

- Oracle WebLogic Scripting Tool (WLST)には、Oracle Access Managementコンソールで実行可能なタスクについて、数多くのカスタムOAMコマンドラインの選択肢が用意されています。

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

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

ロギングは、コンポーネントがファイルにメッセージを書き込むためのメカニズムです。これらのメッセージは、異なる詳細レベルで記録できます。Oracle Access Managementのコンポーネントは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとガイドラインを使用しています。

Oracle Fusion Middlewareにおいて、監査はアカウンタビリティを実現する手段であり、また、誰が、いつ、何を行ったかというタイプの質問への回答を提供します。Oracle Access Managementは、Oracle Fusion Middlewareの共通監査フレームワークを使用し、大量のユーザー認証イベントと認可イベント、および管理イベント(システムへの変更)の監査を支援します。Oracle Fusion Middlewareの共通監査フレームワークを使用すれば、ロギングと例外を一様な形で取り扱い、すべての監査イベントの診断を行うことができます。

管理者は、Oracle Fusion Middleware Controlを使用して、Access ManagerおよびSecurity Token Serviceについてのパフォーマンスおよびログ・メッセージをモニターできます。

詳細は、第III部「共通のロギング、監査、パフォーマンス・モニタリングおよびチューニング」を参照してください。

- 第6章「コンポーネント・イベント・メッセージのロギング」

- 第7章「Webgateイベント・メッセージのロギング」

- 第8章「管理イベントとランタイム・イベントの監査」

- 第9章「Oracle Access Managementコンソールを使用したパフォーマンスのモニタリング」

- 第10章「Fusion Middleware Controlによるパフォーマンスおよびログの監視」

関連項目:

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

3 共通サービスおよび証明書の検証の管理

この章では、Oracle Access Managementに統合されたサービスで一般的に使用されるプロパティの構成方法を説明します。この章の内容は次のとおりです。

- 共通構成要素の概要

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

- 共通設定の管理

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

3.1 前提条件

第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」

3.2 共通構成要素の概要

この項では、共通のシステム構成要素の概要を示します。特に明記しないかぎり、共通構成要素は、ドメイン内のすべてのOAMサーバーおよびサービスによって共有されます。図3-1は、「システム構成」タブの「共通構成」セクションを示します。

図3-1 「システム構成」の「共通構成」ノード

「図3-1「システム構成」の「共通構成」ノード」の説明

表3-1は、「システム構成」タブの「共通構成」セクションを示します。ここの項目は、スイートのすべてのサービスに適用します。また、それぞれについての詳細情報を検索できます。

表3-1 「システム構成」: 「共通構成」セクション

ノード

説明

使用可能なサービス

すべてのサービスにアクセスできます。

関連項目: 「使用可能なサービスの有効化または無効化」

共通設定

セッション・プロパティ、Oracle Coherence、監査構成、デフォルトおよびシステム・アイデンティティ・ストアなど、すべてのOracle Access Managementサービスに適用するプロパティと設定を提供します。

関連項目: 「共通設定の管理」

サーバー・インスタンス

すべての登録されているOAMサーバー・インスタンスにアクセスできます。

関連項目: 第5章「サーバー登録の管理」

セッション管理

アクティブ・セッション管理操作にアクセスできます。

関連項目: 第14章「セッションの管理」

パスワード・ポリシー

Access Managerのグローバル・パスワード・ポリシーの管理操作にアクセスできます。

関連項目: 第16章。

- 「グローバル・パスワード・ポリシーの管理」

- 「DCC対応の11g Webgateと認証ポリシーの構成」

証明書検証

証明書失効リストおよびOCSP/CDP設定にアクセスできます。

関連項目: 「グローバル証明書検証および失効の管理」

データ・ソース

Oracle Access Managementの登録済ユーザー・アイデンティティ・ストアにアクセスできます。

関連項目: 第4章「データ・ソースの管理」

プラグイン

Oracle Access Managementサービスへの認証機能拡張するプラグインをインポート、配布、アクティブ化(または非アクティブ化)および削除するメカニズムを提供します。

- 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

- 「インポートおよびファイルのアップロードの制限」。

- 独自のカスタム・プラグインを作成する方法の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイド

3.3 使用可能なサービスの有効化および無効化

図3-2は、「共通構成」セクションの「使用可能なサービス」ページを示しています。このページには、サービスの状態と、サービスの有効化または無効化を制御するコントロールが表示されています。最初は、「Access Manager」のサービスのみが有効になっています。Oracle Access Management管理者は、関連する機能を使用するために、Oracle Access Managementコンソールにログインしてサービスを有効化する必要があります。この例外は、アイデンティティ・コンテキストで、デフォルトで有効化され、無効化するコントロールがありません。

図3-2 「システム構成」、「使用可能なサービス」ページ(右)

「図3-2 「システム構成」、「使用可能なサービス」ページ(右)」の説明

サービス名の横にある「ステータス」フィールドの緑のチェック・マークは、サービスが有効であることを示します。中に線がある赤の円は、該当するサービスが無効であることを示します。

表3-2 共通のサービス

サービス

説明

Access Manager

「Access Manager」の機能はデフォルトで有効化されています。「Access Manager」サービスは、SSOポリシーの設定と、Access Manager、「共通構成」、およびRESTサービスを有効化するタイミングの構成を要求されます。

デフォルト: 有効

ほかにAccess Managerおよび共通構成に必要なサービスはありません。

アイデンティティ・フェデレーション

フェデレーション・パートナを管理するには、有効化する必要があります。

デフォルト: 無効

注意: Identity Federationがもう1つの認証モジュールであるためAccess Managerサービスも有効化する必要があります。

関連項目: 第VII部: Oracle Access ManagementのIdentity Federationの管理

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

このサービスを有効化すると、セキュリティ・トークン・サービスの機能を使用できます。

デフォルト: 無効

Access Managerサービスは必要ありません。

関連項目: 第VIII部: Oracle Access Managementのセキュリティ・トークン・サービスの管理

Mobile and Social

モバイルおよびソーシャル・サービスは、次のいずれかの方法でデプロイできます。

- Access ManagerはOracle Access Managementの一部としてデフォルトで有効化されますが、Mobile and SocialをAccess Managerとともに使用するには手動で有効化する必要があります。

- Oracle Access Management Mobile and Socialのみ。この場合、Mobile and Socialのみが独立して動作するように(またはリモートAccess Managerを使用するように)デフォルトで有効化されます。

関連項目: 第IX部「Oracle Access Management Mobile and Socialの管理」

前提条件

WebLogic AdminServerが稼動している必要があります。

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

サービスを有効化または無効化する手順

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「共通構成」セクション
「使用可能なサービス」ノード

2. サービスの有効化: 目的のサービス名の横にある「有効化」をクリックします(または「ステータス」のチェック・マークが緑であることを確認します)。

3. サービスの無効化: 目的のサービス名の横にある「無効化」をクリックします(または「ステータス」のチェック・マークが赤であることを確認します)。

3.4 共通設定の管理

共通設定は、すべてのOAMサーバー・インスタンスおよびサービスに適用されます。ここでは、次の内容について説明します。

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

- 共通設定の管理

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

共通設定は、スイート内のすべてのサービスに適用されます。図3-3は、「共通設定」ページの名前付きセクションを示し、これらを展開すると関連する要素および値を表示できます。

図3-3 「共通設定」ページ(折りたたんだ表示)

「図3-3 「共通設定」ページ(折りたたんだ表示)」の説明

Oracle Access Management管理者は、表3-3で説明されているように、単一のサービスのみでなくスイート全体で使用されるパラメータを制御および指定できます。

表3-3 共通設定

タブ名

説明

セッション

セッション構成とは、セッションのライフサイクル要件を管理するプロセスと、グローバル・ログアウトを可能にするためのイベントの通知を指します。エンティティのセッションのログアウトでログアウトがすべてのエンティティに伝播していることを確認するには、OSSOエージェント(mod_osso)のグローバル・ログアウトが必要です。

関連項目: 「共通設定の管理」。

コヒーレンス

すべてのOAMサーバーで共有される共通のOracle Coherence設定は、個々のOAMサーバーの設定とは異なります。ただし、どちらの場合でも、Oracleサポートの指示がない限りは、これらの設定を調整しないことをお薦めします。

関連項目: 「共通設定の管理」。

監査構成

Oracle Access Managementは、多数の管理イベントおよび実行時イベントの監査、統一されたロギングおよび例外処理、すべての監査イベントの診断をサポートしています。Oracle Access Management監査構成は、oam-config.xmlに記録されます。

関連項目: 「共通設定の管理」および「Oracle Access Managementコンソールを使用した監査構成について」

デフォルトおよびシステム・アイデンティティ・ストア

このセクションは、デフォルト・アイデンティティおよびシステム・ストアを識別し、これは同じ(または異なる)ものになる場合があります。

関連項目: 「共通設定の管理」。

関連項目:

すべてのOAMコンポーネントに共通の他の操作の詳細:

- 第6章「コンポーネント・イベント・メッセージのロギング」

- 第9章「Oracle Access Managementコンソールを使用したパフォーマンスのモニタリング」

3.4.2 共通設定の管理

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、「共通設定」ページの表示および変更の実行ができます。それぞれの主な手順には、このマニュアル内に記載されている詳細への参照が含まれています。

前提条件

OAMサーバーが稼動している必要があります。

共通設定を管理する手順

1. 「システム構成」タブから、「共通構成」セクションを展開し、ナビゲーション・ツリーの「共通設定」をダブルクリックします。

2. セッション:

1. 「共通設定」ページで「セッション」セクションを展開します。

2. 必要に応じて、各リストの横にある矢印キーをクリックしてセッションのライフサイクル設定を増減させます。
セッションの存続期間(分)
アイドル・タイムアウト(分)
1ユーザー当たりの最大セッション数

3. データベース永続性: ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します(または選択を解除してデータベース永続性を無効化します)。

4. 「適用」をクリックして変更を送信します。

5. 関連項目: 第14章「セッションの管理」。

3. コヒーレンス: 「共通のコヒーレンス設定の表示」を参照してください。

4. 監査構成:

1. 「監査構成」セクションを開きます。

2. 「監査構成」セクションで、使用環境の詳細を正しく入力します。
最大(ログ)ディレクトリ・サイズ
最大(ログ)ファイル・サイズ

フィルタ有効
「フィルタ・プリセット」(リストから選択して監査データの冗長性を定義します)
監査構成表: 「追加」(+)ボタンまたは「削除」(x)ボタンを使用してユーザーを指定します。

3. 「適用」をクリックして「監査構成」を送信します(または変更を適用しないでページを閉じます)。

4. 関連項目: 第8章「管理イベントとランタイム・イベントの監査」。

5. デフォルト・ストアおよびシステム・ストア

1. 「デフォルトおよびシステム・アイデンティティ・ストア」セクションを展開します。

2. システム・ストア(またはデフォルト・ストア)の名前をクリックし、構成ページを表示します。

3. 詳細は、「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

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

図3-4は、「コヒーレンス」セクションを展開した「共通設定」ページを示します。

注意:

Oracleサポートの支援なしにこれらの設定を変更しないことをお薦めします。

図3-4 共通のコヒーレンス設定

「図3-4 共通のコヒーレンス設定」の説明

表3-4は、これらの設定について説明します。

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

要素

説明

ポート

1から65535の範囲の値を指定できます。

クラスタ・アドレス

224.1.255.0から239.255.255.255の値が許可されます。

存続時間

0から255の値がサポートされます。

クラスタ・ポート

1から65535の範囲の値を指定できます。

共通のコヒーレンス設定を表示する手順

1. 「システム構成」タブから「共通構成」セクションを展開し、「共通設定」をダブルクリックします。

2. 「共通設定」ページで「コヒーレンス」セクションを展開します。

3. 終了したらページを閉じます。変更はしないでください。

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

ここでは、次の内容について説明します。

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

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

- 証明書検証の有効化

- CRL配布ポイント拡張の構成(CDP)

3.5.1 証明書検証および失効について

Oracle Access Managementは、オンライン証明書ステータス・プロトコル(OCSP)を使用して、OAMサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。

- OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。

- OCSPは、証明書ステータスを含むサーバーとそのステータスを通知されるクライアント・アプリケーションの間の通信構文を指定します。

OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻します。

証明書検証モジュールはSecurity Token Serviceによって使用され、次を使用してX.509トークンを検証し、(必要に応じて)証明書が失効しているかどうかを検証します。

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

- Online Certificate Status Protocol

- CRL配布ポイント拡張(CDP拡張)

証明書失効リスト(CRL)は、公開鍵インフラストラクチャを使用する場合のネットワーク内のサーバーへのアクセスを保守する一般的な方法です。CRLは、デジタル証明書ステータスとペアになったサブスクライバのリストです。失効した証明書は理由とともにリストされます。証明書発行の日付および発行したエンティティも含まれます。さらに、各リストには次のリリースの提示日が含まれます。潜在的ユーザーがサーバーにアクセスしようとすると、サーバーはその特定のユーザーのCRLエントリに基づいてアクセスを許可または拒否します。

図3-5は、コンソールのグローバル証明書検証のOCSP/CDP設定を示します。

図3-5 グローバル証明書検証のOCSP/CDP設定

「図3-5 グローバル証明書検証のOCSP/CDP設定」の説明

図3-6は、コンソールを使用したCA CRLの追加を示します。

図3-6 「証明書失効リスト」ダイアログ・ボックス

「図3-6 「証明書失効リスト」ダイアログ・ボックス」の説明

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

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。これは、連続したデータ保護の有効化および現在のCA証明書失効リストのインポートによって実現されます。

関連項目:

証明書検証および失効について

前提条件

CA証明書失効リスト(CA CRL)をインポートできるようにします。

証明書失効リストを管理する手順

1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開き、次のようにします。

1. 「有効」ボックスが選択されていることを確認します。

2. 追加: 「追加」ボタンをクリックし、CRLファイルを参照して選択し、「インポート」をクリックします。

3. 削除: 表内のリスト名をクリックし、「削除」(x)ボタンをクリックし、確認が表示されたら確認します。

4. 構成を保存します。

3. CRLを検索します。

1. 表を確認します。

2. 例による問合せを有効化し、表のヘッダー・フィールドにフィルタ文字列を入力します。

4. 「証明書検証の有効化」に進みます。

3.5.3 証明書検証の有効化

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。これは、オンライン証明書ステータス・プロトコルを有効化することによって実現されます。

関連項目:

証明書検証および失効について

前提条件

CA証明書失効リスト(CA CRL)をインポートできるようにします。

証明書検証を管理する手順

1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開きます。

1. 「有効」ボックスが選択されていることを確認します。

2. 構成を保存します。

3. OCSP/CDPノードを開きます。

1. OCSPを有効化します。

2. OCSPサービスのURLを入力します。

3. OCSPサービスのサブジェクトDNを入力します。

4. この構成を保存します。

5. 「CRL配布ポイント拡張の構成(CDP)」に進みます。

3.5.4 CRL配布ポイント拡張の構成(CDP)

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用してサーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスできます。

関連項目:

証明書検証および失効について

CDPを構成する手順

1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」ノードを開きます。

1. 「有効」ボックスが選択されていることを確認します。

2. 構成を保存します。

3. OCSP/CDPノードを開きます。

1. CDPを有効化します。

2. この構成を保存します。

4 データソースの管理

この章では、Oracle Access Managementコンソールでデータソースを登録および管理する手順について説明します。この章の情報は、Oracle Access Managementコンソールから使用可能なすべてのサービスに共通します。

この章の内容は次のとおりです。

- 前提条件

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

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

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

- 管理者ロールの管理

- ポリシーおよびセッション・データベースの管理

4.1 前提条件

この項では、この章のタスクの要件を明らかにします。この章のタスクを開始する前に、次のトピックを確認してください。

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

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

- 管理者ロールの管理

注意:

デフォルトのLDAPグループAdministratorsは、「Oracle Access Management管理者の概要」で説明されているように、Oracle Fusion Middleware構成ウィザードを使用した初回のデプロイメント時に設定されます。

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

「データ・ソース」という用語はJava Database Connectivity(JDBC)のもので、Access Managerにおいてユーザー・アイデンティティ・ストアのコレクションまたはポリシーのデータベースを指すときに使用します。

Access Managerは、通常、エンタープライズにインストールされるデータソースのタイプをいくつかサポートしています。表4-1に示すように、各データソースは様々な情報タイプのストレージ・コンテナです。

表4-1 Oracle Access Managementのデータソース

データソース

説明

ユーザー・アイデンティティ・ストア

一元化されたLDAPストレージで、ユーザー指向の集計データが系統だって維持管理されます。

Access Managerにはアイデンティティ・サービスは含まれず、ネイティブのユーザーやグループ、ロール・ストアはありません。

デフォルトでは、Access Managerは、WebLogic Serverドメインの埋込みLDAPをユーザー・アイデンティティ・ストアとして使用します。ただし、数多くの他の外部LDAPリポジトリをユーザー・アイデンティティ・ストアとして登録することも可能です。この場合、管理者ロールおよびユーザーを含むシステム・ストアとして1つのストアを指定する必要があります。

データベース

コンテンツのアクセスや管理、更新が簡単となるように、整理されて格納された情報のコレクション。

Access Managerのポリシー・データには、パスワード管理データなどがあり、Access Manager固有のスキーマで拡張されたデータベースに格納してAccess Managerに登録する必要があります。

- セッション・ストア: デフォルトでは、Access Managerのセッション・データはポリシー・ストアに移行されたメモリー内のキャッシュに格納されます。本番環境では、ポリシー・データ用と、その他のセッション・データー用に独立したデータベースを用意できます。セッションとセッション・データの詳細は、第14章を参照してください。

- 監査ストア: 監査データは、ファイルまたは個別のデータベース(ポリシー・ストアのデータベース以外)に格納できます。管理イベントおよび実行時イベントの監査の詳細は、第8章を参照してください。

Javaキーストア

Oracle Access Managementに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成されるセキュリティ・キーの格納に使用されます。すべてのOAMエージェントおよびOSSOエージェントは、他のエージェントが読み取ることができない秘密鍵を持っています。また、Oracle Coherenceベースのセッション管理トラフィックを暗号化するキーもあります。ただし、キーストアは不可視であり、管理や変更はできません。

キーのパスワードは資格証明ストアに格納されます。

データソースは、Access Managerにインストールして登録する必要があります。こうすることで、ユーザーが保護されたリソースにアクセスしようとしたときに認証を可能にします(また、認証時に許可を受けたユーザーのみがリソースにアクセスできるようにします)。

初回のデプロイメント・プロセス中(『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照)に、埋込みLDAPストアがユーザー・アイデンティティ・ストアとして使用されます。Access Managerの構成データは、XMLファイルoam-config.xmlに格納されます。

注意:

変更にはOracle Access ManagementコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。oam-config.xmlは編集しないでください。

表4-2に、Oracle Access Managementに使用できるサービスと、そのサービスのデータソースに関する情報の入手先を示します。

表4-2 Oracle Access Managementのサービスのデータソース

サービス

説明

Access Manager

Access Managerは、この章の次の項で説明するデータソースを使用する、シングル・サインオンに認証を提供します。

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

- ポリシー、パスワード管理およびセッションのデータベース・ストアについて

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

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

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

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

アイデンティティ・フェデレーション

Identity Federationは、複数のアイデンティティ・ストアをサポートし、アイデンティティ・パートナ単位で割り当てることができます。アイデンティティ・ストアは個別にOracle Access Managementに登録する必要があります。アイデンティティ・ストアがアイデンティティ・パートナで定義されていない場合は、指定されたデフォルト・ストアが使用されます。

- フェデレーション用のアイデンティティ・プロバイダ・パートナの管理

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

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

指定されたデフォルト・ストアのみを使用します。次のトピックを参照してください。

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

- 第33章「Security Token Serviceの証明書と鍵の管理」

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

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

Mobile and Social

Mobile and Socialは、ユーザー認証やユーザー・プロファイル・サービス用のディレクトリ・サーバーを参照できるように、独自のアイデンティティ・ディレクトリ・サービス構成を提供しています。

Access Managerやその他のサービスが依存するグローバル(共通)データ・ソースへの依存性は存在しません。

関連項目:

- 第38章「モバイル・サービスの構成」: アイデンティティ・ディレクトリ・サービスの構成とユーザー・プロファイル・サービスの詳細

関連項目:

- 「グローバル・パスワード・ポリシーの管理」および「DCC対応の11g Webgateと認証ポリシーの構成」

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

- 第14章: Oracle Coherenceを使用してメモリー内に格納され、Oracle Databaseに伝播されたセッションの詳細

- 第8章: 監査ファイルまたは個別のOracle Databaseに格納された監査データの詳細

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

ユーザー・アイデンティティ・ストアは一元化されたLDAPストアで、管理者およびユーザー指向の集計データが系統だって保持管理されます。Oracle Access Managementでは複数のLDAPベンダーがサポートされており、Oracle Access Managementとそのサービスによる使用のために複数のLDAPストアを登録できます。

Oracle Access Managementでは、アイデンティティ・ドメインとして各ユーザー移入とLDAPディレクトリ・ストアに対応しています。それぞれのアイデンティティ・ドメインは構成済のLDAPユーザー・アイデンティティ・ストアにマップされます。このストアはOracle Access Managementによって登録する必要があります。

Oracle Fusion Middleware構成ウィザードを使用したWebLogic Serverドメインの最初の構成時、組込みLDAPのみがユーザー・アイデンティティ・ストアとして構成されます。組込みLDAP内では、weblogicがデフォルトの管理者としてあらかじめ設定された管理者グループが作成されます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』

注意:

組込みLDAPは、ユーザーが10,000人未満のときにパフォーマンスが最も良くなります。ユーザーがこれより多い場合は、別のエンタープライズLDAPサーバーを考慮してください。高可用性構成では、ユーザー・アイデンティティ・ストアとして外部LDAPディレクトリを使用することをお薦めします。

ユーザーがAccess Managerに保護されたリソースにアクセスすると、指定したデフォルトのストアのみでなく、任意のストアに対して認証されます。ただし、いくつかの考慮事項があります。

- システム・ストア: 1つのユーザー・アイデンティティ・ストアのみをシステム・ストアとして指定できます(さらに必ず指定する必要があります)。これは、Oracle Access Managementコンソール、リモート登録、およびWLSTのカスタム管理コマンドを使用するためにサインインする管理者の認証に使用されます。
リモート登録ユーティリティまたはOracle Access Managementコンソールを使用する管理者には、システム・ストアに保存されている資格証明が必要になります。

リモート・ユーザー・ストアをシステム・ストアとして定義すると、OAMAdminConsoleSchemeを変更して、同じリモート・ユーザー・ストア(システム・ストア)を参照するLDAP認証モジュールを使用する必要があります。

- デフォルト・ストア: 名前が示すとおり、デフォルト・ストアとして指定されたLDAPストアは、モジュールまたはプラグインに別のストアの使用を構成しないかぎり、LDAP認証モジュールでの使用に対して自動的に選択されます。
セキュリティ・トークン・サービス: 指定されたデフォルト・ストアのみを使用します。トークン発行ポリシーにユーザー条件を追加するとき、たとえば、ユーザーを選択するアイデンティティ・ストアはデフォルト・ストアである必要があります。

注意:

Access Managerに保護されたリソースにアクセスするユーザーは、認証スキームで登録および定義された任意のユーザー・アイデンティティ・ストアに対して認証できます。Security Token Serviceは、デフォルトのユーザー・アイデンティティ・ストアのみを使用します。

Oracle Access Managementコンソールでは、ユーザー・アイデンティティ・ストアの登録は、「データソース」ノード(「システム構成」タブの「共通構成」セクション)の下にまとめられています。管理者は、Oracle Access Managementコンソールまたは『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』に記載されているカスタムWLSTコマンドを使用して、ユーザー・アイデンティティ・ストアの登録と、登録の表示、変更および削除が可能です。

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

管理者はOracle Access Managementに複数のユーザー・アイデンティティ・ストアをインストールおよび登録できます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。複数のアイデンティティ・ストアを登録するとき、管理者は次のように定義する必要があります。

- システム・ストア: 管理者のログインはシステム・ストアに対してのみ実行する。

- デフォルト・ストア: パッチ適用時と、Identity Federationおよびセキュリティ・トークン・サービスの使用時に起動する。

- パッチ適用: パッチの適用前に、デフォルト・ストアとしてUserIdentityStore1を指定し、UserIdentityStore1(Weblogic Serverの組込みLDAP)を使用するようにLDAP認証モジュールを更新します。詳細は、Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイドを参照してください。

- Identity Federation: IdPパートナ単位で複数のアイデンティティ・ストアをサポートします。指定したアイデンティティ・ストアは、別のストアと同じように登録する必要があります。アイデンティティ・ストアがIdPパートナで定義されていない場合は、デフォルト・ストアが使用されます。詳細は、「フェデレーション用のアイデンティティ・プロバイダ・パートナの管理」を参照してください。

- セキュリティ・トークン・サービス: ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、セキュリティ・トークン・サービスにはLDAPサーバーが必要です。目的のLDAPサーバーが、「デフォルト・ストアおよびシステム・ストアの設定」に記載されているようにOracle Access Managementのデフォルト・アイデンティティ・ストアとして登録および構成されていることを確認します。詳細は、「構成の概要: ユーザー名トークンを使用したアイデンティティ伝播」を参照してください。

- 各LDAP認証モジュールまたはプラグイン(およびフォームまたは基本認証スキーム)とともに使用する特定のストア

外部LDAPリポジトリは、ユーザー、ロールおよびグループ・メンバーシップ情報を提供できます。たとえば、ユーザーのグループは、ログイン時に計算され、セッションの存続期間内に格納されます。情報は次のように使用されます。

- 認証中にポリシーを評価する場合

- ポリシー内の認可条件に対するアイデンティティを評価する場合

- 認可ポリシーでの条件のアイデンティティを検索するために、LDAPを使用する場合

注意:

ユーザーのグループ・メンバーシップ情報を消去し、後日Oracle Access Managementで再計算する方法はありません。

OAMでのユーザー・アイデンティティ・ストアの登録は、OAMサーバーとの接続性を提供するために必要です。アイデンティティ・ストアを登録した後、管理者はそれを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。

Oracle Access Managementでは、各ユーザー移入とディレクトリのそれぞれをアイデンティティ・ドメインとして対応可能です。各アイデンティティ・ドメインは、単に構成済アイデンティティ・ストア名にマップします。

最初のOracle Access Manager 11gリリースでは、ユーザーは単純なユーザー名/IDフィールドを使用して内部および外部の両方で識別されました。複数のアイデンティティ・レルムをサポートするには、ユーザーまたはグループのレルム間表現、またはアイデンティティ・ストア内に存在するエンティティが必要です。この表現は、正規識別子と呼ばれますが、Oracle Access Managementの様々なランタイムおよび管理コンポーネントに対する一意の識別子として機能します。

- 外部表現: アイデンティティ・ドメイン情報とともに単純なユーザー名を修飾します。
たとえば、Oracle Access Managementコンソールでユーザー名をリストする表には、それぞれのユーザーのアイデンティティ・ドメインを表示する列が含まれます。アイデンティティ・ドメインはアイデンティティ・ストア名にマップします。ユーザー情報を表示するすべての機能コンポーネント(コンソール、ポリシー、レスポンス、ロギング、セッション管理、監査など)は、アイデンティティ・ドメイン情報の場合と同様に修飾を開始します。

- 内部表現: 曖昧性解消をサポートするために、OAMは完全修飾名を格納および使用します(またはコンポジット・キーを形成するために両方のフィールドをそのまま使用します)。
たとえば、セッション管理エンジンはコンポジットを格納する必要をなくすためにこのようにしています。どちらの場合も、完全修飾名は表示されません。

認可ポリシー管理

認可ポリシー管理は、ユーザーまたはグループへの権限付与のオーサリングを許可します。管理者は、特定のユーザーまたはグループを選択し、アクセス権を付与または拒否して、特定のアイデンティティ・ストア内を検索できます。検索結果は、Access Manager認可ポリシーのアイデンティティ条件タイプのプリンシパルとして格納されている値など、ユーザーおよびグループの正規識別子を提供します。コンソールには、オリジナルの名前およびアイデンティティ・ストアが表示されます。

ランタイム

認証および認可は、ポリシー・ランタイム・コンポーネントに基づきます。OAMIdentityは、認証されたユーザーおよびそのユーザーがメンバーとなっているグループ(存在する場合)のランタイム表現です。ポリシー評価中、OAMIdentity内の情報は、認可ポリシーのアイデンティティ制約の一部として格納されているものと照合されます。ドメインは、トークン内の名前修飾子としてアサートされます。

OAMプロキシの場合、既存のOAM_REMOTE_USERヘッダーに加えて、2番目のOAM_IDENTITY_DOMAINヘッダーを認証されているユーザーのすべてのリクエストに設定し、必要に応じて使用するアプリケーションがユーザーの曖昧性を解消できるようにします。

セッション

セッション管理検索は、ユーザー・アイデンティティ・ストアについて管理者に通知し、これは検索結果表にリストされます。

監査およびロギング

ユーザーが認証されているユーザー・アイデンティティ・ストアは、監査およびロギング中に考慮されます。

関連項目:

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

- 「管理者ロールの管理」

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

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

4.2.2 ポリシー、パスワード管理およびセッションのデータベース・ストアについて

Oracle Access Managementには、Access Managerのポリシー・データ、パスワード管理データおよびAccess Managerセッションを本番環境で保存するデータベースが必要です。

注意:

最大でも、デプロイメントに含まれるのは、1つのポリシー・ストア・データベース(パスワード管理の役割を果たす)と、1つのセッション・ストアです。デフォルトでは、単一のJDBCデータ・ストアが両方に使用されます。

デフォルトでは、次のデータはポリシー・ストア・データベースで維持されます。

- 認証モジュール、スキーム、アプリケーション・ドメインおよびポリシーを含むポリシー・データ。

- 構成済のユーザー・アイデンティティ・ストアごとのパスワード・ポリシー・タイプ、およびパスワードの要件、失効、通知を制御するポリシーを含んだパスワード管理データ。

- 分散されたメモリー内のストレージに対する永続的なバックアップとしてのセッション・データ。

注意:

本番環境での監査データ・ストレージの推奨モードは、スタンドアロンの監査データ専用RDBMSデータベースに監査レコードを書き込むことです。これは、個別に構成された監査ストアを使用して行います。ポリシー・ストアは監査データには使用されません。

関連項目:

「ポリシーおよびセッション・データベースの管理」

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

Access Managerには、Access Manager関連のシステム構成データをすべて含むXMLファイル(oam-config.xml)が用意されています。各OAMサーバーには、最新の構成XMLファイルのローカル・コピーが1つあります。

サーバーとエージェントの登録を含むAccess Managerデプロイメント構成に加えられたすべての変更は、oam-config.xmlファイルに格納されて、自動的に各OAMサーバーに伝播されます。

高可用性環境でフェイルオーバーが構成されているかどうかに関係なく、すべてのOAMサーバーには常に最新のoam-config.xmlファイルがあります。

注意:

oam-config.xmlは編集しないことをお薦めします。

oam-config.xmlファイルは編集しないことをお薦めします。このファイルを変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、oam-config.xmlの編集が必要な場合には、次のガイドラインに従ってください。

- $DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、使用する場合にはコピーを別の場所に保存します。

- AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。

- OAMサーバーが実行されている場合は、ファイルの上部にある構成のバージョン番号に1を加えて変更に関連付けます。さらに、すべてのOAMサーバーにわたる自動伝搬と動的なアクティブ化を有効にします。たとえば、この例の最後から1つ手前の行を参照してください(既存値+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">2</Setting>
</Setting>

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

推奨のキーストア・フォーマットはJKS(Javaキーストア)です。Javaキーストアは水面下でAccess Managerに関連付けられ、エージェント・トラフィックおよびセッション・トークンを暗号化するために生成される暗号化セキュリティ・キーの格納に使用されます。次に例を示します。

- すべてのOAMエージェントおよびOSSOエージェントは、他のエージェントが読み取ることができない秘密鍵を持っています。

- Oracle Coherenceベースのセッション・トラフィックを暗号化するキーがあります。

- エージェントとアプリケーションの登録時に、SSO Cookie(Webgateおよびmod_ossoの場合)の暗号化および復号化に使用されるキーが生成されます。

表4-3は、生成された暗号化キーの比較と、それぞれの格納場所を簡単に説明しています。

表4-3 11.1.2 キーと格納

キーと格納

説明

Access Manager暗号化キー

- 11g WebgateとOAMサーバー間で共有されるエージェントごとに秘密鍵1つ
すべての10g Webゲートが使用する1つのグローバル共有秘密鍵

- 1つのOAMサーバー・キー

Access Managerキー・ストレージ

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

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

注意:

キーストアはコンソールからは使用できず、表示や管理、変更はできません。

4.2.5 Security Token Serviceのキーストアについて

Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。

- OAMサーバー・インスタンスに関連付けられたキーおよび証明書のシステム・キーストア

- OAMサーバー・インスタンスと相互作用するエンティティに信頼性を確立するために使用されるキーおよび証明書の信頼キーストア

- パートナ、クライアントおよびエージェントとの信頼性を確立するために使用されるキーおよび証明書のパートナ・キーストア。パートナ・キーおよび証明書は、機密情報が暗号化されて.oamkeystoreに格納されます。

- 証明書失効リスト(CRL)は、CRLベースの証明書失効確認の実行中に、OAMサーバー・インスタンスによって使用されます。

次のファイルは、JMXフレームワークによってドメイン内のすべてのOAMサーバー間で配布されます。

- システム・キーストアとパートナ・キーストア: .oamkeystore

- 信頼キーストア: amtruststore

- CRL: amcrl.jar

関連項目:

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

4.2.5.1 Security Token ServiceのOracle WSMエージェント・キーストアについて

Security Token ServiceでOracle WSMエージェント機能を使用してWSポリシーを公開し、インバウンドおよびアウトバウンドWSメッセージのメッセージを保護できます。

Oracle WSMでは、システムおよびパートナ・キーおよび証明書用に、JKSタイプの別のキーストアが必要です。

デフォルト名はjps-config.xmlで次のように指定されています。

default-keystore.jks

注意:

Oracle WSMエージェント・キーストアとAccess ManagerおよびSecurity Token Serviceのキーストアは常に異なるものにすることをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Manager/Security Token Serviceがアクセスされる可能性があります。

4.2.6 Identity Federationキーストア

$DOMAIN_HOME/config/fmwconfig/.oamkeystoreは、Identity FederationおよびSecurity Token Serviceによって、デジタル署名や暗号化処理に使用されるキー・ペアと証明書を格納するために使用されます。

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

この項では、Oracle Access Managementコンソールを使用してユーザー・アイデンティティ・ストアの登録を管理する上で必要な手順を説明します。

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

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

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

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

関連項目:

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

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

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

このトピックでは、「システム構成」タブの下の様々なユーザー・アイデンティティ・ストアの設定について説明します。

図4-1に、「ユーザー・アイデンティティ・ストアの作成」ページを示します。このページには、自分の環境に合せて編集できるストア設定とデフォルト設定の入力フィールドがあります。「ストア・タイプ」ドロップダウン・リストには、サポートされる選択項目が表示されます。

図4-1 ユーザー・アイデンティティ・ストア登録の作成

「図4-1 ユーザー・アイデンティティ・ストア登録の作成」の説明

ページ上のアスタリスク(*)は必須の設定です。表4-4に、タイプ別の各要素を示します。

表4-4 ユーザー・アイデンティティ・ストアの要素

要素

説明

ストア名

この登録の一意の名称。名称は最大30文字までを使用できます。

ストア・タイプ

サポートされているすべてのLDAPプロバイダのリスト。ここから選択できます。「複数のアイデンティティ・ストア」の説明のとおり、複数のアイデンティティ・ストアを使用できます。

関連項目: 表16-28「LDAPプロバイダ用のオラクル社提供LDIFのロケーション」

説明

オプション。

SSLの有効化

このボックスをクリックして選択すると、ディレクトリ・サーバーとOAMサーバーの間でSSLが有効であることを示します。

場所と資格証明

説明

ロケーション

パート番号を含むLDAPホストのURL。Oracle Access Management 11gは、フェイルオーバー機能で複数のLDAP URLをサポートします。IDアサーション・プロバイダは、LDAP URLが表示される順序に基づいて次のLDAP URLにフェイルオーバーします。

1つの(または複数の)LDAP URLをホスト:ポートの形式で入力します。複数のURLは、空白または改行で区切る必要があります。このURL値には、ldap://またはldaps://(SSL_NO_AUTHをサポート)を指定する必要はありません。

localhost:myhost:7001

注意: サポートされるURLの文字数は、ブラウザのバージョンに基づきます。Oracle Access Managementおよびブラウザが処理できる長さを超えた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: 参照の例外によって発生します。コンポーネントのユーザーによって検出可能です。

図4-2に、デフォルトとシステム・ストアの指定内容を示します。「アクセス・システム管理者」セクションを参照してください。定義済のシステム・ストアおよびストア自体内のみで、管理者ロールを追加または削除できます。

図4-2 システム・ストア登録

「図4-2 システム・ストア登録」の説明

関連項目:

ユーザーの分類の詳細については、第17章「リソースの保護およびSSOの有効化ポリシーの管理」

4.3.2 新しいユーザー・アイデンティティ・ストアの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールにより新しいユーザー・アイデンティティ・ストアを登録できます。

アイデンティティ・ストアを登録した後、それを認証スキームのベースを形成する1つまたは複数の認証モジュールで参照できます。また、認可ポリシーのアイデンティティ条件内にある特定のアイデンティティ・ストアを参照することもできます。

関連項目:

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

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

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

前提条件

- Oracle Access Managementに登録しようとしているユーザー・アイデンティティ・ストアをインストールします。

- Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの説明に従って、Access ManagerのLDAPディレクトリ・スキーマを拡張します。

- ベンダーのドキュメントの説明に従って、LDAPディレクトリにユーザーとグループを作成します。

新しいユーザー・アイデンティティ・ストアの定義を登録する手順

1. Oracle Access Managementコンソールの「システム構成」タブで「共通構成」セクションから「データソース」ノードを開きます。

2. 「ユーザー・アイデンティティ・ストア」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。

3. デプロイメントに適した値(表4-4)をフォームに入力し、「適用」をクリックして登録を送信します。

4. 接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。

5. 登録ページを閉じます。

6. 管理者の追加: 「管理者ロールの管理」を参照してください。

1. ナビゲーション・ツリーで、登録ページを開くストア名をダブルクリックします。

2. 「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。

3. 「システム管理者ロールの追加」ダイアログ・ボックス(...)に入力します。

4. 「適用」をクリックします。

7. デフォルト・ストアの設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

8. 「適用」をクリックして登録を送信してから、ページを閉じます。

9. 次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。

- 「ネイティブのLDAP認証モジュール」

- 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

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

有効なOracle Access Management管理者の資格証明を持つユーザーは、ユーザー・アイデンティティ・ストアの登録を表示または変更できます。

前提条件

登録しようとしているユーザー・アイデンティティ・ストアが、インストールされて実行中である必要があります。

ユーザー・アイデンティティ・ストアの閲覧または変更の手順

1. Oracle Access Managementコンソールの「システム構成」タブ、「共通構成」セクション、「データソース」ノード、「ユーザー・アイデンティティ・ストア」ノードの順に開きます。

2. 目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開きます。

3. 必要に応じて値を変更します(表4-4を参照)。

4. 「適用」をクリックして、登録を更新します(または変更を適用しないでページを閉じます)。

5. 接続テスト: 「接続テスト」ボタンをクリックして接続性を確認し、「確認」ウィンドウを閉じます。

6. システム・ストアまたはデフォルト・ストアとして設定: 「デフォルト・ストアおよびシステム・ストアの設定」を参照してください。

7. 管理者ロールの管理: 「管理者ロールの管理」を参照してください。

8. 次を参照して、1つ以上の認証モジュールまたはプラグインを、このストアを使用するように構成します。

- 「ネイティブのLDAP認証モジュール」

- 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

9. 完了したらページを閉じます。

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

有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、Oracle Access Managementコンソールによりユーザー・アイデンティティ・ストアの登録を削除できます。

注意:

デフォルト・ストアまたはシステム・ストアの登録は削除できません。

セカンダリ・ユーザー・アイデンティティ・ストア登録の削除の手順

1. 削除するストアを参照しているLDAP認証モジュールを編集します(有効なアイデンティティ・ストアがモジュール内で参照されているか確認するため)。

2. Oracle Access Managementコンソールの「システム構成」タブ、「共通構成」セクション、「データソース」ノード、「ユーザー・アイデンティティ・ストア」ノードの順に開きます。

3. 目的の「ユーザー・アイデンティティ・ストア」登録ページをクリックして開き、削除するストアであることを確認し（さらにデフォルトでないことを確認してから）、ページを閉じます。

4. 希望するインスタンス名をクリックしてから、ツール・バーで「削除」ボタンをクリックします。

5. 「確認」ウィンドウで「削除」ボタンをクリックします(または「取消」をクリックしてウィンドウを閉じ、インスタンスを保持します)。

6. 定義がナビゲーション・ツリーにないことを確認します。

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

この項の内容は次のとおりです。

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

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

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

有効なOracle Access Management管理者の資格証明を持つユーザーは、この手順を利用して、ユーザー・アイデンティティ・ストアの登録をデフォルト・ストアまたはシステム・ストアのいずれかとして指定できます。

関連項目:

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

注意:

管理者ログインは、OAMAdminConsoleSchemeによって使用されるLDAP認証モジュールもそのシステム・ストアを使用する場合のみ機能します。システム・ストアを変更すると、アイデンティティ管理ドメイン全体に影響を与えます。別のストアをリモート・ストアとして設定する場合、ロックアウトを避けるためにOAMAdminConsoleSchemeも変更してください。

図4-3は、新しいユーザー・アイデンティティ・ストア登録を追加した直後に表示されるデフォルト・ストアおよびシステム・ストアのオプションを示します。

図4-3 「登録」ページ内の「デフォルトとシステム・ストアのオプション」

「図4-3 「登録」ページ内の「デフォルトとシステム・ストアのオプション」」の説明

図4-4に、デフォルト・ストアを表示したときの登録ページを示します。

図4-4 「登録」ページで指定されたストア

「図4-4 「登録」ページで指定されたストア」の説明

システム・ストアの指定を適用するとすぐに、アクセス・システム管理者ロールを追加するように要求されます(「管理者ロールの管理」を参照してください)。また、OAMAdminConsoleSchemeによって使用されるLDAPモジュールがシステム・ストアを参照するようにする必要もあります。

図4-5に示されているように、「共通設定」ページから「デフォルトおよびシステム・アイデンティティ・ストア」にアクセスすることもできます。

図4-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア

「図4-5 「共通設定」ページ: デフォルトおよびシステム・アイデンティティ・ストア」の説明

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

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用してデフォルト・ストアおよびシステム・ストアの指定を定義または変更できます。

関連項目:

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

デフォルト・ストアおよびシステム・ストアを定義する手順

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「共通構成」セクション
「データソース」ノード
「ユーザー・アイデンティティ・ストア」ノード

2. システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。

1. システム・ストアとして指定するストア名をクリックし、登録ページを開きます。

2. 「システム・ストアとして設定」の横にあるボックスを選択します(ドメイン全体の認証および認可操作用)。

3. 「適用」をクリックして指定を送信します。

4. 管理者の追加: 「管理者ロールの管理」を参照してください。

5. 認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。

6. このストアを使用するように、次を参照して、1つ以上の認証プラグインを構成します。
「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

3. デフォルト・ストアの設定: このストアは、パッチ適用時のセキュリティ・トークン・サービスおよび移行に必要です。

1. デフォルト・ストアとして指定するストア名をクリックし、登録ページを開きます。

2. 「デフォルト・ストアとして設定」の横にあるボックスを選択し、このLDAPストアを設定します(移行用)。

3. 認証モジュール: OAMAdminConsoleSchemeを見つけて、LDAPモジュールがこのストアを参照していないことを確認します。「ネイティブ認証モジュールの管理」を参照してください。

4. 認可ポリシー条件: 認可ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。認証ポリシー条件の定義を参照してください。

5. トークン発行ポリシー条件: トークン発行ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。「トークン発行ポリシー、条件およびルールの管理」を参照してください。

4. 登録ページを閉じます。

4.5 管理者ロールの管理

ここでは、次の内容について説明します。

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

- 管理者ロールの管理

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

管理者ログインは、認証スキーム(および割り当てられた認証モジュール)がIAMSuiteAgentによって使用されており、そのシステム・ストアも使用する場合にのみ機能します。

デフォルトでは、Oracle Access Managementの管理者ロールは、WebLogic管理者ロール(Administrators)と同じです。他のユーザー・アイデンティティ・ストア(たとえばOracle Internet Directory)を登録することもできますが、ただし、認証先の登録済ストアの少なくとも1人のユーザーを使用してユーザーweblogicを定義する必要があります。

企業によっては、Access Managerを担当するユーザーとSecurity Token Serviceを担当するユーザーに別の管理者グループが必要になることがあります。すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。アイデンティティ・ストア登録の編集時にストアをシステム・ストアとして指定すると、図4-6に示すように「アクセス・システム管理者」セクションがページ上に開きます。

注意:

すべての管理者ロール、ユーザーおよびグループをシステム・ストアに格納する必要があります。システム・ストアを変更する場合は、適切な管理者ロールを新しいシステム・ストアに追加することが必要です。

図4-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録

「図4-6 「アクセス・システム管理者」セクションが表示されたシステム・ストア登録」の説明

ユーザー・アイデンティティ・ストア登録を追加または編集するときに、新しい管理者ロールを追加できます。図4-7は、使用するページとコントロールを示しています。

図4-7 システム管理者ロールの追加

「図4-7 システム管理者ロールの追加」の説明

4.5.2 管理者ロールの管理

次の手順では、システム・ストアとして指定したユーザー・アイデンティティ・ストアに格納する必要があるOracle Access Management管理者ロールの定義または削除方法を説明します。

前提条件

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

システム・ストアの管理者ロールを追加または削除する手順

1. 指定したシステムLDAPストアで、次を実行します。

1. 管理者に使用する目的のLDAPグループを定義します。

2. 管理者グループが、グループ検索ベースで使用可能なことを確認します。

2. システム・ストア登録の表示: 次の手順を実行します(またはシステム・ストアとして指定する、「データソース」ノード内の異なるシステム・ストアを検索します)。

1. Oracle Access Managementコンソールの「ようこそ」ページから、「構成」パネルの「共通設定」をクリックします。

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 Managementコンソールからサインアウトしてブラウザ・ウィンドウを閉じます。

2. Oracle Access Managementコンソールを起動して、以前の管理者ロールを使用してログインを試み、これが失敗することを確認します。

3. 新しい管理者ロールを使用してログインし、この試みが成功することを確認します。
ログイン失敗: 「管理者のロックアウト」を参照してください。

4.6 ポリシーおよびセッション・データベースの管理

この項の内容は次のとおりです。

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

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

4.6.1 データベースのデプロイメントについて

Oracleには、本番環境のポリシー・ストアとして1つのデータベースが必要です。この単一のデータベースは、セッション・データを保存するためにも使用できます。データベースをセッション・ストアとして使用すると、スケーラビリティおよびフォールトトレランス性が増します(すべてのサーバーをダウンさせる電源イベントに対して)。

注意:

データベースは最大2つまで、1つのポリシー・データベースと1つのセッション・データベースを使用できます。Access Managerは、実際のバックエンド・リポジトリには非依存であり、このポリシー・ストアの構成を直接的に管理することはありません。

ポリシー・データベースは、ベンダーの指示に従ってインストールする必要があります。ポリシー・データベースはOracle WebLogic Serverドメインで使用するように構成します。この構成には、Oracle Fusion Middleware構成ウィザードと、ポリシー・ストアのデータベース構成テンプレートを使用します。

WebLogic構成ウィザードを使用した初回のデプロイメント中に、次のデータベース詳細が要求されます。

- データベース・ログインIDとパスワード

- データベース・サービス名と場所

管理者は、RCUを使用するAccess Manager固有のスキーマでデータベースを拡張する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。基本的なスキーマの作成は、RCUが起動されたときに発生します。RCUは、データベースがAccess Managerポリシー、パスワード管理およびセッション・データを受け入れるように準備します。

WebLogic構成ウィザードを使用すると、データベースへの接続を登録およびテストできます。

実際のAccess Managerポリシー要素は、Oracle Access Managementコンソールがデプロイされて初めてWebLogic AdminServerが起動されたときに作成されます。

関連項目:

Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド

4.6.2 Access Managerセッションの個別データベースの構成

Access ManagerにはoamDSというデータソースが含まれており、これはAccess Managerスキーマで拡張されたデータベース・インスタンスに対して構成されます。あらかじめ定義された次のJava Naming and Directory Interface(JNDI)名が、データ・ソースを参照するためにOAMサーバーにより使用されます。

jdbc/oamds (used by both the policy layer and session layer to access database)

以下の手順を使用して、WebLogic管理コンソールを用いて個別のセッション・データのデータベース・インスタンスを作成できます。Oracle Access Managementコンソールでは、この処理はサポートされていません。

注意:

このまれなケースについては、手順2fの説明に従ってoam-config.xmlを慎重に編集することをお薦めします。

セッション・データ用に独立したデータベースを作成、使用する手順

1. セッション・データのデータベースをインストールおよび構成して、RCUをAccess Manager固有のスキーマとともに使用し、セッション・データ・ストアとしてデータベースを設定します。

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サーバーを再起動します。

5 サーバー登録の管理

この章では、Oracle Access Managementと連携する管理対象サーバー・インスタンスの登録方法を説明します。本書では、この管理対象サーバーをOAMサーバーと呼びます。このタスクはOracle Access Managementコンソールを使用して行います。

内容は次のとおりです。

- 前提条件

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

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

5.1 前提条件

次の環境的な考慮事項が満たされていることを確認してください。

- Oracle WebLogic Server管理コンソールまたはWLSTコマンドを使用して、新しい管理対象サーバーがドメインに追加されている。

- 必要に応じて、Oracle JRFテンプレートが管理対象サーバー(またはクラスタ)に適用されている。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。

「OAMサーバー、登録および管理の概要」を確認することをお薦めします。

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

Oracle Access Managementコンソールは、WebLogic管理サーバーと同じコンピュータにインストールして実行する必要があるJava EEアプリケーションです。WebLogic管理サーバーで実行する他の重要なアプリケーションには、WebLogic Server管理コンソールとFusion Middleware Control用のEnterprise Managerがあります。

注意:

Oracle Access Managementコンソールは、OAM管理サーバーと呼ぶこともあります。ただし、これはWebLogic管理対象サーバー上にデプロイされたOAMサーバーと同類ではありません。

Oracle WebLogic管理対象サーバーにデプロイされたOracle Access Management実行時インスタンスは、OAMサーバーと呼びます。OAMサーバーは、Access Managerに登録されている必要があります。これにより、認証時、認可時およびリソースへのアクセス時にエージェントとの通信が可能になります。

管理者はWebLogic Serverドメインを拡張して、別のOAMサーバー・インスタンスを必要に応じて次の方法で追加できます。

- WebLogic Server管理コンソール。Oracle Access Managementコンソールを使用して、OAMサーバー・インスタンスを手動で登録した後で使用します。

- WebLogic構成ウィザード

- カスタマイズされたOracle WebLogicスクリプト・ツール(WLST)コマンド(Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスを参照)

最後の2つの方法では、Oracle Access Managementコンソールに表示されるOAMサーバー・インスタンスが自動的に登録され、他に必要な手順はありません。

関連項目:

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』。

この項では、Oracle Access Managementコンソールを使用した、OAMサーバー・インスタンスの登録と管理の概要について説明します。

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

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

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

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

関連項目:

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

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

管理者は、1つ以上の管理対象サーバーをOracle Access ManagementのWebLogic Serverドメインに追加できます。

WebLogic構成ウィザードを使用するときに、OAMサーバーは自動的に登録されます。ただし、構成ウィザードを使用しない場合は、通信チャネルを開くためにOAMサーバーを手動で登録する必要があります。

または、 OAM用のカスタムWLSTコマンドを使用して、サーバー登録を表示、編集または削除できます。すべての変更は自動的にOracle Access Managementコンソールおよびクラスタ内のすべてのOAMサーバーに伝播されます。

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

OAMサーバーのみがOracle Access Managementに登録されます。Oracle Access Managementコンソール(WebLogic管理サーバー上)は、自身には登録されません。

OAMサーバーの登録に使用された方法に関係なく、各インスタンスの詳細はOracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションにあります。

- サーバー名、ホスト、ポート

- プロキシ: レガシー・アクセス・サーバーとして実行され、通信のセキュリティ・モードを定義します。詳細は、次を参照してください。

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

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

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

- Oracle Coherence: セッション・データを含む様々なOAMサービスに分散されたキャッシュを提供します。

管理者は特定のインスタンス登録を検索し、新しくインストールされたOAMサーバーを登録して、Oracle Access Managementコンソールを使用してサーバー登録を表示、変更または削除できます。詳細については、「OAMサーバー登録のページについて」を参照してください。

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

Oracle Access Managementのサーバー側コンポーネントには、Oracle Access Manager 10gポリシー施行エージェント(10g Webgateおよびアクセス・クライアント)およびOracleAS SSO 10g mod_osso(11gではOSSOエージェントと呼びます)に加え、OpenSSOエージェントとの下位互換性を維持するための、プロキシ・サーバーが含まれています。

レガシー10g SSO: OAMプロキシは複数のアクセス・クライアントから同時にリクエストを受け入れることが可能で、すべてのWebゲートおよびアクセス・ゲート(11gではアクセス・クライアントと呼びます)がAccess Managerと情報交換できるようにします。詳細については、「「OAMプロキシ」ページ」を参照してください。

レガシーOracleAS 10g (OSSO): 統合されたOSSOプロキシは、Access Manager使用時のOSSOエージェントを使用した認証中に、トークン生成およびトークン・リクエストに応じた検証を処理します。OSSOプロキシに構成は必要ありません。第12章および第13章の説明に従って、OSSOエージェントを登録するのみです。

関連項目:

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

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

古いデプロイメントにOracle Access Manager 10gが統合され、OracleAS (OSSO) 10gとともに使用されている場合、OracleAS SSOをアップグレードして、Access Manager SSOを使用できます。

Access Manager 11gを使用するためにOSSOをアップグレードすると、10g Webgatesを同じデプロイメント内のAccess Manager 11g SSOとともに動作させることができます。この場合は、OAMプロキシが必要に応じてOAM 10gアクセス・サーバーまたはAccess Manager 11gのどちらかにリクエストを転送します。

Oracle Access Manager 10g ObSSOCookieは、暗号化されたセッション・ベースのシングル・サインオンcookieで、ユーザーの認証が成功すると生成されます。10g ObSSOCookieはユーザー・アイデンティティ・ストア情報を格納し、必要があればユーザーはそれをキャッシュ化できます。

統合されたOAMプロキシは、10g ObSSOCookieのAES暗号化アルゴリズムをサポートして、リリース10g Webgateとの下位互換性を可能にします。10g Accessサーバーは、OAMプロキシによって作成されたCookieを復号化できます(その逆も可)。これにより、Access Manager 11gで認証を実行し、Oracle Access Manager 10gで認可を実施できます(さらにこの逆も可能です)。

注意:

OAMプロキシによって作成されたAccess Manager 11g ObSSOCookieは、アクセス・サーバーによって作成された10g ObSSOCookieと互換性があります。

詳細については、「「OAMプロキシ」ページ」を参照してください。

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

OAPチャネルの通信モードには以下のものがあります。

- オープン: 通信のセキュリティがデプロイメントで問題にならない場合、この暗号化されていないモードを使用してください。

- 簡易: 認証局(CA)を自分で管理せずに証明書パスワードをプレーン・テキストとして送信するなど、セキュリティ上の考慮事項がある場合に、このオラクル社が署名する証明書モードを使用します。

- 証明書: OAMサーバーとWebgateで異なる証明書を使用し、信頼できるサード・パーティの認証局にアクセスがある場合に、これを使用します。

個々のOAMサーバー登録で、セキュリティ・モードは「プロキシ」タブで定義されます。この詳細は「OAMサーバー登録のページについて」にあります。

「簡易」と「証明書」のモードには以下が必要です。

- すべてのOAMサーバーとWebgateに共通のセキュリティ・パスワード(「OAMプロキシの「簡易」および「証明書」モード・セキュリティのアクセス・プロトコルの管理」を参照してください)。

- 適切に署名されたX.509デジタル証明書。詳細は付録C「通信の保護」を参照してください。

少なくとも1つのOAMサーバー・インスタンスが、エージェント登録時にエージェントと同じモードで実行中である必要があります。そうでなければ、エージェント登録が失敗します。ただし、エージェント登録の後に、OAMサーバーの通信モードは変更できます。エージェントとサーバー間の通信は、WebgateモードがOAMサーバーのモードと同じか、またはそれ以上であれば続けて機能します。エージェント・モードは高くでも問題ありませんが、低くすることはできません。たとえば、OAMサーバーのモードがオープンの場合、エージェントは3つのモードのどれでも通信することができます。OAMサーバー・モードが簡易の場合、エージェントは簡易または証明書を使用できます。OAMサーバー・モードが簡易の場合、エージェントは証明書モードを使用する必要があります。

関連項目:

付録C「通信の保護」

5.2.5 構成変更後のサーバーの再起動について

Oracle Access Managementのほとんどの機能サービスは、OAMサーバーを再起動することなく、Oracle Access Managementコンソールから行った変更を反映します。表5-1に、サーバーの再起動が必要になる条件を示します。

表5-1 サーバーの再起動が必要になる条件

イベント

説明

セッション永続性の変更

セッションの永続性をデータベースからメモリー内(またはその逆)に変更すると、OAMサーバーの再起動が必要になります。

Oracle Coherenceのポート番号

ポート番号を変更すると、OAMサーバーの再起動が必要になります。

ロード・バランサ・サーバーの定義

変更すると、OAMサーバーの再起動が必要になります。

管理対象サーバーのポート番号

変更すると、OAMサーバーの再起動が必要になります。

新しい管理対象サーバー

新しい管理対象サーバーをクラスタに追加したときには、AdminServerを再起動してポリシーの取得を可能にする必要があります。

Oracle Coherenceのセキュリティ構成を新しく組み込んだサーバーを含めて再初期化するために、OAMサーバーを再起動する必要があります。

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

この項では、Oracle Access Managementコンソールを使用して、OAMサーバー・インスタンスを登録および管理する方法を説明します。内容は次のとおりです。

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

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

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

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

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

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して、新しくインストールされた管理対象サーバー(OAMサーバー・インスタンス)を登録したり、既存のOAMサーバー登録を変更できます。

または、カスタムWLSTコマンドを使用して、OAMサーバー・インスタンスを登録および管理できます。変更はOracle Access Managementコンソールに反映されて、クラスタ内のすべてのOAMサーバーに自動的に伝播されます。

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

図5-1は、Oracle Access Managementコンソールから見た一般的なOAMサーバーの登録ページを示します。

図5-1 「プロキシ」タブが表示されたOAMサーバー登録ページ

「図5-1 「プロキシ」タブが表示されたOAMサーバー登録ページ」の説明

個々のサーバー登録設定の説明は、表5-2にあります。

表5-2 OAMサーバー・インスタンスの設定

要素

定義

サーバー名

このサーバー・インスタンス名を識別する名称。WebLogic Serverドメインの初回デプロイメント時に定義されています。

ホスト

サーバー・インスタンスをホストするコンピュータのフルDNS名(またはIPアドレス)。例: host2.domain.com。

ポート

このサーバーが通信(リスニングと応答)するポート。

デフォルト: 5575

注意: 管理対象サーバーのSSLおよびオープン・ポートの両方が有効な場合、管理対象サーバーはデフォルトでSSLポートに設定されます。SSL以外のポートを使用する必要がある場合、認証スキームの資格証明コレクタのURLは、プロトコルとしてhttpおよびSSL以外のポートを指す絶対URLに設定する必要があります。

関連項目: 付録C「通信の保護」

プロキシ

「「OAMプロキシ」ページ」を参照してください。

コヒーレンス

「個々のサーバーの「コヒーレンス」ページ」を参照してください。

関連項目:

「個々のOAMサーバー登録の管理」

5.3.1.1 OAMプロキシページ

統合されたプロキシ・サーバー(OAMプロキシ)が、OAMサーバーの各管理対象サーバーとともにインストールされます。OAMプロキシはレガシー・アクセス・サーバーとして使用され、Access Manager 11gに登録された10gエージェントの下位互換性を提供します。エージェントは新しくインストールするか、Oracle Access Manager 10g SSOデプロイメント内で現在動作中でもかまいません。

それぞれのOAMプロキシ・インスタンスには、異なるポートが必要です。プロキシは、アプリケーションが起動するとリスニングを開始します。登録されたアクセス・クライアントは、プロキシとすぐに通信することができます。

OAMプロキシは、構成と実行時のイベントを両方処理します。それぞれのOAMプロキシは、複数のアクセス・クライアントからのリクエストを同時に受け入れることができます。各OAMプロキシによって、アクセス・クライアントは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(プロキシ不要)

注意:

アクセス・クライアントについては、Access Manager 11gは認証と認可の機能のみを提供します。アクセス・クライアントによるポリシーの変更はサポートされていません。

OAMプロキシ設定は、表5-3の詳細から構成されます。

表5-3 個別のOAMサーバーのOAMプロキシ設定

OAMプロキシ設定

タイプ

値

ポート

int(整数)

このOAMプロキシ・インスタンスがリスニングする一意のポート。

プロキシ・サーバーID

OAMプロキシ(およびこのOAMサーバー・インスタンス)が存在するコンピュータの識別子。DNSホスト名が推奨ですが、有効かつ適切な任意の文字列を使用できます。

モード

OAMプロキシのOAMチャネル・トランスポート・セキュリティは、以下のいずれかを使用できます(エージェント・モードは登録時に一致する必要があり、登録後に上げることができます)。

- オープン: 暗号化なし。

- 簡易: OAMエージェントとOAMサーバー間で渡されるデータは、OAMの自己署名証明書を使用して暗号化されます。
「簡易」モードを指定する前に、グローバル・パスフレーズを指定する必要があります。

- 証明書: OAMエージェントとOAMサーバー間のデータは、認証局(CA)が署名したX.509証明書を使用して暗号化されます。
注意: 「証明書」モードを指定する前に、信頼できるサード・パーティの認証局から署名済証明書を取得する必要があります。

注意: 「簡易」および「証明書」のトランスポート・セキュリティ・モードは、「OAMサーバー共通プロパティ」の「OAMプロキシ」タブで定義された情報により制御されます(「OAMプロキシの「簡易」および「証明書」モード・セキュリティのアクセス・プロトコルの管理」を参照してください)。

関連項目: 付録C(「簡易」および「証明書」トランスポート・セキュリティ・モードを構成する場合)

OAMプロキシ・ロギング: Oracle Access Managementサービスは、他のOracle Fusion Middleware 11gコンポーネントと同じロギング・インフラストラクチャを使用します(第8章を参照してください)。しかし、OAMプロキシはロギングにApache log4jを使用します。

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

Coherenceは、信頼性があり、スケーラビリティの高いピアツーピア・クラスタリング・プロトコルの上に、レプリケートおよび分散(パーティション)されたデータ管理およびキャッシング・サービスを提供します。Coherenceには単一障害点がなく、サーバーが動作不能になった場合やネットワークから切断された場合に、クラスタ化データ管理サービスを自動的および透過的にフェイルオーバーおよび再分散します。

新しいサーバーが追加されたり、障害の起きたサーバーが再起動されると、サーバーは自動的にクラスタに加わってCoherenceはサービスをそのサーバーにフェイルバックして、クラスタ・ロードを透過的に再分散します。Coherenceには、サーバーが自己修復できるようにするネットワーク・レベルの耐故障性機能と透過的なソフト再起動の機能があります。

Coherenceモジュールは、図5-1に示すように値と個々のサーバー・インスタンスのタイプから構成されます。

図5-2 「コヒーレンス」ページと個々のOAMサーバーの値

「図5-2 「コヒーレンス」ページと個々のOAMサーバーの値」の説明

警告:

Oracleサポートから指示がない限り、個々のサーバーのOracle Coherenceの設定を変更しないようお薦めします。

表5-4 個別のOAMサーバーのデフォルトのCoherence設定

Coherenceモジュール

エントリのタイプ

説明とデフォルト値

LogLevel

文字列

OAMサーバー・イベントのCoherenceログ・レベル(0から9)。

LogPort

int(整数)

WebLogic Serverでロギングを行うCoherenceのリスニング・ポート。

LogLimit

文字列

Coherenceのログ制限

Coherenceのロギング: WebLogic Serverログにのみ表示されます。Oracle CoherenceロギングからOracle Access Managementのロギングへの橋渡しはありません。Oracle Fusion Middleware 11gロギング・インフラストラクチャの詳細については、第6章を参照してください。

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

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementコンソールを使用して新しい管理対象サーバー(OAMサーバー)のインスタンスを登録できます。

注意:

エージェントと通信するには、それぞれのOAMサーバーが登録されている必要があります。

前提条件

新しい管理対象サーバーのインスタンスが、Oracle WebLogic Serverドメインで構成され、まだ起動されていない状態である必要があります。

関連項目:

- Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド

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

OAMサーバー・インスタンスの登録の手順

1. 新しい管理対象サーバー・インスタンスをOracle WebLogic Serverドメインにインストールして構成し、このインスタンスを起動しないでください。

2. 通常どおり、Oracle Access Managementコンソールにログインします。

3. 「サーバー構成」タブの「共通構成」セクションから「サーバー・インスタンス」をクリックし、ツール・バーの上にある「作成」ボタンをクリックして新しいページを開きます。

4. 「作成: OAMサーバー」ページで、表5-2のとおりにインスタンスの詳細を入力します。

- サーバー名

- ホスト

- ポート

5. プロキシ: このOAMプロキシ・インスタンスの詳細を入力または選択します。詳細は表5-3にあります。

- ポート

- プロキシ・サーバーID

- モード(オープン、簡易、証明書)

関連項目:

付録E(「簡易」または「証明書」モードを使用する場合)

6. Coherence: Oracleサポートから指示がない限り、個々のサーバー・インスタンスのOracle Coherenceの設定を変更しないようお薦めします。

関連項目:

「Coherenceの使用」

7. 構成を送信するには「適用」をクリックます。構成はナビゲーション・ツリーに表示されます。または、変更を適用せずにページを閉じてください。

8. 新しく登録したサーバーを起動します。

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

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementコンソールを使用して個々のサーバー・インスタンスの設定を表示または変更できます。たとえば、リスニング・ポートやプロキシ通信のトランスポート・セキュリティ・モードの変更が必要になる場合があります。

変更はすぐにOracle Access Managementコンソールに表示され、クラスタ内のすべてのOAMサーバーに伝播されます。

関連項目:

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

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

- 『Oracle Fusion Middleware管理者ガイド』のアイデンティティ管理の新しい本番環境への移動に関する項

サーバー・インスタンスの登録を表示または変更する手順

1. 「システム構成」タブの「共通構成」セクションから、ナビゲーション・ツリーで「サーバー・インスタンス」ノードをクリックして展開します。

2. 希望するインスタンス名をダブルクリックして構成を表示し、次のように処理を続けます。

- 表示のみ: 詳細の閲覧が終わったら、ページを閉じます。

- 変更: 残りの手順を実行して、構成を編集します。

3. 「OAMサーバー」ページで、表5-2に従ってインスタンスの詳細を変更します。

4. プロキシ: 表5-3に従ってこのOAMプロキシ・インスタンスの詳細を変更します。

関連項目:

付録E(「簡易」または「証明書」モードを使用する場合)

5. Coherence: Oracleサポートから指示がない限り、個々のサーバー・インスタンスのOracle Coherenceの設定を変更しないようお薦めします。

関連項目:

「Coherenceの使用」

6. 「適用」をクリックして、変更を送信します(または変更を適用しないでページを閉じます)。

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

有効な管理者の資格証明を持つユーザーは、次のタスクを実行してサーバー登録を削除できます。削除すると、OAMサーバーが無効になります。

前提条件

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

サーバー登録を削除する手順

1. 「システム構成」タブの「共通構成」セクションから、ナビゲーション・ツリーで「サーバー・インスタンス」ノードをクリックして展開します。

2. 希望するインスタンス名をダブルクリックして詳細を確認してから、ページを閉じます。

3. 希望するインスタンス名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

4. インスタンスがナビゲーション・ツリーから削除されたことを確認します。

5. WebLogic Server管理consoleからインスタンスを削除して、サーバー・インスタンスの削除を完了します。
あとは管理対象サーバー・ホスト上のノード・マネージャが自動的に処理します。

第III部

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

第III部では、Oracle Access Managementサービスのロギング、監査、パフォーマンス・モニタリングを実行するために役立つ情報を提供します。

第III部は、次の章で構成されています。

- 第6章「コンポーネント・イベント・メッセージのロギング」

- 第7章「Webgateイベント・メッセージのロギング」

- 第8章「管理イベントとランタイム・イベントの監査」

- 第9章「Oracle Access Managementコンソールを使用したパフォーマンスのモニタリング」

- 第10章「Fusion Middleware Controlによるパフォーマンスおよびログの監視」

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

ロギングは、コンポーネントの重要なイベント、プロセスおよび状態情報を捕捉するために、コンポーネントとサービスがログ・ファイルにメッセージを書き込むメカニズムです。

管理者は、各種の粒度で情報を提供するようにロギングを構成できます。この構成には、その他のOracle Fusion Middleware 11gコンポーネントと同じロギング・インフラストラクチャjava.util.logging(Java環境で使用できる標準)とガイドラインを使用します。ロギング・システムはフラット・ファイルにのみ出力を書き出します。Oracle Databaseインスタンスへのロギングはサポートされていません。

ロギングの構成とログ・ファイルの検索がこの章の焦点です。ログ・ファイルの情報を使用した問題診断については、このマニュアルでは取り上げません。

注意:

特に明記しないかぎり、この章の情報は、Access Manager、Identity Federation、セキュリティ・トークン・サービスのどれを使用している場合でも同じです。また、カスタムのOracle WebLogic Scripting Tool (WLST)コマンドを使用して、ロギング・レベルを変更することもできます。

この章の内容は次のとおりです。

- 前提条件

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

- Access Managerのロギング構成

- セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成

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

6.1 前提条件

この章のタスクを実行する前に、Oracle Access Managementコンソールと管理対象OAMサーバーが実行中であることを確認してください。

第5章「サーバー登録の管理」を確認することをお薦めします。

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

ロギング・インフラストラクチャは、問題診断に使用できるメッセージを記録します。セキュリティ・トークン・サービスはJ2EE Webアプリケーションで、Access Manager J2EEアプリケーションの一部です。どちらもOJDLをロギング目的に使用します。セキュリティ・トークン・サービスは、パートナとの対話操作をタイムスタンプとともに取得します。管理者はメッセージに記録される情報の量を、ログ出力が定義される各コンポーネントのログ・レベルを指定することにより制御します。

注意:

一般に、ユーザーは、問題診断のためにOracleテクニカル・サポートへ送るファイルを作成するためにロギングを有効にします。ログ・メッセージに関するドキュメントはありません。場合によっては、ログ・ファイルを参照することによってユーザー自身で問題を診断できることもあります。

Oracle Access Managementでは、表6-1に示したファイルを使用します。

表6-1 ロギング・ファイル

ファイル・タイプ

説明

ロギング構成ファイル

ロギング・レベルとロギングに関するその他の構成情報を提供します。このファイルは次のパスに格納されています。

DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

注意: デフォルトでは、セキュリティ・トークン・サービスとIdentity Federationのメッセージは、OAMサーバーのログ・ファイルに記録されます。ただし、便宜上、「セキュリティ・トークン・サービスおよびIdentity Federationのロギング構成」で説明しているとおり、logging.xmlを編集してセキュリティ・トークン・サービスまたはIdentity Federationの情報を別のログ・ファイルに記録するようにできます。

ログ・ファイル

記録された情報は次の場所に格納されます。

DOMAIN_HOME/servers/SERVER-NAME/logs/ SERVER-NAME-diagnostics.log

Oracle Access Managementは、表6-2に示すWebLogicコンテナのロギング・デフォルトを使用します。

表6-2 ロギングのデフォルト

説明

イベント

以下のイベントは自動的に記録されます。

- OAMサーバー・イベント(管理されたランタイム・サーバー)

- 管理イベント(コンソールを使用した構成変更に対して生成)

レベル

デフォルトでは、すべてのOracle Access Managementコンポーネントのログ・レベルが「通知」レベルになっています。「エラー」レベルでのロギングで生成される出力は少量ですが、他のログ・レベルではロギング出力が大量になることがあり、その場合はパフォーマンスに影響します。本番環境では、通常はロギングを無効にするか、ロギング出力量が少くなるようなレベル(たとえばエラー・レベル)に設定します。

詳細は、次を参照してください。

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

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

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

関連項目:

- 第10章: Fusion Middleware Controlを使用してログを構成および表示する方法の詳細

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のロギング情報

6.2.1 コンポーネント・ログ出力について

この項では、セキュリティ・トークン・サービスとAccess Managerのコンポーネント・ログ出力について説明します。これらには違いがあります。

セキュリティ・トークン・サービスにあるログ出力は、oracle.security.fedの1つのみです。詳細は、「セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成」を参照してください。

次の表に示すように、それぞれのAccess Managerコンポーネントには対応するログ出力名が関連付けられています。

- 表6-3「Oracle Access Managementのサーバー側コンポーネントのログ出力」

- 表6-4「Oracle Access Management共有サービス・エンジン・コンポーネントのログ出力」

- 表6-5「Oracle Access Management Foundation APIコンポーネントのログ出力」

表6-3 Oracle Access Managementのサーバー側コンポーネントのログ出力

コンポーネント名

OAMロガー名

説明

プロトコル・バインディング

oracle.oam.binding

ワイヤ・プロトコルのリクエストとレスポンスのJavaオブジェクト表現へのマーシャリング/アンマーシャリングを処理します。

SSOコントローラ

oracle.oam.controller.sso

ユーザー・セッションのライフサイクル管理と、SSOおよびログアウト・フローの編成を処理します。

OAMプロキシ

oracle.oam.proxy.oam

OAPプロトコルのリクエストとレスポンスのマーシャリング/アンマーシャリングによるOAM Webゲートとの相互作用と、OAPリクエスト/レスポンスを処理するOAMサーバーを支援するために必要なデータ/メッセージ変換の実行を処理します。

OSSOプロキシ

oracle.oam.proxy.osso

リクエストとレスポンスのマーシャリング/アンマーシャリングによるOSSOエージェントとの相互作用と、mod_ossoリクエスト/レスポンスを処理するOAMサーバーを支援するために必要なデータ/メッセージ変換の実行を処理します。

OpenSSOプロキシ

oracle.oam.proxy.opensso

リクエストとレスポンスのマーシャリング/アンマーシャリングによるOpenSSO WebおよびJavaエージェントとの相互作用と、OpenSSOリクエスト/レスポンスを処理するOAMサーバーを支援するために必要なデータ/メッセージ変換の実行を処理します。

資格証明コレクタ

oracle.oam.credcollector

認証スキームが要求する必須情報を取得するためのユーザーとの相互作用を処理します。

パートナーのリモート登録

oracle.oam.engine.remotereg

OAMサーバーへのパートナの登録と、それに関連付けられた保護済ポリシーの管理を処理します。

Oracle Access Managementコンソール

oracle.oam.admin.console

Access Managementデプロイメントの管理と監視をサポートするコンソールです。

管理サービス構成

oracle.oam.admin.service.config

構成を管理するUIコンソールが使用するモジュールです。

診断とモニタリング

oracle.oam.diag

診断と監視を可能にするためにOAMサーバー・コンポーネントが使用するインスツルメンテーションを提供します。

表6-4 Oracle Access Management共有サービス・エンジン・コンポーネントのログ出力

コンポーネント名

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

OAPランタイム・リクエスト操作に直接マップするメソッドを提供するラッパーです。

表6-5 Oracle Access Management Foundation APIコンポーネントのログ出力

コンポーネント名

OAMロガー名

説明

セッション・アクセス

oracle.oam.session.access

** コードを逆コンパイルしないかぎり、有用ではありません。

セッション・アクセス実行

oracle.oam.session.accessimpl

** コードを逆コンパイルしないかぎり、有用ではありません。

ポリシー・アクセス

oracle.oam.policy.access

** コードを逆コンパイルしないかぎり、有用ではありません。

6.2.2 サンプルのログ出力およびログ・ハンドラの定義

このトピックでは、Access Managerの例のみを示します。

注意:

セキュリティ・トークン・サービスにあるのは、「セキュリティ・トークン・サービスおよびIdentity Federationののロギング構成」で説明しているように、ログ出力とログ・ハンドラそれぞれ1つずつのみです。

例6-1は、logging.xmlファイルでのAccess Managerのログ出力とログ・ハンドラの構成を示します。

例6-1 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項を参照してください。

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

このトピックは、Oracle Access Managementに適用されます。

ロガーにより出力されるデータの量はロガーのレベルによって制御され、レベルが高くなるほどより多くの情報が記録されます。ロガーのレベルは、logging.xmlファイルの中で<logger>要素により、次の書式で指定されます。

<logger name="loggerName" level="notifLevel"/>

ここで、loggerNameはロガー名であり(「コンポーネント・ロガーについて」を参照)、notifLevelはODLメッセージ・レベルとJavaメッセージ・レベルのどちらかです。

表6-6に、ODLメッセージ・レベルとJavaメッセージ・レベルの対応を昇順に示します。

表6-6 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パッケージおよびサブパッケージ(セキュリティ・トークン・サービスのクラス)に定義すると、サーバーを再起動した後でOAMサーバーのログが表示されます。詳細は、「セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成」を参照してください。

6.3 Access Managerのロギング構成

この項では、Access Managerのみのタスクを説明します。

関連項目:

セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成

ロガー・レベルの変更に使用できるグラフィカル・ユーザー・インタフェースはありません。使用できるのはWLSTコマンドのみです。ここでは、次の内容について説明します。

- Access Managerのログ出力レベルの変更

- Access Manager固有のログ出力とログ・ハンドラの追加

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

管理者は、次に示す手順に従い、Access Manager用のカスタムWLSTコマンドを使用してログ出力の設定を変更できます。実際のデプロイメントと選択肢は、説明と異なることがあります。

注意:

WLSTコマンドhelp("fmw diagnostics")を使用してください。

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス

OAMロガー・レベルの変更方法

1. OAMサーバーが稼動中であることを確認します。

2. 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サーバーに関連付けられている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. 「ランタイム・イベント・ロギング構成の検証」へ進みます。

6.3.2 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. Access Managerログ出力とOAMサーバーのレベルを追加します。例:

wls:/base_domain/serverConfig> domainRuntime()
wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam",
level="WARNING", persist="0", target="oam_server1")

5. カスタム・ログ・ハンドラを追加して、それに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/

6.4 セキュリティ・トークン・サービスおよびIdentity Federationのロギングの構成

デフォルトでは、セキュリティ・トークン・サービスとIdentity Federationのメッセージは、OAMサーバーのログ・ファイルに記録されます。Fusion Middleware Controlでログを表示および構成できます。ただし、ここで説明するように、logging.xmlを編集してセキュリティ・トークン・サービスとIdentity Federationの情報を別のログ・ファイルに記録することもできます。

関係するファイルには次のものがあります。

- ロギング構成ファイル: ロガー名と、ロギング用のその他の構成情報を提供します。このファイルは、DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xmlに保存されます。

- ログ・ファイル: たとえば、$DOMAIN_HOME/ostslogs/SERVER-NAME-diagnostics.log。

セキュリティ・トークン・サービスとIdentity Federationでは、ログ・ハンドラがAccess Managerのように分類されません。そのかわり、セキュリティ・トークン・サービスとIdentity Federationのログ・レベルに影響するログ出力が1つだけあります。表6-7では、WLSTコマンドで必要となるこのログ出力の詳細を示します。

表6-7 セキュリティ・トークン・サービスとIdentity Federationのログ出力

コンポーネント名

ログ出力名

ログ・ハンドラ名

ログ・クラス

セキュリティ・トークン・サービスまたはIdentity Federation

oracle.security.fed

stsfed-handler

class=oracle.core.ojdl.logging.ODLHandlerFactory

詳細は、次の項目を参照してください。

- セキュリティ・トークン・サービスまたはIdentity Federationのロギングの構成

- セキュリティ・トークン・サービスまたはIdentity Federationのログ・レベルおよびログ詳細の定義

関連項目:

- 第10章: Fusion Middleware Controlを使用してログを構成および表示する方法の詳細

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のロギング情報

6.4.1 セキュリティ・トークン・サービスまたはIdentity Federationのロギングの構成

管理者は、次の手順を使用してセキュリティ・トークン・サービスまたはIdentity Federationのログ・メッセージをOAMサーバーのメッセージ・ログから切り離すことができます。

セキュリティ・トークン・サービスまたはIdentity Federationのロギングの構成方法

1. 次のlogging.xmlを見つけて開きます。DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

2. 次のように追加して、セキュリティ・トークン・サービスの独立したメッセージ・ログを作成します。

<log_handler name='stsfed-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='stsfed-handler'/>
</logger>

3. ファイルを保存します。

4. 「セキュリティ・トークン・サービスまたはIdentity Federationのログ・レベルおよびログ詳細の定義」に進みます。

6.4.2 セキュリティ・トークン・サービスまたはIdentity Federationのログ・レベルおよびログ詳細の定義

管理者は、ここでの説明に従い、Oracle Access Management用のカスタムWLSTコマンドを使用してセキュリティ・トークン・サービスのログ出力設定を変更できます。この場合は、セキュリティ・トークン・サービスのログ・メッセージ専用の独立した出力ファイルを指定します。

このセキュリティ・トークン・サービスのロギングの手順例は、Access Managerの場合の手順とほとんど同じです。ただしいくつかの違いがあります。実際のデプロイメントの選択肢は、説明と異なることがあります。

注意:

WLSTコマンドhelp("fmw diagnostics")を使用してください。

以下の条件に合致する場合はステップ1から3をスキップしてください。

- OAMサーバーが稼動している

- WLSTスクリプトがある

- すでにサーバーに接続してログインしている

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス

セキュリティ・トークン・サービスのロガー・レベルとログ・ファイルを変更する方法

1. OAMサーバーが稼動中であることを確認します。

2. Oracle Access Management用のカスタム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
DOMAIN_HOME/oiflogs/SERVER-NAME-diagnostics.log

7. 「ランタイム・イベント・ロギング構成の検証」へ進みます。

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

以下の手順を使用して、ランタイム・イベントのロギング構成をテストすることができます。

前提条件

- この章に示すWLSTコマンドを使用してロギングを構成します。

- エージェントとサーバーが稼動していることを確認します。

- 第17章「リソースを保護してSSOを有効化するポリシーの管理」に従い、リソースを保護するためにアプリケーション・ドメインを構成します。

ランタイム・イベント・ロギングの検証方法

1. 保護されたリソースのURLをブラウザに入力し、無効な資格証明を使ってサインインします。

2. 正しい資格証明を使って再度サインインします。

3. 物理サーバー上で、次のパスに生成されるすべてのログを検証します。

DOMAIN_HOME/oamlogs/
DOMAIN_HOME/ostslogs/SERVER-NAME-diagnostics.log
DOMAIN_HOME/oiflogs/SERVER-NAME-diagnostics.log

4. ログ・ファイルを開いて最後のエントリを探し、認証の失敗と成功を確認します。

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

各Webgateインスタンス(10gおよび11g Webgateの両方)は、プロセスおよび状態に関する情報をログ・ファイルに書き込むことができます。ログは、様々なレベルの粒度で情報を提供するように設定できます。たとえば、エラーの記録、エラーおよび状態情報の記録、またはエラーと状態に加えてデバッグ・トレース・レベルのその他の情報を記録することもできます。また、ログから機密情報を削除することもできます。

注意:

特に明記しないかぎり、この項のすべての情報は10gと11gのWebgateに同様に適用されます。たとえば、ログ構成oblog_config_wg.xmlの場所は11gでは変更されましたが、ファイルの内容と他の詳細はほとんど変更されていません。

この章の内容は次のとおりです。

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

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

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

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

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

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

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

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

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

ロギング機能により、システムのパフォーマンスおよび状態を分析し、問題をトラブルシューティングできます。

次のコンポーネントの個別のWebgateインスタンスのロギングを構成できます。

- 10g Webgate

- 11g Webgate

- カスタム・アクセス・クライアント(Access Manager SDK)

コンポーネント・インスタンスの異なる機能領域に対して別々のロギング・レベルを構成できます。たとえば、LDAPアクティビティのデバッグ・データを取得して、それ以外のすべてのコンポーネント・アクティビティではエラー・レベルのデータのみを記録できます。また、コンポーネントが処理する各リクエストで要する時間を記録し、異なるレベルのログ・データを別々の宛先に送信できます。たとえば、エラー情報をファイルに送信し、その他のログ・データをシステム・ログに送信できます。

機密情報の保護: Access Managerでは、ユーザーの機密情報が処理されます。サイトによって異なりますが、ユーザー・パスワード、誕生日、社会保障番号、ロスト・パスワード・リクエストに対するセキュリティ上の質問と回答などが含まれます。セキュリティ番号や保護の対象とするその他の情報も機密データに含めることができます。機密情報は、特定のロギング・レベルで取得されます。現在は、ログ・ファイルの機密情報をフィルタ処理できます(「機密属性のフィルタ処理」を参照してください)。

ロギングの構成: Webgateとともに格納される構成ファイルを編集して、ロギングを構成します。「ログ構成ファイルのパスおよび内容について」を参照してください。

ロギング・レベル: 様々なレベルで、ロギングをリクエストできます。最上位レベルは「致命的」で、最下位レベルは「トレース」です。詳細は、「ログ・レベルについて」を参照してください。

ログ出力先: ログ構成ファイルでは、ログ・ライターと呼ばれるパラメータがログ出力の宛先を決定します。詳細は、「ファイルまたはシステム・ファイルへのログ出力の送信について」を参照してください。ログ・ライターまたはログ・レベルを識別して、ログ出力の完全な定義を作成します。この完全な定義はログ・ハンドラと呼ばれます。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

この後の項では、次の項目について説明します。

- ログ・レベルについて

- ログ出力について

7.1.1 ログ・レベルについて

ロギング・レベルは、ログ・データ・ファイルに書き込まれるデータの量を決定します。各ロギング・レベルは累積的で、上位のレベルで生成されたすべてのデータが各レベルに含まれます。たとえば、エラー・ログには、致命的ログで生成されたすべてのデータに加えて、エラー・カテゴリに固有のイベントが含まれます。

表7-5にレベルを示します。デフォルトのログ・レベルは警告(LOGLEVEL_ WARNING)です。

表7-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 Access Manager API

> 150サード・パーティAPI

このログ・レベルは、コード・パス実行のトレースまたはパフォーマンス・メトリックの取得に使用されます。この情報は、各コンポーネント・ファンクションのエントリ・ポイントおよび終了ポイントで取得されます。通常は、このログ・レベルの情報は開発者にとってのみ意味があります。

これらのログには、機密情報が含まれる場合があります。

LOGLEVEL_ ALL

> 5000

このレベルには、その他のレベルすべてのイベントおよび状態がすべて含まれます。

複合リスト: 隣接していないレベルからログ・データを収集し、異なるレベルのログ・データを別々の宛先に送信できます。たとえば、致命的ログをシステム・ログに送信し、エラー・ログをファイルに書き込めます。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

しきい値: グローバル・カットオフまたはしきい値を構成して、ログ構成ファイルのLOG_THRESHOLD_LEVELパラメータでロギングできます。デフォルトでは、ログ・ハンドラの構成済レベルがカットオフを超えると、ログ・データは収集されません。LOG_THRESHOLD_LEVELパラメータがログ・ハンドラで構成されたレベルに優先するため、構成済レベルにかかわらず、ログが書込みに失敗する場合があります。ログ構成ファイルのMODULE_CONFIGセクションのみがグローバルしきい値をオーバーライドします。詳細は、「単純なリストおよびロギングしきい値」を参照してください。

オーバーライド: グローバル・ロギングしきい値に対する機能固有またはモジュール固有のオーバーライドを、MODULE_CONFIGパラメータに指定します。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

注意:

「トレース」および「デバッグ3」レベルのログには、機密情報が含まれる場合があります。機密情報の詳細は、「機密属性のフィルタ処理」を参照してください。

7.1.2 ログ出力について

ログ出力ファイルの各行は、特定の構造に従います。行は、日付およびタイム・スタンプで始まり、次にリクエストを処理するスレッド、ログが記録された機能またはモジュールの名前とログ・レベルが続きます。

次に、ログ出力ファイルの最も左の列のスナップショットを示します。

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"または"Function returned"などのこのログ・レベルに割り当てられたログ・メッセージがあり、次に示すような機能の名前が続きます。

"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

機密情報を保護して、ロギング操作の出力に含まれないようにする方法は、「機密属性のフィルタ処理」を参照してください。

関連項目:

「ログ構成ファイルの内容」

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

ログ構成ファイルoblog_config_wg.xmlは、Webgateロギング(oblogs)の構成詳細を指定するために使用します。

プレーン・テキスト・エディタで編集するXMLベースのログ・ファイル内のWebgateログ出力を制御するパラメータを構成します。これらのファイルに対する変更は、即時に有効になります。

この後の項では、次の項目について説明します。

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

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

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

デフォルトでは、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/ohs/configおよびInstance_Home/webgate/configの下のWebgate/Oracle_Home後者はロギングを構成するときに使用します。

同じ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の両方に、編集のガイドとして役立つコメントが含まれます。

表7-2にログ構成ファイルの名前をリストします。名前を変更しないでください。

表7-2 コンポーネントのログ構成ファイル名

コンポーネント

ログ構成ファイル名

Webgate

oblog_config_wg.xml

Access Manager SDK (カスタム・アクセス・クライアント)

oblog_config.xml

重要:

いずれのロギング構成ファイルについても、デフォルトのパスまたは名前を変更しないでください。

oblog_config_wg.xmlファイルの編集では、ファイルを更新した後も有効なXMLであることが明確であれば、任意のテキスト・エディタを使用できます。ファイルの更新後、変更は約60秒で有効になります。

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

ログ構成ファイルは次の項目を制御します。

- コンポーネントでログに記録される内容

- データの送信先

- 特定の場合のみ、ログで使用される書込みバッファのサイズ

- ログ・ファイル・ローテーション間隔

ログ構成ファイルにはテキスト・エディタで編集できるXML文が含まれます。

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

ウォッチャ・スレッドは、ログ構成ファイルに対する変更を60秒ごとに取得し、その変更を有効にします。サーバーを再起動する必要はありません。

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

デフォルトの各ログ構成ファイルには、ファイルの編集に役立つコメントが含まれます。

関連項目:

ご使用のシステムのログ構成ファイル。

コメントのあるデフォルト構成ファイルをここに示します。

コメントは、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.       -->

例7-1に、コメントのある典型的なログ構成ファイルを示します。例7-8に、コメントのない典型的なログ構成ファイルを示します。

例7-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>

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

ログ出力を送信先へ送信するには、ログ・ライターを構成します。ログ・ライターはログ出力を次のうちの一方または両方に送信することも、いずれにも送信しないようにすることもできます。

- ログ・ファイル
このファイルは、コンポーネントのルート・インストール・ディレクトリの下にあります。

- コンポーネントに対するホストのシステム・ファイル
複数のコンポーネントが同じホストに存在する場合、すべてのコンポーネントがそのホスト上のシステム・ログ・ファイルにデータを送信します。

特定のレベルのログまたは異なるレベルのログを、複数のタイプのログ・ライターに送信できます。たとえば、致命的データをシステム・ログに送信し、トレース・データをファイルに送信できます。または、致命的データをシステム・ログとファイルの両方に送信できます。

ログ・ハンドラ定義にあるLOG_WRITERパラメータを使用して、ログ構成ファイル内のログ・ライターを定義します。詳細は、「2番目の複合リストおよびログ・ハンドラ」を参照してください。

ログ・ライターについて、表7-3で説明します。

表7-3 ログ・ライター

ライター

説明

SysLogWriter

ログに記録されるコンポーネントをホストするコンピュータのシステム・ログ・ファイルにデータを送信します。通常、システム・ログ・ファイルには、複数のアプリケーションおよびホスト・オペレーティング・システムによるイベント情報が含まれます。

Windowsマシンの場合、これは「マイ コンピュータ」、「管理」、「イベント ビューア」、「アプリケーション」にあるアプリケーション・ログ・ファイルです。

UNIXプラットフォームの場合、システム・ログ・ファイルの名前と場所は、システム管理者のコンピュータとプリファレンスに応じて異なります。ファイルの場所は、コンピュータの管理者に確認してください。

デフォルトのログ構成ファイルは、致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログ・ファイルに送信します。

FileLogWriter

このライターは、OAMサーバーまたはその他のシングルプロセス・アプリケーションのログ・データをディスク・ファイルに保存する場合にお薦めします。

FileLogWriterは、ログ・ファイルを開き、おおよそのファイル・サイズ制限またはファイル・ローテーション間隔に達するまでディスク書込み用にファイルを開いたままにします。複数のプロセスが同じログ・ファイルに書き込む必要のある状況では、このログ・ライターをお薦めしません。このような状況では、MPFileLogWriterを使用してください。

MPFileLogWriter

このライターは、FileLogWriterに似ていますが、データをファイルに書き込むたびにログ・ファイルを開いて閉じる点が異なります。これにより、複数のプロセスが順番にファイルに書き込むことができます。ただし、これによってパフォーマンスが大幅に低下します。

MPFileLogWriterは、マルチプロセスWebサーバー(Apacheなど)またはSolarisバージョンのiPlanet Webサーバーにインストールされているアクセス・クライアントなど、マルチプロセス・アプリケーションに関連するプロセスの一部で、FileLogWriterがロギング・データの記録に失敗する場合にのみ使用することをお薦めします。

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

ログ構成ファイルは標準形式に準拠します。パラメータの編集や、ログ・ハンドラ定義と呼ばれる特定のセクションの追加または除去はできますが、ログ構成ファイルの基礎となる形式の変更はできません。

デフォルトのログ構成ファイルのリスティングは、例7-1または例7-8を参照してください。

この後の項では、次の項目について説明します。

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

- 最初の複合リスト

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

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

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

- フィルタ・リスト

- XML要素の順序について

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

ログ構成ファイルの先頭には、XMLファイル・ヘッダーがあります。

<?xml version="1.0" encoding="ISO-8859-1" ?>

ヘッダーは次の目的で使用します。

- ヘッダーは、関連するXMLバージョン(常に1.0)を宣言します。

- また、エンコーディング形式(常にISO-8559-1)を宣言します。

7.4.2 最初の複合リスト

ヘッダーの後に、次のように区切られた最初の複合リストが続きます。

<CompoundList xmlns="http://www.oblix.com" ListName="logframework.xml.staging">
. . .
</CompoundList>

最初の複合リストの構造は次のとおりです。

- 複合リスト開始タグは、xmlnsパラメータ内のログ構成ファイルの関連XMLネームスペースを示します。

- また、複合リスト開始タグは、ListNameパラメータ内の複合リストの名前を指定します。

- 複合リスト終了タグは、ファイルの最後の近くで発生します。
この複合リストは、すべての構成情報を区切ります。

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

最初の複合リスト開始タグの後に、次のように、単純なリストでロギングのグローバル・デフォルトを設定します。

<SimpleList>
. . .
</SimpleList>

単純なリストの開始タグと終了タグとの間は、次のように構成します。

表7-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番目の複合リスト(ログ・ハンドラ)の後に表示されます。詳細は、「機密属性のフィルタ処理」を参照してください。

例7-2は、oblog_config_wg.xmlファイルの最初の複合リストに表示されるグローバル設定を含む単純なリストを示しています。

例7-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>

7.4.4 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"文が含まれています。その値は、表7-1にある予約名になります(次を参照)。

<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />

- 2番目のNameValPair要素は、ログ出力の宛先を定義します。
この要素にはParamName="LOG_WRITER"文が含まれ、その値は次のように表7-3の予約名です。

<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />

- 3番目のNameValPair要素は、ログ・ハンドラのオンとオフを切り替えます。
この要素にはParamName="LOG_STATUS"文が含まれ、次のように、OnまたはOffの値を伴います。

<NameValPair ParamName="LOG_STATUS" Value="On" />

最後に、ValNameListの開始タグと閉じタグ内で、FileLogWriterまたはMPFileLogWriterをログ・ライターとして指定すると、次のうちの一部またはすべてを追加するか、いずれも追加しないようにできます。詳細は、表7-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" />

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

ログ・ハンドラを区切る複合リスト終了タグの後および最初の複合リストの終了タグの前に、モジュール固有のロギング・パラメータを追加できます。

詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

7.4.6 フィルタ・リスト

モジュール固有のロギング・パラメータの後で、ログ・ファイルからフィルタ除去する必要がある機密情報がフィルタ・リストにより識別されます。たとえば、パスワードとパスワードを忘れた場合の応答は、ログ・ファイルからフィルタで除去する必要がある機密情報です。

FILTER_LISTパラメータに関連付けられている名前と値の各ペアは、ログへの書込みの前にチェックする単語やフレーズの名前、およびその単語またはフレーズのマスキングの長さを指定します。ロギング時には、その単語またはフレーズがマスキングされ、ログ・ファイルから削除されます。

つまり、ロギング時には、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)。

デフォルトのフィルタ・リストを例7-3に示します。

例7-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>

フィルタ・リストに別の属性を追加する場合は、表示名および属性名をディレクトリ・サーバーに含める必要があります。

7.4.7 XML要素の順序について

XMLを使用する場合、要素自体が変更されず、最初に囲まれていたタグ内に含まれているかぎり、リスト内で並列の要素を任意の順序で指定できます。たとえば、例7-4と例7-5のリストは同等です。

例7-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>

例7-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>

同様に、ある特定のタグ内の属性(常にタグの山カッコ内の最初の要素である必要があるタグ名を除く)は、変更されておらず、最初に囲まれていたタグ要素内にあるかぎり、並べ替えることができます。例7-6と例7-7の名前/値リストの開始タグは同等です。

例7-6 名前/値リストの開始タグ

<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys">

例7-7 名前/値リストの開始タグ

<ValNameList ListName="LogError2Sys" xmlns="http://www.example.com">

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

様々な要因により、ロギングが特定のログ・ハンドラに対してアクティブかどうかが決まります。表7-5に、これらの要因をリストします。

表7-5 ロギングがアクティブかどうかを決定する要因

要因

重要度

説明

LOG_ THRESHOLD_ LEVEL

プライマリ

このパラメータは、ロギングのカットオフを設定します。しきい値よりも詳細なログ・レベルは抑制されます。有効なログ・レベルは、表7-1を参照してください。

MODULE_CONFIGパラメータを使用して、ログを記録できる項目のサブセットに対してこのパラメータをオーバーライドできます。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

MODULE_CONFIG

プライマリ

このパラメータは、グローバル・ロギングしきい値のモジュール固有のオーバーライドを設定します。

詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

LOG_STATUS

セカンダリ

このパラメータは、ロギングしきい値またはモジュール固有のオーバーライドで上書きされないかぎり、ロギングのオンとオフを切り替えます。

ログ・ハンドラの物理的な位置

セカンダリ

「ログ・ハンドラの優先順位について」を参照してください。

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

ログ構成ファイルに単一のログ・レベルに対して最大3つのログ・ハンドラ定義を構成できます。特定のログ・レベルの出力を、表7-3で説明される3つの各ログ・ライターに送信する場合は、3つの異なるログ・ハンドラが必要です。

異なるLOG_STATUS設定をこれらのログ・ハンドラに設定する場合、ログ構成ファイルの物理的な終わりに最も近いログ・ハンドラ定義の設定が、同一のログ・レベルの他のログ・ハンドラ定義のステータスを設定します。たとえば、「エラー」ログ・レベルの最初の2つのログ・ハンドラに対してLOG_STATUSをOffに設定できますが、構成ファイル内の3番目の最後のログ・ハンドラに対してLOG_STATUSをOnに設定すると、ロギングは3つのハンドラすべてに対して行われます。

LOG_STATUS設定は、そのレベルが現在のLOG_THRESHOLD_LEVELよりもきめ細かい場合には、無意味になります。この場合、しきい値がモジュール固有のしきい値でオーバーライドされないかぎり、ロギングはこのレベルでアクティブ化されません。詳細は、「異なるデータのタイプへの異なるしきい値レベルの構成」を参照してください。

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

各ログ・ハンドラ定義には、最低でも、表7-6にリストする5つのパラメータが含まれます。

表7-6 必須のログ構成ファイル・パラメータ

パラメータ

コメント

xmlns

このパラメータはValNameList開始タグ内で指定されます。

現在のリストの関連XMLネームスペースを指定し、ある特定のロギング構成ファイル内のすべてのログ・ハンドラ定義に対して同一です。次に例を示します。

http://www.example.com

ListName

このパラメータはValNameList開始タグ内で指定されます。可能な場合はデフォルト名を使用します。

新規のログ・ハンドラ定義の作成の際、他のログ・ハンドラと間違えることのない憶えやすい名前を選択してください。次に例を示します。

WarningsAndAboveToSyslogは、致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログ・ファイルに送信します。

WarningsOnlyToFileLog128KBufferは、警告レベルのメッセージを128KBバッファに従ってディスク・ファイルに送信します。

TraceOnlyToMPRotateDailyはメッセージをトレース・レベルのみからマルチプロセス・ファイル・ライターへ送信し、マルチプロセス・ファイル・ライターはファイルをディスクへ書き込むたびに開いて閉じます。このファイルは、置換時のファイルのサイズには関係なく、新しい(空の)ファイルで毎日置換されます。

LOG_LEVEL

これにより、ログ・レベルが指定されます。詳細は、表7-1を参照。

デフォルトのロギング構成ファイルは、「致命的」、「エラー」、「警告」の3つのレベルのロギングをアクティブにします。

LOG_WRITER

このログ・ライターのログ出力の宛先を指定します。詳細は、表7-3を参照。

デフォルトのログ構成ファイルは、出力をシステム・ログとロギングを行っているコンポーネントのログ・データ・ファイルの両方に送信します。

LOG_STATUS

このパラメータは、ログ・ハンドラを「オン」または「オフ」にします。

LOG_WRITERパラメータの値としてFileLogWriterまたはMPFileLogWriterを指定した場合は、表7-7の4つのパラメータが関連します。

表7-7 ログ・データ・ファイル構成パラメータ

パラメータ

説明

デフォルト

FILE_ NAME

必須です。FileLogWriterまたはMPFileLogWriterのみに使用します。ログ・データが書き込まれるファイルの名前と場所です。

ファイル名に絶対パスを付加して、次のデフォルトの場所以外に格納できます。

component_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日の秒数)

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

各コンポーネントとともにインストールされるログ構成ファイルは、ログに記録されるイベントの階層の上位3つのレベル(「致命的」、「エラー」および「警告」)のみアクティブにし、すべてのログ出力をシステム・ログに送信ます。

Windowsコンピュータでは、「マイ コンピュータ」、「管理」、「イベント ビューア」、「アプリケーション」にナビゲートすることで、ロギングしているコンポーネントをホストするコンピュータのシステム・ログを表示できます。ログに記録されるコンポーネントのシステム・イベント・エントリは、オペレーティング・システムおよびAccess Manager以外のアプリケーションに対してレポートされるシステム・イベントに散在します。

SolarisおよびLinux環境の場合、システム・ログの場所はシステム構成ファイルに記録されますが、このシステム構成ファイルの細目はコンピュータごとに異なる場合があります。このシステム・ファイルやシステム・ログの名前と場所については、システム・ログを調べるコンポーネントのホストとなるコンピュータの所有者に相談してください。

例7-8に、デフォルトのログ構成ファイルを示します。ここでは、ファイル構造を明らかにするためにコメントを削除してあります。

例7-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>

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

デフォルトの構成ファイルは致命的メッセージ、エラー・メッセージおよび警告メッセージをシステム・ログと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に送信されるため、ファイル名、バッファ・サイズ、ローテーション・サイズおよびローテーション間隔を制御するパラメータはすべて有効になります。

図7-1は、デフォルトのログ構成ファイルでのログレベルのアクティブ化を示します。

図7-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化

「図7-1 デフォルトのログ構成ファイルでのログレベルのアクティブ化」の説明

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

問題の診断では、コンポーネントが実行するすべての操作の詳細なログを必要としない場合があります。たとえば、アイデンティティ・サーバーがそのディレクトリに送信するリクエストの応答時間の遅れを診断する場合、LDAP操作の詳細ログを必要とし、それ以外タイプの操作は詳細でなくても構いません。

リリース10.1.4.2では、Access Managerで一部のコンポーネントの詳細なログを生成し、他のコンポーネントでは簡潔なログを生成するまたはログを生成しないように、モジュール固有または機能固有のしきい値レベルをログ構成ファイルで構成できます。

モジュール固有ロギングしきい値は、oblog_config_wg.xmlファイルのMODULE_CONFIGセクションで構成します。MODULE_CONFIGセクションは、このファイルの単純なリストのセクション内のLOG_THRESHOLD_LEVELで指定するグローバルのデフォルトをオーバーライドします。

この後の項では、次の項目について説明します。

- MODULE_CONFIGセクションについて

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

7.7.1 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パラメータは、モジュールまたは機能の名前を設定します。
使用可能な値のリストは、表7-8を参照してください。

- Valueパラメータは、ParanNameパラメータの値として指定したモジュールのロギングしきい値を設定します。
表7-1に、Valueパラメータで使用可能な値をリストします。これらの値に加えて、値をONに設定するとモジュールのロギングを有効にし、値をOFFに設定すると特定のモジュールのロギングを無効にできます。

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

ログ構成ファイルの終了近く、ログ・ハンドラの複合リストの終了タグの後およびファイル内の最初の複合リストの終了タグの前に、モジュール固有しきい値セクションを追加します。

このセクションには、モジュール固有ロギング・セクションの例が含まれます。詳細は、「モジュール固有しきい値を構成する手順」を参照してください。

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

表7-8に、MODULE_CONFIGリスト内でParamNameパラメータに指定できる値のリストの一部を示します。

表7-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 Management開発者ガイドを参照してください。

ACCESS_SERVER

OAMサーバーで実行される操作のロギングしきい値を設定します。

AM_SDK

Access Manager SDKのロギングしきい値を設定します。

詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

AUDIT

監査のロギングしきい値を設定します。

詳細は、第8章を参照してください。

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 Management開発者ガイドを参照してください。

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 Management開発者ガイドを参照してください。

QUERY_BUILDER

クエリー・ビルダー操作のロギングしきい値を設定します。

SECURITY

セキュリティおよび暗号化ライブラリのロギングしきい値を設定します。

SELECTOR

セレクタ操作のロギングしきい値を設定します。

SERVER

サーバー・インフラストラクチャのロギングしきい値を設定します。

SSOTOKEN

シングル・サインオン・トークン管理。

UTILS

ユーティリティ・クラスのロギングしきい値を設定します。

WEB

Webサーバー・プラグイン・インタフェースのロギングしきい値を設定します。

XML

XMLインフラストラクチャのロギングしきい値を設定します。

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

次の手順では、機能固有またはモジュール固有のログ・レベルしきい値を構成する方法について説明します。

モジュール固有しきい値を構成する手順

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パラメータで指定できるモジュールについては、表7-8を参照してください。値は表7-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>

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

前述のように、セキュア・ロギングをアクティブ化してデフォルトのフィルタ・リストを拡張すると、ログ・ファイルの機密情報をマスキングできます。

フィルタ・リストに別の属性を追加する場合は、表示名および属性名をディレクトリ・サーバーに含める必要があります。次の手順では、このタスクの実行方法を説明します。この例では、ユーザーの自宅電話番号(表示名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が同じレベルである、または互いに一貫性があることを確認します(表7-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を繰り返します。

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

Oracle Fusion Middlewareでは、監査とは、管理イベント、認証イベントおよびランタイム・イベントに関連する特定の情報を再確認するために収集するプロセスのことを指します。監査は、ポリシー、ユーザー・アクセス・コントロールおよびリスク管理手順への準拠を評価する上で役に立ちます。監査は、アカウンタビリティの手段提供するとともに、「誰がいつ何を行ったか」という質問の答えを明らかにします。監査データは、ダッシュボードの作成、履歴データの集計、およびリスクの評価に使用できます。記録された監査データを分析すれば、コンプライアンス担当者がコンプライアンス方針を定期的に確認できます。

この章では、Oracle Access Managementサービス(Access Manager、セキュリティ・トークン・サービス、Identity Federation、Mobile and Social)の監査可能な管理イベントとランタイム・イベントについて説明します。共通監査設定の構成および設定した監査構成の検証がこの章の主題です。監査データの分析と監査についてはこの章では取り上げません。

注意:

OpenSSOエージェント、Mobile and Socialまたはアイデンティティ・コンテキストに固有の監査や個別に関連する監査はありません。特に明記しないかぎり、この章の情報は、Access Manager、セキュリティ・トークン・サービス、Identity Federationのどれに関しても同じです。

この章の内容は次のとおりです。

- 前提条件

- 監査の概要

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

- 監査可能なIdentity Federationイベント

- 監査可能なセキュリティ・トークン・サービス・イベント

- Oracle Access Managementの監査の設定

- 監査とレポートの検証

8.1 前提条件

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で、次に関する項を再確認してください。

- Oracle Fusion Middleware監査フレームワークの概要

- Oracle Business Intelligence Publisherの設定

- 監査レポートのカスタマイズ

- 監査データベースの配置方法の詳細: Oracle Fusion Middleware監査フレームワーク・リファレンス

8.2 監査の概要

現在では多くのビジネスにおいて、アイデンティティ情報や、アプリケーションおよびデバイスへのユーザー・アクセスを監査できることが求められます。コンプライアンス監査は、企業が法的要件を満たしていることを確認する助けとなります—例としては、Sarbanes-Oxley ActやHealth Insurance Portability and Accountability Act(HIPAA)の2つが挙げられます。

Oracle Access Managementは、Oracle Fusion Middlewareの共通監査フレームワークを使用し、大量のユーザー認証イベントと認可イベント、および管理イベント(システムへの変更)の監査を支援します。Oracle Fusion Middlewareの共通監査フレームワークを使用すれば、ロギングと例外を一様な形で取り扱い、すべての監査イベントの診断を行うことができます。

監査は、ユーザーまたはユーザー・グループのデータ取得を可能にするOracle Access Managementコンソールで設定した構成パラメータに基づいています。監査機能は有効または無効のどちらに設定しておくことも可能ですが、本番環境では有効にしておくのが普通です。監査による性能への影響は最小限に抑えられており、監査によって得られた情報は有用です(業務に不可欠な場合もあります)。詳細は、 「Oracle Access Managementの監査構成について」と「セキュリティ・トークン・サービスの監査の概要」を参照してください。

監査データは、集中管理された1つのOracle Databaseインスタンスや、バスストップ・ファイルと呼ばれるフラット・ファイルに書き込むことができます。

注意:

Oracle Fusion Middleware共通監査フレームワークのデータベース監査ストアは、Access Managerポリシーやセッション・データを含まず、Oracle Access Managementコンソールからは構成されません。

監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。詳細は、「監査ログとデータについて」を参照してください。

8.2.1 Oracle Access Managementの監査構成について

管理者は、Oracle Access Managementコンソールを使用して一定の監査パラメータを制御します。この監査構成は、ファイルoam-config.xmlに記録されます。その他の監査構成は、共通管理フレームワークを通じて設定する必要があります。

注意:

変更にはOracle Access ManagementコンソールまたはWebLogic Scripting Tool (WLST)コマンドのみを使用することをお薦めします。oam-config.xmlは編集しないでください。

イベント構成(レベルへのイベントのマッピング)は、component_events.xmlで発生します。監査レコードには、特定の要件を満たすために構成できるアイテムのシーケンスが含まれます。

Oracle Access Managementコンソール内では、ログ・ファイルとログ・ディレクトリの最大サイズを設定できます。監査ポリシー(フィルタ・プリセットと呼ばれます)は、特定のコンポーネントについて監査フレームワークによって取得されるイベントのタイプを宣言します。

Fusion Middleware Controlを使用して監査ポリシーを構成することはできません。Oracle Access Managementは、監査構成でJPSインフラストラクチャを使用しません。監査用のWebLogic Scripting Tool (WLST)コマンドはありません。

注意:

OpenSSOエージェント、Mobile and Social、アイデンティティ・コンテキストに関して個別に取り上げている部分はありません。特に明記しないかぎり、この章の情報は、Access Manager、セキュリティ・トークン・サービス、Identity Federationのどれに関しても同じです。

関連項目:

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

- 「監査可能なセキュリティ・トークン・サービス・イベント」

8.2.2 監査記録の保存について

監査データは、集中管理された1つのOracle Databaseインスタンスや、バスストップ・ファイルと呼ばれるフラット・ファイルに書き込むことができます。

デフォルトでは、監査データはファイルに記録されます。しかし、管理者は、監査データをデータベースに記録するように構成を変更できます。書式は異なりますが、監査データの内容はフラット・ファイルの場合もデータベースの場合も同じです。

監査バスストップ: 監査データ・レコードが監査データ・ストアにプッシュされる前に格納されるローカル・ファイルです。監査データ・ストアが構成されていない場合、監査データはこれらのバスストップ・ファイルに残ります。バスストップ・ファイルは、特定の監査イベントを検索するために簡単に問い合せられる単純なテキスト・ファイルです。監査データ・ストアが配備されている場合、バスストップはコンポーネントと監査データ・ストア間の中間的な場所として機能します。これらのローカル・ファイルは、構成可能な時間間隔に基づいて、監査データ・ストアに定期的にアップロードされます。

Javaコンポーネント用のバスストップ・ファイルは、次の場所にあります。

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/OAM/audit.log

システム・コンポーネント用のバスストップ・ファイルは、次の場所にあります。

$ORACLE_INSTANCE/auditlogs/OAM/oam_server1/audit.log

データベース・ロギング: Oracle Fusion Middlewareの全製品について共通監査フレームワークを実行します。その利点は、プラットフォーム・レベルで監査機能が共通化されることです。

データベース監査ストア: 本番環境においては、共通監査フレームワークのスケーラビリティと高可用性を実現するために、データベース監査ストアを使用することをお薦めします。監査データは累積的なもので、その量は時間とともに増大します。これは監査データ専用のデータベースとして、他のアプリケーションは使用しないようにするのが理想です。

注意:

本番環境において望ましいモードは、監査データ専用のスタンドアロンRDBMSデータベースに監査記録を書き込むことです。

監査データ・ストアの主な利点は、複数のコンポーネントの監査データ(すべてのミドルウェア・コンポーネントやインスタンスにおける認証失敗など)をレポート内で関係付けて結合できる点です。

監査記録用の恒久的ストアとしてのデータベースに切り替えるには、まず、リポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・スキーマを作成する必要があります。RCUは、データベースに監査記録を格納するために必要なスキーマを使用して、そのデータベース・ストアをシードします。スキーマ作成後にデータベース監査ストアを構成するには次の操作が必要です。

- 作成した監査スキーマを参照するデータ・ソースの作成

- そのデータ・ソースを参照する監査ストアの設定

図8-1は、サポート対象データベースを使用した監査アーキテクチャの簡略図です。Oracle Fusion Middleware監査フレームワークの監査ログ表用スキーマはリポジトリ作成ユーティリティ(RCU)によって提供されます。このユーティリティは、データベースに情報をログする前に起動している必要があります。

図8-1 データベースによる監査アーキテクチャ

「図8-1 データベースによる監査アーキテクチャ」の説明

関連項目:

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」

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

独立した監査ローダー・プロセスがフラット・ログ・ファイルを読み込んで、Oracleデータベースのログ表にレコードを挿入します。管理者は、監査ストアを使用することにより、Oracle Business Intelligence Publisherの様々な既製レポートを使用して監査データを表示できます。

8.2.3 監査レポートとBusiness Intelligence Publisherについて

Oracle Access Managementは、あらかじめ設定されたコンプライアンス・レポートを提供するOracle Business Intelligence Publisherと統合化できます。データベース監査ストア内のデータは、Oracle Business Intelligence Publisherであらかじめ定義されたレポートを通じて表示されます。これらのレポートを使用すれば、ユーザー名、時間範囲、アプリケーション・タイプ、実行コンテキスト識別子(ECID)などの様々な基準に基づいて、監査データをドリルダウンできます。

Oracle Access Managementには、そのまますぐに使用できるサンプル監査レポートがいくつか用意されており、これらのレポートには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セキュリティ・ガイド』の「監査分析とレポートの使用」

Oracle Access Managementの監査レポートとともに使用するOracle BI EEの準備方法の概要については、「Oracle Business Intelligence Publisher EEの準備」を参照してください。

Oracle Business Intelligence Enterprise Editionのレポートには、データ・フィールドと一目で内容が理解できるラベルの列挙フィールドが含まれています。このレポートの内容については、表8-1に示します(My Oracle Supportのナレッジ・ベース・ドキュメントID 1495333.1からの引用)。

表8-1 Oracle Business Intelligence Enterprise EditionのOAMに関するレポート

レポート・タイプ

説明

アカウント管理

ユーザーID | タイムスタンプ | コンポーネント/アプリケーション名 | イベント詳細

Authentication_Statistics

Authentication_statistics

失敗 | ユーザーID | イベント数

AuthenticationFromIPByUser

IPアドレス | 個々のユーザー数 | 合計試行回数 | ユーザー

AuthenticationPerIP

IPアドレス | 個々のユーザー | 合計試行回数

AuthenticationStatisticsPerServer

サーバー・インスタンス名 | 成功件数 | 失敗件数

Errors_and_Exceptions

All_Errors_and_Exceptions

ユーザーID | タイムスタンプ | コンポーネント/アプリケーション名 | クライアントIPアドレス | メッセージ・イベント | イベント詳細

Authentication_Failures

ユーザーID | タイムスタンプ | コンポーネント/アプリケーション名 | クライアントIPアドレス | 認証方式 | メッセージ・イベント詳細 | Authorization_Failures

Users_Activities

Authentication_History

ユーザーID | タイムスタンプ | コンポーネント/アプリケーション名 | クライアントIPアドレス | 認証方式 | メッセージ・イベント詳細 | Authorization_Failures

Multiple_Logins_From_Same_IP

IPアドレス | 使用ユーザー名

詳細は、次の各項を参照してください。

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

- 監査可能なIdentity Federationイベント

- 監査可能なセキュリティ・トークン・サービス・イベント

8.2.4 監査ログとデータについて

監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。監査ログ・ファイルには、Date、Time、Initiator、EventType、EventStatus、MessageText、ECID、RID ContextFields、SessionId、TargetComponentType、ApplicationName、EventCategoryなどを含むいくつかのフィールドが記録されます。

関連項目:

『Oracle Fusion Middlewareセキュリティ・ガイド』の監査の構成と管理に関する章に含まれる監査ログ関連項目

8.3 監査可能なAccess Managerイベント

この項の内容は次のとおりです。

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

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

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

関連項目:

- 監査可能なIdentity Federationイベント

- 監査可能なセキュリティ・トークン・サービス・イベント

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

管理イベントとは、Oracle Access Managementコンソール使用時に作成されるイベントです。

監査可能なAccess Manager固有の管理イベントと、これらのイベントが取得する内容の詳細を表8-2に示します。これらのイベントの定義と構成は、Oracle Platform Securityの監査サービスの一部として実行されます。

注意:

「監査構成」セクションでフィルタ・プリセットを選択することによって、記録される情報の量とタイプを制御します。

各フィルタ・プリセットの監査可能イベントは、読取専用のcomponent_events.xmlファイル内に指定されています。このファイルをカスタマイズしたり編集したりすることはできません。

表8-2 Access Manager管理監査イベント

管理イベント

含まれるイベント・データ

Oracle Access Managementコンソールのログインの成功/失敗

- ユーザー名

- リモートIP

- ロール

認証ポリシーの作成

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

認証ポリシーの変更

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

- 古いポリシー名

- 古い認証スキームの詳細

- 古いリソースの詳細

認証ポリシーの削除

- ポリシー名

- 認証スキームの詳細

- リソースの詳細

- ポリシー・タイプ(認証または認可)

リソースの作成

- リソース名

- URI

- 操作

- リソース・タイプ

リソースの変更

- リソース名

- URI

- 操作

- リソース・タイプ

- 古いリソース名

- 古いURI

- 古い操作

リソースの削除

- リソース名

- URI

- 操作

- リソース・タイプ

認証スキームの作成

- スキーム名

- 認証モジュール

- レベル

認証スキームの変更

- スキーム名

- 認証モジュール

- レベル

- 古いスキーム名

- 古い認証モジュール

- 古いレベル

認証スキームの削除

- スキーム名

- 認証モジュール

- レベル

レスポンスの作成

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

レスポンスの変更

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

- 古いレスポンス名

- 古いレスポンス・キー

- 古いデータ・ソース

レスポンスの削除

- レスポンス名

- レスポンス・キー

- データ・ソース

- レスポンス・タイプ

パートナーの追加

- パートナー名

- パートナーID

- パートナーURL

- ログアウトURL

パートナーの変更

- パートナー名

- パートナーID

- パートナーURL

- ログアウトURL

- 古いパートナー名

- 古いパートナーURL

- 古いログアウトURL

パートナーの削除

- パートナー名

- パートナーID

- パートナーURL

- ログアウトURL

条件の作成

- 条件名

- 条件タイプ

- 条件データ

条件の変更

- 条件名

- 条件タイプ

- 条件データ

- 古い条件名

- 古い条件タイプ

- 古い条件データ

条件の削除

- 条件名

- 条件タイプ

- 条件データ

サーバー・ドメインの作成

- ドメイン名

サーバー・ドメインの変更

- ドメイン名

- 古いドメイン名

サーバー・ドメインの削除

- ドメイン名

サーバーの構成変更

- 新しい詳細

- 古い詳細

- インスタンス名

- アプリケーション名

- ユーザー名

- リモートID

- ロール

- 日付と時刻

8.3.2 監査可能なAccess Managerランタイム・イベント

ランタイム・イベントは、Access Managerのコンポーネント・エンジンが互いに連携動作するときに生成される一部のイベントによって作成されるイベントです。

生成時に監査可能なランタイム・イベントと、それらのイベントが取得する内容の詳細を表8-3に示します。これらのイベントの定義と構成は、Oracle Platform Securityの監査サービスの一部として実行されます。

注意:

「監査構成」でフィルタ・プリセットを選択することによって、記録される情報の量とタイプを制御します。

各フィルタ・プリセットの監査可能イベントは、読取専用のcomponent_events.xmlファイル内に指定されています。このファイルをカスタマイズしたり編集したりすることはできません。

表8-3 Access Managerランタイム監査イベント

ランタイム・イベント

発生時期

含まれるイベント詳細

認証の試行

ユーザーが保護されたリソースにアクセスしようとして、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

サーバーの起動

サーバーが起動した時。

- 日付と時刻

- インスタンス名

- アプリケーション名

- ユーザー名

サーバーの停止

サーバーが停止した時。

- 日付と時刻

- インスタンス名

- アプリケーション名

- ユーザー名

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

認証中にイベントを監査することは、管理者がシステム内のセキュリティ上の弱点を精査する助けとなります。認証を要求しているユーザーやブルート・フォース攻撃に関する情報を、ファイル・システムやバックエンド・データベースに保存することができます。

認証時の監査のために管理者が構成できるイベントには次のようなものがあります。

- 認証の成功

- 認証の失敗

- 認証ポリシー・データの作成、変更、削除、または表示

認証されるユーザーに関する情報には以下のものが含まれます。

- IPアドレス

- ブラウザ・タイプ

- ユーザー・ログインID

- アクセスの時間

注意:

ユーザー・パスワードなどの取り扱いに注意を要するユーザー属性の監査、ログイング、またはトレースは避けることをお薦めします。

8.4 監査可能なIdentity Federationイベント

Identity Federationは、Fusion Middleware監査フレームワークを使用して監査を行います。この項では、監査されるイベントの概要と、Identity Federationの構成方法を説明します。

次のデータは、監査されるイベントまたはイベント・タイプに関係なく、各監査レコードに含まれています。

- timestamp: 監査イベントが発生したときの日付と時刻

- initiator: 監査イベントの開始者(一部のイベントでは、この属性は空になる場合があります)

- ECID: 実行コンテキストID

Fusion Middleware監査フレームワークは、次の監査レベルをサポートしています。

- なし

- 低

- 中

- カスタム

この項では、各種カテゴリで監査可能なイベントと監査レベルをリストします。表8-4には、イベントのカテゴリと、この章での説明箇所がリストされています。

表8-4 Identity Federationの監査イベントのカテゴリ

カテゴリ

参照先

セッション管理

Identity Federationのセッション管理イベント

プロトコル・フロー

Identity Federationのプロトコル・フロー・イベント

サーバー構成

Identity Federationのサーバー構成イベント

セキュリティ

Identity Federationのセキュリティ・イベント

関連項目:

詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』の「Diagnostics and Auditing」を参照してください。

8.4.1 Identity Federationのセッション管理イベント

本リリースのIdentity Federationのセッション管理イベントには、以前のリリースの監査可能なイベントのサブセットが含まれています。各イベントの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』のセッション管理イベントに関する項を参照してください。

表8-5 Identity Federationのセッション管理イベント

監査可能なイベント

このリリースで監査がサポートされていないイベント

CreateUserSession –

ログイン成功後のセッションの作成

CreateUserFederation –

2つのリモート・サーバー間でのユーザー・フェデレーションの作成

DeleteUserSession –

ログアウト後のセッションの削除

UpdateUserFederation -

2つのリモート・サーバー間でのユーザー・フェデレーションの更新

CreateActiveUserFederation –

ログイン成功後のアクティブ・フェデレーションの作成

DeleteUserFederation –

2つのリモート・サーバー間でのユーザー・フェデレーションの削除

CreateActiveUserFederation –

ログイン成功後のアクティブ・フェデレーションの作成

DeleteActiveUserFederation -

ログアウト後のアクティブ・フェデレーションの削除

LocalAuthentication –

OIFでのユーザーの認証

LocalLogout: Identity Federationでのユーザーのログアウト

8.4.2 Identity Federationのプロトコル・フロー・イベント

本リリースのIdentity Federationのプロトコル・フロー・イベントには、以前のリリースの監査可能なイベントのサブセットが含まれています。各イベントの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』のプロトコル・フロー・イベントに関する項を参照してください。

表8-6 Identity Federationのプロトコル・フロー・イベント

監査可能なイベント

このリリースで監査がサポートされていないイベント

IncomingMessage

Identity Federationが受信したメッセージ

AssertionCreation

Identity Federationによるアサーションの作成(成功した場合のみ)

OutgoingMessage

Identity Federationが送信したメッセージ(成功した場合のみ)

AssertionConsumption

Identity Federationによるアサーションの処理(成功した場合のみ)

8.4.3 Identity Federationのサーバー構成イベント

本リリースのIdentity Federationの監査可能なサーバー構成イベントには、以前のリリースの監査可能なイベントのサブセットが含まれています。各イベントの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』のサーバー構成イベントに関する項を参照してください。

表8-7 Identity Federationのサーバー構成

監査可能なイベント

このリリースで監査がサポートされていないイベント

CreateConfigProperty

新しい構成プロパティの追加(成功した場合のみ)

SetDataStoreType

データ・ストアのタイプの変更(成功した場合のみ)

ChangeConfigProperty

既存の構成プロパティ値の変更(成功した場合のみ)

ChangeDataStore

フェデレーション・データ・ストアの設定(成功した場合のみ)

DeleteConfigProperty

構成プロパティの削除(成功した場合のみ)

CreatePeerProvider

信頼できるプロバイダ・リストへの新しいプロバイダの追加(成功した場合のみ)

UpdatePeerProvider

信頼できるプロバイダ・リストに存在するプロバイダの情報の更新(成功した場合のみ)

DeletePeerProvider

信頼できるプロバイダ・リストからのプロバイダの削除(成功した場合)

LoadMetadata

メタデータのロード(成功した場合のみ)

ChangeFederation

信頼できるプロバイダの変更(成功した場合のみ)

ChangeServerProperty

サーバー構成プロパティの変更(成功した場合のみ)

8.4.4 Identity Federationのセキュリティ・イベント

本リリースのIdentity Federationの監査可能なセキュリティ・イベントには、以前のリリースの監査可能なイベントがすべて含まれています。各イベントの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』のセキュリティ・イベントに関する項を参照してください。

表8-8 Identity Federationのセキュリティ・イベント

監査可能なイベント

このリリースで監査がサポートされていないイベント

CreateSignature

Identity Federationによるデジタル署名の作成

該当なし

VerifySignature

Identity Federationによるデジタル署名の検証

EncryptData

Identity Federationによるデータの暗号化

DecryptData

Identity Federationによるデータの復号化

8.5 監査可能なセキュリティ・トークン・サービス・イベント

セキュリティ・トークン・サービスには、特定のイベント・タイプおよび監査対象イベントを定義する独立した監査構成ファイル(component_events.xml)が用意されています。

この項の内容は次のとおりです。

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

- 監査可能なセキュリティ・トークン・サービス管理イベント

- 監査可能なセキュリティ・トークン・サービス・ランタイム・イベント

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

次のデータは、監査されるイベントまたはイベント・タイプに関係なく、各監査レコードに含まれています。

- イベントの日付と時刻

- イベントを開始するクライアントのIPアドレス

- クライアント・アイデンティティ

- イベントの処理時間

8.5.2 監査可能なセキュリティ・トークン・サービス管理イベント

セキュリティ・トークン・サービス管理イベントは、component_events.xmlに定義されているいくつかの構成管理操作に分類されます。詳細は、表8-9を参照してください。

関連項目:

「Oracle Access Managementの監査の設定」

表8-9 セキュリティ・トークン・サービスの構成管理操作

セキュリティ・トークン・サービスの構成操作

説明

共通属性

- 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

8.5.3 監査可能なセキュリティ・トークン・サービス・ランタイム・イベント

トークン操作のためのセキュリティ・トークン・サービス固有のランタイム・イベントはcomponent_events.xmlに定義されています。詳細は、表8-10を参照してください。

表8-10 セキュリティ・トークン・サービス固有のランタイム・イベント

トークン操作

説明

共通属性

- Requester: RSTの送信によってリクエストしたユーザー

- RelyingParty: トークンが作成されるユーザー

- UserID: エンド・ユーザー・アイデンティティ

- TokenType: SAML11、SAML20、ユーザー名、X.509、Kerberos、OAMまたはカスタム

- Token: トークンのXML値

- TokenContext: トークン操作のために渡されるコンテキスト・データ

- Message: 着信または送信メッセージのXML表現

着信メッセージ

OutgoingMessageで参照されるセキュリティ・トークン・サービスが受信する着信RSTRメッセージ。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- メッセージ

送信メッセージ

IncomingMessageで参照されるセキュリティ・トークン・サービスが受信する送信RSTRメッセージ。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- メッセージ

トークン検証

TokenValidationで参照されるセキュリティ・トークン・サービス内のトークン検証の監査イベント。ステータス属性は、検証操作が成功したかどうかを示します。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Token

- TokenType

- TokenContext

- ステータス

トークン生成

TokenGenerationで参照されるセキュリティ・トークン・サービス内のトークン生成の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- Requester

- RelyingParty

- Token

- TokenType

- TokenContext

- UserID

LDAPユーザー認証

LDAPUserAuthenticationで参照されるLDAPディレクトリでのローカル・ユーザー認証の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- UserID

- ステータス

汎用ランタイム操作

GenericRuntimeOperationで参照されるセキュリティ・トークン・サービスによって実行される汎用操作の監査イベント。

このイベントに対して移入される属性(使用可能な場合):

- OperationType: 操作のタイプ

- OperationData: 操作のコンテキストを表す文字列

8.6 Oracle Access Managementの監査の設定

次の概要には、Oracle Access Managementで監査を実行できるようにするために事前に実行しておかなければならないタスクのリストを示します。

タスクの概要: 監査の構成

1. 「監査データベース・ストアの設定」に示す監査データ・ストアの設定。

2. 「Oracle Business Intelligence Publisher EEの準備」に示す監査レポート発行の設定。

3. 次で説明されているように、Oracle Access Managementコンソールで監査構成を編集します。

- Oracle Access Managementコンソールを使用した監査構成

- 監査設定の追加、表示、または編集

4. 監査が記述されたとおりに機能していることを確認します。「監査とレポートの検証」を参照してください。

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

この項では、監査データベースを作成し、リポジトリ作成ユーティリテ(RCU)を使用してそのスキーマを拡張するために必要なタスクの概要を示します。監査データをデータベースに保存するよう選択した場合、Oracle Access Managementのイベントを監査できるようにするにはこのタスクが必要になります。

関連項目:

- 『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用のJave 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アプリケーション・セキュリティ・ガイド』のバスストップ・ファイルのチューニングに関する項に従い、バスストップ・ファイルのメンテナンスを行います。

8.6.2 Oracle Business Intelligence Publisher EEの準備

Oracle Business Intelligence Publisher Enterprise Edition(EE)をOracle Access Managementの監査レポートとともに使用するには、次の手順に従って準備する必要があります。

関連項目:

- 『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

関連項目:

「監査とレポートの検証」

8.6.3 Oracle Access Managementコンソールを使用した監査構成について

Oracle Access Management内では、特定の「監査構成」設定には「システム構成」の「共通設定」でアクセスできます。データベースに対して監査を行なう時は、これらの設定は必要ありません。図8-2は、「共通設定」ページの「監査構成」セクションを示しています。

図8-2 「共通設定」: 「監査構成」

「図8-2 「共通設定」: 「監査構成」」の説明

「監査中」セクションには、「ログ・ディレクトリ」、「フィルタ設定」、および「監査構成」の「ユーザー」に対する設定が表示されます。

注意:

実際のログ・ディレクトリは、Oracle Access Managementコンソールを使用して構成できません。これは、共通監査フレームワークの監査ローダーのデフォルト・ディレクトリです。このディレクトリの変更は監査ローダーに影響が及ぶため、サポートされません。

「監査構成」ページの要素を表8-11に示します。

表8-11 監査構成要素

要素

説明

最大ディレクトリ・サイズ

監査出力ファイルが格納されるディレクトリの最大サイズ(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ファイル内に指定されています。Oracle Access Managementでは、このファイルの編集やカスタマイズはサポートされていません。指定されたフィルタ・プリセットに監査対象として構成された項目だけが監査可能です。

ユーザー

フィルタが有効になった時だけアクションが含められるユーザーのリストを指定します。特別なユーザーのアクションは、フィルタ・プリセットに関わらずすべて監査されます。管理者は、この表の特別なユーザーを追加、削除、または編集することができます。

8.6.4 監査設定の追加、表示、または編集

管理者は、「OAMサーバー共通プロパティ」ページの「監査構成」タブでフィルタ・プリセットを選択することによって、記録される情報の量とタイプを制御します。各フィルタ・プリセットの監査可能イベントは、読取専用のcomponent_events.xmlファイル内に指定されています。このファイルをカスタマイズしたり編集したりすることはできません。

次の手順では、OAMサーバー共通監査構成の設定を追加、表示または編集する方法を示します。Fusion Middleware Controlを使用して個々の管理ポリシーを構成することはできません。Oracle Access Managementは、監査構成でJPSインフラストラクチャを使用しません。監査用のWebLogic Scripting Tool (WLST)コマンドはありません。

Oracle Access Managementコンソールで監査構成を表示または編集する方法

1. Oracle Access Managementコンソールの「システム構成」タブから、「共通構成」セクションを展開し、ナビゲーション・ツリーの「共通設定」をダブルクリックします。

2. 「監査構成」セクションで、使用環境の詳細を正しく入力します(表8-11)。

- 最大ログ・ディレクトリ・サイズ

- 最大ログ・ファイル・サイズ

- フィルタ有効

- フィルタ・プリセット(監査データの冗長性を定義)

- 監査から特定のユーザーを含めるための「ユーザー」。「ユーザー」表の上の「追加」(+)ボタンをクリックしてフィールドに値を入力します。

3. 「適用」をクリックして「監査構成」を送信します(または変更を適用しないでページを閉じます)。

4. AdminServerおよびOAMサーバーを、変更が適用された後で再起動します。

8.7 監査とレポートの検証

以下の手順を使用して、ランタイム・イベントの監査構成をテストすることができます。

前提条件

- 「Oracle Access Managementの監査の設定」の説明に従って、監査パラメータを設定します。

- エージェントとサーバーが稼動していることを確認します。

- 「Oracle Business Intelligence Publisher EEの準備」の説明に従い、BI EE Publisherを準備します。

監査構成を検証する方法

1. 認証ベント: ここで説明するようにコンソールのログインの成功/失敗を監査するか、表8-2「Access Manager管理監査イベント」の説明に従って管理イベントを監査します。

1. Oracle Access Managementコンソールからサインアウトします。

2. 無効なユーザー(管理者以外)の資格証明を使用して、Oracle Access Managementコンソールにサインインします。

3. 適切な管理者の資格証明を使用して、Oracle Access Managementコンソールにサインインします。

4. ログ・ファイルの確認: 監査ログ・ファイルを開き、最新の管理イベント・エントリを検索します。

$DOMAIN_HOME/servers/$ADMINSERVER_NAME/logs/auditlogs/OAM/audit.log

5. データベース・ログの確認:

1. 「監査データベース・ストアの設定」に示されたタスクを実行します。

2. 手順1の説明に従って、認証イベントを生成します。

3. データベースに接続し、データベースに接続してIAU_BASEテーブルの監査イベントを確認します。

2. ランタイム・イベント: ここで説明するように認証の成功/失敗を監査するか、表8-3「Access Managerランタイム監査イベント」の説明に従ってランタイム・イベントを監査します。

1. ブラウザ・ウィンドウで、自分には権限のない保護されているリソースへのURLを入力します。

2. ログ・ファイルの確認: 監査ログ・ファイルを開き、最新の管理イベント・エントリを検索します。

$$DOMAIN_HOME/servers/$ADMINSERVER_NAME/logs/auditlogs/OAM/audit.log

3. データベース・ログの確認:

1. 「監査データベース・ストアの設定」に示されたタスクを実行します。

2. 手順1の説明に従って、認証イベントを生成します。

3. データベースに接続し、データベースに接続してIAU_BASEテーブルの監査イベントを確認します。

3. 監査構成の変更: 「監査設定の追加、表示、または編集」も参照してください。

1. Oracle Access Managementコンソールの「システム構成」タブから、「共通構成」を展開し、「最大ディレクトリ・サイズ」(MB)と「最大ファイル・サイズ」(MB)のパラメータを変更します。

2. この手順を繰り返し、監査が機能していることを確認します。

4. レポートの表示:

1. Oracle BI EEにサインインします。例:
http://host:port/xmlpserver

ここで、hostはコンピュータをホストするOracle BI Publisher、portはBI Publisherのリスニング・ポート、xmlpserverはBI Publisherのログイン・ページです。

2. Oracle BI Publisher Enterpriseで、希望するレポートを探します。例:
下に示すように、「共有フォルダ」→「Oracle_Fusion_Middleware_Audit」→「Component_Specific」→「Oracle Access Manager」をクリックして希望のレポートを選択します。

3. 必要に応じて分析を行なうか、監査構成の編集を行います。

/Middleware_home/user_projects/domains/base_domain/servers/oam_server1/logs/
auditlogs/OAM/

5. 自社のポリシーに従って監査ログのアーカイブと管理を行ないます。

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

パフォーマンスの監視(モニタリング)とは、特定のコンポーネントの状態を把握するためにパフォーマンス・メトリックを監視(表示)することを指しています。パフォーマンス・メトリックを表示する方法はいくつもありますが、この章では、Oracle Access Managementコンソールの使用に重点を置く次のトピックについて説明します。

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

- DMSメトリック表の確認

- Oracle Access Managementコンソールを使用したサーバー・メトリックの監視

- Oracle Access Managementコンソールを使用したSSOエージェント・メトリックの監視

- OAMプロキシ・メトリックとチューニングの概要

- DMSコンソールによるOpenSSOメトリックの確認

関連項目:

- 第10章(Oracle Enterprise Manager Fusion Middleware Controlを使用する場合)

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

コンポーネント・パフォーマンス・メトリックは、特定のイベントを完了する間に、メモリー内で収集できます。特定のエリアで使用された時間をモニターしたり、特定の発生や状態の変更を追跡できます。

Oracle Access Managementは、Oracle Dynamic Monitoring Systems (DMS)を使用し、OAMサーバーおよび登録されたエージェントについてアプリケーション固有のパフォーマンス情報を測定します。

メトリック収集は、コンポーネントが特定のイベントについてメモリに情報を収集するためのメカニズムです。これらのイベントに基づいて、特定の領域内で経過した時間をモニターしたり、特定の発生事象や状態変化を追跡したりすることができます。これらのメトリックはメモリ内にのみ保存されますが、たとえばEM、dmsSpy、dmsDumpなど、これらを取り出して表示するためのメカニズムもいくつかあります。

dmsSpyは、WebLogicアプリケーション・サーバーの一部であるFusion Middlewareツールです。dmsSpyは、WebLogicアプリケーション・サーバー・インスタンスに固有なDMSロー・データを表示します。表示される情報は名詞タイプによって分類され(Oracle Access ManagementではOAMS.OAM_ prefix)、Weblogicアプリケーション・サーバー・インスタンスで実行中のすべてのDMSインストゥルメント・アプリケーションに関するメトリックが含まれます。Weblogicインスタンスのメトリックを参照するには、http://hostname:port/dms/にアクセスしてください。次に例を示します。

http://samplehost:7001/dms/

関連項目:

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のDMSによるアプリケーションのインストゥルメントの詳細

管理者は、「システム構成」タブで「アクション」メニューの「モニタリング」コマンドを使用して、Access Managerのパフォーマンスを監視できます。

9.2 DMSメトリック表の確認

DMSコンソールにアクセスする方法

1. ブラウザ・ウィンドウで、次のURLを使用してDMSコンソールに移動します。

http:// <example_AdminServer:Port/dms/

2. Oracle Access Management管理者の資格情報を使用してログインします。

3. DMSメトリック表で、表示されている必要なメトリックをクリックして、コンソールの右側に結果を表示します。

9.3 Oracle Access Managementコンソールを使用したサーバー・メトリックの監視

ここでは、次の内容について説明します。

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

- Oracle Access Managementコンソールを使用したサーバー・メトリックの確認

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

有効なOracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、Oracle Access Managementコンソールを使用した様々なパフォーマンス・メトリックを表示できます。

前提条件

OAMサーバーが稼動している必要があります。

Oracle Access Managementコンソールを使用してパフォーマンスを監視する方法

1. Oracle Access Managementコンソールで、「システム構成」タブに移動します。

2. サーバー・インスタンス:

1. 次の順に開きます。
「共通構成」セクション
「サーバー・インスタンス」ノード
DesiredServer

2. ナビゲーション・ツリーの「アクション」メニューで、「モニター・メニュー」をクリックします。

3. 「モニター」ページで、必要なサブタブをクリックして、サーバー・インスタンスの結果を表示します。
サーバー・プロセス概要
セッション操作
サーバー操作
OAMエージェント

4. 「Oracle Access Managementコンソールを使用したサーバー・メトリックの確認」に進みます。

3. 「OAMプロキシ・メトリックとチューニングの概要」も参照してください。

9.3.2 Oracle Access Managementコンソールを使用したサーバー・メトリックの確認

このトピックでは、ナビゲーション・ツリーでサーバー・インスタンスが選択されており、「システム構成」タブで「アクション」メニューの「モニタリング」メニュー・コマンドを選択すると表示されるサーバー・メトリックについて説明します。

図9-1は、サーバー・プロセスのページを示しています。

図9-1 「サーバー・プロセス概要」ページ

「図9-1 「サーバー・プロセス概要」ページ」の説明

「サーバー・プロセス概要」タブでは、次のOAMサーバー・イベントが各列に個別に整理されて表示されます。

表9-1 OAMサーバー・メトリック: 「サーバー・プロセス概要」タブ

サーバー・メトリックの列

認可プロセス

認可リクエスト

認可プロセス失敗

認可プロセス成功

認証前プロセス失敗

認証前プロセス成功

図9-2は、個々の列のすべてのイベント・メトリックを表示するために表をデタッチした後の「セッション操作」の「モニター」タブを示しています。

図9-2 OAMサーバー・メトリック: 「セッション操作」の「モニター」ページ

「図9-2 OAMサーバー・メトリック: 「セッション操作」の「モニター」ページ」の説明

OAMサーバーの「セッション操作」のメトリックには、次のものが含まれます。

図9-2 OAMサーバー・メトリック: 「セッション操作」

セッション操作

セッション検証チェック

セッション検証チェック失敗

セッション検証チェック成功

セッション作成

セッション作成失敗

セッション作成成功

セッション破棄

セッション破棄失敗

セッション破棄成功

クライアント・セッション削除

クライアント・セッション削除失敗

図9-3は、デタッチされたOAMの「サーバー操作」の「モニター」ページを示しています。

図9-3 OAMサーバー・メトリック: 「サーバー操作」タブ

「図9-3 OAMサーバー・メトリック: 「サーバー操作」タブ」の説明

OAMの「サーバー操作」のメトリックには、表9-3に示すものが含まれます。

表9-3 OAMサーバー・メトリック: 「サーバー操作」タブ

OAMサーバー: 操作のメトリック

認証ポリシー・レスポンス失敗

認証ポリシー・レスポンス成功

認証スキーム・レスポンス失敗

認証スキーム・レスポンス成功

認証の失敗

認証失敗レスポンス

認証ポリシー・レスポンス

認証リクエスト

認証スキーム・レスポンス

認証の失敗

認証の失敗

認可プロセスの失敗

認可プロセスの成功

図9-4は、使用可能なメトリックがすべて表示されているOAMサーバー・メトリック: 「OAMエージェント」タブを示しています。

図9-4 OAMサーバー・メトリック: 「OAMエージェント」タブ

「図9-4 OAMサーバー・メトリック: 「OAMエージェント」タブ」の説明

「OAMエージェント」のパフォーマンス・メトリックには、次のものが含まれます。

- エージェント名

- エージェント・ステータス

- バージョン

9.4 Oracle Access Managementコンソールを使用したSSOエージェント・メトリックの監視

この項では、様々なコンポーネントのメトリックの確認方法と、チューニングが必要かどうかの判断方法を説明します。内容は次のとおりです。

- Oracle Access Managementコンソールを使用したエージェント・メトリックの監視

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

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

9.4.1 Oracle Access Managementコンソールを使用したエージェント・メトリックの監視

有効なOracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、Oracle Access Managementコンソールを使用した様々なSSOエージェント・パフォーマンス・メトリックを表示できます。

前提条件

サーバーおよびエージェントが稼動している必要があります。

Oracle Access Managementコンソールを使用してSSOエージェント・パフォーマンスを監視する方法

1. Oracle Access Managementコンソールの「システム構成」タブで、次の順に開きます。
「システム構成」タブ
「Access Manager」セクション
「SSOエージェント」ノード

2. 必要なエージェント・タイプのノードを開きます。

- OAMエージェント

- OSSOエージェント

- OpenSSOエージェント: エージェント・リクエストに対するOpenSSOプロキシの動作以外に、このエージェントをモニターする方法はありません。「DMSコンソールによるOpenSSOメトリックの確認」を参照してください。

3. 通常どおり、監視する必要のあるエージェントを検索します。

4. 「検索結果」表で、必要なエージェントの「シリアル番号」をハイライト表示して、「アクション」メニューから「モニター」を選択します。

5. 必要に応じて先に進みます。

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

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

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

表9-3に示すように、OAMエージェント・メトリックは次のタブにまたがって編成されています。

- 接続性

- 操作の概要

- 操作の詳細

- 情報

関連項目:

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

図9-5 OAMエージェント・メトリック: モニタリング特性

「図9-5 OAMエージェント・メトリック: モニタリング特性」の説明

次の図は、1つのOAMエージェントに対するデタッチされた表を示しており、それぞれについて可能なメトリックがすべて表示されています。

- 図9-6「OAMエージェント・メトリック: デタッチされた接続性の表」

- 図9-7「OAMエージェント・メトリック: デタッチされた操作の概要表」

- 図9-8「OAMエージェント・メトリック: デタッチされた操作の詳細表」

- 図9-9「OAMエージェント・メトリック: デタッチされた情報の表」

図9-6 OAMエージェント・メトリック: デタッチされた接続性の表

「図9-6 OAMエージェント・メトリック: デタッチされた接続性の表」の説明

図9-7 OAMエージェント・メトリック: デタッチされた操作の概要表

「図9-7 OAMエージェント・メトリック: デタッチされた操作の概要表」の説明

図9-8 OAMエージェント・メトリック: デタッチされた操作の詳細表

「図9-8 OAMエージェント・メトリック: デタッチされた操作の詳細表」の説明

図9-9 OAMエージェント・メトリック: デタッチされた情報の表

「図9-9 OAMエージェント・メトリック: デタッチされた情報の表」の説明

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

OSSOエージェントの「検索結果」表でOSSOエージェントが選択されており、表の「アクション」メニューで「モニター」を選択すると、次のメトリック・ページが使用可能になります。

- 図9-10「OSSOエージェントの「モニター」ページの「操作の詳細」」

- 図9-11「OSSOエージェント・モニタリング・プロセスの概要表」

- 図9-12「OSSOエージェント情報の表」

図9-10 OSSOエージェントの「モニター」ページの「操作の詳細」

「図9-10 OSSOエージェントの「モニター」ページの「操作の詳細」」の説明

図9-11は、デタッチされたOSSO 10gエージェント・モニタリング・プロセスの概要表を示します。

図9-11 OSSOエージェント・モニタリング・プロセスの概要表

「図9-11 OSSOエージェント・モニタリング・プロセスの概要表」の説明

図9-12は、デタッチされたOSSOエージェント情報表を示しています。

図9-12 OSSOエージェント情報の表

「図9-12 OSSOエージェント情報の表」の説明

9.5 OAMプロキシ・メトリックとチューニングの概要

ここでは、次の内容について説明します。

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

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

関連項目:

- OpenSSOプロキシ・イベントとメトリック: サーバー

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

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

スループットとは、1秒間に処理されるリクエスト数を言います。待機時間とは、特定のリクエストを処理するために必要な時間を言います。WebgateとOAMサーバーの間にプロキシを導入することによる待機時間の増加は20%未満です。

表9-4は、使用できる様々なOAMプロキシ・メトリックを示しています。

表9-4 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

セキュリティ・モード・ネゴシエーションを実行中のアクティブ・スレッド数

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

OAMプロキシのパフォーマンスは、Jave EEコンテナ管理コンソールを通じてその構成を変更することによってチューニングすることができます。

注意:

Java EEコンテナ管理者とOracle Access管理者はどちらも、Java EEコンテナ管理コンソール(このドキュメントでは取り上げません)を使用してパフォーマンスをチューニングできます。

OAMプロキシのチューニング・パラメータを表9-5に示します。

表9-5 OAMプロキシのチューニング・パラメータ

目的

パラメータ

タイプ

値

説明

サービス拒否攻撃

ConnectionValidationInterval

整数

120

サービス拒否攻撃に関して定期的に接続の検証を行なう際の時間間隔(秒)

BacklogQueue

整数

50

バックログ・キューの最大長さ

MaxNAPHandShakeTime

整数

100

クライアント同士がNAPシェイクハンドを完了させるまでに使用できる最大時間(ミリ秒)。ある接続を介したNAPシェイクハンドがこの時間内に完了しなかった場合、その接続は悪意あるものとしてマークされます。

9.6 DMSコンソールによるOpenSSOメトリックの確認

この項の内容は次のとおりです。

- OpenSSOプロキシ・イベントとメトリック: サーバー

- OpenSSOプロキシ・メトリック: エージェント

- DMSコンソールを使用したOpenSSOメトリックの確認

9.6.1 OpenSSOプロキシ・イベントとメトリック: サーバー

スループットとは、1秒間に処理されるリクエスト数を言います。待機時間とは、特定のリクエストを処理するために必要な時間を言います。監視可能なイベントについては、表9-6を参照してください。

表9-6 OpenSSOプロキシ・サーバー・イベント

イベント

説明

ネーミング・サービスのリクエスト

ネーミングのルックアップに対するリクエスト。OpenSSOプロキシによるこのリクエストの処理にかかるレスポンス時間を監視できます。

エージェント認証プロセス

エージェント認証は次の2つのフェーズで取得されています。

- AgentAuthentication_LoginおよびAgentAuthentication_SubmitRequirementsフェーズ。2つ目のフェーズは、認証のためにOpenSSOエージェントから資格情報が送信された後のフェーズを指します。

- 2つ目のフェーズは、認証のためにOpenSSOエージェントから資格情報が送信された後のフェーズを指します。

エージェント・セッション検証

エージェント・セッション検証

ユーザー認証

このイベントはクライアントSDKに対してのみ取得されます。この診断イベントを通して、クライアントSDKの認証にかかるレスポンス時間を監視できます。

ユーザー・セッション認証

ユーザー・セッションの認証にかかる時間

ユーザー認可

特定のリソース用に構成されたポリシーによる認証にかかる時間

表9-7は、名前付きサーバーに対して使用できる様々なOpenSSOプロキシ・メトリックを示しています。

表9-7 OpenSSOプロキシ・メトリック: サーバー

メトリック

説明

AgentAuthentication_Login

ログイン・フェーズ中に認証のためにエージェントから送信された認証リクエストに対するレスポンス時間の詳細

AgentAuthentication_LoginFailures

ログイン・フェーズ中のエージェント認証リクエストの失敗数

AgentAuthentication_SubmitRequirements

要求の送信フェーズ中に認証のためにエージェントから送信された認証リクエストに対するレスポンス時間の詳細

AgentAuthentication_SubmitRequirementsFailures

送信要求フェーズ中のエージェント認証リクエストの失敗数

NamingServiceRequest

ネーミング・サービス・リクエスト操作に対するレスポンス時間の詳細

NamingServiceRequestFailures

ネーミング・サービス・リクエスト操作の失敗数

UserAuthentication_SDK

ユーザー認証リクエストに対するレスポンス時間の詳細

UserAuthentication_SDKFailures

ユーザー認証リクエストの失敗数

UserAuthorization

ユーザー認可操作に対するレスポンス時間の詳細

UserAuthorizationFailures

ユーザー認可操作の失敗数

ValidateAgentSession

エージェント・セッションの検証操作に対するレスポンス時間の詳細

ValidateAgentSessionFailures

エージェント・セッションの検証操作の失敗数

ValidateUserSession

ユーザー・セッションの検証操作に対するレスポンス時間の詳細

ValidateUserSessionFailures

ユーザー・セッションの検証操作の失敗数

9.6.2 OpenSSOプロキシ・メトリック: エージェント

表2は、各OpenSSOエージェントに対して使用できる様々なOpenSSOプロキシ・メトリックを示しています。

表9-8 OpenSSOプロキシ・メトリック: エージェント

メトリック

説明

AgentAuthentication_SubmitRequirements

エージェントごとに収集された送信要求フェーズ中の認証リクエストに対するレスポンス時間の詳細

AgentCacheMode

クライアント・ポリシー評価者のキャッシュ・モードを指定します。値は、subtreeまたはselfのいずれかです。

AgentFilterMode

保護されたWebアプリケーションに対してエージェントがリクエストをフィルタする方法を指定します。デフォルトではグローバル値が機能し、保護されたアプリケーションで独自のフィルタ設定を持たないものに適用されます。

AgentHostName

OpenSSOエージェントのホスト名

AgentIPAddress

OpenSSOエージェントのIPアドレス

AgentMappingMode

ユーザーIDの決定に使用されるメカニズムを指定します。

AgentState

OpenSSOエージェントの状態: 有効または無効。

UserAttributeName

ユーザーIDを格納するユーザー・ストア属性を指定します。

UserAuthorization

エージェントごとに収集されたユーザー認可操作に対するレスポンス時間の詳細

UserIdentity

認証ユーザーのIDに対するセッション・プロパティ名を指定します。デフォルトは「UserToken」です。

ValidateAgentSession

エージェントごとに収集されたエージェント・セッションの検証操作に対するレスポンス時間の詳細

agentType

OpenSSOエージェントのタイプ: J2EEまたはWebエージェント。

9.6.3 DMSコンソールを使用したOpenSSOメトリックの確認

有効なOracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、DMSコンソールでOpenSSOプロキシ・メトリックを表示できます。

前提条件

OAMサーバーが稼動している必要があります。

DMSコンソールにアクセスする方法

1. ブラウザ・ウィンドウで、次のURLを使用してDMSコンソールに移動します。

http:// <example_AdminServer:Port/dms/

2. Oracle Access Management管理者の資格情報を使用してログインします。

3. OpenSSOエージェント・メトリック: DMSメトリック表で、OAMS.OAM_Server.OPENSSO_Agentsをクリックします。

4. OpenSSOプロキシ・メトリック: DMSメトリック表で、OAMS.OAM_OpenSSOProxyをクリックして、コンソールの右側に結果を表示します。

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

ライブで動的なパフォーマンス・メトリックは、Fusion Middleware Controlで参照できます。この章では、Oracle Fusion Middleware Controlを使用してAccess Managerおよびセキュリティ・トークン・サービスのパフォーマンスおよびログ・メッセージを監視する方法を説明します。この章では、管理者がFusion Middleware Controlから実行できる一般的なタスクを中心に説明しており、ここに示す内容は、『Oracle Fusion Middleware管理者ガイド』の詳細に代わるものではありません。

注意:

特に明記しないかぎり、この章の情報は両方のサービスに対して同じものです。Identity FederationまたはMobile and Social用のOracle Fusion Middleware Controlにはメトリックがありません。

この章の内容は次のとおりです。

- 前提条件

- Fusion Middleware Controlの概要

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

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

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

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

- Fusion Middleware ControlでのMBeanの表示

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

10.1 前提条件

Oracle Fusion Middleware Controlは、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの説明に従い、WebLogic管理サーバー上のOracle Access Managementを使用してデプロイする必要があります。

10.2 Fusion Middleware Controlの概要

Fusion Middleware Control内では、情報はAccess Manager、セキュリティ・トークン・サービス、および他の製品のライブ・セッション中に動的に更新されます。

Fusion Middleware Controlは、様々なパフォーマンス・データと管理機能を個別にWebベースのページにまとめます。これにより、管理者は重要なモニタリング・データや最も一般的に使用される管理機能をWebブラウザから容易に見つけることができます。

注意:

Enterprise Manager Grid Controlは別途ライセンスされる製品で、Fusion Middleware Controlにはない追加的機能(主に、履歴確認や傾向分析のためのデータを収集して保存する機能)を備えています。

Oracle Access Management 11gは、WebLogicコンテナを使用するJava EEアプリケーションとしてデプロイされます。高可用性とフェイルオーバーを実現するために、Oracle Access Managementは普通、WebLogicのクラスタ環境でデプロイされます。

WebLogic Serverドメインは複数のクラスタを持つことができます。クラスタ化されたすべてのコンポーネントのモニタリング統計とパフォーマンス統計を得るには、コンポジット・ターゲットが必要です。このターゲットは、メンバー・インスタンスのステータス、および合計ロード・パフォーマンス・メトリックとレスポンス・パフォーマンス・メトリックを提供します。Access Managerおよびセキュリティ・トークン・サービスに公開されるメトリックに加えて、Java EEアプリケーションやコンポジットJava EEアプリケーションでも一般的なパフォーマンス・メトリックを使用できます。

Fusion Middleware Controlは、図10-1に示すようにWebLogic管理サーバー上のOracle Access Managementを使用してデプロイする必要があります。

図10-1 Fusion Middleware Control (AS-Control)のデプロイメント・アーキテクチャ

「図10-1 Fusion Middleware Control (AS-Control)のデプロイメント・アーキテクチャ」の説明

ターゲットに対するFusion Middleware Controlの使用は、Oracle Access Management内のOracle Dynamic Monitoring Systemsインストゥルメンテーションを通じてサポートされています。このインストゥルメンテーションは以下を提供するために使われます。

- パフォーマンスの概要とドリルダウン

- ログ・メッセージの検索と動的なログ・レベルの変更

- ルーティング・トポロジの概要

- MBeanブラウザ

- Access Manager with Security Token Service用のコンポーネント・レベルおよびクラスタ・レベルのメトリック

10.3 Fusion Middleware Controlのログインおよびログアウト

この項の内容は次のとおりです。

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

- Fusion Middleware Controlへのログイン

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

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

Fusion Middleware Controlのログイン・ページには、ユーザー名とパスワードを入力するためのフィールドがあります。Fusion Middleware Controlのログイン・ページの下部には複数のトピックが表示されており、クリックすると追加的な情報が表示されます。

10.3.2 Fusion Middleware Controlへのログイン

このタスクを実行できるのはFusion Middleware Controlの管理者に限られます。

関連項目:

Fusion Middleware Controlの基礎的な使用方法については『Oracle Fusion Middleware管理者ガイド』

Fusion Middleware Controlへのログイン方法

1. ブラウザ・ウィンドウで、Fusion Middleware ControlのURLを入力します。例:

http://host.example.com:8888/em/

2. 操作性の拡張や新機能についての情報を得るには、ログイン・ページの下側にあるトピックを開いて内容を表示します。

3. Fusion Middleware Control管理者としてログインします。

4. Oracle Access Managementを含んだファームを、必要に応じて選択します。

5. ヘルプ: OAM「ファーム」ページのファーム・リソース・センターで希望のトピックを選択すると(あるいはページの右上にある「ヘルプ」をクリックすると)、より詳しい説明が表示されます。

6. 表示や構成の詳細については、この章の該当トピックを参照してください。

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

Fusion Middleware Controlからのサインアウトは以下に示す手順で行なうことができます。

Fusion Middleware Controlからのログアウト方法

1. Fusion Middleware Controlの右上隅にある「ログアウト」リンクをクリックします。

2. ブラウザ・ウィンドウを閉じます。

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

この項では、Access Managerおよびセキュリティ・トークン・サービスに関する次のトピックについて説明します。

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

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

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

関連項目:

Fusion Middleware Controlの基礎的な使用方法については『Oracle Fusion Middleware管理者ガイド』

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

Fusion Middleware ControlのOAM「ファーム」ページを図10-2に示します。それぞれの「ファーム」ページには同様の情報が含まれています。ファーム・リソース・センターを使用すれば、直ちにオンライン情報にアクセスすることができます。

図10-2 Fusion Middleware ControlのOAM「ファーム」ページ

「図10-2 Fusion Middleware ControlのOAM「ファーム」ページ」の説明

「ファーム」ページの各セクションについては表10-1に示します。

表10-1 「ファーム」ページのセクション

「ファーム」ページのセクション

説明

デプロイメント

ファーム内のこのセクションには、アプリケーション・デプロイメントのそれぞれの内部アプリケーションのステータスとターゲットが表示されます。

「デプロイメント」セクション内(またはナビゲーション・ツリー内)のリンクをクリックすると、詳細を示すページが表示されます。

Fusion Middleware

ファーム内のこのセクションには、以下におけるサーバー・インスタンスのステータス、ホスト、およびCPU使用状況が表示されます。

- WebLogic Serverドメイン

- アイデンティティとアクセス

ページ上(またはナビゲーション・ツリー内)のリンクをクリックすると、より詳しいサマリーを含むページが表示されます。

ファーム・リソース・センター

以下のカテゴリの大量のオンライン情報が含まれています。

- Fusion Middleware Controlの使用を開始する上で有効な情報

- Fusion Middleware Controlを使用する管理者タスク

- その他のリソース

リソース・センターのリソース内にあるリンクをクリックすると、選択した項目に関する情報が表示されます。オンラインで得られる情報は量が多いので、ここではこれらの詳細については繰り返すことはしません。

図10-3に示すようなページの左側にあるナビゲーション・ツリーを使用することにより、現在表示しているページに関係なく、操作対象となる特定のインスタンス(ターゲット)を選ぶことができます。実際に使用している環境で表示されるターゲット名は、ここに示すものとは異なります。

図10-3 Fusion Middleware Controlのファーム・ナビゲーション・ツリー

「図10-3 Fusion Middleware Controlのファーム・ナビゲーション・ツリー」の説明

詳細については「Fusion Middleware Controlへのログイン」を参照してください。

関連項目:

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

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

Oracle Access Managementの場合、Fusion Middleware Controlのファームの詳細は、ナビゲーション・ツリー内の次のノードに分割されます。

- アプリケーション・デプロイメント

- 内部アプリケーション(ログアウト・ページと、OAM AdminServerインスタンスおよびOAM Serverインスタンスのその他の詳細を含む)

- WebLogic Serverドメイン(OAMファームを含むWebLogic Serverの詳細)

- Identity and Access(OAMクラスタ・インスタンスまたは個々のOAMサーバー・インスタンスを含む)

ナビゲーション・ツリーのノードをクリックすると、図10-4(アプリケーション・デプロイメントをクリックした場合)に示すように、個々のリンクと、ターゲット、タイプ、およびフルネームが記述された情報ページが表示されます。

図10-4 Fusion Middleware Controlの「ノード情報」ページ

「図10-4 Fusion Middleware Controlのノード情報ページ」の説明

(ナビゲーション・ツリー上またはページ上で)インスタンス(ターゲット)名をクリックすると、コンテキスト・メニューと詳細サマリー・ページが表示されます。ナビゲーション・ツリー内の「内部アプリケーション」ターゲットはハイライト表示され、右側に同じ名前のページが表示されます。ページ最上部のターゲット名の下にはコンテキスト・メニューが、図10-5のように表示されます。

図10-5 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー

「図10-5 選択した内部アプリケーションのアプリケーション・デプロイメント・サマリー」の説明

「アプリケーション・デプロイメント」メニューを図10-6に示します。

図10-6 「アプリケーション・デプロイメント」メニュー

「図10-6 「アプリケーション・デプロイメント」メニュー」の説明

WebLogic Serverドメイン: 対応するメニューが開いた状態のWebLogic Serverドメイン・ページを図10-7に示します。左下隅には、オンライン・ドキュメントへのリンクが表示されたOracle WebLogic Serverドメインのリソース・センターがあります。このページは、ファーム・ランディング・ページによく似ています。

図10-7 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー

「図10-7 コンテキスト・メニューを開いた状態のWebLogic Serverドメイン・サマリー」の説明

WebLogic Serverのドメイン・ノード内でターゲット名を選択すると、ターゲット・サマリー・ページが表示されます。このページは、図10-5に示すアプリケーション・デプロイメントページによく似ています。

詳細については、Fusion Middleware Controlでのコンテキスト・メニューとターゲット詳細の表示を参照してください。

関連項目:

「Identity and Access」ノードとその関連ページについては「Fusion Middleware Controlでのパフォーマンスの表示」。

10.4.3 Fusion Middleware Controlのコンテキスト・メニューおよびターゲット詳細の表示

Fusion Middleware Controlの管理者は、次の手順を使用してコンテキスト・メニューとターゲット・ページを表示することができます。

注意:

OAMファームページのファーム・リソース・センターで希望のトピックを選択すると(あるいはページの右上にある「ヘルプ」をクリックすると)、より詳しい説明が表示されます。

関連項目:

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

コンテキスト・メニューとターゲット情報の表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. Oracle Access Managementを含んだファームを、必要に応じて展開します。

3. 情報ページ: ナビゲーション・ツリーで以下のいずれかをクリックすると、関連する情報ページが表示されます。

- アプリケーション・デプロイメント

- WebLogic Serverドメイン

- アイデンティティとアクセス

4. メニューとサマリー・ページ: (ナビゲーション・ツリーまたは関連ページで)インスタンス名をクリックすると、サマリー・ページとメニューが表示されます(図10-5と図10-6)。

5. クラスタ・ページまたはサーバー・ページ: 「Fusion Middleware Controlでのパフォーマンスの表示」.を参照。

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

Fusion Middleware Controlは管理者に次の情報を提供します。

- Access Managerとセキュリティ・トークン・サービスのパフォーマンスのクラスタ全体表示

- 重要パフォーマンス・メトリックのサーバーごとのドリルダウン

- パフォーマンス・メトリックを迅速に追加または削除する能力

Fusion Middleware Controlを使用すれば、ライブ・セッションのパフォーマンス・メトリックを様々な書式で表示できます。選択されたノードとターゲット・インスタンスに対するページの概要を表10-2に示します。

表10-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

可

可

可

不可

不可

不可

不可

可

可

アイデンティティとアクセス

OAM (クラスタ)

oam_server (サーバー)

不可

不可

可

可

可

可

注意:

セキュリティ・トークン・サービスのパフォーマンスは、関連するOAMクラスタおよびサーバーのページとともに含まれます。

この項の内容は次のとおりです。

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

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

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

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

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

Fusion Middleware Controlの「パフォーマンス概要」は、個々のクラスタやサーバー・ターゲットの特定のパフォーマンス・メトリックに至るまでのWebLogicクラスタ情報を反映するために使用できます。

「クラスタ」ページ: Identity and Accessの最上位ノードを選択すると、「パフォーマンス概要」を含むOAMクラスタのデプロイメントのページが表示されます。図10-8では、「クラスタ」がナビゲーション・ツリーのIdentity and Accessノードの下で選択されています。図10-8は、「クラスタ」の「デプロイメント」セクションと「パフォーマンス概要」セクションを示します。このページには、トークン発行とトークン検証の表が含まれます。

図10-8 「クラスタ」ページ

「図10-8 「クラスタ」ページ」の説明

OAMサーバー・ページ: OAMサーバー・ターゲット名をナビゲーション・ツリー(または開いているページ)で選択すると、ターゲットの「パフォーマンス概要」が表示されます。OAMサーバー・ページの最上部で、サーバー・インスタンスの「主要なメトリック」のサマリーが「クラスタ」の「デプロイ」セクションのかわりに表示されます。図10-9は、OAM Serverインスタンスの「主要なメトリック」を示しており、「トークン発行/秒」と「トークン検証/秒」を含みます。「トークン検証」の成功率が含まれます。

図10-9 サーバー・ページの「主要なメトリック」

「図10-9 サーバー・ページの「主要なメトリック」」の説明

Fusion Middleware ControlのクラスタおよびOAMサーバー・インスタンスのパフォーマンス概要の要素を表10-3に示します。違いはわずかです。

表10-3 Fusion Middleware Controlの「パフォーマンス概要」のサマリー

セクションまたは列名

説明

「クラスタ」メニュー

動的コンテキスト・メニューには、選択したターゲットに関係する機能が含まれています(ナビゲーション・ツリーでターゲットを右クリックしても表示されます)。このメニューは、選択したクラスタで使用できます。

「コンポーネント・パフォーマンス」コマンドを使用すると、「Access Manager」メトリックを表示するか、「セキュリティ・トークン・サービス」メトリックを表示するかを選択できます。

関連項目: 「Access Managerコンポーネント・ページ」および「セキュリティ・トークン・サービス・コンポーネント・ページ」。

「デプロイメント」、「Oracle Access Managerクラスタ」ページ

このセクションは、「Oracle Access Managerクラスタ」ページのみで表示されます。クラスタ内の各インスタンスのステータスについて説明します。次の情報が含まれています。

- インスタンス名

- ステータス

- 認証

- 認可

インスタンス名

この列には、クラスタ内の各OAMサーバー・インスタンスの名前が含まれます。例:

OAM_server_name

ステータス

この列は、クラスタ内の各OAMサーバー・インスタンスのステータスを、次のいずれかで示します。

- 緑色の上向き矢印(実行中)

- 赤の下向き矢印(停止中)

認証

「認証」列が示す内容:

- 認証/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認証数

- 成功率(成功した認証の割合): クラスタ内の各OAMサーバー・インスタンスの認証成功の割合を表す数値

認可

この列は、クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数を示します。

「認可」列が示す内容:

- 認可/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数

- 成功率(成功した認可の割合): クラスタ内の各OAMサーバー・インスタンスの認可成功の割合を表す数値

サーバー・インスタンスメニュー

動的コンテキスト・メニューには、選択したターゲットに関係する機能が含まれています(ナビゲーション・ツリーでターゲットを右クリックしても表示されます)。このメニューは、選択したサーバー・インスタンスで使用できます。

「コンポーネント・パフォーマンス」コマンドを使用すると、特定の「Access Manager」メトリックを表示するか、「セキュリティ・トークン・サービス」メトリックを表示するかを選択できます。

関連項目: 「Access Managerコンポーネント・ページ」および「セキュリティ・トークン・サービス・コンポーネント・ページ」。

「主要なメトリック」、OAMサーバー・ページ

この表には、選択したOAMサーバー・インスタンスのみの統計のサマリーが表示されます。主要なメトリックには、次に示す、Access Managerとセキュリティ・トークン・サービスの両方の詳細が含まれます。

- 認証/秒、平均認証待ち時間(ミリ秒)、および成功比率

- 認可/秒、平均認可待ち時間(ミリ秒)、および成功比率

- トークン発行/秒、平均発行待ち時間(ミリ秒)、および成功比率

- トークン検証/秒、平均検証待ち時間(ミリ秒)、および成功比率

「パフォーマンス概要」、OAMクラスタ・ページおよびOAMサーバー・ページ

この項では、Access Managerの認証および認可操作と、セキュリティ・トークン・サービスのトークン発行およびトークン検証操作について図示します。「パフォーマンス概要」の「メトリック」は構成できません。メトリック・パレットを使用できるのはパフォーマンス・サマリーだけです。

OAMクラスタまたはOAMサーバー・インスタンスが選択されている場合、「パフォーマンス概要」には次が含まれます。

- 「認証/秒」と「認可/秒」

- 「トークン発行/秒」と「トークン検証/秒」

それぞれの表の座標は以下のとおりです。

- 横軸(x軸)方向の座標は時間を表します。

- 縦軸(y軸)方向の座標は、その時間内に発生した指定トランザクションの回数を表します。

表ビュー

「パフォーマンス概要」の右下の「表ビュー」リンクをクリックすると、ポップアップ・ウィンドウ内の列にパフォーマンス情報が表示されます。

LDAPサーバー、OAMクラスタおよびOAMサーバー・ページ

このセクションは、OAMクラスタ・インスタンスまたは単一のOAMサーバー・インスタンスが選択されていると使用可能になります。デフォルトのLDAPユーザー・アイデンティティ・ストアの情報を示します。

- LDAP操作/秒

- LDAP待機時間(ミリ秒)

- LDAP成功率

「アプリケーション・ドメイン」、OAMクラスタおよびOAMサーバー・ページ

OAMクラスタ・ページおよびOAMサーバー・ページのこのセクションには、認証プロセスおよび認可プロセスで使用されたすべてのアプリケーション・ドメインに関する情報が表示されます。

このセクションの列に表示されるものは、次のとおりです。

- アプリケーション・ドメイン名: リクエストに使用された認証および認可ポリシーを含む各アプリケーション・ドメイン。

- 各アプリケーション・ドメインの「認証/秒」、認証待ち時間(ミリ秒)、成功比率(%)

- 各アプリケーション・ドメインの「認可/秒」、認可待ち時間(ミリ秒)、成功比率(%)

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

「クラスタ」およびサーバー・インスタンスの両方のメニューにある「コンポーネント・パフォーマンス」コマンドを使用すると、Access Manager固有のメトリックを表示できます。

クラスタ・コンポーネント固有のメトリックは、図10-10で示すように、クラスタ全体で集約されます。表10-4の後に詳細な説明があります。

図10-10 クラスタの集約されたAccess Managerコンポーネント・メトリック

「図10-10 クラスタの集約されたAccess Managerコンポーネント・メトリック」の説明

図10-11は、単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリックを示しています。

図10-11 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック

「図10-11 単一のOAMサーバー・インスタンスのAccess Managerコンポーネント・メトリック」の説明

表10-4は、Access Managerのコンポーネント固有のメトリックを示しています。

表10-4 Access Managerコンポーネント・メトリック

Access Managerメトリック

説明

Access Managerクライアント

選択内容(クラスタ・インスタンスまたはサーバー・インスタンス)に基づいて、このページにはクラスタ内でアクティブなすべてのアクセス・クライアントの(または個別のOAMサーバーのアクティブなアクセス・クライアントの)情報が表示されます。詳細には次が含まれます。

- クライアントID

- タイプ

- 認証

- 認可

クライアントID

Oracle Access Managementコンソールのエージェント登録で定義されたエージェント名が表示されます。例:

IAMSuiteAgent

タイプ

エージェントのタイプを表示します。例:

OAM Webgate

認証

「認証」列が示す内容:

- 認証/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認証数

- 待ち時間(ミリ秒): 認証が遅延したミリ秒数

- 成功率(%): クラスタ内の各OAMサーバー・インスタンスの認証成功の割合を表す数値

認可

「認可」列が示す内容:

- 認可/秒: クラスタ内の各OAMサーバー・インスタンスの秒当たりの認可数

- 待ち時間(ミリ秒): 認可が遅延したミリ秒数

- 成功率(%): クラスタ内の各OAMサーバー・インスタンスの認可成功の割合を表す数値

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

「クラスタ」およびサーバー・インスタンスの両方のメニューにある「コンポーネント・パフォーマンス」コマンドを使用すると、セキュリティ・トークン・サービス固有のメトリックを表示できます。

クラスタのコンポーネント固有のメトリックが、図10-10で示すように集約されています。

図10-12 クラスタの集約されたSTSコンポーネント・メトリック

「図10-12 クラスタの集約されたSTSコンポーネント・メトリック」の説明

図10-10で示したとおり、それぞれ個別のサーバー・インスタンスで、STSコンポーネント固有メトリックも使用可能です。

図10-13 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック

「図10-13 個別のOAMサーバー・インスタンスのSTSコンポーネント・メトリック」の説明

表10-5では、STSコンポーネント固有のメトリックを説明します。

表10-5 STSコンポーネント固有のメトリック

セキュリティ・トークン・サービスのメトリック

説明

リクエスタ・パートナ

選択したOAMサーバー・インスタンスの統計サマリー(あるいはクラスタの集約されたサマリー):

- パートナID

- トークン発行

- トークン検証

リクエスタ・パートナIDを選択すると、指定したパートナのみの特定情報を含むリライイング・パーティの詳細が明らかになります。

トークン操作

STSトークン操作のメトリックには、次のものが含まれます。

- トークン・タイプ

- トークン発行: リクエストの合計、リクエスト/秒、平均発行待ち時間(ミリ秒)

- トークン検証: リクエストの合計、リクエスト/秒、平均発行待ち時間(ミリ秒)

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

「クラスタ」メニューまたはサーバー・メニューの「パフォーマンス・サマリー」コマンドは、選択したターゲットのメトリック・チャートを表示します。

図10-14 「パフォーマンス・サマリー」コマンド

「図10-14 「パフォーマンス・サマリー」コマンド」の説明

「パフォーマンス・サマリー」ページには、選択されたそれぞれのメトリックに対してチャートが表示されます。OAMサーバーの「パフォーマンス・サマリー」ページです。図10-15は、「メトリック・パレット」が開いている「パフォーマンス・サマリー」ページを示しており、ここからメトリックを選択してチャート化できます。積上げチャートでは、同じ時間枠の複数のメトリックを比較したり、時間枠を変更して過去にさかのぼったり、拡大や縮小を容易にできます。

図10-15 メトリック・パレットを表示した「パフォーマンス・サマリー」ページ

「図10-15 「メトリック・パレット」を表示した「パフォーマンス・サマリー」ページ」の説明

「パフォーマンス・サマリー」ページで使用できるステータスとコントロールを表10-6 に示します。

表10-6 「パフォーマンス・サマリー」ページのステータスとコントロール

ステータスまたはコントロール

説明

過去n分間

ステータスは指定された時間枠に基づくもので、この時間はスライダで調整することができます。

すべて

n分間

指定された時間枠。スライダを使って調整できます。

スライダ

時間枠を調整するために使用するツール。

チャート・セット

保存されたチャートのセットを選択して表示することのできるリスト。

表示

グリッドの追加、チャートの保存、およびページ上の情報を構成することのできるメニュー。

オーバーレイ

同じタイプの別のインスタンスを検索して表示し、これをサマリー内のインスタンスと比較することのできるメニュー。

メトリック・パレット

チャートに表示するパフォーマンス・メトリックを選択することのできるリスト。Access Managerおよびセキュリティ・トークン・サービス独自の項目がここに表示されます。

左: クラスタの「メトリック・パレット」

右: 単一のOAMサーバーの「メトリック・パレット」

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

Fusion Middleware Controlの管理者は、次の手順を使用して、「パフォーマンス・サマリー」に表示されるメトリックを追加または変更することができます。

関連項目:

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

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

「パフォーマンス・サマリー」に表示されるメトリックの追加または変更方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. パフォーマンス概要:

1. 希望のノードを開いてターゲットを選択します。例: アイデンティティとアクセス
アイデンティティとアクセス
oam_server

2. パフォーマンス概要を確認します。

3. パフォーマンス・サマリー:

1. ターゲットを選択します(ステップ1)。

2. コンテキスト・メニューから「パフォーマンス・サマリー」を選択します。

3. 「サマリー」ページを確認します。

4. メトリックの変更:

1. 「パフォーマンス・サマリー」ページから(ステップ2)、「メトリック・パレットの表示」ボタンをクリックします。

2. サマリーにメトリックを追加する(または削除する)には、メトリック・パレットでノードを開いてチェック・ボックスをオンに(またはオフに)します。

3. 更新された「サマリー」ページを確認します。

4. 終了したら、「メトリック・パレットの非表示」をクリックします。

5. チャート・セットの保存:

1. 「パフォーマンス・サマリー」ページの「表示」メニューで、「チャート・セットの保存」をクリックします。

2. 表示されたダイアログ・ボックスでそのチャート固有の名前を入力し、操作を確認して「OK」をクリックします。

3. 終了したら、「メトリック・パレットの非表示」をクリックします。

4. 「サマリー」ページで更新された情報を確認します。

6. オーバーレイ、Access Managerの追加:

1. 「パフォーマンス・サマリー」ページの「オーバーレイ」メニューで、「別のOracle Access Manager」をクリックします。

2. 「ターゲットの検索と選択」ダイアログでターゲット名とホスト名を入力し、「実行」をクリックします。

3. ターゲット結果の表で希望するターゲット名をクリックし、「選択」を選択します。

4. オーバーレイの表示が終了したら、「オーバーレイ」メニューで「オーバーレイの削除」をクリックします。

7. オーバーレイ、今日と昨日の追加:

1. 「パフォーマンス・サマリー」ページの「オーバーレイ」メニューで、「今日と昨日」をクリックします。

2. オーバーレイの表示が終了したら、「オーバーレイ」メニューで「オーバーレイの削除」をクリックします。

8. テスト:

1. アクセス・テスタを使用して、何回か認証テストと認可テストを行ないます(第18章を参照)。

2. Fusion Middleware Controlでパフォーマンス・メトリックを確認します。

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

Fusion Middleware Controlの管理者は、次の手順を使用してコンポーネント固有のパフォーマンス・データを表示および比較することができます。

関連項目:

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

- 「Security Token Serviceコンポーネント・ページ」

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

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。例:
アイデンティティとアクセス
oam_server

3. コンテキスト・メニューから、「コンポーネント・パフォーマンス」を選択します。

4. 「Access Manager」(または「セキュリティ・トークン・サービス」)を選択します。

5. STSパートナID: 必要な場合は、詳細について「セキュリティ・トークン・サービス」結果表で「パートナID」を選択します。

6. コンポーネント・パフォーマンス:

1. コンテキスト・メニューから、「コンポーネント・パフォーマンス」を選択します。

2. 「Access Manager」または「セキュリティ・トークン・サービス」のいずれかを選択します。

3. 使用可能な場合は、結果表で項目を選択して詳細を表示します。

7. テスト:

1. アクセス・テスタを使用して、何回か認証テストと認可テストを行ないます(第18章を参照)。

2. Fusion Middleware Controlでパフォーマンス・メトリックを確認します。

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

Oracle Access Managerのコンポーネントは、すべてのタイプのイベントを記録するメッセージを含むログ・ファイルを作成します。管理者は、この章の説明に従い、Fusion Middleware Controlを使用してログ・レベルを設定することができます。

注意:

この他、第6章に示すように、管理者はカスタムWebLogic Scripting Tool(WLST)コマンドを使用してOAMロガー・レベルを設定することができます。

この項には、次の各項目が含まれます。

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

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

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

Fusion Middleware Controlを使用すると、管理者はAccess Manager (またはセキュリティ・トークン・サービス)のログ・レベルを動的に変更できます。

表10-7は、使用可能なログとFusion Middleware Controlの機能を示します。

表10-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

可

可

可

不可

可

可

アイデンティティとアクセス

OAM (クラスタ)

oam_server (サーバー)

不可

可

不可

可

図10-16は、Fusion Middleware Controlの「ログ・レベル」構成ページを示します。「ランタイム・ログ出力」が選択された「表示」で、oracle.oamログ出力名が現在表示されていることに注意してください。セキュリティ・トークン・サービスでは、セキュリティ・トークン・サービスのログ・レベルに影響を及ぼすログ出力(oracle.security.fed)が1つのみあります。

図10-16 「ログ構成」タブのAccess Managerログ・レベル

「図10-16 「ログ構成」タブのAccess Managerログ・レベル」の説明

図10-17 セキュリティ・トークン・サービスのログ・レベル

「図10-17 セキュリティ・トークン・サービスのログ・レベル」の説明

ログ構成ページの 「ログ・レベル」タブを使用すれば、永続ロガーおよびアクティブ・ランタイム・ロガー両方のログ・レベルの構成すを設定できます。

- 永続ロガーは構成ファイルに保存され、コンポーネントが起動するとアクティブになります。
これらのロガーのログ・レベルは、コンポーネントを再起動しても維持されます。

- ランタイム・ロガーは実行時に自動的に作成され、特定の機能領域が実行されるとアクティブになります。
たとえばoracle.j2ee.ejb.deployment.Loggerは、EJBモジュールがデプロイされるとアクティブになるランタイム・ロガーです。ランタイム・ロガーのログ・レベルは、コンポーネントを再起動すると変更されます。

表10-8では、ログ・レベルの構成ステータスとオプションを説明します。

表10-8 「ログ構成」ページの「ログ・レベル」タブ

要素

説明

適用

ログ・レベル構成の変更を送信して適用します。変更内容は直ちに有効になります。

元に戻す

前のログ・レベル構成を復元します。復元内容は直ちに有効になります。

表示

このリストを使用して、ランタイム・ロガーまたは永続的なログ・レベル状態を持つロガーを表示します。

- ランタイム・ロガー

- 永続的なログ・レベル状態を持つロガー

検索

このリストを使用して、検索しようとするカテゴリを指定します。

表

ロガー名

検索中に見つかったロガーの名前。リスト内の名前を開いて、最上位ノードの下にあるロガーを表示することができます。

Oracle Diagnostic Loggingのレベル(Javaレベル)

対応するロガー(c)のロギング・レベルを選択します。

「適用」をクリックして、ポップアップ・ウィンドウに表示される確認メッセージを確認します。

ログ・レベルを更新しています
ランタイム・ロガーのログ・レベルを更新しています
ランタイム・ロガーのログ・レベルの更新に成功しました
ログ・レベルの更新に成功しました

ログ・ファイル

「ログ・ファイル」列の名前をクリックすると「ログ・ファイル」ページが表示されます。このページでは、ログ・メッセージを記録するファイル、ログ・メッセージの書式、ローテーション・ポリシー、その他のロギング・パラメータの作成と編集を行なうことができます。

関連項目: 「Fusion Middleware Controlによるログ・ファイル構成の管理」

永続的なログ・レベル状態

「ログ・ファイル」タブを使って値の作成または編集を行なった時に設定した、特定ロガーの永続的状態を示します。

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

Fusion Middleware Controlの管理者は、次の手順を使用して、ログ・レベルを動的に設定することができます。

関連項目:

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

注意:

または、第6章で説明したとおり、管理者はカスタムWebLogic Scripting Tool(WLST)コマンドを使用してログ出力レベルを設定できます。

Fusion Middleware Controlでのロギング・レベルの動的設定方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。例:
アイデンティティとアクセス
oam_server

3. 「Access Manager」コンテキスト・メニューから、「ログ」を選択してから「ログ構成」を選択します。

4. 「ログ・レベル」タブの「表示」リストで、表示するログ出力を選択します。例: ランタイム・ロガー。

5. 「検索」リストからカテゴリを選択し、検索基準を入力して、検索ボタンをクリックします。例: 「すべてのカテゴリ」の「sts」。

6. 結果表内で必要に応じてノードを開き、内容を表示します。

7. 結果表で、ご使用の環境に合ったログ・レベルを選択してから「適用」(または「元に戻す」)をクリックします。

8. 「Fusion Middleware Controlによるログ・ファイル構成の管理」に進みます。

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

この項の内容は次のとおりです。

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

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

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

ログ・ファイルの構成を図10-17に示します。ログ・メッセージの記録場所、ログ・メッセージの書式、使用するローテーション・ポリシー、ログ・ファイルの構成クラスに応じたその他のパラメータの作成と編集にはこのページを使用します。

図10-18 ログ・ファイルの構成ページ

「図10-18 ログ・ファイルの構成ページ」の説明

表10-9では、Access Manager (またはセキュリティ・トークン・サービス)のログ・ファイル構成パラメータを説明します。

表10-9 ログ・ファイル要素

要素

説明

作成

メッセージ記録用の新しいファイルを作成するために未定義フォームを表示するには、このボタンをクリックします。

注意:

- 「ログ・ファイル」はログ・ハンドラの名前です(OAM用のodl-handler)。

- 「ログ・パス」はご使用の環境内のロギング出力ファイルを指していますが、これは変更可能です。

- ユーザー環境内の出力ロギング・ファイルには固有の名前を付けることができます。

類似作成

メッセージ記録用の新しいファイルを作成するために一部定義済みのフォームを表示するには、このボタンをクリックします。

構成の編集

選択したログ・ファイル構成の表示と編集には、このボタンを使用します。

構成の表示

選択したログ・ファイル構成の読取専用記述を表示するには、このボタンをクリックします。

表

この表内の情報は、この表内のファイル構成パラメータに基づくものです。

ハンドラ名

ログ・ファイルの作成時に割り当てられたログ・ファイル名です。

ログ・パス

ファイル作成時に割り当てられたファイル・システム・ディレクトリ・パスです。

ログ・ファイル形式

ログ・ファイル作成時に割り当てられたログ・ファイル形式です。

ローテーション・ポリシー

ログ・ファイル作成時に選択されたローテーション・ポリシーです。

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

Fusion Middleware Controlの管理者は、次の手順を使用して、ログ・ファイルの作成、構成の編集、または読取専用ログ・ファイル構成の表示を行うことができます。

関連項目:

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

Fusion Middleware Controlでログ・ファイルを管理する方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。例:
アイデンティティとアクセス
oam_server

3. 「Access Manager」メニューで、「ログ」を選択してから「ログ構成」を選択します。

4. ログ・ファイルの作成: 「ログ・ファイル」タブから(表10-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でのログ・メッセージの表示」に進みます。

10.8 Fusion Middleware Controlでのログ・メッセージの表示

この項の内容は次のとおりです。

- ログ・メッセージの検索、表示、およびエクスポート

- Fusion Middleware Controlによるログ・メッセージの表示

10.8.1 ログ・メッセージの検索、表示、およびエクスポート

Fusion Middleware ControlでOAMサーバー・インスタンスのコンテキスト・メニューを使用することによって、管理者は次に関する重要ログ情報の検索、表示、およびエクスポートを行うことができます。

- AdminServerおよびOAMサーバー両方のWebLogic(およびOAM)AdminServerログアウト・ページとOAM SSOログアウト・ページを含むアプリケーション・デプロイメント・ターゲット

- OAMファーム、AdminServer、およびOAMサーバーを含むWebLogicサーバー・ドメイン・ターゲット

- OAMファーム、クラスタ、および個々のOAMサーバーを含むIdentity and Accessターゲット

ログ・ファイルを使用して一般的な問題のトラブルシュートを行なうには、以下の条件を満たす必要があります。

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明されているとおり、Oracle Fusion Middlewareコンポーネントが使用するOracle Diagnostic Logging(ODL)のフォーマットを理解する

- 適切なレベルの情報を収集するようにログ・ファイルを構成する

- ファーム内の重要ログ情報を検索、表示、エクスポートする

- コンポーネント間でログ・ファイル内のメッセージを相互に関連付けする

図10-19は、Fusion Middleware ControlでのAccess Managerとセキュリティ・トークン・サービスの「ログ・メッセージ」ページを示しています。

図10-19 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ

「図10-19 Fusion Middleware Controlの標準的な「ログ・メッセージ」ページ」の説明

表10-10はFusion Middleware Controlの「ログ・メッセージ」ページの要素を示しており、これらの要素を使用するとメッセージを探して表示できます。

表10-10 Fusion Middleware ControlのOAMログ・メッセージ検索コントロール

要素

説明

ターゲット・スコープを拡大

このリストから項目を選択すると、この検索に使われるターゲットが拡大(または縮小)されます。

- Oracle WebLogic Serverドメイン

- OAMクラスタ

- Oracle WebLogic Server

- Oracle Fusion Middlewareファーム

ターゲット・ログ・ファイル...

ターゲット・スコープに対するすべてのログ・ファイルのリストが表示されます。ユーザーは、このスコープから特定のログ・ファイルを選択して表示またはダウンロードすることができます。

リフレッシュ・オプション

このリストから項目を選択してリフレッシュ方法を指定します。

- 手動リフレッシュ

- 30秒リフレッシュ

- 1分間リフレッシュ

検索オプション

日付範囲

希望するメッセージのセットが記録される期間。

- 最新
分

時間

日

- 時間間隔
日付範囲

開始日

終了日

メッセージ・タイプ

この検索に適用されるすべてのメッセージ・タイプを選択します。

- インシデント・エラー

- エラー

- 警告

- 通知

- トレース

- 不明

メッセージ

このリストから識別子を選択し、横にある空白フィールドに値を入力して検索基準を変更します。

フィールドの追加

含めることのできる追加検索基準のリストを表示するには、このボタンをクリックします。

検索

特定の基準を使用して検索を開始するには、このボタンをクリックします。

表示オプション

表示

検索結果表の列の表示または並べ替えをするには、このメニューから項目を選択します。

表示

表示するエンティティを選択します。

関連メッセージを表示

このメニューは、検索結果に少なくとも1つのメッセージがリストされていれば使用できます。

メッセージをファイルにエクスポート

検索結果に少なくとも1つのメッセージがリストされていれば使用することのできる表示コマンドのメニュー。以下のコマンドを選択できます。

結果の表の列

これらは、「ログ・メッセージ」ページの「表示」メニューでの選択に基づいて決定されます。

メッセージ・エリア

検索結果の表で選択したメッセージの詳細が表示されます。

10.8.2 Fusion Middleware Controlによるログ・メッセージの表示

Fusion Middleware Controlの管理者は、次の手順を使用して、ターゲットのログ・メッセージの表示とダウンロードを行うことができます。この手順は、メッセージの検索、メッセージの表示(または関連メッセージの表示)、1つのログ・ファイル内のすべてのメッセージの表示、およびメッセージのエクスポートまたはダウンロードの方法を説明したものです。

関連項目:

ログ・メッセージの検索、表示、およびエクスポート

Fusion Middleware Control内でのOAMサーバー・ログ・メッセージの表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。例:
アイデンティティとアクセス
oam_server

3. OAMのコンテキスト・メニューで「ログ」を選択し、さらに「ログ・メッセージの表示」を選択します。

4. 検索(表10-10):

1. 「日付範囲」を指定します。

2. 検索に含めるすべての「メッセージ・タイプ」を選択します。

3. 「メッセージ」内容オプションを決定します。

4. フィールドの追加: メッセージの内容をさらに明確にするための詳細を入力します。

5. 「検索」をクリックして、検索基準に合致するメッセージのリストを表示します。

5. メッセージの表示: 検索結果の表から1つ以上のメッセージをクリックすると、それらがページの下半分に表示されます。

6. 関連メッセージの表示: 以下のいずれかの方法を使って検索結果の表を編成します。

1. 時間別: 関連メッセージの表示メニューから、時間別を選択します。

2. ECID別: スクリーン上のメッセージの中からECIDをクリックします(または、関連メッセージの表示メニューからECID(実行コンテキスト識別子)別を選択します)。

3. 「スコープ」メニューから時間枠を選択します。

7. ログ・ファイル: ファイル内のすべてのメッセージを表示するには、検索結果の表で「ログ・ファイル」列の名前をクリックします。

8. メッセージをファイルにエクスポート

1. 検索結果の表で、1つまたは複数のメッセージを選択します。

2. 「メッセージをファイルにエクスポート」メニューから、希望するエクスポート・フォーマットを選択します。例: Oracle Diagnosticsログ(.txt)

3. ダイアログ・ボックスで使用プログラムをクリックし、希望のプログラムを選択します。

4. 開いたプログラムから、新しいパスにファイルを保存します。

9. ダウンロード

1. 検索結果の表で、1つまたは複数のメッセージを選択します。

2. 「ダウンロード」ボタンをクリックします。

3. ダイアログ・ボックスで使用プログラムをクリックし、希望のプログラムを選択します。

4. 開いたプログラムから、新しいパスにファイルを保存します。

10. テスト:

1. アクセス・テスタを使い、無効なユーザー名を入力して認証を試みます(第18章を参照)。

2. Fusion Middleware Controlでログ・ビューアを開き、エラーを確認します。

3. アクセス・テスターを使い、無効なパスワードを入力して認証を試みます。

4. Fusion Middleware Controlのログ・ビューアでエラーを確認し、すべての関連ログ・メッセージを表示します。

5. 「Fusion Middleware Controlでのログ・レベル変更の管理」の説明に従い、様々なログ・レベルを使ってこのテストを繰返します。

10.9 Fusion Middleware ControlでのMBeanの表示

Javaオブジェクトは、コンピュータを作動させるコードの単位です。それぞれのオブジェクトは特定のクラス、またはクラスのメソッドやプロシージャ、あるいはデータ変数に依存するサブクラスのインスタンスです。Javaプログラミング言語では、管理可能なリソースを表すJavaオブジェクト(アプリケーション、サービス、コンポーネント、またはデバイス)をMBeanと呼びます。

Fusion Middleware Controlを使用すれば次のことが可能です。

- 重要なMBeanの「属性」と「操作」に関する情報の表示

- メソッドの起動

この項の内容は次のとおりです。

- システムMBeanブラウザについて

- MBeanの管理

10.9.1 システムMBeanブラウザについて

Fusion Middleware ControlのシステムMBeanブラウザは、表10-11に概要を示す項目の表示に使用できます。

表10-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

可

可

可

アイデンティティとアクセス

OAM (クラスタ)

oam_server (サーバー)

不可

可

注意:

セキュリティ・トークン・サービスのMBeanは、ここで説明するように使用することもできます。

表10-12は、Access Managerおよびセキュリティ・トークン・サービスがドメイン・ランタイム・サーバー(OAMサーバー)のAdminServerにデプロイするMBeanを示しています。

表10-12 Access Managerとセキュリティ・トークン・サービスがデプロイするMBean

MBean

説明

構成サービス

oracle.oam:type=Config

パートナおよび信頼サービス

oracle.oam:type=PATConfig

STS MBean

oracle.sts:type=Config

証明書検証モジュール

これらはCRL管理に使用されます。

oracle.sts:type=CertRevocationListConfig

図10-20では、「システムMBeanブラウザ」および関連の「属性」タブに、セキュリティ・トークン・サービスのCertRevocationListConfig: oracle.sts:Location=oam_server1,type=CertRevocationListConfigの情報が表示されています。

図10-20 システムMBeanブラウザと「「属性」タブ

「図10-20 「システムMBeanブラウザ」と「属性」タブ」の説明

表10-13では、「システムMBeanブラウザ」と関連するタブを詳細に説明します。

表10-13 システムMBeanブラウザ

システムMBeanブラウザ

システムMBeanブラウザ

このセクションの項目を開くと、選択したターゲットのMBeanが表示されます。「アプリケーション定義のMBean」の下に、oracle.oamとoracle.stsがあります。

MBean情報

選択したターゲットのMBeanに関係する「属性」と「操作」の詳細が右側に表示されます。

属性

このタブには、選択したターゲットのMBean属性が表示されます。

操作

このタブには、選択したターゲットのMBean操作が表示されます。

通知

このタブにはMBeanの起動によって生成される通知がリストされます。

コントロール

次のコントロールをこれらのページで使用できます。

- 「名前」リンク: 名前をいずれかのタブでクリックすると、関係するMBeanの詳細が表示されます。

- 「適用」ボタン: 選択したMBean属性値を送信して適用します。

- 「元に戻す」ボタン: 変更後(「適用」のクリック前)に直前のMBean属性値を復元します。

- 「戻る」ボタン: MBean情報のページに戻ります。

- 「呼出し」ボタン: 選択したMBeanおよび値を呼び出します。

10.9.2 MBeanの管理

Fusion Middleware Control管理者は、次の手順を使用して、Access Managerおよびセキュリティ・トークン・サービスのMBeanを表示できます。さらに、値を適用して(または変更を元に戻して)MBeanを起動できます。

Access Managerおよびセキュリティ・トークン・サービスのMBeanを表示、編集、または起動する方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. 希望のノードを開いてターゲットを選択します。例:
アイデンティティとアクセス
oam_server

3. 「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を呼び出し、表示されるメッセージを確認します。

10.10 Fusion Middleware Controlでのファームのルーティング・トポロジの表示

Fusion Middleware Controlを使用すれば、Access Managerのルーティング・トポロジをグラフィカルに表示できます。

この項の内容は次のとおりです。

- ルーティング・トポロジについて

- Fusion Middleware Controlを使用したルーティング・トポロジの表示

10.10.1 ルーティング・トポロジについて

Fusion Middleware Controlのファーム・ルーティング・トポロジ・ページを図10-21に示します。

図10-21 コンテキスト・メニューが表示された状態のルーティング・トポロジ

「図10-21 コンテキスト・メニューが表示された状態のルーティング・トポロジ」の説明

ファーム・トポロジ・ページのステータスとコントロールを表10-14 に示します。

表10-14 ファーム・トポロジ

要素

説明

イメージの保存

イメージを保存します。

印刷

イメージを印刷します。

イメージを拡大縮小します。

検索

値を入力するか「検索」をクリックすると結果が表示されます。

+

トポロジ・ビュー上のインスタンスを開いて詳細を表示します。

ステータス・バー

完全なファーム名とファーム内のターゲット、および実行状態を表示します。トポロジ・ビュー上の個々のインスタンス上にステータスとメトリックをオーバーレイさせることもできます。

10.10.2 Fusion Middleware Controlを使用したルーティング・トポロジの表示

Fusion Middleware Controlの管理者は、以下の手順を使用して、Access Manager 11gを含むファームのルーティング・トポロジを表示することができます。

関連項目:

ルーティング・トポロジについて

ファーム・ルーティング・トポロジの表示方法

1. Fusion Middleware Controlへのログインの説明に従ってログインします。

2. ナビゲーション・ツリーでファームを選択します。

3. ナビゲーション・ツリー上のトポロジをクリックします。

4. トポロジ・ブラウザ・ウィンドウでファーム名をクリックし、「OK」をクリックします。

5. スケーリング・ツールを使用して、イメージを拡大または縮小します。

6. トポロジ内のインスタンスを開いて、それぞれの詳細を表示します。

7. 「オーバーレイ」オプションを使用して、インスタンスにステータス情報とメトリック情報を追加します。

8. 「検索」オプションを使用して特定の情報を検索します(表10-14)。

9. 必要に応じ、「印刷」または「保存」をクリックします。

第IV部

Access Managerの設定とエージェントの管理

第IV部では、低レベルのAccess Manager構成の管理について説明します。

第IV部の内容は次のとおりです。

- 第11章「Access Managerの設定の構成」

- 第12章「エージェントおよび登録の概要」

- 第13章「OAM 11gエージェントの登録および管理」

- 第14章「セッションの管理」

11 Access Managerの設定の構成

この章では、Access Manager固有の設定について説明します。この章は、次のトピックで構成されています。

- 前提条件

- Access Managerの設定の概要

- ロード・バランシングの管理

- セキュア・エラー・モードの管理

- SSOトークンとIPの検証の管理

- OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

- 実行時のポリシー評価キャッシュの管理

11.1 前提条件

この項では、この章のタスクの要件を明らかにします。この章のタスクを開始する前に、次のトピックを確認してください。

- 第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」

- 第5章「サーバー登録の管理」

11.2 「Access Managerの設定」の概要

「システム構成」タブの「Access Manager」セクションには、Access Managerのサービスの操作に固有の設定が数多く用意されています。

図11-1 Access Managerの設定

「図11-1 Access Managerの設定」の説明

表11-1 Access Managerの設定

設定

参照先

ロード・バランシング

ロード・バランシングの管理

サーバー・エラー・モード

セキュア・エラー・モードの管理

SSO

SSOトークンとIPの検証の管理

アクセス・プロトコル

OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

ポリシー

実行時のポリシー評価キャッシュの管理

11.3 ロード・バランシングの管理

ここでは、次の内容について説明します。

- 共通のロード・バランシング設定について

- OAMサーバーのロード・バランシングの管理

11.3.1 共通のロード・バランシング設定について

アプリケーションのパフォーマンス、スループットまたは高可用性の向上が求められる本番環境では、2つ以上の管理対象サーバーがクラスタとして機能するように構成できます。クラスタとは、同時に稼働し、協調動作によってスケーラビリティと信頼性の向上を実現する、WebLogic Serverの複数のサーバー・インスタンスの集合です。クラスタでは、(単一の管理対象サーバーでなく)管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。1つのドメインには、複数のWebLogic Serverクラスタが存在していても、クラスタとして構成されていない複数の管理対象サーバーが存在していてもかまいません。管理対象サーバーがクラスタ化されている場合とされていない場合の重要な違いは、フェイルオーバーとロード・バランシングに対するサポートです。これらの機能は、管理対象サーバーがクラスタ化されている場合にのみ利用できます。

デフォルトでは、Access Managerは1つのOAMサーバーにすべてのログインおよびログアウト・リクエストを送信します。高可用性デプロイメントでは、この設定を変更してログインおよびログアウト・リクエストが最初にローカル・バランサに送信されるようにする必要があります。

関連項目:

Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順については、『Oracle Fusion Middleware高可用性ガイド』のAccess Managerの高可用性の手順に関する項を参照してください。

図11-2に、「Access Managerの設定」ページの「ロード・バランシング」の設定セクションを示します。以前のリリースでは、これはSSOエンジンの設定の一部でした。SSOエンジンはセッションのコントローラです。

図11-2 「Access Managerの設定」: 「ロード・バランサ」

「図11-2 「Access Managerの設定」: 「ロード・バランサ」」の説明

表11-2で、各要素とその使用方法を説明します。設定はグローバルで、WebLogic管理ドメインのすべてのOAMサーバーに共通です。

表11-2 「Access Managerの設定」: 「ロード・バランサ」

要素

説明

OAMサーバー・ホスト

OAMサーバー・クラスタを表す仮想ホスト名で、ロード・バランサによってOAMサーバー・クラスタの前に公開される場合があります。

OAMサーバー・ポート

OAMサーバー・クラスタに関連付けられている仮想ホスト・ポート。1～65535の値がサポートされています。

OAMサーバー・プロトコル

プロトコル(HTTPまたはHTTPS)で、OAMサーバー・クラスタを表す仮想ホストにアクセスするために使用されます。

関連項目: 「セキュリティ・モードおよびX509Scheme認証について」

11.3.2 OAMサーバーのロード・バランシングの管理

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagementコンソールでAccess Managerのロード・バランシング設定を変更できます。

関連項目:

「共通のロード・バランシング設定について」

共通のロード・バランシング仕様を表示または編集する手順

1. Oracle Access Managementコンソールで、「ロード・バランシング」を開きます。
「システム構成」タブ
「Access Manager」セクション
「Access Managerの設定」
「ロード・バランシング」

2. 「ロード・バランシング」エリアを展開します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: デプロイメントのロード・バランシング設定を編集します(表11-2)。

3. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

4. 確認ウィンドウを閉じます。

11.4 セキュア・エラー・モードの管理

カスタム・ログイン・アプリケーションの一部として、カスタム・エラー・ページがパッケージされています。すぐに使用可能なカスタムWebアプリケーションのアーカイブ・ファイルが提供されており、カスタマイズされたログイン・ページやパスワード・ページを開発するための開始点として使用できます。

サーバー・エラー・モード設定はグローバルで、WebLogic管理ドメインのすべてのOAMサーバーに共通です。この項の内容は次のとおりです。

- OAMサーバー・エラー･モードについて

- OAMサーバーのセキュア・エラー・モードの管理

11.4.1 OAMサーバー・エラー･モードについて

図11-2は、「Access Managerの設定」ページの「ロード・バランシング」設定エリアに表示されるサーバー・エラー・モードの機能を示しています。

図11-3 「Access Managerの設定」: 「サーバー・エラー・モード」

「図11-3 「Access Managerの設定」: 「サーバー・エラー・モード」」の説明

表11-3は、デプロイメントのサーバー・エラー・モードを構成するために選択できるオプションについて説明しています。

表11-3 サーバー・エラー・モード

要素

説明

サーバー・エラー・モード

ここで選択する設定によって、操作が失敗したとき(ユーザー名またはパスワードが無効、サーバー・エラー(LDAPサーバーへの接続が切れている)など)にOAMサーバーによって返されるエラー・メッセージの性質や、エラー・コードが決まります。

次のいずれかの設定を選択し、カスタム・ログイン・ページのエラー・メッセージと各セキュリティ・レベルを構成します。

- セキュア: セキュリティが最も高い設定。汎用的なエラー・メッセージのみを表示し、エラーの内部的な理由はほとんど何も示されません。

- 外部: 推奨レベル。

- 内部: セキュリティ・レベルが最も低い設定。パスワード・ポリシーの検証にお薦めされます(「グローバル・パスワード・ポリシーの管理」を参照)。

- Osso10g: OSSO 10gと互換です。アップグレードした環境で、整合性のために必要な場合があります。

関連項目: 「OAMサーバーのセキュア・エラー・モードの管理」.

表11-4は、3つのモードそれぞれのエラーのトリガー条件とメッセージ・コードを示しています。

表11-4 エラーのトリガー条件、モード、メッセージ・コード

エラーのトリガー条件

内部モード

外部モード

セキュア・モード

無効なログインを試行しました。

OAM-1

OAM-2

OAM-8

送信された資格証明の処理が失敗しました。たとえば、WNAモードでSPNEGOトークンが受信されない場合などです。

OAM-3

OAM-3

OAM-8

認証例外が発生しました。

OAM-4

OAM-4

OAM-9

特定の条件(たとえば、無効な試行回数を超過)に基づいてユーザー・アカウントがロックされています。

OAM-5

OAM-5

OAM-8

OAM-9(OIM統合)

ユーザー・アカウントが無効化されています。

OAM-5

OAM-5

OAM-9

ユーザーが許可される最大セッション数(構成可能な属性)を超えました。

OAM-6

OAM-6

OAM-9

デフォルトのエラー・メッセージ。これは特定のメッセージが伝播されていない場合に表示されます。これはユーザー・レベルには伝播されません。複数の発生条件が考えられます。

OAM-7

OAM-7

OAM-9

パスワードの有効期限が切れています。

OAM-10

OAM-10

OAM-9

表11-5に、エラー・コード、トリガー条件、推奨のメッセージを示します。

関連項目:

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム・エラー・ページの開発に関する項を参照してください。

表11-5 外部エラー・コード、トリガー条件、推奨メッセージ

外部エラー・コード

トリガー条件

推奨される表示メッセージ

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-8

表11-4を参照してください。

認証に失敗しました。

OAM-9

システム・エラーです。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。

システム・エラーです。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。

OAM-10

パスワードの有効期限が切れています。

パスワードの有効期限が切れました。

11.4.2 OAMサーバーのセキュア・エラー・モードの管理

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagementコンソールでOAMサーバーのAccess Managerセキュア・エラー・モードを変更できます。

関連項目:

「共通のロード・バランシング設定について」

OAMサーバーのセキュア・エラー・モードを表示または編集する方法

1. Oracle Access Managementコンソールで、「Access Managerの設定」ページを開きます。
「システム構成」タブ
「Access Manager」セクション
「Access Managerの設定」ノード
「ロード・バランシング」

2. サーバー・エラー・モード:

- 変更: デプロイメントに必要なサーバー・エラー・モードを選択します(表11-3および表11-5)。

- 表示のみ: 終了する場合はページを閉じます。

3. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

4. 確認ウィンドウを閉じます。

5. 「SSOトークンとIPの検証の管理」に進みます。

11.5 SSOトークンとIPの検証の管理

ここでは、次の内容について説明します。

- Access ManagerのSSOトークンとIPの検証の設定について

- SSOトークンとIPの検証の管理

11.5.1 Access ManagerのSSOトークンとIPの検証の設定について

図11-4に、「Access Managerの設定」ページのシングル・サインオン(SSO)の部分を示します。表11-6で、各要素とその使用方法を説明します。

図11-4 「Access Managerの設定」: 「SSO」

「図11-4 「Access Managerの設定」: 「SSO」」の説明

表11-6 「Access Managerの設定」: 「SSO」

要素

説明

IPの検証

Webgateに固有で、クライアントのIPアドレスがシングル・サインオン用に生成されたObSSOCookieに格納されているIPアドレスと同じかどうかを決定するために使用されます。

IP検証を有効にする場合はボックスを選択します。

IP検証を無効にする場合はボックスの選択を解除します。

SSOトークン・バージョン

リストからSSOトークン・バージョンを選択します。

11.5.2 SSOトークンとIPの検証の管理

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagementコンソールでAccess Managerのロード・バランシング設定を変更できます。

関連項目:

「共通のロード・バランシング設定について」

Access ManagerのSSO仕様を表示または編集する手順

1. Oracle Access Managementコンソールで、「Access Managerの設定」ページを開きます。
「システム構成」タブ
「Access Manager」セクション
「Access Managerの設定」ノード

2. 「Access Managerの設定」ページで、「SSO」セクションを展開します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: 残りの手順を実行して、構成を編集します。

3. 表11-6の詳細に基づいて、デプロイメントの必要に応じて、設定を編集します。

4. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. 「OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理」に進みます。

11.6 OAMプロキシの簡易および証明書モード・セキュリティのアクセス・プロトコルの管理

この項の内容は次のとおりです。

- 簡易および証明書モードのトランスポート・セキュリティについて

- セキュア・サーバー通信の共通OAMプロキシ・ページについて

- OAMプロキシの簡易または証明書設定の表示または編集

11.6.1 簡易および証明書モードのトランスポート・セキュリティについて

表11-7は、簡易モードと証明書モードの共通点を示します。

関連項目:

付録C「通信の保護」

表11-7 サマリー: 簡易モードと証明書モード

アーティファクトまたはプロセス

簡易モード

証明書モード

オープン・モード

X.509デジタル証明書のみ。

X

X

なし

OAMエージェントとOAMサーバー間の通信は、Transport Layer Security、RFC 2246(TLS v1)を使用して暗号化されます。

X

X

なし

それぞれの公開鍵に対して、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 Managementコンソールに伝播されます。

それぞれの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

なし

エージェント・キー・パスワード

なし

エージェントの登録時に証明書セキュリティ・モードでパスワードを入力します(表13-1「11gおよび10g OAMエージェントの作成ページの要素」を参照)。

なし

エージェント登録時に、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/

関連項目: 付録C

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/

関連項目: 付録C

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...

なし

11.6.2 セキュア・サーバー通信の共通OAMプロキシ・ページについて

表11-8は、簡易または証明書モードの構成に必要な設定を示します。

表11-8 サーバー共通のOAMプロキシ・セキュア通信の設定

モード

説明

簡易モード構成

OAMが署名したX.509証明書を使用した通信のグローバル・パスフレーズ。これは、初回のOAMサーバーのインストール時に設定されます。

管理者はこのパスフレーズを編集して、既存のすべてのOAMエージェントがそれを使用するように再構成できます。この説明は、「OAMプロキシの簡易または証明書設定の表示または編集」にあります。

証明書モード構成

外部の認証局により署名された証明書モードのX.509証明書が存在するキーKEYSTOREStoreに必要な詳細。

- PEMキーストア別名

- PEMキーストア別名パスワード

注意: これらは初回のOAMサーバーのインストール時に設定されます。証明書は、JDKに付属の証明書のインポート・ユーティリティかキーツールを使用してインポートできます。

管理者は、別名とパスワードを編集して、既存のすべてのOAMエージェントがそれを使用するように再構成できます。この説明は、「OAMプロキシの簡易または証明書設定の表示または編集」にあります。

11.6.3 OAMプロキシの簡易または証明書設定の表示または編集

管理者はこの手順を使用して、共通OAMプロキシの設定を確認または変更できます。

関連項目:

- 「コンソールを使用したOAMエージェントの登録」

- 付録C「通信の保護」

OAMプロキシの簡易または証明書モード設定を表示あるいは編集する手順

1. 「システム構成」タブの「Access Manager」セクションで、「Access Managerの設定」ページを開きます。

2. ページの「アクセス・プロトコル」セクションを、必要に応じて展開します。

3. 簡易モードの場合: OAMが署名したX.509証明書を使用する場合は、「グローバル・パスフレーズ」を追加または変更します。

4. 証明書モードの構成: 次の詳細を指定します。

- PEMキーストア別名

- PEMキーストア別名パスワード

5. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

6. 必要に応じてエージェント登録ページを更新してアーティファクトを再生成し、第12章または第13章の説明に従って初期のアーティファクトを置き換えます。

11.7 実行時のポリシー評価キャッシュの管理

この項では次の内容について説明します。

- 実行時のポリシー評価キャッシュについて

- 実行時のポリシー評価キャッシュの管理

関連項目:

「実行時のリソース評価について」

11.7.1 実行時のポリシー評価キャッシュについて

図11-5に、「Access Managerの設定」ページの「ポリシー」セクションを示します。このセクションには、「リソース一致キャッシュ」と「認可結果キャッシュ」の設定項目があり、この設定は実行時のポリシー評価に使用されます。

図11-5 共通ポリシー評価キャッシュ

「図11-5 共通ポリシー評価キャッシュ」の説明

表11-9は、すべてのサーバーおよびリクエストに適用されるこれらのグローバル設定の概要を示します。

表11-9 ポリシー評価キャッシュ

要素

説明

リソース一致キャッシュ

リクエストされたURLと、そのURLに適用されるリソース・パターンを保持するポリシー間のマッピングをキャッシュ化します。

デフォルト値:

- 最大サイズは100000で、ゼロでキャッシュが無効になります。

- 存続時間(秒) 3600。ゼロは存続時間が無効になります。

認可結果キャッシュ

リクエストされたURLおよびユーザーのポリシー決定をキャッシュ化します。

デフォルト値:

- 最大サイズは100000で、ゼロでキャッシュが無効になります。

- ユーザー当たりの最大サイズは100で、ゼロでキャッシュが無効になります。

- 存続時間(秒) 3600。ゼロは存続時間が無効になります。

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

11.7.2 実行時のポリシー評価キャッシュの管理

管理者はこの手順を使用して、Access Managerのポリシー評価キャッシュを管理できます。

関連項目:

ガイド

- 『Oracle Fusion Middleware高可用性ガイド』

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

実行時の共通ポリシー評価キャッシュ設定を管理する手順

1. Oracle Access Managementコンソールで、「Access Managerの設定」ページを開きます。
「システム構成」タブ
「Access Manager」セクション
「Access Managerの設定」ノード
「ロード・バランシング」

2. 「Access Managerの設定」ページで、「ポリシー」セクションを展開します。

3. リソース一致キャッシュ: 詳細を指定して「適用」をクリックします(表11-9)。

4. 認可結果キャッシュ: 詳細を指定して「適用」をクリックします(表11-9)。

5. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

12 エージェントおよび登録の概要

エージェント(シングル・サインオン・エージェントまたはポリシー施行エージェントとも呼ばれます)は、アクセス・クライアントとして機能する任意のフロントエンドのエンティティであり、エンタープライズ・アプリケーション全体でシングル・サインオンを可能にします。個々のエージェントは、エージェントとOAMサーバー間で必要な信頼を設定するためにAccess Manager 11gに登録する必要があります。登録されたエージェントは、認証タスクをOAMサーバーに委任します。

この章の各項では、エージェントの概要、エージェントの登録と管理、処理およびツールについて説明します。内容は次のとおりです。

- ポリシーの強制エージェントの概要

- エージェント登録の概要

- リモート登録の概要

12.1 ポリシーの強制エージェントの概要

エージェントとは、アプリケーションが存在するWebサーバー(Oracle HTTP Serverなど)にインストールできる、ソフトウェア・プラグインです。保護されたリソースへのアクセスを保護するには、Webサーバーやアプリケーション・サーバー、サードパーティ製のアプリケーションを、Access Managerに登録されたエージェントに関連付ける必要があります。複数のリソースのアクセス時のユーザーの再認証を省略するには、アプリケーションが、シングル・サインオン(SSO)プロバイダであるAccess Managerに、認証機能を委任する必要があります。

エージェントの登録時に、アプリケーションを自動的に登録して、基本ポリシーを自動的に生成できます。また、エージェントの登録時の自動ポリシー生成をオフにして、手動でポリシーを作成することもできます。

登録後のエージェントは、OAMサーバーとそのサービスとの間の通信と協調して、HTTP/HTTPSリクエストのフィルタとして機能します。エージェントは、Access Managerによって保護されたリソースへのリクエストを捕捉して、Access Managerと連動することでアクセス要件を実現します。

この項では、Access Managerのエージェントのタイプについて説明します。

- エージェント・タイプおよびランタイム処理について

- 外部資格証明コレクタとして構成された11g Webgateについて

- Mobile and Social用の11g Webgate機能について

- 事前登録済の10g Webgate IAMSuiteAgentについて

12.1.1 エージェント・タイプおよびランタイム処理について

Access Manager 11.1.2では、各エージェントがリクエストのフィルタとして機能します。デプロイメントには、表12-1で説明するエージェント・タイプを、任意の組合せで含めることができます。

表12-1 エージェント・タイプ

エージェント・タイプ

説明

OAMエージェント

注意: 特に明記しないかぎり、Webgateという用語とアクセス・クライアントという用語は同じ意味で使用されます。

OAMエージェントは、Oracle Access Managementのインストール後に、個別にインストールする必要があります。エージェントをAccess Managerに登録すると、そのエージェントは、登録済のOAMサーバーおよびAccess Managerサービスと直接通信します。OAMエージェントはOAMプロキシを使用してAccess Managerと通信し、リクエストを掃除して、すべてのエージェントに同じように応答します。次のOAMエージェント・タイプが使用できます。

- Webgate: すぐに使用可能なWebサーバーのアクセス・クライアントは、WebリソースのHTTPリクエストを捕捉して、これらをOAMサーバーに転送します。各種のWebサーバー用のWebgateは、Access Managerに同梱されています。

- 11g Webgate (第22章)の提供内容:
プラットフォーム用のOracle Universal Installer
ホストベースのCookie
個別のWebgateのOAMAuthnCookie_<host:port
許可ポリシーに対するリソース
許可結果
Webgate許可キャッシュ
チューニング・パラメータに対する診断ページ
外部資格証明としての役割を果たす機能

関連項目:
「Mobile and Social用の11g Webgateの機能について」
「外部資格証明コレクタとして構成された11g Webgateについて」
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

- 10g Webgateの提供内容
InstallShieldおよびプラットフォームごとに1つのインストーラ
ドメインベースのCookie
ObSSOCookie(すべての10g Webgateに1つ)
Webサーバー構成

関連項目: この表内の「事前登録済の10g IAMSuiteAgent」

- 第22章

- カスタム・アクセス・クライアント: Access Managerは、純粋なJavaソフトウェア開発キット(SDK)を提供していますこのSDKを使用して、カスタムのアクセス・クライアントや、Access Managerの認証および認可機能(およびカスタム・トークン)の拡張機能を作成します。アクセス・クライアントは、ユーザーやアプリケーションからのWebおよびWeb以外(非HTTP)のリソースに対するリクエストを処理します。詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

IAMSuiteAgent

事前登録済のOAM 10gエージェント

この事前登録された10gエージェントは、IAMコンソール・スイートにシングル・サインオン機能を提供します。IAMスイート・エージェントには、付属のアプリケーション・ドメイン(IAMSuite)と、変更することのできない基本ポリシーが含まれています。

関連項目: 「事前登録済の10g Webgate IAMSuiteAgentについて」

レガシーOSSOエージェント

mod_ossoは、中央のOSSOサーバーでユーザーを認証するOracleAS 10gシングル・サインオン(OSSO)ソリューションの一部です。mod_ossoモジュールは、OracleASアプリケーションに認証を提供するOracle HTTPサーバー・モジュールの一部です。

Access Managerに登録すると、OSSO 10gエージェントは、OSSOプロキシを通じてAccess Manager 11gのサービスと直接通信します。OSSOプロキシは、Access Managerへのアップグレード時に既存のOSSOエージェントをサポートします。OSSOプロキシは、OSSOエージェントからのリクエストを処理して、OSSOプロトコルをAccess Manager 11g認証サービスのプロトコルに変換します。

Access Managerは、リソースに定義されたOAMポリシーに関連付けられた認証スキームに基づいて、mod_ossoにユーザー用のリダイレクトURLを渡します。

関連項目: 第21章「レガシーOSSOエージェントの登録および管理」および次の各項。

レガシーOpenSSOエージェント

Javaエージェントは、OpenSSOサーバーと連動するようにJ2EEコンテナにデプロイします。Webエージェントは、任意のWebコンテナまたはサーブレット・コンテナにデプロイできます。各OpenSSOエージェントは、アプリケーションをホストするコンテナ(Oracle WebLogic Server、JBoss、Apacheなど)にプラグインされるフィルタです。

Access Managerは、OpenSSOエージェントによって保護されているリソースへのリクエストを処理するためのOpenSSOプロキシを提供します。

適用範囲はホストベースまたはドメインベースになります
OpenSSOエージェント・キーはローカルに格納されます(エージェント・ブートストラップ・ファイル、エージェント・ホスト)

関連項目: 第20章「レガシーOpenSSOエージェントの登録および管理」。

表12-2に、エージェントの登録、構成管理およびシングル・サインオンをサポートするAccess Managerの機能を示します。各項目のリンク先には、詳細が記載されています。

表12-2 エージェントの登録とSSOサポート

Oracleの提供内容

説明

Oracle Access Managementコンソール

エージェントの登録、構成、管理。

関連項目: 「コンソールを使用したOAMエージェントの登録」

oamregツール

リモートによるエージェントの登録と管理

関連項目: 「リモート登録ツールの取得および設定」

SSO実装

Access Managerは、様々なSSOシナリオをサポートします。

関連項目: 「Access Managerのシングル・サインオンの概要」

インターネット上での情報交換の保護に使用されるプロトコル。

これは、選択した資格証明コレクタに応じて変化します。

関連項目: 表16-5「DCCとECCの比較」

ログイン・フォームとログアウト・フォーム

ログイン・フォームとログアウト・フォームの場所は、資格証明コレクタに応じて変化します。

関連項目: 表16-5「DCCとECCの比較」および第19章

暗号化キー

登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

関連項目: 表1-3「概要: Access Manager 11.1.2」

キー・ストレージ

- エージェント側: エージェントごとのキーは、ウォレット・ファイルのOracle Secret Storeにローカルに格納されます。

- OAMサーバー側: エージェントごとのキーとサーバー・キーは、サーバー側の資格証明ストアに格納されます。

OAMエージェントの実行時の処理

表12-3に、OAMエージェントの実行時の処理についての情報を示します。

関連項目:

「Access Manager資格証明コレクションおよびログインの概要」

表12-3 Access Managerの実行時の処理の概要

エージェント・タイプ

説明

11g Webgate

11gアクセス・クライアント

インストールと登録が終わった後、11g WebgateはOAMプロキシを使用してAccess Managerと通信し、リクエストを"掃除"して、すべてのエージェントに同じように応答します。

プロセス概要、OAMAuthnCookieなしの認証リクエスト: 基本認証スキームによって保護されたリソースに対するリクエストを認証ヘッダー(資格証明)なしで受信した場合

1. Webgateがフロント・チャネルを介し、(スキーム構成に基づいて)埋込みまたはデタッチされた資格証明コレクタにリダイレクトして、資格証明を収集します。

2. 資格証明コレクタは、認証スキームに対して定義されたチャレンジ・メソッドに基づいてユーザーの資格証明を収集します。

3. ユーザーが認証されると、OAMプロキシ(埋込みコレクタ)またはデタッチされたコレクタそのもの(DCC)が、トークン用のバック・チャネル・プロトコルを通じてOAMサーバーと通信し、そのOAMサーバーが発行したトークンを使用して、フロント・チャネルを通じてレスポンスを返します。

4. Webgateは、このレスポンスを検証し、OAMサーバーが発行した認証トークンを抽出して、OAMAuthnCookieにトークンを設定します。

5. 新しく設定したOAMAuthnCookieがアタッチされた状態で、Webgateがリクエストされたリソースにリダイレクトされます。

6. WebgateがOAMAuthnCookieを検証し、バック・チャネルを介して認証を実行して、認証に成功したらページを提示します。

プロセス概要、基本認証: 基本認証スキームによって保護されたリソースに対するリクエストを認証ヘッダー(資格証明)なしで受信した場合

1. WebgateがWWW-Authenticateヘッダーを使用して応答します。ここには、認証スキームにステータス・コード401(認可が必要)を使用して記述されているレルムが格納されています。

2. ブラウザ・クライアントがWWW-Authenticateヘッダーを解釈し、ユーザーから資格情報を収集します。

3. ブラウザ・クライアントが資格証明を含む認証ヘッダーを使用して、リクエストを再実行します。

関連項目:

「外部資格証明コレクタとして構成された11g Webgateについて」

「Mobile and Social用の11g Webgate機能について」

10g Webgate

10gアクセス・クライアント

インストールおよび登録の後、10g Webgateはブリッジとして機能するOAMプロキシを通じてAccess Managerと直接通信します。

関連項目:

- このエージェントおよびアプリケーション・ドメインの詳細は、「IAMSuiteAgent」を参照してください。

- レガシー10g WebgateのAccess Manageへの登録方法の詳細は、第22章を参照してください。

- Oracle ADFセキュリティとOPSS SSOフレームワーク用にコードが記述されたWebアプリケーションと現在ともに動作しているレガシー10g Webgateの詳細は、付録を参照してください。

- Access Manager 11g (またはOracle Access Manager 10g)によるWebLogicコンテナベースのセキュリティを使用するアプリケーション向けに、SSO用のIDアサーション・プロバイダ(IAP)として構成されたレガシー10g Webgateの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

OpenSSOエージェント

関連項目: 「OpenSSOエージェントとAccess Manager間の実行時の処理」。

OSSOエージェント(mod_osso 10g)

関連項目: 「Access Manager使用時のOSSOエージェントの理解」

12.1.2 外部資格証明コレクタとして構成された11g Webgateについて

Oracle Access Manager 11.1.1では、埋込み資格情報コレクタ(IECC)がデフォルトです。ECCは、以前からOAMサーバーに統合されています。

Access Manager 11.1.2も、デフォルトでECCをサポートしています。ただし、Access Manager 11.1.2では、外部資格証明コレクタ(DCC)として使用するように、11g Webgateを構成することもできます。

外部資格証明コレクタ(DCC)として機能するように構成された11g Webgateは、認証Webgateと呼ばれます。リソースを保護するWebgateは、リソースWebgateと呼ばれます。

DCCは、デフォルトの埋込み資格証明コレクタ(ECC)よりも安全性が高いと考えられます。

関連項目:

「DCC対応の11g Webgateと認証ポリシーの構成」

12.1.3 Mobile and Social用の11g Webgate機能について

Webgateは、認証および認可を行うためにクライアントと相互作用します。この相互作用には、リダイレクションによる資格証明の収集、Cookieの設定によるセッション保持、エラーの報告などが含まれます。Webgateはブラウザ・クライアントと連動します。ブラウザ・クライアントは通常、このエンドツーエンドの相互作用に必要なすべての機能をサポートしています。ただし、非ブラウザ/RESTクライアントがリソースにアクセスして認証および認可を実行する必要が生じる場合があります。

Mobile and Socialサポートは、Webgateエージェント登録ページにある2つのユーザー定義のパラメータを使用して有効にします。Mobile and Socialサービスは、Access Managerを使用したプログラムによる非ブラウザ・クライアントを使用します。

関連項目:

- 第IX部「Oracle Access Management Mobile and Socialの管理」

- Oracle Fusion Middleware Oracle Access Management開発者ガイド

12.1.4 事前登録済の10g Webgate IAMSuiteAgentについて

この10g Webgateとコンパニオン・アプリケーション・ドメインは、IDM管理コンソールにシングル・サインオン機能を提供します。IAMSuiteAgentは、OAMサーバーのインストールと構成の一部としてインストールされて事前構成されます。

IAMSuiteAgentとコンパニオン・アプリケーション・ドメインは変更しないでください。ただし、IAMSuiteAgentを新しい10g Webgateに置き換えることはできます。

関連項目:

- 「IAMSuiteAgentの集中ログアウト構成」

- 「IAMSuiteAgentの10g Webgateへの置換」

- 「バンドルされる10g IAMSuiteAgentアーティファクト」

12.2 エージェント登録の概要

Oracle Access Managementコンソールまたはリモート登録ツールを使用して、エージェントの登録および更新を実行できます。特に明記しないかぎり、この項の情報は、Oracle Access Managementコンソールまたはリモート登録ツールのいずれかを使用したエージェント登録に適用されます。

この項では次の情報を提供します。

- エージェントの登録、キーおよびポリシーについて

- ファイル・システム変更および登録されたエージェントのアーティファクトについて

12.2.1 エージェントの登録、キーおよびポリシーについて

登録されたエージェントのみがOAMサーバーと通信でき、保護されたリソースにユーザーがアクセスを試みるときに情報を処理します。エージェント登録時に、ポリシーを作成して、アプリケーションをエージェント登録時に保護できます。

管理者は、運用する各エージェントをAccess Managerに登録する必要があります。このエージェントは、保護対象のアプリケーションをホストするコンピュータ上に存在すると考えられます。ただし、エージェントはプロキシWebサーバー上や、別のホスト上のアプリケーションに存在する場合もあります。

エージェント・キーとパートナ・キーは登録時に作成されます。エージェント登録時にポリシーを自動作成するよう選択した場合、ホスト識別子とアプリケーション・ドメインは、基本ポリシーとリソース定義を使用して作成されます。アプリケーション・ドメインとポリシーは、後から表示および管理できます。

注意:

次に示すように、同じアプリケーション・ドメインとポリシーを使用して、1つのホスト識別子の下に複数のWebgateまたはアクセス・クライアントを登録できます。

1. Webgateを登録するときに、ホスト識別子(ユーザーが名前を選択)を作成し、「ポリシーの自動作成」を有効にすることができます。

2. 手順1と同じホスト識別子を使用して2つ目のWebgateを登録し、「ポリシーの自動作成」ボックスの選択を解除してポリシーが作成されないようにします。

コンソールとリモート登録のどちらを使用していても、登録が成功すると、Oracle Access Managementコンソールに完全なエージェント登録が表示されるようになり、それがクラスタ内の管理対象サーバーに伝播されます。表12-4は、エージェント登録時に生成されるキーとポリシーを示しています。

表12-4 エージェント登録時に生成されるキーとポリシー

キーおよびポリシー

可能なアクセス先

可能なアクセス経路

11g Webgateエージェントごとに1つのキー

すべての10gエージェントに1つのキー

ローカル・エージェントのブートストラップ・ファイルに格納されているOpenSSOエージェントごとに1つのキー

OSSOエージェントごとに1つのキー

関連項目: 「キーの使用、生成、プロビジョニング、およびストレージについて」

- OAMサーバー

- クライアント側: クライアント・ホスト上の保護されたローカル・ストレージ(ローカルのウォレット・ファイル)

- サーバー側: Javaキーストア

アプリケーションのパートナ・キー

(OpenSSOエージェントには存在しません)

- 11g Webgate

クライアント側

アプリケーション・ドメインとデフォルト・ポリシーは、エージェントの登録時に必要に応じて生成されます。

- エージェントの名前

- デフォルトの認証および認可ポリシー(ただしトークン発行ポリシーではない)を使用して伝播されます。

- 登録時にエージェントに対して指定されたものと同じホスト識別子を使用して識別されます。

- 管理者は、Oracle Access ManagementコンソールまたはカスタムのAccess Manager用WLSTコマンドを使用して、登録されたエージェントの表示、変更および削除が可能です。

- 実行時にすべてのエージェント・タイプは、Webサイトにアクセスする試みをモニターし、リクエストを完了する前にOAMサーバーを使用して認証および認可サービスを提供します。

Oracle Access Managementコンソール
ポリシー構成
アプリケーション・ドメイン
ドメイン名

12.2.2 ファイル・システム変更および登録されたエージェントのアーティファクトについて

Oracle Access Managementコンソールを使用してエージェントを登録すると、Oracle Access Managementコンソール・ホストに、エージェントのためのファイル・システム・ディレクトリが新規作成されます。

この新しいディレクトリには、表12-5に示すように、登録済エージェント用に生成されたファイルが格納されます。

表12-5 エージェント登録に関連付けられるアーティファクト

登録アーティファクト

生成対象

すべてのWebgateまたはアクセス・クライアント

ObAccessClient.xml

コンソール・ホスト(AdminServer)上のすべてのWebgate/アクセス・クライアント

実行時に定期的な更新確認が行われます。変更が検出されると、ObAccessClientが自動的に更新されます。

注意: 事前登録された10g IAMSuiteAgentは、ブートストラップや構成にObAccessClient.xmlを使用しません。

関連項目: この表のクライアント上で生成されるプロパティ・ファイル。

cwallet.sso

11g Webgateのみ

トランスポート・セキュリティ・モードに関係なく、11g Webgate。

安全な通信のための証明書とパスワード

すべてのWebgate/アクセス・クライアント例:

- password.xml(簡易モードのグローバル・パスフレーズ用に最小限に暗号化されたファイル)

- aaa_cert.pem (Webgate証明書ファイルの予約名。変更できません)

- aaa_key.pem (Webgateキー・ファイルの予約名。変更できません)

証明書モード:

- PEMキーストア別名

- PEMキーストア別名パスワード

注意: 11g Webgateの登録を編集するときに、モードがオープンから証明書、あるいは簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェントのキー・パスワードを編集しても、新しいpassword.xmlは作成されません。

関連項目: 簡易および証明書モードのトランスポート・セキュリティの詳細は、第11章を参照してください。

OpenSSOプロパティ・ファイル

関連項目: 第20章「レガシーOpenSSOエージェントの登録および管理」

osso.confファイル

関連項目: 第21章「レガシーOSSOエージェントの登録および管理」

生成または更新されたアーティファクトは、コンソール・ホスト(AdminServer)からエージェントのインストール・ディレクトリにコピーする必要があります(表12-6を参照)。

表12-6 生成されたアーティファクトのコピー

エージェント・タイプとアーティファクト

生成されたアーティファクトをエージェントのインストール・ディレクトリにコピー

ObAccessClient.xml

(および11g Webgateのcwallet.sso)

11g Webgateまたはアクセス・クライアント

エージェントの起動前に、ObAccessClientファイル(およびcwallet.sso)を、生成された場所(AdminServer (コンソール)ホスト)からエージェントのインストール・ディレクトリにコピーします。

関連項目: 第13章「OAM 11gエージェントの登録および管理」

ObAccessClient.xml

10g Webgateまたはアクセス・クライアント

エージェントの起動前に、ObAccessClient.xmlを、生成された場所からエージェントのインストール・ディレクトリにコピーします。たとえば、次のAdminServer (コンソール)ホストからコピーします:

注意: 事前登録済のIAMSuiteAgentは、ObAccessClient.xmlを使用しないため、変更する必要はありません。

関連項目: 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」

OpenSSOエージェントのプロパティ・ファイル

関連項目: 第20章「レガシーOpenSSOエージェントの登録および管理」

10g OSSOエージェントのosso.conf

関連項目: 第21章「レガシーOSSOエージェントの登録および管理」

12.3 リモート登録の概要

エージェントの登録にコンソールを使用する以外の方法として、Oracle提供のテンプレートとリモート登録ユーティリティのoamregを使用することもできます。リモート登録スクリプトのユーザーは、Access Managerのプライマリ・ユーザー・アイデンティティ・ストア内の管理者のロールに対してマップされるグループに含めることができます(第4章を参照)。

アプリケーション・ドメインのセキュアな登録と作成(および対称鍵の生成)は、表12-7で説明するどちらのリモート登録モードを使用する場合でもサポートされます。

表12-7 リモート登録の方法

方法

説明

帯域内モード

エージェントをホストするWebサーバーを管理するネットワーク内の管理者は、このモードまたはOracle Access Managementコンソールを使用できます。

帯域外モード

ネットワーク外の管理者は、登録リクエストをネットワーク内の管理者に送信する必要があります。リクエストを処理した後、帯域内の管理者は、ファイルを使用して環境を構成する帯域外の管理者に必要なファイルを戻します。

アプリケーションごとの対称鍵の生成: 登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成されて使用されます。ただし、すべての10g Webgateに対して生成されるキーは1つのみです。

注意:

また、レガシー・エージェント(10g Webgate、OpenSSOおよびOSSO 10g)の登録もサポートされています。

表12-8では、サポートされていない機能について説明しています。

表12-8 リモート登録でサポートされない機能

リモート登録でサポートされない機能

キーおよびエージェント情報の永続性

内部コンポーネントで使用されるキーの生成

エージェント情報を読み取るAPIサポート

詳細は、第13章の次の各項を参照してください。

- 帯域内リモート登録の実行について

- 帯域外リモート登録の実行について

- 更新されたエージェント構成ファイルについて

12.3.1 帯域内リモート登録の実行について

次に、リモート登録ツールを使用してアプリケーションをプロビジョニングする際に、帯域内のWebサーバーの管理者が実行するタスクの概要を示します。特に明記しないかぎり、保護するリソースのあるエージェントのタイプに関係なく、タスクの内容は同じです。

この概要の「管理者」という用語は、Oracle Access Managementに登録されるデフォルト・システム・ユーザーのアイデンティティ・ストアの管理者に指定されるLDAPグループの一部であるネットワーク内のユーザーを示します。

タスクの概要: リモート登録を実行する帯域内の管理者

1. 「登録ツールの取得および設定」の説明に従って、登録ツールを取得します。

2. エージェントおよびアプリケーション・ドメインに合せて入力ファイルを一意の値で更新します(「リモート登録リクエストの作成」を参照してください)。

3. 登録ツールを実行してエージェントを構成し、リソースのデフォルトのアプリケーション・ドメインを作成します(「帯域内リモート登録の実行」を参照してください)。

4. 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証およびアクセスの検証」を参照してください)。

12.3.2 帯域外リモート登録の実行について

帯域外登録という用語は、帯域内および帯域外の管理者の両方の調整およびアクションを含む手動登録を示します。

タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)

1. 帯域外の管理者の手順: 特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。

- 「登録ツールの取得および設定」の説明に従って、登録ツールを取得します。

- テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインに一意の値を入力します(「リモート登録リクエストの作成」を参照してください)。

- 選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。

2. 帯域内の管理者の手順:

- 「登録ツールの取得および設定」の説明に従って、登録ツールを取得します。

- 登録ツールで帯域外の開始リクエストを使用してエージェントをプロビジョニングし、次のファイルを作成して帯域外の管理者に戻します。詳細は、「帯域外リモート登録の実行」を参照してください。

- agentName_Response.xmlは帯域外の管理者用に生成され、手順3で使用されます。

- OAMエージェント: 変更されたObAccessClient.xmlファイル(および11g Webgateのcwallet.ssoファイル)が作成されます。このファイルは、帯域外の管理者がWebgateをブートストラップするために使用できます。
11g Webgate: SSOウォレットの作成。

- OSSOエージェント: OSSOモジュールをブートストラップする帯域外の管理者用に変更されたosso.confファイルが作成されます。

- OpenSSOエージェント: 変更されたバージョンのOpenSSOプロパティ・ファイルが生成されます。

3. 帯域外の管理者の手順: agentName_Response.xmlファイルと一緒に登録ツールを使用し、エージェント構成および他の生成されたアーティファクトを適切なファイル・システム・ディレクトリにコピーします。

注意:

outofbandモードで、帯域内の管理者は帯域外の管理者が送信した開始リクエスト・ファイルを使用し、追加処理のために生成されたagentName_Response.xmlファイルを帯域外の管理者に戻します。帯域外の管理者は、エージェント構成ファイルを生成する入力としてagentName_Response.xmlと一緒にリモート登録ツールを実行します。

4. 帯域内の管理者: 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. 帯域外の管理者の手順: いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。

関連項目:

- 「更新されたエージェント構成ファイルについて」

- 「リモート登録ツール、モードおよびプロセスの理解」

12.3.3 更新されたエージェント構成ファイルについて

登録(または更新)に成功したら、AdminServer (コンソール)ホスト上でエージェント構成ファイルを検索し、表12-9の説明に従って、これらをエージェント・ホストにコピーする必要があります。

表12-9 エージェント登録および構成の更新アーティファクト

対象となるアーティファクト

説明

簡易または証明書モード

簡易または証明書モードを使用する場合、登録後、証明書アーティファクトもエージェント・ホストにコピーする必要があります。

関連項目: 付録C「通信の保護」

11g OAMエージェント(Webgate/アクセス・クライアント)

関連項目: 第13章「OAM 11gエージェントの登録および管理」

10g OAMエージェント(Webgate/アクセス・クライアント)

関連項目: 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」

OSSOエージェント

関連項目: 第21章「レガシーOSSOエージェントの登録および管理」

OpenSSOエージェント

関連項目: 第20章「レガシーOpenSSOエージェントの登録および管理」

13 OAM 11gエージェントの登録および管理

この章では、コンソール方式またはリモート登録コマンドライン・ユーティリティを使用して、11g Webgate(およびプログラム的に同じものであるアクセス・クライアント)を登録および管理する方法について説明します。登録時には、Access Managerで保護する特定のアプリケーションを指定できます。

この章の内容は次のとおりです。

- 前提条件

- コンソール内のOAMエージェント登録パラメータの理解

- コンソールを使用したOAMエージェントの登録

- コンソールを使用した登録済OAMエージェントの構成および管理

- リモート登録ツール、モードおよびプロセスの理解

- リモート登録テンプレートの理解: OAMエージェント

- OAMエージェントのリモート登録の実行

- エージェントのリモート更新の概要

- エージェントのリモート更新

- リモート登録およびリソース保護の検証

13.1 前提条件

この章のタスクを実行する前に、Oracle Access Managementコンソールのホスト(AdminServer)と管理対象OAMサーバーが実行中であることを確認してください。

関連項目:

それぞれの環境の必要に応じて、次の項目を参照してください。

- 第12章「エージェントおよび登録の概要」

- 「ポリシーおよびアプリケーション・ドメインのリモート管理」

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- 第21章「レガシーOSSOエージェントの登録および管理」

- 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」

13.2 コンソール内のOAMエージェント登録パラメータの理解

この項では、OAMエージェントの登録パラメータについて説明します。特に明記しないかぎり、ここに示す情報は、11gと10gのWebgate(プログラムのアクセス・クライアントを含む)に同様に適用されます。内容は次のとおりです。

- OAM Webゲートの作成ページとパラメータについて

- ユーザー定義のWebgateパラメータについて

- Webgate用IPアドレスの検証について

13.2.1 OAM Webゲートの作成ページとパラメータについて

OAM ... Webゲートの作成ページでは、簡潔に登録できるように最小限の情報が要求されます。アスタリスク(*)は必須の詳細です。11g Webgateまたは10g Webgateのどちらを登録する場合でも、要求される最初の情報は同じです。

図13-1 「OAM 11G Webゲートの作成」ページ

「図13-1 「OAM 11G Webゲートの作成」ページ」の説明

表13-1は、11g Webgate(またはアクセス・クライアント)の作成ページについて示しています。特に明記しないかぎり、すべての要素が11gおよび10gエージェントの両方に適用されます。

表13-1 11gおよび10g OAMエージェントの作成ページの要素

OAM Webゲートの要素

説明

名前

このエージェント登録を一意に識別できる名前。ほとんどの場合、Webgateに使用されるWebサーバーをホストするコンピュータ名です。

各エージェント登録を一意に識別する名前がお薦めされます。ただし、次のことに注意してください。

- エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければAccess Managerによってポリシーが作成されます。

- ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

ベースURL

オプション

WebgateのWebサーバーがインストールされるコンピュータのホストおよびポート。たとえば、http://example_host:portまたはhttps://example_host:portになります。ポート番号はオプションです。

注意: 特定のベースURLは、一度のみ登録できます。このベースURLからWebgateがインストールされているWebサーバー・ドメイン(ホスト識別子要素で指定)へのマッピングは、1対1です。ただし、1つのドメインが複数のベースURLを持つことができます。

アクセス・クライアント・パスワード

オプション

このWebgateのオプションかつ一意のパスワードで、この登録プロセス中に割り当てられています。

登録されたWebgateがOAMサーバーに接続するときは、認可されていないWebgateがOAMサーバーに接続してポリシー情報を取得しないように、認証にこのパスワードが使用されます。

セキュリティ

エージェントおよび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は生成されません。

注意: 簡易モードと証明書モード、秘密鍵の暗号化の詳細は、付録Cを参照してください。

ホスト識別子

この識別子は、Webサーバー・ホストを表します。ここにはエージェントの「名前」フィールドの値が自動的に入力されます。

注意: 次に示すように、同じアプリケーション・ドメインとポリシーを使用する1つのホスト識別子の下に、複数のOAM Webgate(またはアクセス・クライアント)を登録できます。

1. Webgateを登録するときに、ホスト識別子(ユーザーが名前を選択)を作成し、「ポリシーの自動作成」を有効にすることができます。

2. 手順1と同じホスト識別子を使用して2つ目のWebgateを登録し、「ポリシーの自動作成」ボックスの選択を解除してポリシーが作成されないようにします。

関連項目: 「仮想Webホスティングについて」

ユーザー定義パラメータ

特定のWebgateの動作を有効にするために入力できるパラメータ。

関連項目: 「ユーザー定義のWebgateパラメータについて」

仮想ホスト

複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールした場合は、「仮想ホスト」の横にあるボックスを選択します。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。

関連項目: 「仮想Webホスティングについて」

ポリシーの自動作成

エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。

デフォルト: 有効

登録およびポリシーの共有: 別々のWebサーバーにインストールされた複数のWebgate(またはアクセス・クライアント)は、同じリソースを保護するために1つの登録およびポリシーを共有することができます。この設定は、高可用性フェイルオーバー環境で役立ちます。手順は次のとおりです。

1. Webgate1: 最初のWebgateを登録し、「ポリシーの自動作成」を有効にして、ホスト識別子(任意の名前)とポリシーを生成します。

2. Webgate2: 2つ目のWebgateを登録し、最初のWebgateと同じホスト識別子を指定して、「ポリシーの自動作成」を無効にします。

2つ目のエージェントの登録後、どちらのWebgateも同じホスト識別子とポリシーを使用します。

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の読取りは試行されません。

詳細は、付録Cを参照してください。

リソース・リスト

保護されているリソース(URI)リスト

保護されているアプリケーションのURI: /myapp/loginなど。保護されているアプリケーションの各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。

デフォルト: /**

デフォルトは、複数のディレクトリにまたがるゼロまたは複数の中間レベル内にある任意の文字シーケンスに一致します。

リソースの追加: 各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、保護されているリソース・リストにリソースを追加します。たとえば、/financialを追加すると(また、/myfinancialの追加を繰り返すと)、「ポリシーの自動作成」が選択されている場合は、次のURLが指定したアプリケーション・ドメインのポリシーにシードされます。

/financialから生成されるリソースURL /financial/**
/myfinancialから生成されるリソースURL /myfinancial/**
/**

関連項目: 「リソースのURL、接頭辞、パターンについて」.

パブリック・リソース(URI)リスト

それぞれのパブリック・アプリケーションは、パブリック・リソース・リストの表の新しい行で指定する必要があります。

リソースの追加: 各URIは、パブリック・リソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、パブリック・リソース・リストにリソースを追加します。たとえば、/peopleを追加すると、次のURLがこの部分と、アプリケーション・ドメインに含まれます(「ポリシーの自動作成」が選択されている場合)。

/people

関連項目: 「リソースのURL、接頭辞、パターンについて」.

関連項目:

表13-3「拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素」

Webgate登録を合理化するために、作成操作の実行時に一部の要素は非表示になり、デフォルト値が適用されます。

注意:

Oracle Access Managementコンソールを使用して変更された内容は、アプリケーション・サーバーの再起動なしで反映されます。変更内容は、再構成タイムアウト期間後に、自動的に反映されます。

13.2.2 ユーザー定義のWebgateパラメータについて

サポートされる一部のパラメータは、Webgateの登録ページで直接入力するか、OAMエージェントのリモート登録リクエスト・テンプレートに入力することで、ユーザー定義にできます。表13-2に、サポートされるユーザー定義パラメータを示します。各パラメータに指定できる値は1つのみです。

表13-2 ユーザー定義のWebgateパラメータ

ユーザー定義の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(分)

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

fallbackToContainerPolicy=true

IAMSuiteAgentに使用されます。falseに設定すると、リソースへのユーザー・アクセスが拒否され、HTTPレスポンス・コード403が返されます。

trueに設定すると、リクエストはコンテナまで到達し、コンテナで構成されているポリシー(J2EEの認証/認可に関係する)を使用してユーザーにアクセス権を付与または拒否します。

デフォルト: true

logoutRedirectUrl=

デフォルト = http://OAMServer_host:14200/oam/server/logout

protectWebXmlSecuredPagesOnly=true

IAMSuiteAgentに使用されます。ユーザーが認証されると、後続のすべてのリクエストに対してこのパラメータを使用し、エージェントで着信リクエストの検証が必要かどうかが決定されます。設定によって次のようになります。

false: エージェントは常に着信リクエストを検証します。

true: デフォルト。着信リクエストを検証するかどうか、次のようにエージェントが決定します。

- アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されている場合、エージェントは着信リクエストを検証します。

- アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されていない場合、エージェントは着信リクエストを検証しません。かわりに、リクエストをそのままアプリケーションまで通過させます。

maxAuthorizationResultCacheElems

認可結果キャッシュの最大要素: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。次に例を示します。

maxAuthorizationResultCacheElems=10000

デフォルト = 100000

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

authorizationResultCacheTimeout

認可結果のキャッシュ・タイムアウト: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。次に例を示します。

authorizationResultCacheTimeout=60

時間が指定されていない場合のデフォルトは、15(秒)です。

注意: 認可結果キャッシュのタイムアウトはデフォルトでは設定されません。

キャッシュが有効になっている場合は、最初のリクエスト結果がキャッシュ期間中保持されます。これにより効果が拡大され、遅延時間が短縮します。たとえば、認証ポリシー・レスポンスを設定し、カスタム・セッション属性exmpl:sampleを設定するとします。これに対応する認可ポリシー・レスポンスは、HEADER SESSION_ATTR_EXMPL=sampleとして返されます。ユーザーが、これらのポリシーによって保護されているURLにアクセスした場合、いくつか更新された後のヘッダーを受信することになります。ただし、最初は値が見つからない可能性もあります。

値が0の場合、キャッシュは無効になります。キャッシュが存在しない場合、ヘッダーのレスポンスに入力するために2つのリクエストが実行されます。1つ目のリクエストでは使用するセッション変数を設定し、2つ目でそのセッション変数を使用します。トリガーした認可リクエスト内にはレスポンス値を設定しないことをお薦めします。

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

UniqueCookieNames

WebgateのCookie名の書式を、次のように制御します。

- Legacy: 従来の書式(デフォルトを維持し下位互換性があります): <prefix>_<host>:<port>_<suffix>

- Enabled: UniqueCookieNames書式を有効化します(rfc2109準拠のCookie名制約): <prefix>_<host>:<port>_<suffix>

- Disabled: Cookie名の書式は、<prefix>_<suffix>になります。<host>:<port>および<host>_<port>は、Cookie名に追加されません。

- その他の値は、デフォルトの従来の書式として扱われます: <prefix>_<host>:<port>_<suffix>

11g Webgateのみ

ssoCookie

OAMAuthnCookieのCookieを制御します。

デフォルト:

ssoCookie=httponly

ssoCookie=Secure

次のどちらかの設定で無効化されます。

ssoCookie=disablehttponly

ssoCookie=disableSecure

注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

- 外部資格証明コレクタが有効化された11g Webgateの場合、これらのパラメータはエージェント登録ページで直接設定します。

- DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキーム内のユーザー定義チャレンジ・パラメータを通じて構成します。

関連項目:

表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」

「暗号化Cookieのチャレンジ・パラメータの構成」

「DCC対応の11g Webgateと認証ポリシーの構成」

miscCookies

その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。

デフォルト:

miscCookies=httponly

miscCookies=Secure

次のどちらかの設定で無効化されます。

miscCookies=disablehttponly

miscCookies=disableSecure

注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

- 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページで直接設定します。

- DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは同じ名前のチャレンジ・パラメータを通じて構成します。

関連項目:

表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」

「暗号化Cookieのチャレンジ・パラメータの構成」

「DCC対応の11g Webgateと認証ポリシーの構成」

OAMAuthAuthenticationServiceLocation

11g Webgate非ブラウザ・クライアント機能

非ブラウザ・クライアント機能をアクティブ化し、認証サービスの場所を定義します。

OAMAuthUserAgentPrefix=: user-agent HTTPヘッダー値の接頭辞として機能する接頭辞文字列。

たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。

OAMAuthAuthenticationServiceLocation=https://login.example.com/nbc

このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。

関連項目: 第36.3項「Oracle Access Management Mobile and Socialの管理」

OAMAuthUserAgentPrefix

11g Webgate非ブラウザ・クライアント機能

非ブラウザ・クライアント機能をアクティブ化し、user-agent HTTPヘッダー値の接頭辞として機能する文字列を定義します。

OAMAuthAuthenticationServiceLocation=: NBC認証サービスの完全URL。

たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。

OAMAuthUserAgentPrefix=NBC

このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。

関連項目: 第36.3項「Oracle Access Management Mobile and Socialの管理」

13.2.3 Webgate用IPアドレスの検証について

IPアドレス検証はWebgate固有です。クライアントのIPアドレスが、シングル・サインオン用に生成されたCookieに格納されているIPアドレスと同じであるかどうかを確認します。IPValidationパラメータは、IPアドレスの検証のオンとオフを切り替えます。IPValidationがtrueの場合は、Cookieに格納されているIPアドレスとクライアントのIPアドレスが一致する必要があり、一致しない場合はSSO Cookie (表1-3)が拒否されるため、ユーザーは再認証が必要になります。デフォルトでは、IPValidationはtrueです。

「IPValidation」パラメータは、一部のWebアプリケーションで問題の原因となる場合があります。たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、Cookieを使用したシングル・サインオンの妨げになります。

「IPValidation」パラメータは、一部のWebアプリケーションで問題の原因となる場合があります。たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、Cookieを使用したシングル・サインオンの妨げになります。

注意:

「IPValidationException」パラメータには、この検証プロセスの対象として例外となるIPアドレスをリストします。

「IPValidation」がtrueの場合は、IPアドレスを「IPValidationException」リストと比較できます。そのアドレスが例外リストにある場合、そのアドレスはCookieに格納されたIPアドレスと一致しなくてもよくなります。IPアドレスは、必要な数だけ追加できます。これらのアドレスは、クライアントの実際のIPアドレスであり、SSO Cookieに格納されたIPアドレスではありません。Cookieが例外IPアドレスのいずれかから発行されたものである場合、Access ManagerはSSO Cookieに格納されているアドレスの検証を省略します。たとえば、CookieのIPアドレスがリバース・プロキシ用のアドレスである場合に、「IPValidationException」パラメータのIPアドレスを使用できます。

Webgateと認証時にクライアントIPアドレスを持たないアクセス・クライアントの間のシングル・サインオンを構成する場合は、IP検証オプションを明示的に無効にできます(「IPValidation」をfalseに設定します)。「IPValidation」パラメータをfalseに設定すると、ブラウザまたはクライアントのIPアドレスは、SSO Cookieの構成要素として使用されなくなります。ただし、IP検証は、可能なかぎり有効にしておくことをお薦めします。

13.3 コンソールを使用したOAMエージェントの登録

この手順は、Webゲートまたはプログラム・アクセス・クライアントのどちらにも使用できます。登録手順は同じです。OAMタイプ・エージェントは、デプロイする前に登録できます。有効な管理者の資格証明を持つユーザーは、次のタスクを実行することにより、Oracle Access ManagementコンソールでWebゲートを登録できます。

関連項目:

- コンソール内のOAMエージェント登録パラメータの理解

- 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の「Oracle HTTP Server 11g Webgate for OAMのインストールおよび構成」の章

エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、Webゲート・モードが少なくともOAMサーバー・モードと同じレベル以上のときに動作を継続します。付録Cを参照してください。

前提条件

少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。

OAMエージェントを登録するには

1. Oracle Access Managementコンソールの「ようこそ」ページの「SSOエージェント」パネルで次のいずれかをクリックして、新しいページを開きます。

- 新規OAM 11gエージェント

- 新規OAM 10gエージェント(第22章も参照)

または、「システム構成」タブの「Access Manager」セクションで「SSOエージェント」ノード、「OAMエージェント」ノードを開き、右上隅のどちらかの... Webゲートの作成ボタンをクリックします。

2. OAM ... Webゲートの作成ページで、必須項目(*がついている項目)を入力して、このエージェントを登録します。

3. 保護されているリソース・リスト: この表では、表13-1で説明しているように、このエージェントで保護する個々のリソースのURLを入力します。

4. パブリック・リソース・リスト: この表では、表13-1にあるように、パブリックにする(保護しない)個々のリソースのURLを入力します。

5. ポリシーの自動作成: 選択すると、新しいアプリケーション・ドメインおよびポリシーが作成されます(または選択を解除すると、別のWebゲートと同じホスト識別子を使用して、ポリシーを共有します(表13-1))。

6. 「適用」をクリックして登録を送信します(または変更を適用しないでページを閉じます)。

7. 10g Webgate: 第22章を参照して、次を実行します。

1. プロビジョニングの結果作成されるObaccessclient.xmlファイルは、ここでは無視します。

2. アプリケーション・ドメインにリソースを追加します。

3. それぞれの環境に応じて次の手順を実行します(第22章)。
既存のWebゲート: 第19章「11g Webgateが関与するセッションの集中ログアウトの構成」に進みます。

新規Webゲートの場合: 「Access Manager 11g用の最新の10g Webgateの検索とインストール」に進みます。

置換する場合: 「IAMSuiteAgentの10g Webgateへの置換」に進みます。

8. 次のように、簡易モード・ファイルまたは証明書モード・ファイルを含むアーティファクトをコピー(または同じ仕様でWebゲートをインストールしてからアーティファクトをコピー)します。たとえば、オープン・モード・ファイルには、次が含まれます。

エージェントおよびアーティファクト

アーティファクト

11g Webgate/アクセス・クライアントの場合:

ObAccessClient.xmlとcwallet.sso

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。

10g Webgate/アクセス・クライアントの場合:

ObAccessClient.xml

注意: このタスクを実行する前に第22章を参照してください。

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェント・ホスト

$10gWG_install_dir/oblix/lib/

9. 登録の検証: 次の手順は、「Oracle Access Managementコンソールによるエージェント登録の検証」の手順に似ています。

1. ナビゲーション・ツリーでエージェント名がリストされていることを確認し、必要な場合はナビゲーション・ツリーのツールバーで「リセット」ボタンをクリックします。

2. 登録ページの情報が適切であることを確認します。

3. ポリシーの自動作成: アプリケーション・ドメインが生成されたことと、アプリケーションのホスト識別子が作成されたことを確認します。さらに、アプリケーション・ドメインにリソースが作成されてホスト識別子に関連付けられたことを確認します。

4. 「リモート登録後の認証およびアクセスの検証」の説明に従って、詳細なテストを実行します。

10. デプロイメントのニーズに合せて次の手順に進みます。

- 「コンソールを使用した登録済OAMエージェントの構成および管理」

- 第V部「Access ManagerのSSO、ポリシーおよびテストの管理」

13.4 コンソールを使用した登録済OAMエージェントの構成および管理

この項では、登録済のWebゲートの管理に役立つ次の内容について説明します。

- コンソール内の登録済OAMエージェント構成パラメータの理解

- OAMエージェント登録の検索

- コンソール内のOAMエージェント登録ページの表示または編集

- コンソールを使用したOAMエージェント登録の削除

13.4.1 コンソール内の登録済OAMエージェント構成パラメータの理解

Oracle Access Managementコンソールとリモート登録ユーティリティのどちらを使用してエージェントを登録していても、図13-2に示すように、コンソールで完全なエージェントの構成ページを表示できます。

図13-2 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ

「図13-2 「確認」ウィンドウと、デフォルト値で入力された11g Webgateの拡張ページ」の説明

11gと10gのWebgate登録ページ間には、少しだけ相違点があります。

注意:

エージェントのページにある要素のほとんどは、拡張されたOAMテンプレートでリモート登録ツールを使用して定義する要素と同じです。使用する方法に関係なく、ObAccessClient.xmlにはエージェントの登録または変更後に値が入力されます。

表13-3は、展開された登録の要素を示しています。ここに表示された追加設定は、OAMプロキシにより使用されます。

表13-3 拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素

要素

説明

名前

アクセス・クライアント・パスワード

セキュリティ

ユーザー定義パラメータ

IPの検証

関連項目: 表13-1「11gおよび10g OAMエージェントの作成ページの要素」。

関連項目: 「ユーザー定義のWebgateパラメータについて」

関連項目: 「Webgate用IPアドレスの検証について」

プライマリCookieドメイン

10g Webgateのみ、第22章

このパラメータは、エージェントがデプロイされるWebサーバー・ドメインを記述します。たとえば、example.comなどです。

Cookieドメインを構成して、Webサーバー間のシングル・サインオンを有効にする必要があります。具体的には、シングル・サインオンを構成するWebサーバーに同じプライマリCookieドメイン値を使用する必要があります。Webgateは、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のリソースのリクエスト時に再認証を行う必要があります。

状態

コンソールのみ

この登録が有効か無効かを指定します。

デフォルト = 有効

最大キャッシュ要素

キャッシュに保持される要素の数。キャッシュは次のとおりです。

- 認証スキームに対するリソース: このキャッシュは、リソース(URL)に関する情報を保持します。そのURLが保護されているかどうか、そして保護されている場合は保護に使用されている認証スキームもその情報に含まれます。

- (11g Webgateのみ)認可ポリシーに対するリソース: このキャッシュは、リソースとそれに関連する認可ポリシーに関する情報を保持します。このキャッシュには、特定の認証スキームIDの認証スキーム情報が格納されます。

この設定の値は、これらのキャッシュの要素の最大合計カウントを参照します。

デフォルト = 100000

キャッシュ・タイムアウト(秒)

キャッシュされた情報が使用も参照もされないとき、Webgateのキャッシュ(認証スキームに対するリソース、認証スキーム、11g Webgateのみの認可ポリシーに対するリソース)にその情報が残る時間。

デフォルト = 1800(秒)

トークンの有効期間(秒)

11g Webgateのみ

エージェント・トークン(11g WebgateのOAMAuthnCookieの内容)の有効な最大時間。

デフォルト = 3600(秒)

注意: 10g Webgateの場合、「トークンの有効期間」を設定するには、「Cookieセッション時間」を使用してください。

最大接続数

このWebgateとOAMサーバーで確立できる接続の最大数。この数値は、このエージェントに実際に関連付けられる接続の数以上にする必要があります。

デフォルト = 1

最大セッション時間(時間)

アクティビティに関係なくユーザーの認証セッションが有効な秒単位の最大時間。このセッション時間の終了時に、ユーザーは再認証を要求されます。これは強制ログアウトになります。

デフォルト = 24(時間)

0(ゼロ)を指定すると、このタイムアウト設定が無効になります。

フェイルオーバーしきい値

このWebgateがセカンダリOAMサーバーの接続を開くポイントを表す数値。

デフォルト = 1

たとえば、このフィールドに30と入力して、プライマリOAMサーバーへの接続数が29の場合、このエージェントはセカンダリOAMサーバーへの接続を開きます。

AAAタイムアウトしきい値

OAMサーバーからのレスポンスを待機する数値(秒単位)。このパラメータが設定されると、デフォルトのTCP/IPタイムアウトではなくアプリケーションのTCP/IPタイムアウトとして使用されます。

デフォルト = -1(デフォルトのネットワークのTCP/IPタイムアウトが使用されます)

このパラメータの一般的な値は、30から60秒です。非常に小さい値に設定すると、OAMサーバーからレスポンスを受信する前にソケット接続がクローズし、エラーが生じる可能性があります。

たとえば、Webgateが1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーに通信するように構成されているとします。ネットワークのワイヤーがプライマリOAMサーバーから引き抜かれた場合、WebgateはプライマリOAMサーバーへの接続がないことを知るために、TCP/IPタイムアウトの間だけ待ちます。Webgateは、プライマリOAMサーバーから順に、使用可能なサーバーに対して接続の再確立を試行します。このときも、接続が確立可能かどうかを判断するために、エージェントはTCP/IPタイムアウトの間だけ待機します。確立できない場合は、リストの次のサーバーが試されます。別のOAMサーバー(プライマリまたはセカンダリ)への接続が確立できる場合、リクエストは再ルーティングされます。ただし、これは予想以上に長くかかることがあります。

Webgateは、新しい接続を検索するときには、使用可能なサーバーのリストを、その構成で指定した順序でチェックします。プライマリOAMサーバーが1つとセカンダリOAMサーバーが1つずつ指定されていて、プライマリOAMサーバーの接続がタイムアウトした場合、エージェントはまだプライマリOAMサーバーを先に試します。結果的に、エージェントはOAMサーバー・タイムアウトのしきい値設定の2倍を超える期間だけ、リクエストをOAMサーバーに送信できません。

OAMサーバーがリクエストにサービスを提供するのに、タイムアウトのしきい値よりも長い時間がかかる場合、エージェントはリクエストを放棄して、新しい接続でそのリクエストをやり直します。接続プール設定によっては、接続プールから戻される新しい接続が同じOAMサーバーの接続になる場合があります。また、しきい値で指定された時間よりも、他のOAMサーバーがリクエストの処理に時間がかかることもあります。この場合、エージェントはOAMサーバーが停止するまで、リクエストを引き続き再試行できます。

アイドル・セッション・タイムアウト

10g Webgateのみ、第22章

デフォルト: 3600

リリース7.0.4のWebgateは、独自のアイドル・セッション・タイムアウトのみを強制していました。

10.1.4.0.1 Webgateは、トークンが訪問したすべてのWebgateの中で、最も制限の多いタイムアウト値を強制しました。

10g(10.1.4.3)では、この要素のデフォルトが7.0.4の動作に戻りました。

アイドル・セッション・タイムアウトのロジックを設定する方法:

- leastComponentIdleTimeoutのデフォルト値は、アイドル・セッション・タイムアウトの施行に最も制限されているタイムアウト値を使用するようWebgateに指示します。

- currentComponentIdleTimeoutの値は、アイドル・セッション・タイムアウトの施行に現在のWebgateのタイムアウト値を使用するようWebgateに指示します。

優先ホスト

ユーザーが保護されたWebサーバーにアクセスしようとしたときに、すべてのHTTPリクエストでホスト名がどう表示されるかを指定します。HTTPリクエスト内のホスト名は、ユーザーのHTTPリクエストでどのように定義されたかに関係なく、このフィールドに入力された値に変換されます。

優先ホストの機能によって、ホストの識別子がホスト識別子リストに含まれていない場合に間違って作成される可能性があるセキュリティ・ホールを防止します。ただし、仮想Webホスティングでは使用できません。仮想ホスティングの場合、ホスト識別子の機能を使用する必要があります。

デフォルトは(Webgate登録の)名前です。

ユーザー定義パラメータ

関連項目: 「ユーザー定義のWebgateパラメータについて」および『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

ログアウトURL

10g Webgateおよび11g Webgate

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

Default = [](未設定)

注意: これは、カスタマイズしたローカル・ログアウト・ページから初期ログアウトをトリガーするために使用する、標準の10g Webgate構成パラメータです。これについては、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」の説明を参照してください。

11g Webgateのみのその他のログアウト

11g Webgateのシングル・サインオフの動作については、特定のログアウト要素と値によって、集中ログアウトURL、コールバックURLおよびend_URLへのリダイレクトが自動化されます。

関連項目: 表19-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・コールバックURL

11g Webgateのみ

コールバック時にCookieを削除するoam_logout_successへのURLです。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。次に例を示します。

デフォルト = /oam_logout_success

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。

注意: リモート登録テンプレートでは、このパラメータの名前はlogoutCallbackUrlです(表13-10)。

関連項目: 表19-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・リダイレクトURL

11g Webgateのみ

このパラメータはエージェントの登録完了後に自動的に格納されます。デフォルトでは、これはデフォルト・ポートが14200のOAMサーバー・ホスト名に基づいて決定されます。次に例を示します。

デフォルト = http://OAMServer_host:14200/oam/server/logout

関連項目: 表19-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・ターゲットURL

11g Webgateのみ

この値は、ログアウト中にOPSSアプリケーションがWebgateに渡す問合せパラメータの名称です。問合せパラメータは、ログアウト完了後に移動するページのターゲットURLを指定します。

デフォルト: end_url

注意: end_url値は、jps-config.xmlのparam.logout.targeturlを使用して構成されます。

関連項目: 表19-2「登録後のログアウトの詳細(ObAccessClient.xml)」

スリープ時間(秒)

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項を参照してください。

すべてのcache-response-directiveが許可されます。たとえば、両方のキャッシュ値をパブリックに設定してPDFファイルのダウンロードを許可する必要がある場合があります。

デフォルト: キャッシュなし

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

デバッグ

デバッグは有効または無効にすることができます。

保護されていない場合に拒否

Webgateのみ(アクセス・クライアントを除く)

「保護されていない場合に拒否」は有効にすることをお薦めします。

この要素を有効にすると、ルールまたはポリシーでアクセスが明示的に許可されていないすべてのリソースへのアクセスが拒否されます。WebゲートがOAMサーバーに問い合せる回数を制限できるため、大規模またはアクセスの多いアプリケーション・ドメインのパフォーマンスを向上できます。

- 11g Webgateの場合: 常に有効で変更できません。

- 10g Webgateの場合: 無効にできます。

重要: 「保護されていない場合に拒否」は、「ホスト識別子」および「優先ホスト」をオーバーライドします。「保護されていない場合に拒否」は有効にすることをお薦めします。有効にしない場合、複数のホスト識別子、仮想ホストおよびその他の複雑な構成を持つ大規模なインストールで、セキュリティ・ホールが発生する可能性があります。

管理操作の許可

このエージェント権限機能で、次のようなエージェントごとのセッション操作のプロビジョニングを有効にできます。

- セッションの停止

- セッションの列挙

- 既存のセッションに対する属性の追加または更新

- 特定のセッションIDまたは読取りセッションのすべての属性のリスト

デフォルト: 無効

注意: セッション管理の操作は、権限のあるエージェントのみが起動できます。このパラメータを有効にすると、セッション管理のリクエスト(上のリスト)がOAMサーバーによって処理されます。無効にすると、エージェントに対してこのリクエストは拒否されます。

11g Webgateのみ

資格証明コレクタ操作の許可

11.1.2以降のWebゲートのみ

シンプル・フォーム認証または動的な複数要因による認証のために、Webgateのデタッチされた資格証明コレクタ機能を有効にします。

デフォルト: 無効

関連項目: 「DCC対応の11g Webgateと認証ポリシーの構成」。

Sharepoint偽装ユーザー

10g Webgateのみ、第22章

Active Directoryでの、偽装用の信頼できるユーザー。このユーザーは偽装以外の目的では使用できません。制約は、Active Directory内の他のユーザーと同じです。

注意: SharePoint偽装は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』で説明するように、Access Managerユーザー偽装とはまったく異なります。

Sharepoint偽装パスワード

10g Webgateのみ、第22章

偽装用の信頼できるユーザー・パスワード。制約は、Active Directory内の他のユーザー・パスワードと同じです。

信頼できるユーザーには強力な権限が付与されるので、非常に複雑なパスワードを選択することをお薦めします。さらに、「パスワードの有効期限なし」ボックスも選択します。偽装モジュールは、信頼できるユーザー・アカウントを表示する唯一のエンティティでなければなりません。パスワードの有効期限が切れたことを外部エージェンシが検出するのは非常に困難です。

プライマリ・サーバー・リスト

このエージェントのプライマリ・サーバー・リストを識別します。デフォルトは、OAMサーバーに基づきます。

- サーバー名

- ホスト名

- ホスト・ポート

- 最大数(このWebgateがOAMサーバーと確立する最大接続数。WebgateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。

セカンダリ・サーバー・リスト

このエージェントのセカンダリOAMサーバーの詳細を識別します。手動で指定する必要があります。

- サーバー名

- ホスト名

- ホスト・ポート

- 最大数(このWebgateがOAMサーバーと確立する最大接続数。WebgateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。

13.4.2 OAMエージェント登録の検索

図13-3に、Webゲートの「検索」コントロール(デフォルト)と、空の「検索結果」表を示します。このページでは、新しい11g Webgate登録または10g Webgate登録を作成したり、特定のWebgateまたはWebgateのグループ(たとえば、すべての11g Webgate)を検索したりできます。

図13-3 Webゲートの「検索」コントロールと各作成ボタン

「図13-3 Webゲートの「検索」コントロールと各作成ボタン」の説明

正確な名前がわからない場合には、検索文字列にワイルドカード(*)を使用できます。「検索結果」表で名前を選択すると、登録ページが開いて表示または編集が可能になります。

このページで使用できるコントロールは、表13-4のとおりです。

表13-4 OAMエージェントの「検索」コントロール

コントロール

説明

11g Webゲートの作成

クリックすると、新規11g Webゲートの登録ページが開きます。

10g Webゲートの作成

クリックすると、新規10g Webgateの登録ページが開きます。第22章「Access Manager 11gを使用する10g Webgateの登録および管理」を参照してください。

名前

登録ページで定義されているとおりの名前(または名前の一部とワイルドカード(*))を入力します。たとえば「a*」と入力すると、結果表で「Agent_WebGate_AccessDebugNew」が返されます。

バージョン

Webゲートのバージョンを選択して、検索と結果を絞り込みます。

- 11g

- 10g

優先ホスト

HTTPリクエストで使用されるとおりのホスト名の全体(または一部とワイルドカード(*))を入力します。たとえば「iam*」と入力すると、結果表で「IAMSuiteAgent」が返されます。

状態

Webゲートの状態を選択して、検索結果を絞り込みます。

- 有効

- 無効

プライマリ・サーバー

プライマリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。

セカンダリ・サーバー

セカンダリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。

前提条件

OAMエージェントは、Access Managerの登録済エージェントであることが必要です。

OAMエージェント登録を検索するには

1. 「システム構成」タブで、「Access Manager」セクションに進みます。

2. 「SSOエージェント」ノードを展開し、「OAMエージェント」ノードをダブルクリックします。

3. 検索対象に応じた手順を実行します。

- 有効なすべて: 「バージョン」で「すべて」、「状態」で「すべて」を選択し、「検索」ボタンをクリックします。

- エージェント・バージョン: 「エージェントのバージョン」リストで10gまたは11gを選択し、「検索」ボタンをクリックします。

- エージェント名: 検索するインスタンスの正確な名前をテキスト・フィールドに入力し、「検索」ボタンをクリックします。次に例を示します。

my_OAM_Agent

4. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集または表示: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: 「コンソールを使用したOAMエージェント登録の削除」に進みます。

- 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

5. 完了したら変更を適用します(またはページを閉じます)。

13.4.3 コンソール内のOAMエージェント登録ページの表示または編集

この手順は、Webゲートとアクセス・クライアント登録のどちらを編集する場合でも同じです。有効な管理者の資格証明を持つユーザーは、次の手順で説明するとおり、Oracle Access Managementコンソールを使用して、登録済のWebゲートおよびプログラム・アクセス・クライアントのあらゆる設定を変更できます。たとえば、タイムアウトのしきい値やOAMプロキシで使用される他の設定を変更する場合などです。

変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをWebゲートの構成領域にコピーする必要はありません。

注意:

Oracle Access Managementコンソールを使用して変更された内容は、アプリケーション・サーバーの再起動なしで反映されます。変更内容は、再構成タイムアウト期間後に、自動的に反映されます。

また、次の点にも注意が必要です。

アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にのみ、Webゲートのディレクトリ・パスにコピーする必要があります。

注意:

アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にのみ、Webゲートのディレクトリ・パスにコピーする必要があります。

前提条件

エージェントがOracle Access Managementコンソールに登録されて、使用可能であることが必要です。

関連項目:

- OAM Webゲートの作成ページとパラメータについて

登録済OAMエージェントの詳細を表示または変更するには

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。

1. 「OAMエージェント」ノードをダブルクリックして、「検索」ページを表示します。

2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

3. 結果表でエージェント名をクリックし、ページを開きます。

2. 必要に応じて、エージェントの詳細とプライマリ・サーバーまたはセカンダリ・サーバーの詳細を変更します(表13-1、表13-3)。

3. ユーザー定義パラメータ: 必要に応じて追加または変更します(表13-2)。

4. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

5. 次のように、簡易モード・ファイルまたは証明書モード・ファイルを含むアーティファクトをコピー(または同じ仕様でWebゲートをインストールしてからアーティファクトをコピー)します。たとえば、オープン・モード・ファイルには、次が含まれます。

エージェントおよびアーティファクト

アーティファクト

11g Webgate/アクセス・クライアントの場合:

ObAccessClient.xmlとcwallet.sso

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先のエージェント・ホスト: $11gWG_install_dir/webgate/config。

10g Webgate/アクセス・クライアントの場合:

ObAccessClient.xml

注意: このタスクを実行する前に第22章を参照してください。

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェント・ホスト

$10gWG_install_dir/oblix/lib/ObAccessClient.xml

6. デプロイメントのニーズに合せて次の手順に進みます。
第V部「Access ManagerのSSO、ポリシーおよびテストの管理」

13.4.4 コンソールを使用したOAMエージェント登録の削除

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access Managementコンソールにより登録されたWebgateまたはアクセス・クライアントを削除できます。

注意:

エージェントの登録を削除すると、登録のみが削除されます(関連付けられているホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント自身は削除されません)。

関連項目:

- コンソール内のOAMエージェント登録パラメータの理解

前提条件

このエージェントに関連付けられているアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていること(または削除可能されていること)を確認します。

Webゲートまたはアクセス・クライアントの登録を削除するには:

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。

1. 「OAMエージェント」ノードを開いて、「検索」ページを表示します。

2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

3. 結果表から目的の登録を選択して開き、削除するエージェントであることを確認して、ページを閉じます。

4. 結果表で名前を選択して「削除」(X)ボタンをクリックし、「確認」ダイアログで確認して、ページを閉じます。

5. エージェント名がナビゲーション・ツリーにないことを確認します。

2. エージェント・インスタンスの削除: 次の手順を実行します(必要があれば「Access Manager 11gデプロイメントからの10g Webgateの削除」を参照)。

1. Webサーバーを停止します。

2. 次のディレクトリ・パスに用意されているユーティリティを使用して、Webゲート・ソフトウェアを削除します。
$Webgate_install_dir/oui/bin

Windows: setup.exe -d
Unix: runInstaller -d

3. Webゲートのアップデート前のhttpd.confバージョンに戻します。次に例を示します。
コピー内容: httpd.conf.ORIG

コピー先: httpd.conf

4. Webサーバーを再起動します。

5. エージェントのホストで、Webgateインスタンス・ディレクトリを手動で削除します。
11g Webgate/アクセス・クライアント: 11gWebgate_instance_dir/webgate/config.

10g Webgate/アクセス・クライアント:  $Webgate_install_dir/oblix/lib/

13.5 リモート登録ツール、モードおよびプロセスの理解

エージェントの登録にコンソールを使用する以外の方法として、Oracle提供のテンプレートとリモート登録ユーティリティのoamregを使用することもできます。Oracle Access Managementコンソールまたはリモート登録ユーティリティを使用する管理者は、システム・ストアに資格証明を格納しておく必要があります(第4章)。

この項では、リモート登録について詳細に説明します。この項の内容は、次のとおりです。

- リモート登録コマンドの引数とモードについて

- リモート登録リクエスト・テンプレート内の共通要素

- キーの使用、生成、プロビジョニングおよび格納について

関連項目:

「リモート登録の概要」

13.5.1 リモート登録コマンドの引数とモードについて

リモート登録ツールを使用する前に、表13-5のサンプルに示すように、スクリプト内の2つの環境変数を設定する必要があります。このサンプルでは、ツールの場所はLinuxシステム上の$OAM_REG_HOMEだと想定されています。環境によっては異なることがあります。

表13-5 oamreg内で設定する環境変数

環境変数

説明

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を参照する必要があります。

さらに、リモート登録ツールを使用する前に、リクエスト・ファイル内の複数のタグを変更する必要があります(表13-9を参照)。

リモート登録コマンドの引数

表13-6に、リモート登録スクリプトの実行に必要な引数を示します。

表13-6 リモート登録コマンドの引数: モード

引数

説明

モード

次のいずれかを適用します。

- inband

- outofband

input/filename.xml

入力ファイル(*request.xmlまたはagentName_Response.xml)への絶対パス、またはOAM_REG_HOMEの値に対する相対パス。

推奨される場所は、$OAM_REG_HOME/inputです。

リモート登録のサンプル・コマンド

サンプル・コマンドを表13-7に示します。このコマンドでは、ツールの場所をLinuxシステムの$OAM_REG_HOMEと想定しています。

表13-7 リモート登録コマンドのサンプル

コマンド・タイプ

サンプル(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

関連項目: 「エージェントのリモート更新」

注意:

スクリプトの起動後、管理者はユーザー名およびパスワードを求められます(表13-7で説明した-nopromptを使用する場合を除く)。

スクリプトの実行後、成功または失敗のメッセージが通知されます。登録または更新が成功したら、「更新されたエージェント構成ファイルについて」の説明に従って、アーティファクトをエージェント・ホストにコピーする必要があります。

13.5.2 リモート登録リクエスト・テンプレート内の共通要素

表13-8に、エージェント・タイプにかかわらず、すべてのリモート登録リクエスト・ファイル内で共通するグローバルな要素を示します。

注意:

表13-8では、各要素の説明を省略しています。表13-1を参照してください。

表13-8 リモート登録リクエストの共通要素

要素

例

<serverAddress>

<serverAddress>http://{oam_admin_ser
ver_host}:{oam_admin_server_port}
</serverAddress>

<agentName>

<agentName>RREG_OAM</agentName>

<hostIdentifier>

<hostIdentifier>RREG_HostId11G
</hostIdentifier>

拡張されたテンプレートのみ

<agentBaseUrl>

<agentBaseUrl>http://{web_server_
host):(web_server_port}
</agentBaseUrl>

<autoCreatePolicy>

<autoCreatePolicy>true
</autoCreatePolicy>

<applicationDomain>

<applicationDomain>RREG_OAM11G
</applicationDomain>

<virtualhost>

<virtualhost>false<virtualhost>

13.5.3 キーの使用、生成、プロビジョニング、およびストレージについて

登録方式(Oracle Access Managementコンソールおよびリモート登録)にかかわらず、各登録エージェントに対称キーがあります。

mod_ossoまたはOAMエージェントの保護の有無に関係なく、各アプリケーションに対称キーがあります。登録ツールにより、このキーが生成されます。必要に応じて取得できるように、アプリケーションのマッピング、キーおよびエージェント・タイプがシステム構成に格納されます。

キーの使用

各11g Webgateエージェントには、エージェントとOAMサーバー間で共有される独自の秘密鍵があります。ある11g Webgateのセキュリティが破られたとしても、その他の11g Webgateには影響しません。概要は次のとおりです。

- ホストベースのWebgate固有のOAMAuthnCookie_<host:port>_<random number>を暗号化/復号化します。

- WebgateおよびOAMサーバー間でリダイレクトされるデータを暗号化/復号化します。

キーの生成

図13-4は、使用方式(Oracle Access Managementコンソールおよびリモート登録)に関係なくエージェントの登録時に自動的に発生するキーの生成プロセスを示しています。エージェントごとに1つの対称キーがあります。

図13-4 キーの生成

「図13-4 キーの生成」の説明

キーのアクセス可能性およびプロビジョニング

エージェント固有の各キーは、クライアント・マシン上の保護されたローカル・ストレージを介して、対応するWebgateからアクセスできる必要があります。暗号化キーは、データ・ストアには格納されません。かわりに、JavaキーストアまたはCSFリポジトリのエントリへの別名が格納され、パートナと信頼管理APIは、リクエストされた時点で実際のキーを取得します。エージェント固有の秘密鍵には、次の特徴があります。

- リモート登録中にプロビジョニングされます(帯域内モードまたは帯域外モード)。

- 各エージェントを一意に識別できるように一意の値が設定されます。

- エージェントにセキュアに配布されます(帯域内モードのワイヤまたは帯域外モードの個別のセキュアなチャネルを使用)。

- SSOウォレットのOracle Secret Storeに保存されます。SSOウォレットの作成は、11g Webgateにのみ適用されます(その他の10g 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のレジストリで保護する必要があります。

13.6 リモート登録テンプレートの理解: OAMエージェント

Oracleでは、エージェントのリモート登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)と一緒に使用するために、短縮版と拡張版の両方の登録リクエスト・テンプレートを提供しています。この項では、主にOAMエージェントのテンプレート(Webゲートおよびアクセス・クライアント)について説明します。

どちらのテンプレート(短縮版または拡張版)を選択した場合でも、11gと10gのOAMエージェントのテンプレート間には、表13-9に示すように少数の相違点があります。これらのテンプレートは、$OAM_REG_HOME/input/に格納されています。

表13-9 OAMエージェント用のリモート登録リクエスト・テンプレート

テンプレート・タイプ

$OAM_REG_HOME/input/内のテンプレート名

簡略(短縮)版

- OAM11GRequest_short.xml (11g Webgate)

- OAMRequest_short.xml (10g Webgate)

拡張(完全)版

- OAM11gRequest.xml (11g Webgate)

- OAMRequest.xml (10g Webgate)

その他のテンプレート

エージェントの更新

ポリシーの作成、ポリシーの更新

帯域外レスポンス

これらの専用タスクおよびテンプレートについては、次を参照してください。

- 「エージェントのリモート更新」

- 「ポリシーおよびアプリケーション・ドメインのリモート管理」

- 「帯域外リモート登録の実行」

注意:

10g Webgateと11g Webgateでほとんど同じですが、使用しているリリースに適切なリクエストをコピーして使用してください。

13.6.1 OAMエージェントのリモート登録用パラメータ

表13-10に、OAMエージェントのリモート登録リクエストに固有の要素を示します。リクエスト・テンプレート内の要素名はOracle Access Managementコンソール内の対応する要素名と少しだけ異なる場合があります。特に明記しないかぎり、ここに記載する情報はすべて、11gおよび10gの両方のWebgate/アクセス・クライアントのリクエストに対して等しく適用されます。保護されているリソース・リスト、パブリック・リソース・リスト、除外されたリソース・リストは、OAMエージェントの短縮版と拡張版の両方のリクエスト・テンプレートに含まれています。

注意:

表13-10では、各要素の説明を省略しています。これらの要素の説明は、表13-3を参照してください。

表13-10 拡張されたOAMエージェントのリモート登録リクエスト内の要素

要素

例

<serverAddress>

<agentName>

<hostIdentifier>

<agentBaseUrl>

<autoCreatePolicy>

<applicationDomain>

<virtualhost>

表13-8「リモート登録リクエストの共通要素」を参照してください。

<hostPortVariationsList>

<hostPortVariationsList>
<host>host1</host>
<port>7777</port>
</hostPortVariations>
<host>host2</host>
<port>7778</port>
</hostPortVariations>
</hostPortVariationsList>

<protectedResourcesList>

<protectedResourcesList>
<resource>/</resource>
</protectedResourcesList>

<publicResourcesList>

<publicResourcesList>
<resource>/public/index.html
</resource>
</publicResourcesList>

<excludedresourcesList>

<excludedresourcesList>
<resource>/excluded/index.html
</resource>
</excludedresourcesList>

<primaryCookieDomain>

10gリクエストのみ

OAMRequest.xml (10g Webgate)では、<hostIdentifier>も優先HTTPホストとして使用されます。

<primaryCookieDomain>{client_domain}
</primaryCookieDomain>

<maxCacheElems>

<maxCacheElems>100000
</maxCacheElems>

<cacheTimeout>

<cacheTimeout>1800</cacheTimeout>

<tokenValidityPeriod>

11gリクエストのみ

<tokenValidityPeriod>3600
</tokenValidityPeriod>

<cookieSessionTime>

10g Webgateのみ、第22章

<cookieSessionTime>3600
</cookieSessionTime>

<maxConnections>

<maxConnections>1</maxConnections>

<maxSessionTime>

<maxSessionTime>24</maxSessionTime>

<idleSessionTimeout>

10g Webgateのみ、第22章

<idleSessionTimeout>3600>
</idleSessionTimeout

<failoverThreshold>

<failoverThreshold>1
</failoverThreshold>

<aaaTimeoutThreshold>-

<aaaTimeoutThreshold>-1
</aaaTimeoutThreshold>

<sleepFor>

<sleepFor>60</sleepFor>

<debug>

<debug>false</debug>

<security>

<security>open</security

<denyOnNotProtected>

<denyOnNotProtected>1
</denyOnNotProtected>

<allowManagementOperations>

<allowManagementOperations>false/<allowManagementOperations>

<cachePragmaHeader>

<cacheControlHeader>

<cachePragmaHeader>no-cache
</cachePragmaHeader>

<cacheControlHeader>no-cache
</cacheControlHeader

<ipValidation>

<ipValidation>0</ipValidation>

<ipValidationExceptions>

<ipValidationExceptions>
<ipAddress>10,11,11,11</ipAddress>
<ipAddress>10,11,11,12</ipAddress>
<ipAddress>10,11,11,13</ipAddress>
</ipValidationExceptions>

<logOutUrls>

<logOutUrls>
<url>/logout1.html</url>
<url>/logout2.html</url>
</logOutUrls>

<logoutCallbackUrl>

11gリクエストのみ

<logoutCallbackUrl>/oam_logout_success
</logoutCallbackUrl>

<logoutTargetUrlParamName>

11gリクエストのみ

<logoutTargetUrlParamName>end_url
</logoutTargetUrlParamName>

ユーザー定義パラメータの名前

例

<userDefinedParameters>
<userDefinedParam>
<name>...</name>
<value>...</value>
</userDefinedParam>

MaxPostDataLength

<userDefinedParameters>
<userDefinedParam>
<name>MaxPostDataLength</name>
<value>750000</value>
</userDefinedParam>

maxSessionTimeUnits

<userDefinedParameters>
<name>maxSessionTimeUnits</name>
<value>hours</value>
</userDefinedParam>

RetainDownstreamPostData

<userDefinedParameters>
<name>RetainDownstreamPostData
</name>
<value>false</value>
</userDefinedParam>

useIISBuiltinAuthentication

<userDefinedParameters>
<name>useIISBuiltinAuthentication
</name>
<value>false</value>
</userDefinedParam>

idleSessionTimeoutLogic

10g Webgateのみ

<userDefinedParameters>
<name>idleSessionTimeoutLogic
</name>
<value>leastComponentIdleTimeout
</value>
</userDefinedParam>

URLInUTF8Format

<userDefinedParameters>

<name>URLInUTF8Format</name>
<value>true</value>
</userDefinedParam>

inactiveReconfigPeriod

共有シークレットは、10g Webgateにのみ適用されます。

構成は、11g Webgateにのみ適用されます。

<userDefinedParameters>
<name>inactiveReconfigPeriod</name>
<value>10</value>
</userDefinedParam>

WaitForFailover

<userDefinedParameters>
<name>WaitForFailover</name>
<value>-1</value>
</userDefinedParam>

proxySSLHeaderVar

<userDefinedParameters>
<name>proxySSLHeaderVar</name>
<value>IS_SSL</value>
</userDefinedParam>

client_request_retry_attempts

<userDefinedParameters>
<name>client_request_retry_attempts </name>
<value>1</value>
</userDefinedParam>

ContentLengthFor401Response

<userDefinedParameters>
<name>ContentLengthFor401Response
</name>
<value>0</value>
</userDefinedParam>

SUN61HttpProtocolVersion

<userDefinedParameters>
<name>SUN61HttpProtocolVersion
</name>
<value>1.0</value>
</userDefinedParam>

impersonationCredentials

<userDefinedParameters>
<name>username:password
</name>
<value>cred</value>
</userDefinedParam>

UseWebgateExtForPassthrough

<userDefinedParameters>
<name>UseWebgateExtForPassthrough
</name>
<value>false</value>
</userDefinedParam>

syncOperationMode

<userDefinedParameters>
<name>syncOperationMode</name>
<value>false</value>
</userDefinedParam>

filterOAMAuthnCookie

11gリクエストのみ

<userDefinedParameters>
<name>filterOAMAuthnCookie</name>
<value>true</value>
</userDefinedParam>

13.7 OAMエージェントのリモート登録の実行

この項では、すべてのエージェント・タイプで同様なリモート登録の実行方法について説明します。この項の内容は、次のとおりです。

- リモート登録ツールの取得および設定

- リモート登録リクエストの作成

- 帯域内リモート登録の実行

- 帯域外リモート登録の実行

13.7.1 リモート登録ツールの取得および設定

oamregクライアント・ツールは、OAMサーバー上でなくても使用できます。oamregのホームをすでに開いている場合は、次の手順を使用することで、oamregスクリプトを入手してオペレーティング・システムに合せて更新できます。

Windowsの場合: oamreg.bat

Linuxの場合: oamreg.sh

注意:

ここで説明するように、最新のバンドル・パッチを適用し、再度RREG.tar.gzを解凍することで、最新のツールとファイルを使用することをお薦めします。

リモート登録には、JAVA_HOMEおよびOAM_REG_HOMの2つの変数が必要です(表13-11を参照してください)。

表13-11 リモート登録に必要な変数

ロケーション

変数

説明

クライアント側

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だと仮定した場合:

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に設定します(表13-11)。

2. OAM_REG_HOMEを、環境変数に基づいてexploded_dir_for_RREG.tar/rregに設定します(クライアント側またはサーバー側、表13-11)。

4. 「リモート登録リクエストの作成」に進みます。

13.7.2 リモート登録リクエストの作成

登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを作成するには、次の手順を使用できます。

前提条件

リモート登録テンプレートの理解: OAMエージェント

登録リクエストを作成するには、次の手順を実行します。

1. 登録するエージェントに必要な*Request*.xml入力ファイルを探します。
どちらのテンプレート(短縮版または拡張版)を選択した場合でも、$OAM_REG_HOME/input/に格納されている11gと10gのエージェントのテンプレート間には少数の相違点があります。次に例を示します。

OAM11GRequest.xml

2. リクエスト・ファイルを新しい名前でコピーします。次に例を示します。
コピー元: OAM11GRequest.xml
コピー先: my11gagent_request.xml

3. 次で説明する詳細を使用して、エージェントおよび保護するリソースの詳細を反映するように、リクエスト・ファイルを変更します。

- 表13-9「OAMエージェント用のリモート登録リクエスト・テンプレート」

- 表13-10「拡張されたOAMエージェントのリモート登録リクエスト内の要素」

4. それぞれの環境に応じて、次のタスクを実行します。

- 帯域内リモート登録の実行

- 帯域外リモート登録の実行

13.7.3 帯域内リモート登録の実行

ネットワーク内のOAM管理者は、すべてのタスクを実行します。この項では、エージェント・タイプに関係なく、帯域内リモート登録を実行する手順を説明します。この例の場合、OAMエージェントは、Linuxシステムで短いリクエストを使用して登録されます。実際のエージェント・タイプ、リクエスト・テンプレートおよび出力ファイルは異なります。

関連項目:

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の「Oracle HTTP Server 11g Webgate for OAMのインストールおよび構成」の章

前提条件

- リモート登録ツールの取得および設定

- リモート登録リクエストの作成

帯域内リモート登録を実行するには、次の手順を実行します。

1. エージェントをホストしているコンピュータで、登録コマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
./bin/oamreg.sh inband input/myagent_request.xml

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
帯域内登録プロセスが正常に完了しました。

固有の構成ファイルの場所が出力フォルダに作成されます。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

4. /rreg/output/AgentName/フォルダにエージェント用に作成されるネイティブ構成ファイルを確認します。

5. 登録の完了: 古い構成ファイルがまだ置換されていない場合、次の手順を実行して置換します。

1. /rreg/output/AgentName/内のアーティファクトをコピーして、エージェント構成を更新します。次に例を示します。
コピー元: AdminServer (コンソール)ホスト

/rreg/output/Agent_Name/ObAccessClient.xmlおよびcwallet.sso

コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1
/config/OHS/ohs1/webgate/config

2. エージェントをホストしているOAMサーバーを再起動します。

6. 「リモート登録の検証」に進みます。

13.7.4 帯域外リモート登録の実行

この項では、ネットワークの外部(および内部)の管理者が連携してエージェントをリモート登録する手順について説明します。

帯域外リモート登録時に、ネットワーク外の管理者は、ネットワーク内の管理者に登録リクエストを送信します。リクエストの処理後、帯域内の管理者は、帯域外の管理者が環境を構成するために必要になる、次のファイルを戻します。

表13-12 帯域内の管理者が帯域外の管理者に戻すファイル

ファイル

説明

agentName_Response.xml

帯域外の管理者に戻され、この管理者が使用します。agentName_Response.xmlを開いたり編集したりしないようにすることをお薦めします。

固有のWebサーバー構成ファイル

帯域外の管理者に戻され、この管理者がWebサーバーを更新するために使用します。

関連項目

「更新されたエージェント構成ファイルについて」

それぞれの管理者が実行する手順は、次のように扱われます。

- 帯域内の管理者: ネットワーク内のWebサーバー管理者が実行するタスクを扱います。

- 帯域外の管理者: ネットワーク外のWebサーバー管理者が実行するタスクを扱います。

関連項目:

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の「Oracle HTTP Server 11g Webgate for OAMのインストールおよび構成」の章

ここでは、LinuxシステムでOAMエージェントを登録する手順を説明します。実際のテンプレートおよび出力ファイルは異なります。

前提条件

リモート登録ツールの取得および設定

関連項目:

第VI部「Access Managerを使用するレガシー・エージェントの登録および使用」(必要な場合)。

帯域外リモート登録を実行するには、次の手順を実行します。

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

2. /rreg/output/AgentNameに生成されるアーティファクトをコピーして、エージェント構成を更新してから、エージェントをホストするOAMサーバーを再起動します。たとえば、ObAccessClient.xmlとcwallet.ssoを次のようにコピーします。
コピー元: AdminServer (コンソール)ホストの/rreg/output/Agent_Name/ObAccessClient.xmlおよびcwallet.sso

コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1
/config/OHS/ohs1/webgate/config

3. 「リモート登録およびリソース保護の検証」に進みます。

13.8 エージェントのリモート更新の概要

管理者が既存のエージェント登録をすばやく更新、検証または削除できるように、複数のリモート管理モードが提供されています。この項の内容は次のとおりです。

- リモート・エージェント更新のモードについて

- リモート11g OAMエージェント更新のテンプレートについて

13.8.1 リモート・エージェント更新のモードについて

表13-13に、リモート・エージェント管理のモードを示します。コマンドのパラメータには、モード、入力*Request.xmlファイル(OAM_REG_HOMEに対する相対パス、入力*Request.xmlファイルの優先ロケーション)が含まれます。

./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value

表13-13 リモート・エージェント更新のモードと入力ファイル

モードおよび入力ファイル

説明および構文

agentUpdateモード

OAM11GUpdateAgentRequest.xml

OAMUpdateAgentRequest.xml

エージェント・タイプに関係なく、管理者が既存のエージェント属性を更新できます。

./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml

関連項目:

OpenSSOUpdateAgentRequest、第20章

OSSOUpdateAgentRequest、第21章

agentValidateモード

入力ファイルは不要です。

エージェントがOracle Access Managerですでにプロビジョニングされているかどうかを検証します。

./bin/oamreg.sh agentValidate agentname

agentDeleteモード

入力ファイルは不要です。

管理者がエージェント登録を削除できます。

./bin/oamreg.sh agentDelete agentname

13.8.2 リモート 11g OAMエージェント更新のテンプレートについて

OAM11GUpdateAgentRequest.xmlを使用して、特定のエージェント更新値をリモート登録ツールのoamregに渡します。更新リクエストと元の登録リクエストの主な違いは、更新リクエストの次の点にあります。

表13-14 相違点: OAMエージェント更新と登録リクエスト

相違点

要素

追加

<ipValidation>

省略

<ipValidationExceptions>

<hostidentifier>

<virtualhost>

<hostportVariations>

<authCreatePolicy>と、アプリケーション・ドメイン関連の要素

<ssoServerVersion>

<idleSessionTimeout>

関連項目:

- 表13-3「拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素」

13.9 エージェントのリモート更新

この項では、エージェント・タイプに関係なく、Access Managerを使用して登録したエージェントに関する次のトピックについて説明します。

- エージェントのリモート更新

- リモート・エージェント検証の実行

- リモート・エージェント削除の実行

13.9.1 エージェントのリモート更新

このトピックでは、エージェント・タイプに関係なく、Access Managerを使用して登録したエージェントを更新する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

関連項目:

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- 第21章「レガシーOSSOエージェントの登録および管理」

- 「10g OAMエージェントのリモート管理」

エージェント登録をリモートで更新する手順

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. 次のいずれかのテンプレートを使用して、更新リクエストを作成します。

- OAM11GUpdateAgentRequest.xml

- OAMUpdateAgentRequest.xml (10g) 第22章

- OSSOUpdateAgentRequest.xml 第21章

- OpenSSOUpdateAgentRequest.xml 第20章

3. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。

./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml

4. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

5. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
agentUpdateプロセスは正常に完了しました。

固有の構成ファイルの場所が出力フォルダに作成されます。

出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

6. エージェント登録を完了します。更新したObAccessClient.xmlとcwallet.ssoをコピーします。
再配置元AdminServer (コンソール)ホスト: /rreg/output/Agent_Name/

コピー先のエージェント・ホスト: $11gWG_install_dir/webgate/config。次に例を示します。

$WebTier_Middleware_Home/Oracle_WT1/instances/instance1/ config/OHS/ohs1/webgate/config

7. このエージェントをホストするOAMサーバーを再起動して、「リモート・エージェント検証の実行」に進みます。

13.9.2 リモート・エージェント検証の実行

このトピックでは、エージェント・タイプに関係なく、エージェント登録を検証する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

エージェント登録をリモートで検証する手順

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェント・ホストで、agentValidateモードで次のコマンドを実行します。次に例を示します。

./bin/oamreg.sh agentValidate agentname

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
AgentValidationプロセスは正常に完了しました。

13.9.3 リモート・エージェント削除の実行

このトピックでは、エージェント・タイプに関係なく、登録されているエージェントを削除する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

エージェント登録をリモートで削除する手順

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。次に例を示します。

./bin/oamreg.sh agentDelete agentname

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージを参照して確認します。

- 成功: 画面のメッセージを確認します。
AgentDeleteプロセスは正常に完了しました。

13.10 リモート登録およびリソース保護の検証

この項の内容は次のとおりです。

- リモート登録の検証

13.10.1 リモート登録の検証

次の手順は、エージェント・タイプに関係なく、エージェントの登録を検証するガイドとして使用できます。Oracle Access Managementコンソールを使用してタスクを実行するには、帯域内の管理者である必要があります。帯域外の管理者は、リモートの認証およびアクセスをテストする必要があります。

このトピックでは、次の手順を説明します。

- Oracle Access Managementコンソールを使用したエージェント登録の検証

- リモート登録後の認証およびアクセスの検証

13.10.1.1 Oracle Access Managementコンソールを使用したエージェント登録の検証

次の手順を使用できるのは、帯域内の管理者のみです。

関連項目:

第17章「リソースを保護してSSOを有効化するポリシーの管理」

エージェントおよびアプリケーション登録を検証するには、次の手順を実行します。

1. Oracle Access Managementコンソールで、エージェントの登録を検証します。

1. Oracle Access Managementコンソールの「システム構成」タブでエージェントの詳細を確認します。

2. 更新したエージェント構成ファイルが、適切な場所に配置されていることを確認します(「OAMエージェントのリモート登録の実行」を参照)。

2. 共有コンポーネントのホスト識別子を検証します。Oracle Access Managementコンソールでホスト識別子が定義されていることを確認します。

3. アプリケーション・ドメインを検証します。「ポリシー構成」タブで、登録されたエージェントに基づいて名付けられた新しいアプリケーション・ドメインがあることを確認します。アプリケーション・ドメインのリソースには、ホスト識別子を関連付ける必要があります。

4. 「リモート登録後の認証およびアクセスの検証」に進みます。

13.10.1.2 リモート登録後の認証およびアクセスの検証

登録後は、AdminServerまたはOAMサーバーを再起動しなくても、適切な認証によって、保護されたリソースにアクセスできる必要があります。帯域内および帯域外のどちらの管理者も、次の手順を使用して、登録およびポリシーが適切であることを検証できます。

ここでの手順は、登録、認証および認可が適切に構成および動作していることを確認するいくつかの方法を示しています。手順は、すべてのエージェント・タイプでほぼ同じです。

登録後に認証およびアクセスを確認するには、次の手順を実行します。

1. 登録されたOAMエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。

http://exampleWebserverHost.sample.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=.example.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 Managementコンソールのリダイレクト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を実行します。

関連項目:

第17章「リソースを保護してSSOを有効化するポリシーの管理」

11. CGIリソース・ヘッダー変数およびCookie: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。

- 新しい認証ポリシーを追加してCommon Gateway Interface(CGI)リソースを保護し、「認証に成功しました」のレスポンスを設定します。

- 新しいポリシーを使用して、リソースを保護します。

- CGIリソースにアクセスします。

- CGIデータ・ダンプでレスポンスに対して構成されたヘッダー値を確認します。

12. エージェントの無効化: WebgateがObAccessClient.xmlで無効な場合、次の手順を実行して、アクセス可能性および認証を検証します(Webgateは、oam-config.xmlから有効な値を選択する必要があります)。

- エージェント状態を無効化します。WebサーバーおよびOAMサーバーを起動します。エージェントによって保護されているアプリケーションにアクセスして、認証を要求されることを確認します。

14 セッションの管理

この章では、Access Managerのセッションの概念および手順について説明します。この章の内容は次のとおりです。

- 前提条件

- セッションおよびセッション管理の概要

- セッションのライフサイクル設定の構成

- アクティブ・セッションの管理

- セッション操作の検証

14.1 前提条件

この章のタスクで必要なことには、次のことが含まれます。

- 「セッションおよびセッション管理の概要」の確認

- 第5章「サーバー登録の管理」の理解

- 第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」の理解

14.2 セッションおよびセッション管理の概要

一般的に、ユーザーがWebサイトにアクセスすることをセッションと呼びます。Access Managerでは、ユーザーはAccess Managerの認証サービスを通じて認証を受け、Access Managerによって保護されているリソースにアクセスする必要があります。作成されたAccess Managerセッションは、認証されているユーザーとクライアントにバインドされます。

Access Managerセッションのライフサイクルは、セッションの作成、更新、アイドルおよび期限切れの状態遷移で構成されています。Access ManagerセッションはOAMサーバー内で保持され、(管理者によって手動で、または自動化されたフローを使用して実行された)特定のセッションのライフサイクルの追跡およびポリシー強制を行います。

Access Managerのセッション管理とは、セッションのライフサイクル要件を管理するプロセス、およびグローバル・ログアウトを有効化するためのセッション・イベントの通知を指します。管理者は、Oracle Access Managementコンソールを使用して、Access Managerセッションのライフサイクル設定を構成できます。

Access Managerのセッション管理エンジン(SME)は、セッション・イベントと通知のコントローラとして動作するSSOエンジンとのインタフェース接続します。SMEサービスは、セッションの自動生成、更新および管理を実現し、管理者がセッション・ライフサイクルを構成し、特定のアクティブ・セッションを検索および削除できるようにします。

注意:

ユーザーは、同じセッションの間、登録されたOAMエージェントとOSSOエージェントの両方に保護されたリソースにアクセスできます。

セッション・データのストレージは、Access Managerをインストールして構成するときに選択する必要があります。クラスタ内のすべてのサーバーには同じストレージ・メカニズムが適用されますが、これはインストール後に変更できます。

セッション・データは、待機時間、可用性、およびリソース消費のバランスを取るために複数の層に保存されます。これには以下のものが含まれます:

- 各管理対象Access Managerサーバーのローカルのメモリー内キャッシュ
このキャッシュには、アクティブ・サーバー・リクエストに使用するセッション・データが格納されます。現在使われていないデータを迅速に排除するために短いTTLが使われます。このキャッシュは、Oracle Coherenceの埋込みテクノロジを使用することで、分散キャッシュのデータ・アクセス待機時間が短縮され、分散キャッシュ(およびデータベース)間でのデータ移動が透過的になります。

- すべての管理対象Access Managerサーバーによって共有される分散メモリー内キャッシュ
このキャッシュには、Oracle Coherenceによる管理のためにシリアル化されたセッション・データが格納されます。Coherenceを使用すれば、エージェントがコンタクトしてセッション関連のアクセス・リクエストを行なうことのできるすべての管理サーバーで、セッション・データを使用することができます。また、Coherenceは実行中のサーバー間でこのデータを複製して、フォールトトレランス性を提供します。分散キャッシュ内のエントリは、TTLではなく、マシンごとに適用される全体的なキャッシュ・メモリ・サイズに基づいて排除されます。

最大キャッシュ・メモリ・サイズに達すると、次のどちらのアクションが取られます:

- セッション・ストアが有効になると、スペースを確保するために分散キャッシュからエントリが排除されます。これらのエントリはデータベース内には存在しており、必要な場合は分散キャッシュに呼び戻すことができます。

- セッション・ストアが有効になっていない場合は、フォールバック・メカニズムとしてローカル・マシン上のフラット・ファイルにエントリが書き込まれます。このファイル内のエントリ数がそのアクティブ・セッション合計数のパーセンテージとともに増えるに従い、パフォーマンスは低下していきます。

注意:

ユーザーがログアウトした時、またはセッションが期限切れとなった時は、メモリ内ストアからセッション・データが自動的に削除されます。詳細は、「セッションのライフサイクルについて」を参照してください。

- Access Managerを使用するには、Access Managerポリシー・データおよび(オプションで) Access Managerセッション・データを保存するデータベースが必要です。このデータベースは、(何十万という同時ログインが行なわれるような)非常に大きなデプロイメントにフォールトトレランス性とスケーラビリティを提供します。Access Manager固有のスキーマを使用して拡張されたデータベース・ポリシーとセッション・データ・ストアを使用する必要があります。
セッション・ストアには、セッション変更ごとに最新のデータが書き込まれます(ステップアップ認証はセッション変更の一例です)。これは非同期で行なわれるので、セッションの作成や更新を伴うリクエストの待機時間に影響しません。セッション・データは不意の電源異常時にも使用できます。

Access Managerセッション・データを保存するには、Access Manager固有のスキーマで拡張されたデータベース・セッション・ストアが必要です。

- Access Manager固有のスキーマを使用してRCUを実行し、ポリシー・ストアおよびセッション・データ・ストアとしてデータベースを設定します。

- Access Managerでデータベース・ポリシー・ストア構成テンプレートを使用して、Access Managerでポリシー・ストアおよびセッション・データ・ストアとしてデータベースを使用できるようにします。

Access Managerは、Oracle Coherenceを使用してデータ・アクセス待機時間の短い分散キャッシュを提供し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細は、「Oracle Coherenceとセッション管理について」を参照してください。

管理者は、セッション・ライフサイクルを構成して、セッションの最大継続時間、ユーザーが再認証を要求される非アクティブ時間、ユーザー当たりの最大アクティブ・セッション数を定義できます。セッションの期限切れを設定すれば、ユーザーのログイン時とログアウト時にのみサーバーから認識できるOSSOエージェント(mod_osso)との相互運用性を有効にすることができます。詳細は、「セッションのライフサイクル設定の構成」を参照してください。

各セッションは固有のものであり、同じユーザーの別のセッションと区別するために、ユーザーIDとセッションIDによって識別されます。管理者は、特定のユーザーもしくはすべてのユーザーの1つまたは複数のアクティブ・セッションを特定して、削除することができます。たとえば、開いているセッションの数が多すぎるユーザーは、管理者に連絡して、新しくセッションを開始できるように自分のセッションの一部またはすべてを削除してもらうことができます。詳細は、「アクティブ・セッションの管理」を参照してください。

Access Managerは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagementコンソールとOAMサーバーの間の状態変更を通信します。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。一部のコンポーネント間にファイアウォールが存在する場合、Coherenceが使用するUDPポートを開いておく必要があります。それ以外の場合、Access Managerは正常に作動しない可能性があります。詳細は、「Coherenceの使用」を参照してください。

14.2.1 Access Managerセッション・セキュリティ

セッション・セキュリティは、サーバー間で時刻を同期させることを含むセキュアなインストールから始まります。インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。

関連項目:

『Oracle Fusion Middleware管理者ガイド』: Oracle Fusion Middlewareコンポーネント間のSSLによるセキュア通信の構成の詳細

この項では、Access Managerセッション・セキュリティについて説明します。

- セキュアHTTPSプロトコル

- Oracle Coherence

- データベースの永続性

14.2.1.1 セキュアHTTPSプロトコル

Access Managerは、プロキシによるIPアドレス・チェックを提供することでセッションの固定化防止に役立ちます。

セッション固定化の防止効果をさらに高めるために、WebgateおよびOAMサーバーの間ではセキュアHTTPSプロトコルを使用してください。

14.2.1.2 Oracle Coherence

メモリー内ではデータは暗号化されませんが、転送時は保護されます。Oracle Coherenceは、様々なサーバーで動作する複数のAccess Managerインスタンス間の通信を処理します。この通信のセキュリティは以下の2つの方法によって確保されます。

- Coherenceが前もってID確認されたホスト間の通信だけをサポートします。
これは一定のIPアドレス範囲として行なうか、特定のホスト名によって行ないます。OAM構成ファイルには、通信に参加するサーバーのエントリが含まれています。起動時にはこの情報がCoherenceに提供され、認可されたサーバーだけが通信に参加するようにします。

- Coherenceは、クラスタ内のすべてのサーバー間で相互認証されたSSLを使用します。インストール時に、適用可能なキーおよび証明書を保持するjceksが作成されます。

詳細についてはOracle Coherenceのドキュメントを参照してください。

14.2.1.3 データベースの永続性

このセッション管理エンジンはデータを暗号化しません。セキュリティ上の懸念がある場合は、Oracle Advanced Securityなどを使用してデータベース内を暗号化します。

14.2.2 セッションのライフサイクルについて

セッションのライフサイクル設定は、Oracle Access Managementコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。

セッションのライフサイクルとは、セッションの開始から終了までのユーザー・アクティビティの期間を指します。セッション・ライフサイクルの状態には以下のものがあります。

- アクティブ: ユーザーがAccess Managerによって認証されるとセッションが開始されます。ユーザーがAccess Managerによって保護されているコンテンツのリクエストを繰り返し、セッションが有効であるかぎり、セッションはアクティブです。

- 非アクティブ: ユーザーがAccess Managerによって保護されているコンテンツにアクセスしない状態が、セッション・ライフサイクル構成の「アイドル・タイムアウト」属性によって定義されている時間を超えて継続すると、セッションは非アクティブになります。

- 期限切れ: セッション持続時間が、「セッションの存続期間」属性によって定義された時間を超えました。

定められた「アイドル・タイムアウト」時間にわたってユーザーが何もしないと、アクティブ・セッションは非アクティブになります。セッション継続時間が定められた「セッションの存続期間」を超えると、そのセッションは期限切れとなります。

セッション管理エンジンは、非アクティブ・セッションのリストを維持します。アクティブ・セッションが非アクティブになるか期限切れになると、ユーザーは再認証をしなければなりません。期限切れとなったセッションのデータは自動的にメモリー内キャッシュ(またはオプションのSMEデータベース)から削除されます。管理者が削除できるのはアクティブ・ユーザー・セッションのデータだけです。

OSSO GITOのサポート: OAMサーバーとともに動作する複数のタイプのエージェント(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 Managementコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。

14.2.3 複数のエージェント・タイプ(OSSOエージェントおよびOAMエージェント)のタイムアウトについて

切断された状態でセッションが稼動しているとしても、アイドル・タイムアウトは適切な形で適用されます(mod_ossoリクエストが実行されてもWebgateによって行われることはなく、サーバーから見るとそのセッションはアイドル・アウトしているように見えます)。

セッション管理エンジンは、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。詳細については「mod_osso Cookie」を参照してください。

OAMサーバーとともに動作する複数のタイプのエージェント(mod_ossoおよびWebgate)でタイムアウトをサポートする特別なケースでは、GITO Cookieが必要です。これが有効になっている時に(editGITOValues WLSTコマンドを使用)ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの、その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。

14.2.4 OpenSSOエージェントについて

セッション管理上は、OpenSSOエージェントはWebgateと同じです。

OpenSSOエージェントは、mod_ossoと異なり、切断状態では動作しません。

14.2.5 Oracle Coherenceとセッション管理について

この項では、メモリー内キャッシュとSMEセッション・データ・ストアとして構成されたデータベースによるセッション管理において、組み込みのOracle Coherenceデータ管理およびキャッシング・サービスを使用する方法を説明します。

注意:

OAMサーバー間で共通のセッション状態を維持するには、Coherenceインフラストラクチャのクラスタ・メンバーをネットワーク接続する必要があります。ネットワーク・コンポーネントに障害が発生した場合もAccess Managerセッション・データの整合性が要求されるデプロイメントには、冗長ネットワーキング・インフラストラクチャを使用することをお薦めします。

Oracle Coherenceは、セッション・データを複製してクラスタ内のすべての管理サーバーに分散します。クライアントはセッション・データの場所を意識せずに処理を行なうことができます。Oracle Coherenceのトラフィックは自動的に暗号化されます。セッション管理エンジンは、必要に応じて他のAccess Managerコンポーネントにセッション・オブジェクトを開示します。データ待機時間を補正してオブジェクトのシリアル化とネットワーク転送を考慮に入れるために、キャッシュは、短命のセッション・オブジェクトを使用時に保持しておくためのニア・キャッシュとして構成されています。

注意:

Oracle Coherenceのトラフィックは自動的に暗号化されます。

Oracle Coherenceはフェイルオーバーとリコンシリエーションも行ないます。たとえば、1つの管理サーバーに障害が発生した場合、Oracle Coherenceは障害発生サーバーのデータを、他の管理サーバー・ホストの分散メモリー内キャッシュへ自動的に分散します。

図14-1は、組込みOracle Coherenceを使用する場合のセッション・データの保存を示します。説明は図の下のリンクをクリックしてください。

注意:

Oracle Access Managementコンソールは、WebLogic AdminServerに存在するアプリケーションです。セッション・データはAdminServerには保存されません。Oracle Access Managementコンソールからセッション管理操作を実行するには、OAMサーバーが稼動している必要があります。

図14-1 セッション・データとOracle Coherenceのロール

「図14-1 セッション・データとOracle Coherenceのロール」の説明

プロセス概要: 認証成功後のSSOセッション・データの保存

1. セッションは、分散メモリー内キャッシュに作成されます。リソースをホストするコンピュータ(この例では管理対象サーバー1)のローカルのメモリー内キャッシュには、そのコピーがあります。セッションは、データベースにも書き込まれます。

2. セッションが変化するたびに、Oracle Coherenceはセッションを更新し、OAMサーバー(この例では管理対象サーバー2)間で分散キャッシュにセッションをレプリケートして分散します。デフォルトでは、変化するたびに、データベースにも書き込まれます。

3. 新しくリソースがリクエストされると、リソースをホストしているコンピュータ(この例では管理対象サーバー3)のローカルのメモリー内キャッシュにセッションが読み込まれます。

14.3 セッションのライフサイクル設定の構成

この項の内容は次のとおりです。

- 共通セッションのライフサイクル設定ページについて

- 共通セッションのライフサイクル設定の表示と変更

14.3.1 共通セッションのライフサイクル設定ページについて

ユーザー・セッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部です。図14-2は、「共通設定」ページの構成可能なライフサイクル属性を示しています。

図14-2 セッション詳細: 「共通設定」ページ

「図14-2 セッション詳細: 「共通設定」ページ」の説明

表14-1に、共通セッションのライフサイクル設定およびそのデフォルトを示します。セッションは切断モードで動作させることができます(たとえばmod_osso)。したがって、セッション規則を確立する構成の変更は、新しいセッションだけに適用されます。変更を直ちに適用する必要がある場合は既存のセッションを終了し、ユーザーには新規則に適合するセッションを新たに作らせることをお薦めします。

表14-1 共通セッション設定

設定

説明

セッションの存続期間(分)

ユーザーの認証セッションがアクティブな状態に維持される分単位の時間。ライフタイムに達すると、そのセッションは期限切れとなります。

デフォルト = 1440分(整数表現の分数で表した24時間)

ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。

注意: 有効期限が切れたセッションは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。

アイドル・タイムアウト(分)

ユーザーの認証セッションが、Access Managerで保護されたリソースにアクセスすることなくアクティブな状態に維持される分単位の時間。これよりも長い時間アイドル状態が続くと、ユーザーは再認証を求められます。

デフォルト = 15分

ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。

非アクティブ・セッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。

注意: 非アクティブ・セッションのセッション・データは、セッションのアイドル・タイムアウトを経過したときに、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。OAMサーバーは、アイドル・タイムアウトを認識して、同じセッションを使用する認証を再開始します。

1ユーザーの最大セッション数

各ユーザーが同時に持つことのできるセッションの数。すべてのユーザーに対する複数セッション制限を構成するには、この設定を使用します。

正の整数が許可されます。

このカウントに"1"を指定すると、特殊モードがアクティブ化されます。ユーザーが別のデバイスを使用してセッションの認証を済ませている(つまり、新しいセッションを作成する)場合、そのユーザーの既存のセッションは削除されます。エラーの報告も、警告の表示もありません。

注意: 数値を大きくしすぎると、パフォーマンスに影響を及ぼし、セキュリティのリスクを招くことになります。ユーザーごとの適切な制限として20未満の数値をお薦めします。それ以外の場合は、パフォーマンスに影響する可能性があります。チューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。

アクティブ・セッションのデータベース永続性が有効

ローカルおよび分散キャッシュに加えて、構成済データベース・セッション・ストアにアクティブ・セッションを永続化します。すべての管理対象サーバーが停止している場合でも、セッションは保持されます。

デフォルト = 有効(選択)

使用する環境でこの必要がない場合、またはデータベースを考慮したサイズでデプロイメントを実行する場合、チェック・ボックスの選択を解除し、すべてのOAMサーバーを再起動してこの機能を無効にします。

14.3.2 共通セッションのライフサイクル設定の表示または変更

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールで次の手順を使用して、共通セッションのライフサイクル設定を変更できます。

関連項目:

共通セッションのライフサイクル設定ページについて

共通セッションのライフサイクル設定を表示または変更する方法

1. 「システム構成」タブから「共通構成」セクションを展開し、「共通設定」をダブルクリックします。

2. 「共通設定」ページで「セッション」セクションを展開します。

3. 必要に応じ、各リストの横にある矢印キーをクリックしてセッションのライフサイクルを増減させます(表14-1)。

- セッションのライフタイム

- アイドル・タイムアウト

- 1ユーザーの最大セッション数

4. ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します。

5. 「適用」をクリックして変更を送信します(または変更を適用せずにページを閉じます)。

6. 終了したらページを閉じます。

7. 「アクティブ・セッションの管理」に進みます。

14.4 アクティブ・セッションの管理

「セッション管理」ページには、管理者がフィルタ条件に基づいて問合せを作成し、検索基準を後で使用するために保存し、検索をさらに絞り込むために問合せフォームにフィールドを追加できる検索コントロールが用意されています。

データベース・ストア構成で、セッションがデータベースには存在するがキャッシュには存在しない場合があります。セッション検索はシステム・タイムスタンプに基づきます。データベースに対して、タイムスタンプよりも先に更新されたセッションの問合せが行われます(書込み遅延を差し引いて)。キャッシュに対しては、このタイムスタンプよりも後に更新されたセッションの問合せが行われます。キャッシュおよびデータベースで検出された結果のデータがマージされます。重複した結果が存在する場合、キャッシュ・データが優先されます。検索操作に詳細パフォーマンス・メトリックが生成されます。

この項では、1ユーザーまたは全ユーザーの1つまたは複数のセッションを特定し、削除する方法を説明します。ここでは、次の情報が提供されます。

- セッション管理ページについて

- アクティブ・セッションの管理

14.4.1 「セッション管理」ページについて

図14-3に、「システム構成」タブの「共通構成」セクションにある「セッション管理」ページを示します。詳細は、図の後に説明します。

図14-3 共通構成: 「セッション管理」ページ

「図14-3 共通構成: 「セッション管理」ページ」の説明

表14-2では、選択したフィルタ条件に基づいて問合せを作成できる「セッション管理」ページおよび検索コントロールについて説明します。

表14-2 セッション管理のコントロールと結果表

名前

説明

すべてのユーザー・セッションを削除

すべてのユーザーのアクティブ・セッションを削除するには、このコマンド・ボタンを選択します。

注意: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

保存済の検索

再使用のために以前保存した検索基準をリストします。検索基準を保存すると次のようなリストが常に使用可能になります。

パーソナライズを選択すると、次のウィンドウで新しい選択を行うことによって保存済検索基準の動作を変更できます。

一致、すべて、任意

検索中に、指定した条件のいずれかに一致させるか、またはすべてに一致させることができます。

注意: リソースがbyAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

ユーザーID

特定のユーザーIDをフィールドに入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。

検索を支援する次のリストが使用可能です。

クライアントIPアドレス

クライアントIPアドレスを入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。ユーザーID検索およびクライアントIPアドレス検索を支援する同じリストが使用可能です。

検索

このボタンをクリックすると、フォームの基準に基づいて検索が開始されます。

リセット

このボタンをクリックすると、フォームのすべての基準がクリアされます。

保存

このボタンをクリックすると、検索基準の再使用を有効にする検索操作が開始されます。次のウィンドウが開きます。

1. 後で選択するときに「保存済の検索」リストに表示する名前を入力します。

2. この検索をデフォルトとして設定します(またはチェック・ボックスの選択を解除します)。

3. この検索が自動的に実行されるように設定します(またはチェック・ボックスの選択を解除します)。

4. 結果のレイアウトを保存します(またはチェック・ボックスの選択を解除します)。

5. 「OK」をクリックします。

フィールドの追加

検索フォームに別のフィールドを追加できます。支援する次のリストが使用可能です。

1. 「フィールドの追加」ボタンをクリックします。

2. リスト内の項目をクリックしてフォームに追加し、「保存」をクリックします。

項目を追加した後、検索を支援するリストが使用可能になります。たとえば、雇用および時間ベースの選択には、次のリストが用意されています。

表示

結果表の上にある「表示」メニューからコマンドを選択して、表を構成します。以下のコマンドを使用できます。

- 列: 表内の特定の詳細を表示または非表示にできる以下のオプションを含むメニューを表示します。

- デタッチ: 結果の表を展開してフルスクリーン表示にします。

- アタッチ: 「セッション管理」ページの表示に戻ります。

- 列の並替え: 結果表のセッション・データを含む列の新しい配列を指定します。

削除

結果表から選択した項目を削除するには、このコマンド・ボタンを選択します。

注意: セッション検索基準が一般的なものである場合(たとえば、ワイルドカード(*)のみを使用する場合など)、大きなセッション・リストからセッションを削除する際に制限があります。セッション検索基準を十分に細分化することによって比較的小さな結果セット(理想的には20以下)を取得することをお薦めします。

付記: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

デタッチ

結果の表を展開してフルページ表示にするには、このボタンをクリックします。

注意: 表がすでにデタッチされてフルページ表示になっている状態で「デタッチ」をクリックすると、「セッション管理」ページに戻ります。

結果表(名前なし)

特定ユーザーのアクティブ・セッションを検索後、表に結果が表示されます。詳細には次が含まれます。

- セッションID: 生成された一意のセッション識別子。

- ユーザーID:

- 偽装:

- 作成時間: セッションが作成された日付と時刻。

- 最終アクセス: セッションに対する最後のアクセスの日付と時刻。

- クライアントIP: 指定したユーザーのIPアドレス。

- IDストア

- インパーソネータ

14.4.2 アクティブ・セッションの管理

有効なOracle Access Management管理者の資格証明を持つユーザーは、次の手順に示す情報を利用して、検索結果表の構成、特定ユーザーのアクティブ・セッションの特定、特定ユーザーの1つ以上のセッションの削除、またはすべてのユーザーのすべてのセッションの削除を実行できます。

リソースがAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

関連項目:

セッション管理ページについて

必要のないステップはスキップしてください。

前提条件

OAMサーバーが実行中でなければなりません。

アクティブ・セッションの特定と管理

1. 「システム構成」タブの「共通構成」セクションから「セッション管理」ノードを開きます。
「ユーザー名」フィールドと結果表を含む「セッション管理」の「検索」ページが表示されます。

2. フィールドの追加: 「フィールドの追加」リストから、目的のフィールド名を選択します(表14-2)。

3. 演算子の選択: 選択した検索フィールドの演算子のリストを開き、目的の関数を選択します。

4. セッションの検索:

1. 目的の問合せフィールドで、基準を入力します(ワイルド・カード(*)の使用は任意)。

2. 「検索」ボタンをクリックして、基準のいずれかまたはすべてに一致するセッションを探します。

3. 結果表を確認します。

4. 必要に応じて繰り返し、検索を絞り込みます。

5. 結果表の構成: 「表示」メニューの機能を使用して、目的の結果表を作成します。

6. セッションの削除:

1. 結果表で、削除する1つ以上のセッションをクリックします。

2. 「削除」(x)ボタンをクリックして選択したセッションを削除します。

3. 「はい」をクリックして選択したセッションの削除を確定します(または「いいえ」をクリックして削除を取り消します)。

4. 必要に応じてユーザーに通知します。

7. すべてのユーザーのセッションの削除:

1. 右上隅にあるすべてのセッションを削除ボタンをクリックします。

2. 確認を求めるメッセージが表示されたら「はい」をクリックします。

8. 終了したら「セッション管理」ページを閉じます。

9. 「セッション操作の検証」に進みます。

14.5 セッション操作の検証

以下の手順を使用してセッション管理操作を検証します。

セッション管理の検証方法

1. 認証:

1. 管理資格証明以外の資格証明を使用して、ブラウザでリソースにアクセスします。

2. 「アクティブ・セッションの管理」の説明に従って、セッションが存在することを検証します。

2. 複数セッション:

1. (Cookieを削除した)2番目のブラウザで同じリソースにアクセスします。

2. 2つのセッションが存在することを検証します。

3. すべてのセッションを削除し(「アクティブ・セッションの管理」の手順7)、アクティブ・セッションが削除されていることを確認します。

4. 再認証の検証:

1. 2番目のブラウザ(手順2)で別のリソースにアクセスして、再認証を要求されることを確認します。

2. そのリソースに必要な資格証明を入力します。

3. セッションが作成されていることを検証します。

5. データベースの検証:

1. すべてのセッションを削除します。

2. データベースに接続し、次の問合せを実行します。

SQL> select * from oam_session

3. 次の結果が得られることを確認します。

no row selected

4. 2番目のブラウザで別のリソースにアクセスします。

5. データベースに接続し、次の問合せを実行します。

SQL> select * from oam_session

6. 次のようなデータが1行表示されることを確認します。

1 rows selected

7. OAM_SESSION_ATTRIBUTESから行を選択して、そのユーザーのデータが存在することを確認します。

第V部

Access ManagerのSSO、ポリシーおよびテストの管理

第V部は、Access Managerを使用したシングル・サインオン(SSO)およびAccess Managerポリシーとログアウトの構成方法の理解に役立つ情報を提供します。シングル・サインオン接続およびポリシーのテストも説明します。

第V部の内容は次のとおりです。

- 第15章「Access Managerを使用したシングル・サインオンの概要」

- 第16章「認証コンポーネントと共有ポリシー・コンポーネントの管理」

- 第17章「リソースを保護してSSOを有効化するポリシーの管理」

- 第18章「アクセス・テスターを使用した接続性とポリシーの検証」

- 第19章「11g Webgateが関与するセッションの集中ログアウトの構成」

15 Access Managerを使用したシングル・サインオンの概要

この章では、Access Managerのシングル・サインオンの要素についての概要と、ポリシーの開発を始める前の基礎知識について説明します。この章の内容は次のとおりです。

- Access Managerのシングル・サインオンの概要

- Access Managerのポリシー・モデルの理解

- アプリケーション・ドメインおよびポリシーの詳細分析

- ポリシーの条件およびルールの概要

- Access Manager資格証明コレクションおよびログインの概要

- SSO Cookieの理解

- シングル・サインオンの構成タスクの概要

注意:

特に明記しないかぎり、この章の情報は、すべてのエージェント・タイプとAccess Manager資格証明コレクタに共通です。

シングル・ログアウトの詳細は、第19章「11g Webgateが関与するセッションの集中ログアウトの構成」を参照してください。

15.1 Access Managerのシングル・サインオンの概要

ログインは、ユーザーの認証および目的のアプリケーションへのアクセスを取得するアクションです。シングル・サインオン(SSO)は、ユーザーが一度の認証で複数の保護されたリソース(Webページやアプリケーション)にアクセスできるようにするプロセスです。SSOはAccess Managerによって実現されます。SSOを使用すると、同一セッションで他のアプリケーションにアクセスする際に、再びログインしたり、別のログインを使用したりする必要がなくなります。

Access Managerは、パートナ・ネットワークのIdentity Federationやサービス指向アーキテクチャ(SOA)のようなSSOアーキテクチャをひとつにまとめます。Access Managerは、複数のプロトコルで一貫したサービスを提供する共通のSSOエンジンを介して、シングル・サインオン(SSO)を提供します。

Oracle Identity Managementインフラストラクチャにより、エンタープライズのアイデンティティを安全に集中管理できるようになります。

- ユーザー・アイデンティティは、ポリシーで参照されているアイデンティティ・ストアに格納されます。

- コンテキスト・データは、ユーザー操作の様々なステージで、OAMサーバーに対して提示する情報またはOAMサーバーによって収集される情報です。そのようなステージには、認証、認可、エンタープライズ・シングル・サインオン、フェデレーション、適応認証、トークン検証、セッション作成などがあります。情報自体は、ユーザーのデバイス・フィンガープリント、IPアドレス、ウイルス対策およびファイアウォール防御、アサーションなどを構成できます。
Access Managerと統合したときにコンテキスト・データ・プロバイダおよびアサーション・プロバイダの役割を果たすコンポーネントには、エンタープライズ・シングル・サインオン、Identity Federation、Oracle Adaptive Access Managerなどがあります。

表15-1に、Access Managerのポリシーをサポートまたは施行するコンポーネントの概要を示します。また、これらのコンポーネントの詳細が説明されている場所を必要に応じて示しています。

注意:

明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。認証タスクをAccess Managerに委任するには、エージェントが依存する相手とともに存在し、Access Managerに登録されている必要があります。エージェントを登録すると、エージェントとAccess Manager SSOとの間で必要な信頼メカニズムが設定されます。

表15-1 概要: SSOのコンポーネント

コンポーネント

説明

アプリケーション

アプリケーションは、認証と認可をAccess Managerに委任して、登録済エージェントからのヘッダーを受け入れます。

注意: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。

- OAMサーバー

- Oracle Access Managementコンソール(WebLogic AdminServerにインストール)

管理者以外のユーザーは、最初に保護されたリソースのURLを入力して、アクセスを取得します。このURLは、SSOログイン・ページを返します。

関連項目: 「Access Manager資格証明コレクションおよびログインの概要」。

管理ユーザーは、URL(https://host:port/oamconsole)を入力してコンソールにアクセスすると、ポリシーを作成できます。ただし、エージェントの登録時にデフォルトのポリシーが自動的に生成されます(第13章を参照)。

関連項目: 第17章「リソースを保護してSSOを有効化するポリシーの管理」。

ポリシー施行エージェント

- OAMエージェント(Webゲートまたはアクセス・クライアント)

- レガシーOSSOエージェント

- レガシーOpenSSOエージェント

関連項目: 第12章「エージェントおよび登録の概要」。

資格証明コレクタおよび通信チャネル

- デフォルトの埋込み資格証明コレクタ(ECC)を使用する認証は、HTTP(HTTPS)チャネルを通じて行われます

- オプションの外部資格証明コレクタ(DCC)を使用する認証は、Oracle Accessプロトコル(OAP)チャネルを通じて行われます

- 認可は、Oracle Accessプロトコル(OAP)チャネルで発生します。

関連項目: 表16-5「DCCとECCの比較」

SSOエンジン

セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。

関連項目: 第14章「セッションの管理」および第19章「11g Webgateが関与するセッションの集中ログアウトの構成」

レガシー・システムをサポートするプロキシ

- OAMプロキシは、レガシー・アクセス・サーバーとしてレガシーAccess Manager実装をサポートします。関連項目:
OAMプロキシの簡易および証明書モードのアクセス・プロトコルの管理のセキュリティ
OAMプロキシ・メトリックとチューニングの概要

- OSSOプロキシは、レガシーOSSOサーバーとしてOSSOエージェントをサポートします。関連項目: 第21章

- Oracleは、OpenSSOエージェントによって保護されているリソースへのリクエストを処理するOpenSSOプロキシを提供しています。関連項目: 第20章

関連項目: 「埋込みプロキシ・サーバーおよび下位互換性について」

アクセス・ポリシー

登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。

注意: 明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。

関連項目: 第17章「リソースを保護してSSOを有効化するポリシーの管理」

ポリシー・ストア

本番環境ではデータベースです(それ以外の場合は、oam-config.xml)。

関連項目: 第4章

暗号化キーおよびキー・ストレージ

登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

関連項目: 表1-3「概要: Access Manager 11.1.2」。

Cookie

関連項目: 「SSO Cookieの理解」。

注意:

Oracle Access Managementコンソールと、WebLogicコンテナにデプロイされたその他のOracle Identity Managementコンソールのシングル・サインオンは、事前登録済のIAMSuiteAgentとコンパニオン・ポリシーを使用して有効化されます。これらのコンソールの保護に、それ以上の構成は必要ありません。

シングル・サインオンは、表15-2に示すように実装できます。この表には、追加情報の参照先が含まれています。

表15-2 SSOの実装の概要

SSOのタイプ

説明

単一のネットワーク・ドメインのSSO

単一のネットワーク・ドメイン(たとえば、example.com)内のリソースに対して、Access Managerのシングル・サインオンを設定できます。これには、単一のネットワーク・ドメイン内にある複数のWebLogic管理ドメインに属するリソースの保護が含まれます。

単一のネットワーク・ドメインのSSOについては、このドキュメントで説明します。

複数のネットワーク・ドメインのSSO

Access Manager 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。

関連項目: 「複数のネットワーク・ドメインのSSO」。

アプリケーションのSSO

アプリケーションのシングル・サインオンを使用すると、Access Managerによって認証されたユーザーは、アプリケーションにアクセスする際に再認証は必要ありません。

関連項目: 「アプリケーションのSSOとAccess Managerについて」

複数のWebLogicサーバー・ドメインSSO

WebLogic Serverインスタンスの基本管理単位をドメインと呼びます。様々なシステム管理者の責任、アプリケーションの境界、またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義することができます。ただし、クラスタ内のすべての管理対象サーバーが同じWebLogic Serverドメインに存在する必要があります。

関連項目: 「複数のWebLogic ServerドメインのSSOについて」

リバース・プロキシSSO

このSSO実装タイプは、わずかな構成の変更でサポートされます。

関連項目: 「リバース・プロキシのSSOについて」

混在リリース・エージェントを使用したSSO

Access Managerは、登録された11gおよび10g OAMエージェント(Webゲートとプログラムのアクセス・クライアント)に加え、レガシーOSSOエージェント(mod_osso 10g)およびレガシーOpenSSOエージェントをシームレスにサポートします。これらは、任意の組合せで使用できます。

15.1.1 複数のネットワーク・ドメインのSSO

Access Managerでは、これは標準機能です。11g Webgateのみを使用している場合、システム内のすべてのCookieはホスト・ベースです。ただし、すべてのドメインを管理する必要があります。一部のドメインが外部のエンティティ(Access Managerのデプロイメントの一部ではないもの)により制御される場合、Identity Federationを使用することをお薦めします。

Access Managerは、ネットワーク間ドメインでの設定不要シングル・サインオンをサポートします。Access Managerのシングル・サインオフ時には、次の処理が実行されます。

- OAMサーバーが設定するSSO Cookieは、ネットワーク・ドメイン全体で機能するホストCookieです。Webgateは、そのスタンドアロン・エージェントCookieを消去し、セッションを消去するためにOAMサーバーにリダイレクトします。

- スタンドアロン・エージェントCookieを使用しない10g Webgateの場合、サーバー側でのみログアウトが行われ、リダイレクトは必要ありません。

- スタンドアロン・エージェントCookieをサポートする11g WebgateとOSSOエージェントの場合、エージェントのログアウト・コールバックURLがパラレルに呼び出されます。セッションでアクセスするエージェントおよび複数のドメインのエージェントは、ブラウザでサポートされる同時接続の数に応じてすべてパラレルにコールされます。

注意:

Access Managerは、Identity Federation 11.1.1よりも前に、独自の複数のネットワーク・ドメインSSO機能を提供しています。これがOracle Access Manager 10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録することによって、このサポートを継続できます。

関連項目:

- 「11g Webgateの集中ログアウト構成」

- Oracle Fusion Middleware Oracle Identity Federation管理者ガイド、11.1.1

15.1.2 アプリケーションのSSOとAccess Managerについて

管理者は、Access Managerを使用して、ユーザーの資格証明が1回検証された後にユーザーが実行する各アプリケーションに提供される信頼網を構築できます。これらの資格証明を使用すると、固有のメカニズムによるユーザーの再認証をアプリケーションで実行する必要がありません。

アプリケーションのシングル・サインオンを使用すると、Access Managerによって認証されたユーザーは、アプリケーションにアクセスする際に再認証は必要ありません。

ユーザーの資格証明を送信する次の2つの方法があります。

- Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。

- ヘッダー変数の使用: エージェントのリクエストで設定され、アプリケーションで参照できるHTTPヘッダー。

注意:

どちらの形式でも、管理者はポリシー内の適切なレスポンスを入力する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。

ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、Access Manager 11gに登録されているエージェントによって保護されているWebサーバーにのみ適用できます。ポリシーに、Access Managerによって保護されていないWebサーバーでホストされているリダイレクトURLが含まれる場合、ヘッダー・レスポンスは適用されません。

たとえば、ユーザーを認証する場合、ポータル索引ページにリダイレクトすることがあります。

http://example.com/authnsuccess.htm

認証に失敗すると、認証アクションによってユーザーがエラー・ページまたは自己登録スクリプトにリダイレクトされる場合があります。

http://example.com/authnfail.htm

15.1.3 複数のWebLogic ServerドメインのSSOについて

Access Managerは、複数の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 Managementコンソールを使用して管理タスクおよび監視タスクを実行する際、ドメインを切り替えることができますが、その際接続する管理サーバーが切り替わります。

複数のドメインを作成した場合、各ドメインは固有のデータベース・スキーマを参照する必要があります。ドメイン間で構成されたリソースまたはサブシステムを共有できません。たとえば、1つのドメインにJDBCデータ・ソースを作成する場合、別のドメインの管理対象サーバーまたはクラスタで使用できません。かわりに、2番目のドメインに類似するデータ・ソースを作成する必要があります。さらに、2つ以上のシステム・リソースに同じ名前を使用できません。

15.1.4 リバース・プロキシのSSOについて

これは、サポート対象の構成ですが、次の注意事項が付随します。

注意事項

シングル・サインオン構成でリバース・プロキシを使用するときには、次のいずれかのタスクを必ず実行してください。そうしていないと、リバース・プロキシはクライアントのIPアドレスを隠します。

- IPvalidationパラメータにfalseを設定します

- または、そのプロキシのIPアドレスをWebゲート登録のIPValidationExceptionsリストに追加します

認証に成功した後、リバース・プロキシが10g Webgate ObSSOCookieをOracle WebLogicに渡さない場合があります。この問題を回避するには:

- Oracle WebLogicでリバース・プロキシを使用するときに、Basic Over LDAPではなくフォーム・ベース認証を使用します。

- 11g Webgateの場合は、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie、デフォルトはtrue)を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。このCookieを渡す必要がある場合は、filterOAMAuthnCookieパラメータにfalseを設定します。

15.2 Access Managerのポリシー・モデルの理解

Access Managerは、Access ManagerとOSSOのポリシー・モデルを抽出して単一のモデルを構成します。この項では、Access Manager 11gのポリシー・モデルの概要を説明します。

図15-1に、Access Manager 11gポリシー・モデルの主な要素である共有ポリシー・コンポーネント、個別のアプリケーション・ドメインおよび外部依存関係を示します。

図15-1 Access Manager 11gのポリシー・モデル

「図15-1 Access Manager 11gのポリシー・モデル」の説明

共有ポリシー・コンポーネント

共有ポリシー・コンポーネントはグローバルであり、1つ以上のアプリケーション・ドメインで使用できます。図15-2に、Access Managerポリシーの共有コンポーネントを示します。

図15-2 Access Managerの共有ポリシー・コンポーネント

「図15-2 Access Managerの共有ポリシー・コンポーネント」の説明

表15-3に、Access Managerポリシーのグローバルな共有コンポーネントの説明を示します。

表15-3 Access Managerのグローバルな共有ポリシー・コンポーネント

コンポーネント

説明

リソース・タイプ

保護するリソースのタイプと関連の動作を定義します。デフォルトのリソース・タイプはHTTPです。ただし、管理者はアプリケーション・ドメイン内の特定のリソースに適用可能なHTTP以外のリソース・タイプを定義できます。

特定のリソース・タイプには、任意の数のリソースが属することが可能です。ただし、1つのポリシーに追加する各リソースは、1つのタイプとして定義されている必要があります。

- HTTP

- wl_authen

- TokenServiceRP

関連項目:

- 第16章: リソース・タイプの管理

- 第34章: TokenServiceRPタイプのリソースの管理

ホスト識別子

ホストに複数の名前を指定できます。OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。

Access Managerでは、使用可能なホストのバリエーションはすべてまとめて格納されます。管理者は、ホストの正規の名前およびユーザーがホストを表現できる他のすべての名前を入力します。リストのアドレスに送信されるリクエストは、公式のホスト名にマップされます。

アプリケーション・ドメインの認証および認可ポリシーは、ホスト識別子に基づいてリソースを保護します。ホスト識別子を使用して実行時にリソースまたはアプリケーションを識別し、設計時にアプリケーション・リソースのポリシーを作成できます。

ホスト識別子は、エージェントの登録中に自動的に生成でき、新しいアプリケーション・ドメインでリソース定義およびデフォルトの認証ポリシーと認可ポリシーをシードするために使用されます。

また、管理者は1つ以上のアプリケーション・ドメインで使用されるホスト識別子の定義を作成できます。

仮想Webホスティング: 単一のサーバーでユニークなサブディレクトリに解決する複数のドメイン名とIPアドレスのサポートを有効にします。同じホストが、複数のNICカード(IPベース)または同じIPに解決する複数の名前(たとえば、abc.comとdef.com)に基づいて、サービスを受ける複数のサイトを持つことができます。

関連項目: 「ホスト識別子について」

認証スキーム

ユーザーの認証に必要なチャレンジ・メカニズム、信頼レベルおよび基礎となる認証モジュールまたはプラグインを定義する名前付きコンポーネント。Access Managerには、複数のデフォルト認証スキームが用意されています。また、管理者は独自のスキーマを定義することもできます。

Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。1つの認証スキームは、複数の認証ポリシーに割り当てることができます。ただし、1つの認証ポリシーには、1つの認証スキームのみ割り当てることができます。

注意: 認証スキームは、グローバルに定義されるため、少人数の管理者が一貫性のあるセキュアな方法で定義できます。

関連項目: 「認証スキームの管理」

認証モジュールおよびプラグイン

認証スキームの最小実行単位です。認証モジュールは、準拠する正確な手順および資格証明にユーザーを要求する方法を決定します。

認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。

認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データを使用して、ユーザーのログイン・ページのCookieやヘッダーを設定することもできます。

複数のプラグインと事前定義済モジュールが用意されています。プラグインは、必要に応じて複数ステップの認証を構成および編成できるため、プラグインの使用をお薦めします。

関連項目:

- ネイティブ認証モジュールの管理

- 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

Access Managerのポリシー・コンポーネント

リソースが明示的にアクセスを許可するポリシーで保護されていない場合、Access Managerのデフォルトの動作として、アクセスが拒否されます。表15-4に、アクセスを許可するように構成できるポリシー・コンポーネントの説明と、詳細の参照先を示します。

関連項目:

「アプリケーション・ドメインおよびポリシーの詳細分析」

表15-4 Access Managerのポリシー・コンポーネント

コンポーネント

説明

アプリケーション・ドメイン

各アプリケーション・ドメインは、各リソースと、それらのリソースにアクセス可能なユーザーを示すために関連付けられたポリシーを格納する論理コンテナを提供します。アプリケーション・ドメインは、エージェントの登録時に自動的に作成されるようにすることも、コンソールを使用して手動で作成することもできます。

関連項目: 「アプリケーション・ドメインおよびポリシーの詳細分析」

リソース定義

定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。

関連項目: 「ポリシーに追加するリソース定義の追加および管理」。

認証ポリシー

1つの認証ポリシーでのみ、アプリケーション・ドメインで定義された各リソースを保護できます。各認証ポリシーには、1つの認証スキームが必要です。

1つの認証ポリシーにより、多くのリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。

関連項目: 「特定のリソースに対する認証ポリシーの定義」

認可ポリシー

1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。認可ポリシーには、成功レスポンスも含めることができます。

1つの認可ポリシーで複数のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。

関連項目: 「特定のリソースに対する認可ポリシーの定義」。

トークン発行ポリシー

生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。

関連項目: 「トークン発行ポリシー・ページについて」。

ポリシー・レスポンス

すべてのポリシー・タイプに使用できます。認証および認可の成功レスポンスをそれぞれのポリシー内で定義して、ポリシー評価後に適用できます。

関連項目: 「SSOのポリシー・レスポンスの概要」。

ルール

認可ポリシーとトークン発行ポリシーのみで利用可能です。

各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。

ルールは、次で説明されている認可条件を参照します。

関連項目:「認可ポリシー・ルールおよび条件の概要」。

条件

認可ポリシーとトークン発行ポリシーのみで利用可能です。

各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。

条件は、ルールの外部で宣言され、ルール内から参照されます。

関連項目:「認可ポリシー・ルールおよび条件の概要」。

15.3 アプリケーション・ドメインおよびポリシーの詳細分析

Access Managerを使用すると、アプリケーション・ドメイン内で定義されているポリシーに基づいて、誰がリソースにアクセスできるかを制御できます。ユーザーは、ブラウザにURLを入力する、アプリケーションを実行する、他のなんらかの外部ビジネス・ロジックをコールするといった方法によって、保護されているリソースにアクセスを試みます。ユーザーが保護されているリソースへのアクセスをリクエストすると、特定のリソースへのアクセスを認可されている認証ユーザーと認可されていない認証ユーザーを選別するポリシーに従って、リクエストが評価されます。

アプリケーション・ドメインは、相互に階層の関係がありません。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。

各アプリケーション・ドメイン内では、アクセスを制御する特定のポリシーによって、特定のリソースが保護対象として識別されます。認証ポリシーおよび認可ポリシーには、成功と評価された場合に適用されるレスポンスが含まれます。このレスポンスは、管理者が構成します。認可ポリシーには、評価の実行方法を定義する条件とルールおよび成功と評価された場合に適用されるレスポンスが含まれます。これらの条件とルールおよびレスポンスは、管理者が構成します。

アプリケーション・ドメインのサイズと数は、管理者が決定します。それを決定するために、必要に応じて、個々のアプリケーション・リソースまたは他の論理グループを使用できます。アプリケーション・ドメインは、エージェント登録時に自動的に作成されます。また、管理者はアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを追加すると、同じエージェントを使用して複数のアプリケーション・ドメインを保護できます。

図15-3に、アプリケーション・ドメイン内のポリシーの詳細およびアプリケーション・ドメインでの共有要素の使用方法を示します。

図15-3 Access Managerポリシーの構造

詳細は、次の各項を参照してください。

- ポリシーに対するリソース定義について

- 認証ポリシーについて

- 認可ポリシーについて

- トークン発行ポリシーについて

15.3.1 ポリシーに対するリソース定義について

リソースという用語は、OAMサーバーに格納されていて、多くのユーザーがアクセスできるドキュメント、エンティティまたは一部のコンテンツを表します。

クライアントは、特定のプロトコル(HTTPやHTTPSなど)を使用してOAMサーバーと通信し、既存のリソース・タイプに該当するリソースをリクエストします。各HTTPリソース・タイプをホスト識別子に関連付ける必要があります。ただし、HTTP以外のリソース・タイプは、(ホスト識別子ではなく)特定の名前に関連付けられます。

Access Managerでは、各リソースを特定のポリシーと関連付けるために、アプリケーション・ドメインのリソース・コンテナ内でリソースとして定義する必要があります。

注意:

アプリケーション・ドメイン内のポリシーに関連付けできるリソースは、リソース・コンテナで定義されているリソースのみです。

詳細は、「Adding and Managing Resource Definitions to be Added to Policies」を参照してください。

注意:

ページの内容の一部を保護するには、Oracle Entitlements Serverの使用をお薦めします。

15.3.2 認証ポリシーについて

管理者は、認証ポリシーを作成して、アプリケーション・ドメイン内の特定のリソースに適用できます。各認証ポリシーで指定する内容は次のとおりです。

- このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。

- ユーザーの認証に使用するチャレンジ・メソッドを提供する認証スキームを指定します。

- このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。

- エージェントが実行する認証後アクションを指定するオプション・レスポンスを定義します。
ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、Oracle Access Manager 10gよりも堅牢性と柔軟性が強化されます。Oracle Access Manager 10gでは、特定の順序でURLにリダイレクトすることでアプリケーションへの(アプリケーション間の)データの経路を提供していました。

ポリシー・レスポンスはオプションです。これらは、管理者が構成する必要があり、アプリケーション・ドメイン内で定義されている特定のリソースに適用する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。

認証ポリシーの評価結果

Access Managerはユーザーを認証するために、このポリシーの認証スキームによって定義されているチャレンジ・メソッドに基づいて、認証資格証明のリクエストをユーザーのブラウザに示します。

ポリシーの評価後に、結果が返され、ユーザーはその結果に基づいてリダイレクトされます。

- 成功(アクセスを許可)の場合、リクエストしたURLにリダイレクトされます。

- 失敗(アクセスを拒否)の場合、汎用エラー・ページにリダイレクトされます。

注意:

ポリシーの評価結果は、ポリシーごとに上書きされます。

関連項目:

- 認証ポリシー・ページについて

- 「実行時のポリシー評価キャッシュの管理」

15.3.3 認可ポリシーについて

認可は、ユーザーにリクエストしたリソースのアクセス権があるかどうかを決定するプロセスです。たとえば、ユーザーは、データを表示したり、ポリシーで保護されているアプリケーション・プログラムを実行したりできます。

管理者は、認可ポリシーを作成して、サブジェクトまたはアイデンティティが特定のリソースにアクセスできる条件を指定できます。リクエストしたリソースは、アプリケーション・ドメインに属している必要があり、特定の認可ポリシー内に含まれている必要があります。

注意:

OracleAS SSO 10gは認可しません。OSSOエージェントは、Access Manager 11g認可ポリシーを使用しません。

各認可ポリシーで指定する内容は次のとおりです。

- このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。

- このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。

- このポリシーおよびリソースに定義されている条件に基づいて、特定の許可ルールまたは拒否ルールを指定します。条件タイプの概要は、表15-5を参照してください。

- 認可後にエージェントが実行するアクションを特定する、オプションのレスポンスを定義します。「SSOのポリシー・レスポンスの概要」を参照してください。

関連項目:

「ポリシーの条件およびルールの概要」

15.3.4 トークン発行ポリシーについて

トークン発行ポリシーは、クライアントのアイデンティティに基づいてリソース(リライイング・パーティ・パートナ)のトークンを発行する際に従うルールを定義します。クライアントは、リクエスタ・パートナまたはエンド・ユーザーのどちらかです。

特に明記しないかぎり、アプリケーション・ドメインおよび認可ポリシーに関する情報は、トークン発行ポリシーにも同様に適用されます。

注意:

ポリシーが自動生成される際は、トークン発行ポリシーは作成されません。トークン発行ポリシー用のコンテナのみが自動生成されます。

トークン発行ポリシーに固有の情報は、次を参照してください。

- 「TokenServiceRPタイプのリソースの管理」

- 「トークン発行ポリシー、条件およびルールの管理」

15.4 ポリシーの条件およびルールの概要

特に明記しないかぎり、ポリシーの条件およびルールに関する情報は、次のポリシーに同様に適用されます。

- 認可ポリシー

- トークン発行ポリシー

条件

条件は、認可ポリシー内およびトークン発行ポリシー内でのみ指定できます。条件は、定義されている条件に基づいてアクセスの許可または拒否を指定するルールと連携させて使用します。表15-5に、使用可能な条件タイプを示します。

表15-5 条件タイプ

タイプ

詳細の参照先

アイデンティティ

認可ポリシー・ルールおよび条件の概要

IP4範囲

IP4範囲条件の定義

一時的

一時的条件の定義

属性

属性条件の定義

True

実質的には「すべて許可」。これを、認証された任意の使用を認める必要がある場合のデフォルト・オプションとして使用することをお薦めします。この場合、認可時に特定の条件が満たされる必要はありません。

これは、Access Managerの前のリリースの「暗黙的な制約の使用」フラグにかわるものです。「暗黙的な制約の使用」フラグも同様に、制約が特に定義されていない場合に、ポリシーの評価を、結果を許可として完了させます。

認可ポリシーおよびトークン発行ポリシーはそれぞれ、1つ以上の条件オブジェクトを含めることができます。ポリシーの条件タイプ1つにつき複数のインスタンスが存在可能です(以前のポリシー・モデルではクラス1つにつき1つのインスタンスのみ存在可能でした)。

条件は、Access Manager 11gの以前の認可制約に似ています。ただし、制約では許可または拒否を指定できますが、条件では指定できません。

ルール

ルールはポリシー・モデルの新しい構造です。各ルールは、ポリシーの全体的な結果を決定する許可指定または拒否指定を定義します。ルールは、さらに、各条件の評価結果を組み合せる方法を定義します。条件はルールで参照され、ルールの外部で宣言されます。

ルール内で、評価結果を次のように組み合せることができます。

- 簡易モード: すべての条件が満たされる場合またはいずれか1つの条件が満たされる場合のどちらかの場合に評価としてtrueを返すことができるコンバイナの値に基づいて組み合された条件名のリストを受け入れます。(以前は、ALLは制約を許可し、ANYは制約を拒否していました。)

- 式モード: ユーザーは、条件名と特殊文字(カンマ「,」、縦線「|」、アンパサンド「&」および感嘆符「!」)を使用して条件を組み合せたブール式を指定できます。

注意:

許可ルールまたは拒否ルールのどちらにも属さない条件が複数存在するポリシーは、有効なポリシーとして処理されます。

条件およびルールの詳細は、第17章を参照してください。

15.5 Access Manager資格証明コレクションおよびログインの概要

この項の内容は次のとおりです。

- Access Manager資格証明コレクションについて

- OAMエージェントとECCを使用するSSOログイン処理について

- OAMエージェントとDCCを使用するログイン処理について

- OSSOエージェント(mod_osso)とECCを使用するSSOログイン処理について

15.5.1 Access Manager資格証明コレクションについて

Access Managerは、認証プロセス時の資格証明コレクションに、2つのメカニズムを提供します。

- デフォルトの埋込み資格証明コレクタ(ECC)は、OAMサーバーとともにインストールされるため、追加のインストールや設定手順なしで使用できます(ただし、グローバル・パスワード・ポリシーを除きます。「グローバル・パスワード・ポリシーの管理」を参照してください)。
ユーザーをポリシー強制点から資格証明コレクタにリダイレクトするメカニズムは、HTTP上のフロント・チャネル・プロトコル専用です。このプロトコルは、現時点では、リクエストのコンテキストと、問合せ文字列に対する認証レスポンスを提供します。

- 11.1.2以降のWebゲートは、オプションの外部資格証明コレクタ(DCC)に切り替えるための1つのスイッチが用意されています。DCCを使用すると、本番環境に強固なセキュリティを提供するネットワーク分離が可能になりますが、いくつかの形式の認証が必要になります。

特に明記しないかぎり、このドキュメントの説明は、ECCの使用を前提にしています。

シングル・サインオンのログイン処理は、ユーザーが有効なユーザーかどうかと、セッション状態がアクティブまたは非アクティブ(初回のユーザーまたはユーザー・セッションの期限が切れている場合)かを決定します。セッション管理サポートでは、セッション・コンテキストおよびユーザー・トークンを検索、保持および消去します。

セルフサービス・プロビジョニング・アプリケーションを使用したログイン

プロビジョニングは、Access Managerのセッションを作成しません。新しいユーザーがセルフサービス・プロビジョニング・アプリケーションを使用してアカウントを作成すると、ユーザーはアプリケーションにアクセスするときにユーザーIDとパスワードを再度求められます。

保護されているアプリケーションはAccess Manager 11gに転送され、Access Manager 11gがユーザーの資格証明をリクエストします。たとえば、Oracle Identity ManagerがAccess Managerで保護されている場合、ユーザー・リクエストは、資格証明の入力をリクエストするAccess Managerにリダイレクトされます。

成功の結果と失敗の結果は、「Access Managerで保護されたリソースへのログイン処理」で説明するとおりです。

Access Managerで保護されたリソースへのログイン処理

ユーザーが保護されたリソースに初めてアクセスすると、リソースの認証スキームと認証レベルに基づいて資格証明が求められます。通常は、ユーザーIDとパスワードが必要になります。

失敗: ユーザーIDまたはパスワードの入力に間違いがあると、認証は失敗します。ユーザーは認証されずに、資格証明を求める別のプロンプトが表示されます。

Oracle Access Manager 11.1.1では、OAMサーバーに埋め込まれた資格証明コレクタのみが使用可能でした(埋込み資格証明コレクタ(ECC))。Access Manager 11.1.2は、デフォルトでECCをサポートします。ただし、Access Managerでは、外部資格証明コレクタ(DCC)として使用するように、11g Webgateを構成することもできます。DCCを有効化したWebゲートは、リソースWebゲートと分離(または組合せ)できます。

DCCは、デフォルトの埋込み資格証明コレクタ(ECC)よりも安全性が高いと考えられます。

ECCとDCCは、どちらもフォームのログイン、エラー、ログインの再試行を含む認証フローを提供します。ECCとDCCは、どちらもSecurIDとサーバー・アフィニティに加え、パスワード・ポリシーの施行を提供します。

ECCとDCCは、資格証明が一度に提出されない場合に、動的、マルチステップ、反復および変数の認証(マルチステップ認証)を提供します。カスタマイズ可能な認証フローには、認証プラグインを含めることができます。この認証プラグインは、そのプラグインとOAMプロキシ、資格証明コレクタ間のコントラクトを持つもの、そのプラグインとログイン・アプリケーション間のコントラクトを持つもの、資格証明コレクタとログイン・アプリケーション間のコントラクトを持つものがあります。

どちらの(または両方の)資格証明コレクタを使用するかを決定するときには、次の事項について検討します。

- 共存: ECCとDCCの共存を許可すると、ECCまたはDCCに対応した構成の認証スキームとポリシーを使用できるようになります。これにより、ECC(たとえば、Oracle Access Managementコンソール)に依存するリソースにフォールバック・メカニズムを使用できるようになります。

- ECCを無効にする: ECCを無効にすると、ECCメカニズム(たとえば、Oracle Access Managementコンソール)に依存するリソースへのアクセスを、完全に禁止することになります。

表15-6に、詳細へのリンクを示します。

表15-6 Access Managerで保護されたリソースへのログイン処理

ログイン処理の項目

次を参照してください。

OAMエージェントとECCの使用

「OAMエージェントとECCを使用するSSOログイン処理について」

OAMエージェントとDCCの使用

「OAMエージェントとDCCを使用するログイン処理について」

OSSOエージェントとECCの使用

「OSSOエージェント(mod_osso)とECCを使用するSSOログイン処理について」

その他のエージェントまたは混在するエージェント・タイプの使用

混在しているエージェント・タイプがサポートされています。各エージェント・タイプの処理は同じです。その他のエージェントタイプについては、次を参照してください。

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- 第21章「レガシーOSSOエージェントの登録および管理」

- 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」

Oracle ADF Securityを使用したアプリケーションのログインおよび自動ログイン

Oracle Platform Security Services(OPSS)は、Oracle WebLogic Serverの内部セキュリティ・フレームワークで構成されます。Oracle WebLogic Serverでは、Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Access Manager 11g SSOと統合して、ユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。

詳細については、付録A「Oracle ADFアプリケーションとAccess Manager SSOの統合」を参照してください。

15.5.2 OAMエージェントとECCを使用するSSOログイン処理について

この項は、OAMエージェント(リソースを保護するリソースWebゲート)にデフォルトの埋込み資格証明コレクタを使用していることを前提にしています。

Access Managerは、顧客が指定した認証方式で各ユーザーを認証してアイデンティティを決定し、ユーザー・アイデンティティ・ストアに格納されている情報を利用します。Access Managerの認証では、いくつかの認証方法と複数の認証レベルをサポートしています。より厳密な認証方式に対応する高いレベルの認証を要求すると、様々な機密度のリソースを保護できます。

ユーザーが保護されているアプリケーションにアクセスしようとすると、Access Managerがリクエストを受け取り、SSO Cookieの有無を確認します。

ユーザーを認証してユーザー・コンテキストおよびトークンを設定した後、Access ManagerはSSO Cookieを設定して、SSOサーバー・キーでCookieを暗号化します(このキーは、SSOエンジンでのみ復号化できます)。

認証の成功および失敗に対して指定されているアクション(Access Manager 11gのレスポンス)に応じて、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を介してユーザー情報が他のアプリケーションに渡されたりします。

認可ポリシーおよび確認結果に基づいて、リクエストした内容へのユーザーのアクセスが許可または拒否されます。ユーザーは、アクセスが拒否されると、別のURL (Webgate登録で管理者が指定)にリダイレクトされます。

図15-4は、ポリシーの評価、ユーザーのアイデンティティの検証、保護されたリソースへのユーザーの認可および保護されたリソースの使用に含まれるプロセスを示しています。この例は、OAMエージェント・フローを示しています。11g Webgate/アクセス・クライアントの場合は、多少異なります。

図15-4 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン

「図15-4 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン」の説明

プロセスの概要: 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン処理

1. ユーザーは、リソースをリクエストします。

2. Webgateは、ポリシー評価のリクエストをAccess Managerに送信します。

3. Access Managerは次を実行します。

- SSO Cookieの有無を確認します。

- ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。

4. Access Managerサーバーは、決定をログに記録して返します。

5. Webgateは、次のように応答します。

1. 保護されていないリソース: リソースがユーザーに提供されます。

2. 保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。

認証ポリシーに基づくログイン・フォームが提供されます。

認証処理が開始されます。

6. ユーザーは資格証明を送信します。

7. Access Managerは、資格証明を検証します。

8. Access Managerはセッションを開始し、次のホストベースCookieを作成します。

- エージェントごとに1つ: 認証に成功した後にOAMサーバーから受け取った認証トークンを使用して11g Webgateによって設定されるOAMAuthnCookie (10g Webgateによって設定されるObSSOCookie)。
注意: 有効なCookieがセッションに必要です。

- OAMサーバーに1つ: OAM_ID

9. Access Managerは、成功または失敗をログに記録します。

10. 資格証明コレクタがWebgateにリダイレクトされ、認可処理が開始されます。

11. Webゲートは、ポリシーの検索、ユーザーのアイデンティティとの比較およびユーザーの認可レベルの決定をAccess Managerに求めます。

12. Access Managerは、ポリシー決定をログに記録し、セッションCookieを確認します。

13. OAMサーバーは認可ポリシーを評価し、結果をキャッシュします。

14. OAMサーバーは、決定をログに記録して戻します。

15. Webgateは、次のように応答します。

- 認可ポリシーでアクセスを許可すると、目的の内容またはアプリケーションがユーザーに提供されます。

- 認可ポリシーによってアクセスが拒否された場合、ユーザーは、管理者が決定した別のURLにリダイレクトされます。

15.5.3 OAMエージェントとDCCを使用するログイン処理について

外部資格証明コレクタとは、デプロイメント内で追加の資格証明コレクション機能を使用するように構成された、Webゲートのことです。DCC Webゲートでもアプリケーションを保護するかどうかによって、2つのデプロイメント・タイプが存在します。

表15-7に、DCCがサポートされるデプロイメントを示します。

表15-7 DCCデプロイメントのサポート

デプロイメント・タイプ

説明

独立したDCCとリソースWebゲート

アプリケーションを保護するWebゲートが、一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。この内容は、次のようになります。

- 2つ以上の11.1.1.5のリソースWebゲート。認証については11.1.2 DCC対応Webゲートにリダイレクトします。

- 10.1.4.3リソースWebゲート。認証については11.1.2 DCC対応Webゲートにリダイレクトします。

ユーザーエージェントとDCCとの間のHTTPSを有効にします(ただし、一部またはすべてのリソースWebゲートとのHTTPSは有効にしません)。

資格証明コレクションがDCC Webゲートに外部化されて一元化されている場合、ユーザーエージェントと他のWebゲートとの接続では、ユーザー資格証明、および他のWebゲートによって保護されているリソースへのアクセスを取得するために使用できるセッション・トークンが伝送されることはありません。これにより、これらのリンクでSSLを使用しないために公開される情報が大幅に減少し、デプロイメントによっては許容可能なトレードオフになります。

- OHSインスタンスの分離: リソースWebゲートと(同じホストまたは別のホスト上の)別のOHSインスタンスに、DCCをインストールします。

- リソースWebゲートの認証スキームのチャレンジ・リダイレクトURLが、DCCをポイントするように定義します。

- リソースWebゲートのlogoutRedirectUrlがDCCログアウト・スクリプト/ページをポイントするように定義します(リソースWebゲートへのログアウト・コールバックは、ログアウト時に呼び出されます)。

関連項目: 図15-5

DCCとリソースWebゲート一体化

構成と処理のオーバーヘッドが最小になる、合理化されたデプロイメントです。

DCC Webゲートは、アプリケーション・リソースを保護するリソースWebゲート(ポリシー強制点)とDCCの両方として機能します。この場合、フロントチャネル・リダイレクションやフロントチャネル処理はありません。

- DCCをリソースWebゲートと同じOHSインスタンス(同じホスト)にインストールします。

- 合理化された構成: チャレンジ・リダイレクトURLは空にします。

- logoutRedirectUrlは必要ありません。また、ログアウト・コールバックは必要ありません。

関連項目: 図15-6

独立したDCCとリソースWebゲート: 図15-5に、DCCを分離したデプロイメントの例を示します。

図15-5 例: リソースWebゲートとDCC Webゲートの分離デプロイメント

このトポロジ(図15-5)は、最大のセキュリティ機密性を備えたシナリオに適した選択肢を示しています。集中資格証明コレクションおよび外部資格証明コレクションの両方が使用されています。アプリケーションを保護するリソースWebゲートは、資格証明コレクションを実行するDCC Webゲートから分離されています。

ユーザーは、公衆回線網から、Access Managerによって保護されているリソースにアクセスします。アプリケーションを保護しているWebゲートは、DMZ内にデプロイされます。DCC WebゲートもDMZ内にデプロイされます。保護されているアプリケーションおよびOAMサーバーのインスタンスは、プライベート・ネットワーク内に配置され、公衆回線網から直接アクセスすることはできません。

DMZ内でDCCを使用すると、サーバー自体への接続に認証済のネットワーク接続のみが許可されます。DCCは、11g Webゲートに利用できるすべてのバックチャネル通信の特性を継承します(Oracle Accessプロトコルを使用するネットワーク接続)。OAPは、次の機能を提供します。

- クライアントとサーバーの間のSSL (オプションでサード・パーティによる署名済証明書を使用)

- クライアントIDおよびパスワードを使用するアプリケーション・レベルの相互認証

- アプリケーション・レベルで多重化された全二重通信をリクエスト

- 組込みの接続ロード・バランシング/フェイルオーバー機能

DCCは、エージェントから認証リクエストを受信すると、DCC Cookieの存在をチェックします。Cookieが存在しない場合、資格証明コレクションが開始され、チェックが行われて、ユーザーが入力した資格証明が検証のために渡されます。

注意:

暗号化は、11gリソースWebゲートからDCCの方向でのみ行われます。10gリソースWebゲートと11g DCCの間の通信はクリアテキストで行われ、チャネルは暗号化されません。

図15-6 DCCとWebゲートの一体化

プロセスの概要: 一体化したDCCとリソースWebゲートによる認証

1. ユーザーが、認証プロセスを開始するリソースへのアクセスをリクエストします。

2. DCCは、フロント・チャネルを通じてログイン・ページにリダイレクトします。

3. ログイン・ページがユーザーに返されます。

4. ユーザーは、資格証明を入力します。この資格証明はアクションURLにポストされます(認証スキームのユーザー定義パラメータについては、表16-22を参照)。

5. 認証には、バック・チャネル(OAP)とOAMプロキシが使用されます。

6. 認証プラグインがアクティブ化されます。

7. プラグインは、追加の資格証明を収集するためのURLへのリダイレクトをリクエストします。

8. プラグインのリクエストは、DCCに返されます。

9. DCCは、そのURLをリダイレクトして、指定された資格証明を要求します。

10. ブラウザは、リダイレクトに従います。

11. 資格証明は、アクションURLにポストされます。

関連項目:

外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

15.5.4 OSSOエージェント(mod_osso)とECCを使用するSSOログイン処理について

登録されたOSSOエージェント(mod_osso)を使用したSSOログイン処理は、Webgateを使用したログイン処理と似ています。ただし、mod_ossoは、Access Manager 11gの認証ポリシーを使用した認証のみを提供します。

注意:

mod_ossoは、固有の認可またはAccess Manager 11gのポリシーを使用した認可をサポートしません。

図15-7は、mod_ossoおよびAccess Manager 11gを使用したログイン処理を示しています。

図15-7 OSSOエージェントとECCを使用したSSOログイン処理

「図15-7 OSSOエージェントとECCを使用したSSOログイン処理」の説明

プロセスの概要: OSSOエージェントとECCを使用したSSOログイン処理

1. ユーザーは、リソースをリクエストします。

2. mod_ossoは、ポリシー評価のリクエストをAccess Managerに転送します。

3. Access Managerは次を実行します。

- SSO Cookieの有無を確認します。

- ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。

4. OAMサーバーは、決定をログに記録して戻します。

5. mod_ossoは、次のように応答します。

1. 保護されていないリソース: リソースがユーザーに提供されます。

2. 保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。

認証ポリシーに基づくログイン・フォームが提供されます。

認証処理が開始されます。

6. ユーザーは資格証明を送信します。

7. ECCは資格証明を検証します。

8. Access Managerはセッションを開始し、認証トークンをアプリケーションに渡して、次のCookieを作成します。

- パートナごとに1つ: OHS_host_port

- OAMサーバーに1つ: OAM_ID

- グローバルな非アクティブ・タイムアウト: ドメインレベルのCookie GITOです。「mod_osso Cookie」を参照してください。

9. Access Managerは、成功または失敗をログに記録します。

10. 資格証明コレクタは、ユーザーの認可にアプリケーションが使用できる単純なヘッダー値を送信するmod_ossoにリダイレクトされます。

11. 認証に成功すると、リソースが提供され、OHS-host-port Cookieが設定されます。

15.6 SSO Cookieの理解

この項では、Access Manager 11gを使用するシングル・サインオンの概要を簡単に説明します。内容は次のとおりです。

- ユーザー・ログイン時のシングル・サインオンCookieについて

- シングル・サインオン・サーバーおよびエージェントCookieについて

15.6.1 ユーザー・ログイン時のシングル・サインオンCookieについて

表15-8は、ユーザー・ログインの実行中に設定または消去できるCookieを示しています。

表15-8 SSO Cookie

ユーザー・ログインで設定されるSSO Cookie

設定元

説明

OAM_ID Cookie

OAMサーバーの埋込み資格証明コレクタ

ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。

関連項目: 「OAM_ID 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によって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。

「10g WebgateのObSSOCookie」を参照してください。

OAM_REQ

OAMサーバーの埋込み資格証明コレクタ

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

「OAM_REQ Cookie」を参照してください。

OAMRequestContext

11g Webgate

11g Webgateによって設定または消去される一時的なCookie。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。

注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

DCCCtxCookie

外部資格証明コレクタ

外部資格証明コレクタ(DCC)の場合は、埋込み資格証明コレクタ(ECC)で作成されるOAM_REQと同様になります。

「DCCCtxCookie」を参照してください。

OHS-host-port

Oracle HTTP Server

Oracle HTTP Server(OHS)でOSSOエージェント(mod_osso)にアクセスする場合のみ設定されます。mod_ossoエージェントおよびOAMサーバーで認識されるキーで保護されます。

注意: このCookieによって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。

「mod_osso Cookie」を参照してください。

GITO Cookie

OAMサーバー

OSSO 10gおよびAccess Manager 11gの間の下位互換性および相互運用性を実現します。このCookieはOAMサーバーによって作成され、OAMサーバーまたはmod_ossoエージェントによってアクセスまたは変更されます。

「mod_osso Cookie」を参照してください。

OpenSSO cookie

OpenSSOプロキシ

「OpenSSO Cookie (iPlanetDirectoryPro)」を参照してください。

認証および認可ポリシーの構成の詳細は、第17章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。

15.6.2 シングル・サインオン・サーバーおよびエージェントCookieについて

- OAM_ID Cookie

- 11g OAM WebgateのOAMAuthnCookie

- 10g WebgateのObSSOCookie

- OAM_REQのCookie

- DCCCtxCookie

- mod_osso Cookie

- OpenSSO Cookie (iPlanetDirectoryPro)

15.6.2.1 OAM_ID Cookie

このCookieは、OAMサーバーが適用範囲になります。OAM_IDは、ユーザーが資格証明のチャレンジを受けたときにOAMサーバーによって生成され、サーバーへのリダイレクトごとにそのサーバーに送信されます。

OAM_IDは、OAMサーバーのみが認識するキーで保護されます。

ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。

- Cookieが存在しない場合、ユーザー認証が開始されます。認証に成功した後、ユーザー・コンテキストおよびトークンがSSOエンジンによって設定されます。Cookieは、グローバル・ユーザーID(GUID)、作成時間およびアイドル・タイムアウトの詳細で設定されます。Cookieの情報はSSOサーバー・キーで暗号化され、SSOエンジンでのみ復号化できます。

- Cookieが存在する場合、Cookieが復号化され、サインインのフローが認証されたユーザーで終了します。

15.6.2.2 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の暗号化に使用されます。

10g WebgateのObSSOCookieと同様です。

15.6.2.3 10g WebgateのObSSOCookie

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エージェントの登録」を参照してください。

15.6.2.4 OAM_REQ Cookie

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用してリクエスト・キャッシュ・タイプをBASICからCOOKIEに変更する必要があります。

注意:

Oracle共通ホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

関連項目:

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

- 表15-8「SSO Cookie」

15.6.2.5 DCCCtxCookie

これは、外部資格証明コレクタ(DCC)にのみ作用します。

DCCCtxCookieは、認証時に必要な各種のコンテキスト情報を保存するために、DCCで使用されます。これに含まれる情報は、認証が完了した時点で元のリクエストを再作成するため、サーバー・アフィニティを保持するため、および反復複数ステップの認証を実行するために必要です。

デフォルトでは、DCCCtxCookieは、認証スキームに基づいて資格証明を収集するために、DCCが最初にリダイレクトされたときに設定されます(フォームによる認証スキーマでは、ブラウザが最初にログイン・フォームにリダイレクトされたとき)。

DCCの場合、認証後にOAMサーバーが、認証レスポンスでDCCに向けてDCCセッション・トークンを発行します。その後で、DCCはこのトークンを使用してホストベースのDCC Cookieを設定し、次の処理を実行します。

- 認証時にDCC Cookieが提示された場合: DCCは、DCCキーを使用してトークンを復号し、部分的なトークンの検証をローカルに実行します(整合性チェック、トークンの有効期間チェック)。この検証をパスすると、DCCはOAMサーバーに対するOAPチャネルで、タイムアウトについての完全なトークンの検証を実行します。

- DCC Cookieが存在しない場合: これは、最初の認証であることを示すため、資格証明コレクションが開始し、資格証明のサニティ・チェックと構文チェックを実行してから、その資格証明を検証するためにOAMサーバーに送信します。

関連項目:

「DCC対応の11g Webgateと認証ポリシーの構成」

15.6.2.6 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)がAccess Manager 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管理者ガイド』を参照してください。

15.6.2.7 OpenSSO Cookie (iPlanetDirectoryPro)

OpenSSOプロキシがセッション検証をトリガーした後、エージェントがこのCookieを検出します。OpenSSO cookieのデフォルト名は次のとおりです。

iPlanetDirectoryPro

OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを検証します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。SSOユーザー・ログインおよび認証フロー中に、OpenSSO Cookieが作成され、ユーザーのブラウザに設定されます。このCookieにはOpenSSOセッション識別子が含まれます。

エンド・ユーザー・セッション検証では、OpenSSOエージェントが保護されているアプリケーションへのリクエストを捕捉し、OpenSSO Cookieを検出します。

ユーザー・シングル・ログアウト時に、OpenSSOプロキシはユーザー・ログアウト・リクエストを受信して、ユーザーをOAMログアウトURLに転送します。OpenSSOプロキシは、OpenSSO Cookieを復号化して、OpenSSOセッション識別子をフェッチし、そこからOAMセッションIDをフェッチします。OpenSSOプロキシは、ログアウト・リクエストをOAMセッションIDとともに、OpenSSOログアウト・イベントを介して、コントローラに送信します。

- SSOユーザー・ログインおよび認証フロー

- エンド・ユーザー・セッションの検証フロー

- ユーザー・シングル・ログアウト・フロー

15.7 シングル・サインオンの構成タスクの概要

次の概要では、Access Manager 11gを使用するシングル・サインオンを構成するために管理者が実行する必要があるタスクについて説明します。タスクごとに、詳細情報へのリンクを提供しています。

タスク概要: シングル・サインオンの構成

1. この章のすべてのトピックを確認し、Access Manager 11gのSSOポリシー・モデルを理解します。

2. 固有のアプリケーションのドキュメントを使用して、保護しようとするアプリケーションごとにシングル・サインオン・ログアウトURLを構成します。

3. どちらかの方法を使用して保護するアプリケーションをホストしている各Webサーバーに、エージェントをインストールし、登録します。関連項目:

- 第12章「エージェントおよび登録の概要」

- 第13章「OAM 11gエージェントの登録および管理」

4. リソース・タイプ、ホスト識別子、認証スキームおよびモジュールの管理に進みます。

- 第16章「認証コンポーネントと共有ポリシー・コンポーネントの管理」

5. 既存のアプリケーション・ドメインを検索して(または新しいアプリケーション・ドメインを作成して)、次の説明に従って、リソースおよびポリシーを追加します。

- 第17章「リソースを保護してSSOを有効化するポリシーの管理」

16 認証コンポーネントと共有ポリシー・コンポーネントの管理

この章では、管理者が共有ポリシー・コンポーネントを管理する方法について説明します。この章の内容は、次のとおりです。

- 前提条件

- 認証コンポーネントと共有ポリシー・コンポーネントの管理の概要

- リソース・タイプの管理

- ホスト識別子の管理

- 認証方式と資格証明コレクタの理解

- ネイティブ認証モジュールの管理

- プラグイン・ベースのモジュールによるマルチステップ認証の編成

- 個別の認証用プラグインのデプロイおよび管理

- 認証スキームの管理

- 暗号化Cookieのチャレンジ・パラメータの構成

- パスワード・ポリシーの理解

- グローバル・パスワード・ポリシーの管理

- パスワード・ポリシー認証の構成

- DCC対応の11g Webgateと認証ポリシーの構成

- パスワード・ポリシー構成の完了

16.1 前提条件

Oracle Access Managementコンソールおよび少なくとも1つのOAMサーバーがWebLogicサーバー・ドメイン内にインストールされ、稼動している必要があります。Access Managerが少なくとも2つのエージェントが登録された状態で稼動している必要があります。

この章で説明されているアクティビティを実行する前に、第15章「Access Managerを使用したシングル・サインオンの概要」で説明されている情報を確認することをお薦めします。

16.2 認証コンポーネントと共有ポリシー・コンポーネントの管理の概要

この項では、共有ポリシー・コンポーネントを構成するために実行する必要のあるタスクについて説明します。このコンポーネントは、リソースを保護し、シングル・サインオンを可能にするAccess Manager認証ポリシーで使用する必要があります。

関連項目:

第15章「Access Managerを使用したシングル・サインオンの概要」

タスク概要: 共有ポリシー・コンポーネントの構成

1. この章の説明に従って、必要なリソース・タイプが定義されていることを確認します。

- リソース・タイプの管理

2. 次の説明に従って、エージェントに由来する名前が付けられたホスト識別子の定義がエージェント登録時に作成された(またはユーザーが手動で作成した)ことを確認します。

- ホスト識別子の管理

3. Access Managerによる資格証明コレクションについて理解します。

- 認証方式と資格証明コレクタの理解

4. 複数ステップの認証を可能にする認証プラグインについて理解してから使用します。

- プラグイン・ベースのモジュールによるマルチステップ認証の編成

- 個別の認証用プラグインのデプロイおよび管理

5. 認証ポリシーに追加できる認証スキームを作成して管理します(次の項目を参照)。

- 認証スキームの管理

- 暗号化Cookieのチャレンジ・パラメータの構成

6. デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタに独自のグローバル・パスワード・ポリシーを設定します(特に明記しないかぎり、このタスクはECCとDCCの両方に適用されます。わずかな違いについては、説明内に示しています)。

- パスワード・ポリシーの理解

- グローバル・パスワード・ポリシーの管理

- パスワード・ポリシー認証の構成

- DCC: DCC対応の11g Webgateと認証ポリシーの構成

- パスワード・ポリシー構成の完了

7. 第17章に進み、認証ポリシーを設定します。

16.3 リソース・タイプの管理

この項の内容は次のとおりです。

- リソース・タイプおよびその使用について

- リソース・タイプ・ページについて

- 特定のリソース・タイプの検索

- カスタム・リソース・タイプの作成

16.3.1 リソース・タイプおよびその使用について

リソースをアプリケーション・ドメインに追加する場合、管理者は定義されているリソース・タイプのリストから選択する必要があります。Oracle提供のリソース・タイプには、次が含まれます。

- HTTP

- wl_authen

- TokenServiceRP

管理者は、他のリソース・タイプを定義できます。また、Oracle提供のリソース・タイプまたはカスタム・リソース・タイプのどちらにも、操作を定義できます。特定のリソースについて、宣言されている操作の一部またはすべて(後でリソース・タイプに対して定義された新しい操作もすべて含めて)を使用するように定義できます。管理者は、リソースが作成されているカスタム・リソース・タイプまたは操作を削除することはできません。Oracle提供のリソース・タイプおよび操作は、ポリシー・ストア内で読取り専用としてマークされており、削除できません。

注意:

リソース・タイプの操作リストは、そのタイプのリソースが存在する場合は、変更できません。

表16-1に、リソース・タイプと操作の比較を示します。

表16-1 Access Managerのリソース・タイプの10gとの比較

Access Manager 11g

Oracle AccessManager 10g

HTTP: HTTPプロトコルおよびHTTPSプロトコルで使用されるデフォルトのリソース・タイプ。

HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。

このリソース・タイプは読取り専用です。HTTPリソース・タイプに関連付けられているデフォルト操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されるポリシーがすべての操作に適用されます。

操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてHTTPタイプのリソースに適用されるポリシーが、すべての操作に適用されます。

- Get

- Post

- Put

- Head

- Delete

- トレース

- Options

- 接続

- Other

関連項目: 「「リソース・タイプ」ページについて」

HTTP: HTTPリソース・タイプは読取り専用です。

操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてリソースに適用されるポリシーが、すべての操作に適用されます。

- Get

- Post

- Put

- Head

- Delete

- トレース

- Options

- 接続

- Other

wl_authen: WebLogic認証スキームを表すリソースも読取り専用です(デフォルト操作は変更も削除もできません。)

この非HTTPリソース・タイプは、Access Managerが存在しないドメインにWebLogicコンテナでデプロイされているリソースとともに使用できます。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。

wl_authenタイプのリソースには、カスタム・アクセス・クライアントが必要です。

なし

TokenServiceRP: トークン・サービスのリライイング・パーティを表すリソース。このリソース・タイプの操作は発行です。

なし

カスタム・リソース・タイプ: 関連付けられたホスト識別子はありません。

カスタムEJBリソース・タイプは、SSO統合に使用するためにオンデマンドに作成できます。

EJB: ユーザー認証のためにWebLogicおよびWebSphereにSSOを統合する場合に使用するカスタム・リソース・タイプ。認証中は、ユーザーのグループがフェッチされ、サブジェクト・プリンシパルにロールとして移入されました。その後の認可は、ユーザー・ロールに基づいて、アプリケーション・サーバー内部で実行されました。

リソース操作によって認可がコールされることはありませんでした。

非HTTPリソース・タイプに関連付けられたホスト識別子はありません。

非HTTPリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。

16.3.2 「リソース・タイプ」ページについて

Oracle Access Managementコンソールでは、リソース・タイプは、「ポリシー構成」タブで他のコンポーネントとともに編成されます。ナビゲーション・ツリーには、Oracle提供のリソース・タイプであるHTTP、wl_authenおよびTokenServiceRPが表示されます。

注意:

事前定義済のリソース・タイプは削除できません。鍵のアイコン付きで示される事前定義済の操作は、削除できません。必要に応じて、追加の操作を作成、編集または削除できます。

HTTPリソース・タイプ(図16-1参照)はAccess Managerで保護され、インターネット・プロトコル(HTTPまたはHTTPS)でアクセスされるWebアプリケーションに使用されます。

図16-1 デフォルトのHTTPリソース・タイプ定義

「図16-1 デフォルトのHTTPリソース・タイプ定義」の説明

図16-2は、 wl_authenリソース・タイプを示しています。これは、次のいずれかのAccess Manager IDアサーション・プロバイダ構成を使用するFusion Middlewareアプリケーションに使用します。このプロバイダ構成については、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

- IDアサーション・プロバイダ

- Oracle Web Services Managerを使用するアイデンティティ・アサータ

- 認証プロバイダ機能

図16-2 デフォルトのリソース・タイプwl_authen

図16-3に示すように、TokenServiceRPリソース・タイプは、トークン・サービス・リライイング・パーティを表します。このリソース・タイプの操作は発行です。詳細は、「TokenServiceRPタイプのリソースの管理」を参照してください。

図16-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ

「図16-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ」の説明

表16-2に、各リソース・タイプ定義の要素を示します。

表16-2 リソース・タイプの定義

要素

説明

名前

必須。最大30文字の英数字の一意の名前。

注意: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。

説明

オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。

たとえば、WebLogic認証スキームを表すリソースなどです。

操作

オプション。特定のリソースを制御するポリシーは、そのリソースに定義されている、指定されたすべての操作に適用されます。このリソース・タイプに文字列として操作を追加(または削除)して、アプリケーション・ドメイン内でこのタイプのリソースを定義すると、操作が使用可能になります。リソース・タイプに追加できる操作の数に制限はありません。

- Get

- Post

- Put

- Head

- Issue (TokenServiceRP)

- Login (wl_authen)

- Delete

- トレース

- Options

- 接続

- Other (Oracle Access Manager 10では使用可能、11gではサポートされていません)

リモート登録: 自動ポリシー作成時に、指定された操作がサポートされます。自動ポリシー作成時に何も操作が指定されていない場合は、そのタイプに対して定義されたすべての操作がサポートされます。

移行: Access Manager 11.1.2へのアップグレード(10gまたは11.1.1.3または11.1.1.5のいずれかから)の実行中、リソース定義およびHTTPデフォルト操作は自動的に処理されます。ただし、10gで提供されていたEJBカスタム・リソース・タイプは現在Oracleから提供されていないので、それに変わるカスタム・リソース・タイプを作成する必要があります。次を参照してください。

関連項目: 「リソース・タイプおよびその使用について」および「アプリケーション・ドメインのリソースの定義について」

次に、リソース・タイプの作成、変更および削除方法を説明します。

16.3.3 特定のリソース・タイプの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して定義されているリソース・タイプを検索できます。

関連項目:

「コンソールを使用した検索の実行」

リソース・タイプを検索するには、次の手順を実行します。

1. Oracle Access Managementコンソールで「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「リソース・タイプ」を選択し、検索するリソース・タイプの名前を(ワイルド・カード(*)の使用は任意)入力して、「検索」をクリックします。次に例を示します。

h*

または、目的のアプリケーション・ドメインに移動して、「リソース」ノードを開いてドメインのコントロールを表示し、リストからリソース・タイプを選択してから「検索」をクリックします。

3. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集または表示: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。

- 列の並替え: 「表示」メニュー項目を選択して、結果表の表示を変更します。

4. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

16.3.4 カスタム・リソース・タイプの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して事前定義のリソース・タイプを作成できます。たとえば、わずか1つまたは2つ(またはそれ以上)の操作に適用されるカスタム・リソース・タイプを定義できます。定義されているカスタム・リソース・タイプは、リソースを認証ポリシーまたは認可ポリシーに追加する際に、デフォルト・リソース・タイプとともにリストに表示されます。

関連項目:

- 「リソース・タイプおよびその使用法について」

- アプリケーション・ドメインのリソースの定義

カスタム・リソース・タイプを作成するには:

1. Oracle Access Managementコンソールで「ポリシー構成」タブをアクティブ化します。

2. 「共有コンポーネント」で「リソース・タイプ」ノードをクリックし、「追加」(+)ボタンをクリックします。

3. 次の情報を入力します。

- 名前: このリソース・タイプを識別する一意の名前。

- 説明: オプション。

- 操作: 「操作」表で「+」をクリックし、表示されるフィルドに操作名を入力します。必要に応じて手順を繰り返して、このリソース・タイプのすべての操作を定義します。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

4. 「適用」をクリックして、このカスタム・リソース定義を送信します。

5. 「ポリシーに追加するリソース定義の追加および管理」の説明に従って、このリソース・タイプをアプリケーション・ドメインに追加します。

16.4 ホスト識別子の管理

この項では、ホスト識別子とその使用方法およびホスト識別子の作成、変更または削除方法を説明します。次に内容を示します。

- ホスト識別子について

- 仮想Webホストについて

- ホスト識別子ページについて

- ホスト識別子の作成

- ホスト識別子定義の検索

- ホスト識別子定義の表示または編集

- ホスト識別子定義の削除

16.4.1 ホスト識別子について

Access Managerポリシーは、コンピュータ・ホストのリソースを保護します。Access Managerでは、コンピュータ・ホストは、ホスト識別子を使用して個別に指定されます。

表16-3は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。

表16-3 ホスト識別子の例

ホスト識別子のサンプル

説明

hrportal.intranet.company.com

従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。

hr-sf-02.intranet.company.com

直接アクセスできるアプリケーションをホストする単一のマシン。

hrportal.company.com

以前の従業員の福利厚生や企業年金情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。

定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。

登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、Access Managerはリソースを保護するポリシーを適用できます。

Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、Oracle Access Management管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。

詳細は、次の項を参照してください。

- ホスト識別子の使用方法

- ホスト識別子のガイドライン

- ホスト識別子のバリエーション

16.4.1.1 ホスト識別子の使用方法

設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(HTTP)またはタイプ(HTTP以外)を使用して、リソースをスコープします。この組合せにより、それらはAccess Manager全体で一意に識別されます。

注意:

各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。

実行時の使用方法

実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のどちらかの方法でWebサーバー・ホスト情報を取得します。

- 仮想Webホスト・サポートに優先ホスト・パラメータが構成されている場合(「仮想Webホストについて」を参照してください)、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。

- 優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。

これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。

たとえば、aseng-wikiにアクセスするユーザーは、次を入力します。

http://example-wiki.uk.example.com/wikiexample

ここで、wikiexampleはリソースURL、example-wiki.uk.example.comはホストです。このホストおよびポート(ポートは80)を照合して、ホスト識別子を示します。

優先ホスト

通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_nameに設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホストについて」を参照してください。

ホストの認証および認証スキームのチャレンジ・リダイレクト

ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。

注意:

認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。

16.4.1.2 ホスト識別子のガイドライン

各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。

- 各ホスト名を一意にする必要があります。

- 各ホスト名:ポート・ペアを一意にする必要があります。

- 各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。

- 各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。

- ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。

- 各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。

詳細は、「ホスト識別子のバリエーション」を参照してください。

16.4.1.3 ホスト識別子のバリエーション

すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。ホスト識別子は、Access Managerで保護するWebサイトまたは仮想Webサイトごとに構成する必要があります。

Access Managerに対してWebサーバー・ホストを指定する場合、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。次に、同じホストのアドレス指定方法の例を示します。

- example.com

- example.com:80

- www.example.com

- www.example.com:80

- 216.200.159.58

- 216.200.159.58:80

16.4.2 仮想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仮想ホスト上のAccess Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。

16.4.2.1 リバース・プロキシの背後へのWebgateの配置

10g Webgateをリバース・プロキシとともに、Access Managerに対して使用できます。この項では、この方針の長所と短所について説明します。

長所:

- リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。
これは、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://example.com:[port]/path/resource)は使用しないことをお薦めします。
絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。

16.4.2.2 Apache以外のWebサーバーの仮想ホストの構成

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。たとえば、次に示すように、ユーザーがURLに文字列example2を入力したとします。

http://example2

Webサーバーで、いずれかのWebサイトのホスト名がexample2であれば、その一致する仮想サイトでリクエストが処理されます。

展開された10g Webgate登録ページの「優先ホスト」フィールドで、次のように入力します。

HOST_HTTP_HEADER

IIS仮想ホスティング: IISコンソールから、各仮想Webサイトを構成して次のフィールドを含める必要があります。

- ホスト・ヘッダー名

- IPアドレス

- ポート

関連項目:

- http://www.simpledns.com/kb.aspx?kbid=1149

- http://support.microsoft.com/kb/q190008/

16.4.2.3 仮想ホスト、ディレクトリまたはファイルとのApache用Webgateの関連付け

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。

注意:

SERVER_NAME値は、Apacheベースのサーバー以外のホストでサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。

ServerNameディレクティブは、hostNameとともに明示的に7777に設定する必要があります。これはListenディレクティブが正しく設定されているかどうかには関係ありません。サーバーは、自己識別のためにこの値を明示的に要求する場合がありますが、通常は自動的に自己識別が可能です。

シングル・サインオンでApacheベースのリバース・プロキシを使用する場合、Webサーバーの構成ファイル(httpd.configなど)でApacheサーバーで実行するWebサイトを指定します。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。指定したサイトに関連付ける参照を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ディレクティブに移動した後は、Webゲートはその仮想ホストに対してのみ動作します。LocationMatchブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。

ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
ProxyRequests On
SSLEngine on
SSLCACertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/intermediateca.cer
SSLCertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.cer
SSLCertificateKeyFile Z:/Apps/sslcert_exampleapps_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

16.4.3 「ホスト識別子」ページについて

Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。

管理者はコンソールを使用して、ホスト識別子を作成および管理できます。Oracle Access Managementコンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。

図16-4は、コンソールの通常のホスト識別子構成ページを示しています。ここでは、ホストの正規の名前およびユーザーが同じホストを表現できる他のすべての名前を入力します。

注意:

各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。

図16-4 ホスト識別子ページ

「図16-4 「ホスト識別子」ページ」の説明

表16-4は、ホスト識別子の定義を示しています。

表16-4 ホスト識別子の定義

プロパティ

説明

名前

この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。

説明

この構成の使用を示す200文字までのオプションの説明。

ホスト名のバリエーション

- ホスト名: ユーザーがアプリケーションにアクセスする場合に使用する可能性のある様々なホスト名または組合せのリスト。
関連項目: 「ホスト識別子のバリエーション」および「ホスト識別子のガイドライン」

- ポート: 各ホストまたは組合せで使用されるWebサーバー・ポート

16.4.4 ホスト識別子の作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を手動で作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。エージェントの登録時に「ポリシーの自動作成」を選択すると、この作業は自動的に実行されます。

注意:

テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。

関連項目:

- 「ホスト識別子について」

- 「仮想Webホスティングについて」

ホスト識別子を手動で作成するには、次の手順を実行します。

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「ホスト識別子」ノードを開きます。

2. 「ホスト識別子の検索」ページの右上隅の「ホスト識別子の作成」ボタンをクリックします。
または、「ホスト識別子」ノードを開いて「検索結果」表の上にある「作成」(+)ボタンをクリックします。

3. 新しい「ホスト識別子」ページで、次の内容を入力します。

1. 名前

2. 説明

3. ホスト名組合せ: 「操作」リストのホスト名とポートのバリエーションを追加(または削除)します。
追加: 「作成」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。

削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。

4. 必要に応じて手順3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。

5. 「適用」をクリックして新しい定義を送信します(または変更を適用しないでページを閉じます)。

6. 確認ウィンドウを閉じて、新しい定義がナビゲーション・ツリーにリストされていることを確認します。

16.4.5 ホスト識別子定義の検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定のホスト識別子を検索できます。

注意:

ホスト識別子がリソースに関連付けられている場合、削除しようとすると、アラートが表示され、確認を求められます。関連付けられていない場合、ホスト識別子は正常に削除されます。

関連項目:

「コンソールを使用した検索の実行」

ホスト識別子を検索するには:

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「ホスト識別子」ノードを開きます。

2. 「ホスト識別子の検索」ページで、「名前」フィールドに名前(またはワイルド・カード(*)を含む部分的な名前)を入力するか、または「名前」フィールドを空白のままにしてすべてのホスト識別子を表示します。次に例を示します。

my_h*

3. 「検索」ボタンをクリックして検索を開始し、表に結果が表示されたら、次の操作を実行します。

- 表示または編集: 「検索結果」表で名前をダブルクリックして構成ページを表示し、通常どおり追加または編集します。

- 削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。

- 連結解除: ツールバーの「連結解除」ボタンをクリックして、「検索結果」表をページ全体に拡張します(または「表示」メニューで「連結解除」をクリックします)。

- 列の並替え: 「表示」メニューで「列の並替え」を選択して、表示される矢印を使用して列を並べ替えます。

16.4.6 ホスト識別子定義の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を変更できます。これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。

前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン

注意:

設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。

関連項目:

「ホスト識別子ページについて」

ホスト識別子を表示または変更するには、次の手順を実行します。

1. 「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索して表示します。

2. 「ホスト識別子」ページで、必要に応じて情報を変更します(表16-4)。

1. 名前

2. 説明

3. ホスト名組合せ: 表示される表で次の操作を実行します。
ホスト名バリエーションの追加(+): 「追加」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。

ホスト名バリエーションの削除(X): ホスト名をクリックし、「削除」ボタンをクリックして削除します。

3. 必要に応じて手順3cを繰り返して、バリエーションを追加または削除します。

4. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じて、終了する場合はページを閉じます。

16.4.7 ホスト識別子定義の削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の全体の定義を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。

注意:

ホスト識別子がリソースに関連付けられている場合、アラートが表示されます。関連付けられていない場合、ホスト識別子は削除されます。

前提条件

アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、そのホスト識別子を使用するアプリケーション・ドメインのリソース定義を先に変更する必要があります。

関連項目:

既存の定義から単一のホスト識別子を削除する場合は、「ホスト識別子定義の表示または編集」を参照してください。

ホスト識別子を削除するには、次の手順を実行します。

1. このホスト識別子を使用するアプリケーション・ドメインの関連するリソース定義を検索して変更します。「リソース定義の検索」を参照してください。

2. 「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索します。

3. 表示: 結果表で名前をダブルクリックして構成ページを表示し、削除可能であることを確認します。

4. 削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。

16.5 認証方式と資格証明コレクタの理解

Access Managerの認証では、リクエスタ(ユーザー)を一元化されたコンポーネントにリダイレクトする操作が伴われます。このコンポーネント(資格証明コレクタと呼びます)が、認証を実行します。

ここでは、次の内容について説明します。

- 複数の認証方式について

- 埋込み資格証明コレクタと外部資格証明コレクタの比較

- 認証イベントのロギングおよび監査

16.5.1 複数の認証方式について

認証は、ユーザーを証明するプロセスです。Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。

Access Managerを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールまたはプラグインに依存します。

この項では、マルチレベル認証およびAccess Managerでサポートされている他の認証方式について説明します。

マルチレベル認証

Access Managerを使用すると、管理者は複数の認証スキームに複数の認証レベルを割り当てて、どのアプリケーションをどのスキームで保護するかを選択できます。各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。

SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。レベル2のリソースへのアクセスを認証されているユーザーは、2以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。

詳細は、「マルチレベル認証およびステップアップ認証について」を参照してください。

マルチステップ認証

マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

「単純フォーム認証とマルチファクタ(マルチステップ)認証の比較」を参照してください。

Windowsネイティブ認証

統合Windowsネイティブ認証は、OSSOおよびWebgateの両方によって保護されているアプリケーションでサポートされています。この形式の認証は、Kerberos認証モジュールに依存しています。詳細は、第43章「Windowsネイティブ認証のためのAccess Managerの構成」を参照してください。

他の認証タイプ

次のような、Oracle Fusion Middlewareアプリケーションに必要な認証機能がサポートされています。

- 一般的にユーザー名およびパスワードを使用して証明書を使用しない弱い認証

- サード・パーティのセルフサービス・ユーザー・プロビジョニングの自動ログイン

- ユーザー・コンテキスト情報のHTTPヘッダー・サポート。たとえば、ホスト識別子を使用してリソースのホスト・コンテキストを作成します。これは、異なるコンピュータで同じURLパスを使用するリソースを追加する場合に役立ちます。

2つのWebGateの異なる認証スキームを使用する場合、ユーザーは再認証なしで高い認証スキームから低い認証スキームに移行できますが、低い認証スキームから高い認証スキームには移行できません。

注意:

シングル・サインオンの実行中、ユーザーが認証テストに成功しても、2番目または3番目のリソースにアクセスする際に認可テストに失敗する場合があります。ドメインの各リソースに一意の認可ポリシーが存在する場合があります。

Access Managerを使用した認証スキームの構成および使用の詳細は、「認証スキームの管理」を参照してください。

16.5.2 埋込み資格証明コレクタと外部資格証明コレクタの比較

Access Manager 11.1.2は、デフォルトで埋込み資格証明コレクタ(ECC)をサポートします。さらに、最新のWebゲートを外部資格証明コレクタ(DCC。認証Webゲートと呼ぶこともあります)として使用するように構成することもできます。

DCCは、デフォルトの埋込み資格証明コレクタ(ECC)よりも安全性が高いと考えられます。集中DCCは、ログイン・ページを提示してユーザーの資格証明(ユーザーIDやパスワードなど)を収集し、バック・チャネルのOracle Accessプロトコル(OAP)を使用してこれらをOAMサーバーに送信します。DCCを使用すると、追加の資格証明が要求されることがあります。

OAMサーバーがDCCを使用するように構成されている場合、ECCとそのHTTPエンドポイントは無効になります。唯一のHTTP通信は、OAMサーバーがデプロイされているドメイン内のWebLogic AdminServerでホストしているOracle Access Managementコンソールに対する通信です。AdminServerへの接続は、ネットワーク・レベルで制御できます。たとえば、内部ネットワークの外部からの管理リクエストを禁止できます。

- ECCとDCCの共存を許可すると、ECCまたはDCCで使用するように構成した認証スキームとポリシーを使用できるようになります。これにより、Oracle Access Managementコンソールを含むECCに依存するリソースにフォールバック・メカニズムを使用できるようになります。

- ECCを無効にする(オフにする)と、Oracle Access Managementコンソールを含むECCメカニズムに依存するリソースへのアクセスを、完全に禁止することになります。

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)には、本質的な違いはありませんが、これらの比較を表16-5に示します。

関連項目:

「Access Manager資格証明コレクションおよびログインの概要」

表16-5 DCCとECCの比較

DCC

ECC

デプロイメント

外部資格証明コレクタは、サーバーの論理部分に存在し続けて、OAMサーバーのフロント・チャネル通信のエンドポイントとして機能します。ただし、DCCは次のようにも構成できます。

- スタンドアロン(OAMサーバーからデタッチされ、アプリケーション・サーバーを必要としません)。

- RSA SecurIDのパスコード検証、次回のトークンの取得、新規PIN作成のワークフローをサポートします。

- サーバーのスケールアウト、攻撃リジリエンスに対する優れた柔軟性に加え、資格証明コレクションUIの作成、フローおよびライフサイクル管理については、以前の10g認証Webゲートと同様です。

埋込み資格証明コレクタは、OAMサーバーとともにデプロイされ、このサーバーに統合され、プロトコル・バインディング・レイヤーの一部になります。

ECCは、RSA SecurIDパスコードの検証、次回のトークンの取得、新規PINの作成ワークフローをサポートします。

DMZデプロイメント

可能。

DMZでDCCを使用するデプロイメントの場合、エンド・ユーザーのネットワーク接続が公衆回線網内で終了し、OAMサーバーには相互認証された接続でOracle Accessプロトコル(Oracle独自のアプリケーション・ネットワーク・プロトコル)を使用して接続するという利点があります。これにより、OAMサーバーは完全に分離され、非認証ネットワーク接続が確立することはありません。

非認証ユーザーは、不正なリクエストをOAMサーバーに送信できません。

不可。

通信チャネル

DCCは、ユーザーからのHTTP/HTTPSリクエストを利用して、SSLに対応できるOracle Accessプロトコル(バック・チャネル)を通じてOAMサーバーと通信します。

ECCは、HTTP/HTTPSを通じてユーザーとOAMサーバーの両方と通信します。

DCCログイン、エラーおよびパスワードのページ

DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso/*、WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよびWEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*ディレクトリで、次を参照してください。

- ログイン・ページ: /oamsso-bin/login.pl

- ログアウト: /oamsso-bin/logout.pl

- RSA SecurIDログイン・ページ: /oamsso-bin/securid.pl

注意: /oamsso-bin内の、login、logoutおよびsecuridスクリプトの最初の行にあるPerlの場所を更新してください。

関連項目: 表16-24「資格証明コレクタのパスワード・ページ」。

この実装のログイン・ページの詳細は、第42章「RSA SecurID認証とAccess Managerとの統合」を参照してください。

ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。

- ログイン・ページ: /pages/login.jsp

- ログアウト・ページ: /pages/logout.jsp

- エラー・ページ: /pages/servererror.jsp

- マルチステップ: /pages/mfa_login.jsp

DCCベースのログインおよびログアウトを行うPerlスクリプト

DCCベースのログインおよびログアウトを行うPerlスクリプト

Perl実行ファイルのパス名は、Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるOracle提供のPerlスクリプト内で、実際の場所と一致するように更新する必要があります。

Unix: whichコマンドを使用すると、OAMサーバー上でperlを検索できます。次に例を示します。

which perl
/usr/bin/perl

ただし、perlスクリプト自体では次の場所が参照されています。

/usr/local/bin/perl

Windows: Oracle提供のPerlスクリプトで指定されているデフォルトのPerlインタプリタは使用できません。これらのスクリプトのPerlインタプリタのパスを、ご使用のシステムの実際のPerlへのパスに更新する必要があります。

なし

パスワード・ポリシーの強制

可能。

「パスワード・ポリシーのDCCフォームの検索と更新」を参照

可

関連項目: 「グローバル・パスワード・ポリシーの管理」

認証スキームのコレクション・メソッド

DCCはすべてのチャレンジ・メソッドをサポートしています。

ECCはすべてのチャレンジ・メソッドをサポートしています。

ECCは、認証スキームのチャレンジ・メソッドに基づいてユーザーの資格証明を収集し、その資格証明を検証するためにOAMサーバーに送り返します。

カスタム認証プラグインとチャレンジ・メソッド

可。ECCと同じです。

すべてのチャレンジ・メソッドとマルチステップ認証(パスワード・ポリシーと、その他のカスタム認証プラグイン)がサポートされます。

シングル・ステップ(単純フォーム)認証

可。ECCと同じです。

可能。次の場合、DCCとECCの両方がこれを処理ます。

- すべての資格証明が1つの単純フォームで提供される場合。

- 資格証明の検証時および認証時。成功または失敗のステータスが返されます。

- これは失敗時に再試行できます。

マルチステップ認証

可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。

この場合、次のようになります。

- 必要な資格証明が、一度に提供されない場合。

- 認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。

- 成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンにフィードする必要がある資格証明とコンテキスト・データが送信されます。

- 認証プラグインは、複数のステップで構成できます。

「マルチレベル認証およびステップアップ認証の理解」を参照

可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。

認証処理

ECCと比較すると、DCCがOAMサーバーの認証機能を制限することはありません。

DCC:

1. 10g Webgateおよび11g Webgateの両方からの認証リダイレクトを処理します。

2. ユーザーの資格証明(単純フォームまたはマルチファクタ)に対するチャレンジを含むフォームベース認証を処理します。

3. エージェント・キーを使用するエージェントからの認証リクエスト・メッセージを復号化し、基本的な整合性チェックを実行し、リクエストの時刻を検証し、リクエスト・コンテキストを含むリクエストからすべてのパラメータを抽出します。

4. 最初に取得したリクエスト・コンテキストを含む認証レスポンス・メッセージを作成し、エージェント・キーを使用してobrarを復号化します。

5. エージェント・キーを使用してログアウト・リダイレクト・リクエストを復号化し、ログアウト処理を起動します。

認証時:

1. ECCは、プロトコル・バインディング・レイヤー(PBL)に着信するリクエストを処理します。PBLでは、リクエストを変換してSSOエンジンに送信します。

2. SSOエンジンは、有効なセッションについてチェックします。有効なセッションが存在しない場合は、認証エンジンに制御を移します。

3. 認証エンジンは、リソースの保護についてチェックし、そのリソースに関連付けられた認証スキームをフェッチします。

4. ECCはクライアントと対話し、データを受け入れて、これをPBLに送信します。

ECCのオーバーライド

DCCをデプロイしてECCを無効にする場合、管理者は次のタスクを実行して、関連するDCC URLとフォームを指定する必要があります。

- OAMエージェント登録: 資格証明コレクタ操作の許可(DCCに対して有効化)

- 認証モジュール、ステップ編成: エラー(失敗時)

- 認証スキーム: チャレンジ・リダイレクトURL (DCCホストおよびポート)

- 認証スキーム: チャレンジURL /oamsso-bin/login.pl (DCCログイン・ページ)

- 認証スキーム: チャレンジ・メソッド

- パスワード・ポリシー: DCCのパスワード・サービスURL (デフォルト: /oamsso-bin/login.pl)

「DCCの資格証明操作の有効化」を参照

なし

ログアウト構成

「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」を参照

「11g Webgateの集中ログアウト構成」を参照

Cookie/トークン

- DCCCtxCookie

- 11g Webgate: OAMAuthnCookie

- 11g Webgate: OAMRequestContext

- 10gリソースWebgate: ObSSOCookie

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」

- 11g Webgate: OAMAuthnCookie

- 11g Webgate: OAM_REQ

- 11g Webgate: OAM_ID

- 11g Webgate: OAMRequestContext

- 10g Webgate: ObSSOCookie

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」

16.5.3 認証イベントのロギングおよび監査

管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。認証するユーザーに関して収集される情報は、次のとおりです。

- IPアドレス

- ユーザー・ログインID

- アクセスの時間

ロギング(または監査)中、ユーザー情報およびユーザー機密属性は記録されません。誤用を避けるためにセキュアなデータ(ユーザー・パスワードなど)が削除されます。

関連項目:

- 第6章「コンポーネント・イベント・メッセージのロギング」

- 第8章「管理および実行時イベントの監査」

- 第9章「Oracle Access Managementコンソールを使用したパフォーマンスのモニタリング」

16.6 ネイティブ認証モジュールの管理

Access Managerでは、各認証スキームに認証モジュールが必要です。

注意:

ネイティブ認証モジュールには、指定された認証ニーズを満たすように複数のプラグインを編成するための柔軟性がありません。したがって、ネイティブ認証モジュールは今後のリリースで非推奨の対象となります。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。

この項では次の情報を提供します。

- ネイティブのAccess Manager認証モジュールについて

- ネイティブ認証モジュールの表示または編集

- ネイティブ認証モジュールの削除

16.6.1 ネイティブのAccess Manager認証モジュールについて

表16-6に、Access Managerネイティブ認証モジュールを示します。

表16-6 ネイティブ認証モジュール

モジュール名

説明

LDAP

リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。

関連項目: ネイティブのLDAP認証モジュール.

LDAPNoPasswordAuthModule

リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。

関連項目: ネイティブのLDAP認証モジュール.

Kerberos

キー・タブ・ファイル名、krb5.configurationファイル名およびプリンシパルを指定します。

第43章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。

関連項目: 「ネイティブのKerberos認証モジュール」

X509

LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示す追加プロパティを使用するLDAPPluginに似ています。

関連項目: ネイティブのX509認証モジュール。

カスタム認証モジュール

このタイプのモジュールは、バンドルされているプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このタイプのモジュールは、通常、複数のプラグインを使用します。これらのプラグインは、各プラグインが固有の認証機能を実行することが保証されるように編成できます。各プラグインに定義されている成功アクションまたは失敗アクションに応じて、別の認証プラグインがコールされます。

関連項目: 「マルチステップ認証のプラグイン・ベースのモジュールについて」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』(カスタム・モジュールを使用するスキーム、カスタム認証モジュールおよびプラグインの開発とデプロイの詳細)。

関連項目:

- 「チャレンジ・メソッドについて」

- カスタム認証プラグインの作成の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

16.6.1.1 ネイティブのKerberos認証モジュール

事前構成済Kerberos認証モジュールを図16-5に示します。詳細は、図の後に説明します。

図16-5 ネイティブのKerberos認証モジュール

「図16-5 ネイティブのKerberos認証モジュール」の説明

表16-7は、ネイティブのKerberos認証モジュールの定義を示しています。既存の事前構成済Kerberos認証モジュールを使用するか、独自のモジュールを作成できます。

表16-7 ネイティブの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キー配布センターの場所)。

16.6.1.2 ネイティブのLDAP認証モジュール

Oracleでは、次の2つのLDAP認証モジュールを提供しています。

- LDAP

- LDAPNoPasswordAuthModule

図16-6に示すように、両方のモジュールが同じ要件(「名前」と「ユーザー・アイデンティティ・ストア」)を持っています。詳細は、図の後に説明します。

図16-6 ネイティブのLDAP認証モジュール

「図16-6 ネイティブのLDAP認証モジュール」の説明

表16-8は、LDAP認証モジュールの要素を示しています。同じ要素と値がLDAPNoPasswordAuthnModuleでも使用されます。

注意:

これらの標準LDAP認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。

表16-8 ネイティブのLDAP認証モジュールの定義

要素

説明

名前

このモジュールの一意の名前。

ユーザー・アイデンティティ・ストア

指定されたLDAPユーザー・アイデンティティ・ストアは、このモジュールの認証に必要なユーザー資格証明を含んでいる必要があります。LDAPストアはAccess Managerに登録されていなければなりません。

関連項目: 「ユーザー・アイデンティティ・ストアの管理」

複数のアイデンティティ・ストア・ベンダーがサポートされています。インストール時には、ユーザー・アイデンティティ・ストアは1つのみで、それが指定されたシステム・ストアでもあります。アイデンティティ・ストアを追加し、別のストアをシステム・ストアとして指定する場合には、必ずそのシステム・ストアを参照するようにLDAPモジュールを変更してください。認証スキームOAMAdminConsoleSchemeは、管理者ロールと資格証明をLDAPモジュールに依存します。

関連項目: 「デフォルト・ストアおよびシステム・ストアの設定」および「管理者のロックアウト」

16.6.1.3 ネイティブのX509認証モジュール

Access Managerは、デフォルトとして事前定義済X509認証モジュールを用意しています。管理者は、新しいX509認証モジュールも作成できます。暗号化の表現のX.509は、シングル・サインオン(SSO)に使用されるデジタル公開鍵証明書の標準です。X.509では、特に公開鍵証明書、証明書失効リストおよび属性証明書の標準形式を指定します。

X.509デジタル証明書を使用すると、証明書を発行する認証局(CA)の厳密な階層システムを取得できます。X.509システムで、CAは、特定の識別名または電子メール・アドレスやDNSエントリなどの代替名に公開鍵をバインドする証明書を発行します。

企業のPKIシステムで使用できるように、企業の信頼されたルート証明書をすべての従業員に配布できます。SSL証明書をすぐに使用できるように、特定のWebブラウザは、事前インストールされたルート証明書を用意しています。

Access Managerは、オンライン証明書ステータス・プロトコル(OCSP)インターネット・プロトコルを使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーおよびそのステータスを通知されるクライアント・アプリケーション間で使用される通信構文を指定します。

ユーザーがサーバーにアクセスしようとすると、OCSPは証明書ステータス情報のリクエストを送信します。OCSPは、特定のネットワーク・ホストが特定の時間に特定の証明書を使用していたことをリクエスタに公開します。サーバーは、「current」、「expired」、または「unknown」というレスポンスを戻します。OCSPは、期限が切れた証明書を使用するユーザーに更新前の指定された期間にサーバーにアクセスできる構成可能な猶予期間を与えます。

OCSPメッセージはASN.1で暗号化され、HTTPで一般的に転送されます。OCSPのリクエストおよびレスポンス特性では、OCSPサーバーを参照する場合に「OCSP応答者」という用語を使用します。Access Managerを使用する場合、Oracle Access ManagementコンソールをホストするコンピュータはOCSP応答者です。

OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。

図16-7 ネイティブのX509認証モジュール

「図16-7 ネイティブのX509認証モジュール」の説明

表16-9は、ネイティブのX509認証モジュールの要件を示しています。

注意:

この標準認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。

表16-9 X509認証モジュールの定義

要素

説明

名前

一意の名前でこのモジュール定義を識別します。

一致するLDAP属性

特定の「X509証明書属性」値に対して検索されるLDAP識別名属性を定義します。

たとえば、証明書のサブジェクトEMAILがme@example.comで、それがLDAP属性の"mail"に一致する必要がある場合、LDAP問合せは、me@example.com (cn)という値を持つ"mail"属性をLDAPから検索する必要があります。

デフォルト: cn

X509証明書属性

公開鍵のバインドに使用される証明書属性を定義します(サブジェクト内の属性、証明書から抽出される発行者スコープ。たとえば、subject.DN、issuer.DN、subject.EMAIL)。

関連項目: この表の前半にある「一致するLDAP属性」

証明書検証有効

X.509証明書の検証を有効化(選択されていない場合は無効化)します。

有効化された場合、OAMサーバーは証明書検証を実行します(OAMサーバーに渡される前にWebLogicサーバーで証明書を捕捉して検証することはありません)。Access Managerが証明書のパス検証をすべて実行します。

OCSP有効

オンライン証明書ステータス・プロトコルを有効化(選択されていない場合は無効化)します。値はtrueまたはfalseです。次に例を示します。

OCSP有効: true

注意: 「OCSP有効」を選択した場合のみ、OCSPサーバー別名、OCSP応答者URLおよびOCSP応答者タイムアウトが必要です。

OCSPサーバー別名

.oamkeystoreファイルのCA証明書を指すOSCSP応答者の別名--別名およびOSCSP応答者インスタンスの実際のインスタンス名またはIPアドレスのマッピング。

OCSP応答者URL

オンライン証明書ステータス・プロトコル応答者のURLを入力します。たとえば、OpenSSLの応答者URLは次のようになります。

http://localhost:6060

OCSP応答者タイムアウト

証明書の更新前の限定された期間にOAMサーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。

16.6.2 ネイティブ認証モジュールの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証モジュールを変更できます。これには、既存のモジュール名の変更および他の属性の変更が含まれます。

前提条件

別の認証モジュールを使用するには、変更されるモジュールを参照する各認証スキームを変更します(必要な場合)。

注意:

デフォルトでは、LDAPモジュールは、Oracle Access Managementコンソールを保護する認証スキームで使用されます。管理者アクセスの安全を確保するために、LDAPモジュールは、システム・ストアとして指定したユーザー・アイデンティティ・ストアを参照する必要があります。指定したシステム・ストアを変更する場合、新しく指定したシステム・ストアを参照するようにLDAPモジュールも変更する必要があります。

認証モジュールを検索、表示または編集する手順

1. Oracle Access Managementコンソールで、次の順に移動します。
「システム構成」タブ
「Access Manager」セクション
「認証モジュール」ノード

2. 目的の「認証モジュール」ページを開きます。

3. 認証モジュール・ページで、必要に応じて情報を変更します。

- Kerberosモジュール: 表16-7を参照してください。

- LDAPモジュール: 表16-8を参照してください。

- X509モジュール: 表16-9と表16-15を参照してください。

4. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

5. 「認証スキームの管理」の手順に従って、更新された認証モジュールを認証スキームに追加します(または、このモジュールを参照する各認証スキームで、別の認証モジュールに変更します)。

16.6.3 ネイティブ認証モジュールの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証モジュールを削除できます。

次の手順は、カスタム認証モジュールとネイティブ認証モジュールのどちらを削除する場合でも同じです。

前提条件

削除するモジュールを参照している各認証スキームで、別の認証モジュールを指定します。

認証モジュールを削除するには、次の手順を実行します。

1. このモジュールを参照する各認証スキームでは、別の認証モジュールを指定します。

2. Oracle Access Managementコンソールで、次の順に移動します。
「システム構成」タブ
「Access Manager」セクション
「認証モジュール」ノード

3. オプション: モジュールを開いて削除するモジュールであることを確認してから、ページを閉じます。

4. 目的のモジュール名をクリックし、「削除」ボタンをクリックします。

5. 削除を確認します(またはモジュールを保持する確認ウィンドウを閉じます)。

16.7 プラグイン・ベースのモジュールによるマルチステップ認証の編成

認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

注意:

カスタム認証モジュールの作成には、認証プラグインを使用するようにお薦めします。

ここでは、次の内容について説明します。

- プラグインとマルチステップ認証モジュールの作成について

- マルチステップ認証のプラグイン・ベースのモジュールについて

- SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合

- プラグイン・ベースのマルチステップ認証モジュールの作成と編成

関連項目:

カスタム認証プラグインを作成する場合は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

16.7.1 単純フォーム認証とマルチファクタ(マルチステップ)認証の比較

単純フォームベースの認証は、デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタと、Access Manager認証メカニズムでユーザー・ログインを処理するWebフォームに依存します。単純フォームベースの認証は、デフォルトであるため、フォームをカスタマイズしないときには、追加の設定は必要ありません。

単純フォームベースの認証を使用する場合:

- すべての資格証明が1つの単純フォームで提供される場合。

- 資格証明の検証時および認証時。成功または失敗のステータスが返されます。

- これは失敗時に再試行できます。

関連項目:

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細

動的なマルチステップ認証のために、Access Managerは、独自にカスタマイズした認証モジュールで設計および編成できる、いくつかのプラグインを提供しています。認証プラグインは、特定のニーズを満たす処理を実現します。

また、管理者はAccess Manager用の複数のユーザー・アイデンティティ・ストアをインストールすることもできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。各認証プラグインは、別々のユーザー・アイデンティティ・ストアを使用するように構成できます。

DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、反復および変数)の認証プロセスを、次のように処理します。

- 必要な資格証明が、一度に提供されない場合。

- 認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。

- 成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンに必要な資格証明とコンテキスト・データが送信されます。

- 認証プラグインは、複数のステップで構成できます。

表16-10に、これら2つの形式の認証についての詳細を示します。

表16-10 単純フォーム認証とマルチステップ認証

認証方式

説明

フォームベースの簡易認証

単純フォームベースの認証は、資格証明コレクタ(ECCおよびDCC)と、Access Manager認証メカニズムを使用してユーザー・ログインを処理するWebフォームに依存します。これはデフォルトであるため、フォームをカスタマイズしないときには、追加の構成は必要ありません。

関連項目:

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細

マルチステップ認証

マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

マルチステップ認証は、次のものに依存しています。

- 認証のチェーン化: 複数の認証プラグインを新しい認証モジュールにチェーンして、そのモジュールを認証スキームに追加できます。

- チャレンジ・メカニズム: 必要な資格証明の収集方法を制御します。現在は、認証スキームに関連付けられています。ECCとDCCは同じチャレンジ・メカニズムを使用します。

- 資格証明コレクション: マルチステップ認証には、ECCまたはDCCのどちらかを使用できます。(DCCにより、ユーザーのアイデンティティを確立するための様々な方法を使用して認証関連情報を収集する際の、ユーザーとの対話またはプログラム・エンティティとの通信の柔軟性が大幅に向上します)。

関連項目:

「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」

カスタム認証プラグインの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

16.7.2 プラグインとマルチステップ認証モジュールの作成について

カスタム・プラグイン・ベースの認証モジュールは、既存のAccess Managerプラグインを使用して作成できます。Oracle Fusion Middleware Oracle Access Management開発者ガイドの説明に従って、ユーザー独自のプラグインを作成することもできます。

各プラグインは個別の機能部分を提供しており、これらは単独で使用するか、一連の手順につなぎ合わせて使用することができます。プラグインのライフサイクルは、プラグインをOAMサーバーに追加し、そのプラグインを使用して、OAMサーバーの拡張機能として動作する機能やワークフローを構築できるようにすることに中心が置かれています。各プラグインはJARファイルとしてデプロイされるので、各プラグインの構成要件はXML形式で指定する必要があります。

注意:

プラグインは、デフォルトの埋込みの資格証明コレクタ(ECC)か、オプションのデタッチされた資格証明コレクタ(DCC対応のWebゲート)のいずれかと連動します。標準(ネイティブの)認証モジュールは、非推奨になる予定です。将来の拡張機能は、標準モジュールでは使用できなくなる予定です。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。

図16-8は、Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから使用できるデフォルトのプラグインを示しています。カスタム認証モジュールを構築するためのステップを追加すると、これらのプラグインと、ユーザーがSDKや使用して作成したりインポートしたプラグインが、リストに表示されます。

図16-8 カスタマイズした認証モジュールのAccess Managerプラグイン

一般的に、「名前」によって、プラグインに依存するコンポーネントが定義されます。「説明」はオプションです。「タイプ」列は、プラグインの目的を示しています。「アクティブ化のステータス」によって、このプラグインがアクティブで使用可能かどうかがわかります。

関連項目:

ユーザー独自のカスタム・プラグイン構築の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。新しいプラグインをインポートしたり、カスタム・プラグインを配布、アクティブ化、非アクティブ化、削除することができます。

Oracle提供のプラグインを使用する場合も、ユーザー独自のプラグインを作成する場合も、カスタム認証モジュールの作成時にプラグインを追加することは同じです。

各カスタム・モジュールには、次のタイプの情報が必要です。

- 「一般」: 個々のプラグインの一意の名前とオプションの説明を識別します。

- 「ステップ」: 各プラグインの構成詳細(使用するユーザー・アイデンティティ・ストアを含む)に基づいて、使用する固有のプラグインと、その実行順序を識別します。

- 「ステップ編成」: 成功時、失敗時、またはエラー時に実行するアクションを指定します。

図16-9に、「システム構成」ツリーの「Access Manager」にある「カスタム認証モジュール」を示します。モジュールごとに、モジュールの情報を入力する3つのサブタブが表示されます。

図16-9 カスタム認証モジュールの作成: 「一般」

「図16-9 カスタム認証モジュールの作成: 「一般」」の説明

表16-11は、「一般」タブの内容について説明しています。

表16-11 「一般」タブ

要素

説明

名前

一意の名前で、60文字以内です。

説明

オプション。250文字以内です。

「ステップ」タブをクリックすると、新しいページが開き、そこで新規ステップを追加できます。新規のステップを追加するときには、次のダイアログ・ボックスが表示されます。ここで入力する情報を使用して、表と、ページの「詳細」セクションにデータが移入されます。

図16-10 ステップの追加とプラグインの関連付け

「図16-10 ステップの追加とプラグインの関連付け」の説明

表16-12では、新規ステップの追加に必要な情報について説明します。各ステップに1つのプラグインが必要です。また、各プラグインには、適切な操作のための具体的な詳細が必要です。

表16-12 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション

要素

説明

ステップ名

ステップを識別するために入力する一意の名前で、60文字以内です。

説明

ステップを追加するときにオプションで入力する、このステップの説明(250文字以内)。

プラグイン名

特定のステップに対して選択するプラグインです。インポートされアクティブ化されているプラグインのリストから選択します。

関連項目: カスタム・プラグインの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

ステップの詳細

正しい操作を確実に実行するために、プラグインの構成詳細を指定する必要があります。詳細の内容は、選択したプラグインと、そのプラグインの要件によって異なることがあります。

関連項目: 表16-13。

表16-13に、各種プラグインで必要になるプラグイン・パラメータの詳細を示します。この表に記載されていないプラグインのKerberosTokenIdentifier、FedAuthnRequestPluginおよびFedUserAuthenticationPluginは、例外的なプラグインです(これらのプラグインには、初期パラメータがありません)。

表16-13 各種プラグインのパラメータの詳細

プラグイン・パラメータ

表示名

説明

KEY_IDENTITY_STORE_REF

アイデンティティ・ストア名

認証時に適切なユーザー・アイデンティティ・ストアが呼び出されるようにするために、ほとんどのプラグインでこの属性が必要になります。

次のプラグインは、このプロパティのみを使用します。

- TAPAssertionPlugIn

このプロパティを採用するプラグインに必要な追加の詳細は、次を参照してください。

- UserIdentificationPlugIn

- UserAuthenticationPlugIn

- UserPasswordPolicyPlugin

- TAPUserAuthenticationPlugin

- TenantDisambiguationPlugin

UserIdentificationPlugIn

KEY_LDAP_FILTER

LDAPフィルタ

ユーザーを特定するために必要な検索フィルタです。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。

KEY_SEARCHBASE_URL

LDAP検索ベース

問合せに必要な検索ベースです。ディレクトリ情報ツリー(DIT)のノードです。このノード以下にユーザー・データが格納されるため、すべてのユーザー・データ検索の最高位のベースになります。

UserAuthenticationPlugIn

KEY_PROP_AUTHN_EXCEPTION

LDAPエラーの伝播

LDAPエラーの伝播を有効(または無効)にします。UserAuthenticationPlugInは、この属性を採用しています。

UserPasswordPolicyPlugin

PLUGIN_EXECUTION_MODE

操作モード

プラグイン(UserPasswordPolicyPlugin)の実行モードです。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。

- PSWDONLY: デフォルト。パスワードのステータスのみを決定する、最もお薦めされる構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。

- AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。

- AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。

POLICY_SCHEMA

使用するポリシー・スキーマ

パスワード・サービス(UserPasswordPolicyPluginで使用)のスキーマを指定します。OAM10Gのみがサポートされています。

デフォルト: OAM10G

NEW_USERPSWD_BEHAVIOR

初回ログイン時にパスワードの変更を強制

新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。UserPasswordPolicyPluginに使用します。値は、次のどちらかになります。

- FORCEPASSWORDCHANGE: パスワード変更を強制します。

- NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。

デフォルト: FORCEPASSWORDCHANGE

DISABLED_STATUS_SUPPORT

無効化されたアカウント・ステータスのサポート

無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。

デフォルト: TRUE

URL_ACTION

パスワード管理アクションURL

パスワード管理のために、ユーザーを移動するURLを指定します。ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。

- REDIRECT_POST

- REDIRECT_GET

- FORWARD

デフォルト: REDIRECT_POST

FedUserProvisioningPlugin

KEY_USER_RECORD_ATTRIBUTE_LIST

ユーザー属性のリスト

フェデレーション用です。ユーザー・レコードの作成に必要なアサーション属性を、カンマで区切ったリストです。

KEY_PROVIDERID_ATTRIBUTE_NAME

パートナ属性名

フェデレーション用です。LDAPユーザー・レコードの属性名です。このレコードの値は、ユーザーをプロビジョニングするときにパートナのアイデンティティ・プロバイダIDに設定されます。最初のフィールドはオプションであり、このフィールドを空にすると、パートナのアイデンティティ・プロバイダIDは、LDAPユーザー・レコードに設定されなくなります。

KEY_USERID_ATTRIBUTE_NAME

ユーザーのUserID属性

フェデレーション用です。LDAP UserIDとして使用されるアサーション属性の属性名です。

TAPIdentifyPlugIn

KEY_TAP_RETURN_ATTRIBUTE

ユーザー名マッピング属性

TAPIdentifyPlugInでアカウントをリンクするために使用する属性の名前です。

SequentialPlugInExecutionStrategy

StrategyName

編成戦略

SequentialPlugInExecutionStrategyに必要なプラグイン編成戦略の名前です。

KerberosTokenAuthenticator

KEY_KEYTAB_FILE

キー・タブ・ファイルの場所

Kerberosプリンシパルと暗号化されたキーを含むファイルの名前です。これは、KerberosTokenAuthenticatorに必要になります。

KEY_PRINCIPAL

OAMサービス・プリンシパル

OAMアカウントのSPNです。KerberosTokenAuthenticatorに必要になります。

KEY_KRB_CONFIG_FILE

Kerberos構成ファイルの場所

Kerberos構成プロパティ・ファイルの場所です。KerberosTokenAuthenticatorに必要になります。

KEY_DOMAIN_DNS2DN_MAP

ADドメインDNS名のDNへのマッピング

Active Directory DNSドメインのDNへのマッピングをカンマで区切ったリストです。KerberosTokenAuthenticatorに必要になります。

X509CredentialExtractor

KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT

ユーザーのマッピング属性

X509証明書属性です。X509CredentialExtractorに必要なユーザー・マッピングに使用します。

KEY_IS_CERT_VALIDATION_ENABLED

証明書検証

X.509証明書の検証を有効または無効にします。X509CredentialExtractorに必要になります。

TAPRequestPlugin

TAPS2PVersion

統合プロトコルのバージョン

統合用のトークン・バージョンです。

TAPPartnerId

統合PartnerId

統合パートナ識別子です。

TAPChallengeURL

パートナ統合のエンドポイントURL

リモート・パートナーのエンド・ポイントURLです。

TAPUserAuthenticationPlugin

KEY_USERNAME_ATTRIBUTE

ユーザー名マッピング属性

アカウントのリンクに使用される属性の名前です。TAPUserAuthenticationPluginに必要になります。

KEY_CHECK_TOKEN_EXPIRY

トークンの有効期限チェックの有効化

統合トークンの有効期限を有効または無効にします。

TenantDisambiguationPlugin

KEY_FEDERATED_TENANTS

FederatedTenantNames

フェデレーテッド認証が有効にされている、オプションの各テナントの名前(カンマ区切り)です。プラグインは、フェデレーション・エンジンにテナントの名前が記述されていないことを問い合せます。

RSA SecurIDプラグイン

username

ユーザー名パラメータ

ユーザー名プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

passcode

パスコード・パラメータ

パスコード・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

nexttoken

次のトークン・パラメータ

次のトークン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

newpin

新規PINパラメータ

新規ピン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

confirmnewpin

新規PINの確認パラメータ

新規pinの確認プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

HTTPTokenExtractor

KEY_HEADER_PROPERTY

HTTPヘッダー名

HTTPヘッダーのカンマ区切りのリストです。

KEY_COOKIE_PROPERTY

HTTP Cookie名

Cookieのカンマ区切りのリストです。

図16-11は、カスタム認証モジュールの「ステップ」サブタブと「詳細」セクションを示しています。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップを表に追加すると、「詳細」セクションに移入されます。

図16-11 プラグイン・ベースの認証モジュールの「ステップ」と「詳細」

「図16-11 プラグイン・ベースの認証モジュールの「ステップ」と「詳細」」の説明

図16-12は、カスタム認証モジュールの「ステップ編成」サブタブを示しています。このサブタブには、定義された各ステップ(および各操作条件に対して選択したアクション)の情報が移入されます。

図16-12 プラグイン・ベースの認証モジュールの「ステップ編成」

「図16-12 プラグイン・ベースの認証モジュールの「ステップ編成」」の説明

表16-14では、「ステップ編成」サブタブの要素について説明します。OnSuccess、OnFailure、OnErrorで選択できるリストの項目は次のとおりです。

- 成功

- 失敗

- StepName (モジュールの任意のモジュールを、操作条件のアクションとして選択できます)

表16-14 「ステップ編成」サブタブ

要素

説明

初期手順

リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。

名前

このモジュールに追加された各ステップが、追加するときに入力した名前別にリストされます。

説明

ステップを追加するときにオプションで入力した、このステップの説明。

OnSuccess

操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。

- 成功

- 失敗

- StepName (次のステップをアクティブ化します)

OnFailure

このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。

- 成功

- 失敗

- StepName (次のステップをアクティブ化します)

OnError

このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。

- 成功

- 失敗

- StepName (次のステップをアクティブ化します)

16.7.3 マルチステップ認証のプラグイン・ベースのモジュールについて

図16-13は、現在使用できるネイティブなプラグイン・ベースの認証モジュールのリストです。

図16-13 Oracle提供のプラグイン・ベースの認証モジュール

次の各項では、事前移入済のプラグインで提供されるネイティブなカスタム・モジュールのいくつかについて説明します。これらを使用すると、独自のカスタム認証モジュールを編成できます。

- KerberosPlugin

- LDAPPlugin

- X509Plugin

- パスワード・ポリシー検証モジュールとプラグイン

関連項目:

- 表16-13「各種プラグインのパラメータの詳細」

- 例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

KerberosPlugin

第43章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。

図16-14は、Access Manager 11gにバンドルされているKerberosPluginモジュールを示しています。これはリソースを暗号化された「Kerberosチケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。

図16-14 KerberosPlugin

「図16-14 KerberosPlugin」の説明

図16-15は、デフォルトのステップと詳細を示しています。図16-16は、ステップの編成と条件を示しています。

図16-15 デフォルトのKerberosPluginステップと詳細

「図16-15 デフォルトのKerberosPluginステップと詳細」の説明

図16-16 デフォルトのKerberosPluginステップと編成

「図16-16 デフォルトのKerberosPluginステップと編成」の説明

LDAPPlugin

図16-17は、Access ManagerにバンドルされているLDAPPluginモジュールを示しています。デフォルトでは、図16-18のようにLDAPPluginには2つのステップがあります。図16-19は、LDAPpluginのステップのデフォルト編成を示しています。

図16-17 LDAPPlugin

「図16-17 LDAPPlugin」の説明

図16-18 デフォルトのLDAPPluginステップと詳細

「図16-18 デフォルトのLDAPPluginステップと詳細」の説明

図16-19 LDAPpluginのステップのデフォルト編成

「図16-19 LDAPpluginのステップのデフォルト編成」の説明

X509Plugin

図16-20は、Access Manager 11gにバンドルされているX509Pluginモジュールを示しています。X509PluginはLDAPPluginと似ていますが、LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示すプロパティが追加されています。図16-21は、このプラグインのデフォルトのステップと詳細を示しています。図16-22は、X509Pluginのステップのデフォルト編成を示しています。

図16-20 X509Plugin

「図16-20 X509Plugin」の説明

図16-21 X509Pluginのデフォルト・ステップと詳細

「図16-21 X509Pluginのデフォルト・ステップと詳細」の説明

このプラグインでは、ルートとサブのCA証明書をDOMAIN_HOME/config/fmwconfig/amtruststoreに追加する必要があります。X509CredentialExtractorプラグインがこの場所から証明書をロードするからです。

表16-15では、stepX509のサブジェクトとサブジェクト代替名の値をリストしています。これらの処理は、X509Pluginの使用時のみサポートされます。

関連項目:

- 表16-13「各種プラグインのパラメータの詳細」

- 例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

表16-15 X509の「ステップの詳細」(KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)

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

図16-22 X509Pluginのステップのデフォルト編成

「図16-22 X509Pluginのステップのデフォルト編成」の説明

関連項目:

「SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合」

パスワード・ポリシー検証モジュールとプラグイン

Oracleでは、認証プロセスで次のプラグインを個別のステップとして採用するパスワード・ポリシー検証モジュールを提供しています。

- ユーザー識別ステップ

- ユーザー認証ステップ

- ユーザー・パスワード・ステータス・ステップ

図16-23は、「ステップ」タブを示しています。詳細は、図の後に説明します。

図16-23 パスワード・ポリシー検証モジュールのプラグイン

図16-24は、パスワード・ポリシー検証モジュールのプラグインの「ステップ編成」ページです。ステップの編成内容は、この図のとおりです。

関連項目:

- 表16-13「各種プラグインのパラメータの詳細」

- 「パスワード・ポリシーの理解」

図16-24 「ステップ編成」: パスワード・ポリシー検証プラグイン

16.7.4 SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合

Access Manager 11gはPIV (Personal Identity Verification)カード(米国連邦政府のスマート・カード)をサポートしており、これは、X.509認証時に、SubjectaltName拡張のFASC-NおよびEDIPI属性を使用してユーザーをマッピングするために使用されます。複数のOCSPプロバイダはサポートされませんが、OCSP Gatewayを使用するか、OSDT OCSP APIを使用するカスタム認証プラグインを作成することで、複数のOCSPプロバイダに対する検証を行うことができます。

次の機能は、X.509プラグイン(X.509認証モジュールではない)のみで使用できます。このプラグイン構成では、X.509クライアント証明書から抽出した属性のマップ先のLDAP属性を指定します。

例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

1. Oracle Access Managementコンソールで、次に示すように、既存のX509Pluginを編集します(またはカスタムX509プラグインを作成します)。
「システム構成」タブ
「Access Manager」セクション
「認証モジュール」ノード
「カスタム認証モジュール」ノード
X509plugin

関連項目:

「プラグイン・ベースのマルチステップ認証モジュールの作成と編成」

「一般」タブ:

1. 名前: CustomX509Plugin。

2. 「説明」: X509のカスタム・プラグイン

「ステップ」タブ:

1. 「+」をクリックして、プラグインにステップを追加します。

2. 「名前」と「説明」を入力して、「X509CredentialExtractor」プラグインを選択します。

「ステップの詳細」:

1. KEY_IS_CERT_VALIDATION_ENABLED: true

2. KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (表16-15): subject.EDIPI, subjectAltName.OTHER_NAME (FASC-N), subjectAltName.RFC822_NAME, subjectAltName.UNIFORM_RESOURCE_IDENTIFIER

3. 「Save」ボタンをクリックします。

別のプラグインの追加:

1. 「+」をクリックして、別のプラグインを追加します。

2. 「名前」と「説明」を入力して、UserIdentificationPluginを選択します。

2つ目のプラグインの「ステップの詳細」:

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」ボタンをクリックします。

5. 「ステップ編成」タブ(ステップ2)に進みます。

2. ステップの編成:

1. 「最初のステップ」: ドロップダウンから「X509CredentialPlugin」ステップを選択します。

2. 「成功時」: 「X509CredentialPlugin」ステップで、ドロップダウン・リストから「UserIdentificationPlugin」を選択します。

3. 「成功時」: 「UserIdentificationPlugin」ステップで、ドロップダウン・リストから「Success」を選択します。

4. 「失敗時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。

5. 「エラー発生時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。

6. 「適用」ボタンをクリックし、プラグインが正常に作成されたことを示す確認ウィンドウを確認します。

3. OCSPを使用して、「証明書検証」と「証明書失効」に証明書検証モジュールを設定します。

関連項目:

「グローバル証明書の検証および取消の管理」

1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト」セクションで、「有効」が選択されていることを確認し、「保存」をクリックします。

3. 「OCSP/CDP」セクションでOCSPを有効にし、OCSPのURLと、OCSPサーバーの証明書のサブジェクトを入力し、「保存」をクリックします。

4. コマンドラインでJavaのkeytoolアプリケーションを使用し、信頼できる証明書のエントリとして$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアに信頼できる証明書をインポートします。

注意:

初期状態ではキーストアは空です。パスワードは、Java keytoolアプリケーションを最初に使用するときに設定されます。

16.7.5 プラグイン・ベースのマルチステップ認証モジュールの作成と編成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、1つ以上の認証プラグインを使用するカスタム認証プラグイン・モジュールを作成できます。

この手順は、認証モジュールの一般ステップの概要を示しています(オンライン証明書ステータス・プロトコル(OCSP)を使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスするために、認証X509モジュールを構成する場合のサンプル情報も含んでいます)。

関連項目:

「例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法」

前提条件

モジュールに関連付けられているユーザー・アイデンティティ・ストアが実行中であり、必要なユーザー移入が含まれていることを確認します。

バンドルされているプラグインを使用してカスタム認証モジュールを作成する手順

1. 「システム構成」タブの「Access Manager」セクションから、「認証モジュール」ノードを展開します。

2. 新規作成:

1. 「カスタム認証モジュール」ノードをクリックします。

2. 「作成」(+)ボタンをクリックします。

3. 一般的な情報の追加: 「名前」と、オプションの「説明」。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。
「適用」をクリックして一般情報を保存します。

3. ステップの追加:

1. 「ステップ」サブタブをクリックします。

2. 「ステップ」表の上にある「追加」(+)ボタンをクリックします。

3. 「新規ステップの追加」ダイアログ・ボックスで、一意の「ステップ名」と、オプションで「説明」を入力します。

4. 目的のカスタム・プラグイン名(たとえば、X509CredentialExtractor)を参照して選択し、「OK」をクリックします。

5. 結果表の情報を確認します。

6. モジュールに必要なすべてのプラグインがリストされるまで、bからeを繰り返して他のステップを追加します。

4. 「ステップの詳細」の定義: 要求されるパラメータに適切な値を使用します(表16-12、表16-13、表16-16「カスタム・プラグインの管理アクション」および「例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法」)。

1. 表の「StepName」をクリックして必要な詳細を表示させ、必要な詳細に適切な値を入力します。

2. OCSPを使用したユーザー証明書の検証:
KEY_IS_CERT_VALIDATION_ENABLEDがtrueに設定されていることを確認します。

KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACTで抽出される証明書属性を追加します(表16-15):

subject.EDIPI
subjectAltName.OTHER_NAME (FASC-N)
subjectAltName.RFC822_NAME
subjectAltName.UNIFORM_RESOURCE_IDENTIFIER

3. 「Save」ボタンをクリックします。

4. 手順を繰り返し、各ステップを適切に構成します。

5. ステップで割り当てるユーザー・アイデンティティ・ストアに、ユーザーがプロビジョニングされていることを確認します。

5. ステップの編成: 表16-14を参照して、次の手順を実行します。

1. 「ステップ編成」サブタブをクリックします。

2. 「最初のステップ」リストで、使用する最初のステップの名前を選択します。

3. 表でステップ名を選択します。

4. 「OnSuccess」リストから、条件(成功または失敗)またはステップ名を選択します。

5. 「OnFailure」リストから必要な条件またはステップ名を選択します。

6. 「OnError」リストから必要な条件またはステップ名を選択します。

7. 手順cからfを繰り返し、このモジュールの各プラグインの操作を編成します。

8. 編成を確認します。

6. 方針の検証の開始: 「適用」をクリックして、編成方針の検証を開始します。

- 方針が正常な場合: 編成方針が適用され、認証スキームにモジュールを追加できるようになります。ステップ9と10を続行します。

- 方針が無効な場合: 「エラー」ボックスで「OK」をクリックし、OnSuccess、OnFailure、OnErrorの方針を編集(プラグインを追加または削除)して問題を修正します。方針が成功するまでこの手順を繰り返します。

7. ナビゲーション・ツリーで新しいカスタム認証モジュールがリストされていることを確認し、終わったらページを閉じます。

8. 「認証スキームの管理」の説明に従って、カスタム・モジュールを認証スキーム内で使用します。

16.8 個別の認証用プラグインのデプロイおよび管理

ここでは、次の内容について説明します。

- 独自の認証プラグインの管理について

- 個別の認証用プラグインのデプロイおよび管理

- カスタム認証プラグインの削除

16.8.1 独自の認証プラグインの管理について

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の情報を使用すると、カスタム認証プラグインを作成して、そのプラグインをカスタマイズしたマルチステップ認証モジュールの定義に使用できるようになります。

プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、管理者はOracle Access Managementコンソールを使用してプラグインを構成および配布できます。

サーバーは、プラグインJARファイル内のXML構成ファイルを処理し、プラグインに関するデータを抽出します。プラグインがインポートされた後、管理者はAdminServerから使用できる情報に基づいて様々なプラグインの状態を参照し、変更できます。

図16-25は、「システム構成」タブの「共通構成」セクションにあるプラグイン・ノードおよびプラグイン・ページを示しています。この「プラグイン」ページに含まれるツールバーのコマンド・ボタンは、その多くが表で選択されたプラグインに作用します。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。ページ最下部の「プラグインの詳細」セクションは、表内の選択されたプラグインの構成詳細を反映しています。

図16-25 「プラグイン」ページ

表16-16に示すように、管理者は「プラグイン」ページ上部の表の上にあるコマンド・ボタンを使用して、プラグインの状態を制御します。

表16-16 カスタム・プラグインの管理アクション

アクション・ボタン

説明

プラグインのインポート

プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。

- 同一のJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と一致する場合、Oracle Access ManagerはJAR(DOMAIN_HOME/oam/plugins内)のXMLファイルから新規構成メタデータを抽出し、新規プラグインのバージョンをチェックします。

- XMLバージョン: 新規プラグインXMLバージョン(DOMAIN_HOME/oam/plugins内)が既存のXMLバージョン(DOMAIN_HOME/config/fmwconfig/oam/plugins内)より新しい場合、検証は成功します。そうでない場合、無効なバージョンを持つ無効なプラグイン名が戻され、新規プラグインJARが削除されます(DOMAIN_HOME/oam/pluginsから)。

- 異なるJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と異なる場合、新規プラグインJARがアップロードされ、検証は成功します。

成功時: ステータスが「アップロード済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アップロード済」と報告し、AdminServerにおけるステータスも「アップロード済」となります。

失敗時: ステータスは「アップロードに失敗しました」と報告されます。

関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム・プラグインのライフサイクルに関する項

選択項目の配布

- 登録済のすべてのOAMサーバーにプラグインを伝播します。

- oam-config.xmlのプラグイン・フラグをDistribute=trueに設定します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerノードからDOMAIN_HOME/config/fmwconfig/oam/pluginsの下の各OAMサーバー・ノードに、プラグインJARを配布します。

成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。

失敗時: ステータスは「配布に失敗しました」と報告されます。

選択項目のアクティブ化

プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。

アクティブ化:

- oam-config.xmlのプラグイン・フラグをActivate=trueに更新します。

- AdminServerとOAMサーバーの間で、メッセージ・リスナーおよび通知メカニズムを起動します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。

成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。

失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。

すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。

選択項目の非アクティブ化

プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。

非アクティブ化:

- oam-config.xmlのプラグイン・フラグをDe-activate=trueに更新します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「非アクティブ化」を送信します。

- OAMサーバーは、AdminServerおよびOAMサーバーの両方のメッセージ・リスナーを使用して、AdminServerにステータス・メッセージを送信します。

成功時: ステータスが「非アクティブ化」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ化」と報告し、AdminServerにおけるステータスも「非アクティブ化」となります。oam-config.xmlからプラグイン構成が削除されます。

注意: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。

失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます。

選択項目の削除

プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスでは、Oracle Access Managerは次の処理を実行します。

削除:

- oam-config.xmlのプラグイン・フラグをRemove=trueに更新します。

- AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

- AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

- AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。

成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「削除済」と報告し、AdminServerにおけるステータスも「削除済」となります。oam-config.xmlからプラグイン構成が削除されます。

失敗時: ステータスは「削除に失敗しました」と報告されます。

表16-17では、プラグイン・ステータス表の要素について説明します。

表16-17 プラグイン・ステータス表

要素

説明

プラグイン名

XMLメタデータ・ファイルのプラグイン名要素から抽出されます。

説明

XMLメタデータ・ファイルの説明要素から抽出されます。

アクティブ化のステータス

AdminServerの情報に基づいてアクティブ化のステータスが報告されます。

タイプ

XMLメタデータ・ファイルのタイプ要素から抽出されます。

最終更新日

XMLメタデータ・ファイルの作成日要素から抽出されます。

最終更新者

XMLメタデータ・ファイルの作成者要素から抽出されます。

このページの「プラグインの詳細」セクションでは、表16-17に示すように、「アクティブ化のステータス」がAdminServerによって維持されます。

図16-26 「プラグインの詳細」: 選択したプラグインのアクティブ化のステータス

プラグインによっては、様々な構成詳細がXMLメタデータ・ファイルの構成要素から抽出され、「プラグインの詳細」セクションの「構成パラメータ」に移入されます。これらの例を表16-18に示します。また、表16-13も参照してください。

表16-18 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例

構成要素

説明

データソース

- <configuration>
- <AttributeValuePair>
<Attribute type="string" length="20">DataSource</Attribute>
<mandatory>true</mandatory>
<instanceOverride>false</instanceOverride>
<globalUIOverride>true</globalUIOverride>
<value>jdbc/CISCO</value>
<AttributeValuePair>
<configuration>

Kerberos詳細

このプラグインを使用するには、Kerberos詳細を定義します。

ユーザー識別詳細

このプラグインを使用するには、ユーザー・アイデンティティ・ストアおよびフィルタの詳細を定義します。

ユーザー認証詳細

このプラグインを使用するには、ユーザー・アイデンティティ・ストアを定義します。

X.509詳細

このプラグインを使用するには、証明書詳細を定義します。

16.8.2 カスタム・プラグインを使用可能にする手順

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

カスタム・プラグインの開発の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

カスタム認証プラグインを使用可能にする方法

1. プラグインをインポートします。

1. Oracle Access Managementコンソールに移動し、通常どおりログインします。次に例を示します。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

3. 「プラグインのインポート」ボタンをクリックします。

4. 「プラグインのインポート」ダイアログ・ボックスで、「参照」をクリックしてプラグインJARファイルの名前を選択します。

5. ダイアログ・ボックスのメッセージを確認し、「インポート」をクリックします。
Oracle Fusion Middleware Oracle Access Management管理者ガイドに示されているように、JARファイルが検証されます。

2. パラメータの構成: 「プラグインの詳細」セクションを開き、「構成パラメータ」をクリックして、必要に応じて適切な情報を入力します。次に例を示します。

3. プラグインをOAMサーバーに配布します。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の配布」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

4. プラグイン(およびカスタム・プラグイン実装クラス)をアクティブ化し、OAMサーバーで使用できるようにします。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目のアクティブ化」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

5. 必要に応じて次のタスクを実行します。

- 認証プラグインのアクティブ化ステータスのチェック

- カスタム認証プラグインの削除

- プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.8.3 認証プラグインのアクティブ化ステータスのチェック

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

カスタム・プラグインを使用可能にする手順

カスタム認証プラグインのアクティブ化ステータスをチェックする手順は、次のとおりです。

1. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

2. プラグイン表で、目的のプラグイン名をクリックして選択します。

3. サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。次に例を示します。

4. 必要に応じて次のタスクを実行します。

- カスタム認証プラグインの削除

- プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.8.4 カスタム認証プラグインの削除

有効な管理者資格証明を持つユーザーは、次の手順を使用してカスタム・プラグインを非アクティブ化してから削除できます。

管理者がカスタム認証プラグインを削除した場合、その名前はプラグインのリストから削除されません。プラグインを削除するには(同じプラグインを後で再インポートするため)、管理者はWebLogic Serverを停止し、oam-config.xmlを手動で編集する必要があります。

前提条件

プラグインが追加されており、コンソールで使用可能になっている必要があります。

カスタム認証プラグインを削除する手順は、次のとおりです。

1. Oracle Access Managementコンソールに移動し、通常どおりログインします。次に例を示します。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」を開きます。

3. プラグインの非アクティブ化: プラグインを削除する前に、これを実行する必要があります。

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の非アクティブ化」ボタンをクリックし、プラグインの「アクティブ化のステータス」をチェックします。

4. 非アクティブ化したプラグインの削除:

1. プラグイン表で、プラグイン名をクリックして選択します。

2. 「選択項目の削除」ボタンをクリックします。

3. WebLogic管理サーバーを停止し、oam-config.xmlの場所を確認し手動で編集して、非アクティブ化したプラグインを削除してから、WebLogic管理サーバーを再起動します。

5. 必要に応じて次のタスクを実行します。

- カスタム・プラグインを使用可能にする手順

- プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.9 認証スキームの管理

リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームには、定義済の認証モジュール(「個別の認証用プラグインのデプロイおよび管理」で説明した標準またはカスタムのモジュール)も含める必要があります。

コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインは、デフォルト・スキームとして設定される認証スキームを使用するポリシーでシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。

新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerberosSchemeというスキームをコピーすると、そのコピーの名前は「KerberosSchemeのコピー」になります。

この項の内容は次のとおりです。

- 認証スキームおよびページについて

- マルチレベル認証およびステップアップ認証の理解

- 認証スキームの作成

- 認証スキームの表示、編集または削除

- 認証スキームの検索

16.9.1 認証スキームおよびページについて

すべての認証スキームには、異なる値を使用した同じ要素が含まれます。図16-27は、例としてデフォルトのLDAPSchemeページを示しています。「認証スキーム」ナビゲーション・ツリーは、提供される他のデフォルト・スキームを示しています。

図16-27 デフォルトのLDAPSchemeページ

「図16-27 デフォルトのLDAPSchemeページ」の説明

表16-19は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。

表16-19 認証スキームの定義

要素

説明

名前

ナビゲーション・ツリーに表示されるこのスキームの一意の名前。

関連項目: 「事前構成済認証スキーム」

説明

このスキームの使用を示す200文字までのオプションの説明。

認証レベル

認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。

信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。

注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表17-1「リソース定義の要素」を参照してください。

注意: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ以下の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。

関連項目: 「マルチレベル認証およびステップアップ認証について」

デフォルト

「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。

チャレンジ・メソッド

リストの選択可能な項目からチャレンジ・メソッドを1つ選択する必要があります。

- フォーム

- Basic(LDAP)

- X509(証明書)

- WNA(Windows固有の認証)

- なし

- DAP

- OAM10g

関連項目: 「チャレンジ・メソッドについて」

チャレンジ・リダイレクトURL

このURLは、資格証明コレクタ(ECCまたはDCC)を参照するエンド・ポイントを宣言します。次に例を示します。

ECC: /oam/server

DCC: http://<dcc-host:port>/

関連項目:

- 「ホスト識別子について」

- 「DCC対応の11g Webgateと認証ポリシーの構成」

認証モジュール

ユーザーに資格証明を要求するために使用する事前構成済認証モジュールを指定します。ここで指定されたモジュールまたはプラグインによって、使用する正確なユーザー・アイデンティティ・ストアが指定されます。

- FederationMTPlugin

- FederationPlugin

- Kerberosプラグイン(「認証モジュール」と「カスタム認証モジュール」)

- MTLDAPBasic

- MTLDAPPlugin

- OIFMTLDAPPlugin

- パスワード・ポリシー検証モジュール

- TAPModule

- X509プラグイン(「X509認証モジュール」ノードの下)

関連項目: 「ネイティブ認証モジュールの管理」および「プラグイン・ベースのモジュールによるマルチステップ認証の編成」。

チャレンジURL

このURLは、指定されているチャレンジ・メソッド(FORMなど)に関連付けられます。

フォーム・ベースの即時利用可能な認証スキーム(LDAPSchemeおよびLDAPNoPasswordValidationScheme)の場合、チャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。

X509ベースのチャレンジURLは、次の形式で指定します。https://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509

注意: デフォルトのチャレンジURLは、OAMサーバーの組込み資格証明コレクタ(ECC)に基づいています。外部資格証明コレクタが有効化されたWebゲートと、Webゲートとともにインストールされる関連DCCページを使用している場合は、「DCC対応の11g Webgateと認証ポリシーの構成」を参照してください。

チャレンジ・パラメータ

サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータについて」を参照してください。

フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム

この後の要素は、チャレンジ・メソッドとしてフォーム、X509またはDAPを使用するスキームにのみ含まれます。他のスキームは、変更する必要がないデフォルトを使用します。

コンテキスト・タイプ

次の使用可能な値に基づいて、埋込み資格証明コレクタの最後のURLを作成するために使用します(ECC専用です。DCCには使用しません)。

- デフォルト: コンテキスト値を使用して、資格証明コレクションのために送信する最後のURLを作成します。たとえば、チャレンジURLが「/pages/login.jsp」、コンテキスト値が/oamの場合、サーバーはECCによる資格証明コレクションのために「/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チャレンジ・メソッドを使用したスキームのみ、表16-19の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。

- カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Access Managerは、カスタム・フォームをサポートしています(『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照)。

- CustomWarおよび外部コンテキスト・タイプでは、次の2つのタスクを実行するカスタム・ログイン・ページ内のロジックが必要になります。

- 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」などです。

詳細は、次の各項を参照してください。

- 事前構成済認証スキーム

- チャレンジ・メソッドについて

- 認証スキームのチャレンジ・パラメータについて

関連項目:

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびメッセージのカスタマイズの詳細

16.9.1.1 事前構成された認証スキーム

表16-20は、Access Managerで使用できる事前構成済認証スキームおよびそれぞれの固有の詳細を示しています。チャレンジ・パラメータの詳細は、表16-20を参照してください。

表16-20 事前構成済認証スキーム

スキーム名

指定

目的

AnonymousScheme

認証レベル: 0
チャレンジ・メソッド: なし
認証モジュール: AnonymousModule

特定のAccess Manager URLを保護されていない状態のままにするので、ユーザーは何も要求されずにこのURLにアクセスできます。ユーザーが要求されないので、資格証明を入力する必要はありません。

注意: 認証レベル0は、公開ページに使用されます。カスタム認証スキームにレベル0を使用しないことをお薦めします。

付記: リソースがAnonymousSchemeによって保護されている場合、セッション検索では表示されません。

BasicFAScheme

Oracle Fusion Applicationsのみ

Fusion Applications用

この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。

http://www.oracle.com/technetwork

BasicScheme

認証レベル: 1
チャレンジ・メソッド: Basic
認証モジュール: LDAP

ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

BasicSessionlessScheme

認証レベル: 1
チャレンジ・メソッド: Basic
認証モジュール: LDAP

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

チャレンジ・パラメータ: CookieLessMode=true

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

FAAuthScheme

Oracle Fusion Applicationsのみ

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP
コンテキスト: customWar
コンテキスト値: /fusion_apps

この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。

http://www.oracle.com/technetwork

FederationMTScheme

Oracle Fusion Applicationsのみ

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: FederationMTPlugin

コンテキスト・タイプ: customWar
コンテキスト値: /fusion_apps
チャレンジ・パラメータ: initial_command=NONE
is_rsa=true

この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。

http://www.oracle.com/technetwork

関連項目: 「認証スキームのチャレンジ・パラメータについて」

FederationScheme

Identity Federation 11.1.2のみ

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: FederationPlugin

コンテキスト・タイプ: customWar
コンテキスト値: /oam
チャレンジ・パラメータ: initial_command=NONE
is_rsa=true

関連項目: 第VII部: Oracle Access ManagementのIdentity Federationの管理

注意: Oracle Identity Federation 11.1.1では、Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明に従って、OIFSchemeを使用します。

KerberosScheme

認証レベル: 2
チャレンジ・メソッド: WNA
認証モジュール: Kerberos

コンテキスト・タイプ: customWar
コンテキスト値: /fusion_apps

Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

LDAPNoPasswordValidationScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAPNoPasswordAuthModule

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

注意: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。

この表の後半の「OAM10gScheme」も参照してください。

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

LDAPScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: customWar
コンテキスト値: /fusion_apps

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

OAAMAdvanced

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: 外部

外部コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの完全な統合が必要な場合、この認証スキームが使用されます。Webgateは、パートナのフロント・エンド処理を行う必要があります。

OAAMBasic

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

チャレンジ・パラメータ
oaamPostAuth=true
oaamPreAuth=true

デフォルト・コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの基本統合が必要な場合、このスキームを使用する必要があります。ここでは、OTPなどの拡張機能はサポートされません。エージェントとしてmod_ossoを使用する場合、統合機能のようになります。

OAM10gScheme

認証レベル: 2
チャレンジ・メソッド: OAM10G
認証モジュール: LDAPNoPasswordAuthModule

この表の前半の「LDAPNoPasswordValidationScheme」も参照してください。

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスの「enableCoexistMode」および「disableCoexistMode」

Oracle Access Manager 10gとの統合および共存を容易にします。共存モードでは、Oracle Access Manager 10gがオーセンティケータ、Access Manager 11gがアサーション・プロバイダになります。

このスキームには、特に「OAM10G」で説明されているようにOAM10gがOSSOと共存する場合は、チャレンジ・メカニズムOAM10Gが必要です。

OAMAdminConsoleScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

Oracle Access Management管理コンソールの認証スキーム。

OICScheme

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: TAPModule

コンテキスト・タイプ: 外部

チャレンジ・パラメータ:
TAPPartnerId=RPPartner
MatchLDAPAttribute=mail

Access Managerは、このスキームを使用して認証をMobile and Socialサービスに委任し、ユーザーを認証のためにMobile and Socialログイン・ページにリダイレクトします。

関連項目: 第IX部「Oracle Access Management Mobile and Socialの管理」

OIFScheme

Oracle Identity Federation 11.1.1のみ

Identity Federation 11.1.2の場合はFederationSchemeを使用します。

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: DAP

コンテキスト・タイプ: 外部

このスキームは認証をOIFに委任し、その後、Oracle Fusion Middleware Oracle Access Manager統合ガイドで説明されているように、Oracle Identity FederationがOAMサーバーによってアサートされているトークンを送信します。

委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。

チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner

関連項目: 「認証スキームのチャレンジ・パラメータについて」

OIMScheme

認証レベル: 1
チャレンジ・メソッド: フォーム
認証モジュール: LDAP

コンテキスト・タイプ: デフォルト
コンテキスト値: /oam

デフォルト・コンテキスト・タイプでOracle Identity Manager関連リソースを保護します。

注意: OAMおよびOIMを統合する場合、OAMは、次のいずれかが検出された場合にユーザーの認証レベルをダウングレードします。

パスワード期限切れ
強制的なパスワードの変更
未実行のチャレンジ設定

このため、ユーザーがリダイレクトされるアイデンティティ管理(OIM)ページの必要な操作を実行した後にのみ、ユーザーはページにアクセスできます。

レベル1の場合、必要な操作の公開ページおよびOIMページにのみアクセスできます。

注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。

OSSOCoexistMigrateScheme

OSSO 10gからAccess Manager 11gに移行されている環境のデフォルトの認証スキームとして設定します。

関連項目: Oracle Fusion Middleware Oracle Identity and Access Managementアップデート、アップグレードおよび移行ガイド

PasswordPolicyValidationScheme

認証レベル: 2
チャレンジ・メソッド: フォーム
認証モジュール: パスワード・ポリシー検証モジュール
コンテキスト: 外部

パスワード・ポリシー評価を有効にします。

TAPResponseOnlyScheme

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: DAP

TAPScheme

認証レベル: 2
チャレンジ・メソッド: DAP
認証モジュール: DAP

コンテキスト・タイプ: 外部

IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」でIDM製品リソースにTAPSchemeを使用するには、「認証スキーム」の変更に加えて、次の構成を行う必要があります。

1. IAM Suiteアプリケーション・ドメインの「Protected Higher Level Policy」から、IAMSuiteAgent:/oamTAPAuthenticateを削除します。

2. IAM Suiteアプリケーション・ドメインで、LDAPSchemeを使用する新しい認証ポリシーを作成します。

3. 新規作成したポリシーを使用して、IAMSuiteAgent:/oamTAPAuthenticateを保護します。

チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName

X509Scheme

認証レベル: 5
チャレンジ・メソッド: X509
認証モジュール: X509

この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。

注意: このスキームは、SSLに依存して、ユーザーのX.509証明書をOAMサーバーに送ります。

16.9.1.2 チャレンジ・メソッドについて

認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。Access Managerは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。

- フォーム

- 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クライアント証明書を確認する必要があります。

Access Managerに関連付けられているユーザー・アイデンティティ・ストアに対して、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認証モジュールに基づいています。

関連項目:

第43章: Windows固有の認証との統合の詳細

なし

なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。これは、AnonymousScheme認証スキームで使用されます。この認証スキームを使用すると、ユーザーは、保護しないAccess Manager固有のURLにアクセスできます。

DAP

委任認証プロトコル(DAP)チャレンジ・メソッドは、認証モジュールがDAP、コンテキスト・タイプが外部であるOIFScheme (Oracle Identity Federation 11.1.1統合)で必要です(表16-19)。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、Access Managerが受け取ったトークンのアサーションを実行します。

DAPModuleはアサーション・モジュールですが、このアプリケーション専用であり、Oracle Access Managementコンソールの認証モジュールのリストには表示されません。この統合により、OSSO 10gはAccess Manager 11gに置き換えられますが、Identity Federation側からの変更はありません。

DAPチャレンジ・メカニズムは、認証をサード・パーティ(この場合はIdentity Federation)に委任します。challenge_urlは、Identity FederationサーバーのURLを指しています。リソースがこのスキームで保護されている場合、OAMサーバーは資格証明コレクションのためにIdentity FederationサーバーURLにリダイレクトします。この場合、OAMサーバーは、資格証明の収集または検証を実行しません。Identity Federationは、資格証明を収集し、アイデンティティ・ストアに対してユーザーを認証して、ユーザー名で構成されるアサーション・トークンをOAMサーバーに返します。Access Managerは、このトークンを受信して復号化し、Oracle Access Managementのデフォルト・アイデンティティ・ストアでユーザーが有効なユーザーかどうかを確認します。ユーザーが有効な場合、Access Managerはリソースへのアクセスを付与します。

DAPTokenは、Access ManagerとIdentity Federationによって共有されるキーで暗号化および復号化されます。DAPTokenは、Access Manager側で構築されます。

Identity Federation管理EMコンソールでは、Access ManagerとIdentity Federationの間の通信を保護するために使用される暗号化鍵を含むキーストアを生成できます。Access ManagerのWLSTコマンド(registerOIFDAPPartner)は、Identity Federationストアによって生成されるキーストアの場所を受け取り、キーを取得して、Identity Federation側に格納します。

OAM10G

このメカニズムは、OSSO 10gと共存するOracle Access Manager 10g向けに作成されています。OAM10Gメソッドは常に認証/認可のプロバイダとして動作します。また、Oracle Access Manager 10gがドメインを保護し、さらにOSSO 10g統合クラシック・アプリケーション(Portal、Discoなど)を含んでいる場合に、OAM10gSchemeとLDAPNoPasswordAuthModuleを使用して信頼関係を円滑化するために、OAM10Gメソッドが必要です。

OSSO10GはWebgateを通じてOAM10Gチャレンジ・メソッドで保護されます。OAM10Gは、常に認証/認可プロバイダとして動作します。

統合の促進: OSSO 10g統合クラシック・アプリケーションをAccess Managerにアップグレードできます。その場合、Access Managerは、アサーション・プロバイダとしてのみ動作します。Access Managerは、これらのアプリケーションがアクセスできるように、mod_ossoが消費できるトークンを作成します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAMサーバーのフロント・エンド処理を行い、10gアクセス・サーバーに対して構成されているWebgateが存在します。

設定: リソースへのアクセスが行われると、Webgateはリクエストを捕捉し、認証のために10gアクセス・サーバーに送信します。Oracle Access Manager 10gは、資格証明を収集し、アイデンティティ・ストアに対して検証し、ヘッダー変数(OAM_REMOTE_USER)としてユーザー名を設定します。リクエストはOAMサーバーに移動し、OAMサーバーはOAM10gSchemeを使用してヘッダー変数のユーザー名を検索します。Access Managerは、ヘッダー変数を取得し、プライマリ・アイデンティティ・ストアに対してユーザーの存在をアサートします。存在する場合、必要なCookie(OAM_ID)が生成され、リソースにリダイレクトされます。

関連項目:

- 表16-20のOAM10gScheme

- Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのenableCoexistModeおよびdisableCoexistModeに関する項

16.9.1.3 認証スキームのチャレンジ・パラメータについて

チャレンジ・パラメータは、Webgateおよび資格証明コレクタ・モジュールによって使用および解釈される短いテキスト文字列で、その値で示された方法で動作します。

チャレンジ・パラメータは、次の構文で指定します。

<parmatername>=<value>

これは、Webgateのリリース(10gと11g)に固有の構文ではありません。認証スキームは、Webgateのリリースから独立しています。

表16-21は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。

表16-21 事前構成済スキームのチャレンジ・パラメータ

事前構成済スキーム

チャレンジ・パラメータ

BasicSessionlessScheme

CookieLessMode=true

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

FederationMTScheme

initial_command=NONE

主に、複数要因認証をサポートするFusion Applicationsに使用されます。

is_rsa=true

第42章「Integrating RSA SecurID Authentication with Access Manager」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、RSAマルチステップ認証で使用されます。

FederationScheme

Identity Federation 11.1.2のみ。Oracle Identify Federation 11.1.1の場合はOIFSchemeを使用します。

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

コンテキスト値: /fusion_apps
チャレンジ・パラメータ: initial_command=NONE
is_rsa=true

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

OAAMBasic

oaamPostAuth=true

oaamPreAuth=true

OAAM関連のリソースを保護します。これらのパラメータは、OAAMとの基本統合が必要な場合に使用します。

OIFScheme

Oracle Identify Federation 11.1.1のみ。Identity Federation 11.1.2の場合はFederationSchemeを使用します。

TAPPartnerId=OIFDAPPartner

このスキームは、認証をOracle Identity Federation 11.1.1に委任し、その後、FederationがOAMサーバーによってアサートされているトークンを送信します。

TapScheme

TAPPartnerId=TAPPartnerName

認証スキームは、リクエストをアクセス・サーバーに送信する前に、コンテキスト固有の情報を収集できます。コンテキスト固有の情報は、情報の外部コールの形を取ることができます。表16-22に、認証スキームで使用できるユーザー定義チャレンジ・パラメータを示します。

表16-22 認証スキームのユーザー定義チャレンジ・パラメータ

チャレンジ・パラメータ

定義

initial_command=NONE

収集対象の資格証明を指示する場合に必要です。

たとえば、フォームベースの認証の場合、通常、このフレームワークではログイン・ページから送信される「username」と「password」を収集することになります。ただし、ログイン・ページの別のフィールド(たとえば、「form_username」と「form_password」)からの資格証明が必要になることがあります。このチャレンジ・パラメータを設定すると、初期制御をログイン・ページからプラグインに移すことができます。このプラグインで、ログイン・ページから収集するパラメータを判断してから、ログイン・ページに適切に転送またはリダイレクトします。

デフォルト: 空白(未設定)

action=

actionパラメータは、ハード・コードされたECCデフォルトの/oam/server/auth_cred_submitを使用しないときに、HTMLフォームのポスト先URLを指定します。

注意: ECCは、action=パラメータを使用しません。action=チャレンジ・パラメータが指定されていない場合、DCCとECCは、どちらもデフォルトの/oam/server/auth_cred_submitを使用します。

関連項目: 「PasswordPolicyValidationSchemeの構成」

creds=

DCCのみ

外部資格証明コレクタ(DCC)でのみサポートされます。

次の例では、usernameとpasswordは、ログイン・フォームの該当するフィールドの名前です。

creds=username password

次に、もう一つの例を示します。

creds:source$name

このsourceは、次のいずれかを指します(省略時は次の順序でソースを検索します)。

server (他のWebサーバー・プラグインによって設定される変数)
header (HTTPヘッダー変数)
post (ポストされたデータ)
query (問合せ文字列データ)
cookie (HTTP Cookie)

Webサーバーのソース(サーバー・パラメータ)は、他のソースより優先されます。これにより、ユーザーが設定するリクエスト・データがWebサーバーのデータをオーバーライドすることが防止されます。たとえば、ユーザーから送信されたremote_user Cookieは、Webサーバーによって設定されたremote_user変数を上書きしません。

一般に、フォームベースのチャレンジ・メソッドを使用する認証スキームで保護されているログイン・フォームをユーザーが送信すると、DCCは、このcreds=パラメータで指定された資格証明を処理します。

METHOD=POST処理を使用するフォームの場合、リクエストの本体にフォームからの資格証明データを付けてブラウザがPOSTリクエストをWebサーバーに送信します。フォームでMETHOD=GETが使用されている場合は、credsパラメータに指定されたものと同じ名前を持つ問合せ文字列パラメータを付けてブラウザがGETリクエストを送信します。可能な場合はPOSTプロセスを使用することをお薦めします。

注意: credsパラメータは、他のタイプのチャレンジ・メソッドにも指定できます。プラグインでcredsパラメータを使用する場合、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、ObUserSessionオブジェクトのobMap資格証明パラメータで渡す内容を指定します。

関連項目: 「PasswordPolicyValidationSchemeの構成」

extracreds=

DCCのみ

DCCでのみサポートされます。オプションのパラメータを指定します。オプションのパラメータが存在するときには、DCCを使用するマルチステップ認証の各反復時に、認証プラグインは、そのパラメータを収集できるようになります。

extracredsパラメータは、credsパラメータと同じ構文を使用します。extracreds=で分離した修飾名または非修飾名の[{any | cookie | header | server | query | post}:] <name>になります。ただし、値anyは、extracredsにのみ使用します。次に例を示します。

extracreds=[{any | cookie | header | server | query | post}:] <name>

関連項目: 「PasswordPolicyValidationSchemeの構成」

OverrideRetryLimit=0

ログインのRetryLimitを上書きする試行回数です。

値は正整数である必要があります。

0を指定すると、この機能は無効になります。

関連項目: 「PasswordPolicyValidationSchemeの構成」

MaxPostDataBytes=

ユーザーの資格証明として送信され、OAMサーバーに送信されるPOSTデータの最大バイト数を制限します。

関連項目: 「PasswordPolicyValidationSchemeの構成」

ssoCookie=

OAMAuthnCookie Cookieを制御します。「暗号化Cookieのチャレンジ・パラメータの構成」を参照してください。

デフォルト:

ssoCookie=httponly

ssoCookie=Secure

次のどちらかの設定で無効化されます。

ssoCookie=disablehttponly

ssoCookie=disableSecure

注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

- 外部資格証明コレクタが有効化された11g Webgateの場合、これらのパラメータはエージェント登録ページで直接設定します。

- DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキーム内のユーザー定義チャレンジ・パラメータを通じて構成します。

関連項目:

表16-23「10g/11g暗号化Cookieのチャレンジ・パラメータ」

miscCookies=

その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。

デフォルト:

miscCookies=httponly

miscCookies=Secure

次のどちらかの設定で無効化されます。

miscCookies=disablehttponly

miscCookies=disableSecure

注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

- 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページで直接設定します。

- DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは同じ名前のチャレンジ・パラメータを通じて構成します。

関連項目:

表16-23「10g/11g暗号化Cookieのチャレンジ・パラメータ」

「PasswordPolicyValidationSchemeの構成」

DCCCtxCookieMaxLength=

DCCのみ

DCC Cookieの最大長を定義します。

デフォルト:4096

関連項目: 詳細は、この表のTempStateModeを参照してください。

TempStateMode=

次に示すパラメータの値(cookieまたはform)での指定に応じて、DCCがOAMサーバーの状態を格納する方法を制御します。

- form: デフォルトです。OAMサーバーの状態は、フォーム・パラメータのOAM_REQを通じて格納され渡されます。これにより、OAMサーバーの構成がserverRequestCacheType=COOKIEのときに、肥大化したサーバーの状態がDCCCtxCookieの制限を超えて異常な動作が発生することを防止します。
Cookieキャッシュ・モードは、デフォルトのCOOKIEモードからFORMモードへ変更できます。FORMモードは、長いURLで機能します。動作における唯一の違いは、プログラム認証用であり、OAM_REQパラメータ・セットをフォームに渡すためには適切なフォームの提出が必要になるということです。カスタム資格証明収集ページで、フォームと一緒に提出されるOAM_REQパラメータを処理する必要があります。

- cookie: このパラメータと値を追加すると、OAMサーバーの状態はDCCCtxCookieの一部(encdata=… svrctx=…)を通じて格納されます。ただし、serverRequestCacheType=COOKIEまたは=FORMのときに、結果のCookie長がブラウザの制限を超えると、異常な動作が発生することがあります。

注意:

- serverRequestCacheType=COOKIEの場合は、TempStateMode=formをお薦めします。

- serverRequestCacheType=BASICの場合は、どちらのモードでもかまいません。

serverRequestCacheTypeを更新する場合は、WLSTコマンドのconfigRequestCacheTypeを使用します。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。Oracle Access Managementコンソールを使用したserverRequestCacheTypeの編集は、サポートされていません。

ECCの場合: serverRequestCacheTypeでは、OAMサーバーがサーバーの状態をメモリー内(BASIC)に格納するか、メモリー外(FORMまたはCOOKIE)に格納するかを指示します。serverRequestCacheType = COOKIEまたはFORMは、ECCを使用する場合にのみ効果に違いがあります。OAMサーバーは、サーバーの状態をリクエスト・トークンに格納します。ECCは、パラメータでの指定(たとえば、serverRequestCacheType=COOKIE)に応じて、Cookieまたは非表示のフォーム・フィールドにこれを保持します。

DCCの場合: serverRequestCacheType=COOKIEまたはFORMに違いはありません。TempStateModeは、DCCがOAMサーバーの状態を格納する方法(cookieまたはform)を、パラメータ値の指定(たとえば、TempStateMode=cookie)に応じて制御します。

関連項目: 「DCC対応の11g Webgateと認証ポリシーの構成」

16.9.2 マルチレベル認証およびステップアップ認証の理解

ここでは、次の内容について説明します。

- マルチレベル認証およびステップアップ認証について

- OAMエージェントによる不十分な認証レベルの検出

- 10g OSSOエージェントを使用したマルチレベル認証の処理

16.9.2.1 マルチレベル認証およびステップアップ認証について

各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。

- LDAPScheme authLevel=1

- KerbScheme authLevel=2

注意:

マルチレベル認証は、X.509証明書の認証に影響を与えず、X.509証明書の認証を否定または変更しません。

SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。特定のレベルのユーザーの認証に成功した後、ユーザーは、1つ以上のアプリケーション・ドメインで保護された1つ以上のリソースにアクセスできます。ただし、アプリケーション・ドメインで使用される認証スキームは、同じレベル(または下位のレベル)にする必要があります。ユーザーが現在のSSOトークンのレベルを超える認証レベルで保護されたリソースにアクセスする場合、再認証されます。ステップアップ認証の場合、高いレベルで示されるチャレンジに失敗しても、ユーザーは現在のレベルのアクセスを維持します。これは「追加認証」です。

注意:

レベル3のリソースへのアクセスを認証されているユーザーは、3以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。

Access Managerポリシーでは、同じアプリケーションの複数のリソースを複数の認証レベルで保護できます。ただし、mod_ossoプラグインは、異なる信頼レベルの同じアプリケーションの2つのリソースをサポートしません。

注意:

mod_ossoは、Access Managerに認証を委任します。mod_ossoで保護されたリソースは、Access Manager認証レベルで保護することをお薦めします。

その場合、アプリケーションはそのレベルを適用し、再認証するために動的ディレクティブをmod_ossoに送信する必要があります。動的ディレクティブを受信すると、mod_ossoは、適切なレベルで再認証するためにAccess Managerにリダイレクトします。

どちらのエージェント・タイプでも、ユーザーをOAMサーバーにリダイレクトして再認証します。リソースのポリシーに構成された認証スキームのレベルに応じて、チャレンジが示されます。

登録されたエージェントは、次に示すように認証レベルを検出します。

- OAMエージェントは、OAMサーバーから不十分なレベルのエラー・メッセージを受け取ります(「OAMエージェントによる不十分な認証レベルの検出」を参照してください)。

- mod_ossoは、動的ディレクティブから認証レベルを検出します(「10g OSSOエージェントを使用したマルチレベル認証の処理」を参照してください)。

関連項目:

例は、Oracle Fusion Middleware Oracle Identity Management Suite統合ガイドの「Oracle Access ManagerとOracle Adaptive Access Managerの統合」の章を参照してください。すでに認証されているユーザーが、Access Managerを使用して低い認証レベルの別のリソースにアクセスします。ユーザーはすでに認証されているので、Oracle Adaptive Access Managerはユーザー名およびパスワードを入力するページを表示しません。ただし、Oracle Adaptive Access Managerで実行されるフローは、ユーザーがOracle Adaptive Access Managerにすでにログインしているかどうかによって異なります。

16.9.2.2 OAMエージェントによる不十分な認証レベルの検出

ユーザーが高いレベルの認証スキームで保護されるリソースをリクエストすると、次のプロセスが発生します。

プロセスの概要: OAMエージェントによる不十分なセッション・レベルの検出

サーバー側で認証レベルの確認は行われません。次の例は、10g OAMエージェントについての説明です。

注意:

11g OAMエージェントは、エージェントごとに個別のOAMAuthnCookiesに関連付けられます。

1. OAMエージェントはリクエストをOAMプロキシに送信し、保護されたリソースのスキーム詳細を取得します。

2. OAMエージェントは、セッション情報のリクエストをOAMプロキシに送信します。

3. OAMプロキシは、認証されたレベルのObSSOCookieを含むObSSOCookieの詳細を戻します。

4. OAMエージェントは、ObSSOCookieのレベルを認証スキームのレベルと比較します。

- 不十分な場合、エージェントは認証プロセスを再起動します。

- 十分な場合、アクセス権が付与されます。

16.9.2.3 10g OSSOエージェントを使用したマルチレベル認証の処理

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プロキシ)は再認証を要求します。

- レベルが十分な場合、アクセス権が付与されます。

16.9.3 認証スキームの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインで使用される新しい認証スキームを追加できます。

前提条件

認証モジュールは、定義済であり使用できる状態であることが必要です(「個別の認証用プラグインのデプロイおよび管理」を参照)。

関連項目:

- 「認証スキームおよびページについて」

- 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」(必要な場合)

認証スキームを作成するには、次の手順を実行します。

1. Oracle Access Managementコンソールで、次に進みます。
「ポリシー構成」タブ
「共有コンポーネント」ノード
「認証スキーム」ノード

2. 「認証スキーム」をクリックし、ツール・バーの「作成」ボタンをクリックします。

3. 新しい「認証スキーム」ページ(表16-19)で、デプロイメントに応じて次の情報を入力します。

1. 名前: LDAPSimpleFormScheme

2. 認証レベル

3. チャレンジ・メソッド: フォーム

4. チャレンジ・リダイレクトURL: http://CredentialCollectorhost:port

5. 認証モジュール: LDAP

6. チャレンジURL: /CredentialCollector/loginform...

7. チャレンジ・パラメータ: 表16-21、表16-22、表16-23

8. コンテキスト・タイプ

4. 「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

7. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認します(必要に応じて、ツリーを更新してください)。

8. 「特定のリソースの認証ポリシーの定義」に進みます。

16.9.4 認証スキームの検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定の認証スキームを検索できます。

関連項目:

「コンソールを使用した検索の実行」

認証スキームを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「認証スキーム」を選択して、検索を定義します。

3. テキスト・フィールドに目的のスキーム名を(ワイルドカード(*)の使用は任意)入力します。次に例を示します。

OA*

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

- 編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。

- 削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

- 連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

16.9.5 認証スキームの表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを表示または変更できます。

注意:

認証ポリシーに関連付けられている認証スキームを削除しようとすると、関連付けの詳細が表示され、確認を求められます。ポリシーが関連付けられていない場合、スキームは削除されます。

関連項目:

- 「認証スキームおよびページについて」

- 「PasswordPolicyValidationSchemeの構成」

認証スキームを表示または変更するには、次の手順を実行します。

1. Oracle Access Managementコンソールで、目的のスキームを開きます。
「ポリシー構成」タブ
「共有コンポーネント」ノード
「認証スキーム」ノード
DesiredScheme

2. 編集:

1. 「認証スキーム」ページで、環境に合わせて値を変更します(表16-19)。

注意:

OSSOエージェントを使用するアップグレード済のデプロイメントでは、SSOCoExistMigrateSchemeを使用するように、この認証スキームとすべての保護されたリソース・ポリシーを変更します。

2. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

3. 確認ウィンドウを閉じます。

3. デフォルトとして設定: 新しいアプリケーション・ドメインでポリシーを作成する際にこのスキームが自動的に使用されるようにするには、「デフォルトとして設定」ボタンをクリックして「確認」ウィンドウを閉じます。

4. 削除:

1. この認証スキームを使用しているアプリケーション・ドメインがあるかどうかを確認し、あれば別のスキームを割り当てます。

2. 「認証スキーム」ページを確認してこれが削除するスキームであることを確認し、ページを閉じます。

3. ナビゲーション・ツリーでスキームの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。

4. 削除を確認します(または確認ウィンドウを閉じます)。

16.10 暗号化Cookieのチャレンジ・パラメータの構成

ここでは、次の内容について説明します。

- 暗号化Cookieのチャレンジ・パラメータについて

- 暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

- 暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

16.10.1 暗号化Cookieのためのチャレンジ・パラメータ

Access Managerは、OAMサーバーCookie (OAM_ID)に加えて、暗号化Cookieを使用してシングル・サインオンを実装します。

- 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>
注意: 有効なOAMAuthnCookieがセッションに必要です。

- 10g Webgate、すべての10g Webgateに対してObSSOCookieを1つ。

Access Managerが提供するssoCookieチャレンジ・パラメータは、Webgateによる暗号化Cookieのフラグの設定方法を制御するために任意の認証スキーム内で使用できます。次に例を示します。

- 暗号化Cookieの保護: 暗号化CookieがSSL接続を介してのみ送信され、暗号化CookieがセキュアでないWebサーバーに返信されないようにできます。

- 暗号化Cookieの永続性: ユーザーが、単一のセッションではなく、一定期間ログインできるようにします。Cookieの永続機能は、Internet ExplorerおよびMozillaブラウザと連動します。

注意:

チャレンジ・パラメータの値は、大文字/小文字が区別されません。どのリリースのWebゲートでも、構文は同じです。単一の値は、等号(=)の後ろに指定します。

ssoCookie=value

複数の値は、セミコロン(;)で区切る必要があります。次に例を示します。

ssoCookie=value1;value2;...

- 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページ(表13-2)で直接設定します。

- DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキームのチャレンジ・パラメータ(表16-23)を通じて構成します。

表16-23は、Webgateがシングル・サインオンの暗号化Cookieのフラグを設定する方法を制御する、特定のチャレンジ・パラメータを示しています。

表16-23 10g/11g暗号化Cookieのチャレンジ・パラメータ

暗号化Cookieの11g/10g Webgateチャレンジ・パラメータの構文

説明

ssoCookie=

SSO CookieのOAMAuthnCookieのフラグを制御するパラメータです。

miscCookies=

その他すべてのAccess Manager暗号化Cookieのフラグを制御するパラメータです。

Secure

HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。

ssoCookie=Secure
miscCookies=Secure

disableSecure

セキュアCookieを明示的に無効にします。

ssoCookie=disableSecure
miscCookies=disableSecure

httponly

11g Webgate SSO OAMAuthnCookieと、その他のCookieをデフォルトで有効にします。

ssoCookie=httponly
miscCookies=httponly

disablehttponly

httponly機能を明示的に無効にして、クライアント側のスクリプトが暗号化Cookieにアクセスできるようにします。

ssoCookie=disablehttponly
miscCookies=disablehttponly

ssoCookie=max-age=time-in-seconds

ブラウザ内に永続Cookieを作成します。これは、1つのセッションの間保持されるものではなく、Cookieの有効期限は時間間隔in-secondsで指定します。

たとえば、Cookieを30日(2592000秒)で期限切れにするには、次のように設定します。

max-age=2592000

16.10.2 暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

チャレンジ・パラメータは、大文字/小文字が区別されません。

関連項目:

「認証スキームの作成」

暗号化Cookieを保護する手順は次のとおりです。

1. 認証スキームを作成します。

2. 「チャレンジ・パラメータ」フィールドで、目的の暗号化Cookie(表16-23)の指定内容を入力します。

3. 付録Cの説明に従って、OAMサーバーとクライアント(OAMエージェント)が、Oracle Accessプロトコル・チャネルを介してセキュアに通信していることを確認します。

16.10.3 暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

チャレンジ・パラメータは、大文字/小文字が区別されません。

関連項目:

「認証スキームの作成」

暗号化Cookieの永続性を定義する手順は次のとおりです。

1. 認証スキームを定義します。

2. このスキームのチャレンジ・パラメータのセクションで、次を追加します(表16-23)。
Webgate ssoCookie=max-age=time-in-seconds

16.11 パスワード・ポリシーの理解

ここでは、次の内容について説明します。

- あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

- Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

- 資格証明コレクタとパスワード・ポリシーの検証について

16.11.1 あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

Access Managerは、資格証明の収集時にユーザーとの対話用にいくつかのページを提供します(資格証明コレクタのパスワード・ページを参照)。この場所は、デプロイする認証スキームのトポロジーに応じてカスタマイズできます。

表16-24 資格証明コレクタのパスワード・ページ

資格証明コレクタ

説明

ECCページ

デフォルトの埋込み資格証明コレクタのjspフォーム。デフォルトでOAMサーバーに配置されます。

- ログイン・ページ: /pages/login.jsp

- ログアウト・ページ: /pages/logout.jsp

- エラー・ページ: /pages/servererror.jsp

- マルチステップ認証ページ: /pages/mfa.jsp

DCCページ

DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webgateホストの次の項目を参照してください。

- WEBGATE_HOME/webgate/ohs/oamsso/*

- WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl(login、logoutおよびsecuridスクリプトの最初の行にあるPerlの場所を更新してください)

- WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*

関連項目:

ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

表16-25に、提供されるパスワード・フォームを示します。デフォルト・ページは企業の要求に合せてカスタマイズしたり、すべてをカスタム・ページと置き換えたりできます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。

表16-25 パスワード管理フォームと機能

フォーム

機能

サインイン・フォーム

「ユーザーID」と「パスワード」フィールドを表示する標準的なログイン・フォームです。「ログイン」ボタンをクリックすると、認証モジュールによって制御される認証プロセスが開始されます。

ログイン・フォームのカスタマイズ方法の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

サインイン・エラー

この標準のログイン・フォームはエラーが発生したときに表示されます。赤く表示された文字は、エラーを示します。このエラーは表示と非表示を指定できます。

表示と非表示の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

パスワードの期限切れの通知

次のメッセージは、通知ポリシーに従って、ユーザーにパスワードの期限が切れることを通知するために表示されます。

パスワードの変更フォーム

パスワードの期限切れポリシーの構成に従って、ポリシーを施行し、ユーザーにパスワードの変更を要求する次のウィンドウが表示されます。

パスワードの変更の成功

次のパスワードの変更が成功したことを確認するメッセージが表示されます。

ユーザー・アカウントのロックまたは無効化

許可される最大ログイン試行回数の範囲内で、パスワード・ポリシーに基づいて指定した資格証明が拒否された場合は、ユーザー・アカウントのロックアウトが発生します。

16.11.2 Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

図16-28は、Oracle Access Managementコンソールで表示した「パスワード・ポリシー」ページを示しています。管理者はこのページで、企業の要求に従ってポリシーを定義します。

図16-28 パスワード・ポリシー構成ページ

表16-26は、構成可能なパスワード・ポリシーの要素の説明です(コンソールの左から右の順番に記載されています)。これらの要素は、ECCとDCCの両方で使用します。

表16-26 パスワード・ポリシーの要素

要素

説明

最小大文字数

パスワードに必要な大文字の最小数を定義します。

最小小文字数

パスワードに必要な小文字の最小数を設定します。

最小英字数

パスワードで許可される特殊文字の最小数を定義します。

最小数字数

パスワードに必要な数字の最小数を設定します。

最小英数字数

パスワードに必要な英数文字の最小数を定義します。

最小特殊文字数

パスワードに必要な特殊文字の最小数を設定します。

最大特殊文字数

パスワードで許可される特殊文字の最大数を定義します。

最小Unicode文字数

パスワードに必要なUnicode文字の最小数を定義します。

最大Unicode文字数

パスワードで許可されるUnicode文字の最大数を設定します。

パスワードの最小文字数

パスワードに必要な合計の最小文字数を設定します。

最大パスワード長

パスワードで許可される合計の最大数文字数を定義します。

必須の文字

パスワードに必要な特定の文字を定義します。この定義にはデリミタは必要なく、また使用できません。

許可されていない文字

パスワードで使用可能な特定の文字を設定します。この定義にはデリミタは必要なく、また使用できません。

許可されている文字

パスワードで許可されるすべての文字を定義します。この定義にはデリミタは必要なく、また使用できません。

許可されていないサブ文字列

パスワードで許可されない特定の文字列です。この定義ではカンマをデリミタとして使用します。

アルファベットで始まる

選択時は、パスワードの先頭文字に英文字が必要であることを指定します。

姓の許可

選択時は、ユーザーの姓がパスワードに含まれることを許可します。

名の許可

選択時は、ユーザーの名がパスワードに含まれることを許可します。

ユーザーIDの許可

選択時は、ユーザーのユーザーIDがパスワードに含まれることを許可します。

警告までの時間

ユーザーにパスワードが期限切れになることをいつ(何日前に)警告するかを定義します。

最大試行回数

ユーザーがロックアウトになるまでに行えるログイン試行回数を示します。

有効期限切れまでの時間

パスワードの有効期間(日数)を定義します。

ロックアウト期間

指定された回数だけログイン試行が失敗した後に、ユーザーがロックアウトされる期間(分単位)を示します。この期間の後、ユーザーは新たにログインを試行できます。

永続的ロックアウト

指定された回数だけログイン試行が失敗した後の永続的ロックアウトを指定します。

姓の禁止

ユーザーがパスワードを変更するとき、いくつ前のパスワードまで使用できないかを定義します。

パスワード辞書ファイル

パスワードで指定できない禁止単語のリストを含むOAMサーバー上の物理ファイルを示します。

パスワード・ファイル・デリミタ

パスワード辞書ファイルでいくつかのワードを区切るために使用するデリミタを定義します。たとえば、ファイルの内容がabc,def,welcomeで、辞書のデリミタがカンマ(,)の場合、ユーザー・パスワードで禁止され、使用できない単語はabc defとwelcomeです。

パスワード・サービスURL

いくつかのパスワード・ページの場所です。

16.11.3 資格証明コレクタとパスワード・ポリシーの検証について

資格証明コレクションにどの方法を選択していても、1つのグローバル・パスワード・ポリシーを構成して、Access Managerで(認証スキームのパスワード・ポリシー検証モジュールを使用して)保護するリソースのすべてに適用することになります。また、資格証明コレクタと関連するフォームに対応するURLは、表16-27で説明したように指定する必要があります。

表16-27 認証用の資格証明コレクタと関連フォームの指定

指定する場所

ECCの場合

DCCの場合

OAMエージェント登録

DCCのみ

なし。

OAMエージェント登録ページの「管理操作の許可」の横にあるチェック・ボックスを選択します。

関連項目: 「DCCの資格証明操作の有効化」

ログイン、エラーおよびパスワード・ページ

ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。

- ログイン・ページ: /pages/login.jsp

- ログアウト・ページ: /pages/logout.jsp

- エラー・ページ: /pages/servererror.jsp

- マルチステップ認証: /pages/mfa_login.jsp

DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。

Webgateホストのディレクトリ(WEBGATE_HOME/webgate/ohs/oamsso/*、WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよびWEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*)で、次を参照してください。

- ログイン・ページ: /oamsso-bin/login.pl

- ログアウト: /oamsso-bin/logout.pl

- RSA SecurIDログイン・ページ: /oamsso-bin/securid.pl

DCCベースのログインおよびログアウトを行うPerlスクリプト

Perl実行ファイルのパス名は、Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるOracle提供のPerlスクリプト内で、実際の場所と一致するように更新する必要があります。

関連項目: 表16-5「DCCとECCの比較」

パスワード・ポリシー、パスワード・サービスURL

Default/ECCのパスワード・ページが自動的に使用されます。

ECCのパスワード・サービスURL: /oam/pages/pswd.jsp

関連項目: 「グローバル・パスワード・ポリシーの定義」

DCCパスワード・ページに次を入力します。

DCCのパスワード・サービスURL: /oamsso-bin/login.pl

関連項目: 「パスワード・ポリシーのDCCフォームの検索と更新」

ユーザー・アイデンティティ・ストア

Access Managerスキーマのユーザー・データー・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、ldapaddツールを使用して各ユーザー・アイデンティティ・ストアに追加する必要があります。オラクル社が提供するLDIFについて表16-28に示します。

DCCとECCのどちらについても同じです。

関連項目:

- 「デフォルト・ストアへのキー・パスワード属性の追加」

- 「パスワードの変更後ユーザー属性を変更するために管理者を追加」

パスワード・ポリシー検証認証モジュール

3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。

関連項目:

- 表16-13「各種プラグインのパラメータの詳細」

- 「パスワード・ポリシー検証認証モジュールの構成」

DCCとECCのどちらについても同じです。

認証スキーム、チャレンジ・リダイレクトURL

資格証明コレクタのホストを入力します。

- ECCの場合、相対URI形式: /oam/server (serverにhost:portを付加します)

関連項目: 「PasswordPolicyValidationSchemeの構成」

資格証明コレクタのホストを入力します。

- DCCの場合、完全URL: http://dcchost:port

- DCCがリソースWebgateと一体化されている場合: 空のままにします

関連項目: 「PasswordPolicyValidationSchemeの構成」

認証スキーム、チャレンジURL

資格証明コレクタのログイン・フォームの相対URIを入力します。

- ECCの場合: /pages/login.jsp

関連項目: 「PasswordPolicyValidationSchemeの構成」

資格証明コレクタのログイン・フォームの相対URIを入力します。

- DCCの場合: /oamsso-bin/login.pl

関連項目: 「PasswordPolicyValidationSchemeの構成」

認証スキーム、チャレンジ・パラメータ

ECC: ユーザー定義のチャレンジ・パラメータ:

OverrideRetryLimit=0
initial_command=NONE

関連項目:

- 表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」

- 「PasswordPolicyValidationSchemeの構成」

DCC: ユーザー定義のチャレンジ・パラメータ:

- creds

- extracreds

- MaxPostDataBytes

- DCCCtxCookieMaxLength

- TempStateMode

関連項目:

- 表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」

- 「PasswordPolicyValidationSchemeの構成」

サーバー・エラー・モード

DCCとECCのどちらについても同じです。

関連項目: 「パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定」

DCCとECCのどちらについても同じです。

関連項目: 「パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定」

認証ポリシー

認証ポリシーの資格証明コレクタ:

- ECC: 保護Webgate(リソースWebgate)のアプリケーション・ドメイン内のECC用に構成された認証スキームを使用します。

関連項目: 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」

認証ポリシーの資格証明コレクタ:

リソースWebgateから独立したDCC:

***保護(リソース)Webgateアプリケーション・ドメイン(リソースを保護する
認証ポリシー)は、DCC関連の認証スキームを使用します。

***DCC Webgateアプリケーション・ドメイン、
リソースを保護する認証ポリシーは、
DCC関連の認証スキームを使用します。次の事項を考慮します:

--アクションURLなし: DCCは、デフォルトの/oam/server/auth_cred_submitを使用します。これは、DCC関連の認証スキームで自動的に保護されます。

--アクションURLあり: 指定したアクションURLを
DCCスキームで明示的に保護します。

関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」

ログアウト構成

ECC:

保護(リソース)Webgateエージェントの登録で、「ログアウトURL」を構成します。表13-3「拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素」を参照してください。

「11g Webgateの集中ログアウト構成」を参照

DCC:

- DCCエージェントの登録ページでは、「ログアウト・リダイレクトURL」は無視されます。

- 保護(リソース)Webgate登録で、次のように定義します。
ログアウト・リダイレクトURL:
http//dcchost:port/oamsso-bin/logout.pl

注意: リソースWebgateのログアウト・リダイレクトURLがlogout.*以外の場合、そのURLはDCC Webgate登録のログアウトURLパラメータで定義する必要があります。例:

リソースWebgate登録に
ログアウト・リダイレクトURL
http//dcchost:port/someurl.html

がある場合、DCC Webgate登録には
ログアウトURL: someurl.htmlを含める必要があります。

- DCC: Oracle提供のスクリプト内のPerlパスは、更新する必要があります。

「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」を参照

統合デプロイメントの注意事項

Oracle Internet Directoryで、Oracle Identity ManagementとOracle Access Managementを使用する場合、2種類のパスワード・ポリシー定義および施行が存在します。

- Oracle Identity ManagementとOracle Internet Directoryの両方のパスワード・ポリシー定義

- 次のいずれかで、パスワード・ポリシーを施行します。
Oracle Access Managementは、Webアクセスの間に状態ポリシー(間違ったパスワードなど)を施行します。Oracle Internet Directoryは独自の状態ポリシーとLDAP処理(バインドや比較など)を施行します。

Oracle Identity Managementは、パスワード更新のユーザー作成の間に値ポリシー(パスワードの特性)を施行します。Oracle Internet Directoryは独自の値ポリシーとLDAP処理用のポリシー(追加や変更など)を施行します。

1つのポリシー・セットのみを使用する場合は、次のいずれかを実行します。

1. Oracle Internet DirectoryポリシーをOracle Identity ManagementおよびOracle Access Managementポリシーよりも低い優先度か同じ優先度にします。ただし、これにより2つの施行が発生します。

2. ネイティブのLDAPパスワード・ポリシー検証を無効にします。ただし、直接のLDAP操作に対するポリシー施行もなくなります。

16.12 グローバル・パスワード・ポリシーの管理

認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。

Access Managerの認証プロセスは、認証モジュール(またはプラグイン)を使用して、要件およびバックエンド認証スキームへの情報転送を制御するルールを定義します。デフォルトで、Access Managerは、認証処理に対するOAMサーバー埋込み資格証明コレクタ(ECC)の使用をサポートしています。ただし、外部資格証明コレクタ(DCC)を使用するように、11g Webgateを構成することもできます。

ECCとDCCは、どちらも資格証明が一度に提供されない場合のマルチステップ認証フローを簡単にできます。これにより、認証関連の情報を収集するための、ユーザーやプログラム的なエンティティとの対話処理の柔軟性が向上します。複数要因による認証の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

資格証明コレクションにどの方法(デフォルトのECCまたはオプションのDCC)を選択していても、この項で説明するようにグローバル・パスワード・ポリシーを構成して、Access Managerで保護されたすべてのリソースに適用できます。

前提条件

- あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

- Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

- 資格証明コレクタとパスワード・ポリシーの検証について

次に示す概要では、このパスワード・ポリシーを構成および使用する方法について説明している項へのリンクを示します。特に明記しないかぎり、すべてのタスクはECCとDCCに同様に適用できます。ご使用のデプロイメントに該当しないタスクは省略してください。

タスクの概要: パスワード・ポリシー管理のタスクは次のとおりです。

1. グローバル・パスワード・ポリシーの定義

2. デフォルト・ストアへのキー・パスワード属性の追加

3. パスワードの変更後ユーザー属性を変更するために管理者を追加

4. パスワード・ポリシー認証の構成

5. DCC: DCC対応の11g Webgateと認証ポリシーの構成

6. パスワード・ポリシー構成の完了

7. マルチステップ認証のテスト

16.12.1 グローバル・パスワード・ポリシーの定義

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、企業で定義された要件に基づいた共通のパスワード・ポリシーを定義できます。

注意:

ECCとDCCのグローバル・パスワード・ポリシーの唯一の相違点は、パスワード・サービスURLです。これは、資格証明コレクタ固有であり、デフォルトは手順2で示すようにECCページです。

この例の仕様は、説明の目的のみに使用されているものです。環境はユーザーによって異なります。

Oracle Access Managementでパスワード・ポリシーを構成するには

1. 「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。
「システム構成」タブ
「共通構成」セクション
「パスワード・ポリシー」

2. 「パスワード・ポリシー」ページで、目的の資格証明コレクタのログイン・ページ(ECCまたはDCC、表16-27)のパスワード・サービスURLを入力します。

ECCのパスワード・サービスURL

DCCのパスワード・サービスURL

/pages/login.jsp

/oamsso-bin/login.pl

3. 「パスワード・ポリシー」ページで、企業の要件に基づいた値(表16-26)を入力します。次に例を示します。

- 警告までの時間: 3

- 有効期限切れまでの時間: 20

- 永続的ロックアウト: (無効)

- ロックアウト期間: 1

- 最小特殊文字数: 1

4. 「適用」をクリックして、ポリシーを送信します。

5. それぞれの環境に合せて次の手順に進みます。完了済のタスクはスキップしてください。

- デフォルト・ストアへのキー・パスワード属性の追加

- パスワードの変更後ユーザー属性を変更するために管理者を追加

16.12.2 パスワード・ポリシー用のデフォルト・ストアの指定

パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。管理者のロールと資格証明は、システム・ストアに存在している必要があります。

関連項目:

「デフォルト・ストアおよびシステム・ストアの設定」

グローバル・パスワード・ポリシーにデフォルト・ストアを指定するには

1. Oracle Access Managementコンソールで、「システム構成」タブを開き、「ユーザー・アイデンティティ・ストア」ノードを開きます。
「システム構成」タブ
「共通構成」セクション
「データソース」ノード
「ユーザー・アイデンティティ・ストア」ノード

2. システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。

1. システム・ストアとして指定するストアのページを開きます。

2. 「システム・ストアとして設定」をクリックします(ドメイン全体の認証および認可操作用)。

3. 「適用」をクリックします。

4. 管理者の追加: 「管理者ロールの管理」を参照してください。

5. 認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。

6. このストアを使用するように、1つ以上の認証プラグインを構成します。詳細は、「プラグイン・ベースのモジュールによるマルチステップ認証の編成」を参照してください。

3. デフォルト・ストアの設定: このストアは、パッチ適用時のパスワード・ポリシー、セキュリティ・トークン・サービスおよび移行に必要です。

1. デフォルト・ストアとして指定するストアのページを開きます。

2. 「デフォルト・ストアとして設定」の横にあるボックスを選択します。

3. 認証モジュール: OAMAdminConsoleSchemeを見つけて、LDAPモジュールがこのストアを参照していないことを確認します。「ネイティブ認証モジュールの管理」を参照してください。

4. 認可ポリシー条件: 認可ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。認証ポリシー条件の定義を参照してください。

5. トークン発行ポリシー条件: トークン発行ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。「トークン発行ポリシー、条件およびルールの管理」を参照してください。

4. 登録ページを閉じます。

16.12.3 デフォルト・ストアへのキー・パスワード属性の追加

パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。この項では、Oracle Access Managementのパスワード・ポリシー処理のデフォルト・ストア・スキーマを拡張する手順を説明します。

- デフォルト・ストア・スキーマの拡張について

- デフォルト・ストア・スキーマのパスワード・ポリシー属性の拡張

16.12.3.1 デフォルト・ストア・スキーマの拡張について

Access Managerの一部として配布されているLDIF (Lightweight Directory Interchange Format)ファイルは、必須のオブジェクト・クラスでスキーマを拡張するためのものです。一般に、これらを適用するには、idmConfigToolを使用するか、手動で連結してあるAccess ManagerとOracle Identity Managementを使用します。

Access Managerスキーマのユーザー・データー・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、ldapaddツールを使用して各ユーザー・アイデンティティ・ストアに追加する必要があります。オラクル社が提供するLDIFについて表16-28に示します。

注意:

OAM_HOMEホームには、Oracle Access Managementをホストするためにインストールされているファイルが含まれます。OAM_HOMEホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。

表16-28 LDAPプロバイダ用のオラクル社提供LDIFのロケーション

LDAPプロバイダ

LDIFロケーション

OID: Oracle Internet Directory

$OAM_HOME/
oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif

OVD: Oracle Virtual Directory

$OAM_HOME/
oam/server/pswdservice/ldif/OVD_PWDPersonSchema.ldif

AD: Microsoft Active Directory

$OAM_HOME/
oam/server/pswdservice/ldif/AD_PWDPersonSchema.ldif

SJS: sun Java System Directory

$OAM_HOME/
oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif

eDirectory: Novell eDirectory

$OAM_HOME/
oam/server/pswdservice/ldif/ED_PWDPersonSchema.ldif

ODSEE: Oracle Directory Server Enterprise Edition

$OAM_HOME/
oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif

OUD: Oracle Unified Directory

$OAM_HOME/
oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif

SLAPD: OpenLDAP Directory

$OAM_HOME/
oam/server/pswdservice/ldif/OLDAP_PWDPersonSchema.ldif

IBM: OBM Tivoli Directory

$OAM_HOME/
oam/server/pswdservice/ldif/TIVOLI_PWDPersonSchema.ldif

パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性を表16-29に示します。各ユーザー・アイデンティティ・ストアのユーザー・データ・オブジェクトには、表16-29に示す属性を含める必要があります。これらは、ldapaddツールを使用して、LDIF (Lightweight Directory Interchange Format)ファイルに追加できます。

表16-29 パスワード・ポリシーのキー・パスワード属性

属性

説明

書式および値

obPasswordCreationDate

日付と時刻(ユーザー・ログインの時点)です。パスワードの有効期限が切れているかどうか、また警告を発行する必要があるかどうかを計算するために使用します。

YYYY-MM-DDThh:mm:ssZ

obPasswordHistory

最後に使用されたパスワードの数を追跡するために使用します。Access Managerは、10g oblixPersonPwdPolicyの書式を認識して、新しい書式に変換します。

新しい書式: password1###password2###

以前の書式:

passwordX = SHA256 (password+canonical userid)

obPasswordChangeFlag

初回ユーザー・ログイン時のパスワード変更の強制(または、管理者が開始したパスワード変更の強制)に使用します。

ブール文字列値。

true | false

空の文字列は、falseを意味します。

obuseraccountcontrol

無効になったユーザーを表します。

暗号化されていない文字列値。

activated | deactivated

空の文字列は、activatedを意味します。

obpasswordexpirydate

この時刻以降は、ユーザー・パスワードが期限切れであるとみなされます。

YYYY-MM-DDThh:mm:ssZ

空の値は、not expiredを意味します。

obLockoutTime

この時刻までは、ログインの試行回数が多すぎるために、ユーザーがロック・アウトされるとみなされます。

時期値(秒単位)は、将来の時間を表します。

Seconds (1970年1月1日を基点とする)

obLoginTrvCount

ユーザーによるログインが連続して失敗した回数。このカウンタは、最初に正しいパスワードが入力された時点でリセットされます。

暗号化されていない整数値。

1、2、3など。

obLastSuccessfulLoginTime

前回成功したログインの時間。

YYYY-MM-DDThh:mm:ssZ

obLastFailedLoginTime

前回失敗したログインの時間。

YYYY-MM-DDThh:mm:ssZ

16.12.3.2 パスワード・ポリシー属性によるデフォルト・ストア・スキーマの拡張

環境が idmConfigTool -prepareIDStoreを使用して構成されている場合、このタスクをスキップできます。

ユーザー・アイデンティティ・ストアがoblixスキーマで拡張されていない場合は、このスキーマを更新して、パスワード・サービスに必要なオブジェクト・クラスを含める必要があります。

LDAPツールは、OAM_HOME配下の/binディレクトリから実行する必要があります。次の手順は、Oracle Internet Directoryスキーマの拡張方法を示しています。環境によっては異なることがあります。

デフォルト・ユーザー・アイデンティティ・ストア・スキーマを拡張するには

1. 次のコマンドを使用して、パスワード・サービスに必要な、指定されたデフォルト・ストアのOracle Internet Directoryオブジェクトを更新します。

ldapadd -D "cn=orcladmin" -w <password> –h <hostname> -p 3060 –x -f $OAM_HOME/
oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif

2. 「パスワードの変更後ユーザー属性を変更するために管理者を追加」に進みます。

16.12.4 パスワードの変更後ユーザー属性を変更するために管理者を追加

この手順では、デフォルト・ストア(この例ではOracle Internet Directory)を変更して、別の権限が与えられたアカウントをバインドDNとして使用します。これにより、パスワードの変更後、ユーザー属性を変更可能な権限が与えられます。

前提条件

サポートされているLDAPストアを登録し、デフォルト・ストアに指定します。追加したユーザーがデフォルト・ストア内で定義されていることを確認します。

関連項目:

「管理者ロールの管理」

図16-29は、指定されたデフォルト・ストアの完成した登録ページを示しています。この図の次に管理者の追加手順を示します。

図16-29 新しい管理者が指定されたデフォルト・ストア

新しい管理者を追加するには

1. 通常どおり、Oracle Access Managementコンソールにログインします。

https://hostname:port/oamconsole/

2. 目的の「ユーザー・アイデンティティ・ストア」登録ページを開きます。
「システム構成」タブ
「共通構成」セクション
「データソース」ノード
「ユーザー・アイデンティティ・ストア」ノード
OID

3. 新しい管理者を追加します。

1. このページの「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。

2. ダイアログ・ボックスで、すべてのユーザーを検索し、desireduserを強調表示して、「選択済の追加」をクリックします。

3. 「適用」をクリックして変更を送信します。

4. デフォルト・ストア: 指定したデフォルト・ストアであることを確認(または「デフォルト・ストア」をクリック)して、「適用」をクリックします。

5. 「パスワード・ポリシー認証の構成」に進みます。

16.13 パスワード・ポリシー認証の構成

パスワード・ポリシー、デフォルト・ストアおよび管理者の準備が完了すると、この項で説明するように、認証モジュールとスキームを作成できるようになります。

- パスワード・ポリシー検証認証モジュールの構成

- PasswordPolicyValidationSchemeの構成

- 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」: DCCを使用している場合は、この項をスキップして、「DCC対応の11g Webgateと認証ポリシーの構成」に進みます。

16.13.1 パスワード・ポリシー検証認証モジュールの構成

デフォルト・ストアを使用するには、パスワード・ポリシー検証認証モジュールも構成する必要があります。

注意:

認証用のパスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。

サンプル・モジュールを図16-30に示します。ユーザー・パスワードのステータス・ステップは、UserPasswordPolicyPluginに基づく一意のステップです。

図16-30 パスワード・ポリシー検証認証モジュールと編成済プラグイン

各ステップは、特定の名前付きプラグインが提供するアクションを特定します。

関連項目:

「プラグイン・ベースのモジュールによるマルチステップ認証の編成」および 表16-18。

図16-31は、認証モジュール内でのステップの編成を示しています。モジュールとステップの詳細は、「プラグイン・ベースのマルチステップ認証モジュールについて」を参照してください。

図16-31 パスワード・ポリシー検証モジュールのステップ編成

表16-30では、指定したパスワード・ポリシー検証モジュール・ステップの詳細を説明します。

表16-30 ユーザー・パスワード・ステップの詳細

ステップ名

ステップの詳細

説明

ユーザー識別ステップ

KEY_LDAP_FILTER

KEY_LDAP_FILTER属性にLDAPフィルタを追加します。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。次に例を示します。

(uid={KEY_USERNAME})

関連項目: アイデンティティ・ストアの正確な構文は表17-22「Access ManagerのLDAP検索フィルタの例」 およびベンダーのドキュメントを参照

KEY_IDENTITY_STORE_REF

モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。

デフォルト: 登録済デフォルト・ストア

KEY_SEARCH_BASE_URL

ユーザーの検索のベースURL。次に例を示します。

dc=us,dc=example,dc=com

ユーザー認証ステップ

KEY_IDENTITY_STORE_REF

モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。

デフォルト: 登録済デフォルト・ストア

KEY_PROP_AUTHN_EXCEPTION

LDAPエラーの伝播を有効または無効にします。

ユーザー・パスワード・ステータス・ステップ

PLUGIN_EXECUTION_MODE

プラグインの実行モード。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。

- PSWDONLY: パスワードのステータスのみを決定する、最も推奨される構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。

- AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。

- AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。

デフォルト: PSWDONLY

KEY_IDENTITY_STORE_REF

モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。

デフォルト: 登録済デフォルト・ストア

NEW_USERPSWD_BEHAVIOR

新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。値は、次のどちらかになります。

- FORCEPASSWORDCHANGE: パスワード変更を強制します。

- NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。

デフォルト: FORCEPASSWORDCHANGE

POLICY_SCHEMA

パスワード・サービスのポリシー・スキーマ。現在はOAM10Gのみがサポートされています。

デフォルト: OAM10G

URL_ACTION

ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。

- REDIRECT_POST

- REDIRECT_GET

- FORWARD

デフォルト: REDIRECT_POST

DISABLED_STATUS_SUPPORT

無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。

デフォルト: TRUE

前提条件

グローバル・パスワード・ポリシーの定義

注意:

パスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。

パスワード・ポリシー検証モジュールを構成するには

1. 「システム構成」タブで、次の項目を開きます。
「Access Manager」セクション
「認証モジュール」
「カスタム認証モジュール」
パスワード・ポリシー認証モジュール

2. 「ステップ」タブをクリックします。3つのステップのそれぞれに、KEY_IDSTORE_REFの横のフィールドで デフォルト・ストア名を追加します(それぞれの変更で保存します)。次に例を示します。

1. ユーザー識別ステップ
KEY_IDSTORE_REF: OID

保存:

2. ユーザー認証ステップ
KEY_IDSTORE_REF: OID

保存:

3. ユーザー・パスワード・ステータス・ステップ
KEY_IDSTORE_REF: OID

保存:

3. 「適用」をクリックします。

4. 「PasswordPolicyValidationSchemeの構成」に進みます。

16.13.2 PasswordPolicyValidationSchemeの構成

グローバル・パスワード・ポリシーには複数の認証スキームを使用することができます。管理者の資格証明を持つユーザーは、この手順に従って、PasswordPolicyValidationSchemeを構成できます。

注意:

ECCとDCCの値の相違点(表16-27)には、次の項目が含まれます。

- チャレンジ・リダイレクトURL: 資格証明コレクタのホストとポート

- チャレンジURL: 資格証明コレクタのページ

- チャレンジ・パラメータ: 表16-22

図16-32のスキーム例は、ECC用に構成されています。認証スキームは、ユーザーによって異なります。

図16-32 ECC PasswordPolicyValidationSchemeの例

前提条件

パスワード・ポリシー検証認証モジュールの構成

関連項目:

「認証スキームの管理」

PasswordPolicyValidationSchemeを構成するには

1. 「システム構成」タブで、次の項目を開きます。
「ポリシー構成」タブ
「共有コンポーネント」
「認証スキーム」
PasswordPolicyValidationScheme

2. 使用環境のスキームを設定します。次に例を示します。

- 認証レベル2

- デフォルト(空白)

- チャレンジ・メソッド: フォーム

- チャレンジ・リダイレクトURL: http://CredCollector_host:port/

- 認証モジュール: パスワード・ポリシー検証モジュール

- チャレンジURL: /CredCollector_pages/

- コンテキスト・タイプ: 外部

- チャレンジ・パラメータ:

ECCチャレンジ・パラメータ

DCCチャレンジ・パラメータ

OverrideRetryLimit=0
initial_command=NONE

OverrideRetryLimit=0
creds=userid password

関連項目: 表16-22、「認証スキームのユーザー定義チャレンジ・パラメータ」

action
指定していない場合、ECCとDCCは、どちらもデフォルトの/oam/server/auth_cred_submitになります。

DCCCtxCookieMaxLength
(デフォルトは4096)

TempStateMode
パラメータ値での指定に応じて、DCCがOAMサーバーの状態をCookieで格納するか、フォーム(デフォルト)で格納するかを制御します。

MaxPostDataBytes
ユーザーの資格証明として送信さるPOSTデータの最大バイト数を制限します。

creds
渡すパラメータをObUserSessionオブジェクトのobMap資格証明パラメータで指定する必要があります。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

3. 「適用」をクリックします。

4. 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」に進みます。

16.13.3 ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加

管理権限を持つユーザーは、保護Webゲート(リソースWebゲート)のアプリケーション・ドメインで、ECC用に構成したPasswordPolicyValidationSchemeを使用できます。

前提条件

PasswordPolicyValidationSchemeの構成

ECC認証ポリシーにPasswordPolicyValidationSchemeを追加するには

1. ECC: コンソールで、該当するアプリケーション・ドメインを検索して開きます。(「既存のアプリケーション・ドメインの検索」を参照)。

関連項目:

「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」

2. ECC: PasswordPolicyValidationSchemeを使用してリソースを保護します。

1. 「認証ポリシー」タブで保護されたリソース・ポリシーを探して開きます(「認証ポリシーの表示または編集」を参照)。
認証ポリシー
保護されたリソース・ポリシー

2. 保護されたリソース・ポリシー(認証スキーム)の「PasswordPolicyValidationScheme」を選択して、「適用」をクリックします。

3. 認可および認証ポリシーの更新を終了します(第17章を参照してください)。

3. それぞれの環境で必要に応じて次に進んでください。

- ECC: 「パスワード・ポリシー構成の完了」

- DCC: DCC対応の11g Webgateと認証ポリシーの構成

16.14 DCC対応の11g Webgateと認証ポリシーの構成

ECCを使用している環境の場合は、このセクションをスキップして、「パスワード・ポリシー構成の完了」に進みます。

タスクの概要: DCC対応の11g Webgateと認証ポリシーの構成

1. DCCの資格証明操作の有効化には、次の両方の構成手順が説明されています。
リソースWebゲートと一体化されたDCC: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にします。

独立したDCCとリソースWebゲート: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にして、「ログアウト・リダイレクトURL」にDCCのlogout.plを設定します。

2. パスワード・ポリシーのDCCフォームの検索と更新

3. DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加には、次の両方の構成手順が説明されています。
一体化されたDCC/リソースWebゲート: 一体化されたDCC/リソースWebゲート・アプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。

独立したDCCとWebゲート: 独立したリソースWebゲートのアプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。

16.14.1 DCCの資格証明操作の有効化

独立したDCCを使用しているか、DCCとリソースWebゲートを一体化しているかにかかわらず、DCCのOAMエージェント登録ページで「資格証明コレクタ操作の許可」を有効にする必要があります。

DCCとリソースWebゲートが独立している場合は、リソースWebゲート登録ページを編集して、手順3で示すように、「ログアウト・リダイレクトURL」にDCCのlogout.plを設定する必要があります。

次の手順は、デプロイメントでオープン・モード通信を使用していると仮定しています。デプロイメントで簡易モードまたは証明書モードの通信を使用している場合は、手順4の実行時に適切なアーティファクトをコピーしてください。

前提条件

- コンソールを使用した登録済OAMエージェントの構成および管理

- グローバル・パスワード・ポリシーの管理

- パスワード・ポリシー認証の構成(DCC固有の詳細を使用する場合)

DCCの資格証明操作を有効化するには

1. Oracle Access Managementコンソールを使用して、DCCとして動作する11.1.2 Webゲートの登録ページを検索して開きます。
「システム構成」タブ
「Access Manager」セクション
「SSOエージェント」ノード
DCCAgent

2. DCC Webゲート登録: 「資格証明コレクタ操作の許可」を選択し、「適用」をクリックして、手順4と5を実行します。

注意:

DCCをリソースWebゲートと一体化している場合は、手順3をスキップしてください。

3. 独立したWebゲート: リソースWebゲート登録を編集して、「ログアウト・リダイレクトURL」にDCCのlogout.pl (表16-27)を設定し、「適用」をクリックして、手順4と5を実行します。

4. AdminServer (コンソール)ホストからエージェント構成ファイル(簡易モード・ファイルまたは証明書モード・ファイルを含む)をエージェント・ホストにコピーします。次に例を示します。

エージェントおよびアーティファクト

アーティファクト

11g Webgate/アクセス・クライアントの場合:

ObAccessClient.xmlとcwallet.sso

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。

簡易または証明書モード

エージェント・ホストにコピー: $11gWG_install_dir/webgate/config

- aaa_key.pem

- aaa_cert.pem

- aaa_chain.pem

- password.xml

関連項目: 付録C「通信の保護」

5. OHS Webサーバーを再起動します。

6. 「パスワード・ポリシーのDCCフォームの検索と更新」に進みます。

16.14.2 パスワード・ポリシーのDCCフォームの検索と更新

Access Managerは、DCCに対するユーザー操作のためにいくつかの動的なページを提供します。

関連項目:

Oracle Fusion Middleware Oracle Access Management開発者ガイド

前提条件

DCCの資格証明操作の有効化

DCCフォームを検索して更新するには

1. Webゲート・ホストでDCCフォームを検索します(表16-27):
WEBGATE_HOME/webgate/ohs/oamsso/*、
WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよび
WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*。

2. それらの場所は、デプロイする認証スキームのトポロジーに応じてカスタマイズします。

3. Perlの場所を更新します: Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるlogin、logoutおよびsecuridスクリプトの最初の行で、Perlの場所を実際の場所と一致するように更新します(表16-27の「DCCベースのログインおよびログアウトを行うPerlスクリプト」を参照)。

4. デフォルト・ページを企業に合せてカスタマイズするか、デフォルト・ページ全体をカスタム・ページと置き換えます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。

5. 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」に進みます。

16.14.3 DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加

次に、保護されたリソースの認証ポリシーでDCC認証スキームを使用するために、実行する必要がある手順を説明します。実行する手順は、デプロイメントのタイプに応じて異なります。

- 一体化されたDCC/リソースWebゲート: 手順1を実行して、一体化されたDCC/リソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。

- 独立したリソースWebゲート: 手順3を実行して、独立したリソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。

手順2は、DCCのデプロイメント・タイプにかかわらず実行してください。デフォルトでは、ログインおよびログアウトのフォームは、OHSの/httpd.conf/webgate.confを通じて除外されるため、これらのフォームをポリシーから除外する必要はありません。ただし、Chromeブラウザの場合は、明示的にasync favicon.icoリクエストを除外する必要があります(このリクエストは、DCCCtxCookieを無視します)。

注意:

この例では、以前にDCCに設定したPasswordPolicyValidationSchemeについて説明しています。

前提条件

パスワード・ポリシーのDCCフォームの検索と更新

アプリケーション・ポリシーでDCC認証スキームを使用するには

1. 一体化されたDCC/リソースWebゲート: DCCアプリケーション・ドメインを開きます。
ポリシー構成
アプリケーション・ドメイン
DCCDomain

1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。

2. このポリシーにDCC認証スキームを追加します(「特定のリソースの認証ポリシーの定義」を参照してください)。
PasswordPolicyValidationScheme (DCC認証スキーム)

3. Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。

2. Chromeブラウザ: 次の手順を実行して、DCCDomainで/favicon.icoを追加します。

1. DCCDomainで、「リソース」タブをクリックします。

2. HTTPリソースの/favicon.icoを見つけて開きます(または、「新規リソース」ボタンをクリックして、このリソースを追加します)。

3. 「リソースURL」を確認または編集して、次のようにします。

/favicon.ico

4. 「保護」セクションで、「保護レベル」リストから「除外」を選択して、「適用」をクリックします。

5. 手順4に進みます。

3. 独立したWebゲート: リソースWebゲート・アプリケーション・ドメインを開きます。
ポリシー構成
アプリケーション・ドメイン
ResourceWGDomain

1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。

2. このポリシーに、DCC認証スキームと、オプションの失敗URLを追加します(指定していない場合、失敗URLはデフォルトのエラー・ページを表示します)。「特定のリソースに対する認証ポリシーの定義」を参照してください。
DCC認証スキーム
失敗URL (オプション)

3. Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。

4. Webサーバーを再起動して、「パスワード・ポリシーの構成の完了」に進みます。

関連項目:

外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

16.15 パスワード・ポリシー構成の完了

ここで説明するタスクは、どの証明書コレクタを構成していても同じです。次のタスクを実行して、パスワード・ポリシーの構成を完了します。

- パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

- ネイティブLDAPパスワード・ポリシー検証のオーバーライド

- ECC操作の無効化とDCCの単独使用

- マルチステップ認証のテスト

16.15.1 パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

管理権限を持つユーザーは、この手順を使用して、図16-33に示すように、パスワード・ポリシー・メッセージのサーバー・エラー・モードを設定できます。

図16-33 パスワード管理のサーバー・エラー・モード

前提条件

- グローバル・パスワード・ポリシーの管理

- パスワード・ポリシー認証の構成

- オプション: DCC対応の11g Webgateと認証ポリシーの構成

エラー・メッセージ・モードを設定するには

1. コンソールで、「Access Manager」セクションを開きます。
「システム構成」
「Access Manager」
「Access Managerの設定」

2. 「ロード・バランシング」セクションで、「サーバー・エラー・モード」を「内部」に設定します。

3. 「適用」をクリックします。

4. 「ネイティブLDAPパスワード・ポリシー検証のオーバーライド」に進みます。

16.15.2 ネイティブLDAPパスワード・ポリシー検証のオーバーライド

前述のとおり、ネイティブLDAPパスワード・ポリシー検証を無効にした後でないと、非ネイティブのパスワード・ポリシーは使用できるようになりません。

たとえば、Oracle Access Managementに登録されたOracle Internet Directoryの使用時、ネイティブのパスワード・ポリシーは、通常次の場所にあります。

dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,<DOMAIN_CONTAINER>

注意:

ネイティブLDAPパスワード・ポリシー検証を無効にすると、直接のLDAP操作に対するポリシー施行がなくなります。Oracle Internet Directoryには、次のうちの1つを含む様々なパスワード・ポリシーがあります。

dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext

ただし、これはドメインに適用することはできません。

orclpwdpolicyenableパラメータをゼロ(0)に設定することで、Oracle Internet Directoryパスワード・ポリシーを無効にできます。

関連項目:

Oracle Fusion Middleware Oracle Internet Directory管理者ガイドには、様々な属性が説明されています。

次の手順は1つの例です。環境はユーザーによって異なります。

前提条件

パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

ネイティブLDAPポリシーをOracle Access Managementパスワード・ポリシーでオーバーライドするには

1. LDAPディレクトリ・ベンダーのマニュアルを参照してください。

2. Oracle Internet Directory: orclpwdpolicyenableをゼロ(0)に設定することで、ネイティブ・ポリシーを無効にします。

- ドメインのパスワード・ポリシーの場所を確認します。

- 適切なネイティブLDAPポリシーがわかっている場合は、そのポリシーを無効にします。次に例を示します。

orclpwdpolicyenable = 0

3. 使用するデプロイメントに応じて、次の作業を実行します。

- 「ECC操作の無効化とDCCの単独使用」

- 「マルチステップ認証のテスト」

- 第19章: 「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」

16.15.3 ECC操作の無効化とDCCの単独使用

DCCとECCの共存を許可して、両方の資格証明コレクタに認証スキームとポリシーを保持する場合、このタスクはスキップできます。

ECCを無効にする場合は、ここで説明するように、oam-config.xmlファイルを編集する必要があります。通常、oam-config.xmlファイルは編集しないことをお薦めします。このファイルを変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、他の方法でECCを完全に無効にして、DCCを選択できません。

注意:

ECCを無効にすると、そのECCに依存するスキームとポリシーで保護されているリソース(Oracle Access Managementコンソールを含む)にはアクセスできなくなります。

前提条件

DCC対応の11g Webgateと認証ポリシーの構成

ECC操作を無効にして、DCCを単独で使用するには

1. AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。

2. 必要に応じて、$DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、後で使用するためにコピーを別の場所に保存します。

3. OAMServicesDescriptorセクションでECCEnabledパラメータを見つけて、次の太字で示された部分を変更します。

<Setting Name="OAMServicesDescriptor" Type="htf:map">
... ...
<Setting Name="ECCEnabled" Type="htf:map">
<Setting Name="ServiceStatus" Type="xsd:boolean">false</Setting>
</Setting>

4. ファイルの先頭にある構成バージョン番号を1増加させて、この変更を関連付け、実行中のすべてのOAMサーバーに対する自動伝播と動的アクティブ化を有効にします(この例の、最後の行のすぐ上を参照してください)。

<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">2</Setting>
</Setting>

5. 「マルチステップ認証のテスト」に進みます。

16.15.4 マルチステップ認証のテスト

この項では、各自のデプロイメントが適切に動作していることを確認するために実行できる、いくつかの評価方法について説明します。

関連項目:

第19章「11g Webgateが関与するセッションの集中ログアウトの構成」

マルチステップ認証を確認するには

1. ログイン後のアクセスを確認します。

1. ブラウザを開き直して、リソースをリクエストします。

2. ユーザー資格証明を使用してログインします。

3. リソースにアクセスできることを確認します。

2. 不正なログインでアクセスできないことを確認します。

1. ブラウザを開き直して、リソースをリクエストします。

2. 不正なユーザー資格証明を使用してログインします。

3. 再認証が必要になることを確認します。

3. 不正なログインの最大試行回数を超過したときのロックアウトを確認します。

1. ブラウザを開き直して、リソースをリクエストします。

2. 不正なユーザー資格証明を使用して、繰り返しログインします。

3. ユーザー・アカウントがロックされたことを確認します。

4. パスワード有効期限ポリシーを変更および評価します。

1. Oracle Access Managementコンソールにログインします。

2. パスワード・ポリシーで、有効期限とロックアウト期間(表16-26)をリセットして、次回のログイン時に警告が表示されるようにします。

3. ポリシーの更新を保存します。

4. ブラウザを開き直して、リソースをリクエストします。

5. パスワードが期限切れになることを示す警告ページが表示されることを確認します。

6. パスワードを変更しないで続行するリンクをクリックします。

5. パスワードを変更します。

1. ブラウザを開き直して、リソースをリクエストします。

2. パスワード有効期限切れの警告ページで、パスワードを変更するリンクをクリックします。

3. パスワード変更のページで、古いパスワードを正しく入力します。

4. 新しいパスワードのフィールドで、パスワード・ポリシーに従わない新しいパスワードを入力して、パスワード検証のエラーを確認します。

5. 要件を満たす新しいパスワードを入力して、変更の成功とリソースへのアクセスを確認します。

17 リソースを保護してSSOを有効化するポリシーの管理

Access Managerアプリケーション・ドメインおよびポリシーへのアクセス、およびこれらの管理は、Oracle Access Managementコンソールを通じて行うことができます。この章では、ポリシーの作成および管理方法を説明し、これらのポリシーを制御するリソースを確認します。内容は次のとおりです。

- 前提条件

- アプリケーション・ドメインおよびポリシーの作成の概要

- コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解

- コンソールを使用したアプリケーション・ドメインおよびポリシーの管理

- ポリシーに追加するリソース定義の追加および管理

- 特定のリソースの認証ポリシーの定義

- 特定のリソースの認証ポリシーの定義

- SSOのポリシー・レスポンスの概要

- SSOのポリシー・レスポンスの追加および管理

- 認可ポリシー・ルールおよび条件の概要

- 認可ポリシー条件の定義

- 認可ポリシー・ルールの定義

- アプリケーション・ドメインの認証および認可の検証

- ポリシーおよびアプリケーション・ドメインのリモート管理の理解

- ポリシーおよびアプリケーション・ドメインのリモート管理

17.1 前提条件

プレビュー:

- コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解

関連項目:

付録D「バンドル、生成および移行されるアーティファクトの確認」

この章のタスクのシステム・レベル要件は次のとおりです。

- OAMサーバーが実行されている必要があります。

- 保護されたリソースにアクセスできるユーザーおよびグループがOracle Access Managementに関連付けられたユーザー・アイデンティティ・ストアにすでに作成されている必要があります。

- ポリシー施行エージェントを登録する必要があります(第12章を参照してください)。

- アプリケーション・ドメインで使用する共有コンポーネントを定義する必要があります(第16章を参照してください)。

17.2 アプリケーション・ドメインおよびポリシーの作成の概要

アプリケーション・ドメインは、Access Manager 11gポリシー・モデルの最上位の構造です。各アプリケーション・ドメインでは、リソースまたはリソースのセットに対する論理コンテナと、特定のリソースにアクセスできるユーザーを示す、関連付けられたポリシーが提供されます。各アプリケーション・ドメイン内では、特定の共有コンポーネントが使用されます。

注意:

セキュリティ強化のため、Access Managerのデフォルトの動作では、リソースがアクセスを明示的に許可するポリシーによって保護されていない場合に、アクセスが拒否されます。

各Access Managerアプリケーション・ドメインには、次の項目が含まれています。

- リソース定義
アプリケーション・ドメインの各リソース定義には、リソース・タイプ、ホスト識別子(HTTPリソースの場合)および特定のリソースへのURLが必要です。アプリケーション・ドメインには必要なだけリソース定義を含めることができます。

- 認証ポリシーおよび特定のリソースへのレスポンス
それぞれの認証ポリシーには、一意の名前、ひとつの認証スキーム、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソース、認証が成功した後に適用される管理者が定義したレスポンスが含まれます。

注意:

認証または認可の成功と失敗に指定されたポリシーのレスポンスに応じて、エンド・ユーザー特定のURLにリダイレクトされたり、ユーザー情報がヘッダー変数やcookieの値を通じて他のアプリケーションに渡されることがあります。

- 特定のリソースに対する認可ポリシー、条件、ルールおよびレスポンス
それぞれの認可ポリシーには、一意の名前、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソースが含まれます。さらに、管理者は認可が成功するために満たされなければならない特定の条件と、認可が成功した後で適用されるレスポンスを定義できます。

- 特定のリソースのトークン発行ポリシー、条件およびルール
トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してセキュリティ・トークン・サービスがトークンを発行する際に従うルールを定義します。

各アプリケーション・ドメインは、特定のホストの単一のアプリケーションを表すリソースの集合です。構成可能なポリシーを使用して、ドメインのリソースへのアクセスを許可または拒否できます。

新しいアプリケーションを既存のエージェントの背後に配置する場合、管理者は、アプリケーションを個別の(新しい)アプリケーション・ドメインおよびポリシーで保護するのか、既存のアプリケーション・ドメインおよびポリシーで保護するのかを決定する必要があります。

この項では、選択に役立つ次のトピックを説明します。

- アプリケーション・ドメインおよびポリシーの自動生成について

- 手動によるアプリケーション・ドメインおよびポリシーの作成について

17.2.1 アプリケーション・ドメインおよびポリシーの自動生成について

Access Managerでポリシー施行エージェントを登録するときに、ポリシーを自動生成することを選択(または拒否)できます。

エージェントの登録中、保護するアプリケーションと同じWebサーバー上にエージェントがあると仮定します。ただし、エージェントをプロキシWebサーバー、アプリケーションを異なるホストに配置できます。

自動的に作成されるアプリケーション・ドメインには、エージェントに基づく名前が付けられ、デフォルトのリソースおよび基本ポリシー(認証および認可)でシードされます。これらのために空のコンテナが提供されますが、トークン発行ポリシーは定義されません。

デフォルトのリソースは、管理者がリソースを追加したり、ポリシーを変更または追加するまで、基本ポリシーによって保護されます。

注意:

IAMSuiteAgentは、Oracle Fusion Middlewareコンソールやその他のコンソールを保護するためのアプリケーション・ドメイン(IAMSuite)を提供する、事前登録されたJavaエージェント・フィルタです。詳細は、「バンドルされた10g IAMSuiteAgentアーティファクト」を参照してください。

17.2.2 手動によるアプリケーション・ドメインおよびポリシーの作成について

管理者は、同じWebサーバーに存在して様々な方法で相互に密接に関連付けられている場合でも、リソースに異なるアプリケーション・ドメインを定義できます。たとえば、管理者は、財務アプリケーションおよび売掛金勘定アプリケーション用に単一のアプリケーション・ドメインを作成することも、各アプリケーション用に異なるアプリケーション・ドメインを使用することもできます。

注意:

新しいリソースをアプリケーション・ドメインに追加する前に、リソースが既存のアプリケーションおよびポリシーに属するかどうかや、固有の特定のポリシーを使用する新しいアプリケーションとして定義するかどうかを検討します。

17.2.3 ポリシーのリモート作成および更新について

Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。

詳細は、「ポリシーおよびアプリケーション・ドメインのリモート管理の理解」を参照してください。

17.2.4 アプリケーション・ドメインおよびポリシーの作成または管理について

次に示す概要では、アプリケーション・ドメインとポリシーを手動で作成または管理するために実行する必要のある手順について、簡単に説明しています。また、各手順を完了するための説明が記載された項目についても示しています。

タスクの概要: アプリケーション・ドメインの管理

1. 次の詳細を理解します。

- 第15章「Access Managerを使用したシングル・サインオンの概要」

- 第16章「認証コンポーネントと共有ポリシー・コンポーネントの管理」

- コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解

- ポリシーおよびアプリケーション・ドメインのリモート管理の理解

2. 次の項の説明に従って、この章の前提タスクをすべて実行します。

- 前提条件

3. 次の項の説明に従って、新しいアプリケーション・ドメインを作成します(または既存のアプリケーション・ドメインを表示します)。

- コンソールを使用した新しいアプリケーション・ドメインの作成

- Oracle Access Managementコンソールを使用したアプリケーション・ドメインの表示または編集

- ポリシーおよびアプリケーション・ドメインのリモート管理

4. 次の項の説明に従って、リソース定義をアプリケーション・ドメインに追加します。

- ポリシーに追加するリソース定義の追加および管理

5. 次の項の説明に従って、認証ポリシーを定義します。

- 特定のリソース用の認証ポリシーの作成

- SSOのポリシー・レスポンスの追加および管理

6. 次の項の説明に従って、認可ポリシーを定義します。

- 認可ポリシーおよび特定のリソースの作成

- SSOのポリシー・レスポンスの追加および管理

- 認可ポリシー条件の定義

- 認可ポリシー・ルールの定義

7. 次の項の説明に従って、トークン発行ポリシーを定義します。

- 第34章: トークン発行ポリシーおよび条件の管理

- SSOのポリシー・レスポンスの追加および管理

- 認可ポリシー条件の定義

- 認可ポリシー・ルールの定義

8. 次の項の説明に従って、SSO設定およびポリシー評価キャッシュを構成します。

- 第11章: 「SSOトークンおよびIPの検証の管理」

- 第11章: 実行時のポリシー評価キャッシュの管理

9. 次の項の説明に従って、ポリシーおよび構成を検証します。

- 第19章: グローバル・サインオンおよび一元化されたログアウトの検証

17.3 コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解

エージェントの登録時に、手動でアプリケーション・ドメインを作成しても、ポリシーの自動生成を受け入れても、アプリケーション・ドメインの要素は同じになります。すべてのポリシーおよびアプリケーション・ドメインは、Oracle Access Managementコンソールを使用して管理します。詳細は、次の項を参照してください。

- アプリケーション・ドメインのページおよびナビゲーションについて

- アプリケーション・ドメインの「サマリー」ページについて

- アプリケーション・ドメインのリソース・コンテナについて

- 認証ポリシー・ページについて

- 認可ポリシー・ページについて

- トークン発行ポリシー・ページについて

17.3.1 アプリケーション・ドメインのページおよびナビゲーションについて

どの作成方法を選択してアプリケーション・ドメインを作成するかにかかわらず、一意の名前を識別子として使用する必要があります。「アプリケーション・ドメイン」ノードを開くと、「検索」ページが使用可能になります。右上隅の「アプリケーション・ドメインの作成」ボタンを使用すると、新しいドメインの定義を開始できます。または、名前を入力し(または「名前」フィールドを空白のまま残し)、「検索」ボタンをクリックし、既存のアプリケーション・ドメインをリストします。

図17-1は、アプリケーション・ドメインの検索ページ、コントロール、および独自のツールバーを含む「検索結果」表を示しています。

図17-1 アプリケーション・ドメインの検索ページ

「図17-1 アプリケーション・ドメインの検索ページ」の説明

17.3.2 アプリケーション・ドメインの「サマリー」ページについて

アプリケーション・ドメインを作成または表示すると、その名前およびオプションの説明が「サマリー」タブに表示されます。

図17-2は、アプリケーション・ドメインの「サマリー」ページを示しています。生成されたアプリケーション・ドメインの場合、次のように「名前」および「説明」が移入されます。手動でアプリケーション・ドメインを作成する場合、「説明」の入力はオプションです。

図17-2 「サマリー」タブ: 生成されたアプリケーション・ドメイン

「図17-2 「サマリー」タブ：生成されたアプリケーション・ドメイン」の説明

17.3.3 アプリケーション・ドメインのリソース・コンテナについて

アプリケーション・ドメインの「リソース」タブには、そのドメインのすべてのリソース定義のコンテナが表示されます。「リソース」タブが表示されると、特定の定義をすばやく検索できる「検索」コントロールが使用可能になります。

図17-3は、リソース定義の検索結果を絞り込むことができる「検索」コントロールを示しています。右上隅には「新規リソース」ボタンも表示されます。「検索結果」表では、検索された各定義の主要な情報が提供されます。

図17-3 アプリケーション・ドメインのリソースの検索結果

「図17-3 アプリケーション・ドメインのリソースの検索結果」の説明

デフォルトのリソース・タイプはHTTPですが、デフォルトのリソースURLは/**です。HTTPリソース定義を使用すると、そのリソース用に定義された問合せ文字列に基づいて検索を実行できます。この問合せ文字列に使用できるのはベースURLのみで、一連のURLを示すオプションのパターン一致特殊文字を含めることができます。この生成されたドメインでは、「ホスト識別子」が、登録されたHTTPエージェントの名前に一致します。ポリシーの基本情報も提供されます。

関連項目:

- ポリシーに追加するリソース定義の追加および管理

- 付録D「バンドル、生成および移行されるアーティファクトの確認」

17.3.4 認証ポリシー・ページについて

「認証ポリシー」タブでは、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。管理者がアプリケーション・ドメインを手動で作成する場合、その管理者はポリシーもすべて手動で作成する必要があります。生成されたアプリケーション・ドメインでは、図17-5のように、2つの認証ポリシーが自動的に作成されます。

- 認証ポリシー: Protected Resource Policy

- 認証ポリシー: パブリック・リソース・ポリシー

図17-4 「認証ポリシー」タブ

「図17-4 「認証ポリシー」タブ」の説明

認証ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。1つの認証ポリシーでのみ、各リソースを保護できます。

図17-5は、保護されたリソース・ポリシー、およびポリシーの「リソース」タブに自動的に表示される情報の列を示しています。「レスポンス」タブが使用可能です。

図17-5 「認証ポリシー」ページ: 「リソース」および「レスポンス」

「図17-5 「認証ポリシー」ページ: 「リソース」および「レスポンス」」の説明

注意:

最初は、すべてのリソースが保護されます。成功および失敗URLとレスポンスを手動で追加する必要があり、デフォルト値は提供されません。

自動生成時に次のような説明が提供されます。

"Policy set during domain creation. Add resources to this policy to protect them."

この生成されたポリシーでは、LDAPSchemeが認証スキームとして使用されます。ただし、ポリシーのオプション要素はまだ定義されていません。

保護されているリソースは、HostIdentifier/**として「リソース」タブで識別されます。

注意:

管理者は、認証スキームの変更、成功URLと失敗URLの指定、他のリソースの追加およびSSOレスポンスの定義を行うことができます。

パブリック・リソース・ポリシー: 2つ目の認証ポリシーも自動生成されます。このポリシーでは、AnonymousSchemeが認証のデフォルト・スキームとして使用され、すべてのアクセスが許可されます。

このパブリック・リソース・ポリシーは、最初はいずれのリソースも含まず、いずれのリソースも提供しません。「説明」で管理者は要件を確認します。

Policy set during domain creation. Add resources to this policy to allow anyone access.

関連項目:

「SSOのポリシー・レスポンスの概要」

17.3.5 認可ポリシー・ページについて

「認可ポリシー」タブでも、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。生成されたアプリケーション・ドメインでは、次の2つの認可ポリシーが自動的に作成されますが、各リソースは1つの認可ポリシーによってのみ保護できます。

- 保護されたリソース・ポリシー

- パブリック・リソース・ポリシー

図17-7は、「認可ポリシー」タブを示しています。このタブで、ポリシーを選択して新しいポリシーを編集または作成できます。

図17-6 「認可ポリシー」ページ

図17-7は、「認可ポリシー」ページを示しています。提供されるいくつかのタブでは、この認可ポリシーの様々なコンポーネントを定義できます。最初は、すべてのリソースが保護され、アクセスが拒否されます。成功URLと失敗URL、条件、ルールおよびレスポンスを手動で追加する必要があります(デフォルト値は提供されません)。

図17-7 個々の「認可ポリシー」ページ

「図17-7 個々の「認可ポリシー」ページ」の説明

図17-8は、「認可ポリシー・リソース」タブを示しています。このページを使用し、このポリシーのリソースを追加(または削除)します。

図17-8 個々の「認可ポリシー・リソース」タブ

管理者は、このポリシーの条件、ルールおよびレスポンスも定義できます。自動生成されるものはありません。

関連項目:

- 「SSOのポリシー・レスポンスの概要」

- 「認可ポリシー・ルールおよび条件の概要」

17.3.6 トークン発行ポリシー・ページについて

生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。リソース、条件、ルールおよびレスポンスはすべて手動で追加する必要があります。

図17-9 「トークン発行ポリシー」ページ

このポリシー・タイプの詳細は、次の項を参照してください。

- 「TokenServiceRPタイプのリソースの管理」

- 「トークン発行ポリシー、条件およびルールの管理」

17.4 コンソールを使用したアプリケーション・ドメインおよびポリシーの管理

この項では、Oracle Access Managementコンソールを使用してアプリケーション・ドメインを作成および管理する方法を説明します。内容は次のとおりです。

- アプリケーション・ドメインの「サマリー」ページについて

- コンソールを使用した新しいアプリケーション・ドメインの作成

- 既存のアプリケーション・ドメインの検索

- Oracle Access Managementコンソールを使用したアプリケーション・ドメインの表示または編集

- アプリケーション・ドメインおよびその内容の削除

17.4.1 アプリケーション・ドメインの「サマリー」ページについて

アプリケーション・ドメインの管理には、一般的な設定とポリシー、およびリソース関連の設定とポリシーの追加、変更または削除が含まれます。

Oracle Access Managementコンソールを使用してアプリケーション・ドメインを作成または編集する場合は、複数のページを扱うことになります。最初は、図17-10に示されているフォームに一般詳細(名前およびオプションの説明)を追加します。

図17-10 新しいアプリケーション・ドメインの「サマリー」ページ

「図17-10 新しいアプリケーション・ドメインの「サマリー」ページ」の説明

各アプリケーション・ドメインには、エージェント名と一致する一意の名前を使用する必要があります。新しいアプリケーション・ドメインの名前とオプションの説明を適用した後、そのアプリケーション・ドメインが作成されます。手動による作成の場合、一連のタブ(「サマリー」、「リソース」、「認証ポリシー」、「認可ポリシー」、「トークン発行ポリシー」)がすべて使用可能になります。リモート登録を使用して作成された場合、またはエージェントの登録中に作成された場合は、基本ポリシー情報も生成されます。

17.4.2 コンソールを使用した新しいアプリケーション・ドメインの作成

新しいアプリケーション・ドメインが必要かどうか、またはリソースを既存のアプリケーション・ドメインに追加できるかどうかを決定します。単一のアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを手動で追加すると、同じエージェントを使用して複数のアプリケーションを保護できます。

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメインを手動で作成できます。

また、第12章および第13章で説明したように、エージェント登録時にアプリケーション・ドメインを自動的に生成することもできます。

前提条件

この章の始めにある「前提条件」を参照してください。

新しいアプリケーション・ドメインを作成するには

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「アプリケーション・ドメイン」ノードを開き、「検索」ページの「作成」ボタンをクリックします。
または、「ようこそ」ページの「ポリシー」パネルで、「新規アプリケーション・ドメイン」をクリックして新しいページを開きます。

2. 新しいアプリケーション・ドメイン・ページで、ドメインの一意の名前およびオプションの説明を追加して、「適用」をクリックして確認ウィンドウを閉じます。

3. 「アプリケーション・ドメイン」コンテナ内に、次のコンテナ(タブ)を表示し、管理します。

- リソース: 「ポリシーに追加するリソース定義の追加および管理」を参照してください。

- 認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。

- 認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。

- トークン発行ポリシー: 「トークン発行ポリシー、条件およびルールの管理」を参照してください。

17.4.3 既存のアプリケーション・ドメインの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメインを検索できます。

注意:

この検索操作では、大文字と小文字が区別されます。

アプリケーション・ドメインを検索するには

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「アプリケーション・ドメイン」ノードを開き、「検索」コントロールを表示します。

2. 提供されたフィールドに、検索するアプリケーション・ドメインの名前を入力します(名前の一部とワイルドカード(*)を入力したり、すべてのドメインを取得するためにフィールドを空白のまま残すこともできます)。次に例を示します。

DesiredDomain

3. 「検索」ボタンをクリックして検索を開始します。

4. 「検索結果」表で名前を選択し、必要なタスクを実行します。次に例を示します。

- 編集: ツールバーの「編集」ボタンをクリックして構成ページを表示し、「Oracle Access Managementコンソールを使用したアプリケーション・ドメインの表示または編集」に進みます。

- 削除: 「アプリケーション・ドメインおよびその内容の削除」を参照してからこのタスクを実行します。

- 連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。

- 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

17.4.4 Oracle Access Managementコンソールを使用したアプリケーション・ドメインの表示または編集

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含みます)を表示または変更できます。

類似するアプリケーションを同じアプリケーション・ドメインにグループ化することをお薦めします。アプリケーション・ドメインを編集する場合、異なるアプリケーションが同じドメインを使用していることに注意してください。説明およびドメイン名の編集がサポートされます。

関連項目:

「ポリシーおよびアプリケーション・ドメインのリモート管理」

アプリケーション・ドメインおよびその内容を表示または変更するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 次の各タブをクリックして開き、特定の詳細を追加、表示、変更または削除します。

- リソース: 「ポリシーに追加するリソース定義の追加および管理」を参照してください。

- 認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。

- 認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。

- トークン発行ポリシー: 「トークン発行ポリシー、条件およびルールの管理」を参照してください。

17.4.5 アプリケーション・ドメインおよびその内容の削除

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含みます)を削除できます。

アプリケーション・ドメインおよびその内容を削除すると、エージェント登録など、参照されているすべてのオブジェクトが削除されます。この方法を使用すると、後から同じエージェントの再登録が必要になった場合、その操作が可能になります。これは、以前のアプリケーション・ドメインおよびその内容の参照が残っていないためです。

注意:

削除操作中、アプリケーション・ドメインにポリシー要素が含まれている場合、アラートが表示されます。

前提条件

削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。

アプリケーション・ドメインを削除するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。

3. 「検索結果」表で、目的の名前の横にある「シリアル番号」をクリックし、ツールバーの「削除」(x)ボタンをクリックします。

4. 警告ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

5. 結果表で、アプリケーション・ドメインが削除されていることを確認します。

17.5 ポリシーに追加するリソース定義の追加および管理

各アプリケーション・ドメインには、リソース定義のコンテナである「リソース」タブが含まれます。このコンテナでリソースを定義すると、そのリソースをアプリケーション・ドメインのポリシーに追加できます。

リソースの保護には、特定のリソース定義を含むアプリケーション・ドメインが必要です。OAMでは、次のような非HTTP/HTTPSベースのリソースおよびHTTP/HTTPSベースのリソースを含む様々なタイプのリソースを保護できます。

- すべての外部Webサイト

- Webサイトの特定のページ

- パートナ・ポータル

- 部品注文アプリケーション

- 請求書アプリケーション

- 多くの国の企業のWebサーバーの福利厚生加入アプリケーション

この項の内容は次のとおりです。

- アプリケーション・ドメインのリソースの定義について

- リソース定義の検索

- アプリケーション・ドメインのリソースの定義

- リソース定義の表示、編集または削除

17.5.1 アプリケーション・ドメインのリソースの定義について

各リソースをアプリケーション・ドメインで個別に定義する必要があります。アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のタイプ、およびサーバーに格納されて多くのユーザーがアクセスできるリソース(ドキュメントまたはエンティティ)を識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。

注意:

明示的に「除外」とマークされていないリソースがポリシーに関連付けられていない場合、一致するポリシーがないため、すべてのユーザーのアクセスが拒否されます。

リソース定義のガイドライン

1. URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。

2. 機能が制限された次のパターン一致
' * 'および'...'がサポートされます。

3. リソースをドメイン間で一意にする必要はありません。

4. HTTP URLの問合せ文字列保護。

5. 各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。

6. 特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。

7. リソースは、「保護」、「非保護」または「除外」として指定されます。

8. カスタム・リソース・タイプが許可されます。

図17-11は、新しい「リソース」定義ページを示しています。

図17-11 アプリケーション・ドメインの新しい「リソース」(定義)ページ

「図17-11 アプリケーション・ドメインの新しい「リソース」(定義)ページ」の説明

表17-1は、リソース定義を構成する要素を示しています。

表17-1 リソース定義の要素

要素

説明

リソース・タイプ

HTTPタイプがデフォルトです。HTTPまたはHTTPSプロトコルを使用してアクセスするリソースを扱います。特定のリソースを制御するポリシーが、そのリソース用に定義されたすべての操作に適用されます。

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明しているように、Fusion Middlewareアプリケーション・シナリオではwl_authenリソース・タイプが使用されます。

「TokenServiceRPタイプのリソースの管理」で説明するように、TokenServiceRPリソース・タイプはトークン・サービス・リライイング・パーティを表すために使用されます。

リソース定義を追加(またはリソースを検索)すると、定義されたすべてのカスタム・リソース・タイプがデフォルトのリソース・タイプとともにリストされます。

関連項目: 「リソース定義のリソース・タイプについて」

ホスト識別子

共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。

注意: リソース定義を構成するホスト識別子およびURL文字列の組合せは、すべてのアプリケーション・ドメインで一意にする必要があります。

関連項目: 「ホスト識別子の管理」

説明

このリソースのオプションの一意の説明。

「URI」セクション

情報は選択したリソース・タイプによって異なります。

問合せ

名前と値のリスト

HTTPリソース・タイプの場合のみ。アクセス・ポリシーで使用する名前と値のペアのリストを提供できます。

関連項目: 「リソース定義の問合せ文字列の名前と値のパラメータについて」

問合せ

文字列

HTTPリソースの場合、問合せ文字列を提供し、アクセス・ポリシー内の完全一致するリテラル文字列を検索できます。

関連項目: 「リソース定義のリテラル問合せ文字列について」

リソースURL

「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URL文字列として、値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。

内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。

- 最下位の終端レベルのパスにのみ、アスタリスク(*)を使用できます。アスタリスクは、0(ゼロ)個以上の文字と一致します。

- 終端レベルを除く任意のレベルのパスに省略記号(…)を使用できます。省略記号は、0(ゼロ)個以上の一連の中間レベルを表します。

表17-2も参照してください。

「操作」セクション

許可される特定の操作を定義して、独自のリソース定義をカスタマイズできます。

注意: Oracle提供のリソース・タイプは読取り専用です。Oracle提供のリソース・タイプに関連付けられた操作は定義する必要がなく、変更もできません。開発されOracle提供のリソース・タイプに適用されたポリシーは、すべての操作に適用されます。

使用可能な操作

このリソース定義で許可されるすべてのHTTP操作を識別します。開発され、このカスタマイズされたリソースに適用されたポリシーは、識別した操作にのみ適用されます。特に明記しないかぎり、使用可能な次の操作は、すべてHTTPリソース・タイプのみを対象としています。

- 接続

- Options

- Put

- Post

- トレース

- Head

- Delete

- 接続

- Login (wl_authenリソース・タイプのみ)

- Issue (TokenServiceRPリソース・タイプのみ)

注意: エージェントの登録時に、リソース定義自体に操作が指定されなかった場合は、そのリソース・タイプのすべての操作がサポートされます。

関連項目: 「リソース・タイプおよびその使用法について」

保護

リソース定義のこのセクションのコントロールを使用すると、このリソースに適用する保護レベルを識別し、使用するポリシーに名前を付けることができます。

保護レベル

適切な保護レベルを次のオプションから選択します。

- 保護(デフォルト)
保護されているリソースは、様々な認証スキーム(LDAPなど)を使用する保護レベル認証ポリシーに関連付けられます。

認可ポリシーは保護されているリソースに対して許可されます。

レスポンス、条件、監査およびセッション管理は、リソースを保護するポリシーを使用して保護されているリソースに対して有効化されます。

- 非保護
保護されていないリソースは、様々な認証スキーム(LDAPなど)を使用する非保護レベル認証ポリシー(レベル0)に関連付けられます。

認可ポリシーは保護されていないリソースに対して許可されますが、このようなアクセスを許可するための基本ポリシーが必要です。ただし、条件およびレスポンスが含まれる複雑なポリシーは不適切です。

レスポンス、条件および監査は、リソースを保護するポリシーを使用して保護されていないリソースに対して有効化されます。セッション管理のみが有効化されていません。保護されていないリソースにアクセスすると、WebgateからのOAMサーバー・チェックが引き起こされます(監査可能)。

- 除外(パブリック)
HTTPリソース・タイプのみが除外できます。通常はイメージ(*.jpg, *.png)などのセキュリティの区別がないファイルで、保護レベルが「除外」のリソースでは、認証、認可、レスポンス処理、セッション管理および監査に対するOAMサーバー・チェックは必要ありません。除外されたリソースは、コンソール内のユーザー定義ポリシーには追加できません。

除外されたリソースへのアクセスを許可している間、WebgateはOAMサーバーにコンタクトしないため、アクセスは監査されません。最も標準的なリソース検証が、除外されたリソースに適用されます。ただし、リソースをポリシーに追加するときに、除外されたリソースはリストに表示されていません。

リソースに関連付けられた認証または認可はありません。

注意: リソース保護レベルが「保護」から「除外」に変更され、そのリソースに対するポリシーが存在する場合、リソースとポリシーとの関連付けを解除するまで、変更は失敗します。

認証ポリシー

指定したリソース保護レベルに基づく認証ポリシーのリストが使用可能になりました。このドメイン内にあり、指定した保護レベルに一致するポリシーのみがリストされます。

認可ポリシー

ドメインで定義された認可ポリシーのリストが使用可能になり、そこからこのリソースを保護するためのポリシーを選択できるようになります。

リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストされ、そこからポリシーに含める1つ以上のリソースを選択できます。

リソース定義内の様々な仕様の詳細は、次の項を参照してください。

- リソース定義のリソース・タイプについて

- リソース定義のホスト識別子について

- リソースURL、接頭辞およびパターンについて

- リソース定義の問合せ文字列の名前と値のパラメータについて

- リソース定義のリテラル問合せ文字列について

- 実行時リソース評価について

17.5.1.1 リソース定義のリソース・タイプについて

リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。ネイティブ・リソース・タイプは読取り専用で、変更または削除できません。HTTP、TokenserviceRP、wl_authenなどがあります。

関連項目:

「リソース・タイプおよびその使用法について」

HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。

表17-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURL、接頭辞およびパターンについて」を参照してください。

表17-2 HTTPリソースのサンプルのURL値

リソース

サンプルのURL値

ディレクトリ

- /mydirectory

- /mydirectory/**

ページ

- /mydirectory/projects/index.html

- /mydirectory/projects/*.html

- /mydirectory/.../*.html

Webアプリケーション

- /mydirectory/projects/example.exe

- /mydirectory/projects/*.exe

- /mydirectory/**

17.5.1.2 リソース定義のホスト識別子について

管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを識別します。

注意:

HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。

ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。

すべての定義されたホスト識別子がリソース・ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。

Access Managerは、リソースのURLを認識できるよう、そのリソースのホスト・コンピュータを参照するために使用される様々な方法を認識できる必要があります。

17.5.1.3 リソースURL、接頭辞およびパターンについて

自動的なアプリケーション・ドメインの生成中、すべてのリソースが保護されるURL接頭辞が定義されます。リソースは線形で階層ではありません。リソースの定義は、完全なURLとして扱われます。

注意:

非HTTPリソース・タイプに関連付けられるホスト識別子はありません。

管理機能は、特定のリソースURLを使用して、アプリケーション・ドメインの個々のリソースを識別します。個々のリソースURLをドメイン間で一意にする必要はありません。ただし、リソースURL、問合せ文字列およびホスト識別子の組合せをドメイン間で一意にする必要があります。

HTTPタイプのリソースは、パスを表す単一の相対URL文字列として表現されます。文字列は、「/」文字で区切られた一連の階層レベルで構成されます。内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。

URL接頭辞

Access Managerポリシー・モデルでは、リソース接頭辞がサポートされません。つまり、ポリシーの継承はありません。

ポリシーが/mydirectory/projects/に定義されている場合、そのURLにのみ適用されます(/mydirectory/projects/index.htmlなどには適用されません)。

同じ接頭辞文字列を使用したすべてのリソースのポリシーが必要な場合、特殊文字(/mydirectory/projects/.../*などの3つのピリオド...(省略記号)または*(アスタリスク))を使用してリソースを定義できます。

注意:

Access Managerポリシー・モデルでは、リソース接頭辞がサポートされません。つまり、ポリシーの継承はありません。

URLパターン、一致および優先順位

管理者は、詳細なURLパターンを作成して、リソースのネームスペースの詳細な部分を指定できます。すべての照合は、大文字と小文字が区別されます。

- 表17-3のパターンには、サポートされるワイルドカードの一致が提供されます。

- 表17-4は、サンプル・リソースURLおよびその正確性を示しています。

表17-3 リソースURLパターンでサポートされるワイルドカード(優先順)

パターン

説明

例

/**

デフォルトです。スラッシュ(/)で始まる0個以上の文字の連続に一致します。

このパターンを使用すると、特定の名前付きディレクトリの下にあるパスを保護できます。

注意: これは既存の10gワイルドカードではありません。10gでは、/.../*パターンによって、パターンが定義されたレベルのルートを含まない排他的な一致が返されました。たとえば、/foo/.../*は/foo/barに一致しますが、ディレクトリ/foo/自体には一致しませんでした。10gでは接頭辞(ルート)が認識されるため、ほとんどの評価は接頭辞を取り除いた後に実行されました。

· /**

一致する内容

/foo/bar
/foo/

/foo/…/*は/foo/barに一致しますが、/foo/には一致しません。

リテラル

リソースのパターンには、特殊文字が含まれません。

{パターン1,パターン2,...}

パターン集合の1つに一致します。

中カッコ内部のパターン自体には、その他の特殊文字を含めることができます(中カッコは除きます。パターン集合はネストできません)。

- a{ab,bc}bは、aabbおよびabcbに一致します。

- a{x*y,y?x}bは、axyb、axabayb、ayaxbなどに一致します。

[範囲またはセット]

文字集合の1つに一致します。

集合は、リテラル文字列または文字範囲として指定できます。文字範囲とは、ハイフン(-)で結ばれた任意の2文字間のすべての文字です。

文字範囲とは、ハイフン(-)で結ばれた任意の2文字間のすべての文字です。

スラッシュ(/)は、集合に入れることができない無効な文字です。

文字集合は、/を含んだ範囲が指定されている場合でも、/には一致しません。

- [nd]はnまたはdにのみ一致します。

- [m-x]は、mとxの間(両端を含む)の任意の1文字に一致します。

- [--b]は、-とbの間(両端を含む)の任意の1文字に一致しますが、/には一致しません。記号の順序については、/usr/pub/asciiを参照してください。

- [abf-n]は、a、bおよびfとnの間(fおよびnを含む)の任意の1文字に一致します。

- [a-f-n]は、aとfの間の任意の1文字(両端を含む)、-またはnに一致します。(2番目の-は文字どおりに解釈されます。前のfがすでに範囲の一部となっているためです。)

単一文字のワイルドカード?

?(疑問符)は、「/」以外の任意の1文字に一致します。これは問合せ文字列のデリミタとしては扱われません。

a?bは、aabとazbには一致しますが、a/bには一致しません。

ワイルドカード*

* (アスタリスク)ワイルドカードは、連続する0個以上の文字に一致します。ただし、* (アスタリスク)は前方のスラッシュ(/)には一致しません。

a*bは、ab、azb、azzzzzzbには一致しますが、a/bには一致しません。

*

* (アスタリスク)は、最下位の終端レベルのパスにのみ使用できます。0(ゼロ)または1つ以上の文字に相当します。

URLパターン内のすべての文字は対応するURLパス内の文字に正確に一致する必要があります。

例外:

- パターンの最後の/*は、以降の一連の文字と一致します。

- パターン*拡張子は、名前が付いた拡張子で終わるファイル名と一致します。

- 「/」には一致しません。

次のURLパターン:

/.../update.html

一致する内容:

/humanresources/benefits/update.html
/corporate/news/update.html
update.html

関連項目: 表17-4

/.../階層

/.../*ホスト全体

スラッシュ(/)で囲まれた1つ以上の文字の連続に一致します。

評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。

ホスト全体とは、パターン全体を意味します。

- パターン/.../index.htmlは、次のURLと一致します。
/index.html、/oracle/index.html、/oracle/sales/index.html、index.html

xyzindex.htmlやxyz/index.htmlには一致しません。

- /oracle/.../*.htmlは、次のURLと一致します。
/oracle/index.html/oracle/sales/order.htmlなど

\

円記号は、特殊文字をエスケープするために使用します。前に円記号を付けた任意の1文字は、その文字自体に一致します。

- ワイルドカード内でのパターンの表現では、エスケープされている特殊文字は無視されます。

- エスケープされた特殊文字は、着信URL内に特殊文字があれば、その文字にリテラルとして一致します。

- abc\*dはabc*dにのみ一致します。

- abc\\dはabc\dにのみ一致します。

表17-4は、ホスト識別子およびリソースURLに基づいてアルファベット順に整理された、アプリケーション・ドメイン内のいくつかのリソース定義を示しています。表17-4の右側の列は、形式が正しいかどうかを示しています。

表17-4 サンプル・リソース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

いいえ

17.5.1.4 リソース定義の問合せ文字列の名前と値のパラメータについて

ポリシー・モデルでは、リソース・パターン定義での問合せ文字列の名前と値のパラメータの使用がサポートされます。

- 名前: 記号などの任意の文字を含むことができる文字列リテラル。すべての文字がリテラルとして扱われます。

- 値: 任意の文字を含む文字列リテラルを指定できます。連続する0個以上の文字に一致させるには、ワイルドカード(*のみ)を含めます。アスタリスク(*)はワイルドカードとして扱われます。

- 量: 問合せ文字列に指定できる名前と値のペアの数に制限はありません。ただし、単一のリソースの場合、ペアは2、3個になります。

- 順序: 名前と値のペアには任意の順序を使用できます。実行時、これらのペアは問合せ文字列の一部として、任意の順序で処理される場合があります。

リソースの一致および優先順位: 問合せ文字列の名前および値のパラメータ

Access Managerでは、まず最も一致率の低いリソースを検出し、それよりも一致率の高いリソースを検出していくアルゴリズムが使用されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。

パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。

1. パス一致: Access Managerによって、リクエストされたリソースのパスへの一致が試行されます。問合せコンポーネントや宣言された操作が異なる、複数の候補に一致する場合があります。

2. 問合せ文字列一致: 取得した一致に対して、Access Managerによって、問合せ文字列(リクエストしたURL内に存在する場合)への一致が試行されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、リテラル文字列で定義された候補が優先されます。操作が異なる複数の候補が残る場合があります。

3. 操作一致: 取得した一致に対して、リクエストされた操作への一致が試行されます。完全一致が存在しない場合は、特定の操作が定義されていないリソースを確認します。つまり、リソース・タイプの一部として定義されているすべての操作に適用されます。いずれの場合も、これによって単一の最善一致が検出されます。

パス一致: 定義済リソースが、リクエストされたURLのパス・コンポーネントに対して評価され、一致が検索されます。使用される優先順位は、次のとおりです。

- リテラル(リソースのパターンに特殊文字が含まれていない場合など)

- 選択肢: {パターン1,パターン2,...}。それぞれ自体に次の特殊文字が含まれる場合があり、同じ優先順位を使用して順番に評価されます。

- 範囲: [ ]

- 単一文字のワイルドカード: ?

- ワイルドカード: *

- 階層: /.../

- ホスト全体: /…/*はパターンの全体です。

評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが、次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。

注意:

11gのすべての照合は、以前と同様に大文字/小文字が区別されます。

表17-5は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。

表17-5 リクエストされたURLのパターン一致

リクエストされたURL

一致パターン

/oam/sales/oam/page8.html

/oam/.../*.html

/oam/Dept1/page8.html

/oam/Dept?/page8.html

/oam/DeptQ/page8.html

/oam/Dept[A-Z]/page[1-8].html

/oam/DeptQ/page8.html

/oam/Dept[A-Z]/page?.html

/oam/saals/foo/aba/zzz/indexp.html

sa{*,le,l?,a[k-m],[a-f-m]}s/.../{*b,?a}{a,/../ii}/.../{index,test}[pa].?tml

問合せ文字列一致

単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。単一の問合せ文字列のスコアは、すでに説明したアルゴリズムを使用して決定されます。

パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。

- パラメータ値にワイルドカードが含まれていないリソースの優先順位は高くなります。そのようなリソースのセットの中で、最善一致はパラメータの名前と値を組み合せた長さを使用して決定されます。

- 問合せ文字列リテラルについては、組み合せた長さが等しい複数の一致が検出された場合、一致は失敗します。

- 次に検討されるのは、パラメータ値にワイルドカードが含まれているリソースです。そのようなリソースの中で、最善一致は各リソース内のワイルドカードの合計数を使用して決定されます。ワイルドカード数が等しい複数の一致が検出された場合、パラメータの名前と値を組み合せた長さによって最善一致が決定されます。

- 組み合せた長さが等しい複数のリソースが検出された場合、一致は失敗します。

問合せ文字列一致パターン: 2つ目およびそれに続くパターンでは、次のパラメータ・リストが使用されます。

/oam/index.html::a=*d (単一の問合せ文字列)
/oam/index.html::a:b
/oam/index.html::a:b,c:d
/oam/index.html::a:b*
/oam/index.html::a:b*,c:d
/oam/index.html::a:b*,c:d*
/oam/index.html::a:b*,c:*d*

表17-6は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。

表17-6 問合せ文字列一致: 例

リクエストされたURL

一致パターン

/oam/index.html?a=b&c=d

/oam/index.html::a=*d

/oam/index.html?a=b1&c=d

/oam/index.html::a:b*,c:d

/oam/index.html?a=b1,c=d1

/oam/index.html::a:b*,c:d*

/oam/index.html?a=b1,c=1d1

/oam/index.html::a:b*,c:*d*

操作一致の例: リクエスト処理のこの時点で、1つ以上の候補リソースがあり、これらはすべて、リクエストされたURLパスおよび問合せ文字列コンポーネントに等しく一致します。Access Managerでは、リクエストされた操作をそれらの候補のいずれかに一致させます。ここで一致するのは、特にその操作を(他の特定の操作と同様に)保護するよう定義されているリソースです。特定の操作を保護するよう定義できるリソースは1つのみであるため、これで単一の最善一致が決まります。

実行時の評価: 名前と値のペアは、実行時に次のように評価されます。

名前と値
a ab
a a*

異なる形式で指定された同じリソースURL: URLが同じで問合せ文字列に同じ文字を含んでいても、コンソール内で異なる形式で(1つはキーおよび値として、もう1つは単一の文字列として)指定されたリソースは、異なるリソースと見なされ、許可されます。たとえば、次の2つのリソース・パターンは、異なるものと見なされます。

リソースURL: /test.html
問合せ文字列: area=*&dept=*

リソースURL: /test.html
問合せの名前と値
area *
dept *

ポリシー評価中のリソースの一致: 名前と値のペアは、実行時にどの順序で到着しても問題ありません。すべての名前と値が問合せ文字列に一致すれば、一致は成功します。着信リクエストには、定義されたものよりも多くの名前と値のパラメータが含まれる場合がありますが、その場合も一致は成功します。

例1: 他のパターンが同じURL、問合せ文字列変数および追加問合せ文字列変数(revenue=1000)で定義されていない場合、次のパターンが着信URLに一致します。

着信URL→/test.html?area=emea&dept=engg&revenue=1000
リソース・パターン→/test.html

問合せ文字列の名前と値
area emea
dept engg

例1: 同じリソースURLおよび問合せ文字列を含むリソースがあり、1つが単一の文字列、もう1つが名前と値のペアとして定義されている場合、ポリシー評価の一致では、リテラル問合せ文字列が優先され、次に名前と値のペアが検討されます。たとえば、次の例では、a)に一致します。

実行時リクエスト: URL→/test.html?area=emea&dept=engg

リソース・パターン:
a)
リソース:/test.html
問合せ文字列: area=emea&dept=engg

b)
リソース:/test.html

問合せ文字列の名前と値
area emea
dept engg

最善一致、複数のリソース: 複数のリソースが問合せ文字列の名前と値のペアで定義されている場合、リソースの最善一致は、最も多い数の問合せ文字列のパラメータに一致するパターンです。ワイルドカード値が使用された場合、それに次ぐ基準として各パラメータ値の一致率が使用されます。

たとえば、次の2つの問合せ文字列パターンが定義されているとします。

問合せ文字列の名前と値
area e*
dept e*
および
area em*
dept en*

実行時の問合せ文字列のパラメータ:
area emea
dept engg

結果: 2つ目の名前と値のパターンの方が一致順位が高くなります。

図17-12は、リソース定義ページを示しています。ここに示される、「rev*」は有効な名前です(アスタリスク文字は許可され、リテラル文字として扱われます。これは10gと同等の動作です)。Oracle Access Managementコンソールを使用すると、問合せ文字列を名前と値のペアとして追加できます。問合せ文字列をリテラル文字列として追加することもできます。リテラル問合せ文字列を選択した場合、名前と値のオプションは無効になります。リテラル問合せ文字列を選択しなかった場合、このオプションは有効になります。

図17-12 HTTPリソース、問合せ文字列のリソースURLコントロール

「図17-12 HTTPリソース、問合せ文字列のリソースURLコントロール」の説明

Access Managerに移行するときの動作: Access Managerに(10gから)アップグレードする場合、以前の問合せ文字列は(単一の文字列であるか名前と値のペアであるかにかかわらず)11gに適切に作成されます。適切なタイプの問合せ文字列がAccess Managerに作成されます。

17.5.1.5 リソース定義のリテラル問合せ文字列について

ポリシー・モデルでは、アクセス・ポリシー内の完全なリテラル問合せ文字列ベースの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エージェントには、リソースごとに認証スキームを施行する機能はありません。かわりに、単一の認証スキームがアプリケーションの全リソースに適用されます。

17.5.1.6 実行時のリソース評価について

リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。

関連項目:

次の項に記載されているその他の処理の詳細

- 「リソースURL、接頭辞およびパターンについて」

- 「リソース定義の問合せ文字列の名前と値のパラメータについて」

- 「リソース定義のリテラル問合せ文字列について」

- 「実行時のポリシー評価キャッシュの管理」

プロセスの概要: リソースの評価

1. ユーザーは、リクエストしたリソースのURLを指定します。

2. Access Managerでは、ホスト識別子およびURLに基づいて、URLパターンを含む完全修飾URLが作成されます。

3. Access Managerは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。

- 一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。

- リクエストしたユーザーがアクセスを許可された場合、リソースが提供されます。

表17-7は、可能性のある結果を示しています。

表17-7 リソース評価の結果

結果

説明

最善一致

最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。

一致なし

一致なしの場合、デフォルトの評価結果は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」のみ含みます。

17.5.2 アプリケーション・ドメインのリソースの定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して保護するリソース定義を対応するアプリケーション・ドメインに追加できます。

個別の問合せパラメータのリストに基づくリソースの保護は、リテラル問合せ文字列よりもセキュアで管理が容易です。問合せパラメータ(文字列および名前と値のペア)を含むリソースURLに基づいてポリシーを作成することが必要な場合があります。

注意:

無効なホスト識別子の値を指定すると、次のエラーが発生する場合があります。チャレンジURLが無効です。

前提条件

共有コンポーネントとしてリソース・タイプを定義する必要があります。リソース定義ページのいくつかの要素は、定義および選択されたリソース・タイプに基づいています。詳細は、「リソース・タイプの管理」を参照してください。

関連項目:

「アプリケーション・ドメインのリソースの定義について」

リソース定義をアプリケーション・ドメインに追加するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、Oracle Access Managementコンソールで目的のアプリケーション・ドメインを検索および表示します。

2. 「アプリケーション・ドメイン」で、「リソース」タブをクリックし、「検索」ページの右上端にある「新規リソース」ボタンをクリックします。

3. リソース定義ページで、次の手順を実行します。

1. 単一のリソースの詳細を選択または入力します(表17-1)。
タイプ
説明
ホスト識別子
リソースURL(表17-4)
操作
問合せ文字列(表17-6)
保護レベル
認証ポリシー(レベルが「保護」の場合)
認可ポリシー(レベルが「保護」で「認証ポリシー」が選択されている場合)

2. 「適用」をクリックして、このリソースをアプリケーション・ドメインに追加します。

3. この手順を繰り返して、他のリソースをこのアプリケーション・ドメインに追加します。

4. 次の項の説明に従って、アプリケーション・ドメイン内の特定のポリシーに
定義済リソースを追加します。

- 特定のリソースの認証ポリシーの定義

- 特定のリソースの認証ポリシーの定義

- トークン発行ポリシー、条件およびルールの管理

17.5.3 リソース定義の検索

この項の内容は次のとおりです。

- 特定のリソース定義の検索について

- 特定のリソース定義の検索

17.5.3.1 特定のリソース定義の検索について

図17-13は、アプリケーション・ドメイン内のリソース定義のデフォルトの検索要素および検索結果の表を示しています。

図17-13 アプリケーション・ドメイン内のリソース定義の検索例

「図17-13 アプリケーション・ドメイン内のリソース定義の検索例」の説明

デフォルトを使用して「検索」ボタンをクリックするか、リソースを探すために表17-8に示す情報を必要に応じてできるだけ多く、またはできるだけ少なく指定して検索を絞り込みます。

表17-8 アプリケーション・ドメイン内のリソースの検索要素

検索要素

説明

リソース・タイプ

定義されたリソース・タイプのリストから選択できます。空白にしておくこともできます。

デフォルト値: HTTP

ホスト識別子

必要に応じて、ホスト識別子をここに入力します。ここは空白のままにできます。

デフォルト値: 空白

リソースURL

必要に応じて、リソースURLを入力します。ここは空白のままにできます。

デフォルト値: 空白

問合せ文字列

リソースの問合せ文字列を入力するか、空白のままにします。アプリケーション・ドメインへの追加時に、リソースの問合せ文字列が定義されている場合は、この要素を検索条件に含めることができます。

デフォルト値: 空白

認証ポリシー

このアプリケーション・ドメインに定義された認証ポリシーのリストが表示されます。1つ選択するか、空白のままにします。

デフォルト値: 空白

認可ポリシー

このアプリケーション・ドメインに定義された認可ポリシーのリストが表示されます。1つ選択するか、空白のままにします。

デフォルト値: 空白

「リセット」をクリックしてフォームをクリアするか、「検索」をクリックして検索を開始します。結果表を例17-0に示します。リストされている各リソースには、ドメインへの追加時に指定したすべての要素が含まれています。表では「アクション」メニューおよび「表示」メニューを使用できます。また、「作成」コマンド・ボタンをクリックして、このドメインに新規リソース定義を追加することもできます。

図17-14 アプリケーション・ドメイン内のリソース定義の検索結果例

「図17-14 アプリケーション・ドメイン内のリソース定義の検索結果例」の説明

17.5.3.2 特定のリソース定義の検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のリソース定義を検索できます。

リソース定義を検索する手順は次のとおりです。

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、Oracle Access Managementコンソールで目的のアプリケーション・ドメインを検索および表示します。

2. 「リソース」タブをクリックしてリソース検索コントロールを表示します。

3. 検索条件を入力し(表17-8)、「検索」ボタンをクリックします。

4. 「検索結果」表で、目的のリソース定義をクリックし、必要なアクションを実行します。

- 「アクション」メニュー: 項目を選択して、選択したリソースを作成、編集または削除します。

- 「表示」メニュー: 項目を選択して、結果表の外観を変更します。

- 「編集」ボタン: ツールバー内のこのボタンをクリックして、構成ページを表示します。

- 「削除」: 「リソース定義の表示、編集または削除」を参照してください。

- 連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。

17.5.4 リソース定義の表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメイン内のリソース定義を変更できます。

ポリシーに関連付けられているリソースの保護レベルが「保護」から「除外」に変更された場合、その変更は失敗します。まずポリシーからリソースを削除してから、変更を加えて、リソースをポリシーに追加してください。

注意:

リソースがポリシーに関連付けられている場合、削除中にアラートが表示されます。ポリシーに関連付けられていない場合、リソースは削除されます。

前提条件

目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。

関連項目:

「アプリケーション・ドメインのリソースの定義について」

リソース定義を表示、変更または削除するには

1. 「リソース定義の検索」で説明したように、リソースを検索します。

- 表示のみ: 終了する場合はページを閉じます。

- 変更: 必要に応じて定義を変更し、「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

- 削除:

- 目的のリソース定義を開いて削除対象であることを確認し、ページを閉じます。

- 目的のリソース定義の名前をクリックして、ツールバーの「削除」ボタンをクリックします。

- 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
リソースがポリシーに関連付けられている場合、まずリソースをそのポリシーから削除します。

- 必要に応じてこの手順を繰り返し、アプリケーション・ドメインの他のリソースを削除します。

17.6 特定のリソースに対する認証ポリシーの定義

1つの認証ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認証ポリシーの変更、新しいポリシーの追加、および認証ポリシーへのリソースの割当てを開始できます。

自動的に生成されたアプリケーション・ドメインでは、次の認証ポリシーがデフォルトとしてシードされ、管理者のタスクを効率化できます。

- 保護されているリソース

- パブリック・リソース

関連項目:

「コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解」

この項の内容は次のとおりです。

- 認証ポリシー・ページについて

- 特定のリソース用の認証ポリシーの作成

- 認証ポリシーの検索

- 認証ポリシーの表示または編集

- 認証ポリシーの削除

17.6.1 「認証ポリシー」ページについて

管理者は、認証ポリシーを使用して特定のリソースを保護できます。認証ポリシーは、ポリシーで制御されたリソースの唯一の認証方式を提供します。

各認証ポリシーにより、Access Managerの十分な信頼レベルを提供してリクエストを実行するユーザーにアクセス権を付与するために実行する必要がある検証のタイプが定義されます。

認証ポリシーはローカルです。単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。

認証ポリシーのガイドライン

1. 認証ポリシーには、リソース、成功レスポンスおよび認証スキームが含まれます。

2. 認証および認可ポリシーを成功または失敗で評価できます。

3. クエリー・ビルダーおよびLDAPフィルタのサポート(特定の表示タイプの属性に基づく一致を取得する場合など)。

4. 決められた範囲内で使用できるリソース/…/*のポリシーを定義できます。

5. トークン発行ポリシーは、リソースおよびユーザー・ベースまたはパートナに基づく条件を使用して定義できます。

図17-15は、アプリケーション・ドメインの「認証ポリシー」ページを示しています。

図17-15 アプリケーション・ドメインの「認証ポリシー」ページの例

図17-16は、特定の認証ポリシーを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。この例は、IAM Suiteアプリケーション・ドメインのものです。

図17-16 個々の「認証ポリシー」ページの例

「図17-16 個々の「認証ポリシー」ページの例」の説明

表17-9は、認証ポリシーの要素を示しています。IAM Suiteアプリケーション・ドメインが例として示されています。

表17-9 認証ポリシーの要素および説明

要素

説明

名前

識別子として使用される一意の名前。

説明

認証ポリシーを説明するオプションの一意のテキスト。

認証スキーム

ユーザー認証のためにポリシーで使用される単一の事前定義された認証スキーム。関連項目: 詳細は、「認証スキームの管理」を参照してください。

成功URL

認証の成功時に使用されるリダイレクトURL。

失敗URL

認証の失敗時に使用されるリダイレクトURL。

リソース

リストから選択されたリソースのURL。リストされるURLは、以前にアプリケーション・ドメインに追加されたものです。認証ポリシーで保護する1つ以上のリソースを追加できます。リソース定義は、ポリシーに含める前にアプリケーション・ドメイン内に存在する必要があります。

関連項目: 「認証ポリシーのリソースについて」

レスポンス

Webエージェントで実行される必須処理(認証後のアクション)。認証に成功すると、保護されたアプリケーションをホストするアプリケーション・サーバーは、これらのレスポンスに基づいてユーザー・アイデンティティをアサートできる必要があります。認証に失敗すると、ブラウザはリクエストを事前構成されたURLにリダイレクトします。

関連項目: 「SSOのポリシー・レスポンスの概要」

17.6.1.1 認証ポリシーのリソースについて

認証ポリシーで保護する1つ以上のリソースを追加できます。認証ポリシー・ページの「リソース」タブには、リソースURLを入力できる表が用意されています。アプリケーション・ドメイン内の定義済リソースから選択できるリストも用意されています。

リソースを追加するには、「+」ボタンをクリックして、リストから選択します。リソースを削除するには、「リソース」表から名前を選択して、表の「削除」ボタンをクリックします。

17.6.2 特定のリソース用の認証ポリシーの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証ポリシーおよびリソースをアプリケーション・ドメインに追加できます。認証ポリシーの事前構成された認証スキームまたはカスタム認証スキームを使用できます。

関連項目:

- 「認証ポリシー・ページについて」

- 「認証スキームの管理」

前提条件

ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。

特定のリソースの認証ポリシーを追加するには、次の手順を実行します。

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 「認証ポリシー」タブをクリックし、次に「認証ポリシーの作成」ボタンをクリックして、新しいページを開きます。

3. 必須要素: このポリシーの情報を追加します。

- 名前

- 認証スキーム

4. オプション要素(表17-9): ポリシーに必要な場合は追加します。

- 説明(オプション)

- 成功URL

- 失敗URL

5. リソースの追加: リソースを特定のポリシーに追加するには、そのリソースをアプリケーション・ドメイン内で定義する必要があります。

- 認証ポリシー・ページの「リソース」タブをクリックします。

- 「リソース」タブの「追加」ボタンをクリックします。

- 「Search」ボタンをクリックします。

- 「結果」表内のURLをクリックし、「選択済の追加」をクリックします。

- 必要に応じてこれらの手順を繰り返して、リソースを追加します。

6. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

7. レスポンス: 「SSOのポリシー・レスポンスの追加および管理」の説明に従って、ポリシーのレスポンスを追加します。

8. 終了する場合はページを閉じます。

17.6.3 認証ポリシーの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認証ポリシーを検索できます。

アプリケーション・ドメインの認証ポリシーを検索するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 「認可ポリシー」タブをクリックし、次の操作を実行します。

- 編集: 「認証ポリシーの表示または編集」を参照してください。

- 削除: 「認証ポリシーの削除」

- 表の連結解除: 表を1ページ全面に展開するには、ツールバーの「連結解除」をクリックします。

- 「表示」メニュー: メニュー項目を選択して、結果表の外観を変更します。

17.6.4 認証ポリシーの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインの認証ポリシーを変更できます。これには、認証スキームの変更、リソースやレスポンスの追加または削除および成功または失敗URLの変更が含まれます。

関連項目:

「認証ポリシー・ページについて」

認証ポリシーを表示または変更するには、次の手順を実行します。

1. 「認証ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 目的のポリシー名をクリックして、その構成を表示します。

3. ポリシー要素を編集します(表17-9)。

4. リソース: 「リソース」タブをクリックし、次の操作を実行します。

- 追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。

- 削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。

5. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

6. レスポンス: レスポンスを表示または編集します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

7. 終了する場合はページを閉じます。

17.6.5 認証ポリシーの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインから認証ポリシーを削除できます。

ポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、ポリシーおよびすべてのレスポンスが削除されます。

注意:

削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。

次の手順は、全体のポリシーの削除方法を示しています。ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。

関連項目:

「認証ポリシー・ページについて」

認証ポリシーを削除するには、次の手順を実行します。

1. 「認証ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 目的のポリシー名をクリックして、この構成を表示および確認します。

3. このポリシーで制御されたリソースが別のポリシーに追加されていることを確認します。

4. すべてのレスポンスを削除します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。

5. 「認証ポリシー」タブで、ポリシーの横にある「シリアル番号」をクリックし、ツールバーの「削除」ボタンをクリックします。

6. 確認ウィンドウで、確認して「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

17.7 特定のリソースの認可ポリシーの定義

1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。

自動的に生成されるアプリケーション・ドメインでは、デフォルトとして次の認可ポリシーがシードされます。

- 保護されているリソース

- パブリック・リソース

関連項目:

「コンソールを使用したアプリケーション・ドメインおよびポリシーの管理の理解」

リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認可ポリシーの変更、新しいポリシーの追加および認可ポリシーへのリソースの追加を開始できます。この項の内容は次のとおりです。

- 特定のリソースの認可ポリシーについて

- 認可ポリシーおよび特定のリソースの作成

- 認可ポリシーの検索

- 認可ポリシーおよびリソースの表示または編集

- 認可ポリシー全体の削除

17.7.1 特定のリソースの認可ポリシーについて

管理者は、認証されたユーザーまたは環境の属性に基づいて、1つ以上のリソースへのアクセスを保護する認可ポリシーを作成できます。認可ポリシーは、ポリシーに含まれるリソースの唯一の認可保護を提供します。

認可ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。

単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。

図17-17は、アプリケーション・ドメイン内の「認可ポリシー」ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。

図17-17 個々の「認可ポリシー」ページの例

「図17-17 個々の「認可ポリシー」ページの例」の説明

表17-10は、認可ポリシーの要素を示しています。ドメインに関係なく要素は同じで、詳細のみ異なります。

表17-10 認可ポリシーの要素および説明

要素

説明

名前

ナビゲーション・ツリーの識別子として使用される一意の名前。

説明

認可ポリシーを説明するオプションの一意のテキスト。

成功URL

認可の成功時に使用されるリダイレクトURL。

失敗URL

認可の失敗時に使用されるリダイレクトURL。

サマリー

一般情報(通常は「名前」およびオプションの「説明」)。

リソース

認可ポリシーで保護される1つ以上の事前定義されたリソースURL。

条件

「認可ポリシー・ルールおよび条件の概要」も参照。

ルール

「認可ポリシー・ルールおよび条件の概要」も参照。

レスポンス

「SSOのポリシー・レスポンスの概要」も参照してください。

17.7.2 認可ポリシーおよび特定のリソースの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーをアプリケーション・ドメインに追加できます。

前提条件

ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。

関連項目:

「特定のリソースの認可ポリシーについて」

認可ポリシーおよびリソースを作成するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 「認可ポリシー」タブをクリックし、次に「認証ポリシーの作成」ボタンをクリックして、新しいページを開きます。

3. 「サマリー」タブ: 情報を「サマリー」タブに追加します(表17-10)。

4. リソースの追加: リソースを特定のポリシーに追加するには、そのリソースをアプリケーション・ドメイン内で定義する必要があります。

- 「認可ポリシー」ページの「リソース」タブをクリックします。

- 「リソース」タブの「追加」ボタンをクリックします。

- 「検索」ボタンをクリックします。

- 「結果」表内のURLをクリックし、「選択済の追加」をクリックします。

- これらの手順を繰り返して、さらにリソースを追加します。

5. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

6. レスポンス: 「SSOのポリシー・レスポンスの追加および管理」の説明に従って、ポリシーのレスポンスを追加します。

7. 条件: 「認可ポリシー条件の定義」の説明に従って、認可条件を追加します。

8. 条件: 「認可ポリシー・ルールの定義」の説明に従って、認可ルールを追加します。

9. 終了する場合はページを閉じます。

17.7.3 認可ポリシーの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認可ポリシーを検索できます。

図17-18 「認可ポリシー」ページ

認可ポリシーを検索するには、次の手順を実行します。

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 「認可ポリシー」タブをクリックし、次の操作を実行します。

- 編集: 「認可ポリシーおよびリソースの表示または編集」を参照してください。

- 削除: 「認可ポリシー全体の削除」を参照してください。

- 表の連結解除: 表を1ページ全面に展開するには、ツールバーの「連結解除」をクリックします。

- 「表示」メニュー: メニュー項目を選択して、結果表の外観を変更します。

17.7.4 認可ポリシーおよびリソースの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメイン内の認可ポリシーを表示または変更できます。

関連項目:

「特定のリソースの認可ポリシーについて」

認可ポリシーを表示または編集するには、次の手順を実行します。

1. 「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。

2. サマリー: 必要に応じて編集します(表17-10)。

3. リソース: 「リソース」タブをクリックし、必要に応じて次のようにリソースを追加または削除します。

- 追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。

- 削除: 「リソース」表のURLをクリックし、表の「削除」ボタンをクリックした後、確認します。

4. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

5. 条件: 「認可ポリシー条件の表示、編集または削除」を参照してください。

6. ルール: 「認可ポリシー・ルールの定義」を参照してください。

7. レスポンス: 「SSOのポリシー・レスポンスの表示、編集または削除」を参照してください。

8. 終了する場合はページを閉じます。

17.7.5 認可ポリシー全体の削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーまたはポリシー内のリソースを削除できます。

注意:

削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。

全体のポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、アクセスを制御する認可ポリシー、条件およびルールが削除されます。

ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。

関連項目:

「特定のリソースの認可ポリシーについて」

前提条件

ポリシーを削除する前または後に、ポリシーで制御されたリソースを別の認可ポリシーに割り当てます。

認可ポリシーを削除するには、次の手順を実行します。

1. 「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。

2. オプション: ポリシー名をダブルクリックして内容を確認し、終了したらページを閉じます。

3. 削除: ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックします。

4. 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。

5. ポリシーがナビゲーション・ツリーにリストされていないことを確認します。

17.8 SSOのポリシー・レスポンスの概要

各ポリシーは、1つ以上の認証または認可レスポンスあるいはその両方をオプションで含むことができます。レスポンスは、Webエージェントで実行される後処理のアクション(必須処理)です。

注意:

トークン発行ポリシーにはレスポンスがありません。

この項の内容は次のとおりです。

- SSOの認証および認可ポリシー・レスポンスについて

- ポリシー・レスポンスの言語について

- ポリシー・レスポンスのネームスペースおよび変数名について

- SSOのポリシー・レスポンスの構築について

- ポリシー・レスポンス処理について

- アサーションの要求および処理について

17.8.1 SSOの認証および認可ポリシーのレスポンスについて

管理者は、認証または認可が成功した後に実行する必要があるアクションを宣言するレスポンスを定義できます。認証および認可データがクライアント(通常はWebエージェント)に戻されます。

ポリシー・レスポンスにより、情報をセッションまたはアプリケーションに挿入し、SSOを有効化するために後で情報を抽出できます。たとえば、アイデンティティ・マッピングを顧客アプリケーションに挿入するか、エージェントまたはアプリケーションでアクションを実行できます。

認証または認可の成功および失敗に応じて指定されるレスポンスによっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。

注意:

Oracle Access Manager 10gでは、特定の順序のURLのリダイレクトでのみ、アプリケーションのデータの経路を提供しました。

デフォルトのレスポンスは提供されません。図17-19は、Oracle Access Managementコンソールの管理者に定義された認可ポリシー・レスポンスを示しています。認可レスポンスは、認可条件と組み合せて操作できます。

図17-19 コンソールの認可ポリシー・レスポンス

「図17-19 コンソールの認可ポリシー・レスポンス」の説明

各レスポンスは、2つの入力(タイプおよび式)と1つの出力(評価された式の値)で構成されます。式は、式を処理する場合の値の構築方法を宣言します。レスポンス・タイプは、値文字列を使用して実行するアクションの形式を定義します。

- 認証ポリシーは、ユーザーのアイデンティティを決定します。各認証ポリシーには、認証スキームおよびレスポンス(式)が必要です。

- 認可ポリシーは、リソースへのユーザーのアクセス権を付与するかどうかを決定します。各認可ポリシーには、認可条件およびレスポンス(式)が必要です。

レスポンスのガイドライン

1. Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。

2. URLリダイレクトを設定できます。

3. レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。

管理者は、表17-11で説明されているとおり、Oracle Access Managementコンソールのレスポンスを設定します。

表17-11 レスポンスの要素

要素

説明

名前

このレスポンスと同じメカニズム(タイプ)を使用する他のレスポンスを区別する一意の名前。

タイプ

レスポンスを伝達するために使用されるメカニズム。値文字列を使用して実行するアクションの形式。

- HEADER(ヘッダー変数): 定義された値を使用して実行するアクション(事前定義されたHTTPヘッダー名を使用したユーザーIDのアサーションなど)を指示するダウンストリーム・アプリケーションのHTTPリクエスト・ヘッダーを設定します。もう一つの例として、更新時に、OSSOのサブスクライバ情報(レルムDNなど)を取得して、レスポンスを作成します。新しいOSSOエージェントは、手動で構成する必要があります。

- SESSION: 定義されたセッション変数名および値に基づいて、シングル・サインオンを有効化するためにクライアントがユーザー・セッション内の属性を設定します。

- COOKIE: 通常はWebエージェントによって設定される認証セッションCookie内の変数名および値を設定して、シングル・サインオンを有効化します。
Cookieなしモードの場合、WebgateからCookieを格納するWebキャッシュが現在使用されています。ただし、Cookieなしモードの場合、エンド・アプリケーションでCookieにアクセスしてCookieを使用できません。

- アサートされた属性: このタイプの場合、このポリシーの実行時に「アサーション属性」タイプ・レスポンスを収集するには、このポリシーでIDアサーションを有効にする必要があります。「名前」リストでは、選択対象の有効な識別子が提供されます。

値

変数として設定されるレスポンスの式。

詳細は、「ポリシー・レスポンスの言語について」を参照してください。

IDアサーション

IDアサーションは、エンド・ユーザー(およびそのAccess Managerセッション)を表す、Access Managerから発行されたトークンのID伝播に必要です。

リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを得るためにトークンをリクエストするAccess Managerによって保護されるWebアプリケーションであるセキュリティ・トークン・サービス・クライアントでは、エンド・ユーザーを表すAccess Manager IDアサーションを渡す必要があります。

IDアサーション・トークンは、正常に認証された後に生成され、ポリシー・レスポンス(名前が「OAM_IDENTITY_ASSERTION」で値がSAMLトークンというHTTPヘッダー)として返されます。

(「アサートされた属性」以外のタイプの)レスポンスを追加するたびに、「アイデンティティ・アサーションはこのポリシーに対して有効になっていません...」というメッセージが表示される場合があります。ポリシーの実行時に「アサートされた属性」タイプ・レスポンスを収集するには、IDアサーションを有効にします。

関連項目:

- 「シナリオ: Access Managerトークンを使用したアイデンティティ伝播」

- 「WebgateによるIDアサーションの認証ポリシー・レスポンス」

- 第41章「アイデンティティ・コンテキストの使用」

17.8.2 ポリシー・レスポンスの言語について

次の2つの主な構造とともに非常に小規模なドメイン固有言語(DSL)を使用して、Access Manager認証および認可レスポンスを定義します。

- リテラル文字列: This is a valid expressionなどです。

- 変数の参照

- ドル記号の接頭辞($)を使用して宣言します。

- ネームスペース$namespace.var_nameでスコープされます。

注意:

変数に$ns.name.attribute属性が含まれる場合があります。

17.8.3 ポリシー・レスポンスのネームスペースおよび変数名について

ネームスペース・メカニズムを使用すると、次の変数タイプでシングル・サインオンが有効化します。

- リクエスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報

- セッション: ユーザー・セッションの詳細

- ユーザー: ユーザーの詳細(ユーザーID、グループおよび属性情報)

詳細は、次の表を参照してください。

- 表17-12「シングル・サインオンのネームスペース・リクエスト変数」

- 表17-13「シングル・サインオンのネームスペース・セッション変数」

- 表17-14「ネームスペース・ユーザー変数」

表17-12 シングル・サインオンのネームスペース・リクエスト変数

ネームスペース

説明

agent_id

リクエストしているエージェントの名前

client_ip

ユーザー・ブラウザのIPアドレス

policy_appdomain

リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前

policy_res

リクエストに一致するリソース・ホストIDおよびURLパターン

policy_name

リクエストに一致する特定のポリシーの名前

res_host

リクエストしたリソースのホスト名

res_port

リクエストしたリソースのポート番号

res_type

リクエストしたリソースのタイプ

res_url

リクエストしたリソースURL

表17-13 シングル・サインオンのネームスペース・セッション変数

ネームスペース

説明

attr

名前が変数属性として渡される任意のセッション属性の参照。前のリクエストでセッション・レスポンスを実行することで、値がセッションにバインドされています。

authn_level

セッションの現在の認証レベル

authn_scheme

現在の認証レベルを実現するために実行される認証スキームの名前

count

セッションにバインドされたユーザーのセッション数

creation

セッションの作成時間

expiration

セッションの有効期間

表17-14 ネームスペース・ユーザー変数

ネームスペース

説明

attr

名前が変数属性として渡される任意のLDAP属性の参照。

groups

ユーザーのグループ・メンバーシップのカンマ区切りリスト

userid

ユーザーID

user.id_domain

ユーザーのアイデンティティ・ドメイン(基本的にアイデンティティ・ストアと同じ)

guid

アイデンティティ・ストアでユーザー・エントリを特定する一意の識別子

17.8.4 SSOのポリシー・レスポンスの構築について

この項の内容は次のとおりです。

- 単純なレスポンス

- 複合的および複雑なレスポンス

関連項目:

条件に基づく認可レスポンスのガイドライン

17.8.4.1 単純なレスポンス

レスポンス・タイプとネームスペースおよび変数を決定した後、Oracle Access Managementコンソールでレスポンス属性を入力します。図17-20に示すように、単純なレスポンスはいくつかの認可レスポンスのいずれかのようになります。

図17-20 単純なレスポンスのサンプル

「図17-20 単純なレスポンスのサンプル」の説明

単純なレスポンスはスタンドアロンです。それぞれの先頭にドル記号($)が付けられ、変数値とドット(.)で区切られるネームスペースがその後に付けられます。次に例を示します。

$namespace1.var1

表17-15は、いくつかの単純なレスポンスおよびそれぞれに戻される内容の説明を示しています。

表17-15 単純なレスポンスおよび説明

名前

タイプ

値(単純な$ネームスペース.変数)

戻される環境変数および値

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

17.8.4.2 複合的および複雑なレスポンス

複合的または複雑なポリシー・レスポンスを作成する場合、管理者は、中括弧{}を使用してリテラルおよび変数を任意に結合して式を構築できます。コロン(:)はセパレータとして使用されます。次に例を示します。

${namespace1.var1}:${namespace2.var2}

リテラル文字列(LS): ${namespace1.var1}:${namespace2.var2}

LS: ${namespace1.var1}, LS:${namespace2.var2}

図17-21は、管理者によって定義されるいくつかの複雑なレスポンスを示しています。すべてがヘッダー・タイプ・レスポンスで、ダウンストリーム・アプリケーションで利用されるHTTPリクエストのヘッダー変数の値が設定されます。

図17-21 複雑なレスポンスの例

「図17-21 複雑なレスポンスの例」の説明

表17-16は、図17-21に示す複雑なレスポンスの説明です。

表17-16 複雑なレスポンス

名前

値

戻される環境変数および値

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 Oct 23 17:47:42 PST 2011/Wed Oct 24 01:47:42 PST 2011/7

oam_app_user

$user.userid

HTTP_OAM_USERID 名前

詳細は、「ポリシー・レスポンス処理について」を参照してください。

17.8.5 ポリシー・レスポンス処理について

ポリシー・レスポンス処理は、認証レスポンスを再実行する認可リクエストの実行中に発生します。変数の参照に適切な値が入力され、すべての変数に値が設定されて認可値で一貫して設定できることを確認します。

一連の手順を実行して、レスポンスの式を処理します。

- スキャナ/トークナイザ

- パーサー

- インタープリタ
解釈中、値の変数の参照が解決します。処理後の結果は単純な文字列値で、エージェントに伝播されるか、将来の使用に備えてセッション内に保存されます。

最初の適用される認可リクエストの認可レスポンスとともに認証の成功レスポンスが保存され、“再実行”されます。

認可レスポンスの式は、式の評価(成功、失敗または未確定)に応じて実行されるアクションを作成します。

注意:

Oracle Access Manager 10gでは、認証Webgate構成内と同じ動作を示します。これはAccess Manager 11gで10g Webgateを使用した場合にも適用されます。10g Webgateは常に、認証Webgateのような働きをするAccess Manager 11g資格証明コレクタにリダイレクトします。

変数を参照すると、値または次の内容が戻されます。

- 変数が設定されていない場合、NOT FOUNDが戻されます。

- 変数がnull値に設定されている場合、NULLが戻されます。

注意:

レスポンスを検証してください。

処理のないパススルー

処理しないでパススルーを実行する必要がある値は、\を使用して識別できます。次に例を示します。

\$1000

値$1000の結果が戻される値に表示されます。

17.8.6 アサーションの要求および処理について

詳細は、第41章「アイデンティティ・コンテキストの使用」を参照してください。

17.9 SSOのポリシー・レスポンスの追加および管理

ポリシーおよびレスポンスを使用してシングル・サインオンを有効化し、他のディレクティブを上書きできます。この項のアクティビティを開始する前に、「SSOのポリシー・レスポンスの概要」を確認してください。

特に指定のないかぎり、この項の情報が認証および認可レスポンスに同等に適用されます。

- SSOのポリシー・レスポンスの追加

- SSOのポリシー・レスポンスの表示、編集または削除

17.9.1 SSOのポリシー・レスポンスの追加

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを保護されたリソース・ポリシーに追加できます。

たとえば、Oracle Internet Directoryをインストールしたときに作成される、レルムのDNを収集できます。オプションとして、Oracle Internet Directory内のサブスクライバのグローバル・ユーザーIDや、サブスクライバ名(デフォルトの会社ではなく)を構成することもできます(表17-17を参照)。

表17-17 新しいOSSOのインストール: 保護されたポリシー・レスポンス(ヘッダー)

レスポンスのパラメータ

OIDがインストールされたときにレルムDNを収集する

OID内のサブスクライバのGUIDを別の会社に構成する

OID内のサブスクライバのGUIDをデフォルトの会社に構成する

名前

osso-subscriber-dn (小文字)

osso-subscriber (オプション)

osso-subscriber-guid (オプション)

タイプ

ヘッダー

ヘッダー

ヘッダー

値

dc=country,dc=example,dc=com

dc=country_or_region,dc=com

,dc=default_company,dc=com

サブスクライバDN(たとえば、Oracle Internal Directory内)に移動して、値(たとえば、そのDNのorclguid)を検出します。

前提条件

認可レスポンスを作成する前に目的の条件を分析して、レスポンスによって適切なアクションが実行されることを確認します。認証または認可ポリシーが存在しているアプリケーション・ドメインが必要です。

関連項目:

「SSOのポリシー・レスポンスの概要」

ポリシー・レスポンスを追加するには

1. 「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。

2. 個々のポリシー・ページで、「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックした後、次の操作を実行します。

- 「名前」フィールドに、このレスポンスの一意の名前を入力します。

- 「タイプ」リストから、レスポンス・タイプ(セッション、ヘッダーまたはCookie)を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。たとえば、$namespace1.var1などです。

関連項目:

「ポリシー・レスポンスのネームスペースおよび変数名について」

- 必要に応じて繰り返します。

3. 「適用」をクリックして、確認ウィンドウを閉じます。

4. 終了する場合はページを閉じます。

5. 定義内容に基づいて、レスポンスを検証します。

17.9.2 SSOのポリシー・レスポンスの表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを表示または編集できます。

前提条件

認証または認可ポリシーが存在しているアプリケーション・ドメインが必要です。

関連項目:

「SSOのポリシー・レスポンスの概要」

ポリシー・レスポンスを表示、変更または削除するには、次の手順を実行します。

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 「認証ポリシー」(または「認可ポリシー」)タブをクリックし、目的のポリシー名をクリックします。

3. 個々のポリシー・ページで、「レスポンス」タブをクリックし、必要に応じて先に進みます。

- 追加: 「SSOのポリシー・レスポンスの追加」を参照してください。

- 編集: 目的のレスポンスの名前、タイプまたは値をクリックし、必要に応じて編集して「適用」をクリックします。

- 削除: 目的のレスポンスをクリックして、「レスポンス」表の「削除」ボタンをクリックします。

4. 確認ウィンドウを閉じます。

5. 終了する場合はページを閉じます。

6. 定義に基づいて、次のレスポンスを確認します。

- ヘッダー

- セッション

- Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。

- アサーションの要求

17.10 認可ポリシー・ルールおよび条件の概要

Access Manager 11gでは、各認可ポリシーに、そのポリシーによって保護されるリソースへのアクセスを許可するか拒否するかを定義するルールが含まれます。ルールでは、アクセスを許可または拒否されるユーザーや移入を定義する条件、および認可に関するその他の考慮事項が参照されます。認可ルールおよび条件は、特定の認可ポリシー内のすべてのリソースに適用されます。

条件およびルールの評価により、認可ポリシーを着信リクエストに適用するかどうかが決定されます。認証に成功した後、適切な必須処理が有効になり、定義された認可ルール、条件およびレスポンスと連携して動作します。着信リクエストごとに、認可ポリシーによって、適用される条件が存在するかどうかが決定されます。その場合、これらの条件が評価されます。

この項の内容は次のとおりです。

- 許可または拒否ルールについて

- 認可ポリシー条件について

- 条件のユーザーおよびグループの分類について

- 条件に基づく認可レスポンスのガイドライン

17.10.1 許可または拒否ルールについて

認可ポリシーでは、そのポリシー用に定義されたすべての条件(またはサブセット)がルールに含まれます。ルールの影響によって、ポリシーの影響が決まります。

ポリシーごとに、1つ以上のルールの影響(結果)を設定できます。ただし、結果ごとに指定できるルールは1つのみです。次の結果を認可およびトークン発行ポリシーに適用できます。

- 認可されたユーザーによる、保護されたリソースへのアクセスを許可します。許可条件がユーザーに適用されない場合、ユーザーがポリシーの対象外となり、デフォルトでリクエストしたリソースへのユーザーのアクセスが拒否されます。

- 認可されたユーザーによる、保護されたリソースへのアクセスを拒否します。

単一条件に依存する単純なルールを作成するか、式を使用して複数の条件に基づくより複雑なルールを定義します。詳細は、「式および式ベースのポリシー評価について」を参照してください。

17.10.2 認可ポリシー条件について

条件は、アクセス・リクエストで満たす必要がある1つ以上の基準を指定する要素です。条件の構造は制約と似ています(11.1.1.3および11.1.1.5を参照)。ただし、以前の制約に含まれていた許可および拒否ルールは、個別に「ルール」タブで指定されます。

各認可ポリシーには1つ以上の条件を含めることができます。様々な条件タイプを使用すると、次のことが可能になります。

- 保護されたリソースへのアクセスが(ルールに基づいて)許可または拒否されるユーザーまたはユーザー・グループの識別。

- 保護されたリソースのアクセスを許可または拒否するIPアドレスの範囲の指定。

注意:

ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。

- 条件の適用期間を定義する時間の設定。

- リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。

「条件」タブでは、図17-22のように、名前別に整理された定義済条件の表、および選択した条件の詳細を示す表が提供されます。

図17-22 個々の認可ポリシーの「条件」タブ

「図17-22 個々の認可ポリシーの「条件」タブ」の説明

表17-18は、「条件」タブの要素およびコントロールを示しています。

表17-18 認可ポリシーの「条件」タブ

要素

説明

「条件」の表の要素

このポリシー用に定義されたすべての条件をリストします。

名前

条件の識別子として使用される一意の名前。

タイプ

使用する条件の種類。次のタイプから1つのみ指定できます。

- アイデンティティ

- IP4範囲

- 一時的

- 属性

- True (表15-5を参照)

説明

この条件を説明するオプションの一意のテキスト。

「条件詳細」セクション

この表の情報は、選択した条件のタイプによって異なります。詳細は、次の項を参照してください。

- 「アイデンティティ条件について」

- 「IP4範囲条件タイプについて」

- 「一時的条件について」

- 「属性条件について」

17.10.3 条件のユーザーおよびグループの分類について

ユーザーおよびグループを分析して明示的にアクセスを許可または拒否するユーザーを決定する場合、ポリシーおよび条件に同じ情報を使用することをお薦めします。たとえば、特定のユーザー・グループ(アイデンティティ・タイプ)に制約される認可ポリシーがある場合、特定の時間(一時的タイプ)に制約される認可ポリシーがある可能性があります。

注意:

任意の条件でアクセスを拒否されるユーザーについては気にしないでください。どのアクセス条件も満たしていない場合、デフォルトでユーザーのアクセスは拒否されます。

ユーザーを分類する場合、ユーザーおよびユーザー・グループを異なる条件が適用されるグループに分割することをお薦めします。たとえば、ユーザーがリソースにアクセスできる時間帯や、ユーザーがリクエストを行う場合に使用する必要があるコンピュータなどの条件を指定できます。

マーケティング・グループのユーザーが特定のプロジェクト・グループに属し、人事管理グループのユーザーもプロジェクト・グループに属する場合などの一部のユーザーが複数のカテゴリに該当する場合、両方のカテゴリにユーザーを配置します。ユーザーが2つの条件を満たすことを必須にできます。

アプリケーション・ドメイン内でリソースのサブセットに対してポリシーを作成し、そのサブセットを別の認可ルールおよび条件で保護するには、同じ情報、つまり、このポリシーによって保護されるリソースへのアクセスをどのユーザーに許可し、どのような条件でリソースへのアクセスを明示的に許可または拒否するのかを検討します。

17.10.4 条件に基づく認可レスポンスのガイドライン

条件タイプごとに、認可されたユーザーに発生するレスポンス・アクションを検討します。たとえば、戻されたユーザー・プロファイル情報を下流のアプリケーションに渡すこともできます。次に例を示します。

- ユーザーが認可されている場合、アプリケーションでカスタマイズされたメッセージをユーザーに表示できるように、ユーザーの共通名(cn)を別のアプリケーションに渡すことができます。

- ユーザーに使用権が認可されない場合も、ユーザーに関する情報が戻されると、セキュリティのために役立ちます。

17.11 認可ポリシー条件の定義

認可ポリシー内で条件を使用する目的は、次のとおりです。

- ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。

- ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。

- ルールが適用される時間帯を設定します。

- リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。

条件を追加するメカニズムは、どのタイプを選択しても同じです。表示されたダイアログ・ボックスで、名前およびタイプを定義して条件のコンテナを作成します。その後、提供されたコントロールを使用して条件の詳細を定義します。

この項の内容は次のとおりです。

- 条件タイプの選択

- アイデンティティ条件の定義

- IP4範囲条件の定義

- 一時的条件の定義

- 属性条件の定義

- 認可ポリシー条件の表示、編集または削除

17.11.1 条件タイプの選択

この項の内容は次のとおりです。

- 条件タイプの選択について

- 条件タイプの選択

17.11.1.1 条件タイプの選択について

ポリシー内では、特定の条件タイプのインスタンスを複数保持できます。

管理者が条件を認可ポリシーに追加すると、名前、タイプおよびオプションの説明を入力できるウィンドウ(図17-23)が表示されます。送信されると、この情報を使用して、同じく指定する必要がある条件詳細のコンテナが作成されます。

図17-23 「条件の追加」ウィンドウ

「図17-23 「条件の追加」ウィンドウ」の説明

表17-19は、「条件の追加」の要素を説明しています。

表17-19 「条件の追加」ウィンドウの要素

要素

説明

名前

この条件の一意の名前。

タイプ

次のタイプから1つのみ指定できます。

- アイデンティティ(「アイデンティティ条件について」を参照)

- IP4範囲(「IP4範囲条件タイプについて」を参照)

- 一時的(「一時的条件について」を参照)

- 属性(「属性条件について」を参照)

説明

オプション。

コンテナを追加すると、図17-24のように、そのコンテナが「条件」タブに表示されます。「名前」、「タイプ」および「説明」は、タブの最上部にある「結果」表に表示されます。下部のパネルには、条件の詳細が含まれます。

図17-24 「認可ポリシー」ページの条件コンテナ

「図17-24 「認可ポリシー」ページの条件コンテナ」の説明

関連項目:

「認可ポリシー条件の定義」の情報および手順

17.11.1.2 条件タイプの選択

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーの条件クラスを選択できます。

注意:

ポリシー内では、特定の条件クラスのインスタンスを複数保持できます。

前提条件

アプリケーション・ドメインが存在している必要があります。

関連項目:

条件タイプの選択について

条件クラスを選択するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. ポリシー名をクリックして、その構成を開きます。

3. 個々のポリシー・ページで、「条件」タブをクリックします。

4. 「追加」(+)ボタンをクリックし、次の操作を実行します(表17-19)。

- 名前: 一意の名前を入力します。

- 「タイプ」リスト: 条件の種類を選択します(「アイデンティティ」など)。

- 「選択済の追加」ボタンをクリックします。

5. 次のいずれかの項に進み、定義を完了します。

- アイデンティティ条件の定義

- IP4範囲条件の定義

- 一時的条件の定義

- 属性条件の定義

17.11.2 アイデンティティ条件の定義

この項では、アイデンティティ条件に関するすべての情報を提供します。内容は次のとおりです。

- アイデンティティ条件について

- アイデンティティ・タイプ条件の指定

17.11.2.1 アイデンティティ条件について

アイデンティティ条件を定義する場合、1つ以上のユーザー・アイデンティティ・ストアから、ユーザー移入の1つ以上のメンバーを追加する必要があります。ユーザー移入は、ユーザーまたはグループのリストとして追加できます。また、実行時に使用するLDAP検索フィルタを追加して、ユーザー移入を識別することもできます。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット・アイデンティティの移入を簡単に指定できます。詳細は、次の各項を参照してください。

- アイデンティティ条件およびユーザー移入について

- アイデンティティ条件でのLDAP検索フィルタのサポートについて

- LDAP検索フィルタの構文について

17.11.2.1.1 アイデンティティ条件およびユーザー移入について

条件コンテナを開いた後、定義されたユーザー移入が表示されます。他の条件タイプと同様、アイデンティティ・タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。

アイデンティティ条件を追加する場合、「追加」(+)ボタンの横にあるポップアップ・メニューを開き(図17-25の1)、「ユーザーとグループの追加」または「検索フィルタの追加」(2)を選択します。図17-25は、ポップアップ・メニューおよび表示される「アイデンティティの追加」ウィンドウ(3)を示しています。目的のアイデンティティを検索したら、それらを選択し、「選択済の追加」(4)をクリックします。

図17-25 「アイデンティティの追加」ウィンドウ

「図17-25 「アイデンティティの追加」ウィンドウ」の説明

表17-20は、「アイデンティティの追加」の要素を示しています。

表17-20 「アイデンティティの追加」の要素

要素

説明

ストア名

この検索に使用するLDAPストアを、登録されたLDAPストアのリストから選択します。

エンティティ・タイプ

「ユーザー」、「グループ」または「すべて」を選択して、検索基準を定義します。

エンティティ名

情報を入力して検索基準をさらに絞り込みます。

検索

検索基準が定義されたときにこのボタンをクリックします。

結果表

検索結果を表示します。

選択済の追加

クリックして、選択したユーザーまたはグループを結果表から条件の詳細に追加します。

1つ以上のアイデンティティを選択し、「選択済の追加」ボタンをクリックすると、「条件」タブは図17-26のようになります。

図17-26 アイデンティティ条件および詳細

「図17-26 アイデンティティ条件および詳細」の説明

条件としてこれらの詳細を保存するには、タブの右上の「保存」ボタンをクリックします。

17.11.2.1.2 アイデンティティ条件でのLDAP検索フィルタのサポートについて

Access Manager 11gの認可条件では、許可または拒否されるアイデンティティの一部として、ユーザー、グループおよびLDAP検索フィルタのリストが受け入れられます。LDAPフィルタは、検索操作の特定の基準を表現するテキスト文字列です。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット移入を簡単に指定できます。

Access Manager 11gでは、次の条件およびリソース・タイプ用のLDAP検索フィルタ・データが受け入れられます。

- アイデンティティ条件

- トークン・リクエスタ・アイデンティティ条件

- すべてのリソース・タイプ(HTTP、TokenServiceRPおよびその他のカスタム・リソース・タイプ)

ユーザーがLDAP検索フィルタを含む条件によって保護されているリソースへのアクセスを試行すると、Access Managerによって、フィルタの一部として指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対するディレクトリ検索(LDAP検索)が実行されます。検索結果はキャッシュされるため、ディレクトリ・サーバー検索が繰り返し実行されることはありません。

「検索フィルタの追加」を選択すると、図17-27のようなコントロールが表示されます。複数のLDAP検索フィルタを認可ルールに追加し、実行時の評価に使用できます。LDAP検索フィルタを入力したフィールドは、許可または拒否されるユーザーの識別に使用されます。

図17-27 「検索フィルタの追加」のコントロール

表17-21は、検索フィルタの追加に関連付けられている要素を示しています。

表17-21 「検索フィルタの追加」の要素

要素

説明

ドメイン

実行時に検索する必要があるアイデンティティ・ドメイン(登録されたユーザー・アイデンティティ・ストア)。各フィルタは特定のユーザー・アイデンティティ・ストアに関連付けられている必要があります。Access Manager 11gでは、指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対してのみディレクトリ検索(LDAP検索)が実行されます。

検索フィルタ

LDAP検索フィルタを入力するフィールド。次に例を示します。

((|dept=sales)(dept=support))

関連項目: 「LDAP検索フィルタの構文について」

テスト・フィルタ

このボタンを使用すると、LDAP検索フィルタをテストして、予想した結果が返されるかどうかを確認できます。

テスト結果

フィルタ・テストの結果は、独自に指定した次の内容とともに表示されます。

- タイプ: LDAPSearchFilter

- 識別子: 使用するLDAP検索フィルタ

フィルタの追加

このアイデンティティ条件にフィルタを追加するときにクリックします。

取消

フィルタを追加せずに「検索フィルタの追加」ダイアログを閉じるときにクリックします。

図17-28は、LDAP検索フィルタの追加後に表示される、アイデンティティ条件の詳細ページを示しています。

図17-28 アイデンティティ条件の詳細

関連項目:

- 「LDAP検索フィルタの構文について」

- 「アイデンティティ条件の定義」

17.11.2.1.3 LDAP検索フィルタの構文について

LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。正確な構文はアイデンティティ・ストアによって異なるため、ベンダーのドキュメントを参照してください。表17-22は、Access ManagerのLDAP検索フィルタの例を示しています。

表17-22 Access ManagerのLDAP検索フィルタの例

フィルタ・タイプおよび演算子

説明

構文例

静的LDAP検索フィルタ

静的検索フィルタの実装では、すべての検索結果が固定値に一致する必要があります。たとえば、ディレクトリ・プロファイルの組織単位がSalesの人々のみを戻すように検索を制限できます。

単純な静的フィルタの例として、seeAlso属性でセレクタ検索を使用する場合を検討します。このフィルタにより、ディレクトリ・プロファイルにbusinessCategory値としてdealershipを含む人々のみが検索結果として戻されます。

(attribute=value)

次に例を示します。

(businessCategory=dealership)

ワイルド・カードを使用した静的検索

ワイルド・カードを使用する静的フィルタの例として、セレクタを使用した検索時にManagerという語を含む役職の人々のみを戻す場合を検討します。アスタリスク(*)ワイルドカードを使用して文字列Managerを検索するフィルタを作成できます。

(attribute=*value*)

次に例を示します。

(title=*manager*)

動的LDAP検索フィルタ

動的フィルタにより、ユーザー・プロファイルに基づいた検索結果を戻すことができます。動的フィルタは、フィルタ置換構文を使用する従来のLDAP検索フィルタです。

(attribute=$attribute$)

置換構文

置換構文は、タスクを実行するユーザーに応じて動的に評価されます。たとえば、置換構文を入力すると、ソースDN(アプリケーションにログインしているユーザー)の属性値が代入され、ターゲットDN(参照しようとしているエントリ)に対して評価されます。

注意: 検索ベースを設定すると深刻な管理オーバーヘッドが発生する可能性があります。置換構文で指定されるフィルタ・ベース・アプローチにより提供される機能は、よりスケーラブルで簡易化された設計と同一です。

置換構文を使用すると、ディレクトリ構造の上位検索を開始する関数を作成できますが、この関数は、検索開始者のレコードの情報の属性(たとえば、置換$ou$を使用)を使用可能な結果それぞれのデータの属性(たとえば、ou=)と比較することで、検索データをフィルタ処理します。置換構文は属性アクセス制御および検索ベースに使用できます。たとえば、inetOrgPersonのタイプ属性Loginにフィルタを設定すると、範囲外にあるレコードを表示するユーザーの権限が削除されます。

注意: 選択された検索ベースでは、ユーザーは自分と同じouのエントリのみを検索できます。これはそのユーザーのレコードの属性のみに適用され、エントリが存在するディレクトリのブランチのouには適用されません。また、ou=peopleのユーザーは、選択された検索ベース内のエントリを検索できます。

(attribute=$attribute$)

たとえば、次のフィルタでは、同じ組織単位に属するすべてのエントリが、アプリケーションにログインしているユーザーとして検索されます。

(ou=$ou$)

ワイルド・カードを使用した動的検索

動的フィルタでは、ワイルドカードがサポートされます。

例として、organizationalUnitオブジェクトのcontactPerson属性を指定する場合を検討します。contactPerson属性により、organizationalUnitオブジェクトと同じ郵便番号の人々を戻す必要があります。organizationalUnitプロファイルにzipCodeという属性が含まれており、postalAddressディレクトリ属性の最後に郵便番号が指定されている場合があります。

(attribute=*$attribute$)

次に例を示します。

(postalAddress=*$zipCode$)

否定演算子(!)を使用した検索

フィルタの構築時には、否定演算子がサポートされます。最適化されたアルゴリズムを使用する場合、フィルタ(!(sn=white))では期待した結果は得られません。

((!(sn=white))(objectclass=personOC))

関連項目:

「アイデンティティ・タイプ条件の指定」

(10gから)Access Manager 11gへの移行中、各LDAPルールは、Oracle Access Manager 10gディレクトリ・プロファイルに基づいて、対応する11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)にマップされます。Access Manager 11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)は、各LDAP検索フィルタに関連付ける必要があります。

関連項目:

『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』

17.11.2.2 アイデンティティ・タイプ条件の指定

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、アイデンティティ・タイプ条件をアプリケーション・ドメインに追加できます。

注意:

別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。

前提条件

アプリケーション・ドメインが存在している必要があります。

関連項目:

- 「アイデンティティ条件について」

- 「アイデンティティ条件でのLDAP検索フィルタのサポートについて」

アイデンティティ条件を認可ポリシーに追加するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 「条件」タブをクリックし、「追加」(+)ボタンをクリックします。

3. 「名前」を入力し、「タイプ」リスト(または「トークン・リクエスタ・アイデンティティ」)から「アイデンティティ」を選択して、「選択済の追加」をクリックします。

4. ユーザー/グループの追加:

- 「条件詳細」セクションで、「追加」(+)ボタンをクリックします。

- リストから「ユーザーとグループの追加」を選択します。

- ストア名: 登録されたLDAPストアのリストから目的の名前を選択します。

- 検索する移入の基準(アイデンティティ・タイプおよびアイデンティティ名)を入力し、「検索」ボタンをクリックします。

- 目的の結果を選択します。

- 「選択済の追加」をクリックします。

- 別のユーザーまたはグループの条件を追加するには、この手順を繰り返します。

5. 検索フィルタの追加:

- 「条件詳細」セクションで、「追加」(+)ボタンをクリックします。

- ドメイン名: このフィルタのユーザー・アイデンティティ・ストアを選択します。

- 検索フィルタ: 検索フィルタの構文を入力します(表17-21)。

- テスト: 「テスト・フィルタ」ボタンをクリックし、結果表を確認します。

- 「選択済の追加」ボタンをクリックします。

- 別のLDAP検索フィルタの条件を追加するには、この手順を繰り返します。

6. 「適用」をクリックして、確認ウィンドウを閉じます。

7. 終了する場合はページを閉じます。

8. 異なるユーザーとしてログインすることによって条件を検証し、リソースへのアクセスをテストします。

17.11.3 IP4範囲条件の定義

この項の内容は次のとおりです。

- IP4範囲条件タイプについて

- IP4範囲条件の定義

17.11.3.1 IP4範囲条件タイプについて

IP4範囲条件タイプを使用すると、管理者はアクセスを許可または拒否されるIPアドレス範囲のリストを指定できます。他の認可条件と同様、IP4範囲条件タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。

明示的なアドレス: 指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。

注意:

Oracle Access Manager 10gでは、ワイルドカードが最後の入力として受け入れられます(192.2.2.*や192.2.*など)。ワイルドカードを含まないIP4範囲は、複数のIP4範囲の値を含む条件を作成することによって、簡単に11gに移植できます。ただし、ワイルドカードを含む10gのIP4範囲は、アップグレード・ツールの使用によって、そのワイルドカードに関連する複数の範囲に拡張されます。

IP4範囲: 「開始」(開始)および「終了」(範囲の終了)にアドレスを入力することによって、範囲を定義します。指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。「終了」フィールドには、「開始」フィールドよりも値の大きいアドレスを指定する必要があります。認可中、Access Managerによって、クライアントのIPアドレスが「開始」(開始)および「終了」(範囲の終了)に指定したアドレスの範囲に含まれているかどうかが確認されます。複数の重複する範囲が指定され、クライアントのIPアドレスがその範囲の1つにでも含まれている場合、条件によってtrueと評価され、その条件に設定された条件に基づいてアクセスが許可(または拒否)されます。

複数の重複する範囲が指定され、クライアントのIPアドレスがそのいずれかの範囲に含まれている場合は、条件によってtrueと評価され、その条件に基づいてアクセスが許可(または拒否)されます。

注意:

「開始」のIPアドレスが「終了」のアドレスよりも大きい場合、条件はどのクライアントのIPアドレスにも一致しません。

図17-29は、開始および終了が指定されたサンプルIP4範囲を含むIP4範囲条件の表を示しています。無効な値を指定すると、そのことが通知され、値は保存できません。

図17-29 IP4範囲条件

「図17-29 IP4範囲条件」の説明

17.11.3.2 IP4範囲条件の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、IP4範囲タイプ条件をアプリケーション・ドメインに追加できます。別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。

注意:

ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。

前提条件

アプリケーション・ドメインが存在している必要があります。

関連項目:

「IP4範囲条件タイプについて」

IP4範囲タイプ条件を認可ポリシーに追加するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 「条件」タブをクリックし、「追加」(+)ボタンをクリックします。

3. 「名前」を入力し、「タイプ」リストから「IP4範囲」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。

4. 目的のIPアドレス範囲を追加します(表17-22を参照してください)。

- 「詳細」パネルで、「追加」(+)ボタンをクリックして「IP範囲の追加」ダイアログを表示します。

- 開始: 範囲の開始を入力します。

- 終了: 範囲の終了を入力します。

- 「追加」ボタンをクリックして、この範囲を「条件詳細」セクションに含めます。

- 別の範囲を追加する場合は、これらの手順を繰り返します。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 異なるIPアドレスを持つ異なるクライアントからログインして、保護されたリソースへのアクセスをテストすることによって、IP4範囲条件を検証します。

17.11.4 一時的条件の定義

この項の内容は次のとおりです。

- 一時的条件について

- 一時的条件の定義

17.11.4.1 一時的条件について

一時的条件タイプを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の条件のように、アイデンティティ条件およびIP4範囲条件と組み合せてこれを使用できます。

図17-30では何も選択されていませんが、デフォルトですべての曜日が有効です。

図17-30 一時的条件タイプの詳細ページ

「図17-30 一時的条件タイプの詳細ページ」の説明

グリニッジ標準時(GMT)の24時間制に基づくHH:MM:SS(時間、分、秒)形式で期間を指定する必要があります。深夜は00:00:00(開始)に指定します。24:59:59で1日が終了します。

表17-23 一時的条件の詳細

要素

説明

タイプ

結果タイプ: アクセスを許可または拒否します。

開始時間

注意: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。

この条件が開始する時間、分および秒を指定します。

注意: 時間はグリニッジ標準時(GMT)に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。

終了時間

この条件が終了する時間、分および秒を指定します。

日

このポリシーがアクティブな日を指定します。

デフォルト: すべての日(ただし、ここでは選択されていません。)

このページを閉じる前に、詳細を保存します。

関連項目:

「一時的条件の定義」

17.11.4.2 一時的条件の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、一時的タイプ条件をアプリケーション・ドメインに追加できます。

注意:

別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。

前提条件

アプリケーション・ドメインが存在している必要があります。

関連項目:

「一時的条件について」

一時的条件を認可ポリシーに追加するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 「条件」タブをクリックし、「追加」(+)ボタンをクリックします。

3. 「名前」を入力し、「タイプ」リストから「一時的」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。

4. 「詳細」パネル(表17-23)で、次の操作を実行します。「詳細」パネルを開くには、表内の条件名をクリックします。

- 開始時間を入力します。

- 終了時間を入力します。

- この条件を適用する曜日をクリックします(またはすべてを空白にして毎日を指定します)。

- 「保存」をクリックします。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 異なる回数ログインして、保護されたリソースへのアクセスを検証することによって、一時的条件を検証します。

17.11.5 属性条件の定義

この項の内容は次のとおりです。

- 属性条件について

- 属性タイプ条件の定義

17.11.5.1 属性条件について

属性タイプ条件では、アプリケーション・ドメイン内のすべてのリソース・タイプおよび認可ポリシーに関連する許可または拒否アクセスのリクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性が評価されます。属性タイプ条件を定義すると、アクセスは次の項目によってスコープ指定される、名前と値のペアのリストに基づきます。

- リクエスト・コンテキスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報。

- セッション: ユーザーがセッションを確立したときのユーザー・セッションの詳細(事前定義済のセッション属性または任意のセッション属性の参照)。

- ユーザー: ユーザー属性の情報(LDAP属性の参照)。この条件は、ユーザーの任意のLDAP属性の参照に対する条件を定義する場合のみ使用されます。ただし、userIDまたはgroupIDに基づく条件は、アイデンティティ条件を使用して定義されます。

アクセスが表17-24で説明されているいずれかの状況に基づく場合は、属性タイプ条件が必要です。

表17-24 属性タイプ条件を必要とするアクセス条件

アクセスが基づく内容

説明

セッション属性

ユーザーにリソースへのアクセスが認可されるのは、セッション属性「認証レベル」がxx、セッション属性s1がv1およびセッションの開始時間がxxxxである場合です。

参照: 表17-27 組込みセッションの属性名

リクエストされたリソース

ホスト名およびポート番号

参照: 表17-26 組込みリクエストの属性名

ユーザーの詳細

ユーザーにリソースへのアクセスが認可されるのは、そのリソースのEmpnoがxxxxである(department=salesなど)場合です。

参照: 表17-28 属性条件のデータ(条件の集約)

セッション属性に基づくトークン発行

リクエスタ・パートナーでは、要求に含まれる属性SessionActiveTimeが15000である場合、リライイング・パーティにトークンを発行できます。

トークン発行ポリシーの要求ベースの条件は、セッション・データを使用して作成されたアサーションに基づいて定義します。

属性タイプ条件を定義する管理者は、組込み属性および既知の属性のフィールドにデータを入力します。属性名は、テキスト・フィールドに入力するか、値のリストから選択できます。実行する条件は、その条件にANDまたはOR接続詞を使用して構築されます。図17-31は、属性条件のページを示しています。

図17-31 属性条件のページ

図17-32は、「属性の追加」ダイアログ・ボックスを示しています。各属性条件は、表17-25で説明されているフィールドによって定義されます。

関連項目:

「属性条件の定義」

図17-32 「属性の追加」ダイアログ

表17-25 属性条件の要素

条件

説明

ネームスペース

サポートされるネームスペース:

- 組込みリクエスト

- 組込みセッション

- セッション(ユーザー・セッション)

- ユーザー(ユーザー属性)

名前

属性名。次の内容に従って追加できます。

- 「ネームスペース」が「リクエスト」(表17-26)または「セッション」(表17-27)の場合、リストから選択します。

- 「ネームスペース」が「ユーザー」の場合、手動でテキスト・フィールドに入力されます。

演算子

許可される演算子:

- STARTS WITH

- EQUALS

- CONTAINS

- ENDS WITH

値

特殊なワイルドカード文字を含まないリテラル値。

組込みリクエスト

表17-26は、組込みリクエストの組込み属性名のリストを示しています。

表17-26 組込みリクエストの属性名

属性名

説明

agent_id

リクエストしているエージェントの名前。

client_ip

ユーザー・ブラウザのIPアドレス。

Policy_appdomain

リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前。

Policy_res

リクエストに一致するリソース・ホストIDおよびURLパターン。

policy_name

リクエストに一致する特定のポリシーの名前。

res_host

リクエストしたリソースのホスト名。

res_port

リクエストしたリソースのポート番号。

res_type

リクエストしたリソースのタイプ。

res_url

リクエストしたリソースURL。

組込みセッション

表17-27は、セッション・ベースの属性タイプ条件の属性名のリストを示しています。

表17-27 組込みセッションの属性名

属性名

説明

認証レベル

セッションの現在の認証レベル。

認証スキーム

現在の認証レベルを実現するために実行される認証スキームの名前。

セッション・カウント

セッションにバインドされたユーザーのセッション数。

セッション作成時間

セッションの作成時間。

セッション有効期限時間

セッションの有効期間。

例: 属性条件のデータ(条件の集約)

表17-28は、許容できる各ネームスペースのサンプル条件データを示しています。

表17-28 属性条件のデータ(条件の集約)

ネームスペース

名前

演算子

値

組込みリクエスト

Res_host

Equals

7777

組込みセッション

Authn_level

Equals

2

セッション

Sessionattr1

Contains

Foo

ユーザー

department

Equals

sales

17.11.5.2 属性タイプ条件の定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、属性タイプ条件をアプリケーション・ドメインに追加できます。

注意:

別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。

前提条件

アプリケーション・ドメインが存在している必要があります。

関連項目:

「属性条件について」

属性タイプ条件を認可ポリシーに追加するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 「条件」タブをクリックし、「追加」(+)ボタンをクリックします。

3. 「名前」を入力し、「タイプ」リストから「属性」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。

4. 属性条件の詳細の追加: 条件の名前をクリックして詳細パネルを開き、次の操作を実行します。

- 一致: 「すべて」または「任意」をクリックします。

- ネームスペース: リストから選択するか、手動で入力します(表17-25)。

- 名前: リストから選択するか、手動で入力します(表17-26または表17-27)。

- 演算子: リストから選択します(表17-25)。

- 値: 手動で入力します(表17-28)。

- 「保存」をクリックします。

- 必要に応じて繰り返します。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 異なるシナリオでログインすることによって、属性条件を検証します。

17.11.6 認可ポリシー条件の表示、編集または削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、アイデンティティ・タイプ条件をアプリケーション・ドメインに追加できます。

前提条件

アプリケーション・ドメインおよび認可ポリシーが存在していること。

関連項目:

「認可ポリシー・ルールおよび条件の概要」

認可ポリシー条件を表示、編集または削除するには

1. 「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。

2. 「条件」タブをクリックします。

3. 「条件詳細」の編集: 目的の条件をクリックして、「編集」ボタンをクリックすると「詳細」パネルが表示されます。条件タイプによっては、「説明」のみが編集可能になります。

- 「アイデンティティ条件の定義」

- 「IP4範囲条件の定義」

- 「一時的条件の定義」

- 「属性条件の定義」

- True: 名前をクリックし、「編集」ボタンをクリックします。編集できるのは「説明」のみです。

4. 条件の削除: 削除する条件をクリックし、「条件」タブの「削除」ボタンをクリックします。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. 終了する場合はページを閉じます。

7. リソースにアクセスして結果を評価することによって、条件を検証します。

17.12 認可ポリシー・ルールの定義

アクセスの許可ルール、アクセスの拒否ルールまたはこの両方が指定されていて、ユーザーがこれらの条件に該当しない場合、ユーザーはルールの対象外とされ、リクエストしたリソースへのアクセスをデフォルトで拒否されます。

ルールでは、リソースへのアクセスをユーザーに許可するか否かを指定するために次のことができます。

- ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。

- ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。

- ルールが適用される時間帯を設定します。

この項の内容は次のとおりです。

- 認可ポリシーのルールの定義について

- 式および式ベースのポリシー評価について

- 認可ポリシーのルールの定義

17.12.1 認可ポリシーのルールの定義について

ルールはAccess Manager 11gポリシー・モデルの新しい構造です。ルールによって、条件の評価結果を組み合せる方法が指定されます。また、各ルールには、全体的なポリシーの結果を決定するルール効果(ALLOWまたはDENY)が含まれます。

認可ルールでは、ポリシー、条件およびルールの評価中に実行するアクションと、その結果に基づく必要な操作が定義されます。結果は次の3つのいずれかになります。

- True (アクセスの許可): アクセスの許可条件を満たす場合、ユーザーはルールのアクセスの許可部分の対象になります。

- False (アクセスの拒否): アクセスの拒否条件を満たす場合、ユーザーはルールのアクセスの拒否部分の対象になります。

- 未確定: アクセスの許可条件もアクセスの拒否条件も満たさない場合、ルールはそのユーザーにとって対象外と呼ばれます。これは、ユーザーがルールの対象外であることと同じ意味です。ルールを評価した結果、ユーザーが対象外となった場合、ユーザーはそのルールに基づいてリソースへのアクセスを拒否されます。

場合によっては、単一の認可ルールが、アプリケーション・ドメインまたはポリシーのリソースを保護するための唯一の要件となります。ルールを構成して、そのルールによって保護されるリソースへのアクセスが許可されるユーザー、アクセスが拒否されるユーザー、およびこれらの制御が適用される条件(いつどのコンピュータから適用されるかなど)を識別できます。認可ルールに含まれるアクセスの許可条件およびアクセスの拒否条件で、すべてのユーザーを対象にする必要はありません。ルールによって保護されるリソースへのアクセスをリクエストしたが、いずれの条件も満たしていないユーザーは、そのリソースへのアクセスを拒否されます。

または、複数の認可条件からルールを構成してリソースを保護することが必要な場合もあります。異なるユーザーに対して複雑な条件を設けることもできます。たとえば、様々な認可条件を含むルールを定義し、それらの条件の1つ以上をユーザーが満たしているときにのみ、保護されているリソースへのアクセスを許可(または拒否)できます。たとえば、ユーザーがリソースへのアクセス権を付与されるには、2つの条件(あるグループに属し、かつ特定のIPアドレスが割り当てられているコンピュータを使用している、など)を満たす必要があると指定することもできます。

Oracle Access Managementコンソールを使用すると、認可ルールの式を簡単に作成できます。条件はルールの外部で宣言され、ルールの内部で参照されます。評価結果は、簡易モードと式モードのいずれかで結合されます。図17-33は、認可ポリシーの「ルール」タブを示しています。

図17-33 認可ポリシーの「ルール」タブ: 簡易モード

表17-29は、簡易モードの評価の「ルール」タブに表示される要素およびコントロールを示しています。

表17-29 認可ポリシーの「ルール」の要素

要素

説明

ルール・モード

条件およびルールの評価に使用される次の方法。

- 簡易: 単純なアルゴリズムを使用して組み合される条件名のリストを受け入れます。
許可条件は論理ANDを使用して組み合されます。アクセスを得るには、すべての許可条件を満たす必要があります。

拒否条件は論理ORを使用して組み合されます。いずれかの拒否条件がtrueの場合、アクセスは拒否されます。拒否条件は常に許可条件よりも優先されます。

- 式: 条件名、特殊文字(、)、|、&および!を使用して条件を組み合せるユーザー指定のブール式を受け入れます。条件を組み合せて複雑なポリシーを作成します。
関連項目: 「式および式ベースのポリシー評価について」

- 許可ルールと拒否ルールのどちらにも含まれない1つ以上の条件を含むポリシーは、有効なポリシーと見なされます。

ルールの許可

ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。

ルールの拒否

ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。

一致

「選択した条件」リストのすべての条件に一致させるか、「選択した条件」リストのいずれかの条件に一致させるかを選択する基準。

使用可能な条件

この認可ポリシー用に定義されたすべての条件のリスト。

選択した条件

ポリシーの評価プロセス用に構築する特定の条件のリスト。「使用可能な条件」リストからこのリストに項目を移動することによって構築します。

矢印型のコントロールを使用すると、条件を「選択した条件」リストに追加できます(またはその逆に、選択されている条件を削除できます)。

17.12.2 式および式ベースのポリシー評価について

ユーザーがリソースへのアクセスをリクエストし、そのリソースが認可条件およびルールで保護されている場合、そのユーザーに関する情報がルールのとおりであるかどうかを確認します。条件にその他の情報(条件が適用される時間帯や日時など)が指定されている場合は、その情報も確認されます。このプロセスは、ルールの評価と呼ばれます。

認可条件式は、単一のルール、またはより複雑な条件を表現するために組み合せた複数ルールのグループから構成されます。たとえば、ユーザーがリソースへのアクセス権を付与されるために2つのルールのアクセスの許可条件を満たすことを要求する式を作成できます。これらの式を作成するには、Oracle Access Managementコンソールを使用します。式には次の要素が含まれます。

- 認可条件。認可ポリシー内で定義されている、使用可能な条件から選択します。

- ルールを組み合せるための演算子。ルールの組合せにより、必要な認可保護を提供します(表17-31)。

複数の条件を含む式に対しては、ユーザーは式のどの条件の対象にもならない場合や、1つの条件の対象になる場合、または複数のルールの条件の対象になる場合があります。ユーザーにリソースへのアクセスが許可されるか拒否されるかは、常に式の評価結果(1つの条件ではなく、すべての条件とその組合せ)によって決まります。

認可条件式の最終結果の概要: Access Managerでは、最終的な結果を得られるまで、式に含まれる各ルールを評価します。認可条件式の評価では、最終結果として、アクセスの許可、アクセスの拒否または未確定のいずれかが戻されます。

図17-34は、式をルール・モードとして使用したときの「ルール」タブを示しています。

図17-34 「ルール」タブ: ルール・モードの式

表17-30は、式モードの「ルール」タブに表示される要素を示しています。

表17-30 式モードの「ルール」タブ

要素

説明

ルール・モード

条件およびルールの評価に使用される次の方法。

- 式: 条件名、特殊文字(、)、|、&および!を使用して条件を組み合せるユーザー指定のブール式を受け入れます。条件を組み合せて複雑なポリシーを作成します。

- 許可ルールと拒否ルールのどちらにも含まれない1つ以上の条件を含むポリシーは、有効なポリシーと見なされます。

関連項目: 表17-31 認可ルールの式の演算子

ルールの許可

ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。

ルールの拒否

ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。

条件

この認可ポリシー用に定義されたすべての条件のリストが提供されます。

挿入条件

選択した条件が式ウィンドウに追加されます。

検証

自動的に式の妥当性がテストされ、結果がレポートされます。

表17-31は、認可条件式の作成時に使用できる演算子を示しています。

表17-31 認可ルールの式の演算子

演算子

説明

( )

デフォルトでは、AND演算子で2つのルールを組み合せたものが、AND論理積条件になります。OR演算子の両側にあるルールは、少なくとも一方が満たされれば条件は成立します。カッコを使用してルールをグループ化しない場合は、AND演算子がOR演算子より優先されます。

カッコを使用すると、式のルールをグループ化するデフォルトの方法を上書きできます。評価は引き続き左から右に実行されますが、ルールはカッコを使用して作成した組合せおよびグループ内で編成されます。

&

AND演算子。認可ルールを組み合せて論理積条件を作成するのに使用します。AND演算子を使用すると、任意の数のルールを組み合せ、ユーザーが認可要件を満たすために従う必要がある一連の条件を実装できます。ただし、AND句の最終的な結果を得るには、ユーザーは、論理積条件の全ルールで同様の条件(アクセスの許可またはアクセスの拒否)を満たす必要があります。

認可条件式には、ANDで組み合されたルールの組合せまたはグループを複数個含めることができます。たとえば、複数のAND句を含めて、それぞれの句をOR演算子で接続できます。

|

AND演算子。認可条件式には、複数の代替可能な認可条件が含まれる複合ルールを含めることができます。論理和条件を構成する認可ルールは、OR演算子を使用して組み合せます。OR論理和条件で指定した各認可ルールは、独立したルールになります。AND演算子を使用する論理積条件とは異なり、ユーザーは、OR演算子で接続された認可ルールのうち、ただ1つのルールの条件に対してのみ対象になる必要があります。

認可条件式には、保護するリソースに対して認可ポリシーを表すのに必要な数の認可ルールをOR演算子で接続して含めることができます。OR演算子は、アクセスの拒否条件のみを持つ認可ルール同士、アクセスの許可条件のみを持つ認可ルール同士、またはアクセスの拒否条件とアクセスの許可条件を組み合せて指定した認可ルール同士を接続するのに使用できます。ORを使用して1つのルールを1つのルールに接続できるのみでなく、ANDで組み合されたルールを含む句に1つのルールを接続することもできます。

17.12.2.1 認可ルールの式の評価

認可ルールの評価結果(式に複数の認可ルールが含まれている場合は、それらの認可ルールとも組み合せた評価結果)により、リクエストしたリソースへのアクセス権がユーザーに付与されるかどうかが判定されます。ルールの評価は、次のように実行されます。

- 式に指定された各認可ルールは、左から右に評価されます。結果は以前に評価されたルールと順次組み合されます。

- 評価結果が、それ以上他のルールを評価することなく、全体的なポリシーの結果を判断できるほど良好である場合、評価は終了し、全体的な結果が返されます。

- 各評価結果は、True、False、未確定のいずれかになります。
認可成功: この場合、ユーザーはリクエストしたリソースにアクセスできます。この結果は、式のアクセスの許可条件に関連付けられています。

認可失敗: この場合、ユーザーはリクエストしたリソースにアクセスできません。この結果は、式のアクセスの拒否条件に関連付けられています。

認可未確定: この場合、式のルールにより矛盾する結果がいくつか生成され、ユーザーはリソースへのアクセスを拒否されます。アイデンティティ、IP4アドレスまたはタイミング条件の一致が失敗した場合、式の評価は終了し、全体的な評価の結果は未確定と判断されます。ただし、式に含まれる他のルールによっては、この結果が全体的なポリシーの評価に影響を与えない場合があります。

たとえば、次のような式があります。

(Rule1 AND Rule 2) OR (Rule 3 AND Rule 4)

生成される結果は次のとおりです。

- Rule1 - INCONCLUSIVE

- Rule2 - FALSE

- Rule3 - TRUE

- Rule4 - TRUE

- 全体: TRUE (許可)

次のサンプル式では、(タイプ順)アイデンティティ、一時的、IP4範囲および属性条件を使用します。

(IsEMEAemployee & IsEMEAWorkingHours &    !(ConnectedOverVPN |NotReadDisclaimer))

スペース、タブまたは特殊文字を含む条件名(式を定義するときに正しくエスケープされている場合)は、正しく処理されます。

17.12.3 認可ポリシーのルールの定義

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、ルールを認可ポリシーに追加できます。

前提条件

認可ポリシー条件の定義

関連項目:

「認可ポリシーのルールの定義について」

認可ポリシー・ルールを定義するには

1. 「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。

2. 「ルール」タブをクリックします。

3. 式:

1. 「ルール・モード」で「式」をクリックします。

2. 「ルールの許可」の「式」フィールドでは、演算子を入力し(表17-31)、条件を選択および挿入する(表17-30)ことで、式を作成できます。

3. 「検証」ボタンをクリックして式を確認します。

4. 「ルールの拒否」で手順bおよびcを繰り返します。

5. 「適用」をクリックします。

4. 簡易ルール・モード:

1. 「ルール・モード」で「簡易」をクリックします。

2. ルールの許可:
一致させる次のいずれかの内容をクリックします。

選択したすべての条件
選択したいずれかの条件

「ルールの許可」または「ルールの拒否」の矢印を使用して、「使用可能な条件」列から「選択した条件」列に目的の条件を移動します。

「適用」をクリックします。

3. 「ルールの拒否」で手順bを繰り返します。

5. 「適用」をクリックして、確認ウィンドウを閉じます。

6. リソースにアクセスして結果を評価することによって、ルールを検証します。

17.13 アプリケーション・ドメインの認証および認可の検証

ここでの手順は、エージェント登録と認証および認可ポリシーを操作できることを確認するいくつかの方法を示しています。手順は、OAMエージェントおよびOSSOエージェント(mod_osso)でほとんど同じです。ただし、OSSOエージェントは認証ポリシーのみ使用し、認可ポリシーは使用しません。

前提条件

- アクセス権を付与されるユーザーおよびグループは、Oracle Access Managementに登録されるプライマリLDAPユーザー・アイデンティティ・ストアに存在する必要があります。

- Access Managerで操作するためにエージェントを登録する必要があります。登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。

- アプリケーション・ドメイン、認証ポリシーおよび認可ポリシーを構成する必要があります。

- ログアウトは、第19章「11g Webgateが関与するセッションの集中ログアウトの構成」の説明に従って構成されている必要があります。

認証およびアクセスを確認するには、次の手順を実行します。

1. Webブラウザを使用すると、登録されたエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。

http://exampleWebserverHost.example.com:8100/resource1.html

2. ログイン・ページにリダイレクトしていることを確認します。

3. サインイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「サインイン」をクリックします。

4. リソースにリダイレクトしていることを確認し、先に進みます。

- 成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。

- 失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。

- 失敗した認証: 有効な資格証明を使用して再度サインインします。

- URL...のアクセスの拒否: このリソースのアクセスにこのユーザーIDが認可されていません。

- 使用不能なリソース: リソースが使用できることを確認します。

- 不正なリダイレクトURL: Oracle Access ManagementコンソールのリダイレクトURLを確認します。

関連項目:

第18章「アクセス・テスターを使用した接続性とポリシーの検証」

17.14 ポリシーおよびアプリケーション・ドメインのリモート管理の理解

いくつかのリモート管理モードで、管理者は既存のエージェント登録を更新、検証または削除できます。この項の内容は次のとおりです。

- ポリシーのリモート管理について

- ポリシー作成のリクエスト・テンプレートについて

- ポリシー更新のリクエスト・テンプレートについて

- リモート・ポリシー管理およびテンプレートについて

17.14.1 ポリシーのリモート管理について

Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。

注意:

アプリケーション・ドメインの削除は手動のタスクであり、Oracle Access Managementコンソールを使用して実行する必要があります。

表17-32に、リモート・アプリケーション・ドメイン管理のモードを示します。ここでもコマンドのパラメータには、モード、OAM_REG_HOMEに対する相対パスを使用する入力*Request.xmlファイル、入力ファイルの優先ロケーションが含まれます。

./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value

表17-32 リモート・ポリシー管理のモード、テンプレートおよびフラグ

モードおよびテンプレート

説明

policyCreate

$OAM_REG_HOME/input/

CreatePolicyRequest.xml

管理者が、エージェントを登録せずにホスト識別子とアプリケーション・ドメインを作成できます。

./bin/oamreg.sh policyCreate input/myCreatePolicyRequest.xml

関連項目: 「ポリシー作成のリクエスト・テンプレートについて」

policyUpdate

$OAM_REG_HOME/input/

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

17.14.2 ポリシー作成のリクエスト・テンプレートについて

CreatePolicyRequest.xmlファイルをリモートpolicyCreateモードで使用すると、管理者はエージェント登録を作成または更新することなく、ホスト識別子とアプリケーション・ドメインを作成できます。

- 複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を作成します。

- アプリケーション・ドメインを作成します。

- 複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。

- カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを作成します。

前述のとおり、CreatePolicyRequest.xmlファイルと、拡張された(完全な)エージェント登録テンプレートには、同じパラメータが多数存在します。CreatePolicyRequest.xmlファイルには、認証および認可のポリシーおよびリソースの要素があります(<agentName>要素はない)。

CreatePolicyRequest.xmlファイルのパラメータの一部は新規であり、エージェント登録XMLファイル全体には含まれず、元のエージェント登録ファイルの特定の要素を使用して作成または更新されます。ただし、同じ要素もあります。CreatePolicyRequest.xml固有の主な違いは、次のとおりです。

- 認証および認可のポリシーおよびリソースの要素があります。

- <agentName>要素または関連する要素はありません。

関連項目:

「リモート・ポリシー管理およびテンプレートについて」

17.14.3 ポリシー更新のリクエスト・テンプレートについて

UpdatePolicyRequest.xmlとCreatePolicyRequest.xmlの内容は、ほぼ同じです。どちらも同じ要素を提供しますが、例外は<protectedAuthnScheme>要素です。

関連項目:

「リモート・ポリシー管理およびテンプレートについて」

UpdatePolicyRequest.xmlを使用して、管理者は次の操作が可能です。

- 複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を更新します。

- アプリケーション・ドメインを更新します。

- 問合せ文字列の有無にかかわらず、複数の保護リソース、パブリック・リソース、除外リソースを追加します。

- カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを更新します。

- 次を含む、カスタマイズしたポリシーを作成します。

- ポリシーの表示名

- ポリシーの説明

- 認証スキーム(認証ポリシーのみ)およびポリシーに関連付けられるリソースのサブセット

17.14.4 リモート・ポリシー管理およびテンプレートについて

この項では、CreatePolicyRequest.xmlおよびUpdatePolicyRequest.xmlファイルにある、アプリケーション・ドメイン管理に対する一意のリモート管理要素について説明します。これらの要素の詳細は、表17-33を参照してください。

関連項目:

リモート登録とリモート管理に共通する要素の説明は、表13-8「リモート登録リクエストの共通要素」を参照してください。

表17-33 リモート管理テンプレートの要素

要素

説明

例

<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>

17.15 ポリシーおよびアプリケーション・ドメインのリモート管理

次の手順は、管理者が、エージェントの登録を修正せずに、リモートでポリシーを作成するか、または既存のポリシーを更新する方法について説明します。

前提条件

「ポリシーのリモート管理について」を確認してください。

エージェントを使用せずにリモートでポリシーまたはアプリケーション・ドメインを管理するには

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. 適切なリクエスト・テンプレートをコピーし、独自のポリシー管理リクエスト(必要に応じてアプリケーション・ドメインを修正)を開発します。

- ポリシー作成リクエスト・ファイル

- ポリシー更新リクエスト・ファイル

3. エージェント・ホストで、適切なモードで独自の*Request*.xml入力ファイルを指定して、次のコマンドを実行します。次に例を示します。
policyCreateモード:

./bin/oamreg.sh policyCreate input/myCreatePolicyRequest.xml

policyUpdateモード:

./bin/oamreg.sh policyUpdate input/myUpdatePolicyRequest.xml

4. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

5. 画面に表示されるメッセージを読んで成功したことを確認し、Oracle Access Managementコンソールを使用してドメインおよびポリシーを管理します。
agentUpdateプロセスは正常に完了しました。

固有の構成ファイルの場所: ...が出力フォルダ...に作成されました。

出力フォルダは、RREG.tar.gzが解凍されている場所(.../rreg/output/AgentName/)にあります。

18 アクセス・テスターを使用した接続性とポリシーの検証

Oracleでは移植可能なスタンドアロンのJavaアプリケーションであるアクセス・テスターが提供されており、このテスターはOAMサーバーに接続されている登録済エージェントをシミュレートします。スクリプトによる実行では、コマンドライン処理が可能です。スクリプトを記録および再生して、様々な機能の出力を取得できます。暗号化された接続および複数のサーバー接続がサポートされています。

IT専門家や管理者はアクセス・テスターを使用して、リクエストやレスポンス・セマンティクス、アクセス・ポリシー設計の高速テストを行ったり、サーバー接続のエージェントの問題をトラブルシューティングできます。

この章では、アクセス・テスターとその使用方法を紹介します。

- 前提条件

- Access Manager 11gのアクセス・テスターの概要

- アクセス・テスターのインストールと起動

- アクセス・テスター・コンソールとナビゲーションの概要

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

18.1 前提条件

この章に示すタスクを実行するには、以下の前提条件を満たす必要があります。

- Oracle Access ManagementコンソールおよびOAMサーバーが実行中であることを確認します。

- 第17章の説明に従い、1つまたは複数のリソースのアプリケーション・ドメインとポリシーを確認します。

18.2 Access Manager 11gのアクセス・テスターの概要

アクセス・テスターは移植可能なスタンドアロンのJavaアプリケーションで、Access Manager 11gに同梱されています。アクセス・テスターは、個々のIT専門家や管理者とOAMサーバー間の機能的なインタフェースを提供します。

IT専門家はアクセス・テスターを使用して接続を検証し、物理的デプロイメントのトラブルシュートを行なうことができます。アプリケーション管理者は、アクセス・テスターを使用してポリシーを迅速に検証できます。この章で言う「管理者」とは、アクセス・テスターを使用する人物を表します。

アクセス・テスターは、OAMサーバーへのネットワーク接続を持つ任意のコンピュータから使用できます。また、グラフィカル・ユーザー・インタフェース(この章ではテスター・コンソールと呼びます)とコマンドライン・インタフェースの両方を使用できます。コマンドライン・モードを使用すれば、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。

実際のエージェントのように見せることによって、アクセス・テスターはポリシー構成設計やトラブルシューティングを助け、場合によってはOAMサーバーの応答性に関するトラブルシューティングに使用することもできます。アクセス・テスターを使用する時は実際のエンド・ユーザーのように振る舞う必要がありますが、アクセス・テスターが実際にエンド・ユーザーと通信することはありません。

アクセス・テスターを使用するには、Access Managerによって保護されるアプリケーションまたはリソースの認証ポリシーと認可ポリシーを理解し、管理する必要があります。

アクセス・テスターを使用すれば次のことが可能です。

- エミュレート用のOAMサーバーに送信するリクエストの構成。エミュレート用OAMサーバーは、実際のエージェントが本番環境のOAMサーバーに送る内容をエミュレートします。

- リクエストをOAMサーバーに送信し、実際のエージェントが受信する応答と同じ応答を受信。アクセス・テスターはOAMアクセス・プロトコル(OAP)APIを使用し、OAMチャネルを介して、OAMサーバーの一部として実行中のOAMプロキシにリクエストを送信します。OAMサーバーはこのリクエストを処理してレスポンスを返します。

- サーバー・レスポンスの処理と表示。

- 実際のエージェントによるレスポンスの取り扱いと同様に処理を続行。たとえば、Webgateがリソースは証明書認証スキームによって保護されていると判断した場合、Webgateはhttp SSL接続からエンド・ユーザーの証明書を取得する必要があります。
証明書認証スキームの場合、アクセス・テスターにはエンド・ユーザーの資格証明として使われる証明書を参照させなければなりません。

先に挙げた機能を実行してエージェントをシミュレートすることに加えて、アクセス・テスターによって以下の操作を行なうことができます。

- 予定しているポリシー変更のパフォーマンス特性の確認

- 認証リクエストと認可リクエストの待機時間の追跡

- OAMサーバーのストレス・テストを実施してユーザー負荷に関連するローパフォーマンス・ウォーターマークまたはハイパフォーマンス・ウォーターマークを確立し、バックエンド・ハードウェアのサイズを決定

- コマンドライン・モードのみで複数の同時テスト(マルチスレッド・モード)を実行することにより、ポリシー・サーバーのストレス・テストを実施します。

- 継続的にパォーマンス・メトリックの確立と測定を行い、求められていた成果を検証

基本的な動作中、アクセス・テスターはサーバー・レスポンスに関して何の判定も行なわず、そのレスポンスの可否判定も行ないません(たとえばリソースXが保護されているかどうか、あるいはユーザーYがリソースXへのアクセスを認可されているかどうかなど)。アクセス・テスターを操作するときは、特定のレスポンスが適切なものかどうかを決定するポリシー構成に注意する必要があります。

アクセス・テスターは、複数の個別リクエストをグループ化してテスト・スクリプトにまとめ、それをOAMサーバーに送って処理することを可能にする拡張機能を備えています。このようなテスト実行の出力はアクセス・テスターで取得し、「確認済みの」応答を含む同様ドキュメントとの比較に使用することができます。このように、アクセス・テスターは、ポリシー構成の誤変更検出用の自動化テストに使用することができます。

また、アクセス・テスターには、ポリシー・サーバーのストレス・テストを実施する目的でマルチスレッド機能が提供されています。マルチスレッドによる方法では、ポリシー・サーバーに接続する仮想テスト・クライアントの数、および各仮想クライアントでテスト・スクリプトを実行する反復回数を特定します。これにより、ポリシー・サーバーのストレス・テストを実施できます。

詳細については、この章の以下の説明を参照してください。

- OAMエージェントとサーバーの相互運用性について

- アクセス・テスターのセキュリティと処理について

- アクセス・テスター・モードと管理者の対話操作について

18.2.1 OAMエージェントおよびサーバーの相互運用性について

OAMアーキテクチャにおける2つの主要なアクター・タイプは、ポリシー・サーバー(OAMサーバー)とOAMポリシー強制エージェント(Webgateまたはアクセス・クライアント)です。セキュリティ分野においてはエージェントがポリシー強制点(PEP)を表し、OAMサーバーがポリシー決定点(PDP)を表します。

- エージェントはhttpベース・アプリケーションなどのリソースのセキュリティを確保するゲートキーパーの役割を果たし、そのリソースにアクセスしようとするユーザーとのすべての対話操作を管理します。これは、ポリシー・サーバー(OAMサーバー)に保持されているアクセス制御ポリシーに従って実現されます。

- OAMサーバーの役割は、エージェントに対してポリシー・サービス、アイデンティティ・サービス、およびセッション・サービスを提供してアプリケーション・リソースに対する適切なセキュリティを確保し、ユーザーの認証と認可を行なって、ユーザーセッションを管理することです。

この中核的なOAM製品アーキテクチャは、エージェントとOAMサーバー間の相互動作を支配する以下のようなやり取りを中心に展開します。相互運用性と重要な決定点を明らかにするために、ユーザーがリソースに関するリクエストを行う際のOAMエージェントとOAMサーバー間の標準的な相互動作を図18-1に示します。

図18-1 OAMエージェント(PEP)とOAMサーバー(PDP)の相互運用性

「図18-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. エージェントは、ポリシー応答に基づいてアクセスを認可または拒否します。

18.2.2 アクセス・テスターのセキュリティおよび処理について

この項では、セキュアな通信、接続、保存、入力、ロギングおよび分析に関する情報を説明します。

セキュアな通信: アクセス・テスターは、OAMサーバーとの通信について、オープン接続モード、簡易接続モードまたは証明書接続モードに対応しています。

- オープン・モード: 物理的接続に対するセキュリティがありません。

- 簡易モード: 組込み証明書を使用して物理的接続を暗号化します。簡易モードでは、OAMサーバー用に構成されたグローバル・パス・フレーズの入力を求められます。

- 証明書モード: フィールド提供の証明書を使用して物理的接続を暗号化します。アクセス・テスターの証明書モードでは、次を実行する必要があります。

- 証明書モードの通信用にエージェント(既存または新規)を構成します。

- エミュレートするエージェントの証明書を取得します。

アクセス・テスターの証明書モードでは、提供されたPEM(BASE64-コード化ASCII)証明書(aaa_trust.pem、aaa_key.pem、aaa_cert.pem)からimportcertツールを使用して作成した2つのJKSキーストアが必要です。

- トラスト・ストア(ルートCA証明書を持つJKSキーストアが含まれるファイル)が必要です。

- キーストア(エージェントの秘密鍵および証明書を持つJKSキーストアが含まれるファイル)が必要です。

- エージェント証明書を持つキーストアの暗号化には、キーストア・パスワードを使用します。

関連項目:

- 付録C「安全な通信」: 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は出力スクリプトとともに作成されます。詳細については「実行ログについて」を参照してください。

その他の詳細については「アクセス・テスター・モードと管理者の対話操作について」を参照してください。

18.2.3 アクセス・テスターのモードおよび管理者の操作について

この項では、モード、対話操作およびアクセス・テスターの起動と実行に必要なjarファイルについて説明します。

コンソール: アクセス・テスターはユーザーとの対話操作のために1つのウィンドウを表示します。すべてのアクセス・テスター操作はメイン・ウィンドウから行なうことができ、このウィンドウは、ユーザーがテスト・ケースの特定の詳細を送信したりレスポンスを表示したりすることのできるセントラル・ダッシュボードとしての役割を果たします。

コマンドラインおよびスクリプト: アクセス・テスターでコマンドラインを使用し、生産性を最大限まで向上させてコストとリソースを最小限に抑える自動実行を実現するために、対話的な実行やバッチ実行が可能なテスト・スクリプトを作成できます。

起動および実行時JARファイル: アクセス・テスターでは、アプリケーションの起動に使用するメインjarのoamtest.jarと同じディレクトリにnap-api.jarを置く必要があります。

対話操作: アクセス・テスター実行のために選択したモードにかかわらず、ユーザーとアクセス・テスターの主な対話操作には次の操作が含まれます。

- リクエストの発行と結果の表示
リソース保護、ポリシー構成、ユーザー認証、およびユーザー認可を検証するために、アクセス・テスターを使用してOAMサーバーへのリクエストを発行します。必要に応じ、テスト・ケースの結果はただちに分析することもできますし、長期的な分析のためにデータを保存しておくこともできます。

- テスト・スクリプトの管理
テスト・スクリプトはテスト実行によって作成されたデータを取得することによって作成でき、これはスタンドアロン・ドキュメントとして使用できます。テスト・スクリプトは手動分析と自動分析の両方で実行できます。アクセス・テスターを使用すれば、事後分析を可能にするあらゆる統計データを収集して、それぞれの自動実行後に何らかの自動分析を行なうことができます

- OAMサーバー接続の管理
サーバー接続情報を含むアプリケーション設定を管理することができます。

コンソール・モード操作とコマンドライン・モード操作の両方おける情報の流れを図18-2に示します。詳細は、図の後に説明します。より高度な操作としては、テスト・スクリプトの作成と実行があります。

注意:

コマンドライン・モードを使用すると、シングル・クライアントまたはマルチクライアント・モード環境のテスト・スクリプト実行を完全に自動化できます。アクセス・テスターは、読取り専用モードで使用可能な「確認済(Known Good)」の入力テスト・スクリプトを変更せずにテスト実行を構成する制御メカニズムを公開しています。

図18-2 アクセス・テスターのユーザー操作

「図18-2 アクセス・テスターのユーザー操作」の説明

テスター・コンソール・モード操作とコマンドライン・モード操作の両方における情報の処理フローを表18-1に示します。

表18-1 ユーザー操作: テスター・コンソール・モードとコマンドライン・モードの操作

テスター・コンソール・モード

コマンドライン・モード

ユーザーはコマンド・ラインからアクセス・テスターを開始します。

コマンドライン・モードでは、ユーザーまたはシェル・スクリプトがアクセス・テスターを開始します。

セキュアな通信用の証明書モード: キーストアは、以前に保存された構成情報が格納されているOamTestConfiguration.xmlファイルで指定されます。

ユーザーが前に保存されたOamTestConfiguration.xmlファイルを開いてアプリケーション・フィールドへの入力を行い、接続フィールドを含めてデータ入力をできるだけ少なくします。あるいは、テスター・コンソールを使用して手動でデータを入力することもできます。

アクセス・テスターは、入力スクリプトに基づいてテスト・ケースの処理を開始します。

ユーザーが「接続」ボタンをクリックしてOAMサーバーとの接続を開きます。

入力スクリプトの詳細に基づいてアクセス・テスターがOAMサーバーとの接続を開きます。

リソース保護: ユーザーが、リソース保護の検証、ユーザー資格証明の認証、およびユーザー・アクセスの認可のためのステップを順番に実行します。

リソース保護: 入力スクリプトに基づいてアクセス・テスターがテスト・ケースの処理を開始します。

アクセス・テスターはテスト完了時に以下のものを作成します。

- 結果のスクリプト

- 一致しない応答に関する情報を含む実行統計のファイル

- 処理フローの詳細を示すログ・ファイル

アクセス・テスターはスクリプト完了時に以下のものを作成します。

- 結果のスクリプト

- 一致しないレスポンスに関する情報を含む実行統計のファイル

- 処理フローの詳細を示すログ・ファイル

必要に応じてユーザーがステップを繰り返して検証を終了させます。

必要に応じてユーザーがステップを繰り返して検証を終了させます。

証明書モードでは、必要なキーストアを特定するように要求されます。

証明書モードでは、キーストアは、以前に保存された構成情報が格納されているXMLファイルで指定されます。

以下ではアクセステスターの使用に伴うタスクの概要と、詳細が記載されたこの章のトピックを示します。

タスクの概要: Access Managerの接続とポリシーのテスト

1. 以下のトピックを確認します。

- アクセス・テスターのインストールと起動

- アクセス・テスター・コンソールとナビゲーションの概要

2. 「アクセス・テスター・コンソールによる接続性とポリシーのテスト」の説明に従ってアクセス・テスター・コンソールを使用し、テストを実行してデータを取り込みます。

3. 「テスト・ケースおよびスクリプトの作成と管理」へ進みます。

18.3 アクセス・テスターのインストールと起動

アクセス・テスターは、WebLogicドメイン内外の任意のコンピュータから使用できる2つのjarファイルで構成されます。この項では、テストを実行するコンピュータにアクセス・テスターのjarファイルをコピーするなど、アクセス・テスターのインストール方法を説明します。テスト入力用に選択したモードがテスター・コンソール・モードかコマンドライン・モードかにかかわらず、アクセス・テスターはコマンドラインから開始する必要があります。この項は次のトピックに分割されています。

- アクセス・テスターのインストール

- アクセス・テスターでサポートされているシステム・プロパティについて

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

18.3.1 アクセス・テスターのインストール

このトピックでは、どのコンピュータでも使えるようにアクセス・テスターをインストールする方法を説明します。インストール終後は、いつでもアクセス・テスターを使用することができます。特別なセットアップは必要ありません。

アクセス・テスターのインストール方法

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 Managementコンソールのエージェント登録ページで定義されているものと同じキーストアが含まれていることを確認してください。第12章を参照してください。

5. 使用する環境と要件に応じて、以下の手順に従ってください。

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始するの手順に従えば、手動でリクエストを実行できます。

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

- テスト・スクリプトの実行の手順に従えば、「確認済み(Known Good)」のポリシー構成に従って作成され、「確認済み」としてマークされたテスト・スクリプトを使用することができます。

18.3.2 アクセス・テスターでサポートされているシステム・プロパティについて

アクセス・テスターでは、プレゼンテーションに使用したりテストの特定側面に使用したりすることのできるいくつかの構成オプションを選択することができます。これらのオプションは、サポートされているすべてのシステム・プロパティを示した表18-2に示すように、起動時にJavaの-Dメカニズムを使用して指定します。

表18-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"

18.3.3 テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

グラフィカル・ユーザー・インタフェースを通じて手動でリクエストを行って(結果を取り込み)リアルタイム応答を表示するには、テスター・コンソール・モードでテスターを開始します。テスター・コンソール・モードでもいくつかのシステム・プロパティを使用できますが、この手順ではすべて省略します。

jarファイルはデフォルトの開始クラスを定義します(クラス名を指定する必要はありません)。oamtest.jarと同じディレクトリ内にnap-api.jarが存在することを確認してください。

関連項目:

- アクセス・テスターでサポートされているシステム・プロパティについて

- コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

システム・プロパティを使わずにコンソール・モードでシステム・テスターを開始する方法

1. アクセス・テスターのjarファイルが置かれたディレクトリで、次のコマンドを入力します。

java -jar oamtest.jar

2. oamtestコマンドライン・ツールで使用可能なすべてのオプションを一覧表示するには、-helpオプションを使用します。

java -jar oamtest.jar -help

3. 詳細については以下のいずれかのトピックを参照してください。

- アクセス・テスター・コンソールとナビゲーションの概要

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

18.3.4 コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する

この項は次のトピックに分割されています。

- アクセス・テスターのコマンドラインモードについて

- テスター・コンソール・モードで使用するためのシステム・プロパティなしでテスターを開始する

18.3.4.1 アクセス・テスターのコマンドライン・モードについて

テスト・スクリプトを実行したりアクセス・テスターの動作をカスタマイズしたりするには、コマンドライン・モードでテスターを開始し、Javaの-Dオプションを使ってシステム・プロパティを含めなければなりません。

関連項目:

アクセス・テスターでサポートされているシステム・プロパティについて

コマンドライン・モードでアクセス・テスターを実行すると、アクセス・テスターは、テスト実行管理のためのシェル・スクリプトで使用できる完了コードを返します。コンソール・モードでアクセス・テスターを実行する時は、アクセス・テスターによって返されるコードに従う必要はありません。

特定のテスト・ケースを実行するためにアクセス・テスターをラップするシェル・スクリプトは、アクセス・テスターによって伝達される終了コードを認識し、これに従って動作できる必要があります。コマンドライン・モードでは、アクセス・テスターはSystem.Exit (N)を使用して終了します(Nは次のいずれかのコードになります)。

- 0は、不一致なしですべてのテスト・ケースが正常に終了したことを示します。これには、入力スクリプト内にテスト・ケースが定義されていない状況も含まれます。

- 3は、少なくとも1つの不一致ですべてのテスト・ケースが正常に終了したことを示します。

- 1は、エラーによってアクセス・テスターを実行できなかったこと、またはテスト・ケースを完了できなかったことを示します。これには、入力スクリプトが指定されていない、入力スクリプトを読み込めない、サーバー接続を確立できない、ターゲット・スクリプトを作成できないという状態が含まれます。

これらの終了コードは、アクセス・テスターを使って特定のテスト・ケースを実行するために作られたシェル・スクリプト(Bourneシェルの$?)によって取得することができます。

18.3.4.2 システム・プロパティを持つアクセス・テスターの起動

以下の手順を使ってコマンドライン・モードでアクセス・テスターを開始し、Javaの-Dメカニズムを使用して任意の数の構成オプションを指定します。

関連項目:

アクセス・テスターでサポートされているシステム・プロパティについて

システム・プロパティを指定してアクセス・テスターを開始する方法、またはコマンドライン・モードで開始する方法

1. アクセス・テスターのjarファイルが置かれたディレクトリで、使用環境に合った適切なシステム・プロパティを指定してコマンドを入力します。例:

java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true"
-jar oamtest.jar

2. 開始後は、以下のいずれかのトピックを参照してください。

- アクセス・テスター・コンソールによる接続性とポリシーのテスト

- テスト・ケースおよびスクリプトの作成と管理

18.4 アクセス・テスター・コンソールとナビゲーションの概要

この項では、アクセス・テスター・コンソール、ナビゲーション、およびコントロールの概要を示します。

固定サイズのアクセス・テスター・コンソールを図18-3に示します。コンソール・モードでアクセス・テスターを開始した場合、ユーザーはこのウィンドウを通じてアプリケーションとの対話操作を行なうことができます。このウィンドウのサイズを変更することはできません。詳細は、図の後に説明します。

図18-3 アクセス・テスター・コンソール

「図18-3 アクセス・テスター・コンソール」の説明

メイン・ウィンドウの最上部にあるメニュー・バーにはメニュー名が表示されています。メニュー・バーの下にはツール・バーがあります。ツール・バー内にボタンで表示されているすべてのコマンドは、メニュー・コマンドとして選択することもできます。アクセス・テスター・コンソールは、表18-3に示すように4つのパネルに分割されています。

表18-3 アクセス・テスターのコンソール・パネル

パネル名

説明

サーバー接続

OAMサーバー(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)との接続を確立するために必要な情報を入力するためのフィールドと、「接続」ボタンがあります。

「アクセス・テスターとOAMサーバー間の接続の確立」も参照してください。

保護リソースのURI

保護状態を検証する必要のあるリソースに関する情報が表示されます。リソース検証サーバー・リクエストを送信するには、「検証」ボタンを使用します。

「アクセス・テスター・コンソールからリソース保護を検証」も参照してください。

ユーザー・アイデンティティ

資格証明を認証する必要のあるユーザーに関する情報が表示されます。「ユーザーの認証」サーバー・リクエストの送信には「認証」ボタンを使用します。

「アクセス・テスター・コンソールからユーザー認証をテスト」も参照してください。

ステータス・メッセージ

ユーザーのリクエストに対してアプリケーションが表示するメッセージで構成された、スクロール可能なステータス・メッセージ・エリアが表示されます。ユーザーの認可サーバー・リクエストの送信には認可ボタンを使用します。

「リクエスト待機時間の監視」も参照してください。

テキスト・フィールドでは、右クリックによる「編集」メニューの表示、およびマウスとカーソルによるドラッグアンドドロップ操作が可能です。

OAMサーバーにテスト・リクエストを送信するために使用する4つのプライマリ・ボタンがあります。それぞれのボタンは、表18-4に示す指定アクションを開始するためのトリガとして働きます。

表18-4 アクセス・テスター・パネルのコマンド・ボタン

パネル・ボタン

説明

接続

接続情報を送信して接続を開始します。

検証

保護リソースのURIパネルに入力された情報を送信して、保護の検証を開始します。

認証

「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認証の確認を開始します。

認可

「ユーザー・アイデンティティ」パネルに入力された情報を送信して、認可の確認を開始します。

関連項目:

アクセス・テスターのメニューとコマンド・ボタン

18.4.1 アクセス・テスターのメニューとコマンド・ボタン

アクセス・テスターのその他のボタンとその使用方法を表18-5に示します。ボタンの上にカーソルを合わせると、そのボタンに関するヒントが表示されます。

表18-5 その他のアクセス・テスター・ボタン

コマンド・ボタン

説明

XMLファイル(デフォルトはconfig.xml)に保存された接続構成の詳細をロードします。

このボタンをクリックすると、コンソール内の情報をリフレッシュすることができます。

接続構成の詳細をファイル(デフォルト名はconfig.xml)に保存します。このドキュメントの名前は、コマンド・ライン・モードで実行中のアクセス・テスターに正しい接続情報を提供するために、入力スクリプトに追加できます。

コンソールの一番下にある「保存」コマンド・ボタンは、「ステータス・メッセージ」パネルの内容をログ・ファイルに保存します。

アイコンを含むパネル上のフィールドをクリアします。ツール・バーのボタンを使用すると、接続がすでに確立されている場合は接続フィールドを除くすべてのフィールドがクリアされます。

最後に指定されたリクエストを取得し、これに対してOAMサーバーから受信したレスポンスとともに取得キューに入れます。リクエストとレスポンスを組み合せてテスト・ケースが作成されます。

コンソールの一番下にある取得キューのステータスが更新されて、キュー内のテスト・ケースの数が反映されます。

取得キューの内容は保存することができ、「テスト」メニューのスクリプト作成コマンドまたはコマンド・ボタンを使用して、複数のテスト・ケースを含むテスト・スクリプトを作成することができます。

現在取得キューに置かれているあらゆるテスト・ケースを含むテスト・スクリプトを作成して、キューをクリアするかどうかの確認を行います。キューは、すべてのテスト・ケースが取得されてテスト・スクリプトに保存されるまでクリアしないでください。

現在のOAMサーバーに対してテスト・スクリプトを実行します。「ステータス」メッセージ・ウィンドウには、スクリプトが各テスト・ケースへ進むのに合わせて実行ステータスが表示されます。

コピーされたURIを解析後にクリップボードからインポートし、URIパネルのフィールドに表示します。

パスワードをクリア・テキストで表示するダイアログを表示します。

アクセス・テスターには表18-6に示すメニューがあります。すべてのメニュー項目にはニーモニックがあり、これはALTキーを押すことによって開くことができます(Wondowsシステム上)。また、各メニュー・コマンドに対して定義されたCTRLキーと<文字キー>の組合せを使用して、コマンド・アクセラレータ(キーボード・ショートカット)を利用することもできます。

表18-6 アクセス・テスターのメニュー

メニュー名

メニュー・コマンド

ファイル

- 構成を開く

- 構成の保存

- 終了

注意: データ入力量をできるだけ少なくするために、「構成の保存」メニューと構成を開くメニュー(およびツールバーのコマンド・ボタン)を使用して、特定の接続、URI、およびアイデンティティ情報をファイルに保存したりファイルから読み出したりすることができます。したがって、複数構成の管理が極めて容易になります。また、コマンドライン・モードでアクセス・テスターを使用してテスト・スクリプトを実行する時は、構成ファイルをアクセス・テスターへの入力として使用することができます。

編集

フィールドに対して使用できる標準編集コマンドを提供します。

- 切取り

- コピー

- 貼付け

- すべてのフィールドをクリア

- 保存したURLからURIフィールドをインポート

テスト

- 最後の"..."リクエストを取得(たとえば最後の"認可"リクエストを取得)

- テスト・スクリプトを保存

- テスト・スクリプトを実行

注意: これらの機能を使用し、最後のリクエストと応答を取得してテスト・ケースを作成することができます。これらのテスト・ケースは、テスト・スクリプトに保存して後で実行することができます。

ヘルプ

使用状況情報を表示するAboutコマンドです。

18.5 アクセス・テスター・コンソールによる接続性とポリシーのテスト

この項では、アクセス・テスターをOAMサーバーとともにコンソール・モードで使用して、クイック・スポット・チェックを行なう方法を説明します。

エージェントとOAMサーバー間の接続のスポット・チェックやトラブルシューティングを行うと、エージェントがOAMサーバーと通信できるかどうかの評価に役立ちますが、これは、アップグレードや製品移行を行った後は特に有効です。また、エージェントやOAMサーバーによるリソース保護のスポット・チェックやトラブルシューティングを行うと、アプリケーション・ライフサイクルの間にポリシー構成のエンドツーエンド・テストを作成する際に役立ちます。

以下に、実行するタスクおよびシーケンスの概要と、各タスクの詳細について参照すべき箇所を示します。

注意:

ユーザーは、それぞれのリクエストとレスポンスのペアを取得してテスト・ケースを作成し、そのテスト・ケースをスクリプト・ファイルに保存して後で実行することができます。詳細については「テスト・ケースおよびスクリプトの作成と管理」を参照してください。

タスクの概要: アクセス・テスター・コンソールからスポット・チェックを行なう。

1. 「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。

2. 「アクセス・テスターとOAMサーバー間の接続の確立」の説明に従って、「サーバー接続」パネルに関連詳細事項を入力します。

3. 「アクセス・テスター・コンソールからリソース保護を検証」の説明に従って、保護リソースのURIペインに詳細を入力またはインポートします。

4. 「アクセス・テスター・コンソールからユーザー認証をテスト」の説明に従って、「ユーザー・アイデンティティ」パネルに関連詳細事項を入力します。

5. 認証が正常に終了したら、「アクセス・テスター・コンソールからユーザー認可をテスト」の説明に従って「ユーザー・アイデンティティ」パネルの認可をクリックします。

6. 「リクエスト待機時間の監視」の説明に従って、リクエストの待機時間をチェックします。

18.5.1 アクセス・テスターとOAMサーバー間の接続の確立

OAMサーバーにリクエストを送信するには、アクセス・テスターとサーバ間の通信を確立しなければなりません。この項では、その接続を確立する方法を説明します。

- 「接続」パネルについて

- アクセス・テスターとOAMサーバーの接続

18.5.1.1 「接続」パネルについて

エミュレートしようとしているOAMサーバーとエージェントに関する必要情報をアクセス・テスターの「接続」パネルに入力して、「接続」ボタンをクリックします。テスターが接続を開始して、「ステータス・メッセージ」パネルにステータスを表示します。接続が確立されると、その接続がその後のすべての操作に使われます。

注意:

接続が確立されると、アクセス・テスター・コンソールを再起動するまでその接続を変更することはできません。

「サーバー接続」パネルとコントロールを図18-4に示します。このパネルには、OAMサーバーのプロキシ・ポートへの接続の確立に必要な情報が含まれています。

図18-4 アクセス・テスターの「サーバー接続」パネル

「図18-4 アクセス・テスターの「サーバー接続」パネル」の説明

接続の確立に必要な情報を表18-7に示します。この値は、Oracle Access Managementコンソールの「システム構成」タブから取得されます。

表18-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サーバー間の接続の確立

18.5.1.2 アクセス・テスターとOAMサーバーとの接続

以下の手順を使用してOAMサーバーの接続の詳細を送信します。

注意:

証明書モードでは、付録C「安全な通信」に示すように生成されたキーストアの存在が必要です。

前提条件

アクセス・テスターのインストールと起動

関連項目:

「接続」パネルについて

アクセス・テスターとOAMサーバー間の接続のテスト方法

1. 「アクセス・テスターのインストールと起動」の説明に従ってアクセス・テスターを起動します。

2. 「サーバー接続」パネル(表18-7)で、以下の情報を入力します。

- プライマリおよびセカンダリOAMプロキシの詳細

- タイムアウト時間

- 通信暗号化モード

- エージェントの詳細

3. 「接続」ボタンをクリックします。

4. 「接続」ボタンの横に、接続の確立を示す緑色のチェック・マークが表示されていることを確認します。

5. 「ステータス・メッセージ」パネルに「はい」のレスポンスが表示されていることを確認します。
成功しない場合: OAMサーバーへの接続に問題がある場合は、すべての接続情報(必要に応じて、IPアドレスとポート、エージェント名とパスワード、接続モードおよび関連する証明書とパスワード)を正しく入力したことを確認してください。

まだ接続を確立できない場合は、トレース接続コマンド・モードを使用してアクセス・テスター・コンソールを起動し、接続ログ内の詳細を確認します。また、OAMサーバーの管理者にポリシー・サーバー・ログの確認を依頼します。

18.5.2 アクセス・テスター・コンソールからリソース保護を検証

ユーザーがリソースにアクセスできるようにするには、まず、リソースが保護されていることをエージェントが確認する必要があります。以下の説明に従い、ユーザーがアクセス・テスターを使用してエージェントの役を演じ、指定されたURIが保護されているかどうかをOAMサーバーに検証させて応答をアクセス・テスターに伝達させます。

- 保護リソースのURIパネルについて

- リソース保護の検証

18.5.2.1 保護リソースのURIパネルについて

検証しようとするリソースに関する必要情報をアクセス・テスターの保護リソースのURIパネルに入力し、「検証」ボタンをクリックします。

データ入力量をできるだけ小さくするために、長いURIをブラウザからコピーして、URIのインポートコマンド・ボタンをクリックしてインポートできます。テスターがクリップボードに保存されたURIを解析して、アクセス・テスターのURIフィールドに入力します。

リソースが保護されていることを検証するためにURI詳細を入力するパネルを図18-5に示します。これらのURIフィールドを組み合せるとRFC表記に従った書式になります。例: http://oam_server1:7777/index.html

図18-5 アクセス・テスターの保護リソースのURIパネル

「図18-5 アクセス・テスターの保護リソースのURIパネル」の説明

この評価を行なうために必要な情報を表18-8に示します。

表18-8 保護リソースURIパネルのフィールドとコントロール

フィールドまたはコントロール

説明

スキーム

リソースに指定された通信セキュリティに応じてhttpまたはhttpsを入力します。

注意: アクセス・テスターはhttpまたはhttpsリソースだけをサポートします。アクセス・テスターを使用して、http以外のカスタム・リソースを保護するポリシーをテストすることはできません。

ホスト

リソースの有効なホスト名を入力します。

注意: アクセス・テスター内に指定された<host:port>の組合せは、Oracle Access Managementコンソール内に定義されたホスト識別子のいずれかと一致している必要があります。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。

ポート

URIに対する有効ポートを入力します。

注意: アクセス・テスター内に指定された<host:port>の組合せは、OAMサーバー内に定義されたようにホスト識別子のいずれかと一致する必要があります。このホスト識別子を確認できない場合、OAMはリソース保護を検証できません。

リソース

URIのリソース部分を入力します(たとえば/index.htm)。このリソースは、Oracle Access Managementコンソールで認証および認可ポリシーに対して定義されたリソースと一致している必要があります。

注意: 保護されている場合、ここに入力したリソース識別子は、Oracle Access Managementコンソールで認可ポリシーに指定された識別子と一致している必要があります。

クリップボードに保存されたURIを解析してインポートするには、このボタンをクリックします。

操作

アクセス・テスターに示されたリストから、URIの操作部分を選択します。ただし、OAMサーバーはアクションの違いを認識しません。したがって、ここは「取得 」のままにしておいても問題ありません。

認証スキームを取得

保護リソースのセキュリティ保証に使用する認証スキームについて、その詳細を返すようOAMサーバーに要求するには、このチェック・ボックスを選択します。URIが保護されている場合、この情報は「ステータス・メッセージ」パネルに表示されます。

検証

「検証」ボタンをクリックしてOAMサーバーにリクエストを送信します。レスポンスを受信すると、アクセス・テスターはそのレスポンスを「ステータス・メッセージ」パネルに表示します。

「検証」ボタンの横に表示される緑色のチェック・マークは、「はい」のレスポンスを示し、この場合、リソースは保護されています。ステータス・メッセージパネルにはリソースのリダイレクトURLが表示される他、資格証明が必要とされることも表示されます。

注意: 認証スキームを取得ボックスを選択した場合は、「ステータス・メッセージ」パネルにもこのリソースを保護する認証スキームの名前とレベルが表示されます。

「検証」ボタンの横に表示される赤の円は、リソースが保護されていないことを示します。「ステータス・メッセージ」パネルにも「いいえ」のレスポンスが表示されます。

ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。

関連項目:

- アクセス・テスター・コンソールからリソース保護を検証

- テスト・ケースおよびスクリプトの作成と管理

18.5.2.2 リソース保護の検証

以下の手順を使用してリソース情報をOAMサーバーに送信し、「ステータス・メッセージ」パネルでレスポンスを検証します。

前提条件

アクセス・テスターとOAMサーバー間の接続の確立

関連項目:

保護リソースのURIパネルについて

リソースが保護されていることを確認する方法

1. アクセス・テスターの保護リソースのURIパネルで、自身のリソース情報を入力またはインポートします(表18-8)。

2. 「検証」ボタンをクリックしてリクエストを送信します。

3. リソースの保護方法や保護レベルといったリソース関連のデータを含め、アクセス・テスターの出力を確認します。

4. 「検証」ボタンの横に、リソースが保護されていることを示す緑色のチェック・マークが表示されていることを確認します。

5. 「ステータス・メッセージ」パネルで、リダイレクトURL、認証スキーム、および資格証明が必要とされることを確認します。

6. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。

7. 以下のいずれかの方法を使用し、データ入力とサーバーの処理をできるだけ少なくするためにURIを保存しておきます。

8. 「アクセス・テスター・コンソールからユーザー認証をテスト」に進んでください。

18.5.3 アクセス・テスター・コンソールからユーザー認証をテスト

この項の内容は次のとおりです。

- 「ユーザー・アイデンティティ」パネルについて

- ユーザー資格証明による認証のテスト

18.5.3.1 「ユーザー・アイデンティティ」パネルについて

ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められた認証ポリシーに基づいてユーザーのアイデンティティを検証する必要があります。アクセス・テスターを使用すれば、ユーザーがエージェントの役を演じて、保護リソースに対する特定のユーザーIDをOAMサーバーに認証させることができます。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。

テスト評価に必要な情報を入力するアクセス・テスター・パネルを図18-6 に示します。

図18-6 アクセス・テスターの「ユーザー・アイデンティティ」パネル

「図18-6 アクセス・テスターのユーザー・アイデンティティパネル」の説明

入力が必要な情報を表18-9に示します。

表18-9 アクセス・テスターの「ユーザー・アイデンティティ」パネルのフィールドとコントロール

フィールドまたはコントロール

説明

IPアドレス

ユーザー資格証明の検証を行なうユーザーのIPアドレスを入力します。OAMサーバーと通信するすべてのエージェントがエンド・ユーザーのIPアドレスを送信します。

デフォルト: 入力されるIPアドレスは、アクセス・テスターを実行するコンピュータに属するものです。

実際のユーザーのIPアドレスを必要とするポリシーをテストするには、デフォルトのIPアドレスを実際のIPアドレスに置き換えてください。

ユーザー名

資格証明の検証対象となる個人のユーザーIDを入力します。

注意: 資格証明を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはそのユーザー名フィールドとパスワード・フィールドを有効または無効にします。同様に、ユーザーのX509証明書を必要とする認証スキームによってリソースが保護されている場合、アクセス・テスターはその証明書フィールドを有効または無効にします。

パスワード

資格証明の検証対象となる個人のパスワードを入力します。

?

ポップアップ・ウィンドウ内にクリア・テキストでパスワードを表示するには、このボタンをクリックします。

ユーザー資格証明ストア

資格証明を認証する必要のあるユーザーのX.509証明書を格納するPEMフォーマットのファイルです。

X509認証スキームによってURIが保護されている場合、テスターは、ユーザー名/パスワードではなく、またはユーザー名/パスワードに加えて、PEMフォーマットのX509証明書を資格証明として使用します。OAMサーバーでのセキュリティ・ポリシーの構成によっては、X509証明書が認証に使用される場合もあります。

注意: 証明書ベースの認証を機能させるには、CA証明書とSSLキーストア証明書を使用してOAMサーバーを正しく構成する必要があります。OAMサーバーとWebgate間の通信のセキュリティ確保の詳細は、付録Cを参照してください。

...

ユーザー証明書ストア・パスのファイル・システムを表示するには、このボタンをクリックします。

認証

OAMサーバーにリクエストを送信して「ステータス・メッセージ」パネルでレスポンスを探すには、「認証」ボタンをクリックします。

注意: 提供される資格証明のタイプ(ユーザー名/パスワードまたはX.509証明書)は、URIを保護している認証スキームの要件と一致していなければなりません。

注意: 証明書ベースの認証では、付録Cに示すように、証明書を使用してOAMサーバー・デプロイメントを正しく構成する必要があります。

認可

ユーザーの資格証明の検証後に認可ボタンをクリックすれば、リソースに対するリクエストをOAMサーバーに送信することができます。レスポンスについては「ステータス・メッセージ」パネルを確認してください。

このリクエストは、アイデンティティ・パネルで定義されたユーザーが、「URI」パネルで定義されたリソースにアクセスできるかどうかを決定するために、「URI」およびアイデンティティ・パネルで収集した情報をOAMサーバーに送信します。サーバーは「はい」(ユーザーはリソースにアクセスできます)または「いいえ」(ユーザーはリソースにアクセスできません)を返します。OAMサーバーからは、実際のエージェントならば正常に処理するアクション(レスポンス)などの追加情報が返される場合があります。

「認証」ボタンの横に表示される緑色のチェック・マークは認証が成功したことを示します。「ステータス・メッセージ」パネルにも認証が成功したことを示す「はい」のレスポンスが表示されるほか、ユーザーDNとセッションIDも示されます。

「認可」ボタンの横に表示される緑色のチェック・マークは認可が成功したことを示します。「ステータス・メッセージ」パネルにも、認可が成功したことを示す「はい」のレスポンスとアプリケーション・ドメインの詳細が表示されます。

「認証」ボタンの横に表示される赤の円は認証が失敗したことを示します。「ステータス・メッセージ」パネルにも認証に失敗したことを示す「いいえ」のレスポンスが表示されます。

認可ボタンの横に表示される赤の円は認可が失敗したことを示します。「ステータス・メッセージ」パネルにも認可にしっぱししたことを示す「いいえ」のレスポンスが表示されます。

ユーザーは、それぞれのリクエストとレスポンスのペアを取得して複数のテスト・ケースを作成し、後で実行できるようにそのテスト・ケースをスクリプト・ファイルに保存します。

関連項目:

- アクセス・テスター・コンソールからユーザー認証をテスト

- テスト・ケースおよびスクリプトの作成と管理

18.5.3.2 ユーザー資格証明による認証のテスト

以下の手順を使用してエンド・ユーザーの資格証明をOAMサーバーに送信し、認証を検証します。このポリシー評価の際には、関係するすべての認証レスポンスが考慮されます。

前提条件

コンソールに保持されたURI情報でアクセス・テスター・コンソールからリソース保護を検証します。

関連項目:

「ユーザー・アイデンティティ」パネルについて

ユーザー資格証明による認証のテスト方法

1. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認証対象のユーザーに関する情報を入力します(表18-9)。

2. 「認証」ボタンをクリックしてリクエストを送信します。

3. 「認証」ボタンの横に、ユーザーが認証されたことを示す緑色のチェック・マークが表示されていることを確認します。
認証できない場合: 正しいユーザーIDとパスワードを入力したことを確認し、再度認証を試みてください。また、第14章の説明に従い、終了させる必要のあるアクティブ・ユーザー・セッションの有無をOracle Access Managementコンソールで確認してください。

4. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストと応答を取得し、後で使用できるテスト・ケースを作成します。

5. URIとユーザー・アイデンティティ情報を保持して、「アクセス・テスター・コンソールからユーザー認可をテスト」へ進んでください。

18.5.4 アクセス・テスター・コンソールからユーザー認可をテスト

ユーザーがリソースにアクセスできるようにするには、エージェントが、OAMサーバー上に定められたポリシーに基づいてユーザーの権限を検証する必要があります。アクセス・テスターを使用してユーザーがエージェントとしての役割を演じ、認証されたユーザー・アイデンティティにリソースへのアクセスを認可できるかどうかをOAMサーバーに検証させることができます。

以下の手順を使用して、認証済みエンド・ユーザーのリソースへのアクセス認可を検証します。このポリシー評価の際には、関係するすべての認可上の条件とレスポンスが考慮されます。

前提条件

コンソールに保持されたすべての情報でアクセス・テスター・コンソールからユーザー認証をテストします。

関連項目:

「ユーザー・アイデンティティ」パネルについて

注意:

アクセス・テスターから保護リソースのURIが確認されてユーザーのアイデンティティが認証されれば、それ以外の情報は必要ありません。認可ボタンをクリックしてリクエストを送信してください。ただし、リソースが別のものに変更された場合は改めてシーケンスを開始して検証を行い、次いで認証と認可を行なう必要があります。

ユーザー認可のテスト方法

1. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、ユーザーが認証されていることを確認します(表18-9)。

2. アクセス・テスターの「ユーザー・アイデンティティ」パネルで、認可ボタンをクリックします。

3. 認可ボタンの横に、ユーザーが認可されたことを示す緑色のチェック・マークが表示されていることを確認します。
成功しない場合: Oracle Access Managementコンソールを使用して認可ポリシーを確認します。

4. 「ステータス・メッセージ」パネルで、テスト実行に関する詳細を確認します。

5. 「テスト・ケースおよびスクリプトの作成と管理」の説明に従ってリクエストとレスポンスを取得し、後で使用できるテスト・ケースを作成します。

6. 次の項目へ進みます。

- リクエスト待機時間の監視

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

18.5.5 リクエスト待機時間の監視

OAMサーバーのパフォーマンスを理解するには、OAMサーバーがエージェントから渡されるリクエストをどの程度の効率で処理しているかを知る必要があります。サーバーのメトリックを明らかにする方法は数多くありますが、エージェントの立場からサーバーのパフォーマンスを明らかにするのが有効な場合もあります。これは、アクセス・テスターを使用して以下の手順により行なうことができます。

前提条件

アクセス・テスターのインストールと起動

タスクの概要: リクエスト待機時間の監視には以下のタスクが含まれます。

1. リソース保護の検証

2. アクセス・テスター・コンソールからユーザー認証をテスト

3. アクセス・テスター・コンソールからユーザー認可をテスト

4. 次に示す実行ログファイル内、およびテスト実行中に生成されるその他のファイル内の待機時間情報を確認します。例:

...
[2/3/12 11:03 PM][info] Summary statistics
[2/3/12 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms
[2/3/12 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms
[2/3/12 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms
[2/3/12 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms
...

5. 次の項目へ進みます。

- テスト・ケースおよびスクリプトの作成と管理

- スクリプト、ログ・ファイル、および統計の評価

18.6 テスト・ケースおよびスクリプトの作成と管理

テスト管理とは、管理者やシステムによっていつでも実行することのできる再現可能なテストを作成することを言います。クイック・スポット・チェックは、直面している問題のトラブルシュートを行なう上で非常に有効かつ効果的です。しかし、サーバーとポリシーの構成を検証する上で、より高い予測可能性と再現性を備えた方法が必要になることも少なくありません。この方法には、製品リビジョン後の性能低下に関するOAMサーバー構成のテスト、あるいはポリシー作成中やQAサイクルにおけるOAMサーバー構成のテストを含めることができます。

これらのテストを有効なものとするには、複数のユースケースをグループとして実行できるようにする必要があります。テスト・スクリプトが設計されて誤りのないことが確認されてしまえば、OAMサーバーに対して再度テストを行なうことは、ポリシー構成の質の低下を明らかにする助けとなります。

この項では、テスト管理を行なうために必要な情報を以下に示すトピックの中で示します。

- テスト・ケースとテスト・スクリプトについて

- テスト・ケースの取得

- 入力テスト・スクリプトの作成

- 入力テスト・スクリプトのパーソナライズ

- テスト・スクリプトの実行

18.6.1 テスト・ケースおよびテスト・スクリプトについて

テスト・ケースは、アクセス・テスターを使用してOAMサーバーに送信したリクエストと、OAMサーバーから受信した応答で作成します。様々なデータ要素がある中で、テスト・ケースにはリクエスト待機時間と、新旧のテスト・ケースの分析と比較を可能にするその他のアイデンティティ確認情報が含まれます。

取得したテスト・ケースは、新たな入力なしで再実行して新旧の結果を比較することができます。古い結果が「確認済み(Known Good)」としてマークされている場合は、それらの結果と差がテスト・ケースを失敗させる要素となります。

テスト・ケースのワークフローを図18-7に示します。

図18-7 テスト・ケースのワークフロー

「図18-7 テスト・ケースのワークフロー」の説明

タスクの概要: テスト・ケースの作成と管理

アクセス・テスター・コンソールからは、OAMサーバーに接続して手動で個々のテストを行なうことができます。リクエストは、リクエストを送信してOAMサーバーから応答を受信した後に取得キューに保存することができます。他のテスト・ケースを取得は、テスト・スクリプトを作成して取得キューをクリアする前に続けて行なうことができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでおくことをお薦めします。

テスト・スクリプトの作成後は、アクセス・テスター・コンソールまたはコマンド・ラインからそのスクリプトを実行することができます。

18.6.2 テスト・ケースの取得

それぞれのテスト・ケースは、アクセス・テスターからOAMサーバーにリクエストを送信してレスポンスを受信した後に、取得キューに保存できます。テスト・ケースのグループの実行を自動化するテスト・スクリプトを作成する前に、個々のテスト・ケースを必要なだけ取得できます。例として、個別に取得する必要がある3つのテスト・ケースの概要を次に示します。

- 検証のリクエストと応答

- 認証のリクエストと応答

- 認可のリクエストと応答

表18-10に、取得オプションの場所を示します。

表18-10 アクセス・テスターの取得リクエスト・オプション

ロケーション

説明

「テスト」メニュー

最後の"..."リクエストを取得

「テスト」メニューからこのコマンドを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。

ツール・バーからこのコマンド・ボタンを選択して、発行した最後のリクエストと受信した結果を取得キューに追加します(後でテスト・スクリプトに含めるため)。

取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。アクセス・テスターの取得キューは、すべてのテスト・ケースの取得が終了するまでクリアしないでください。

1つまたは複数のテスト・ケースを取得する方法

1. 「アクセス・テスター・コンソールからの接続性とポリシーのテスト」の説明に従い、アクセス・テスターからリクエストを発行します。

2. 応答を受信したら、ツール・バーの「最後の"..."リクエストを取得」コマンド・ボタンをクリックします(または「テスト」メニューから同じオプションを選択)。

3. 「ステータス・メッセージ」パネルで取得を確認し、さらにコンソールの一番下に表示される取得キューのテスト・ケース数を確認します。

4. ステップ1、2、3を繰り返して、テスト・スクリプトに必要な各テスト・ケースをキュー内に取得します。

5. 「入力テスト・スクリプトの作成」へ進みます。

18.6.3 入力テスト・スクリプトの生成

テスト・スクリプトは、アクセス・テスター・コンソールを使用して取得された個々のテスト・ケースの集合です。個々のテスト・ケースをグループにまとめた場合は、テスト範囲を自動化して特定のアプリケーションまたはサイトに関するポリシー構成を検証することが可能になります。

アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。スクリプト作成オプションを使用すれば、XMLファイルのテスト・スクリプトを作成して取得キューをクリアすることができます。取得したキューを保存せずにアクセス・テスターを終了しようとすると、終了前にテスト・ケースをテスト・スクリプトに保存するかどうかの確認が行なわれます。

注意:

取得キューは、スクリプトに含めようとしているすべてのテスト・ケースを取得するまでクリアしないでください。

18.6.3.1 入力テスト・スクリプトの生成について

アクセス・テスターへの入力として使用するテスト・スクリプトを作成して、複数のテスト・ケースを自動処理することができます。これらのスクリプトは以下の規則に従わなければなりません。

- オペレータまたはシステムによるリプレイが可能

- 異なるポリシー・サーバーを作動させるテスト・スクリプトの共有を可能にするために、スクリプトを変更することなく異なるポリシー・サーバーへのリプレイが可能

- 「確認済み(Known Good)」の結果に対するテスト実行結果の比較が可能

スクリプト作成コマンドの場所を以下に示します。

表18-11 スクリプト作成コマンド

コマンドの場所

説明

「テスト」メニュー

スクリプト作成

「テスト」メニューからスクリプト作成を選択して、取得したテスト・ケースを含むスクリプトの作成をを開始します。

ツール・バーからスクリプト作成コマンド・ボタンを選択して、取得したテスト・ケースを含むスクリプトの作成をを開始します。スクリプトの名前を指定または選択すると、取得キューをクリアするかどうかの確認が行なわれます。取得キューは、テスト・ケースがすべてスクリプトに保存されるまでクリアしないでください。

18.6.3.2 入力テスト・スクリプトの生成

前提条件

テスト・ケースの取得

取得したテスト・ケースを含むテスト・スクリプトの作成方法

1. 「テスト・ケースの取得」の説明に従い、スクリプトに含めたいリクエストを実行して取得します。

2. ツール・バーのスクリプト作成コマンド・ボタンをクリックして(または「テスト」メニューから同じオプションを選択して)、取得したすべてのテスト・ケースを含めます。

3. 新しいダイアログ・ボックスで新しいXMLスクリプト・ファイルの名前を選択または入力し、「保存」をクリックします。

4. 既存ファイルに上書きする場合は「はい」をクリックします(または「いいえ」をクリックしてウィンドウを閉じ、新しいファイル名を入力)。

5. 「警告の保存」ダイアログ・ボックスで「いいえ」をクリックして取得キューをそのまま維持し、スクリプトへのテスト・ケースの追加を継続します(または「はい」をクリックしてすべてのテスト・ケースのキューをクリア)。

6. アクセス・テスターを終了する前にテスト・スクリプトの場所を確認します。

7. 次に示すようにスクリプトの作成者、作成時期、作成理由などの詳細を含め、テスト・スクリプトをパーソナライズします。

18.6.4 入力テスト・スクリプトのパーソナライズ

この項では、テスト・スクリプトのパーソナライズ方法とカスタマイズ方法を説明します。

- テスト・スクリプトのカスタマイズについて

- テスト・スクリプトのカスタマイズ

18.6.4.1 テスト・スクリプトのカスタマイズについて

スクリプトにタグを付けてテスト実行時に使用する情報を指定するには、テスト・スクリプトの制御ブロックを使用します。スクリプトの作成者、作成時期、および作成理由についての詳細を含めたい場合も考えられます。また、1つまたは複数の制御パラメータを使ってスクリプトをカスタマイズしたい場合もあるかもしれません。

アクセス・テスターでは、スクリプトを変更することなくスクリプトの処理を変更するコマンドライン「制御」パラメータを使用することができます (テスト名やテスト番号など)。これにより、「確認済み(Known Good)」の入力テスト・スクリプトを変更することなくテスト実行を構成することが可能です。制御要素とこれらのカスタマイズ方法を表18-12に示します。

表18-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

18.6.4.2 テスト・スクリプトのカスタマイズ

前提条件

入力テスト・スクリプトの作成

テスト・スクリプトのカスタマイズ方法

1. アクセス・テスターで作成したテスト・スクリプトを探して開きます。

2. スクリプトをカスタマイズまたはパーソナライズするために必要な詳細を追加します。

3. ファイルを保存して「テスト・スクリプトの実行」へ進みます。

18.6.5 テスト・スクリプトの実行

「確認済み(Known Good)」のポリシー構成を基準にテスト・スクリプトを作成してこれを「確認済み」としてマークしたら、コンソールを使ってそれぞれのテストを手動で指定するのではなく、スクリプトを使ってアクセス・テスターを作動させることが重要です。この項の内容は次のとおりです。

- テスト・スクリプトの実行について

- テスト・スクリプトの実行

18.6.5.1 テスト・スクリプトの実行について

テスト・スクリプトは、アクセス・テスター・コンソール内部から対話的に実行したり、コマンド・スクリプトにより自動でテストを実行したりすることができます。自動テスト実行は、オペレーティング・システムやApache JMeterなどのハーネスによるスケジュールが可能で、手動操作を加えることなく実行されます。コマンドライン・モードでの人間による入力がない点を除けば、これら2つの実行モードは同じものです。

注意:

.bat(Windows)や.sh(Unix)などのスクリプトは、コマンドライン・モードでテスト・スクリプトを実行します。作成したテスト・スクリプトは、スクリプト実行メニュー・コマンドやアクセス・テスターのコマンドラインを使用して実行することができます。

テスト・スクリプトを実行するためのコマンドを表18-13に示します。

表18-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. コマンドライン・モードでは、「アクセス・テスターのコマンドライン・モードについて」に示すようにアクセス・テスターは終了コードで終了します。

18.6.5.2 テスト・スクリプトの実行

前提条件

入力テスト・スクリプトの作成

テスト・スクリプトの実行方法

1. 「入力テスト・スクリプトの作成」に示すように、アクセス・テスターを終了する前に保存テスト・スクリプトの場所を確認します。

2. 以下のいずれかの方法を使い、処理のためにテスト・スクリプトを送信します。

- アクセス・テスター・コンソールでツール・バーからスクリプト実行コマンド・ボタンを選択して(または「テスト」メニューのスクリプト作成を選択して)プロンプトに従い、スクリプトの実行に合わせて「ステータス・メッセージ」パネルに表示されるメッセージを確認します。

- コマンドラインから、希望のシステム・プロパティが指定されたテスト・スクリプトを指定します。「コマンドライン・モードで使用するためのシステム・プロパティを指定してアクセス・テスターを開始する」を参照してください。

java -Dscript.scriptfile="\tests\script.xml" -Dcontrol.ignorecontent="true"
-jar oamtest.jar

3. 「スクリプト、ログ・ファイル、および統計の評価」に示すように、ログ・ファイルと出力ファイルを確認し、新たに作成された結果と入力スクリプトから取得した結果をアクセス・テスターが比較した後で、追加的な分析を行ないます。

18.7 スクリプト、ログ・ファイル、および統計の評価

この項の内容は次のとおりです。

- テスト結果の評価について

- 保存された接続構成ファイルについて

- 作成された入力テスト・スクリプトについて

- テスト実行結果が格納されたターゲット出力ファイルについて

- 統計ドキュメントについて

- 実行ログについて

18.7.1 テスト結果の評価について

テスト実行終了時には、3つのドキュメントからなる「結果バンドル」が作成されます。

- ターゲット・スクリプト: 新しいテスト・ケースが格納されたXMLドキュメント

注意:

アクセス・テスターがマルチスレッド・モードで実行するように構成されている場合、ターゲット・スクリプトは作成されません。

- 実行ログ: スクリプト実行時に表示されたメッセージが格納されたテキストファイル

- 実行統計: テスト・メトリックと不一致要素のリストが格納されたXMLドキュメント

オリジナル・スクリプトとターゲット・スクリプト内にあるテスト・ケースの一致ペアは、テスト・ケースIDを共有しています。このIDは、オリジナル・スクリプトとターゲット・スクリプト内の個々のテスト・ケースの比較を可能にするUUID(中略)で表わされます。詳細については「作成された入力テスト・スクリプトについて」を参照してください。

統計ドキュメントにはサマリー統計と詳細統計、および一致しなかったテスト・ケースのリストが格納されます。詳細統計は、さらに詳しい分析や結果履歴の記録に使用できます。サマリー統計はテスト実行の終了時に表示されるものと同じ統計で、テスト実行の結果を迅速に評価するために使用できます。統計ドキュメント内に作成される不一致テスト・ケースのリストには、表18-14に示すように、不一致をトリガしたテスト・ケースIDと不一致の理由が含まれています。

表18-14 統計ドキュメントの不一致結果の理由

不一致の理由

説明

結果

OAMサーバーのレスポンス・コード(「はい」と「いいえ」)が異なるためテスト・ケースが一致しませんでした。

コンテンツ

OAMサーバーによって返された特定データの値が異なるためテスト・ケースが一致しませんでした。不一致をトリガした最後のテスト実行時の特定値が含まれます。

18.7.2 保存された接続構成ファイルについて

これは、「ファイル」メニューの「構成を保存」コマンドを使用して保存した出力ファイルで、デフォルトのファイル名はconfig.xmlです。この接続構成ファイルには、アクセス・テスター・コンソールのサーバー接続パネルで指定された詳細が格納されています。

注意:

以下のトピックに示すように、入力テスト・スクリプト・ファイルも作成されます。構成ファイル名は、アクセス・テスターをコマンドライン・モードで実行した時に接続ファイル内に定義された接続情報を取得できるようにするために、入力テスト・スクリプト内で使われます。

例18-1 接続構成ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestconfig xmlns="http://xmlns.example.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>

18.7.3 生成された入力テスト・スクリプトについて

入力テスト・スクリプトは、アクセス・テスターを使用してユーザー固有のテスト・ケースを取得することによって作成されます。「制御」要素の「configfile」属性は、OAMサーバーとの接続確立用にコマンドライン・モードで使用する接続構成ファイルを指定するために、作成後に更新されます。

例18-2 生成された入力テストスクリプト

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.example.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Manually generated using agent 'agent1'"
createdon="2012-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://emerald.uk.example.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=uk,dc=example,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>

18.7.4 テスト実行結果を含むターゲット出力ファイルについて

この例は、コマンドライン・モードでアクセス・テスターを実行して、取得した4つのテスト・ケースを実行するための入力としてscript.xmlファイルを指定することにより作成されたものです。

Dscript.scriptfile="script.xml" -jar oamtest.jar

例18-3の様々なセクションに注意してください。実行ログに示すようにこのテスト実行では不一致が見つからず、4つのリクエストのすべてが一致していることが示されています。

例18-3 テスト実行中に生成された出力ファイル

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<oamtestscript xmlns="http://xmlns.example.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent 'agent1'"
createdon="2012-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://emerald.uk.example.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>

18.7.5 統計ドキュメントについて

統計ファイル(_stats.xml)は、実行ログに示されたテスト実行時にターゲット出力スクリプトとともに作成されます。script.xmlファイルは、取得した4つのテスト・ケースを実行するための入力として使われます。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。

サンプル統計ドキュメントを例18-4に示します。この実行の統計は様々なセクションに示されており、これらと過去の「確認済(Known Good)」実行の統計と比較できます。

例18-4 統計ドキュメントの例

A sample statistics document is shown here. Notice,
<oamteststats xmlns="http://xmlns.example.com/idm/oam/oamtest/schema"
version="1.0">
<history description="Generated from script 'script.xml' using agent
'agent1'" createdon="2012-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>

18.7.6 実行ログについて

このサンプル実行ログは、テスト実行時に4つのテスト・ケースを実行するscript.xmlを使用して、ターゲット出力スクリプトとともに作成されたものです。このテスト実行では不一致は見つからず、4つのリクエストのすべてが一致していることが示されています。

この例を見ると、アクセス・テスターの「ステータス・メッセージ」パネルに表示される情報と同じ情報で構成されていることが分かります。テスト・ケース、テスト名、接続構成ファイル、エージェント名、接続ステータス、リクエスト評価ステータス、認証スキーム、リダイレクトURL、求められる資格証明、認証ステータスとユーザーDN、セッションID、認証ステータス、検証ステータス、サマリー統計などを確認してください。また、この実行によってターゲット・スクリプトと統計ドキュメントが作成されていることにも注意してください。

例18-5 実行ログ

[2/3/12 11:02 PM][info] Setting up to run script 'script.xml'
[2/3/12 11:02 PM][info] Loading test cases and control parameters from script
[2/3/12 11:02 PM][info] Loaded 4 cases
[2/3/12 11:02 PM][info] Control data for this test run:
[2/3/12 11:02 PM][info] Test name : 'samplerun1'
[2/3/12 11:02 PM][info] Configuration file : 'config.xml'
[2/3/12 11:02 PM][info] Ignore content : 'false'
[2/3/12 11:02 PM][info] Loading server configuration from file
[2/3/12 11:02 PM][info] Loaded server configuration
[2/3/12 11:02 PM][info] Connecting to server as agent 'oam_agent1'
[2/3/12 11:03 PM][info][request] Connect : Yes
...
[2/3/12 11:03 PM][info] Test 'samplerun1' will process 4 cases
[2/3/12 11:03 PM][info][request] Validate : Yes
[2/3/12 11:03 PM][info] Authentication scheme : LDAPScheme, level : 2
[2/3/12 11:03 PM][info] Redirect URL :
http://oam_server1.uk.example.com:2100/server/
[2/3/12 11:03 PM][info] Credentials expected: 0x01 (password)
[2/3/12 11:03 PM][info][request] Authenticate : Yes
[2/3/12 11:03 PM][info] User DN : cn=admin1,dc=us,dc=company,dc=com
[2/3/12 11:03 PM][info] Session ID : -1
[2/3/12 11:03 PM][info][request] Authorize : Yes
[2/3/12 11:03 PM][info][request] Validate : Yes
[2/3/12 11:03 PM][info] Summary statistics
[2/3/12 11:03 PM][info] Matched 4 of 4, avg latency 232ms vs 238ms
[2/3/12 11:03 PM][info] Validate: matched 2 of 2, avg latency 570ms vs 578ms
[2/3/12 11:03 PM][info] Authenticate: matched 1 of 1, avg latency 187ms vs 187ms
[2/3/12 11:03 PM][info] Authorize: matched 1 of 1, avg latency 172ms vs 188ms
[2/3/12 11:03 PM][info] Generated target script 'samplerun1_0302171__target.xml'
[2/3/12 11:03 PM][info] Generated statistics log 'samplerun1_0302171__stats.xml'

19 11g Webgateが関与するセッションの集中ログアウトの構成

この章では、11g Webgateが関与するセッションに対するAccess Managerの単一のログアウト(グローバル・ログアウト)について説明します。Access Managerでは、単一のログアウトはアクティブなセッションを終了するプロセスを意味します。ログアウトには、カスタム・ログアウト・スクリプトではなく、Access Managerが提供するログアウト・メカニズムを使用することをお薦めします。このメカニズムについては、この章で説明します。

この章の内容は次のとおりです。

- 前提条件

- Access Manager 11gの集中ログアウトの概要

- 11g Webgateの集中ログアウト構成

- グローバル・サインオンと集中ログアウトの検証

関連項目:

エージェントに応じて、様々なログアウトの実装ステップが必要になります。

- 第22章の10g Webgateログアウト

- 第21章のOSSOエージェント(mod_osso)ログアウト

19.1 前提条件

この章に示すタスクを実行するには、以下の前提条件を満たす必要があります。

- Access Managerによってエージェントが構成され登録されたWebサーバー上に、アプリケーションがデプロイされていなければなりません。

- サポートされている任意のWebサーバーおよびプラットフォーム上では、1つのOAMエージェントが実行されていて、Access Manager 11gに登録されている必要があります(第13章)。

- ポリシーは、Access Manager 11gアプリケーション・ドメイン内のリソースを保護するように構成する必要があります(第17章)。

19.2 Access Manager 11gの集中ログアウトの概要

特に明記しないかぎり、この章の情報は、デフォルトの埋込み資格証明コレクタ(ECC)を使用するOAM 11g Webgateエージェントに適用されます。

この項の内容は次のとおりです。

- 11g Webgateの集中ログアウトについて

- 11g Webgateのログアウト・パラメータについて

19.2.1 11g Webgateの集中ログアウトについて

Access Managerは、セッションに集中ログアウト(グローバル・ログアウト)を提供します。集中ログアウトとは、アクティブなセッションを終了するプロセスのことであり、次の事項を意味します。

- アプリケーションが、SSO環境で使用する固有のログアウト・ページを提供することはできません。

- アプリケーションは、Webgate Administratorが指定するログアウトURLを参照する値でログアウト・リンクを構成できるようにする必要があります。

注意:

アプリケーションでADF認証サーブレットを使用することをお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。

パートナ・アプリケーションとは異なり、外部アプリケーション(Yahoo!メールなど)では、認証がOAMに委任されません。また、ログアウト制御もOAMシングル・サインオン・サーバーに引き渡されません。これらのアプリケーションのログアウトはユーザーの責任となります。

表19-1に、集中ログアウトが行われる状況を示します。ログアウトURLが見つかり、Cookie(11g Webgateの場合はOAMAuthnCookie、10g Webgateの場合はObSSOcookie)が削除された場合。Webgateはユーザーをログアウトさせて、ユーザーの再認証を要求します。

表19-1 集中ログアウトの状況

状況

説明

明示的

クライアントの状態が無効化されてセッションが終了。リソースに再度アクセスしようとする場合、クライアントは再認証を行なわなければなりません。

- ユーザーがログアウトした時

- 管理者がセッションを終了させたとき

- アイデンティティ側の変化に基づいてセッションが終了された時

暗黙的

定められたセッション・タイムアウト時間内にユーザー・アクティビティがなかった場合、そのユーザーは自動的にログアウトされてパートナーにリダイレクトされ、新しいセッションIDが付与されて資格証明のために新しいプロンプトが表示されます。これは、リソースに対して低レベルの認証が構成されていない場合に実行されます。

Access Managerの場合、logout.htmlにサーバー・ログアウトへの明示的なリダイレクトが指定されていないかぎり、10g Webgateが単にログアウトURLに遭遇しただけではユーザーはログアウトされません。Webgateは、サーバー・ログアウトへユーザーをリダイレクトします。

19.2.2 11g Webgateのログアウト・パラメータ

一般的に、SSOエンジンは、集中ログアウトの際にuser-session-exists要求を受け取ります。セッション管理エンジンはセッションを参照し、the-session-exists応答で応答します。SSOエンジンは、Clear Session要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。その後、SSOエンジンは、Session Cleared応答を送信します。

ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはアプリケーションのクライアント側状態を削除します。

OAMサーバーからの11g Webgateのログアウトを構成するには、Logout Callback URLが必要になります(表13-3)。11gエージェントの集中ログアウトでは、Cookieをloggedoutからemptyに設定し、ログアウト時にOAMAuthnCookie_<ホスト:ポート>_<ランダムの数値>を期限切れにして、これを明示的に削除します(Cookieを空状態やログアウトされた状態のままにするのではありません)。

11g Webgateと10g Webgateには若干違いがあり、Logout Callback URLのURI部分のみ一致します。

SSOエンジンはOAMサーバー上の集中ログアウト・ページをサポートし、以下の処理を行います。

- ログアウト時に11g WebgateのLogout Callback URLをコールバックします。
WebgateのパラメータLogout Callback URLは、ホスト:ポート部分のないURI形式(推奨)を使用して構成できます。OAMサーバーは、元の要求に含まれるホスト:ポートを基に動的に完全なURLを作成して、そのURLをコールバックします。これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。

- ログアウト後に、end_url(問合せパラメータとして渡される)にランディングします。

11g Webgate登録ページのいくつかの要素は、11g Webgateの集中ログアウトを可能にします。登録後はObAccessClient.xmlファイルに表19-2の情報が格納されます。

表19-2 登録後のログアウトの詳細(ObAccessClient.xml)

要素

説明

ログアウトURL

10g Webgateおよび11g Webgate

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

- 一致する場合、Webgateログアウト・ハンドラが起動します。

- ログアウトURLが構成されていない場合の要求URLの確認は「logout.」に対して行なわれ、このURLが見つかった場合も(「logout.gif」と「logout.jpg」を除く)ログアウト・ハンドラがトリガされます。

Default = [](未設定)

注意: これは、カスタマイズしたローカル・ログアウト・ページから初期ログアウトをトリガーするために使用する、標準の10g Webgate構成パラメータです。これについては、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」の説明を参照してください。

11g Webgateのみのその他のログアウト

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サーバーは、コールバックURLを再構築することなく直接コールバックします。

リクエストURLがログアウト・コールバックURLに一致したとき、Webgateは自身のcookieを消去してレスポンスで.gifイメージをストリーミングします。これはOSSOエージェントの動作に似ています。

Webgateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ(end_url=http://host:port/...")として記録され、ログアウト後にOAMサーバーがリダイレクトする先のページになります。

注意: リモート登録テンプレートでは、このパラメータの名前はlogoutCallbackUrlです(表13-10)。

他のOracle Access Managementサービスは、サーバー上の中央のログアウト・ページをサポートします。end_urlは、OPSS組み込みアプリケーションから渡されるターゲットURL問合せパラメータに依存しています。関連項目: 「Oracle ADFコード・アプリケーションの集中ログアウト構成」。

ログアウト・リダイレクトURL

このパラメータは、エージェントの登録が完了すると、自動的に移入されます。デフォルトでは、OAMサーバーのホスト名とデフォルト・ポートの14200に基づきます。例:

デフォルト = http://OAMServer_host:14200/oam/server/logout

ログアウトURLは、ログアウト・ハンドラをトリガーします。これは、OAMAuthnCookie_<host:port>_<random number>を削除して、ユーザーが次回Access Managerにより保護されたリソースにアクセスするときに、再認証を義務付けます。

- Webgateログアウト・ハンドラがトリガーされると、このハンドラはログアウト・リダイレクトURLパラメータに指定された集中ログアウト・ページにリダイレクトします(ログアウト・リダイレクトURLパラメータが指定されている場合)。

- 明示的に消去され、構成されていない場合は、10gの動作がトリガーされます。ローカル・ログアウト・ページでは、カスタマイズされたスクリプトを使用して集中ログアウト・ページにリダイレクトが可能で、必要な場合は追加的なサード・パーティのCookieを削除できます。

ログアウト・ターゲットURL

この値は、ログアウト時にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。

デフォルト: end_url

注意: end_url値は、jps-config.xmlのparam.logout.targeturlを使用して構成されます。

- ログアウト・ターゲットURLが設定されている場合、Webgateはログアウト・リクエストの問合せパラメータで渡された値を探し、それをOAMサーバーへのリダイレクトURL内のend_url問合せパラメータとして渡します。

- ログアウト・ターゲットURLが設定されていない場合、Webgateはデフォルト名「end_url」を探し、そのend_url問合せパラメータを一緒に渡します。

19.3 11g Webgateの集中ログアウト構成

この項の内容は次のとおりです。

- ECC使用時の11g Webgateの集中ログアウト構成

- 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

関連項目:

- 「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」

- Access Manager 11.1.2使用時のOSSOエージェントのログアウト

- Oracle ADFコード・アプリケーションの集中ログアウト構成

19.3.1 ECC使用時の11g Webgateの集中ログアウト構成

11gリソースWebgateの登録時または編集時には、ここで説明するようにログアウト・パラメータを構成します。

注意:

LogOutUrlパラメータがすでに11g Webgate用に(/oamsso/logout.html以外の値で)構成されている場合は、LogOutUrlパラメータの一部としても存在していることを確認してください。

関連項目:

外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

11g Webgateの集中ログアウト構成方法

1. 登録方法の選択については、第13章「OAM 11gエージェントの登録および管理」を参照してください。

2. エージェント登録の作成や編集を行なう時は、使用環境に適したログアウト値を含めてください(表19-2)。

- ログアウトURL

- ログアウト・コールバックURL

- ログアウト・リダイレクトURL

- ログアウト・ターゲットURL

3. 通常どおりにエージェントの登録を完了して、保存します。

4. マルチDNSドメイン: Access Manager 11g SSO用に構成されたマルチDNSドメインがある場合は、次のステップを実行します。

注意:

Logout Callback URLは各Webゲートに固有のものにできますが、各Webゲートに対してLogout Callback URLを作成するには、OAMサーバーに対して各ドメインの各Webゲートのホストとポートを指定するだけで十分です。Logout Callback URLが参照するファイルは、Webゲートのインストール・ディレクトリにあるlogout.htmlスクリプトとは異なるものでなければなりません。

1. Logout Callback URLを、各リソースWebゲート上のlogOutUrlsパラメータの2つ目の値として構成します。
Logout Callback URLは、ドメイン内のSSO Cookieを消去するためのリクエストを送る必要があるWebゲート上の場所です。Logout Callback URLをlogout.htmlにできません。

2. ファイルが、Logout Callback URLで示される場所(通常はlogout.htmlと同じ場所)にある各Webサーバー上に物理的に存在していることを確認します。
たとえば、logout.htmlと同じ場所にlogout.pngという名前のファイルを構成する場合、logout.pngのLogout Callback URLの値は次のようになります。

/oamsso/logout.png

5. 「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。

19.3.2 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

DCCは、エージェントからログアウト・リクエストを受信すると、次の処理を実行します。

- 必要に応じて、ログアウト・リクエストを復号化します。

- end_urlを取得し、必要に応じてエージェントのhost:portを使用して完全なURLを作成します。

- DCC Cookieを消去します(DCCCtxCookie)。

- ログアウト・リクエストをバックチャネル経由で送信して、セッションを終了します。

- Logout Callback URLLogout Callback URLsにより、訪問したすべてのエージェントへのリンクを含むログアウト・ページを、この情報を保持しているOAMサーバーから取得するか、ログアウト・ページをローカルに作成するために、OAMサーバーから訪問者のリストのみを取得し、DCC上のこのページにユーザーをリダイレクトします。

- ログアウトが完了したら、end_urlに戻ります。

DCCとは別のリソースWebゲートのログアウトを構成するには:

1. DCCログアウト用のPerlスクリプトに、WebゲートのホストのWEBGATE_HOME/oamsso-bin/*pl上にある、Perlの実行可能ファイルの実際の場所が含まれていることを確認してください。

2. リソースWebゲート: DCCのlogout.plをポイントするように、「ログアウト・リダイレクトURL」を変更します。

1. リソースWebゲート登録の検出: 「OAMエージェント登録の検索」を参照してください。

2. DCCのlogout.plをポイントするように、「ログアウト・リダイレクトURL」を変更します。例:
http://DCCWGhost:port/oamsso-bin/logout.pl

注意:

DCCは、Webゲート登録ページ内の「ログアウト・リダイレクトURL」パラメータを無視します。ただし、リソースWebゲートの「ログアウト・リダイレクトURL」がlogout.*以外の場合、そのURLはDCCの「ログアウト・リダイレクトURL」で定義されている必要があります。表16-27「認証用の資格証明コレクタと関連フォームの指定」を参照してください。

3. 「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。

19.4 グローバル・サインオンと集中ログアウトの検証

この項の内容は次のとおりです。

- グローバル・サインオンの確認

- 様々なエージェント・タイプを使用したグローバル・サインオンの検証

- 集中ログアウトの監視

19.4.1 グローバル・サインオンの確認

シングル・サインオンによるグローバル・ログインの監視には以下の手順を使用します。

前提条件

- エージェントとサーバーがAccess Managerによって登録され、実行されていなければなりません。

- Access Managerアプリケーション・ドメイン内で、SSOを制御するリソースとポリシーを定義する必要があります。

グローバル・サインオンの監視方法

1. ブラウザから、保護されたリソースのURLを入力します。

2. ログイン・ページで、正しい資格証明を使用してサインインします。

3. リソースが提供されることを確認します。ログアウトはしないでください。

4. 同じブラウザ・ウィンドウで、別の保護されたリソースのURLを入力し、再認証を求められずにそのリソースが提供されることを確認します。

19.4.2 混在するエージェント・タイプを持つグローバル・サインオンの検証

以下の手順を使用して、同じ認証レベルを持つ様々なアプリケーションとエージェントによるシングル・サインオンによるグローバル・ログインを監視します。

たとえば、以下の場所に以下のパートナーがあるものとします。

- OSSOパートナー、http://host1.example.com:7777/private/index.html、mod_ossoを使用して保護

- Webgateパートナ、http://host2.example.com:8888/mydomain/finance/index.html、OAMエージェントを使用して保護

同じブラウザ・セッション内で、1回のサインインにより、どちらかのエージェントによって保護されたすべてのアプリケーションにアクセスすることができます。

前提条件

- エージェントとサーバーがAccess Managerによって登録され、実行されていなければなりません。

- Access Managerアプリケーション・ドメイン内で、リソースとポリシーを定義する必要があります。

- どちらのパートナーも、同じ認証レベルで保護されていなければなりません。

- この章の説明に従ってシングル・サインオンが構成されていなければなりません。

様々なエージェント・タイプによるグローバル・サインオンの監視方法

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. 保護されたリソースを使用できることと、ログイン・ページが表示されないことを確認します。

19.4.3 集中ログアウトの監視

以下の手順を使用して集中ログアウトを監視します。

- OAMエージェントの場合はログアウトURLがサーバーへのリダイレクトを行い、その後の要求によってCookieが特定されないようにCookieが消去されて無効化されます。

- mod_ossoの場合は、各エージェントがそのCookieを破棄します。ログアウトURLがサーバー上のグローバル・ログアウト・ページへのリダイレクトを行い、各パートナーがそのサーバーにCookieを送ります。

前提条件

- エージェントが登録されて実行されていなければなりません。

- リソースはAccess Managerアプリケーション・ドメインによって保護されている必要があります。

- シングル・サインオンは、Access Managerアプリケーション・ドメイン内で、認証および認可のためのポリシーと応答によって構成されている必要があります。

集中ログアウトの監視方法

1. 1つのアプリケーション:

1. ブラウザから、保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 保護されたリソースを使用できることを確認します。

4. 新しいブラウザ・タブまたはウィンドウを開いて同じリソースにアクセスし、2回目のアクセス時に新たなログインが要求されないことを確認します。

5. 1つのタブからログアウトします。

6. もう一度そのリソースにアクセスして、ログイン・ページが表示されることを確認します。

2. 2つのアプリケーション:

1. ブラウザから、保護されたリソースのURLを入力します。

2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

3. 新しいタブまたはウィンドウで、別の保護されたアプリケーションにアクセスし、2つ目のアプリケーションで新たなログインを要求されないことを確認します。

4. 1つ目のアプリケーションからログアウトします。

5. 2つ目のアプリケーションにアクセスして、ログイン・ページが表示されることを確認します。

第VI部

Access Managerを使用したレガシー・エージェントの登録および使用

Oracle HTTP Server以外のWebサーバー・タイプがある企業では、10g WebgateをインストールしてAccess Managerで使用できます。

第VI部の内容は次のとおりです。

- 第20章「レガシーOpenSSOエージェントの登録および管理」

- 第21章「レガシーOSSOエージェントの登録および管理」

- 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」

- 第23章「Apache、OHS、IHSの10g Webgate用の構成」

- 第24章「10g Webgate用のISAサーバーの構成」

- 第25章「10g Webgate用のIIS Webサーバーの構成」

- 第26章「10g Webgate用のLotus Domino Webサーバーの構成」

20 レガシーOpenSSOエージェントの登録および管理

既存のOracleデプロイメントにOpenSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、これをソリューションとして引き続きサポートします。また、Access Managerで使用するために、既存のOpenSSOエージェントを登録することもできます。

この章では、Access Manager 11.1.2で使用するためにレガシーOpenSSOエージェントを登録または管理する方法について説明します。この章の内容は、次のとおりです。

- OpenSSO、エージェント、移行および共存の概要

- OpenSSOエージェントとAccess Manager間の実行時の処理

- OpenSSOエージェント登録パラメータの理解

- コンソールを使用したOpenSSOエージェントの登録および管理

- OpenSSOエージェントのリモート登録の実行

- 登録済OpenSSOエージェントのリモート更新

- その他のOpenSSOエージェントの情報の参照先

20.1 OpenSSO、エージェント、移行および共存の概要

OpenSSOは、Sun Access Management、Federation Management、Web Services Security製品のオープン・ソース・バージョンです。各OpenSSOエージェントは、アプリケーションをホストするコンテナ(Oracle WebLogic Server、JBoss、Apacheなど)にプラグインされるフィルタです。

OpenSSOエージェントは、Webゲート、アクセス・クライアントまたはOSSOエージェントと共存できます。Oracleは、既存のOpenSSOエージェント、プロファイルおよびポリシーをAccess Managerに移行するために使用できるOpenSSO評価ツールおよびOpenSSO移行ツールを提供しています。

関連項目:

OpenSSOエージェント、プロファイルおよびポリシーを評価し、Access Managerに移行するためのOracle提供のツールおよびプロセスの詳細は、Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイドを参照してください。

各OpenSSOエージェントは、アプリケーションに対するリクエストを捕捉することで、これらのアプリケーションへのアクセスを制限します。プロビジョニング後、OpenSSOエージェントはOpenSSOサーバーのかわりにOAMサーバーを使用するようになります。

注意:

OpenSSOエージェントを、OpenSSOサーバーではなく、OAMサーバーで使用するには、Access Managerに登録する必要があります。

プロビジョニング後、OpenSSOエージェントはOpenSSOサーバーのかわりにOAMサーバーを使用するようになります。アプリケーションへの制限付きアクセスは、それらのアプリケーションへのリクエストを捕捉することで実現します。OAMサーバーは、エージェントとOAMサーバー間の通信を可能にするOpenSSOプロキシを提供し、エージェント保護のアプリケーションに対するSSOを円滑化します。

OAMサーバーは、エージェントとOAMサーバー間の通信を可能にするOpenSSOプロキシを提供し、エージェント保護のアプリケーションに対するSSOを円滑化します。登録済のOpenSSOエージェントを使用すると、Access Managerは、表20-1に示した機能(認証機能および認可機能のサブセット)を提供します。

表20-1 機能: Access Managerを使用するOpenSSOエージェント

エージェント認証

ユーザー認証

ユーザー・シングル・サインオン

ユーザー・シングル・ログアウト

エージェントが混在する場合のSSO(OpenSSOエージェントとWebGateエージェント)

ユーザー認可

自己およびサブツリー・モードの検索

ポリシー条件(アイデンティティ、LDAPフィルタ、セッション属性、IP範囲、一時的)

ユーザー・プロファイル属性の取得

RESTリクエストまたはレスポンスによる一元化されたエージェント構成

エージェント・プロファイル、ポリシー、ユーザー・ストア、認証ストアの移行

移行評価ツール

詳細は、次を参照してください。

- OpenSSOとAccess Managerの間の移行と共存について

- OpenSSOエージェントのAccess Managerへの依存について

- OpenSSOエージェントとAccess Manager間の実行時の処理

20.1.1 OpenSSOとAccess Managerの間の移行と共存について

Access Managerは、OpenSSOからAccess Managerへのアップグレード・ツールを使用して移行した、既存のOpenSSOサーバー・デプロイメントとの共存をサポートしています。

OpenSSOからAccess Managerへのアップグレードでは、次のトピックに示す要件を満たすOpenSSO検出エージェントとポリシー・マッピング・ロジックが使用されます。

- OpenSSOポリシー移行

- OpenSSO移行時のアプリケーション・ドメインの作成

- OpenSSO認証ポリシー移行

- Access Managerでのホスト識別子の作成

Access ManagerおよびOpenSSOのシステム要件とサポートされたプラットフォームについては、次のサイトにあるOracle IdentityとAccess Managementのマトリックスを参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

関連項目:

Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

OpenSSOポリシー移行

OpenSSOポリシーは、OpenSSOデプロイメントで使用可能なアーティファクトに基づいて、Access Managerの認証および認可ポリシーにマップされます。表20-2は、ポリシー移行時にOpenSSOとAccess Managerとの間で実行されるマッピングの概要を示しています。

関連項目:

移行されるアーティファクト: OpenSSO

表20-2 OpenSSOポリシー移行

番号

OpenSSO

Access Manager

1

ポリシー・レルム

ポリシー・ドメイン

2

ポリシー

認証および認可ポリシー

3

リソース

リソースとホスト識別子

4

アクション

指定なし(デフォルトでは「GET」のみ)

5

サブジェクト

認可ポリシーのアイデンティティ条件

6

条件

認証スキームと認可条件

7

レスポンス・プロバイダ

ポリシー・レスポンス

OpenSSO移行時のアプリケーション・ドメインの作成

既存のAccess Managerアプリケーション・ドメインおよびポリシーがOpenSSOポリシー・ドメインと一致しない場合、Access Managerに新しいアプリケーション・ドメインが作成されます。作成されたアプリケーション・ドメインはOpenSSOレルムに対応します。各レルム(OpenSSOの最上位レルムとサブレベル・レルム)について、アプリケーション・ドメインがAccess Managerに作成されます。

既存のすべてのアプリケーション・ドメインがOpenSSOポリシー・ドメインと比較されます。既存のすべてのポリシーに対してポリシー名がチェックされます。同じ名前のポリシーが存在する場合、エラーが発生します。それ以外の場合は、Access Managerに新しいポリシーが作成されます。

注意:

OpenSSOポリシーの参照ポリシーは移行されません。

OpenSSO認証ポリシー移行

有効なルールと条件を含むOpenSSOポリシーは、Access Manager認証ポリシーに移行されます。これは、新規ポリシーが作成されるか既存のポリシーが更新されるかのどちらかです。ポリシーの作成時には、OpenSSOポリシー・ルールのhost:port情報を使用して、ホスト識別子とアプリケーション・ドメインへの正確なリソースURL (またはURI)が作成されます。

注意:

ルールのないアーティファクトを含むOpenSSOポリシーは有効なポリシーではありません。

条件付きのポリシーは、OpenSSOに対して有効です。ただし、これらはAccess Managerのデフォルトの認証ポリシーに基づいて移行されます。IPまたは一時条件のあるポリシーは、Access Manager認可ポリシー条件に移行することができます。

OpenSSOポリシーが非参照ポリシーの場合、作成されるAccess Manager認証ポリシーには、対応するOpenSSOからの認証モジュール、ホスト識別子、OpenSSOポリシーからのリソースによる認証スキームが含まれます。Access Manager認可ポリシーでは、対応するOpenSSOの制約とサブジェクトが設定されます。

制限: (同じアプリケーション・ドメインまたはレルム内のいずれかのポリシーに)リソースがすでに存在している場合、認証ポリシーの作成には例外が発生します。リソースが別のポリシーによってすでに保護されている(ホスト識別子の下にすでに存在している)場合、同じリソースに対して新しいポリシーを作成すると、例外が発生します。この新しいポリシーは作成されません。エラーはログ・ファイルに記録され、Oracle Access Managementコンソールにも表示されます。

Access Managerでのホスト識別子の作成

Access Manager内では、OpenSSOによる一意のhost:portの組合せ1つに対して1つのホスト識別子が作成されます。各レルムの各ポリシー・ルールからすべてのhost:portを取得する必要があります。これにより、一意のhost:portの組合せと同じ数だけhostIdentifierが作成されます。

最上位レルム: デフォルトでは、OpenSSOには最上位レルム(/)は1つしかありません。その他のレルムはすべて、この最上位レルムの下に作成できます。理論的には、Access Managerでホスト識別子を作成するhost:portの組合せはすべて最上位レルムに含まれることになります。

サブ・レルム: サブ・レルム内のポリシー・ルールにあるhost:portの組合せは、最上位レルムの下に作成される参照ポリシー内のhost:portに依存します。参照ポリシー内のhost:portは、最上位レルムの他の非参照ポリシー内のhost:portによるものとは限りません(さらに、参照ポリシーは移行に適していません)。したがって、サブ・レルムのポリシーにあるhost:portは、移行に適している最上位レルムのポリシーにあるhost:portとは異なる場合があるため、各レルムのポリシーのhost:portが確認されます。

制限: OpenSSOでは、同じリソースを保護するためにルールは同じであるものの認証スキームが異なる2つ(以上)のポリシーが存在する場合、1つだけ(最初に出現したもの)をAccess Managerに移行できます。それ以外は無視され、Access Managerには作成されません。ただし、このようなことが発生するのは非常に稀です。

20.1.2 OpenSSOエージェントのAccess Managerへの依存について

Access Managerは、表20-3に示すOpenSSOエージェントと処理をサポートしています。

表20-3 OpenSSOのAccess Managerへの依存

コンポーネント

説明

OpenSSOエージェント

自己認証によって信頼性を確立するには、OpenSSOエージェントがAccess Managerに登録されていなければなりません。OAMサーバーは次の処理を行います。

- 提供された資格証明によってエージェントを認証します。

- エージェントのセッションを作成します。

- この情報をキャッシュに保存して、グループ/クラスタ内の任意のサーバーがエージェントからの次のリクエストを処理できるようにします。

- セッション識別子をエージェントに渡し、その後の相互作用中にこれをOAMサーバーに提示できるようにします。

このエージェント・セッションには有効期限がないので、エージェントはOAMサーバーとの信頼性を継続して維持することができます。

エージェント登録は有効または無効にすることができます。無効にすると、エージェントは応答しなくなります。

複数のOpenSSOエージェントが一元化された同じ構成を共有できます(必要時、集中型構成モードで登録されている場合)。その場合でも、各エージェントには独自の一意のセッションおよびセッションIDがあります。エージェント登録では、登録ごとの「許容されるエージェント・セッションの最大数」を構成できます。

エージェントのセッションが期限切れになるかどうかを定義する、セッション・タイムアウト・プロパティが存在する場合もあります。

関連項目:

「コンソールを使用したOpenSSOエージェントの登録および管理」

「Access Manager資格証明コレクションおよびログインの概要」

OpenSSOプロキシ

このOracle提供のプロキシは、Access Manager 11.1.2にバンドルされ、ともにインストールされます。OpenSSOプロキシは、OpenSSOエージェントとOAMサーバーとの間の通信を可能にします。OpenSSOプロキシは、認証、認可、SSOに関するすべてのOpenSSOエージェントのリクエストとレスポンスを処理します。OpenSSOプロキシは、プロトコル・バインディングとメッセージ(リクエストまたはレスポンス)変換機能を提供します。

関連項目: 「OpenSSOエージェントとAccess Manager間の実行時の処理」

プロトコル・バインディング・レイヤー

このOracle提供のフレームワークは、エージェント固有のプロトコル処理と認証プロトコル・メッセージのマッピングを実行します。また、このフレームワークは、受信したプロトコル固有のリクエストをプロトコルに依存しないリクエストにアンマーシャリングしたり、プロトコルに依存しないレスポンスをプロトコル固有のレスポンスにマーシャリングします。

パートナおよびトラスト・ストア

OpenSSOエージェントの一元化された構成を格納します。Access Managerのパートナおよびトラスト・ストアは、エージェントIDとエージェント・パスワードに関するGET APIを提供することで、エージェント認証もサポートします。

OpenSSOアプリケーション・ドメイン

OpenSSOエージェントの登録時に「ポリシーの自動作成」オプションを使用することで、自動的に生成できます。

Cookie

エンド・ユーザーの持つ有効なCookieは次のとおりです。

- OAM_ID cookie (エージェント認証後のエンド・セッションを表します)。次を参照してください。

- OpenSSO Cookie (OpenSSOプロキシがセッションの検証をトリガーした後に、エージェントがこのCookieを検出します)。OpenSSO cookieのデフォルト名は次のとおりです。
iPlanetDirectoryPro

保護されたリソースの認可ポリシー

認可ポリシーは次の条件を使用して設定します。

- 「IP範囲」条件: 指定した範囲のIPアドレスのみにアクセスできるようにします。

- 「一時的」条件: 指定した期間のみアクセスできるようにします。

- 「アイデンティティ」条件: 構成済のアイデンティティ(ユーザーまたはグループ)のみが保護されたリソースにアクセスできるようにします。

- 「LDAPフィルタ」条件: フィルタ条件を満たす場合のみアクセスできるようにします。

- セッション属性条件: セッションのセッション属性が必要な値で構成されている場合のみ、アクセスできるようにします。

- ネームスペースのリクエスト、ユーザー、セッションの属性条件: 属性が必要な値で構成されている場合のみアクセスできるようにします。

SSOコントローラ

機能コンポーネント(SSOエンジンや認証エンジンなど)を呼び出すことでプロトコル・リクエストを実行します。

SSOエンジン

オンライン・セッション時に、エンタープライズおよび同レベルのドメイン・サインオンとシングル・ログアウト(SLO)を提供します。

セッション・ライフサイクルを管理します。有効なセッション内のすべてのリライイング・パーティ間のログアウトを編成することで、グローバル・ログアウトを実行します。トークン処理エンジンと通信して、有効なエンジンを作成し、ユーザーを永続化します。

セッション管理エンジン

ユーザーおよび管理者が開始するタイムアウト・ベースのイベントのサポートによって、セッションおよびトークン・コンテキストの情報を管理します。SSOエンジンは、セッション管理エンジン機能を使用してセッションを管理します。

- セッション作成

- セッションの読取り

- セッションの更新

- セッションの削除

- セッションの検証

- セッションIDの取得

- 作成時間の設定/取得

- 有効期限時間の設定/取得

- 最終アクセス時間の設定/取得

- セッション状態の設定/取得

- セッションのパージ

注意: Oracle Access Managementコンソールを使用してOpenSSOエージェント・セッションを表示または管理することはできません。必要に応じて、OpenSSOエンジン・コントローラ・レイヤーが適切なセッション管理インタフェースを呼び出します。セッション・マネージャはエージェント・セッション・キャッシュ・マネージャを内部的に呼び出し、エージェント・セッション用の分散キャッシュを管理します。

登録されたOpenSSOエージェントごとに一意のセッションが作成され、これがエージェントとOAMサーバー間の信頼メカニズムとなります。一意のセッションIDには、ユーザー・リクエストを処理する前にOAMサーバーによって検証する必要のあるエージェント・トークンとして、セッション検証やユーザー認可などに関するすべてのXML/HTTPリクエストが付随しています。

デフォルトでは、エージェント・セッションには有効期限がありません。エージェント・セッションはメモリー内のセッション・キャッシュに格納されます。OAMサーバーを再起動する場合、エージェント・セッションを保持する必要はありません。

エージェント・セッションはOAMサーバーに存在しており、一意のエージェント・セッションIDが使用可能な形式でエージェントに戻されます。エージェント・セッションは、「無効」(未認証)と「有効」(認証済)の2つの状態をサポートしています。OAMサーバーが正常に通信できるのは、「有効」なセッション状態のエージェントに対してのみです。

トークン処理エンジン

トークン発行および検証プロトコル・リクエストに応じて、トーク生成とトークン検証を実行します。デフォルト機能では、ユーザー名、SAML、およびX509トークンを管理(発行、検証、更新、キャンセル)します。デフォルトでサポートされているすぐ使用可能なセキュリティ・トークン・タイプの範囲を超えて、カスタム・トークンを処理できるように機能を拡張することもできます。

Oracle Access Managementコンソール

管理者はコンソールを使用して次の処理を行います。

- OpenSSOエージェントのプロビジョニング/登録。

- 保護されているリソースに対するアプリケーション・ドメイン、認証および認可ポリシーの管理。

リモート登録ユーティリティ

管理者はリモート登録ユーティリティを使用して、エージェントをプロビジョニングし、集中型モードでエージェントが使用する構成ファイルを生成することができます。エージェントは必要なすべての構成情報のコピーを持っているので、このためにOAMサーバーにアクセスすることはありません。

注意: OpenSSOエージェント・プロファイルをAccess Managerに移行する場合、ローカライズ・モードと集中モードの両方がサポートされます。

WLSTコマンド

管理者はWLSTコマンドを使用して次の処理を行うことができます。

- OpenSSOエージェントのOAMサーバーへの移行。

関連項目: 「移行されるアーティファクト: OpenSSO」。

20.2 OpenSSOエージェントとAccess Manager間の実行時の処理

OAMサーバーには、OpenSSOエージェントとの通信を処理するOpenSSOプロキシが組み込まれているため、OpenSSOサーバーとの相互運用性が簡単になります。たとえば、OpenSSOポリシー・エージェントとOAMサーバーとの間でのシングル・サインオン(SSO)とシングル・サインアウト(SLO)があげられます。相互運用性は、エンドユーザー認証でHTML/HTTP認証リクエストを(HTTPリダイレクトとして)参照し、エンドユーザー・セッションの検証でXML/HTTP SSOリクエストを参照することによって、実現されます。

図20-1は、OpenSSOとAccess Managerが含まれるデプロイメントを示しています。OpenSSOエージェントは、Web/Java EEコンテナおよび保護されているリソースとともに存在します。OpenSSOサーバーは、別のホストに存在します。

図20-1 OpenSSOとAccess Managerが含まれる一般的なデプロイメント

「図20-1 OpenSSOとAccess Managerが含まれる一般的なデプロイメント」の説明

表20-4は、Access ManagerとOpenSSOエージェント間のSSO処理についての説明です。

表20-4 Access ManagerによるOpenSSOの処理

機能

説明

OpenSSOエージェント認証

ユーザー認証の前に、OpenSSOエージェントが認証されて有効なエージェント・セッションが確立されます。

OpenSSOエージェントは、OAMサーバーに対してOpenSSOプロキシ経由で自身を認証します。

OpenSSOエージェント認証(エージェントがOpenSSOプロキシに対して自身を認証)は、エージェント・タイプに基づいて次のように行われます。

J2EEエージェント: エージェント・コンテナ起動時。
Webエージェント: Webサーバーに対する最初のユーザー認証リクエストによる。

1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースにアクセスするリクエストを送信します。

2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるために次のようにOAMサーバーにリダイレクトします。
J2EEエージェント: エージェント・コンテナ起動時。
Webエージェント: Webサーバーに対する最初のユーザー認証リクエストによる。

3. エージェントは、ネーミング・リクエストをプロキシに送信し、他のすべてのサービスURL (認証サービス、セッション・サービスなど)をフェッチします。

4. エージェントは、xml認証リクエストを認証サービス・エンドポイントでの資格証明(手順3でネーミング・リクエストにより取得)とともにプロキシに送信します。

5. プロキシは、エージェント認証モジュールに対してエージェントを認証し、プロキシ・レイヤー自体に無期限セッションを作成します。

6. プロキシは、httpを介して、認証xmlレスポンスをエージェント・セッション詳細とともにエージェントに送信します。

エージェントが認証されると、有効なエージェント・セッションが作成されます。エージェント認証の後に生成されるキーは、パートナおよびトラスト・ストアに格納されます。

SSOユーザー・ログインおよび認証

エージェントがOAMサーバーにより認証された後、ユーザー・リクエストがOAMサーバーにより認証されます。SSOはその後、エージェントにより保護されているリソースにアクセスする認証済ユーザーに提供されます。

OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを確認します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。

ユーザー・ログイン

1. OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉します。OpenSSOエージェントは、ユーザーがOpenSSO Cookieを持っているかどうかをチェックします。持っていない場合、OpenSSOエージェントは、ユーザーを認証サービスを得るためにOpenSSOプロキシにリダイレクトします。OpenSSOプロキシは、リクエストされたリソースURLおよびエージェントIDを捕捉します。

2. OpenSSOプロキシのOpenSSOログイン・イベントは、コア・ログイン・イベントで処理できるように、このリクエストをラップします。OpenSSOログイン・イベントは、リソースURLおよびエージェントIDをコア・ログイン・イベントに渡します。

3. コア・ログイン・イベントが実行され、リクエスト・オブジェクトにOAM_ID Cookieが含まれるかどうかをチェックします。含まれている場合、OAMサーバーは、OAM_ID Cookieで表されるセッションが有効なセッションかどうかをチェックします。

4. OAM_ID Cookieで表されるセッションが有効な場合、コア・ログ・イベントからログイン・レスポンス・イベントが返されます。これはOpenSSOログイン・イベントでラップされ、OpenSSOログイン・レスポンス・ハンドラに渡されます。コア・ログイン・イベントは、検証されたセッションの識別子を返します。

5. OpenSSOログイン・レスポンス・ハンドラ(OpenSSOプロキシに含まれます)は、OpenSSOエージェントが理解できる形式でOpenSSOセッション識別子を作成し、OAMセッション識別子を使用して拡張します。OpenSSO Cookieが作成され、ユーザーのブラウザに設定されます。このCookieにはOpenSSOセッション識別子が含まれます。

エンド・ユーザー・セッションの検証

OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉します。

エンド・ユーザー・セッションの検証

1. OpenSSOエージェントは、保護されたアプリケーションへのリクエストを捕捉し、OpenSSO Cookieを検出します。

2. OpenSSOエージェントは、このOpenSSO Cookieを検証するためのXML/HTTPリクエストを作成します。このXMLリクエストには、アプリケーション/エージェント・トークンIDおよびセッションIDが含まれます。このリクエストは、OpenSSOプロキシ・レイヤーに届きます。

3. OpenSSOプロキシはリクエストに関連付けられたアプリケーション・トークンを取得し、アプリケーション・トークンをOAMサーバーを使用して検証します。

4. OAMサーバーは、トークンを検証し、レスポンスをOpenSSOプロキシに送信します。

5. アプリケーション・トークンが無効な場合、OpenSSOプロキシはそのことをOpenSSOエージェントに通知し、OpenSSOエージェントは有効なアプリケーション・トークンを取得するためにエージェント認証フローを開始します。

6. アプリケーション・トークンが有効な場合、OpenSSOプロキシはOpenSSO Cookieを復号化して、OpenSSOセッションIDをフェッチし、OpenSSOセッションIDに拡張として格納されているOAMセッションIDを取得します。

7. OpenSSOプロキシは、セッション検証フローをトリガーします。

8. OAMセッションIDで表されるセッションが有効な場合、OpenSSOプロキシはそのことをエージェントに通知し、保護されているアプリケーションがユーザーに表示されます。このセッション検証では、セッション・データを、セッション検証イベント・レスポンスの出力としてプロキシ・レイヤーに返します。

9. セッションが無効な場合、OAMサーバーが認証フローを開始し、ユーザー資格証明を収集してユーザーを検証します。

Webエージェント・タイプのユーザー・プロファイル属性の取得

ユーザーがログインに成功して、有効なセッションが作成されると、OpenSSOエージェントは、セッションIDを渡すことによって、ユーザー・プロファイル属性をリクエストできます。OpenSSOプロキシ・レイヤーは、このリクエストを受信し、OpenSSOセッションID拡張からOAMセッションIDをフェッチする必要があります。OpenSSO Webエージェントは、これらのリクエストにポリシー・サービスURLを使用します。

OpenSSOプロキシは、これらの属性をフェッチしてセッションIDをOAMサーバーに渡します(OAMサーバーはレスポンス・フレームワークを使用してユーザー・プロファイル属性をフェッチし、データをOpenSSOプロキシに返します)。

J2EEエージェント・タイプのユーザー・プロファイル属性の取得

OpenSSO J2EEエージェントは、jax-rpcコールを使用して、ユーザー・プロファイル属性を取得します。フローは、Webエージェント・タイプの場合のこれらのプロパティを取得するフローと同様です。

ユーザー・シングル・ログアウト

1. OpenSSOプロキシは、ユーザー・ログアウト・リクエストを受信すると、ユーザーをOAMログアウトURLに転送します。

2. OpenSSOプロキシはOpenSSO Cookieを復号化して、OpenSSOセッション識別子をフェッチし、そこからOAMセッションIDをフェッチします。OpenSSOプロキシは、ログアウト・リクエストをOAMセッションIDとともに、OpenSSOログアウト・イベントを介して、コントローラに送信します。

3. コア・ログアウト・イベントが実行され、コントローラ・コールによりセッションが存在することをSSOエンジンに確認します。セッションが存在する場合、OAM_ID Cookieが削除され、グローバル・ログアウトが実行されます。

4. SSOエンジンは、セッションが消去されたことを示すレスポンスをコントローラに返します。

5. コントローラは、プロキシにトークン消去リクエストを送信します。

6. プロキシは、トークン消去リクエストを、OpenSSOログアウト・レスポンス・ハンドラを介して、エージェントに送信します。

SSOエージェント・ログアウト

Access Managerは、OpenSSOエージェントから送信されたシングル・ログアウト・リクエストを処理します。

注意: ユーザーは、他のエージェント(たとえば、WebゲートやMOD_OSSO)によって保護されているリソースからログアウトする必要があります。マルチドメイン環境以外では、エージェント・ログアウトは必要ありません。

1. OpenSSOエージェントは、OpenSSOプロキシにログアウトをリクエストします。

2. プロキシは、リクエストからアプリケーション・トークンをフェッチし、リクエストが認証済エージェントから送信されていることを検証します。

3. Openssoエージェント・ログアウトは、独立したエージェント・セッション管理モジュールでセッションが作成されるため、プロキシ内部で処理されます。

4. 復号化されたトークンがOpenSSOプロキシに返されます。OpenSSOトークンが存在しない場合、手順2と3は行われません。

5. OpenSSOプロキシのOpenSSOログイン・イベントは、コア・ログイン・イベントで処理できるように、このリクエストをラップします。

6. コア・ログイン・イベントが実行され、リクエストをコントローラを介してSSOエンジンに転送し、ユーザーを認証します。認証されたユーザーのための新しいセッションが作成されます。

7. コア・ログ・イベントからログイン・レスポンス・イベントが返されます。これはOpenSSOログイン・イベントでラップされ、OpenSSOログイン・レスポンス・ハンドラに渡されます。

8. OpenSSOログイン・レスポンス・ハンドラは、レスポンスをOpenSSOエージェントに送信します。

OpenSSOエージェントのトークン生成

Access Managerは、OpenSSOエージェント用に生成され、OpenSSOエージェントによって使用されるトークンを処理します。

ロギング

OAMサーバー・ログ・コンポーネントを使用して、次のイベントに対するエンド・ユーザー・アクセス実施中のイベントを追跡できます。

- ログイン成功およびログイン失敗イベント

- ログアウト成功およびログアウト失敗イベント

- 様々なロギング・レベル(FATAL、ERROR、WARNING、DEBUG、TRACE)のログ・メッセージ。降順でそれぞれが重大度を示しています。

監査

OAMサーバー監査コンポーネントを使用して、次を実行します。

- ログイン・イベントの監査

- ログアウト成功イベントの監査

ポーリング

ポーリングはサポートされていません。セッション破棄通知のみが、OpenSSOプロキシでサポートされています。

20.3 OpenSSOエージェント登録パラメータの理解

既存のOpenSSOエージェントをAccess Managerに移行する場合も、新しいOpenSSOエージェントを登録する場合も、Oracle Access Managementコンソールを使用すると、OpenSSOエージェントの管理と登録が一元化できます。

- OpenSSOエージェント登録パラメータについて

- 拡張されたOpenSSOエージェント・ページとパラメータについて

20.3.1 OpenSSOエージェント登録パラメータについて

図20-2に、「新規OpenSSOエージェント」ページを示します。管理者は新しいOpenSSOエージェントを登録する際に、このページで情報を入力します。

図20-2 「新規OpenSSOエージェント」ページ

表20-5では、「新規OpenSSOエージェント」ページの要素について説明します。

表20-5 「新規OpenSSOエージェント」ページの要素

要素

説明

エージェント・タイプ

OpenSSOエージェント・タイプは次のどちらかです。

- Web: WebリソースおよびWebリソースURLの場合に使用。

- J2EE: デフォルトのエージェント・タイプ。Java EEのリソースおよびアプリケーションの場合は、J2EEタイプのエージェントを使用します。
J2EEエージェントの場合は、次のどちらかを選択してフィルタ・モードを設定する必要があります。

SSO_ONLY (Access Managerの認証のみ): フィルタ操作の最新の制限モードを有効にします。エージェントは単純に、保護されたWebリソースにアクセスしようとするすべてのユーザーが認証されるようにします。

URL_Policy (Access Managerの認証および認可): エージェント・フィルタがURLポリシーを施行できるようにします。デフォルトでは、Webエージェントのcom.sun.identity.agents.config.sso.onlyattributeは「false」に設定されています。

注意: どちらのエージェント・タイプも、同時にSSOのみを選択した場合は、アクセスが保護されます。

エージェント名

このエージェントの一意の名前。

パスワード

パスワードの再入力 *

このOpenSSOエージェントの必須かつ一意のパスワードで、この登録プロセス中に割り当てられています。このエントリは不明瞭化された形式で、コンソール、oam-config.xml、OpenSSOAgentBootstrap.propertiesに表示されます。

登録されたエージェントがOAMサーバーに接続すると、ユーザーはパスワードの入力を求められます。パスワードにより、認証時に認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。

ホスト識別子

OpenSSOエージェントのホストおよびポートを識別する名前。

デフォルト: エージェント名

関連項目: 「仮想Webホスティングについて」

ベースURL

OpenSSOエージェントがインストールされているコンピュータのプロトコル、ホストおよびポート。

たとえば、http://host.example.domain.com:port or https://example.domain.com:portなどです。

ポリシーの自動作成

エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。エージェント名は、デフォルトで、アプリケーション・ドメイン名として使用されます。

デフォルト: 有効

関連項目: 「生成されるアーティファクト: OpenSSO」。

注意: Access Managerのアプリケーション・ドメインは、OpenSSOのレルムに対応します。アプリケーション・ドメインおよびポリシーがすでに存在する場合、単純に新しいリソースをそれに追加できます。このオプションを解除(チェックなし)すると、アプリケーション・ドメインやポリシーは自動的に生成されません。

OpenSSOエージェントのプロパティ

OpenSSOエージェントのプロパティは、次のファイルに格納されます。これらのファイルは、エージェントの登録時と構成の変更時に更新され、実行時に使用されます。

- OpenSSOAgentBootstrap.properties

- OpenSSOAgentConfiguration.properties

これらのファイルは、コンソール・ホスト(AdminServer)に格納されているため、表20-6に示すように、OpenSSOエージェントの/configディレクトリに再配置する必要があります。

表20-6 OpenSSOアーティファクトの再配置

AdminServer

OpenSSOエージェントの/configディレクトリ

$MW_HOME/Oracle_IDM1/oam/server/rreg/client/rreg/output

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/

Open SSOエージェント用に生成されるアプリケーション・ドメインの詳細は、「生成されるアーティファクト: OpenSSO」を参照してください。

20.3.2 拡張されたOpenSSOエージェント・ページとパラメータについて

この項では、拡張されたOpenSSOエージェント・ページについて説明します。このページは、Oracle Access Managementコンソールを使用してエージェントを管理するときに利用できます。

登録時には、プロセスを簡潔にするために、使用可能なパラメータのうち少数のサブセットのみが表示されます。Oracle Access Managementコンソールとリモート登録ユーティリティのどちらを使用してエージェントを登録していても、コンソールで完全なエージェントの構成ページを表示できます。デフォルト値は、このページに最初の登録後に移入され、エージェントのページを開いたときに表示されます(図20-3を参照)。

図20-3 拡張されたOpenSSO Webエージェント登録ページ

「図20-3 拡張されたOpenSSO Webエージェント登録ページ」の説明

J2EEエージェント登録ページの情報は、Webエージェントの詳細とほぼ同じです。J2EEエージェント登録ページを図20-4に示します。

図20-4 拡張されたOpenSSO J2EEエージェント登録ページ

「図20-4 拡張されたOpenSSO J2EEエージェント登録ページ」の説明

拡張されたOpenSSOエージェント登録ページのすべての要素については、表20-7で説明しています。

表20-7 拡張されたOpenSSOエージェント登録の要素

要素

説明

ステータス

このエージェント登録の状態: 「有効」または「無効」。

デフォルト: 有効

関連項目: 表20-5「「新規OpenSSOエージェント」ページの要素」

フィルタ・モード

J2EEエージェント・タイプのみ

エージェント・フィルタは、保護されているアプリケーション内にインストールされています。セキュリティ・ポリシーの施行を円滑化し、保護されているアプリケーション内のすべてのリソースへのアクセスを制御します。J2EEエージェントによって保護されるすべてのアプリケーションのデプロイメント・ディスクリプタを、エージェント・フィルタを使用するように変更する必要があります。この設定が行われていないアプリケーションは、J2EEエージェントによって保護されず、エージェント・レルムがインストールされているデプロイメント・コンテナにデプロイされた場合は正常に動作しなかったり使用できなくなったりする可能性があります。

J2EEエージェントの場合、フィルタ・モードに、SSO_ONLYまたはURL_Policyのどちらかのオプションを選択して設定する必要があります。

デフォルト: URL_Policy

- SSO_ONLY (Access Managerの認証のみ): フィルタ操作の最新の制限モードを有効にします。エージェントは単純に、保護されたWebリソースにアクセスしようとするすべてのユーザーが認証されるようにします。

- URL_Policy (Access Managerの認証および認可): エージェント・フィルタがURLポリシーを施行できるようにします。デフォルトでは、Webエージェントのcom.sun.identity.agents.config.sso.onlyattributeは「false」に設定されています。

プロセスの概要: 認証のみ(SSO_ONLY J2EEフィルタ・モード)

1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースへのアクセスをリクエストします。

2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。

3. 認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定し、ユーザーを元の保護されているリソースにリダイレクトします。

4. 有効なOpenSSOセッションを取得した認証済エンド・ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。

5. OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してOpenSSOセッションを検証し、エンド・ユーザーのSSOを有効にします。

6. エンド・ユーザーは、保護されているアプリケーションまたはリソースへのアクセスを取得します。

プロセスの概要: URL_Policy J2EEフィルタ・モードによる認証および認可

1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースへのアクセスをリクエストします。

2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。

3. 認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定し、ユーザーを元の保護されているリソースにリダイレクトします。

4. 有効なOpenSSOセッションを取得した認証済エンド・ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。

5. OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してOpenSSOセッションを検証します。

6. OpenSSOエージェントは、OpenSSOプロキシを介して、ポリシー・リクエストをOAMサーバーに送信し、認証ユーザーがリソースへのアクセスを認可されることを保証します。

7. OpenSSOプロキシは、(OAMポリシー・エンジンを使用して)保護されているリソースのポリシーを評価し、ポリシー決定としてAllowまたはDenyをエージェントに送信します。

8. ポリシー決定がAllowの場合、エンド・ユーザーはアクセスを取得します。

注意: フィルタ・モードとして「なし」、J2EE_Policy、「すべて」はサポートされていません。

関連項目: 「OpenSSOエージェント登録パラメータの理解」。

セッション・タイムアウト秒数(ユーザー)

矢印をクリックして期間を指定します。この期間を経過すると、セッションはタイムアウトして、ユーザーは再認証が必要になります。

デフォルト: 0

Cookie名

OpenSSO cookieのデフォルト名は次のとおりです。

デフォルト: iPlanetDirectoryPro

Cookieセパレータ

Cookieとして同じ属性の複数の値を設定する場合にセパレータとして使用する文字を定義します。たとえば、パイプ記号「|」を使用できます。

デフォルト:

Cookieのエンコードの有効化

J2EEエージェント・タイプのみ

Cookieのエンコードを有効にするかどうかを指定します。

デフォルト: 有効

SSOのみ

Webエージェント・タイプのみ

OpenSSOエージェントが、ブートストラップし、Access Managerによって提供されるOpenSSOプロキシを介してOAMサーバーで認証できるようにします。

エンド・ユーザーがOpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスすると、OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。

認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定して、ユーザーを元の保護されているアプリケーションまたはリソースにリダイレクトします。

有効なOpenSSOセッションを取得した認証済ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してセッションを検証します。

エンド・ユーザーは、Access Managerの認証ポリシーに基づいてアクセスを取得します。

URL

ログインURL

ログインURLを入力します。このURLには、適切なプロトコル(HTTPまたはHTTPS)、ホスト、ドメインおよびポートを次の形式で指定する必要があります。

http://example.domain.com:port

デフォルト: http://oamhost:port/opensso/UI/Login

注意: ポート番号はオプションです。

ログアウトURL

ログアウトURLは、ログアウト・ハンドラをトリガします。これにより、Access Managerで保護されているリソースにユーザーが次回アクセスする際に再認証が必要になります。

ログアウトURLを入力する場合、適切なプロトコル(HTTPまたはHTTPS)、ホスト、ドメインおよびポートを指定する必要があります。例:

http://example.domain.com:port/opensso/UI/Logout

デフォルト: http://oamhost:port/opensso/UI/Logout

注意: ポート番号はオプションです。ユーザーは、他のエージェント(たとえば、WebゲートやMOD_OSSO)によって保護されているリソースからログアウトする必要があります。マルチドメイン環境以外では、エージェント・ログアウトは必要ありません。

ポリシーを強制しないURL

Webエージェント・タイプのみ

このリストに入力するURLはポリシーを強制しません。これはパブリックURLと同等であり、保護されておらず、すべてのユーザーがアクセスできます。

アクセス拒否URI

ユーザーが、リクエストしたリソースへのアクセスが拒否された場合にリダイレクトされるURI。WebエージェントおよびJ2EEエージェントのどちらでも使用可能ですが、それぞれ次の形式で指定する必要があります。

Webエージェント(完全なURL): http://host:port/context/accessDeniedURL.html

J2EEエージェント(相対URI): /context/accessDeniedURL.htm

デフォルト: (空白)

監査

デバッグ・レベル

J2EEエージェント・タイプのみ

設定されている場合、OAMサーバーは次のメッセージをログに記録します。

- ログイン成功およびログイン失敗イベント

- ログアウト成功およびログアウト失敗イベント

- 複数のロギング・レベル(重大度の高い順にエラー、警告、メッセージ)のログ・メッセージ

デフォルト: エラー

関連項目: 第6章「コンポーネント・イベント・メッセージのロギング」

デバッグ・ディレクトリ

J2EEエージェント・タイプのみ

OAMサーバーの次の監査ログを格納するファイルシステム・ディレクトリ・パス。

- ログイン・イベントの監査

- ログアウト成功イベントの監査

関連項目: 第8章「管理イベントとランタイム・イベントの監査」

デバッグ・ファイル

Webエージェント・タイプのみ

ローカル・コンポーネントのイベント・ロギング・ファイルのファイルシステム・ディレクトリ・パスを定義します。

デフォルト:

ローカル・ログ・ファイル

ローカル・コンポーネントのイベント・ロギング・ファイルのファイルシステム・ディレクトリ・パスを定義します。

デフォルト:

ユーザー・マッピング

マッピング・モード

- HTTP_HEADER

- USER_ID

- PROFILE_ATTRIBUTE

- SESSION_PROPERTY

デフォルト: User_ID

ユーザー・アイデンティティ

デフォルト: ユーザーID

ユーザー属性名

デフォルト:

属性マッピング

属性取得は、アプリケーションが使用するHTTPリクエスト内ユーザー属性をフェッチおよび設定します。

次の「属性マッピング」パネルが用意されています。

- プロファイル属性

- レスポンス属性

- セッション属性

フェッチ・モード: 一部のアプリケーションは、ユーザー・リクエストを適切に処理するために、なんらかの形でユーザー固有のプロファイル情報が存在することを前提としています。ユーザーがプロファイル属性、レスポンス属性またはセッション属性で「フェッチ・モード」を指定すると、エージェントは様々な形のユーザーのプロファイルからこれらの属性を取得できます。

- なし: 属性はフェッチされません。

- HTTP_HEADER: HTTPヘッダーとしてLDAP属性を提供するようにエージェントが構成されている場合、これらの属性を取得できます。

- REQUEST_ATTRIBUTE: リクエスト属性としてLDAP属性を提供するようにエージェントが構成されている場合、エージェントはこれらの属性値を、後でアプリケーションが必要に応じて使用できる属性として、HttpServletRequestに移入します。たとえば、プロファイル属性をフェッチし、プロファイル属性プロパティにモードを割り当て、現在の認証済ユーザーに固有の名前で移入するプロファイル属性をマッピングします。

- HTTP_COOKIE: CookieとしてLDAP属性を提供するようにエージェントが構成されている場合、エージェントはパスを「/」と指定して、サーバー固有のCookieとして必要な値を設定します。複数値属性は、セパレータ文字を使用して属性のすべての値を単一文字列に連結することによって、単一Cookie値として設定されます。セパレータ文字は、Cookie Separatorプロパティで指定できます。

デフォルト:なし

プロファイル属性

ユーザー・プロファイル情報は、現在の認証済ユーザーに固有の名前で移入できます。例:

フェッチ・モード: REQUEST_ATTRIBUTE

名前(マップ・キー): cn

値: CUSTOM-Common-Name

名前(マップ・キー): mail

値: CUSTOM-Email

デフォルト: データなし

レスポンス属性

ポリシー・レスポンス属性をフェッチし、ポリシー・レスポンス属性プロパティにモードを割り当て、現在の認証済ユーザーに固有の名前で移入するポリシー・レスポンス属性をマッピングすることによって、ユーザー固有情報を取得します。

フェッチ・モード: REQUEST_ATTRIBUTE

名前(マップ・キー): cn

値: CUSTOM-Common-Name

名前(マップ・キー): mail

値: CUSTOM-Email_Addr

デフォルト: データなし

セッション属性

OAMサーバーによって保持されるセッション・オブジェクトの属性。これらはセッション検証レスポンスの一部としてエージェントに送信されます。

フェッチ・モード: REQUEST_ATTRIBUTE

名前(マップ・キー): UserToken

値: CUSTOM-userid

デフォルト: データなし

その他

大部分のエージェント・プロパティは、ホットスワップ可能です。構成プロパティを変更すると、予期しない結果が発生する可能性があります。ホットスワップ可能なプロパティは即時に有効になります。そのため、誤りも即時に実装されます。大部分のエージェント・プロパティは、Oracle Access Managementコンソールで構成するために最も便利な形式で提示されます。ただし、この形式は、OpenSSOAgentBootstrap.propertiesファイルでは使用されていません。

リスト・プロパティ: 一部のプロパティは、プロパティ名を表すキー、リストで値が指定されるたびに1ずつ増える(0から始まる)正数、および値で構成されるリストとして指定されます。例:

com.sun.identity.agents.config.notenforced.uri[0]=/agentsample/public/*
com.sun.identity.agents.config.notenforced.uri[1]=/agentsample/images/*
com.sun.identity.agents.config.notenforced.uri[2]=/agentsample/index.html

マップ構成: 一部のプロパティは、プロパティ名を表すキー、マップで使用できる参照キーを形成する名前文字列、およびマップで名前に関連付けられている値で構成されるマップ構成として指定されます。例:

com.sun.identity.agents.config.filter.mode[app1]=ALL
com.sun.identity.agents.config.filter.mode[app2]=SSO_ONLY

注意: 特定の構成キーに特定の名前を指定するエントリは、構成内で1つのみ指定できます。特定の構成キーで同じ<名前>のエントリが複数存在する場合、その中のいずれか1つの値のみがシステムにロードされ、それ以外の値は破棄されます。

アプリケーション固有のプロパティ: 一部のプロパティは、特定のアプリケーション向けに構成できます。エージェントは、構成ファイルで定義することによって、同じプロパティでアプリケーションごとに異なる値を使用できます。アプリケーション固有の構成プロパティは、マップ構成のルールおよび構文に従って記述する必要があります。次の単一プロパティの設定例は、ルート・コンテキストおよびコンテキスト/Portalにデプロイされているアプリケーションを除くアプリケーションでは、プロパティのデフォルト値がvalue3に設定されることを示しています。

com.sun.identity.agents.config.example[Portal] = value1
com.sun.identity.agents.config.example[DefaultWebApp] = value2
com.sun.identity.agents.config.example = value3

グローバル・プロパティ: 特定のアプリケーション向けに構成されていないプロパティは、デプロイメント・コンテナ上のすべてのアプリケーションに適用されます。そのようなプロパティは、グローバル・プロパティと呼ばれます。

シリアル番号: 自動的に割り当てられます。

名前: 次のいずれかを選択します。

値: 選択した名前に対する適切な値を入力します。

注意: OpenSSOエージェント構成のホットスワップを有効にするには、openssoエージェントが、OAMサーバー上のOpenSSOプロキシでエージェントのプロファイルの「その他」プロパティ・セクションに次のプロパティがあり、エージェント・サーバーが再起動されることを確認します。

J2eeエージェント: com.sun.identity.client.notification.url =http://<AGENT_SERVER_HOST>:<AGENT_SERVER_PORT>/agentapp/notification

Webエージェント:

com.sun.identity.client.notification.url =http://AGENT_SERVER_HOST:AGENT_SERVER_PORT/UpdateAgentCacheServlet?shortcircuit=false

サポート対象外、Webエージェント: com.sun.identity.agents.config.change.notification.enable = true

関連項目:

「OpenSSOブートストラップ構成マッピングの再確認」

要素

説明

関連項目:

表20-5「「新規OpenSSOエージェント」ページの要素」

ステータス

このエージェント登録の状態: 「有効」または「無効」。

デフォルト: 有効

フィルタ・モード

J2EEエージェント・タイプのみ

エージェント・フィルタは、保護されているアプリケーション内にインストールされています。セキュリティ・ポリシーの施行を円滑化し、保護されているアプリケーション内のすべてのリソースへのアクセスを制御します。J2EEエージェントによって保護されるすべてのアプリケーションのデプロイメント・ディスクリプタを、エージェント・フィルタを使用するように変更する必要があります。この設定が行われていないアプリケーションは、J2EEエージェントによって保護されず、エージェント・レルムがインストールされているデプロイメント・コンテナにデプロイされた場合は正常に動作しなかったり使用できなくなったりする可能性があります。

J2EEエージェントの場合、フィルタ・モードに、SSO_ONLYまたはURL_Policyのどちらかのオプションを選択して設定する必要があります。

デフォルト: URL_Policy

- SSO_ONLY (Access Managerの認証のみ): フィルタ操作の最新の制限モードを有効にします。エージェントは単純に、保護されたWebリソースにアクセスしようとするすべてのユーザーが認証されるようにします。

- URL_Policy (Access Managerの認証および認可): エージェント・フィルタがURLポリシーを施行できるようにします。デフォルトでは、Webエージェントのcom.sun.identity.agents.config.sso.onlyattributeは「false」に設定されています。

プロセスの概要: 認証のみ(SSO_ONLY J2EEフィルタ・モード)

1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースへのアクセスをリクエストします。

2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。

3. 認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定し、ユーザーを元の保護されているリソースにリダイレクトします。

4. 有効なOpenSSOセッションを取得した認証済エンド・ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。

5. OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してOpenSSOセッションを検証し、エンド・ユーザーのSSOを有効にします。

6. エンド・ユーザーは、保護されているアプリケーションまたはリソースへのアクセスを取得します。

プロセスの概要: URL_Policy J2EEフィルタ・モードによる認証および認可

1. エンド・ユーザーは、OpenSSOエージェントにより保護されているアプリケーションまたはリソースへのアクセスをリクエストします。

2. OpenSSOエージェントは、この非認証ユーザーを認証を受けるためにOAMサーバーにリダイレクトします。

3. 認証に成功すると、OpenSSOプロキシは、レスポンスCookieにOpenSSOセッションIDを設定し、ユーザーを元の保護されているリソースにリダイレクトします。

4. 有効なOpenSSOセッションを取得した認証済エンド・ユーザーは、OpenSSOエージェントによって保護されているアプリケーションまたはリソースにアクセスします。

5. OpenSSOエージェントは、OpenSSOプロキシを介して、OAMサーバーに対してOpenSSOセッションを検証します。

6. OpenSSOエージェントは、OpenSSOプロキシを介して、ポリシー・リクエストをOAMサーバーに送信し、認証ユーザーがリソースへのアクセスを認可されることを保証します。

7. OpenSSOプロキシは、(OAMポリシー・エンジンを使用して)保護されているリソースのポリシーを評価し、ポリシー決定としてAllowまたはDenyをエージェントに送信します。

8. ポリシー決定がAllowの場合、エンド・ユーザーはアクセスを取得します。

注意: フィルタ・モードとして「なし」、J2EE_Policy、「すべて」はサポートされていません。

関連項目: 「OpenSSOエージェント登録パラメータの理解」。

20.4 コンソールを使用したOpenSSOエージェントの登録および管理

このトピックの内容は次のとおりです。

- Oracle Access Managementコンソールを使用したOpenSSOエージェントの登録

- コンソールを使用した登録済OpenSSOエージェントの構成および管理

20.4.1 Oracle Access Managementコンソールを使用したOpenSSOエージェントの登録

Oracle Access Management管理者の資格証明を持つユーザーは、Oracle提供のツールを使用してOpenSSO環境を分析および移行することも、ここで説明するようにOracle Access Managementコンソールを使用して手動でOpenSSOエージェントをプロビジョニングすることもできます。

登録手順は、OpenSSOエージェント・タイプとしてWebまたはJ2EEのどちらを選択した場合も同じです。OpenSSOエージェントは、デプロイする前に登録できます。有効な管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access ManagementコンソールによりOpenSSOエージェントを登録できます。

注意:

新しいOpenSSOエージェントを作成する場合、サポートされているのは集中構成モードのみです。

エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、エージェントがフィルタ・モードとしてSSOのみを使用しているかぎり、動作を継続します。

前提条件

少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。エージェントを次の説明に従ってインストールします。

- Oracle Sun OpenSSOエンタープライズ・ポリシー・エージェント3.0 Webエージェント・ユーザーズ・ガイド

- Oracle Sun OpenSSOエンタープライズ・ポリシー・エージェント3.0 J2EEエージェント・ユーザーズ・ガイド

関連項目:

「OpenSSOエージェント登録パラメータの理解」

コンソールを使用してOpenSSOエージェントを登録するには:

1. Oracle Access Managementコンソールで「新規OpenSSOエージェント」リンクをクリックします。
「ようこそ」ページ
「SSOエージェント」パネル
「新規OpenSSOエージェント」リンク

または、「システム構成」タブの「Access Manager」セクションで「SSOエージェント」ノード、「OpenSSOエージェント」ノードを開き、右上隅のどちらかのOpenSSOエージェントの作成ボタンをクリックします。

2. 「新規OpenSSOエージェント」ページで必須詳細情報(*付き)を入力します(表20-5)。

3. 「ポリシーの自動作成」ボックスが選択されていることを確認します(または、新しいアプリケーション・ドメインが必要ない場合にはボックスの選択を解除してこの機能を無効にします)。

4. 「適用」をクリックして、登録を送信します(または登録を送信せずにページを閉じます)。

5. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

6. ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。

7. コンソール・ホスト(AdminServer)からOpenSSOエージェントのブートストラップ・ファイルおよび構成ファイルをエージェント・ホストWebサーバーにコピーします。

OpenSSOプロパティ・ファイルのコピー元

パス

コピー元: AdminServer (コンソール)ホスト

DOMAIN_HOME/output/$Agent_Name/

- OpenSSOAgentBootstrap.properties

- OpenSSOAgentConfiguration.properties

OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。

例:

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/

8. エージェントをホストしているOAMサーバーを再起動します。

9. 必要に応じて、次のトピックに進みます。

- 「コンソールを使用した登録済OpenSSOエージェントの構成および管理」

- 第V部「Access ManagerのSSO、ポリシーおよびテストの管理」

20.4.2 コンソールを使用した登録済OpenSSOエージェントの構成および管理

次の手順は、編集(表示、変更または削除)するOpenSSOエージェントのタイプがJ2EEまたはWebのどちらの場合も同じです。有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して、登録済のエージェントのあらゆる設定を変更できます。

変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをOpenSSOエージェントの構成領域にコピーする必要はありません。アーティファクトは、エージェント名、パスワードまたはセキュリティ・モードが変更された場合にのみ、OpenSSOエージェント・ディレクトリ・パスにコピーする必要があります。

注意:

エージェントの登録を削除すると、登録のみが削除されるため(関連付けられているホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント・インスタンス自身は削除されません)、同じエージェントが必要になった場合に再登録する必要はありません。ただし、アプリケーション・ドメインおよびその内容を削除すると、「アプリケーション・ドメインおよびその内容の削除」で説明するように、エージェント登録を含むすべての参照オブジェクトが削除されます。

前提条件

エージェントは登録済であり、Oracle Access Managementコンソールでその登録を表示可能である必要があります。AdminServerおよび1つのOAMサーバーが稼動している必要があります。

関連項目:

「拡張されたOpenSSOエージェント・ページとパラメータについて」

登録詳細を表示または変更(または登録を削除)するには:

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。

1. 「OpenSSOエージェント」ノードを開き、「検索」ページを表示します。

2. 登録を検索します。フォームに(「エージェント名」または「エージェント・タイプ」、またはその両方を)入力するか、単純に「検索」ボタンをクリックします。

3. 登録を開きます。結果表のエージェント名をクリックしてページを開きます。

2. 既存の詳細を変更します。

1. 必要に応じてエージェントの詳細を追加または変更します(表20-5)。

2. 「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます。

3. OpenSSOエージェント構成ファイルは、エージェント名、パスワードまたはセキュリティ・モードが変更された場合にのみコピーします。

3. OpenSSOエージェント登録を削除します。これにより、エージェント・インスタンス自体は削除されず、コンソールから登録ページのみが削除されます。

1. エージェントの登録ページが開いている場合は閉じます。

2. 希望するエージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

3. エージェント名がナビゲーション・ツリーにないことを確認します。

4. エージェントをホストしているOAMサーバーを再起動します。

5. 第V部「Access ManagerのSSO、ポリシーおよびテストの管理」に進みます。

20.5 OpenSSOエージェントのリモート登録の実行

この項では、オラクル社提供のツールoamregを使用したリモート登録について簡単に説明します。この項の内容は、次のとおりです。

- OpenSSOエージェントのリモート登録用リクエスト・テンプレートの理解

- OpenSSOブートストラップ構成マッピングの再確認

- OpenSSOエージェントの帯域内リモート登録の実行

- OpenSSOエージェントの帯域外リモート登録の実行

20.5.1 OpenSSOエージェントのリモート登録用リクエスト・テンプレートの理解

各OpenSSOエージェントは、アプリケーションに対するリクエストを捕捉することで、これらのアプリケーションへのアクセスを制限します。OpenSSOエージェント・プロビジョニングとは、OpenSSOエージェントをAccess Managerに登録するプロセスです。

inbandとoutofbandのどちらのリモート登録モードにも、表20-8に示した入力引数を含むリクエスト・ファイルが必要になります。

表20-8 リモート登録用のOpenSSOリクエスト・ファイル

テンプレートの対象

説明

OpenSSOエージェントの登録

$OAM_REG_HOME/input/OpenSSORequest.xml

$OAM_REG_HOME/input/OpenSSORequest_short.xml

短縮リクエストでoamregを実行する場合、拡張リクエスト内のみにある要素に対しては、デフォルト値が自動的に適用されます。

その他のテンプレート

エージェントの更新:

$OAM_REG_HOME/input/OpenSSOUpdateAgentRequest.xml

関連項目: 「エージェントのリモート更新」

ポリシーの作成:

エージェントを登録せずに新しいホスト識別子とアプリケーション・ドメインを作成

$OAM_REG_HOME/input/CreatePolicyRequest.xml

関連項目: 「ポリシーおよびアプリケーション・ドメインのリモート管理」

ポリシーの更新:

既存のホスト識別子と、(エージェント登録に関連付けられていない)アプリケーション・ドメイン

$OAM_REG_HOME/input/UpdatePolicyRequest.xml

関連項目: 「ポリシーおよびアプリケーション・ドメインのリモート管理」

OpenSSOエージェントのリモート登録では、次の処理が自動的に行われます。

- Oracle Access Managementコンソール用のエージェント・ページの作成

- アプリケーションを保護するためのアプリケーション・ドメインと基本ポリシーの作成

- エージェントが実行時に使用する、クライアント上のOpenSSOプロパティ・ファイルの作成

OpenSSOエージェントのリクエスト・テンプレートの要素については、表20-9を参照してください。特に明記しないかぎり、短縮版と拡張版の両方のリクエスト・ファイル内にすべての要素が存在します。

表20-9 OpenSSOエージェントのリモート登録リクエスト

要素

説明

例

<serverAddress>

<agentName>

<hostIdentifier>

<agentBaseUrl>

<autoCreatePolicy>

<applicationDomain>

<virtualhost>

すべてのリモート登録リクエスト・テンプレートに共通の要素。

表13-8「リモート登録リクエストの共通要素」を参照してください。

<agentType>

J2EEまたはWebタイプのOpenSSOエージェントのどちらかを選択します。

<agentType>WEB</agentType>

パスワード

パスワードの再入力 *

このOpenSSOエージェントの必須かつ一意のパスワードで、この登録プロセス中に割り当てられています。このエントリは不明瞭化された形式で、コンソール、oam-config.xml、OpenSSOAgentBootstrap.propertiesに表示されます。

登録されたエージェントがOAM SServerに接続すると、ユーザーはパスワードを入力するよう求められます。パスワードにより、認証時に認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。

リモート登録時にパスワードを入力するように求められます。これはテンプレートには表示されません。

拡張されたOpenSSOテンプレートのみ

<agentDebugDir>

<debug>をtrueに設定すると、記録されたエージェント・メッセージへのディレクトリ・パスを構成できます。

デフォルト:なし

関連項目: 第6章「コンポーネント・イベント・メッセージのロギング」

<agentDebugDir>/scratch/debug</agentDebugDir>

<agentAuditDir>

OAMサーバーから次の監査ログへのディレクトリ・パスを定義します。

- ログイン・イベントの監査

- ログアウト成功イベントの監査

関連項目: 第8章「管理イベントとランタイム・イベントの監査」

<agentAuditDir>/scratch/audit</agentAuditDir>

<agentAuditFileName>

監査ログ・ファイル名を定義します。

<agentAuditFileName>audit.log</agentAuditFileName>

<debug>

trueに設定すると、OAMサーバーは次のイベントに関するメッセージを記録します。

- ログイン成功およびログイン失敗イベント

- ログアウト成功およびログアウト失敗イベント

- 様々なロギング・レベル(FATAL、ERROR、WARNING、DEBUG、TRACE)のログ・メッセージ。降順でそれぞれが重大度を示しています。

デフォルト: false

関連項目: 第6章「コンポーネント・イベント・メッセージのロギング」

<debug>false</debug>

<cookieName>

Cookieの名前。OpenSSOプロキシがセッションの検証をトリガーした後に、エージェントがこのCookieを検出します。

エンド・ユーザーの持つ有効なCookieは次のとおりです。

- OAM_ID cookie (エージェント認証後のエンド・ユーザー・セッションを表します)。

- OpenSSO cookie

<cookieName>iPlanetDirectoryPro</cookieName>

<accessDeniedUrl>

アクセスが拒否された場合、ユーザーはこのURLにリダイレクトされます。

<accessDeniedUrl></accessDeniedUrl>

<protectedAuthnScheme>

認証ポリシーで使用する認証スキームを指定します。

アップグレード済の環境の場合、新しく登録するOSSOエージェントの保護されたリソース・ポリシーには、SSOCoExistMigrateSchemeを使用してください。

<protectedAuthnScheme></protectedAuthnScheme>

20.5.2 OpenSSOブートストラップ構成マッピングの再確認

この項では、OpenSSOのブートストラップ構成マッピングについて説明します。

- 表20-10「J2EEリクエスト・ファイルのプロパティ・ファイルに対するマッピング」

- 表20-11「Webリクエスト・ファイルのプロパティ・ファイルに対するマッピング」

表20-10 J2EEリクエスト・ファイルのプロパティ・ファイルに対するマッピング

プロパティ名

デフォルト値

値の例

com.iplanet.am.naming.url

入力XMLより<serverAddress>/opensso/namingservice

http://example.com:7575/opensso/namingservice

com.sun.identity.agents.app.username

入力XMLより<agentName>

<Agent registration ID>

com.iplanet.am.service.secret

入力XMLより<agentPassword>

注意: これは入力XMLファイルの一部としては収集されるのではなく、リモート登録ツールにより入力を求められます。

<Encrypted Agent registration ID password>

com.iplanet.services.debug.directory

入力XMLより<agentDebugDir>

/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/debug

com.sun.identity.agents.config.local.logfile

入力XMLより<agentAuditDir>/<agentAuditFileName>

/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/audit/amAgent_example_com_7676.log

com.sun.identity.agents.config.organization.name

入力XMLより<realmName>

注意: これは、入力XMLファイルから収集する<hostIdentifier>の値です。明示的に指定していない場合は、デフォルトで<agentName>とみなされます。

com.sun.identity.agents.config.profilename

入力XMLより<agentName>

<Agent registration ID>

リモート登録ファイルに含まれないプロパティ

com.iplanet.am.naming.url

なし

なし

com.sun.identity.agents.config.service.resolver

なし

なし

com.sun.services.debug.mergeall

なし

なし

com.sun.identity.agents.config.lock.enable

FALSE

なし

なし

am.encryption.pwd

なし

なし

表20-11に、Webエージェント・リクエスト・ファイルとプロパティ・ファイルの間のマッピングを示します。

表20-11 Webリクエスト・ファイルのプロパティ・ファイルに対するマッピング

プロパティ名

デフォルト値

値の例

com.iplanet.am.naming.url

入力XMLより<serverAddress>/<serverAddress>/opensso/namingservice

http://example.com:7575/opensso/namingservice

com.sun.identity.agents.config.username

入力XMLより<agentName>

<Agent profile ID>

com.sun.identity.agents.config.password

入力XMLより<agentPassword>

注意: これは入力XMLファイルの一部としては収集されるのではなく、リモート登録ツールにより入力を求められます。

<Encrypted Agent registration ID password>

com.iplanet.services.debug.directory

入力XMLより<agentDebugDir>

/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/debug

com.sun.identity.agents.config.local.logfile

入力XMLより<agentAuditDir>/<agentAuditFileName>

/opt/30j2ee/j2ee_agents/tomcat_v6_agent/Agent_001/logs/audit/amAgent_redsky_red_iplanet_com_7676.log

com.sun.identity.agents.config.organization.name

入力XMLより<realmName>

注意: これは、入力XMLから収集する<hostIdentifier>の値です。ステータス: オープン、固定またはクローズ済

com.sun.identity.agents.config.profilename

入力XMLより<agentName>

20.5.3 OpenSSOエージェントの帯域内リモート登録の実行

この項では、OpenSSOエージェントの帯域内リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、ここで説明する別の章を参照してください。

前提条件

「リモート登録の概要」

タスクの概要: リモート登録を実行する帯域内の管理者

1. 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. エージェントとアプリケーション・ドメインに対して一意の値で入力ファイルを作成します(「リモート登録リクエストの作成」を参照)。
作成元: OpenSSORequest.xml
作成先: myopenssoagent_request.xml

3. 登録ツールを実行してエージェントを構成し、リソースに対するデフォルトのアプリケーション・ドメインを作成して、更新したエージェント構成ファイルをコピーします(「帯域内リモート登録の実行」を参照)。
コピー元: コンソール・ホスト(AdminServer)

/rreg/output/Agent_Name/

- OpenSSOAgentBootstrap.properties

- OpenSSOAgentConfiguration.properties

OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。例:

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/

4. 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証およびアクセスの検証」を参照してください)。

20.5.4 OpenSSOエージェントの帯域外リモート登録の実行

この項では、OpenSSOエージェントの帯域外リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、ここで説明する別の章を参照してください。

前提条件

「リモート登録の概要」

タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)

1. 帯域外の管理者の手順: 特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。

- 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

- テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインに一意の値を入力します(「リモート登録リクエストの作成」を参照してください)。

OAM_REG_HOME/input/OpenSSORequest.xml

- 選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。

2. 帯域内の管理者の手順:

- 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

- 登録ツールで帯域外の開始リクエストを使用してエージェントを登録し、帯域外の管理者に戻すレスポンスおよびネイティブ・エージェントの構成ファイルを作成します。「帯域外リモート登録の実行」を参照してください。

- opensso_Response.xmlは、帯域外の管理者が手順3で使用するために生成されます。

- OpenSSOプロパティ・ファイルは、帯域外の管理者がOSSOモジュールをブートストラップできるように変更します。

3. 帯域外の管理者: レスポンス・ファイルと登録ツールを使用して、アーティファクトをファイル・システムの適切なディレクトリにコピーします。

- opensso_Response.xml。

- opensso....propertiesファイル

4. 帯域内の管理者: 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. 帯域外の管理者の手順: いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。

20.6 登録済OpenSSOエージェントのリモート更新

この項では、「エージェントのリモート更新の概要」で説明したリモート登録テンプレートとモードを使用して、OSSOエージェントを更新、検証および削除する方法について説明します。

更新リクエスト・ファイルを使用して、具体的な値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。

表20-12 OpenSSOリモート登録とリモート更新の相違点

相違点

要素

追加

変更を追跡する、<startDate>yyyy_mm_dd</startDate>要素

追加

agent_base_url_portを指定する<homeUrl>要素

省略

<hostidentifier>

省略

<agentbaseURL>

関連項目:

- 表20-7「拡張されたOpenSSOエージェント登録の要素」

- OpenSSOエージェントのリモート更新

20.6.1 OpenSSOエージェントのリモート更新

OAM 10gエージェント登録をリモート更新するには

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントの更新:

1. OAMUpdateAgentRequest.xmlテンプレートを使用して、更新リクエストを作成します。

2. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:

./bin/oamreg.sh agentUpdate input/OpenSSOUpdateAgentRequest.xml

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージで成功したことを確認します。

5. エージェント・ホストのOpenSSOAgentBootstrapとOpenSSOAgentConfiguration.propertiesファイルを再配置します。
再配置元AdminServer (コンソール)ホスト: /rreg/output/Agent_Name/

OpenSSOエージェント・ホストWebサーバー: $OHS_dir/configにコピーします。例:

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/*.properties

6. このエージェントをホストするOAMサーバーを再起動します。

3. エージェントの検証:

1. エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:

./bin/oamreg.sh agentValidate agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。

4. エージェントの削除:

1. エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:

./bin/oamreg.sh agentDelete agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。
成功: 画面のメッセージを確認します。

AgentDeleteプロセスは正常に完了しました。

20.7 その他のOpenSSOエージェントの情報の参照先

Access Managerを使用するレガシーOpenSSOエージェントの追加情報は、表20-13を参照してください。

表20-13 このガイドに記載されたOpenSSOのその他の情報

トピック

ロケーション

コンポーネントのログ出力

表6-3「Oracle Access Managementのサーバー側コンポーネントのログ出力」

DMSコンソール内のOpenSSOメトリック

DMSコンソールでのOpenSSOメトリックの確認

セッションの管理

「OpenSSOエージェントについて」

アーティファクト

「生成されるアーティファクト: OpenSSO」

移行されるアーティファクト: OpenSSO

21 レガシーOSSOエージェントの登録および管理

レガシーOracleAS SSO 10gが既存のデプロイメントのエンタープライズ・ソリューションとしてすでに配置されている場合、Oracle Fusion Middlewareは、これをソリューションとして引き続きサポートします。さらに、第12章で説明するように、既存のOSSO 10g mod_ossoモジュールをAccess Managerのエージェントとして登録することもできます。

この章では、Access Manager 11.1.2で使用するためにレガシーOSSOエージェントを登録または管理する方法について説明します。この章の内容は、次のとおりです。

- Access Manager使用時のOSSOエージェントの理解

- Oracle Access Managementコンソールを使用したOSSOエージェントの登録

- コンソールを使用した登録済OSSOエージェントの構成および管理

- OSSOエージェントのリモート登録の実行

- 登録済OSSOエージェントのリモート更新

- Access Manager 11.1.2使用時のOSSOエージェントのログアウト

- その他のOSSOエージェントの情報の参照先

21.1 Access Manager使用時のOSSOエージェントの理解

ここでは、次の内容について説明します。

- Access Manager使用時のOSSOエージェントについて

- Access Manager 11g SSOとOSSO 10gの比較

21.1.1 Access Manager使用時のOSSOエージェントについて

mod_ossoモジュールは、シングル・サインオン・サーバーの唯一のアプリケーションとして機能することで、認証プロセスを簡易化するOracle HTTP Serverモジュールです。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。これにより、OracleAS Single Sign-Onで保護されたアプリケーションは、ユーザーのログイン後に、ユーザー名とパスワードのかわりにHTTPヘッダーを受け入れるようになります。これらのヘッダーの値がmod_osso Cookieに格納されます。

これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。ユーザーの認証後、mod_ossoは、ユーザーの認可にアプリケーションで使用される可能性のある単純なヘッダー値を送信します。

- ユーザー名

- ユーザーGUID(グローバル・ユーザー・アイデンティティ)

- 言語および地域

Access Managerに登録すると、OSSO 10gエージェントは、OSSOプロキシを通じてAccess Manager 11gのサービスと直接通信できるようになります。OSSOプロキシは、Access Managerへのアップグレード時に既存のOSSOエージェントをサポートします。このプロキシは、OSSOエージェントからのリクエストを処理して、OSSOプロトコルをAccess Manager 11g認証サービスのプロトコルに変換します。

OSSOプロキシは、Access ManagerエージェントとOSSOエージェント間の相互運用性をサポートします(OSSOエージェントを使用して、Webゲートまたはアクセス・クライアントのために作成された有効なSSOセッションにアクセスしたり、Webゲートまたはアクセス・クライアントを使用してOSSOエージェントのために作成された有効なSSOセッションにアクセスしたりします)。

OSSOプロキシのサポート対象

説明

SSOログイン

OSSOエージェントからOAMサーバー(およびOSSO固有のトークン)

SSOログアウト

OSSOエージェントからOAMサーバー

OSSOエージェントのリクエストおよびプロトコル

OSSOプロキシは、OSSOプロトコルをAccess Manager用のプロトコルに変換します。

10g mod_ossoをエージェントとして登録した後、Access Managerはリソースに定義されたOAMポリシーに関連付けられた認証スキームに基づいて、mod_ossoにユーザーのためのリダイレクトURLを渡します(表21-1を参照)。

表21-1 Access Manager使用時のOSSOエージェント

有効な既存のOracle HTTPサーバーcookieを確認

必要に応じてOAMサーバーにリダイレクトし、認証中にディレクトリに連絡します。

OSSOサーバーから移入された暗号化されたユーザー・アイデンティティを復号化

ヘッダーにユーザー属性を設定

21.1.2 Access Manager 11g SSOとOSSO 10gの比較

この項では、シングル・サインオンのAccess Manager 11gポリシーを実装および施行する主要コンポーネントをOSSO 10gと比較しながら説明します。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。

OracleAS SSO 10gは認証のみ提供します。

表21-2に、これらの違いについての概要を示します。

表21-2 11g Access Manager SSOとOSSO 10gコンポーネントの概要

コンポーネントの説明

11g Access Manager

OSSO 10g

Oracle Identity Managementインフラストラクチャ

エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。

エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。

エージェント

依存するパーティとともに存在し、認証および認可タスクをOAMサーバーに委任します。

- 11g OAMエージェント

- 10g OAMエージェント

- 10g OSSOエージェント(mod_osso)

- OpenSSOエージェント

注意: 8つの管理者言語がサポートされています。

- mod_osso(パートナ)
注意: mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。

サーバー

注意: 管理ユーザーは、https://host:port/oamconsoleのURLを入力して、コンソールのホームページにアクセスできます。

管理外ユーザーは、SSOログイン・ページを戻すアプリケーションのURLを入力して、シングル・サインオン・サーバーに最初にアクセスします。

- OAMサーバー

- WebLogic管理サーバーにインストールされるOracle Access Managementコンソール

関連項目:

Oracle Access Managementコンソールのログインとサインアウト

「Access Manager資格証明コレクションおよびログインの概要」

- OracleAS SSOサーバー(OSSOサーバー)

関連項目: 『Oracle Application Server Single Sign-On管理者ガイド』

プロキシ

レガシー・システムのサポートを提供します。

- OAMプロキシは、レガシー・アクセス・サーバーとしてレガシーAccess Manager実装をサポートします。

- OSSOプロキシは、レガシーOSSOサーバーとしてOSSOエージェントをサポートします。

- Oracleは、OpenSSOエージェントによって保護されているリソースへのリクエストを処理するOpenSSOプロキシを提供しています。

- OSSOプロキシは、レガシーOSSOサーバーとしてレガシーSSO実装をサポートします。

コンソール

Oracle Access Managementコンソール

Access Manager 11g以前に同等のコンソールはありません。

インターネット上での情報交換の保護に使用されるプロトコル。

エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS

11g Webゲートでは、エージェント・キーを使用して情報交換が保護されます。

-関連項目: 暗号化キー

なし

ポリシー・ストア

データベース

mod_ossoおよびパートナ・アプリケーション

アプリケーション

認証および認可をAccess Managerに委任して登録されたエージェントからヘッダーを受け入れるアプリケーション。

注意: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。

認証をmod_ossoおよびOracleAS Single Sign-Onサーバーに委任するアプリケーション。

注意: Access Manager 11gでmod_ossoを登録した後、mod_ossoは認証をOAMに委任します。

mod_ossoモジュールを使用すると、ユーザーのログイン後に認証されたユーザー情報をアプリケーションで受け入れることができます。登録されたOSSOエージェントからヘッダーを受け入れて、再認証を回避します。

アプリケーションは、認証されたユーザーがアプリケーションの使用を認可されているかを判別します。

SSOエンジン

セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。

Access Manager 11gによって登録されたエージェントを使用します。

- 認証(資格証明コレクション)は、HTTP(HTTPS)チャネルで発生します。

- 認可は、Oracle Accessプロトコル(OAP)チャネルで発生します。

- mod_ossoは、認証のみを委任して、HTTPチャネルのみで通信します。

暗号化キー

- 11gエージェントの登録中、エージェントのキーが生成され、OAMサーバーとも共有されます。
キーは、SSO Cookieの暗号化および復号化に使用されます。

- 10gエージェントの登録時、Access Manager 11g全体にわたる(すべてのエージェントとOAMサーバー)グローバル共有秘密鍵が生成されます。

- OSSOエージェントの登録時、mod_ossoとOSSOサーバー間でパートナごとに1つのキーが共有されます。

- OpenSSOエージェントのホストまたはドメイン・ベースの鍵は、エージェント・ホストのブートストラップ・ファイル内にローカルに保存されます。

- OAMサーバーのインストール中、1つのOAMサーバー・キーが生成されます。

注意: 登録されたmod_ossoエージェントごとに1つのキーが生成され、使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。

- mod_ossoおよびOSSOサーバー間で共有されるパートナごとの1つのキー

- OSSOサーバー固有のキー

- GITOドメインCookieのOSSO設定ごとの1つのグローバル・キー

キー・ストレージ

- エージェント側: エージェントごとのキーは、ローカルでウォレット・ファイルのOracleシークレット・ストアに格納されます。

- OAMサーバー側: エージェントごとのキーとサーバー・キーは、サーバー側の資格証明ストアに格納されます。

- セキュリティ・トークン・サービス

- mod_osso側: パートナ・キーおよびGITOグローバル・キーが曖昧な構成ファイルにローカルに格納されます。

- OSSOサーバー側: パートナ・キー、GITOグローバル・キーおよびサーバー・キーがすべてディレクトリ・サーバーに格納されます。

Cookie

関連項目: 表15-8

および

ユーザー・ログイン時のシングル・サインオンCookieについて

ホストベースの認証Cookie

- 11g Webgate、エージェントごとに1つ: OAMAuthnCookie_<host:port>_<random number>

- 10g Webgate、すべての10g Webgateに対してObSSOCookieを1つ。

- OAMサーバーに1つ: OAM_ID(表15-8)

- ホストベースの認証Cookie
パートナごとに1つ: OHS-host-port

OSSOサーバーに1つ: (Access Manager 11gの使用なし)

- 対応している場合、グローバル非アクティビティ・タイムアウト(GITO)のドメインレベルのセッションCookie

ポリシー

登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。

mod_ossoは、Access Manager 11g認証ポリシーのみを使用して、定義されたリソースのアクセスを取得するユーザーを決定します。

mod_ossoは、認証のみを提供します。

クライアントIP

- このクライアントIPを保守管理して、それをホスト・ベースのOAMAuthnCookieに含めます。

- 元のクライアントIPをホストのCookie内に含めます。
後の認証リクエストでCookieが提示されると、元のクライアントIPとプレゼンタのIPが比較されます。

一致しない場合は拒否されます。

暗号化/復号化(暗号化されたデータを元の形式に変換する)

クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。

1. Webgateは、エージェント・キーを使用してobrareq.cgiを暗号化します。
注意: obrareq.cgiは、WebgateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

2. OAMサーバーは、リクエストを復号化して認証し、セッションを作成してサーバーcookieを設定します。

3. また、OAMサーバーはエージェントの認証トークン(エージェント・キーを使用して暗号化)を生成し、セッション・トークン(cookieベースのセッション管理を使用する場合)や認証トークン、その他のパラメータを使用してそれをobrar.cgiにパックしてから、エージェント・キーを使用してobrar.cgiを暗号化します。
注意: obrar.cgiは、OAMサーバーからWebgateにリダイレクトされた認証レスポンス文字列です。

4. Webgateはobrar.cgiを復号化して、認証トークンを抽出し、ホスト・ベースのCookieを設定します。

暗号化はmod_ossoおよびOSSOサーバーの両方で実行されます。

1. site2pstoreトークン(mod_ossoからサーバーへのリクエスト)は、mod_ossoでパートナ・キーを使用してローカルで暗号化されます。

2. OSSOサーバーは、site2pstoreトークンを復号化して認証を行い、独自のcookieを生成します。

3. urlcトークン(OSSOサーバーからmod_ossoへのレスポンス)は、サーバーでパートナ・キーを使用して暗号化されます。

4. mod_ossoはurlcトークンをローカルで復号化し、独自のフォーマットを使用して再び暗号化してホスト・ベースのcookieに設定します。

セッション管理

- セッション・アイドル・タイムアウトの動作は、11gセッション管理エンジン(SME)によりサポートされています。

- グローバルな非アクティブのタイムアウト(GITO)のドメイン・レベルのcookieによって、単一のドメインがサポートされます。
マルチドメインSSO: ユーザーがあるドメインにログインした後で、別のドメインに移動すると、最初のドメインではアイドル状態と見なされます。元のドメインで、アイドルのタイムアウトになると、そのユーザーは元のドメインで再度認可される必要があります。

レスポンス・トークンの再生防止

- レスポンス・トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をobrareq.cgiに含めて、それをobrar.cgiにコピーします。

- トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をsite2pstoreトークンに含めて、それをurlcトークンにコピーします。

複数のネットワーク・ドメインのサポート

Access Manager 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。

この場合は、Oracle Federationを使用することをお薦めします。

なし

一元化されたログアウト

- logOutUrls (10g Webgateの構成パラメータ)は保持されています。10g logout.htmlには、Access Manager 11g固有の詳細情報が必要です。

- 11g Webgateには次の新しいパラメータが追加されています。

ログアウト・リダイレクトURL
ログアウト・コールバックURL

ログアウト・ターゲットURL

第19章を参照してください。

mod_osso(OSSOエージェント)を持つAccess Manager 11gでは変更は必要ありません。

動的ディレクティブを使用するアプリケーションは、mod_osso.confにエントリを必要としません。かわりに、1つまたは複数の動的ディレクティブとして保護がアプリケーションに書き込まれます。

第19章を参照してください。

関連項目:

「Access Manager資格証明コレクションおよびログインの概要」

21.2 Oracle Access Managementコンソールを使用したOSSOエージェントの登録

この項では、Oracle Access Managementコンソールを使用したOSSOエージェント登録(mod_osso)の管理方法について説明します。詳細は、次の項目を参照してください。

- OSSOエージェント登録の作成ページとパラメータの理解

- コンソールを使用したOSSOエージェント(mod_osso)の登録

21.2.1 OSSOエージェント登録の作成ページとパラメータの理解

このトピックでは、Oracle Access Managementコンソールを使用したOSSOエージェントの登録について説明します。

注意:

OSSOエージェントを登録する前に、Oracle HTTP Serverがクライアント・コンピュータ上にインストールされて、mod_ossoにWebサーバーが構成済であることを確認してください。

図21-1に、Oracle Access Managementコンソールの「システム構成」タブにある「OSSOエージェントの作成」ページを示します。

図21-1 「OSSOエージェントの作成」ページ

「図21-1 「OSSOエージェントの作成」ページ」の説明

「OSSOエージェントの作成」ページでは、必要な情報にアスタリスク(*)で印が付けられています。表21-3 は、新しいエージェントを登録する際に指定できる必須およびオプションの詳細を示します。

表21-3 「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などです。

注意: ホストとポートは、展開された登録のデフォルトとして使用されます。表21-5を参照してください。

管理者ID

このmod_ossoインスタンスの管理者のログインID(オプション)。たとえば、SiteAdminなどです。

管理者情報

このmod_ossoインスタンスの管理者の詳細(オプション)。たとえば、アプリケーション管理者などです。

ホスト識別子

ホスト識別子は、エージェント名に基づいて自動的に入力されます。

ポリシーの自動作成

エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。

OSSOプロキシには、汎用のURL (/**)を持ったリソースを含み、LDAPスキーム(デフォルト)に基づくポリシーで保護されているアプリケーション・ドメインが必要です。サーバー側で汎用のURLが使用されるのは、このためです。

デフォルト: 有効

注意: ドメインおよびポリシーをすでに登録している場合は、新しいリソースを追加できます。このオプションを解除(選択解除)すると、アプリケーション・ドメインやポリシーは自動的に生成されません。

アップグレード済のデプロイメントでは、SSOCoExistMigrateSchemeを使用するように、認証ポリシー内の認証スキームを変更する必要があります。

エージェントの登録を合理化するため、いくつかの要素は非表示にされ、コンソールで登録時にはデフォルト値が使用されます。Oracle Access Managementコンソールでエージェントの登録ページを表示すると、「コンソール内の拡張されたOSSOエージェント・ページの理解」で説明する要素と値をすべて確認できます。

OSSOエージェント構成ファイル

OSSOエージェント構成ファイルのosso.confは、エージェントの登録および構成の変更時に更新されます。これは、コンソール・ホスト(AdminServer)に格納されます。登録または構成を更新したときには、表21-4に示すように、アーティファクトをエージェント・ホスト上のmod_ossoディレクトリ・パスに再配置する必要があります。

表21-4 OSSOアーティファクトの再配置

AdminServer

再配置先のOHS_dir/osso.conf

$DOMAIN_HOME/output/$Agent_Name/

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/osso

21.2.2 コンソールを使用したOSSOエージェント(mod_osso)の登録

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を実行すると、Oracle Access Managementコンソールを使用してOSSOエージェントを登録できます。

前提条件

Oracle HTTP Serverがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。

関連項目:

OSSOエージェント登録の作成ページとパラメータの理解

OSSOエージェントを登録する手順

1. Oracle Access Managementコンソールで「新規OpenSSOエージェント」リンクをクリックします。
「ようこそ」ページ
「SSOエージェント」パネル
「新規OSSOエージェント」リンク

または、「システム構成」タブの「Access Manager」セクションで「SSOエージェント」ノード、「OSSOエージェント」ノードを開き、右上隅の「OSSOエージェントの作成」ボタンをクリックします。

2. 「OAMエージェントの作成」ページで、表21-3にある必要な詳細を入力します。

- 名前

- ベースURL

3. 必要な「トークン・バージョン」を選択し、必要な場合にはオプションの詳細を入力します(表21-3)。

4. 「適用」をクリックして、登録を送信します(または変更を適用しないでページを閉じます)。

5. 「確認」ウィンドウで、生成されたアーティファクトのパスを確認し、ウィンドウを閉じます。例:

Artifacts are generated in following location : /.../base_domain/output/$Agent_Name

6. コンソールのホスト(AdminServer)からosso.confをエージェントのホストのWebサーバーにコピーします。例:

osso.conf

パス

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェントのホストのWebサーバーのmod_ossoディレクトリ・パス: $OHS_dir/osso.conf.

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/osso.conf

7. アップグレード済のデプロイメントでは、SSOCoExistMigrateSchemeを使用するように、保護されたリソース・ポリシーの認証スキームを変更します。

8. エージェントをホストしているOAMサーバーを再起動します。

9. 必要に応じて次の手順に進みます。

- 「コンソールを使用した登録済OSSOエージェントの構成および管理」

- 第V部「Access ManagerのSSO、ポリシーおよびテストの管理」

21.3 コンソールを使用した登録済OSSOエージェントの構成および管理

この項では、Oracle Access Managementコンソールを使用したOSSOエージェント登録(mod_osso)の管理方法について説明します。詳細は、次の項目を参照してください。

- コンソール内の拡張されたOSSOエージェント・ページの理解

- OSSOエージェント(mod_osso)の登録の検索

- OSSOエージェント(mod_osso)の登録の表示または編集

- OSSOエージェント(mod_osso)の削除

21.3.1 コンソール内の拡張されたOSSOエージェント・ページの理解

登録時には、登録プロセスを簡潔にするために、使用可能なパラメータのサブセットのみが表示されます。Oracle Access Managementコンソールとリモート登録ユーティリティのどちらを使用してエージェントを登録していても、エージェントの登録後には、コンソールで完全なエージェントの構成ページを表示できます。それまで非表示にされていた要素にはデフォルト値が移入されています。この要素は、図21-2に示すように、エージェントのページを開いたときに表示されます。「確認」ウィンドウはそのまま表示されます。

図21-2 「OSSOエージェント」ページと「確認」ウィンドウ

「図21-2 「OSSOエージェント」ページ」および「確認」ウィンドウ」の説明

表21-5は、OSSOエージェントで使用される展開済の要素とデフォルトの概要を示します。

表21-5 展開されたOSSOエージェントの要素

要素

説明

サイト・トークン

認証をリクエストする際にパートナにより使用されるアプリケーション・トークン。これは編集できません。

成功URL

認証の成功時に使用されるリダイレクトURL。デフォルトでは、ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_successが使用されます。例:

デフォルト: https://example.domain.com:7001/osso_login_success

失敗URL

認証が失敗したときに使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_failureが使用されます。

デフォルト: https://example.domain.com:7001/osso_login_failure

開始日

アプリケーションへのログインがサーバーにより許可される第1日目の年月日。

デフォルト: エージェントの登録日。

ホームURL

認証後にホーム・ページとして使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。

デフォルト: https://example.domain.com:7001

ログアウトURL

ログアウトするときに使用されるリダイレクトURL。これは、ユーザーをサーバー上のグローバル・ログアウト・ページにリダイレクトします: osso_logout_success。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。

デフォルト: https://example.domain.com:7001/osso_logout_success

関連項目: 「Access Manager 11gの集中ログアウトの概要」。

21.3.2 OSSOエージェント(mod_osso)登録の検索

「OSSOエージェント」ノードを初めて開くと、「検索」フォームが表示されます。「結果」表に、すべてのOSSOエージェントがリストされます。結果が多すぎて目的のものをすぐに見つけられない場合には、コントロールを使用して検索を絞り込むことができます。

OSSOエージェントの検索を絞り込む要素は、登録時に割り当てられた「エージェント名」、またはシステムによって割り当てられる「エージェントID」の2つのみです。

前提条件

OSSOエージェントがOracle Access Managementコンソールに登録されて、使用可能であることが必要です。

OSSOエージェント登録を検索する手順

1. 「システム構成」タブで、「Access Manager」セクションに進みます。

2. 「SSOエージェント」ノードを展開し、「OSSOエージェント」ノードを開きます。

3. 「名前」フィールドに、検索条件を入力します(ワイルドカード(*)の使用は任意)。例:

my*

4. 「Search」ボタンをクリックします。

5. 「検索結果」表で、次のようにします。

- 作成: 「検索」ページ上部にある「OSSOエージェントの作成」ボタンをクリックします。

- 編集または表示: ツール・バーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。

- 削除: 「OSSOエージェント(mod_osso)登録の削除」に進みます。

- 連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。

- 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. 終了したら変更を適用します(またはページを閉じます)。

21.3.3 OSSOエージェント(mod_osso)の登録の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順で説明するとおり、Oracle Access Managementコンソールを使用して、登録済のOSSOエージェントのあらゆる設定を変更できます。たとえば、終了日を変更したり、管理者の情報を追加する場合があります。

前提条件

Oracle HTTP Serverがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。

関連項目:

- コンソール内の拡張されたOSSOエージェント・ページの理解

OSSOエージェント登録の閲覧または変更の手順

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを展開します。

2. 「OSSOエージェント」ノードをダブルクリックします。

3. エージェントの検索: 「OSSOエージェント(mod_osso)登録の検索」を参照してください。

4. 表示または変更: 登録ページで、必要に応じて詳細を表示または変更します(表21-3および表21-5)。

5. 「適用」をクリックして変更を送信し(または変更を適用せずにページを閉じます)、「確認」ウィンドウを閉じます。

6. コンソールのホスト(AdminServer)からosso.confをエージェントのホストのWebサーバーにコピーします。例:

osso.conf

パス

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェントのホストのWebサーバーのmod_ossoディレクトリ・パス: $OHS_dir/osso.conf.

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/osso.conf

7. エージェントをホストしているOAMサーバーを再起動します。

8. 第V部「Access ManagerのSSO、ポリシーおよびテストの管理」に進みます。

21.3.4 OSSOエージェント(mod_osso)登録の削除

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access Managementコンソールにより登録されたOSSOエージェントを削除できます。

注意:

エージェントの登録を削除すると、登録のみが削除されるため(関連付けられているホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント・インスタンス自身は削除されません)、同じエージェントが必要になった場合に再登録する必要はありません。ただし、アプリケーション・ドメインおよびその内容を削除すると、「アプリケーション・ドメインおよびその内容の削除」で説明するように、エージェント登録を含むすべての参照オブジェクトが削除されます。

前提条件

このエージェントに関連付けられたアプリケーション・ドメイン、リソースおよびポリシーを評価し、別のエージェントを使用するように構成されているのか、削除できるのかを確認してください。

関連項目:

OSSOエージェント(mod_osso)の登録の検索

OSSOエージェントの登録を削除する手順

1. 「システム構成」タブの「Access Manager」セクションから、「SSOエージェント」ノードを開き、「OSSOエージェント」ノードを開きます。

2. 「検索」をクリックし、目的の名前を選択します(または、必要に応じて検索を絞り込みます)。

3. オプション: 希望する名前をダブルクリックして、登録ページを表示します。これが削除するエージェントであることを確認し、ページを閉じます。

4. エージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。

21.4 OSSOエージェントのリモート登録の実行

この項では、Oracle提供のツールを使用したOSSOエージェントのリモート登録について簡単に説明します。

ここでは、次の内容について説明します。

- OSSOリモート登録用のリクエスト・テンプレートの理解

- OSSOエージェントの帯域内リモート登録の実行

- OSSOエージェントの帯域外リモート登録の実行

21.4.1 OSSOリモート登録用のリクエスト・テンプレートの理解

この項では、リモート登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)で使用するOSSO登録リクエストについて説明します。太字でハイライト表示されている情報をmod_ossoエージェント用に変更する必要があります。ただし、他のすべてのフィールドはデフォルト値を使用できます。

inbandとoutofbandのどちらのリモート登録モードにも、表21-6に示した入力引数を含むリクエスト・ファイルが必要になります。

表21-6 リモート登録用のOpenSSOリクエスト・ファイル

テンプレートの対象

説明

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

関連項目: 「ポリシーおよびアプリケーション・ドメインのリモート管理」

表21-7に、OSSOリクエスト・ファイルのOSSORequest.xmlに含まれる要素を示します。

表21-7 リモート登録リクエストのOSSO固有の要素

要素

説明

例

<serverAddress>

<agentName>

<hostIdentifier>

<agentBaseUrl>

<autoCreatePolicy>

<applicationDomain>

<virtualhost>

すべてのリモート登録リクエスト・テンプレートに共通の要素。

表13-8「リモート登録リクエストの共通要素」を参照してください。

<ssoServerVersion>

SSOトークン・バージョン値。

- v3.0: OAMサーバーと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> >

<OracleHomePath>

mod_ossoエージェントへのファイル・システム・ディレクトリの絶対パス。

<oracleHomePath>
$ORACLE_HOME
</oracleHomePath>

<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>

OSSOエージェント登録では、次の処理が自動的に行われます。

- Oracle Access Managementコンソール用のエージェント・ページの作成

- アプリケーションを保護するためのアプリケーション・ドメインと基本ポリシーの作成

- 実行時にエージェントが利用するように、クライアント側のOSSO構成ファイルを更新します

21.4.2 OSSOエージェントの帯域内リモート登録の実行

この項では、OSSOエージェントの帯域内リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、第13章を参照してください。

前提条件

リモート登録の概要

タスクの概要: リモート登録を実行する帯域内の管理者

1. 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. エージェントとアプリケーション・ドメインに対して一意の値で入力ファイルを作成します(「リモート登録リクエストの作成」を参照)。
作成元: OSSORequest.xml
作成先: myossoagent_request.xml

3. 登録ツールを実行してエージェントを構成し、リソースに対するデフォルトのアプリケーション・ドメインを作成して、更新したエージェント構成ファイルをコピーします(「帯域内リモート登録の実行」を参照)。
AdminServer(コンソール)ホスト:

$DOMAIN_HOME/output/$Agent_Name/osso.conf

エージェント・ホスト: $OHS_dir/osso.conf上のmod_ossoディレクトリ・パスにコピーします。例:

WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/osso.conf

4. 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証およびアクセスの検証」を参照してください)。

21.4.3 OSSOエージェントの帯域外リモート登録の実行

帯域外登録という用語は、帯域内および帯域外の管理者の両方の調整およびアクションを含む手動登録を示します。

outofbandモードでは、帯域内の管理者は帯域外の管理者が送信した開始リクエスト・ファイルを使用して、追加処理のために生成された応答ファイルを帯域外の管理者に戻します。帯域外の管理者は、この応答ファイルを入力として使用してリモート登録ツールを実行し、エージェント構成ファイルを更新します。

この項では、OSSOエージェントの帯域外リモート登録を実行するために必要な手順について簡単に説明しています。詳細は、ここで説明する別の章を参照してください。

前提条件

「リモート登録の概要」

タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)

1. 帯域外の管理者の手順: 特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。

- 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

- テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインに一意の値を入力します(「リモート登録リクエストの作成」を参照してください)。

OAM_REG_HOME/input/OSSORequest.xml

- 選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。

2. 帯域内の管理者の手順:

- 登録ツールを入手して、環境変数を設定します(「リモート登録ツールの取得および設定」を参照)。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

- 登録ツールで帯域外の開始リクエストを使用してエージェントを登録し、帯域外の管理者に戻すレスポンスおよびネイティブ・エージェントの構成ファイルを作成します。「帯域外リモート登録の実行」を参照してください。

- osso_Response.xmlは、帯域外の管理者用に生成され、手順3で使用されます。

- osso.confは、帯域外の管理者がOSSOモジュールをブートストラップできるように変更されます。

3. 帯域外の管理者: レスポンス・ファイルと登録ツールを使用して、アーティファクトをファイル・システムの適切なディレクトリにコピーします。

- osso_Response.xml.

- osso.conf

4. 帯域内の管理者: 構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。

5. 帯域外の管理者の手順: いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。

21.5 登録済OSSOエージェントのリモート更新

この項では、「エージェントのリモート更新の概要」で説明したリモート登録テンプレートとモードを使用して、OSSOエージェントを更新、検証および削除する方法について説明します。

更新リクエスト・ファイルを使用して、具体的な値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。

表21-8 OSSOリモート登録とリモート更新の相違点

相違点

要素

追加

変更を追跡する、<startDate>yyyy_mm_dd</startDate>要素

agent_base_url_portを指定する<homeUrl>要素

省略

<hostidentifier>

省略

<agentbaseURL>

OSSOエージェント登録をリモートで更新するには

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントの更新:

1. OSSOUpdateAgentRequest.xmlテンプレートを使用して、更新リクエストを作成します。

2. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:

./bin/oamreg.sh agentUpdate input/*OSSOUpdateAgentRequest.xml

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージで成功したことを確認します。

5. エージェント・ホストのosso.confに再配置します。
再配置元AdminServer (コンソール)ホスト: /rreg/output/Agent_Name/

再配置先はmod_ossoディレクトリ・パス(エージェント・ホストのWebサーバー$OHS_dir/osso.conf)です。

$WebTier_Middleware_Home/Oracle_WT1/instances1/config/OHS/ohs1/config/osso.conf

6. このエージェントをホストするOAMサーバーを再起動します。

3. エージェントの検証:

1. エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:

./bin/oamreg.sh agentValidate agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。

4. エージェントの削除:

1. エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:

./bin/oamreg.sh agentDelete agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。
成功: 画面のメッセージを確認します。

AgentDeleteプロセスは正常に完了しました。

21.6 Access Manager 11.1.2使用時のOSSOエージェントのログアウト

ここでは、次の内容について説明します。

- OSSOエージェント(mod_OSSO)とAccess Manager使用時の集中ログアウトについて

- ログアウト時のカスタムmod_osso Cookieの削除

21.6.1 OSSOエージェント(mod_OSSO)とAccess Manager使用時の集中ログアウトについて

OSSOエージェント(mod_osso 10g)では、パートナ・アプリケーションはログアウト制御もOAMサーバー(シングル・サインオン・サーバー)に引き渡します。ユーザーが1つのアプリケーションをログアウトすると、そのユーザーは自動的に他のすべてのアプリケーションをログアウトします。

注意:

OSSOエージェントを使用する既存アプリケーションのログアウトURL構成に変更を加える必要はありません。

プロセス概要: mod_ossoによる集中ログアウト

1. アプリケーションで「ログアウト」をクリックすると、ログアウト用のページが表示されます。

2. ユーザーが正常にサインオフすると、集中ログアウト・ページにリストされた各アプリケーションのアプリケーション名の横にチェック・マークが表示されます。

3. アプリケーション名の横に壊れたイメージが表示された場合は、ログアウトが正常に行なわれなかったことを示します。

4. セッション内でアクティブにされたすべてのアプリケーションにチェック・マークが表示されると、「戻る」をクリックすればログアウトを開始したアプリケーションに戻ることができます。

5. ログアウト時にカスタムmod_ossoエージェントCookieを削除します。

21.6.2 ログアウト時のカスタムmod_osso Cookieの削除

OSSOサーバーのcookieには、パートナIDのリストが含まれます。

処理の概要: 1つのパートナ・アプリケーションからユーザーがログオフする場合

1. OSSOサーバーがログアウトURLのリストを取得します。

2. OSSOサーバーは自身のcookieを消去します。

3. OSSOサーバーはカスタマイズされたJSPページ(OSSOサーバー上でホストされる)にリダイレクトし、リクエストにあるログアウトURLのリストを渡します。

4. JSPページは、チェック・マークのイメージ・タグをいくつか含むログアウトURLを読み込み、読み込みの結果として、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. ファイルを保存します。

21.7 その他のOSSOエージェントついての情報の参照先

Access Managerを使用するレガシーOSSOエージェントについての追加情報は、表21-9を参照してください。

表21-9 このガイドに記載されたOSSOのその他の情報

トピック

ロケーション

コンポーネントのログ出力

表6-3「Oracle Access Managementのサーバー側コンポーネントのログ出力」

DMSコンソール内のOSSOメトリック

「OSSOエージェント・メトリックの確認」

セッションの管理

「複数のエージェント・タイプ(OSSOエージェントおよびOAMエージェント)のタイムアウトについて」

22 Access Manager 11gを使用する10g Webgateの登録および管理

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』に、Oracle HTTP ServerへのOracle Access Manager 11gの初期デプロイメントについての説明が記載されています。ただし、Oracle HTTP Server以外のWebサーバー・タイプがある企業では、既存の10g Webgateを使用するか、新規に10g Webgateをインストールして、Access Managerで使用できます。また、事前登録済のIAMSuiteAgentから、10g Webgateの使用に切り替えて、Oracle Identity Managementコンソールを保護することもできます。

次の項では、10g Webgateの新規インスタンスをインストールしてAccess Managerで使用する方法を説明します。

- 前提条件

- Access Manager 11g用の10g OAMエージェントの概要

- Access Manager 11.1.2と10gの比較

- IAMSuiteAgentの集中ログアウト構成

- Access Manager 11gを使用した10g Webgateのリモート登録

- 10g OAMエージェントのリモート管理

- Access Manager 11g用の最新の10g Webgateの検索とインストール

- 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

- IAMSuiteAgentの10g Webgateへの置換

- Access Manager 11gデプロイメントからの10g Webgateの削除

22.1 前提条件

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 Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。

- ポリシー強制エージェントの紹介

- この章のAccess Manager 11g用の10g OAMエージェントの概要

22.2 Access Manager 11g用の10g OAMエージェントの概要

この項の内容は次のとおりです。

- IAMSuiteAgentについて: Access Managerに登録された事前構成済10g Webgate

- レガシーOracle Access Manager 10gデプロイメントとWebgateについて

- Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて

- 10g OAMエージェントと11g OAMサーバー使用時の集中ログアウトについて

22.2.1 IAMSuiteAgentについて: Access Managerに登録された事前構成済10g Webgate

IAMSuiteAgentは、Access Manager 11.1.2に事前登録済のJavaエージェント・フィルタです。このエージェントと付属アプリケーション・ドメインは、Access Managerによる事前構成済でインストールされます。

IAMSuiteAgentは、ドメイン全体のエージェントです。

- Access Managerがデプロイされると、ドメイン内の各サーバーにIAMSuiteAgentがインストールされます。

- 無効にしないかぎり、WebLogicアプリケーション・サーバーに入ってくるすべてのリクエストは、IAMSuiteAgentによって評価および処理されます。

- 特定のIAMSuiteAgent構成の要素はWebLogic管理コンソール(「セキュリティ・プロバイダ」セクション)に、その他の要素はOracle Access Managementコンソールにあります。

IAMSuiteAgentおよび関連ポリシーは、IDM管理コンソール、Oracle Identityコンソール、Oracle Access Managementコンソール、およびアイデンティティ管理ドメインの特定リソースに、SSO保護を提供します。

IAMSuiteAgentを10g Webgateに置き換えると、Oracle Identity Managementコンソールと、アイデンティティ管理ドメイン(選択した場合)を保護できます。

関連項目:

- 「IAMSuiteAgentの集中ログアウト構成」

- 「IAMSuiteAgentの10g Webgateへの置換」

- 「バンドルされる10g IAMSuiteAgentアーティファクト」

22.2.2 レガシーOracle Access Manager 10gデプロイメントとWebgateについて

11g OAMサーバーは、Access Manager 11.1.2で操作するように登録されている10g Webgateをサポートします。このようなWebgateには、次のものがあげられます。

- Oracle Access Manager 10gで現在稼働中のレガシー10g Webgate。

- SSO用にIDアサーション・プロバイダ(IAP)として構成されているレガシー10g Webgate(『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載されているように、Oracle Access Manager 10gでIAP WebLogicコンテナベースのセキュリティを使用しているアプリケーション用)。

- Oracle ADFセキュリティとOPSS SSOフレームワーク用にコードが記述されたWebアプリケーションで現在操作しているレガシー10g Webgate。

Oracle Access Managementコンソールまたはリモート登録ツールを使用して、Access Manager SSOを使用するように、これらのエージェントを登録できます。登録後は、10g Webgateはブリッジとして機能するJAVAベースのOAMプロキシを使用して、Access Managerと直接通信できます。

関連項目:

- 表1-3

- 付録A、「Oracle ADFアプリケーションとAccess Manager SSOの統合化」

次の概要では、既存の10g WebgateをAccess Managerで使用するための設定に必要なタスクをまとめています。

タスクの概要: レガシー10g WebgateをAccess Managerで使用できるようにする設定

1. Access Manager 11gを使用した10g Webgateのリモート登録

2. 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

3. オプション: 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明するように、アプリケーションをWebLogicコンテナにデプロイします。

22.2.3 Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて

この章で説明しているように、新しい10g WebgateをインストールしてAccess Manager 11gで使用できます。10g Webgateは、いくつかのWebサーバー・プラットフォーム用に提供されています。

インストールおよび登録の後で、10g Webgateはブリッジとして機能するJAVAベースのOAMプロキシを使用して、Access Managerと直接通信できます。

注意:

Access Manager用に新規10g Webgateをインストールする場合、最新のWebgateを使用することをお薦めします。また、フェイルオーバーやロード・バランシング用に、複数のWebgateをインストールすることをお薦めしています。

11g Access Managerデプロイメントへの10g Webgateのインストールと、Oracle Access Manager 10gデプロイメントへの10g Webgateのインストールにはいくつかの違いがあります。表22-1に違いをまとめます。

表22-1 10g Webgateのインストールの比較

11gデプロイメントへの10g Webgate

10gデプロイメントへの10g Webgate

1. パッケージ: 10g Webgateのインストール用パッケージは、コア・コンポーネントとは別のメディアおよび仮想メディアにあります。

2. プロビジョニング: インストール前に、Access Manager 11gでWebgateをプロビジョニングします。詳細は、「Access Manager 11gを使用した10g Webgateのリモート登録」を参照してください。

3. OAMサーバーとの関連付け: Webgateの登録中に実施します(タスク2)。

4. インストール: アプリケーションの前(またはFusion Middlewareの場合は、WebLogicサーバーの前)に10g Webgateをインストールします。

5. 言語パック: Access Managerは10g Webgateの言語パックをサポートしています。

6. Webサーバー構成: Access Managerで生成されたファイルを、Webgateのインストール・ディレクトリ・パスにコピーして、Webサーバーの構成を更新します。

7. 証明書のインストール: Webgateのインストール・ディレクトリ・パスにファイルをコピーします。

8. フォーム: 10g Webgateで提供されている10gフォームは、11g OAMサーバーでは使用できません。
11g OAMサーバーでの10g Webgateの使用方法や範囲は、リソースWebgate(認証用Webgateではなく、転送を行う側)と同様です。10g Webgateと11g OAMサーバーを使用する場合、10g Webgateは常に、認証Webgateのような働きをする11g資格証明コレクタにリダイレクトします。

9. シングル・ログアウト: 第19章「11g Webgateが関与するセッションの集中ログアウトの構成」の情報を使用して構成します。

10. マルチドメイン・サポート: Access Manager 11には適用されません。

1. パッケージ: 10g Webgateのインストール用パッケージは、コア・コンポーネントとは別のメディアおよび仮想メディアにあります。

2. プロビジョニング: インストール前に、アクセス・システム・コンソールでWebgateインスタンスを作成します。

3. AAAとの関連付け: インストール前に、アクセス・システム・コンソールで、Webgateをアクセス・サーバーに関連付けます。

4. インストール: 10g Webgateパッケージを使用します。

5. 言語パック: Webgateのインストール中(または後で)10g Webgateの言語パックをインストールできます。

6. Webサーバーの構成: Webgateのインストール中に自動的に行われます(またはWebgateのインストール後に手動でも可能)。

7. 証明書のインストール: Webgateのインストール・ディレクトリ・パスにファイルをコピーしました。

8. フォーム: 10gデプロイメント用に提供されていました。

9. Oracle Access Manager 10gの集中ログアウト。

10. マルチドメイン・サポート: Oracle Access Manager 10g用に構成可能。

次の概要では、この章でAccess Manager 11g用の10g Webgateのインストールおよび登録タスクについて詳細に説明したトピックをあげています。Access Manager 11gを正しく操作するために、すべての手順を完了する必要があります。

タスクの概要: 10g WebgateのAccess Manager 11g用の登録とインストール

1. 10g Webgateの登録:

2. Access Manager 11gで使用する10g Webgateの検索とダウンロード

3. 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

4. オプション: 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明するように、アプリケーションをWebLogicコンテナにデプロイします。

22.2.4 10g OAMエージェントと11g OAMサーバー使用時の集中ログアウトについて

登録された10g Webgateに対して構成されたlogout.htmlファイルがアプリケーションによって起動されると、ログアウトが開始されます。

一般的に、10g Webgate使用時の集中ログアウトの際には、SSOエンジンがユーザー・セッションの有無を問う要求を受け取ります。セッション管理エンジンはセッションを参照し、セッションが存在するという応答をします。SSOエンジンはセッション削除要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。SSOエンジンはセッション削除完了レスポンスを送信します。

ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはアプリケーションのクライアント側状態を削除します。詳細は、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」を参照してください。

関連項目:

「IAMSuiteAgentの集中ログアウト構成」

22.3 Access Manager 11.1.2と10gの比較

この項では、Access ManagerおよびOSSOの10gアーキテクチャとの比較について説明します。次のトピックが含まれます。

- Access Manager 11gと10gの比較

- Access Manager 11gと10gのポリシー・モデルの比較

22.3.1 Access Manager 11gと10gの比較

Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11g(ユーザー・セルフサービス、セルフ登録、ワークフロー機能、動的グループ管理、委任されたアイデンティティ管理を含む)に移管されたという点で、10gとは異なります。

Access Manager 10gは、認証レベルが同じかより低いターゲット・リソースへのアクセスに必要なユーザー・アイデンティティおよびセッションの情報を含む単一のセッションcookie(ObSSOCookie)を使用して、シングル・サインオンをサポートしていました。ObSSOCookieは、グローバル共有の秘密鍵を使用して暗号化、復号化され、秘密鍵の値はディレクトリ・サーバーに格納されていました。ObSSOCookieは、ユーザー・アイデンティティを検証して保護されたリソースへのアクセスを許可または却下するために、アクセス・システム・コンポーネントによって消費されていました。

あらゆるセキュリティ・ギャップを埋めるために、Access Manager 11gでは、既存のAccess Manager 10gポリシー施行エージェント(Webgate)およびOSSO 10gエージェント(mod_osso)との下位互換性を維持するサーバー側コンポーネントが新たに提供されます。新しいAccess Manager 11g Webgateは10g Webgateの強化バージョンで、シングル・サインオン(SSO)・ソリューションのためにエージェントごとの秘密鍵をサポートしています。したがって、Cookieリプレイ型の攻撃が阻止されます。11g Webgateは、すべて同じレベルで信頼されます。つまり、Webgate固有のCookieが設定され、それを使用しても、他のWebgateで保護されたアプリケーションにユーザーの代理でアクセスすることはできません。

特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。

Access Manager 11gでは、Oracle Coherenceの技術を使用して、分散されて集中化された信頼のできるセッション管理が可能です。

表22-2は、Access Manager 11gと10gの比較を示しています。Access Manager 11gで変更された名前のリストについては、「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。

表22-2 比較: Access Manager 11g対10g

Access Manager 11g

10g

エージェント

- エージェント: Webgate、アクセス・クライアント、OpenSSO、OSSO (mod_osso)およびIAMSuiteAgent

注意: 8つの管理者言語がサポートされています。

- リソースWebgate(RWG)

- 認証Webgate(AWG)

- アクセス・ゲート

- アクセス・サーバー

- ポリシー・マネージャ

- アイデンティティ・システム

注意: 8つの管理者言語がサポートされています。

サーバー側のコンポーネント

- OAMサーバー(WebLogic管理対象サーバーにインストール)
セキュリティ・トークン・サービスとIdentity FederationはOAMサーバーで実行されます。

- アクセス・サーバー

- ポリシー・マネージャ

- アイデンティティ・サーバー

コンソール

Oracle Access Managementコンソール

アクセス・システム・コンソール

アイデンティティ・システム・コンソール

インターネット上での情報交換の保護に使用されるプロトコル。

エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS

11g Webゲートでは、エージェント・キーを使用して情報交換が保護されます。

-関連項目: 暗号化キー

プレーン・テキストでの10gエージェントの情報交換は保護されません。

暗号化キー

- 11g WebgateとOAMサーバー間で共有されるエージェントごとの秘密鍵1つ

- OAMサーバー・キー1つ(サーバー登録時に生成)

注意: 登録されたmod_ossoエージェントごとに1つのキーが生成され、使用されます。

すべての10g Webゲートが使用するAccess Managerデプロイメントごとに1つのグローバル共有秘密鍵

キー・ストレージ

- エージェント側: エージェントごとのキーは、ローカルでウォレット・ファイルのOracleシークレット・ストアに格納されます。

- OAMサーバー側: エージェントごとのキーとサーバー・キーは、サーバー側の資格証明ストアに格納されます。

- セキュリティ・トークン・サービス

ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可)

Cookie

ホストベースの認証Cookie。表1-3「概要: Access Manager 11.1.2」を参照してください。

- 認証とセッション管理の両方について、すべてのWebgate(AWGを含む)に対して1つのドメイン・ベースのObSSOCookie

暗号化 / 復号化(暗号化されたデータを元の形式に変換するプロセス)

クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。

1. Webgateは、エージェント・キーを使用してobrareq.cgiを暗号化します。
注意: obrareq.cgiは、WebgateからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

2. OAMサーバーは、リクエストを復号化して認証し、セッションを作成してサーバーcookieを設定します。

3. また、OAMサーバーはエージェントの認証トークン(エージェント・キーを使用して暗号化)を生成し、セッション・トークン(cookieベースのセッション管理を使用する場合)や認証トークン、その他のパラメータを使用してそれをobrar.cgiにパックしてから、エージェント・キーを使用してobrar.cgiを暗号化します。
注意: obrar.cgiは、OAMサーバーからWebgateにリダイレクトされた認証レスポンス文字列です。

4. Webgateはobrar.cgiを復号化して、認証トークンを抽出し、ホスト・ベースのCookieを設定します。

- トークンの生成/暗号化、および検証/復号化は、アクセス・サーバーに委任されます。

- obrareq.cgiとobrar.cgiはどちらも暗号化されずに送信され、セキュリティは基礎となるHTTP(S)トランスポートに依存します。

セッション管理

- 第14章「セッションの管理」

- 単一のドメインがサポートされています。
マルチドメイン: ユーザーがあるドメイン上でアイドルのままタイムアウトし、認証のWebgateではタイムアウトしていない場合、AWG Cookieはまだ有効です(再認証は必要ありません)。新しいCookieが更新されたタイムアウトとともに生成されます。

クライアントIP

- このクライアントIPを保守管理して、それをホスト・ベースのOAMAuthnCookieに含めます。

- 元のクライアントIPをObSSOCookieの中に含めます。
IPの検証が構成されている場合、後の認証や認可リクエストでCookieが提示されたときは、この元のクライアントIPが提示者のIPと比較されます。

一致しない場合は拒否されます。

レスポンス・トークンの再生防止

- レスポンス・トークンの再生を防ぐために、RequestTime(リダイレクト直前のタイムスタンプ)をobrareq.cgiに含めて、それをobrar.cgiにコピーします。

なし

複数のネットワーク・ドメインのサポート

ネットワーク間ドメインの設定不要なシングル・サインオン。

複数のネットワーク・ドメインをサポートする場合は、Oracle Federationを使用することをお薦めします。

独自の複数のネットワーク・ドメインSSO機能が、Oracle Identity Federationより前から存在します。これが10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録すればこのサポートを引き続き受けられます。

- 単一のドメインがサポートされています。
一度ユーザーがあるWebgateからログオフすると、ドメインのCookieは消去されて、ユーザーはドメイン全体からログオフしたと見なされます。

- マルチドメインSSOは、チェーン化されたカスタマイズ済のログアウト・ページを通してサポートできます。

一元化されたログアウト

- logOutUrls (10g Webgateの構成パラメータ)は保持されています。10g logout.htmlには、Access Manager 11g固有の詳細情報が必要です。

- 11g Webgateには次の新しいパラメータが追加されています。

ログアウト・リダイレクトURL
ログアウト・コールバックURL

ログアウト・ターゲットURL

第19章を参照してください。

10g WebgateとAccess Manager 11gを併用する場合、logout.htmlでは特定の詳細が必要です。第19章を参照してください。

- 単一のドメインがサポートされています。
一度ユーザーがあるWebgateからログオフすると、ドメインのCookieは消去されて、ユーザーはドメイン全体からログオフしたと見なされます。

- マルチドメインSSOは、チェーン化されたカスタマイズ済のログアウト・ページを通してサポートできます。

22.3.2 Access Manager 11gと10gのポリシー・モデルの比較

明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。

Access Manager 10gは、ポリシー・ドメイン内のポリシーに基づく認証と認可を提供します。アクセス・サーバーへのWebgate問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合Access Manager 10gのデフォルトの動作ではアクセスが許可されていました。

表22-3は、Access Manager 11gポリシー・モデルと10gモデルを比較しています。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。対照的に、Access Manager 10gのデフォルトの動作では、リソースがアクセスを明示的に指定するルールやポリシーによって保護されていない場合に、アクセスが許可されていました。

表22-3 Access Manager 11gと10gのポリシー・モデルの比較

ポリシーの要素

11gポリシー・モデル

10gポリシー・モデル

ポリシー・オーサリング

Oracle Access Managementコンソール

ポリシー・マネージャ

ポリシー・ストア

データベース

LDAPディレクトリ・サーバー

ドメイン

アプリケーション・ドメイン

ポリシー・ドメイン

リソース

1. URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。

2. 機能が制限された次のパターン一致
' * 'および'...'がサポートされます。

3. リソースをドメイン間で一意にする必要はありません。

4. HTTP URLの問合せ文字列保護。

5. 各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。

6. 特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。

7. リソースは、「保護」、「非保護」または「除外」として指定されます。

8. カスタム・リソース・タイプが許可されます。

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. トークン発行ポリシーのサポートはありません。

認証スキーム

認証スキームはグローバルに定義され、共有されます(認証ポリシー内から参照できます)。

信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。

注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。

関連項目: 表16-19 認証スキームの定義

認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。

認可ポリシー

1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。

関連項目: 「ルール」、この表の以降の項目および「特定のリソースの認証ポリシーの定義」

リソースを保護するには、1つ以上の条件を含んだ認可ルールを定義します。また、1つ以上の認可ルール使用する認可条件式を構成します。ポリシー・ドメイン(およびポリシー)には、それぞれ1つの認可条件式のみを含めることができます。

トークン発行ポリシー

生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。

関連項目: トークン発行ポリシー・ページについて

なし

レスポンス

すべてのポリシー・タイプで使用可能。

1. 認証および認可の成功レスポンスをポリシー内に定義できます。これらはポリシーの評価後に適用されます。

2. Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。

3. URLリダイレクトを設定できます。

4. レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。

1. 認証および認可レスポンスを成功、失敗および未確定イベントでポリシー内に定義できます。これらはポリシーの評価後にコール元に戻されます。

2. HTTP_HEADERおよびCookieベースの変数を設定できます。

3. 認証および認可ポリシー評価の成功および失敗イベントにリダイレクトURLを設定できます。

4. レスポンス値には、リテラル文字列およびユーザー属性値のリストを含めることができます。

Cookie

関連項目: 表15-8

および

ユーザー・ログイン時のシングル・サインオンCookieについて

関連項目: 表15-8

および

ユーザー・ログイン時のシングル・サインオンCookieについて

問合せ文字列ベースのHTTPリソース定義

アクセス・ポリシー内でサポートされます。表17-1「リソース定義の要素」を参照してください。

このポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。

ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。

ルール

認可ポリシーとトークン発行ポリシーのみで利用可能です。

各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。

ルールは、次で説明されている認可条件を参照します。

関連項目: 認可ポリシー・ルールおよび条件の概要

ポリシーは(いくつかのポリシー要素の中で)認証ルールを使用して定義します。認可ルールの概要は次のとおりです。

- ポリシーの外部で定義され(ただし、スコープはポリシー・ドメイン内)、ポリシー内で参照されます。

- 2箇所に出現: 1)ドメインのデフォルト・ルールの内容および2)ポリシー定義内

各ルールは、誰(どのユーアー、グループまたはIP4アドレス)がアクセスを許可または拒否されるか、およびそのルールが適用される期間を指定します。

また、許可を拒否よりも優先するかどうかの条件も指定できます。

条件

認可ポリシーとトークン発行ポリシーのみで利用可能です。

各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。

条件は、ルールの外部で宣言され、ルール内から参照されます。

関連項目: 認可ポリシー・ルールおよび条件の概要

なし

22.4 IAMSuiteAgentの集中ログアウト構成

IAMSuiteAgentは、OAMサーバーに対して集中ログアウトを行うために必要なログアウト・パラメータによって事前構成されています。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. 「保存」をクリックします。

5. 次の項目へ進みます。

- 「アプリケーション・ドメインでの認証と認可の検証」

- 第18章「アクセス・テスターを使用した接続性とポリシーの検証」

22.5 Access Manager 11gを使用した10g Webgateのリモート登録

レガシー10g Webgateがインストールされているか、Access Manager 11gで使用する新しい10g Webgateインスタンスをインストールするかにかかわらず、Access Manager 11gの認証および認可サービスを使用するようにWebgateを登録する必要があります。

Oracle Access Managementコンソールまたはリモート登録ツールを使用して、このタスクを実行できます。リモート登録ツールでは、テンプレートを使用して、登録前にすべてのWebgateパラメータを指定できます。

次の手順によって、リモート登録ツールを使用してインバンド・モードでのプロビジョニングのウォーク・スルーが行えます。この例では、OAMRequest_short.xmlをテンプレートとして使用してmy-10g-agent1という名前のエージェントを作成し、/.../*の保護と、パブリック・リソース、/public/index.htmlの宣言を行います。実際の値はこれとは異なります。完全な登録テンプレートを使用して、パブリック・リソース、プライベート・リソースおよび除外されたリソースを指定できます。

関連項目:

必要に応じて次を参照してください。

- 「IAMSuiteAgentの10g Webgateへの置換」

- 「OAMエージェントのリモート登録の実行」

Access Manager 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)に、状況(クライアント側またはサーバー側)と 表13-5の情報に応じた次の環境変数を設定します。
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://ruby.uk.example.com:7001</serverAddress>
<hostIdentifier>my-10g</hostIdentifier>
<agentName>my-10g-agent1</agentName>
<autoCreatePolicy>true</autoCreatePolicy>
<primaryCookieDomain>.uk.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. 登録時に作成されたObAccessClient.xmlファイルは、ここでは無視します。

5. Oracle Access Managementコンソールにログインして、次のようにリソースを新しい登録に追加します。

1. 「システム構成」タブの「Access Manager」セクションで、次のノードを開いて「検索」コントロールを表示します。
システム構成
Access Manager
SSOエージェント
OAMエージェント

2. 「検索」コントロールを使用して、目的のWebgate登録ページを見つけて、そのページを開くために「結果」表内の名前をクリックします。

3. OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します(表5-3を参照)。

6. リソースをアプリケーション・ドメインに追加します(「表17-1」を参照)。

7. それぞれの環境で必要に応じて次に進んでください。

- Webgateの終了: 「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」

- アンインストールしたWebgate: 「Access Manager 11g用の最新の10g Webgateの検索およびインストール」

- オプション: 「IAMSuiteAgentの10g Webgateへの入れ替え」

- オプション: 「10g OAMエージェントのリモート登録」

22.6 10g OAMエージェントのリモート登録

この項では、「エージェントのリモート更新の概要」で説明したリモート登録テンプレートとモードを使用して、OAM 10gエージェントを更新、検証および削除する方法について説明します。

OAM 10gエージェント登録をリモート更新するには

1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

2. エージェントの更新:

1. OAMUpdateAgentRequest.xmlテンプレートを使用して、更新リクエストを作成します。

2. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:

./bin/oamreg.sh agentUpdate input/*OAMUpdateAgentRequest.xml

3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

4. 画面のメッセージで成功したことを確認します。

5. 次のように、エージェント・ホストObAccessClient.xmlを再配置します。
再配置元AdminServer(コンソール)ホスト: /rreg/output/Agent_Name/

再配置先エージェント・ホスト: $10gWG_install_dir/oblix/lib例:

$WebTier_Middleware_Home/Oracle_WT1/instance1/ config/OHS/ohs1/oblix/lib

6. このエージェントをホストするOAMサーバーを再起動します。

3. エージェントの検証:

1. エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:

./bin/oamreg.sh agentValidate agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。

4. エージェントの削除:

1. エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:

./bin/oamreg.sh agentDelete agentname

2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

3. 画面のメッセージで成功したことを確認します。
成功: 画面のメッセージを確認します。

AgentDeleteプロセスは正常に完了しました。

22.7 Access Manager 11g用の最新の10g Webgateの検索とインストール

Access Manager 11gで使用する新規10g Webgateをインストールする場合は、この項の手順を使用します。それ以外の場合は、この項はスキップして「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進みます。

タスクの概要: Webgateのインストール

1. Access Manager 11gで使用する新規10g Webgateのインストールの準備

2. Access Manager 11gで使用する10g Webgateの検索とダウンロード

3. Webgate 10gのインストールの開始

4. トランスポート・セキュリティ・モードの指定

5. Webgateの構成詳細の指定

6. セキュアな通信のための証明書のリクエストまたはインストール

7. Webgate Webサーバー構成の更新

8. Webgateのインストール終了

9. アーティファクトと証明書のインストール

10. Webgateのインストールの確認

22.7.1 Access Manager 11gで使用する新規10g Webgateのインストールの準備

表22-4に、10g Webgateのインストール開始前に満たしておく必要のある要件を示します。

表22-4 Access Manager 11gで使用する10g Webgateのインストールの準備

情報

説明

サポートされている最新のWebgate

Access Manager 11gでは、サポートされている最新の10g (10.1.4.3) Webgateを必ず使用してください。ただし、該当する10g (10.1.4.3) Webgateが提供されていない場合は、その次に新しいWebgate(10g (10.1.4.2.0)を使用してください。

関連項目: 「Access Manager 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サーバーを構成していることを確認します。

付録Cも参照してください

コンピュータ・レベルと仮想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サーバー

Access Manager 11gは、SSLが有効または無効なApacheをサポートするコンポーネント用に単一パッケージを提供しています。

- APACHE2_Webgateは、SSLが有効または無効なv2(およびリバース・プロキシが有効または無効なSolarisおよびLinux)をサポートしています。第23章も参照してください。

- APACHE22_Webgateは、SSLが有効または無効なv2.2(およびリバース・プロキシが有効または無効なSolarisおよびLinux)をサポートしています。第23章も参照してください。

注意: SSL対応の通信用に、Access ManagerはApache-SSLではなく、mod_sslのApacheのみをサポートしています。mod_sslはApache-SSLから派生した代替品です。

IBM HTTP Server (IHS) v2 Webサーバー:

IHS2_WebgateはIBM-AIX上でApache v2により稼動しています。Access Managerは、SSLが有効または無効なIHS v2およびIHS v2リバース・プロキシ・サーバーをサポートしています。

詳細は第23章を参照してください

Domino Webサーバー:

10g WebgateをDomino Webサーバーにインストールする前に、Domino Enterprise Server R5を正しくインストールし、設定しておく必要があります。

関連項目: 第26章「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内にあります。複数のインストールを実行すると、このファイルのバージョンが複数作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。この場合は、webgate.dllとpostgate.dllが1つずつ存在していることを検証する必要があります。

関連項目: 第25章「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を検索します。

関連項目: 第24章「10g Webgate用のISAサーバーの構成」

22.7.2 Access Manager 11gで使用する10g Webgateの検索とダウンロード

必要に応じて、次の手順を使用して10g Webgateを取得します。ご使用のWebサーバーに適したインストール・パッケージを選択してください。

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のインストールの開始」に進みます。

22.7.3 Webgate 10gのインストールの開始

次の手順によって、Webサーバー・タイプに関係なく共通のウォーク・スルーを行います。

インストール・オプションを識別し、自分の環境に合わない場合はスキップできます。Webgateのインストール中は、特定の時点で情報が保存されます。Webgateのインストール処理は必要に応じて取り消すことができます。ただし、Webgateのインストールを知らせるメッセージを受領後にWebgateのインストールを取り消す場合は、コンポーネントのアンインストールが必要です。

注意:

HP-UXおよびAIXシステムでは、-is:tempdirパス・パラメータを使用して、十分な領域があるディレクトリにインストールを指示できます。パスは、十分な領域があるファイル・システムへの絶対パスでなければなりません。

Webgate 10gのインストールの開始手順

1. Webgate 10gをホスティングするコンピュータ上で、Webサーバーの管理者権限のあるユーザーとしてログインします。

2. Webサーバー・インスタンスを停止します。

3. 該当するプラットフォーム、インストール・モード、Webサーバー用のWebgateインストーラを起動します。例:

4. 「ようこそ」画面を閉じます(管理者権限で画面に表示された指示に従います)。

5. Webgateのインストール・ディレクトリを指定します。

6. LinuxまたはSolaris: このコンピュータ上のGCCランタイム・ライブラリの場所を指定します。

7. 言語パック—デフォルトのロケールとインストールするその他のロケールを選択して、次へをクリックします。

8. プレゼンテーション・ワークシートにインストール・ディレクトリをまだ記録していない場合は記録し、次へをクリックして続行します。
Webgateのインストールが開始し、数秒間かかることがあります。Windowsシステムでは、Microsoft管理インタフェースの構成を知らせる画面が表示されます。

インストール・プロセスはまだ完了していません。トランスポート・セキュリティ・モードの指定を求められます。この時点では、情報のリストアに戻れません。

9. 必要に応じて、ダウンロード済のGCCライブラリを解凍した場所を指定します。

22.7.4 トランスポート・セキュリティ・モードの指定

少なくとも1つのOAM Server間のトランスポート・セキュリティは一致する必要があります。

関連項目:

付録C

トランスポート・セキュリティ・モードの指定手順

1. Webgate用に、「オープン」、「簡易」または「証明書」を選択します。

2. 指定したトランスポート・セキュリティ・モードに従って進みます。

- 簡易または証明書モード—「セキュアな通信のための証明書のリクエストまたはインストール」に進みます。

- オープン・モード—「Webgate Webサーバー構成の更新」までスキップします。

22.7.5 安全な通信のための証明書の要求またはインストール

Access Manager 11g環境でオープン・モード・トランスポート・セキュリティを使用する場合は、「Webgate Webサーバー構成の更新」までスキップできます。

Webgate証明リクエスト: OAMサーバーに信頼されているルートCAに送信する必要があるリクエスト・ファイル(aaa_req.pem)を生成します。ルートCAは、Webgate用にインストール可能な署名付きの証明書を返します。

リクエストした証明書を\Webgate_install_dir\access\oblix\configディレクトリにコピーし、Webgate Webサーバーを再起動する必要があります。

関連項目:

付録C

Webgate 10g用の証明書をリクエストまたはインストールする手順

1. 証明書をリクエストするのか、インストールするのかを指定し、次へをクリックして続行します。例:

- 証明書をリクエストする場合は、手順2に進みます。

- 証明書をインストールする場合は、手順3に進みます。

2. 証明書をリクエストします。

- リクエストされた情報を入力し、次に次へをクリックして、証明書のリクエストをCAに発行します。

- 証明書のファイルの場所が表示された場合は、それを記録します。

- 証明書がある場合ははいをクリックして、手順3から続行します。それ以外の場合は、「Webgate Webサーバー構成の更新」までスキップします。

3. インストール中に証明書をインストールする場合: 次のファイルへの絶対パスを指定して、次へをクリックします。
Webgate_install_dir\access\oblix\config

- cacert.pemはOracleが提供したopenSSL認証局の署名を受けた証明書リクエストです。

- password.xmlには、インストール中に指定されたランダムなグローバル・パスフレーズが不明瞭化された形式で含まれています。これを使用して、他の顧客が同一CAを使用しないようにします。Access Managerは、OAM AgentとOAM Server間の初期ハンドシェイク中に追加のパスワード・チェックを行います。

- aaa_key.pemには秘密鍵(openSSLによって生成)が含まれています。

- aaa_cert.pemはPEM形式の署名済証明書です。

- 「Webgate Webサーバー構成の更新」に進みます。

22.7.6 Webgateの構成詳細の指定

Access Manager 11gでのWebgateのプロビジョニングと登録の間に指定した情報を使用して次のタスクを実行します。

Webgateの構成詳細の指定手順

1. アクセス・システム・コンソールで指定した、Webgateに必要な情報を提供します。

- Webgate ID—登録中に指定したエージェント名を入力します。

- Webgateパスワード—登録中にパスワードを指定した場合は、それを入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。

- アクセス・サーバーID—必要な場合は、このWebgateを登録したOAMサーバーを入力するか、選択した任意の名前を使用します。

- アクセス・サーバー・ホスト名—このWebgateを登録するOAMサーバーのDNSホスト名を入力します。

- ポート番号—OAM Proxyプロキシが実行中のポートを入力します。プロビジョニング中にポートを入力しなかった場合のデフォルト・ポートは3004です。

2. 次へをクリックして続行します。

22.7.7 Webgate Webサーバー構成の更新

WebサーバーがWebgateと連動するように構成する必要があります。インストール時に自動的にWebサーバー構成を更新することをお薦めします。ただし、自動および手動の両方の更新手順が含まれています。

注意:

Webサーバーの手動構成手順

1. 自動更新に進むかどうかを尋ねられたら「いいえ」をクリックし、次に「次へ」をクリックします。

2. Webgate Webサーバーの手動設定をサポートするために表示される画面を確認し、「Webサーバーの手動構成」を参照します。

3. Webgateのインストール画面に戻り、「次へ」をクリックして、「Access Manager 11gを使用した10g Webgateのリモート登録」の手順に進みます。

Webサーバーの自動構成手順

1. はいをクリックしてWebサーバーの自動更新を行い、次へをクリックします(またはいいえをクリックして「Webサーバーの手動構成」を参照します)。

- ほとんどのWebサーバー—Webサーバー構成ファイルを含むディレクトリの絶対パスを指定します。

- IIS Webサーバー—プロセスがすぐに開始し、1分以内に終了します。詳細は、第25章「10g Webgate用のIIS Webサーバーの構成」を参照してください。
続行する前に特殊な指示があるかもしれません。NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。

- Sun Webサーバー—続行する前に、必ずWebサーバー管理コンソールで変更を適用しておいてください。

Webサーバーの構成が更新されたことを知らせる画面が表示されます。

2. 「次へ」をクリックして「Webgateのインストール終了」に進みます。

22.7.7.1 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サーバーが該当するAccess Managerファイルを認識できるように、元の設定指示に戻って、すべての指示内容を完了したことを確認します。

注意:

間違ってウィンドウを閉じてしまった場合は、手順1に戻って、該当するリンクを再度クリックします。一部の設定では新しいブラウザ・ウィンドウが開いたり、コマンドウィンドウへの入力が求められることがあります。

3. 「Webgateのインストール終了」に進みます。

22.7.8 Webgateのインストール終了

ReadMe情報に、マニュアルとOracleに関する詳細が記載されています。

注意:

64ビットのIIS Webgateをインストールする場合は、「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を使用する場合は、Access ManagerのWebgateのインストール時に、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。

- Apache2、OHS2、IHS2 Webサーバー: 第23章「Apache、OHS、IHSの10g Webgate用の構成」

- IIS Webサーバー: Webgateのインストール後に、net stop iisadminおよびnet start w3svcを使用してメタベースが破損していないことを確認します。第25章「10g Webgate用のIIS Webサーバーの構成」も参照してください。

- ISA Webサーバー: 第24章「10g Webgate用のISAサーバーの構成」

- Lotus Domino Webサーバー: 第26章「10g Webgate用のLotus Domino Webサーバーの構成」

5. 「アーティファクトと証明書のインストール」に進みます。

22.7.9 アーティファクトと証明書のインストール

ObAccessClient.xmlファイルはプロビジョニングで生成されるものの1つです。Webgateのインストール後、このファイルをWebgateインストール・ディレクトリ・パスにコピーする必要があります。Webgateのインストール後に署名済のWebgate 10g証明書を受領した場合、次の手順に従ってインストールできます。

前提条件

Webサーバーの構成

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サーバーを再起動します。

22.7.10 Webgateのインストールの確認

WebgateのインストールとWebサーバーの更新後、Webgateの診断を有効にしてWebgateが正しく実行されていることを確認できます。

Webgateの診断確認手順

1. Access Manager 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が正常に機能しています。ページを閉じてください。「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進みます。

注意:

IAMSuiteAgentをこのWebgateに入れ替える場合は、「WebLogicサーバー・プラグインの更新」に進みます。

- 失敗した場合: 「Access Manager 11gデプロイメントからの10g Webgateの削除」の説明に従って、Webgateをアンインストールして再インストールする必要があります。

22.8 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

この項の内容は次のとおりです。

- 10g OAMエージェントと11g OAMサーバー使用時の集中ログアウトについて

- 11g OAMサーバー使用時の10g Webgateの集中ログアウト・スクリプトについて

- Access Manager使用時の10g Webgateの集中ログアウト構成

22.8.1 11g OAMサーバー使用時の10g Webgateの集中ログアウト処理について

次のプロセス概要では、Access Managerの集中ログアウト・プロセスを要約して示しますが、このプロセスが発生するのは、保護機能を果たす10g Webgateが構成されたWebサーバー上にアプリケーションがデプロイされたときです。

ログアウトは、登録されたOAMエージェント(この場合は10g Webgate)に対して構成されたlogout.htmlファイルがアプリケーションによって起動されると開始されます。

プロセス概要: 11g OAMサーバー使用時の10g Webgateの集中ログアウト

1. アプリケーションが、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を含むページをユーザーのブラウザに送信します。

注意:

Logout Callback URLは、「OAM Webゲートの作成ページとパラメータについて」で説明するように、拡張されたOAMエージェント登録ページで指定します(または、表13-3「拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素」で説明するリモート登録テンプレートで指定します)。

3. コールバック・ページから、各Webgateの特定URIに対して新しいリクエストが開始されます。このリクエストが特定ドメインの特定Webgateに届くと、そのドメインのObSSOCookieは消去されます。

4. ユーザーは、ログアウト・スクリプト内のend_urlにリダイレクトされます。ただし、end_urlパラメータがない場合はOAMサーバーによって適切なメッセージが送信されます。

詳細は、「11g OAMサーバー使用時の10g WebGateの集中ログアウト・スクリプトについて」を参照してください。

22.8.2 11g OAMサーバー使用時の10g Webgateの集中ログアウト・スクリプトについて

10g Webgateでは、シングルおよびマルチ両方のDNSドメイン集中ログアウト処理にlogout.htmlスクリプトが必要です。logout.htmlは、実際にログアウトを行うJavaScriptsをアクティブにします。

注意:

11g Webgateではlogout.htmlスクリプトを使用しないかわりに、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に示すようにエージェント登録をさらに詳細に構成する必要があります。

例22-1は、ユーザー固有の環境に合せて一定の行を編集することによりテンプレートとして使用できる、logout.htmlスクリプトです(編集の必要性についてはスクリプトの最上部に記述されています)。たとえば、SERVER_LOGOUTURLを変更する必要があります。この例の後に追加的情報を示します。

例22-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 Server is running.
//b. "port" to point to the port where the OAM 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内のログアウト・リンク指定方法を表22-5に示します。

表22-5 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

22.8.3 Access Manager使用時の10g Webgateの集中ログアウト構成

次の手順では、Access Manager使用時の10g Webgateの集中ログアウト構成方法を示します。

注意:

オプションのタスクや、マルチDNSドメインのログアウトだけに必要なタスクは識別されているので、必要な場合以外はスキップすることができます。

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載された手順例には、WebLogic Serverドメインにアプリケーションをデプロイする手順が含まれています。

タスクの概要: 10g Webgateの集中ログアウトの構成

1. デフォルトのログアウト・ページ(logout.html)を作成し、Webgateインストール・ディレクトリ上でそのページを使用できるようにします。

1. 例22-1「logout.htmlスクリプト」に基づいて、Webgate用のlogout.htmlを作成および編集します。

2. 作成または編集したogout.htmlスクリプトを以下のディレクトリ・パスに保存します。

Webgate_install_dir/oamsso/logout.html

注意:

logout.htmlを他の場所に置く場合は、エージェント登録時にログアウト・リンクを正しく指定してlogout.htmlファイルの正しい場所を参照するようにしてください。

3. 必要に応じて以下のステップを実行します。

2. ステップ1にあるlogout.htmlで、ユーザーを11g OAMサーバー上のこの中央管理ログアウトのURI(/oam/server/logout)にリダイレクトする設定になっていることを確認します。

3. オプション: 「logout.html内のend_urlパラメータのガイドライン」に示すように、アプリケーションが、ログアウト後にユーザーがリダイレクトされる場所を示すend_urlパラメータを渡せるようにします。

4. 10g Webgateが構成されているWebサーバー・ファイルを確認し、次の説明に従って適切な手順を実行します。

- OHS Webサーバーのhttpd.confファイル: 次の行が存在する場合、それらを削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

- その他のWebサーバーの構成ファイル: 次の行を追加します。

Alias /oamsso "WebgateInstallationDirectory/oamsso"

22.9 IAMSuiteAgentの10g Webgateへの置換

IAMSuiteAgentを10g Webgateと入れ替えていない場合は、この項をスキップしてください。

Access ManagerおよびOracle Identity Managerは、Oracle Fusion Middleware 11gコンポーネントの一部です。WebLogicサーバー構成ウィザードの初期構成中に、IAMSuiteAgentがIDMドメイン・ホスト識別子およびそのエージェントに指定されたアプリケーション・ドメインとともにAccess Manager 11gに登録されます。

Oracle Fusion MiddlewareはIAMSuiteAgentを使用して、保護されたOracle Identity ManagementコンソールにAccess Manager 11gをそのまま使用します。

コンテナ外のアプリケーションを保護するために、IAMSuiteAgentを10g Webgateに入れ替えることができます(事前登録済のIAMSuiteAgentと同じアプリケーション・ドメインとポリシーを使用して、同じアプリケーション・セットを保護する場合)。

タスクの概要: IAMSuiteAgentの10g Webgateへの置換

1. IAMSuiteAgentの入替え用10g Webgateの登録

2. IAMSuiteAgentの入替え用10g Webgateのインストール

3. WebLogicサーバー・プラグインの更新

4. オプション: OAM/OIM統合用のAutoLoginホスト識別子の確認

5. オプション: WebLogic用のOAMセキュリティ・プロバイダの構成

6. オプション: IAMSuiteAgentの無効化

7. 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

8. 検証

22.9.1 IAMSuiteAgentの入替え用10g Webgateの登録

次に示す手順では、帯域内モードでリモート登録ツールを使用して、入替え用10g Webgateを登録する方法を順に説明します。

関連項目:

- リモート登録ツール、処理、リクエスト・ファイルの詳細は、第13章を参照

この例では、OAMRequest_short.xmlをテンプレートとして使用して、10g4IDMという名前のエージェントを作成し、/.../*の保護と、パブリック・リソース/public/index.htmlの宣言を行います。実際の値はこれとは異なります。

注意:

入替え用のWebgateでIAM Suiteポリシーを使用するには、IAMSuiteAgentホスト識別子と優先ホストを使用するようにWebgateの登録が構成されていることを確認します。

10g Webgateを入替え用のIAMSuiteAgentに登録するには:

1. リモート登録ツールを入手して、環境に合ったスクリプトを設定します。例:

1. 次のパスにあるRREG.tar.gzファイルを探します。

ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz

2. RREG.tar.gzファイルを別な場所に解凍します。例: rreg/bin/oamregなど。

3. oamregスクリプトに、状況(クライアント側またはサーバー側)と 表13-5の情報に応じた次の環境変数を設定します。
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://ruby.uk.example.com:7001</serverAddress>
<hostIdentifier>10g4IAM</hostIdentifier>
<agentName>10g4IAM</agentName>
<autoCreatePolicy>false</autoCreatePolicy>
<primaryCookieDomain>.uk.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 Managementコンソールにログインして、新規登録を確認します。

1. 「システム構成」タブの「Access Manager」セクションで、次のノードを開きます。
システム構成
Access Manager
SSOエージェント
OAMエージェント

2. エージェント名をダブルクリックして、登録ページを表示し、詳細を確認します(新規Webgateをインストールする場合は、インストール中に次の詳細を入力する必要があります)。例:
エージェント名—Webgateのインストール中にWebgate IDとして入力します。

アクセス・クライアント・パスワード—Webgateのインストール中に、Webgateのパスワードとして入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。

アクセス・サーバー・ホスト名—このWebgateを登録するプライマリOAMサーバーのDNSホスト名を入力します。

3. OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します。

5. プロビジョニングの結果作成されるObAccessClient.xmlファイルは無視してください。

6. 「WebLogicサーバー・プラグインの更新」に進みます。

22.9.2 IAMSuiteAgentの入替え用10g Webgateのインストール

プロビジョニング後、IAMSuiteAgentと入れ替えるために10g Webgateをインストールする必要があります。インストール中は、プロビジョニング時と同じWebgateの情報を提供する必要があります。

前提条件

IAMSuiteAgentの入替え用10g Webgateの登録

タスクの概要: Webgateのインストール

1. Access Manager 11g用の最新の10g Webgateの検索とインストール

2. IAMSuiteAgentの入替え: 「WebLogicサーバー・プラグインの更新」に進みます。

22.9.3 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です)。例では実装のための正確な構文を示します。

例22-2では入力サンプルを使用して変更が必要な部分を示します。使用する環境によって入力内容は異なります。

例22-2 mod_wl_ohs.confでの10g Webgate用の更新

<IfModule weblogic_module>
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost ruby.uk.example.com
WebLogicPort    6162
</Location>
<Location apmmconsole>
SetHandler weblogic-handler
WebLogicHost ruby.uk.example.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要素を含むようにファイルを編集します(例22-2を参照)。

3. ファイルを保存します。

4. Webサーバーを再起動します。

5. 必要に応じて次のタスクに進みます。

- OAM/OIM統合用のAutoLoginホスト識別子の確認

- WebLogic用のOAMセキュリティ・プロバイダの構成

22.9.4 OAM/OIM統合用のAutoLoginホスト識別子の確認

このトピックではAccess ManagerがOracle Identity Manager(OIM)と統合されている場合に、OIMの自動ログイン機能を確認(または構成)する方法を説明します。

注意:

Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。

Oracle Identity ManagerがAccess Manager 11gに統合されている場合、AutoLogin機能では、IAMSuiteAgentのホスト識別子リスト内に10g Webgate Webサーバーのホスト名とポートが含まれている必要があります。

注意:

10g Webgate Webサーバーの前にロード・バランサがある場合、ステップ3でロード・バランサのホスト名とポートを含む必要があります。

agentBaseUrlパラメータを使用して特定のホスト識別子を更新します。ただし、自動ポリシーの作成がfalseに設定されている場合、リモート登録ユーティリティはアプリケーション・ドメインを作成せず、agentBaseUrlパラメータを参照しません。

次の手順では、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セキュリティ・プロバイダの構成」に進みます。

22.9.5 WebLogic用のOAMセキュリティ・プロバイダの構成

この項では、Access Manager 11gと10g Webgateを使用してシングル・サイン・オンが行えるように、WebLogicセキュリティ・プロバイダを構成する方法を説明します。

注意:

Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。

10g Webgate用のセキュリティ・プロバイダの設定の詳細は、次のトピックを参照してください。

- セキュリティ・プロバイダについて

- 10g Webgate用のセキュリティ・プロバイダの設定

22.9.5.1 セキュリティ・プロバイダについて

IAMSuiteAgentを10g Webgateに入れ替える場合に、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プロバイダの構成詳細が記載されています。

Access Manager JARは、Oracle Fusion Middleware製品(Oracle Identity Management、Oracle SOA Suite、またはOracle WebCenter)のインストール時に使用可能な認証プロバイダのWARファイルです。Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っています。

- oamAuthnProvider.jar: シングル・サインオン用のAccess Manager IDアサーション・プロバイダのファイルとOracle WebLogic Server 10.3.1以降の認証プロバイダのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web(非HTTP)リソースに対するリクエストを処理するために、カスタムのAccess Managerアクセス・ゲートも用意されています。

- oamauthenticationprovider.war: Oracle WebLogicサーバー・コンソールに表示されるプロバイダ・リストを、Access Managerで使用する必要があるもののみに限定します。
拡張をデプロイする際に、管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更管理プロセスに関与します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server管理コンソールの拡張』を参照してください。

22.9.5.2 10g Webgate用のセキュリティ・プロバイダの設定

次の手順にはWebLogicサーバー管理コンソールが必要です。この例では、Oracle Internet DirectoryプロバイダをOAM Identity Asserterおよびデフォルト・オーセンティケータで設定する方法を示します。OVDの場合も必要な手順は同じです。

注意:

Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っているので、次の手順1をスキップできます。ただしFusion Middlewareアプリケーションがない場合は、スタンドアロンOracle WebLogicサーバーなので、手順1で説明したようにOracle Technology NetworkからJARおよびWARファイルを入手する必要があります。

前提条件

WebLogicサーバー・プラグインの更新

10g WebgateとAccess Manager 11g用のプロバイダをWebLogicサーバー・ドメインに設定する手順

1. Oracle Fusion Middlewareアプリケーションがない場合: Access Managerプロバイダを次の手順で入手します。

1. 次のOracle Technology Networkにログインします。

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. 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: 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が[セキュリティ・プロバイダについて」に記載された正しい場所にあることを確認します。

22.9.6 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サーバーを再起動します。

3. 「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進んでから、「検証」に戻ります。

22.9.7 検証

10g Webgateを使用してそれぞれの環境をテストし、IAMSuiteAgentで保護されていたすべてのアプリケーションが、10g Webgateの構成後も保護されていることを確認するようお薦めします。

前提条件

「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」

関連項目:

- 「アプリケーション・ドメインでの認証と認可の検証」

- 第18章「アクセス・テスターを使用した接続性とポリシーの検証」

22.10 Access Manager 11gデプロイメントからの10g Webgateの削除

必要に応じて、次の手順を使用して、Access Manager 11gデプロイメントから10g Webgateを削除します。

注意:

エージェントの登録を削除しても、関連付けられたホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント・インスタンスは削除されません。

考慮事項

Webサーバーの構成変更: Webサーバーの構成変更は、Webgateのアンインストール後に手動で元に戻す必要があります。追加内容の詳細は、お使いのWebサーバーに該当する章を参照してください。

Webgate IISフィルタ: Webgateおよび関連するフィルタをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。詳細は、「Access Manager 11gデプロイメントからの10g Webgateの削除」を参照してください。

前提条件

このエージェントに関連付けられたアプリケーション・ドメイン、リソースおよびポリシーを評価し、別のエージェントを使用するように構成されているのか、削除できるのかを確認してください。

10g Webgateのアンインストール手順

1. 削除するWebgateのWebサーバーを無効にします。

注意:

Webサーバーを無効にしなかった場合、アンインストールは失敗し、バックアップ・フォルダは削除されません。この場合、バックアップ・フォルダを手動で削除する必要があります。

2. Oracle Access ManagementコンソールのWebgate登録ページで、「状態」オプションの横の「無効」ボックスをクリックしてWebgateを無効化します。

3. 言語パック: インストールされている言語パック(デフォルトの管理者言語(ロケール)として選択されているものを除く)を次のように削除します。

- コンポーネントのアンインストール・ディレクトリ内にある、該当する言語パックを検索します。例:
Webgate_install_dir\uninstIdentityLP_fr-fr
\uninstaller.exe

- 言語パック・アンインストーラ・プログラムを実行して、ファイルを削除します。

- このプロセスを繰り返し実行して、関連するコンポーネントから同じ言語パックを削除します。

- Webgate Webサーバーを停止して再起動し、適切な言語サポートを再初期化します。

- このプロセスを繰り返し実行して、各言語パックを削除します(デフォルトの管理者言語(ロケール)として選択されているものを除く)。

4. 次の手順を実行して10g Webgateの構成データを削除します。

- Access Managerコンポーネントのインスタンスが1つしかない場合は、手順4を完了して削除します。

- コンポーネントのインスタンスが複数ある場合は、手順5も参照してください。

5. 特定のプログラムのアンインストール・プログラムを検索して実行し、Access Managerファイルを削除します。例:
Webgate_install_dir\access\_uninstWebgate\uninstaller.exe

注意:

UNIXシステムではuninstaller.binを使用します

6. 複数のインスタンス: 複数のWebgateインスタンスがあり、そのうちの1つ、またはすべてを削除する場合は、プラットフォーム固有のメソッドを使用する必要があります。

- Windows: 最後のコンポーネントは、プログラムの追加/削除でアンインストールできます。それ以外は、\access \uninstComponentディレクトリからアンインストール・プログラムを実行してアンインストールできます。

- UNIX: 常にuninstaller.binを実行する必要があります。

7. Webサーバー構成に対するAccess Manager関連の更新を削除します。特定のWebサーバーに関する詳細は、第23章、 第25章、第24章、および第26章を参照してください。

8. Webサーバーを再起動します。

9. 特に再インストールを予定している場合、Webgate_install_dirディレクトリが残っていれば削除します。

23 Apache、OHS、IHSの10g Webgate用の構成

Oracleは、Apache v2で稼動するWebサーバー用のWebgateを提供しています。これにはApache、Oracle HTTP ServerおよびIBM HTTP Server (IHS)が含まれています。

この章では3つのWebサーバー・タイプの構成に関して次を含む詳細を説明します。

- Oracle HTTP ServerとAccess Managerについて

- ApacheおよびIHS v2 Webgateを使用したAccess Managerについて

- Apache v2アーキテクチャとAccess Managerについて

- Oracle HTTP Server、IHS、Apache v2 Webサーバーの要件

- Webサーバーの準備

- Apache v2およびIHS v2のリバース・プロキシの起動

- Webgate用のhttpd.conf更新の検証

- Access Manager用のOracle HTTP Server Webgateのチューニング

- OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング

- Oracle HTTP Server Webサーバーの起動と停止

- Access Manager用のApache/IHS v2 Webgateのチューニング

- アンインストール後のWebサーバー構成変更の削除

- 役立つ情報

23.1 前提条件

Oracle Access Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシー強制エージェントの紹介」

- 「Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて」

23.2 Oracle HTTP ServerとAccess Managerについて

Oracle HTTP Server用の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リリースがAccess Managerで動作します。

Oracle HTTP Server 11g: 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コンポーネント要件を必ず把握しておいてください。

23.3 ApacheおよびIHS v2 Webgateを使用したAccess Managerについて

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。

注意:

最新の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

Access Managerの以前のリリースには、プレーン・モードとSSL対応モード用に別なプラットフォーム固有のインストール・パッケージが含まれていました。たとえば各プラットフォームに対して、APACHE_WebgateおよびAPACHESSL_Webgateという2つのWebgateファイルが提供されていました。

これらのWebサーバーをサポートするために、Access Managerコンポーネントには機能的な変更はありません。Access Managerの認証は、HTTP基本認証、フォーム、またはSSLクライアント証明書を使用して、Webgateを介して行われます。認証済ユーザーによるWebリソースの許可、他のWebサーバーやアプリケーションとの簡易およびマルチドメインSSOもWebgateを介して行われます。

23.3.1 Apache HTTP Serverについて

Apache HTTP Serverは、Apache Software Foundationのオープン・ソースHTTP Webサーバー・プロジェクトです。プロジェクトの目的は、現在のHTTP標準に合った安全で効率のよい、拡張性のあるサーバーおよびHTTPサービスを提供することです。

詳細は、「Apache v2アーキテクチャとAccess Managerについて」を参照してください。

23.3.2 IBM HTTP Serverについて

IBM HTTP Server (IHS)はApache v2のバリエーションです。IBM HTTP ServerはThe Apache Groupの開発したソフトウェアに基づいています。IBM HTTP Serverコンポーネントには、OpenSSL Projectが開発したソフトウェアおよびEric Youngが開発したソフトウェアも含まれています。

ApacheアーキテクチャとAccess Managerに関する「Apache v2アーキテクチャと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

23.3.3 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サーバーの要件」を参照してください。

23.4 Apache v2アーキテクチャとAccess Managerについて

Apache v2 Webサーバーは、スレッドセーフのAccess Managerライブラリと互換性のある、ハイブリッドのマルチスレッド、マルチプロセス・アーキテクチャを提供します。

重要:

特に明記しないかぎり、ここに示す詳細な説明は、10g Webgate用のApache v2とIHS v2 Webサーバーに同様に適用されます。

標準モジュール・セット以外に、Apache v2 Webサーバーにはコンピュータ上のネットワーク・ポートをバインドし、プロセス・リクエストの受付けと処理を行うマルチプロセス・モジュール(MPM)が含まれています。ApacheまたはIHS v2のWebgateをインストールする前に、適切な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です。ワーカーMPMはハイブリッド・マルチプロセス、マルチスレッド・サーバーを実装します。このMPMをを制御するために最も重要なディレクティブは、ThreadsPerChildおよびMaxClientsです。詳細は、「Access Manager用のApache/IHS v2 Webgateのチューニング」を参照してください。

Apache v2 WebサーバーにはApache Portable Runtime (APR)ライブラリが含まれており、プラットフォーム固有の実装へのインタフェースを提供し、プラットフォームに関係なく同一の動作が行われない場合はAPI開発者に事前に通知し、条件付きコンパイルの#lfdefsの必要性をなくします。include/apu_compat.hファイルでは下位互換性がサポートされていますが、Apache v2 APRの使用をお薦めします。

詳細はご使用のApache v2のドキュメントを参照してください。「Access Manager用のApache/IHS v2 Webgateのチューニング」も参照してください。

Apacheアーキテクチャは次の項で説明しているように、様々な方法で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サーバーの制限により、Access Managerのフォームベースの認証スキーム用に構成されたプラグインは次の場合に変数を渡しません。

- 後処理プログラムによってログイン資格証明を渡すために、オプションのチャレンジ・パラメータ、passthrough:Yesが認証スキームに含まれています。

- フォーム・アクションは受領したすべてのヘッダーと変数のダンプを作成するCGIスクリプトで、この方法はHTTP POSTメソッドを使用して呼び出されます。

例:

<html>
<form name="myloginform" action="/access/...cgi" method="post">

23.5 Oracle HTTP Server、IHS、Apache v2 Webサーバーの要件

Access Manager HTMLページではUTF-8エンコーディングを使用します。Apache、Oracle HTTP ServerおよびIBM HTTP Server (IHS)を含むApacheベースのWebサーバーでは、管理者はAddDefaultCharsetディレクティブを使用して、送信されたすべてのHTMLページのデフォルト文字セットを指定できます。このディレクティブは、HTMLページを生成するアプリケーションによって指定された任意の文字を無効にします。AddDefaultCharsetディレクティブがUTF-8以外の文字セットを有効にした場合、Access Manager HTMLページで文字化けが発生します。

OracleはWebサーバー構成ファイル(httpd.conf)でAddDefaultCharsetディレクティブを次のように指定し、Access Manager HTMLページが正しく表示されるようにすることをお薦めします。

AddDefaultCharset Off

このディレクティブの詳細は、ご使用のWebサーバーのドキュメントを参照してください。

次のトピックでは注意が必要な追加の詳細情報を提供します。

- IHS2 Webサーバーの要件

- ApacheおよびIHS v2リバース・プロキシ・サーバーの要件

- Apache v2 Webサーバーの要件

23.5.1 IHS2 Webサーバーの要件

ここでは、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からダウンロードできます。

23.5.2 ApacheおよびIHS v2リバース・プロキシ・サーバーの要件

前に説明したproxy_moduleによって、プロキシ/ゲートウェイが実装されます。クライアントは特殊な構成を行う必要はありません。proxy_moduleを使用してFTP、CONNECT (SSL用)、HTTP/0.9、HTTP/1.0、およびHTTP/1.1用のプロキシ機能を実装できますが、特定のAccess Manager ApacheおよびIHS v2 Webgateではリバース・プロキシ機能のみがサポートされています。

Apache Webサーバーの場合: 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のリバース・プロキシの起動」を参照してください。

23.5.3 Apache v2 Webサーバーの要件

ここでは、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: Access ManagerはSSL対応または非対応の通信機能を備えたApacheをサポートしています。基本のApache Webサーバーはブラウザ接続にSSLを使用せず、HTTPSリクエストに応答しません。SSL対応の通信用に、Access Managerはmod_ssl付きのApacheのみをサポートしています。SSL固有の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の構築では、追加の変数を設定する必要はありません。

23.6 Webサーバーの準備

Access Manager Webコンポーネントのインストール用にホスト・コンピュータを準備する方法と手順は、次のタスクの概要で説明しているように具体的なWebサーバーとプラットフォームによって異なります。

Access Managerでリバース・プロキシ機能を使用するには、「ApacheおよびIBM HTTPリバース・プロキシ・サーバーについて」で説明しているように、configureコマンドにプロキシ・モジュールを含む必要があります。「Apache v2およびIHS v2のリバース・プロキシの起動」も参照してください。

タスクの概要: Webサーバーの準備と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 Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Oracle Access Managementをインストールします。

4. 「Webgate用のhttpd.conf更新の検証」の説明に従って、Webサーバーの構成を終了します。

5. 必要に応じて次のトピックを参照してください。

- 「Access Manager用のOracle HTTP Server Webgateのチューニング」

- 「OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング」

- 「Access Manager用のApache/IHS v2 Webgateのチューニング」

注意:

次のすべての手順では、パス名変数、モジュール、およびオプションは手順を説明するためだけに提供されている例です。お使いの環境とは異なります。詳細は、お使いのWebサーバーのドキュメントを参照してください。

23.6.1 IHS v2 Webサーバーの準備

IHS v2 WebサーバーでIHS v2用のWebgateを受け入れて使用できるようにするには、環境や要件に応じて、次の手順の1つ以上を完了する必要があります。

- IHS v2インストール用ホストの準備

- IBM HTTP Server v2のインストール

- SSL機能の設定

- セキュアな仮想ホストの起動

- Apache v2およびIHS v2のリバース・プロキシの起動

該当する手順を完了すると、IHS v2用のWebgateをインストールする準備が整います。

23.6.1.1 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のインストール」に進みます。

23.6.1.2 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のリバース・プロキシの起動

23.6.1.3 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のリバース・プロキシの起動

23.6.1.4 セキュアな仮想ホストの起動

セキュアな仮想ホストを起動する必要がある場合は、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のリバース・プロキシの起動に進んでください。

23.6.2 Linux上でのApacheおよびOracle HTTP Server Webサーバーの準備

Linux上のApacheまたはOracle HTTP ServerにWebgateをインストールする場合、Webサーバーを実行しているユーザーとしてインストールするように促されます。httpd.confファイルのUserおよびGroupディレクティブを参照してください。

ベンダーがバンドルしたRed Hat Enterprise Linux 4上のApache v2用にAccess Manager Webgateをインストールする場合は、すべてのWebgateがWebサーバーのユーザーおよびグループ(デフォルト: apache)用にインストールされていることを確認してください。「Access Manager用のApache/IHS v2 Webgateのチューニング」も参照してください。

注意:

Linux上では、Oracle HTTP Server 11g用のWebgateではNPTLのみが使用され、LinuxThreadsライブラリは使用できません。この場合は、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。

23.6.3 LinuxおよびWindowsプラットフォームでのOracle HTTPサーバーWebサーバーの準備

WindowsおよびLinuxプラットフォーム上のOracle HTTP Server v2用にWebgateを使用する場合、PerlモジュールとPHPモジュールの両方を、httpd.conf内でコメント・アウトしておく必要があります。

注意:

Oracle HTTP Server 11gでは、どのプラットフォームでもWebgate用のモジュールをコメント・アウトする必要はありません。

23.6.4 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サーバーを再起動します。

23.6.5 UNIX上でのApache v2 Webサーバーの準備

ここでは、Solaris、UNIX、LinuxおよびAIXを含むUNIXプラットフォーム上ので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および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」を参照してください。

注意:

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のリバース・プロキシの起動に進んでください。

23.6.6 AIX上でのApache v2 SSL Webサーバーの準備

Apache v2 SSL Webサーバーの構築中に、OpenSSLライブラリlibssl.aからの記号がApacheのhttpd実行可能ファイルにエクスポートされます。Access ManagerがOpenSSLライブラリから必要な記号は次のとおりです。

- SSL_get_peer_certificate( )

- i2d_X509( )

AIXプラットフォーム上でのリンクとバインド中に、未使用または参照されていない記号は削除されます。したがって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プラットフォームが、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: 特定の記号のエクスポート。

23.6.7 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のリバース・プロキシの起動に進んでください。

23.7 Apache v2およびIHS v2のリバース・プロキシの起動

Apache v2およびIHS v2 powered by Apache用のWebgateは、リバース・プロキシ機能を起動している場合に、この機能をサポートします。リバース・プロキシ機能の実装手順は、ご使用の環境によって異なります。

- Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

- Apache v2 Webサーバーのリバース・プロキシ機能の起動手順

23.7.1 Apache v2 Webサーバーのリバース・プロキシの起動

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. 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」の手順を実行します(実行していない場合)。

23.7.2 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. 次の手順を実行します。

- 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」で説明するように、Access Manager 11gを使用して10g Webgateのインストールを完了します(完了していない場合)。

- 必要に応じて、この章に戻って、残りのタスクを実行します。

23.8 Webgate用のhttpd.conf更新の検証

次の手順を完了して、ApacheまたはIHS v2のhttpd.confファイルに、Access Manager用のWebサーバー構成の更新が含まれていることを確認するようお薦めします。詳細は次を参照してください。

- Webgateの詳細検証

- 言語エンコーディングの検証

IHS Webサーバー上のリバース・プロキシ用httpd.confを更新するには、「IHS v2 Webサーバーのリバース・プロキシの起動」を参照してください。Webサーバー用にhttpd.confをカスタマイズするには、ご使用のWebサーバーのドキュメントを参照してください。

23.8.1 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. 詳細は、「Access Manager用のApache/IHS v2 Webgateのチューニング」を参照して、Apache v2用のAccess Managerの実装を終了するために必要な手順を完了してください。

重要:

httpd.confファイルからWebgate関連の変更をクリアする必要がある場合にかぎり、次の手順を使用し、改めてWebgate用のApache v2 Webサーバー構成を完了する必要があります。

httpd.conf更新を新規に開始する手順

1. 元のhttpd.confファイルをリストアして、既存のAccess Managerエントリを削除します。

2. 次の方法を使用して、Access Manager用のhttpd.confファイルを更新します。

- 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」で説明するように、ファイルcomponent_install_dir/access/oblix/lang/LangTag/docs/config.htmを開いて、手動で構成を実行します。

- または、component_install_dir/access/oblix/tools/setup/InstallTools/ManageHttpConf内のManageHttpConfプログラムをオプションなしで実行して、使用方法に関する指示を出力します。

注意:

httpd.confファイル内にWebgateエントリがある状態でManageHttpConfプログラムを実行すると、エラー・メッセージが表示され、httpd.confファイルは更新されません。

3. 「Access Manager用のApache/IHS v2 Webgateのチューニング」の作業を完了してください。

23.8.2 言語エンコーディングの検証

前述のように、Access Manager HTMLページではUTF-8エンコーディングを使用します。ApacheベースのWebサーバーでは、管理者はHTMLページを生成しているアプリケーションが指定する文字を無効にするAddDefaultCharsetディレクティブを使用して、送信されるすべてのHTMLページにデフォルトの文字セットを指定できます。AddDefaultCharsetディレクティブがUTF-8以外の文字セットを有効にした場合、Access Manager HTMLページで文字化けが発生します。

正しい言語エンコーディングの確認手順

1. httpd.confファイルを開きます。

2. AddDefaultCharsetディレクティブを探します。

3. 次のいずれかの作業を完了し、Access Manager HTMLページのエンコーディングが正しいことを確認します。

- AddDefaultCharsetディレクティブをオフにします。

- または、AddDefaultCharsetディレクティブをコメント・アウトします。

4. httpd.confファイルを保存してWebサーバーを再起動します。

23.9 Access Manager用のOracle HTTP Server Webgateのチューニング

Oracle HTTP Server用のAccess Manager Webコンポーネントをインストールしたら、次の手順を実行する必要があります。

前述のように、Oracle HTTP Server用のWebgateをインストールする前に、コンポーネントのインストールを行うユーザーに合わせて、httpd.confファイル内のユーザーとグループを変更する必要があります。

注意:

Linux上では、Oracle HTTP Server 11g用のWebgateではNPTLのみが使用され、LinuxThreadsライブラリは使用できません。この場合は、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。

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を起動します。

23.10 OAM用のOHS/Apache PreforkおよびMPMモジュールのチューニング

これらのWebサーバー用に、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モジュールのチューニング

- カーネル・パラメータのチューニング

23.10.1 Oracle HTTP Server/Apache Preforkモジュールのチューニング

次の説明は、Oracle HTTP ServerまたはApache PreforkモジュールでAccess Managerを使用する場合の大まかなガイドラインとして使用することをお薦めします。

Timeout 300

KeepAlive On

MaxKeepAliveRequests 500

KeepAliveTimeout 10

StartServers: 5 (最初に起動するプロセスの数; 起動時のみ使用。)

MaxClients: 500 (ピーク時の負荷を処理するための合計プロセス数。ピーク時のリクエスト処理用に作成する子プロセス数を決定します。

ServerLimit: 500 (プロセス存続期間中のMaxClientsの最大構成値。MaxClientsがデフォルトよりも高い値に設定されている場合、ServerLimit値には残りのパラメータより高い値を設定する必要があります。

MinSpareServers、MaxSpareServers: デフォルト値で過度の負荷を処理するための要件を満足できるはずです。操作中は、これらの値によって、親プロセスはリクエスト処理用の子プロセス作成を規制します。

MaxRequestsPerChild: 0 - 各子プロセスに送信するリクエスト数。0はプロセスが失効しないことを示します。

23.10.2 Oracle HTTP Server/Apache MPMモジュールのチューニング

次の説明は、Oracle HTTP ServerまたはApache Preforkモジュールで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の値はプロセスが失効しないことを示します。)

23.10.3 カーネル・パラメータのチューニング

ファイル記述子のソフトおよびハード・リミットのカーネル・パラメータが、高い値に設定されていることを確認することをお薦めします。例:

ハード・リミット(rlim_fd_max): 65535

ソフト・リミット(rlim_fd_cur): 65535

リクエスト用にソケットの開閉を行うApacheサーバーでは、ファイル記述子の値を高く設定しておくことを強くお薦めします。

23.11 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

23.12 Access Manager用のApache/IHS v2 Webgateのチューニング

特に明記しないかぎり、ここに記載された情報はApacheおよびIHS v2 Webgate(プラグインとも呼ばれている)の両方に適用されます。Oracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド10gリリース2 (10.1.2)』を参照してください。

セキュリティ拡張LinuxにバンドルされたApache v2: SELinuxでは、Access Manager Webgateのインストール後に、より厳格なSELinuxポリシーが設定されたLinuxディストリビューションで、Webサーバーを起動する際に、WebServerログ/コンソールにエラーが報告されます。Webサーバーを再起動する前に、インストールされたWebコンポーネント用の適切なchconコマンドを実行することにより、これらのエラーを防止できます。

関連項目:

「SELinuxの問題」

Apache v2がバンドルされたSELinux対応のLinuxディストリビューション: セキュリティ強化されたLinux(SELinux)は、アクセス・コントロール・メカニズムの強制自動的に実装します。ご使用のLinuxのドキュメントにも記載されているように、SELinuxポリシーはシステム・デーモン用に、/etc/httpd/conf、/usr/sbin/apachect、および/var/log/(これはほんの一例)などの特定の事前定義済システム・ディレクトリへのアクセスを提供します。

バンドルされたApache Webサーバーを使用してWebgateをインストールした場合、Apacheのプロセスがインストール・ファイルにアクセスできるように、特定のポリシーを追加する必要があります。

バンドルされたApache Webサーバーは、context=user_u:system_r:unconfined_tとして定義されたセキュリティ・コンテキストで、ユーザー"apache"として実行されます。その結果、Webgateをいずれかのユーザー・フォルダにインストールすると、Apache Webサーバーは起動しません。

$SELINUX_SRC変数は、SELinuxポリシー・ソース・ディレクトリを示します。デフォルト値は/etc/selinux/targeted/src/policyです。ただし、お使いの環境とは異なることがあります。ご使用のシステムの実際の値については、必ずシステム管理者にご相談ください。

Access ManagerのポリシーをRed Hat Enterprise Linux 4にバンドルされたApacheに追加する手順

1. 各Access Manager Webgateのインストール後、「root」ユーザーとしてログインします。

2. Webサーバーのユーザーおよびグループ(デフォルト: apache)に対して、すべての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に作成し、Webgateのインストール・ディレクトリを登録します(アイデンティティやアクセスの接尾辞なしで)。例:

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だけで使用されます。Access Managerプラグインの初期化は初回リクエスト時まで延期されるので、このディレクティブを高い値で維持してもわずかな効果しか得られません。それでも、このパラメータをできるだけ高く維持しておくと便利です。

- MaxSpareThreads: この値はmpm_workerだけで使用されます。MaxSpareThreadsの値は、MinSpareThreadsとThreadsPerChildの合計と同じか、それより多い必要があり、そうなっていなければApache HTTP Serverが自動的に修正します。
推奨: 高い値を維持してください。専用サーバーの場合は、これは問題にはなりません。

- MaxSpareServers: Apache v2では、prefork MPMモデルだけで使用されます。サーバーにできるだけ多くの状態を保存するには、MaxSpareServersを高い値に設定してください。この値を最大の255に設定すると、使用可能なすべてのApacheワーカー・プロセスを維持しますが、負荷が低い期間にワーカー・プロセスのリサイクル機会が提供されません。

- MinSpareServers: Apache v2では、prefork MPMモデルのみで使用されます。Access Managerプラグインの初期化は初回リクエスト時まで延期されるので、MinSpareServersパラメータに高い値を使用してもわずかな効果しか得られません。それでも、このパラメータをできるだけ高く維持しておくと便利です。専用Webサーバー・システムの場合は、これによる負荷はそれほど多くないはずです。

- MaxClients: IHS v2とワーカー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のドキュメントを参照してください。

23.13 アンインストール後のWebサーバーの構成変更の削除

インストール中に生じたWebサーバーの構成変更は、Webgateのアンインストール後に手動で削除する必要があります。このタイプの情報は手動で削除する必要があります。

さらに、Webgate用にWebサーバー構成ファイルに対して手動で行った変更もすべて削除する必要があります。各コンポーネントに追加した内容の詳細は、この章の別な場所で調べてください。

23.14 役立つ情報

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

24 10g Webgate用のISAサーバーの構成

この章では、Access Manager ISAPI WebgateとMicrosoft Internet Security and Acceleration Server(ISAサーバー)が連動するように構成する方法を説明します。次の項目について説明します。

- 前提条件

- Access ManagerおよびISAサーバーについて

- 互換性とプラットフォームのサポート

- ISAサーバー用のWebgateのインストールおよび構成

- ISAPI Webgate用のISAサーバーの構成

- ISAサーバーの起動、停止および再起動

- ISAサーバーのWebgateをアンインストールする前のAccess Managerフィルタの削除

24.1 前提条件

Oracle Access Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシー施行エージェントについて」

- 「Access ManagerおよびISAサーバーについて」

24.2 Access ManagerおよびISAサーバーについて

ISAサーバーは、Microsoft社の統合エッジ・セキュリティ・ゲートウェイです。このサーバーは、インターネットベースの脅威からIT環境を保護し、アプリケーションおよびデータへの安全なリモート・アクセスをユーザーに提供するように設計されています。

Webgateは、Access ManagerのWebサーバー・プラグイン・アクセス・クライアントで、WebリソースへのHTTPリクエストを捕捉して、認証と認可を行うためにアクセス・サーバーに転送します。ISAPIは、ISAサーバー(およびIIS Webサーバー)と通信するWebgateを識別するためにAccess Managerで使用されるインターネットWebサーバー拡張機能です。

このWebgateは、Access Managerの基本およびフォーム(フォームベース)認証スキームの両方を使用するシナリオでISAサーバーと連動することがテストされています。通常どおり、Access Managerを使用して基本およびフォーム認証スキームとポリシー・ドメインを開発してください。

注意:

Access Managerのクライアント証明書認証は、ISAサーバーに対してはサポートされていません。

関連項目:

認証管理とポリシー・ドメインの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。

ISAサーバーをAccess Managerと連動させる方法は、IIS Webサーバーの場合とほぼ同じです。ただし、ISAサーバーでは、ファイアウォールと仮想プライベート・ネットワーク(VPN)の機能が提供されます。

ISAサーバーは、サード・パーティのセキュリティ・フィルタを使用するように構成できます。ISAサーバー使用時の認証および認可に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をアンインストールする前のAccess Managerフィルタの削除」

24.3 互換性とプラットフォームのサポート

次の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

24.4 ISAサーバー用のWebgateのインストールおよび構成

ISAサーバーのインストール後、ISAサーバーと連動させるためにWebgateをインストールするには、次のタスクを実行します。

関連項目:

「互換性とプラットフォームのサポート」

タスクの概要: ISAサーバー用のWebgate構成の実行

1. 「ISAサーバーでのWebgateのインストール」

2. 「/accessディレクトリの権限の変更」

3. 「Access ManagerプラグインのISAサーバーWebフィルタとしての登録」

24.4.1 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. 次の項目の詳細は第22章を参照してください。これらはご使用の環境に応じて適用されます。

- Access Manager 11gを使用した10g Webgateのリモート登録

- Access Manager 11g用の最新の10g Webgateの検索とインストール

- 11g OAMサーバー使用時の10g Webgateの集中ログアウト構成

2. /accessディレクトリの権限の変更

24.4.2 /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に対して、「フル コントロール」を選択します。

24.5 ISAPI Webgate用のISAサーバーの構成

次の項では、ISAサーバーをAccess Manager ISAPI Webgateと連動するように構成する方法について説明します。

タスクの概要: ISAサーバー用のWebgate構成の実行

1. 「Access ManagerプラグインのISAサーバーWebフィルタとしての登録」

2. 「ISA WebフィルタのISAファイアウォール・ポリシーの構成」

24.5.1 Access ManagerプラグインのISAサーバーWebフィルタとしての登録

ISAPI Webgate権限をリセットしたら、Access Managerのwebgate.dllおよびpostgate.dllプラグインをISAサーバー内にWebフィルタとして登録する必要があります。Webフィルタは、ISAサーバーのホストを通過するHTTPトラフィックをすべて検査します。条件に適合するリクエストのみが、通過を許可されます。

Access Manager認証スキームでは、ユーザーへの資格証明のチャレンジ方法、ユーザーが入力した情報のマッピングや検証方法などを定義します。ISAサーバーでは、チャレンジ方法としてフォーム認証または基本認証のどちらかを選択する必要があります。ユーザーが入力した資格証明を、ディレクトリ・サーバーに格納されている対応するユーザー・プロファイルにマッピングするためにチャレンジ・パラメータも指定する必要があります。

注意:

Access ManagerライブラリがISA Webフィルタとして登録されていないと、Access Manager認証が失敗する可能性があります。認証スキームのフォームベースのログイン用アクション・パスでwebgate.dllを指定しないでください。かわりに、/accessディレクトリ内のダミー・ファイルへのパスを次のように指定する必要があります。

action= "/access/dummy"

フォームベースの認証の場合、postgate.dllをインストールし、webgate.dllよりも上位に置く必要があります。

次の手順では、Access ManagerプラグインをISAサーバーに登録する方法を説明します。

注意:

フィルタ登録を元に戻す必要がある場合、次の手順を使用し、regsvr32コマンドに/uオプションを指定します。たとえば、regsvr32 /u ISA_install_dir\access\oblix\apps\webgate\bin\webgate.dllのようになります。

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ファイアウォール・ポリシーの構成」に進みます。

24.5.2 ISA WebフィルタのISAファイアウォール・ポリシーの構成

ユーザーを認証するには、ISAサーバーが認証サーバーと通信可能である必要があります。Access Managerのwebgate.dllとpostgate.dllをISA Webフィルタとして登録した後、これらのWebフィルタを使用してリソースを保護するようにISAファイアウォール・ポリシー・ルールを構成する必要があります。

Web公開ルールでは、基本的に受信リクエストが適切なWebサーバーにマッピングされます。アクセス・ルールでは、送信元ネットワーク上のクライアントが宛先ネットワーク上のリソースにアクセスする方法を決定します。ISAファイアウォール・ポリシー・ルールでは、ユーザー・セットのクライアント・メンバーシップ(ファイアウォール・クライアント、認証済Webクライアント、仮想プライベート・ネットワーク(VPN)クライアントのいずれか)が必要になります。ISAサーバーは、ISAファイアウォール・ポリシー・ルールに基づいて認証済ユーザーの照合を試みます。

関連項目:

ISAサーバーのドキュメントの、ISAファイアウォール・ポリシーおよびルールの詳細

次の手順では、Access Managerのwebgate.dllとpostgate.dllをISA Webフィルタとして使用するためにISAファイアウォール・ポリシー・ルールを構成する方法について説明します。

注意:

次の手順を実行した後、認証のリスナーを作成する場合は、「Advanced Properties」の「Allow client authentication over HTTP」を選択します。

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. 該当するポートのみが開き、通過させるトラフィックが許可されていることを確認します。

24.5.3 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より高い優先度でインストールされていることを確認します。

24.6 ISAサーバーの起動、停止および再起動

Access Manager Webコンポーネントのインストールまたは設定中にISAサーバーの再起動を求められた場合は、画面に表示されるすべての指示に従ってください。また、ISAサーバーの起動と停止に適している、net stop fwsrvおよびnet start fwsrvの使用を検討してください。netコマンドは、インストールに伴いメタベースが破損しないようにするために役立ちます。

詳細は、ISAサーバーのドキュメントを参照してください。

24.7 ISAサーバーのWebgateをアンインストールする前のAccess Managerフィルタの削除

ISAサーバーと連動するように構成されたWebgateのアンインストールを計画している場合、最初にAccess Managerフィルタの登録を手動で解除してから、Webgateをアンインストールする必要があります。

関連項目:

第22章: 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

25 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サーバー構成変更の削除

25.1 前提条件

Oracle Access Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。

- ポリシー施行エージェントについて

- Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて

25.2 IIS WebサーバーでのWebgateのガイドライン

ISAPIは、IIS Webサーバーと通信するWebgateのためのインターネットWebサーバーの拡張機能です。たとえば、IISに対応するWebgateをインストールするには、次のパッケージが必要です。

Oracle_Access_Manager10_1_4_3_0_Win32_ISAPI_Webgate

64ビットWebgate: Oracle_Access_Manager10_1_4_3_0_Win64_ISAPI_Webgate.exe

Webgateをインストールするときは、IIS Webサーバーの構成ファイルを更新する必要があります。IIS Webサーバー使用時の構成の更新には、ISAPIフィルタを追加してAccess Managerに必要な拡張機能を作成することにより、直接Webサーバーを更新することが含まれます。フィルタは、そのフィルタがインストールされたサイトへのリクエストをすべてリッスンします。フィルタは、IISの機能を強化するために、受信データ・ストリームと送信データ・ストリームの両方を調べて変更できます。ISAPI拡張機能は、IISにより制御されるプロセスへロードされるDLLとして実装されます。ASPやHTMLのページと同様に、IISでは、ファイル・システム内でDLLファイルの仮想的な場所が使用され、IIS提供のURLネームスペースにISAPI拡張機能がマップされます。

IIS Webサーバー構成ファイルは、Webgateのインストール中に自動的に更新することをお薦めします。自動更新には数分以上かかることがあります。一方、IIS Webサーバー構成ファイルの手動更新は自動更新より時間がかかり、意図しないエラーが発生する場合があります。

詳細なガイドラインは、次を参照してください。

- ISAPI Webgateのガイドライン

- IIS 7対応10g Webgateのインストールの前提条件

- IIS 7対応32ビットWebgateのインストールの前提条件

25.2.1 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にあります。複数のインストールを実行すると、このファイルのバージョンが複数作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。その場合は、webgate.dllとpostgate.dllが1つだけ存在するようにしてください。

注意:

postgate.dllは常にサイト・レベルでインストールされます。なんらかの理由でWebgateを再インストールすると、postgate.dllも再インストールされます。この場合、サイト・レベルにはpostgate.dllが1つだけ存在するようにしてください。

Webgate用のWebサーバー構成の更新: 他のWebgateの場合と同じく、WebサーバーがWebgateと連動するように構成する必要があります。インストール時に自動的にWebサーバー構成を更新することをお薦めします。ただし、自動更新を拒否し、そのかわりに「Access Manager 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固有のガイドラインはこの章を参照してください。一般的な準備とインストールの詳細は、第22章を参照してください。

Webgateインストールの完了と確認: ISAPI WebgateとIISのバージョンに対応するタスクを実行します。

関連項目:

- IISでのWebgateインストールの完了

- 64ビットWebgateインストールの終了

- IISへのWebgateのインストールの確認

25.2.1.1 IIS v7対応Webgate

通常、一般的なガイドラインとWebgateのインストール方法は、WebgateをインストールするIISのリリースに関係なく同じです。ただし、IIS v7に対して1つ以上のWebgateをインストールしているときは、次に示す特定のトピックを確認してください。

- IIS 7対応Webgateのインストールの前提条件

- Windows 2008でのIIS 7 Webサーバー構成の更新

- 1つのIIS 7インスタンスに対する複数の10g Webgateのインストールと構成

25.2.1.2 IIS v6対応Webgate

通常、一般的なガイドラインとWebgateのインストール方法は、WebgateをインストールするIISのリリースに関係なく同じです。ただし、いくつかの点に注意してください。

1つのIIS 6インスタンスに対する複数のWebgate: IIS v6.0では、複数のWebサイトを1つのWebサーバー・インスタンスでホストすることがサポートされており、ISAPI Webgateを使用すると、異なるWebgateを使用する各Webサイトを保護できます。

関連項目:

1つのIIS 6インスタンスに対する複数のWebgate

64ビットIIS v6 Webgate: 第22章の手順を使用して、他のすべての場合のようにインストールを実行します。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)をインストールします。

25.2.1.3 1つのIIS 6インスタンスに対する複数のWebgate

特に明記しないかぎり、この項の詳細は32ビットと64ビットのWebgateに同様に適用されます。

IIS v6.0では、複数のWebサイトを1つのWebサーバーでホストすることがサポートされており、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のインストールと構成」

25.3 IIS 7対応Webgateのインストールの前提条件

この項では、IIS v7 Webサーバーに対してWebgateをインストールするための前提条件を説明します。内容は次のとおりです。

- IIS 7対応10g Webgateのインストールの前提条件

- IIS 7対応32ビットWebgateのインストールの前提条件

25.3.1 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. ファイルを保存します。

25.3.2 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」をクリックします。

25.4 Windows 2008でのIIS 7 Webサーバー構成の更新

Webgateインストール時にWebサーバーの自動更新を選択しない場合は、次の手順を表示できます。

ISAPI WebgateのためにWindows 2008でのIIS 7 Webサーバーの構成手順を表示する手順

1. Webgateをインストールするとき、自動Webサーバー更新が必要かどうかを尋ねられたら「いいえ」をクリックします。

1. Webgate用にWebサーバーを手動で設定するのに役立つ情報を新しい画面で読みます。

2. 表示される表の次の項目をクリックして、表示される手順を実行します。

表25-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インストールの完了」に進みます。

25.5 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サイトの保護

25.5.1 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. フィルタが正しい順序で表示されていることを確認します。

25.5.2 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ファイルの複数のバージョンが作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。

25.5.3 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サーバーでのパススルーの実装

25.5.3.1 ISAPI Webgate 10.1.4.2.3について

ISAPI Webgateリリース10.1.4.2.3以上では、ワーカー・プロセス分離モードで実行するIIS 6.0に対する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のインストールに関する項)の情報よりも優先されます。

25.5.3.2 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フィルタとして構成する必要があります。

25.5.3.3 パススルーの実装: ワーカー・プロセス分離モードのIIS 6.0

このタスクは次の手順で説明します。

タスクの概要: ワーカー・プロセス分離モードのIIS 6.0 Webサーバーでのパススルー機能の実装

1. 「Access Manager 11g用の最新の10g Webgateの検索およびインストール」の説明に従ってWebgateをインストールします。

2. 「WebgateプロファイルでのUseWebGateExtForPassthroughパラメータの設定」の説明に従ってパススルーのパラメータを設定します。

3. 「ISAPI拡張機能としてのwebgate.dllの構成」の説明に従ってwebgate.dllを構成します。

25.5.3.3.1 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の構成」に進みます。

25.5.3.3.2 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サーバーを再起動します。

25.5.3.4 IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルーの実装

このタスクは次の手順で説明します。

注意:

ワーカー・プロセス分離モードのIIS 6.0 Webサーバーを使用している場合、このタスクは実行しません。

タスクの概要: IIS 5.0分離モードのIIS 6.0 Webサーバーでのパススルー機能の実装

1. 第22章「Access Manager 11gを使用する10g Webgateの登録および管理」の説明に従ってWebgateをインストールします。

2. 「IIS 5.0分離モードのIIS 6.0 Webサーバーの設定」の説明に従ってIIS 6.0を設定します。

3. 「ポストゲートISAPIフィルタのインストール」の説明に従ってpostgate.dllをインストールします。

25.5.3.4.1 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フィルタのインストール」に進みます。

25.5.3.4.2 ポストゲートISAPIフィルタのインストール

次の情報は10.1.4.2.3 Webgateに対応するように更新されています。

1つのWebgateインストールの場合、次の順序でフィルタをインストールする必要があります。

- ISAPI Webgateフィルタは、sspifiltフィルタの後で、他のフィルタの前にインストールする必要があります。

- postgateフィルタは、Webgateフィルタの前にインストールする必要があります(必要な場合のみ)。

- その他すべてのAccess Managerフィルタは最後にインストールできます。

注意:

インストールの前(またはインストールの後)には、フィルタを手動で削除する必要があります。1つのフィルタを複数インストールした場合、新しいフィルタをインストール前に手動で削除できません。

上位レベルのWebサイトとは別のレベルに複数のwebgate.dllを構成できます。ただし、それらは同じpostgate.dllを共有します。1つのコンピュータで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのために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の使用を検討します。

25.5.4 デフォルト・サイトが設定されていない場合の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」をクリックします。

25.6 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のインストールの確認」

25.6.1 複数のWebgateシナリオにおける各IIS 7 Webgateのインストール

ISAPI Webgateをインストールした後で、次に説明する手動の手順をいくつか実行します。

デフォルトでは、webgate.dllはホスト名(上位)レベルでISAPIフィルタとして構成されます。複数のWebgateを1つのIIS 7インスタンスに対してインストールしているときは、各Webgateインストールの後で、上位レベルからそれぞれのwebgate.dllを削除して、個々の適切なWebサイトで構成する必要があります。

1つのIIS 7インスタンスに対して複数のWebgateがある場合に各Webgateをインストールする手順

1. 第22章の説明に従って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をインストールするには、これらの手順を繰り返します。

25.6.2 複数のIIS 7 Webgateに対する偽装DLLの設定

クライアントのアクセス・トークンは偽装トークンとも呼ばれます。偽装トークンでは、クライアント、クライアントのグループおよびクライアントの権限が識別されます。トークン内の情報は、スレッドがクライアントのかわりにリソースへのアクセスをリクエストする際に、アクセス・チェックに使用されます。

Access Managerによってユーザーの認証および認可が行われます。ワイルドカード拡張機能のAccess ManagerのIISImpersonationExtension.dllは、Webサーバーへの各リクエストのフィルタのように機能します。Access Managerでは、「アクセス・ゲート構成」ページの偽装ユーザー名/パスワードを使用して、別のユーザーを偽装する権限を持つ特別なユーザーを構成することでユーザーを指定します。指定されたユーザーにはオペレーティング・システムとして機能する権限が必要です。DLLは、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のインストールの確認」

25.6.3 複数の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の構成」

25.6.4 パススルー機能のための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のインストールの確認」に進みます。

25.6.5 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をアンインストールしてから再インストールする必要があります。Access Managerの削除の詳細は、『Oracle Access Managerインストレーション・ガイド』の第22章を参照してから、Webgateのインストールに関する章に戻ってください。

25.7 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ファイルの複数のバージョンが作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。

タスクの概要: 1つのIISインスタンスに対する複数のWebgateのインストールと構成

1. 複数のWebgateシナリオにおける各Webgateのインストール

2. 複数のWebgateに対する偽装DLLの設定

3. 複数のWebgateに対するSSLとクライアント認証の有効化

4. 次のタスクを実行します。このタスクはIIS Webサーバー・インスタンスごとにインストールするWebgateの数に関係なく同じです。

- 「ISAPIフィルタの並替え」

- 「IISへのWebgateのインストールの確認」

関連項目:

「複数のWebgateのインストールの確認」

25.7.1 複数のWebgateシナリオにおける各Webgateのインストール

特に明記しないかぎり、この項は32ビットと64ビットのWebgateに同様に適用されます。

ISAPI Webgateをインストールした後で、次に説明する手動の手順をいくつか実行します。

デフォルトでは、webgate.dllはWebサイト(上位)レベルでISAPIフィルタとして構成されます。複数のWebgateを1つのIISインスタンスに対してインストールしているときは、各Webgateインストールの後で、上位レベルからそれぞれのwebgate.dllを削除して、個々の適切なWebサイトで構成する必要があります。

注意:

1台のマシンで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。1つのIIS v6 Webサーバー・インスタンスに対して複数のWebgateが構成されている環境では、postgate.dllはサポートされません。

1つのIISインスタンスに対して複数のWebgateがある場合に各Webgateをインストールする手順

1. 第22章の説明に従って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. 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. ファイル・システムで、次のように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をインストールするには、これらの手順を繰り返します。

25.7.2 複数のWebgateに対する偽装DLLの設定

特に明記しないかぎり、この項は32ビットと64ビットのWebgateおよびIIS v6に同様に適用されます。

クライアントのアクセス・トークンは偽装トークンとも呼ばれます。偽装トークンでは、クライアント、クライアントのグループおよびクライアントの権限が識別されます。トークン内の情報は、スレッドがクライアントのかわりにリソースへのアクセスをリクエストする際に、アクセス・チェックに使用されます。

アクセス・システムによってユーザーの認証および認可が行われます。ワイルドカード拡張機能のAccess ManagerのIISImpersonationExtension.dllは、Webサーバーへの各リクエストのフィルタのように機能します。アクセス・システムでは、「アクセス・ゲート構成」ページの偽装ユーザー名/パスワードを使用して、別のユーザーを偽装する権限を持つ特別なユーザーを構成することでユーザーを指定します。指定されたユーザーにはオペレーティング・システムとして機能する権限が必要です。DLLは、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のインストールの確認」

25.7.3 複数の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のインストールの確認」に進みます。

25.7.4 複数のWebgateのインストールの確認

このタスクは32ビットと64ビットのWebgateおよびIIS v6 Webサーバーに同様に適用されます。

1台のマシンで複数のWebgateインストールを実行すると、postgate.dllファイルの複数のバージョンが作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。1つのIIS v6 Webサーバー・インスタンスに対して複数のWebgateが構成されている環境では、postgate.dllはサポートされません。

関連項目:

- 「64ビットWebgateインストールの終了」

- 「IISへのWebgateのインストールの確認」

25.8 64ビットWebgateインストールの終了

この項では、64ビットWebgateのインストールを完了する方法について説明します。32ビットのWebgateをインストールする場合は、この項をスキップできます。その場合は、かわりに「IISでのWebgateインストールの完了」を参照してください。

このタスクを開始する前に、第22章の情報に従ってWebgateのインストールが完了していることを確認してください。また、該当のWebgateに対応するWebサーバー構成の更新は、Webgateのインストール時に自動で完了させておくか、「IIS v6対応Webgate」の説明に従って手動で完了させておく必要があります。

タスクの概要: 64ビットWebgateのインストールの終了

1. 「アクセス権限、ISAPIフィルタおよびディレクトリのセキュリティ認証の設定」の手順を実行します。

2. 必要に応じて、クライアント証明書を有効化します。「クライアント証明書認証の設定」を参照してください。

3. これらを完了したら、次を実行できます。

- 「IISへのWebgateのインストールの確認」の説明に従って操作を確認します。

- 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』の説明に従ってWindows偽装を実装します。

25.8.1 アクセス権限、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フィルタの並替え」の手順を実行し、すべてのフィルタが追加されていてその順序が正しいことを確認します。

25.8.2 クライアント証明書認証の設定

このタスクはオプションであり、クライアント証明書認証を使用する場合にのみ実行する必要があります。その場合は、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のインストールの確認」に進みます。

25.9 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をアンインストールしてから再インストールする必要があります。Access Managerの削除の詳細は、10g Webgateのインストールに関する章(第22章)の「Access Manager 11gデプロイメントからの10g Webgateの削除」を参照してください。

25.10 IIS Webサーバーの起動、停止および再起動

Webgateのインストールまたは設定中にIIS Webサーバーの再起動を求められた場合は、画面に表示されるすべての指示に従ってください。また、Webサーバーの起動と停止に適している、net stop iisadminおよびnet start w3svcの使用を検討してください。netコマンドは、インストールに伴いメタベースが破損しないようにするために役立ちます。

25.11 アンインストール前の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を使用してメタベースを編集します。

26 10g Webgate用のLotus Domino Webサーバーの構成

この章では、Webgateと連動させるためのLotus Dominoのインストールと構成に関するヒントを示します。次の項目について説明します。

- 前提条件

- Domino Webサーバーのインストール

- 最初のDomino Webサーバーの設定

- Domino Webサーバーの起動

- SSLの有効化(オプション)

- Dominoセキュリティ(DSAPI)フィルタのインストール

注意:

この章の情報は、オペレーティング・システム・コマンド、Lotus NotesおよびDomino Webサーバーの知識があることを前提としています。

26.1 前提条件

Oracle Access Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。

- 「ポリシー施行エージェントについて」

- 「Access Manager 11.1.2で使用する新しい10g Webgateのインストールについて」

26.2 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に含めてください。

26.3 最初の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として実行しないでください。

26.4 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を実行してサーバーを再起動します。

26.5 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

26.6 Dominoセキュリティ(DSAPI)フィルタのインストール

DominoセキュリティAPIフィルタ(DSAPI)は、DLLをDomino Webサーバーに登録するための認証方法です。この場合、認証のリクエストが発生すると、Webサーバーは、SSLまたは基本認証を使用するかわりにWebgate DLLをコールしてユーザーを認証します。

Access Manager DSAPIフィルタを使用する場合、Domino内の認証はオプションです。認証においてデフォルトのWebサーバーではサポートされていない特定の側面を実装できます。

タスクの概要: Webgateとフィルタのインストールの完了

1. WebgateをDomino Webサーバーにインストールする前に、これまで説明したすべての手順を完了してください。

2. 「Access Manager 11g用の最新の10g Webgateの検索およびインストール」の説明に従って、WebgateのインストールとWebサーバーの更新を実行します。

3. 「Webgateインストールの完了」を参照して、説明されている2つのオプションから1つを選択します。

26.6.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サーバー・タスクを再起動します。

第VII部

Oracle Access Management Identity Federationの管理

第VII部の内容は次のとおりです。

- 第27章「Oracle Access ManagementでのIdentity Federationの概要」

- 第28章「Oracle Access Managementコンソールを使用したIdentity Federationのパートナの管理」

- 第29章「Oracle Access Managementコンソールを使用したIdentity Federationの設定の管理」

- 第30章「Oracle Access Managementコンソールを使用したフェデレーション関連のスキームおよびポリシーの管理」

27 Oracle Access ManagementでのIdentity Federationの概要

この章では、Oracle Access Managementコンソールから使用可能なアイデンティティ・フェデレーション機能について説明します。この章の内容は次のとおりです。

- Identity FederationとOracle Access Managementの統合

- Oracle Access ManagementコンソールでのIdentity Federationの概要

- フェデレーション・サービスの管理

27.1 Identity FederationとOracle Access Managementの統合

この章では、11gリリース2(11.1.2)のOracle Access Managementで使用可能なIdentity Federationの機能について説明します。

この章の内容は、Identity Federationについて、ある程度の知識が前提になります。バックグラウンドおよび概念の情報は、「フェデレーテッド・アイデンティティの管理」を参照してください。

27.1.1 Oracle Access ManagementでのフェデレーテッドSSO

Oracle Identity Managementフレームワークは、クロスドメインのシングル・サインオンで次の2つの方法をサポートしています。

- Oracle Access Management Access Managerサーバー(OAMサーバー)に組み込まれているOracle Access Management Identity Federationサーバー。Identity Federationサーバーの構成はすべてOracle Access Managementコンソールで実行します。
この新しい方法は、11gリリース2(11.1.2)で導入されました。このドキュメントではこの方法について説明します。

注意:

このリリースではサービス・プロバイダ機能のみが提供されます。

- フェデレーション機能を使用するために統合可能なOracle Identity Federationリリース1(11.1.1)とOracle Access Managerの個別のサーバー。この統合用に両方のサーバーを構成し、管理する必要があります。
この方法は11gリリース1(11.1.1)の時点ですでに存在しており、引き続き使用できます。このアプローチの詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』を参照してください。

注意:

それぞれの統合は独立しているため、前述の方法を組み合せることはできません。ご使用のインストールに最適な方法を選択してください。

最新のドキュメントでは、11gリリース2(11.1.2)の機能に限定して説明します。

27.1.2 Access ManagerとIdentity Federation 11.1.2の併用による利点

11gリリース2(11.1.2)のAccess ManagerとIdentity Federationサーバーを併用すると、次のような利点があります。

- これにより、各サーバーへの個別のインストールや管理は不要になります。

- インストール後のフェデレーション機能の構成が簡略化されます。具体的には、Oracle Access Managementコンソールからこれらのフェデレーション機能にアクセスできるようになります。

- 連携する2つのサーバーのスケーラビリティが向上します。

- 診断およびトラブルシューティングの機能が強化されます。

27.1.3 Access ManagerとIdentity Federation統合の主要な要素

機能的観点から、このシナリオにおけるフェデレーテッド・アクセスの主要な構成要素は次のようになります。

1. ユーザーがブラウザでログインを試みます。コールは通常のHTTPコールです。

2. Access Managerサーバーには、フェデレーテッド・コンテキストで管理サービスにアクセスする際に必要なコンポーネントがすべて含まれています。コンポーネントは次のとおりです。

- 資格証明コレクタ

- フェデレーション認証プラグイン

- アサーションを処理するフェデレーション・エンジン

- フェデレーション・データ・キャッシュ

3. Oracle WebLogic Serverは、次のような主要なインフラストラクチャ・サービスをホストし、提供します。

- Oracle Entitlement Serverと相互作用する認可エンジン

- トラスト・サークルの詳細や他の構成を含むフェデレーション・データ

- Coherenceマップ・ストア

4. 認証タスクに必要なアイデンティティ・データは、アイデンティティ・ストアやCoherenceデータベースなどのデータ・ストアで保持されます。

27.1.4 主な機能

この項では、Identity FederationとAccess Managerの統合で使用できる主な機能について説明します。

27.1.4.1 動作モード

Identity Federationは次のモードで動作します。

- シングル・サインオン(SSO)モード
サーバーは、サービス・プロバイダ(SP)として機能するフェデレーテッドSSOをサポートします。このモードには次の2つのバリエーションがあります。

- SPが開始するSSO。SPがIdPに認証リクエストを送信すると、フェデレーテッドSSOフローが開始されます。

- IdPが開始するSSO。IdPがSPに非送信請求アサーション・レスポンスを送信します(SPからの認証リクエストがない場合)。

- ログアウト・モード
ログアウトは次の場所から開始できます。

- リモート・フェデレーション・パートナ

- Access Managerで保護されたアプリケーション

注意:

管理者がOracle Access Managementコンソールからユーザー・セッションを終了すると、そのセッションに関与するリモート・アイデンティティ・プロバイダにはログアウトが伝播されません。そのため、ログアウト済のユーザーは、Identity Federationを通じて自動的にAccess Managerに再認証されるようになります。

27.1.4.2 サポートされているプロトコル

Identity Federationは、11gリリース2(11.1.2)のAccess Managerで次のフェデレーション・プロトコルをサポートしています。

表27-1 サポートされているプロトコル

プロトコル

モード/拡張

バインディング

名前IDフォーマット

SAML 1.1

シングル・サインオン(SSO)

POST、アーティファクト

電子メール、サブジェクトDN、Kerberos、Windows、未指定、カスタム

SAML 2.0

SSO、シングル・ログアウト(SLO)

リダイレクト、POST、アーティファクト

電子メール、サブジェクトDN、Kerberos、Windows、一時、未指定、カスタム

OpenID 2.0

認証/SSO、Attribute Exchange (AX)、PAPE、UI拡張、検出/XRDS

リダイレクト、POST

主張識別子

27.1.4.3 サポートされているデータ・ストア

Identity Federationは、Access Manager共通ユーザー・ストアをサポートしており、マルチIDストアのサポートも提供します。

データをリンクする永続的なアカウントのフェデレーション・データ・ストアはサポートされていません。

27.1.4.4 ユーザー・マッピング

SPとして動作するIdentity Federationは、IdPパートナが作成したSAMLアサーションの検証を終えると、次の3つの方法のいずれかを使用して、ローカル・ユーザーにアサーションをマップできます。

- UserID属性(uid)にSAMLサブジェクトをマップする方法。

- 指定された別のユーザー・レコード属性にSAMLサブジェクトをマップする方法。

- LDAP問合せを使用して、SAMLアサーションのAttributeStatement要素に含まれる1つ以上の属性またはSAMLサブジェクトをマップする方法。SAML属性名およびこのマップ先となるユーザー・レコード属性の両方を構成する必要があります。

27.1.4.5 マルチテナントのサポート

マルチテナントは、SPフローでサポートされます。

27.1.4.6 プラットフォームとの依存関係

このアーキテクチャでは、資格証明ストア・フレームワーク(CSF)を使用する際にOracle Fusion Middlewareプラットフォームを利用します。

資格証明ストア・フレームワーク(CSF)の使用について

Identity Federationは、CSFを使用してキーストア・パスワードと、サーバーの資格証明(HTTP Basic認証のユーザー名とパスワードなど)を安全に格納します。

27.1.5 管理

Access ManagerとIdentity Federationの統合は、次の組合せで管理されます。

- Oracle Access Managementコンソール
このコンソールを使用すると、Identity Federationサービスを有効にしたり、アイデンティティ・プロバイダ(IdP)パートナーを管理したりできます。また、フェデレーテッド認証スキームおよびポリシーに対する作業を実行できます。

- Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツール
WLSTユーティリティを使用すると、追加のサーバーおよびパートナの構成プロパティを管理できます。

詳細は、この章の残りの各項および本ドキュメントのこの部の以降の章を参照してください。

27.2 Oracle Access ManagementコンソールでのIdentity Federationの概要

管理者はOracle Access Managementコンソールを使用して、サーバーのフェデレーション・サービスとパートナに関連する構成を管理できます。表27-2に、Oracle Access ManagementコンソールでIdentity Federation用に構成できる情報の種類を要約します。

表27-2 Oracle Access ManagementコンソールのIdentity Federation構成

要素

説明およびこのドキュメント内での場所

フェデレーション管理者

フェデレーテッド・パートナおよび関連する構成を管理できる管理者。「Oracle Access Managementコンソールおよびコントロールの概要」を参照してください。

フェデレーション・サービス

Access ManagerのIdentity Federationサービスを有効または無効にします。「フェデレーション・サービスの管理」を参照してください。

フェデレーション設定

基本的なIdentity Federationサービス構成プロパティの管理。第29章「Oracle Access Managementコンソールを使用したIdentity Federationの設定の管理」を参照してください。

フェデレーションのアイデンティティ・プロバイダ

フェデレーションIdPパートナの管理。「フェデレーション用のアイデンティティ・プロバイダ・パートナの管理」を参照してください。

フェデレーションの認証スキームおよび認証モジュール

フェデレーションの認証スキームの管理。「Identity Federation 11gリリース2(11.1.2)の認証スキームおよび認証モジュールの使用」を参照してください。

フェデレーションで使用するポリシー

フェデレーション・パートナに使用するポリシーの管理。「Identity Federationで使用するAccess Managerのポリシーの管理」を参照してください。

表27-3に、Oracle Access Managementコンソールを使用してIdentity Federationを実装する際に必要なタスクの概要を示します。

表27-3 Identity FederationとAccess Manager 11gリリース2 (11.1.2)の統合

タスク

参照先

Identity Federationサービスを有効にします。

第27.3項

フェデレーション設定を構成します。

第29.3項

IdPパートナを指定し、そのパートナの属性を構成します。

第28.3項

認証または認可ポリシーを構成します。

第30章

このポリシーでリソースを保護します。

第17章

27.3 フェデレーション・サービスの管理

Identity Federationは、Oracle Access Managementに含まれる認証モジュールです。Identity Federationを使用するには、Access ManagerサービスとIdentity Federationサービスの両方を有効にする必要があります。

図27-1に、Oracle Access Managementコンソールの「使用可能なサービス」ページを示します。このページを使用して、Identity FederationサービスとAccess Managerサービスを有効にします。

図27-1 「使用可能なサービス」ページ

Access ManagerでIdentity Federationサービスを管理する手順

1. 通常どおり、Oracle Access Managementコンソールにログインします。

https://hostname:port/oamconsole/

2. 「ようこそ」ページの「構成」で、「使用可能なサービス」をクリックします。

3. Identity Federationの有効化: 「Identity Federation」の横にある「有効化」をクリックします(または、「ステータス」に緑のチェック・マークが表示されていることを確認します)。

4. Access Managerの有効化: 「Access Manager」の横にある「有効化」をクリックします(または、「ステータス」に緑のチェック・マークが表示されていることを確認します)。

28 Oracle Access Managementコンソールを使用したIdentity Federation用パートナの管理

この章では、Oracle Access ManagementのIdentity Federationで使用するフェデレーション・パートナについて説明します。この章の内容は次のとおりです。

- 前提条件

- フェデレーション・パートナの管理の概要

- フェデレーション用のアイデンティティ・プロバイダ・パートナの管理

28.1 前提条件

この章に記載されている内容は、前の章の「フェデレーション・サービスの管理」を実行していることを前提としています。また、この章は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』に記載されているOracle Identity Federation 11.1.1についてある程度理解していることを前提としています。

28.2 フェデレーション・パートナの管理の概要

Oracle Access Management Access Managerに含まれるIdentity Federationの機能を使用すると、フェデレーテッド・シングル・サインオン操作に必要なトラステッド・パートナを追加できます。

フェデレーション・パートナの作成には、Oracle Access ManagementコンソールまたはWLSTコマンドライン・ユーティリティを使用できます。

SPモード機能およびIdPモード機能

11gリリース2(11.1.2)には、Access Managerに統合されたフェデレーション・サービス・プロバイダ(SPモード)機能が用意されています。ただし、アイデンティティ・プロバイダ(IdP-mode)の機能が必要な場合は、Oracle Identity Federation 11.1.1を使用する必要があります。

28.3 フェデレーション用のアイデンティティ・プロバイダ・パートナの管理

アイデンティティ・プロバイダ(IdP)は、そのサービス・プロバイダ(SP)パートナのユーザーIDのセットを管理、認証およびアサートします。Identity Federationサービスが外部アイデンティティ・プロバイダを使用してSSOを実行するには、そのプロバイダがトラステッド・パートナとして定義されている必要があります。

この項の内容は次のとおりです。

- フェデレーション・アイデンティティ・プロバイダの作成

- フェデレーションのアイデンティティ・プロバイダの管理

28.3.1 フェデレーション・アイデンティティ・プロバイダの作成

「新規アイデンティティ・プロバイダ」ページを使用して、Access Managerのアイデンティティ・プロバイダ(IdP)パートナのレコードを定義します。サービスの詳細は、手動で指定することもメタデータ・ファイルからロードすることも可能です。

図28-1に、サービスの詳細をメタデータからロードした場合のフェデレーテッドIdPパートナの「新規アイデンティティ・プロバイダ」ページを示します。

図28-1 サービスの詳細をメタデータからロードした場合の「新規アイデンティティ・プロバイダ」ページ

図28-2に、サービスの詳細を手動で入力した場合のフェデレーテッドIdPパートナの「新規アイデンティティ・プロバイダ」ページを示します。

図28-2 サービスの詳細を手動で入力した場合の「新規アイデンティティ・プロバイダ」ページ

表28-1では、「新規アイデンティティ・プロバイダ」の各要素について説明します。

表28-1 アイデンティティ・プロバイダ・パートナの設定

要素

説明

名前

プロバイダ名です。

説明

プロバイダの簡単な説明です。(オプション)。

プロトコル

プロバイダ・プロトコルです(SAML 1.1、SAML 2.0など)。

サービスの詳細

このドロップダウンを使用して、サービスの詳細を手動で入力するか、メタデータからロードするかを選択します。

メタデータ・ファイル

このフィールドは、ファイルからメタデータをロードする場合に表示されます。「参照」をクリックして、使用するファイルを選択します。

発行者ID

プロバイダの発行者IDです。

簡潔ID

プロバイダの簡潔IDです。この要素は、アーティファクト・プロファイルを使用する場合は必須です。

SSOサービスURL

SSOリクエストが送信されるURLアドレスです。

SOAPサービスURL

SOAPサービス・リクエストが送信されるURLアドレスです。この要素は、アーティファクト・プロファイルを使用する場合は必須です。

ログアウト・リクエスト・サービスURL

プロバイダからログアウト・リクエストが送信されるURLアドレスです。この要素はログアウト機能を使用する場合は必須です。

ログアウト・レスポンス・サービスURL

ログアウト・レスポンスが送信されるURLアドレスです。この要素はログアウト機能を使用する場合は必須です。

署名証明書

プロバイダが使用する署名証明書です。pemおよびderフォーマットで指定できます。

ユーザー・アイデンティティ・ストア

IdPのユーザーが配置およびマップされるアイデンティティ・ストアです。Identity Federationは、パートナ単位で定義された複数のアイデンティティ・ストアをサポートします。ユーザー・アイデンティティ・ストアが選択されていない場合は、Access Managerに定義されたデフォルト・ストアが使用されます。

ユーザー検索ベースDN

ユーザー・レコードの参照時に使用される基本検索DNです。(オプション。省略した場合は、選択したユーザー・アイデンティティ・ストア用に構成されているデフォルトのユーザー検索ベースDNが使用されます。)

マッピング・オプション

この設定では、アイデンティティ・ストア内のユーザーに着信アサーションをマップする方法を指定します。次のいずれかのオプションを選択します。

- ユーザーIDストア属性にアサーション名IDをマップ
アサーションのNameIDのマップ先となるアイデンティティ・ストア属性を入力します。

- ユーザーIDストア属性にアサーション属性をマップ
アサーション属性とそのマップ先となるアイデンティティ・ストア属性を入力します。

- LDAP問合せを使用してユーザー・レコードにアサーションをマップ
着信データのプレースホルダを含むLDAP問合せを入力します。次を使用できます。

- SAMLアサーションのAttributeStatement要素の属性。属性名の先頭と末尾に%文字を付けて参照します。

- SAMLアサーションのサブジェクトのNameID。%fed.nameidvalue%で参照します。

- アイデンティティ・プロバイダのパートナ名。%fed.partner%で参照します。

たとえば、2つのアサーション属性(lastnameとemail)に基づいて着信アサーションをマップするLDAP問合せは、(&(sn=%lastname%)(mail=%email%))のようになります。

HTTP Basic認証の有効化

HTTP基本資格証明を受け入れる場合はこのボックスを選択します。(拡張要素。プロバイダの「Edit」モードのみで使用できます。)

注意:

アイデンティティ・プロバイダ(IdP)機能には、11gリリース1(11.1.1)のOracle Identity Federationサーバーを使用してください。詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』を参照してください。

フェデレーションで使用するSAML 2.0アイデンティティ・プロバイダを定義する手順

次の手順に従って、新しいSAML 2.0アイデンティティ・プロバイダ(IdP)を定義します。

1. Oracle Access Managementコンソールで、次のようにフェデレーション・アイデンティティ・プロバイダに移動します。

System Configuration tab
Federation section
Identity Providers node

2. 「IDプロバイダの作成」ボタンをクリックして、「新規アイデンティティ・プロバイダ」ページを表示します。

3. 通常、SAML 2.0はメタデータで構成します。「サービスの詳細」ドロップダウンで、「プロバイダ・メタデータからロード」を選択します。

4. 「メタデータ・ファイル」という新しいフィールドが表示されます。「参照」をクリックします。

5. 対象のメタデータ・ファイルを選択します。

6. ファイルからメタデータがロードされます。

7. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。

フェデレーションで使用するSAML 1.1アイデンティティ・プロバイダを定義する手順

次の手順を実行して、新しいSAML 1.1アイデンティティ・プロバイダ(IdP)を作成します。

1. Oracle Access Managementコンソールで、次のようにフェデレーション・アイデンティティ・プロバイダに移動します。

System Configuration tab
Federation section
Identity Providers node

2. 「IDプロバイダの作成」ボタンをクリックして、「新規アイデンティティ・プロバイダ」ページを表示します。

3. 使用環境に適した値(表28-1)を、「新規アイデンティティ・プロバイダ」ページに入力します。指定する情報は、プロバイダなどの要素で選択したプロトコルに応じて異なります。

4. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。

フェデレーションで使用するOpenID 2.0アイデンティティ・プロバイダを定義するには:

11gリリース2 (11.1.2)では、フェデレーション・サービスは、OpenIDをサポートし、OpenID RP/SPの役割を果たします。OpenIDプロバイダ(OP)は、IdPパートナとして登録できます。これらのOpenIDパートナを使用して作成された認証スキームは、OpenIDアイデンティティ・プロバイダが提供する認証サービスを使用してOAMリソースを保護します。

フェデレーションWLSTコマンドを使用すると、OpenID IdPパートナを登録および管理できます。

関連項目:

『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』。

Google IdPパートナ

次のWLSTコマンドを実行して、Google IdPパートナを追加します。

addOpenID20GoogleIdPFederationPartner()

これにより、次の検出URLを使用するGoogleという名前のIdPパートナを作成します。

https://www.google.com/accounts/o8/id

このパートナは、SPがGoogle IdPから表28-2に一覧されたアサーション属性を要求できるように構成され、それらの属性を対応するセッション属性名にマップします。

表28-2 Google OpenIDパートナの属性

アサーション属性名

セッション属性名

http://axschema.org/contact/country/home

country

http://axschema.org/contact/email

email

http://axschema.org/namePerson/first

firstname

http://axschema.org/pref/language

language

http://axschema.org/namePerson/last

lastname

Googleパートナはユーザー・マッピング属性としてmailを使用するため、着信のhttp://axschema.org/contact/email属性は、ユーザー・アイデンティティ・ストアに含まれるユーザーのmail属性と一致するようになります。

次のWLSTコマンドを使用すると、GoogleがデフォルトIdPになります。

putStringProperty("/spglobal/defaultssoidp","google")

Yahoo IdPパートナ

次のWLSTコマンドを実行して、Yahoo IdPパートナを追加します。

addOpenID20YahooIdPFederationPartner()

これにより、次の検出URLを使用するyahooという名前のIdPパートナを作成します。

https://open.login.yahooapis.com/openid20/user_profile/xrds

このパートナは、SPがYahoo IdPから表28-3に一覧されたアサーション属性を要求できるように構成され、それらの属性を対応するセッション属性名にマップします。

表28-3 Yahoo OpenIDパートナの属性

アサーション属性名

セッション属性名

http://axschema.org/contact/country/home

country

http://axschema.org/contact/email

email

http://axschema.org/namePerson/first

firstname

http://axschema.org/pref/language

language

http://axschema.org/namePerson/last

lastname

Yahooパートナはユーザー・マッピング属性としてmailを使用するため、着信のhttp://axschema.org/contact/email属性は、ユーザー・アイデンティティ・ストアに含まれるユーザーのmail属性と一致するようになります。

次のWLSTコマンドを使用すると、YahooがデフォルトIdPになります。

putStringProperty("/spglobal/defaultssoidp", "yahoo")

その他のOpenID 2.0 IdPパートナ

次のWLSTコマンドを実行して、GoogleまたはYahoo以外のOpenID 2.0 IdPパートナを追加します。

addOpenID20IdPFederationPartner(partnerName, idpSSOURL, discoveryURL, description)

説明:

- partnerNameは、作成するパートナの名前です。

- idpSSOURLは、IdPの初期SSO URLです。検出URLが指定されていて、そのURLを使用する場合は、""を設定します。

- discoveryURLは、IdPのOpenID検出URLです。IdP SSO URLが指定されていて、そのURLを使用する場合は、""を設定します。

- descriptionは、パートナの説明です。このパラメータはオプションです。

例1:

addOpenID20IdPFederationPartner(“testpartner1”, “”, “http://host:port/discoveryurl”, description="Test IdP1")

例2:

addOpenID20IdPFederationPartner(“testpartner2”,
“http://host:port /openidv20/sso”, “”, description="Test IdP2")

パートナIdPにアイデンティティ・ストアを設定するには

次のWLSTコマンドを使用すると、IdPのユーザーをマップするために使用するアイデンティティ・ストアを指定できます。このアイデンティティ・ストアは、OAMに登録されている必要があります。管理コンソールで登録済のストアを確認するには、「システム構成」、「共通構成」、「データソース」、「ユーザー・アイデンティティ・ストア」の順に移動します。

setPartnerIDStoreAndBaseDN(partnerName, ”idp”, storeName, searchBaseDN)

説明:

- partnerNameは、更新するパートナの名前です。

- storeNameは、アイデンティティ・ストアの名前です。

- searchBaseDNは、LDAPの検索ベースDNです(オプション)。

例:

setPartnerIDStoreAndBaseDN(partnerName="testpartner", partnerType="idp", storeName="testldap", searchBaseDN="dc=company,dc=com")

アサーション属性をユーザー属性にマップするには

ユーザーを特定するには、IdPから受信したOpenIDアサーションの属性を、特定のデータ・ストアにマップするように指定します。次のWLSTコマンドを使用すると、属性でユーザーのアサーションをマッピングするパートナを構成できます。

setIdPPartnerMappingAttribute(partnerName, assertionAttr,userstoreAttr)

説明:

- partnerNameは、更新するパートナのIDです。

- assertionAttrは、マッピングに使用するアサーションの属性です。

- userstoreAttrは、アサーション属性値のマップ先になるユーザー・ストア内の属性名です。

例:

setIdPPartnerMappingAttribute(partnerName="testpartner", assertionAttr="email", userstoreAttr="mail")

注意:

assertionAttrを含むIdPから受信したアサーションが、確実にユーザー・マッピングに使用されるようにするために、IdPが送信する属性を指定できます。

詳細は、後述の項「属性をマップするには」を参照してください。

IdPパートナの属性プロファイルを構成するには

属性プロファイルを作成すると、OpenID IdPから要求する属性を指定できます。

次のWLSTコマンドを使用すると、このプロファイルを作成できます。

createIdPPartnerAttributeProfile(attrProfileID)

このattrProfileIDは、作成するIdPパートナ属性プロファイルを参照する識別子です。例:

createIdPPartnerAttributeProfile(attrProfileID="openid-idp-attribute-profile")

その次に、IdPから要求される属性ごとに、属性プロファイルのエントリを作成します。

setIdPPartnerAttributeProfileEntry(attrProfileID, messageAttributeName, oamSessionAttributeName, "true")

説明:

- attrProfileIDでは、エントリが含まれるIdPパートナ属性プロファイルを特定します。

- messageAttributeNameは、要求される属性の名前です。

- oamSessionAttributeNameは、OAMセッションに示される属性の名前です($session.attr.fed.attr.%oamSessionAttributeName%、%oamSessionAttributeName%の部分が、この属性の名前に置き換わります)。

例:

setIdPPartnerAttributeProfileEntry("openid-idp-attribute-profile", "http://axschema.org/namePerson", "name", "true")

注意:

このコマンドの最後のパラメータは、この属性がIdPから要求されることを示すために"true"のままにします。

最後に、OpenID IdPパートナに使用する属性プロファイルとして、作成した属性プロファイルを指定します。

setIdPPartnerAttributeProfile(partnerName, attrProfileID)

説明:

- partnerNameは、IdPパートナのIDです。

- attrProfileIDは、IdPパートナに使用する属性プロファイルです。

例:

setIdPPartnerAttributeProfile("testpartner, "openid-idp-attribute-profile")

属性プロファイルを削除するには

次のWLSTコマンドを使用すると、属性プロファイルを削除できます。

deleteIdPPartnerAttributeProfile(<attrProfileID>)

このattrProfileIDは、削除するIdPパートナ属性プロファイルの識別子です。例:

deleteIdPPartnerAttributeProfile("openid-idp-attribute-profile")

注意:

属性プロファイルを削除する前に、属性プロファイルを参照するパートナが存在しないことを確認してください。

OpenId IdPパートナをデフォルトのフェデレーションIdPとして指定するには

次のWLSTコマンドを使用すると、OpenId IdPパートナをデフォルトのフェデレーションIdPとして指定できます。

putStringProperty("/spglobal/defaultssoidp", partnerName)

このpartnerNameは、デフォルトのフェデレーションIdPとして指定するIdPパートナのIDです。例:

putStringProperty("/spglobal/defaultssoidp", "testpartner")

OpenID IdPパートナを削除するには

次のWLSTコマンドを使用すると、OpenID IdPパートナを削除できます。

deleteFederationPartner(partnerName, "idp")

このpartnerNameは、IdPパートナのIDです。例:

deleteFederationPartner("testpartner", "idp")

OAMのリソースを保護する認証スキームを作成するには

OAMのリソースは、OpenD IdPを使用する認証スキームで保護できます。次のWLSTコマンドを使用すると、認証スキームおよびモジュールを作成できます。

createAuthnSchemeAndModule(partnerName)

このpartnerNameは、認証スキームおよびモジュールを作成する対象のIdPパートナのIDです。例:

createAuthnSchemeAndModule("testpartner")

OpenID簡易登録を有効化するには

デフォルトでは、Identity FederationはAttribute Exchange Extensionを使用して、OpenID IdPからユーザー・アイデンティティ属性を取得します。ただし、古いSimple Registration(SREG)拡張機能を使用する必要がある場合は、次のWLSTコマンドを実行することで、有効化できます。

putBooleanProperty("/spglobal/openid20axenabled", "false")
putBooleanProperty("/spglobal/openid20sregenabled", "true")

OpenID Simple Registrationを無効化するには

Simple Registration(SREG)拡張機能からAttribute Exchange Extensionに切り替えてOpenID IdPからユーザー・アイデンティティ属性を取得するには:

putBooleanProperty("/spglobal/openid20axenabled", "true")
putBooleanProperty("/spglobal/openid20sregenabled", "false")

28.3.2 フェデレーションのアイデンティティ・プロバイダの管理

Identity Federation用の既存のIdPを管理するには、次の手順を使用します。

前提条件

フェデレーション・サービスの有効化

既存のアイデンティティ・プロバイダを検索する手順

次の手順に従います。

1. Oracle Access Managementコンソールで、次のようにフェデレーション・アイデンティティ・プロバイダに移動します。

System Configuration tab
Federation section
Identity Providers node

2. ページの「検索」に、アイデンティティ・プロバイダの検索基準を入力します。"*"(アスタリスク)文字と"."(ピリオド)文字は、検索のワイルドカードとしてサポートされています。検索パラメータの詳細は、表28-4を参照してください。

3. 「検索」をクリックします。

4. 検索結果は、表に表示されます。

表28-4 IdPのプロバイダ検索で使用される要素

要素

説明

パートナ名

特定のパートナ名を検索します。

プロバイダID

プロバイダIDで検索します。

ステータス

ステータスに一致するプロバイダを検索します。

説明

プロバイダの説明で検索します。

プロトコル

指定したプロバイダを使用するプロバイダを検索します。

注意:

WLSTコマンドを使用して作成されたOpenID 2.0 IdPパートナは、IdPの検索結果に表示されます。ただし、管理コンソールから編集や更新を実行できません。そのかわりに、次の関連WLSTコマンドを使用します。

表28-4に、IdP検索の検索結果の例を示します。

図28-3 アイデンティティ・プロバイダの検索

フェデレーションで使用するアイデンティティ・プロバイダを更新する手順

1. Oracle Access Managementコンソールで、次のようにフェデレーション・アイデンティティ・プロバイダに移動します。

System Configuration tab
Federation section
Identity Providers node

2. 更新対象のプロバイダを検索します。詳細は、「既存のアイデンティティ・プロバイダを検索する手順」を参照してください。

3. 検索結果の表から対象のプロバイダを選択します。

4. 鉛筆アイコンをクリックして、プロバイダの更新ページを表示します。このページは、「サービス情報」、「署名証明書」、「ユーザー・マッピング」および「詳細設定」のセクションに分かれています。

5. プロバイダの情報を更新します。詳細は、表28-1を参照。

6. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が更新されます。

図28-4に、IdP定義の更新の例を示します。

図28-4 アイデンティティ・プロバイダの更新

29 Oracle Access Managementコンソールを使用したIdentity Federationの設定の管理

この章では、Oracle Access Management Identity Federation用に構成が必要な設定について説明します。この章の内容は次のとおりです。

- 前提条件

- Oracle Access Managementコンソールの「フェデレーション設定」の概要

- フェデレーションの一般設定の管理

- Oracle Access Managementコンソールでのフェデレーションのプロキシ設定の管理

- Oracle Access Managementコンソールでのフェデレーションのキーストア設定の定義

- メタデータのエクスポート

29.1 前提条件

この章に記載されている内容は、第28章「Oracle Access Managementコンソールを使用したIdentity Federation用パートナの管理」のタスクが実行されていることを前提としています。

29.2 Oracle Access Managementコンソールの「フェデレーション設定」の概要

この項では、Oracle Access Managementコンソールで使用可能なIdentity Federationの機能を有効にする際に構成が必要なフェデレーション設定について説明します。

図29-1に、Oracle Access Managementコンソールで表示される「フェデレーション設定」ページを示します。このページは、「ようこそ」ページの「構成」パネルから「Identity Federationサービスの設定」を選択した場合、または「システム構成」タブの「フェデレーション」セクションを表示して「フェデレーション設定」を選択した場合と同じです。

図29-1 「Identity Federationサービスの設定」ページ

表29-1に、構成可能なフェデレーション設定の種類の概要を示します。

表29-1 コンソールの「フェデレーション設定」

要素

説明

一般

フェデレーションの一般設定には、アサーションの送信に使用されるプロバイダやキーに関する基本情報が含まれます。

関連項目: フェデレーションの一般設定の管理

プロキシ

プロキシ設定では、フェデレーションのプロキシ・サーバーを設定できます。

関連項目: Oracle Access Managementコンソールでのフェデレーションのプロキシ設定の管理

キーストア

キーストア設定では、キーストア内のキーに対して別名(略称)を作成できます。

関連項目: Oracle Access Managementコンソールでのフェデレーションのキーストア設定の定義

29.3 フェデレーションの一般設定の管理

この項の内容は次のとおりです。

- フェデレーションの一般設定の管理について

- フェデレーションの一般設定の管理

29.3.1 フェデレーションの一般設定の管理について

フェデレーションの一般的なプロパティの表示と管理は、コンソールの「フェデレーション設定」ページで行います。

図29-2に、「フェデレーション設定」ページの「一般」セクションを示します。

図29-2 「フェデレーション設定」ページの「一般」セクション

表29-2では、「フェデレーション設定」ページの「一般」セクションに含まれる各要素について説明します。

表29-2 フェデレーションの一般設定

要素

説明

プロバイダID

このフェデレーション・サーバーのプロバイダIDです。たとえば、http://foo.example.com/fedです。

署名鍵

この鍵を使用して、アサーションに署名します。

暗号化鍵

この鍵を使用して、着信メッセージの復号化を行います。

カスタム信頼アンカー・ファイル

フェデレーションで使用する信頼できるルート証明書を含むキーストアを指定します。デフォルトの信頼ストアは、
$DOMAIN_HOME/config/fmwconfig/amtruststoreです。

ほとんどの場合、デフォルトの信頼アンカーで十分です。必要に応じて、使用する別のキーストアの場所を指定します。

注意: カスタム信頼アンカー・キーストアを使用する場合、クラスタ全体に自動的に複製されることはありません。このキーストアの複製を管理する必要があります。

SAML 2.0メタデータのエクスポート

「一般」設定の変更後に、フェデレーション・パートナ用のメタデータをエクスポートする必要があります。

関連項目: メタデータのエクスポート

29.3.2 フェデレーションの一般設定の管理

「一般」設定には、プロバイダに関する基本情報が含まれます。

前提条件

ありません。

フェデレーションの「一般」設定を設定または変更する手順

1. Oracle Access Managementコンソールで、次のように「フェデレーション設定」に移動します。
「システム構成」タブ
「フェデレーション」セクション
「フェデレーション設定」ノード

別のアクセス方法: 「ようこそ」ページの「構成」パネルで、「Identity Federationサービスの設定」をクリックします。

2. 「フェデレーション設定」ページで、使用する「一般」設定の値(表29-2)を入力します。

3. 「適用」をクリックして、変更を保存します。

4. 「Oracle Access Managementコンソールでのフェデレーションのプロキシ設定の管理」に進みます。

29.4 Oracle Access Managementコンソールでのフェデレーションのプロキシ設定の管理

この項の内容は次のとおりです。

- フェデレーションのプロキシ設定について

- Identity Federationのプロキシ設定の管理

29.4.1 フェデレーションのプロキシ設定について

Identity Federationでフェデレーション・パートナに直接接続する必要がある場合(SAMLアーティファクトのSSO操作などで)、プロキシが必要になる場合があります。

フェデレーション・パートナ用に構成されたプロキシの表示および管理は、コンソールの「フェデレーション設定」ページで行います。

図29-3に、「フェデレーション設定」ページのフェデレーションのプロキシ設定セクションを示します。続いて、表29-3では、このページのこのセクションに含まれる各要素について説明します。

図29-3 フェデレーションのプロキシ設定

表29-3では、「フェデレーション設定」ページのフェデレーションのプロキシ設定セクションに含まれる各要素について説明します。

表29-3 フェデレーションのプロキシ設定

要素

説明

プロキシの有効化

このボックスを選択すると、プロキシ・サーバーが有効になります。

このボックスが選択されていない場合、プロキシ機能は無効になっており、関連するフィールドにアクセスして編集することはできません。

ホスト

この要素では、プロキシのホスト名を指定します。

ポート

この要素では、プロキシのポート番号を指定します。

非プロキシ・ホスト

プロキシを使用してはならないホストのリストです。複数のホストを区切るには、「;」を使用します。

ユーザー名

プロキシへの接続時に使用するプロキシ・ユーザー名です。

パスワード

プロキシへの接続時に使用するプロキシ・パスワードです。

29.4.2 Identity Federationのプロキシ設定の管理

「フェデレーション設定」ページを表示している場合、ステップ1は省略します。

前提条件

ありません。

フェデレーションの「プロキシ」設定を設定または変更する手順

1. Oracle Access Managementコンソールで、「フェデレーション設定」を次のように見つけて開きます。
「システム構成」タブ
「フェデレーション」セクション
「フェデレーション設定」ノード

2. 「フェデレーション設定」ページで、使用環境に必要な値に対して現在のプロキシ設定値を評価します。

3. 使用環境に適した値(表29-3)を、「プロキシ」設定に入力します。

4. 「適用」をクリックして、変更を保存します。

5. 「Oracle Access Managementコンソールでのフェデレーションのキーストア設定の定義」に進みます。

29.5 Oracle Access Managementコンソールでのフェデレーションのキーストア設定の定義

この項の内容は次のとおりです。

- Identity Federationのキーストア設定の管理について

- Identity Federationの暗号化/署名鍵の管理

29.5.1 Identity Federationのキーストア設定の管理について

フェデレーション・パートナ用に構成されたキーストアの表示と管理は、コンソールの「フェデレーション設定」ページで行います。

図29-4 キーストア設定

表29-4では、「フェデレーション設定」ページのキーストア設定セクションに含まれる各要素について説明します。

表29-4 フェデレーションのキーストア設定

要素

説明

キーストアの場所

この要素では、キーストアのパスを指定します。

キーID

一意のキーIDです。

説明

この要素では、キーの簡単な説明(使用方法など)を指定します。

別名

この要素では、キーの別名を指定します。

注意: ドロップダウンでは、キーストアで使用可能な別名の中からいずれか一つを選択できます。

パスワード

この要素では、キー・パスワードを指定します。

29.5.2 Identity Federationの暗号化/署名鍵の管理

Identity Federationは、次のことを実行する際にキーを使用します。

- 送信アサーションの署名
SAMLメッセージに含まれる着信XML暗号化データの復号化

Identity Federationは、暗号化証明書および署名証明書を格納する際に次のキーストアを使用します。

DOMAIN_HOME/config/fmwconfig/.oamkeystore

タスクの概要: Identity Federationの暗号化/署名鍵の管理

- システム(.oamkeystore)および信頼(amtruststore)キーストア・パスワードのリセット

- システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

注意:

この説明では、AMはAccess Manager、STSはSecurity Token Service、IFはIdentity Federationを表します。

29.5.2.1 システム(.oamkeystore)および信頼(amtruststore)キーストア・パスワードのリセット

次の手順を使用すると、キーストアおよびキーストアと同じパスワードを使用するキー・エントリを保護するパスワードがリセットされます。

キーストアはIM/OAMAM/OSTSインストーラによって作成および構成されており、パスワードとキー・エントリ・パスワードはランダムに生成されています。WLSTのresetKeystorePasswordメソッドを使用すると、.oamkeystoreパスワードおよび.oamkeystoreパスワードと同じパスワードが設定されたキー・エントリに新しい値を設定できます。このコマンドは次のことを実行します。

- .oamkeystoreパスワードの更新

- .oamkeystore内でキーストアと同じパスワードを持つキー・エントリの更新

- OAMAM/STS/IFの構成の更新および変更の反映

- amtruststoreパスワードの更新(キーストアが.oamkeystore(デフォルト)と同じパスワードで保護されている場合)

システム・キーストア(.oamkeystore)・パスワードを設定する手順

1. WLSTスクリプト環境を入力します。

2. connect()コマンドを使用してWebLogic Server AdminServerに接続します。

3. ドメイン・ランタイム・ツリーdomainRuntime()に移動します。

4. 次のコマンドを実行します。

resetKeystorePassword()

5. パスワードを入力および確認します。

29.5.2.2 システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

システム・キーストア(.oamkeystore)に新しいキー・エントリを追加するには、新しいキー・エントリを作成および追加するkeytoolコマンドを使用します。エントリを追加したら、アサーションの署名および着信メッセージの復号化の際にそのエントリを使用できるように、Identity Federation設定の構成画面で定義する必要があります。

このトピックでは、の手順を使用して新しいエントリをシステム・キーストアに追加し、SAMLアサーションの署名、またはWSSに含まれないXML暗号化データの復号化を実行します。

- .oamkeystoreへの新しいエントリの追加

- Identity Federation設定への新しいエントリの追加

- キーの署名および暗号化の構成

29.5.2.2.1 .oamkeystoreへの新しいエントリの追加

前提条件

システム・キーストア(.oamkeystore)・パスワードをリセットしておきます。

新しいエントリを構成する手順

1. keytoolを探します。

2. keytoolを使用して次のことを実行します。

- 自己署名付き証明書を生成します。または、

- 証明書リクエストを生成し、リクエストをリモート認証局(CA)にエクスポートして、さらにCAで発行された証明書をインポートします。

29.5.2.2.2 Identity Federation設定への新しいエントリの追加

その手順は次のとおりです。

1. Oracle Access Managementコンソールで、「フェデレーション設定」を次のように見つけて開きます。

System Configuration tab
Federation section
Federation Settings node

2. 「フェデレーション設定」ページで、「キーストア」表に移動します。

3. 行を追加します。

4. Identity Federationの構成時にこのキーを参照するために使用するキーIDを入力します。

5. .oamkeystoreに格納されるキー・エントリの別名を選択します。

6. キー・パスワードを入力します。

7. 「適用」をクリックします。

29.5.2.2.3 キーの署名および暗号化の構成

キーストア表にキーを追加したら、Identity Federationを構成してそのキーを使用できます。その手順は次のとおりです。

1. Oracle Access Managementコンソールで、「フェデレーション設定」を次のように見つけて開きます。

System Configuration tab
Federation section
Federation Settings node

2. 「一般」セクションに移動します。

3. キーストア表に定義されている使用可能なキー・エントリのリストから署名鍵を選択します。

4. キーストア表に定義されている使用可能なキー・エントリのリストから暗号鍵を選択します。

5. 「適用」をクリックします。

これでIdentity Federationで前述のキーを使用してメッセージの署名および復号化を行えるようになりました。

29.6 メタデータのエクスポート

「一般」設定を変更した後で、フェデレーション・パートナ用のメタデータをエクスポートできます。

SAML 2.0メタデータをエクスポートする手順

メタデータをエクスポートするには、次の手順を実行します。

1. Oracle Access Managementコンソールで、「フェデレーション設定」を次のように見つけて開きます。
「システム構成」タブ
「フェデレーション」セクション
「フェデレーション設定」ノード

2. 「フェデレーション設定」ページで、「SAML 2.0メタデータのエクスポート」をクリックします。

3. ダイアログ・ボックスが表示され、メタデータのエクスポート先ファイルの場所を指定するよう求められます。

4. 「保存」をクリックして、新しいメタデータ・ファイルを保存します。

30 Oracle Access Managementコンソールを使用したフェデレーション関連のスキームおよびポリシーの管理

この章では、Oracle Access Management Identity Federation用に構成が必要なフェデレーション関連の認証スキームとポリシーについて説明します。

この章の内容は次のとおりです。

- 前提条件

- Identity FederationとAccess Managerの併用方法の概要

- Identity Federation 11gリリース2(11.1.2)の認証スキームおよび認証モジュールの使用

- Oracle Identity Federation 11gリリース1の認証スキームおよび認証モジュールの使用

- Identity Federationで使用するAccess Managerのポリシーの管理

- Identity Federationの構成のテスト

- デフォルト・アイデンティティ・プロビジョニング・プラグインの使用

- アイデンティティ・プロバイダ検出サービスの構成

- フェデレーション・ユーザー自己登録モジュールの構成

30.1 前提条件

1つ以上の認証スキームを定義することにより、Oracle Access Management Access Managerとフェデレーション・プロバイダを連携して、Access Managerで保護されたリソースへのアクセスを要求するユーザーを認証できるようになります。

Identity Federationの概念、背景および大まかなフローについては、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』の「Oracle Identity Federationのデプロイ」の章を参照してください。

30.2 Identity FederationとAccess Managerの併用方法の概要

Access Managerとフェデレーション機能を併用する方法はリリースによって異なります。Identity Federationと統合する場合は次のとおりです。

- 11gリリース1(11.1.1)のサイト、および11gリリース1(11.1.1)から11gリリース2(11.1.2)にアップグレードしたサイトでは、Oracle Fusion Middleware Oracle Identity Management Suite統合ガイドに記載されている統合を使用できます。

- 新しい11gリリース2(11.1.2)インストールを使用するサイトでは、Oracle Access Managementコンソールを使用してフェデレーション機能を利用できます。

30.3 Identity Federation 11gリリース2 (11.1.2)の認証スキームおよび認証モジュールの使用

この項の内容は次のとおりです。

- スキームFederationSchemeについて

- モジュールFederationPluginについて

30.3.1 スキームFederationSchemeについて

FederationSchemeは、Identity Federation 11gリリース2(11.1.2)で使用される汎用スキームです。

図30-1に、AccessコンソールのFederationSchemeのページを示します。

図30-1 FederationScheme

表30-1では、FederationSchemeについて説明します。

表30-1 FederationSchemeの要素の定義

要素

説明

名前

スキーム名です。

説明

スキームの簡単な説明です。

認証レベル

認証スキームの信頼レベルです。

デフォルト

「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックスです。

チャレンジ・メソッド

チャレンジ・メソッドは、ドロップダウン・ボックスで使用可能なチャレンジ・メソッドから選択できます。

チャレンジ・リダイレクトURL

ユーザー・リクエストを処理するためのリダイレクト先となる別のサーバーのURLです。

認証モジュール

スキームで使用する認証モジュールです。

チャレンジURL

資格証明コレクションのために資格証明コレクタがリダイレクトするURLです。フェデレーション・プラグインでは使用されません。

コンテキスト・タイプ

この要素を使用して、資格証明コレクタの最後のURLを作成します。

コンテキスト値

この要素を使用して、資格証明コレクタの最後のURLを作成します。値はコンテキスト・タイプによって異なります。

チャレンジ・パラメータ

チャレンジで使用するパラメータ(ある場合)のリストです。

関連項目:

FederationSchemeの指定については、表16-20を参照してください。

スキームFederationMTSchemeについて

認証スキームFederationMTSchemeは、11gリリース2(11.1.2)で使用するために設計されたもう一つのスキームです。これはマルチテナント環境で使用します。

30.3.2 モジュールFederationPluginについて

FederationPluginにはカスタム認証モジュールが用意されています。

図30-2 FederationPlugin

表30-2では、FederationPluginのステップについて説明します。

表30-2 FederationPluginのステップ

要素

説明

ステップ名

モジュール内のステップ名です。

説明

この要素は、ステップの簡単な説明です。

プラグイン名

この要素では、ステップに関連付けるプラグインを指定します。

図30-3に、FederationPluginの編成を示します。これは、表16-14「ステップ編成」サブタブに記載されている編成と同じものです。

編成では、プラグイン内でのステップの順序とそれらの各ステップが成功または失敗した場合の処理を指定できます。

図30-3 FederationPluginの編成

表30-3では、FederationPluginの編成について説明します。

表30-3 FederationPluginの編成

要素

説明

名前

ステップ名です。ステップは実行される順序でこの列に表示されます。順序は「最初のステップ」ドロップダウンで変更できます。

説明

ステップの簡単な説明です。

成功時

ステップが正常に完了した場合に実行するアクションです(編成内の次のステップの実行など)。

エラー発生時

エラーが発生した場合に実行するアクションです(指定の失敗アクションの実行など)。

失敗時

ステップが失敗した場合に実行するアクションです。

30.3.3 11gリリース2のIdentity Federationでの認証の管理

この項では、FederationSchemeおよびカスタム認証モジュールであるFederationプラグインの管理方法について説明します。

前提条件

ありません。

FederationSchemeを表示または変更する手順

1. Oracle Access Managementコンソールで、FederationSchemeを次のように見つけて開きます。
ポリシー構成
共有コンポーネント
認証スキーム
FederationScheme

2. FederationSchemeの詳細が、デプロイメントで必要な要件を満たしていることを確認します。フィールドの詳細は、表30-1を参照してください。

3. 「保存」ボタンをクリックします。

FederationPluginを表示または変更する手順

1. Oracle Access Managementコンソールで、FederationPluginを次のように見つけて開きます。
システム構成
Access Managerの設定
認証モジュール
カスタム認証モジュール
FederationPlugin

2. FederationPluginの詳細が、デプロイメントで必要な要件を満たしていることを確認します。プラグインのステップの詳細は、表30-2を参照してください。

3. ステップの表の上にあるアイコンを使用して、ステップを追加(+)または削除(x)します。

4. 必要に応じて「ステップ編成」を使用して、ステップの順序を変更します。編成の詳細は、表30-3を参照してください。

5. 「保存」ボタンをクリックします。

FederationSchemeを使用する認証ポリシーを追加する手順

前提条件: ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義されている必要があります。

次の手順に従って、FederationSchemeを使用する認証ポリシーを設定し、このポリシーを使用して保護対象のリソースを関連付けます。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。

Application Domains
Desired Domain

2. ナビゲーション・ツリーで、「認証ポリシー」をクリックし、次に「作成」ボタンをクリックして、新しいページを開きます。

3. 次に示すポリシーの一般詳細を追加します(表17-9「認証ポリシーの要素および説明」を参照してください)。

- 名前

- 認証スキーム

4. 次に示すグローバル・ポリシー要素および指定を追加します。

- 説明(オプション)

- 成功URL

- 失敗URL

5. 次の手順に従ってリソースを追加します。

1. 認証ポリシー・ページの「リソース」タブをクリックします。

2. タブの「追加」ボタンをクリックします。

3. リストからURLを選択します。

4. 必要に応じてこれらの手順を繰り返して、リソースを追加します。

6. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

7. レスポンス: 「SSOのポリシー・レスポンスの概要」および「SSOのポリシー・レスポンスの追加および管理」を参照してください。

認証ポリシーを定義して、そのポリシーをリソースに関連付ける場合のコンソール・ページを図30-4に示します。

図30-4 FederationSchemeを使用した認証ポリシーの設定

30.4 Oracle Identity Federation 11gリリース1の認証スキームおよび認証モジュールの使用

この項では、Oracle Fusion Middlewareリリース11g R1(11.1.1)のOracle Identity Federationサーバーで使用可能な認証スキームおよび認証モジュールについて説明します。

注意:

11gリリース2(11.1.2)のIdentity Federationで使用するスキームについては、第30.3項を参照してください。

認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームは、定義された認証モジュールも含む必要があります。

関連項目:

スキームの詳細は、第16.9項を参照してください。

- スキームOIFSchemeについて

- モジュールOIFMTLDAPPluginについて

- Oracle Identity Federationリリース11gR1での認証の管理

30.4.1 スキームOIFSchemeについて

OIFSchemeおよびOIFMTSchemeは、Oracle Identity Federation 11gリリース1(11.1.1)との統合で使用されます。

注意:

Identity Federation 11gリリース2 (11.1.2)で使用可能なスキームについては、第30.3項を参照してください。

図30-5 OIFScheme

表30-4では、スキームOIFSchemeについて説明します。

表30-4 OIFSchemeの定義

要素

説明

名前

スキーム名です。

説明

スキームの簡単な説明です。

認証レベル

認証スキームの信頼レベルです。

デフォルト

「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックスです。

チャレンジ・メソッド

チャレンジ・メソッドは、ドロップダウン・ボックスで使用可能なチャレンジ・メソッドから選択できます。

チャレンジ・リダイレクトURL

ユーザー・リクエストを処理するためのリダイレクト先となる別のサーバーのURLです。

認証モジュール

スキームで使用する認証モジュールです。

チャレンジURL

資格証明コレクションのために資格証明コレクタがリダイレクトするURLです。

コンテキスト・タイプ

この要素を使用して、資格証明コレクタの最後のURLを作成します。

チャレンジ・パラメータ

チャレンジで使用するパラメータ(ある場合)のリストです。

関連項目:

OIFSchemeの指定については、表16-20を参照してください。

30.4.2 モジュールOIFMTLDAPPluginについて

OIFMTLDAPPluginは、フェデレーテッド・テナントの認証にはIdentity Federationを使用し、非フェデレーテッド・テナントの認証にはAccess Managerに関連付けられたアイデンティティ・ストアを使用します。

図30-6 OIFMTLDAPPlugin

表30-5では、OIFMTLDAPPluginのステップについて説明します。

表30-5 OIFMTLDAPPluginのステップ

要素

説明

ステップ名

モジュール内のステップ名です。

説明

この要素には、このステップの簡単な説明です。

プラグイン名

この要素では、このステップに関連付けるプラグインを指定します。

プラグイン・パラメータ

この要素は、プラグインの実行に必要なパラメータ(ある場合)のリストです。パラメータのリストはプラグインによって異なります。

30.4.3 Oracle Identity Federationリリース11gR1での認証の管理

この項では、OIFSchemeおよびIdentity Federation 11gリリース1(11.1.1)のカスタム認証モジュールであるOIFMTLDAPPluginの管理方法について説明します。

前提条件

ありません。

OIFSchemeを表示または変更する手順

1. Oracle Access Managementコンソールで、OIFSchemeを次のように見つけて開きます。
ポリシー構成
共有コンポーネント
認証スキーム
OIFScheme

2. OIFschemeの詳細が、デプロイメントで必要な要件を満たしていることを確認します。フィールドの詳細は、表30-4を参照してください。

3. 「保存」ボタンをクリックします。

前提条件

ありません。

OIFMTLDAPPluginを表示または変更する手順

1. Oracle Access Managementコンソールで、OIFMTLDAPPluginを次のように見つけて開きます。
システム構成
Access Managerの設定
カスタム認証モジュール
OIFMTLDAPPlugin

2. OIFMTLDAPPluginの詳細を確認し、デプロイ対象として構成されていることを確認します。フィールドの詳細は、表30-5を参照してください。

3. 「保存」ボタンをクリックします。

OIFSchemeを使用する認証ポリシーを追加する手順

このタスクの手順は、「FederationSchemeを使用する認証ポリシーを追加する手順」に記載されているものと同じです。

30.5 Identity Federationで使用するAccess Managerのポリシーの管理

この項では、フェデレーション・ポリシーに従ってAccess Managerでポリシー・レスポンスを使用する方法について説明します。

- Identity Federationのアサーション属性を含むポリシー・レスポンスについて

- Identity Federationのアサーション属性を含むポリシー・レスポンスの定義

30.5.1 Identity Federationのアサーション属性を含むポリシー・レスポンスについて

ポリシーには、1つ以上の認証レスポンスまたは認可レスポンスあるいはその両方をオプションで含めることができます。Identity FederationでAccess Managerのポリシー・レスポンスを設定する際に、アサーション属性を使用するよう構成できます。

アサーション属性は、次のようなコンテキストで使用します。

- 認可ポリシーの条件

- HTTPヘッダーのレスポンス属性

- アイデンティティ・コンテキストのレスポンス属性

図30-7に、認可ポリシーの「レスポンス」構成タブを示します。

図30-7 認可ポリシーの「レスポンス」タブ

表30-6では、ポリシー・レスポンスの要素について説明します。

表30-6 ポリシー・レスポンスの要素

要素

説明

名前

このレスポンスと同じメカニズム(タイプ)を使用する他のレスポンスを区別する一意の名前です。

タイプ

値文字列を使用して実行されるアクションのレスポンス形式を伝達するために使用されるメカニズムです。「アサーション属性」を選択します。

値

変数として設定されるレスポンスの式です。認証または認可ポリシーでフェデレーション・データをレスポンス属性として指定する場合、次の値を参照できます。

- 名前IDの値の場合は$session.attr.fed.nameidvalue

- その他のアサーション属性の場合は$session.attr.fed.attr.AttributeName

30.5.2 Identity Federationのアサーション属性を含むポリシー・レスポンスの定義

Oracle Access Managementコンソールを使用して、アサーション属性を含むポリシー・レスポンスを構成します。

Identity Federationの条件およびレスポンスの背景

Identity Federationの条件とレスポンスは別々のタスクで使用されるため、個別に指定する必要があります。

条件は、Access Manager内のリソースへのアクセスを制御するために使用されます。

たとえば、アイデンティティ・プロバイダでロール・アサーションを送信し、サービス・プロバイダでリソースへのアクセスをsalesというロールを持つユーザーのみに許可する場合、次のような条件を追加します。

- 条件ネームスペースを「セッション」にします。

- 「名前」を「fed.attr.role」にします。

- 「演算子」を「次と等しい」に設定します。

- 値は「sales」です。

注意:

- この例のロールを実際のSAMLでアサートされる属性に置き換えてください。

- 標準のSAML名前IDの値を条件として使用する場合の値は「attr.fed.nameidvalue」です。

これに対し、アサートされた属性をレスポンスによってアプリケーションに渡すことができます。たとえば、アサートされた属性roleをHTTPヘッダーでバックエンドのアプリケーションに渡す場合は次のようにします。

- 「レスポンス」タブに移動します。

- Roleというヘッダー(HTTPヘッダーの名前)を追加します。

- 値は$session.attr.fed.attr.roleです。

この場合も、この例のロールを実際にアサートされるSAML属性に置き換えてください。

前提条件

ありません。

アサーション属性を含むポリシー・レスポンスを表示する手順

1. Oracle Access Managementコンソールで、レスポンスを表示または構成するポリシーを次のように見つけて開きます。
ポリシー構成
アプリケーション・ドメイン
対象のドメイン
認証ポリシー(認可ポリシー)
対象のポリシー

2. 「レスポンス」タブを選択します。

3. 該当するアイコンをクリックして、レスポンスを追加、削除、更新します。

4. 更新する場合は、そのレスポンスの詳細が、デプロイメントで必要な要件を満たしていることを確認します。フィールドの詳細は、表30-6を参照してください。

5. 「保存」ボタンをクリックします。

図30-8に、フェデレーションのレスポンス属性の構成例を示します。

図30-8 フェデレーションのレスポンス属性のAuthZポリシーへの追加

30.6 Identity Federationの構成のテスト

前のセクションで説明した手順を実行すると、SPモードのフェデレーションを構成するためのすべての手順が完了します。この手順を要約すると、次のようになります。

1. Oracle Access Managementコンソールを使用してIdentity Federationのサービスを有効にします。

2. IdPパートナを作成するか、既存のIdPパートナを使用します。

3. IdPの設定(SAML属性、グローバル・ログアウトおよび名前IDフォーマットなど)が構成されていることを確認します。

4. FederationSchemeおよびフェデレーションのレスポンス属性を使用する認証/認可ポリシーを構成します。

5. このポリシーでリソースを保護します。

この構成をテストするには、認証ポリシーで保護されたリソースにアクセスし、そのアクセスがポリシーで許可または拒否されているかを検証します。

テストSPモジュール

Identity Federationには、テストSPモジュールが用意されています。このモジュールを使用すると次のことが可能になります。

- フェデレーションSSOとIdPパートナのテスト

- フェデレーションSSO操作の結果およびアイデンティティ・プロバイダが送信したアサーションの確認

テストSPモジュールを有効または無効にするには、次の手順に従います。

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. テストSPモジュールを有効にするには、次のWLSTコマンドを実行します。

configureTestSPEngine("true")

5. テストSPモジュールを無効にするには、次のWLSTコマンドを実行します。

configureTestSPEngine("false")

注意:

本番環境では、テストSPモジュールを無効にする必要があります。

テストSPモジュールにアクセスし、IdPパートナとのフェデレーションSSO操作を実行するには、次の手順に従います。

1. 次のサービスにアクセスします。

http(s)://oam-hostname:oam-port/oamfed/user/testspsso

2. フェデレーションSSOを実行するIdPを選択します(注意: リストには有効なIdPパートナのみが表示されます)。

3. フェデレーションSSO操作を開始します。ブラウザは認証用のIdPパートナにリダイレクトされた後、フェデレーション・レスポンスによってIdentity Federationに再度リダイレクトされます。

4. Identity Federationによってフェデレーションのアサーションが処理され、テストSPモジュールによって処理結果が表示されます(注意: この操作の結果、作成されるAccess Managerセッションはありません)。

30.7 デフォルト・アイデンティティ・プロビジョニング・プラグインの使用

11gリリース2(11.1.2)が提供するプラグインを使用すると、フェデレーテッドSSO操作時に存在しないアイデンティティを必要に応じてプロビジョニングすることができます。

- プロビジョニング・プラグインを使用する理由

- デフォルト・プロビジョニング・プラグインについて

- デフォルト・プロビジョニング・プラグインの使用

- カスタム・プロビジョニング・プラグインへの切替え

30.7.1 プロビジョニング・プラグインを使用する理由

フェデレーテッドSSOトランザクションが開始されると、処理フローは次のようになります。

1. IdPがユーザーを認証し、アサーションをOracle Access Management Identity Federationに送信します。

2. SPとして動作するIdentity Federationがユーザーをローカル・アイデンティティ・ストアにマップします。

3. ユーザーがローカル・ストアに存在しない場合、マッピングは失敗します。

このような問題を解決するには、トランザクションを継続できるようにユーザーをプロビジョニングする機能が必要です。

30.7.2 デフォルト・プロビジョニング・プラグインについて

アイデンティティ・マッピングの失敗を処理するために、Identity Federationでは、アイデンティティ・ストアに存在しないユーザーをプロビジョニングするためのプラグイン(デフォルト・プロビジョニング・プラグインと呼ばれる)を設定する機能をサポートしています。これにより、フェデレーテッド・シングル・サインオンの続行が可能になります。

ユーザーは、IdPパートナに関連付けられたアイデンティティ・ストア内にプロビジョニングされます。

次の項で説明するように、プラグインのプロビジョニングで使用される属性のリストを指定できます。

30.7.3 デフォルト・プロビジョニング・プラグインの使用

このデフォルト・プロビジョニング・プラグインは、プラグイン構成インタフェースから有効にできます。その手順は次のとおりです。

1. プラグイン構成インタフェースからFedUserProvisioningPluginを選択します。

2. 「構成パラメータ」タブで、次のパラメータを設定します。

- KEY_USER_RECORD_ATTRIBUTE_LIST: ユーザーのプロビジョニングで使用される属性のリストです。この属性はアサーションの一部として使用できます。例: mail、givenname。(オプション)

- KEY_PROVIDERID_ATTRIBUTE_NAME: 実行時にIdentity Federationがテナント名を移入する、アイデンティティ・ストア内のテナントID属性の名前です。(オプション)

- KEY_USERID_ATTRIBUTE_NAME: アサーション属性のuserid値に使用される属性名です。(オプション)

3. 次のWLSTコマンドを実行して、デフォルト・プラグインによるユーザー・プロビジョニングを有効にします。

putBooleanProperty("/fedserverconfig/userprovisioningenabled","true")

30.7.4 カスタム・プロビジョニング・プラグインへの切替え

Identity Federationでは、カスタム・プロビジョニング・プラグインを使用することもできます。

デフォルト・プラグインからカスタム・プラグインに切り替えるには、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム・ユーザー・プロビジョニング・プラグインの開発に関する章のガイドラインに従います。

カスタム・プラグインを使用する場合、次のWLSTコマンドを使用してプラグイン名を設定します。

putStringProperty("/fedserverconfig/userprovisioningplugin","CustomPlugin")

30.8 アイデンティティ・プロバイダ検出サービスの構成

アイデンティティ・プロバイダ検出は、SSOで使用するアイデンティティ・プロバイダを(多くの場合、ユーザーとの対話によって)選択するためのサービスです。Identity Federationは、アイデンティティ・プロバイダ検出サービスを備えていませんが、SPが開始するSSOにおいて、SPへの認証リクエストでIdPが渡されなかった場合に、IdPを選択するサービスを使用できるようサポートしています。

IdP検出の詳細は次の仕様を参照してください。

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cs-01.pdf

Identity Federationがサービス・プロバイダとして動作している場合、パートナIdPのプロバイダIDが指定されずにSSO操作が開始された場合に、SSOを実行するアイデンティティ・プロバイダを選択するためのIdP検出サービスにユーザーをリダイレクトするよう構成できます。

ユーザーがアイデンティティ・プロバイダを選択すると、選択したIdPを含むSSOリクエストがカスタム・ページからIdentity Federationに再送信されます。

- バンドルされたIdP検出サービスの使用

- カスタムIdP検出サービスの作成

- IdP検出サービスの使用の無効化

30.8.1 バンドルされたIdP検出サービスの使用

Identity Federationには、単純なアイデンティティ・プロバイダ検出サービスが用意されています。これを使用することにより、フェデレーションSSO操作で使用されるフェデレーションIdPパートナを実行時に決定できます。

IdP検出を構成するには、次の手順に従います。

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. 次のWLSTコマンドを実行して、IdP検出サービスを使用するようにIdentity Federationを構成します。

putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "true")

5. 次のWLSTコマンドを実行して、デフォルトのすぐに使用可能なIdP検出サービスを使用するようにIdentity Federationを構成します。

putBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "true")putStringProperty("/spglobal/idpdiscoveryserviceurl", "/oamfed/discovery.jsp")

30.8.2 カスタムIdP検出サービスの作成

リモートでデプロイされたカスタムIdP検出サービスとやり取りするようにIdentity Federationを構成できます。

カスタムIdP検出を使用するようにIdentity Federationを構成するには、次の手順に従います。

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. 次のWLSTコマンドを実行して、IdP検出サービスを使用するようにIdentity Federationを構成します。

putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "true")

5. 次のWLSTコマンドを実行して、カスタムIdP検出サービスを使用するようにIdentity Federationを構成します(IDP_DISCOVERY_SERVICE_URLを検出サービスの完全修飾URLに置き換えます)。

putBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "false")
putStringProperty("/spglobal/idpdiscoveryserviceurl", "IDP_DISCOVERY_SERVICE_URL")

実行時に、Identity Federationは次のパラメータを指定して、IdP検出サービス・ページへのリダイレクトを行います。

- return: このページからIdentity Federationに対する新しいリクエストの送信先のURLです。リクエストには選択されたIdPのプロバイダIDが含まれます。

- returnIDParam: Identity Federationに送信するリクエストで、選択されたIdPのプロバイダIDを指定する際に使用するパラメータの名前です。

検出サービスはこれらのパラメータの値を取得し、IdPのリストを表示した後、選択されたIdPのプロバイダIDを指定して新しいリクエストをIdentity Federationに送信します。

注意:

URL問合せパラメータ値が正しくURLエンコードされていることを確認します。

例

IdP検出サービス・ページの例を次に示します。このページでは、ユーザーがアイデンティティ・プロバイダを(プロバイダIDのリストhttp://idp1.com, http://idp2.com, http://idp3.comから)選択すると、選択されたプロバイダIDがIdentity Federationに送信され、SSOフローが続行されます。

<%@ page buffer="5kb" autoFlush="true" session="false"%>
<%@ page language="java" import="java.util.*, java.net.*"%>

<%
// Set the Expires and Cache Control Headers
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

// Set request and response type
request.setCharacterEncoding("UTF-8");
response.setContentType("text/html; charset=UTF-8");

String submitURL = request.getParameter("return");
String returnIDParam = request.getParameter("returnIDParam");

List idps = new ArrayList();
idps.add("http://idp1.com");
idps.add("http://idp2.com");
idps.add("http://idp3.com");

%>

<html>
<title>
Select an Identity Provider
</title>
<body bgcolor="#FFFFFF"><form  method="POST" action="<%=submitURL%>" id="PageForm" name="PageForm" autocomplete="off">
<center>
<table cellspacing="2" cellpadding="5" border="0" width="500">
<tr><td colspan="2" align="center">
Select an Identity Provider
</td></tr>
</tr>
<tr>
<td align="right">Provider ID</td>
<td>
<select size="1" name="<%=returnIDParam%>">
<%
Iterator idpIT = idps.iterator();
while(idpIT.hasNext())
{
String idp = (String)idpIT.next();
%>
<option value="<%=(idp)%>"><%=idp%></option>
<%
}
%>

</select>
</td>
</tr>
<tr>
<td colspan="2" align="center">
<input type="submit" value="Continue"/>
</td>
</tr>
</table>
</center>
</form>
</body>
</html>

30.8.3 IdP検出サービスの使用の無効化

IdP検出サービスの使用を停止するようにIdentity Federationを構成するには、次の手順に従います。

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. 次のWLSTコマンドを実行して、IdP検出サービスの使用を停止するようにIdentity Federationを構成します。

putBooleanProperty("/spglobal/idpdiscoveryserviceenabled", "false")
putBooleanProperty("/spglobal/idpdiscoveryservicepageenabled", "false")
putStringProperty("/spglobal/idpdiscoveryserviceurl", "/oamfed/discovery.jsp")

30.9 フェデレーション・ユーザー自己登録モジュールの構成

Identity Federationがサービス・プロバイダ(SP)モードで動作している場合、LDAPディレクトリ内のローカル・ユーザー・レコードにユーザー・アサーションがマップされ、フェデレーテッド・シングル・サインオンが完了します。フェデレーションSSO操作を実行するユーザーのローカル・アカウントが存在しないためにマッピングが失敗した場合に、ユーザー自己登録フローを起動してユーザーがローカルにアカウントを作成できるようにIdentity Federationを構成できます。

実行時にアサーション・マッピング操作に失敗した場合に、自己登録が有効な場合は、ユーザー自己登録フレームは次のことを実行します。

- 自己登録ページにユーザーをリダイレクトします。

- 自己登録ページには次のフィールドがあります。

- username

- password

- confirm password

- first name

- last name

- email address

これらのフィールドには、アサーションからのデータを事前に移入しておくことができます。また、アサーション・マッピング処理で使用されるフィールドを編集することはできません。セキュリティ上の理由により、アサーション・マッピング操作で使用する情報をユーザーが変更することはできません。

- ユーザーがアカウントを作成すると、フェデレーションSSOフローが再開され、Access Managerセッションが作成されます。この時点で、ユーザーは保護されたリソースにリダイレクトされます。

ユーザー自己登録モジュールを有効または無効にするには、次の手順に従います。

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. ユーザー自己登録モジュールを有効にするには、次のWLSTコマンドを実行します。

putBooleanProperty("/fedserverconfig/userregistrationenabled", "true")
putStringProperty("/fedserverconfig/userregistrationurl", "/oamfed/registration.jsp")

5. ユーザー自己登録モジュールを無効にするには、次のWLSTコマンドを実行します。

putBooleanProperty("/fedserverconfig/userregistrationenabled", "false")
putStringProperty("/fedserverconfig/userregistrationurl", "/oamfed/registration.jsp")

アサーションに含まれるデータが自己登録ページの各フィールドに事前に移入されるようにIdentity Federationを構成できます。デフォルトでは、自己登録ページのそれらのフィールドは、次の内容に基づいて移入されます。

- firstname: Identity Federationは、アサーションに含まれるfirstname属性またはgivenname属性のいずれかを使用します。userregistrationfirstnameattr構成プロパティには、このフィールドの移入時に使用されるカンマ区切り属性のリストを指定します。デフォルトでは、このフィールドにはfirstname,givennameが設定されます。

- last name: Identity Federationは、アサーションに含まれるlastname属性またはsn属性のいずれかを使用します。userregistrationlastnameattr構成プロパティには、このフィールドの移入時に使用されるカンマ区切り属性のリストを指定します。デフォルトでは、この設定にはlastname,snが設定されます。

- email address: Identity Federationは、アサーションに含まれるmail属性またはアサーションの名前ID(fed.nameidvalueで参照される)のいずれかを使用します。userregistrationemailattr構成プロパティには、このフィールドの移入時に使用されるカンマ区切り属性のリストを指定します。デフォルトでは、この設定にはmail,fed.nameidvalueが設定されます。

- username: Identity Federationは、アサーション属性を使用してこのフィールドに移入するように構成されていません。userregistrationusernameattr構成プロパティには、このフィールドの移入時に使用されるカンマ区切り属性のリストを指定します。デフォルトでは、この設定は空です。

アサーションの属性または名前IDが欠落している場合、フィールドは空になります。

userregistrationfirstnameattr、userregistrationlastnameattr、userregistrationemailattrおよびuserregistrationusernameattrの各プロパティを構成する手順

1. WLST環境を入力します。

$OH/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect()

3. ドメイン・ランタイムの場所に移動します。

domainRuntime()

4. first nameフィールドのルールを設定するには、次のWLSTコマンドを実行します。

putStringProperty("/fedserverconfig/userregistrationfirstnameattr", "firstname,givenname")

5. last nameフィールドのルールを設定するには、次のWLSTコマンドを実行します。

putStringProperty("/fedserverconfig/userregistrationlastnameattr", "lastname,sn")

6. email addressフィールドのルールを設定するには、次のWLSTコマンドを実行します。

putStringProperty("/fedserverconfig/userregistrationemailattr", "mail,fed.nameidvalue")

7. usernameフィールドのルールを設定するには、次のWLSTコマンドを実行します。

putStringProperty("/fedserverconfig/userregistrationusernameattr", "uid,fed.nameidvalue")

第VIII部

Oracle Access Managementセキュリティ・トークン・サービスの管理

第VIII部では、管理者がOracle Access Managementで使用できるセキュリティ・トークン・サービスを管理する際に役に立つ情報を提供します。

第VIIIの構成は次のとおりです。

- 第31章「セキュリティ・トークン・サービスの実装シナリオ」

- 第32章「セキュリティ・トークン・サービスの設定値と設定の管理」

- 第33章「Security Token Serviceの証明書と鍵の管理」

- 第34章「テンプレート、エンドポイントおよびポリシーの管理」

- 第35章「Token Serviceパートナとパートナ・プロファイルの管理」

- 第36章「セキュリティ・トークン・サービスのトラブルシューティング」

31 セキュリティ・トークン・サービスの実装シナリオ

この章では、セキュリティ・トークン・サービスの実装シナリオおよび処理シナリオをいくつか示します。シナリオの詳細に関係なく、構成タスクとトークン処理の両方に多数の類似点があります。この章の内容は次のとおりです。

- 前提条件

- 一般的なトークン・エコシステム

- シナリオ: Access Managerトークンを使用したアイデンティティ伝播

- シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

31.1 前提条件

Oracle Access Managementセキュリティ・トークン・サービスの概要.

31.2 一般的なトークン・エコシステム

ここで取り上げる抽象モデルは、このようなモデルをサポートするためにSecurity Token Serviceに設定されている要件を示すために役立ちます。

ここでは、セキュリティ・トークン・エコシステムという語句を使用して、セキュリティ・トークンが使用される一般的な環境を表します。このような環境では、環境に必要なセキュリティ・モデルに基づいて、セキュリティ・トークンを使用してブローカ・トラストやシングル・サインオンなどの最終目標を達成できます。ここに示すように、環境およびセキュリティ・トークンのタイプに関係なく、いくつかの側面はすべてのモデルに共通しています。

図31-1に、トークン発行局、トークン・リクエスタ、トークン・コンシューマ、セキュリティ・トークンなどを含む一般的なトークン・エコシステムを示します。

図31-1 一般的なトークン・エコシステム

「図31-1 一般的なトークン・エコシステム」の説明

アクターとプロセスの概要: 一般的なトークン・エコシステム

1. トークン・リクエスタは、トークン発行局にセキュリティ・トークンをリクエストします。
このセキュリティ・トークンは、サービス・プロバイダ(セキュリティ・トークンを受け入れるトークン・コンシューマ)が提供するサービスと通信し、サービスへのアクセスをリクエストする必要があります。

- トークン・リクエスタは、トークン発行局のパートナである可能性があります(通常はトークン発行局に登録されます)。

- トークン・リクエスタは、エンド・ユーザーである可能性があります(通常はトークン発行局には登録されません)。

2. トークン発行局(Access Manager、Security Token Serviceなど)は、次のようにセキュリティ・トークン・リクエストを受信および処理し、セキュリティ・トークンを返します。

- 入力資格証明を認証します。

- 特定のトークン・コンシューマのセキュリティ・トークンのリクエストを認可されているトークン・リクエスタを指定するトークン発行ポリシーに基づいて、セキュリティ・トークン・リクエストを認可します。

3. トークン・コンシューマ(通常はサービス・プロバイダ)。

- セキュリティ・トークンをサービス・リクエストの一部として受け入れ、入力セキュリティ・トークンの有効性に基づいてサービスを提供します。

- トークン発行局を使用して入力セキュリティ・トークンを検証します。

注意:

トークン・コンシューマは通常、トークン発行局の登録済パートナです。トークン・コンシューマはリライイング・パーティとも呼ばれます。これは、トークン・リクエスタ認証のためにトークン発行局を信頼し、依存しているためです。トークン・コンシューマ(リライイング・パーティ・パートナ)は、Webアプリケーション(Access Managerの場合、Security Token Serviceがトークン発行局)またはSTSリライイング・パーティWebサービスです。

31.3 シナリオ: Access Managerトークンを使用したアイデンティティ伝播

これは、ユーザーのアイデンティティ情報をWebアプリケーションからWebサービス・プロバイダに伝播する必要があるデプロイメントです。Webサービス・プロバイダは、Webアプリケーションと同じセキュリティ・ドメインに存在することも、別のセキュリティ・ドメインに存在することもできます。

図31-2 OAMトークンを使用したアイデンティティ伝播

「図31-2 OAMトークンを使用したアイデンティティ伝播」の説明

アイデンティティ伝播とは、元のユーザー・コンテキストを元のセキュリティ層またはドメイン境界の外側で表示できるようになることです。ユーザー・セキュリティ・コンテキストは、ステップアップ認証、認可、監査/内部アプリケーション固有のビジネス・ロジックなど、層またはドメイン固有のセキュリティ・ニーズをサポートするために、異なるセキュリティ層またはドメインに伝播されます。

ID伝播は、最初のノードで確立されたアイデンティティ・コンテキストを後続のノードに伝播するときに、そのアイデンティティのコンテキストでリクエストをさらに処理できるようにするために、リクエストの分散処理で発生すると言われています。

ID伝播は複数の方法で実行できます。IDプロバイダがIDアサーションのトラスト・ブローカとして機能する、ブローカ・トラスト・モデルに基づく方法があります。ここで説明する内容は、このモデルに関連しています。

図31-3に、ブローカ・トラスト・モデルのID伝播シナリオを示します。このシナリオでは、ユーザー向けアプリケーションがエンド・ユーザーのコンテキストでバックエンド・サービス・アプリケーションによる処理を要求する必要があります。ID伝播の主な側面を明らかにするために、エンド・ユーザー、アプリケーションおよびバックエンド・サービス・アプリケーション間の他のすべての相互作用および関係の詳細は無視されます。

図31-3 アイデンティティ伝播中のプロセス・フロー

「図31-3 アイデンティティ伝播中のプロセス・フロー」の説明

アクターとプロセスの概要: アイデンティティ伝播

1. IDアサーション・トークン・リクエスタ(エンド・ユーザー向けアプリケーション)は、エンド・ユーザーへのアクセス時に、アイデンティティ・プロバイダの認証およびIDアサーション・トークンをリクエストします。

注意:

IDアサーション・トークン・リクエスタの例には、OAMで保護されるWebアプリケーションがあります。IDアサーション・トークン・リクエストは、暗黙的な場合もあれば、IDプロバイダのポリシーから導かれる場合もあります。

2. IDプロバイダ(Security Token Service)はリクエストを処理し、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

3. IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

4. IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

詳細は、次のトピックを参照してください。

- コンポーネント処理: OAMトークンを使用したアイデンティティ伝播

- リクエスト・セキュリティ・トークンの属性と実行時の処理

- 構成要件: OAMトークンを使用したアイデンティティ伝播

31.3.1 コンポーネント処理: OAMトークンを使用したアイデンティティ伝播

図31-4に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の一般的なデプロイメント・トポロジを示します。

図31-4 アイデンティティ伝播のデプロイメント

「図31-4 アイデンティティ伝播のデプロイメント」の説明

図31-5に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の処理を示します。詳細は、図の後に説明します。

図31-5 アイデンティティ伝播処理

「図31-5 アイデンティティ伝播処理」の説明

プロセスの概要: アイデンティティ伝播のコンポーネント相互作用

1. ユーザーが保護されたリソースにアクセスを試みます。

2. Webgateはリソースを保護しており、認証および認可のためにAccess Managerにリクエストを送信します。

3. Access Managerでは、このWebgateアプリケーション・ドメイン用に構成されたポリシーを使用してユーザーが認証されます。レスポンス・タイプ「IDENTITY_ASSERTION」がこのWebgate用に構成されていることを確認し、IDアサーション・トークンも生成します。

4. Access ManagerはWebgateに認証およびIDアサーションを送信します。

5. Webgateでは、レスポンスを処理し、IDアサーション・トークンをヘッダー(WebgateがインストールされているOHS)に設定した後、リソースをホストするWLSにリクエストをリダイレクトします。

6. IAP (WebLogic Server上のAccess Manager Identity Asserter)では、OAM_IDENTITY_ASSERTIONヘッダーが設定されていることを確認し、ヘッダーを処理した後、IDアサーション・トークンをサブジェクトのプライベートな資格証明(OamIdentity)に設定します。

7. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザーのサブジェクトからIDアサーション・トークンを取得し、そのIDアサーション・トークンを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してSecurity Token Serviceに送信します。

8. Security Token ServiceではOBOトークン内のIDアサーション・トークンを確認し、Access Managerライブラリを使用してAccess Managerに検証/認証リクエストを送信します。

9. Access ManagerではIDアサーション・トークンを検証および認証した後、Security Token Serviceにレスポンス(ユーザー・アイデンティティ)を送信します。

10. Security Token Serviceではこのユーザー・アイデンティティを使用して、ポリシー評価、トークン発行などの処理がさらに行われます。その後、リクエスト・セキュリティ・トークン・レスポンスが生成されます。

11. Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

31.3.2 リクエスト・セキュリティ・トークンの属性と実行時の処理

次の属性を持つ着信リクエスト・セキュリティ・トークン(RST)の場合、リクエストを処理し、トークンを発行するようにSecurity Token Serviceを構成する必要があります。

OAMトークンを使用したアイデンティティ伝播のRST属性

- SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。

- SOAP本体にはWS-Trust RSTメッセージが含まれています。

- RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにOAM ID伝播トークンが含まれています。OnBehalfOf要素に含まれるトークンはBinarySecrityTokenで、テキスト値はOAMセッション伝播トークンのBase 64エンコード・フォーマット、ValueType属性はhttp://something.example.com/am/2012/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フィールドが含まれている可能性がありますが、このフィールドはSecurity Token Serviceでは無視されます。

プロセスの概要: OAMトークンを使用したアイデンティティ伝播

1. クライアントは次の方法でリクエストを準備します。

1. SOAPメッセージを作成します。

2. クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

3. WS-Trust RSTメッセージを作成します。

4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

5. SOAP本体にRSTメッセージを含めます。

2. クライアントはSecurity Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをSecurity Token Service WSS検証テンプレートにマップします。

3. Security Token Serviceでは着信リクエストが処理されます。

4. Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

1. ユーザー名トークンのフォーマットを検証します。

2. ユーザー名トークンに含まれる資格証明とSecurity Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

3. リクエスタ・パートナを確認した後、Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

5. Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。

1. OnBehalfOfフィールドに存在するトークンのタイプを判断します。

2. OAMトークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

3. OAMトークンのフォーマットおよびOAMトークンを検証し、トークンをユーザーにマップします。

4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

6. Security Token ServiceではAppliesToフィールドが検査されます。

- 存在する場合、Security Token Serviceはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、Security Token Serviceはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、Security Token Serviceはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

- 存在しない場合、Security Token Serviceはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

7. Security Token ServiceではTokenTypeフィールドが検査されます。

- 存在する場合、Security Token Serviceはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

- 存在しない場合、Security Token Serviceはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

8. Security Token Serviceでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

9. Security Token Serviceではトークンが作成されます。

- 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

- 発行されるトークンがSAMLタイプの場合、Security Token ServiceサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

10. Security Token Serviceでは、クライアントが処理するレスポンスが作成されます。

1. WS-Trust RSTRCを作成します。

2. 返されたトークンを追加します。

3. 必要に応じて証明鍵を追加します。

31.3.3 構成要件: OAMトークンを使用したアイデンティティ伝播

このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。

- 構成の概要: OAMトークンを使用したアイデンティティ伝播

- WebLogic Server Identity Assertion Provider

- Access Manager Identity Asserterの詳細

- LDAP認証プロバイダの詳細

- デフォルト・アイデンティティ・ストアの構成

- トークン発行ポリシー

- WebgateによるIDアサーションの認証ポリシー・レスポンス

- エンドポイントの構成

- 発行テンプレートの構成

- パートナ構成: リクエスタ

- パートナ・プロファイル: リライイング・パーティ

- パートナ・プロファイル: リクエスタ

- WS-TRUSTの検証テンプレート

- Cookieおよびヘッダー(切捨て)

- クライアントによって送信されるリクエスタ・セキュリティ・トークン(切捨て)

- Security Token Serviceによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)

構成の概要: OAMトークンを使用したアイデンティティ伝播

アイデンティティ伝播の環境と実装タスクの概要を次に示します。

- クライアントとして機能するカスタム・アプリケーション・モジュールでは、次の処理が行われます。

- HTTPリクエストからのOAMセッション伝播トークンの取得

- Security Token ServiceサーバーへのWS-Trustリクエストの送信(Access Managerセッション伝播トークンをOnBehalfOf要素として使用)

- Webgateで保護され、WS-TrustリクエストをSecurity Token Serviceに送信するクライアントWebアプリケーションを起動するWebアプリケーション

- セキュリティ・トークン・サービスURL: http://myhost.domain.com:14100/sts/<endpoint>

注意:

<endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

- Webアプリケーションを保護するWebgateを備えたOHS 11g
WebLogic Serverにデプロイされたアプリケーションを保護するために、Webgate (11gまたは10g)をプロビジョニング(登録)します。OAMSuiteアプリケーション・ドメインは事前に送信され、Access Manager 11gとともに配布されます。このアプリケーション・ドメイン(または別の既存のアプリケーション・ドメイン)を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。

OHSサーバーmod_wl_ohs.conf内のWebgateのリバース・プロキシ・マッピングを次に示します。

アイデンティティ伝播のトークン処理を実装するには、次のSecurity Token Service構成が必要です。

- 1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

- 1つの発行テンプレート

- 1つのWS-Trust検証テンプレート

- Security Token Serviceのエンドポイント

- ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Security Token ServiceにはLDAPサーバーが必要です。
目的のLDAPサーバーが、デフォルト・アイデンティティ・ストアとして構成されていることを確認します。

WebLogic Server Identity Assertion Provider

IDアサーション・プロバイダwarをデプロイします。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

図31-6に、このシナリオに必要なWebLogic Server Identity Assertion Providerを示します。

図31-6 必要なv1.0 WebLogic Server Identity Assertion Provider

「図31-6 必要なv1.0 WebLogic Server Identity Assertion Provider」の説明

Access Manager Identity Asserterの詳細

IAP-Security Token Serviceアイデンティティ・アサータを最初に設定してから、REQUIRED Controlフラグを使用して設定する必要があります。OAM_REMOTE_USER1のSSOヘッダー名を使用して、「Active Types」をObSSOCookieおよびOAM_REMOTE_USERとして設定する必要があります。

図31-7に構成を示します。

図31-7 IAP-Security Token Serviceの詳細

「図31-7 IAP-Security Token Serviceの詳細」の説明

LDAP認証プロバイダの詳細

OPTIONAL JAASフラグを使用してLDAPのオーセンティケータを作成します。これは、Access Managerトークンを提供するOracle Access Managementのデフォルト・システム・ストアを指します。

図31-8では、これを説明しています。

図31-8 LDAPプロバイダ: IAP-DSEE

「図31-8 LDAPプロバイダ: IAP-DSEE」の説明

デフォルト・アイデンティティ・ストアの構成

図31-9に、Oracle Access Managementコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。

図31-9 Access Managerに定義されているデフォルト・アイデンティティ・ストア

「図31-9 Access Managerに定義されているデフォルト・アイデンティティ・ストア」の説明

トークン発行ポリシー

図31-10に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

図31-10 アイデンティティ伝播のトークン発行ポリシー

「図31-10 アイデンティティ伝播のトークン発行ポリシー」の説明

WebgateによるIDアサーションの認証ポリシー・レスポンス

IDアサーションは、エンド・ユーザー(およびそのOAMセッション)を表すAccess Managerから発行されたトークンのID伝播で必要です。

IDアサーション・トークンは、正常に認証された後に生成され、ポリシー・レスポンス(名前が「OAM_IDENTITY_ASSERTION」で値がSAMLトークンというHTTPヘッダー)として返されます。

Access Managerによって保護されているWebアプリケーションであるSecurity Token Serviceクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。

IDプロバイダ(Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

関連項目:

「SSOのポリシー・レスポンスの概要」

IAM Suiteアプリケーション・ドメイン内の認証ポリシー・レスポンスの一部として「IDアサーション」ボックスが選択されていることを確認します。これにより、保護されているリソースに対してWebgateでIDアサーションを実行できるようになります。

各レスポンスを追加すると、次のように通知される場合があります: Identity Assertion has not been enabled for this policy. Enable Identity Assertion in order to collect Assertion Attribute type responses (when this policy is executed)

関連項目:

「SSOのポリシー・レスポンスの追加および管理」.

エンドポイントの構成

図31-11に示すように、/wss10userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。

図31-11 IDアサーションの/wssuserエンドポイント

「図31-11 IDアサーションの/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トークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

31.3.4 実装のテスト

構成の完了後、リソースにアクセスし、実装が正しく動作していることを確認できます。

Webgateでは、認証の成功時にユーザーの既存のセッションがない場合、OAM Serverにリダイレクトする必要があり、ユーザーはSTSサーバーによって送信されるRSTおよびRSTRを表示できることが必要です。

Cookieおよびヘッダー(切捨て)

クライアントによって送信されるリクエスト・セキュリティ・トークン(切捨て)

クライアントによって送信されるセキュリティ・トークンの(切り捨てられた)リクエストを次に示します。

セキュリティ・トークン・サービスによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)

セキュリティ・トークン・サービスによって送信されるRSTへの(切り捨てられた)レスポンスを次に示します。

31.4 シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

ここでは、次の内容について説明します。

- ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

- ユーザー名トークンを使用したアイデンティティ伝播のRST属性および処理

- 構成要件: ユーザー名トークンを使用したアイデンティティ伝播

31.4.1 ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

プロセスの概要: アイデンティティ伝播のコンポーネント相互作用

1. ユーザーが保護されたリソースにアクセスを試みます。

2. ユーザーが認証されます。

3. WebLogicコンテナでは、ユーザーのアイデンティティがこのセッションのサブジェクトに設定されます。

4. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザー・サブジェクトからユーザーのアイデンティティを取得し、そのアイデンティティを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してSecurity Token Serviceに送信します。

5. Security Token Serviceでは、Webサービス・クライアントをリクエスタ・パートナとして認証します。

6. Security Token ServiceではOBOトークン内にユーザー名トークンが表示され、ユーザーのアイデンティティがLDAP内のユーザー・レコードにマップされます。

7. その後、Security Token Serviceではリクエスト・セキュリティ・トークン・レスポンスが生成されます。

8. Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

31.4.2 ユーザー名トークンを使用したアイデンティティ伝播の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フィールドが含まれている可能性がありますが、このフィールドはSecurity Token Serviceでは無視されます。

プロセスの概要: OAMトークンを使用したアイデンティティ伝播

1. クライアントは次の方法でリクエストを準備します。

- SOAPメッセージを作成します。

- クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

- WS-Trust RSTメッセージを作成します。

- ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むユーザー名トークンを作成します。

- SOAP本体にRSTメッセージを含めます。

2. クライアントはSecurity Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをSecurity Token Service WSS検証テンプレートにマップします。

3. Security Token Serviceでは着信リクエストが処理されます。

4. Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

- ユーザー名トークンのフォーマットを検証します。

- ユーザー名トークンに含まれる資格証明とSecurity Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

- リクエスタ・パートナを確認した後、Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

5. Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。

- OnBehalfOfフィールドに存在するトークンのタイプを判断します。

- ユーザー名トークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

- ユーザー名トークンを検証し、トークンをユーザーにマップします。

6. Security Token ServiceではAppliesToフィールドが検査されます。

- 存在する場合、Security Token Serviceはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、Security Token Serviceはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、Security Token Serviceはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

- 存在しない場合、Security Token Serviceはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

7. Security Token ServiceではTokenTypeフィールドが検査されます。

- 存在する場合、Security Token Serviceはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

- 存在しない場合、Security Token Serviceはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

8. Security Token Serviceでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

9. Security Token Serviceではトークンが作成されます。

- 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

- 発行されるトークンがSAMLタイプの場合、Security Token ServiceサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

10. Security Token Serviceでは、クライアントが処理するレスポンスが作成されます。

- WS-Trust RSTRCを作成します。

- 返されたトークンを追加します。

- 必要に応じて証明鍵を追加します。

31.4.3 構成要件: ユーザー名トークンを使用したアイデンティティ伝播

このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。

- 構成の概要: ユーザー名トークンを使用したアイデンティティ伝播

- デフォルト・アイデンティティ・ストアの構成

- トークン発行ポリシー

- エンドポイントの構成

- 発行テンプレートの構成

- パートナ構成: リクエスタ

- パートナ・プロファイル: リライイング・パーティ

- パートナ・プロファイル: リクエスタ

- WS-TRUSTの検証テンプレート

- 例31-1「交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン」

- 例31-2「Security Token Serviceによって送信されるリクエスト・セキュリティ・トークン・レスポンス」

構成の概要: ユーザー名トークンを使用したアイデンティティ伝播

アイデンティティ伝播の環境と実装タスクの概要を次に示します。

- ユーザーがリクエストするWebアプリケーション。このWebアプリケーションはユーザーを認証した後、リモートWebサービス・プロバイダへのSOAPメッセージの送信を試行します。そのSOAP交換の一部として、WS-SecurityクライアントはWebサービス・プロバイダのWS-Securityポリシーをダウンロードし、Security Token Serviceに接続してWebサービス・プロバイダがリクエストしたトークンを取得し、Webサービス・プロバイダにSOAPメッセージを含むセキュリティ・トークンを送信します。

- セキュリティ・トークン・サービスURL: http://myhost.domain.com:14100/sts/<endpoint>

注意:

<endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

アイデンティティ伝播のトークン処理を実装するには、次のSecurity Token Service構成が必要です。

- 1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

- 1つの発行テンプレート

- 1つのWS-Trust検証テンプレート

- Security Token Serviceのエンドポイント

- ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Security Token ServiceにはLDAPサーバーが必要です。

- 目的のLDAPサーバーが、Access Managerのデフォルト・アイデンティティ・ストアとして構成されていることを確認します。

デフォルト・アイデンティティ・ストアの構成

図31-12に、Oracle Access Managementコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。

図31-12 Access Managerに定義されているデフォルト・アイデンティティ・ストア

「図31-12 Access Managerに定義されているデフォルト・アイデンティティ・ストア」の説明

トークン発行ポリシー

図31-13に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

図31-13 アイデンティティ伝播のトークン発行ポリシー

「図31-13 アイデンティティ伝播のトークン発行ポリシー」の説明

エンドポイントの構成

図31-14に示すように、/wss11userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。

図31-14 IDアサーションの/wss11userエンドポイント

「図31-14 IDアサーションの/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-Trust

- トークン・タイプ: ユーザー名

- タイムスタンプの存続期間: 600

- 資格証明検証の有効化: 選択解除

- トークン・マッピング:

- トークンの宛先ユーザーのマップ: 選択

- 簡易ユーザー・マッピングの有効化: 選択

- データストア属性: uid

これで、ユーザー名トークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

例31-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>

例31-2 セキュリティ・トークン・サービスによって送信されるリクエスト・セキュリティ・トークン・レスポンス

セキュリティ・トークン・サービスによって送信される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="myhost.uk.example.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@mycompany.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>

32 セキュリティ・トークン・サービスの設定値と設定の管理

この章では、セキュリティ・トークン・サービスのエンドポイントの保護に含まれるコンポーネントを管理する方法について説明します。この章は、次の項目で構成されています。

- 前提条件

- セキュリティ・トークン・サービス構成の概要

- セキュリティ・トークン・サービスの有効化および無効化

- Oracle Access Managementコンソールを使用したセキュリティ・トークン・サービスの設定の定義

- Oracle WSMエージェントのためのWSSポリシーの使用および管理

- WSSプロトコル通信のためのOWSMの構成

- セキュリティ・トークン・サービス・ポリシーの管理および移行

- セキュリティ・トークン・サービス・メッセージのロギングの概要

- セキュリティ・トークン・サービスの監査の概要

32.1 前提条件

この項では、この章のタスクの要件を明らかにします。

この章のタスクを開始する前に、次のトピックを確認してください。

- 「Oracle Access Managementセキュリティ・トークン・サービスの概要」

- 第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」

- 第5章「サーバー登録の管理」

32.2 セキュリティ・トークン・サービス構成の概要

セキュリティ・トークン・サービスは、Access Managerと共存するWebサービスです。セキュリティ・トークン・サービスは、いくつかのAccess Managerコンポーネントを起動して、セキュリティ・トークンを検証および発行します。通常、Webクライアントはユーザー名トークンやX.509トークンのようなセキュリティ・トークンを提供することで、セキュリティ・トークン・サービスを使用してSAMLなどのアウトバウンド・トークンを要求できます。

セキュリティ・トークン・サービスはOracle Access Managementコンソールと統合され、統一された一貫性のある管理機能を提供します。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。

セキュリティ・トークン・サービスは次を提供します。

- トークン:

- 検証トークン: 標準トークン(ユーザー名、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)およびカスタム・トークン

- 構成による発行および検証

- 複数の層およびドメインにまたがるアイデンティティ伝播による高度な監査

- 統合された共有プラットフォーム・サービスは、内部サービス(Access Manager SSO、Federation、Oracle Web Services Manager)および外部サービスと対話します。

ここでは、次の内容について説明します。

- インストール後の構成

- OAMサーバーとセキュリティ・トークン・サービスについて

- Security Token Serviceクライアントについて

- エージェントとセキュリティ・トークン・サービスについて

関連項目:

『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』

32.2.1 インストール後の構成

インストールおよびサーバーの起動後、OAMサーバー上のOracle Access Managementコンソールにアクセスできます。たとえば、OAMサーバーのURLがhttp://machine:14100/oamの場合、次のものにアクセスできます。

- Oracle Access Managementコンソール: http://machine:7001/oamconsole

- セキュリティ・トークン・サービス: http://machine:14100/sts/wss11user?wsdlにより、デフォルトで使用できる/sts/wss11userエンドポイントのWSDLを表示して、セキュリティ・トークン・サービスが使用できることを確認します。
デフォルトではセキュリティ・トークン・サービスは無効になっているため、すべてのランタイム機能およびWebサービス・エンドポイントも無効になっています。これらのエンドポイントにアクセスするには、最初にOracle Access Managementコンソールを使用してセキュリティ・トークン・サービスを有効にする必要があります。その後、エンドポイントにアクセスできるようになります。

インストール後の構成には次の概要に示すタスクが含まれており、詳細が記載されているこのマニュアル内の他の項を参照しています。

タスクの概要: セキュリティ・トークン・サービスの構成に必要なもの

1. サーバー側の構成: 次のタスクにOracle Access Managementコンソールを使用します。

1. サービス有効化: 「セキュリティ・トークン・サービスのサービスの有効化および無効化」

2. 設定の構成: 「「セキュリティ・トークン・サービスの設定」の管理」

3. エンドポイント登録: 「エンドポイントの管理」

4. トークン発行テンプレート構成: 「トークン発行テンプレートの管理」

5. トークン検証テンプレート構成: 「トークン検証テンプレートの管理」

6. パートナ・プロファイル作成: 「Token Serviceパートナ・プロファイルの管理」

7. パートナ構成: 「Token Serviceパートナの管理」

8. トークン発行ポリシーによる、特定のリライイング・パーティに対してセキュリティ・トークン・サービスを使用してトークンを発行するための認可ルールの定義: 「トークン発行ポリシー、条件およびルールの管理」

2. 次の項の説明に従って、Oracle WSMエージェントとの相互作用を設定します。

1. Oracle WSMエージェントのためのWSSポリシーの使用および管理

2. WSSプロトコル通信のためのOWSMの構成

3. 「セキュリティ・トークン・サービス・メッセージのロギングの概要」の説明に従って、メッセージ・ロギングを設定します。

4. 「Oracle Access Managementの監査の設定」の説明に従って、イベント監査を構成します。

5. ライフサイクル管理の構成

1. 項目1cの説明に従って、セキュリティ・トークン・サービスのトラスト・エンドポイントを登録します。

2. 「Token Serviceパートナの管理」の説明に従って、リクエスタまたはリライイング・パーティ・パートナをセキュリティ・トークン・サービスに登録します。

3. 第10章「Fusion Middleware Controlを使用したパフォーマンスおよびログの監視」の説明に従って、パフォーマンスを監視します。

32.2.2 OAMサーバーとセキュリティ・トークン・サービスについて

Oracle Access Managementでは、すべてのセキュリティ・トークン・サービス・インスタンスはOAMサーバー(管理対象サーバーとも呼ばれる)上にインストールされます。各サーバーをAccess Managerに登録する必要があります。

セキュリティ・トークン・サービスでは、共有サービスの共通インフラストラクチャおよびOracle Access Management管理モデルが利用されます。

セキュリティ・トークン・サービスではWeb Services Securityプロトコル1.0および1.1がサポートされており、次のトークン(Security SOAPヘッダーに存在する場合)が処理されます。

- ユーザー名トークン(UNT)

- SAML 1.1またはSAML 2.0アサーション

- Kerberos

- X.509

注意:

第5章「サーバー登録の管理」の説明に従って、セキュリティ・トークン・サービスをホストする管理対象サーバーを、Access Managerに登録する必要があります。

サード・パーティのサーバー: セキュリティ・トークン・サービスは、サード・パーティのセキュリティ・トークン・サーバーと相互運用できます。たとえば、サード・パーティのセキュリティ・トークン・サービスでは、オラクル社のセキュリティ・トークン・サービスで使用できる有効なSecurity Assertion Markup Language (SAML)アサーションを作成できます。

32.2.3セキュリティ・トークン・サービス・クライアントについて

セキュリティ・トークン・サービスは、様々な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クライアントとサーバーの間でセキュアなキー交換が必要です。単に、Security Token Service証明書をクライアントにインポートします。

SOAPの相互作用中に、WS-Securityプロトコルでは、セキュリティ・トークン・サービス・エンドポイントを保護するOWSMエージェントによるWSS操作に使用される署名/暗号化証明書を信頼することをクライアントに要求する場合があります。その場合、Oracle Access Management管理者はWSS操作に使用されるセキュリティ・トークン・サービスOWSM署名/暗号化証明書を抽出し、WSクライアントに提供する必要があります。詳細は、「Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出」を参照してください。

32.2.4 エージェントとセキュリティ・トークン・サービスについて

Oracle Web Services Managerはエージェントを介して通信します。このトピックでは、セキュリティ・トークン・サービスを操作するエージェントについて説明します。

Oracle WSMエージェント: Oracle Web Services Manager (Oracle WSM)エージェントはセキュリティ・トークン・サービスと統合されます。このエージェントは、セキュリティ・トークン・サービスWebサービス・エンドポイントに対してWebサービス・セキュリティ・サポートを提供します。

- セキュリティ・トークン・サービスのWebサービス・エンドポイントの保護

- SOAPメッセージをリライイング・パーティに送信するためのWS-Securityサポートの提供。そのプロセスの一部として、OWSMクライアントはセキュリティ・トークン・サービスとの相互作用により、リライイング・パーティに表示されるセキュリティ・トークンを取得します。

- トークン取得およびトークン検証のためのセキュリティ・トークン・サービスとの相互作用

セキュリティ・トークン・サービスでは、Oracle Web Services Manager (Oracle WSM)エージェントによるトークン取得およびトークン検証がサポートされています。Oracle Web Services Managerエージェントでは、インバウンドまたはアウトバウンド・セキュリティ・ポリシー施行の一部としてセキュリティ・トークン・サービスを使用する必要はありません。Oracle Web Services Managerクライアント・バインディングは、Oracle Web Services Manager管理者の担当です。

Oracle WSMエージェントは、セキュリティ・トークン・サービスとクライアントの間のSOAP通信チャネルのメッセージを保護するために、セキュリティ・トークン・サービスで使用されます。Oracle WSMエージェントでは、WSSクライアントの証明書を検証するときに、関連する信頼できる証明書を含むOPSSキーストア(デフォルトでは$DOMAIN_HOME/config/fmwconfigディレクトリにあるdefault-keystore.jksキーストア)がキャッシュされます。その後、キーストアの内容またはキーストア名を変更する場合は、Oracle Enterprise Manager Fusion Middleware Control、WebLogic ServerコンソールまたはNodeManagerを使用して管理対象サーバーを再起動する必要があります。

セキュリティ・トークン・サービスで使用できるOracle WSMエージェントは、次のタスクを実行するために、セキュリティ・トークン・サービス・エンドポイントを保護するように構成する必要があります。

- リクエストの復号化(必要な場合)

- リクエストに表示されるデジタル証明書の検証

- リクエストのデジタル署名を作成するために使用される証明書の検証(署名が秘密鍵で作成された場合)

- SOAPヘッダー内のX.509トークンの検証(存在する場合)

- SOAPヘッダー内のKerberosトークンの検証(存在する場合)

- 送信レスポンスの署名(必要な場合)

- 送信レスポンスの暗号化(必要な場合)

Oracle WSMエージェント・キーストア: Oracle WSMエージェントでは、様々な暗号化操作にキーストアが使用されます。これらの操作では、Oracle WSMエージェントはOracle WSMタスク用に構成されたキーストアを使用します。

Webgate: セキュリティ・トークン・サービスでは、Access Managerセッション伝播トークンにWebgateが使用されます。このアイデンティティ伝播のユースケースは、より高度なものです。WebLogic Serverおよび一部のカスタム統合でIDアサーション・プロバイダを必要とします。

関連項目:

- 第31章「セキュリティ・トークン・サービスの実装シナリオ」

- 第31章「セキュリティ・トークン・サービスの実装シナリオ」

- 「Oracle Web Services Managerのキーストア(default-keystore.jks)について」

32.2.5 セキュリティ・トークン・サービス・エンドポイントとポリシーについて

エンドポイントを追加すると、セキュリティ・トークン・サービス・エンドポイントと関連付けるポリシーURIおよび検証テンプレートのリストから選択できるようになります。デフォルトでは、セキュリティ・トークン・サービスは図32-1に示すエンドポイントで構成されています。

図32-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート

「図32-1 デフォルト・エンドポイント、ポリシーおよび検証テンプレート」の説明

ORAPROVIDERはOracle WSMエージェントと統合されており、クライアントとセキュリティ・トークン・サービスの間で交換されているSOAPメッセージ上でWebサービス・セキュリティをサポートします。セキュリティ・トークン・サービスはWebサービスのORAPROVIDERを利用して、次の処理を行います。

- Web Servicesエンドポイントの動的な公開

- SOAPメッセージを処理するためのセキュリティ・トークン・サービスの起動

- 各WSエンドポイントのWSDLファイルの公開

Oracle WSMエージェントWSSポリシー・ストア: Oracle WSMエージェントでは、リポジトリで必要なWebサービス・セキュリティ(WSS)ポリシーを取得する必要があります。セキュリティ・トークン・サービスでは2つのタイプのリポジトリがサポートされています。

- WSSポリシーを含むJARファイル: WLSドメインがクラスパス用に構成されている場合に使用されます。

- Oracle WSM Policy Manager: SOAデプロイメントから使用できます。

関連項目:

- 「WSSプロトコル通信のためのOWSMの構成」

- セキュリティ・トークン・サービスのためのOracle Workspace Studioポリシーの管理

- 『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』: セキュリティ・トークン・サービスのポリシーの詳細

ポリシー・アサーション: 即時利用可能です。セキュリティ・トークン・サービスでは、Oracle Workspace Studio: SOAPメッセージ・セキュリティおよびWS-Trustのコンテキストでメッセージを保護する方法を示すために、WS-Policyフレームワークで使用するセキュリティ・ポリシー・アサーションのセットを提供しています。

- セキュリティ・トークン・サービスでは、セキュリティ・ポリシー・ファイルをデプロイ済のWSDLにアタッチすることで、関連するセキュリティ・ポリシー・ファイルをパブリックに使用できるようになります。

- セキュリティ・トークン・サービス・ランタイムでは、WS-Security暗号化およびデジタル署名操作のためにjps-config.xmlで定義されているキーストアに格納された秘密鍵とX.509証明書のペアが使用されます。

次の段落および表では、セキュリティ・トークン・サービスおよびOracle WSMエージェントで即時に利用できるポリシーを示します。

メッセージ・レベルのセキュリティが不要: メッセージ・レベルのセキュリティが不要な場合は、名前にmessage_protectionが指定されていないセキュリティ・トークン・サービス・ポリシーを使用します。これは、WS-Security SOAPヘッダーのトークンに含まれる資格証明を使用してユーザーを認証します。Fusion Applicationsトークンに含まれる資格証明は、検証テンプレートに指定されているルールに基づいてマップされます。プレーン・テキストとダイジェスト・メカニズムの両方がサポートされています。

メッセージ・レベルのセキュリティが不要な場合のトランスポート・セキュリティ: クライアント・アプリケーションとWebLogicサーバーの両方が相互に資格証明を提示する双方向のSSLを構成できます。コアWebLogic Serverセキュリティの双方向または一方向のSSLを構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。表32-1に説明されているポリシーを使用します。

WS-Security 1.0および1.1ポリシーの相互運用性: WS-Security 1.0または1.1(認証要件および資格証明の可用性により異なる)との相互運用性が必要な場合は、図32-2のポリシーを使用します。強力なセキュリティ要件がある場合は、WS-Security 1.1ポリシーを使用します。

図32-2 WS-Security 1.0および1.1ポリシー

「図32-2 WS-Security 1.0および1.1ポリシー」の説明

関連項目:

「Oracle WSMエージェントのためのWSSポリシーの使用および管理」

タスクの概要: WS-Sポリシーの使用および変更

1. 「Oracle Access Managementコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. 「エンドポイント」ノードから、「セキュリティ・トークン・サービス・エンドポイントの管理」の説明に従って、保護されるエンドポイントを検索または作成します。

3. 「ポリシーURI」リストから、次の説明に従って、エンドポイントを保護するための特定のWS Securityポリシーを選択します。

- Security Token ServiceのためのWSSポリシーの管理: クラスパス

- セキュリティ・トークン・サービスのためのWSSポリシーの管理: Oracle WSM Policy Manager

32.3 セキュリティ・トークン・サービスの有効化および無効化

このトピックの内容は次のとおりです。

- セキュリティ・トークン・サービスとOracle Access Managementコンソールについて

- セキュリティ・トークン・サービスのサービスの有効化について

- セキュリティ・トークン・サービスのサービスの有効化および無効化

32.3.1 セキュリティ・トークン・サービスとOracle Access Managementコンソールについて

Oracle Access Managementコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。

Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。これには、このマニュアルの第II部で説明する次の一般的なタスクが含まれています。

- 共通のOAMサーバーとプロキシ情報の登録および管理

- 共通のデフォルト・ユーザー・アイデンティティ・ストアの登録および管理

- WSS処理に使用されるOWSMキーストアとは異なるOAMキーストアの構成

- 証明書の検証と失効

Oracle Access Managementコンソールを使用すると、管理者は次のセキュリティ・トークン・サービス固有のタスクを実行できます。

- 検証トークン・テンプレートの管理: 検証テンプレートには、Webサービス・セキュリティ/WSTrustトークンを検証し、デフォルト・ユーザー・アイデンティティ・ストア内のリクエスタ・パートナまたはユーザー・レコードにマップするための構成プロパティが含まれています。

- 発行テンプレートの管理: 発行テンプレートには、トークンの作成方法に関するルールが含まれています。

- パートナ・データの管理: パートナは、セキュリティ・トークン・サービスが信頼しているパートナを表します。セキュリティ・トークン・サービスは、リクエスタ、リライイング・パーティおよび発行局の3つのタイプのパートナを定義します。各パートナ・エントリは、パートナ・プロファイルに関連付けられます。パートナ・エントリには、パートナを一意に識別するための署名証明書および暗号化証明書と識別子が含まれています。

- パートナ・プロファイルの管理: パートナ・プロファイルには、パートナのセットに共通の構成プロパティが含まれています。

- 要求マッピング

- トークン・タイプの定義

- トークン・タイプに対して定義される発行および検証テンプレート

- 発行局(その他のSTS)の検証テンプレート・ルールの上書き

- セキュリティ・トークン・サービス・エンドポイントの管理

- トークン発行ポリシーの管理(リクエスタ・パートナがリクエストで参照されるリライイング・パーティに基づいてトークンをリクエストできるかどうかを判断するために評価される認可ポリシー)

- セキュリティ・トークン・サービスのグローバル設定

- カスタム・トークン

32.3.1.1 セキュリティ・トークン・サービス管理者について

Oracle Access Managementコンソールへの管理アクセス権を持つユーザーには、Security Token Servicesへのアクセス権があります。

最初は管理者ユーザーは、初回構成時に設定されたWebLogic管理者の資格証明を使用してOracle Access Managementコンソールにログインする必要があります。ただし、企業によっては、Access Managerを担当するユーザーとセキュリティ・トークン・サービスを担当するユーザーに別の管理者グループが必要になることがあります。

32.3.1.2 セキュリティ・トークン・サービスへのログインおよびサインアウトについて

Security Token ServiceをAccess Managerとともに使用する場合、Access Managementコンソールへのログインとサインアウトは同じです。

関連項目:

次のトピックについては、第2章を参照してください。

- Oracle Access Managementコンソールへのログイン

- Oracle Access Managementコンソールからのサインアウト

32.3.2 セキュリティ・トークン・サービスのサービスの有効化について

Security Token Serviceを使用するには、図32-3に示すように、Security Token ServiceとAccess Managerの両方を有効にする必要があります。デフォルトでは、Security Token Serviceは無効になっているため、有効にする必要があります。

図32-3「使用可能なサービス」パネル

「図32-3「使用可能なサービス」パネル」の説明

サービス名の横にある「ステータス」フィールドの緑のチェック・マークは、サービスが有効であることを示します。中に線がある赤の円は、該当するサービスが無効であることを示します。

32.3.3 セキュリティ・トークン・サービスのサービスの有効化および無効化

前提条件

Oracle Access Managerサービスを有効にする必要があります。

セキュリティ・トークン・サービスを有効または無効にするには

1. 通常どおり、Oracle Access Managementコンソールにログインします。

https://hostname:port/oamconsole/

2. 「システム構成」タブの「共通構成」セクションから「使用可能なサービス」をクリックします。

3. セキュリティ・トークン・サービスの有効化: セキュリティ・トークン・サービスの横で、「有効」をクリック(または「ステータス」チェック・マークが緑になっていることを確認)し、Access Manager Serviceも有効になっていることを確認します。

4. セキュリティ・トークン・サービスの無効化: セキュリティ・トークン・サービスの横で、「無効」をクリック(または「ステータス」チェック・マークが赤になっていることを確認)します。

32.4 Oracle Access Managementコンソールを使用したセキュリティ・トークン・サービスの設定の定義

この項の内容は次のとおりです。

- 「セキュリティ・トークン・サービスの設定」について

- 「セキュリティ・トークン・サービスの設定」の管理

32.4.1 「セキュリティ・トークン・サービスの設定」について

「セキュリティ・トークン・サービス」は、「システム構成」タブの「セキュリティ・トークン・サービス」セクションから表示または変更できます。これらの設定を図32-4に示します。

図32-4 「セキュリティ・トークン・サービス」ページ

「図32-4 「セキュリティ・トークン・サービス」ページ」の説明

表32-1に、「セキュリティ・トークン・サービスの設定」ページの要素を示します。

表32-1 セキュリティ・トークン・サービスの設定

要素

説明

パートナ識別属性

「パートナ」ページの「アイデンティティ属性」表で使用できる必要がある、デフォルトで使用可能な属性以外の属性をリストするフィールド。これらの属性を使用すると、属性の値を着信リクエストに含まれる値と照合することでパートナを識別できます。

リクエスタがセキュリティ・トークン・サービスにWS-Trustリクエストを送信すると、サーバーはリクエスタのアイデンティティを含む着信トークンを、セキュリティ・トークン・サービス・パートナ・ストアのパートナ・エントリにマップできます。

そのために、セキュリティ・トークン・サービスでは検証テンプレートで構成されているマッピング設定を使用し、トークン・データをパートナ・アイデンティティ属性と照合することで参照を実行して、トークン・データをパートナ・エントリにマップします。

デフォルトでは、各リクエスタ・パートナには、ユーザー名、HTTP Basicユーザー名、SSLクライアント証明書DNの3つのアイデンティティ属性が含まれています。

リクエスタ・パートナ・エントリごとに設定できる追加のアイデンティティ属性を定義できます。

このセクションでは、新しい属性を設定できます。新しい属性を定義すると、その属性は「リクエスタ・パートナ」エントリ・セクションで使用可能になり、WSS検証テンプレートのマッピング・ルールで使用できます。

カスタム信頼アンカー・ファイル

デフォルトでは、Access ManagerおよびSecurity Token Serviceでは、X.509トークンの検証時またはSAMLアサーション署名で使用される証明書の検証時に、Security Token Serviceによる証明書検証に使用される信頼アンカーを含むデフォルトの$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアが使用されます。

必要に応じて、セキュリティ・トークン・サービスの操作および検証にのみ使用される信頼アンカーを含む特定の信頼アンカー・ファイルを使用するように、セキュリティ・トークン・サービスを構成できます。この場合、このフィールドには使用するJKSキーストアの場所を指定する必要があります。

次の点に注意してください。

- カスタム信頼アンカー・キーストアを使用する場合、クラスタ全体に自動的に複製されることはありません。複製を管理する必要があります。

- ほとんどの場合、デフォルトのAccess ManagerおよびSecurity Token Service信頼アンカーで十分です。

関連項目: 第33章「Security Token Serviceの証明書と鍵の管理」

デフォルト暗号化テンプレート

セキュリティ・トークン・サービス暗号化用のデフォルト・テンプレートを選択できるリストを次に示します。

- osts_encryption

- osts_signing

関連項目: 「デフォルトの暗号化鍵の設定」

プロキシ

アウトバウンド接続のプロパティ、HTTPプロキシ設定: このセクションを使用して、オプションで実行時にリライイング・パーティのWS-Secポリシーを取得する場合、送信HTTP接続にプロキシを使用するようにセキュリティ・トークン・サービスを構成します。

- 有効: このボックスが選択されている場合、プロキシ機能が有効になっており、リライイング・パーティのWS-Securityポリシーを取得するときに使用されます。このボックスが選択されていない場合、プロキシ機能は無効になっており、関連するフィールドにアクセスして編集することはできません。

- ホスト: プロキシ・ホスト名。

- ポート: プロキシ・ポート番号。デフォルトは8080です。

- 非プロキシ・ホスト: プロキシを使用しないホストのリスト。複数のホストを区切るには、「;」を使用します。

- ユーザー名: プロキシに接続するときに使用するユーザー名。

- パスワード: プロキシに接続するときに使用するパスワード。

キーストア

ロケーション: セキュリティ・トークン・サービスのインストール時に設定されたアクティブなキーストアのパス。

キーストア表には、表内のテンプレートごとに次の情報が含まれており、各テンプレートは、デフォルト暗号化テンプレートとして使用できます。

- テンプレートID: キーストアにアクセスできるテンプレートの名前。

- 別名: テンプレートの別名を識別します。テンプレートを追加するときに、リストされている別名から選択できます。次に例を示します。

- パスワード: 選択した別名のパスワード。

- 説明: オプション。

キーストア・セクションでは、Security Token Serviceキーストア($DOMAIN_HOME/config/fmwconfig/.oamkeystore)にあるキー・エントリが定義されます。

エントリが定義されると、そのエントリを(SAML発行テンプレートのように)他のSecurity Token Serviceテンプレートで使用できます。

32.4.2 「セキュリティ・トークン・サービスの設定」の管理

有効な管理者の資格証明を持つユーザーは、この手順を使用して、「セキュリティ・トークン・サービスの設定」を確認または変更できます。

前提条件

Access Managerサービスとセキュリティ・トークン・サービスの両方が有効になっている必要があります。

「セキュリティ・トークン・サービスの設定」を表示または編集する手順

1. 通常どおり、Oracle Access Managementコンソールにログインします。

https://hostname:port/oamconsole/

2. 「システム構成」タブから「セキュリティ・トークン・サービス」セクションを開きます。

3. 「セキュリティ・トークン・サービスの設定」をダブルクリックします。

4. 「セキュリティ・トークン・サービスの設定」ページで、次の情報を表示(または変更)します(表32-1を参照)。

- パートナ識別属性

- カスタム信頼アンカー・ファイル

- 「プロキシ」の詳細

5. キーストア表: 新しい暗号化テンプレートを表示、追加または削除します。

6. 「適用」をクリックし、変更を送信します(または、「元に戻す」をクリックして変更を取り消します)。

7. 終了したらページを閉じます。

32.5 Oracle WSMエージェントのためのWSSポリシーの使用および管理

既存のOracle Workspace Studioポリシーを使用して、セキュリティ・トークン・サービスWebサービス・エンドポイントを保護できます。次に例を示します。

- クラスパス・モード: このモードでは、$ORACLE_IDM_HOME/oam/server/policy/sts-policies.jarに定義されている既存のOracle Workspace Studioポリシーが使用されます。

- SOAデプロイメント: SOAデプロイメントから使用できる、Oracle WSM Policy Managerに定義されているポリシーが使用されます。

この項では、次の各トピックでSecurity Token ServiceのWebサービス・セキュリティ・ポリシーを管理する方法を説明します。

- Oracle Workspace Studioポリシーの使用方法と変更方法

- Security Token ServiceのためのWSSポリシーの管理: クラスパス

- セキュリティ・トークン・サービスのためのWSSポリシーの管理: Oracle WSM Policy Manager

32.5.1 Oracle Workspace Studioポリシーの使用方法と変更方法

この項では、Security Token Service WSエンドポイントの保護に使用されるWS-Securityポリシーおよびこれらのポリシーの変更方法を説明します。Oracleが提供するWS-Securityポリシーは、ほとんどのユースケースに対応している必要があります。

関連項目:

- 「セキュリティ・トークン・サービス・エンドポイントとポリシーについて」

- 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のWebサービスへのポリシーのアタッチに関する項

32.5.2 セキュリティ・トークン・サービスのためのWSSポリシーの管理: クラスパス

事前定義済のOracle Web Services Managerポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して構成します。WSSポリシーのクラスパス・モードの場合、OWSMエージェントはクラスパスにあるsts-policies.jarからポリシーを取得します。

SOAがWebLogic Serverドメインにデプロイされていない場合、セキュリティ・トークン・サービス・インストーラではWSSポリシーのクラスパス・モード用にWebLogic Serverドメインが構成されます。WLSドメインがクラスパス用に構成されるときに使用されるWSSポリシーを含むJARファイルは、次の場所にあります。

$IDM_ORACLE_HOME/oam/server/policy/sts-policies.jar

ご使用の環境がクラスパス・モードの場合は、管理者が次のタスクを実行してsts-policies.jarがクラスパスにあることを確認します。

関連項目:

- 「セキュリティ・トークン・サービス・エンドポイントとポリシーについて」

- 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』の事前定義済のOracle WSMポリシーとアサーション・テンプレートに関する項

タスクの概要: セキュリティ・トークン・サービスのための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. セキュリティ・トークン・サービスを実行している管理対象サーバーを再起動します。

6. Oracle Access Managementコンソールに移動し、セキュリティ・トークン・サービス・エンドポイントを構成します。

32.5.3 セキュリティ・トークン・サービスのための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部、「高度な管理」

タスクの概要: セキュリティ・トークン・サービスのためのWSSポリシーの管理: OWSM Policy Manager

1. OWSM Policy Managerから、目的のポリシーを探して開きます。

2. 『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』を参照して、必要に応じてポリシーを変更します。

3. セキュリティ・トークン・サービスを実行しているすべての管理対象サーバーを再起動します。

4. 「WSSプロトコル通信のためのOWSMの構成」に進みます。

32.6 WSSプロトコル通信のためのOWSMの構成

この項では、セキュリティ・トークン・サービスに組み込まれているWS-SecクライアントとOracle WSMエージェントの間の通信を構成する方法を説明します。

Oracle WSMエージェントはセキュリティ・トークン・サービスのWebサービス・エンドポイントを保護し、WSSプロトコル交換をサポートします。クライアントがOracle WSMエージェントと正常に通信するためには、次のことが必要です。

- クライアントは、Oracle WSMエージェントで使用される署名証明書および暗号化証明書を認識する必要があります(そのためには、セキュリティ・トークン・サービスに組み込まれているOWSMエージェントで使用される署名証明書および暗号化証明書を抽出して配布する必要があります)。

- Oracle WSMエージェントは、ポリシーに応じてクライアントで使用される署名証明書を認識する必要があります(そのためには、Oracle WSMエージェントの信頼できる証明書としてクライアントの証明書を追加する必要があります)。

タスクの概要: Oracle WSMエージェントとの通信の構成

1. 「セキュリティ・トークン・サービスのOracle WSMエージェントのWS-Securityポリシーについて」を参照

2. Oracle WSMキーストア・パスワードの取得

3. Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出

4. Oracle WSMキーストアへの信頼できる証明書の追加

5. Oracle WSMキーストア内の信頼できる証明書の検証

6. WSS KerberosポリシーのためのOracle WSMエージェントの構成

関連項目:

第33章「Security Token Serviceの証明書と鍵の管理」

32.6.1 セキュリティ・トークン・サービスのOracle WSMエージェントのWS-Securityポリシーについて

Oracle WSMエージェントでは、リポジトリで必要なWeb Services Security (WSS)ポリシーを取得する必要があります。Access Managerでは、セキュリティ・トークン・サービスのために次の2つのタイプのリポジトリがサポートされています。

- WSSポリシーを含むJARファイル: WLSドメインがクラスパス用に構成されている場合に使用されます。必要なJARファイルは$IDM_ORACLE_HOME/oam/server/policy/ sts-policies.jarにあります。

- SOAデプロイメントから使用できるOracle WSM Policy Manager

セキュリティ・トークン・サービスのインストール時に、インストーラにより、Oracle Web Services Manager Policy Managerが存在し、WebLogicセキュリティ・ドメインにデプロイされているかどうかが検出されます。

- WebLogicセキュリティ・ドメインにデプロイされていない場合、インストーラでは、Webサービス・セキュリティ・ポリシー・クラスパス・モード用にWebLogicセキュリティ・ドメインが構成されます。このモードでは、WSMエージェントによりJARファイルからポリシーが取得されます。

- 存在する場合、インストーラはOracle Web Services Manager Policy Managerに接続し、セキュリティ・トークン・サービス・エンドポイントの保護に使用されるポリシーをアップロードします。

関連項目:

Access Managerポリシー・データおよびAccess Managerセッション・データ(オプション)に必要なデータベースの詳細は、「ポリシー、パスワード管理およびセッションのデータベース・ストアについて」を参照してください。

32.6.2 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署名証明書および暗号化証明書の抽出」に進みます。

32.6.3 Oracle STS/Oracle WSM署名証明書および暗号化証明書の抽出

SOAPの相互作用中に、WS-Securityプロトコルでは、セキュリティ・トークン・サービス・エンドポイントを保護するOWSMエージェントによるWSS操作に使用される署名/暗号化証明書を信頼することをクライアントに要求する場合があります。その場合、Oracle Access Management管理者はWSS操作に使用されるセキュリティ・トークン・サービスOWSM署名/暗号化証明書を抽出し、WSクライアントに提供する必要があります。

管理者は、WSS暗号操作のためにセキュリティ・トークン・サービスで使用される署名証明書および暗号化証明書をエクスポートする必要があります。次の手順は、この操作の実行方法を示しています。

- $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キーストアへの信頼できる証明書の追加」に進みます。

32.6.4 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キーストア内の信頼できる証明書の検証」に進みます。

32.6.5 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キーストアには、署名証明書または署名証明書の発行者の証明書を含める必要があります。

関連項目:

第33章「Security Token Serviceの証明書と鍵の管理」

32.6.6 WSS KerberosポリシーのためのOracle WSMエージェントの構成

セキュリティ・トークン・サービスは、様々なOracleクライアント(Oracle Web Services Managerクライアント)またはサード・パーティ・クライアント(MicrosoftおよびIBM)にサービスを提供します。Oracle WSMエージェントは、着信リクエストに対してメッセージ保護のみを実行します(認証は実行しません)。Oracle WSMエージェントでは、OPSSアイデンティティ・ストア内のユーザー・レコードへの着信Kerberosチケットのマップは試行されません。

Oracle WSMがWSS Kerberosポリシーを使用してセキュリティ・トークン・サービスとやり取りするクライアントの場合、『Oracle Fusion Middleware Web Servicesのためのセキュリティおよび管理者ガイド』のOracle WSM Kerberos全体の設定に関する項が適用されます。

ただし、クライアントがOracle WSMではない場合は表32-2を参照し、クライアントの構成方法に関する項、およびKerberosチケットで参照されるユーザーの認証に関する項は無視してください。

表32-2 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サービスの設定

32.7 セキュリティ・トークン・サービス・ポリシーの管理および移行

ここでは、次の内容について説明します。

- セキュリティ・トークン・サービス・ポリシーの管理および移行について

- セキュリティ・トークン・サービス・ポリシーの管理

- セキュリティ・トークン・サービス・ポリシーの移行

32.7.1 セキュリティ・トークン・サービス・ポリシーの管理および移行について

セキュリティ・トークン・サービスでは、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を更新してください。

32.7.2 セキュリティ・トークン・サービス・ポリシーの管理

次の手順は、ポリシー更新の様々なシナリオを示しています。

タスクの概要: ポリシーおよび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. 既存のポリシー内容の更新: ファイル名を変更せずにポリシー・ファイルの内容を更新する場合、その他の処理を実行する必要はありません。

32.7.3 セキュリティ・トークン・サービス・ポリシーの移行

インストール時に、セキュリティ・トークン・サービスがインストールされるドメイン内にSOAがデプロイされているかどうかを確認するために、チェックが行われます。

- SOAがインストールされていない場合、Oracle WSMプロトコルはクラスパスに設定され、クラスパス上のJARからポリシーが読み込まれます。

関連項目:

「Oracle WSMエージェントのためのWSSポリシーの使用および管理」

- SOAがドメイン内に存在する場合、Security Token Serviceはsts-policies.jarからポリシーを読み取り、Oracle WSM MbeansをコールすることでOracle WSM PMリポジトリに移行します。

- セキュリティ・トークン・サービスの後、同じドメイン内にSOAがインストールされる場合、次のようにSOAとセキュリティ・トークン・サービスの間のスムーズな操作が保証されます。

- Oracle WSMプロトコルを「remote」に設定する必要があります。

- Oracle WSMが提供するツールを使用して、セキュリティ・トークン・サービス・ポリシーをsts-policies jarからOracle WSM PMリポジトリに移行する必要があります。

32.8 セキュリティ・トークン・サービス・メッセージのロギングの概要

ロギングは、コンポーネントがファイルにメッセージを書き込むためのメカニズムです。管理者は、ロギング・メカニズムを使用して重要なコンポーネント・イベントを取得できます。Access Managerは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとガイドラインを使用しています。これはjava.util.loggingパッケージを使用して行いますが、このパッケージは標準的なもので、すべてのJava環境で使用できます。ロギング・システムはフラット・ファイルにのみ出力を書き出します。Oracle Databaseインスタンスへのロギングはサポートされていません。

ロギングの構成とログ・ファイルの検索がこの項の焦点です。ログ・ファイルの情報を使用した問題診断については、このマニュアルでは取り上げません。

ログ・メッセージは問題の診断に使用されます。ロギング・インフラストラクチャは、Access Managerからのメッセージを記録します。管理者は、ロガーの定義対象となる各コンポーネントに対してログ・レベルを指定することにより、メッセージ内の記録情報量を制御します。

注意:

一般に、ユーザーは、問題診断のためにOracleテクニカル・サポートへ送るファイルを作成するためにロギングを有効にします。ログ・メッセージに関するドキュメントはありません。場合によっては、ログ・ファイルを参照することによってユーザー自身で問題を診断できることもあります。

デフォルトでは、Access Managerのログ・レベルが通知レベルになっています。「エラー」レベルでのロギングで生成される出力は少量ですが、他のログ・レベルではロギング出力が大量になることがあり、その場合はOAMのパフォーマンスに影響します。本番環境では、通常はロギングを無効にするか、ロギング出力量が少くなるようなレベル(たとえばエラー・レベル)に設定します。

Access Managerおよびセキュリティ・トークン・サービスは、次のWebLogicコンテナのロギング・デフォルトを使用します。

- ロギング・ファイル: DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

- ロギング構成ファイル: ロギング・レベルと、ロギングのためのその他の構成情報を提供します。このファイルは次のパスに保存されます: DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

32.9 セキュリティ・トークン・サービスの監査の概要

Oracle Fusion Middlewareにおいて、監査はアカウンタビリティを実現する手段であり、また、誰が、いつ、何を行ったかというタイプの質問への回答を提供します。監査データは、ダッシュボードの作成、履歴データの集計、およびリスクの評価に使用できます。記録された監査データを分析すれば、コンプライアンス担当者がコンプライアンス方針を定期的に確認できます。

この項では、監査可能なセキュリティ・トークン・サービス管理イベントとランタイム・イベントを説明します。セキュリティ・トークン・サービスの共通監査設定を構成することと、設定した監査構成の検証がこの章の主題です。ただし、監査データの分析と監査についてはこのマニュアルでは取り上げません。

Oracle Fusion Middlewareの共通監査フレームワークは、大量のランタイム・イベントと管理イベント(システムへの変更)の監査をサポートします。Oracle Fusion Middlewareの共通監査フレームワークを使用すれば、ロギングと例外を一様な形で取り扱い、すべての監査イベントの診断を行うことができます。

監査機能は有効または無効のどちらに設定しておくことも可能ですが、本番環境では有効にしておくのが普通です。監査による性能への影響は最小限に抑えられており、監査によって得られた情報は有用です(業務に不可欠な場合もあります)。

監査は、1人のユーザーまたは一連のユーザーに対してデータ・キャプチャを有効にする、Oracle Access Managementコンソールで設定される構成パラメータに基づいています。

監査データは、集中管理された1つのOracle Databaseインスタンスや、フラットファイルに書き込むことができます。監査記録の保存場所にかかわらず、記録には、特定の要件に合せて構成することのできる一連の項目が含まれています。監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。

セキュリティ・トークン・サービスは、あらかじめ設定されたコンプライアンス・レポートを提供するOracle Business Intelligence Publisherと統合できます。

32.9.1 セキュリティ・トークン・サービス監査レコードの格納について

セキュリティ・トークン・サービスは、共通監査フレームワークでサポートされている様々なターゲットに監査レコードを書き込むように構成できます。

- ローカル・フラット・ファイル: デフォルトでは、セキュリティ・トークン・サービスは監査データをファイルに記録します。

- 中央データベース: 本番環境においては、共通監査フレームワークのスケーラビリティと高可用性を実現するために、データベース監査ストアを使用することをお薦めします。監査データは累積的なもので、その量は時間とともに増大します。これは監査データ専用のデータベースとして、他のアプリケーションは使用しないようにするのが理想です。

- プラットフォーム固有のログ(LinuxのSyslogおよびWindowsのイベント・ログ)

- Audit Vault

監査記録用の恒久的ストアとしてのデータベースに切り替えるには、まず、リポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・スキーマを作成する必要があります。RCUは、データベースに監査記録を格納するために必要なスキーマを使用して、そのデータベース・ストアをシードします。スキーマ作成後にデータベース監査ストアを構成するには次の操作が必要です。

- 作成した監査スキーマを参照するデータ・ソースの作成

- そのデータ・ソースを参照する監査ストアの設定

関連項目:

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 監査データベース・ストアの設定

- 「監査設定の追加、表示または編集」

32.9.2 監査レポートおよびOracle Business Intelligence Publisherについて

データベース監査ストア内のデータは、Oracle Business Intelligence Publisherであらかじめ定義されたレポートを通じて表示されます。これらのレポートを使用すれば、ユーザー名、時間範囲、アプリケーション・タイプ、実行コンテキスト識別子(ECID)などの様々な基準に基づいて、監査データをドリルダウンできます。

セキュリティ・トークン・サービスには、そのまますぐに使用できるサンプル監査レポートがいくつか用意されており、これらのレポートにはOracle Business Intelligence Publisherでアクセスできます。また、Oracle Business Intelligence Publisherを使用して、独自のカスタム監査レポートを作成することもできます。

関連項目:

「監査レポートおよびOracle Business Intelligence Publisherについて」

32.9.3 監査ログについて

監査ログ・ファイルは、監査フレームワークが正常に機能しない場合に監査管理者がエラーを追跡したり問題を診断したりする助けとなります。監査ログ・ファイルには、Date、Time、Initiator、EventType、EventStatus、MessageText、ECID、RID ContextFields、SessionId、TargetComponentType、ApplicationName、EventCategoryなどを含むいくつかのフィールドが記録されます。

関連項目:

『Oracle Fusion Middlewareセキュリティ・ガイド』の監査の構成と管理に関する章に含まれる監査ログ関連項目

32.9.4 セキュリティ・トークン・サービス・イベントの監査について

セキュリティ・トークン・サービスに対して監査可能な特定の管理イベントとランタイム・イベントは、第8章「管理イベントとランタイム・イベントの監査」にまとめられています。イベントに付随し、監査を設定および検証するための共通の手順が示されています。詳細は、次のドキュメントを参照してください。

- 監査可能なセキュリティ・トークン・サービス・イベント

- Oracle Access Managementの監査の設定

- 監査とレポートの検証

33 セキュリティ・トークン・サービスの証明書と鍵の管理

この章の内容は次のとおりです。

- 前提条件

- セキュリティ・トークン・サービスの証明書と鍵の概要

- セキュリティ・トークン・サービスの暗号化/署名鍵の管理

- WS-Trust通信のパートナ・キーの管理

- 証明書検証の管理

33.1 前提条件

「セキュリティ・トークン・サービスの有効化および無効化」の説明に従って、セキュリティ・トークン・サービスを実行する必要があります。

33.2 セキュリティ・トークン・サービスの証明書と鍵の概要

この項では、セキュリティ・トークン・サービスに使用される証明書と鍵について説明します。

「証明書、認証局および暗号化鍵について」で説明されているとおり、公開鍵インフラストラクチャにより、デジタル証明書はWebベースのトランザクションの資格証明を確立します。

実行時の公開鍵: 実行時に公開鍵インフラストラクチャの資格証明が使用される独自のケースがあります。たとえば、(OWSMエージェントを使用した)リクエスタとセキュリティ・トークン・サービスとの間のWebサービス・セキュリティ(WSS)プロトコル通信のときなどです。表33-1も参照してください。

表33-1 実行時に使用されるセキュリティ・トークン・サービスの公開鍵

セキュリティ・トークン・サービスの動作

説明

SAMLアサーションの発行

- セキュリティ・トークン・サービスの署名アサーションは、STSグローバル設定に定義されている鍵を使用します。

- セキュリティ・トークン・サービスは、タイプが公開鍵のHolder-of-Key確認メソッドの証明鍵としてリクエスタの署名証明書を使用します。

- セキュリティ・トークン・サービスは、タイプが秘密鍵のHolder-of-Key確認メソッドの秘密証明鍵を暗号化するためにリライイング・パーティの暗号化証明書を使用します。

- セキュリティ・トークン・サービスは、タイプが秘密鍵のHolder-of-Key確認メソッドのRSTR内の秘密証明/エントリを暗号化するためにリクエスタの暗号化証明書を使用します。

トークンの発行

- セキュリティ・トークン・サービスではリライイング・パーティの暗号化証明書を使用して、送信トークンを暗号化します。

SAMLアサーションの検証

- セキュリティ・トークン・サービスでは発行局の署名証明書を使用して、着信SAMLアサーションの署名を検証します。

Webサービス・セキュリティ(WSS)プロトコル通信の使用

(OWSMエージェントを使用した)リクエスタとセキュリティ・トークン・サービスの間の通信

33.2.1 キーストアとセキュリティ・トークン・サービスについて

Security Token Serviceのいくつかのタイプのキーストアを簡単に要約したものを次に示します。

表33-2に、これらの詳細を示します。表の後に説明が続きます。

表33-2 Access Managerとセキュリティ・トークン・サービスのキーストア

キーストア

説明

システム・キーストア

.oamkeystore

OAM Serverインスタンスに関連付けられた鍵および証明書のコンテナ(署名および暗号化のためのOAM秘密鍵とセキュリティ・トークン・サービス秘密鍵)。

JCEKSタイプのシステム・キーストア.oamkeystoreのみが存在することが可能です。

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

「表32-1 セキュリティ・トークン・サービスの設定」で説明されているとおり、Oracle Access Managementコンソールを使用して証明書別名とパスワードを構成できます。

信頼キーストア

amtrustkeystore

クライアントが提示する証明書を検証するには、信頼キーストアを使用します。

$DOMAIN_HOME/config/fmwconfig/amtruststore

amtruststoreはインストール時に作成され、少なくとも1つの信頼できるアンカーを含める必要があります。

信頼キーストアは、JREのkeytoolアプリケーションを使用して管理されます。セキュリティ・トークン・サービスではカスタム信頼キーストアを使用できます。

証明書失効リスト(CRL)

証明書失効情報リストは、ファイルシステム上のZIPアーカイブに格納されます。これは、CRLベースの証明書失効チェックを実行するときにOAMサーバー・インスタンスで使用されます。amcrl.jarにはDERフォーマットのCRLファイルが含まれています。

$DOMAIN_HOME/config/fmwconfig/amcrl.jar

OAM Serverでは、キーストアおよびCRL Zipファイルの通知リスナーが定義されます。これらのファイルを変更すると、セキュリティ・トークン・サービスでは、再起動しなくてもキーストア/crl-zipが実行時にリロードされます。

「証明書失効リスト(CRL)」で説明されているとおり、amcrl.jarはインストールによって作成され、Oracle Access Managementコンソールを使用して変更できます。

表33-3のファイルは、JMXフレームワークによってドメイン内のすべてのOAMサーバーに配布されます。$DOMAIN_HOME/config/fmwconfig /mbeansディレクトリでは、ファイルを管理し、ファイルをドメイン全体に伝播する必要があることを識別するために、MBeanを示すファイルごとに登録mbeans.xmlが定義されます。

表33-3 キーストアMbean

キーストア

Mbeanと説明

システム・キーストア: .oamkeystore

.oamkeystoreの構成は、JREのkeytoolアプリケーションを使用して実行されます。

信頼キーストア: .amtruststore

amtruststoreの構成は、JREのkeytoolアプリケーションを使用して実行されます。

CRL: amcrl.jar

CRL MBean: CRLの管理に使用できます。

トークン・セキュリティの鍵ペアは、セキュリティ・トークン・サービスで共有される共通のキーストアに移入されます。これにより、Oracle Web Services Managerエージェントは共通キーストアと相互作用する必要がなくなります。

「システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット」で説明されているとおり、WLSTコマンドを使用してキーストアおよびamtruststoreのパスワードを取得できます。

33.2.2 Oracle Web Services Managerのキーストア(default-keystore.jks)について

このトピックでは、システムおよびパートナのキーと証明書を追加するためにOracle WSMエージェントで必要なJKSタイプのキーストアについて説明します。

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エージェント・キーストアとセキュリティ・トークン・サービス・キーストアは常に別にしておくことをお薦めします。そのようにしないと、キーはOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Managerキーがアクセスされる可能性があります。

注意:

Oracle WSMエージェント・キーストアとセキュリティ・トークン・サービス・キーストアは常に別にしておくことをお薦めします。

インストール中、Oracle WSMキーストアが構成されていない場合にインストーラが行うことを次に示します。

- $DOMAIN_HOME/config/fmwconfigフォルダでの新しいキーストアの作成(デフォルト名はdefault-keystore.jks)

- 署名および暗号化操作のためにOWSMで使用される、対応する証明書を持つキー・エントリの作成。このキー・エントリは、orakey別名の下のOWSMキーストアに格納されます。

- キー・エントリおよびキーストアのパスワードをCSFに格納します

キーストアにアクセスするために、場合によっては必要となることを次に示します。

- クライアントに配布するための署名/暗号化証明書の抽出(必要な場合)

- 署名/暗号化キー・エントリの更新または置換

- 信頼できる証明書を追加します

関連項目:

- 「WSSプロトコル通信のためのOWSMの構成」

33.2.3 リクエスタ証明書のOPSSキーストアの使用について

(Webサービス・リクエストの一部として受信される証明書トークンとは対照的に)クライアントがSKIなどの参照スキームを使用する特別な場合、リクエスタの証明書をOPSSキーストアに移入する必要があります。これは、キーをOPSSキーストアに手動でプロビジョニングする必要がある、一般的ではないシナリオです。

詳細は、「エージェントとセキュリティ・トークン・サービスについて」を参照してください。

33.3 セキュリティ・トークン・サービスの暗号化/署名鍵の管理

セキュリティ・トークン・サービスでは、鍵を使用して次の処理が行われます。

- 送信アサーションの署名

- WSSプロトコルで処理されないRSTメッセージに含まれる着信XML暗号化データ(トークン、エントロピなど)の復号化

セキュリティ・トークン・サービスでは、暗号化証明書および署名証明書の格納に次のキーストアが使用されます。

DOMAIN_HOME/config/fmwconfig/.oamkeystore

タスクの概要: セキュリティ・トークン・サービスのキーの管理

1. システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット

2. システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

3. セキュリティ・トークン・サービス証明書の抽出

関連項目:

「WSSプロトコル通信のためのOWSMの構成」

33.3.1 システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット

次の手順を使用して、キーストアを保護するパスワード、およびそのキーストアと同じパスワードを使用するキー・エントリをリセットします。

Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドで説明されているように、これらのキーはインストール時に作成および構成されます。パスワードおよびキー・エントリのパスワードはランダムに生成されます。

管理者は次のようにWLST resetKeystorePasswordメソッドを使用して、.oamkeystoreパスワードおよび.oamkeystoreパスワードと同じパスワードを持つ任意のキー・エントリを新しい値に設定できます。

- .oamkeystoreパスワードの更新

- キーストアと同じパスワードを持つ.oamkeystore内のキー・エントリの更新

- 変更を反映させるためのAccess Manager、Identity Federationおよびセキュリティ・トークン・サービスの構成の更新

- amtruststoreパスワードの更新(キーストアがデフォルトの.oamkeystoreと同じパスワードで保護されている場合)

関連項目:

Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

システム・キーストアおよび信頼キーストアのパスワードをリセットするには

1. 通常どおりWSLTスクリプト環境を入力します。

2. connect()コマンドを使用してWebLogic Server AdminServerに接続します。

3. ドメイン実行時ツリーのdomainRuntime()に移動します。

4. resetKeystorePassword()を実行します。

5. パスワードを入力および確認します。

33.3.2 システム・キーストア(.oamkeystore)への新しいキー・エントリの追加

管理者は、次の手順を使用して、新しいキー・エントリを作成および追加するkeytoolコマンドを使用してシステム・キーストア(.oamkeystore)に新しいキー・エントリを追加できます。エントリを追加した後、アサーションの署名および着信メッセージの復号化に使用できるように、エントリをセキュリティ・トークン・サービスの構成画面で定義する必要があります。

このトピックでは、新しいエントリを追加する次の手順により、SAMLアサーションの署名、またはWSSに含まれないXML暗号化データの復号化を実行します。

- 新しいエントリの追加

- 署名鍵を使用するためのSAML発行テンプレートの構成

- デフォルトの暗号化鍵の設定

33.3.2.1 新しいエントリの追加

前提条件

システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット

新しいエントリを構成する手順

1. keytoolを探します。

2. 自己署名証明書を生成するか証明書リクエストを生成する場合は、リモート認証局にリクエストをエクスポートし、認証局が発行した証明書をインポートします。

3. 画面のメッセージを確認します。

4. 必要に応じて次の手順に進みます。

- 「署名鍵を使用するためのSAML発行テンプレートの構成」(必要な場合)

- 「デフォルトの暗号化鍵の設定」(必要な場合)

33.3.2.2 署名鍵を使用するためのSAML発行テンプレートの構成

有効な管理者の資格証明を持つユーザーは、署名鍵を使用するように既存のテンプレートを編集する場合に、この手順をガイドとして使用できます。

関連項目:

- トークン発行テンプレートの管理について

- 既存のテンプレートの検索

署名鍵を使用するようにSAML発行テンプレートを構成する手順

1. 既存のトークン発行テンプレートのリストを表示します。
Oracle Access Managementコンソール
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート

2. 新しい鍵を使用するSAML発行テンプレートを検索して開きます。たとえば、saml11-issuance-templateなどです。

3. SAML発行テンプレートページで、「セキュリティ」タブをクリックします。

4. 「セキュリティ」タブの「署名と暗号化」セクションで、「アサーションの署名」をクリックします。

5. 「署名キーストア・アクセス・テンプレートID」リストから、署名キーストア・エントリとして「キーID」を選択します。

6. ページの上部にある「適用」ボタンをクリックしてこの情報を保存します。

7. 必要に応じて、「デフォルトの暗号化鍵の設定」に進みます。

33.3.2.3 デフォルトの暗号化鍵の設定

有効な管理者の資格証明を持つユーザーは、署名鍵を使用するように既存のテンプレートを編集する場合に、この手順をガイドとして使用できます。

関連項目:

「「セキュリティ・トークン・サービスの設定」について」

デフォルトの暗号化鍵を設定する手順

1. 「セキュリティ・トークン・サービスの設定」ページに移動します。
Oracle Access Managementコンソール
システム構成
セキュリティ・トークン・サービス
セキュリティ・トークン・サービスの設定

2. 「デフォルト暗号化テンプレート」リストから、新しいキー・エントリを選択します。

3. ページの上部にある「適用」ボタンをクリックしてこの情報を保存します。

4. 「デフォルトの暗号化鍵の設定」に進みます。

33.3.3 セキュリティ・トークン・サービス証明書の抽出

場合によっては、SAML署名操作またはXML暗号化操作に使用されるセキュリティ・トークン・サービス・キーを配布する必要があります。

- セキュリティ・トークン・サービスにより発行されたSAMLアサーションを検証するために、リライイング・パーティがセキュリティ・トークン・サービス署名鍵にアクセスする必要がある場合

- トークンをセキュリティ・トークン・サービス・サーバー用に暗号化する必要がある場合

SAML署名操作またはXML暗号化操作のためにセキュリティ・トークン・サービスで使用されるキー・エントリの証明書を配布するには、(「システム構成」→「セキュリティ・トークン・サービス」→「セキュリティ・トークン・サービスの設定」にリストされる)キーIDおよび優先エンコーディング(derとpem)を指定して、証明書取得サービスを使用します。詳細は、「証明書取得サービスの使用」を参照してください。

33.3.3.1 証明書取得サービスの使用

証明書取得サービスを使用する手順

1. (「Oracle Access Managementコンソール」の「システム構成」タブ、「セキュリティ・トークン・サービス」セクション、「セキュリティ・トークン・サービスの設定」にリストされる)証明書を取得するエントリのキーIDを取得します。

2. URLを作成します。たとえば、http(s)://osts-hostname:osts-port/sts/servlet/samlcert?id=<KEYID>&encoding=<ENCODING>などを作成し、次のものを指定します。

- エントリのキーIDを保持するID

- 証明書が返されるフォーマットを表すエンコーディング。使用可能な値はpem (PEMフォーマット)またはder (DERフォーマット)です(オプション、デフォルト値はpem)。

3. ブラウザに返された証明書を確認します。

33.4 WS-Trust通信のパートナ・キーの管理

この項の内容は次のとおりです。

- パートナ証明書について

- 実行時のリライイング・パーティの証明書のダウンロードについて

- パートナの署名証明書または暗号化証明書の設定

33.4.1 パートナ証明書について

WS-Trustメッセージの処理中に、セキュリティ・トークン・サービスではパートナ証明書を使用することが必要となる場合があります。表33-4に示すように、必要な証明書は状況によって異なります。

表33-4 WS-Trust通信のパートナ・キー

セキュリティ・トークン・サービス必須の実行内容

OAMサーバーの対応

リライイング・パーティ用に暗号化されたSAMLアサーションの発行

リライイング・パーティの暗号化証明書を使用して、送信トークンを暗号化します。

Holder of Key/非対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リクエスタ・パートナの署名証明書をアサーションに含まれる証明鍵として使用します。

注意: 署名に使用されたSOAPヘッダー内のX.509バイナリ・セキュリティ・トークンを参照するUseKey要素がWS-Trust RSTに含まれている場合、セキュリティ・トークン・サービスではこの証明書を証明鍵として使用できます。

Holder of Key/対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リライイング・パーティの暗号化証明書を使用して、アサーションに含まれる秘密証明鍵を暗号化します。

Holder of Key/対称タイプのサブジェクト確認を使用したSAMLアサーションの発行

リクエスタ、秘密またはサーバー・エントロピのRSTRで暗号化できます。

この場合、サーバーは次の処理を行います。

- リクエスタの暗号化証明書を使用して秘密を暗号化(秘密がサーバー・エントロピのみを使用して生成された場合)

- またはサーバー・エントロピを使用してRSTR内の秘密を暗号化(秘密がクライアントおよびサーバー・エントロピから導出された場合)

注意: 署名に使用されたSOAPヘッダー内のX.509バイナリ・セキュリティ・トークンを参照するProofEncryption要素がWS-Trust RSTに含まれている場合、セキュリティ・トークン・サービスではこの証明書を使用して、クライアントに返された秘密またはエントロピを暗号化できます。

着信SAMLアサーションの検証

発行局の署名証明書を使用して、アサーションに存在するXMLデジタル署名を検証します。

33.4.2 実行時のリライイング・パーティの証明書のダウンロードについて

セキュリティ・トークン・サービスは実行時に、RSTのAppliesToフィールドにリストされるサービスのリライイング・パーティWSSポリシーをダウンロードできます。セキュリティ・トークン・サービスがリライイング・パーティのWS-Secポリシーをダウンロードするように構成されている場合は、セキュリティ・トークン・サービスがリライイング・パーティに接続できるように、必要に応じてプロキシ設定が正しく入力されていることを確認します。

リライイング・パーティ・パートナ・プロファイルがそのように構成されている場合、セキュリティ・トークン・サービスに対してサービスからWS-Secポリシーをダウンロードするように指示されます。その後、セキュリティ・トークン・サービスではポリシーに存在する証明書を抽出し、必要に応じて暗号化操作に使用します。また、次の点にも注意が必要です。

- セキュリティ・トークン・サービスがリライイング・パーティに対して暗号化されたSAMLアサーションを発行する場合、サーバーではリライイング・パーティのWS-Secポリシーからダウンロードされた証明書を使用して送信トークンが暗号化されます。

- セキュリティ・トークン・サービスがHolder of Key/対称タイプのサブジェクト確認を使用してSAMLアサーションを発行する場合、セキュリティ・トークン・サービスではリライイング・パーティのWS-Secポリシーからダウンロードされた証明書を使用して、アサーションに含まれる秘密証明鍵が暗号化されます。

リライイング・パーティ・パートナ・プロファイルが実行時に証明書をダウンロードするように構成するには、「パートナの署名証明書または暗号化証明書の設定」を参照してください。

33.4.3 パートナの署名証明書または暗号化証明書の設定

パートナの署名証明書または暗号化証明書を設定するには、次の操作を実行します。

または、WLSTパートナ・コマンドを使用して、特定のパートナの署名証明書または暗号化証明書を設定します。

前提条件

表33-4「WS-Trust通信のパートナ・キー」を確認します。

パートナの証明書を設定する手順

1. 「Oracle Access Managementコンソール」の「システム構成」タブの「セキュリティ・トークン・サービス」セクションで、「パートナ」ノードを展開します。

2. 「パートナ」ノード内で、「リクエスタ」(または、「リライイング・パーティ」または「発行局」(表33-4を参照))を展開します。

3. 証明書を設定する必要があるパートナを検索して開きます(または作成します)。

4. 必要に応じて「パートナ」設定を編集(「Token Serviceパートナの管理」を参照)し、「保存」をクリックします。

5. 暗号化証明書: 「参照」ボタンをクリックし、暗号化証明書を検索して選択します。

6. 署名証明書: 「参照」ボタンをクリックし、署名明書を検索して選択します。

7. 情報を保存してページを閉じます。

8. 「証明書検証の管理」に進みます。

33.5 証明書検証の管理

この項では、証明書検証の管理について説明します。証明書検証の条件は、表33-5で説明されています。

表33-5 セキュリティ・トークン・サービスの証明書検証の条件

STSによって証明書が検証される場合...

検証されるセキュリティ・トークンは次のタイプのいずれかです。

- X.509

- X.509v3

- PKCS#7

SAMLアサーションを検証する必要があります。

セキュリティ・トークン・サービスはSAML発行局の署名証明書を検証するように構成されます。

検証が成功するための要件を表33-6に示します。

表33-6 証明書検証が成功するための要件

証明書が次の状態であること

方法...

信頼できるアンカーにリンクされていること:

- 信頼できるアンカーになる

- または発行者を信頼できるアンカーにする

取り消されていないこと:

- 信頼できるアンカーになる

- または発行者を信頼できるアンカーにする

証明書の取消ステータスは、次のものを確認することで判断できます。

- 管理者によってアップロードされたCRLのリスト

- OCSPサーバー

- CRL配布ポイント

証明書検証には信頼アンカー・ストア(.amtruststore)が必要です。このストアおよび検証を管理する手順については、次のトピックで説明します。

- 信頼アンカー・ストア(amtruststore)の管理

- 証明書失効リストの管理

- セキュリティ・トークン・サービスのカスタム信頼アンカー・ストアの使用方法

33.5.1 信頼アンカー・ストア(amtruststore)の管理

信頼アンカー・キーストアは、keytoolコマンドを使用して管理されます。キーストアに追加された証明書は、証明書検証モジュールによって検出されます。

注意:

通知はJMX通知フレームワークを使用して実行されますが、通知のリフレッシュ時間(デフォルトでは60秒)に応じて時間を要する場合があります。

前提条件

システム・キーストア(.oamkeystore)および信頼キーストア(amtruststore)のパスワードのリセット

信頼アンカー・ストア(amtruststore)を管理する手順

1. keytoolを探します。

2. 次のコマンドを実行します。

keytool -keystore $DOMAIN_HOME/config/fmwconfig/amtruststore
-storetype JKS -alias orakey -file $CERT_FILE

3. 画面のメッセージを確認し、要求された場合はパスワードを入力します。

4. 「証明書失効リストの管理」に進みます。

33.5.2 証明書失効リストの管理

セキュリティ・トークン・サービスでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。

この項では、証明書の失効ステータスを確認し、次の操作を実行するために証明書失効リスト(CRL)を追加または削除する方法を説明します。

関連項目:

「グローバル証明書の検証および取消の管理」

前提条件

証明書失効リストをインポート可能な状態にします。

タスクの概要: 証明書検証および失効リストの管理

1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

2. 「証明書失効リスト(CRL)の管理」を参照してください。

3. 「証明書検証の有効化」を参照してください。

4. 「CRL配布ポイント拡張の構成(CDP)」を参照してください。

33.5.3 セキュリティ・トークン・サービスのカスタム信頼アンカー・ストアの使用方法

オプションで、特定のデプロイメントにAccess Managerの信頼アンカーとは別の信頼アンカーのセットが必要な場合、別のキーストアをセキュリティ・トークン・サービスの信頼できる証明書ストアとして構成できます。これを実行するには、管理者が次のタスクを実行しておく必要があります。

注意:

カスタム信頼アンカー・ストアの使用は、ほとんどの顧客に不要なオプション機能です。

タスクの概要: 信頼できる証明書のカスタム・キーストアのデプロイ

1. $DOMAIN_HOME/config/fmwconfigディレクトリにJKSキーストアを作成します。

2. 「Oracle Access Managementコンソール」の「セキュリティ・トークン・サービスの設定」ページで、新しい信頼ストアのフルパス名を入力し、変更を適用します。

3. セキュリティ・トークン・サービスがデプロイされているドメインで、管理者がカスタム信頼アンカー・キーストアをすべてのサーバーに手動で伝播する必要があります。

34 テンプレート、エンドポイントおよびポリシーの管理

この章では、セキュリティ・トークン・サービスの次の情報を提供します。

- 前提条件

- 概要

- 既存のテンプレートの検索

- トークン発行テンプレートの管理

- トークン検証テンプレートの管理

- セキュリティ・トークン・サービス・エンドポイントの管理

- トークン発行ポリシー、条件およびルールの管理

- TokenServiceRPタイプのリソースの管理

- カスタム・クラスを使用可能にする

- セキュリティ・トークン・サービス・カスタム構成の管理

34.1 前提条件

「セキュリティ・トークン・サービスの有効化および無効化」の説明に従って、「使用可能なサービス」ページでセキュリティ・トークン・サービスを有効にする必要があります。

34.2 はじめに

セキュリティ・トークン・サービスでは、ポリシーに基づいてリソースへのアクセスを定義するアプリケーション・ドメインを定義することで、WSPにアクセスするユーザーの制御がサポートされています。アプリケーション・ドメインは、WSPに基づいてセキュリティ・トークンをリクエストできるユーザーを決定する認可ルールとともにWebサービスを識別します。

次の機能は信頼発行ポリシーによって確立されており、このポリシーは、「Oracle Access Managementコンソール」の「ポリシー構成」タブにある「アプリケーション・ドメイン」を介して管理できます。

- リライイング・パーティまたはWebサービス・プロバイダを表すTokenServiceRPタイプのリソース。

- タイプがTokenServiceRPのリソースのセットに対してポリシーを定義するトークン発行ポリシー。

- ポリシーにリストされているリソースのトークンの発行を許可または拒否されるクライアントのアイデンティティを定義する条件。クライアントは、リクエスタ・パートナまたはデフォルト・アイデンティティ・ストアからのユーザーです。

セキュリティ・トークン・サービスでは、セキュリティ・トークン・サービスにより発行されるセキュリティ・トークンのコンシューマになるリモートWebサービス・プロバイダを表す、リライイング・パーティ・パートナの作成がサポートされています。

WS-Trustリクエストに指定されているWS-Addressingエンドポイントがセキュリティ・トークン・サービスのリライイング・パーティ・パートナにマップされるように、リライイング・パーティ・パートナごとに、パートナにマップされるURLを定義できます。

実行時に、クライアントがトークンの発行を要求すると、セキュリティ・トークン・サービスでは信頼発行ポリシーを評価し、トークンを発行できるかどうかを判断します。

- クライアントはリクエスタ・パートナまたはエンド・ユーザーとして識別されます。

- WS-TrustリクエストにAppliesTo要素が存在し、リライイング・パーティ・パートナにマップされた場合、信頼発行ポリシー評価のTokenServiceRPリソースはセキュリティ・トークン・サービスのリライイング・パートナのパートナIDになります。

- WS-TrustリクエストにAppliesTo要素が存在し、リライイング・パーティ・パートナにマップできなかった場合、信頼発行ポリシー評価のTokenServiceRPリソースはAccess Managerアプリケーション・ドメインに定義されているUnknownRPになります。

- WS-TrustリクエストにAppliesTo要素がない場合、信頼発行ポリシー評価のTokenServiceRPリソースはAccess Managerアプリケーション・ドメインに定義されているMissingRPになります。

セキュリティ・トークン・サービスでは、(少なくとも)次の項目がリクエストを処理し、着信リクエスト(RST)に基づいてトークンを発行する必要があります。

- エンドポイント

- 1つの発行テンプレート

- 1つの検証テンプレート

- トークンを含む1つのリクエスタ・パートナ・プロファイル

- 1つのリライイング・パーティ・パートナ・プロファイル

注意:

パートナのプロビジョニングが必要な場合があります。

ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、その後そのレコードを使用して送信トークンを移入するために、セキュリティ・トークン・サービスにはLDAPサーバーが必要です。パートナが使用可能になる前に、移入が必要な場合があります。

34.3 既存のテンプレートの検索

「トークン検証テンプレート」または「トークン発行テンプレート」ノードを開くと、検索結果の表に定義済のすべてのテンプレート名が表示されます。特定のテンプレートまたはテンプレートのセットを迅速に検索するために、検索コントロールを使用できます。

この項では、検索の絞込みに使用できるコントロールについて説明します。このコントロールは、トークン検証テンプレートとトークン発行テンプレートのどちらを検索する場合も類似しています。内容は次のとおりです。

- テンプレートの検索コントロールについて

- テンプレートの検索

34.3.1 テンプレートの検索コントロールについて

次の図は、多くの類似点がある検索ページを示しています。

- 図34-1「検証テンプレートの検索コントロール」

- 図34-2「発行テンプレートの検索コントロール」

図34-1 検証テンプレートの検索コントロール

「図34-1 検証テンプレートの検索コントロール」の説明

図34-2 発行テンプレートの検索コントロール

「図34-2 発行テンプレートの検索コントロール」の説明

表34-1に、テンプレート検索の絞込みに使用できるコントロールを示します。特に明記しないかぎり、すべての要素を検証テンプレートと発行テンプレートの両方の検索に使用できます。

表34-1 検証テンプレートの検索

要素

説明

一致

「すべて」を選択して、指定のすべてに一致するテンプレートを検索します。

「任意」を選択して、少なくとも1つの指定に一致するテンプレートを検索します。

検索操作リスト

検索を絞り込むために選択する操作のリスト。

...テンプレート名

リストから操作を選択し、検索の絞込みに役立つ情報をフィールドに入力します。

説明

オプションの説明フィールドを使用して検索を絞り込みます。

トークン・プロトコル

検証テンプレートのみ

リストされているプロトコルからトークン・プロトコルを選択します。

- WS-Trust

- WS-Security

トークン・タイプ

トークン・タイプを選択します。標準とカスタムの両方のトークン・タイプがあります。

- ユーザー名: 消費および作成

- X.509: 消費

- SAML: 消費および作成

- OAM 11g: OBO (代理)フィールドを使用する消費

- Kerberos: 消費

- カスタム: OBO (代理)フィールドを使用する消費および作成

検索

フォームの基準を使用して検索機能を開始します。

リセット

デフォルトのみで「検索」フォームをリセットします。

フィールドの追加

検索基準として追加できる追加項目のリスト。

「検索結果」表

この表の後半に説明されているように、「表示」メニューの選択内容に基づいて検索の結果を項目化します。

「アクション」メニュー

表示: 検証テンプレート用のアクション

結果表の選択項目で実行できる次の機能を提供します。

注意: 「アクション」メニューの機能は、結果表の上のコマンド・ボタンをミラー化します。次に例を示します。

- 新規 ... テンプレート: 「検索」ページの上にある新規 ... テンプレート・ボタンをクリックするか、メニューから新規 ... テンプレートを選択するか、表の上にある「+」ボタンをクリックします。

- 編集: 結果表の名前をクリックするか、「アクション」メニューから「編集」を選択するか、結果表の上にある「編集」(鉛筆)コマンド・ボタンをクリックします。

- 類似作成: 表の目的の行を選択し、「アクション」メニューから「類似作成」を選択するか、表の上にある「類似作成」コマンド・ボタンをクリックします。

- 削除: 結果表の目的の行を選択し、「アクション」メニューから「削除」を選択するか、表の上にある「削除」(X)コマンド・ボタンをクリックします。

「表示」メニュー

検証テンプレートのみ

結果表に表示する情報を識別できるリスト。

「表示」メニュー

発行テンプレートのみ

結果表に表示する情報を識別できるリスト。

結果表にリストされる項目の順序を定義するために選択できるコントロール:

- 昇順

- 降順

34.3.2 テンプレートの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、特定のテンプレートまたはテンプレートのセットを検索するために検索コントロールを使用できます。たとえば、特定のトークン・タイプのすべてのテンプレートを検索するには、単にそのトークンのタイプを選択します。特定のトークン・タイプおよび名前のすべてのテンプレートに検索を絞り込むことができます。

これらの手順を実行する場合、必要に応じてできるだけ多く、またはできるだけ少なく情報を入力します。該当しない手順はスキップしてください。

関連項目:

「テンプレートの検索コントロールについて」

テンプレートを検索する手順

1. 「システム構成」タブから「Secure Token Serviceの設定」セクションを展開します。

2. ナビゲーション・ツリーで、目的の「テンプレート」ノードを開きます。たとえば、「トークン検証テンプレート」など。

3. 検索条件を編集します(表34-1)。次に例を示します。

- 一致: 「すべて」

- 名前: 「次を含む」、em

- トークン・タイプ: 「次と等しい」、ユーザー名

4. 「検索」をクリックし、結果を確認して、開くものをクリックします。

34.4 トークン発行テンプレートの管理

発行テンプレートには、トークンの作成方法に関するルールが含まれており、トークン・タイプに固有のものです。発行テンプレートはそれぞれ署名および暗号化を示しており、トークンの一部として送信される属性名、値マッピングおよびフィルタリング設定も含まれています。

この項の内容は次のとおりです。

- トークン発行テンプレートの管理について

- トークン発行テンプレートの管理

34.4.1 トークン発行テンプレートの管理について

トークン発行テンプレートはそれぞれ、トークンの構築方法を示しています。つまり、トークンの構築時に使用される署名または暗号化を示しています。各トークン発行テンプレートでは、送信トークンに含まれる属性に適用される属性マッピングおよびフィルタリング・ルールも定義されます。ただし、発行テンプレートには、送信トークンで送信される属性はリストされません。これはリライイング・パーティ・パートナ・プロファイルで定義されます。

トークン発行テンプレートには、選択したトークン・タイプに応じて異なる点の詳細が表示されます。表34-2に、詳細が記載されている場所を示します。

表34-2 発行テンプレートの要件

トピック

図および表

一般詳細

図34-3、表34-3

発行プロパティ: ユーザー名トークン

図34-4、表34-4

発行プロパティ: SAMLトークン

図34-5、表34-6

セキュリティ: SAMLトークン

図34-6、表34-6

属性マッピング: SAMLトークン

図34-9、表34-7

一般詳細

図34-3に、デフォルトが表示されている状態の「新規発行テンプレート」ページを示します。特に明記しないかぎり、「一般情報」は、選択するトークン・タイプドを問わず同じです。詳細は、表34-3を参照してください。「一般情報」を入力して「保存」をクリックした後、テンプレート名またはトークン・タイプに戻って編集することはできません。

図34-3 発行テンプレート: 一般詳細とデフォルト

「図34-3 発行テンプレート: 一般詳細とデフォルト」の説明

表34-3 発行テンプレート: 一般詳細

要素

説明

発行テンプレート名

このテンプレートの一意の名前を入力します。

説明

オプション。

トークン・タイプ

リストされているタイプから標準(または、ある場合はカスタム)のトークン・タイプを選択します。

SAML、ユーザー名およびカスタムのトークン・タイプ

暗号化されたトークンの送信

クリックしてトークン暗号化を有効にします。

トークン暗号化アルゴリズム

トークン暗号化が有効になっている場合は、リストされているアルゴリズムから「トークン暗号化アルゴリズム」を選択します。

発行プロパティ: ユーザー名トークン・タイプ

トークン・タイプがユーザー名の場合、ユーザー名トークン・タイプ・テンプレートには図34-4に示す発行プロパティが必要です。

図34-4 発行プロパティ: ユーザー名トークン・タイプ

「図34-4 発行プロパティ: ユーザー名トークン・タイプ」の説明

表34-4に、ユーザー名トークン・タイプの発行プロパティを示します。

表34-4 発行プロパティ: ユーザー名トークン・タイプ

要素

説明

名前識別子ユーザー属性

ユーザー名トークンへのUsername要素の移入に使用される属性。

名前識別子ユーザー属性ストア

ユーザー属性ストア・タイプを選択します。

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

パスワード属性

ユーザー名トークンへのPassword要素の移入に使用される属性。

パスワード属性ストア

パスワード属性ストア・タイプを選択します。

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

Nonceを含める

ランダム・データからなるNonceをユーザー名トークンに含めるかどうかを示します。

デフォルト: 無効

タイムスタンプを含める

Created要素をユーザー名トークンに含めるかどうかを示します。

デフォルト: 無効

発行プロパティ: SAMLトークン・タイプ

SAML 1.1および2.0トークン・タイプには、図34-5に示す発行プロパティが必要です。

注意:

これらのプロパティは、ユーザー名トークン・タイプのプロパティとは異なります。

図34-5 発行プロパティ: SAMLトークン・タイプ

「図34-5 発行プロパティ: SAMLトークン・タイプ」の説明

表34-5に、すべての発行プロパティをトークン・タイプ別に示します。発行プロパティが必要なのは、SAMLトークン・タイプのみです。

表34-5 発行プロパティ: SAMLトークン・タイプ

要素

説明

アサーション発行者

アサーションの発行者を表す識別子を指定します。この文字列は、このセキュリティ・トークン・サービスをアサーションの発行者として表すために使用されます。

名前識別子フォーマット

リストからフォーマットを選択した後、テキスト・フィールドに詳細を入力します。

名前識別子修飾子

「名前識別子修飾子」として設定される文字列を含みます。

名前識別子ユーザー属性

名前識別子の値の移入に使用される属性を参照します。

名前識別子ユーザー属性ストア

- ユーザーストア

- コンテキスト

注意: 属性ストアが「ユーザーストア」の場合、ユーザー・レコードからの属性の取得にはLDAPが使用されます。属性ストアが「コンテキスト」の場合は、着信トークンからのデータが属性ソースとして使用されます。

認証文を含める

SAML認証文をアサーションに含めるかどうかを示します。

デフォルト: 無効

注意: このタイプの文を含めるには認証操作が必要です。着信トークンに一部の認証データが含まれ、そのデータが検証される場合、認証文が含まれます(たとえば、着信SAMLアサーションに認証文が含まれるか、ユーザー名トークンに検証済の資格証明が含まれます)。

属性文を含める

SAML属性文を送信アサーションに含めるかどうかを示します。

このタイプの文が含まれるのは、このフラグがtrueに設定され、少なくとも1つの属性が送信アサーションに含まれる場合のみです。

デフォルト: 有効

注意: RP PPは、送信トークンに含める必要がある属性を決定します。

有効期間

トークンが有効な時間の長さ(秒)を指定します。

デフォルト: 3600(秒)

「セキュリティ」の詳細: SAMLトークン

図34-6および表34-6に示すように、SAMLトークン・タイプにのみ「セキュリティ」の詳細が必要です。

図34-6 「セキュリティ」の詳細: SAMLトークン

「図34-6 「セキュリティ」の詳細: SAMLトークン」の説明

表34-6 「セキュリティ」の詳細: SAMLトークン

要素

説明

署名と暗号化

「署名キーストア・アクセス・テンプレートID」フィールドで参照されるキーを使用して、アサーションに署名するかどうかを示します。

アサーションの署名

アサーションに署名証明書が含まれるかどうかを示します。

デフォルト: 有効

署名に証明書を含める

デフォルト: 有効

署名キーストア・アクセス・テンプレートID

この発行テンプレートで作成されたアサーションに署名するために使用されるキーを参照します。キー・テンプレートは、「セキュリティ・トークン・サービスの設定」セクションで定義されます。

サブジェクト確認

デフォルト・サブジェクト確認メソッド

リクエスタがWS-Trustリクエストでメソッドを指定しなかった場合、デフォルトで使用される「サブジェクト確認メソッド」を示します。可能な値は次のとおりです。

- ベアラー

- 「公開鍵」を使用するHolder of Key

- 「対称鍵」を使用するHolder of Key

- 送信者保証

Holder-of-Key対称鍵の計算

デフォルト: 有効

Holder of Key対称鍵データの秘密鍵の作成時に、セキュリティ・トークン・サービスでランダム・データが生成されるかどうかを示します。

- 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に変更できます。

- 属性のローカル値をフィルタ処理して送信アサーションに含まれないようにする属性値フィルタリング。たとえば、削除されるセンシティブ属性値もあれば、発行される属性値もあります。

関連項目:

図34-9および表34-11のトークン・マッピング属性。

表34-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のローカル値を表します。

- 大/小文字区別なし: 属性値を「ローカル属性」フィールドと比較するときに、セキュリティ・トークン・サービスで大/小文字が区別されるかどうかを示します。

属性値フィルタ

アサーションに含まれる属性の、オプションの値フィルタリングを定義します。

注意: この属性値フィルタリングは、属性名マッピングに適用されます。属性の属性フィルタリングを定義するには、まずその属性の属性名マッピングを定義する必要があります。

- 条件: 属性値がフィルタ処理されるかどうかを判断する式に関連付けられた条件を含みます。使用可能な値は、「属性値の条件フィルタ」で説明されています。

- 式: フィルタリング・ルールの評価に使用されるデータを含みます。

- 大/小文字区別なし: 属性値を式フィールドと比較するときに、セキュリティ・トークン・サービスで大/小文字が区別されるかどうかを示します。

属性値の条件フィルタ

このオプションの値フィルタリングは属性名マッピングに適用され、アサーションに含まれます。属性の属性フィルタリングを定義するには、まずその属性の属性名マッピングを定義する必要があります。「条件」は、属性値がフィルタ処理されるかどうかを判断する式に関連付けられます。使用可能な「条件」の値は次のとおりです。

- regexp: 式には正規表現が含まれ、trueと評価された場合、属性値がフィルタ処理されます。

- equals: 属性値が式フィールドに含まれるデータと一致する場合、属性値はフィルタ処理されます。

- not-equals: 属性値が式フィールドに含まれるデータと一致しない場合、属性値はフィルタ処理されます。

- not-equals: 属性値が式フィールドに含まれるデータと一致しない場合、属性値はフィルタ処理されます。

- endswith: 属性値が式フィールドに含まれるデータで終了する場合、属性値はフィルタ処理されます。

- contains: 式フィールドに含まれるデータが属性値に出現する場合、属性値はフィルタ処理されます。

- not-contains: 式フィールドに含まれるデータが属性値に出現しない場合、属性値はフィルタ処理されます。

- equals-null: 属性値がnullの場合、フィルタ処理されます。

- not-equals-null: 属性値がnull以外の場合、フィルタ処理されます。

34.4.2 トークン発行テンプレートの管理

有効なOracle Access Management管理者の資格証明を持つユーザーは、新しいトークン発行テンプレートを開発する(または既存のテンプレートを編集する)場合に、この手順をガイドとして使用できます。該当しない手順はスキップしてください。

次の手順では、Security Assertion Markup Language (SAML)トークンの新しいトークン発行テンプレートを作成する方法を説明します。

前提条件

目的のLDAPアイデンティティ・ストアが登録され、デフォルト・ストアとして構成されていることを確認します。

関連項目:

- トークン発行テンプレートの管理について

- 既存のテンプレートの検索

新しいトークン発行テンプレートを作成する手順

1. 既存のトークン発行テンプレートのリストを表示します。
Oracle Access Managementコンソール
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート

2. 新しいトークン発行テンプレート:

1. 右上角の「新規発行テンプレート」ボタンをクリックします(または「検索結果」表の上にある追加「+」コマンド・ボタンをクリックします)。

2. 一般: このテンプレートの一般情報を定義し、次のものを表示します。
表34-3「発行テンプレート: 一般詳細」

3. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

4. ユーザー名トークン・タイプ: このテンプレートの発行パラメータを定義し、次のものを表示します。
表34-4「発行プロパティ: ユーザー名トークン・タイプ」

5. SAMLトークン・タイプ: このテンプレートのパラメータを定義し、次のものを表示します。
表34-5「発行プロパティ: SAMLトークン・タイプ」

表34-6「「セキュリティ」の詳細: SAMLトークン」

表34-7「発行テンプレート: 属性マッピング、SAMLトークン」

6. 「適用」をクリックします(または保存せずに「元に戻す」をクリックします)。

7. 定義を閉じます。

3. 既存のテンプレートの検索: 「システム構成」タブの「セキュリティ・トークン・サービス」セクションから次の手順を実行します。

1. すべて検索: 「トークン発行テンプレート」ノードをダブルクリックし、結果表を確認します。

2. 検索の絞込み: 検索条件(表34-1)を指定し、「検索」ボタンをクリックして結果表を確認します。

3. 検索フォームのリセット: 「リセット」ボタンをクリックします。

4. テンプレートの編集: 作成した保存済のページから編集を開始します。
または、ステップ3を使用して目的のテンプレートを検索し、「検索結果」表の名前をクリックして定義を表示します。

1. 必要に応じて詳細を編集します。

2. ページの上部にある「適用」ボタンをクリックし、変更を送信します(または「元に戻す」をクリックして変更を取り消します)。

5. テンプレートの削除:

1. 「検索結果」表の目的の名前をクリックし、削除する項目を選択します。

2. 「アクション」メニューの「削除」をクリックします(または、表の上にある「削除」(X)コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

34.5 トークン検証テンプレートの管理

検証テンプレートを使用して、着信トークンを検証したり、オプションでリクエスタ・パートナまたはユーザー・レコードに着信トークンをマップします。

- OnBehalfOfユースケースの場合、WS-Trust検証テンプレートが存在する必要があります。

- アサーションを検証するためには、発行局パートナ・プロファイルが存在する必要があります。

セキュリティ・トークン・サービス・エンドポイントは、WSSヘッダー内のトークンを検証する方法とトークンとバインディング・データをリクエスタにマップする方法を示すWSS検証テンプレートにリンクされます。

この項の内容は次のとおりです。

- トークン検証テンプレートの管理について

- トークン検証テンプレートの管理

34.5.1 トークン検証テンプレートの管理について

セキュリティ・トークン・サービス・エンドポイントは常に、リクエストをリクエスタ・エントリまたはユーザーにマップする方法を示すWS-Security検証テンプレートでマップされます。

- マッピングが必要で一致が見つからない場合、処理は失敗します。

- マッピングが不要な場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。

- どちらの場合も、リクエスタ・パートナ・プロファイルが取得されます。

- ユーザー・レコードへのマッピングが実行される場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。

- リクエスタ・パートナ・エントリへのマッピングが実行される場合は、このパートナのリクエスタ・パートナ・プロファイルが使用されます。

検証テンプレートによってトークン検証ルールが決定されます。

- 着信トークンを検証およびマップするかどうか。

- マッピングが有効な場合に使用されるマッピング・ルール。

表34-8に示すように、検証テンプレートはトークン・タイプおよびプロトコルに固有です。

表34-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マッピング表

図34-7に、「新規検証テンプレート」ページのデフォルトの一般詳細を示します。

図34-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト

「図34-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト」の説明

表34-9に、「新規検証テンプレート」の「一般」ページの要素を示します。

表34-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(秒)

認証の詳細

ユーザー名トークン検証テンプレートに固有です。

資格証明検証の有効化

ユーザー名トークンに含まれる資格証明を使用して検証を有効にするには、このボックスを選択します。

有効にすると、セキュリティ・トークン・サービスでは、指定された検証ソースを使用して、ユーザー名トークンに含まれるusernameおよびpassword要素が検証されます。

注意: ユーザー名トークンのWS-Securityプロファイルに定義されているパスワード・ダイジェストは、このリリースではサポートされていません。

関連項目: 表34-10「新規検証テンプレート: 認証の詳細」

図34-8に、「資格証明検証の有効化」を選択し、そのページの「認証の詳細」セクションにデフォルト値が表示されている状態の「一般」詳細ページを示します。これは、ユーザー名トークン検証に固有です。

図34-8 新規検証テンプレート: 「一般」の「認証の詳細」

「図34-8 新規検証テンプレート: 「一般」の「認証の詳細」」の説明

表34-10に、「資格証明検証の有効化」を選択した場合に使用できる認証関連の詳細を示します。

表34-10 新規検証テンプレート: 認証の詳細

要素

説明

検証ソース

資格証明検証ソースを選択できるリスト

ユーザー名トークンに含まれる資格証明を検証する場合、次に示す4つのタイプの検証ソースがあります。

- LDAP: 資格証明の検証にはスタンドアロンLDAPサーバーが使用されます。接続情報を入力する必要があります。

- 組込みLDAP: 資格証明の検証には、WebLogicサーバーに組み込まれたLDAPサーバーが使用されます。情報を入力する必要はありません。

- UserStore: 資格証明の検証には、「共通構成」->「データソース」で構成されているデフォルトのユーザー・アイデンティティ・ストアが使用されます。この検証テンプレート画面で情報を入力する必要はありません。

- パートナ: 資格証明は、「リクエスタ・パートナ」エントリに入力されたユーザー名/パスワード情報に対して検証されます。
注意: 選択した場合、「トークン・マッピング」構成セクションが無効になります。これは、資格証明の検証操作後にトークンがリクエスタ・パートナにマップされているためです。

LDAP URL

LDAPサーバーのURL。

管理者ユーザー

LDAPサーバーの参照に使用されるアカウントのユーザー名。

管理者パスワード

LDAPサーバーの参照に使用されるアカウントのパスワード。

ベースDN

ユーザー・レコードの参照時に使用される基本検索DN。

HAの有効化

LDAPサーバーがHAモードで、前にロード・バランサがあるかどうかを示します。

個人オブジェクト・クラス

ユーザー・レコードに関連付けられた個人オブジェクト・クラス。

一意のID

ユーザーの一意の識別子データを含むユーザー・レコードの属性。ほとんどの場合、「資格証明ID」フィールドと同じです。

資格証明ID

ユーザー名データを含むユーザー・レコードの属性。このフィールドは、ユーザー名に基づいてユーザー・レコードを参照するために使用されます。

最大接続数

開いている同時LDAP接続の最大数。

デフォルト: 50

接続待機タイムアウト

新しい接続を開くときに待機する最大時間。

デフォルト: 5000(秒)

接続の非アクティブのタイムアウト

LDAP接続を閉じるまでの非アクティブの最大時間。

デフォルト: 5000(秒)

接続の読込みのタイムアウト

開いている同時LDAP接続の最大数。

デフォルト: 5000(秒)

トークン・マッピング

「トークン・マッピング」セクションは次の内容を示します。

- 着信トークンをマップする必要があるかどうか。

- 着信トークンをマップする必要があるかどうか、実行されるマッピングの種類。たとえば、ユーザーへのトークンのマッピング、パートナへのトークンのマッピングなどです。

- マッピングの実行方法。たとえば、パートナ/ユーザー属性へのトークン属性のマッピング、複数のトークン属性を含むLDAP問合せの使用などです。

マッピング・ルールは、着信データをユーザーまたはパートナにマップする方法を決定します。着信トークンの次のデータが使用されます。

- UNTのユーザー名

- KerberosのユーザーID

- SAMLの名前IDおよび属性

- X.509のDNコンポーネント

- カスタムからの属性

マッピングは次のものを使用して実行されます。

- 簡易マッピング: ある着信属性をユーザー・レコード属性と照合

- 複雑なLDAP問合せ: 着信データのプレースホルダを含むLDAP問合せ。例: (&(sn=%lastname%)(mail=%email%))

- SAMLの名前IDマッピング表

新しい検証テンプレートのトークン・マッピングの例を次に示します。

- 図34-9「トークン・マッピング: SAML2 WS-Security検証テンプレート」

- 図34-10「トークン・マッピング: username-wstrust-validation-template」

- 図34-11「トークン・マッピング: x509-wss-validation-template」

図34-9は、名前IDフォーマットに基づいて、一致する属性を持つユーザー・レコードと名前ID値を照合することでユーザー・レコードにトークンをマップするためにセキュリティ・トークン・サービスに必要なマッピング構成設定を示しています。

- 「トークンの宛先ユーザーのマップ」の有効化

- 簡易ユーザー・マッピングの有効化

- 属性ベース・ユーザー・マッピングの無効化

図34-9 トークン・マッピング: SAML2 WS-Security検証テンプレート

「図34-9 トークン・マッピング: SAML2 WS-Security検証テンプレート」の説明

図34-10に、一致するuidを持つユーザー・レコードとユーザー名トークンのusername要素を照合することでユーザー・レコードにトークンをマップするためにセキュリティ・トークン・サービスに必要なマッピング構成設定を示します。必要な設定は次のとおりです。

- 「トークンの宛先ユーザーのマップ」の有効化

- 簡易ユーザー・マッピングの有効化

- データストア属性: 「uid」に設定

- 属性ベース・ユーザー・マッピングの無効化

図34-10 トークン・マッピング: username-wstrust-validation-template

「図34-10 トークン・マッピング: username-wstrust-validation-template」の説明

図34-11に、SSLクライアント証明書DN識別属性が一致するリクエスタ・パートナと証明書の「サブジェクトDN」を照合することでリクエスタ・パートナ・エントリにトークンをマップするためにセキュリティ・トークン・サービスに必要なマッピング構成設定を示します。必要な設定は次のとおりです。

- トークンの宛先パートナのマップ

- 簡易ユーザー・マッピングの無効化

- 属性ベース・ユーザー・マッピングの無効化

- 簡易パートナ・マッピングの有効化

図34-11 トークン・マッピング: x509-wss-validation-template

「図34-11 トークン・マッピング: x509-wss-validation-template」の説明

すべての要素がすべてのトークン・タイプおよびトークン・プロトコルに適用されるわけではありません。定義する必要がある要素は異なります。

表34-11に、検証テンプレートのトークン・マッピング要素を示します。

表34-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に含まれる属性の名前になります。
SAML検証テンプレートの「トークン・マッピング」セクションで、「ユーザー・トークン属性」は、ドロップダウンから選択する「名前ID」か、テキスト・フィールドに入力するSAML属性名のいずれかになります。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。
SAML検証テンプレートの「トークン・マッピング」セクションの「データストア属性」は、LDAPの一致問合せに使用されるディレクトリ属性の名前です。

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アサーションをユーザーにマップします。

有効な場合、セキュリティ・トークン・サービスでは名前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アサーションをユーザーにマップします。

有効な場合、セキュリティ・トークン・サービスでは名前IDフォーマットが評価され、パートナ識別属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるリクエスタ・パートナ識別属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の「追加」ボタンをクリックし、カスタムURIを入力します。

マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でリクエスタ・パートナ識別属性を設定します。

34.5.2 トークン検証テンプレートの管理

これはサーバー側の構成です。デフォルトの「トークン検証テンプレート」が存在します。有効な管理者の資格証明を持つユーザーは、この項の手順を使用して、トークン検証テンプレートを追加、検索、編集または削除できます。不要な手順はスキップしてください。

セキュリティ・トークン・サービス・エンドポイントを、次のものを示す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. 「テンプレートの検索」の説明に従って、目的のトークン検証テンプレートを見つけて開きます。

2. 新しいトークン検証テンプレート:

1. 右上隅の「新規検証テンプレート」ボタンをクリックします(または、「検索結果」表の上にある「追加」(+)コマンドをクリックします)。

2. 一般: このテンプレートのパラメータ(表34-9)を定義します。次に例を示します。
名前(ユーザー名トークン): email-wstrust-valid-temp
トークン・プロトコル(トークン・プロトコルのWS-Security): Webservice
トークン・タイプ(ユーザー名): email
デフォルト・パートナ・プロファイル: requester-profile

3. 認証: 必要に応じてこのテンプレートの資格証明検証を有効にし、詳細を示します(表34-10)。トークン・タイプがユーザー名の場合、必要に応じてこのテンプレートの資格証明検証を有効にし、詳細を示します。

4. トークン・マッピング: トークン・タイプに基づいてこのテンプレートのプリファレンスを指定します(表34-11)。

5. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

6. 定義を閉じます(またはステップ4の説明に従って定義を編集します)。

3. テンプレートの編集: 作成した保存済のページから編集を開始します。

1. 必要に応じてテンプレート定義を編集します。

2. ページの上部にある「適用」ボタンをクリックし、変更を送信します(または「元に戻す」をクリックして変更を取り消します)。

4. 新しいトークン検証テンプレートの削除:

1. 「検索結果」表の目的の名前をクリックし、削除する項目を選択します。

2. 「アクション」メニューの「削除」をクリックします(または、表の上にある「削除」(X)コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

34.6 セキュリティ・トークン・サービス・エンドポイントの管理

エンドポイントは、クライアントがSOAPを介してWS-Trustリクエストを送信できるセキュリティ・トークン・サービスによって公開されるWebサービスです。エンドポイントの特徴は次のとおりです。

- WS Securityポリシーで保護されます。

- セキュリティ・トークンの検証方法およびマップ方法を示すWSS検証テンプレートにバインドされます。

- トークン・タイプ、つまりWSS検証テンプレートで指定したタイプに固有です。

注意:

エンドポイントを保護するWS-Securityポリシーは、エンドポイントにバインドされたWSS検証テンプレートと互換性があることが必要です。

エンドポイントは、セキュリティ・トークン・サービスによって公開され、OWSMエージェントによって保護されるWebサービス・エンドポイントです。エンドポイントは次のものにバインドされます。

- メッセージ保護およびセキュリティ・トークンの観点からWSS要件を決定するWS-Securityポリシー。

- リクエストの処理方法およびセキュリティ・トークンの検証方法を示すWSS検証テンプレート。

この項の内容は次のとおりです。

- エンドポイントの管理について

- エンドポイントの管理

34.6.1 エンドポイントの管理について

図34-12に示すように、セキュリティ・トークン・サービス・エンドポイントの定義は3つのカテゴリで構成されています。

図34-12 「エンドポイント」ページ

「図34-12 「エンドポイント」ページ」の説明

表34-12に、エンドポイントに必要なカテゴリを示します。

表34-12 「エンドポイント」ページ

要素

説明

エンドポイントURI

エンドポイントへのパス。セキュリティ・トークン・サービスのベースURLと相対的です。セキュリティ・トークン・サービスのベースURLは/stsです。

ポリシーURI

Oracle WSMポリシーのリストから、このエンドポイントの保護に使用するものを選択します。

Oracle Access Management管理者は、使用可能リストに新しいカスタム・ポリシーを追加できます。新しく作成したポリシーURIをエンドポイント表リストで表示するには、次のwlstコマンドを使用してowsmpoliciesマップを更新します。

putStringProperty("/stsglobal/owsmpolicies/<index>", "<newcustom_policypath>)

次に例を示します。

putStringProperty("/stsglobal/owsmpolicies/31", "sts/newcustom_policy")

「検証テンプレート」のID

このエンドポイントで使用する名前を識別するために、検証テンプレート名のリストから選択します。

エンドポイントが作成されると、その削除は可能ですが、定義を編集することはできません。

34.6.2 エンドポイントの管理

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行してエンドポイントを追加、編集または削除できます。

前提条件

参照するトークン検証テンプレートの作成

エンドポイントを作成または削除する手順

1. 「Oracle Access Managementコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. エンドポイント・ノードを開いて、既存のエンドポイントのリストを表示します。

3. 新規エンドポイント: 表34-12を参照してください。

1. 表の上にある「追加」(+)ボタンをクリックします(または「アクション」メニューから「新規エンドポイント」を選択します)。

2. 新しい「エンドポイントURI」を入力します。

3. このエンドポイントを保護するOracle WSMポリシーの1つを選択します。

4. このエンドポイントで使用する「検証テンプレート」を選択します。

5. 「適用」をクリックし、定義を送信して確認ウィンドウを閉じます(または「元に戻す」をクリックし、定義を送信せずにページを閉じます)。

6. ページを閉じます。

4. エンドポイントの削除:

1. 「エンドポイント」表の行を強調表示し、「削除」(X)ボタンをクリックします(または「アクション」メニューから「選択項目の削除」を選択します)。

2. 削除を確認します(または削除を取り消します)。

34.7 トークン発行ポリシー、条件およびルールの管理

ここでは、次の内容について説明します。

- トークン発行ポリシーについて

- トークン発行条件およびルールの管理について

- トークン発行ポリシーおよび条件の管理

34.7.1 トークン発行ポリシーについて

トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してトークンを発行する際に従うルールを定義します。リクエスタが存在しない場合、(on-behalf-of (OBO)トークンまたはWSSトークンで表される)ユーザーがリライイング・パーティにアクセスしようとしていると想定されます。

トークンを発行する場合、セキュリティ・トークン・サービスはそのトークンが作成されるリライイング・パーティを判断し、クライアントがそのリライイング・パーティへのトークンのリクエストを認可されているかどうかを評価します。トークンを発行するために、操作に含まれるリソース、および場合によっては条件を使用してトークン発行ポリシーを作成する必要があります。実行時にポリシー評価が成功すると、トークンが発行されます。

このトークン発行ポリシーに、条件、ルールおよびレスポンスを追加できます。

34.7.2 トークン発行条件およびルールの管理について

トークン発行ポリシーを使用すると、管理者はポリシーの「許可」および「拒否」ルールとともに条件を定義できます。各トークン発行ポリシーには、1つ以上の条件に加え、リクエストしたリソースへのアクセスを付与または拒否するかどうかを決定するルールを含めることができます。

- 保護されたリソースへのアクセスを認可されるユーザーを指定する許可タイプのルール。
「条件」にリストされているパートナおよびユーザーのみがアクセス権を付与され、他のユーザーはリソースへのアクセスを拒否されます。

- 保護されたリソースへのアクセスを拒否されるユーザーを明示的に指定する拒否タイプのルール。
「条件」にリストされているパートナおよびユーザーのみがアクセスを拒否され、他のユーザーはリソースへのアクセス権を付与されます。

注意:

ユーザー条件を追加すると、ユーザーが選択に使用できるアイデンティティ・ストアがリストから選択されます。デフォルトのユーザー・アイデンティティ・ストアを選択したことを確認します。これは、セキュリティ・トークン・サービスでのみ使用されるアイデンティティ・ストアです。

トークン発行条件の管理は、認可条件とルールの管理に似ています。図34-4には、「トークン発行ポリシー」の「条件」タブが示されています。

Figure 34-13 「トークン発行ポリシー」および「条件」

「図34-13 トークン発行ポリシーおよび条件」の説明

表34-13に、トークン発行条件の要件を示します。

関連項目:

第IX部「Oracle Access Management Mobile and Socialの管理」: Mobile and Social認証サービスのトークン発行ポリシー追加の詳細

表34-13 「条件」タブ: トークン発行ポリシー

要素

説明

「サマリー」タブ

名前

このトークン発行ポリシーの一意の名前。

説明

オプション。

「条件」タブ

表17-18は、「条件」タブの要素およびコントロールを示しています。

クラス

トークン発行ポリシー条件にはトークン・リクエスタ・アイデンティティのみ許可されています。これは「条件の追加」ダイアログ・ボックスで選択します。

「ルール」タブ

表17-29は、簡易モードの評価の「ルール」タブに表示される要素およびコントロールを示しています。

表17-30は、式モードの「ルール」タブに表示される要素を示しています。

条件詳細

追加

次の移入から選択します。

- アイデンティティの追加: 選択すると「検索」ウィンドウが開き、「ストア名」を設定できます。「エンティティ・タイプ」(「すべて」、「ユーザー」または「グループ」)を選択し、「エンティティ名」を指定します。その後、リストされた結果から1つ以上を選択し、「選択済の追加」をクリックして条件を移入します。

- パートナの追加: 選択すると、条件を移入する特定のパートナを検索できる「検索」ウィンドウが開きます。検索条件を入力(または、すべてのパートナを検索する場合はフィールドの横の矢印キーをクリック)した後、1つ以上の結果を選択し、「選択済の追加」をクリックして条件を移入します。

エンティティ名

選択した「ユーザー・アイデンティティ・ストア」に定義されている、ユーザーまたはグループの名前。

エンティティ・タイプ

条件にアイデンティティを追加するために検索中に検索するエンティティのタイプ: 「ユーザー」または「グループ」

ストア名

条件を移入するユーザーまたはグループを検索する、「ユーザー・アイデンティティ・ストア」の名前を選択します。セキュリティ・トークン・サービスではデフォルトのアイデンティティ・ストアのみを使用することに注意してください。

34.7.3 トークン発行ポリシーおよび条件の管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用してトークン発行ポリシーおよび条件をアプリケーション・ドメインに追加できます。このポリシーにリソースを追加するときに、UnknownRPおよびMissingRPリソースを追加できます。

前提条件

アプリケーション・ドメインがすでに存在する必要があります。

注意:

IAM Suiteアプリケーション・ドメインにトークン発行ポリシーを追加できます。

トークン発行ポリシーおよび条件を管理するには

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. 個々の「アプリケーション・ドメイン」ページで、「トークン発行ポリシー」タブをクリックします。

3. トークン発行ポリシーの作成:

1. 目的のドメインで、「トークン発行ポリシー」タブをクリックし、「トークン発行ポリシーの作成」ボタンをクリックして新しいページを開きます。

2. 「サマリー」ページで、一意の名前とオプションの説明を入力します。

4. リソースの追加: この手順では、アプリケーション・ドメインでリソースが定義されており、ポリシーへの追加準備ができていることを仮定しています。

1. 「リソース」タブをクリックします。

2. 「追加」(+)ボタンをクリックします。

3. 「検索」ボタンをクリックして、追加可能な定義済リソースのリストを表示します。

4. 結果の表内で目的のリソースをクリックし、「選択済の追加」をクリックします。

5. 必要に応じて手順を繰り返して、他のリソースをこのポリシーに追加します。

5. ポリシーへの条件の追加: 使用可能なタイプは、「トークン・リクエスタ・アイデンティティ」または「True」のみです。

1. 「条件」タブ→「条件」タブの「追加」ボタンをクリックして、「条件の追加」ウィンドウを表示します。

2. ダイアログ・ボックスにこの条件の一意の名前を入力します。

3. 「タイプ」リストから「トークン・リクエスタ・アイデンティティ」を選択します。

4. 「選択済の追加」をクリックします。

5. 手順5に進んで、トークン・リクエスタ・アイデンティティの詳細を追加します。それ以外の場合は、手順6に進みます。

6. 条件詳細の追加:

1. 条件名をクリックして、「条件: 詳細」を表示します。

2. 「選択したアイデンティティ」表で、「追加」ボタンをクリックして、次のいずれかを選択します。
パートナの追加: 「検索」フィールドに基準を入力(または、すべてのパートナを検索する場合はフィールドの横の矢印キーをクリック)した後、1つ以上の結果を選択し、「選択済の追加」をクリックして条件を移入します。

アイデンティティの追加: 「ストア名」→目的の「アイデンティティ・タイプ」を選択し、検索基準を入力して「検索」ボタンをクリックし、1つ以上の結果を選択して、「選択済の追加」をクリックして条件を移入します。

3. 「条件: 詳細」パネルで「保存」ボタンをクリックします。

7. ルールの追加: 次の手順に従って、条件に基づいてアクセスを許可または拒否します。

1. 「ルール」タブをクリックします。

2. 「ルール・モード」のチェック: 「簡易」または「式」を選択します。

3. 「式」モード: 演算子を入力し(表17-31)、条件を選択および挿入することで(表17-30)、式を作成します。

4. 「簡易」モード: これをクリックして、「選択したすべての条件」または「選択したいずれかの条件」を一致させるように指定し、「ルールの許可」(または「ルールの拒否」)の矢印を使用して、目的の条件を「使用可能な条件」列から「選択した条件」列に移動します。

8. 「適用」をクリックして、確認ウィンドウを閉じます。

9. アプリケーション・ドメイン内のTokenServiceRPリソースの検索(または追加): 「TokenServiceRPタイプのリソースの管理」を参照してください。

34.8 TokenServiceRPタイプのリソースの管理

トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してトークンを発行する際に従うルールを定義します。

トークンを発行する場合、セキュリティ・トークン・サービスはそのトークンが作成されるリライイング・パーティを判断し、クライアントがそのリライイング・パーティへのトークンのリクエストを認可されているかどうかを評価します。

注意:

トークンを発行するために、操作に含まれるリソース、および場合によっては条件を使用してトークン発行ポリシーを作成する必要があります。実行時にポリシー評価が成功すると、トークンが発行されます。

ポリシー内のリソースには次のものがあります。

- TokenServiceRPタイプのリソースは、(Mobile and Social RESTクライアントで必要とされる)トークン・サービス・リライイング・パーティのためのリソースを表し、トークン・サービス・リライイング・パーティをベースとしています。

関連項目:

第IX部「Oracle Access Management Mobile and Socialの管理」: Mobile and Social認証サービスのためのAccess Managerの構成の詳細

- 既存のUnknownRPリソース。セキュリティ・トークン・サービスで、WS-TrustリクエストのAppliesTo要素で参照されるサービスURLをセキュリティ・トークン・サービスのリライイング・パーティ・パートナ・エントリにマップできない場合に必要なリソースです。

- 既存のMissingRPリソース。WS-TrustリクエストのAppliesTo要素が存在しない場合に必要なリソースです。

注意:

MissingRPとUnknownRPはどちらもIAM Suiteアプリケーション・ドメインに定義されています。

TokenServiceRPタイプのリソース(図34-14)は、セキュリティ・トークン・サービス・パートナ・ストアに定義されているセキュリティ・トークン・サービスのリライイング・パーティ・パートナを表します。

図34-14 事前定義されたリソース・タイプ: TokenServiceRP

「図34-14 事前定義されたリソース・タイプ: TokenServiceRP」の説明

TokenServiceRPタイプのリソースはトークン発行ポリシーで使用されます。このポリシーは、セキュリティ・トークン・サービスが実行時にトークンを発行するときに評価されます。これは、削除できない事前定義リソース・タイプです。ただし、必要に応じて、追加の操作を作成、編集または削除できます。事前定義された操作はロック・アイコンで示されています。

詳細は、次を参照してください。

- Access Manager内のTokenServiceRPタイプのリソースの管理について

- アプリケーション・ドメイン内のTokenServiceRPタイプのリソースの管理

34.8.1 Access Manager内のTokenServiceRPタイプのリソースの管理について

ドメイン内の特定のタイプのリソースを検索するには、アプリケーション・ドメインの検索コントロールを使用します。図34-15に、IAM Suiteリソースの検索コントロールを示します。リソース・タイプTokenServiceRPは検索条件です。「検索結果」表に、アプリケーション・ドメイン内のこのタイプのリソースをすべてリストします。

図34-15 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP

「図34-15 検索: アプリケーション・ドメイン内のリソース・タイプTokenServiceRP」の説明

このドメイン内のTokenServiceRPリソースには、前述のとおり、即時利用可能な状態で提供されるリソースが含まれています。

- UnknownRPリソース

- MissingRPリソース

34.8.2 アプリケーション・ドメイン内のTokenServiceRPタイプのリソースの管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用してTokenServiceRPリソースをアプリケーション・ドメインに追加できます。

注意:

- RSTにAppliesToが存在し、リクエスタをマップできなかった場合は、TokenServiceRP:UnknownRPリソースを使用します。

- AppliesToが存在しない場合は、TokenServiceRP:MissingRPを使用し、それ以外の場合は該当するリソースを選択します。

関連項目:

Access Manager内のTokenServiceRPタイプのリソースの管理について

TokenServiceRPリソースを管理する手順

1. 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。

2. アプリケーション・ドメインへのTokenServiceRPリソースの追加:

1. アプリケーション・ドメインの「検索」ページの「新規リソース」ボタンをクリックします。

2. 「リソース・タイプ」を「TokenServiceRP」と指定します。

3. トークン発行ポリシーが定義されるリライイング・パーティIDである「リソースURL」を入力します。

4. ページの上部にある「適用」ボタンをクリックし、これを送信して確認ウィンドウを閉じます。

5. 「アプリケーション・ドメインのリソースの定義」も参照してください。

3. TokenServiceRPリソースの検索:

1. 目的のアプリケーション・ドメインで、「リソース」タブを開いて検索コントロールを表示します。

2. 「リソース・タイプ」から「TokenServiceRP」を選択し、「検索」をクリックします。

3. 「検索結果」表を確認し、名前をクリックしてリソース定義を開きます。

34.9 カスタム・クラスを使用可能にする

セキュリティ・トークン・サービスに設定せずに検証や発行に使用できるトークンが含まれていない場合には、開発者はカスタムの検証および発行モジュール・クラスを記述できます。この項では、コンソールを使用してカスタム・クラスを使用できるようにする方法を説明します。

ここに記載した情報は、次のものがある場合に適用されます。

- WS-Securityユーザー名トークン

- WS-Trustカスタム・トークン

- 発行中のカスタム・トークン

注意:

コンソールを介して実行できる操作のWebLogic Scripting Toolコマンドが含まれるスクリプトも記述できます。手順は、Oracle Fusion Middleware WebLogicスクリプト・ツール・コマンド・リファレンスを参照してください。

この項の内容は次のとおりです。

- クラスを使用可能にする処理について

- カスタム・トークンの検索範囲の絞込みについて

- カスタム・トークンの管理

34.9.1 クラスを使用可能にする処理について

カスタム・トークンの検証または発行クラス(あるいはその両方)を記述した後、セキュリティ・トークン・サービスにカスタム・トークン構成を追加して、これらのクラスを使用するケースと使用方法を指定する必要があります。

図34-16に示すように、新規カスタム・トークン・ページでは、「トークン・タイプ名」のみ必須です(アスタリスク*で識別)。すべての要素がすべてのカスタム・トークンに適用されるわけではありません。ただし、不完全な情報を送信した場合、不足内容を示すダイアログ・ボックスが表示されます。

図34-16 新規カスタム・トークン・ページ

新規カスタム・トークン詳細を正常に送信した後、保存されたページは図34-17に示すように編集できます。

図34-17 カスタム・トークン定義: 電子メール

カスタム・トークンについては、XML要素名、XML要素のネームスペース、バイナリ・セキュリティ・トークン・タイプなどを決定する必要があります。表34-14では、この章の例に基づくカスタム・トークン・ページの要素について説明します。

表34-14 新規カスタム・トークン要素

要素

説明

トークン・タイプ名

このカスタム・トークンについて選択する一意の名前。次に例を示します。

email_token

注意: 新規カスタム・トークン構成を保存した後は、この名前は編集できません。

デフォルト・トークンURI

このカスタム・トークンのURI。このURIをRSTで使用し、このタイプのカスタム・トークンを発行する必要があることをリクエストできます。この章の例の場合、値は次のようになります。

oracle.security.fed.sts.customtoken.email

XML要素名

ユーザーが決定する名前であり、トークン・タイプ名に関連付けられます。次に例を示します。

email

XML要素名としてemailを指定した場合、要素名emailが着信トークンに表示されるたび、トークン・タイプ名に関連付けられます(この場合はemail_token)。

注意: 少なくともXML要素名またはバイナリ・セキュリティ・トークン・タイプのいずれかが必要です。

検証クラス名

セキュリティ・トークン・サービスで使用できるようにしたカスタム・トークン検証クラスの名前。次に例を示します。

oracle.security.fed.sts.tpe.providers.email.EmailTokenValidatorModuleImpl

注意: カスタム・トークンを発行するか検証するかに応じて、少なくとも発行クラス名または検証クラス名のいずれかが必要です。

XML要素のネームスペース

カスタム・トークン要素名のネームスペース。次に例を示します。

http://email.example.com

発行クラス名

セキュリティ・トークン・サービスで使用できるようにしたカスタム・トークン発行クラスの名前。次に例を示します。

oracle.security.fed.sts.tpe.providers.email.EmailTokenIssuerModuleImpl

注意: カスタム・トークンを発行するか検証するかに応じて、少なくとも発行クラス名または検証クラス名のいずれかが必要です。

バイナリ・セキュリティ・トークン・タイプ

BinarySecurityTokenとして送信されたカスタム・トークンをクラスで検証できるようにします。

このカスタム・トークンのBinarySecurityTokenのValueType。セキュリティ・トークン・サービスがこのValueTypeのバイナリ・セキュリティ・トークンを受け取った場合、検証のためにこのカスタム・トークンの検証クラスに転送されます。

検証属性

この項では、検証属性を追加(または削除)できます。既存の検証属性が表に表示されます(ある場合)。この例では、次のように指定します。

- 属性名: testsetting

- 属性タイプ: String

注意: トークン検証テンプレートの作成時に、属性に値を追加します。

発行属性

この項では、発行属性を追加(または削除)できます。既存の発行属性に関する次の情報が表に表示されます。

- 属性名: testsetting

- 属性タイプ: String

注意: トークン発行テンプレートの作成時に、属性に値を追加します。

保存

構成情報を保存するには、新規カスタム・トークン・ページでこのボタンをクリックします。

取消

構成詳細を閉じるには、このボタンをクリックします。

適用

変更内容を送信するには、このボタンをクリックします。

元に戻す

変更内容を取り消すには、このボタンをクリックします。

タスク概要: カスタム・クラスのカスタム・トークンの追加

1. カスタムTokenIssuerModuleまたはTokenValidatorModuleクラス(あるいはその両方)のみが含まれるJARファイルを作成します。XMLメタデータもマニフェストも必要ありません。

2. 図34-17および表34-14の情報を確認します。

3. 第34.9.3項「カスタム・トークンの管理」で説明するように、セキュリティ・トークン・サービスをホストするOAMサーバーにJARを追加し、新規カスタム・トークンを作成します。

34.9.2 カスタム・トークンの検索範囲の絞込みについて

図34-18では、カスタム・トークン検索コントロールおよび結果表を示しています。これらは、ナビゲーション・ツリーでカスタム・トークン・ノードをダブルクリックすると表示されます。デフォルトでは、「検索結果」表が表示されると、現在定義されているすべてのカスタム・トークンがリストされます。

図34-18 カスタム・トークン検索ページおよびコントロール

表34-15では、カスタム・トークン検索要素およびコントロールについて説明します。カスタム・トークン検索では、ワイルド・カード(*)は使用できません。

表34-15 カスタム・トークン検索要素およびコントロール

要素

説明

デフォルト・トークンURI

カスタム・トークンに対して定義されたURI。URI全体またはその一部のみを入力できます。たとえば、「ai」と入力した場合、「検索結果」表には、文字「ai」が含まれるトークンURIで定義されたすべてのカスタム・トークンが表示されます。

注意: カスタム・トークン検索では、ワイルド・カードは使用できません。

検索

フォームで指定された基準を使用して検索機能が開始されます。

リセット

デフォルトのみで「検索」フォームをリセットします。

検索結果

「表示」メニューの選択内容に基づいて、検索結果が表示されます。

「アクション」メニュー

結果表の選択項目で実行できる次の機能を提供します。

注意: 「アクション」メニューの機能は、結果表の上のコマンド・ボタンをミラー化します。次に例を示します。

- 新規カスタム・トークン: 検索ページ上部の「新規カスタム・トークン」ボタンをクリックするか、メニューから「新規カスタム・トークン」を選択するか、または表の上の「+」ボタンをクリックします。

- 編集: 「検索結果」表の「トークン・タイプ名」列で名前をダブルクリックするか、「アクション」メニューから「編集」を選択するか、結果表の上の編集(鉛筆アイコン)コマンド・ボタンをクリックします。

- 類似作成: 表の目的の行を選択し、「アクション」メニューから「類似作成」を選択するか、表の上にある「類似作成」コマンド・ボタンをクリックします。

- 削除: 表内の目的の行を選択して、「アクション」メニューから「削除」を選択するか、表の上の削除「X」コマンド・ボタンをクリックします。

「表示」メニュー

結果表に各種情報を表示するために使用できる機能を提供します。

結果表にリストされるアイテムの順序に影響するコントロール:

- 昇順

- 降順

34.9.3 カスタム・トークンの管理

有効な管理者資格証明を持つユーザーは、この項の手順を使用して、カスタム・トークン・モジュール・クラスのカスタム・トークンを管理できます。

次の手順には、カスタム・トークンまたはカスタム・トークンの属性を追加、編集および削除するステップが含まれます。不要な手順はスキップしてください。

前提条件

次の詳細は、カスタム・トークンを作成する開発者およびOracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

TokenValidatorModuleクラスの記述

TokenIssuanceModuleクラスの記述

関連項目:

- 「カスタム・クラスを使用可能にする」

- 「カスタム・トークンの検索範囲の絞込みについて」

カスタム・クラスを使用できるようにする手順は、次のとおりです。

1. 次のいずれかの方法を使用して、発行および検証クラスが含まれるJARを作成し、セキュリティ・トークン・サービスをホストするOAMサーバーに追加します。

- 起動スクリプトを編集することで、カスタム・トークンjarおよびDOMAIN_HOME/config/fmwconfig/mbeans/oamにあるsts-common.jarを、管理対象サーバーのクラスパスに追加します。

- カスタム・トークンjarおよびDOMAIN_HOME/config/fmwconfig/mbeans/oamにあるsts-common.jarを、DOMAIN_HOME/libディレクトリに追加し、管理対象サーバーのクラスパスにこれらのjarを自動的に追加します。

- OAMサーバーを再起動します。

2. 新規カスタム・トークン: Oracle Access Managementコンソールの「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開き、次のようにします。

1. 「カスタム・トークン」ノードを開き、検索コントロールを開きます。

2. 「新規カスタム・トークン」ボタンをクリックします。

3. 「新規カスタム・トークン」ページにカスタム・クラスの詳細を入力します(表34-14)。

4. 「保存」をクリックし、確認ウィンドウを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

5. ページを閉じます(またはステップ4のとおりに編集します)。

6. 必要に応じてステップ4または「セキュリティ・トークン・サービス・カスタム構成の管理」に進みます。

3. カスタム・トークンの検索: 「システム構成」タブの「セキュリティ・トークン・サービス」セクション:

1. すべて検索: 「検索」ボタンをクリックし、カスタム・トークンがすべてリストされた結果表を表示します。

2. 検索の絞込み: 目的のデフォルト・トークンURIに一部またはすべての文字を入力し、「検索」ボタンをクリックして、結果表を確認します。

3. 検索フォームのリセット: 「リセット」ボタンをクリックします。

4. カスタム・トークン構成の編集: 作成した保存済ページから開始します。
代替手段: ステップ3を使用して目的のカスタム・トークンを検索してから、「検索結果」表で名前をダブルクリックし、ページを開きます。

1. 指定されたカスタム・トークン・ページで、該当するフィールドをクリックし、必要に応じて編集します。

2. 属性の追加: 「属性」表の追加「+」アイコンをクリックし、属性名および属性タイプを入力します(表34-14)。

3. 属性の削除: 「属性」表から、削除する属性が含まれる行をクリックし、表の削除「X」アイコンをクリックし、「確認」ウィンドウを閉じます。

4. 変更内容の適用: ページ上部の「適用」ボタンをクリックし、変更内容を送信します。

5. カスタム・トークンの削除:

1. 「検索結果」表の目的の名前をクリックし、削除する項目を選択します。

2. 「アクション」メニューの「削除」をクリックします(または、表の上にある「削除」(X)コマンド・ボタンをクリックします)。

3. 「確認」ウィンドウで「削除」ボタンをクリックします(または「いいえ」をクリックして操作を取り消します)。

34.10 セキュリティ・トークン・サービス・カスタム構成の管理

このタスクは、次の手順で構成されます。

- 検証テンプレートの作成

- カスタム・トークンの発行テンプレートの作成

- カスタム・トークンをリクエスタ・プロファイルに追加

- カスタム・トークンをリライイング・パーティ・プロファイルに追加

- トークンをリクエスタにマップ

- /wssuserエンドポイントの作成

34.10.1 検証テンプレートの作成

有効なOracle Access Management管理者資格証明を持つユーザーは、次のタスクを実行して、Webservice Trustのトークン・プロトコルを含む検証テンプレートを作成し、トークンをリクエスタにマップできます。

この例のテンプレートは、この章で前述したモジュール・クラスに使用できます。次の各図では、実装の完全な詳細を示しています。これらを確認する際に、このテンプレートの仕様がモジュール・クラス・コードを参照する仕組みに注意してください。

- 図34-19「一般的な詳細: email-wstrust-valid-temp」

- 図34-20「トークン・マッピング: email-wstrust-valid-temp」

図34-19 一般的な詳細: email-wstrust-valid-temp

図34-20 トークン・マッピング: email-wstrust-valid-temp

カスタム・モジュール・クラスの検証テンプレートを作成する手順は、次のとおりです。

1. 既存のトークン検証テンプレートのリストを表示します。
Oracle Access Managementコンソール
システム構成
セキュリティ・トークン・サービス
トークン検証テンプレート

2. 右上隅の「新規検証テンプレート」ボタンをクリックします(または、「検索結果」表の上にある「追加」(+)コマンドをクリックします)。

3. 一般: カスタム・トークンで使用する次のものを設定します。
検証テンプレート名: email-wstrust-valid-temp

トークン・プロトコル: Webservice Trust

トークン・タイプ: email

デフォルト・パートナ・プロファイル: requester-profile

カスタム検証属性: testsetting: hello

4. トークン・マッピング: この章でカスタム・トークンに使用する次のものを設定します。
「トークンの宛先ユーザーのマップ」の隣のボックスを選択します(有効化)。

「簡易ユーザー・マッピングの有効化」の隣のボックスを選択し、次を入力します。

ユーザー・トークン属性: STS_SUBJECT_ID
データストア属性: mail

5. 「保存」をクリックし、「確認」ウィンドウを閉じます。

6. 「カスタム・トークンの発行テンプレートの作成」に進みます。

34.10.2 カスタム・トークンの発行テンプレートの作成

これはサーバー側の構成です。有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行してトークン発行テンプレートを作成できます。

各トークン発行テンプレートは、トークンの構成方法およびトークン構成時に使用する署名または暗号化を示します。また、各トークン発行テンプレートは、データのマッピングおよびフィルタ処理のためにアウトバウンド・トークンの一部として送信される属性を定義します。ただし、発行テンプレートには、リライイング・パーティ・パートナ・プロファイルで定義されたマッピングまたはフィルタ処理ルールはリストされません。

この例のテンプレートは、この章で前述した電子メール・カスタム・トークンに使用できます。実装の詳細を次の各図に示しており、付け加えられた手順で説明しています。これらを確認する際に、このテンプレートの仕様がモジュール・クラス・コードを参照する仕組みに注意してください。

- 図34-21「一般的な詳細: email-issuance-temp」

- 図34-22「発行プロパティ: email-issuance-temp」

図34-21 一般的な詳細: email-issuance-temp

カスタム・トークン・タイプをデプロイした場合、発行プロパティはカスタム・トークンにあわせて調整されます。たとえば、図34-22に示した発行テンプレートでは、カスタム電子メール・トークン・タイプが選択されています。

図34-22 発行プロパティ: email-issuance-temp

この手順では、この章のカスタム・モジュール・クラスのコンパニオン発行テンプレートを生成します。この例の場合、次のようになります。

- カスタム・トークンタイプ: 電子メールでは使用されないトークン暗号化アルゴリズムは無視します。

- カスタム・トークン・コードから移入されるカスタム・トークン属性の値を入力します。

関連項目:

Oracle Fusion Middleware Oracle Access Management管理者ガイド

カスタム・モジュール・クラスの発行テンプレートを作成する手順は、次のとおりです。

1. 既存のトークン発行テンプレートを検索します。
システム構成
セキュリティ・トークン・サービス
トークン発行テンプレート
「検索」ボタン(検索基準を入力したかどうかに関係なく)

2. 新しいトークン発行テンプレート:

1. 右上隅の「新規発行テンプレート」ボタンをクリックします(または、「検索結果」表の上にある「追加」(+)コマンドをクリックします)。

2. 一般: この章でカスタム・トークンに使用する次のものを設定します。
発行テンプレート名: email-issuance-temp
トークン・タイプ: email

3. 「保存」をクリックし、確認ウィンドウを閉じます(または保存せずに「取消」をクリックします)。

4. 発行プロパティ: この章でカスタム・トークンに使用する次のものを設定します。
カスタム・トークン属性値: world

5. 「適用」をクリックし、確認ウィンドウを閉じます(または保存せずに「元に戻す」をクリックします)。

6. 定義を閉じます(またはステップ4の説明に従って定義を編集します)。

3. テンプレートの編集: 目的のテンプレートを見つけて、詳細を編集し、「適用」をクリックします。
または、ステップ3を使用して目的のテンプレートを検索し、「検索結果」表の名前をクリックして定義を表示します。

34.10.3 カスタム・トークンをリクエスタ・プロファイルに追加

既存のリクエスタ・プロファイルを編集してカスタム・トークンを「トークン・タイプ構成」表に追加するか、新規リクエスタ・プロファイルを作成してカスタム・トークンで使用できます。どちらの方法も、次を構成します。

- トークン・タイプ: email (カスタム・トークン)

- 検証テンプレート: email-wstrust-valid-temp

前提条件

カスタム・トークンおよび検証テンプレートを定義する必要があります。

カスタム・トークンのリクエスタ・プロファイルを作成または編集する手順は、次のとおりです。

1. 「Oracle Access Managementコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. ナビゲーション・ツリーで、パートナ・プロファイル・ノードを開き、リクエスタ・プロファイル・ノードをダブルクリックして既存のプロファイルのリストを表示します。

3. 既存のプロファイル:

1. リクエスタ・プロファイル・ページの「検索結果」表で、目的のプロファイルの名前をクリックします。

2. トークンと属性: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「保存」ボタンをクリックします。
トークン・タイプ: email
検証テンプレート: email-wstrust-valid-temp

3. 「保存」をクリックし、確認ウィンドウを閉じてページを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

4. 「カスタム・トークンをリクエスタ・プロファイルに追加」に進みます。

4. 新規プロファイル: 「新規リクエスタ・プロファイル」ボタンをクリックし、詳細を入力する新規パートナ・プロファイル・ページを表示します。

1. 一般: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「次」ボタンをクリックします。
プロファイルID: unique_requesterprofile_name
デフォルト・リライイング・パーティ・プロファイル: unique_relyingparty_name

2. トークン・タイプ構成の追加: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「保存」ボタンをクリックします。
トークン・タイプ: email
検証テンプレート: email-wstrust-valid-temp

3. 「カスタム・トークンをリクエスタ・プロファイルに追加」に進みます。

34.10.4 カスタム・トークンをリライイング・パーティ・プロファイルに追加

既存のリライイング・パーティ・プロファイルを編集するか、デフォルトでカスタム・トークンを発行するプロファイルを新規作成し、発行テンプレートおよび関連情報を参照できます。どちらの方法も、次を構成します。

- 発行するデフォルト・トークン: email (カスタム・トークン)

- 発行テンプレート: email-issuance-temp

前提条件

カスタム・トークンおよび発行テンプレートを定義する必要があります。

カスタム・モジュール・クラスのリクエスタ・プロファイルを編集する手順は、次のとおりです。

1. 「Oracle Access Managementコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. ナビゲーション・ツリーで、パートナ・プロファイル・ノードを開き、リライイング・パーティ・プロファイル・ノードをダブルクリックして既存のプロファイルのリストを表示します。

3. 既存のプロファイル:

1. リライイング・パーティ・プロファイル・ページの「検索結果」表で、目的のプロファイルの名前をクリックします。

2. 「トークンと属性」タブをクリックします。

3. トークン・タイプ構成: 「トークン・タイプ構成」表の上の追加「+」ボタンをクリックし、次の詳細を入力します。
トークン・タイプ: email
発行テンプレート: email-issuance-temp

4. 属性: 「属性」表の上の追加「+」ボタンをクリックし、次の内容を定義します。
属性名: mail
ストア・タイプ: Userstore
トークンに含める: (check to enable)
暗号化(空のまま)
値(空のまま)

5. 「適用」をクリックし、確認ウィンドウを閉じてページを閉じます(または「取消」をクリックし、送信せずにページを閉じます)。

4. 新規プロファイル: 「新規リライング・パーティ・プロファイル」ボタンをクリックし、詳細を入力する新規パートナ・プロファイル・ページを表示します。

1. 一般: この章のカスタム・トークンについて次の詳細を入力し、ページ上部の「次」ボタンをクリックします。
プロファイルID: unique_relyingparty-name
デフォルト・トークン: email

2. 「トークンと属性」タブをクリックし、ステップ2cおよび2dを実行してから「適用」をクリックします。

34.10.5 トークンをリクエスタにマップ

ユーザー名検証テンプレート(username-wss-valid-template)がない場合、Oracle Access Managementコンソールを使用して、トークンをリスナーにマップするテンプレートを作成します。

検証テンプレート名: username-wss-valid-template

トークン・タイプ: ユーザー名

「/wssuserエンドポイントの作成」に進みます。

34.10.6 /wssuserエンドポイントの作成

前提条件

トークンをリクエスタにマップ

エンドポイントを作成する手順は、次のとおりです。

1. 「Oracle Access Managementコンソール」の「システム構成」タブから、「セキュリティ・トークン・サービス」セクションを開きます。

2. 「エンドポイント」ノードをダブルクリックして、既存のエンドポイントのリストを表示します。

3. 新規エンドポイント:

1. 表の上にある「追加」(+)ボタンをクリックします(または「アクション」メニューから「新規エンドポイント」を選択します)。

2. 新規エンドポイントURIを入力します(/wssuser)。

3. Oracle WSMポリシー(sts/wss_username_service_policy)を選択します。

4. 検証テンプレートを選択します(username-wss-validation-template)。

5. 「適用」をクリックし、定義を送信して確認ウィンドウを閉じます(または「元に戻す」をクリックし、定義を送信せずにページを閉じます)。

6. ページを閉じます。

35 Token Serviceパートナとパートナ・プロファイルの管理

この章には、Token Serviceパートナとパートナ・プロファイルの管理について説明する次のトピックが用意されています。

- 前提条件

- Token Serviceパートナとパートナ・プロファイルの概要

- Token Serviceパートナの管理

- Token Serviceパートナ・プロファイルの管理

35.1 前提条件

「Oracle Access Managementセキュリティ・トークン・サービスの概要」

第31章「セキュリティ・トークン・サービスの実装シナリオ」

Oracle Access Managementコンソールを使用して実行できるタスクは、次のものを使用して実行することもできます。

関連項目:

『Oracle Fusion Middleware WebLogic Scripting Tool Command Reference』

35.2 Token Serviceパートナとパートナ・プロファイルの概要

ここでは、次の内容について説明します。

- Token Serviceパートナについて

- パートナ・プロファイルについて

- パートナ・エントリについて

35.2.1 Token Serviceパートナについて

Token Serviceパートナは、セキュリティ・トークン・サービスで信頼されているパートナを表します。表35-1には、パートナ・タイプが説明されています。

表35-1 セキュリティ・トークン・サービス・パートナ

パートナ・タイプ

説明

リクエスタ

トークンを発行または検証するためにセキュリティ・トークン・サービスと直接相互作用するWebサービス・クライアントを表します。

リライイング・パーティ

セキュリティ・トークン・サービス・サーバーによって発行されるトークンの受信者になるWebサービス・プロバイダを示します。

発行局

アサーション発行者を表します。アサーションを検証する場合、発行者はセキュリティ・トークン・サービス内の既知の発行局パートナ・エントリであることが必要です。

セキュリティ・トークン・サービスでは、表35-2に示されたクライアント・タイプと相互作用できます。

表35-2 セキュリティ・トークン・サービス・クライアント

クライアントのタイプ

説明

Webサービス・クライアント

セキュリティ・トークン・サービス内のリクエスタ・パートナ(通常はSOAPクライアント)として定義されるモジュール。

エンド・ユーザー

エンド・ユーザーはリクエスタ・パートナとして定義されるのではなく、ユーザー・アイデンティティ・ストアに存在する可能性があります。

35.2.2 パートナ・プロファイルについて

パートナ・プロファイルには、パートナのセットに共通の構成プロパティが含まれており、各パートナ・エントリはパートナ・プロファイルに関連付けられます。パートナと同様に、パートナ・プロファイルには3つのタイプ(リクエスタおよび発行局パートナ・プロファイル)があります。

- リクエスタ・プロファイル

- リライイング・パーティ・プロファイル

- 発行局パートナ・プロファイル

35.2.2.1 パートナ・エントリについて

パートナ・エントリには表35-3の情報が含まれます。

表35-3 セキュリティ・トークン・サービス・パートナ・エントリ

パートナ・エントリ

説明

証明書

署名証明書と暗号化証明書

参照先

パートナ・プロファイルへの参照

リクエスタのみ

パートナがリクエスタの場合、パートナ・エントリにはユーザー名トークン資格証明に加え、着信データをリクエスタにマップするために使用されるID文字列も含まれます。

35.2.2.2 パートナ・プロファイル・データについて

パートナ・プロファイル・エントリには、プロファイルのタイプに応じて表35-4の情報が含まれます。

表35-4 セキュリティ・トークン・サービス・パートナ・プロファイルのデータ

クライアントのタイプ

説明

リクエスタ

- 要求マッピング

- OnBehalfOf要素に存在するトークンの検証に使用されるWS-Trust検証テンプレート

リライイング・パーティ

- RPに送信される属性

- 使用される発行テンプレート

発行局

- 属性名/値マッピングの設定

- パートナ/ユーザーへの着信トークンのマップに使用される特定のマッピング・アクション・ルール

35.3 Token Serviceパートナの管理

この項の内容は次のとおりです。

- Token Serviceパートナの管理について

- Token Serviceパートナの管理

- パートナ検索の絞込み

35.3.1 Token Serviceパートナの管理について

新しいパートナの作成を選択した場合、選択した特定のパートナ・タイプの新しいページが表示されます。図35-1に、「Oracle Access Managementコンソール」の「新規リクエスタ・パートナ」ページを示します。このページにはすべての「パートナ」要素が含まれます。

図35-1 「新規リクエスタ・パートナ」ページ

「図35-1 「新規リクエスタ・パートナ」ページ」の説明

ほとんどの要素(名前、説明およびこのパートナが信頼されているかどうか)はすべてのパートナに共通ですが、表35-5で説明されているとおり、特定の要素は特定のパートナ・タイプによって決まります。

表35-5 パートナ・タイプのパートナ要素

パートナ・タイプ

説明

リクエスタ・パートナ

暗号化証明書、署名証明書、トークン認証およびアイデンティティ属性を指定できます。

リライイング・パーティ・パートナ

暗号化証明書とリソースURLのみを指定できます。

図35-2を参照してください。

発行局パートナ

署名証明書のみを指定できます。

図35-2 「新規リライイング・パーティ・パートナ」ページ

表35-6に、セキュリティ・トークン・サービス・パートナの要素を示します。特に明記しないかぎり、すべての要素がすべてのパートナ・タイプに適用されます。

表35-6 セキュリティ・トークン・サービス・パートナの要素

要素

説明

パートナ名

このパートナの名前を入力します。

発行者ID

発行局のみ

SAMLアサーションの発行者フィールドで使用される、この発行局を示す一意の識別子。

パートナ・タイプ

編集不可の記述で、作成または編集しているパートナのタイプに応じて異なります。

- リクエスタ

- リライイング・パーティ

- 発行局

パートナ・プロファイル

リストされたプロファイルから選択して、選択するパートナを定義します。

説明

オプション。

信頼

パートナが信頼されているかどうかを示すには、このボックスを選択します。選択しない場合、セキュリティ・トークン・サービス・サーバーでは、リクエストにそのようなエントリが含まれるときにエラーが報告されません。

証明書のロード

要求された証明書を参照してアップロードしますが、これはパートナ・タイプによって異なります。

- 暗号化証明書と署名証明書

- 暗号化証明書

- 署名証明書

ユーザー名トークン認証

リクエスタのみ

ユーザー名トークン認証の次のものについて値を入力できます。

- ユーザー名

- パスワード

- パスワードの確認

新規リクエスタ・パートナのアイデンティティ属性を「セキュリティ・トークン・サービスの設定」セクションで定義し、リクエスタ・パートナの「アイデンティティ属性」表に表示できます。

注意: ユーザー名とパスワードのデータは、ユーザー名トークンの資格証明を検証するために使用されます。ユーザー名を使用したリクエスタ・パートナへの着信トークンのマップのみにデータが使用される場合、ユーザー名のみを入力し、パスワードを入力しないこともできます。

アイデンティティ属性

リクエスタのみ

実行時にセキュリティ・トークン・サービスでは、セクションに定義されたデータを使用して、着信リクエストをリクエスタ・パートナ・エントリにマップします。次のものが使用されます。

- SSLクライアント証明書のサブジェクトDN(存在する場合)、HTTP Basic認証ユーザー名などのトークン・データまたはバインディング・データ。

- 各リクエスタ・パートナ・エントリに存在するアイデンティティ属性。

新しいマッピングを「リライイング・パーティ・パートナ」セクションにhttp://relying.party.test.com/testing.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/です。

図35-3に、入力する「リクエスタ・パートナ」ページを示します。

図35-3 定義済のリクエスタ・パートナ

「図35-3 定義済のリクエスタ・パートナ」の説明

35.3.2 Token Serviceパートナの管理

有効な管理者の資格証明を持つユーザーは、次の手順に従って、Oracle Access Managementコンソールを使用してトークン・サービス・パートナを作成、検索、編集または削除できます。

前提条件

作成するパートナのタイプのパートナ・プロファイルを定義する必要があります。

Token Serviceパートナを管理する手順

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「セキュリティ・トークン・サービス」セクション
「パートナ」ノード

2. 「パートナ」ノードで、目的のパートナ・タイプをダブルクリックし、必要に応じて次の手順に進みます。

- リクエスタ

- リライイング・パーティ

- 発行局

3. 新規パートナ:

1. 新規パートナ・タイプボタンをクリックして、定義に使用する新しいページを表示します。

2. 選択したパートナ・タイプの一般情報(表35-6)を入力します。

3. 信頼: クリックして選択します(これが信頼できるパートナではない場合は、空白のままにします)。

4. 証明書: 必要な証明書をロードします。

5. リライイング・パーティ: 必要に応じてリソースURLを入力します。

6. 発行局: この発行局の発行者IDを入力します。

7. リクエスタ: 必要に応じてユーザー名トークン資格証明を入力します。

8. 「保存」をクリックして送信(または「取消」をクリックしてページを閉じます)し、確認ウィンドウを閉じます。

4. パートナ検索の絞込み: 「パートナ検索の絞込み」

1. ステップ1および2を実行します。

2. 問合せを定義し、「検索」ボタンをクリックします。

3. 「検索結果」表で、表示、編集または削除するパートナの名前をクリックします。

5. パートナの編集:

1. 「検索結果」表で、編集するパートナの名前をクリックし、「編集」ボタンをクリックします(または「アクション」メニューから「編集」を選択します)。

2. パートナ情報に必要な変更を加えます(表35-6)。

3. 「適用」をクリックして変更を送信(または「元に戻す」をクリックして変更を取り消します)し、確認ウィンドウを閉じます。

6. パートナの削除: 必要に応じて、検索コントロールを使用して問合せを絞り込んで送信します。

1. 「検索結果」表で、削除するパートナを含む行を強調表示します。

2. 「削除」(X)ボタンをクリック(または「アクション」メニューから「選択項目の削除」を選択します)し、確認ウィンドウを閉じます。

35.3.3 パートナ検索の絞込み

他のシステム構成コンポーネントと同様に、「パートナ」ノードを開くと、すべてのパートナ・タイプ・ノードが使用可能になります。特定の「パートナ」ノードを選択すると、関連する検索コントロールと「検索結果」表が使用可能になります。

図35-4にリクエスタ・パートナを示します。結果は他のパートナ・タイプの結果とは異なります。

図35-4 パートナの検索コントロール

「図35-4 パートナの検索コントロール」の説明

「検索」ページから「検索結果」表の名前を選択するか、コントロールを使用して検索を絞り込み、特定のパートナまたは特定の特性を持つパートナを検索します。

35.4 Token Serviceパートナ・プロファイルの管理

この項では、Token Serviceパートナ・プロファイルに関する情報を示します。

- パートナ・プロファイルの管理について

- Token Serviceパートナ・プロファイルの管理

- プロファイル検索の絞込み

35.4.1 パートナ・プロファイルの管理について

図35-5に、「一般」タブと「トークンと属性」タブの両方が表示されている、入力が完了した「リクエスタ・プロファイル」ページを示します。

図35-5 リクエスタ・プロファイル: 一般

「図35-5 リクエスタ・プロファイル: 一般」の説明

表35-7に、すべてのプロファイル・タイプの「一般」要素を示します。

表35-7 プロファイル: 一般

要素

説明

プロファイルID

このプロファイルに対する一意の識別子。

説明

オプション。

プロファイル・タイプ

プロファイルのタイプ(編集不可): 「リクエスタ」、「リライイング・パーティ」または「発行局」になります。

デフォルト・リライイング・パーティ・プロファイル

リクエスタ・パートナ・プロファイルのみ

WS-Trustリクエストがリライイング・パーティを参照しない(AppliesTo要素が存在しないなど)か、AppliesTo要素を既知のリライイング・パーティ・パートナ・プロファイルにマップできなかった場合、使用するリライイング・パートナ・プロファイルを参照します。

デフォルトとして使用するリライイング・パーティ・プロファイルを選択し、必要に応じて次の特性を有効または無効にします。

- 欠落している要求に対してエラーを返す
発行されたトークンにクライアントがリクエストした要求が含まれていない場合、セキュリティ・トークン・サービスはエラーを返します。

リライイング・パーティ・パートナ・プロファイルでは発行されたトークンに含めることができる属性/要求のリストが定義されるため、クライアントがリクエストした一部の要求が返されない可能性があります。

- マップされていない要求を許可
WS-Trustリクエストにリストされる要求は、「トークンと属性」セクションを使用してローカル属性にマップするために、翻訳される言語で指定されます。

このフラグは、翻訳できない要求をそのまま参照するかどうかを示します。これにより、クライアントによってリクエストされる要求を制御できます。

発行するデフォルト・トークン

リライイング・パーティのみ

この表は、このプロファイルにリンクされたリライイング・パーティのトークンの発行に使用する発行テンプレートを示します。

このプロファイルのデフォルトとしてトークン・タイプを選択します。

- SAML 1.1

- SAML 2.0

- ユーザー名

- カスタム

ポリシーをトークンに関連付けるには、「ポリシーのダウンロード」の横にあるボックスを選択します。選択した場合、セキュリティ・トークン・サービスでは実行時に、RST内のAppliesTo要素で参照されるリライイング・パーティのWS-Securityポリシーがダウンロードされます。存在する場合、セキュリティ・トークン・サービスではそのURLを使用してポリシーをダウンロードした後、ポリシーに存在する情報に基づいて返すトークンのタイプを決定します。

リクエスタ・プロファイル: トークンと属性

図35-6に、「トークンと属性」タブおよびリクエスタ・プロファイルに付随する表を示します。「トークン・タイプ構成」セクションは、トークン・タイプに基づいてWS-TrustリクエストのOnBelhalfOf要素に含まれるトークンの検証に使用するWS-Trust検証テンプレートを示します。このセクションでは、クライアントによってリクエストされるWS-Trust要求とローカル属性名の間のマッピングが定義されます。

図35-6 リクエスタ・プロファイル: トークンと属性

「図35-6 リクエスタ・プロファイル: トークンと属性」の説明

表35-8に、リクエスタ・プロファイルの「トークンと属性」要素およびコントロールを示します。

表35-8 リクエスタ・プロファイル: トークンと属性

要素

説明

トークン・タイプ構成

表の上の「+」をクリックして次のダイアログ・ボックスを表示した後、各リストから1つずつ選択します。

「トークン・タイプ」リストには、サポートされている(およびカスタム)デプロイ済のトークン・タイプがすべて表示されます。

「検証テンプレート」リストには、現在定義されているすべてのWS-Trust検証テンプレートが含まれています。

属性名マッピング

この表は、セキュリティ・トークン・サービスが名前およびオプションの「フォーマット/ネームスペース」で表される要求をローカル属性にマップする方法を定義します。

セキュリティ・トークン・サービスではInfocard要求言語がサポートされています。Infocard要求をローカル属性に変換するには、「着信属性」に要求名、「ローカル属性」にローカル名が含まれるマッピングを定義する必要があります(「フォーマット/ネームスペース」列は空になります)。

たとえば、あるマッピングは次のようになります。

- 着信属性: surname

- ローカル属性: sn

別のマッピングは次のようになります。

- 着信属性: givenname

- ローカル属性: givenname

別のマッピングは次のようになります。

- 着信属性: emailaddress

- ローカル属性: mail

リライイング・パーティ・プロファイル: トークンと属性

図35-7に、リライイング・パーティ・プロファイルに対して定義されている「トークンと属性」を示します。この項により、管理者はこのプロファイルに関連付けられたリライイング・パーティのトークンの発行に使用される発行テンプレートを定義できます。

また、発行済のトークンに含まれる属性(名前別)、その属性のソース、クライアントがリクエストした場合のみ属性を発行済トークンに含めるか、または常に含めるかもリストされます。

このページでは、リライイング・パーティ・プロファイルにはトークン・タイプ以外に発行テンプレートも必要です。また、属性タイプは他のプロファイルとは異なります。

図35-7 リライイング・パーティ・プロファイルの「トークンと属性」

「図35-7 リライイング・パーティ・プロファイルの「トークンと属性」」の説明

表35-9に、リライイング・パーティ・プロファイルに必要な要素を示します。

表35-9 リライイング・パーティ・プロファイルの要件

要素

説明

トークン・タイプ構成

表の上の「+」をクリックして次のダイアログ・ボックスを表示した後、各リストから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アサーションの認証方式を含みます。

発行局プロファイル: トークンと属性

発行局パートナ・プロファイルでは、異なる発行局パートナに共通の設定が定義されます。

図35-8に示すように、「トークンと属性」セクションを使用すると、管理者は属性の名前および値をローカル名および値に変換するために使用されるマッピング・ルールを定義できます。

図35-8 トークンと属性: 発行局

「図35-8 トークンと属性: 発行局」の説明

表35-10に、発行局の「トークンと属性」要素を示します。トークンから属性を抽出するときに、アサーションに含まれる属性に適用される属性マッピング・ルールを定義できます。2つのルールのセットがあります。

- SAML属性の名前をローカル名に変換できる属性名マッピング(たとえば、firstnameをgivennameに変換できます)。

- SAML属性の値をローカル値に変換できる属性名マッピング(たとえば、PresidentをCEOに変換できます)。

表35-10 「トークンと属性」要素: 発行局

要素

説明

属性名マッピング

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にするかどうかを示します。

- 大/小文字区別なし: 属性値を「ローカル属性」フィールドと比較するときに、セキュリティ・トークン・サービスで大/小文字が区別されるかどうかを示します。

発行局プロファイル: トークン・マッピング

図35-9に示すように、「トークン・マッピング」タブを使用すると、管理者はSAML検証テンプレートに定義されているマッピング・ルールを、発行局パートナ・プロファイルに定義されているマッピング・ルールでオーバーライドできます。このように、セキュリティ・トークン・サービスはアサーション発行者のセットに固有のルールに基づいてSAMLアサーションをマップできます。表35-10に、発行局の「トークン・マッピング」要素を示します。

図35-9 発行局プロファイル: 「トークン・マッピング」タブ

表35-11 発行局の「トークン・マッピング」要素

要素

説明

トークン・マッピングのオーバーライド

このセクションに定義されているマッピング・ルールが、アサーションの処理に使用されるSAML検証テンプレートにリストされているマッピング・ルールをオーバーライドするかどうかを示します。これによってセキュリティ・トークン・サービスは、アサーション発行者に固有のマッピング・ルールを使用できます。trueの場合、すべてのマッピング・ルールがこのセクションにリストされている設定でオーバーライドされます。

簡易ユーザー・マッピングのオーバーライド

簡易ユーザー・マッピングでは、単一のトークン属性を使用して、単一のユーザー・レコード属性と照合することで、着信トークンをユーザー・レコードにマップします。

- ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。

- データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。

ユーザー名識別子マッピングのオーバーライド

有効な場合、名前IDユーザー・マッピング操作を定義します。この操作では、名前IDフォーマットに基づいて名前ID値を単一のユーザー・レコード属性にマップすることで、着信SAMLアサーションをユーザーにマップします。

有効な場合、セキュリティ・トークン・サービスでは名前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アサーションをユーザーにマップします。

有効な場合、セキュリティ・トークン・サービスでは名前IDフォーマットが評価され、パートナ識別属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるリクエスタ・パートナ識別属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。

- カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。

- マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でリクエスタ・パートナ識別属性を設定します。

35.4.2 Token Serviceパートナ・プロファイルの管理

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、トークン・サービス・パートナ・プロファイルを作成、検索、表示、編集または削除できます。

前提条件

リクエスタ・パートナ・プロファイルの前提条件は、次のとおりです。

- デフォルト・リライイング・パートナ・プロファイルを定義するために、リライイング・パートナ・プロファイルが存在する必要があります。

- OnBehalfOf要素に存在するトークンの検証に使用されるテンプレートを設定するために、WS-Trust検証テンプレートが存在する必要があります。

リライイング・パートナ・プロファイルの前提条件は、次のとおりです。

- トークン発行操作に使用するテンプレートを構成するために、発行テンプレートが存在する必要があります。

発行局パートナ・プロファイルの前提条件はありません。

パートナ・プロファイルを作成、検索、編集または削除する手順

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「セキュリティ・トークン・サービス」セクション
「パートナ・プロファイル」ノード

2. 「パートナ・プロファイル」ノードで、目的のプロファイル・タイプをダブルクリックし、必要に応じて次の手順に進みます。

- リクエスタ・プロファイル

- リライイング・パーティ・プロファイル

- 発行局プロファイル

3. 新規プロファイル:

1. 新規プロファイル・タイプボタンをクリックして、定義に使用する新しいページを表示します。

2. 選択したプロファイル・タイプの一般情報(表35-7)を入力し、「次」ボタンをクリックします。

3. トークンと属性: 適切な表を使用して、選択したプロファイル・タイプの詳細を指定します。
リクエスタ・プロファイル: 表35-8

リライイング・パーティ・プロファイル: 表35-9

発行局プロファイル: 表35-10

4. 「保存」をクリックして送信(または「取消」をクリックしてページを閉じます)し、確認ウィンドウを閉じます。

4. プロファイル検索の絞込み: 「プロファイル検索の絞込み」

1. ステップ1および2を実行します。

2. 問合せを定義し、「検索」ボタンをクリックします。

3. 「検索結果」表で、表示、編集または削除するパートナの名前をクリックします。

5. プロファイルの編集:

1. 「検索結果」表で、編集するプロファイルの名前をクリックし、「編集」ボタンをクリックします(または「アクション」メニューから「編集」を選択します)。

2. パートナ情報に必要な変更を加えます。
リクエスタ・プロファイル: 表35-8

リライイング・パーティ・プロファイル: 表35-9

発行局プロファイル: 表35-10

3. 「適用」をクリックして変更を送信(または「元に戻す」をクリックして変更を取り消します)し、確認ウィンドウを閉じます。

6. プロファイルの削除: プロファイルを削除するには、プロファイルが他の場所で参照されていない状態にする必要があります。
リクエスタ・パートナ・プロファイルを削除するには、次のことが必要です。

- リクエスタ・パートナがプロファイルを参照していないこと。

- WS-Security検証テンプレートがプロファイルを参照していないこと。

リライイング・パーティ・パートナ・プロファイルを削除するには、次のことが必要です。

- リライイング・パーティ・パートナがプロファイルを参照していないこと。

- リクエスタ・パートナ・プロファイルがプロファイルを参照していないこと。

発行局パートナ・プロファイルを削除するには、次のことが必要です。

- 発行局パートナがプロファイルを参照していないこと。

これらの前提条件が満たされている場合は、次の作業を実行します。

1. 「検索結果」表で、削除するプロファイルを含む行を強調表示します。

2. 「削除」(X)ボタンをクリック(または「アクション」メニューから「選択項目の削除」を選択します)し、確認ウィンドウを閉じます。

35.4.3 プロファイル検索の絞込み

パートナ定義と同様に、「パートナ・プロファイル」ノードを開くと、すべての「パートナ・プロファイル」ノードが使用可能になります。特定のタイプの「パートナ・プロファイル」ノードを選択すると、関連する検索コントロールと「検索結果」表が使用可能になります。

図35-4に、一般的なプロファイルの検索ページを示します。これはリクエスタ・プロファイルの場合です。ただし、コントロールはすべて同じです。異なるプロファイル・タイプでは結果のみが異なります。

図35-10 プロファイルの検索ページ: リクエスタ

「図35-10 プロファイルの検索ページ: リクエスタ」の説明

「検索」ページから「検索結果」表の名前を選択してプロファイルを表示または編集するか、コントロールを使用して検索を絞り込み、特定のプロファイルまたは特定の特性を持つプロファイルを検索します。

36 セキュリティ・トークン・サービスのトラブルシューティング

この章では、セキュリティ・トークン・サービスのトラブルシューティングに関するヒントを提供します。

- 認可の問題

- エンドポイントの問題

- マッピング操作の問題

36.1 認可の問題

問題: トークンの発行操作中に認可に失敗しました

WS-Trustリクエストの発行操作中に、セキュリティ・トークン・サービスがエラーを返します。

エラー・メッセージ

ログに表示される可能性があるエラー・メッセージのサンプルを次に示します。

<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リソースが存在し、トークン発行ポリシーに割り当てられていますが、ポリシーに満たされていない条件があります。この場合、ポリシー・ルールを確認します。ポリシーが正しい場合、クライアントはトークンをリクエストできません。それ以外の場合は、クライアントのアイデンティティを含むようにポリシー/条件を更新します。

36.2 エンドポイントの問題

問題: エンドポイントが見つかりません

Oracle Access Managementコンソールを介して追加された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.>

解決策

セキュリティ・トークン・サービスがデプロイされていますが、有効になっていません。セキュリティ・トークン・サービスを有効にするには、次の操作を実行します。

1. Oracle Access Managementコンソールに移動します。

2. 「システム構成」に移動し、「共通構成」、「使用可能なサービス」の順に選択します。

3. セキュリティ・トークン・サービスを有効にします。

セキュリティ・トークン・サービスが変更を検出し、エンドポイントを公開します。再起動は不要です。

36.3 マッピング操作の問題

問題: AppliesTo要素をリライイング・パーティ・パートナにマップできません

セキュリティ・トークン・サービスでWebサービス・プロバイダを参照するAppliesTo要素を使用してWS-Trustリクエストを処理する場合、サーバーでは、パートナ・エントリに定義されているリソースURLを使用して、AppliesTo要素に含まれるロケーションをセキュリティ・トークン・サービス・リライイング・パーティ・パートナにマップしようと試みます。そのようなマッピングが失敗した場合、サーバーでは、操作が失敗したこと、および使用された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が定義されているリライイング・パーティ・パートナにマップされます。

注意:

このメッセージは通知レベルで記録されるため、セキュリティ・トークン・サービスで記録されるようにするには、Notification:1レベルを含むように、適切なロギング・レベルを設定する必要があります。

場合によっては、AppliesToアドレスをリライイング・パーティ・パートナに正しくマップできないと、次の理由によりエラーが発生します。

- 認証評価の失敗

- セキュリティ・トークン・サービスで、リライイング・パーティ・パートナに属している証明書を取得できない。

第IX部

Oracle Access Management Mobile and Socialの管理

この部ではOracle Access Management Mobile and Socialについて説明します。

Mobile and Socialは、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのOracle Access ManagementサービスとOracle Identity Managementサービスの間の橋渡しの役割を果たします。Mobile and Socialでは簡易クライアント・ライブラリが提供され、開発者はこれを使用することで、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドでは、Mobile and Socialサービスのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアを更新しなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます。

第IX部の内容は次のとおりです。

- 第37章「Mobile and Socialの理解」

- 第38章「モバイル・サービスの構成」

- 第39章「インターネット・アイデンティティ・サービスの構成」

- 第40章「Mobile and Socialシステム設定の構成」

37 Mobile and Socialの理解

この章では、Oracle Access Management Mobile and Socialの用途と機能について説明します。内容は次のとおりです。

- Mobile and Socialの概要

- モバイル・サービスの理解

- モバイル・サービスのプロセスの理解

- モバイル・サービスの使用

- インターネット・アイデンティティ・サービスの理解

- インターネット・アイデンティティ・サービス・プロセスの理解

- インターネット・アイデンティティ・サービスの使用

37.1 Mobile and Socialの概要

Oracle Access Management Mobile and Socialサービスは、保護されたリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアクセス管理サービスおよびアイデンティティ管理サービスの間の橋渡しの役割を果たします。Mobile and Socialには簡易なクライアント・ライブラリが用意されており、開発者はこれを使用して、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドでは、Mobile and Socialサーバーのプラガブルなアーキテクチャにより、システム管理者は、ユーザーのクライアント・ソフトウェアやモバイル・アプリケーションを更新しなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除できます。Mobile and Socialは、次に示す無料の2つの機能セットを提供します:

- モバイル・サービスは、アプリケーションおよびデバイスを、Oracle Identity Access Management製品スイートで使用可能なエンタープライズ・アクセス管理サービスおよびアイデンティティ管理サービスに接続します。これにより、認可されたデバイスのみがアクセスできるように制限するために、高度な認証および認可サービスの機能(モバイル・デバイスとアプリケーションの登録や、デバイス・フィンガープリンティングなど)を簡単に利用できるようになります。また、クライアント・アプリケーションでは、基本的なパスワードベースの認証よりも優れた強力な機能であるナレッジベース認証も実装できます。

注意:

デバイス・フィンガープリンティングおよびナレッジベース認証には、いずれもOracle Adaptive Access Managerが必要です。

モバイル・サービスは、有効なデバイスとクライアント資格証明に加え、アプリケーション・トークン・リクエストごとにユーザー・トークンを要求するように構成できます。これにより、認可済のユーザーのみが保護されたリソースにアクセスできるようになり、そのユーザーが同一デバイスで認可済のアプリケーションを実行している場合にのみ、アプリケーションごとの資格証明を提供する必要がなくなります。モバイル・サービスは、Mobile and SocialがLDAP準拠のディレクトリ・サーバーと統合されている場合、ユーザー・プロファイル・サービスへの簡単なアクセスも提供します。

- インターネット・アイデンティティ・サービスを使用すると、Mobile and Socialは、GoogleやYahoo、Facebook、Twitter、LinkedInなどの一般的なクラウドベースのアイデンティティ認証および認可サービスとの相互作用中に、リライイング・パーティの役割を果たすことができます。Mobile and Socialをデプロイすると、各プロバイダを個別に実装しなくても、複数のログイン・オプションがユーザーに提供されます。これにより、ユーザーは信頼できるアイデンティティ・プロバイダにある自分の資格証明を使用して保護されたリソースにアクセスできるようになります。

Mobile and SocialはAccess Managerとの密接な統合に加え、Oracle Adaptive Access Managerおよび様々なLDAP準拠のディレクトリ・サーバーといった他のバックエンドのアイデンティおよびアクセス管理サービス・オファリングと連携動作するようにあらかじめ統合されています。フロントエンドに対して、Mobile and Socialは、簡単に使用できるSDKを提供して、JavaおよびiOSプラットフォーム上のクライアント・アプリケーショを統合に対応しています。クライアント・アプリケーションは、簡易なREpresentational State Transfer(REST)コールを使用して、Mobile and Socialサーバーと通信します。

注意:

RESTは、World Wide Webの開発に使用されているソフトウェアのアーキテクチャ様式です。RESTは、軽量であり、特にWebベースのアプリケーションやサービスの構築に適しています。

モバイル・サービスとインターネット・アイデンティティ・サービスを連動するように構成できます。たとえば、インターネット・アイデンティティ・サービスを使用してGoogle、Facebook、Twitterなどでユーザーが認証できるようにし、モバイル・サービスを使用して(a)ローカル認証機能を提供するか、(b)ソーシャル・アイデンティティ・プロバイダのユーザーIDアサーションを受け付けることでユーザー・トークンを生成できます。モバイル・サービスをインターネット・アイデンティティ・サービスとともに使用すると、デバイス登録セキュリティを強化することもできます。

注意:

Mobile and Socialサービスは、iOSデバイスまたはJava SE JVMで実行される登録済アプリケーションや、RESTコールを使用してサービスと通信する登録済アプリケーションにセキュリティ・レイヤー機能を提供します。追加のモバイル機能が必要な場合は、無償のOracle製品オファリングであるADFモバイルが、iOSで動作するデバイス用のフル機能のアプリケーションを作成するためのアプリケーション開発フレームワークを提供します。詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkモバイル開発者ガイドを参照してください。

次の各項には、Mobile and Socialのインストールとデプロイメントについての追加情報と説明のリンクが含まれています。

- Mobile and Socialのデプロイ

- Mobile and Socialのインストール

37.1.1 Mobile and Socialのデプロイ

次のリストは、Mobile and Socialのいくつかのデプロイメント方法の情報とリンクを示しています。

- Mobile and SocialをAccess Managerとともにデプロイする場合は、Mobile and SocialとAccess Managerの両方を同一ドメインまたは別のドメインの同じサーバー上に一緒にデプロイできます。詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドを参照してください。

- Mobile and SocialをOracle Access Manager 10gまたは11gR1 PS1とともにデプロイする場合は、Mobile and SocialとOracle Access Managerは別々のドメインの別々のサーバー上にインストールする必要があります。詳細は、第40.3項「Oracle Access Managerを使用するMobile and Socialのデプロイ」を参照してください。

注意:

すでにAccess Managerがインストールされている場合は、OAMドメインを拡張することでMobile and SocialをOracle Access Managementのインストールに追加することはできません。これを試みると、次のようなエラーが発生します。

CFGFWK-64071- the selection conflicted with templates already installed in the domain OAM with database policy store 11.1.1.3.0

- Mobile and Socialをテスト環境から本番環境に移行する場合は、第40.4項「テストから本番に移行するスクリプトを実行した後のMobile and Socialの構成」を参照してください。

37.1.2 Mobile and Socialのインストール

Mobile and Socialは単体でインストールすることも、Access ManagerまたはOracle Adaptive Access Manager (OAAM)とともにインストールすることも、これら3つをすべて一緒にインストールすることもできます。Mobile and Socialとともにインストールしたソフトウェアに応じて使用できる機能が異なります。表37-1に詳細を示します。

表37-1 インストールしたコンパニオン・サービスに基づくMobile and Socialの機能

機能

Mobile and Social + Access Manager

Mobile and Social + Access Manager + OAAM

Mobile and Socialのみ

Mobile and Social + OAAM

ネイティブAccess Manager認証ダイアログを使用したAccess Managerトークン・サポート

✔

✔

認証および認可のJWTトークン・サポート

✔

✔

✔

✔

接続モバイル・デバイスを一意に識別する機能(デバイスのフィンガープリント)

✔

✔

デバイスの登録およびアクセス・リクエスト時の基本的な(制限付きの)デバイス・セキュリティ・チェック

✔

✔

リスクベースのアクセス制御(地理ロケーションおよび他のデバイス属性に基づくアクセスの許可または拒否など)を含む、デバイスの登録およびアクセス・リクエスト時の拡張デバイス・セキュリティ・チェック

✔

✔

マルチステップ認証サポート(ナレッジベース認証およびワンタイム・パスワードのサポート)

✔

✔

ディレクトリ・サーバーとの連携およびユーザー・プロファイル・サービスのサポート

✔

✔

✔

✔

インターネットベースのアイデンティティ・プロバイダ(Facebook、Google、Twitter、LinkedIn、Yahoo)のリライイング・パーティ・サポート

✔

✔

✔

✔

インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。

37.2 モバイル・サービスの理解

モバイル・サービスは、クライアント・デバイスで実行しているアプリケーションを、Oracle Identity Access Management製品スイートで使用可能なセキュリティ・サービスと製品に接続します。また、ユーザー・プロファイル・サービスはモバイル・サービス機能であり、多くの一般的なLDAP準拠ディレクトリ・サーバーにクライアント・アプリケーションを接続します。モバイル・サービスは、次のコンポーネントで構成されます。

- バックエンドのアイデンティティ・サービス・インフラストラクチャとのインタフェースとなるサーバー・コンポーネント。サーバーは、サポートされているクライアント・アプリケーション(およびそれらのアプリケーションを使用するユーザー)と、バックエンドのアイデンティティ・サービスの間の橋渡しの役割を果たします。このような配置により、クライアント・アプリケーションはバックエンドのインフラストラクチャから分離されるため、クライアント・プログラムを更新しなくても、バックエンドのインフラストラクチャを変更できます。Mobile and Socialサービスは、単独で実行することも、Access ManagerサービスやOAAM製品と組み合せて実行することもできます。詳細は、第37.1項「Mobile and Socialの概要」を参照してください。

- Mobile and Socialモバイル・サービス・クライアント・ソフトウェア開発キット(クライアントSDK)には、iOSデバイスとJavaに使用できます。これは、モバイル・デバイスとデスクトップ・デバイスで実行するアプリケーションに認証、認可およびディレクトリ・アクセス機能を組み込む場合に使用します。また、モバイル・サービス・クライアントSDKを使用すると、モバイル・シングル・サインオン(SSO)エージェント・アプリケーションを作成することもできます(iOSデバイスのみ)。モバイルSSOの詳細は、第37.2.3項「モバイル・シングル・サインオン(SSO)機能の概要」を参照してください。Mobile and Socialモバイル・サービス・クライアントSDKの詳細は、第37.2.4項「Mobile and Socialモバイル・サービス・クライアントSDKの概要」を参照してください。

次の各項では、Mobile and Socialのモバイル・サービスの部分について詳細に説明します。

- 認証サービスおよび認可サービスの概要

- ユーザー・プロファイル・サービスの概要

- モバイル・シングル・サインオン(SSO)機能の概要

- Mobile and Socialモバイル・サービス・クライアントSDKの概要

37.2.1 認証サービスおよび認可サービスの概要

認証および認可サービスを使用すると、モバイルおよび非モバイル・アプリケーションに既存の認証および認可インフラストラクチャを拡張できます。モバイル・サービスは、次の一般的なトークン・タイプをサポートします。

- ユーザー・トークンは、認証されたユーザーに関連付けられた権限をトークン・ベアラーに付与します。

- アクセス・トークンは、WebリソースやURLなど保護されている特定のリソースへのアクセスを許可します。

- クライアント・トークンは、Webアプリケーションやサーバー・アプリケーションなどの非モバイル・ハードウェア・デバイスへのアクセスを許可します。

- クライアント登録ハンドル(クライアント・トークンと同様)もモバイル・サービスで使用されます。これは、モバイル・デバイスで実行しているモバイル・クライアント・アプリケーションを示すものです。Mobile and Socialは、クライアント登録ハンドルを使用して、モバイル・デバイスを登録します。これに対して、非モバイル・サービス・プロバイダは、クライアント・トークンを使用して、非モバイル・デバイスを認証します。

モバイル・デバイスとは、Apple社のiOSモバイル・オペレーティング・システムなどのモバイル・オペレーティング・システムを実行するデバイスです。一方、非モバイル・デバイスとは、Mac OS X、Windows 7およびLinuxデスクトップなどの非モバイル・オペレーティング・システムを実行するデバイスです。モバイル・デバイスと非モバイル・デバイスのセキュリティ上の課題は異なるため、Mobile and Socialではモバイルの認証と非モバイルの認証は別々に管理されます。新しいモバイル・デバイスははるかに頻繁にオンラインになるため、不正検出手段など、より詳細な精査を必要とします。

注意:

非モバイル・デバイスは、適切な入力を提供すると、モバイル・サービスと非モバイル・サービスの両方を使用できます。

Mobile and Socialは、Access Managerトークン(Mobile and SocialとともにAccess Managerがインストールされている場合)と、JWTトークンをサポートします。それぞれのトークン・タイプには、それに対応する事前構成済のモバイルおよび非モバイル・サービス・プロバイダがあります。事前構成済の認証サービス・プロバイダについては、表37-2を参照してください。

表37-2 構成済のモバイルおよび非モバイル認証サービス・プロバイダ

認証サービス・プロバイダ

説明

OAMAuthentication

これによって、デスクトップ・デバイスからWebアプリケーションを実行するユーザーは、Access Managerを使用して認証できます。

MobileOAMAuthentication

これによって、モバイル・デバイスを使用するユーザーは、Access Managerを使用して認証できます。

JWTAuthentication

これによって、デスクトップ・デバイスからWebアプリケーションを実行するユーザーは、JSON Webトークン・フォーマットを使用して認証できます。JSON Web Tokenは、HTTP認可ヘッダーなど、領域に制約がある環境に適したコンパクトなトークン形式です。

MobileJWTAuthentication

これによって、モバイル・デバイスを使用するユーザーは、JSON Webトークン・フォーマットを使用して認証できます。

37.2.2 ユーザー・プロファイル・サービスの概要

ユーザー・プロファイル・サービスにより、組織のユーザーがモバイル・デバイスからユーザー・プロファイル・サービスにアクセスできるアプリケーションを作成できます。ユーザー・プロファイル・サービスを使用すると、Web、モバイルおよびデスクトップ・アプリケーションは、次に示すような各種のLDAP準拠のディレクトリ・サーバーのタスクを実行できるようになります。

- ユーザーおよびグループの作成、読取り、更新および削除機能

- 検索機能

- 組織図のレポート機能

これを達成するために、Mobile and Socialサーバーは、次にあげる多くの一般的なLDAP準拠のディレクトリ・サーバーとインタフェース接続できます。

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

- Oracle Internet Directory

- Oracle Unified Directory

- Oracle Virtual Directory

- Open LDAP

- WebLogic Server Embedded LDAP

ユーザー・プロファイル・サービスに対するSDKの使用方法を示すコード例については、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

注意:

HTTP通信が可能なデバイスは、RESTコールをMobile and Socialサーバーに送信することで、ユーザー・プロファイル・サービスを使用できます。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のcURLを使用したMobile and Social RESTコールの送信に関する項を参照してください。

37.2.3 モバイル・シングル・サインオン(SSO)機能の概要

モバイル・シングル・サインオン(モバイルSSO)を使用すると、ユーザーは、同一デバイス上で複数のモバイル・アプリケーションを実行するときに、それぞれの資格証明を提供する必要がなくなります。ネイティブ・アプリケーションとブラウザベースのアプリケーションは、どちらもモバイルSSOに参加できます。

モバイルSSOが機能するには、モバイル・デバイスにインストールされているアプリケーションをモバイルSSOエージェントに指定する必要があります。エージェント・アプリケーションは、リモートのMobile and Socialサーバーと、バックエンドのアイデンティティ・サービスで認証する必要のあるデバイス上の他のアプリケーションとの間でプロキシとしての役割を果たします。エージェントは、専用エージェント(他の用途には使用されないアプリケーション)であっても、エージェント機能も同時に提供するビジネス(クライアント)アプリケーションであってもかまいません。

注意:

アプリケーションでモバイルSSOを使用してMobile and Socialサーバーとの認証を行うには、そのサーバーでアプリケーションをモバイルSSOエージェントまたはクライアントとして構成しておく必要があります。モバイルSSO用にモバイル・サービス・セキュリティを構成する方法の詳細は、第38.7項「サービス・ドメインの定義」を参照してください。

モバイル・アプリケーション開発者は、モバイルSSOエージェントを使用することでメリットが得られます。モバイルSSOエージェントは、デバイスの登録や高度な認証スキーム(たとえば、マルチファクタ認証やワンタイム・パスワード認証など)を処理するため、このような機能をそれぞれのモバイル・アプリケーションに組み込む必要がなくなります。モバイルSSOエージェントが存在する場合は、ユーザー資格証明がモバイル・ビジネス・アプリケーションに公開されなくなります。モバイルSSOエージェントとSSOクライアントは、次のように相互作用します。

- SSOクライアント・アプリケーションは、デバイス登録リクエスト、アプリケーション登録リクエストおよびユーザー・トークン・リクエストをSSOエージェントに送信します。

- SSOエージェントは、SSOクライアントのかわりに必要な収集を実行します。

- SSOクライアント・アプリケーションは、登録ハンドルとユーザー・トークンを使用して、必要になるアクセス・トークンをリクエストします。

ブラウザベースのビジネス・アプリケーションも、認証にモバイルSSOエージェントを使用するように構成できます。その場合は、ブラウザベースのビジネス・アプリケーションを起動すると、モバイルSSOエージェントが起動され、そのエージェントによってユーザー名とパスワードが収集されてMobile and Socialサーバーに送信されます。ビジネス・アプリケーションとエージェントがSSOで認可されると、Mobile and Socialサーバーはアクセスを認可します。続いて、エージェントは、リソースのアクセス・トークンを(ビジネス・アプリケーションのかわりに)要求し、ヘッダーに含まれているアクセス・トークンでブラウザをビジネス・アプリケーションのURLにリダイレクトします。

ユーザーの視点から見た場合、ネイティブおよびブラウザベースのアプリケーションは、ユーザーに資格証明を要求することなく、デバイス上で開始されます。モバイル・デバイスにエージェントがインストールされていない場合またはビジネス・アプリケーションがモバイルSSOで承認されない場合は、各アプリケーションを起動するたびに、ユーザーは自分の資格証明をMobile and Socialサーバーに個別に直接送信する必要があります。

モバイルSSOエージェントは、アイドル・セッションのタイムアウトや、すべてのアプリケーションに対するグローバル・ログアウト管理も可能で、デバイス選択消去にも役立ちます。さらに、オフラインのBasic認証やローカル記憶域用の一方向暗号化ユーザー・パスワードもサポートしています。オフライン認証の場合、エージェントは、ユーザー名とパスワードの検証にローカルに保存されているバージョンを使用します。エージェントは、すべてのセッションのアイドル・タイムアウトと、ローカル・パスワードの有効期限ポリシーを強制します。

構築済のモバイルSSOエージェントは提供していませんが、iOS用のMobile and Socialモバイル・サービス・クライアントSDKを使用してモバイルSSOエージェント・アプリケーションを構築できるようにドキュメントを提供しています。モバイルSSOエージェント・アプリケーション作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のiOSモバイル・サービスSDKに関するドキュメントを参照してください。

注意:

モバイルSSOエージェントは、iOSデバイスでのみサポートされます。

37.2.4 Mobile and Socialモバイル・サービス・クライアントSDKの概要

Mobile and Socialモバイル・サービス・クライアントSDKには、iOSデバイス用とJava仮想マシン(JVM)用の個々のSDKが含まれています。表37-3は、各モバイル・サービス・クライアントSDK機能と、その機能が動作するソフトウェアについての説明です。

表37-3 Mobile and Social Mobileサービス・クライアントSDKのJava機能およびiOS機能

機能

iOS

Java

Mobile and Socialサーバー経由でのクライアント登録ハンドル、ユーザー・トークンおよびアクセス・トークンを取得可能なモバイル・アプリケーションの作成

✔

Mobile and Socialサーバー経由でのクライアント・トークン、ユーザー・トークンおよびアクセス・トークンを取得可能なデスクトップ・アプリケーションの作成

✔

ディレクトリ・サーバーとの連携およびユーザー・プロファイル・サービスの実装

✔

✔

モバイル・シングル・サインオン(SSO)アプリケーションの作成

✔

37.3 モバイル・サービスのプロセスの理解

保護されたリソースにユーザーがアクセスしようとすると、Mobile and Socialによってクライアント・トークン(クライアントの資格証明を安全に格納するサーバーまたはコンピュータを通してユーザーが接続している場合)またはクライアント登録ハンドル(ユーザーがモバイル・デバイスを使用している場合)が要求されます。つまり、クライアント・デバイス(モバイル・デバイスを含む)とクライアント・アプリケーションが保護されたリソースにアクセスするには、Mobile and Socialサーバーに登録する必要があるということです。

注意:

また、アプリケーションは通常、ユーザー・トークンとアクセス・トークンを要求するように構成されています。

モバイル・デバイス上で実行するクライアント・アプリケーションが、この高度な認証プロセスに従った後で、モバイル・アプリケーションは保護されたリソースにアクセスできるようになります。

1. ユーザーは、アプリケーションのログイン画面でユーザー名とパスワードを入力して、Mobile and Socialサーバーで認証されます。

2. モバイル・デバイスがMobile and Socialサーバーにまだ登録されていない場合、ユーザーの認証後に、このサーバーはモバイル・デバイスにクライアント登録ハンドルを送信します。

3. クライアント登録ハンドルがMobile and Socialサーバーに返されて、ユーザー・トークンが取得されます。

4. クライアント登録ハンドルとユーザー・トークンがMobile and Socialサーバーに返されて、アクセス・トークンが取得されます。

非モバイル・アプリケーションも、モバイル・サービスが提供する認証サービスを利用できます。そのような場合は、クライアント登録ハンドルのかわりにクライアント・トークンが使用されます。クライアント・トークンを取得すると、前述したようにユーザー・トークンとアクセス・トークンをリクエストできます。追加のシナリオについては、この項で説明します。

- ユーザー認証によるモバイル・デバイスの登録

- 登録済デバイスによるユーザー認証

- ユーザー認証のためのRESTコールの使用

- モバイルのブラウザベースのWebアプリケーションによるユーザーの認証

37.3.1 ユーザー認証によるモバイル・デバイスの登録

モバイル・デバイスが保護されたリソースにアクセスしようとしたときに、そのデバイスがMobile and Socialにまだ登録されていない場合は、モバイルSSOエージェントをインストールする必要があります。登録認証プロセスは、次のフローで説明します。このプロセスの説明の後に、図37-1と図37-2を示します。

1. ユーザーがモバイル・デバイスでアプリケーションを起動します。

2. アプリケーションは、ユーザーをモバイルSSOエージェントにリダイレクトします。

3. モバイルSSOエージェントにより、ログイン・ページが表示されます。

4. ユーザーは、ユーザー名とパスワードを入力します。

5. モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。

6. Mobile and Socialサーバーはユーザー名とパスワードを、ユーザーを認証するAccess Managerにフォワードします。

7. Mobile and Socialサーバーは、デバイス属性と他の認証結果をOAAMモバイル・セキュリティ・ハンドラ・プラグインに送信し、プラグインはOAAMサーバーに格納されているポリシーを実行します。

注意:

OAAMには、アクティブとパッシブの2つの登録フローがあります。アクティブ・フローでは、デバイス登録プロセスの続行を許可する前に、チャレンジによってユーザーへの本人確認を行います。パッシブ・フローは、ユーザーに対する本人確認なしで続行します。

OAAMセキュリティ・ハンドラ・プラグインは、2つのセキュリティ・ハンドル(Mobile and SocialがモバイルSSOエージェントまたはビジネス・アプリケーションそのものと一緒に格納するデータの一部)を作成します。各ハンドルには、名前、値および有効期限のタイムスタンプが格納されます。

- oaam.deviceハンドルはモバイル・デバイスを表します。(同じデバイス上の異なるクライアント・アプリケーションは、すべて同じデバイス・ハンドル値を持ちます。)OAAMは、このハンドルをキーとして使用し、OAAMデータベースに保存されている完全なデバイス・プロファイルを取得します。このハンドルの存続期間は、比較的長期間です。

- oaam.sessionハンドルは、クライアント・アプリケーション用のOAAMログイン・セッションを表します。(デバイス上の各クライアント・アプリケーションは、一意のセッション・ハンドル値を持ちます。)OAAMは、このハンドルをキーとして使用して、OAAMデータベースに保存されているOAAMセッションの詳細を取得します。ユーザーがクライアント・アプリケーションからログアウトすると、oaam.sessionハンドルは削除されます。

8. Mobile and Socialサーバーは、モバイル・クライアント登録ハンドル、OAAMデバイス・ハンドルおよびOAAMセッション・ハンドルを、モバイルSSOエージェントに返します。

9. モバイルSSOエージェントは、以前に受信したクライアント登録ハンドルとOAAMデバイス・ハンドルをサーバーに渡すことで、ユーザー・トークンを取得します。

10. モバイルSSOエージェントは、Access Managerのアクセス・トークンをリクエストします。このリクエストには、クライアント登録ハンドルとOAAMデバイス・ハンドルが含まれています。図37-2を参照してください。

図37-1 初回時のデバイス/アプリケーション登録と認証プロセス

「図37-1 初回時のデバイス/アプリケーション登録と認証プロセス」の説明

図37-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント

「図37-2 Access Managerからのアクセス・トークンをリクエストするモバイルSSOエージェント」の説明

37.3.2 登録済デバイスによるユーザー認証

このシナリオでは、Mobile and Socialと互換性があるビジネス・アプリケーションを起動するモバイル・デバイス(Mobile and Socialに登録済)を使用するユーザーについて説明します。このシナリオでは、モバイルSSOエージェントがインストールされていて、ユーザーはアクセス・トークンが必要になる保護されたリソースにアクセスする必要があります。ビジネス・アプリケーションは、アクセス・トークンをリクエストするために、最初にユーザー・トークンを取得する必要があります。添付の図(図37-3と図37-4)は、このプロセスを示しています。

1. ユーザーがモバイル・デバイスでビジネス・アプリケーションを起動します。

2. ビジネス・アプリケーションは、モバイルSSOエージェントにユーザー・トークンを求めます。このとき、次のいずれかが行われます。

1. ローカル資格証明ストアに有効なユーザー・トークンが存在する場合、モバイルSSOエージェントは、そのトークンをビジネス・アプリケーションに返します。ビジネス・アプリケーションは、Mobile and Socialサーバーにアクセス・トークンを求める直接リクエストに、ユーザー・トークンを挿入します。ビジネス・アプリケーションが、サーバーから返されたアクセス・トークンを使用して保護されたリソースにアクセスした時点で、このフローは完了します(図37-3を参照)。

図37-3 資格証明ストアに有効なアクセス・トークンを持つモバイルSSOエージェント

「図37-3 資格証明ストアに有効なアクセス・トークンを持つモバイルSSOエージェント」の説明

2. ローカル資格証明ストアに有効なユーザー・トークンが存在しない場合は、次のようにログイン・フローを続行します(図37-4を参照)。

3. モバイルSSOエージェントはログイン・ページを表示し、ユーザーはユーザー名とパスワードを入力します。

4. モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(図37-4の手順2)。

5. Mobile and Socialサーバーはクライアント登録ハンドルを検証して、ユーザー資格証明を(JWTトークン・サービスまたはAccess Managerトークン・サービスを使用して)認証し、リスク分析のためにOAAMを起動します。その後で、ユーザー・トークンをモバイルSSOエージェントに返します。(図37-4の手順3)。

6. モバイルSSOエージェントはユーザー・トークンのコピーをそのローカル資格証明ストアに格納し、そのユーザー・トークンをビジネス・アプリケーションに返します。(図37-4の手順4)。

7. ビジネス・アプリケーションはそのユーザー・トークンを使用して、Mobile and Socialサーバーにアクセス・トークンを直接リクエストします。(この手順は図には示されていません。)

8. Mobile and SocialサーバーからモバイルSSOエージェントにアクセス・トークンが返されます。

9. ビジネス・アプリケーションは、アクセス・トークンを使用して、Access ManagerまたはOracle Enterprise Gateway (OEG)で保護されたリソースを呼び出します。(図37-4の手順5)。

図37-4 資格証明ストアに有効なトークンを持たないモバイルSSOエージェント

「図37-4 資格証明ストアに有効なトークンを持たないモバイルSSOエージェント」の説明

37.3.3 ユーザー認証のためのRESTコールの使用

このシナリオでは、モバイル・デバイスで実行するアプリケーションはモバイルSSOエージェントにインタフェース接続し、エージェントはRESTコールを使用してMobile and Socialサーバーと通信します。サーバーは必要に応じてAccess ManagerおよびOAAMとインタフェース接続し、モバイルSSOエージェントに(再度RESTコールを使用して)必要なトークンを返します。エージェントは、アプリケーションにトークンを送り返します。このアプリケーションは、保護されたリソースにRESTコールまたはSOAPコールを使用してアクセスできるようになります。このプロセスについて、次のフローで説明します。このプロセスの説明に後に、図37-5を示します。

1. ユーザーがモバイル・デバイスでアプリケーションを起動します。

2. クライアント・アプリケーションはAccess Managerによって保護されたリソースにアクセスする必要があるため、モバイルSSOエージェントにアクセス・トークンの取得を要求します。

3. モバイルSSOエージェントは、Mobile and Socialサーバーからアプリケーション・プロファイルを取得します。

4. モバイルSSOエージェントは、ユーザー名とパスワードの入力を求めます。

5. モバイルSSOエージェントは、デバイス属性およびアプリケーションIDとともに、ユーザー名とパスワードをMobile and Socialサーバーに送信します。

6. Mobile and Socialサーバーがデバイスを登録し、ユーザーを認証します。

7. サーバーからモバイルSSOエージェントにアクセス・トークンが返されます。

8. モバイルSSOエージェントは、ローカル資格証明ストアにハッシュ・パスワードを保存します。

9. モバイルSSOエージェントは、クライアント・アプリケーションにアクセス・トークンを渡します。

10. クライアント・アプリケーションは、アクセス・トークンを提示することで、保護されたリソースにアクセスします。

図37-5 RESTを使用するユーザー認証

「図37-5 RESTを使用するユーザー認証」の説明

37.3.4 モバイルのブラウザベースのWebアプリケーションによるユーザーの認証

このシナリオでは、Mobile and Socialと互換性があるブラウザベースのWebアプリケーションを起動するMobile and Socialに登録されたモバイル・デバイスを使用するユーザーについて説明します。このシナリオでは、モバイルSSOエージェントがインストールされています。標準認証のプロセスは、次のフローで説明します。このプロセスの説明に後に、図37-6を示します。

1. ユーザーがモバイル・デバイスのWebブラウザでURLを開きます。

2. アプリケーションWebサーバーにより、ブラウザがAccess Managerにリダイレクトされます。

3. Access ManagerはWebブラウザにURLリダイレクトを送信します。

4. WebブラウザはモバイルSSOエージェントを起動することでリダイレクトに応答します。
エージェントがインストールされていない場合は、モバイルSSOエージェント・アプリケーションをインストールするためのリンクと指示が表示されます。

5. モバイルSSOエージェントは、ユーザー・ログイン・ページを表示します。

6. ユーザーは、ユーザー名とパスワードを入力します。

7. モバイルSSOエージェントは、ユーザー名、パスワードおよびクライアント登録ハンドルをMobile and Socialサーバーに送信します。(この手順は図には示されていません。)

8. Mobile and Socialサーバーはクライアント登録ハンドルを検証して、Access Managerで資格証明を認証し、IDコンテキストをAccess Managerサーバーに発行してから、リスク分析のためにOAAMを起動します。

9. Access Managerは、ユーザー・トークンまたはアクセス・トークンをMobile and Socialサーバーに返します。このサーバーは、そのユーザー・トークンまたはアクセス・トークンをモバイルSSOエージェントに返します。(この手順は図には示されていません。)

10. モバイルSSOエージェントはMobile and Socialサーバーにブラウザをリダイレクトして、このサーバーでCookieを注入します。

11. モバイルSSOエージェントは、WebブラウザにURLリダイレクトとアクセス・トークンを送信します。

12. モバイルWebブラウザはリダイレクトに応答しますが、今回はアクセス・リクエストにアクセス・トークンが含まれているため元のWeb URLを開きます。

13. アプリケーションWebサーバーによって、リクエストされたページがモバイルWebブラウザに送信されます。

図37-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証

「図37-6 登録済モバイル・デバイス上のブラウザベースWebアプリケーションからのユーザー認証」の説明

37.4 モバイル・サービスの使用

次の各項では、モバイル・サービスを使用する方法について説明します。

- モバイル・クライアント登録エンドポイントの保護

- 資格証明の交換

- ユーザー・プロファイル・サービスと認可サービスの保護

- モバイル・サービスとOracle Access Managerの併用

- モバイル・サービスとOracle Adaptive Access Managerサービスの使用

37.4.1 モバイル・クライアント登録エンドポイントの保護

保護されたリソースにアクセスを試行するモバイル・デバイスは、Mobile and Socialサーバーに登録されている必要があります。これは、このサーバーの登録エンドポイントに送信された匿名のリクエストは、このサーバーによって拒否されるためです。さらに、各サービス・ドメインは、アプリケーションを登録する場合に、ユーザー・パスワードまたはユーザー・トークンを要求するように構成する必要があります。次に、モバイル・クライアントとモバイル・アプリケーションの登録エンドポイントの例を示します。

https:// host : port /idaas_rest/rest/mobileservice1/register

Mobile and Socialへの登録時、JavaクライアントSDKまたはREST APIを使用するクライアント・アプリケーションは、次のスキームの1つ以上を使用するサーバーに有効な資格証明を提示する必要があります。

- HTTP Basic認証

- ユーザーIDとパスワード(UIDPASSWORD)

- OAMトークン認証

iOS SDKを使用するクライアント・アプリケーションではクライアント登録ハンドルが取得され、クライアント登録ハンドルではUIDPASSWORD認証スキームを使用して登録が保護されます。

37.4.2 資格証明の交換

iOSおよびJava SDKは、トークン、資格証明およびMobile and Socialサーバーによって要求される他のデータを送信します。表37-4は、クライアント・デバイスまたはアプリケーションに基づいて要求されるトークンおよび返されるトークンを示しています。

注意:

資格証明の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「cURLを使用したMobile and Social RESTコールの送信」のモバイル・サービスRESTリファレンス: 認証と認可に関する項を参照してください。

表37-4 Mobile and Socialサーバーのトークン要件

登録が必要なデバイスまたはアプリケーションのタイプ

Mobile and Socialサーバーによって要求されるトークン、資格証明またはデータ

返されるトークンのタイプ

非モバイル・デバイス(未登録)

HTTPS上で送信されるクライアント・アプリケーションに関連付けられたIDとパスワード。

クライアント・トークン

モバイルSSOエージェント・アプリケーション

- HTTPS上で送信されるユーザーIDとパスワード。

- モバイル・デバイスのデバイス・プロファイル・データ。

- アプリケーションの名前(つまり、クライアントID)。
注意: 管理者はサービス・ドメインにモバイルSSOエージェントの名前を追加することも必要です。

クライアント登録ハンドル

モバイルSSOクライアント・アプリケーション

(たとえば、Mobile and Socialに登録するためにモバイルSSOエージェント・アプリケーションを使用するビジネス・アプリケーション。)

- 次のうちの1つ。
HTTPS上でMobile and Socialサーバーに送信されるユーザーIDとパスワード。

または

ユーザー・トークン。

- モバイル・デバイスのデバイス・プロファイル・データ。

- アプリケーションの名前(つまり、クライアントID)。
注意: 管理者はサービス・ドメインにモバイルSSOクライアント・アプリケーションの名前を追加することも必要です。

- oaam.deviceハンドル(Mobile and SocialがOAAMに統合されている場合)。

- SSOクライアント・アプリケーションがSSOエージェント・アプリケーションを通して登録しようとしている場合は、(以前にSSOエージェント用に取得された)モバイルSSOクライアント登録ハンドル。

クライアント登録ハンドル

37.4.3 ユーザー・プロファイル・サービスと認可サービスの保護

モバイル・サービスのサービス・ドメインの構成時に、次のようにユーザー・プロファイル・サービスと認可サービスを保護できます。

ユーザー・プロファイル・サービス: ユーザー・プロファイル・サービスのセキュリティは、サービス・プロファイルに次を選択することで構成します。

- 認証サービス・プロバイダ(OAMAuthentication、MobileOAMAuthentication、JWTAuthentication、モバイルJWT認証、インターネット・アイデンティティ認証など)を選択します。

- 「セキュア・アプリケーション」セキュリティ・トークンと「セキュア・ユーザー」セキュリティ・トークンを要求することで、サービスを保護します。

- 「読取りの許可」および「書込みの許可」オプションを設定します。

認可サービス - : 認可サービスのセキュリティは、サービス・プロファイルに次を選択することで構成します。

- 認証サービス・プロバイダ(OAMAuthentication、MobileOAMAuthentication、JWTAuthentication、モバイルJWT認証、インターネット・アイデンティティ認証など)を選択します。

- 「セキュア・アプリケーション」セキュリティ・トークンと「セキュア・ユーザー」セキュリティ・トークンを要求することで、サービスを保護します。

37.4.4 モバイル・サービスとOracle Access Managerの併用

開発者は、Oracle Access Management Access Managerや、10gまたは11gR1 PS1 (11.1.1.5)バージョンのOracle Access Managerで保護されたリソースにアクセスするアプリケーションを簡単に作成できます。Mobile and Social SDKは、資格証明コレクション・インタフェースを使用してユーザーの資格証明を収集した後は、認証をプログラム的に処理します。その後、SDKでは、アプリケーション用に構成されたトークン・サービスにより、Mobile and Social RESTインタフェースを使用してユーザーが認証されます。Access Managerを使用するモバイル・サービスの認証フローの詳細は、第37.3.1項「ユーザー認証によるモバイル・デバイスの登録」を参照してください。

37.4.5 モバイル・サービスとOracle Adaptive Access Managerサービスの使用

Oracle Adaptive Access Manager (OAAM)を使用して、実行時の認証を決定することもできます。たとえば、認可されていない国や場所からユーザーの認証が実行された場合に認証を拒否できます。また、次の機能もサポートされています。

- マルチパート・ログイン・フロー: たとえば、OAAMがリスクのある使用パターンや通常外の使用パターン(ユーザーが通常の時間以外にデバイスを使用していたり、最後の認証から地理的に遠く離れている場合など)を検知すると、ナレッジベース認証の質問でユーザーが本人であるか確認したり、ワンタイム・パスワード(OTP)機能を使用した認証をユーザーに要求できます。

- デバイス属性(デバイスに割り当てられているMACアドレスなど)をチェックします。また、デバイスがジェイルブレークされていないことを検証します。デバイスの属性に基づいて、OAAMでアクセスを許可または拒否できます。

- また、Mobile and SocialとともにOAAMを使用する場合は、デバイス選択消去もオプションです。

- 登録されたデバイス情報に基づいて、OAAMでは特定のデバイスをホワイトリストまたはブラックリストに記載できます。

Mobile and SocialとOAAMを併用する方法の詳細は、第38.9.2項「Oracle Adaptive Access Manager用のモバイル・サービスの構成」を参照してください。

37.5 インターネット・アイデンティティ・サービスの理解

インターネット・アイデンティティ・サービスを使用すると、Mobile and Socialは、GoogleやYahoo、Facebook、Twitter、LinkedInなどの一般的なクラウドベースのアイデンティティ認証および認可サービスとの相互作用中に、リライイング・パーティ(RP)の役割を果たすことができます。信頼できるアイデンティティ・プロバイダの資格証明を使用して保護されたリソースにログインできると、ユーザーにとって便利です。Mobile and Socialをデプロイすると、各プロバイダを個別に実装しなくても、便利な複数のログイン・オプションをユーザーに提供できます。ユーザーはクラウドベースのアイデンティティ・サービスの資格証明を使用して、次の3つのアプリケーション・タイプにログインできます。

- Java準拠のアプリケーション・サーバー上で実行されるWebアプリケーション。Webアプリケーションにインターネット・アイデンティティ・サービス機能を追加するには、インターネット・アイデンティティ・サービス・クライアントSDKを使用してWebアプリケーションをMobile and Socialサーバーに接続します。詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」を参照してください。

- Access Managerや、10gまたは11.1.1.5バージョンのOracle Access Managerで保護されているアプリケーション。Oracle Access Management製品のAccess Managerサービスによって保護されているアプリケーションか、10gまたは11gR1 PS1バージョンのOracle Access Managerによって保護されているアプリケーションは、SDKを使用しないで、インターネット・アイデンティティ・サービスとともに動作するように構成できます。認証フローの詳細は、第37.6.4項「Access Managerとインターネット・アイデンティティ・サービスによるユーザー認証」を参照してください。

- iOSを実行するモバイル・アプリケーション。iOSを実行するモバイル・アプリケーションは、インターネット・アイデンティティ・プロバイダを使用して認証するように構成できます。Mobile and Socialサーバーに接続するには、iOSアプリケーションでiOS用モバイル・サービスSDKを使用します。別個のSDKは不要です。

インターネット・アイデンティティ・サービスは、次の標準をサポートするアイデンティティ・プロバイダにサービスを提供します。

- OpenIDバージョン2.0

- OpenID Simple Registration Extension 1.0

- Open ID Attribute Exchange Extension 1.0

- OpenID Provider Authentication Policy Extension 1.0

- OAuth 1.0および2.0

表37-5に示したアイデンティティ・プロバイダのネイティブ・サポートは、Mobile and Socialのインストール後に提供されます。

表37-5 Mobile and Socialがネイティブにサポートするアイデンティティ・プロバイダ

アイデンティティ・プロバイダ

サポートされているプロトコル

Facebook

OAuth 2.0

Google

OpenID 2.0

LinkedIn

OAuth 1.0

Twitter

OAuth 1.0

Yahoo

OpenID 2.0

Javaプログラマは、Javaインタフェースを実装し、Mobile and Socialコンソールを使用してJavaクラスをMobile and Socialデプロイメントに追加することで、追加のOpenIDおよびOAuthアイデンティティ・プロバイダに対するリライイング・パーティのサポートを追加できます。詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「Mobile and Socialサーバーの機能の拡張」を参照してください。

37.6 インターネット・アイデンティティ・サービス・プロセスの理解

次のシナリオでは、インターネット・アイデンティティ・サービスを使用しているときのBasic認証プロセスについて説明します。

1. ユーザーが保護されたリソースへのアクセスを要求すると、Mobile and Socialにリダイレクトされます。

2. Mobile and Social (RP)は、Googleなど(アイデンティティ・プロバイダ)の資格証明を使用してログインするかどうかをユーザーに尋ねます。

3. Mobile and Socialは、ユーザー名とパスワードを入力するGoogleのログイン・ページにユーザーをリダイレクトします。

4. Googleは資格証明を検証し、ユーザーをMobile and Socialにリダイレクトします。それと同時に、アイデンティティ・プロバイダは、その構成に基づいて、Mobile and Socialにアイデンティティの属性を返します。
ユーザーが組織のアカウントを持っていない場合は、ユーザーにアカウントを登録するように促します。登録フォームは、アイデンティティ・プロバイダから返された情報で入力済にされています。

注意:

Access Managerの場合、ユーザーはローカルに登録されている必要があります。それ以外の場合は、アクセスが許可されません。Access Managerを使用していないときには、ユーザーは保護されたリソースにリダイレクトされ、ユーザーが登録されていない場合でもアクセスが許可されます。詳細は、第37.7.1項「インターネット・アイデンティティ・サービスとOracle Access Managerの併用」を参照してください。

追加のシナリオについては、この項で説明します。

- ローカル・アカウントを持つユーザーが返された場合の認証

- ローカル・アカウントのない新しいユーザーの認証

- OAuthを使用したアクセス・トークンの取得

- Access Managerとインターネット・アイデンティティ・サービスによるユーザー認証

- ユーザーのローカル認証

37.6.1 ローカル・アカウントを持つユーザーが返された場合の認証

このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図ではLocal AuthおよびIdRepositoryと表示)の間の認証フローを説明します。このシナリオでは、ユーザーがすでにローカル・アカウントを持っているかどうかは、ローカル・アイデンティティ・リポジトリによって判断されます。そのため、Mobile and Socialが作成のプロンプトを表示することはありません。このプロセスの説明に後に、図37-7を示します。

1. ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバーは、ユーザー・ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。

2. ユーザーがアイデンティティ・プロバイダを選択します。

3. Mobile and Socialサーバーが選択されたアイデンティティ・プロバイダにユーザーをリダイレクトすると、ログイン・ページが表示されます。

4. ユーザーが認証時にユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。

5. ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合せます。
アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持つユーザーであると判断されます。

- モバイル・アプリケーションまたは直接統合されたWebアプリケーションがMobile and Socialを使用して認証している場合は、Mobile and Socialサーバーはユーザーのブラウザに認証アサーションを送信します。

- Access Mangerによって保護されたアプリケーションが認証している場合は、ユーザーがローカル・アカウントを持っている場合のみ、Access Managerはユーザーのためにセッションを作成します。(新しく登録されたユーザーは、ローカル・アカウント保持者とみなされます。)

6. ユーザーのブラウザは、Mobile and Socialによって送信された認証アサーションを、保護されたリソースのアクセス管理サービスに送信します。

7. アクセス管理サービスは、必要に応じて追加の認証ステップを実行します。

8. アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。

図37-7 ローカル・アカウントを持つユーザーが返された場合の認証

「図37-7 ローカル・アカウントを持つユーザーが返された場合の認証」の説明

37.6.2 ローカル・アカウントのない新しいユーザーの認証

このシナリオでは、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)、アイデンティティ・プロバイダおよびローカル・ユーザー認証サービス(図ではLocal AuthおよびIdRepositoryと表示)の間の認証フローを説明します。このシナリオでは、ユーザーはローカル・アカウントを持っていないため、Mobile and Socialによりアカウントの作成が求められます。このプロセスの説明に後に、図37-8を示します。

1. ユーザーがWebブラウザで保護されたリソースのURLを開くと、Mobile and Socialサーバー(この図ではRP)は、ユーザー・ログイン・ページとアイデンティティ・プロバイダ(Google、Yahoo、Facebook、Twitter、LinkedInなど)の選択メニューをユーザーに表示します。

2. ユーザーがアイデンティティ・プロバイダを選択します。

3. Mobile and Socialサーバーは選択されたアイデンティティ・プロバイダにユーザーをリダイレクトし、このプロバイダがログイン・ページを表示します。

4. ユーザー認証時にユーザーがユーザー名とパスワードを入力すると、アイデンティティ・プロバイダはMobile and Socialサーバーに認証アサーションを送信します。

5. ユーザーがローカル・アカウントを持っているかどうかについて、Mobile and Socialサーバーがアイデンティティ・リポジトリに問い合わせます。
アイデンティティ・リポジトリは、ディレクトリ・サーバー、データベース、Oracle Identity Managerまたはそれに類似したものになります。このユーザーは、ローカル・アカウントを持たないユーザーであると判断されます。Mobile and Socialによって、次のように続行されます。

- アイデンティティ・プロバイダがOpen IDプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得された認証アサーションのデータを処理することで、ユーザーのプロファイル属性を取得します。

- アイデンティティ・プロバイダがOAuthプロトコルを使用する場合は、Mobile and Socialサーバーは以前に取得されたアクセス・トークンを使用してアイデンティティ・プロバイダに別個のHTTPコールを行って、ユーザーのプロファイル属性を取得します。

6. Mobile and Socialサーバーは、新規ユーザー登録フォームをユーザーのブラウザに送信します。
この登録フォームは、アイデンティティ・プロバイダによって送信されたユーザー・プロファイル属性を使用して入力済にされています。

7. ユーザーは登録フォームの入力を完了して、そのフォームをインタフェース接続しているユーザー・レジストリ(ディレクトリ・サーバーまたはOracle Identity Manager)に送信し、アカウントを作成します。
アイデンティティ・プロバイダからアクセス・トークンが取得される場合は、アクセス・トークンもMobile and Socialからクライアント・アプリケーションに返されます。

8. クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。

9. アクセス管理サービスが、保護されたリソースへのユーザーのアクセスを許可します。

図37-8 ローカル・アカウントのない新しいユーザーの認証

「図37-8 ローカル・アカウントのない新しいユーザーの認証」の説明

37.6.3 OAuthを使用したアクセス・トークンの取得

この項では、ユーザー、Mobile and Socialサーバー(リライイング・パーティ)およびOAuthアイデンティティ・プロバイダ間のOAuth認証およびアクセス・トークン取得フローに関する補足的な詳細を説明します。(FacebookではOAuth 2.0プロトコルが、LinkedInとTwitterではOAuth 1.0プロトコルが使用されています。)このシナリオでは、サーバーはOAuthアイデンティティ・プロバイダとインタフェース接続して、OAuthアイデンティティ・プロバイダによって保護されたリソースにアクセスするための認可コードとアクセス・トークンを取得します。このシナリオのクライアント・アプリケーションは、Java準拠のアプリケーション・サーバー上で実行しているWebアプリケーションまたはモバイル・アプリケーションのどちらかになります。このプロセスの説明に後に、図37-9を示します。

1. ユーザーがクライアント・アプリケーションを開始すると、そのアプリケーションは保護されたWebページをユーザーのブラウザに返します。

2. ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。

3. ユーザーが保護されたリソースにアクセスできるように、クライアント・アプリケーションはMobile and Socialサーバーにアクセス・トークンの取得を求めます。
Mobile and Socialのキャッシュ内に有効なアクセス・トークンがある場合は、Mobile and Socialによってアクセス・トークンがクライアント・アプリケーションにフォワードされ、認証シナリオは手順10にスキップします。このフローでは、Mobile and Socialがローカル・キャッシュにアクセス・トークンを保持していないと仮定します。

4. アクセス・トークンがローカル・キャッシュに存在しないため、Mobile and SocialはユーザーのかわりにOAuthアイデンティティ・プロバイダによる認証リクエストを開始します(OAuthクライアントID、スコープ情報およびリダイレクトURLを埋め込むためにHTTPヘッダーを利用します)。

5. OAuthアイデンティティ・プロバイダは、ログイン・ページを表示します。

6. ユーザーがOAuthアイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力して、ユーザーのプロファイル属性をMobile and Socialサーバー(および拡大解釈してクライアント・アプリケーション)に提供することをアイデンティティ・プロバイダに対して承諾します。

7. OAuthアイデンティティ・プロバイダは、認可コードをMobile and Socialサーバーに送信します。

8. Mobile and Socialサーバーは、アクセス・トークン・リクエストをOAuthアイデンティティ・プロバイダに送信します。
リクエストには、前の手順で受信された認可コードに加え、OAuthクライアントIDおよびクライアント資格証明が含まれます。

9. OAuthアイデンティティ・プロバイダは、アクセス・トークンをMobile and Socialサーバーに返します。

10. Mobile and Socialサーバーは、アクセス・トークン(ユーザーIDとOAuthクライアントを含む)をキャッシュして、そのアクセス・トークンをクライアント・アプリケーションに転送します。

11. クライアント・アプリケーションはアクセス・トークンを使用して保護されたリソースにアクセスし、保護されたページをユーザーのブラウザに返します。

図37-9 OAuthアイデンティティ・プロバイダによるユーザー認証

「図37-9 OAuthアイデンティティ・プロバイダによるユーザー認証」の説明

37.6.4 Access Managerとインターネット・アイデンティティ・サービスによるユーザー認証

このシナリオでは、ユーザー、Access Manager、Mobile and Socialサーバー(リライイング・パーティ)およびアイデンティティ・プロバイダ間の認証プロセスを説明します。ユーザーは、ローカル・アカウントを持っているか、求められたときにローカル・アカウントに登録する必要があることに注意してください。そのようにしないと、Access Managerは保護されたリソースへのユーザーのアクセスを許可しないため、ユーザーはログイン・ページにリダイレクトされます。このプロセスの説明に後に、図37-10を示します。

1. ユーザーがクライアント・アプリケーション上で保護されたリソースを開こうとします。

2. リソースを保護するWebゲートが、アクセス・リクエストをインターセプトします。

3. Access Managerがリソースを保護する認証ポリシーを識別し、Mobile and Socialサーバーが提供するログイン・ページにユーザーをリダイレクトします。

4. ログイン・ページに、ソーシャル・アイデンティティ・プロバイダのメニューが表示されます。

5. ユーザーはOpenIDアイデンティティ・プロバイダを選択し、Access ManagerはユーザーのブラウザをMobile and Socialサーバーにリダイレクトします。Mobile and Socialサーバーはユーザーのブラウザを、選択されたソーシャル・アイデンティティ・プロバイダ(Google、Facebook、Twitterなど)のログイン・ページにリダイレクトします。

6. ユーザーはソーシャル・アイデンティティ・プロバイダのログイン・ページにユーザー名とパスワードを入力します。
アイデンティティ・プロバイダが認証プロセスを完了し、アイデンティ情報の共有に対するユーザーの承諾を求めます(該当する場合)。

7. 認証が完了すると、ソーシャル・アイデンティティ・プロバイダはブラウザをリダイレクトしてMobile and Socialサーバーに戻します。
アイデンティティ・プロバイダが提供するアイデンティ・アサーションのさらなる処理とユーザー・アイデンティティ情報の取得の後、Mobile and SocialサーバーはユーザーのブラウザをAccess Managerにリダイレクトします。今回は、ページ・リクエストのHTTPヘッダーで、ユーザーの認証ステータスと属性をAccess Managerに提供します。

8. Access Managerはユーザー・セッションを作成し、保護されたリソースにユーザーをリダイレクトします。

図37-10 Access Managerによるユーザーの認証

「図37-10 Access Managerによるユーザーの認証」の説明

37.6.5 ユーザーのローカル認証

このシナリオでは、ユーザーがソーシャル・アイデンティティ・プロバイダを通じた認証を選択するかわりに、ローカル・アカウントを使用して認証する場合の認証プロセスを説明します。このプロセスの説明に後に、図37-11を示します。

1. ユーザーが保護されたリソースのURLをWebブラウザで開くと、Mobile and Socialサーバーがログイン・ページとアイデンティティ・プロバイダの選択メニューをユーザーに表示します。

2. ユーザーはローカル認証の使用を選択して、ログイン・ページにユーザー名とパスワードを入力します。

3. クライアント・アプリケーションのアクセス管理サービスは、追加の認証ステップを必要に応じて実行します。

- JWTトークン・サービスを使用する場合は、ユーザー・トークンを作成できます。

- OAMトークン・サービスは、ローカル認証フロー時にトークンを返しません。

4. アクセス管理サービスがユーザーのためにセッションを作成し、ユーザーは保護されたリソースにアクセスします。

図37-11 ユーザーのローカル認証

「図37-11 ユーザーのローカル認証」の説明

37.7 インターネット・アイデンティティ・サービスの使用

次の各項では、インターネット・アイデンティティ・サービスを使用する方法について説明します。インターネット・アイデンティティ・サービスの統合方法の例については、第37.6項「インターネット・アイデンティティ・サービスの処理の理解」を参照してください。

- インターネット・アイデンティティ・サービスとOracle Access Managerの併用

- インターネット・アイデンティティ・サービスとモバイル・サービスの使用

- インターネット・アイデンティティ・サービスSDKの使用

37.7.1 インターネット・アイデンティティ・サービスとOracle Access Managerの併用

インターネット・アイデンティティ・サービスをAccess Managerと統合すると、ユーザーはインターネット・アイデンティティ・プロバイダの資格証明を使用してAccess Managerで保護されているリソースにログインできます。このアレンジでは、ユーザーは自分たちのアイデンティティ・プロバイダの資格証明を入力します。Access Managerは、ユーザーのログイン・リクエストをMobile and Socialにフォワードし、Mobile and Socialはバックグラウンドのアイデンティティ・プロバイダを使用して認証プロセスを完了します。Mobile and Social (リライイング・パーティ)は、ユーザーをAccess Managerにリダイレクトします。同時に、Mobile and SocialはAccess Managerに、アイデンティティ・プロバイダが送信したユーザーの認証ステータスとユーザー属性を提供します。Access Managerが認証にインターネット・アイデンティティ・サービスを使用する方法の詳細は、第37.6.4項「Access Managerとインターネット・アイデンティティ・サービスによるユーザー認証」を参照してください。

37.7.2 インターネット・アイデンティティ・サービスとモバイル・サービスの使用

インターネット・アイデンティティ・サービスを使用してモバイル・デバイスで認証できるように、モバイル・サービスを構成できます。アイデンティティ・プロバイダによってユーザーの資格証明が検証された後に、組織でのアカウントを作成するようにインターネット・アイデンティティ・サービスによってユーザーに促すことができます。アイデンティティ・プロバイダから返されたデータで新規ユーザー登録フォームを入力済にする場合は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」を参照してください。

37.7.3 インターネット・アイデンティティ・サービスSDKの使用

Java準拠のWebアプリケーションを保守する開発者は、Mobile and Socialインターネット・アイデンティティ・サービスSDKを使用して、そのWebオファリングにインターネット・アイデンティティ・サービス機能を追加できます。このSDKは、Javaが駆動するWebアプリケーションでのみ使用できます。SDKの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」を参照してください。

38 モバイル・サービスの構成

Mobile and Socialには、モバイル・サービスを構成するためのGUIが用意されています。この章では、Oracle Access Managementコンソールを使用して、モバイル・サービスを構成する方法について説明します。この章の内容は、次のとおりです。

- モバイル・サービスのGUIのナビゲート

- モバイル・サービスの構成の理解

- サービス・プロバイダの定義

- サービス・プロファイルの定義

- セキュリティ・ハンドラ・プラグインの定義

- アプリケーション・プロファイルの定義

- サービス・ドメインの定義

- ジェイルブレーク検出ポリシーの使用

- その他のOracle製品を使用したモバイル・サービスの構成

注意:

モバイル・サービスは、WLSTを使用することでコマンドラインから構成することもできます。Mobile and SocialのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

38.1 モバイル・サービスのGUIのナビゲート

モバイル・サービスのグラフィカル・ユーザー・インタフェース(GUI)は、管理者が正常に認証されてOracle Access Managementコンソールへのアクセスが得られると表示できるようになります。このコンソールは、次の部分に分割されています。

- ホーム・エリアは、コンソールが最初に表示されたときに、GUIの右側に配置される広いウィンドウです。このページには、モバイル・サービスのほとんどの構成オブジェクトが一覧表示され、構成プロセスを論理的な順序で進められるように編成されています。ホーム・エリア内の構成オブジェクトは、パネルの左上隅にある矢印ボタンをクリックすることで展開または縮小できるパネルに表示されます。

- ナビゲーション・ペインは、GUIの左部分に表示されます。このペインは、Mobile and Social構成オブジェクトを階層型ビューで表示します。ほとんどの場合、構成オブジェクトの作成、編集および削除には、ホーム・エリアまたはナビゲーション・ペインのいずれかを使用できます。(ただし、ジェイルブレーク検出ポリシー構成オブジェクトを開く場合は、ナビゲーション・ペインを使用する必要があります。)ナビゲーション・ペイン内のコントロールを使用すると、構成オブジェクトを作成、表示、編集および削除できます。
ナビゲーション・ペインを使用すると、構成オブジェクトを関係ビューまたはカテゴリ・ビューで表示できます。関係ビューには、構成オブジェクトが階層順に表示されます(サービス・ドメインが一番上)。関係ビューを使用すると、オブジェクトを次のような方法で表示できます。

- サービス・プロファイルとアプリケーション・プロファイルとの関係、およびそれらが属するサービス・ドメインを表示します。

- サービス・プロバイダとそれに接続されたサービス・プロファイルの関係を表示します。

- セキュリティ・ハンドラ・プラグインを表示します。

- ジェイルブレーク検出ポリシーを表示します。

カテゴリ・ビューには、構成オブジェクトを簡単に参照できるようにするフラット構造を使用して、構成オブジェクトがオブジェクト・タイプ別にリストされます。2つのビューを切り替えるには、ツリービュー・ペインの上部にあるメニュー・バーのボタンを使用します。

次の手順を実行すると、モバイル・サービスの構成ページにアクセスできます。

1. Oracle Access Managementコンソールにログインします。

2. コンソールの上部にある、「システム構成」タブをクリックします。

3. ページの左側にある「Mobile and Social」をクリックします。

4. 「モバイル・サービス」をクリックします。
「Mobile and Socialへようこそ - モバイル・サービス」ページがホーム・エリアにロードされます。

38.2 モバイル・サービスの構成の理解

「Mobile and Socialへようこそ - モバイル・サービス」の構成ページは、ホーム・エリアに表示されます。このページは複数のパネルに分割されていて、管理時には各パネルを表示または非表示にできます。これらのパネルでは、クライアント・アプリケーションとMobile and Socialサーバーの通信方法や、Mobile and Socialサーバーとバックエンドのアイデンティティ・サービス(クライアント・アプリケーションで使用)の通信方法を定義します。次の各項では、モバイル・サービスの各パネルについて詳細に説明します。

- サービス・プロバイダの理解

- サービス・プロファイルの理解

- セキュリティ・ハンドラ・プラグインの理解

- アプリケーション・プロファイルの理解

- サービス・ドメインの理解

注意:

Mobile and Socialには、一般的なデプロイメント・シナリオをサポートする、事前構成済オブジェクトが含まれています。これらのオブジェクトは、わずかな変更を加えるだけでMobile and Socialの準備と実行が可能になるように設計されています。各項には、インストール後に利用できる事前構成済オブジェクトの一覧が示されています。

38.2.1 サービス・プロバイダの理解

サービス・プロバイダは、クライアント・アプリケーションで使用できるようにするバックエンド・サービスごとに定義します。サービス・プロバイダとしてバックエンド・サービスを構成することで、Mobile and Socialサーバーはそのプロバイダと通信する方法を認識します。バックエンド・サービスは、次のサービス・プロバイダ・タイプの1つとして構成できます。

- 認証サービス・プロバイダ: アイデンティティ・プロバイダとインタフェース接続し、バックエンド・サービスがユーザー、モバイル・デバイス、クライアント・アプリケーションおよびアクセス権を認証し、それに従って認証トークンを発行できるようにします。Mobile and Socialは、Access ManagerとJSON Web Token (JWT)を、それらに独自のサービス・プロバイダとサービス・プロファイルの構成オブジェクトでサポートします。さらに、モバイル・クライアントの認証と非モバイル・クライアントの認証は、個別に管理されるため、それぞれのトークン・タイプは個別のモバイルおよび非モバイルのサービス・プロバイダとサービス・プロファイルを持つようになります。次の事前構成済の認証サービス・プロバイダは、一般的なデプロイメントで使用できます。

- OAMAuthentication: Oracle Access Manager認証トークン・サービス・プロバイダ(Access ManagerとMobile and Socialを両方インストールしている場合にのみ使用可能)

- MobileOAMAuthentication: モバイルのOracle Access Manager認証トークン・サービス・プロバイダ(Access ManagerとMobile and Socialを両方インストールしている場合にのみ使用可能)

- JWTAuthentication: JSON Web Token認証サービス・プロバイダ

- MobileJWTAuthentication: モバイルのJSON Web Token認証サービス・プロバイダ

- InternetIdentityAuthentication: インターネット・アイデンティティのJSON Web Tokenプロバイダ。これにより、モバイル・サービスを使用してMobile and Socialのインターネット・アイデンティティ・サービスからの認証結果を受け入れるアプリケーションの事前構成済サポートが提供されます(第37.5項「インターネット・アイデンティティ・サービスの理解」を参照)。

カスタム認証サービス・プロバイダの作成方法については、第38.3.1項「認証サービス・プロバイダの定義、変更または削除」を参照してください。

- 認可サービス・プロバイダ: 認可(アクセス)を決定するバックエンド・アイデンティティ・プロバイダとインタフェース接続します。事前構成済のOAMAuthorization認可サービス・プロバイダ(Access ManagerとMobile and Socialを両方インストールしている場合にのみ使用可能)は、一般的なデプロイメント用に提供されています。カスタム認可サービス・プロバイダの作成方法については、第38.3.2項「認可サービス・プロバイダの定義、変更または削除」を参照してください。

- ユーザー・プロファイル・サービス・プロバイダ: ディレクトリ・サーバーとインタフェース接続して、ユーザー・プロファイル・レコードを参照および更新します。事前構成済のユーザー・プロファイル・サービス・プロバイダは、一般的なデプロイメント用に提供されています。カスタム・ユーザー・プロファイル・サービス・プロバイダの作成方法については、第38.3.3項「ユーザー・プロファイル・サービス・プロバイダの定義、変更または削除」を参照してください。

38.2.2 サービス・プロファイルの理解

サービス・プロバイダを定義した後で、それに対する1つ以上のサービス・プロファイルを定義します。サービス・プロファイルは、Mobile and Socialサーバー上のサービス・プロバイダのサービス・エンドポイントURLを定義する論理エンベロープです。1つのサービス・プロバイダに複数のサービス・プロファイルを作成して、各種のトークン機能とサービス・エンドポイントを定義できます。各サービス・プロバイダ・インスタンスには、対応する少なくとも1つのサービス・プロファイルが必要です。Mobile and Socialには、事前構成済サービス・プロバイダ構成オブジェクトごとの事前構成済サービス・プロファイルが含まれています。詳細は、第38.2.1項「サービス・プロバイダの理解」を参照してください。

38.2.3 セキュリティ・ハンドラ・プラグインの理解

セキュリティ・ハンドラ・プラグインは、信頼およびリスク分析のための追加のロジックを参照することで、セキュリティを高めます。(そのような追加のロジックによって、リスクのある特定の操作が拒否されることがあります。)セキュリティ・ハンドラ・プラグインは、クライアント・アプリケーションの登録などの認証サービス操作中に、セキュリティ・ロジックを適用します。セキュリティ・ハンドラ・プラグインの使用はオプションです。このバージョンのソフトウェアで提供されるセキュリティ・ハンドラ・プラグインは、モバイル・アプリケーション用に最適化されています。使用する場合は、モバイル関連のサービス・ドメインとその認証サービスおよびクライアント・アプリケーションにのみ適用します。非モバイル・アプリケーションでは、セキュリティ・ハンドラ・プラグインを使用しないでください。

Mobile and Socialは、機密のセキュリティ操作時(認証時など)やトークン取得に関連する操作時に、セキュリティ・ハンドラ・プラグインを起動します。Mobile and Socialには、次の事前構成済セキュリティ・ハンドラ・プラグインが含まれています。

- OAAMSecurityHandlerPluginにより、Oracle Adaptive Access Managerで使用可能な高度なデバイス登録と、リスクベースの強力な認証ロジックが有効になります。

- Defaultセキュリティ・ハンドラ・プラグインは、より限定的なデバイス登録ロジックを提供します。

38.2.4 アプリケーション・プロファイルの理解

アプリケーション・プロファイルには、サービス・プロバイダが提供するサービスを利用するクライアント・アプリケーションの構成とセキュリティ・プロパティを記述します。アプリケーション・プロファイルは、モバイル・アプリケーションを使用する場合、またはセキュアなアプリケーション保護がないサービスで非モバイル・アプリケーションを使用する場合に必要です。定義される属性には、アプリケーション・プロファイルの名前、アプリケーションについての簡単な説明、名前と値の属性をペアにしたリスト、およびそのアプリーションのモバイル構成設定などがあります。(モバイル構成設定には、プロファイルをキャッシュできる最長期間(分単位)、認証の再試行の許容可能な回数、オフライン認証が許可されるかどうかなどのオプションがあります。)また、アプリケーションに必要なモバイル・デバイス属性(phonecarriername、phonenumber、osversionなど)を選択することもできます。1つのアプリケーション・プロファイルを複数のサービス・ドメインに割り当てることができます。

38.2.5 サービス・ドメインの理解

サービス・ドメインは、アプリケーション・プロファイルとセキュリティ・ハンドラ・プラグイン(オプション)を含むサービス・プロファイルを関連付けるために、論理的にサーバーをグループ化したものです。サービス・ドメインは、アプリケーションにMobile and Socialのサービスへのアクセスを許可する方法を指定します。通常、組織は、モバイル・アプリケーションの管理用に1つと、別に非モバイル・アプリケーションの管理用に1つのサービス・ドメインを持っています。サービス・ドメインを作成するときには、次を実行します。

- サービス・ドメインで、モバイル・アプリケーションを管理するのか、デスクトップ・アプリケーションを管理するのかを決定します。

- サービス・ドメインの認証スキームおよびセキュリティ・ハンドラ・プラグイン(オプション)を選択します。

- 1つ以上のモバイルSSOエージェントを追加して、エージェント間の優先順位を構成します。

- 1つ以上のアプリケーションをサービス・ドメインに追加して、どのアプリケーションにモバイルSSOエージェントの使用を許可するかを構成します。

- サービス・ドメインに対して少なくとも1つのサービス・プロファイルを選択します。

- セキュリティ設定を構成して、サービス・ドメインのサービスを保護します。

Mobile and Socialには、次の事前構成済サービス・ドメインが含まれています。

- デフォルト(サービス・ドメイン)は、非モバイル・アプリケーション用に事前構成されています。

- モバイル・サービス・ドメインは、モバイル・アプリケーション用に事前構成されています。

これらのサービス・ドメインは、独自のサービス・ドメインを作成するためにどちらかをテンプレートとして使用することも、組織のニーズに合せて変更することもできます。モバイル・サービス・ドメインに追加できるのは、モバイル認証サービス・プロファイルのみです。

38.3 サービス・プロバイダの定義

サービス・プロバイダは、クライアント・アプリケーションで使用可能なバックエンド・サービスごとに定義します。これにより、Mobile and Socialサーバーが定義済のバックエンド・サービス・プロバイダとインタフェース接続する方法を構成します。提供しているサービスに応じて、使用可能なサービス・プロバイダ・オプションの1つまたは2つを構成するだけでよい場合があります。たとえば、認証サービスのみを提供する場合、「ユーザー・プロファイル・サービス・プロバイダ」や「認可サービス・プロバイダ」を定義する必要はありません。この項では、次の手順について説明します。

- 認証サービス・プロバイダの定義、変更または削除

- 認可サービス・プロバイダの定義、変更または削除

- ユーザー・プロファイル・サービス・プロバイダの定義、変更または削除

38.3.1 認証サービス・プロバイダの定義、変更または削除

認証サービス・プロバイダを使用すると、Mobile and Socialはトークン交換によるバックエンド認証サービスを使用してユーザー、クライアント・アプリケーションおよびアクセス権を認証できます。認証と検証の成功時に、トークンがクライアント・アプリケーションに返される場合があります。サポートされる認証タイプは、次のとおりです。

- Access Managerと一緒にインストールした場合、Mobile and SocialはJSON Web Token (JWT)とAccess Managerトークンをサポートします。

- Access Managerと一緒にイントールしていない場合は、JSON Web Token (JWT)のみがサポートされます。

次の各項では、認証サービス・プロバイダについて説明します。

- 認証サービス・プロバイダの作成

- 認証サービス・プロバイダの編集または削除

- 事前構成済認証サービス・プロバイダの理解

38.3.1.1 認証サービス・プロバイダの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロバイダ」パネルで「作成」をクリックして、「認証サービス・プロバイダの作成」を選択します。
「認証サービス・プロバイダ」の「構成」ページが表示されます。

3. 認証サービス・プロバイダのプロパティに値を入力します。

- 名前: この認証サービス・プロバイダに一意の名前を入力します。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

- サービス・プロバイダのJavaクラス: この認証サービス・プロバイダを実装するJavaクラスの名前を入力します。

4. 認証サービス・プロバイダの属性と値を、表38-1(OAMAuthenticationおよびMobileOAMAuthenticationサービス・プロバイダ・タイプ)または表38-3(JWTAuthenticationおよびMobileJWTAuthenticationサービス・プロバイダ・タイプ)に基づいて追加または削除します。

注意:

カスタム認証サービス・プロバイダを作成した場合は、「属性」パネルを使用してさらに構成を進めます。JWTAuthenticationおよびMobileJWTAuthenticationサービス・プロバイダの場合は、カスタム属性は使用されません。

- 表38-1と表38-2は、Access Managerと統合しているMobile and Sociaに固有のものです。表38-1の値は、OAMAuthenticationとMobileOAMAuthenticationの両方のサービス・プロバイダ・タイプに適用されます。表38-2の値は、Webゲート・エージェントを構成するものです。

表38-1 Access Manager認証サービス・プロバイダのデフォルト属性

名前

値

注意

OAM_VERSION

OAM_11G

使用しているOracle Access Managerのバージョンに応じて、OAM_11GまたはOAM_10Gです。

DEBUG_VALUE

0

TRANSPORT_SECURITY

OPEN

このAccessGateとアクセス・サーバーとの間のメッセージの暗号化方式を指定します。暗号化方式は一致している必要があります。有効な値は次のとおりです。

- OPEN

- SIMPLE

- CERT

OAM_SERVER_1

localhost:5575

プライマリOracle Access Managementサーバーのホスト名およびポート番号を指定します。

OAM_SERVER_1_MAX_CONN

4

このMobile and SocialインスタンスがOAM_SERVER_1と確立できる接続の最大数を指定します。デフォルト値は4です。

OAM_SERVER_2

oam_server_2:5575

セカンダリOracle Access Managementサーバーのホスト名およびポート番号を指定します。

OAM_SERVER_2_MAX_CONN

4

このMobile and SocialインスタンスがOAM_SERVER_2と確立できる接続の最大数を指定します。デフォルト値は4です。

IDContextEnabled

true

この属性を追加してtrueの値を設定すると、アイデンティティ・コンテキストが有効になります。「Oracle Access Management Mobile and Socialの構成」を参照してください。

表38-2 認証サービス・プロバイダのWebゲート・エージェントのデフォルト属性

名前

値

注意

WebゲートID

接続先のWebゲート・インスタンスを識別するWebゲート・エージェント名を入力します。

暗号化パスワード

「WebゲートID」用の暗号化されたパスワードをコピーして貼り付けます

OAM-Domain-Directory/output/Profile-Name/ObAccessClient.xmlファイルを見つけて、要素ParamName=accessClientPasswdの暗号化されたパスワード値をコピーします。

- 表38-3は、JWT認証サービス・プロバイダに接続するMobile and Socialに固有のものです。この項の構成値は、JWTAuthenticationおよびMobileJWTAuthenticationの両方のサービス・プロバイダ・タイプに適用されます。

表38-3 JWT認証サービス・プロバイダのデフォルト属性

名前

値

注意

アイデンティティ・ディレクトリ・サービス名

ユーザーの検証に使用するディレクトリ・サービスをメニューから選択します。

JWTトークン・サービスは、ディレクトリ・サーバーを使用してユーザーを検証します。

暗号スキーム

RS512

JWTトークンのコンテンツへの署名に使用する暗号アルゴリズムです。デフォルト値はRS512です。(SHA-512ハッシュ・アルゴリズムを使用するRSA暗号化。)

有効期間

3600

トークンが有効とみなされる秒単位の時間です。デフォルト値は3600です。

リライイング・パーティ・トークン

有効

サービス・プロバイダが外部発行者からのセキュリティ・トークンを受け入れる必要がある場合は、「有効」を選択します。

発行者

「リライイング・パーティ・トークン」が有効になっている場合は、セキュリティ・トークン・サービス発行者を指定します。

5. 「作成」をクリックして、サービス・プロバイダ構成オブジェクトを作成します。

38.3.1.2 認証サービス・プロバイダの編集または削除

認証サービス・プロバイダを編集または削除するには、パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.3.1.3 事前構成済認証サービス・プロバイダの理解

Mobile and Socialでは、表38-4にリストされている認証サービスに事前構成済の認証サービス・プロバイダが提供されます。

トークン・タイプ(Access ManagerとJWT)ごとに、Mobile and Socialでは「すぐに使用できる」個別のモバイルおよび非モバイル(またはデスクトップ)サービス・プロバイダ構成が提供されます。個別の構成は、それぞれを各アクセス・モードのニーズに最も合わせて最適化できるようにするために提供されています。モバイル・デバイスは、モバイル・サービス・プロバイダを使用する必要がありますが、非モバイル・デバイスは、モバイル・サービス・プロバイダと非モバイル・サービス・プロバイダの両方を使用できます(適切な入力を提供している場合)。

モバイル・サービス・プロバイダは、クライアント登録ハンドルを使用して、モバイル・デバイスを登録します。これに対して、非モバイル・サービス・プロバイダは、クライアント・トークンを使用して、非モバイル・デバイスを認証します。Mobile and Socialのクライアント・トークン機能は無効にできますが、クライアント登録ハンドル機能は無効にできません。

表38-4 事前構成済の認証サービス・プロバイダ

認証サービス

Mobile and Socialサービス・プロバイダ名

説明

Access Manager

OAMAuthentication

デスクトップ・デバイスを使用しているユーザーが、Access Managerを使用して認証を受けるための事前構成済サポートを提供します。

このサービス・プロバイダは、クライアント・トークンを発行できますが、モバイル・デバイスの登録はできません。

次のJavaクラスがこのサービス・プロバイダを実装します:

oracle.security.idaas.rest.provider.token.OAMSDKTokenServiceProvider

Mobile Access Manager

MobileOAMAuthentication

モバイル・デバイスを使用しているユーザーが、Access Managerを使用して認証を受けるための事前構成済サポートを提供します。

このサービス・プロバイダは、ユーザーの認証時におけるクライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。

次のJavaクラスがこのサービス・プロバイダを実装します:

oracle.security.idaas.rest.provider.token.MobileOAMTokenServiceProvider

JSON Web Token

JWTAuthentication

非モバイル・アプリケーションを使用しているユーザーが、JSON Web Token形式を使用して認証を受けるための事前構成済サポートを提供します。JSON Web Tokenは、HTTP認可ヘッダーなど、領域に制約がある環境に適したコンパクトなトークン形式です。

このサービス・プロバイダは、クライアント・トークンを発行できますが、クライアント登録ハンドルを使用した新しいデバイスの登録はできません。

次のJavaクラスがこのサービス・プロバイダを実装します:

oracle.security.idaas.rest.provider.token.JWTTokenServiceProvider

Mobile JSON Web Token

MobileJWTAuthentication

モバイル・デバイスを使用しているユーザーが、Mobile JSON Web Token形式を使用して認証を受けるための事前構成済サポートを提供します。

このサービス・プロバイダは、クライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。

次のJavaクラスがこのサービス・プロバイダを実装します:

oracle.security.idaas.rest.provider.token.MobileJWTTokenServiceProvider

Internet Identity Services Web Token

InternetIdentityAuthentication

モバイル・サービスを使用するアプリケーションが、インターネット・アイデンティティ・サービス(たとえば、Google、Facebook、Twitterなど)から認証結果を受け入れるための事前構成済サポートを提供します。

このサービス・プロバイダは、クライアント登録ハンドルを使用した新しいデバイスの登録をサポートしています。ユーザーがアイデンティティ・プロバイダを使用して認証を受けた後、このサービス・プロバイダによって、要求側のクライアント・アプリケーションにユーザー・トークンが発行されます。このユーザー・トークンによって、ユーザーはそのデバイスのクライアント登録ハンドルを取得できます。

このサービスではJSON Web Tokenサービスと同じJavaクラスを使用しますが、それは追加された2つの名前と値の属性のペアで構成されます。

次のJavaクラスがこのサービス・プロバイダを実装します:

oracle.security.idaas.rest.provider.token.JWTTokenServiceProvider

38.3.2 認可サービス・プロバイダの定義、変更または削除

認可サービス・プロバイダを使用すると、バックエンド・アイデンティティ・サービスは接続されているアプリケーションのかわりに認可を決定できます。この項では、認可サービス・プロバイダについて、次の内容を説明します。

- 認可サービス・プロバイダの作成

- 認可サービス・プロバイダの編集または削除

- 事前構成済認可サービス・プロバイダの理解

38.3.2.1 認可サービス・プロバイダの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロバイダ」パネルで「作成」をクリックして、「認可サービス・プロバイダの作成」を選択します。
「認可サービス・プロバイダ」の「構成」ページが表示されます。

3. 認可サービス・プロバイダのプロパティに値を入力します。

- 名前: この認可サービス・プロバイダの一意の名前を入力します。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

- サービス・プロバイダのJavaクラス: この認可サービス・プロバイダを実装するJavaクラスの名前を入力します。

4. 認可サービス・プロバイダの属性と値を、表38-5に基づいて追加または削除します。

表38-1 Access Manager認可サービス・プロバイダのデフォルト属性

名前

値

注意

OAM_VERSION

OAM_11G

使用しているOracle Access Managerのバージョンに応じて、OAM_11GまたはOAM_10Gです。

DEBUG_VALUE

0

TRANSPORT_SECURITY

OPEN

このAccessGateとアクセス・サーバーとの間のメッセージの暗号化方式を指定します。暗号化方式は一致している必要があります。有効な値は次のとおりです。

- OPEN

- SIMPLE

- CERT

OAM_SERVER_1

localhost:5575

プライマリOracle Access Managementサーバーのホスト名およびポート番号を指定します。

OAM_SERVER_1_MAX_CONN

4

このMobile and SocialインスタンスがOAM_SERVER_1と確立できる接続の最大数を指定します。デフォルト値は4です。

OAM_SERVER_2

oam_server_2:5575

セカンダリOracle Access Managementサーバーのホスト名およびポート番号を指定します。

OAM_SERVER_2_MAX_CONN

4

このMobile and SocialインスタンスがOAM_SERVER_2と確立できる接続の最大数を指定します。デフォルト値は4です。

5. Webゲート・エージェントを新規に作成するか、既存のものに値を入力して、Webゲート・エージェントを構成します(表38-6を参照)。Webゲート・エージェント構成値は、モバイル・サービスとAccess Managerの間の統合に固有のものです。

表38-6 認可サービス・プロバイダのWebゲート・エージェントのデフォルト属性

名前

値

注意

WebゲートID

接続先のWebゲート・インスタンスを識別するWebゲート・エージェント名を入力します。

暗号化パスワード

「WebゲートID」用の暗号化されたパスワードをコピーして貼り付けます

OAM-Domain-Directory/output/Profile-Name/ObAccessClient.xmlファイルを見つけて、要素ParamName=accessClientPasswdの暗号化されたパスワード値をコピーします。

6. 「作成」をクリックして、サービス・プロバイダ構成オブジェクトを作成します。

38.3.2.2 認可サービス・プロバイダの編集または削除

認可サービス・プロバイダを編集または削除するには、パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.3.2.3 事前構成済認可サービス・プロバイダの理解

Mobile and Socialには、OAMAuthorization認可サービスプロバイダという名前の、Access Manager用の事前構成済認可サービス・プロバイダが用意されています。Javaクラスのoracle.security.idaas.rest.provider.authorization.OAMSDKAuthZServiceProviderが、事前構成済の認可サービス・プロバイダを実装します。

38.3.3 ユーザー・プロファイル・サービス・プロバイダの定義、変更または削除

ユーザー・プロファイル・サービス・プロバイダを使用すると、アプリケーションでディレクトリ・サーバーを問合せおよび更新できます。次に示すように、LDAP準拠の多数のディレクトリ・サーバーがサポートされています。

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

- Oracle Internet Directory

- Oracle Unified Directory

- Oracle Virtual Directory (Oracle Internet Directoryテンプレートを使用)

- OpenLDAP

- IBM Tivoli Directory Server (OpenLDAPテンプレートを使用)

- WebLogic Server Embedded LDAP

Mobile and Socialには、UserProfileという名前の事前構成済ユーザー・プロファイル・サービス・プロバイダも含まれています。次の各項では、詳細を説明します。

- ユーザー・プロファイル・サービス・プロバイダの作成

- ユーザー・プロファイル・サービス・プロバイダの編集または削除

- 事前構成済ユーザー・プロファイル・サービス・プロバイダの理解

38.3.3.1 ユーザー・プロファイル・サービス・プロバイダの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロバイダ」パネルで「作成」をクリックして、「ユーザー・プロファイル・サービス・プロバイダの作成」を選択します。
「ユーザー・プロファイル・サービス・プロバイダ」の「構成」ページが表示されます。

3. ユーザー・プロファイル・サービス・プロバイダのプロパティに値を入力します。

- 名前: このユーザー・プロファイル・サービス・プロバイダに一意の名前を入力します。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

4. ユーザー・プロファイル・サービス・プロバイダの属性と値を、表38-7に基づいて追加または削除します。

注意:

通常、LDAP属性の名前には大文字と小文字の区別はありませんが、Oracle Identity Governance Framework (IGF)と通信する場合、LDAP属性の名前は大文字と小文字が区別されます。

表38-7 ユーザー・プロファイル・サービス・プロバイダのデフォルト属性の名前と値

名前

値

注意

accessControl

false

サポートされる値は、accessControl機能を有効化する場合のtrueと、無効化する場合のfalseです。

adminGroup

cn=Administrators,ou=groups,ou=myrealm,dc=base_domain

accessControlを有効化している場合は、ユーザーが存在するかどうかを確認するためにadminGroupの識別名(DN)を指定します。

selfEdit

true

サポートされている値は、ユーザーがaccessControl機能について彼または彼女のプロファイルを編集できるかどうかに応じてtrueまたはfalseです。これは、accessControl機能の構成プロパティの1つでもあります。

proxyAuth

-

サポートされる値は、proxyAuth機能を有効化する場合のtrueと、無効化する場合のfalseです。この属性は、proxyAuthがサポートされていて、管理者がproxyAuth機能の使用を希望しない場合にのみ必要になります。

この属性は、Mobile and Socialの新規インストールには含まれていません。管理者はこのプロパティを追加できます。

5. ディレクトリ・サービスとユーザー・プロファイル・サービス・プロバイダを関連付けるために、「新規作成」または「既存のものを使用」を選択して、アイデンティティ・ディレクトリ・サービスのプロパティを構成します。

- 名前: ドロップダウン・メニューから既存のアイデンティティ・ディレクトリ・サービス接続を選択します。また、新しいアイデンティティ・ディレクトリ・サービス定義を作成する場合は値を入力します。

- デフォルトのアイデンティティ・ディレクトリ・サービスのいずれか(userroleまたはidxuserrole)を選択すると、このセクションで構成値を表示したり編集できません。

- 管理者が作成したアイデンティティ・ディレクトリ・サービス接続を選択すると、追加のプロパティを(定義の作成後に)表示および編集できるようになります。詳細は、第38.3.3.2項「ユーザー・プロファイル・サービス・プロバイダの編集または削除」を参照してください。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

6. 「新規作成」または「既存のものを使用」を選択して、リポジトリのプロパティを構成します。
「新規作成」では、アイデンティティ・ディレクトリ・サービス接続の新しいリポジトリ・オブジェクト(つまり、LDAPディレクトリ・サーバーの参照)を定義します。「リポジトリ」セクションで値を定義した後に、「接続テスト」をクリックして、定義した値に間違いがないことを確認します。このオプションは、新しいアイデンティティ・ディレクトリ・サービス接続を定義している場合にのみ使用可能です。「既存のものを使用」を使用すると、以前に定義したリポジトリ・オブジェクトをドロップダウン・メニューから選択できるようになります。

- (リポジトリの)「名前」: 新しい一意の名前を入力するか(作成する場合)、メニューから既存のものを選択します。新しい名前を入力した後には、アイデンティティ・ディレクトリ・サービス接続のプロパティを構成します。

- ディレクトリ・タイプ: Microsoft Active DirectoryやOracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを選択します。ディレクトリがリストされない場合は、このフィールドを空白のままにします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

- ホスト情報: アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を格納します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。「ホスト名」列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。「ポート」列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

- 可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。

- SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。それ以外の場合は、オプション・ボックスをクリアにします。

- バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。

- バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。

- ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。

7. ユーザーのプロパティを構成して、Mobile and Socialのユーザー・プロファイル・サービスのLDAPユーザー・オブジェクトを構成します。

注意:

既存のアイデンティティ・ディレクトリ・サービス接続を使用している場合、これらのフィールドは読取り専用です。

- オブジェクト・クラス: ディレクトリ・サーバーで定義されている組織内の人々を表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。

- 名前属性: ディレクトリ・サーバー上のユーザー・オブジェクトに対して指定されている名前属性を入力します。

- ベースDN: ディレクトリ・サーバー上のユーザー・オブジェクトのベースDNを(LDAP形式で)入力します。

8. グループのプロパティを構成して、Mobile and Socialのユーザー・プロファイル・サービスのLDAPグループ・オブジェクトを構成します。

- オブジェクト・クラス - ディレクトリ・サーバーで定義されている組織内の人々のグループを表すカスタム・オブジェクト・クラスを追加するには、「追加」をクリックします。

- 名前属性: ディレクトリ・サーバー上のグループ・オブジェクトに対して指定されている名前属性を入力します。

- ベースDN: ディレクトリ・サーバー上のグループ・オブジェクトのベースDNを(LDAP形式で)入力します。

9. 「作成」をクリックして、サービス・プロバイダ構成オブジェクトを作成します。

38.3.3.2 ユーザー・プロファイル・サービス・プロバイダの編集または削除

ユーザー・プロファイル・サービス・プロバイダを編集または削除するには、パネルでサービス・プロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。この項では、ユーザー・プロファイル・サービス・プロバイダの追加の構成プロパティについて説明します。これらのプロパティは、アイデンティティ・ディレクトリ・サービス用のもので、管理者が作成したユーザー・プロファイル・サービス・プロバイダを編集するときに表示されます。

- 名前 - ドロップダウン・メニューから、ユーザー・プロファイル・サービス・プロバイダと関連付けるアイデンティティ・ディレクトリ・サービス接続を選択します。

- デフォルトのアイデンティティ・ディレクトリ・サービスのいずれか(userroleまたはidxuserroleのいずれか)を選択すると、構成値の表示や編集はできなくなります。

- 管理者が作成したアイデンティティ・ディレクトリ・サービス接続を選択すると、構成値を必要に応じて表示および編集できるようになります。

- 一般およびリポジトリ - このタブのフィールドを使用して、Mobile and Socialがディレクトリ・サービスに接続するために使用するディレクトリ・サービスおよびリポジトリ構成値を編集します。

- リポジトリ名 - このメニューから、アイデンティティ・ディレクトリ・サービス接続と関連付けるリポジトリを選択します。リポジトリを選択したら、次のフォームのフィールドを使用してそのプロパティを構成します。

- ディレクトリ・タイプ - Microsoft Active Directory、Oracle Internet Directoryなど、リポジトリをホストするディレクトリ・サーバー・ソフトウェアのタイプを表示します。このフィールドは読取り専用です。

- ホスト情報 - アイデンティティ・ディレクトリ・サービス・リポジトリが配置されているホスト・コンピュータに関する情報を表示します。ディレクトリ・サーバーがクラスタの一部である場合は、複数のホストを追加します。新しいホストを表に追加するには、「追加」をクリックします。ホスト名列に、IPアドレスまたはディレクトリ・サーバーが実行されているコンピュータ(または仮想コンピュータ)の名前を入力します。ポート列に、ディレクトリ・サーバーが使用するように構成されているポート番号を入力します。ホストがクラスタの一部である場合は、負荷分散列に、各ホストにダイレクトされる負荷の量をパーセントとして入力します。複数のホストの場合、量の合計が100%になる必要があります。ホストを削除するには、表でその行を選択し、「削除」をクリックします。新しいアイデンティティ・ディレクトリ・サービス接続を定義しているのでも、新しいリポジトリを作成しているのでもない場合は、このフィールドは読取り専用です。

- 可用性 - クラスタがフェイルオーバー操作用に構成されている場合はフェイルオーバーを選択し、クラスタが複数のホストに負荷を分散している場合はロード・バランスを選択します。既存のリポジトリを使用している場合、このフィールドは読取り専用です。

- SSL - 接続がSSL用に構成されている場合は、「有効」を選択します。それ以外の場合は、オプション・ボックスをクリアにします。

- バインドDN - ディレクトリ・サーバーから認証を受けるために使用するLDAP管理者の識別名(DN)を入力します。

- バインド・パスワード - ディレクトリ・サーバーから認証を受けるために使用するバインドDNパスワードを入力します。

- ベースDN - ユーザーおよびグループのデータが配置されているベース識別名(DN)を入力します。

- エンティティ属性 - このタブのフィールドを使用して、企業ディレクトリ・サービスのスキーマをナビゲートするためにMobile and Socialで使用される属性を表示または編集します。「追加」をクリックして表に属性を追加するか、「削除」をクリックして属性を削除します。

- 名前 - 属性名。

- 物理属性 - 基盤となるリポジトリの対応する物理属性タイプの名前。

- タイプ - 属性のデータ・タイプ。

- 説明 - 属性の簡単な説明。

- 機密 - 属性にパスワードなどの機密情報が含まれていることを示す場合に選択します。

- 読取り専用 - 変更されないように属性を保護する場合に選択します。

- エンティティ/ユーザー・プロパティ - 「ユーザー」副項目のフィールドを使用して、Mobile and SocialがLDAPサーバー上のユーザー・エンティティと相互作用する方法を構成します。

- ベースの作成 - ユーザーを定義するベースDN (LDAPディレクトリ・ツリーの最上位レベル)を指定します。

- 検索ベース - ユーザーの検索ベースDNを指定します。検索操作が処理されるときは、検索ベースDNにあるかそれより下のエントリのみが対象になります。

- オブジェクト・クラスの作成 - 個人に関連付けられている属性が格納されているオブジェクト・クラスを指定します。

- RDN属性 - 相対識別名属性を指定します。たとえば、cnです。

- ID属性 - ユーザーを一意に識別する属性を指定します。uid属性やloginid属性などです。

- フィルタ・オブジェクト・クラス - フィルタ条件にするオブジェクト・クラスを指定します。

- 属性コンフィギュレーション - ユーザー・プロファイル・サービス・プロバイダによる使用と検索を可能にするユーザーの属性を指定します。

- 使用中 - 属性が、ディレクトリ・サービスでユーザーに対して使用されている場合に指定します。

- 属性名 - 「エンティティ属性」タブで定義した属性の名前を指定します。

- 結果内 - 指定した属性を、検索結果で返す必要がある場合に選択します。

- 検索可能 - 指定した属性を検索操作に対して使用可能にする場合に選択します。

- 検索演算子 - 指定した属性の検索方法を制限するには、このメニューから検索演算子を選択します。

- 操作構成 - ユーザー・エンティティ・レベルで有効にする操作を「作成」、「更新」、「削除」、および「検索」から選択します。これらを無効にするには、オプション・ボックスの選択を解除します。

- エンティティ/グループのプロパティ - 「グループ」副項目のフィールドを使用して、Mobile and SocialがLDAPサーバー上のグループ・エンティティと相互作用する方法を構成します。

- ベースの作成 - ユーザーを定義するベースDN (LDAPディレクトリ・ツリーの最上位レベル)を指定します。

- 検索ベース - グループの検索ベースDNを指定します。検索操作が処理されるときは、検索ベースDNにあるかそれより下のエントリのみが対象になります。

- オブジェクト・クラスの作成 - グループに関連付けられている属性が格納されているオブジェクト・クラスを指定します。

- RDN属性 - 相対識別名属性を指定します。たとえば、cnです。

- ID属性 - グループを一意に識別するLDAP属性を指定します。

- フィルタ・オブジェクト・クラス - フィルタ条件にするオブジェクト・クラスを指定します。

- 属性コンフィギュレーション - ユーザー・プロファイル・サービス・プロバイダによる使用と検索を可能にするグループ属性を指定します。

- 使用中 - 属性が、ディレクトリ・サービスでユーザーに対して使用されている場合に指定します。

- 属性名 - 「エンティティ属性」タブで定義した属性の名前を指定します。

- 結果内 - 指定した属性を、検索結果で返す必要がある場合に選択します。

- 検索可能 - 指定した属性を検索操作に対して使用可能にする場合に選択します。

- 検索演算子 - 指定した属性の検索方法を制限するには、このメニューから検索演算子を選択します。

- 操作構成 - グループ・エンティティ・レベルで有効にする操作を「作成」、「更新」、「削除」、および「検索」から選択します。これらを無効にするには、オプション・ボックスの選択を解除します。

- 関係 - このタブのフィールドを使用して、このアイデンティティ・ディレクトリ・サービスの属性間の関係を構成します。

- 名前 - 関係の名前。

- エンティティ(から) - 「ユーザー」を選択してユーザー属性から選択するか、「グループ」を選択して、属性(から)列のグループ属性から選択します。

- 属性(から) - マッピング元にする属性を選択します。

- リレーション - 開始列で指定した属性と終了列で指定した属性間の関係を説明するメニューオプションを選択します。

- エンティティ(に) - 「ユーザー」を選択してユーザー属性から選択するか、「グループ」を選択して、属性(に)列のグループ属性から選択します。

- 属性(に) - マッピング先にする属性を選択します。

- 再帰的 - 関係をディレクトリ・ツリーの下方向に拡張してネストされた子エンティティを含めるか、ディレクトリ・ツリーを上方向に拡張して親エンティティを含める場合に選択します。

- 関係構成 - アイデンティティ・ディレクトリ・サービスの対応する列にアクセスするために使用するURIセグメントを入力します。新しい関係を追加するには「追加」を、構成済の関係を削除するには「削除」を使用します。

- アクセスURI - アイデンティティ・ディレクトリ・サービスの対応するデータ列にアクセスするために使用するURIセグメントを入力します。たとえば、memberOfがアクセスURIである場合は、

http://host:port/.../idX/memberOf

が、ID idXを持つエンティティの関連エンティティにアクセスするためのURIです。

- アイデンティティ・ディレクトリ・サービスの関係 - 「アクセスURI」セグメントによってアクセスされるディレクトリ・サービス関係を選択します。アイデンティティ・ディレクトリ・サービスが、事前構成済UserProfileアイデンティティ・プロバイダではない場合、「アイデンティティ・ディレクトリ・サービス」構成セクションの「関係」タブで関係を構成できます。(UserProfileサービス・プロバイダに対してはアイデンティティ・ディレクトリ・サービス関係を構成できません。)

- エンティティURI属性 - Mobile and Socialサーバーから送信されるURIレスポンスで使用されるJSON属性名を入力します。たとえば、指定されているエンティティURI属性がperson-uriである場合、URIレスポンスは次のようになります。

{ {"person-uri":uriY1, ...}, {"person-uri":uriY2, ...}, ... }

ここで、uriY1およびuriY2は、関連エンティティのそれぞれにアクセスするための直接URIです。

- 再帰型をリクエストするスコープ - 関係検索で、ネストされたレベルの属性を取得するには、スコープ属性値をスコープ問合せパラメータとともに使用します。再帰的に関連エンティティにアクセスするには、使用する値を入力します。Mobile and Socialのデフォルト構成では、toTopとallの2つのスコープ属性値が使用されます。「再帰型をリクエストするスコープ」の値が属性値allである場合、次のREST URIの例が使用されてリクエストが実行されます。

http://host:port/.../idX/reports?scope=all

この例では、URIによって、ID idXを持つエンティティに関連するエンティティが、それに続いて関連しているエンティティすべてとともに返されます。

38.3.3.3 事前構成済ユーザー・プロファイル・サービス・プロバイダの理解

Mobile and Socialには、UserProfileという名前の、LDAP準拠のディレクトリ・サーバー用の事前構成済ユーザー・プロファイル・サービス・プロバイダが用意されています。このサービス・プロバイダを使用すると、Mobile and Socialを使用するディレクトリ・オブジェクトに対して、参照タスクと更新タスクを実行できるようになります。

38.4 サービス・プロファイルの定義

サービス・プロファイルでは、Mobile and Socialサーバー上のサービス・プロバイダに対するサービス・エンドポイントURLを定義します。各サービス・プロバイダ・インスタンスには、対応する少なくとも1つのサービス・プロファイル・インスタンスが必要です。1つのサービス・プロバイダに複数のサービス・プロファイルを作成できます。それぞれのサービス・プロファイルでは、そのサービス・プロバイダに対する各種のトークン機能とサービス・エンドポイントを定義します。

注意:

1つのサービス・プロファイルを複数のサービス・ドメインに割り当てることができます。一般的に、モバイル・サービス・プロファイルはモバイル・サービス・ドメインに割り当て、非モバイル・サービス・プロファイルは非モバイル・サービス・ドメインに割り当てる必要があります。詳細は、第38.7項「サービス・ドメインの定義」を参照してください。

必要なサービス・プロバイダの作成後に、1つ以上のサービス・プロファイルを作成します。この項の項目は次のとおりです。

- 認証サービス・プロファイルの定義、変更および削除

- 認可サービス・プロファイルの定義、変更および削除

- ユーザー・プロファイル・サービス・プロファイルの定義、変更および削除

38.4.1 認証サービス・プロファイルの定義、変更および削除

次の各項では、認証サービス・プロファイルについて説明します。

- 認証サービス・プロファイルの作成

- 認証サービス・プロファイルの編集または削除

38.4.1.1 認証サービス・プロファイルの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロファイル」パネルで「作成」をクリックして、認証サービス・プロファイルの作成を選択します。
認証サービス・プロファイルの「構成」ページが表示されます。

3. 認証サービス・プロファイルの一般プロパティに値を入力します。

表38-8 認証サービス・プロファイルのデフォルトの一般プロパティ

名前

注意

名前

この認証サービス・プロファイルに一意の名前を入力します。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

サービス・タイプ

作成しているサービス・プロファイルのタイプ(「ユーザー・プロファイル・サービス」、「認証サービス」および「認可サービス」のいずれか)が表示されます。

サービス・エンドポイント

ボックスに文字列(たとえば、localhost:5575)を入力して、このサービスに一意のUniform Resource Identifier (URI)アドレスを作成します。

- 「認証サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、そのプロファイルのクライアント、ユーザー、およびアクセス・トークンを作成、検証、管理、および削除するために作成されるURIと、デバイスの登録に使用されるクライアント登録ハンドルURIが表示されます。

- 「認可サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成される認可URIカテゴリが表示されます。

- 「ユーザー・プロファイル・サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成されるURIカテゴリ(1つのURIはユーザーを管理するため、もう1つのURIはグループを管理するため)が表示されます。

サービス・プロバイダ

このサービス・プロファイルのベースにするサービス・プロバイダを選択します。このリストの内容は、サービス・タイプによって決まります。対応するサービス・プロファイルを作成する前に、サービス・プロバイダを定義する必要があります。

サービス有効

このボックスを選択すると、サービスが有効化されます。無効化するには、このボックスの選択を解除します。

4. 「トークン・サポートおよびURIカテゴリ情報」のオプションを選択して、そのサービスでトークン・タイプのサポートを有効にします。または、このオプション・ボックスを選択解除して、そのサービスでトークン・タイプのサポートを無効にします。
「トークン・サポート」は、認証サービス・プロファイルにのみ適用されます。各トークン・タイプとともに、対応するUniform Resource Identifier (URI)もリストされます。

表38-9 トークン・サポートおよびURIカテゴリ情報のデフォルトのプロパティ

名前

注意

クライアント登録ハンドル

モバイル・トークン・サービスの場合は、Mobile and Socialサーバーにクライアント・デバイスを登録できるようにするために必須です。ユーザーの認証後、サーバーによってクライアント登録ハンドルが発行されます。OAAMとOAAMのセキュリティ・ハンドラ・プラグインがモバイル認証サービスで併用されている場合は、そのプラグインで不正検出とリスク分析ポリシー・チェックが実行できるようになるため、確実性とクライアントの信頼度が向上します。認証サービス・プロファイルをモバイル・サービス・ドメインに追加するには、クライアント登録ハンドルが有効化されている必要があります。クライアント登録ハンドルは、非モバイル・サービス・ドメインでは使用されません。

クライアント・トークン

サービスでクライアント・トークンを有効化する場合に選択します。クライアント・トークンは、非モバイル・デバイスまたはクライアントが認証済であることを証明するためにMobile and Socialサーバーによって発行されるセキュリティ権限付与です。サーバーは、名前とパスワードまたはその他の資格証明に基づいてクライアントを認証した後、クライアント・トークンを発行します。クライアント・トークンは、非モバイル・サービス・ドメインではオプションです。モバイル・サービス・ドメインでは使用されません。

ユーザー・トークン

サービスでユーザー・トークンを有効化する場合に選択します。ユーザー・トークンは、ユーザーが認証済であることを証明するためにMobile and Socialサーバーによって発行されるセキュリティ権限付与です。ユーザー・トークンは、アクセス・トークンを要求するために使用できます。

アクセス・トークン

サービスでアクセス・トークンを有効化する場合に選択します。アクセス・トークンは、特定の保護されているリソースにクライアント・アプリケーションがアクセスできるようにMobile and Socialサーバーによって発行されるセキュリティ権限付与です。ユーザーがリソースへのアクセスを認可されている場合、クライアント・アプリケーションは、ユーザー・トークンを提示することでアクセス・トークンを入手できます。

5. 「作成」をクリックして、サービス・プロファイル構成オブジェクトを作成します。

38.4.1.2 認証サービス・プロファイルの編集または削除

認証サービス・プロファイルを編集または削除するには、パネルでサービス・プロファイルを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.4.2 認可サービス・プロファイルの定義、変更および削除

次の各項では、認証サービス・プロファイルについて説明します。

- 認可サービス・プロファイルの作成

- 認可サービス・プロファイルの編集または削除

38.4.2.1 認可サービス・プロファイルの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロファイル」パネルで「作成」をクリックして、認可サービス・プロファイルの作成を選択します。
認可サービス・プロファイルの「構成」ページが表示されます。

3. 認可サービス・プロファイルの一般プロパティに値を入力します。

表38-10 認可サービス・プロファイルのデフォルトの一般プロパティ

名前

注意

名前

この認可サービス・プロファイルに一意の名前を入力します。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

サービス・タイプ

作成しているサービス・プロファイルのタイプ(「ユーザー・プロファイル・サービス」、「認証サービス」および「認可サービス」のいずれか)が表示されます。

サービス・エンドポイント

ボックスに文字列(たとえば、localhost:5575)を入力して、このサービスに一意のUniform Resource Identifier (URI)アドレスを作成します。

- 「認証サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、そのプロファイルのクライアント、ユーザー、およびアクセス・トークンを作成、検証、管理、および削除するために作成されるURIと、デバイスの登録に使用されるクライアント登録ハンドルURIが表示されます。

- 「認可サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成される認可URIカテゴリが表示されます。

- 「ユーザー・プロファイル・サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成されるURIカテゴリ(1つのURIはユーザーを管理するため、もう1つのURIはグループを管理するため)が表示されます。

サービス・プロバイダ

このサービス・プロファイルのベースにするサービス・プロバイダを選択します。このリストの内容は、サービス・タイプによって決まります。対応するサービス・プロファイルを作成する前に、サービス・プロバイダを定義する必要があります。

サービス有効

このボックスを選択すると、サービスが有効化されます。無効化するには、このボックスの選択を解除します。

4. 「作成」をクリックして、サービス・プロファイル構成オブジェクトを作成します。

38.4.2.2 認可サービス・プロファイルの編集または削除

認可サービス・プロファイルを編集または削除するには、パネルでサービス・プロファイルを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.4.3 ユーザー・プロファイル・サービス・プロファイルの定義、変更および削除

次の各項では、認証サービス・プロファイルについて説明します。

- ユーザー・プロファイル・サービス・プロファイルの作成

- ユーザー・プロファイル・サービス・プロファイルの編集または削除

38.4.3.1 ユーザー・プロファイル・サービス・プロファイルの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロファイル」パネルで「作成」をクリックして、ユーザー・プロファイル・サービス・プロファイルの作成を選択します。
ユーザー・プロファイル・サービス・プロファイルの「構成」ページが表示されます。

3. ユーザー・プロファイル・サービス・プロファイルの一般プロパティに値を入力します。

表38-11 ユーザー・プロファイル・サービス・プロファイルのデフォルトの一般プロパティ

名前

注意

名前

この認可サービス・プロファイルに一意の名前を入力します。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

サービス・タイプ

作成しているサービス・プロファイルのタイプ(「ユーザー・プロファイル・サービス」、「認証サービス」および「認可サービス」のいずれか)が表示されます。

サービス・エンドポイント

ボックスに文字列(たとえば、localhost:5575)を入力して、このサービスに一意のUniform Resource Identifier (URI)アドレスを作成します。

- 「認証サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、そのプロファイルのクライアント、ユーザー、およびアクセス・トークンを作成、検証、管理、および削除するために作成されるURIと、デバイスの登録に使用されるクライアント登録ハンドルURIが表示されます。

- 「認可サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成される認可URIカテゴリが表示されます。

- 「ユーザー・プロファイル・サービス」プロファイルを作成している場合、「URIカテゴリ情報」セクションに、サービス上に作成されるURIカテゴリ(1つのURIはユーザーを管理するため、もう1つのURIはグループを管理するため)が表示されます。

サービス・プロバイダ

このサービス・プロファイルのベースにするサービス・プロバイダを選択します。このリストの内容は、サービス・タイプによって決まります。対応するサービス・プロファイルを作成する前に、サービス・プロバイダを定義する必要があります。

サービス有効

このボックスを選択すると、サービスが有効化されます。無効化するには、このボックスの選択を解除します。

4. 「作成」をクリックして、サービス・プロファイル構成オブジェクトを作成します。

38.4.3.2 ユーザー・プロファイル・サービス・プロファイルの編集または削除

ユーザー・プロファイル・サービス・プロファイルを編集または削除するには、パネルでサービス・プロファイルを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.5 セキュリティ・ハンドラ・プラグインの定義

セキュリティ・ハンドラ・プラグインは、信頼およびリスク分析のための追加のロジックを参照することで、セキュリティを高めます。このような追加のロジックにより、リスクのある特定の操作に基づいてアクセスを拒否できるようになります。モバイル認証によって、機密セキュリティ操作中(たとえば、クライアント・アプリケーション登録など実質的にすべてのトークン取得操作中)にセキュリティ・ハンドラ・プラグインが起動されます。

注意:

セキュリティ・プラグインの使用はオプションです。使用する場合は、モバイル関連のサービス・ドメインとその認証サービスおよびクライアント・アプリケーションにのみ適用されます。

Mobile and Socialには、次の事前構成済セキュリティ・ハンドラ・プラグインが含まれています。

- OAAMSecurityHandlerPluginは、高機能なデバイスおよびクライアント・アプリケーション登録ロジック有効化するとともに、OAAMの高度なリスクおよび不正分析ロジックを有効化します。

- Defaultは、ごくわずかなリスク分析ロジックを提供します。

次の各項では、セキュリティ・ハンドラ・プラグインの定義方法について説明します。

- セキュリティ・ハンドラ・プラグインの作成

- セキュリティ・ハンドラ・プラグインの編集または削除

- デバイス・フィンガープリントおよびデバイス・プロファイル属性

38.5.1 セキュリティ・ハンドラ・プラグインの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「セキュリティ・ハンドラ・プラグイン」パネルで、「作成」をクリックします。
「セキュリティ・ハンドラ・プラグイン」の「構成」ページが表示されます。

3. セキュリティ・ハンドラ・プラグインの一般プロパティに値を入力します。

表38-12 セキュリティ・ハンドラ・プラグインの一般プロパティ

名前

注意

名前

この認可サービス・プロファイルに一意の名前を入力します。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

セキュリティ・ハンドラ・クラス

使用するセキュリティ・ハンドラ・プラグインを定義するJavaクラスを選択します。Mobile and Socialのこのリリースでは、DefaultSecurityHandlerPluginとOAAMSecurityHandlerPluginの2つのセキュリティ・ハンドラ・プラグインがサポートされています。

4. セキュリティ・ハンドラ・プラグインの属性に名前と値のペアを入力します。

- OaamSecurityHandlerPlugin属性の説明は、第38.9.2.6.3項「OTP電子メール統合のセットアップ」を参照してください。

- DefaultSecurityHandlerPluginには、allowJailBrokenDevicesという1つの属性設定があります。これは、ジェイルブレークされたクライアント・デバイスが、保護されているリソースへのアクセスを許可されるか拒否されるかを指定します。アクセスを拒否する(デフォルト設定)場合は、この属性の値をfalseに設定します。アクセスを許可する場合は、この値をtrueに設定します。ジェイルブレークの強制のために、OAAMSecurityHandlerPluginを構成する必要はありません。詳細は、第38.8.1項「新しいジェイルブレーク検出ポリシーの追加」を参照してください。

5. 「作成」をクリックして、セキュリティ・ハンドラ・プラグイン構成オブジェクトを作成します。

38.5.2 セキュリティ・ハンドラ・プラグインの編集または削除

セキュリティ・ハンドラ・プラグインを編集または削除するには、パネルでプロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。

38.5.3 デバイス・フィンガープリントおよびデバイス・プロファイル属性

モバイル・アプリケーションが起動されたときに、そのアプリケーション内のモバイル・クライアントSDKロジックによって、いくつかのデバイス・プロファイル属性の検出が試みられます。いくつかのデバイス・プロファイル属性は、OSタイプ、OSバージョン、言語ロケール設定、ネットワーク設定、地理的な位置などデバイスを一意に識別できない一般的な属性です。一部の属性は、デバイスを一意に識別できるハードウェア識別子になります。ハードウェア識別子の例としてはモバイル・デバイスのMACアドレスがあります。モバイルOSタイプおよびバージョンは、検出可能なある種のデバイス・プロファイル属性を示します。

モバイル・アプリケーションが、モバイル・クライアントSDKを介してトークンを要求すると、SDKロジックによってHTTPリクエストの一部としてデバイス・プロファイル属性が送信されます。このセットのデバイス・プロファイル属性によって、デバイスに対してデバイス識別を支援する監査証跡が作成され、セキュリティが高まります。

OAAMセキュリティ・プラグインを使用する場合、デバイス・プロファイル属性値の特定の組合せは、デバイス・フィンガープリント(OAAM管理コンソールではデジタル・フィンガープリントと呼ぶ)として処理されます。各フィンガープリントには、一意のフィンガープリント番号が割り当てられています。各OAAMセッションはフィンガープリントと関連付けられており、そのフィンガープリントによって、認証およびトークンの取得を実行しているデバイスのログ(および監査)が可能になります。

38.6 アプリケーション・プロファイルの定義

アプリケーション・プロファイルによって、サービス・プロバイダが提供するサービスを消費するクライアント・アプリケーションが定義されます。1つのアプリケーション・プロファイルを複数のサービス・ドメインに割り当てることができます。詳細は、次の項を参照してください。

- アプリケーション・プロファイルの作成

- アプリケーション・プロファイルの編集または削除

38.6.1 アプリケーション・プロファイルの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「アプリケーション・プロファイル」パネルで、「作成」をクリックします。
「アプリケーション・プロファイル」の「構成」ページが表示されます。

3. アプリケーション・プロファイルの一般プロパティに値を入力します。

表38-13 アプリケーション・プロファイルの一般プロパティ

名前

注意

名前

この値は、このアプリケーションをサーバー上の他のすべてのアプリケーションと区別できる一意の値にする必要があります。この値とクライアント・アプリケーションに組み込まれたアプリケーション名の値は、一致している必要があります。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

4. Mobile and Socialサーバーが、このアプリケーションに対してサーバー機能(たとえば、クライアント登録ハンドルの作成)を実行するために使用する属性に、名前と値のペアを入力します。

- Mobile.clientRegHandle.baseSecretは、このアプリケーションに対して各クライアント登録ハンドルに署名するためのプライベートな秘密としてサーバーによって使用される必須属性です。

- userId4BasicAuthは、サーバーとアプリケーションがHTTP Basic認証を実行するために使用するユーザーID属性です。詳細は、第37.4.1項「モバイル・クライアント登録エンドポイントの保護」を参照してください。

- sharedSecret4BasicAuthは、サーバーとアプリケーションがHTTP Basic認証を実行するために使用する共有シークレット属性です。

5. モバイル・アプリケーション・プロファイルのプロパティを定義します。

- ジェイルブレーク検出 - 「有効」ボックスを選択してこのアプリケーションに対してジェイルブレーク検出をアクティブにするか、そのボックスの選択を解除してそれを無効化にします。ジェイルブレーク検出がグレー表示されている場合、ジェイルブレーク検出ポリシーはMobile and Socialで無効化されています。詳細は、第38.8項「ジェイルブレーク検出ポリシーの使用」を参照してください。

- モバイル構成 - 「アプリケーション・プロファイル構成」ページで追加のモバイル構成設定を公開する場合は、このオプションを選択します。

6. 「作成」をクリックして、アプリケーション・プロファイル構成オブジェクトを作成します。
アプリケーション・プロファイルの作成後にのみ構成できる属性については、第38.6.2項「アプリケーション・プロファイルの編集または削除」を参照してください。

38.6.2 アプリケーション・プロファイルの編集または削除

アプリケーション・プロファイルを編集または削除するには、パネルで定義を選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。この項では、アプリケーション・プロファイルの追加のプロパティについて説明します。これらのプロパティは、以前に管理者が作成したユーザー・プロファイル・サービス・プロバイダを編集するときに表示されます。

- 構成設定

- プロファイル・キャッシュ継続時間 - モバイル・デバイス上にキャッシュされたアプリケーション・プロファイルの詳細が有効になっている最長時間。モバイル・クライアント・アプリケーションがアプリケーション・プロファイルを要求したときにその時間を過ぎていた場合、キャッシュされていたプロファイルは、新たにダウンロードされたバージョンで置き換えられます。その時間を過ぎていない場合は、キャッシュされているプロファイルが使用されます。

- 認証再試行回数 - 登録または認証中に無効な資格証明が提供された場合に、ユーザーに許可される再試行の最大回数。この設定は、iOSモバイルSDKでは使用されません。

- オフライン認証 - アプリケーションにローカルにログインして認証を受けることをユーザーに許可するには、「許可」ボックスを選択します。ローカルに認証を受けることをユーザーに禁止するにはこのボックスの選択を解除します。

- 要求属性 - 登録または認証中にデバイスからフェッチされ、サーバーに渡される属性のセット。

- インターネット・アイデンティティ・サービスWebビュー - 埋込みWebViewクラスを使用してアプリケーション内でMobile and Socialログイン・ページをユーザーに表示する場合は「埋込み」を選択し、ログイン・ページを外部ブラウザに表示する場合は、「外部」を選択します。

- プラットフォーム固有の設定

- URLスキーム - アプリケーション自体で構成されているとおりに、このモバイル・クライアント・アプリケーションを起動するために使用されるURLスキームを入力します。

- Apple iOSバンドルID - モバイル・クライアント・アプリケーションで構成されている一意のバンドルIDを入力します。各iOSモバイル・アプリケーションには、一意のバンドルIDがあります。

- Androidパッケージ

- Androidアプリケーションの署名

- カスタム設定/モバイル・カスタム属性 - モバイル・クライアント・アプリケーションに固有の属性またはプロパティを構成します。モバイル・カスタム属性は、アプリケーション・プロファイルの一部としてサーバーからモバイル・アプリケーションに返されます。

38.7 サービス・ドメインの定義

サービス・ドメインを作成すると、サービス・プロファイルを、アプリケーション・プロファイルとそれに対応する構成設定に関連付けできます。「サービス・ドメインの作成」ページを表示して、次の操作を実行します。

- サービス・ドメインがモバイル・アプリケーションまたはデスクトップ・アプリケーションを管理する場合に選択します。

- サービス・ドメインの認証スキームおよびセキュリティ・ハンドラ・プラグイン(オプション)を選択します。

- サービス・ドメインに1つ以上のモバイルSSOエージェントを追加し、他のエージェントより優先されるエージェントを構成します。

- 1つ以上のアプリケーションをサービス・ドメインに追加して、どのアプリケーションにモバイルSSOエージェントの使用を許可するかを構成します。

- サービス・ドメインに対して少なくとも1つのサービス・プロファイルを選択します。

- サービス・ドメインの選択したサービスを保護するセキュリティ設定を構成します。

詳細は、次の項を参照してください。

- サービス・ドメインの作成

- サービス・ドメインの編集または削除

38.7.1 サービス・ドメインの作成

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・ドメイン」パネルで、「作成」をクリックします。
「サービス・ドメインの作成」の「構成」ページが表示されます。

3. サービス・ドメインの一般プロパティに値を入力します。

表38-14 サービス・ドメインの一般プロパティ

名前

注意

名前

このサービス・ドメインの一意の名前を入力します。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

タイプ

「モバイル・アプリケーション」または「デスクトップ・アプリケーション」を選択します。モバイル・アプリケーションは、Apple社のiOSモバイル・オペレーティング・システムなどモバイル・オペレーティング・システム上で実行されるアプリケーションです。デスクトップ・アプリケーションは、非モバイル・オペレーティング・システム上で実行されるアプリケーションです。

アプリケーション登録用資格証明

モバイル・サービス・ドメインを構成している場合は、アプリケーションの登録に最小限必要な資格証明レベルを選択します。「ユーザー・パスワード」を選択すると、そのデバイスにモバイル・シングル・サインオン・エージェントがインストールされている場合でもアプリケーションが登録されるたびにユーザーにユーザー名とパスワードの入力が要求されるようになります。「ユーザー・トークン」を選択すると、サーバーからモバイルSSOエージェントにユーザー名とパスワードを提供するように要求されます。そのデバイスでの後続のアプリケーション登録では、その目的でモバイルSSOエージェントに発行されたユーザー・トークンが使用されるようになります。ユーザー・パスワードによって、アプリケーション登録プロセスを保護する追加のセキュリティが提供されます。ユーザー・トークンによって、アプリケーション登録プロセスがユーザーにとって便利になります。

認証スキーム

モバイル・サービス・ドメインを構成している場合は、「モバイル・サービス認証」または「インターネット・アイデンティティ認証」を選択します。「モバイル・サービス認証」を選択すると、ユーザーはユーザー名とパスワードをの入力をクライアントから要求されるようになります。「インターネット・アイデンティティ認証」を選択した場合、クライアントはMobile and Socialサーバーにリダイレクトされ、ユーザーはインターネット・アイデンティティ・サービスを使用して、たとえばGoogleやFacebookなどのアイデンティティ・プロバイダで認証を受けます。この選択により、「サービス・プロファイル選択」構成画面でどの認証サービス・プロファイルを選択できるかが決まります。

セキュリティ・ハンドラ・プラグイン名

セキュリティ・ハンドラ・プラグイン名 - モバイル・サービス・ドメインを構成している場合、使用するセキュリティ・ハンドラ・プラグインを選択します。使用可能なセキュリティ・ハンドラ・プラグインの詳細は、第38.2.3項「セキュリティ・ハンドラ・プラグインの理解」を参照してください。

4. 次のオプションのいずれかまたはすべてを使用して、アプリケーション・プロファイルを追加または選択します。
モバイル・ドメインを構成している場合は、選択できるのはモバイル・アプリケーションのみです。同様に、非モバイル・ドメインを構成している場合、選択できるのはデスクトップ・アプリケーションのみです。

1. 「アプリケーション・プロファイル」セクションの「アプリケーション・プロファイルの参照」をクリックすると、「検索」ウィンドウが開きます。このウィンドウでは、サービス・ドメインに追加する1つ以上の事前構成済アプリケーション・プロファイルを検索できます。追加するプロファイルを選択し、「選択」をクリックします。

2. あるいは、アプリケーション・プロファイルの正確な名前がわかっている場合は、「追加」をクリックして、その名前を表に直接入力します。

表38-15 アプリケーション・プロファイル選択のプロパティ

名前

注意

アプリケーション・プロファイル名

Mobile and Socialに対するクライアント・アプリケーションを一意に識別する名前です。

モバイル・シングル・サインオン(SSO)構成

モバイル・サービス・ドメインを構成している場合は、各アプリケーションがモバイル・シングル・サインオンにSSOエージェントとして参加するのか、SSOクライアントとして参加するのか、それとも参加しない(「なし」)のかを選択します。

- このアプリケーションをモバイルSSOに参加させず、かわりにMobile and Socialサーバーで直接ユーザー認証を実行する場合は、「なし」を選択します。

- アプリケーションが他のアプリケーションからの認証リクエストを承認できるモバイル・シングル・サインオン・エージェントの場合は、「SSOエージェントとして」を選択します。カスタム・モバイルSSOエージェントの作成の詳細は、Oracle Access Management開発者ガイドのiOS SDK情報を参照してください。

- アプリケーションがモバイル・シングル・サインオンと連動するように構成されており、ユーザー認証およびユーザー・セッション管理をモバイルSSOエージェントに委任する場合は、「SSOクライアントとして」を選択します。

エージェント優先度

モバイルSSOエージェントとして構成されているアプリケーションの数値ランキングを表示します。デバイスに複数のエージェント・アプリケーションがインストールされている場合、高い優先度(最も小さい数値ランク)を持つエージェント・アプリケーションが、他のすべてのエージェント・アプリケーションのエージェント・アプリケーションとして機能します。デバイスからそのエージェントが削除されると、次に高いランキングを持つエージェントがアクティブ・エージェントになります。優先度を基準にしてエージェントを並べ替えるには、「上に移動」および「下に移動」をクリックします。

説明

(オプション)自分または別の管理者が将来このサービスを識別する際に役立つ簡単な説明を入力します。

5. 「次へ」をクリックして、サービス・プロファイルを選択します。
「サービス・プロファイル」ページが表示されます。

6. 次のオプションのどちらかまたは両方を使用して、少なくとも1つのサービス・プロファイルをサービス・ドメインに追加します。
モバイル・サービス・ドメインの場合、認証、認可、およびユーザー・プロファイル・サービスのサービス・プロバイダごとに1つのサービス・プロファイルを追加できます。非モバイル・サービス・ドメインの場合、認証、認可、およびユーザー・プロファイル・サービスのサービス・プロバイダごとに複数のサービス・プロファイルを追加できます。

1. 「選択」をクリックして、「検索」ウィンドウを開きます。このウィンドウでは、以前に構成したサービス・プロファイルを検索できます。モバイル・ドメインを構成している場合は、選択できるのはモバイルと互換性のある認証サービス・プロファイルのみです。同様に、非モバイル・ドメインを構成している場合、選択できるのはデスクトップと互換性のある認証サービス・プロファイルのみです。割り当てるプロファイルを選択し、「選択」をクリックします。サービス・プロファイルの正確な名前がわかっている場合は、「追加」をクリックして、その名前を表に直接入力します。

2. 「作成」をクリックして、新しいサービス・プロファイルを作成します。

表38-16 サービス・プロファイル選択のプロパティ

名前

注意

認証サービス

(オプション)このサービス・ドメインおよび対応するサービス・エンドポイントに対して構成済の認可サービス・プロファイルの名前を表示します。新しいサービス・プロファイルを作成している場合は、第38.4.1項「認証サービス・プロファイルの定義、変更および削除」を参照してください。

認可サービス

(オプション)このサービス・ドメインおよび対応するサービス・エンドポイントに対して構成済の認可サービス・プロファイルの名前を表示します。新しいサービス・プロファイルを作成している場合は、第38.4.2項「認可サービス・プロファイルの定義、変更および削除」を参照してください。

ユーザー・プロファイル・サービス

(オプション)このサービス・ドメインおよび対応するサービス・エンドポイントに対して構成済のユーザー・プロファイル・サービス・プロファイルの名前を表示します。新しいサービス・プロファイルを作成している場合は、第38.4.3項「ユーザー・プロファイル・サービス・プロファイルの定義、変更および削除」を参照してください。

7. 「次へ」をクリックして、サービス保護(認証)を構成します。
「サービス保護」ページが表示されます。

8. 次のいずれかのオプションを使用して、サービス・プロファイルの認証を構成します。

1. このサービス・ドメインに対してユーザー・プロファイル・サービスを選択していた場合は、セキュリティ設定を構成して、そのサービスを保護します。

表38-17 ユーザー・プロファイル・サービス保護のプロパティ

名前

注意

認証

このメニューから、このサービス・ドメインに対して構成されていて、このユーザー・プロファイル・サービスを保護するために使用する認証サービス・プロファイルを選択します。

セキュア・アプリケーション

クライアント・アプリケーションの認証に、クライアント・リソース・ハンドルまたはクライアント・トークンの提示を要求する場合に選択します。

セキュア・ユーザー

ユーザー・トークンまたはアクセス・トークン(アクセス・トークンが、ユーザー・トークンを使用して事前に取得されている場合)を提示することで、ユーザーの認証を要求する場合に選択します。

読取りの許可

ユーザー・プロファイル・データの表示をユーザーに許可する場合に選択します。

書込みの許可

ユーザー・プロファイル・データの更新をユーザーに許可する場合に選択します。

2. このサービス・ドメインに対して認可サービスを選択していた場合は、セキュリティ設定を構成して、そのサービスを保護します。

表38-18 認可サービス保護のプロパティ

名前

注意

認証

このメニューから、このサービス・ドメインに対して構成されていて、この認可サービスを保護するために使用する認証サービス・プロファイルを選択します。

セキュア・アプリケーション

クライアント・アプリケーションの認証に、クライアント・リソース・ハンドルまたはクライアント・トークンの提示を要求する場合に選択します。

セキュア・ユーザー

ユーザー・トークンまたはアクセス・トークン(アクセス・トークンが、ユーザー・トークンを使用して事前に取得されている場合)を提示することで、ユーザーの認証を要求する場合に選択します。

9. 「次へ」をクリックして、選択内容を確認します。

10. 「終了」をクリックして、サービス・ドメインを作成します。

38.7.2 サービス・ドメインの編集または削除

サービス・ドメインを編集または削除するには、パネルで定義を選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。この項では、サービス・ドメインの追加のプロパティについて説明します。これらのプロパティは、以前に管理者が作成したサービス・ドメインを編集するときに表示されます。

- 「アプリケーション・プロファイル」タブ

- プロファイル・キャッシュ継続時間 - モバイル・デバイス上にキャッシュされたアプリケーション・プロファイルの詳細が有効になっている最長時間。モバイル・クライアント・アプリケーションがアプリケーション・プロファイルを要求したときにその時間を過ぎていた場合、キャッシュされていたプロファイルは、新たにダウンロードされたバージョンで置き換えられます。その時間を過ぎていない場合は、キャッシュされているプロファイルが使用されます。

- 認証再試行回数 - 登録または認証中に無効な資格証明が提供された場合に、ユーザーに許可される再試行の最大回数。この設定は、iOSモバイルSDKでは使用されません。

- オフライン認証 - アプリケーションにローカルにログインして認証を受けることをユーザーに許可するには、「許可」ボックスを選択します。ローカルに認証を受けることをユーザーに禁止するにはこのボックスの選択を解除します。

- 要求属性 - 登録または認証中にデバイスからフェッチされ、サーバーに渡される属性のセット。

- インターネット・アイデンティティ・サービスWebビュー - 埋込みWebViewクラスを使用してアプリケーション内でMobile and Socialログイン・ページをユーザーに表示する場合は「埋込み」を選択し、ログイン・ページを外部ブラウザに表示する場合は、「外部」を選択します。

- プラットフォーム固有の設定

- URLスキーム - アプリケーション自体で構成されているとおりに、このモバイル・クライアント・アプリケーションを起動するために使用されるURLスキームを入力します。

- Apple iOSバンドルID - モバイル・クライアント・アプリケーションで構成されている一意のバンドルIDを入力します。各iOSモバイル・アプリケーションには、一意のバンドルIDがあります。

- Androidパッケージ

- Androidアプリケーションの署名

- カスタム設定/モバイル・カスタム属性 - モバイル・クライアント・アプリケーションに固有の属性またはプロパティを構成します。モバイル・カスタム属性は、アプリケーション・プロファイルの一部としてサーバーからモバイル・アプリケーションに返されます。

38.8 ジェイルブレーク検出ポリシーの使用

ジェイルブレークとは、製造業者がデバイスに適用している制限を解除または迂回するプロセスです。ジェイルブレークは、合法ですが、保護されているリソースに対するセキュリティ・リスクを高める可能性があります。このリスクに対処するために、Mobile and Socialでは、iOSデバイス用の事前構成済ジェイルブレーク検出ポリシーが提供されます。

ジェイルブレーク検出ポリシーは、Mobile and Social SDK for iOSを使用して作成したクライアント・アプリケーションに、デバイスがジェイルブレークされていることを示す可能性があるファイルの検索を指示する1つ以上の文で構成されています。Mobile and Socialサーバーは、このポリシー文をiOSクライアント・アプリケーションに送信します。クライアント・デバイスは、true値(ジェイルブレークが検出された場合)またはfalse値をMobile and Socialサーバーに送り返します。この値は、セキュリティ・ハンドラ・プラグインに転送され、使用しているセキュリティ・ハンドラ・プラグインのセキュリティ・ポリシーに応じて、Mobile and Socialはアクセスを許可、アクセスを拒否、またはアプリケーションからMobile and Social固有のデータをすべて消去できます。

- デフォルトのセキュリティ・ハンドラ・プラグインがアクティブ状態のときに、ポリシー・ロジックによりデバイスがジェイルブレークされていると判断されると、このプラグインでクライアント・デバイスのアクセスをallowJailBrokenDevicesプラグイン属性の設定内容に応じて許可または拒否できます。

- Oaamセキュリティ・ハンドラ・プラグインがアクティブ状態のときに、ポリシー・ロジックによりデバイスがジェイルブレークされていると判断されると、このプラグインでクライアント・デバイスのアクセスをOAAMポリシーのルールの構成内容に応じて許可またはブロックできます。(「OAAM認証後セキュリティ」ポリシーの下での「ジェイルブレークされたモバイル・デバイス」ルールなど、ポリシー・ルールの詳細は、Oracle Adaptive Access Manager管理者ガイドを参照してください)
さらに、デバイスがブラックリストに記載されているか、紛失または盗まれたものである場合は、このプラグインは、そのデバイスからMobile and Social固有のデータをすべて削除するWIPEOUTコマンドを送信し、今後のリクエストではそのデバイスをブロックできます。ユーザーが紛失デバイスを回収したときには、OAAMでデバイスをリセットできます。

詳細は、第38.5項「セキュリティ・ハンドラ・プラグインの定義」を参照してください。

注意:

OAAMのブロックとMobile and Socialの拒否は同じことを意味します。

次の各項では、詳細を説明します。

- 新しいジェイルブレーク検出ポリシーの追加

- ジェイルブレーク検出ポリシーの編集

38.8.1 新しいジェイルブレーク検出ポリシーの追加

XMLを使用して新しいジェイルブレーク検出ポリシーを作成する場合は、「ロード」ボタンをクリックしてデフォルトのポリシーを完全に上書きします。スキーマ・ファイルはカスタマ・サポートから入手できます。

次の手順を実行すると、Oracle Access Managementコンソールで新しいジェイルブレーク検出ポリシーを作成できます。

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ナビゲーション・ペインで「ジェイルブレーク検出ポリシー」をクリックします。
「ジェイルブレーク検出ポリシー」ページが表示されます。

3. 「追加」をクリックして、新しいジェイルブレーク検出ポリシーの条件および検出ロジックのプロパティを構成します。

- ジェイルブレーク検出 - 「有効」を選択してジェイルブレーク検出ポリシーをオンにするか、このオプションの選択を解除してすべてのクライアント・アプリケーション・インスタンスに対してこの機能をオフにします。ここでジェイルブレーク検出ポリシーを有効化しても、このポリシーはアプリケーションごとに無効化できます。ただし、ここでこのポリシーを無効化すると、この機能をアプリケーションごとに有効化したり無効化したりできなくなります。

- 最低OSバージョン - ポリシーが適用されるiOSの最低バージョン。この値が1.0である場合、ポリシーは、少なくともバージョン1.0のiOSを実行しているiOSデバイスに適用されます。

- 最高OSバージョン - ポリシーが適用されるiOSの最高バージョン。この値が空になっている場合、最高OSバージョン番号が確認されることはなくなり、「最低OSバージョン」に指定されている値より高いすべてのiOSバージョンにポリシーが適用されます。

- 最低クライアントSDKバージョン - Mobile and SocialクライアントSDKの最低バージョン番号。たとえば、11.1.2.0.0などです。

- 最高クライアントSDKバージョン - Mobile and SocialクライアントSDKの最高バージョン番号。たとえば、11.1.2.0.0などです。

- ポリシー有効期間 - iOSクライアント・デバイス上のSDKが、ポリシーのローカル・コピーの期限が切れて新しいバージョンを取得するまで待機する時間の長さを秒単位で入力します。

- 自動チェック期間 - iOSクライアント・デバイスが、既存のジェイルブレーク検出ポリシー文を再び実行するまで待機する時間の間隔を分単位で入力します。

- 検出ロケーション - iOSクライアント・デバイスが、論理OR演算子を使用してポリシー文を評価します。次のように、検出ロケーションを追加します。

- ファイル・パス - 検出ポリシーによって検索されるデバイス上のファイルまたはディレクトリの絶対パスを入力します。

- アクション - 「存在」を選択します。それにより、それがファイル・パスにアクセスできるかどうかを評価するように検出ポリシーに指示します。

- 成功 - 指定したファイルまたはディレクトリがデバイス上に見つかったときに、ポリシーによってジェイルブレーク済としてそのデバイスにフラグを設定する場合に選択します。ポリシーが、認可されていないファイルまたはディレクトリについて確認している場合は、このオプションを使用します。指定したファイルまたはディレクトリが見つからないときに、ポリシーによってジェイルブレーク済としてそのデバイスにフラグを設定する場合は、このオプションの選択を解除します。(必須のファイルまたはディレクトリについて確認している場合は、このオプションを使用します。)

38.8.2 ジェイルブレーク検出ポリシーの編集

多くの場合、「ジェイルブレーク検出ポリシー構成」ページの「ポリシー文」エディタを使用して、ジェイルブレーク検出ポリシーを変更できます。

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. ナビゲーション・ペインで「ジェイルブレーク検出ポリシー」をクリックして、次のいずれかのオプションを選択します。

- ジェイルブレーク検出ポリシーに変更を追加するには、ツールバーの「ロード」をクリックし、追加するジェイルブレーク検出ポリシー文を含むXMLファイルを参照し、「既存のポリシー文の後に追加」を選択し、「OK」をクリックします。スキーマ・ファイルはカスタマ・サポートから入手できます。

- ジェイルブレーク検出ポリシーを上書きするには、ツールバーの「ロード」をクリックし、ロードするジェイルブレーク検出ポリシー文を含むXMLファイルを参照し、「既存のポリシー文を上書き」を選択し、「OK」をクリックします。スキーマ・ファイルはカスタマ・サポートから入手できます。

- ジェイルブレーク検出ポリシーを編集するには、そのポリシーを「ポリシー文」表から選択することでプロパティを表示して、変更を加えてから(第38.8.1項「新しいジェイルブレーク検出ポリシーの追加」を参照)、「適用」をクリックします。

38.9 その他のOracle製品を使用したモバイル・サービスの構成

次の各項では、その他のOracle製品でMobile and Socialを構成する方法について説明します。

- Access Manager用のモバイル・サービスの構成

- Oracle Adaptive Access Manager用のモバイル・サービスの構成

38.9.1 Access Manager用のモバイル・サービスの構成

次の各項では、各バージョンのAccess Managerと連動するようにMobile and Socialを構成する方法について説明します。

- 簡易モードおよび証明書モードのAccess Managerと連動するモバイル・サービスの構成

- リモートのOracle Access Manager Server 10g用の認証サービス・プロバイダの構成

- リモートのAccess Manager 11gR2またはOracle Access Manager 11gR1 PS1用の認証サービス・プロバイダの構成

注意:

Oracle Fusion Middleware構成ウィザードは、インストール時に、Mobile and SocialとAccess Managerの両方をサポートするドメインを生成します。詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの「Mobile and Socialの構成」の章を参照してください。

38.9.1.1 簡易モードおよび証明書モードのAccess Managerと連動するモバイル・サービスの構成

Access Managerが簡易モードに構成されている場合、Access Managerと連動するようにモバイル・サービスを構成するには、次の手順を使用します。

1. Oracle Access Management管理コンソールを開きます。

2. 「システム構成」タブを選択し、「共通構成」→「サーバー・インスタンス」→「oam_server1」を選択します。

3. 「開く」ボタンをクリックします。

4. 「モード」メニューで、「簡易」を選択し、「適用」をクリックします。
システムは、~/oam-domain/outputディレクトリ内にwebgate-sslディレクトリを作成して、次のファイルを生成します。

- oamclient-keystore.jks

- oamclient-truststore.jks

5. .jksファイルを~/oam-domain/config/fmwconfigディレクトリにコピーします。

6. ~/oam-domain/output/accessgate-oicに移動し、password.xmlを開きます。

7. そのファイルからpasswd値をコピーします。

8. 管理コンソールのナビゲーション・ペインで、「システム構成」タブを選択します。

9. 「Mobile and Social」を開いて、「モバイル・サービス」、「サービス・プロバイダ」、「認証サービス・プロバイダ」、「OAMAuthentication」の順に選択します。

10. 次の名前と値のペアを「属性」表に追加します。

表38-19 Access Manager簡易モード構成の必須属性

名前

値

PASSPHRASE

手順4からのpasswd値。

KEYSTORE

<完全修飾パス>/oam-domain/config/fmwconfig/oamclient-keystore.jks

TRUSTSTORE

<完全修飾パス>/oam-domain/config/fmwconfig/oamclient-truststore.jks

11. 「属性」表で、TRANSPORT_SECURITYを見つけ、その値をOPENからSIMPLEまたはCERTに変更し、「保存」をクリックします。

12. 管理コンソールのナビゲーション・ペインで、「システム構成」タブの「Access Manager」セクションをクリックして開き、「SSOエージェント」を選択します。

13. 「OAMエージェント」をダブル・クリックして開きます。

14. 「検索」ボックスで、「名前」フィールドにaccessgate-oicと入力し、「検索」をクリックします。

15. 検索結果でaccessgate-oicをクリックして、プロファイル・ページを開きます。

16. 「セキュリティ」設定を「オープン」から「簡易」または「証明書」に変更し、「適用」をクリックします。

17. Oracle Access Managementサーバーを再起動します。

38.9.1.2 リモートのOracle Access Manager Server 10g用の認証サービス・プロバイダの構成

次の手順は、Oracle Access Manager 10gサーバーのリモート・インスタンスと連動するように認証サービス・プロバイダを構成する方法を示しています。

1. 10gコンソールにログインして、WGプロファイルを作成します。
OAM 10gアクセス管理サービスは、オンにする必要があります。

2. Mobile and Socialコンソールで、「モバイル・サービス」、「サービス・プロバイダ」、「認証サービス・プロバイダ」の順にナビゲートします。

3. 「新規」をクリックして、新しい認証サービス・プロバイダ構成を作成します。

4. パラメータに適切な値を入力します。

1. OAM_VERSIONは、OAM_11GからOAM_10Gに変更します。

2. WEBGATE_IDは、前の手順でWGプロファイルの作成に使用した名前に変更します。

3. OAM_SERVER_1は、OAM 10Gサーバーをホストするマシンのホスト名:ポート番号に変更します。

4. AuthNURLという新しいパラメータを追加して、任意の保護されたリソースのURL(たとえば、http://server1.domain.com/index.html)を移入します。

5. 認証サービス・プロバイダ構成を保存します。

6. Mobile and Socialコンソールで、「モバイル・サービス」、「サービス・プロファイル」、「認証サービス」、「OAMAuthentication」の順にナビゲートします。

7. 「サービス・プロバイダ」ドロップダウン・メニューから、前の手順で作成した認証サービス・プロバイダ(たとえば、10GOAMAuthentication)を選択します。

8. 「クライアント・トークン」チェック・ボックスを選択します。

9. 「アクセス・トークン」チェック・ボックスを選択解除します。

10. OAMAuthentication構成を保存します。

Mobile and SocialがOracle Access Manager 10gサーバーのリモート・インスタンスと連動するように構成されている場合は、さらに次のいずれかを実行する必要があります。

- Oracle Access ManagerのUserStore内のユーザー・レコードに対するディレクトリDNエントリに、uid属性を定義します。

- Mobile and Socialでディレクトリ・ユーザー・エントリの識別に使用できる、一意のディレクトリ・ユーザー・エントリ属性を定義します。

注意:

Mobile and Socialは、一意のディレクトリ・ユーザー属性名をOracle Access Managerリリース11gから動的に取得できますが、10gリリース以前ではMobile and Socialの構成時に使用する属性を指定する必要があります。この属性が設定されていないと、Mobile and Socialでのクライアント・トークンの検証は失敗します。

次の手順は、CNに値を設定する方法を示しています。ディレクトリ・サーバーで構成したように、一意のユーザー・エントリに値を設定します。uidまたはloginidを選択することも可能です。手順を開始する前に、UserStoreに対するOracle Access ManagerのDNに、アプリケーション・プロファイルprofileid1のuid属性が含まれていないことと、DNが次のようになっていることを確認します。

"CN=profileid1 profileid1, OU=Test, ..."

両方の条件を満たしていることを確認してから、次の手順を完了します。

1. Mobile and Socialで、profileid1の「アプリケーション・プロファイル構成」ページを開きます(第38.6項「アプリケーション・プロファイルの定義」を参照)。

2. 「属性」セクションで、次の名前と値のペアを追加し、「適用」をクリックします。
名前: userPrincipalAttrValue

値: CN

3. Oracle Access Manager 10g認証サービス・プロバイダの「サービス・プロバイダの構成」ページを開きます(第38.3.1項「認証サービス・プロバイダの定義、変更または削除」を参照)。

4. 「属性」セクションで、次の名前と値のペアを追加し、「適用」をクリックします。
名前: userPrincipalAttrName

値: CN

38.9.1.3 リモートのAccess Manager 11gR2またはOracle Access Manager 11gR1 PS1用の認証サービス・プロバイダの構成

次の手順は、リリース11gR2および11gR1 PS1と連動するように認証サービス・プロバイダを構成する方法を示しています。11gR1 PS1リリースのコンソールについての相違点は、11gR2の各手順内で説明しています。

1. Oracle Access Managementコンソールにログインして、Mobile and Social用のWebゲート(OAMエージェント)を登録します。
次のオプションを有効にしていることを確認します。

- 管理操作の許可

- トークン・スコープ操作の許可

- マスター・トークン取得の許可

- 資格証明コレクタ操作の許可

注意:

OAM 11.1.1.5リリースのコンソールを使用している場合は、「管理操作の許可」を有効にします。

2. Mobile and Socialコンソールで、「モバイル・サービス」、「サービス・プロバイダ」、「認証サービス・プロバイダ」の順にナビゲートします。

3. 「新規」をクリックして、新しい認証サービス・プロバイダ構成を作成します。

4. OAM 11.1.2リリースのコンソールを使用している場合は、次の値を入力します。

1. OAM_VERSIONのデフォルト値は、OAM_11Gのまま維持します。

2. WEBGATE_IDは、前の手順でWGプロファイルの作成に使用した名前に変更します。

3. OAM_SERVER_1は、OAM 11Gサーバーをホストしているマシンのホスト名:ポート番号に変更します。

注意:

OAM 11.1.1.5リリースのコンソールを使用している場合:

1. OAM_VERSIONの値は、OAM_10Gに変更します。

2. WEBGATE_IDは、前の手順でWGプロファイルの作成に使用した名前に変更します。

3. OAM_SERVER_1は、OAM 11.1.1.5サーバーをホストしているマシンのホスト名:ポート番号に変更します。

4. AuthNURLという新しいパラメータを追加して、任意の保護されたリソースのURL(たとえば、http://server1.domain.com/index.html)を移入します。

5. 認証サービス・プロバイダ構成を保存します。

6. Mobile and Socialコンソールで、「モバイル・サービス」、「サービス・プロファイル」、「認証サービス」、「OAMAuthentication」の順にナビゲートします。

7. 「サービス・プロバイダ」ドロップダウン・メニューから、前の手順で作成した認証サービス・プロバイダ(たとえば、10GOAMAuthentication)を選択します。

8. 「クライアント・トークン」チェック・ボックスを選択します。

9. OAM 11g R1 PS1を使用している場合にのみ、「アクセス・トークン」チェック・ボックスを選択解除します。

10. OAMAuthentication構成を保存します。

11. CSFウォレット・ファイルをマージします。
OAM 11Gは、管理者がMobile and Social用のWGプロファイルを作成したときに、cwallet.ssoファイルを生成します。このWGプロファイルと通信するために、管理者は、cwallet.ssoのsecret値をMobile and Socialウォレットにマージする必要があります。

注意:

次のコマンドを使用して、マージの前と後のウォレットを表示し、マージが正常に完了しているかどうかを確認してください。

orapki wallet display -wallet wallet_location

1. cwallet.ssoを、OAM (~/domain-home/output)から、Mobile and Socialをホストするマシンのディレクトリ/tmp/oamにコピーします。

2. Mobile and Socialをホストするマシンのディレクトリ(~/config/fmwconfig)から、Mobile and Socialをホストするマシンのディレクトリ/tmp/oicにcwallet.ssoをコピーします。

3. Mobile and Socialをホストするマシンのディレクトリ/tmpにmerge-creds.xmlをダウンロードします。
例38-1は、サンプルのmerge-creds.xmlファイルです。

例38-1 サンプルのmerge-creds.xml

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider"
name="credstoressp" type="CREDENTIAL_STORE">
<description>File-based credential provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<!-- Source file-based credential store instance -->
<serviceInstance location="/tmp/oam" provider="credstoressp"
name="credential.file.source">
</serviceInstance>

<!-- Destination file-based credential store instance -->
<serviceInstance location="/tmp/oic" provider="credstoressp"
name="credential.file.destination">
</serviceInstance>
</serviceInstances>

<jpsContexts>
<jpsContext name="FileSourceContext">
<serviceInstanceRef ref="credential.file.source"/>
</jpsContext>

<jpsContext name="FileDestinationContext">
<serviceInstanceRef ref="credential.file.destination"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

4. PATH変数を設定して、~/oracle_common/bin:~/oracle_common/common/bin:~を含めます。

5. コマンドラインからwlst.shを実行して、WebLogic Scripting Toolを初期化します。

6. WLSTコマンドのmigrateSecurityStoreを実行します。
次に、WLSTコマンドの構文例を示します。

$ wlst.sh

wls:/offline> connect("weblogic", "weblogic-passwd", "localhost:<port>")
wls:/WLS_IDM/serverConfig>
migrateSecurityStore(type="credStore",configFile="/tmp/merge-creds.xml",
src="FileSourceContext",dst="FileDestinationContext")

12. Mobile and Socialサーバーを再起動します。

38.9.2 Oracle Adaptive Access Manager用のモバイル・サービスの構成

Oracle Adaptive Access Manager (OAAM)のデバイス登録機能を使用するようにサービス・ドメインを構成するには、サービス・ドメイン構成ページを開き、「セキュリティ・ハンドラ・プラグイン名」リストから「OAAMSecurityHandlerPlugin」オプションを選択します。第38.7.1項「サービス・ドメインの作成」を参照してください。

注意:

Oracle Fusion Middleware構成ウィザードでは、インストール時に、Mobile and SocialとOracle Adaptive Access Managerの両方をサポートするドメインを生成できます。Mobile and Socialには、少なくともOracle Adaptive Access Managerバージョン11gリリース2が必要です。詳細は、Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの「Mobile and Socialの構成」の章を参照してください。

次の各項では、Mobile and SocialとOAAMとの統合を完了するために必要なポリシー、条件、ルールおよびアクションの構成方法について説明します。

- Mobile and SocialのOAAMサポートの理解

- WebLogic管理ドメインの構成

- 紛失または盗難デバイス・ルールの設定

- ブラックリストに記載されたデバイスおよびアプリケーションの構成

- モバイル・アプリケーションのOAAMセッションの理解

- OAAM認証のユーザー登録

- OAAMナレッジベース認証の設定

- OAAMワンタイム・パスワードの設定

注意:

OAAMルールおよびポリシーの順序の設定の詳細は、Oracle Adaptive Access Manager管理者ガイドを参照してください。

38.9.2.1 Mobile and SocialのOAAMサポートの理解

Mobile and Socialは、表38-20に(OAAMチェックポイント別に)示すOAAMポリシーをサポートします。

表38-20 Mobile and SocialでサポートされるOAAMポリシー

チェックポイント

サポートされているポリシー

認証後

OAAM認証後セキュリティ
OAAMユーザー対自分自身
OAAMユーザー対すべてのユーザー
OAAMではユーザーがプロファイルを持ちます
OAAM予測分析ポリシー

チャレンジ

OAAMチャレンジ・ポリシー

デバイスID

OAAMデバイスIDポリシー
OAAMシステム詳細分析Flashありポリシー
OAAMシステム詳細分析Flashなしポリシー

Mobile and SocialとOAAMでは、類似した用語を使用して、認証および認可イベントに応じて実行できるセキュリティ・アクションを記述しています。表38-21は、Mobile and Social用語とOAAM用語の対応表です。

表38-21 OAAMとMobile and Socialの用語の対応

OAAMのアクション・グループ

Mobile and Socialのアクション

OAAM許可

ALLOW

OAAMブロック

DENIED

OAAMチャレンジ

CHALLENGE

OAAMブラック・リストに記載されたモバイル・デバイス

WIPE_OUT

OAAM紛失デバイス

WIPE_OUT

- OAAMポリシー、ルールおよびチェックポイントの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。

- OAAMポリシーおよびルールをカスタマイズするには、Oracle Adaptive Access Manager管理者のコンソールを使用します。

38.9.2.2 WebLogic管理ドメインの構成

OAAMポリシーを構成する前に、この項の手順を完了します。

- OAAM管理のための管理者の作成

- OAAMデータ・ソースのターゲットとしてのOracle Access Managementサーバーの追加

38.9.2.2.1 OAAM管理のための管理者の作成

1. WebLogic管理ドメインのOracle WebLogic管理コンソールにログインします。

2. ページの左側にある「ドメイン構造」タブで、「セキュリティ・レルム」を選択します。

3. 「セキュリティ・レルムのサマリー」ページで、構成するレルム(たとえば、myrealm)を選択します。

4. 「新規」をクリックし、名前(たとえば、user1)、説明(オプション)、プロバイダ(DefaultAuthenticatorと入力)、パスワードおよびパスワードの確認の必要な情報を入力して、セキュリティ・レルムにユーザーを作成します。

5. クリックして、新しく作成したユーザーを選択します。

6. 「グループ」タブをクリックします。

7. そのユーザーに、OAAM接頭辞が付いたすべてのグループを割り当てます。

8. 「保存」をクリックします。

38.9.2.2.2 OAAMデータ・ソースのターゲットとしてのOracle Access Managementサーバーの追加

1. WebLogic管理ドメインのOracle WebLogic管理コンソールにログインします。

2. ページの左側にある「ドメイン構造」タブで、「サービス」を選択します。

3. 「サービスの概要」ページで、「データ・ソース」を選択します。

4. 「データ・ソース」表でOAAM_SERVER_DSを開きます。

5. 「ターゲット」タブをクリックします。

6. oam_server1を選択します。

7. 「保存」をクリックします。

38.9.2.3 紛失または盗難デバイス・ルールの設定

紛失デバイスを「OAAM紛失または盗難デバイス」グループに追加できるように、ユーザーはサポート部門に紛失または盗難デバイスを報告する必要があります。このようにすると、紛失デバイスから認証が試行されたときに、OAAMからMobile and SocialにDENYアクションまたはWIPE_OUTアクションを送信できるようになります。これにより、Mobile and Socialサーバーに関連するそのアプリケーションのデータが消去されます。ユーザーが紛失デバイスを回収したときには、OAAMでデバイスをリセットできます。次の手順では、「OAAM紛失または盗難デバイス」デバイス・グループにデバイスIDを追加することで、紛失中として報告された各デバイスに対する、紛失または盗難デバイス・ルールを作成する方法について説明します。

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで「セッション」をダブルクリックします。
セッション検索ページが表示されます。

3. 「ユーザー名」、「クライアント・アプリケーション」の名前、「デバイスID」などで検索して、紛失または盗難デバイスを見つけます。

4. 「検索結果」表でセッションIDをクリックします。
「セッション詳細」ページが開きます。

5. 「グループに追加」をクリックします。
「グループに追加」ポップアップ・ウィンドウが開きます。

6. 「追加するデータ型の選択」セクションで、「デバイス」を選択し、「次」をクリックします。

7. 「OAAM紛失または盗難デバイス」グループを選択し、「次」をクリックします。

8. 選択した内容を確認し、「終了」をクリックします。

9. 「OK」をクリックします。
紛失デバイスのポリシーおよびグループの管理の詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。

38.9.2.4 ブラックリストに記載されたデバイスおよびアプリケーションの構成

ルールを構成することで、特定のデバイスやアプリケーションへのアクセスをブロックできます。次の各項では、詳細を説明します。

- ブラックリストに記載されたデバイスのルールの設定

- ブラックリストに記載されたアプリケーション・ルールの設定

38.9.2.4.1 ブラックリストに記載されたデバイスのルールを設定するには

アクセスをブロックするデバイスごとに、ブラックリストに記載されたデバイスのルールを作成します。次の手順では、「OAAMブラック・リストに記載されたモバイル・デバイス」グループにデバイスIDを追加することで、ブラックリストに記載されたデバイス・ルールを作成する方法について説明します。

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで「セッション」をダブルクリックします。
セッション検索ページが表示されます。

3. その検索ページを使用して、ブロックするデバイスを検索します。たとえば、「ユーザー名」、「クライアント・アプリケーション」名、「デバイスID」などで検索します。

4. 「検索結果」表でセッションIDをクリックします。
「セッション詳細」ページが開きます。

5. 「グループに追加」をクリックします。
「グループに追加」ポップアップ・ウィンドウが開きます。

6. 「追加するデータ型の選択」セクションで、「デバイス」を選択し、「次」をクリックします。

7. 「OAAMブラック・リストに記載されたモバイル・デバイス」グループを選択し、「次」をクリックします。

8. 選択した内容を確認し、「終了」をクリックします。

9. 「OK」をクリックします。

38.9.2.4.2 ブラックリストに記載されたアプリケーション・ルールの設定

ブラックリストに記載されたアプリケーション・ルールを追加するタスクは、次の手順に分けられます。次の手順を(記載順に)実行して、「OAAMブラック・リストに記載されたモバイル・デバイス」グループにアプリケーションを追加します。

- 新しいアラート・グループの作成

- ブラックリストに記載されたアプリケーション名を格納する汎用文字列グループの作成

- 新しいブラックリストに記載されたアプリケーション・ルールの作成

38.9.2.4.3 新しいアラート・グループの作成

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで、「グループ」をダブルクリックします。
グループ検索ページが表示されます。

3. 「新規グループ」をクリックします。
「グループの作成」ポップアップ・ウィンドウが開きます。

4. 次のようにフォームに入力して「作成」をクリックします。

- グループ名 - OAAM Blacklisted mobile application usedと入力します。(これが、ブラックリストに記載するモバイル・アプリケーションの名前です。)

- グループ・タイプ - メニューから「Alerts」を選択します。

- キャッシュ・ポリシー - メニューから「フル・キャッシュ」を選択します。

- 説明 - Session coming from a blacklisted mobile applicationと入力します。

5. 「アラート」タブをクリックします。

6. 「このグループにメンバーを追加」ボタンをクリックします。
アラートの追加ポップアップ・ウィンドウが開きます。

7. 「新規要素の追加オプション」セクションで、新規アラートの作成を選択します。
次のようにフォームに入力して「追加」をクリックします。

- アラート・タイプ - メニューから「不正」を選択します。

- アラート・レベル - メニューから「中」を選択します。

- アラート・メッセージ - Session coming from a blacklisted mobile applicationと入力します。

アラートの追加ウィンドウに、新規要素が正常に作成されたことを確認するメッセージが表示されます。

38.9.2.4.4 ブラックリストに記載されたアプリケーション名を格納する汎用文字列グループの作成

1. ナビゲーション・ペインで、「グループ」をダブルクリックします。
グループ検索ページが表示されます。

2. 「新規グループ」をクリックします。
「グループの作成」ポップアップ・ウィンドウが開きます。

3. 次のようにフォームに入力して「作成」をクリックします。

- グループ名 - OAAM blacklisted mobile applicationと入力します。

- グループ・タイプ - メニューから「汎用文字列」を選択します。

- キャッシュ・ポリシー - メニューから「フル・キャッシュ」を選択します。

- 説明 - OAAM blacklisted mobile applicationと入力します。

4. 「汎用文字列」タブをクリックし、「このグループにメンバーを追加」ボタンをクリックします。

5. アプリケーションの名前を入力します。
汎用文字列の追加ウィンドウに、新規要素が正常に作成されたことを確認するメッセージが表示されます。

「OK」をクリックします。

38.9.2.4.5 新しいブラックリストに記載されたアプリケーション・ルールの作成

1. ナビゲーション・ペインで、「ポリシー」をダブルクリックします。
ポリシー検索ページが表示されます。

2. 「チェックポイント」メニューから「認証後」を選択し、「検索」をクリックします。

3. 「OAAM認証後セキュリティ」をクリックします。
「OAAM認証後セキュリティ」ページが開きます。

4. 「ルール」タブをクリックします。

5. 「ルールの追加」ボタンをクリックします。
次のようにフォームに入力して「追加」をクリックします。

- ルール名 - Check for blacklisted mobile applicationsと入力します。

- ルール・ステータス - メニューから「アクティブ」を選択します。

- Rule Notes - Check if application is in the Oaam blacklisted mobile application groupと入力します。

6. 「条件」タブをクリックします。

7. 「条件の追加」をクリックします。
「条件の追加」ポップアップ・ウィンドウが開きます。

8. 次のようにフォームに入力して「検索」をクリックします。

- 条件名 - Check Current Sessionと入力します。

- タイプ - メニューから「セッション内」を選択します。

9. 結果の表で、「セッション: フィルタ条件を使用した現在のセッションの確認」をクリックします。
フィルタ条件の詳細が表示されます。

10. 次のように実行し、「保存」をクリックします。

1. 「チェック」の下で「クライアント・アプリケーション」を選択します。

2. 演算子として「次に含まれる」を選択します。

3. ターゲット・タイプとして「グループ」を選択します。

4. グループ・タイプとして「汎用文字列」を選択します。

5. グループ名としてOAAMブラック・リストに記載されたモバイル・アプリケーションを選択します。

英語では、条件はCheck if the Client Application is in the "OAAM blacklisted mobile application" groupとなります。

11. 「結果」タブをクリックします。

12. 「アクション・グループ」メニューから「OAAMブロック」を選択します。

13. 「アラート・グループ」メニューからOAAM Blacklisted application usedを選択します。

14. 「適用」をクリックします。

38.9.2.5 モバイル・アプリケーションのOAAMセッションの理解

OAAMセッションは、OAAMルールの実行において一般的に使用される概念エンティティです。ルールは、入力としてセッション属性(たとえば、クライアント・アプリケーション名およびOAAMデバイスID)を使用し、出力時にそのセッションのステータスに影響を与える(つまり、ステータスを「ブロック済」に変更する)ことができます。

OAAMがWebブラウザなどの非モバイル環境で使用されている場合、ユーザー認証セッション(たとえば、OAMセッション)とOAAMセッションの間には1対1の関係があります。たとえば、次のフィールドに関連付けられたデータが、各OAAMセッションに含まれているとします。

- ユーザーID

- クライアントIPアドレス

- OAAMデバイスIDおよびフィンガープリント

- (認証)ステータス: 成功、保留中、ブロック済など。

- クライアント・アプリケーション名

モバイル・アプリケーション環境では、同じユーザーによって使用される同じデバイス上で実行されるアプリケーションはそれぞれ、モバイルSSOシナリオの中でも異なるOAAMセッションを持つと想定されています。たとえば、次のアプリケーションがモバイル・デバイスにインストールされていると想定します。

- SSOセキュリティ・エージェント・アプリケーション

- ホワイト・ページ・アプリケーション

- 経費レポート・アプリケーション

これらのアプリケーションは、同じサービス・ドメインの参加者としてまとめてリストされ、それらはすべてシングル・サインオンに参加します。ユーザーは、モバイルSSOエージェント・アプリケーションを使用して1回ログインするだけで済みます。したがって、同じデバイス上の複数のアプリケーションによって共有される1つのユーザー認証セッション(つまり、1つのAccess Managerセッション)のみが存在するようになります。一方、ユーザーが同じAccess Managerセッション内で3つのアプリケーションすべてを同時に使用する場合、各モバイル・アプリケーションは独自のOAAMセッション・エントリを持つことになり、OAAM管理コンソールには3つのOAAMセッションが表示されるようになります。

モバイル・アプリケーションごとに独立したOAAMセッションを持つ理由は、ルールがモバイル・クライアント・アプリケーションを考慮できるようにするためです。同じルールによって、いくつかのアプリケーションからのセッションをブロックすると同時に、他のアプリケーションからのセッションを許可することができます。(第38.9.2.4.2項のブラックリストに記載されたアプリケーション・ルールが、これの一例です。)さらに高度なルールでは、1つのセッションの複数の要因を考慮できます。たとえば、経費レポート・アプリケーションは機密度が高いと評価する一方で、ホワイト・ページ(ディレクトリ参照)アプリケーションは機密度が低いと評価できます。同じ「リスクのあるIP」ルールによって、同じ中程度のリスクのあるIPアドレスからのセッションであっても、経費レポート・アプリケーションではセッションをブロックし、ホワイト・ページ・アプリケーションではブロックしないことが可能です。

38.9.2.6 OAAM認証のユーザー登録

OAAMは、ナレッジベース認証やワンタイム・パスワードなどの強力な認証機能を提供します。ワンタイム・パスワードは、電子メールまたはモバイル・テキスト・メッセージを使用してパスワードを提供します。これらの機能では、エンドユーザーがセキュリティ・プロファイルを登録する必要があります。それには、セキュリティ上の質問、携帯電話番号および電子メール・アドレスが含まれる場合があります。

注意:

詳細は、Oracle Adaptive Access Manager管理者ガイドを参照してください。

次の各項では、これらの認証プロセスを設定する方法について説明します。

- OAAMナレッジベース認証の設定

- OAAMワンタイム・パスワードの設定

38.9.2.6.1 OAAMナレッジベース認証の設定

Mobile and Socialは、OAAMがインストールされている場合、ナレッジベース認証(KBA)を提供します。KBAは、OAAMの強力な認証のデフォルト・オプションです。管理者は、KBAを機能させるために特別な構成をする必要はありません。ユーザーは、OAAM管理対象サーバー・コンソールを使用して、彼らのKBA質問を彼らのユーザー・プロファイルの登録に記録する必要があります。KBAの詳細は、Oracle Adaptive Access Manager管理者ガイドを参照してください。

38.9.2.6.2 OAAMワンタイム・パスワードの設定

Mobile and Socialは、OAAMがインストールされている場合、ワンタイム・パスワード(OTP)のサポートを提供します。OTPを使用すると、エンド・ユーザーはサーバーが生成したワンタイム・パスワードを入力することで認証されるようになります。このパスワードは、SMSまたは電子メールで受信することになります。ワンタイム・パスワードは帯域外で送信されるため、有効なユーザー以外の他者がワンタイム・パスワードへのアクセスを取得するリスクは軽減されます。次の各項では、詳細を説明します。

- OTP電子メール統合の設定

- SMSメッセージ用のOTP統合の設定

- OAAMチャレンジ・ポリシー・トリガー組合せの変更

38.9.2.6.3 OTP電子メール統合の設定

Mobile and Socialは、次のいずれかの方法で電子メールを送信できます。

- 組込みのSMTPクライアントの使用

- Oracle User Messaging Service (UMS)の使用

この項では、これらの統合手順について説明します。電子メール用のSMTPの設定または電子メール用のUMSの設定のどちらからを選択して、開始してください。

注意:

SMTPまたはUMSのいずれかを構成します。両方を構成できません。

SMTPまたはUMSの属性値を構成した後で、この項の3番目の手順「OAAMサーバーでの電子メール用のチャレンジ・タイプの有効化」で説明するように、OAAMサーバーでチャレンジ・タイプを有効にしてください。

電子メール用のSMTPの設定

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. 画面の右側にある「セキュリティ・ハンドラ・プラグイン」セクションで、「OaamSecurityHandlerPlugin」をクリックし、ツールバーの「編集」をクリックします。

3. 「属性」セクションで、次の属性名の値を入力し、「適用」をクリックします。
mail.smtp.host - SMTPサーバー・ホスト。

mail.smtp.port - SMTPサーバー・ポート。

mail.smtp.security.type - SMTPセキュリティ・タイプ。SSLまたはTLSです。

mail.smtp.user - SMTPサーバーにログオンするためのユーザー名。

mail.smtp.fromadd - Mobile and Socialの発信元アドレス。たとえば、mobileadmin@example.comです。

mail.smtp.password - mail.smtp.userアカウントのパスワード。

mail.smtp.truststore.location - サーバー・アイデンティティの検証に使用されるトラスト・ストアの場所を含むファイル名。

mail.smtp.keystore.location - クライアント証明書を含むキー・ストアのファイル名。

mail.smtp.keystore.password - キー・ストア・パスワード。

mail.smtp.truststore.password - トラスト・ストア・パスワード。

4. 「OAAMサーバーでの電子メール用のチャレンジ・タイプの有効化」の手順を完了します。

電子メール用のUMSの設定

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. 画面の右側にある「セキュリティ・ハンドラ・プラグイン」セクションで、「OaamSecurityHandlerPlugin」をクリックし、ツールバーの「編集」をクリックします。

3. 「属性」セクションで、次の属性名の値を入力し、「適用」をクリックします。
ums.service.uri - UMSサーバーのWebサービスURL。たとえば、次のようになります。

http://<UMS Server URL>:<UMS Port>/ucs/messaging/webservice

ums.username - UMSサーバーのユーザー名。

ums.password - UMSサーバーのパスワード。

ums.from.address - Mobile and Socialの発信元アドレス。たとえば、mobileadmin@example.comです。

ums.from.name - Mobile and Socialの発信元名。

ums.email.enabled - trueに設定します。

4. 「OAAMサーバーでの電子メール用のチャレンジ・タイプの有効化」の手順を完了します。

OAAMサーバーでの電子メール用のチャレンジ・タイプの有効化

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで、「環境」→「プロパティ」を選択し、「プロパティ」をダブルクリックしします。
プロパティ検索ページが表示されます。

3. 「検索」ボックスで、「名前」フィールドにbharosa.uio.default.register.userinfo.enabledと入力し、「検索」をクリックします。
「検索結果」セクションでクリックしてレコードを選択し、その値をtrueに変更して「保存」をクリックします。

4. 「検索」ボックスで、「名前」フィールドにbharosa.uio.default.userinfo.inputs.enum.email.enabledと入力し、「検索」をクリックします。
「検索結果」セクションでクリックしてレコードを選択し、その値をtrueに変更して「保存」をクリックします。

5. 「検索」ボックスで、「名前」フィールドにbharosa.uio.default.challenge.type.enum.ChallengeEmail.availableと入力し、「検索」をクリックします。
「検索結果」セクションでクリックしてレコードを選択し、その値をtrueに変更して「保存」をクリックします。

38.9.2.6.4 SMSメッセージ用のOTP統合の設定

Mobile and Socialは、Oracle UMSを使用してSMSメッセージを送信します。「UMSを使用するSMSの設定」を完了してから、「OAAMサーバーでのSMS用のチャレンジ・タイプの有効化」を完了してください。

UMSを使用するSMSの設定

1. Oracle Access Managementコンソールで、「モバイル・サービス」ホーム・ページを開きます(第38.1項「モバイル・サービスのGUIのナビゲート」を参照)。

2. 画面の右側にある「セキュリティ・ハンドラ・プラグイン」セクションで、「OaamSecurityHandlerPlugin」をクリックし、ツールバーの「編集」をクリックします。

3. 「属性」セクションで、次の属性名の値を入力し、「適用」をクリックします。
ums.service.uri - UMSサーバーのWebサービスURL。たとえば、次のようになります。

http://<UMS Server URL>:<UMS Port>/ucs/messaging/webservice

ums.username - UMSサーバーのユーザー名。

ums.password - UMSサーバーのパスワード。

ums.from.address - Mobile and Socialの発信元アドレス。たとえば、mobileadmin@example.comです。

ums.from.name - Mobile and Socialの発信元名。

ums.email.enabled - trueに設定します。

4. 「OAAMサーバーでのSMS用のチャレンジ・タイプの有効化」の手順を完了します。

OAAMサーバーでのSMS用のチャレンジ・タイプの有効化

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで、「環境」→「プロパティ」を選択し、「プロパティ」をダブルクリックしします。
プロパティ検索ページが表示されます。

3. 「検索」ボックスで、「名前」フィールドにbharosa.uio.default.register.userinfo.enabledと入力し、「検索」をクリックします。
「検索結果」セクションでクリックしてレコードを選択し、その値をtrueに変更して「保存」をクリックします。

4. 「検索」ボックスで、「名前」フィールドにbharosa.uio.default.challenge.type.enum.ChallengeSMS.availableと入力し、「検索」をクリックします。
「検索結果」セクションでクリックしてレコードを選択し、その値をtrueに変更して「保存」をクリックします。

38.9.2.6.5 OAAMチャレンジ・ポリシー・トリガー組合せの変更

OAAMは、イベントによってチャレンジ・アクションがトリガーされるとチャレンジ・ポリシーを評価します。KBAがユーザーに対してアクティブになっている場合、OAAMチャレンジ質問アクション・グループからユーザーに質問が出されます。ユーザーがOAAMチャレンジ質問に3回失敗すると、OAAM SMSチャレンジ・アクション・グループが起動されます。

OAAMチャレンジ・ポリシー・トリガー組合せを使用してアクション・グループを並べ替えることができます。それによって、OAAMチャレンジ電子メール・グループやOAAMチャレンジSMSグループなど、他のチャレンジ・アクション・グループが、OAAMチャレンジ質問よりも優先されるようになります。次の手順では、OAAMチャレンジ・ポリシー・トリガー組合せの変更方法を説明します。

1. OAAM管理コンソールにログインします。

2. ナビゲーション・ペインで、「ポリシー」をダブルクリックします。
ポリシー検索ページが表示されます。

3. 「チェックポイント」メニューから「チャレンジ」を選択し、「検索」をクリックします。

4. 「検索結果」表で、クリックして「OAAMチャレンジ・ポリシー」を選択します。

5. 「トリガー組合せ」タブをクリックします。

6. 「順序変更」をクリックします。
「トリガー組合せの順序変更」ポップアップ・ウィンドウが開きます。

7. このコントロールを使用してトリガー組合せを高い位置または低い位置に移動します。

39 インターネット・アイデンティティ・サービスの構成

Mobile and Socialには、インターネット・アイデンティティ・サービスを構成するためのGUIが用意されています。この章では、Oracle Access Managementコンソールを使用して、モバイル・サービスを構成する方法について説明します。この章の内容は、次のとおりです。

- インターネット・アイデンティティ・サービスのGUIのナビゲート

- インターネット・アイデンティティ・サービスの構成の理解

- インターネット・アイデンティティ・プロバイダの定義

- サービス・プロバイダ・インタフェースの定義

- アプリケーション・プロファイルの定義

- インターネット・アイデンティティ・サービスとモバイル・アプリケーションの統合

注意:

インターネット・アイデンティティ・サービスは、WLSTを使用することでコマンドラインから構成することもできます。Mobile and SocialのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

39.1 インターネット・アイデンティティ・サービスのGUIのナビゲート

インターネット・アイデンティティ・サービスのグラフィカル・ユーザー・インタフェース(GUI)は、管理者が正常に認証されてOracle Access Managementコンソールへのアクセスが得られると表示できるようになります。このコンソールは、次の部分に分割されています。

- ホーム・エリアは、コンソールが最初に表示されたときに、GUIの右側に配置される広いウィンドウです。このページには、インターネット・アイデンティティ・サービスのほとんどの構成オブジェクトが一覧表示され、構成プロセスを論理的な順序で進められるように編成されています。ホーム・エリア内の構成オブジェクトは、パネルの左上隅にある矢印ボタンをクリックすることで展開または縮小できるパネルに表示されます。

- ナビゲーション・ペインは、GUIの左部分に表示されます。このペインは、インターネット・アイデンティティ・サービス構成オブジェクトを階層型ビューで表示します。ほとんどの場合、構成オブジェクトの作成、編集および削除には、ホーム・エリアまたはナビゲーション・ペインのいずれかを使用できます。(ただし、ジェイルブレーク検出ポリシー構成オブジェクトを開く場合は、ナビゲーション・ペインを使用する必要があります。)ナビゲーション・ペイン内のコントロールを使用すると、構成オブジェクトを作成、表示、編集および削除できます。
ナビゲーション・ペインを使用すると、構成オブジェクトを関係ビューまたはカテゴリ・ビューで表示できます。関係ビューには、構成オブジェクトが階層順に表示されます(サービス・ドメインが一番上)。カテゴリ・ビューには、構成オブジェクトを簡単に参照できるようにするフラット構造を使用して、構成オブジェクトがオブジェクト・タイプ別にリストされます。2つのビューを切り替えるには、ツリービュー・ペインの上部にあるメニュー・バーのボタンを使用します。

次の手順を実行すると、インターネット・アイデンティティ・サービスの構成ページにアクセスできます。

1. Oracle Access Managementコンソールにログインします。

2. コンソールの上部にある、「システム構成」タブをクリックします。

3. ページの左側にある「Mobile and Social」をクリックします。

4. 「インターネット・アイデンティティ・サービス」をクリックします。
「Mobile and Socialへようこそ - インターネット・アイデンティティ・サービス」ページがホーム・エリアにロードされます。

39.2 インターネット・アイデンティティ・サービスの構成の理解

「Mobile and Socialへようこそ - インターネット・アイデンティティ・サービス」の構成ページは、ホーム・エリアに表示されます。これは、複数のパネルに分割されていて、管理時には表示または非表示にできます。次の各項では、「インターネット・アイデンティティ・サービス」パネルについて詳細に説明します。

- インターネット・アイデンティティ・プロバイダの理解

- サービス・プロバイダ・インタフェースの理解

- アプリケーション・プロファイルの理解

39.2.1 インターネット・アイデンティティ・プロバイダの理解

「インターネット・アイデンティティ・プロバイダ」パネルは、GoogleやFacebook、Twitterなどのアイデンティティ・プロバイダの(事前構成されている)構成の詳細を編集するために使用します。これらの設定は、一度確立した後はそれほど頻繁に変更する必要はありません。

Javaインタフェースoracle.security.idaas.rp.spi.IdentityProviderを実装することで、ユーザー自身を追加するインターネット・アイデンティティ・プロバイダの構成の詳細を定義することもできます。インターネット・アイデンティティ・プロバイダの追加の詳細は、Oracle Access Management開発者ガイドのMobile and Socialサーバーの機能の拡張に関する項を参照してください。

インターネット・アイデンティティ・プロバイダの詳細は、第39.3項「インターネット・アイデンティティ・プロバイダの定義」を参照してください。

39.2.2 サービス・プロバイダ・インタフェースの理解

サービス・プロバイダ・インタフェースは、指定したアプリケーション・プロファイルの認証フローを制御する一連のルールを指します。Mobile and Socialは、次のサービス・プロバイダ・インタフェースを提供します。

- DefaultServiceProviderInterface: Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーションのサポートを提供します。

- OAMServiceProviderInterface: Access Managerサービスで実行されるWebアプリケーションのサポートを提供します。

サービス・プロバイダ・インタフェースの詳細は、第39.4項「サービス・プロバイダ・インタフェースの定義」を参照してください。

注意:

Java開発者は、1つ以上のアイデンティティ・プロバイダ・インタフェース・コントラクトのカスタム実装を作成できます。「サービス・プロバイダ・インタフェース」セクションは、開発者が作成したカスタム・サービス・プロバイダを追加する必要がある場合にのみ使用します。

39.2.3 アプリケーション・プロファイルの理解

アプリケーション・プロファイルでは、Mobile and Socialサーバー上のインターネット・アイデンティティ・プロバイダ・サービスを使用するアプリケーションを定義します。このパネルを使用して、モバイル・アプリケーション、Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーション、およびAccess Managerと統合されるWebアプリケーションが、インターネット・アイデンティティ・サービスを使用するように構成します。

- WebアプリケーションがAccess Managerと統合されていない場合は、インターネット・アイデンティティ・サービスのログイン・ページをWebアプリケーションと統合します。詳細は、Oracle Access Management開発者ガイドの「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。

- WebアプリケーションがAccess Managerに統合されている場合は、OAMApplicationという名前の事前構成済のアプリケーション・プロファイルを編集します。Oracle Access Managementのインストール時に、Access ManagerとMobile and Socialを同時にインストールすると、両方の製品が信頼されたパートナとして登録され、事前構成済のアプリケーション・プロファイルが含まれます。そのため、Access Managerとインターネット・アイデンティティ・サービスに統合されているWebアプリケーションを統合するために、コードを記述する必要はありません。Mobile and Socialに組み込まれているOAMApplicationアプリケーション・プロファイルは、Access Managerと連動するように事前構成済であり、わずかな構成変更を実行するだけで、使用している環境で動作するようになります。

アプリケーション・プロファイルの詳細は、第39.5項「アプリケーション・プロファイルの定義」を参照してください。

39.3 インターネット・アイデンティティ・プロバイダの定義

インターネット・アイデンティティ・プロバイダは、GoogleやFacebook、Twitterなどのアイデンティティ・プロバイダについての構成詳細を収集します。インターネット・アイデンティティ・プロバイダの作成後に、その設定を変更する必要はほとんどありません。次の各項では、インターネット・アイデンティティ・プロバイダの作成、変更および削除について説明します。

- インターネット・アイデンティティ・プロバイダの作成

- インターネット・アイデンティティ・プロバイダの編集または削除

- OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成

- インターネット・アイデンティティ・プロバイダのトラブルシューティング

39.3.1 インターネット・アイデンティティ・プロバイダの作成

1. Oracle Access Managementコンソールで、「インターネット・アイデンティティ・サービス」ホーム・ページを開きます(第39.1項「インターネット・アイデンティティ・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「インターネット・アイデンティティ・プロバイダ」パネルで、「作成」をクリックします。
「新規インターネット・アイデンティティ・プロバイダの作成」構成ページが表示されます。

3. インターネット・アイデンティティ・プロバイダのプロパティに値を入力します。

- 名前: この認証サービス・プロバイダに一意の名前を入力します。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

- インターネット・アイデンティティ・プロバイダ・プロトコル: ドロップダウン・メニューからアイデンティティ・プロバイダを選択します。

- Google (OpenID)

- Yahoo (OpenID)

- Facebook (OAuth)

- Twitter (OAuth)

- LinkedIn (OAuth)

「カスタム」を選択すると、カスタム・アイデンティティ・プロバイダを構成できます。ここでの選択内容により、表示される「プロトコル属性」パネルと「返されたユーザー属性」パネルは、そのインターネット・アイデンティティ・プロバイダ(OpenIDまたはOAuth)で使用する認証プロトコルに特有のプロパティを反映するように変更されます。

- 実装クラス: このフィールドには、インターネット・アイデンティティ・プロバイダの選択に基づいて、それに該当するプロバイダ固有のJavaインタフェースoracle.security.idaas.rp.spi.IdentityProviderの実装が移入されます。(「カスタム」の場合は、そのアイデンティティ・プロバイダと通信する該当の実装クラスを入力します。)Mobile and Socialサーバーは、この情報を使用して、インターネット・アイデンティティ・プロバイダと通信します。

4. 「プロトコル属性」のプロパティに値を入力します。この値は、前の手順で選択したインターネット・アイデンティティ・プロバイダで使用するプロトコル「OpenID」(表39-1)または「OAuth」(表39-2)に基づいて決定します。(「カスタム」の場合、カスタム・プロバイダに必要な値と、使用される認証プロトコルに関連する値をすべて追加します。)

- OpenIDプロトコルを実装するアイデンティティ・プロバイダに必要になる値を指定します(表39-1を参照)。

表39-1 OpenIDプロトコルの属性

名前

値

注意

Yadisエンドポイント

HTTPまたはHTTPSの絶対URLになります

このアイデンティティ・プロバイダのOpenID認証プロトコル・メッセージを受け入れる、公開URLを入力します。Mobile and Socialは、このURLを使用して、ユーザー認証リクエストを作成します。

ハッシュ・アルゴリズム

- SHA256は、256ビット長の鍵アルゴリズムです

- SHA1は、160ビット長の鍵アルゴリズムです

- なし

署名アルゴリズムを選択します。Mobile and Socialによって、この値が内部で使用されて、アイデンティティ・プロバイダと通信するためのセッション・タイプおよびアソシエーション・タイプ・プロパティが構成されます。

認証ポリシー

ユーザーの認証時、OpenIDプロバイダで認証ポリシーを適用することを要求する場合は「はい」を選択します。それ以外の場合は、「いいえ」を選択します。

PAPE (Provider Authentication Policy Extension)の使用により、Web開発者は、アイデンティティ・プロバイダからユーザーにパスワードの入力を再度要求することなどフローに対するその他の変更を要求できます。

認証ポリシー最大期間

0秒以上の値を指定します。パスワードの再入力の要求を強制するには、0を指定します。

アクティブに認証を受けていないユーザーが、要求された認証ポリシーを使用して認証を受けることが必要になる前にログイン・セッションを使用できる最長時間を秒単位で入力します。このパラメータを使用すると、アイデンティティ・プロバイダへのユーザーのログイン・セッションが最新であることを確実にできます。

優先認証ポリシー

ユーザーの認証時、アイデンティティ・プロバイダが満たす必要がある認証ポリシーを表す0個以上のURIを空白で区切って入力します。次に例を示します。

http://schemas.openid.net/pape/policies/2007/06/phishing-resistant

http://schemas.openid.net/pape/policies/2007/06/multi-factor

- OAuthプロトコルを実装するアイデンティティ・プロバイダに必要になる値を指定します(表39-2を参照)。

表39-2 OAuthプロトコルの属性

名前

値

注意

認可URL

アイデンティティ・プロバイダの公開OAuth認可URLです。アイデンティティ・プロバイダが公開OAuth URLを変更したときには、それに合せて、この値を更新します。

アイデンティティ・プロバイダによってリクエスト・トークンが返された後、Mobile and SocialによってユーザーがこのURLに誘導されます(リクエスト・トークンURLを参照してください)。アイデンティティ・プロバイダによってユーザーのアイデンティティが検証され、ユーザーは、ユーザーの保護されている情報をMobile and Socialサーバーに解放する権限をアイデンティティ・プロバイダに付与します。

アクセス・トークンURL

アイデンティティ・プロバイダの公開アクセス・トークンURLを入力します。

ユーザーがリクエスト・トークンを(認可URLを使用して).認可した後、Mobile and SocialによってこのURLが使用されてアイデンティティ・プロバイダにアクセス・トークンが要求されます。

リクエスト・トークンURL

アイデンティティ・プロバイダの公開リクエスト・トークンURLを入力します。(Facebookには適用されません。)

Mobile and Socialは、このURLを使用して、アイデンティティ・プロバイダからリクエスト・トークンを取得します。アイデンティティ・プロバイダによってリクエスト・トークンが付与された後、Mobile and Socialサーバーによってユーザーがアイデンティティ・プロバイダの認可URLに誘導されます。(RFC 5849「The OAuth 1.0 Protocol」のrequest tokenおよびrequest secretという用語は、temporary credentialsという用語にかわりました。)

プロファイルURL

アイデンティティ・プロバイダの公開プロファイルURLを入力します。

Mobile and Socialは、このURLを使用して、OAuthアクセス・トークンに基づいてユーザー属性を要求します。

コンシューマ・キー

Mobile and Socialサーバーが、それ自体をアイデンティティ・プロバイダに識別させるために使用する値を入力します。

アイデンティティ・プロバイダからコンシューマ・キーを要求する方法の詳細は、第39.3.3項「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。

コンシューマ・シークレット

コンシューマ・キーの所有権を確立するためにMobile and Socialサーバーが使用するシークレットを入力します。

アイデンティティ・プロバイダからコンシューマ・シークレットを要求する方法の詳細は、第39.3.3項「OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成」を参照してください。

サーバー時間同期

Mobile and Socialサーバーとリモート・アイデンティティ・プロバイダの時間が同期されていない場合は、リモート・プロバイダにリクエストを送信するときに現在のサーバー時刻に追加するスキューを分単位で入力します。このフィールドには、正と負の両方の整数を入力できます。

通常、LinkedInでは、同期しているサーバー時刻値が必要とされます。FacebookやTwitterには適用されません。

「属性名」列に、OpenIDアイデンティティ・プロバイダによって返される属性名に割り当てるローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。

「属性名」列に、アイデンティティ・プロバイダがサポートしていない属性を追加した場合、それらの属性は、Mobile and Socialで使用できません。

5. 「返されたユーザー属性」パネルに値を追加します。この値は、前の手順で選択したインターネット・アイデンティティ・プロバイダのプロトコル「OpenID」、「OAuth」または「カスタム」に基づいて決定します。

- OpenID: 「属性名」列に、アイデンティティ・プロバイダが返す属性名に割り当てる、ローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。「属性名」列に、アイデンティティ・プロバイダがサポートしていない属性を追加した場合、それらの属性は、Mobile and Socialで使用できません。表39-3「Googleが返すユーザー属性値」と表39-4「Yahooが返すユーザー属性値」に、GoogleおよびYahooがサポートするユーザー属性を示します。

表39-3 Googleが返すユーザー属性

属性

説明

country

ユーザーの母国を要求します。次のように設定する必要があります。http://axschema.org/contact/country/home

email

ユーザーのGmailアドレスを要求します。次のように設定する必要があります。

http://axschema.org/contact/email

firstname

ユーザーの名前を要求します。次のように設定する必要があります。

http://axschema.org/namePerson/first

language

ユーザーの優先言語を要求します。次のように設定する必要があります。

http://axschema.org/pref/language

lastname

ユーザーの姓を要求します。次のように設定する必要があります。

http://axschema.org/namePerson/last

表39-4 Yahooが返すユーザー属性

属性

説明

gender

ユーザーの性別を要求します。次のように設定する必要があります。

http://axschema.org/person/gender

email

ユーザーの電子メール・アドレスを要求します。次のように設定する必要があります。

http://axschema.org/contact/email

fullname

ユーザーの姓名を要求します。次のように設定する必要があります。

http://axschema.org/namePerson

language

ユーザーの優先言語を要求します。次のように設定する必要があります。

http://axschema.org/pref/language

nickname

ユーザーの希望する名前を要求します。次のように設定する必要があります。

http://axschema.org/namePerson/friendly

Timezone

ユーザーの優先タイムゾーンを要求します。次のように設定する必要があります。

http://axschema.org/pref/timezone

- OAuth: OAuthアイデンティティ・プロバイダ(Twitter、FacebookおよびLinkedIn)が返すユーザー・プロファイル属性を指定します。「属性名」列に、アイデンティティ・プロバイダによって返される属性名に対応するローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、アイデンティティ・プロバイダ属性名を入力します。OAuthプロバイダの場合、「属性名」値と「属性スキーマ名」 値は、通常、同じです。

注意:

LinkedInは、ユーザー・アイデンティティ属性をMobile and Socialに返すときに電子メール・アドレスも暗号化されていないログインIDも返しません。LinkedInからのアイデンティティ属性を使用して、ユーザーの登録フォームに事前移入する場合は、この制限に注意してください。

- カスタム: 「属性名」列に、カスタム・アイデンティティ・プロバイダが返す属性名に割り当てる、ローカル・アプリケーション属性名を入力します。「属性スキーマ名」列に、Mobile and Socialサーバーがアイデンティティ・プロバイダにユーザー・データを要求できるURLを入力します。

6. 「作成」をクリックして、インターネット・アイデンティティ・プロバイダ構成オブジェクトを作成します。

39.3.2 インターネット・アイデンティティ・プロバイダの編集または削除

インターネット・アイデンティティ・プロバイダを編集または削除するには、パネルでプロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第39.3.1項「インターネット・アイデンティティ・プロバイダの作成」を参照してください。

39.3.3 OAuthプロバイダのコンシューマ・キーおよびコンシューマ・シークレットの生成

次の各項では、OAuthプロトコルをサポートするインターネット・アイデンティティ・プロバイダ用のコンシューマ・キーとコンシューマ・シークレットの生成方法について説明します。

- Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成

- Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成

- LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成

注意:

この項の手順は、このドキュメントの公開日の時点で正確です。Facebook、TwitterおよびLinkedInのWebサイトを使用したコンシューマ・キーおよびコンシューマ・シークレットの作成に必要な手順は、常に変更される可能性があります。

39.3.3.1 Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Facebook用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

1. 次のURLをWebブラウザで開きます。
https://developers.facebook.com/apps

2. 「Create New App」をクリックします。

3. 「Create New App」フォームに入力します。
Facebookによりアプリケーションが作成され、それに一意のアプリケーションIDおよびアプリケーション・シークレットが割り当てられます。

4. 「Basic Info」セクションに情報を入力します。
「Select how your application integrates with Facebook」セクションで、「Website with Facebook Login」を選択します。

5. 「Site URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。
http://OAM-Hosted-Machine: Port/

6. 「Save Changes」をクリックします。

7. 第39.4.1項の説明に従って、「インターネット・アイデンティティ・プロバイダ」→「フェイスブック」構成ページを開いて編集します。

8. 「コンシューマ・キー」フィールドにアプリケーションIDを、「コンシューマ・シークレット」フィールドにアプリケーション・シークレットを貼り付けます。
「適用」をクリックして、変更を保存します。

39.3.3.2 Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、Twitter用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

1. 次のURLをWebブラウザで開きます。
https://dev.twitter.com/apps/new

2. 「Create an application」フォームに入力します。
「Callback URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。

http://OAM-Hosted-Machine: Port/oic_rp/return

Twitterによりアプリケーションが作成され、それに一意のコンシューマ・キーおよびコンシューマ・シークレットが割り当てられます。

3. (オプション)自分のTwitterアプリケーションを必要に応じて構成し、変更内容を保存します。

4. 第39.4.1項の説明に従って、「インターネット・アイデンティティ・プロバイダ」→「ツイッター」構成ページを開いて編集します。

5. 「コンシューマ・キー」フィールドにコンシューマ・キーを、「コンシューマ・シークレット」フィールドにコンシューマ・シークレットを貼り付けます。
「適用」をクリックして、変更を保存します。

39.3.3.3 LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成

この項では、LinkedIn用のコンシューマ・キーとコンシューマ・シークレットの生成方法を説明します。

1. 次のURLをWebブラウザで開きます。
https://www.linkedin.com/secure/developer?newapp=

2. 「Add New Application」フォームに入力します。
「OAuth User Agreement」セクションの「OAuth Redirect URL」フィールドに、Mobile and Socialサーバーに到達できるURLを入力します。次に例を示します。

http://OAM-Hosted-Machine: Managed Server Port/

3. 「Add Application」をクリックします。
LinkedInによってアプリケーションが作成され、それに一意のAPIキーおよびシークレット・キーが割り当てられます。

4. 第39.4.1項の説明に従って、「インターネット・アイデンティティ・プロバイダ」→LinkedIn構成ページを開いて編集します。

5. 「コンシューマ・キー」フィールドにAPIキーを、「コンシューマ・シークレット」フィールドにシークレット・キーを貼り付けます。
「適用」をクリックして、変更を保存します。

39.3.4 インターネット・アイデンティティ・プロバイダのトラブルシューティング

この項では、Facebookインターネット・アイデンティティ・プロバイダに影響する、既知の構成問題について説明します。

- Facebookとの互換性があるWebLogic Serverの構成

- Facebookとの互換性があるWebLogic Server 10.3.5以前の構成

39.3.4.1 Facebookとの互換性があるWebLogic Serverの構成

次の手順に従って、FacebookをサポートするようにWebLogic Serverを構成します。

1. WebLogicコンソールを開きます。
http://host:port/console

2. 「ドメイン」→「環境」→「サーバー」→「管理対象サーバー」を選択します。

3. 「SSL」タブ、「詳細」を順にクリックします。

4. ロックして編集構成をクリックします。

5. ホスト名検証機能を「なし」に変更します。

6. 管理対象サーバーを再起動します。

ホスト名検証機能が「なし」に設定されていないと、Facebookがアイデンティティ・プロバイダである場合に、保護されたリソースへのアクセスが試みられたときに次のエラーが表示されることがあります。

Exception in processRequest method: oracle.security.idaas.rp.RPException:
oracle.security.idaas.rp.RPException: Request failed:

39.3.4.2 Facebookとの互換性があるWebLogic Server 10.3.5以前の構成

FacebookのSSL証明書には、ワイルドカード識別子として*.facebook.comが含まれています。WebLogic Serverバージョン10.3.5以前には、ワイルドカードを含むホスト名の検証に問題があります。このため、Facebookと、WebLogic Server上にデプロイされたOracle Access Management Mobile and Socialのインストールの間に通信障害が発生する場合があります。回避方法は、次のとおりです。

- WebLogic Serverバージョン10.3.5またはそれ以前を使用している場合、次の手順を実行します。

1. 管理コンソールで、「サーバー」→「oam_server_where_Mobile_and_Social_is_deployed」→「SSL」→「詳細」を選択します。

2. ホスト名検証機能を「なし」に変更します。

- このWebLogic Serverのバグは、バージョン10.3.6で次のように修正されました。新しいカスタム・ホスト名検証機能SSLWLSWildcardHostnameVerifierが実装されました。これは、デフォルトのホスト名検証機能から導出されており、SANなど、デフォルトのホスト名検証機能で実行できることがすべてサポートされています。SSLハンドシェイク中にワイルドカード証明書のサポートが必要な場合はこのカスタム・ホスト名検証機能を使用するようにWebLogic Serverを構成する必要があります。1つの選択肢としては、次のWebLogicプロパティを使用することがありです。

-Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildca rdHostnameVerifier

39.4 サービス・プロバイダ・インタフェースの定義

サービス・プロバイダ・インタフェースは、指定したアプリケーション・プロファイルの認証フローを制御する一連のルールを指します。Mobile and Socialは、次のサービス・プロバイダ・インタフェースを提供します。

- DefaultServiceProviderInterface: Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーションのサポートを提供します。

- OAMServiceProviderInterface: Access Managerサービスで実行されるWebアプリケーションのサポートを提供します。

必要に応じて、Java開発者は、1つ以上のアイデンティティ・プロバイダ・インタフェース・コントラクトのカスタム実装を作成できます。この項には次のトピックが含まれます:

- サービス・プロバイダ・インタフェースの作成

- サービス・プロバイダ・インタフェースの編集または削除

- カスタム・サービス・プロバイダ・インタフェース実装の追加

39.4.1 サービス・プロバイダ・インタフェースの作成

1. Oracle Access Managementコンソールで、「インターネット・アイデンティティ・サービス」ホーム・ページを開きます(第39.1項「インターネット・アイデンティティ・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「サービス・プロバイダ・インタフェース」パネルで、「作成」をクリックします。
「新規サービス・プロバイダ・インタフェースの作成」構成ページが表示されます。

3. サービス・プロバイダ・インタフェースのプロパティに値を入力します。

- 名前: この認証サービス・プロバイダに一意の名前を入力します。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

4. インタフェース情報のプロパティに値を入力します(表39-5を参照)。

表39-5 サービス・プロバイダ・インタフェースのプロパティ

名前

注意

IDPセレクタ

カスタム・プロバイダのIDPセレクタ実装クラスを選択します。

ポストIDPセレクタ

カスタム・プロバイダのポストIDPセレクタ実装クラスを選択します。

IDP相互作用プロバイダ

カスタム・プロバイダのIDP相互作用プロバイダ実装クラスを選択します。

登録ステータス・チェック

カスタム・プロバイダの登録ステータス・チェック実装クラスを選択します。

セッション作成プロバイダ

カスタム・プロバイダのセッション作成プロバイダ実装クラスを選択します。

5. 「作成」をクリックして、サービス・プロバイダ・インタフェース構成オブジェクトを作成します。

39.4.2 サービス・プロバイダ・インタフェースの編集または削除

サービス・プロバイダ・インタフェースを編集または削除するには、パネルでプロバイダを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第39.4.1項「サービス・プロバイダ・インタフェースの作成」を参照してください。

39.4.3 カスタム・サービス・プロバイダ・インタフェース実装の追加

カスタム・インタフェース実装を追加するには、新しいインターネット・アイデンティティ・プロバイダを作成し、業務目的に合わせて必要に応じてカスタムまたはデフォルト、あるいはその両方の実装クラスの組合せを必要に応じて選択します。詳細は、Oracle Access Management開発者ガイドのインターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発に関する項を参照してください。

39.5 アプリケーション・プロファイルの定義

アプリケーション・プロファイルでは、Mobile and Socialサーバー上のインターネット・アイデンティティ・プロバイダ・サービスを使用するアプリケーションを定義します。このパネルを使用して、モバイル・アプリケーション、Javaに準拠したアプリケーション・サーバーで実行されるWebアプリケーション、およびAccess Managerと統合されるWebアプリケーションが、インターネット・アイデンティティ・サービスを使用するように構成します。

- WebアプリケーションがAccess Managerと統合されていない場合は、インターネット・アイデンティティ・サービスのログイン・ページをWebアプリケーションと統合します。詳細は、Oracle Access Management開発者ガイドの「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」の章を参照してください。

- WebアプリケーションがAccess Managerに統合されている場合は、OAMApplicationという名前の事前構成済のアプリケーション・プロファイルを編集します。Oracle Access Managementのインストール時に、Access ManagerとMobile and Socialを同時にインストールすると、両方の製品が信頼されたパートナとして登録され、事前構成済のアプリケーション・プロファイルが含まれます。そのため、Access Managerとインターネット・アイデンティティ・サービスに統合されているWebアプリケーションを統合するために、コードを記述する必要はありません。Mobile and Socialに組み込まれているOAMApplicationアプリケーション・プロファイルは、Access Managerと連動するように事前構成済であり、わずかな構成変更を実行するだけで、使用している環境で動作するようになります。

通常、Access ManagerでWebゲートを構成すると、リソースおよびポリシーを含むアプリケーション・ドメインが作成されます。Mobile and Socialでは、OAMApplicationが、Access Managerのアプリケーション・ドメインに対応するアプリケーション・プロファイルです。そのため、10個のWebゲートをAccess Managerで定義し、それぞれが、ユーザー認証にMobile and Socialを使用する必要がある1つのアプリケーションを表している場合は、OAMApplicationをテンプレートとして使用してその10個のアプリケーション・ドメインに一致する名前を持つ10個の対応するアプリケーション・プロファイルを作成します。

注意:

Access Managerでアプリケーションを保護するためにWebゲートをインストールすると、そのWebゲートのセットアップにより、認証メカニズムとしてLDAPを備えたアプリケーション・ドメインが自動的に作成されます。Mobile and Social認証を使用するには、認証スキームをOICSchemeに変更します。

この項では、アプリケーション・プロファイルの作成ウィザードおよびアプリケーション・プロファイルの編集ページのヘルプを提供します。

次の各項では、詳細を説明します。

- アプリケーション・プロファイルの作成

- アプリケーション・プロファイルの編集または削除

39.5.1 アプリケーション・プロファイルの作成

1. Oracle Access Managementコンソールで、「インターネット・アイデンティティ・サービス」ホーム・ページを開きます(第39.1項「インターネット・アイデンティティ・サービスのGUIのナビゲート」を参照)。

2. ホーム・エリアの「アプリケーション・プロファイル」パネルで、「作成」をクリックします。
「新規アプリケーション・プロファイルの作成」構成ページが表示されます。

3. アプリケーション・プロファイルの一般プロパティに値を入力します。

- 名前 - Webアプリケーションまたはモバイル・アプリケーションのコンテキスト名を表示します。この名前は、リソースを保護しているエージェントに登録されている名前と一致する必要があります。アプリケーションがAccess Managerに統合されている場合は、Access Managerに定義されているアプリケーション・ドメイン名が表示されます。この値は、モバイル・サービスのアプリケーション・プロファイルで定義した名前の値と同じにする必要があります(該当する場合)。

- 説明: (オプション)簡単な説明を入力します。この説明は自分や他の管理者が、将来、このサービスを特定するために役立ちます。

- 共有シークレット: モバイル・アプリケーションまたはWebアプリケーションの場合は、そのアプリケーションとMobile and Socialサーバーがセキュアな通信を容易にするために共有するセキュリティ・シークレットを指定します。Mobile and Socialのユーザー登録機能を使用するには、これが必要になります。任意の文字列にすることもできます。

- 戻りURL: アプリケーションがモバイル・アプリケーションの場合、この値は使用されません。ただし、これは必須の属性です。そのため、モバイル・アプリケーションには、「モバイル・アプリケーション戻りURL」を使用してください。Webアプリケーションには、認証レスポンスを送り返すためにMobile and Socialが使用する必要があるURLを入力します。アプリケーションがAccess Managerに統合されている場合は、次のURLを指定します。これは、Mobile and Socialが認証レスポンスを送り返すために使用するURLです。
http://oam-host:port/oam/server/dap/cred_submit

- モバイル・アプリケーション戻りURL - モバイル・アプリケーションに対して、認証レスポンスを送り返すためにMobile and Socialが使用する必要があるURLを入力します。この値は、モバイル・アプリケーションの戻りURLに一致している必要があります。

4. 次のアプリケーション・プロファイル構成のプロパティに値を入力します。

- ログイン・タイプ: ユーザー・ログイン・ページで、ユーザーがローカルでの認証とアイデンティティ・プロバイダを使用する認証のどちらかを選択できるようにする場合は、「ローカル認証およびインターネット・アイデンティティ・プロバイダ認証」を選択します。ユーザー・ログイン・ページで、ユーザーがローカルでの認証のオプションを選択できないようにする場合は、「インターネット・アイデンティティ・プロバイダ認証のみ」を選択します。Mobile and Socialのログイン・ページは「インターネット・アイデンティティ・プロバイダ認証のみ」をサポートしますが、ローカル・ログインのサポートはありません。

- ブラウザ・ポップアップの有効化 - ログイン・ページをボップアップ・ウィンドウで開くには、「はい」を選択します。これがモバイル・アプリケーションの場合は、この値は無効になります。

- ユーザー登録 - ユーザーがインターネット・アイデンティティ・プロバイダで認証を受けた後にアプリケーションに登録できるようにする場合は、「有効」を選択します。アプリケーションのログイン・ページには、「ユーザー登録」フォームが表示され、ユーザーに登録を求めるようになります。ユーザーはそのフォームに入力して登録するか、「登録のスキップ」ボタンをクリックできます。ログイン・ページに「ユーザー登録」フォームを表示せず、ユーザーに登録を求めない場合は、「無効」を選択します。

- 登録URL - ユーザーがローカル・アカウントに登録できるようにユーザーを転送する先となるURLを入力します。通常、ユーザーは、アプリケーション・プロファイルで定義されている登録サービス属性に対応するフィールドがあるフォームに誘導されます。マップでは属性オブジェクトを含む暗号化トークンも、パラメータとしてクライアント・アプリケーションに渡されます。これらの属性は、ユーザーのプロファイル・データを登録ページに事前移入するために使用されます。

- UserID属性 - ユーザーを一意に識別するために使用される属性名を入力します。この属性名は、「アプリケーション・プロファイル構成」ページの「アプリケーション・ユーザー属性」セクションにも表示されます。

- ユーザー・プロファイル・サービス・エンドポイント - アプリケーションによって使用されるユーザー・プロファイル・サービス・エンドポイントを選択します。ユーザー・プロファイル・サービスによって、アプリケーションがLDAPディレクトリ・サービスに誘導され、そこで登録時にユーザーが作成されます。ユーザー・プロファイル・サービス・エンドポイントは、モバイル・サービスで構成されます。

- 認証サービス・エンドポイント: 認証サービス・エンドポイントにより、ローカル・ログインが要求されたときにユーザーを認証する方法が決定されます。モバイル・アプリケーションの場合は、InternetIdentityAuthentication、またはInternetIdentityAuthenticationタイプの任意のカスタム認証を選択します。

- 認証リクエストをAccess Managerに転送するには、「/oamauthentication」を選択します。IAMSuiteアプリケーション・ドメイン内のMobile and Social認証ポリシーと関連付けられた認証スキームにより、ユーザーの認証方法が決定されます。

- 対応するエンドポイントで指定されているアイデンティティ・ストアを使用するには、/internetidentityauthenticationを選択します。

- アプリケーション・プロファイル・プロパティ - アプリケーション・プロファイル属性を表に追加するには、「追加」をクリックします。サポート対象は次のとおりです。

- app.passwd.field - 登録ページ上のパスワードを暗号化します。値としてpasswordを追加します。登録ページでパスワードをアスタリスク(*)でマスクするには、app.passwd.fieldプロパティを追加し、その値としてpasswordを追加します。

- oic.app.idp.oauth.token - Mobile and Socialに、アプリケーションへの最終リダイレクトの一部としてOAuthアクセス・トークンを含めるように指示します。値としてtrueを追加します。ユーザーがOAuthプロバイダ(Facebook、Twitter、LinkedIn)を選択した場合にのみ適用されます。

- oic.app.user.token - ユーザーがアイデンティティ・プロバイダで認証を受けてアプリケーションにリダイレクトされるときにJWTユーザー・トークンを作成します。値としてtrueを追加します。このトークンには、アイデンティティ・プロバイダ関連のURIと、アイデンティティ・プロバイダに記録されているユーザー識別子の値が含まれています。このトークンを使用して、ユーザー・プロファイルRESTサービスなど、他の保護されているMobile and Social RESTサービスにアクセスします。

5. 「追加」をクリックして、インターネット・アイデンティティ・プロバイダが認証後にアプリケーションに返す、アプリケーション・ユーザー属性を追加します。
これらの属性の詳細は、次の「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」の手順で構成します。

6. 「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」表に行を追加して、インターネット・アイデンティティ・プロバイダが提供するアプリケーション属性に、ローカル(ユーザー)登録属性をマップします。
追加のアプリケーション・ユーザー属性については、前の手順で先に追加しておきます。次の各定義は、「登録サービス詳細とアプリケーション・ユーザー属性のマッピング」表のプロパティに適用されます。

- 登録サービス属性 - このメニューから、構成する登録サービス属性を選択します。

- ユーザー属性表示名 - 「登録サービス属性」列の属性に対して、ユーザー登録フォームに表示する名前を入力します。これが、ユーザーに表示される属性名です。

- 読取り専用 - ユーザーによる属性値の更新を防止する場合に選択します。属性値はフォーム上でグレー表示されるようになり、ユーザーによる更新はブロックされるようになります。

注意:

Yahooがインターネット・アイデンティティ・プロバイダである場合は、「名」および「姓」に対して「読取り専用」オプションを選択しないでください。Yahooでは、これらの属性の値は返されません。「読取り専用」オプションを選択すると、ユーザー登録に失敗し、例外エラーが表示されるようになります。

- 必須 - この属性をユーザー登録フォームの必須項目にする場合に選択します。

- アプリケーション・ユーザー属性 - 「登録サービス属性」列の属性に対応する属性を選択します。

7. 「次へ」をクリックして、サービス・プロバイダ・インタフェースを構成します。
「サービス・プロバイダ・インタフェース」ページが表示されます。

8. ドロップダウン・メニューから「DefaultServiceProviderInterface」を選択します。
サービス・プロバイダ・インタフェースの詳細は、第39.4項「サービス・プロバイダ・インタフェースの定義」を参照してください。

9. 「次へ」をクリックして、インターネット・アイデンティティ・プロバイダを構成します。
「インターネット・アイデンティティ・プロバイダ」ページが表示されます。このセクションを使用して、1つ以上のインターネット・アイデンティティ・プロバイダを選択して、ローカル・アプリケーション・ユーザーの属性をインターネット・アイデンティティ・プロバイダの属性にマップします。たとえば、インターネット・アイデンティティ・プロバイダがGoogleの場合、一意のローカル・ユーザー識別子として電子メール・アドレスを使用するには、次の手順を実行します。

1. 「インターネット・アイデンティティ・プロバイダ」列でGoogleを選択します。
2列の表が開きます。

2. 次のようにマッピングを作成します。

1. 「アプリケーション・ユーザー属性」列の最初の行で「uid」を選択します。

2. 「インターネット・アイデンティティ・プロバイダ・ユーザー属性」列で「電子メール」を選択します。

10. 「終了」をクリックして、アプリケーション・プロファイルを作成します。

39.5.2 アプリケーション・プロファイルの編集または削除

アプリケーション・プロファイルを編集または削除するには、パネルでプロファイルを選択してから、そのパネルのツールバーにある「編集」または「削除」をクリックします。属性の説明は、第39.5.1項「アプリケーション・プロファイル」を参照してください。

39.6 インターネット・アイデンティティ・サービスとモバイル・アプリケーションの統合

モバイル・デバイス上のアプリケーションがインターネット・アイデンティティ・サービスを使用して認証を受けられるように、モバイル・サービスを構成できます。インターネット・アイデンティティ・サービスを使用する必要のあるアプリケーションは、それに対応するアプリケーション・プロファイルがインターネット・アイデンティティ・サービスに存在している必要があります。モバイル・アプリケーションにインターネット・アイデンティティ・サービスを使用する必要がある場合、そのアプリケーションのプロファイルが、インターネット・アイデンティティ・サービスとモバイル・サービスにプロファイルに存在している必要があります。

1. 「インターネット・アイデンティティ・サービス」の下で、アプリケーション・プロファイルの作成ウィザードを開きます。

2. 保護するモバイル・アプリケーションに該当する値を、アプリケーション・プロファイルの属性に入力して、「次へ」をクリックします。
属性の定義は、第39.5.1項「アプリケーション・プロファイルの作成」を参照してください。

3. サービス・プロバイダ・インターフェイスを選択して、「次へ」をクリックします。
第39.4項「サービス・プロバイダ・インターフェイスの定義」を参照してください。

4. インターネット・アイデンティティ・プロバイダを選択して、「次へ」をクリックします。
第39.2項「インターネット・アイデンティティ・サービスの構成の理解」を参照してください。

5. 「アプリケーション・プロファイル」の概要を確認してから、「終了」をクリックしてアプリケーション・プロファイルを作成します。

6. 「モバイル・サービス」の下で、「サービス・ドメインの作成」ウィザードを開きます。
既存のサービス・ドメインを変更する場合は、それを開いて編集します。詳細は、第38.4項「サービス・プロファイルの定義」を参照してください。

7. フォームに次のように入力します。

- 「タイプ」については、「モバイル・アプリケーション」を選択します。

- 「認証スキーム」については、「インターネット・アイデンティティ認証」を選択します。

詳細は、第38.7項「サービス・ドメインの定義」を参照してください。

8. 「アプリケーション・プロファイル選択」セクションで、保護するモバイル・アプリケーションを示すモバイル・サービスのアプリケーション・プロファイルを追加し、モバイルSSOに、エージェントとして参加するのか、クライアントとして参加するのか、それとも参加しないのかを選択します。
既存のプロファイルを参照するか、名前を入力して、該当するアプリケーション・プロファイルを選択します。アプリケーション・プロファイルは、先に作成しておく必要があります。(モバイル・サービスのアプリケーション・プロファイルを作成する場合は、第38.6項「アプリケーション・プロファイルの定義」を参照してください。インターネット・アイデンティティ・サービスのアプリケーション・プロファイルを作成する場合は、第39.5項「アプリケーション・プロファイルの定義」を参照してください。)

9. 「次へ」をクリックして、サービス・プロファイルを選択(または作成)します。
第38.4項「サービス・プロファイルの定義」を参照してください。

10. 「次へ」をクリックして、サービス保護を選択します。
たとえば、ユーザー・プロファイル・サービスを保護する場合は、認証サービスとしてInternetIdentityAuthenticationを使用します。

11. 「次へ」をクリックして、「サービス・ドメインの作成」の概要を確認します。

12. 「終了」をクリックして、サービス・ドメインを作成します。

注意:

詳細は、Oracle Access Management開発者ガイドの「インターネット・アイデンティティ・サービス・クライアントSDKを使用したアプリケーションの開発」のインターネット・アイデンティティ・サービスとモバイル・アプリケーションとの統合に関する項を参照してください。

40 Mobile and Socialシステム設定の構成

この章では、Oracle Access Management Mobile and Socialシステムの構成タスクについて説明します。この章には次の項目があります。

- Mobile and Social設定インタフェースへのアクセス

- ロギングおよび監査

- Oracle Access Managerを使用するMobile and Socialのデプロイ

- テストから本番に移行するスクリプトを実行した後のMobile and Socialの構成

40.1 Mobile and Social設定インタフェースへのアクセス

Oracle Access Managementコンソールの「Mobile and Social設定」ページを使用して、システム・レベルの設定を構成します。

注意:

Mobile and Socialの多くの構成タスク、WebLogic Scripting Tool (WLST)を使用してコマンドラインから実行できます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

次の手順を実行して、「Mobile and Social設定」ページにアクセスします。

1. Oracle Access Managementコンソールにログインします。

2. ページの上部にある「システム構成」タブをクリックします。

3. ページの左側にある「Mobile and Social」をクリックします。

4. 「Mobile and Social設定」をクリックします。
メインフレームに「Mobile and Social設定」タブが開きます。Mobile and Socialサーバーとアイデンティティ・プロバイダの間にプロキシが配置されている場合は、次のアイデンティティ・プロバイダ・サービスの設定を構成します。

- プロキシURL: プロキシ・サーバーへの接続に使用するプロトコル(HTTPまたはHTTPS)を選択し、プロキシ・サーバーのホスト名およぴポート番号を入力します。

- プロキシ認証: プロキシ・サーバーで認証を受けるために必要なユーザー名およびパスワードを入力します。

- SAEトークン有効期間: Secured Attribute Exchangeトークンを期限切れにするまで待機する秒数を入力します。SAEは、Mobile and Socialサーバーと、インターネット・アイデンティティ・サービスと直接統合されているアプリケーションとの間の通信を保護するために使用されるデフォルト・スキームです。

40.2 ロギングおよび監査

Fusion Middlewareロギングの詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの監視」の章を参照してください。

Fusion Middlewareの監査の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。

40.3 Oracle Access Managerを使用するMobile and Socialのデプロイ

Mobile and Socialは、Oracle Access Manager 10gまたは11gR1 PS1と併用するように構成できます。ただし、これが機能するには、Oracle Access ManagerとMobile and Socialを、別々のドメインの別のサーバーにインストールする必要があります。その後、Mobile and SocialとOracle Access Managerを連携動作するように構成する必要があります。次の手順では、Oracle Access Manager 11gR1 PS1を使用して、これを実現する方法について説明します。開始する前に: Mobile and SocialをHost 1にインストールし、Oracle Access Manager 11gR1 PS1をHost 2にインストールします。

1. Host 2のOracle Access Managementコンソールにログオンし、デフォルト値を使用して、Mobile and Social用のWebゲートを作成します。

2. Mobile and Socialで、Oracle Access Manager 11.1.1.5用の認証サービス・プロバイダを作成します。
手順については、第38.3.1.1項「認証サービス・プロバイダの作成」を参照してください。

次の表に示すように、属性を設定します。

表40-1 Oracle Access Manager 11gR1 PS1認証サービス・プロバイダ用の属性の設定

名前

値

OAM_VERSION

OAM_10G

DEBUG_VALUE

0

TRANSPORT_SECURITY

OPEN

OAM_SERVER_1

ホスト:ポート

OAM_SERVER_1_MAX_CONN

4

OAM_SERVER_2

ホスト:ポート

OAM_SERVER_2_MAX_CONN

4

AuthNURL

wl_authen://Authen/Basic

3. Mobile and Socialで、前の手順で作成した認証サービス・プロバイダ用のサービス・プロファイルを作成します。
手順については、第38.4項「サービス・プロファイルの定義」を参照してください。

4. Mobile and Socialで、サービス・ドメインを作成します。
手順については、第38.7.1項「サービス・ドメインの作成」を参照してください。

5. Host 2のcwallet.ssoファイルを、Host 1のcwallet.ssoファイルにマージします。

1. Host 2からHost 1に、cwallet.ssoをコピーします。

2. Host 1で、次を入力します。

# mkdir /tmp/oam  /tmp/oic# cp <host>/cwallet.sso /tmp/oam    # cp config/fmwconfig/cwallet.sso /tmp/oic

3. ファイルmerge-creds.xmlを作成します。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
schema-major-version="11" schema-minor-version="1">
<serviceProviders>
<serviceProvider
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider"
name="credstoressp" type="CREDENTIAL_STORE">
<description>File-based credential provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>
<!-- Source file-based credential store instance -->
<serviceInstance location="/tmp/oam" provider="credstoressp"
name="credential.file.source">
</serviceInstance>
<!-- Destination file-based credential store instance -->
<serviceInstance location="/tmp/oic" provider="credstoressp"
name="credential.file.destination">
</serviceInstance>
</serviceInstances>
<jpsContexts>
<jpsContext name="FileSourceContext">
<serviceInstanceRef ref="credential.file.source"/>
</jpsContext>
<jpsContext name="FileDestinationContext">
<serviceInstanceRef ref="credential.file.destination"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

4. PATH変数を設定して、$MW_HOME/oracle_common/bin:$MW_HOME/oracle_common/common/binを含めます。

5. 次のコマンドを実行して、cwallet.ssoファイルをマージします。

# wlst.shwlst:/> migrateSecurityStore(type="credStore", configFile="/tmp/mergecreds.xml",src="FileSourceContext",dst="FileDestinationContext")

6. マージしたファイルを、config/fmwconfigにコピーします。

# cp /tmp/oic/cwallet.sso /scratch/kerwin/wls10/user_projects/domain/base_domain/cfnfig/fmwconfig

7. Host 1で、OAMサーバーを再起動します。

40.4 テストから本番に移行するスクリプトを実行した後のMobile and Socialの構成

Mobile and Socialをテスト環境から本番環境に移行するとき、テストから本番に移行するスクリプトを実行した後に各本番マシンで次の構成ステップを実行します。

1. Oracle Access Managementコンソールを起動します。

2. 「ポリシー構成」タブで、「共有コンポーネント」、「認証スキーム」、OICスキームの順に選択してから、「開く」をクリックします。
「認証スキーム」構成ページが開きます。

3. 本番マシン(テスト・マシンではありません)を指すように「チャレンジ・リダイレクトURL」値を更新して、「適用」をクリックします。
例: https://production_machine:port/oic_rp/login.jsp

4. 次のWLSTコマンドを実行して、テスト・マシンから本番マシンを指すようにMobile and Social資格証明ストア・フレームワーク(CSF)エントリを更新します。

createCred(map="OIC_MAP", key=" https://<production machine host>:<production machine port>/oam/server/dap/cred_submit ", user="="<description>", password=" DCC5332B4069BAB4E016C390432627ED", desc="<description>");

passwordには、oam-config.xml内のTapCipherKey属性のRPPartnerエントリの値を使用します。このファイルは、本番マシンのdomain home/config/fmwconfigディレクトリにあります。

5. Oracle Access Managementコンソールで、次の手順を実行します。

1. 「システム構成」タブを選択します。

2. 「Mobile and Social」→「インターネット・アイデンティティ・サービス」の順に選択します。

3. 「アプリケーション・プロファイル」セクションで、OAMApplicatonを選択し、「編集」をクリックします。(OAMApplication以外のアプリケーション・プロファイル名を使用している場合、かわりにそれを編集します。)

4. 本番マシンを指すように、「登録URL」フィールドのホスト名およびポートを更新します。
「適用」をクリックします。

第X部

アイデンティティ・コンテキストの使用方法

この部では、Oracle Identity Contextの概要について説明します。

第X部の内容は次のとおりです。

- 第41章「アイデンティティ・コンテキストの使用」

41 アイデンティティ・コンテキストの使用方法

アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を活用することで、増大するセキュリティの脅威に対応できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。次の項では、アイデンティティ・コンテキストの詳細とその使用方法について説明します。

- アイデンティティ・コンテキストの概要

- アイデンティティ・コンテキストの理解

- アイデンティティ・コンテキスト・サービスの操作

- アイデンティティ・コンテキストAPIの使用方法

- アイデンティティ・コンテキスト・サービス・コンポーネントの構成

- アイデンティティ・コンテキストの検証

41.1 アイデンティティ・コンテキストの概要

エンタープライズ・アプリケーション・インフラストラクチャがサポートするビジネス・アプリケーションをWeb対応にするために、それらのインフラストラクチャには過去10年間にわたって変更が行われてきました。これらの変更によって、様々なタイプのデバイスを使用した、より多くのユーザーによるアクセスが可能になっています。ユーザー数の増加に伴う追加のリスクに対応するために、アクセス管理に使用される基盤となるセキュリティ・モデルは、サイロベースの実装から、より動的なものへと進化し、アイデンティティおよびリスク・データがアプリケーション配信プロセス全体のコンポーネントにわたって共有されるようになりました。この動的な実装は、Webシングル・サインオン(SSO)、きめ細かな認可、Web Services Security、Identity Federationなどを提供することでセキュリティ制御を特定のランタイム・デプロイメント環境(Webサーバーまたはアプリケーション・サーバー・コンテナ)内に集約し、ポリシーベースのセキュリティ制御を提供することでアプリケーション・リソースへのアクセスを管理するシステムに依存します。さらに、アイデンティティおよびリスク・データによって、アクセスを要求しているユーザーのコンテキストが提供されます。

アプリケーション・セキュリティ制御は、最初は、特定のエンタープライズ・アプリケーション・デプロイメント・パラダイム(たとえば、すべてのWebサーバー・アプリケーション、すべてのWebサービス・アプリケーション、またはすべてのアプリケーション・サーバー・アプリケーション)内のサイロの統合に焦点が当てられていましたが、今日では内外のセキュリティの脅威のプレゼンスの増加により、増大するリスクを適切に管理するために異なるセキュリティ・モデルの統合が必要とされています。

この要件は、クラウドおよびモバイル・コンピューティング・パラダイムの出現によりさらに拡大されました。そこでは、アプリケーションは、もはやセキュアなエンタープライズの保護された範囲内で整然と実行されるコンポーネントで構成されているものではなくなりました。

アプリケーションがクラウド・サービスを活用するには、独自の方法でサイロ化されているそれらのサービスから生じるリスクの増大を解決する必要がありました。クラウド・デプロイメントおよびモバイル配信チャネルに対する脅威の数は着実に増加しており、エンドツーエンド・アプリケーション配信プロセスに、広範な脅威への対処に不可欠なポリシー制御を実装することが必要となっています。これらのポリシー制御では、どのセキュリティの決定を行う必要があるのかを踏まえて、要求側のユーザーに関する情報にアクセスすることが必要です。したがって、セキュリティ・ポリシー管理インフラストラクチャはコンテキストを意識したものにして、管理者が、保護されているアプリケーション環境へのアクセスを要求するユーザーに対して適用するセキュリティのレベルを制御するポリシーを作成できるようにする必要があります。

以前は、アイデンティティ・コンテキストは、1つ以上のアイデンティティ・ストア(LDAPディレクトリやSQLデータベースなど)のアイデンティティ・レコードのプレゼンスによって定義されていました。アイデンティティ・レコードには、プロファイル属性、そのユーザーがメンバーになっているグループ、およびエンタープライズ・ロールが含まれます。しかし、Web、クラウド、およびモバイル・アプリケーションの配信チャネルの範囲は絶え間なく拡大しているため、アイデンティティに関してさらに動的な情報を意識した認可ポリシー制御が必要です。この情報は、保護されているリソースへのアクセスを試みるアイデンティティと関連付けられており、次の一部またはすべてを含む場合があります。

- プレゼンス(場所、履歴パターン)

- 認証強度(弱、強)

- アシュアランスのレベル(NISTレベル、X509証明書)

- リスク評価(パターン分析)

- フェデレーション(パターン属性)

- デバイス特性(フィンガープリント、デバイスの状態、デバイスの保護、トラステッド・データ)

- トラステッド・パートナからのアサーション(SAMLトークンなど)

- シングル・サインオン・セッション(セッション・タイムアウト)

次の例は、アイデンティティ・コンテキスト・データがアプリケーションによってどのように使用される可能性があるのかを示しています。アプリケーションは、次のように動作する場合があります。

- ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。

- 組織が(Identity Federationを介して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。

- 不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。

- 管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。

- 不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。

アイデンティティ・コンテキストの概念をアクセス管理に組み込むことで、制御は、アイデンティティ・プロファイルに含まれているとは限らない動的データ(アイデンティティ・コンテキスト属性と呼ばれる)を使用して決定できるようになりました。つまり、アイデンティティ・コンテキストは、特定の保護されているリソースにアクセスするユーザーの要求を取り巻く環境および状況と考えられます。それは、アクティビティの範囲、地理的な領域、通信プラットフォーム、アプリケーション、あるいは論理または物理ドメインである場合があります。

41.2 アイデンティティ・コンテキストの理解

このリリースでは、Access Managerは、Oracle Access Managementプラットフォームの組込みサービスとしてアイデンティティ・コンテキストを組み込むことで、コンテキストを意識したアクセス管理を可能にします。図41-1は、複数のシステム・コンポーネントによって実装されているアイデンティティ・コンテキスト・プロセスのフローを示しています。各アプリケーション配信コンポーネントには、アプリケーションのその個別のスライスの保護を担うそれ自体のセキュリティ・ポリシー・インフラストラクチャがあります。この特定のユース・ケースには、エンド・ユーザー・デバイス、静的GUIページを実行するWebサーバー、動的コンテンツをレンダリングするポータル・サーバーを実行するアプリケーション・サーバー、Webサービス・エンドポイントを公開するサービス・バス・サーバー、トランザクション・データを格納するデータベース・サーバー、およびアイデンティティ・プロファイル・データを格納するLDAPサーバーが含まれています。

図41-1 エンドツーエンド・アイデンティティ・コンテキスト・プロセス

「図41-1 エンドツーエンド・アイデンティティ・コンテキスト・プロセス」の説明

プロセスの各コンポーネントには、保護されているリソースへのアクセスを制御する認可ポリシーが管理者によって定義され、実行時に適用されるそれ自体のセキュリティ・インフラストラクチャがあります。さらに、それらのコンポーネントのいくつかまたはすべてで、ポリシー管理をOracle Entitlements Serverなどの外部認可サーバーに外在させる場合もあります。アプリケーションがOracle Platform Security Servicesを活用して構築されている場合がこれに該当します。図41-2は、構成しているOracleアプリケーションに基づいたアイデンティティ・コンテキストの機能アーキテクチャを示しています。

図41-2 エンドツーエンド・アイデンティティ・コンテキスト・プロセスのコンポーネント

「図41-2 エンドツーエンド・アイデンティティ・コンテキスト・プロセスのコンポーネント」の説明

図から明らかなように、コンテキストを意識したセキュリティ・ポリシー管理は、Oracle Access Managementプラットフォームを活用することで実現されます。このプラットフォームには、エンドユーザーのアプリケーションを変更することなくアイデンティティ・コンテキスト属性(リスク・スコア、トラステッド・デバイス・データ、認証データなど)を操作および適用するためのネイティブ・サポートが含まれています。

41.3 アイデンティティ・コンテキスト・サービスの操作

Oracle Access Managementプラットフォームにより、アイデンティティ・コンテキスト・データを収集し、関与するコンポーネントに伝播し(図41-2に定義)、保護されているリソースへのアクセス権限を付与または拒否するために使用可能にできます。アイデンティティ・コンテキスト・サービスにより、アイデンティティ・コンテキストAPIを介したアイデンティティ・コンテキスト・ランタイムへのアクセスが可能になります。アイデンティティ・コンテキスト・ディクショナリ・スキーマによって、アイデンティティ・コンテキスト属性が指定されます。次の項では、これらのコンポーネントについて詳しく説明します。

- アイデンティティ・コンテキストの使用方法

- アイデンティティ・コンテキスト・ランタイムの理解

41.3.1 アイデンティティ・コンテキスト・ディクショナリの使用方法

アイデンティティ・コンテキスト・アーキテクチャの中心となるのは、アイデンティティ・コンテキスト・ディクショナリです。このディクショナリは、Oracle Access Managementプラットフォームで定義されているアイデンティティ・コンテキスト属性を指定することでアイデンティティ・コンテキスト・スキーマを定義します。そのスキーマでは、namespace : attributeと等しい一意の名前で各属性が記述されます。表41-1は、それらのスキーマ属性を示しています。

注意:

仮想属性(表41-1に記載)は、特定の属性の作成元となるアイデンティティ情報の抽象クラスを表します。仮想属性を公開する場合、アイデンティティ・コンテキストAPIは、属性値にattr-name=attr-valueが含まれていることを想定します。実際の属性は、名前namespace : attribute : attr-nameとattr-valueの値を使用して作成されます。この方法により、Oracle Access Managementコンポーネントによって直接管理されていないソースからの値を持つ属性の公開が可能になります。

表41-1 アイデンティティ・コンテキスト・スキーマ属性

ネームスペース

属性

タイプ

仮想

プライマリ・パブリッシャ

説明

oracle:idm:claims:nameid

value

文字列

不可

OAM

一意のユーザー識別子を示します。Access Managerは現在ユーザーDNを公開しています

oracle:idm:claims:nameid

format

文字列

不可

OAM

ユーザー識別子のタイプを示します。Access Managerは現在urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectNameを公開しています

oracle:idm:claims:nameid

qualifier

文字列

不可

OAM

ユーザーが属する論理アイデンティティ・ドメインを示します。Access Managerは、現在、UserIdentityStore1などのアイデンティティ・ストアの論理名を公開しています。

oracle:idm:claims:nameid

spprovidedid

文字列

不可

OAM

SP自体のアイデンティティ・ストアでユーザーを見つけるためにすべてのSPで使用できる一意の識別子を示します。Access Managerは、現在、登録済アイデンティティ・ストアで構成されている一意のID属性の値を公開しています。

oracle:idm:claims:client

firewallenabled

ブール

不可

OESSO

クライアント・デバイスでファイアウォールが有効化されていることを示します。

oracle:idm:claims:client

antivirusenabled

ブール

不可

OESSO

クライアント・デバイスでウイルス対策が有効化されていることを示します。

oracle:idm:claims:client

fingerprint

文字列

不可

OESSO、Oracle Access Management Mobile and Social (OMS)

クライアント・デバイスのフィンガープリントを示します。

oracle:idm:claims:client

ostype

文字列

不可

OMS

クライアント・デバイスのオペレーティング・システム・システム・タイプを示します。

oracle:idm:claims:client

osversion

文字列

不可

OMS

クライアント・デバイスのオペレーティング・システム・バージョンを示します。

oracle:idm:claims:client

jailbroken

ブール

不可

OMS

クライアント・デバイスがジェイルブレーク(iOS)またはルート化(Android)されているかどうかを示します。

oracle:idm:claims:client

macaddress

文字列

不可

OMS

クライアント・デバイスのイーサネット(MAC)アドレスを示します。

oracle:idm:claims:client

ipaddress

文字列

不可

OMS

クライアント・デバイスのクライアントIPアドレスを示します。

oracle:idm:claims:client

vpnenabled

ブール

不可

OMS

クライアントのデバイスでVPNが有効化されているかどうかを示します。

oracle:idm:claims:client

geolocation

文字列

不可

OMS

クライアント・デバイスの場所の地理的座標を緯度,経度の形式で示します。

oracle:idm:claims:risk

newdevice

ブール

不可

OAAM

クライアント・デバイスが既知であるかどうかを示します。既知でないデバイスからログインされている場合はtrue、それ以外の場合はfalseです。

oracle:idm:claims:risk

level

整数

不可

OAAM

リスク・レベルを示します。レベルはログインの失敗後に増加します。

oracle:idm:claims:risk

safeforuser

ブール

不可

OAAM

ユーザーが2番目のチャレンジ質問に回答したかどうかを示します。ユーザーがそれに適切に回答した後はtrue、それ以外の場合はfalseです。

oracle:idm:claims:risk

fingerprint

文字列

不可

OAAM

OAAMによって測定されるデバイス・フィンガープリントを示します。デバイスごとに、残されるフィンガープリントが異なります。デバイス(Flashを介して取得)のフィンガープリントとブラウザ(httpのみ)のフィンガープリントの間で切り替えることができます。

oracle:idm:claims:session

authnlevel

整数

不可

OAM

Access Managerの認証レベルを示します

oracle:idm:claims:session

usercount

整数

不可

OAM

ユーザーによって保持されるセッション数を示します

oracle:idm:claims:session

appdomain

文字列

不可

OAM

ポリシーが含まれているAccess Managerアプリケーション・ドメインの名前を示します。

oracle:idm:claims:session

apppolicy

文字列

不可

OAM

アクセスを許可したAccess Managerポリシーの名前を示します

oracle:idm:claims:session

appagent

文字列

不可

OAM

Access Managerにリクエストを送信したエージェントの名前を示します

oracle:idm:claims:session

appclientip

文字列

不可

OAM

Access Managerにリクエストを送信したクライアントのIPアドレスを示します

oracle:idm:claims:session

sessionid

文字列

不可

OAM

Access ManagerセッションIDを示します

oracle:idm:claims:session

attributes

文字列

可

OAM

セッション・ストアから取得されるセッション属性を示します。たとえば、Access Managerで、要求名としてoracle:idm:claims:session:attributesを選択し、attr-name=$session.attr.nameという表記法を使用してセッション属性を指定します(nameは、そのセッションに格納される属性の名前)。要求は、oracle:idm:claims:session:attributes:attr-nameの名前と、セッションのname属性に等しい値で作成されます。

oracle:idm:claims:fed

partner

文字列

不可

OAMまたはIF

Identity Federationによって判別されるパートナIDを示します

oracle:idm:claims:fed

nameidvalue

文字列

不可

OAMまたはIF

Identity Federationによって判別されるフェデレーション・パートナのユーザーIDを示します

oracle:idm:claims:fed

nameidformat

文字列

不可

OAMまたはIF

Identity Federationによって判別されるフェデレーション・パートナのユーザーIDの形式を示します

oracle:idm:claims:fed

attributes

文字列

可

OAM

パートナによって提供され、Identity Federationによって判別されるフェデレーション属性を示します。たとえば、Access Managerで、要求名としてoracle:idm:claims:fed:attributesを選択し、attr-name=$session.attr.fed.attr.nameという表記法を使用してフェデレーション属性を指定します(nameは、パートナのSAMLアサーションでのSAML属性の名前)。要求は、oracle:idm:claims:fed:attributes:attr-nameの名前と、SAMLのname属性で提供されるパートナのアサーションに等しい値で作成されます。

oracle:idm:claims:ids

attributes

文字列

可

OAM

たとえば、Access Managerで、要求名としてoracle:idm:claims:ids:attributesを選択し、attr-name=$user.attr.nameという表記法を使用してIDストア属性を指定します(nameは、ユーザー・プロファイル上のその属性の名前)。要求は、oracle:idm:claims:ids:attributes:attr-nameの名前と、ユーザー・プロファイルのname属性に等しい値で作成されます。

oracle:idm:claims:tenant

tenantid

文字列

不可

OAM

現在、今後の使用のために予約済です。(テナントIDを示します。)

oracle:idm:claims:tenant

attributes

文字列

可

OAM

現在、今後の使用のために予約済です。(パブリッシャによって提供されるテナント属性を示します。この要求値は、attr-name=attr-valueを含むことになります。要求は、oracle.idm:claims:tenant:attr-nameの名前と、attr-valueの値で作成されます。)

41.3.2 アイデンティティ・コンテキスト・ランタイムの理解

アイデンティティ・コンテキスト・ランタイムは、アイデンティティ・コンテキスト属性(アイデンティティ・コンテキスト・ディクショナリで定義される)のコレクションを参照します。それは、その属性に対して権限を持つと認識されている様々なトラステッド・アプリケーション・コンポーネントまたはセキュリティ・フレームワーク、あるいその両方によってアサートされます。これが、Oracle Access Managementプラットフォームです。ランタイム・コンテキストは、現在の状況、環境、背景、または設定を表し、それらによってランタイム・アプリケーション環境でのアイデンティティに対するイベントの意味が判別、指定、または明確化されます。

Oracle Access Managementプラットフォームでは、Context Management Engine (CME)と呼ばれる共通インフラストラクチャ・コンポーネントが活用されます。CMEにより、Oracle Access Managementプラットフォームを介して処理されるすべてのトランザクションに対してアイデンティティ・コンテキストが生成されることが保証されます。CMEによって収集されるコンテキスト・データは、WebチャネルまたはWebサービス・チャネルおよびOracle Access Managementプラットフォームで使用可能なソフトウェア製品の多くを使用してユーザーが実行するトランザクションに適用されます。バックエンドで開始されるいくつかのトランザクションにも、アイデンティティ・コンテキストへのアクセスが必要な場合があり、アイデンティティ・コンテキストがある程度の期間、永続化されることが必要な場合があります。

一般的なOracleミドルウェア・デプロイメントでは、アイデンティティ・コンテキスト・ランタイムは主にOracle Access Managementプラットフォームによって、保護されているアプリケーションのかわりにポリシーベースの決定を実行するために利用されます。ただし、コンテナ内で実行されているどのアプリケーションも、アイデンティティ・コンテキストAPIを活用することでアイデンティティ・コンテキスト・ランタイムを直接統合および使用することが可能です。使用可能なアイデンティティ・コンテキスト・データの量は、デプロイされている製品に応じて異なります。そのままで使用できるデフォルトのセットのアイデンティティ属性が用意されます。これらは主にAccess ManagerでIDアサーションを活用することで構成されます。表41-1「アイデンティティ・コンテキスト・スキーマ属性」は、これらのデフォルト属性を示しています。次のリストは、アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフローの詳細を示しています。そのリストの下の図41-3は、フローを示しています。

プロセスの概要: アイデンティティ・コンテキスト・ランタイムのエンドツーエンドのフロー

1. ユーザーが、保護されているアプリケーションにデバイスからアクセスします。

2. Access Managerによって、アイデンティティがアサートされ、コンポーネントを公開する関連Access Managementからアイデンティティ属性が収集され、アイデンティティ・コンテキストが作成されます。

3. Access Managerによって、IDアサーション(SAMLセッション・トークン)が生成され、アイデンティティ・コンテキスト属性が組み込まれます。Access Manager Identity Asserterによって、IDアサーションが処理され、OPSS属性サービスを使用してWebLogic Serverコンテナにアイデンティティ・コンテキストが公開されます。

4. 保護されているアプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。OESによってアイデンティティ・コンテキストがローカルOES PDPに自動的に伝播されます。

5. OESによって、適切な認可ポリシーが検索され、その条件が(アイデンティティ・コンテキスト属性に基づいて)評価されます。評価は、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して実行できます。

6. 保護されているアプリケーションによって、JRF Webサービス呼出しが行われ、その中でOracle Web Service Manager (OWSM)クライアントによってSAMLトークンが使用され、アイデンティティ・コンテキストがWebサービス・アプリケーション環境に伝播されます。

7. OWSM (Webサービス側)によってそのアイデンティティ・コンテキストでSAMLアサーションが処理され、OPSS属性サービスを使用することによってそのアイデンティティ・コンテキストがWebLogic Serverコンテナに公開されます。

8. Webサービス・アプリケーションによってOES PEP APIが呼び出され、認可の決定が行われます。

9. OESによってアイデンティティ・コンテキストがリモートOES PDPに自動的に伝播され、そこでアイデンティティ・コンテキスト属性に基づいた条件が、組込みのアイデンティティ・コンテキスト関数またはカスタム関数を使用して評価されます。

図41-3 アイデンティティ・コンテキストのプロセス・フロー

CMEによって、アイデンティティ・コンテキストがアプリケーション層および基盤となるアプリケーション・サーバー・コンテナに伝播されると、そのアイデンティティ・コンテキストはコンテナおよびその中で実行されているアプリケーションから使用できるようになります。表41-2は、アイデンティティ・コンテキストを使用して動作する場合に、どのアクセス管理プラットフォーム製品によって何が実行されるのかを示しています。

表41-2 アイデンティティ・コンテキスト操作のマッピング

ロールおよびコンテキスト操作

説明

コンポーネント

パブリッシャ - アイデンティティ・コンテキストの公開

アプリケーション・コンポーネントを保護するトラステッド・セキュリティ・フレームワークは、アイデンティティまたはアイデンティティのアクセス要求、あるいはその両方に関する適切なファクトを、別のトラステッド・セキュリティ・フレームワークから取得するか、それが使用できる情報から導出します。

権限を持つコンポーネントによって収集される情報は、コンポーネントのランタイム・フレームワークで使用できる環境コンテキストに基づいています。たとえば、Access Managerによって、ユーザーの認証強度のレベルが判別され、OAAMによって特定のオンライン・セッションに関連付けられているリスク・スコアが計算され、OESSOによってクライアント・デバイスでファイアウォールが有効化されているかどうかが判別されます。

- OAM – セッション、フェデレーション、およびアイデンティティ・スコア属性

- OAAM – リスク属性

- OESSO – デバイス属性

- OMS Mobile SDK - デバイス属性

プロパゲータ - アイデンティティ・コンテキストを伝播する

トラステッド・セキュリティ・フレームワークによってアイデンティティ・コンテキスト属性が伝播され、別のアプリケーション・セキュリティ・フレームワークによって使用されるかアプリケーションによって直接使用されます。たとえば、OAAMによって、ユーザーのリスク・スコアがそのユーザーのAccess Managerセッションに伝播され、Access Managerによって、認証済ユーザーの一意のIDおよび認証レベルとともにIDアサーション(SAMLトークン)が伝播され、OWSMクライアントによって現在のアイデンティティ・コンテキストが、Webサービスに伝播され、そこで、OWSMエージェントによってWebサービス・アプリケーションでアイデンティティ・コンテキストが再構築されます。

- OAMはWeb層とコンテナ層の間にあります

- OWSMはWebサービス・クライアント層とWebサービス層の間にあります

- OPSSはAccess Manager Identity AsserterまたはOWSMエージェントとWebLogic Serverコンテナの間にあります

- OMSはOMS Mobile SDKとAccess Managerの間にあります

評価者 - アイデンティティ・コンテキストを評価する

アイデンティティ・コンテキスト属性を使用するトラステッド・セキュリティ・フレームワークまたはエンドユーザー・アプリケーションです。ポリシー決定を実行するか、アプリケーションのビジネス・ロジックをパーソナライズします。たとえば、OAAMが存在し、リスク・スコアを計算するように構成されている場合、OES内のアプリケーションの認可ポリシーによって、そのリスク・スコアが特定のしきい値未満のときにのみアクセスが許可されます。また、Access ManagerでIdentity Federationが構成されている場合、そのアプリケーションによって、パートナが提供するアサーション(アイデンティティ・コンテキストで入手可能)が使用され、OESを使用してトランザクションへのアクセスが認可されます。

- OAM – Web境界ポリシー

- OWSM – Webサービス・ポリシー

- OES – アイデンティティ・コンテキストが存在するコンテナから行われたすべてのPEP API呼び出しに対するアプリケーション固有またはWLS固有ポリシーこれには、すべてのADFアプリケーション、IAMアプリケーション、カスタム・アプリケーションなどが含まれます。

41.4 アイデンティティ・コンテキストAPIの使用方法

アイデンティティ・コンテキストAPIは、アイデンティティ・コンテキスト・ディクショナリおよびアイデンティティ・コンテキスト・ランタイムと連動するように設計されたJavaクラスのセットです。このAPIは、Oracle Java Required Files (JRF)の一部であるIdentityContext.jarとして配布されます。例41-1は、アイデンティティ・コンテキスト・ディクショナリと連動するアプリケーションを示しています。

例41-1 アイデンティティ・コンテキスト・ディクショナリとの連動

// Display Identity Context Dictionary
try {
ClaimDictionary idCtxDict = new ClaimDictionary();
System.out.println
("IDC Dictionary :" + idCtxDict.getClaimCount() + "attributes");
Iterator<String> iterNamespace = idCtxDict.getAllNamespaces();
while (iterNamespace != null && iterNamespace.hasNext()) {
String namespace = iterNamespace.next();
System.out.println("Namespace : " + namespace);
Iterator<ClaimSchema>
iterClaimSchema=idCtxDict.getClaimsForNamespace(namespace);
while (iterClaimSchema != null && iterClaimSchema.hasNext()) {
out.println(iterClaimSchema.next().getUniqueName());
}
}
} catch (Exception e) {
System.out.println("Unable to acquire IDC Dictionary. " + toString());
}

アプリケーションは、アイデンティティ・コンテキスト・ランタイムと連動し、アプリケーション・インフラストラクチャに現在存在しているアイデンティティ・コンテキストのランタイム状態を取得します。保護されたアプリケーションがアイデンティティ・コンテキスト・ランタイムと連動するには、Oracle Fusion Middleware PS5(PS5用のOPSS Opatchを適用)またはOracle Fusion Middleware PS6以降で作成されたWebLogic Serverドメインに、そのアプリケーションをデプロイする必要があります。

さらに、アイデンティティ・コンテキスト・ランタイムとの連動は権限付き操作であり、WebLogic Server(必要なアイデンティティ・コンテキスト・サポートがある)で実行されているアプリケーションに適切なソース・コード・グラントがあることを必要とします。WebLogic Serverコンテナ内で実行されている、権限のあるアプリケーションは、OPSS属性サービスに要求することでアイデンティティ・コンテキスト・ランタイムにアクセスできます。例41-2は、WLSTを使用してOPSS属性サービスにアプリケーション(この場合はssofilter.jar)へのアクセス権を付与する方法を示しています。

例41-2 属性サービスにアプリケーションへのアクセス権を付与するためのWLSTの使用方法

# sh ../oracle_common/common/bin/wlst.sh
connect ('<username>', '<password>','t3://localhost:7001')
grantPermission(codeBaseURL="file:${common.components.home}/
modules/oracle.ssofilter_11.1.1/ssofilter.jar", permClass="oracle.security.jps.service.attribute.AttributeAccessPermission",
permTarget="*", permActions="get, set, remove")
exit()

例41-3は、アイデンティティ・コンテキスト・ランタイムと連動するアプリケーションを示しています。

例41-3 アイデンティティ・コンテキスト・ランタイムとの連動

import java.security.AccessController;
import java.security.PrivilegedAction;
import oracle.security.jps.internal.api.runtime.AppSecurityContext;
import oracle.security.idm.IdentityContext;

…

// get runtime ID Context from OPSS
private static Object getIDContext() {
Object idc = AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {return AppSecurityContext.getSecurityContext().getAttribute
(oracle.security.idm.IdentityContext.Constants.IDC_API_ID); }});
return idc;
}

…

// Display runtime ID Context
try {
Context idCtx = (Context)getIDContext();
if (idCtx != null) {
System.out.println("IDC Runtime :" + idCtx.getSize() + "attributes");
Iterator<Claim> i = idCtx.getClaims();
while (i != null && i.hasNext()) {
Claim c = i.next();
System.out.println(c.getName() + " : " + c.getValue());
}
} else {
System.out.println("Identity Context Runtime is not available");
}
} catch (Exception e) {
System.out.println("Unable to acquire Identity Context Runtime. " + e.toString());
}

…

// Obtain few attributes from Identity Context Runtime
Attr authnLevel = ctx.getAttr (Constants.ATTR_SESSION_AUTHN_LEVEL);
Attr isFirewallEnabled = ctx.getAttr(Constants.ATTR_CLIENT_FIREWALL_ENABLED);
Attr isTrustedDevice = ctx.getAttr(Constants.ATTR_RISK_TRUSTED_DEVICE);

// Use user's authentication strength established at login by OAM
int authLevel = new Integer(authnLevel.getValue()).intValue();
if (authLevel < 20) {
// do something
}

詳細は、Oracle Fusion Middleware Oracle Platform Security Services Java APIリファレンスに記載されています。

41.5 アイデンティティ・コンテキスト・サービス・コンポーネントの構成

アイデンティティ・コンテキストのサポートは、表41-2「アイデンティティ・コンテキスト操作のマッピング」にリストされている各関係Oracle Access Managementコンポーネントに事前に統合されています。このため、ビジネス要件に対応するように各コンポーネントを構成する必要があります。

次の項では、必要なアイデンティティ・コンテキスト構成の高度な概要を示します。ただし、詳細は、それぞれの製品に付属のドキュメントを参照してください。

- Oracle Fusion Middlewareの構成

- Access Managerの構成

- Oracle Adaptive Access Managerの構成

- Webサービス・セキュリティ・マネージャの構成

- Oracle Entitlements Serverの構成

- Oracle Enterprise Single Sign Onの構成

- Oracle Access Management Mobile and Socialの構成

41.5.1 Oracle Fusion Middlewareの構成

保護対象にするアプリケーションは、WebLogic Serverドメインにデプロイする必要があります。このドメインは、Oracle Platform Security Services(OPSS)のPS5用Opatchを適用したOracle Fusion Middleware 11.1.1パッチ・セット(PS5)またはOracle Fusion Middleware PS6以降で作成する必要があります。アプリケーションが実行されているWebLogic Serverドメインは、Access Manager Identity Asserterコンポーネントによって保護されている必要があり、そのコンポーネントによって、Access Managerから受け取ったIDアサーションが検証され、アイデンティティ・コンテキスト・ランタイムの作成プロセスが開始されます。Access Manager Identity Asserterは、トークン・タイプOAM_IDENTITY_ASSERTIONを検出するように構成する必要があります。また、アイデンティティ・コンテキスト・ランタイムと直接連動する保護されているアプリケーションは、OPSS属性サービスと連動するためのソース・コード・グラントを(例41-2のように)付与されている必要があります。

関連項目:

Access Manager Identity Asserterおよびソース・コード・グラントの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

41.5.2 Access Managerの構成

OAMは、アイデンティティ・コンテキストの主なパブリッシャおよびプロパゲータとして、関係コンポーネントからアイデンティティ・コンテキスト・データを収集するための中心的な構成ポイントとして機能します。次の項では、アイデンティティ・コンテキスト管理の背後にあるアーキテクチャの主要な要素について説明します。

- IDアサーションの構成

- フェデレーション属性の構成

- セッション属性の構成

- アイデンティティ・ストア属性の構成

41.5.2.1 IDアサーションの構成

Web層とアプリケーション層の間にエンドツーエンド・セキュリティを適切に施行するために、Access Manager認可ポリシーにアサートされた属性を定義することをお薦めします。

IDアサーション(SAMLセッション・トークン)は、Webリソースを保護するWebゲートとアプリケーション・サーバー・コンテナとの間の信頼の確保に加えて、SAML属性としてアイデンティティ・コンテキスト・データを公開するためにも使用されます。

IDアサーションは、有効化されている必要があり、アイデンティティ・コンテキスト内に特定の属性を想定しているビジネス・ロジックの必要に応じてアサートされた属性が移入されている必要があります。それは、OAMポリシー・レスポンスタブ内で構成され、認証と認可の両方のポリシーに対して定義できます。

関連項目:

Access Manager IDアサーションおよびアサートされた属性(表17-11)。

41.5.2.2 フェデレーション属性の構成

リソースをAccess Manager認証スキームFederationSchemeで保護すると、Access Managerはサービス・プロバイダのように動作し、フェデレーション・パートナによって提供されるSAMLアサーションを受け取るようになります。フェデレーション・シングル・サインオン(SSO)操作の後、次の属性が、認証済アイデンティティのAccess Managerセッションに存在するようになります。

- $session.attr.fed.partner (パートナ名を含む)

- $session.attr.fed.nameidvalue (SAML名前ID値を含む)

- $session.attr.fed.nameidformat (SAML名前IDフォーマットを含む)

- SAML属性ごとに1つの$session.attr.fed.attr.nameエントリ(パートナから受け取るSAMLアサーションに含まれる)
これらのフェデレーション属性は、アサートされた属性としてoracle:idm:claims:fed:attributesを選択し、その値をattr-name=$session.attr.fed.attr.nameに設定することでIDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、パートナのSAMLアサーション内のSAML属性の名前です。

たとえば、partner-role=$session.attr.fed.attr.roleの値でoracle:idm:claims:fed:attributesを定義すると、managerという値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:fed:attributes:partner-roleが作成されます($session.attr.fed.attr.roleに、SAML属性roleに対してパートナのSAMLアサーションで指定されているmanagerが含まれていると想定します)。

41.5.2.3 セッション属性の構成

Access Managerセッション属性は、アサートされた属性としてoracle:idm:claims:session:attributesを選択し、その値をattr-name=$session.attr.nameに設定することでIDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、Access Managerセッション属性の名前です。

たとえば、authn-strength=$session.attr.authnlevelの値でoracle:idm:claims:session:attributesを定義すると、ログイン・プロセス中に使用される認証スキームによって定義されている値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:session:attributes:authn-strengthが作成されます。

41.5.2.4 アイデンティティ・ストア属性の構成

アイデンティティ・ストア属性は、アサートされた属性としてoracle:idm:claims:ids:attributesを選択し、その値をattr-name=$user.attr.nameに設定することでAccess Manager IDアサーションの構成に使用できます。attr-nameは、アイデンティティ・コンテキスト属性に指定されている名前、nameは、アイデンティティ・ストア属性の名前です。

たとえば、first-name=$user.attr.fnameの値でoracle:idm:claims:ids:attributesを定義すると、アイデンティティ・ストアに保持されているそのユーザーのfname属性の値を持つアイデンティティ・コンテキスト属性oracle:idm:claims:ids:attributes:first-nameが作成されます。

41.5.3 Oracle Adaptive Access Managerの構成

Oracle Access ManagerとOracle Adaptive Access Manager (OAAM)との間の統合の一部として、OAAMはリスクベースのアイデンティティ・コンテキスト属性を公開および伝播します。この場合、OAAM属性は、ユーザー認証フロー(OAAM側)の終わりにDAPトークンでOAMに渡されます。DAPトークンは、表41-1「アイデンティティ・コンテキスト・スキーマ属性」のoracle:idm:claims:riskネームスペースによって定義される属性を伝送します。その後、OAMによってこれらの属性が$session.risk.attrネームスペースにプッシュされます。次の項では、OAAMとOAMの構成について説明します。

- Oracle Adaptive Access Managerのセットアップ

- OAAM統合のためのAccess Managerの構成

- OAAMによって公開されるアイデンティティ・コンテキスト・データの検証

41.5.3.1 Oracle Adaptive Access Managerのセットアップ

この項では、OAAMのインストールおよびセットアップについて説明します。

Oracle Adaptive Access Managerをセットアップするには

1. スナップショットをインポートすることで、OAAMをセットアップします。
詳細は、Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイドを参照してください。

2. 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』に記載されているようにOAAMとAccess Managerを統合します。
TAPトークンのバージョンは、v2.0ではなくv2.1であることが必要です。

3. 次のプロパティがtrueに設定されていることを確認します。

- oracle.oaam.idcontext.enabledは、デフォルトでtrueになっています。この値を変更するには、OAAM管理コンソールを使用します。

- bharosa.uio.default.registerdevice.enabledは、safeforuser要求が適切に処理されるためにはtrueであることが必要です。

4. OAAM管理コンソールから、「プロパティ」、「新規プロパティの作成」に移動します。

5. v2.1に等しい値を持つプロパティ名oaam.uio.oam.dap_token.versionを入力します。

6. oaam_server_server1を再起動します。

41.5.3.2 OAAM統合のためのAccess Managerの構成

次の手順を実行します。TAPSchemeを使用すると、強制的に、ユーザーがOAAM認証スキームを使用して認証されるようになります。

注意:

OAAM AdvancedまたはOAAM Basicを使用しないでください。

OAAMと統合するようにAccess Managerを構成するには

1. 認証にTAPSchemeを使用して(表16-20)、リソースを保護します(「特定のリソースに対する認証ポリシーの定義」)。

2. 次のチャレンジ・パラメータをTAPSchemeに追加します(表16-21)。

TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate

41.5.3.3 OAAMによって公開されるアイデンティティ・コンテキスト・データの検証

次の情報は、OAAMによって公開されるアイデンティティ・コンテキスト・データの検証方法を示しています。

- oracle:idm:claims:risk:newdeviceは、新しいデバイスからのログイン後はtrueになり、それ以外の場合はfalseになります。

- oracle:idm:claims:risk:levelは、いくつかの失敗したログインに続く成功したログインの後に高い値になります。これについてテストするには、いくつかの失敗するログインの後に、成功するログインを実行してみます。

- oracle:idm:claims:risk:safeforuserは、チャレンジ質問にユーザーが適切に回答した後、trueになります。

- oracle:idm:claims:risk:fingerprintには、ユーザーのデバイスのフィンガープリントが含まれます。デフォルトでは、HTTPヘッダー・データから構築されたフィンガープリントが使用されますが、それが使用できない場合は、Flashから構築されたフィンガープリント・データが使用されます。様々なフィンガープリントについてテストするには、様々なデバイスを試してみます。

41.5.4 Webサービス・セキュリティ・マネージャの構成

次のように実行して、Oracle Web Service Security Manager (OWSSM)がアイデンティティ・コンテキストを伝播できるようにします。

アイデンティティ・コンテキストに対応するようにWeb Service Security Managerを構成するには

1. アイデンティティ・コンテキストをサポートしているOWSSMセキュリティ・ポリシーを変更してtrueの値を持つpropagate.identity.context要素を含めることで、セキュリティ・ポリシーを構成します。

注意:

propagate.identity.context(デフォルトではfalse)は、SAML関連ポリシーの構成オーバーライド・プロパティです。それをグローバルに有効化するには、そのプロパティをtrueに設定してグローバル・ポリシーを構成します。

2. SAMLアサーションとメッセージに署名するように、キーストアと証明書ストアを構成します。更新したキーストアと証明書ストアを、domain_home/config/fmwconfig/ディレクトリにコピーします。

41.5.5 Oracle Entitlements Serverの構成

Oracle Entitlements Server (OES)とのランタイムの統合は完全に自動化されています。アプリケーションによってPEP APIが起動され、認可コールが行われると、PEP APIによってアイデンティティ・コンテキスト・ランタイム全体が、条件(アイデンティティ・コンテキストを定義するポリシー・オブジェクト)が評価されるOES PDPに自動的に伝播されます。

注意:

認可コールを行うときは、newPepRequest()メソッドに渡される最後の引数が、nullではなく、少なくともこの例で示すように空のhashmapであることを確認します。

PepRequestFactory requestFactory =
PepRequestFactoryImpl.getPepRequestFactory();
PepRequest request = requestFactory.newPepRequest (subject,
action, resource, new HashMap<String, Object>());
PepResponse response = request.decide();
boolean isAuthorized = response.allowed();

条件は、セキュリティ管理者がOES管理コンソールを使用して、アイデンティティ・コンテキスト・スキーマに基づいて作成します。次の組込み関数を使用して、アイデンティティ・コンテキスト属性を使用する条件を指定します。

- ASSERT_IDENTITY_CONTEXT

- GET_STRING_IDENTITY_CONTEXT

- GET_INTEGER_IDENTITY_CONTEXT

- GET_BOOLEAN_IDENTITY_CONTEXT

カスタムOES関数は、既知のリクエスト属性として完全なアイデンティティ・コンテキスト・ランタイム情報を受け取ります。このデータ構造は、アイデンティティ・コンテキストAPIを使用してアイデンティティ・コンテキスト・ランタイムに変換できます。例41-4は、受け取ったパラメータからコンテキストを作成するカスタムOES関数を示しています。

例41-4 アイデンティティ・コンテキストを作成するカスタム関数

public OpssString GET_STRING_IDENTITY_CONTEXT_V2 (
RequestHandle requestHandle,
Object[] args,
Subject subject,
Map roles,
Resource resource,
ContextHandler contextHandler) throws RuntimeException {

// Obtain string representation of the runtime ID Context from the request handle.
Context runtimeCtx = null;
try {
AttributeElement ctxAttr = requestHandle.getAttribute
(Constants.IDM_IDC_API_ID, false);
if (ctxAttr != null) {
String ctxStr = (String) ctxAttr.getValue();
runtimeCtx = new Context(ctxStr);
} else {
throw new RuntimeException ("Unable to acquire ID Context from request handle");
}
} catch (Exception e) {
throw new RuntimeException (e.toString());
}

…

// start using Context which now contains the same exact Identity Context Runtime as was present in the application that made the PEP API call
…
}

41.5.6 Oracle Enterprise Single Sign Onの構成

アイデンティティ・コンテキスト・サービスの一部として、Oracle Enterprise Single Sign-on(OESSO)は、クライアントベースのアイデンティティ・コンテキスト属性を公開および伝播できます。完全な統合が構成されると、クライアント固有のアイデンティティ・コンテキスト属性(第41.3.1項「アイデンティティ・コンテキスト・ディクショナリの使用方法」に記載)が、アクセス・リクエストで送信されたユーザー資格証明とともにセッション開始リクエストでOESSOによってOAMに送信されます。

リクエストの受信後に、OESSOによって、SSLで保護されているOAM REST API(OESSO管理者によって事前に構成され、OESSOクライアント配布の一部として含まれている)に対するコールが実行されます。このAPIによって、OAM_ID CookieがOESSOに返されます。その後、OESSOによって、有効なOAM_ID Cookieがクライアント・ブラウザ(Internet ExplorerおよびFirefox)に伝播され、それによってOESSOリソースの保護が可能になり、OAM埋込み資格証明コレクタによって保護されるリソースでシングル・サインオン(SSO)が有効になります。(これには、分散型資格証明コレクタによって保護されるリソースは含まれません。)その後、OESSOによって、OAM埋込み資格証明コレクタが受入れ可能なOAM資格証明とともに、ペイロード内のクライアント・コンテキスト情報が提供されます。

注意:

このペイロードは次のものによって保護されます。

- 16バイト・ランダムSaltの生成

- その16バイト・ランダムSaltを使用したSHA-256ハッシュの生成

- OESSOによって保護されるOAMパスワードを使用した要求の暗号化

アイデンティティ・コンテキストの属性を取得するようにOESSOを構成するには

1. OAMとOESSOの統合の詳細は、Oracle Enterprise Single Sign-On Suite Plusインストレーション・ガイドのログオン・マネージャ・クライアントサイド・ソフトウェアのインストールに関する項を参照してください。

2. 補足的な詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのログオン・マネージャでのOracle Access Managementのサポートに関する項を参照してください。

41.5.7 Oracle Access Management Mobile and Socialの構成

Oracle Access Management Mobile and Social (Mobile and Social)は、モバイルおよびデスクトップ・デバイス用にユーザー・プロファイル・サービスおよび認証サービスのほかにRESTベースの認証サービスを提供しています。Access Managerを使用する認証を提供するようにMobile and Socialを構成すると、モバイル・クライアントによって提供されるアイデンティティ・コンテキスト属性をAccess Managerに公開できます。このアイデンティティ・コンテキスト属性は、iOSおよびJavaのプラットフォーム用のMobile and Social SDKによって公開されます。

モバイル・アプリケーションは、Mobile and Social SDKを使用して、Mobile and Socialサーバーによって提供されるサービスにアクセスし、使用します。モバイル・アプリケーションがiOSまたはAndroid APIを使用して認証を実行する場合、それによってアイデンティティ・コンテキスト属性が取得され、そのデータがMobile and Socialサーバーに公開され、そこでその属性がAccess Managerサーバーに公開されます。管理者は、Mobile and Socialサーバーを、すべての属性を取得するように構成することも、必要な属性のみを取得するように構成することもできます。

管理者は、Access Manager管理コンソールの「システム構成」タブの下にある「Mobile and Social」アコーディオンの「アプリケーション・プロファイル構成」ページで、アプリケーションによって送信されるアイデンティティ・コンテキスト属性を構成できます。

Mobile and Socialサーバーは、Mobile and Social SDKからそのサーバーにアプリケーション・プロファイルを求めるアクセスがあったときに、必要なアイデンティティ・コンテキスト属性をMobile and Social SDKに渡します。(アプリケーション・プロファイルには、収集するアイデンティティ・コンテキストと実行する認証のタイプに関する情報が含まれています。)SDKは、属性の収集がユーザーまたはプラットフォームによって許可されている場合はそれを実行し、それらを認証リクエストの一部としてMobile and Socialサーバーに公開します。

注意:

一部のモバイル・プラットフォーム(たとえば、iOS)では、アプリケーションによる特定のデバイス属性(たとえば、UDIDまたはIMEIデバイス番号)の収集が禁止されています。また、そのユーザーは、アプリケーションがロケーションの更新を入手することを拒否できます。そのため、サーバーが属性を要求しても、SDKによってそれらがすべて収集できることは保証されません。

Mobile and Social SDKから収集した属性を、OAMサーバーで作成され維持されているユーザー・セッションに公開するようにMobile and Socialサーバーを構成する場合、管理者は、IDコンテキストを有効化するようにMobile and Socialサーバーを構成する必要があります(図41-4を参照)。

図41-4 OAM認証プロバイダの構成

アイデンティティ・コンテキストの属性を取得するようにMobile and Socialを構成するには

1. Mobile and Socialサービスが有効化されていることを確認します(「使用可能なサービスの有効化および無効化」を参照)。

2. MobileOAMAuthenticationの「サービス・プロバイダ」ページで、IDContextEnabled属性を追加して、その値にtrueを設定します。

関連項目:

- 構成の完全な詳細は、第38章「モバイル・サービスの構成」を参照してください。

- iOS SDKを使用してアプリケーションを開発する方法の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

41.6 アイデンティティ・コンテキストの検証

Access Managerを使用してアイデンティティ・コンテキストの適切な操作を確保する手順は、次のとおりです。

アイデンティティ・コンテキストの操作を検証するには

1. 次のように実行して、Access Managerによって構築されるIDアサーション・レスポンスを検証します。

1. /testidcリソースをWebゲート・エージェントで保護し、認可レスポンスの一部として目的のアサートされた属性を持つIDアサーションを返すようにAccess Managerを構成します。

2. OAMテスターを使用して、/testidcに対する認可リクエストへのレスポンスでOAM_IDENTITY_ASSERTION属性としてIDアサーションが返されていることを検証します。

2. 次のように実行して、WebゲートによってIDアサーションを含むHTTPヘッダーが作成されていることを検証します。

1. /cgi-bin/printenv.plスクリプトが、/testidcリソースを保護しているものと同じポリシーによって保護されていることを確認します。

注意:

printenv.plは、OHSの一部として出荷されており、実行する権限を持っている必要があります。かわりに、ヘッダー情報を表示する任意のスクリプトを使用できます。

2. printenv.plにアクセスし、ログインを起動し、HTTPヘッダーを表示します。

3. HTTP_OAM_IDENTITY_ASSERTIONヘッダーに、アサートされた属性を持つSAMLトークンが含まれていることを確認します。

第XI部

他の製品とAccess Managerとの統合

第XI部では、他のベンダーの製品とAccess Managerを統合する方法について説明します。

第XI部の内容は次のとおりです。

- 第42章「RSA SecurID認証とAccess Managerとの統合」

- 第43章「Windowsネイティブ認証のためのAccess Managerの構成」

- 第44章「JBossとAccess Managerの統合」

- 第45章「Microsoft SharePoint Server 2010とAccess Managerの統合」

42 RSA SecurID認証とAccess Managerとの統合

オラクル社は、RSAセキュリティ製品とインタフェース接続し、Access Managerによって保護されているリソースにネイティブRSA SecurID®認証を提供するコンポーネントを提供しています。

この章では、SecurID認証、およびSecurID認証とAccess Manager 11.1.2を適切に統合するために必要なコンポーネント、要件、および手順について説明します。トピックは次のとおりです。

- Access ManagerおよびRSA SecurID認証の概要

- SecurID認証に必要なコンポーネント

- SecurID認証モード

- RSA SecurID認証用のAccess Managerの構成

42.1 Access ManagerおよびRSA SecurID認証の概要

Access Manager 11.1.2は、RSAコンポーネントと統合して、SecurID認証を提供します。RSA SecurID認証は、ユーザーが認識しているものとユーザーが所有しているものの2つのファクタに基づいています。

- ユーザーが認識しているもの: これは秘密の個人識別番号(PIN)であり、概念的には個人の銀行コードPINに似ています。この場合、PINは、システム生成または個人的に選択したものであり、RSA Authentication Managerに登録されます。

- ユーザーが所有しているもの: これは、トークンと呼ばれるハンドヘルド・デバイスによって生成された現在のコードです。Oracle Access Managerでは、ハードウェアベースとソフトウェアベースの両方のすべてのRSA SecurIDトークン・フォーム・ファクタがサポートされています。

これらのトークンは、アルゴリズム的に内部クロックまたはイベントに基づいており、予測不能な値でトークンコードを生成します。ユーザーのPINとSecurIDトークンコードが組み合されて、ユーザーのパスコードになります。

Access Managerは、RSAの2つのファクタのSecurID認証セキュリティ機能を使用およびサポートし、次のものを提供することでSecurID認証との統合を可能にします。

- SecurID認証操作に必要なHTMLフォーム

- 認証を作成およびオーケストレートするためにユーザー識別プラグインで使用できるRSA SecurIDプラグイン。

Access Managerは、RSA Authentication Managerと統合し、表42-1に記載する統合機能を提供します。

表42-1 RSA機能に対するAccess Managerのサポート

RSA機能

Access Managerのサポート

認証方式

ネイティブSecurID認証

New PINモード(ユーザー生成PIN)

新規PINと確認を要求します。

トークンは、ユーザーが初めてログインしたときはNew PINモードになっている可能性があります。それ以外の場合は、Authentication Manager管理者がNew PINモードを有効化できます。New PINモードでは、新しいPIN番号は、ユーザーが一連のフォームに入力して定義するか、システムに生成させる必要があります。

オラクル社が提供するNew PINフォームおよび機能は次のとおりです。

- システム生成PIN (サポートされていません)

- ユーザー定義(4～8個の英数文字)

- ユーザー定義(5～7個の数字)

- 4および8桁PINの拒否

- 英数字PINの拒否

- 数値PINの拒否

- PINの再利用

関連項目: 「SecurID New PIN認証」.

Next Tokencode

認証中にAuthentication Managerによって、ユーザーは、割当て済トークンを持っていることを証明するために彼ら自身のSecurIDトークンに表示される次のトークンコードを入力するように指示されることがあります。この操作は、Next Tokencodeモードと呼ばれ、次の状況のいずれかで起動されることがあります。

関連項目: 「SecurID Next Tokencode認証」

パスコード

- 16桁パスコード

- 4桁固定パスコード

ロード・バランシング

RSA Authentication Managerレプリカ。

セカンダリ・サーバー・サポート

あり

SecurIDユーザー仕様

指定されたユーザー

管理者のSecurID保護

あり

Access Managerの特徴と機能

すべて

表42-2の場合は、Access ManagerはRSA機能をサポートしません。

表42-2 サポートされないRSA機能

RSA機能

Access Managerのサポート対象外

RSA Authentication Manager 7.1 SP2

Active Directoryフォレスト・マルチドメイン環境ではサポートされません。

複数のACEレルム

RSA認証APIでは、自動レスポンス時間ロード・バランシング・アルゴリズムを使用して、認証リクエストの送信先が決定されます。そのようなリクエストは、プライマリRSA Authentication Managerまたはレプリカのいずれかに送信されます。自動アルゴリズムは、sdopts.recという手動ロード・バランシング構成ファイルを作成することで上書きできます。ただし、RSA Authentication Managerを最後の手段のサーバーとして手動で重み設定しても、それとエージェントとの通信が防止されることはありません。そのため、この方法では真のフェイルオーバー・セットアップを実現できません。詳細は、ご使用のRSA Authentication Managerのドキュメントを参照してください。

システム生成PIN

Access Managerでサポートされていません。

フェイルオーバー

OAM SecurIDサーバーではサポートされていません。SecurID認証を実行できるのは1つのOAM SecurIDサーバーのみであるためです。

42.2 SecurID認証に必要なコンポーネント

統合には次のコンポーネントが必要です。

- サポートされるバージョンおよびプラットフォーム

- 必要なRSAコンポーネント

- インストール要件および構成要件

42.2.1 バージョンおよびプラットフォームのサポート

最新のサポート情報は、Oracle Technology Network(OTN)を参照してください。この情報を表示するには、OTNに登録する必要があります。

証明書マトリックスで、この統合のためのプラットフォームおよびバージョンのサポートが提供されています。これにはRSA Authentication Manager v7.xおよびSecurID認証APIが含まれます。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

42.2.2 必要なRSAコンポーネント

Access ManagerとSecurID認証の統合には、次のRSAコンポーネントが必要です。

- RSA Authentication Manager

- RSA SecurIDトークン

42.2.2.1 RSA Authentication Manager

ユーザー、エージェント、トークン、およびユーザーのPINのレコードはネットワーク内のいずれかの場所に配置されています。これらのレコードの一部が、Authentication ManagerまたはLDAPディレクトリに配置されていることがあります。認証中に、Authentication Managerは、それらのレコードとユーザーがネットワークにアクセスを試みるときにそれが受け取る情報を比較します。レコードとトークンコードまたはパスコードが一致すると、ユーザーはアクセスの権限を付与されます。

42.2.2.2 RSA SecurIDトークン

RSA SecurIDトークンは、ハードウェアベースまたはソフトウェアベースのセキュリティ・トークンであり、保護されているリソースにユーザーが安全にアクセスすることを可能にするランダム番号を生成および表示します。このランダム番号はトークンコードと呼ばれます。ユーザーがトークンによって認証を受けるには、その前にトークンがAuthentication Managerによって認識される必要があります。RSAまたはご使用のベンダーによってトークン・シード・ファイルが同梱されており、それをデータ・ストアにインポートする必要があります。このファイルにリストされているシードは、トークンに割り当てられており、Authentication Managerエージェントから認証リクエストを受信したときにトークンコードを生成します。

SecurID認証プロセス中に、ユーザーは、自分のユーザー名とパスコードをHTMLフォームを使用して送信する必要があります。RSA Authentication Managerは、クライアントとしてAuthentication Managerに登録されているサーバー(RSA認証エージェント)を介して各ユーザーのアイデンティティを認証します。1つのアクセス・サーバー(他のアクセス・サーバーと区別するためにOracle SecurID Access Serverと呼ばれる)を、クライアントまたはエージェントとして登録およびセットアップする必要があります。

RSA Authentication Managerはそれが生成したトークンコードを、ユーザーが入力したトークンコードと比較します。トークンコードは、指定された間隔(通常は60秒)で変わります。時間同期によって、ユーザーのトークンに表示されたトークンコードは、その時点に対してAuthentication Managerソフトウェアによって生成されたものと同じコードになります。トークンコードが一致すると認証は成功します。2つのファクタによる認証は、タスクを誰が実行したのかについてより強力な法的証拠を提供します。Authentication Managerは、適切に構成されている場合、すべてのログイン・リクエストおよび操作を追跡し、記録された各アクションに責任を持つユーザーを高い信頼度で特定します。

42.2.3 インストール要件および構成要件

SecurIDは、ユーザー操作のためにOAMサーバーとRSA Authentication Managerとの間のアフィニティを必要とします。したがって、ユーザーとOAMサーバーとの間の対話はスティッキーである必要があります(この制約がSecurID認証のセキュリティの特徴です)。クラスタ環境で、ロード・バランサが使用されてリクエストが複数の管理対象サーバーにルーティングされる場合、ロード・バランサとOAMサーバーとの間にスティッキネスが設定されるようにします。

SecurID認証APIは、Access Managerに同梱されており、すべてのOAMサーバーにインストールされます。SecurID認証APIによって接続機能が提供されるため、OAMサーバー上に認証エージェントをインストールする必要はありません。つまり、このAPIはエージェントです。

表42-3に記載されている他の要件とともに、すべてのOAMサーバーを、Authentication ManagerにRSA Authentication Agentホストとして登録する必要があります。

表42-3 インストールおよび構成のガイドライン

SecurID認証を完了できるのは、1つの指定されたOAM SecurIDサーバーのみです。ただし、すべてのOAMサーバーを、Authentication ManagerにRSA Authentication Agentホストとして登録する必要があります。

OAM SecurIDサーバーをAuthentication Managerクライアントとして認識できるようにします。

Authentication Managerが認証エージェント(OAM SecurIdサーバー)と通信するためにポート5500 (UDP)が使用可能になっている必要があります。このサービスは、Oracle SecurId Serverから認証リクエストを受信し、リプライを送信します。詳細は、ご使用のRSA Authentication Managerのドキュメントを参照してください。

クライアントからAuthentication Managerへの認証リクエストを管理します。

2つのファクタの認証を適用し、認可されていないアクセスをブロックします。

レプリカのAuthentication Managerのレスポンス時間を検出し、それに応じて認証リクエストをルーティングすることで、自動ロード・バランシングを提供します。

サーバーとクライアントの非同期を防止するために、クライアント上のシステム時間が正確であることを確認します。

Access Managerに対してフェイルオーバーはサポートされていません。

SecurID Authentication Managerは、サポートされているプラットフォームにインストールする必要があります。

サーバーとクライアントの非同期を防止するために、システム時間は正確である必要があります。

SecurIDトークンまたはキー・フォブは、トークン・シード・レコードで提供することで、Authentication Managerによってプロビジョニングされる必要があります。

各ユーザー名は、LDAPフィルタを介して、ディレクトリ内の識別名にマップ可能であることが必要です。

Authentication ManagerスレーブまたはレプリケートされたAuthentication Manager、あるいその両方は、プライマリAuthentication Managerが停止した場合に、フェイルオーバーを提供できます。

この統合には、カスタムHTMLログイン・フォームおよびプロパティ・ファイルが必要です。オラクル社が提供するサンプルのカスタムhtmlおよびカスタムhtmlプロパティ・ファイルは次の場所にあります。

$ORACLE_HOME/oam/server/tools/customLoginHtml

関連項目:

- Oracle Fusion Middleware Oracle Access Management開発者ガイドのカスタム・ログイン・ページの開発に関する項

- 「RSA SecurID認証用のAccess Managerの構成」

42.3 SecurID認証モード

次のシナリオでは、3つのモードの操作について説明します。

- 標準SecurID認証

- SecurID Next Tokencode認証

- SecurID New PIN認証

42.3.1 標準SecurID認証

ユーザーが、SecurID認証スキームで保護されているリソースにアクセスしようとすると、次のプロセスが実行されます。

注意:

11.1.2資格証明コレクタは、デフォルトの埋込み資格証明コレクタと、オプションの外部資格証明コレクタのいずれかを示しています。詳細は、「認証方式と資格証明コレクタの理解」を参照してください。

プロセスの概要: ユーザーがリソースを要求するとき

1. Webゲートは、リソース・リクエストをインターセプトし、Access Serverに問合せを実行して、リソースが保護されているかどうか、保護の方法、およびユーザーが認証されているかどうかを判定します。

2. OAM SecurIdサーバーは、認証スキームについてディレクトリに問合せを実行し、ディレクトリから認証情報を受信します。

3. Webゲートは、チャレンジ・コレクタにリダイレクトし、それこで2つの部分からなるSecurIDパスコードをユーザーに求めるフォームを表示します。

4. ユーザーが資格証明をチャレンジ・コレクタに送信します。

5. チャレンジ・コレクタは、資格証明をOAM SecurIdサーバーに渡します。

6. OAM SecurIdサーバー上のSecurID認証APIが認証ダイアログを実行し、LDAPバインドをAuthentication Managerに送信します。

7. Authentication ManagerデータベースがSecurIDパスワードをユーザーIDと照合し、成功レスポンスをAuthentication Managerに返し、そこでユーザーのPINと照合します。

8. Authentication ManagerがレスポンスをそのエージェントであるOAM SecurIdサーバーに返します。

9. ユーザーの資格証明が有効な場合、SecurID認証は成功します。OAM SecurIdサーバーによって、ユーザーのセッションが作成され、ユーザーがWebゲートにリダイレクトされ、そこでリソース認可についてOAM SecurIdサーバーに問合せが実行されます。

- 「標準SecurID認証」の説明のように、特定の条件下では、New Tokencodeモードが開始されます。

- 「SecurID Next Tokencode認証」の説明のように、特定の条件下では、New Pinモードが開始されます。

10. OAM SecurIdサーバーが、認可リクエストを評価し、それによって、認可ルールに基づいてアクセスが許可または拒否されます。

11. アクセスの権限が付与されると、OAM SecurIdサーバーによって認可がWebゲートに渡され、それによってリソースがユーザーに提示されます。

42.3.2 SecurID Next Tokencode認証

Next Tokencodeモードがオンになっている場合、ユーザーは、彼らのSecurIDトークンの次のトークンコードを入力する必要があります。このモードは、次の場合に起動できます。

- ログイン中に不正なパスコードが繰り返し入力された場合。ユーザーが4回連続して不正なパスコードを使用して認証を試みた場合、Authentication Managerのアクティビティ・レポートに記載されているように、Authentication ManagerによってNext Tokencodeモードがオンになります。次にユーザーが正しいパスコードを使用して認証に成功したときに、彼らは彼らのSecurIDトークンに表示される次のトークンコードの入力を求められます。

- Authentication Managerは、トークンの確認、または同期を必要とします。正しいパスコードが使用された場合でも、Authentication Manager管理者はNext Tokencodeモードをオンにして、ユーザーに、彼らがSecurIDトークンを持っていることを確認したり、トークンをAuthentication Managerと同期することを強制することがあります。Next Tokencodeモードがオンになっている場合、成功したログインの直後にNext Tokencodeチャレンジ・フォームがユーザーに表示されます。

プロセスの概要: Next Tokencodeがオンのとき

1. 資格証明コレクタによって、成功したログインの後のトークン上の次のトークンコードの入力をユーザーに求めるフォームが提示されます。

2. ユーザーはユーザー名を入力し、60秒間待ってから、SecurIDトークン上の次のトークンコードを入力します。

3. トークンコードが正しい場合、ユーザーが最初に入力したパスコードが受け入れられてユーザーが認証されます。

42.3.3 SecurID New PIN認証

ユーザーが新しいPINを持つことが必要とされている場合、チャレンジ・コレクタがユーザーに入力を求める特定のフォームを表示します。

プロセスの概要: New PINが必要なとき

1. チャレンジ・コレクタによって、ユーザーが希望するPINを入力できるフォームが提示されます。

2. ユーザーが新しいPINを入力し、その新しいPINを再入力して、フォームを完了します。

3. OAM SecurIDサーバーは、その情報をAuthentication Managerに転送します。

4. Authentication Managerは、その新しいPINを登録し、それは、その後のログインでユーザーが入力する必要があるPINコードの一部になります。

5. ログイン・フォームが再度表示され、そこで、ユーザーは強制された再認証のためにユーザー名とパスコードを入力します。

42.4 RSA SecurID認証用のAccess Managerの構成

有効なOracle Access Management管理者資格証明を持つユーザーは、この項の手順を使用して、RSA SecurID認証を有効化できます。

前提条件

インストールおよび構成(このマニュアルの範囲外)については表42-3を参照してください。それらは、Access ManagerとSecurIDとの統合を開始する前に完了しておく必要があります。

関連項目:

- Oracle Fusion Middleware Oracle Access Management開発者ガイドのカスタム・ログイン・ページの開発に関する項

Access ManagerとSecurID認証をセットアップするには

1. 次のように、oam-config.xmlで、OAM SecurIDサーバーのserverRequestCacheTypeパラメータをBASICに設定します。

1. すべてのWebLogic Server(OAMサーバーと管理サーバー)を停止します。

2. 次のパスでoam-config.xmlを見つけます。

$DOMAIN_HOME/config/fmwconfig/oam-config.xml

3. 次のようにserverRequestCacheTypeをCOOKIE (デフォルト)からBASICに変更します。

<Setting Name="serverRequestCacheType" Type="xsd:string">BASIC</Setting>

4. すべてのWebLogic Server (OAMサーバーと管理サーバー)を起動します。

2. RSAコンソールからWebエージェントを登録します。それはAccess Managerによって使用されます。次に、次のようにエージェント構成ファイル(sdconf.rec)をコピーします。

$DOMAIN_HOME/config/fmwconfig/servers/$SERVER_NAME/oam/sdconf.rec

3. Oracle Access Managementコンソールから、次のようにRSA用のカスタム認証モジュールを作成します。

関連項目:

「プラグイン・ベースのモジュールによるマルチステップ認証の編成」

1. 「システム構成」タブ、「Access Manager」セクション、「認証モジュール」ノード、「カスタム認証モジュール」ノードを開きます。

2. 「ステップ」タブの「追加」(+)ボタンをクリックして、次の情報を入力することで、RSA_AUTHという新しいモジュールを作成します。

3. 「一般」タブ:

Name: RSA_AUTH

4. 「ステップ」タブ: 次のようにステップの名前を入力し、RSA SecurIDプラグインを選択します。

Step Name: stepRSA
Plugin Name: RSA SecurID Plugin
OK

5. stepRSA、「ステップの詳細」: 次の画面に表示される「ステップの詳細」に入力して保存します。これは、使用しているcustomhtml.propertiesファイルにも表示されます。

6. 「ステップ」タブ: ユーザーIDの追加プラグイン: 次のようにステップの名前を入力し、RSA SecurIDプラグインを選択します。

Step Name: rsa_useridentification
Plugin Name: UserIdentificationPlugin
OK

7. rsa_useridentification、ステップの詳細: 使用している環境について次の詳細を入力して保存します。
KEY_LDAP_FILTER: (uid={KEY_USERNAME})

KEY_IDENTITY_STORE_REF: 登録済デフォルト・ストア。

KEY_SEARCH_BASE_URL: dc=us,dc=example,dc=com

4. 次のようにステップをオーケストレートします。stepRSAは先頭にする必要があります(ユーザーをRSAサーバーで認証するため)、成功ステップに対するユーザーIDプラグインを指定します。

Initial Step: stepRSA

Name: StepRSA
On Success: rsa_useridentification
On Failure
On Error
Apply

Name: rsa_useridentification
On Success: Success
On Failure: stepRSA
On Error
Apply

5. カスタムHTMLログイン・フォームとともに、RSAに対して作成したカスタム認証モジュールを使用する新しい認証スキーム(たとえばRSACredScheme)を作成します。サンプルの値を次の画面に示します。

注意:

認証スキームのコンテキスト値は、カスタムHTMLログイン・フォームのパスを指定します。カスタムHTMLプロパティ・ファイルは、同じディレクトリ・パスにあるフォームと同じ名前(.properties拡張子付き)を共有する必要があります。この例ではcustomhtml.htmlとcustomhtml.propertiesを使用します。

チャレンジ・パラメータは、認証のための最初のRSAコマンドを指定します(RSA_USER_PASSCODE)。is_rsa=trueパラメータと値をRSAに対して指定する必要があります。

6. このスキームは、SecurID認証を必要とするリソースを保護しているアプリケーション・ドメインで使用します。

7. カスタムHTMLファイルが次の場所に存在していることを確認します。

$DOMAIN_HOME/config/fmwconfig/customhtml.html

RSA用カスタム・ログイン・フォームでは、フォーム・アクションが次のように/oam/server/auth_cred_submitに設定されている必要があります。

<form id="loginData" action="/oam/server/auth_cred_submit" method="post" name="loginData">

<div id="oam_credentials" class="input-row">
<span class="ctrl"></span>
</div>
div class="button-row">
<span class="ctrl">
<input id="login_button" type="submit" value="Login" class="formButton"
onclick="this.disabled=true;document.body.style.cursor = 'wait';
this.className='formButton-disabled';form.submit();return false;"/>
</span>
</div>
<div id="oam_error_messages"></div>
</form>

8. 使用しているcustomHTML.propertiesファイルが次のとおりであることを確認します。

- カスタムHTMLファイルに.properties拡張子付きの名前が付いていること。

- カスタムHTMLファイルと同じパスに格納されていること。

- 設定がRSA SecurIDプラグイン構成パラメータと一致していること。次に例を示します。

username=Username
password=Password
passcode=Mother's maiden name
rsa_new_pin=RSA New Pin
rsa_new_pin_confirm=RSA Confirm New Pin
Pin=RSA Pin
rsa_sysgen_pin=RSA Create New Pin
rsa_sysgen_pin_confirm=RSA System Generated Pin
error1=Username not specified

9. OAMサーバーを再起動します。

10. 保護されている適切なリソースにアクセスし、様々なモードを検証することで構成をテストします。

11. 問題が発生する場合、詳細は、「RSA SecurIDの問題とログ」を参照してください。

43 Windowsネイティブ認証のためのAccess Managerの構成

Access Managerでは、Microsoft Internet Explorerユーザーが各自のデスクトップ資格証明を使用して自動的にWebベースのシングル・サインオン・アプリケーションへの認証を行うように設定できます。これはWindowsネイティブ認証(WNA)と呼ばれています。

この章には、Active Directoryを使用して環境を準備し、この統合を実行する方法を説明する次の項が含まれています。

- このリリースの新機能

- Access ManagerとWindowsネイティブ認証の概要

- Active Directory/Kerberosトポロジの準備

- Oracle固有の前提条件となるタスクの実行

- Kerberosトークンを返すためのブラウザの有効化

- KerberosPluginとOracle Virtual Directoryの統合

- Access Manager KerberosPluginと検索フェイルオーバーの統合

- Windowsネイティブ認証のためのAccess Managerの構成

- Access Managerによって保護されたリソースでのWNAの検証

- WNA構成のトラブルシューティング

43.1 このリリースの新機能

このドキュメントは、最新の情報を反映するために更新されています。この更新内容には、次のものがあります。

- Active Directoryを使用したWindowsネイティブ認証によるAccess Managerの証明書。これについては、このドキュメントで説明しています。

注意:

アイデンティティ・ストアは、Kerberosユーザー名(user@realm)のマッピングを実行できる任意のLDAPディレクトリにできます。Active Directoryでなくてもかまいません。

- userprincipalnameとsamAccountNameの使用を明確にするナレッジベース・ノート1408574.1の詳細。

- ナレッジベース・ノート1278339.1には、Access Manager WNAログイン・シナリオが含まれます。

- ナレッジベース・ノート1410845.1には、Access Manager WNAフォールバック認証が含まれます。

43.2 Access ManagerとWindowsネイティブ認証の概要

Access Managerは、Windowsネイティブ認証(WNA)とのActive Directoryのマルチドメインおよびマルチフォレスト・トポロジ統合をサポートします。Active Directoryのディレクトリ・サービスは、オブジェクト(ユーザー、グループ、コンピュータ、ドメイン、組織単位およびセキュリティ・ポリシー)に関するすべてのディレクトリ情報にデータ・ソース(ディレクトリと呼ばれる)を使用します。

関連項目:

Oracle Identity and Access Management 11gR1のシステム要件とサポート対象プラットフォーム: https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

この章で説明する統合では、アプリケーションは、KerberosPlugin認証メソッドを使用したチャレンジ・メソッドとしてWNAとともにKerberos認証スキーム(KerberosScheme)を使用するAccess ManagerOracle Access Manager認証ポリシーによって保護される必要があります。この場合は、ユーザー・アイデンティティ・ストアとしてAccess Managerに登録されたWindows Active Directoryインスタンスに、資格証明を保存する必要があります。

言い換えると、保護されたリソースそれぞれがAccess Managerのアプリケーション・ドメインで定義されます。認証ポリシーには、デフォルトのユーザー・アイデンティティ・ストアに関連付けられている認証モジュール(Kerberos)を使用する認証スキーム(KerberosScheme)が含まれています。このストアは、認証に「ユーザー名属性」の値を使用します。この値は、特定のAccess Managerリリースに応じて、Active Directoryのユーザーおよびuserprincipalname = username@domianまたはSamAccountName = usernameの値に関連付けられています。

Access Managerシングル・サインオンをWNAと組み合せると、ユーザーのログイン資格証明などが含まれたKerberosセッション・チケットが生成されます。このKerberosセッション・チケットはユーザーには表示されません。

Access Managerは、Windowsネイティブ認証(WNA)と相互運用し、ユーザーがWindowsドメインにログインしたときに取得したKerberos資格証明を使用します。このクロス・プラットフォーム認証は、Kerberosプロトコルを使用するWindows間のネイティブ認証サービスのネゴシエーション動作をエミュレートすることによって実現します。このクロス・プラットフォーム認証を機能させるため、OAMサーバーは、SPNEGOトークンを解析して、認証に使用されるKerberosトークンを抽出する必要があります。

- SPNEGOは、考えられる多数の実際のメカニズムの1つをネゴシエートするために使用されるGSSAPI(Generic Security Services Application Programming Interface)「擬似メカニズム」です。SPNEGOは、これを使用してイニシエータおよびアクセプタでKerberosメカニズムまたはNTLMSSPメカニズムのいずれかをネゴシエートできるようにするMicrosoftの「HTTPネゴシエート」認証拡張子でよく使用されます。GSSAPI実装は、ほとんどの主なkerberosの配布に含まれています。SPNEGOの詳細は、http://tools.ietf.org/html/rfc4559を参照してください。

- Kerberosは、秘密鍵暗号化を使用してクライアント/サーバー・アプリケーションおよびサービスに強力な認証を提供するネットワーク認証プロトコルです。Kerberosプロトコルの無料実装は、マサチューセッツ工科大学から入手でき、また市販されています。

詳細は、次を参照してください。

- Access ManagerのWNAログインおよびフォールバック認証

- サポートされる統合方法

43.2.1 Access ManagerのWNAログインおよびフォールバック認証

WNAが実装されていることで、ユーザーは資格証明のチャレンジを別途行うことなくWebアプリケーションをクリックできます。これは、Kerberosセッション・チケットがブラウザを通じてOAMサーバーに渡されるためです。OAMサーバーは、受信したトークンを復号化(キー・タブを使用)して、そこから認証済ユーザーの名前を抽出します。認証が成功すると、ユーザーはWebアプリケーションへのアクセスが自動的に許可されます。

関連項目:

Oracle Identity and Access Management 11gR1のサポート対象ブラウザおよびサポート対象プラットフォーム: https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

この項では、いくつかのWNAログイン・シナリオについて説明します。

プロセスの概要: 正常なAccess Manager WNA認証

1. ブラウザは、統合Windows認証(IWA)用に構成されます。

2. Access ManagerおよびWNAによって保護されるリソースが呼び出されます。

3. 有効なKerberosチケットが表示されます: Http headers... Authorization: Negotiate YIIJ/...

4. ユーザーは、認証に関してチャレンジされません。リクエストしたリソースが表示され、WNAが機能することが証明されます。

つまり、ブラウザが統合Windows認証を使用するように構成されていて、リソースがAccess Manager Kerberos認証モジュールで保護されている場合は、次のようになります。

- KerberosチケットをAccess Manager(ドメインにかかわりなく)が受け取ると、認証が試行されます。

- 成功: アクセスが付与されます。

- 失敗: Kerberosチケットの情報が提示されないかまたはデフォルトのユーザー・アイデンティティ・ストアで定義したユーザー名属性の値と一致しない場合、「不適切なユーザー名またはパスワード。」エラーが表示されます。アクセスは拒否されます。ブラウザはチケットを自動的に送信して、Access Managerとの相互作用はユーザーがロックアウトされるまで繰り返されます。ブラウザは、各交換の開始前に一時停止できません。

- NTLMSSPチケットをAccess Managerから受け取った場合、認証は失敗します。NTLMSSPは、すべてのバージョンのDCOM(Distributed Component Object Model)で使用できるセキュリティ・サポート・プロバイダです。これは、認証中にユーザーのパスワードをサーバーに実際には渡さない認証にNTLMプロトコルを使用します。

- 使用するブラウザは、統合Windows認証を使用するように構成されず、Access Manager Kerberos認証モジュールによって保護されるリソースがリクエストされるとき、TGTは提供されません。ブラウザの基本認証ウィンドウが表示され、ここで、Access ManagerのUser login attributeのデフォルトのアイデンティティ・ストアで定義された有効なユーザー名/パスワードの組合せを入力できます。

注意:

KerberosチケットがAccess Manager(ブラウザ、オペレーティング・システム、ドメイン・ログインなどには関係ない)によって識別できない場合、フォールバック・メカニズムが呼び出されます。

WNAフォールバック認証: フォールバックは、チャレンジ・メソッド「Basic」と認証モジュール「LDAP」による認証スキーム「BasicScheme」を使用します。この認証モジュールは、コンソールを使用して変更できます。

このLDAP認証モジュールは、LDAPプラグインを使用します。このプラグインでは、ユーザー・アイデンティティ・ストアを、「ユーザー名属性」に使用する属性を定義する、現在登録されている任意のユーザー・アイデンティティ・ストアとして定義できます。

処理の概要: Access ManagerのWNAフォールバック認証

1. ブラウザは、統合Windows認証(IWA)用に構成されます。

2. Access Manager WNAによって保護されるリソースがリクエストされます。

3. チケットは表示されません(NTLM/Kerberos) - Http headers... Authorization: Basic

4. 基本認証ウィンドウのポップアップが表示されます。

5. ユーザーは有効なユーザー名/パスワードを入力します。

6. リクエストしたリソースが表示されます(WNAフォールバックが機能します)。

43.2.2 サポートされる統合方法

Access Managerでは、次の方法がサポートされます。

- Oracle Virtual Directoryを使用したKerberosプラグイン: Oracle Virtual Directoryと統合された、編成された認証プラグインとともにAccess Managerを使用すると、複数のActive Directoryグローバル・カタログが仮想化されます

関連項目:

- Active Directory/Kerberosトポロジの準備

- Oracle固有の前提条件となるタスクの実行

- KerberosPluginとOracle Virtual Directoryの統合

- 複数のADGC間で検索フェイルオーバーを使用するKerberosプラグイン: Access Managerを編成された認証プラグインとともに使用します。このプラグインは、複数のActive Directoryグローバル・カタログ間でフェイルオーバー・パターンを実行します。

関連項目:

- Active Directory/Kerberosトポロジの準備

- Oracle固有の前提条件となるタスクの実行

- Access Manager KerberosPluginと検索フェイルオーバーの統合

43.3 Active Directory/Kerberosトポロジの準備

この項のタスクは、選択する方法に関係なく必要です。

ここで説明する完全に構成されたMicrosoft Active Directory認証サービス設定が必要です。この項の手順に従うと、Active DirectoryとKerberosクライアントが連動します。ただし、これはOracle固有ではありません。

次のサンプル・シナリオは、一般的なActive Directoryトポロジを表しています。Access Managerによって指示された要件でもAccess Manager用の要件でもありません。ここで使用される名前は単なる例です。環境はユーザーによって異なります。

フォレストと信頼のサンプル

例として、企業内で動作する2つのActive Directoryフォレストについて考えてみます。

フォレスト

ドメイン名

ORACLE

lm.example.com

SPRITE

lmsib.sprite.com

ORACLEフォレスト内に子ドメイン(child.lm.example.com)が存在するとします。

信頼は次のように要求されます。

- フォレスト間: 双方向、非推移的な信頼。

- 子ドメインとその親の間: 双方向、推移的な信頼。

接尾辞と継承

- SPRITEユーザーには、sun.comやjava.comなどのUPN接尾辞があります。SPRITEフォレストにはtestuser.java.comが含まれています。

- ORACLEユーザーには、myoracleco.comやoracleco.comなどの接尾辞が付きます。ORACLEフォレストにはtestuser.oracleco.comが含まれています。

- ORACLEの子ドメインは、親ドメインのUPN接尾辞を継承します。

注意:

DOMAIN\USERNAMEという形式のPre-Windowsユーザー名はサポートされません。

WNAのデフォルト・アイデンティティ・ストア・ユーザー名属性

WNAとの統合では、デフォルト・アイデンティティ・ストア用に定義されたUser Name AttributeをActive DirectoryユーザーのsamAccountNameと一致する値を持つ任意の属性にできます。

暗号化タイプ

環境が使用する暗号化タイプを把握している必要があります。場合によっては、このアカウントにDES暗号化タイプを使用するを有効にしてユーザーを作成する場合があります。ただし、Active DirectoryはDES暗号化を使用しません。

注意:

次の手順で作成するkeytabファイルはRC4-HMAC暗号化を使用します。

Access ManagerはJGSS/JDK6がサポートするものをサポートします。使用可能なTGT暗号化の制限事項は、サポートされる最も一般的でないまたは最下位の暗号化(KDC、Keytab、オペレーティング・システム、Kerberosクライアント)であるピースによって決まります。Access Managerは、どのKerberos暗号化タイプもサポートしません。これは、認定される汎用セキュリティ・サービス(GSS)/Kerberos jdk暗号化タイプによって決まります。Access Managerは、暗号化タイプに依存せず、TGT暗号化を使用しません。SPNEGOトークンの一部として、Access Managerは、ktpass/keytabコマンド実行時にサービス(ここではAccess Manager)が登録したキーで暗号化されたサービス・チケットのみを検索します。

注意:

次の手順で作成するkeytabファイルはRC4-HMAC暗号化を使用します。

暗号化は、異なるOS(Kerberosサーバー/クライアントとして動作するWindows/Linux)の間の通信に使用されます。OAMサーバーは、ユーザーの資格証明の抽出元であるSPNEGOトークンのみを必要とします。Access Managerによって使用されるWindowsクライアント(ブラウザ)、Windows KDCおよび汎用セキュリティ・サービス(GSS)の各クラス間のこの3つの否定プロセスで使用される暗号化は、使用されるバージョンに依存します(これは一致する必要があります)。

関連項目:

Access ManagerがサポートするKerberos暗号化タイプの詳細のMy Oracle Support [Doc 1212906.1](https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1212906.1)

ドメイン要件

信頼できるドメイン(たとえば、ルート・ドメインlm.example.com)で、次の目的を達成する手順を実行します。

- OAMサーバーのアカウントの作成。

- Active Directoryマルチドメインまたはマルチフォレスト・トポロジおよび信頼関係で構成されたkeytabファイルの抽出。

- OAMサーバー(またはOAMクラスタを表すロード・バランサ)の完全修飾ホスト名にレルム名を付加したサービス・プリンシパル名(SPN)の指定。

サンプル名

この例では、表43-1の名前が使用されます。

表43-1 サンプル名

名前

説明

kdc.lm.example.com

KDCホスト名

KDCは、Active Directoryドメイン内のユーザーとコンピュータにセッション・チケットおよび一時セッション・キーを提供する、信頼できるネットワーク・サービスです。KDCは、Active Directoryドメイン・サービスの一部として各ドメイン・コントローラ上で実行され、ドメイン・サービスとして実装されます。KDCは、Active Directoryをアカウント・データベースとして使用します。Kerberosプロトコルの実装では、KDCは、2つのサービス(認証サービス(AS)とチケット付与サービス(TGS))を提供する単一プロセスです。

kdc.lm.example.com

AdminServerホスト名

これは、KDCホスト名と同じです。

oam11g.example.com

OAMサーバー・ホスト名

LM.EXAMPLE.COM

LMSIB.SPRITE.COM

デフォルトのActive Directoryレルム

2つ目のActive Directoryレルム

レルム名は、ユーザー・アカウントの場所を識別します。レルム名は、接頭辞または接尾辞のいずれかにできます。

アクセス・クライアントがユーザー資格証明を送信するとき、ユーザー名が含まれることが多いです。ユーザー名の中には2つのエレメント(ユーザー・アカウント名とユーザー・アカウントの場所)が入っています。

HTTP/fully_qualified_OAMServerhostname@REALM_NAME(大文字)

ユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)にはサービス・プリンシパル名(SPN)が必要です。

注意: フォレスト全体にわたってコンピュータにサービスのインスタンスを複数インストールする場合、各インスタンスに独自のサービス・プリンシパル名がある必要があります。

次の手順のコマンドは、Unixオペレーティング・システム用です。コマンド構文は、環境内固有のオペレーティング・システムによって異なります。

Active Directoryおよびkerberosを準備するには:

1. Oracle証明書マトリックスを確認し、この統合に対してサポートされているバージョンのActive Directoryをインストールしていることを確認します。

https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

2. 次のようにActive Directoryをインストールして構成します。

- 次の必要な信頼関係を備えたマルチフォレスト・トポロジが構成されていて動作する
a.Kerberosサービスをマップするユーザー・アカウント

b.これらのユーザー・アカウント(クライアントがサービスのインスタンスを一意に識別する名前)のサービス・プリンシパル名(SPN)。

c.キー・タブ・ファイル

- Active Directoryグローバル・カタログ(ADGC)が各フォレスト内で有効になっていて動作する

- マルチフォレスト・デプロイメント: この場合、様々なフォレストに基づくユーザーを一意に識別するネーミング属性(グローバル・カタログ内にある)が存在することを確認します。一般的に、userprincipalnameはフォレストに対して一意で、samAccountNameはドメインに対して一意です。

- フォレスト・アフィリエーションに関係なく、他のドメインそれぞれに直接的または間接的に信頼されている1つのドメイン。

3. Access Managerのユーザーを作成し、WNA認証中に使用し、このユーザー名を記録してkeytabファイル(DES暗号化なし)を生成します。

4. OAMサーバー・ホスト名を記録します。次に例を示します。

oam11g.example.com

5. KDCホスト名およびActive Directoryドメイン/レルムを記録します。

KDC = kdc.lm.example.com
Default AD Realm = lm.example.com

6. OAMサーバー・クライアントが使用しているActive Directoryユーザーのサービス・プリンシパル名(SPN)を作成し、その結果(暗号化タイプを含む)を記録します。次に例を示します。
ktpass -princ <protocol/oamserver_host> -pass <mypassword> -mapuser <user from step 1> -out <path_to_filename>

ktpass -princ HTTP/oam11g.example.com@lm.example.com -mapuser oam -pass
examplepw -out c:\temp\oam.keytab

C:\Users\Administrator>ktpass -princ HTTP/oam11g.example.com@LM.EXAMPLE.COM
-mapuser oam -pass welcome1 -out c:\temp\oam.keytab
Targeting domain controller: kdc.lm.example.com
Using legacy password setting method
Successfully mapped HTTP/oam11g.example.com to oam.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to c:\temp\oam.keytab:
Keytab version: 0x502
keysize 80 HTTP/oam11g.example.com@lm.example.com ptype 0 (KRB5_NT_
UNKNOWN) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0xa3a685f89364d4a
5182b028fbe79ac38)

7. 新しく作成したkeytabファイルをOAMサーバーの適切な場所にコピーし、権限が正しいことを確認して、Access Managerを作成したユーザーがこのファイルにアクセスしてktpassコマンドを実行できるようします。

8. 単純なOAMサーバーKerberosのkrb5.confまたはkrb5.ini構成を作成します。次に例を示します。

[libdefaults]
default_realm = lm.example.com
ticket_lifetime = 600
clock_skew = 600

[realms]
lm.example.com = { --
kdc = kdc.lm.example.com
admin_server = kdc.lm.example.com
default_domain = lm.example.com
}
[domain_realm]
lm.example.com =LM.EXAMPLE.COM
.lm.example.com = LM.EXAMPLE.COM

注意:

OAMアカウントは、すべてが信頼する1つのドメイン(lm.example.com)に作成します。これは、lmsib.sprite.comでは必要ありません。

9. keytabファイルと作成したActive DirectoryおよびAccess ManagerのユーザーのSPNを使用して、klistおよびkinitsが機能することを確認し、その結果を記録します。

1. kdestroy

2. klist [-k] [-t <keytab_filename>]。次に例を示します。

bash-3.2$ klist -k -t -K -e FILE:/refresh/home/oam.keytab
Keytab name: FILE:/refresh/home/oam.keytab
KVNO Timestamp Principal
---- ----------------- ---------------------------------------------------
3 12/31/69 19:00:00 HTTP/oam11g.example.com@lm.example.com (ArcFour
with HMAC/md5)(0xa3a685f89364d4a5182b028fbe79ac38)
bash-3.2$

3. kdestroy

4. kinit [-k] [-t <keytab_filename>] [<principal>]。次に例を示します。

klist -k -t -K -e FILE:/refresh/home/oam.keytab

bash-3.2$ kinit -V -k -t /refresh/home/oam.keytab
HTTP/oam11g.example.com@lm.example.com
Authenticated to Kerberos v5

5. klist -e

bash-3.2$ klist -e
Ticket cache: FILE:/tmp/krb5cc_8000
Default principal: HTTP/oam11g.example.com@lm.example.com

Valid starting Expires Service principal
02/25/12 18:46:55 02/25/12 18:56:55 krbtgt/LM.EXAMPLE.COM@LM.EXAMPLE.COM
Etype (skey, tkt): ArcFour with HMAC/md5, AES-256 CTS mode with 96-bit
SHA-1 HMAC

Kerberos 4 ticket cache: /tmp/tkt8000
klist: You have no tickets cached
bash-3.2$

10. 次のように続行します。
成功: 「Oracle固有の前提条件となるタスクの実行」に進みます。

不成功: 停止してこの統合と関係のない問題を解決します。この時点での失敗は、Access Manager WNAを機能できないことを示します。

43.4 Oracle固有の前提条件となるタスクの実行

完全に機能するAccess Managerのデプロイメントが必要です。この項のタスクは、選択する方法に関係なく必要です。関連項目:

- Access Managerの操作の確認

43.4.1 Access Managerの操作の確認

この手順では、アプリケーション・ドメインを構成してリソースを保護するWebGateをインストールして登録します。そして、環境がKerberos以外の認証スキームで機能していることを確認します。

注意:

この章の情報はAccess Managerに基づいています。

関連項目:

2つ以上の管理対象サーバーがクラスタとして動作するように構成された高可用性環境の詳細に関する『Oracle Fusion Middleware高可用性ガイド』

Access Manager環境を検証するには:

1. 第2章の説明に従って、管理者の資格証明を使用してOracle Access Managementコンソールにログインします。

2. デフォルト・アイデンティティ・ストアの接続を確認します。

3. 第13章の説明に従って、Webgate(または11.1.2)をOAMエージェントとして登録してインストールし、自動ポリシー生成を受け入れます。

4. リソースをアプリケーション・ドメインに追加し、リソースを保護する認証ポリシーをKerberos以外の任意の認証スキームを使用するようにカスタマイズします。

5. 構成をテストし、リソース保護およびアクセスが期待どおりに機能することを確認します。

6. 「Kerberosトークンを返すためのブラウザの有効化」に進みます。

43.5 Kerberosトークンを返すためのブラウザの有効化

次の手順を使用して、Kerberosトークンを返すようにInternet ExplorerブラウザまたはMozilla Firefoxブラウザを構成できます。

注意:

Internet Explorerブラウザでは、統合Windows認証はデフォルトで有効になっており、WNAを機能させるためにデフォルト構成を変更する必要はありません。

Internet ExplorerでKerberosトークンを有効化する手順は、次のとおりです。

1. Active Directoryドメイン内のWindowsホストに、ドメイン・ユーザーとしてサインインします。

2. Internet Explorerブラウザを開きます。

3. 「ツール」メニューから「インターネット オプション」をクリックし、「セキュリティ」→「ローカル イントラネット」→「詳細設定」をクリックします。

4. 「詳細設定」タブで、「セキュリティ」セクションの「統合Windows認証を使用する」の横にあるボックスを選択して「OK」をクリックします。

5. Oracle Access Manager CCホストまたはドメイン名をローカル・イントラネット・ゾーンに追加します(http://node.host:portの形式を使用(portは必須ではない))。次に例を示します。

http://oam11g.example.com

6. Internet Explorerブラウザを再起動して、変更を有効にします。

Mozilla FirefoxでKerberosトークンを有効化する手順は、次のとおりです。

1. ブラウザのアドレス・バーに、about:configと入力します。

2. Oracle Access Manager CCホストまたはドメイン名をnetwork.negotiate-auth.trusted-urisの下にnetwork.negotiate-auth.trusted-uris=http://oam11g.example.comとして追加します。

43.6 KerberosPluginとOracle Virtual Directoryの統合

Oracle Virtual Directoryでは、インフラストラクチャまたはアプリケーションを変更することなく、またはその必要性を最小限に抑えながら、LDAP対応のアプリケーションを様々なディレクトリ環境に統合できます。この項では、Oracle Virtual DirectoryとのWNAのためのAccess Manager KerberosPlugin認証を構成するために実行する必要があるタスクを説明します。

この項では、次のトピックと手順について説明します。

タスクの概要: Access Manager KerberosPluginとOracle Virtual Directoryの統合

1. この項では次のタスクを実行します。

- 統合のためのOracle Virtual Directoryの準備

- WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録

- Access Manager KerberosPluginおよびOVDを使用した認証の設定

2. Windowsネイティブ認証のためのAccess Managerの構成

3. Kerberosトークンを返すためのブラウザの有効化

4. Access Managerによって保護されたリソースでのWNAの検証

43.6.1 統合のためのOracle Virtual Directoryの準備

Oracle Virtual Directoryは、アダプタを経由して他のディレクトリと通信します。Oracle Virtual Directoryをアイデンティティ・ストアとして使用し始める前に、使用するディレクトリそれぞれへのアダプタを作成する必要があります。

その手順は、接続先のディレクトリに応じて若干異なります。Oracle Internet Directory、Active Directory、Oracle Directory Server Enterprise Edition(ODSEE)またはOracle Unified Directoryの使用を選択すると、Oracle Identity Managementサーバーのインストールおよび構成時に、必要なアダプタが作成され、構成されます。アダプタの管理の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のIdentity Virtualization Library(libOVD)アダプタの管理に関する項を参照してください。

次の手順では、信頼できるドメインでOAMサーバーのアカウントを作成します。また、完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。

デフォルトでは、Active Directoryはdcを使用して、ルート・コンテキスト識別名を構築します。これが使用中のデプロイメントで異なる場合、それに合わせてアダプタ・ネームスペースを調整します。

この統合のためにOracle Virtual Directoryをデプロイするには:

1. 「Access Managerの操作の確認」の説明に従ってタスクを実行します。

2. 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Oracle Virtual Directoryをインストールします。

3. Oracle Virtual Directoryコンソールで、次のように完全修飾ドメイン名をネームスペースとして使用して、2つのActive Directoryアダプタ(フォレストごとに1つ)を作成します。

1. アダプタ1、EXAMPLEアダプタ・ネームスペース(ドメインDNS lm.example.com):

dc=lm,dc=example,dc=com

2. アダプタ2、SPRITEアダプタ・ネームスペース(ドメインDNS lmsib.sprite.com):

dc=lmsib,dc=sprite,dc=com

4. OAMクラスタをシャットダウンします。

5. AdminServerおよびすべてのOAMサーバーを再起動します。

6. 「WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録」に進みます。

43.6.2 WNAのデフォルト・ストアとしてのOracle Virtual Directoryの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Windowsネイティブ認証と相互運用するAccess Managerのユーザー・ストアとしてOracle Virtual Directoryを登録できます。

Windowsネイティブ認証の場合、ユーザー資格証明はMicrosoft Active Directoryにある必要があります。Access Directoryは、Oracle Virtual Directoryインスタンスで管理できます。Access Managerによるシングル・サインオンの場合、各ユーザー・アイデンティティ・ストアを登録して、Access Managerと連動する必要があります。

通常、userprincipalnameは、Windowsログイン名を反映します。Access ManagerによるWNAの場合、ユーザー検索ベースおよびグループ検索ベースを空白のままにするかまたは前提条件となるタスクを実行中に構成した両方のアダプタに共通の識別名パスを入力します。

前提条件

Active Directory/Kerberosトポロジの準備

Oracle固有の前提条件となるタスクの実行

関連項目:

第4章

Access ManagerにOracle Virtual Directoryを登録するには:

1. Oracle Access Managementコンソールから、「データソース」ノードを開きます。

「システム構成」タブ

「共通構成」セクション

「データソース」ノード

2. 「ユーザー・アイデンティティ・ストア」ノードをクリックし、ツール・バーの「追加」ボタンをクリックします。

3. Oracle Virtual Directoryインスタンスについての必要な値を入力します。次に例を示します。
名前: OVD
LDAP URL: ldap://ovd_host.domain.com:389
プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
資格証明: ********
ユーザー検索ベース:dc=com
ユーザー名属性: userprincipalname
グループ名: cn
グループ検索ベース: dc=com
LDAPプロバイダ: Oracle Virtual Directory

4. デフォルト・ストア: 「デフォルト・ストア」ボタンをクリックし、これをAccess Managerのユーザー・アイデンティティ・ストアにします。

5. 「適用」をクリックして登録を送信し、「確認」ウィンドウを閉じます。

6. AdminServerおよびOAMサーバーを再起動します。

7. 「Access Manager KerberosPluginおよびOVDを使用した認証の設定」に進みます。

43.6.3 Access Manager KerberosPluginおよびOVDを使用した認証の設定

ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。

KerberosPluginは、リソースをリクエストするユーザーの資格証明(kerberosチケット(SPNEGOトークン)の暗号化されたユーザー名)と一致する資格証明マッピング・モジュールです。デフォルトでは、KerberosPluginは、dcコンポーネントを使用してドメインDNS名を対応する識別名にマップします。ただし、マッピングが異なる場合、名前:値のトークンのセミコロン(;)で区切られたリストとして正しいマッピングを指定できます。次に例を示します。

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementコンソールを使用してデフォルトのKerberosPluginのステップをWindowsネイティブ認証の統合を有効にするステップと置き換えることができます。

関連項目:

第11章

OVDのAccess Manager KerberosPluginを設定するには

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「Access Manager」セクション
「認証モジュール」ノード
カスタム認証モジュールノード
KerberosPlugin

2. KerberosPluginページで、「ステップ」タブをクリックします。
「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。

1. stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。

2. 「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。

要素

説明

名前

stepKTA

クラス

KerberosTokenAuthenticator

「ステップの詳細」:

この新しいstepKTAにパラメータKEY_DOMAIN_DNS2DN_MAP(以前作成)が含まれていることを確認し、デプロイメントの値を入力します。

要素

説明

KEY_DOMAIN_DNS2DN_MAP

デプロイメントのActive Directoryフォレスト。次に例を示します。

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

注意: デフォルトでは、DNドメイン名a.b.cは、dc=a、dc=b、dc=cにマップされます。マッピングが異なる場合のみパラメータを指定する必要があります。そうでなければ、これを使用せずデフォルトの動作のままにすることが最善です。

サービス・プリンシパル

HTTP/oam11g.example.com@LM.EXAMPLE.COM

keytab.conf

stepKTAのkeytab.confの場所

krb5.conf

stepKTAのkrb5.confの場所

3. stepUIFの詳細: 次のように構成し、「保存」をクリックします。

要素

説明

KEY_LDAP_FILTER

(samAccountName={KEY_USERNAME})

KEY_IDENTITY_STORE_REF

OVD

KEY_SEARCHBASE_URL

ここは空のままにします

4. stepUIおよびstepUA: 次のように構成し、「保存」します。

KEY_IDENTITY_STORE_REF

OVD

5. 変更を保存します。

6. OAMクラスタを再起動します。

7. 「Windowsネイティブ認証のためのAccess Managerの構成」に進みます。

43.7 Access Manager KerberosPluginと検索フェイルオーバーの統合

Oracle Virtual Directoryデプロイメントが実行不能で、ユーザーを検索するときにある順序または階層に基づいて検索フェイルオーバーを実行することが受け入れられる場合、この項の説明に従ってAccess Managerを構成できます。

タスクの概要: Access Manager KerberosPluginと検索フェイルオーバーの統合

1. 次の前記の項のタスクの完了

- 「Active Directory/Kerberosトポロジの準備」

- 「Oracle固有の前提条件となるタスクの実行」(検索フェイルオーバーに必要ではないこの統合のためのOracle Virtual Directoryの統合に関する項を除く)

- 「Kerberosトークンを返すためのブラウザの有効化」

2. 次の項のタスクの実行

- 「Microsoft Active DirectoryインスタンスのAccess Managerへの登録」

- 「ADGCのためのAccess Manager KerberosPluginの設定」

3. Windowsネイティブ認証のためのAccess Managerの構成

4. 「Access Managerによって保護されたリソースでのWNAの検証」

43.7.1 Microsoft Active DirectoryインスタンスのAccess Managerへの登録

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Oracle Access Managementの個別のユーザー・アイデンティティ・ストアとして各Active Directoryグローバル・カタログ(ADGC)を関連する検索ベースおよびネーミング属性に登録できます。

前提条件

Kerberosサービスをマップするユーザー・アカウント、それらのアカウントのサービス・プリンシパル名(SPN)、およびキー・タブ・ファイルを含む、完全に構成されたMicrosoft Active Directory認証サービスが設定されている必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.3)』を参照してください。

関連項目:

データ・ソースの登録の詳細に関する 第4章

Microsoft Active Directoryグローバル・カタログをAccess Managerに登録するには:

1. Oracle Access Managementコンソールから、「データソース」ノードを開きます。

「システム構成」タブ

「共通構成」セクション

「データソース」ノード

2. 「ユーザー・アイデンティティ・ストア」ノードをクリックし、ツール・バーの「追加」ボタンをクリックします。

3. 最初のADGCについての必要な値を入力します。次に例を示します。
名前: ADGC1-EXAMPLE
LDAP URL: ldap://ADGC1_host.domain.com:389
プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
資格証明: ********
ユーザー検索ベース: dc=lm,dc=example,dc=com
ユーザー名属性: userprincipalname
グループ検索ベース: dc=lm,dc=example,dc=com
LDAPプロバイダ: AD

4. デフォルト・ストア: 「デフォルト・ストア」ボタンをクリックします。

5. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます。

6. これらのステップを繰り返し、適切な検索ベースおよびネーミング属性を備えた2つ目のADGC(ADGC2-SPRITE)を追加します。
名前: ADGC2-SPRITE
LDAP URL: ldap://ADGC2_host.domain.com:389
プリンシパル: cn=Administrator,cn=users,dc=lm,dc=example,dc=com
資格証明: ********
ユーザー検索ベース: dc=lmsib,dc=example,dc=com
ユーザー名属性: userprincipalname
グループ検索ベース: dc=lmsib,dc=example,dc=com
LDAPプロバイダ: AD

7. AdminServerおよびOAMサーバーを再起動します。

8. 「ADGCのためのAccess Manager KerberosPluginの設定」に進みます。

43.7.2 ADGCのためのAccess Manager KerberosPluginの設定

ネイティブ認証モジュールから必要とする十分な柔軟性が提供されない場合、特定の要求を満たすために設計されたプラグインを使用してカスタム認証モジュールを作成できます。

KerberosPluginはリソースを暗号化された「kerberosチケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。デフォルトでは、KerberosPluginは、dcコンポーネントを使用してドメインDNS名を対応する識別名にマップします。ただし、マッピングが異なる場合、名前:値のトークンのセミコロン(;)で区切られたリストとして正しいマッピングを指定できます。次に例を示します。

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、KerberosPluginのステップを作成したADGCを指すステップと置き換えるかまたは更新できます。これらは、その等価物と連動します(最初のステップでADGCが失敗した場合、2つ目のADGCが使用されます)。

前提条件

Active Directory/Kerberosトポロジの準備

Oracle固有の前提条件となるタスクの実行

関連項目:

プラグインの詳細: 第11章

ADGCのためにAccess Manager KerberosPluginを設定するには:

1. Oracle Access Managementコンソールから、次を開きます。
「システム構成」タブ
「Access Manager」セクション
「認証モジュール」ノード
カスタム認証モジュールノード
KerberosPlugin

2. KerberosPluginページで、「ステップ」タブをクリックします。
「ステップ」タブ: ここの説明に従ってstepKTAを置き換えて、「保存」をクリックします。

1. stepKTAをクリックしてから「削除」(x)ボタンをクリックしてこのステップを削除します。

2. 「追加」(+)ボタンをクリックして、次のステップをプラグインに追加します。

要素

説明

名前

stepKTA

クラス

KerberosTokenAuthenticator

新規stepKTAの詳細:

この新しいstepKTAにパラメータKEY_DOMAIN_DNS2DN_MAP(以前作成)が含まれていることを確認し、デプロイメントの値を入力します。

要素

説明

KEY_DOMAIN_DNS2DN_MAP

LM.EXAMPLE.COM:dc=lm,dc=example,dc=com;LMSIB.SPRITE.COM:dc=lmsib,dc=sprite,dc=com

サービス・プリンシパル

HTTP/oam11g.example.com@LM.EXAMPLE.COM

keytab.conf

stepKTAのkeytab.confの場所次に例を示します。

/refresh/home/oam.keytab

krb5.conf

stepKTAのkrb5.confの場所

/etc/krb5.conf

3. stepUIF: ステップ詳細(次のように構成して保存):

要素

説明

KEY_IDENTITY_STORE_REF

ADGC1-ORACLE

KEY_SEARCHBASE_URL

{KEY_USERDOMAIN}

KEY_LDAP_FILTER

(samAccountName={KEY_USERNAME})

4. stepUIおよびstepUA: ステップ詳細(これらのステップを構成して保存):

要素

説明

KEY_IDENTITY_STORE_REF

ADGC1-ORACLE

5. 変更を保存します。

6. stepUIF2の追加: これは連動し、stepUIFが失敗した場合に実行されます。

要素

説明

KEY_IDENTITY_STORE_REF

ADGC2-SPRITE

KEY_SEARCHBASE_URL

{KEY_USERDOMAIN}

KEY_LDAP_FILTER

(samAccountName= {KEY_USERNAME})

7. stepUI2の追加: これは連動し、stepUIが失敗した場合に実行されます。

要素

説明

KEY_IDENTITY_STORE_REF

ADGC2-SPRITE

8. stepUA2の追加: これは、stepUI2が成功したときに実行されます。

要素

説明

KEY_IDENTITY_STORE_REF

それぞれADGC1-EXAMPLEおよびADGC2-SPRITE

9. ステップ詳細の追加: 「共通構成」、「プラグイン」、KerberosTokenAutheticator。
デプロイの値を入力します。

要素

説明

keytab.conf

stepKTAのkeytab.confの場所例: /refresh/home/oam.keytab

krb5.conf

stepKTAのkrb5.confの場所例: /etc/krb5.conf

10. OAMクラスタを再起動します。

11. 「Windowsネイティブ認証のためのAccess Managerの構成」に進みます。

43.8 Windowsネイティブ認証のためのAccess Managerの構成

Oracle Virtual Directoryを使用していてもグローバル・カタログを備えたActive Directoryを使用していても、この項は、ユーザーが実行できるステップを含む次のトピックを提供します。

- Windowsネイティブ認証用の認証スキームの作成

- Windowsネイティブ認証用のAccess Managerポリシーの構成

- Access Manager構成ファイルの確認

43.8.1 Windowsネイティブ認証用の認証スキームの作成

有効なOracle Access Management管理者の資格証明を持つユーザーは、次のタスクを実行して、Windowsネイティブ認証用アプリケーションを保護するポリシーで使用するAccess Managerの認証スキームを定義できます。

前提条件

KerberosPluginとOracle Virtual Directoryの統合

または

Access Manager KerberosPluginと検索フェイルオーバーの統合

関連項目:

認証スキームの詳細: 第16章

WNAのKerberos認証スキームを作成するには:

1. Oracle Access Managementコンソールから、「ポリシー構成」タブを開き、「認証スキーム」ノードを開きます。

2. KerbSchemeを開いてその構成詳細を表示し、次の属性を設定(または確認)します。
「チャレンジ・メソッド」: WNA

「認証モジュール」: KerberosPlugin

3. デプロイメントのKerbSchemeの構成を終了します。

4. 「適用」をクリックして、「確認」ウィンドウを閉じます。

5. 「Windowsネイティブ認証用のAccess Managerポリシーの構成」に進みます。

43.8.2 Windowsネイティブ認証用のAccess Managerポリシーの構成

この手順では、アプリケーション・ドメインおよびポリシーを編集(または作成)し、Windowsネイティブ認証のリソースを保護します。

前提条件

Windowsネイティブ認証用の認証スキームの作成

関連項目:

ポリシー管理の詳細: 第17章

Windowsネイティブ認証のAccess Managerポリシーを設定するには:

1. Oracle Access Managementコンソールから、「ポリシー構成」タブを開き、「アプリケーション・ドメイン」ノードを開きます。

2. 「コンソールを使用したアプリケーション・ドメインおよびポリシーの管理」の説明に従って、必要なアプリケーション・ドメインを開きます(または作成します)。

3. リソース定義: 「ポリシーに追加するリソース定義の追加および管理」の説明に従って、リソース定義をドメインに追加します。

4. 認証ポリシー:

1. 「認証ポリシー」ノードを開き、次の属性を含む必要な認証ポリシーを開きます(または作成します)。
認証スキーム: KerbScheme。更新したKerberosPluginが含まれていることを確認します。

認証スキームとしてKerbSchemeを選択し、更新したKerberosPluginが含まれていることを確認します。

2. 「適用」をクリックして、「確認」ウィンドウを閉じます。

3. 認証ポリシーのリソース: 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の説明に従って、リソースを認証ポリシーに追加します。

4. 必要なレスポンスを加えて認証ポリシーを完了します。

5. 認可ポリシー: 「特定にリソースに対する認可ポリシーの定義」の説明に従って、必要なレスポンスまたは条件を加えて認証ポリシーを完了します。

6. 「Access Manager構成ファイルの確認」に進みます。

43.8.3 Access Manager構成ファイルの確認

oam-config.xmlファイルで、次のものが指定されていることを検証します。

- krb5.confファイルへのパス

- keytabファイルへのパス

- KDCに接続するプリンシパル

例: oam-config.xml

<Setting Name="KerberosModules" Type="htf:map">
<Setting Name="6DBSE52C" Type="htf:map">
<Setting Name="principal"           Type="xsd:string">HTTP/oam11g.example.com@LM.EXAMPLE.COM
</Setting>
<Setting Name="name" Type="xsd:string">XYZKerberosModule</Setting>
<Setting Name="keytabfile"           Type="xsd:string">/refresh/home/oam.keytab
</Setting>
<Setting Name="krbconfigfile" Type="xsd:string">/etc/krb5.conf</Setting>
</Setting>
</Setting>

43.9 Access Managerによって保護されたリソースでのWNAの検証

統合Windows認証(IWA)は、特定のWindowsオペレーティング・システムに含まれているSPNEGO、KerberosおよびNTLMSSPの認証プロトコルを使用するMicrosoft製品と関連付けられています。統合Windows認証(IWA)という用語は、Microsoft Internet Information Services、Internet ExplorerおよびMicrosoftのActive Directoryの間で発生する自動認証プロセス用に使用されます。

注意:

IWAは、HTTPネゴシエート認証、NT認証、NTLM認証、ドメイン認証、Windows統合認証、Windows NTチャレンジ/レスポンス認証、Windows認証など別の名前で呼ばれることもあります。

WNA認証は内部的に行われます。Access Managerと統合すると次のようになります。

- ユーザーは、認証のためにAccess Managerにリダイレクトされます。

- OAMサーバーは、リソースがWNAのチャレンジ・メソッドでAccess Managerによって保護されている場合、wwwネゴシエート・ヘッダーを使用した認証をリクエストします。

- 統合Windows認証(IWA)用に構成されたブラウザは、Kerberos SPNEGOトークンを復号化するためにOAMサーバーに送信します。

- OAMサーバーは、受信したユーザーSPNEGOトークンを復号化(キー・タブを使用)して、ユーザーをCookieとともにリダイレクトしてエージェントに戻し、リソースにアクセスできるようになります。

Access Managerによって保護されたリソースでWNAを検証するには:

1. Active Directoryドメイン内のWindowsシステムに、ドメイン・ユーザーとしてログインします。

2. Access Managerに登録されたホスト対象のActive Directoryに保存されているWindowsドメイン資格証明を使用して、Windows OSクライアントにサインインします。

3. Internet Explorerのブラウザ・ウィンドウを開き、使用中の環境のOAMによって保護されたアプリケーションのURLを入力します。

4. Windowsドメインの資格証明でアプリケーションにログインしていて、追加のログインがないことを確認します。

43.10 WNA構成のトラブルシューティング

この項の内容は次のとおりです。

- Kinitの失敗

- WNA認証スキームを使用して保護されたリソースにアクセスできない

- ユーザー・アイデンティティ・ストアがActive Directoryではない

関連項目:

My Oracle SupportのAccess Manager WNAクイック・スタート・ガイドのナレッジベース・ノート1416903.1(https://support.oracle.com/)

43.10.1 Kinitの失敗

エラー

初期資格証明取得時にKerberosデータベースでクライアントが見つかりません

原因

これはKerberosバージョンの「ユーザーが見つかりません」です。次のいずれかと関係がある場合があります。

- プリンシパル名のミススペルまたはタイプミス

- プリンシパルがKerberosデータベースに追加されなかったためにプリンシパルが存在しない。

- ユーザー名がActive Directoryに存在しないまたはKerberosユーザーとして登録されなかった。

- SPNが一意ではない。

- Active Directory側で1つ以上の重複エントリが見つかった。

解決策

Active Directory管理者にLDAPツリーを検索してもらい、SPNの重複エントリを探して、それを削除する。

43.10.2 WNA認証スキームを使用して保護されたリソースにアクセスできない

WNA認証スキームを使用してAccess Managerによって保護されたリソースにアクセスできません。エラー: 「指定したユーザー名またはパスワードが正しくありません」

エラー

「指定したユーザー名またはパスワードが正しくありません」

43.10.3 ユーザー・アイデンティティ・ストアがActive Directoryではない

原因

Access Managerが使用するアイデンティティ・ストアがWindows Active Directoryを指していない可能性があります。デフォルトでは、アイデンティティ・ストアは組込みLDAPです。

解決策

1. Active Directory(Oracle Access Managementコンソール、システム構成、、データ・ソース、ユーザー・アイデンティティ・ストア)を登録し、ActiveDirectoryを作成します。

2. 「デフォルト・ストアおよびシステム・ストアの設定」で説明するように、Active Directoryをデフォルト・ストアに設定します。

44 JBossとAccess Managerの統合

Oracleは、Access ManagerとJBossのスムーズな統合を実現するために、J2EEタイプのJBossエージェントおよびJBossログイン・モジュールを提供します。この章では、この統合の役に立つ次の情報を提供します。

- JBossとAccess Managerの概要

- 統合トポロジ

- JBoss統合のための環境の準備

- JBoss固有のリソースの保護

- JBossエージェントによるWebアプリケーションの保護

- localhostではなくホスト名にアクセスするためのJBossサーバーの構成

- EJBを保護するためのログイン・モジュールの構成

- Webサービスへのアクセスを保護するためのログイン・モジュールの構成

- JBossエージェントおよびログイン・モジュールのためのロギングの構成

- 構成の検証

44.1 JBossとAccess Managerの概要

JBossアプリケーション・サーバーは、IBM WebSphereアプリケーション・サーバーおよびSAP NetWeaverアプリケーション・サーバーのオープン・ソースの代替手段です。JBossアプリケーション・サーバーおよび関連サービスは、エンタープライズJavaアプリケーション、Webアプリケーション・サービスおよびポータルの開発とデプロイに使用されるJ2EEプラットフォームです。J2EEは、標準化されたモジュラ・コンポーネントの使用を許可し、Javaプラットフォームによるプログラミングの多くの側面の処理を自動的に可能にします。

JBossとの統合のために、Oracleは次のものを用意しています。

- Access Manager JBossエージェント(J2EEタイプ・エージェント)

- 任意のクライアントとともに使用してAccess Managerに対して認証できるJAAS準拠のログイン・モジュール

注意:

Access Manager内でのJBossエージェントによる(またはAccess ManagerによるJBossエージェントへの)特別な処理はありません。

JBossとAccess Managerを統合すると次のことが可能になります。

- Webアプリケーションの保護およびユーザー・シングル・サインオンの確立

- EJB用にログイン・モジュールを構成することによるEJBアクセスの保護

- ログイン・モジュールをWebサービス・ハンドラとともに使用して呼び出し元を認証および認可することによるWebサービスの保護

クライアント・インタフェースはありません。詳細は、次の各項を参照してください。

- Access Manager JBossエージェントによる構成および処理について

- Access Managerログイン・モジュールによる構成および処理について

44.1.1 Access Manager JBossエージェントによる構成および処理について

Access Manager JBossエージェントは、JBossサーバー上で動作する完全対応エージェントです。

このJBossエージェントは、Webgateを使用した(またはWebgateを使用しない)Access Manager Webシングル・サインオン・フローをサポートします。認証と認可は、Access Managerポリシー内で定義されたリソースURLに基づいています。JBossエージェントは、OAMサーバーへのすべての着信リクエストを捕捉し、リクエストされたリソースのアクセス権があるかどうかを確認します。リソースがOAMポリシーによって保護されている場合、JBossエージェントは、リソースにアクセスしようとしているユーザーの認証と認可を開始します。

非認証ユーザーが保護されている任意のリソースへのアクセスをリクエストした場合には、JBossエージェントは必ずユーザーを資格証明コレクタにリダイレクトして、ユーザー名とパスワードを求めます。入力されるユーザー名とパスワードは、OAMサーバーによって認証されます。次に、JBossエージェントは、ユーザーのログイン・モジュールを使用して、JBossコンテナにユーザー・セッションを確立します。ログイン・モジュールは、LDAPディレクトリに問合せ、認証されたユーザー・プリンシパルをフェッチしてサブジェクトを設定します。

JBossエージェントは、OAMサーバーとのアクセスおよび通信に関して、Pure Java ASDKクラスおよびAPIに依存します。JBossエージェントは、javax.servlet.Filterインタフェースを実装します。詳細は、 Oracle Fusion Middleware Oracle Access Management Access Manager Access SDK Java APIリファレンスを参照してください。

JBossエージェントは、OAMサーバーの通信詳細、証明書ストアなどを要求します。これらは、次のように構成できます。

- すべての構成詳細を含むプロパティ・ファイル(このファイルへのパスはフィルタ・パラメータとして設定できます)

- web.xmlのフィルタ構成内に追加されるプロパティ・ファイルの絶対パス

注意:

Oracle Access Management管理者によって定義されるカスタム・ヘッダーは、これらのメソッドを使用してのみ定義できます。

アプリケーション・フィルタは、異なるロギング・レベル(FATAL、ERROR、WARNING、DEBUG、TRACE)でメッセージをログする必要があります。各レベルは、ログされる情報の重大度を降順で示しています。フィルタは、着信メッセージの詳細トレースを1セットとしてログできる必要があります。JBossエージェントおよびログイン・モジュールは、両方とも様々なログ・レベルのメッセージを備えています。同じログ・ファイル(server.log)のロギングの場合、次のようになります。

<category name="<<Component_code_package>>">
<priority value="FINEST" class="org.jboss.logging.log4j.JDKLevel"/>
</category>

たとえば、ASDKの場合、前のタグのカテゴリ名は、次に示すようにoracle.security.am.asdkです。

<category name="<<oracle.security.am.asdk>>">
<priority value="FINEST" class="org.jboss.logging.log4j.JDKLevel"/>
</category>

次の概要では、Access Manager JBossエージェントの機能の処理を説明します。

処理の概要: Access Manager JBossエージェントの機能

1. OAMサーバーを問合せ、リクエストされたリソースが保護されているかどうかを確認します。

2. OAMサーバーを呼び出し、認証スキームを取得します。

3. 保護されているリソースの認証スキームを分析し、リクエストを資格証明コレクタにリダイレクトします。

4. ユーザー資格証明を認証します。

5. 認証成功: OAMサーバーから生成される認証トークンをCookieに設定します。

6. 認証トークン: リクエストを処理する前にトークンの整合性を検証します。保護されているリソースにアクセスすることをユーザーが認可されていることを確認するようにOAMサーバーにリクエストし、それに応じてOAMサーバーからのレスポンスを処理します。

7. ユーザー・リクエストとOAMサーバーのレスポンスに応じて、JBossエージェントは、ユーザー・リクエストのリダイレクト先を識別し、保護されているリソースへのアクセスを許可または拒否します。

44.1.2 Access Managerログイン・モジュールによる構成および処理について

JAAS準拠のOAMログイン・モジュールは、Access Manager javax.security.*パッケージによって提供される、JAAS APIを使用するプラガブルな認証モジュールです。JAAS準拠のAccess Managerログイン・モジュール・インタフェースを使用すると、クライアントは、認証データをサーバーに渡すことができます。ログイン・モジュールは、JBossサーバーおよびアプリケーションによって構成され、モジュールとJBossアプリケーション・サーバーを統合します。

JAAS準拠のAccess Managerログイン・モジュール実装クラスは次のとおりです。

public class OAMLoginModule implements LoginModule

このクラスで必要な標準JAASパッケージはjavax.security.*です。ログイン・モジュール・クラスは、JARファイル($JBOSS_HOME/server/default/lib)に格納されます。

ログイン・モジュールは次の2つのモードで動作します。

- usernamePassword: セキュリティ・アイデンティティと資格証明のペアを形成するユーザー名とパスワードの組合せまたはユーザーと証明書の組合せに基づいてユーザーを認証します。ログイン・モジュールは直接LDAPに問合せしません。かわりに、ログイン・モジュールは、OAM Java ASDKを使用して、OAMサーバーでユーザー資格証明と通信してこれを認証します。ユーザーおよびグループの情報はレスポンスとして取得されます。

- tokenBased: SSOトークンを検証してサブジェクトを設定します。

JAAS準拠のAccess Managerログイン・モジュールは、ユーザー名、パスワードまたはAccess Managerトークンを使用します。このモジュールは、OAMサーバーで(Access Manager Java ASDK APIを使用して)資格証明またはトークンを認証および検証し、OAMサーバーから取得したユーザーおよびグループの情報をJAASサブジェクトに移入します。

JAAS準拠のAccess Managerログイン・モジュール構成

login-config.xmlファイルは、デフォルトのJBossログイン・モジュール構成ファイルです。このログイン・モジュールは、JAASセキュリティ・ドメイン名(OAMLoginModuleなど)を必要とします。情報は、login-config.xmlに名前付きセキュリティ・ドメインのリストとして格納され、それぞれがそのドメイン内での認証に使用する複数のJAASログイン・モジュールを指定します。たとえば、これを手動で追加してから、JBossサーバーを再起動します。

<application-policy name="OAMLoginModule">
<authentication>
<login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
flag="required">
<module-option name="loginType">tokenBased</module-option>
<module-option name="configPath">D:/agentconfig</module-option>
<module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
<module-option name="rolesParam">OAM_GROUPS</module-option>
<module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
</login-module>
</authentication>
</application-policy>

セキュリティ・ドメインおよびデプロイメント記述子

アプリケーションがセキュリティを必要とするときには必ず、ドメイン名を指定して、アプリケーションのJBoss固有のデプロイメント記述子(一方または両方)で使用する必要があります。

- jboss.xml: アプリケーション用のJBoss固有構成を定義します。

- jboss-web.xml: Webアプリケーション用のJBossを定義します。このファイルは、セキュリティ・ドメインを宣言し、WEB-INFフォルダに配置する必要があります。

JAAS準拠のOAMログイン・モジュールは、次の概要で説明するように動作します。

プロセスの概要: usernamePasswordモードのJAAS準拠のOAMログイン・モジュール

1. ログイン情報をフェッチします。

2. JBossエージェントによって収集された資格証明に基づいて、Access Managerでユーザーを認証します。

3. サーバー上のクライアントに対してコンテナ・セッションを作成します。

4. ユーザーIDおよびロールを使用してJAASサブジェクトを設定します。

5. ログアウト時、セッションでサブジェクトのプリンシパル設定をクリアし、サブジェクトのロールに関連付けられている権限の設定を削除します。

トークン・ベース・モードで発生したログイン・モジュール処理がusernamePasswordモードと似ていても、その違いについて次の概要で説明します。

プロセスの概要: tokenBasedモードのJAASの準拠のOAMログイン・モジュール

1. ログイン情報をフェッチします。

2. OAMサーバーから生成されるSSO認証トークンをCookieで検証します。

3. サーバー上のクライアントに対してコンテナ・セッションを作成します。

4. 既存のSSOセッション・トークンを使用してフェッチしたユーザーIDおよびロールを使用してJAASサブジェクトを設定します。

5. ログアウト時、セッションでサブジェクトのプリンシパル設定をクリアし、サブジェクトのロールに関連付けられている権限の設定を削除します。

44.2 統合トポロジ

この項の内容は次のとおりです。

- Access Manager JBossエージェントの機能

- トポロジ: Access ManagerとJBossエージェント

- トポロジ: Webgateを使用して構成されたWebサーバーの背後のJBossエージェント

- サンプル統合トポロジ

44.2.1 Access Manager JBossエージェントの機能

JBossエージェントは、表44-1に記載したコンポーネントから構成されます。各コンポーネントは、Access ASDKを使用してOAMサーバーと通信します。

表44-1 JBossエージェントの構成

コンポーネント

説明

認証バルブ

すべての着信リクエストに対するJBoss認証フェーズの間に呼び出されます。リソースがアプリケーションのWeb記述子のセキュリティ制約によって保護されるとマークを付けられている場合、認証バルブはHTTPセッションにユーザー・プリンシパルがあるかどうかを確認します。

- 有効なユーザーが存在する場合: 認証バルブによって、ユーザー・プリンシパルがアプリケーションのWeb記述子のセキュリティ制約を満たしているかどうか評価されます。制約が満たされている場合、リクエストは処理されます。満たされていない場合は、認可失敗メッセージが表示されます。

- 有効なシングル・サインオンCookie(ObSSOCookie)がある場合(有効なユーザーなし): 認証バルブによって、Access Managerログイン・モジュールを使用してCookieの妥当性が確認されます(さらに、セッションでユーザー・プリンシパルが設定されます)。

- 有効なシングル・サインオンCookie(ObSSOCookie)がない/有効なユーザーがない場合: リソースがAccess Managerポリシーを使用して保護されているとマークを付けられている場合、バルブによってOAMログイン・ページにリダイレクトされます。

認証フィルタ

JBoss認証フェーズに続く各着信リクエストに対して呼び出されます。各着信リクエストに対して、フィルタはトークンがあるかどうか確認します。

- トークンがある場合: フィルタはASDKを使用してトークンを検証します。

- 無効なトークン: フィルタはAccess Managerログイン・ページにリダイレクトします。

Access Managerログイン・モジュール

JBossエージェントによって内部的に使用され、SSOトークンに基づいてユーザーを認証します。

任意のクライアント(スタンドアロンまたはJBossコンテナ内にデプロイされる)は、ログイン・モジュールを使用して、ユーザー名とパスワードまたは有効なトークンに基づいて着信ユーザーを認証できます。

44.2.2 トポロジ: Access ManagerとJBossエージェント

図44-1は、JBossアプリケーション・サーバーにデプロイされた任意のJ2EEアプリケーションに安全にアクセスできる様々なクライアント(ブラウザ、EJBまたはWebサービス)を示しています。JBossエージェントは、このアクセスに対して構成され、JBossアプリケーション・サーバー内にデプロイされます。

図44-1 JBossアプリケーション・サーバーにデプロイされた様々なクライアント

44.2.3 トポロジ: Webgateを使用して構成されたWebサーバーの背後のJBossエージェント

単独での動作に加えて、JBossエージェントは、図44-2に示すように、WebGateを使用して構成されたOracle HTTP Server(プロキシ)と連携しても動作できます。

図44-2 Oracle HTTP Server Webgateを使用してデプロイされたJBossエージェント

アプリケーションは、JBossエージェントによって保護されているJBossアプリケーション・サーバーにデプロイされます。また、リクエストは、WebGateを使用して構成されたOracle HTTP Serverインスタンスを介して着信されます。WebGateとJBossエージェントの両方とも、同じAccess Managerデプロイメントに対して構成されます。ここで、JBossエージェントは、Webgateによって転送されるトークンが有効であることを単純に確認し、WebGateによって確立されるアイデンティティを使用するアイデンティティ・アサータの役割を果たします。

44.2.4 サンプル統合トポロジ

図44-3は、Access ManagerとJBossの統合のためにこの章で使用されているトポロジを説明しています。

図44-3 サンプル統合トポロジ

このデプロイメントの詳細は、「JBoss統合のための環境の準備」で説明します。

ユースケース

図44-3のトポロジは次のことをサポートします。

- Webアプリケーションの保護
このユースケースは、アプリケーション固有かつJBoss固有です。これは、JBossエージェントを備えたAccess Manager SSOおよびJBoss上のWebアプリケーションにアクセスするブラウザの認可ポリシーを使用します(ローカルEJB呼び出しがある場合、これを使用)。

- Access Manager(Host 1)

- JBossアプリケーション・サーバーにホストされたアプリケーション(Host 2)

- リッチJavaクライアントを使用した保護されているEJBの起動
クライアントは、次のようにクライアント・アーキテクチャに応じて様々な方法でEJBにアクセスできます。

1. JBossコンテナのJAAS準拠のAccess Managerログイン・モジュールを構成して、EJBへのアクセスを保護します。クライアントは、JBoss固有のメカニズムを利用して、Access Manager SSOトークンをJBossコンテナに伝播できます。
クライアントは、すでに取得したAccess Manager SSOトークンまたはJAAS準拠のAccess Managerログイン・モジュールのいずれかを使用して、ユーザーの資格証明に基づいてSSOトークンを取得できます。

2. または、リッチJavaクライアントに対して公開されているカスタムHTTP Webサーバー・ベースのAccess Manager認証サービスを使用してAccess Manager SSOトークンを取得できます。

- Webサービス・プロバイダ(WSP)としてのEJB呼び出し
JAAS準拠のAccess Managerログイン・モジュールは、Webサービス・プロバイダ側で構成して、ユーザー名とパスワードまたはSSOトークンを検証できます。

代替手段: Webサービス消費(WSC)でユーザー名しか利用できない場合、SAMLトークンを要求するWSPが必要であり、そのトークンをユーザー名をアサートするセキュリティ・トークン・サービスによって発行します。続いて、ユーザー名のみの拡張アサーション機能によってJAAS準拠のAccess Managerログイン・モジュールを呼び出します。

- JAAS準拠のAccess Managerログイン・モジュールを使用したEJBアクセスの保護(Host 2)

- JBossサーバーへのEJBアプリケーションのホスト(Host 2)

- Access Manager(Host 1)

この章の後半では、この統合を完了する方法を説明します。

44.3 JBoss統合のための環境の準備

次の手順では、JBossアプリケーション・サーバーとAccess Managerを統合するための環境の準備方法を説明します。これには次のものが含まれます。

- Oracle Access ManagementコンソールおよびOAMサーバー

- JBoss Application Server 5.1.0

- Access Manager Access SDK

- Access Manager Jbossエージェント

JBossアプリケーション・サーバーとAccess Managerの統合を準備するには:

1. 次のサイトで最新のサポート情報を確認します。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

2. Host 1:

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Access Managerをインストールします。

3. Host 2:

1. JBossインストレーション・ガイドの説明に従って、JBoss 5.1.0アプリケーション・サーバーをインストールします。

2. JBossのserver.xmlを編集して、<Engine name="jboss.web" defaultHost="localhost">を<Engine name="jboss.web" defaultHost="0.0.0.0">に変更します。次に例を示します。
JBoss_install_directory\server\default\deploy\jbossweb.sar\server.xml

次から

<Engine name="jboss.web" defaultHost="localhost">

次へ

<Engine name="jboss.web" defaultHost="0.0.0.0">

4. Host 2: 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Access Manager Access SDKをインストールします。

5. Host 2: OAM JBossエージェントをインストールします。次に例を示します。

1. oam-j2eeagent.zipを抽出します。
次から

/agentconfig/oam_config.propertiesファイル

2. oam-authenticatorvalve.jarとj2eeagent.jarをコピーします。
次へ

JBoss_install_directory\server\default\lib

6. 「JBoss固有のリソースの保護」に進みます。

44.4 JBoss固有のリソースの保護

このタスクは、JBoss固有で、すべてのJBoss統合ユースケース(アプリケーション、WebサーバーまたはEJBの保護)で必要です。

この項では、エージェント登録の作成方法およびリソースを追加して認可ポリシーを構成し、Access Manager JBossエージェントで使用する方法を説明します。詳細は、次の章または項を参照してください。

- 自動ポリシー作成を使用したJBossエージェントの登録

- JBossリソース保護のためのカスタム・ポリシーの作成

44.4.1 自動ポリシー作成を使用したJBossエージェントの登録

このタスクでは、ここで説明するOracle Access Managementコンソールまたは『Oracle Fusion Middleware Oracle Access Management管理者ガイド』で説明されているリモート登録のいずれかを使用できます。

Access ManagerとJBoss Agentの通信には、オープン、簡易または証明書のセキュリティ・モードを使用できます。簡易モードまたは証明書モードを使用するようにJBossエージェントを構成すると、Java ASDKは同じモードで動作します。登録中、新しいファイル・システム・ディレクトリがOracle Access Managementコンソール・ホスト(AdminServer)のエージェント用に作成されます。登録後、アーティファクトを次のエージェントのディレクトリ・パスにコピーします。

- ObAccessClient.xml

- password.xml(簡易モードまたは証明書モードのみ)

- oamclient-keystore.jks(手順を使用して作成。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照)

次の手順で、変数を使用している環境の値に置き換えます。この例では、証明書モードを使用します。使用しているデプロイメントとは異なる場合があります。

関連項目:

第22章

10g OAMエージェントの新規登録を作成するには:

1. Oracle Access Managementコンソール(host 1)に移動し、管理者の資格証明を使用してログインします。次に例を示します。

https://host1:port/oamconsole
User: adminuserID
Password ********

2. 「ようこそ」ページのSSOエージェントパネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

3. 「OAMエージェントの作成」ページで、次の項目(および必要な詳細)を入力し、このOAMエージェントを登録します。次に例を示します。

- 名前: JBoss

- セキュリティ: 証明書

- ユーザー定義パラメータ

logoutRedirectUrl=http://OAM_Server.domain.com:14100/oam/server/logout

4. 「保護されているリソース・リスト」: この表で「追加」(+)ボタンをクリックして、デフォルトの認証ポリシーおよび認可ポリシーで保護するリソースを入力します。

/Authen/Basic
/Authen/SSOToken

5. 「ポリシーの自動作成」: 新規ポリシーおよびアプリケーション・ドメインの作成を確認します。

6. 「適用」をクリックして、登録を送信します。

7. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

8. ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。

9. ObAccessClient.xmlをAdminServerからJBossエージェント・インストール・ディレクトリ・パスにコピーします。
コピー元: WLS_HOME/middleware/user_projects/domains/base_domain/output/AGENTNAME

コピー先: D:\agentconfig

10. 「JBossリソース保護のためのカスタム・ポリシーの作成」に進みます。

44.4.2 JBossリソース保護のためのカスタム・ポリシーの作成

このタスクでは、カスタム認可ポリシーを作成し、ユーザー・グループをヘッダー変数として返すというレスポンスを追加します。たとえば、レスポンスにOAM_GROUPS(値$user.groupsを含む)という名前を付けます。

注意:

このカスタム認可ポリシーでは、このポリシーの単一の目的が認可ユーザーにレスポンスを提供することであるため、成功と失敗のリダイレクトURLは不要です。リダイレクトURLが提供されても、JBossエージェントまたはログイン・モジュールのロジックの処理ではリダイレクトは発生しません。

関連項目:

第17章

JBossアプリケーション・ドメインがコンソールで開いている場合にはステップ1をスキップします。

JBossエージェント固有のリソースを保護するためのカスタム認可ポリシーを作成するには:

1. Oracle Access Managementコンソールの「ポリシー構成」タブから、JBossの「アプリケーション・ドメイン」を開きます。
「アプリケーション・ドメイン」
JBoss

2. 認可ポリシー:

1. 「認可ポリシー」ノードをクリックし、「作成」(+)ボタンをクリックします。

2. 「サマリー」タブの「名前」フィールドに一意の名前を入力します。次に例を示します。
カスタム認可ポリシー

3. リソースの追加: JBossエージェント固有のリソースは、エージェント登録中に定義されました。

1. 「認可ポリシー」ページの「リソース」タブをクリックします。

2. 「追加」(+)ボタンをクリックします。

3. 「検索」ボタンをクリックします。

4. リストからURLを選択し、「選択済の追加」をクリックします。

/Authen/Basic

5. ステップaからdを繰り返して次の項目を追加します。

/Authen/SSOToken

6. 「適用」をクリックします。

4. レスポンスの追加: 「レスポンス」タブをクリックし、「追加」(+)ボタンをクリックし、次の手順を実行します。

- 「名前」フィールドに、このレスポンスの一意の名前(OAM_GROUPS)を入力します。

- 「タイプ」リストから、レスポンス・タイプ(「ヘッダー」)を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。例: $user.groups

5. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

6. 使用中のデプロイメントに適切なトピックに進みます。

- JBossエージェントによるWebアプリケーションの保護

- EJBを保護するためのログイン・モジュールの構成

- Webサービスへのアクセスを保護するためのログイン・モジュールの構成

44.5 JBossエージェントによるWebアプリケーションの保護

この項では、JBossエージェントでWebアプリケーションを保護するために必要な次のタスクを説明します。

- JBossエージェントの構成プロパティの作成

- 認証バルブの構成

- アプリケーションのweb.xmlファイルへのフィルタのマッピング

- Access Managerポリシーを使用するためのJBossログイン・モジュールの構成

前提条件

通常どおりにアプリケーションをデプロイします。

44.5.1 JBossエージェントの構成プロパティの作成

このタスクでは、Jbossエージェント登録アーティファクトをAdminServerからJBossホストにコピーし、後で参照するフィルタ構成プロパティ・ファイルを作成します。

注意:

JBossエージェントは、登録したJBossエージェントと同じモードで動作する11g Java ASDKに依存します。

JBossエージェントには、多くの重要なプロパティを定義する構成ファイル(oam_config.properties)が必要です。これらには、エージェントの登録アーティファクトへのファイル・システム・パス(ObAccessClient.xml)、JBossサーバーのログイン構成ファイルで定義されるセキュリティ・ドメイン、認証中にJBossエージェントに返されるパラメータと値およびリクエストにauthTokenがあるかどうかを確認するオプションの属性が含まれます。

JBossエージェントの構成プロパティを作成するには:

1. ガイドとして次のサンプルを使用して、oam_config.propertiesという名前のJBossエージェント構成ファイルを作成します。

##Path of the folder containing the ObAccessClient.xml
configPath=D:\\agentconfig

##Name of the security domain as configured in JBoss's login-config.xml
realmName=oamrealm

##Optional. If not specified then defaults to /Authen/Basic
##publicAuthnResourceName=/Authen/Basic

##Optional. If not specified then defaults to http
##publicAuthnResourceType=http

##Optional. If not specified then defaults to GET
##publicAuthnResourceOperation=GET

##Optional. If not specified then defaults to /Authen/SSOToken
##publicAuthzResourceName=/Authen/SSOToken

##Optional. If not specified then defaults to http
##publicAuthzResourceType=http

##Optional. If not specified then defaults to GET
##publicAuthzResourceOperation=GET

rolesParam=OAM_GROUPS

##Optional. This attribute is responsible to check whether the credential in
##the subject / callback handler is an authn token. Defaults to authnToken.
authToken=authToken

####################################
##### OAM logout related properties #####
####################################
##Host name of the OAM 11g Server

##Managed server port number of the OAM 11g Server

2. oam_config.propertiesをJBossホストに保存します。

/agentconfig/oam_config.properties

3. 「認証バルブの構成」に進みます。

44.5.2 認証バルブの構成

この手順を実行して、認証バルブを構成する必要があります。このタスクの実行には2つの方法があります。使用中の環境に最適な方法を選択します。

- 認証バルブをcontext.xmlに追加するには: このグローバル構成では、認証バルブによって、Jbossエージェントへのすべてのリクエストが捕捉されます。

- バルブをアプリケーションのデプロイメントに追加するには: この構成では、該当するアプリケーションのみに影響します(認証バルブによって、この特定のアプリケーションからのリクエストのみが捕捉されます)。

認証バルブをcontext.xmlに追加するには:

1. JBossエージェントを編集するために、次の場所にあるcontext.xmlファイルを探して開きます。

JBoss_install_dir\server\default\deploy\jbossweb.sar\context.xml

2. 次のバルブ・エントリを追加してファイルを保存します。

<Valve className="oracle.security.am.agent.common.authenticator.OAMAuthenticatorValve" configFile="<full_path_to_oamagent_config_properties_file> " />

3. 「アプリケーションのweb.xmlファイルへのフィルタのマッピング」.

グローバル・ユースのために認証バルブをcontext.xmlに追加するのではなく、かわりに次のタスクを実行してcontext.xmlをアプリケーションのデプロイメントの一部として追加できます。

バルブをアプリケーションのデプロイメントに追加するには:

1. 新規のcontext.xmlファイルを作成して、これをweb.xmlを含むWEB-INFに格納します。

JBoss_install_dir\server\default\deploy\jbossweb.sar\context.xml

2. 次のバルブ・エントリを追加します。

<?xml version="1.0" encoding="UTF-8"?>

<Context privileged="true">
<Valve className="oracle.security.am.agent.common.authenticator.OAMAuthenticatorValve" configFile="<full_path_to_oamagent_config_properties_file> " />

</Context>

3. アプリケーションを再デプロイします。

4. 「アプリケーションのweb.xmlファイルへのフィルタのマッピング」.

44.5.3 アプリケーションのweb.xmlファイルへのフィルタのマッピング

この手順では、この統合のフィルタ・マッピングをアプリケーションのweb.xmlに追加します。フィルタの構成プロパティ・ファイルの名前も追加します。

フィルタ・マッピングをweb.xmlに追加するには:

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

my_app/WEB-INF/web.xml

2. 次のフィルタ・マッピングをアプリケーションのweb.xmlに追加します。次に例を示します。

<filter>
<filter-name>OAMFilterAgent</filter-name>
<filter-class>
oracle.security.am.agent.common.filter.OAMAuthenticationFilter
</filter-class>
<init-param>
<param-name>configFile</param-name>
<param-value>D:/oam_config.properties</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>OAMFilterAgent</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

3. ファイルを保存します。

4. Access Managerポリシーを使用するためのJBossログイン・モジュールの構成に進みます。

44.5.4 Access Managerポリシーを使用するためのJBossログイン・モジュールの構成

この手順では、Access Managerポリシーを使用するためにJBossに必要なログイン・モジュール・エントリを説明します。

フィルタ・マッピングをweb.xmlに追加した後、アプリケーションを再デプロイし、JBossサーバーを起動します。

注意:

-b 0.0.0.0を使用してJBossサーバーを起動すると、ユーザーは、localhost / 127.0.0.1ではなくホスト名を使用してサーバーにアクセスできます。このパラメータを使用しないと、localhost / 127.0.0.1またはホスト名を使用してJBossサーバーにアクセスできます。

JBossでOAMポリシーを使用できるようにするログイン・モジュールを構成するには:

1. login-config.xmlファイルを探して開きます。

JBoss_install_dir\server\default\conf\login-config.xml

2. 次のように、ログイン・モジュールの新しいエントリを追加します。

<application-policy name="oamrealm">
<authentication>
<login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"       flag="required">
<module-option name="loginType">tokenBased</module-option>
<module-option name="configPath">D:/agentconfig</module-option>
<module-option>
<module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
<module-option name="rolesParam">OAM_GROUPS</module-option>
<module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
</login-module>
</authentication>
</application-policy>

3. アプリケーションをデプロイします。

4. 次のコマンドを使用して、次のようにJBossを起動します。

JBoss_install_dir\bin\run –b 0.0.0.0

「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

44.6 localhostではなくホスト名にアクセスするためのJBossサーバーの構成

この手順はオプションです。localhost/127.0.0.1ではなくホスト名を使用してJBossサーバーにアクセスする場合のみこれを実行します。

注意:

-b 0.0.0.0を使用してJBossサーバーを起動すると、ユーザーは、localhost / 127.0.0.1ではなくホスト名を使用してサーバーにアクセスできます。このようにしないと、localhost / 127.0.0.1またはホスト名を使用してJBossサーバーにアクセスできます。

ホスト名を使用してJBossサーバーにアクセスするには:

1. JBossサービス・ホスト上で、次のパスにあるserver.xmlファイルを探します。

JBoss_install_dir\server\default\deploy\jbossweb.sar\server.xml

2. server.xmlを編集して、デフォルトのホストを次のように変更します。
変更前:

<Engine name="jboss.web" defaultHost="localhost">

変更後:

<Engine name="jboss.web" defaultHost="defaultHost="0.0.0.0">

3. server.xmlを保存します。

44.7 EJBを保護するためのログイン・モジュールの構成

このタスクは、次のトピックで説明するように、サーバー側とクライアント側の両方の構成と関連します。

- EJBを保護するためのサーバーの構成

- EJBを保護するためのクライアント側の構成

44.7.1 EJBを保護するためのサーバーの構成

サーバー側では、セキュリティ・ドメイン注釈をEJBに追加し、記述子をjboss.xmlに追加する必要があります。新規エントリもログイン・モジュールのJBossサーバー構成ファイルに追加します。

ロールに基づいてEJB、WebアプリケーションまたはWebサービスを保護するには、次のようにlogin-config.xmlに追加の構成を行う必要があります。

<module-option name="rolesParam">OAM_GROUPS</module-option>

ここで、OAM_GROUPSは、「JBossリソース保護のためのカスタム・ポリシーの作成」で構成したレスポンスです。

前のステップで構成したエージェントをまたは新規エージェントのいずれかを使用できます。

注意:

新規エージェントを使用するには、ObAccessClient.xmlをJBossホスト上の/agentディレクトリから別のディレクトリにコピーする必要があります。

EJBを保護するためにサーバーを構成するには:

1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

- コピー元: WLS_HOME/middleware/user_projects/domains/base_domain/output/agent_name.

- コピー先: JBossホスト上のディレクトリ

2. @SecurityDomain("oamrealm")注釈をEJBに追加します。たとえば、EJBクラスがDemoEJBの場合、次の注釈をコード・レベルで追加する必要があります。

import org.jboss.security.annotation.SecurityDomain;

@SecurityDomain("oamrealm")
public class DemoEJB{ ... }

3. オプション: 次の記述子をjboss.xmlファイルに追加してセキュリティ・ドメインを定義します。

META-INF/jboss.xml

<jboss>
<security-domain>java:/jaas/myother</security-domain>
</jboss>

注意:

セキュリティ・ドメイン注釈に関連付けられた名前は、ステップ4の説明に従って、使用するログイン・モジュールで指定する必要があります。関連項目: Access Managerポリシーを使用するためのJBossログイン・モジュールの構成。

4. JBossサーバーのログイン構成: ログイン・モジュール・クラス名のエントリを追加します。これは、ログイン・メカニズムの一部である必要があります。
JBoss_install_dir\server\default\conf\login-config.xml

<application-policy name="EJBRealm">
<authentication>
<login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
flag="required">
<module-option name="loginType">tokenBased</module-option>
<module-option name="configPath">D:/agentconfig</module-option>
<module-option name="rolesParam">OAM_GROUPS</module-option>
<module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
<module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
</login-module>
</authentication>
</application-policy>

5. アプリケーションをデプロイします。

6. 次のコマンドを使用してJBossを起動します。

JBoss_install_dir\bin\run –b 0.0.0.0

「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

7. tに進みます。

44.7.2 EJBを保護するためのクライアント側の構成

この手順では、クライアント・ログイン構成ファイルの作成方法を説明します。

EJBを保護するためにログイン・モジュールのクライアント側を構成するには:

1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

- 新規エージェント: MW_HOME/middleware/user_projects/domains/base_domain/output/agent_nameからエージェント・ホスト上のフォルダ。

- 既存のエージェント: JBossホスト上の場所からエージェント・ホスト上の別のディレクトリ。

2. クライアント・ホスト上で、次のようにクライアント・ログイン構成テキスト・ファイルを作成します。

oamauth {
oracle.security.am.agent.common.jaas.login.OAMLoginModule required
loginType="usernamePassword   "
configPath="D:/agentconfig"
publicAuthzResourceName="/Authen/Basic"
publicAuthzResourceName="/Authen/SSOToken";
};

3. 次のコードをエントリに追加し、ログイン・モジュールを構成してアイデンティティをEJBコンテナに伝播します。

propagate {
org.jboss.security.ClientLoginModule required
restore-login-identity="true";
};

4. ファイルを保存します。

注意:

リッチ・クライアントからEJBを起動している間にステップ5を実行し、Access Managerによって認証が実行され(Pure Java ASDKを使用)、資格証明をEJBアプリケーション・サーバーに伝播します。

5. リッチ・クライアント: EJBをクライアント側から起動する前に次のコードをクライアント・コードに追加します。

System.setProperty("java.security.auth.login.config", authFile);
MyCallbackHandler handler = new MyCallbackHandler(<USERNAME>,<PASSWORD>);
LoginContext lc = new LoginContext("oamauth", handler);
lc.login();
//Fetch the private credentials of type String.class
Set<String> set = lc.getSubject().getPrivateCredentials(String.class);

//Set the SSO Token in callback handler along with the username
handler = new MyCallbackHandler(<USERNAME>, set.iterator().next());
LoginContext lc2 = new LoginContext("propagate", handler);
lc2.login();

44.8 Webサービスへのアクセスを保護するためのログイン・モジュールの構成

Webサービス・プロバイダは、Webサービスの呼び出しにセキュリティを適用するために、着信WebサービスSOAPメッセージを捕捉して処理する様々なメカニズムの1つを提供する場合があります。

このタスクは、次のトピックで説明するように、サーバー側とクライアント側の両方の構成と関連します。

- Webサービスへのアクセスを保護するためのサーバーの構成

- Webサービスへのアクセスを保護するためのクライアントの構成

44.8.1 Webサービスへのアクセスを保護するためのサーバーの構成

Webサービスへのアクセスを保護するためのサーバーの構成には、エージェント登録アーティファクトをコピーし、Webサービス・セキュリティのためのAccess Manager JAAS準拠のログイン・モジュールをJBossサーバーのログイン構成ファイルに追加することが含まれます。

前のステップで構成したエージェントをまたは新規エージェントのいずれかを使用できます。新規エージェントを使用するには、ObAccessClient.xmlをJBossホスト上の/agentディレクトリからこのホスト上の別のディレクトリにコピーする必要があります。

Webサービスの作成には複数のフレームワークの任意のものを使用できるため、Webサービスを構成またはデプロイする特定の詳細を示すことはしません。JBossコンテナ上にデプロイされるWebサービスのプロバイダは、次の一般的なガイドラインに従う必要があります。

- OAM SSOトークンを取得するためにクライアントによって挿入された特定のヘッダーを探す機能を組み込む。

- OAM SSOトークンを検証するためにOAM JAASログイン・モジュールを使用する。

- 任意のEJBセッションBeanがWebサービスとして公開されている場合、JBoss固有のJAASログイン・モジュールClientLoginModuleを使用して、OAMトークンをEJBコンテナに伝播する必要がある。

Webサービスへのアクセスを保護するためにサーバーを構成するには:

1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

- 既存のエージェント: JBossホスト上の場所からエージェント・ホスト上の別のディレクトリ。

- 新規エージェント: MW_HOME/middleware/user_projects/domains/base_domain/output/agent_nameからエージェント・ホスト上の別のディレクトリ。

2. Webサービス(理想的には.wsddファイル)を使用してSOAPハンドラを登録します。
WSスタブが作成されアプリケーションのWEB-INFフォルダ内に配置されるときに、.wsddファイルが生成されます。

3. JBossサーバーのログイン構成ファイルを編集して、次のようにWebサービス・セキュリティのためにAccess Manager JAAS準拠のログイン・モジュールのエントリを追加します。
JBoss_install_dir\server\default\conf\login-config.xml

<application-policy name="WSRealm">
<authentication>
<login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
flag="required">
<module-option name="loginType">tokenBased</module-option>
<module-option name="configPath">D:/agentconfig</module-option>
<module-option name="rolesParam">OAM_GROUPS</module-option>
<module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
<module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
</login-module>
</authentication>
</application-policy>

4. JBossサーバーのログイン構成ファイルを保存します。

5. アプリケーションをデプロイします。

6. 次のコマンドを使用してJBossを起動します。

JBoss_install_dir\bin\run –b 0.0.0.0

「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

7. 「Webサービスへのアクセスを保護するためのクライアントの構成」に進みます。

44.8.2 Webサービスへのアクセスを保護するためのクライアントの構成

このタスクでは、OAMサーバーとのユーザー認証を構成し、SOAPメッセージに対して、SSOトークンを含むセキュリティ・ヘッダー・エレメントを作成します。

注意:

理想的には、このステップは、Webサービス・メソッドを呼び出す前に実行します。つまり、このコードは、Webサービスの呼び出し中にクライアント・コードに追加する必要があります。

Webサービスへのアクセスを保護するためにクライアントを構成するには:

1. WSクライアント上: OAMサーバーとのユーザー認証を実行し、SOAPメッセージに対して、SSOトークンを含むセキュリティ・ヘッダー・エレメントを作成します。

2. 通常どおりにWebサービスを呼び出します。

3. 「JBossエージェントおよびログイン・モジュールのためのロギングの構成」に進みます。

44.9 JBossエージェントおよびログイン・モジュールのためのロギングの構成

JBossエージェントおよびログイン・モジュールは、両方とも様々なログ・レベルでログイン・メッセージを備えています。これらのメッセージをログするには、この手順の説明に従ってjboss-log4j.xmlファイルを編集する必要があります。

JBossエージェントおよびログイン・モジュールのためにロギングを構成するには:

1. 次のパスで、jobss-log4j.xmlファイルを探します。

$JBOSS_HOME/server/default/conf/jboss-log4j.xml

2. エディタでファイルを開き、次の情報を追加します。

<appender name="J2EEAGENT" class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/j2eeagent.log"/>
<param name="Append" value="true"/>
<param name="DatePattern" value="'.'yyyy-MM-dd"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
</layout>
</appender>

<category name="oracle.security.am.agent.common">
<appender-ref ref="J2EEAGENT"/>
</category>

<root>
...
<appender-ref ref="J2EEAGENT"/>
</root>

3. ファイルを保存します。

44.10 構成の検証

構成を検証する特定のメカニズムはありません。ただし、構成が正しく機能しているかどうかを手動で判定できます。

構成を検証するには:

1. 認可ユーザー: Webサービスの呼び出しを認可されたユーザーに対して生成されたSSOトークンを提供してWebサービスを手動で呼び出します。

- 成功: 認可ユーザーはアクセスを付与されます。

- 失敗: 認可ユーザーはアクセスを拒否されます。

- エラー: 構成は正しくありません。OAMサーバー・ログでログイン・モジュールによって生成されたエントリを確認します。

2. 未認可ユーザー: Webサービスを手動で呼び出し、未認可ユーザー用のSSOトークンを提供します。

- 成功: 未認可ユーザーはアクセスを拒否されます。

- 失敗: 未認可ユーザーはアクセスを付与されます。

- エラー: エラーが発生した場合、構成は正しくありません。OAMサーバー・ログでログイン・モジュールによって生成されたエントリを確認します。

45 Microsoft SharePoint Server 2010とAccess Managerの統合

この章では、Access Managerと10g WebgateおよびMicrosoft SharePoint Server 2010を統合する方法を説明します。内容は次のとおりです。

- このリリースの新機能

- SharePoint Server 2010との統合の概要

- 統合の要件

- SharePoint 2010との統合の準備

- Microsoft SharePoint Server 2010との統合

- Microsoft Windowsの偽装の設定

- SharePoint Serverの統合の完了

- LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

- Officeドキュメントのためのシングル・サインオンの構成

- Microsoft SharePoint Server 2010のためのシングル・サインオフの構成

- Access ManagerとWindowsネイティブ認証の設定

- ディレクトリ間のユーザー・プロファイルの同期化

- 統合のテスト

- トラブルシューティング

注意:

特に明記しないかぎり、この章のすべての詳細は、OAM偽装プラグインを使用したMicrosoft SharePoint Server 2010およびLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010とのAccess Managerの統合に同様に適用されます。

45.1 このリリースの新機能

この章には、次の新しい情報が含まれます。

- Microsoft SharePoint Server 2010との統合

- LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

- Access Manager WNAを使用したMicrosoft SharePoint Server 2010との統合

Access ManagerとSharePoint 2010との統合をサポートすることによって、次の機能が可能になります。

- Access Managerを使用したSSOログインの前にユーザーがSharePoint 2010にアクセスするとき、ユーザーにはAccess Manager SSOログイン資格証明を求めるプロンプトが表示されます。

- 有効なAccess Managerログイン・セッションを持つユーザーがSharePointドキュメントにアクセスするとき、SharePointによって確立される必要があります(ログインしてSharePointで認証される)。Access Managerセッションが確立されると、SharePointによってLDAPメンバーシップ・プロバイダ、OAM WNAおよび偽装を使用したAccess ManagerとSharePointの統合も実行されます。認証ステータスに基づいて、SharePointは、SharePointに格納されているドキュメントへのアクセスを許可または拒否します。

- ユーザーがブラウザを使用してOfficeドキュメントをSharePointから開くとき、SSOセッションはMS Officeプログラムに永続化し、MS Officeプログラムを介したドキュメントへのアクセスが維持されるようにする必要があります。「Officeドキュメントのためのシングル・サインオンの構成」を参照してください。

- Access Manager 10gとのShare point 2010の統合によってすべての機能を備えたパリティが提供され、Access Managerへのアップグレードが容易になります。

注意:

11g WebgatesはIIS Webサーバーではサポートされていません。この統合には、IIS対応10g Webgateのみ使用できます。

45.2 SharePoint Server 2010との統合の概要

SharePoint Serverは、Windows Server Microsoft Internet Information Services (IIS)およびWindows SharePoint Services (WSS)上に構築されたMicrosoft所有の安全でスケーラブルなエンタープライズ・ポータル・サーバーです。SharePoint 2010は、通常、Webコンテンツおよびドキュメント管理システムと関連付けられています。SharePoint Serverは、Microsoft IIS Webサーバーと連動して、コラボレーション、ファイル共有、Webデータベース、ソーシャル・ネットワークおよびWeb公開のためのサイトを生成します。WSS機能に加えて、SharePoint Serverは、追加の機能(ニュースとトピック、MySiteの個人ビューと公開ビューなど)を組み込んでいます。

Microsoft SharePoint Server 2010は、コンテンツ、ビジネス・プロセスおよび情報共有の制御を拡張します。Microsoft SharePoint Server 2010によって、ドキュメント、ファイル、Webコンテンツおよび電子メールの一元化されたアクセスおよび制御が提供され、コラボレーション作業のためのユーザーによるポータルへのファイルの送信が可能になります。

SharePointサーバー・ファームは、Webサイト、ポータル、イントラネット、エクストラネット、インターネット・サイト、Webコンテンツ管理システム、検索エンジン、Wiki、ブログ、ソーシャル・ネットワーク、ビジネス・インテリジェンス、ワークフローをホストでき、またWebアプリケーション開発用のフレームワークを提供します。

Microsoft SharePoint Server 2010と統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理します。このことによって、Access ManagerとSharePoint Serverの間のシングル・サインオンが可能になります。

SharePoint 2010は、次の認証メソッドをサポートします。

- フォーム・ベースの認証

- 偽装ベースの認証

- Windows認証: ユーザーに関する情報がActive Directoryサーバーに格納されている構成に対してのみ使用

この章の統合では、Microsoft SharePoint Server 2010リソースおよびその他すべてのAccess Managerによって保護されているリソースへのシングル・サインオンを提供します。詳細は、次を参照してください。

- Windowsの偽装について

- この統合でのフォーム・ベースの認証について

- Windowsの偽装およびSharePoint 2010の統合を使用した認証について

- Access ManagerとWindowsネイティブ認証について

45.2.1 Windowsの偽装について

特に明記しないかぎり、この章で説明する統合は、Windowsの偽装に依存します。

Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、Microsoft SharePoint Server 2010のターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。

偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがアクセス・システム・ドメイン内のリソースであるかのように実行されます。

注意:

Windowsの偽装は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合時には使用されません。

45.2.2 この統合でのフォーム・ベースの認証について

3つの認証メソッドのいずれかを使用してAccess ManagerとSharePoint 2010を統合できます。LDAPサーバー(Sun Directory Serverとインスタンス用Active Directory)の一般的な使用の場合、統合に任意のLDAPサーバーを組み込めます。

SharePoint 2010のフォーム・ベースの認証は要求対応型です。ユーザーがSharePointのRelying Party(RP)の「Formsログイン」ページに資格証明を入力するとき、これらはSharePointのSecurity Token Service(STS)に渡されます。SharePoint STSは、そのメンバーシップ・プロバイダに対してユーザーを認証し、SharePoint RPに渡すSAMLトークンを生成します。SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

フォーム・ベースの認証では、WebgateはISAPIフィルタとして構成されます。SharePoint RPのフォーム・ログイン・ページは、ユーザーがSharePoint RPによって資格証明の入力を求められないようにカスタマイズされます。また、メンバーシップ・プロバイダは、Webgateによって設定されたObSSOCookieのみを検証してユーザーを認証するようにカスタマイズされます。

次の概要では、フォーム・ベースの認証を使用してこの統合の認証フローを説明します。

プロセス概要: フォーム・ベースの認証を使用したリクエスト処理

1. ユーザー・リクエストはSharePoint Server RPサイトにアクセスします。

2. サイトを保護するWebgateは、リクエストを捕捉し、リソースが保護されているかどうかを判定し、ユーザーに要求します。

3. ユーザーはOAM資格証明を入力し、Webgateは、LDAPから資格証明を確認してユーザーを認証するOAMサーバーに接続します。Webgateは、OAMネイティブSSO Cookie(ObSSOCookie)を生成します。これは、シングル・サインオンを可能にし、HTTPリクエストの(ユーザー名に対する)ユーザーIDヘッダー変数を設定し、ユーザーをSharePoint RPサイトにリダイレクトします。

4. SharePoint RPのカスタム・ログイン・ページが呼び出され、これが、ユーザー名をヘッダー変数で設定されたユーザーIDに設定し、パスワードをObSSOCookie値に設定します。ログイン・ページもこれらの資格証明をSharePoint RPサイトに自動的に送信します。

5. SharePoint RPサイトは、資格証明をSharePoint STSに渡し、これは、ユーザー資格証明の検証のためにカスタム・メンバーシップ・プロバイダを呼び出します。

6. カスタム・メンバーシップ・プロバイダは、(パスワードとして渡された)ObSSOCookie値を取得し、ASDK呼び出しをWebgateによって保護されているリソースに対して使用し(またはこれをHTTPリクエストの一部として送信し)ObSSOCookieを検証します。

7. ObSSOCookieが有効な場合、SharePoint STSは、SAMLトークンを生成し、これをSharePoint RPに渡します。

8. SharePoint RPは、SAMLトークンを検証し、FedAuth Cookieを生成します。ユーザーは、SharePoint RPサイトへのアクセスを許可されます。

45.2.3 Windowsの偽装およびSharePoint 2010の統合を使用した認証について

前記のとおり、Windowsの偽装によって、Windowsサーバー・ドメインの信頼できるユーザーは、SharePoint Portal Server 2010のターゲット・リソースをリクエストする任意のユーザーのアイデンティティを持つことができます。この信頼できるインパーソネータは、ユーザーのアイデンティティ・コンテキストを維持し、ユーザーのかわりにリソースにアクセスします。偽装は、ユーザーに対して透過的に行われます。アクセスは、SharePointリソースがOAMサーバー・ドメイン内のリソースであるかのように実行されます。WindowsベースのSharePoint 2010との統合は、SharePoint 2007とのサポートされている統合と同じです。

注意:

SharePoint 2007の統合では、Access Manager ISAPIの拡張子(IISImpersonationExtension.dll)が使用されていました。SharePoint 2010のイベント処理の内部アーキテクチャでは、Access ManagerはISAPI拡張子からHTTPモジュールに変更されました。

次の概要では、SharePoint 2010およびWindowsの偽装を有効にした場合に認証処理フローを特定します。

プロセス概要: Windowsの偽装を使用した統合認証

1. ユーザー・リクエストはSharePoint Portal Serverリソースにアクセスします。

2. SharePoint Portal Serverを保護するWebゲートISAPIフィルタは、リクエストを捕捉し、ターゲット・リソースが保護されているかどうかを判定し、保護されている場合にはユーザーに認証資格証明を要求します。

3. ユーザーが資格証明を提供し、OAMサーバーがこれを検証すると、WebgateはユーザーのブラウザにObSSOCookieを設定し、シングル・サインオンを有効にします。Webgateは、impersonateというHTTPヘッダー変数も設定します。この値は次についてonに設定されます。

- 認証されるユーザーのLDAP uid

- ユーザー・アカウントがActive Directoryに存在する場合、samaccountname

4. Access Manager HTTPモジュールIISImpersonationModule.dllは、impersonateという認可成功アクション・ヘッダー変数があるかどうかを確認します。

5. このヘッダー変数が存在する場合、Oracle ISAPIモジュールは、このユーザーに対するKerberosチケットを取得します。
このService for User to Self (S4U2Self)偽装トークンを使用すると、指定された信頼できるユーザーは、リクエストしているユーザーのアイデンティティを持ち、IISおよびSharePoint Portal Serverを介してターゲット・リソースにアクセスできます。

45.2.4 Access ManagerとWindowsネイティブ認証について

Access Managerは、Windowsネイティブ認証(WNA)のサポートを提供します。環境には次のものが含まれます。

- Windows 2008または2008 R2サーバー

- Internet Information Services(IIS)7または7.5

- Active Directory
たとえばユーザーのディレクトリ・サーバーにNTログオンIDがある場合、またはユーザー名がすべての場所で同じ場合、ユーザーは任意のディレクトリ・サーバーに対して認証できます。Windows Server 2008で最も一般的な認証メカニズムはKerberosです。

Access ManagerによるWNAの使用はシームレスです。ユーザーは、デスクトップにログインし、Internet Explorer(IE)ブラウザを開き、保護されているWebリソースをリクエストしてシングル・サインオンを完了するときに、通常の認証とWNAの違いに気付きません。

プロセスの概要: WNA認証の使用方法

1. ユーザーがデスクトップ・コンピュータにログインすると、Windows Domain Administrator認証スキームを使用してローカル認証が完了します。

2. ユーザーは、Internet Explorer(IE)ブラウザを開き、アクセス・システムで保護されたWebリソースをリクエストします。

3. ブラウザは、ローカル認証をメモし、KerberosトークンをIIS Webサーバーに送信します。

注意:

Internet Explorerのインターネットおよび(または)イントラネットのセキュリティ設定が「自動ログイン」を許可するように適切に調整されていることを確認してください。

4. IIS WebサーバーにインストールされているWebGateは、KerberosトークンをOAM 11gサーバーに送信します。OAM 11gサーバーは、KDC(キー配布センター)を使用してkerberosトークンをネゴシエーションします。

5. Access Managerは、認証成功情報をWebGateに送信します。

6. WebGateは、ObSSOCookieを作成し、それをブラウザに送信します。

7. Access Managerの認可およびその他のプロセスは通常どおりに進められます。
WebGateに対して構成されている最大セッション・タイムアウト期間が、生成されたObSSOCookieに適用されます。

45.3 統合の要件

特に明記しないかぎり、この項では、この章で説明する統合に必要なコンポーネントを紹介します。内容は次のとおりです。

- 要件の確認

- 必要なAccess Managerのコンポーネント

- 必要なMicrosoftのコンポーネント

45.3.1 要件の確認

特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。最新のAccess Manager証明書の情報は、Oracle Technology Networkの動作保証マトリックス(次のURL)を参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

45.3.2 必要なAccess Managerのコンポーネント

Access Managerは、アクセス機能およびセキュリティ機能(Webベースのシングル・サインオン、ポリシー管理、レポートと監査など)を提供します。Microsoft SharePoint Server 2010と統合すると、Access Managerは、ISAPIフィルタおよびISAPIモジュールを介してユーザー認証を処理し、2つの製品間のシングル・サインオンが可能になります。

表45-1のコンポーネントは、Microsoft SharePoint Server 2010(またはLDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010)との統合に必要です。

表45-1 Access Managerのコンポーネントの要件

コンポーネント

説明

10g Webgate

ISAPIバージョン10g Webgateは、SharePoint Server 2010と同じコンピュータに存在する必要があります。

この統合のコンテキスト内では、このWebgateは、WebリソースのHTTPリクエストを捕捉し、これらをOAMサーバーに転送してリクエストをしたユーザーを認証するISAPIフィルタです。認証が成功すると、Webgateは、ObSSOCookieを作成し、これをユーザーのブラウザに送信するため、シングル・サインオンが容易になります。Webgateは、このユーザー・セッションのHeaderVarアクションとして偽装の設定も行います。

LDAPメンバーシップ・プロバイダのシナリオの場合: 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合」を参照してください。

IISImpersonationModule.dll

このIISネイティブ・モジュールは、Webgateとともにインストールされます。IISImpersonationModule.dllは、認可成功アクションHeaderVarが偽装に設定されたかどうかを判定し、その場合には、このdllは、SharePoint Server Active Directoryの特別な信頼できるユーザーが元々リクエストをしたユーザーに偽装できるようにするKerberos S4U2Selfチケットを作成します。

Webgateのインストール後、IISImpersonationModule.dllを手動で構成し、偽装およびこの統合を有効にする必要があります。

LDAPメンバーシップ・プロバイダのシナリオの場合: IISImpersonationModule.dllを構成しないでください。

ディレクトリ・サーバー

Access Managerは、任意のサポートされているディレクトリ・サーバー(LDAPおよびActive Directoryを含むがこれらに限定されない)に接続できます。Access Managerは、SharePoint Server 2010によって使用されるActive Directoryの同じインスタンスにさえ接続できます。

いずれのケースでも、ディレクトリはSharePoint Serverおよび保護しているWebgateと同じマシン上である必要はありません。

OAMサーバー

この統合では、SharePoint Serverのインストールを保護しているWebgateが相互運用に構成されている相互運用相手のOAMサーバーのインストールも必要です。

SharePoint Serverを保護しているWebgate以外のコンポーネントをSharePoint Serverをホストしているマシンに配置する必要はありません。

関連項目: 「SharePoint 2010との統合の準備」.

Access Manager ASDK

カスタム・メンバーシップ・プロバイダは、ObSSOCookieの検証にWin 64ビットASDKを使用します。

45.3.3 必要なMicrosoftのコンポーネント

最小要件では、64ビット、4コアのプロセッサを指定しています。ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作確認情報は、Microsoft SharePoint Server 2010の次のMicrosoftライブラリの場所を参照してください。

https://technet.microsoft.com/en-us/library/cc262485.aspx

SharePointの多目的プラットフォームでは、イントラネット・ポータル、エクストラネットおよびWebサイトの管理およびプロビジョニング、ドキュメント管理とファイル管理、コラボレーション・スペース、ソーシャル・ネットワーク・ツール、エンタープライズ検索とインテリジェンス・ツール、プロセスと情報の統合、サードパーティが開発したソリューションが可能です。

注意:

最小要件では、64ビット、4コアのプロセッサを指定しています。ただし、特定のバージョンおよびプラットフォームについて言及している場合、それらは例示のみの目的で記載されています。Access Managerの最新の動作確認情報は、次のOracle Technology Networkを参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

表45-2に、この統合に必要なその他のコンポーネントを示します。

関連項目:

Microsoft SharePoint Server 2010の次のライブラリの場所および適用可能なソフトウェアへのアクセス。

http://technet.microsoft.com/en-us/library/cc262485.aspx

表45-2 この統合のためのMicrosoftの要件

コンポーネント

説明

SharePointサイトのカスタム・ログイン・ページ

フォーム・ベースの認証を使用するように構成されたSharePointサイトにユーザーがアクセスしようとすると、ユーザーはログイン・ページにリダイレクトされ、そこで資格証明(ユーザー名、パスワード)を入力できます。カスタム・ログイン・ページは資格証明をSharePointサイトに渡します。

SharePointサイト

SharePointサーバーの全体管理アプリケーションを使用してSharePointサイトを作成します。このサイトは、http://technet.microsoft.com/en-us/library/ee806890.aspxで説明されている次のステップに従って、認証メソッドとしてフォーム・ベースの認証を使用するように構成されます。

SharePointサイトは、カスタム・メンバーシップ・プロバイダによるObSSOCookieの検証成功時にSAMLトークンを生成するSharePoint STSにユーザー資格証明を渡します。SharePointサイトは、SAMLトークンをSharePoint STSから受信したときにFedAuth Cookieも生成します。SharePointサイトは、FedAuth Cookieをユーザーに渡し、ユーザーがSharePointサイトにアクセスできるようにします。

SharePointセキュリティ・トークン・サービス(STS)

SharePointサイトは、ユーザー資格証明(ユーザー名とパスワード)をSharePoint STSに渡し、これは、カスタム・メンバーシップ・プロバイダを呼び出して、これに資格証明を渡します。カスタム・メンバーシップ・プロバイダがこれに渡されたObSSOCookieを検証すると、SharePoint STSは、SharePoint Relying Party(RP)に渡されたユーザーのためにSAMLトークンを生成します。

SharePoint STSのためのカスタム・メンバーシップ・プロバイダ

SharePoint STSは、(フォーム・ベースの認証によって構成された)メンバーシップ・プロバイダを呼び出します。STSは、ユーザー資格証明および(SharePointサイト上のweb.configで構成された)IISリソースのURLをCookie検証のためにカスタム・メンバーシップ・プロバイダに渡します。

メンバーシップ・プロバイダは、これに渡されたObSSOCookie値が有効な場合に成功を返すようにカスタマイズされます。プロバイダは、Webgateによって保護されているIISリソース(HTMLページ)にHTTPリクエストを送信するかまたは（使用中の構成に基づいて）ASDK呼び出しを実行して、ObSSOCookieを検証します。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)は、パッケージ化されIIS Webサーバーの10g Webgateを使用してインストールされます。SharePoint 2010ホストのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

CustomMembershipProviderクラスは、Microsoft.Office.Server.SecurityネームスペースにあるLdapMembershipProviderクラスから派生します。

Cookie検証のIISリソース

カスタム・メンバーシップ・プロバイダは、Webgateによって保護されているIISリソース(HTMLページ)にHTTPリクエストを送信するかまたは（構成に基づいて）ASDK呼び出しを実行して、ObSSOCookieを検証します。IISリソースのURLはSharePointサイトのweb.configファイルで構成されます。

HTTP検証メソッドの場合、Webgateは、カスタム・メンバーシップ・プロバイダによって送信されたリクエストを捕捉し、リクエストからObSSOCookieを抽出してこれを検証します。Cookieが有効な場合、リクエストはIISリソースにリダイレクトされ、これが200(OK)に設定されたステータス・コードを含むレスポンスをカスタム・メンバーシップ・プロバイダに返します。そうでない場合は、403(禁止)エラー・コードがカスタム・メンバーシップ・プロバイダに返されます。

45.4 SharePoint 2010との統合の準備

次の手順のタスクは、この章で説明するすべての統合シナリオで必要です。

Microsoftコンポーネントをインストールしてテストした後、ここに示すステップを実行して統合のためにAccess Managerをインストールします。このタスクは、この章の両方の統合シナリオに適用されます。重複を避けるために、ここで示す情報は、他の場所では繰り返しません。

ISAPI 10g Webgateは、SharePoint Serverと同じコンピュータにインストールする必要があります。この統合の他のコンポーネントは、Webgateと同じホストまたはデプロイメント(Solaris、LinuxまたはWindowsプラットフォーム)の他のコンピュータに配置できます。異なるホストをActive Directoryまたは他のディレクトリ・サービスに設定できます。Access ManagerとSharePoint Serverの両方がActive Directoryの異なるインスタンスに設定される場合、両方のインスタンスは、同じActive Directoryドメインに属する必要があります。

関連項目:

10g Webgateのインストールの場合は、第22章

前提条件

「必要なMicrosoftのコンポーネント」に記載されているMicrosoftのコンポーネントをインストールしてテストします。

SharePoint 2010との統合を準備するには:

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Oracle Identity ManagementおよびAccess Managerをインストールします。

2. IIS Webサーバーの10g WebgateをAccess Managerに登録します。

1. Oracle Access Managementコンソールにログインします。例: http://host:port/oamconsole.

2. 「ようこそ」ページのSSOエージェントパネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

3. 「OAMエージェントの作成」ページで、必要な詳細(*が付いている項目)を入力します。
「名前」
「セキュリティ・モード」(エージェント・ホストはOAMサーバーと一致する必要があります)
「ポリシーの自動作成」(チェック)

注意:

ベースURLを指定しないでください。

4. 保護されているリソース・リスト: この表では、このOAMエージェントで保護する個々のリソースのURLを入力します。

5. パブリック・リソース・リスト: この表では、公開する(保護しない)個々のリソースのURLを入力します。

6. 「適用」をクリックして登録を送信し、「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

3. ASDK: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、Access Manager Win 64ビットASDKをダウンロードしてインストールします。

4. 次の手順を実行します。

- 新規Webgateのインストール: ステップ6、7および8に進み、第45章「Microsoft SharePoint Server 2010とAccess Managerの統合」を参照してください。

- SharePointホスト上の既存のWebgate: 「Microsoft SharePoint Server 2010との統合」にスキップします。

注意:

「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合」で説明しているように、64ビットISAPI Webgateのみがサポートされます。

5. 次のように、64ビットISAPI Webgateのインストーラを探してダウンロードします。

1. 次のOracle Fusion Middleware 11gR1ソフトウェア・ダウンロードに移動します。

https://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

2. ページの最も上のライセンス契約に同意をクリックします。

3. Access Manager Webgates (10.1.4.3.0)の行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。

4. インストールする10g(10.1.4.3)アクセス・システムの言語パックと同じディレクトリにWebgateインストーラを格納します。

6. 使用中のプラットフォーム、インストール・モード、Webサーバー用のWebgateインストーラを起動します。

1. 画面に表示されるプロンプトに従います。

2. Webサーバーの管理者資格証明を指定します。

3. 言語パック—デフォルトのロケールとインストールするその他のロケールを選択して、次へをクリックします。

4. Webgateインストールが始まります(IISImpersonationModule.dllはWebgate_install_dir\access\Oblix\apps\Webgate\bin\にインストールされます)。

7. Webサーバー構成を更新する前に、WebgateアーティファクトをAdminServerからWebgateをホストしているコンピュータにコピーします。

1. Oracle Access Managementコンソール(AdminServer)をホストしているコンピュータでObAccessClient.xml(およびすべての証明書アーティファクト)を探してコピーします。
DOMAIN_HOME/output/$Agent_Name/

ObAccessClient.xml
password.xml(必要に応じて)
aaa_key.pem(openSSLによって生成される秘密鍵)
aaa_cert.pem(PEMフォーマットの署名済証明書)

2. OAMエージェントのホストで、アーティファクトをWebgateパスに追加します。次に例を示します。
Webgate_install_dir/access/oblix/lib/ObAccessClient.xml
Webgate_install_dir/access/oblix/config

3. Webgate Webサーバーを再起動します。

4. このエージェントをホストするOAMサーバーを再起動します。

8. 必要に応じて次に進み、使用中の環境内でこの統合を完了します。

- Microsoft SharePoint Server 2010との統合

- LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

45.5 Microsoft SharePoint Server 2010との統合

次の概要では、この統合のために実行する必要があるタスクと、手順および詳細に関する項目について説明します。

カスタム・メンバーシップ・プロバイダ・ライブラリ(OAMCustomMembershipProvider.dll)は、パッケージ化されIIS Webサーバーの10g Webgateを使用してインストールされます。次に説明するように、SharePoint 2010をホストするコンピュータのグローバル・アセンブリ・キャッシュにライブラリをデプロイする必要があります。

タスクの概要: Microsoft SharePoint Server 2010との統合には次の項目が含まれます

1. 前提条件となるタスクの実行

- 「必要なMicrosoftのコンポーネント」のインストール

- 「SharePoint 2010との統合の準備」

2. SharePoint Server 2010での新規Webアプリケーション(またはサイト・アプリケーション)の作成は、次のトピックで説明します。

- 「Microsoft SharePoint Server 2010での新規Webアプリケーションの作成」

- Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成

3. 「Microsoft Windowsの偽装の設定」(LDAPメンバーシップ・プロバイダには使用しません)。

4. 「SharePoint Serverの統合の完了」。

5. 「Microsoft SharePoint Server 2010のためのシングル・サインオフの構成」

6. 「ディレクトリ間のユーザー・プロファイルの同期化」

7. 「統合のテスト」

45.5.1 Microsoft SharePoint Server 2010での新規Webアプリケーションの作成

Microsoft SharePoint Server 2010との統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。

前提条件

Microsoftのコンポーネントのインストール。「必要なMicrosoftのコンポーネント」を参照してください。

Microsoft SharePoint Server 2010で新規Webアプリケーションを作成するには:

1. SharePoint 2010がインストールされているホストで、「集中管理」ホーム・ページを開きます: 「起動」、すべてのプログラム、SharePoint 2010製品、SharePoint 2010、「集中管理」。

2. 「集中管理」ホーム・ページから、アプリケーション管理をクリックします。

3. アプリケーション管理ページの「Webアプリケーション」から、Webアプリケーションの管理をクリックします。

4. 左上隅で、「新規作成」ボタンをクリックして新規Webアプリケーションを作成します。

5. 新規Webアプリケーションの作成ページで表45-3の項目を構成します。

表45-3 Microsoft SharePoint Server 2010の「Webアプリケーションの作成: {0}」オプション

セクション

この項で構成するもの

認証

この項では、要求ベースの認証またはクラシック・モード認証のどちらか該当するほうを選択します。

IIS Webサイト

この項では、次のように、新規Webアプリケーションに対して次の設定を構成します。

- 既存のWebサイトを選択するには、既存のWebサイトを使用するをクリックします。

- 新規のサイトを作成するには、「作成」をクリックします。

- ポートフィールドで、Webアプリケーションへのアクセスに使用するポート番号を入力します。
新規Webサイトの場合、このフィールドにはデフォルトのポート番号が入っています。既存のサイトの場合、このフィールドには現在構成されているポート番号が入っています。

- オプションのホスト・ヘッダーフィールドに、WebアプリケーションにアクセスするためのURLを入力します。

- 「パス」フィールドに、サーバー上のサイトを含むディレクトリへのパスを入力します。
新規Webサイトの場合、このフィールドにはデフォルトのパスが入っています。既存のサイトの場合、このフィールドには現在のパスが入っています。

セキュリティ構成

この項では、次のように、使用中のWebアプリケーションに対して認証と暗号化を構成します。

- 「認証プロバイダ」セクションで、適宜、ネゴシエート(Kerberos)またはNTLMを選択します。

- 匿名を許すセクションで、「はい」または「いいえ」を選択します。
値が「はい」の場合、コンピュータ固有の匿名アクセス・アカウントを使用して、Webサイトへの匿名アクセスが許可されます。アカウント名はIUSR_コンピュータ名です。

- 「Secure Sockets Layer」(SSL)セクションで、「はい」または「いいえ」を選択します。
Webサイトに対してSSLを有効にすることを選択すると、証明書をリクエストしてインストールすることによってSSLを構成する必要があります。

パブリックURL

このWebアプリケーションでユーザーがアクセスするすべてのサイトのドメイン名のURLを入力します。このURLドメインは、Webアプリケーションのページに表示されるすべてのリンクで使用されます。デフォルトでは、このボックスには現在のサーバー名およびポートが移入されます。「ゾーン」フィールドは、新規Webアプリケーションのデフォルトに自動的に設定され、このページからは変更できません。

アプリケーション・プール

「アプリケーション・プール」セクションでは、次のように、このWebアプリケーションに対して既存のアプリケーション・プールを使用するか新規アプリケーション・プールを作成するかを選択します。

- 既存のアプリケーション・プールを使用するには、既存のアプリケーション・プールを使用を選択し、ドロップダウン・メニューから使用するアプリケーション・プールを選択します。

- 新規アプリケーション・プールを作成するには、新規アプリケーション・プールの作成を選択し、アプリケーション・プール名フィールドに、新規アプリケーション・プールの名前を入力するか、デフォルト名のままにします。
このアプリケーション・プール用のセキュリティ・アカウントを選択するセクションで、「事前定義」を選択して既存のアプリケーション・プールのセキュリティ・アカウントを使用し、ドロップダウン・メニューからセキュリティ・アカウントを選択します。既存のアプリケーション・プールに現在使用されていないセキュリティ・アカウントを使用するには、構成可能を選択し、使用するアカウントのユーザー名を「ユーザー名」フィールドに入力し、そのアカウントのパスワードを「パスワード」フィールドに入力します。

データベース名および認証

この項では、新規Webアプリケーションに対してデータベース・サーバー、データベース名および認証メソッドを選択します。

「データベース名」フィールドに、データベースの名前を入力するか、デフォルト・エントリを使用します。データベース認証フィールドで、次のように、Windows認証(推奨)を使用するかSQL認証を使用するかを選択します。

- Windows認証を使用する場合、このオプションを選択したままにします。

- SQL認証を使用する場合、SQL認証を選択します。「アカウント」フィールドに、SQL Serverデータベースに対して認証するためにWebアプリケーションが使用するアカウント名を入力し、「パスワード」フィールドにパスワードを入力します。

フェイルオーバー・サーバー

オプションで、フェイルオーバー・データベース・サーバーを指定してフェイルオーバー・サーバーを構成することを選択できます。

サービス・アプリケーション接続

デフォルト値を使用するか、カスタム値を選択できます。また、オプションで、Webアプリケーションが接続するサービスを選択できます。

6. 「OK」をクリックして新規Webアプリケーションを作成するか、「取消」をクリックしてプロセスを取り消し、アプリケーション管理ページに戻ります。

7. 「Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成」に進みます。

45.5.2 Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成

Microsoft SharePoint Server 2010との統合時に、LDAPメンバーシップ・プロバイダを使用してまたは使用せずにこのタスクを実行します。

Microsoft SharePoint Server 2010のために新規サイト・コレクションを作成するには:

1. アプリケーション管理ページのサイト・コレクションセクションから、サイト・コレクションの作成をクリックします。

2. サイト・コレクションの作成ページの「Webアプリケーション」セクションで、次のように、サイト・コレクションをホストするWebアプリケーションを(「Webアプリケーション」ドロップダウン・リストから)選択するか、新規Webアプリケーションを作成してサイト・コレクションをホストします。

表45-4 SharePoint Server 2010のサイト・コレクションをホストするWebアプリケーションの作成

セクション

この項で構成するもの

割当て制限テンプレート

適宜、事前定義済の割当てテンプレートを使用してこのサイト・コレクション用に使用するリソースを制限するか、「割当てなし」を使用できます。

タイトルと説明

サイト・コレクションのタイトルと説明の入力

Webサイト・アドレス

URLタイプを選択し、サイト・コレクションのURLを指定します。

テンプレート

タブ付きテンプレート制御からテンプレートを選択します。

プライマリ・サイト・コレクション管理者

サイト・コレクションのプライマリ管理者にするユーザーのユーザー・アカウント名を入力します。

テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある名前の確認アイコンをクリックしてユーザー・アカウントを確認できます。

セカンダリ・サイト・コレクション管理者(オプション)

サイト・コレクションのセカンダリ管理者にするユーザーのユーザー・アカウントを入力します。

テキスト・ボックスの右にある「ブック」アイコンをクリックしてユーザー・アカウントを参照することも可能です。テキスト・ボックスの右にある名前の確認アイコンをクリックしてユーザー・アカウントを確認できます。

3. この統合を終了したら次のトピックを参照してください。

- Microsoft Windowsの偽装の設定

- 「SharePoint Serverの統合の完了」

- Microsoft SharePoint Server 2010のためのシングル・サインオフの構成

- ディレクトリ間のユーザー・プロファイルの同期化

- 統合のテスト

関連項目:

「タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合」

45.6 Microsoft Windowsの偽装の設定

SharePoint Serverの統合のためでも他のアプリケーションによって使用するためでも、偽装の設定は、次の項で説明します。

注意:

LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010と統合している場合、この項をスキップしてください。LDAPメンバーシップ・プロバイダでは、Windowsの偽装は使用しません。

タスクの概要: 偽装の設定

1. 「信頼できるユーザー・アカウントの作成」の説明に従って、SharePoint Serverに接続されたActive Directoryでの偽装に対してのみ信頼できるユーザー・アカウントを作成します。

2. 「信頼できるユーザーへの権限の割当て」の説明に従って、オペレーティング・システムの一部として機能する特別な権限を信頼できるユーザーに与えます。

3. 「信頼できるユーザーのWebgateへのバインド」の説明に従って、信頼できるユーザーの認証資格証明を提供して、信頼できるユーザーをWebgateにバインドします。

4. 「偽装レスポンスの認可ポリシーへの追加」の説明に従って、アプリケーション・ドメインで偽装のための認可成功アクションにIMPERSONATEという名前のヘッダー変数を追加します。

5. 「偽装dllのIISへの追加」の説明に従って、IISImpersonationModule.dllをIIS構成に追加して、IISを構成します。

6. 「偽装のテスト」の説明に従って、偽装をテストします。

45.6.1 信頼できるユーザー・アカウントの作成

この特別なユーザーは、偽装以外には使用しないでください。

次の手順例では、Impersonatorを新規オブジェクト - ユーザーとして使用します。環境はユーザーによって異なります。

信頼できるユーザー・アカウントを作成するには:

1. SharePoint Serverインストールをホストしているコンピュータで次のステップを実行します。

- Windows 2008: 「スタート」→「プログラム」→「管理ツール」→「Active Directoryユーザーとコンピュータ」の順に選択します。

2. 「Active Directoryユーザーとコンピュータ」ウィンドウで、左ペインのツリーで「ユーザー」を右クリックし、「新規作成」→「ユーザー」の順に選択します。

3. 「新規オブジェクト - ユーザー」というペインの1つ目の「名前」フィールドに、覚えやすい名前(Impersonatorなど)を入力します。

4. この同じ文字列を「ユーザー ログオン名」フィールドにコピーし、「次へ」をクリックします。

5. 次のパネルで、パスワードの選択と確認用の再入力を求められます。

注意:

信頼できるユーザーには、非常に強力な権限が付与されるため、非常に複雑なパスワードを選択することをお薦めします。また、「パスワードの有効期限なし」ボックスがマークされていることも確認してください。偽装モジュールは、信頼できるユーザー・アカウントを表示できる唯一のエンティティであるため、外部のエージェンシがパスワードの期限切れを発見することは非常に困難です。

図45-1 Windowsの偽装のための信頼できるユーザー・アカウントの設定

45.6.2 信頼できるユーザーへの権限の割当て

オペレーティング・システムの一部として機能する権限を信頼できるユーザーに与える必要があります。

信頼できるユーザーに適切な権限を与えるには:

1. 使用中の環境で次のステップを実行します。

- Windows 2008: 「スタート」→「プログラム」→「管理ツール」→「ローカル セキュリティ ポリシー」の順に選択します。

2. 左ペインのツリーで、「ローカル ポリシー」の横のプラス・アイコン(+)をクリックします。

3. 左ペインのツリーで「ユーザー権利の割り当て」をクリックします。

4. 右ペインで「オペレーティング システムの一部として機能」をダブルクリックします。

5. 「ユーザーまたはグループの追加」をクリックします。

6. 「ユーザーまたはグループの追加」パネルで、信頼できるユーザーのユーザー・ログオン名(この例ではSPPSImpersonator)をユーザー名とグループ名のテキスト入力ボックスに入力し、「OK」をクリックして変更を登録します。

図45-2 Windowsの偽装での信頼できるユーザーの権限の構成

45.6.3 信頼できるユーザーのWebgateへのバインド

次のように、信頼できるユーザーの認証資格証明を提供することによって、Access Managerと通信する10g Webgateに信頼できるユーザーをバインドする必要があります。

次の手順では、10g WebgateをAccess Managerにまだ登録していないことを前提としています。次の手順の値は、例としてのみ提供されます。環境はユーザーによって異なります。

関連項目:

10g Webgateの管理の詳細は、第22章

信頼できるユーザーをWebgateにバインドするには:

1. Oracle Access Managementコンソールに移動します。
次に例を示します。

http://hostname:port/oamconsole

ここで、hostnameはOracle Access Managementコンソールをホストしているコンピュータの完全修飾DNS名、portはOAMサーバー用に構成されたリスニング・ポート、oamconsoleはOracle Access Managementコンソールです。

2. 「ようこそ」ページのSSOエージェントパネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

3. 「OAMエージェントの作成」ページで、必要な詳細(*の付いたもの)を入力して、このWebgateを登録します

4. 保護されているリソース・リスト: この表では、表14-9にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。

5. パブリック・リソース・リスト: この表では、表14-9にあるように、公開する(保護しない)個々のリソースのURLを入力します。

6. 「ポリシーの自動作成」: 新規ポリシーの作成をチェックします(または、クリアして別のWebgateと同じホスト識別子を使用してポリシーを共有します(表14-9))。

7. 「適用」をクリックして、登録を送信します。

8. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

9. ナビゲーション・ツリーで、「エージェント」ページを開きます。

10. SharePoint要件: ここに表示されるフィールドに信頼できるユーザーの資格証明を追加し、「適用」をクリックします。

11. 次のようにアーティファクトをコピーします(またはWebgateをインストールしてからこれらのアーティファクトをコピーします)。

1. Oracle Access Managementコンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml(およびすべての証明書アーティファクト)を検索します。次に例を示します。
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml

2. エージェントをホストしているコンピュータで、アーティファクトをコピーします。次に例を示します。
10g Webgate/AccessClient: $Webgate_install_dir/oblix/lib/
ObAccessClient.xml

3. 「偽装レスポンスの認可ポリシーへの追加」に進みます。

45.6.4 偽装レスポンスの認可ポリシーへの追加

SharePointリソースを保護するアプリケーション・ドメインおよび基本ポリシーは、WebゲートをAccess Managerに登録したときに作成されました。ここで、ヘッダーの戻りタイプを含む認可成功アクション(レスポンス)を追加し、この名前をIMPERSONATEに設定し、レスポンス値を$user.useridにします。

関連項目:

アプリケーション・ドメインおよびポリシーの詳細は、第17章。

偽装レスポンスを認可ポリシーに追加するには:

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「アプリケーション・ドメイン」を開き、DesiredDomainを見つけて開いてから、DesiredPolicyを開きます。
「認可ポリシーの検索」を参照してください。

ここで、DesiredDomainは、偽装専用に作成されたアプリケーション・ドメイン(Impersonationなど)を表します。DesiredPolicyは、エージェント登録中に作成されたデフォルトのポリシーです。デフォルトでは、ユーザーが作成するまでポリシー・レスポンスは存在しません。

2. レスポンス: ポリシーを開くページで、「レスポンス」タブをクリックし、「追加」(+)ボタンをクリックします。

- 「タイプ」リストから「ヘッダー」を選択します。

- 「名前」フィールドに、このレスポンスの一意の名前を入力します: IMPERSONATE

- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

- 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

3. 「追加」をクリックして、レスポンスを保存します。これは、2つ目のWebゲート・リクエスト(認可用)に使用されます。次に例を示します。

45.6.5 偽装dllのIISへの追加

この統合のためにIIS Webサーバーを構成する準備ができました。そのためには、すべてのサイト(中央管理およびWebサービスを含む)でIISImpersonationModule.dllを登録して構成します。

または、複数のWebサイトがあり、その一部がAccess Managerに統合されていて、残りが統合されていない場合、Access Managerに統合されてしるWebサイトに対してのみ偽装を有効にする必要があります。そのためには、統合が必要なサイトのみでネイティブ・モジュールを構成する必要があります。関連項目:

- IISに対してImpersonationModuleを構成して登録するには:

- Webサイトに対してサイト・レベルのネイティブ・モジュールを構成するには:

IISに対してImpersonationModuleを構成して登録するには:

1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

2. IIS 7の左ペインで、ホスト名をクリックします。

3. 中央ペインのIISヘッダーで、「モジュール」をダブルクリックします。

4. 右ペインで「ネイティブ モジュールを構成」をクリックして「登録」をクリックします。

5. ウィンドウに、モジュール名(たとえば、Oracle偽装モジュール)を入力します。

6. 「パス」フィールドに、IISImpersonationModule.dllへのフルパスを入力します。
デフォルトでは、パスは次のとおりです。

Webgate_install_dir\access\oblix\apps\Webgate\bin\IISImpersonation

ここで、Webgate_install_dirはWebgateインストールのディレクトリです。

注意:

パスにスペースが存在する場合(たとえば、C:\Program Files\Oracle\...)文字列全体を二重引用符(" ")で囲みます。

7. 「OK」をクリックして、モジュールを登録します。

8. 新しく作成したモジュールの名前を確認し、「OK」をクリックして、各Webサイトにモジュールを適用します。

図45-3 偽装モジュールの登録

Webサイトに対してサイト・レベルのネイティブ・モジュールを構成するには:

1. サイトの左にあるプラス・アイコン(+)をクリックします。

2. 偽装を有効にするサイトをクリックします。

3. 中央ペインのIISで、「モジュール」をダブルクリックします。

4. 右ペインで「ネイティブ モジュールを構成」をクリックして、前に登録した偽装モジュールを選択します。

5. 「OK」をクリックします。

6. 次に進みます。

- 「偽装のテスト」

- 「SharePoint Serverの統合の完了」

45.6.6 偽装のテスト

統合を完了する前に、次の方法で偽装が正しく機能していることをテストできます。

- 「SharePoint Serverによって保護されていないIIS仮想サイトの作成」で説明する、SharePoint Serverの外部でのシングル・サインオンをテスト

- 「イベント・ビューアを使用した偽装のテスト」で説明する、イベント・ビューアの使用

- 「Webページを使用した偽装のテスト」で説明する、Webページの使用

- 「偽装のネガティブ・テスト」で説明する、ネガティブ・テストの使用

関連項目:

偽装の構成が正しく機能することを確認した場合、「SharePoint Server統合の完了」

45.6.6.1 SharePoint Serverによって保護されていないIIS仮想サイトの作成

SharePoint Server外の偽装機能をテストするまたはシングル・サインオンをテストするには、SharePoint Serverによって保護されていないIIS仮想Webサイト上にターゲットWebページが必要です。このような仮想Webサイトは、次のタスクを実行して作成します。

SharePoint Serverによって保護されていないIIS仮想サイトを作成するには:

1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

2. 左側のペインにあるツリー上のローカル・コンピュータのアイコンの左のプラス・アイコン(+)をクリックします。

3. 左ペインにあるツリー上のWebサイトを右クリックして、メニューの「新規作成」、「Webサイト」に移動します。

4. 「Webサイト作成」ウィザードでプロンプトに応答します。

5. 仮想サイトを作成した後、これをアプリケーション・ドメインのポリシーで保護する必要があります。アプリケーション・ドメインおよびポリシーの詳細は、第17章を参照してください。

45.6.6.2 イベント・ビューアを使用した偽装のテスト

Windows 2003イベント・ビューアを使用して偽装のテストを実行する場合、実際のテストを実行する前にイベント・ビューアを構成する必要があります。

イベント・ビューアを使用して偽装をテストするには:

1. 「スタート」メニュー→「イベント ビューア」に順に選択します。

2. 左ペインで、「セキュリティ」を右クリックし、「プロパティ」をクリックします。

3. 「セキュリティのプロパティ」シートで「フィルタ」タブをクリックします。

4. すべての「イベントの種類」にチェックが付いていることおよび「イベント ソース」と「分類」の各リストが「すべて」に設定されていることを確認し、「OK」をクリックして「プロパティ」シートを閉じます。
イベント・ビューアは、リソース・リクエストに関連付けられたHeaderVarに関する情報が表示されるように構成されました。

図45-4 イベント・ビューアの設定の確認

5. 新規IIS仮想サーバー(仮想サイト)を作成します。

6. 仮想サイト上のツリーのどこかにターゲットWebページを配置します。

7. Webページでブラウザを指します。

偽装が正しく機能している場合、イベント・ビューアがアクセス試行の成功を報告します。

45.6.6.3 Webページを使用した偽装のテスト

リクエストに関する情報を返し、表示できる.aspページやPerlスクリプトなどの動的テスト・ページを使用して偽装をテストすることも可能です。

サーバー変数を表示するWebページを使用して偽装をテストするには:

1. パラメータAUTH_USERおよびIMPERSONATEを表示する.aspページまたはPerlスクリプトを作成します。これは、次のリストに示すサンプル・ページに似せることができます。

例45-1 サンプルの.ASPページ・コード

<TABLE border=1>
<TR>
<TD>Variable</TD>
<TD>&nbsp&nbsp</TD>
<TD>Value</TD></TR>
<%for each servervar in request.servervariables%>
<TR>
<TD><%=servervar%></TD>
<TD>&nbsp&nbsp</TD>
<TD><%=request.servervariables(servervar)%>&nbsp</TD>
</TR>

2. IIS仮想サイトを作成するかまたは前のタスクで作成したものを使用します。

3. 新規仮想サイトのツリーのどこかに.aspページまたはPerlスクリプト(前のリストのサンプルなど)を配置します。

4. ブラウザで表示するページを指定し、要求を発行するユーザーの名前にAUTH_USERとIMPERSONATEの両方を設定します。

45.6.6.4 偽装のネガティブ・テスト

偽装のネガティブ・テストを実行するには、次の手順で説明するように、信頼できるユーザーをWebgateからバインド解除します。

信頼できるユーザーをWebgateからアンバインドするには:

1. Oracle Access Managementコンソールで、Webゲートを探します。
「OAMエージェント登録の検索」を参照してください。

2. テキスト・フィールドで、必要なインスタンスの正確な名前を入力します。例: ImpersonationAgent。「検索」をクリックします。

3. 必要なWebゲート登録ページを開いて、信頼できるユーザーの資格証明を削除します。

4. 「適用」をクリックして変更を保存します。

5. ブラウザ・ウィンドウでIISサーバーを再起動し、保護されているコード・ページ(信頼できるユーザーが以前アクセスできたページ)に移動します。

6. ページが表示されるというメッセージを受信することを確認します。AUTH_USERとIMPERSONATEの値は、偽装資格証明をWebgateにバインドするために必要です。

7. 信頼できるユーザーをWebゲート登録ページにリストアします。

45.7 SharePoint Serverの統合の完了

Access ManagerとSharePoint Serverとの統合を設定するためには、複数の手順を実行する必要があります。

注意:

LDAPメンバーシップ・プロバイダを使用して構成されたSharePoint Server 2010と統合している場合、この項をスキップしてください。

タスクの概要: SharePoint Serverの統合の完了

1. 「IISセキュリティの構成」の説明に従って、IISセキュリティを設定します。

2. 「SharePoint Serverの統合のテスト」の説明に従って、統合をテストします。

45.7.1 IISセキュリティの構成

続行する前にIISセキュリティを構成します。

SharePoint Serverの統合のためにIISセキュリティを構成するには:

1. 「スタート」→「管理ツール」→「インターネット インフォメーション サービス(IIS)マネージャ」の順に選択します。

2. 左側のペインにあるツリー上のローカル・コンピュータのアイコンの左のプラス・アイコン(+)をクリックします。

3. 左ペインのツリーで「Webサイト」をクリックします。

4. 中央ペインで、IISの下の「認証」をダブルクリックします。

5. 「匿名アクセス」が有効になっていて、「Windows認証」が無効になっていることを確認します。

図45-5 偽装認証

45.8 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

このシナリオでは、Access Managerは、SharePoint Security Token Service(STS)を使用してSharePoint 2010と統合されます。これには、IISへのISAPI Webgateインストール、Access Managerの構成およびHeaderVarの統合を実現するために必要な手順が含まれます。

注意:

この統合には、64ビットISAPI Webgateのみがサポートされます。

次の概要では、この統合のために実行する必要があるタスク(前提条件を含む)と、各タスクに必要な情報がある場所について説明します。

タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合

1. この統合の準備

1. 説明に従って、「必要なMicrosoftのコンポーネント」をインストールします。

2. 「Microsoft SharePoint Server 2010での新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。

3. 「Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。

4. SharePointのドキュメントの説明に従って、要求ベースの認証タイプ(LDAPメンバーシップ・プロバイダを使用)を使用して、作成したWebサイトをLDAPディレクトリに対して構成します。

5. LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

6. SharePointのドキュメントの説明に従って、構成をテストして、LDAPディレクトリに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

2. 「LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010のためのAccess Managerのインストール」の説明に従って、すべてのタスクを実行します。
このタスクには、IIS対応10g Webgateのインストールと個別のSharePoint WebサイトのためのWebgate.dllの構成が含まれます。

3. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」の説明に従って、この統合の認証スキームを追加します。

4. 「SharePoint Webサイトを保護するアプリケーション・ドメインの更新」の説明に従って、SharePoint Webサイトを保護するアプリケーション・ドメインを更新します。

5. 「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」の説明に従って、新規アプリケーション・ドメインで、この統合の認可ルールを作成します。

6. 「OAMAuthCookieのための認可レスポンスの作成」のすべてのステップを実行します。

7. 「OAMCustomMemebershipProviderの構成およびデプロイ」のすべてにステップを実行します。

8. 「ディレクトリ・サーバーが同期化されていることの確認」の説明に従って、必要に応じてディレクトリ・サーバーを同期化します。

9. 「Officeドキュメントのためのシングル・サインオンの構成」の説明に従って、Officeドキュメントのシングル・サインオンを構成します。

10. 「Microsoft SharePoint Server 2010のためのシングル・サインオフの構成」の説明に従って、シングル・サインオフを構成します。

11. 「統合のテスト」の説明に従って、統合をテストしてこれが問題なく機能することを確認して終了します。

45.8.1 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合について

前のシナリオ「Microsoft SharePoint Server 2010との統合」では、Windows認証の使用方法を説明しています。そのシナリオでは、認証および認可は、Active Directoryに存在するユーザーに対して実行されます。Access Managerは、統合のためにWindowsの偽装を使用しました。

この項で説明する統合の場合、LDAPメンバーシップ・プロバイダのサポートは、HeaderVarベースの統合によって実現されます。ISAPI Webgateフィルタは、WebリソースのHTTPリクエストを捕捉し、OAMサーバーと連動して、リクエストをしたユーザーを認証します。認証が成功すると、Webgateは、ObSSOCookieを作成し、これをユーザーのブラウザに送信して、シングル・サインオン(SSO)を容易にします。Webgateは、このユーザー・セッションのHeaderVarアクションとしてSP_SSO_UIDの設定も行います。SharePointのOracleカスタム・メンバーシップ・プロバイダは、次のいずれかのメソッドでObSSOCookieを検証します(これは構成できます)。

- HTTP検証メソッド: Access Managerのカスタム・メンバーシップ・プロバイダが、HTTP/HTTPSリクエストを保護されているリソースに発行し、Access Managerが認可成功時に返されるユーザー・ログインをSP_SSO_UIDによって検証および比較します。

- ASDK検証メソッド: このメソッドでは、OAMのカスタム・メンバーシップ・プロバイダはOAM ASDK呼び出しを実行してObSSOCookieを検証します。

関連項目:

この章で説明する、この統合と他の統合の処理の違いに関する「SharePoint Server 2010との統合の概要」

要件: この統合では、Microsoft SharePoint Server 2010が次のとおりである必要があります。

- LDAPメンバーシップ・プロバイダと統合され、Windows認証は使用しない

- 要求ベースの認証を使用してWebサイトで構成したIISImpersonationModule.dllを持っていない

関連項目:

「統合の要件」

45.8.2 LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010のためのAccess Managerのインストール

この手順は、LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010と統合するためのインストールの準備方法を説明します。

前提条件

前の「タスクの概要: LDAPメンバーシップ・プロバイダを使用して構成されたMicrosoft SharePoint Server 2010との統合」のステップ1を実行します。

LDAPメンバーシップ・プロバイダを含む統合のデプロイメントを準備するには:

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Oracle Identity ManagementおよびAccess Managerをインストールします。

2. 第22章および第25章のステップを使用してISAPI Webgateをプロビジョニングおよびインストールします。

3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。次に例を示します。

1. インターネット・インフォメーション・サービス(IIS)マネージャを起動します(「スタート」→「管理ツール」→「Internet Information Services (IIS) Manager」をクリックします)。

2. 「Webサイト」で、保護するSharePoint Webサイトの名前をダブルクリックします。

3. 中央ペインで、「ISAPIフィルタ」をダブルクリックし、右ペインで「追加」をクリックします。

4. フィルタ名をOracle Webgateと入力します。

5. Webgate.dllファイルに次のパスを入力します。

Webgate_install_dir/access/oblix/apps/Webgate/bin/Webgate.dll

6. これらの変更を保存して適用します。

7. 中央ペインで、「認証」をダブルクリックします。

8. 「匿名認証」および「フォーム認証」が有効になっていて、「Windows認証」が無効になっていることを確認します。

注意:

要求ベースの認証をAccess Managerで使用する場合、SharePointサイトのWindows認証を無効にする必要があります。

9. これらの変更を保存して適用します。

4. 保護するWebサイト・レベルに移動し、新しくインストールしたWebgate_install_dirを指す/access仮想ディレクトリを作成します。次に例を示します。

1. 「Webサイト」で、保護するWebサイトの名前を右クリックします。

2. 該当のWebgate_install_dir\accessを指す別名「access」という名前を使用して「仮想ディレクトリの追加」を選択します。

3. アクセス許可で、「読取り」、「起動スクリプト」および「実行」をチェックします。

4. これらの変更を保存して適用します。

5. 「LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成」に進みます。

45.8.3 LDAPメンバーシップ・プロバイダを使用するための認証スキームの構成

統合にLDAPメンバーシップ・プロバイダが含まれる場合、この手順で説明するように、3つのAccess Manager認証メソッドのみがサポートされます。

関連項目:

認証スキームの管理の詳細は、第16章

LDAPメンバーシップ・プロバイダを使用したSharePointのための認証スキームを構成するには:

1. Oracle Access Managementコンソールの「ポリシー構成」タブから、「共有コンポーネント」ノードを開きます。

2. 「認証スキーム」ノードをクリックし、ツール・バーの「作成」ボタンをクリックします。

3. 「認証スキーム」ページで、次の項目を入力します。
「名前」: このスキームの一意の名前を入力します。例: SharePoint w/LDAP-MP

「説明」: オプション

4. 「認証レベル」: スキームのセキュリティのレベルを選択します。

5. 「チャレンジ・メソッド」を選択します。
SharePoint Webサイトのルート(/)に対する基本認証

SharePoint Webサイトのルート(/)に対する「チャレンジ・リダイレクト」を使用したフォーム認証

SharePoint Webサイトのルート(/)に対するクライアント資格証明認証

6. 「チャレンジ・リダイレクト」: 必要に応じて、チャレンジ・リダイレクト値を入力します。

7. リストの中から「認証モジュール」を選択します。

8. 「チャレンジ・パラメータ」: 必要に応じて、チャレンジ・パラメータ値を入力します。

9. 「チャレンジURL」: 資格証明コレクションのために資格証明コレクタがリダイレクトするURL。

10. 「適用」をクリックして新しいスキームを送信し、「確認」ウィンドウで詳細を確認します。

11. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、「確認」ウィンドウを閉じます。

12. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

13. 「SharePoint Webサイトを保護するアプリケーション・ドメインの更新」に進みます。

注意:

SharePointリソースがAccess Managerのクライアント資格証明認証スキームで保護されている場合、PATH環境変数にC:\Program Files\Microsoft Office Servers\14.0\Bin;C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BINを追加する必要がある場合があります。

45.8.4 SharePoint Webサイトを保護するアプリケーション・ドメインの更新

このアプリケーション・ドメインは、IIS Webgateをプロビジョニングして、LDAPメンバーシップ・プロバイダを使用した統合シナリオでMicrosoft SharePoint Server 2010 Webサイトを保護するときに作成されました。

アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のタイプおよびサーバーに格納されて多くのユーザーがアクセスできるドキュメントまたはエンティティを識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。

注意:

この統合では、URL接頭辞を空のままにします。URL接頭辞に追加するリージョンを入力しないでください。

以前に作成した認証スキームを使用する必要があります。ObSSOCookieを検証するには、Webgateによって保護されているリソースに別のポリシーを作成する必要があります。例: /ValidateCookie。このリソースは、Webgateによって保護されているWebサーバーにデプロイし、正しいAccess Manager資格証明を提供した後にアクセスできる必要があります(http(s)://host:port/ValidateCookieを提供した後にアクセスできる必要があります。)

この例では、アプリケーション・ドメイン名としてSharePoint w/LDAP-MPを使用しています。環境はユーザーによって異なります。

注意:

ステップ6には、フォーム認証スキームを使用してSharePoint Webサイトを保護する代替認証スキームが含まれています。

関連項目:

リソースを保護するポリシーの管理の詳細に関する第17章

ルートのSharePoint Webサイトを保護するアプリケーション・ドメインを更新するには

1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MPアプリケーション・ドメインを開きます。
「既存のアプリケーション・ドメインの検索」を参照してください。

2. 「リソース」タブを開いて、「新規リソース」ボタンをクリックします。

3. 「リソース」の「定義」ページで、1つのリソースの詳細を入力して、「適用」をクリックします。
タイプ: http
説明(オプション): SharePoint Webサイトの保護
ホスト識別子: 前に追加したホスト識別子を選択します。
リソースURL: /ValidateCookieと入力します。
保護レベル: 保護
認証ポリシー(レベルが「保護」の場合)
認可ポリシー(レベルが「保護」で、「認証ポリシー」が選択されている場合)

4. 「認証ポリシー」の保護されたリソース・ポリシーに、定義済リソースを追加します。
「既存のアプリケーション・ドメインの検索」、「特定のリソースに対する認証ポリシーの定義」を参照してください。

- 認証ポリシー・ページの「リソース」タブをクリックします。

- 「リソース」タブの「追加」ボタンをクリックします。

- 目的のリソース定義を見つけて選択してから、「選択済の追加」をクリックします。

- 「適用」をクリックして、リソースを追加します。

- これを繰り返して、さらにリソースを追加します。

5. 「レスポンス」タブをクリックして、「追加」ボタンをクリックします。

- 「名前」フィールドに、このレスポンスの一意の名前を入力します(SP_SSO_UID)。

- 「タイプ」リストから「ヘッダー」を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

- 「適用」をクリックします。

- 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

6. ポリシーの追加: 選択した場合、HTTP検証メソッドに使用するリソースのポリシーを追加します。

7. このアプリケーション・ドメインを有効にする前に、「ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成」に進みます。

45.8.5 ヘッダー変数SP_SSO_UIDのための認可レスポンスの作成

このトピックは、LDAPメンバーシップ・プロバイダを使用して構成された統合に関する認可レスポンスを追加する方法を説明します。この統合では、次のヘッダー変数を認可成功のレスポンスとしてアプリケーション・ドメインに追加します。

Type = Header
Name = SP_SSO_UID
Return Attribute = $user.userid

この場合、次のようになります。

- 戻り属性は、ログインに使用されるログイン属性です。

- この認可ルールは、ルートのSharePoint Webサイト「/」を保護します。

関連項目:

認可ルールの詳細に関する第17章

LDAPメンバーシップ・プロバイダを使用したSharePointに対して認可レスポンスを作成するには:

1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MP認可ポリシー(ProtectedResourcePolicy)を開きます。
「認可ポリシーの検索」を参照してください。

2. 「認可ポリシー」の「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックします。

- 「名前」フィールドに、このレスポンスの一意の名前を入力します(SharePoint w/LDAP-MP).。

- 「タイプ」リストから「ヘッダー」を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

- 「適用」をクリックします。

- 必要に応じて繰り返します。

- 関連項目: 「SSOのポリシー・レスポンスの追加および管理」。

3. 「OAMAuthCookieのための認可レスポンスの作成」に進みます。

45.8.6 OAMAuthCookieのための認可レスポンスの作成

ここでは、次のOAMAuthCookieという名前のヘッダー変数を認可成功のレスポンスとしてアプリケーション・ドメインに追加します。

Type = Cookie
Name = OAMAuthCookie
Return Attribute = $user.userid

関連項目:

ポリシー・レスポンスの詳細に関する第17章

検証URLを保護するためのアプリケーション・ドメインを作成するには

1. Oracle Access Managementコンソールから、SharePoint w/LDAP-MPアプリケーション・ドメインを開きます。「認可ポリシー」: 保護されたリソース・ポリシー:
「認可ポリシーの検索」を参照してください。

2. 「レスポンス」タブをクリックして、「追加」ボタンをクリックします。
「リダイレクションURL」: この統合では不要です。

戻り値

Type = Cookie
Name = OAMAuthCookie
Return Attribute = $user.userid

- 「名前」フィールドに、このレスポンスの一意の名前を入力します(OAMAuthCookie)。

- 「タイプ」リストから「Cookie」を選択します。

- 「値」フィールドに、このレスポンスの値を入力します。例: $user.userid。

- 「適用」をクリックしてレスポンスを送信し、「確認」ウィンドウを閉じます。

- 必要に応じて繰り返します。

3. 「OAMCustomMemebershipProviderの構成およびデプロイ」に進みます。

45.8.7 OAMCustomMemebershipProviderの構成およびデプロイ

SharePointで次の構成ステップを実行し、Access Manager認証モジュールを使用してユーザーを認証して認可します。

注意:

Webgate_install_dir\access\oblix\apps\Webgate\OAMCustomMembershipProvider\samples\Sample.Default.aspxにバンドルされたデフォルトのログイン・ページを指定できます。

SharePointを構成してOAM認証モジュールを使用するには:

1. SharePoint Webサイト・ディレクトリの物理的な場所に移動します。次に例を示します。

C:\Inetpub\wwwroot\wss\VirtualDirectories\SharePoint website Name

2. folder_formsから、ファイルDefault.aspxをDefault.ORIG.aspxとしてコピーします。

3. Default.aspxを開き、</asp:login>を探し、その行の後に次のコードを追加して、ファイルを保存します。

<asp:HiddenField EnableViewState="false" ID="loginTracker" runat="server" Value="autoLogin" />

<%bool autoLogin = loginTracker.Value == "autoLogin";%>

<script runat="server">
void Page_Load()
{

signInControl.LoginError += new EventHandler(OnLoginError);
NameValueCollection headers = Request.ServerVariables;
NameValueCollection queryString = Request.QueryString;
string loginasanotheruser = queryString.Get("loginasanotheruser");
string username = Request.ServerVariables.Get("HTTP_SP_SSO_UID");
HttpCookie ObSSOCookie = Request.Cookies["ObSSOCookie"];
bool isOAMCredsPresent = username != null && username.Length > 0  && ObSSOCookie != null && ObSSOCookie.Value != null;
bool signInAsDifferentUser = loginasanotheruser != null && loginasanotheruser.Contains("true");

if (isOAMCredsPresent)
{

//Handling For UTF-8 Encoding in HeaderName
if (username.StartsWith("=?UTF-8?B?") && username.EndsWith("?="))
{
username = username.Substring("=?UTF-8?B?".Length, username.Length - 12);
byte[] decodedBytes = Convert.FromBase64String(username);
username = Encoding.UTF8.GetString(decodedBytes);
}
}
if (isOAMCredsPresent  && loginTracker.Value == "autoLogin" && !signInAsDifferentUser)
{
bool status=Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Site.Url),username,"ObSSOCookie:"+ObSSOCookie.Value);
if(status){
if (Context.Request.QueryString.Keys.Count > 1)
{
Response.Redirect(Context.Request.QueryString["Source"].ToString());
}
else
Response.Redirect(Context.Request.QueryString["ReturnUrl"].ToString());
}
else{
loginTracker.Value =
}

}
else
{

// DO NOTHING
}
}
void OnLoginError(object sender, EventArgs e)
{
loginTracker.Value = "";
}
</script>

4. IISマネージャに移動し、サイトの前のプラス・アイコン(+)をクリックします。

5. SharePoint Webサービスの前のプラス・アイコン(+)をクリックします。

6. 「SecurityTokenServiceApplication」を右クリックし、「エクスプローラ」をクリックします。

7. バックアップ・コピーWeb.configをWeb.config.ORIGとして作成し、Web.configを開きます。

8. メンバーシップ・プロバイダ・エントリで、LDAPメンバーシップ・プロバイダを有効にするには、<membership>、<providers>、タイプに移動し、タイプ値を次のように変更します。

type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1

9. ObSSOCookie検証メソッドの要件に応じて、次の2つの属性(ValidationMode="OAMAsdk"またはValidationMode="OAMHttp")をステップ8のエントリの最後に追加します。

注意:

ValidationMode="OAMAsdk"の場合、パラメータAsdkPath="<ASDK INSTALL PATH>"で指定したインストール・パスを使用してWin 64ビットASDKをインストールする必要があります。

<add name="membership"
type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1"
server="HOST1.COM"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="sAMAccountName"
userContainer="cn=users,dc=bored,dc=com"
userObjectClass="person"
userFilter="(&amp;(ObjectClass=person))"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn"
ValidationURL="/ValidateCookie.html"
OAMAuthUser="OAMAuthCookie
ValidationMode="OAMAsdk"
AsdkPath="C:\AccessServerSDK"
/>

注意:

ValidationMode="OAMHttp"の場合、検証URLを次に示すように指定する必要があります。

ValidationURL="http(s)://host:port/ValidateCookie.html"
OAMAuthUser="OAMAuthCookie"

注意:

検証URLのために構成するリソースは、Webサーバー上に存在する必要があります。また、OAMAuthUserパラメータの値は、ステップ6の説明に従って、認可戻りアクションとして構成する必要があります。

10. ファイルを保存します。

11. コマンド・プロンプトを使用して、次のディレクトリに移動します。

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe

12. 次のように入力します。

gacutil -l OAMCustomMembershipProvider

13. 結果が戻されないことを確認します。

14. 次のように入力します。

gacutil -i <Webgate_install_dir>\access\oblix\apps\Webgate\OAMCustomMembershipProvider\OAMCustomMembershipProvider.dll

15. 次のように入力します。

gacutil -l OAMCustomMembershipProvider

16. 1つの結果が戻されることを確認します。

17. SharePoint Webサイトを再起動します。

18. 次の手順を実行します。

- CustomMemeberShipProviderのロギングの有効化

- ディレクトリ・サーバーが同期化されていることの確認

- Microsoft SharePoint Server 2010のためのシングル・サインオフの構成

45.8.8 CustomMemeberShipProviderのロギングの有効化

Oracleカスタム・メンバーシップ・プロバイダのログを有効にする場合、Oracleカスタム・メンバーシップ・プロバイダの構成ファイルの「DebugFile」パラメータを構成する必要があります。たとえば、DebugFile=Location_of_logs_file"のサンプル・エントリは次のようになります。

type = "Oracle.CustomMembershipProvider, OAMCustomMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=52e6b93f6f0427a1" DebugFile="c:\Debug.txt"

45.8.9 ディレクトリ・サーバーが同期化されていることの確認

Access Managerに対して構成されているディレクトリ・サーバーのユーザーは、SharePointによって使用されるディレクトリ・サーバーと同期している必要があります(これらが異なる場合)。これは、この章の他の統合シナリオで実行したタスクと同じです。ただし、SharePointの統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートするディレクトリ・サーバーを使用できます。

関連項目:

ディレクトリ間のユーザー・プロファイルの同期化

45.8.10 統合のテスト

これは、この章の他の統合シナリオで実行したタスクと似ています。LDAPメンバーシップ・プロバイダを使用して構成した場合、違いはありません。

関連項目:

「SharePoint Serverの統合のテスト」

45.9 Officeドキュメントのためのシングル・サインオンの構成

Officeドキュメントのためのシングル・サインオンは、認証スキームで永続Cookieを設定することによって実現できます。このためには、認証スキームでssoCookie:max-ageを設定する必要があります。こうすることによって、複数セッション継続する永続Cookieが作成されます。

注意:

Windowsネイティブ認証に基づく統合の場合には、永続Cookieパラメータを設定する必要はありません。

Officeドキュメントのためのシングル・サインオンに永続Cookieを定義するには:

1. Oracle Access Managementコンソールにログインします。

2. 使用する「認証スキーム」を探し、ページを開きます。

3. 「チャレンジ・パラメータ」フィールドで、次を追加します。

ssoCookie:max-age=1000000   (Table 16-23)

ここで、time-in-secondsは、Cookieが期限切れになるまでの時間間隔を表します。たとえば、ssoCookie:max-age=3600の設定では、Cookieは1時間(3600秒)で期限切れになります。

4. 変更内容を保存します。

5. 第19章の説明に従って、10g Webgateの集中管理ログアウトを構成します。

45.10 Microsoft SharePoint Server 2010のためのシングル・サインオフの構成

ユーザーがSharePoint Server 2010から「ログアウト」ボタンをクリックすると、手動ログアウトされます。ユーザーがSharePoint Server 2010サイトから「ログアウト」ボタンをクリックしたときにAccess Managerのログアウトもトリガされるように、Access ManagerでSharePoint Server 2010のログアウトURLを構成することも可能です。

注意:

安全にために、常に、サインオフした後にブラウザ・ウィンドウを閉じることをお薦めします。

ユーザー・セッション全体がObSSOCookieによって制御されると、Cookieタイムアウトが発生します。次のユースケースについて考えてみます。

- FedAuth Cookieがタイムアウトになり、ObSSOCookieが依然として有効: ObSSOCookieが存在するため、ユーザーはチャレンジされません。新規FedAuth Cookieが生成されます(以前説明した同じフローを使用)。

- ObSSOCookieがタイムアウトになり、FedAuth Cookieが依然として有効: 各リクエストがWebgateによって捕捉されるため、ユーザーは再び資格証明を求められます。

Access Managerは、ユーザー・セッションに単一のログアウト(グローバル・ログアウトまたは集中管理ログアウトとも呼ばれる)を提供します。Access Managerでは、単一のログアウトはアクティブなユーザー・セッションを終了するプロセスを意味します。

このトピックは、SharePointとの統合に関してシングル・サインオフを構成する方法を説明します。シングル・サインオフは、ユーザー・セッションを削除します。

- SharePoint Server 2010でのカスタム・ログアウトURLの構成

- 偽装を使用したSharePoint Server 2010でのログアウトの構成

関連項目:

OAM 11gサーバーを使用した10g Webgateの集中管理ログアウトの構成の詳細に関する第15章

45.10.1 SharePoint Server 2010でのカスタム・ログアウトURLの構成

SharePoint Server 2010でカスタム・ログアウトURLを構成するには:

1. Webgateのために生成されたアーティファクトから、logout.htmlをSharePoint Server 2010サイトに追加します。

2. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATESを探します。

3. \CONTROLTEMPLATESで、次のタグを追加してwelcome.ascxを変更します。次に例を示します。

<SharePoint:MenuItemTemplate runat="server" id="ID_OverrideLogout" Text="Custom Logout"
ClientOnClickNavigateUrl="/logout.html?end_url=_layouts/SignOut.aspx"
Description="My Custom Logout"
MenuGroupId="200"
Sequence="100"
UseShortId="true" />

4. 「保存」をクリックします。

5. 匿名認証を使用して、アプリケーション・ドメインの2つのURL(/_layouts/SignOut.aspxと/_layouts/closeConnection.aspx)を保護します。

6. 偽装を使用したSharePoint Server 2010でのログアウトの構成に進みます。

45.10.2 偽装を使用したSharePoint Server 2010でのログアウトの構成

偽装を構成していない場合、この手順をスキップできます。

偽装を使用してSharePoint Server 2010でログアウトを構成するには:

1. signout.aspxをC:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTSから同じパスのMySignout.aspxにコピーします。

2. MySignout.aspxの(<asp:content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">)の下に、次のスクリプト詳細を追加します。

<script runat="server">
private void Page_Load(object sender, System.EventArgs e){
Response.Status = "302 Moved Temporarily";
Response.AddHeader("Location", "/logout.html?end_url=/_layouts/SignOut.aspx");}
</script>

3. 保存します。

4. 偽装の場合、このURL _layouts/Mysignout.aspxをSharePoint Server 2010のカスタム・ログアウトURLとして使用します。

5. 「統合のテスト」に進みます。

45.11 Access ManagerとWindowsネイティブ認証の設定

この項の内容は次のとおりです。

- Access Manager WNAの設定

- SharePoint Server 2010を使用したWNAの設定

- WNAおよびSharePoint Server 2010のためのAccess Managerのインストール

- WNA実装のテスト

45.11.1 Access Manager WNAの設定

第43章の説明に従って、Windowsネイティブ認証を使用するようにAccess Managerを構成します。

45.11.2 SharePoint Server 2010を使用したWNAの設定

次の概要では、Access ManagerおよびSharePoint Server 2010を使用してWNAを設定するために実行する必要があるタスクを説明します。

タスクの概要: SharePoint Server 2010を使用したWNAの設定

1. 次の前提条件となるタスクを実行します。

- 「必要なMicrosoftのコンポーネント」のタスクを実行します。

- 「Microsoft SharePoint Server 2010での新規Webアプリケーションの作成」の説明に従って、SharePoint Webサイトを作成します。

- 「Microsoft SharePoint Server 2010のための新規サイト・コレクションの作成」の説明に従って、SharePointサイト・コレクションを構成します。

- SharePointのドキュメントの説明に従って、構成をテストして、ディレクトリ・サーバーに存在するユーザーがSharePoint Webサイトにログインして適切なロールを取得できることを確認します。

2. 「WNAおよびSharePoint Server 2010のためのAccess Managerのインストール」の説明に従って、Access Managerをインストールします。
この手順には、IIS対応Webgateのインストールと個別のSharePoint WebサイトのためのWebgate.dllの構成が含まれます。

3. 次のようにActive Directory認証プロバイダを構成します。

1. WebLogicコンソールにログインします。

2. 「セキュリティ・レルム」に移動し、使用する「レルム」をクリックします。

3. 「プロバイダ」タブに移動し、「新規」をクリックします。

4. プロバイダ名を入力し、タイプActiveDirectoryAuthenticatorを選択して「OK」をクリックします。

5. 新しく作成したプロバイダを選択し、「制御フラグ」を「十分」に変更して、保存します。

6. 「プロバイダ固有」タブに移動し、Active Directoryの詳細を入力して、これらを保存します。

4. 「WNA実装のテスト」を実行します。

45.11.3 WNAおよびSharePoint Server 2010のためのAccess Managerのインストール

「タスクの概要: SharePoint Server 2010を使用したWNAの設定」のステップ1で説明しているすべての前提条件を実行した後、このタスクを実行します。この統合シナリオでほとんどのAccess Managerコンポーネントをインストールすることは、他のシチュエーションの場合と同じです。

IIS Webgateのインストールは、他の任意のWebgateのインストールと似ています。Webgateは、IIS v7 Webサーバーを使用してインストールする必要があります。後で、これを特定のSharePoint Webサイト・レベルで構成して保護できます。IISの場合、Webgateを「Webサイト」レベルで構成する必要があります。Microsoft SharePoint Server 2010の場合、Webgateを特定のSharePoint Webサイト・レベルで構成して保護する必要があります。

WNAおよびSharePoint Server 2010のためにAccess Managerをインストールするには:

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Access Managerをインストールします。

2. 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の次の章のステップを使用してISAPI Webgateをインストールします。

- Webgateのインストール

- IIS WebサーバーのためのWebコンポーネントのインストール
次に、保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。Webgate.dllを「Webサイト・レベル」で構成すると、IIS Webサーバー上のすべてのWebサイトが保護されます。しかし、Webgate.dllを「SharePoint Webサイト」で構成すると想定されるWebサイトのみが保護されます。

3. 保護の対象となるSharePoint WebサイトでWebgate.dllを構成します。次に例を示します。

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

4. 仮想ディレクトリの作成

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\

5. 仮想ディレクトリの権限の設定:

1. 手順3で作成したaccess仮想ディレクトリを選択します。

2. accessの「Home」ペインで「Handler Mappings」をダブルクリックします。「Action」ペインで「Edit Feature Permissions…」を選択します。

3. 「Read」、「Script」および「Execute」の横のボックスを選択してから、「OK」をクリックします。

6. 第43章の説明に従って、Windowsネイティブ認証を使用するようにAccess Managerを構成します。

7. Microsoft 2010 SharePointで新規Webアプリケーションを作成するときに、Microsoft SharePoint 2010認証をクラシック・モード認証に構成します。「認証プロバイダ」セクションで、ネゴシエート(Kerberos)を選択します。

8. IISで新しく作成したSharePointサイトに移動します。

1. 「認証」、Windows認証、詳細設定の順に開きます。

2. Kernelモード認証を有効にするを選択します。

3. プロバイダを選択して、NTLMプロバイダを削除します。

4. ネゴシエート:Kerberosを追加し、これを上位レベルに移動します。

5. IISを再起動します。

9. 「WNA実装のテスト」に進みます。

45.11.4 WNA実装のテスト

次のステップを使用して、WNA実装が正しく動作していることを確認します。

WNA実装をテストするには:

1. Access ManagerとWindowsオペレーティング・システムの両方のユーザーである人物としてマシンにログインします。

2. 保護されたリソースのURLを入力します。

45.12 ディレクトリ間のユーザー・プロファイルの同期化

特に明記しないかぎり、このタスクは、この章のすべての統合シナリオで実行する必要があります。

注意:

統合にLDAPメンバーシップ・プロバイダが含まれている場合、LDAPコマンドをサポートする任意のディレクトリ・サーバーを使用できます。

SharePoint ServerのディレクトリとAccess Managerのディレクトリの間でユーザー・プロファイルを同期化する必要があります。

- ユーザー・データのアップロード: Access ManagerのインストールがSharePoint Active Directory以外の任意のディレクトリ・サーバーに対して構成されている場合、他のディレクトリ・サーバーにあるユーザー・プロファイルをSharePoint Active Directoryにロードする必要があります。
「統合のテスト」に進みます。

45.13 統合のテスト

タスクを完了して統合を有効にした後、テストして統合が動作していることを確認する必要があります。

この項には次のトピックが含まれます:

- SharePoint Serverの統合のテスト

- SharePoint Serverの統合のためのシングル・サインオンのテスト

45.13.1 SharePoint Serverの統合のテスト

Access Managerの認証とSharePoint Serverの認可を使用してSharePoint Serverのリソースにユーザーがアクセスできることを確認できます。

SharePoint Serverの統合をテストするには:

1. ブラウザを使用して、任意のSharePoint Server Webページに移動します。
資格証明を求められます。

2. 必要な資格証明を提供してログインします。

3. リクエストしたページを表示できることを確認します。

4. オプション: イベント・ビューアを確認して、アクセス・リクエストが成功したことを確認します。

45.13.2 SharePoint Serverの統合のためのシングル・サインオンのテスト

資格証明を提供し、SharePoint Serverリソースにアクセスしたユーザーが(ObSSOCookieが期限切れになる前に)再び資格証明を提供せずに非SharePoint Serverリソースにアクセスできることを示してシングル・サインオンをテストすることもできます。たとえば、Policy Managerで定義したリソースを使用します。

シングル・サインオンが動作している場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

SharePoint Serverの統合のためにシングル・サインオンをテストするには:

1. アプリケーション・ドメインを使用して新規仮想サイトを作成して保護します(または、すでに作成したものを使用します)。

2. この仮想サイトのツリーのどこかにWebページを配置します。

3. ブラウザを使用して、新規仮想サイトのページに移動します。
すでに認証をパスしている場合、再び資格証明を提供する必要なく、ページへのアクセスが付与されます。

45.14 トラブルシューティング

- Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない

45.14.1 Internet ExplorerがSSL経由によるファイルのダウンロードを実行できない

この問題は、サーバーがCache-control:no-storeヘッダーまたはCache-control:no-cacheヘッダーを送信している場合に発生します。Webgateは、構成パラメータを提供して、これらのヘッダーの設定を制御します。次に、パラメータとそのデフォルト値を示します。

CachePragmaHeader no-cache

CacheControlHeader no-cache

Webgate構成を変更して、これらのヘッダーをまったく設定しないようにできます(これらのパラメータの値は空白のままになります)。こうすることによって、Access Managerはキャッシング動作を制御しなくなります。

第XII部

付録

第XII部では、Oracle Access Management 11.1.2を使用する日常の管理タスクの範囲外の情報について説明します。

第XII部は、次の付録で構成されます。

- 付録A、「Oracle ADFアプリケーションとAccess Manager SSOの統合化」

- 付録B「10g Webgateの国際化とマルチバイト・データ・サポート」

- 付録C「通信の保護」

- 付録D「バンドル、生成および移行されるアーティファクトの確認」

- 付録E「トラブルシューティング」

A Oracle ADFアプリケーションとAccess Manager SSOの統合

Oracle Application Developer Framework(ADF)とOracle ADF標準にコード化されたアプリケーションは、OPSS SSO Frameworkとのインタフェースです。Oracle Platform Security Services(OPSS)のシングル・サインオン・フレームワークは、あるドメインのアプリケーションをシングル・サインオン(SSO)ソリューションと統合する方法を提供します。

ユーザー認証のために、Oracle ADFセキュリティを使用するWebアプリケーションおよびOPSS SSOフレームワークを、Access Manager SSOのセキュリティ・プロバイダと統合できます。この章の内容は次のとおりです。

- Oracle Platform Security ServicesおよびOracle Application Developer Frameworkの概要

- Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したAccess ManagerとWebアプリケーションの統合

- Oracle ADFコード・アプリケーションの集中ログアウト構成

- 実行時のアプリケーションドリブン認証の確認

A.1 Oracle Platform Security ServicesおよびOracle Application Developer Frameworkの概要

この項の内容は次のとおりです。

- Oracle Platform Security Servicesシングル・サインオン・フレームワーク

- Oracle Application Developer Framework

A.1.1 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 Frameworkとのインタフェースです。Oracle ADFの詳細は、「Oracle Application Developer Framework」を参照してください。

Access Manager SSOソリューションは即時利用可能で、Oracle ADF標準にコード化されたアプリケーションとOPSS SSOフレームワークに次のものを提供します。

- ログイン(アプリケーションドリブン): 認証を必要とするセキュアなアーティファクトの一部にアクセスするときに、アプリケーションは認証を起動し、ユーザーをリダイレクトして適切なソリューションにより認証されるようにします。

- 自動ログイン: アプリケーションに最初にアクセスするユーザーは、アカウントをアプリケーション(Oracle Identity Managerなど)に匿名で登録します。正常に登録されると、ユーザーは認証URLにリダイレクトされます。またユーザーは要求されることなく自動的にログインできます。

- グローバル・ログアウト: ユーザーがアプリケーションからログアウトすると、そのログアウトはソリューションにより有効になっているその他のアプリケーション全体に伝播します。

注意:

OPSS SSOフレームワークはマルチレベル認証をサポートしていません。

関連項目:

SSOソリューションおよびAccess Managerソリューションの選択の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「シングル・サインオン構成」の部分を参照してください。

A.1.2 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アップグレード・ガイド』を参照してください。

A.2 Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したAccess ManagerとWebアプリケーションの統合

この項では、Oracle ADFセキュリティおよびOPSS SSOフレームワークを使用するWebアプリケーションと、ユーザー認証用のAccess Manager SSOセキュリティ・プロバイダの統合方法について説明します。

Webアプリケーションを実行する前に、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)

表A-1はaddOAMSSOProviderコマンドラインの各引数に必要な値を定義します。

表A-1 addOAMSSOProviderコマンドライン引数

引数

定義

loginuri

ログイン・ページのUIRを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、"/<context-root>/adfAuthentication"を'loginuri'パラメータに指定する必要があります。手順を示します。

1. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

2. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

3. Access Managerには'loginuri'の値を保護するポリシー、たとえば、"/<context-root>/adfAuthenticationが存在する必要があります。

4. ADFがこのURIにリダイレクトすると、Access Managerにより「ログイン」ページが表示されます(このURI用のAccess Managerで構成された認証スキームにより異なる)。

logouturi

ログアウト・ページのUIRを指定します

注意: ADFセキュリティが有効なアプリケーションの場合、logouturiを第19章のログアウト・ガイドラインに基づいて構成する必要があります。対象

- 11g Webgateでは、logouturiの値は11g Webgateの管理者から検索される必要があります。

- 10g Webgateでは、logouturiの値は"/oamsso/logout.htmlである必要があります。

autologinuri

自動ログイン・ページのUIRを指定します

Oracle ADF Securityが有効なFusion Webアプリケーション用にドメイン・レベルjps-config.xmlを構成する手順は、より大きなタスクの一部です。コマンド構文を除き、すべてのタスクはAccess Manager 10gと11gとで同じです。

詳細は、次を参照してください。

- Access Manager用のSSO構成のサンプル

- SSOプロバイダ構成詳細

関連項目:

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスの章「インフラストラクチャ・セキュリティ・コマンド」

A.2.1 Access Manager用のSSO構成のサンプル

すべてのタスク(Access Manager SSOプロバイダおよびOAM構成例を含む)用に『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明されている手順で入力したSSOサービス構成は、ファイルjps-config.xmlに書き込まれます。指定されたデータには次のものが含まれます。

- 特定のSSOサービス

- 自動ログインおよび自動ログアウトURI

- 認証レベル

- 選択したSSOサービスにより戻されるURLに含まれる問合せパラメータ

- トークン生成に適した設定

jps-config.xmlファイルにある次のコードはAccess Manager SSOプロバイダの構成を示しています。いくつかの値は実際の内容に対するプレースホルダにすぎません。使用する構成では実装用の値を含む必要があります。

関連項目:

「SSOプロバイダ構成詳細」

例A-1 Access Manager用の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>

A.2.2 SSOプロバイダ構成詳細

次の重要な点に注意してください。

- SSOプロバイダは少なくともフォーム・ログイン用のURIをプロパティlogin.url.FORMを使用して定義する必要があります。値はURLである必要はありません。

- アプリケーションが自己登録ページURIまたはURLをサポートする場合、プロパティautologin.urlを使用して指定する必要があります。

- SSOソリューションがグローバル・ログアウトURIまたはURLをサポートする場合、プロパティlogout.urlを使用して指定する必要があります。OAMソリューションはグローバル・ログアウトをサポートします。

- 例A-1に示す次のプロパティはオプションです。

- param.login.successurl

- param.login.cancelurl

- param.autologin.targeturl

- param.login.token

- param.logout.targeturl

- プロパティ・セットprops.auth.uri内の値などのURI仕様における変数app.contextは、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は例A-1に示すように"2"に設定する必要があります。

- SSOプロバイダのサービス・インスタンス内のプロパティ token.typeが必要です。
このトークンのタイプは、正常な認証後にSSOプロバイダが発行するHTTPリクエストのトークン・セットを特定します。2回目以降は、このトークンがSSOプロバイダで使用されるので、ユーザーの再認証が不要となり、ユーザーのサインオンが引き続き有効となります。OAMソリューションの場合、例A-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>

A.3 Oracle ADFコード・アプリケーションの集中ログアウト構成

Access Manager SSOソリューションは、Oracle ADF標準およびOPSS SSOフレームワークに従ってコーディングされたアプリケーションに使用できます。Access Managerでログアウトを実行するように構成されたADFコード・アプリケーションは、/oamsso/logout.htmlリソースにリダイレクトします。

IAMSuiteAgentはリクエストのインターセプトと処理を行い、セッションをクリーン・アップし、集中ログアウト・ページにリダイレクトして(OAMサーバーにより実行)再びend_urlにリダイレクトします。

関連項目:

Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド

注意:

ADFアプリケーションの場合は、追加的な構成ステップが1つだけ必要です(OPSS用にOAMSSOProviderを構成)。

タスクの概要: Access ManagerによるADFアプリケーションの保護

1. 「Oracle ADF標準に従ってコーディングされたアプリケーションの集中ログアウト処理について」を確認してください。

2. 以下のどちらかを使ってADFコード・アプリケーションを保護します。

- 11g Webgate

- 10g Webgate

3. ADFコード・アプリケーション用に追加的な構成ステップを1つ実行します: 「Access Manager使用時のADFコード・アプリケーションの集中ログアウト構成」の説明に従ってOAMSSOProviderを構成してください。

4. 選択したWebgateのバージョンに合わせてログアウト構成ステップを実行します。

A.3.1 Oracle ADF標準に準拠してコードが記述されたアプリケーションでの一元化されたログアウト処理について

ADFコード・アプリケーションとは、ADFと完全に統合化されたアプリケーション、またはADF認証サーブレットだけを使用してOPSSとの統合化を図るアプリケーションを言います。

この場合、ログアウトは、ADFアプリケーションがログアウトURIを呼び出した時に開始されます。次のプロセスは、Oracle ADF標準に従ってコーディングされたアプリケーションのAccess Manager集中ログアウト・プロセスの概要です。

プロセス概要: 10g Webgate使用時のADFアプリケーションの集中ログアウト

1. ADFアプリケーションは以下のURIを呼び出します。

/<application 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を含むページをユーザーのブラウザに送信します。

注意:

表13-3に示すように、ログアウト・コールバックURLは、展開された(短縮されていない)OAMエージェント登録で指定されます。

3. コールバック・ページから、各Webgateの特定URIに対して新しいリクエストが開始されます。このリクエストが特定ドメインの特定Webgateに届くと、そのドメインのObSSOCookieは消去されます。

4. ユーザーは、ログアウト・スクリプト内のend_urlにリダイレクトされます。ただし、end_urlパラメータがない場合はOAMサーバーによって適切なメッセージが送信されます。

A.3.2 Access Managerでの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から呼び出す必要があります。

関連項目:

- 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. 11g Webgate: 「11g Webgateの集中ログアウト構成」の手順を実行します。

5. 10g Webgate: 「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」のステップを実行します。

関連項目:

Access ManagerのIDアサーションのプロバイダ設定の詳細は、「シナリオ: Access Managerトークンを使用したアイデンティティ伝播」

A.4 実行時のアプリケーションドリブン認証の確認

この章でこれまでに述べたように、これは認証を起動し、ユーザーをリダイレクトして、適切なソリューションで認証されるようにするアプリケーションです。たとえば、認証が必要なセキュアなアーティファクトの一部にユーザーがアクセスしているとアプリケーションが判断すると、この場合はAccess Manager SSOを使用して、アプリケーションドリブン認証が起動されます。

実行時にアプリケーションドリブン認証を確認する手順

1. Oracle ADFフレームワークに基づくアプリケーションを作成します。

2. 「Oracle ADF SecurityおよびOPSS SSOフレームワークを使用したAccess ManagerとWebアプリケーションの統合」の説明に従い、Access Manager SSO Securityプロバイダを構成します。

3. 保護されたフィールドにアクセスし、アプリケーションが認証を起動することを確認します。

B 10g Webgateの国際化とマルチバイト・データ・サポート

ここに記載する情報は、10g Webgateを使用している場合に対象となる可能性があります。

- 国際化とマルチバイト・データ・サポートの概要

B.1 国際化とマルチバイト・データ・サポートの概要

Access Managerは、変更を加えずにどこでも同時にアクセスおよび実行が可能で、ユーザーの母国語とロケール設定でコンテンツを表示する、多言語アプリケーションとソフトウェア製品を提供します。

ロケールとは、システムまたはプログラムが実行している、言語および文化的な環境のことです。ロケールと関連付けられたデータは、日付、時刻、数値、通貨などの、指定の言語および国に対応する言語的、文化的な要件に基づくものの書式設定および解析のサポートを提供します。

Oracle製品のグローバリゼーションは、国際化とローカライズを含む2つの部分からなるプロセスです。国際化(時々"I - 18文字 -N"を意味するI18Nと略される)では、ソフトウェア製品およびアプリケーションが、あらゆるサポートしているオペレーティング・システムが(サポートしている言語で)実行し、US以外のキーボードまたはその他の国固有のハードウェアを装備したコンピュータ上で使用できる必要があります。Oracleアプリケーションは、言語文字列へのハードコードされた依存はなく、他の製品のUS以外のバージョンと相互運用します。Oracleアプリケーションは分散環境でマルチバイト文字と差異を処理することができ、ユーザーの要求するロケールを検知することもできます。Access Managerはこれらの要件を満たし、Unicode規格4.0に準拠しています。

ローカライズには個別のファイル・テキストの翻訳が含まれます。Oracle製品では、データの書式設定、照合、通貨、日付、時刻およびテキストの方向(右から左または左から右)など、ユーザーの地域の表記規則に従った方法で情報が表示されます。

詳細は、次を参照してください。

- ローカライズされたメッセージの言語

- 双方向言語サポート

- UTF-8エンコーディング

B.1.1ローカライズされたメッセージの言語

翻訳可能な情報は、エンドユーザー情報(すべてのユーザーがアクセス可能)と管理情報(管理者権限を持つユーザー用)の2つのタイプに分類できます。Oracle Access Manager 10.1.4を言語パックなしでインストールすると、英語が管理者およびエンドユーザーのデフォルトの言語になります。10.1.4をOracle提供の言語パックを使用してインストールすると、管理用アクティビティのデフォルトとして使用する言語を選択できます。インストール時に選択したデフォルトの管理者言語にかかわらず、英語は必ずインストールされます。

注意:

新機能の結果としてマイナー・リリース(10g(10.1.4.2.0)および10g(10.1.4.3))に追加されたメッセージは翻訳されていない可能性があり、英語のみで表示される場合があります。

エンド・ユーザーに対して静的アプリケーション・データ(エラー・メッセージ、およびタブ、パネル、プロパティの表示名など)を表B-1で識別されるエンド・ユーザー言語で表示できます。管理情報は、表B-1にリストされた管理者言語でのみ表示できます。その他の言語で(ブラウザ設定により)管理ページがリクエストされた場合、製品のインストール時に選択されたデフォルト言語が管理ページの表示に使用されます。

表B-1 ローカライズされたメッセージの言語

インストール・ディレクトリの言語タグ

エンド・ユーザー情報

管理者

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

トルコ語

B.1.2 双方向言語のサポート

ほとんどの欧米言語は左から右(LTR)、ページの上から下へ書かれます。東アジア言語は通常上から下へ、ページの右から左へ(RTL)へ書かれますが、多くの場合、欧米言語から翻訳された技術書は例外です。

ヘブライ語やアラビア語などの一部の言語は、大部分は右から左へ書かれて読まれます。アラビア語およびヘブライ語では数字の方向は逆になります。テキストは右から左へ書かれますが、ヨーロッパ言語やその他のLTR言語と同様に、文中の数字は左から右へ書かれ、最上位桁が左になります。

LTR言語がRTL言語と混在する場合、ドキュメントまたはコンテンツ全体は双方向と見なされます。Access Managerは、双方向言語をサポートできます。ホスト・コンピュータ上のブラウザが双方向言語を使用するように構成されていれば、Access Managerはそれを適切に処理します。

注意:

双方向言語サポートを必要とする管理言語はありません。

複数の言語および双方向言語のサポートを提供するために、Access Manager 10.1.4はエンコード用にUnicode規格をサポートします。

注意:

書く方向は文字のエンコードに影響を与えません。書く方向にかかわらず、データは画面に表示される順序ではなく、論理的な順序、つまり言語を入力するユーザーが使用する順序で保存されます。

B.1.3 UTF-8エンコーディング

新しく10.1.4をインストールした場合も、古いインストールをAccess Managerにアップグレードした場合も、UTF-8エンコーディングおよびサポートが自動的に提供されます。環境を変更する必要はありません。以前のリリースと同様に、ディレクトリ・サーバーのデータはUTF-8エンコーディングを使用して格納されます。

注意:

ディレクトリ・データはすべてUTF-8形式です。Access Managerでは、ディレクトリ内でのデータ型の混在をサポートしていません。

C 通信の保護

この付録では、OAMサーバーおよびクライアント(OAMエージェント)がアクセス・プロトコル・チャネルを介して安全に通信できるようにするために必要な情報と手順について説明します。この章の内容は次のとおりです。

- 前提条件

- OAMサーバーとWebgate間の安全な通信の概要

- 証明書モードのOAMテスターのクライアント・キーストア生成

- Access Managerの証明書モード通信の構成

- Access Managerの簡易モード通信の構成

C.1 前提条件

OAMサーバーが実行中であることを確認してください。

SSL自動化ツールの使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

C.2 OAMサーバーとWebgate間の安全な通信の概要

OAMサーバーとクライアント(Webgate)間の通信を保護するということは、コンポーネント登録ページ内のNAP (OAPとも呼びます)チャネルに対してトランスポート・セキュリティ・モードを定義することを意味します。チャネルのセキュリティ・レベルは、次のいずれかに指定されます。

- オープン: 暗号化されていない通信
オープン・モードでは、WebgateとOAMサーバー間で認証または暗号化は行われません。WebgateはOAMサーバーのアイデンティティの証明を要求せず、OAMサーバーはすべてのWebgateからの接続を受け入れます。オープン・モードは、通信のセキュリティがデプロイメントで問題にならない場合に使用します。

- 簡易: Oracleにより発行された公開鍵証明書を使用したSecure Sockets Layer(SSL)プロトコルによる暗号化された通信
簡易モードは、プレーン・テキストでパスワードを送信したくないといったセキュリティ上の懸念があるものの、独自の認証局(CA)を管理しない場合に使用します。この場合、OAMサーバーおよびWebgateはOracle CAにより発行および署名された同じ証明書を使用します。詳細は、「簡易モード、暗号化および鍵について」を参照してください。

- 証明書: 信頼されているサード・パーティ認証局(CA)により発行された公開鍵を使用したSSLによる暗号化された通信。
証明書モードは、OAMサーバーとWebgateで異なる証明書を使用し、信頼されているサード・パーティCAにアクセスできる場合に使用します。このモードでは、DESアルゴリズムを使用して秘密鍵を暗号化する必要があります。Access ManagerコンポーネントはPEM形式でのX.509デジタル証明書のみを使用します。PEMとはプライバシ強化メールのことであり、パスフレーズが必要です。PEM(プライバシ強化メール)形式は秘密鍵、デジタル証明書、および信頼されている認証局(CA)に適しています。望ましいキーストア形式はJKS(Java KeyStore)形式です。詳細は、「証明書モードの暗号化およびファイルについて」を参照してください。

関連項目:

「証明書、認証局および暗号化鍵について」

図C-1に、ユーザー認証および認可中にOAMサーバーおよびWebgateにより使用される通信チャネルを示します。論理的に、リクエストはAccess Manager資格証明コレクタに送信されます。ただし、Webサーバー・プロキシがWebLogic AdminServerの前にある場合、<LocationMatch "/*">によって、すべてのリクエストがプロキシ経由でルーティングされます。この場合、プロキシを使用した周辺防衛が存在します。

図C-1 OAMサーバーとWebgateの通信チャネル

「図C-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)形式です。Access Managerコンポーネントは、DER(バイナリ形式の証明書)形式のみのX.509デジタル証明書を使用します。

詳細は、次を参照してください。

- 「証明書、認証局および暗号化鍵について」

- セキュリティ・モードおよびX509Scheme認証について

- Importcertツールについて

C.2.1 証明書、認証局および暗号化鍵について

公開鍵インフラストラクチャにより、デジタル証明書は次のものに基づきWebベースのトランザクションの資格証明を確立します。

- 証明書の所有者の名前

- 証明書のシリアル番号

- 証明書の有効期限

- 証明書の所有者の公開鍵のコピー、これはメッセージおよびデジタル署名の暗号化に使用されます

- 証明書を発行する認証局のデジタル署名が提供されて、受信者はその証明書が本物であることを確認できます

デジタル証明書はレジストリに格納でき、そこから認証ユーザーが他のユーザーの公開鍵を検索できます。

暗号化では、公開鍵は暗号化キーとして使用される、指定した認証局により提供された値です。公開鍵を使用するためのシステムは公開鍵インフラストラクチャ(PKI)と呼ばれます。公開鍵インフラストラクチャの一部として、認証局は登録局(RA)に問合せてデジタル証明書のリクエスタにより提供された情報を検証します。RAがリクエスタの情報を検証すると、CAは証明書を発行できます。

秘密鍵は公開鍵から導出できます。公開鍵および秘密鍵の組合せは非対称暗号と呼ばれ、メッセージおよびデジタル署名を効果的に暗号化するのに使用できます。

関連項目:

- 「証明書モードの暗号化およびファイルについて」

- 「簡易モードの暗号化および鍵について」

C.2.2 セキュリティ・モードおよび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://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509

注意:

相対的なチャレンジURLをX509Schemeで指定した場合、OAMサーバーは指定したサーバーホスト/ポートを使用してX509資格証明コレクタの完全修飾URLを構築します。ただし、この構成は動作しません。

関連項目:

「SSOトークンとIPの検証の管理」

C.2.3 Importcertツールについて

管理者はOracleが提供するimportcertツールを、キーストア、キーおよび証明書に関連した様々な手順で使用します。表C-1は、importcertコマンドの構文を示しています。

表C-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>

キーストア・パスワードを、求められたら入力します。

C.3 証明書モードの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. それぞれの環境に応じて次の手順を実行します。

- Access Managerの証明書モード通信の構成

- Access Managerの簡易モード通信の構成

3. キーストアの削除: 次のコマンドを使用して、JKSキーストアを削除します。例:

keytool -delete -alias <alias> -keystore  <path to clientkey.JKS> -storetype <JKS>

キーストア・パスワードを、求められたら入力します。

C.4 Access Manager用の証明書モード通信の構成

この項では、Access Managerの証明書モード通信の構成方法について説明します。

次のタスクは証明書モードにのみ適用されます。簡易モードでは、バンドルされたOAM-CA署名付き証明書が使用されて、次のタスクのほとんどは必要ありません。

タスク概要: OAMサーバーの証明書の追加には次のものが含まれます。

1. 次の内容の確認:

- OAMサーバーとWebgate間の安全な通信の概要

- 証明書モードの暗号化およびファイルについて

2. OAMサーバー用の証明書リクエストおよび秘密鍵の生成

3. OAMキーストア別名およびパスワードの取得

4. 信頼できる、署名された証明書チェーンをキーストアへインポート

5. 証明書詳細をAccess Manager設定に追加

6. Webgate用の秘密鍵および証明書リクエストの生成

7. 証明書を使用するようにWebgateを更新

C.4.1 証明書モードの暗号化およびファイルについて

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にコピー)する必要があります。

C.4.2 OAMサーバー用の証明書リクエストおよび秘密鍵の生成

次の手順を使用して、秘密鍵、証明書およびOAMサーバーのCA証明書を取得します。

注意:

10gと11gの登録間の一貫性を保つための認証ツールはopenSSLです。証明書およびキーをPEM形式で生成するには、他のツールではなくopenSSLを使用することをお薦めします。

OAMサーバーの秘密鍵および証明書を取得するには:

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キーストア別名およびパスワードの取得」に進みます。

C.4.3 OAMキーストア別名およびパスワードの取得

有効な管理者証明書を持つユーザーは、次のタスクを実行して、認証に使用される指定キーストア内の証明書の別名と、証明書のインポートに必要なパスワードを取得できます。

OAMキーストア・パスワードを取得する手順

1. Oracle Access Managementコンソールが実行中であることを確認してください。

2. Oracle Access Managementコンソールをホストしているコンピュータで、キーストア・パスワードの取得時に使用するOAMインストール・パスのWebLogic Scripting Toolを探します。例:
$ORACLE_IDM/common/bin/

ここで、$ORACLE_IDMはOracle Access Managementのベース・インストール・ディレクトリで、/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は、Access Managerによって使用されるキーストアの名前を表します。

7. 表示されるOAMキーストアのパスワードは、証明書のインポートに必要なため、最新の注意を払ってください。

8. 「信頼できる、署名された証明書チェーンをキーストアへインポート」に進みます。

C.4.4 信頼できる、署名された証明書チェーンをキーストアへインポート

Oracleが提供するimportcertツールは、既存の秘密鍵、署名済証明書(公開鍵)ファイルを指定のキーストア形式であるJKS (クライアント・キーストア形式)またはJCEKS (OAMサーバー・キーストア形式、たとえば .oamkeystore)へインポートするために使用します。

Access Managerに関連付けられたキーストアはPKCS8 DER形式の証明書のみを受け入れます。

- PEM形式の証明書が認証局(CA)によって署名されている場合、次の手順はAccess Managerに付属しているimportcertを使用してこれらの証明書を変換した後にインポートする方法を説明します。

- PEM形式の証明書がない場合は、証明書リクエストを作成してCAで署名を受けた後で、次の手順を開始してください。

次にJDKバージョン6のkeytoolを使用するための手順を示します。異なるバージョンのkeytoolの場合、そのJDKバージョンのドキュメントを参照してください。

注意:

keytoolユーティリティを使用する場合、デフォルトの鍵ペア生成アルゴリズムはデジタル署名アルゴリズム(DSA)です。ただし、Oracle Access ManagementおよびWebLogic ServerはDSAをサポートしないので、別の鍵ペア生成および署名アルゴリズムを指定する必要があります。

前提条件

OAMキーストア別名およびパスワードの取得

信頼できる証明書チェーンをキーストアにインポートする手順

1. 次のパスでキーツールを探します。

$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設定に追加」に進みます。

C.4.5 証明書詳細をAccess Manager設定に追加

証明書をキーストアにインポートした後で、先ほど指定した別名およびパスワードを、Oracle Access ManagementコンソールでAccess Manager設定構成に、ここでの説明に従って追加する必要があります。

注意:

簡易モードには明示的な構成は必要なく、即時可能な状態で提供されます。

前提条件

信頼できる、署名された証明書チェーンをキーストアへインポート

関連項目:

- 「OAMプロキシの簡易および証明書モードのアクセス・プロトコルの管理のセキュリティ」

証明書詳細をAccess Manager設定に追加する手順

1. Oracle Access Managementコンソールで、「システム構成」タブをクリックします。

2. 「システム構成」タブの「Access Manager」セクションで、「Access Managerの設定」ページを開きます。

3. ページの「アクセス・プロトコル」セクションを、必要に応じて展開します。

4. 前の手順で取得した別名および別名パスワード詳細を入力します。例:
証明書モード構成

PEMキーストア別名: my_keystore_alias

PEMキーストア別名のパスワード: my_keystore_alias_pw

5. 「適用」をクリックして構成を保存します。

6. ページを閉じます。

7. OAMサーバー登録ページを開き、「プロキシ」タブをクリックし、プロキシ・モードを「証明書」に変更して「適用」をクリックします。

8. OAMサーバーを再起動します。

9. 「Webgate用の秘密鍵および証明書リクエストの生成」に進みます。

C.4.6 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を更新」に進みます。

C.4.7 証明書を使用するようにWebgateを更新

すべての通信モード(オープン、簡易または証明書)で、エージェント登録はOracle Access Managementコンソールから更新する必要があります。

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インスタンスを再起動します。

C.5 Access Managerの簡易モード通信の構成

トランスポート・セキュリティ通信モードはOAMのインストール中に選択されます。簡易モードのとき、インストーラは最初にランダムなグローバル・パスフレーズを生成しますが、これは後で必要に応じて編集できます。

OAMエージェントまたは新しいOAMサーバーを登録するときにモードを指定できます。しかし、グローバル・パスフレーズの変更には、簡易モードを使用するすべてのエージェントと新しいグローバル・パスフレーズの再構成が必要です。

エージェントの登録中に、少なくとも1つのOAMサーバー・インスタンスがエージェントと同じモードで実行していることが必要です。そうでないと、登録は失敗します。ただし、エージェントの登録後、OAMサーバーの通信モードを変更できます。

注意:

エージェントとサーバー間の通信は、WebgateモードがOAMサーバー・モードと同じか、またはそれ以上であれば動作します。

エージェント・モードは高くても問題ありませんが、低くしないでください。最高レベルのセキュリティは「証明書」モードで、最も低いのは「オープン」モードです。

証明書」モード、「簡易」モード、「オープン」モード

この項では、簡易モード通信の構成に必要な情報を提供します。

タスク概要: 簡易モード通信の構成には次のことが含まれます

1. 次の内容の確認:

- 「簡易モードの暗号化および鍵について」

- 「Importcertツールについて」

2. 簡易モード用のグローバル・パスフレーズの取得

3. 簡易モード用Webgate登録の更新

4. 簡易モード構成の検証

C.5.1 簡易モード、暗号化および鍵について

簡易モード暗号化の場合、Access Managerには認証局がその固有の秘密鍵とともに含まれ、すべてのWebgateおよびOAMサーバーにインストールされます。インストール中に、OAMサーバーの秘密鍵-公開鍵のペアが生成され、保存されます。OAMエージェントのインストールでも同様にOracle認証局がインストールされます。

インストーラは最初にランダムなグローバル・パスフレーズを生成しますが、これは必要に応じて編集または表示できます。エージェントがSIMPLE(簡易)モードで登録されていると、次のクライアント証明書が生成され、クライアントにより使用されます。

- aaa_key.pem: 秘密鍵が含まれています

- aaa_cert.pem: 署名された証明書

- password.xml: ランダムなグローバル・パスフレーズが不明瞭化された形式で含まれています

注意:

グローバル・パスフレーズを変更すると、「簡易」モードですでに構成されているすべてのエージェントの再構成が必要になります。

C.5.2 簡易モード用のグローバル・パスフレーズの取得

Access Managerは「簡易」モード通信用のランダムなグローバル・パスフレーズを、インストール中に生成します。次の手順では、このパスワードを取得する方法を説明します。

「簡易」モード通信用のランダムなグローバル・パスフレーズを取得する手順

1. Oracle Access Managementコンソールが実行中であることを確認します。

2. Oracle Access Managementコンソールをホストしているコンピュータで、次のパスにあるWebLogic Scripting Toolを探します。例:

$Oracle_IDM/common/bin

ここで、$Oracle_IDMはベース・インストール・ディレクトリで、/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登録の更新」に進みます。

C.5.3 簡易モード用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インスタンスを再起動します。

C.5.4 簡易モード構成の検証

簡易モードへの変更をインスタンス化するためにWebサーバーを再起動する必要があります。次にその結果を検証できます。

簡易モードの変更を検証する手順

1. コマンドライン・ウィンドウからWebサーバーを再起動します。例:

d:\middleware\ohs_home\instances\ohs_webgate11g\bin
opmnctl stopall
opmnctl startall

2. ブラウザ・ウィンドウで、簡易モードを使用してWebgateにより保護されているリソースへのURLを入力します。

3. 求められたら、ログイン資格証明を入力します。

4. リソースが実行中であることを確認してください。

D バンドル、生成および移行されるアーティファクトの確認

この付録では、Access Managerでバンドルまたはエージェント登録中に生成されるアーティファクトの例を見ていきます。この付録の内容は次のとおりです。

- バンドルされる10g IAMSuiteAgentアーティファクト

- 生成されるアーティファクト: OpenSSO

- 移行されるアーティファクト: OpenSSO

D.1 バンドルされる10g IAMSuiteAgentアーティファクト

ここでは、次の内容について説明します。

- 事前登録される10g IAMSuiteAgent

- IAMSuiteAgentセキュリティ・プロバイダの設定、WebLogic管理コンソール

- IAMSuiteAgent登録

- IAMSuiteAgentによって保護されるリソース

- 事前シード済のIAM Suiteアプリケーション・ドメインおよびポリシー

D.1.1 事前登録済の10g IAMSuiteAgent

この10g OAMエージェントと付属アプリケーション・ドメイン(第17章を参照)は11.1.1.5で使用できます。これらの定義は変更しないことをお薦めします。

注意:

従来のIDMDomainAgentは、このパッチ・セットでは利用できません。パッチ・セットの適用後は、アーティファクトとして残ります。ただし、内容はすべて削除されます。

IAMSuiteAgentは、IDM管理コンソールにシングル・サインオン機能を提供します。IAMSuiteAgentは、OAMサーバーのインストールと構成の一部としてインストールされ、事前構成されています。

IAMSuiteAgentは、ドメイン全体のエージェントです。

- 一度デプロイされると、IAMSuiteAgentはドメイン内のすべてのサーバーにインストールされます。

- 無効にしないかぎり、WebLogicアプリケーション・サーバーに入ってくるすべてのリクエストは、IAMSuiteAgentによって評価および処理されます。

- 構成の詳細は、Oracle Access Managementコンソールの「10g Webゲート」ノード(「ポリシー構成」タブ)の下にあります。

特定のIAMSuiteAgent構成の要素はWebLogic管理コンソール(「セキュリティ・プロバイダ」セクション)に、その他の要素はOracle Access Managementコンソールにあります。

D.1.2 IAMSuiteAgentセキュリティ・プロバイダの設定、WebLogic管理コンソール

WebLogic管理コンソールの「セキュリティ・プロバイダ」セクションには、ブートストラップ構成パラメータが5つあります。

これらは変更せずに保持することをお薦めしますが、次のパラメータのいずれかを変更することが必要な場合があります。

- プライマリ・アクセス・サーバー: この値は、実際のOAMサーバーの情報で置き換えることができます。複数のホストがIDMドメインの一部である場合は、デフォルト値(localhost:5575)を実際のOAMサーバーの情報で置き換えられます。IAMスイート・エージェントとその付属アプリケーション・ドメイン(IAMSuite)は、11.1.1.3.0 IDMドメイン・エージェントとその付属アプリケーション・ドメインを置換するものです。エージェント・パスワード: デフォルトではパスワードはありません。ただし、NetPoint (現在はOracle) Access Protocol (NAPまたはOAP)を介してOAMサーバーにIAMSuiteAgent接続するときのパスワードを確立する場合には、ここで追加できます。

図D-1は、IAMSuiteAgentのデフォルトの「セキュリティ・プロバイダ」の設定を示します。

図D-1 WebLogic管理コンソールでのIAMSuiteAgent設定

「図D-1 WebLogic管理コンソールでのIAMSuiteAgent設定」の説明

D.1.3 IAMSuiteAgent登録

IAMSuiteAgentの登録ページには、他のOAMエージェント登録ページと同様、エージェントに関する詳細が表示されます。

- セキュリティ・モード: IAMSuiteAgentで使用できるセキュリティ・モードは「オープン」のみです。これは変更できません。

- 優先ホスト: IAMSuiteAgentはあらかじめ構成されたホストで、このエージェントで必要です。

注意:

ここのアクセス・クライアント・パスワードは、WebLogic管理コンソールのエージェント・パスワードと一致する必要があります。エージェント・パスワードを変更した場合、アクセス・クライアント・パスワードも変更する必要があります。

図D-2に、IAMSuiteAgentのページを示します。「ユーザー定義パラメータ」は、WebLogic Serverのコンテナ・ポリシーにフォール・バックする動作を通知し、ログアウトのためのリダイレクトURLを作成します。

図D-2 IAMSuiteAgent登録

「図D-2 IAMSuiteAgentの登録」の説明

このエージェントは、第22章「Access Manager 11gを使用する10g Webgatesの登録および管理」で説明するように、10g Webgateで入れ替えることができます。

表D-1は、IAMSuiteAgent、11g Webgate、10g Webgateの3つの違いを示しています。

表D-1 IAMSuiteAgentの11gおよび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

保護されていない場合に拒否

×

×

×

D.1.4 IAMSuiteAgentで保護されるリソース

図D-3は、IAMSuiteAgentによって保護されるリソースと、正確な認証ポリシーおよび認可ポリシーを示しています。追加や変更は一切行わないことをお薦めします。WebLogic管理コンソール(/console)は保護されています。

図D-3 IAMSuiteAgentによって保護されるリソース

「D-3 IAMSuiteAgentによって保護されるリソース」の説明

D.1.5 事前シード済のIAM Suiteアプリケーション・ドメインおよびポリシー

次の図は、IAM Suiteアプリケーション・ドメインの認証ポリシーを示しています。

- 図D-4, 「IAMSuite認証ポリシー: OAM管理コンソール・ポリシー」

- 図D-5, 「保護されるより高度なポリシー: 認証, LDAPスキーム」

- 図D-6, 「保護されるより低度なポリシー: 認証, OIMスキーム」

- 図D-7, 「パブリック・ポリシー: 認証, Anonymousスキーム」

図D-4 IAMSuite認証ポリシー: OAM管理コンソール・ポリシー

「図D-4 IAMSuite認証ポリシー: OAM管理コンソール・ポリシー」の説明

図D-5 保護されるより高度なポリシー: 認証, LDAPスキーム

「図D-5 保護されるより高度なポリシー: 認証, LDAPスキーム」の説明

図D-6 保護されるより低度なポリシー: 認証, OIMスキーム

「図D-6 保護されるより低度なポリシー: 認証, OIMSスキーム」の説明

図D-7 パブリック・ポリシー: 認証, Anonymousスキーム

「図D-7 パブリック・ポリシー: 認証, Anonymousスキーム」の説明

IAM Suite認可ポリシー

図D-8は、IAM Suiteアプリケーション・ドメインの認可ポリシーを示しています。デフォルトでは、明示的な条件やレスポンスは定義されません。しかし、環境に適していれば追加できます。

図D-8 IAM Suite認可ポリシー

「図D-8 IAM Suite認可ポリシー」の説明

IAM Suiteトークン発行ポリシー

図D-9に、IAM Suiteアプリケーション・ドメインのIAM Suiteトークン発行ポリシーを示します。デフォルトでは、明示的な条件は定義されていません。しかし、環境で要求されるものは定義できます。

図D-9 IAM Suiteのトークン発行ポリシーとリソースURL

「図D-9 IAM Suiteのトークン発行ポリシーとリソースURL」の説明

D.2 生成されるアーティファクト: OpenSSO

この項では、カスタム認証モジュール、ホスト識別子、アプリケーション・ドメイン、およびOpenSSOエージェント・プロビジョニング中に生成されるポリシーを示します。

- 生成されたOpenSSOAgentAuthPlugin

- 生成されるホスト識別子: OpenSSOAgent

- 生成されるアプリケーション・ドメイン: OpenSSOAgent

- 生成されるリソース: OpenSSOAgent

- 生成される認証ポリシー: OpenSSOAgentアプリケーション・ドメイン

- 生成される認可ポリシー: OpenSSOAgentアプリケーション・ドメイン

D.2.1 生成されるOpenSSOAgentAuthPlugin

図 D-10は、OpenSSOAgentカスタム認証モジュール: OpenSSOAgentAuthPluginを示します。

図 D-10 生成される認証モジュール: OpenSSOAgentAuthPlugin

D.2.2 生成されるホスト識別子: OpenSSOAgent

図D-11 生成されるホスト識別子: OpenSSOAgent

D.2.3 生成されるアプリケーション・ドメイン: OpenSSOAgent

図D-12 生成されるアプリケーション・ドメイン: OpenSSOAgent

D.2.4 生成されるリソース: OpenSSOAgent

図D-13 アプリケーション・ドメイン・リソース: OpenSSOAgent

D.2.5 生成される認証ポリシー: OpenSSOAgentアプリケーション・ドメイン

図D-14 生成される認証ポリシー: OpenSSOAgentアプリケーション・ドメイン

D.2.6 生成される認可ポリシー: OpenSSOAgentアプリケーション・ドメイン

図D-15 生成される認可ポリシー: OpenSSOAgentアプリケーション・ドメイン

D.3 移行されるアーティファクト: OpenSSO

この項では、Oracle提供の分析ツールやOpenSSO環境のOracle Access管理コンソールへの移行ツール使用時に移行されるアーティファクトを示します。

- 移行されるユーザー・アイデンティティ・ストア: OpenSSO

- 移行されるエージェント: OpenSSO

- 移行される認証モジュール: OpenSSO

- 移行されるホスト識別子: OpenSSO

- 移行されるアプリケーション・ドメイン: OpenSSO

- 移行されるリソース: OpenSSO

- 移行される認証ポリシー: OpenSSO

- 移行される認可ポリシー: OpenSSO

D.3.1 移行されるユーザー・アイデンティティ・ストア: OpenSSO

図D-16 移行されるユーザー・アイデンティティ・ストア: OpenSSO

D.3.2 移行されるエージェント: OpenSSO

図D-17 移行されるエージェント: OpenSSO

D.3.3 移行される認証モジュール: OpenSSO

図D-18 移行される認証モジュール: OpenSSO

D.3.4 移行されるホスト識別子: OpenSSO

図D-19 移行されるホスト識別子: OpenSSO

D.3.5 移行されるアプリケーション・ドメイン: OpenSSO

図D-20 移行されるアプリケーション・ドメイン: OpenSSO

D.3.6 移行されるリソース: OpenSSO

図D-21 移行されるリソース: OpenSSO

D.3.7 移行される認証ポリシー: OpenSSO

図D-22 移行される認証ポリシー: OpenSSO

D.3.8 移行される認可ポリシー: OpenSSO

図D-23 移行される認可ポリシー2 条件: OpenSSO

図D-24 移行される認可ポリシー2: IP条件詳細

E トラブルシューティング

この章ではトラブルシューティングのヒントについて説明します。

- Oracle Access Managementトラブルシューティングの概要

- My Oracle Supportを使用したその他のトラブルシューティング情報

- Oracle Access Management Consoleの状態が矛盾している

- WebLogic Serverのインストール時に不正なJavaパスが指定されると管理サーバーが起動しない

- エージェント名が一意ではない

- アプリケーションURLの要件

- 認証の問題

- 認可の問題

- 認証LDAPまたはデータベースにアクセスできない

- 構成が見つからない

- OSSOとAccess Manager間のCo-existence

- 部分トリガーが見つからない

- サービス攻撃の拒否

- 新しくインストールした10g Webgateでのデプロイメント

- IIS WebサーバーでのWindowsのチャレンジ/レスポンス認証の無効化

- UserIdentityStore1タイプを変更すると管理者がロックアウトされる可能性がある

- IIS Webサーバーの問題

- jpsロガー・クラスのインスタンス化警告が認証時にログに記録される

- 国際化、言語および翻訳

- 保護されたページへのログインの失敗

- OAMメトリック永続性タイマーIllegalStateException: SafeCluster

- 部分的なクラスタ障害および断続的なログインおよびログアウト障害

- RSA SecurIDの問題とログ

- 登録の問題

- Rowkeyに主キー属性がないエラー

- SELinuxの問題

- セッションの問題

- SSLとオープンな通信の比較

- 起動の問題

- OAMサーバー・クロックの同期化

- Coherenceの使用

- エラーの検証

- Webサーバーの問題

- Windowsネイティブ認証

E.1 Oracle Access Managementトラブルシューティングの概要

Oracle Access Managementはビジネス・クリティカルなシステムで、停止時間によりビジネスに高いコストが生じる可能性があります。システム分析の目標は、迅速な問題の切り分けおよび原因の修正です。これにはシステムの全体像と、使用中のシステムを監視し、コンポーネントをさらに大きな視野と関連付けるツールが必要です。

管理者による迅速な診断を支援するために、この項では次の項目を提供します。

- システム分析と問題例について

- LDAPサーバーまたはアイデンティティ・ストアの問題について

- OAMサーバーまたはホストの問題について

- エージェント側の構成およびロードの問題について

- 実行時データベース(監査またはセッション・データ)の問題について

- 変更の伝播またはアクティブ化の問題について

- ポリシー・ストア・データベースの問題について

E.1.1 システム分析と問題例について

システム分析には、製品の動作、失敗の可能性、起こりうる例、およびその影響または観測可能な問題の理解が含まれます。

システムの問題は次の基本的な2つのカテゴリに分類できます。

- 連鎖的で致命的な障害

- 漸進的なパフォーマンスの低下

連鎖的で致命的な障害は次のことが原因で発生する可能性があります。

- LDAPサーバーがロードされて応答しない

- 朝のピーク負荷の開始

- WebgateがプライマリOAMサーバーにリクエストを送信

- Webgateリクエストがタイムアウトで、WebgateがセカンダリOAMサーバーに再試行

漸進的パフォーマンスの低下は、次のように、時間の経過にともなって発生する可能性があります。

- OAMのサイズが変更され、10,000ユーザーおよび500グループ用にロールアウトされた

- 1年の間に、ユーザーおよびグループの数が大幅に増加(たとえば50,000ユーザーおよび250グループ)

もっとも一般的に発生する問題については、次の各項を参照してください。

- システム分析と問題例について

- LDAPサーバーまたはアイデンティティ・ストアの問題について

- OAMサーバーまたはホストの問題について

- エージェント側の構成およびロードの問題について

- 実行時データベース(監査またはセッション・データ)の問題について

- 変更の伝播またはアクティブ化の問題について

- ポリシー・ストア・データベースの問題について

E.1.2 LDAPサーバーまたはアイデンティティ・ストアの問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

- 症状: 動作が遅い

- 症状: サービスがすべて失われる

症状: 動作が遅い

- ユーザーの操作性の悪化

- エージェントのタイムアウトによる複数回の再試行

原因

- OAM以外の負荷がOAMの操作に影響を与える可能性がある

- ピーク負荷の漸進的増加によるキャパシティの問題

症状: サービスがすべて失われる

原因

- すべてのLDAPサーバーの停止

- ロード・バランサの古い接続のタイムアウト

診断

1. LDAPサーバーを停止します。

2. ブラウザを再起動します。

3. 保護されたサイトにアクセスしてみます。

4. 第6章(または第10章)の説明に従い、OAMサーバー・ログ・ファイルでエラーを確認します。

5. Oracle Access Managementコンソールにアクセスしてみます。

6. WebLogic AdminServerログ・ファイルでエラーを確認します。

7. LDAPサーバーを再度立ち上げます。

8. 保護されたアプリケーションに再度アクセスしてみます。

9. Oracle Access Managementコンソールに再度アクセスしてみます。

10. 環境に応じた要件に基づき問題を修正します。

E.1.3 OAMサーバーまたはホストの問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

- 症状: キャパシティの問題

- 症状: ホスト上の他のサービスとの衝突

症状: キャパシティの問題

- 動作の遅さによるユーザーの操作性の悪化

- エージェントのタイムアウトと再試行のために余分な負荷が発生している

原因

- CPUサイクル

- メモリの問題

症状: ホスト上の他のサービスとの衝突

- 動作の遅さによるユーザーの操作性の悪化

- エージェントのタイムアウトと再試行のために余分な負荷が発生している

原因

- CPUサイクルの競合

- メモリの競合

- ファイルシステムが満杯

診断: OAMサーバー

1. OAMサーバーを停止します

2. Webgateまたは保護されたリソースmod_ossoにアクセスしてみます

3. OAMサーバーを立上げます

4. アクセス・テスターを使用して、第18章の説明に従い認証および認可をテストします。

5. アクセス・テスターを使用しながら、'top'を使用してOAMサーバーのCPUおよびメモリ消費を計算します

6. OAMサーバーのスレッド・ダンプを取得します。

診断: AdminServer

1. AdminServerを停止します。

2. ブラウザを再起動し、処理の必要がある保護されたリソースにアクセスします。

3. 第13章の説明に従い、リモート登録を使用して新しいパートナを登録します(これは失敗するはずです)。

4. OAM AdminServerを開始します。

E.1.4 エージェント側の構成およびロードの問題について

この項では、エージェントとサーバー間の時間の問題の症状、考えられる原因および診断手順を提供します。

症状: エージェントとサーバーでクロック時間が異なる

- エージェントおよびサーバーの両方で高いCPU使用率

- ユーザーにシステム停止が発生

原因

- エージェントはサーバーが発行したトークンが無効だと判断

- エージェントがトークンの再発行のためサーバーへ戻し続けている

診断

1. 保護されたリソースにアクセスします。

2. 確認: クライアント・アクセスがハングしています。

3. 確認: エージェントおよびサーバーで高いCPU使用率。

E.1.5 実行時データベース(監査またはセッション・データ)の問題について

監査およびセッション機能はどちらも書込み集中型の処理です。ポリシー・データベースは読取り集中型のサービスに対してチューニングできます。

症状

- 監査およびセッション処理が遅い

- OAMサーバー上のファイルシステムが、まだデータベースに書き込まれていない監査データで満杯

- クラスタ内のいずれかのサーバーの障害発生時にメモリ内セッションが消失

原因

- データベースが書込み集中型の処理向けにチューニングされていない

- データベースがメンテナンスにより使用できない

- データベースの容量の問題

診断

1. 監査およびセッション・データを格納するのに使用するデータベースを停止します。

2. 保護されたリソースにアクセスしてみます。

3. 第6章(または第10章)の説明に従い、OAMサーバー・ログ・ファイルでエラーおよび警告メッセージを確認します。

E.1.6 変更の伝播またはアクティブ化の問題について

この項では、次の問題の症状、考えられる原因および診断手順を提供します。

症状

- ポリシーへの変更がすぐに有効にならない

- システム構成への変更がすぐに有効にならない

原因

- サーバーがランタイム・リクエストの処理でビジー状態(CPUの競合)

- コヒーレンス・ネットワークが遅い

診断: 「ポリシー・ストア・データベースの問題について」を参照してください

E.1.7 ポリシー・ストア・データベースの問題について

この項では、ポリシー・データベースの問題の症状、考えられる原因および診断手順を提供します。

症状: ポリシーの変更が許可されず、実行時に影響を及ぼさない

原因

- データベースが使用できない(メンテナンスによる停止)

- データベースの容量の問題

診断

1. OAMポリシーを含むデータベースを停止します。

2. 保護されたリソースにアクセスし、実行時アクセスに影響が及んでいないことを確認します。

3. Oracle Access Managementコンソールにアクセスしてポリシーを編集してから、AdminServerログ・ファイルでエラーを確認します。

E.2 My Oracle Supportを使用したその他のトラブルシューティング情報

Oracle Fusion Middlewareの問題解決にMy Oracle Support(以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。

- ナレッジ・ベース記事

- コミュニティ・フォーラムとディスカッション

- パッチとアップグレード

- 動作保証情報

注意:

My Oracle Supportを使用すると、サービス・リクエストのログ記録もできます。

My Oracle Supportにはhttps://support.oracle.comからアクセスできます。

E.3 管理者のロックアウト

問題

管理者がOracle Access Managementコンソールへ正常にログインできない。次のメッセージが表示されます。

Manually Change Identity Store Settings at OPSS Level and configure the IDMDOmainAgent.

原因

Access Managerは、IAM Suiteアプリケーション・ドメインの認証情報すなわちOAM管理コンソール・ポリシーに基づき、Oracle Access Managementコンソールを保護します。このポリシーは、フォーム・チャレンジ・メソッドおよびLDAP認証モジュールを使用する単一の認証スキーム(OAMAdminコンソール・スキーム)に基づいています。LDAP認証モジュールは、システム・ストアとして指定されたユーザー・アイデンティティ・ストアをポイントしている必要があります。

たとえば、開発モードを設定して、(すべての管理者、ユーザーおよびその中で定義されるグループが)Oracle Internet Directoryを使用できるようにすれば、LDAP認証モジュールはこのユーザー・アイデンティティ・ストアをポイントし、システム・ストアとして指定することになります。

解決策

1. ユーザー・アイデンティティを、指定されたシステム・ストアと埋込みLDAPストアの両方に挿入します。

2. Oracle Access Managementコンソールにログインします。

3. 「ネイティブ認証モジュールの管理」の説明に従い、指定されたシステム・ストアにより使用されるLDAP認証モジュールを構成して、適切なユーザー・アイデンティティ・ストアをポイントするようにします。

E.4 Oracle Access Managementコンソールの状態が矛盾している

問題

複数の管理者が更新を同時に実行すると、Oracle Access Managementコンソールのシステム構成が一貫性のない状態になります。

原因

構成の同時更新はサポートされていません。

解決策

どのようなときでも、1人の管理者のみがシステム構成を変更できるようにする必要があります。

E.5 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)パスが使用されます。しかし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

E.6 エージェント名が一意ではない

各エージェント登録を一意に識別する名前がお薦めされます。ただし、次のことに注意してください。

- エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければAccess Managerによってポリシーが作成されます。

- ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

E.7 アプリケーションURL要件

URLで使用可能な文字数は、ブラウザのバージョンに基づいています。

cookieサイズに影響するメイン属性が、リクエストされたURLの長さです。ADFアプリケーション用のシステム生成URLの一部はかなり長く、cookieが最大サイズを超える原因になる可能性があります。

別の事例としては、カスタム・プラグインを使用する場合です。プラグインが認証コンテキストに追加するデータがCookieで永続され、Cookieサイズを大きくする原因となる可能性があります。

複数の不正パスワードによる攻撃も、より多くのコンテキスト・データをCookieに追加する可能性があります。前述の事例が組み合さることで、Cookieサイズは急速に大きくなる可能性があります。

解決策

Access Managerおよびブラウザが処理できる長さを超えたURLを、アプリケーションで使用しないようにしてください。

Cookieキャッシュ・モードは、デフォルトのCOOKIEモードからFORMモードへ変更できます。FORMモードは、長いURLで機能します。動作における唯一の違いは、プログラム認証用であり、OAM_REQパラメータ・セットをフォームに渡すためには適切なフォームの提出が必要になるということです。カスタム資格証明収集ページで、フォームと一緒に提出されるOAM_REQパラメータを処理する必要があります。

また、長いURLをサポートする場合は、次に示すように、oam-config.xmlのserverRequestCacheTypeパラメータをFORMに設定します。このファイルは、$DOMAIN_HOME/config/fmwconfig/oam-config.xmlにあります。

<Setting Name="serverRequestCacheType"
Type="xsd:string">FORM</Setting>

E.8 認証の問題

この項では次の情報を提供します。

- 匿名認証の問題

- X.509スキームおよびSSLハンドシェイクの問題

- X.509保護リソースおよびシングル・サインオフ

- X509CredentialExtractor証明書検証エラー

E.8.1 匿名認証の問題

問題

チャレンジ・リダイレクト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.

解決策

匿名認証スキームを編集するときは必ずチャレンジ・メソッドとチャレンジ・リダイレクトの両方を含める必要があります。

E.8.2 X.509スキームおよびSSLハンドシェイクの問題

Access Manager X.509認証スキームは、ユーザーのX.509証明書をOAMサーバーへ配信するSSLに基づきます。X.509認証スキームには、チャレンジ・メソッドの値としてX509プラグインが必要です(認証モジュールではありません)。

問題

ユーザーがブラウザで証明書を選択しいるのに、OAMサーバーの証明書が有効ではない。

解決策

具体的な解決策は、SSLハンドシェイク障害の理由により決まります。次に例を示します。

- WebLogic Serverで切断するSSL接続のデバッグを行うには、http://docs.oracle.com/cd/E12840_01/wls/docs103/secmanage/ssl.htmlを参照してください。

- OHSサーバーで切断するSSL接続のデバッグを行うには、http://docs.oracle.com/cd/E12839_01/web.1111/e10144/under_mods.htm#i1007687を参照してください。

SSLハンドシェイク障害の理由およびSSLハンドシェイクを終了させているピアを特定してください。解決策は次のカテゴリに類別されます。

- 構成の問題

- 信頼性の問題

- 証明書検証の問題

E.8.2.1 構成の問題

デフォルトでSSL実装のWebLogic ServerとのSSL接続を確立させるのに問題がある場合は、WLS 10.3.3以降でサポートされているJSSE SSL実装の使用へ切り替えてください。

次のリストはその他の発生する可能性がある構成の問題を特定しています。

- OHSプラグインの構成に間違いがあるため、ユーザー資格証明がWebLogicサーバーに送信されない。

- 暗号スイート: この構成が、ユーザー証明書と一致していない。

- スマート・カード: ブラウザがスマートカード・リーダーと通信していない。

- PKCS#11 (またはハードウエア暗号化): デバイスが作動していることを確認してください。

E.8.2.2 信頼性の問題

証明書内のサーバー名がホスト名に一致していません。この照合は構成により無効化できます。

サーバーが、トラスト・ストアにあるユーザー証明書パス上にCA証明書を実装していません。

E.8.2.3 証明書検証の問題

次のリストは発生する可能性がある構成の問題を特定しています。

- 証明書が期限切れになっている。

- 証明書が失効している。

- 資格証明検証の構成に間違いがあるか、接続に問題があるために、この検証が機能していない。

E.8.3 X.509保護リソースおよびシングル・サインオフ

問題

シングル・サインオフが、X.509認証でリソースにアクセスした後で機能しないことがあります。ユーザーがログアウトURLでログアウトして、同じブラウザでリソースにアクセスしようとすると、認証が行われないことがあります。かわりに、ユーザーは証明書ポップアップを使用した認証を求められます。

これは、いずれのエージェント・タイプでも起こる可能性があります。

解決策

ログアウトURLを実行した後で、ブラウザで「SSL状態のクリア」を次のようにクリックしてから、X.509保護リソースにアクセスします。

ブラウザ・ウィンドウで、「ツール」メニューを開いて「インターネット オプション」をクリックし、「コンテンツ」、「SSL状態のクリア」の順に選択します。

E.8.4 X509CredentialExtractor証明書検証エラー

問題

クライアント証明書認証は、WebLogic Serverと.oamkeystore keystoresにrootとsub CA証明書をインポートすると、標準X509認証モジュールを使用して正常に作動します。

しかし、カスタムX509プラグイン認証モジュールおよびWebLogic Serverと.oamkeystore keystoresにインポートされたrootとsub CA証明書を使用する場合、証明書検証エラーが発生する可能性があります。

解決策

カスタムX509プラグイン認証モジュールと一緒に、rootおよびsub CA証明書を、DOMAIN_HOME/config/fmwconfig/amtruststore because the X509CredentialExtractor plug-in loads certificates from this locationに追加する必要があります。X509CredentialExtractorプラグインが、この保管場所から証明書をロードするからです。

E.9 認可の問題

ここでは、次の内容について説明します。

- 認可条件のエラー

- LDAP検索フィルタ・テストの結果

- 認可ヘッダー・レスポンスの名前

E.9.1 認可条件のエラー

IPv4範囲または一時的条件を作成または編集するたびに、エラーがoam-server診断ログ・ファイルに記録されます。

.... refreshPolicy specified but no response collector supplied

原因

これは誤ってERRORレベルでログに記録されるメッセージです。

解決策

メッセージの正しいレベルはINFOです。

E.9.2 LDAP検索フィルタ・テストの結果

多すぎる結果が戻されると、次が示されます。

解決策

1. 「OK」をクリックします。

2. 新たなテストを開始するにはテスト・フィルタ・ボタンをクリックします。

3. 検索フィルタの編集ダイアログで変更します。

4. テスト結果を照合します。

E.9.3 認可ヘッダー・レスポンスの名前

一部の文字は、ヘッダー・レスポンス内の名前または値に使用できないことがあります。これは、該当するレスポンスを受信するクライアントが、Webゲートであるかどうかに依存し、そのクライアントがWebゲートである場合は、どのWebサーバーを保護しているかによって異なります。特定の文字には自動変換が適用され、サーバー固有の方法で、別の文字に自動的に変換される可能性があります。

詳細は、使用しているWebサーバーのドキュメントを参照してください。

E.10 認証LDAPまたはデータベースにアクセスできない

認証に使用されるLDAPディレクトリ(またはポリシー・ストアとして定義されているデータベース)が停止またはアクセスできない場合、高負荷またはタイムアウトが原因の可能性があります。このLDAPまたはポリシー・ストアを使用する保護されたリソースへアクセスしようとするとメッセージが表示されます。

解決策

1. 登録されたLDAPまたはデータベースを手動で停止します。

2. 登録されたLDAPまたはデータベースを再起動します。

E.11 構成が見つからない

E.11.1 構成が存在しない...

WebLogic ServerドメインのOAMサーバーを構成する前に、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.

この問題を解決するには、Access Managerで構成を登録する前にWebLogic ServerドメインにOAMサーバーを構成する必要があります。

E.12 OSSOとAccess Manager間のCo-existence

問題

Access Manager 11gとのOSSO 10g coexistenceで、OAMサーバーのダウン時にユーザーが保護されたリソースにアクセスしようとすると、リクエストはロード・バランサを通してOSSO 10gログイン・ページへリダイレクトされます。ユーザーが有効な資格証明を入力すると、リソースが指定されます。

しかし、ユーザーがOracle HTTP Server cookieを削除し、OSSO 10gサーバーをダウン(およびOAM Serverを起動)させると、保護されたリソースへのアクセスの際に、ユーザーはAccess Managerログイン(認証)について質問されます。そうではなく、認証なしでアプリケーションにアクセスできる必要があります。

解決策

移行されたユーザー・アイデンティティ・ストアがAccess Managerデフォルト・ストアおよびシステム・ストアとして設定されていることを確認します。

関連項目:

- Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのenableCoexistModeおよびdisableCoexistModeに関する項

- Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド

E.13 部分トリガーが見つからない

管理サーバー出力で、(ポリシー構成」タブまたは「ホスト識別子ノードをクリック時に、選択したノードそれぞれに対して複数回)「部分トリガーが見つからない」というエラーが表示される場合には、ナビゲーション・ツリーの他のノードのいずれかをクリックします。

これは機能を妨げるものではありません。

E.14 DoS攻撃

サービス拒否攻撃(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リクエストから守る

E.14.1 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パフォーマンスおよびチューニング』の次のトピックに従い、最大着信リクエスト・サイズ、完了メッセージ・タイムアウトを指定し、ファイル記述子の数を設定して、パフォーマンスを最適化します。

- メッセージ・サイズのチューニング

- 完了メッセージ・タイムアウトのチューニング

- ファイル記述子数のチューニング

E.14.2 ネットワーク遅延に対する補償

WebgateがOAMサーバーに認証リクエストを送信する場合を考えます。資格証明が正常に収集および検証された後で、OAMサーバーはセッションおよび関連Cookie (OAM_ID、ObSSOCookie)を作成します。ところがネットワーク遅延のために、OAMサーバーがそれをWebgateへ送信し、それによりWebgateが認証リクエストをOAMサーバーへ再送信する時間により、レスポンスはタイムアウトしてしまいます。OAMサーバーはセッションを認識し、それからObSSOCookieを再作成して、レスポンスをエージェントへ送信します。ネットワーク遅延がまだ続いていると、このサイクルはサーバーとWebgateの間で無限に繰り返します。ユーザーは再度ログインするように求められことがなく、エラー・メッセージも表示されません。

E.14.3 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

E.15 新しくインストールした10g Webgateでのデプロイメント

OAMサーバーの診断機能を使用してOAMサーバー側でデバッグします。この項の内容は次のとおりです。

- 10g Webgateでの認証の問題

- 10g Webgateでのログアウトの問題

関連項目:

第19章「11g Webgateが関与するセッションの集中ログアウトの構成」

E.15.1 10g Webgateでの認証の問題

次の方法を使用して、Access Managerデプロイメントに10g Webgateを新たにインストールしたときの認証の問題をトラブルシューティングします。

- Internet Explorer HTTPヘッダーまたはFirefox Live HTTPヘッダーのようなhttpヘッダー・トレースを使用して、リクエストが保護されていたことを確認します。

- リクエストが認証のためOAMサーバーに送信されることを確認します。

- GET /oam/server/obrareq.cgi?....

- ホスト: oam-server:port

E.15.2 10g Webgateでのログアウトの問題

次の方法を使用して、Access Managerデプロイメントに10g Webgateを新たにインストールしたときのログアウトの問題をトラブルシューティングします。

- HTTPヘッダー・トレースを十分に使用します

- 特定のlogout.htmlが10g Webgateのインストール・ディレクトリの/access/oamssoフォルダにコピーされたことを確認します。存在しない場合、「11g OAMサーバーでの10g Webgateの集中ログアウトの構成」の説明に従い、logout.htmlを作成する必要があります。

- 10g Webgateのhttpd.confを変更して次の行を削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

- Oracle Access Managementコンソールから、LogoutUrlsパラメータ(/oamsso/logout.html)がこのWebgate用に構成されていることを確認します

E.16 初期化およびパフォーマンスの問題の診断

この項の内容は次のとおりです。

- 初期化の問題の診断

- パフォーマンスの問題の診断

- メモリー不足の問題のヒープ・ダンプを使用した診断

E.16.1 初期化の問題の診断

問題

OAMサーバーが起動しない。

解決策

1. OAMサーバーをホストしているコンピュータ上のOAMサーバー・ログ・ファイルを探して確認します。

DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

2. 第6章「コンポーネント・イベント・メッセージのロギング」の説明に従い、このコンピュータのログを有効にします。

DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

3. OAMサーバーを再起動し、動作を監視し、必要ならばログ・ファイルを再度確認します。

E.16.2 パフォーマンスの問題の診断

問題

OAMサーバーの監視により、認証中の待機時間の著しいスパイクが明らかになります。

解決策

1. OAMサーバーをホストしているコンピュータ上のOAMサーバー・ログ・ファイルを探して確認します。

DOMAIN_HOME/servers/SERVER-NAME/logs/SERVER-NAME-diagnostics.log

2. 第6章「コンポーネント・イベント・メッセージのロギング」の説明に従い、このコンピュータのログを有効にします。

DOMAIN_HOME/config/fmwconfig/servers/SERVER-NAME/logging.xml

3. OAMサーバーを再起動し、動作を監視し、必要ならばログ・ファイルを再度確認します。

E.16.3 メモリー不足の問題のヒープ・ダンプを使用した診断

問題

解析および評価のすべての式のデバッグにより、メモリーの増加が原因で、重大なパフォーマンスの負荷が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>

E.17 IIS WebサーバーでのWindowsのチャレンジ/レスポンス認証の無効化

Windows上のIIS Webサーバーは、IISがインストールされたときのデフォルトであるチャレンジ/レスポンス認証をサポートします。これにより、ユーザーはIISからリソースをリクエストされ、Access Managerの認証と競合する可能性があるときにドメイン・ログインを使用できます。

たとえば、Internet Explorer(IE)ブラウザから、Access ManagerによりBasic認証スキームで保護されたIIS上のリソースへの最初のリクエスト時に、IEはドメインと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を閉じます。

E.18 UserIdentityStore1タイプを変更すると管理者がロックアウトされる可能性がある

システム・ストアとして指定されているアイデンティティ・ストアを編集し、ストア・タイプを変更したり(たとえば、組込みLDAPからOIDへ)接続URLを変更しないようにする必要があります。

編集でのストア・タイプ変更を禁止するシステム・ストアとして指定されているアイデンティティ・ストアを変更する必要がある場合は、新規アイデンティティ・ストアを作成してから、この登録を編集してシステム・ストアとしてマークすることをお薦めします。

E.19 IIS Webサーバーの問題

次の各項目が役に立ちます。

- フォーム認証またはパススルーが動作しない

- IISおよび一般Webコンポーネントのガイドライン

- IIS v6 Webサーバーの問題

- ページが表示されないエラー

- IIS DLLの削除および再インストール

E.19.1 フォーム認証またはパススルーが動作しない

フォーム認証またはパススルー機能が動作しない場合、問題はWebgateプロファイルの"UseWebGateExtForPassthrough"パラメータがtrueに設定されていないか、webgate.dllがIISのWild Card Application Mappingのように構成されていないかのいずれかである可能性があります。このような場合、Webgateはフォームベース認証により保護されたリソースに対するHTTP "POST"リクエストの認証または認可を実行しません。

解決策: WebgateプロファイルのUseWebGateExtForPassthroughパラメータを値trueで構成し、webgate.dllをWild Card Application Mappingのように構成します。

E.19.2 IISおよび一般Webコンポーネントのガイドライン

Access Manager WebgatesとIIS Webサーバーのインストール時の一般的なガイドラインを次に示します。

アカウント権限: Access Managerのインストールを実行するアカウントには管理者権限が必要です。OAMサービスを実行するのに使用するユーザー・アカウントには"サービスとしてログオンする"権限が必要で、これは管理ツール、ローカル・ポリシー、ローカル・ポリシー、ユーザー権限の割当て、サービスとしてログオンを選択して設定できます。

IIS 6 Webサーバー: WWWサービスをIIS 5.0分離モードで実行する必要があります。これはISAPIのpostgateフィルタにより必要です。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ファイルシステム上で設定できない様々な権限を手動で設定するための指示が表示されます。この場合、これらの指示を無視できます。

E.19.3 IIS v6 Webサーバーの問題

IIS 6 Webサーバーでのみ、WWWサービスをIIS 5.0分離モードで実行する必要があり、これはISAPI postgateフィルタの要件です。この例は、32ビットWindowsオペレーティング・システムで実行している32ビットの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

E.19.4 ページが表示されないエラー

パススルー機能用にWebgateを構成した後に表示される、ページが表示できないというエラーは、構成の問題を示しています。

解決策: WebgateプロファイルのUseWebGateExtForPassthroughパラメータを値trueで構成し、webgate.dllをWild Card Application Mappingのように構成します。

E.19.5 IIS DLLの削除および再インストール

Access ManagerがMicrosoftのIIS Webサーバーで実行している場合、Access Managerを再インストールするときには次のISAPIフィルタを手動でアンインストールおよび再インストールする必要があります。

- tranfilter.dll

- oblixlock.dll(Webgateがインストール済の場合)

- webgate.dll(Webgateがインストール済の場合)

IIS DLLを削除および再インストールする手順

1. Access Managerをアンインストールします。

2. 前述のDLLを手動でアンインストールします。

3. Access Manager.Active Directoryを再インストールします。

4. DLLを手動で再インストールします。

注意:

これらのフィルタは使用しているIISのバージョンにより異なる可能性があります。これらのフィルタが存在しないまたは別のものが存在する場合、存在するフィルタを削除する必要があるかどうかはOracleにお問い合せください。

E.20 インポートおよびファイル・アップロードの制限

UPLOAD_MAX_MEMORYとUPLOAD_MAX_DISK_SPACEは、50MBに設定されています。50MBを超えるアップロードに対応する場合は、これらの設定をweb.xmlで変更します。

メモリーおよびディスク領域のパラメータを変更するには

1. WEB-INF/lib/ngam-ui.war内で、web.xmlを探します。

2. ファイルを編集して、UPLOAD_MAX_MEMORYを変更します。例:

<context-param>
<param-name>org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY</param-name>
<param-value>104857600</param-value>
<context-param>

3. ファイルを編集して、UPLOAD_MAX_DISK_SPACEを変更します。例:

<context-param>
<param-name>org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE</param-name>
<param-value>104857600</param-value>
<context-param>

4. ファイルを保存します。

5. OAMサーバーを再起動します。

関連項目:

Oracle Application Development Framework開発者ガイドのファイル・アップロード機能の提供に関する項。

E.21 jpsロガー・クラスのインスタンス化警告が認証時にログに記録される

jpsロガー・クラスのインスタンス化警告が認証時にバックエンドに表示されることがあります。しかしこれは無害な警告で対処する必要はありません。

E.22 国際化、言語および翻訳

ここでは、次の内容について説明します。

- 自動生成された説明が翻訳されない

- コンソールがきれいに表示されない

- 認証の失敗: ASCII以外の文字を含むユーザー

- ASCII以外のエージェント名ではアクセス・テスターが機能しない

- ロケール、言語およびOracle Access Managementコンソール・ログイン・ページ

E.22.1 自動生成された説明が翻訳されない

「ポリシー構成」タブの各コンポーネントの自動生成される説明は翻訳されません。これは異常ではなく、管理者が「説明」を必要にあわせて変更できるようにします。このような変更に従うため、Oracleによる翻訳が可能になっていません。

E.22.2 コンソールがきれいに表示されない

リモート登録用に入力された構成ファイルがUTF-8形式でない場合や、OAMサーバーがUTF-8ロケール(たとえばen_US.utf8)で起動していない場合、Oracle Access Managementコンソールでポリシーおよびリソースが正しく表示されません。

認証ポリシーおよび保護リソースを生成するためにリモート登録ツール用の構成ファイルoamregを作成する場合は、UTF-8エンコーディングを必ず使用してください。また、OAMサーバーをUTF-8ロケールのマシンで起動することも必要です。それ以外の場合、インバンド登録が成功した後にOracle Access Managementコンソールでポリシーとリソースがきれいに表示されない可能性があります。

E.22.3 認証の失敗: ASCII以外の文字を含むユーザー

WNAチャレンジ・メソッドによるKerberos認証スキームを使用するようにAccess Managerを構成して、Microsoft Active Directory内にASCIIではないユーザーを作成します。

問題

ユーザー詳細を取得してサブジェクトにユーザーDNおよびGUID属性を移入しようとすると、例外が発生します。Active Directory内のASCIIではないユーザーが、Access Managerで保護されたリソースにアクセスしようとすると、OAMサーバーのログに認証の失敗とエラーが記録されます。

... Failure getting users by attribute : cn, value ....

原因

属性で渡されるユーザー名は、java文字列として変換されません。

解決策

ASCII以外のユーザーは、次のJVMシステム・プロパティ(組込みのWebLogic SPNEGOサポート用)を適用することで、Kerberos WNAスキームで保護されたリソースにアクセスできるようになりました。

-Dsun.security.krb5.msinterop.kstring=true

E.22.4 ASCII以外のエージェント名ではアクセス・テスターが機能しない

ASCIIではない名前を使用して、WebゲートをAccess Managerに登録します。アクセス・テスターで、有効なIPアドレス、ポートおよびエージェントID(ASCIIではない名前)を入力して、「接続」をクリックします。

接続テストは失敗します。

E.22.5 ロケール、言語およびOracle Access Managementコンソール・ログイン・ページ

ブラウザのロケールがサポートされていない場合、Oracle Access Managementコンソールのログイン・ページはサーバー・ロケールで表示されます。つまり、元の英語で表示されます。これは正常な動作です。

- クライアントのロケールがサポートされていない場合、Oracle Access Managementはサーバー・ロケールに戻ります。

- サーバー・ロケールがサポートされていない場合、Oracle Access Managementは英語に戻ります。

ユーザーがサポートされない言語を選択して「Access Manager SSO」ページに進むと、サーバー・ロケールで表示されます(たとえばドイツ語)。しかし、ログイン後は、すべてのページが英語で表示されます。

英語に戻る手順

「Access Manager SSO」ページを無効にすると、元のAccess Managerログイン・ページも英語に戻ります。

E.23 保護されたページへのログインの失敗

問題

物理的なホストおよびポートを使用してOAMのインストールとページの保護後、OHS物理ホストおよびポートを使用してアプリケーションを登録します。保護されているページにアクセスするときに、ログインはユーザーへの資格証明の要求に失敗します。ログ・ファイルに、すべての構成と登録が正しく設定されているにもかかわらず、そのURがは仮想ホストにリダイレクトされたことが示されます。

解決策

Oracle HTTP Server(OHS)物理ホストおよびポートを使用してページを保護する場合、httpd.confから仮想ホスト・ディレクティブを削除します。

E.24 OAMメトリック永続性タイマーIllegalStateException: SafeCluster

問題

WebLogic構成ウィザードを使用して2つのコンピュータに1つのOAMサーバー・クラスタを作成し、AdminServerを開始した後で、すべてのサーバーが適切に開始します。停止後、WebLogic Server管理コンソールを使用して3つ目のサーバーを追加し、新しい管理対象サーバーを作成してクラスタに追加します。3つ目のサーバーは開始すると実行モードになりますが、いくつかの例外が開始ログに記録されます。

... Exception in thread "OAM Metric Persistence Timer"

解決策

WebLogic管理コンソールでの操作に追加して、Oracle Access Managementコンソールを使用してサーバーを登録し、サーバーが自分自身を識別できるようにする必要があります。

注意:

同じコンピュータに2つ目のサーバー・インスタンスを追加および登録する場合、すべてのポート、すなわちOAMプロキシ・ポート、WebLogic Serverコンソールのポートと必ず一致するポートおよびコヒーレンス・ポートの番号は異なる必要があります。

サーバー登録の詳細は、「個別のOAMサーバー登録の管理」を参照してください。

E.25 部分的なクラスタ障害および断続的なログインおよびログアウト障害

問題

Access Managerの部分的な停止(クラスタのいくつかのインスタンス、ただしすべてではない)が発生したときに、エンド・ユーザーに断続的なログインおよびログアウト障害が発生することがあります。

回避策

1. デプロイメントからOHSを削除します

2. OHSインスタンスを構成して、各OHSインスタンスをWebLogic Serverインスタンスに固定します。

3. 正常に動作していないAccess Managerアプリケーションを伴うWebLogic Serverコンテナは、サービスから削除(停止)してリカバリ時に戻す必要があります。

E.26 RSA SecurIDの問題とログ

各OAM SecurID Serverは、RSA認証Managerとともに独立したエージェントとして登録する必要があります。これにより、OAM SecurID Serverでノード・シークレット・ファイルが使用できるように設定されます。すべてのOAM SecurID Serverで、OAM SecurID Serverの構成ファイルが、$DOMAIN_HOME/config/fmwconfig/servers/$SERVER_NAME/oamの下に保存される必要があります。

RSA SecurID認証プラグインがエラーを返すと、そのエラーはOAM Serverログに記録されます。Webサーバー・ログも、異常発生の可能性に関する手掛かりとなります。Webサーバーでログオンが有効であることを確認してください。

通信がAccess Serverと認証Managerとの間で確立されている場合、sdadminツールによりレポート・メニュー下のログにアクセスできます。アクティビティ・レポートも例外レポートも役立つ情報になります。

認証Managerロギング構成およびレポートの検証

1. 認証Manager管理者ツール、つまりsdadminを使用して、ユーザーを追加し、トークンを割り当てていることを確認します。

2. sdconf.recファイルをOAM Serverにコピーしていることを検証します。

3. 認証Managerコンソール、つまりレポート・メニューから、有用な情報を得るためにアクティビティ・レポートと例外レポートを開きます。

SecurIDプラグイン・パラメータを変更されたHTMLフィールドと照合してください。

HTMLフォーム中のHTMLフィールド名を変更している場合は、RSA SecurIDプラグイン・パラメータが一致するように構成されていることを確認してください。

すべてのログイン属性値から@記号を削除してください。

ログイン属性値中にアットマーク(@)があると、ユーザー・ログインは失敗する可能性があります。これは、SecurIDの既知の問題です。

E.27 登録の問題

問題: リモート登録ツールの障害

解決策

エージェント名が一意(まだ存在していない)でAdminServerが実行していることを確認します。

問題: ObAccessClient.xmlファイルが生成されない

解決策

保護されたパブリック・リソースは、'/index.html'の形式の相対URLとして記述される必要があります。リソースの最初が'/'でないと、ObAccessClient.xmlファイルは生成されません。保護されたパブリック・リソースURLを確認し、すべてが"/"で始まるようにしてください。詳細については、「リソースURL、接頭辞およびパターンについて」を参照してください。

問題: パートナ登録の障害

パートナ登録は、一意のエージェント名を指定しないと失敗する場合があり、このエージェント名は、アプリケーション・ドメインを作成するためにも使用されます。エージェント名とアプリケーション・ドメイン名は同一であることと一意であることが必要です。エージェント名がアプリケーション・ドメイン名と一致しないと、oamreg検証コマンドの使用が失敗する場合があります。

解決策

エージェント名およびアプリケーション・ドメイン名は必ず同じにします。

E.28 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.>

これは無害で機能を妨げるものではありません。

E.29 SELinuxの問題

Oracle Enterprise Linuxに同梱されているSELinux変更は、Linuxカーネル内でLinux Security Modules(LSM)の使用を介して様々なポリシーを提供します。

SELinuxには、Access Manager Webgateのインストール後、関連するWebサーバーの開始前に、追加の手順の実行が必要です。

問題

より厳密なSELinuxポリシーが存在するLinux配布上のWebサーバーを開始するときに(Webgateのインストール後)、次のエラーがログ/コンソールに記録されることがあります。

11g Webgate

$Webgate_OH/webgate/ohs/lib/webgate.so: cannot restore segment prot after reloc:
Permission denied.

10g Webgate

$Webgate_install_dir/access/oblix/apps/webgate/bin/webgate.so: cannot restore segment prot after reloc:
Permission denied.

原因

これらのエラーはファイルのセキュアLinuxセキュリティ・コンテキスト・ポリシーにより報告されます。

解決策

これらのエラーを防ぎ、Webサーバーを開始するには、次のchconコマンドを実行し、各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

E.30 セッションの問題

この項の内容は次のとおりです。

- セッション偽装がデフォルトでは有効になっていない

- Oracle Identity Federation 11.1.1と統合されたOracle Access Manager 11.1.1とのセッション

E.30.1 セッション偽装がデフォルトでは有効になっていない

セッション偽装はデフォルトでは有効になっていません。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を保存します。

E.30.2 Oracle Identity Federation 11.1.1と統合されたOracle Access Manager 11.1.1とのセッション

予想される動作: Oracle Identity Federation 11.1.1セッションがクリアされない。

Oracle Access Manager 11.1.1がOracle Identity Federation 11.1.1と統合される場合、コンソールを使用してセッションをクリアすると、Oracle Access Managerセッションのみがクリアされます。Oracle Identity Federationセッションはクリアされません。

E.31 SSLとオープンな通信の比較

管理対象サーバーのSSLおよびオープン・ポートの両方が有効な場合、管理対象サーバーはデフォルトでSSLポートに設定されます。

SSL以外のポートを使用する必要がある場合、認証スキームの資格証明コレクタのURLは、プロトコルとして'http'およびSSL以外のポートを指す絶対URLに設定する必要があります。

E.32 起動の問題

問題: 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コンテナは保護を処理(ログインを含む)します。

E.33 OAMサーバー・クロックの同期化

セッションの状態は依存側にとっての真のソースです。様々なサーバーのシステム・クロックは同期が必要です。

依存側のシステム・クロックは、SMEクロックの同期の範囲外であることがあります。依存側のクロックが次の場合:

- セッション・クロックよりも進んでいる: 依存側の認証のリクエストが作成されアクティブ・セッションIDが戻されます。

- セッション・クロックよりも遅れている: 依存側ヘルプへのイベント通知によりセッションが無効になります。

たとえば、Webサーバー・クロックがサーバー・クロックよりも進んでいる場合、WebgateからOAMサーバーに送信されるリクエストには、OAMサーバーではまだ発生していない時間が含まれます。これによりログイン・イベントが失敗することがあります。簡易または証明書モードで実行している場合、タイムスタンプは同期の範囲外となるか、またはクライアント証明書が無効のように見えることがあります。

注意:

イベント通知の問題を防止するには、すべてのOAMサーバーのクロックをNISTインターネット・タイム・サービスのようなタイム・サービスに同期させるようにします。

正常な処理のために次のことを行います。

- すべてのコンピュータ・クロックが同期しているようにします。許容レベルはありません。たとえば、WebgateクロックがわずかでもOAMサーバー・クロックより進んでいる場合、Webgateにより生成されたCookieは未来のものと見なされ、OAMサーバーで問題を引き起こす可能性があります。

- Webgateが実行している各コンピュータのクロックが、関連するOAMサーバーよりも進んでいないことを確認します。OAMサーバーは最大60秒までWebgateのクロックよりも進んでいる必要があります。

E.34 Coherenceの使用

Access Managerは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagementコンソールとOAMサーバーの間の状態変更を通信します。

次の2つの分散デプロイメント・トポロジを考えます。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。Access Managerの特定のコンポーネント間にファイアウォールが存在する場合、Coherenceによって使用される対応したUDPポートが開いている必要があります。それ以外の場合、Access Managerは正常に作動しない可能性があります。

たとえば、Coherenceが使用するUDPポートは次のようにオープンしている必要があります。

- Oracle Access Managementコンソールはイントラネット内にデプロイされており、OAMサーバーはDMZにデプロイされています。この場合、Coherenceが使用するUDPポートは、DMZとイントラネットの間のファイアウォールでオープンしている必要があります。

- Oracle Access ManagementコンソールとOAMサーバーはDMZのそれぞれ別のセキュリティ・ゾーンにデプロイされており、隣り合う2つのゾーンの間にはファイアウォールが設置されています。この場合、Coherenceが使用するUDPポートは、Oracle Access ManagementコンソールおよびOAMサーバーの1つ以上のインスタンスが実行される、隣り合ったセキュリティ・ゾーンの間のファイアウォールでオープンしている必要があります。

Access Manager 11gはOracle Coherenceを使用して分散キャッシュのデータ・アクセス待機時間を短縮し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細は、「Oracle Coherenceとセッション管理について」を参照してください。

警告:

Oracleサポートからの要求がない限り、Oracle Coherence設定を変更しないことをお薦めします。

表示しているのが個別のサーバー・インスタンスのOracle Coherence設定、またはすべてのOAMサーバーに共通のOracle Coherence詳細のいずれであっても、Oracleサポートからの要求がない限り、Oracle Coherence設定を変更しないことをお薦めします。

Oracle Coherenceロギングは、WebLogic Serverログだけに表示されます。Oracle CoherenceロギングからAccess Managerのロギングへの橋渡しはありません。

関連項目:

Oracle Coherenceのドキュメント。

E.35 検証エラー

問題: リソースが認証または認可ポリシーに追加されない

認証または認可ポリシーの作成中に、別の認証または認可ポリシーで使用したことのあるリソースを追加する場合、「適用」をクリックするときに検証エラーが表示されます。これは予想通りです。

エラー・ウィンドウで「OK」をクリックすると、別の認証または認可ポリシーで使用されていない有効なリソースを追加することを求められ、そのリソースは追加されず、認可または認証ポリシーは作成されません。

解決策

1. 「適用」をクリックして、「認証ポリシー」または「認可ポリシー」ページを閉じます。

2. ナビゲーション・ツリーでポリシー名を再度クリックし、「編集」をクリックしてページを開き、新しいリソースを追加します。

問題: 検証に失敗 - "description"属性が無効

200文字を超えるオプションの説明を入力すると検証エラーが表示されます。

解決策

オプションの説明の長さは200文字、10行以内にします。

E.36 Webサーバーの問題

Webサーバーで次の問題が発生することがあります。

- Apache Webサーバー上のサーバー障害

- HP-UX上のApache v2

- Red Hat Enterprise Linux 4にバンドルされたApache v2

- セキュリティ強化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の削除および再インストール

E.36.1 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

E.36.2 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

E.36.3 Red Hat Enterprise Linux 4にバンドルされたApache v2

ベンダー・バンドルApacheにWebgateをインストールした後、Webサーバーの開始時に次のエラーが発生することがあります。

Error: Cannot load libgcc_s.so.1 library - Permission denied.

解決策: 「Access Manager用のApache/IHS v2のチューニング」の説明に従い、Access Manager Webgate用のSecurity-Enhanced Linux (SELinux)ポリシー・ルールを変更します。

E.36.4 セキュリティ強化LinuxにバンドルされたApache v2

Access Manager Webコンポーネントのインストール後、より厳密なSELinuxポリシーが存在するLinux配布上のWebサーバーを開始するときに、エラーがWebServerのログ/コンソールに記録されることがあります。Webサーバーを再起動する前に、インストールされたWebコンポーネント用の適切なchconコマンドを実行することにより、これらのエラーを防止できます。

関連項目:

「SELinuxの問題」

E.36.5 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サーバーを設定します。

E.36.6 Domino Webサーバーの問題

認証イベントの失敗: Domino Webサーバーの場合、Access Managerを介したURLのりダイレクトは、認証タイプがBasic Over LDAPに設定され、リダイレクトされるURLが次のいずれかで示されていると、動作しないことがあります。

同じWebサーバー上に存在する相対パス

または、ホスト識別子文字列の組合せで定義されたコンピュータ名を含む、同じWebサーバー上のフルパス

認証の失敗イベントを解決するには、ホスト識別子グループの下で定義されていないコンピュータ名を使用してリダイレクトされるURLを設定する必要があります。たとえば、コンピュータのIPアドレスです。

この問題はフォームベースの認証タイプでは発生しません。

ヘッダー変数: クライアント証明書認証スキームを使用しているときに、REMOTE_USER以外のヘッダー変数を、Lotus Notes Domino WebサーバーにインストールされたWebgateに渡すことができない場合があります。

たとえば、ヘッダー変数はクライアント証明書認証を発生させるリクエストには設定できません。しかし、その他のすべてのリクエストにはヘッダー変数を設定できます。

詳細は、第26章「10g Webgate用Lotus Domino Webサーバーの構成」を参照してください。

E.36.7 エラー、アクセスの消失および予期しない動作

症状: Webサーバー・インスタンスの作成に使用したものと違うユーザーIDを使用してUNIXにAccess Managerをインストールすると、Access Managerが不安定になることがあります。次のような動作が発生する可能性があります。

- ランダムなバグ・レポート・ページ

- ログ・ファイルへの書込み失敗エラー

- Webページへのアクセスの消失

解決策: chownコマンドを使用してファイルの権限を変更します。Access Managerディレクトリを、Webサーバー・インスタンスを作成するのに使用したのと同じユーザーIDに変更します。

E.36.8 ISA Webサーバーの既知の問題

WebgateはISAPIの拡張を使用してユーザー拒否エラー・メッセージおよび診断ページを表示します。しかし、ISA 2006は拡張をサポートしていません。そのため、

- ユーザーがWebgateによりアクセス拒否される場合、ユーザーはAccess Managerのアクセス拒否エラー・メッセージではなく、ページが表示されないエラー・メッセージを受け取ります。

- 診断URL、http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1は、ISAに対しては動作しません。

E.36.9 LinuxThreadsでOracle HTTP Serverが開始しない

Oracle HTTP ServerにWebgateインスタンスをインストールすると、サーバーが起動しません。これは、Access Managerで古いLinuxスレッド・モデルを使用しているために発生します。

注意:

Access Managerの実行時は、デフォルトではLinuxThreadsが使用されます。これは環境変数LD_ASSUME_KERNELが2.4.19に設定されていることが必要です。NPTLを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

E.36.10 Linux Red Hat 4上でOracle HTTP Server Webgateが初期化されない

この状況は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またはそれ以上にアップグレードする必要があります。

E.36.11 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

E.36.12 IIS v6 Webサーバーの問題

IIS 6 Webサーバーでのみ、WWWサービスをIIS 5.0分離モードで実行する必要があり、これはISAPI postgateフィルタの要件です。この例は、32ビットWindowsオペレーティング・システムで実行している32ビットの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

E.36.13 Sun Webサーバーの開始時のPCLOSEエラー

症状: Sun Webサーバーを開始しようとしたときに、次のようなエラーが発生します。

Unable to start, PCLOSE

解決策: たくさんの問題がこのエラーを引き起こす可能性があります。

- obj.confファイルの構文エラー

- obj.confファイルの先頭のスペース

- Webサーバー・インスタンスの作成に使用したのとは異なるユーザーIDでのAccess Managerのインストール

- obj.confファイルの最後にある改行

E.36.14 IIS DLLの削除および再インストール

Access ManagerがMicrosoftのIIS Webサーバーで実行している場合、Access Managerを再インストールするときには次のISAPIフィルタを手動でアンインストールおよび再インストールする必要があります。

- tranfilter.dll

- oblixlock.dll(Webgateがインストール済の場合)

- webgate.dll(Webgateがインストール済の場合)

IIS DLLを削除および再インストールする手順

1. Access Managerをアンインストールします。

2. 前述のDLLを手動でアンインストールします。

3. Access Manager.Active Directoryを再インストールします。

4. DLLを手動で再インストールします。

注意:

これらのフィルタは使用しているIISのバージョンにより異なる可能性があります。これらのフィルタが存在しないまたは別のものが存在する場合、存在するフィルタを削除する必要があるかどうかはOracleにお問い合せください。

E.37 Windowsネイティブ認証

問題

Windowsネイティブ認証の設定後、およびWNA保護ページにアクセスすると、ブラウザはユーザー名またはパスワード(およびその両方)が正しくないことを示すエラーを受け取ることがあります。

原因

Oracle Access Managementが使用するアイデンティティ・ストアがWindows Active Directoryを指していない可能性があります。デフォルトでは、アイデンティティ・ストアは組込みLDAPです。

解決策

1. Oracle Access Managementコンソールで、アイデンティティ・ストアの構成、「システム構成」、「データソース」、「ユーザー・アイデンティティ・ストア」を確認します。

2. LDAPストア設定がActive Directoryを指していることを確認します。

Mobile and Social用語集

アプリケーション・プロファイル

モバイル・サービスを使用するアプリケーションのアプリケーション固有の構成の詳細が含まれます。アプリケーション・プロファイルに含まれる詳細には、アプリケーションの名前、アプリケーションの簡単な説明、名前と値の属性ペアのリストなどがあります。Oracle Access Management Mobile and Socialから、アプリケーションによってサービス(トークン、ユーザー・プロファイル情報)を取得できるようにするには、アプリケーション・プロファイルが必要になる場合があります。

認証サービス・プロバイダ

バックエンドのアイデンティティ・サービス・プロバイダが、モバイル(REST)サービス・コールを使用したトークン交換を介して、ユーザー、クライアント・アプリケーションおよびMobile and Socialへのアクセス権限を認証できるようにします。トークン・サービスとも呼ばれます。認証および検証の成功時に、一部の操作ではトークンがクライアント・アプリケーションに返される場合があります。

認証サービス・プロバイダは、構成可能な3つのサービス・プロバイダ構成オプションの1つです。「認可サービス・プロバイダ」および「ユーザー・プロファイル・サービス・プロバイダ」も参照してください。

認可サービス・プロバイダ

Mobile and Socialおよびアイデンティティ・サービス・プロバイダが、モバイル(REST)サービス・コールを使用して認可を決定できるようにします。

認可サービス・プロバイダは、構成可能な3つのサービス・プロバイダ構成オプションの1つです。「認証サービス・プロバイダ」および「ユーザー・プロファイル・サービス・プロバイダ」も参照してください。

アイデンティティ・サービス・プロバイダ

「サービス・プロバイダ」を参照してください。

アイデンティティストア・サービス・プロバイダ

「ユーザー・プロファイル・サービス・プロバイダ」を参照してください。

インターネット・アイデンティティ・サービス

クラウドベースの認証サービス・プロバイダによって実装される標準のプロトコル(OAuthやOpenIDなど)を使用して、これらのプロバイダに簡単にアクセスできるようにします。インターネット・アイデンティティ・サービスでは軽量のインフラストラクチャと事前定義されたサービス実装が提供され、これらを使用することで、Mobile and Socialは、一般的なクラウドベースのサービス・プロバイダ(GoogleやYahoo、Facebook、Twitter、LinkedInなど)との連携時にリライイング・パーティ(RP)として機能できるようになります。Javaインタフェースを実装して、追加のOpenIDおよびOAuthのサービス・プロバイダをMobile and Socialに追加することもできます。

Mobile and Socialで提供される別の中核的なIDaaS (Identity-as-a-Service)機能である「モバイル・サービス」も参照してください。

モバイル・サービス

Webアプリケーション、モバイル・アプリケーションおよびデスクトップ・アプリケーションを既存のアイデンティティ・インフラストラクチャに接続して、認証、認可および基本的なユーザー・プロファイル・ディレクトリ・サービスを提供します。モバイル・サービスでは、Oracle Identity Access Management (IAM)製品、およびLDAPと互換性があるバックエンド・ディレクトリ・サーバーがサポートされます。モバイル・サービスでは、シンプルなRESTインタフェースを使用して、クライアント・アプリケーションをMobile and Socialサーバーに接続します。

Mobile and Socialで提供される別の中核的なIDaaS (Identity-as-a-Service)機能である「インターネット・アイデンティティ・サービス」も参照してください。

モバイル・シングル・サインオン・エージェント・アプリケーション

iOSおよびAndroidモバイル・デバイスにコンパニオン・アプリケーションとしてインストールし、リモートのMobile and Socialサーバーと、バックエンドのアイデンティティ・サービスとの認証を必要とするビジネス・アプリケーションの間のプロキシとしての役割を果たします。モバイル・シングル・サインオンを使用すると、エンド・ユーザーは、同じデバイスではアプリケーションごとに資格証明を提供しなくても、複数のモバイル・アプリケーションを使用できます。ネイティブ・デバイス・アプリケーションに加えて、ブラウザベースのアプリケーションもサポートされています。モバイル・シングル・サインオン・エージェント・アプリケーションは、Mobile and Socialを使用する上で必須ではありませんが、同じモバイル・デバイス上で複数のアプリケーションを使用する場合、これがないとシングル・サインオンは機能しません。iOSおよびAndroidモバイル・サービスSDKを使用して、カスタム・モバイル・シングル・サインオン・エージェント・アプリケーションを作成したり、iTunes App StoreからOracleモバイル・セキュリティ・アプリケーション(Oracle商標付きのiOSデバイス用アプリケーション)をダウンロードできます。

「Oracleモバイル・セキュリティ・アプリケーション」も参照してください。

Oracle Access Management Access Manager

高信頼性でパーソナライズされたWebアプリケーションへのアクセスを可能にし、認証、認可、Webシングル・サインオンおよび識別サービスを提供するOracle製品。Access Managerには各種Webサービス、アプリケーション・サーバーおよびポータル用のサポートが含まれます。Access Managerには、BASICおよび拡張認証の各種フォームをサポートし、ステップアップ認証ルールの定義機能が含まれます。

Oracle Adaptive Access Manager(OAAM)

ユーザー・レベルとデバイス・レベルの両方での堅牢な認証を提供するOracle製品。Mobile and Socialとあわせてインストールすると、Oracle Adaptive Access Managerは、デバイス属性(携帯電話番号や地理的な位置データなど)を分析し、デバイスがVPNに対応していることと、ジェイルブレークされていないことを検証してから、モバイル・デバイスのフィンガープリントと認証を行います。デバイス・フィンガープリント・データを使用して、実行時の認証を決定することもできます。たとえば、認可されていない国や場所からユーザーの認証が実行された場合に認証を拒否できます。また、Oracle Adaptive Access Managerでは、ユーザーが通常の時間以外にデバイスを使用していたり、最後の認証から地理的に遠く離れている場合に、ナレッジベース認証の質問でユーザーが本人であるか確認したり、ワンタイム・パスワード(OTP)機能を使用した認証をユーザーに要求することができます。OAAMは、特定のデバイスを登録(またはホワイトリストに記載)することもできます。

Mobile and Social

アプリケーションを実行するユーザーと、信頼できる認証サービスおよび認可サービスの間の橋渡しの役割を果たすことで、IDaaS (Identity-as-a-Service)機能を登録済アプリケーションに拡張します。Mobile and Socialでは、次の2つの無償の機能セットが提供されます。 (1) モバイル・サービスは、アプリケーションを、Oracle Identity Access Management (IAM)製品スイートで使用可能な認証サービス、認可サービスおよびディレクトリ・サービスに接続するインタフェースを提供し、(2) インターネット・アイデンティティ・サービスは、一般的なクラウドベースのアイデンティティ認証および認可サービス(GoogleやYahoo、Facebook、Twitter、LinkedInなど)との連携時に、Mobile and Socialがリライイング・パーティ(RP)の役割を果たすことができるようにする機能を提供します。Mobile and Socialではソフトウェア開発キット(SDK)が提供され、開発者はこのキットを使用して、モバイル・サービスの機能およびインターネット・アイデンティティ・サービスの機能を各自のアプリケーションに統合できます。さらに、シンプルなRESTインタフェースによってクライアント・アプリケーションをMobile and Socialサーバーへ接続するため、開発者は、Mobile and SocialサーバーへのMobile and Social RESTコールを送受信するコードを書くことができます。

Oracleモバイル・セキュリティ・アプリケーション

iTunes App Storeからダウンロード可能な、Oracle商標付きのiOSデバイス用のモバイル・シングル・サインオン・エージェント・アプリケーション。

「モバイル・シングル・サインオン・エージェント・アプリケーション」も参照してください。

リライイング・パーティ

ログインするユーザーの認証に、信頼できる外部のアイデンティティ・プロバイダを使用するWebサイト、Webサービスまたはアプリケーション。Mobile and Socialは、一般的なクラウドベースのサービスとの連携時にリライイング・パーティ(RP)として機能させることができます。

「インターネット・アイデンティティ・サービス」も参照してください。

REST

HTTPおよびWorld Wide WebはRESTの原則に準拠しているため、特にWeb開発に適しているソフトウェア・アーキテクチャの方式。RESTの制約と原則により、適切に設計されたWebサイト、WebサービスまたはWebアプリケーションがサーバーに存在するリソースをどのように作成、取得、更新および削除するかが決まります。RESTは、REpresentation State Transferの頭字語です。

RESTful

RESTの制約および原則に準拠したシステムまたはアーキテクチャ。

セキュリティ・ハンドラ・プラグイン

デバイス登録中にセキュリティ・ロジックが適用されるMobile and Socialコンポーネント。Mobile and Socialには、Oracle Adaptive Access Managerで高度なデバイス登録ロジックの使用を可能にするOAAMSecurityHandlerPluginまたはより限定されたデバイス登録ロジックであるデフォルトのセキュリティ・ハンドラ・プラグインの2つのセキュリティ・ハンドラ・プラグインが含まれます。

サービス・ドメイン

1つ以上のアプリケーションをアクセス管理サービスおよびアイデンティティ管理サービスのセットに関連付ける論理グループ化。各サービス・ドメインでは、アプリケーションにどのようにMobile and Socialのサービスへのアクセスを許可するかを指定します。サービス・ドメインを構成するには、メインのモバイル・サービス・ページを使用して、アプリケーション・プロファイルをサービス・プロファイルに関連付けます。組織では通常、1つのサービス・ドメインが必要ですが、複数のサービス・ドメインを使用することもできます。

サービス・エンドポイント

特定のモバイル・サービス(REST)のフロントエンドのサービスを表す文字列。エンドポイントは、バックエンドのサービス・プロバイダとフロントエンドのクライアント・アプリケーションが通信に使用するUniform Resource Identifier (URI)に追加されます。

サービス・プロファイル

サービス・プロバイダのサービス・エンドポイントURLをMobile and Socialモバイル・サービス・サーバーに定義します。サービス・プロファイルは論理的な構成です。複数のサービス・プロファイルを作成して、1つのサービス・プロバイダに対して異なるトークン機能やサービス・エンドポイントを定義することもできます。各サービス・プロバイダ・インスタンスには、対応する少なくとも1つのサービス・プロファイル・インスタンスが必要です。サービス・プロファイルを表示および編集するには、モバイル・サービス・コンソール・ページを使用します。

サービス・プロバイダ

認証、認可、ディレクトリの参照および変更などのアイデンティティ・サービスをアプリケーションに提供するバックエンドの信頼できるアイデンティティ・ストア。ユーザー・プロファイル(アイデンティティ・ストア・サービス・プロバイダ)、認証(トークン・サービス・プロバイダ)および認可のサービス・プロバイダ・コンポーネントを構成するには、Mobile and Socialコンソールのメインのモバイル・サービス・ページを使用します。

トークン・サービス

「認証サービス」を参照してください。

ユーザー・プロファイル・サービス・プロバイダ

Mobile and Socialがモバイル(REST)サービス・コールを使用して、アイデンティティ・サービス・プロバイダに問い合せて更新できるようにします。

ユーザー・プロファイル・サービス・プロバイダは、構成可能な3つのサービス・プロバイダ構成オプションの1つです。「認証サービス・プロバイダ」および「認可サービス・プロバイダ」も参照してください。

索引

A  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を有効化する手順」, 25.6.3

A

AAタイムアウトしきい値フィールド, 13.4.1

概要

Oracle Enterprise Manager Fusion Middleware Control, 10.2

Webゲートのインストール, 22.2.3

Access Manager SDK

AccessGate構成パラメータへの影響, 13.4.1

アクセス・サーバー

ロギング, 7.1

アクセス・システム

トランスポート・セキュリティ, 22.7.4

アクセス・ゲート

キャッシュ, 13.4.1

ロギング, 7.1

ユーザー定義パラメータ, 13.2.2

アクセス・ゲートのパスワード・フィールド, 13.4.1 アクション

認証の成功または失敗, 17.10.4

AddDefaultCharsetディレクティブ, 23.5 管理

ページ, B.1.1

管理者

言語, B.1.1, B.1.1

管理者言語

削除, 22.10

Apache, 22.7.1

Apache WebGateと特定リソースの関連付け, 16.4.2.3

Apache v2

アーキテクチャ, 23.4

ディレクティブ, 23.12

HTTPサーバー, 23.3.1

制限, 23.4

Portable Runtimeライブラリ, 23.4

APACHE_WebGate, 23.3 APACHESSL_WebGate, 23.3 app.context, A.2.2 アプリケーション・ドメイン

アプリケーション・ドメイン内のシングル・サインオン, 15.3.3

認証, 15.5.2

複数セッションにわたる保持, 16.10.3

認証スキーム

キャッシュ、13.4.1

時間ベース, 16.10.3

認可, 15.5.2

式, 作成, 45.8.5

シングル・サインオン・クッキー, 使用, 15.6.2.3

自動ログイン, A.1.1 autologin.url, A.2.2

C

キャッシュ

アクセス・ゲート, 13.4.1

InactiveReconfigPeriods, 13.2.2

ObSSOCookie, 5.2.3

キャッシュ・タイムアウト・フィールド, 13.4.1 CachePragmaHeaderフィールド, 13.6.1, 13.6.1, 13.6.1, 13.6.1 証明書モード, 13.2.1, 18.5.1.1 cert_authn.dll, 25.5.2 証明書

アイデンティティ・サーバー22.7.5

完了

WebGateのインストール

Domino, 26.6.1

IISによるWebGateのインストール, 25.5 ISAサーバーによるWebGateのインストール, 24.4, 24.5 構成データ

削除, 22.10

確認

Webgateのインストール, 22.7.10

クッキー

暗号化されたセッション・トークン, 15.6.2.3

複数セッションにわたる存続, 16.10.1

プライマリ・クッキー・ドメイン, 13.4.1, 13.4.1

資格証明の送信, 15.1.2

作成

Webゲートのインストール, 22.7.2

CredentialMapping権限, A.2.2

D

default.auth.level, A.2.2

デプロイメント・タイプ, 1.2.2

診断

ログ・ファイルでの収集, 7.7.1

Domino, 22.7.1

Webサーバー, E.36.6

DSAPIフィルタ, 26.6, 26.6.1 動的認証, A.1.1

E

エンド・ユーザー言語, B.1.1

エンド・ユーザー言語, B.1.1

式

作成, 概要, 45.8.5

F

フェイルオーバーしきい値フィールド, 13.4.1

終了

Webゲートのインストール, 22.7.8

G

グローバル・ログアウト, A.1.1

H

ヘッダー変数

シングル・サインオン, 15.1.2

情報の受渡し, 15.5.2, 17.2, 17.8.1

ProxySSLStateHeader, 13.2.2

資格証明の設定, 15.1.2

WebGateがリバース・プロキシの背後にある場合に使用, 13.2.2

ホスト識別子

追加、16.4.4

削除, 16.4.7

変更, 16.4.6

表示, 16.4.5

「保護されていない場合に拒否」と対比, 13.4.1

ホスト

識別子の構成, 16.4.1.3

I

I18N, B.1

IBM HTTPサーバー, 23.3.2

IHSも参照, 23.3

アイデンティティ・サーバー

証明書のインストール, 22.7.5

ロギング, 7.1

証明書のリクエスト, 22.7.5

IHS, 23.5.1

制限, 23.4

Webサーバー, 23.3.3

IHS v2 Webサーバー, 22.7.1 IIS, 22.7.1

WebゲートによるSSL, 25.5.1

Webgate, 22.7.7, 22.7.8, 22.7.10

IIS仮想Webサーバー, 22.7.1, 25.2.1 IIS Webサーバー

ISAPIも参照, 25.2

インストール

Domino Security(DSAPI)フィルタ, 26.6

アイデンティティ・サーバー証明書, 22.7.5

Webゲート, 22, 22.7

IPアドレスの検証, 13.2.3 ISAプロキシ・サーバー, 22.7.1 ISAサーバー, 24, 24.2 ISAPI, 24.2, 25.2 ISAPI Webゲート・フィルタ, 25.5.3.4.2

L

言語パック

削除, 22.10

言語パック, B.1.1 言語タグ, B.1.1 ロケール, B.1 ローカライズされたメッセージ, B.1.1 ロギング

ログ・レベル, 7.4.4

ロギング

概要7.1

ログ・ハンドラのアクティブ化, 7.4.4

Buffer_Size, 7.6

構成ファイル, 7.2

変更, 7.2.2

要素の順序, 7.4.7

エントリの評価順序, 7.5.1

構造, 7.4

構成ファイルの構造, 7.4, 7.4 デフォルトの構成ファイル, 7.2.2.2, 7.2.2.2 デフォルトのログ構成ファイル, 7.6.1 ログのデフォルト設定, 7.6.1 ログ出力の送信, 7.4.4 File_Name, 7.6 FileLogWriter, 7.3 グローバル・レベルしきい値, 7.4.3 レベル, 7.5 ListName, 7.6 ログ構成ファイルのパス, 7.2.1 ログ・ファイル・バッファ・サイズ, 7.4.4 ログ・ファイル名, 7.4.4 ログ・ファイル・ローテーション, 7.4.4 ログ・レベルの概要, 7.1 ログ・レベル, 各モジュールへのレベルの設定, 7.7 ログ・レベルの表, 7.1.1 ログ出力先, 7.3 ログ・ライター, 7.4.4 ログ・ライター, 7.3 Log_Level, 7.6 Log_Status, 7.5, 7.6 Log_Threshold_Level, 7.5 Log_Writer, 7.6 Max_Rotation_Size, 7.6 Max_Rotation_Time, 7.6 MODULE_CONFIGセクション, 7.7.1 ログ・ファイル内のモジュール, 7.7.1.2 MPFileLogWriter, 7.3 構成ファイル内の要素の順序, 7.4.7 出力の送信先, 7.3 モジュール固有しきい値, 7.7 モジュール固有しきい値の構成, 7.7.2 複数の宛先へのログ・データの送信, 7.3 SysLogWriter, 7.3 SolarisおよびLinuxのシステム・ログ, 7.6.1 Windowsのシステム・ログ, 7.6.1 しきい値, 7.7.1 サーバーの再起動が必要な場合, 7.2.2.1 ログ・データの送信先, 7.3 xmlns, 7.6 login.url.FORM, A.2.2 ログアウト

強制実行, 13.4.1

logout.url, A.2.2 Lotus Notes, 26.6.1, E.36.6

M

手動構成

WebゲートWebサーバー, 22.5, 22.7.7.1

MaxClients, 23.12 「最大接続数」フィールド, 13.4.1 キャッシュ内の最大要素数フィールド, 13.4.1 最大セッション時間フィールド, 13.4.1 MaxSpareServers, 23.12 MaxSpareThreads, 23.12 MinSpareServers, 23.12 MinSpareThreads, 23.12 mod_ssl, 23.5.3 MODULE_CONFIGセクション, 7.7.1 MPM, 23.4, 23.12 mpm_winnt, 23.4, 23.12 mpm_worker_module, 23.4, 23.4, 23.6.5, E.36.5 複数インスタンス

削除, 22.10

マルチプロセス・モジュール

mpmも参照, 23.4

N

名前変更, はじめに

名前, 新規, はじめに, はじめに

net start w3svc, 25.5.3.4.2

net stop iisadmin, 25.5.3.4.2

O

OAMソリューション, A.1.1, A.3

oamAuthnProvider.jar, 22.9.5.1

oblixlock.dll, 25.5.2

ObSSOCookie, 13.2.1, 13.2.3, 13.4.1, 13.4.1

キャッシュ, 5.2.3

複数セッションにわたる保持, 16.10.3

オープンモード, 13.2.1, 18.5.1.1 OPSS SSOフレームワーク, A, A, A.1.1, A.1.1 Oracle Access Manager

保護, 16.9.1.1, 16.9.1.1, 16.9.1.1

非保護, 16.9.1.1

Oracle Business Intelligence Publisher, 8.1 Oracle HTTP Server

OHSも参照, 23.3

Oracle HTTP Server (OHS), E.36.9 Oracle Platform Security Services, 15.5.1

P

PDFファイル, 13.4.1

Peoxwsuew

Somino

UnixにDomino Webサーバーをインストールする手順, 26.2

パフォーマンス, 13.4.1 プラットフォームの要件, 45.3.1 プラグイン

ロギング, 7.1

ポリシー・ドメイン

ルート, 17.5.1.3

DITのトップページURLのプレフィックス, 17.5.1.3

ポリシー・マネージャ

クロック, E.33

認可条件式ルールの作成, 17.12.2

ロギング, 7.1

ポリシー・ドメイン・ルート, 17.5.1.3

使用目的, 17.12.2

ポストゲート・フィルタ, 25.5.3.4.2 postgate.dll, 25.5.3.4.2

ISAサーバー, 24.2

優先ホスト

「保護されていない場合に拒否」と対比, 13.4.1

優先HTTPホスト・フィールド, 13.4.1 プレフォークMPM, 23.4 プライマリCookieドメイン・フィールド, 13.4.1 手順

認証

認証スキームに永続Cookieを定義する手順, 16.10.3

Domino

キーリング・ファイルとスタッシュ・ファイルを生成する手順, 26.5

最初のDominoサーバーを設定する手順, 26.3

Dominoサーバーを起動する手順, 26.4

ロギング

モジュール固有しきい値を構成する手順, 7.7.2

OHS

OHSの起動の失敗を解決する手順, E.36.9

ポリシー・ドメインおよびポリシー

ポリシー・ドメインを作成する手順, 45.8.4

SharePoint

ポリシー・ドメインへ偽装アクションを追加する手順, 45.6.4

IIS構成に偽装dllを追加する手順, 45.6.5

信頼できるユーザーをWebGateにバインドする手順, 45.6.3

SPPS統合についてIISのセキュリティを構成する手順, 45.7.1

SPPSで保護されないIIS仮想サイトを作成する手順, 45.6.6.1

信頼できるユーザーに適切な権限を付与する手順, 45.6.2

統合化のためにOracle Access Managerコンポーネントをインストールする手順, 45.4

サーバー変数を表示するWebページを使用して偽装をテストする手順, 45.6.6.3

イベント・ビューアを使用して偽装をテストする手順, 45.6.6.2

統合のためにシングル・サインオンをテストする手順, 45.13.2

統合をテストする手順, 45.13.1

SharePoint Portal

信頼できるユーザー・アカウントを作成する手順, 45.6.1

シングル・サインオン

ObSSOCookieを保護する手順, 16.10.2

Windowsのチャレンジ/レスポンス認証を無効化する手順, E.17 アンインストール

Oracle Access Managerのコンポーネントをアンインストールする手順, 22.10

Webサーバー

IIS DLLを削除および再インストールする手順, E.19.5, E.36.14

WebGate

ISAPIフィルタとしてcert_authn.dllを追加する手順, 25.5.1

IIS v7に対するISAPIフィルタとしてcert_authn.dllを追加する手順, 25.6.3

複数のWebGateによるISAPIフィルタとしてcert_authn.dllを追加する手順, 25.7.3

ISAサーバーのアクセス・サブディレクトリに対する権限を変更する手順, 24.4.2

IIS 7 Webサーバーでcert_authn.dllを有効化する手順, 25.6.3

IISに対するSSLを有効化する手順, 25.5.1

複数のWebGateによるIISに対するSSLを有効化する手順, 25.7.3

インストールを終了する手順, 22.7.8

ポストゲートISAPIフィルタをインストールする手順, 25.5.3.4.2

Webサーバーを手動で構成する手順, 22.7.7.1

Webサーバー構成の手動更新手順, 22.7.7

ISAPIフィルタの順序付け手順, 25.5.2

ISAサーバー用ISAPIフィルタの順序付け手順, 24.5.3

Webサイト(デフォルト・サイトではない)の保護の手順, 25.5.4

構成詳細の指定手順, 22.7.6

Oracle Access ManagerプラグインをISAサーバーWebフィルタとして登録する手順, 24.5.1

IIS 6でIIS 5.0分離を設定する手順, 25.5.3.4.1

トランスポート・セキュリティ・モードの指定手順, 22.7.4

インストールを開始する手順, 22.7.3

ISAサーバー上でWebGateをアンインストールする前にフィルタの登録を解除する手順, 24.7

Webサーバー構成の更新手順, 22.7.7

WebGate 64ビット

IISおよびクライアント証明書認証に対してSSLを有効化する手順, 25.8.2

プロセスの概要

URLパターンの使用方法, 17.5.1.6

Sharepoint統合による要求の処理, 45.2.2

IWA認証の使用, 45.2.4

ユーザーがアクセスをリクエストする場合, 15.5.2, 15.5.4

props.auth.level, A.2.2 props.auth.uri, A.2.2 props.auth.url, A.2.2 保護

デフォルト・サイトが設定されていない場合, 25.5.4

proxy_module, 23.3.3 公開鍵, 11.6.1

R

削除

Apache v2 Webサーバー構成, 23.13

構成データ, 22.10

IHS v2 Webサーバー構成, 23.13

IIS Webサーバー構成, 25.11

言語パック, 22.10

複数インスタンス, 22.10

OHS v2 Webサーバー構成, 23.13

Webサーバー構成, 22.10

Webサーバー構成変更, 22.10

レポート・ファイル, 13.4.1 リクエスト証明書

アイデンティティ・サーバー22.7.5

リソース

J2EE, 17.5.1.1

ポリシー・ドメイン・ルート, 17.5.1.3

リソース・タイプ

Cプログラム, 17.5.1.1

C++プログラム, 17.5.1.1

CRMアプリケーション, 17.5.1.1

ディレクトリ, 17.5.1.1

Enterprise Java Beans(EJBs), 17.5.1.1

ERPアプリケーション, 17.5.1.1

Javaプログラム, 17.5.1.1

Java Serverページ(JSP), 17.5.1.1

問合せ文字列, 17.5.1.1

Webアプリケーション, 17.5.1.1

Webページ, 17.5.1.1

再起動

ISAサーバー, 24.6

リバース・プロキシ, 23.3.3

S

セキュリティ・フィールド, 13.2.1, 13.2.1, 13.4.1, 13.4.1

セキュリティ・ポリシー, 15.5.2

Security-Enhanced Linux (SELinux), 22.7.8, 23.12, 23.12, 23.12, E.29, E.36.4

共有シークレット

読取りの頻度, 13.2.2

SharePoint統合

概要, 45

シングル・サインオン, 45.2, 45.3

統合の完了, 45.7

IISセキュリティ, 45.7.1

暗号化

ポリシー・ドメインへの偽装アクションの追加, 45.6.4

IISへの偽装DLLの追加, 45.6.5

設定, 45.6

テスト, 45.6.6

Oracle Access Managerコンポーネント, 45.3.2 ユーザー・プロファイルの同期, 45.12 偽装設定タスクの概要, 45.6 統合のテスト, 45.13 信頼できるユーザー

権限の割当, 45.6.2

WebGateへのバインド, 45.6.3

信頼できるユーザー・アカウント, 45.6.1 ユーザー・プロファイルの同期, 45.12 Windowsの偽装, 併用, 45.2.1 シンプル・モード, 13.2.1, 18.5.1.1 シングル・サインオン

定義, 16.5.1

IPアドレスに関する問題, 13.2.3, 13.2.3

ObSSOCookie, 5.2.3

ObSSOCookie, 保護, 16.10.1

指定

Webゲート構成詳細, 22.7.6

WebGateトランスポート・セキュリティ・モード, 22.7.4

SSOログアウトURL, 13.4.1, 13.4.1, 15.6.2.7, 16.11.3, 16.11.3, 19.2.2, 19.2.2, 19.2.2, 20.3.2 SSOサービス, A.1.1 SSOサービスの構成, A.2.1 sso.provider.class, A.2.2 起動

ISAサーバー, 24.6

「状態」フィールド, 13.4.1 停止

ISAサーバー, 24.6

Sun Webサーバー

Webゲート, 22.7.7

T

タスクの概要

インスタンスの追加およびWebGateのインストール, 22.2.2, 22.2.3

IIS WebGateのインストール, 25.5

認可条件式の作成, 45.8.5

シングル・ドメイン・シングル・サインオンの有効化, 15.7, 16.2

ISAサーバー上でのISAPI WebGateのインストールおよび構成, 24.2

ISAサーバー用ISAPI WebGateのインストール, 24.4.1

WebGateのインストール手順, 22.7, 22.9.2

Office SharePoint Server 2007との統合, 45.5

LDAPメンバーシップ・プロバイダを使用して構成されたOffice SharePoint Server 2007との統合, 45.8

ISAサーバー用WebGate構成の実行, 24.4, 24.5

偽装の設定, 45.6

SharePoint統合の設定, 45.7

ThreadsPerChild, 23.12 token.provider.class, A.2.2 翻訳可能情報, B.1.1 トランスポート・セキュリティ

アクセス・システム, 22.7.4

オプション, 13.2.1, 13.2.1, 13.4.1

トラブルシューティング

Apache上のアクセス・サーバーのクラッシュ, E.36.1

ログ・ファイルへの書込み失敗エラー, E.36.7

アクセスの消失, E.36.7

Webページへのアクセスの消失, E.36.7

Sun WebサーバーのPCLOSEエラー, E.36.13

ランダムなバグ・レポート・ページ, E.36.7

IIS DLLの再インストール, E.19.5, E.36.14

Webサーバーの問題, E.36

U

Unicode規格

4.0, B.1

アンインストーラ, 22.10 更新

WebGate Webサーバー構成, 22.7.7

URL

ObSSOCookieの包含, 15.6.2.3

キャッシュ内の最大数, 13.2.2, 13.2.2, 13.4.1

Oracle Access Manager URLs, 保護解除, 16.9.1.1

ポリシー・ドメイン・ルートURL, 17.5.1.3

接頭辞, 17.5.1.3

Oracle Access ManagerのURLの保護, 16.9.1.1, 16.9.1.1, 16.9.1.1

SSOログアウトURL, 13.4.1, 13.4.1, 15.6.2.7, 16.11.3, 16.11.3, 19.2.2, 19.2.2, 19.2.2, 20.3.2

httpsとして格納, 13.2.2

V

仮想Webホスティング, 16.4.2

W

Webサーバー

構成変更

削除, 22.10

Webサーバー

構成変更

削除, 22.10

IHS, 23.3.3 Webサーバー・ホスト

識別子の構成, 16.4.1.3

Webゲート, 15.5.2, 15.5.4

アクセス・サーバーのタイムアウトしきい値, 13.4.1

特定の仮想ホスト、ディレクトリまたはファイルとの関連付け, 16.4.2.3

CacheControlHeader, 13.4.1

CachePragmaHeader, 13.4.1

クロック, E.33

構成詳細, 22.7.6

インスタンスの作成, 22.7.2

IISに対するSSLの有効化, 25.5.1

ID, 22.7.6

IIS, 22.7.7, 22.7.8, 22.7.10

インストール, 22.7

IPアドレスの検証, 13.2.3

ロギング, 7.1

パスワード, 22.7.6

Sun Webサーバー, 22.7.7

webgate.dll, 24.5.3, 25.5.2, 25.5.3.4.2

ISAサーバー, 24.2

Webパス

ロギング, 7.1

ワーカーMPM, 23.4

X

xlC.rte 6.0ランタイム・ライブラリ, 23.3.2

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved.