Oracle® Fusion Middleware

Oracle Identity Federationの管理

11g リリース1(11.1.1)

B66693-04(原本部品番号:E55733-01)

2015年4月

フェデレーテッド・パートナと連携するための構成方法をはじめ、Oracle Identity Federationのデプロイ方法と管理方法について説明します。

Oracle Fusion Middleware Oracle Identity Federation管理者ガイド, 11gリリース1 (11.1.1)

B66693-04

Copyright © 2006, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Vinaye Misra

原本協力者: Deepthi Buddhiraju、Damien Carru、Mrudula Gaidhani、Ari Kermaier、Maya Neelakandhan、Naveen Kumar Vemula

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドの最新情報

- 11gリリース1 (11.1.1.9)における更新内容

- 11gリリース1(11.1.1.7)の新機能と変更機能

- 11gリリース1(11.1.1.6)の新機能と変更機能

- 11gリリース(11.1.1)パッチ・セット4における更新内容

- Oracle Identity Federation 11gリリース1(11.1.1)パッチ・セット3の新機能

- Oracle Identity Federation 11gリリース1(11.1.1)の新機能

第I部 概要

1 Oracle Identity Federationの概要

- 1.1 フェデレーテッドID管理

- 1.1.1 アイデンティティ・フェデレーションにおける課題

- 1.1.2 フェデレーションのユースケース

- 1.1.3 概念

- 1.1.4 フェデレーション・プロトコル

- 1.1.4.1 SAMLの基本

- 1.1.4.2 フェデレーテッドIDの標準の発展

- 1.1.4.3 SAML 1.x

- 1.1.4.4 SAML 2.0

- 1.1.4.5 WS-Federation

- 1.2 Oracle Identity Federation

- 1.2.1 Oracle Identity Federationの特長と利点

- 1.2.2 アーキテクチャ

- 1.2.3 処理フローの概要

- 1.2.4 フェデレーション・プロトコル・プロファイル

- 1.2.4.1 ブラウザPOSTプロファイル

- 1.2.4.2 ブラウザ・アーティファクト・プロファイル

- 1.2.4.3 SOAPバインディング

- 1.2.4.4 ブラウザHTTPリダイレクト・プロファイル

- 1.2.4.5 名前識別子管理プロファイル

- 1.2.4.6 SAML属性共有プロファイル

- 1.2.4.7 WS-Federationパッシブ・リクエスタのプロファイル

- 1.2.4.8 フェデレーション終了プロファイル

- 1.2.4.9 グローバル・ログアウト・プロファイル

- 1.2.4.10 OpenIDプロファイルおよび拡張

- 1.2.5 アフィリエーション

- 1.2.6 暗号化プロバイダ

- 1.2.7 フェデレーション・イベント・フローの例

- 1.2.8 サポートされている標準とアプリケーション

2 Oracle Identity Federationデプロイメントの計画

- 2.1 アーキテクチャ・オプション

- 2.1.1 フェデレーションでのロール

- 2.1.2 プロキシ・サーバー

- 2.1.3 サーバー・セキュリティ

- 2.1.3.1 SSL暗号化

- 2.1.3.2 証明書ベースの認証

- 2.1.3.3 証明書リポジトリおよび検証

- 2.1.4 プロトコル

- 2.2 プロトコルとバインディング

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

- 2.2.1.1 SAML 2.0プロトコル

- 2.2.1.2 SAML 1.xおよびWS-Federationプロトコル

- 2.2.1.3 OpenID 2.0プロトコル

- 2.2.2 プロファイルの選択

- 2.2.2.1 アーティファクト・プロファイルの使用

- 2.2.2.2 POSTプロファイルの使用

- 2.2.2.3 SAMLでのセキュリティに関する考慮事項

- 2.2.2.4 SAML属性共有プロファイルの使用

- 2.2.2.5 WS-Federationログアウト・プロファイルの使用

- 2.2.2.6 OpenIDプロファイルおよび拡張の使用

- 2.3 認証エンジン

- 2.3.1 Oracle Identity Federationのエンジン

- 2.3.2 リポジトリを使用した認証

- 2.3.3 IdPモードでのIdMソリューションを使用する認証

- 2.3.4 SPモードでのOracle Access Managerへの認証状態の伝播

- 2.3.5 SPモードでのOracle Single Sign-Onへの認証状態の伝播

- 2.3.6 HTTP Basic認証

- 2.4 データ・リポジトリ

- 2.4.1 フェデレーション・データ・ストア

- 2.4.2 ユーザー・データ・ストア

- 2.4.3 セッション・データ・ストアおよびメッセージ・データ・ストア

- 2.4.4 構成データ・ストア

- 2.5 インストール要件

- 2.5.1 必須コンポーネント

- 2.6 サイジングのガイドライン

- 2.6.1 デプロイメントおよびアーキテクチャの考慮事項

- 2.6.1.1 プロファイル

- 2.6.1.2 リポジトリ

- 2.6.1.3 一時(セッションおよびメッセージ)ストレージ

- 2.6.1.4 アサーションのセキュリティ

- 2.6.1.5 接続のチューニング

- 2.6.1.6 高可用性

- 2.6.1.7 サーバーのチューニング

- 2.6.1.8 HTTPセッションの永続性

- 2.6.1.9 追加のセキュリティの影響

- 2.6.2 一般的なデプロイ・シナリオ

- 2.6.3 リファレンス・サーバーのフットプリント

- 2.6.4 トポロジ

- 2.7 実装チェックリスト

3 Oracle Identity Federationのデプロイ

- 3.1 概要

- 3.2 デプロイ・シナリオ

- 3.2.1 Oracle Identity FederationとOracle HTTP Serverのデプロイ

- 3.2.1.1 Oracle HTTP Serverのインストール

- 3.2.1.2 Oracle HTTP Serverインスタンスの管理

- 3.2.1.3 Oracle HTTP Serverと管理対象サーバーの関連付け

- 3.2.1.4 Oracle Identity Federationの構成の更新

- 3.2.2 Oracle Identity FederationとOracle Single Sign-Onのデプロイ

- 3.2.2.1 Oracle HTTP Serverインスタンスの作成および管理

- 3.2.2.2 Oracle Single Sign-OnとOHSの統合

- 3.2.2.3 Oracle Single Sign-Onを認証エンジンとして使用する場合のOracle Identity Federationの構成

- 3.2.2.4 Oracle Single Sign-On SP統合を使用する場合のOracle Identity Federationの構成

- 3.2.2.5 Oracle Single Sign-Onの構成

- 3.2.2.6 フェデレーテッド・シングル・サインオンのテスト

- 3.2.3 Oracle Identity FederationとOracle Access Manager 11gのデプロイ

- 3.2.4 Oracle Identity FederationとOracle Access Manager 10gのデプロイ

- 3.2.4.1 OHSの作成および管理

- 3.2.4.2 認証エンジンとしてのOracle Access Managerの統合

- 3.2.4.3 SP統合モジュールとしてのOracle Access Managerの統合

- 3.2.5 Oracle Access Managerに対するOracle Identity Federation/SPの認証

- 3.2.5.1 認証の概要

- 3.2.5.2 既存のフェデレーション・スキームを使用した認証の有効化

- 3.2.5.3 新しいフェデレーション・スキームを作成する場合の認証の有効化

- 3.2.5.4 Oracle Identity Federation資格証明の更新

- 3.2.5.5 Oracle Access Managerに対する認証の無効化

- 3.2.6 Oracle Identity FederationとOracle Directory Server Enterprise Editionのデプロイ

- 3.2.6.1 要件

- 3.2.6.2 Webプロキシ・サーバーを使用しないOracle Identity Federationの構成

- 3.2.6.3 Webプロキシ・サーバーの背後へのOracle Identity Federationの構成

- 3.2.6.4 アイデンティティ・サーバーおよびアクセス管理サーバーの更新

- 3.2.6.5 Oracle Directory Server Enterprise Edition構成ファイルのサンプル

- 3.2.7 テストSPエンジンの使用

- 3.2.7.1 テストSPエンジンの構成

- 3.2.7.2 SPが開始するSSOでのテストSPエンジンの使用

- 3.2.7.3 IdPが開始するSSOでのテストSPエンジンの使用

- 3.2.7.4 テストSPエンジンの結果

- 3.3 アップグレード後の管理

- 3.3.1 11gサーバー署名証明書

第II部 Oracle Identity Federationの管理

4 サーバー管理

- 4.1 基本管理

- 4.1.1 Oracle Identity Federationサーバー管理者について

- 4.1.1.1 ロールについて

- 4.1.1.2 デプロイメントの計画

- 4.1.1.3 他の計画タスク

- 4.1.2 Oracle Identity Federationの管理

- 4.1.3 Oracle Identity Federationのログ・ファイル

- 4.1.4 バックアップ

- 4.2 一般的なタスク

- 4.2.1 サーバー・メタデータの取得

- 4.2.1.1 バージョン

- 4.2.1.2 プロバイダ固有のメタデータ

- 4.2.2 サーバー証明書の取得

- 4.2.2.1 証明書の使用方法の指定

- 4.2.2.2 証明書タイプの指定

- 4.2.3 SPが開始するシングル・サインオンの実行

- 4.2.4 IdPが開始するシングル・サインオンの実行

- 4.2.5 IdPが開始するSSOでのリレー状態の使用

- 4.2.6 ログアウト処理の起動

- 4.2.7 署名検証証明書プロパティの設定(SAML 1.x)

- 4.2.8 SPが開始するシングル・サインオンの実行(SAML 1.x)

- 4.2.9 属性リクエストおよび問合せの送信(SAML 1.x)

- 4.2.9.1 属性リクエスタ・サービスを使用する場合の名前IDフォーマット文字列

- 4.2.10 認証問合せの送信(SAML 1.x)

- 4.3 アイデンティティ・フェデレーションの管理

- 4.3.1 プロバイダの検索

- 4.3.2 信頼できるプロバイダの追加

- 4.3.3 信頼できるプロバイダの更新

- 4.3.4 信頼できるプロバイダの削除

- 4.3.5 SAML 1.xとWSフェデレーションに対するシングル・サインオンの設定

- 4.4 アイデンティティの構成

- 4.4.1 フェデレーテッド・アイデンティティについて

- 4.4.2 アイデンティティ - フェデレーション

- 4.4.3 アイデンティティ - ユーザー

- 4.4.4アイデンティティ - 検索オプション

- 4.5 Oracle Identity Federationの資格証明の管理

5 Oracle Identity Federationの構成

- 5.1 Oracle Identity Federationがメンテナンスするデータ

- 5.1.1 サーバー構成データ

- 5.1.2 ユーザー・フェデレーション・データ

- 5.2 サーバー・プロパティの構成

- 5.2.1 ホスト接続のプロパティ

- 5.2.2 アウトバウンド接続のプロパティ

- 5.3 アイデンティティ・プロバイダの構成 - 共通プロパティ

- 5.4 アイデンティティ・プロバイダの構成 - プロトコル固有のプロパティ

- 5.4.1 SAML 2.0 IdPプロパティの構成

- 5.4.2 SAML 1.x IdPプロパティの構成

- 5.4.3 WS-Federation IdPプロパティの構成

- 5.4.4 OpenID IdPプロパティの構成

- 5.4.5 外部OpenIDプロバイダの構成

- 5.5 サービス・プロバイダの構成

- 5.5.1 サービス・プロバイダの構成 - 共通プロパティ

- 5.5.2 SAML 2.0 SPプロパティの構成

- 5.5.3 SAML 1.x SPプロパティの構成

- 5.5.4 WS-Federation SPプロパティの構成

- 5.5.5 OpenID SPプロパティの構成

- 5.6 Oracle Access Manager AuthZプラグインによる属性共有の構成

- 5.6.1 属性共有で使用されるコンポーネント

- 5.6.2 リモート・ユーザーとローカル・ユーザー

- 5.6.3 Oracle Access Managerプラグインの構成

- 5.6.4 Oracle Access Managerのスキームとポリシーの構成

- 5.6.4.1 属性共有認証スキームの構成

- 5.6.4.2 属性共有認可スキームの構成

- 5.6.4.3 属性共有を使用するOracle Access Managerポリシーの構成

- 5.6.5 SP属性リクエスタとしてのOracle Identity Federationの構成

- 5.6.5.1 OHSでHTTP Basic認証を使用する場合

- 5.6.5.2 OHSを使用せずにHTTP Basic認証を使用する場合

- 5.6.5.3 SSLクライアント認証を使用する場合

- 5.6.6 IdP属性レスポンダとしてのOracle Identity Federationの構成

- 5.6.7 SSL用のOracle Identity Federationの構成

- 5.7 SSOアサーションで属性を送信するアイデンティティ・プロバイダの構成

- 5.8 属性共有用のWebサービス・インタフェース

- 5.8.1 サービス・インタフェースの概要

- 5.8.2 属性リクエスト・メッセージ

- 5.8.3 属性レスポンス・メッセージ

- 5.8.4 インタフェースWSDL

- 5.9 属性マッピングおよびフィルタリングの構成

- 5.9.1 属性マッピングおよびフィルタリングの概要

- 5.9.1.1 属性名マッピング

- 5.9.1.2 属性値マッピング

- 5.9.1.3 属性値フィルタリング

- 5.9.2 マッピングおよびフィルタリング構成

- 5.9.2.1 属性名マッピングの構成

- 5.9.2.2 属性値マッピングの構成

- 5.9.2.3 属性値フィルタリングの構成

- 5.10 セキュリティおよび信頼の構成

- 5.10.1 セキュリティおよび信頼 - ウォレット

- 5.10.2 セキュリティおよび信頼 - プロバイダ・メタデータ

- 5.10.3 セキュリティおよび信頼 - 信頼できるCAおよびCRL

- 5.11 フェデレーションの構成

- 5.12 アイデンティティの構成

- 5.13 データ・ストアの管理

- 5.13.1 ユーザー・データ・ストアの管理

- 5.13.1.1 RDBMSユーザー・データ・ストアを使用するOracle Identity Federationの構成

- 5.13.1.2 LDAPユーザー・データ・ストアを使用するOracle Identity Federationの構成

- 5.13.1.3 ユーザー・データ・ストアとしてのOracle Virtual Directoryの構成

- 5.13.1.4 冗長性ユーザー・データ・ストアの構成

- 5.13.1.5 ユーザー・データ・ストアを使用しない構成

- 5.13.2 フェデレーション・データ・ストアの管理

- 5.13.2.1 RDBMSフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- 5.13.2.2 LDAPフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- 5.13.2.3 XMLフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- 5.13.2.4 フェデレーション・データ・ストアとしてのOracle Virtual Directoryの構成

- 5.13.3 セッション・データ・ストアおよびメッセージ・データ・ストアの管理

- 5.13.4 構成データ・ストアの管理

- 5.13.4.1 ファイル・システム構成データ・ストアの使用

- 5.13.4.2 RDBMS構成データ・ストアの使用

- 5.13.4.3 RDBMS構成データ・ストアが停止した場合

- 5.13.5 RCUを使用したOracle Identity Federationスキーマの作成

- 5.14 認証メカニズムの構成

- 5.14.1 認証メカニズムについて

- 5.14.1.1 デフォルト認証メカニズムの設定

- 5.14.1.2 プロトコル固有の方式からローカル・メカニズム、ローカル・メカニズムから認証エンジンへのマッピング

- 5.14.1.3 ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピング

- 5.14.2 認証メカニズムの構成 - ローカル

- 5.14.3 認証メカニズムの構成 - SAML 2.0

- 5.14.4 認証メカニズムの構成 - SAML 1.x

- 5.14.5 認証メカニズムの構成 - WS-Federation 1.1

- 5.15 認証エンジンの構成

- 5.15.1 認証エンジン - HTTPヘッダー

- 5.15.1.1 HTTPヘッダー認証エンジンの構成

- 5.15.1.2 HTTPヘッダーの属性の構成

- 5.15.2 認証エンジン - Oracle Single Sign-On

- 5.15.3 認証エンジン - Oracle Access Manager 11g

- 5.15.4 認証エンジン - Oracle Access Manager 10g

- 5.15.5 認証エンジン - LDAPディレクトリ

- 5.15.5.1 認証エンジンとしてのOracle Virtual Directoryの構成

- 5.15.6 認証エンジン - データベース・セキュリティ

- 5.15.7 認証エンジン - データベース表

- 5.15.7.1 RDBMS認証エンジンを使用するOracle Identity Federationの構成

- 5.15.8 認証エンジン - 情報カード

- 5.15.9 認証エンジン - フェデレーテッドSSOプロキシ

- 5.15.9.1 フェデレーテッドSSOプロキシ認証エンジンについて

- 5.15.9.2 使用するアイデンティティ・プロバイダの選択

- 5.15.9.3 フェデレーテッドSSOプロキシ認証エンジンの構成

- 5.15.10 認証エンジン - JAAS

- 5.15.11 認証エンジン - カスタム

- 5.16 SP統合モジュールの構成

- 5.16.1 SP統合モジュール - Oracle Single Sign-On

- 5.16.2 SP統合モジュール - Oracle Access Manager 11g

- 5.16.3 SP統合モジュール - Oracle Access Manager 10g

- 5.16.4 SP統合モジュール - テストSPエンジン

- 5.16.5 SP統合モジュール - カスタム

6 その他のサーバー構成

- 6.1 シングル・サインオン・サービスの設定

- 6.1.1 Oracle Single Sign-On

- 6.1.2 Oracle Access Manager

- 6.1.3 SPが開始するSSO

- 6.1.4 IdPが開始するSSO

- 6.2 アフィリエーション関連の作業

- 6.3 追加のLDAP構成

- 6.3.1 LDAP非アクティブ設定の構成

- 6.3.2 LDAP読取りタイムアウト設定の構成

- 6.3.3 LDAP接続に対するECIDサポート

- 6.4 高可用性のための追加構成

- 6.4.1 高可用性LDAPサーバーの構成

- 6.4.2 HTTPセッション状態のスリープ/再試行間隔の構成

- 6.4.3 SSLモードでのOracle Identity Federation HAの構成

- 6.5 追加のRDBMS構成

- 6.5.1 RDBMSセッション・キャッシュの構成

- 6.5.2 RDBMSデータ圧縮の構成

- 6.6 セッション・リポジトリの構成

- 6.6.1 ユーザー・セッションのアサーション属性の格納

- 6.7 追加のHTTP構成

- 6.7.1 Oracle Identity Federationによって設定されるHTTP CookieのHTTPOnlyフラグの構成

- 6.7.2 HTTP POSTプロファイルをカスタマイズする場合の注意事項

- 6.7.3 リダイレクトでの303ステータス・コードの使用

- 6.8 追加のプロトコル構成

- 6.8.1 eAuthモードの構成

- 6.8.2 BAEの直接属性交換プロファイルの構成

- 6.8.3 SAML 2.0 LDAP属性プロファイルの構成

- 6.8.4 オンデマンド・グローバル・ログアウトの構成

- 6.9 SOAPエンドポイントの保護

- 6.9.1 SSLクライアント認証

- 6.9.2 HTTP Basic認証

- 6.9.2.1 SOAP URLを保護するためのHTTP Basic認証の構成

- 6.9.2.2 保護されているSOAP URLに接続するためのOracle Identity Federationの構成

- 6.10 SAML 2.0 IdP検出(共通ドメインCookie)プロファイルの構成

- 6.10.1 CDCを設定するための準備手順

- 6.10.2 アイデンティティ・プロバイダとしてのCDCプロファイルの構成

- 6.10.3 サービス・プロバイダとしてのCDCプロファイルの構成

- 6.10.4 CDC内の信頼できるプロバイダ・リストを表示するためのOracle Identity Federationの構成

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

- 6.11.1 IdP検出サービス・ページの作成

- 6.12 情報カードの設定

- 6.12.1 サーバー側での情報カードの設定

- 6.12.1.1 Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

- 6.12.1.2 Oracle Identity Federationの構成の更新

- 6.12.1.3 個人カード発行者用STSの追加

- 6.12.1.4 マネージ情報カード用STSの追加

- 6.12.2 クライアント側での情報カードの設定

- 6.12.2.1 Oracle Identity Federation SSL証明書のインポート

- 6.12.2.2 個人情報カードの作成

- 6.13 追加のランタイム構成

- 6.13.1 SSO処理およびログアウト処理におけるターゲットURLの検証

- 6.13.2 SSO完了後のSPエンジンへのXMLメッセージの送信

- 6.13.3 エラー・ページのカスタマイズ

- 6.13.4 SSOプロトコル・メッセージに対するスキーマ検証の構成

- 6.14 追加のフェデレーション・データ・ストア構成

- 6.15 Oracle Identity Federation 10gおよびShareIDサービスURLに対する下位互換性の設定

- 6.16 SPモードでの属性および名前IDによるユーザーのマッピング

- 6.16.1 ユーザーの検索

- 6.16.2 Oracle Identity Federationの構成

- 6.16.3 例1: フェデレーテッド・アイデンティティを使用しない場合のSAML 2.0の名前IDによるアサーション・マッピング

- 6.16.4 例2: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる簡単なアサーション・マッピング

- 6.16.5 例3: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる複雑なアサーション・マッピング

- 6.16.6 例4: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せと名前IDマッピングによるアサーション・マッピング

- 6.16.7 例5: フェデレーテッド・アイデンティティを使用しない場合の特定のIdPのアサーション・マッピング

- 6.17 属性問合せマッピングに基づいた自動アカウント・リンク

- 6.17.1 ユーザーの検索

- 6.17.2 Oracle Identity Federationの構成

- 6.17.3 例1: SAML 2.0の名前IDマッピングによる自動アカウント・リンク

- 6.17.4 例2: LDAP/SQL問合せによる簡単な自動アカウント・リンク

- 6.17.5 例3: LDAP/SQL問合せによる複雑な自動アカウント・リンク

- 6.17.6 例4: LDAP/SQL問合せと名前IDマッピングによる自動アカウント・リンク

- 6.17.7 例5: 特定のIdPへの属性問合せによる自動アカウント・リンク

- 6.18 シングル・サインオンでのユーザー・オプトインおよびオプトアウト

- 6.18.1 操作のモード

- 6.18.2 Oracle Identity Federationの構成

- 6.18.3 例1: オフ・モード

- 6.18.4 例2: オプトイン・モード

- 6.18.5 例3: オプトアウト・モード

- 6.18.6 例4: 特定のIdPに対するオプトイン・モード

- 6.19 アサーション処理時のユーザー・マッピングのバイパス

- 6.19.1 Oracle Identity Federationの構成

- 6.20 名前IDマッピングのパートナ単位での上書き

- 6.21 アサーションのオーディエンス制限の構成

- 6.22 証明書パス検証

- 6.23 認証リクエストを使用したACS URLの送信

- 6.24 OpenIDパートナとの統合

- 6.24.1 OpenIDプロバイダ(OP)との統合

- 6.24.1.1 OPパートナのプロビジョニング

- 6.24.1.2 OPへのデータの提供

- 6.24.2 リライイング・パーティ(RP)との統合

- 6.24.2.1 RPパートナのプロビジョニング

- 6.24.2.2 RPへのデータの提供

- 6.24.3 属性の構成

- 6.24.3.1 OPとしてのOracle Identity Federationの属性

- 6.24.3.2 RPとしてのOracle Identity Federationの属性

- 6.25 OpenID UI Extensionの実装

7 診断および監視

- 7.1 監視

- 7.1.1 Oracle Identity Federationのホーム・ページ

- 7.1.2 パフォーマンス・サマリー

- 7.1.2.1 センサーの重みについて

- 7.1.2.2 イベントのメトリック

- 7.1.2.3 状態イベント

- 7.1.2.4 フェーズ・イベント

- 7.2 可用性

- 7.3 ロギング

- 7.3.1 Oracle Identity Federationのロギングについて

- 7.3.1.1 ログのタイプ

- 7.3.1.2 ログ・レベル

- 7.3.1.3 メッセージID

- 7.3.1.4 ログ構成用ツール

- 7.3.2 Oracle Identity Federationのログ・メッセージの表示

- 7.3.2.1 表示するメッセージの選択

- 7.3.2.2 表示オプションの指定

- 7.3.3 Oracle Identity Federationのログの構成

- 7.3.3.1 Oracle Identity Federationのログ・レベルの構成

- 7.3.3.2 Oracle Identity Federationのログ・ファイルの構成

- 7.3.4 一般的なログ・メッセージ

- 7.3.4.1 スレッド中断メッセージ

- 7.4 監査

- 7.4.1 Oracle Identity Federationでの監査について

- 7.4.1.1 監査イベントのカテゴリ

- 7.4.1.2 監査レベル

- 7.4.2 Oracle Identity Federationの監査の構成

- 7.4.2.1 「カスタム」レベルでの監査の構成

- 7.4.3 監査データの表示

8 セキュリティ

- 8.1 Oracle Identity FederationでのSSLの構成

- 8.1.1 SSLサーバーとしてのOracle Identity Federationの構成

- 8.1.1.1 Oracle WebLogic ServerでのSSLの設定

- 8.1.1.2 Oracle Identity Federationの構成

- 8.1.2 SSLクライアントとしてのOracle Identity Federationの構成

- 8.1.2.1 Oracle WebLogic Serverの構成

- 8.1.2.2 Oracle Identity Federationでのキーストア・パスワードの構成

- 8.1.2.3 Oracle Identity FederationをSSLクライアントとして構成する別の方法

- 8.1.2.4 SSL経由によるLDAPサーバーへの接続

- 8.1.2.5 Fusion Middleware ControlによるOracle Identity Federationターゲットの管理を確実にする方法

- 8.1.3 HAモードでのSSLの構成

- 8.2 署名ウォレットおよび暗号化ウォレットの管理

- 8.2.1 署名パスワードおよび暗号化パスワード

- 8.2.2 署名ウォレットまたは暗号化ウォレットの置換

- 8.3 Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

9 Oracle Identity Federationコマンドライン・ツール

- 9.1 Oracle Identity Federationのコマンドライン・ツールの概要

- 9.1.1 WLST環境の設定

- 9.1.2 コマンドの実行

- 9.2 Oracle Identity Federationのコマンド

- 9.2.1 addConfigListEntryInMap

- 9.2.1.1 説明

- 9.2.1.2 構文

- 9.2.1.3 例

- 9.2.2 addConfigMapEntryInMap

- 9.2.2.1 説明

- 9.2.2.2 構文

- 9.2.2.3 例

- 9.2.3 addConfigPropertyListEntry

- 9.2.3.1 説明

- 9.2.3.2 構文

- 9.2.3.3 例

- 9.2.4 addConfigPropertyMapEntry

- 9.2.4.1 説明

- 9.2.4.2 構文

- 9.2.4.3 例

- 9.2.5 addCustomAuthnEngine

- 9.2.5.1 説明

- 9.2.5.2 構文

- 9.2.5.3 例

- 9.2.6 addCustomSPEngine

- 9.2.6.1 説明

- 9.2.6.2 構文

- 9.2.6.3 例

- 9.2.7 addFederationListEntryInMap

- 9.2.7.1 説明

- 9.2.7.2 構文

- 9.2.7.3 例

- 9.2.8 addFederationMapEntryInMap

- 9.2.8.1 説明

- 9.2.8.2 構文

- 9.2.8.3 例

- 9.2.9 addFederationPropertyListEntry

- 9.2.9.1 説明

- 9.2.9.2 構文

- 9.2.9.3 例

- 9.2.10 addFederationPropertyMapEntry

- 9.2.10.1 説明

- 9.2.10.2 構文

- 9.2.10.3 例

- 9.2.11 deleteCustomAuthnEngine

- 9.2.11.1 説明

- 9.2.11.2 構文

- 9.2.11.3 例

- 9.2.12 deleteCustomSPEngine

- 9.2.12.1 説明

- 9.2.12.2 構文

- 9.2.12.3 例

- 9.2.13 deleteProviderFederation

- 9.2.13.1 説明

- 9.2.13.2 構文

- 9.2.13.3 例

- 9.2.14 deleteUserFederations

- 9.2.14.1 説明

- 9.2.14.2 構文

- 9.2.14.3 例

- 9.2.15 changeMessageStore

- 9.2.15.1 説明

- 9.2.15.2 構文

- 9.2.15.3 例

- 9.2.16 changePeerProviderDescription

- 9.2.16.1 説明

- 9.2.16.2 構文

- 9.2.16.3 例

- 9.2.17 changeSessionStore

- 9.2.17.1 説明

- 9.2.17.2 構文

- 9.2.17.3 例

- 9.2.18 createConfigPropertyList

- 9.2.18.1 説明

- 9.2.18.2 構文

- 9.2.18.3 例

- 9.2.19 createConfigPropertyListInMap

- 9.2.19.1 説明

- 9.2.19.2 構文

- 9.2.19.3 例

- 9.2.20 createConfigPropertyMap

- 9.2.20.1 説明

- 9.2.20.2 構文

- 9.2.20.3 例

- 9.2.21 createConfigPropertyMapInMap

- 9.2.21.1 説明

- 9.2.21.2 構文

- 9.2.21.3 例

- 9.2.22 createFederationPropertyList

- 9.2.22.1 説明

- 9.2.22.2 構文

- 9.2.22.3 例

- 9.2.23 createFederationPropertyListInMap

- 9.2.23.1 説明

- 9.2.23.2 構文

- 9.2.23.3 例

- 9.2.24 createFederationPropertyMap

- 9.2.24.1 説明

- 9.2.24.2 構文

- 9.2.24.3 例

- 9.2.25 createFederationPropertyMapInMap

- 9.2.25.1 説明

- 9.2.25.2 構文

- 9.2.25.3 例

- 9.2.26 createPeerProviderEntry

- 9.2.26.1 説明

- 9.2.26.2 構文

- 9.2.26.3 例

- 9.2.27 getConfigListValueInMap

- 9.2.27.1 説明

- 9.2.27.2 構文

- 9.2.27.3 例

- 9.2.28 getConfigMapEntryInMap

- 9.2.28.1 説明

- 9.2.28.2 構文

- 9.2.28.3 例

- 9.2.29 getConfigProperty

- 9.2.29.1 説明

- 9.2.29.2 構文

- 9.2.29.3 例

- 9.2.30 getConfigPropertyList

- 9.2.30.1 説明

- 9.2.30.2 構文

- 9.2.30.3 例

- 9.2.31 getConfigPropertyMapEntry

- 9.2.31.1 説明

- 9.2.31.2 構文

- 9.2.31.3 例

- 9.2.32 getFederationListValueInMap

- 9.2.32.1 説明

- 9.2.32.2 構文

- 9.2.32.3 例

- 9.2.33 getFederationMapEntryInMap

- 9.2.33.1 説明

- 9.2.33.2 構文

- 9.2.33.3 例

- 9.2.34 getFederationProperty

- 9.2.34.1 説明

- 9.2.34.2 構文

- 9.2.34.3 例

- 9.2.35 getFederationPropertyList

- 9.2.35.1 説明

- 9.2.35.2 構文

- 9.2.35.3 例

- 9.2.36 extractproviderprops

- 9.2.36.1 説明

- 9.2.36.2 構文

- 9.2.37 setproviderprops

- 9.2.37.1 説明

- 9.2.37.2 構文

- 9.2.38 getFederationPropertyMapEntry

- 9.2.38.1 説明

- 9.2.38.2 構文

- 9.2.38.3 例

- 9.2.39 listCustomAuthnEngines

- 9.2.39.1 説明

- 9.2.39.2 構文

- 9.2.39.3 例

- 9.2.40 listCustomSPEngines

- 9.2.40.1 説明

- 9.2.40.2 構文

- 9.2.40.3 例

- 9.2.41 loadMetadata

- 9.2.41.1 説明

- 9.2.41.2 構文

- 9.2.41.3 例

- 9.2.42 oifStatus

- 9.2.42.1 説明

- 9.2.42.2 構文

- 9.2.42.3 例

- 9.2.43 removeConfigListInMap

- 9.2.43.1 説明

- 9.2.43.2 構文

- 9.2.43.3 例

- 9.2.44 removeConfigMapEntryInMap

- 9.2.44.1 説明

- 9.2.44.2 構文

- 9.2.44.3 例

- 9.2.45 removeConfigMapInMap

- 9.2.45.1 説明

- 9.2.45.2 構文

- 9.2.45.3 例

- 9.2.46 removeConfigProperty

- 9.2.46.1 説明

- 9.2.46.2 構文

- 9.2.46.3 例

- 9.2.47 removeConfigPropertyList

- 9.2.47.1 説明

- 9.2.47.2 構文

- 9.2.47.3 例

- 9.2.48 removeConfigPropertyMap

- 9.2.48.1 説明

- 9.2.48.2 構文

- 9.2.48.3 例

- 9.2.49 removeConfigPropertyMapEntry

- 9.2.49.1 説明

- 9.2.49.2 構文

- 9.2.49.3 例

- 9.2.50 removeFederationListInMap

- 9.2.50.1 説明

- 9.2.50.2 構文

- 9.2.50.3 例

- 9.2.51 removeFederationMapInMap

- 9.2.51.1 説明

- 9.2.51.2 構文

- 9.2.51.3 例

- 9.2.52 removeFederationMapEntryInMap

- 9.2.52.1 説明

- 9.2.52.2 構文

- 9.2.52.3 例

- 9.2.53 removeFederationProperty

- 9.2.53.1 説明

- 9.2.53.2 構文

- 9.2.53.3 例

- 9.2.54 removeFederationPropertyList

- 9.2.54.1 説明

- 9.2.54.2 構文

- 9.2.54.3 例

- 9.2.55 removeFederationPropertyMap

- 9.2.55.1 説明

- 9.2.55.2 構文

- 9.2.55.3 例

- 9.2.56 removeFederationPropertyMapEntry

- 9.2.56.1 説明

- 9.2.56.2 構文

- 9.2.56.3 例

- 9.2.57 removePeerProviderEntry

- 9.2.57.1 説明

- 9.2.57.2 構文

- 9.2.57.3 例

- 9.2.58 setConfigProperty

- 9.2.58.1 説明

- 9.2.58.2 構文

- 9.2.58.3 例

- 9.2.59 setCustomAuthnEngine

- 9.2.59.1 説明

- 9.2.59.2 構文

- 9.2.59.3 例

- 9.2.60 setCustomSPEngine

- 9.2.60.1 説明

- 9.2.60.2 構文

- 9.2.60.3 例

- 9.2.61 setFederationProperty

- 9.2.61.1 説明

- 9.2.61.2 構文

- 9.2.61.3 例

第III部 Oracle Universal Federation Framework

10 サード・パーティのIDおよびアクセス管理モジュールとの統合

- 10.1 カスタム実装のためのバックグラウンド情報

- 10.2 アーキテクチャおよびフロー

- 10.2.1 アーキテクチャ

- 10.2.2 認証エンジン・フレームワーク

- 10.2.3 SP統合エンジン・フレームワーク

- 10.2.4 ログアウト

- 10.2.5 要件

- 10.3 カスタム認証エンジンの作成

- 10.3.1 カスタム認証エンジンの計画

- 10.3.2 認証モジュールの開発および実装

- 10.3.3 Oracle Single Sign-On統合用のサンプルの認証モジュール

- 10.3.4 LDAP統合用のサンプルの認証モジュール

- 10.4 カスタムSP統合エンジンの作成

- 10.4.1 カスタムSP統合エンジンの計画

- 10.4.2 統合モジュールの開発および実装

- 10.4.2.1 パスURL

- 10.4.2.2 SP統合エンジンの追加または変更

- 10.4.2.3 サービスの実装

- 10.4.3 サンプルの統合モジュール

- 10.4.4 サンプルの統合モジュール1: Oracle WebLogic Server JavaEE統合

- 10.4.5 サンプルの統合モジュール2: カスタム・シングル・サインオン統合

- 10.5 ログアウト

- 10.5.1 ログアウト・フローの変更

- 10.5.2 サンプルのログアウト・サービス

- 10.5.3 ログアウト・サービス例1

- 10.5.4 ログアウト・サービス例2

11 ビジネス処理プラグイン用のOracle Identity Federationの構成

- 11.1 ビジネス処理プラグインについて

- 11.1.1 ビジネス処理プラグインの基本フロー

- 11.1.2 実装

- 11.1.3 プラグインの構築、操作およびパラメータ

- 11.2 ビジネス処理プラグインの構成

- 11.3 プラグインのパッケージ化

- 11.4 JavaEEセキュリティの構成

- 11.5 プラグインとリダイレクト・ページの例

- 11.6 ビジネス処理プラグインAPI

12 カスタム・アクションの実装

- 12.1 カスタム・アクションの概要

- 12.1.1 認証エンジン用の前処理および後処理カスタム・アクション

- 12.1.2 SP統合エンジン用の前処理および後処理カスタム・アクション

- 12.1.3 カスタム・アクションのアーキテクチャ

- 12.1.3.1 SPとしてのOracle Identity Federationのフロー

- 12.1.3.2 ユーザーを認証するOracle Identity Federationのフロー

- 12.2 認証エンジン用の前処理カスタム・アクション

- 12.2.1 前処理カスタム・アクションの実装

- 12.2.2 カスタム・アクション用のOracle Identity Federationの構成

- 12.3 認証エンジン用の後処理カスタム・アクション

- 12.3.1 後処理プラグインの実装

- 12.3.2 プラグイン用のOracle Identity Federationの構成

- 12.3.3 後処理カスタム・アクションの例

- 12.3.3.1 設定

- 12.3.3.2 パッケージ化

- 12.3.3.3 Oracle Identity Federationの構成

- 12.3.3.4 cookieextract.jspの実装

- 12.4 SP統合エンジン用の前処理カスタム・アクション

- 12.4.1 前処理プラグインの実装

- 12.4.2 プラグイン用のOracle Identity Federationの構成

- 12.4.3 前処理プラグインの例

- 12.4.3.1 設定

- 12.4.3.2 パッケージ化

- 12.4.3.3 Oracle Identity Federationの構成

- 12.5 SP統合エンジン用の後処理カスタム・アクション

- 12.5.1 後処理プラグインの実装

- 12.5.2 プラグイン用のOracle Identity Federationの構成

- 12.5.3 後処理プラグインの例

- 12.5.3.1 設定

- 12.5.3.2 パッケージ化

- 12.5.3.3 Oracle Identity Federationの構成

- 12.5.3.4 fedusercheck.jspの実装

第IV部 付録

A Oracle Identity Federation MBean

- A.1 サーバー全体の構成(config.xml)

- A.1.1 FederationConfig

- A.1.1.1 FederationConfigMXBean

- A.1.1.2 FederationConfig要素

- A.1.2 Config

- A.1.2.1 ConfigMXBean

- A.1.2.2 Config要素

- A.1.3 PropertiesList

- A.1.3.1 PropertiesListMXBean

- A.1.3.2 PropertiesList要素

- A.1.4 PropertiesMap

- A.1.4.1 PropertiesMapMXBean

- A.1.4.2 PropertiesMap要素

- A.2 プロバイダ固有の構成

- A.2.1 CircleOfTrust

- A.2.1.1 CircleOfTrustMXBean

- A.2.1.2 CircleOfTrust要素

- A.2.2 PeerProvider

- A.2.2.1 PeerProviderMXBean

- A.2.2.2 PeerProvider要素

- A.3 データ・ストアの構成

- A.3.1 データ・ストア

- A.3.1.1 DatastoreMXBean

- A.3.1.2 datastore要素

- A.3.2 DiscoveryProvider

- A.3.2.1 DiscoveryProviderMXBean

- A.3.2.2 DiscoveryProvider要素

- A.4 Oracle Identity Federationスキーマ

- A.5 Oracle Identity Federation MBeanへのプログラムによるアクセス

- A.5.1 MBeanサーバーへのアクセス

- A.5.2 Oracle Identity Federation MBeanへのアクセス

- A.6 Oracle Identity Federation MBean API

B Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用

- B.1 プロキシ・サーバーとしてのOracle HTTP Serverの構成

- B.2 Oracle HTTP ServerのSSL構成

C Oracle Identity Federationのトラブルシューティング

- C.1 問題および解決策

- C.1.1 一般的な問題

- C.1.1.1 Microsoft Internet Information Serverでの属性共有でX.509証明書のSubjectDNを取得できない

- C.1.1.2 署名付きSAML 1.0アサーションによってSSOが失敗することがある

- C.1.1.3 ネットワーク接続の暗号化

- C.1.1.4 SSL経由によるLDAPサーバーへの接続

- C.1.1.5 RDBMSメッセージ・ストアでのスレッド中断メッセージ

- C.1.1.6 Oracle Identity FederationがSSL用に構成されている場合にメタデータ・ファイルを使用できない

- C.1.1.7 診断ログのParseExceptionメッセージ

- C.1.2 Oracle Identity Federationの構成に関する問題

- C.1.2.1 日本語ロケールにおいてSAML 1.x POSTメソッドを使用したアサーションが失敗する

- C.1.2.2 「Failed to find orclfednamevalue」エラー

- C.1.2.3 Oracle Identity Federationイベントに対する監査ポリシーの構成

- C.1.2.4 空のJNDI名メッセージ

- C.1.2.5 IDPPROVIDEDNAMEIDVALUEでデータベース列が短すぎるエラー

- C.1.3 Oracle Single Sign-Onのログインに関する問題

- C.1.3.1 正しくないログイン・ページが表示される

- C.1.3.2 ブックマークしたログイン・ページのエラー

- C.1.3.3 プロバイダのメタデータのアップロードに使用したファイルを変更できない

- C.1.4 Oracle Access Managerの構成に関する問題

- C.1.4.1 アクセス・ゲート権限エラー

- C.1.4.2 非ASCIIアクセス・ゲートID

- C.1.4.3 LD_ASSUME_KERNEL値の設定

- C.1.4.4 2つのバックエンドに同一のCookieドメインを使用する

- C.1.4.5 Oracle Access Managerの統合に関する問題

- C.1.5 オペレーティング・システムの構成に関する問題

- C.1.5.1 Linux上のファイル記述子

- C.1.6 実行時/シングル・サインオンに関する問題

- C.1.6.1 WS-Federationが保護するリソースに対するブックマークのエラー

- C.1.6.2 SPが名前IDをローカル・ユーザーにマップできない

- C.1.7 パフォーマンスの問題

- C.1.7.1 LDAPストアの使用時の内部エラー500

用語集

索引

例一覧

- 1-1 SAML 1.0認証アサーションを含むサンプルSAMLPレスポンス

- 1-2 SAML 2.0認証アサーション

図一覧

- 1-1 従業員ポータルからのパートナへのシングル・サインオン

- 1-2 フェデレーテッド・アカウントの作成

- 1-3 SAMLのリクエスト/レスポンス・サイクル

- 1-4 Oracle Identity Federation

- 1-5 Oracle Identity Federationのサード・パーティ統合

- 2-1 ハブ・アンド・スポーク・フェデレーション・ネットワーク

- 2-2 アーティファクト・プロファイル処理フロー

- 2-3 プロキシを使用したアーティファクト・プロファイル処理

- 2-4 POSTプロファイルの処理

- 2-5 プロキシを使用するPOSTプロファイル

- 2-6 OpenIDの処理フロー

- 2-7 IdPモードでのリポジトリを使用した認証

- 2-8 IdPモードでのIdMソリューションを使用した認証

- 2-9 SPモードでのOracle Access Managerによる認証

- 2-10 SPモードでのOracle Single Sign-Onによる認証

- 2-11 一般的なFederationデプロイメント・アーキテクチャ

- 2-12 Oracle Identity Federationのトポロジのサンプル

- 10-1 Oracle Identity Federationモジュールの相互作用

- 10-2 Oracle Identity Federationモジュールの相互作用

- 12-1 カスタム・アクション・プラグイン

表一覧

- 2-1 SAML 2.0の場合のOracle Identity Federationのプロファイルおよびバインディング

- 2-2 SAML 1.xとWS-Federationの場合のOracle Identity Federationのプロファイルおよびバインディング

- 2-3 OpenID 2.0の場合のOracle Identity Federationのプロファイルおよび拡張

- 2-4 実装チェックリスト

- 4-1 Oracle Identity Federationのログ・ファイル

- 4-2 属性リクエスタ・サービスの名前IDフォーマット

- 4-3 資格証明ストアに格納されているOracle Identity Federationのプロパティ

- 5-1 SAML 2.0 IdPの名前IDフォーマット

- 5-2 ユーザー承諾URLに渡されるパラメータ(SPグローバル)

- 5-3 SAML 1.xアイデンティティ・プロバイダの名前IDフォーマット

- 5-4 SAML 2.0 SPのNameIDフォーマット

- 5-5 ユーザー承諾URLに渡されるパラメータ(ローカル設定)

- 5-6 SAML 1.1/1.0 SPの名前IDフォーマット

- 5-7 config.xmlのマッピング例

- 5-8 regexpフィルタリング条件の使用例

- 6-1 フェデレーテッド・シングル・サインオンの組合せ

- 6-2 ポリシーの作成が必要なURL

- 7-1 プロトコル・プロファイルのイベント

- 7-2 セキュリティ処理のイベント

- 7-3 JVTDiscoveryProviderイベント

- 7-4 プロトコル・プロファイルのイベント

- 7-5 フェーズ・イベントのセキュリティ処理

- 7-6 Oracle Identity Federationのログ・レベル

- 7-7 Oracle Identity Federationのメッセージ・カテゴリ

- 9-1 Oracle Identity FederationのWLSTコマンド

- 12-1 認証エンジンのエンジンID

- 12-2 前処理プラグインに対する認証エンジンの構成

- 12-3 後処理プラグインに対するSPエンジンの構成

- A-1 Oracle Identity Federation構成MBeanのObjectName

はじめに

Oracle Identity Federationは、複数ドメインからなるアイデンティティ・ネットワークでのシングル・サインオンおよび認証を可能にする、自己完結型フェデレーション・サーバーです。

対象読者

このドキュメントは、フェデレーテッド・ネットワーク環境でサーバーのデプロイと運用の管理を行うOracle Identity Federation管理者を対象としています。

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

オラクル社のアクセシビリティへの取組みの詳細は、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 (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion MiddlewareおよびOracle Databaseのドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Enterprise Manager Fusion Middleware Controlで使用可能なオンライン・ヘルプ

- Oracle Fusion MiddlewareおよびOracle Databaseのドキュメント・セット。特に次のマニュアルを参照してください。

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementスタート・ガイド』

- Oracle Fusion Middleware管理者ガイド

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

- 『Oracle Fusion Middleware高可用性ガイド』

- 『Oracle Database管理者ガイド』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドの最新情報

この章では、Oracle Identity Federationの最新リリースで導入された新機能について簡単に説明し、各項目の関連項目を記載します。内容は次のとおりです。

- 11gリリース1 (11.1.1.9)における更新内容

- 11gリリース1(11.1.1.7)の新機能と変更機能

- 11gリリース1(11.1.1.6)の新機能と変更機能

- 11gリリース(11.1.1)パッチ・セット4における更新内容

- Oracle Identity Federation 11gリリース1(11.1.1)パッチ・セット3の新機能

- Oracle Identity Federation 11gリリース1(11.1.1)の新機能

注意:
この章では、Oracle Identity Federationサーバーをフェデレーション・サーバーと呼びます。

11gリリース1 (11.1.1.9)における更新内容

このドキュメントでは、11gリリース1 (11.1.1.9)の次の更新について説明します。

- 属性名とアサーション属性の1対1マッピング。第5.9.1.1項を参照してください。

- SSLモードでのHA構成の考慮事項。第6.4.3項を参照してください。

- Oracle Access Manager 11gの後処理プラグイン構成の詳細および例。第12.2.2項、第12.5.3.3項および第12.5.3.4項を参照してください。

- WLST環境に入力する新規コマンド構文。第9.1.2項を参照してください。

- 特定のコマンドの修正されたコマンド構文。第6.20項、第9.2.36.2項および第9.2.37.2項を参照してください。

11gリリース1(11.1.1.7)の新機能と変更機能

このドキュメントでは、11gリリース1(11.1.1.7)の次の更新について説明します。

- Oracle Access Manager 11gとの統合について、アップグレード済11.1.1.7.0環境で操作する場合のアップグレード・スクリプトの実行要件。第 5.16.2項を参照してください。

- バックエンド属性交換(BAE)の直接属性交換プロファイルのサポート。第 6.8.2項を参照してください。

- 外部OpenIDプロバイダの追加手順。第 5.4.5項を参照してください。

11gリリース1(11.1.1.6)の新機能と変更機能

このドキュメントでは、11gリリース1(11.1.1.6)の次の新機能と更新についてについて説明します。

- XML署名におけるSHA-256のサポート

- IdPが開始するSSOでのリレー状態の使用

- Oracle Access Manager 11g認証エンジンのサポート

- Oracle Access Manager 11g SP統合エンジンのサポート

- IdPが開始するSSO処理におけるACS URLのサポート

- SAML 2.0の認証リクエストを使用したACS URLの送信

- OpenID UI Extensionの実装

ドキュメントには次の追加変更も記載されています。

- 第11.3項には、ビジネス処理プラグインのパッケージ化で更新された手順が記載されています。

- 第6.24項では、OpenIDパートナと統合するようにOracle Identity Federationを構成する方法について説明しています。

- 第4.2.5項では、Oracle Identity Federationで、IdPが開始するシングル・サインオンでリレー状態が決定される仕組みについて説明しています。

- 図2-11は、Oracle Identity Federationサーバーの前面にあるWebプロキシを示すように修正されています。

- ドキュメントの様々な訂正箇所が修正されています。

11gリリース(11.1.1)パッチ・セット4における更新内容

このドキュメントは、ドキュメントの訂正箇所を修正するために更新されています。

Oracle Identity Federation 11gリリース1(11.1.1)パッチ・セット3の新機能

11gリリース1(11.1.1)パッチ・セット3には次の機能があります。

- キーストアと暗号化キーの個別のパスワード

- グローバル・ログアウトの拡張機能

- Oracle Identity Federation/SP自身をOracle Access Managerで認証するための構成

- OpenIDプロトコルのサポート

- 新しいHTTPヘッダー認証エンジン

- Oracle Access Manager 11gにおける認証

- WLSTによるプロバイダ設定のインポートおよびエクスポート

- アサーション有効期間の制限

- 名前IDマッピングをパートナ単位で上書きする機能

- SAML 1.xのソースIDのサポート

- 前処理および後処理のカスタム・アクション

- eAuth仕様のサポート

- HTTPヘッダー・コレクタのサポート

このリリースでは、ドキュメントが次のように変更されています。

- カスタマイズ機能は、別の部、第III部「Oracle Universal Federation Framework」にまとめられました。

- PDF版のドキュメントは2冊に分割されました。

Oracle Identity Federation 11gリリース1(11.1.1)の新機能

- WebLogic Serverとの統合: Oracle Identity Federationは、Oracle WebLogic Serverで管理されるJavaコンポーネントになりました。

関連項目:

- Oracle Fusion Middlewareコンポーネント

- 『Oracle Fusion Middlewareコンセプト・ガイド』

- Fusion Middleware Control: Oracle Enterprise Manager Fusion Middleware Controlというグラフィカル・ユーザー・インタフェースを使用してOracle Identity Federationを管理できます。

関連項目:
Oracle Fusion Middlewareの管理の概要

- 共通監査インフラストラクチャとの統合: Oracle Identity FederationがOracle Fusion Middlewareの監査インフラストラクチャと統合されました。コマンドラインまたはFusion Middleware Controlを使用して監査を構成できます。

関連項目:

- 第7.4項「監査」

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 10g(10.1.4.2.0)以上のOracle Single Sign-OnおよびOracle Access Managerのサポート: Oracle Fusion Middleware 11gリリース1(11.1.1)にはOracle Single Sign-OnまたはOracle Access Managerは含まれていません。ただし、Oracle Identity Federation 11gリリース1(11.1.1)は10g(10.1.4.2.0)以上のOracle Single Sign-OnおよびOracle Access Managerと互換性があります。

第I部

概要

第I部では、フェデレーションの概要およびOracle Identity Federationの機能について説明します。

第I部は、次の章で構成されています。

- 第1章「Oracle Identity Federationの概要」

- 第2章「Oracle Identity Federationデプロイメントの計画」

- 第3章「Oracle Identity Federationのデプロイ」

1 Oracle Identity Federationの概要

この章では、フェデレーテッドID管理の概要、およびOracle Identity Federationの特長や利点について説明します。この章には次の項目があります。

- フェデレーテッドID管理

- Oracle Identity Federation

1.1 フェデレーテッドID管理

シングル・サインオン(SSO)は繰返しログインする必要性が少なくなるため幅広く採用されていますが、フェデレーテッド環境つまり、サービスをビジネス・パートナと共有しつつ、そのサービスを不正アクセスから保護する必要がある環境で運用する企業の場合、SSOだけでは不十分です。

フェデレーテッド環境は、各ビジネス・パートナがそれぞれのセキュリティ・ドメインを横断してID情報を共有するメカニズムを提供することにより、ID管理レルムにおける統合を達成できます。

この項では、フェデレーテッドID管理の概要について説明します。これらの項目が含まれます。

- アイデンティティ・フェデレーションにおける課題

- フェデレーションのユースケース

- 概念

- フェデレーション・プロトコル

1.1.1 アイデンティティ・フェデレーションにおける課題

Webベースのアプリケーションへのシングル・サインオンは、この数年間、各種の方法で取り組まれ、解決されてきたビジネス目標です。それでもなお、企業情報システムを効率的なコストで管理するためには大きな課題があります。この課題には次のようなものがあります。

- それらのソリューションの多くが独自規格のものであるために、プロトコルとソフトウェアが特定ベンダー、実装業者、またはデプロイ・シナリオに限定され、他のシングル・サインオン・システムとの相互運用に適していません。

- コンテンツ・フォーマット、サプライ・チェーン、顧客管理システムおよびユーザー・データ・ストアが急増するため、セキュリティとメンテナンスに問題が生じます。たとえば、医療機関にサービスを提供している金融サービス会社の場合、何十万もの従業員アカウントを管理する必要があったり、パスワードの紛失などのイベントやその他のレコード・メンテナンスに対処しながら新しいユーザーをプロビジョニングするために多大なコストが発生する可能性があります。ユーザーの側では、認証システムが様々であるために、複数のIDとパスワードを記憶したり、場合によっては書き留めておくことが必要になりますが、それを行うことは言うまでもなく危険です。

- 絶えず規模が拡大し、活動的になるエンドユーザー・コミュニティでは、情報とアプリケーションに、従業員だけではなく、ベンダー、パートナと顧客からもアクセス可能であることが必要です。従来のアクセス提供の取組みでは、組織内部で個人ユーザーのアカウントをメンテナンスする必要があり、IDデータが重複したり、管理やコンプライアンス上の問題が発生する可能性があります。

フェデレーテッドID管理はSSOパラダイムの進化形で、自社の境界外にあるコンピューティング・リソースやサービスにアクセスする必要性の高まりに応えるものです。フェデレーテッド環境では、そうしたサービスを提供する企業が、個人やその他のエンティティのID情報を、ユーザーの本拠である組織やセキュリティ・ドメインから、信頼性を保って取得できます。これには、次のような利点が伴います。

1. ビジネスが行われている各エンティティにアクセスするエンド・ユーザーが、ログイン資格証明を提示する必要がありません。これにより、多数のログイン名やパスワードを記憶、管理する必要がなくなります。(ただし、両方のアカウントをリンクするために、それぞれのサイトにアカウントが必要です。)

2. いずれかのパートナ組織にすでに認識されているユーザーのIDを管理するために新しいアカウントを作成する必要はありません。先ほどの例で言えば、サービス・プロバイダはクライアントの医療機関が内部的に維持していた従業員データを活用することができます。

関連項目:
詳細な定義については、「フェデレーテッドID管理(FIM)」を参照してください。

1.1.2 フェデレーションのユースケース

この項のユースケースでは、複数のアプリケーションに対する認証を1度のみ行うことで、フェデレーションがエンドユーザーにスムーズな操作感を提供し、前述のような実際のビジネスでの問題を克服できることを説明します。

ユースケース1: パートナ・サイトへのシングル・サインオン

図1-1 従業員ポータルからのパートナへのシングル・サインオン

図1-1は、MyCorpの従業員Maryが次の出張計画を立てようとしている状況を示しています。次の手順を実行することによって、Maryは1つのセッションでスムーズに計画を完成できます。

1. Maryが自分の端末から自社のMyCorp従業員ポータルにアクセスします。

2. WS-Federationに対応したポータルにサインオン・ダイアログが表示されます。

3. Maryがサインオンすると、ポータルにより、Maryの情報が表示されたパーソナライズ・ページが返されます。

4. Maryは出張計画の作成を開始するにあたり、ポータル内でTravelClubのリンクをクリックします。TravelClubは、MyCorp社の従業員に対して旅行サービスへのアクセスを提供するパートナ組織です。MaryはTravelClubとの間にフェデレーテッド関係をすでに確立しています。

5. TravelClubでは、Maryが自分のアカウントにアクセスするために認証を行う必要があり、MyCorpに対しても同じ認証を要求します。MyCorpはTravelClubに対して必要なID情報を返します。これで、MaryはTravelClubサイトに自動的に認証されます。TravelClubがMaryの出張アカウント情報が表示されたページを返します。

6. Maryの作業が終了したら、シングル・グローバル・ログアウト機能を使用して、MyCorpのホームページからTravelClubとMyCorpの両方のセッションをログアウトできます。

この方法では、Maryは自社のWebサイトで1度認証を受けるだけで別のサイトに接続して必要なタスクを実行でき、2番目のサイトであらたに認証を受ける必要がありません。

ユースケース2: パートナ・サイトでの新規フェデレーテッド・アカウント

図1-2 フェデレーテッド・アカウントの作成

図1-2のユースケースでは、MyCorpの別の従業員であるJimがMyCarsに新規アカウントを設定しようとしています。MyCarsは、MyCorpの従業員に格安の自動車修理サービスを提供する外部サイトです。手順は次のとおりです。

1. JimがMyCorpポータルにサインオンします。

2. Jimはポータル内で作業した後で、ポータルの「Vendors」ページに移動して自動車修理サービスを探すために「MyCars」リンクをクリックします。

3. MyCarsに新規アカウントを設定するための情報が要求されます。MyCarsはJimの権限を使用して、JimのIDに関連する情報を取得するためにMyCorpと通信します。

4. これでJimはMyCarsのアカウントを取得できました。このアカウントには、先ほどのユースケースで説明したのと似た方法でアクセスできます。

これらのユースケースは、フェデレーテッド・シングル・サインオンとフェデレーテッドID管理の一般的な使用例です。次の各項で、フェデレーション・テクノロジのキー・コンセプトと、Oracle Identity Federationでのその活用法について詳しく見ていきます。

1.1.3 概念

この項ではフェデレーテッドID管理の主要な概念を説明します。

プリンシパル

プリンシパルは、サービスを利用しフェデレーテッドIDを取得する資格を持つエンティティです。

プリンシパルとは、そのIDが認証を受けることができる、人(「ユーザー」)、ユーザーのグループ(会社など)またはシステム・エンティティです。

これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にアイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)があります。

ドメイン

ドメインとは、プリンシパルがリソースを使用できるWebサイトおよびアプリケーションです。フェデレーテッド・サイトはアイデンティティ・プロバイダ(一部の仕様ではソース・ドメイン)か、サービス・プロバイダ(宛先ドメイン)、またはその両方です。

アイデンティティ・プロバイダ

アイデンティティ・プロバイダ(IdP)は、一連のフェデレーション内でIDの集合を管理、認証および宣言します。

これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にプリンシパルとサービス・プロバイダがあります。

アイデンティティ・プロバイダは、SAML 1.xプロトコルではソース・ドメインとも呼ばれます。この観点では、ソース・ドメインのユーザーが、アクセス先ドメインにあるサイト上のリソースにアクセスするための許可をリクエストする、リクエストの発生箇所がアイデンティティ・プロバイダです。

サービス・プロバイダ

サービス・プロバイダ(SP)はプリンシパルにサービスを提供し、プリンシパルのIDの認証はアイデンティティ・プロバイダに依存します。

サービス・プロバイダは、リライイング・パーティ(SAML)または宛先ドメインとも呼ばれます。ドメインの観点からすると、サービス・プロバイダには、ソース・ドメインのユーザーがアクセスするリソースが含まれます。

サービス・プロバイダはユーザーにWebベースのサービスを提供する組織です。この広範なカテゴリには、たとえば次のような、実質的にすべてのWeb上の組織が含まれます。

- インターネット・ポータル

- 小売業者

- 金融機関

- 行政機関

- NPO(非営利組織)

- 娯楽産業

- 運送業者

これは、Oracle Identity Federationがサポートするアイデンティティ・フェデレーション・プロトコルで定義されている、3つのプライマリ・ロールの1つです。他にアイデンティティ・プロバイダとプリンシパルがあります。

注意:
1つの組織が、一般的あるいは特定の相互作用のコンテキスト内で、アイデンティティ・プロバイダとサービス・プロバイダの両方であることがあります。

OpenIDプロバイダ

OpenIDプロトコルによってユーザー認証を行うプロバイダ。略称はOPです。SAMLのIDプロバイダに類似しています。

リライイング・パーティ

OpenIDのリライイング・パーティ。略称はRPです。SAMLのサービス・プロバイダに類似しています。

主張識別子

OPが管理するユーザーを示す、OpenIDの識別子です。

アソシエーション

OPとRP間における承諾です。メッセージの署名に使用されるMAC秘密鍵を定義します。

検出

OpenIDのOPとRPがサービス・サポートとエンドポイントの場所を特定して検証する際に使用するオンライン手段です。OpenIDの検出は、XRDSメタデータ公開プロトコルによって行われます。OPのXRDSメタデータには、サポートされるサービス(たとえば、属性交換、PAPEなど)やサインオンURLが記述されています。RPのXRDSには、戻りURLが記述されています。

フェデレーション

フェデレーションとは、アイデンティティ・プロバイダとサービス・プロバイダ間の信頼関係です。プリンシパルはこれを利用して、これらのプロバイダとビジネス・トランザクションを実行する際に、シングル・フェデレーテッド・アイデンティティおよびシングル・サインオンを使用できます。

組織は、フェデレーション・テクノロジおよび組織間の信頼関係を定義する運用協定に基づいて、フェデレーションを作成します。

たとえば、企業フェデレーションを作成することにより、アイデンティティ・プロバイダが企業を横断して従業員ネットワークIDを活用できるようになります。別の例として消費者バンキングがあります。この場合、ユーザーの銀行が他の各種サービス・プロバイダとビジネス関係(つまり、フェデレーション)を確立しており、ユーザーはそれらのプロバイダに対して銀行ベースのネットワークIDを使用できます。

フェデレーション・ソリューション

フェデレーションで最も重要な点は、個々のセキュリティ・ドメイン間でIDデータを交換することです。フェデレーションの実現方法を考える場合、信頼レベル、達成目標、そして各種フェデレーションに伴う管理作業量について必然的に考えなければなりません。

注意:
次のリストは、ビジネス・レベルでのフェデレーション、およびフェデレーションの計画時に関連すると思われるソリューションのタイプに対する考え方を定義しています。これらの考え方は、必ずしも特定の技術ソリューションに該当するものではありません。

- 一時フェデレーション
一時フェデレーションでは、追加のIDエンティティ・データの送信や使用を必要とせずに、ドメイン間でユーザー・セッションの転送が行われます。受信者は、送信者を信頼してプリンシパルの認証/認可を行います。

一時フェデレーションは、a)各プロバイダが暗黙的に相互に信頼し合っている場合、b)各プロバイダが共通の標準(SAML 2.0など)に合意している場合に適しています。

一時フェデレーションは、実装および管理が比較的しやすい方法です。ユーザーはリンクをクリックするだけで、認証ユーザーとしてサービス・プロバイダにアクセスできるので、ユーザー操作は透過的になります。

一時フェデレーションの一般的な応用例として、国民に関する情報を独自のドメインで維持、認証するために証明書などの認証方法を使用している政府機関では、他の機関にユーザーをフェデレートすることにより、それらの機関のサービスへのシングル・サインオンが可能になります。

一時フェデレーションの明らかな限界は、送信ドメインの信頼性に起因して、受信ドメインが追加のユーザー検証を実行できないことです。

- アカウント・マッピング
アカウント・マッピングは、確立済の非常に高度な信頼がセキュリティ・ドメインにないと考えられる場合や、フェデレーテッド・ユーザーがアクセスできる情報を制限する場合に適しています。

アカウント・マッピングでは、IDを両方のドメインでメンテナンスする必要があるため、追加の管理作業が必要になります。ドメインは、ユーザーIDを含むメッセージ形式でユーザー情報(アサーション)を交換します。受信者は、このユーザーIDをローカル・ストア内にある既知のIDにマップできます。アカウント・マッピングの利点も同様に、フェデレーションを行うドメイン間で高度な信頼を必要としないことです。

- アカウント・リンク
アカウント・リンクはアカウント・マッピングの拡張です。ただし、ローカルIDの詳細を各ドメインで維持するかわりに、最初にフェデレーションが行われるときにユーザーから取得する情報を受信パートナが使用したり拡張したりすることができ、さらに将来使用するために保管することができます。

アカウント作成のタスクはユーザーに委任されます。そのため、アカウント・リンクではアカウント・マッピングで必要とされる管理作業が軽減されます。

アカウント・リンクおよびアカウント・マッピングの一般的な応用例は旅行業界で見られます。旅行関連企業が関連するパートナとフェデレートして商機を共有することにより、ユーザーは旅行に関するあらゆること(航空券の予約、車のレンタル、ホテルの予約など)を計画できます。また、最小限の認証で必要なサービスにアクセスすることも可能になります。

- 属性フェデレーション
属性フェデレーションは、パートナ間でアクセス制御ポリシーに基づいてリソースへのアクセス権を付与する場合、またはその必要がある場合に有効です。

各ドメインではユーザーIDを維持するかわりに、グループ、ロールなどの情報を維持します。フェデレーション時には、受信パートナがユーザーの属性を調べてその属性をこの認可情報にマップし、許可するアクセスのタイプを決定します。したがって、パートナ間で共通のマッピング・ルールに合意している必要があります。

実際のIDデータではなく、ルールのみを維持すれば済むため、(アカウント・マッピングやアカウント・リンクに比べて)管理がより簡単です。

このタイプのフェデレーションの例として、企業間(B2B)環境があります。この環境ではパートナ間でID情報が交換される一方で、リソースへのアクセスをリクエストするユーザーに対してアクセス権の付与や認可の決定を行うための個々のルールは各パートナが維持します。

- 組合せフェデレーション
組合せフェデレーションでは、その名前が示すように、送信ドメインは識別情報(名前、アドレス、ロールなど)をフェデレーション・リクエストで必要なだけ提供できます。

このフェデレーション方式の長所は、各ドメインでリクエストを形成する際に柔軟性がもたらされる点です。同時に、組合せフェデレーションの短所は、高度な管理が求められる点と、パートナ間で強固な信頼関係と連携が必要になる点です。

アイデンティティ・フェデレーション

アイデンティティ・フェデレーションとは、フェデレーションを作成した1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダで、プリンシパルが保持している場合がある、2つ以上のアカウントの結びつきです。

ユーザーが複数のビジネスに対して持っている、相互に独立している個別のアカウント(ローカルID)をフェデレートすると、2つのエンティティ間にリレーションシップ(任意の数のサービス・プロバイダとアイデンティティ・プロバイダで構成される関係付け)が作成されます。

技術的な観点からすると、プリンシパルの識別に使用する一連のIDや属性についてプロバイダ間で合意がある場合、そのプリンシパルIDはプロバイダ間でフェデレーテッド関係にあると言われています。

シングル・サインオン

シングル・サインオンの場合、ユーザーはアイデンティティ・プロバイダとサービス・プロバイダのフェデレーテッド・グループのメンバーに対して1度サインオンすれば、そのグループ内の各種のリソースをそれ以降使用でき、再び署名する必要がありません。

SAMLプロトコルまたはWS-Federationプロトコルを使用して、プリンシパル間でシングル・サインオン処理を実行するには、SPおよびIdPで次のことが必要です。

- SPとIdPの間にフェデレーションが存在する(信頼できるビジネス・リレーションシップがある)こと。

- プリンシパルが、SPとIdPの両方のローカルID(またはロール)を持っており、その2つのIDがフェデレーテッド関係にあること。

Oracle Universal Federation Framework

Oracle Universal Federation Frameworkには、業界標準のフェデレーション機能に対してすぐに使用できるサポートが用意されています。また、次のような拡張機能も数多く用意されています。

- 認証およびSP統合処理の前後におけるカスタム・アクション(この機能は、前処理プラグインおよび後処理プラグインとも呼ばれます)

- カスタム認証エンジン

- カスタムSP統合エンジン

1.1.4 フェデレーション・プロトコル

セキュリティ・ドメインを横断する相互運用性、保証および信頼上の問題に対処するフェデレーテッド・アーキテクチャの構築では、ID管理統合で有用な構築ブロックとして次のプロトコルが注目を集めています。

- SAML 1.0および1.1。セキュリティ・データ交換(アサーション)で使用するフォーマットや、アサーションの使用手段を提供するプロファイルを定義します。

- SAML 2.0。SAML 1.1の拡張で、追加のプロファイルを提供します。

- WS-Federation。参加しているWebサービスの間でのID、ユーザー属性、認証の信頼を仲介することによって、異なるセキュリティ・レルムのフェデレーションを可能にします。

SAMLとWS-Federationプロトコルは、セキュリティ・ドメイン相互の間での情報の交換、プロバイダ間の調整(「ハンドシェイク」)、およびフェデレーテッド・サインオンとグローバル・ログアウトなどの識別イベントの管理のためのフレームワークを提供します。これらの標準は、ドメインを超えてセキュリティ情報を通信するためのXMLベースのフレームワークを提供します。これには次の利点があります。

- ドメインの疎結合。ディレクトリ間でユーザー・データを同期したりレプリケートする必要がありません。

- プラットフォームやテクノロジに中立な手法。クロスドメイン統合の障害を除去します。

- アプリケーション・サーバー、Webサービス管理、およびセキュリティ製品、セキュリティ・ベンダーにより広くサポートされ、採用する組織は増え続けています。

この項では、基礎的なSAMLの概念とフェデレーション・プロトコルについて詳しく説明します。内容は次のとおりです。

- SAMLの基本

- フェデレーテッドIDの標準の発展

- SAML 1.x

- SAML 2.0

- WS-Federation

Oracle Identity Federationでサポートされているプロファイルの詳細は、第1.2.4項「フェデレーション・プロトコル・プロファイル」を参照してください。

注意:
Liberty 1.xのサポートは非推奨です。

1.1.4.1 SAMLの基本

Security Assertions Markup Language(SAML): オンライン・ビジネス・パートナの間でのセキュリティ情報を交換するための手段として、OASISによって開発された標準です。

二者間の一般的なSAMLメッセージ交換では、片方がリライイング・パーティ、もう一方がアサーティング・パーティとなります。

アサーティング・パーティは、特定のサブジェクトについて、そのサブジェクトが認証されているかどうか、あるアクションを実行する権限を認可されているかどうかなどの情報を宣言します。リライイング・パーティは、アサーティング・パーティが提供した情報を使用して、サブジェクトに関するセキュリティ関連の決定を行います。たとえば、そのサブジェクトが特定のリソースに対して許可されるアクセスの種類などを決定します。

SAMLアサーション

SAMLは、特定のドメイン内でのプリンシパルのアクセス権限を決定する際に使用できる追加のID情報にプリンシパルを関連付けます。SAMLドキュメントはすべて、こうした関連付けを含むアサーション要素を持っています。

SAMLは、次の3種類のアサーションを定義します。これらはサブジェクトに関する1つ以上の事実の宣言です。

- 認証アサーション。ユーザーの識別情報が、特定の時刻において特定の方法によって証明されていることを明示します。

- 属性アサーション。従業員番号やアカウント番号など、ユーザーに関する固有の詳細情報が含まれます。

- 認可アサーション。ユーザーがアクセスできるリソースと、アクセス可能な条件を明示します。

アサーションはすでに発生したイベントについて生成される、コード化された文です。SAMLによって資格証明に関するアサーションが作成されますが、実際にユーザーの認証や許可が行われるわけではありません。

例1-1は、SAMLPレスポンス・メッセージにラップされた典型的なSAML 1.0認証アサーションを示しています。

SAMLのリクエストとレスポンスのサイクル

通常のSAMLサイクルでは、特定のクライアント・リクエストを認証する必要があるリライング・パーティが、SAMLリクエストを発行認証局に送信します。発行認証局はSAMLアサーションで回答し、リクエストされたセキュリティ情報をリライング・パーティに提供します。このサイクルを図1-3に示します。

図1-3 SAMLのリクエスト/レスポンス・サイクル

たとえば、ユーザーがリライング・パーティのSAML準拠サービスにサインインする場合、サービスにより発行認証局に「認証アサーションのリクエスト」が送信されます。発行認証局は、そのユーザーが特定の方法で特定の時刻に認証されていることを記述した「認証アサーション」参照を返します。通常の認証アサーションの詳細は例1-1を参照してください。

サービスは、ユーザーの資格証明を検証するために他のリライイング・パーティ・サイトにこのアサーション参照を渡すことができます。ユーザーが認証を必要とするもう1つのSAML準拠サイトにアクセスすると、そのサイトは参照を使用して発行認証局からの「認証アサーション」をリクエストします。このアサーションには、ユーザーがすでに認証されていることが記述されています。

発行認証局では、アサーション・レイヤーがSAMLプロトコルを使用してリクエストおよびレスポンスのメッセージを処理します。SAMLプロトコルは、様々な通信および転送プロトコル(HTTP、SOAPなど)にバインドできます。クライアントは常にアサーションのコンシューマになりますが、発行認証局はアサーションを作成および検証できるので、プロデューサとコンシューマの役割を果すことができます。

SAMLプロトコルのバインディングとプロファイル

SAMLは、アサーション(SAMLP)をリクエストおよび取得するためのプロトコルを定義します。バインディングは、SAMLメッセージと標準的な通信プロトコルの間にマッピングを提供することで、発行認証局とリライング・パーティにおいてSAMLリクエストとレスポンス・メッセージが転送される標準的な方法を定義します。たとえば、SAMLリクエストおよびレスポンスのために定義されたHTTP経由の転送メカニズムの1つがSimple Object Access Protocol(SOAP)です。これにより、いくつかのWebサービスを横断するSAML情報の標準的な方法での交換が可能になります。

プロファイルは、SAMLアサーションが標準的なフレームワークとプロトコルにどのように組み込まれ、また抽出されるかを記述します。シングル・サインオンのためのWebブラウザ・プロファイルと、SOAPペイロードのセキュリティを確保するためのSOAPプロファイルは、利用可能なプロファイルの一例です。

1.1.4.2 フェデレーテッドIDの標準の発展

クロスドメインのシングル・サインオン・アプリケーションを迅速に開発する必要があったアクセス制御ベンダーのニーズに応えるOASIS標準化団体の取組みにより、この種の最初の標準であるSAML 1.0が2002年に生まれました。Liberty AllianceはフェデレーテッドIDのオープン標準に取り組み、SAML仕様の上に構築する形でLiberty 1標準を作成しました。同時期に、別のベンダーと企業のコンソーシアムが、Webサービス指向アプリケーションのための、進化を続ける認証および認可の標準に取り組んでいました。それ以降の取組みにより、WS-Federation標準の開発と、SAMLおよびLiberty標準の拡張と改善が並行して実現しました。これらの様々な標準について次に説明します。

1.1.4.3 SAML 1.x

SAML 1.0では、次の2つの主要な概念が定義されています。

1. アサーションとも呼ばれるセキュリティ・トークン・フォーマット。任意のIDを特定のアクセス権限に関連付けます。

2. シングル・サインオンを提供するためにそれらのアサーションをパッケージングする方法を記述したプロファイル。

SAML 1.1は、SAML 1.0にフィードバックと訂正を反映させたものです。特に、SAML 1.1にはXMLデジタル署名の変更が取り入れられており、相互運用性が大幅に向上しています。このようにXMLデジタル署名が変更されたことによって、署名検証時の問題が大幅に軽減されるため、可能なかぎりSAML 1.0のかわりにSAML 1.1プロトコルを使用することをお薦めします。

例1-1は、SAMLPレスポンス・メッセージにラップされた典型的なSAML 1.0認証アサーションを示しています。

例1-1 SAML 1.0認証アサーションを含むサンプルSAMLPレスポンス

<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="123.45.678.90.12345678"
IssueInstant="2005-12-14T10:00:23Z"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success" />
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="123.45.678.90.12345678"
Issuer="IssuingAuthority.com"
IssueInstant="2005-12-14T10:00:23Z" >
<saml:Conditions
NotBefore="2005-12-14T10:00:30Z"
NotAfter="2005-12-14T10:15:00Z" />
</saml:Conditions
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2005-12-14T10:00:20Z">
<saml:Subject>
<saml:NameIdentifier NameQualifier="RelyingParty.com">
john.smith
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>

1.1.4.4 SAML 2.0

SAML 2.0には、大部分をLiberty Alliance ID-FF仕様によって開発されたフレームワークに基づくシングル・サインオンのサポートが含まれます。

アイデンティティ・フェデレーションの概念は仕様にありませんが、SAML2.0では、特定の用途のための名前識別子の存在に注意を促しています。SAML2.0は、SAML1.xから継承した名前識別子の他に、Liberty ID - FF 1.2の機能を大幅に反映した、名前が付けられた多くのプロファイルをサポートしています。

例1-2は、SAML 2.0認証アサーションを示しています。

例1-2 SAML 2.0認証アサーション

<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0"
ID="id-V01vmFAGUOKmKVJh9-hQ-gsPhX8-"
IssueInstant="2005-10-06T21:03:17.375Z">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://issuingauthority.example.com/
</saml:Issuer>
<!-- signature by the issuer over the assertion -->
<ds:Signature>
...
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
id-V9l9N2S4nA8KlHd0X9Df3KYKm4E-
</saml:NameID>
<saml:SubjectConfirmation Method=
"urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
NotOnOrAfter="2005-10-06T21:03:32.375Z"
Recipient="http://issuingauthority.example.com/fed/sp/art20"
InResponseTo="id-G2mgYgtGH9gu8Nwo8KwxPYrpXKE-"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2006-04-27T16:40:49Z"
NotOnOrAfter="2006-04-27T17:05:49Z">
<saml:AudienceRestriction>
<saml:Audience>
http://serviceprovider.example.com:80/fed/sp
</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2005-10-06T21:01:03.451Z"
SessionIndex="1448745">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>

1.1.4.5 WS-Federation

WS-Federation仕様は「異なる信頼レルムやプロトコル間でのID、認証、認可のフェデレーションを可能にする統合モデル」です。WS-Federationは、SOAP対応アプリケーションなどのアクティブ・リクエスタの他に、Webブラウザなどのパッシブ・リクエスタのプロファイルもサポートするWebサービス指向の標準です。

注意:
現在はOracle Identity FederationでもWS-Federationのパッシブ・リクエスタをサポートしています。

1.2 Oracle Identity Federation

この項では、Oracle Identity Federationで、Oracle Identity Management製品のユーザーや、Oracle APSスタックに慣れていない顧客が、様々なユーザー認証のソースを使用して、異種環境を横断してどのようにビジネス結合に関与するかを説明します。内容は次のとおりです。

- Oracle Identity Federationの特長と利点

- アーキテクチャ

- 処理フローの概要

- フェデレーション・プロトコル・プロファイル

- アフィリエーション

- 暗号化プロバイダ

- フェデレーション・イベント・フローの例

- サポートされている標準とアプリケーション

1.2.1 Oracle Identity Federationの特長と利点

Oracle Identity Federationはスタンドアロンの自己完結型フェデレーション・サーバーで、複数ドメインのIDネットワークにおいてシングル・サインオンと認証を提供します。Oracle Identity Federationは、Liberty ID-FF、OpenID、SAMLプロトコルなど、複数のフェデレーテッドIDプロトコルをサポートしています。これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。

Oracle Identity Federationの主要な機能には、次のようなものがあります。

- アイデンティティ・プロバイダとサービス・プロバイダの両方を含む環境で、クロスサイトのアクセスと認証を実装可能

- 外部サイトの構成、有効化および無効化が可能

- シングル・サインオンを使用して宛先サイトのアプリケーションにアクセス可能

- 次に示す主要なフェデレーション・プロトコルのサポート

- SAML 1.x属性リクエスタと属性レスポンダ、認証問合せレスポンダ、アサーションIDレスポンダの機能を含むSAML 1.x

- SAML 2.0属性リクエスタと属性レスポンダ、認証問合せレスポンダ、アサーションIDレスポンダの機能を含むSAML 2.0

- WS-Federationのパッシブ・リクエスタ

- Liberty ID-FF 1.x

- OpenID 2.0

- Oracle Access ManagerおよびOracle Single Sign-Onとの統合

- プロトコルを超えたシングル・サインオンおよびサインアウトのサポート

- アフィリエーションのサポートにより、サービス・プロバイダがフェデレーション情報を共有できるため、フェデレーションの数を削減可能

- Oracle Internet Directoryとの統合、および次のサポート

- Oracle Access ManagerやLDAPなどの広範な認証エンジン

- Microsoft Active DirectoryやSun Java System Directory ServerなどのLDAPストアを含むユーザー・データ・リポジトリ

- リレーショナル・データベース

- X.509証明書検証のサポート

1.2.2 アーキテクチャ

図1-4は、Oracle Identity Federationのアーキテクチャと、他のフェデレーション・コンポーネントとOIFの関係を示しています。ここで、Oracle Identity Federation(OIFと表記)は、他のアイデンティティ・プロバイダとサービス・プロバイダ(追加のOracle Identity Federationインスタンスまたはサード・パーティのプロバイダ)とのフェデレーションを作成しています。

図1-4 Oracle Identity Federation

注意:
1つのOracle Identity Federationインスタンスは、1つのIdPおよび1つのSPとして動作することができます。図に示されているアイデンティティ・プロバイダと2つのサービス・プロバイダは、フェデレーテッド・ピア・プロバイダです。

Oracle Identity Federationには、自己完結した軽量の認証サービスが含まれます。

図1-5 Oracle Identity Federationのサード・パーティ統合

Oracle Identity Federationは、次のような広範な認証メカニズムおよびユーザー・データ・リポジトリと通信できます。

1. Oracle Identity Management
Oracle Identity Federation認証サービスは、Oracle Single Sign-OnまたはOracle Access Managerにより保護された次のようなリソースへのシングル・サインオン・アクセスを可能にするように構成できます。

- Oracle Collaboration Suite

- Oracle E-Business Suite

- PeopleSoftモジュール

- その他

サード・パーティのアクセス管理ソリューションと併用するためにOracle Single Sign-Onがデプロイされていれば、この構成では、Oracle Single Sign-On(およびOracle Internet Directoryユーザー・リポジトリ)またはOracle Access Manager(および各種のリポジトリ)の他に、サード・パーティのアクセス管理ソリューションも活用できます。

注意:
Oracle Identity FederationとOracle Single Sign-Onの両方がリソースを保護している環境では、いずれかのコンポーネントを、ユーザー・リクエストが保護リソースにアクセスした場合に認証メカニズムとして動作するように構成できます。たとえば、Oracle Identity Federationは、認証リクエストをOracle Single Sign-Onに転送できます。また、Oracle Single Sign-Onは、適切なアイデンティティ・プロバイダを見つけるようにOracle Identity Federationにリクエストできます。
同様に、Oracle Identity FederationとOracle Access Managerの両方を含む環境にも類似の機能があります。

2. データ・ストア
Oracle Identity Federationは、次のものにアクセスするように構成できます。

- LDAPディレクトリ

- RDBMSデータベース

1.2.3 処理フローの概要

Oracle Identity Federation機能を詳しく見る前に、フェデレーテッド環境でユーザー・アクセスを管理する際の大まかな処理フローを考察しておくと参考になります。

通常、ユーザーは、会社のポータルを介して複数のドメインのアプリケーションにアクセスします。たとえば、Alpha Corporationが、Alphaのユーザー・ログイン、ページのパーソナライズなどを管理するポータル・サーバーを備えているとします。そのポータル・サーバーは、アプリケーション・サーバー内で動作する自社製ロジックで構成されている場合や、市販の製品の場合があります。パートナ会社であるBeta Corporationは、MyBeta.comというタイプのポータルを使用して、その技術的なデータベース・アプリケーションを提供できます。この場合、それぞれが自社ポータル・サーバーを運用していることになります。

プロセス・フローは次のようになります。

1. ユーザーは、Oracle Access Manager、Oracle Single Sign-Onやその他の製品などのWebアクセス管理(WAM)システムによりアクセスが管理されているAlphaポータルにログインします。

2. ユーザーは、実際にはBeta Corporationがホストしているリソースをクリックしてリクエストを開始します。

3. アイデンティティ・プロバイダ(IdP)として動作しているAlphaポータルのOracle Identity Federationインスタンスが、ユーザー情報をWAMシステムに送信します。

4. WAMシステムは、ローカル・アイデンティティ・ストアのアイデンティティにユーザーをマッピングした後、セッションを作成します。

5. WAMシステムにより、成功したレスポンスとセッション・トークンがAlphaポータルのOracle Identity Federation IdPサーバーに戻されます。

6. 前述の情報を使用して、AlphaポータルのIdPはSAMLアイデンティティ・アサーションを作成し、プライベート署名キーを使用して署名します。このレスポンスは、Beta Corporationのサービス・プロバイダ(SP)として動作するOracle Identity Federationインスタンスに送信されます。

7. Beta CorporationのSPとして動作するOracle Identity Federationサーバーは、署名キーに関連付けられたIdPのパブリック証明書を使用して署名付きレスポンスを検証します。

8. Beta CorporationのOracle Identity Federationサービス・プロバイダはアサーションを抽出し、ユーザー・セッションをローカル認証システムにマッピングした後、アサーションに対するユーザー・セッションを作成します。

9. Oracle Identity Federationサービス・プロバイダは、ユーザーのブラウザにリクエストされたリソースへのリダイレクトを送信します。

10. ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。

Oracle Identity Federation処理フローの詳細は、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。

1.2.4 フェデレーション・プロトコル・プロファイル

アイデンティティ・プロバイダとサービス・プロバイダは、SAMLやWS-Federation、OpenIDなどのフェデレーション・プロトコルで定義されているプロファイルやサービスを使用してアサーションを交換します。アサーション機能には、次の機能があります。

- 保護接続の確立

- その接続を経由した認証データの運搬

- 他のドメインからのアサーションの受信と解釈

プロファイルは、IdPとSPの間でアサーションを転送するために必要な交換の種類を定義します。この項では、Oracle Identity Federationで利用できるアサーション・プロファイルを詳しく見ていきます。

- ブラウザPOSTプロファイル

- ブラウザ・アーティファクト・プロファイル

- SOAPバインディング

- ブラウザHTTPリダイレクト・プロファイル

- 名前識別子管理プロファイル

- SAML属性共有プロファイル

- WS-Federationパッシブ・リクエスタのプロファイル

- フェデレーション終了プロファイル

- グローバル・ログアウト・プロファイル

- OpenIDプロファイルおよび拡張

注意:
Liberty 1.xのサポートは非推奨です。

1.2.4.1 ブラウザPOSTプロファイル

SAMLブラウザPOSTプロファイルは、アーティファクトを使用せずに、アイデンティティ・プロバイダからサービス・プロバイダへアサーション全体を送信します。Oracle Identity FederationはHTMLフォームの非表示変数としてユーザーのブラウザにアサーションを送信し、ブラウザが宛先サイトにアサーションをポストします。

SAMLおよびWS-Federationでは、実際の通信プロトコルに従ってSAMLプロトコル・メッセージの埋込みと転送を行うためのフレームワークとしてHTTP POSTバインディングを提供しています。

1.2.4.2 ブラウザ・アーティファクト・プロファイル

一部のブラウザで、取り扱えるURL文字の数に制限があることがあります。SAMLブラウザ・アーティファクト・プロファイルは、アサーション全体を送信せず、アーティファクトと呼ばれるアサーションへの簡易参照を使用してデータを伝達することによって、これに対処します。アーティファクトの受信者は、アーティファクト解決プロトコルを使用して、アーティファクトにより参照されたアサーション全体を入手します。

SAMLでは、実際の通信プロトコルに従ってアーティファクトの埋込みと転送を行うためのフレームワークとしてHTTP Artifactバインディングを提供しています。

1.2.4.3 SOAPバインディング

バインディングとは、抽象的なメッセージ交換から、実世界のメッセージングや通信プロトコルへのマッピングです。たとえば、SAML SOAPバインディングは、SAMLプロトコル・メッセージがSOAPメッセージ内でどのように通信されるかを定義しています。

1.2.4.4 ブラウザHTTPリダイレクト・プロファイル

ブラウザHTTPリダイレクト・プロファイルは、リクエストされたリソースが異なるURLの下にあることをリクエスト元に示します。

SAMLおよびWS-Federationでは、HTTPリダイレクト・バインディングは、URL問合せ文字列パラメータのデータを、HTTPリダイレクト・レスポンスを使用して相互に送信しています。送信できるデータ量は、ブラウザにより許可される最長のURLによって制限されるため、これは通常アサーション全体でなく、より短いメッセージで使用されます。

1.2.4.5 名前識別子管理プロファイル

名前識別子プロファイルは、いずれかのプロバイダが、共通するユーザーのいずれかに割り当てられている名前識別子を更新しようとしたときに、プロバイダが相互に通信する方法を定義します。このプロファイルにより、サービス・プロバイダやアイデンティティ・プロバイダがプリンシパルの名前識別子を指定(または登録)できます。ピア・プロバイダは、プリンシパルについて他のプロバイダと通信する場合は、この名前識別子を使用する必要があります。

Oracle Identity Federationは、次のSOAP/HTTPおよびHTTPリダイレクト名前識別子プロファイルをサポートしています。

- IdPが開始するLiberty ID-FF 1.1の名前識別子登録プロファイル

- SPが開始するLiberty ID-FF 1.1の名前識別子登録プロファイル

- IdPが開始するLiberty ID-FF 1.2の名前識別子登録プロファイル

- SPが開始するLiberty ID-FF 1.2の名前識別子登録プロファイル

- IdPが開始するSAML 2.0の名前識別子更新用のNameID管理プロファイル

- SPが開始するSAML 2.0の名前識別子更新用のNameID管理プロファイル

1.2.4.6 SAML属性共有プロファイル

SAMLには、プリンシパルの属性を取得するための属性問合せ/レスポンス・プロトコルがあります。

このプロトコルがどのように使用されているかを見るには、サービス・プロバイダがメンテナンスしているWebリソースにアクセスする必要があるプリンシパルを検討します。認証は、ユーザーのフェデレーテッド資格証明を、信頼されているX.509v3証明書の形で、関連付けられている秘密鍵の所有証明とともに提示することによって行われます。この方法の一般的な例の1つは、ユーザーのブラウザとWebサーバーの間で使用される、SSL(Secure Sockets Layer)プロトコルのクライアント証明書認証機能です。

サービス・プロバイダは、一部の制限リソースの認可決定に際して、プリンシパルについての追加情報を必要とすることがあります。その情報を入手するには、SPはプリンシパルのX.509v3証明書のSubjectDNを使用して、必要な属性をアイデンティティ・プロバイダに問い合せます。IdPがこれらの属性値を返すと、SPは、その追加データに基づいて認可決定をくだすことが可能になります。プロファイルは、このようにして、不正アクセスを阻止する、強化されたリソース保護を提供します。

1.2.4.7 WS-Federationパッシブ・リクエスタのプロファイル

WS-Federationは、セキュリティ・ドメインやプロトコルを横断するID、認証および認可の統合をサポートしています。フェデレーション・サービスのクライアントに、HTTPプロトコルをサポートするWebブラウザなどのパッシブ・リクエスタが含まれている場合、WS-Federationパッシブ・リクエスタ・プロファイルがその仕様の使用方法を定義します。

1.2.4.8 フェデレーション終了プロファイル

ユーザーはフェデレーションを終了させることができます。そうするには、通常、アイデンティティ・プロバイダまたはサービス・プロバイダのWebサイト上のリンクを使用します。IdPで開始されている場合、このアクションによりSPは、それ以降IdPからSPに対してユーザーのID情報が提供されないことを通知されます。SPで開始されている場合、このアクションによりIdPは、それ以降IdPからSPに対してユーザーのID情報を提供しないようにユーザーが要求していることを通知されます。

注意:
フェデレーションの終了は、フェデレーション解除とも呼ばれます。

フェデレーション終了プロファイルは、アイデンティティ・プロバイダやサービス・プロバイダがフェデレーション終了について通知される方法を指定します。

Oracle Identity Federationは、次のフェデレーション終了プロファイルをサポートしています。

- IdPが開始するLiberty ID-FF 1.1のフェデレーション終了通知プロファイル

- SPが開始するLiberty ID-FF 1.1のフェデレーション終了通知プロファイル

- IdPが開始するLiberty ID-FF 1.2のフェデレーション終了通知プロファイル

- SPが開始するLiberty ID-FF 1.2のフェデレーション終了通知プロファイル

- IdPが開始するSAML 2.0の名前識別子削除用のNameID管理プロファイル

- SPが開始するSAML 2.0の名前識別子削除用のNameID管理プロファイル

1.2.4.9 グローバル・ログアウト・プロファイル

名前のとおり、このプロファイルはグローバル・ログアウトのサポートを提供します。アイデンティティ・プロバイダは、IdPが提供するアサーションに基づいて、任意のユーザーがログインしているすべてのサービス・プロバイダのリストをメンテナンスしています。ユーザーがログアウトしようとすると、IdPは各SPに対してログアウト・リクエストを送信して、そのIdPに関してグローバル・ログアウトを実行します。

ログアウト処理の手順は次のとおりです。

1. ユーザーまたはピア・プロバイダがログアウト・リクエストを開始します。
Oracle Identity FederationのIdPが、ユーザーがログインしているサービス・プロバイダやアイデンティティ・プロバイダにログアウト・リクエストを送信します。送信するメッセージの種類はシングル・サインオンのタイプにより異なります。

2. Oracle Identity Federationは、メッセージが送信されたプロバイダからログアウト・レスポンスを受け取ります。

3. Oracle Identity Federationが次のログアウト・リクエスト(手順1)を送信します。

4. ユーザーがすべてのプロバイダからログアウトすると、Oracle Identity Federationがユーザーをサーバーからログアウトさせます。

5. WS-Federationログアウトの場合、Oracle Identity Federationはユーザーに対して正常ログアウトのページを表示します。SAML 2.0のログアウト・プロファイルは、元のログアウト・リクエストを送信したピア・プロバイダにユーザーを送り返します。

Oracle Identity Federationは次のプロトコルのSOAP/HTTPおよびHTTPリダイレクト・グローバル・ログアウト・プロファイルをサポートしています。

- IdPが開始するSAML 2.0のシングル・ログアウト・プロファイル

- SPが開始するSAML 2.0のシングル・ログアウト・プロファイル

- WS-Federationのパッシブ・リクエスタ・ログアウト・プロファイル

- IdPが開始するLiberty ID-FF 1.1のシングル・ログアウト・プロファイル

- SPが開始するLiberty ID-FF 1.1のシングル・ログアウト・プロファイル

- IdPが開始するLiberty ID-FF 1.2のシングル・ログアウト・プロファイル

- SPが開始するLiberty ID-FF 1.2のシングル・ログアウト・プロファイル

1.2.4.10 OpenIDプロファイルおよび拡張

Oracle Identity Federationは、次のOpenID拡張仕様とプロファイル仕様をサポートしています。

- Attribute Exchange(AX)
AXはOpenID 2.0の拡張で、ユーザー属性をリクエストしたり、返したりすることができます。

- Provider Authentication Policy Extension (PAPE)
PAPEはOpenID 2.0の拡張で、保証レベルなど、特定の認証タイプや強度をRPがリクエストできるようにします。

- 米国政府Federal Identity, Credentialing and Access Management (ICAM)プロファイル
このプロファイルは、OpenID 2.0の導入に対して米国政府が示したポリシー要件とセキュリティ要件をサポートしています。次のものが含まれます。

- 非個人識別情報

- Private Personal Identifier

- OpenIDのGSAプロファイル

- NIST認証レベル

詳細は、第2.2項「プロファイルとバインディング」のOpenIDに関するトピックを参照してください。

1.2.5 アフィリエーション

SAML 2.0またはLiberty 1.2のアフィリエーションは、論理グループに参加しているサービス・プロバイダで構成されます。

注意:
Liberty 1.xのサポートは非推奨です。

アフィリエーションは具体的なエンティティやサーバーではなく、論理上のプロバイダです。このため、アフィリエーションとして動作できるサーバーはありません。そのかわり、プロトコル・メッセージの交換を実行する際にサービス・プロバイダによってアフィリエーションIDが使用されます。この場合、メッセージはアフィリエーションの論理エンティティから送信されるように見えますが、メッセージの実際の送信者は具体的なサービス・プロバイダです。このようにして、アフィリエーションはアフィリエーション内のすべてのサービス・プロバイダの別名として機能し、それぞれのサービス・プロバイダはアフィリエーション・エンティティに関連付いたフェデレーション情報を使用できます。

1.2.6 暗号化プロバイダ

Oracle Identity Federationは、署名処理や暗号化処理を実行する必要がある場合には、Java Cryptographic Extensionを使用します。

署名鍵および暗号鍵は、PKCS#12ウォレットまたはJavaキーストアとしてOracle Identity Federationに提供する必要があります。

注意:
署名鍵と暗号化鍵を提供する、特定のJCE Providerを使用するようにOracle Identity Federationを構成できます。

1.2.7 フェデレーション・イベント・フローの例

この項では、フェデレーテッド・インタラクションにおける通常のメッセージ・フローについて説明します。

図1-1のユースケースを細かく見てみましょう。Maryがmycorp.comで認証済であり、未ログインのtravelclub.comに移動する場合を考えます。travelclub.comはMaryに対して認証を受けることを要求し、travelclub.comのシングル・サインオンをリクエストしているmycorp.comに、SAML 2.0メッセージを付けてMaryをリダイレクトします。そうしないとMaryは自分のローカル・アカウントにアクセスできません。Maryはアイデンティティ・プロバイダにログイン済であるため、mycorp.comはMaryのアカウントとフェデレーション・データを取得し、travelclub.comに彼女をリダイレクトしなおします。プロバイダ識別子mycorp.comと、リダイレクトで提供されたユーザー識別子xyz123を使用すると、travelclub.comはMaryのフェデレーション・データとローカル・アカウントを一意に取得できます。

1.2.8 サポートされている標準とアプリケーション

Oracle Identity Federationによってサポートされているプラットフォームと製品バージョンの詳細は、次の該当する認定マトリックスを参照してください。

1. https://metalink.oracle.comにアクセスして、My Oracle Supportにログインします。

2. 「Certify」タブをクリックします。

3. 「View Certifications by Product」をクリックします。

4. 「Application Server」オプションを選択し、「Submit」をクリックします。

5. 「Oracle Identity Management」オプションを選択し、「Submit」をクリックします。

6. 「General Oracle Identity Management Certification Information」で、「Oracle Identity Federation Certification」をクリックします。

2 Oracle Identity Federationデプロイメントの計画

この章では、インストール・オプションをよく理解できるように、Oracle Identity Federationのデプロイメントに関する考慮事項を説明します。これらの項目が含まれます。

- アーキテクチャ・オプション

- プロファイルとバインディング

- 認証エンジン

- データ・リポジトリ

- インストール要件

- サイジングのガイドライン

- 実装チェックリスト

2.1 アーキテクチャ・オプション

Oracle Identity Federationのデプロイメントを計画する場合、サーバー・アーキテクチャ、運用環境、およびフェデレーテッド交換ネットワークでサーバーが持つロールについて把握する必要があります。この項では、Oracle Identity Federationのデプロイメントにおけるアーキテクチャについて、次のような事項を概説します。

- フェデレーションでのロール

- プロキシ・サーバー

- サーバー・セキュリティ

- プロトコル

2.1.1 フェデレーションでのロール

前述したとおり、フェデレーテッド・ネットワークでのOracle Identity Federationのインスタンスは、アイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)のいずれか、または両方として動作できます。

アイデンティティ・プロバイダ・ロール

ユーザーがフェデレーテッド・ネットワーク内の保護されたリソースにアクセスすると、そのリソース用のサービス・プロバイダによって、ユーザーは認証用のアイデンティティ・プロバイダとして動作するOracle Identity Federationに誘導されます。Oracle Identity Federationは認証エンジンを使用して資格証明を取得し、ユーザーを認証します。これでOracle Identity FederationがユーザーのIDをリソース(SP)に対して宣言することができるようになり、リソースではユーザーの認証が実施され、要求されたアプリケーションが提供されます。

サービス・プロバイダ・ロール

ユーザーがOracle Single Sign-Onなどの認証エンジンで保護されたリソースにアクセスすると、ユーザーはOracle Identity Federationにリダイレクトされます。サービス・プロバイダ・ロールでは、Oracle Identity Federationは、グローバル認証用ポータルなどのアイデンティティ・プロバイダにユーザーをリダイレクトします。これによってIdPポータルは資格証明を取得し、ユーザーを認証して、Oracle Identity Federationにリダイレクトを返します。このOracle Identity FederationはIdPからアサートされたIDを取得します。Oracle Identity Federationは(認証された)ユーザーを認証エンジンにリダイレクトし、その認証エンジンが保護されたリソースへのアクセス権を付与します。

フェデレーション・トポロジ

フェデレーションは任意の数のアイデンティティ・プロバイダとサービス・プロバイダで構成できます。一般的なフェデレーション・トポロジの一つに、ハブ・アンド・スポーク・モデルと呼ばれるものがあります。このトポロジでは、1つのサービス・プロバイダが複数のアイデンティティ・プロバイダから認証を受け入れるか、1つのアイデンティティ・プロバイダが複数のサービス・プロバイダに対して認証を実施します。

図2-1 ハブ・アンド・スポーク・フェデレーション・ネットワーク

2.1.2 プロキシ・サーバー

DMZにどのコンポーネントを置くか、プロキシ・サーバーを使用するかどうかを決定する必要があります。Oracle Identity Federationをファイアウォールの背後に置いた場合、プロキシがリクエストとレスポンスをフェデレーション・サーバーに転送することによって、インターネットなどの外部ネットワークからサーバーへの透過的なアクセスを可能にする必要があります。

Oracle Identity Federationの構成は、実装するプロファイルの種類により異なります。

関連項目:
Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。

SPのDMZに置いたプロキシを使用するPOSTプロファイル

POSTプロファイルはHTTPS経由でSPにアサーション全体を送信します。IdPとSPはどちらも、SSLポートを経由して通信するように構成されています。本番環境でPOSTプロファイルを使用する場合、SPはDMZにあるプロキシ・サーバーを使用します。

IdPおよびSPのDMZに置いたプロキシを使用するアーティファクト・プロファイル

ブラウザ・アーティファクト・プロファイルを使用する場合、IdPは実際のアサーションでなく、アーティファクト(識別子)を送信します。SPはアーティファクトを受信し、その後でアサーション全体をリクエストします。

プロキシの使用を選択する場合は、このプロファイルを使用するためにはIdPとSPの両方のプロキシを使用する必要があることに注意してください。プロキシは、アーティファクト、アサーション・リクエストおよびアサーションを処理し、それらのオブジェクトをそれぞれのプロバイダに転送する、受信者およびレスポンダ・サービスとして機能します。

2.1.3 サーバー・セキュリティ

Oracle Identity Federationは、次を使用することによってセキュアな通信を提供します。

- SSL暗号化

- 証明書ベースの認証

- 証明書リポジトリおよび検証

2.1.3.1 SSL暗号化

Oracle Identity Federationは、パートナ・ドメイン相互の間にセキュアなSSL通信を提供します。SSL暗号化は、インストール時にサーバー・インスタンスごとに有効または無効にできるオプションです。

注意:
SSLの構成については、第8.1.1.1項「Oracle WebLogic ServerでのSSLの設定」を参照してください。

2.1.3.2 証明書ベースの認証

初回の設定とテストでは、アイデンティティ・プロバイダおよびサービス・プロバイダはデフォルトの自己署名証明書を使用できます。しかし、本番に移行する前に、インストールされたプロバイダがサード・パーティのCA証明書を使用するように設定されていることを確認する場合があります。

2.1.3.3 証明書リポジトリおよび検証

Oracle Identity Federationには、信頼できるCAのリストと証明書失効リスト(CRL)を格納できるリポジトリがあります。

サーバーで証明書が有効になっている場合は、Oracle Identity Federationにより、SAMLおよびWS-Federationの各プロトコルで、着信するシグネチャを検証するために使用されているすべての証明書が検証されます。

証明書を検証する際、サーバーは証明書または信頼できる証明書とみなせるその発行者を見つけようと試み、証明書がCRLにないことを確認します。

関連項目:

- 証明書検証の有効化の詳細は、第5.10.2項「セキュリティおよび信頼 - プロバイダ・メタデータ」を参照してください。

- 証明書リポジトリの詳細は、第5.10.1項「セキュリティおよび信頼 - ウォレット」を参照してください。

2.1.4 プロトコル

Oracle Identity Federationをインストールする場合、サーバーがサポートするフェデレーション・プロトコルを決定する必要があります。Oracle Identity Federationでは、次のプロトコルを使用できます。

- SAML 1.0

- SAML 1.1

- SAML 2.0

- WS-Federation

- OpenID

Oracleアイデンティティ・フェデレーション管理者は、サーバーで使用するフェデレーション・プロトコルを決定する必要があります。

詳細は、第1.1.4項「フェデレーション・プロトコル」を参照してください。

2.2 プロトコルとバインディング

この項では、プロファイルとバインディングを説明します。内容は次のとおりです。

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

- プロファイルの選択

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

フェデレーション・サーバーのインスタンスがサポートするプロトコルを選択したら、実装するプロトコル・プロファイル、セキュリティ転送バインディングおよびその他の機能を選択する必要があります。この項では、Oracle Identity Federationでサポートされているプロトコルについて概説します。

2.2.1.1 SAML 2.0プロトコル

表2-1は、Oracle Identity Federationでサポートされている、SAML 2.0プロトコル・プロファイルとセキュリティ転送バインディングの組合せを示しています。

表2-1 SAML 2.0の場合のOracle Identity Federationのプロファイルおよびバインディング

機能

プロファイル/
バインディング

SAML 2.0

シングル・サインオン

アーティファクト

x

シングル・サインオン

HTTP Post

x

Logout

HTTPリダイレクト

x

Logout

HTTP Post

x

NameID登録

HTTPリダイレクト

x

NameID登録

HTTP Post

x

NameID登録

SOAP

x

フェデレーション終了

HTTPリダイレクト

x

フェデレーション終了

HTTP Post

x

フェデレーション終了

SOAP

x

属性取得

SOAP

x

2.2.1.2 SAML 1.xおよびWS-Federationプロトコル

表2-2は、Oracle Identity Federationでサポートされている、SAML 1.xおよびWS-Federation (WS-Fed)のプロトコル・プロファイルとセキュリティ転送バインディングの組合せを示しています。

表2-2 SAML 1.xとWS-Federationの場合のOracle Identity Federationのプロファイルおよびバインディング

機能

プロファイル/
バインディング

SAML 1.0/1.1

WS-Federation

シングル・サインオン

アーティファクト

x

シングル・サインオン

HTTP Post

x

x

Logout

HTTPリダイレクト

x

2.2.1.3 OpenID 2.0プロトコル

Oracle Identity Federationは、OpenIDバージョン2.0をサポートしています。

認証

Oracle Identity Federationは、基本的なOpenID認証リクエスト機能をサポートしています。

アソシエーション

Oracle Identity Federationは、次に示すような、メッセージの署名および検証にHMAC共有秘密鍵を使用するプロバイダ・フェデレーションをサポートしています。

- HMAC-SHA1

- HMAC-SHA256

Oracle Identity Federationは、次のセッション・アソシエーション・タイプをサポートしています。

- 暗号化なし

- Diffie-Hellman SHA1

- Diffie-Hellman SHA256

検出

Oracle Identity Federationは、次をサポートしています。

- OpenIDプロバイダ(OP)およびリライイング・パーティ(RP)に対するメタデータの公開

- RPによるOPのXRDS検出

RPエンドポイント検証を実装することにより、RPになりすましてOpenIDアサーションを取得するURLリダイレクタを防ぎます。OPによるRPエンドポイント検証は、次のように実装されます。

- RPのXRDS検出。レルムURLでホストされるXRDS文書にエンドポイントが記述されているかどうかを確認します。

- OpenIDの仕様に記載されているように、レルムを使用した検証。レルムにはURIまたは一致するドメイン(*.foo.comなど)のいずれかを指定できます。検証では、サーバーがレルムからドメインを抽出し、RPエンドポイントへの照合を試みます。検証に使用する有効なドメインには、少なくとも2つの要素が含まれている必要があります(.foo.comは許容されますが、.comは許容されません)。また、サーバーは破棄すべきドメインの指定方法も提供します(*.co.ukなど)。

アカウント・リンク

Oracle Identity Federationは、OpenID主張識別子とローカル・ユーザー・アカウントの間の永続的なアカウント・リンクをサポートするために、フェデレーション・データ・ストアを使用します。

アサーション

Oracle Identity Federationは、SP側でのアサーションからユーザーへのレコード・マッピングをサポートしています。

偽名

Oracle Identity Federationは、不透明で永続的な名前識別子をOpenIDアサーションで使用します。つまり、次のことを意味します。

- フェデレーション・データ・ストアは、IdP側に必要です。

- フェデレーション・データ・ストアは、SP側ではオプションです。SPがアサーションをユーザーにマップする際にフェデレーテッドIDを使用するように構成されている場合は、フェデレーション・データ・ストアが必要です。

プロファイルおよび拡張

表2-3は、Oracle Identity Federationでサポートされている、プロトコル・プロファイルと拡張を示しています。

表2-3 OpenID 2.0の場合のOracle Identity Federationのプロファイルおよび拡張

プロファイル/拡張

注意

Attribute Exchange(AX)拡張

v. 1.0がサポートされています。

Provider Authentication Policy Extension (PAPE)

v. 1.0がサポートされています。

ICAMプロファイル

非個人識別情報、Private Personal Identifier、OpenIDのGSAプロファイルおよびNIST認証レベルのサポート

2.2.2 プロファイルの選択

この項では、選択したプロトコルに実装するプロファイルを選択する際に留意すべき考慮事項を説明します。

- SAMLプロトコルでは、プロバイダがアーティファクト・プロファイルまたはPOSTプロファイルを使用してOracle Identity Federationアサーションを交換するかどうかを指定できます。これらのプロファイルは、アサーションを安全に交換するための方法の違いを表しています。

- OpenIDプロトコルでは、ICAMプロファイル、AX拡張またはPAPE拡張を選択できます。

この項では、次の内容を説明します。

- アーティファクト・プロファイルの使用

- POSTプロファイルの使用

- SAMLでのセキュリティに関する考慮事項

- SAML属性共有プロファイルの使用

- WS-Federationログアウト・プロファイルの使用

- OpenIDプロファイルおよび拡張の使用

2.2.2.1 アーティファクト・プロファイルの使用

アーティファクト・プロファイルを考慮する場合には次のことを検討してください。

- アーティファクト・プロファイルは、XML署名を使用するPOSTプロファイルほどリソース集約的ではありません。

- アイデンティティ・プロバイダのSAMLコンポーネントはDMZに置く必要があります。

アーティファクト・プロファイルのリクエスト処理

図2-2は、アーティファクト・プロファイルでリクエストが処理されるプロセスを示しています。

図2-2 アーティファクト・プロファイル処理フロー

処理フローは次のような道筋をたどります。

1. ユーザーがOracle Identity Federation(IdPとして動作)でリクエストを実行します。

2. Oracle Identity Federationがユーザーを認証し、SPに認識されているIdPの識別子を含むアーティファクトを作成します。
送信されるメッセージは、検索用のキーとなるアーティファクトとともに、サーバーのリポジトリに格納されます。

注意:
インストールにより異なりますが、リポジトリはメモリーとリレーショナル・データベースのどちらにも置けます。レプリケートされた高可用性Oracle Identity Federationサーバーを使用する場合、リポジトリはデータベースにある必要があります。

3. サーバーはユーザーを、そのアーティファクトを持つピア・サイトにリダイレクトします。アーティファクト・プロファイルは、メッセージを運ぶために使用されます。

4. ピア・サイトはアーティファクトをデコードし、Oracle Identity Federationが元のサイトであることを導き出します。

5. ピア・サイトはIdPのOracle Identity Federationと連絡を取り、アーティファクトを送信して、サーバーにそれを間接参照するように求めます。

6. Oracle Identity Federationは、アーティファクトを使用してリポジトリからメッセージを取得します。

7. Oracle Identity Federationが処理のためにピア・サイトにメッセージを送信します。

注意:
この使用例は、IdPが開始したシングル・サインオンを解説したものです。リクエストがSPによって開始された場合は、ユーザーはサービス・プロバイダで直接リソースをリクエストします。

ユーザー・エントリやユーザー・フェデレーション・レコードと比べると、アーティファクト・オブジェクトは一時的なデータとみなすことができます。この一時的な性質のため、アーティファクトは持続時間が限定されており、一定の時間が経過するとリポジトリから削除されます。

プロキシを使用するアーティファクト・プロファイル

図2-3に示したように、アーティファクト・プロファイルを使用する場合、Oracle Identity Federationに、IdPサーバーやSPサーバーのプロキシを構成することができます。このセキュア環境で、プロキシはDMZにあります。

関連項目:
Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。

図2-3 プロキシを使用したアーティファクト・プロファイル処理

プロセス・フローは次のようになります。

1. ユーザーがOracle Identity Federation IdPサーバーでリクエストを発行します。

2. Oracle Identity Federationがユーザーを認証し、IdPサーバーの短い識別子を含むアーティファクトを作成します。サーバーは、アーティファクトを持つユーザーを、SPプロキシ・サーバー上の受信者サービスにリダイレクトします。

3. ユーザーのブラウザが、SPのDMZにあるプロキシ上のサービス・プロバイダの受信者サービスのURLに、アーティファクトを含んでいるリクエストを送信します。

4. プロキシはリクエストをOracle Identity Federation SPサーバーに転送します。

5. SPはIdPのDMZにあるプロキシ上のIdPのレスポンダ・サービスと連絡を取り、アーティファクトを送信して、IdPにそれを間接参照するように求めます。

6. プロキシはリクエストをIdPに転送します。

7. IdPはアーティファクトを使用してリポジトリからメッセージを取得し、SPに送信します。

8. SPサーバーはユーザー・セッションを作成し、ユーザーのブラウザを目的のリソースにリダイレクトします。

テスト目的で、開いているポートを経由して通信するようにピア・プロバイダを構成することができます。ただし、本番環境ではセキュアなSSLポートをお薦めします。また、IdPとSPの管理者は、各自のCA証明書を互いに交換してインストールしている必要があります。この証明書は、それぞれのフェデレーション・サーバーの間で交換されるリクエストとレスポンスを暗号化および復号化するために使用されます。

2.2.2.2 POSTプロファイルの使用

SAML POSTプロファイルを使用して、アイデンティティ・プロバイダはHTTPS経由でサービス・プロバイダにアサーション全体を送信します。テスト時に、プロキシを使用しないようにOracle Identity Federationを構成する場合があります。

注意:
アサーションはHTTP経由でも送信できます。ただし、通信のセキュリティを確保するために、本番環境では常にHTTPSを使用することをお薦めします。

POSTプロファイルを考慮する場合には次のことを検討してください。

- POSTプロファイルでは、IdPのSAMLコンポーネントをDMZに置く必要はありません。

- SAMLコンポーネントはファイアウォールの背後に置くことができます。

- POSTプロファイルにはXML署名の使用が必要です。また、署名と検証には大量のリソースが必要です。

- 多数のリクエストやレスポンスを送受信する計画がある場合のパフォーマンス上のヒントは、第2.6項「サイジングのガイドライン」を参照してください。

POSTプロファイルのリクエスト処理

図2-4は、POSTプロファイルの下でリクエストが処理されるプロセスを示します。

図2-4 POSTプロファイルの処理

プロセス・フローは次のようになります。

1. ユーザーがリクエストを開始します。認証されるまでリクエストを処理できません。

2. Oracle Identity Federationはアイデンティティ・プロバイダとして動作し、ユーザーを認証して、レスポンスを含むHTMLフォームを返します。このフォームは、IDアサーションと、サービス・プロバイダのURLで構成されます。レスポンスは、Oracle Identity FederationのIdPの秘密署名キーを使用して署名されます。

3. ブラウザは、このフォームをサービス・プロバイダの受信者サービスのURLにpostします。受信者サービスは、IdPの署名キーに関連付けられた公開証明書を使用して、署名されたレスポンスを検証します。

4. サービス・プロバイダはアサーションを抽出し、アサーションのためにユーザー・セッションを作成します。

5. サービス・プロバイダは、ユーザーのブラウザに、リクエストされたリソースへのリダイレクトを送信します。

6. ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。

プロキシを使用するPOSTプロファイル

セキュアなデプロイメントでは、POSTプロファイルはSSL経由でサービス・プロバイダにアサーション全体を送信します。IdPとSPは、SSLポートを通るHTTPS経由で通信するように構成されます。図2-5は、本番でPOSTプロファイルを使用するための望ましい手法を示しています。Oracle Identity Federationは、DMZにあるSPとして動作しています。

図2-5 プロキシを使用するPOSTプロファイル

関連項目:
Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。

プロセス・フローは次のようになります。

1. Oracle Identity FederationがIdPとして動作している状態で、ユーザーがリソースをリクエストします。SPであるOracle Identity Federationサーバーは、DMZにあるプロキシ・サーバー経由でアクセスされます。

2. IdPサーバーはユーザーを認証して、レスポンスとしてアサーションとターゲット・リソースのURLが含まれるHTMLフォームを送信します。
レスポンスは、Oracle Identity FederationのIdPの秘密署名キーを使用して署名されます。

3. ユーザーのブラウザは、SPのプロキシ受信者サービスURLにフォームをpostします。

4. プロキシはフォームをSPの受信者サービスに転送します。

5. Oracle Identity Federation SPは署名を検証してアサーションを抽出し、アサーションのためにユーザー・セッションを作成して、ユーザーのブラウザにリソースへのリダイレクトを送信します。

6. ブラウザは新規ユーザー・セッションを経由して、ターゲット・リソースにリクエストを送信します。リクエストはサービス・プロバイダのDMZにある追加のプロキシによって処理されることがあります。

2.2.2.3 SAMLでのセキュリティに関する考慮事項

SAMLは、SAMLメッセージとメッセージ交換のプライバシ、整合性、正統性および秘匿性を確保するために使用できる多数のセキュリティ機能があります。

この項では、メッセージのセキュリティに関する考慮事項の簡単な概要を説明します。セキュリティに関するリスクと対策の詳細な分析は、次の場所にある、「Security and Privacy Considerations for OASIS SAML V2.0」というタイトルの、OASIS SAMLセキュリティ関連考慮事項の仕様書を参照してください。

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

Oracle Identity Federationは、SAMLデプロイメントで使用できる一連のセキュリティ関連のテクノロジとテクニックをサポートしています。これには、次の内容が含まれます。

- ピア認証とセキュアな通信のためのSSL/TLS

- メッセージ・レベルの整合性と認証のためのXML-SIG

- SHA-1を使用した署名生成

- SHA-1またはSHA-256を使用した署名検証

- メッセージ・レベル機密保護のためのXML-ENC

メッセージ・レベルのセキュリティに加え、すべてのSAMLメッセージ・フローで、セキュアなSSL/TLSチャネルを使用することをお薦めします。アイデンティティ・プロバイダとサービス・プロバイダの間の通信はすべて、双方向認証(クライアント証明書とサーバー証明書)を使用する必要があります。

SAMLプロファイルは、通信プロトコルでSAMLアサーションとリクエスト/レスポンス・メッセージをセキュアに使用する方法に関する、具体的な推奨事項です。ここでは、SAML SSOのアーティファクト・プロファイルとPOSTプロファイルのセキュリティ要件を示します。

SAMLアーティファクト・プロファイルを使用するセキュアな通信

SAMLアーティファクト・プロファイルを使用するセキュアな通信には、次のことが必要です。

1. IdPからユーザーのブラウザへのリダイレクション、およびブラウザからSPへのリダイレクションにはSSLが必須です。

2. IdPおよびSPで直接通信を行うために使用されるSOAPチャネルは、SSLまたはHTTP Basic認証のいずれかを使用して保護する必要があります。

注意:
SPは、IdPに認識されているユーザー名とパスワードを使用したHTTP Basic認証を使用することもできます。

SAML POSTプロファイルを使用するセキュアな通信

SAML POSTプロファイルを使用するセキュアな通信には、次のことが必要です。

1. ブラウザからサービス・プロバイダへのユーザー・リクエストの転送にはセキュアHTTP(HTTPS)が必要です。

2. アイデンティティ・プロバイダは、サービス・プロバイダに送信するレスポンスに署名する際にはXML署名を使用する必要があります。

3. サービス・プロバイダはレスポンスのXML署名を検証する必要があります。

2.2.2.4 SAML属性共有プロファイルの使用

SAML属性共有プロファイルは、リソース・リクエストの認可を提供するために追加のユーザー属性が必要であるときに、サービス・プロバイダが、SAMLアサーションでなくSSLクライアントX.509証明書を使用してユーザーを認証するために使用されます。

Oracle Identity Federationは、Oracle Access Managerとともに使用してピア・サイトでのSAML実装との相互運用を可能にするために、属性共有プロファイルを提供しています。コンポーネントとそのロールの詳細、およびOracle Identity FederationとOracle Access Managerの構成方法の詳細は、第5.6.4.3項「属性共有を使用するOracle Access Managerポリシーの構成」を参照してください。

2.2.2.5 WS-Federationログアウト・プロファイルの使用

WS-Federationは、実際の認証を実行するアイデンティティ・プロバイダを使用して1つ以上のサービス・プロバイダにサインインするために使用できます。

ログアウトするには、WS-Federationサインアウトを開始するIdPサイトでリンクをクリックします。Oracle Identity Federationは、セッションCookieを使用して、ユーザーがサインインした各SPを追跡しています。サーバーはユーザーのブラウザにHTMLサインアウト・ページを返します。各SPはサインアウト・クリーンアップを処理し、Oracle Identity Federationのために作成されたセッションをサインアウトします。

2.2.2.6 OpenIDプロファイルおよび拡張の使用

この項では、OpenIDの様々なプロファイルと拡張に対するOracle Identity Federationのサポートについて説明します。

Attribute Exchange(AX)

AXはOpenID 2.0の拡張で、ユーザー属性をリクエストしたり、返したりすることができます。OIFは、AXバージョン1.0をサポートしています。

IdPにおけるサポートは次のとおりです。

- IdPでのプロファイルのサポートが有効になります。ただし、各SPに対しては有効になりません。属性を送信するかどうかを指定する必要があります。

- 属性の定義は、SPパートナ固有のページにある既存の画面によって行われます。

SPにおけるサポートは次のとおりです。

- 属性の定義は、IdPパートナ固有のページにある既存の画面によって行われます。

- 属性定義のページで、SSOプロトコルの実行時にIdPからリクエストする属性を指定できます。

- カスタムSPエンジンまたは前処理エンジンは、SSOプロトコルの実行時にIdPからリクエストする必要のある属性を実行時に指定できます。

Provider Authentication Policy Extension (PAPE)

PAPEはOpenID 2.0の拡張で、保証レベルなど、特定の認証タイプや強度をRPがリクエストできるようにします。Oracle Identity Federationは、PAPEバージョン1.0をサポートしています。

IdPおよびOPにおけるサポートは次のとおりです。

- IdPは、PAPE拡張が有効かどうかをXRDS文書で公開します。

- 有効な場合、IdPはユーザーの認証に使用される認証メカニズムをSPへのレスポンスに組み込みます。

SP/RPにおけるサポートは次のとおりです。

- IdPがPAPEをサポートし、特定の認証メカニズムをリクエストするように構成されている場合、IdPでのユーザー認証に使用するメカニズムはSPが指定します。

注意:
Oracle Identity Federationの認証メカニズムはOpenIDの認証方式に変換されます。

米国政府Federal Identity, Credentialing and Access Management (ICAM)プロファイル

Oracle Identity Federationは、OpenID 2.0の導入に対して米国政府が示した、次のプライバシ・ポリシー要件とセキュリティ要件をサポートしています。

- ICAM OpenID 2.0 Profile URIによって参照される非個人識別情報。有効かつプロトコル交換で指定されている場合は、IdPはSPへのレスポンスに個人情報を組み込むことができません。

- OASIS Private Personal Identifier URIによって参照されるPrivate Personal Identifier。有効かつプロトコル交換で指定されている場合は、IdPはRPに固有の不透明なClaimedIDを返す必要があります。

- ICAM OpenID 2.0プロファイルURIによって参照されるOpenIDのGSAプロファイル。有効かつプロトコル交換で指定されている場合は、IdPはOpenID SSOプロトコルの実行時にGSAプロファイルのルールに従う必要があります。

- NIST認証レベル(参照URI: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pd)。有効な場合、IdPはNISTの保証レベル情報をSPへのレスポンスに組み込みます。

注意:
これらのプロファイルは、Oracle Identity Federationで有効にできますが、フェデレーション・サーバーが要件に準拠していることを確認する必要があります。

OpenIDプロファイルのリクエスト処理

図2-6は、OpenIDプロファイルでのリクエスト処理を示しています。

図2-6 OpenIDの処理フロー

2.3 認証エンジン

Oracle Identity Federationの機能の多くは、ユーザーが認証されていることを必要とします。このような操作には、次のものがあります。

- シングル・サインオン、フェデレーション作成、フェデレーション終了およびNameID登録などのIdPプロトコル操作

- フェデレーション作成、フェデレーション終了およびNameID登録などのSPプロトコル操作

認証の効力について見通しを得るために、フェデレーション・サーバーを、次のような別個のモジュールを含むものとして考えることができます。

1. Oracle Identity FederationがWS-Federation、Liberty 1.x、SAML 1.0/1.1、SAML 2.0およびOpenIDプロトコルをサポートします。

2. 認証モジュールが、ユーザー認証およびIdMソリューションとの統合をサポートします。

これらの操作をサポートするために、Oracle Access Managerは、Webシングル・サインオン、ユーザーのセルフサービスと登録、ポリシー管理および委任管理など、広汎なID管理機能を提供します。

この項では、様々な構成のこれらのモジュールにより可能になる認証フローを検討します。

- Oracle Identity Federationのエンジン

- リポジトリを使用した認証

- IdPモードでのIdMソリューションを使用する認証

- SPモードでのOracle Access Managerへの認証状態の伝播

- SPモードでのOracle Single Sign-Onへの認証状態の伝播

- HTTP Basic認証

2.3.1 Oracle Identity Federationのエンジン

Oracle Identity Federationは、ユーザー・フェデレーション操作を実行するときには次の2つのモジュールと相互作用します。

- 認証エンジンはローカル認証メカニズムとして動作します。このモードでは、認証モジュールは使用可能な認証システムを使用してローカルに認証することができます。
Oracle Identity Federationは、認証モジュールに認証リクエストを伝えます。デプロイメントにより異なりますが、認証モジュールは、直接RDBMSまたはLDAPリポジトリと情報をやり取りすることも、Oracle Single Sign-OnなどのIdMソリューションに認証を委任することもあります。

- Oracle Identity Federation SP統合エンジンは認証状態を伝播させるために動作します。このモードでは、サービス・プロバイダであるOracle Identity Federationが、フェデレーション・プロトコルを使用して、ユーザーがピア・アイデンティティ・プロバイダで認証されるようにします。Oracle Identity Federationは、ユーザーを認証モジュールに転送します。このモジュールは、SPにデプロイされたIdMソリューションに認証済のユーザー・セッションを伝播し作成します。これにより、リクエストされた保護リソースへのアクセスが順に可能になります。

2.3.2 リポジトリを使用した認証

このデプロイメントでは、認証モジュールが次のような様々なリポジトリやIdMソリューションと情報を直接やり取りして、Oracle Identity Federationがユーザーをローカルに認証できるようにします。

- RDBMSリポジトリ

- LDAPリポジトリ

図2-7 IdPモードでのリポジトリを使用した認証

このようなデプロイメントに関わるローカル認証のフローは次のとおりです。

- ユーザーがOracle Identity Federationにアクセスします(手順1)。

- ローカル認証の場合、Oracle Identity Federationがユーザーを認証モジュールに転送します(手順3)。

- 次の場合、ユーザーが資格証明を入力します(手順5)。

- 認証モジュールが資格証明の入力をユーザーに求めます(手順6)。

- 認証モジュールは、ユーザーを認証するためにリポジトリと情報をやり取りします(手順7)。

- 認証モジュールは、ユーザーをユーザーのIDとともにOracle Identity Federationに転送します(手順6、1)。

- Oracle Identity Federationが認証されたユーザーと通信します(手順2)。

2.3.3 IdPモードでのIdMソリューションを使用する認証

このデプロイメントでは、認証モジュールがOracle Single Sign-On IdMソリューションまたはOracle Access Managerに認証を委任して、Oracle Identity FederationがIdPモードで認証できるようにします。

図2-8 IdPモードでのIdMソリューションを使用した認証

IdMデプロイメントに関わるローカル認証のフローは次のとおりです。

- ユーザーがOracle Identity Federationにアクセスします(手順1)。

- ローカル認証の場合、Oracle Identity Federationがユーザーを認証モジュールに転送します(手順2)。

- 認証のために、認証モジュールがユーザーをIdMサーバーにリダイレクトします(手順3、4)。

- IdMサーバーはユーザーを認証し、ユーザーを認証モジュールにリダイレクトして戻します(手順5、6)。

- 認証モジュールは、ユーザーをユーザーのIDとともにOracle Identity Federationに転送します(手順7)。

- Oracle Identity Federationが認証されたユーザーと通信します(手順8)。

2.3.4 SPモードでのOracle Access Managerへの認証状態の伝播

このモードで、Oracle Identity Federationはフェデレーション・プロトコルを使用してユーザーを識別し、Oracle Access Manager上に認証済セッションを作成するように認証モジュールにリクエストします。これによりユーザーはリクエストされたリソースにアクセス可能になります。リクエストされたリソースは、WebGate(Oracle Access Manager IdMデプロイメント)によって保護されています。

リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。

図2-9 SPモードでのOracle Access Managerによる認証

Oracle Access Managerを使用して、ピア・プロバイダでユーザーを認証するフローは次のとおりです。

- ユーザーはピアIdPにいます(手順1)。

- IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします(手順2、3)。

- Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します(手順4)。

- 認証モジュールはOracle Access Managerと情報をやり取りし、の認証済セッションを作成します(手順5)。

- 認証モジュールがユーザーを保護されたリソースにリダイレクトします(手順6)。

- WebGate Webエージェントが、保護されたリソースへのアクセスをユーザーに許可します(手順7)。

2.3.5 SPモードでのOracle Single Sign-Onへの認証状態の伝播

このモードで、Oracle Identity Federationはフェデレーション・プロトコルを使用してユーザーを識別し、ユーザーがリクエストされたリソースにアクセスできるように、Oracle Single Sign-Onに認証済セッションを作成するように認証モジュールにリクエストします。リクエストされたリソースはmod_ossoによって保護されています。

リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。

図2-10 SPモードでのOracle Single Sign-Onによる認証

Oracle Single Sign-Onを使用して、ピア・プロバイダでユーザーを認証するフローは次のとおりです。

- ユーザーはピアIdPにいます(手順1)。

- IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします(手順2、3)。

- Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します(手順4)。

- 認証モジュールが、ユーザーをユーザーIDとともにOracle Single Sign-Onにリダイレクトします(手順5、6)。

- Oracle Single Sign-Onが、ローカルの認証済セッションを作成し、mod_ossoによって保護されたリソースへのアクセスを許可します(手順7、8)。

2.3.6 HTTP Basic認証

Oracle Identity Federationは、IDおよびアクセス管理システムを必要とせず、HTTP Basic資格証明を承諾するように構成できます。これはJAAS認証エンジンを使用することに相当します。

2.4 データ・リポジトリ

この項では、Oracle Identity Federationでデータ・ストアを使用する場合のインストール要件について説明します。内容は次のとおりです。

- フェデレーション・データ・ストア

- ユーザー・データ・ストア

- セッション・データ・ストアおよびメッセージ・データ・ストア

- 構成データ・ストア

2.4.1 フェデレーション・データ・ストア

永続フェデレーション・データ・ストアに使用するデータ・リポジトリを選択する必要があります。Oracle Identity Federationでは、次のような業界標準のLDAPリポジトリを使用できます。

- Oracle Internet Directory

- Sun Java System Directory Server

- Microsoft Active Directory

- IBM Tivoli

XMLストア、データベース、さらには電子メール・アドレス、X.509 DN、KerberosまたはWindows名前識別子などの、不透明でない名前識別子を使用する、SAMLおよびWS-FederationのNoneオプション(リポジトリなし)もサポートしています。

接続情報

Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。

- 接続URL(ホスト名とポートで構成されるLDAPサーバーURLのスペース区切りリスト)。

- バインドDN。
これは、Oracle Identity FederationサーバーがLDAPサーバーに接続するために使用するDNです。次に例を示します。

cn=fedid,dc=mycompany,dc=com

- Password

- ユーザー・フェデレーション・レコード・コンテキスト。
これは、このOracle Identity Federationサーバーのすべてのフェデレーション・レコードをその下に格納するノードです。

- LDAPコンテナ・オブジェクト・クラス。
これは、LDAPコンテナがまだない場合に、それを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキストのタイプです。このフィールドが空白の場合は、applicationprocessに値が設定されます。Microsoft Active Directoryの場合、たとえばコンテナにこのフィールドが設定される必要があります。このフィールドの適切な設定は、使用されているユーザー・フェデレーション・レコード・コンテキストにより異なります。(ユーザー・フェデレーション・レコード・コンテキストについては、この項の後の方で説明します)。

様々なタイプのディレクトリ・サーバーの場合のLDAPコンテナ・オブジェクト・クラスの例を次に示します。

- Oracle Internet Directory: 空

- Oracle Directory Server Enterprise Edition: 空

- Microsoft Active Directory: container

- 一意のフェデレーションID属性。
これは、フェデレーション・レコードを一意に識別するために使用されるLDAP属性です。この属性は、Federation RecordタイプのLDAPオブジェクト・クラス、またはその最上位の親で定義される必要があります。空の場合は、デフォルトのフェデレーションID属性はフェデレーション・レコードのDNとして使用されます。

様々なタイプのディレクトリ・サーバーの場合の、一意のフェデレーションID属性の例を示します。

- Oracle Internet Directory: 空

- Oracle Directory Server Enterprise Edition: 空

- Microsoft Active Directory: 空

- 最大接続数。これは、Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。

- 接続待機タイムアウト。これは、Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。

ユーザー・フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスの関係

ユーザー・フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスには互換性がある必要があります。ユーザー・フェデレーション・レコード・コンテキストでは、フェデレーション・レコードが格納されるコンテナのDNを管理者が指定します。そのDNは、コンテナの親(あらかじめ存在する必要があります。たとえばdc=us,dc=oracle,dc=com)、およびそのオブジェクト・クラスの一部であるフェデレーション・レコード・コンテキストの属性(たとえばcn=orclfed)を含みます。そうしたDNの例は、たとえばcn=orclfed,dc=us,dc=oracle,dc=comのようになります。

この例の要件は、cnがLDAPコンテナ・オブジェクト・クラス・フィールドに設定されているオブジェクト・クラス(設定されていない場合はapplicationprocessオブジェクト・クラス)の属性である必要があるということです。

DNがou=fed,dc=us,dc=oracle,dc=comであるようなフェデレーション・レコード・コンテキストを持つことを管理者が選択する場合、管理者は、LDAPコンテナ・オブジェクト・クラス・フィールドを、属性がouであるオブジェクト・クラス(たとえば、organizationalUnit)に設定する必要があります。

要約すると、ユーザー・フェデレーション・レコード・コンテキストは、フェデレーション・レコードが格納されるLDAPコンテナ・エントリを参照しており、DNで使用されるLDAPコンテナの属性は、使用されるLDAPコンテナ・オブジェクト・クラスで定義される必要があります。たとえば、DNがou=fed,dc=us,dc=oracle,dc=comの場合、LDAPコンテナ・オブジェクト・クラスはou属性を定義する必要があります。DNがcn=fed,dc=us,dc=oracle,dc=comの場合は、LDAPコンテナ・オブジェクト・クラスはcn属性を定義する必要があります。

LDAPスキーマに関する注意

フェデレーション・サーバーによりLDAPサーバーにレコードが作成されるようにするには、Oracle Identity Federationが定義する属性およびオブジェクト・クラスが含まれるようにLDAPスキーマをアップグレードする必要があります。

LDAPスキーマのアップグレードは、インストール時(拡張インストール・モードを使用)またはインストール後に行います。

インストール時のスキーマのアップグレード

インストール時にアップグレードするには、次の手順を実行します。

1. 「拡張インストール」モードを選択します。

2. 「構成オプションの選択」ページで、「LDAPサーバー内のフェデレーション・データ」ボックスを選択します。これにより、フェデレーション・レコードが、スキーマのアップグレードが必要なLDAPサーバーに格納されるように指定されます。

3. 「フェデレーション・データ・ストアの指定」ページで、LDAP接続情報を入力します。これで、スキーマがインストール・プロセスの一部としてアップグレードされます。

インストール後のスキーマのアップグレード

インストール後にアップグレードを行うには、Oracle Identity Federationのインストールに、ldapmodifyツールを使用してLDAPサーバーのスキーマをアップグレードできるLDIFファイルが含まれていることを確認してください。

使用するLDIFファイルは、使用するLDAPサーバーの種類によって異なります。

- Oracle Internet Directoryを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldifです。

- Oracle Directory Server Enterprise Edition 5.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne5.ldifです。

- Oracle Directory Server Enterprise Edition 6.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne6.ldifです。

- Microsoft Active Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldifです。この場合、LDIFファイルを編集して%DOMAIN_DN%という文字列を使用中のActive Directoryのドメインの接尾辞と置き換える必要があります。
たとえば、接尾辞はdc=mydomain,dc=mycompany,dc=comです。

- IBM Tivoli Directory Server(IBM TDS)6.0を使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaTivoli.ldifです。

ldapmodifyを使用して、LDAPスキーマをLDIFファイルでアップグレードできます。次に例を示します。

ldapmodify -c -D BIND_DN_USERNAME
-w PASSWORD
-f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif
-h LDAP_HOSTNAME -p LDAP_PORT -x

2.4.2 ユーザー・データ・ストア

ユーザー・データ・ストアではデータ・リポジトリを選択する必要があります。Oracle Identity Federationでは、次のような業界標準のリポジトリを使用できます。

- LDAP(Oracle Internet Directory、Sun Java System Directory ServerおよびMicrosoft Active Directory)

- RDBMS

データ・リポジトリのロールは、Oracle Identity Federationがアイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)のどちらに構成されるかにより異なります。

- IdPの場合、Oracle Identity Federationはリポジトリを使用して、ユーザーIDを検証し、プロトコル・アサーションを構築します。

- SPの場合、次のようになります。

- Oracle Identity Federationはリポジトリを使用して、受信したアサーションの情報を宛先のユーザーIDにマップし、その後で保護されたリソースへのアクセスを認可します。

- 新たにフェデレーションを作成する場合、Oracle Identity Federationは、リポジトリを使用してユーザーを特定し、新しいフェデレーションをそのユーザーのアカウントにリンクします。

LDAPリポジトリの場合の接続情報

Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。

- 接続URL - LDAPのURLのスペース区切りリスト。

- バインドDN。

- Password

- ユーザーID属性 - ルックアップまたは認証手順でユーザーをマップするために使用する属性名。
ディレクトリ・サーバーのタイプごとのユーザーID属性の例を次に示します。

- Oracle Internet Directory: uid

- Oracle Directory Server Enterprise Edition: uid

- Microsoft Active Directory: sAMAccountName

- ユーザー説明属性。
このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。

ディレクトリ・サーバーのタイプごとのユーザー説明属性の例を次に示します。

- Oracle Internet Directory: uid

- Oracle Directory Server Enterprise Edition: uid

- Microsoft Active Directory: sAMAccountName

- 個人オブジェクト・クラス - LDAPサーバーでユーザーを表すLDAPオブジェクト・クラス。
様々なタイプのディレクトリ・サーバーの場合の個人オブジェクト・クラスの例を次に示します。

- Oracle Internet Directory: inetOrgPerson

- Oracle Directory Server Enterprise Edition: inetOrgPerson

- Microsoft Active Directory: user

- ベースDN - LDAPユーザー検索が実行されるノード。次に例を示します。
dc=us,dc=oracle,dc=com

- 最大接続数 - Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。

- 接続待機タイムアウト - Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。

RDBMSリポジトリの場合の接続情報

Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。

- JNDI名 - ユーザーを認証またはロケーティングするためにOracle WebLogic Serverに構成されている、RDBMSを参照するデータソースを参照します。Oracle Identity Federationをインストールした後で、このデータソースを定義しないとユーザーを認証できません。

- ログイン表 - 認証とルックアップのために使用される、ユーザー情報を含むRDBMS表。

- ユーザーID列 - ユーザー識別子を含むログイン表のRDBMS列。

- ユーザー説明属性 - このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。

2.4.3 セッション・データ・ストアおよびメッセージ・データ・ストア

Oracle Identity Federationは、フェデレーション・セッション/プロトコルの状態に使用する一時セッション・データ・ストアやメッセージ・データ・ストアもメンテナンスします。このデータは、メモリー内の表またはリレーショナル・データベースに格納できます。

高可用性とクラスタ化のサポートを使用するには、RDBMSのセッション・データ・ストアおよびメッセージ・データ・ストアが必要です。

2.4.4 構成データ・ストア

Oracle Identity Federationの構成データは、XMLファイルまたはリレーショナル・データベースに格納できます。

高可用性とクラスタ化のサポートを使用するには、RDBMS構成データ・ストアが必要です。

2.5 インストール要件

この項では、インストール要件を説明します。

注意:
Liberty 1.xのサポートは非推奨です。

2.5.1 必須コンポーネント

Oracle Identity Federationには、次のコンポーネントが必要です。

- Java 2 SDK Standard Edition (J2SE) Version 1.4.2(インストールにバンドル)。

- Oracle WebLogic Server

- ユーザーIDデータ・ストア。通常はLDAPディレクトリですが、オプションでデータベース・ストアにすることもできます。

- ユーザー・フェデレーション・データ・ストア用に次のリポジトリのいずれか。

- Oracle Internet Directory

- Microsoft Active Directory

- Sun Java System Directory Server

注意:
Oracle Identity Federationではユーザー・フェデレーション・データ・ストアがすべての場合に必ず必要になるとは限りません。Liberty 1.xおよびSAML 2.0の不透明な永続識別子には必要ですが、SAML 1.x、WS-Federation、およびSAML 2.0の不透明でない識別子(電子メール・アドレス、サブジェクトDNなど)では任意です。

- Oracle Database for the RDBMS一時データ・ストア用に次のバージョンのOracle Databaseのいずれか。

- Oracle Database 10.2.0.4以上

- Oracle Database 11.1.0.7以上

- Oracle Database 11.2.x

注意:
最新のバージョン情報については、認定マトリクスを確認してください。

- プロキシ実装用のOracle HTTP Server。これはOracle Identity Federationでサポートされる唯一のプロキシ・サーバーで、インストールにバンドルされています。

2.6 サイジングのガイドライン

Oracle Identity Federationを活用するフェデレーテッド・アイデンティティ・システムのデプロイを計画する場合、アーキテクチャに関係するパフォーマンス関連の考慮事項、選択肢およびトレードオフを把握する必要があります。

この項では、フェデレーテッド環境においてパフォーマンスに影響を与える様々な要因について検討し、スタンドアロンのOracle Identity Federationサーバーを使用する本番システム向けのハードウェア要件を見積もる際に役立つガイドラインを提供します。トピックは次のとおりです。

- デプロイメントおよびアーキテクチャの考慮事項

- 一般的なデプロイ・シナリオ

- リファレンス・サーバーのフットプリント

- トポロジ

2.6.1 デプロイメントおよびアーキテクチャの考慮事項

Oracle Identity Federationをデプロイする前に、フェデレーテッド認証設定におけるOracle Identity Federationのアーキテクチャとその役割を定義する必要があります。次の事項を決定する必要があります。

- 様々な信頼できるパートナでどのフェデレーション仕様が使用されるか。次のような選択肢があります。

- SAML 2.0。SAML 1.xと比較すると、フローが追加されることによってパフォーマンス上の考慮事項がより重要になる可能性があります。

- SAML 1.0および1.1

- WS-Federation

- パートナとのフェデレーションにどのプロファイルを使用するか。オプションには、ブラウザPOSTプロファイルまたはアーティファクト・プロファイル、WS-Federationパッシブ・リクエスタ・プロファイル、属性共有、その他があります。

- どのトランスポート・セキュリティ・プロトコルおよび証明書を使用するか。アサーションは署名されるか。

- Oracle Identity Federationが果す役割は何か。オプションは次のとおりです。

- アイデンティティ・プロバイダ(IdP)(ソース・ドメイン)

- サービス・プロバイダ(SP)(宛先ドメイン)

- IdPおよびSPの両方

- どのタイプ(およびどのベンダー)の認可IDリポジトリがインストールされるか。

注意:
Oracle Identity Federationは、アクセス管理システムを必要としない、軽量のフェデレーション・エンドポイントの作成を可能にする統合フレームワークを提供します。

- Oracle Identity Federationにプロキシ・サーバーをインストールするかどうか。インストールする場合、DMZまたはファイアウォールの内部など、Oracle Identity Federationおよびプロキシ・サーバーが置かれる場所に配慮してください。

- アーキテクチャがどのように高可用性のシナリオを提供するか。具体的には、次のとおりです。

- Oracle Application Server高可用性トポロジを活用して、コールド・フェイルオーバー・クラスタをサポートするかどうか

- ロード・バランシングおよびフェイルオーバー構成において、複数のフェデレーション・サーバーがアサーション・データを使用できるように、一般的なアサーション・ストア・データベースを設定するかどうか

Oracle Identity Federationの全体的なスループットおよびパフォーマンスは、次のような様々な要因によって左右されます。

- サポートされているプロファイル(アーティファクトまたはPOSTなど)

- 使用されるセキュリティ機能(証明書、デジタル署名または暗号化アサーション(あるいはその両方))

- トランザクションの処理に関係する、ファイアウォール、プロキシ・サーバー、LDAPディレクトリ、データベース、およびIAMシステムなどの個々のコンポーネントの使用

以降の副項では、これらの内容について詳しく説明します。

- プロファイル

- リポジトリ

- 一時(セッションおよびメッセージ)ストレージ

- アサーションのセキュリティ

- 接続のチューニング

- 高可用性

- サーバーのチューニング

- HTTPセッションの永続性

- 追加のセキュリティの影響

2.6.1.1 プロファイル

SAMLの仕様は、デプロイされる2つの主要なプロファイル、SAMLブラウザPOSTプロファイルおよびアーティファクト・プロファイルを含む、多数のプロファイルをサポートします。一般的に、SAMLブラウザPOSTプロファイルを使用すると、IdPおよびSP間での必要なラウンドトリップが少ないため、POSTプロファイルはアーティファクト・プロファイルよりもパフォーマンスに優れています。ただし、一般的にアーティファクト・プロファイルのほうがSAMLアサーションの交換においてはより安全な方法のため、セキュリティ上のトレードオフの可能性が生じます。

2.6.1.2 リポジトリ

LDAPディレクトリ、RDBMSおよびバックエンドIAMシステムを使用する場合、本番環境のパフォーマンスに影響を与える恐れがあるため、該当するコンポーネントのトランザクションの処理スピードに注意する必要があります。次の点に注意してください。

- データベース接続プールの設定を制御するオプションを提供するように、RDBMSパラメータを設定できます。

- バックアップされたIDおよびアクセス管理システムとして、Oracle Access Managerを使用する場合、次に示すアクセス・サーバーのサイジング考慮事項と同様、アクセス・ゲートのパフォーマンス上の考慮事項が適用されます。
http://docs.oracle.com/cd/E15217_01/doc.1014/e12490.pdf

2.6.1.3 一時(セッションおよびメッセージ)ストレージ

パフォーマンスを向上させるために、一時データ・ストアをメモリー内に置くようにします。

2.6.1.4 アサーションのセキュリティ

SAMLアサーションでは、デジタル署名/暗号化を使用するかどうかによってパフォーマンスが左右されます。これらの機能を削除するとパフォーマンスは向上しますが、IdPおよびSPの通信がインターネット上で行われる場合は、削除しないことをお薦めします。

2.6.1.5 接続のチューニング

次に対する同時接続の最大数を、適切に調整してください。

- LDAPサーバー

- RDBMS(一時セッション・データおよび構成向け)

- リモート・プロバイダ(Oracle Identity FederationがSOAPプロトコルを使用して相互に直接通信する場合)

2.6.1.6 高可用性

パフォーマンスおよび高可用性を向上させるには、複数のOracle Identity Federationサーバーのスケーリングおよびロード・バランシングを行うことも考慮してください。ロード・バランシング・ソリューションを実装すると、使用するサイトをバックアップおよびフェイルオーバーによって保護できます。

詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

2.6.1.7 サーバーのチューニング

本番環境における他のサーバーの存在も考慮します。具体的には、次のように考慮します。

- Oracle WebLogic Serverをチューニング、およびOracle Identity Federationへの適切な接続制限を設定します。次のことが可能です。

- メモリーの使用量、プロセスの数などの典型的な構成パラメータを使用してOracle WebLogic Serverをチューニングします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』を参照してください。

- Oracle Identity FederationがリモートのHTTPサーバーおよびRDBMSサーバーと通信する際に使用するHTTP/JDBC接続の最大数を指定します。詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。

- Oracle Identity Federationが活用するOracle HTTPサーバーをチューニングします。

関連項目:
チューニングおよびパフォーマンスのガイドラインは次を参照してください。

- 第6.3.1項「LDAP非アクティブ設定の構成」

- 第6.4.2項「HTTPセッション状態のスリープ/再試行間隔の構成」

- 第6.5.1項「RDBMSセッション・キャッシュの構成」

- 第6.6.1項「ユーザー・セッションのアサーション属性の格納」

- 第7章「診断および監視」

- 『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

2.6.1.8 HTTPセッションの永続性

Oracle Identity Federationは、リクエストを処理する際にHTTPセッション状態を使用します。Oracle WebLogic Serverのセッション永続性を構成するには、『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「セッションとセッション永続性の使用」の章を参照してください。

デフォルトでは、メモリーベースのストレージが使用されます。Oracle WebLogic Serverの実行中に十分なヒープサイズを確保できない場合、高負荷の状況でサーバーのメモリーが不足するおそれがあります。

2.6.1.9 追加のセキュリティの影響

ファイアウォール、プロキシ・サーバーなどの追加のセキュリティ対策の導入や、SSL認証の使用によりフェデレーテッド・トランザクションに追加のステップが加わると、パフォーマンスに影響が及ぶ場合があります。

2.6.2 一般的なデプロイ・シナリオ

図2-11は、サービス・プロバイダ向けの一般的なOracle Identity Federationデプロイメントのアーキテクチャを示しており、ここではOracle Identity Federationは、バックエンドのアクセス管理システムとしてOracle Access Managerに依存しています。この図では、複数のパートナがDMZを介して、ロード・バランシングが行われたOracle Identity Federationプロキシ・サーバーのペアにアクセスしています。これらのプロキシ・サーバーは、Oracle Identity Federationサーバーのペアのフロントエンドです。

図2-11 一般的なFederationデプロイメント・アーキテクチャ

2.6.3 リファレンス・サーバーのフットプリント

2000人の同時ユーザーをサポートする環境においては、基本のOracle Identity Federationデプロイメントについて、次のハードウェアおよび機器をお薦めします。

- Oracle Identity Federation用にサポートされるすべてのサーバークラスのマシンおよびオペレーティング・システム。Oracle Identity Federation向けに認定されたプラットフォームのリストは、認定マトリクスを参照してください。
フェイルオーバーのシナリオでは、必要なマシン数が倍になります。冗長性を確保するため、2つ以上のOracle Identity Federationサーバーを別個のマシン上で使用します。

- サーバーのフットプリント:

- 2から4GBのメモリー(4GBを推奨)

- マシンごとに2つ以上のCPU

- プロキシ・サーバーを使用する場合は、ベンダー固有のサイジングの推奨に従ってください。

2.6.4 トポロジ

図2-12は、SPモードでのOracle Identity Federationデプロイメントに対して推奨されるトポロジを示しています。ここでは、Oracle HTTPサーバーがWebGateによって保護されたプロバイダ・アプリケーションを提供します。

図2-12 Oracle Identity Federationのトポロジのサンプル

2.7 実装チェックリスト

次のチェックリストはOracle Identity Federationインストールを計画するための主要な項目を要約したもので、デプロイメントを行うための第1歩となります。

注意:
Liberty 1.xのサポートは非推奨です。

表2-4 実装チェックリスト

計画項目

推奨値/提案値

注意

アーキテクチャ/基本構成

設定するロール

IdPとSPのいずれかまたは両方。

プロトコル

Liberty 1.1、Liberty 1.2、SAML 2.0、またはこれらの任意の組合せ。SAML 1.0、SAML 1.1およびWS-Federation。

リポジトリ

ユーザー・データおよびフェデレーション永続データのリポジトリを指定します。

LDAPサーバー・ホスト名

例: ldap.mydomain.com

LDAPサーバーのポート番号

例: 389

LDAPサーバーのアクセス資格証明

たとえばBind DN = {cn=orcladmin}, Password = {mysecret}。

ベースDN

たとえばdc=mydomain,dc=com。

フェデレーション・レコード・コンテキスト

たとえばcn=fed,dc=mydomain,dc=com。

フェデレーション・スキーマの更新脚注1

この情報はインストール時に必要です。

一時データ・ストア

一時データのリポジトリを、RDBMSにするか、メモリー内にするか指定します。

構成データ・ストア

一時データのリポジトリを、RDBMSにするか、ファイルにするか指定します。

IdPのプロファイルとバインディング

有効な組合せ1つに1行を使用します。

SPのプロファイルとバインディング

有効な組合せ1つに1行を使用します。

SSL暗号化

有効/無効

SSL用Javaキーストア

SSL設定の詳細は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

証明書

署名

署名キーのペアに対するPKCS #12ウォレットの位置を指定します。

暗号化

暗号化キーのペアに対するPKCS #12ウォレットの位置を指定します。

パフォーマンス計画

トポロジ、リファレンス・サーバーのフットプリント

パフォーマンス上のヒントおよび推奨事項は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。

脚注 1 フェデレーション・スキーマ更新の場合、接続URL、バインドDN、パスワード、ユーザー・フェデレーション・レコード・コンテキスト、LDAPコンテナ・オブジェクト・クラス(Microsoft Active Directory)および一意のフェデレーションID属性を収集します。

3 Oracle Identity Federationのデプロイ

この章では、IDおよびアクセス管理システム、Webサーバーおよびバックエンド・データ・ストアとの統合など、主なデプロイ・シナリオについて説明します。内容は次のとおりです。

- 概要

- デプロイ・シナリオ

- アップグレード後の管理

3.1 概要

Oracle Identity Federationは、異機種間システム環境で動作し、様々な種類のプラットフォームやアプリケーションと連携できます。また、データ・ストアおよび認証プロバイダのための多様なオプションをサポートしています。

デプロイメントの問題および質問を解決するには、第2章「Oracle Identity Federationデプロイメントの計画」を参照してください。この章では、デプロイメントの計画に役立つ広範なバックグラウンド情報が説明されています。

- 第2.1項「アーキテクチャ・オプション」では、サポートされているプロトコルおよびプロファイルに関する詳細と、デプロイメント・オプションを評価する際の考慮事項について説明しています。

- 第2.6項「サイジングのガイドライン」では、パフォーマンスに影響を与える要因と、トポロジに関する推奨事項について説明しています。

- 第2.7項「実装チェックリスト」は、デプロイメント用のチェックリストです。

次の項では、様々なデプロイ・シナリオについて説明した後で、フェデレーション環境の主要なコンポーネントと連携するようにOracle Identity Federationを構成する手順について段階的に説明します。

3.2 デプロイ・シナリオ

この項では、一般的なOracle Identity Federationのデプロイ・シナリオを実装するために必要な手順について説明します。これらの項目が含まれます。

- Oracle Identity FederationとOracle HTTP Serverのデプロイ

- Oracle Identity FederationとOracle Single Sign-Onのデプロイ

- Oracle Identity FederationとOracle Access Manager 11gのデプロイ

- Oracle Identity FederationとOracle Access Manager 10gのデプロイ

- Oracle Access Managerに対するOracle Identity Federation/SPの認証

- Oracle Identity FederationとOracle Directory Server Enterprise Editionのデプロイ

- テストSPエンジンの使用

3.2.1 Oracle Identity FederationとOracle HTTP Serverのデプロイ

HTTPサーバーはWeb層にデプロイされます。

大半のアイデンティティ管理コンポーネントはWeb層なしで動作できますが、大半のエンタープライズ・デプロイメントではWeb層が望ましいです。Oracle Single Sign-OnやOracle Access Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。

この項では、Oracle HTTP Server (OHS)と統合されるようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。

- Oracle HTTP Serverのインストール

- Oracle HTTP Serverインスタンスの管理

- Oracle HTTP Serverと管理対象サーバーの関連付け

- Oracle Identity Federationの構成の更新

3.2.1.1 Oracle HTTP Serverのインストール

注意:
Oracle HTTP Serverのインストール時に有効になるのはHTTPプロトコルのみです。Oracle HTTP Serverと、Oracle Identity Federationが実行されている管理対象サーバーの間でSSLを有効にするには、インストール後にHTTPSを構成する必要があります。
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

IdMスイートのインストール時に、「コンポーネントの選択」画面で「Oracle HTTP Server」を選択します。これによりOracle HTTP Serverがインストールされます。

インストール後に、次のコマンドライン命令を発行してインスタンスを作成します。

$AS_INST/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME

$AS_INSTはアプリケーション・サーバー・インスタンス・ホームを、$OHS_NAMEは新しいOHSコンポーネントの名前を示しています。

3.2.1.2 Oracle HTTP Serverインスタンスの管理

Oracle HTTP Serverを開始、停止および再起動するためのコマンドは、それぞれ次のとおりです。

$AS_INST/bin/opmnctl startproc process-type=OHS
$AS_INST/bin/opmnctl stopproc process-type=OHS
$AS_INST/bin/opmnctl restartproc process-type=OHS

AS_INSTはアプリケーション・サーバー・インスタンス・ホームを示しています。

3.2.1.3 Oracle HTTP Serverと管理対象サーバーの関連付け

次に、次の手順を実行してOracle Identity Federationが実行されている管理対象サーバーにOracle HTTP Serverを関連付けます。

1. $AS_INST/config/OHS/$OHS_NAME/moduleconf/oif.confを開きます。
$AS_INSTはアプリケーション・サーバー・インスタンス・ホームを示しています。

2. Oracle Identity Managementがスタンドアロン・モードでインストールされている場合は、Oracle Identity Federationが実行されているWebLogic管理対象サーバーを参照するようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: myhost.us.mycorp.comと7499)。

3. Oracle Identity Managementがクラスタ・モードでインストールされている場合は、Oracle Identity Federationが実行されているOracle WebLogic Server管理対象サーバーを参照するようにWebLogicCluster変数を非コメント化して設定します(例: myhost1.us.mycorp.com:7499、myhost2.us.mycorp.com:7499)。

4. ファイルを保存して終了します。

5. Oracle HTTP Serverを再起動します。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

3.2.1.4 Oracle Identity Federationの構成の更新

次に、次の手順を実行してOracle Identity Federationの構成を更新します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サーバー・プロパティ」の順に移動します。

3. OHSで構成されているホスト名が反映されるようにホスト名を変更します(ホスト名が異なる場合)。

4. 「ポート - SSL有効」および「SOAPポート - SSL有効」の情報を変更してOHSの構成を反映させます。

5. 変更を保存します。

6. Oracle Identity Federationメタデータが変更されるため、メタデータをリモート・パートナに再分配して、変更をリモート・パートナに通知します。

関連項目:
第5.2項「サーバー・プロパティの構成」

3.2.2 Oracle Identity FederationとOracle Single Sign-Onのデプロイ

この項では、Oracle Single Sign-Onと統合するようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。

この方法でデプロイすると、Oracle Identity Federationは、ローカル・ユーザー認証が必要な場合に、Oracle Single Sign-Onが提供する認証機能を利用することができます。Oracle Identity Federationは次のことが可能です。

- OHSおよびOracle Single Sign-Onと統合し、認証エンジンとして動作します。

- Oracle Single Sign-Onと統合し、SP統合モジュールとして動作します。

このデプロイを実行する手順を簡単にまとめると、次のようになります。

- Oracle HTTP Serverインスタンスの作成および管理

- Oracle Single Sign-OnとOHSの統合

- Oracle Single Sign-Onを認証エンジンとして使用する場合のOracle Identity Federationの構成

- Oracle Single Sign-On SP統合を使用する場合のOracle Identity Federationの構成

- Oracle Single Sign-Onの構成

- フェデレーテッド・シングル・サインオンのテスト

次に、これらの手順の詳細を説明します。

注意:
Oracle Single Sign-Onと統合した場合、Oracle Identity Federationでは、ユーザーの資格証明を再要求する機能がサポートされません。このため、Oracle Identity Federationでは、再認証を要求する必要があるユース・ケースをサポートできません。
たとえば、ForceAuthn="true"のAuthnRequestがSPからOracle Identity Federation IdPに送信され、Oracle Identity FederationがOracle Single Sign-Onと統合されている場合、ForceAuthnフラグは無視されます。

3.2.2.1 Oracle HTTP Serverインスタンスの作成および管理

OHSを構成するには、第3.2.1項「Oracle Identity FederationとOracle HTTP Serverのデプロイ」の手順を実行します。

3.2.2.2 Oracle Single Sign-OnとOHSの統合

Oracle Identity FederationとOracle Single Sign-Onをデプロイするにはこの統合が必要です。

パートナ・アプリケーションの登録

まず11gリリース1(11.1.1) OHSのmod_ossoモジュールを10g Oracle Single Sign-Onサーバーにパートナ・アプリケーションとして登録します。

この手順の詳細は、『Oracle Application Server Single Sign-On管理者ガイド 10g』のパートナ・アプリケーションの構成および管理に関する項を参照してください。

Oracle Single Sign-Onサーバーからssoregを実行してosso.confファイルを生成し、パートナ・アプリケーション(Oracle Identity FederationインスタンスのAS_INST)に手動でコピーする必要があります。

リモート・パートナ・アプリケーションをOracle Single Sign-Onサーバーに登録する場合の例を次に示します。

$ORACLE_HOME/sso/bin/ssoreg.sh
-site_name oif.server.com:7499
-config_mod_osso TRUE
-mod_osso_url http://oif.server.com:7499
-remote_midtier
-config_file oif.server.com.osso.conf

Oracle Single Sign-OnサーバーのOC4J_SECURITYインスタンスを再起動します。

このコマンドを実行すると、コマンドを起動したディレクトリにoif.server.com.osso.confというファイルが作成されます。そのファイルを$AS_INST/config/OHS/$OHS_NAME/にコピーします。

mod_ossoの設定

次の手順ではmod_ossoを設定します。

$AS_INST/config/OHS/$OHS_NAME/disabled/mod_osso.confを$AS_INST/config/OHS/$OHS_NAME/moduleconfにコピーします。OHSの起動時に、moduleconfディレクトリ内のすべてのファイルが読み込まれます。

$AS_INST/config/OHS/$OHS_NAME/moduleconf/mod_osso.confファイルを開きます。作成後に次のOHS configディレクトリにコピーされたOracle Single Sign-On構成ファイルを参照するように、OssoConfigFileディレクティブを設定します。

OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/oif.server.com.osso.conf

Location要素を介して、Oracle SSOサーバーで保護する/fed/user/authnosso URLを追加します。

mod_osso.confの例は次のようになります。

LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/
${COMPONENT_NAME}/oif.server.com.osso.conf

<Location /fed/user/authnosso>
require valid-user
AuthType Osso
</Location>
</IfModule>

注意:
SSLが有効でない場合は、OssoSecureCookiesディレクティブを追加して、offに設定する必要があります。これを行わないと、mod_ossoはCookieが保護されていると見なして、HTTPSでCookieを送信するようにブラウザに指示します。
詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのmod_osso Cookieのセキュアな伝送に関する項を参照してください。

mod_osso.confは次のようになります。

LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/oif.server.com.osso.conf

</IfModule>

#

#
# To have short hostnames redirected to fully qualified
# hostnames for clients that need authentication via
# mod_osso to be able to enter short hostnames into their
# browsers use a mod_rewrite configuration such as the following.
#
# e.g
#RewriteEngine On
#RewriteCond %{HTTP_HOST} !www.example.com
#RewriteRule ^.*$ http://%{SERVER_NAME}%{REQUEST_URI} [R]
#where www.example.com is the fully qualified domain name.

OHSを再起動して、mod_ossoおよびmod_wlの構成の変更を有効にします。

3.2.2.3 Oracle Single Sign-Onを認証エンジンとして使用する場合のOracle Identity Federationの構成

このタスクでは、Oracle Single Sign-On認証エンジンを使用するようにサーバーを構成します。詳細は、第2.3.1項「Oracle Identity Federationのエンジン」を参照してください。

まず次の手順を実行してOracle Single Sign-On認証エンジンを有効にします。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」→Oracle SSOの順に移動します。

3. エンジンを有効にします。

4. 変更を保存します。

Oracle Single Sign-OnがOracle Identity Federationの認証エンジンとして統合のみが行われている場合は、Oracle Single Sign-OnサーバーでOracle Single Sign-Onのログアウト用の構成を設定し、Oracle Identity FederationサーバーでOracle Identity Federationのログアウト用の構成を設定する必要があります。

Oracle Single Sign-Onを設定するには、次の手順を実行します。

1. $ORACLE_HOME/sso/conf/policy.propertiesを開きます。

2. SASSOLogoutUrlを非コメント化します。

3. Oracle Identity Federationのホスト名/ポート情報を次のように設定します。

SASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/authnsloosso

4. 変更を保存して終了します。

5. OC4J_SECURITYインスタンスを再起動します。

関連項目:
第5.15項「認証エンジンの構成」

Oracle Identity Federationを設定するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」→Oracle SSOの順に移動します。

3. ログアウトを有効にします。

4. Oracle Single Sign-Onサーバーの「ログアウトURL」で次のように入力します。

http://osso-hostname:osso-port/sso/logout

5. 変更を保存します。

関連項目:
第5.15項「認証エンジンの構成」

3.2.2.4 Oracle Single Sign-On SP統合を使用する場合のOracle Identity Federationの構成

このタスクでは、Oracle Single Sign-Onをサービス・プロバイダ統合モジュールとして有効にし、必要に応じてOracle Single Sign-On認証エンジンのログアウトを無効にします。

まず次の手順を実行してOracle Single Sign-On SPモジュールをOracle Identity Federationで有効にします。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ統合モジュール」→Oracle SSOの順に移動します。

3. SPモジュールを有効にします。

4. フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合は、ユーザーをローカルに認証するために使用する認証メカニズムを選択します。

5. Oracle SSOに対してOracle Identity Federationが提供する必要のあるユーザー名属性を入力します。デフォルトはuidです。

6. Oracle Single Sign-Onサーバーの「ログインURL」を次のように入力します。

http://osso-hostname:osso-port/sso/auth

7. Oracle Single Sign-Onサーバーの「ログアウトURL」を次のように入力します。

http://osso-hostname:osso-port/sso/logout

8. 「ログアウト有効」を選択します。

9. 「OSSOシークレットの再生成」をクリックして暗号化鍵を作成します。この暗号化鍵はファイルに保存され、Oracle Single Sign-Onに渡されます。キーストアをローカルに保存します。

10. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

Oracle Single Sign-OnがOracle Identity Federationの認証エンジンおよびSP統合モジュールとして統合されている場合は、SP統合モジュールでログアウトが管理されるため、Oracle Single Sign-On認証エンジンのログアウトを無効にする必要があります。Oracle Single Sign-On認証エンジンのログアウトをOracle Identity Federationで無効にする手順は次のとおりです。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」→Oracle SSOの順に移動します。

3. ログアウトを無効にします。

4. 変更を保存します。

関連項目:
第5.15項「認証エンジンの構成」

3.2.2.5 Oracle Single Sign-Onの構成

ここでの設定では、Oracle Single Sign-Onサーバーでの設定とパートナの構成が必要です。

注意:
パートナ・アプリケーションは、Oracle Application ServerベースのアプリケーションまたはOracle Single Sign-Onサーバーに認証機能を委任しているOracle以外のアプリケーションです。Oracle Single Sign-Onで認証済のユーザーがアプリケーションの使用を認可されるかどうかは、パートナ・アプリケーションで決定されます。

Oracle Single Sign-Onを設定するには、次の手順を実行します。

1. 前に生成したキーストア・ファイルを$ORACLE_HOME/sso/confにコピーし、キーストアとして保存します。

2. $ORACLE_HOME/sso/conf/policy.propertiesを開きます。

3. SASSOAuthnUrl、SASSOLogoutUrl、SASSOAuthLevelおよびMediumHighSecurity_AuthPluginを非コメント化します。

4. Oracle Identity Federationのホスト名/ポート情報にSASSOAuthnUrl= http\://oif-hostname\:oif-port/fed/user/spossoを設定します。

5. Oracle Identity Federationのホスト名/ポート情報にSASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/spsloossoを設定します。

6. Oracle Identity Federationプラグインの認証レベルにSASSOAuthLevel = MediumHighSecurityを設定します。

7. MediumHighSecurity_AuthPluginを設定します。これによりOracle Identity FederationプラグインがMediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuthのように定義されます。

8. 変更を保存して終了します。

9. OC4J_SECURITYインスタンスを再起動します。

Oracle Identity Federationを認証プラグインとして使用するようにパートナを構成するには、次の手順を実行します。

1. $ORACLE_HOME/sso/conf/policy.propertiesを開きます。

2. パートナ・アプリケーションを追加して、Oracle Identity Federationプラグインにマップされている認証レベルで保護されるようにします。次に例を示します。

content.example.com\:8888 = MediumHighSecurity

3. 変更を保存して終了します。

4. OC4J_SECURITYインスタンスを再起動します。

3.2.2.6 フェデレーテッド・シングル・サインオンのテスト

次の手順に従って、フェデレーテッド・シングル・サインオン構成をテストします。

1. Webブラウザを使用して保護されたリソースにアクセスします。アイデンティティ・プロバイダに求められたら、IdPのドメインでの資格証明を使用してログインします。サービス・プロバイダに求められたら、SPのドメインでの資格証明を使用してログインします。これで保護されたリソースにリダイレクトされます。
パートナ・アプリケーションおよびリソースの保護の詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドを参照してください。

2. ログアウトし、もう一度保護されたリソースへのアクセスを試みます。ここでログインを求めてくるのはアイデンティティ・プロバイダだけです。

3.2.3 Oracle Identity FederationとOracle Access Manager 11gのデプロイ

Identity Federationと、Oracle Access Managerサーバー(OAMサーバー)11gリリース1を統合できます。

統合の詳細は、次のドキュメントを参照してください。

http://docs.oracle.com/cd/E23943_01/doc.1111/e15740/oif.htm

3.2.4 Oracle Identity FederationとOracle Access Manager 10gのデプロイ

この項では、Oracle Access Manager 10gと統合されるようにOracle Identity Federationをインストールおよびデプロイするために必要な手順について説明します。この統合では、認証ユーザー・セッションを作成するためにOracle Identity FederationとOracle Access Managerを相互運用することが可能になります。この手順では、2つのノードから構成されるデプロイ・シナリオを説明します。

この項は、インストールするコンポーネントおよびデプロイメント・タスクの違いに応じて、別々の手順に別れています。

- OHSの作成および管理

- 認証エンジンとしてのOracle Access Managerの統合

- SP統合モジュールとしてのOracle Access Managerの統合

注意:
Oracle Identity Federationによって作成されるOracle Access Managerポリシー・オブジェクトは、Oracle Access Manager Policy/Access Manager管理インタフェースからは変更しないでください。これらのオブジェクトは次の記述によって識別できます:「OIFが作成しました。変更しないでください」。このようなオブジェクトをOracle Access Managerから変更すると、同期上の問題を引き起こす場合があります。したがって、これらのポリシー・オブジェクトは必ずFusion Middleware Controlから更新してください。

注意:
Oracle Access Manager 10g認証エンジンと統合した場合、Oracle Identity Federationでは、ユーザーの資格証明を再要求する機能がサポートされません。このため、Oracle Identity Federationでは、再認証を要求する必要があるユース・ケースをサポートできません。
たとえば、ForceAuthn="true"のAuthnRequestがSPからOracle Identity Federation IdPに送信され、Oracle Identity FederationがOracle Access Managerと統合されている場合、ForceAuthnフラグは無視されます。

3.2.4.1 OHSの作成および管理

11gリリース1(11.1.1)OHSコンポーネントのインスタンスを作成および管理する手順は次のとおりです。

- OHSインスタンスを作成します。

- Oracle Identity Federationが実行されているOracle WebLogic Server管理対象サーバーにOHSインスタンスを関連付けます。

- Oracle Identity Federationの構成を更新します。

- OHSインスタンスを管理します。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

Oracle HTTP Serverインスタンスの作成

注意:
$OHS_NAMEはOHSコンポーネントの名前を示しています。

次のコマンドを実行してインスタンスを作成します。

$AS_ISNT/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME

管理対象サーバーへのOracle HTTP Serverインスタンスの関連付け

OHSから、Oracle Identity Federationが実行されている管理対象サーバーへの接続を有効にするには次の手順を実行します。

1. $AS_ISNT/config/OHS/$OHS_NAME/moduleconf/oif.confを開きます。

2. Idmインストールがスタンドアロン・モードの場合は、Oracle Identity Federationが実行されているWLS管理対象サーバーを参照するようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: myhost.mycorp.comと7499)。

3. Idmインストールがクラスタ・モードの場合は、Oracle Identity Federationが実行されているWLS管理対象サーバーを参照するようにWebLogicCluster変数を非コメント化して設定します(例: myhost1.mycorp.com:7499、myhost2.mycorp.com:7499)。

4. 変更を保存して終了し、OHSを再起動します。

関連項目:
再起動の手順については、第3.2.1.2項「Oracle HTTP Serverインスタンスの管理」を参照してください。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

Oracle Identity FederationにおけるOHSの構成の更新

Oracle Identity FederationサーバーがOHSを認識できるようにするには次の手順を実行します。

1. Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。

2. 「管理」→「サーバー・プロパティ」の順に移動します。

3. OHSで構成されているホスト名が反映されるようにホスト名を変更します(ホスト名が異なる場合)。

4. 「ポート - SSL有効」および「SOAPポート - SSL有効」の情報を変更してOHSの構成を反映させます。

5. 変更を保存します。

6. Oracle Identity Federationメタデータが変更されるため、メタデータをリモート・パートナに再分配して、変更をリモート・パートナに通知します。

関連項目:
第5.2項「サーバー・プロパティの構成」

Oracle HTTP Serverインスタンスの管理

OHSを起動するには、次のようにします。

$AS_ISNT/bin/opmnctl startproc process-type=OHS

$AS_INSTはアプリケーション・サーバー・インスタンス・ホームです。

OHSを停止するには、次のようにします。

$AS_ISNT/bin/opmnctl stopproc process-type=OHS

OHSを再起動するには、次のようにします。

$AS_ISNT/bin/opmnctl restartproc process-type=OHS

3.2.4.2 認証エンジンとしてのOracle Access Managerの統合

関連項目:
認証エンジンの機能と利点を確認するには、第2.3項「認証エンジン」を参照してください。

認証エンジンとしてのOracle Access Managerは、/fed/user/authnoam URLを保護します。

この機能を構成するには、次の手順を実行します。

- 要件の確認およびOHSのデフォルト構成の更新

- OHSとOracle Access Managerの統合

- Oracle Access Managerの構成

- Oracle Identity Federationの構成

要件の確認

コンポーネントのバージョンを確認するには、次の手順を実行します。

1. Oracle Access Managerサーバーのバージョンが10.1.4.3であることを確認します。

2. 11gR1 OHS (2.2)に対応するOracle Access Manager WebGateがインストールされていることを確認します。

OHSで次の手順を実行します。

1. $AS_ISNT/config/OHS/$OHS_NAME/httpd.confファイルを編集します。

2. httpd.confファイルでUserおよびGroupディレクティブを非コメント化するか追加します。

3. nobodyのデフォルト値を、OHS 11gリリース1(11.1.1)をインストールしたユーザーとユーザー・グループに置き換えるか、UserおよびGroupディレクティブがない場合はユーザーとユーザー・グループを追加します。
次に例を示します。

User oracle
Group dba

Oracle HTTP ServerとOracle Access Managerの統合

Oracle Access Managerコンソールを使用して新しいアクセス・ゲートを作成し、アクセス・サーバー・インスタンスに関連付けます。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

関連項目:
WebGateのインストールの詳細は、『Oracle Access Managerインストレーション・ガイド 10g』を参照してください。

OHSがインストールされているマシンで、次の手順を使用してWebGateをインストールします。

1. インストール・ウィザードを起動して、Oracle HTTP Server11gにWebGateをインストールします。

2. アクセス・ゲートの詳細と、アクセス・サーバーの接続情報を入力します。

3. WebGateとOracle HTTP Serverを統合するには、Oracle HTTP Serverのhttpd.confファイルの場所($AS_ISNT/config/OHS/$OHS_NAME/httpd.confにあります)を入力します。

Oracle Access Managerの構成

Oracle Access Managerは、WebGateを使用してOracle Identity Federationのリソースを保護する必要があります。WebGateはすでにインストールされているため、Oracle Access Managerを認証エンジンとして使用するには、Oracle Identity Federationサーバーを保護するポリシーをOracle Access Managerで使用するだけで済みます。Oracle Access Managerで認証を行う場合、Oracle Identity Federationに対してユーザー識別子をHTTPヘッダーとして渡す必要があります。

Oracle Access Managerを構成するには、次の手順を実行します。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

1. Oracle Access Managerコンソールに移動し、「ポリシー・マネージャ」に移動します。

2. ドメインの/fed/user/authnoamリソースを認証スキームと認証ルールで保護します。

3. 「認可ルール」で、「アクション」タブに移動して「変更」をクリックし、「認可成功」セクションで「戻り」プロパティを追加して、値にユーザーIDを設定します。このプロパティはHTTPヘッダーになります。(たとえば、「タイプ」にheadervar、「名前」にuserid、「戻り属性」にuidを設定します。)

関連項目:
Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g

Oracle Identity Federationの構成

次の手順を実行します。

1. Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。

2. 「管理」→「認証エンジン」→「Oracle Access Manager」の順に移動します。

3. エンジンを有効にします。

4. ユーザーIDを含むHTTPヘッダーを入力します。

5. 認証エンジン・フレームワークのみを使用してOracle Identity FederationとOracle Access Managerの統合が行われている場合は、次のログアウト構成手順を実行します。それ以外の場合は、ここではOracle Access Manager認証エンジンのログアウトを無効にします。ログアウト処理を構成する場合は、第3.2.4.3項「SP統合モジュールとしてのOracle Access Managerの統合」を参照してください。

- ログアウトを有効にするには、「ログアウト有効」ボックスを選択します。

- Oracle Access Managerドメインからユーザーがログアウトする際に、Oracle Identity FederationによってOracle Access ManagerのCookieをリセットする場合、「Cookieのクリア」ボックスを選択します。

- Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択して、URLを入力します。詳細は、次の注意を参照してください。

6. 変更を保存します。

注意:
ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。
Oracle Access ManagerのログアウトURLに追加される問合せパラメータは、returnurlで参照します。

注意:
/fed/user/authnoam URLをHTTP Basic認証で保護する場合は、Oracle Access ManagerのBug 5736326の修正が必要です。

HTTPヘッダーでの代替戻り属性の使用

Oracle Identity FederationとOracle Access Managerを統合して認証を行う場合、WebGateが/fed/user/authnoam URLを保護し、Oracle Access Managerはユーザー識別子をHTTPヘッダーとしてOracle Identity Federationに渡すように構成されます。/fed/user/authnoam URLを保護するポリシーには認可ルールとアクションが含まれており、このアクションによって、LDAPユーザー・レコードのユーザーIDを参照する戻り属性を含むHTTPヘッダーが追加されます。この戻り属性は、「管理」→「データ・ストア」→「ユーザー・データ・ストア」セクションの順でOracle Identity Federationインスタンスに移動する場合にFusion Middleware Controlに設定される一意ユーザーIDと同じです。

不具合により、ユーザー識別子を含むHTTPヘッダーの戻り属性としてorclguidを使用することができません。回避策として、一意ユーザー識別子を別の属性に変更する必要があります。変更するには次の手順を実行します。

- Oracle Access Managerコンソールで、戻り属性を新しい属性(uidなど)に変更します。

- Fusion Middleware Controlで、Oracle Identity Federation管理→「データ・ストア」→「ユーザー・データ・ストア」の順に移動し、一意ユーザーIDを新しい属性(uidなど)に変更します。

- 他の認証エンジンを使用している場合は、その一意ユーザーID属性が正しく更新されていることを確認します。

- Oracle Access Manager SP統合モジュールを使用してOracle Identity FederationとOracle Access Managerを統合している場合は、次の手順を実行して統合を更新します。まず前述の変更を行ってからFusion Middleware ControlでOracle Identity Federationインスタンスに移動し、「管理」→「SP統合モジュール」→OAM SPエンジンの順に移動します。Oracle Access Managerの管理者資格証明を入力して、更新対象の作成済認証スキームを選択し、「Oracle Access Managerの構成」をクリックします。これにより、Oracle Access Managerのマッピング・ルールが新しい属性を反映するように更新されます。

3.2.4.3 SP統合モジュールとしてのOracle Access Managerの統合

このタスクによりSP統合モジュールとOracle Access Managerの相互作用が可能になります。

基本の手順は次のとおりです。

- 要件の確認

- Oracle Access Server SDKのインストール

- Oracle Access ManagerとOracle Access Server SDKの統合

- Oracle WebLogic Serverのクラスパスの更新

- Oracle Identity Federationの構成

- Oracle Identity FederationとOracle Access Managerの統合

- Oracle Identity FederationによるOracle Access Managerリソースの保護

要件の確認

次の手順を実行します。

1. Access Server SDK 10gがインストールされていることを確認します。

2. 高可用性(HA)環境では、Access Server SDKを別個のマシンにインストールして、異なるアクセス・ゲートとしてOracle Access Managerと統合する必要があります。

注意:
HA環境にデプロイする場合は、必ず『Oracle Fusion Middleware高可用性ガイド』のOracle Access Managerとの統合における高可用性の考慮事項に関する項に記載されている手順に目を通し、実行するようにしてください。
必ず、Access Server SDKのインストール先ディレクトリに関する指示に従い、すべての管理対象サーバーを再起動してください。

Oracle Access Server SDKのインストール

SDKがインストールされているディレクトリを参照するようにOracle Identity Federationを構成します。

SDKがドメイン・ホーム・ディレクトリにインストールされている場合は、ドメイン・ホーム・フォルダからの相対パスSDKを参照できます。SDKが別の場所にインストールされている場合は、絶対パスを使用してSDKフォルダを参照する必要があります。

HA環境でOracle Identity Federationを使用する場合は、Oracle Identity Federationがインストールされているそれぞれのマシンで同じディレクトリ名の相対パスを使用して、Access Server SDKをドメイン・ホーム・フォルダにインストールすることをお薦めします。このように、異なるOracle Identity Federationインスタンスが同じ構成を共有します。具体的にはAccess Server SDKがインストールされているディレクトリは、すべてのOracle Identity Federationインスタンスで同じ値になります。

Oracle Access ManagerとOracle Access Server SDKの統合

このタスクでは、新しいアクセス・ゲートをアクセス・サーバー・インスタンスに関連付けることができます。

Oracle Access Managerコンソールで、アクセス管理サービスを有効にして新しいアクセス・ゲートを作成し、アクセス・サーバー・インスタンスに関連付けます。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

configureアクセス・ゲートスクリプトを次のように呼び出して、Access Server SDKを統合します。

$ACCESS_SERVER_SDK/oblix/tools/configureAccessGate -i $ACCESS_SERVER_SDK -t AccessGate -w $ACCESS_GATE_ID -m open -h $ACCESS_SERVER_HOST -p $ACCESS_SERVER_PORT

次のように置き換えます。

- $ACCESS_SERVER_SDK: Access Server SDKディレクトリの絶対パス

- $ACCESS_GATE_ID: このアクセス・ゲートの識別子

- $ACCESS_SERVER_HOST: アクセス・サーバーがインストールされているマシンのホスト名

- $ACCESS_SERVER_PORT: アクセス・サーバーのポート

Oracle WebLogic Server環境の更新

Oracle Identity Federationが実行されている管理対象サーバーは、Oracle Access Managerとの統合に必要なJARファイルと共有ライブラリにアクセスできる必要があります。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

環境を更新する手順は次のとおりです。

1. 管理対象サーバーを停止します。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のWebLogic Serverの起動と停止に関する項。

2. jobaccess.jarファイルを$ASDK_DIR/oblix/libフォルダから$DOMAIN/libフォルダにコピーします。

3. 次の手順は、実行されているOracle Access Managerのバージョンによって異なります。

- 実行されているOracle Access Managerのバージョンが10.1.4.3以降で、管理対象サーバーをWebLogic管理コンソールから起動する場合は、次の手順に従います。

- WebLogic管理コンソールを開きます。

- 「サーバー」→「管理対象サーバー」→「構成」→「サーバーの起動」の順に移動します。

- 「引数」のテキスト・ボックスで、-Djava.library.pathを追加してASDK_DIR/oblix/libを含めます。

- 変更を保存します。

- 管理対象サーバーをコンソールから起動します。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

- 実行されているOracle Access Managerのバージョンが10.1.4.2以前、またはOracle Access Managerのバージョンが10.1.4.3で管理対象サーバーをコマンドラインから起動する場合は次の手順を実行します。

- jobaccess.jarファイルを$ASDK_DIR/oblix/libフォルダから$DOMAIN/libフォルダにコピーします。

- 管理対象サーバーを停止します。

- Linuxの場合は、ファイル$DOMAIN/bin/startManagedWebLogic.shを開きます。
次の行を追加します。

LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:accessSDK installdir/oblix/lib
export LD_LIBRARY_PATH

Oracle Access Managerのバージョンが10.1.4.2以前の場合は、次の2行も追加します。

LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL

- Windowsの場合は、ファイル$DOMAIN/bin/startManagedWebLogic.cmdを開きます。
次の行を追加します。

set PATH=%PATH%;AccessSDK_InstallDir/oblix/lib

- (管理コンソールではなく)コマンドラインから管理対象サーバーを起動します。

Oracle Identity Federationの構成

次の手順を実行します。

1. Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。

2. 「管理」→「サービス・プロバイダ統合モジュール」→「Oracle Access Manager」の順に移動します。

3. SPモジュールを有効にします。

4. SAMLアサーション(ユーザーに対してローカル・フェデレーション・レコードの作成が必要な場合などに必要)の処理時に使用する認証メカニズムを選択します。

5. Access Server SDKがインストールされているディレクトリを入力します。SDKが$DOMAIN_HOMEディレクトリにインストールされている場合は、そのフォルダへのパスを$DOMAIN_HOMEからの相対パスにできます。別のディレクトリにインストールされている場合は、絶対パスにする必要があります。

6. Oracle Identity Federationにユーザー・セッションを作成する際に、Oracle Identity Federationが使用するデフォルトの認証スキームを入力します。

7. Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインを入力します。

8. Oracle Identity Federationでは、Oracle Access ManagerのCookieを永続CookieまたはセッションCookieとして設定できます。永続Cookieの場合は、Cookieが有効になる時間を分単位で入力します。セッションCookieの場合は、0を入力します。

9. Cookieを保護するようにマークする必要があるかどうかを確認します。マークすると、ブラウザはCookieをHTTPS接続経由で送信します。

10. ログアウトを有効にする必要がある場合は、「ログアウト有効」ボックスを選択します(推奨)。

11. Oracle Access Managerドメインからユーザーがログアウトする際に、Oracle Identity FederationによってOracle Access ManagerのCookieをリセットする場合、「Cookieのクリア」ボックスを選択します。

12. Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択して、URLを入力します。

注意:
ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。
Oracle Access ManagerのログアウトURLに追加される問合せパラメータは、returnurlで参照します。

13. 変更を保存します。

注意:

- 保護対象のリソースには、WebgateでCookieドメインを設定する必要があります。Cookieドメインの例を次に示します。

.us.example.com

- Fusion Middleware Controlを使用してユーザー・データ・ストアを構成します。これは、Oracle Identity FederationがOracle Access Managerポリシー・サーバーでポリシー・オブジェクトを作成する際に使用します。
Fusion Middleware Controlを使用してユーザー・データ・ストアを変更する手順は次のとおりです。

- Oracle Identity FederationとOracle Access Managerの統合を再実行します。

- Oracle Identity FederationによってOracle Access Managerポリシー・サーバーに作成された既存の認証スキームを更新します。

Oracle Identity FederationとOracle Access Managerの統合

Oracle Identity Federationは着信SSOアサーションの処理およびユーザーの識別を行った後で、そのユーザーのOracle Access ManagerセッションをOracle Access Managerドメイン内に作成します。その際、Oracle Identity Federationは次のことを行います。

1. 構成時にOracle Identity Federationが作成したポリシー・ドメインを使用します。

2. Oracle Identity Federation認証メカニズム(ユーザーのチャレンジを行うためにIdPで使用される認証方式)を、構成時にOracle Identity Federationによって作成されたOracle Access Manager認証スキームにマップします。マップ先のOracle Access Manager認証スキームが存在しない場合は、Oracle Identity Federationの構成のセクションで入力したデフォルトの認証スキームが使用されます。

3. Oracle Access Managerと連携して、ユーザー・セッションを作成します。その際に、ユーザー・セッションのポリシー・ドメインと認証スキームを指定します。
Oracle Identity Federationに入力するポリシー・ドメイン名は、Oracle Identity Federationによって作成された既存のポリシー・ドメインを参照する必要があります。

4. ユーザーのブラウザでOracle Access ManagerのCookieを設定します。

統合を正しく行うためには、ポリシー・オブジェクトと認証スキームをOracle Access Managerに作成する必要があります。次の操作を実行します。

注意:
このタスクでは、Oracle Access Managerに対して適切な管理者資格証明を所有しているとことが前提になります。ポリシー・オブジェクトの作成時には、必ずOracle Access Managerのマスター管理者アカウントを使用してください。

関連項目:
Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g

関連項目:
画面の詳細は、第5.16.3項「SP統合モジュール - Oracle Access Manager 10g」を参照してください。

1. Fusion Middleware ControlでOracle Identity Federationインスタンスを見つけます。

2. 「管理」→「サービス・プロバイダ統合モジュール」→「Oracle Access Manager」の順に移動します。

3. 「Oracle Access Managerプロパティ」セクションを開きます。

4. Oracle Access Managerの資格証明を入力してOracle Access Managerを構成します。

注意:
資格証明が使用されるのは、「Oracle Access Managerの構成」ボタンをクリックしてOracle Access Managerサーバーに接続し、構成を行うときのみです。これらの資格証明はOracle Identity Federationの構成ファイルには保存されません。

5. ポリシー・ドメインの構成時にOracle Identity Federationが使用するホストIDを入力します。このホストIDは、Oracle Access Managerサーバーで定義します。ホストIDには、Oracle Identity Federationサーバーが使用するように構成されたホスト名:ポート情報とそのバリエーションを含める必要があります。

注意:
これは必須パラメータです。

6. ポリシー・ドメインの作成時に使用されるデフォルトの認証ルールを入力します。

7. 使用可能なOracle Identity Federation認証メカニズムは表にリストされています。それぞれの認証メカニズムにマップされている認証スキーム名と認証スキーム・レベルが表に記載されています。これらのマッピングは、デフォルトではOracle Identity Federationのみに保存されているため、Oracle Access Managerで作成、更新または削除するメカニズムとスキームを選択する必要があります。
作成するスキームを選択して、「Oracle Access Managerの構成」をクリックすると、指定されている名前とレベルでスキームが作成され、Oracle Identity Federationの構成の対応する認証メカニズムにマップされます。作成したスキームのいずれかを、Oracle Identity Federationで使用されるデフォルトのOracle Access Manager認証スキームとして選択する必要があります。デフォルトでは、この値はOracle Identity Federationによってパスワードで保護されます。そのため、デフォルトとして何も選択されてない場合は、パスワードで保護された認証スキームを選択して作成する必要があります。スキームを選択して削除すると、同様に、Oracle Access Managerからそのスキームが削除されます。スキームを選択して更新すると、Oracle Identity Federationで使用されるデフォルトのOracle Access Manager認証スキームとその名前がOracle Access Managerで更新されます。

注意:
ドメインで使用されている認証スキームは、サーバーで更新/削除できません。

8. 「Oracle Access Managerの構成」をクリックします。

Oracle Identity FederationによるOracle Access Managerリソースの保護

関連項目:
Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 10g

Oracle Identity FederationとOracle Access Managerを統合して認証スキームを作成すると、作成したスキームを使用してリソースを保護できるようになります。特定のスキームによってリソースを保護すると、次のように作用します。

1. 認証されていないユーザー(またはスキームの認証レベルよりも低いレベルの認証ユーザー)が、Oracle Identity Federation認証スキームで保護されているリソースにアクセスしようとすると、Oracle Access ManagerサーバーがそのユーザーをOracle Identity Federationにリダイレクトし、フェデレーションSSOが行われます。

2. Oracle Access Managerは、リクエストされたリソースと使用するOracle Identity Federation認証スキーム名をOracle Identity Federationに渡します。

3. Oracle Identity Federationは、その認証スキームを認証メカニズムにマップしてから、SAML/WS-Fed認証方式にマップします。

4. Oracle Identity Federationは、アイデンティティ・プロバイダにユーザーを送信し、ユーザーに認証を要求するために使用する認証方式を指定して、フェデレーションSSOフローを開始します。

5. IdPは、ユーザーの正当性を確認してアサーションを作成し、アサーションとともにユーザーをOracle Identity Federationに送り戻します。

6. Oracle Identity Federationは、このアサーションを処理する際に、ユーザーの認証に使用する方式をアサーションから抽出して認証メカニズムにマップします。

7. 処理が成功すると、Oracle Identity Federationが認証メカニズムを認証スキームにマップし、ユーザーのOracle Access Managerセッションを作成します。

8. Oracle Identity Federationが、リクエストされたリソースにユーザーをリダイレクトします。

9. 最後に、Oracle Access Managerが、認証ユーザーに対してリソースへのアクセスを許可します。

3.2.5 Oracle Access Managerに対するOracle Identity Federation/SPの認証

Oracle Identity Federationがサービス・プロバイダとして動作する場合、Oracle Access Managerユーザー・セッションの作成時に、Oracle Access Managerサーバーに対してOracle Identity Federation自身の認証を行うように構成できます。

このセクションの内容は次のとおりです。

- 認証の概要

- 既存のフェデレーション・スキームを使用した認証の有効化

- 新しいフェデレーション・スキームを作成する場合の認証の有効化

- Oracle Identity Federation資格証明の更新

- Oracle Access Managerに対する認証の無効化

3.2.5.1 認証の概要

この認証操作は、Oracle Identity FederationがOracle Access Managerフェデレーション認証スキームを使用してユーザー・セッションを作成する際に、Oracle Identity Federationをホストするマシンにインストールされているアクセス・ゲートを介して行われます。

この操作では、スキームを呼び出すモジュールが確実にOracle Identity Federationサーバーであること、またそれ以外のプロセスによってそのスキームが使用されないことが保証されます。

操作フロー

デプロイメントおよび実行時のフローは次のとおりです。

1. Oracle Identity Federation管理者がFusion Middleware Controlを使用して、Oracle Access Managerフェデレーション・スキームを作成または既存のOracle Access Managerフェデレーション・スキームを更新し、2つの新しいプラグインを追加します。

2. Oracle Identity Federation管理者がFusion Middleware Controlを使用して、必要な資格証明をOIFに指定します。

3. 実行時に、Oracle Identity Federationがこの資格証明とともに、Oracle Access Managerユーザー・セッションの作成に使用されるデータを渡します。

4. Oracle Access Managerサーバーが、LDAPユーザー・リポジトリに対してOracle Identity Federation資格証明の検証を行います。

5. Oracle Identity Federation資格証明の検証後に、Oracle Access Managerユーザー・セッションが作成されます。

LDAPアカウントのカスタマイズ

管理者は次の内容を選択することにより、Oracle Identity Federation資格証明の検証に使用されるLDAPアカウントをカスタマイズできます。

- エントリの場所(つまり、ユーザーのブランチとは異なる場所)

- エントリのオブジェクト・クラス

認可されたサーバーによる認証の呼出し

セキュリティ上の理由により、フェデレーション・スキームのcredential_mappingプラグインにOracle Identity Federationのユーザー名を設定できます。これにより、このスキームの呼出し時にそのアカウントに対応するユーザーのみが使用されることが保証されます。

この機能はオプションですが、有効にすることで認可されたOracle Identity Federationサーバーに限定してフェデレーション認証スキームを呼び出すことができます。

3.2.5.2 既存のフェデレーション・スキームを使用した認証の有効化

ここでの前提は次のとおりです。

- Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。

- Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされていません。

- アクセス・サーバーに作成されているフェデレーション・スキームはすべて、Oracle Identity FederationがOracle Access Managerの認証を行うようには構成されていません。

構成には次の操作が必要です。

- Oracle Identity Federation認証に使用するアカウントをLDAPディレクトリに作成します。

- Fusion Middleware Controlを使用して、Oracle Identity Federationアカウント情報を設定し、認証を有効にします。

- Fusion Middleware Controlを使用して、既存のすべてのフェデレーション・スキームを更新し、新しいOracle Access Managerプラグインを定義します。

- Oracle Access Managerコンソールを使用して、既存のすべてのフェデレーション・スキームを更新し、新しいプラグインに対する新しい認証フローを定義します。

LDAPエントリの作成

フェデレーション・スキームを使用する場合に、Oracle Identity FederationからOracle Access Managerへの認証を可能にするために、Oracle Identity Federation資格証明の検証時に使用するエントリをLDAPディレクトリに含める必要があります。そのようなエントリが存在しない場合は、識別子に基づいて双方からの検索が可能で、パスワード属性を持つエントリを作成します。Fusion Middleware Controlを使用して、次のものを設定します。

- 識別子

- パスワード

- エントリのベースDN

- エントリのオブジェクト・クラス

- 識別子を格納する属性

次の選択が可能です。

- すべてのユーザー・レコードが位置するブランチとは異なるエントリの場所

- ユーザー・レコード・タイプとは異なるオブジェクト・クラス

Oracle Identity Federationアカウント情報の設定

フェデレーション・スキームの呼出し時に、資格証明を示すようにOracle Identity Federationを構成するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. チェック・ボックスを選択してOracle Identity Federation認証を有効にします。

4. Oracle Identity Federation認証に使用するアカウントのユーザー名とパスワードを入力します。

5. Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを入力します。

6. Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを入力します。

7. ユーザー名を含める、検索可能なLDAPエントリ属性を入力します(LDAPエントリで定義されている場合は、uidなど)。

新しいプラグインの定義

次に、既存のフェデレーション・スキームを更新して、認証操作に使用する2つの新しいプラグインを組み込みます。次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. Oracle Access Managerに作成されているすべてのフェデレーション・スキームを選択して「更新」をクリックします。

4. Oracle Access Manager管理者資格証明を入力して、Oracle Access Managerサーバーで管理用更新処理を実行できるようにします。

5. 「Oracle Access Managerの構成」をクリックします。

これによりスキームが更新され、次の2つの新しいプラグインが組み込まれます。

- credential_mappingプラグイン。Oracle Identity Federationアカウントを検索する際に使用されます。

- validate_passwordプラグイン。Oracle Identity Federationの任意のアカウントに指定されているパスワードを検証する際に使用されます。

新しい認証フローの定義

アクセス・サーバーの制限により、前述の手順で作成した新しいプラグインを組み込むための新しい認証フローを作成する際に、Fusion Middleware Controlを使用することができません。かわりに、Oracle Access Managerコンソールを使用して、それらのオブジェクトを作成する必要があります。

更新したそれぞれのフェデレーション・スキームに対して、次のアクションを実行します。

1. Oracle Access Managerコンソールに管理者としてログインします。

2. 「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」の順に移動します。

3. 更新するフェデレーション・スキームを選択します。

4. 「ステップ」タブをクリックします。

5. 「追加」をクリックして、新しいステップを追加します。

6. 「ステップ名」フィールドにステップの名前を入力します。

7. 「使用可能なプラグイン」表で、次の順序で手順を実行します。

注意:
この順序が重要です。

1. 2つ目のcredential_mappingプラグインを選択して、「追加」をクリックします。

2. validate_passwordプラグインを選択して、「追加」をクリックします。

3. 1つ目のcredential_mappingプラグインを選択して、「追加」をクリックします。

8. 「保存」をクリックします。

9. 「認証フロー」タブをクリックします。

10. 「変更」をクリックします。

11. 新しいステップを「開始ステップ」として選択します。

12. 「成功時の次のステップ」で「停止」を選択します。

13. 「失敗時の次のステップ」で「停止」を選択します。

14. 「保存」をクリックします。

15. 「ステップ」タブをクリックします。

16. 古いステップを選択します。「削除」をクリックします。

3.2.5.3 新しいフェデレーション・スキームを作成する場合の認証の有効化

この構成では次の前提に対応しています。

- Oracle Identity Federationがすでにデプロイされ、Oracle Access Managerと統合されているか、またはOracle Identity Federationがデプロイされているが、Oracle Access Managerとまだ統合されていない状態です。

- Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされていません。

- アクセス・サーバーにはフェデレーション・スキームが作成されていません。

これには次のタスクが含まれます。

- Oracle Identity Federation認証に使用するアカウントをLDAPディレクトリに作成します。

- Oracle Identity Federationのアカウントに関する情報、および新しい認証スキームの作成で必要になると想定されるOracle Identity Federation/Oracle Access Manager統合に関する情報をFusion Middleware Controlで設定します。

- Fusion Middleware Controlを使用して、新しいフェデレーション・スキームを作成します。

LDAPアカウントの作成

フェデレーション・スキームを使用する場合に、Oracle Identity FederationからOracle Access Managerへの認証を可能にするために、Oracle Identity Federation資格証明の検証時に使用するエントリをLDAPディレクトリに含める必要があります。そのようなエントリが存在しない場合は、識別子に基づいて双方からの検索が可能で、パスワード属性を持つエントリを作成する必要があります。Fusion Middleware Controlを使用して、次のものを設定します。

- 識別子

- パスワード

- エントリのベースDN

- エントリのオブジェクト・クラス

- 識別子を格納する属性

次の選択が可能です。

- すべてのユーザー・レコードが位置するブランチとは異なるエントリの場所

- ユーザー・レコード・タイプとは異なるオブジェクト・クラス

Oracle Identity Federationアカウント情報の設定

フェデレーション・スキームの呼出し時に、資格証明を示すようにOracle Identity Federationを構成するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. Oracle Identity Federation認証を有効にします。

4. Oracle Identity Federation認証に使用するアカウントのユーザー名とパスワードを入力します。

5. Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを入力します。

6. Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを入力します。

7. ユーザー名を含める、検索可能なLDAPエントリ属性を入力します(LDAPエントリで定義されている場合は、uidなど)。

8. 必要に応じてOracle Access Managerの残りのフィールドを構成し、「Oracle Access Managerの構成」をクリックして変更を適用します。

この後に作成されるフェデレーション・スキームには、実行時のOracle Identity Federationの認証に必要な情報が含まれます。フェデレーション認証スキームを更新するために、Oracle Access Managerコンソールで手動で操作する必要はありません。

3.2.5.4 Oracle Identity Federation資格証明の更新

ここでの前提は次のとおりです。

- Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。

- Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされています。

- フェデレーション・スキームが存在し、実行時にOracle Identity Federation認証を実行するように構成されています。

Oracle Identity Federation資格証明を更新すると、フェデレーション・スキームに対して次のような更新が必要になる場合があります。

- Oracle Identity Federationパスワードのみが更新されている場合は、フェデレーション・スキームを変更しなくても構いません。

- パスワード以外のOracle Identity Federationアカウントに関する情報(オブジェクト・クラス、ベースDN、ユーザー名など)が更新されている場合は、すべてのフェデレーション・スキームを更新する必要があります。

Oracle Identity Federationパスワードのみの更新

Oracle Identity Federationパスワードのみを更新する場合は、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. Oracle Identity Federation認証に使用するアカウントのパスワードを入力します。

4. 「Oracle Access Managerの構成」をクリックして変更を適用します。

パスワード以外のデータの更新

Oracle Identity Federationパスワード以外の情報を更新する場合は、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. Oracle Identity Federation認証に使用するアカウントのユーザー名またはパスワード、あるいはその両方を更新します(任意)。

4. Oracle Identity Federationのアカウントが位置する場所を参照するベースDNを更新します(任意)。

5. Oracle Identity Federation認証に使用するLDAPエントリのオブジェクト・クラスを更新します(任意)。

6. ユーザー名が格納される検索可能なLDAPエントリ属性(LDAPエントリで定義されている場合は、uidなど)を更新します(任意)。

7. Oracle Access Managerに作成されているすべてのフェデレーション・スキームを選択して「更新」をクリックします。

8. Oracle Access Manager管理者資格証明を入力して、Oracle Access Managerサーバーで管理用更新処理を実行できるようにします。

9. 「Oracle Access Managerの構成」をクリックします。

これで、フェデレーション・スキームのcredential_mappingプラグインに更新された情報が組み込まれ、Oracle Identity Federationの認証処理で使用されるようになりました。

3.2.5.5 Oracle Access Managerに対する認証の無効化

ここでの前提は次のとおりです。

- Oracle Identity Federationはすでにデプロイされており、Oracle Access Managerと統合されています。

- Oracle Identity FederationにはOracle Access Managerへの認証用の構成がされています。

- フェデレーション・スキームが存在し、実行時にOracle Identity Federation認証を実行するように構成されています。

これらのタスクには次が含まれます。

- 既存のフェデレーション・スキームを更新して、Oracle Identity Federation認証に関連するオブジェクトを削除します。

- Fusion Middleware Controlを使用して、Oracle Identity Federation認証を無効にします。

既存のフェデレーション・スキームの更新

この手順では、Oracle Identity Federation認証で不要となったフェデレーション・スキームを更新します。この処理を行わない場合、スキームは引き続き資格証明を受け入れようとしますが、これ以降、Oracle Identity Federationから資格証明が送信されることはありません。

更新したそれぞれのフェデレーション・スキームに対して、次の手順を実行します。

1. 「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」の順に移動します。

2. 更新するフェデレーション・スキームを選択します。

3. 「ステップ」タブを選択します。

4. 「追加」をクリックして、新しいステップを追加します。

5. 「ステップ名」フィールドにステップの名前を入力します。

6. 次の手順は、Oracle Identity Federation認証を有効にしたタイミング(このスキームの作成前か後か)によって異なります。

- プラグインの順序が、credential_mapping、validate_password、credential_mappingの場合は、最後のcredential_mappingプラグインを選択して「追加」をクリックします。

- プラグインの順序が、credential_mapping、credential_mapping、validate_passwordの場合は、最初のcredential_mappingプラグインを選択して「追加」をクリックします。

7. 「保存」をクリックします。

8. 「認証フロー」タブをクリックします。

9. 「変更」をクリックします。

10. 新しいステップを「開始ステップ」として選択します。

11. 「成功時の次のステップ」で「停止」を選択します。

12. 「失敗時の次のステップ」で「停止」を選択します。

13. 「保存」をクリックします。

14. 「ステップ」タブをクリックします。

15. 古いステップを選択します。「削除」をクリックします。

16. 「プラグイン」タブをクリックします。

17. 「変更」をクリックします。

18. Oracle Identity Federationユーザー名が指定されているプラグイン・パラメータを持つ、validate_passwordプラグインとcredential_mappingプラグインを選択します。

19. 「削除」→「保存」の順にクリックします。

このアクションの後には、プラグイン・パラメータに文字列%OIFUSERID%を含むcredential_mappingプラグインのみが残ります。

Oracle Identity Federation認証の無効化

認証を無効にするには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「SP統合モジュール」→「Oracle Access Manager」の順に移動します。

3. Oracle Identity Federation認証を無効にします。

4. 「Oracle Access Managerの構成」をクリックして変更を適用します。

このアクションの後は、フェデレーション・スキームを呼び出しても、Oracle Identity Federationから認証用の資格証明が送信されることはなくなります。

Oracle Identity Federationの再有効化

Oracle Access ManagerへのOracle Identity Federation認証を無効にした後で再び有効にするには、第3.2.5.2「既存のフェデレーション・スキームを使用した認証の有効化」の手順に従います。

3.2.6 Oracle Identity FederationとOracle Directory Server Enterprise Editionのデプロイ

この項では、Oracle Directory Server Enterprise Edition(以前のSun Java System Web Server)とOracle Identity Federationを統合して、Webプロキシとして動作させる方法について説明します。

この項には、次の項目が含まれます。

- 要件

- Webプロキシ・サーバーを使用しないOracle Identity Federationの構成

- Webプロキシ・サーバーの背後へのOracle Identity Federationの構成

- アイデンティティ・サーバーおよびアクセス管理サーバーの更新

- Oracle Directory Server Enterprise Edition構成ファイルのサンプル

3.2.6.1 要件

Oracle Identity Federationの前面でプロキシを使用する場合は、プロキシ・サーバー・インスタンスのホスト名とポート番号が、Oracle Identity Federationへのアクセスに使用され、Oracle Identity Federationの構成に設定されます。

3.2.6.2 Webプロキシ・サーバーを使用しないOracle Identity Federationの構成

まずOracle Identity Federationをインストールして構成し、デプロイメントで必要なバックエンド(LDAP、RDBMS、Oracle Access Managerなど)と統合します。内容は次のとおりです。

- Oracle Identity FederationをSSO SAMLプロトコル用に構成します。

- Oracle Identity Federationのフェデレーションに信頼できるプロバイダを追加します。

- Oracle Identity Federationとバックエンドの統合

関連項目:

- 第4章「サーバー管理」

- 第5章「Oracle Identity Federationの構成」

3.2.6.3 Webプロキシ・サーバーの背後へのOracle Identity Federationの構成

Webプロキシ・サーバーの背後にOracle Identity Federationを構成する場合の手順は、次を除いて、Webプロキシ・サーバーを使用しない環境で実行した手順(第3.2.6.2項「Webプロキシ・サーバーを使用しないOracle Identity Federationの構成」を参照)と同じです。

- Webプロキシ・サーバーは、Oracle Identity Federationを参照するように構成されます。

- Oracle Identity Federationの構成は、Webプロキシ・サーバーのホスト名とポート情報を使用します。

標準的な手順(第3.2.6.2項「Webプロキシ・サーバーを使用しないOracle Identity Federationの構成」を参照)に従ってOracle Identity Federationを構成しますが、次の点を変更します。

- 構成URLを各構成のプロキシ・サーバーのURLに変更します。
Fusion Middleware Controlで、「管理」→「サーバー・プロパティ」の順に移動します。

- 実際のURLではなくプロキシのURLを使用してメタデータを収集した後で、そのメタデータをアップロードします。
「管理」→「セキュリティおよび信頼」の順に移動し、メタデータを取得します(メタデータのホスト名/ポート情報に新しい値が使用されるようになります)。リモート・プロバイダにメタデータを配布します。

- アクセス・システム・コンソールで、ホスト識別子を次の形式で作成します。

proxy-host:port

次に、認証スキームのチャレンジ・リダイレクトをproxy-host:portに変更します。

関連項目:
第5.2項「サーバー・プロパティの構成」および第5.10項「セキュリティおよび信頼の構成」

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

Sun Oneプロキシ・サーバーのOracle Identity Federation用構成の詳細は、『Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server』のobj.confファイルの変更に関するガイドラインを参照してください。

3.2.6.4 アイデンティティ・サーバーおよびアクセス管理サーバーの更新

これでユーザーはWebサーバー・プロキシを経由してOracle Identity Federationにアクセスできるため、Oracle Access ManagerなどのIAMサーバーも同様に、ローカルのOracle Identity Federationマシンではなくプロキシを参照するように更新する必要があります。

Oracle Identity Federation(Oracle Access ManagerやOracle Single Sign-Onなど)を参照するバックエンドに移動し、Oracle Identity Federationがインストールされているローカル・マシンのかわりにWebプロキシ・サーバーのホスト名/ポートの値を使用するように構成を更新します。

3.2.6.5 Oracle Directory Server Enterprise Edition構成ファイルのサンプル

Webプロキシ・サーバーは、Oracle Identity FederationがインストールされているマシンにHTTPリクエストを転送する必要があります。

この項では、obj.confおよびmagnus.conf構成ファイルのサンプルを示します。

サンプルのobj.confファイル

<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
NameTrans fn="assign-name" from="/*" name="serverexample"
NameTrans fn="ntrans-j2ee" name="j2ee"
NameTrans fn=pfx2dir from=/mc-icons dir="/home/pfx/SunOne6.1/ns-icons" name="es-internal"
NameTrans fn=document-root root="$docroot"
PathCheck fn=unix-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html,index.jsp"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap
Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file
Service method=TRACE fn=service-trace
Error fn="error-j2ee"
AddLog fn=flex-log name="access"
</Object>

<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>

<Object name="cgi">
ObjectType fn=force-type type=magnus-internal/cgi
Service fn=send-cgi user="$user" group="$group" chroot="$chroot" dir="$dir"
nice="$nice"
</Object>

<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal"
</Object>

<Object name="send-compressed">
PathCheck fn="find-compressed"
</Object>

<Object name="compress-on-demand">
Output fn="insert-filter" filter="http-compression"
</Object>

# Execute these instructions for any resource with the assigned name
# "server.example.com"
<Object name="serverexample">
# Proxy the requested resource to the URL
# "http://server.example.com:8080"
Service fn="service-passthrough" servers="http://unit1.mycorp.co.in:1234"
</Object>

サンプルのmagnus.confファイル

#
# The NetsiteRoot, ServerName, and ServerID directives are DEPRECATED.
# They will not be supported in future releases of the Web Server.
NetsiteRoot /home/pfx/SunOne6.1
ServerName calgary
ServerID https-oif_idp_flagstaff
#
RqThrottle 128
DNS off
Security off
PidLog /home/pfx/SunOne6.1/https-oif_idp_flagstaff/logs/pid
User pfx
StackSize 131072
TempDir /tmp/https-oif_idp_flagstaff-65cd125c

Init fn=flex-init access="$accesslog" format.access="%Ses->client.ip%
- %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\"
%Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%"
Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/lib/libj2eeplugin.so" shlib_flags="(global|now)"
Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/passthrough/plugins/passthrough
/libpassthrough.so"

3.2.7 テストSPエンジンの使用

Oracle Identity Federationには、シングル・サインオンのテスト用としてテストSPエンジンが用意されています。後続の項では、テストSPエンジンの使用方法について説明します。

- テストSPエンジンの構成

- SPが開始するSSOでのテストSPエンジンの使用

- IdPが開始するSSOでのテストSPエンジンの使用

- テストSPエンジンの結果

注意:
本番環境では、テストSPエンジンを無効にする必要があります。

3.2.7.1 テストSPエンジンの構成

テストSPエンジンを有効/無効にするには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ統合モジュール」の順に移動します。

3. 「SPエンジンのテスト」タブで、エンジンの有効化を選択/選択解除します。

テストSPエンジンをデフォルトのSPエンジンにするには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ統合モジュール」の順に移動します。

3. 「デフォルトSP統合モジュール」で、テストSPを選択します(注意: テストSPエンジンを有効にする必要があります)。

関連項目:
第5.15項「認証エンジンの構成」

3.2.7.2 SPが開始するSSOでのテストSPエンジンの使用

テスト・エンジンを使用するには、次のURLでシングル・サインオン・フローを開始します。

HTTP://OIF-SP-HOST:OIF-SP-PORT/fed/user/testspsso

ここで、

- HTTPは、オープン接続の場合はhttp、セキュア接続の場合はhttpsです。

- OIF-SP-HOSTは、Oracle Identity Federationサービス・プロバイダ・サーバーのホスト名です。

- OIF-SP-PORTは、Oracle Identity Federationサービス・プロバイダ・サーバーのhttpまたはhttpsポート番号です。ポート80またはポート443に対しては、入力を省略します。

「SSOの開始」ボタンをクリックすると、ページで指定した情報でシングル・サインオンが開始されるようにOracle Identity Federationサービス・プロバイダにリクエストが送信されます(つまり、アイデンティティ・プロバイダに認証リクエストが送信されます)。次のパラメータを指定できます。

- IdPプロバイダID: サービス・プロバイダが認証リクエストを送信するアイデンティティ・プロバイダのプロバイダIDまたは説明です。

- 認証リクエスト・バインディング: サービス・プロバイダのバインディングを認証リクエストの送信に使用するように指定します。SAML 2.0プロトコルにのみ適用されます。

- 強制認証: 選択した場合、以前の認証コンテキストを信頼するかわりに、アイデンティティ・プロバイダが強制的にユーザーを認証します。SAML 2.0およびWS-Fedプロトコルにのみ適用されます。

- パッシブ: 選択した場合、アイデンティティ・プロバイダとユーザーとの対話は行われません。SAML 2.0プロトコルにのみ適用されます。

- リレー状態: このフィールドには任意の文字列を入力できます。これは、リクエストの識別子または戻りURLのいずれかです。Oracle Sign-Onフローが実行された後にリレー状態として返されます。

- デフォルト構成を使用: 選択した場合、Oracle Identity Federationは次のプロパティに対してデフォルトの構成を使用します。

- フェデレーション作成を許可

- SSOレスポンス・バインディング

- 名前IDフォーマット

- リクエストされた認証メカニズム

- 認証メカニズムの比較

選択しない場合は、次が適用されます。

- フェデレーション作成を許可: 選択しない場合は、ユーザーのフェデレーションが存在しない場合でも、アイデンティティ・プロバイダはフェデレーションを作成しません。SAML 2.0プロトコルにのみ適用されます。

- SSOレスポンス・バインディング: アイデンティティ・プロバイダがサービス・プロバイダにレスポンスを送信する際に使用するバインディングを指定します。SAMLプロトコルにのみ適用されます。

- 名前IDフォーマット: ここで指定する名前IDフォーマットは、ユーザーのフェデレーションの検索時または作成時にアイデンティティ・プロバイダが使用するようにサービス・プロバイダによってリクエストされます。SAML 2.0プロトコルにのみ適用されます。

- リクエストされた認証メカニズム: サービス・プロバイダが使用するローカル認証メカニズムを指定します。サービス・プロバイダはこのローカル・メカニズムをプロトコル固有の方式にマップし、アイデンティティ・プロバイダに対して認証リクエストでこの方式を指定します。(第5.14.1項「認証メカニズムについて」を参照してください。)SAML 2.0およびWS-Fedプロトコルにのみ適用されます。

- 認証メカニズムの比較: SAML 2.0を使用している場合は、使用する認証メカニズムをアイデンティティ・プロバイダが決定する際に使用するコンパレータを指定します。オプションは次のとおりです。

- EXACT: アイデンティティ・プロバイダは、リクエストされた認証メカニズムを使用する必要があります。

- MINIMUM: アイデンティティ・プロバイダは、最低でもリクエストされた認証メカニズムと同じ強度のメカニズムを使用する必要があります。

- BETTER: アイデンティティ・プロバイダは、リクエストされた認証メカニズムよりも高い強度のメカニズムを使用する必要があります。

- MAXIMUM: アイデンティティ・プロバイダは、リクエストされた認証メカニズムの強度の範囲内で、可能なかぎり強いメカニズムを使用する必要があります。

3.2.7.3 IdPが開始するSSOでのテストSPエンジンの使用

IdPが開始するシングル・サインオンをテストするためにテストSPエンジンを使用することもできます。サービス・プロバイダでは、テストSPエンジンを有効にし、テストSPをデフォルトSPエンジンとして構成した後で、IdPが開始するSSOをアイデンティティ・プロバイダから開始するだけです。テストSPエンジンにはシングル・サインオン処理の結果が表示されます。

3.2.7.4 テストSPエンジンの結果

シングル・サインオンを実行すると、次のような操作の結果がテストSPエンジンに表示されます。

- SSO認証結果: 操作が成功したかどうか。

- ユーザー識別子: シングル・サインオンが行われたユーザーのユーザーID。

- 認証インスタント: ユーザーを認証したアイデンティティ・プロバイダのインスタント。

- セッション失効インスタント: ユーザー・セッションが無効になるインスタント。

- 認証メカニズム: ユーザーの認証に使用されたローカル・メカニズム。

- SSOプライマリ・ステータス・コード: アイデンティティ・プロバイダから受信したアサーションのプライマリ・ステータス・コード。

- SSOセカンダリ・ステータス・コード: アイデンティティ・プロバイダから受信したアサーションのセカンダリ・ステータス・コード。

- SSOステータス・メッセージ: アイデンティティ・プロバイダから受信したアサーションのステータス・メッセージ。

- IdPプロバイダID: ユーザーを認証したアイデンティティ・プロバイダのプロバイダID。

- アイデンティティ・プロバイダから受信したアサーションに含まれる属性のリスト。次のとおりです。

- orafed-providerid: ユーザーを認証したアイデンティティ・プロバイダのプロバイダID。

- orafed-nameid-format: ユーザー・フェデレーションの名前IDフォーマット。

- orafed-nameid-value: ユーザー・フェデレーションの名前ID。

- orafed-assertionid: アイデンティティ・プロバイダから受信したアサーションのID。

- アイデンティティ・プロバイダから受信したアサーションに含まれる任意のユーザー属性。

3.3 アップグレード後の管理

この項では、Oracle Identity Federationのアップグレード後に管理者が行う必要のあるアクションについて説明します。

3.3.1 11gサーバー署名証明書

リリース10gから11gへのアップグレード時に、アップグレード・アシスタントによって、Oracle Identity Federation 10g Liberty/SAML2.0署名鍵/証明書が、SAML2.0/SAML1.x/WS-Fed操作で使用するOracle Identity Federation 11gインスタンスの署名証明書として移行されます。

SAML 1.x/WS-Fedメッセージの署名にOracle Identity Federation 10gサーバーを使用していた場合、次の2つのオプションがあります。

- SAML1.x/WS-Fed鍵/証明書を、すべてのプロトコル(SAML2.0/SAML1.x/WS-Fed)のOracle Identity Federation 11g署名鍵/証明書として維持します。
これを実装するには、10gキーストアを11g署名キーストアとしてアップロードします。10gキーストアは、Oracle Identity Federation管理コンソールの「SAML 1.x/WSフェデレーション」→「署名者」にあります。11gキーストアは、Fusion Middleware ControlでOracle Identity Federationインスタンスに移動すると、「セキュリティおよび信頼」セクションにあります。

変更後にSAML2.0メタデータをリモート・パートナに再分配して、新しい署名証明書をパートナが使用できるようにする必要があります。

- SAML 2.0署名鍵/証明書を、Oracle Identity Federation 11gサーバーの署名鍵/証明書として維持します。
これを実装するには、すべてのSAML 1.x/WS-Fedパートナに対して新しい署名証明書を提供する必要があります。

第II部

Oracle Identity Federationの管理

第II部では、Oracle Identity Federationの管理に関する内容で構成されています。

第II部は、次の章で構成されています。

- 第4章「サーバー管理」

- 第5章「Oracle Identity Federationの構成」

- 第6章「その他のサーバー構成」

- 第7章「診断および監視」

- 第8章「セキュリティ」

- 第9章「Oracle Identity Federationコマンドライン・ツール」

4 サーバー管理

この章では、Oracle Identity Federationの日常の管理タスクと、管理者が場合によって実行する必要があるその他のタスクについて説明します。内容は次のとおりです。

- 基本管理

- 一般的なタスク

- アイデンティティ・フェデレーションの管理

- アイデンティティの構成

- Oracle Identity Federationの資格証明の管理

4.1 基本管理

この項では、Oracle Identity Federationの基本的な管理について説明します。内容は次のとおりです。

- Oracle Identity Federationサーバー管理者について

- Oracle Identity Federationの管理

- Oracle Identity Federationのログ・ファイル

- バックアップ

4.1.1 Oracle Identity Federationサーバー管理者について

Oracle Identity Federationの管理者は、次の2つの主要なタスクを実行します。

- サーバー実行時の基本管理。サーバーの起動、停止、監視など

- フェデレーテッドID管理。ユーザー管理(ユーザーの作成、削除およびフェデレーション)、および信頼できるプロバイダやそのプロバイダと連携しているユーザーについての情報の維持

この項は次のトピックで構成されています。

- ロールについて

- デプロイメントの計画

- 他の計画タスク

4.1.1.1 ロールについて

Oracle WebLogic Serverでは、Oracle WebLogic Serverで設定されるセキュリティ・レルムに次のような特定のグローバル・ロールが定義されています。

- Admin(デフォルトでAdministratorsグループが含まれています)

- Operator(デフォルトでOperatorsグループが含まれています)

- Monitor(デフォルトでMonitorsグループが含まれています)

関連項目:
Oracle Fusion Middleware Oracle WebLogic Serverのロールとポリシーを使用したリソースの保護のユーザー・ロール、グループ・ロール、およびセキュリティ・ロールに関する項

ドメイン管理者は、FederationAdminロールを作成して、Admin、Operator、Monitor以外のユーザーにOracle Identity Federation管理者アクセス権を付与できます。

注意:
FederationAdminロールは、WLSTコマンドと他のJMX MBeanクライアントでのみ認識されます。Fusion Middleware Controlでは認識されません。これは、FederationAdminロールを持つユーザーは、Fusion Middleware Controlではなく、WLSTまたは他のJMXクライアントを使用した場合にのみOracle Identity Federationを構成できるということです。

4.1.1.2 デプロイメントの計画

信頼できるソースと宛先から構成されたネットワークにOracle Identity Federationをデプロイする場合、情報を他のサイト管理者と交換して、それに応じてアイデンティティ・プロバイダとサービス・プロバイダを構成する必要があります。

関連項目:

- サーバー・プロパティの詳細は、第5章「Oracle Identity Federationの構成」を参照してください。

- 信頼できるプロバイダの詳細は、第4.3項「アイデンティティ・フェデレーションの管理」を参照してください。

ユーザーIDの交換

フェデレーテッド環境では、最も単純な場合、サービス・プロバイダはID情報のコンシューマ、アイデンティティ・プロバイダ(ユーザー・リクエストの発生源)はID情報のサプライヤになります。アイデンティティ・プロバイダも、必要な資格証明を取得するために認証および認可メカニズム(AAAシステム)と通信する場面では、コンシューマの立場をとることがあります。必須ではありませんが、サービス・プロバイダもユーザーを宛先のIDにマップすると好都合なことがあります。IDサプライヤとコンシューマは実行時にデータを交換できる必要があります。このため、プリンシパルを一意に識別する手段として宛先が信頼することができる、プリンシパルに関するなんらかのID情報をソースが宣言することになります。

アイデンティティ・プロバイダは、パートナ・サイト管理者と連携する中で、自ドメインの関連ユーザーのリストを提供する場合があります。これはオプションの情報交換です。

クロスドメインの信頼の確立

Oracle Identity Federationでは、Libertyメタデータの仕様およびSAML 2.0メタデータの仕様に準拠したプロバイダ・メタデータを生成し使用できます。さらに、Oracle Identity Federationでは、SAML 2.0クエリ・リクエスタ用のメタデータ拡張機能を使用するプロバイダ・メタデータをインポートする機能をサポートしています。

クロスドメインの信頼を確立するには、認証を設定し、信頼できるソースと宛先のネットワークでキーや証明書を交換する必要があります。

初回の設定とテストでは、アイデンティティ・プロバイダおよびサービス・プロバイダはどちらもデフォルトの自己署名証明書を使用できます。ただし、本番に移行する際は、使用タイプを検討して自己署名の証明書で十分かどうかを決定してください。エンティティ間に事前の信頼関係がない場合、たとえばインターネット経由でSSLを使用してWebサイトにアクセスする場合は、CA発行の証明書が最も有効です。しかし、フェデレーション・ピア間の信頼関係がメタデータまたは同等のもの(ピア証明書などで、通常はピア証明書が使用される)の交換を必要とする場合、ピア証明書の取得方法を信頼できるかぎり、本番デプロイメントでも自己署名証明書で十分です。CA発行の証明書は、メタデータの交換、たとえば署名された電子メールやSSL経由でのWebサーバーからのダウンロードで使用されることがあるので注意してください。

メタデータを使用すると、クロスドメインの信頼を設定するプロセスを簡単にできます。Oracle Identity Federationではプロバイダ固有のメタデータを格納できます。これにより、グローバルなIdPおよびSP設定が、各ピア・プロバイダとの通信に固有なデータに上書きされます。

PKIおよびSSL暗号化

Oracle Identity Federationは、.509証明書認証を使用する、セキュアな通信を提供します。

Oracle Identity Federationでは、公開鍵と秘密鍵のペアを使用する技術である公開鍵暗号を使用してデータの整合性を確保します。データは送信元で、秘密鍵を使用して署名され、受信者はその署名を、送信者の公開鍵を使用して検証します。

Oracle Identity Federationは、証明書と呼ばれるドキュメントを使用して、ピア・プロバイダ同士が信頼を確立できるようにします。認証局(CA)が証明書を発行してユーザーのアイデンティティを保証します。受信者が使用する公開鍵も証明書に含まれています。

キー・ペアと証明書は、ローカル・キーストアを使用して構成します。アイデンティティ・プロバイダは、POSTプロファイルを使用する場合、公開鍵と秘密鍵のペアと証明書を構成します。公開鍵は認証局(CA)により検証されます。IdPが公開鍵を提示し、SPが証明書を取り込む過程は、パートナ間の信頼関係を管理する上での重要な局面です。

SSL接続を実装することもできます。SSL接続とクライアント証明書を構成する方法の詳細は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

注意:
SSL機能はOracle Identity Federationの外部から提供される機能です。

4.1.1.3 他の計画タスク

IDの交換やそれらのIDがかかわる通信の安全性を確保する他に、フェデレーテッド・ネットワークに関係する計画がある場合は、次のような項目についても合意する必要があります。

- フェデレーション・プロトコル

- サービス

- プロファイル

ネットワークの参加者と連携して、様々なIdPやSPがビジネス・パートナの設定を理解し、フェデレーションが正しく機能するようにする必要があります。

4.1.2 Oracle Identity Federationの管理

Oracle Identity Federationサーバーの管理にはOracle Fusion Middlewareの管理ツールを使用します。詳細は『Oracle Fusion Middleware管理者ガイド』の次の項を参照してください。

- Oracle Enterprise Manager Fusion Middleware Controlの使用の概要

- コマンドライン・ツールの使用の概要

- Fusion Middleware Control MBeanブラウザの使用

4.1.3 Oracle Identity Federationのログ・ファイル

$DOMAIN_HOME/servers/servername/logsディレクトリに置かれるOracle Identity Federationのログ・ファイルは、サーバー・インスタンスの管理と監視に関する有用な情報を提供します。次のようなログ・ファイルがあります。

表4-1 Oracle Identity Federationのログ・ファイル

ログ・ファイル名

説明

servername_diagnostics.log

Oracle Identity Federationサーバーの実行時ログ・レコードが含まれます。

注意:
以前のリリースでは、プロバイダ間で交換されたSAMLメッセージはfederation-msg.logに含まれていました。このログ・ファイルはすでに存在しません。これらのメッセージは、Oracle Fusion Middlewareの共通監査フレームワークで監査および使用できるようになりました。

4.1.4 バックアップ

システムの通常のバックアップに使用するツールを使用して、構成/システムを日常的にバックアップする必要があります。

このトピックの詳細は、『Oracle Fusion Middleware管理者ガイド』の高度な管理: バックアップとリカバリに関する項を参照してください。

Windowsの場合

次のバックアップ規則を使用します。

- Windowsプラットフォーム上のバックアップとリストアのシステム・ツールを使用します。

- Oracle Identity Federation構成の中の全コンポーネント上にあるすべてのものをバックアップします。

Linux/solarisの場合

次のバックアップ規則を使用します。

- Oracle WebLogic ServerとOracle Identity Federationのすべてのコンポーネントをシャットダウンします。

- 管理対象サーバーのOracle Identity Federationフォルダ、およびOracle Identity Federationが使用しているRDBMSデータ・ファイルを含む、すべてのコンポーネントに対してtarコマンドを実行します。
次に例を示します。

tar cvzf oif11_backup oif_folder

4.2 一般的なタスク

この項では、Oracle Identity Federationで提供される、管理者およびピア・ユーザー向けの一般的なサービスについて説明します。次のタスクについて説明します。

- サーバー・メタデータの取得

- サーバー証明書の取得

- SPが開始するシングル・サインオンの実行

- IdPが開始するシングル・サインオンの実行

- IdPが開始するSSOでのリレー状態の使用

- ログアウト処理の起動

- 署名検証証明書プロパティの設定(SAML 1.x)

- SPが開始するシングル・サインオンの実行(SAML 1.x)

- 属性リクエストおよび問合せの送信(SAML 1.x)

- 認証問合せの送信(SAML 1.x)

4.2.1 サーバー・メタデータの取得

Oracle Identity Federationメタデータを取得するには、Oracle Enterprise Manager Fusion Middleware Controlから取得するか、URLに直接アクセスします。

Fusion Middleware Controlからメタデータを取得する手順は次のとおりです。

1. 「Oracle Identity Federation」→「管理」→「セキュリティおよび信頼」→「プロバイダ・メタデータ」の順に移動します。

2. 作成するプロバイダ・タイプおよびOracle Identity Federationメタデータのバージョンを選択します。

3. 「生成」をクリックします。

Oracle Identity Federation IdP メタデータを取得するには、次の形式のURLにアクセスします。

http://host:port/fed/idp/metadata

Oracle Identity Federation SPメタデータを取得するには、次の形式のURLにアクセスします。

http://host:port/fed/sp/metadata

IdPメタデータのサンプル

次に示すのは、SSOアイデンティティ・プロバイダ、属性認証局、認証問合せおよびアサーションIDレスポンダの機能が有効なサーバーのメタデータのサンプルです。

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="id-PmHsOU3mD8zEyjDo0QbyelE5oxY-" entityID="https://node.us.example.com:7002/fed/idp" validUntil="2009-05-24T15:48:15Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICIzCCAYygAwIBAgIBJTANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMDkwMTEzMjMwMTE2WhcNMTAwMTEzMjMwMTE2WjA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI7X7J6A057NEBgTnCYussaz6E3IY6JsgAYOiXHfwunEv6zRZnpdVlZIRUyT+NNULSfk+PLbQU/NCg8yQdJeSNYkQ4BId+yyUDcYC447nhHa37uLKM7aWyAXc6AeffC6CSEs0yZltgU2nIxJh9tLhPe5hzf0QjSImyXR/vjS/6nDAgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQUmZ8T7GkFv2VZB+FogX99DIvodTswDQYJKoZIhvcNAQEEBQADgYEAbMGoZzjo9Bfaua3wiRh3LyMeahdoHv5S67JPAWNXrvQUxKjvYH0QR2oTnD+Rf3hIhi6Tjwy4oP9YrcADiChp8tqckrBnR3L1aEErLXGau6r++a/PwslasuysNfbEoHrGJ1m+3K9DXGYYkGKdKgW9Dgg8MObZshDxd7xUm557QO8=
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=node.us.example.com Signing Certificate</dsig:X509IssuerName>
<dsig:X509SerialNumber>37</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com Signing Certificate</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICPDCCAeYCEC5V26OFPaoDxzAazNs8UBwwDQYJKoZIhvcNAQEEBQAweTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDgxMTE4MjAwNzE4WhcNMjMxMTE5MjAwNzE4WjCBhTELMAkGA1UEBhMCVVMxEDAOBgNVBAgWB015U3RhdGUxDzANBgNVBAcWBk15VG93bjEXMBUGA1UEChYOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsWEEZPUiBURVNUSU5HIE9OTFkxHzAdBgNVBAMWFnN0YTAwNTM0LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJCDgD00LDSUdWT0SznaU35ZkeQD2Ql6hvtoGcs8MfQpOM/yzM3C9GDlK9+0JpN+7EFGQsCCezFVEX6lMzWdkvdGhbTUJ8/FI32QZ6FPkFItZrnfOS6eDpxcPsnv33rPVQ+ccRvj7BK+sn24PEeV5rt3xF1cGuHGr57t/LtUa01AgMBAAEwDQYJKoZIhvcNAQEEBQADQQAChW8nbopN0FTyZRcVOTZKUlklHXf5X8Xi4gh2OIkkr7q9kjFlfI60SQZoD/nThn1sGZPPbtPGEwRevpqv7cI/
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509IssuerName>
<dsig:X509SerialNumber>61590287842211333696140797217026625564</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
</md:KeyDescriptor>
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/idp/soap" index="1" isDefault="true"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://node.us.example.com:7002/fed/idp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/idp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/idp/samlv20ss" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20ss"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://node.us.example.com:7002/fed/idp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/idp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/idp/samlv20ss" ResponseLocation="https://node.us.example.com:7002/fed/idp/samlv20ss"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/idp/soap"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://node.us.example.com:7002/fed/idp/samlv20"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/idp/samlv20ss"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/idp/soap"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="https://node.us.example.com:7002/fed/idp/assertionid"/>
</md:IDPSSODescriptor>
<md:AuthnAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICIzCCAYygAwIBAgIBJTANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMDkwMTEzMjMwMTE2WhcNMTAwMTEzMjMwMTE2WjA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI7X7J6A057NEBgTnCYussaz6E3IY6JsgAYOiXHfwunEv6zRZnpdVlZIRUyT+NNULSfk+PLbQU/NCg8yQdJeSNYkQ4BId+yyUDcYC447nhHa37uLKM7aWyAXc6AeffC6CSEs0yZltgU2nIxJh9tLhPe5hzf0QjSImyXR/vjS/6nDAgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQUmZ8T7GkFv2VZB+FogX99DIvodTswDQYJKoZIhvcNAQEEBQADgYEAbMGoZzjo9Bfaua3wiRh3LyMeahdoHv5S67JPAWNXrvQUxKjvYH0QR2oTnD+Rf3hIhi6Tjwy4oP9YrcADiChp8tqckrBnR3L1aEErLXGau6r++a/PwslasuysNfbEoHrGJ1m+3K9DXGYYkGKdKgW9Dgg8MObZshDxd7xUm557QO8=
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=node.us.example.com Signing Certificate</dsig:X509IssuerName>
<dsig:X509SerialNumber>37</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com Signing Certificate</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICPDCCAeYCEC5V26OFPaoDxzAazNs8UBwwDQYJKoZIhvcNAQEEBQAweTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDgxMTE4MjAwNzE4WhcNMjMxMTE5MjAwNzE4WjCBhTELMAkGA1UEBhMCVVMxEDAOBgNVBAgWB015U3RhdGUxDzANBgNVBAcWBk15VG93bjEXMBUGA1UEChYOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsWEEZPUiBURVNUSU5HIE9OTFkxHzAdBgNVBAMWFnN0YTAwNTM0LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJCDgD00LDSUdWT0SznaU35ZkeQD2Ql6hvtoGcs8MfQpOM/yzM3C9GDlK9+0JpN+7EFGQsCCezFVEX6lMzWdkvdGhbTUJ8/FI32QZ6FPkFItZrnfOS6eDpxcPsnv33rPVQ+ccRvj7BK+sn24PEeV5rt3xF1cGuHGr57t/LtUa01AgMBAAEwDQYJKoZIhvcNAQEEBQADQQAChW8nbopN0FTyZRcVOTZKUlklHXf5X8Xi4gh2OIkkr7q9kjFlfI60SQZoD/nThn1sGZPPbtPGEwRevpqv7cI/
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509IssuerName>
<dsig:X509SerialNumber>61590287842211333696140797217026625564</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
</md:KeyDescriptor>
<md:AuthnQueryService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/authnauth/soap"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/authnauth/soap"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="https://node.us.example.com:7002/fed/authnauth/assertionid"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
</md:AuthnAuthorityDescriptor>
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICIzCCAYygAwIBAgIBJTANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMDkwMTEzMjMwMTE2WhcNMTAwMTEzMjMwMTE2WjA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI7X7J6A057NEBgTnCYussaz6E3IY6JsgAYOiXHfwunEv6zRZnpdVlZIRUyT+NNULSfk+PLbQU/NCg8yQdJeSNYkQ4BId+yyUDcYC447nhHa37uLKM7aWyAXc6AeffC6CSEs0yZltgU2nIxJh9tLhPe5hzf0QjSImyXR/vjS/6nDAgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQUmZ8T7GkFv2VZB+FogX99DIvodTswDQYJKoZIhvcNAQEEBQADgYEAbMGoZzjo9Bfaua3wiRh3LyMeahdoHv5S67JPAWNXrvQUxKjvYH0QR2oTnD+Rf3hIhi6Tjwy4oP9YrcADiChp8tqckrBnR3L1aEErLXGau6r++a/PwslasuysNfbEoHrGJ1m+3K9DXGYYkGKdKgW9Dgg8MObZshDxd7xUm557QO8=
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=node.us.example.com Signing Certificate</dsig:X509IssuerName>
<dsig:X509SerialNumber>37</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com Signing Certificate</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICPDCCAeYCEC5V26OFPaoDxzAazNs8UBwwDQYJKoZIhvcNAQEEBQAweTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDgxMTE4MjAwNzE4WhcNMjMxMTE5MjAwNzE4WjCBhTELMAkGA1UEBhMCVVMxEDAOBgNVBAgWB015U3RhdGUxDzANBgNVBAcWBk15VG93bjEXMBUGA1UEChYOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsWEEZPUiBURVNUSU5HIE9OTFkxHzAdBgNVBAMWFnN0YTAwNTM0LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJCDgD00LDSUdWT0SznaU35ZkeQD2Ql6hvtoGcs8MfQpOM/yzM3C9GDlK9+0JpN+7EFGQsCCezFVEX6lMzWdkvdGhbTUJ8/FI32QZ6FPkFItZrnfOS6eDpxcPsnv33rPVQ+ccRvj7BK+sn24PEeV5rt3xF1cGuHGr57t/LtUa01AgMBAAEwDQYJKoZIhvcNAQEEBQADQQAChW8nbopN0FTyZRcVOTZKUlklHXf5X8Xi4gh2OIkkr7q9kjFlfI60SQZoD/nThn1sGZPPbtPGEwRevpqv7cI/
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509IssuerName>
<dsig:X509SerialNumber>61590287842211333696140797217026625564</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
</md:KeyDescriptor>
<md:AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/aa/soap"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/aa/soap"/>
<md:AssertionIDRequestService Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" Location="https://node.us.example.com:7002/fed/aa/assertionid"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:AttributeProfile>urn:oasis:names:tc:SAML:2.0:profiles:attribute:basic</md:AttributeProfile>
</md:AttributeAuthorityDescriptor>
</md:EntityDescriptor>

SPメタデータのサンプル

次に示すのは、SSOサービス・プロバイダ、属性リクエスタの機能が有効なサーバーのメタデータのサンプルです。

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="id-f4-F2z4ncIOsHw5w6CkMjneSE7I-" entityID="http://node.us.example.com:7499/fed/sp" validUntil="2009-05-24T15:39:48Z">
<md:RoleDescriptor xmlns:query="urn:oasis:names:tc:SAML:metadata:ext:query" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" xsi:type="query:AttributeQueryDescriptorType">
<md:KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICIzCCAYygAwIBAgIBJTANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMDkwMTEzMjMwMTE2WhcNMTAwMTEzMjMwMTE2WjA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI7X7J6A057NEBgTnCYussaz6E3IY6JsgAYOiXHfwunEv6zRZnpdVlZIRUyT+NNULSfk+PLbQU/NCg8yQdJeSNYkQ4BId+yyUDcYC447nhHa37uLKM7aWyAXc6AeffC6CSEs0yZltgU2nIxJh9tLhPe5hzf0QjSImyXR/vjS/6nDAgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQUmZ8T7GkFv2VZB+FogX99DIvodTswDQYJKoZIhvcNAQEEBQADgYEAbMGoZzjo9Bfaua3wiRh3LyMeahdoHv5S67JPAWNXrvQUxKjvYH0QR2oTnD+Rf3hIhi6Tjwy4oP9YrcADiChp8tqckrBnR3L1aEErLXGau6r++a/PwslasuysNfbEoHrGJ1m+3K9DXGYYkGKdKgW9Dgg8MObZshDxd7xUm557QO8=
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=node.us.example.com Signing Certificate</dsig:X509IssuerName>
<dsig:X509SerialNumber>37</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com Signing Certificate</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICPDCCAeYCEC5V26OFPaoDxzAazNs8UBwwDQYJKoZIhvcNAQEEBQAweTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDgxMTE4MjAwNzE4WhcNMjMxMTE5MjAwNzE4WjCBhTELMAkGA1UEBhMCVVMxEDAOBgNVBAgWB015U3RhdGUxDzANBgNVBAcWBk15VG93bjEXMBUGA1UEChYOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsWEEZPUiBURVNUSU5HIE9OTFkxHzAdBgNVBAMWFnN0YTAwNTM0LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJCDgD00LDSUdWT0SznaU35ZkeQD2Ql6hvtoGcs8MfQpOM/yzM3C9GDlK9+0JpN+7EFGQsCCezFVEX6lMzWdkvdGhbTUJ8/FI32QZ6FPkFItZrnfOS6eDpxcPsnv33rPVQ+ccRvj7BK+sn24PEeV5rt3xF1cGuHGr57t/LtUa01AgMBAAEwDQYJKoZIhvcNAQEEBQADQQAChW8nbopN0FTyZRcVOTZKUlklHXf5X8Xi4gh2OIkkr7q9kjFlfI60SQZoD/nThn1sGZPPbtPGEwRevpqv7cI/
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509IssuerName>
<dsig:X509SerialNumber>61590287842211333696140797217026625564</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>lastname</md:NameIDFormat>
</md:RoleDescriptor>
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICIzCCAYygAwIBAgIBJTANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwHhcNMDkwMTEzMjMwMTE2WhcNMTAwMTEzMjMwMTE2WjA1MTMwMQYDVQQDEypzdGEwMDUzNC51cy5vcmFjbGUuY29tIFNpZ25pbmcgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI7X7J6A057NEBgTnCYussaz6E3IY6JsgAYOiXHfwunEv6zRZnpdVlZIRUyT+NNULSfk+PLbQU/NCg8yQdJeSNYkQ4BId+yyUDcYC447nhHa37uLKM7aWyAXc6AeffC6CSEs0yZltgU2nIxJh9tLhPe5hzf0QjSImyXR/vjS/6nDAgMBAAGjQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwfwADAdBgNVHQ4EFgQUmZ8T7GkFv2VZB+FogX99DIvodTswDQYJKoZIhvcNAQEEBQADgYEAbMGoZzjo9Bfaua3wiRh3LyMeahdoHv5S67JPAWNXrvQUxKjvYH0QR2oTnD+Rf3hIhi6Tjwy4oP9YrcADiChp8tqckrBnR3L1aEErLXGau6r++a/PwslasuysNfbEoHrGJ1m+3K9DXGYYkGKdKgW9Dgg8MObZshDxd7xUm557QO8=
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=node.us.example.com Signing Certificate</dsig:X509IssuerName>
<dsig:X509SerialNumber>37</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com Signing Certificate</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:X509Data>
<dsig:X509Certificate>MIICPDCCAeYCEC5V26OFPaoDxzAazNs8UBwwDQYJKoZIhvcNAQEEBQAweTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkxEzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDgxMTE4MjAwNzE4WhcNMjMxMTE5MjAwNzE4WjCBhTELMAkGA1UEBhMCVVMxEDAOBgNVBAgWB015U3RhdGUxDzANBgNVBAcWBk15VG93bjEXMBUGA1UEChYOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsWEEZPUiBURVNUSU5HIE9OTFkxHzAdBgNVBAMWFnN0YTAwNTM0LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJCDgD00LDSUdWT0SznaU35ZkeQD2Ql6hvtoGcs8MfQpOM/yzM3C9GDlK9+0JpN+7EFGQsCCezFVEX6lMzWdkvdGhbTUJ8/FI32QZ6FPkFItZrnfOS6eDpxcPsnv33rPVQ+ccRvj7BK+sn24PEeV5rt3xF1cGuHGr57t/LtUa01AgMBAAEwDQYJKoZIhvcNAQEEBQADQQAChW8nbopN0FTyZRcVOTZKUlklHXf5X8Xi4gh2OIkkr7q9kjFlfI60SQZoD/nThn1sGZPPbtPGEwRevpqv7cI/
</dsig:X509Certificate>
<dsig:X509IssuerSerial>
<dsig:X509IssuerName>CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509IssuerName>
<dsig:X509SerialNumber>61590287842211333696140797217026625564</dsig:X509SerialNumber>
</dsig:X509IssuerSerial>
<dsig:X509SubjectName>CN=node.us.example.com, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US</dsig:X509SubjectName>
</dsig:X509Data>
</dsig:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://node.us.example.com:7002/fed/sp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/sp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/sp/samlv20ss" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20ss"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://node.us.example.com:7002/fed/sp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/sp/samlv20" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/sp/samlv20ss" ResponseLocation="https://node.us.example.com:7002/fed/sp/samlv20ss"/>
<md:ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://node.us.example.com:7002/fed/sp/soap"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://node.us.example.com:7002/fed/sp/art20" index="0" isDefault="true"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://node.us.example.com:7002/fed/sp/authnResponse20" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://node.us.example.com:7002/fed/sp/authnResponse20ss" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://node.us.example.com:7002/fed/sp/authnResponse20" index="4"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>

次のサブトピックについて説明します。

- バージョン

- プロバイダ固有のメタデータ

4.2.1.1 バージョン

IdPおよびSPの操作でメタデータ・リクエストを発行する際に、メタデータのバージョンを指定するには、version問合せパラメータを指定します。

問合せパラメータに次のいずれかの値を指定する必要があります。

- saml10 - SAML 1.0メタデータ

- saml11 - SAML 1.1メタデータ

- saml20 - SAML 2.0メタデータ

- lib11 - Liberty 1.1

- lib12 - Liberty 1.2

注意:
Liberty 1.xのサポートは非推奨です。

次の問合せの例は、SAML 2.0バージョンのIdPメタデータをリクエストします。

http://host:port/fed/idp/metadata?version=saml20

注意:
versionパラメータを指定しない場合は、バージョンはsaml20とみなされます。

4.2.1.2 プロバイダ固有のメタデータ

Oracle Identity Federationでは、グローバルな構成パラメータを定義できます。また、特定のリモート・プロバイダと通信する場合にこれらのグローバル・パラメータを上書きする方法も用意されています。一部のパラメータは、上書きするとメタデータが変更されます。

相互運用性を考慮して、Oracle Identity Federationは特定のプロバイダの構成に基づいたメタデータの生成、またはグローバル設定を使用したメタデータの生成をサポートしています。

特定のプロバイダのグローバル設定を上書きする場合は、通常、プロバイダ固有の構成に基づいてOracle Identity Federationメタデータを生成し、そのメタデータをリモート・プロバイダに提供します。

特定のリモート・プロバイダのOracle Identity Federationメタデータを生成するには、URLにproviderid問合せパラメータを追加して、パラメータにプロバイダIDを設定します。次に例を示します。

http://host:port/fed/idp/metadata?providerid=idp.com

注意:
provideridパラメータを指定しない場合は、グローバル構成に基づいてメタデータが生成されます。

4.2.2 サーバー証明書の取得

Oracle Identity FederationのIdP証明書を取得するには、次の形式のURLにアクセスします。

http://host:port/fed/idp/cert

Oracle Identity FederationのSP証明書を取得するには、次の形式のURLにアクセスします。

http://host:port/fed/sp/cert

その他の内容は次のとおりです。

- 証明書の使用方法の指定

- 証明書タイプの指定

4.2.2.1 証明書の使用方法の指定

返される証明書の使用方法(署名または暗号化)を指定するには、次のいずれかの値をuseパラメータに含めます。

- enc - 暗号化証明書

- sign - 署名証明書

次に例を示します。

http://host:port/fed/idp/cert?use=enc

このリクエスト・フォーマットではOracle Identity Federation IdPの新しい暗号化証明書が返されます。

注意:
useパラメータを指定しない場合は、デフォルトで署名証明書が返されます。

4.2.2.2 証明書タイプの指定

返される証明書のタイプ(新/旧)を指定するには、次のいずれかの値をtypeパラメータに含めます。

- new - 新しい証明書

- old - 古い証明書

次に例を示します。

http://host:port/fed/idp/cert?type=old&use=enc

このリクエスト・フォーマットではOracle Identity Federation IdPの旧暗号化証明書が返されます。

注意:
typeパラメータを指定しない場合は、デフォルトで新しい証明書が返されます。

4.2.3 SPが開始するシングル・サインオンの実行

フェデレーションSSO処理を開始するには、Oracle Identity Federation/SPインスタンスでサービスを直接リクエストします。

Oracle Identity FederationでリクエストされるURLは次のような形式になります。

http://host:port/fed/sp/initiatesso

URLをリクエストする際に、次の問合せパラメータを指定できます。

- providerid - SSO処理を実行するために使用するIdPの識別子です(オプション)。指定しない場合は、デフォルトのSSOプロバイダが使用されます。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。詳細は、第6.2項「アフィリエーション関連の作業」を参照してください。

- returnurl - SSO処理が成功した場合にユーザーが送られるURLです。「非送信請求SSOリレー状態」プロパティが指定されていない場合は必須です。

URLの形式の例を次に示します。

http://host:port/fed/sp/initiatesso?providerid=http%3A%2F%2Fidp.com&returnurl=ProtectedAppURL

注意:
問合せパラメータ値が正しくURLエンコードされていることを確認します。

4.2.4 IdPが開始するシングル・サインオンの実行

Oracle Identity Federationには、IdPとして動作するOracle Identity FederationインスタンスでURLを直接リクエストすることによってSSO処理を開始する機能が用意されています。

Oracle Identity Federationで、http://host:port/fed/idp/initiatessoの形式のURLをリクエストします。

次の問合せパラメータを指定できます。

- providerid - SSO処理を実行するために使用するSAML 2.0 SPの識別子です(オプション)。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。詳細は、第6.2項「アフィリエーション関連の作業」を参照してください。

- returnurl - SSO処理が成功した場合にユーザーが送られるURLです。

このタイプのURLの例を次に示します。

http://host:port/fed/idp/initiatesso?providerid=http%3A%2F%2Fsp.com&returnurl=ProtectedAppURL

注意:
問合せパラメータ値が正しくURLエンコードされていることを確認します。

4.2.5 IdPが開始するSSOでのリレー状態の使用

IdPが非送信請求シングル・サインオン操作を実行するときに、リレー状態をサービス・プロバイダに通信できます。リレー状態は、シングル・サインオン処理が正常に終了した後にユーザーが送られる最終のターゲットURLとして使用できます。

IdPが開始するSSOでは次の使用方法が可能です。

シナリオ1: リレー状態を使用したIdPが開始するSSO

IdPが開始するURLの形式は次のとおりです。

http://host:port/fed/idp/initiatesso?providerid=providerA&returnURL=http://somelink

この場合、Oracle Identity Federationは、initiatessoディレクティブにreturnURLがあることを確認し、そのURLをrelayStateに設定してSPに送信します。

シナリオ2: SPでリレー状態を設定する場合のIdPが開始するSSO

IdPが開始するURLの形式は次のとおりです。

http://host:port/fed/idp/initiatesso?providerid=providerA

この場合、returnURLがないため、サーバーはSP(providerA)の構成を確認します。非送信請求リレー状態に対して特定のURLが設定されている場合は、そのURLをRelayStateとして設定してSPに送信します。

シナリオ3: リレー状態がない場合のIdPが開始するSSO

シナリオ2と同様に、IdPが開始するURLの形式は次のとおりです。

http://host:port/fed/idp/initiatesso?providerid=providerA

この場合、returnURLがないため、サーバーはproviderAの構成を確認します。非送信請求リレー状態に対してURLが設定されていない場合は、SPにRelayStateを送信しません。このシナリオでは、サーバーは、SSO処理完了後のユーザーの送信先はSPの構成/ロジックに基づいて決定されることを想定しています。

4.2.6 ログアウト処理の起動

ログアウト処理を起動するには、次の形式のURLにアクセスします。

http://hostname:port/fed/user/logout?returnurl=http%3A%2F%2Fanotherhostname%2Fpath

ログアウト・サービスは、returnurlパラメータを取ります。これは正確な処理に必要です。ログアウト処理が完了した後にユーザーがこのURLにリダイレクトされます。

Oracle Identity FederationログアウトURLの呼出し時にreturnurlパラメータを指定しない場合は、サインオフ処理が実行された後で、組込みのログアウト結果ページがサーバーに表示されます。

ログアウトは、次のプロトコルのすべてのピア・プロバイダに対して実行されます。

- SAML 2.0

- WS-Federation

- Liberty 1.1

- Liberty 1.2

SAML 1.xプロトコルでは、ローカルのOracle Identity Federationセッションのみが削除されます。ユーザーのセッションが終了したことは、SAML 1.xリモート・プロバイダには通知されません。

関連項目:
ユーザーがグローバル・ログアウトを呼び出せるようにOracle Identity Federationを構成する方法の詳細は、第6.8.4項「オンデマンド・グローバル・ログアウトの構成」を参照してください。

4.2.7 署名検証証明書プロパティの設定(SAML 1.x)

SAML 1.xプロバイダのXMLメタデータをアップロードしておらず、そのプロバイダが署名付きメッセージを送信するように構成されている場合は、次を実行する必要があります。

- プロバイダがIdPの場合は、IdP Signature Verification Certificateプロパティを設定する必要があります。

- プロバイダがSPの場合は、SP Signature Verification Certificateプロパティを設定する必要があります。

関連項目:
これらの証明書の取得方法の詳細は、第4.2.2項「サーバー証明書の取得」を参照してください。

4.2.8 SPが開始するシングル・サインオンの実行(SAML 1.x)

SPが開始するSSOを実行するには、特定のプロパティを設定する必要があります。

SPメタデータをIdPに追加し、そのメタデータを選択して「編集」をクリックします。「信頼できるプロバイダ設定」セクションで次のプロパティを設定します。

SPアサーション・コンシューマ・サービスURLは次のとおりです。

http://host:port/fed/sp/samlv11sso

IdPメタデータをSPに追加してから、そのメタデータを選択して「編集」をクリックします。「信頼できるプロバイダ設定」セクションで次のプロパティを設定します。

- IdPが開始するSSOのURL -- http://host:port/fed/idp/samlv11sso(SAML 1.1の場合)またはhttp://host:port/fed/idp/samlv10sso(SAML 1.0の場合)

- IdPが開始するSSOのターゲット・パラメータ -- ピア・プロバイダが目的のリソースを特定する際に使用する任意の妥当な文字列(Oracle Identity Federationでは"TARGET")。

- IdPが開始するSSOのプロバイダ・パラメータ - providerid

- IdP SOAPアーティファクト解決エンドポイント -

http://host:port/fed/idp/soapv11

4.2.9 属性リクエストおよび問合せの送信(SAML 1.x)

SAML 1.xではユーザーの属性を取得するためのプロトコルが定義されています。SPとして動作するOracle Identity Federationインスタンスに属性リクエストを送信したり、IdPとして動作するOracle Identity FederationインスタンスにSAML 1.x属性問合せを送信したりできます。

第5.6項「Oracle Access Manager AuthZプラグインによる属性共有の構成」では、SPおよびIdPでSAMLの属性共有を構成する方法について説明しています。

属性リクエストを(SOAPエンベロープで)SPに送信するには、次のURLを使用します。

http://sphost:port/fed/ar/soap

SAML 1.x属性問合せを(SOAPエンベロープで)IdPに送信するには、次のURLを使用します。

http://idphost:port/fed/aa/soapv11

詳細は、次を参照してください。

- 第5.6項「Oracle Access Manager AuthZプラグインによる属性共有の構成」

- 第4.3.5項「SAML 1.xとWSフェデレーションに対するシングル・サインオンの設定」

また、属性の名前と値のマッピングおよび属性フィルタリングを構成することもできます。詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください。

アイデンティティ・プロバイダとして動作するOracle Identity FederationでSAML 1.x属性問合せを受信する場合、リクエスタを識別する必要があります。Oracle Identity Federationでリクエスタを識別するには、SSLクライアント証明書を指定する方法とHTTP Basic認証で認証する方法の2つがあります。

SSLクライアント証明書によってリクエスタを認証する場合、証明書サブジェクトのcnは、Oracle Identity Federationがリクエスタの識別に使用するプロバイダIDである必要があります。HTTP Basic認証によってリクエスタを認証する場合、リクエスタが使用するユーザー名は、Oracle Identity Federationがリクエスタの識別に使用するプロバイダIDである必要があります。

クライアント認証またはHTTP Basic認証によってSSLを設定する方法の詳細は、第6.9項「SOAPエンドポイントの保護」を参照してください。

4.2.9.1 属性リクエスタ・サービスを使用する場合の名前IDフォーマット文字列

属性リクエスタ・サービスを使用する場合に、NameIDフォーマットに使用される文字列は次のとおりです。

表4-2 属性リクエスタ・サービスの名前IDフォーマット

フォーマット

文字列

x509

oracle:security:nameid:format:x509

email

oracle:security:nameid:format:emailaddress

windows

oracle:security:nameid:format:windowsdomainqualifiedname

kerberos

oracle:security:nameid:format:kerberos

persistent

oracle:security:nameid:format:persistent

transient

oracle:security:nameid:format:transient

unspecified

oracle:security:nameid:format:unspecified

カスタム

oracle:security:nameid:format:custom

userid

oracle:security:nameid:format:userid

4.2.10 認証問合せの送信(SAML 1.x)

IdPとして動作するOracle Identity FederationインスタンスにSAML 1.x認証問合せを送信するには、次の形式のURLを使用します。

http://host:port/fed/authnauth/soapv11

アイデンティティ・プロバイダとして動作するOracle Identity FederationでSAML 1.x認証問合せを受信する場合、リクエスタを識別する必要があります。Oracle Identity Federationでリクエスタを識別するには、SSLクライアント証明書を指定する方法とHTTP Basic認証で認証する方法の2つがあります。

SSLクライアント証明書によってリクエスタを認証する場合、証明書サブジェクトのcnは、Oracle Identity Federationがリクエスタの識別に使用するプロバイダIDである必要があります。HTTP Basic認証によってリクエスタを認証する場合、リクエスタが使用するユーザー名は、Oracle Identity Federationがリクエスタの識別に使用するプロバイダIDである必要があります。

クライアント認証またはHTTP Basic認証によってSSLを設定する方法の詳細は、第6.9項「SOAPエンドポイントの保護」を参照してください。

4.3 アイデンティティ・フェデレーションの管理

サーバーの信頼できるプロバイダを表示および管理するには、Fusion Middleware ControlでOracle Identity Federationサーバーの「フェデレーション」ページを使用します。

Fusion Middleware Controlでページを表示するには、対象のインスタンスを選択して、「Oracle Identity Federation」→「管理」→「フェデレーション」の順に移動します。

このセクションの内容は次のとおりです。

- プロバイダの検索

- 信頼できるプロバイダの追加

- 信頼できるプロバイダの更新

- 信頼できるプロバイダの削除

- SAML 1.xとWSフェデレーションに対するシングル・サインオンの設定

4.3.1 プロバイダの検索

この機能を使用して、信頼できるプロバイダからプロバイダを見つけます。

テキスト・ボックスで、プロバイダIDまたはプロバイダの説明を入力します。「検索」アイコンをクリックします。

プロバイダIDまたは説明の一部を入力することができます。たとえば、ポート番号を入力すると、指定したポートをリスニングするサーバーのみが表示されます。

4.3.2 信頼できるプロバイダの追加

サーバーの信頼できるプロバイダに信頼できるプロバイダを追加する手順は次のとおりです。

1. Fusion Middleware Controlで、左側のトポロジ・パネルでサーバー・インスタンスを選択します。

2. 「Oracle Identity Federation」→「管理」→「フェデレーション」の順にナビゲートします。

3. 「フェデレーション」ページで、「追加」をクリックします。
「信頼できるプロバイダの追加」ダイアログが表示されます。プロバイダの詳細をここで指定するか、ファイル・システムからアップロードできます。

次の点に注意してください。

- メタデータをアップロードする場合は、関連するSPサイトまたはIdPサイトで同じプロトコルが使用されているかどうかを確認するための検証は行われません。プロトコルを検証する場合は、フェデレーテッド・シングル・サインオンを実行します。

- Firefoxブラウザを使用して、Fusion Middleware Controlの「フェデレーション」ページからプロバイダ・メタデータをアップロードすると、アップロードしたプロバイダ・メタデータ・ファイルはFirefoxを再起動するまで変更できません。
これは、FirefoxのLive HTTP Headerアドオンに起因するものです。このアドオンを無効にしてFirefoxを再起動すると、「フェデレーション」ページでプロバイダのメタデータをアップロードした後に、メタデータ・ファイルを変更できるようになります。

4.3.3 信頼できるプロバイダの更新

信頼できるプロバイダを更新または削除する手順は次のとおりです。

1. Fusion Middleware Controlで、左側のトポロジ・パネルでサーバー・インスタンスを選択します。

2. 「Oracle Identity Federation」→「管理」→「フェデレーション」の順にナビゲートします。

3. プロバイダを選択して、「編集」をクリックします。

信頼できるプロバイダの制御プロパティが次のように表示されます。

「信頼できるプロバイダ設定」タブが次のように表示されます。

「Oracle Identity Federation設定」タブの最初のフィールド群は次のように表示されます。

「Oracle Identity Federation設定」タブの2番目および最後のフィールド群は次のように表示されます。

関連項目:
第4.3.5項「SAML 1.xとWSフェデレーションに対するシングル・サインオンの設定」

4.3.4 信頼できるプロバイダの削除

サーバーの信頼できるプロバイダを更新または削除する手順は次のとおりです。

1. Fusion Middleware Controlで、左側のトポロジ・パネルでサーバー・インスタンスを選択します。

2. 「Oracle Identity Federation」→「管理」→「フェデレーション」の順にナビゲートします。

3. プロバイダを選択して、「削除」をクリックします。

4.3.5 SAML 1.xとWSフェデレーションに対するシングル・サインオンの設定

SAML 1.xおよびWS-Federationプロトコルに対するSSOを設定するには、まず信頼できるプロバイダのリストにピア・プロバイダを追加し、続いてプロトコルの必須属性を入力します。

信頼できるプロバイダへのピア・プロバイダの追加

このタスクを実行するには、次の手順を実行します。

1. Fusion Middleware Controlで、左側のトポロジ・パネルでサーバー・インスタンスを選択します。

2. 「Oracle Identity Federation」→「管理」→「フェデレーション」の順に移動します。

3. 「フェデレーション」ページで、「追加」をクリックします。

4. 「プロバイダの手動追加」オプションを選択します。必須属性を入力したら、「OK」をクリックして信頼できるプロバイダを追加します。

SAML 1.xの必須属性の入力

SAML1.xメタデータをアップロードすることもできます。これは、Oracle Identity Federationで生成できます。ピア・プロバイダの署名証明書とアーティファクト解決SOAPエンドポイントのパラメータは自動的に入力されます。

このタスクを実行するには、次の手順を実行します。

1. 「フェデレーション」ページで、SAML 1.Xプロバイダを選択して「編集」をクリックします。

2. 「手動更新」オプションを選択します。

3. 「信頼できるプロバイダ設定」タブを選択します。

4. ピア・プロバイダがアイデンティティ・プロバイダの場合は、次の手順を実行します。

1. 「アイデンティティ・プロバイダ/認証局設定」セクションで、「新規署名検証証明書」フィールドにピア・プロバイダの署名証明書を入力します。

2. 「SSO URLの開始」フィールドに、ピア・プロバイダでSSOフローの開始に使用するURLを入力します。

3. 「SSOターゲット・パラメータの開始」フィールドに、ピア・プロバイダで目的のリソースの識別に使用するパラメータを入力します(Oracle Identity FederationではTARGET)。

4. 「SSOプロバイダIDパラメータの開始」フィールドに、ピア・プロバイダでサービス・プロバイダのプロバイダIDの識別に使用するパラメータの名前を入力します。Oracle Identity Federationピア・アイデンティティ・プロバイダの場合、パラメータ名はprovideridです。

5. 「アーティファクト解決SOAPエンドポイント」フィールドに、ピア・プロバイダでSOAPリクエストを受信してアーティファクトを解決する際に使用するURLを入力します。

6. 「アーティファクト・ソースID」フィールドに、ソースIDパラメータを入力します。Oracle Identity Federation/SPは、この値を使用して既知のIdPのリストからユーザーの優先アイデンティティ・プロバイダを検索します。
ソースIDが指定されていない場合は、Oracle Identity FederationがプロバイダIDのSHA-1ダイジェストとして自動的にソースIDを生成します。

たとえば、Oracle Identity Federationピア・アイデンティティ・プロバイダは、前述のステップb、c、dで入力した構成を使用する次の「SSO URLの開始」を持つ場合があります。

http://saml.example.com/fed/idp/initiatesso?TARGET=<protected-resource-url>&providerid=<sp-provider-id-uri>

5. ピア・プロバイダがサービス・プロバイダの場合は、次の手順を実行します。

1. 「サービス・プロバイダ/リクエスタ設定」セクションで、「新規署名検証証明書」フィールドにピア・プロバイダの署名証明書を入力します。

2. 「アサーション・コンシューマ・サービスURL」フィールドに、ピア・プロバイダでアサーションの処理に使用するURLを入力します。

WS-Federation SSOの必須属性の入力

このタスクを実行するには、次の手順を実行します。

1. 「フェデレーション」ページで、WS-Fed 1.1プロバイダを選択して「編集」をクリックします。

2. 「手動更新」オプションを選択します。

3. 「ピア・プロバイダ設定」タブを選択します。

4. ピア・プロバイダがアイデンティティ・プロバイダの場合は、次の手順を実行します。

1. 「アイデンティティ・プロバイダ/認証局設定」セクションで、「新規署名検証証明書」フィールドにピア・プロバイダの署名証明書を入力します。

2. 「アイデンティティ・レルム・セキュア・トークンURL」フィールドに、認証リクエストの送信先となるピア・プロバイダのURLを追加します。

5. ピア・プロバイダがサービス・プロバイダの場合は、次の手順を実行します。

1. 「リソース・レルム・セキュア・トークンURL」フィールドに、アサーションの送信先となるピア・プロバイダのURLを入力します。

2. 「アサーション・タイプ/バージョン」ドロップダウン・リストから、このサービスプロバイダに送信されるアサーションのバージョンを選択します。

ピア・プロバイダに送信する必須プロパティ - WS-Federation

IdPの場合は次のものをピア・プロバイダ(SP)に送信する必要があります。

- プロバイダID http(s)://server_name:server_port/fed/idp

- 署名証明書

- アイデンティティ・レルム・セキュア・トークンURL(認証リクエストの送信先URL http(s)://server_name:server_port/fed/idp/wsfed11)

SPの場合は次のものをピア・プロバイダ(IdP)に送信する必要があります。

- プロバイダID http(s)://server_name:server_port/fed/sp

- リソース・レルム・セキュア・トークンURL(アサーションの送信先URL http(s)://server_name:server_port/fed/sp/wsfed11)

- アサーション・タイプ/バージョン(送信されるアサーションのバージョン(オプション))

ピア・プロバイダに送信する必須プロパティ - SAML 1.x

IdPの場合は次のものをピア・プロバイダ(SP)に送信する必要があります。

- プロバイダID http(s)://server_name:server_port/fed/idp

- 署名証明書

- IdPが開始するSSOのURL(認証リクエストの送信先となるURL)
SAML 1.1の場合:

http(s)://server_name:server_port/fed/idp/samlv11sso

SAML 1.0の場合:

http(s)://server_name:server_port/fed/idp/samlv10sso

- IdPアーティファクト解決URL(アーティファクト問合せを送信するURL) http(s)://server_name:server_port/fed/idp/soapv11

- ターゲットURL問合せパラメータ(Oracle Identity FederationではTARGET)。このパラメータには、ユーザーのサインオンが成功した場合に表示されるURLを含めます。

- プロバイダID URL問合せパラメータ(Oracle Identity Federationではproviderid)。このパラメータには、SPでSAML1.x SSOを開始する際のSPプロバイダIDを含めます。

- アーティファクト・プロファイルに必要なソースID。この値はIdPメタデータ(タグ<saml1md:SourceID>)から取得されます。

SPの場合は次のものをピア・プロバイダ(IdP)に送信する必要があります。

- プロバイダID http(s)://server_name:server_port/fed/sp

- 署名証明書(SOAPリクエストに署名する場合)

- アサーション・コンシューマのURL(アサーションの送信先URL http(s)://server_name:server_port/fed/sp/samlv11sso)

4.4 アイデンティティの構成

このページは、ユーザーおよびフェデレーテッド・アイデンティティの検索と管理、および検索オプションのメンテナンスを行う場合に使用します。

- フェデレーテッド・アイデンティティについて

- アイデンティティ - フェデレーション

- アイデンティティ - ユーザー

- アイデンティティ - 検索オプション

注意:
Liberty 1.xのサポートは非推奨です。

4.4.1 フェデレーテッド・アイデンティティについて

ユーザーが初めてSSOを実行するときに、Oracle Identity Federationがフェデレーション・データ・ストアで構成されている場合は、ユーザーのフェデレーテッド・アイデンティティに関する情報を含むフェデレーション・レコードが作成されます。内容は次のとおりです。

- ユーザー名 - Oracle Identity Federationがユーザーを識別するユーザーID。

- ユーザーの説明 - ユーザーの説明。

- IdP指定名前ID - SSO実行時にアイデンティティ・プロバイダで指定される名前ID。

- IdP指定名前IDフォーマット - アイデンティティ・プロバイダで指定される名前IDのフォーマット。このフィールドは、フォーマットが"persisent"の場合は空白になります。

- IdP指定名前ID修飾子 - アイデンティティ・プロバイダで必要に応じて指定される名前ID修飾子。

- プロトコルのバージョン - SSO実行時に使用されるプロトコルのバージョン。

- SP指定名前ID - サービス・プロバイダで指定される名前ID。フェデレーションの作成時には空白になります。

- SP指定名前IDフォーマット - サービス・プロバイダで指定される名前IDのフォーマット。このフィールドは、フォーマットが"persisent"の場合は空白になります。

- SP指定名前ID修飾子 - サービス・プロバイダで必要に応じて指定される名前ID修飾子。

- SP指定名前IDバージョン - SP名前IDのバージョン。

- プロバイダID - SSOが実行されたピア・プロバイダのプロバイダID。

- フェデレーション・タイプ - 作成されたフェデレーションのタイプ。次の値のいずれかになります。

- 1 - IdPとして動作するこのサーバーとSP間のフェデレーション

- 2 - IdPとして動作するこのサーバーとアフィリエーション間のフェデレーション

- 3 - SPとして動作するこのサーバーとIdP間のフェデレーション

- 4 - アフィリエーションとして動作するOracle Internet DirectoryサーバーとIdP間のフェデレーション

アイデンティティ・プロバイダで名前識別子管理(MNI)操作を実行してフェデレーションを更新すると、次のフィールドの値が更新されます。

- IdP指定名前ID

- IdP指定名前IDフォーマット

- IdP指定名前ID修飾子

- プロトコルのバージョン

サービス・プロバイダで名前識別子管理(MNI)操作を実行してフェデレーションを更新すると、次のフィールドの値が更新されます。

- SP指定名前ID

- SP指定名前IDフォーマット

- SP指定名前ID修飾子

- SP指定名前IDバージョン

次のフィールドは、フェデレーション・レコードの作成時には空白になります。

- SP指定名前IDフォーマット

- SP指定名前ID修飾子

- SP指定名前IDバージョン

4.4.2 アイデンティティ - フェデレーション

このページは、フェデレーテッド・アイデンティティ・レコードの検索およびメンテナンスを行う場合に使用します。

簡易検索

次の検索フィールドがあります。

- プロバイダID: プロバイダIDを入力して「参照」をクリックし、信頼できるプロバイダのリストから適切なIDを選択します。このフィールドにプロバイダIDを入力すると、指定したプロバイダで作成されたフェデレーテッド・アイデンティティのみに限定して検索が行われます。プロバイダIDを指定しない場合は、すべての信頼できるプロバイダで作成されたフェデレーテッド・アイデンティティを対象に検索が行われます。

- 検索値: 検索する値を入力します。値を指定しない場合は、すべてのフェデレーテッド・アイデンティティ・レコードが返されます。

検索によってフェデレーション・レコードの表が返されます。表に表示される列は、検索オプションの構成で構成されているデフォルト表示属性によって異なります。

関連項目:
第4.4.4項「アイデンティティ - 検索オプション」

拡張検索

拡張検索を実行するには、次の手順を実行します。

- 「プロバイダID」またはその一部を入力して「参照」をクリックし、信頼できるプロバイダのリストから適切なIDを選択します。このフィールドにプロバイダIDを入力すると、指定したプロバイダで作成されたフェデレーテッド・アイデンティティのみに限定して検索が行われます。プロバイダIDを指定しない場合は、すべての信頼できるプロバイダで作成されたフェデレーテッド・アイデンティティを対象に検索が行われます。

- 新規および旧名前IDの値をフェデレーション・レコードの検索に含めるには、「新規および旧名前IDを検索に含める」を選択します。

注意:
新規および旧名前IDの各フィールドは、フェデレーション・レコードに対して以前に更新操作が実行されていて、プロトコルが有効になっている場合にのみ移入されます。
NameID登録が無効になっているか、これまでに更新操作が実行されていない場合は、検索操作でこれらのフィールドを含める必要はありません。

- 「演算子」ラジオ・ボタンを使用して、返されるレコードがすべての条件を満たしている必要がある(And)か、いずれかの条件を満たしていればよい(Or)かを指定します。

- 検索条件を追加するには、次の手順に従います。

- 「属性の追加」をクリックします。

- ポップアップ・ボックスが表示されます。ドロップダウン・リストを使用してフェデレーテッド・アイデンティティの属性を選択し、「OK」をクリックします。

- 属性が検索オプションとして表示されます。使用するコンパレータおよび検索する値を選択します。

- 「検索」をクリックします。

レコードの管理

表示されたレコードを管理するには、対応する行を選択します。ページにあるボタンの機能は次のとおりです。

- 更新 - 名前ID管理(MNI)操作を実行して、フェデレーテッド・アイデンティティの名前IDを更新します。詳細は、第4.4.1項「フェデレーテッド・アイデンティティについて」を参照してください。

- 削除 - 名前ID管理(MNI)操作を実行して「Terminate」フラグをtrueに設定し、レコードを削除することによってフェデレーテッド・アイデンティティを終了します。

これらの機能は、SAML 2.0およびLiberty 1.xプロトコルの場合に使用できます。

注意:
Liberty 1.xのサポートは非推奨です。

4.4.3 アイデンティティ - ユーザー

このページは、ユーザー・レコードの検索およびメンテナンスを行う場合に使用します。

簡易検索

ローカル・ユーザーのエントリで検索する値を入力し、「検索」をクリックします。値を指定しない場合は、すべてのユーザーが返されます。

検索によってユーザー・レコードの表が返されます。表に表示される列は、検索オプションの構成で構成されているデフォルト表示属性によって異なります。

関連項目:
第4.4.4項「アイデンティティ - 検索オプション」

拡張検索

拡張検索を実行するには、次の手順を実行します。

- 「演算子」ラジオ・ボタンを使用して、返されるレコードがすべての条件を満たしている必要がある(And)か、いずれかの条件を満たしていればよい(Or)かを指定します。

- 検索条件を追加するには、次の手順に従います。

- 「属性の追加」をクリックします。

- ポップアップ・ボックスが表示されます。リストからユーザーの属性を選択し、「OK」をクリックします。

注意:
このリストに表示される属性は、第4.4.4項「アイデンティティ - 検索オプション」の検索オプションの構成で構成した属性です。

- 属性が検索条件として表示されます。使用するコンパレータおよび検索する値を選択します。

- 「検索」をクリックします。

4.4.4 アイデンティティ - 検索オプション

このページは、ユーザーおよびフェデレーションのレコードの検索で使用する属性を構成する場合に使用します。

このページには、次の2つの表が表示されます。

- 「フェデレーション」表には、「アイデンティティ」ページのアイデンティティ - フェデレーション・レコードタブで使用可能な属性が表示されます。表示される内容は次のとおりです。

- 属性の表示名

- この属性が簡易検索のデフォルト検索属性かどうか、つまり、この属性に対して簡易検索が行われるどうか。

- 簡易検索および拡張検索の結果にこの属性がデフォルトで表示されるかどうか。

チェック・ボックスを使用して、デフォルトで使用できるようにする属性を検索用と表示用のそれぞれに指定します。「適用」をクリックして、変更を保存します。

- 「ローカル・ユーザー」表には、「アイデンティティ」ページのアイデンティティ - ユーザータブで使用可能な属性が表示されます。表示される内容は次のとおりです。

- ユーザー・データ・ストアの属性の名前

- 属性の表示名

- この属性が簡易検索のデフォルト検索属性かどうか、つまり、この属性に対して簡易検索が行われるどうか。

- 簡易検索および拡張検索の結果にこの属性がデフォルトで表示されるかどうか。

チェック・ボックスを使用して、デフォルトで使用できるようにする属性を検索用と表示用のそれぞれに指定します。「適用」をクリックして、変更を保存します。

「作成」をクリックして、別の属性をリストに追加します。次の値を入力します。

- 属性名 - ユーザー・データ・ストアの属性名。

- 表示名 - この属性を参照したときに表示される名前。

- デフォルト検索属性 - 簡易検索でこの属性を検索する場合に選択します。

- デフォルト表示属性 - この属性を検索結果に表示する場合に選択します。

- ソート対象 - この属性の値に基づいて検索結果をソートする場合に選択します。

表示および検索で使用可能な属性のリストから属性を削除するには、その属性を選択して「削除」をクリックします。属性を削除すると、その属性は使用できなくなりますが、「作成」を使用して、その属性をリストに追加しなおすことができます。

フェデレーテッド・アイデンティティの属性

使用できる属性は、次のとおりです。

- ユーザー名

- ユーザーの説明

- IdP ID

- IdPフォーマット

- IdP修飾子

- プロトコルのバージョン

- SPプロバイダID

- SPプロバイダIDフォーマット

- SPプロバイダIDバージョン

- プロバイダID

- フェデレーション・タイプ
フェデレーション・タイプには次の値を指定できます。

- 1 - IdPとして動作するこのサーバーとSP間のフェデレーション

- 2 - IdPとして動作するこのサーバーとアフィリエーション間のフェデレーション

- 3 - SPとして動作するこのサーバーとIdP間のフェデレーション

- 4 - アフィリエーションとして動作するOracle Internet DirectoryサーバーとIdP間のフェデレーション

新規および旧名前IDの値をフェデレーション・レコードの検索操作に含めるには、「新規および旧名前IDを検索に含める」を選択します。

新規および旧名前IDの各フィールドは、フェデレーション・レコードに対して以前に更新操作が実行されていて、NameID登録プロトコルが有効になっている場合にのみ移入されます。

プロトコルが無効になっているか、これまでに更新操作が実行されていない場合は、検索操作でこれらのフィールドを含める必要はありません。

ユーザーの属性

ローカル・ユーザーの検索を実行するには、「検索オプション」タブの「ローカル・ユーザー」表にユーザーの属性を追加する必要があります。ただし、ユーザー・データ・ストアのタイプがLDAPの場合は、次の属性があらかじめ追加されています。

- 電子メール・アドレス

- ユーザーID

- 姓

- 名

4.5 Oracle Identity Federationの資格証明の管理

Oracle Identity Federationで使用されるいくつかのプロパティは、資格証明ストアに格納されています。表4-3にプロパティのリストを示します。

注意:
引用符付きの値は、格納されているリテラル値です。

表4-3 資格証明ストアに格納されているOracle Identity Federationのプロパティ

キー

説明

Username

Password

別名

jcepwdsign

PKCS#12/JCE署名パスワード

"UniqueUserNameCredential"

password

ApplicationName

oldjcepwdsign

旧PKCS#12/JCE署名パスワード

"UniqueUserNameCredential"

password

ApplicationName

jcepwdenc

PKCS#12/JCE暗号化パスワード

"UniqueUserNameCredential"

ApplicationName

oldjcepwdenc

旧PKCS#12/JCE暗号化パスワード

"UniqueUserNameCredential"

password

ApplicationName

userldappassword

ユーザー・データ・ストアのLDAP資格証明

User Store Bind DN (userldapusername)

password

ApplicationName

fedldappassword

フェデレーション・データ・ストアのLDAP資格証明

Fed Store Bind DN (fedldapusername)

password

ApplicationName

ldappassword

LDAP認証エンジンのLDAP資格証明

Auth Engine Bind DN (ldapbinddn)

password

ApplicationName

ossopartnerkey

Oracle SSOパートナ・キー

"UniqueUserNameCredential"

password

ApplicationName

ossooldpartnerkey

旧Oracle SSOパートナ・キー

"UniqueUserNameCredential"

password

ApplicationName

proxypassword

Fusion Middleware Controlの「サーバー・プロパティ」ページのプロキシ・パスワード

プロキシ・ユーザー名(proxyuser)

password

ApplicationName

PROVIDER_ID

ピア・プロバイダ固有のページでのHTTP Basic認証用パスワード

HTTP Basic認証のユーザー名(authnbasicusername)

password

ApplicationName

次の点に注意してください。

- パスワードは構成時にユーザーが入力します。

- ApplicationNameは、Oracle Identity Federationのデプロイ時に使用される名前です(デフォルトではOIF)。

- Authn Engine Bind DNは、ユーザーがLDAP認証エンジンに指定したバインドDNです。

- Fed Store Bind DNは、ユーザーがLDAPフェデレーション・ストアに指定したバインドDNです。

- User Store Bind DNは、ユーザーがユーザー・アイデンティティ・ストアに指定したバインドDNです。

手動による資格証明の管理

注意:
次のWLSTコマンドを実行するときには、Oracle Identity Federationが実行されている管理対象サーバーではなく、管理サーバーに接続してください。

Fusion Middleware Controlを使用してOracle Identity Federationを構成すると、資格証明は自動的に資格証明ストアに格納されます。

必要に応じて、WLSTコマンドを使用するか、Fusion Middleware Controlを使用して、これらの資格証明を手動で更新できます。

関連項目:
この2つのツールを使用した構成方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の資格証明ストアの構成に関する項を参照してください。

WLSTの対話モードの使用例として、Oracle Identity Federationにアクセスできるようにuserldappasswordを資格証明ストアに格納する場合は、次のコマンドを発行します。

この例では、LDAPバインドdnはcn=orcladminであり、passwordには正しいパスワードが代入されていて、Oracle Identity FederationがOIFというアプリケーション名でデプロイされていることを想定しています。

userldappassword資格証明を作成するには、次のようにします。

createCred(map="OIF", key="userldappassword",
user="cn=orcladmin", password="password", desc="user ldap password")

userldappassword資格証明を更新するには、次のようにします。

updateCred(map="OIF", key="userldappassword",
user="cn=orcladmin", password="password", desc="User ldap password")

userldappassword資格証明を削除するには、次のようにします。

deleteCred(map="OIF", key="userldappassword")

5 Oracle Identity Federationの構成

この章では、Oracle Identity Federationの構成タスクについて説明します。内容は次のとおりです。

- Oracle Identity Federationがメンテナンスするデータ

- サーバー・プロパティの構成

- アイデンティティ・プロバイダの構成 - 共通プロパティ

- アイデンティティ・プロバイダの構成 - プロトコル固有のプロパティ

- サービス・プロバイダの構成

- Oracle Access Manager AuthZプラグインによる属性共有の構成

- SSOアサーションで属性を送信するアイデンティティ・プロバイダの構成

- 属性共有用のWebサービス・インタフェース

- 属性マッピングおよびフィルタリングの構成

- セキュリティおよび信頼の構成

- フェデレーションの構成

- アイデンティティの構成

- データ・ストアの管理

- 認証メカニズムの構成

- 認証エンジンの構成

- SP統合モジュールの構成

5.1 Oracle Identity Federationがメンテナンスするデータ

Oracle Identity Federation管理者はサーバーの管理と運用に必要なデータを、サード・パーティ(他のプロバイダの管理者)、サード・パーティとのアグリーメント、ローカル構成の決定事項など、様々な情報源から取得します。管理者は、フェデレーション・サーバーのロードとメンテナンスを担当します。

大きく分けて、フェデレーション・サーバーは2つのカテゴリの詳細構成をメンテナンスします。

- サーバー構成データ: 実行時のフェデレーション・サーバー・インスタンスの動作を規定するプロパティなど

- ユーザー・フェデレーション・データ: 個別ユーザーのフェデレーテッドIDや使用方法の情報

注意:
Liberty 1.xのサポートは非推奨です。

5.1.1 サーバー構成データ

各Oracle Identity Federationインスタンスは2つのタイプの構成データをメンテナンスします。

- プロトコル・データ。次のものが含まれます。

- サーバー・インスタンス全体のプロパティ(ホスト名とポート、SSLが有効かどうか、署名および暗号化PKCS#12/JKSキーストアなど)。

- サーバー・インスタンスがアイデンティティ・プロバイダとして動作しているときに、有効なフェデレーション・プロトコルをサポートする方法(セッション・タイムアウト、再認証タイムアウト、デフォルトのプロバイダIDなど)。

- サーバー・インスタンスがサービス・プロバイダとして動作しているときに、有効なフェデレーション・プロトコルをサポートする方法。このケースでメンテナンスされるデータは、サーバーがアイデンティティ・プロバイダとして動作するときに格納されるデータに非常に類似しています。

- このサーバーの信頼できるプロバイダであるピア・プロバイダに関する情報。信頼できるプロバイダの構成データには、次のものが含まれます。

- アサーションで使用する名前IDフォーマット

- 認証レスポンスとともに送信する属性

- アサーションと認証リクエストの署名要件

- 優先バインディング

- アサーションとアーティファクトの有効期間

- その他の時間関連パラメータ(同期していないサーバーの間の許容時間差など)

- アカウント・リンキング・パラメータ

構成設定とプロバイダ・メタデータ

構成設定とサーバーが生成するプロバイダ・メタデータの間に関係が存在する場合があることに注意してください。メタデータに影響を与える設定と与えない設定があります。たとえば、「セッション・タイムアウト」値の変更はメタデータに影響を与えませんが、「SOAPポート」の変更には、管理者が、他の信頼できるプロバイダにメタデータを再公開することが必要です。同様に、管理者はピア・プロバイダのメタデータに対する変更を認識している必要があります。

メタデータに影響を与えるプロパティのリストを次に示します。

- メタデータ・プロパティ

- メタデータの署名

- 有効期間

- サーバー・プロパティ

- サーバー・ホスト名

- サーバー・ポート

- SOAPポート

- IdpEnabled

- SpEnabled

- SSL有効

- 署名PKCS #12/JKSキーストア

- 暗号化PKCS #12/JKSキーストア

- 共通のIdPプロパティ

- プロバイダID

- SAML 2.0有効

- 共通のSPプロパティ

- プロバイダID

- SAML 2.0有効

- 属性リクエスタ・サービスの有効化

- SAML 2.0 IdPプロパティ

- プロトコル・プロファイルの有効化

- フェデレーション終了有効

- 名前ID登録有効

- 属性レスポンダ有効

- SAML 2.0 SPプロパティ

- プロトコル・プロファイルの有効化

- フェデレーション終了有効

- 名前ID登録有効

各種プロトコルのメタデータURLの形式は次のとおりです。

注意:
Fusion Middleware Controlからメタデータを取得するには、「セキュリティおよび信頼」→「プロバイダ・メタデータ」の順に移動します。

- IdPメタデータのURL - http(s)://hostname:port/fed/idp/metadata?version=version

- SPメタデータのURL - http(s)://hostname:port/fed/sp/metadata?version=version

versionにはsaml20、saml11、saml10、lib11またはlib12を指定できます。

5.1.2 ユーザー・フェデレーション・データ

データ・ストアには各ユーザーのアイデンティティ・フェデレーション・データが格納されます。データ・ストアにはLDAPディレクトリまたはRDBMSを使用できます。ユーザーの基本参照情報の他、ユーザーに関連付けられた一意の各アイデンティティ・フェデレーションごとにレコードがあります。フェデレーション・レコードは次のものにより定義されます。

- リモート・プロバイダ

- 名前識別子のタイプ(たとえば、電子メール・アドレスやDN)

- プロトコル(たとえば、SAML 2.0)

これは、これらの3つの属性の組合せが一意であるかぎり、同一のリモート・プロバイダに対してユーザーが複数のアイデンティティ・フェデレーション・レコードを持つことができることを意味します。たとえば、ユーザーの最初のレコードがProviderX/myemail1/SAML 2.0の組合せ、2番目のレコードがProviderX/myemail2/SAML 2.0の組合せで識別されることがありえます。

同期

前述のとおり、フェデレーション・レコードはユーザーごとに独立して格納され、一意のユーザー属性(DN、ユーザー名など)を使用してユーザー・データ・ストアのユーザー・レコードにリンクします。

ユーザーの一意属性値を変更するイベント、たとえば従業員がオフィスで新しい場所に移動し、DNが更新されたような場合などは、ユーザーのフェデレーションを削除して再確立する必要があります。

ユーザー・ストアのユーザーの属性値が変更された場合は、Fusion Middleware Controlの「アイデンティティ」ページなどからユーザーのフェデレーション・レコードを更新できます。

プロビジョニング解除

同様に、ユーザーのレコードが削除されてもフェデレーション・データは残ります。これは、ユーザーがプロビジョニング解除される場合、管理者がユーザーのフェデレーション・データを確実に削除する必要があることを意味します。

注意:
この状況でフェデレーション・データを削除しない場合、セキュリティ上の問題が発生する可能性があります。たとえば、新しいユーザーがそれ以後に同一の一意属性値(たとえば、同一のDNまたはユーザー名)でプロビジョニングされたとします。以前のユーザーのアカウント・リンクが残されていた場合、それを新しいユーザーが引き継いでしまう可能性があります。

フェデレーション・データは次の方法で削除できます。

- LDAPサーバーまたはデータベースの管理ツールを使用します。Oracle Internet Directoryに格納されたデータの詳細は、『Oracle Identity Managementユーザー・リファレンス』を参照してください。

- Oracle Identity Federationに用意されているコマンドライン・ユーティリティを使用します。詳細は、第9章「Oracle Identity Federationコマンドライン・ツール」を参照してください。

5.2 サーバー・プロパティの構成

サーバー・プロパティには次のものがあります。

- ホスト接続のプロパティ

- アウトバウンド接続のプロパティ

5.2.1 ホスト接続のプロパティ

サーバーに対して次のタイプのプロパティが構成されます。

- 基本的な接続パラメータ

- 暗号化設定

- ログアウト・オプション

接続パラメータ

次のパラメータを構成できます。

- ホスト
Oracle Identity Federationインスタンスのホスト名です。

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

サーバーのホストまたはポートを変更する場合は、仮想ホスト名またはプロキシ・サーバー・ホスト名を定義するか、サーバーのホスト・プロパティを変更します。

- ポート
Oracle Identity Federationがリスニングするポートです。

注意:

- この設定は、メタデータ生成時にIdPおよびSPのメタデータ内でどのサーバー・ポートが指定されるかだけを規定します。Oracle Identity Federationが実行されているコンテナ・インスタンスに対して複数のHTTPまたはHTTPSポートが有効である場合、ユーザーまたはピア・プロバイダは、ここで指定されたポートだけでなく、それらのいずれのポートからでもOracle Identity Federationにアクセスできます。

- このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

「SSL有効」ボックスを選択すると、Secure Sockets Layer(SSL)暗号化が有効になり、サーバーでHTTPSモードでのリスニングが可能になります。

注意:

- このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- この設定は、メタデータ生成時にIdPおよびSPのメタデータ内でどのプロトコル(httpまたはhttps)が指定されるかだけを規定します。このプロパティを設定してもSSLの構成は行われません。SSLを有効にする方法の詳細は、次を参照してください。

- 第8.1項「Oracle Identity FederationでのSSLの構成」

- 『Oracle Fusion Middleware管理者ガイド』

「強制SSL」ボックスを選択すると、サーバーとの通信が強制的にHTTPSモードで行われます。HTTPSモードで実行されている場合、Oracle Identity Federationでは着信接続がSSLで実行されているかチェックされます。HTTPSモード以外の場合、サーバーはSSLをサポートしているURLにユーザーをリダイレクトします。このURLは、ホスト名およびポートの各プロパティ、およびリクエストされたURLで作成されています。

- SOAPポート
Oracle Identity FederationがSOAPメッセージをリスニングするポートです。

注意:

- この設定は、メタデータ生成時にIdPおよびSPのメタデータ内でどのSOAPポートが指定されるかだけを規定します。Oracle Identity Federationが実行されているコンテナ・インスタンスに対して複数のHTTPまたはHTTPSポートが有効である場合、ユーザーまたはピア・プロバイダは、ここで指定されたポートだけでなく、それらのいずれのポートからでもOracle Identity Federationにアクセスできます。

- このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

「SSL有効」ボックスを選択すると、Secure Sockets Layer(SSL)暗号化が有効になり、サーバーでHTTPSモードでのリスニングが可能になります。

注意:

- このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- このプロパティを設定してもSSLの構成は行われません。SSLを有効にする方法の詳細は、次を参照してください。

- 第8.1項「Oracle Identity FederationでのSSLの構成」

- 『Oracle Fusion Middleware管理者ガイド』

「強制SSL」ボックスを選択すると、サーバーとの通信が強制的にHTTPSモードで行われます。HTTPSモードで実行されている場合、Oracle Identity Federationでは着信接続がSSLで実行されているかチェックされます。HTTPSモード以外の場合、サーバーはSSLをサポートしているURLにユーザーをリダイレクトします。このURLは、ホスト名およびポートの各プロパティ、およびリクエストされたURLで作成されています。

「クライアント証明書が必要」を選択すると、すべての着信SOAP接続で強制的にSSLクライアント認証が行われます。

- サーバー・クロック・ドリフト
Oracle Identity Federationと、そのピア・サーバーとの間で許容される時間の誤差です。デフォルトは600秒です。

- セッション・タイムアウト
このパラメータは、認証されたセッションがアクティブである期間を秒単位で指定するために使用されます。アクティブな期間を過ぎるとセッションは非アクティブになり、ユーザーは再認証を受ける必要があります。デフォルト値は7200秒です。

このパラメータがどのように使用されるかはサーバーのロールと問題のセッションの性質に依存します。

シナリオ1: ローカルに認証されたユーザー

ユーザーをローカルに認証できるのは次の場合です。

- Oracle Identity FederationがIdPとして動作している場合

- Oracle Identity FederationがSPで、新しいフェデレーションが作成されたため、ユーザーに対して資格証明を求める必要がある場合

この場合、認証されたセッションの有効期間は、「セッション・タイムアウト」パラメータの値に設定されます。

シナリオ2: 既存のフェデレーション

Oracle Identity Federationが既存のフェデレーションに対してSPとして動作している場合、サーバーは、ユーザーと認証情報が含まれているSAMLアサーションをIdPから受信します。アサーションにはReauthenticateOnOrAfter属性が含まれることがあります。この属性は、この属性が指定する期間が過ぎたら、このユーザーは再認証が必要であることをOracle Identity Federationに対して示しています。

この場合、SPとして動作するOracle Identity Federationサーバーが、認証されたセッションの有効期間を、Session Timeoutパラメータと、ReauthenticateOnOrAfterアサーション属性の、いずれか少ない方に設定します。

注意:
Oracle Identity Federationがユーザー・データ・ストアとしてOracle Access Managerを使用する場合、セッション・タイムアウトはユーザー・セッションに影響しません。Oracle Access Managerでは、セッション・タイムアウトは、アクセスされたリソースを保護しているAccessGateの構成によって決定されます。

- リクエスト・タイムアウト
Oracle Identity Federationから送信するリクエストの有効期間です(単位は秒)。デフォルトは120秒です。

暗号化設定

「デフォルトXMLデータ暗号化アルゴリズム」で、次の使用可能な暗号化アルゴリズムのいずれかを選択します。

- AES-128 CBC

- Triple DES CBC

- AES-192 CBC

- AES-256 CBC

注意:
AES-128 CBC以外の暗号化方式では、JCE暗号化パッケージのインストールが必要です。第8.3項「Oracle WebLogic ServerでのJCEポリシー・ファイルの設定」を参照してください。

ログアウト・オプション

次のログアウト・オプションのいずれかを構成できます。

- エラーでの失敗
グローバル・ログアウト・フローでエラーが発生すると、Oracle Identity Federationは操作を中断してエラーをスローするか、ログアウト操作を継続して終了させます。

- ステータス・リターン
戻る: 有効な場合に、/fed/user/logout URLにアクセスしてOracle Identity Federationのログアウト操作が開始されると、サーバーはログアウト操作の終了時にユーザーをreturnURLにリダイレクトし、ログアウト操作の結果を示す問合せパラメータをそのURLに追加します。

問合せパラメータ名はorafed_slostatusです。また、指定できる値は次のとおりです。

- 0: 成功

- 1: 失敗

- ローカルのみログアウト
有効な場合は、Oracle Identity Federationは、ユーザーのログアウト処理実行時に、WS-Fed/SAMLログアウト・プロトコルを呼び出しません。かわりに、認証エンジンと、IDおよびアクセス管理フレームワークからのユーザーのログアウトのみが記録され、Oracle Identity Federationセッションが破棄されます。

- パラレル・ログアウト
デフォルトでは、Oracle Identity FederationはSAML/WS-Fedグローバル・ログアウト操作実行時に、ログアウトが必要なすべてのプロバイダに対してユーザーを順次にリダイレクトします。この操作には時間がかかることがあります。また、プロバイダからの応答が得られず、任意のポイントでログアウト・フローが失敗すると、ログアウト・フローは終了しません。「パラレル・ログアウト」を有効にすると、ユーザーにはOracle Identity Federationによってフレームが含まれるページが表示され、それぞれのフレームが1つの特定のプロバイダに対してSAML/WS-Fedログアウト処理を実行します。これにより、ログアウト・フローのグローバル・パフォーマンスを向上させ、処理の中断を最小限に抑えることができます。

5.2.2 アウトバウンド接続のプロパティ

アウトバウンドSOAP接続

次のパラメータを構成できます。

- 最大SOAP接続数

- サーバーごとの最大SOAP接続数

Oracle Identity Federationは、各種バインディング、中でもSOAPバインディンを使用して、リモートSAMLサーバーと通信できます。Oracle Identity Federationは、SOAPプロトコルを使用してリモート・サーバーにメッセージを送信する必要がある場合、接続を直接オープンしてSOAPメッセージを送信します。

Oracle Identity Federationでは、SOAPメッセージの送信時にオープンできる最大同時接続数、および特定のプロバイダへのSOAPメッセージの送信時にオープンできる最大同時接続数を構成できます。

HTTPプロキシ設定

このセクションは、送信SOAP接続でプロキシを使用するようにOracle Identity Federationを構成するために使用します。

- プロキシ・ホスト - プロキシ・ホスト名。

- プロキシ・ポート - プロキシ・ポート番号。

- ユーザー名 - プロキシへの接続時に使用するユーザー名。

- パスワード - プロキシへの接続時に使用するパスワード。

- 非プロキシ・ホスト - プロキシを使用しないホストのリスト。複数のホストを指定する場合は、「;」で区切ります。

5.3 アイデンティティ・プロバイダの構成 - 共通プロパティ

IdPの有効化

サーバーをIdPとして有効にするには:

- 「アイデンティティ・プロバイダの有効化」ボックスを選択します。

- 「プロバイダID」を指定します。
Oracle Identity FederationインスタンスのURIです。URLの場合は、実際のリソースを参照している必要があります。

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

アサーション設定

次のようにアサーション・パラメータを指定します。

- 署名付アサーションの送信
アイデンティティ・プロバイダが発行するアサーションに署名を付けるかどうかを決定します。

- アサーション有効期間
アイデンティティ・プロバイダが発行したアサーションの有効期間です(単位は秒)。有効期間外に処理されたアサーションは無効とみなされます。デフォルトは300秒です。

- 再認証までの時間
これがその有効期間で、これを過ぎるとサービス・プロバイダはユーザーを再度認証する必要があります(単位は秒)。アイデンティティ・プロバイダによる認証ステートメントを含んでいるアサーションが有効なのはこの期間だけで、それを過ぎるとユーザーは認証されていないものとみなされます。デフォルトは3600秒です。

プロトコル設定

次のようにプロトコル設定を指定します。

- アーティファクト・タイムアウト
Oracle Identity Federationによって作成されるアーティファクト・オブジェクトの有効期間です(単位は秒)。デフォルトは300秒です。

- XML署名に署名証明書を含める
選択した場合、送信メッセージのXMLデジタル署名要素にOracle Identity Federationの署名証明書が追加されます。これは、メッセージに含まれる署名証明書がOracle Identity Federationによって作成された署名であることをリモート・プロバイダで検証する必要がある場合に有用です。

- 共通ドメイン

関連項目:
第6.10項「SAML 2.0 IdP検出(共通ドメインCookie)プロファイルの構成」

アイデンティティ・フェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれるとき、サービス・プロバイダは、プリンシパルが使用するアイデンティティ・プロバイダを決定するための方法を必要とします。そのため、フェデレーション・ネットワーク内でIdPとSPに共通のドメインを使用して、このドメインで書かれ、ユーザーがログインしているすべてのIdPが記載されたCookieがユーザーのブラウザに送信されます。このようなドメインは共通ドメインと呼ばれ、IdPを識別するCookieは共通ドメインCookieまたは導入Cookieと呼ばれます。

このIdPが概要Cookieを設定するように指定するには、「共通ドメインの有効化」を選択します。ローカル認証が行われるたびに、Oracle Identity Federationはユーザーを共通ドメインにリダイレクトし、ここでサーバーがその識別子をユーザーのブラウザの概要Cookieに追加できます。

共通ドメインを設定する場合、次のパラメータは必須です。

- 共通ドメインURL
アイデンティティ・フェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれている場合、すべてのプロバイダに共通のドメインが、サービス・プロバイダがプリンシパルで使用されているアイデンティティ・プロバイダを判別するためのひとつの方法となります。認証が行われるたびに、ユーザーのブラウザ上のCookie (このドメインで書き込まれたもの)がIdP識別子で更新され、このCookieにすべてのユーザーのIdPがリストされサービス・プロバイダから読み取ることができます。

Oracle Identity FederationがIdP導入Cookieを読み取ったり設定したりする場所のURLを入力します。サーバーはこのURL上でリスニングし、リクエストを受け入れ、ユーザーのブラウザ上の導入Cookieを更新します。

共通ドメインを有効にする場合にのみ、この値を設定します。

- 名前
IdP概要Cookieに使用される共通ドメインです。概要Cookieでは、Cookieパラメータとして設定されます。この値は、ドット(.)で始まる、.domain.suffixの形式にする必要があります。デフォルト値は、.DOMAIN_TO_BE_SETです。

- Cookie存続期間(日)
IdPが発行する共通ドメインCookieの存続期間(単位は日)です。このフィールドが0に設定されている場合(デフォルト)、共通ドメインCookieはセッションCookieです。

- SSOユーザー・オプトイン/オプトアウト
そのユーザーにフェデレーテッド・シングル・サインオンの実行権限が付与(または拒否)されているかどうかを、ユーザーのディレクトリ・レコードの属性値に基づいて判断します。

関連項目:
詳細は、第6.18項「シングル・サインオンでのユーザー・オプトインおよびオプトアウト」を参照してください。

- ユーザー・セッション属性の欠落時に再認証
Oracle Identity FederationがIdPとして動作する場合、セッションに保存される属性を使用してアサーションに移入できます。セッション属性は次のように設定されます。

- Oracle Identity Federationユーザー・セッションに格納される属性がカスタム認証エンジンによって提供される場合は、認証時に設定されます。

- Oracle Identity Federationがサービス・プロバイダとして動作する場合は、アサーションの内容(名前ID、属性など)をユーザー・セッションに保存できます。デフォルトではそれらのデータは保存されません。

アサーションが作成されると、ユーザー・セッションから取得してアサーションに組み込む必要のある属性がOracle Identity Federation/IdPによってリストされます。アサーションに必要な一部の属性がユーザーセッションにない場合は、その属性を切り捨てるか、認証フレームワークを呼び出してそれらの属性をカスタム認証エンジンから取得できるようにOracle Identity Federationを構成できます。

5.4 アイデンティティ・プロバイダの構成 - プロトコル固有のプロパティ

この項では、IdPプロトコル固有のプロパティを構成する方法について説明します。

- SAML 2.0 IdPプロパティの構成

- SAML 1.x IdPプロパティの構成

- WS-Federation IdPプロパティの構成

- OpenID IdPプロパティの構成

- 外部OpenIDプロバイダの構成

5.4.1 SAML 2.0 IdPプロパティの構成

アサーション・プロパティ

このページのこの部分は、SAML 2.0プロトコルのアサーション名前識別子フォーマットをメンテナンスするために使用します。

次の情報を表で指定します。

- 有効 - Oracle Identity FederationインスタンスがIdPモードでSAML 2.0名前識別子の値として使用するフォーマットを有効にするには、希望のフォーマットに対応するボックスを選択します。

- デフォルト - ラジオ・ボタンを使用してデフォルトの名前IDフォーマットを選択します。

- ユーザー・セッションから値を取得 - このボックスを選択すると、対応する名前IDがマップされている属性を、ユーザーの認証時に作成されたセッション内で検索するように指定できます。

- 名前IDフォーマット - この列には使用可能な名前識別子フォーマットが表示されます。フォーマットは次のとおりです。

表5-1 SAML 2.0 IdPの名前IDフォーマット

名前IDフォーマット

デフォルト値

X.509サブジェクト名

dn

電子メール・アドレス

mail

Windowsドメイン修飾名

空

Kerberosプリンシパル名

空

カスタム

未指定

永続識別子

一時/単発識別子

なし

- ユーザー属性マッピング - 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストア(または「ユーザー・セッションから値を取得」が選択されている場合はユーザー・セッション)から、このフォーマットの名前IDを検索します。

注意:
「アサーション・サブジェクト名前IDフォーマット」表のユーザー属性を「orafed-userid」に設定すると、NameID要素を移入する際にユーザーIDを使用できます。これは、IdP用のユーザー・ストアが構成されておらず、使用可能なユーザー・ストア属性がない場合に特に役立ちます。

注意:
この表は、送信アサーションの作成時に使用されます。Oracle Identity Federation/IdPは、名前IDフォーマットに応じて次のことを行います。

- 「X.509サブジェクト名」、「電子メール・アドレス」、「Windowsドメイン修飾名」、「Kerberosプリンシパル名」および「未指定」の場合は、サーバーが構成を確認して、NameID要素の移入とユーザー・レコードからの値の取得に、どのユーザー属性を使用するかを判断します。

- 「カスタム」の場合は、サーバーが構成を確認して、NameID要素の移入とユーザー・レコードからの値の取得に、どのユーザー属性を使用するかを判断します。また、名前IDのフォーマットを、構成で指定されている値に設定します。

- 「永続識別子」の場合は、サーバーはランダムに生成された識別子を使用して名前IDを作成します。この識別子は、後続の処理でこのユーザーとリモート・プロバイダを関連付けるためにフェデレーション・レコードとして保存されます。

- 「一時/単発識別子」の場合は、サーバーはランダムに生成された識別子を使用して名前IDを作成します。この名前IDは1回しか使用されません。

- 「なし」の場合は、サーバーはいずれの名前IDもアサーションに組み込みません。

カスタム・フォーマット名 - カスタム名前IDフォーマットを使用するアサーションの作成時に、名前IDで使用されるフォーマットです。

名前IDとしてのユーザーID

「アサーション・サブジェクト名前IDフォーマット」表のユーザー属性を「orafed-userid」に設定すると、NameID要素を移入する際にユーザーIDを使用できます。この機能は、IdP用のユーザー・ストアが構成されておらず、使用可能なユーザー・ストア属性がない場合に特に役立ちます。

その他のアサーションフィールド

表の下にあるフィールドは次のとおりです。

- フェデレーション作成ユーザー承諾URL
ユーザーが新しいフェデレーションに同意する必要がある場合、これはユーザーがリダイレクトされる先のURLです。このための承諾ページをデザインする必要があります。

- ユーザー承諾を強制
このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。このボックスが選択されている場合、フェデレーション・サーバーにリダイレクトされたユーザーが続行するためには、リンクを明示的に承諾または拒否する必要があります。

- 暗号化された属性の送信
このボックスを選択すると、Oracle Identity Federationが暗号化された属性をピア・プロバイダに送信できるようになります。

- 暗号化された名前IDの送信
このボックスを選択すると、Oracle Identity Federationが暗号化された名前識別子をピア・プロバイダに送信できるようになります。

- 暗号化されたアサーションの送信
このボックスを選択すると、Oracle Identity Federationが暗号化されたアサーションをピア・プロバイダに送信できるようになります。

- 署名付きアサーションの送信
このボックスを選択すると、Oracle Identity Federationが署名付きのアサーションをピア・プロバイダに送信できるようになります。SAML 2.0プロトコルを使用する場合、アイデンティティ・プロバイダ - 共通タブで指定した値はこのページで指定した値で上書きされます。アイデンティティ・プロバイダ - 共通の値を上書きしたくない場合は、四角に入力できないように青い円をクリックすると、上の図で示したように四角を指す矢印が表示されます。

ユーザー承諾ページについて

ユーザーが新しいフェデレーションに同意する必要がある場合、ユーザーがリダイレクトされる承認ページを設計する必要があります。

サーバーはこのURLにいくつかの問合せパラメータを渡します。

表5-2 ユーザー承諾URLに渡されるパラメータ(SPグローバル)

パラメータ

説明

providerid

ピア・プロバイダのID。

description

ピア・プロバイダIDの説明。

returnurl

承諾意思決定がなされた場合にユーザーをリダイレクトする先のURL。

refid

returnurlに問合せパラメータとして渡されます。サーバーが承諾URLにリダイレクトされる前に実行していた操作をOracle Identity Federationが再開するには、このパラメータが必要です。

承諾URLページが戻り先URLにユーザーを導く際には(リンク、フォームの送信などの手段で)、表に説明があるrefidパラメータと、ユーザーが承諾したかどうかを示す承諾パラメータ(値はtrueまたはfalse)の、2つの問合せパラメータを渡す必要があります。

承諾ページの例を次に示します。

<%
String prefix = request.getContextPath();
String redirectURL = request.getParameter("returnurl");
String refID = request.getParameter("refid");
String providerID = request.getParameter("providerid");
String desc = request.getParameter("description");
%>
<HTML>
<BODY>
Do you consent to create a federation with <%=providerID%> (<%=desc%>):<br>
<form method="POST" action="<%=redirectURL%>">
<input type="checkbox" name="userconsent" value="true"/>I agree<br>
<input type="submit" value="OK" />
<input type="hidden" name="refid"  value="<%=refID%>"/>
</form>
</BODY>
</HTML>

プロトコル設定

- SAML 2.0プロトコルの有効化 - このボックスを選択すると、SAML 2.0プロトコルが有効になります。

- シングル・サインオン・プロトコルの有効化 - このボックスを選択すると、シングル・サインオン・プロトコルが有効になります。

- 名前ID管理プロトコルの有効化: 終了
このボックスを選択すると、フェデレーション終了機能が有効になります。

関連項目:
第1.2.4.8項「フェデレーション終了プロファイル」

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- 名前ID管理プロトコルの有効化: 登録: このボックスを選択すると、NameID登録が有効になります。

関連項目:
第1.2.4.5項「名前識別子管理プロファイル」

- 属性問合せレスポンダの有効化
このボックスを選択すると、アイデンティティ・プロバイダを属性認証局として動作させることができます。

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- 属性レスポンスのアイデンティティ・フェデレーションの使用
このボックスは、このアイデンティティ・プロバイダ内で属性リクエストのユーザーをフェデレーテッド・アイデンティティを使用して検索する場合に選択します。この設定を使用する場合、ユーザーはフェデレーションIDを持っている必要があります。また、名前IDの値とフォーマットがAttributeQueryで指定されているサブジェクトの値とフォーマットに一致する必要があります。

このボックスを選択すると、属性認証局はまずフェデレーション・ストア内でユーザーを検索しようとします。レコードが見つからない場合は、ユーザー・データ・ストアの属性値によってユーザーを特定します。

このプロパティは、「Oracle Identity Federation設定」タブの「信頼できるプロバイダの編集」ページで上書きすることもできます。

関連項目:
第5.6.6項「IdP属性レスポンダとしてのOracle Identity Federationの構成」

- 認証問合せレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダを認証局として動作させることができます。サービス・プロバイダは認証問合せを認証局に送信することにより、「認証のためにこのオブジェクトに発行されたアサーションの内容」を問い合せることができます。認証局は、指定されたサブジェクトを認証するために以前に発行されたアサーションを指定して応答します。

このボックスを選択すると、アイデンティティ・プロバイダを認証局として動作させることができます。

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- アサーションIDレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダをアサーションID認証局として動作させることができます。信頼できるサービス・プロバイダは、アイデンティティ・プロバイダが以前発行したアサーションの一意IDを提供するアサーションID認証局に対してアサーションIDのリクエストを送信できます。アサーションID認証局は、アサーションをリクエストのIDとともにアサーションを指定して応答します。

アイデンティティ・プロバイダをアサーションID認証局として動作させるには、このボックスを選択します。

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- プロトコル・バインディングの有効化
ドロップダウンで、有効化するすべてのプロトコル・バインディングを選択します。

- デフォルト・バインディング
アイデンティティ・プロバイダがリクエストまたはレスポンス(SSOレスポンスを除く)を送信する際に、優先バインディングが(名前ID管理プロトコル・メッセージなどで)指定されていない場合に、デフォルトとして使用するバインディングを選択します。

- デフォルトSSOレスポンス・バインディング
アイデンティティ・プロバイダがSSOレスポンスを送信する際に、優先バインディングがAuthnRequestで指定されていない場合に、デフォルトとして使用するバインディングを選択します。

- 署名付を送信/要求するメッセージ
Oracle Identity FederationがIdPモードで送信するときに署名が必要なメッセージ、およびOracle Identity FederationがIdPモードで受信するときに署名付を要求するメッセージを指定します。

注意:
署名付AuthnRequestの要求プロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

5.4.2 SAML 1.x IdPプロパティの構成

このページは、Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合に、SAML 1.0/SAML 1.1プロトコルを使用するよう構成する場合に使用します。このページには、アサーション設定用およびプロトコル設定用の表がそれぞれあります。

アサーション設定

この表には、構成可能な名前IDフォーマットが表示されます。次の情報を指定します。

- 有効 - このボックスを選択すると、対応する名前IDフォーマットが有効になります。

- デフォルト - ラジオ・ボタンを使用してデフォルトの名前IDフォーマットを選択します。

- ユーザー・セッションから値を取得 - このボックスを選択すると、対応する名前IDがマップされている属性を、ユーザーの認証時に作成されたセッション内で検索するように指定できます。

- 名前IDフォーマット - この列には使用可能な名前識別子フォーマットが表示されます。フォーマットは次のとおりです。

表5-3 SAML 1.xアイデンティティ・プロバイダの名前IDフォーマット

名前IDフォーマット

デフォルト値

X.509サブジェクト名

dn

電子メール・アドレス

mail

Windowsドメイン修飾名

空

未指定

空

カスタム

空

なし

- ユーザー属性マッピング - 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストア(または「ユーザー・セッションから値を取得」が選択されている場合はユーザー・セッション)から、このフォーマットの名前IDを検索します。

注意:
「アサーション・サブジェクト名前IDフォーマット」表のユーザー属性を「orafed-userid」に設定すると、NameID要素を移入する際にユーザーIDを使用できます。これは、IdP用のユーザー・ストアが構成されておらず、使用可能なユーザー・ストア属性がない場合に特に役立ちます。

署名付アサーションの送信 - このボックスを選択すると、Oracle Identity Federationが署名付きのアサーションをピア・プロバイダに送信できるようになります。SAML 1.0またはSAML 1.1プロトコルを使用する場合、アイデンティティ・プロバイダ - 共通タブで指定した値はこのページで指定した値で上書きされます。アイデンティティ・プロバイダ - 共通の値を上書きしたくない場合は、四角に入力できないように青い円をクリックすると、上の図で示したように四角を指す矢印が表示されます。

プロトコル設定

この表は、プロトコル設定および関連属性を指定するために使用します。

次の情報を指定します。

- プロトコル - 「SAML 1.1プロトコルの有効化」ボックスおよび「SAML 1.0プロトコルの有効化」ボックスのいずれかまたは両方を選択します。

- シングル・サインオン・プロトコルの有効化 - このボックスを選択すると、シングル・サインオン・プロトコルが有効になります。

- 属性問合せレスポンダの有効化 - このボックスを選択すると、アイデンティティ・プロバイダを属性認証局として動作させることができます。

- 認証問合せレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダを認証局として動作させることができます。サービス・プロバイダは認証問合せを認証局に送信することにより、「認証のためにこのオブジェクトに発行されたアサーションの内容」を問い合せることができます。認証局は、指定されたサブジェクトを認証するために以前に発行されたアサーションを指定して応答します。

このボックスを選択すると、アイデンティティ・プロバイダを認証局として動作させることができます。

- アサーションIDレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダをアサーションID認証局として動作させることができます。信頼できるサービス・プロバイダは、アイデンティティ・プロバイダが以前発行したアサーションの一意IDを提供するアサーションID認証局に対してアサーションIDのリクエストを送信できます。アサーションID認証局は、アサーションをリクエストのIDとともにアサーションを指定して応答します。

アイデンティティ・プロバイダをアサーションID認証局として動作させるには、このボックスを選択します。

- デフォルトSSOレスポンス・バインディング - アイデンティティ・プロバイダがSSOレスポンスを送信する際に、優先バインディングがAuthnRequestで指定されていない場合に、デフォルトとして使用するバインディングを選択します。

- 署名付を送信/要求するメッセージ - Oracle Identity FederationがIdPモードで送信するときに署名が必要なメッセージ、およびOracle Identity FederationがIdPモードで受信するときに署名付を要求するメッセージを指定します。

5.4.3 WS-Federation IdPプロパティの構成

このページは、Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合に、WS-Federation 1.1プロトコルを使用するよう構成する場合に使用します。

次の情報を指定します。

- WSフェデレーション1.1プロトコルの有効化 - このボックスを選択すると、プロトコルが有効になります。

- SSOトークン・タイプ - ドロップダウン・ボックスを使用して、シングル・サインオン・トークン・タイプを選択します。

- Microsoft Webブラウザ・フェデレーテッドSSOプロファイルの使用 - このボックスを選択すると、Oracle Identity FederationでMicrosoft WS-Fedプロトコル仕様を使用できます。

5.4.4 OpenID IdP プロパティの構成

このページを使用して、IdPモードでOpenIDプロバイダを構成します。

関連項目:
.

- 第2.2.1.3項「OpenID 2.0プロトコル」

- 第5.4.5項「外部OpenIDプロバイダの構成」

フィールドは次のとおりです。

- OpenID 2.0プロトコルの有効化 - このボックスを選択すると、OpenID 2.0プロトコルが有効になります。

- XRDSメタデータを使用したReturnTo URLの検証 - このボックスを選択すると、XRDSを使用してReturnTo URL(認証が処理された後でサーバーがリダイレクトするURL)を検証できます。

- レルムを使用したReturnTo URLの検証 - このボックスを選択すると、OpenID認証リクエストで指定されたReturnTo URLを、IdPがレルムを使用して検証するように指定できます。

- 有効なセッション・タイプ - レルムを使用してReturnURLを検証する場合は、各ボックスを選択して特定のセッション・タイプを有効にするか、Allを選択してすべてのセッション・タイプを有効にします。

- デフォルトのセッション・タイプ - レルムを使用してReturnURLを検証する場合は、ドロップダウンを使用してデフォルトのセッション・タイプを選択します。任意の有効なセッション・タイプを選択できます。

- 有効なアソシエーション・セッション・タイプ - 次に示す、OpenIDプロバイダでサポートされている有効なアソシエーション・タイプが表示されます。

- 暗号化なし

- Diffie-Hellman SHA1

- Diffie-Hellman SHA256

- デフォルトのアソシエーション・セッション・タイプ - デフォルトのアソシエーション・セッション・タイプを指定します。

注意:
セッション・タイプやアソシエーション・タイプを変更した場合は、Oracle Identity Federationサーバーを再起動する必要があります。

- アソシエーション・タイムアウト(秒) - アソシエーションの有効期間です(単位は秒)。

- 新しいフェデレーテッド・アイデンティティを作成するためにユーザー承諾を強制 - このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。

- すべてのシングル・サインオン操作に対してユーザー承諾を強制 - このボックスを選択すると、SSOに対して承諾が必要になります。

- 属性交換のあるシングル・サインオン操作に対してユーザー承諾を強制 - このボックスを選択すると、ユーザーはOracle Identity Federation/IdPとRPの間でSSO処理が実行されるときには常に承諾を求められます。これによりユーザー属性がRPにリリースされます。
この機能に関連するフィールドは次のとおりです。

- ユーザー承諾強制のWebコンテキスト - Oracle Identity Federationの組込みのOpenID承諾ページのかわりに使用されるOpenID承諾ページのWebコンテキストを入力します。入力した場合、Oracle WebLogic Serverにあるユーザー実装のページを参照します。

- ユーザー承諾強制のWebパス

- Attribute Exchange (AX) 1.0の有効化 - このボックスを選択すると、AX拡張が有効になります。

- Provider Authentication Policy Extension (PAPE) 1.0の有効化 - このボックスを選択すると、PAPE 1.0拡張が有効になります。この機能では、次の中から1つ以上を指定できます。

- 米国政府Level of Assuranceポリシーのサポート

- Private Personal Identifier (PPID)ポリシーのサポート

- 米国政府OpenID Trust Level 1ポリシーのサポート

- No Personally Identifiable Information (No PII)ポリシーのサポート

- 一般OpenIDサービス・プロバイダ
Oracle Identity Federationでは次のようにOpenID RPを定義できます。

- 特定の設定を定義できるフェデレーテッド・パートナ

- 一般的な属性マッピングを使用した未知のRP

一般OpenID RPを定義するには「作成」をクリックします。

5.4.5 外部OpenIDプロバイダの構成

第5.4.4項には、即時利用可能なOracle Identity Federation OpenIDプロバイダの有効化方法が記載されています。

また、外部OpenIDプロバイダを構成することにより、Oracle Identity Federationがリライイング・パーティ(RP/SP)として機能し、外部リソースがOpenIDプロバイダ(OP)として機能するようにすることもできます。外部OpenIDプロバイダの例にはGoogleやYahooなどがあります。

次の手順を実行して、外部OpenIDプロバイダを構成します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. Oracle Identity Federationインスタンスにナビゲートします。

3. 「管理」→「フェデレーション」を選択します。

4. 「追加」をクリックして新しいOpenIDプロバイダを追加します。

5. ポップアップ・ボックスで、「プロバイダの手動追加」を選択します。

6. 次の形式のURLを使用してプロバイダIDを入力します。

http://node123.us.example.com:7777/fed/idp

7. プロトコル・バージョンとして「OpenID2.0」を選択します。

8. プロバイダ・タイプとして「アイデンティティ・プロバイダ」を選択します。

9. 「OK」をクリックし、プロバイダを作成します。

10. 新しいプロバイダを編集します。次の形式でプロバイダの検出URLを入力します。

http://node123.us.example.com:7777/fed/idp

また、IdPがOpenID検出をサポートしていない場合は、プロバイダのOpenIDエンドポイントURLを入力します。

11. 「適用」をクリックし、編集をコミットします。

この手順では、第4.3.2項「信頼できるプロバイダの追加」に示すように、プロバイダを構成する基本手順に従います。

5.5 サービス・プロバイダの構成

この項では、Oracle Identity Federationにおいてサービス・プロバイダ(SP)のプロトコル固有のプロパティを編集および更新する方法を説明します。内容は次のとおりです。

- サービス・プロバイダの構成 - 共通プロパティ

- SAML 2.0 SPプロパティの構成

- SAML 1.x SPプロパティの構成

- WS-Federation SPプロパティの構成

- OpenID SPプロパティの構成

5.5.1 サービス・プロバイダの構成 - 共通プロパティ

この表では、すべてのプロトコルに共通のSPプロパティを構成します。

アサーション設定

- アサーションのユーザー・アカウントへのマップを有効化 - このボックスは、Oracle Identity Federationでアサーションをユーザー・アカウントにマップする場合に選択します。カスタムSPエンジンを実装してマッピングを行う場合は無効にします。

- 匿名ユーザーID - 受信したアサーションをユーザー・アカウントにマップできない場合に、SPエンジンに渡すユーザーIDを入力します。マップできない場合は、ユーザー・アカウントへのアサーションのマッピングが無効化されているか、アサーション内の名前IDのフォーマットが「transient」になっています。

- 不明な条件を無視 - このボックスを選択すると、アイデンティティ・プロバイダから送信されたアサーションでサービス・プロバイダが認識できない条件を無視できます。

- 署名付アサーションが必要 - このボックスは、アイデンティティ・プロバイダから受信するアサーションに署名が必要な場合に選択します。

プロトコル設定

- デフォルトSSOアイデンティティ・プロバイダ - SSO処理の開始時に、優先アイデンティティ・プロバイダが指定されていない場合に、リクエストのデフォルトの送信先となるアイデンティティ・プロバイダを選択します。

- 非送信請求SSOリレー状態 - Oracle Identity Federation SPが必須でないアサーションを受信すると、ユーザーはSSO処理に続いてアサーションで指定されたリレー状態に送られます。アサーションのリレー状態フィールドが空の場合、ユーザーのリダイレクトには非送信請求SSOリレー状態が使用されます。

- XML署名に署名証明書を含める - XMLメッセージの署名時に、Oracle Identity Federationで署名に署名証明書を含める場合はこのボックスを選択します。

- アイデンティティ・プロバイダ検出サービスの有効化
Oracle Identity Federationには、アイデンティティ・プロバイダ検出サービスと呼ばれるサービスがあります。このサービスでは、ユーザーをカスタム・ページにリダイレクトし、認証を受けるアイデンティティ・プロバイダをそのページでユーザーに選択させることができます。

アイデンティティ・プロバイダ検出サービスを有効にするには、このボックスを選択して、カスタム・ページのサービスURLを入力します。ユーザーはこのカスタム・ページで、使用するアイデンティティ・プロバイダを選択できます。

関連項目:
第6.11項「アイデンティティ・プロバイダ検出サービスの構成」

- 共通ドメインCookieサービスの有効化
IDフェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれる場合、プリンシパルで使用されるアイデンティティ・プロバイダを決定する方法が、サービス・プロバイダで必要です。そのため、フェデレーション・ネットワーク内でIdPとSPに共通のドメインを使用して、このドメインで書かれ、ユーザーがログインしているすべてのIdPが記載されたCookieがユーザーのブラウザに送信されます。このようなドメインは共通ドメインと呼ばれ、IdPを識別するCookieは共通ドメインCookieまたは導入Cookieと呼ばれます。

このSPで導入Cookieを読み取るように指定するには、このボックスを選択して、Oracle Identity Federationは導入Cookieを読み取るサービスURLを入力します。

関連項目:
第6.10項「SAML 2.0 IdP検出(共通ドメインCookie)プロファイルの構成」

- 属性リクエスタ・サービスの有効化 - このボックスを選択すると、このサービス・プロバイダを属性リクエスタとして動作させることができます。

関連項目:
第5.6.5項「SP属性リクエスタとしてのOracle Identity Federationの構成」

注意:
このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

属性リクエスタ・サービスの構成

- デフォルト属性認証局 - リクエストで属性認証局が指定されていない場合に、属性問合せのデフォルトの送信先となる属性認証局を選択します。

- DNパターンから属性レスポンダへのマッピング - この表は、属性認証局にユーザーDNのパターンをマップするために使用します。任意のユーザーの属性問合せを送信すると、Oracle Identity FederationがユーザーのDNを確認し、DNとこの表のパターンを照合して、対応する属性認証局に属性問合せを送信します。ユーザーのDNと一致するパターンがない場合は、デフォルトの属性認証局が使用されます。
デフォルトでは、DNパターンの大/小文字は区別され、ユーザーDNとDNパターンの比較時には大/小文字が考慮されます。比較時に大/小文字を区別するには、WLST構成コマンドを次のように使用します。

setConfigProperty ('dnidpmapping','caseinsensitive','true','boolean')

比較時に大/小文字を区別する場合はtrueを、区別しない場合はfalseを使用します。

関連項目:
第5.6.5項「SP属性リクエスタとしてのOracle Identity Federationの構成」

SSO認証メカニズムのアイデンティティ・プロバイダ

この表では、アイデンティティ・プロバイダに認証メカニズムをマップします。SSO処理の開始時にアイデンティティ・プロバイダが指定されていない場合、Oracle Identity Federationはこの表を確認して、リクエストされた認証メカニズムをアイデンティティ・プロバイダにマップし、このアイデンティティ・プロバイダに対してAuthnRequestを送信します。認証メカニズムをアイデンティティ・プロバイダにマップできない場合は、デフォルトのSSOアイデンティティ・プロバイダが使用されます。

関連項目:
第5.14項「認証メカニズムの構成」

5.5.2 SAML 2.0 SPプロパティの構成

このタブは、SAML 2.0プロトコルに従ってサービス・プロバイダ・モードで動作するOracle Identity Federationのプロパティをメンテナンスする場合に使用します。

アサーション設定

関連付けられたボックスを選択して、アサーション・マッピングの方法を次の中から選択します。

- フェデレーテッド・アイデンティティ

- 属性問合せ

- サブジェクトの名前ID

フェデレーテッド・アイデンティティを使用してユーザーをマップする場合は、「自動アカウント・リンクの有効化」というボックスを選択します。

関連項目:
第6.17項「属性問合せマッピングに基づいた自動アカウント・リンク」

属性問合せを使用してユーザーをマップする場合は、関連付けられているボックスに問合せ文字列を入力します。

サブジェクトの名前IDを使用してユーザーをマップする場合は、ボックスを選択して、「アサーション・サブジェクト名前IDフォーマット」という表から該当する名前IDフォーマットを選択します。表で次の情報を指定します。

- Oracle Identity FederationインスタンスがSPモードでサポートするフォーマットを有効にするには、希望のフォーマットに対応する「有効」ボックスを選択します。

- 名前IDフォーマット - この列には、使用可能なSAML 2.0名前IDフォーマットが表示されます。

- ユーザー属性マッピング - 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストアから、このフォーマットの名前IDを検索します。
名前識別子のフォーマットは次のとおりです。

表5-4 SAML 2.0 SPの名前IDフォーマット

名前IDフォーマット

デフォルト値

X.509サブジェクト名

dn

電子メール・アドレス

mail

Windowsドメイン修飾名

空

Kerberosプリンシパル名

カスタム

空

未指定

空

カスタム・フォーマット名 - アサーションの処理時に、カスタム名前IDフォーマット・タイプにマップされるフォーマットの名前です。

また、Oracle Identity Federationでのマッピング・エラーの処理方法を指定する場合は、「ユーザー・マッピング失敗時のエラー」を選択します。

プロトコル設定

次の情報を指定します。

- SAML 2.0プロトコルの有効化 - このボックスを選択すると、SPに対してこのプロトコルが有効になります。

- シングル・サインオン・プロトコルの有効化 - このボックスを選択すると、シングル・サインオンプロトコルが有効になります。

- 名前ID管理プロトコルの有効化: 登録: このボックスを選択すると、NameID登録が有効になります。

関連項目:
第1.2.4.5項「名前識別子管理プロファイル」

- フェデレーション終了プロトコルの有効化 - このボックスを選択すると、フェデレーション終了プロトコルが有効になります。
この機能の説明は、第1.2.4.8項「フェデレーション終了プロファイル」を参照してください。

- 暗号化名前IDの送信 - このボックスを選択すると、Oracle Identity Federationが暗号化された名前識別子をピア・プロバイダに送信できるようになります。

- 暗号化属性の送信 - このボックスを選択すると、Oracle Identity Federationが暗号化された属性をピア・プロバイダに送信できるようになります。

- フェデレーション作成を許可 - このボックスを選択すると、フェデレーションの作成が可能になります。これは、永続名前IDフォーマットをリクエストするようにSPを構成する(後述を参照)場合は必須です。

- ユーザー承諾を強制 - このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。フェデレーション・サーバーにリダイレクトされたユーザーが続行するためには、リンクを明示的に承諾または拒否する必要があります。

- ユーザー承諾URL - フェデレーションの承諾を取得するためにユーザーに表示されるURLを入力します。
サーバーはこのURLにいくつかの問合せパラメータを渡します。

関連項目:
問合せパラメータの使用方法を示した例については、第5.4.1項「SAML 2.0 IdPプロパティの構成」を参照してください。

表5-5 ユーザー承諾URLに渡されるパラメータ(ローカル設定)

パラメータ

説明

providerid

ピア・プロバイダのIDです。

description

ピア・プロバイダIDの説明です。

returnurl

承諾の決定がされた場合に、ユーザーが導かれるURLです。

refid

returnurlに問合せパラメータとして渡されます。サーバーが承諾URLにリダイレクトされる前に実行していた操作をOracle Identity Federationが再開するには、このパラメータが必要です。

- プロトコル・バインディングの有効化 - ドロップダウン・リストを使用して、有効なバインディングを指定します。

- デフォルト・バインディング - ピア・プロバイダにメッセージを送信する際に、可能な場合、使用する優先バインディングを指定します。有効な値は次のとおりです。

- HTTPリダイレクト

- HTTP POST

- HTTP POSTシンプル署名

- SOAP

- デフォルトSSOリクエスト・バインディング - 認証リクエストをアイデンティティ・プロバイダに送信する際に、可能であればサービス・プロバイダが使用する優先バインディングを指定します。このサーバー・インスタンスがサービス・プロバイダとして動作している場合のみ使用します。有効な値は次のとおりです。

- HTTPリダイレクト

- HTTP POST

- HTTP POSTシンプル署名

- デフォルトSSOレスポンス・バインディング - アサーションをサービス・プロバイダに送信する際に、可能であればアイデンティティ・プロバイダが使用する優先バインディングを指定します。有効な値は次のとおりです。

- アーティファクト

- HTTP POST

- HTTP POSTシンプル署名

- デフォルト認証リクエスト名前IDフォーマット - リスト・ボックスを使用して認証リクエスト用のデフォルトの名前IDフォーマットを選択します。選択肢は次のとおりです。

- X.509サブジェクト名

- 電子メール・アドレス

- Windowsドメイン修飾名

- Kerberosプリンシパル名

- 永続識別子

- 一時/単発識別子

- 未指定

SPにデフォルト認証リクエスト名前IDフォーマットが指定されていない場合、IdPはアサーションの作成時にデフォルト・アサーション名前IDフォーマット(たとえば、電子メール名前IDフォーマット)を使用します。

- リクエスト認証コンテキスト・メカニズム - このリスト・ボックスでは、このサービス・プロバイダがアイデンティティ・プロバイダへのAuthnRequestで指定する認証メカニズムを選択します。

関連項目:
第5.14項「認証メカニズムの構成」

- リクエスト認証コンテキストの比較:このリスト・ボックスでは、このサービス・プロバイダがアイデンティティ・プロバイダに送信するAuthnRequestで指定する認証コンテキストの比較を選択します。

- 署名付を送信/要求するメッセージ
この表は、サービス・プロバイダを構成して、プロバイダが署名付で送信するメッセージ・タイプや署名を要求するメッセージ・タイプを指定するために使用します。

注意:

- 「署名付アサーションが必要」プロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。

- SPが永続名前IDフォーマットをリクエストするように構成する場合(または、SPがフォーマットを指定しない場合は、永続名前IDフォーマットをIdPから受信する必要がある場合)は、SPがフェデレーションを作成できるように構成する必要があります。

- 「適用」をクリックすると構成の変更は保存されますが、変更内容をこのページで有効にするには、プロトコルのボックスを少なくとも1つは選択する必要があります。

5.5.3 SAML 1.x SPプロパティの構成

このタブは、Oracle Identity Federation SAML 1.xのドメインの構成の詳細を指定するために使用します。

アサーション設定

次のマッピングの選択肢のいずれかを選択します。

- 属性問合せによるユーザーのマップ - このボックスを選択して、属性問合せを入力します。

- 名前IDによるユーザーのマップ - このボックスを選択して、「アサーション・サブジェクト名前IDフォーマット」という表から該当する名前IDフォーマットを選択します。

また、Oracle Identity Federationでのマッピング・エラーの処理方法を指定する場合は、「ユーザー・マッピング失敗時のエラー」を選択します。

「アサーション・サブジェクト名前IDフォーマット」表の使用

サブジェクトの名前IDによるアサーション・マッピングを選択した場合は、表で次の情報を指定します。

- Oracle Identity FederationインスタンスがSPモードでSAML 1.1/1.0名前識別子フォーマットとしてサポートするフォーマットを有効にするには、希望のフォーマットに対応する「有効」ボックスを選択します。

- 名前IDフォーマット - この列には、使用可能なSAML 1.x名前IDフォーマットが表示されます。

- ユーザー属性マッピング - 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストアから、このフォーマットの名前IDを検索します。
名前識別子のフォーマットは次のとおりです。

表5-6 SAML 1.1/1.0 SPの名前IDフォーマット

名前IDフォーマット

デフォルト値

X.509サブジェクト名

dn

電子メール・アドレス

mail

Windowsドメイン修飾名

空

未指定

空

カスタム

空

プロトコル設定

次の情報を指定します。

- SAML 1.1プロトコルの有効化 - このボックスを選択すると、SPに対してこのプロトコルが有効になります。

- SAML 1.0プロトコルの有効化 - このボックスを選択すると、SPに対してこのプロトコルが有効になります。

- プロトコル・バインディングの有効化 - ドロップダウンを使用して、使用するバインディングを選択します。

- 署名付を送信/要求するメッセージ - この表は、サービス・プロバイダを構成して、プロバイダが署名付で送信するメッセージ・タイプを指定するために使用します。

注意:
「適用」をクリックすると構成の変更は保存されますが、変更内容をこのページで有効にするには、プロトコルのボックスを少なくとも1つは選択する必要があります。

5.5.4 WS-Federation 1.1 SPプロパティの構成

このページは、Oracle Identity Federationがサービス・プロバイダとして動作する場合に、WS-Federation 1.1プロトコルを使用するよう構成する場合に使用します。

次の情報を指定します。

- WSフェデレーション1.1プロトコルの有効化 - このボックスを選択すると、プロバイダに対してWS-Federation 1.1プロトコルが有効になります。

- リクエスト認証コンテキスト・メカニズム - このドロップダウンでは、認証リクエストでアイデンティティ・プロバイダに送信される認証メカニズムを選択します。

変更を保存するには「適用」を、画面を前の値に戻すには「元に戻す」をクリックします。

5.5.5 OpenID SPプロパティの構成

このページは、OpenIDプロトコルをSPモードで構成する場合に使用します。

関連項目:
第2.2.1.3項「OpenID 2.0プロトコル」

アサーション設定

アサーション設定のフィールドは次のとおりです。

- フェデレーテッド・アイデンティティによるユーザーのマップ - このボックスは、RPが着信アサーションをユーザー・レコードにマップする際にフェデレーテッド・アイデンティティを使用するように指定する場合に選択します。選択しない場合は、アサーション・データに基づいてユーザーが検索されます。

- 自動アカウント・リンクの有効化 - このボックスは、フェデレーテッド・アイデンティティが存在しない場合に、RP/SPが着信アサーションをユーザー・レコードにマップするように指定する場合に選択します。マッピングではアサーション・データを使用します。

- 属性問合せによるユーザーのマップ - LDAP/RDBMS問合せによるアサーションとユーザーのマッピングを有効にするには、ボックスを選択して、関連付けられている「属性問合せ」フィールドを使用します。

- ユーザー・マッピング失敗時のエラー - このボックスを選択すると、アサーション・データを使用して着信アサーションをユーザー・レコードにマッピングする際に失敗した場合は、401エラーが表示されます。選択しない場合は、RPはユーザーの認証、識別、プロビジョニングのために認証エンジンを呼び出し、呼出しが認証エンジンから戻った後で処理を再開します。(注意: 呼び出される認証エンジンは、フローを開始したSPに対して構成されている認証メカニズムで決まります)。

- 署名付アサーションが必要 - RP/SPが着信アサーションに署名付を要求するかどうかを指定します。

プロトコル設定

プロトコル設定のフィールドは次のとおりです。

- OpenID 2.0プロトコルの有効化 - このボックスを選択すると、OpenID 2.0プロトコルが有効になります。

- OpenIDプロバイダ検出の実行 - このボックスは、RPがSSO処理を開始する際に、検出URLからOPを検出するように指定する場合に選択します。検出によって、OPでサポートされる機能が決まり、それに応じて認証リクエストが作成されます。検出が無効の場合は、OpenIDプロバイダのSSO URLを指定する必要があります。また、認証リクエスト・フォーマットはRP構成のみに基づきます。

- ユーザー承諾を強制 - このボックスを選択すると、IdP/OP、RP/SPおよびユーザーの間で新しいフェデレーション(つまり、新しいClaimedID)が作成されるときにユーザーは承諾を求められます。

- デフォルト認証メカニズム - アサーションでPAPE認証ポリシーを使用する場合に、ローカル認証メカニズムを保持して、IdP/OPでユーザーを認証する際の認証方式として使用します。

- 有効なセッション・タイプ - ドロップダウンを使用して、アソシエーションの交換時に使用する有効なセッション・タイプをリストします。使用可能な値は次のとおりです。

- 暗号化なし

- dh-sha1

- dh-sha256

- 有効なアソシエーション・セッション・タイプ - ドロップダウンを使用して、OPでサポートされている有効なアソシエーション・タイプを指定します。使用可能な値は次のとおりです。

- hmac-sha1

- hmac-sha256

- デフォルトのアソシエーション・セッション・タイプ - デフォルトのアソシエーション・セッション・タイプを、有効なタイプから指定します。

注意:
セッション・タイプやアソシエーション・タイプを変更した場合は、Oracle Identity Federationサーバーを再起動する必要があります。

- ユーザー承諾を強制 - このボックスを選択すると、OP、RPおよびユーザーの間で新しいフェデレーション(つまり、新しいClaimedID)が作成されるときにユーザーは承諾を求められます。

- ユーザー承諾強制のWebコンテキスト - Oracle Identity Federationの組込みのOpenID承諾ページのかわりに使用されるOpenID承諾ページのWebコンテキストを入力します。

- アソシエーション開始時のDiffie-Hellmanパラメータの生成 - このボックスは、タイプDH-SHA1またはDH-SHA256のアソシエーション開始時にDiffie-Hellmanパラメータを生成する場合に選択します。選択しない場合は、デフォルト値が使用されます。

- Provider Authentication Policy Extension (PAPE) 1.0の有効化 - このボックスを選択すると、PAPE 1.0拡張が有効になります。この機能では、次の中から1つ以上を指定できます。

- 米国政府Level of Assuranceポリシーのサポート

- Private Personal Identifier (PPID)ポリシーのサポート

- 米国政府OpenID Trust Level 1ポリシーのサポート

- No Personally Identifiable Information (No PII)ポリシーのサポート

5.6 Oracle Access Manager AuthZプラグインによる属性共有の構成

属性共有は、X.509認証ベースのシステムにSAML属性共有プロファイルを実装する、Oracle Access ManagerとOracle Identity Federationの組合せ機能です。このプロファイルでは、保護されたリソースやサービスをリクエストするユーザーは、SSLクライアントのX.509証明書によって認証されますが、認可は、SAMLプロトコルを使用してユーザーの本拠である組織から取得されたユーザー属性で実行されます。ユーザーの本拠である組織がアイデンティティ・プロバイダ(IdP)、認証と認可を実行する組織がサービス・プロバイダ(SP)です。

この項では、Oracle Access ManagerとOracle Identity Federationで属性共有を構成する方法を説明します。内容は次のとおりです。

- 属性共有で使用されるコンポーネント

- リモート・ユーザーとローカル・ユーザー

- Oracle Access Managerプラグインの構成

- Oracle Access Managerのスキームとポリシーの構成

- SP属性リクエスタとしてのOracle Identity Federationの構成

- IdP属性レスポンダとしてのOracle Identity Federationの構成

- SSL用のOracle Identity Federationの構成

5.6.1 属性共有で使用されるコンポーネント

属性共有では、いくつかのOracle Access ManagerおよびOracle Identity Federationのコンポーネントを使用します。手順では、これらのコンポーネントがすでにインストールされ、通常動作するように構成されていると想定しています。

サービス・プロバイダのコンポーネント

SPコンポーネントには次のものがあります。

- Access Manager WebGateを持つWebサーバー - 保護されたURLのHTTPリクエストでは、SSLクライアント証明書認証を実行し、Oracle Access Managerサーバーからのアクセス決定を実施します。

- Oracle Access Manager - WebGateの認証と認可を実行します。属性共有機能では次のカスタム・プラグインを使用します。

- authz_attribute認証プラグイン - 証明書のSubjectDNをauthz_attribute認可プラグインに渡します。

- authz_attribute認可プラグイン - 属性リクエスタ・サービスを使用してユーザーのSubjectDNの属性値を取得し、その属性値でルール式を評価して、アクセスを許可するかどうかを決定します。

注意:
認証プラグインと認可プラグインは、同一のauthz_attributeライブラリを使用します。

- Oracle Identity Federation属性リクエスタ・サービス - ユーザーのSubjectDNによって決定されたIdP属性レスポンダ・サービスにSAML 1.xまたはSAML 2.0属性問合せを送信し、取得した属性をauthz_attributeプラグインに返します。

IdPコンポーネント

Oracle Identity Federation属性レスポンダ・サービスまたは他のSAML 1.x/SAML 2.0準拠フェデレーション製品 - SP属性リクエスタ・サービスからSAML属性問合せを受信し、指定ユーザーの属性を取得して(ローカル・ポリシー制御に従い)、属性を含むレスポンスを属性リクエスタ・サービスに返します。

5.6.2 リモート・ユーザーとローカル・ユーザー

ローカル・ユーザーによって保護されたリソースは、SAML属性検索で認可されたリモート・ユーザー権限の他に、サービス・プロバイダのOracle Access Managerユーザー・ディレクトリ内で定義された属性を使用してアクセスされることもあります。ここで説明したように構成されたローカル・ユーザーはauthz_attribute認証プラグインによって検出され、プラグインはFailureステータスを返します。後で説明する認証スキームは、このステータスを使用してユーザーのローカル・セッションを作成するため、ローカルLDAPフィルタを持つ認可ルールを適用できます。

5.6.3 Oracle Access Managerプラグインの構成

Oracle Access Managerプラグインを構成するには、次の手順を実行します。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

1. AccessサーバーをインストールしたユーザーとしてAccessサーバー・ホストにログインします。

2. INSTALLDIR/oblix/config/attributePlug-inディレクトリがない場合は作成します。

3. INSTALLDIR/oblix/config/attributePlug-inディレクトリのconfig.xmlファイルを、ここに示したconfig.xmlファイルをテンプレートとして使用して編集または作成します。

4. 必要に応じて、config.xmlファイルの属性と要素を編集します。

5. 変更を有効にするためにアクセス・サーバーを再起動します。

config.xmlのサンプル

次にサンプルのconfig.xmlファイルを示します。

<Config LogLevel="audit" WaitTime="30" SizeLimit="0" MaxConnections="5"
InitialConnections="2"
Authn="basic" Username="coreid-as-ashost-6021"  Password="xyzzy"
KeyPassword="abcde"
CacheTimeout="3600" MaxCachedUsers="1000" HeaderKeyLength="128"
RequestFormat="values">
<Mapping Local="true">
<DN>O=Company,C=US</DN>
</Mapping>
<Mapping URL="https://fed1.company.com:7499/fed/ar/soap">
<DN>O=PeerA,C=US</DN>
<DN>O=PeerB,C=US</DN>
</Mapping>
<Mapping URL="https://fed2.company.com:7499/fed/ar/soap"
RequestFormat="all">
<DN>O=PeerC,C=US</DN>
<DN>O=PeerD,C=US</DN>
</Mapping>
<Mapping URL="https://fed3.company.com:7499/fed/ar/soap">
<DN>C=US</DN>
</Mapping>
</Config>

構成パラメータ

構成パラメータは次のとおりです。

- LogLevel - INSTALL_DIR/oblix/logs/authz_attribute_plug-in_log.txtに記録される情報の量を制御します。

- off - エラーのみ記録します(デフォルト)。

- audit - 認証リクエスト1件につき1行記録し、アクセス決定、ユーザーの証明書サブジェクトDNまたはローカル・ディレクトリDN、およびHTTP処理と、リクエストされたURLのローカル部分を示します。

- debug - 問題のデバッグの役に立つ広汎な情報を記録します。

- HTTP接続パラメータ(Oracle Identity Federation属性リクエスタ・サービスへのauthz_attributeプラグイン)。構成要素は次のとおりです。

- WaitTime - レスポンスを待つ時間です(単位は秒)。デフォルトは30秒です。

- SizeLimit - Oracleメッセージが送受信したHTTPメッセージの最大サイズです(デフォルトは無制限を表す0)。

- MaxConnections - HTTP同時最大接続数です(デフォルトは5)。

- InitialConnections - 初期に開かれた現在のHTTP接続数です(デフォルトは2)。

- Oracle Identity Federation属性リクエスタ・サービスへのauthz_attributeプラグインの認証パラメータ。次のとおりです。

- Authn - 認証方式

- none - 認証なし

- basic - ユーザー名とパスワードを使用するHTTP Basic認証(デフォルト)

- cert - SSLクライアント証明書認証。key.pem、cert.pemおよびKeyPasswordを使用

- Username - Basic認証のユーザー名です。

- Password - Basic認証のパスワードです。

- KeyPassword - SSLクライアント証明書認証の、key.pemのパスワードです。

- 属性値キャッシュ・パラメータ。次のとおりです。

- CAcheTimeout - キャッシュされた属性値を保持する秒数。この時間が過ぎると値の更新を要求します(デフォルトは3600秒、つまり1時間。0はキャッシング無効)。

- MaxCAchedUsers - キャッシュされた属性を持つユーザーの最大人数。キャッシュがいっぱいになると、期限内だが、使用された時期が最も古いエントリを取り消します(デフォルトは1000)。

- 属性リクエスタ・サービスURLへのサブジェクトDNのマッピング。各属性リクエスタ・サービスについて、次を指定します。

- URL - サービス用。形式は%HTTP_PROTOCOL%://%OIF_HOST%:%OIF_PORT%/fed/ar/soap。各部分は次のとおりです。

- %HTTP_PROTOCOL% - httpまたはhttps

- %OIF_HOST%:%OIF_PORT% - Oracle Identity Federationのホストとポート

例: https://fed1.company.com:7499/fed/ar/soap

- Local - trueの場合、一致しているユーザーはローカルで、属性リクエスタ・サービスは使用されません。trueの場合、URLパラメータは無視されます。

- DN - ユーザーのSubject DNと照合するDNパターンを指定している1つ以上の要素。パターンは、DNの一番右の部分です。例: O=PeerA,C=US

- 属性問合せプロパティ - RequestFormatパラメータは、属性、および属性レスポンスで返される値を決定します。RequestFormatは認可ルールより優先されます。たとえば、認可ルールは属性と値の両方を指定しているが、RequestFormatが名前を指定している場合は、問合せでは値が省略されます。RequestFormatを指定するオプションは次のとおりです。

- RequestFormat="values"
AttributeQueryには、認可ルールのruleExpressionから取得された属性名と値が含まれます。属性レスポンダは、AttributeQueryにあるユーザー属性と値のみを返します。これがデフォルトの設定です。この設定は、属性値のキャッシュに使用されるメモリーの量を最小にします(値をリクエストされるのは、認可で必要な場合のみ)。代償として、属性リクエストの回数が増大します。

- RequestFormat="names"
AttributeQueryには、属性名は含まれますが、ruleExpressionから取得した属性名は含まれません。属性レスポンダは、名前付き属性のそのユーザーのすべての値を返します。ただし、属性値へのアクセスを制御しているあらゆるレスポンダ・ポリシーに従います。この設定は、「values」設定と「all」設定の中間に位置し、キャッシュ・メモリー使用量と属性リクエスト数のトレードオフを提供します。注意: この設定では、認可のためにどの属性値が必要か、AttributeQueryはIdPに明示しないため、セキュリティ上の理由で「values」設定より望ましい場合があります。

- RequestFormat="all"
AttributeQueryには、属性名や値が含まれていません。属性レスポンダは、属性値へのアクセスを制御しているあらゆるレスポンダ・ポリシーに従うユーザーに、すべての属性と値を返します。この設定では、属性リクエストの回数は減少しますが、属性値が認可に使用される前に(使用されない場合もある)属性値のキャッシュに使用されるメモリー量は増大します。この設定は、属性レスポンダ・ポリシーが、SPが求める属性のみを返すように構成された場合に、最適に機能します。注意: この設定では、認可のためにどの属性が必要か、AttributeQueryはIdPに明示しないため、セキュリティ上の理由で「values」および「names」の設定より望ましい場合があります。

サンプルのconfig.xmlファイルに示されているように、RequestFormatパラメータは、デフォルトのリクエスト・フォーマットを設定する場合は<Config>要素に表示され、マッピングでカバーされるサブジェクトDNのリクエスト・フォーマットを設定する場合は<Mapping>要素に表示されます。

サンプル構成のマッピング例

以前に示したサンプルのconfig.xml構成ファイルの場合の、マッピング例を示します。

表5-7 config.xmlのマッピング例

ユーザー・サブジェクトDN

URLへのマップ

E=john.smith@company.com,CN=John Smith, OU=Development,O=Company,C=US

ローカル

E=betty.jones@peera.com.CN=Betty Jones,OU=Marketing,O=PeerA,C=US

https://fed1.company.com:7499/fed/ar/soap

E=sally.smith@peerd.com,CN=Sally Smith,OU=Marketing,O=PeerD,C=US

https://fed2.company.com:7499/fed/ar/soap

E=bill.jones@peerx.com,CN=Bill Jones,OU=Finance,O=PeerX,C=US

https://fed3.company.com:7499/fed/ar/soap

SSLとクライアント証明書認証の構成

HTTPSとSSLクライアント証明書認証を構成するには、次の手順を使用します。

1. HTTPSが、authz_attributeプラグインと、1つ以上の属性リクエスタ・サービスの間で使用される場合は、INSTALL_DIR/oblix/config/attributePlug-in/cacerts.pemに、信頼できるCAのリストを設定します。属性リクエスタ・サービスを認証する各CAごとに、PEMフォーマットされた証明書(-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----を含む)をcacerts.pemに追加します。

2. SSLクライアント証明書認証が、authz_attributeプラグインと、1つ以上の属性リクエスタ・サービスの間で使用される場合は、key.pemファイルとcert.pemファイルを設定します。

- 次の手順に従って、Oracle Access Managerに含まれているopensslユーティリティを使用して、秘密鍵と証明書リクエストを生成します。

- cd INSTALL_DIR/oblix/tools/openssl

- openssl req -config openssl.cnf -newkey rsa:1024 -keyout../../config/attributePlug-in/key.pem -out../../config/attributePlug-in/req.pem

- 証明書を受信するには、CAにINSTALL_DIR/oblix/config/attributePlug-in/req.pemを送信します。

- 生成された証明書をINSTALL_DIR/oblix/config/attributePlug-in/cert.pemにコピーします。

3. プラグインがPEMファイルを確実に使用するようにするには、アクセス・サーバーを再起動します。

5.6.4 Oracle Access Managerのスキームとポリシーの構成

この項では、Oracle Access ManagerのスキームとポリシーをOracle Identity Federation用に構成する方法を説明します。これらの項目が含まれます。

- 属性共有認証スキームの構成

- 属性共有認可スキームの構成

- 属性共有を使用するOracle Access Managerポリシーの構成

5.6.4.1 属性共有認証スキームの構成

次の手順を実行します。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

1. マスター・アクセス管理者としてOracle Access Managerシステム・コンソールにログインします。「アクセス・システム構成」パネルの「認証管理」を選択します。

2. 「追加」をクリックして、「新規認証スキームの定義」フォームに記入します。

- 名前: OIF属性共有。

- 説明: Oracle Identity Federation属性共有認可のためにSSLクライアント証明書認証を実行します。

- レベル: 保護されたリソースの要件に基づいて設定します。あらゆるパスワード・スキームより高くします。

- チャレンジ・メソッド: X509Cert。

- チャレンジ・パラメータ: ssoCookie:Expires=Tue, 1 Nov 2005 00:00:00 GMT。

注意:
このチャレンジ・パラメータは、保護されたリソースへのすべてのアクセスで、確実にこの認証方式が実行されるようにするために、ブラウザに強制的にObSSOCookieを破棄させ、Oracle Access Managerに再認証させます。

- SSL必須: はい。

- 有効: いいえ(プラグインの構成前)。

「保存」をクリックして変更をコミットします。

3. 「プラグイン」タブを選択し、「変更」をクリックします。表に示したプラグイン・パラメータを追加します。組込みプラグインを入力するには、ドロップダウン・リストからプラグイン名を選択します。カスタムのプラグインを入力するには、ドロップダウン・リストから「カスタム・プラグイン」を選択し、テキスト・ボックスにプラグイン名を入力します。プラグインをすべて追加したら、「保存」をクリックします。

プラグイン名

タイプ

プラグイン・パラメータ

authz_attribute

カスタム

(なし)

cert_decode

組込み

(なし)

credential_mapping

組込み

obMappingBase="MAPPING_BASE",obMappingFilter="(uid=OblixAnonymous)"

credential_mapping

組込み

obMappingBase="MAPPING_BASE",obMappingFilter="(&(&(objectclass=PERSON_OBJECTCLASS) (USER_ATTRIBUTE=%certSubject.FIELD%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))"

次に例を示します。

プラグイン名

プラグイン・パラメータ

authz_attribute

cert_decode

credential_mapping

obMappingBase="o=Company,c=US", obMappingFilter="(uid=OblixAnonymous)"

credential_mapping

obMappingBase="o=Company,c=US", obMappingFilter="(&(&(objectclass=inetorgperson)(mail=%certSubject.E%)) (|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))"

4. 「ステップ」パネルを選択します。次の手順を追加します。

手順名

アクティブ・プラグイン

目的

SubjectDN

authz_attribute

証明書からSubjectDNを抽出し、ユーザーがリモートとローカルのどちらであるかを判定します。

RemoteUser

最初のcredential_mapping

リモート・ユーザー用の匿名セッションを作成します。

LocalUser

cert_decode、2番目のcredential_mapping

ローカル・ユーザー用のリアル・セッションを作成します。

5. 「認証フロー」パネルを選択し、「変更」をクリックして、表に示したフローを設定します。注意: authz_attributeプラグインは、ユーザーがリモートである場合はSuccessを返し、ユーザーがローカルである場合はFailureを返します。

手順名

開始手順

Successの場合の次の手順

Failureの場合の次の手順

デフォルトのステップ

いいえ

停止

停止

SubjectDN

はい

RemoteUser

LocalUser

RemoteUser

いいえ

停止

停止

LocalUser

いいえ

停止

停止

6. 「ステップ」パネルに戻り、使用しなかったデフォルト手順を削除します。

7. 「一般」パネルに戻り、認証スキームを有効にします。

5.6.4.2 属性共有認可スキームの構成

次の手順は、属性共有認可スキームを構成するために使用します。

関連項目:
Webベースのユーザー・インタフェースの詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。

1. マスター・アクセス管理者としてOracle Access Managerシステム・コンソールにログインします。「アクセス・システム構成」パネルの「認可管理」を選択します。

2. 「追加」をクリックして、「新規認可スキームの定義」フォームに記入します。

- 名前: OIF属性共有。

- 説明: Oracle Identity Federationを使用して、リモート・ユーザーがルール式を評価するための属性を取得するために使用します。

- 共有ライブラリ: oblix/lib/authz_attribute。

- プラグインは管理コードです: いいえ。

- 管理コードのネームスペース:(なし)。

- ユーザー・パラメータ: RA_SubjectDN(注意: authz_attributeプラグインによって設定されたSubjectDNヘッダーを取得する際に、「アクションのリバース」機能を使用します。)

- 必須パラメータ

- 名前: ruleExpression

- 値: (なし) (注意: 各アクセス・ポリシー認可ルールによりルール式が提供されます。)

- 「保存」をクリックして変更をコミットします。

5.6.4.3 属性共有を使用するOracle Access Managerポリシーの構成

次の手順は、属性共有プロファイルを使用するOracle Access Managerポリシーを構成するために使用します。

1. マスター・アクセス管理者または委任アクセス管理者としてOracle Access Managerにログインします。「ポリシー・ドメインの作成」を選択します。

2. 「一般」パネル・フォームに次の内容を入力します。

- 名前: 適切な名前(たとえば、Oracle Identity Federation属性共有テスト)。

- 説明: 適切に入力します。

「保存」をクリックします。

3. リソース・パネルを選択して、1つ以上の保護するリソースのURL接頭辞を追加します(/attribute-testなど)。

4. 「認可ルール」パネルを選択し、リモート・ユーザーに必要な属性の各セットごとに認可ルール(ルール式で表現)を追加します。

- 「カスタム認可スキーム」を選択し、「追加」をクリックします。

- 認可ルール・フォームに記入して、「保存」をクリックします。

- 名前: 適切な名前(たとえば、「Peer Marketing VP」)。

- 説明: 適切に入力します。

- 認可スキーム: OIF属性共有。

- 「プラグイン・パラメータ」パネルを選択し、「変更」をクリックして、表に示したruleExpressionパラメータを設定します。注意: 「=」、「!=」、「&」および「|」の左右にはスペースを配置できます。

要素

構文

意味

none

英数字と「-」、「_」および「.」の文字列

ユーザーのアイデンティティ・プロバイダからリクエストする属性の名前。

value

文字列のいずれか1つか、anyまたはnull

必須属性値です。Oracle COREid Access 7.0.4では、文字列はLatin-1文字に限定されます。Oracle Access Manager10.1.4以降では、文字列はUnicode文字を含むことができます。値anyは、属性のすべての値を取得し、照合します。NULL値は、xsi:nil="true"属性を持つSAML<属性>に一致します。

comparison

name = value、name != value、または (式)

それぞれ、ユーザーが属性値を持っている場合/持っていない場合にtrue。

and句

comparison & comparison

両方のcomparisonがtrueのときにtrueになります。

or句

comparison | comparison

どちらかのcomparisonがtrueのときにtrueになります。&は!よりも優先されます。

- 名前の例を次に示します。

- title = "VP" & function = "Marketing"

- title = "VP" | title = "Director"

- title = "VP" & (function = "Marketing" | function = "Finance")

- title = any & function = any

- 目的に応じて、認可ルール用の任意のタイミング条件またはアクションを設定します。

- 「一般」パネルに戻って、ルールを有効にします。

5. 「認可ルール」パネルを選択して、ローカル・ユーザー属性に対する認可ルールを追加します。

- 「Oracle認可スキーム」を選択し、「追加」をクリックします。

- 認可ルール・フォームに記入します。

- 名前: 適切な名前(たとえば、「Company Marketing VP」)。

- 説明: 適切に入力します。

- 有効: はい。

- 優先を許可: いいえ。

「保存」をクリックします。

- 「アクセスの許可」パネルを選択し、「変更」をクリックして、ローカル属性用のLDAPフィルタを追加します。Oracle Access Manager Identity User ManagerのQuery Builderを使用できます(「構成」→「管理の委任」→「フィルタの作成」)。次に例を示します。

ldap:///o=Company,c=US??sub?(&(title=VP)(function=Marketing))

- 目的に応じて、認可ルール用の任意のタイミング条件またはアクションを設定します。

- 「一般」パネルに戻って、ルールを有効にします。

6. 「デフォルト・ルール」パネルを選択して、デフォルト認証ルールを追加します。

- 名前: 適切に入力します。

- 説明: 適切に入力します。

- 認証スキーム: OIF属性共有。

「保存」をクリックします。

7. 「認可条件式」パネルを選択して、デフォルト認証ルールを追加します。

- 上で定義されたとおりに適用可能なリモート認可ルールを選択し、「追加」(たとえば、Peer Marketing VP)をクリックします。

- 対応するローカル認可ルールがある場合は、「OR」を選択してローカル認可ルールを追加します。(たとえば、Peer Marketing VP | Company Marketing VP)。

「保存」をクリックします。

8. かわりに、保護されたURLのサブセットの認可式を使用して、ポリシー・ドメインにポリシーを追加できます。

5.6.5 SP属性リクエスタとしてのOracle Identity Federationの構成

次の手順は、サービス・プロバイダ・モードの属性リクエスタとしてOracle Identity Federationを構成するために使用します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 属性リクエスタ機能を有効にします。

- 「管理」→「サービス・プロバイダ」の順に移動します。

- 「属性リクエスタ・サービスの有効化」ボックスを選択し、「適用」をクリックします。

注意:
「属性リクエスタ・サービスの有効化」ボックスを選択すると、属性リクエスタ機能が有効になります。これにより、属性リクエスタ・サービスに関する情報を含むSPのメタデータも変更されます。ピア・プロバイダのサイトにあるメタデータを新しいバージョンで更新する必要があります。

3. SAML 1.xまたはSAML 2.0 IdPメタデータをアップロードするか、SAML 1.xプロバイダのエントリを手動で作成します。

- 「管理」→「フェデレーション」の順に移動します。

- 「追加」をクリックします。

- SAML 1.xまたはSAML 2.0メタデータをアップロードする場合は、「メタデータのアップロード」を選択し、IdPメタデータの場所と追加説明を入力します。

- SAML 1.xプロバイダを手動で追加する場合は、「信頼できるプロバイダの手動追加」を選択して、「プロバイダID」、プロバイダ・バーション(SAML 1.1またはSAML 1.0)を入力し、「アイデンティティ・プロバイダ/属性レスポンダ」を「プロバイダ・タイプ」として選択して、追加説明を入力します。

- 「OK」をクリックします。

4. DNからIdPへのマッピングを構成します。

- 「管理」→「サービス・プロバイダ」の順に移動します。

- 「属性リクエスタ・サービスの構成」をクリックします。

- ドロップダウン・リストから「デフォルト属性認証局」を選択し、「適用」をクリックします。

- マッピングを追加するには、次の操作を行います。

- 「追加」をクリックします。

- DNまたはサブDNを入力します(たとえば、c=us)。

- 既存のIdPにこのDNまたはサブDNをマップします。

- 必要に応じて操作を繰返します。

- 「OK」をクリックします。

5. 証明書検証を有効にして構成します。

- 「管理」→「セキュリティおよび信頼」の順に移動します。

- 「認証検証の有効化」を選択し、「適用」をクリックします。

- 信頼できるCAまたはCRLを追加するには、対応する表で「追加」をクリックし、CAまたはCRLの場所を選択します。(注意: 証明書検証が有効な場合は、署名を検証するために信頼できるCAが必要です)。

注意:
DNからIdPへの構成および証明書検証の構成はオプションです。

6. SAML 2.0を使用する場合は、暗号化を有効にします。

- 「管理」→「サービス・プロバイダ」の順に移動します。

- SAML 2.0タブの「プロトコル設定」で、次のようにします。

- AttributeQueryの名前識別子を属性レスポンダに暗号化するには「暗号化された名前IDの送信」を選択します。

- AttributeQueryの属性を属性レスポンダに暗号化するには「暗号化された属性の送信」を選択します。

- 「適用」をクリックします。

注意:
暗号化はオプションです。

7. 属性リクエスタ・サービスはhttp://sp-hostname:port/fed/ar/soapから使用できます。

属性リクエスタ機能を有効にし、デフォルト属性認証局またはDNマッピングを設定した後、属性名マッピングおよび属性値マッピングを構成する必要があります。詳細は、第5.9.2項「マッピングおよびフィルタリングの構成」を参照してください。

その他の内容は次のとおりです。

- OHSでHTTP Basic認証を使用する場合

- OHSを使用せずにHTTP Basic認証を使用する場合

- SSLクライアント認証を使用する場合

5.6.5.1 OHSでHTTP Basic認証を使用する場合

プラグインとOracle Identity Federationの間でBasic認証を使用する場合は、Oracle Identity Federationインスタンス用のOHSのhttpd.confファイルに次の内容を追加する必要があります。

<LocationMatch "/fed/ar/soap">
AllowOverride None
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /private/oifpassword
Require user alice
Order allow,deny
Allow from all
</LocationMatch>

htpasswdユーティリティを使用してユーザー・パスワード・ファイルを作成する必要もあります。上の例で、ユーザーとパスワードを含むAuthUserFileは/private/oifpasswordファイルを参照しており、このファイルでユーザーaliceが定義されています。

この例では、ユーザーaliceを追加することによってこのようなファイルを作成します。

$ORACLE_HOME/ohs/bin/htpasswd -c /private/oifpassword alice

5.6.5.2 OHSを使用せずにHTTP Basic認証を使用する場合

Oracle HTTP Serverを使用せずにHTTP Basic認証を使用する場合は、第6.9.2項「HTTP Basic認証」を参照してください。

5.6.5.3 SSLクライアント認証を使用する場合

クライアント証明書認証を使用する場合は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

5.6.6 IdP属性レスポンダとしてのOracle Identity Federationの構成

次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 属性レスポンダ機能を有効にします。

- 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

- SAML 2.0または「SAML 1.x」タブで、「属性問合せレスポンダの有効化」を選択します。SAML 2.0を使用する場合に、IdPでフェデレーテッド・アイデンティティを使用して属性リクエストのユーザーを検索する場合は、「属性レスポンスのアイデンティティ・フェデレーションの使用」を選択します。この設定を使用する場合、ユーザーはフェデレーションIDを持っている必要があります。また、名前IDの値とフォーマットがAttributeQueryで指定されているサブジェクトの値とフォーマットに一致する必要があります。

- 「適用」をクリックします。

注意:
「属性レスポンダ有効」ボックスを選択すると、属性認証局機能が有効になります。これにより、属性認証局サービスに関する情報を含むIdPのメタデータも変更されます。ピア・プロバイダのサイトにあるメタデータを新しいバージョンで更新する必要があります。

3. 名前IDフォーマットをマップします。

- 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

- SAML 2.0タブの「アサーション設定」で、使用するサブジェクト・フォーマットが有効で、ユーザー・リポジトリから正しいユーザー・エントリ属性にマップされていることを確認します。

- dnを使用して、X.509サブジェクト名をエントリの識別名にマップするか、ユーザー・エントリの任意の属性を使用します。

注意:
X.509サブジェクト名に選択された属性は、RFC2253で指定されたフォーマットに従って、クライアント証明書サブジェクトDNに正確に一致する必要があります。フォーマットに確信がない場合は、SPでテストを実行して、ログに記録される、SPから送信されたSubject NameIdentifierの値を確認します。

- 「適用」をクリックします。

4. SAML 1.xまたはSAML 2.0 IdPメタデータをアップロードするか、SAML 1.xプロバイダのエントリを手動で作成します。

- 「管理」→「フェデレーション」の順に移動します。

- 「追加」をクリックします。

- SAML 1.xまたはSAML 2.0メタデータをアップロードする場合は、「メタデータのアップロード」を選択し、IdPメタデータの場所と追加説明を入力します。

- SAML 1.xプロバイダを手動で追加する場合は、「信頼できるプロバイダの手動追加」を選択して、「プロバイダID」、プロバイダ・バーション(SAML 1.1またはSAML 1.0)を入力し、「サービス・プロバイダ」と「属性リクエスタ」を「プロバイダ・タイプ」として選択して、追加説明を入力します。

- 「適用」をクリックします。

5. SP属性リクエスタの属性マッピングを構成します。

- 「管理」→「フェデレーション」の順に移動します。

- SPの「属性リクエスタ」エントリを選択して、「編集」をクリックします。

- 「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。

- 属性マッピングを追加するには、次の操作を行います。

- 「追加」をクリックします。

- ユーザー・リポジトリ属性名を「ユーザー属性名」列に入力します。

- 「アサーション属性名」に、属性を参照するために、AttributeQueryまたはアサーションで使用する識別子を入力します。

- 「フォーマットまたはネームスペース」を入力します(使用する場合)。これは、バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。
- SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。

- SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。

- 他の属性のマッピングを追加するには、操作を繰り返します。

- 「OK」をクリックします。

注意:
Oracle Identity Federationを使用するSPの場合、第5.6.4.3項「属性共有を使用するOracle Access Managerポリシーの構成」で設定したように、アサーション属性名はruleExpressionでの属性名により決定されます。属性名はIdPとSPで一致している必要があります。

6. 証明書検証を有効にして構成します。

- 「管理」→「セキュリティおよび信頼」の順に移動します。

- 「認証検証の有効化」を選択し、「適用」をクリックします。

- 信頼できるCAまたはCRLを追加するには、対応する表で「追加」をクリックし、CAまたはCRLの場所を選択します。(注意: 証明書検証が有効な場合は、署名を検証するために信頼できるCAが必要です)。

注意:
証明書検証の構成はオプションです。

7. SAML 2.0を使用する場合は、暗号化を有効にします。

- 「管理」→「サービス・プロバイダ」の順に移動します。

- SAML 2.0タブの「プロトコル設定」で、次のようにします。

- AttributeQueryの名前識別子を属性レスポンダに暗号化するには「暗号化された名前IDの送信」を選択します。

- AttributeQueryの属性を属性レスポンダに暗号化するには「暗号化された属性の送信」を選択します。

- 「適用」をクリックします。

注意:
暗号化はオプションです。

属性レスポンダ機能を有効にした後、次を構成する必要があります。

- 送信対象の属性

- 属性名マッピング

- 属性値マッピング

- 属性値フィルタ

詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください。

5.6.7 SSL用のOracle Identity Federationの構成

サーバーのSSLを構成するには、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

5.7 SSOアサーションで属性を送信するアイデンティティ・プロバイダの構成

シングル・サインオン処理時に、必要に応じて、アイデンティティ・プロバイダによりサービス・プロバイダが使用する認証アサーションに属性を含めることができます。

アサーションでの属性の送信を有効にするには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「フェデレーション」の順に移動します。

3. 属性共有を構成するサービス・プロバイダを選択し、「編集」をクリックします。

4. 「手動更新」を選択します。

5. 「Oracle Identity Federation設定」タブで、「シングル・サインオンの属性の有効化」を選択します。

6. その下にあるボックスを選択して、アサーションで送信する属性の名前IDフォーマットを指定します。

7. 「適用」をクリックします。

「シングル・サインオンの属性の有効化」ボックスを選択した後、次を構成する必要があります。

- 送信対象の属性

- 属性名マッピング

- 属性値マッピング

- 属性値フィルタ

詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください。

5.8 属性共有用のWebサービス・インタフェース

この項では、Oracle Identity Federationの属性リクエスタ・サービス・インタフェースについて説明します。内容は次のとおりです。

- サービス・インタフェースの概要

- 属性リクエスト・メッセージ

- 属性レスポンス・メッセージ

- インタフェースWSDL

5.8.1 サービス・インタフェースの概要

属性リクエスタ・サービスには、SOAP POSTプロトコルを使用したリクエスト/レスポンス・インタフェースが用意されています。このサービスは、X.509認証ベースの属性共有プロファイルをサポートしており、SAML <AttributeQuery>表記規則に従っています。

このサービスを起動して、samlp:AttributeQueryメッセージをリモートアイデンティティ・プロバイダに送信できます。

Webサービス・クライアントがAttributeRequestをOracle Identity Federation/属性リクエスタ・サーバーに送信するときに実行される手順は、次のとおりです。

1. Webサービス・クライアントは、SOAPプロトコルを使用してAttributeRequestメッセージを送信します。

2. Oracle Identity Federationは、リクエストで指定されたIdP、またはAttributeRequestに含まれるSubjectに基づいて、受信AttributeRequestメッセージを処理し、SAML AttributeQueryの送信先のIdPを選択します。

3. Oracle Identity Federationは、特定のリモートIdPに対して、AttributeRequestにリストされているオプションの属性値の属性値マッピングを適用します。

4. Oracle Identity Federationは、特定のリモートIdPに対して、AttributeRequestにリストされているオプションの属性の属性名マッピングを適用します。

5. Oracle Identity Federationは、AttributeQueryをリモートIdPに送信します。

6. Oracle Identity Federationは、IdPによって送信された属性とともに、アサーションが含まれるレスポンスを受信します。

7. Oracle Identity Federationは、特定のリモートIdPに対して、アサーションのAttributeStatementにリストされている属性名の属性名マッピングを適用します。

8. Oracle Identity Federationは、特定のリモートIdPに対して、アサーションのAttributeStatementにリストされている属性値の属性値マッピングを適用します。

9. Oracle Identity Federationは、AttributeResponseメッセージを構築し、これをSOAPレスポンス・メッセージでWebサービス・クライアントに戻します。

5.8.2 属性リクエスト・メッセージ

AttributeRequestメッセージにより、ユーザーの属性データに対するリクエストを発行します。AttributeRequestでは、次の入力を指定します。

- Subject: ユーザーを表す文字列。これは必須入力です。

- Subject Format: サブジェクト文字列がどのようにユーザーを表すかを指定するURI。指定しない場合は、フォーマット「oracle:security:nameid:format:x509」が使用されます。有効なフォーマットは次のとおりです。

- oracle:security:nameid:format:x509: 名前IDがサブジェクトDNであることを示します。

- oracle:security:nameid:format:entity: 名前IDが、SAMLサービスを提供するエンティティの識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。

- oracle:security:nameid:format:emailaddress: 名前IDが電子メール・アドレスの形式であることを示します。

- oracle:security:nameid:format:windowsdomainqualifiedname: 名前IDがWindowsドメイン修飾名であることを示します(Windowsドメイン修飾名は「DomainName\UserName」という形式の文字列です。DomainNameと「\」は省略できます)。

- oracle:security:nameid:format:kerberos: 名前IDがname[/instance]@REALMというフォーマットを使用したKerberosプリンシパル名の形式であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。

- oracle:security:nameid:format:persistent: 名前IDが、IdPおよびSPに固有のユーザーの不透明な永続識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。

- oracle:security:nameid:format:transient: 名前IDが、ユーザーの不透明で一時的な識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。

- oracle:security:nameid:format:unspecified: 名前IDの解釈は、実装に準拠することを示します。

- oracle:security:nameid:format:custom: 名前IDがカスタム値であることを示します。

- oracle:security:nameid:format:userid: 名前IDが、Oracle Identity Federationによるユーザーの識別に使用されるユーザーIDであることを示します。

注意:
名前IDフォーマットを有効/無効にして、ユーザー・データ・ストアの属性にマップするには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「アイデンティティ・プロバイダ」または「サービス・プロバイダ」の順に移動します(それぞれ、IdPまたはSPを構成します)。

3. SAML 2.0または「SAML 1.x」タブで、次のように「アサーション・サブジェクト名前IDフォーマット」を変更します。

1. 有効にするフォーマットの横にある「有効」ボックスをクリックします。

2. 各フォーマットをユーザー・データ・ストアの属性にマップします。

4. 「適用」をクリックします。

- AttributeQueryが送信される属性認証局。属性認証局を指定しない場合、Oracle Identity FederationはAttributeQueryの送信先の属性認証局を次のように決定します。

- Subject Formatが"oracle:security:nameid:format:x509"または指定されていない場合は、Subjectの値をアイデンティティ・プロバイダにマップします。SubjectDNに対するマッピングが見つからない場合は、デフォルト属性認証局をが使用されます。

- それ以外の場合は、デフォルト属性認証局を使用します。

関連項目:
デフォルト属性認証局およびSubjectDNとIdPのマッピングを構成する方法の手順は、第5.6.5項「SP属性リクエスタとしてのOracle Identity Federationの構成」を参照してください。

- このユーザーについて取得する0個以上の属性。

- 各属性に対する0個以上の値。NULL値は<Value Null="true"/>で表すことができます。

AttributeRequestメッセージはSOAPEnvelopeおよびBodyでラップされ、HTTP POSTリクエストで送信されます。次にAttributeRequestメッセージの例を示します。

例1

次のリクエストでは、Subjectのフォーマットが指定されていないため、"oracle:security:nameid:format:x509"であるとみなされます。ターゲットIdPも指定されていないため、Oracle Identity Federationは、使用する属性認証局を決定するためにSubjectDNをIdPにマッピングします。

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeRequest        xmlns:orafed-arxs=http:"//www.oracle.com/fed/ar/10gR3">
<orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
<orafed-arxs:Value>bob@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname">
<orafed-arxs:Value>Bobby</orafed-arxs:Value>
<orafed-arxs:Value>Charles</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="lastname">
</orafed-arxs:Attribute>
</orafed-arxs:AttributeRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

例2

次のリクエストでは、ターゲットIdPに"http://my-corp.com/fed/idp"が指定されているため、Oracle Identity Federationは、この属性認証局にAttributeQueryを送信します。また、Subject Formatが"oracle:security:nameid:format:userid"であるため、サブジェクト値「alice」は、属性をリクエストしたユーザーのユーザーIDであるとみなされます。

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeRequest xmlns:orafed-arxs=http://www.oracle.com/fed/ar/10gR3 TargetIDP="http://my-corp.com/fed/idp">
<orafed-arxs:Subject Format="oracle:security:nameid:format:userid">alice
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
<orafed-arxs:Value>bob@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname">
<orafed-arxs:Value>Bobby</orafed-arxs:Value>
<orafed-arxs:Value>Charles</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="lastname">
</orafed-arxs:Attribute>
</orafed-arxs:AttributeRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

出力ルールは次のとおりです。

- SAML <AttributeQuery>表記規則に従い、属性名を指定しない場合はすべてのユーザー属性が戻されます。

- リクエスト内で1つ以上の属性名を指定すると、これらの属性のみが戻されます。

- リクエストで値が指定されていない場合、属性認証局はリクエストにローカル属性値のみを返します(リクエストに値がある場合)。

- 属性はレスポンダのローカル・ポリシーに従って戻されます。

5.8.3 属性レスポンス・メッセージ

属性リクエスタ・サービスは、属性リクエストに続いてAttributeResponseメッセージをSOAPクライアントに戻します。

AttributeResponseの出力には、次が含まれます。

- SAML 1.xまたはSAML 2.0問合せのステータス(SuccessまたはFailure、およびその理由)。クライアントは、この情報をロギング用に使用できます。

- リクエストで指定したSubject

- リクエストで指定したSubject Format

- 0(ゼロ)以上の<Attribute>要素(各要素が属性名と0(ゼロ)以上の値を提供します)

戻される属性値については、次の点に注意してください。

- すべての値はUTF-8文字列です。

- SAML AttributeQuery表記規則に従い、リクエスタによる属性の値の確認が許可されていない場合、Attribute要素はValue要素なしで戻されます。

- NULLの属性値は<Value Null="true"/>で表されます。

- AttributeResponseメッセージのCacheFor属性により、属性値をキャッシュできる時間を指定します。

AttributeResponseメッセージはSOAP EnvelopeおよびBodyでラップされ、HTTP 200 OKレスポンスで戻されます。次の属性レスポンスは、前述の例の属性リクエストに対応しています。

例1

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeResponse        xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3" CacheFor="1199">
<orafed-arxs:Status>Success</orafed-arxs:Status>
<orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="lastname">
<orafed-arxs:Value>Appleton</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname"></orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
</orafed-arxs:AttributeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

例2

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeResponse  xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3" CacheFor="1199">
<orafed-arxs:Status>Success</orafed-arxs:Status>
<orafed-arxs:Subject Format="oracle:security:nameid:format:userid">alice
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="lastname">
<orafed-arxs:Value>Appleton</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname"></orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
</orafed-arxs:AttributeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

5.8.4 インタフェースWSDL

属性リクエスタ・サービス・インタフェースを正式に定義するWSDLは、次のとおりです。

<?xml version ="1.0" encoding="US-ASCII" ?>
<wsdl:definitions name="AttributeRequesterFed" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3"
xmlns:orafed-arwsdl="http://www.oracle.com/fed/ar/wsdl"
targetNamespace="http://www.oracle.com/fed/ar/wsdl">
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.oracle.com/fed/ar/10gR3"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="SubjectType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Format" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Subject" type="orafed-arxs:SubjectType"/>

<xs:complexType name="ValueType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Null" type="xs:boolean"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Value" type="orafed-arxs:ValueType"/>

<xs:complexType name="AttributeType">
<xs:attribute name="Name" type="xs:ID"/>
<xs:sequence>
<xs:element ref="orafed-arxs:Value"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Attribute" type="orafed-arxs:AttributeType"/>

<xs:complexType name="AttributeRequestType">
<xs:attribute name="TargetIDP" type="xs:string"/>
<xs:sequence>
<xs:element ref="orafed-arxs:Subject"/>
<xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="AttributeRequest" type="orafed-arxs:AttributeRequestType"/>

<xs:complexType name="AttributeResponseType">
<xs:sequence>
<xs:element name="Status" type="xs:string"/>
<xs:element ref="orafed-arxs:Subject"/>
<xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="CacheFor" type="xs:unsignedInt"/>
</xs:complexType>
<xs:element name="AttributeResponse" type="orafed-arxs:AttributeResponseType"/>
</xs:schema>
</wsdl:types>

<wsdl:message name="AttributeRequestMessage">
<wsdl:part name="body" element="orafed-arxs:AttributeRequest"/>
</wsdl:message>

<wsdl:message name="AttributeResponseMessage">
<wsdl:part name="body" element="orafed-arxs:AttributeResponse"/>
</wsdl:message>

<wsdl:portType name="AttributeRequesterServicePortType">
<wsdl:operation name="AttributeRequestOp">
<wsdl:input message="orafed-arwsdl:AttributeRequestMessage"/>
<wsdl:output message="orafed-arwsdl:AttributeResponseMessage"/>
</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="AttributeRequesterServiceBinding" type="orafed-arwsdl:AttributeRequesterServicePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="AttributeRequestOp">
<soap:operation soapAction="http://www.oracle.com/fed/AttributeRequestOp" />
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

<wsdl:service name="AttributeRequesterService">
<wsdl:port name="AttributeRequesterServicePort"
binding="orafed-arwsdl:AttributeRequesterServiceBinding">
<soap:address location="http://node.us.example.com:1234/fed/ar/soap"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

typesおよびmessageセクションは、AttributeRequestおよびAttributeResponseメッセージの内容を定義します。

attribute要素のName属性には、組込みXMLスキーム・タイプIDが使用されます。このタイプにより、属性名の必要な構文(文字、数値、「_」、「-」および「.」)が概算されます。ただし、ID(XML NCNameタイプから導出)には、文字と拡張機能を組み合せた複数のUnicodeも含まれます。

関連項目:
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCNameにあるW3C仕様「Namespaces in XML」

bindingおよびserviceセクションは、SOAPおよびHTTP(S)を介してメッセージを送信する方法を指定します。

5.9 属性マッピングおよびフィルタリングの構成

この項では、Oracle Identity Federationの属性マッピング機能を構成する方法について説明します。内容は次のとおりです。

- 属性マッピングおよびフィルタリングの概要

- マッピングおよびフィルタリング構成

5.9.1 属性マッピングおよびフィルタリングの概要

サポート対象エンティティ

Oracle Identity Federationは、次に関する属性マッピングをサポートしています。

- 属性認証局

- 属性リクエスタ

- アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)

マッピング機能

Oracle Identity Federationには、次の属性マッピング機能が用意されています。

- 属性名マッピング: SAMLメッセージで使用される外部属性名にローカル属性名をマップします。

- 属性値マッピング: SAMLメッセージで使用される外部属性値にローカル属性値をマップします。

- 属性値フィルタリング: アサーション・メッセージで許容値のみを送信することによってローカル属性値にフィルタリングします。

注意:
11g リリース1(11.1.1)では、属性マッピングおよびフィルタリングはすべて、グローバル・レベルではなく、ピア・プロバイダ単位の構成としてのみ適用できます。

属性ソース

Oracle Identity Federationでは、属性を次のソースから送信アサーションにマップできます。

1. ユーザー・セッション

2. ユーザー・データ・ストア

3. Oracle Identity Federation構成の静的値

この項は次のトピックで構成されています。

- 属性名マッピング

- 属性値マッピング

- 属性値フィルタリング

5.9.1.1 属性名マッピング

管理者は、属性名マッピングを使用することにより、メッセージの送受信時にSAMLメッセージでローカル属性を定義するための名前を指定できます。

IdP/属性権限側では、マッピングの定義時に、属性を特定のピア・プロバイダに送信するようOracle Identity Federationを構成することもできます。つまり、名前マッピングを定義しない場合、Oracle Identity Federationは属性をピア・プロバイダに送信しないよう構成されます。

Oracle Identity Federationによって属性名マッピングが実行されるのは、Oracle Identity Federationが次のものとして動作する場合です。

- 属性認証局

- 属性リクエスタ

- アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)

1対1マッピング

属性名マッピングは、アウトバウンド・マッピングでは1:1である必要があります。ローカル属性名ごとに、1つのアサーション属性名のみを指定できます。

属性名マッピングは、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.1項「属性名マッピングの構成」を参照してください。

5.9.1.1.1 静的属性値

Oracle Identity Federation構成から静的属性値(DeploymentVersion=6.4など)を送信アサーションにマップできます。

この機能は、既存の属性名マッピング定義の次に示す2つのプロパティで実装されています。

- from-config, a boolean

- attribute-value-fromconfig

from-configがtrueで、その属性を送信アサーションに含める必要がある場合は、attribute-value-fromconfigに格納されている値が送信アサーションに配置されます。

from-configがfalseの場合は、Fusion Middleware Controlで属性に設定した値が使用されます。

この手順には、属性マッピングのリストに対する属性名マッピング定義の作成、および次のプロパティの設定が含まれます。

- 属性の内部名。datastore-attrによって参照されます。

- アサーションに表示される際の属性の名前。assertion-attrによって参照されます。

- SAML属性のフォーマットまたはネームスペース(空白も可能)。format-attrによって参照されます。

- その属性をSSOアサーションで送信するかどうかを示すフラグ。send-with-ssoによって参照されます。

- 属性値をOracle Identity Federationユーザー・セッションから取得するかどうかを示すフラグ。from-sessionによって参照されます。

- 属性値が静的かどうかを示すフラグ。from-configによって参照されます。

- attribute-value-fromconfigによって参照されるプロパティ。静的値が含まれます。

静的属性マッピングを構成するWLSTコマンドは次のとおりです。

注意:
次の例のホスト:ポート、マップ名および静的値のサンプル値は、有効な値で置き換える必要があります。

- http://myhost.domain.com:7499/fed/spというprovideridに対して、属性の属性名マッピング定義(ローカル名をcn、アサーション名をcommonNameに設定)を次のように作成します(まだ存在していない場合)。

createFederationPropertyMap('http://myhost.domain.com:7499/fed/sp',
'attributelist')
createFederationPropertyMapInMap('http://myhost.domain.com:7499/fed/sp','attributelist','cncommonName')

- 属性にプロパティがまだ存在しない場合は、次のガイドラインを使用して新しいプロパティを追加します。(このプロパティは、前の手順で作成した要素に追加されます。)

注意:
最初からマッピングを作成する場合は、属性「require-from-infocard」を含める必要があります。

プロパティ

設定値

datastore-attr

cn

assertion-attr

commonName

format-attr

空の値

send-with-sso

true(常にSSOアサーションで属性を送信する)またはfalse(属性を送信しない)

from-session

true(Oracle Identity Federationユーザー・セッションから属性値を取得する)またはfalse(値を取得しない)

from-config

true(属性に静的値がある)またはfalse

attribute-value-fromconfig

静的値(必要な場合)

次に例を示します。

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'datastore-attr', 'cn', 'string')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'assertion-attr', 'commonName', 'string')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'format-attr', '', 'string')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'send-with-sso', 'true', 'boolean')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-session', 'false', 'boolean')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-config', 'true', 'boolean')

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'attribute-value-fromconfig', 'cn=users,dc=oracle,dc=com', 'string')

「require-from-infocard」プロパティを含む別の例を次に示します。

addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'require-from-infocard', 'true', 'boolean')

- プロパティとそれに対応する属性のマップを削除するには次のようにします。

removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName','attribute-value-fromconfig')

removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName','from-config')

removeFederationMapInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName')

5.9.1.2 属性値マッピング

管理者は、属性値マッピングを使用することにより、メッセージの送受信時にSAMLメッセージでローカル属性を割り当てるための値を指定できます。

属性値マッピングには、次のような特徴があります。

- 値マッピングは、ローカル値とこれに対応する外部値の組合せで構成されます。

- 値マッピングは任意のローカル属性に対して定義できます。ローカル属性ごとに複数の値マッピングを定義できます。

- 値マッピングを使用して、同じローカル値に対して様々な外部値をマップできます。送信モードで使用される外部値の決定には、デフォルトの属性が使用されます。

- 値マッピングを使用して、同じ外部値に対して様々なローカル値をマップできます。外部値からローカル値へのマッピング時に受信モードで使用されるローカル値の決定には、デフォルトの属性が使用されます。

Oracle Identity Federationによって属性値マッピングが実行されるのは、Oracle Identity Federationが次のものとして動作する場合です。

- 属性認証局

- 属性リクエスタ

- アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)

属性値マッピングは、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.2項「属性値マッピングの構成」を参照してください。

5.9.1.3 属性値フィルタリング

管理者は、属性値フィルタリングを使用して、SAMLメッセージの送信時に使用可能なローカル値を指定できます。

属性値フィルタリングには、次のような特徴があります。

- フィルタ・ルールは任意のローカル属性に対して定義できます。フィルタ・ルールによって各属性値を評価し、送信可能かどうかを決定します。評価結果が正である場合、値は送信されます。正でない場合、送信対象の属性値のリストから削除されます。

- ローカル属性ごとに複数のフィルタリング・ルールを定義できます。値の送信時には、次のいずれかのようにOracle Identity Federationを設定できます。

- すべてのフィルタが正常に評価された場合のみ送信します。

- 少なくとも1つのフィルタが正常に評価された場合のみ送信します。

- 管理者は、比較のタイプと比較対象の文字列値を指定することにより、フィルタリング・ルールを定義します(第5.9.2.3項「属性値フィルタリングの構成」を参照)。

- Oracle Identity Federationは、属性値と文字列を比較する場合、次の比較タイプをサポートしています。

- 次と等しい

- 次と等しくない

- 次で始まる

- 次で終わる

- 次を含む

- 次を含まない

- NULLと等しい

- NULLと等しくない

- これらの比較タイプ以外にも、フィルタリングでは正規表現もサポートしており、属性値と正規表現を照合できます。詳細は、第5.9.2.3項「属性値フィルタリングの構成」の第5.9.2.3.1項「フィルタリング条件」を参照してください。

- フィルタリング・ルールを使用して、比較時に大/小文字を区別するかどうかを指定できます。

Oracle Identity Federationによって属性値フィルタリングが実行されるのは、Oracle Identity Federationが次のように動作する場合です。

- 属性認証局

- アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)

この機能は、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.3項「属性値フィルタリングの構成」を参照してください。

5.9.2 マッピングおよびフィルタリング構成

この項では、マッピングおよびフィルタリングの構成方法を説明します。

- 属性名マッピングの構成

- 属性値マッピングの構成

- 属性値フィルタリングの構成

5.9.2.1 属性名マッピングの構成

属性名マッピングの構成には次の目的があります。

IdP側:

- アサーションに含まれる属性名をローカル属性名にマップします。

- ピア・プロバイダに送信できるローカル属性を定義します。つまり、ピア・プロバイダの属性名マッピングを定義することにより、Oracle Identity Federationによるこの属性のリモート・サーバーへの送信を認可します。

SP側:

- SOAPクライアントのリクエストに含まれる属性名を、属性認証局への属性問合せの名前にマップします。

属性名マッピングを定義するには、次の手順を実行します。

関連項目:
第5.11項「フェデレーションの構成」

IdP側

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「フェデレーション」の順に移動します。

3. 属性共有を構成する属性リクエスタを選択し、「編集」をクリックします。

4. 「属性名マッピングの編集」をクリックします。

5. 「名前マッピング」タブで「追加」をクリックして属性名マッピングを追加し、次のフィールドを設定します。

- ユーザー属性名: ユーザー・リポジトリ内のローカル属性の名前です。アサーション属性にユーザーIDをマップする必要がある場合は、このフィールドに「orafed-userid」を設定します。

- アサーション属性名: 属性問合せおよびアサーション内の属性を識別するために使用される名前です。

- フォーマットまたはネームスペース: バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。

- SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。

- SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。

- SSOアサーションで送信: SSO処理時にアサーションで属性を送信するかどうかを示します。

注意:
アイデンティティ・プロバイダからピア・プロバイダに属性を送信するには、その属性のマッピングを前述したように定義する必要があります。

- ユーザー・セッションから値を取得: 属性値をユーザー・セッションから取得するかどうかを示します。

- 情報カードの内容が必要: 属性を情報カードから渡す必要があるかどうかを示します。

SP側

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「フェデレーション」の順に移動します。

3. 属性共有を構成する属性認証局を選択し、「編集」をクリックします。

4. 「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。

5. 「名前マッピング」タブで「追加」をクリックして属性名マッピングを追加し、次のフィールドを設定します。

- ユーザー属性名: AttributeRequestのSOAPクライアントで使用される名前です。

- アサーション属性名: 属性問合せおよびアサーション内の属性を識別するために使用される名前です。

- フォーマットまたはネームスペース: バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。

- SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。

- SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。

- ユーザー・セッションから値を取得: 属性値をユーザー・セッションから取得するかどうかを示します。

- 情報カードの内容が必要: 属性を情報カードから渡す必要があるかどうかを示します。

注意:
属性名に対するマッピングが見つからない場合、サービス・プロバイダは名前をそれ自体にマップします。

例

次に、属性名構成とその構成で得られる結果を示します。

SPの名前マッピング:

ユーザー属性

アサーション属性

phone

telephone

userid

username

email

emailaddress

id

idnumber

IdPの名前マッピング:

アサーション属性

ユーザー属性

lastname

sn

idnumber

employeenumber

telephone

telephonenumber

title

title

username

uid

emailaddress

mail

firstname

givenname

結果:

SOAPクライアント・リクエスト内の属性

SAML属性問合せ内の属性

ユーザー・データ・ストア内の属性

SAMLアサーション内の属性

SOAPクライアントへのレスポンス内の属性

lastname

lastname

sn

lastname

lastname

id

idnumber

employeenumber

idnumber

id

phone

telephone

telephonenumber

telephone

phone

title

title

title

title

title

userid

username

uid

username

userid

email

emailaddress

mail

emailaddress

email

firstname

firstname

givenname

firstname

firstname

middlename

middlename

-

-

-

次の点に注意してください。

- 属性lastname、title、firstnameは、SPでマッピングされていないため、これらの属性はそれ自体にマッピングされます。

- 属性middlenameは、IdPでマッピングされていないため、IdPはこの属性に関する値を返しません。属性問合せ/アサーションで使用される属性名がユーザー・データ・ストア内の名前と同じ場合は、属性名のマッピングを明示的に定義する必要があるため、属性titleで示したように、名前をそれ自体にマップします。

5.9.2.2 属性値マッピングの構成

属性値マッピングを定義するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「フェデレーション」の順に移動します。

3. 属性共有を構成するピア・プロバイダを選択し、「編集」をクリックします。

4. 「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。

5. 「値マッピング」タブで「追加」をクリックして属性値マッピングを追加し、次のフィールドを設定します。

- 属性名: ユーザー・リポジトリ内のローカル属性の名前です。

- アンマップ値: マッピングが定義されていない値をOracle Identity Federationから送信できるようにするには、「送信」を選択します。マッピングが定義されていない値をOracle Identity Federationで受信できるようにするには、「受信」を選択します。

- ローカルと外部との値マッピングのリスト:

- ローカル値: 属性のローカル値

- 外部値: 外部メッセージで送信する際に対応する値

- 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。

- ローカルNULL: 選択した場合、ローカル値がヌル文字列(空の文字列「""」とは異なる)であることを示します。

- 外部NULL: 選択した場合、外部値がヌル文字列(空の文字列「""」とは異なる)であることを示します。

- デフォルト: 選択した場合、着信外部値が複数のローカル値にマップ可能な場合に、このローカル値が使用されることを示します。

例

属性titleに対して次の値マッピングが構成されている場合、結果は次のようになります。

- 属性名: title

- アンマップ値:

- 送信: 選択

- 受信: 選択

- 値マッピング:

ローカル値

外部値

大/小文字区別なし

ローカルNULL

外部NULL

デフォルト値

Senior Member of Technical Staff

smts

選択

選択

Principal Member of Technical Staff

pmts

選択

なし

選択

Senior Member of Technical Staff

srmts

選択

Consulting Member of Technical Staff

cmts

選択

結果:

外部値

ローカル値へのマップ

Consulting Member of Technical Staff

cmts

PRINCIPAL MEMBER OF TECHNICAL STAFF

pmts

Principal Member of Technical Staff

pmts

Senior Member of Technical Staff

smts

Vice President

Vice President

ローカル値

外部値へのマップ

NULL

なし

smts

Senior Member of Technical Staff

srmts

Senior Member of Technical Staff

CEO

CEO

次の点に注意してください。

- 値マッピングで大/小文字は区別しないと定義したため、「PRINCIPAL MEMBER OF TECHNICAL STAFF」と「Principal Member of Technical Staff」は両方ともpmtsにマップされます。

- 「アンマップ値」の「送信」が選択されており、値「Vice President」にはルールが定義されていないため、この値はそれ自体にマップされます。

- smtsを「Senior Member of Technical Staff」のデフォルトローカル値として定義したため、「Senior Member of Technical Staff」はsrmtsにもマップされていますが、smtsにマップされます。

- ローカル値がNULLの場合は、文字列Noneにマップされます。

- smtsおよびsrmtsは、ともに"Senior Member of Technical Staff"にマップされます。

- 「アンマップ値」の「受信」が選択されており、「CEO」にはルールが定義されていないため、この値はそれ自体にマップされます。

5.9.2.3 属性値フィルタリングの構成

次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「フェデレーション」の順に移動します。

3. 属性共有を構成する属性リクエスタを選択し、「編集」をクリックします。

4. 「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。

5. 「値フィルタ」タブで「追加」をクリックして属性値フィルタを追加し、次のフィールドを設定します。

- 属性名: ユーザー・リポジトリ内のローカル属性の名前です。

- 条件演算子: 「and」を選択した場合は、送信される属性がすべての条件を満たしている必要があることを示します。「or」を選択した場合は、1つでも条件を満たしていれば属性を送信できることを示します。

- フィルタリング・ルールのリストには次のフィールドがあります。

- 条件: 属性値の評価に使用される条件です。

- 式: 属性値の評価に使用される値または正規表現です。

- 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。

5.9.2.3.1 フィルタリング条件

Oracle Identity Federationには複数のフィルタリング条件が用意されています。

- equals: 式の値が送信属性値と等しい場合、trueを戻します。

- does not equal: 式の値が送信属性値と異なる場合、trueを戻します。

- starts with: 送信属性値が式の値から始まる場合、trueを戻します。

- ends with: 送信属性値が式の値から終わる場合、trueを戻します。

- contains: 送信属性値に式の値が含まれる場合、trueを戻します。

- does not contain: 送信属性値に式の値が含まれない場合、trueを戻します。

- equals null: 送信属性値がNULLである場合、trueを戻します。

- does not equal nul: 送信属性値がNULLでない場合、trueを戻します。

- regexp: 送信属性値が式の値に定義されている正規表現と一致する場合、trueを戻します。

注意:
これらのルールを使用して許容値が決定されます。このため、ルールの評価結果がtrueである場合、値が送信可能であることを示します。

フィルタリング条件をregexpに設定する場合、式の値は標準のUNIXの正規表現である必要があります。

正規表現の構文の詳細は、http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.htmlを参照してください。

注意:
フィルタリング条件をregexpに設定すると、正規表現ではすでに大/小文字を区別しないため、属性値処理時にignoreCaseフラグは無視されます。

表5-8は、regexpフィルタリング条件の使用方法を表す例を示しています。

表5-8 regexpフィルタリング条件の使用例

正規表現

意味

.*rector

「rector」で終わる任意の文字列

[^abc]

a、bまたはcを除く任意の文字(否定)

user\d

user0、user1、...、user9

a*b

0個以上の文字aで始まり、文字bで終わる文字列(例: aaaaab)

5.9.2.3.2 値フィルタの例

この項では、値フィルタの構成例をいくつか示します。

例1

属性titleに対して次の値フィルタが構成されている場合、結果は次のようになります。

- 属性名: title

- 条件演算子: and

- 値フィルタ:

条件

式

大/小文字区別なし

does not equal

Vice-President

選択

次を含む

President

選択

結果:

値

値を送信するか

Vice-President

いいえ

President

はい

Vice-President

いいえ

Senior Vice-President

はい

例2

属性値マッピングが、第5.9.2.2項「属性値マッピングの構成」の例で示したように定義されているとします。属性titleに対して次の値フィルタが構成されている場合、結果は次のようになります。

- 属性名: title

- 条件演算子: and

- 値フィルタ:

条件

式

大/小文字区別なし

does not equal

mngr

true

次で終わる

mts

false

結果:

値

値を送信するか

送信される値

mngr

いいえ

cmts

はい

Consulting Member of Technical Staff

次の点に注意してください。

- 送信される値は、mngrに一致してはいけないため、値mngrは送信されません。

- cmtsは送信され(すべてのフィルタ条件がtrueの場合)、「Consulting Member of Technical Staff」にマップされます。

- 次の値フィルタでも同じ結果になります。

条件

式

大/小文字区別なし

does not equal

mngr

true

regexp

*mts

5.10 セキュリティおよび信頼の構成

セキュリティおよび信頼の各ページを使用して、Oracle Identity Federationサーバーのキーストアおよび証明書を構成します。

これらのページにアクセスするには、まず「トポロジ」アイコンの隣にあるドロップダウンから「Oracle Identity Federation」を選択し、「管理」→「セキュリティおよび信頼」の順に移動します。

この項では、信頼の構成に関連する次の内容について説明します。

- セキュリティおよび信頼 - ウォレット

- セキュリティおよび信頼 - プロバイダ・メタデータ

- セキュリティおよび信頼 - 信頼できるCAおよびCRL

5.10.1 セキュリティおよび信頼 - ウォレット

サーバー・インスタンスの署名証明書および暗号化証明書はウォレットに保存されます。このページは、署名および暗号化ウォレットを管理するために使用します。

このページには次の内容が表示されます。

- 署名ウォレットのタイプ(PKCS#12、JKSなど)

- ウォレット内の署名鍵の別名

- 旧署名ウォレットのタイプ(PKCS#12、JKSなど)

- 旧ウォレット内の旧署名鍵の別名

- 暗号化ウォレットのタイプ(PKCS#12、JKSなど)

- ウォレット内の暗号化鍵の別名

- 旧暗号化ウォレットのタイプ(PKCS#12、JKSなど)

- 旧ウォレット内の旧暗号化鍵の別名

ウォレットの情報を変更するには、「更新」をクリックします。「ウォレットの更新」ダイアログでは、署名または暗号化ウォレットに関する次の情報が必要になります。

- ウォレット・ロケーション - ウォレットを含むオペレーシング・システム・ファイルを選択できます。

- パスワード - 秘密鍵を暗号化するために使用されたパスワードを入力します。

- キー・パスワード - JKSキーストアおよびカスタムJavaキーストアの場合にのみ必要です。

- 署名鍵別名 - 秘密鍵がウォレットに保存される場合の別名です。

5.10.2 セキュリティおよび信頼 - プロバイダ・メタデータ

このページでは、次の操作を行います:

- メタデータ署名の要件を指定します。

- 更新されたメタデータを生成します。

メタデータ署名

Oracle Identity Federationは、準拠しているフェデレーション・サーバーによって公開されるサービスを記述するXMLメタデータ文書でXMLデジタル署名をサポートしています。Oracle Identity Federationは、メタデータ署名に次のサポートを提供します。

- Oracle Identity Federationが公開するメタデータにデジタルで署名します。

- サーバーにアップロードされるメタデータ文書にあるXMLデジタル署名を検証します。検証が失敗すると、メタデータはアップロードされません。

- 信頼できるプロバイダにアップロードするためにプロバイダ・メタデータでXMLデジタル署名を必要とするようサーバーを構成します。

このページのこのセクションでは、メタデータ署名を指定します。次の情報を指定します。

- 署名付メタデータが必要 - このボックスを選択すると、信頼できるプロバイダに記述子をインポートするときに、署名されたメタデータをOracle Identity Federationが要求するよう指定できます。そのため、ピア・プロバイダは署名付メタデータをサーバーに提供する必要があります。

- メタデータの署名 - このボックスは、Oracle Identity Federationサーバーでメタデータに署名する必要がある場合に選択します。

- 有効期間 - 有効期間を入力します(単位は日)。

変更を保存するには「適用」を、フィールドを前の状態にリセットするには「元に戻す」をクリックします。

メタデータの生成

このページのこのセクションは、メタデータに影響するサーバー構成を変更した後で、メタデータを生成してピア・プロバイダに配布する場合に使用します。

- プロバイダ・タイプ - ドロップダウン・リストからタイプを選択します。

- プロトコル - ドロップダウン・リストからプロトコルを選択します。
この機能は、SAML 1.0、1.1および2.0プロトコルでサポートされます。

注意:
Liberty 1.xの構成およびメタデータのアップロードを利用するには、WLSTコマンドライン・ツールを使用します。

「保存」をクリックしてメタデータを生成および配布します。

5.10.3 セキュリティおよび信頼 - 信頼できるCAおよびCRL

Oracle Identity Federationは、信頼できる証明書とCRLを保持するための証明書ストアをメンテナンスします。証明書検証ストアが有効化されている場合、Oracle Identity Federationでは、これを使用してSAML/WSフェデレーション受信メッセージの署名検証が必要な証明書が検証されます。

このページは、証明書検証ストア内で次のオブジェクトをメンテナンスする場合に使用します。

- 認証局(CA)証明書

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

次の情報を指定します。

- 認証検証の有効化 - このボックスを選択すると、サーバーでの証明書の検証が有効になります。
変更を保存するには「適用」を、フィールドを前の状態にリセットするには「元に戻す」をクリックします。

- 信頼できる認証局(CA) - この表には、Oracle Identity Federationで信頼されているCAの詳細が表示されます。
CAのフィールドは次のとおりです。

- サブジェクト - CA証明書のサブジェクト

- 発行者 - 証明書の発行者

- シリアル番号 - 証明書のシリアル番号

- 有効期限開始 - 証明書の有効期間の開始日時

- 有効期限終了 - 証明書の有効期間の終了日時

CAをストアから削除するには、そのCAを選択して「削除」をクリックします。新しい信頼できるCAをストアに追加するには、「追加」をクリックします。

- 証明書失効リスト - CRLの表には、Oracle Identity Federationが認識している証明書失効リスト(CRL)のリストが表示されます。
CRLのフィールドは次のとおりです。

- 発行者 - CRLを発行したCA

- 有効期限開始 - CRLの有効期間の開始日時

- 有効期限終了 - CRLの有効期間の終了日時

CRLをストアから削除するには、そのCRLを選択して「削除」をクリックします。新しいCRLをストアに追加するには、「追加」をクリックします。

5.11 フェデレーションの構成

第4.3項「アイデンティティ・フェデレーションの管理」を参照してください。

5.12 アイデンティティの構成

第4.4項「アイデンティティの構成」を参照してください。

5.13 データ・ストアの管理

この項では、Oracle Identity Federationで使用される各種データ・ストアの構成方法および管理方法について説明します。

- ユーザー・データ・ストアの管理

- フェデレーション・データ・ストアの管理

- セッション・データ・ストアおよびメッセージ・データ・ストアの管理

- 構成データ・ストアの管理

- RCUを使用したOracle Identity Federationスキーマの作成

5.13.1 ユーザー・データ・ストアの管理

この項では、Oracle Identity Federationでユーザー・データ・ストアを構成する方法を説明します。

- RDBMSユーザー・データ・ストアを使用するOracle Identity Federationの構成

- LDAPユーザー・データ・ストアを使用するOracle Identity Federationの構成

- ユーザー・データ・ストアとしてのOracle Virtual Directoryの構成

- 冗長性ユーザー・データ・ストアの構成

- ユーザー・データ・ストアを使用しない構成

5.13.1.1 RDBMSユーザー・データ・ストアを使用するOracle Identity Federationの構成

Oracle Identity Federationでデータベースをユーザー・データ・ストアとして使用するには、ユーザー表と呼ばれる、ユーザー情報を格納する表をそのデータベースで使用する必要があります。ユーザー表にはユーザーIDを格納する列が必要になります。Oracle Identity FederationはこのユーザーIDを使用してユーザーを識別します。ユーザーIDは必ず存在し、すべてのユーザーで一意である必要があります。属性共有または属性を使用したユーザー・マッピングを使用する場合は、これらの属性の列もユーザー表に存在する必要があります。

RDBMSユーザー・データ・ストアを使用するようにOracle Identity Federationを構成する手順は次のとおりです。

1. JDBCデータ・ソースを作成します。

2. Oracle Identity Federationデータ・ストア構成を変更します。

JDBCデータ・ソースを作成します。

JDBCデータ・ソースを作成するには、次の手順に従います。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「JDBC」→「データ・ソース」の順に移動します。

3. 「新規」をクリックします。

4. 新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。

RDBMSユーザー・データ・ストアの構成

RDBMSユーザー・データ・ストアを構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「ユーザー・データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。

5. 次のプロパティを入力します。

- JNDI名: WebLogic管理コンソールで作成したデータ・ソースのJNDIです。

- ログイン表: ユーザー表の名前です。

- ユーザーID属性: ユーザー表の「ユーザーID」列の名前です。

- ユーザーの説明属性: ユーザー表の「ユーザーの説明」列の名前を入力します。

6. 「OK」をクリックします。

例

次の「UserInformation」というユーザー表を使用し、データ・ソースのJNDI名が「MyCorpUserDS」であるとします。

Username

FirstName

LastName

FullName

Email

alice

Alice

Smith

Alice Smith

alice@mycorp.com

bob

Robert

Jones

Robert Jones

bob@mycorp.com

charlie

Charles

Johnson

Charles Johnson

charlie@mycorp.com

david

David

Jones

David Jones

david@mycorp.com

robert

Robert

Williams

Robert Williams

williams@mycorp.com

このユーザー・データ・ストアに対するOracle Identity Federation構成は次のようになります。

- JNDI名: MyCorpUserDS

- ログイン表: UserInformation

- ユーザーID属性: Username

- ユーザーの説明属性: Full Name

または、次のように構成することもできます。

- JNDI名: MyCorpUserDS

- ログイン表: UserInformation

- ユーザーID属性: Username

- ユーザーの説明属性: Username

5.13.1.2 LDAPユーザー・データ・ストアを使用するOracle Identity Federationの構成

LDAPユーザー・データ・ストアを構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「ユーザー・データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「LDAPディレクトリ」を選択します。

この構成で設定するフィールドは次のとおりです。

- 接続URL - サーバーに接続するLDAPのURLです。例: ldap://ldap.oif.com:389

- バインドDN - LDAPサーバーへの接続に使用する管理者アカウントDNです。例: cn=orcladmin

- パスワード - LDAPサーバーに接続する管理者パスワードです。

- ユーザーID属性 - 認証時にユーザーを識別するために使用されるLDAP属性(たとえばuid)です。様々なタイプのディレクトリ・サーバーに対するユーザーID属性の例を次に示します。

- Oracle Internet Directory:uid

- Sun Java System Directory Server:uid

- Microsoft Active Directory:sAMAccountName

- ユーザーの説明属性 - フェデレーション・レコードの所有者を識別するために使用される可読的なLDAP属性(たとえばuid)です。ディレクトリ・サーバーのタイプごとのユーザー説明属性の例を次に示します。

- Oracle Internet Directory:uid

- Sun Java System Directory Server:uid

- Microsoft Active Directory:sAMAccountName

- 個人オブジェクト・クラス - オブジェクト・クラスにより、どのようなデータまたは属性をオブジェクトに関連付けるかが定義されます。個人オブジェクト・クラスは「個人」オブジェクトの属性を参照しますが、これは当該コンテキストでは、フェデレーテッド・アイデンティティ所有者のことです。ディレクトリは、1つ以上のオブジェクト・クラスを利用して個人データ(名前、住所など)を保持できます。サーバーでLDAPユーザー・エントリを表しているLDAPオブジェクト・クラスを入力します。様々なタイプのディレクトリ・サーバーに対する個人オブジェクト・クラスの例を次に示します。

- Oracle Internet Directory:inetOrgPerson

- Sun Java System Directory Server:inetOrgPerson

- Microsoft Active Directory:user

- ベースDN - ユーザーを検索する範囲となるディレクトリです。

- 最大接続数 - Oracle Identity FederationがLDAPサーバーに同時に開くLDAP接続の数の最大値です。

- 接続待機タイムアウト - Oracle Identity FederationがLDAPサーバーへの接続を開く際に使用するタイムアウト(分)です。

5.13.1.3 ユーザー・データ・ストアとしてのOracle Virtual Directoryの構成

Oracle Identity FederationはOracle Virtual Directoryと統合できます。Oracle Virtual Directoryをユーザー・データ・ストアとして使用する場合は、Oracle Virtual Directoryに接続されているすべてのディレクトリ構造に対して、ベースDN、個人オブジェクト・クラス、一意ユーザーIDおよびユーザーの説明属性の設定が有効になるようにしてください。

5.13.1.4 冗長性ユーザー・データ・ストアの構成

ユーザー・データ・ストアでは冗長性がサポートされます。この項では、冗長性ユーザー・データ・ストアの設定方法について説明します。

冗長性ユーザー・データ・ストアを設定するには次の2つの方法があります。

1. ユーザー・データ・ストア構成の「サーバーURL」フィールドで、LDAP URLのスペース区切りリストを入力します。
次に例を示します。

ldap://ldap1.oif.mycorp.com ldap://ldap2.oif.mycorp.com ldap://ldap3.oif.mycorp.com

または

2. LDAPサーバーの前面にロード・バランサを設定し、Oracle Identity Federation構成の「ldaphaenabled」プロパティをtrueに設定します。このタスクの詳細は、第6.4.1項「高可用性LDAPサーバーの構成」を参照してください。

5.13.1.5 ユーザー・データ・ストアを使用しない構成

実行時にユーザー・データ・ストアを使用しないようにOracle Identity Federationを構成できます。この構成では、サーバーで使用できるユーザー情報は次の時点のユーザー識別子に限られます。

- ローカル認証後

- サーバーがサービス・プロバイダとして動作する場合は、フェデレーテッド・アイデンティティ・レコードを使用して着信アサーションがマップされた後

ユーザー・データ・ストアを使用しないようにOracle Identity Federationを構成する手順は次のとおりです。

1. Oracle Identity Federationデータ・ストア構成を変更します。

2. ユーザー識別子を使用するようにOracle Identity Federation構成を変更します。

Oracle Identity Federationデータ・ストア構成を変更します。

ユーザー・データ・ストアを使用しないように構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「ユーザー・データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストからNoneを選択します。

5. 「OK」をクリックします。

ユーザー識別子を使用するためのOracle Identity Federation構成の変更

ユーザー・データ・ストアでNoneを選択した場合、アサーション・データの移入時またはフェデレーション・データ・ストアの構成時にユーザー識別子を使用するようにOracle Identity Federationを構成できます。

Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合、サーバーを次のように構成できます。

- ユーザー識別子をアサーション名前IDとして設定します。
これを行うには、「名前IDフォーマット」表に移動して、名前IDフォーマットのユーザー属性にorafed-useridを設定します。

- ユーザー識別子をアサーション属性として追加します。
これを行うには、アサーションが送信されるリモート・サービス・プロバイダの構成画面に移動して、送信属性を定義し、ユーザー属性にorafed-useridを設定します。

フェデレーション・データ・ストアを使用している場合は、フェデレーション・データ・ストアを構成するセクションで、Oracle Identity FederationがユーザーID属性およびユーザーの説明属性としてorafed-useridを使用するようにしてください。

5.13.2 フェデレーション・データ・ストアの管理

Oracle Identity Federationには、フェデレーテッド・アイデンティティ情報を含むレコードをバックエンドのデータ・ストアに保存するための構成オプションが用意されています。

XML、LDAPまたはRDBMSのタイプのフェデレーション・データ・ストアを使用するように構成されている場合、Oracle Identity Federationは各ユーザーのフェデレーション・レコードを作成し、選択されたデータ・ストアにレコードを保存して、シングル・サインオンでアサーションを作成する際(アイデンティティ・プロバイダとして動作する場合)、またはIdPから受信したアサーションをユーザーにマップする際(サービス・プロバイダとして動作する場合)にこのレコードを使用します。

SAML 2.0プロトコルで永続名前IDを使用するには、フェデレーション・データ・ストアが必要です。これは、各ユーザーの不透明な識別子を作成する必要があるためです(つまり、ユーザーの識別時に使用される名前IDを、ユーザー・データ・ストアの属性から指定することができないため、この名前IDを個別に作成して保存する必要があります)。

Oracle Identity Federationは、ユーザーがシングル・サインオン処理を最初に実行するときにフェデレーション・レコードを作成します。Oracle Identity Federationがサービス・プロバイダとして動作し永続名前IDを使用する場合、名前IDにはユーザー情報が含まれないため、Oracle Identity Federationはユーザーにローカル認証を要求し、この認証からユーザー情報を取得してフェデレーション・レコードを作成します。フェデレーションが作成されると、Oracle Identity Federation(サービス・プロバイダとして動作)は、このフェデレーション・レコードを使用してアサーションの不透明な名前IDを自動的にユーザーにマップするため、ユーザーはローカル・ログインを求められません。

フェデレーション・データ・ストアがNoneに設定されている場合、Oracle Identity Federationはフェデレーション・レコードの作成、保存、使用を行わずに、ユーザー・データ・ストアの属性を使用してユーザーを識別し、アサーションの作成(アイデンティティ・プロバイダとして動作する場合)や、ユーザーへのアサーションのマップ(サービス・プロバイダとして動作する場合)を行います。

注意:
本番環境では、XMLをフェデレーション・ストアとして構成することはお薦めしません。本番環境ではRDBMSまたはLDAPストアを使用してください。

注意:
冗長性データ・ストアを設定することもできます。詳細は、第5.13.1.4項「冗長性ユーザー・データ・ストアの構成」を参照してください。

ガイドライン

一般的なガイドラインを次に示します。

- フェデレーション・データ・ストアがNoneに設定されている場合:

- 永続名前IDを使用することはできません。

- アイデンティティ・プロバイダとして動作する場合、Oracle Identity Federationはアサーションを作成する際に、使用する名前IDフォーマットをユーザー・データ・ストアの属性にマッピングし、この属性の値を名前IDとして使用します。

- サービス・プロバイダとして動作する場合、Oracle Identity Federationはアイデンティティ・プロバイダから受信したアサーションをマップする際に、属性問合せを使用するか、アサーションの名前IDをユーザー・データ・ストアのエントリにマッピングします。

- フェデレーション・データ・ストアがXML、LDAPまたはRDBMSに設定されている場合:

- 永続名前IDを使用できます。

- アイデンティティ・プロバイダとして動作する場合、Oracle Identity Federationはアサーションの作成時に、そのユーザーに作成されたフェデレーション・レコードの名前IDを使用します。

- サービス・プロバイダとして動作する場合、Oracle Identity Federationはアサーションをユーザーにマップする際に、アサーションに含まれている名前IDでフェデレーション・レコードを検索します。

- サービス・プロバイダとして動作し永続名前IDを使用する場合、そのユーザーとプロバイダが最初にSSOを実行するときにOracle Identity Federationによってローカル認証が求められます。

以降の項では、次の内容について説明します。

- RDBMSフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- LDAPフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- XMLフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

- フェデレーション・データ・ストアとしてのOracle Virtual Directoryの構成

5.13.2.1 RDBMSフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

RDBMSフェデレーション・データ・ストアを構成するための大まかな手順は次のとおりです。

1. JDBCデータ・ソースを作成します。

2. RCUを実行してOracle Identity Federationスキーマを作成します。

注意:
RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。

3. Oracle Identity Federationデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、フェデレーション・データ・ストアを構成する手順が含まれます。

以降で、それぞれの手順を詳しく説明します。

JDBCデータ・ソースを作成します。

JDBCデータ・ソースを作成するには、次の手順に従います。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「JDBC」→「データ・ソース」の順に移動します。

3. 「新規」をクリックします。

4. 新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。

Oracle Identity Federationスキーマの作成

第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。

Oracle Identity Federationデータ・ストア構成を変更します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「フェデレーション・データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。

5. 「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。

6. 「OK」をクリックします。

5.13.2.2 LDAPフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

関連項目:
第2.4.1項「フェデレーション・データ・ストア」のLDAPスキーマに関する注意

LDAPフェデレーション・データ・ストアを構成するには、次の手順に従います。

接続URL

サーバーに接続するLDAPのURLです。次に例を示します。

ldap://ldap.oif.com:389

このフィールドには、LDAP接続URLのスペース区切りリストを入力できます。

バインドDN

LDAPサーバーへの接続に使用する管理者アカウントDNです。次に例を示します。

cn=orcladmin

ユーザー・フェデレーション・レコード・コンテキスト

すべてのフェデレーション・レコードが格納されるLDAPコンテナ・エントリです。次に例を示します。

cn=fed,dc=us,dc=oracle,dc=com

注意:

- フィールドの説明にあるように、ユーザー・フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスには互換性が必要です。

- LDAPディレクトリにユーザー・フェデレーション・レコード・コンテキスト・コンテナが存在しない場合、Oracle Identity Federationにより、実行時に最初にフェデレーション・レコードを格納する必要が生じたときに作成されます。

LDAPコンテナ・オブジェクト・クラス

LDAPコンテナがまだない場合に、それを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキスト・クラスのタイプです。フィールドが空の場合、値はapplicationProcessに設定されます。

Microsoft Active Directoryの場合、このフィールドは、ユーザー・フェデレーション・レコード・コンテキストに応じて、たとえばcontainerに設定される必要があります。これは、Microsoft Active DirectoryではapplicationProcessが機能しないためです。

これらのフィールドの関係を理解するには、ユーザー・フェデレーション・レコード・コンテキストがフェデレーション・レコードの格納されるLDAPコンテナ・エントリを参照し、LDAPコンテナ・オブジェクト・クラスによって、DNに使用されるLDAPコンテナ属性が定義されることに注意してください。ユーザー・フェデレーション・レコード・コンテキストには、フェデレーション・レコードが格納されるコンテナのDNを指定します。そのDNには、既存のコンテナの親と、そのオブジェクト・クラスの一部であるフェデレーション・レコード・コンテキストの属性が含まれます。

たとえば、コンテナの親がdc=us,dc=oracle,dc=comで、レコード・コンテキスト属性がcn=orclfedである場合、cnは「LDAPコンテナ・オブジェクト・クラス」フィールド(設定されていない場合はapplicationProcessオブジェクト・クラス)で設定されたオブジェクト・クラスの属性である必要があるという要件があるため、DNは最終的に次のようになります。

cn=orclfed,dc=us,dc=oracle,dc=com

「ユーザー・フェデレーション・レコード・コンテキスト」のDNをou=fed,dc=us,dc=oracle,dc=comのように表示することにした場合、属性にouを持つオブジェクト・クラス(たとえばapplicationProcess)に、「LDAPコンテナ・オブジェクト・クラス」を設定する必要があります。

DNが次のようである場合は、

cn=fed,dc=us,dc=oracle,dc=com

LDAPコンテナ・オブジェクト・クラスはcn属性を定義する必要があります。

様々なタイプのディレクトリ・サーバーの場合のLDAPコンテナ・オブジェクト・クラスの例を次に示します。

- Oracle Internet Directory: 空

- Sun Java System Directory Server: 空

- Microsoft Active Directory: container

最大接続数

Oracle Identity FederationがLDAPサーバーに同時に開くLDAP接続の数の最大値です。

接続待機タイムアウト

Oracle Identity FederationがLDAPサーバーへの接続を開く際に使用するタイムアウトです(単位は秒)。

5.13.2.3 XMLフェデレーション・データ・ストアを使用するOracle Identity Federationの構成

XMLファイルをフェデレーション・データ・ストアとして使用するようにOracle Identity Federationを構成するには、次の手順に従います。

注意:
本番環境では、XMLをフェデレーション・ストアとして構成することはお薦めしません。本番環境ではRDBMSまたはLDAPストアを使用してください。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「フェデレーション・データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストからXMLファイルを選択します。

5. 「OK」をクリックします。

5.13.2.4 フェデレーション・データ・ストアとしてのOracle Virtual Directoryの構成

Oracle Virtual DirectoryをOracle Identity Federation環境に統合してフェデレーション・データ・ストアとして動作させる場合、フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスの設定が、フェデレーション・レコードの格納に使用される特定のディレクトリ構造に対して有効であることを確認してください。つまり、フェデレーション・レコード・コンテキストによって参照されるLDAPサーバーのディレクトリ構造に対して有効である必要があります。

5.13.3 セッション・データ・ストアおよびメッセージ・データ・ストアの管理

Oracle Identity Federationは、フェデレーション・プロトコル/セッションの状態などの一時データの格納にメッセージ・データ・ストアおよびユーザー・データ・ストアを使用します。メッセージ・データ・ストアはユーザー・セッション・データ・ストアとともに、一時データ・ストアとも呼ばれます。

一時データは、メモリー内またはリレーショナル・データベースに格納できます。

メモリー内セッション/メッセージ・データ・ストアを使用するようにOracle Identity Federationを構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「セッション・データ・ストアとメッセージ・データ・ストア」セクションで、「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「メモリー」を選択します。

RDBMSセッション/メッセージ・データ・ストアを使用するようにOracle Identity Federationを構成する大まかな手順は次のとおりです。

1. JDBCデータ・ソースを作成します。

2. RCUを実行してOracle Identity Federationスキーマを作成します。

注意:
RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。

3. Oracle Identity Federationのデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、フェデレーション・データ・ストアを構成する手順が含まれます。

以降で、それぞれの手順を詳しく説明します。

JDBCデータ・ソースを作成します。

JDBCデータ・ソースを作成するには、次の手順に従います。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「JDBC」→「データ・ソース」の順に移動します。

3. 「新規」をクリックします。

4. 新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。

Oracle Identity Federationスキーマの作成

第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。

Oracle Identity Federationデータ・ストア構成を変更します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「構成データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。

5. 「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。

6. 「OK」をクリックします。

5.13.4 構成データ・ストアの管理

Oracle Identity Federationアプリケーションは、構成データ・ストアを使用して構成アーティファクトを格納します。構成データ・ストアは、XMLファイルまたはリレーショナル・データベースにすることができます。使用中のデプロイメントが高可用性デプロイメントの場合は、リレーショナル・データベースを構成データ・ストアとして使用する必要があります。

この項は次のトピックで構成されています。

- ファイル・システム構成データ・ストアの使用

- RDBMS構成データ・ストアの使用

- RDBMS構成データ・ストアが停止した場合

5.13.4.1 ファイル・システム構成データ・ストアの使用

構成データ・ストアは、基本インストール時にデフォルトでファイル・システムに格納されます。ストアをデータベースからファイル・システムに変更する手順は次のとおりです。

1. 「管理」→「データ・ストア」の順にナビゲートします。

2. 「構成データ・ストア」セクションで「編集」をクリックします。

3. 「リポジトリ・タイプ」ドロップダウン・リストから「ファイル・システム」を選択します。

5.13.4.2 RDBMS構成データ・ストアの使用

RDBMS構成データ・ストアを使用するようにOracle Identity Federationを構成する大まかな手順は次のとおりです。

1. JDBCデータ・ソースを作成します。

2. RCUを実行してOracle Identity Federationスキーマを作成します。

注意:
RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。

3. Oracle Identity Federationデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、構成データ・ストアを設定する手順が含まれます。

以降で、それぞれの手順を詳しく説明します。

JDBCデータ・ソースを作成します。

JDBCデータ・ソースを作成するには、次の手順に従います。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「JDBC」→「データ・ソース」の順に移動します。

3. 「新規」をクリックします。

4. 新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。

Oracle Identity Federationスキーマの作成

第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。

Oracle Identity Federationデータ・ストア構成を変更します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「データ・ストア」の順にナビゲートします。

3. 「構成データ・ストア」セクションで「編集」をクリックします。

4. 「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。

5. 「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。

6. 「OK」をクリックします。

5.13.4.3 RDBMS構成データ・ストアが停止した場合

構成データ・ストアがRDBMSに統合されていて、そのデータベースが停止した場合、Oracle Identity FederationではRDBMSから取得した最新バージョンの構成データを使用できるため、実行時の操作は影響を受けません。ただし、RDBMSの停止中は構成を行わないでください。これは、変更内容がRDBMSに保存されず、構成の変更がデータベースに伝播されないためです。

5.13.5 RCUを使用したOracle Identity Federationスキーマの作成

この項では、RCUを使用してOracle Identity Federationスキーマを作成する方法について説明します。データベースを使用するようにデータ・ストアを構成するには、スキーマを作成する必要があります。

1. インストールCDまたはインストーラ・バイナリからRCUをインストールします。

2. $RCU_HOME/bin/rcuを実行します。

注意:
RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。

3. 「作成」を選択してデータベースにコンポーネントを作成します。

4. 次の画面でデータベース接続の詳細を入力します。

5. 「コンポーネントの選択」画面の「アイデンティティ管理」から「Oracle Identity Federation」を選択します。

6. 「スキーマ・パスワード」画面でパスワードを入力します。

7. 処理を続行してOracle Identity Federationのスキーマ作成を完了させます。

5.14 認証メカニズムの構成

認証メカニズムにはルールが含まれており、このルールにはエンティティのアイデンティティを検証するために資格証明をどのように使用するかが指定されています。

次の項では、認証メカニズムについて説明した後で、各サーバー・プロトコルの認証メカニズムを構成します。

- 認証メカニズムについて

- 認証メカニズムの構成 - ローカル

- 認証メカニズムの構成 - SAML 2.0

- 認証メカニズムの構成 - SAML 1.x

- 認証メカニズムの構成 - WS-Federation 1.1

5.14.1 認証メカニズムについて

認証メカニズムにより、認証が必要な場合にユーザーがチャレンジを受ける方法を指定します。選択肢として、ユーザー名/パスワード、Kerberosなどがあります。サービス・プロバイダは認証リクエストで認証方式を指定することにより、アイデンティティ・プロバイダに対して一定の方法でユーザーのチャレンジを行うようにリクエストできます。

SPおよびIdPは様々なプロトコルによる通信が可能なため、Oracle Identity Federationのローカル認証メカニズムはプロトコル固有の方式をマップできるよう定義されています。

たとえば、SAML 2.0方式urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordとSAML 1.x方式urn:oasis:names:tc:SAML:1.0:am:passwordをローカル認証メカニズムoracle:fed:authentication:passwordにマップできます。

Oracle Identity Federationはこうしたローカル認証メカニズムを次のような状況で使用します。

1. SPは、ユーザーの認証方法を示した認証方式をリクエストで指定できます。Oracle Identity Federation IdPはこのリクエストを受信すると、リクエストされた方式をローカル認証メカニズムにマップします。認証方式がリクエストされなかった場合、IdPではデフォルト認証メカニズムが使用されます。この認証メカニズムが認証エンジンにマップされ、ユーザーに対するチャレンジ方法が決定されます。

2. SPエンジンは、ローカル認証メカニズムを指定することにより、SPがアイデンティティ・プロバイダにリクエストする認証方式を指定できます。このローカル・メカニズム(SPエンジンが指定しなかった場合はデフォルト・メカニズム)はプロトコル固有の方式にマップされ、SPがアイデンティティ・プロバイダに送信する認証リクエストに組み込まれます。

3. SPエンジンが認証リクエストの送信先のアイデンティティ・プロバイダを指定しない場合、SPはIdPを特定する際に、SPエンジンから受信した認証メカニズムをアイデンティティ・プロバイダにマップします(エンジンがメカニズムを送信しなかった場合は、デフォルト・メカニズムを使用します)。

4. アサーションの作成時に、アイデンティティ・プロバイダはユーザーの認証に使用するメカニズムを決定し、対応するプロトコル固有の認証方式をアサーションで指定します。

5. ユーザー・セッションの作成時に、Oracle Identity Federationはユーザーの認証に使用するローカル認証メカニズムを記録します。

6. Oracle Identity Federation IdPでフェデレーションSSOプロキシ・認証エンジンを使用する場合、Oracle Identity Federation IdPはリクエストされた認証メカニズム(SPから方式のリクエストがなかった場合はデフォルト・メカニズム)を使用して、リクエストの送信先のアイデンティティ・プロバイダを特定します。この認証エンジンの詳細は、第5.15.9.1項「フェデレーテッドSSOプロキシ認証エンジンについて」を参照してください。

この項のその他の内容は次のとおりです。

- デフォルト認証メカニズムの設定

- プロトコル固有の方式からローカル・メカニズム、ローカル・メカニズムから認証エンジンへのマッピング

- ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピング

5.14.1.1 デフォルト認証メカニズムの設定

サービス・プロバイダがリクエストで認証方式を指定しなかった場合、Oracle Identity Federation IdPでは前述のような状況でデフォルト認証メカニズムが使用されます。

関連項目:
第5.14.1項「認証メカニズムについて」

デフォルト認証メカニズムを設定するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証メカニズム」の順に移動します。

3. デフォルト認証メカニズムを選択して、「適用」をクリックします。

5.14.1.2 プロトコル固有の方式からローカル・メカニズム、ローカル・メカニズムから認証エンジンへのマッピング

前述のように、Oracle Identity Federationには次のようなマップ機能が用意されています。

- プロトコル固有の認証方式からローカル認証メカニズム

- ローカル認証メカニズムから認証エンジン

これにより、サービス・プロバイダがリクエストで指定した認証方式に応じて異なる認証エンジンを使用できます。

たとえば、SAML 2.0プロトコルで次のようなマッピングを定義できます。

urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos -> oracle:fed:authentication:kerberos

oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine

および

urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password

oracle:fed:authentication:password  ->  Oracle Single Sign-On

SAML 2.0 SPが、メカニズムurn:oasis:names:tc:SAML:2.0:ac:classes:Kerberosによってユーザーを認証するようにリクエストした場合、Oracle Identity Federationは作成済のカスタム認証エンジンを使用し、Kerberosによってユーザーを認証します。一方、SPがメカニズムurn:oasis:names:tc:SAML:2.0:ac:classes:Passwordをリクエストした場合は、Oracle Single Sign-Onエンジンによってユーザーが認証されます。

構成する内容は次のとおりです。

- ローカル認証メカニズムから認証エンジンへのマッピング

- プロトコル固有の認証方式からローカル認証メカニズムのマッピング

次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証メカニズム」の順に移動します。

3. 「ローカル・メカニズム」タブで、ローカル・メカニズムを有効にして認証エンジンにマップし、「適用」をクリックします。
たとえば、次のようなマッピングを追加します。

oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine

oracle:fed:authentication:password  ->  Oracle Single Sign-On

4. 各プロトコルに固有のタブ(SAML 2.0、SAML 1.x、WS-Federation 1.1)で、プロトコル固有の認証方式をローカル・メカニズムにマップし、「適用」をクリックします。
たとえば、SAML 2.0タブで次のようなマッピングを追加します。

urn:oasis:names:tc:SAML:2.0:ac:classes: Kerberos -> oracle:fed:authentication: kerberos

urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password

5.14.1.3 ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピング

ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピングを構成するには、次の手順に従います。

関連項目:
第5.5項「サービス・プロバイダの構成」

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ」の順に移動します。

3. 「プロトコル設定」で、「アイデンティティ・プロバイダ・マッピングに対するSSO認証メカニズム」をクリックします。

4. 「追加」をクリックして、認証メカニズムとマップ先のアイデンティティ・プロバイダを選択します。

5. マッピングの追加が完了したら、「OK」をクリックします。次に、「適用」をクリックします。

フェデレーションSSOプロキシ認証エンジンは、これらのマッピングを使用して、リクエストの送信先のアイデンティティ・プロバイダを決定します。

Oracle Identity Federationサービス・プロバイダも同様に、SPエンジンがSPへのリクエストでターゲットIdPを指定しなかった場合は、これらのマッピングを使用して、リクエストの送信先のアイデンティティ・プロバイダを特定します。たとえば、Oracle Access Manager SPエンジンを使用する場合、Oracle Access ManagerスキームをOracle Identity Federationのローカル認証メカニズムにマップできます。認証リクエストの送信先のアイデンティティ・プロバイダを特定する際にはこのマッピングが使用されます。

5.14.2 認証メカニズムの構成 - ローカル

このページでは、次の操作を行います:

- ローカル認証メカニズムの表示、追加、削除

- 選択した認証メカニズムの有効化または無効化

- ローカル認証メカニズムから認証エンジンへのマップ

- 相対的な順序やローカル認証メカニズムの更新表内で上位の順序にあるメカニズムほど、より上位の認証レベルを持ちます。

認証メカニズムの表には次の列が表示されます。

- ローカル認証メカニズムの名前

- メカニズムに現在関連付けられている認証エンジン

- そのメカニズムが現在アクティブかどうかを示すチェック・ボックス

メカニズムを有効(無効)にするには、「有効化」列で該当するボックスを選択(選択解除)します。

表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。

新しい認証メカニズムを追加するには、「追加」をクリックします。

既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。

メカニズムの順序を変更するには、行を選択してから表の上部にある矢印キーを使用します。

変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。

5.14.3 認証メカニズムの構成 - SAML 2.0

このページでは、次の操作を行います:

- SAML 2.0認証メカニズムの表示、追加、削除

- SAML 2.0認証メカニズムからローカル認証メカニズムへのマップ

認証メカニズムの表には次の列が表示されます。

- ローカル認証メカニズムの名前

- メカニズムに現在関連付けられている認証エンジン

表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。

新しい認証メカニズムを追加するには、「追加」をクリックします。

既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。

変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。

5.14.4 認証メカニズムの構成 - SAML 1.x

このページでは、次の操作を行います:

- SAML 1.x認証メカニズムの表示、追加、削除

- SAML 1.x認証メカニズムからローカル認証メカニズムへのマップ

認証メカニズムの表には次の列が表示されます。

- SAML 1.x認証メカニズムの名前

- メカニズムに現在関連付けられている認証エンジン

表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。

新しい認証メカニズムを追加するには、「追加」をクリックします。

既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。

変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。

5.14.5 認証メカニズムの構成 - WS-Federation 1.1

このページでは、次の操作を行います:

- WS-Federation 1.1認証メカニズムの表示、追加、削除

- WS-Federation 1.1認証メカニズムからローカル認証メカニズムへのマップ

認証メカニズムの表には次の列が表示されます。

- WS-Federation 1.1認証メカニズムの名前

- メカニズムに現在関連付けられている認証エンジン

表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。

新しい認証メカニズムを追加するには、「追加」をクリックします。

既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。

変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。

5.15 認証エンジンの構成

このページで構成する内容は次のとおりです。

- ユーザー・セッションの属性として使用されるHTTPヘッダー
これらのヘッダーを構成するには、「HTTPヘッダーの属性」の横にある「構成」ボタンをクリックします。表示されるダイアログ・ボックスで、ヘッダーの追加および既存ヘッダーの削除ができます。

- Oracle Identity Federationサーバーの認証エンジン

このページは、それぞれの認証エンジン用のタブで構成されています。タブで行った更新は、他のタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

- 認証エンジン - HTTPヘッダー

- 認証エンジン - Oracle Single Sign-On

- 認証エンジン - Oracle Access Manager 11g

- 認証エンジン - Oracle Access Manager 10g

- 認証エンジン - LDAPディレクトリ

- 認証エンジン - データベース・セキュリティ

- 認証エンジン - データベース表

- 認証エンジン - 情報カード

- 認証エンジン - フェデレーテッドSSOプロキシ

- 認証エンジン - JAAS

- 認証エンジン - カスタム

5.15.1 認証エンジン - HTTPヘッダー

HTTPヘッダー認証エンジンはHTTPヘッダーの値に基づいてユーザーを認証します。

そのようなエンジンのデプロイメントは、通常次のように構成されます。

- ドメインにデプロイされたOracle Identity Federationサーバー

- Oracle Identity Federationが実行されているWebLogic管理対象サーバーの前面に配置されたWebサーバー(Oracle HTTP Serverなど)(Oracle HTTP Serverがインストールされていない場合のデプロイ方法と統合方法の詳細は、第3.2.1項「Oracle Identity FederationとOracle HTTP Serverのデプロイ」を参照してください。)

- Webサーバーに統合されたWebエージェント。HTTPヘッダー認証エンジンのURL(http(s)://oif-host:oif-port/fed/user/authnhttp)を保護します。

- HTTPヘッダー認証エンジンのURLのWebエージェント・ポリシー。エージェントに対して、ユーザーのアイデンティティをHTTPヘッダー変数として設定するように指示します。

- ユーザーのアイデンティティを含むHTTPリクエストからHTTPヘッダー変数を取得するように構成されたOracle Identity Federation

WebエージェントによってHTTPヘッダー認証エンジンのURLが保護されるため、このURLでOracle Identity Federationサーバーが処理するリクエストは、Webエージェントが属しているWebアクセス管理システムによってユーザー認証が行われていることになります。

5.15.1.1 HTTPヘッダー認証エンジンの構成

「HTTPヘッダー」タブには次のフィールドがあります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- ユーザーの一意IDヘッダー - Oracle Identity FederationでHTTPヘッダー・エンジンを認証エンジンとして使用する場合、WebエージェントはOracle HTTP Server/Oracle Identity Federationに統合され、Oracle Identity Federation URLを保護します。Oracle Identity Federation URLのポリシー・ドメインは、ユーザー識別子をHTTPヘッダーとして提供するように構成されます。
このフィールドでは、Webエージェントから提供されるユーザー識別子を含むHTTPヘッダーの名前を指定します。

- ログアウト有効 - このボックスを選択すると、このエンジンによるログアウトが有効になります。ログアウトを有効にする場合、次のフィールドが関連します。

- ログアウトURL - Webアクセス管理システムのログアウト時に、Oracle Identity Federationによってユーザーがリダイレクトされる必要のあるURLです。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

注意:
ユーザーのログアウト時に、(ログアウト操作を実行するために)Webアクセス管理URLにリダイレクトする必要がある場合は、「ログアウト有効」を選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Webアクセス管理のログアウト操作が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。
Oracle Identity Federationは、returnurlで参照されるログアウトURLに問合せパラメータを追加します。

5.15.1.2 HTTPヘッダーの属性の構成

HTTPヘッダーの属性モジュールは、ローカル認証操作が成功した場合に呼び出されます。この操作では、ユーザーのHTTPリクエストからHTTPヘッダーが抽出され、Oracle Identity Federationセッションの属性として保存されます。Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合、これらの属性を使用してSAMLアサーションに移入できます。

HTTPヘッダーの属性モジュールを構成するには、次の手順を実行します。

1. 「認証エンジン」セクションで、「構成」をクリックして、HTTPヘッダーの属性モジュールを管理します。
HTTPヘッダーの属性がリストされたウィンドウが表示されます。この属性は、ローカル認証操作が成功した場合にOracle Identity Federationによって収集されます。

2. HTTPヘッダーを追加して、セッション属性として収集および保存されるようにするには、次のようにします。

- 「追加」をクリックします。

- HTTPヘッダーを取得するために、新しいフィールドにその名前を入力します。たとえば、Accept Languageヘッダーを取得するには、Accept-Languageと入力します。

- HTTPリクエストで提供されたCookieの値を取得するには、接頭辞にorafed-cookie-を使用してCookieの名前を入力します。たとえば、userLanguageCookieというCookieの値を取得するには、orafed-cookie-userLanguageCookieと入力します。Oracle Identity Federationは、実行時にCookieを取得して値を抽出し、orafed-cookie-userLanguageCookieセッション属性を設定します。

3. HTTPヘッダーを削除するには、次のようにします。

- 削除するHTTPヘッダーを選択します。

- 「削除」をクリックします。

4. 「OK」をクリックして変更を保存します。

HTTPヘッダーの属性モジュールを構成したら、Oracle Identity Federationを構成して、アサーションの作成時にこれらのセッション属性を使用して次のものに移入できます。

- アサーションのSubjectの名前識別子の値

- アサーションの属性。たとえば、「Accept-Language」および「orafed-cookie-userLanguageCookie」をアサーション属性として送信するには、それらを信頼できるサービス・プロバイダの「属性マッピングとフィルタ」セクションでリストします。

実行時のフローは次のようになります。

1. Oracle Identity Federationは、ユーザーの認証が必要かどうかを判断し、認証エンジンを呼び出してそのユーザーのチャレンジと識別を行います。

2. ユーザーは、資格証明または情報(たとえば、LDAP認証エンジンの資格証明処理URLにPOSTするユーザー名とパスワード)を提供するために、認証エンジンURLにデータを送信します。

3. ユーザー・データが検証されると、エンジンが内部的にユーザーをOracle Identity Federationに再転送します。

4. HTTPヘッダーの属性モジュールが、認証エンジンに送信されたHTTPリクエストを解析します(内部転送操作により、モジュールがリクエストにアクセスできます)。このモジュールは必要なHTTPヘッダーやCookieの値をこのリクエストから抽出します。

5. Oracle Identity Federationは抽出されたデータをセッション属性として保存します。

6. アサーションの作成時に、Oracle Identity Federation/IdPはセッション属性を使用して名前IDや属性の要素を移入します(このように構成されている場合)。

5.15.2 認証エンジン - Oracle Single Sign-On

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- ユーザーの一意ID属性 - Oracle Identity Federationがユーザーの識別に使用する属性です。

注意:

- 各ユーザーのこの属性の値は、ユーザー・データ・ストアの構成で一意ID属性に指定した属性と同じ値にする必要があります。たとえば、ここで構成される属性がmailで、ユーザー・データストアの構成時に一意ID属性として構成した属性がEmailAddressの場合、認証エンジン・バックエンドのmailの値は、ユーザー・データストアのEmailAddressと同じ値にする必要があります。

- ここで構成する属性の値は、すべてのユーザーで一意である必要があります。

- ログアウトURL - ログアウト時に表示されるOracle Single Sign-OnサーバーのURLです。

- ログアウト有効 - このボックスを選択すると、Oracle Identity Federationログアウト・フローの実行時に、Oracle Identity FederationによってユーザーがOracle SSOログアウトURLにリダイレクトされるように指定できます。
ログアウトURLは、次のようなOracle SSOログアウトURLにする必要があります。

http(s)://sso-host:sso-port/sso/logout

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.3 認証エンジン - Oracle Access Manager 11g

このタブは、Oracle Access Manager 11g認証エンジンを構成する際に使用します。

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- エージェント・タイプ: エージェントは、Webgate11g、Webgate10g、mod_ossoのいずれかである必要があります。

- ユーザーの一意IDヘッダー - Oracle Identity Federationがユーザーの識別に使用する属性です。mod_ossoエージェントの場合、ここはドロップダウン・リストが表示され、デフォルトではProxy Remote Userに設定されています。Webgate10gまたはWebgate11gの場合のデフォルトは、OAM_REMOTE_USERです。

注意:

- 各ユーザーのこの属性の値は、ユーザー・データ・ストアの一意ID属性に指定した属性と同じ値にする必要があります。たとえば、ここで構成される属性がmailで、ユーザー・データストアの一意ID属性として構成した属性がEmailAddressの場合、認証エンジン・バックエンドのmailの値は、ユーザー・データストアのEmailAddressと同じ値にする必要があります。

- ここで構成する属性の値は、すべてのユーザーで一意である必要があります。

- ログアウトURL - ログアウト時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。

http://oam_host:oam_port/oam/server/logout

注意:
SPとOAM11gエンジンとの統合が有効で、ログアウトの構成がされている場合、OAM11g認証エンジンでログアウトを構成する必要はありません。

- ログアウト有効 - このボックスを選択すると、Oracle Identity Federationログアウト・フローの実行時に、Oracle Identity FederationによってユーザーがOracle Access ManagerログアウトURLにリダイレクトされるように指定できます。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.4 認証エンジン - Oracle Access Manager 10g

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- ユーザーの一意IDヘッダー - Oracle Identity FederationでOracle Access Managerを認証エンジンとして使用する場合、WebGateはOracle HTTP Server/Oracle Identity Federationに統合され、Oracle Identity Federation URLを保護します。Oracle Identity Federation URLのポリシー・ドメインは、ユーザー識別子をHTTPヘッダーとして提供するように構成されます。
このフィールドでは、WebGateから提供されるユーザー識別子を含むHTTPヘッダーの名前を指定します。

- ログアウト有効 - このボックスを選択すると、このエンジンによるログアウトが有効になります。ログアウトを有効にする場合、次のフィールドが関連します。

- Cookieのクリア - 選択した場合、Oracle Access ManagerのCookieは、ユーザーがOracle Access Managerドメインからログアウトする際にOracle Identity Federationによってリセットされます。

- Cookieドメイン - Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインです。

- ログアウトURLへのリダイレクト - Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、このボックスを選択してURLを入力します。

- ログアウトURL - ログアウト時に表示されるURLです。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.5 認証エンジン - LDAPディレクトリ

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- 接続URL - ホスト名とポートで構成されるLDAPサーバーURLのスペース区切りリストです。

- バインドDN - Oracle Identity FederationサーバーがLDAPサーバーに接続するために使用するDNです。次に例を示します。
cn=fedid,dc=mycompany,dc=com

- パスワード - サーバーのパスワードです。

- パスワードの確認 - サーバーのパスワードです。

- 最大接続数 - Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。

- ユーザー資格証明ID属性 - Oracle Identity Federationがユーザーの認証に使用する属性です。
たとえば、ここで構成される属性がmailで、ユーザーのこの属性の値がalice@mycorp.comの場合、ユーザーはユーザー名alice@mycorp.comで認証される必要があります。

注意:
ここで構成する属性の値は、すべてのユーザーで一意である必要があります。

- ユーザーの一意ID属性 - Oracle Identity Federationがユーザーを識別する属性です。

注意:

- 各ユーザーのこの属性の値は、ユーザー・データ・ストアの一意ID属性に指定した属性と同じ値にする必要があります。たとえば、ここで構成される属性がmailで、ユーザー・データストアの一意ID属性として構成した属性がEmailAddressの場合、認証エンジン・バックエンドのmailの値は、ユーザー・データストアのEmailAddressと同じ値にする必要があります。

- ここで構成する属性の値は、すべてのユーザーで一意である必要があります。

- 個人オブジェクト・クラス - LDAPサーバーでユーザーを表すLDAPオブジェクト・クラス。様々なタイプのディレクトリ・サーバーの場合の個人オブジェクト・クラスの例を次に示します。

- Oracle Internet Directory:inetOrgPerson

- Sun Java System Directory Server:inetOrgPerson

- Microsoft Active Directory:user

- ベースDN - LDAPユーザー検索が実行されるノード。次に例を示します。
dc=us,dc=oracle,dc=com

- 接続待機タイムアウト - Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

LDAP認証エンジンの構成に関する詳細は、次を参照してください。

- 第6.4.1項「高可用性LDAPサーバーの構成」

- 第5.13.1.4項「冗長性ユーザー・データ・ストアの構成」では、LDAPサーバーの前面にロード・バランサを構成する方法について説明しています。

5.15.5.1 認証エンジンとしてのOracle Virtual Directoryの構成

Oracle Identity FederationはOracle Virtual Directoryと統合できます。Oracle Virtual DirectoryをLDAP認証エンジンとして使用する場合は、Oracle Virtual Directoryに接続されているすべてのディレクトリ構造に対して、ベースDN、個人オブジェクト・クラス、一意ユーザーIDおよびユーザーの説明属性の設定が有効になるようにしてください。

5.15.6 認証エンジン - データベース・セキュリティ

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- JDBC URL - データベースの接続URLです。

- JDBCドライバ - JDBCドライバ文字列を入力します。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.7 認証エンジン - データベース表

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられたリスト・ボックス)にこのエンジンが表示されます。

- JNDI名 - Oracle WebLogic Server管理コンソールで作成したデータ・ソースのJNDIです。

- ログイン表 - ログイン表の名前です。

- ログインID列 - ログイン表のログインID列の名前です。

- ユーザーの一意ID列 - ログイン表のユーザーID列の名前です。

- ログイン・パスワード列 - ログイン表のログイン・パスワード列の名前です。

- パスワード・ダイジェスト・アルゴリズム - ログイン表のパスワードに適用されるダイジェスト・アルゴリズムです。パスワードをクリアテキストでデータベースに格納する場合は、Noneを選択します。パスワードのMD5ハッシュ値またはSHA1ハッシュ値をデータベースに格納する場合は、MD5またはSHA1を選択します。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.7.1 RDBMS認証エンジンを使用するOracle Identity Federationの構成

Oracle Identity Federationでデータベースを認証エンジンとして使用するには、ログイン表と呼ばれる、ユーザーのログイン情報を格納する表をそのデータベースで使用する必要があります。ログイン表の各ユーザーは次の属性を持っている必要があります。

1. ログインID: ユーザーがログイン時に使用する一意のユーザー名です。

2. ログイン・パスワード: ユーザーがログイン時に使用するパスワードです。この列の値は、クリアテキスト・パスワード、パスワードのMD5ハッシュ値またはSHA1ハッシュ値にできます。

3. ユーザーID: Oracle Identity Federationがユーザーを識別する一意の識別子です。ユーザーIDの値は、ユーザー・データ・ストアのユーザーIDの値と一致する必要があります。

ログインID属性とユーザーID属性は2つの別々の列に格納できます。または、ログインIDをユーザーIDとして使用する場合は1つの列に格納することもできます。

例1

次のような「UserLoginInfo1」というログイン表があるとします。この表では、ログインIDは列「Email」に、ユーザーIDは列「UserID」に含まれます。

UserID

FirstName

LastName

Password

Email

alice

Alice

Smith

gu*L3nb

alice@mycorp.com

bob

Robert

Jones

aqweb80

bob@mycorp.com

charlie

Charles

Johnson

b23thag

charlie@mycorp.com

david

David

Jones

094bshyq=

david@mycorp.com

robert

Robert

Williams

#)haba*(+

williams@mycorp.com

例2

次のような「UserLoginInfo2」というログイン表があるとします。この表では、ログインIDとユーザーIDはともに「Username」列に含まれます。

Username

Password

FullName

alice

gu*L3nb

Alice Smith

bob

aqweb80

Robert Jones

charlie

b23thag

Charles Johnson

david

094bshyq=

David Jones

robert

#)haba*(+

Robert Williams

RDBMS認証エンジンを使用するようにOracle Identity Federationを構成するには、次の手順が必要です。

1. JDBCデータ・ソースを作成します。

2. Oracle Identity Federation認証エンジンを変更します。

JDBCデータ・ソースを作成します。

RDBMSユーザー・データ・ストアを構成するには、次の手順に従います。

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「JDBC」→「データ・ソース」の順に移動します。

3. 「新規」をクリックします。

4. 新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

Oracle Identity Federation認証エンジンの変更

RDBMS認証エンジンを構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」の順に移動します。

3. 「データベース表」タブで、「認証エンジンの有効化」を選択し、次のプロパティを追加します。

- JNDI名: WebLogic管理コンソールで作成したデータ・ソースのJNDIです。

- ログイン表: ログイン表の名前です。

- ログインID列: ログイン表のログインID列の名前です。

- ユーザーの一意ID属性: ログイン表のユーザーID列の名前です。

- ログイン・パスワード列: ログイン表のログイン・パスワード列の名前です。

- パスワード・ダイジェスト・アルゴリズム: ログイン表のパスワードに適用されるダイジェスト・アルゴリズムです。
パスワードをクリアテキストでデータベースに格納する場合は、Noneを選択します。パスワードのMD5ハッシュ値またはSHA1ハッシュ値をデータベースに格納する場合は、MD5またはSHA1を選択します。

4. 「適用」をクリックします。

例1の構成

前述の例1の表「UserLoginInfo1」に対応する構成は次のとおりです。このデータベースに作成されているデータ・ソースのJNDI名は「MyCorpUserDS」であるとします。

- JNDI名: MyCorpUserDS

- ログイン表: UserLoginInfo1

- ログインID列: Email

- ユーザーの一意ID属性: UserID

- ログイン・パスワード列: Password

- パスワード・ダイジェスト・アルゴリズム: None/MD5/SHA1

例2の構成

前述の例2の表「UserLoginInfo2」に対応する構成は次のとおりです。このデータベースに作成されているデータ・ソースのJNDI名は「MyCorpUserDS」であるとします。

- JNDI名: MyCorpUserDS

- ログイン表: UserLoginInfo2

- ログインID列: Username

- ユーザーの一意ID属性: Username

- ログイン・パスワード列: Password

- パスワード・ダイジェスト・アルゴリズム: None/MD5/SHA1

5.15.8 認証エンジン - 情報カード

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- アサーションのユーザーへのマップ - 選択した場合、着信アサーションは「サービス・プロバイダ」ページのSAML 2.0/SAML 1.xアサーションタブの構成に基づいてユーザー・レコードにマップされます。

- 情報カード・プロバイダごとに1つのエントリを表示 - 選択した場合、「フェデレーション」ページで構成した情報カード・プロバイダごとに情報カード選択オプションが表示されます。

- 認証メカニズムを含む - 選択した場合、Oracle Identity Federationは認証メカニズムを必要なクレームとして追加し、情報カード・プロバイダからの特定の認証方式をリクエストできます。

- 個人カード発行者にマップされた認証メカニズム - ここで構成した認証メカニズムによって情報カード認証エンジンが呼び出され認証が行われる場合、個人発行者カードがログイン・ページに表示されます。ここで構成した認証メカニズム以外で呼び出された場合は、すべての情報カード・プロバイダが表示されます。

関連項目:
第6.12項「情報カードの設定」

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.15.9 認証エンジン - フェデレーテッドSSOプロキシ

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

- 認証メカニズム - フェデレーテッドSSOプロキシを使用する場合に、Oracle Identity Federationがユーザーをロカールに認証するために使用する認証メカニズムです。

警告:

ここで指定した認証メカニズムを、フェデレーテッドSSOプロキシ認証エンジンにマップしないでください。

関連項目:
第5.15.9.1項「フェデレーテッドSSOプロキシ認証エンジンについて」

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

その他の内容は次のとおりです。

- フェデレーテッドSSOプロキシ認証エンジンについて

- 使用するアイデンティティ・プロバイダの選択

- フェデレーテッドSSOプロキシ認証エンジンの構成

5.15.9.1 フェデレーテッドSSOプロキシ認証エンジンについて

アイデンティティ・プロバイダがフェデレーテッドSSOプロキシ認証エンジンを使用してユーザーを認証する場合、このアイデンティティ・プロバイダは、認証を行うためにサービス・プロバイダの役割を果たし、ユーザーを認証する2つ目のアイデンティティ・プロバイダとシングル・サインオン・フローを開始します。

フローは次のようになります。

1. サービス・プロバイダ(SP-1)が、認証リクエストをOracle Identity Federationアイデンティティ・プロバイダ(IdP-1)に送信します。

2. Oracle Identity Federation/IdP-1は、フェデレーテッドSSOプロキシ認証エンジンを使用しているので、信頼できるアイデンティティ・プロバイダ(IdP-2)を選択して、サービス・プロバイダの役割を担い、指定のユーザーの新しい認証リクエストをIdP-2に送信します。

3. IdP-2がユーザーを認証します。

4. IdP-2は、アサーションをOracle Identity Federation/IdP-1に送り返し、Oracle Identity Federation/IdP-1は、このアサーションを処理します。

5. 必要に応じて(フェデレーションの作成処理を実行する必要がある場合など)、Oracle Identity Federation/IdP-1はユーザーをローカルに認証します。

6. Oracle Identity Federation/IdP-1が、新しいアサーションをSP-1に送り返します。

5.15.9.2 使用するアイデンティティ・プロバイダの選択

フェデレーテッドSSOプロキシ認証エンジンを使用するアイデンティティ・プロバイダは、サービス・プロバイダから認証リクエストを受信すると、新しいリクエストの送信先となる信頼できるアイデンティティ・プロバイダを選択します。アイデンティティ・プロバイダを選択するために、Oracle Identity Federationは、サービス・プロバイダからリクエストされた認証メカニズム(SPが認証メカニズムをリクエストしなかった場合はデフォルトのメカニズム)をアイデンティティ・プロバイダにマップし、このIdPに新しいリクエストを送信します。

このメカニズムがアイデンティティ・プロバイダにマップされていない場合は、Oracle Identity Federationによって構成内のデフォルト・アイデンティティ・プロバイダが使用されます。(認証メカニズムの詳細およびプロトコル固有の方式がローカル認証メカニズムにマップされる仕組みの詳細は、第5.14.1項「認証メカニズムについて」を参照してください)。

たとえば、ローカル認証メカニズムからアイデンティティ・プロバイダに対して次のようなマッピングが構成されているとします。

oracle:fed:authentication:internet-protocol -> http://corp-1.com/idp
oracle:fed:authentication:password-protected -> http://corp-2.com/idp

また、デフォルト・アイデンティティ・プロバイダはhttp://corp-3.com/idpであるとします。

このとき、サービス・プロバイダがoracle:fed:authentication:internet-protocolにマップされている認証方式をリクエストすると、Oracle Identity Federationはhttp://corp-1.com/idpをアイデンティティ・プロバイダとして選択します。ただし、サービス・プロバイダがoracle:fed:authentication:password-protectedをリクエストすると、Oracle Identity Federationはhttp://corp-2.com/idpを選択します。サービス・プロバイダが認証方式をリクエストしない場合、Oracle Identity Federationは新しい認証リクエストをhttp://corp-3.com/idpに送信します。

ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピングを定義するには、次の手順に従います。

関連項目:
第5.5項「サービス・プロバイダの構成」

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ」の順に移動します。

3. 「プロトコル設定」で、「アイデンティティ・プロバイダ・マッピングに対するSSO認証メカニズム」をクリックします。

4. 「追加」をクリックして、認証メカニズムとマップ先のアイデンティティ・プロバイダを選択します。

5. マッピングの追加が完了したら、「OK」をクリックします。次に、「適用」をクリックします。

デフォルト・アイデンティティ・プロバイダを構成するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ」の順に移動します。

3. 「デフォルトSSOアイデンティティ・プロバイダ」を選択して、「適用」をクリックします。

5.15.9.3 フェデレーテッドSSOプロキシ認証エンジンの構成

フェデレーテッドSSOプロキシ認証エンジンを正しく使用するには、認証メカニズムを構成する必要があります。たとえば、次のようなことがあります。

1. デフォルト認証メカニズムの設定

2. プロトコル固有の方式からローカル・メカニズムへのマッピングおよびローカル・メカニズムから認証エンジンのマッピング

3. ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピング

認証メカニズムの構成に加えて、フェデレーテッドSSOプロキシ認証エンジン自体も構成する必要があります。これを実行するには、次の手順に従います。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」の順に移動します。

3. 「フェデレーテッドSSOプロキシ」タブで、「認証エンジンの有効化」を選択し、必要に応じてユーザーのローカル認証に使用する認証メカニズムを選択します。

警告:

ユーザーのローカル認証に使用するローカル認証メカニズムを、フェデレーテッドSSOプロキシ認証エンジンにマップしないでください。そうした場合、IdP-1からIdP-2にリクエストが連続的に送信されるため、ループが発生します。(IdP-1はIdP-2にリクエストを送信し、アサーションを受信します。IdP-1はユーザーをローカルに認証する必要があるため、メカニズムをフェデレーテッドSSOプロキシ認証エンジンにマップします。これにより、IdP-1はIdP-2に新しいリクエストを送信するよう求められます)。

認証メカニズムの詳細および認証メカニズムを認証エンジンにマップする方法の詳細は、第5.14.1項「認証メカニズムについて」を参照してください。

5.15.10 認証エンジン - JAAS

JAAS認証エンジンはOracle Identity Federationサーバーのデフォルト認証エンジンです。

このエンジンを有効または無効にするには、「認証エンジンの有効化」チェック・ボックスを使用します。

JAASはデフォルト・エンジンであるため、このボックスはデフォルトで選択されています。JAAS認証エンジンを無効にする場合、別のエンジンがデフォルト・エンジンとして機能するようにする必要があります。必要に応じて、先に別の認証エンジンを設定してからこのタブに戻り、JAASエンジンを無効にします。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

注意:
JAAS認証エンジンはログアウトをサポートしていません。つまり、このエンジンを使用するプロバイダを構成して、IdPとSPの間でシングル・サインオンを実行し、Oracle Identity FederationのログアウトURL http://host:port/fed/user/logoutを発行すると、ユーザーはログアウトされないので、再度ログインせずにSSOフローを実行できます。

ユーザーの作成およびoifusersグループへの追加

JAAS認証エンジンで認証を受けるユーザーは、Oracle Identity FederationがデプロイされているWLSドメインのセキュリティ・レルムに対応するユーザー・エントリが存在している必要があります。また、oifusersグループに含まれている必要があります。

oifusersグループを作成して新しいユーザーを追加するには、次の手順に従います。

関連項目:
Oracle Fusion Middlewareの管理の概要

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のペインで、「セキュリティ・レルム」を選択し、「myrealm」→「ユーザーとグループ」→「グループ」の順に移動します。

3. 「新規」をクリックして、名前にoifusersと入力します。

4. 「ユーザーとグループ」→「ユーザー」の順に移動します。

5. 「新規」をクリックして、名前とパスワードを選択します。

6. 作成したユーザーをクリックして、「グループ」タブを選択します。

7. グループoifusersを選択して「選択済み」列に移動します。「保存」をクリックします。

さらにユーザーを入力するには、ステップ4から7までを繰り返します。グループとユーザーを作成したら、管理サーバーおよびOracle Identity Federationが実行されている管理対象サーバーを再起動して、変更を有効にする必要があります。

5.15.11 認証エンジン - カスタム

このタブでは、カスタム認証エンジンを設定できます。

カスタム・エンジンの表示

カスタム・エンジンの表を並べ替えるには、「表示」ボタンを使用します。列の表示順序を変更して、含めるまたは除外するフィールドを指定できます。「列の並替え」ダイアログでは、任意のフィールドを選択し、矢印を使用してそのフィールドを表に再配置できます。

エンジンの追加

「追加」をクリックして、新しいカスタム・エンジンを追加します。一意のエンジン名を入力するよう求められ、エンジンIDが自動的に生成されます。エンジンを追加した後で、次の情報を追加できます。

- 有効 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。

- Webコンテキスト - カスタム認証エンジンをデプロイするWebアプリケーション・コンテキストを指定します。

- 認証相対パス - カスタム認証エンジンに対する、Webコンテキストからの相対パスを指定します。

- ログアウト相対パス - カスタム認証エンジンのログアウト・サービス(使用する場合)に対する、Webコンテキストからの相対パスを指定します。たとえば、「/auth_engines/myAuthLogout.jsp」などです。

関連項目:
第10.3項「カスタム認証エンジンの作成」

このタブには次のフィールドがあります。

- デフォルトの認証エンジン - 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- 認証エンジンの有効化 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.16 SP統合モジュールの構成

このページは、Oracle Identity FederationのSP統合モジュールを構成する場合に使用します。

このページは、それぞれのSP統合モジュール用のタブで構成されています。タブで行った更新は、他のタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

- SP統合モジュール - Oracle Single Sign-On

- SP統合モジュール - Oracle Access Manager 11g

- SP統合モジュール - Oracle Access Manager 10g

- SP統合モジュール - テストSPエンジン

- SP統合モジュール - カスタム

5.16.1 SP統合モジュール - Oracle Single Sign-On

このタブは、Oracle Single Sign-On用のSP統合を構成する場合に使用します。

このタブには次のフィールドがあります。

- デフォルトSP統合モジュール - サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- SPモジュールの有効化 - このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。

- 認証メカニズム - フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。

- ユーザー名属性 - Oracle Identity FederationからOracle SSOに渡す必要のあるユーザー名属性です。デフォルトはuidです。

- ログインURL - ログイン時に表示されるOracle Single Sign-OnサーバーのURLです。次に例を示します。

http://sso_host:sso_port/sso/auth

- ログアウトURL - ログアウト時に表示されるOracle Single Sign-OnサーバーのURLです。次に例を示します。

http://sso_host:sso_port/sso/logout

- ログアウト有効 - Oracle Single Sign-Onアプリケーションでのログアウトを有効/無効にします。

「再生成」ボタンをクリックすると暗号化鍵が作成されます。この暗号化鍵はファイルに保存され、Oracle SSOサーバーに渡されます。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.16.2 SP統合モジュール - Oracle Access Manager 11g

このタブは、Oracle Access Manager 11g用のSP統合を構成する場合に使用します。

注意:
リリース11.1.1.7.0では、このページからOAM 11gの秘密鍵を再生成する前に追加の手順が必要です。詳細は、リリース・ノートを参照してください。

このタブには次のフィールドがあります。

- デフォルトSP統合モジュール - サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- SPモジュールの有効化 - このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。

- 認証メカニズム - フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。

- ユーザー名属性 - Oracle Identity FederationからOracle Access Managerに渡す必要のあるユーザー名属性です。デフォルトはcnです。

- ログインURL - ログイン時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。

http://oam_host:oam_port/oam/server/dap/cred_submit

- ログアウトURL - ログアウト時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。

http://oam_host:oam_port/oam/server/logout

- ログアウト有効 - Oracle Access Managerでのログアウトを有効/無効にします。

「再生成」ボタンをクリックするとキーストア・ファイルが生成されます。このファイルには、Oracle Access ManagerとOracle Identity Federationサーバーの間で交換されるトークンの暗号化および復号化に使用される鍵が含まれています。

注意:
リリース11.1.1.7.0では、このページからOAM 11gの秘密鍵を再生成する前に追加の手順が必要です。詳細は、リリース・ノートを参照してください。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.16.3 SP統合モジュール - Oracle Access Manager 10g

このタブは、Oracle Access Manager用のSP統合を構成する場合に使用します。

関連項目:
Oracle Access ManagerをSP統合エンジンとして構成する場合の詳細は、第3.2.4.3項「SP統合モジュールとしてのOracle Access Managerの統合」を参照してください。

このタブには次のフィールドがあります。

- デフォルトSP統合モジュール - サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- SPモジュールの有効化 - このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。

- 認証メカニズム - フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。

- サーバーSDKディレクトリへのアクセス - アクセス・サーバーSDKのディレクトリの場所です。DOMAIN_HOMEへの絶対パスまたは相対パスです。

- デフォルトの認証スキーム - Oracle Identity Federationで作成されたポリシーのデフォルト・スキームとして使用されるOracle Access Managerの認証スキームです。

- Cookieドメイン - Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインです。

- 永続Cookieの場合は、Cookieの有効期間です(単位は分)。セッションCookieの場合は0を入力します。

- Cookieセキュア・フラグ設定済: Cookieの安全性を示す必要があるかどうかをチェックします。示す必要がある場合、ブラウザはCookieをHTTPS接続経由で送信します。

- ログアウト有効 - Oracle Access Managerアプリケーションでのログアウトを有効/無効にします。

- Cookieのクリア - 選択した場合、Oracle Access ManagerのCookieは、ユーザーがOracle Access Managerドメインからログアウトする際にOracle Identity Federationによってリセットされます。

- ログアウトURLへのリダイレクト - Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択してURLを入力します。

注意:
ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。
Oracle Access ManagerのログアウトURLに追加される問合せパラメータは、returnurlで参照します。

このタブには、Oracle Access ManagerとOracle Identity Federationの統合に必要な次のフィールドがあります。

- ポリシー・ドメインの構成に必要なOracle Access Manager資格証明

- サーバー自身の認証をOracle Identity Federationで可能にするためのOracle Identity Federationアカウント情報

これらの機能の詳細は、第3.2.4.3項「SP統合モジュールとしてのOracle Access Managerの統合」および第3.2.5項「Oracle Access Managerに対するOracle Identity Federation/SPの認証」.

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.16.4 SP統合モジュール - テストSPエンジン

このタブは、テストSPエンジン用のSP統合を構成する場合に使用します。

このタブには次のフィールドがあります。

- デフォルトSP統合モジュール - サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- SPモジュールの有効化 - このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。

- 認証メカニズム - フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

5.16.5 SP統合モジュール - カスタム

このタブは、カスタムSPエンジン用のSP統合を構成する場合に使用します。

このタブには次のフィールドがあります。

- デフォルトSP統合モジュール - サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。

- SPモジュールの有効化 - このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。

SP統合モジュールの表示

SP統合モジュールの表を並べ替えるには、「表示」ボタンを使用します。列の表示順序を変更して、含めるまたは除外するフィールドを指定できます。「列の並替え」ダイアログでは、任意のフィールドを選択し、矢印を使用してそのフィールドを表に再配置できます。

エンジンの追加

「追加」ボタンをクリックして、新しいカスタム・エンジンを追加します。一意のエンジン名を入力するよう求められ、エンジンIDが自動的に生成されます。エンジンを追加した後で、次の情報を追加できます。

- 有効 - このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。

- 認証メカニズム - アサーションの処理時にローカル認証を行う必要がある場合に使用する認証メカニズムです。

- Webコンテキスト - SP統合エンジンのcontextPathを「Webコンテキスト」フィールドに指定します。たとえば、/engineなどです。

- 認証相対パス - SP統合エンジンのログイン・サービスの相対パスを「ログイン相対パス」フィールドに指定します。たとえば、/application.jspです。

- ログアウト相対パス - SP統合エンジンのログアウト・サービスの相対パスを「ログアウト相対パス」フィールドに指定します。

関連項目:
第10.4項「カスタムSP統合エンジンの作成」

このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。

6 その他のサーバー構成

この章では、Oracle Identity Federationサーバーの構成と管理に関するその他のトピックについて説明します。内容は次のとおりです。

- シングル・サインオン・サービスの設定

- アフィリエーション関連の作業

- 追加のLDAP構成

- 高可用性のための追加構成

- 追加のRDBMS構成

- セッション・リポジトリの構成

- 追加のHTTP構成

- 追加のプロトコル構成

- SOAPエンドポイントの保護

- SAML 2.0 IdP検出(共通ドメインCookie)プロファイルの構成

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

- 情報カードの設定

- 追加のランタイム構成

- 追加のフェデレーション・データ・ストア構成

- Oracle Identity Federation 10gおよびShareIDサービスURLに対する下位互換性の設定

- SPモードでの属性および名前IDによるユーザーのマッピング

- 属性問合せマッピングに基づいた自動アカウント・リンク

- シングル・サインオンでのユーザー・オプトインおよびオプトアウト

- アサーション処理時のユーザー・マッピングのバイパス

- 名前IDマッピングのパートナ単位での上書き

- アサーションのオーディエンス制限の構成

- 証明書パス検証

- 認証リクエストを使用したACS URLの送信

- OpenIDパートナとの統合

- OpenID UI Extensionの実装

6.1 シングル・サインオン・サービスの設定

使用中のバックエンドとフローが初期化される場所に応じて、フェデレーテッド・シングル・サインオン(SSO)処理の実行にはいくつかの方法があります。表6-1に、可能な組合せを示します。

表6-1 フェデレーテッド・シングル・サインオンの組合せ

組合せ

フロー

Oracle Single Sign-On

ユーザーがmod_ossoによって保護されたリソースにアクセスすると、シングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。

Oracle Access Manager

ユーザーがWebGateによって保護されたリソースにアクセスすると、シングル・サインオンがトリガーされ、Oracle Identity FederationはSPとして動作します。

SPが開始するシングル・サインオン

ユーザーが直接Oracle Identity Federation URLにアクセスすることでシングル・サインオンを開始し、Oracle Identity FederationはSPとして動作します。

IdPが開始するシングル・サインオン

ユーザーが直接Oracle Identity Federation URLにアクセスすることでシングル・サインオンを開始し、Oracle Identity FederationはIdPとして動作します。

この項では、様々な組合せの構成方法を説明します。

- Oracle Single Sign-On

- Oracle Access Manager

- SPが開始するSSO

- IdPが開始するSSO

6.1.1 Oracle Single Sign-On

Oracle Single Sign-Onは、mod_ossoによって保護されたリソースをリクエストする場合に、SSO処理をトリガーするように構成できます。

そうするには、Oracle Single Sign-Onパートナ・アプリケーションが定義され、mod_ossoによって保護される必要があります。また、パートナ・アプリケーションがSASSO認証プラグインに関連付けられたSSOセキュリティ・レベルを使用するように構成される必要があります。それには、Oracle Single Sign-OnデプロイメントのORACLE_HOME/sso/conf/policy.propertiesファイルを編集し、パートナ・アプリケーション(ホスト名とポートで定義)を、SASSOAuthLevelと同一のセキュリティ・レベルに設定します。

次に例を示します。

MediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuth
MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth
...
www.app.com\:7890 = MediumHighSecurity
...
SASSOAuthnUrl= http\://oif-hostname\:oif-port/fed/user/sposso
SASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/spsloosso
SASSOAuthLevel = MediumHighSecurity

ファイルを保存し、Oracle Single Sign-Onサーバーを再起動して変更を適用します。

次にユーザーが保護されたリソースへの未認証アクセスを試みると、そのユーザーはOracle Identity Federationにリダイレクトされ、そこでSSO処理が行われます。

URL問合せパラメータ

保護されたリソースをリクエストする場合、Oracle Identity FederationがSSO処理を実行するために使用するURL問合せパラメータを指定できます。パラメータは次のとおりです。

- providerid - SSO処理を実行するために使用するアイデンティティ・プロバイダの識別子です(オプション)。指定されていない場合、Fusion Middleware Controlの「サービス・プロバイダ」→「共通」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。

そうしたURLの例を次に示します。

http://protected_app:port/path?providerid=http%3A%2F%2Fidp.com

URL問合せパラメータ値が正しくURLエンコードされていることを確認します。

関連項目:
第6.2項「アフィリエーション関連の作業」

SSO構成の詳細は、Oracle Single Sign-Onのドキュメントを参照してください。

6.1.2 Oracle Access Manager

Oracle Access Manager WebGateエージェントによって保護されているリソースをユーザーがリクエストした場合にSSO処理が開始されるようにOracle Accessポリシーを構成できます。

それには、Oracle Access Policy Managerを使用して、ポリシー・ドメイン、またはリソースを保護するポリシーを構成します。ポリシー・ドメインまたはポリシー用に認証ルールを作成する場合は、Fed SSO認証スキームを選択します。Oracle Accessを使用するように構成する場合、Oracle Identity Federationは自動的にこの認証スキームを作成します。リソースがアクセスされるとスキームによりシングル・サインオン処理が開始され、結果としてフェデレーテッド・ユーザーに関連付けられたローカル・ユーザーのためのセッションが作成されます。ポリシー・ドメインまたはポリシーのための認可ルールと式を設定して、結果的に作成されたローカル・ユーザーにアクセスを割り当てます。

URL問合せパラメータ

保護されたリソースをリクエストする場合、Oracle Identity FederationがSSO処理を実行するために使用するURL問合せパラメータを指定できます。パラメータは次のとおりです。

- providerid - SSO処理を実行するために使用するアイデンティティ・プロバイダの識別子です(オプション)。指定されていない場合、Fusion Middleware Controlの「サービス・プロバイダ」→「共通」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。

関連項目:
第6.2項「アフィリエーション関連の作業」

そうしたURLの例を次に示します。

http://protected_app:port/path?providerid=http%3A%2F%2Fidp.com

URL問合せパラメータ値が正しくURLエンコードされていることを確認します。

SSO構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

6.1.3 SPが開始するSSO

Oracle Identity Federationサーバーがサービス・プロバイダとして動作する場合、ユーザーは、Oracle Identity Federation /SPインスタンスで直接サービスをリクエストすることによって、SSO処理を開始することができます。

Oracle Identity FederationでリクエストされるURLは次のとおりです。

http(s)://OIF_host:OIF_port/fed/sp/initiatesso

URL問合せパラメータ

そのURLをリクエストする場合、URL問合せパラメータを指定できます。

- providerid - SSO処理を実行するために使用するアイデンティティ・プロバイダの識別子です(オプション)。指定されていない場合、Fusion Middleware Controlの「サービス・プロバイダ」→「共通」→「デフォルトSSOアイデンティティ・プロバイダ」で構成されたデフォルトのSSOプロバイダが使用されます。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。

関連項目:
第6.2項「アフィリエーション関連の作業」

- returnurl - SSO処理が成功した場合にユーザーが送られるURLです。Fusion Middleware Controlの「フェデレーション」→「サービス・プロバイダ」(共通)で設定された「非送信請求SSOリレー状態」プロパティが空の場合は必須です。

そうしたURLの例を次に示します。

http://oif_host:oif_port/fed/sp/initiatesso?providerid=http%3A%2F%2Fidp.com&returnurl=http%3A%2F%FProtectedAppHost%2FProtectedAppPath

問合せパラメータ値が正しくURLエンコードされていることを確認します。

6.1.4 IdPが開始するSSO

Oracle Identity Federationには、IdPとして動作するOracle Identity FederationインスタンスでURLを直接リクエストすることによってSSO処理を開始する機能が用意されています。

URLフォーマット

Oracle Identity FederationでリクエストされるURLは次のような形式になります。

http(s)://oif_host:oif_port/fed/idp/initiatesso

URL問合せパラメータ

そのURLをリクエストする場合、URL問合せパラメータを指定できます。

- providerid - SSO処理を実行するために使用するサービス・プロバイダの識別子です(オプション)。

- federationid - SSOで使用するアフィリエーションの識別子です(オプション)。

関連項目:
第6.2項「アフィリエーション関連の作業」

- returnurl - SSO処理が成功した場合にユーザーが送られるURLです(オプション)。

- acsurl - アサーション・コンシューマ・サービスURLです。この値にはAssertion Consumer Service URLの値でエンコードされたURLを含める必要があります。
OIF/IdPは、指定されたURLをSPメタデータにリストされているAssertion Consumer Service URLと比較します。メタデータ内のACS URLのいずれかと一致する必要があります。

問合せパラメータ値が正しくURLエンコードされていることを確認します。

そうしたURLの例を次に示します。

http://oif_host:oif_port/fed/idp/initiatesso?providerid=http%3A%2F%2Fsp.com&returnurl=http%3A%2F%FProtectedAppHost%2FProtectedAppPath

6.2 アフィリエーション関連の作業

アフィリエーションの実行時動作は、Oracle Identity FederationサーバーがIdPとSPのいずれとして動作しているかにより異なります。

Oracle Identity FederationがIdPとして動作している場合

Oracle Identity FederationがIdPの場合、アフィリエーション/SPがトラスト・サークルに存在し、有効であれば、Oracle Identity Federationサーバーは、アフィリエーションを使用するサービス・プロバイダが送信するあらゆるリクエストを処理する準備ができています。

Oracle Identity FederationがSPとして動作している場合

SPとして、SPが所属するアフィリエーションを使用して、IdPへのシングル・サインオン処理をトリガーできます。そのための手順は、IdMバックエンドが保護しているURLにfederationid問合せパラメータを含め、そのアフィリエーションIDにパラメータ値を設定します。

Oracle Single Sign-Onバックエンドを例にとって、リソースがmod_ossoによって保護され、Oracle Identity Federation認証用として構成されていると仮定します。このとき、federationid問合せパラメータを使用してこのリソースのURLをリクエストすると、Oracle Identity Federationは、ピアIdPに対してシングル・サインオンを実行する際にアフィリエーションを使用します。そのようなURLの例を次に示します。

http://protected_res_host:protected_res_port/path?federationid=http%3A%2F%Faffiliationid

同一のfederationid問合せパラメータを使用して、直接http://oif_host:oif_port/fed/sp/initiatesso URLにアクセスすることも可能です。この場合、Oracle Identity Federationはシングル・サインオン処理をトリガーし、ピアIdPの「非送信請求SSOリレー状態」を、ユーザーが認証成功後にリダイレクトされるURLとして使用します。

注意:
「非送信請求SSOリレー状態」は、Fusion Middleware Controlの「フェデレーション」→「信頼できるプロバイダの編集」で設定します。

6.3 追加のLDAP構成

この項では、LDAPの構成およびメンテナンスについて説明します。内容は次のとおりです。

- LDAP非アクティブ設定の構成

- LDAP読取りタイムアウト設定の構成

- LDAP接続に対するECIDサポート

6.3.1 LDAP非アクティブ設定の構成

Oracle Identity Federationがユーザー・データ・ストア、フェデレーション・データ・ストアまたは認証エンジンとして動作するように高可用性LDAPサーバーと統合されている場合、サーバーは後続のリクエストで再利用可能なLDAP接続のプールを保持します。

長期的には、非アクティブの状態が長く続いたためにLDAPサーバーが接続をクローズすることがあります。チェックしないままだと、これがエラーの原因となり、Oracle Identity Federationのパフォーマンスが低下する可能性があります。

非アクティブ属性を設定することにより、LDAP接続がアクティブでないために削除されるまでプールに保持しておく期間をOracle Identity Federationに指示できます。デフォルトでは、非アクティブ・タイムアウトは300秒に設定されています。

Oracle Identity Federationの非アクティブ設定を設定するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- 次の例に示すように、authnenginesグループのldapconnectioninactivitytimeout longプロパティに非アクティブ・タイムアウトを秒単位で設定し、LDAP認証エンジンの非アクティブ・タイムアウトを構成します。

setConfigProperty('authnengines', 'ldapconnectioninactivitytimeout', '300', 'long')

- 次の例に示すように、datastoreグループのuserldapconnectioninactivitytimeout longプロパティに非アクティブ・タイムアウトを秒単位で設定し、LDAPユーザー・データ・ストアの非アクティブ・タイムアウトを構成します。

setConfigProperty('datastore',
'userldapconnectioninactivitytimeout', '300', 'long')

- 次の例に示すように、datastoreグループのfedldapconnectioninactivitytimeout longプロパティに非アクティブ・タイムアウトを秒単位で設定し、LDAPフェデレーション・データ・ストアの非アクティブ・タイムアウトを構成します。

setConfigProperty('datastore','fedldapconnectioninactivitytimeout', '300', 'long')

6.3.2 LDAP読取りタイムアウト設定の構成

Oracle Identity Federationがユーザー・データ・ストア、フェデレーション・データ・ストアまたは認証エンジンとしてLDAPサーバーと統合されている場合、サーバーはユーザー属性の取得、ユーザーの認証、ユーザーの検索および関連処理の実行のためにLDAPディレクトリと通信します。

LDAPサーバーは応答しなくなることがありますが、その場合、スレッド/ユーザーはレスポンスまたはエラーを待つことになります。サーバーが応答していないときにエラーを長時間待つことがないよう、Oracle Identity FederationでLDAP接続に対する読取りタイムアウト・プロパティを設定します。読取りタイムアウトの時間内にLDAPサーバーが応答しない場合はエラーが生成され、Oracle Identity Federationは接続をクローズし、新しい接続をオープンして、LDAPコマンドを再発行します。

読取りタイムアウト設定を設定することにより、LDAPサーバーからのデータの待機時間をOracle Identity Federationサーバーに指示できます。デフォルトでは、読取りタイムアウトは10秒に設定されています。

Oracle Identity Federationの読取りタイムアウト設定を設定するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、必要に応じて次のプロパティを例に示すように設定します。

- authnenginesグループのldapconnectionreadtimeout longプロパティに読取りタイムアウトを秒単位で設定して、LDAP認証エンジンの読取りタイムアウトを構成します。

setConfigProperty('authnengines', 'ldapconnectionreadtimeout', 'long','10')

- datastoreグループのuserldapconnectionreadtimeout longプロパティに読取りタイムアウトを秒単位で設定して、LDAPユーザー・データ・ストアの読取りタイムアウトを構成します。

setConfigProperty('datastore',
'userldapconnectionreadtimeout', 'long', '10')

- datastoreグループのfedldapconnectionreadtimeout longプロパティに読取りタイムアウトを秒単位で設定して、LDAPフェデレーション・データ・ストアの読取りタイムアウトを構成します。

setConfigProperty('datastore', 'fedldapconnectionreadtimeout', 'long', '10')

6.3.3 LDAP接続に対するECIDサポート

Oracle Identity Federation 11gは、DMSおよび監査プロセスに対する実行コンテキストID(ECID)をサポートしています。

Oracle Identity Federationでは、Oracle Internet DirectoryとのLDAP接続を作成する場合に、OID LDAP接続に対してECIDコンテキストを渡すことができます。

この機能は、デフォルトで無効になっています。この機能を有効(無効)にするには、次のプロパティをtrue(false)に設定します。

- LDAP認証エンジンのconfigにあるauthnenginesグループのldapuseecidブール型プロパティを設定します。

- LDAPユーザー・ストアのconfigにあるauthnenginesグループのuserldapuseecidブール型プロパティを設定します。

- LDAPフェデレーション・データ・ストアのconfigにあるauthnenginesグループのfedldapuseecidbooleanプロパティを設定します。

注意:
LDAPサーバー(ECIDサポートが有効になっている)は、Oracle Internet Directory 11gリリース1(11.1.1)以降にする必要があります。

6.4 高可用性のための追加構成

この項では、高可用構成に関するその他のトピックについて説明します。内容は次のとおりです。

- 高可用性LDAPサーバーの構成

- Configuring the HTTPセッション状態のスリープ/Retry Interval

- SSLモードでのOracle Identity Federation HAの構成

6.4.1 高可用性LDAPサーバーの構成

デフォルトでは、Oracle Identity Federationは、高可用性LDAPサーバーと統合されるようには構成されていません。Oracle Identity FederationをHA LDAPサーバーと統合して、ユーザー・データ・ストア、フェデレーション・データ・ストア、または認証エンジンとして動作させるには、LDAPサーバーの機能に基づいてOracle Identity Federationを構成する必要があります。

Oracle Identity FederationのWLSTスクリプト環境を入力してから、必要に応じて次のプロパティを設定します。

- ユーザー・データ・ストアをHA LDAPサーバーと統合するには、datastoreグループのuserldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('datastore','userldaphaenabled', 'true', 'boolean')

- フェデレーション・データ・ストアをHA LDAPサーバーと統合するには、datastoreグループのfedldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('datastore', 'fedldaphaenabled',
'true', 'boolean')

- LDAP認証エンジンをHA LDAPサーバーと統合するには、authnenginesグループのldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('authnengines','ldaphaenabled', 'true', 'boolean')

6.4.2 HTTPセッション状態のスリープ/再試行間隔の構成

Oracle Identity FederationをHAモードでクラスタにデプロイする場合、Oracle Identity Federationが実行されているOracle WebLogicサーバー全体にユーザーHTTPセッション状態がレプリケートされるよう構成できます。

デフォルトでは、Oracle Identity FederationのHTTPセッション状態レプリケーションは無効になっています。これを有効にするには、『Oracle Fusion Middleware高可用性ガイド』のクラスタ全体の構成の変更に関する項を参照してください。

この項の以降では、HTTPセッション状態レプリケーションを有効にした場合のOracle Identity Federationのその他の構成について説明します。

注意:
パフォーマンス上の理由により、HTTPセッション状態レプリケーションは無効にすることをお薦めします。

この追加構成を行うことにより、フェデレーション・リクエストの処理時に、エラーが生じることなく、個々のOracle Identity Federationサーバーにユーザーがアクセスできるようになります。

サーバー・インスタンス間でのHTTPセッション状態のレプリケート速度が不十分な場合など、状態がまだコピーされていないOracle Identity Federationインスタンスのサービスにユーザーがアクセスすると、エラーが発生することがあります。

この問題を回避するには、次の2つのオプションのいずれかを選択します。

- ロード・バランサでスティッキー・セッションを有効にし、特定のユーザーがHTTPリクエストを送信する際には必ず同じOracle WebLogic Server管理対象サーバーにアクセスするよう強制します。
または

- Oracle Identity Federationの追加の構成プロパティを設定して、HTTPセッション状態のレプリケートがまだ完了していないことをサーバーが検出した場合に、情報がコピーされるまでそのサーバーが待機するようにします。この機能を有効にして、待機時間を構成します。

注意:
パフォーマンス上の理由により、スティッキー・セッションは無効にすることをお薦めします。

Oracle Identity FederationのユーザーHTTPセッション状態レプリケーションの設定を有効にして待機時間を設定するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- Oracle Identity Federationがセッション状態のレプリケートを待機するよう構成するには、serverconfigグループのsessionreplicationenabledブール型プロパティをtrueに設定します。待機しない場合は、falseに設定します。

setConfigProperty('serverconfig','sessionreplicationenabled', 'true', 'boolean')

- serverconfigグループのsessionreplicationtimeout longプロパティに待機時間をミリ秒単位で設定します。次に例を示します。

setConfigProperty('serverconfig', 'sessionreplicationtimeout', '2000', 'long')

6.4.3 SSLモードでのOracle Identity Federation HAの構成

相互にミラー化されている2つ以上のOracle Identity Federationサーバーがあり、フロントエンドにロード・バランサがある高可用性環境でSSLを設定する場合、次の2つの方法があります。

- SSL接続がユーザーとロード・バランサの間をつなぐように、ロード・バランサでSSLを構成します。この場合、ロード・バランサによって使用されるキーストアおよび証明書には、ロード・バランサのアドレスを参照するCNが含まれます。
ロード・バランサとWLS/Oracle Identity Federation間の通信では、SSLの使用は任意です(SSLを使用する場合、Oracle WebLogic Serverでは、キーストアおよび証明書がロード・バランサによって信頼されているかぎり、どのキーストアや証明書でも使用できます)。

- ユーザーとOracle Identity Federationサーバー間でSSL接続が行われるように、Oracle Identity FederationサーバーでSSLを構成します。この場合、ユーザーがロード・バランサのホスト名を使用して接続するため、Oracle WebLogic Server/Oracle Identity Federationのキーストアおよび証明書のCNはロード・バランサのアドレスを参照する必要があり、証明書CNがロード・バランサのアドレスと一致している必要があります。
つまり、ユーザーに接続されるSSLエンドポイント(ロード・バランサまたはOracle WebLogic Server/Oracle Identity Federation)のキーストアおよび証明書には、ロード・バランサのホスト名に設定されたCNが含まれる必要があります。ユーザーは、そのアドレスを使用してOracle Identity Federationに接続するためです。

6.5 追加のRDBMS構成

この項では、Oracle Identity FederationのRDBMS構成に関するその他のトピックについて説明します。内容は次のとおりです。

- RDBMSセッション・キャッシュの構成

- RDBMSデータ圧縮の構成

6.5.1 RDBMSセッション・キャッシュの構成

Oracle Identity FederationでRDBMSを使用してユーザー・セッション・オブジェクトを格納する場合、サーバーはキャッシュ・メカニズムを使用して、実行時のパフォーマンスを向上させます。つまり、サーバーは最近使用されたセッション・オブジェクトへの参照をメモリー内に保持し、データベースへの読取りアクセスを回避します。

注意:
ユーザーのセッションはSSO処理の実行時に何度もアクセスされるため、これは重要な機能です。

キャッシュ内のセッション・エントリの最大数、およびキャッシュ内のセッションがクリアされるまでの最大時間を構成できます。デフォルトでは、Oracle Identity Federationサーバーにキャッシュされるセッション・エントリの最大数は25,000、最大時間は300秒です。

最適なタイムアウトを設定することは、特にクラスタ・モードで次のように設定されている場合は、別のOracle Identity Federationサーバーによってセッションが破棄される可能性があるため重要です。

- スティッキー・セッションを使用せずにロード・バランサを使用している

- SOAPログアウトが有効になっている

Oracle Identity Federationの最大エントリ数とタイムアウトを設定するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次の例に示すプロパティを設定します。

- datastoreグループのtransientrdbmssessioncachesize longプロパティに最大エントリ数を設定します。

setConfigProperty('datastore', 'transientrdbmssessioncachesize', '25000', 'long')

- datastoreグループのtransientrdbmssessioncachetimeout longプロパティにキャッシュ・タイムアウトを秒単位で設定します。

setConfigProperty('datastore', 'transientrdbmssessioncachetimeout', '300', 'long')

6.5.2 RDBMSデータ圧縮の構成

RDBMSに格納されるデータの量を減らすために、Oracle Identity Federationはデータを圧縮してからデータベースに格納する機能を備えています。

Oracle Identity FederationとRDBMSを統合し、ユーザー・セッション・データやメッセージ・データを格納する場合、どの時点でデータ圧縮を行うか決めることは重要事項になります。

圧縮可能なデータには次の3種類があります。

注意:
Liberty 1.xのサポートは非推奨です。

- SSOアーティファクト・プロファイルのAuthnRequest: Oracle Identity FederationがLiberty 1.xプロトコルのIdPとして動作する場合、サーバーは、アーティファクト・プロファイルが使用されたときに、AuthnRequestメッセージをRDBMSに格納します。Liberty 1.xを使用しない場合、このデータは圧縮しないでください。デフォルトでは、圧縮は無効です。

- SSOアーティファクト・プロファイルのアサーション・レスポンス: Oracle Identity FederationがSSOプロトコルのIdPとして動作する場合、サーバーは、アーティファクト・プロファイルが使用されたときに、アサーションを含むレスポンス・メッセージをRDBMSに格納します。アサーションに属性が含まれている場合は、これを有効にする必要があります。デフォルトでは、圧縮は有効です。

- ユーザー・セッション・データ: Oracle Identity Federationは、実行時にユーザー関連のセッション・データを格納します。(カスタム認証エンジンで設定されているか、Oracle Identity FederationがSPである場合に属性アサーション・ストレージが有効になっていたために)複数の属性がユーザー・セッションに格納される場合、圧縮を使用する必要があります。デフォルトでは、圧縮は無効です。

データを圧縮するようOracle Identity Federationを構成するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- SSOアーティファクト・プロファイルのAuthnRequestを圧縮する必要がある場合は、datastoreのtransientartifactrequestcompressionブール型プロパティをtrueに設定します。圧縮する必要がない場合は、falseに設定します。

setConfigProperty('datastore','transientartifactrequestcompression', 'true', 'boolean')

- SSOアーティファクト・プロファイルのアサーション・レスポンスを圧縮する場合は、datastoreのtransientartifactresponsecompressionブール型プロパティをtrueに設定します。圧縮しない場合は、falseに設定します。

setConfigProperty('datastore', 'transientartifactresponsecompression', 'true', 'boolean')

- ユーザー・セッション・データを圧縮する場合は、datastoreのtransientcompressionブール型プロパティをtrueに設定します。圧縮しない場合は、falseに設定します。

setConfigProperty('datastore', 'transientcompression', 'true', 'boolean')

注意:
Liberty 1.xのサポートは非推奨です。

6.6 セッション・リポジトリの構成

この項では、セッション・リポジトリのメンテナンスに関連するトピックについて説明します。

6.6.1 ユーザー・セッションのアサーション属性の格納

Oracle Identity Federationサーバーは、現在の認証ユーザーのセッション情報を格納するセッション・ストアとして機能します。Oracle Identity Federationがアイデンティティ・プロバイダ(IdP)として動作する場合、このセッション・リポジトリに、SSOアサーションに移入するための属性を格納できます。

ユーザー・セッションに格納されている属性は、次の2つの方法でストアに追加できます。

- カスタム認証エンジンで、ユーザー・セッションに保存される属性のリストを設定します。

- サービス・プロバイダ(SP)として動作するOracle Identity Federationによって、着信アサーションの処理時に行います。Oracle Identity Federationでは、アサーションに含まれる属性およびユーザー・セッションの名前IDとプロバイダIDを保存できます。

デフォルトでは、パフォーマンス上の理由により、Oracle Identity FederationがSPとして動作する場合、ユーザー・セッションのアサーション情報の格納は無効になっています。

アサーション情報を格納するようOracle Identity Federationサーバーを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- アサーションに含まれる属性および名前IDとプロバイダIDをユーザー・セッションに格納する場合は、spglobalグループのsessionstoreassertionattrsブール型プロパティをtrueに設定します。

setConfigProperty('spglobal',
'sessionstoreassertionattrs', 'true', 'boolean')

- それ以外の場合はfalseに設定します。

setConfigProperty('spglobal','sessionstoreassertionattrs', 'false', 'boolean')

6.7 追加のHTTP構成

この項では、Oracle Identity FederationのHTTP構成に関するその他のトピックについて説明します。内容は次のとおりです。

- Oracle Identity Federationによって設定されるHTTP CookieのHTTPOnlyフラグの構成

- HTTP POSTプロファイルをカスタマイズする場合の注意事項

- リダイレクトでの303ステータス・コードの使用

6.7.1 Oracle Identity Federationによって設定されるHTTP CookieのHTTPOnlyフラグの構成

RFC2965に対する非標準拡張では、HttpOnlyフラグを指定することにより、set-cookieヘッダーがさらに拡張されます。このフラグを設定した場合、クライアント(ブラウザ)では、スクリプト環境で使用可能なCookieコンテンツが生成されません。たとえば、Java Scriptのdocument.cookieメソッドはCookieコンテンツを返しません。これにより、クロスサイト・スクリプティングなどの攻撃から大幅に保護されます。

デフォルトでは、Oracle Identity FederationではHttpOnlyフラグは設定されていません。

Oracle Identity Federationサーバーは、ユーザーのブラウザに次のものを設定する際に、HttpOnlyフラグを設定するよう構成できます。

- Oracle Identity Federationがユーザー・セッションの参照に使用するCookie

- Oracle Access ManagerのCookie

HttpOnlyヘッダーを設定するようOracle Identity Federationを構成するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

1. Oracle Identity FederationのCookieをブラウザに送信する際にHttpOnlyフラグを設定する場合は、serverconfigグループのcookiehttponlyenabledブール型プロパティをtrueに設定します。フラグを設定しない場合は、falseに設定します。

setConfigProperty('serverconfig',
'cookiehttponlyenabled', 'true', 'boolean')

2. Oracle Access ManagerのCookieをブラウザに送信する際にHttpOnlyフラグを設定する場合は、spenginesグループのoamcookiehttponlyenabledブール型プロパティをtrueに設定します。フラグを設定しない場合は、falseに設定します。

setConfigProperty('spengines',
'oamcookiehttponlyenabled', 'true', 'boolean')

6.7.2 HTTP POSTプロファイルをカスタマイズする場合の注意事項

SAML/WS-Fedの仕様は、POSTプロファイルを定義しています。このプロファイルは、SAML/WS-FederationサーバーがHTMLフォームを使用してユーザーのブラウザをリモートのSAML/WS-Fed実装にリダイレクトする場合に使用します。

通常、このようなサーバーは、ブラウザに対して次のものを含むFORMが記述されたHTMLページを送信します。

- リモート・サーバーを参照するアクションURL

- SAML/WS-Fedメッセージを含む非表示フィールドや属性

このプロファイルを使用する場合、Oracle Identity Federationサーバーは、アクションURL、リモート・サーバーを参照するプロバイダID、およびリモート・サーバーに送信する非表示フィールドのリストを作成します。このデータは、postprofile.jspページ($ORACLE_IDM_HOME/fed/install/oif.earファイルのweb.warに含まれる)に渡され、この情報を使用して、ブラウザに表示されるHTMLページが作成されます。

このページを次のようにカスタマイズできます。

- ブラウザに表示される内容の変更

- リモート・サーバーに送信するフィールドの追加

注意:
リモートのSAML/WS-Federationサーバーが仕様に準拠していない場合、これらのフィールドを処理できない可能性があります。

特定のデプロイメント要求に沿うようにファイルを変更するには、POSTプロファイルに影響しないよう注意してください。たとえばこれは、アクションURLや非表示フィールドなど、Oracle Identity Federationサーバーによって設定される必須パラメータ/フィールドを削除した場合などに発生する可能性があります。ファイルを変更するには、oif.earおよびweb.warを解凍して変更を行い、web.warおよびEARファイルを再パッケージ化します。

6.7.3 リダイレクトでの303ステータス・コードの使用

Oracle Identity Federationは、SAML/WS-Fed/Libertyプロトコルを実装しています。これらのプロトコルは、ブラウザなどのHTTPクライアントにシングル・サインオン(SSO)機能を提供します。Oracle Identity Federationサーバーがブラウザに対してHTTPリダイレクト・コマンドを発行する場合、実行時にSSO処理で実行されるプロトコルやプロファイルに、HTTPリダイレクトを含めることができます。

注意:
Liberty 1.xのサポートは非推奨です。

デフォルトでは、Oracle Identity Federationは、リダイレクトの発行時に302 HTTPステータス・コードを使用します。クライアントがHTTP 1.1をサポートする場合、リダイレクトを発行する際に、かわりに303 HTTPステータス・コードを使用するようOracle Identity Federationサーバーを構成できます。

303 HTTPステータス・コードを使用するよう(可能な場合)Oracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- Oracle Identity Federationサーバーで303 HTTPステータス・コードを使用する場合(可能な場合)は、serverconfigグループのredirectuse302ブール型プロパティをfalseに設定します。

setConfigProperty('serverconfig',
'redirectuse302', 'false', 'boolean')

- それ以外の場合は、プロパティをtrueに設定します。

6.8 追加のプロトコル構成

この項は次のトピックで構成されています。

- eAuthモードの構成

- BAEの直接属性交換プロファイルの構成

- SAML 2.0 LDAP属性プロファイルの構成

- オンデマンド・グローバル・ログアウトの構成

6.8.1 eAuthモードの構成

Oracle Identity Federationサーバーは、eAuth仕様に準拠するよう構成できます。構成のほとんどは、Fusion Middleware Controlを使用して行いますが、仕様によりSSOアサーションの次の2つの属性が必須になります。これらの属性は、MBean/WLSTスクリプトによってのみ構成できます。

- us:gov:e-authentication:basic:specVer属性。このサーバーでサポートされるeAuth仕様のバージョンが含まれます。

- us:gov:e-authentication:basic:Sid属性。シングル・サインオンを実行するユーザーのセッション識別子が含まれます。

この2つの属性を(特定のプロバイダに対して)設定して、eAuthバージョンの値を設定するようOracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、必要に応じて次のプロパティを設定します。

- リモート・プロバイダのeauthmodeenabledブール型プロパティをtrueに設定して、eAuthモードを有効にします。

setFederationProperty(REMOTE_PROVIDER_ID,
'eauthmodeenabled', 'true', 'boolean')
##
## replace REMOTE_PROVIDER_ID with the identifier of the remote provider

- idpglobalグループのeauthversion文字列プロパティを、Oracle Identity Federationサーバーが使用する値(2.0など)に設定します。

setConfigProperty('idpglobal', 'eauthversion', '2.0', 'string')

6.8.2 BAEの直接属性交換プロファイルの構成

11gリリース1(11.1.1.7.0)以降では、Oracle Identity Federationでバックエンド属性交換(BAE)の直接属性交換プロファイルがサポートされます。このプロファイルは、SAML 2.0仕様で定義されるSAML属性問合せプロファイルに基づきます。

関連項目:
次の場所にある『Security Markup Language (SAML) 2.0 Identifier and Protocol Profiles for Backend Attribute Exchange (BAE) v2.0』ドキュメント
http://www.idmanagement.gov/sites/default/files/documents/BAE_v2_SAML2_Profile_Final_v1.0.0.pdf

BAEの直接属性交換プロファイルと相互作用するパートナの構成

BAEの直接属性交換プロファイルを使用して、パートナと相互運用するOracle Identity Federationを構成するには、次のようにします。

- 該当のパートナとの属性問合せプロトコルの交換について、Oracle Identity Federationを構成します。
詳細は、次の資料を参照してください。

- 第5.6項「Oracle Access Manager AuthZプラグインによる属性共有の構成」

- 第5.8項「属性共有用のWebサービス・インタフェース」

- BAEモードの該当のパートナを構成します。Oracle Identity Federationパートナに関するメッセージの送信や処理を行う場合にOracle Identity FederationでBAEプロファイル・ルールを使用するように、そのパートナのエントリでブール型プロパティを設定する必要があります。

パートナに対するBAEの直接属性交換プロファイルの設定

特定のパートナに対してBAEプロファイルを設定するようにOracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力して、パートナのattributebaeenabledブール型プロパティを設定します。

- setFederationProperty("PARTNER_PROVIDER_ID", "attributebaeenabled" , "true","boolean")

該当のパートナに対してBAE機能を有効にします(PARTNER_PROVIDER_IDを、パートナのProviderIDに置き換えます)。

- setFederationProperty("PARTNER_PROVIDER_ID", "attributebaeenabled" , "false","boolean")

該当のパートナに対してBAE機能を無効にします(PARTNER_PROVIDER_IDを、パートナのProviderIDに置き換えます)。

6.8.3 SAML 2.0 LDAP属性プロファイルの構成

SAML 2.0仕様には、X.500 LDAP属性プロファイルが定義されており、このプロファイルに準拠するようアサーションに含める必要のある属性がリストされています。

要件は次のとおりです。

- フォーマットは、urn:oasis:names:tc:SAML:2.0:attrname-format:uriにする必要があります。

- 名前はURIにする必要があります。

- SAML属性要素でXMLエンコーディング属性を指定する必要があり、その値は「LDAP」に設定する必要があります。

最初の2つの要件を満たすには、Oracle Identity Federationサーバー・インスタンスの属性をFusion Middleware Controlで構成します。

最後の要件を満たすには、WLSTスクリプトを使用してOracle Identity Federationを構成します。これにより、アサーションに含まれる属性をOracle Identity Federation/IDP/AttributeAuthorityが送信する際の送信先のプロバイダにプロパティが設定されます。

X.500 LDAP属性プロファイルに対するWLSTの使用方法

Oracle Identity Federationサーバー・インスタンスのWLSTスクリプト環境を入力してから、Oracle Identity Federationがアサーションを提供するリモート・プロバイダのattrx500ldapenabledプロパティを設定します。

attrx500ldapenabledブール型プロパティをtrueに設定して、サーバーがX.500 LDAP属性プロファイルに準拠するようにします。それ以外の場合はfalseに設定します。

setFederationProperty(REMOTE_PROVIDER_ID,
'attrx500ldapenabled', 'true', 'boolean')
##
## replace REMOTE_PROVIDER_ID with the identifier of the remote provider

6.8.4 オンデマンド・グローバル・ログアウトの構成

Oracle Identity Federationサーバーでログアウト処理が呼び出されたときに、WS-Fed/SAMLグローバル・ログアウトを実行するかどうかを指定できます。

一般的なフェデレーション・デプロイメントでは、ユーザーがフェデレーション・サーバーでログアウトを呼び出した場合のフローは、次のようになります。

- ユーザーは、/fed/user/logout URLでOracle Identity Federationのログアウト・サービスを呼び出します。
ログアウト・サービスの詳細は、第4.2.6項「ログアウト処理の起動」を参照してください。

- Oracle Identity Federationは、次の操作を行います。

- ユーザーを各種認証エンジンおよびSP統合モジュール(Oracle Access Manager、Oracle Single Sign-Onなど)からログアウトさせます。

- ユーザーをリダイレクトして、現在のユーザー・セッションで呼び出されたリモート・フェデレーション・パートナからログアウトさせます。この操作をグローバル・ログアウトと呼びます。

- グローバル・ログアウトが完了したら、ログアウト処理を終了します。

グローバル・ログアウト・フローを無効にする場合、Fusion Middleware Controlで次の2つの方法を使用できます。

- グローバルに無効にする場合は、「ローカルのみログアウト」設定を選択します(第5.2項「サーバー・プロパティの構成」を参照)。

- プロバイダごとに無効にする場合は、パートナ構成セクションの「Oracle Identity Federation設定」タブにある「このプロバイダでグローバル・ログアウトを実行しないでください」設定を選択します。

この2つの方法では、ログアウト・フローの動作を静的に制御できますが、オンデマンド・グローバル・ログアウトを使用すると、ユーザーが実行時にグローバル・ログアウト・プロトコルを呼び出せるかどうかを指定できます。

ユーザーがグローバル・ログアウトを選択できるかどうかを指定するには、serverconfigグループのslouserprefenabledブール型プロパティを次のように設定して、フェデレーション・サーバーを構成します。

- グローバル・ログアウトの選択をユーザーに許可する場合はtrueに設定します。

- グローバル・ログアウトの選択をユーザーに許可しない場合はfalseに設定します。

プロパティを設定するには、Oracle Identity Federationサーバー・インスタンスのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

setConfigProperty('serverconfig', 'slouserprefenabled', 'true', 'boolean')

オンデマンド・グローバル・ログアウトが有効な場合、ユーザーは、Oracle Identity Federationのログアウト・サービスURLを呼び出す際にglobalslo問合せパラメータを指定することにより、WS-Fed/SAMLログアウト処理を実行できます。

このブール型のパラメータには、次の2つのいずれかの値を指定できます。

- true。グローバル・ログアウト処理が実行されることを意味します。

- false。ローカル・ログアウト処理のみが実行されることを意味します。

ユーザーは、第4.2.6項「ログアウト処理の起動」の手順に従って、次のようなURLでサービスを呼び出します。

http://hostname:port/fed/user/logout?returnurl=http%3A%2F%2Fanotherhostname%2Fpath&globalslo=false

6.9 SOAPエンドポイントの保護

Oracle Identity Federationには、SAML 1.x/SAML 2.0/Liberty 1.xプロトコルで使用されるSOAPエンドポイントを保護するために、次の2つの方法が用意されています。

- SSL証明書を介したクライアント認証を使用したSSL: SOAPエンドポイントは、SSLを使用し、SSLクライアント証明書を要求することによって保護されます。

- HTTP Basic認証: この方法の場合、SOAPエンドポイントはHTTP Basic認証メカニズムを使用して保護されます。

注意:
Liberty 1.xのサポートは非推奨です。

この項の内容は次のとおりです。

- SSLクライアント認証

- HTTP Basic認証

6.9.1 SSLクライアント認証

次の方法の詳細は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

- SOAP URLを保護するためのSSLの構成

- SSLによって保護されているSOAPエンドポイントに接続するためのOracle Identity Federationの構成

6.9.2 HTTP Basic認証

この項では、次の内容について説明します。

- SOAP URLを保護するためにサーバー上でHTTP Basic認証を構成する方法

- HTTP Basic認証によって保護されているリモート・サーバーに、SOAPプロトコルを介して接続する際に使用される資格証明を構成する方法

注意:
mod_ossoを使用してOracle Single Sign-Onと統合されている場合、Oracle Identity FederationはHTTP Basic認証では保護できません。

6.9.2.1 SOAP URLを保護するためのHTTP Basic認証の構成

この項では、SOAPエンドポイントを保護するために必要な手順を示します。構成の変更は、Oracle WebLogic管理サーバーで行います。

手順は次のとおりです。

作成したポリシーを確認するためのOracle WebLogic Serverの構成

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のペインで、「セキュリティ・レルム」を選択し、「myrealm」→「構成」→「詳細」の順に移動します。

3. 次の設定を選択します。

- ロールとポリシーのチェック: すべてのWebアプリケーションとEJB

- WebアプリケーションまたはEJBのデプロイ時: デプロイメント・ディスクリプタのロールとポリシーを初期化
「保存」をクリックします。

4. 管理サーバーを停止するために、「環境」→「サーバー」→「制御」に移動し、「AdminServer」を選択して、「停止」→「ただちに強制停止」をクリックします。

5. ターミナル・ウィンドウから、スクリプト$DOMAIN_HOME/bin/startWebLogic.shを呼び出して、管理サーバーを起動します。

グループおよびユーザーの作成

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のペインで、「セキュリティ・レルム」を選択し、「myrealm」→「ユーザーとグループ」→「グループ」の順に移動します。

3. 「新規」をクリックして、名前(soapusersなど)を選択します。「OK」をクリックします。

4. 「ユーザーとグループ」→「ユーザー」の順に移動します。

5. 「新規」をクリックして、名前とパスワードを選択します。「OK」をクリックします。

6. 作成したユーザーをクリックして、「グループ」タブを選択します。

7. 作成したグループを選択して、「選択済み」列に移動します。「保存」をクリックします。

さらにユーザーを入力するには、ステップ4から7までを繰り返します。

ロールおよびポリシーの作成

1. Oracle WebLogic Serverの管理サーバー・コンソールにログインします。

2. 左側のペインで、「デプロイメント」を選択し、Oracle Identity Federationアプリケーションを展開して、「/fed」をクリックします。

3. 「セキュリティ」→「ロール」の順に移動します。

4. 「新規」をクリックして、名前(soapusersなど)を選択します。「URLパターン」で、「/」を入力します。「OK」をクリックします。

5. 作成したロールをクリックして、「条件の追加」を選択します。

6. 「グループ」を選択して、「次へ」をクリックします。

7. 作成したグループの名前を入力して、「追加」→「終了」の順にクリックします。

8. 「保存」をクリックします。

9. 左側のペインで、「デプロイメント」を選択し、Oracle Identity Federationアプリケーションを展開して、「/fed」をクリックします。

10. 「セキュリティ」→「ポリシー」の順に移動します。

11. SOAPエンドポイントを保護するには、一連のポリシー(保護が必要なURLごとに1つのポリシー)を作成する必要があります。保護が必要なURLのリストを表6-2に示します。ポリシーを作成するには、次の手順に従います。

1. 「新規」をクリックして、保護する必要のあるURLを(表1から)入力します。「OK」をクリックします。

2. 作成したポリシーをクリックして、「条件の追加」を選択します。

3. 「ロール」を選択して、「次へ」をクリックします。

4. 作成したロールの名前を入力して、「追加」→「終了」の順にクリックします。

5. 「保存」をクリックします。

12. グループ、ユーザー、ロールおよびポリシーを作成したら、管理サーバーおよび管理対象サーバーを再起動して変更を有効にします。

表6-2 ポリシーの作成が必要なURL

Liberty 1.x/SAML 2.0 SOAPエンドポイント

SAML 1.x SOAPエンドポイント

/idp/soap

/idp/soapv11

/sp/soap

/sp/soapv11

/aa/soap

/aa/soapv11

/ar/soap

/authnauth/soapv11

/authnauth/soap

6.9.2.2 保護されているSOAP URLに接続するためのOracle Identity Federationの構成

クライアント側では、Oracle Identity Federationにより、SOAPチャネルでピア・プロバイダに接続する場合のBasic認証のサポートが実装されます。Oracle Identity Federation構成を更新し、サーバーがリモート・プロバイダのSOAPエンドポイントに接続する際、入力した資格証明が使用されるようにする必要があります。

Oracle Identity Federationから保護されているSOAP URLへの接続を有効にするには、次の手順を実行します。

1. Oracle Identity FederationがデプロイされているドメインでFusion Middleware Controlコンソールにログインします。

2. 「Oracle Identity Federation」→「管理」→「フェデレーション」の順にナビゲートします。

3. SOAPチャネルでHTTP Basic認証が必要なリモート・プロバイダを選択し、「編集」をクリックします。

4. 「Oracle Identity Federation設定」タブで、「HTTP基本認証の有効化」を選択して、リモート・プロバイダへの接続時にサーバーが使用するユーザー名とパスワードを入力します。

5. 「適用」をクリックします。

6.10 SAML 2.0 IdP検出(共通ドメインCookie)プロファイルの構成

SAML 2.0では、サービス・プロバイダはユーザーが認証に使用したアイデンティティ・プロバイダを検出できます。ユーザーを認証した後で、IdPはそのプロバイダIDをユーザーのブラウザのCookieの値に追加します。SPはこのCookieを読み取り、使用されたIdPを検出します。IdPおよびSPでこのCookieを読み書きするには、このCookieがすべてのIdPおよびSPに共通のドメインにある必要があります。そのため、このCookieは共通ドメインCookie(CDC)と呼ばれます。

Oracle Identity Federationは、SPとして動作している場合に、CDCプロファイルが有効で、ターゲットIdPのプロバイダIDが指定されずにSSO処理が開始されると、共通ドメインCookieを読み取り、リスト内で最初のIdPに対してSSOを実行します。Oracle Identity Federationを構成して、SSOを実行するIdPを選択するようユーザーに求めることもできます。ユーザーは、CDC内にあるすべてのIdPのリストから選択できます。このIdPは、SPとして動作するOracle Identity Federationに信頼されています。

この項では、Oracle Identity Federationを構成して、CDCプロファイルを使用する方法について説明します。内容は次のとおりです。

- CDCを設定するための準備手順

- アイデンティティ・プロバイダとしてのCDCプロファイルの構成

- サービス・プロバイダとしてのCDCプロファイルの構成

- CDC内の信頼できるプロバイダ・リストを表示するためのOracle Identity Federationの構成

6.10.1 CDCを設定するための準備手順

共通ドメインCookieは常にセキュアなCookieとしてマークされます。そのため、CDCプロファイルを使用するには、アイデンティティ・プロバイダとして動作しているか、サービス・プロバイダとして動作しているかにかかわらず、SSLを有効にする必要があります。SSLを有効にするには、第8.1項「Oracle Identity FederationでのSSLの構成」の手順を参照してください。

6.10.2 アイデンティティ・プロバイダとしてのCDCプロファイルの構成

Oracle Identity FederationがIdPとして動作している場合は、次の手順に従ってCDCプロファイルを構成します。

関連項目:
第5.3項「アイデンティティ・プロバイダの構成 - 共通プロパティ」

1. Oracle Enterprise Managerにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

3. 「共通」タブで、「共通ドメインの有効化」を選択して、次のプロパティを入力します。

- 共通ドメインURL: 次の形式でOracle Identity Federationがリスニングしている、共通ドメイン内のOracle Identity Federation intro URLです。

https://hostname_in_common_domain:sslport/fed/idp/intro

次に例を示します。

https://mycorp.commondomain.com:4443/fed/idp/intro

注意:
このURLには、前述の手順で構成したHTTPSとSSLポートを使用する必要があります。

- 名前: Cookieが書き込まれるドメインです(.commondomain.comなど)。

注意:
ドメインの名前は、ピリオド(.)で始まる必要があります。

- Cookie存続期間(日): Cookieの存続期間(日単位)です。

6.10.3 サービス・プロバイダとしてのCDCプロファイルの構成

Oracle Identity Federationがサービス・プロバイダとして動作している場合は、次の手順に従ってCDCプロファイルを構成します。

関連項目:
第5.5項「サービス・プロバイダの構成」

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ」の順に移動します。

3. 「共通」タブで、「共通ドメインCookieサービスの有効化」を選択して、次のプロパティを入力します。

- サービスURL - 次の形式でOracle Identity Federationがリスニングしている、共通ドメイン内のOracle Identity Federation introsso URLです。

https://hostname_in_common_domain:sslport/fed/sp/introsso

次に例を示します。

https://mycorp.commondomain.com:4443/fed/sp/introsso

注意:
このURLには、前述の手順で構成したHTTPSとSSLポートを使用する必要があります。

6.10.4 CDC内の信頼できるプロバイダ・リストを表示するためのOracle Identity Federationの構成

ターゲットIdPのプロバイダIDが指定されずにSSOフローが開始された場合に、ユーザーに対して共通ドメインCookie内の信頼できるIdPのリストから入力を求めるようにするには、次の手順に従ってOracle Identity Federationを構成します。

1. 第6.10.3項「サービス・プロバイダとして動作する場合のCDCプロファイルの構成」の手順に従って、CDCプロファイルを構成します。

2. Oracle Identity FederationのWLSTコマンドまたはMBeanを使用して、Config「spglobal」のcommondomainidpdiscenabledプロパティをtrueに設定します。

WLSTコマンドの使用

次のコマンドを使用します。

setConfigProperty('spglobal', 'commondomainidpdiscenabled', 'true', 'BOOLEAN')

詳細は、第9章「Oracle Identity Federationコマンドライン・ツール」を参照してください。

MBeanの使用

spglobalというConfigMXBeanで、次の引数を指定してputProperty処理を呼び出します。

- 名前: commondomainidpdiscenabled

- 値: true

- 型: BOOLEAN

詳細は、付録A「Oracle Identity Federation MBean」を参照してください。

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

アイデンティティ・プロバイダ検出は、SSOで使用するアイデンティティ・プロバイダを(多くの場合、ユーザーとの対話によって)選択するためのサービスです。Oracle Identity Federationは、アイデンティティ・プロバイダ検出サービスを備えていませんが、SPが開始するSSOにおいて、SPへの認証リクエストでIdPが渡されなかった場合に、IdPを選択するサービスを使用できるようサポートしています。

詳細は次の仕様を参照してください。

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cs-01.pdf

Oracle Identity Federationがサービス・プロバイダとして動作している場合、ターゲットIdPのプロバイダIDが指定されずにSSO処理が開始された場合に、SSOを実行するアイデンティティ・プロバイダを選択するためのカスタムページにユーザーをリダイレクトするよう構成できます。

ユーザーがアイデンティティ・プロバイダを選択すると、選択したIdPを含むSSOリクエストがカスタム・ページからOracle Identity Federationに再送信されます。

IdP検出を構成するには、次の手順に従います。

関連項目:
第5.5項「サービス・プロバイダの構成」

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サービス・プロバイダ」の順に移動します。

3. 「共通」タブで、「アイデンティティ・プロバイダ検出サービスの有効化」を選択して、次のプロパティを入力します。

- Service URL: 選択対象のIdPを表示するカスタム・ページの場所です。

6.11.1 IdP検出サービス・ページの作成

Oracle Identity Federationは、IdP検出サービス・ページへのリダイレクト時に次のパラメータを指定します。

- return: このページからOracle Identity Federationに対する新しいリクエストの送信先のURLです。リクエストには選択されたIdPのプロバイダIDが含まれます。

- returnIDParam: Oracle Identity Federationに送信するリクエストで、選択されたIdPのプロバイダIDを指定する際に使用するパラメータの名前です。

このページはこれらのパラメータの値を取得し、IdPのリストを表示した後、選択されたIdPのプロバイダIDを指定して新しいリクエストをOracle Identity Federationに送信します。

注意:
URL問合せパラメータ値が正しくURLエンコードされていることを確認します。

例

IdP検出サービス・ページの例を次に示します。このページでは、ユーザーがアイデンティティ・プロバイダを(プロバイダIDのリストhttp://idp1.com, http://idp2.com, http://idp3.comから)選択すると、選択されたプロバイダIDがOracle 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>

6.12 情報カードの設定

Oracle Identity Federationでは、サーバーが情報カードのRP(リソース・プロバイダ)として動作する場合、情報カードを認証エンジンとして使用できます。

フローは次のようになります。

- Oracle Identity Federationは、そのユーザーを認証するためにチャレンジが必要であると判断し、情報カード認証エンジンを選択します。

- Oracle Identity Federationは、情報カードのリンクが含まれるログイン・ページを表示します。このリンクには、Oracle Identity Federationがリクエストする、STSサーバーからのクレームと、戻されるアサーションのタイプ(オプション)が含まれます。Oracle Identity Federationでは、認識されているSTSサーバーを個別に表示することも、1つの情報カード・リンクのみを表示して、認識済のSTSサーバーは表示しないこともできます。

- ユーザーがリンクをクリックします。

- ユーザーのマシンにインストールされているアイデンティティ・セレクタが起動され、この処理で使用可能なカードが表示されます。

- ユーザーがカードを選択します。

- アイデンティティ・セレクタは、STSサーバーに接続してSAMLアサーションを取得します。(注意: SAMLアサーションは、Oracle Identity Federation SSLサーバー証明書を使用して暗号化されます。)

- アイデンティティ・セレクタは、SAMLアサーションをOracle Identity Federationに提供します。

- Oracle Identity Federationは、暗号化キーストアを使用してアサーションを復号化し、署名を検証します。

- Oracle Identity Federationは、SAMLアサーションをローカル・ユーザーにマップします。このとき、「SAML 1.x」およびSAML 2.0タブの「サービス・プロバイダ」ページにリストされている設定に基づいて、SAML 1.xまたはSAML 2.0のアサーション・マッピング・モジュールを使用します。(注意: Oracle Identity Federationがサービス・プロバイダとして動作する場合、このステップはフェデレーションSSOと同様のフローになります。)

- アサーションがローカル・ユーザー・レコードにマッピングされると、認証フェーズが完了し、Oracle Identity Federationは情報カード認証エンジンを呼び出す前に実行していた処理を再開します。

情報カード認証エンジンは、さらに、情報カード・プロバイダのオプション属性をリクエストできます。

情報カード・エンジンは、特定の属性を返すよう指示されると、それらの属性をオプション・クレームとして情報カード・プロバイダへのリクエストに追加します。この特定の属性とは、アサーションの内容の一部が認証エンジンで移入されたユーザー・セッション属性に依存していることに起因して、IdPとして動作しているOracle Identity Federationがリクエストした属性です。

この項は次のトピックで構成されています。

- サーバー側での情報カードの設定

- クライアント側での情報カードの設定

6.12.1 サーバー側での情報カードの設定

サーバー側の設定は次のとおりです。

- Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

- Oracle Identity Federationの構成の更新

- 個人カード発行者用STSの追加

- マネージ情報カード用STSの追加

6.12.1.1 Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

次の手順を実行します。

1. Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesを次のURLからダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

2. ミドルウェア・ホーム・フォルダの下にあるすべての$JAVA_HOME/jre/lib/securityディレクトリでファイルを解凍します(これらのディレクトリを検索するには、US_export_policy.jarファイルを探します)。それぞれの$JAVA_HOME/jre/lib/securityディレクトリで、デフォルトの低強度のlocal_policy.jarファイルとUS_export_policy.jarファイルをOracleが提供するファイルで上書きします。

関連項目:
『Oracle Fusion Middleware管理者ガイド』の「Middlewareホームとは」に関する項

3. 管理サーバーおよびOracle Identity Federationが実行されている管理対象サーバーを再起動します。

6.12.1.2 Oracle Identity Federationの構成の更新

Fusion Middleware ControlでOracle Identity Federationインスタンスに移動して、次の操作を実行します。

1. 情報カード認証ではSSLが必要です。第8.1項「Oracle Identity FederationでのSSLの構成」の説明に従ってOracle WebLogic ServerでSSLを構成し、Oracle Identity FederationサーバーでSSLを有効にします。SSLキーストアが存在しない場合は、新しいSSLキーストアを作成する必要があります。
SSLサーバー証明書では、RSA公開鍵アルゴリズムを使用する必要があります。これはSAML暗号化処理で必要になります。

2. Oracle Identity Federation暗号化ウォレットには、Oracle WebLogic ServerでSSLサポートに使用されるSSLキーストアを使用します。このキーストアを使用すると、情報カード・クライアントはSSLサーバー証明書を使用してアサーションを暗号化します。そのため、Oracle Identity Federationでは、このキーストアをSSLトラフィックで使用される鍵ペアの暗号化ウォレットとして使用する必要があります。

3. SSL JavaキーストアをOracle Identity Federation暗号化ウォレットとしてロードします。「管理」→「セキュリティおよび信頼」の順に移動し、パスワードと別名を指定して、新しいウォレット・キーストアをアップロードします。

注意:
暗号化キーストアが変更されているため、信頼できるパートナにメタデータを再分配する必要があります。

4. 「IDMデータ・ストア」→「認証エンジン」の順に移動し、情報カード・エンジンを有効にします。WS-Trustアサーションをユーザー・データ・ストアのレコードにマップするかどうかによって、「アサーションのユーザーへのマップ」のボックスを選択または選択解除します。

注意:
Oracle Identity Federationは、認証メカニズムを必須クレームとして追加するよう構成できます。これにより、情報カード・プロバイダからの特定の認証方式をリクエストできるようになります。この機能を有効にするには、「認証メカニズムを含む」ボックスを選択します。

注意:
情報カード・プロバイダがこの機能をサポートしない場合を除いて、ほとんどのデプロイメントで、このボックスのチェックは外したままにしてください。
このボックスを選択した場合、Oracle Identity Federationは、認証メカニズムのマッピングで定義されているとおりに、ローカル認証メカニズムの値をSAML認証方式に変換します。

また、このボックスを選択した場合、Oracle Identity Federationは、指定の情報カード・プロバイダが認証メカニズムの組込みをサポートしているかどうかを確認するために、「認証メカニズム・クレームをサポートします」というプロバイダ固有のプロパティを確認します。このプロパティは、「リモート・プロバイダ」構成セクションの信頼できるプロバイダ設定で定義されています。

必要に応じて、デフォルト認証エンジンにする情報カードを選択し、変更を保存します。

「アサーションのユーザーへのマップ」ボックスを選択すると、「サービス・プロバイダ」ページのSAML 2.0/SAML 1.xアサーションタブの構成に基づいて、着信アサーションがユーザー・レコードにマップされます。

注意:
個人発行者カードにマップされている認証メカニズムで認証を行うために情報カード認証エンジンが呼び出された場合、その個人発行者カードのみがログイン・ページに表示されます。個人発行者カードにマップされている認証メカニズム以外で呼び出された場合は、すべての情報カード・プロバイダが表示されます。

6.12.1.3 個人カード発行者用STSの追加

Oracle Identity Federationが個人カード発行者用のSTSからアサーションを受け取る場合、Oracle Identity Federationと発行者との間で信頼関係が確立されている必要があります。この信頼関係を確立するには、STSを定義し、サーバーのフェデレーションで有効にします。

Fusion Middleware Controlで、Oracle Identity Federationインスタンスを特定し、次の操作を実行します。

1. 「管理」→「フェデレーション」の順に移動し、http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/selfで識別されるWS-Fed 1.1 IdPを追加します。

2. STSを選択して、「更新」をクリックし、「手動更新」を選択します。

3. 「シングル・サインオン/情報カード・モード」ドロップダウンから、「情報カード」(STSが情報カード・プロトコルのみをサポートする場合)、または「シングル・サインオンと情報カード」(STSが情報カード・プロトコルとSSOプロトコルをサポートする場合)を選択します。

4. 情報カードには、STSで作成され、アサーションに組み込まれた属性やクレームを、リライイング・パーティ(この場合は、Oracle Identity Federation)で表示する必要があることが記述されています。属性およびオプションの名前IDがアサーションに含まれる場合、Oracle Identity Federationはこのアサーションをローカル・ユーザー・レコードにマップできます(この操作のための構成がされている場合)。
STSにリクエストする属性を追加するには、「属性マッピング」をクリックします。

5. カード・セレクタが呼び出されたときに、Oracle Identity Federationサーバーで必要な属性がリストされるように属性マッピングを構成します。「情報カードの内容が必要」と表示されているそれぞれの属性について、Oracle Identity Federationは、その属性をWS-Trustサーバーからのアサーションで戻すよう要求します。「ユーザー属性名」は、Oracle Identity Federationの属性を参照するために使用します。「アサーション属性名」は、STSで認識される属性の名前です。また、「フォーマットまたはネームスペース」は、属性がバインドされるネームスペースです。Oracle Identity FederationからSTSへの必要なクレームは、ネームスペース、「/」、およびアサーション属性名が連結されたもので構成されます。
次に例を示します。

- 属性エントリ(「ユーザー属性名」: lastname、「アサーション属性名」: surname、「フォーマットまたはネームスペース」: http://schemas.xmlsoap.org/ws/2005/05/identity/claims)を追加します。「情報カードの内容が必要」ボックスを選択します。

- 別の属性エントリ(「ユーザー属性名」: firstname、「アサーション属性名」: givenname、「フォーマットまたはネームスペース」: http://schemas.xmlsoap.org/ws/2005/05/identity/claims)を追加します。「情報カードの内容が必要」ボックスを選択します。

6. 個人カード発行者から提供されるアサーションをローカル・ユーザーにマップするようOracle Identity Federationを構成します。
たとえば、「Oracle Identity Federation設定」タブの「アサーション設定」タブで、「名前IDによるユーザーのマップ」ボックスを選択解除し、「属性問合せによるユーザーのマップ」を選択して、LDAP問合せ(&(sn=%lastname%)(givenname=%firstname%))を入力します。

7. 変更を保存します。

8. 「認証メカニズム・クレームをサポートします」ボックスを選択または選択解除し、認証メカニズムを必要な情報カード属性としてリストするかどうかを指定します。リクエストする認証メカニズムを属性で指定する機能は、すべてのWS-Trustサーバーでサポートされているとはかぎりません。

9. 変更を保存します。

6.12.1.4 マネージ情報カード用STSの追加

Oracle Identity FederationがリモートSTSからアサーションを受け取る場合、Oracle Identity Federationサーバーとリモート・サーバーとの間で信頼関係が確立されている必要があります。この信頼関係を確立するには、STSを定義し、サーバーのフェデレーションで有効にします。

Fusion Middleware Controlで、Oracle Identity Federationインスタンスを特定し、次の操作を実行します。

1. エントリを追加するには、STSのプロバイダIDを入力して、IdPおよびWS-Fed 1.1バージョンを選択します。

2. STSを選択して、「更新」をクリックします。

3. IdPの署名検証証明書を入力します。

4. 「シングル・サインオン/情報カード・モード」ドロップダウンから、「情報カード」(STSが情報カード・プロトコルのみをサポートする場合)、または「シングル・サインオンと情報カード」(STSが情報カード・プロトコルとSSOプロトコルの両方をサポートする場合)を選択します。

5. 情報カードには、STSで作成され、アサーションに組み込まれた属性やクレームを、リライイング・パーティ(この場合は、Oracle Identity Federation)で表示する必要があることが記述されています。属性およびオプションの名前IDがアサーションに含まれる場合、Oracle Identity Federationはこのアサーションをローカル・ユーザー・レコードにマップできます(この操作のための構成がされている場合)。
STSにリクエストする属性を追加するには、「属性マッピング」をクリックします。

6. カード・セレクタが呼び出されたときに、Oracle Identity Federationサーバーで必要な属性がリストされるように属性マッピングを構成します。「情報カードの内容が必要」と表示されているそれぞれの属性について、Oracle Identity Federationは、その属性をWS-Trustサーバーからのアサーションで戻すよう要求します。「ユーザー属性名」は、Oracle Identity Federationの属性を参照するために使用します。「アサーション属性名」は、STSで認識される属性の名前です。また、「フォーマットまたはネームスペース」は、属性がバインドされるネームスペースです。Oracle Identity FederationからSTSへの必要なクレームは、ネームスペース、「/」、およびアサーション属性名が連結されたもので構成されます。
次に例を示します。

- 属性エントリ(「ユーザー属性名」: lastname、「アサーション属性名」: surname、「フォーマットまたはネームスペース」: http://schemas.xmlsoap.org/ws/2005/05/identity/claims)を追加します。「情報カードの内容が必要」ボックスを選択します。

- さらに、別の属性エントリ(「ユーザー属性名」: firstname、「アサーション属性名」: givenname、「フォーマットまたはネームスペース」: http://schemas.xmlsoap.org/ws/2005/05/identity/claims)を追加します。「情報カードの内容が必要」ボックスを選択します。

7. 個人カード発行者から提供されるアサーションをローカル・ユーザーにマップするようOracle Identity Federationを構成します。
たとえば、「Oracle Identity Federation設定」タブの「アサーション設定」タブで、「名前IDによるユーザーのマップ」ボックスを選択解除し、「属性問合せによるユーザーのマップ」を選択して、LDAP問合せ(&(sn=%lastname%)(givenname=%firstname%))を入力します。

8. 変更を保存します。

6.12.2 クライアント側での情報カードの設定

この項は次のトピックで構成されています。

- Oracle Identity Federation SSL証明書のインポート

- 個人情報カードの作成

6.12.2.1 Oracle Identity Federation SSL証明書のインポート

クライアント・マシンで、Oracle Identity Federationを信頼し、ローカル・コンピュータに格納されている情報カードの使用をユーザーに許可するには、Windows CardSpaceに対応したOracle Identity Federation SSL証明書を信頼する必要があります。SSLサーバーを生成した認証局をクライアントで信頼しない場合は、証明書をインポートする必要があります。

証明書をインポートするには、次の手順を実行します。

1. Internet Explorerを使用して、https://host:portの形式のURLに移動します。

2. ページを右クリックします。

3. 「プロパティ」を選択します。

4. 「証明書」を選択します。

5. 「証明のパス」タブをクリックします。

6. 証明書を発行したCAを選択し、証明書を表示します。

7. 「証明書のインストール」をクリックし、「信頼されたルート証明機関」に証明書をインポートします。

6.12.2.2 個人情報カードの作成

Windows CardSpaceで個人情報カードを作成するには、次の手順を実行します。

1. Windowsの「コントロール パネル」に移動します。

2. 「Windows CardSpace」をダブルクリックします(ない場合は、Microsoftのダウンロード・サイト(http://www.microsoft.com/downloads)から.NETをインストールします)。

3. 「Add a Card」をクリックします。

4. 「Create a Personal Card」を選択して、各フィールドを入力します。

5. 変更を保存します。

6.13 追加のランタイム構成

この項では、実行時の動作を管理するために構成可能な追加機能について説明します。

- SSO処理およびログアウト処理におけるターゲットURLの検証

- SSO完了後のSPエンジンへのXMLメッセージの送信

- エラー・ページのカスタマイズ

- SSOプロトコル・メッセージに対するスキーマ検証の構成

6.13.1 SSO処理およびログアウト処理におけるターゲットURLの検証

SSOプロトコルおよびログアウト・プロトコルの実行時に、Oracle Identity FederationはSAML/WS-Fedプロトコル交換を実行し、次のような最終のターゲットURLにユーザーをリダイレクトします。

- 保護されているリソース(SSO実行時)、または

- returnurl(ログアウト実行時)

これらのURLは、実行時に問合せパラメータとして指定できます(たとえば、IdPが開始するSSOやログアウト・フローなどでのreturnurl問合せパラメータ)。

注意:
returnurl問合せパラメータ値は、正しくURLエンコードする必要があります。

URLを指定する場合の例を次に示します。

- ユーザーは次のようにアクセスして、IdPが開始するSSOフローを開始できます。

/fed/idp/initiatesso?providerid=SP_PROVIDER_ID&returnurl=http%3A%2F%2Furl.com

- ユーザーは次のようにアクセスして、ログアウト・フローを開始できます。

/fed/user/logout?returnurl=http%3A%2F%2Furl.com

Oracle Identity Federationでは、実行時に指定されるURLを検証できます。検証を構成するには、承認済のホスト名または承認済のドメイン名のリストを指定します。

注意:
ドメインは「.」で始まる文字列です。たとえば、Oracleドメイン用の.oracle.comなどです。

デフォルトでは、検証は無効です。

戻りURL検証モジュールを構成するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、serverconfigグループのreturnurlvalidationenabledブール型プロパティをtrue(またはfalse)に設定し、モジュールを有効(または無効)にします。次に例を示します。

setConfigProperty('serverconfig', 'returnurlvalidationenabled', 'true', 'boolean')

ホスト名またはドメインを承認済URLのリストに追加するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のコマンドを発行します。

- ホスト名をreturnurlvalidationlistリストに追加するには、次のようにします。

addConfigPropertyListEntry('serverconfig','returnurlvalidationlist',
'hostname.domain.com','string')

- ドメインをreturnurlvalidationlistリストに追加するには、次のようにします。

addConfigPropertyListEntry('serverconfig','returnurlvalidationlist',
'.domain.com','string')

6.13.2 SSO完了後のSPエンジンへのXMLメッセージの送信

Oracle Identity FederationがSPとして動作している場合、フェデレーション・シングル・サインオン・フローでサーバーが受信したアサーションが含まれるXMLメッセージを送信できます。これは、使用されたバインディングに応じて、SAMLまたはSOAPメッセージになります。

次の点に注意してください。

- XMLメッセージは、アサーションで受信した属性とともにSPエンジンに送信されます。

- メッセージは、orafed-xmlmessageで参照されるマップに格納されます。

- 属性マップは、oracle.security.fed.sp.attributesで参照されるHttpServletRequestオブジェクトに属性として格納されます。

メッセージの送信を有効にするには、spglobalグループのspattrsincludexmlmessageブール型プロパティをtrueに設定します。

メッセージの送信を無効にするには、このプロパティをfalseに設定します。

注意:
デフォルト構成は、falseです。

6.13.3 エラー・ページのカスタマイズ

Oracle Identity Federationでは、次のような様々な理由でエラーが発生します。

- ページが見つからない

- フェデレーテッド・シングル・サインオン(SSO)エラー

- ランタイム・エラー

エラーが発生すると、サーバーはエラー・コード(404、401または500)を返し、ユーザーにはOracle WebLogic Serverのエラー・ページが表示されます。

Oracle Identity Federationを構成して、ユーザーのリダイレクト先をエラー・コードに基づいたカスタム・ページにすることができます。

serverconfig構成グループの文字列プロパティまたはurlerrornnnを、Oracle Identity Federationからエラーが返された場合のユーザーのリダイレクト先のURLに設定します。ここで、nnnは、401、404または500です。(つまり、urlerror401、urlerror404およびurlerror500プロパティを設定できます。)

注意:

- 401エラーは、フェデレーテッドSSO処理でフェデレーテッドSSOが失敗した場合に発生します。

- 404エラーは、ユーザーがOracle Identity Federationサーブレット(/fed/idp、/fed/sp、/fed/user...)のいずれかにアクセスしようとして、そのページが見つからなかった場合に発生します。

- 500エラーは、実行時に致命的な例外が発生した場合に発生します。

- サーバーを適切に初期化できない場合、Oracle Identity Federationは、ユーザーをurlerror500 URLにリダイレクトできません。

6.13.4 SSOプロトコル・メッセージに対するスキーマ検証の構成

Oracle Identity Federationは、SSOプロトコル・メッセージに対するXMLスキーマ検証をサポートしています。

この機能は、schemavalidationenabledプロパティで実装されています。デフォルトでは、検証はオフになっています。

スキーマ検証を有効にするには、Oracle Identity Federationサーバー・インスタンスのスクリプト環境を入力してから、schemavalidationenabledプロパティをtrueに設定します。

setConfigProperty('serverconfig','schemavalidationenabled','true','boolean')

検証を無効にするには、このプロパティをfalse(デフォルト値)に設定します。

setConfigProperty('serverconfig','schemavalidationenabled','false','boolean')

6.14 追加のフェデレーション・データ・ストア構成

フェデレーション・データ・ストアとしてLDAPサーバーまたはRDBMSを使用するようOracle Identity Federationが構成されている場合、サーバーは、フェデレーション・レコードの作成、検索、更新、削除に伴う各種処理を実行します。

通常、フェデレーション・レコードは次のもので構成されています。

- IdP名前ID: アイデンティティ・プロバイダで作成され、SAMLメッセージで使用される名前識別子データです。

- SP名前ID: 名前識別子管理の更新処理時にサービス・プロバイダでオプションで設定される名前識別子データです。
名前IDが設定されている場合は、その名前IDがSAMLメッセージで使用されます。設定されていない場合は、IdP名前IDが使用されます。

Oracle Identity Federationがサービス・プロバイダとして動作する場合、サーバーはアサーションを処理する操作で、アサーションに含まれる名前ID要素の参照先のフェデレーション・レコードを検索しようとします。デフォルトでは、まずSP名前IDに基づいて検索を実行し、結果が戻らなかった場合は、IdP名前IDに基づいて検索を実行します。

一部のデプロイメントでは、Oracle Identity Federationが次のような状態であることが考えられます。

- どの名前ID管理プロトコル交換を実行するようにも構成されていない。

- SP名前IDを設定するためにフェデレーション・レコードが更新されていない(つまり、どのフェデレーション・レコードに対しても、管理者が管理ツールを使用して更新処理を実行したことがないということです)。

この場合、SP名前IDを使用したアサーションの処理で、フェデレーション・レコードの最初の検索が実行された際に、いずれのレコードも返されません。また、レスポンス時間が増大します。

SP名前ID検索が不要な場合は、これを無効にすることでパフォーマンスを向上させることができます。検索を有効または無効にするには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、この構成を次のように変更します。

注意:
デフォルトでは、SP名前ID検索は有効です。

- SP名前ID検索を有効にするには、datastoreグループのfedusespnameidlookupブール型プロパティをtrueに設定します。

- SP名前ID検索を無効にするには、datastoreグループのfedusespnameidlookupブール型プロパティをfalseに設定します。

次に例を示します。

setConfigProperty('datastore', 'fedusespnameidlookup', 'false', 'boolean')

6.15 Oracle Identity Federation 10gおよびShareIDサービスURLに対する下位互換性の設定

背景

Oracle Identity Federation 10gでは、SHAREid/COREid Federation 2.xと同様に、SAML 1.xおよびWS-Federationプロトコル・サポートのサービスURLを提供していました。これらは、SAML 2.0およびLiberty 1.xサービスURLとは異なります。これらのURLは、SAML 2.0およびLiberty 1.xサービスURLとの一貫性を保つために、11gのOracle Identity Federationで変更されました。つまり、Oracle Identity Federation 11gにアップグレードするカスタマがSAML 1.xまたはWS-Federationを使用する場合、パートナ・プロバイダに新しいシングル・サインオンのサービスURLを知らせる必要があります。

注意:
Liberty 1.xのサポートは非推奨です。

この移行を容易にするために、Oracle Identity Federation 11gには、SHAREidサービスURLとの下位互換性を可能にする個別モジュールが用意されています。このモジュールは、Oracle Identity Federationとのデプロイが可能なJ2EEアプリケーションです。このモジュールにより、ShareID/Oracle Identity Federation 10gのサービスURLのリクエストが処理され、そのリクエストはOracle Identity Federation 11gの対応するサービスURLにリダイレクトまたは転送されます。

注意:
SAML1xプロトコルの場合、10gでは、認証リクエストの送信時に「METHOD」問合せパラメータを希望のプロファイルに設定することによって、認証レスポンス・プロファイルのバインディングを設定できました。この機能は11gではサポートされていないため、希望のプロファイルのバインディングを使用して認証レスポンスを送信するようにIdPを構成する必要があります。

手順

ShareIDプロキシを設定するには、次の手順を実行します。

注意:
付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」のようにプロキシが構成されている場合は、oif.confファイルを変更して、/shareid URLがOracle WebLogic Serverに転送されるようにする必要があります。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項

1. Oracle WebLogic Server管理コンソールで、「デプロイメント」ページに移動します。

2. 「ロックして編集」をクリックします。

3. 「インストール」をクリックします。

4. shareidupdate.earファイルの場所($ORACLE_HOME/fed/install)に移動します。

5. 「次へ」をクリックします。

6. 「Install this deployment as an application」を選択してから「Next」をクリックします。

7. 管理対象サーバーの名前を選択して、「次へ」をクリックします。

8. 「セキュリティ」セクションで「詳細」を選択します。

9. 「終了」をクリックします。

10. 「変更の適用」をクリックします。

11. 「デプロイメント」ページに戻って、「shareidupdate」という新しいアプリケーションを検索します(注意: アプリケーションが最初の10エントリに表示されていない場合は、「次へ」をクリックしてください)。

12. shareidupdateアプリケーションの状態が「アクティブ」と表示されていない場合は、アプリケーションを選択し、「起動」→「すべてのリクエストを処理」をクリックし、「はい」をクリックします。「デプロイメント」ページでshareidupdateアプリケーションを検索すると、今度は状態が「アクティブ」として表示されるはずです。

デフォルトでは、shareidupdateプロキシは、着信プロトコル(HTTPまたはHTTPS)、サーバー名、およびサーバー・ポートを、メッセージのリダイレクト先のプロトコル、サーバー名、およびサーバー・ポートとして使用します。プロキシ・サーバーを使用する場合などには、デフォルト値以外の使用も検討してください。

これらの値を設定する手順は、次のとおりです、

- shareidupdate web.xmlファイルを見つけます。これは、次のパスのサブフォルダにあるはずです。

DOMAIN_HOME/servers/SERVER_NAME/tmp/_WL_user/shareidupdate

- プロパティIsSecure、ServerName、ServerPortを使用しているサーブレットに追加します。(注意: 使用するプロトコルがHTTPSの場合は、IsSecureをtrueに、HTTPの場合は、falseに設定します。)

- 変更を保存して、アプリケーションを再起動します。

たとえば、<servlet>要素には次のような要素が含まれます。

<init-param>
<param-name>IsSecure</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>ServerPort</param-name>
<param-value>7777</param-value>
</init-value>

6.16 SPモードでの属性および名前IDによるユーザーのマッピング

Oracle Identity FederationがSPとして動作している場合、フェデレーション・レコードを使用せずに、アサーションに格納されている属性と名前識別子の値に基づいてユーザーを検索できます。

アサーションをユーザー・レコードにマップする際にフェデレーテッド・アイデンティティを使用するよう構成されていない場合、Oracle Identity Federation/SPは、着信アサーションに格納されている名前IDと属性を使用して、リポジトリのユーザーをマップします。ユーザー・レコードが見つかった場合、Oracle Identity Federation/SPは、IDおよびアクセス管理フレームワーク内にそのユーザーの認証済セッションを作成し、ユーザーを最終のターゲットURLにリダイレクトします。

このフローではフェデレーション・レコードを使用しないため、Oracle Identity Federationをサービス・プロバイダとして使用するようにフェデレーション・データ・ストアを構成する必要はありません。

このフローでOracle Identity Federationがユーザーを検索できなかった場合は、デフォルトの動作として、ユーザーには401 Unauthorizedエラーが返ります。ユーザーのリダイレクト先を認証エンジンに変更するようOracle Identity Federationを構成することにより、ユーザー・アカウントのプロビジョニングなど、カスタムの是正措置を開始することができます。この動作は、「ユーザー・マッピング失敗時のエラー」プロパティで実装します。第6.16.2項「Oracle Identity Federationの構成」の「マッピングに失敗した場合」というタイトルの手順を参照してください。

認証エンジンからOracle Identity Federationに戻る際にも、依然としてユーザーをマップできない場合は、最終的に401が返されます。

制限事項

次の制限に注意してください。

- Oracle Identity Federation/SPは、フェデレーテッド・アイデンティティを使用せずにアサーションをマップするよう構成されている場合、フェデレーション・レコードが格納されないため、Fusion Middleware Controlの「アイデンティティ・フェデレーション」セクションで使用できるアカウント・リンク情報はありません。

- また、名前識別子更新プロファイルおよびフェデレーション終了プロファイルは完了しません。そのため、ピアIdPがこのプロファイルのいずれかのメッセージを送信すると、Oracle Identity Federation/SPはフェデレーション・レコードが見つからなかったことを示すエラー・メッセージを返します。

この項は次のトピックで構成されています。

- ユーザーの検索

- Oracle Identity Federationの構成

- 例1: フェデレーテッド・アイデンティティを使用しない場合のSAML 2.0の名前IDによるアサーション・マッピング

- 例2: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる簡単なアサーション・マッピング

- 例3: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる複雑なアサーション・マッピング

- 例4: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せと名前IDマッピングによるアサーション・マッピング

- 例5: フェデレーテッド・アイデンティティを使用しない場合の特定のIdPのアサーション・マッピング

6.16.1 ユーザーの検索

リポジトリ内のユーザー・レコードを検索する場合、次の2つのオプションがあります。

- 名前IDフォーマット・マッピングの使用。名前IDはユーザー属性にリンクされます。

- LDAP/SQL問合せの使用。問合せにはアサーションに格納される名前IDと属性が含まれます。

どちらのオプションも有効な場合、Oracle Identity Federation/SPは、最初に名前IDマッピング検索を使用し、結果が戻らなかった場合はLDAP/SQL問合せフローを使用します。

問合せに含まれるプレースホルダは、アサーションに含まれる属性と名前IDの値で置き換えられます。プレースホルダには%NAME%フォーマットが使用され、Oracle Identity Federation/SPはNAMEを次のもので置き換えます。

- アサーションに含まれる属性を参照する属性名。問合せの作成時に、Oracle Identity Federation/SPは、%AttributeName%をAttributeNameで参照される属性の値で置き換えます。

注意:
アサーションに含まれる属性は、属性マッピング・モジュールによって、リモート・プロバイダ用に構成されている属性名/値にマップされます。属性名はこのリストの属性を参照する必要があります。

- orafed-nameid-value - このプレースホルダが名前IDの値で置き換えられることを示します。

- orafed-nameid-qualifier - このプレースホルダが名前ID識別子で置き換えられることを示します。

- orafed-nameid-format - このプレースホルダが名前IDフォーマットで置き換えられることを示します。

- orafed-providerid - このプレースホルダがピア・プロバイダIDで置き換えられることを示します。

6.16.2 Oracle Identity Federationの構成

SAML 2.0モジュールでは、フェデレーテッド・アイデンティティの使用がサポートされますが、SAML 1.xモジュールではサポートされません。

ユーザー・マッピング処理でアサーションのフェデレーテッド・アイデンティティを使用するようOracle Identity Federationを構成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択または選択解除します。

名前IDを使用してユーザーをマップする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「名前IDによるユーザーのマップ」を選択します。

4. 検索手順で使用されるようにユーザー・レコードの名前IDフォーマットと属性を構成します。

LDAP/RDBMS問合せを使用してユーザーをマップする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「属性問合せによるユーザーのマップ」を選択します。

4. 検索手順で使用されるLDAPまたはSQL問合せを入力します。

マッピングに失敗した場合

マッピングに失敗した場合、401エラー・コードを返すかわりに認証エンジンを呼び出すようOracle Identity Federationを構成できます。サーバーを構成するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「ユーザー・マッピング失敗時のエラー」を選択解除して、認証エンジンを呼び出すことにより、アサーションの内容と属性にアクセスできるようになります。

注意:
アサーションに含まれる属性は、属性マッピング・モジュールによって、リモート・プロバイダ用に構成されている属性名/値にマップされます。属性名はこのリストの属性を参照する必要があります。

6.16.3 例1: フェデレーテッド・アイデンティティを使用しない場合のSAML 2.0の名前IDによるアサーション・マッピング

この例では、Oracle Identity Federation/SPはアサーションに含まれる名前IDを使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。名前IDのフォーマットはemailAddressです。また、検索ではLDAPユーザー・レコードのmail属性を使用します。

名前IDマッピング機能を使用してユーザーを検索するようにサーバーを構成します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択解除します。

4. 「属性問合せによるユーザーのマップ」を選択解除します。

5. 「名前IDによるユーザーのマップ」を選択します。

6. 電子メール・アドレス名前IDフォーマットを有効にして、ユーザー・レコードで電子メール・アドレスが格納されている属性を入力します(通常、LDAPサーバーの場合はmail)。

7. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

8. 変更を適用します。

6.16.4 例2: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる簡単なアサーション・マッピング

この例では、Oracle Identity Federation/SPはアサーションに含まれる名前IDを使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。名前IDのフォーマットはemailAddressです。また、検索ではLDAPユーザー・レコードのmail属性を使用します。

LDAP/SQL問合せ機能を使用してユーザーを検索するようにサーバーを構成します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択解除します。

4. 「属性問合せによるユーザーのマップ」を選択します。

5. 「属性問合せ」フィールドに、LDAP問合せ「(&(mail=%orafed-nameid-value%))」を入力します。

6. 「名前IDによるユーザーのマップ」を選択解除します。

7. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

8. 変更を適用します。

6.16.5 例3: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せによる複雑なアサーション・マッピング

この例では、Oracle Identity Federation/SPはアサーションに含まれるSAMLの電子メール・アドレスと姓の属性を使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。

ローカル属性mailおよびsnはLDAPユーザー・レコードから取得されます。アサーションの属性は、emailおよびlastnameとして参照されます。Oracle Identity Federation/SPは属性名マッピングを使用するように構成されていません。そのため、LDAP問合せではSAMLアサーションに含まれる属性名が使用されます。属性名マッピングが構成されている場合は、LDAP問合せで属性名マッピングの名前が使用されます(詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください)。

LDAP/SQL問合せ機能を使用してユーザーを検索するようにサーバーを構成します。次の構成手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択解除します。

4. 「属性問合せによるユーザーのマップ」を選択します。

5. 「属性問合せ」フィールドに、LDAP問合せ「(&(mail=%email%)(sn=%lastname%))」を入力します。

6. 「名前IDによるユーザーのマップ」を選択解除します。

7. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

8. 変更を適用します。

6.16.6 例4: フェデレーテッド・アイデンティティ使用しない場合のLDAP/SQL問合せと名前IDマッピングによるアサーション・マッピング

この例では、Oracle Identity Federation/SPは名前IDに含まれる電子メール・アドレスを使用して、ユーザーを検索します。処理が失敗した場合は、アサーション内のSAMLの姓属性を使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。このとき、LDAPユーザー・レコードのローカル属性mailおよびsnを使用します。

名前IDマッピングおよびLDAP/SQL問合せの両方を使用してユーザーを検索するようにサーバーを構成します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択解除します。

4. 「属性問合せによるユーザーのマップ」を選択します。

5. 「属性問合せ」フィールドに、LDAP問合せ「(&(sn=%lastname%))」を入力します。

6. 「名前IDによるユーザーのマップ」を選択します。

7. 電子メール・アドレス名前IDフォーマットを有効にして、ユーザー・レコードで電子メール・アドレスが格納されている属性を入力します(通常、LDAPサーバーの場合はmail)。

8. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

9. 変更を適用します。

6.16.7 例5: フェデレーテッド・アイデンティティを使用しない場合の特定のIdPのアサーション・マッピング

Oracle Identity Federation/SPで、ピア・アイデンティティ・プロバイダに固有の属性ベースの認証構成が必要な場合、フェデレーション・リストのIdPのエントリに設定情報を格納する必要があります。

この例では、Oracle Identity Federation/SPを設定して、http://idp.comで参照されるIdPに属性ベースの認証を設定します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「フェデレーション」の順に移動します。

3. アイデンティティ・プロバイダを選択して、「更新」をクリックします。

4. 「Oracle Identity Federation設定」タブをクリックします。

5. 「サービス・プロバイダ/リクエスタ設定」セクションを開いて、アサーション設定に移動します。

6. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択解除します。

7. 「属性問合せによるユーザーのマップ」を選択します。

8. 「属性問合せ」フィールドに、LDAP問合せ「(&(mail=%email%)(sn=%lastname%))」を入力します。

9. 「名前IDによるユーザーのマップ」を選択解除します。

10. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

11. 変更を適用します。

6.17 属性問合せマッピングに基づいた自動アカウント・リンク

SP側の自動アカウントにより、サービス・プロバイダはユーザーへのアサーションに含まれるアイデンティティを直接マップできます。

Oracle Identity Federationがサービス・プロバイダとして動作しており、フェデレーテッド・アイデンティティを使用してSAML 2.0着信アサーションをマップするように構成されている場合、アサーションで受信した属性と名前識別子に基づいてユーザーが検索され、自動的にフェデレーション・レコードが作成されます。

この項では、アカウント・リンクに関連するトピックについて説明します。

- ユーザーの検索

- Oracle Identity Federationの構成

- 例1: SAML 2.0の名前IDマッピングによる自動アカウント・リンク

- 例2: LDAP/SQL問合せによる簡単な自動アカウント・リンク

- 例3: LDAP/SQL問合せによる複雑な自動アカウント・リンク

- 例4: LDAP/SQL問合せと名前IDマッピングによる自動アカウント・リンク

- 例5: 特定のIdPへの属性問合せによる自動アカウント・リンク

6.17.1 ユーザーの検索

フェデレーテッド・アイデンティティを使用するよう構成されており、自動アカウント・リンクが有効な場合、管理者は次の2つの方法でリポジトリ内のユーザー・レコードを検索できます。

- 名前IDフォーマット・マッピングの使用。名前IDはユーザー属性にリンクされます。これは既存のマッピングを使用します。

- LDAP/SQL問合せの使用。問合せにはアサーションに格納される名前IDと属性が含まれます。

どちらのオプションも有効な場合、Oracle Identity Federation/SPは、最初に名前IDマッピング検索を使用し、結果が戻らなかった場合はLDAP/SQL問合せフローを使用します。このフローで、Oracle Identity Federation/SPがユーザー・レコードを見つけられなかった場合、サーバーはユーザーの資格証明を要求します。

管理者は、ユーザーの検索時に使用するLDAP/SQL問合せをOracle Identity Federation構成で指定します。問合せに含まれるプレースホルダは、アサーションに含まれる属性と名前IDの値で置き換えられます。プレースホルダには%NAME%フォーマットが使用され、Oracle Identity Federation/SPはNAMEを次のもので置き換えます。

- アサーションに含まれる属性を参照する属性名。問合せの作成時に、Oracle Identity Federation/SPは、%AttributeName%をAttributeNameで参照される属性の値で置き換えます。

注意:
アサーションに含まれる属性は、属性マッピング・モジュールによって、リモート・プロバイダ用に構成されている属性名/値にマップされます。属性名はこのリストの属性を参照する必要があります。

- orafed-nameid-value - このプレースホルダは名前IDの値で置き換えられます。

- orafed-nameid-qualifier - このプレースホルダは名前ID識別子で置き換えられます。

- orafed-nameid-format - このプレースホルダは名前IDフォーマットで置き換えられます。

- orafed-providerid - このプレースホルダはピア・プロバイダIDで置き換えられます。

6.17.2 Oracle Identity Federationの構成

SAML 2.0モジュールのみで、フェデレーテッド・アイデンティティの使用がサポートされます。SAML 1.xモジュールではサポートされません。

ユーザー・マッピングでアサーションのフェデレーテッド・アイデンティティを使用するようOracle Identity Federationを構成し、自動アカウント・リンク処理を有効にする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

4. 「自動アカウント・リンクの有効化」を選択します。

名前IDを使用してユーザーをマップする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「名前IDによるユーザーのマップ」を選択します。

4. 名前IDフォーマットを有効にし、ユーザー・レコードの属性が自動アカウント・リンク処理の検索手順で使用されるように構成します。

LDAP/RDBMS問合せを使用してユーザーをマップする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「属性問合せによるユーザーのマップ」を選択します。

4. 自動アカウント・リンク処理の検索手順で使用されるLDAPまたはSQL問合せを入力します。

6.17.3 例1: SAML 2.0の名前IDマッピングによる自動アカウント・リンク

この例では、Oracle Identity Federation/SPはアサーションに含まれる名前IDを使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。名前IDのフォーマットはemailAddressです。また、検索ではLDAPユーザー・レコードのmail属性を使用します。

自動アカウント・リンクで、名前IDマッピング機能を使用してユーザーを検索するようにサーバーを構成します。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

4. 「自動アカウント・リンクの有効化」を選択します。

5. 「属性問合せによるユーザーのマップ」を選択解除します。

6. 「名前IDによるユーザーのマップ」を選択します。

7. 電子メール・アドレス名前IDフォーマットを有効にして、ユーザー・レコードで電子メール・アドレスが格納されている属性を入力します(通常、LDAPサーバーの場合はmail)。

8. 変更を適用します。

6.17.4 例2: LDAP/SQL問合せによる簡単な自動アカウント・リンク

この例では、Oracle Identity Federation/SPはアサーションに含まれる名前IDを使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索し、フェデレーション・レコードを自動的に作成します。名前IDのフォーマットはemailAddressです。また、検索ではLDAPユーザー・レコードのmail属性を使用します。

LDAP/SQL問合せ機能を使用してユーザーを検索するようにサーバーを構成します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

4. 「自動アカウント・リンクの有効化」を選択します。

5. 「属性問合せによるユーザーのマップ」を選択します。

6. 属性問合せを「(&(mail=%orafed-nameid-value%))」に設定します。

7. 「名前IDによるユーザーのマップ」を選択解除します。

8. 変更を適用します。

6.17.5 例3: LDAP/SQL問合せによる複雑な自動アカウント・リンク

この例では、Oracle Identity Federation/SPはアサーションに含まれるSAMLの電子メール・アドレスと姓の属性を使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索し、フェデレーション・レコードを自動的に作成します。LDAPユーザー・レコードのローカル属性mailおよびsnが使用されます。アサーションの属性は、emailおよびlastnameとして参照されます。

Oracle Identity Federation/SPは属性名マッピングを使用するように構成されていません。そのため、LDAP問合せではSAMLアサーションに含まれる属性名が使用されます。属性名マッピングが構成されている場合は、LDAP問合せで属性名マッピングの名前が使用されます(属性名マッピングの詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください)。

LDAP/SQL問合せ機能を使用してユーザーを検索するようにサーバーを構成します。次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

4. 「自動アカウント・リンクの有効化」を選択します。

5. 「属性問合せによるユーザーのマップ」を選択します。

6. 属性問合せを「(&(mail=%email%)(sn=%lastname%))」に設定します。

7. 「名前IDによるユーザーのマップ」を選択解除します。

8. 変更を適用します。

6.17.6 例4: LDAP/SQL問合せと名前IDマッピングによる自動アカウント・リンク

この例では、Oracle Identity Federation/SPは名前IDに含まれる電子メール・アドレスを使用して、ユーザーを検索し、フェデレーション・レコードを作成します。処理に失敗した場合、Oracle Identity Federation/SPはアサーションに含まれるSAMLの姓の属性を使用して、LDAPユーザー・データ・ストアでローカル・ユーザーを検索します。LDAPユーザー・レコードのローカル属性mailおよびsnが使用されます。

名前IDマッピング機能およびLDAP/SQL問合せ機能を使用してユーザーを検索するようにサーバーを構成します。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→SAML 2.0→「アサーション設定」の順に移動します。

3. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

4. 「自動アカウント・リンクの有効化」を選択します。

5. 「属性問合せによるユーザーのマップ」を選択します。

6. 属性問合せを「(&(sn=%lastname%))」に設定します。

7. 「名前IDによるユーザーのマップ」を選択します。

8. 電子メール・アドレス名前IDフォーマットを有効にして、ユーザー・レコードで電子メール・アドレスが格納されている属性を入力します(通常、LDAPサーバーの場合はmail)。

6.17.7 例5: 特定のIdPへの属性問合せによる自動アカウント・リンク

Oracle Identity Federation/SPで、ピア・アイデンティティ・プロバイダに固有の属性ベースの認証構成が必要な場合、フェデレーション・リストのIdPのエントリに設定情報を格納する必要があります。

この例では、Oracle Identity Federation/SPでフェデレーテッド・アイデンティティを使用し、http://idp.comで参照されるIdPへの属性問合せによって自動アカウント・リンクを設定します。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「フェデレーション」の順に移動します。

3. アイデンティティ・プロバイダを選択して、「更新」をクリックします。

4. 「Oracle Identity Federation設定」タブをクリックします。

5. 「サービス・プロバイダ/リクエスタ設定」セクションを開いて、アサーション設定に移動します。

6. 「フェデレーテッド・アイデンティティによるユーザーのマップ」を選択します。

7. 「自動アカウント・リンクの有効化」を選択します。

8. 「属性問合せによるユーザーのマップ」を選択します。

9. 「属性問合せ」フィールドに、LDAP問合せ「(&(mail=%email%)(sn=%lastname%))」を入力します。

10. 「名前IDによるユーザーのマップ」を選択解除します。

11. 「ユーザー・マッピング失敗時のエラー」を選択します。これにより、ユーザーが見つからなかった場合に、Oracle Identity Federationからブラウザに401エラーが返るようになります。

12. 変更を適用します。

6.18 シングル・サインオンでのユーザー・オプトインおよびオプトアウト

Oracle Identity Federation IdPを構成することにより、そのユーザーにフェデレーテッド・シングル・サインオンの実行権限が付与(または拒否)されているかどうかを、ユーザーのディレクトリ・レコードの属性値に基づいて判断できます。

承諾が取得されている場合、そのユーザーがOracle Identity Federation/IdP、またはOracle Identity Federationに統合されているIDおよびアクセス管理(IAM)フレームワーク内で認証されると、SSO処理が自動的に実行されます。承諾が取得されていない場合は、そのユーザーがIAMドメインのOracle Identity Federationですでに認証されていても、フェデレーションSSO処理が行われるたびに、Oracle Identity Federation/IdPはユーザーの資格証明を要求する必要があります。

注意:
この項では、Oracle Identity Federation/IdPはアイデンティティ・プロバイダとして動作しているOracle Identity Federationを意味します。

このセクションの内容は次のとおりです。

- 操作のモード

- Oracle Identity Federationの構成

- 例1: オフ・モード

- 例2: オプトイン・モード

- 例3: オプトアウト・モード

- 例4: 特定のIdPに対するオプトイン・モード

6.18.1 操作のモード

Oracle Identity Federation/IdPでは、この機能を次の3つのモードで実装できます。

1. オフ - オプトイン/オプトアウト機能は実行されません。

2. オプトイン - オプトイン/オプトアウトのユーザー属性が、管理者が設定した値と一致する場合、Oracle Identity Federation/IdPはフェデレーションSSO処理でユーザーの再認証を実行しません。一致しない場合は、再認証を実行します。

3. オプトアウト - オプトイン/オプトアウトのユーザー属性が、管理者が設定した値と一致する場合、Oracle Identity Federation/IdPはフェデレーションSSO処理でユーザーの再認証を実行します。一致しない場合は、再認証を実行しません。

6.18.2 Oracle Identity Federationの構成

オプトイン/オプトアウトを使用するようにOracle Identity Federationを構成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

3. オプトイン/オプトアウトモードを選択します。

- オフ: オプトイン/オプトアウト機能は実行されません。

- オプトイン: オプトイン・モードがアクティブです。

- オプトアウト: オプトアウト・モードがアクティブです。

4. モードを「オプトイン」または「オプトアウト」に設定する場合は、ユーザー・レコードから取得する属性を参照するオプトイン/アウト・ユーザー属性を入力します。この値は、管理者が設定する値と比較されます。

5. モードを「オプトイン」または「オプトアウト」に設定する場合は、管理者によって設定され、ユーザー属性との比較に使用される値を保持するオプトイン/アウト属性値を入力します。

6.18.3 例1: オフ・モード

この例では、オプトイン/オプトアウト機能がオフになっているため、Oracle Identity Federation/IdPでフェデレーション・レコードが作成されるときに、ユーザーの資格証明が要求されることはありません。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

3. オプトイン/オプトアウトモードで「オフ」を選択します。

4. 変更を適用します。

6.18.4 例2: オプトイン・モード

この例では、オプトイン/オプトアウト機能がオプトインに設定されており、ユーザー設定が含まれる属性はfedrecordcreationで、ユーザーがオプトインしたことを示す値はagreedです。

Oracle Identity Federation/IdPはフェデレーションの作成処理時に、ユーザーのfedrecordcreation属性値がagreedと異なる場合にのみ、ユーザーの資格証明を再度要求します。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

3. オプトイン/オプトアウトモードで「オプトイン」を選択します。

4. 「オプトイン/アウト・ユーザー属性」をfedrecordcreationに設定します。

5. 「オプトイン/アウト属性値」をagreedに設定します。

6. 変更を適用します。

6.18.5 例3: オプトアウト・モード

この例では、この機能をoptoutに設定し、ユーザー設定が含まれる属性をfedrecordcreation、ユーザーがオプトインしたことを示す値をdisallowedにします。

Oracle Identity Federation/IdPはフェデレーションのを作成処理時に、ユーザーのfedrecordcreation属性値がdisallowedと一致する場合にのみ、ユーザーの資格証明を再度要求します。

次の手順を実行して、Oracle Identity Federation/SPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「アイデンティティ・プロバイダ」の順に移動します。

3. オプトイン/オプトアウトモードで「オプトアウト」を選択します。

4. 「オプトイン/アウト・ユーザー属性」をfedrecordcreationに設定します。

5. 「オプトイン/アウト属性値」をdisallowedに設定します。

6. 変更を適用します。

6.18.6 例4: 特定のIdPに対するオプトイン・モード

Oracle Identity Federation/IdPで、ピア・サービス・プロバイダに固有のオプトイン・モード構成が必要な場合、フェデレーション・リストのSPのエントリに設定情報を格納する必要があります。

この例では、http://sp.comで参照されるSPに対して、オプトイン/オプトアウト機能をオプトインに設定し、ユーザー設定が含まれる属性をfedrecordcreation、ユーザーがオプトインしたことを示す値をagreedにします。

Oracle Identity Federation/IdPはフェデレーションの作成処理時に、ユーザーのfedrecordcreation属性値がagreedと異なる場合にのみ、ユーザーの資格証明を再度要求します。

次の手順を実行して、Oracle Identity Federation/IdPを構成します。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「フェデレーション」の順に移動します。

3. サービス・プロバイダを選択して、「更新」をクリックします。

4. 「Oracle Identity Federation設定」タブをクリックします。

5. 「アイデンティティ・プロバイダ/認証局設定」セクションを開きます。

6. オプトイン/オプトアウトモードで「オプトイン」を選択します。

7. 「オプトイン/アウト・ユーザー属性」をfedrecordcreationに設定します。

8. 「オプトイン/アウト属性値」をagreedに設定します。

9. 変更を適用します。

6.19 アサーション処理時のユーザー・マッピングのバイパス

Oracle Identity Federationがサービス・プロバイダとして動作している場合にこの機能を使用すると、アサーションに含まれる情報に基づいたユーザーの検索は行われません。かわりに、SP統合モジュールにアサーションの内容が直接送り戻され、このモジュールによってユーザー・マッピング・フローが実装されます。

マッピングをバイパスする(つまり、アサーションで識別されているプリンシパルをローカル・ユーザーにマップしない)ようにOracle Identity Federation/SPを構成した場合、Oracle Identity Federationは次のことを実行します。

- Oracle Identity Federation管理コンソールの「サービス・プロバイダ」セクションで指定されている匿名ユーザーに対してOracle Identity Federationセッションを作成します。これは、サーバーがそのサーバーやピア・プロバイダで認証されるユーザーを認識する必要がある場合(たとえば、ログアウト処理など)に必要です。
そのため、Fusion Middleware Controlの「Oracle Identity Federation」ページにある「匿名ユーザーID」の設定は必須になります。

- 第10.4.2.3項「サービスの実装」の「Oracle Identity Federationのアサーション処理」で記述されているように、名前ID、属性などの情報をSP統合モジュールに送り戻します。

6.19.1 Oracle Identity Federationの構成

着信アサーションをユーザー・レコードにマップする(またはマップしない)ようにOracle Identity Federationを構成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「管理」→「サービス・プロバイダ」→「共通」の順に移動します。

3. 「アサーションのユーザー・アカウントへのマップ」を選択して、着信アサーションをユーザー・レコードにマップするようにOracle Identity Federationを構成します。アサーションをマップしないようにするには選択を解除します。

4. 変更を適用します。

6.20 名前IDマッピングのパートナ単位での上書き

Oracle Identity Federation管理者は、ローカル・ユーザー・ディレクトリ属性に対する名前IDフォーマットのマッピングをパートナ単位で上書きすることができます。

この機能をコマンドラインで構成するには、次の手順を実行します。

1. 第9章「Oracle Identity Federationコマンドライン・ツール」の説明に従って、スクリプト環境を設定します。

2. プラットフォームに適したコマンドを使用してWLSTシェルを呼び出します。
Windows

IDM_ORACLE_HOME\common\bin\wlst.cmd

Linux

IDM_ORACLE_HOME/common/bin/wlst.sh

3. 使用する名前フォーマットに応じて、次のいずれかのコマンドを入力します。

- setFederationProperty('SPproviderID','nameformatemail','attribute-name','string')

名前フォーマットが「電子メール・アドレス」の場合

- setFederationProperty('SPproviderID','nameformatx500','attribute-name','string')

名前フォーマットが「X509サブジェクト名」の場合

- setFederationProperty('SPproviderID','nameformatunspecified','attribute-name','string')

名前フォーマットが「未指定」の場合

- setFederationProperty('SPproviderID','nameformatkerberos','attribute-name','string')

名前フォーマットが「Kerberos」の場合

- setFederationProperty('providerID','nameformatwindows','attribute-name','string')

名前フォーマットが「Windowsドメイン修飾名」の場合

- setFederationProperty('providerID','nameformatcustom','attribute-name','string')

名前フォーマットが「カスタム」の場合

注意:
フェデレーション・ストアが設定されていて、そのユーザーのフェデレーション・レコードが存在する場合は、フェデレーション・レコードのnameidが使用されます。

6.21 アサーションのオーディエンス制限の構成

アサーションを使用して情報を交換する場合、アイデンティティ・プロバイダや属性認証局などのSAMLオーソリティで、アサーションが有効になる条件を設定できます。一般的には次のような条件があります。

- アサーションが有効になるまでの期間。

- アサーションが無効になる時点。

- アサーションを処理できるプロバイダのリスト。アサーションのAudienceRestictionCondition要素にリストされているプロバイダのみが、そのアサーションを使用できます。

SAML仕様では、AudienceRestictionConditionはAudience要素のリストとして定義されており、それぞれはアサーションを処理できるプロバイダを参照しています。

デフォルトでは、Oracle Identity Federationは、アサーションの生成時にAudienceRestrictionCondition要素を作成し、次のルールを使用してアサーションの受信者を組み込みます。

- SAML 1.xプロトコル交換の場合は、Audienceをサービス・プロバイダのアサーション・コンシューマ・サービスURLとして設定します。

- SAML 2.0プロトコル交換の場合は、Audienceをサービス・プロバイダ/属性リクエスタのProviderIDとして設定します。

- SAMLアサーションを使用するWS-Fedプロトコル交換の場合は、Audienceをサービス・プロバイダのProviderIDとして設定します。

Oracle Identity Federationは、アサーションを受信して処理する際に、デフォルトではProviderIDまたはアサーションがポストされたURLを使用して、AudienceRestrictionCondition(存在する場合)を検証します。

デプロイメント・シナリオによっては、AudienceRestrictionCondition要素の生成および検証を無効にする必要がある場合があります。これは、プロトコル・レベル(SAML 1.0、SAML 1.1またはSAML 2.0アサーション)または信頼できるプロバイダ・レベルで実行できます。

SAML 1.x/SAML 2.0アサーションでAudienceRestrictionConditionの生成および処理をグローバル・レベルで制御するようにOracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、次のようにします。

- idpsaml10、idpsaml11またはidpsaml20グループのaudiencerestrictionenabledブール型プロパティをtrue(デフォルト)に設定して、SAML 1.0、SAML 1.1またはSAML 2.0アサーションの作成におけるAudienceRestrictionConditionの生成を有効にします。

setConfigProperty('idpsaml11', 'audiencerestrictionenabled', 'true', 'boolean')

条件の生成を無効にするには、falseに設定します。

- spsaml10、spsaml11またはspsaml20グループのaudiencerestrictionenabledブール型プロパティをtrue(デフォルト)に設定して、SAML 1.0、SAML 1.1またはSAML 2.0アサーションの処理におけるAudienceRestrictionConditionの検証を有効にします。

setConfigProperty('spsaml11', 'audiencerestrictionenabled', 'true', 'boolean')

条件の検証を無効にするには、falseに設定します。

特定の信頼できるプロバイダに対してAudienceRestrictionConditionの生成および処理が有効になるようにOracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、REMOTE_PROVIDER_IDで参照される信頼できるプロバイダのaudiencerestrictionenabledブール型プロパティをtrueに設定します。

setFederationProperty(REMOTE_PROVIDER_ID, 'audiencerestrictionenabled', 'true', 'boolean')

条件の生成および処理を無効にするには、プロパティをfalseに設定します。

Oracle Identity Federationを構成して、次のようにカスタム文字列を使用することもできます。

- Oracle Identity Federation/IdPによるアサーションの作成時
Oracle Identity Federationは、構成で指定されているカスタム文字列を使用してAudienceRestrictionCondition要素を移入します。

- Oracle Identity Federation/SPによるアサーションの処理時
Oracle Identity Federationは、AudienceRestrictionCondition要素(存在する場合)を、構成で指定されているカスタム文字列と比較して検証します。

SAML 1.x/SAML 2.0アサーションのAudienceRestrictionConditionをグローバル・レベルで検証する場合に、特定のオーディエンス値を使用するようにOracle Identity Federationを構成するには、インスタンスのWLSTスクリプト環境を入力してから、spsaml10、spsaml11またはspsaml20グループのaudiencerestrictionvalue文字列プロパティを、SAML 1.0、SAML 1.1またはSAML 2.0アサーションの処理時にOracle Identity FederationがAudienceRestrictionConditionの検証で使用するカスタム値に設定します。

setConfigProperty('spsaml11', 'audiencerestrictionvalue', 'someglobalvalue', 'string')

audiencerestrictionvalueを空の文字列値に設定した場合、Oracle Identity Federation/SPはAudienceRestrictionCondition要素を前述のとおりに検証します。

特定の信頼できるプロバイダに対してAudienceRestrictionConditionの生成時/処理時に特定のAudience値を使用するようにOracle Identity Federationを構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力してから、REMOTE_PROVIDER_IDで参照される信頼できるプロバイダのaudiencerestrictionvalue文字列プロパティを、アサーションの作成時/処理時に条件を生成/検証する際に使用するカスタム文字列に設定します。

setFederationProperty(REMOTE_PROVIDER_ID, 'audiencerestrictionvalue', 'customvalue', 'string')

audiencerestrictionvalueを空の文字列値に設定した場合、Oracle Identity Federation/SPはAudienceRestrictionCondition要素を前述のとおりに移入/検証します。

6.22 証明書パス検証

Oracle Identity Federationには証明書検証モジュール(第5.10.3項「セキュリティおよび信頼 - 信頼できるCAおよびCRL」を参照)が用意されています。このモジュールは、XMLデジタル署名検証に使用される任意の証明書を、管理者がアップロードした信頼できるCAおよびCRLの証明書を使用して検証します。

このモジュールはJRE CertPathValidation APIと統合し、JVMで構成されているデフォルトのCertPathValidationモジュールを使用して証明書を検証します。デフォルトのCertPathValidationモジュールはSunの実装です。Oracle Identity Federationでは、Sunのモジュールが提供するオンライン証明書ステータス・プロトコル(OCSP)およびCRL配布ポイント(CDP)の機能を利用できます。

証明書検証を管理するには、次のプロパティを使用します。

- Fusion Middleware ControlでOracle Identity Federationサーバー・インスタンス→「セキュリティおよび信頼」→「信頼できるCAおよびCRL」セクションの順に移動します。

- 「認証検証の有効化」ボックスを選択すると、Oracle Identity Federationで証明書検証が有効になります。

- 「信頼できる認証局(CA)」表には、CAの既知の信頼できる証明書がすべて表示されます。

- 「証明書失効リスト」表には、証明書の失効ステータスをチェックするために使用されるCRLが表示されます。

- serverconfig構成グループのcertpathvalidationenabledブール型プロパティによって、検証モジュールを使用するかどうかを次のように指定します。

- falseは、「信頼できる認証局(CA)」表および「証明書失効リスト」表に基づいて、Oracle Identity Federationの内部証明書検証モジュールが使用されることを意味します。

- trueは、JRE CertPathValidationモジュールが使用されることを意味します。このモジュールは、「信頼できる認証局(CA)」表の内容とともにブートストラップされ、信頼できるCAの基準となります。

- serverconfig構成グループのcertpathvalidationcrlenabledブール型プロパティには、JRE CertPathValidationモジュールで、「証明書失効リスト」表にリストされたCRLを使用して証明書の失効をチェックするかどうかを次のように指定します。

- falseを指定すると、JRE CertPathValidationモジュールでのCRL検証が無効になります。

- trueを指定すると、JRE CertPathValidationモジュールでのCRL検証が有効になります。

- serverconfig構成グループのcertpathvalidationocspenabledブール型プロパティには、Sun CertPathValidation実装のOCSPプラグインを有効にするかどうかを次のように指定します。

- falseを指定すると、OCSP検証が無効になります。

- trueを指定すると、OCSP検証が有効になります。

注意:

- OCSPプラグインを有効にするには、certpathvalidationcrlenabledをtrueに設定する必要があります。

- Sun CertPathValidationモジュールは、最初にOCSP検証を実行し、結果が不確定な場合はCRL失効チェック処理を実行します。

- serverconfig構成グループのcertpathvalidationocspurl文字列プロパティには、Sun CertPathValidationモジュールが検証のためにリクエストを送信するOCSPサーバーのURLを指定します。

注意:
OCSP機能を有効にするには、certpathvalidationocspenabledブール型プロパティをtrueに設定します。

- serverconfig構成グループのcertpathvalidationocspcertsubject文字列プロパティには、OCSPサーバーの証明書のサブジェクト名を指定します。

注意:

- 一致する証明書は、Oracle Identity Federationの信頼できるCA証明書ストアにも追加する必要があります。

- OCSP機能を有効にする場合は、certpathvalidationocspenabledブール型プロパティをtrueに設定してください。

- serverconfig構成グループのcertpathvalidationcdpenabledブール型プロパティには、CRL失効チェック処理の実行時に、Sun CertPathValidationモジュールでCDP拡張を使用するかどうかを指定します。

OCSPモジュールを有効にすると、Oracle Identity FederationによってJVMに次のJava Securityプロパティが設定されます。

- ocsp.enableがtrueに設定されます。

- ocsp.responderURLがOCSPサーバーのURLに設定されます。

- ocsp.responderCertSubjectNameがOCSPサーバーの証明書のサブジェクト名に設定されます。

関連項目:
これらのシステム・プロパティの詳細は、Java PKIプログラマーズ・ガイドの次の項を参照してください。
http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC

CDP機能を有効にすると、com.sun.security.enableCRLDP Javaシステム・プロパティがtrueに設定されます。

注意:
OCSP機能およびCDP機能を有効にする場合、デフォルトのCertPathValidationモジュールをSun実装に設定する必要があります(標準インストールのデフォルトではtrueです)。

6.23 認証リクエストを使用したACS URLの送信

場合によっては、SAML 2.0 IdPがSPに対して、Assertion Consumer Service (ACS) URLを認証リクエストの一部として送信するよう要求することがあります。

この機能を使用すると、ACS URLをSAML 2.0認証リクエストで送信するようにOracle Identity Federationを構成できます。このURLは、フェデレーションSSO処理の終了時にIdPによってユーザーがリダイレクトされる場所を参照します。デフォルトでは、この機能はfalse(ACS URLを送信しません)に設定されています。

この機能は、WLSTコマンドを使用して、SAML 2.0グローバル・レベルまたはSAML 2.0パートナ・レベルで構成できます。

この機能を構成するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

- 認証リクエストを使用してSAML 2.0グローバル・レベルでACS URLを送信するようにサーバーを構成するには、spsaml20グループのsendacsurlauthnrequestブール型プロパティをtrueに設定します。このURLを送信しない場合は、falseに設定します。次に例を示します。

setConfigProperty('spsaml20', 'sendacsurlauthnrequest', 'true', 'boolean')

- 認証リクエストを使用して特定のIdPパートナにACS URLを送信するようにサーバーを構成するには、そのパートナのsendacsurlauthnrequestブール型プロパティをtrueに設定します。そのパートナにこのURLを送信しない場合は、falseに設定します。次に例を示します。

setFederationProperty(REMOTE_IDP_PROVIDER_ID, 'sendacsurlauthnrequest','true', 'boolean')

6.24 OpenIDパートナとの統合

この項では、OpenIDパートナおよびリライイング・パートナと連携するようにOracle Identity Federationを構成する方法について説明します。この項の内容は次のとおりです。

- OpenIDプロバイダ(OP)との統合

- リライイング・パーティ(RP)との統合

- 属性の構成

6.24.1 OpenIDプロバイダ(OP)との統合

OpenIDプロバイダと統合するには、Oracle Identity Federationにパートナ情報をプロビジョニングして、特定の情報をフェデレーテッド・パートナに提供する必要があります。

6.24.1.1 OPパートナのプロビジョニング

OPパートナをプロビジョニングするには、次の手順を実行します。

1. パートナを作成するには、Fusion Middleware ControlでOracle Identity Federationサーバーを見つけて、「フェデレーション」ページに移動し、次の要素を指定します。

- OPのプロバイダID: この値は、そのOPとのフェデレーションSSOフロー開始時に(たとえば、/fed/sp/initiatesso URLなどで)使用されます。Oracle Identity FederationがOPである場合は、http(s)://hostname:port/fed/idp/openidv20のようにURLを入力します。

- プロトコルのバージョン: OpenID 2.0

- ロール: アイデンティティ・プロバイダ

2. 「信頼できるプロバイダ設定」タブで次の設定を使用してパートナを編集します。

- 検出URL: OPがXRDSメタデータを公開するURLです。Oracle Identity FederationがOPである場合は、http(s)://hostname:port/fed/idp/openidv20のようにURLを使用します。

- エンドポイントURL: 認証時にユーザーがOPでリダイレクトされるURLです。Oracle Identity FederationがOPである場合は、http(s)://hostname:port/fed/idp/openidv20のようにURLを使用します。

6.24.1.2 OPへのデータの提供

OPと統合する場合、Oracle Identity Federation/RPがフェデレーテッド・パートナに特定の情報を提供しなければならない場合があります。OPで、次のデータが必要になる場合があります。

- レルム: RPを識別するURLです。Oracle Identity Federation/RPのレルムURLは、http(s)://hostname:port/fed/sp/openidv20のようなURLになります。これは、Oracle Identity Federation/RP OpenIDプロバイダIDとしても動作します。

- エンドポイントURL: ユーザーが認証情報とともにOPからOracle Identity Federation/RPにリダイレクトされるURLです。Oracle Identity Federation/RPのエンドポイントURLは、http(s)://hostname:port/fed/sp/openidv20のようなURLになります。

6.24.2 リライイング・パーティ(RP)との統合

リライイング・パーティと統合するには、RPパートナをプロビジョニングして、特定の情報をRPに提供する必要があります。

6.24.2.1 RPパートナのプロビジョニング

Fusion Middleware Controlの「アイデンティティ・プロバイダ」ページの「OpenID 2.0」タブで「一般OpenIDサービス・プロバイダ」を作成していない場合は、任意のRPがOracle Identity Federation/OPとフェデレーテッドSSOを実行できるように、RPパートナをプロビジョニングする必要があります。

1. 「フェデレーション」ページで次の内容を指定して、パートナを作成します。

- RPのプロバイダID: RPレルム値です。そのRPとのフェデレーションSSOフロー開始時に(たとえば、/fed/idp/initiatesso URLなどで)使用されます。RP検出で、レルムURLからRP XRDSメタデータをダウンロードする際にも使用されます。Oracle Identity FederationがRPである場合は、http(s)://hostname:port/fed/sp/openidv20のようにURLを入力します。

- プロトコルのバージョン: OpenID 2.0

- ロール: サービス・プロバイダ

2. 「信頼できるプロバイダ設定」タブで次の設定を使用してパートナを編集します。

- エンドポイントURL: ユーザーが認証情報とともにOPからOracle Identity Federation/RPにリダイレクトされるURLです。Oracle Identity FederationがRPである場合は、http(s)://hostname:port/fed/sp/openidv20のようにURLを入力します。

6.24.2.2 RPへのデータの提供

RPと統合する場合、Oracle Identity Federation/OPがフェデレーテッド・パートナに情報を提供しなければならない場合があります。RPで、次のデータが必要になる場合があります。

- 検出URL: Oracle Identity Federation/OPがXRDSメタデータを公開するURLです。OIF/OPの検出URLは、http(s)://hostname:port/fed/idp/openidv20のようなURLになります。

- エンドポイントURL: ユーザーが認証時にRPからOracle Identity Federation/OPにリダイレクトされるURLです。Oracle Identity Federation/OPのエンドポイントURLは、http(s)://hostname:port/fed/idp/openidv20のようなURLになります。

6.24.3 属性の構成

Oracle Identity FederationがOpenIDパートナと連携できるようにするには、属性を構成する必要があります。

6.24.3.1 OPとしてのOracle Identity Federationの属性

Oracle Identity Federation/OPがOpenIDレスポンスで属性を送信できるようにするには、次のようにOpenID Attibute Exchange (AX)プロトコルを有効にする必要があります。

1. Fusion Middleware Controlで、「アイデンティティ・プロバイダ」ページに移動し、「OpenID 2.0」タブを選択します。

2. 「Attribute Exchange (AX) 1.0の有効化」ボックスを選択します。

3. 変更を保存します。

各RP(または一般OpenIDサービス・プロバイダ)に対して、そのRPの属性を送信するようにOracle Identity Federation/OPを構成し、OpenIDレスポンスに組み込むことのできる属性を定義する必要があります。

1. Fusion Middleware Controlで、「フェデレーション」ページに移動します。

2. RPを選択して、「編集」をクリックします。

3. 「属性名マッピングの編集」をクリックします。

4. OpenIDレスポンスで送信可能な属性を表すエントリを追加します。

5. 「追加」をクリックします。

6. ユーザー・データ・ストアの属性の名前を「ユーザー属性名」フィールドに入力します。

7. OpenIDレスポンスの属性の名前は、「フォーマットまたはネームスペース」および「アサーション属性名」で構成されます。ここで、「フォーマットまたはネームスペース」には属性名のURL接頭辞を含めます。また、「アサーション属性名」には接尾辞を含めます。たとえば、http://openid.net/schema/contact/internet/email属性を定義する場合、「フォーマットまたはネームスペース」にはhttp://openid.net/schema/contact/internet/を、「アサーション属性名」にはemailを設定します。

8. Oracle Identity Federationユーザー・セッションから属性を取得する場合は、「ユーザー・セッションから値を取得」ボックスを選択します。

9. RPからリクエストされなかった場合でも、この属性を常にOpenIDレスポンスで送信する場合は、「SSOアサーションで送信」を選択します。

10. 「OK」をクリックします。

11. すべての属性を追加したら、「OK」をクリックします。

12. 「シングル・サインオン(SSO)の属性の有効化」ボックスを選択します。

13. 「適用」をクリックします。

6.24.3.2 RPとしてのOracle Identity Federationの属性

Oracle Identity Federation/RPは、実行時に属性をリクエストする際に、カスタムの事前SPアクション・モジュールまたはカスタムSPエンジンを経由するか、またはユーザーを認証するOPの構成に基づくことができます。

OPの属性をリクエストするようにOracle Identity Federation/RPを構成する手順は次のとおりです。

1. Fusion Middleware Controlで、「フェデレーション」ページに移動します。

2. OPを選択して、「編集」をクリックします。

3. 「属性名マッピングの編集」をクリックします。

4. OPにリクエストする属性を表すエントリを追加します。

5. 「追加」をクリックします。

6. この属性を表す際にローカルに使用する名前を「ユーザー属性名」フィールドに入力します。

7. OpenIDレスポンスの属性の名前は、「フォーマットまたはネームスペース」および「アサーション属性名」で構成されます。ここで、「フォーマットまたはネームスペース」には属性名のURL接頭辞を含めます。また、「アサーション属性名」には接尾辞を含めます。たとえば、http://openid.net/schema/contact/internet/email属性を定義する場合、「フォーマットまたはネームスペース」にはhttp://openid.net/schema/contact/internet/を、「アサーション属性名」にはemailを設定します。

8. このOPのこの属性をリクエストするには、「情報カードの内容が必要」ボックスを選択します。

9. 「OK」をクリックします。

10. すべての属性を追加したら、「OK」をクリックします。

6.25 OpenID UI Extensionの実装

Oracle Identity Federationは、OpenID User Interface Extension 1.0 (UI Ext)をサポートしています。これには、様々な環境や言語に応じて最適化されたOpenIDユーザー・インタフェースをサポートするためのメカニズムが定義されています。

Oracle Identity Federationでは、IdPとユーザーとの視覚的な対話方法を示すデータをIdPへのリダイレクトURLに組み込むよう指定できます。

構成パラメータは次のとおりです。

- openiduiextenabled (boolean, false by default)

UI Extをサポートしていることを公開するようにOracle Identity Federation/IdPを構成します。IdPとして動作するOracle Identity Federationのテストのみを目的としています。

- openiduiextlangenabled (boolean, false by default)

IdPでUI Ext言語をサポートしている場合、Oracle Identity Federation/SPからIdPへのリダイレクトURLで、UI Ext言語パラメータを送信するようにOracle Identity Federation/SPを構成します。

- openiduiextpopupenabled (boolean, false by default)

IdPでUI Extモードをサポートしている場合、Oracle Identity Federation/SPからIdPへのリダイレクトURLで、UI Extモード・パラメータをpopupに設定して送信するようにOracle Identity Federation/SPを構成します。

- openiduiexticonenabled (boolean, false by default)

後述のopeniduiexticonurlパラメータで指定された値でUI ExtアイコンをサポートすることをXRDSで公開するようにOracle Identity Federation/SPを構成します。

- openiduiexticonurl (string, empty by default)

IdPで使用されるアイコンのURLの場所を指定します。これはSP XRDSで公開されます。

この機能を構成するには、Oracle Identity FederationのWLSTスクリプト環境を入力してから、次のプロパティを設定します。

setConfigProperty('idpopenid20', 'openiduiextenabled', 'true', 'boolean')
setConfigProperty('spopenid20', 'openiduiextlangenabled', 'true', 'boolean')
setConfigProperty('spopenid20', 'openiduiextpopupenabled', 'true', 'boolean')
setConfigProperty('spopenid20', 'openiduiexticonenabled', 'true', 'boolean')
setConfigProperty('spopenid20', 'openiduiexticonurl', 'http://my.icon.com', 'string')

注意:
http://my.icon.comはアイコンのURLの場所で置き換えてください。

7 診断および監視

この章では、Oracle Identity Federation用のOracle Enterprise Manager Fusion Middleware Controlの監視機能およびロギング機能について説明します。これらの項目が含まれます。

- 監視

- 可用性

- ロギング

- 監査

注意:
Liberty 1.xのサポートは非推奨です。

7.1 監視

この項では、Oracle Identity Federatiornサーバーを監視する方法について説明します。

- Oracle Identity Federationホームページ

- パフォーマンス・サマリー

7.1.1 Oracle Identity Federationのホームページ

Oracle Identity Federationサーバー・インスタンスのホーム・ページを次に示します。

このページには、サーバー・インスタンスに関する統計が要約されています。ここに表示されるメトリックの詳細は、第7.1.2項「パフォーマンス・サマリー」を参照してください。

7.1.2 パフォーマンス・サマリー

Oracle Identity Federationが提供する様々な組込みメトリックを使用すると、アプリケーション開発者、システム管理者、その他のユーザーは、アプリケーション固有のパフォーマンス情報を測定できます。システム・イベント、状態イベントおよびフェーズ・イベントのメトリックは、次の機能領域で使用できます。

- プロトコル・プロファイル

- エンタープライズ・データ層の接続性

- セキュリティ・プロトコル・メッセージ

- データ・モデル(JVT DiscoveryProviders)

この項は次のトピックで構成されています。

- センサーの重みについて

- イベントのメトリック

- 状態イベント

- フェーズ・イベント

7.1.2.1 センサーの重みについて

DMSセンサーの重みは、Oracle Identity Federationが実行されている管理対象サーバーの設定の一つです。センサーの重みによって、表示されるメトリックが次のように異なります。

- all - すべてのセンサーがアクティブになります。

- normal(または、重みの値が設定されていない場合) - 標準レベルのすべてのセンサーがアクティブになります。

- heavy - デフォルト・レベルおよびheavyレベルのすべてのセンサーがアクティブになります。

- None - すべてのセンサーが非アクティブになります。

高負荷の計測によるコストを考慮すると、必要なセンサーのみを条件付きでアクティブにするようにセンサーの重みを設定することにより、サーバーに関する関連メトリック・データを効率的に収集できます。

センサーの重みの設定

管理コンソールを使用してOracle WebLogic Serverを起動する場合は、サーバーのservers/serverName/server start/argumentsセクションで-Doracle.dms.sensors=levelプロパティを設定します。ここで、levelは前述のセンサー・レベルのいずれかです。

スクリプトによってOracle WebLogic Serverを起動する場合は、domain_home/bin/startManagedWebLogic.shスクリプトで-Doracle.dms.sensors=levelプロパティを設定します。

7.1.2.2 イベントのメトリック

この項は次のトピックで構成されています。

- プロトコル・プロファイル

- セキュリティ処理

注意:
表にあるラベルおよび説明は、Fusion Middleware Controlでメトリックに付けられているショート・ラベルと、そのメトリックの説明を示しています。

7.1.2.2.1 プロトコル・プロファイル

表7-1に、プロトコル・プロファイルのメトリックを示します。

表7-1 プロトコル・プロファイルのイベント

名前

ラベル、説明

重み

Requests

HTTPおよびSOAPリクエスト

受信したリクエストの合計数。RequestsHTTPとRequestsSOAPを加算したリクエスト・メッセージの数です。

normal

RequestsHTTPRedirect

リダイレクト・バインディングを使用したHTTPリクエスト

HTTPリダイレクト・バインディングを使用して送受信したリクエストの合計数。

normal

RequestsHTTPPOST

POSTバインディングを使用したHTTPリクエスト

HTTP-POSTバインディングを使用して送受信したリクエストの合計数。

normal

RequestsHTTPPOSTSimpleSign

POSTシンプル署名バインディングを使用したHTTPリクエスト

HTTP-POSTシンプル署名バインディングを使用して送受信したリクエストの合計数。

normal

RequestsSOAP

SOAPリクエスト

SOAPバインディングを使用して送受信したリクエストの合計数。

normal

WellFormedRequests

正常に解析された受信XMLリクエスト

受信した形式が正しいリクエスト、つまりXML変換エラーのないリクエストの合計数。

normal

BadlyFormedRequests

解析が失敗した受信XMLリクエスト

形式が正しくないリクエスト、つまりXML変換エラーとなるリクエストの合計数。

normal

SignedRequests

署名したリクエスト

メッセージ・レベルの署名で送受信したリクエストの合計数。

normal

EncryptedRequests

暗号化されたリクエスト

メッセージ・レベルの暗号化で送受信したリクエストの合計数。

normal

SignedAndEncryptedRequests

署名と暗号化の両方が行われたリクエスト

メッセージ・レベルの署名および暗号化で送受信したリクエストの合計数。

normal

Responses

HTTPまたはSOAPレスポンス

送受信したレスポンスの合計数。ResponsesHTTPおよびResponsesSOAPレスポンス・メッセージの合計です。

normal

ResponsesHTTPRedirect

リダイレクト・バインディングを使用したHTTPレスポンス

HTTPリダイレクト・バインディングを使用して送受信したレスポンスの合計数。

normal

ResponsesHTTPPOST

POSTバインディングを使用したHTTPレスポンス

HTTP-POSTバインディングを使用して送受信したレスポンスの合計数。

normal

ResponsesHTTPPOSTSimpleSign

POSTシンプル署名バインディングを使用したHTTPレスポンス

HTTP-POSTシンプル署名バインディングを使用して送受信したレスポンスの合計数。

normal

ResponsesSOAP

SOAPレスポンス

SOAPバインディングを使用して送受信したレスポンスの合計数。

normal

ErrorResponses

エラー・レスポンス

エラー・ステータスで送受信したレスポンスの合計数。

normal

SignedResponses

署名したレスポンス

メッセージ・レベルの署名で送受信したレスポンスの合計数。

normal

EncryptedResponses

暗号化されたレスポンス

メッセージ・レベルの暗号化で送受信したレスポンスの合計数。

normal

SignedAndEncryptedResponses

署名と暗号化の両方が行われたレスポンス

メッセージ・レベルの署名および暗号化で送受信したレスポンスの合計数。

normal

AttributeQueryRequests

AttributeQueryリクエスト

SPが送信またはIdPが受信した<AttributeQuery>リクエストの合計数。

normal

AttributeQueryResponses

AttributeQueryレスポンス

IdPが送信またはSPが受信した<Response>レスポンスの合計数。

normal

AttributeQueryErrorResponses

AttributeQueryエラー・レスポンス

IdPが送信またはSPが受信した<Response>エラー・レスポンスの合計数。

normal

AuthnRequestRequests

AuthnRequestリクエスト

SPが送信またはIdPが受信した<AuthnRequest| Request>リクエストの合計数。

normal

AuthnRequestResponses

AuthnRequestレスポンス

IdPが送信またはSPが受信した<Response|AuthnResponse>レスポンスの合計数。

normal

AuthnRequestErrorResponses

AuthnRequestエラー・レスポンス

IdPが送信またはSPが受信した<Response| AuthnResponse >エラー・レスポンスの合計数。

normal

SecurityTokenResponses

RequestSecurityTokenレスポンス

IdPが送信またはSPが受信した<RequestSecurityTokenResponse >レスポンスの合計数。

normal

LogoutRequests

ログアウト・リクエスト

送受信した<LogoutRequest| SignOut>リクエストの合計数。

normal

LogoutResponses

ログアウト・レスポンス

送受信したLogoutResponseメッセージの数。

normal

LogoutErrorResponses

ログアウト・エラー・レスポンス

送受信したエラー・ステータスのLogoutResponseメッセージの数。

normal

NameIDManagementRequests

ManageNameIDリクエスト

送受信した<ManageNameIDRequest|RegisterNameIdentifier|FederationTerminationNotification>リクエストの合計数。

normal

NameIDManagementResponses

ManageNameIDレスポンス

送受信した<ManageNameIDResponse>またはRegisterNameIdentifierレスポンスの合計数。

normal

NameIDManagementErrorResponses

ManageNameIDエラー・レスポンス

送受信した<ManageNameIDRequest|RegisterNameIdentifier|FederationTerminationNotification>エラー・レスポンスの合計数。

normal

ArtifactResolutionRequests

ArtifactResolveリクエスト

SPが送信またはIdPが受信した<ArtifactResolve|Request>リクエストの合計数。

normal

ArtifactResolutionResponses

ArtifactResolveレスポンス

IdPが送信またはSPが受信した<ArtifactResponse|Response>レスポンスの合計数。

normal

ArtifactResolutionErrorResponses

ArtifactResolveエラー・レスポンス

IdPが送信またはSPが受信した<ArtifactResponse|Response>エラー・レスポンスの合計数。

normal

NameIdentifierFormat_Persistent

処理された永続フォーマットの名前ID

SPまたはIdPで処理したメッセージ内の永続名前識別子の合計数。

normal

NameIdentifierFormat_Transient

処理された一時フォーマットの名前ID

SPまたはIdPで処理したメッセージ内の一時名前識別子の合計数。

normal

NameIdentifierFormat_Unspecified

処理された未指定フォーマットの名前ID

SPまたはIdPで処理したメッセージ内の未指定名前識別子の合計数。

normal

NameIdentifierFormat_EmailAddress

処理されたEmailAddressフォーマットの名前ID

SPまたはIdPで処理したメッセージ内の電子メール・アドレス名前識別子の合計数。

normal

NameIdentifierFormat_X509DN

処理されたX509SubjectNameフォーマットの名前ID

SPまたはIdPで処理したメッセージ内のX.509サブジェクト名前識別子の合計数。

normal

NameIdentifierFormat_Windows

処理されたWindowsDomainQualifiedNameフォーマットの名前ID

SPまたはIdPで処理したメッセージ内のWindowsドメイン修飾名識別子の合計数。

normal

NameIdentifierFormat_Kerberos

処理されたKerberosフォーマットの名前ID

SPまたはIdPで処理したメッセージ内のKerberosプリンシパル名前識別子の合計数。

normal

RequestProcessed

ApplicationControllerリクエスト

ApplicationControllerが処理したリクエストの合計数。

normal

7.1.2.2.2 セキュリティ処理

表7-2に、プロトコル・プロファイルのメトリックを示します。

注意:
表にあるラベルおよび説明は、Fusion Middleware Controlでメトリックに付けられているショート・ラベルと、そのメトリックの説明を示しています。

表7-2 セキュリティ処理のイベント

名前

ラベル、説明

重み

XMLSignatures_Signed

生成されたXML署名

生成されたXML署名の合計数。

normal

XMLSignatures_Verified

XML署名検証成功

XML署名検証成功の合計数。

normal

XMLSignatures_VerifyFailed

XML署名検証失敗

XML署名検証失敗の合計数。

normal

XMLEncryption_Encryptions

生成されたXML暗号化

生成されたXML暗号化の合計数。

normal

XMLEncryption _Decryptions

XML復号化成功

XML復号化成功の合計数。

normal

XMLEncryption _DecryptionFailures

XML復号化失敗

XML復号化失敗の合計数。

normal

7.1.2.3 状態イベント

次のメトリックはエンタープライズ・データ層の接続性に対して収集されます。

- Server_OpenSessions - このメトリックのFusion Middleware Controlのラベルは「オープン・サーバー接続」です。LDAPまたはRDBMSサーバーとのオープン接続の合計数を表します。
センサーの重みは「all」です。

7.1.2.4 フェーズ・イベント

この項は次のトピックで構成されています。

- データ・モデル

- プロトコル・プロファイル

- セキュリティ処理

7.1.2.4.1 データ・モデル

表7-3に、フェーズ・イベント・センサーによるJVTDiscoveryProvidersメトリックを示します。

注意:
表にあるラベルおよび説明は、Fusion Middleware Controlでメトリックに付けられているショート・ラベルと、そのメトリックの説明を示しています。

表7-3 JVTDiscoveryProviderイベント

名前

ラベルおよび説明

重み

ArtifactCreation

SAMLアーティファクト作成時間(ミリ秒)

Artifact DiscoveryProviderでアーティファクトの作成に要した時間。

heavy

LocateArtifact

SAMLアーティファクト取得時間(ミリ秒)

Artifact DiscoveryProviderのアーティファクトの検出に要した時間。

heavy

LocateConfiguration

サーバー構成取得時間(ミリ秒)

Configuration DiscoveryProviderによるプロトコル/サーバー構成の検出に要した時間。

heavy

LocateMetadata

プロバイダ・メタデータ取得時間(ミリ秒)

メタデータ検出プロバイダがメタデータ検出に要した時間。

heavy

ProfileStateCreation

ProfileStateオブジェクト作成時間(ミリ秒)

ProfileState DiscoveryProviderのプロファイル・ステータスの検出に要した時間。

heavy

LocateProfileState

ProfileStateオブジェクト取得時間(ミリ秒)

ProfileState DiscoveryProviderのプロファイル・ステータスの検出に要した時間。

heavy

SessionCreation

ユーザー・セッション取得または作成時間(ミリ秒)

Session DiscoveryProviderのユーザーの作成または検出に要した時間。

heavy

LocateUser

ユーザー・オブジェクト取得時間(ミリ秒)

User DiscoveryProviderのユーザーの検出に要した時間。

heavy

LocateSession

セッション・オブジェクト取得時間(ミリ秒)

セッションの検出に要した時間。

heavy

CreateActiveServiceProviderFederation

アクティブなSPフェデレーションの作成時間(ミリ秒)

アクティブ・サービス・プロバイダ・フェデレーションの作成に要した時間。

heavy

LocateActiveServiceProviderFederation

アクティブなSPフェデレーションの取得時間(ミリ秒)

アクティブ・サービス・プロバイダ・フェデレーションの検出に要した時間。

heavy

CreateActiveIdentityProviderFederation

アクティブなIdPフェデレーションの作成時間(ミリ秒)

アクティブ・アイデンティティ・プロバイダ・フェデレーションの作成に要した時間。

heavy

LocateActiveIdentityProviderFederation

アクティブなIdPフェデレーションの取得時間(ミリ秒)

アクティブ・アイデンティティ・プロバイダ・フェデレーションの検出に要した時間。

heavy

LocateProviderFederation

プロバイダ・フェデレーション取得時間(ミリ秒)

プロバイダ・フェデレーションの検出に要した時間。

heavy

LocateTemporaryProviderFederation

一時プロバイダ・フェデレーション取得時間(ミリ秒)

一時プロバイダ・フェデレーションの検出に要した時間。

heavy

CreateAffiliationProviderFederation

アフィリエーション・フェデレーション作成時間(ミリ秒)

アフィリエイション・プロバイダ・フェデレーションの作成に要した時間。

heavy

LocateAffiliationFederation

アフィリエーション・フェデレーション取得時間(ミリ秒)

アフィリエイション・フェデレーションの検出に要した時間。

heavy

CreateServiceProviderFederation

SPフェデレーション作成時間(ミリ秒)

サービス・プロバイダ・フェデレーションの作成に要した時間。

heavy

CreateIdentityProviderFederation

IdPフェデレーション作成時間(ミリ秒)

アイデンティティ・プロバイダ・フェデレーションの作成に要した時間。

heavy

DeleteSession

セッション削除時間(ミリ秒)

セッションの削除に要した時間。

heavy

CreateBinaryLargeObject

データベースBLOB作成時間(ミリ秒)

BLOB作成に要した時間。

heavy

LocateBinaryLargeObject

データベースBLOB取得時間(ミリ秒)

BLOBの検出に要した時間。

heavy

SessionPersistence

セッション・データを維持する時間(ミリ秒)

セッションの維持に要した時間。

heavy

DeleteArtifact

SAMLアーティファクト削除時間(ミリ秒)

アーティファクトの削除に要した時間。

heavy

DeleteProfileState

ProfileStateデータ削除時間(ミリ秒)

プロファイル・ステータスの削除に要した時間。

heavy

DeleteActiveIdPFederation

アクティブなIdPフェデレーションの削除時間(ミリ秒)

アクティブIdPフェデレーションの削除に要した時間。

heavy

DeleteActiveSPFederation

アクティブなSPフェデレーションの削除時間(ミリ秒)

アクティブSPフェデレーションの削除に要した時間。

heavy

DeleteProviderFederation

プロバイダ・フェデレーション削除時間(ミリ秒)

プロバイダ・フェデレーションの削除に要した時間。

heavy

ProviderFederationPersistence

プロバイダ・フェデレーションを維持する時間(ミリ秒)

プロバイダ・フェデレーションの維持に要した時間。

heavy

7.1.2.4.2 プロトコル・プロファイル

表7-4に、リクエストおよびレスポンスに対して、フェーズ・イベント・センサーで収集されるプロトコル・プロファイルのメトリックを示します。

注意:
表にあるラベルおよび説明は、Fusion Middleware Controlでメトリックに付けられているショート・ラベルと、そのメトリックの説明を示しています。

表7-4 プロトコル・プロファイル・イベント

名前

ラベルおよび説明

重み

LocalAuthn

ローカル・ユーザー認証時間(ミリ秒)

ユーザーがIdP/SPでローカルに認証されるのに要した時間。

normal

AuthnRequestProcessing

IdPでのAuthnRequestの処理時間(ミリ秒)

IdPでAuthnRequestの処理に要した時間。

heavy

AuthnResponseProcessing

SPでのAuthnResponseの処理時間(ミリ秒)

SPでAuthnResponseの処理に要した時間。

normal

ArtifactProcessing

SAMLアーティファクト処理時間(ミリ秒)

アーティファクトの処理に要した時間。

heavy

Logout

グローバル・ログアウト時間(ミリ秒)

グローバル・ログアウトに要した時間。

heavy

RequestProcessing

受信リクエスト処理時間(ミリ秒)

ApplicationControllerがリクエスト処理に要した時間。

normal

EventProcessing

イベント処理時間(ミリ秒)

ActionStateMachineのイベント処理に要した時間。

heavy

7.1.2.4.3 セキュリティ処理

表7-5に、セキュリティ処理時にフェーズ・イベント・センサーで収集されるメトリックを示します。

注意:
表にあるラベルおよび説明は、Fusion Middleware Controlでメトリックに付けられているショート・ラベルと、そのメトリックの説明を示しています。

表7-5 フェーズ・イベントのセキュリティ処理

名前

ラベルおよび説明

重み

XMLSigner

XMLメッセージ署名時間(ミリ秒)

XMLSignerがメッセージの署名に要した時間。

heavy

XMLSignatureVerifier

XMLメッセージ署名検証時間(ミリ秒)

XMLSignatureVerifierがメッセージ署名の検証に要した時間。

heavy

QueryStringSigner

URL問合せ文字列署名時間(ミリ秒)

問合せ文字列の署名に要した時間。

heavy

QueryStringSignatureVerifier

URL問合せ文字列署名検証時間(ミリ秒)

問合せ文字列の署名検証に要した時間。

heavy

XMLEncryptionService

XMLメッセージ暗号化時間(ミリ秒)

メッセージの暗号化に要した時間。

heavy

XMLDecryptionService

XMLメッセージ復号化時間(ミリ秒)

メッセージの復号化に要した時間。

heavy

SerializeMessage

XMLメッセージ整列化時間(ミリ秒)

LibertyProtocolMarshallerがメッセージをシリアライズするのに要した時間。

heavy

DeSerializeMessage

XMLメッセージ非整列化時間(ミリ秒)

LibertyProtocolMarshallerがメッセージをデシリアライズするのに要した時間。

heavy

7.2 可用性

Oracle Identity Federationは、Fusion Middleware Controlによって可用性が追跡されるJavaコンポーネントです。

詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Enterprise Manager Fusion Middleware Controlの使用の概要に関する項を参照してください。

7.3 ロギング

この項では、Oracle Identity Federationのロギングついて説明します。

- Oracle Identity Federationのロギングについて

- Oracle Identity Federationのログ・メッセージの表示

- Oracle Identity Federationのログの構成

- 一般的なログ・メッセージ

Oracle Fusion Middlewareのロギングの詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。

7.3.1 Oracle Identity Federationのロギングについて

この項では、Oracle Identity Federationのロギングの基本概要を説明します。この項の内容は次のとおりです。

- ログのタイプ

- ログ・レベル

- メッセージID

- ログ構成用ツール

7.3.1.1 ログのタイプ

Oracle Identity Federationには、次の2つのタイプのログがあります。

- 永続ログ - このログは、コンポーネントを再起動しても保持されます。

- ランタイム・ログ - このログは、実行時にサーバーで自動的に作成され、特定の機能がアクティブになったときにアクティブになります。

永続ログ・ファイルの内容は次のとおりです。

- servername-diagnostic.log - 一般的なアプリケーション・ログ・メッセージ、デバッグ・メッセージおよびエラー・メッセージが含まれます。このログは、フェデレーション・ログとも呼ばれます。

- Oracle Identity Federationに関するロギング・メッセージが含まれる可能性のあるログ・ファイルはこの他に、servername.logとservername.outがあります。

7.3.1.2 ログ・レベル

表7-6は、Oracle Identity Federationのログ・メッセージのログ・レベルを示しています。

表7-6 Oracle Identity Federationのログ・レベル

ログ・レベル

description

INTERNAL ERROR

回復不能なエラーを表すイベントです。

ERROR

回復可能および回復不能なエラーを表すイベントです。

WARNING

外部的および暗黙的なOracle Identity Federationサーバー・アクションの処理における失敗を表すイベントです。

NOTIFICATION

フローを表す、Oracle Identity Federationの主要な運用イベントです。

TRACE

詳細な処理フローとステート情報が含まれるイベントです。

7.3.1.3 メッセージID

Oracle Identity Federationのログ・メッセージは、次のカテゴリに分類されます。

表7-7 Oracle Identity Federationのメッセージ・カテゴリ

メッセージIDの範囲

メッセージ・カテゴリ

FED-10000からFED-10099

コンプライアンス

FED-10100からFED-10999

構成

FED-11000からFED-11699

データ

FED-11700からFED-11999

ネットワーク

FED-12000からFED-12999

その他

FED-13000からFED-14999

プログラム関連

FED-15000からFED-17999

リクエストおよびレスポンス

FED-18000からFED-19999

セキュリティ

FED-20000からFED-20099

スレッド

7.3.1.4 ログ構成用ツール

Oracle Identity Federationには、ログの構成および管理用として次の2つのツールが用意されています。

- Fusion Middleware Control(GUIベースで構成する場合)

- wlst(コマンドラインで構成する場合)

7.3.2 Oracle Identity Federationのログ・メッセージの表示

Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。「Oracle Identity Federation」ドロップダウン・メニューで、「ログ」→「ログ・メッセージの表示」の順に選択します。

7.3.2.1 表示するメッセージの選択

表示するメッセージを選択するには、次の手順を実行します。

1. 「Oracle Identity Federation」メニューで、「ログ」→「ログ・メッセージの表示」の順に選択します。「ログ・メッセージ」ページが表示されます。

2. 表示するログの日付範囲を選択します。「最新」は、分単位、時間単位または日単位で選択できます。また、「時間間隔」を選択し、開始日時と終了日時を指定することもできます。

3. 表示する「メッセージ・タイプ」を選択します。

4. 追加条件を指定します(任意の文字列を含むメッセージのみを表示する場合など)。

5. 特定の検索を実行するには、「フィールドの追加」を選択し、検索するフィールドを追加します。各フィールドに対し、基準をリストから選択した後、テキストをボックスに入力します。フィールドを削除するには、赤いXを選択します。フィールドを追加するには、「フィールドの追加」を選択します。基準の追加が終了した後、「検索」をクリックします。

7.3.2.2 表示オプションの指定

表示するメッセージを指定する他に、次のような表示オプションが用意されています。

- ドメインに関するメッセージを表示するには、「広範囲のターゲット・スコープ」リストを使用します。

- ログ・メッセージをXML、テキストまたはカンマ区切りのリストとしてファイルにエクスポートするには、「メッセージをファイルにエクスポート」を選択します。

- 個々のログ・ファイルに関する情報を表示するには、「ターゲット・ログ・ファイル」をクリックします。

- 表示をリフレッシュするタイミングを指定できます。右上のリストから「手動リフレッシュ」、「30秒リフレッシュ」または「1分間リフレッシュ」を選択します。

- リストされている列の変更や列の並替えには、「表示」リストを使用します。

- メッセージのグループ分けの変更には、「表示」リストを使用します。

- ログ・メッセージのリストのみを表示するには、「検索」ラベルを閉じます。

- ログ・ファイルの内容を表示するには、「ログ・ファイル」列でファイル名をダブルクリックします。「ログ・ファイルの表示:filename」ページが表示されます。「時間」、「メッセージ・タイプ」および「メッセージID」列で上向きまたは下向きの矢印を使用してファイル内のレコードを並べ替えることができます。

7.3.3 Oracle Identity Federationのログの構成

このページは、Oracle Identity Federationサーバーのログを表示および構成する際に使用します。

ログ構成ページに移動するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「Oracle Identity Federation」ドロップダウン・メニューで、「ログ」→「ログ構成」の順に選択します。

この項の内容は次のとおりです。

- Oracle Identity Federationのログ・レベルの構成

- Oracle Identity Federationのログ・ファイルの構成

7.3.3.1 Oracle Identity Federationのログ・レベルの構成

このページでは、次の操作を行います:

- Oracle Identity Federationのロギング・レベルを表示および更新します。

- 新しい永続ログ出力を作成します。

各ログ出力は、特定のサーバー機能のメッセージを記録します。たとえば、EJBデプロイメント・ログ出力は、EJBモジュールのメッセージを記録します。

ログ出力レベルの表示または更新

ログ出力を選択するには、「表示」ドロップダウンを使用します。

次のフィールドがあります。

- ログ出力名 - ログ出力の名前です。

- Oracle Diagnostic Loggingレベル - ロギング・レベルです。「レベル」ドロップダウンを使用してログ・レベルを変更します。

- ログ・ファイル - ログ・ファイルの名前です。ログ・ファイルのプロパティを表示および更新するには、ログ・ファイル名をクリックします。

ログ出力の指定

ページのこの部分は、「表示」ドロップダウンで永続ログ・レベルのログ出力を選択した場合に表示されます。

永続ログ出力を作成するには、次の情報を指定します。

- 名前 - 新しいログ出力の名前を入力します。

- Oracle Diagnostic Loggingレベル - ロギング・レベルです。「レベル」ドロップダウンを使用してログ・レベルを選択します。

ページにあるボタンの機能は次のとおりです。

- 適用 - ログ出力構成の更新を保存します。または新しいログ出力情報を生成します。

- 元に戻す - 構成の更新を破棄します。

7.3.3.2 Oracle Identity Federationのログ・ファイルの構成

ログ・ファイルの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルの設定の構成に関する項を参照してください。

7.3.4 一般的なログ・メッセージ

この項では、Oracle Identity Federationのログに表示される可能性のある一般的なメッセージについて説明します。

7.3.4.1 スレッド中断メッセージ

管理対象サーバーのログ・ファイルに次のようなメッセージが表示される場合があります。

oracle.security.fed.jvt.discovery.model.session.RDBMSSessionDiscoveryProvider
run
WARNING: InterruptedException: thread interrupt occurred during sleep()
java.lang.InterruptedException: sleep interrupted

これらのメッセージは、RDBMSの停止中のスレッドが構成のリロードにより中断されたことを示す通知にすぎません。このスレッドに置き換わる新しいスレッドが作成されています。アクションは不要です。

7.4 監査

Oracle Identity Federationは、Fusion Middleware監査フレームワークを使用して監査を行います。

この項では、監査対象のイベントについて、およびOracle Identity Federationの監査を構成する方法について説明します。これらの項目が含まれます。

- Oracle Identity Federationでの監査について

- Oracle Identity Federationでの監査の構成

- 監査データの表示

関連項目:
監査の構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査の構成と管理に関する項を参照してください。

7.4.1 Oracle Identity Federationでの監査について

この項では、各種カテゴリで監査可能なイベントをリストし、監査レベルについて説明します。

7.4.1.1 監査イベントのカテゴリ

Oracle Identity Federationの監査イベントには、次の4つのカテゴリがあります。

- ユーザー・セッション管理

- プロトコル・フロー

- サーバー構成

- セキュリティ

各カテゴリのイベントについては、次の各項で説明します。

7.4.1.1.1 ユーザー・セッション管理のイベント

セッション管理のイベントと各イベントの属性は、次のとおりです。

- CreateUserSession - ログイン成功後のユーザー・セッションの作成

- SessionID

- AuthenticationMechanism

- UserID

- DeleteUserSession - ログアウト後のユーザー・セッションの削除

- SessionID

- AuthenticationMechanism

- UserID

- CreateUserFederation - 2つのリモート・サーバー間でのユーザー・フェデレーションの作成

- FederationID

- FederationType (SP/IdP/Affiliation)

- UserID

- RemoteProviderID

- ProtocolVersion

- NameIDFormat

- NameIDQualifier

- NameIDValue

- UpdateUserFederation - 2つのリモート・サーバー間でのユーザー・フェデレーションの更新

- FederationID

- FederationType (SP/IdP)

- UserID

- RemoteProviderID

- ProtocolVersion

- NameIDFormat

- NameIDQualifier

- NameIDValue

- OldNameIDQualifier

- OldNameIDValue

- DeleteUserFederation - 2つのリモート・サーバー間でのユーザー・フェデレーションの削除

- FederationID

- FederationType (SP/IdP)

- UserID

- RemoteProviderID

- ProtocolVersion

- NameIDFormat

- NameIDQualifier

- NameIDValue

- CreateActiveUserFederation - ログイン成功後のアクティブ・フェデレーションの作成

- FederationID

- FederationType (SP/IdP)

- SessionID

- UserID

- RemoteProviderID

- ProtocolVersion

- DeleteActiveUserFederation - ログアウト後のアクティブ・フェデレーションの削除

- FederationID

- FederationType (SP/IdP)

- SessionID

- UserID

- RemoteProviderID

- ProtocolVersion

- LocalAuthentication - OIFでのユーザーの認証

- AuthenticationMechanism

- AuthenticationEngineID

- RemoteIP

- SessionID

- UserID

- LocalLogout - Oracle Identity Federationでのユーザーのログアウト

- RemoteIP

- SessionID

- UserID

7.4.1.1.2 プロトコル・フローのイベント

プロトコル・フローのイベントとその属性は、次のとおりです。

- IncomingMessage - Oracle Identity Federationが受信したメッセージ

- RemoteIP

- Binding(SOAP、GET、POST、Artifactなど)

- ProtocolVersion(SAML2、Libv11など)

- RemoteProviderID

- Role(サービス・プロバイダ、アイデンティティ・プロバイダ、属性認証局など)

- IncomingMessageString(CLOB)

- MessageType(SSOLoginRequest、SSOLoginResponse、SSOLogoutRequestなど)

- OutgoingMessage - Oracle Identity Federationが送信したメッセージ(成功した場合のみ)

- RemoteIP

- Binding(SOAP、GET、POST、Artifactなど)

- ProtocolVersion(SAML2、Libv11など)

- RemoteProviderID

- Role(サービス・プロバイダ、アイデンティティ・プロバイダ、属性認証局など)

- OutgoingMessageString(CLOB)

- MessageType(SSOLoginRequest、SSOLoginResponse、SSOLogoutRequestなど)

- AssertionCreation - Oracle Identity Federationによるアサーションの作成(成功した場合のみ)

- RemoteIP

- ProtocolVersion(SAML2、Libv11など)

- AssertionVersion(2.0など)

- IssueInstant

- Issuer

- NameIDQualifier

- NameIDValue

- NameIDFormat

- AssertionID

- UserID

- SessionID

- FederationID

- RemoteProviderID

- AssertionConsumption - Oracle Identity Federationによるアサーションの処理(成功した場合のみ)

- ProtocolVersion(SAML2、Libv11など)

- AssertionVersion(2.0など)

- IssueInstant

- Issuer

- NameIDQualifier

- NameIDValue

- NameIDFormat

- AssertionID

- UserID

- SessionID

- FederationID

- RemoteProviderID

7.4.1.1.3 サーバー構成のイベント

サーバー構成のイベントとその属性は、次のとおりです。

- CreateConfigProperty - 新しい構成プロパティの追加(成功した場合のみ)

- PropertyName

- PropertyType(PropertiesList、PropertiesMap、String、Booleanなど)

- 値

- PeerProviderID

- Hierarchy

- ChangeConfigProperty - 既存の構成プロパティ値の変更(成功した場合のみ)

- PropertyName

- PropertyType(PropertiesList、PropertiesMap、String、Booleanなど)

- OldValue

- NewValue

- PeerProviderID

- Hierarchy

- DeleteConfigProperty - 構成プロパティの削除(成功した場合のみ)

- PropertyName

- PropertyType(PropertiesList、PropertiesMap、String、Booleanなど)

- OldValue

- PeerProviderID

- Hierarchy

- CreatePeerProvider - 信頼できるプロバイダ・リストへの新しいプロバイダの追加(成功した場合のみ)

- PeerProviderID

- ProviderType(sp、idp、sp idpなど)

- ProtocolVersion

- 説明

- UpdatePeerProvider - 信頼できるプロバイダ・リストに存在するプロバイダの情報の更新(成功した場合のみ)

- PeerProviderID

- ProviderType(sp、idp、sp idpなど)

- ProtocolVersion

- 説明

- DeletePeerProvider - 信頼できるプロバイダ・リストからのプロバイダの削除(成功した場合)

- PeerProviderID

- ProviderType(sp、idp、sp idpなど)

- ProtocolVersion

- 説明

- LoadMetadata - メタデータのロード(成功した場合のみ)

- Metadata

- 説明

- SetDataStoreType - データ・ストアのタイプの変更(成功した場合のみ)

- DataStoreName

- OldValue

- NewDataStoreType

- ChangeDataStore - フェデレーション・データ・ストアの設定(成功した場合のみ)

- DataStoreBefore

- DataStoreAfter

- ChangeFederation - 信頼できるプロバイダの変更(成功した場合のみ)

- COTBefore

- COTAfter

- ChangeServerProperty - サーバー構成プロパティの変更(成功した場合のみ)

- ServerConfigBefore

- ServerConfigAfter

7.4.1.1.4 セキュリティのイベント

セキュリティのイベントとその属性は、次のとおりです。

- CreateSignature - Oracle Identity Federationによるデジタル署名の作成

- Type(XML、String)

- VerifySignature - Oracle Identity Federationによるデジタル署名の検証

- Type(XML、String)

- EncryptData - Oracle Identity Federationによるデータの暗号化

- Type(XML、String)

- DecryptData - Oracle Identity Federationによるデータの復号化

- Type(XML、String)

7.4.1.1.5 すべてのイベントで共有される属性

すべてのイベントで共有される属性は、次のとおりです。

- timestamp - 監査イベントが発生したときのタイムスタンプ

- initiator - 監査イベントの開始者(一部のイベントでは、この属性は空になる場合があります)

- ECID - 実行コンテキストID

7.4.1.2 監査レベル

Fusion Middleware監査フレームワークは、次の監査レベルをサポートしています。

- なし

- 低

- 中

- カスタム

次の監査イベントは、監査レベルが「低」および「中」の場合に監査されます。

注意:
FAILURESONLYは、イベントが失敗した場合にのみ、監査されることを示しています。

「低」レベルで監査されるイベント

- ServerConfiguration

- CreateConfigProperty

- ChangeConfigProperty

- DeleteConfigProperty

- CreatePeerProvider

- UpdatePeerProvider

- DeletePeerProvider

- LoadMetadata

- SetDataStoreType

- ChangeDataStore

- ChangeCOT

- ChangeServerProperty

「中」レベルで監査されるイベント

- ServerConfiguration

- CreateConfigProperty

- ChangeConfigProperty

- DeleteConfigProperty

- CreatePeerProvider

- UpdatePeerProvider

- DeletePeerProvider

- LoadMetadata

- SetDataStoreType

- ChangeDataStore

- ChangeCOT

- ChangeServerProperty

- UserSession.FAILUREONLY

- CreateUserSession.FAILUREONLY

- DeleteUserSession.FAILUREONLY

- CreateUserFederation.FAILUREONLY

- UpdateUserFederation.FAILUREONLY

- DeleteUserFederation.FAILUREONLY

- CreateActiveUserFederation.FAILUREONLY

- DeleteActiveUserFederation.FAILUREONLY

- LocalAuthentication.FAILUREONLY

- LocalLogout.FAILUREONLY

- ProtocolFlow.FAILUREONLY

- IncomingMessage.FAILUREONLY

- OutgoingMessage.FAILUREONLY

- AssertionCreation.FAILUREONLY

- AssertionConsumption.FAILUREONLY

- Security.FAILUREONLY

- CreateSignature.FAILUREONLY

- VerifySignature.FAILUREONLY

- EncryptData.FAILUREONLY

- DecryptData.FAILUREONLY

「カスタム」レベルで監査されるイベント

「カスタム」監査レベルでは、監査するイベントのみを選択できます。

関連項目:
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査の構成と管理に関する項

7.4.2 Oracle Identity Federationの監査の構成

監査を構成するには、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドライン・インタフェースを使用します。

Fusion Middleware Controlで監査の構成を開始するには、次の手順を実行します。

1. Fusion Middleware Controlにログインして、「Identity Management」ドメインに移動します。

2. 「WebLogicドメイン」ドロップダウン・メニューで、「セキュリティ」を選択してから、「監査ポリシー」を選択します。

3. Oracle Identity Federationコンポーネントを選択します。

4. 「監査レベル」メニューで、希望の監査レベルを選択します。
各種カテゴリで実行される監査ポリシーを表示するには、コンポーネントの「+」チェック・ボックスを開きます。

注意:
選択したレベルが「カスタム」の場合は、第7.4.2.1項「カスタム・レベルでの監査の構成」を参照してください。

5. オプションで「ユーザー」テキスト・ボックスを使用して、監査レベルに関係なくすべてのイベントで常に監査されるユーザーを追加できます。

6. 「適用」をクリックします。

7.4.2.1 「カスタム」レベルでの監査の構成

監査ポリシーを構成して、「カスタム」監査レベルを使用する場合は、次の手順を実行します。

1. 「監査レベル」メニューで、監査レベルとして「カスタム」を選択します。

2. 監査対象のイベントをイベントの表で選択します。

- コンポーネント名の横にある「+」記号をクリックして、監査イベントのカテゴリのリストを取得します。

- カテゴリ名の横にある「+」記号をクリックして、イベントのリストを取得します。

- イベント名の横にある「+」記号をクリックして、「成功」または「失敗」監査オプションを取得します。

3. 監査対象のイベントまたはカテゴリの横にある「監査の有効化」ボックスを選択します。(たとえば、「セキュリティ」の横のボックスを選択すると、すべてのセキュリティ・イベントが監査されます。)CreateUserSession Failureイベントの横にあるボックスを選択すると、すべてのCreateUserSession失敗イベントが監査されます。

4. オプションで、フィルタを追加すると、ファイングレイン監査を実行できます。
イベントまたはカテゴリ名の右にある鉛筆のアイコンをクリックします。必要なフィルタ条件を追加します。

5. 終了したら、「OK」をクリックします。

関連項目:
監査ポリシーの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査の構成と管理に関する項を参照してください。

7.4.3 監査データの表示

監査データは、ファイル(バスストップ・ファイルとも呼ばれます)内に置くことも、データベース監査ストア内に置くこともできます。

監査データがバスストップ・ファイル内に存在する場合は、次の場所のファイルを直接検索できます。

<domain_home>/servers/<server_name>/logs/auditlogs/OIF/audit.log

監査データがデータベース内に存在する場合は、Oracle Business Intelligence Publisherなどのツールを使用して、監査レポートを表示できます。

関連項目:
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査分析とレポートの使用に関する項

8 セキュリティ

この章では、次に示すような、Oracle Identity Federationのセキュリティに関するトピックについて説明します。

- Oracle Identity FederationでのSSLの構成

- 署名ウォレットおよび暗号化ウォレットの管理

- Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

8.1 Oracle Identity FederationでのSSLの構成

サーバーでのキーストアの使用方法について

Oracle Identity Federationでは、署名と暗号化キーストアに対する1つのパスワードの構成のみサポートされ、そのパスワードを使用してキーストアと秘密鍵の両方を開きます。これは、キーストアが異なるストア・パスワードとキー・パスワードで構成されている場合、Oracle Identity Federationで秘密鍵にアクセスしようとすると、エラーになるということです。

このエラーを回避するには、構成されているキーの別名の秘密鍵パスワードをキーストア・パスワードと同じにします。

注意:
Oracle Identity Federation 11gリリース1(11.1.1)では、キーストア・パスワードに合せてキー・パスワードを変更する場合、古いキーストアやウォレットを構成から削除する必要があります。

注意:
Keystores、信頼できる証明書およびOracle Identity Federationの証明書は、他のOracle Fusion Middlewareコンポーネントでの管理と同様に管理されます。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

この項には、次の項目が含まれます。

- SSLサーバーとしてのOracle Identity Federationの構成

- SSLクライアントとしてのOracle Identity Federationの構成

- HAモードでのSSLの構成

関連項目:
SSLモードでのOracle Identity Federation HAの構成については、6.4.3項を参照してください。

8.1.1 SSLサーバーとしてのOracle Identity Federationの構成

この項では、Oracle WebLogic ServerでのSSLポートの構成方法、およびSSLを使用する場合のOracle Identity Federationの構成方法について説明します。

8.1.1.1 Oracle WebLogic ServerでのSSLの設定

SSLを設定するOracle WebLogic ServerでSSLポートとキーストアを構成するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインし、「環境」→「サーバー」の順に移動します。

2. SSLを設定するサーバーを選択します。

3. 「SSLリスニング・ポートの有効化」を選択して、SSLリスニング・ポート番号(443など)を入力します。
以降では、このポートを$SSL_PORTと呼ぶことにします。

4. 「保存」をクリックします。

5. 「キーストア」タブに移動して、「ロックして編集」をクリックします。

6. 「キーストア」で、カスタムIDを組み込むためのオプションを選択します。

7. 「ID」セクションで、次のようにプロパティを入力します。

- カスタムIDキーストア: location of keystore containing the SSL private key and certificate

- カスタムIDキーストアのタイプ: jks

- カスタムIDキーストアのパスフレーズ: storepassword

8. 「保存」をクリックします。

9. 「SSL」タブに移動します。

10. 「ID」セクションで、次のようにプロパティを入力します。

- 秘密鍵の別名: keyalias

- 秘密鍵のパスフレーズ: keypassword

11. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

12. サーバーを再起動します。

13. SSLが正しく設定されていることを確認するために、https://$HOSTNAME:$SSL_PORTに移動すると、証明書が提示されます。この証明書を表示します。サブジェクトは、証明書の作成時に入力したcnと一致している必要があります。

注意:

- SSLサーバー証明書のCNは、完全修飾ホスト名である必要があります(eaevma1302.de.mycorp.com, not eaevma1302など)。

- Oracle Weblogic ServerでのSSLの設定方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

クライアントSSL証明書を要求するようにOracle WebLogic Serverを構成する場合は、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインし、「環境」→「サーバー」の順に移動します。

2. SSLを設定するサーバーを選択します。

3. 「SSL」タブ→「詳細」の順に移動します。

4. プロパティ「相互クライアント証明書の動作」で、「クライアント証明書をリクエスト(強制する)」を選択します。

5. 「保存」をクリックします。

6. 「キーストア」タブに移動します。

7. 「キーストア」で、構成する信頼キーストアのタイプのオプションを選択して、「信頼」セクションのフィールドに移入します。

8. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

9. サーバーを再起動します。

クライアント証明書を発行したCAを、Oracle WebLogic構成で指定した信頼キーストアにインポートする必要があります。Javaキーストアの場合は、次のコマンドを使用できます。

keytool -import -alias aliasfortrustedca -trustcacerts -file trustedcafile.pem -keystore keystorelocation -storepass truststorepassword

8.1.1.2 Oracle Identity Federationの構成

SSLリスニングポートを有効にし、サーバーおよび信頼できる証明書をそれぞれのキーストアにアップロードしている場合は、Oracle Identity FederationでSSLを使用するように構成する必要があります。

手順は次のとおりです。

1. Fusion Middleware Controlにログインし、Oracle Identity Federationインスタンスを見つけます。

2. 「サーバー・プロパティ」に移動します。

3. ポート(および必要に応じてSOAPポート)を更新して、Oracle Weblogic Server管理コンソールで構成したSSLポートを反映させます。

4. 「SSL有効」チェック・ボックスを選択します。

5. リクエストが非SSLポートで受信された場合にSSLの使用を強制するには、「強制SSL」ボックスを選択します。それ以外の場合は、チェックを外したままにします。

6. クライアント認証を強制するには、「クライアント証明書が必要」ボックスを選択します。それ以外の場合は、チェックを外したままにします。

7. 「適用」をクリックします。

SSLを有効にした後で、メタデータを再生成して、ピア・プロバイダに再配布する必要があります。

注意:

- ポート(およびSOAPポート)を変更すると、サーバーのメタデータが変更され、適切なサービスURLが反映されます。

- ピア・プロバイダのサイトにあるメタデータを新しいバージョンで更新する必要があります。

8.1.2 SSLクライアントとしてのOracle Identity Federationの構成

Oracle Identity FederationをSSLクライアントとして構成して、リモートSSLサーバーに接続するには、次の2つの方法があります。

- Oracle WebLogic Serverのキーストアをアイデンティティ・リポジトリおよび信頼リポジトリとして使用するようにOracle Identity Federationを設定します。このアプローチは、第8.1.2.1項「Oracle WebLogic Serverの構成」および第8.1.2.2項「Oracle Identity Federationでのキーストア・パスワードの構成」で説明します。

- 独自のアイデンティティ・リポジトリと信頼リポジトリを使用するようにOracle Identity Federationを設定します。このアプローチは、第8.1.2.3項「Oracle Identity FederationをSSLクライアントとして構成する別の方法」で説明します。

このセクションの内容は次のとおりです。

- Oracle WebLogic Serverの構成

- Oracle Identity Federationでのキーストア・パスワードの構成

- Oracle Identity FederationをSSLクライアントとして構成する別の方法

- SSL経由によるLDAPサーバーへの接続

- Fusion Middleware ControlによるOracle Identity Federationターゲットの管理を確実にする方法

8.1.2.1 Oracle WebLogic Serverの構成

一部のSSLサーバーでは、SSLハンドシェイク時にクライアントの認証を実行する必要がある場合があります。通常、この操作は、SSLクライアントによるSSLクライアント証明書のSSLサーバーへの提示で実行されます。

この項では、SSLサーバーからリクエストされた際に、クライアントSSL証明書を提示するようにOracle WebLogic ServerとOracle Identity Federationを構成する方法について説明します。これには次の対応が必要です。

- SSLサーバー証明書を発行したCAの信頼を設定します。

- Oracle Identity Federation SSLクライアントの証明書を取得します。

これを実行するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインし、「環境」→「サーバー」の順に移動します。

2. SSLを設定するサーバーを選択します。

3. 「キーストア」 タブに移動して、「ロックして編集」をクリックします。

4. 「キーストア」で、構成するカスタムIDと信頼キーストアのタイプを含むオプションを選択します。

5. 「ID」セクションで、次のようにプロパティを入力します。

- カスタムIDキーストア: location of keystore with SSL private key and certificate

- カスタムIDキーストアのタイプ: identity keystore type

- カスタムIDキーストアのパスフレーズ: storepassword

6. 「信頼」セクションで、信頼キーストアの情報をプロパティに入力します。

7. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

8. サーバーを再起動します。

8.1.2.2 Oracle Identity Federationでのキーストア・パスワードの構成

Oracle Identity Federationがリモート・プロバイダに接続して、SSLクライアント証明書を提供する必要がある場合は、Oracle WebLogic ServerではなくOracle Identity Federationの設定で、アイデンティティ・キーストアおよび信頼キーストアのパスワードを構成する必要があります。手順は次のとおりです。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「サーバー・プロパティ」の順に移動します。

3. 「SSL設定」の「アウトバウンド接続」セクションで、次の2つのプロパティの値を入力します。

- WebLogic Serverのアイデンティティ・キーストアのパスワード - Oracle WebLogic Serverの構成で入力したアイデンティティ・キーストアのパスワードです。

- WebLogic Serverのトラスト・キーストアのパスワード - Oracle WebLogic Serverの構成で入力した信頼キーストアのパスワードです。このプロパティを空白のままにした場合は、パスワードなしで信頼キーストアがオープンされます。

8.1.2.3 Oracle Identity FederationをSSLクライアントとして構成する別の方法

リモートSSLサーバーに接続する場合に、アイデンティティ・キーストアおよび信頼キーストアの情報をOracle WebLogic Serverの構成に入力しない場合は、別の方法でOracle Identity FederationをSSLクライアントとして構成できます。

このアプローチでは、Oracle Identity FederationのWLSTコマンドまたはMBeanを使用して、特定の構成プロパティを設定する必要があります。また、資格証明ストアでキーストア・パスワードを入力する必要があります。

8.1.2.3.1 Oracle Identity Federation構成のプロパティの設定

次の5つの「serverconfig」プロパティを次の値に設定する必要があります。

- usewlssslconfig - false

- clientsslkeystoreloc - アイデンティティ・キーストアのパスとファイル名です。パスにはドメイン・ホームからの絶対パスまたは相対パスを指定できます。

- clientsslkeystoretype - アイデンティティ・キーストアのタイプです。タイプを指定しない場合はJKSとみなされます。

- clientssltruststoreloc - 信頼キーストアのパスとファイル名です。パスにはドメイン・ホームからの絶対パスまたは相対パスを指定できます。

- clientssltruststoretype - 信頼キーストアのタイプです。タイプを指定しない場合はJKSとみなされます。

例: WLSTコマンドの使用

setConfigProperty('serverconfig', 'usewlssslconfig', 'false', 'BOOLEAN')
setConfigProperty('serverconfig', 'clientsslkeystoreloc',    '/usr/local/ssl/keystore', 'STRING')
setConfigProperty('serverconfig', 'clientsslkeystoretype', 'JKS', 'STRING')
setConfigProperty('serverconfig', 'clientssltruststoreloc',    '/usr/local/ssl/truststore', 'STRING')
setConfigProperty('serverconfig', 'clientssltruststoretype', 'JKS', 'STRING')

WLSTコマンドの使用方法の詳細は、第9章「Oracle Identity Federationコマンドライン・ツール」を参照してください。

例: MBeanの使用

「serverconfig」という名前のConfigMXBeanで、次の引数を指定して「putProperty」処理を5回呼び出します。

プロパティ名

プロパティ値

プロパティ・タイプ

usewlssslconfig

false

BOOLEAN

clientsslkeystoreloc

/usr/local/ssl/keystore

STRING

clientsslkeystoretype

JKS

STRING

clientssltruststoreloc

/usr/local/ssl/keystore

STRING

clientssltruststoretype

JKS

STRING

詳細は、付録A「Oracle Identity Federation MBean」を参照してください。

8.1.2.3.2 資格証明ストアへのキーストア・パスワードの入力

アイデンティティ・キーストアおよび信頼キーストアのパスワードは、資格証明ストアに格納する必要があります。資格証明ストアに格納するこれらのパスワードの鍵は次のとおりです。

- clientsslkeystorepwd - アイデンティティ・キーストアのパスワードです。

- clientssltruststorepwd - 信頼キーストアのパスワードです。

次の例では、WLSTコマンドを使用して、これらのパスワードを資格証明ストアで作成および更新する方法を示します。この例では、Oracle Identity Federationが「OIF」という名前のアプリケーションでデプロイされていることを前提にしています。アイデンティティ・キーストアおよび信頼キーストアのパスワードはいずれも「mypassword」です。

キーストア資格証明を作成するには、次のようにします。

createCred(map="OIF", key="clientsslkeystorepwd",
user="UniqueUserNameCredential", password="mypassword", desc="identity keystore pwd")

createCred(map="OIF", key="clientssltruststorepwd",
user="UniqueUserNameCredential", password="mypassword", desc="trust keystore pwd")

キーストア資格証明を更新するには、次のようにします。

updateCred(map="OIF", key="clientsslkeystorepwd",
user="UniqueUserNameCredential", password="mypassword", desc="identity keystore pwd")

updateCred(map="OIF", key="clientssltruststorepwd",
user="UniqueUserNameCredential", password="mypassword", desc="trust keystore pwd")

詳細は、第4.5項「Oracle Identity Federationの資格証明の管理」を参照してください。

8.1.2.4 SSL経由によるLDAPサーバーへの接続

Oracle Identity FederationがSSLを使用してLDAPサーバーに接続する必要がある場合、まずOracle WebLogic Server管理コンソールで信頼キーストアにLDAPのCA証明書を追加する必要があります。この情報は、Oracle Identity Federationが実行されている管理対象サーバーのサーバー/キーストア構成画面に表示されます。

また、Oracle Identity Federationの構成で信頼キーストアのパスワードを入力する必要があります(第8.1.2.1項「Oracle WebLogic Serverの構成」および第8.1.2.2項「Oracle Identity Federationでのキーストア・パスワードの構成」を参照)。

注意:

- LDAPサーバーに接続する場合、Oracle Identity Federationではクライアント認証はサポートされません。

- LDAPサーバーに接続する場合、Oracle Identity FederationはWLS信頼キーストアのみを使用します。

SSL経由でLDAPサーバーを検索する場合

ユーザー・データ・ストアまたはフェデレーション・データ・ストアがSSLを使用するLDAPサーバーにあり、Fusion Middleware Control(「管理」→「アイデンティティ」)で検索処理を使用する場合は、LDAPのCA証明書をJVMの cacertキーストアにインポートする必要があります。

検索処理を実行すると、ログに次のようなエラーが表示されます。

SEVERE: NamingException: error while interacting with an LDAP server or JNDI module
javax.naming.NameNotFoundException: remaining name: env/jmx/runtime

これは予期されているもので、検索には影響しません。

8.1.2.5 Fusion Middleware ControlによるOracle Identity Federationターゲットの管理を確実にする方法

管理サーバーと、Oracle Identity Federationをホストする管理対象サーバーに対してSSLを有効にした後、Fusion Middleware Controlで引き続きOracle Identity Federationサーバーを管理できることを確認する必要があります。

Fusion Middleware ControlでOracle Identity Federationサーバー・ターゲットを管理できるようにするには、次の手順を実行します。

1. $INSTANCE_HOME/EMAGENT/EMAGENT/sysman/emd/targets.xmlを探します。
'serviceURL'プロパティのプロトコルを正しいプロトコルに変更します。Oracle Identity Federationターゲットが(ホストとoracle_emd以外に)複数ある場合は、各ターゲットの'serviceURL'を変更する必要があります。

2. $INSTANCE_HOME/EMAGENT/EMAGENT/sysman/config/emd.propertiesを探します。
必要に応じて、'REPOSITORY_URL'のプロトコルを正しいプロトコルに更新します。EMエージェントは、このプロパティを使用してFusion Middleware Controlに接続します。

3. 次のコマンドを使用してEMエージェントを停止します。

$INSTANCE_HOME/bin/opmnctl stopproc ias-component=EMAGNET

4. 次のコマンドを使用してEMエージェントを保護します。

$INSTANCE_HOME/EMAGENT/EMAGENT/bin/emctl secure fmagent -admin_host
<host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>]

5. 次のコマンドを使用してEMエージェントを再起動します。

$INSTANCE_HOME/bin/opmnctl startproc ias-component=EMAGNET

8.1.3 HAモードでのSSLの構成

このトピックの詳細は、第6.4.3項を参照してください。

8.2 署名ウォレットおよび暗号化ウォレットの管理

Oracle Identity Federationには、署名ウォレットおよび暗号化ウォレットを、サービスを中断することなくスムーズに更新するための方法が用意されています。

署名または暗号化ウォレットを置き換えて新しいウォレットをアップロードする必要がある場合、Oracle Identity Federationによって古いウォレットが保存されます。その後サーバーは、古いウォレットが削除されるまで、そのウォレットを引き続き使用します。ただし、生成されるメタデータには新しいウォレットの情報と古いウォレットの情報が含まれます。そのため、変更についてリモート・プロバイダに通知するための時間を取ることができます。

新しいメタデータを作成し、すべてのリモート・プロバイダに配布したら、古いウォレットを削除できます。それ以降、Oracle Identity Federationはすべてのトランザクションで新しくアップロードされたウォレットを使用します。

この項は次のトピックで構成されています。

- 署名パスワードおよび暗号化パスワード

- 署名ウォレットまたは暗号化ウォレットの置換

8.2.1 署名パスワードおよび暗号化パスワード

11gリリース1(11.1.1)パッチ・セット3の時点では、キーストア(署名鍵)のパスワードと暗号化鍵のパスワードを同一にする必要はありません。パスワードの扱い方は次のとおりです。

- ストア・パスワードとキー・パスワードを個別に構成できます。

- 構成しない場合、キー・パスワードはストア・パスワードと同一であるとみなされます。

関連項目:
『Oracle Fusion Middleware管理者ガイド』のキーストア、ウォレットおよび証明書の管理に関する項を参照してください。

8.2.2 署名ウォレットまたは暗号化ウォレットの置換

署名ウォレットまたは暗号化ウォレットを置き換える場合は、次の手順に従います。

1. 新しいウォレットをアップロードします。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「セキュリティおよび信頼」の順に移動します。

3. 「ウォレット」タブで、「更新」をクリックします。

4. 更新するウォレットの「更新」チェック・ボックスを選択します。

5. キーストアのタイプ、ウォレットの場所、パスワードおよび別名を選択します。

6. 「OK」をクリックします。

2. 新しいメタデータを生成し、配布します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「セキュリティおよび信頼」の順に移動します。

3. 「プロバイダ・メタデータ」タブの「メタデータの生成」セクションで、プロバイダのタイプと生成するメタデータのプロトコルを選択して、「生成」をクリックします。

4. 生成されたメタデータを保存します。

5. 生成されたメタデータをすべてのリモート・ピア・プロバイダに配布します。

3. 古いウォレットを削除します。

1. Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「セキュリティおよび信頼」の順に移動します。

3. 「ウォレット」タブで、「更新」をクリックします。

4. 更新したウォレットで、古いウォレットの削除をクリックします。

8.3 Oracle WebLogic ServerでのJCEポリシー・ファイルの設定

Oracle Identity Federationはデフォルトで、暗号化/復号化処理に対してXML暗号化などの低強度の暗号鍵サイズをサポートしています。

AES-256などの強固な対称暗号化アルゴリズムを使用するには、JVMを変更してJava Cryptography Extension (JCE) Unlimited Strength Jurisdictionポリシーを組み込む必要があります。

次の手順を実行します。

1. Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesを次のURLからダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

2. $BEA_HOMEの下にあるすべての$JAVA_HOME/jre/lib/securityディレクトリでファイルを解凍します(これらのディレクトリを検索するには、US_export_policy.jarファイルを探します)。それぞれの$JAVA_HOME/jre/lib/securityディレクトリで、デフォルトの低強度のlocal_policy.jarファイルとUS_export_policy.jarファイルをOracleが提供するファイルで上書きします。

3. 管理サーバーおよびOracle Identity Federationが実行されている管理対象サーバーを再起動します。

9 Oracle Identity Federationコマンドライン・ツール

この章では、Oracle Identity Federationで使用可能なコマンドライン・ツールについて説明します。

- Oracle Identity Federationのコマンドライン・ツールの概要

- Oracle Identity Federationのコマンド

9.1 Oracle Identity Federationのコマンドライン・ツールの概要

WLSTは、Oracle Fusion Middlewareのコンポーネントとアプリケーションの管理に使用するコマンドライン・ユーティリティです。Oracle Enterprise Manager Fusion Middleware Controlに加えて、管理のための別のオプションが用意されています。

関連項目:
WLSTユーティリティのバックグラウンド情報および説明の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスを参照してください。

WLSTコマンドライン・ユーティリティには、Oracle Identity Federationを管理するための様々なツールが用意されています。たとえば、次のような管理に対するコマンドがあります。

- プロパティ管理

- フェデレーション管理

- カスタムSPおよび認証エンジンの管理

- メッセージ・ストアのメンテナンス

9.1.1 WLST環境の設定

WLSTコマンドを実行するには、次のコマンドを実行して環境を設定します。

Linuxの場合

Linuxシステムで環境を設定するための構文は次のとおりです。

bash

export $DOMAIN_HOME=PATH_TO_DOMAIN_HOME

source $ORACLE_HOME/fed/scripts/setOIFEnv.sh
(replace $ORACLE_HOME with the correct path for your environment.)

Windowsの場合

Windowsシステムで環境を設定するための構文は次のとおりです。

set DOMAIN_HOME=PATH_TO_DOMAIN_HOME

%ORACLE_HOME%/fed/scripts/setOIFEnv.cmd

9.1.2 コマンドの実行

次のコマンドを実行してOracle Identity FederationのWLSTスクリプト環境を入力します。

Windowsの場合

IDM_ORACLE_HOME\common\bin\wlst.cmd

Linuxの場合

IDM_ORACLE_HOME/common/bin/wlst.sh

コマンドを実行するには次の形式を使用します。

command-name('param1','param2',...)

次に例を示します。

deleteUserFederations(['user1','user2'])

注意:
connect() URLの入力を求められたら、管理対象サーバーのポートを入力します(管理サーバーのポートではありません)。

9.2 Oracle Identity Federationのコマンド

表9-1に示すWLSTコマンドを使用して、Oracle Identity Federationの構成を表示および管理します。

表9-1 Oracle Identity FederationのWLSTコマンド

使用するコマンド

機能

WLSTでの使用

addConfigListEntryInMap

構成リスト・エントリをマップに追加します。

オンライン

addConfigMapEntryInMap

構成マップ・エントリをマップに追加します。

オンライン

addConfigPropertyListEntry

構成プロパティ・リスト・エントリを追加します。

オンライン

addConfigPropertyMapEntry

構成プロパティ・マップ・エントリを追加します。

オンライン

addCustomAuthnEngine

カスタム認証エンジンを追加します。

オンライン

addCustomSPEngine

カスタムSPエンジンを追加します。

オンライン

addFederationListEntryInMap

特定のリモート・プロバイダの構成のマップにリスト・エントリを追加します。

オンライン

addFederationMapEntryInMap

特定のリモート・プロバイダの構成のマップにマップ・エントリを追加します。

オンライン

addFederationPropertyListEntry

特定のリモート・プロバイダの構成にプロパティ・リスト・エントリを追加します。

オンライン

addFederationPropertyMapEntry

特定のリモート・プロバイダの構成にマップ・エントリを追加します。

オンライン

deleteCustomAuthnEngine

カスタム認証エンジンを削除します。

オンライン

deleteCustomSPEngine

カスタムSPエンジンを削除します。

オンライン

deleteProviderFederation

特定のプロバイダのフェデレーテッド・アイデンティティを削除します。

オンライン

deleteUserFederations

特定のユーザーのフェデレーテッド・アイデンティティを削除します。

オンライン

changeMessageStore

メッセージ・ストアをメモリーまたはRDBMSに変更します。

オンライン

changePeerProviderDescription

ピア・プロバイダの説明を変更します。

オンライン

changeSessionStore

セッション・ストアをメモリーまたはRDBMSに変更します。

オンライン

createConfigPropertyList

構成プロパティ・リストを作成します。

オンライン

createConfigPropertyListInMap

マップに構成プロパティ・リストを作成します。

オンライン

createConfigPropertyMap

構成プロパティ・マップを作成します。

オンライン

createConfigPropertyMapInMap

マップの中に、構成プロパティ・マップをネストして作成します。

オンライン

createFederationPropertyList

特定のリモート・プロバイダの構成にプロパティ・リストを作成します。

オンライン

createFederationPropertyListInMap

特定のリモート・プロバイダの構成のマップにプロパティ・リストを作成します。

オンライン

createFederationPropertyMap

特定のリモート・プロバイダの構成にプロパティ・マップを作成します。

オンライン

createFederationPropertyMapInMap

特定のリモート・プロバイダの構成のマップに、ネストされたプロパティ・マップを作成します。

オンライン

createPeerProviderEntry

ピア・プロバイダ・エントリを作成します。

オンライン

getConfigListValueInMap

マップから構成リスト値を取得します。

オンライン

getConfigMapEntryInMap

マップから構成マップ値を取得します。

オンライン

getConfigProperty

構成プロパティ・エントリを取得します。

オンライン

getConfigPropertyList

構成プロパティ・リストを取得します。

オンライン

getConfigPropertyMapEntry

構成プロパティ・マップ・エントリを取得します。

オンライン

getFederationListValueInMap

特定のリモート・プロバイダの構成のマップからプロパティ・リスト値を取得します。

オンライン

getFederationMapEntryInMap

特定のリモート・プロバイダの構成のマップからプロパティ・マップ値を取得します。

オンライン

getFederationProperty

特定のリモート・プロバイダの構成からプロパティ値を取得します。

オンライン

getFederationPropertyList

特定のリモート・プロバイダの構成からプロパティ・リストを取得します。

オンライン

extractproviderprops

すべてのプロバイダ構成プロパティをテキスト・ファイルにエクスポートします。

スクリプト

setproviderprops

プロバイダのプロパティを入力テキスト・ファイルに基づいて設定します。

スクリプト

getFederationPropertyMapEntry

特定のリモート・プロバイダの構成からプロパティ・マップ・エントリを取得します。

オンライン

listCustomAuthnEngines

カスタム認証エンジンのリストを表示します。

オンライン

listCustomSPEngines

カスタムSPエンジンのリストを表示します。

オンライン

loadMetadata

ファイルからメタデータをロードします。

オンライン

oifStatus

Oracle Identity Federationサーバーのステータスを表示します。

オンライン

removeConfigListInMap

マップから構成リストを削除します。

オンライン

removeConfigMapEntryInMap

マップ内の構成マップ・エントリを削除します。

オンライン

removeConfigMapInMap

ネストされた構成マップを削除します。

オンライン

removeConfigProperty

構成プロパティを削除します。

オンライン

removeConfigPropertyList

プロパティ・リストを削除します。

オンライン

removeConfigPropertyMap

プロパティ・マップを削除します。

オンライン

removeConfigPropertyMapEntry

プロパティ・マップ内のエントリを削除します。

オンライン

removeFederationListInMap

特定のリモート・プロバイダの構成のマップからリストを削除します。

オンライン

removeFederationMapInMap

特定のリモート・プロバイダの構成のマップからネストされたマップを削除します。

オンライン

removeFederationMapEntryInMap

特定のリモート・プロバイダの構成のマップからネストされたマップ・プロパティ・エントリを削除します。

オンライン

removeFederationProperty

特定のリモート・プロバイダの構成のプロパティを削除します。

オンライン

removeFederationPropertyList

特定のリモート・プロバイダの構成のプロパティ・リストを削除します。

オンライン

removeFederationPropertyMap

プロパティ・マップを削除します。

オンライン

removeFederationPropertyMapEntry

特定のリモート・プロバイダの構成のマップからプロパティを削除します。

オンライン

removePeerProviderEntry

ピア・プロバイダ・エントリを削除します。

オンライン

setConfigProperty

構成プロパティを設定します。

オンライン

setCustomAuthnEngine

カスタム認証エンジンを定義します。

オンライン

setCustomSPEngine

カスタムSPエンジンを定義します。

オンライン

setFederationProperty

特定のリモート・プロバイダの構成にプロパティを設定します。

オンライン

詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』を参照してください。

9.2.1 addConfigListEntryInMap

マップの中にネストされているリストにプロパティ値を追加するオンライン・コマンドです。

9.2.1.1 説明

このコマンドは、config.xml内のマップの中にネストされているリストにプロパティ値を追加します。

9.2.1.2 構文

addConfigListEntryInMap('configName', 'mapname', 'listName', 'value', 'type')

引数

定義

configname

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapname

config.xml内の変更するプロパティ・マップの名前を指定します。

listname

リストの名前を指定します。

value

プロパティ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.1.3 例

次のコマンドは、サーバー構成のマップ・リストにvalueAを追加します。

wls:/mydomain/serverConfig> addConfigListEntryInMap('serverconfig','mymap','mylistA','valueA','string')

9.2.2 addConfigMapEntryInMap

マップに、ネストされたマップ・プロパティ・エントリを追加するオンライン・コマンドです。

9.2.2.1 説明

このコマンドは、config.xml内のマップの中にネストされているマップにプロパティ名/値ペアを追加します。

9.2.2.2 構文

addConfigMapEntryInMap('configName', 'mapname', 'nestedMapName', 'propName', 'value', 'type')

引数

定義

configname

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapname

config.xml内の変更するプロパティ・マップの名前を指定します。

nestedmapname

変更するネストされたプロパティ・マップの名前を示します。

propname

リストの名前を指定します。

value

プロパティ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.2.3 例

次のコマンドは、マップmymapの中のnestedmapBにブール型の名前/値ペアを追加します。

wls:/mydomain/serverConfig> addConfigMapEntryInMap('serverconfig','mymap','nestedmapB','myvarB','true',
'boolean')

9.2.3 addConfigPropertyListEntry

config.xmlにリスト・プロパティ・エントリを追加するオンライン・コマンドです。

9.2.3.1 説明

このコマンドは、config.xml内のリストにプロパティ値を追加します。

9.2.3.2 構文

addConfigPropertyListEntry('configName', 'listName', 'value', 'type')

引数

定義

configname

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

listname

config.xml内の更新するプロパティ・リストの名前を指定します。

value

新しいプロパティ・リスト値を指定します。入力した値がリストに追加されます。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.3.3 例

次のコマンドは、mylistAに文字列値を追加します。

wls:/mydomain/serverConfig> addConfigPropertyListEntry('serverconfig','mylistA','valueA','string')

9.2.4 addConfigPropertyMapEntry

config.xml内のマップにプロパティ名/値エントリを追加するオンライン・コマンドです。

9.2.4.1 説明

このコマンドは、config.xml内のマップにプロパティ名/値エントリを追加します。

9.2.4.2 構文

addConfigPropertyMapEntry('configName', 'mapName', 'propName','value', 'type')

引数

定義

configname

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapname

config.xmlのプロパティ・マップの名前を指定します。

propname

プロパティ・マップの名前を指定します。

value

追加するプロパティ・マップ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.4.3 例

次のコマンドは、マップに文字列型のvalueAを追加します。

wls:/mydomain/serverConfig> addConfigPropertyMapEntry('serverconfig','mymapA','myvarA','valueA','string')

9.2.5 addCustomAuthnEngine

カスタム認証統合エンジンを追加するオンライン・コマンドです。

9.2.5.1 説明

このコマンドは、config.xmlにカスタム認証統合エンジンを追加します。

9.2.5.2 構文

addCustomAuthnEngine('name' 'enabled' 'webContext' 'authnRelativePath' 'logoutRelativePath' 'logoutEnabled')

引数

定義

name

カスタム・エンジンの名前を指定します。

enabled

このフラグには、エンジンを有効にする(true)か、無効にする(false)かを指定します。

webContext

エンジンのWebコンテキストを指定します。

authnRelativePath

エンジンの認証相対パスURLを指定します。

logoutRelativePath

エンジンのログアウト相対パスURLを指定します。

logoutEnabled

このフラグは、エンジンのログアウトを有効にする場合はtrueに設定します。それ以外の場合はfalseに設定します。

9.2.5.3 例

次のコマンドは、testという名前のエンジンを定義し、有効に設定します。

wls:/mydomain/serverConfig> addCustomAuthnEngine('test','true')

9.2.6 addCustomSPEngine

カスタム・サービス・プロバイダ(SP)エンジンを追加するオンライン・コマンドです。

9.2.6.1 説明

このコマンドは、config.xmlにカスタムSP統合エンジンを追加します。

9.2.6.2 構文

addCustomSPEngine('name' 'enabled' 'authnMech' 'webContext' 'authnRelativePath' 'logoutRelativePath' 'logoutEnabled')

引数

定義

name

カスタム・エンジンの名前を指定します。

enabled

このフラグには、エンジンを有効にする(true)か、無効にする(false)かを指定します。

authnMech

エンジンの認証メカニズムを指定します。

webContext

エンジンのWebコンテキストを指定します。

authnRelativePath

エンジンの認証相対パスURLを指定します。

logoutRelativePath

エンジンのログアウト相対パスURLを指定します。

logoutEnabled

このフラグは、エンジンのログアウトを有効にする場合はtrueに設定します。それ以外の場合はfalseに設定します。

9.2.6.3 例

次のコマンドは、エンジンを追加し、そのステータスを無効に設定します。

addCustomSPEngine('new engine','false','oracle:fed:authentication:unspecified','webcontext')

9.2.7 addFederationListEntryInMap

マップにリスト・プロパティ・エントリを追加するオンライン・コマンドです。

9.2.7.1 説明

このコマンドは、cot.xml内のマップの中にネストされているリストにプロパティ値を追加します。

9.2.7.2 構文

addFederationListEntryInMap('providerID', 'mapname', 'listName', 'value', 'type')

引数

定義

providerID

プロバイダIDを指定します。

mapname

cot.xml内の変更するプロパティ・マップの名前を指定します。

listname

マップに追加するプロパティ・リストの名前を指定します。

value

追加するプロパティ・リスト値を指定します。入力した値がリストに追加されます。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.7.3 例

次のコマンドは、mymapにブール型プロパティ・リストを追加します。

wls:/mydomain/serverConfig> addFederationListEntryInMap('providerB','mymap','mylistB','true','boolean')

9.2.8 addFederationMapEntryInMap

マップに、ネストされたマップ・プロパティ・エントリを追加するオンライン・コマンドです。

9.2.8.1 説明

このコマンドは、cot.xml内のマップの中にネストされているマップにプロパティ名/値ペアを追加します。

9.2.8.2 構文

addFederationMapEntryInMap('providerID', 'mapname', 'nestedMapName', 'propName', 'value', 'type')

引数

定義

providerID

プロバイダIDを指定します。

mapname

cot.xml内の変更するプロパティ・マップの名前を指定します。

nestedMapName

変更するネストされたプロパティ・マップの名前を指定します。

propName

マップで更新するプロパティの名前を指定します。

value

追加するプロパティ値を指定します。入力した値がリストに追加されます。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.8.3 例

次のコマンドは、ネストされたマップの中にあるmyvarAプロパティに、文字列型の値を追加します。

wls:/mydomain/serverConfig> addFederationMapEntryInMap('providerA','mymap','nestedmapA','myvarA','valueA',
'string')

9.2.9 addFederationPropertyListEntry

リスト・プロパティ・エントリを追加するオンライン・コマンドです。

9.2.9.1 説明

このコマンドは、cot.xml内のリストにプロパティ値を追加します。

9.2.9.2 構文

addFederationPropertyListEntry('providerID', 'listName', 'value', 'type')

引数

定義

providerID

プロバイダIDを指定します。

listname

更新するプロパティ・リストの名前を指定します。

value

追加するプロパティ・リスト値を指定します。入力した値がリストに追加されます。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.9.3 例

次のコマンドは、指定したプロパティ・リストに文字列型の値を追加します。

wls:/mydomain/serverConfig> addFederationPropertyListEntry('providerA','mylistA','valueA','string')

9.2.10 addFederationPropertyMapEntry

マップにプロパティ名/値エントリを追加するオンライン・コマンドです。

9.2.10.1 説明

このコマンドは、cot.xml内のマップにプロパティ名/値ペアを追加します。

9.2.10.2 構文

addFederationPropertyMapEntry('providerID', 'mapName', 'propName','value', 'type')

引数

定義

providerID

プロバイダIDを指定します。

mapname

cot.xml内の変更するプロパティ・マップの名前を指定します。

propName

マップに追加するプロパティの名前を指定します。

value

追加するプロパティ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.10.3 例

次のコマンドは、マップにブール型プロパティmyvarBを追加します。

wls:/mydomain/serverConfig> addFederationPropertyMapEntry('providerA','mymapB','myvarB','true','boolean')

9.2.11 deleteCustomAuthnEngine

構成からカスタム認証統合エンジンを削除するオンライン・コマンドです。

9.2.11.1 説明

このコマンドは、config.xml内のカスタム認証統合エンジンを削除します。config.xml内の既存のカスタム認証エンジンのエンジンIDを指定する必要があります。

9.2.11.2 構文

deleteCustomAuthnEngine('engineID')

引数

定義

engineID

削除する既存のエンジンのエンジンIDを指定します。

9.2.11.3 例

次のコマンドは、id1234というIDの認証エンジンを削除します。

wls:/mydomain/serverConfig> deleteCustomAuthnEngine('id1234')

9.2.12 deleteCustomSPEngine

構成からカスタム・サービス・プロバイダ(SP)統合エンジンを削除するオンライン・コマンドです。

9.2.12.1 説明

このコマンドは、config.xml内のカスタムSP統合エンジンを削除します。config.xml内の既存のカスタムSPエンジンのエンジンIDを指定する必要があります。

9.2.12.2 構文

ddeleteCustomSPEngine('engineID')

引数

定義

engineID

削除する既存のエンジンのエンジンIDを指定します。

9.2.12.3 例

次のコマンドは、id1234というIDのエンジンを削除します。

wls:/mydomain/serverConfig> deleteCustomSPEngine('id1234')

9.2.13 deleteProviderFederation

指定したプロバイダのフェデレーションを削除するオンライン・コマンドです。

9.2.13.1 説明

このコマンドは、指定したプロバイダIDのフェデレーションを削除します。

9.2.13.2 構文

deleteProviderFederation('providerID')

引数

定義

providerID

フェデレーションを削除するピア・プロバイダのプロバイダIDを指定します。

9.2.13.3 例

次のコマンドは、providerAを削除します。

wls:/mydomain/serverConfig> deleteProviderFederation(providerA)

9.2.14 deleteUserFederations

指定したユーザーのフェデレーションを削除するオンライン・コマンドです。

9.2.14.1 説明

このコマンドは、指定したユーザーのリストのフェデレーションを削除します。

9.2.14.2 構文

deleteUserFederations(['user1,..'])

引数

定義

user1

フェデレーションを削除するユーザーのコンマ区切りのリストを指定します。1つ以上のユーザーを指定する必要があります。

9.2.14.3 例

次のコマンドは、3つのユーザーのフェデレーションを削除します。

wls:/mydomain/serverConfig> deleteUserFederations(['userA','userB','userC'])

9.2.15 changeMessageStore

メッセージ・ストアをメモリーとRDBMSとの間で切り替えるオンライン・コマンドです。

9.2.15.1 説明

このコマンドは、メッセージ・ストアをメモリーまたはRDBMSに変更します。

9.2.15.2 構文

changeMessageStore('type','jndiname')

引数

定義

type

ストアのタイプ(RDBMSまたはメモリー)を指定します。デフォルトはメモリーです。

jndiname

ストアに設定するjndi名を指定します。タイプがRDBMSの場合は必須です。

9.2.15.3 例

次のコマンドは、メッセージ・ストアをRDBMSに変更します。

wls:/mydomain/serverConfig> changeMessageStore('RDBMS','jdbc/mydb')

9.2.16 changePeerProviderDescription

ピア・プロバイダの説明を変更するオンライン・コマンドです。

9.2.16.1 説明

このコマンドは、cot.xml内のピア・プロバイダの説明を更新します。

9.2.16.2 構文

changePeerProviderDescription('providerID','description')

引数

定義

providerID

プロバイダIDを指定します。

description

プロバイダの説明を指定します。

9.2.16.3 例

次のコマンドは、プロバイダの説明を更新します。

wls:/mydomain/serverConfig> changePeerProviderDescription('providerA','new description')

9.2.17 changeSessionStore

セッション・ストアをメモリーとRDBMSとの間で切り替えるオンライン・コマンドです。

9.2.17.1 説明

このコマンドは、セッション・ストアをメモリーまたはRDBMSに変更します。

9.2.17.2 構文

changeSessionStore('type','jndiname')

引数

定義

type

ストアのタイプ(RDBMSまたはメモリー)を指定します。デフォルトはメモリーです。

jndiname

ストアに設定するjndi名を指定します。タイプがRDBMSの場合は必須です。

9.2.17.3 例

次のコマンドは、セッション・ストアをRDBMSに変更します。

wls:/mydomain/serverConfig> changeSessionStore('RDBMS','jdbc/mydb')

9.2.18 createConfigPropertyList

プロパティ・リストを作成するオンライン・コマンドです。

9.2.18.1 説明

このコマンドは、config.xmlにプロパティ・リストを作成します。

9.2.18.2 構文

createConfigPropertyList('configName', 'listName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

listName

プロパティ・リスト名を指定します。

9.2.18.3 例

次のコマンドは、プロパティ・リストmylistAを作成します。

wls:/mydomain/serverConfig> createConfigPropertyList('serverconfig','mylistA')

9.2.19 createConfigPropertyListInMap

プロパティ・マップの中にネストされたプロパティ・リストを作成するオンライン・コマンドです。

9.2.19.1 説明

このコマンドは、config.xml内のプロパティ・マップの中に、プロパティ・リストをネストして作成します。

9.2.19.2 構文

createConfigPropertyListInMap('configName', 'mapName', 'listName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

ネストされたリストを含める既存のプロパティ・マップを指定します。

listName

プロパティ・リスト名を指定します。

9.2.19.3 例

次のコマンドは、プロパティ・マップの中に、プロパティ・リストmylistAをネストして作成します。

wls:/mydomain/serverConfig> createConfigPropertyListInMap('serverconfig','mymapA','mylistA')

9.2.20 createConfigPropertyMap

プロパティ・マップを作成するオンライン・コマンドです。

9.2.20.1 説明

このコマンドは、config.xmlにプロパティ・マップを作成します。

9.2.20.2 構文

createConfigPropertyMap('configName', 'mapName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

作成するプロパティ・マップを指定します。

9.2.20.3 例

次のコマンドは、プロパティ・マップmymapAを作成します。

wls:/mydomain/serverConfig> createConfigPropertyMap('serverconfig','mymapA')

9.2.21 createConfigPropertyMapInMap

プロパティ・マップを作成するオンライン・コマンドです。

9.2.21.1 説明

このコマンドは、config.xmlにプロパティ・マップを作成します。

9.2.21.2 構文

ccreateConfigPropertyMapInMap('serverconfig','mymapA','nestedmapA')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

既存のプロパティ・マップの名前を指定します。

nestedMapName

mapNameの中にネストして作成するプロパティ・マップの名前を指定します。

9.2.21.3 例

次のコマンドは、ネストされたプロパティ・マップnestedmymapAを作成します。

wls:/mydomain/serverConfig> createConfigPropertyMapInMap('serverconfig','mymapA','nestedmapA')

9.2.22 createFederationPropertyList

プロパティ・リストを作成するオンライン・コマンドです。

9.2.22.1 説明

このコマンドは、cot.xmlにプロパティ・リストを作成します。

9.2.22.2 構文

引数

定義

providerID

プロバイダIDを指定します。

listName

プロパティ・リストの名前を指定します。

9.2.22.3 例

次のコマンドは、プロパティ・リストmylistAを作成します。

wls:/mydomain/serverConfig> createFederationPropertyList('providerA','mylistA')

9.2.23 createFederationPropertyListInMap

プロパティ・マップの中にネストされたプロパティ・リストを作成するオンライン・コマンドです。

9.2.23.1 説明

このコマンドは、cot.xml内のプロパティ・マップの中に、プロパティ・リストをネストして作成します。

9.2.23.2 構文

createFederationPropertyListInMap('providerID', 'mapName', 'listName')

引数

定義

providerID

プロバイダIDを指定します。

mapName

ネストされたリストを含める既存のプロパティ・マップを指定します。

listName

プロパティ・リストの名前を指定します。

9.2.23.3 例

次のコマンドは、ネストされたプロパティ・リストmylistAを作成します。

wls:/mydomain/serverConfig> createFederationPropertyListInMap('providerA','mymapA','mylistA')

9.2.24 createFederationPropertyMap

プロパティ・マップを作成するオンライン・コマンドです。

9.2.24.1 説明

このコマンドは、cot.xmlにプロパティ・マップを作成します。

9.2.24.2 構文

createFederationPropertyMap('providerID', 'mapName')

引数

定義

providerID

プロバイダIDを指定します。

mapName

cot.xmlに追加するプロパティ・マップの名前を指定します。

9.2.24.3 例

次のコマンドは、プロパティ・マップmymapAを作成します。

wls:/mydomain/serverConfig> createFederationPropertyMap('providerA','mymapA')

9.2.25 createFederationPropertyMapInMap

ネストされたプロパティ・マップを作成するオンライン・コマンドです。

9.2.25.1 説明

このコマンドは、cot.xml内のプロパティ・マップの中に別のプロパティ・マップをネストして作成します。

9.2.25.2 構文

createFederationPropertyMapInMap('providerID', 'mapName', 'nestedMapName')

引数

定義

providerID

プロバイダIDを指定します。

mapName

既存のプロパティ・マップの名前を指定します。

nestedMapName

cot.xml内のmapNameの中にネストして作成するプロパティ・マップの名前を指定します。

9.2.25.3 例

次のコマンドは、ネストされたプロパティ・マップnestedmapAを作成します。

wls:/mydomain/serverConfig> createFederationPropertyMapInMap('providerA','mymapA','nestedmapA')

9.2.26 createPeerProviderEntry

ピア・プロバイダ・プロパティ・マップ・エントリを作成するオンライン・コマンドです。

9.2.26.1 説明

このコマンドは、cot.xmlにマップ・プロパティ・エントリとしてピア・プロバイダを作成します。

9.2.26.2 構文

createPeerProviderEntry('providerID', 'description', 'providerType','version')

引数

定義

providerID

作成するプロバイダIDを指定します。

description

プロバイダIDの説明です。

providerType

作成するピア・プロバイダのプロバイダ・タイプを指定します。

version

作成するピア・プロバイダのバージョンを指定します。

9.2.26.3 例

次のコマンドは、SAML 2.0サービス・プロバイダを作成します。

wls:/mydomain/serverConfig> createPeerProviderEntry('providerA','idp test','SP','SAML2.0')

9.2.27 getConfigListValueInMap

マップの中にネストされているリストを返すオンライン・コマンドです。

9.2.27.1 説明

このコマンドは、config.xml内のマップの中にネストされているリストを返します。

9.2.27.2 構文

getConfigListValueInMap('configName', 'mapName', 'listName')

引数

定義

configName

アクセスする構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

プロパティ・マップの名前を指定します。

listName

マップからフェッチするリストの名前を指定します。

9.2.27.3 例

次のコマンドは、mylistAを返します。

wls:/mydomain/serverConfig> getConfigListValueInMap('serverConfig','mymapA','mylistA'

9.2.28 getConfigMapEntryInMap

マップの中にネストされているマップ・プロパティ・エントリを返すオンライン・コマンドです。

9.2.28.1 説明

このコマンドは、config.xml内のマップの中にネストされているマップ・プロパティ・エントリを返します。

9.2.28.2 構文

getConfigMapEntryInMap('configName', 'mapname', 'nestedMapName', 'propName')

引数

定義

configName

アクセスする構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

プロパティ・マップの名前を指定します。

nestedmapName

ネストされたプロパティ・マップの名前を指定します。

propName

ネストされたマップからフェッチするプロパティの名前を指定します。

9.2.28.3 例

次のコマンドは、プロパティ・エントリmyvarAを返します。

wls:/mydomain/serverConfig> getConfigMapEntryInMap('serverconfig','mymap','nestedmapA','myvarA')

9.2.29 getConfigProperty

プロパティ値を返すオンライン・コマンドです。

9.2.29.1 説明

このコマンドは、config.xml内のプロパティ値を返します。

9.2.29.2 構文

getConfigProperty('configName', 'propName')

引数

定義

configName

アクセスする構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

propName

ネストされたマップからフェッチするプロパティの名前を指定します。

9.2.29.3 例

次のコマンドは、プロパティmyvarAを返します。

wls:/mydomain/serverConfig> getConfigProperty('serverconfig','myvarA')

9.2.30 getConfigPropertyList

プロパティ・リストを返すオンライン・コマンドです。

9.2.30.1 説明

このコマンドは、config.xml内のプロパティ・リストを返します。

9.2.30.2 構文

getConfigPropertyList('configName', 'listName')

引数

定義

configName

構成名を指定します。

listName

config.xmlからフェッチするプロパティ・リストの名前を指定します。

9.2.30.3 例

次のコマンドは、mylistAを返します。

wls:/mydomain/serverConfig> getConfigPropertyList('serverconfig','mylistA')

9.2.31 getConfigPropertyMapEntry

マップ内のプロパティ値を返すオンライン・コマンドです。

9.2.31.1 説明

このコマンドは、config.xml内のマップからプロパティ値を返します。

9.2.31.2 構文

getConfigPropertyMapEntry('configName', 'mapName', 'propName')

引数

定義

configName

構成名(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

プロパティ・マップの名前を指定します。

propName

config.xml内のマップからフェッチするプロパティの名前を指定します。

9.2.31.3 例

次のコマンドは、プロパティpropAを返します。

wls:/mydomain/serverConfig> getConfigPropertyMapEntry('serverconfig','mapA', 'propA')

9.2.32 getFederationListValueInMap

マップの中にネストされているリスト値を返すオンライン・コマンドです。

9.2.32.1 説明

このコマンドは、cot.xml内のマップの中にネストされているリスト値を返します。

9.2.32.2 構文

getFederationListValueInMap('providerID', 'mapName', 'listName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

プロパティ・マップの名前を指定します。

listName

マップからフェッチするリストの名前を指定します。

9.2.32.3 例

次のコマンドは、ネストされたリストmylistAを返します。

wls:/mydomain/serverConfig> getFederationListValueInMap('providerA','mymapA','mylistA')

9.2.33 getFederationMapEntryInMap

マップの中にネストされているマップ・プロパティ・エントリを返すオンライン・コマンドです。

9.2.33.1 説明

このコマンドは、cot.xml内のマップの中にネストされているマップ・プロパティ・エントリを返します。

9.2.33.2 構文

getFederationMapEntryInMap('providerID', 'mapname', 'nestedMapName', 'propName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

プロパティ・マップの名前を指定します。

nestedmapName

ネストされたプロパティ・マップの名前を指定します。

propName

ネストされたマップからフェッチするプロパティの名前を指定します。

9.2.33.3 例

次のコマンドは、プロパティ・エントリmyvarAを返します。

wls:/mydomain/serverConfig> getFederationMapEntryInMap('providerA','mymap','nestedmapA','myvarA')

9.2.34 getFederationProperty

プロパティ値を返すオンライン・コマンドです。

9.2.34.1 説明

このコマンドは、cot.xml内のプロパティ値を返します。

9.2.34.2 構文

getFederationProperty('providerID', 'propName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

propName

cot.xmlからフェッチするプロパティの名前を指定します。

9.2.34.3 例

次のコマンドは、プロパティmyvarAを返します。

wls:/mydomain/serverConfig> getFederationProperty('providerA','myvarA')

9.2.35 getFederationPropertyList

プロパティ・リストを返すオンライン・コマンドです。

9.2.35.1 説明

このコマンドは、cot.xml内のプロパティ・リストを返します。

9.2.35.2 構文

getFederationPropertyList('providerID', 'listName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

listName

マップからフェッチするリストの名前を指定します。

9.2.35.3 例

次のコマンドは、リストmylistAを返します。

wls:/mydomain/serverConfig> getFederationPropertyList('providerA','mylistA')

9.2.36 extractproviderprops

プロバイダのプロパティをエクスポートするスクリプト・コマンドです。

注意:
これはスクリプト・コマンドです。オンラインのWLSTプロンプトから直接実行することはできません。Oracle Identity Federationのスクリプトは、$ORACLE_HOME/fed/scriptsにあります。

9.2.36.1 説明

指定したプロバイダのすべての構成プロパティを抽出して、それらをテキスト・ファイルにエクスポートするスクリプト・コマンドです。後でこのファイルを使用して、同じプロパティを別のプロバイダに設定できます。

9.2.36.2 構文

Windowsの場合

IDM_ORACLE_HOME\common\bin\wlst.cmd extractproviderprops.py
providerID filename

Linuxの場合

IDM_ORACLE_HOME/common/bin/wlst.sh extractproviderprops.py
providerID filename

引数

定義

providerID

プロパティを抽出するプロバイダの名前を指定します。

filename

プロバイダのプロパティを抽出するテキスト・ファイルの名前を指定します。

スクリプトの実行時に、WebLogic管理者資格証明書および接続URLの入力を求められます。接続URLには管理サーバーのポートではなく、管理対象サーバーのポートを指定してください。

ファイル・フォーマット

抽出ファイルの形式は次のとおりです。

TYPE:NAME:PROPNAME:PROPVALUE:PROPTYPE

次に例を示します。

X:X:sendattribute:false:boolean
MAP:attributelist/mailemail:datastore-attr:mail:string
LIST:sendattributefornameid:unspecified::string

9.2.37 setproviderprops

テキスト・ファイルの値を使用して、プロバイダのプロパティを設定するスクリプト・コマンドです。

注意:
これはスクリプト・コマンドです。オンラインのWLSTプロンプトから直接実行することはできません。Oracle Identity Federationのスクリプトは、$ORACLE_HOME/fed/scriptsにあります。

9.2.37.1 説明

テキスト・ファイルの値を使用して、プロバイダのプロパティを設定するスクリプト・コマンドです。

テキスト・ファイルはextractproviderpropsコマンドで生成します。

9.2.37.2 Syntax

Windowsの場合

IDM_ORACLE_HOME\common\bin\wlst.cmd setproviderprops.py providerID filename

Linuxの場合

IDM_ORACLE_HOME/common/bin/wlst.sh setproviderprops.py providerID filename

引数

定義

providerID

プロパティを更新するプロバイダの名前を指定します。

filename

プロパティを読み取る入力ファイルの名前を指定します。

スクリプトの実行時に、WebLogic管理者資格証明書および接続URLの入力を求められます。接続URLには管理サーバーのポートではなく、管理対象サーバーのポートを指定してください。

9.2.38 getFederationPropertyMapEntry

マップ内のプロパティ値を返すオンライン・コマンドです。

9.2.38.1 説明

このコマンドは、cot.xml内のマップからプロパティ値を返します。

9.2.38.2 構文

getFederationPropertyMapEntry('providerID', 'mapName', 'propName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

プロパティ・マップの名前を指定します。

propName

ネストされたマップからフェッチするプロパティの名前を指定します。

9.2.38.3 例

次のコマンドは、マップからプロパティpropAを返します。

wls:/mydomain/serverConfig> getFederationPropertyMapEntry('providerA','mapA', 'propA')

9.2.39 listCustomAuthnEngines

カスタム認証統合エンジンのリストを返すオンライン・コマンドです。

9.2.39.1 説明

このコマンドは、config.xmlからカスタム認証統合エンジンのリストを返します。

9.2.39.2 構文

listCustomAuthnEngines()

9.2.39.3 例

次のコマンドは、すべてのSPエンジンのリストを返します。

wls:/mydomain/serverConfig> listCustomAuthnEngines()

9.2.40 listCustomSPEngines

カスタムSP統合エンジンのリストを返すオンライン・コマンドです。

9.2.40.1 説明

このコマンドは、config.xmlからカスタム・サービス・プロバイダ(SP)統合エンジンのリストを返します。

9.2.40.2 構文

listCustomSPEngines()

9.2.40.3 例

次のコマンドは、すべてのSP統合エンジンのリストを返します。

wls:/mydomain/serverConfig> listCustomSPEngines()

9.2.41 loadMetadata

入力ファイルからメタデータをロードするオンライン・コマンドです。

9.2.41.1 説明

このコマンドは、入力ファイルからcot.xmlにメタデータをロードします。

9.2.41.2 構文

loadMetadata('metadatafile','description')

引数

定義

metadatafile

追加または更新するピア・プロバイダのメタデータを指定します。

description

ロードするピア・プロバイダの簡単な説明です。

9.2.41.3 例

次のコマンドは、ファイルmetadatafile.xmlからメタデータをロードします。

wls:/mydomain/serverConfig> loadMetadata('/home/metadatafile.xml','some description')

9.2.42 oifStatus

WLSTが接続している管理対象サーバーのOracle Identity Federationアプリケーションの現行のステータスを報告するオンライン・コマンドです。

9.2.42.1 説明

このコマンドは、管理対象サーバーのOracle Identity Federationの現行のステータスを表示します。

9.2.42.2 構文

oifStatus('serverurl', 'configfile', 'keyfile')

引数

定義

serverurl

管理対象サーバーのURLを指定します。

configfile

WLST storeUserConfigコマンドで作成された事前定義済のユーザー構成ファイルです。

keyfile

WLST storeUserConfigコマンドで作成された事前定義済のキー・ファイルです。

9.2.42.3 例

次のコマンドでは、引数が指定されていないため、WLSTによってOracle WebLogic Serverのユーザー名、パスワードおよび管理対象サーバーのURLを入力するよう求められ、入力後にフェデレーション・サーバーのステータスが表示されます。

wls:/mydomain/serverConfig> oifStatus()

次のコマンドでは、管理対象サーバーのURLのみが指定されているため、WLSTによってOracle WebLogic Serverのユーザー名とパスワードを入力するよう求められ、入力後にフェデレーション・サーバーのステータスが表示されます。

wls:/mydomain/serverConfig> oifStatus('', '', 't3://localhost:7499')

次のコマンドでは、WLSTに必要な引数がすべて指定されているため、フェデレーション・サーバーのステータスが表示されます。

wls:/mydomain/serverConfig> oifStatus('configfileA', 'keyfileB', 't3://localhost:7499')

9.2.43 removeConfigListInMap

マップの中にネストされているリスト・プロパティを削除するオンライン・コマンドです。

9.2.43.1 説明

このコマンドは、config.xml内のマップの中にネストされているリスト・プロパティを削除します。

9.2.43.2 構文

removeConfigListInMap('configName', 'mapName', 'listName')

引数

定義

configName

アクセスする構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

プロパティ・マップの名前を指定します。

listName

マップから削除するリストの名前を指定します。

9.2.43.3 例

次のコマンドは、リスト・プロパティmylistAを削除します。

wls:/mydomain/serverConfig> removeConfigListInMap('serverConfig','mymapA','mylistA')

9.2.44 removeConfigMapEntryInMap

マップの中にネストされているマップ・プロパティを削除するオンライン・コマンドです。

9.2.44.1 説明

このコマンドは、config.xml内のマップの中にネストされているマップ・プロパティ・エントリを削除します。

9.2.44.2 構文

oifStatus('serverurl', 'configfile', 'keyfile')

引数

定義

serverurl

アクセスする構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

configfile

プロパティ・マップの名前を指定します。

keyfile

ネストされたプロパティ・マップの名前を指定します。

9.2.44.3 例

次のコマンドは、ネストされたプロパティmyvarAを削除します。

wls:/mydomain/serverConfig> removeConfigMapEntryInMap('serverconfig','mymap','nestedmapA','myvarA')

9.2.45 removeConfigMapInMap

マップの中にネストされているマップ・プロパティを削除するオンライン・コマンドです。

9.2.45.1 説明

このコマンドは、config.xml内のマップの中にネストされているマップ・プロパティ・エントリを削除します。

9.2.45.2 構文

removeConfigMapEntryInMap('configName', 'mapname', 'nestedMapName', 'propName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

プロパティ・マップの名前を指定します。

nestedmapName

ネストされたプロパティ・マップの名前を指定します。

propName

ネストされたマップから削除するプロパティの名前を指定します。

9.2.45.3 例

次のコマンドは、ネストされたプロパティmyvarAを削除します。

wls:/mydomain/serverConfig> removeConfigMapEntryInMap('serverconfig','mymap','nestedmapA','myvarA')

9.2.46 removeConfigProperty

構成プロパティを削除するオンライン・コマンドです。

9.2.46.1 説明

このコマンドは、config.xml内のプロパティを削除します。

9.2.46.2 構文

removeConfigProperty('configName', 'propName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

propName

削除するプロパティの名前を指定します。

9.2.46.3 例

次のコマンドは、プロパティmyvarAを削除します。

wls:/mydomain/serverConfig> removeConfigProperty('serverconfig','myvarA')

9.2.47 removeConfigPropertyList

構成プロパティ・リストを削除するオンライン・コマンドです。

9.2.47.1 説明

このコマンドは、config.xml内のプロパティ・リストを削除します。

9.2.47.2 構文

removeConfigPropertyList('configName', 'listName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

listName

削除するプロパティ・リストの名前を指定します。

9.2.47.3 例

次のコマンドは、プロパティ・リストmylistAを削除します。

wls:/mydomain/serverConfig> removeConfigPropertyList('serverconfig','mylistA')

9.2.48 removeConfigPropertyMap

プロパティ・マップを削除するオンライン・コマンドです。

9.2.48.1 説明

このコマンドは、config.xml内のプロパティ・マップを削除します。

9.2.48.2 構文

removeConfigPropertyMap('configName', 'mapName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

削除するプロパティ・マップの名前を指定します。

9.2.48.3 例

次のコマンドは、mapAを削除します。

wls:/mydomain/serverConfig> removeConfigPropertyMap('serverconfig','mapA')

9.2.49 removeConfigPropertyMapEntry

マップからプロパティ値を削除するオンライン・コマンドです。

9.2.49.1 説明

このコマンドは、config.xml内のマップからプロパティ値を削除します。

9.2.49.2 構文

removeConfigPropertyMapEntry('configName', 'mapName', 'propName')

引数

定義

configName

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

mapName

更新するプロパティ・マップの名前を指定します。

propName

マップから削除するプロパティの名前を指定します。

9.2.49.3 例

次のコマンドは、プロパティpropAを削除します。

wls:/mydomain/serverConfig> removeConfigPropertyMapEntry('serverconfig','mapA', 'propA')

9.2.50 removeFederationListInMap

マップ内のプロパティ・リストを削除するオンライン・コマンドです。

9.2.50.1 説明

このコマンドは、cot.xml内のマップからプロパティ・リストを削除します。

9.2.50.2 構文

removeFederationListInMap('providerID', 'mapName', 'listName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

プロパティ・マップの名前を指定します。

listName

削除するプロパティ・リストの名前を指定します。

9.2.50.3 例

次のコマンドは、mymapAのmylistAを削除します。

wls:/mydomain/serverConfig> removeFederationListInMap('providerA','mymapA','mylistA')

9.2.51 removeFederationMapInMap

マップの中にネストされているマップを削除するオンライン・コマンドです。

9.2.51.1 説明

このコマンドは、cot.xml内のマップの中にネストされているプロパティ・マップを削除します。

9.2.51.2 構文

removeFederationMapInMap('providerID', 'mapname', 'nestedMapName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

ネストされたマップを含むプロパティ・マップの名前を指定します。

nestedmapName

削除するネストされたプロパティ・マップの名前を指定します。

9.2.51.3 例

次のコマンドは、mymapからnestedmapAを削除します。

wls:/mydomain/serverConfig> removeFederationMapInMap('providerA','mymap','nestedmapA')

9.2.52 removeFederationMapEntryInMap

マップの中にネストされているマップ・プロパティ・エントリをマップから削除するオンライン・コマンドです。

9.2.52.1 説明

このコマンドは、cot.xml内のマップの中にネストされているマップからプロパティ名/値ペアを削除します。

9.2.52.2 構文

removeFederationMapEntryInMap('providerID', 'mapname', 'nestedMapName', 'propName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

ネストされたマップを含むプロパティ・マップの名前を指定します。

nestedmapName

ネストされたプロパティ・マップの名前を指定します。

propName

ネストされたマップから削除するプロパティの名前を指定します。

9.2.52.3 例

次のコマンドは、マップ・プロパティ・エントリmyvarAを削除します。

wls:/mydomain/serverConfig> removeFederationMapEntryInMap('providerA','mymap','nestedmapA','myvarA')

9.2.53 removeFederationProperty

プロパティ値を削除するオンライン・コマンドです。

9.2.53.1 説明

このコマンドは、cot.xml内のプロパティ・エントリを削除します。

9.2.53.2 構文

removeFederationProperty('providerID', 'propName')

引数

定義

providerID

更新するピア・プロバイダの名前を指定します。

propName

削除するプロパティの名前を指定します。

9.2.53.3 例

次のコマンドは、プロバイダ・プロパティmyvarAを削除します。

wls:/mydomain/serverConfig> removeFederationProperty('providerA','myvarA')

9.2.54 removeFederationPropertyList

プロパティ・リスト・エントリを削除するオンライン・コマンドです。

9.2.54.1 説明

このコマンドは、cot.xml内のプロパティ・リスト・エントリを削除します。

9.2.54.2 構文

removeFederationPropertyList('providerID', 'listName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

listName

削除するプロパティ・リストの名前を指定します。

9.2.54.3 例

次のコマンドは、mylistAを削除します。

wls:/mydomain/serverConfig> removeFederationPropertyList('providerA','mylistA')

9.2.55 removeFederationPropertyMap

プロパティ・マップを削除するオンライン・コマンドです。

9.2.55.1 説明

このコマンドは、cot.xml内のプロパティ・マップを削除します。

9.2.55.2 構文

removeFederationPropertyMap('providerID', 'mapName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

削除するプロパティ・マップの名前を指定します。

9.2.55.3 例

次のコマンドは、マップを削除します。

wls:/mydomain/serverConfig> removeFederationPropertyMap('providerA','mapA')

9.2.56 removeFederationPropertyMapEntry

マップからプロパティ値を削除するオンライン・コマンドです。

9.2.56.1 説明

このコマンドは、cot.xmlのマップからプロパティ値を削除します。

9.2.56.2 構文

removeFederationPropertyMapEntry('providerID', 'mapName', 'propName')

引数

定義

providerID

アクセスするピア・プロバイダの名前を指定します。

mapName

更新するプロパティ・マップの名前を指定します。

propName

マップから削除するプロパティの名前を指定します。

9.2.56.3 例

次のコマンドは、マップからプロパティpropAを削除します。

wls:/mydomain/serverConfig> removeFederationPropertyMapEntry('providerA','mapA', 'propA')

9.2.57 removePeerProviderEntry

ピア・プロバイダ・エントリを削除するオンライン・コマンドです。

9.2.57.1 説明

このコマンドは、cot.xmlからピア・プロバイダ・エントリを削除します。

9.2.57.2 構文

removePeerProviderEntry('providerID')

引数

定義

providerID

削除するピア・プロバイダの名前を指定します。

9.2.57.3 例

次のコマンドは、providerAを削除します。

wls:/mydomain/serverConfig> removePeerProviderEntry('providerA')

9.2.58 setConfigProperty

config.xmlにプロパティ値を設定するオンライン・コマンドです。

9.2.58.1 説明

このコマンドは、config.xmlにプロパティ値を追加、またはconfig.xmlのプロパティ値を更新します。

9.2.58.2 構文

setConfigProperty('configname', 'propName', 'value', 'type')

引数

定義

configname

更新する構成の名前(idpsaml20、serverconfig、spsaml20など)を指定します。

propname

config.xmlに追加/更新するプロパティの名前を指定します。

value

プロパティ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.58.3 例

次のコマンドは、プロパティmyvarAとその値をサーバー構成に設定します。

wls:/mydomain/serverConfig> setConfigProperty('serverconfig','myvarA','myvalA','string')

9.2.59 setCustomAuthnEngine

カスタム認証統合エンジンを更新するオンライン・コマンドです。

9.2.59.1 説明

このコマンドは、config.xml内のカスタム認証統合エンジンを更新します。

9.2.59.2 構文

setCustomAuthnEngine('engineID', 'name', 'enabled', 'webContext', 'authnRelativePath', 'logoutRelativePath', 'logoutEnabled')

引数

定義

engineID

既存のエンジンのエンジンIDを指定します。

name

カスタム・エンジンの名前を指定します。

enabled

このフラグには、エンジンを有効にする(true)か、無効にする(false)かを指定します。

webContext

エンジンのWebコンテキストを指定します。

authnRelativePath

エンジンの認証相対パスURLを指定します。

logoutRelativePath

エンジンのログアウト相対パスURLを指定します。

logoutEnabled

このフラグは、エンジンのログアウトを有効にする場合はtrueに設定します。それ以外の場合はfalseに設定します。

9.2.59.3 例

次のコマンドは、カスタム認証エンジンabcdefの構成を更新します。

wls:/mydomain/serverConfig> setCustomAuthnEngine('abcdef',
'custom one','false','oracle:fed:authentication:unspecified','webcontext')

9.2.60 setCustomSPEngine

カスタムSP統合エンジンを更新するオンライン・コマンドです。

9.2.60.1 説明

このコマンドは、config.xml内の既存のカスタムSP統合エンジンを更新します。

9.2.60.2 構文

setCustomSPEngine('engineID' ,'name', 'enabled', 'authnMech', 'webContext', 'authnRelativePath', 'logoutRelativePath', 'logoutEnabled')

引数

定義

engineID

既存のカスタム・エンジンのエンジンIDを指定します。

name

カスタム・エンジンの名前を指定します。

enabled

このフラグには、エンジンを有効にする(true)か、無効にする(false)かを指定します。

authnMech

エンジンの認証メカニズムを指定します。

webContext

エンジンのWebコンテキストを指定します。

authnRelativePath

エンジンの認証相対パスURLを指定します。

logoutRelativePath

エンジンのログアウト相対パスURLを指定します。

logoutEnabled

このフラグは、エンジンのログアウトを有効にする場合はtrueに設定します。それ以外の場合はfalseに設定します。

9.2.60.3 例

次のコマンドは、engineID2というIDのエンジンに名前と有効フラグを設定します。

wls:/mydomain/serverConfig> setCustomSPEngine('engineid2','test','true')

9.2.61 setFederationProperty

プロパティ値を追加または更新するオンライン・コマンドです。

9.2.61.1 説明

このコマンドは、cot.xmlにプロパティ値を追加、またはcot.xml内の既存のエントリを更新します。

9.2.61.2 構文

setFederationProperty('providerID', 'propName', 'value', 'type')

引数

定義

providerID

更新するピア・プロバイダの名前を指定します。

propname

cot.xmlに追加/更新するプロパティの名前を指定します。

value

プロパティ値を指定します。

type

プロパティの型(BOOLEAN、STRINGまたはLONG)を指定します。

9.2.61.3 例

次のコマンドは、プロパティmyvarAを作成し、その値を設定します。

wls:/mydomain/serverConfig> setFederationProperty('providerA','myvarA','myvalA','string')

第III部

Oracle Universal Federation Framework

第III部では、Oracle Universal Federation Frameworkを使用してOracle Identity Federationをカスタマイズする方法について説明します。

第III部は、次の章で構成されています。

- 第10章「サード・パーティのIDおよびアクセス管理モジュールとの統合」

- 第11章「ビジネス処理プラグイン用のOracle Identity Federationの構成」

- 第12章「カスタム・アクションの実装」

10 サード・パーティのIDおよびアクセス管理モジュールとの統合

この項には、カスタム・エンジンの実装に関連する次の内容が含まれています。

- カスタム実装のためのバックグラウンド情報

- アーキテクチャおよびフロー

- カスタム認証エンジンの作成

- カスタムSP統合エンジンの作成

- ログアウト

10.1 カスタム実装のためのバックグラウンド情報

デフォルトでは、Oracle Identity Federationは、Oracle Access Manager、Oracle AS Single Sign-Onなどの複数のIDおよびアクセス管理(IAM)製品と統合されます。詳細は、第5.15項「認証エンジンの構成」および第5.16項「SP統合モジュールの構成」を参照してください。

関連項目:
Oracle Identity Federationの解説と、他のフェデレーション・コンポーネントとの関係の詳細は、第1.2.2項「アーキテクチャ」を参照してください。

この項では、カスタムIAM製品に対するフレームワークのコンポーネントについて説明し、カスタムIAMソリューションを構成してこのフレームワークに統合する方法を示します。

注意:
この項で説明されているカスタム統合および認証用以外のアプリケーションをOracle WebLogic管理対象サーバーにデプロイすると、セキュリティ上のリスクが発生する可能性があるため、そのようなデプロイは行わないことをお薦めします。無関係なアプリケーションをOracle WebLogic管理対象サーバーにデプロイしたすると、悪意のあるソフトウェアによってサーバー・フローの動作が変更される可能性があるため、フェデレーション・サーバーのセキュリティに悪影響を及ぼすことがあります。

10.2 アーキテクチャおよびフロー

実行時に、Oracle Identity Federationは2種類の外部モジュール(ユーザー・データ・ストアと、IDおよびアクセス管理(IAM)システム)と相互作用します。

Oracle Identity Federationがユーザー・データ・ストアと連携する目的は次のとおりです。

- ローカル認証後のユーザーの検索

- 着信SAMLアサーションの処理後のユーザーの検索

- 特定のユーザーの属性の取得

IDおよびアクセス管理(IAM)システムは、保護されたリソースに対するアクセスを制御します。Oracle Identity Federationがフェデレーション・サーバーとしてIAMと相互作用する目的は次のとおりです。

- サーバーがユーザーのローカルIDを取得する必要がある場合にユーザーを認証します。この操作は、サーバーがIdPとして機能する場合、またはSPとして機能するサーバーが初期アカウント・リンク/フェデレーション作成中にユーザーを認証する必要がある場合に行われることがあります。

- サーバーが着信SAMLアサーションを処理し、特定のユーザーのIDをIAMシステムに対して宣言する場合に、そのユーザー用の認証済セッションを作成します。

- ログアウト・フローを処理します。この場合、フェデレーション・サーバーは、ユーザーをシステムからログアウトさせるIAM機能を起動します。

10.2.1 アーキテクチャ

図3-1に、Oracle Identity Federationデプロイメントの複数の外部および内部モジュールと、各モジュールが実行時に相互作用する方法を示します。

図10-1 Oracle Identity Federationモジュールの相互作用

ここでは、わかりやすいように、Oracle Identity Federationを次の3つの内部モジュールとして示します。

- アイデンティティ・フェデレーション・エンジン。AuthnRequest、アサーションおよびログアウトなどのSAMLメッセージの作成および処理を行います。
このモジュールの機能は次のとおりです。

- SAMLメッセージの処理時に、ユーザー・データ・ストアと連携します。

- ユーザーをローカルに識別する必要がある場合に、認証エンジンと相互作用します。

- アサーションの処理後にユーザーがIAMコンポーネントにリダイレクトされる際に、SP統合エンジンと相互作用します。

- 認証エンジン。フェデレーション・エンジンからのリクエストを処理してユーザーを認証します。このモジュールはIAMコンポーネントおよびユーザー・データ・ストアと相互作用して、ユーザーの認証と、Oracle Identity Federationでユーザーの参照に使用される一意の識別子の取得を実行します。
このモジュールは、ローカル認証が必要な場合に、IdPまたはSPモードで起動できます。

ユーザーの認証後、認証エンジンは、ユーザー識別子や認証時刻およびその他のデータなどの認証情報をフェデレーション・エンジンに送信します。

- フェデレーション・エンジンは、着信SAMLアサーションを正常に処理し、アサーションで参照されるユーザーを検索した後、そのユーザー用の認証済セッションをIAMドメインで作成するようにSP統合エンジンに指示します。必要な情報(ユーザー識別子、認証時刻など)をSP統合エンジンに渡します。SP統合エンジンは、IAMサーバーと相互作用してこのセッションを作成します。

10.2.2 認証エンジン・フレームワーク

Oracle Identity Federationの認証エンジン・フレームワークはユーザーを認証するように設計されており、デフォルトでサポートされている各種のIAMサーバーとの相互作用を可能にする複数の内部プラグインが含まれています。

- Oracle Single Sign-On

- Oracle Access Manager

- LDAPサーバーを使用したユーザー名/パスワード

- RDBMSサーバーを使用したユーザー名/パスワード

- RDBMS表を使用したユーザー名/パスワード

- 情報カード

- フェデレーションSSOプロキシ

- JAAS

また、Oracle Identity Federationはサード・パーティ認証モジュールとのサーバーの統合を可能にするフレームワークも提供します。インテグレータは、次の2つの方法を使用して、他の認証プラットフォームと相互作用するようにOracle Identity Federationをカスタマイズできます。

- JavaEEサーブレット転送を使用してOracle Identity Federationと相互作用する認証モジュールを設計し、実装する。新しいモジュールは、ユーザーを認証する役割を果たすサード・パーティ認証ソリューションにもリンクされます。

- 特定のログイン・モジュールを使用するようにJAASを利用する。Oracle Identity Federationには内部転送に基づく認証エンジンが含まれており、これはJAASライブラリを使用してユーザーを認証します。これにより、インテグレータはOracle Identity Federationを構成することによって、既存のJAAS準拠のログイン・モジュールをOracle Identity Federationサーバー・モジュールで再利用することが可能になります。

ここでは、認証エンジンが一般的なユーザー・フローで他のコンポーネントと相互作用する方法を段階的に説明します(Oracle Identity Federationはフェデレーション・サーバーとも呼ばれます)。

1. ユーザーがOracle Identity FederationにアクセスしてSSO処理を行います(SPまたはIdPモード)。

2. サーバー内の内部プロセスが、特定の認証メカニズム(構成で指定されたデフォルトのメカニズムまたはリモート・サービス・プロバイダによってリクエストされたメカニズム)を使用してユーザーを識別する必要があることを判断します。

3. フェデレーション・サーバーが、指定された認証メカニズムに対して、ユーザーをチャレンジ/識別するために使用する認証エンジンを決定します。

4. 次に、フェデレーション・サーバーはユーザーをチャレンジ/識別する認証エンジンのWebコンテキストおよびログイン相対パスにユーザーのリクエストを内部的に転送し、HttpServletRequestインスタンスの属性として格納されているJavaオブジェクトで指定された次のような情報を渡します。

- ユーザーのIDのチャレンジ時に使用する認証メカニズム。

- 実行されている現在のアクションを参照する識別子。

- フェデレーションSSO処理が行われている場合は、このローカル認証をリクエストしているリモート・サービス・プロバイダのProviderIDと説明。

- ユーザーの認証に使用するエンジンを参照する識別子。

- ユーザーの識別子。

- ユーザーがすでに認証済でもエンジンがユーザーをチャレンジすべきかどうかを示すForce Authenticationフラグ。

- エンジンがユーザーと視覚的に対話可能かどうかを示すIs Passiveフラグ。

- オプションで、エンジンが設定する必要がある属性のマップ。これらの属性は、特定のリモート・プロバイダの構成で指定されたとおりに、Oracle Identity Federation/IdPがAttributeStatementを使用してアサーションを正しく作成するために必要です。

- ユーザーがすでにアクティブなセッションを開始している場合は、オプションで、Oracle Identity Federationのセッション識別子を含むString。Oracle Identity Federationは、認証エンジンがユーザーにリンクされた状態を維持できるように、すでに存在するユーザー・セッション(存在する場合)のセッションIDをエンジンに渡します。またOracle Identity Federationは、sessionID値を使用してそのデータを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションに使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするsessionIDをエンジンに渡します。

5. 認証エンジンが受信リクエストを処理します。認証エンジンは、HttpServletRequest属性として格納されている情報にアクセスできます。

6. 認証エンジンは、IAMコンポーネントと相互作用し、ユーザーの資格証明を要求する場合があります。認証に成功すると、Cookieを設定する場合があります(IAMサーバーまたはターゲット・アプリケーション、あるいはその両方との認証済セッションを維持するためなど)。

7. 認証モジュールは内部転送(Webコンテキスト/fedおよびログイン相対パス/user/loginsso)を使用してユーザーをOracle Identity Federationに戻し、次の情報をHttpServletRequest属性として渡します。

- ユーザーの識別子。

- 認証時刻

- 認証済セッションの有効期限

- ユーザーの識別に使用した認証メカニズム

- リクエストからの、実行されたアクションを参照する識別子

- ユーザーの認証に使用するエンジンを参照する識別子。

- オプションで、ユーザー・セッションに格納されている属性のマップ。

- オプションで、Oracle Identity FederationがOracle Identity Federationユーザー・セッションの参照に使用する必要があるOracle Identity Federationのセッション識別子を含む文字列。これにより、エンジンとOracle Identity Federationは、同じ識別子を共有してユーザー・セッションを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションに使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするsessionIDをエンジンに渡します。

注意:

- ユーザーID属性が空だが、認証時刻と認証メカニズム属性が空ではない場合、認証は成功したがサーバー上でユーザーが不明であることがOracle Identity Federationに通知されます。これはIdPの役割を果たすOracle Identity Federationが、エンジンによって渡された属性を使用してアサーションを作成するように構成されている場合に有用です。

- 認証時刻または認証メカニズム属性が空の場合は、認証に失敗したことがOracle Identity Federationに通知されます。

8. Oracle Identity Federationが次のアクションを実行します。

- 受信リクエストの処理

- 属性としてHttpServletRequestに埋め込まれたデータの取得

- ユーザー・データ・ストアでのユーザーの検索

- ユーザー用のセッションの作成

- Cookieの設定

- SSO処理の再開

10.2.3 SP統合エンジン・フレームワーク

Oracle Identity Federationに付属のSP統合エンジンは、サーバーからのリクエストを処理してIAMサーバーでユーザー用の認証済セッションを作成するサーブレットで構成されています。このエンジンには、次のような複数のIAMサーバーとの相互作用を可能にする複数の内部プラグインが含まれています。

- Oracle Single Sign-On

- Oracle Access Manager

- Oracle Identity Federationテスト・アプリケーション

また、Oracle Identity Federationでは、サーバーとサード・パーティのIAMフレームワークとの統合を可能にするフレームワークが提供されています。カスタマイズされたSP統合モジュールが内部のJ2EEサーブレット転送を使用してOracle Identity Federationと対話し、サード・パーティのIAMシステムと通信して認証済ユーザー・セッションを作成します。

ここでは、SP統合エンジンが一般的なユーザー・フローでOracle Identity Federationフレームワークと相互作用する方法を段階的に説明します。

1. ユーザーが、IAMソリューションにより保護され、ユーザーの認証にフェデレーションSSOを使用するように構成されているリソースへのアクセスを試みます。

2. IAMデプロイメントが、Oracle Identity Federation上の対応するSP統合モジュールにユーザーをリダイレクトします。

3. SP統合モジュールがIAMデプロイメントによって送信された情報をデコードし、次の情報をHttpServletRequest属性として設定して、ユーザーをOracle Identity Federationサーバーに内部転送します。

- 認証時に使用するようにIdPにリクエストする認証メカニズムをSPに対して指定する、オプションの認証メカニズム。

注意:
設定した場合、このパラメータは使用すべきIdPを決定するために使用されます。この場合、次に説明するデフォルト・パラメータは無視されます。

- フェデレーションSSOで使用するIdPを参照する、オプションのプロバイダID。指定されていない場合、Oracle Identity Federationは指定された認証メカニズムにマップされたIdPを使用します。IdPが見つからなかった場合は、Oracle Identity FederationはデフォルトSSO IdPとして構成されているIdPを使用します。

- フェデレーションSSOのトリガーに使用するアフィリエーションを参照する、オプションのフェデレーションID。

- リレー状態。リポジトリに保存されたデータへの参照などの短い文字列、またはSSO処理の完了後にユーザーをリダイレクトする保護リソースを指す短いURLを含めることができます。

- SSOフローを開始したSPエンジンの識別子。

- Oracle Identity Federationサーバーが認証エンジンを使用してユーザーをローカルに認証すべきか、またはユーザーを認証用にIdPにリダイレクトすることによりフェデレーションSSOを開始すべきかを示す、オプションのブール値。

- Oracle Identity Federationに格納されている構成を使用するか、またはSPエンジンによって渡された、IdP以外の情報に基づいてSSO処理のみを開始するかを示す、Booleanオブジェクト。

- ユーザーが認証済の場合でもユーザーをチャレンジするようにSPからIdPに指示するかどうかを示す、Booleanオブジェクト。

- SSO処理中に、フェデレーション・レコードがまだ存在しない場合はレコードを作成するようにSPがIdPに対して許可するかどうかを示す、Booleanオブジェクト。

- SSO処理中にIdPとユーザーとの間で対話が行われないようにSPが指示するかどうかを示す、Booleanオブジェクト。

- AuthnRequestの送信時に使用するバインディングを表すString。

- アサーションを含むレスポンスの送信時に使用するバインディングを表すString。

- IdPでの認証時に使用する認証コンテキスト比較をリクエストする場合にSPに対して指定する、オプションの認証メカニズム比較。

- SSO処理に関してSPがIdPに問い合せるために使用する名前IDフォーマットを表すString。

4. Oracle Identity Federationが、リモートIdPとの間でフェデレーションSSO処理を開始します。

5. IdPがユーザーを認証し、必要に応じてユーザーをアサーションとともに、SPとして機能するフェデレーション・サーバーにリダイレクトします。

6. サーバーがアサーションを処理し、ユーザーをユーザー・データ・ストアで検索します。これで、ユーザーがフェデレーション・サーバーで認証されます。

7. Oracle Identity Federationが、Oracle Identity Federation内で構成されているSP統合モジュールのWebコンテキストとログイン相対パスを使用して、ユーザーをSP統合モジュールに内部的に転送して戻します。サーバーは次のデータをHttpServletRequest属性として渡します。

- SSO処理が成功したかどうかを示すBooleanオブジェクト

- ユーザーの識別子。

- 認証時刻

- 認証済セッションの有効期限

- ユーザーの識別に使用した認証メカニズム

- リレー状態

- アサーションの内容(NameID、アサーションのIssuerおよびオプションの属性)。注意: アサーションの内容はXMLデータとしては渡されません。つまり、元のアサーションはモジュールには戻されません。追加のデータは次のように参照されます。

- 名前ID値を含むorafed-nameid-value

- 名前ID修飾子を含むorafed-nameid-qualifier

- 名前IDフォーマットを含むorafed-nameid-format

- ピア・プロバイダIDを含むorafed-providerid

- SAMLレスポンスの最高ステータス

- SAMLレスポンスの低ステータス(存在する場合)

- ステータス・メッセージ(存在する場合)

- SSOアサーションを作成したProviderID

- 前述の情報を処理するSPエンジンの識別子

- ユーザー・セッションのOracle Identity Federation識別子を含むString。Oracle Identity Federationは、SPエンジンがユーザーにリンクされた状態を維持できるように、ユーザー・セッションのセッションIDを渡します。またOracle Identity Federationは、sessionID値を使用してそのデータを参照できます。後でログアウト・フローの実行時に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするセッションIDをエンジンに渡します。

8. SP統合エンジンが、IAMサーバーと相互作用して、ユーザー用の認証済セッションを作成します。このセッションは、Oracle Identity Federationから受信されたデータに基づきます。

9. SP統合エンジンが、ユーザーを最終のターゲットURLにリダイレクトします。

10.2.4 ログアウト

ログアウト時には、Oracle Identity Federationおよび認証またはSPエンジンからログアウトする必要があります。これには、次の操作が含まれます。

1. 認証エンジンからユーザーをログアウトさせます。

2. SPエンジンからユーザーをログアウトさせます。

3. SAML/WS-Fedグローバル・ログアウト・プロファイルを実行します。

4. Oracle Identity Federationからユーザーをログアウトさせます。

図10-2 Oracle Identity Federationモジュールの相互作用

ログアウトを呼び出すにはいくつかの方法があります。

- ユーザーがオプションの戻りURLを指定することにより、/fed/user/logoutにあるOracle Identity Federationログアウト・サーバーを呼び出します。この場合、Oracle Identity Federationはユーザーを認証エンジンまたはSPエンジン、リモートSAMLプロバイダおよびOracle Identity Federation自体からログアウトさせ、ユーザーを戻りURLにリダイレクトするか、ログアウト結果ページを表示します。

- グローバル・ログアウト・プロトコルを使用して、ユーザーをリモートSAML/WS-FedプロバイダからOracle Identity Federationにリダイレクトします。この場合、Oracle Identity Federationはユーザーを認証エンジンまたはSPエンジン、リモートSAML/WS-Fedプロバイダ(ログアウト・メッセージを送信したプロバイダ以外の)およびOracle Identity Federation自体からログアウトさせ、ユーザーを元のメッセージを送信したリモートSAMLプロバイダにリダイレクトして戻します。

- ユーザーが、認証エンジンまたはSPエンジンに統合された環境からログアウトを開始します。この場合、この環境によりログアウト用の認証エンジンまたはSPエンジンが呼び出され、そのエンジンがユーザーをログアウト用にOracle Identity Federationに送信します。その後、Oracle Identity Federationがユーザーを認証エンジンまたはSPエンジン(ユーザーをOracle Identity Federationにリダイレクトしたエンジン以外の)およびOracle Identity Federation自体からログアウトさせ、フローを開始した認証エンジンまたはSPエンジンにユーザーをリダイレクトして戻します。

注意:
Oracle Identity Federationから認証エンジンまたはSPエンジンへの、また認証エンジンまたはSPエンジンからOracle Identity Federationへのユーザーの送信には、内部転送が使用されます。

Oracle Identity Federationによる認証エンジンまたはSPエンジンの呼出し

Oracle Identity Federationは、ユーザーを認証エンジンまたはSPエンジンに送信する際に、次の処理を実行します。

1. エンジンのWebコンテキストおよび相対ログアウト・パスへの内部転送を実行します。

2. ログアウト時に呼び出すエンジンのエンジンIDを指定します。

3. オプションで、ログアウトされるユーザー・セッションの識別子を指定します。

認証エンジンまたはSPエンジンによるユーザーのログアウト時に、エンジンはユーザーをOracle Identity Federationに内部的に転送して戻し、次の処理を実行します。

1. /fed Webコンテキストおよび/user/logoutretssoへの内部転送を実行します。

2. 呼び出すエンジンのエンジンIDを指定します。

認証エンジンまたはSPエンジンによるOracle Identity Federationの呼出し

認証エンジンまたはSPエンジンは、ログアウト時にOracle Identity Federationを呼び出す場合、次の処理を実行します。

1. /fed Webコンテキストおよび/user/logoutssoへの内部転送を実行します。

2. ログアウト時に呼び出すエンジンのエンジンIDを指定します。

3. Oracle Identity Federationがログアウト後にユーザーをリダイレクトする戻りURLを指定します。

ログアウト・フローの最後に、ユーザーはOracle Identity Federationからログアウトされ、戻りURLにリダイレクトされます。

10.2.5 要件

Oracle Identity Federationは、認証操作およびSP統合に関する特定の要件を満たすよう設計されています(ユーザー・セッションがIAMサーバーで作成される場合)。したがって、カスタム認証エンジンまたはSP統合エンジンの実装時は次の要件を満たす必要があります。

- 認証エンジン、SP統合エンジン、Oracle Identity FederationエンジンおよびIAMサーバーは、同じユーザー・データ・ストアをユーザー・リポジトリとして使用する必要があります。このストアには、ユーザーの検索および認証に使用されるユーザー・データが含まれています。

- 認証エンジンおよびSP統合エンジンには、Javaサーブレット/JSPが含まれている必要があります。

- Oracle Identity Federationと認証/SP統合エンジンの間のデータ交換は、内部HTTPリクエスト転送を介して行われる必要があります。これは実際には、J2EEサーブレット・フレームワークに依存したモジュール間の内部APIコールであり、HTTPプロトコルを介して行われます。

- ログアウト・サービスを実装し、認証エンジンまたはSP統合エンジン(あるいはその両方)がこのサービスを使用できるようにする必要があります。このログアウト・サービスは、サーブレット/JSPとして公開される必要があります。

10.3 カスタム認証エンジンの作成

この項では、カスタム認証エンジンを計画、開発および実装する方法を説明します。

10.3.1 カスタム認証エンジンの計画

カスタマイズされた認証エンジンの作成には、次の手順が含まれます。

- Oracle Identity Federationからの受信リクエストを処理するサービスの作成。

- ユーザーを認証するモジュールの実装。

- ユーザーを必須情報とともにフェデレーション・サーバーに転送するサービスの作成。

- 認証エンジンがユーザーの認証後にCookieを設定するかどうかの判断。設定する場合、認証モジュールをログアウト処理と統合する必要があります(第10.5項「ログアウト」を参照)。

- サービスおよびモジュールのWebアプリケーションへのパッケージ化と、Oracle Identity Federationが実行されているOracle WebLogic管理対象サーバーへのアプリケーションのデプロイ。

- Oracle Identity Federationが新しい認証エンジンを参照するようにするための構成。

- 認証エンジンによって返されるユーザー識別子が、Oracle Identity Federationユーザー・データ・ストア内の同じユーザーを参照することの確認。

10.3.2 認証モジュールの開発および実装

ここでは、モジュール開発のいくつかの側面について説明します。

URL

フェデレーション・エンジンと認証エンジンの間の通信は、APIコールに相当する内部サーブレット転送を介して行われます。これらの転送では、次のJavaEE APIを使用します。

ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)

ここで、

- contextPathは、Webアプリケーションのルート・コンテキスト・パスです。たとえば、Oracle Identity FederationのcontextPathは/fedです。

- relativePathは、ユーザーの転送先となるサービスURLであり、contextPathに相対的です。たとえば、ユーザーの認証後、認証エンジンではユーザーの転送時に/user/loginssoをrelativePathとして使用します。

Oracle Identity Federationは、新しい認証エンジンのID、contextPathおよびrelativePathを把握している必要があります。これは、フェデレーション・サーバーが発行した認証リクエストを処理するURLです。

認証エンジンの追加または変更

認証エンジンを追加または変更するには、次の手順を実行します。

- Fusion Middleware Controlに移動し、Oracle Identity Federationインスタンスを選択します。

- 「管理」→「認証エンジン」に移動します。

- 認証エンジンを追加するには、「追加」をクリックして、認証エンジンの名前を入力します。Oracle Identity Federationにより、新しいエンジンに対するIDが生成されます。

注意:
Fusion Middleware Controlでは、名前は表示目的でのみ使用し、Oracle Identity Federationと認証エンジン間の通信ではIDを使用します。

- 認証エンジンを変更するには、認証エンジンを選択して、次の操作を実行します。

- エンジンを有効または無効にします。

- 「Webコンテキスト」フィールドで、認証エンジンのcontextPathを指定します。

- 「ログイン相対パス」フィールドに、認証エンジンのログイン・サービスの相対パスを指定します。

- ログアウトを有効または無効にします。

- 「ログアウト相対パス」フィールドに、認証エンジンのログアウト・サービスの相対パスを指定します。

- 「適用」をクリックします。

関連項目:
第5.15項「認証エンジンの構成」

サービスの実装

この項では、認証エンジンが実行する役割と、実装を成功させるためにサービスで実行できる必要がある処理タスクについて説明します。

認証エンジンは次を実行する必要があります。

- フェデレーション・エンジンからのリクエストの処理

- 認証成功後のフェデレーション・サーバーへのユーザーの転送

サーバーからの認証リクエストの処理時に、エンジンは次の着信データを処理する必要があります。

- ユーザーのIDのチャレンジ時に使用する認証メカニズム(String、oracle.security.fed.authn.authnmechで識別)。

- 実行中の現在のアクションを参照する識別子(String、oracle.security.fed.authn.refidで識別)。

- フェデレーションSSO処理が行われている場合は、このローカル認証をリクエストしているリモート・サービス・プロバイダのProviderIDと説明(String、oracle.security.fed.authn.provideridおよびoracle.security.fed.authn.providerdescriptionで識別)。

- ユーザーの認証に使用するエンジンを参照する識別子(oracle.security.fed.authn.engineidで識別)。

- 設定されている場合は、ユーザーの識別子(String、oracle.security.fed.authn.useridで識別)。

- ユーザーがすでに認証済でもエンジンがユーザーをチャレンジすべきかどうかを示す、強制認証フラグ(Booleanオブジェクト)。指定されていない場合、Falseとみなされます。(oracle.security.fed.authn.forceauthnで識別)

- エンジンがユーザーと視覚的に対話可能かどうかを示す、Is Passiveフラグ(Booleanオブジェクト)。指定されていない場合、Falseとみなされます。(oracle.security.fed.authn.passiveで識別)

- オプションで、エンジンが設定する必要がある属性のマップ。これらの属性は、特定のリモート・プロバイダの構成で指定されたとおりに、Oracle Identity Federation/IdPが属性文を使用してアサーションを正しく作成するために必要です。(oracle.security.fed.authn.attributesで識別)
Oracle Identity FederationがSSOアサーションを受け取り、処理し、サーバーがアサーションをローカル・ユーザーにマップできなかったためユーザーをローカルに認証することをリクエストすると、マップにはアサーションからの次のデータが含まれます。

- orafed-nameid-value - ユーザーの名前ID値

- orafed-nameid-qualifier - ユーザーの名前ID修飾子

- orafed-nameid-format - ユーザーの名前IDフォーマット

- orafed-providerid - IdPのプロバイダID

- orafed-assertionid - アサーションのID

- orafed-xmlmessage - アサーションを含むオプションのXMLメッセージ

詳細は、第6.13.2項「SSO完了後のSPエンジンへのXMLメッセージの送信」を参照してください。

- ユーザーがすでにアクティブなセッションを開始している場合は、オプションで、Oracle Identity Federationのセッション識別子を含むString。Oracle Identity Federationは、認証エンジンがユーザーにリンクされた状態を維持できるように、すでに存在するユーザー・セッション(存在する場合)のセッションIDをエンジンに渡します。またOracle Identity Federationは、セッションID値を使用してそのデータを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするセッションIDをエンジンに渡します。(oracle.security.fed.sessionidで識別)。

関連項目:
第5.9.2.1項「属性名マッピングの構成」

認証が成功したら、エンジンは、フェデレーション・エンジンのrootContextである/fedおよび相対パス/user/loginssoを使用して、ユーザーをフェデレーション・サーバーに転送する必要があります。

Oracle Identity Federationでは、内部転送の処理時に次のデータが必要です。

- ユーザーの識別子(String、oracle.security.fed.authn.useridで識別)

- 認証時刻(Dateオブジェクト、oracle.security.fed.authn.authntimeで識別)

- 認証済セッションの有効期限(Dateオブジェクト、oracle.security.fed.authn.expirationtimeで識別)

- ユーザーを識別するために使用する認証メカニズム(String、oracle.security.fed.authn.authnmechで識別)。

- リクエストからの、実行されたアクションを参照する識別子(oracle.security.fed.authn.refidで識別)。

- ユーザーの認証に使用するエンジンを参照する識別子(oracle.security.fed.authn.engineidで識別)。

- オプションで、ユーザー・セッションに格納されている属性のマップ。このマップは、キーとしてStringオブジェクトを、値としてオブジェクトのセットを持ちます(oracle.security.fed.authn.attributesで識別)。

- オプションで、Oracle Identity FederationがOracle Identity Federationユーザー・セッションの参照に使用する必要があるOracle Identity Federationのセッション識別子を含むString。これにより、エンジンとOracle Identity Federationは、同じ識別子を共有してユーザー・セッションを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするセッションIDをエンジンに渡します。(oracle.security.fed.sessionidで識別)。

注意:

- oracle.security.fed.authn.userid属性が空だが、oracle.security.fed.authn.authntimeとoracle.security.fed.authn.authnmech属性が空ではない場合、認証は成功したがサーバー上でユーザーが不明であることをOracle Identity Federationに対して示します。これはIdPの役割を果たすOracle Identity Federationが、エンジンによって渡された属性を使用してアサーションを作成するように構成されている場合に有用です。
oracle.security.fed.authn.userid属性がnullである場合、アサーション・データはカスタム認証エンジンから渡された情報のみに基づくため、IdPはフェデレーション・データ・ストアは使用しないように構成する必要があります。

- XMLベースのフェデレーション・ストアはテストにのみ使用し、本番環境では使用しないでください。

- oracle.security.fed.authn.authntimeまたはoracle.security.fed.authn.authnmech属性が空の場合は、認証が失敗したことをOracle Identity Federationに対して示します。

さらに、次の追加の実装要件があります。

- サービスでCookieを設定する必要がある場合、ユーザーをフェデレーション・サーバーに転送する前にその操作を実行してください。

- Cookieのパス値を/に設定します。これは、Oracle Identity FederationのWebアプリケーションと認証エンジンのWebアプリケーション間の内部転送のために必要です。ユーザーのブラウザは、フェデレーション・サーバーにのみアクセスする場合にも、認証エンジンに関連するCookieを送信する必要があります。これにより、フェデレーション・サーバーから認証エンジンへの内部転送時に、エンジンによって設定されたCookieがHTTPリクエストで使用可能になります。

10.3.3 Oracle Single Sign-On統合用のサンプルの認証モジュール

この項では、カスタム認証エンジンをOracle Single Sign-Onと統合する方法を説明します。

設定

この例では、Oracle Identity Federationが実行されているアプリケーション・サーバーはOracle Single Sign-Onサーバーと統合されており、SSOモジュールは/engine/forward.jsp URLを静的に保護しています。

また、Oracle Identity Federationに対して構成されているユーザー・データ・ストアは、Oracle Single Sign-Onで使用されるOracle Internet Directoryサーバーを参照します。

関連項目:
SSO統合の詳細は、第3.2.2項「Oracle Single Sign-OnとのOracle Identity Federationのデプロイ」を参照してください。

パッケージ化

認証エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。

- authentication.jsp: Oracle Identity Federationサーバーからの受信リクエストを処理します。

- forward.jsp: Oracle Single Sign-Onで保護され、ユーザーを必須データとともにフェデレーション・サーバーに転送して戻します。

エンジンの追加

エンジンを追加するには、次の手順を実行します。

- Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

- 「管理」→「認証エンジン」の順に移動します。「認証エンジン」→「カスタム」タブを選択します。

- 認証エンジンを追加するには、「追加」をクリックして、認証エンジンの名前を入力します。Oracle Identity Federationにより、その新しいエンジンに対するIDが生成されます。このテストでは、このIDはTEST_ENGINE_IDとして参照します。

- 認証エンジンを選択して、次のように変更します。

- エンジンを有効にします。

- 認証エンジンの「Webコンテキスト」を/engineに設定します。

- 認証エンジンの「ログイン相対パス」を/authentication.jspに設定します。

- 「適用」をクリックします。

関連項目:
第5.15項「認証エンジンの構成」

authentication.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String authnMech = (String)request.getAttribute("oracle.security.fed.authn.authnmech");
String refid = (String)request.getAttribute("oracle.security.fed.authn.refid");

String redirectURL = "/engine/forward.jsp?refid=" +
(refid != null ? URLEncoder.encode(refid) : "");

response.sendRedirect(redirectURL);
%>

forward.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String refid = request.getParameter("refid");
String userID = request.getRemoteUser();
String authnMethod = "oracle:fed:authentication:password-protected";
Date now = new Date();

request.setAttribute("oracle.security.fed.authn.engineid", TEST_ENGINE_ID);
request.setAttribute("oracle.security.fed.authn.userid", userID);
request.setAttribute("oracle.security.fed.authn.refid", refid);
request.setAttribute("oracle.security.fed.authn.authnmech", authnMethod);
request.setAttribute("oracle.security.fed.authn.authntime", now);

request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/loginsso").forward(request, response);
%>

Oracle Single Sign-OnフレームワークではユーザーのブラウザでCookieを設定するため、認証エンジンをログアウト・フローと統合する必要があります(第10.5項「ログアウト」を参照)。

10.3.4 LDAP統合用のサンプルの認証モジュール

この項では、カスタマイズされた認証エンジンをスタンドアロンLDAPサーバーと統合する方法を示します。

設定

Fusion Middleware ControlでOracle Identity Federationに対して構成されているユーザー・データ・ストアは、認証エンジンで使用されるLDAPサーバーを参照します。

パッケージ化

認証エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。

- loginpage.jsp: フェデレーション・サーバーからの受信リクエストを処理し、ログイン・ページを表示します。

- ldapforward.jsp: ユーザーの資格証明をLDAPサーバーに対して認証し、認証成功時にユーザーをフェデレーション・サーバーに転送します。

エンジンの追加

エンジンを追加するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「認証エンジン」の順に移動します。「認証エンジン」→「カスタム」タブを選択します。

3. 認証エンジンを追加するには、「追加」をクリックして、認証エンジンの名前を入力します。Oracle Identity Federationにより、その新しいエンジンに対するIDが生成されます。このテストでは、このIDはTEST_ENGINE_IDとして参照します。

4. 認証エンジンを選択して、次のように変更します。

- エンジンを有効にします。

- 認証エンジンの「Webコンテキスト」を/engineに設定します。

- 認証エンジンの「ログイン相対パス」を/loginpage.jspに設定します。

5. 変更を保存します。

関連項目:
第5.15項「認証エンジンの構成」

loginpage.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String refid = request. getAttribute("oracle.security.fed.authn.refid");

String postURL = "/engine/ldapforward.jsp?refid=" +
(refid != null ? URLEncoder.encode(refid) : "");

String msg = request.getParameter("message");
%>
<HTML>
<BODY>
<FORM action="<%=postURL%>" method="POST">
<% if(msg != null && msg.length() > 0) { %> <%=msg%><BR/> <%}%>
Username: <INPUT type="text" name="username"/><BR/>
Password: <INPUT type="password" name="password"/><BR/>
<INPUT type="submit" value="Submit"/>
</FORM>
</BODY>
</HTML>

forward.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String refid = request.getParameter("refid");
String authnMethod = "oracle:fed:authentication:password-protected";

String userID = request.getParameter("username");
String password = request.getParameter("password");
Date now = new Date();

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://mynode.us.mycorp.com:389");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=" + userID + ",cn=users,dc=us,dc=oracle,dc=com");
env.put(Context.SECURITY_CREDENTIALS, password);

try {
DirContext ctx = new InitialDirContext(env);
} catch (NamingException ex) {
String redirectURL = "/engine/loginpage.jsp?refid=" +
(refid != null ? URLEncoder.encode(refid) : "") + "&message=" + URLEncoder.encode(ex.toString() + " for " + userID);
response.sendRedirect(redirectURL);
return;
}

request.setAttribute("oracle.security.fed.authn.engineid", TEST_ENGINE_ID);
request.setAttribute("oracle.security.fed.authn.userid", userID);
request.setAttribute("oracle.security.fed.authn.refid", refid);
request.setAttribute("oracle.security.fed.authn.authnmech", authnMethod);
request.setAttribute("oracle.security.fed.authn.authntime", now);

request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/loginsso").forward(request, response);
%>

Logout

このフローではCookieは設定されないため、認証エンジンをログアウト・フローと統合する必要はありません(第10.5項「ログアウト」を参照)。

10.4 カスタムSP統合エンジンの作成

この項では、カスタムSP統合エンジンを計画、開発および実装する方法を説明します。

関連項目:

- SP統合エンジンの説明と、このエンジンがOracle Identity Federationアーキテクチャに組み込まれる方法は、第10.2.1項「アーキテクチャ」を参照してください。

10.4.1 カスタムSP統合エンジンの計画

カスタムSP統合エンジンの開発には、次の手順が含まれます。

- Oracle Identity FederationからのリクエストをSPモードで処理するサービスの作成。

- ユーザー用の認証済セッションをIAMサーバーで作成するモジュールの実装。

- 最終のターゲットURLへのユーザーのリダイレクト。

- SP統合エンジンがIAMサーバーでの認証済セッションの作成後にCookieを設定するかどうかの判断。設定する場合、エンジンをログアウト処理と統合する必要があります(第10.5項「ログアウト」を参照)。

- 前述のサービスおよびモジュールのWebアプリケーションへのパッケージ化と、フェデレーション・サーバーが実行されているOracle WebLogic管理対象サーバーへのこのアプリケーションのデプロイ。

- Oracle Identity Federationが新しいSP統合モジュールを参照するようにするための構成。

- SP統合エンジンがユーザー・リポジトリにアクセスする場合、それが、Oracle Identity Federationで使用されるようにFusion Middleware Controlで構成されているユーザー・データ・ストアと同じであることの確認。

10.4.2 統合モジュールの開発および実装

この項では、統合モジュールを開発する方法と、フェデレーション環境に実装する方法を説明します。

- パスURL

- SP統合エンジンの追加または変更

- サービスの実装

10.4.2.1 パスURL

Oracle Identity FederationエンジンとSP統合エンジンの間の通信では、APIコールに相当する内部サーブレット転送が必要です。これらの転送は、次のJavaEE APIを使用して実現されます。

ServletContext.getContext(String contextPath)
.getRequestDispatcher(String relativePath)
.forward(HttpServletRequest request,
HttpServletResponse response)

ここで

- contextPathは、Webアプリケーションのルート・コンテキスト・パスです。たとえば、Oracle Identity FederationのcontextPathは/fedです。

- relativePathは、ユーザーの転送先となるサービスURLであり、contextPathに相対的です。たとえば、フェデレーションSSOフローを開始する際、SP統合エンジンはユーザーの転送時に/sp/startssoをrelativePathとして使用します。

Oracle Identity Federationは、新しいSP統合エンジンのIDおよびcontextPathとrelativePathを把握する必要があります。これは、フェデレーション・サーバーによって着信アサーションが処理された後にフェデレーションSSO処理の結果を処理するURLです。

10.4.2.2 SP統合エンジンの追加または変更

SP統合エンジンを追加または変更するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「SP統合モジュール」に移動します。「カスタムSPエンジン」タブをクリックします。

3. SP統合エンジンを追加するには、「追加」をクリックして、SP統合エンジンの名前を入力します。Oracle Identity Federationにより、新しいエンジンに対するIDが生成されます。

注意:
Fusion Middleware Controlでは、名前は表示目的でのみ使用し、Oracle Identity Federationと認証エンジン間の通信ではIDを使用します。

4. SP統合エンジンを変更するには、エンジンを選択して、次の操作を実行します。

- エンジンを有効または無効にします。

- 「Webコンテキスト」フィールドで、SP統合エンジンのcontextPathを指定します。

- 「ログイン相対パス」フィールドに、SP統合エンジンのログイン・サービスの相対パスを指定します。

- アサーション処理中にローカル認証手順を実行する必要がある場合に使用する認証メカニズムを選択します(これは、ユーザー・レコードへのアサーションのマップにフェデレーテッドIDが使用されている場合にフェデレーション・レコードが存在しないときに発生します。この場合、レコードを作成する1回かぎりの操作を実行するために、ユーザーをローカルに認証する必要があります)。

- ログアウトを有効または無効にします。

- 「ログアウト相対パス」フィールドに、SP統合エンジンのログアウト・サービスの相対パスを指定します。

5. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

10.4.2.3 サービスの実装

Oracle Identity Federationからリクエストを受信した後、SP統合エンジンは次の機能を実行する必要があります。

- ユーザー用の認証済セッションの作成

- 最終のURLへのユーザーのリダイレクト

SP統合モジュールにより設定される属性

フェデレーションSSO処理を開始するには、SP統合モジュールは次のデータをHttpServletRequest属性として指定することにより、ユーザーをOracle Identity Federationに転送する必要があります。

- 認証中に使用するようにIdPにリクエストする認証メカニズムをSPに対して指定する、オプションの認証メカニズム。(oracle.security.fed.sp.authnmechで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

注意:
設定された場合は、次に説明するように、このパラメータは使用すべきIdPを決定するために使用されます。この場合、usedefaultパラメータは無視されます。

- フェデレーションSSOで使用するIdPを参照する、オプションのプロバイダID。指定されていない場合、Oracle Identity Federationは指定された認証メカニズムにマップされたIdPを使用します。IdPが見つからなかった場合は、Oracle Identity FederationはデフォルトSSO IdPとして構成されているIdPを使用します。この値はStringです(oracle.security.fed.sp.provideridで識別)。

- フェデレーションSSOのトリガーに使用するアフィリエーションを参照する、オプションのフェデレーションID(String、oracle.security.fed.sp.federationidで識別)。

- リレー状態。リポジトリに保存されたデータへの参照などの短い文字列、またはSSO処理の完了後にユーザーをリダイレクトする保護リソースを指す短いURLを含む場合があります。(oracle.security.fed.sp.relaystateで識別)。

- SSOフローを開始したSPエンジンの識別子(String、oracle.security.fed.sp.engineidで識別)。

- Oracle Identity Federationサーバーが認証エンジンを使用してユーザーをローカルに認証すべきか、またはユーザーを認証用にIdPにリダイレクトしてフェデレーションSSOを開始すべきかを示す、オプションのboolean(Boolean、oracle.security.fed.sp.localauthnで識別。デフォルトはfalse)。

- Oracle Identity Federationに格納されている構成を使用すべきか、またはSPエンジンによって渡された、IdP以外の情報に基づいてSSO処理のみを開始すべきかを示す、Booleanオブジェクト(oracle.security.fed.sp.usedefaultで識別)。指定されていない場合、trueとみなされます。

- ユーザーが認証済の場合にもユーザーをチャレンジするようにSPがIdPに指示すべきかを示す、Booleanオブジェクト(oracle.security.fed.sp.forceauthnで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理中に、フェデレーション・レコードがまだ存在しない場合はレコードを作成することをSPがIdPに対して許可すべきかを示す、Booleanオブジェクト(oracle.security.fed.sp.allowfedcreationで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理中にユーザーと対話しないようにSPがIdPに指示すべきかを示す、Booleanオブジェクト(oracle.security.fed.sp.passiveで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- AuthnRequestの送信時に使用するバインディングを表すString(oracle.security.fed.sp.requestbindingで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。許容される値は、プロトコルに応じて、httpredirect、httpostまたはhttppostsimpleになります。

- アサーションを含むレスポンスの送信時に使用するバインディングを表すString(oracle.security.fed.sp.responsebindingで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。許容される値は、プロトコルに応じて、artifactまたはhttpostになります。

- 認証中に使用するようにIdPにリクエストする認証コンテキスト比較をSPに対して指定する、オプションの認証メカニズム比較(oracle.security.fed.sp.authnmechcomparisonで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理に関してSPがIdPに問い合せる名前IDフォーマットを表すString(oracle.security.fed.sp.nameidformatで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- フェデレーションSSO処理中に、アイデンティティ・プロバイダに対してリクエストするオプションの属性(たとえばOpenID IdPとの対話時に)。データは、キーとしてStringを、値としてオブジェクトのセットを使用するMapとして渡されます(oracle.security.fed.sp.attributesで識別)。値はオプションですが、キーには属性名が含まれます。

Oracle Identity Federationのアサーション処理

次にOracle Identity Federationは、リモートIdPとのSAML/WS-Fed SSO処理を実行し、アサーションを処理し、オプションでローカル・ユーザー・レコードにアサーションをマップし、最後に次の情報をHttpServletRequest属性として指定することにより、処理を開始したSP統合エンジンにユーザーを転送して戻します。

- SSO処理が成功したかどうかを示すBooleanオブジェクト(oracle.security.fed.sp.authnresultで識別)

- ユーザーの識別子(String、oracle.security.fed.sp.useridで識別)

- 認証時刻(Dateオブジェクト、oracle.security.fed.sp.authntimeで識別)

- 認証済セッションの有効期限(Dateオブジェクト、oracle.security.fed.sp.expirationtimeで識別)

- ユーザーを識別するために使用する認証メカニズム(String、oracle.security.fed.sp.authnmechで識別)

- リレー状態(String、oracle.security.fed.sp.relaystateで識別)

- アサーションの内容: 名前ID、アサーションの発行者およびオプションの属性。注意: アサーションの内容はXMLデータとしては渡されません。つまり、元のアサーションはモジュールには戻されません。データは、キーとしてStringを、値としてオブジェクトのセットを使用するMapとして渡されます(oracle.security.fed.sp.attributesで識別)。追加のデータは次のように参照されます。

- 名前ID値を含むorafed-nameid-value

- 名前ID修飾子を含むorafed-nameid-qualifier

- 名前IDフォーマットを含むorafed-nameid-format

- ピア・プロバイダIDを含むorafed-providerid

- orafed-assertionid - アサーションのID

- orafed-xmlmessage - アサーションを含むオプションのXMLメッセージ
詳細は、第6.13.2項「SSO完了後のSPエンジンへのXMLメッセージの送信」を参照してください。

- SAMLレスポンスの最高ステータス(String、oracle.security.fed.sp.topstatusで識別)

- SAMLレスポンスの低ステータス(存在する場合)(String、oracle.security.fed.sp.lowstatusで識別)

- ステータス・メッセージ(存在する場合)(String、oracle.security.fed.sp.statusmessageで識別)

- SSOアサーションを作成したプロバイダID(String、oracle.security.fed.sp.provideridで識別)

- 前述の情報を処理するSPエンジンの識別子(oracle.security.fed.sp.engineidで識別)

- ユーザー・セッションのOracle Identity Federation識別子を含むString。Oracle Identity Federationは、SPエンジンがユーザーにリンクされた状態を維持できるように、ユーザー・セッションのセッションIDを渡します。またOracle Identity Federationは、セッションID値を使用してそのデータを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするセッションIDをエンジンに渡します。(oracle.security.fed.sessionidで識別)。

認証済セッションの作成

これらのデータを使用して、SP統合エンジンは、認証済セッションを作成し、ユーザーを最終のターゲットURLにリダイレクトします。

サービスでCookieを設定する必要がある場合は、Cookieのパスを/に設定します。これは、Oracle Identity FederationのWebアプリケーションとSP統合エンジンのWebアプリケーション間の内部転送のために必要です。ユーザーのブラウザは、フェデレーション・サーバーにのみアクセスする場合にも、SP統合エンジンに関連するCookieを送信する必要があります。これにより、フェデレーション・サーバーからSP統合エンジンへの内部転送時に、エンジンによって設定されたCookieがHTTPリクエストで使用可能になります。

10.4.3 サンプルの統合モジュール

次の2つの項では、カスタム認証エンジンの実装例を示します。

- サンプルの統合モジュール1: Oracle WebLogic Server JavaEE統合

- サンプルの統合モジュール2: カスタム・シングル・サインオン統合

注意:
この後でサンプルの統合モジュール1および2として説明されているカスタム統合および認証用以外のアプリケーションをOracle WebLogic管理対象サーバーにデプロイすると、セキュリティ上のリスクが発生する可能性があるため、そのようなデプロイは行わないことをお薦めします。無関係なアプリケーションをOracle WebLogic管理対象サーバーにデプロイしたすると、悪意のあるソフトウェアによってサーバー・フローの動作が変更される可能性があるため、フェデレーション・サーバーのセキュリティに悪影響を及ぼすことがあります。

10.4.4 サンプルの統合モジュール1: Oracle WebLogic Server JavaEEコンテナ統合

この項では、javax.servlet.http.HttpSessionを使用して属性を設定する単純なSP統合エンジンを示します。この属性の存在により、ユーザーを認証するかどうかが決まります。

注意:
この項の例は、説明のみを目的としているため、本番環境では使用しないでください。この例では、Oracle WebLogic管理対象サーバーにデプロイされている他のアプリケーションがSP統合エンジンで設定されるデータを使用すると想定していますが、このようなアプローチは使用しないことをお薦めします。さらに、この例は、特定のデプロイメント、特にHttpSessionを複数のJ2EEアプリケーションに伝播しているデプロイメントでは、正しく機能しない場合があります。

設定

SP統合エンジンは、Oracle Identity Federationで使用されるユーザー・データ・ストアとは相互作用しません。

パッケージ化

SP統合エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。

- wlsintegration.jsp: フェデレーション・サーバーからのリクエストを処理し、ユーザー識別子が含まれるfeduserid属性を使用してHttpSessionを作成します。

- application.jsp: アプリケーションとして機能します。HttpSessionのfeduserid属性を検索し、属性が見つからない場合はフェデレーションSSOをトリガーします。

SP統合エンジンの追加または変更

SP統合エンジンを追加または変更するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「SP統合モジュール」に移動します。「カスタムSPエンジン」タブをクリックします。

3. SP統合エンジンを追加するには、「追加」をクリックして、SP統合エンジンの名前を入力します。Oracle Identity Federationにより、その新しいエンジンに対するIDが生成されます。このテストでは、このIDはTEST_ENGINE_IDとして参照します。

4. SP統合エンジンを変更するには、エンジンを選択して、次の操作を実行します。

- エンジンを有効にします。

- 認証エンジンの「Webコンテキスト」を/engineに設定します。

- SP統合エンジンの「ログイン相対パス」を/wlsintegration.jspに設定します。

- アサーション処理中にローカル認証手順を実行する必要がある場合に使用する認証メカニズムを選択します(これは、ユーザー・レコードへのアサーションのマップにフェデレーテッドIDが使用されている場合にフェデレーション・レコードが存在しないときに発生します。この場合、レコードを作成する1回かぎりの操作を実行するために、ユーザーをローカルに認証する必要があります)。

5. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

application.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String userid = (String)request.getSession().getAttribute("feduserid");
if (userid == null || userid.length() == 0) {
request.setAttribute("oracle.security.fed.sp.engineid", TEST_ENGINE_ID);
request.setAttribute("oracle.security.fed.sp.usedefault", Boolean.TRUE);
request.setAttribute("oracle.security.fed.sp.relaystate", "/engine/application.jsp");
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/sp/startsso").forward(request, response);
return;
}
%>
Welcome <%=userid%>

wlsintegration.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String userid = (String)request.getAttribute("oracle.security.fed.sp.userid");
String targetURL  = (String)request.getAttribute("oracle.security.fed.sp.relaystate");

request.getSession().setAttribute("feduserid", userid);
response.sendRedirect(targetURL);
%>

Logout

このアプリケーションではOracle WebLogic管理対象サーバー・インスタンスでHttpSessionを設定するため、SP統合エンジンをログアウト・フローと統合する必要があります(第10.5項「ログアウト」を参照)。

10.4.5 サンプルの統合モジュール2: カスタム・シングル・サインオン統合

この項で示すSP統合エンジンでは、ユーザー名および認証済セッションの有効期限が含まれているCookieに基づく単純なシングル・サインオン・フレームワークを使用します。

注意:
この例は、説明のみを目的としているため、本番環境では使用しないでください。たとえば、この例で設定されるCookieは暗号化されないため、攻撃者がこのようなCookieを手動で構成することで、ユーザーのなりすましが可能になります。

設定

SP統合エンジンは、Oracle Identity Federationで使用されるユーザー・データ・ストアとは相互作用しません。このエンジンは、String変数のユーザー識別子とlong変数のセッション・タイムアウトが含まれるCookieをドメイン全体に対して設定します。

パッケージ化

SP統合エンジンは、ルート・コンテキストが/engineに設定されたWebアプリケーションで構成され、次の2つのJSPページを含んでいます。

- domainintegration.jsp: Oracle Identity Federationサーバーからのリクエストを処理し、ユーザーIDおよびセッション・タイムアウトを含むCookieを作成します。

- domainapplication.jsp: アプリケーションとして機能します。Cookieを検索し、Cookieが見つからない場合はフェデレーションSSOをトリガーします。

SP統合エンジンの追加または変更

SP統合エンジンを追加または変更するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「SP統合モジュール」に移動します。「カスタムSPエンジン」タブをクリックします。

3. SP統合エンジンを追加するには、「追加」をクリックして、SP統合エンジンの名前を入力します。Oracle Identity Federationにより、その新しいエンジンに対するIDが生成されます。このテストでは、このIDはTEST_ENGINE_IDとして参照します。

4. SP統合エンジンを変更するには、エンジンを選択して、次の操作を実行します。

- エンジンを有効にします。

- 認証エンジンの「Webコンテキスト」を/engineに設定します。

- SP統合エンジンの「ログイン相対パス」を/domainintegration.jspに設定します。

- アサーション処理中にローカル認証手順を実行する必要がある場合に使用する認証メカニズムを選択します(これは、ユーザー・レコードへのアサーションのマップにフェデレーテッドIDが使用されている場合にフェデレーション・レコードが存在しないときに発生します。この場合、レコードを作成する1回かぎりの操作を実行するために、ユーザーをローカルに認証する必要があります)。

5. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

domainapplication.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*, java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

Cookie[] cookies = request.getCookies();
String userid = null;
Date timeout = null;
for(int i = 0, size = (cookies != null ? cookies.length : 0); i < size; i++) {
String name = cookies[i].getName();
if ("spintegrationcookie".equals(name)){
String value = cookies[i].getValue();
StringTokenizer st = new StringTokenizer(value, "*");
userid = st.nextToken();
timeout = new Date(Long.parseLong(st.nextToken()));
break;
}
}
if (userid == null || userid.length() == 0) {
request.setAttribute("oracle.security.fed.sp.engineid", TEST_ENGINE_ID);
request.setAttribute("oracle.security.fed.sp.usedefault", Boolean.TRUE);
request.setAttribute("oracle.security.fed.sp.relaystate", "/engine/domainapplication.jsp");
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/sp/startsso").forward(request, response);
return;
}
%>
Welcome <%=userid%>. You are logged until <%=timeout%>

domainintegration.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String userid = (String)request.getAttribute("oracle.security.fed.sp.userid");
String targetURL  = (String)request.getAttribute("oracle.security.fed.sp.relaystate");
Date expirationInst = (Date)request.getAttribute("oracle.security.fed.sp.expirationtime");
String cookieValue = userid + "*" + expirationInst.getTime();
Cookie cookie = new Cookie("spintegrationcookie", cookieValue);
cookie.setDomain(".us.example.com");
cookie.setPath("/");
response.addCookie(cookie);
response.sendRedirect(targetURL);
%>

Logout

このサンプルのアプリケーションではドメインCookieを設定するため、SP統合エンジンをログアウト・フローと統合する必要があります(第10.5項「ログアウト」を参照)。

10.5 ログアウト

この項では、ログアウト・フローを構成する方法を説明します。

10.5.1 ログアウト・フローの変更

この項には、ログアウト中のリダイレクションに関連する内容が含まれます。

URL

ユーザーは、ログアウト操作中に、フェデレーション・エンジンと、認証およびSP統合エンジンのログアウト・サービスとの間でリダイレクトされます。

Oracle Identity Federationは、ユーザーをサーブレット/jspページにリダイレクトしてログアウトするために、ログアウト・サービスの場所を認識している必要があります。このURLは、認証エンジンおよびSP統合エンジンのログアウト場所フィールドで定義します。URLは、エンジンのWebコンテキストとログアウト相対パスを組み合せたものとして定義できます。

ログアウト・サービスの実装

ログアウト・サービスでは、次の操作を実行する必要があります。

- フェデレーション・エンジンからのリクエストを処理し、ユーザーをIAMフレームワークからログアウトさせ、ユーザーをOracle Identity Federationに送り返します。

- IAMフレームワークからのリクエストを処理し、ユーザーをログアウトさせるためにOracle Identity Federationに送信し、ログアウト後にユーザーをOracle Identity Federationから受け取り、ユーザーをIAMフレームワークに送信します。

Oracle Identity Federationによる認証エンジンまたはSPエンジンの呼出し

Oracle Identity Federationは、ユーザーを認証エンジンまたはSPエンジンに送信する際に、次の処理を実行します。

1. エンジンのWebコンテキストおよび相対ログアウト・パスへの内部転送を実行します。

2. oracle.security.fed.authn.engineid(エンジンが認証エンジンの場合)またはoracle.security.fed.sp.engineid(エンジンがSPエンジンの場合)で参照されるHttpServletRequestの属性に、呼び出すエンジンのエンジンIDを指定します。

3. オプションで、oracle.security.fed.sessionidで参照され、ログアウト対象のユーザー・セッションの識別子(Stringオブジェクト)を格納する属性をHttpServletRequestで指定します。

認証エンジンまたはSPエンジンによるユーザーのログアウト時に、エンジンはユーザーをOracle Identity Federationに内部的に転送して戻し、次の処理を実行します。

1. /fed Webコンテキストおよび/user/logoutretssoへの内部転送を実行します。

2. oracle.security.fed.authn.engineid(エンジンが認証エンジンの場合)またはoracle.security.fed.sp.engineid(エンジンがSPエンジンの場合)で参照されるHttpServletRequestの属性に、呼び出されたエンジンのエンジンIDを指定します。この属性値は、ログアウト処理を実行したエンジンの識別子です。

認証エンジンまたはSPエンジンによるOracle Identity Federationの呼出し

認証エンジンまたはSPエンジンは、ログアウト時にOracle Identity Federationを呼び出す場合、次の処理を実行します。

1. /fed Webコンテキストおよび/user/logoutssoへの内部転送を実行します。

2. oracle.security.fed.authn.engineid(エンジンが認証エンジンの場合)またはoracle.security.fed.sp.engineid(エンジンがSPエンジンの場合)で参照されるHttpServletRequestの属性に、呼び出すエンジンのエンジンIDを指定します。この属性値は、ログアウト用に呼び出すエンジンの識別子です。

3. Oracle Identity Federationがログアウト後にユーザーをリダイレクトする戻りURLを指定します。このURLは、oracle.security.fed.logout.returnurlで参照されるHttpServletRequestの属性で指定します。

ログアウト・フローの最後に、ユーザーはOracle Identity Federationからログアウトされ、戻りURLにリダイレクトされます。

10.5.2 サンプルのログアウト・サービス

次の2つの項では、ログアウト・サービスの次の使用例を概説します。

- ログアウト・サービス例1では、認証エンジンとSP統合エンジンの両方がカスタマイズされている場合のカスタム・ログアウト・サービスについて説明します。

- ログアウト・サービス例2では、SP統合エンジンのみがカスタマイズされている場合のカスタム・ログアウト・サービスについて説明します。

10.5.3 ログアウト・サービス例1

この項では、認証エンジンとSP統合エンジンの両方がカスタマイズされている場合、つまりデフォルト・エンジンが使用されていない場合に、カスタム・ログアウト・サービスを統合する方法を説明します。

設定

この例では、認証エンジンは第10.3項「カスタム認証エンジンの作成」で説明したLDAPエンジンであり、SP統合エンジンは第10.4.4項「サンプルの統合モジュール1: Oracle WebLogic Server JavaEEコンテナ統合」で説明したOracle WebLogic Server統合エンジンです。

パッケージ化

ログアウト・サービスは、認証およびSP統合エンジンとバンドルされている次のJSPページで構成されています。

- logout.jsp: Oracle Identity Federationからのリクエストを処理し、wlsintegration.jspページで設定されているHttpSessionオブジェクトからfeduserid属性を削除し、ユーザーをOracle Identity FederationまたはdoneURLパラメータにリダイレクトします。

エンジンの更新

エンジンを更新するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「SP統合モジュール」に移動します。「カスタムSPエンジン」タブをクリックします。

3. SP統合エンジンを変更するには、エンジンを選択して、次の操作を実行します。

- ログアウト・エンジンを有効にします。

- SP統合エンジンの「ログアウト相対パス」を/logout.jspに設定します。

4. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

logout.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

request.getSession().removeAttribute("feduserid");

request.setAttribute("oracle.security.fed.sp.engineid", TEST_ENGINE_ID);

request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/logoutretsso").forward(request, response);
%>

10.5.4 ログアウト・サービス例2

この項では、SP統合エンジンがカスタマイズされている場合に、カスタム・ログアウト・サービスを統合する方法を説明します。

設定

この例では、SP統合エンジンは、第10.4.5項「サンプルの統合モジュール2: カスタム・シングル・サインオン統合」で説明したカスタマイズされたSSO統合エンジンです。

パッケージ化

ログアウト・サービスは、認証およびSP統合エンジンとバンドルされている次のJSPページで構成されています。

- domainlogout.jsp: Oracle Identity Federationからのリクエストを処理し、Cookieを削除し、ユーザーを/logoutretsso URLにリダイレクトします。

エンジンの更新

エンジンを更新するには、次の手順を実行します。

1. Fusion Middleware Controlで、Oracle Identity Federationインスタンスに移動します。

2. 「管理」→「SP統合モジュール」に移動します。

3. SP統合エンジンを変更するには、エンジンを選択して、次の操作を実行します。

- ログアウト・エンジンを有効にします。

- SP統合エンジンの「ログアウト相対パス」を/domainlogout.jspに設定します。

4. 変更を保存します。

関連項目:
第5.16項「SP統合モジュールの構成」

domainlogout.jspの実装

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

Cookie cookie = new Cookie("spintegrationcookie", "");
cookie.setDomain(".us.example.com");
cookie.setPath("/");
cookie.setMaxAge(0);
response.addCookie(cookie);

request.setAttribute("oracle.security.fed.sp.engineid", TEST_ENGINE_ID);

request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/logoutretsso").forward(request, response);
%>

11 ビジネス処理プラグイン用のOracle Identity Federationの構成

Oracle Identity Federationは、サーバーによって実行される操作のビジネス処理をカスタマイズするためのプラグイン・フレームワークを提供します。この章では、プラグイン機能について説明し、例を紹介します。

- ビジネス処理プラグインについて

- ビジネス処理プラグインの構成

- プラグインのパッケージ化

- JavaEEセキュリティの構成

- プラグインとリダイレクト・ページの例

- ビジネス処理プラグインAPI

11.1 ビジネス処理プラグインについて

この項では、プラグイン・フレームワークのいくつかの要点について説明します。

- ビジネス処理プラグインの基本フロー

- 実装

- プラグインの構築、操作およびパラメータ

11.1.1 ビジネス処理プラグインの基本フロー

プロセス・フローは次のようになります。

- ビジネス・フローの様々なセクションで呼び出されるプラグインを実装します。

- プラグインでは、操作の実行中に収集されたデータを分析し、追加のビジネス・ステップが必要かどうかを判断できます。

- 追加のアクションを実行すべき場合は、プラグインはユーザーのリダイレクト先のURLをOracle Identity Federationに返します。

- リダイレクションURLには、プラグインによって設定された問合せ文字列パラメータを含めることができます。

- Oracle Identity FederationはrefIDによって参照される1つの問合せ文字列パラメータを追加します。これは、ユーザーがOracle Identity Federationに戻される際に送信されます。

- 追加の操作が実行された場合、ユーザーはrefidパラメータとともに次のURLでOracle Identity Federationにリダイレクトされる必要があります。

http(s)://OIF-HOST:OIF-PORT/fed/user?refid=VALUE_RETRIEVED_FROM_REDIRECT_URL

11.1.2 実装

ビジネス・プラグインを実装するために必要な作業は次のとおりです。

- プラグインの構築
第11.1.3項「プラグインの構築、操作およびパラメータ」を参照してください。

- Oracle Identity Federation構成ファイルへのプラグインの登録
第11.2項「ビジネス処理プラグインの構成」を参照してください。

- プラグインのJARファイルへのパッケージ化、およびJARファイルのCLASSPATHへの追加
第11.3項「プラグインのパッケージ化」を参照してください。

- JavaEEセキュリティの設定
第11.4項「JavaEEセキュリティの構成」を参照してください。

- Oracle WebLogic Serverを再起動します。

11.1.3 プラグインの構築、操作およびパラメータ

プラグインの構築

プラグインはoracle.security.fed.plugins.bizops.OperationListenerインタフェースを拡張し、public ListenerResult process(int operationType, OperationData params)メソッドを実装する必要があります。

このメソッドには2つの引数があります。1つ目には実行される操作のタイプを、2つ目にはこの操作に関連するパラメータを指定します。このパラメータはプラグインが判断する際に使用します。メソッドは、ステータスおよびオプションのredirectURLを含むListenerResultクラスを返します。ステータスがOKの場合、Oracle Identity Federationは操作を再開します。OKではない場合は、指定されたリダイレクションURLにユーザーをリダイレクトします。

操作

次の操作があります。

- OperationTypes.BUSINESS_IDP_CREATE_PERSISTENT_FEDERATION: IdP側に永続フェデレーションが作成されることを示します。

- OperationTypes.BUSINESS_IDP_CREATE_TRANSIENT_FEDERATION: IdP側に一時フェデレーションが作成されることを示します。

- OperationTypes.BUSINESS_IDP_SSO: IdP側でSSO処理が実行されることを示します。

渡されるパラメータ

OperationDataオブジェクトで渡されるパラメータは次のとおりです。

- BusinessProcessingConstants.DATA_STRING_PROVIDERID: サービス・プロバイダIDを参照します。タイプはStringです

- BusinessProcessingConstants.DATA_STRING_USERID: ユーザーIDを参照します。タイプはStringです。

- BusinessProcessingConstants.DATA_STRING_SESSIONID: セッションIDを参照します。タイプはStringです。

- BusinessProcessingConstants.DATA_STRING_NAMEID_FORMAT: 作成されているフェデレーションの名前IDフォーマットを参照します。タイプはStringです。

- BusinessProcessingConstants.DATA_STRING_PROTOCOL_VERSION: 実行されるプロトコルを参照します。タイプはStringです。

- BusinessProcessingConstants.DATA_BOOLEAN_AUTHNREQUEST_ISPASSIVE: AuthnRequestからのIsPassiveフィールドを参照します。タイプはBooleanです

ListenerResultクラスの戻りステータス値は次のとおりです。

- BusinessProcessingConstants.STATUS_OK: プラグインには特定のアクションは必要ないことを示します。

- BusinessProcessingConstants.STATUS_REDIRECT: プラグインはユーザーをURLにリダイレクトする必要があることを示します。

11.2 ビジネス処理プラグインの構成

Oracle Identity Federation構成ファイルにプラグインを追加するには、次の手順を実行します。

1. $DOMAIN_HOME/config/fmwconfig/servers/wls_oif1/applications/OIF_11.1.1.2.0/configuration/config.xmlファイルを開きます。

2. 属性名がserverconfigであるConfig XML要素を見つけます。

3. 属性名がbusinessprocessingpluginsであるPropertiesList XML要素を見つけます。

4. Property XML子要素をPropertiesListに追加します。Property要素のテキスト子要素はプラグインのクラス名にし、この要素のタイプ属性はstringにする必要があります。

5. 保存して終了します。

構成ファイルの例を次に示します。

<FederationConfig xmlns="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd" version="0" activationenabled="false">
<Config name="serverconfig">
...
<PropertiesList name="businessprocessingplugins">
<Property type="string">oracle.security.fed.plugins.BusinessProcessingSample</Property>
</PropertiesList>
...
</Config>
...
</FederationConfig>

11.3 プラグインのパッケージ化

プラグインをパッケージ化するには、次の手順を実行します。

1. プラグインをjarファイルに追加します。

2. jarファイルをOracle WebLogic Serverのlibディレクトリにコピーします。

Oracle/Middleware/user_projects/domains/IDMDomain/lib

3. 必要な他のjarファイルを同じディレクトリにコピーします。

- oif.jarをOracle/Middleware/Oracle_IDM1/fed/jlib/からOracle/Middleware/user_projects/domains/IDMDomain/libにコピーします。

注意:
パッチ・セットを適用するたびに、この手順を繰り返します。

- commons-httpclient-3.1.jarを同じディレクトリにコピーします。

- commons-codec-1.2.jarを同じディレクトリにコピーします。

環境構成の詳細は、『Oracle Fusion Middleware管理者ガイド』の環境変数の設定に関する項を参照してください。

11.4 JavaEEセキュリティの構成

次の場所にあるWebLogicポリシー・ファイルを更新します。

Oracle/Middleware/wlserver_10.3/server/lib/weblogic.policy

このファイルに次の行を追加します。

grant codeBase "file:${user.domain}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase
"file:/home/oracle/Oracle/Middleware/user_projects/domains/IDMDomain/lib/-"
{
permission java.security.AllPermission;
};

11.5 プラグインとリダイレクト・ページの例

サンプル・プラグインは、次のようになります。

package oracle.security.fed.plugins;

import java.net.URLEncoder;
import java.util.Set;
import java.util.HashSet;

import oracle.security.fed.plugins.bizops.BusinessProcessingConstants;
import oracle.security.fed.plugins.bizops.BusinessProcessingException;
import oracle.security.fed.plugins.bizops.ListenerResult;
import oracle.security.fed.plugins.bizops.OperationData;
import oracle.security.fed.plugins.bizops.OperationListener;
import oracle.security.fed.plugins.bizops.OperationTypes;

// in this example, the plug-in will redirect the user to an external page the first time a user
// creates a persistent federation. Later on, if the user creates another federation (with the same
// provider or another one), the plug-in will not redirect the user anymore.
// Note: restarting the server will wipe out the cached information from the plug-in, resetting the data
// indicating whether or not any user was already redirected to the external page.

public class BusinessProcessingSample implements OperationListener {

private Set licenseAgreements = new HashSet();

public ListenerResult process(int operationType, OperationData params)
throws BusinessProcessingException {
ListenerResult result = new ListenerResult(BusinessProcessingConstants.STATUS_OK);

switch(operationType)
{
case OperationTypes.BUSINESS_IDP_CREATE_PERSISTENT_FEDERATION:
String userid = params.getStringProperty(BusinessProcessingConstants.DATA_STRING_USERID);
if (!licenseAgreements.contains(userid))
{
// redirect to remote page
result.setStatus(BusinessProcessingConstants.STATUS_REDIRECT);

StringBuffer sb = new StringBuffer();
sb.append("http://WEB-SERVER-HOST:WEB-SERVER-PORT/businesstest.jsp?providerid=");
sb.append(URLEncoder.encode(params.getStringProperty(BusinessProcessingConstants.DATA_STRING_PROVIDERID)));
sb.append("&userid=");
sb.append(URLEncoder.encode(params.getStringProperty(BusinessProcessingConstants.DATA_STRING_USERID)));
result.setRedirectURL(sb.toString());

// add the user to the license agreement set
licenseAgreements.add(userid);
}
break;
}

return result;
}
}

次に、サンプル・リダイレクト・ページを示します。

<%@ page language="java"
import="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");

String providerid = request.getParameter("providerid");
String userid = request.getParameter("userid");
String refid = request.getParameter("refid");

String returnurl = "http://OIF-HOST:OIF-PORT/fed/user?refid=" + URLEncoder.encode(refid);
%>

<html>
<body>
License Agreeement approved for:
ProviderID = <%=providerid%>
<BR>
UserID = <%=userid%>
<BR>
<a href="<%=returnurl%>">Click here to resume flow</a>

</body>
</html>

11.6 ビジネス処理プラグインAPI

ビジネス処理プラグインAPI(javadoc)は次のページから入手できます。

Oracle Fusion Middleware Oracle Identity Federationビジネス処理プラグインJava APIリファレンス

12 カスタム・アクションの実装

カスタム・アクションを使用すると、Oracle Identity Federationフローで認証エンジンまたはSP統合エンジンの呼出し前または後に、サイト固有の操作を実行できます。

Oracle Identity Federationでは、前処理および後処理アクション・プラグインを使用してカスタム・アクションを実装します。この章では、カスタム・アクションを実装する方法について説明します。

- カスタム・アクションの概要

- 認証エンジン用の前処理カスタム・アクション

- 認証エンジン用の後処理カスタム・アクション

- SP統合エンジン用の前処理カスタム・アクション

- SP統合エンジン用の後処理カスタム・アクション

注意:
ここでは、Oracle Identity Federationをフェデレーション・サーバーとも呼びます。

12.1 カスタム・アクションの概要

前処理および後処理プラグインは、認証フロー中に呼び出されるJSPまたはJavaEEサーブレットとして実装されます。

- 認証エンジンの呼出し前後

- SP統合エンジンの呼出し前後

カスタム・アクションは、カスタム・エンジンも含め、すべての認証エンジンおよびSP統合エンジンで使用できます。この項では、アクションがどのように機能し、Oracle Identity Federationとどのように相互作用するかについて説明します。

- 認証エンジン用の前処理および後処理カスタム・アクション

- SP統合エンジン用の前処理および後処理カスタム・アクション

- カスタム・アクションのアーキテクチャ

12.1 認証エンジン用の前処理および後処理カスタム・アクション

Oracle Identity Federationは、実行時にユーザーの識別が必要な場合に認証エンジンを呼び出します。次のステップは、イベントの一般的なフローを示しています。

1. Oracle Identity Federationが次のステップを実行します。

- ユーザーを識別する必要があることを判断します。

- 使用する認証エンジンを選択します。

- 認証エンジンの場所を取得します。

- エンジンのエンドポイントのルート・コンテキストと相対パスを指定して、ユーザーを認証エンジンに内部的に転送します。

2. ユーザー・アイデンティティを確認するために外部認証プロバイダと対話するプラガブル・モジュールである認証エンジンが、次のステップを実行します。

- ユーザーと対話して、資格証明を取得します。たとえば、LDAP認証エンジンはユーザー資格証明を取得するためにログイン・ページを表示します。取得した資格証明はLDAPディレクトリとの照合により検証されます。

- 成功した場合は、ユーザーを認証情報とともにOracle Identity Federationに内部的に転送して戻します。認証情報は、ユーザー識別子とアイデンティティが確認された時刻から構成されます。

3. Oracle Identity Federationが情報を分析し、ユーザー・セッションを作成または更新します。

カスタム・アクションを使用して次のことを行えます。

- フェデレーション・サーバーと認証エンジン間で交換されるデータを操作する。たとえば、ユーザー名johndoeから電子メール・アドレスjohndoe@mycompany.comを作成できます。

- 認証中に追加のステップを実行する。たとえば、ユーザーに関する情報をさらに得るために、外部のデータソースまたはシステムに接続できます。

カスタム・アクション・プラグインを設定するには、次の操作を実行します。

- 認証エンジンの呼出し前に実行される前処理アクション・プラグインを実装します。

- 認証後に、ユーザーが認証エンジンからOracle Identity Federationにリダイレクトされる際に実行されるアクションや変更に応じた後処理プラグインを実装します。

- Oracle Identity Federationが実行されているWebLogic管理対象サーバーにプラグインをデプロイします。

- 認証エンジンのかわりにプラグインを呼び出して、プラグインが前処理タスクを実行できるように、Oracle Identity Federationを構成します。

- Oracle Identity Federationにリダイレクトするかわりにプラグインを呼び出して、プラグインが後処理タスクを実行できるように、認証エンジンを構成します。

注意:
デフォルトの(出荷時に設定されている)認証エンジンを使用している場合は、Oracle Identity Federation構成を変更する必要があります。カスタム・エンジンを使用している場合は、そのエンジンを更新する必要があります。

12.1.2 SP統合エンジン用の前処理および後処理カスタム・アクション

Oracle Identity Federationがサービス・プロバイダとして機能している場合、次のいずれかの操作が行われます。

- IDおよびアクセス管理(IAM)システム(Oracle Access Managerなど)が、フェデレーテッドSSO処理を実行してリモート・アイデンティティ・プロバイダでユーザーを認証するために、Oracle Identity Federationを呼び出します。

- リモート・アイデンティティ・プロバイダが、SPドメイン内の保護リソースにユーザーがアクセスできるようにフェデレーテッドSSO処理を開始します。
IAMシステムがフェデレーテッドSSOのためにOracle Identity Federationを呼び出す場合のフローは次のとおりです。

1. ユーザーが、IAMシステムで保護されているリソースへのアクセスを試みます。

2. IAMシステムが、フェデレーテッドSSO処理によって認証される必要があることを判断します。

3. IAMシステムが、統合されているOracle Identity Federation SPエンジンにユーザーをリダイレクトします。

4. Oracle Identity Federation SP統合モジュール(カスタム・モジュールの場合もある)がなんらかの操作を行い、操作に必要な情報を指定してユーザーをOracle Identity Federationに内部的に転送します。たとえば、使用する認証メカニズム、リレー状態などを指定できます。

5. Oracle Identity Federationが情報を処理し、フェデレーテッドSSO処理をトリガーし、認証用にリモート・アイデンティティ・プロバイダにユーザーをリダイレクトします。

6. アイデンティティ・プロバイダがユーザーを識別してアサーションを作成し、ユーザーをOracle Identity Federation/SPにリダイレクトして戻します。

7. Oracle Identity Federationがアサーションを検証し、ローカル・ドメイン内のユーザーにマップし、ユーザーに対するOracle Identity Federationセッションを作成します。

8. Oracle Identity Federationが、フローをトリガーしたSP統合モジュール(またはIdP開始のSSO処理の場合はデフォルトのSP統合モジュール)にユーザーを内部的に転送して戻します。

9. SP統合モジュールがデータを処理してWebアクセス・セッションを作成し、ユーザーを保護リソースにリダイレクトします。

10. IAMシステムが、リソースへのアクセスをユーザーに許可します。

カスタム・アクションを使用して、フェデレーション・サーバーとSP統合モジュール間で交換されるデータをカスタマイズし、処理中に特定のアクションを実行できます。

カスタム・アクション・プラグインを設定するには、次の操作を実行します。

- SP統合モジュールがOracle Identity Federationにユーザーをリダイレクトしてフローを開始する前にアクションまたは変更を実行する必要がある場合は、前処理プラグインを実装します。

- フェデレーテッドSSO処理の後、ユーザーがOracle Identity FederationからSP統合モジュールにリダイレクトされる際にアクションまたは変更を実行する必要がある場合は、後処理プラグインを実装します。

- Oracle Identity Federationが実行されているWebLogic管理対象サーバーにプラグインをデプロイします。

- Oracle Identity Federationにリダイレクトするかわりにプラグインを呼び出して、プラグインがカスタム・タスクを実行できるように、SP統合モジュールを構成します。

注意:
デフォルトの(出荷時に設定されている)SP統合モジュールを使用している場合は、Oracle Identity Federation構成を変更する必要があります。カスタム・エンジンを使用している場合は、そのエンジンを更新する必要があります。

- SP統合モジュールのかわりにプラグインを呼び出して、プラグインがカスタム・タスクを実行できるように、Oracle Identity Federationを構成します。

12.1.3 カスタム・アクションのアーキテクチャ

図12-1に、カスタム・アクション・プラグインのアーキテクチャを示します。

図12-1 カスタム・アクション・プラグイン

この図では、Oracle Identity Federationはカスタマイズされており、次の時点でプラグインを呼び出すように構成されています。

- SP統合エンジンがOracle Identity Federationを呼び出す前

- Oracle Identity FederationがSP統合エンジンを呼び出す前

- Oracle Identity Federationが認証エンジンを呼び出す前

- 認証エンジンがOracle Identity Federationを呼び出す前

12.1.3.1 SPとしてのOracle Identity Federationのフロー

Oracle Identity Federationがサービス・プロバイダとして機能するフェデレーテッドSSO処理のフローは次のとおりです。

1. Oracle Access ManagerなどのIDおよびアクセス管理(IAM)モジュールが、フェデレーテッドSSO処理を開始するためにSP統合エンジンを呼び出します。SP統合エンジンが、カスタム・アクションを実行するためのSPエンジン用の前処理プラグインを呼び出します。

2. SPエンジン用の前処理プラグインが、フェデレーテッドSSOフローを開始するためにOracle Identity Federationを呼び出します。

3. Oracle Identity Federationが、ユーザーの認証およびアサーションの作成が行われるIdPにユーザーをリダイレクトします。

4. IdPが、検証およびユーザーへのマップが行われたアサーションとともに、ユーザーをOracle Identity Federationにリダイレクトして戻します。

5. Oracle Identity Federationがユーザーとアサーション・データをバンドルし、なんらかのカスタム・タスクを実行するためにSPエンジン用の後処理プラグインを呼び出します。

6. 後処理プラグインがユーザーとアサーション・データを提供して、SP統合エンジンを呼び出します。

7. SPエンジンがIAMドメイン内にユーザー・セッションを作成し、ユーザーを保護リソースにリダイレクトします。

12.1.3.2 ユーザーを認証するOracle Identity Federationのフロー

Oracle Identity Federationがユーザーを認証する必要がある場合のフローは次のとおりです。

1. Oracle Identity Federationが実行時フローの一環として、ユーザーをローカルに認証する必要があることを判断します。なんらかのカスタム・タスクを実行するために認証エンジン用の前処理プラグインを呼び出します。

2. 前処理プラグインが認証エンジンを呼び出します。

3. 認証エンジンが、IAMドメインを使用してユーザーをチャレンジし、識別します。

4. 認証エンジンが認証データをバンドルし、なんらかのカスタム・タスクを実行するために認証エンジン用の後処理プラグインを呼び出します。

5. 認証エンジン用の後処理プラグインが、認証データを提供して、Oracle Identity Federationを呼び出します。

6. Oracle Identity Federationが処理を再開します。

12.2 認証エンジン用の前処理カスタム・アクション

前処理プラグインは、認証操作の一環として、認証エンジンを呼び出す前にユーザーがリダイレクトされるモジュールです。このプラグインにより、認証前にカスタム・アクションを実行することが可能になります。

プラグインの使用時には、Oracle Identity Federationはユーザーを認証エンジンにリダイレクトしません。かわりに、ユーザーをプラグインに内部的に転送し、認証中に使用する特定のデータをプラグインに渡します。カスタム・アクションの実行後、プラグインはフェデレーション・サーバーによって提供された元のデータとともに、認証フローを再開するように、ユーザーを適切な認証エンジンに転送します。

12.2.1 前処理カスタム・アクションの実装

カスタム・アクションとOracle Identity Federationとの相互作用

Oracle Identity Federationはユーザーを認証エンジンにリダイレクトするときに、HttpServletRequestオブジェクトの属性として、特定のデータをエンジンに渡します。同じデータが前処理プラグインにも提供されます。

- ユーザーのIDのチャレンジ時に使用する認証メカニズム(String、oracle.security.fed.authn.authnmechで識別)。

- 実行中のアクションを参照する識別子(String、oracle.security.fed.authn.refidで識別)。

- フェデレーテッドSSO処理が行われている場合は、このローカル認証をリクエストしているリモート・サービス・プロバイダのプロバイダIDと説明(String、それぞれoracle.security.fed.authn.provideridおよびoracle.security.fed.authn.providerdescriptionで識別)。

- ユーザーの認証に使用するエンジンを参照する識別子(String、oracle.security.fed.authn.engineidで識別)。

- 設定されている場合は、ユーザーの識別子(String、oracle.security.fed.authn.useridで識別)。

- ユーザーがすでに認証済でもエンジンがユーザーをチャレンジすべきかどうかを示す強制認証フラグ。指定されていない場合、falseとみなされます。(Boolean、oracle.security.fed.authn.forceauthnで識別)

- エンジンがユーザーと視覚的に対話可能かどうかを示すパッシブ・フラグ。指定されていない場合、falseとみなされます(Boolean、oracle.security.fed.authn.passiveで識別)

- オプションで、エンジンが設定する必要がある属性のマップ。これらの属性は、特定のリモート・プロバイダの構成で指定されたとおりに、Oracle Identity Federation/IdPがAttributeStatementを使用してアサーションを正しく作成するために必要です。(oracle.security.fed.authn.attributesで識別)
Oracle Identity FederationがSSOアサーションを受け取って処理したが、アサーションをローカル・ユーザーにマップできない場合、サーバーはユーザーをローカルに認証することをリクエストします。この場合、マップにはアサーションからの次のデータが含まれます。

- orafed-nameid-value - ユーザーの名前ID値

- orafed-nameid-qualifier - ユーザーの名前ID修飾子

- orafed-nameid-format - ユーザーの名前IDフォーマット

- orafed-providerid - IdPのプロバイダID

- orafed-assertionid - アサーションのID

- orafed-xmlmessage - アサーションを含むオプションのXMLメッセージ

- ユーザーがすでにアクティブなセッションを開始している場合は、オプションでOracle Identity Federationのセッション識別子。Oracle Identity Federationは、認証エンジンがユーザーにリンクされた状態を維持できるように、すでに存在するユーザー・セッションのセッション識別子をエンジンに渡し、セッションID値を使用してそのデータを参照します。(String、oracle.security.fed.sessionidで識別)
後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity Federationはセッション識別子をエンジンに渡します。

関連項目:
第10.3.2項「認証モジュールの開発および実装」

認証エンジンへのユーザーの転送

処理後に、前処理プラグインはユーザーを適切な認証エンジン(プラグインがない場合にOracle Identity Federationが呼び出すエンジン)に転送する必要があります。

HttpServletRequestオブジェクト内にあるoracle.security.fed.authn.engineid属性を使用して、ユーザーの内部転送先のパスを決定できます。使用可能なエンジンID値を表12-1に示します。

表12-1 認証エンジンのエンジンID

エンジンID

意味

osso

ルート・コンテキスト/fedおよび相対パス/user/authnossoで参照されるエンドポイントへの転送を実行することにより、Oracle Single Sign-Onエンジンを呼び出します。

oam

ルート・コンテキスト/fedおよび相対パス/user/authnoamで参照されるエンドポイントへの転送を実行することにより、Oracle Access Managerエンジンを呼び出します。

ldap

ルート・コンテキスト/fedおよび相対パス/user/authnldapで参照されるエンドポイントへの転送を実行することにより、LDAPエンジンを呼び出します。

rdbmssec

ルート・コンテキスト/fedおよび相対パス/user/authnrdbmssecで参照されるエンドポイントへの転送を実行することにより、RDBMSセキュリティ・エンジンを呼び出します。

rdbmstable

ルート・コンテキスト/fedおよび相対パス/user/authnrdbmstbで参照されるエンドポイントへの転送を実行することにより、RDBMS表エンジンを呼び出します。

jaas

ルート・コンテキスト/fedおよび相対パス/user/authnjaasで参照されるエンドポイントへの転送を実行することにより、JAASエンジンを呼び出します。

infocard

ルート・コンテキスト/fedおよび相対パス/user/authnicで参照されるエンドポイントへの転送を実行することにより、情報カード・エンジンを呼び出します。

proxy

ルート・コンテキスト/fedおよび相対パス/user/authnproxyで参照されるエンドポイントへの転送を実行することにより、フェデレーションSSOプロキシ・エンジンを呼び出します。

httpheader

ルート・コンテキスト/fedおよび相対パス/user/authnhttpで参照されるエンドポイントへの転送を実行することにより、HTTPヘッダー・エンジンを呼び出します。

注意:

- プラグインは、認証フローの一環としてプラグインに渡されたデータ(すなわちHttpServletRequestオブジェクトに設定されている属性)を認証エンジンに提供する必要があります。

- プラグインは、HttpServletRequestオブジェクトに設定されているすべての属性(oracle.security.fed.authn.authnmech、oracle.security.fed.authn.refidおよびoracle.security.fed.authn.engineid属性を除く)を変更できます。

12.2.2 カスタム・アクション用のOracle Identity Federationの構成

次の作業を実行することにより、ユーザーを前処理プラグインに転送するようにOracle Identity Federationを構成します。

- フローを変更する認証エンジンを指定します。選択可能なエンジンは、Oracle SSO、OAM、LDAP、RDBMSセキュリティ、RDBMS表、プロキシ、JAASおよび情報カードです。

- 次の2つのプロパティを作成または設定します。

- Webコンテキスト・プロパティ: 前処理プラグインのカスタムJSPページまたはサーブレットが置かれているWebコンテキストを参照します。このプロパティは、Oracle Identity Federation構成のauthnenginesグループにあります。

- 相対パス・プロパティ: カスタム・プラグインが置かれているWebコンテキスト内のパスを参照します。

表12-2に、各認証エンジンのプロパティの設定方法を示します。

表12-2 前処理プラグインに対する認証エンジンの構成

認証
エンジン

Webコンテキスト・プロパティ

相対パス・プロパティ

Oracle Single Sign-On

osso-login-context(デフォルトは、指定なし)

osso-login(デフォルトは、/user/authnosso)

Oracle Access Manager 10g

oam-login-context(デフォルトは、指定なし)

oam-login(デフォルトは、/user/authnoam)

Oracle Access Manager 11g

oam11g-login-context (デフォルトは、指定なし)

oam11g-login (デフォルトは、/user/spretoam11g)

LDAP

ldap-login-context(デフォルトは、指定なし)

ldap-login(デフォルトは、/user/authnldap)

RDBMSセキュリティ

rdbmssec-login-context(デフォルトは、指定なし)

rdbmssec-login(デフォルトは、/user/authnrdbmssec)

RDBMS表

rdbmstable-login-context(デフォルトは、指定なし)

rdbmstable-login(デフォルトは、/user/authnrdbmstb)

JAAS

jaas-login-context(デフォルトは、指定なし)

jaas-login(デフォルトは、/user/authnjaas)

情報カード

infocard-login-context(デフォルトは、指定なし)

infocard-login(デフォルトは、/user/authnic)

フェデレーションSSOプロキシ

proxy-login-context(デフォルトは、指定なし)

proxy-login(デフォルトは、/user/authnproxy)

HTTPヘッダー

httpheader-login-context(デフォルトは、指定なし)

httpheader-login(デフォルトは、/user/authnhttp)

Oracle Identity Federation構成内でこれらのプロパティを設定するには、WLSTコマンドを使用します。

たとえば、Oracle SSOエンジンの前に前処理プラグインを呼び出すように構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境で次のコマンドを使用します。

setConfigProperty('authnengines', 'osso-login-context', '/rootcontext', 'string')

setConfigProperty('authnengines', 'osso-login', '/relativepath', 'string')

12.3 認証エンジン用の後処理カスタム・アクション

認証エンジンが処理を完了した後、ユーザーがOracle Identity Federationにリダイレクトされる前に、ユーザーは認証操作の一環として後処理プラグイン・モジュールにリダイレクトされます。このプラグインにより、認証後にカスタム・アクションを実行することが可能になります。

プラグインの使用時には、認証エンジンは認証データとともにユーザーをプラグインに内部的に転送します。カスタム・アクションの実行後、プラグインは認証データとともにユーザーをOracle Identity Federationに転送します。

注意:
使用可能な認証エンジンは、Oracle SSO、OAM、LDAP、RDBMSセキュリティ、RDBMS表、プロキシ、JAAS、情報カードおよびHTTPヘッダーです。

12.3.1 後処理プラグインの実装

カスタム・アクションとOracle Identity Federationとの相互作用

認証エンジンは認証フロー中にユーザーをOracle Identity Federationにリダイレクトするときに、HttpServletRequestオブジェクトの属性として、次のデータをプラグインに渡します。

- ユーザーの識別子(String、oracle.security.fed.authn.useridで識別)。

- 認証時刻(Date、oracle.security.fed.authn.authntimeで識別)

- 認証済セッションの有効期限(Date、oracle.security.fed.authn.expirationtimeで識別)

- ユーザーを識別するために使用する認証メカニズム(String、oracle.security.fed.authn.authnmechで識別)。

- リクエストからの、実行されたアクションを参照する識別子(String、oracle.security.fed.authn.refidで識別)。

- ユーザーの認証に使用するエンジンを参照する識別子(String、oracle.security.fed.authn.engineidで識別)。

- オプションで、ユーザー・セッションに格納される属性のマップ。このマップは、キーとしてStringオブジェクトを、値としてオブジェクトのセットを持ちます(oracle.security.fed.authn.attributesで識別)。

- オプションで、Oracle Identity FederationがOracle Identity Federationユーザー・セッションの参照に使用するOracle Identity Federationのセッション識別子。これにより、エンジンとOracle Identity Federationは、同じ識別子を共有してユーザー・セッションを参照できます。(String、oracle.security.fed.sessionidで識別)
後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするセッションIDをエンジンに渡します。

注意:

- プラグインは、認証フローの一環としてプラグインに渡されたデータ(すなわちHttpServletRequestオブジェクトに設定されている属性)をOracle Identity Federationサーバーに提供する必要があります。

- プラグインは、HttpServletRequestオブジェクトに設定されているすべての属性(oracle.security.fed.authn.authnmech、oracle.security.fed.authn.refidおよびoracle.security.fed.authn.engineid属性を除く)を変更できます。

12.3.2 プラグイン用のOracle Identity Federationの構成

認証フローの後にユーザーを後処理プラグインに転送するようにOracle Identity Federationを構成するには、次のプロパティを設定します。

- Webコンテキスト・プロパティを作成または設定します。これは、カスタムJSPページまたはサーブレットが置かれているWebコンテキストを参照します。このプロパティは、Oracle Identity Federation構成のserverconfigグループにあります。serverconfigのauthncontext文字列プロパティを設定します(デフォルトは、指定なし)。

- 相対パス・プロパティを設定します。これは、カスタムJSPページまたはサーブレットが置かれているWebコンテキスト内のパスを参照します。serverconfigのauthnpath文字列プロパティを設定します(デフォルトは、/user/loginsso)。

Oracle Identity Federation構成内でこれらのプロパティを設定するには、WLSTコマンドを使用します。

たとえば、すべての認証エンジンの後に後処理プラグインを呼び出すように構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境で次のコマンドを使用します。

setConfigProperty('serverconfig', 'authncontext', '/rootcontext', 'string')

setConfigProperty('serverconfig', 'authnpath', '/relativepath', 'string')

12.3.3 後処理カスタム・アクションの例

この項では、ローカル認証操作の最後にユーザーがOracle Identity Federationにリダイレクトされる前に、すべての組込み認証エンジンにより呼び出される単純な後処理プラグインを示します。このプラグインはブラウザにより提示されたカスタムCookieにアクセスし、そこからデータを抽出し、アサーションを作成する操作中に使用できるようにそのデータをOracle Identity Federationセッション属性として設定します。

Oracle Identity Federationは次の場合に、ローカル認証操作中に認証エンジンによって設定されるセッション属性をサポートします。

- Oracle Identity FederationがIdPとして動作している場合

- 認証エンジン・フローがいくつかの属性をattr1およびattr2と呼ばれるセッション属性として設定する場合

- Oracle Identity Federationが特定のサービス・プロバイダ・パートナに対するアサーションの作成時に、attr1およびattr2として参照されるセッション属性を送信するように構成されている場合

この例は、組込み認証エンジンが使用されている場合に、ローカル認証フロー内で後処理プラグインがどのようにセッション属性を設定できるかを示しています。

この例では、プラグインは認証が成功した後、別のコンポーネントによって設定済のカスタムCookieから抽出した次の属性を追加します。

- cookie-language: ユーザーの優先言語を含みます。

- cookie-homepage: ユーザーの優先ホームページを含みます。

12.3.3.1 設定

カスタム・コンポーネントにより、この例で使用するCookieが設定されます。

12.3.3.2 パッケージ化

後処理プラグインは、ルート・コンテキストが/pluginに設定されたWebアプリケーションから構成され、カスタムCookieからデータを抽出し、セッション属性として設定する1つのJSPページcookieextract.jspを含みます。プラグインは、内部転送を使用してユーザーをフェデレーション・サーバーにリダイレクトすることにより、フローを再開します。

12.3.3.3 Oracle Identity Federationの構成

ローカル認証フローの最後にOracle Identity Federationサーバーの前に後処理プラグインを呼び出すようにOracle Identity Federationを構成するには、次の手順を実行します。

1. Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力します。

2. 後処理プラグイン・ページのルート・コンテキストを含むauthncontextプロパティを設定します。

setConfigProperty('serverconfig', 'authncontext', '/plugin', 'string')

3. 後処理プラグイン・ページの相対パスを含むauthnpathプロパティを設定します。

setConfigProperty('serverconfig', 'authnpath', '/cookieextract.jsp', 'string')

4. WLSTスクリプト環境を終了します。

12.3.3.4 cookieextract.jspの実装

JSPは次のようになります。

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

// check if authentication was successful
if (request.getAttribute("oracle.security.fed.authn.authntime") != null)
{
// authentication was successful. Attributes will be added
Map attributes = (Map)request.getAttribute("oracle.security.fed.authn.attributes");
if (attributes == null)
{
attributes = new HashMap();
request.setAttribute("oracle.security.fed.authn.attributes", attributes);
}

// get the cookie
Cookie[] cookies = request.getCookies();
String cookieValue = null;
for(int i = 0; i < cookies.length; i++)
{
Cookie cookie = cookies[i];
if (cookie.getName().equals("customcookie"))
cookieValue = cookie.getValue();
}
if (cookieValue != null && cookieValue.length() > 0)
{
StringTokenizer st = new StringTokenizer(cookieValue, "+");
String language = st.nextToken();
String homepage = st.nextToken();

Set languageValues = new HashSet();
languageValues.add(language);
attributes.put("cookie-language", languageValues);

Set homepageValues = new HashSet();
homepageValues.add(homepage);
attributes.put("cookie-homepage", homepageValues);
}
}

// forward to the OIF server to resume the flow
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/loginsso").forward(request, response);
%>

12.4 SP統合エンジン用の前処理カスタム・アクション

前処理プラグインは、フェデレーションSSO処理を開始するためにOracle Identity Federationサーバーにリダイレクトされるかわりに、SP SSOフローの一環としてSP統合モジュールからユーザーがリダイレクトされるモジュールです。このプラグインにより、SSOフロー前にカスタム・アクションを実行することが可能になります。

前処理プラグインの使用時は、SP統合モジュールは、フェデレーテッドSSO処理に使用される実行時データとともに、ユーザーをプラグインに内部的に転送します。プラグインはカスタム操作を実行し、ユーザーを実行時データともにOracle Identity Federationに転送して、フェデレーションSP SSOフローを再開します。

12.4.1 前処理プラグインの実装

SPエンジンはユーザーをOracle Identity Federationにリダイレクトするときに、HttpServletRequestオブジェクトの属性として、特定のデータをサーバーに渡します。同じデータが前処理プラグインにも提供されます。

プラグインに渡されるデータは次のとおりです。

- フェデレーテッドSSOに使用するIdPを参照する、オプションのプロバイダID。指定されていない場合、Oracle Identity Federationは指定された認証メカニズムにマップされたIdPを使用します。IdPが見つからなかった場合は、Oracle Identity FederationはデフォルトSSO IdPとして構成されているIdPを使用します(String、oracle.security.fed.sp.provideridで識別)。

- フェデレーテッドSSOのトリガーに使用するアフィリエーションを参照する、オプションのフェデレーションID(String、oracle.security.fed.sp.federationidで識別)。

- リポジトリに保存されたデータへの参照などの短い文字列、またはSSO処理の完了後にユーザーがリダイレクトされる保護リソースを指す短いURLを含むリレー状態。(String、oracle.security.fed.sp.relaystateで識別)

- SPエンジンがデフォルトのSPエンジン(Oracle Access Manager、Oracle Single Sign-OnまたはテストSPエンジンのいずれか)である場合に、ユーザーがアクセスしようとしていた保護リソース。(oracle.security.fed.sp.returnurlで識別)

- SSOフローを開始したSPエンジンの識別子(String、oracle.security.fed.sp.engineidで識別)

- Oracle Identity Federationが認証エンジンを使用してユーザーをローカルに認証すべきか、またはユーザーを認証用にIdPにリダイレクトすることによりフェデレーテッドSSOを開始すべきかを示す、オプションのフラグ(Boolean、oracle.security.fed.sp.localauthnで識別され、デフォルトはfalse)

- Oracle Identity Federationに格納されている構成を使用すべきか、またはSPエンジンによって渡された、IdP以外の情報に基づいてSSOのみを開始すべきか(Boolean、oracle.security.fed.sp.usedefaultで識別)。指定されていない場合、trueとみなされます。

- ユーザーが認証済の場合にもユーザーをチャレンジするようにSPがIdPに指示すべきか(Boolean、oracle.security.fed.sp.forceauthnで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理中に、フェデレーション・レコードがまだ存在しない場合はレコードを作成することをSPがIdPに対して許可すべきか(Boolean、oracle.security.fed.sp.allowfedcreationで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理中にユーザーと対話しないようにSPがIdPに指示すべきか(Boolean、oracle.security.fed.sp.passiveで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- AuthnRequestの送信時に使用するバインディング(String、oracle.security.fed.sp.requestbindingで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。許容される値は、プロトコルに応じて、httpredirect、httpostおよびhttppostsimpleになります。

- アサーションを含むレスポンスの送信時に使用するバインディング(String、oracle.security.fed.sp.responsebindingで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。許容される値は、プロトコルに応じて、artifactまたはhttpostになります。

- 認証中に使用するようにIdPにリクエストする認証コンテキスト比較をSPに対して指定する、オプションの認証メカニズム比較。(String、oracle.security.fed.sp.authnmechcomparisonで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- SSO処理に対してSPがIdPに発行する名前IDフォーマット(String、oracle.security.fed.sp.nameidformatで識別)。usedefaultがtrueであるか指定されていない場合は、このパラメータは無視されます。

- フェデレーションSSO処理中に、IdPに対してリクエストするオプションの属性(たとえばOpenID IdPとの対話時に)。データは、キーとしてStringを、値としてオブジェクトのセットを使用するマップとして渡されます(oracle.security.fed.sp.attributesで識別)。値はオプションですが、キーには属性名が含まれます。

関連項目:
SP統合エンジンにより提供されるデータの詳細は、第10.4.2項「統合モジュールの開発および実装」を参照してください。

注意:

- プラグインは、SPフェデレーテッドSSOフローの一環として渡されたデータ(すなわちHttpServletRequestオブジェクトに設定されている属性)をOracle Identity Federationサーバーに提供する必要があります。

- プラグインは、HttpServletRequestオブジェクトに設定されているすべての属性(oracle.security.fed.sp.engineid属性を除く)を変更できます。

12.4.2 プラグイン用のOracle Identity Federationの構成

SPフェデレーテッドSSOフローの開始時にユーザーを前処理プラグインに転送するようにOracle Identity Federationを構成するには、次のプロパティを設定します。

- Webコンテキスト・プロパティを作成または設定します。これは、カスタムJSPページまたはサーブレットが置かれているWebコンテキストを参照します。このプロパティは、Oracle Identity Federation構成のserverconfigグループにあります。serverconfigのspcontext文字列プロパティを設定します(デフォルトは、指定なし)。

- 相対パス・プロパティを設定します。これは、カスタムJSPページまたはサーブレットが置かれているWebコンテキスト内のパスを参照します。serverconfigのsppath文字列プロパティを設定します(デフォルトは、/sp/startsso)。

Oracle Identity Federation構成内でこれらのプロパティを設定するには、WLSTコマンドを使用します。

たとえば、SSOフローの前に前処理プラグインを呼び出すように構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境で次のコマンドを使用します。

setConfigProperty('serverconfig', 'spcontext', '/rootcontext', 'string')

setConfigProperty('serverconfig', 'sppath', '/relativepath', 'string')

12.4.3 前処理プラグインの例

この例は、フェデレーションSSO処理を開始するためにユーザーがOracle Identity Federationに転送される前に、フェデレーションSSO処理で使用するIdPを判断するために、デフォルトのSPエンジンによって呼び出される単純な前処理プラグインを示します。

この例では、ローカル・ドメインにはOracle Access Managerによって保護されている2つのリソースがあります。

- http://www.domain.com/resource1、使用するIdPはidp1.com

- http://www.domain.com/resource2、使用するIdPはidp2.com

12.4.3.1 設定

Oracle Identity Federation/SPサーバーはOracle Access Managerに統合されています。

12.4.3.2 パッケージ化

前処理プラグインは、ルート・コンテキストが/pluginに設定されたWebアプリケーションから構成され、保護リソースのURLを評価し、使用するIdPを判断する1つのJSPページfedidpeval.jspを含みます。

12.4.3.3 Oracle Identity Federationの構成

フェデレーションSSOフローの最初にOracle Identity Federation処理の前に前処理プラグインを呼び出すようにOracle Access Manager SPエンジンを構成するには、次の手順を実行します。

1. Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力します。

2. 前処理プラグイン・ページのルート・コンテキストを含むspcontextプロパティを設定します。

setConfigProperty('serverconfig', 'spcontext', '/plugin', 'string')

3. 前処理プラグイン・ページの相対パスを含むsppathプロパティを設定します。

setConfigProperty('serverconfig', 'sppath', '/fedusercheck.jsp', 'string')

4. WLSTスクリプト環境を終了します。

fedusercheck.jspの実装

Implementation of fedusercheck.jsp
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

String returnURL = (String) request.getAttribute("oracle.security.fed.sp.returnurl");
String providerid = null;

if (returnURL != null && returnURL.startsWith("http://www.domain.com/resource1"))
{
providerid = "idp1.com";
}
else if (returnURL != null && returnURL.startsWith("http://www.domain.com/resource2"))

{
providerid = "idp2.com";
}

if (providerid != null)
request.setAttribute("oracle.security.fed.sp.providerid", providerid);

// forward to OIF
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/sp/startsso").forward(request, response);
%>

12.5 SP統合エンジン用の後処理カスタム・アクション

後処理プラグインは、フェデレーテッドSSO処理の一環として、ユーザーがリダイレクトされるモジュールです。このプラグインにより、処理の完了後にカスタム・アクションを実行することが可能になります。

プラグインの使用時には、Oracle Identity FederationはユーザーをSPエンジンにリダイレクトしません。かわりに、ユーザーをプラグインに内部的に転送し、SSO処理で生成されたデータを渡します。カスタム・アクションの実行後、プラグインはフェデレーション・サーバーによって提供された元のデータとともに、認証フローを再開するように、ユーザーを適切なSPエンジンに転送します。

12.5.1 後処理プラグインの実装

Oracle Identity FederationはフェデレーテッドSSOフローの最後にユーザーをSPエンジンにリダイレクトするときに、HttpServletRequestオブジェクトの属性として、特定のデータをエンジンに渡します。同じデータが後処理プラグインにも提供されます。

プラグインに渡されるデータは次のとおりです。

- SSO処理が成功したかどうか(Boolean、oracle.security.fed.sp.authnresultで識別)

- ユーザーの識別子(String、oracle.security.fed.sp.useridで識別)。

- 認証時刻(Date、oracle.security.fed.sp.authntimeで識別)

- 認証済セッションの有効期限(Date、oracle.security.fed.sp.expirationtimeで識別)

- ユーザーを識別するために使用する認証メカニズム(String、oracle.security.fed.sp.authnmechで識別)。

- リレー状態(String、oracle.security.fed.sp.relaystateで識別)

- SPエンジンがデフォルトのSPエンジン(Oracle Access Manager、Oracle Single Sign-OnまたはテストSPエンジンのいずれか)である場合に、ユーザーがアクセスしようとしていた保護リソース(oracle.security.fed.sp.returnurlで識別)。

- 名前ID(アサーションの発行者)およびオプションの属性から構成されるアサーションの内容。
アサーションの内容はXMLデータとしては渡されません。つまり、元のアサーションはモジュールには戻されません。かわりに、データは、キーが文字列で、値がオブジェクトのセットであるマップとして渡されます(oracle.security.fed.sp.attributesで識別)。追加のデータは次のように参照されます。

- orafed-nameid-value - 名前ID値

- orafed-nameid-qualifier - 名前ID修飾子

- orafed-nameid-format - 名前IDフォーマット

- orafed-providerid - プロバイダID

- orafed-assertionid - アサーションのID

- orafed-xmlmessage - アサーションを含むオプションのXMLメッセージ

関連項目:
詳細は、第6.13.2項「SSO完了後のSPエンジンへのXMLメッセージの送信」を参照してください。

- SAMLレスポンスの最高ステータス(String、oracle.security.fed.sp.topstatusで識別)

- SAMLレスポンスの低ステータス(存在する場合)(String、oracle.security.fed.sp.lowstatusで識別)

- ステータス・メッセージ(存在する場合)(String、oracle.security.fed.sp.statusmessageで識別)

- SSOアサーションを作成したプロバイダID(String、oracle.security.fed.sp.provideridで識別)

- 前述の情報を処理するSPエンジンの識別子(oracle.security.fed.sp.engineidで識別)

- ユーザー・セッションのOracle Identity Federation識別子。(String、oracle.security.fed.sessionidで識別)
Oracle Identity Federationは、SPエンジンがユーザーにリンクされた状態を維持できるように、ユーザー・セッションのセッションIDを渡します。またOracle Identity Federationは、セッションID値を使用してそのデータを参照できます。後でログアウト・フローが実行される際に、このユーザー・セッションで使用されたデータをエンジンが削除できるように、Oracle Identity FederationはログアウトするsessionIDをエンジンに渡します。

注意:

- プラグインは、SPフェデレーテッドSSOフローの一環として渡されたデータ(すなわちHttpServletRequestオブジェクトに設定されている属性)をSPエンジンに提供する必要があります。

- プラグインは、HttpServletRequestオブジェクトに設定されているすべての属性(oracle.security.fed.sp.engineid属性を除く)を変更できます。

12.5.2 プラグイン用のOracle Identity Federationの構成

SSOフローの最後にSPエンジンではなく後処理プラグインにユーザーを転送するようにOracle Identity Federationを構成するには、次の作業を実行します。

- フローを変更するSPエンジンを指定します。選択可能なエンジンは、Oracle SSO、Oracle Access Manager、テストSPおよびプロキシです。

- 次の2つのプロパティを設定します。

- Webコンテキスト・プロパティを作成または設定します。これは、後処理プラグインのカスタムJSPページまたはサーブレットが置かれているWebコンテキストを参照します。このプロパティは、Oracle Identity Federation構成のspenginesグループにあります。

- 相対パス・プロパティを設定します。これは、カスタムJSPページまたはサーブレットが置かれているWebコンテキスト内のパスを参照します。

表12-2に、各SPエンジンのプロパティの設定方法を示します。

表12-3 後処理プラグインに対するSPエンジンの構成

SPエンジン

Webコンテキスト・プロパティ

相対パス・プロパティ

Oracle Single Sign-On

osso-login-context(デフォルトは、指定なし)

osso-login(デフォルトは、/user/spretosso)

Oracle Access Manager 10g

oam-login-context(デフォルトは、指定なし)

oam-login(デフォルトは、/user/spretoam)

Oracle Access Manager 11g

oam11g-login-context

oam11g-login

テストSP

testsp-login-context(デフォルトは、指定なし)

testsp-login(デフォルトは、/user/testspretsso)

フェデレーションSSOプロキシ

proxy-login-context(デフォルトは、指定なし)

proxy-login(デフォルトは、/user/proxyretsso)

Oracle Identity Federation構成内でこれらのプロパティを設定するには、WLSTコマンドを使用します。

たとえば、フェデレーテッドSSO処理の最後に、Oracle SSO SPエンジンの前に後処理プラグインを呼び出すように構成するには、Oracle Identity FederationインスタンスのWLSTスクリプト環境で次のコマンドを使用します。

setConfigProperty('spengines', 'osso-login-context', '/rootcontext', 'string')

setConfigProperty('spengines', 'osso-login', '/relativepath', 'string')

12.5.3 後処理プラグインの例

この項では、フェデレーテッドSSOの最後にOracle Access Manager SPエンジンの前に、アサーションで参照されているユーザーが実際にアイデンティティ・プロバイダ(IdP)のローカル・ドメインに属していることを確認するために、Oracle Identity Federationによって呼び出される単純な後処理プラグインを示します。

Oracle Identity Federationは、フェデレーション・パートナとして複数のIdPを持つことができます。各IdPは、Oracle Identity Federation SPおよびフェデレーション・サーバーがデプロイされているローカル・ドメインのかわりに、ユーザーを認証します。

典型的なシナリオでは次のことが行われます。

- ユーザーは認証のためにIdPにリダイレクトされます。

- IdPがユーザーのアイデンティティを含むアサーションを作成します。

- Oracle Identity Federation/SPが着信アサーションをローカル・ユーザー・レコードにマップし、ドメイン内に認証済セッションを作成します。

デプロイメントによっては、アサーションで参照されているユーザーがアサーション発行者のドメインに属していることを確認する必要がある場合があります。この場合、ユーザーはプライマリ・アイデンティティ・プロバイダを使用していると、SPドメインのサービスにしかアクセスできないことがあります。

この例では、アサーションの名前IDは電子メール・アドレスに基づいており、アドレス・ドメインは単一のIdPにマップされています。Oracle Identity Federation/SPは、次のIdPを認識しています。

- http://idp.acme.com/fed/idp: このドメインのユーザーの対応する電子メール・アドレスは@acme.comです。

- http://samlidp.foo.com/fed/idp: このドメインのユーザーの対応する電子メール・アドレスは@foo.comです。

- http://fed.bar.com/fed/idp: このドメインのユーザーの対応する電子メール・アドレスは@bar.comです。

この項の内容は次のとおりです。

- 設定

- パッケージ

- Oracle Identity Federationの構成

- fedusercheck.jspの実装

12.5.3.1 設定

Oracle Identity Federation/SPサーバーはOracle Access Managerに統合されています。

12.5.3.2 パッケージ化

後処理プラグインは、ルート・コンテキストが/pluginに設定されたWebアプリケーションから構成され、IdPから受信したアサーション・データを検証する1つのJSPページfedusercheck.jspを含みます。検証が成功すると、プラグインは、Oracle Access Managerセッションを作成し、ユーザーを保護リソースにリダイレクトできるように、内部転送によってユーザーをOracle Access Manager SPエンジンにリダイレクトします。

12.5.3.3 Oracle Identity Federationの構成

フェデレーテッドSSOフローの最後にOracle Access Manager SPエンジンの前に後処理プラグインを呼び出すようにOracle Identity Federationを構成するには、次の手順を実行します。

1. Oracle Identity FederationインスタンスのWLSTスクリプト環境を入力します。

2. 後処理プラグイン・ページのルート・コンテキストを含むoam-login-contextプロパティを設定します。

setConfigProperty('spengines', 'oam11g-login-context', '/plugin', 'string')

3. 後処理プラグイン・ページの相対パスを含むoam-loginプロパティを設定します。

setConfigProperty('spengines', 'oam11g-login', '/fedusercheck.jsp', 'string')

4. WLSTスクリプト環境を終了します。

12.5.3.4 fedusercheck.jspの実装

JSPは次のように実装されます。

<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*, javax.naming.*, javax.naming.directory.*, java.net.*"%>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");

Map attributes = (Map)request.getAttribute("oracle.security.fed.sp.attributes");
String email = (String)attributes.get("orafed-nameid-value");
String providerid = (String)attributes.get("orafed-providerid");

// check that email address is linked to providerid
if ("http://idp.acme.com/fed/idp".equals(providerid))
{
// acme domain
if (!email.endsWith("@acme.com"))
{
throw new Exception("User is invalid: " + email + " does not belong to " + providerid);
}
}
else if ("http://samlidp.foo.com/fed/idp".equals(providerid))
{
// foo domain
if (!email.endsWith("@foo.com"))
{
throw new Exception("User is invalid: " + email + " does not belong to " + providerid);
}
}
else if ("http://fed.bar.com/fed/idp".equals(providerid))
{
// bar domain
if (!email.endsWith("@bar.com"))
{
throw new Exception("User is invalid: " + email + " does not belong to " + providerid);
}
}
else
throw new Exception("Unknown IdP: " + providerid);

// forward to the OAM SP Engine to resume the flow
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/spretoam11g").forward(request, response);
%>

第IV部

付録

この部には次のリファレンス付録が含まれます:

- 付録A「Oracle Identity Federation MBean」

- 付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」

- 付録C「Oracle Identity Federationのトラブルシューティング」

A Oracle Identity Federation MBean

Oracle Identity Federationサーバーの基礎となる構成は複数のMBeanにより管理されています。構成データは次の3つのファイルに格納されています。

- config.xml: サーバー全体の構成が格納されます。

- cot.xml: プロバイダ固有の構成が格納されます。

- datastore.xml: バックエンドのデータ・ストアの構成が格納されます。

この付録では、各MBeanの機能および対応する構成ファイルの要素について説明します。内容は次のとおりです。

- サーバー全体の構成(config.xml)

- プロバイダ固有の構成

- データ・ストアの構成

- Oracle Identity Federationスキーマ

- Oracle Identity Federation MBeanへのプログラムによるアクセス

- Oracle Identity Federation MBean API

A.1 サーバー全体の構成(config.xml)

FederationConfig、Config、PropertiesMapおよびPropertiesList MBeanが、config.xml内でサーバー全体の構成を管理します。

- FederationConfig

- Config

- PropertiesList

- PropertiesMap

A.1.1 FederationConfig

この項では、FederationConfigMXBeanおよび対応するFederationConfig要素について説明します。

- FederationConfigMXBean

- FederationConfig要素

A.1.1.1 FederationConfigMXBean

FederationConfigMXBeanは、Config要素のシーケンスおよび対応するConfigMXBeanのライフサイクルを管理します。次の操作を公開します。

- createEmptyConfig: 名前が指定されると、新しいConfig要素および対応するConfigMXBeanを作成します。名前にはnullまたは空の文字列は指定できません。また、名前はこのFederationConfig内のすべてのConfig要素で一意である必要があります。

- destroyConfig: 名前が指定されると、指定された名前のConfig要素を破棄し、対応するConfigMXBeanを登録解除します。

- hasConfig: 名前が指定されると、このFederationConfigに指定された名前のConfig要素が存在する場合にのみ、trueを返します。

- retrieveConfig: 名前が指定されると、指定されたConfig要素に対応するConfigMXBeanの、MBeanサーバーに登録されているObjectNameを返します。

- retrieveConfigs: 名前が指定されると、すべての子Config要素に対応するConfigMXBeanの、MBeanサーバーに登録されているObjectNameを返します。

A.1.1.2 FederationConfig要素

FederationConfigは、config.xmlファイルの最上位要素です。Config要素のシーケンスを含みます。

<fed:FederationConfig xmlns:fed="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
<fed:Config name="serverconfig">
…
</fed:Config>
<fed:Config name="idpglobal">
…
</fed:Config>
…
</fed:FederationConfig>

A.1.2 Config

この項では、ConfigMXBeanおよび対応するConfig要素について説明します。

- ConfigMXBean

- Config要素

A.1.2.1 ConfigMXBean

ConfigMXBeanは、プロパティの追加、削除および取得を管理し、対応するPropertiesListMXBeanおよびPropertiesMapMXBeanのライフサイクルを管理することにより、その子PropertiesListおよびPropertiesMapを管理します。次の操作を公開します。

- 要素名の取得

- プロパティの取得、追加および削除

- PropertiesListMXBeanのライフサイクル管理

- PropertiesMapMXBeanのライフサイクル管理

要素名の取得

getNameは対応するConfig要素の名前を取得します。

プロパティの取得、追加および削除

プロパティの追加、削除および取得を管理する操作は次のとおりです。

- hasProperty: 名前が指定されると、このConfigに指定された名前のPropertyが存在する場合にのみ、trueを返します。

- putProperty: 名前、値およびタイプが指定されると、指定された名前、値およびタイプでPropertyをこのConfigに追加します。
指定された名前のPropertyがすでに存在する場合は、既存のプロパティの値とタイプを指定された値とタイプに設定します。ただし、指定された名前のPropertyがすでに存在する場合は、指定されたタイプは、既存のプロパティのタイプと一致する必要があります。

どちらの場合も、タイプはstring、booleanまたはlongのいずれかであり、値は指定したタイプのものでなければなりません。名前はnullまたは空の文字列にはできません。

- removeAllProperties: このConfig内のすべてのProperty要素を削除します。

- removeProperty: 名前が指定されると、このConfigから指定された名前のPropertyを削除します。

- retrievePropertyType: 名前が指定されると、このConfig内の指定された名前のPropertyのタイプを返します。

- retrievePropertyValue: 名前が指定されると、このConfig内の指定された名前のPropertyの値を返します。

PropertiesListMXBeanのライフサイクルの管理

PropertiesListMXBeanのライフサイクルを管理する操作は次のとおりです。

- createPropertiesList: 名前が指定されると、新しいPropertiesList要素と対応するPropertiesListMXBeanを作成します。名前にはnullまたは空の文字列は指定できず、また名前はこのConfig内のすべてのPropertiesList要素にわたって一意である必要があります。

- destroyAllPropertiesLists: すべてのPropertiesList要素を破棄し、対応するPropertiesListMXBeanを登録解除します。

- destroyPropertiesList: 名前が指定されると、このConfig内の指定された名前のPropertiesList要素を破棄し、対応するPropertiesListMXBeanを登録解除します。

- hasPropertiesList: 名前が指定されると、このConfigに指定された名前のPropertiesListが存在する場合にのみ、trueを返します。

- retrieveAllPropertiesLists: すべての子PropertiesList要素に対応するPropertiesListMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

- retrievePropertiesList: 名前が指定されると、このConfig内の指定された名前のPropertiesList要素に対応するPropertiesListMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

PropertiesMapMXBeanのライフサイクル管理

PropertiesMapMXBeanのライフサイクルを管理する操作は、子PropertiesListMXBeanのライフサイクルを管理する操作と同じです。

A.1.2.2 Config要素

Config要素は、名前属性と、Property、PropertiesListおよびPropertiesMap子要素を持ちます。

<fed:FederationConfig xmlns:fed="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
<fed:Config name="serverconfig">
…
</fed:Config>
<fed:Config name="idpglobal">
<fed:Property name="providerid" type="string">          http://node1.us.example.com:1234/fed/idp</fed:Property>
<fed:Property name="lib11enabled" type="boolean">true</fed:Property>
<fed:PropertiesList name="sendattributefornameid">
…
</fed:PropertiesList>
<fed:PropertiesMap name="attr-value-filters">
…
</fed:PropertiesMap>
<fed:PropertiesMap name="attr-value-mappings">
…
</fed:PropertiesMap>
</fed:Config>
…
</fed:FederationConfig>

A.1.3 PropertiesList

この項では、PropertiesListMXBeanおよび対応するPropertiesList要素について説明します。

- PropertiesListMXBean

- PropertiesList要素

A.1.3.1 PropertiesListMXBean

PropertiesListMXBeanは、指定された索引にあるプロパティの追加、削除および取得を管理します。次の操作を公開します。

- addProperty(オーバーロード): 値、タイプおよび索引が指定されると、指定された索引で指定された名前とタイプのPropertyを追加します。タイプはstring、booleanまたはlongのいずれかであり、値は指定したタイプのものでなければなりません。

- addProperty(オーバーロード): 値およびタイプが指定されると、このPropertiesListの最後に、指定された名前とタイプのPropertyを追加します。タイプはstring、booleanまたはlongのいずれかであり、値は指定したタイプのものでなければなりません。

- getName: このPropertiesListの名前を返します。

- hasPropertyValue: 値が指定されると、このPropertiesListに指定された値のPropertyが存在する場合にのみ、trueを返します。

- indexOf: 値が指定されると、指定された値を持つ最初のPropertyの索引を、またはこのPropertiesList内のいずれのPropertyもこの値を持たない場合は-1を返します。

- removeAllProperties: このPropertiesListからすべてのProperty要素を削除します。

- removeProperty(オーバーロード): 索引が指定されると、指定された索引にあるProperty要素を削除します。

- removeProperty(オーバーロード): 値が指定されると、指定された値を持つ最初のProperty要素を削除します。

- retrieveAllPropertyValues: このPropertiesList内のProperty要素の値を含むリストを返します。値は、Property要素の表示順と同じ順序で返されます。

- retrieveNumberOfProperties: このPropertiesList内のPropertyの数を返します。

- retrievePropertyType: 索引が指定されると、指定された索引にあるProperty要素のタイプを返します。

- retrievePropertyValue: 索引が指定されると、指定された索引にあるProperty要素の値を返します。

A.1.3.2 PropertiesList要素

PropertiesListは、名前属性と、Property子要素を持ちます。PropertiesList内のProperty要素には名前はありません。

<fed:FederationConfig xmlns:fed="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
<fed:Config name="serverconfig">
…
</fed:Config>
<fed:Config name="idpglobal">
…
</fed:Config>
<fed:Config name="idpliberty11">
<fed:PropertiesList name="ssobindings">
<fed:Property type="string">artifact</fed:Property>
<fed:Property type="string">httppost</fed:Property>
</fed:PropertiesList>
<fed:PropertiesList name="authnreqbindings">
<fed:Property type="string">httppost</fed:Property>
<fed:Property type="string">httpredirect</fed:Property>
</fed:PropertiesList>
…
</fed:Config>
…
</fed:FederationConfig>

A.1.4 PropertiesMap

この項では、PropertiesMapMXBeanおよび対応するPropertiesMap要素について説明します。

- PropertiesMapMXBean

- PropertiesMap要素

A.1.4.1 PropertiesMapMXBean

PropertiesMapMXBeanは、プロパティの追加、削除および取得を管理し、対応するPropertiesListMXBeanおよびPropertiesMapMXBeanのライフサイクルを管理することにより、その子PropertiesListおよびPropertiesMapを管理します。ConfigMXBeanと同じ操作に加え、次の追加の操作を公開します。

retrieveAllPropertyNames: このPropertiesMap内のProperty要素の名前を含むリストを返します。

A.1.4.2 PropertiesMap要素

PropertiesMap要素は、名前属性と、Property、PropertiesListおよびPropertiesMap子要素を持ちます。

<fed:FederationConfig xmlns:fed="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
…
<fed:Config name="fedusersearch">
<fed:PropertiesMap name="fedldap">
<fed:Property name="includesearchattrs" type="boolean">true</fed:Property>
<fed:Property name="defaultsorton"
type="string">orclFedOwnerGUID</fed:Property>
<fed:PropertiesList name="defaultsearch">
…
</fed:PropertiesList>
<fed:PropertiesList name="defaultdisplay">
…
</fed:PropertiesList>
<fed:PropertiesMap name="displaynames">
…
</fed:PropertiesMap>
</fed:PropertiesMap>
…
</fed:Config>
…
</fed:FederationConfig>

A.2 プロバイダ固有の構成

CircleOfTrustおよびPeerProvider MBeanが、cot.xml内でプロバイダ固有の構成をサポートします。

- CircleOfTrust

- PeerProvider

A.2.1 CircleOfTrust

この項では、CircleOfTrustMXBeanおよび対応するCircleOfTrust要素について説明します。

- CircleOfTrustMXBean

- CircleOfTrust要素

A.2.1.1 CircleOfTrustMXBean

CircleOfTrustMXBeanは、PeerProvider要素のシーケンスおよび対応するPeerProviderMXBeanのライフサイクルを管理します。次の操作を公開します。

- createPeerProvider: 説明、プロバイダID、プロバイダ・タイプおよびバージョンが指定されると、新しいPeerProvider要素と対応するPeerProviderMXBeanを作成します。いずれのパラメータもnullにすることはできません。また、プロバイダID、プロバイダ・タイプおよびバージョンに空の文字列は使用できません。指定されたプロバイダIDのPeerProviderがすでに存在する場合は、既存のプロバイダは破棄され、新しいプロバイダで置き換えられます。

- destroyPeerProvider: プロバイダIDが指定されると、このCircleOfTrust内の指定されたプロバイダIDのPeerProvider要素を破棄し、対応するPeerProviderMXBeanをMBeanサーバーから登録解除します。

- hasPeerProvider: プロバイダIDが指定されると、このCircleOfTrustに指定されたプロバイダIDのPeerProvider要素が存在する場合にのみ、trueを返します。

- loadMetadata: ピア・プロバイダのメタデータを含む文字列が指定されると、メタデータ内の情報を使用して新しいPeerProvider要素を作成し、対応するPeerProviderMXBeanを作成します。メタデータをnullにすることはできません。またXMLフォーマットである必要があります。さらに、メタデータはSAML 1.x、SAML 2.0またはLiberty 1.x仕様に準拠する必要があります。

- retrievePeerProvider: プロバイダIDが指定されると、このCircleOfTrust内の指定されたプロバイダIDのPeerProvider要素に対応するPeerProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

- retrievePeerProviders: すべての子PeerProvider要素に対応するPeerProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

A.2.1.2 CircleOfTrust要素

CircleOfTrustは、cot.xmlファイルの最上位要素です。PeerProvider要素のシーケンスを含みます。

<CircleOfTrust xmlns="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
…
<PeerProvider version="SAML1.0" succinctID="Iyrw+aKYfAkLFKROZCE2qe2w0Qk=" providerType="idp" providerID="http://node2.us.example.com:1234/fed/idp" description="">
…
</PeerProvider>
<PeerProvider version="SAML2.0" succinctID="AZh2wC8biWp6uPwO4KgKLY82EQ8=" providerType="idp" providerID="http://node3.us.example.com:1234/fed/idp" description="">
…
</PeerProvider>
…
</CircleOfTrust>

A.2.2 PeerProvider

この項では、PeerProviderMXBeanおよび対応するPeerProvider要素について説明します。

- PeerProviderMXBean

- PeerProvider要素

A.2.2.1 PeerProviderMXBean

PeerProviderMXBeanは、属性およびMetadata要素のテキスト内容の取得と設定を管理します。また、Config要素の対応するConfigMXBeanのライフサイクルも管理します。次の操作を公開します。

- 属性の取得と設定

- 子Metadata要素の取得と設定

- 子ConfigMXBeanのライフサイクル管理

属性の取得と設定

属性を取得および設定する操作は次のとおりです。

- get/setDescription: 説明属性の値を取得または設定します。値としてnullは設定できません。

- getProviderID: プロバイダID属性の値を取得します。

- get/setProviderType: プロバイダ・タイプ属性の値を取得または設定します。値としてnullまたは空の文字列は設定できません。

- get/setVersion: バージョン属性の値を取得または設定します。値としてnullまたは空の文字列は設定できません。

- get/setSuccinctID: 簡潔なID属性の値を取得または設定します。値としてnullまたは空の文字列は設定できません。

子Metadata要素の取得と設定

Metadata要素を取得および設定する操作は次のとおりです。

- retrieveMetadata: このピア・プロバイダのメタデータをXMLフォーマットで含む文字列を返します。

- updateMetadata: メタデータを含む文字列が指定されると、このピア・プロバイダのMetadata要素のテキスト値を指定されたメタデータに設定します。指定されるメタデータは、XMLフォーマットである必要があります。

子ConfigMXBeanのライフサイクル管理

retrieveConfigは、このPeerProvider内のConfig要素に対応するConfigMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

A.2.2.2 PeerProvider要素

PeerProvider要素は次の属性を持ちます。説明、プロバイダID、プロバイダ・タイプ、バージョンおよび簡潔なID。また子要素として、1つのMetadata要素および1つのConfig要素も持ちます。

<CircleOfTrust xmlns="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
…
<PeerProvider version="SAML2.0" succinctID="AZh2wC8biWp6uPwO4KgKLY82EQ8=" providerType="idp" providerID="http://node3.us.example.com:1234/fed/idp" description="">
<Metadata>
…
<Metadata>
<Config name="http://node2.us.example.com:1234/fed/idp">
…
</Config>
</PeerProvider>
…
</CircleOfTrust>

A.3 データ・ストアの構成

DatastoreおよびDiscoveryProvider MBeanが、data-store.xml内でデータ・ストアの構成を管理します。

- Datastore

- DiscoveryProvider

A.3.1 Datastore

この項では、DatastoreMXBeanおよび対応するdatastore要素について説明します。

- DatastoreMXBean

- datastore要素

A.3.1.1 DatastoreMXBean

DatastoreMXBeanはdefaultPackage属性の取得を管理し、また対応するDiscoveryProviderMXBeanを制御することによりDiscoveryProvider要素のシーケンスも管理します。次の操作を公開します。

- getDefaultPackage: defaultPackage属性の値を返します。

- createDiscoveryProvider: タイプ、セッター、クラス名および依存先が指定されると、新しいDiscoveryProvider要素および対応するDiscoveryProviderMXBeanを作成します。いずれのパラメータもnullにすることはできません。また、クラス名およびセッターに空の文字列は使用できません。タイプは、このdatastore内のすべてのDiscoveryProvider要素にわたって一意である必要があります。

- destroyDiscoveryProvider: タイプが指定されると、指定されたタイプのDiscoveryProvider要素を破棄し、対応するDiscoveryProviderMXBeanを登録解除します。

- hasDiscoveryProvider: タイプが指定されると、このdatastoreに指定されたタイプのDiscoveryProviderが存在する場合にのみtrueを返します。

- retrieveDiscoveryProvider: タイプが指定されると、このdatastore内の指定されたタイプのDiscoveryProviderに対応するDiscoveryProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

- retrieveDiscoveryProviders: すべての子DiscoveryProvider要素に対応するDiscoveryProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

A.3.1.2 datastore要素

datastoreは、data-store.xmlファイルの最上位要素です。defaultPackage属性を持ち、DiscoveryProvider要素のシーケンスを含みます。

<datastore xmlns="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd" defaultPackage="oracle.security.fed.jvt.discovery.model">
<DiscoveryProvider type="ActiveIdentityProviderFederationDiscovery">
…
</DiscoveryProvider>
<DiscoveryProvider type="ActiveServiceProviderFederationDiscovery">
…
</DiscoveryProvider>
…
<DiscoveryProvider type="ConfigurationDiscovery">
…
</DiscoveryProvider>
…
</datastore>

A.3.2 DiscoveryProvider

この項では、DiscoveryProviderMXBeanおよび対応するDiscoveryProvider要素について説明します。

- DiscoveryProviderMXBean

- DiscoveryProvider要素

A.3.2.1 DiscoveryProviderMXBean

DiscoveryProviderMXBeanは、属性およびClassName要素のテキスト内容の取得と設定を管理します。また、対応するDiscoveryProviderMXBeanを管理することにより、子Dependencies要素内のDiscoveryProvider要素のシーケンスも管理します。次の操作を含みます。

- 属性の取得と設定の管理

- 子ClassName要素の取得と設定の管理

- 孫DiscoveryProviderMXBeanのライフサイクルの管理

属性の取得と設定

属性を取得および設定する操作は次のとおりです。

- getDependsOn: dependsOn属性の値を返します。

- getSetter: setter属性の値を返します。

- getType: type属性の値を返します。

子ClassName要素の取得と設定

子ClassName要素を取得および設定する操作は次のとおりです。

- changeClassNameTo: クラス名が指定されると、ClassName要素のテキスト値を指定されたクラス名に設定します。クラス名にはnullまたは空の文字列は使用できません。

- retrieveClassName: このDiscoveryProviderのClassName要素のテキスト値を返します。

孫DiscoveryProviderMXBeanのライフサイクルの管理

DiscoveryProviderMXBeanのライフサイクルを管理する操作は次のとおりです。

- createDiscoveryProviderDependency: セッター、クラス名および依存先が指定されると、このDiscoveryProviderの子Dependencies要素内に、指定されたセッター、クラス名、依存先およびこのDiscoveryProviderのタイプで、新しいDiscoveryProvider要素を作成します。また、対応するDiscoveryProviderMXBeanも作成します。

- destroyDiscoveryProviderDependency: セッターが指定されると、このDiscoveryProviderのDependencies内の指定されたセッターのDiscoveryProvider要素を破棄し、対応するMBeanをMBeanサーバーから登録解除します。

- hasDiscoveryProviderDependency: セッターが指定されると、このDiscoveryProviderのDependenciesに指定されたセッターのDiscoveryProviderが存在する場合にのみtrueを返します。

- retrieveDiscoveryProviderDependencies: このDiscoveryProviderのDependencies内のすべての子DiscoveryProvider要素に対応するDiscoveryProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

- retrieveDiscoveryProviderDependency: セッターが指定されると、このDiscoveryProviderのDependencies内の指定されたセッターのDiscoveryProvider要素に対応するDiscoveryProviderMXBeanに対してMBeanサーバーに登録されているObjectNameを返します。

A.3.2.2 DiscoveryProvider要素

DiscoveryProvider要素は、type、setterおよびdependsOn属性を持ちます。また子要素として、1つのClassName要素および1つのDependencies要素も持ちます。Dependencies要素は、DiscoveryProvider要素のシーケンスを含みます。

<datastore xmlns="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd" defaultPackage="oracle.security.fed.jvt.discovery.model">
…
<DiscoveryProvider type="ConfigurationDiscovery">
<ClassName>
oracle.security.fed.jvt.discovery.model.config.ChainingConfigDiscoveryProvider
</ClassName>
<Dependencies>
<DiscoveryProvider type="ConfigurationDiscovery"       setter="setConfigurationDiscovery">
…
</DiscoveryProvider>
…
</Dependencies>
</DiscoveryProvider>
…
</datastore>

A.4 Oracle Identity Federationスキーマ

Oracle Identity Federationスキーマは次のとおりです。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd"
elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns:fed="http://xmlns.oracle.com/fed/schema/oif-11_2.xsd">
<xsd:element name="FederationConfig" type="fed:FederationConfigType"/>
<xsd:complexType name="FederationConfigType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="fed:Config"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Config" type="fed:ConfigType"/>
<xsd:complexType name="ConfigType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="fed:Property"/>
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="fed:PropertiesList"/>
<xsd:element ref="fed:PropertiesMap" maxOccurs="unbounded" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="Property" type="fed:PropertyType"/>
<xsd:complexType name="PropertyType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" use="required" type="xsd:string"/>
<xsd:attribute name="type" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="PropertiesList" type="fed:PropertiesListType"/>
<xsd:complexType name="PropertiesListType">
<xsd:choice>
<xsd:element ref="fed:Property" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="PropertiesMap" type="fed:PropertiesMapType"/>
<xsd:complexType name="PropertiesMapType">
<xsd:choice>
<xsd:element ref="fed:Property" maxOccurs="unbounded" minOccurs="0"/>
<xsd:element ref="fed:PropertiesList" maxOccurs="unbounded"
minOccurs="0"/>
<xsd:element ref="fed:PropertiesMap" maxOccurs="unbounded" minOccurs="0"/>
</xsd:choice>
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="CircleOfTrust" type="fed:CircleOfTrustType"/>
<xsd:complexType name="CircleOfTrustType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="fed:PeerProvider"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="PeerProvider" type="fed:PeerProviderType"/>
<xsd:complexType name="PeerProviderType">
<xsd:sequence>
<xsd:element ref="fed:Metadata"/>
<xsd:element ref="fed:Config"/>
</xsd:sequence>
<xsd:attribute name="providerID" type="xsd:string" use="required"/>
<xsd:attribute name="succinctID" type="xsd:string" use="required"/>
<xsd:attribute name="description" type="xsd:string"/>
<xsd:attribute name="providerType" type="xsd:string" use="required"/>
<xsd:attribute name="version" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:element name="Metadata" type="fed:MetadataType"/>
<xsd:complexType name="MetadataType">
<xsd:simpleContent>
<xsd:extension base="xsd:string"/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="datastore" type="fed:datastoreType"/>
<xsd:complexType name="datastoreType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="fed:DiscoveryProvider"/>
</xsd:sequence>
<xsd:attribute name="defaultPackage" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:element name="DiscoveryProvider" type="fed:DiscoveryProviderType"/>
<xsd:complexType name="DiscoveryProviderType">
<xsd:sequence>
<xsd:element ref="fed:ClassName"/>
<xsd:element ref="fed:Dependencies"/>
</xsd:sequence>
<xsd:attribute name="type" use="required" type="xsd:string"/>
<xsd:attribute name="setter" type="xsd:string"/>
<xsd:attribute name="dependsOn" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="ClassName" type="fed:ClassNameType"/>
<xsd:complexType name="ClassNameType">
<xsd:simpleContent>
<xsd:extension base="xsd:string"/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="Dependencies" type="fed:DependenciesType"/>
<xsd:complexType name="DependenciesType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0"
ref="fed:DiscoveryProvider"/>
</xsd:sequence>
</xsd:complexType>

A.5 Oracle Identity Federation MBeanへのプログラムによるアクセス

この項では、MBeanサーバーにリモート・アクセスし、MBeanに対して操作を実行する方法について説明します。

- MBeanサーバーへのアクセス

- Oracle Identity Federation MBeanへのアクセス

A.5.1 MBeanサーバーへのアクセス

MBeanサーバーにリモートからアクセスする場合には、いくつかの変数を定義する必要があります。

- HOSTNAME: Oracle Identity Federationがデプロイされているマシンのホスト名

- PORT: Oracle Identity Federationのリスニング・ポート

- USERNAMEとPASSWORD: 管理者のユーザー名とパスワード

次のコードは、MBeanサーバーにリモート・アクセスする方法を示しています。このコードを実行するには、クラスパス内に次のライブラリが必要です。

- WL_HOME/server/lib/weblogic.jar

- WL_HOME/server/lib/wljmxclient.jar

- WL_HOME/server/lib/wlclient.jar

MBeanServerConnection mbs = null;
try{
JMXServiceURL url = new JMXServiceURL ("t3", HOSTNAME, Integer.parseInt(PORT), "/jndi/weblogic.management.mbeanservers.runtime");

HashMap<String, Object> env = new HashMap<String,Object>();
env.put(javax.naming.Context.SECURITY_PRINCIPAL, USERNAME);
env.put(javax.naming.Context.SECURITY_CREDENTIALS, PASSWORD);
env.put(javax.management.remote.JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");
JMXConnector connector = JMXConnectorFactory.connect(url, env);
mbs = connector.getMBeanServerConnection();
} catch(Exception e){ //should log exception throw new RuntimeException(e.toString(), e);
}

A.5.2 Oracle Identity Federation MBeanへのアクセス

最上位のOracle Identity Federation構成MBeanは、表A-1に示す、ObjectNameのグローバル/変換バージョンで登録されます(ObjectNameは名前の衝突を防ぐために変換されます)。

表A-1 Oracle Identity Federation構成MBeanのObjectName

構成MBean

ObjectName

FederationConfig

com.oracle.security.fed:type=OIFConfigMBean,name=ServerConfig

CircleOfTrust

com.oracle.security.fed:type=OIFConfigMBean,name=CircleOfTrust

Datastore

com.oracle.security.fed:type=OIFConfigMBean,name=Datastore

MBeanのグローバル/変換ObjectNameの検索には、問合せを使用します。FederationConfigMXBeanのObjectNameを検索するための問合せの例を示します。

String fedObjNameQueryString = "com.oracle.security.fed:name=ServerConfig,type=OIFConfigMBean,*";
Set s = mbs.queryNames(new ObjectName(fedObjNameQueryString), null);
ObjectName FED_CONFIG_OBJ_NAME = null;
if(s != null && !s.isEmpty())
FED_CONFIG_OBJ_NAME = (ObjectName)s.iterator().next();
else{
//should log exception
throw new RuntimeException("Cannot find FedConfigMBean");
}

MBeanServerConnectionのinvokeメソッドを使用して、これらのMBeanを直接操作できます。

関連項目:
http://download.oracle.com/javase/1.5.0/docs/api/index.html?javax/management/MBeanServerConnection.htmlからダウンロードできる、メソッドに関するJavaドキュメント

FederationConfigMXBeanでretrieveConfig操作を呼び出す例を示します。

try
{
ObjectName configObjName =  (ObjectName)mbs.invoke(FED_CONFIG_OBJ_NAME, "retrieveConfig", new Object[]{configName}, new String[]{String.class.getName()});
} catch(Exception e){
//should log exception
throw new RuntimeException(e.toString(), e);
}

ConfigMXBeanのObjectNameの取得後、操作を同様の方法で実行できます。たとえば、新しいプロパティを追加するには、次のようにします。

try
{
String previousValue = (String)mbs.invoke(configObjName, "putProperty", new Object[]{propertyName, propertyValue, propertyType}, new String[]{String.class.getName(), String.class.getName(), String.class.getName()});
} catch(Exception e){
//should log exception
throw new RuntimeException(e.toString(), e);
}

A.6 Oracle Identity Federation MBean API

Oracle Identity Federation MBeans API(javadoc)は次のページから入手できます。

Oracle Fusion Middleware Oracle Identity Federation構成MBean Java APIリファレンス

B Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用

この付録では、Oracle Identity Federationに対するプロキシ・サーバーとしてOracle HTTP Serverを設定する方法を説明します。

- プロキシ・サーバーとしてのOracle HTTP Serverの構成

- Oracle HTTP ServerのSSL構成

B.1 プロキシ・サーバーとしてのOracle HTTP Serverの構成

注意:
環境に対するプロキシ・サーバーの設定の詳細は、アプリケーション・サーバーのドキュメントを参照してください。

Oracle Identity Federationに対するプロキシとしてOracle HTTP Serverを設定するには、次の手順を実行します。

1. IdMインストーラを使用して作成済でない場合は、次のコマンドを使用してOracle HTTP Serverコンポーネントを作成します。

$AS_ISNT/bin/opmnctl createcomponent -componentType OHS -componentName
$OHS_NAME

$AS_ISNTはアプリケーション・サーバー・インスタンスがインストールされているディレクトリ、$OHS_NAMEは新しいOracle HTTP Serverコンポーネントの名前です。

2. $AS_ISNT/config/OHS/$OHS_NAME/moduleconf/oif.confファイルを編集します。ファイルが存在しない場合は、次の内容で作成します。

# References the WebLogic server or Cluster where OIF is running
<Location /fed>
# Standalone install
# WebLogicHost myweblogic.server.com
# WebLogicPort 7499

# Clustered install
# WebLogicCluster w1s1.com:7499,w1s2.com:7499,w1s3.com:7499

SetHandler weblogic-handler
</Location>

1. IdMインストールがスタンドアロン・モードの場合は、Oracle Identity Federationが実行されているWebLogic管理対象サーバーを参照するように、WebLogicHostおよびWebLogicPort変数を非コメント化して設定します。

# Standalone install
WebLogicHost OIF-HOST
WebLogicPort OIF-PORT

2. IdMインストールがクラスタ化モードの場合は、Oracle Identity Federationが実行されているWebLogic管理対象サーバーを参照するように、WebLogicCluster変数を非コメント化して設定します。

# Clustered install
WebLogicCluster OIF-HOST-1:OIF-PORT-1,OIF-HOST-2:OIF-PORT-2,OIF-HOST-3:OIF-PORT-3

3. プロキシとOracle Identity Federationとの間でSSLを使用する場合は、$ORACLE_HOME/ohs/conf/httpd.confファイルを編集します。次のディレクティブを追加します。

WlSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default"

4. このウォレットにあるOracle Identity Federationサーバーの証明書を発行した認証局の証明書をインポートします(まだインポートしていない場合)。詳細は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。

5. プロキシでSSLを使用する場合は、第8.1項「Oracle Identity FederationでのSSLの構成」の指示に従います。mod_wl.confファイルの編集に関する項は省略します。

6. 構成変更を有効にするために、Oracle HTTP Serverを再起動します。

$AS_ISNT/bin/opmnctl restartproc process-type=OHS

7. Fusion Middleware Controlに移動し、Oracle HTTP Serverインスタンスを選択し、「管理」→「ポート構成」に移動して、プロキシのHTTPまたはHTTPSポートを指定します。プロキシは、次を呼び出すことによりテストできます。

HTTP://PROXY-HOST:PROXY_PORT/fed/sp/metadata

8. 外部URLに対してプロキシ・ホストおよびポートを使用するようにOracle Identity Federationを再構成します。Fusion Middleware ControlでOracle Identity Federationインスタンスを選択し、「管理」→「サーバー・プロパティ」→「接続設定」の順に移動します。

- ホスト

- ポート

- SOAPポート

- SSL有効

9. アイデンティティ管理システムとしてOracle Access Managerを使用している場合は、アクセス・システム・コンソールを使用してフェデレーションSSO認証スキームを更新します。コンソールで、「アクセス・システム構成」→「認証管理」の順に移動します。各Oracle Identity Federation認証スキームに対する「チャレンジ・リダイレクト」パラメータを、プロキシ・ホストおよびポートを使用するように変更します。

関連項目:
Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。

10. 必要に応じて、このOracle Identity Federationサーバーを使用してパートナに変更を通知します。SAML 2.0、SAML 1.xまたはLiberty 1.xを使用するパートナは、新しいメタデータをダウンロードする必要があります。WSフェデレーションを使用するパートナは、構成を手動で更新する必要があります。

11. Oracle Identity FederationがOracle Single Sign-Onと統合されている場合は、いくつかの追加手順が必須です。次の項の手順に従います。

- 第3.2.2.2項「Oracle Single Sign-OnとOHSの統合」

- 第3.2.2.3項「Oracle Single Sign-Onを認証エンジンとして使用する場合のOracle Identity Federationの構成」

- 第3.2.2.4項「Oracle Single Sign-On SP統合を使用する場合のOracle Identity Federationの構成」

- 第3.2.2.5項「Oracle Single Sign-Onの構成」

B.2 Oracle HTTP ServerのSSL構成

Oracle HTTP ServerとOracle WebLogic Server間にSSLを構成するには、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware管理者ガイド』

- 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』

C Oracle Identity Federationのトラブルシューティング

この付録では、Oracle Identity Federationを構成して、使用するときに発生する可能性がある一般的な問題と、その解決方法を説明します。

C.1 問題および解決策

この項で取り扱う一般的な問題と解決方法は、次のトピックに分類されています。

- 一般的な問題

- Oracle Identity Federationの構成に関する問題

- Oracle Single Sign-Onのログインに関する問題

- Oracle Access Managerの構成に関する問題

- オペレーティング・システムの構成に関する問題

- 実行時/シングル・サインオンに関する問題

- パフォーマンスの問題

C.1.1 一般的な問題

この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。

- Microsoft Internet Information Serverでの属性共有でX.509証明書のSubjectDNを取得できない

- 署名付きSAML 1.0アサーションによってSSOが失敗することがある

- ネットワーク接続の暗号化

- SSL経由によるLDAPサーバーへの接続

- RDBMSメッセージ・ストアに対するスレッド中断メッセージ

- Oracle Identity FederationがSSL用に構成されている場合にメタデータ・ファイルを使用できない

- 診断ログのParseExceptionメッセージ

C.1.1.1 Microsoft Internet Information Serverでの属性共有でX.509証明書のSubjectDNを取得できない

問題

Oracle Access Manager WebGateエージェントがインストールされている場合、Microsoft Internet Information Servers(IIS)で属性共有機能を使用することはできません。この機能では、認証プラグインがクライアントのX.509証明書からSubjectDNを持つHTTPヘッダーを設定し、認可プラグインがそのヘッダーを取得してSAML属性問合せを開始します。ただし、IIS WebGateによるSSLクライアント証明書の認証方法により、認可プラグインはSubjectDNヘッダーを取得できません。この場合、ユーザーのブラウザで次のエラーが報告されます。

Oracle Access Manager操作エラー<ターゲットURL>に対するユーザー<OblixAnonymousユーザーDN>のアクセスが拒否されました。

また、次のエラー・メッセージがOBACCESS_INSTALL/access/oblix/config/logs/authz_attribute_plugin_log.txtファイルに書き込まれます。

SubjectDN header ObNullString

および

SubjectDNが見つかりません。ローカル・ユーザーを想定して続行を返します

解決方法

この問題を回避するには、Oracle HTTP ServerやSun One Web Serverなどの別のWebサーバーを使用してください。

C.1.1.2 署名付きSAML 1.0アサーションによってSSOが失敗することがある

問題

SAML 1.0ではXML署名仕様の使用方法を完全には規定していないため、SAML 1.0プロトコルの実装の相互運用が難しい場合があります。SP/RPがSAML 1.0 IdPによって作成されたXMLデジタル署名を検証できないことがあります。

したがって、SAML 1.0プロトコルを使用するアイデンティティ・プロバイダとサービス・プロバイダとの間のフェデレーションSSO処理中に、SAMLレスポンスとSAMLアサーションの検証時に、サービス・プロバイダ・サーバー上でエラーが発生することがあります。

解決方法

回避策は、SAML 1.0ではなくSAML 1.1プロトコルを使用することです。(実際、SAML 1.1が改訂された理由の1つは、XML署名の使用方法を改善することでした。)

注意:
SAML 1.x SSOプロファイルでは、署名付アサーションは必須でなく、一般には使用されません。

C.1.1.3 ネットワーク接続の暗号化

デフォルトでは、JDBCはOracle Identity FederationとOracle Databaseの間のネットワーク接続を暗号化しません。オプションで、サイトはOracle Advanced Securityを使用してこれらの接続を暗号化できます。

Oracle Internet Directoryまたはその他のLDAPサーバーを使用してユーザー認証をするためにOracle Identity Federationを構成する場合、サイトはSSLを使用してLDAPサーバーに接続するかどうかを選択できます。SSLを使用しない場合、Oracle Identity FederationとLDAPサーバーの間のネットワーク接続を介して、暗号化されていないパスワードを送信できます。

C.1.1.4 SSL経由によるLDAPサーバーへの接続

Oracle Identity FederationがSSLを使用してLDAPサーバーに接続する必要がある場合(クライアント証明書認証ありまたはなしで)、まずOracle WebLogic Server管理コンソールでアイデンティティ・キーストアと信頼キーストアに必要な証明書を追加する必要があります。この情報は、Oracle Identity Federationが実行されている管理対象サーバーのサーバー/キーストア構成画面で提供されています。

Oracle Identity FederationがSSLを使用してLDAPサーバーに接続する必要がある場合に接続エラーが発生するときは、次のことを確認します。

- 適切なキーストア/証明書を使用するには、Oracle WebLogic Server管理対象サーバーを更新する必要があります。

- Fusion Middleware Controlが実行されている管理サーバーにも正しいキーストア/証明書が必要です。

注意:
Oracle Internet Directoryサーバーを使用している場合は、Oracle Internet Directoryでは認証なしのSSLを無効にすることはできないため、Oracle Internet DirectoryへのSSL接続はサーバー認証なしで作成されることがあることに注意してください。

C.1.1.5 RDBMSメッセージ・ストアでのスレッド中断メッセージ

RDBMSメッセージ・ストアを使用している場合、次のような警告がログに記録されることがあります。

[2009-02-05T11:43:34.322-08:00] [wls_oif1] [WARNING] [FED-12032]
[oracle.security.fed.jvt.discovery.model.profilestate.RDBMSProfileStateDiscove
ryProvider] [tid: Thread-25] [userId: <anonymous>] [ecid:
0000Hx7vp6JESO8nvgZBF119YUEk000004,1:5576] [APP: Oracle Identity Federation#11.1.1.1.0] [arg:
java.lang.InterruptedException: sleep interrupted] InterruptedException:
thread interrupt occurred during sleep() java.lang.InterruptedException:
sleep interrupted

このようなルーチン・メッセージは通常処理の一部であり、単にRDBMSクリーニング・スレッドが停止したことを示しています。

アクションは不要です。

C.1.1.6 Oracle Identity FederationがSSL用に構成されている場合にメタデータ・ファイルを使用できない

問題

Oracle Identity FederationサーバーがプロキシOHSのSSLポートを使用するように構成されている場合、メタデータを開くかロードしようとすると(Fusion Middleware Controlで、フェデレーション・サーバーの「セキュリティおよび信頼」ページの「メタデータ」タブを使用して)、メタデータ・ファイルが壊れているように見えます。

解決策

Oracle Identity FederationがSSL用に構成されている場合、Fusion Middleware Controlコンソールが実行されているOracle WebLogic Server管理サーバーは、Oracle Identity Federationが実行されているOracle WebLogic管理対象サーバーのSSL証明書(または証明書の認証局)を信頼する必要があります。

SSL証明書(またはそのCA)を信頼するようにOracle WebLogic Serverを構成するには、管理サーバーによってSSL接続に使用されているJSSE信頼キーストアに信頼できる証明書エントリとして必要な証明書を追加する必要があります。

参照:

- SSL接続で使用するためにJSSE信頼キーストアを変更する方法に関するOracle WebLogic Serverドキュメント(必要に応じて)。

- keytoolを使用して証明書を信頼できる証明書エントリとしてJSSE信頼キーストアに追加する方法に関するJavaドキュメント。

C.1.1.7 診断ログのParseExceptionメッセージ

インストール後、構成アシスタントでは、MBeansを使用してOracle Identity Federationサーバーへの大量の構成の更新が実行されます。このサーバーへの通知が行われるように、別のタスクによって、構成ファイルが変更されているかどうかが定期的にチェックされます。

この手順の実行中に解析エラーが発生すると、診断ログ・ファイルに次のようなメッセージが記録されます。

$DOMAIN_HOME/servers/wls_oif1/logs/wls_oif1-diagnostic.log
.
[org.xml.sax.SAXParseException: XML document structures must start and end
within the same entity.]
at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalExcept
ion(AbstractUnmarshallerImpl.java:315)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmar
shalException(UnmarshallerImpl.java:514)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(
UnmarshallerImpl.java:215)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(U
nmarshallerImpl.java:184)
at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnm
arshallerImpl.java:137)
at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnm
arshallerImpl.java:184)
at
oracle.as.config.persistence.jaxb.JAXBXmlPersistenceManagerImpl.load(
JAXBXmlPersistenceManagerImpl.java:156)
... 10 more
Caused by: org.xml.sax.SAXParseException: XML document structures must start
and
end within the same entity.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAX
ParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalErro
r(ErrorHandlerWrapper.java:174)
.

Oracle Identity Federationサーバーが稼働している(エラーなしで/fed/idp/metadataにアクセスできる)場合、このメッセージは無害で、サーバーの安定性に影響しません。構成の変更は正常に実行され、すべてのサーバーに変更が通知されます。

C.1.2 Oracle Identity Federationの構成に関する問題

この項では、フェデレーション・サーバーの構成に関する問題について説明します。

- 日本語ロケールにおいてSAML 1.x POSTメソッドを使用したアサーションが失敗する

- 「Failed to find orclfednamevalue」エラー

- Oracle Identity Federationイベントに対する監査ポリシーの構成

- 空のJNDI名メッセージ

- IDPPROVIDEDNAMEIDVALUEでデータベース列が短すぎるエラー

C.1.2.1 日本語ロケールにおいてSAML 1.x POSTメソッドを使用したアサーションが失敗する

問題

日本語ロケールでは、SAML 1.x POSTメソッドを使用したアサーションは次のエラーで失敗します。

エラー: SAMLレスポンスは必要な認可レベルによって署名されていませんでした(RVE013)

この問題の原因は、署名証明書サブジェクトDNおよび署名証明書発行者DN内のOUおよびSTに対応する文字列が変換されることにあります。

解決方法

この問題の回避策は、OU値とST値を同等の英語文字列と置換することです。英語文字列の値は、MyDomain構成内の発行者およびサブジェクトDNから取得できます。

C.1.2.2「Failed to find orclfednamevalue」エラー

問題

フェデレーション・データ・ストアがLDAPサーバーにある状態で、Liberty 1.x / SAML 2.0シングル・サインオン操作を実行するとスキーマ違反エラーが発生します。DOMAIN_HOME/servers/servername/logs/servername_diagnostics.logに、次のエラー・メッセージが表示されます。

javax.naming.directory.SchemaViolationException:
[LDAP: エラー・コード65 -
orclfednamevalueが必須またはオプションの属性リストで見つかりません。]

この問題は、フェデレーション・データ・ストアのLDAPサーバーのスキーマがOracle Identity Federation属性とオブジェクト・クラスを含めるためアップグレードされていない場合に発生します。

解決方法

LDAPスキーマのアップグレードは、インストール時(拡張インストール・モードを使用)またはインストール後に行います。

インストール時のスキーマのアップグレード

インストール時にアップグレードするには、次の手順を実行します。

1. 「拡張インストール」モードを選択します。

2. Oracle Identity Federation拡張フロー属性の選択ページで、フェデレーション・ストアに対するドロップダウンから「LDAP」オプションを選択します。これにより、フェデレーション・レコードが、スキーマのアップグレードが必要なLDAPサーバーに格納されるように指定されます。

3. フェデレーション・データ・ストアに対するLDAP属性の指定ページで、LDAP接続情報を入力します。これで、スキーマがインストール・プロセスの一部としてアップグレードされます。

インストール後のスキーマのアップグレード

インストール後にアップグレードを行うには、Oracle Identity Federationのインストールに、ldapmodifyツールを使用してLDAPサーバーのスキーマをアップグレードできるLDIFファイルが含まれていることを確認してください。

使用するLDIFファイルは、使用するLDAPサーバーの種類によって異なります。

- Oracle Internet Directoryを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldifです。

- Sun One Directory Server 5.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne5.ldifです。

- Sun One Directory Server 6.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne6.ldifです。

- IBM Tivoliを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaTivoli.ldifです。

- Microsoft Active Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldifです。この場合、LDIFファイルを編集して%DOMAIN_DN%という文字列を使用中のActive Directoryのドメインの接尾辞と置き換える必要があります。
たとえば、接尾辞はdc=mydomain,dc=mycompany,dc=comです。

ldapmodifyを使用して、LDAPスキーマをLDIFファイルでアップグレードできます。次に例を示します。

ldapmodify -c -D BIND_DN_USERNAME
-w PASSWORD
-f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif
-h LDAP_HOSTNAME
-p LDAP_PORT -x

C.1.2.3 Oracle Identity Federationイベントに対する監査ポリシーの構成

Fusion Middleware Controlでは、Oracle Identity Federationイベントに対する監査ポリシーの構成時には、EM監査ポリシー・ページにはすべてのOracle Identity Federationイベントに対する成功および失敗イベント・タイプの両方が表示されますが、一般にほとんどのOracle Identity Federation構成変更イベントは設計上、成功ステータスしか持たないことに注意してください。

失敗が監査されるOracle Identity Federationイベントは、次のイベントのみです。

- encryptData

- decryptData

- verifySignature

- createSignature

- localAuthentication

- localLogout

- createActiveUserFederation

- deleteActiveUserFederation

- createUserFederation

- deleteUserFederation

- createUserSession

- deleteUserSession

- incomingMessage

- updateUserFederation

C.1.2.4 空のJNDI名メッセージ

Oracle Enterprise Manager Fusion Middleware Controlを使用して構成データ・ストアをRDBMSに移行する際には、JNDI名を指定する必要があります。操作中にサーバー・ログに次のような警告メッセージが表示されることがあります。

<Warning>
<oracle.security.fed.controller.web.servlet.OIFApplicationLifeCycleCallBack>
<FED-10205> <The JNDI name for RDBMS configuration backend is empty.>
<Warning>
<oracle.security.fed.controller.web.servlet.OIFApplicationLifeCycleCallBack>
<FED-10205> <The JNDI name for RDBMS configuration backend is empty.>

このメッセージは無視してかまいませんが、繰り返し表示される場合は、正しいJNDI名がFusion Middleware Controlで入力されていることを確認してください。

C.1.2.5 IDPPROVIDEDNAMEIDVALUEでデータベース列が短すぎるエラー

問題

セッションおよびメッセージ・データ・ストアにデータベース・ストアを使用するようOracle Identity Federationが構成されている場合、IDPPROVIDEDNAMEIDが200文字より長いと、次のエラーが表示されます。

ORA-12899: value too large for column
"WDO_OIF"."ORAFEDTMPPROVIDERFED"."IDPPROVIDEDNAMEIDVALUE" (actual: 240,
maximum: 200)\n]

解決方法

この問題を回避するには、idpProvidedNameIDValueの列サイズを240に増やすように、ORAFEDTMPPROVIDERFED表を修正します。

C.1.3 Oracle Single Sign-Onのログインに関する問題

この項では、Oracle Identity Federationがサービス・プロバイダ(SP)で、Oracle Single Sign-Onがバックエンドのアイデンティティ・プロバイダ(IdP)として設定されているときに発生する問題を説明します。内容は次のとおりです。

- 正しくないログイン・ページが表示される

- ブックマークしたログイン・ページのエラー

- プロバイダのメタデータのアップロードに使用したファイルを変更できない

C.1.3.1 正しくないログイン・ページが表示される

問題

次の設定では正しくないログイン・ページが表示されます。

1. Oracle Identity Federationがサービス・プロバイダとして構成されています。

2. パートナ・アプリケーションがOracle Identity Federationによって保護されるように構成されています。

3. 保護されたリソースにユーザーがアクセスしようとすると、意図したOracle Identity Federationログイン・ページでなく、Oracle Single Sign-Onログイン・ページが表示されます。

パートナ・アプリケーションがmod_ossoに対して誤って構成されている場合にこの問題が発生し、ユーザーにローカル認証を求めます。

解決方法

パートナ・アプリケーションがmod_ossoに対して正しく構成されていることを確認するために必要な手順の概要を次に示します。

1. Oracle HTTP ServerとOC4J_SECURITYをシャットダウンします。

2. Oracle Application Server InfrastructureディレクトリにあるOracle HTTP Serverの構成ファイル、ORACLE_HOME/Apache/Apache/conf/httpd.confを次のように編集します。

- AddModule(Windows)ディレクティブおよびLoadModule(Windows、Linux)ディレクティブを使用して、サーバーのロード済モジュールにosso_moduleを追加します。

- 仮想ホストを追加して、mod_ossoにより保護される新しいパートナ・アプリケーション・リスナーを作成します。

3. ssoregを実行して、手動でmod_ossoとOracle Single Sign-Onサーバーを構成します。

注意:

- osso_APPLICATION_NAME.confが、仮想ホストの構成で定義した値に一致していることを確認します。

4. Oracle HTTP Server(OHS)とOC4J_SECURITYを再起動します。

C.1.3.2 ブックマークしたログイン・ページのエラー

問題

ブックマークしたログイン・ページを使用してログインしようするとエラーが返されます。これは、ユーザーが次の手順に従った場合に発生します。

- SAML 2.0、LibertyまたはWS-Federationプロトコルを使用してシングル・サインオン(SSO)処理を実行します。

- ログイン・ページで、ページにブックマークします。

- 新しいブラウザ・インスタンスを開いて、ブックマークしたログイン・ページに移動します。有効なユーザー資格証明を使用してログインします。

ユーザーはエラーを受け取り、SSOは失敗します。

解決方法

ログイン・ページはブックマークしないでください。Oracle Identity Federationでは、ブックマークしたログイン・ページの使用はサポートされません。

C.1.3.3 プロバイダのメタデータのアップロードに使用したファイルを変更できない

Firefoxブラウザを使用して、Fusion Middleware Controlの「フェデレーション」ページからプロバイダ・メタデータをアップロードすると、アップロードしたプロバイダ・メタデータ・ファイルはFirefoxを再起動するまで変更できません。

この問題の原因は、FirefoxのLive HTTP Headerアドオンです。このアドオンを無効にしてFirefoxを再起動すると、「フェデレーション」ページでプロバイダのメタデータをアップロードした後に、メタデータ・ファイルを変更できるようになります。

C.1.4 Oracle Access Managerの構成に関する問題

この項では、バックエンドでOracle Access Managerコンポーネントを構成する場合に発生することがある問題について説明します。内容は次のとおりです。

- アクセス・ゲート権限エラー

- 非ASCIIアクセス・ゲートID

- LD_ASSUME_KERNEL値の設定

- 2つのバックエンドに同一のCookieドメインを使用する

- Oracle Access Managerの統合に関する問題

C.1.4.1 アクセス・ゲート権限エラー

問題

次の設定ではアクセス・ゲート構成エラーが返されます。

1. アクセス・サーバーSDKが、アクセス・ゲートの実行権限を持つ特定のユーザーを指定します。

2. Oracle Identity Federationは別のユーザーの権限下にあるLinuxまたはSolarisプラットフォームにインストールされています。

3. アクセス・ゲート構成ページをOracle Access Managerユーザー・データ・ストアに適用すると、次のエラーを受け取ります。

AccessGate configuration failed. Reason: Preparing to connect to Access Server. Please wait. Error: Permission denied.

このエラーの原因はOracle Identity Federationとアクセス・サーバーSDKのインストールが、異なった所有者を持っていることです。

解決方法

Oracle Identity FederationがLinuxまたはSolarisにインストールされている場合は、アクセス・サーバーSDKの各ファイルが、Oracle Identity Federationインストールと同一の所有者およびグループを持っていることを確認します。

C.1.4.2 非ASCIIアクセス・ゲートID

問題

アクセス・ゲートを使用してOracle Access Managerユーザー・データ・ストアの構成を試みると、アクセス・ゲートIDに非ラテン文字(たとえば、「ÆÖ2」)が含まれると、エラーになります。

アクセス・ゲート構成が失敗しました。理由: アクセス・サーバーへの接続を準備しています。お待ちください。クライアント認証が失敗しました。アクセス・ゲートIDを確認してください。

この問題は、アクセス・ゲートIDに、ASCII Latin-1以外の文字(「Ådmïn」)が含まれる場合にも発生します。

解決方法

Oracle Identity Federationアクセス・ゲートではアクセス・ゲートIDにASCII文字のみを使用するようにします。

C.1.4.3 LD_ASSUME_KERNEL値の設定

問題

Fusion Middleware Controlを使用して、Oracle Access ManagerをSP統合モジュールとして使用するために構成しようとすると、Oracle Identity Federationは構成に失敗します。これは、Oracle Access Managerバックエンド・バージョン10.1.4.2以前を使用した操作で発生します。

この問題は、LD_ASSUME_KERNEL環境変数の設定が正しくないことが原因の可能性があります。アクセス・サーバーSDKはLinuxスレッド・モデルをサポートし、Native POSIX Thread Library(NPTL)をサポートしていないため、この変数は2.4.19に設定する必要があります。

たとえば、LD_ASSUME_KERNELが設定されていない場合は、Oracle Identity Federationのログ・ファイルにこのタイプのエラーが記録されます。

com.oblix.access.ObAccessException: Env variable LD_ASSUME_KERNEL not set to 2.4.19.
at com.oblix.access.ObConfig.jni_initialize(Native Method)
...

またブラウザにも、この設定中に(つまり、Fusion Middleware Controlを使用してOracle Access ManagerをSP統合モジュールとして構成しようとすると)エラーが表示されます。

解決方法

Oracle WebLogic Server環境でのLD_ASSUME_KERNELの設定方法について説明している、第3.2.4.3項「SP統合モジュールとしてのOracle Access Managerの統合」を参照してください。

C.1.4.4 2つのバックエンドに同一のCookieドメインを使用する

問題

Oracle Access Managerバックエンドを持つ2つのプロバイダ(たとえばIdPとSP2)が構成に含まれ、両方のインスタンスが同一のCookieドメインを使用している場合、シングル・サインオンを試みるとエラーが発生することがあります。

この問題が発生するのは、複数のOracle Access Managerプロバイダが同一のCookieドメインを使用している場合です。

解決方法

Oracle Access Managerインスタンスが異なるCookieドメインを使用するように変更するか、IdP側で異なるバックエンド(LDAPバックエンドなど)を使用することで、問題を解決できます。

C.1.4.5 Oracle Access Managerの統合に関する問題

問題

Fusion Middleware Controlを使用して、Oracle Access Manager 10gと統合されるようにOracle Identity Federationを構成すると、次のエラーが表示されることがあります。

2009-03-09T21:54:56.354-07:00] [wls_oif1] [INCIDENT_ERROR] [FED-10192] [oracle.security.fed.admin.config.mbeans.OAMConfigUtils] [tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <WLS Kernel>] [ecid: 0000HziivsZ7IBT6uBr2EH19hQcU000017,1:5006] [APP: Oracle Identity Federation#11.1.1.1.0] Oracle Access Server SDK could not be initialized

解決方法

Oracle Access Managerおよびアクセス・サーバーSDKで、Oracle Identity Federationの構成を確認します。

問題

Oracle Identity FederationがOracle Access Manager 10gと統合されている場合にユーザーがOAMに保護されたリソースにアクセスしようとすると、次のエラーが表示されることがあります。

Error:  oracle.security.fed.event.EventException:
com.oblix.access.ObAccessException:
Unprotected resource GET used in an ObAuthenticationScheme or ObUserSession
constructor

解決方法

このエラーが発生した場合は、ホストIDにOracle Identity Federationポート(たとえばポート7499)が指定されていることを確認します。

C.1.5 オペレーティング・システムの構成に関する問題

この項では、Oracle Identity Federationがインストールされたマシンのオペレーティング・システムの構成に関する問題を説明します。

- Linux上のファイル記述子

注意:
この項に示した問題の中には、Oracle Identity Federationサーバーのシステム全体に影響がある問題もあれば、特定のフェデレーション・パートナなど特定のコンポーネントにのみ影響がある問題もあります。

C.1.5.1 Linux上のファイル記述子

問題

Oracle Identity Federationサーバーが断続的にクラッシュし、ログ・ファイルに次のエラー・メッセージが記録されることがあります。

java.net.SocketException: Too many open files

このエラーは、ファイル記述子の上限に達している場合に発生します。

解決方法

/etc/security/limits.conf構成ファイルで指定されているファイル記述子の上限値を増やします。

注意:
ファイル記述子の上限が定義されていない場合、サーバーはデフォルト値の1024を使用します。

この例では、ファイル記述子の上限値が16Kの値に設定されます。

soft nofile 16384
hard nofile 16384

値を変更したら、マシンを再起動します。

C.1.6 実行時/シングル・サインオンに関する問題

この項では、Oracle Identity Federationの使用時に発生することがある、実行時およびシングル・サインオンに関する問題について説明します。

- WS-Federationが保護するリソースに対するブックマークのエラー

- SPが名前IDをローカル・ユーザーにマップできない

C.1.6.1 WS-Federationが保護するリソースに対するブックマークのエラー

問題

ユーザーがWS-Federationにより保護されているリソースにブックマークし、サービス・プロバイダがOracle Single Sign-Onバックエンドを使用している場合、後でブックマークにアクセスしようとすると、ユーザーはエラーを受け取ります。

解決方法

SPがOracle Single Sign-Onバックエンドを使用している場合、WS-Federationにより保護されたリソースへの直接アクセスはサポートされません。このシナリオの場合、リソースにブックマークして、後でアクセスしようとしないでください。

C.1.6.2 SPが名前IDをローカル・ユーザーにマップできない

問題

電子メール・アドレスなどの名前IDフォーマット(mailなどの属性値にマップされた)の使用時に、最初はユーザーはSSOを実行でき、IdPとSPでフェデレーション・レコードが生成されます。

ただし、属性(mail)の値は変更される可能性があります。変更後も、IdPはアサーション内で古い名前ID値(この場合は古い電子メール・アドレス)を送り続けるため、SSOが失敗します。

解決方法

Oracle Identity Federation管理者は、新しい属性値を反映するようにフェデレーション・レコードを更新する必要があります。

C.1.7 パフォーマンスの問題

この項は次のトピックで構成されています。

- LDAPストアの使用時の内部エラー500

C.1.7.1 LDAPストアの使用時の内部エラー500

問題

LDAPベースのデータ・ストアの使用時に、サーバーで大量のログイン・アクティビティが発生していると、ユーザーに対して次のエラーがログに表示されることがあります。

Internal Error: 500

解決策

原因としては、LDAPストアのチューニングが不十分であることが考えられます。LDAPサーバーに対する接続プールが正しくチューニングされていることを確認してください。

用語集

3DES

「Triple Data Encryption Standard (3DES)」を参照してください。

アカウント・ロックアウト

指定の時間内にログオン試行の失敗が繰り返された場合に、セキュリティ・ポリシー設定に基づいてユーザー・アカウントをロックするセキュリティ機能。任意の数のワークステーションからユーザーがアカウントとパスワードの組合せを送信した回数が、Oracle Internet Directoryで許可されている回数を上回ると、Oracle Single Sign-Onでアカウント・ロックアウトが発生します。デフォルトのロックアウト期間は24時間です。

Advanced Encryption Standard (AES)

データ暗号化規格(DES)にかわる暗号標準として意図された対称型暗号アルゴリズム。商用および政府データの暗号化に対する、米国連邦情報処理標準(Federal Information Processing Standard: FIPS)となっています。

アドバンスト対称型レプリケーション

「Oracle Databaseアドバンスト・レプリケーション」を参照してください。

AES

「Advanced Encryption Standard(AES)」を参照してください。

匿名認証

ディレクトリがユーザー名とパスワードの組合せを要求せずにユーザーを認証するプロセス。各匿名ユーザーは、匿名ユーザー用に指定された権限を行使します。

API

「Application Program Interface(API)」を参照してください。

Application Program Interface

コンピュータ・アプリケーションと、下位レベルのサービスや機能(オペレーティング・システム、デバイス・ドライバ、他のソフトウェア・アプリケーションなど)との間のインタフェースとなる一連のソフトウェア・ルーチンおよび開発ツール。プログラマがソフトウェア・アプリケーションを組み立てるための構築ブロックとなります。たとえばLDAP対応のクライアントは、LDAP APIに用意されているプログラム・コールを使用してOracle Internet Directoryの情報にアクセスします。

アプリケーション・サービス・プロバイダ

ソフトウェアベースのサービスやソリューションの管理および配信を、中央のデータ・センターからWide Area Networkを通じて顧客に提供するサード・パーティ・エンティティ。つまり、アプリケーション・サービス・プロバイダは、企業が必要とする情報技術の一部またはすべてをアウトソースする手段となります。

アーティファクト・プロファイル

アサーション全体を送信せず、アーティファクトと呼ばれるアサーションへの簡易参照を使用してデータを伝達する認証メカニズム。このプロファイルは、処理できる文字数が限定されたブラウザに対応します。

ASN.1

Abstract Syntax Notation One (ASN.1)は、情報データの構文定義に使用される国際電気通信連合(International Telecommunication Union: ITU)の表記規約です。ASN.1は、構造化された情報、特に通信メディアを介して送受信される情報の記述に使用されます。ASN.1は、インターネット・プロトコルの仕様において幅広く使用されています。

アサーション

リソースにアクセスしようとしているサブジェクトについての情報を交換するために、セキュリティ・ドメインでプロバイダが使用する文。アイデンティティ・プロバイダとサービス・プロバイダはIDに関するアサーションを交換して認証および認可を決定し、リソースを保護するセキュリティ・ポリシーを有効にします。

非対称型アルゴリズム

暗号化と復号化に異なる鍵を使用する暗号化アルゴリズム。

「公開鍵暗号」も参照してください。

非対称型暗号化

「公開鍵暗号」を参照してください。

認証

エンティティが主張しているIDを、その資格証明に基づいて検証するプロセス。ユーザーの認証は、一般的に、ユーザーが知っているか所持しているもの(パスワードや証明書など)に基づいて行われます。

電子メッセージの認証の場合は、特定のシステム(公開鍵暗号など)を使用して、ファイルまたはメッセージが主張しているとおりの個人または企業から間違いなく発信されたものであることを検証するプロセスや、メッセージの内容に基づくチェックを使用して、メッセージが配信中に変更されていないことを検証するプロセスが含まれます。

認証レベル

アプリケーションに対して特定の認証動作を指定するためのOracle Single Sign-Onのパラメータ。このパラメータと特定の認証プラグインをリンクできます。

認証プラグイン

特定の認証方式の実装。Oracle Single Sign-OnのJavaプラグインは、パスワード認証、デジタル証明書、Windowsシステム固有の認証、およびサード・パーティのアクセス管理に対応しています。

認可

サービスまたはネットワーク・リソースへのアクセスを許可または拒否するプロセス。大半のセキュリティ・システムは、2ステップのプロセスを基本としています。最初のステップは認証で、ここでユーザーは自身のIDを証明します。2番目のステップは認可で、ここでユーザーは、各自のIDと定義済の認可ポリシーに基づいて各種リソースへのアクセスが許可されます。

認可ポリシー

認可ポリシーは、保護されたリソースに対するアクセスを制御する方法を決定します。ポリシーによって、IDおよびオブジェクトが、特定のシステム・モデルに従って一連の権限に対応付けられます。たとえば、認可ポリシーによって、営業部に属しているユーザーのみが販売レポートにアクセスできるなどが規定されます。

Basic認証

大半のブラウザによってサポートされる認証プロトコルです。Webサーバーでは、データ通信に使用するエンコード済のユーザー名とパスワードを使用してエンティティが認証されます。BASE64エンコーディングは自由に利用できるデコーディング・ユーティリティを使用して誰でもデコードできるため、Basic認証は平文認証と呼ばれることもあります。エンコーディングと暗号化は異なる点に注意してください。

基本エンコーディング規則

基本エンコーディング規則(BER)は、ASN.1で規定されたデータ単位をエンコードするための標準規則です。BERは誤ってASN.1とひとまとめにされることがありますが、ASN.1はエンコーディング技術ではなく抽象構文指定のみに適用されます。

BER

「基本エンコーディング規則」を参照してください。

バインディング

ネットワークの場合は、通信エンティティ間の論理的な接続の確立を意味します。

Oracle Internet Directoryでは、バインディングはディレクトリに対して認証を行うプロセスを表します。

SOAPメッセージを、相互に交換する目的で他のプロトコル(基礎となるプロトコル)内またはその上で伝送する、一定の形式に従った規則の組合せもバインディングと呼ばれます。

CA

「認証局」を参照してください。

CA証明書

認証局は、自局が発行するすべての証明書を自身の秘密鍵で署名します。それに対応する認証局の公開鍵は、CA証明書(またはルート証明書)と呼ばれる証明書の中に含まれます。ブラウザは、CAの秘密鍵によって署名されたメッセージを信頼するには、信頼できるルート証明書リストの中にCA証明書を保持している必要があります。

キャッシュ

通常は、コンピュータ内部にある、高速にアクセス可能な一定量のメモリー領域のことを指します。ただし、Webでは、ブラウザがダウンロードしたファイルや画像を格納するコンピュータ上の場所を指すことが多いです。

CBC

「暗号ブロック連鎖」を参照してください。

証明書

公開鍵とその所有者のIDを関連付ける特別な形式のデータ構造。証明書は、認証局(CA)によって発行されます。証明書には、特定のエンティティの名前、シリアル番号、有効期限および公開鍵が含まれます。証明書は、それが本物であることを受信側が検証できるように、発行元のCAによってデジタル署名されます。大半のデジタル証明書は、X.509標準に準拠します。

認証局

デジタル証明書の発行、更新および失効を行う、信頼できる第三者機関。CAの基本的な役割はエンティティの識別情報を保証することで、申請者の検証を登録局(RA)に委任する場合もあります。広く一般に知られている認証局(CA)には、Digital Signature Trust、Thawte、VeriSignなどがあります。

証明連鎖

ユーザー証明書とそれに関連付けられたCA証明書の1つ以上のペアを含む、順序付けられた証明書のリスト。

証明書失効リスト

発行元の認証局(CA)によって失効されたデジタル証明書のリスト。

変更ログ

ディレクトリ・サーバーに加えられた変更を記録するデータベース。

暗号

「暗号化アルゴリズム」を参照してください。

暗号ブロック連鎖

ブロック暗号の操作モードの1つ。CBCでは、初期設定ベクトル(IV)と呼ばれる特定長のベクトル値が使用されます。CBCの最も重要な特性の1つは、連鎖メカニズムによって、特定の暗号文ブロックの復号化が、それよりも前のすべての暗号文ブロックに依存することにあります。結果として、1つ前の暗号文ブロックには、それよりも前のすべてのブロックの全体としての妥当性が含まれることになります。

暗号スイート

Secure Sockets Layer(SSL)において、ネットワークのノード間でメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセット。SSLハンドシェイク時に、2つのノード間で折衝し、メッセージを送受信するときに使用する暗号スイートを確認します。

暗号文

判読可能なデータ(平文)に暗号化アルゴリズムを適用することで、適切な鍵の所有者以外は誰も判読できないデータに変換したもの。

トラスト・サークル

アイデンティティ・プロバイダとサービス・プロバイダのグループ内の信頼関係。このグループ内では、プリンシパルによりプロバイダとの商取引において1つのフェデレーテッドIDおよびシングル・サインオンの使用が認められています。

企業は、Liberty対応のテクノロジおよび企業間の信頼関係を定義する運用協定に基づいて、トラスト・サークルに加入し、フェデレーションまたはアフィリエーションを構成します。

「フェデレーション」、「Liberty Alliance」も参照してください。

申告

エンティティによって行われる宣言内容(名前、ID、鍵、グループなど)。

クライアントSSL証明書

Secure Sockets Layer(SSL)で、サーバーに対するクライアント・マシンの身元確認(クライアント認証)に使用される証明書。

クラスタ

単一のコンピューティング・リソースとして使用される、相互接続された使用可能なすべてのコンピュータの集合。ハードウェア・クラスタによって、高可用性およびスケーラビリティが実現します。

CMP

「Certificate Management Protocol」を参照してください。

CMS

「Cryptographic Message Syntax」を参照してください。

コード署名証明書

Javaプログラム、JavaScriptまたはその他の署名ファイルに署名したエンティティの身元確認に使用される証明書。

コールド・フェイルオーバー・クラスタ

Oracle Application Serverコールド・フェイルオーバー・クラスタは高可用性ソリューションの一種で、この構成でOracle Application Server Infrastructureは通常、共有ストレージ・デバイスを持つ2ノードのハードウェア・クラスタにデプロイされます。ノードがアクティブ(「ホット」に)なるとは、そのノードでInfrastructureが実行されていることを示します。一方、「コールド」とは、ノードでInfrastructureが実行されていないことを意味します。アクティブなノードに障害が発生すると、クラスタウェアによりInfrastructureの動作が、それまで「コールド」だったノードに切り替えられ、そのノード上でInfrastructureが開始されます。

同時実行性

複数のリクエストを同時に処理できる機能。同時実行性メカニズムの例には、スレッドおよびプロセスなどがあります。

機密保護

暗号化では、機密保護(またはプライバシ保護)は、認可されていないエンティティがデータを読み取ることを防止する機能を意味します。通常、これは暗号化によって実現されます。

接続記述子

特別にフォーマットされた、ネットワーク接続のための宛先の記述。接続記述子には、宛先サービスとネットワーク・ルート情報が含まれます。宛先サービスを示すには、そのOracle Databaseに対応するサービス名、あるいはOracleリリース8.0またはバージョン7のデータベースに対応するOracleシステム識別子(SID)を使用します。ネットワーク・ルートは、少なくとも、ネットワーク・アドレスによってリスナーの場所を提供します。

競合

リソースの競合。

コンテキスト接頭辞

ネーミング・コンテキストのルートの識別名(DN)。

CRL

「証明書失効リスト」(CRL)を参照してください。

CRMF

「Certificate Request Message Format」を参照してください。

暗号化アルゴリズム

判読可能なデータ(平文)を判読できないデータ(暗号文)に変換する、またはその逆を行うために定義された一連の処理手順。これらの変換には特別なシークレット情報が必要で、通常、それらは鍵に含まれます。暗号化アルゴリズムには、DES、AES、Blowfish、RSAなどがあります。

Cryptographic Message Syntax

デジタル・メッセージの署名、ダイジェスト、認証および暗号化に使用される構文。RFC 3369で定義されます。

暗号化

情報を判読できない形式に変換することによって保護する処理。情報は、データを判読不能にする鍵を使用して暗号化され、情報が再度必要になったときに復号化されます。「公開鍵暗号」と「対称型暗号」も参照してください。

dads.conf

データベース・アクセス記述子の構成に使用される、Oracle HTTP Serverの構成ファイル。

DAS

「Oracle Delegated Administration Services」を参照してください。(DAS)。

Data Encryption Standard

幅広く使用されている対称型暗号アルゴリズムで、1974年にIBM社によって開発されました。64ビットのデータ・ブロックごとに56ビットの鍵が適用されます。DESおよび3DESは、主にS/MIMEの暗号化アルゴリズムとして使用されます。

データ整合性

受信したメッセージの内容が、送信された元のメッセージの内容から変更されていないことの保証。

「整合性」も参照してください。

データベース・アクセス記述子

特定のOracle Application Serverコンポーネント(Oracle Single Sign-Onスキーマなど)のデータベース接続情報。

復号化

暗号化されたメッセージ(暗号文)の内容を元の判読可能形式(平文)に変換するプロセス。

フェデレーション解除

アイデンティティ・プロバイダまたはサービス・プロバイダからのユーザーのアカウントのリンクを解除する行為。

DER

「高度なエンコーディング規則」を参照してください。

DES

「データ暗号化規格」を参照してください。

DIB

「ディレクトリ情報ベース」を参照してください。

Diffie-Hellman

保護されていないチャネルで通信を行う二者間で共有シークレットを構築することを可能にする公開鍵暗号プロトコル。Diffie-Hellmanは1976年に公開され、使用可能になった最初の公開鍵暗号システムです。

「対称型アルゴリズム」も参照してください。

ダイジェスト

「メッセージ・ダイジェスト」を参照してください。

デジタル証明書

「証明書」を参照してください。

デジタル署名

デジタル署名は、特定のデータ・ブロックに対して2ステップのプロセスを適用して得られます。最初に、データにハッシュ関数を適用して結果を生成します。次に、その結果を署名者の秘密鍵を使用して暗号化します。デジタル署名は、データの整合性、メッセージ認証および否認防止を保証する目的で使用できます。デジタル署名アルゴリズムには、DSA、RSA、ECDSAなどがあります。

Digital Signature Algorithm

Digital Signature Standard (DSS)の一部として使用されている非対称型アルゴリズム。DSAは暗号化には使用できず、デジタル署名にのみ適用されます。このアルゴリズムは1組の大きな数を生成することで、署名者の認証と、結果として添付されているデータの整合性を保証します。DSAは、デジタル署名の生成と検証の両方に使用されます。

「Elliptic Curve Digital Signature Algorithm」も参照してください。

高度なエンコーディング規則

ASN.1オブジェクトをバイト・シーケンスにエンコーディングするための1組の規則。DERは基本エンコーディング規則の特殊な形式です。

識別名

X.500識別名(DN)は、ディレクトリ・ツリー内のノードの一意名です。DNは、ユーザーまたはそれ以外のディレクトリ・エントリの一意名の作成に使用されます。DNは、ルート・ノードから特定のエントリのノードまでのパス上にある、ツリー内の各ノードから選択された属性の連結です。たとえば、LDAP表記規則では、米国のオラクル社に勤務するJohn Smithという名前のユーザーのDNは、cn=John Smith, ou=People, o=Oracle, c=usとなります。

DN

「識別名」を参照してください。

Document Type Definition(DTD)

特定のXMLドキュメントで有効なタグおよびタグの順序に関する制約を指定するドキュメント。DTDは、XMLの親言語であるSimple Generalized Markup Language(SGML)の規則に準拠します。

ドメイン

あるプリンシパルがリソースを利用できるWebサイトおよびアプリケーション。フェデレーテッドID管理(FIM)では、フェデレートされたサイトはアイデンティティ・プロバイダ(ソース・ドメイン)、サービス・プロバイダ(ターゲット・ドメイン)またはその両方として機能します。

DSA

「Digital Signature Algorithm」または「ディレクトリ・システム・エージェント」を参照してください。

DSE

「ディレクトリ固有のエントリ」を参照してください。

DTD

「Document Type Definition」を参照してください。

ECC

「Elliptic Curve Cryptography」を参照してください。

ECDSA

「Elliptic Curve Digital Signature Algorithm」を参照してください。

EJB

「Enterprise JavaBeans(EJB)」を参照してください。

Elliptic Curve Cryptography

RSAにかわる暗号化システムで、大きな数の因数分解よりも楕円曲線の離散対数問題の解決の方が困難であることに基づいています。ECCは、Certicom社によって開発および商品化され、ワイヤレス・デバイスやPCカードのような、制限された演算能力の中で高速が要求される環境に特に適しています。ECCは、同じ鍵サイズ(ビット単位)であれば、RSAよりもセキュリティが高いです(鍵なしでの復号化がより困難です)。

Elliptic Curve Digital Signature Algorithm

Elliptic Curve Digital Signature Algorithm(ECDSA)は、Digital Signature Algorithm(DSA)標準の楕円曲線版です。RSA的な方式と比較したECDSAの利点は、鍵の長さが短く、署名と復号化が高速なことです。たとえば、160ビットのECC鍵は、1024ビットのRSA鍵に相当するセキュリティを実現します。210ビットのECC鍵は2048ビットのRSA鍵に相当し、セキュリティ・レベルが高くなるにつれて、この利点が顕著になります。

暗号化

暗号化アルゴリズムを適用することで、平文を暗号文に変換する処理。

暗号化証明書

電子メッセージ、ファイル、ドキュメントまたはデータ伝送の暗号化や、同じ目的のセッション鍵の交換または確立に使用される公開鍵を含む証明書。

エンドツーエンド・セキュリティ

メッセージレベルのセキュリティによって実現される特性。ビジネス・エンティティ内およびビジネス・エンティティ間の複数のアプリケーションでメッセージが伝送処理されるときに、それらのあらゆる経路でメッセージがセキュアである場合に確立されます。

Enterprise JavaBeans

Sun社によって開発されたJava APIで、複数層からなるクライアント/サーバー・システムのコンポーネント・アーキテクチャを定義します。EJBシステムはJavaで記述されているため、プラットフォームに依存しません。オブジェクト指向に基づき、既存システムへの実装には、再コンパイルや構成をほとんどまたはまったく必要としません。

Enterprise Manager

「Oracle Enterprise Manager」を参照してください。

フェイルオーバー

障害を認識し、リカバリする処理。Oracle Application Serverコールド・フェイルオーバー・クラスタ(Identity Management)で、1つのクラスタ・ノード上で実行されているアプリケーションは、他のクラスタ・ノードに透過的に移行されます。この移行時に、クラスタ上のサービスにアクセスするクライアントは一時的に接続できず、フェイルオーバーが完了した後、再接続する必要がある場合があります。

Federal Information Processing Standards

米国商務省の標準技術局(National Institute of Standards and Technology: NIST)によって発行されている情報処理標準。

フェデレーテッドID管理

自律型ドメイン内でIDと資格をポータブルにするための協定、標準およびテクノロジ。FIMによって、複数ドメイン全体でユーザー認証が認識可能になり、認証済ユーザーが複数ドメイン内の個人向けサービスに参加可能になります。FIMは、複数のアカウント間でID情報をリンク可能にすることで、個人情報が一箇所に格納されることの危険性を回避します。フェデレーテッドIDには、信頼と標準という2つの主要なコンポーネントが必要です。フェデレーテッドID管理の信頼モデルは、トラスト・サークルに基づきます。標準は、Liberty Alliance Projectによって定義されます。

フェデレーション

「アイデンティティ・フェデレーション」を参照してください。

フィルタ

ディレクトリに対するリクエストまたは検索結果として返されるエントリを定義する式。フィルタは、多くの場合、cn=susie smith,o=acme,c=usのような識別名で表されます。

FIM

「フェデレーテッドID管理」を参照してください。

FIPS

「Federal Information Processing Standards」を参照してください。

強制認証

事前設定した時間が経過してもユーザーがアイドル状態のままの場合に、ユーザーの再認証を強制することです。Oracle Single Sign-Onでは、グローバル・ユーザーに関して非アクティブのタイムアウトを指定できます。この機能は、機密情報を扱うアプリケーションを含むシステム向けです。

GET

ログイン資格証明がログインURLの一部として送信される認証方式。

グローバル管理者

ホスティングされた環境では、アプリケーション・サービス・プロバイダなどの1企業が、他の複数の企業にOracleコンポーネントを使用可能にして、その情報を格納します。この種の環境では、グローバル管理者はディレクトリ全体にまたがるアクティビティを実行します。

Global Unique Identifier

エントリがディレクトリに追加されると、システムで生成され、エントリに挿入される識別子。マルチマスター・レプリケート環境で、DNではなくGUIDがエントリを一意に識別します。エントリのGUIDをユーザーが変更することはできません。

グローバル・ユーザーの非アクティビティ・タイムアウト

事前設定した時間が経過してもユーザーがアイドル状態のままの場合に、ユーザーを強制的に再認証する、Oracle Single Sign-Onのオプション機能。グローバル・ユーザーの非アクティブ・タイムアウトは、シングル・サインアウト・セッション・タイムアウトよりもかなり短いです。

グローバルな一意のユーザーID

ユーザーを一意に識別する数値。ユーザー名、パスワード、識別名は変更または追加できますが、グローバルな一意のユーザーIDは常に同じです。

猶予期間ログイン

パスワード期限切れ前の指定された期間内に行われるログイン。

ゲスト・ユーザー

匿名ユーザーではなく、特定のユーザー・エントリも持っていないユーザー。

GUID

「Global Unique Identifier」を参照してください。

ハンドシェイク

2台のコンピュータが通信セッションを開始するために使用するプロトコル。

ハッシュ

アルゴリズムを使用してテキスト文字列から生成される数値。ハッシュ値は、テキスト文字列より大幅に短くなります。ハッシュの数値は、セキュリティの目的とデータに対する高速アクセスの目的で使用します。

「ハッシュ関数」も参照してください。

ハッシュ関数

暗号化におけるハッシュ関数または一方向ハッシュ関数は、特定のデータ・ブロックに適用されるアルゴリズムを意味します。ハッシュ関数の結果は、特定のデータ・ブロックの整合性を保証する目的で使用できます。ハッシュ関数が安全であるためには、既知のデータ・ブロックと既知の結果を与えられたときに、同じ結果となる別のデータ・ブロックを作成することがきわめて困難である必要があります。

Hashed Message Authentication Code

ハッシュ関数の1つの技法で、秘密のハッシュ関数結果の作成に使用されます。HMACは、MD5やSHAなどの既存のハッシュ関数を強化します。また、Transport Layer Security(TLS)で使用されます。

HMAC

「Hashed Message Authentication Code」を参照してください。

HTTP

Hyper Text Transfer Protocolの略称。Webブラウザとサーバー間でドキュメントのリクエストとその内容の転送に使用されるプロトコル。この仕様は、World Wide Web Consortiumによって維持および開発されます。

HTTP Server

「Oracle HTTP Server」を参照してください。

httpd.conf

Oracle HTTP Serverの構成に使用されるファイル。

iASAdmins

Oracle Application Serverのユーザーとグループの管理機能を担当する管理グループ。Oracle Single Sign-On管理者はグループiASAdminsのメンバーです。

アイデンティティ・フェデレーション

あるトラスト・サークル内の1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダでプリンシパルが保持する可能性がある複数のアカウントのリンク。

ユーザーが複数のビジネスに対して持っている、相互に独立している個別のアカウント(ローカルID)をフェデレートすると、2つのエンティティ間にリレーションシップ(任意の数のアイデンティティ・プロバイダとサービス・プロバイダで構成される関連付け)が作成されます。

ID管理

組織でネットワーク・エンティティのセキュリティ・ライフ・サイクル全体を管理するプロセス。通常、組織のアプリケーション・ユーザーの管理を指します。セキュリティ・ライフ・サイクルの手順には、アカウント作成、一時停止、権限変更およびアカウント削除が含まれます。管理されるネットワーク・エンティティには、デバイス、プロセス、アプリケーション、またはネットワーク環境で対話する必要があるその他のすべてのものが含まれます。アイデンティティ管理プロセスで管理されるエンティティには、組織外のユーザー(顧客、取引先、Webサービスなど)も含まれます。

ID管理インフラストラクチャ・データベース

Oracle Single Sign-OnおよびOracle Internet Directoryのデータを含むデータベース。

アイデンティティ・プロバイダ

Oracle Identity Federationでサポートされているアイデンティティ・フェデレーション・プロトコルに定義された3つの主要な役割の1つ。(残りの2つは、サービス・プロバイダおよびプリンシパル。)アイデンティティ・プロバイダは、あるトラスト・サークル内にある一連のIDを管理および認証します。

サービス・プロバイダ(SAMLのリライング・パーティ)は、プリンシパルのIDのアイデンティティ・プロバイダ認証に基づいて、サービスまたは商品をプリンシパルに提供します。

アイデンティティ・プロバイダは、他のサービス・プロバイダと連携するためのビジネス・インセンティブを提供するサービス・プロバイダ。通常、アイデンティティ・プロバイダがプリンシパルのIDを認証およびアサートします。

IdMBridge

IdMBridgeはアサーションのためのユーザー属性をバインドおよび提供し、データの各種の認可ソースとの通信を行います。

インポート・エージェント

Oracle Directory Integration and Provisioning環境において、Oracle Internet Directoryにデータをインポートするエージェント。

インポート・データ・ファイル

Oracle Directory Integration and Provisioning環境において、インポート・エージェントでインポートされたデータを含むファイル。

インフラストラクチャ層

ID管理を行うOracle Application Serverのコンポーネント。すなわち、Oracle Single Sign-On、Oracle Delegated Administration ServicesおよびOracle Internet Directoryです。

継承

オブジェクト・クラスが別のクラスから導出されたときに、導出元のオブジェクト・クラスの多数の特性も導出(継承)されること。同様に、属性のサブタイプも、そのスーパータイプの特性を継承します。

整合性

暗号化では、権限のないエンティティによってデータが変更されていないかどうかを検出する機能を表します。

Internet Directory

「Oracle Internet Directory」を参照してください。

Internet Engineering Task Force

新しいインターネット標準仕様の開発に従事する主要機関。インターネット・アーキテクチャおよびインターネットの円滑な操作の発展に関わるネットワーク設計者、運営者、ベンダーおよび研究者による国際的な団体です。

Internet Message Access Protocol

プロトコルの一種。クライアントは、このプロトコルを使用して、サーバー上の電子メール・メッセージに対するアクセスおよび操作を行います。リモートのメッセージ・フォルダ(メールボックスとも呼ばれる)を、ローカルのメールボックスと機能的に同じ方法で操作できます。

J2EE

「Java 2 Platform, Enterprise Edition」を参照してください。

Java 2 Platform, Enterprise Edition

Java 2 Platform, Enterprise Edition(J2EE)は、Oracleで定義されるエンタープライズ・アプリケーションを開発およびデプロイするための環境です。J2EEプラットフォームは、一連のサービス、Application Program Interface(API)およびプロトコルで構成され、複数層のWebベース・アプリケーションの開発機能を提供します。

JavaServer Pages

JavaServer Pages(JSP)はサーバー側のテクノロジで、Oracleによって開発されたJavaサーブレット・テクノロジに対する拡張です。JSPには、HTMLコードと連携して動作する動的なスクリプティング機能があり、それによってページ・ロジックが静的要素(ページの設計と表示)から分離されます。Javaソース・コードとその拡張機能がHTMLページに埋め込まれることで、HTMLがより機能的になり、データベースへの動的な問合せなどに使用されます。

JSP

「JavaServer Pages」を参照してください。

キー

特定のデータ・ブロックの暗号化と復号化の成功に必要なシークレット情報を含むデータ構造。鍵のサイズが大きくなるにつれて、暗号化されたデータ・ブロックのクラッキングは困難になります。たとえば、256ビットの鍵は128ビットの鍵よりも安全です。

鍵のペア

公開鍵とそれに対応する秘密鍵のペア。

「公開鍵と秘密鍵のペア」も参照してください。

待機時間

指定したディレクトリ操作が完了するまでのクライアントの待機時間。待機時間は、空費時間として定義される場合があります。ネットワーク通信では、待機時間は、ソースから宛先へパケットが移動する時間として定義されます。

LDAP

「Lightweight Directory Access Protocol」を参照してください。

LDAP接続キャッシュ

スループットが向上するように、Oracle Single Sign-OnサーバーはOracle Internet Directoryへの接続をキャッシュして再利用します。

LDAP Data Interchange Format

システム間でディレクトリ・データを交換するためのテキストベースの共通フォーマット。LDAPコマンドライン・ユーティリティに使用する入力ファイルをフォーマットするための一連の規格です。

LDIF

「LDAP Data Interchange Format」を参照してください。

レガシー・アプリケーション

認証をOracle Single Sign-Onサーバーに委任するように変更できない古いアプリケーション。外部アプリケーションと呼ばれることもあります。

Liberty Alliance

Liberty Alliance Projectは、世界中の企業、非営利団体および非政府機関からなるコンソーシアムです。このコンソーシアムは、現在および将来のネットワーク・デバイスをサポートする、フェデレーテッドID管理(FIM)およびIDベースのWebサービスの、オープン規格の開発に従事しています。

Lightweight Directory Access Protocol

ディレクトリ内の情報にアクセスするための1組のプロトコル。LDAPでは、あらゆるタイプのインターネット・アクセスに必要なTCP/IPがサポートされます。また、その設計規則のフレームワークによって、Oracle Internet Directoryなどの業界標準のディレクトリ製品がサポートされます。これはX.500標準の簡易版であるため、LDAPはX.500 Lightと呼ばれることもあります。

ロード・バランサ

複数のサーバー間の接続リクエスト数を平均化するハードウェア・デバイスおよびソフトウェア。BigIP、AlteonまたはLocal Directorはよく使用されるハードウェア・デバイスです。ロード・バランシング・ソフトウェアの例にはOracle Web Cacheがあります。

論理ホスト

Oracle Application Serverのコールド・フェイルオーバー・クラスタ(Identity Management)における、1つ以上のディスク・グループおよびホスト名とIPアドレスのペア。論理ホストは、クラスタ内の物理ホストにマップされます。この物理ホストは、論理ホストのホスト名とIPアドレスを使用します。

MAC

「メッセージ認証コード」を参照してください。

介在者

第三者によるメッセージの不正傍受などのセキュリティ攻撃。第三者、つまり介在者は、メッセージを復号化して再暗号化し(元のメッセージを変更する場合と変更しない場合があります)、元のメッセージの宛先である受信者に転送します。これらの処理はすべて、正当な送受信者が気付かないうちに行われます。この種のセキュリティ攻撃は、認証が行われていない場合にのみ発生します。

マッピング・ルール・ファイル

Oracle Directory Integration and Provisioning環境において、Oracle Internet Directoryの属性と接続ディレクトリの属性のマッピングを指定するファイル。

マスター定義サイト

レプリケーションにおいて、管理者が構成スクリプトを実行するOracle Internet Directoryのデータベース。

マスター・サイト

レプリケーションにおいて、マスター定義サイト(MDS)以外のサイトで、LDAPレプリケーションのメンバーであるサイト。

MD2

Message Digest Twoの略称。メッセージ・ダイジェストを作成するハッシュ関数。このアルゴリズムは入力テキストを処理し、元のメッセージに対して固有でデータの整合性検証に使用できる128ビットのメッセージ・ダイジェストを作成します。MD2は、RSA Security社のRon Rivest氏によって開発され、スマート・カードなどの、メモリーが限られるシステムでの使用が意図されています。

MD4

Message Digest Fourの略称。MD2と類似しますが、ソフトウェアでの高速処理に特化して設計されています。

MD5

Message Digest Fiveの略称。メッセージ・ダイジェストを作成するハッシュ関数。このアルゴリズムは入力テキストを処理し、元のメッセージに対して固有でデータの整合性検証に使用できる128ビットのメッセージ・ダイジェストを作成します。MD5は、MD4の潜在的な脆弱さが報告された後、Ron Rivest氏によって開発されました。MD5はMD4と類似しますが、元のデータに対してより多くの処理を行うため速度は遅くなります。

MDS

「マスター定義サイト」を参照してください。

メッセージ認証

特定のメッセージが特定のエンティティから発信されたことを検証するプロセス。

「認証」も参照してください。

メッセージ認証コード

メッセージ認証コード(MAC)は、特定のデータ・ブロックに対して2ステップのプロセスを適用して得られます。最初に、ハッシュ関数の結果を取得します。次に、その結果を秘密鍵を使用して暗号化します。MACは、特定のデータ・ブロックのソースの認証に使用できます。

メッセージ・ダイジェスト

ハッシュ関数の結果。

「ハッシュ」も参照してください。

メタディレクトリ

企業のすべてのディレクトリ間で情報を共有するディレクトリ・ソリューション。すべてのディレクトリを1つの仮想ディレクトリに統合します。集中的に管理できるため、管理コストを削減できます。ディレクトリ間でデータが同期化されるため、企業内のデータに一貫性があり最新であることが保証されます。

中間層

Oracle HTTP ServerおよびOC4Jで構成されるOracle Single Sign-Onインスタンスの部分。Oracle Single Sign-On中間層は、アイデンティティ管理インフラストラクチャ・データベースとクライアントの間に位置します。

mod_osso

Oracle HTTP Server上のモジュール。これにより、ユーザーが一度Oracle Single Sign-Onサーバーにログインすると、Oracle Single Sign-Onで保護されるアプリケーションがユーザー名とパスワードのかわりにHTTPヘッダーを受け取ることができます。これらのヘッダーの値は、mod_osso Cookieに格納されます。

mod_osso Cookie

HTTP Serverに格納されるユーザー・データ。Cookieはユーザーの認証時に作成されます。同じユーザーが別のアプリケーションをリクエストした場合、Webサーバーはmod_osso Cookieの情報を使用してアプリケーションにユーザーをログインさせます。この機能によって、サーバーのレスポンス時間が短縮されます。

mod_proxy

Oracle HTTP Serverのモジュール。これにより、mod_ossoを使用して、レガシー・アプリケーションまたは外部アプリケーションへのシングル・サインオンを有効にできます。

MTS

「共有サーバー」を参照してください。

マルチマスター・レプリケーション

peer-to-peer またはn-wayレプリケーションとも呼ばれます。同等に機能する複数のサイトが、レプリケートされたデータのグループを管理できるようにするレプリケーションのタイプ。マルチマスター・レプリケーション環境では、各ノードはサプライヤ・ノードであると同時にコンシューマ・ノードであり、各ノードでディレクトリ全体がレプリケートされます。

ネーミング属性

Oracle Delegated Administration ServicesまたはOracle Internet Directory Java APIを使用して作成した新規ユーザー・エントリの相対識別名を構成するために使用する属性。この属性のデフォルト値はcnです。

ニックネーム属性

ディレクトリ全体のユーザーを一意に識別するために使用する属性。この属性のデフォルト値はuidです。アプリケーションでは、この属性を使用して単純なユーザー名が完全な識別名に変換されます。ユーザー・ニックネーム属性を複数値にはできません。つまり、ユーザーは同じ属性名で複数のニックネームを保持することはできません。

否認防止

暗号化において、特定のデジタル署名が特定のエンティティの秘密鍵によって生成されていることと、メッセージが特定の時点で改ざんされずに伝送されていることを保証する機能。

OASIS

Organization for the Advancement of Structured Information Standardsの略称。E-Business標準の開発、策定および採用を推進する国際的な非営利組織です。

オブジェクト・クラス

LDAPにおいて、情報のグループ化に使用されます。通常、オブジェクト・クラスは、従業員やサーバーなどの実社会の事物をモデル化します。各ディレクトリ・エントリは、1つ以上のオブジェクト・クラスに属します。オブジェクト・クラスは、エントリを構成する属性を決定します。オブジェクト・クラスは別のオブジェクト・クラスから導出でき、結果として、他のクラスの特性が継承されます。

OC4J

「Oracle Containers for J2EE」を参照してください。

OCA

「Oracle Certificate Authority」を参照してください。

OCI

「Oracle Call Interface」を参照してください。

OCSP

「Online Certificate Status Protocol」を参照してください。

OEM

「Oracle Enterprise Manager」を参照してください。

OID

「Oracle Internet Directory」を参照してください。

OID制御ユーティリティ

サーバーの起動と停止のコマンドを発行するコマンドライン・ツール。コマンドは、OIDモニターのプロセスによって解析され、実行されます。

OIDデータベース・パスワード・ユーティリティ

Oracle Internet DirectoryがOracle Databaseに接続するときのパスワードの変更に使用されるユーティリティ。

OIDモニター

Oracle Internet Directoryサーバー・プロセスの開始、監視および終了を実行するOracle Internet Directoryのコンポーネント。レプリケーション・サーバー(インストールされている場合)およびOracle Directory Integration and Provisioning Serverの制御も行います。

Online Certificate Status Protocol

デジタル証明書の有効性確認において、広く使用されている2つの方式のうちの1つ。もう1つの方式の証明書失効リスト(CRL)はOCSPよりも古く、使用シナリオによってはOCSPに置き換えられています。OCSP仕様はRFC 2560で規定されています。

一方向関数

一方向への計算は容易ですが、逆の計算(反対方向への計算)は非常に難しい関数。

一方向ハッシュ関数

可変サイズの入力を取得して、固定サイズの出力を作成する一方向関数。

「ハッシュ関数」も参照してください。

Oracle Application Server Single Sign-On

Oracle Single Sign-Onは、ユーザーがアプリケーション(経費報告書、メール、給付金など)に安全にログインできるようにするプログラム・ロジックで構成されます。これらのアプリケーションには、パートナ・アプリケーションと外部アプリケーションの2つの形態があります。どちらの場合も、一度認証されると複数のアプリケーションへのアクセスが可能になります。

Oracle Call Interface

Application Program Interface(API)の1つ。これにより、第三世代言語のネイティブ・プロシージャやファンクション・コールを使用して、Oracle Databaseサーバーにアクセスし、SQL文の実行のすべての段階を制御するアプリケーションを作成できます。

Oracle Certificate Authority

Oracle Application Server環境内で使用される認証局(CA)。OracleAS Certificate AuthorityはOracle Internet Directoryを証明書のストレージ・リポジトリとして使用します。OracleAS Certificate AuthorityのOracle Single Sign-OnおよびOracle Internet Directoryとの統合により、透過的な証明書プロビジョニング・メカニズムが、これらを使用するアプリケーションに提供されます。Oracle Internet Directoryでプロビジョニングされ、Oracle Single Sign-Onで認証されたユーザーは、OracleAS Certificate Authorityへのデジタル証明書のリクエストを選択できます。

Oracle CMS

IETF Cryptographic Message Syntax(CMS)プロトコルのオラクル社による実装。CMSは、セキュアなメッセージ・エンベロープを実現するデータ保護方式を定義します。

Oracle Containers for J2EE

Java 2 Platform, Enterprise Edition(J2EE)用の軽量でスケーラブルなコンテナ。

Oracle Crypto

コア暗号化アルゴリズムを提供するPure Javaライブラリ。

Oracle Databaseアドバンスト・レプリケーション

2つのOracleデータベース間で、データベースの表を継続的に同期化できるOracle Databaseの機能。

Oracle Delegated Administration Service

Oracle Delegated Administration Servicesユニットと呼ばれる個々の事前定義済サービスのセットで、ユーザーのかわりにディレクトリ操作を実行します。Oracle Internet Directoryセルフ・サービス・コンソールによって、Oracle Internet Directoryを使用するOracleアプリケーションおよびサード・パーティ・アプリケーションの両方の管理ソリューションを容易に開発および配布できます。

Oracle Directory Integration and Provisioning

インタフェースとサービスの集合で、Oracle Internet Directoryといくつかの関係するプラグインやコネクタを使用して複数のディレクトリを統合します。外部のユーザー・リポジトリが使用されている場合に、そこからOracle製品への認証を可能にするOracle Internet Directoryの機能です。

Oracle Directory Manager

Oracle Internet Directoryを管理するための、Graphical User Interfaceを備えたJavaベースのツール。

Oracle Enterprise Manager

別個のOracle製品で、Oracle製品群を管理するための統合的、包括的なシステム管理プラットフォームを提供するために、グラフィカル・コンソール、エージェント、共通サービスおよびツール類を統合します。

Oracle HTTP Server

Hypertext Transfer Protocol(HTTP)を使用する、Webトランザクションを処理するソフトウェア。オラクル社では、Apache Groupが開発したHTTPソフトウェアを使用します。

Oracle Identity Management

インフラストラクチャ対応のデプロイメントにより、すべての企業IDと、それらによる企業内の各種アプリケーションへのアクセスを集中的、かつ安全に管理します。

Oracle Internet Directory

分散ユーザーやネットワーク・リソースに関する情報の検索を可能にする、一般的な用途のディレクトリ・サービス。Lightweight Directory Access Protocol (LDAP)バージョン3と、Oracleデータベースの高度なパフォーマンス、スケーラビリティ、耐久性および可用性を組み合せたもの。

Oracle Liberty SDK

Liberty Alliance Project仕様のオラクル社による実装。サード・パーティ製のLiberty準拠アプリケーション間で、フェデレーテッド・シングル・サインオンを可能にします。

Oracle Net Services

Oracleのネットワーク製品ファミリの基礎。Oracle Net Servicesを使用すると、サービスやアプリケーションを異なるコンピュータに配置して通信できます。Oracle Net Servicesの主な機能には、ネットワーク・セッションの確立およびクライアント・アプリケーションとサーバー間のデータ転送があります。Oracle Net Servicesは、ネットワーク上の各コンピュータに配置されます。ネットワーク・セッションの確立後、Oracle Net Servicesはクライアントとサーバーのためのデータ伝達手段として機能します。

Oracle PKI証明書使用

証明書でサポートされるOracleアプリケーション・タイプを定義します。

Oracle PKI SDK

公開鍵インフラストラクチャ(PKI)実装内で必要なセキュリティ・プロトコルのオラクル社による実装。

Oracle SAML

異種システムおよびアプリケーション間でセキュリティ資格証明を、XMLベースのフォーマットで交換するためのフレームワークを提供します。Security Assertions Markup Language(SAML)に関するOASIS仕様に基づきます。

Oracle Security Engine

X.509ベースの証明書管理機能を組み込んだ、Oracle Cryptoの拡張。Oracle Security Engineは、Oracle Cryptoのスーパーセットです。

Oracle S/MIME

Internet Engineering Task Force(IETF)が発行するセキュアな電子メールに関するSecure/Multipurpose Internet Mail Extension(S/MIME)仕様のオラクル社による実装。

Oracle Universal Federation Framework

フェデレーション標準に準拠したクロス・ドメイン・シングル・サインオンのあらゆるマルチベンダー環境への迅速なデプロイを実現する、拡張可能でカスタマイズ可能な統一されたアーキテクチャー。

このフレームワークは、多岐わたるカスタマイズ機能を提供します。詳細は、第III部「Oracle Universal Federation Framework」を参照してください。

Oracle Wallet Manager

セキュリティ管理者が、クライアントとサーバー上での公開鍵セキュリティ資格証明の管理に使用するJavaベースのアプリケーション。

関連資料:『Oracle Database Advanced Security管理者ガイド』

Oracle Web Services Security

既存のセキュリティ・テクノロジを使用して認証および認可を行うためのフレームワークを提供します。Webサービス・セキュリティに関するOASIS仕様に基づきます。

Oracle XML Security

XML暗号化およびXML署名に関するW3C仕様のオラクル社による実装。

OracleAS Portal

ファイル、イメージ、アプリケーションおよびWebサイトを統合するメカニズムを提供する、Oracle Single Sign-Onのパートナ・アプリケーション。外部アプリケーション・ポートレットにより、外部アプリケーションにアクセスできます。

OWM

「Oracle Wallet Manager」を参照してください。

パーティション

一意の重複していないディレクトリ・ネーミング・コンテキスト。1つのディレクトリ・サーバーに格納されています。

パートナ・アプリケーション

認証機能をOracle Single Sign-Onサーバーに委任する、Oracle Application ServerアプリケーションまたはOracle以外のアプリケーション。このようなアプリケーションでは、mod_ossoヘッダーを受け取るので、ユーザーを再認証する必要がありません。

peer-to-peerレプリケーション

マルチマスター・レプリケーションまたはn-wayレプリケーションとも呼ばれます。同等に機能する複数サイトがレプリケートされたデータのグループを管理できるようにするレプリケーションのタイプです。このようなレプリケーション環境では、各ノードはサプライヤ・ノードであると同時にコンシューマ・ノードであり、各ノードでディレクトリ全体がレプリケートされます。

PKCS#1

Public Key Cryptography Standards(PKCS)は、RSA Laboratoriesによって開発された仕様です。PKCS#1は、RSAアルゴリズムをベースとした公開鍵暗号の実装に関する推奨事項を定めています。この内容には、暗号化の基本から、暗号化方式、署名方式、鍵の表記や各種方式の識別に使用するASN.1構文までが含まれます。

PKCS#5

公開鍵暗号規格(PKCS)とは、RSA Laboratoriesによって策定された仕様のこと。PKCS#5は、パスワードをベースとした暗号化の実装に関する推奨事項を定めています。

PKCS#7

公開鍵暗号規格(PKCS)とは、RSA Laboratoriesによって策定された仕様のこと。PKCS #7は、デジタル署名やデジタル・エンベロープなどの、暗号化が適用されるデータに関する汎用構文を定めています。

PKCS#8

公開鍵暗号規格(PKCS)とは、RSA Laboratoriesによって策定された仕様のこと。PKCS #8は、公開鍵と秘密鍵の対応付けアルゴリズムや一連の属性などの、秘密鍵情報に関する構文を定めています。この標準は、暗号化された秘密鍵に関する構文も定めています。

PKCS#10

公開鍵暗号規格(PKCS)とは、RSA Laboratoriesによって策定された仕様のこと。PKCS #10は、公開鍵、名前および一連の可能な属性の証明リクエストに関する構文を定めています。

PKCS#12

公開鍵暗号規格(PKCS)とは、RSA Laboratoriesによって策定された仕様のこと。PKCS #12は、個人の識別情報(秘密鍵、証明書、その他の秘密情報、拡張項目など)の伝送に関する構文を定めています。この標準をサポートするシステム(ブラウザやオペレーティング・システムなど)を使用するユーザーは、主にウォレットと呼ばれるフォーマットによって、1組の個人用ID情報をインポート、エクスポートおよび利用できます。

PKI

「公開鍵インフラストラクチャ」を参照してください。

平文

暗号化によって暗号文に変換される前の判読可能データ、または復号化によって暗号文から変換された結果の判読可能データ。

point-to-pointレプリケーション

ファンアウト・レプリケーションとも呼ばれます。サプライヤがコンシューマに直接レプリケートするレプリケーションのタイプ。コンシューマは1つ以上の他のコンシューマにレプリケートできます。レプリケーションには、完全レプリケーションと部分レプリケーションがあります。

ポリシーの優先順位

Oracle Application Server Certificate Authority(OCA)では、メイン・ポリシー・ページに表示されている順番で、ポリシーが受信リクエストに適用されます。OCAポリシー・プロセッサ・モジュールがポリシーを解析する際、ポリシー・リストの上部にあるポリシーが最初にリクエストに適用されます。ポリシー・リストの下部にあるポリシーは最後に適用され、他のポリシーよりも優先されます。有効なポリシーのみが受信リクエストに適用されます。

policy.properties

シングル・サインオン・サーバーで必要な基本パラメータを含む、Oracle Single Sign-Onのための汎用構成ファイル。Oracle Single Sign-Onの高度な機能(マルチレベル認証など)の構成にも使用されます。

POSIX

Portable Operating System Interface for UNIXの略称。アプリケーションのソース・コードの記述方法を決めることで、異なるオペレーティング・システム間でのアプリケーションの移植を可能にするプログラミング・インタフェース標準のセットです。この標準セットは、Internet Engineering Task Force(IETF)によって開発されています。

POST

ログイン資格証明がログイン・フォーム本体内で送信される認証方式。

条件

Oracle Application Server Certificate Authority(OCA)において、ポリシー述語はポリシーに適用可能な論理式で、着信証明書リクエストまたは失効に対するポリシーの適用方法を制限します。たとえば、次の述語式によって、表示されたポリシーでは、ou=sales,o=acme,c=usが含まれたDNを持つクライアントからのリクエストまたは失効に対して異なる影響を与えることを指定します。

Type=="client" AND DN=="ou=sales,o=acme,c=us"

プライマリ・ノード

Oracle Application Serverコールド・フェイルオーバー・クラスタ(Identity Management)で、指定した時間にアプリケーションが実行されるクラスタ・ノード。

「セカンダリ・ノード」も参照してください。

プリンシパル

プリンシパルは、サービスを使用し、フェデレーテッドIDを取得できるエンティティです。

「フェデレーテッドID管理」も参照してください。

秘密鍵

公開鍵暗号で使用される公開鍵と秘密鍵のペアにおいて、秘密にされる鍵。エンティティは自身の秘密鍵を使用して、公開鍵によって暗号化されたデータを復号化します。また、エンティティは秘密鍵を使用して、デジタル署名を作成することもできます。エンティティの公開鍵で暗号化されたデータと秘密鍵で作成された署名のセキュリティはどちらも、秘密鍵の秘密が守られることを前提とします。

秘密鍵暗号

「対称型暗号」を参照してください。

プロビジョニング・アプリケーション

ユーザーおよびグループの情報がOracle Internet Directoryに一元化される環境にあるアプリケーション。これらのアプリケーションは、一般的にOracle Internet Directory内の該当する情報に対する変更に関心があります。

プロビジョニング

エンタープライズ環境で使用可能なアプリケーションおよびその他のリソースへのアクセスをユーザーに付与するプロセス。

プロビジョニング・エージェント

Oracle固有のプロビジョニング・イベントを外部またはサード・パーティのアプリケーション固有のイベントに変換するアプリケーションまたはプロセス。

プロキシ・サーバー

Webブラウザなどのクライアント・アプリケーションと実サーバーの間にあるサーバー。プロキシ・サーバーは、実サーバーに対するすべてのリクエストを代理受信して、自分がそのリクエストを処理できるかどうかを調べます。処理できない場合、リクエストは実サーバーに転送されます。Oracle Single Sign-Onでは、プロキシは、ロード・バランシング目的とセキュリティ対策用の追加層として使用されます。

「ロード・バランサ」も参照してください。

プロキシ・ユーザー

通常、ファイアウォールなどの中間層を備えた環境で利用されるユーザー。このような環境では、エンド・ユーザーは中間層を認証します。この結果、中間層はエンド・ユーザーにかわってディレクトリにログインします。プロキシ・ユーザーにはアイデンティティを切り替える権限があり、1度ディレクトリにログインすると、エンド・ユーザーのアイデンティティに切り替えます。次に、その特定のエンド・ユーザーに付与されている認可を使用して、エンド・ユーザーのかわりに操作を実行します。

公開鍵

公開鍵暗号で使用される公開鍵と秘密鍵のペアにおいて、一般に公開される鍵。エンティティは、公開鍵を使用してデータを暗号化します。そのデータは、公開鍵の所有者のみが、対応する秘密鍵を使用して復号化できます。公開鍵は、対応する秘密鍵で作成されたデジタル署名の検証にも使用できます。

公開鍵証明書

「証明書」を参照してください。

公開鍵暗号化

公開鍵暗号(非対称型暗号とも呼ばれます)では、公開鍵と秘密鍵の2つの鍵が使用されます。これらの鍵は、鍵のペアと呼ばれます。秘密鍵は秘密にしておく必要がありますが、公開鍵は任意のパーティに送信できます。秘密鍵と公開鍵は、数学的に関連付けられています。秘密鍵によって署名されたメッセージは、対応する公開鍵によって検証できます。同様に、公開鍵によって暗号化されたメッセージは、対応する秘密鍵によって復号化できます。秘密鍵の所有者のみがメッセージを復号化できるため、この方式によって機密保護が保証されます。

公開鍵暗号化

メッセージの送信側が、受信側の公開鍵でメッセージを暗号化するプロセス。配信されたメッセージは、受信側の秘密鍵で復号化されます。

公開鍵インフラストラクチャ

公開鍵と秘密鍵の発行、配布および認証を管理するシステム。通常、PKIは次のコンポーネントによって構成されます。

- 認証局(CA): デジタル証明書の生成、発行、公開および失効に責任を持ちます。

- 登録局(RA): CAに対する証明書リクエストに記載されている情報の検証に責任を持ちます。

- ディレクトリ・サービス: CAによって証明書または証明書失効リスト(CRL)が公開される場所。このシステムに依存する第三者は、ここでそれらを取得できます。

- 依存する第三者: デジタル署名の検証とデータの暗号化に、CAによって発行された証明書と、それに含まれる公開鍵を使用するエンティティ。

公開鍵と秘密鍵のペア

数学的に関連付けられた2つの数字のセット。1つは秘密鍵、もう1つは公開鍵と呼ばれます公開鍵は通常広く使用可能であるのに対して、秘密鍵はその所有者のみ使用可能です。公開鍵で暗号化されたデータは、それに関連付けられた秘密鍵でのみ復号化でき、秘密鍵で暗号化されたデータは、それに関連付けられた公開鍵でのみ復号化できます。公開鍵で暗号化されたデータを、同じ公開鍵で復号化することはできません。

RC2

Rivest Cipher Twoの略称。RSA Security社のRonald Rivest氏によって開発された64ビット・ブロック暗号で、データ暗号化規格(DES)に置き換える目的で設計されました。

RC4

Rivest Cipher Fourの略称。RSA Security社のRonald Rivest氏によって開発されたストリーム暗号。RC4では、最大1024ビットの可変長の鍵を使用できます。RC4は、Secure Sockets Layer(SSL)プロトコルを使用するWebサイト間で通信を暗号化することによってデータ伝送を保護する際に、最も幅広く使用されています。

RDN

「相対識別名」を参照してください。

判読可能データ

暗号化を使用するときに暗号文に変換される前のデータ、または復号化を使用するときに暗号文から変換された結果のデータ。

登録局

登録局(RA)は、認証局(CA)によって証明書が発行される前のユーザーの検証と登録に責任を持ちます。RAは、各申請者に対して、新しく適用される証明書の相対識別値または相対識別名を割り当てます。RAは、証明書の署名および発行は行いません。

リレーショナル・データベース

構造化されたデータの集合。同一の列のセットを持つ1つ以上の行で構成される表にデータが格納されます。Oracleでは、複数の表のデータを容易にリンクできます。このため、Oracleはリレーショナル・データベース管理システム、つまりRDBMSと呼ばれます。Oracleはデータを複数の表に格納し、さらに表間の関係を定義できます。このリンクは両方の表に共通する1つ以上のフィールドに基づいて行われます。

関連識別名

ローカルの、最も細かいレベルのエントリ名。エントリのアドレスを一意に識別するために使用される他の修飾エントリ名は含まれません。たとえば、cn=Smith,o=acme,c=USでは、cn=Smithが相対識別名です。

リモート・マスター・サイト

レプリケート環境におけるマスター定義サイト(MDS)以外のサイトで、Oracle Databaseアドバンスト・レプリケーションのメンバーであるサイト。

レスポンス時間

リクエストの発行からレスポンスの完了までの時間。

RFC

Internet Request For Comments(RFC)文書は、インターネットのプロトコルとポリシーについて記述された定義です。Internet Engineering Task Force(IETF)が、新しい規格の議論、開発および制定を促進します。規格は、RFCという頭字語と参照番号を使用して発表されます。たとえば、電子メールの公式規格はRFC 822です。

ルートCA

ルート認証局(CA)のこと。階層構造を持つ公開鍵インフラストラクチャ(PKI)において、その公開鍵がセキュリティ・ドメイン全体の最も信頼できるデータとして機能するCA。

ルート・ディレクトリ固有のエントリ

ディレクトリに関する操作情報を格納するエントリ。情報は複数の属性に格納されています。

ルートDSE

「ルート・ディレクトリ固有のエントリ」を参照してください。

ルートOracleコンテキスト

Oracle Identity Managementインフラストラクチャでは、ルートOracleコンテキストは、インフラストラクチャのデフォルトアイデンティティ管理レルムへのポインタを含むOracle Internet Directoryのエントリです。単純な名前を指定してアイデンティティ管理レルムの位置を特定する方法の詳細も含まれます。

RSA

公開鍵暗号アルゴリズムの名前で、その考案者(Rivest、ShamirおよびAdelmanの3氏)から名付けられました。RSAアルゴリズムは、最も幅広く使用されている暗号化/認証アルゴリズムで、Netscape社およびMicrosoft社のWebブラウザや、他の多くの製品の一部として組み込まれています。

RSAES-OAEP

RSA Encryption Scheme - Optimal Asymmetric Encryption Padding(RSAES-OAEP)は、RSAアルゴリズムとOAEP方法を組み合せた公開鍵暗号化スキーム。Optimal Asymmetric Encryption Padding(OAEP)は、Mihir BellareおよびPhil Rogawayによって開発されたメッセージのエンコーディング方法です。

S/MIME

「Secure/Multipurpose Internet Mail Extension」を参照してください。

SAML

「Security Assertions Markup Language」を参照してください。

SASL

「Simple Authentication and Security Layer」を参照してください。

スケーラビリティ

使用可能なハードウェア・リソースに応じて、そのハードウェア・リソースによってのみ制限されるシステムの機能。

スキーマ

属性、オブジェクト・クラスおよびそれらに対応する一致規則の集合。

セカンダリ・ノード

Oracle Application Serverコールド・フェイルオーバー・クラスタ(Identity Management)で、フェイルオーバー中にアプリケーションの移動先となるクラスタ・ノード。

「プライマリ・ノード」も参照してください。

秘密鍵

対称型アルゴリズムで使用される鍵。秘密鍵は暗号化と復号化の両方に使用されるため、暗号文を相互に送受信するパーティ間で共有される必要がありますが、許可されていないすべてのエンティティに対しては秘密が維持される必要があります。

秘密鍵暗号

「対称型暗号」を参照してください。

Secure Hash Algorithm

入力に基づいて160ビットのメッセージ・ダイジェストを生成するハッシュ関数アルゴリズム。このアルゴリズムは、Digital Signature Standard(DSS)で使用されています。128、192、256ビットの3通りの鍵サイズを提供するAdvanced Encryption Standard(AES)の導入によって、それらに対応する同レベルのセキュリティを持つハッシュ・アルゴリズムが必要となっています。より新しいSHA-256、SHA-284およびSHA-512ハッシュ・アルゴリズムは、これらの拡張要件を満たしています。

Secure Sockets Layer (SSL)

ネットワーク(インターネットなど)経由での暗号化および認証された通信を実現するために、Netscape社によって設計されたプロトコル。SSLでは、RSA社の公開鍵暗号システムが使用され、デジタル証明書の使用も組み込まれています。SSLでは、セキュアな通信の3要素である機密保護、認証および整合性が実現されます。

SSLが発展したものがTransport Layer Security(TLS)です。TLSとSSLは相互運用できません。ただし、TLSを使用して送信されたメッセージはSSLを扱うクライアントで処理できます。

Secure/Multipurpose Internet Mail Extension

デジタル署名と暗号化を使用したMIMEデータの保護に関するInternet Engineering Task Force(IETF)の標準。

Security Assertions Markup Language

インターネット経由でセキュリティ情報を交換するためのXMLベースのフレームワーク。SAMLは、他の方法では相互運用できない可能性があるアイデンティティ・プロバイダとサービス・プロバイダの間で、認証および認可情報の交換を可能にします。SAML 1.0仕様は2002年にOASISに採用されました。

サーバー証明書

セキュアなWebサーバーを使用してデータを提供する組織のIDが真正であることを証明する証明書。サーバー証明書は、相互に信頼できる認証局(CA)によって発行された公開鍵と秘密鍵のペアに関連付けられる必要があります。サーバー証明書は、ブラウザとWebサーバー間のセキュアな通信に必須です。

サービス・プロバイダ

トラスト・サークルのメンバーによって、Webベースのサービスをユーザーに提供するエンティティとして認識されている組織。サービス・プロバイダは他のサービス・プロバイダおよびアイデンティティ・プロバイダと連携して、関連するユーザーにフェデレーション内の全パーティに対するセキュアなシングル・サインオンを提供するという目標を実現します。

サービス時間

リクエストの開始から、そのリクエストに対するレスポンスの完了までの時間。

セッション鍵

メッセージまたは通信の1セッション期間内でのみ使用される秘密鍵。

SGA

「システム・グローバル領域」を参照してください。

SHA

「Secure Hash Algorithm」を参照してください。

共有サーバー

サポートされるユーザー数を増やすために、多数のユーザー・プロセスがごく少数のサーバー・プロセスを共有できるように構成されたサーバー。共有サーバー構成では、多数のユーザー・プロセスがディスパッチャに接続します。ディスパッチャは、複数の着信ネットワーク・セッション要求を共通キューに送ります。サーバー・プロセスの共有プールの中のアイドル状態の共有サーバー・プロセスは、共通キューから要求を取り出します。つまり、サーバー・プロセスのプールが小さくても、多数のクライアントにサービスを提供できます。専用サーバーと対比される機能です。

兄弟関係

1つ以上の他のエントリと同じ親を持ったエントリ。

Signed Public Key And Challenge

Netscape Navigatorブラウザが証明書のリクエストに使用する固有のプロトコル。

簡易認証

ネットワークでの送信時に暗号化されない識別名とパスワードを使用して、クライアントがサーバーに対して自己認証を行うプロセス。簡易認証オプションでは、クライアントが送信した識別名とパスワードと、ディレクトリに格納されている識別名とパスワードが一致していることをサーバーが検証します。

Simple Authentication and Security Layer

接続ベースのプロトコルに認証サポートを追加する方法。この仕様を使用するために、プロトコルには、ユーザーを識別してサーバーに対して認証を行い、オプションで、以降のプロトコル対話に使用するセキュリティ・レイヤーを規定するコマンドが含まれます。このコマンドには、SASL方式を識別する必須引数があります。

単一鍵ペア・ウォレット

単一のユーザー証明書とその関連する秘密鍵が含まれるPKCS#12形式のウォレット。公開鍵は証明書に埋め込まれています。

シングル・サインオフ

Oracle Single Sign-Onセッションを終了し、すべてのアクティブなパートナ・アプリケーションから同時にログアウトするプロセス。操作しているアプリケーションからログアウトするとシングル・サインオフを実行できます。

シングル・サインオン

一度の認証で、ユーザーが複数のコンピュータ・プラットフォームやアプリケーション・システムにアクセスすることを可能にするプロセスまたはシステム。

Single Sign-On SDK

Oracle Single Sign-Onのパートナ・アプリケーションをシングル・サインオン対応にするレガシーAPI。このSDKは、PL/SQLおよびJava APIと、これらのAPIの実装方法を示すサンプル・コードで構成されます。このSDKは現在は使用不可で、かわりにmod_ossoが使用されます。

Single Sign-On Server

Single Sign-Onアプリケーション(経費報告、電子メール、福利厚生情報など)に安全にログインできるようにするプログラム・ロジック。

SLAPD

スタンドアロンのLDAPデーモン。レプリケーションを除くディレクトリの大半の機能を担当するLDAPディレクトリ・サーバー・サービス。

SOAP

Simple Object Access Protocolの略称。インターネットを介したシステム間でHTTPを使用してメッセージを交換するためのフレームワークを定義する、XMLベースのプロトコル。SOAPメッセージは、メッセージとその処理方法を指定するエンベロープ、アプリケーション定義データ型のインスタンスを表す一連のエンコーディング規則、およびリモート・プロシージャ・コールとレスポンスを表すための規約、という3つの部分から構成されます。

特定管理領域

次の3つの側面を制御する管理領域。

- サブスキーマ管理

- アクセス制御管理

- 共通属性管理

特定管理領域では、この3つの管理側面のうち1つが制御されます。特定管理領域は、自律型管理領域の一部です。

SPKAC

「Signed Public Key And Challenge」を参照してください。

スポンサ・ノード

レプリケーションにおいて、新規ノードに初期データを設定するために使用されるノード。

SSL

「Secure Sockets Layer」を参照してください。

ストリーム暗号

対称型アルゴリズムの一種。ストリーム暗号では、一度に1ビットや1バイトという小さな単位で暗号化され、特定形式のフィードバック・メカニズムの実装によって鍵が絶えず変更されます。RC4はストリーム暗号の例です。

subACLSubentry

アクセス制御リスト情報(ACL)が含まれた特定のタイプのサブエントリ。

サブクラス

別のオブジェクト・クラスから導出されたオブジェクト・クラス。導出元のオブジェクト・クラスは、そのスーパークラスと呼ばれます。

サブエントリ

サブツリー内のエントリ・グループに適用可能な情報が含まれているエントリのタイプ。情報には次の3つのタイプがあります。

- アクセス制御ポリシー・ポイント

- スキーマ規則

- 共通属性

サブエントリは、管理領域のルートのすぐ下に位置しています。

従属CA

従属認証局(CA)のこと。階層構造を持つ公開鍵インフラストラクチャ(PKI)において、その証明書署名鍵が別のCAによって証明され、役割がそのCAによって制約されるCA。

従属参照

エントリのすぐ下から始まるネーミング・コンテキストの参照位置を、ディレクトリ情報ツリー(DIT)内の下位方向に指し示すナレッジ参照してください。

サブスキーマDN

独立したスキーマ定義を持つディレクトリ情報ツリー(DIT)領域のリスト。

subSchemaSubentry

スキーマ情報が含まれた特定のタイプのサブエントリ。

サブツリー

ディレクトリ階層(ディレクトリ情報ツリーとも呼ばれます)の中の1つのセクション。通常、サブツリーは特定のディレクトリ・ノードから始まり、ディレクトリ階層内でそのノードよりも下位にあるすべてのサブディレクトリとオブジェクトが含まれます。

サブタイプ

オプションを持たない同じ属性に対して、1つ以上のオプションを持つ属性。たとえば、American Englishをオプションとして持つcommonName(cn)属性は、そのオプションを持たないcommonName(cn)属性のサブタイプです。逆に、オプションを持たないcommonName(cn)属性は、オプションを持つ同じ属性のスーパータイプです。

成功URL

Oracle Single Sign-Onを使用する場合の、アプリケーションのセッションとセッションCookieを確立するルーチンのURL。

スーパーユーザー

一般的には、ディレクトリ情報へのあらゆるアクセスが可能な特別なディレクトリ管理者。

スーパークラス

別のオブジェクト・クラスの導出元のオブジェクト・クラス。たとえば、オブジェクト・クラスpersonは、オブジェクト・クラスorganizationalPersonのスーパークラスです。後者のorganizationalPersonは、personのサブクラスであり、personに含まれている属性を継承します。

上位参照

ディレクトリ情報ツリー内(DIT)で、参照先のディレクトリ・システム・エージェント(DSA)が保持しているすべてのネーミング・コンテキストより上位のネーミング・コンテキストを保持しているDSAを上位方向に指し示すナレッジ参照してください。

スーパータイプ

1つ以上のオプションを持つ同じ属性に対して、オプションを持たない属性。たとえば、オプションを持たないcommonName(cn)属性は、オプションを持つ同じ属性のスーパータイプです。逆に、American Englishをオプションとして持つcommonName(cn)属性は、そのオプションを持たないcommonName(cn)属性のサブタイプです。

サプライヤ

レプリケーションにおいて、ネーミング・コンテキストのマスター・コピーを保持しているサーバー。マスター・コピーからコンシューマ・サーバーに更新を供給します。

対称型アルゴリズム

暗号化と復号化に同じ鍵を使用する暗号アルゴリズム。主要な対称型(秘密鍵)アルゴリズムには、ストリーム暗号とブロック暗号の2つのタイプがあります。

対称型暗号

共有秘密暗号とも呼ばれる、データの暗号化と復号化に同じ鍵を使用するシステム。対称型暗号の課題は、送信者と受信者が秘密鍵を合意する手段の安全性を保証することです。転送中の秘密鍵が第三者によって傍受された場合、傍受者はその秘密鍵を使用することで、その鍵によって暗号化されたすべてのデータを復号できるようになります。通常、対称型暗号は非対称型暗号よりも高速で、大量のデータ交換が必要なときに使用されることが多いです。対称型暗号のアルゴリズムには、DES、RC2、RC4などがあります。

対称鍵

「秘密鍵」を参照してください。

システム・グローバル領域

共有メモリー構造の1グループ。1つのOracleデータベース・インスタンスに関するデータと制御情報が含まれています。複数のユーザーが同じインスタンスに同時に接続した場合、そのインスタンスのSGA内のデータはユーザー間で共有されます。したがって、SGAは共有グローバル領域と呼ばれることもあります。バックグラウンド・プロセスとメモリー・バッファの組合せは、Oracleインスタンスと呼ばれます。

システム処理属性

ディレクトリ自体の処理に関係する情報を保持する属性。一部の処理情報は、サーバーを制御するためにディレクトリによって指定されます(例: エントリのタイムスタンプ)。アクセス情報などのその他の処理情報は、管理者が定義し、ディレクトリ・プログラムの処理時に、そのプログラムによって使用されます。

思考時間

ユーザーが実際にプロセッサを使用していない時間。

サード・パーティのアクセス管理システム

Oracle以外のシングル・サインオン・システム。Oracle Application Serverアプリケーションへのアクセスを得るために、Oracle Single Sign-Onを使用するように変更できます。

スループット

Oracle Internet Directoryが単位時間ごとに処理するリクエストの数。通常、「処理/秒」(1秒当たりの処理件数)で表されます。

Time Stamp Protocol

タイムスタンプ・プロトコル(TSP)では、RFC 3161に指定されているように、デジタル・メッセージのタイムスタンプに関連するエンティティ、メッセージ書式および転送プロトコルが定義されます。TSPシステムでは、信頼できるサード・パーティのタイムスタンプ局(TSA)がメッセージのタイムスタンプを発行します。

TLS

「Transport Layer Security」を参照してください。

Transport Layer Security

インターネット上の通信プライバシを提供するプロトコル。このプロトコルによって、クライアント/サーバー・アプリケーションは、通信時の盗聴、改ざんまたはメッセージの偽造を防止できます。

Triple Data Encryption Standard (3DES)

Triple Data Encryption Standard(3DES)は、IBM社によって1974年に開発されたデータ暗号化規格(DES)に基づく暗号化アルゴリズムで、1977年に米国の連邦標準として採用されています。3DESでは、64ビットの鍵が3つ使用されます(鍵の長さは全体で192ビットになりますが、実際の鍵長は56ビットです)。データは、第一の鍵で暗号化され、第二の鍵で復号化され、さらに第三の鍵で再度暗号化されます。結果として、3DESは標準的なDESよりも3倍低速になりますが、3倍セキュアになります。

信頼できる証明書

一定の信頼度を有すると認定された第三者の識別情報。信頼できる証明書は、識別情報の内容がそのエンティティと一致していることを検証するときに使用されます。通常、信頼できる証明書は、ユーザー証明書の発行業務を行う、信頼された認証局(CA)によって発行されます。

トラスト・ポイント

「信頼できる証明書」を参照してください。

TSP

「Time Stamp Protocol」を参照してください。

Unicode

汎用キャラクタ・セットのタイプ。16ビットの領域にエンコードされた64Kの文字の集合。既存のほとんどすべてのキャラクタ・セット規格の文字をすべてエンコードします。世界中で使用されているほとんどの記述法を含みます。Unicode はUnicode社によって所有および定義されます。Unicodeは標準的なエンコーディングであり、異なるロケールで値を伝達できることを意味します。しかし、UnicodeとすべてのOracleキャラクタ・セットとの間で、情報の損失なしにラウンドトリップ変換が行われることは保証されません。

UNIX Crypt

UNIX暗号化アルゴリズム。

URI

Uniform Resource Identifierの略称。Web上にある、あらゆるコンテンツ(テキスト・ページ、ビデオ・クリップ、サウンド・クリップ、静止画、動画、プログラムなど)の位置を識別する手段です。最も一般的なURIはWebページ・アドレスで、URLと呼ばれる、URIの特別な形式つまりサブセットで構成されます。

URL

Uniform Resource Locatorの略称。インターネット上にあるアクセス可能なファイルのアドレスです。テキスト・ファイル、HTMLページ、画像ファイル、プログラムなど、HTTPでサポートされるすべてのファイルが対象となります。URLには、リソースへのアクセスに必要なプロトコルの名前、インターネット上の特定のコンピュータを識別するドメイン名、およびコンピュータ上のファイル場所の階層的な記述が含まれます。

URLCトークン

認証されたユーザーの情報をパートナ・アプリケーションに渡すOracle Single Sign-Onのコード。パートナ・アプリケーションでは、この情報を使用してセッションCookieを構築します。

ユーザー名マッピング・モジュール

ユーザー証明書をユーザーのニックネームにマッピングするOracle Single Sign-OnのJavaモジュール。ニックネームは認証モジュールに渡され、認証モジュールがこのニックネームを使用して、ユーザーの証明書をディレクトリから取得します。

ユーザー検索ベース

Oracle Internet Directoryのデフォルトのディレクトリ情報ツリー(DIT)で、すべてのユーザーが配置されるID管理レルムのノード。

UTC

世界中のあらゆる場所で共通の標準時間。以前から現在に至るまで広くグリニッジ時(GMT)または世界時と呼ばれており、UTCは名目上は地球の本初子午線に関する平均太陽時を表します。UTC形式である場合、値の最後にzが示されます(例: 200011281010z)。

UTF-8

文字ごとに連続した1、2、3または4バイトを使用するUnicodeの可変幅8ビット・エンコーディング。0から127の文字(7ビットASCII文字)は1バイトでエンコードされ、128から2047の文字では2バイト、2048から65535の文字では3バイト、65536以上の文字は4バイトを必要とします。このためのOracleキャラクタ・セット名はAL32UTF8(Unicode 3.1規格用)となります。

UTF-16

Unicodeの16ビット・エンコーディング。Latin-1文字は、この規格の最初の256コード・ポイントです。

検証

署名とその署名の意図的な適用先となるデータ・ブロックを作成する目的で、公開鍵とそれに対応する秘密鍵が与えられているときに、特定のデジタル署名が有効であることを確認するプロセス。

仮想ホスト

1つ以上のWebサイトまたはドメインをホスティングする1台の物理的なWebサーバー・マシン、または他のマシンに対するプロキシ(受信リクエストを受け取り、それらを適切なサーバーにルーティングする)としての機能を持つサーバー。

Oracle Single Sign-Onの場合、仮想ホストは、複数のOracle Single Sign-Onサーバー間のロード・バランシングに使用されます。また、これによってセキュリティがさらに強化されます。

仮想ホスト名

Oracle Application Serverコールド・フェイルオーバー・クラスタ(Identity Management)で、特定の仮想IPアドレスに対応するホスト名。

仮想IPアドレス

Oracle Application Serverコールド・フェイルオーバー・クラスタ(Identity Management)では、各物理ノードに独自の物理IPアドレスと物理ホスト名があります。クラスタは、クラスタ内のどの物理ノードにも移動できる動的IPアドレスを使用して、単一のシステム・イメージを示すことができます。これは、仮想IPアドレスと呼ばれます。

待機時間

リクエストの発行からレスポンスの開始までの時間。

ウォレット

個々のエンティティに対するセキュリティ資格証明の格納と管理に使用される抽象的な概念。様々な暗号化サービスで使用できるように、資格証明の格納と取出しを実現します。Wallet Resource Locator (WRL)は、Walletの位置を特定するために必要な情報をすべて提供します。

Wallet Manager

「Oracle Wallet Manager」を参照してください。

Webサービス

HTTP、XML、SOAPなどの標準的なインターネット・プロトコルを使用してアクセスできるアプリケーションまたはビジネス・ロジック。Webサービスでは、コンポーネントベース開発とWorld Wide Webの両者が持つ優れた利点が結び付けられています。Webサービスは、コンポーネントと同様、サービスの実装方法を知らなくても使用または再利用できるブラックボックス機能を実現します。

Web Services Description Language

XMLを使用してWebサービスを定義するための標準形式。WSDL定義には、Webサービスへのアクセス方法と、それを使用して実行できる操作が記述されます。

WSDL

「Web Services Description Language」を参照してください。

WS-Federation

Web Services Federation Languageのこと。Microsoft、IBM、VeriSignおよびRSA Security社によって開発された仕様。WS-Federationは、異種または同種のメカニズムを使用するエンティティ間でのフェデレーションを可能にするメカニズムを定義します。これは、公開されているWebサービス間で、ID、属性および認証の信頼性を確立および仲介することで実現されます。

「Liberty Alliance」も参照してください。

X.500

グローバル・ディレクトリの構造化方法を定義する、国際電気通信連合(ITU)の標準。X.500ディレクトリは、たとえば国、都道府県、市町村などの情報カテゴリごとに異なるレベルを持つ階層です。

X.509

デジタル証明書の定義において、最も幅広く使用されている標準。これは、認証サービスが備わった階層型ディレクトリに関する国際電気通信連合(ITU)の標準で、多くの公開鍵インフラストラクチャ(PKI)実装で使用されています。

XML

eXtensible Markup Language(XML)は、W3Cによって開発された仕様です。XMLは、Standard Generalized Markup Language(SGML)のWeb文書専用に設計された縮小版です。XMLはメタ言語(タグ・セットを定義する方法)であり、開発者は独自にカスタマイズしたマークアップ言語を文書の多数のクラスに定義できます。

XML正規化

論理的に同等な2つのXMLドキュメントを同じ物理表現に解決するプロセス。署名はそれが最初に計算処理されたときのデータの物理表現に対してのみ検証可能なため、XML正規化はデジタル署名において重要となります。詳細は、W3CのXML正規化仕様を参照してください。

索引
A B C D E F G H I J K L M N O P R S T U W X

A

アカウント・リンク, 1.1.3

管理

一般的なタスク, 4.2

アフィリエーション, 1.2.5

実行時の動作, 6.2

アーキテクチャ

一般的なデプロイメント, 2.6.2

アーキテクチャの考慮事項, 2.6.1 アサーション・マッピング

例, 6.16.3

アサーション有効, 5.3 アソシエーション, 1.1.3 アソシエーション・セッション・タイプ, 5.4.4 Attribute Exchange, 5.4.4

BAEプロファイル, 6.8.2

Attribute Exchange (AX), 2.2.2.6 属性マッピング

静的, 5.9.1.1.1

属性マッピングおよびフィルタリング, 5.9.1 属性名マッピング, 5.9.1.1 属性問合せ, 4.2.9 属性リクエスト, 4.2.9 属性リクエスト・メッセージ, 5.8.2 属性リクエスト, 5.8 属性リクエスタ

サービス・インタフェース, 5.8.1

属性レスポンス・メッセージ, 5.8.3 属性共有, 5.6

コンポーネント, 5.6.1

Webサービス・インタフェース, 5.8

属性値フィルタリング, 5.9.1.3

構成, 5.9.2.3

属性値マッピング, 5.9.1.2

構成, 5.9.2.2

監査, 7.4 認証エンジン, 10.2.1

認証フロー, 2.3

認証エンジン, 5.15

カスタム, 5.15.11

データベース・セキュリティ, 5.15.6

データベース表, 5.15.7

フェデレーテッドSSOプロキシ, 5.15.9

HTTPヘッダー, 5.15.1

情報カード, 5.15.8

JAAS, 5.15.10

LDAPディレクトリ, 5.15.5

Oracle Access Manager, 5.15.4

Oracle Access Manager 11g, 5.15.3

Oracle Single Sign-On, 5.15.2

認証メカニズム

デフォルト, 5.14.1.1

認証メカニズム, 5.14

ローカル, 5.14.2

SAML 1.x, 5.14.4

SAML 2.0, 5.14.3

WS-Federation 1.1, 5.14.5

認証モード, 2.3.1

B

バックエンド属性交換, Preface, 6.8.2

BAEの直接属性交換プロファイル, 6.8.2

双方向認証, 2.2.2.3

バインディング

HTTPアーティファクト, 1.2.4.2

HTTP POST, 1.2.4.1

HTTPリダイレクト, 1.2.4.4

ビジネス処理プラグイン, 11

例, 11.5

実装, 11.1.2

ユーザー・マッピングのバイパス, 6.19

C

証明書パス検証, 6.22

証明書リポジトリ, 2.1.3.3

証明書検証, 2.1.3.3

証明書

信頼, 4.1.1.2

認定マトリックス, 1.2.8 主張識別子, 1.1.3 共通ドメイン・パラメータ, 5.3 構成設定

メタデータ, 5.1.1

構成設定とプロバイダ・メタデータ, 5.1.1 オーディエンス制限の構成, 6.21 サービス・プロバイダの構成, 5.5 Cookie存続期間, 5.3 カスタム認証エンジンの作成, 10.3 カスタムSP統合エンジンの作成, 10.4 資格証明, 4.5 クロスドメインの信頼, 4.1.1.2 暗号化プロバイダ, 1.2.6 カスタムIAM, 10.1

D

データ・ストア, 2.4

構成, 2.4.4, 5.13.4

フェデレーション, 2.4.1, 5.13.2

セッションおよびメッセージ, 2.4.3, 5.13.3

ユーザー, 2.4.2, 5.1.2, 5.13.1

データ・ストア

管理, 5.13

デプロイメント

アーキテクチャ, 2.1

インストール要件, 2.4.4

計画, 4.1.1.3

プロファイルとバインディング, 2.2

プロトコル, 2.1.4

プロキシ・サーバー, 2.1.2

シナリオ, 3.2

セキュリティ, 2.1.3

サーバー・ロール, 2.1.1

サイズ設定, 2.6

トポロジ, 2.1.1, 2.6.4

Oracle HTTP Server, 3.2.1

Oracle Single Sign-On, 3.2.2

デプロイメント計画, 4.1.1.2 プロビジョニング解除, 5.1.2 宛先ドメイン, 1.1.3 検出, 1.1.3 DNパターンから属性レスポンダ

大/小文字区別, 5.5.1

ドメイン, 1.1.3

E

エラー・タイプ, 6.13.3

ユーザーIDの交換, 4.1.1.2

外部OpenIDプロバイダ, 5.4.5

F

機能, 新

リリース11g(11.1.1), Preface

フェデレーテッドID管理, 1.1.1

イベント・フロー, 1.2.7

フェデレーテッドSSOプロキシ

認証エンジン, 5.15.9

フェデレーション

アカウント・リンク, 1.1.3

利点, 1.1.1

概念, 1.1.3

標準の発展, 1.1.4.2

ユースケース, 1.1.2

フェデレーション・データ・ストア, 2.4.1, 5.13.2.1, 6.14 フェデレーション・プロファイル, 1.2.4

アーティファクト, 1.2.4.2

フェデレーション終了, 1.2.4.8

グローバル・ログアウト, 1.2.4.9

名前識別子, 1.2.4.5

フェデレーション・プロトコル, 1.1.4 フェデレーション・レコード

構造, 5.1.2

一意性, 5.1.2

フェデレーション終了

プロファイル, 1.2.4.8

強制SSL, 5.2.1, 5.2.1 再認証の強制

Oracle Single Sign-Onではサポートされない, 3.2.2

G

グローバル・ログアウト

オンデマンド, 6.8.4

H

高可用性, 2.6.1.6

ホスト接続のプロパティ, 5.2.1

HTTP Basic認証, 2.3.6

HTTPヘッダーの属性, 5.15.1

HTTPSモード, 5.2.1, 5.2.1

I

ICAM

OpenID, 2.2.2.6

アイデンティティ

フェデレーション, 4.4.2

検索オプション, 4.4.4

ユーザー, 4.4.3

アイデンティティ・フェデレーション・エンジン, 10.2.1 Identity Management

課題, 1.1.1

フェデレーテッド, 1.1.1

アイデンティティ・プロバイダ, 1.1.3 アイデンティティ・プロバイダ

SSOアサーションでの属性の送信, 5.7

アイデンティティ・プロバイダ - 共通プロパティ, 5.3 アイデンティティ・プロバイダ - プロトコル固有のプロパティ, 5.4 IdPプロパティ

OpenID, 5.4.4

SAML 1.x, 5.4.2

SAML 2.0, 5.4.1

WS-Federation, 5.4.3

実装チェックリスト, 2.7

J

JAAS

認証エンジン, 5.15.10

JCEポリシー・ファイル, 8.3

K

キーストア, 4.1.1.2

パスワード, 8.2.1

L

LD_ASSUME_KERNEL, C.1.4.3

LDAPディレクトリ

認証エンジン, 5.15.5

ログ・ファイル, 4.1.3 ロギング, 7.3 ログイン表

RDBMS認証エンジン, 5.15.7.1

ログアウト, 4.2.6

M

マッピング

認証メカニズムから認証エンジン, 5.14.1.2

方式から認証メカニズム, 5.14.1.2

マッピングおよびフィルタリング

構成, 5.9.2

MBean

構成データ, A

データ・ストアの構成, A.3

プロバイダ固有の構成, A.2

サーバー全体の構成, A.1

メッセージ・データ・ストア, 5.13.3 メタデータ, 4.1.1.2

影響を受けるプロパティ, 5.1.1

影響を与えるプロパティ, 5.1.1

メタデータ, 5.1.1

影響を与えるプロパティ, 5.1.1

プロトコルのURL, 5.1.1

再公開, 5.1.1

監視, 7.1

N

名前ID

ユーザーIDの使用, 5.4.2

名前IDの検索

無効化, 6.14

新機能

リリース11g(11.1.1), Preface

O

OASIS, 1.1.4.1

オンデマンド・グローバル・ログアウト, 6.8.4

OpenID, 2.2.1.3

アソシエーション, 1.1.3

属性交換, 2.2.2.6

主張識別子, 1.1.3

Diffie-Hellmanのパラメータ, 5.5.5

検出, 1.1.3

一般サービス・プロバイダ, 5.4.4

ICAM, 2.2.2.6

PAPE, 2.2.2.6

PAPE 1.0, 5.5.5

処理フロー, 2.2.2.6

プロファイルおよび拡張, 2.2.2.6

プロファイルおよび拡張, 1.2.4.10

プロバイダ, 1.1.3

リライイング・パーティ, 1.1.3

SPプロパティ, 5.5.5

OpenID IdP, 5.4.4 OpenIDパートナ

統合, 6.24

OpenIDプロバイダ, 1.1.3

外部, 5.4.5

統合, 6.24.1

OpenID SP, 5.5.5 Oracle Access Manager

認証, 2.3.4

認証エンジン, 5.15.4

プラグインの構成 5.6.3

デプロイ, 3.2.4

スキームおよびポリシー, 5.6.4

Oracle Access Manager 11g

認証エンジン, 5.15.3

Oracle Directory Server Enterprise Edition

デプロイ, 3.2.6

Oracle HTTP Server

プロキシとして動作, B.1

デプロイ, 3.2.1.1

Oracle Identity Federation, 1.2

管理, 4.1.2

管理ツール, 4.1.2

PKI, 4.1.1.2

アーキテクチャ, 1.2.2, 10.2.1

IdP属性レスポンダとして動作, 5.6.6

SP属性リクエスタとして動作, 5.6.5

SSLクライアントとして動作, 8.1.2

SSLサーバーとして動作, 8.1.1

基本管理, 4.1

利点, 1.2.1

構成, 5

保持されるデータ, 5.1

Oracle Access Managerとのデプロイ, 3.2.4

Oracle HTTP Serverとのデプロイ, 3.2.1

Oracle Single Sign-Onとのデプロイ, 3.2.2

フェデレーテッド・アイデンティティ, 4.4.1

フェデレーション, 4.3

ホームページ, 7.1.1

インストール要件, 2.5

ログ・ファイル, 4.1.3

資格証明の管理, 4.5

モジュールおよびフロー, 10.2.1

プロキシ, B

スキーマ, 5.13.5

SSL, 8.1

Oracle Directory Server Enterprise Edition, 3.2.6

WLST

コマンドのリスト, 9.2

WLST, 9 Oracle Identity Federation/SP

OAMに対する認証, 3.2.5

Oracle Single Sign-On

認証, 2.3.5

認証エンジン, 5.15.2

デプロイ, 3.2.2

デプロイのテスト, 3.2.2.6

Oracle Universal Federation Framework, 1.1.3 アウトバウンド接続のプロパティ, 5.2.2 名前IDマッピングの上書き, 6.20

P

PAPE

OpenID, 2.2.2.6

PAPE 1.0, 5.4.4 パフォーマンス, 6.14

アサーションのセキュリティ, 2.6.1.4

接続のチューニング, 2.6.1.5

プロファイル, 2.6.1.1

リポジトリ, 2.6.1.2

サーバーのチューニング, 2.6.1.7

チューニング、2.6

パフォーマンス・サマリー, 7.1.2 PKI, 4.1.1.2 プリンシパル, 1.1.3 プロファイル

アーティファクト

リクエストの処理, 2.2.2.1

セキュリティ, 2.2.2.3

使用, 2.2.2.1

プロキシ, 2.2.2.1

属性共有

使用, 2.2.2.4

選択, 2.2.2 フェデレーション終了, 1.2.4.8 HTTPリダイレクト, 1.2.4.4 ログアウト, 1.2.4.9 OpenID, 2.2.2.6 パッシブ・リクエスタ, 1.2.4.7 POST, 1.2.4.1

リクエストの処理, 2.2.2.2

セキュリティ, 2.2.2.3

使用, 2.2.2.2

プロキシ, 2.2.2.2

WS-Federation

使用, 2.2.2.5

プロキシ・サーバー, 2.1.2, B

R

RCU

スキーマの作成, 5.13.5

再認証, 5.3

Oracle Single Sign-Onでは強制はサポートされない, 3.2.2

リファレンス・フットプリント, 2.6.3 リライイング・パーティ, 1.1.3

統合, 6.24.2

ロール

FederationAdmin, 4.1.1.1

S

SAML, 1.1.4.1

アサーション, 1.1.4.1

認証例, 1.1.4.4

プロファイル, 1.1.4.1

プロトコル・バインディング, 1.1.4.1

リクエストとレスポンスのサイクル, 1.1.4.1

リクエスト-レスポンス・サイクル, 1.1.4.1

SAML 1.x, 1.1.4.3

IdPプロパティ, 5.4.2

SP, 5.5.3

SAML 2.0, 1.1.4.4

IdP名前IDフォーマット, 5.4.1

IdPプロパティ, 5.4.1

SP, 5.5.2

SAMLでのセキュリティに関する考慮事項, 2.2.2.3 スキーマ

作成, 5.13.5

検証, 6.13.4

スキーマ検証, 6.13.4 セキュリティおよび信頼

構成, 5.10

プロバイダ・メタデータ, 5.10.2

信頼できるCAおよびCRL, 5.10.3

ウォレット, 5.10.1

セキュリティに関する考慮事項, 2.2.2.3 サーバー証明書, 4.2.2 サーバー・クロック・ドリフト, 5.2.1 サーバー構成データ, 5.1.1 サーバー・ホスト名, 5.2.1 サーバー・メタデータ, 4.2.1 サーバー・ポート, 5.2.1 サービス・プロバイダ, 1.1.3 サービス・プロバイダ

共通プロパティ, 5.5.1

OpenID, 5.5.5

SAML 1.x, 5.5.3

SAML 2.0, 5.5.2

WS-Federation 1.1, 5.5.4

セッション

アクティブな期間, 5.2.1

セッション・データ・ストア, 5.13.3 セッション・タイムアウト, 5.2.1 セッション・タイプ, 5.4.4 setConfigProperty

DNパターンの照合, 5.5.1

署名の検証, 4.2.7 署名ウォレットおよび暗号化ウォレット, 8.2 シングル・サインオン, 1.1 シングル・サインオン

SAML 1.xおよびWS-Federation, 4.3.5

ユーザー・オプトインおよびオプトアウト, 6.18

スキーマ検証, 6.13.4

サイジングのガイドライン, 2.6 SOAPポート, 5.2.1 SP統合エンジン

カスタム, 10.4

SPプロパティ

OpenID, 5.5.5

SSL, 8.1

PKI, 4.1.1.2

構成, 8.1.1

Oracle Identity Federationの構成, 8.1

有効化, サーバー用, 5.2.1, 5.2.1

署名ウォレットおよび暗号化ウォレット, 8.2

静的属性マッピング, 5.9.1.1.1 サポートされている標準とアプリケーション, 1.2.8

T

テストSPエンジン, 3.2.7

サード・パーティのIAMソリューション, 10.1

タイムアウト・パラメータ, 5.3

トポロジ, 2.6.4

一時データ・ストア, 2.4.3

トラブルシューティング

アクセス・ゲート権限エラー, C.1.4.1

同一のCookieドメインを持つバックエンド, C.1.4.4

ログイン・ページのブックマーク, C.1.3.2

リソースのブックマーク, C.1.6.1

ファイル記述子エラー, C.1.5.1

正しくないログイン・ページ, C.1.3.1

LD_ASSUME_KERNEL, C.1.4.3

非ASCIIアクセス・ゲートID, C.1.4.2

オペレーティング・システムの構成, C.1.5

Oracle Access Managerの構成, C.1.4

Oracle Identity Federationの構成, C.1.2

Oracle Single Sign-Onの構成, C.1.3

実行時およびSSOに関する問題, C.1.6

信頼できるプロバイダ

追加, 4.3.2

削除, 4.3.4

SSO, 4.3.5

検索, 4.3.1

更新, 4.3.3

U

ユーザー承諾, 5.4.1

ページの例, 5.4.1

ユーザー・データ・ストア, 2.4.2

使用しない構成, 5.13.1.5

接続データ, 2.4.2

ユーザー・フェデレーション・データ, 5.1.2 ユーザー・フェデレーション・レコード・コンテキスト, 2.4.1 ユーザー・オプトインおよびオプトアウト

シングル・サインオン, 6.18

ユーザー・レコード

基本データ, 5.1.2

プロビジョニング解除, 5.1.2

フェデレーション・データ, 5.1.2

同期, 5.1.2

W

Webアクセス管理(WAM)システム, 1.2.3

Webプロキシ

背後での構成, 3.2.6.3

WLST, 9

addConfigListEntryInMap, 9.2.1

addConfigMapEntryInMap, 9.2.2

addConfigPropertyListEntry, 9.2.3

addConfigPropertyMapEntry, 9.2.4

addFederationListEntryInMap, 9.2.7

addFederationMapEntryInMap, 9.2.8

addFederationPropertyMapEntry, 9.2.10

changePeerProviderDescription, 9.2.16

changeSessionStore, 9.2.17

createConfigPropertyList, 9.2.18

createConfigPropertyListInMap, 9.2.19

createConfigPropertyMap, 9.2.20

createConfigPropertyMapInMap, 9.2.21

createFederationPropertyList, 9.2.22

createFederationPropertyListInMap, 9.2.23

createFederationPropertyMap, 9.2.24

createFederationPropertyMapInMap, 9.2.25

createPeerProviderEntry, 9.2.26

deleteCustomAuthnEngine, 9.2.11

deleteCustomSPEngine, 9.2.12

deleteUserFederations, 9.2.14

environment setup, 9.1.1

executing commands, 9.1.2

extractproviderprops, 9.2.36

getConfigListValueInMap, 9.2.27

getConfigMapEntryInMap, 9.2.28

getConfigProperty, 9.2.29

getConfigPropertyList, 9.2.30

getConfigPropertyMapEntry, 9.2.31

getFederationListValueInMap, 9.2.32

getFederationMapEntryInMap, 9.2.33

getFederationProperty, 9.2.34

getFederationPropertyList, 9.2.35

getFederationPropertyMapEntry, 9.2.38

listCustomAuthnEngines, 9.2.39

listCustomSPEngines, 9.2.40

loadMetadata, 9.2.41, 9.2.42

removeConfigListInMap, 9.2.43

removeConfigMapEntryInMap, 9.2.44

removeConfigMapInMap, 9.2.45

removeConfigProperty, 9.2.46

removeConfigPropertyList, 9.2.47

removeConfigPropertyMap, 9.2.48

removeConfigPropertyMapEntry, 9.2.49

removeFederationListInMap, 9.2.50

removeFederationMapEntryInMap, 9.2.52

removeFederationMapInMap, 9.2.51

removeFederationProperty, 9.2.53

removeFederationPropertyList, 9.2.54

removeFederationPropertyMap, 9.2.55

removeFederationPropertyMapEntry, 9.2.56

removePeerProviderEntry, 9.2.57

setConfigProperty, 9.2.58

setCustomAuthnEngine, 9.2.59

setCustomSPEngine, 9.2.60

setFederationProperty, 9.2.61

setproviderprops, 9.2.37

WS-Federation, 1.1.4.5

IdPプロパティ, 5.4.3

WS-Federation 1.1

SP, 5.5.4

X

X.509証明書, 4.1.1.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。