Oracle® Fusion Middleware

Oracle Identity Manager開発者ガイド

11gリリース2 (11.1.2.1.0)

B69536-05(原本部品番号:E27150-08)

2013年9月

Oracle Fusion Middleware Oracle Identity Manager開発者ガイド, 11g リリース2 (11.1.2.1.0)

B69536-05

Copyright © 1991, 2013, Oracle and/or its affiliates. All rights reserved.

原本著者:  Debapriya Datta

原本協力著者:  Prakash Hulikere

協力者:  Atul Goyal、Javed Beg、Rajesh Pakkath、Sanjay Rallapalli

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

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

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

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の登録商標です。

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

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

第I部 概念

1 製品の概要

- 1.1 主な特長と利点

- 1.1.1 デプロイの容易性

- 1.1.2 UIのカスタマイズの簡略化

- 1.1.3 構成の簡略化

- 1.1.4 柔軟性と耐性

- 1.1.5 既存のインフラストラクチャを最大限に再利用

- 1.1.6 広範なユーザー管理

- 1.1.7 Webベースのユーザー・セルフサービス

- 1.1.8 モジュール型のスケーラブルなアーキテクチャ

- 1.1.9 主要なソフトウェア開発標準への準拠

- 1.1.10 強力で柔軟性の高いプロセス・エンジン

- 1.1.11 組込みの変更管理

- 1.1.12 ワークフローおよびポリシー

- 1.1.13 監査およびコンプライアンス管理

- 1.1.14 統合ソリューション

- 1.1.15 ユーザー・プロビジョニング

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

2 製品のアーキテクチャ

- 2.1 Oracle Identity Managerの仕組み: Oracle Identity Managerの層

- 2.1.1 プレゼンテーション層

- 2.1.2 ビジネス・サービス層

- 2.1.2.1 APIサービス

- 2.1.2.2 統合サービス

- 2.1.2.3 プラットフォーム・サービス

- 2.1.3 ミドルウェア層

- 2.1.3.1 リクエスト・サービスと承認ワークフロー

- 2.1.3.2 認可サービス

- 2.1.3.3 UIカスタマイズ・フレームワーク

- 2.1.3.4 スケジューラ・サービス

- 2.1.3.5 レポート作成

- 2.1.4 データ層

- 2.1.4.1 Oracle Identity Managerデータベース

- 2.1.4.2 メタデータ・ストア

- 2.1.4.3 アイデンティティ・ストア

- 2.1.4.4 LDAPアイデンティティ・ストアとOracle Identity Managerの統合

- 2.2 システム・コンポーネント

3 セキュリティのアーキテクチャ

- 3.1 セキュリティ・モデル

- 3.1.1 管理ロールの割当て

- 3.1.2 ユーザー属性に対する属性レベルのセキュリティ

- 3.1.2.1 ポリシー評価用の属性を渡すためのプラグインの使用

- 3.1.3 ポリシーの責任

- 3.2 機能およびデータ・セキュリティのマッピング

- 3.3 組織へのエンティティの公開

- 3.4 OESポリシーの管理

- 3.4.1 認可ポリシーのカスタマイズ

- 3.4.1.1 誰がどのユーザーを表示できるかの制御

- 3.4.1.2 誰がどのユーザーを変更できるかの制御

- 3.4.1.3 誰がどのリンクを表示できるかの制御

- 3.4.1.4 誰がアプリケーション・インスタンスのアカウントをリクエストできるかの制御

- 3.4.1.5 誰がアカウントを変更できるかの制御

- 3.4.1.6 誰がアプリケーション・インスタンスを管理できるかの制御

- 3.4.1.7 誰がユーザー・パスワードを変更できるかの制御

- 3.4.1.8 誰がアカウント・パスワードを変更できるかの制御

- 3.4.1.9 どの操作が直接またはリクエスト・ベースであるかの制御

- 3.4.1.10 セルフ・プロファイルの拒否属性の制御

- 3.5 機能セキュリティの強制

- 3.5.1 タスク・フローまたはリージョンの実装

- 3.5.2 定義済のアクション

- 3.5.3 フィールドレベル・セキュリティの実装

第II部 アプリケーションのプロビジョニング

4 アプリケーション・インスタンスの開発

- 4.1 ITリソースの作成

- 4.2 ITリソースの管理

- 4.2.1 ITリソースの表示

- 4.2.2 ITリソースの変更

- 4.2.3 ITリソースの削除

- 4.3 Design Consoleを使用したリソースの管理

- 4.3.1 リソース管理の概要

- 4.3.2 「ITリソース・タイプ定義」フォーム

- 4.3.2.1 ITリソース用のテンプレート(リソース・タイプ)の定義

- 4.3.2.2 「ITリソース・タイプ定義」フォームのタブ

- 4.3.2.3 ITリソース・タイプ定義表

- 4.3.3 「ルール・デザイナ」フォーム

- 4.3.3.1 ルールの作成

- 4.3.3.2 「ルール・デザイナ」フォームのタブ

- 4.3.3.3 ルール・デザイナ表

- 4.3.4 「リソース・オブジェクト」フォーム

- 4.3.4.1 リソース・オブジェクトの作成

- 4.3.4.2 「リソース・オブジェクト」フォームのタブ

- 4.3.4.3 複数の信頼できるソースのリコンシリエーション

- 4.3.5 サービス・アカウントの管理

- 4.4 接続なしアプリケーション・インスタンスの接続アプリケーション・インスタンスへの変換

- 4.4.1 本番環境での接続なしアプリケーション・インスタンスの作成

- 4.4.2 本番環境からの接続なしアプリケーション・インスタンスのエクスポート

- 4.4.3 テスト環境での接続なしアプリケーション・インスタンスのインポート

- 4.4.4 接続なしから接続ありへのアプリケーション・インスタンスの変更

- 4.4.5 接続アプリケーション・インスタンスのテスト

5 プロビジョニング・プロセスの開発

- 5.1 プロセス管理の概要

- 5.2 「電子メール定義」フォーム

- 5.2.1 電子メール・サーバーの指定

- 5.2.2 「電子メール定義」フォーム

- 5.2.3 電子メール定義の作成

- 5.3 「プロセス定義」フォーム

- 5.3.1 プロセス定義の作成

- 5.3.2 「プロセス定義」フォームのタブ

- 5.3.2.1 「タスク」タブ

- 5.3.2.2 リコンシリエーション・フィールド・マッピング・タブ

- 5.3.2.3 「管理者」タブ

- 5.3.3 プロセス・タスクの変更

- 5.3.3.1 「一般」タブ

- 5.3.3.2 統合タブ

- 5.3.3.3 タスク依存性タブ

- 5.3.3.4 「レスポンス」タブ

- 5.3.3.5 取消し/リカバリ・タブ

- 5.3.3.6 「通知」タブ

- 5.3.3.7 タスクとオブジェクトのステータス・マッピング・タブ

- 5.3.3.8 タスクの編集ウィンドウの「割当て」タブ

6 プロセス・フォームの開発

- 6.1 フォームの作成

- 6.2 「フォーム・デザイナ」フォームのタブ

- 6.2.1 「追加列」タブ

- 6.2.1.1 フォームへのデータ・フィールドの追加

- 6.2.1.2 フォームからのデータ・フィールドの削除

- 6.2.1.3 AccountPasswordプロパティの値の設定

- 6.2.2 子表タブ

- 6.2.2.1 フォームへの子表の割当て

- 6.2.2.2 フォームからの子表の削除

- 6.2.3 オブジェクト権限タブ

- 6.2.3.1 ユーザー作成フォームへのユーザー・グループの割当て

- 6.2.3.2 ユーザー作成フォームからのユーザー・グループの削除

- 6.2.4 「プロパティ」タブ

- 6.2.4.1 データ・フィールドへのプロパティおよびプロパティ値の追加

- 6.2.4.2 カスタマイズされた参照問合せのプロパティおよびプロパティ値の追加

- 6.2.4.3 データ・フィールドからのプロパティおよびプロパティ値の削除

- 6.2.5 「管理者」タブ

- 6.2.5.1 ユーザー作成フォームのレコードに対する権限のユーザー・グループへの割当て

- 6.2.5.2 ユーザー作成フォームのレコードに対するユーザー・グループ権限の削除

- 6.2.6 使用方法タブ

- 6.2.7 「事前移入」タブ

- 6.2.8 デフォルト列タブ

- 6.2.9 「ユーザー定義フィールド」タブ

- 6.3 フォームの追加バージョンの作成

7 参照定義およびRemote Managerの管理

- 7.1 概要

- 7.2 「参照定義」フォーム

- 7.2.1 参照定義の作成

- 7.2.2 参照コード情報タブ

- 7.2.2.1 参照値の作成および変更

- 7.2.2.2 参照値の削除

- 7.2.3 ユーザーのチャレンジ質問の構成

- 7.3 「Remote Manager」フォーム

第III部 コネクタ

8 アダプタ・ファクトリの使用

- 8.1 アダプタの概要

- 8.2 アダプタのタイプ

- 8.3 アダプタ環境とツール

- 8.3.1 アダプタ環境の構成

- 8.3.2 Remote Manager

- 8.3.3 アダプタ・ファクトリ

- 8.3.4 アダプタのコンパイル

- 8.3.4.1 アダプタの自動コンパイル

- 8.3.4.2 アダプタの手動コンパイル

- 8.4 アダプタの定義

- 8.5 「アダプタ・ファクトリ」フォームのタブ

- 8.5.1 アダプタ・タスク

- 8.5.2 実行スケジュール

- 8.5.3 リソース

- 8.5.4 変数リスト

- 8.5.5 使用状況参照

- 8.5.6 レスポンス

- 8.6 アダプタの無効化と再有効化

- 8.7 アダプタ変数について

- 8.7.1 アダプタ変数の作成

- 8.7.2 アダプタ変数の変更

- 8.7.3 アダプタ変数の削除

- 8.8 アダプタ・タスクの作成

- 8.8.1 アダプタ・タスクのタイプ

- 8.8.2 Javaタスクの作成

- 8.8.3 リモート・タスクの作成

- 8.8.4 ストアド・プロシージャ・タスクの作成

- 8.8.5 ユーティリティ・タスクの作成

- 8.8.6 Oracle Identity Manager APIタスクの作成

- 8.8.7 アダプタ変数の値の再割当て

- 8.8.8 エラー・ハンドラ・タスクの追加

- 8.8.9 ロジック・タスクの作成

- 8.9 アダプタ・タスクの変更

- 8.10 タスクの順序とネストの変更

- 8.11 アダプタ・タスクの削除

- 8.12 レスポンスの使用

- 8.12.1 レスポンスの作成

- 8.12.2 レスポンスの変更

- 8.12.3 レスポンスの削除

- 8.13 ルール・ジェネレータおよびエンティティ・アダプタのスケジューリング

- 8.13.1 ルール・ジェネレータおよびエンティティ・アダプタのスケジューリング

- 8.14 ルール・ジェネレータ・アダプタの使用

- 8.14.1 ルール・ジェネレータのアダプタ変数のマッピング

- 8.14.2 ルール・ジェネレータとプロセスの関連付け

- 8.14.3 ルール・ジェネレータのフォーム・フィールドからの削除

- 8.15 エンティティ・アダプタの使用

- 8.16 タスク割当てアダプタの使用

- 8.16.1 タスク割当てアダプタのプロセス・タスクへのアタッチ

- 8.16.2 タスク割当てアダプタのプロセス・タスクからの削除

- 8.16.2.1 タスク割当てアダプタのプロセス・タスクからの削除

- 8.17 事前移入アダプタの使用

- 8.17.1 事前移入アダプタのフォーム・フィールドへのアタッチ

- 8.17.2 事前移入アダプタのフォーム・フィールドからの削除

- 8.18 プロセス・タスク・アダプタの使用

- 8.18.1 プロセス・タスク・アダプタを使用するためのガイドライン

- 8.18.2 プロセス・タスク・アダプタのプロセス・タスクへのアタッチ

- 8.18.3 プロセス・タスク・アダプタのプロセス・タスクからの削除

- 8.18.3.1 プロセス・タスク・アダプタのプロセス・タスクからの削除

- 8.19 アダプタ・マッピング情報

- 8.19.1 アダプタ・タスク・マッピング情報

- 8.19.1.1 アダプタ変数

- 8.19.1.2 アダプタ・タスク

- 8.19.1.3 リテラル

- 8.19.1.4 アダプタ参照

- 8.19.1.5 組織定義

- 8.19.1.6 プロセス定義

- 8.19.1.7 ユーザー定義

- 8.19.2 アダプタ変数マッピング情報

- 8.19.2.1 「変数リスト」タブ

- 8.19.2.2 プロセス・タスク・アダプタ変数マッピング

- 8.19.2.3 タスク割当てアダプタ変数マッピング

- 8.19.2.4 ルール・ジェネレータおよびエンティティ・アダプタ変数マッピング

- 8.19.2.5 事前移入アダプタ変数マッピング

- 8.20 エラー・メッセージの定義

9 Identity Connector Frameworkの理解

- 9.1 ICFの利点

- 9.2 ICFアーキテクチャの概要

- 9.3 ICF APIの使用

- 9.3.1 ConnectorInfoManagerFactoryクラス

- 9.3.2 ConnectorInfoManagerインタフェース

- 9.3.3 ConnectorKeyクラス

- 9.3.4 ConnectorInfoインタフェース

- 9.3.5 APIConfigurationインタフェース

- 9.3.6 ConfigurationPropertiesインタフェース

- 9.3.7 ConnectorFacadeFactoryクラス

- 9.3.8 ConnectorFacadeインタフェース

- 9.4 ICF SPIの概要

- 9.4.1 必須インタフェースの実装

- 9.4.1.1 org.identityconnectors.framework.spi.Connector

- 9.4.1.2 org.identityconnectors.framework.spi.Configuration

- 9.4.2 機能ベースのインタフェースの実装

- 9.4.2.1 org.identityconnectors.framework.spi.PoolableConnector

- 9.4.2.2 org.identityconnectors.framework.spi.AttributeNormalizer

- 9.4.3 処理インタフェースの実装

- 9.4.3.1 SchemaOpインタフェースの実装

- 9.4.3.2 CreateOpインタフェースの実装

- 9.4.3.3 DeleteOpインタフェースの実装

- 9.4.3.4 SearchOpインタフェースの実装

- 9.4.3.5 UpdateOpインタフェースの実装

- 9.4.4 共通クラス

- 9.5 アイデンティティ・コネクタ・バンドルの拡張

- 9.6 アイデンティティ・コネクタ・サーバーの使用

- 9.6.1 Javaコネクタ・サーバーの使用

- 9.6.1.1 Javaコネクタ・サーバーのインストールおよび構成

- 9.6.1.2 Microsoft WindowsでのJavaコネクタ・サーバーの実行

- 9.6.1.3 SolarisおよびLinuxでのJavaコネクタ・サーバーの実行

- 9.6.1.4 Javaコネクタ・サーバーへのアイデンティティ・コネクタのインストール

- 9.6.1.5 SSLを使用したコネクタ・サーバーとの通信

- 9.6.2 Microsoft .NET Frameworkコネクタ・サーバーの使用

- 9.6.2.1 .NETコネクタ・サーバーのインストール

- 9.6.2.2 .NETコネクタ・サーバーの構成

- 9.6.2.3 トレース設定の構成

- 9.6.2.4 .NETコネクタ・サーバーの実行

- 9.6.2.5 .NETコネクタ・サーバーへの複数のコネクタのインストール

10 Javaを使用したアイデンティティ・コネクタの開発

- 10.1 フラット・ファイル・コネクタの開発

- 10.1.1 ファイル入力および出力処理のサポート・クラス

- 10.2 Oracle Identity Managerデータベースへのアイデンティティ・コネクタ・バンドルのアップロード

- 10.2.1 Oracle Identity Managerへのコネクタ・バンドルの登録

- 10.2.2 基本的なアイデンティティ・コネクタ・メタデータの作成

- 10.2.2.1 ITリソース・タイプ定義の作成

- 10.2.2.2 リソース・オブジェクトの作成

- 10.2.2.3 参照の作成

- 10.2.3 プロビジョニング・メタデータの作成

- 10.2.3.1 プロセス・フォームの作成

- 10.2.3.2 アダプタの作成

- 10.2.3.3 プロセス定義の作成

- 10.2.3.4 プロビジョニング属性マッピング参照の作成

- 10.2.4 リコンシリエーション・メタデータの作成

- 10.2.4.1 リコンシリエーション・スケジュール・タスクの作成

- 10.2.4.2 リコンシリエーション・プロファイルの作成

- 10.2.4.3 リコンシリエーション・アクション・ルールの設定

- 10.2.4.4 リコンシリエーション・マッピングの作成

- 10.2.4.5 リコンシリエーション一致ルールの定義

- 10.3 フラット・ファイル・アカウントのプロビジョニング

- 10.4 Javaコネクタ・サーバーのSSLの構成

11 .NETを使用したアイデンティティ・コネクタの開発

- 11.1 フラット・ファイル.NETコネクタの開発

- 11.2 .NETコネクタ・サーバーでのアイデンティティ・コネクタ・バンドルのデプロイ

- 11.2.1 .NETコネクタ・サーバーへのコネクタ・バンドルの登録

- 11.2.2 基本的なアイデンティティ・コネクタ・メタデータの作成

- 11.2.2.1 ITリソース・タイプ定義の作成

- 11.2.2.2 リソース・オブジェクトの作成

- 11.2.2.3 参照の作成

- 11.2.3 プロビジョニング・メタデータの作成

- 11.2.3.1 プロセス・フォームの作成

- 11.2.3.2 アダプタの作成

- 11.2.3.3 プロセス定義の作成

- 11.2.3.4 プロビジョニング属性マッピング参照の作成

- 11.2.4 リコンシリエーション・メタデータの作成

- 11.2.4.1 リコンシリエーション・スケジュール・タスクの作成

- 11.2.4.2 リコンシリエーション・プロファイルの作成

- 11.2.4.3 リコンシリエーション・アクション・ルールの設定

- 11.2.4.4 リコンシリエーション・マッピングの作成

- 11.2.4.5 リコンシリエーション一致ルールの定義

- 11.3 フラット・ファイル・アカウントのプロビジョニング

12 ICFとOracle Identity Managerの統合

- 12.1 ICF共通

- 12.2 統合アーキテクチャ

- 12.3 Oracle Identity Managerのグローバル参照

- 12.3.1 メインの参照構成

- 12.3.2 ユーザー管理構成

- 12.3.3 リコンシリエーション変換参照(Lookup.CONNECTOR_NAME.UM.ReconTransformation)

- 12.3.4 リコンシリエーション検証参照(Lookup.CONNECTOR_NAME.UM.ReconValidation)

- 12.3.5 オプションのデフォルト参照

- 12.4 ITリソース

- 12.5 プロビジョニング

- 12.5.1 ICFプロビジョニング・マネージャ

- 12.5.1.1 プロビジョニング用のAPI

- 12.5.1.2 アカウント関連の操作

- 12.5.1.3 複数値の操作

- 12.5.1.4 その他の操作

- 12.5.2 プロビジョニング参照

- 12.5.3 ユーザー以外のオブジェクト・タイプ

- 12.5.4 プロビジョニングのオプションの参照

- 12.5.4.1 プロビジョニング検証参照

- 12.5.5 プロビジョニング属性マップの参照でのオプション・フラグ

- 12.5.6 プロビジョニング属性マップでの複合属性

- 12.6 ICF共通でのリコンシリエーションの概念

- 12.6.1 リコンシリエーションのタイプ

- 12.6.1.1 ターゲットおよび信頼できるリコンシリエーション

- 12.6.1.2 完全リコンシリエーションおよび増分リコンシリエーション

- 12.6.1.3 高度な増分リコンシリエーション

- 12.6.1.4 リコンシリエーションの削除

- 12.6.1.5 グループ参照リコンシリエーション

- 12.6.2 Oracle Identity Managerのリコンシリエーション・アーティファクトのリスト

- 12.6.2.1 リコンシリエーションの参照

- 12.7 事前定義済のスケジュール済タスク

- 12.7.1 LookupReconTask

- 12.7.2 SearchReconTask

- 12.7.3 SearchReconDeleteTask

- 12.7.4 SyncReconTask

- 12.8 ICFフィルタの構文

13 ICF統合のJava APIの使用

14 ICFコネクタの構成

- 14.1 コネクタ・ロード・バランサの構成

- 14.2 リコンシリエーションおよびプロビジョニング中のデータ検証の構成

- 14.3 ユーザー・リコンシリエーション中のデータ変換の構成

- 14.4 リソース除外リストの構成

- 14.5 コネクタ・サーバーおよびOIMのSSLの設定

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

- 14.6 ターゲット・システム属性の追加

- 14.6.1 プロビジョニングに関するターゲット・システム属性の追加

- 14.6.2 ターゲット・リコンシリエーションに関するターゲット・システム属性の追加

- 14.6.3 信頼できるリコンシリエーションに関するターゲット・システム属性の追加

15 ICFのベスト・プラクティスおよびFAQの理解

- 15.1 ICFのベスト・プラクティス

- 15.2 ICFのFAQ

16 汎用テクノロジ・コネクタの理解

- 16.1 汎用テクノロジ・コネクタの必要性

- 16.2 汎用テクノロジ・コネクタの機能アーキテクチャ

- 16.2.1 リコンシリエーション・モジュールのプロバイダおよびデータセット

- 16.2.2 プロビジョニング・モジュールのプロバイダおよびデータセット

- 16.2.3 「Oracle Identity Manager」データセット

- 16.3 汎用テクノロジ・コネクタの機能

- 16.3.1 リコンシリエーション・モジュールに固有の機能

- 16.3.1.1 信頼できるソースのリコンシリエーション

- 16.3.1.2 アカウント・ステータスのリコンシリエーション

- 16.3.1.3 完全リコンシリエーションおよび増分リコンシリエーション

- 16.3.1.4 バッチ・リコンシリエーション

- 16.3.1.5 複数値属性データ(子データ)の削除のリコンシリエーション

- 16.3.1.6 リコンシリエーション停止の失敗しきい値

- 16.3.2 その他の機能

- 16.3.2.1 カスタム・データ・フィールドおよびフィールド・マッピング

- 16.3.2.2 カスタム・プロバイダ

- 16.3.2.3 多言語サポート

- 16.3.2.4 カスタム日付書式

- 16.3.2.5 Oracle Identity Managerユーザー属性に対する変更のターゲット・システムへの伝播

- 16.4 汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト

- 16.4.1 「リコンシリエーション」と「プロビジョニング」の両方の選択

- 16.4.2 「リコンシリエーション」のみの選択

- 16.4.3 「プロビジョニング」のみの選択

- 16.5 このマニュアルでの汎用テクノロジ・コネクタに関する情報のロードマップ

17 汎用テクノロジ・コネクタ用事前定義済プロバイダ

- 17.1 共有ドライブ・リコンシリエーション・トランスポート・プロバイダ

- 17.2 CSVリコンシリエーション・フォーマット・プロバイダ

- 17.3 SPMLプロビジョニング・フォーマット・プロバイダ

- 17.3.1 ランタイム・パラメータ

- 17.3.2 設計パラメータ

- 17.3.3 必須でないパラメータ

- 17.3.4 値が事前定義済のパラメータ

- 17.4 Webサービス・プロビジョニング・トランスポート・プロバイダ

- 17.4.1 Oracle Identity Managerとターゲット・システムWebサービスの間のSSL通信の構成

- 17.5 変換プロバイダ

- 17.5.1 連結変換プロバイダ

- 17.5.2 翻訳変換プロバイダ

- 17.5.2.1 アカウント・ステータスのリコンシリエーションの構成

- 17.6 検証プロバイダ

18 汎用テクノロジ・コネクタ用カスタム・プロバイダの作成

- 18.1 プロバイダの役割

- 18.1.1 汎用テクノロジ・コネクタ作成中のプロバイダの役割

- 18.1.2 リコンシリエーション中のプロバイダの役割

- 18.1.3 プロビジョニング中のプロバイダの役割

- 18.2 カスタム・プロバイダの作成

- 18.2.1 プロバイダ要件の確認

- 18.2.1.1 リコンシリエーション・プロバイダ要件の確認

- 18.2.1.2 プロビジョニング・プロバイダ要件の確認

- 18.2.2 プロバイダ・パラメータの識別

- 18.2.3 値オブジェクトのJavaコード実装の開発

- 18.2.4 プロバイダSPIメソッドのJavaコード実装の開発

- 18.2.5 ロギングおよび例外処理のJavaコードの開発

- 18.2.6 プロバイダXMLファイルの作成

- 18.2.7 プロバイダのリソース・バンドル・エントリの作成

- 18.2.8 プロバイダのデプロイ

- 18.3 プロバイダの再利用

- 18.3.1 リコンシリエーション・プロバイダの再利用

- 18.3.2 プロビジョニング・プロバイダの再利用

- 18.4 カスタム・プロバイダのデプロイ

19 汎用テクノロジ・コネクタの作成および管理

- 19.1 概要

- 19.2 汎用テクノロジ・コネクタの作成

- 19.2.1 プロバイダ要件の確認

- 19.2.2 組み込むプロバイダの選択

- 19.2.3 前提条件への対応

- 19.2.4 Identity System Administrationを使用したコネクタの作成

- 19.2.4.1 「ステップ1: 基本情報の指定」ページ

- 19.2.4.2 「ステップ2: パラメータ値の指定」ページ

- 19.2.4.3 「ステップ3: コネクタ構成の変更」ページ

- 19.2.4.4 「ステップ4: コネクタ・フォーム名の検証」ページ

- 19.2.4.5 「ステップ5: コネクタ情報の検証」ページ

- 19.2.5 リコンシリエーションの構成

- 19.2.6 プロビジョニングの構成

- 19.2.7 フォームの作成とアプリケーション・インスタンスの公開

- 19.2.8 ロギングの有効化

- 19.3 汎用テクノロジ・コネクタの管理

- 19.3.1 汎用テクノロジ・コネクタの変更

- 19.3.2 汎用テクノロジ・コネクタのエクスポート

- 19.3.3 汎用テクノロジ・コネクタのインポート

- 19.4 カスタム・コネクタでの汎用接続プール・フレームワークの使用

- 19.4.1 ResourceConnectionインタフェースの具体的な実装の指定

- 19.4.2 追加のITResourceパラメータの定義

- 19.4.3 プールからの接続の取得およびリリース

- 19.4.4 サード・パーティ・プールの使用

- 19.4.5 例: ResourceConnectionの実装

- 19.5 ベスト・プラクティス

- 19.5.1 「基本情報の指定」ページの使用

- 19.5.2 「パラメータ値の指定」ページの使用

- 19.5.3 「コネクタ構成の変更」ページの使用

- 19.5.3.1 フィールドの名前

- 19.5.3.2 パスワード・フィールド

- 19.5.3.3 パスワード型フィールド

- 19.5.3.4 マッピング

- 19.5.3.5 「Oracle Identity Manager」データセット

- 19.5.4 共有ドライブ・リコンシリエーション・トランスポート・プロバイダの使用

- 19.5.5 カスタム・プロバイダの使用

- 19.5.6 コネクタ・オブジェクトの使用

- 19.5.7 汎用テクノロジ・コネクタの変更

20 汎用テクノロジ・コネクタのトラブルシューティング

- 20.1 汎用テクノロジ・コネクタに関する一般的な問題

- 20.1.1 作成の問題

- 20.1.2 多言語サポート

- 20.1.3 その他の一般的な問題

- 20.2 汎用テクノロジ・コネクタの構成に関する問題

- 20.2.1 汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前

- 20.2.2 「ステップ3: コネクタ構成の変更」ページ

- 20.2.3 コネクタ作成中のエラー

- 20.2.4 リコンシリエーション中のエラー

- 20.2.5 プロビジョニング中のエラー

第IV部 リクエストおよび承認プロセス

21 承認および手動プロビジョニングのワークフローの開発

- 21.1 ワークフローの概要

- 21.1.1 ワークフローの概要

- 21.1.2 ワークフローの概念

- 21.1.3 ワークフローのアーキテクチャ

- 21.2 新しいSOAコンポジットの作成

- 21.2.1 新しいSOAコンポジットの作成

- 21.2.2 SOAコンポジットのOracle SOAサーバーへのデプロイ

- 21.2.3 SSLモードでのOracle Identity Managerとの通信のための前提条件

- 21.3 ワークフローの開発: Vision社のリクエストのチュートリアル

- 21.3.1 チュートリアルの概要

- 21.3.2 前提条件

- 21.3.2.1 リクエストWebサービスのデプロイ

- 21.3.2.2 Webサービスの保護

- 21.3.3 アプリケーション・インスタンスの作成

- 21.3.3.1 FinAppアプリケーション・インスタンスの作成

- 21.3.3.2 アプリケーション・インスタンス属性の定義とフォームの作成

- 21.3.3.3 1つ以上の組織へのアプリケーション・インスタンスの公開

- 21.3.3.4 アプリケーション・インスタンスへの権限のリンク

- 21.3.3.5 カタログへのアプリケーション・インスタンスおよび権限の公開

- 21.3.4 カタログでのFinAppの構成

- 21.3.5 承認用SOAコンポジットの作成と構成

- 21.3.5.1 承認ワークフローの作成

- 21.3.5.2 WSDLおよびXSDファイルのコピー

- 21.3.5.3 パートナ・リンクの構成

- 21.3.5.4 BPELプロセスに対するリクエストおよびカタログ・データの使用可能化

- 21.3.5.5 ワークフローの選択の構成

- 21.3.5.6 ヒューマン・タスクの構成

- 21.3.5.7 ヒューマン・タスクとBPELのマッピングの構成

- 21.3.5.8 SOAコンポジットのデプロイ

- 21.3.5.9 承認ポリシーの作成

- 21.4 デフォルトのリクエスト・レベルおよび操作レベルの承認コンポジットの構成

- 21.5 カスタム・タスク詳細タスクフローの作成およびデプロイ

- 21.5.1 カスタム・タスク詳細タスクフローを開発するための前提条件

- 21.5.2 カスタム・タスク詳細タスクフローの開発

- 21.5.3 電子メール通知のカスタム・タスク詳細の開発(オプション)

- 21.5.4 タスク詳細タスクフローのデプロイ

- 21.5.5 ヒューマン・タスクとタスクフロー権限の構成

- 21.5.6 カスタム・タスクフローのテスト

- 21.6 リクエスト・データセットの理解

- 21.7 リクエスト管理操作の拡張

- 21.7.1 リクエスト・ステータス変更に基づくカスタム・コードの実行

- 21.7.2 リクエスト・データの検証

- 21.7.3 リクエスト作成時の属性値の事前移入

- 21.8 自己登録リクエストの自動承認の有効化

22 職務の分離(SoD)の使用

- 22.1 SoD検証プロセスの理解

- 22.2 SoD起動ライブラリの概要

- 22.3 SoD対応コネクタのインストール

- 22.4 SILおよびSILプロバイダのデプロイ

- 22.5 SoDエンジンの構成

- 22.5.1 Oracle Application Access Controls Governorの構成

- 22.5.2 SAP GRCの構成

- 22.5.3 Oracle Identity Analyticsの構成

- 22.6 SoDの有効化および無効化

- 22.6.1 SoDの有効化

- 22.6.2 SoDの無効化

- 22.7 SSL通信の有効化

- 22.7.1 Oracle Application Access Controls GovernorとOracle Identity Manager間のSSLの有効化

- 22.7.2 SAP GRCとOracle Identity Manager間のSSLの有効化

- 22.7.3 SSL経由でのSoDチェックWebサービスのコール

- 22.8 SoD非対応コネクタでのワークフローの構成

- 22.8.1 SoD用の承認ワークフローの変更

- 22.8.2 SoD用のプロビジョニング・ワークフローの変更

- 22.9 権限データを保持する子プロセス・フォーム表のマーク

- 22.9.1 権限データを保持するリクエスト・データセット属性のマーク

- 22.9.2 権限データを保持する子プロセス・フォーム表のマーク

- 22.10 ターゲット・システムおよびSoDエンジンのカスタムの組合せ

- 22.10.1 カスタム・ターゲット・システムの使用

- 22.10.1.1 前提条件への対応

- 22.10.1.2 変換レイヤーの作成

- 22.10.1.3 変換レイヤーのデプロイ

- 22.10.1.4 登録XMLファイルの変更

- 22.10.1.5 新規ターゲット・システムの登録

- 22.10.2 カスタムSoDエンジンの追加

- 22.10.2.1 前提条件への対応

- 22.10.2.2 SoDエンジンの情報を保持するためのITリソースの作成

- 22.10.2.3 プロバイダ用サービス・コンポーネントの実装

- 22.10.2.4 サービス・コンポーネントのデプロイ

- 22.10.2.5 新規SoDエンジン用登録XMLファイルの変更

- 22.10.2.6 新規SILプロバイダの登録

- 22.11 Oracle Identity AnalyticsによるロールSoDチェックの実行

- 22.11.1 ロールSoDチェックの有効化

- 22.11.2 ロールSoDチェックの使用

- 22.11.2.1 ユーザーがロールをリクエストする場合のSoDチェック

- 22.11.2.2 ユーザーがロールを削除する場合のSoDチェック

- 22.11.2.3 管理者がロールの割当てをリクエストする場合のSoDチェック

- 22.11.2.4 管理者がロールの削除をリクエストする場合のSoDチェック

- 22.12 プロビジョニング・ワークフローでのSoDの使用

- 22.12.1 アプリケーション・インスタンスと子データのプロビジョニング

- 22.12.2 アプリケーション・インスタンスの変更による子データの追加または削除

- 22.12.3 ユーザーへの権限のプロビジョニング

- 22.12.4 ユーザーの権限の失効

- 22.12.5 ロールおよび権限のリクエスト

- 22.12.6 ロールおよびアプリケーション・インスタンスと子データのリクエスト

- 22.12.7 DefaultSODApprovalワークフローによるリクエスト・プロビジョニング

- 22.12.8 アクセス・ポリシーがアタッチされたロールのリクエスト

- 22.12.9 承認なしのアクセス・ポリシーに基づくプロビジョニング

- 22.12.10 承認ありのアクセス・ポリシーに基づくプロビジョニング

- 22.12.11 2つのアプリケーション・インスタンスからの権限のリクエスト

- 22.13 SoD関連イベントのロギングの有効化

- 22.14 SoDチェックのトラブルシューティング

第V部 データの同期化

23 リコンシリエーションのカスタマイズ

- 23.1 リコンシリエーションの機能

- 23.1.1 パフォーマンス強化の機能

- 23.1.1.1 新しいメタデータ・モデル - プロファイル

- 23.1.1.2制御フローとイベントの処理のパラメータ

- 23.1.1.3 リコンシリエーション実行によるイベントのグループ化

- 23.1.1.4 バッチによるイベントのグループ化

- 23.1.1.5 リコンシリエーション・エンジン・ロジックのデータベースでの実装

- 23.1.1.6 改善されたJavaエンジン

- 23.1.1.7 改善されたデータベース・スキーマ

- 23.1.2 Webベースのイベント管理インタフェース

- 23.1.3 その他の機能

- 23.1.3.1 ステージング表

- 23.1.3.2 競合状態の処理

- 23.1.3.3 非定型リンク

- 23.2 リコンシリエーションのアーキテクチャ

- 23.2.1 リコンシリエーション・プロファイル

- 23.2.2 リコンシリエーション・メタデータ

- 23.2.3 リコンシリエーション・ターゲット

- 23.2.4 リコンシリエーション実行

- 23.2.5 リコンシリエーションAPI

- 23.2.6 リコンシリエーション・スキーマ

- 23.2.7 リコンシリエーション・エンジン

- 23.2.7.1 照合モジュール

- 23.2.7.2 アクション・モジュール

- 23.2.8 リコンシリエーションのコネクタ

- 23.2.9 アーカイブ

- 23.2.10 下位互換性

- 23.2.11 リコンシリエーション・イベントの管理

- 23.3 リコンシリエーション・ルールの定義

- 23.3.1 リコンシリエーション・ルールの定義

- 23.3.2 ルール要素の追加

- 23.3.3 ルール内でのルールのネスト

- 23.3.4 ルール要素またはルールの削除

- 23.4 リコンシリエーションのスケジュール済タスクの開発

- 23.5 リコンシリエーション・プロファイルの手動による更新

- 23.5.1 リコンシリエーション・プロファイルの作成および更新

- 23.5.2 プロファイル・モードの変更

- 23.6 リコンシリエーションAPIの理解

- 23.6.1 ReconOperationsService API

- 23.6.2 マルチスレッド環境における非スケジュール済タスクベース・リコンシリエーションの呼出し

- 23.7 信頼できるリコンシリエーションの後処理

- 23.8 リコンシリエーションのトラブルシューティング

- 23.8.1 一般的なリコンシリエーション問題のトラブルシューティング

- 23.8.2 データベース関連のリコンシリエーション問題のトラブルシューティング

- 23.8.3 リコンシリエーション・プロファイル構成の失敗のトラブルシューティング

- 23.9 RECON_EXCEPTIONS表へデータ移入

- 23.10 リコンシリエーションのベスト・プラクティス

- 23.10.1 照合モジュールの追加の索引要件

- 23.10.2 リコンシリエーション・パフォーマンスに関するデータベース・スキーマ統計の収集

- 23.11 DMSを使用したリコンシリエーション・パフォーマンスの監視

24 バルク・ロード・ユーティリティの使用

- 24.1 バルク・ロード・ユーティリティの機能

- 24.2 バルク・ロード・ユーティリティ実行の前提条件

- 24.2.1 バルク・ロード・ユーティリティのインストール

- 24.2.1.1 ユーティリティを構成するスクリプト

- 24.2.1.2 バルク・ロード操作中に使用される一時表

- 24.2.1.3 ユーティリティで提供されるオプション

- 24.2.2 バルク・ロード操作用のデータベースの準備

- 24.2.2.1 一時表の表領域の作成

- 24.2.2.2 Oracle Identity Manager表領域でのデータファイルの作成

- 24.3 ユーティリティの実行

- 24.4 OIMユーザー・データのロード

- 24.4.1 ユーティリティによって追加されたOIMユーザーのデフォルト・パスワードの設定

- 24.4.2 バルク・ロード操作用の入力ソースの作成

- 24.4.2.1 入力ソースとしてのCSVファイルの使用

- 24.4.2.2 入力ソースとしてのデータベース表の作成

- 24.4.3 ユーティリティの入力パラメータの値の確認

- 24.4.4 操作の進捗の監視

- 24.4.5 操作中に記録された例外の処理

- 24.4.6 例外の修正およびデータ・レコードのリロード

- 24.4.7 バルク・ロード操作の結果の検証

- 24.4.8 監査スナップショットの生成

- 24.5 アカウント・データのロード

- 24.5.1 バルク・ロード操作用の入力ソースの作成

- 24.5.1.1 入力ソースとしてのCSVファイルの使用

- 24.5.1.2 入力ソースとしてのデータベース表の作成

- 24.5.2 ユーティリティの入力パラメータの値の確認

- 24.5.3 操作の進捗の監視

- 24.5.4 操作中に記録された例外の処理

- 24.5.5 例外の修正およびデータ・レコードのリロード

- 24.5.6 バルク・ロード操作の結果の検証

- 24.6 ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロード

- 24.6.1 バルク・ロード操作用の入力ソースの作成

- 24.6.1.1 入力ソースとしてのCSVファイルの使用

- 24.6.1.2 入力ソースとしてのデータベース表の作成

- 24.6.1.3 ロール・ロード後に生成されるUGP_NAMEの確認

- 24.6.2 ユーティリティの入力パラメータの値の確認

- 24.6.3 操作の進捗の監視

- 24.6.4 操作中に記録された例外の処理

- 24.6.5 例外の修正およびデータ・レコードのリロード

- 24.6.6 バルク・ロード操作の結果の検証

- 24.7 操作中に記録されるデータ

- 24.8 バルク・ロード操作からの診断データの収集

- 24.9 バルク・ロード操作後のクリーンアップ

25 LDAPコンテナ・ルールの構成

26 スケジュール済タスクの開発

- 26.1 タスク作成の概要

- 26.1.1 タスク作成の手順

- 26.1.2 スケジュール済タスクの例

- 26.2 スケジュール済タスクのメタデータの定義

- 26.3 スケジュール済タスクXMLファイルの構成

- 26.4 スケジュール済タスク・クラスの開発

- 26.5 プラグインXMLファイルの構成

- 26.6 スケジュール済タスクのディレクトリ構造の作成

- 26.7 スケジュール済タスクの構成ファイル

- 26.7.1 スケジューラXMLファイルの構造

- 26.7.2 scheduledTasks要素

- 26.7.3 task要素

- 26.7.4 name要素

- 26.7.5 class要素

- 26.7.6 description要素

- 26.7.7 retry要素

- 26.7.8 parameters要素

- 26.7.9 string-param要素

- 26.7.10 number-param要素

- 26.7.11 boolean-param要素

- 26.8 カスタムのスケジュール済タスクを作成するためのベスト・プラクティス

- 26.9 isStop()メソッドの使用

第VI部 カスタム操作

27 プラグインの開発

- 27.1 プラグインおよびプラグイン・ポイント

- 27.1.1 プラグインおよびイベント・ハンドラ

- 27.1.2 プラグイン・ストア

- 27.1.2.1 ファイル・ストア

- 27.1.2.2 データベース・ストア

- 27.2 デプロイメントでのプラグインの使用

- 27.3 プラグイン・ポイント

- 27.4 プラグインの構成

- 27.5 カスタム・プラグインの開発

- 27.5.1 プラグインの開発

- 27.5.2 プラグインの宣言

- 27.6 プラグインの登録

- 27.6.1 APIを使用したプラグインの登録および登録解除

- 27.6.2 プラグイン登録ユーティリティを使用したプラグインの登録および登録解除

- 27.7 プラグインの移行

28 イベント・ハンドラの開発

- 28.1 編成の概念

- 28.2 カスタム・イベント・ハンドラの使用

- 28.3 カスタム・イベント・ハンドラの開発

- 28.3.1 SPIの実装およびJARの作成

- 28.3.1.1 開発に関する考慮事項

- 28.3.1.2 メソッドおよび引数

- 28.3.1.3 コード例

- 28.3.1.4 カスタム・イベント・ハンドラ・コードを使用したJARファイルの作成

- 28.3.1.5 例外の処理

- 28.3.1.6 トランザクションの管理

- 28.3.2 カスタム・イベント定義XMLの定義

- 28.3.2.1 イベント・ハンドラXMLファイルの要素

- 28.3.2.2 イベント定義の例

- 28.3.3 プラグインZIPの作成および登録

- 28.4 イベント・ハンドラの実行の順序付け

- 28.5 カスタム検証イベント・ハンドラの作成

- 28.6 ベスト・プラクティス

- 28.7 イベント・ハンドラの移行

- 28.8 イベント・ハンドラのトラブルシューティング

- 28.9 Design Consoleを使用したイベント・ハンドラの管理

- 28.9.1 「イベント・ハンドラ・マネージャ」フォーム

- 28.9.2 「データ・オブジェクト・マネージャ」フォーム

- 28.9.2.1 「データ・オブジェクト・マネージャ」フォームのタブ

29 コンテキストの理解

- 29.1 子コンテキスト

- 29.2 コンテキスト・タイプ

第VII部 カスタマイズ

30 インタフェースのカスタマイズ

- 30.1 カスタマイズの概念

- 30.1.1 UIライブラリおよびアプリケーションのデプロイ

- 30.1.2 MDSカスタマイズの概要

- 30.1.3 Web Composerの概要

- 30.2 サンドボックスの管理

- 30.2.1 同時実行の競合への対処

- 30.2.1.1 同時実行性の問題のトラブルシューティング

- 30.2.2 サンドボックスの作成

- 30.2.3 サンドボックスのアクティブ化および非アクティブ化

- 30.2.4 サンドボックスの詳細の表示および変更

- 30.2.5 サンドボックスのエクスポートおよびインポート

- 30.2.6 サンドボックスの公開

- 30.2.7 カートからのアイテムのチェックアウト

- 30.2.8 サンドボックスの削除

- 30.2.9 変更をデフォルト設定に戻す

- 30.3 Oracle Identity Managerでのスキンのカスタマイズ

- 30.3.1 新しいスキンの構成

- 30.3.2 レガシー拡張コンソールのスキンの構成

- 30.3.3 ブランドおよびロゴの変更

- 30.4 実行時のページのカスタマイズ

- 30.4.1 UIカスタマイズでの式言語の使用

- 30.4.1.1 ユーザー・コンテキストで使用可能なEL式

- 30.4.1.2 RequestFormContextで使用可能なEL式

- 30.4.1.3 リソース文字列の国際化

- 30.4.2 UIコンポーネントの条件付き表示または非表示

- 30.4.3 リクエスト・プロファイルの条件付き表示

- 30.4.4 ADFバリデータを使用した入力データの検証

- 30.4.5 必要に応じた入力属性のマーキング

- 30.4.6 リンクまたはボタンの追加

- 30.4.7 ADFコンポーネントの非表示および削除

- 30.4.8 属性の表示および非表示

- 30.4.9 ユーザー登録とその他の認証されていないページのカスタマイズ

- 30.4.10 証明ページのカスタマイズ

- 30.5 UIコンポーネントの保護

- 30.5.1 APMを使用したカスタム・タスクフローの保護

- 30.5.2 EL式を使用したタスク・フロー・リージョンの保護

- 30.6 Oracle Identity Managerヘルプのカスタマイズ

- 30.6.1 カスタム・ヘルプ・トピックの追加

- 30.6.2 インライン・ヘルプの追加

- 30.7 ホーム・ページのカスタマイズ

- 30.8 チャレンジ質問のカスタマイズ

- 30.9 暫定UIのカスタマイズ

- 30.9.1 検索ドロップダウン項目のカスタマイズ

- 30.9.2 検索ドロップダウン項目数および検索結果数のカスタマイズ

- 30.10 マネージドBeanおよびタスク・フローの開発

- 30.10.1 ViewControllerプロジェクトの設定

- 30.10.2 モデル・プロジェクトの設定

- 30.10.3 カスタム・マネージドBeanの追加

- 30.10.4 Oracle Identity Managerへのカスタム・コードのデプロイ

- 30.10.5 マネージドBeanの使用

- 30.10.5.1 コンポーネントの条件付き表示

- 30.10.5.2 フィールドの条件付き事前移入

- 30.10.5.3 条件付き必須フィールドの設定

- 30.10.5.4 カスタム・フィールド検証の実装

- 30.10.5.5 カスタム・カスケードLOVの実装

- 30.10.5.6 RequestFormContextを使用したフォームのカスタマイズ

- 30.10.5.7 リクエスト・カタログの「送信」ボタンのオーバーライド

- 30.10.5.8 ホーム・ページ・ポートレットの開発

- 30.10.5.9 タスク・フローの起動

- 30.10.5.10 外部リンクの作成

- 30.10.6 リクエスト属性を移入するためのマネージドBeansの使用

- 30.10.6.1 マネージドBeansを使用したリクエスト属性の移入

- 30.10.6.2 事前移入プラグインを使用したリクエスト属性の移入

- 30.11 UIカスタマイズの移行

- 30.12 UIカスタマイズのベスト・プラクティス

- 30.13 UIカスタマイズのロールバック

第VIII部 他のアプリケーションを統合するインタフェース

31 APIの使用

- 31.1 Oracle Identity Managerサービスへのアクセス

- 31.1.1 OIMClientの使用

- 31.1.2 tcUtilityFactoryの使用

- 31.2 Oracle Identity Managerサービス

- 31.2.1 Oracle Identity Manager 11gのサービス

- 31.2.2 従来のサービスまたはユーティリティ

- 31.3 よく使用されるサービス

- 31.3.1 従来のサービスと新規サービス間のマッピング

- 31.4 Oracle Identity Manager用クライアントの開発

- 31.4.1 クライアント開発の前提条件

- 31.4.2 設定と構成

- 31.5 従来のOracle Identity Manager APIの使用

- 31.5.1 結果セット・オブジェクトの使用方法

- 31.5.2 Oracle Identity Manager例外の処理

- 31.5.3 クリーンアップ

- 31.6 コード例

32 SPMLサービスの使用

- 32.1 概要

- 32.1.1 SPMLの相互作用について

- 32.1.2 統合インタフェース

- 32.2 一般的な考慮事項

- 32.2.1 ユーザーへのSPML管理者ロールの割当て

- 32.2.2 自動承認ポリシーの作成

- 32.3 アイデンティティの作成(SPMLコア・サービス: addRequest)

- 32.4 ユーザー、ロール、属性およびロール・メンバーシップの変更(SPMLコア・サービス: modifyRequest)

- 32.5 アイデンティティまたはロールの削除(SPMLコア・サービス: deleteRequest)

- 32.6 リクエスト・ステータスの確認(SPMLコア・サービス: statusRequest)

- 32.7 使用可能なターゲットのリスト(SPMLコア・サービス: listTargets)

- 32.8 ユーザーの無効化(SPML一時停止サービス: suspendRequest)

- 32.9 ユーザーの有効化(SPML一時停止サービス: resumeRequest)

- 32.10 ユーザーがアクティブであるかどうかの確認(SPML一時停止サービス: activeRequest)

- 32.11 ユーザー名の検証(SPMLユーザー名サービス: validateUsername)

- 32.12 ユーザー名の取得(SPMLユーザー名: suggestUsername)

- 32.13 アイデンティティまたはロールの参照(SPMLコア・サービス: lookupRequest)

- 32.14 パスワードのリセット(SPMLコア・サービス: resetPasswordRequest)

- 32.15 ユーザー名ポリシーの参照(SPMLユーザー名サービス: lookupUsernamePolicy)

- 32.16 リクエストの取消し(SPML非同期サービス: cancelRequest)

- 32.17 バッチ・リクエスト(SPMLバッチ・リクエスト・サービス: batchRequest)

- 32.18 SPML Webサービスの保護

- 32.18.1 Webサービスのセキュリティについて

- 32.18.2 リクエストの例

- 32.18.3 ポリシーの適用

- 32.19 サポートされていない操作

- 32.20 SPML属性とLDAPマッピング、およびOracle Identity Managerの属性

- 32.20.1 アイデンティティのPSO属性

- 32.20.1.1 カスタム・アイデンティティ属性

- 32.20.2 ロールのPSO属性

- 32.20.2.1 カスタム・ロール属性

- 32.20.3 プリファレンス属性

- 32.20.4 Oracle Identity Managerの属性における特殊文字制限

- 32.20.4.1 すべての属性で使用可能な文字

- 32.20.4.2 パスワード・フィールドにおける特殊文字

- 32.20.4.3 一重引用符の使用

- 32.20.4.4 セミコロンの使用

- 32.20.4.5 サポートされていない特殊文字

- 32.20.5 操作データ

- 32.20.5.1 操作データを渡す場合

- 32.20.5.2 参照データを渡す場合

- 32.21 SPMLの例

- 32.21.1 SPMLの例 - ユーザーの追加

- 32.21.2 SPMLの例 - ユーザーの削除

- 32.21.3 SPMLの例 - ユーザーの変更

- 32.21.4 SPMLの例 - ユーザーの再開

- 32.21.5 SPMLの例 - ユーザー名の提案

- 32.21.6 SPMLの例 - ユーザーの一時停止

- 32.21.7 SPMLの例 - ユーザー名の検証

- 32.21.8 SPMLの例 - ユーザーがアクティブかどうかのチェック

- 32.21.9 SPMLの例 - ユーザー名ポリシーの参照

- 32.21.10 SPMLの例 – ユーザーの追加とロールの割当て

- 32.21.11 SPMLの例 - ロール・メンバーシップの割当て

- 32.21.12 SPMLの例 – ロール・メンバーシップの失効

- 32.21.13 SPMLの例 - ロールの追加

- 32.21.14 SPMLの例 - 親を持つロールの追加

- 32.21.15 SPMLの例 - ロールの変更

- 32.21.16 SPMLの例 - ロールへの親の追加

- 32.21.17 SPMLの例 - ロールの付与

- 32.21.18 SPMLの例 - ロールの削除

- 32.21.19 SPMLの例 - ステータスのリクエスト

- 32.21.20 SPMLの例 - アイデンティティ/ロールの参照

- 32.21.21 SPMLの例 - パスワードのリセット

- 32.21.22 SPMLの例 - 通知を使用したパスワードのリセット

- 32.21.23 SPMLの例 - ユーザー名ポリシーの参照

- 32.21.24 SPMLの例 - リクエストのキャンセル

- 32.21.25 SPMLの例 - バッチ・リクエスト

33 URLの使用

第IX部 通知サービス

34 通知イベントの開発

- 34.1 通知の概念

- 34.2 カスタム通知の開発

- 34.2.1 通知ロジックの構築

- 34.2.1.1 イベント・メタデータの定義

- 34.2.1.2 リゾルバ・クラスの作成

- 34.2.2 リゾルバ・クラスを含むプラグイン・パックの作成

- 34.2.3 起動ロジックの構築

- 34.2.4 通知サービスの構成

- 34.3 通知のトラブルシューティング

- 34.3.1 誤ったURLに関連する問題

- 34.3.2 送信サーバーの電子メール・ドライバの誤ったプロパティ

- 34.3.3 SOAサーバーで生成されるエラー

- 34.3.4 認証の失敗

- 34.3.5 電子メール配信の失敗がEMを介してレポートされない問題

35 コールバック・サービスの使用

- 35.1 コールバック・サービスの概要

- 35.1.1 コールバックの使用

- 35.1.2 イベント処理の理解

- 35.1.3 コールバックの再試行

- 35.2 Oracle Identity Manager属性のマッピング

- 35.3 イベント・コールバックの送信

- 35.4 コールバック・サービスの構成

- 35.4.1 CallbackConfiguration.xmlの理解

- 35.4.2 CallbackConfiguration.xmlのインポート

- 35.4.3 OIM.DefaultTenantGUIDシステム・プロパティの追加

- 35.5 コールバック・サービスのトラブルシューティング

第X部 ライフサイクルのカスタマイズ

36 カスタマイズのタイプの理解

37 カスタマイズのデプロイおよびアンデプロイ

- 37.1 ユーザーが修正可能なメタデータ・ファイルの移行

- 37.1.1 MDSへのメタデータ・ファイルのエクスポート

- 37.1.2 MDSからのメタデータ・ファイルのインポート

- 37.1.3 MDSからのメタデータ・ファイルの削除

- 37.1.4 ユーザーが修正可能なメタデータ・ファイル

- 37.1.5 MDSのバックアップの作成

- 37.2 JARおよびリソース・バンドルの移行

- 37.2.1 JARのアップロード・ユーティリティ

- 37.2.2 JARのダウンロード・ユーティリティ

- 37.2.3 JARの削除ユーティリティ

- 37.2.4 リソース・バンドルのアップロード・ユーティリティ

- 37.2.5 リソース・バンドルのダウンロード・ユーティリティ

- 37.2.6 リソース・バンドルの削除ユーティリティ

38 構成およびカスタマイズの移行

- 38.1 デプロイメント・マネージャの使用

- 38.1.1 デプロイメント・マネージャの機能

- 38.1.2 デプロイメントのエクスポート

- 38.1.3 デプロイメントのインポート

- 38.1.4 デプロイメント・マネージャの使用に関連するベスト・プラクティス

- 38.1.4.1 必要な場合にのみ行うシステム・オブジェクトのエクスポート

- 38.1.4.2 関連するオブジェクトのグループのエクスポート

- 38.1.4.3 定義データおよび操作データの個別のグループ化

- 38.1.4.4 フォーム・バージョンに対する論理的なネーミング規則の使用

- 38.1.4.5 ルートのエクスポートによる完全な組織階層の保持

- 38.1.4.6 わかりやすいエクスポートの説明

- 38.1.4.7 インポート前のすべての警告のチェック

- 38.1.4.8 データ・エクスポート前の依存性のチェック

- 38.1.4.9 一致するスケジュール済タスク・パラメータ

- 38.1.4.10 スケジュール済タスクの再インポート時のデプロイメント・マネージャの動作

- 38.1.4.11 アダプタのコンパイルおよびスケジュール済タスクの有効化

- 38.1.4.12 エンティティ・アダプタの個別のエクスポート

- 38.1.4.13 ロールの権限のチェック

- 38.1.4.14 データベースのバックアップ

- 38.1.4.15 システム静止中のデータのインポート

- 38.1.4.16 カスタム・データ・オブジェクトの移行

- 38.1.4.17 依存性としてイベント・ハンドラをインポートする前のデータ・オブジェクト・フィールドの削除

- 38.1.5 デプロイメント・マネージャのトラブルシューティング

- 38.1.5.1 デプロイメント・マネージャの問題のトラブルシューティング

- 38.1.5.2 デプロイメント・マネージャのロギングの有効化

- 38.2 移動スクリプトを使用したテスト環境から新たな本番環境への移動

- 38.3 ポリシーの移行

- 38.3.1 ポリシー移行のトラブルシューティング

第XI部 レポートおよび監査

39 レポートの構成

- 39.1 Oracle Identity Managerレポートについて

- 39.2 Oracle BI Publisherについて

- 39.3 ライセンス

- 39.4 Oracle Identity Managerレポートのデプロイ

- 39.4.1 メタデータ・リポジトリの作成

- 39.4.2 BI Publisher 11g (11.1.1.6)のインストール

- 39.5 Oracle Identity Managerレポートの構成

- 39.5.1 BI Publisher 11g (11.1.1.6)でのセキュリティの構成

- 39.5.2 Oracle Identity Managerレポートの実行のためのデータソースの構成

- 39.5.2.1 Oracle Identity Manager JDBC接続の構成

- 39.5.2.2 BPELベースのJDBC接続の構成

- 39.6 Oracle Identity Managerレポートの生成

- 39.6.1 サンプル・データソースに対するサンプル・レポートの生成

- 39.6.2 Oracle Identity Manager JDBCデータソースに対するレポートの生成

- 39.6.3 BPELベースのJDBCデータソースに対するレポートの生成

40 監査の理解

- 40.1 監査レベル

- 40.2 監査者に関する情報の格納に使用される表

- 40.3 監査メッセージの発行

第XII部 付録

A 一般的なカスタマイズの概念

- A.1 ルール要素、変数、データ型およびシステム・プロパティ

- A.2 サービス・アカウント

- A.2.1 サービス・アカウントのカスタマイズ: シナリオ1

- A.2.2 サービス・アカウントのカスタマイズ: シナリオ2

- A.3 Design Consoleのアクション

B FacesUtilsクラス

索引

例一覧

- 9-1 ConnectorInfoManagerFactoryの実装

- 9-2 ConnectorInfoManagerの実装

- 9-3 ConnectorKeyの実装

- 9-4 ConnectorInfoの実装

- 9-5 APIConfiguration定義

- 9-6 setPropertyValueメソッド・シグネチャ

- 9-7 ConfigurationPropertiesの実装

- 9-8 ConnectorFacadeFactoryの定義

- 9-9 ConnectorFacadeの実装

- 9-10 フラット・ファイル・コネクタの実装

- 9-11 initメソッドの実装

- 9-12 disposeメソッドの実装

- 9-13 getConfigurationメソッドの実装

- 9-14 構成実装

- 9-15 validateメソッドの実装

- 9-16 setConnectorMessagesメソッドの定義

- 9-17 getConnectorMessagesメソッドの定義

- 9-18 フラット・ファイルPoolableConnectorの実装

- 9-19 checkAliveメソッドの実装

- 9-20 normalizeAttributeメソッドの定義

- 9-21 schemaメソッド・シグネチャ

- 9-22 schemaメソッドの実装

- 9-23 createメソッド・シグネチャ

- 9-24 createメソッドの実装

- 9-25 deleteメソッド・シグネチャ

- 9-26 deleteメソッドの実装

- 9-27 createFilterTranslatorメソッド・シグネチャ

- 9-28 createFilterTranslatorメソッドの実装

- 9-29 executeQueryメソッド・シグネチャ

- 9-30 executeQueryメソッドの実装

- 9-31 updateメソッド・シグネチャ

- 9-32 updateメソッドの実装

- 9-33 トレース設定の定義

- 10-1 AbstractConfigurationの実装

- 10-2 PoolableConnectorの実装

- 10-3 AbstractFilterTranslator<T>の実装

- 10-4 MANIFEST.MFファイル

- 10-5 FlatFileIOFactory

- 10-6 FlatFileMetadata

- 10-7 FlatFileParser

- 10-8 FlatFileWriter

- 10-9 FlatfileLineIterator

- 10-10 FlatfileUserAccount

- 10-11 FlatfileAccountConversionHandler

- 10-12 Messages.Properties

- 10-13 スケジュール済タスク詳細が含まれたデプロイメント・マネージャXML

- 11-1 AbstractConfigurationの実装

- 11-2 PoolableConnectorの実装

- 11-3 AbstractFilterTranslator<T>の実装

- 11-4 スケジュール済タスク詳細が含まれたデプロイメント・マネージャXML

- 19-1 ResourceConnection実装の例

- 21-1 プラグインとデータ・バリデータおよび事前移入アダプタの関連付け

- 22-1 登録スクリプトの実行例

- 23-1 リコンシリエーション・プロファイルのサンプル

- 23-2 マルチスレッド環境における非スケジュール済タスクベース・リコンシリエーションの呼出し

- 24-1 OIMユーザー・データのロード後に生成されるログ・ファイルの例

- 24-2 アカウント・データのロード後に生成されるログ・ファイルの例

- 24-3 OIMロール・データのロード後に生成されるログ・ファイルの例

- 26-1 スケジュール済タスクのサンプルXML

- 26-2 スケジュール済タスクのディレクトリ構造

- 28-1 カスタム電子メール検証

- 28-2 ミドル・ネームを設定するカスタム前処理イベント・ハンドラ

- 28-3 カスタム後処理イベント・ハンドラのサンプル

- 28-4 bulkExecuteメソッドを使用するカスタム・ユーザー後処理イベント・ハンドラ

- 28-5 isApplicableメソッドでのコンテキストの使用

- 28-6 カスタム・イベント定義のサンプル・メタデータXMLファイル

- 31-1 Oracle Identity Manager情報の取得

- 35-1 サンプルCallbackConfiguration.xml

- B-1 サンプルのFacesUtilsクラス

図一覧

- 2-1 Oracle Identity Managerのアーキテクチャ

- 2-2 ICFアーキテクチャ

- 2-3 汎用テクノロジ・コネクタの機能アーキテクチャ

- 2-4 Remote Managerのアーキテクチャ

- 2-5 Oracle Identity ManagerでのSoD検証プロセス

- 2-6 リクエスト・サービスおよびSOAの統合

- 2-7 OESベースの認可サービス

- 2-8 UIカスタマイズ・フレームワーク

- 2-9 Oracle Identity Managerスケジューラのアーキテクチャ

- 2-10 Oracle Identity ManagerとLDAP

- 2-11 Oracle Identity Managerのシステム・コンポーネント

- 3-1 OESベースの認可サービス

- 3-2 OrclOIMUserViewerDirectWithObligationPolicy

- 3-3 「責任属性の編集」ダイアログ・ボックス

- 4-1 「ITリソース・タイプ定義」フォーム

- 4-2 「ルール・デザイナ」フォーム

- 4-3 「ルール・デザイナ」フォームのルール要素タブ

- 4-4 ルール要素の編集ウィンドウ

- 4-5 「ルール・デザイナ」フォームの使用方法タブ

- 4-6 ルール・デザイナ表

- 4-7 「リソース・オブジェクト」フォーム

- 4-8 信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合

- 4-9 信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合

- 4-10 子属性

- 4-11 エクスポート・サマリー

- 4-12 インポート・サマリー

- 5-1 「電子メール定義」フォーム

- 5-2 「プロセス定義」フォーム

- 5-3 「プロセス定義」フォームの「タスク」タブ

- 5-4 「プロセス定義」フォームのリコンシリエーション・フィールド・マッピング・タブ

- 5-5 ハンドラの選択ダイアログ・ボックス

- 6-1 「フォーム・デザイナ」フォーム

- 6-2 「プロパティの追加」ダイアログ・ボックス

- 6-3 値が入力された「プロパティの追加」ダイアログ・ボックス

- 6-4 「プロパティの追加」ダイアログ・ボックス

- 6-5 「プロパティの編集」ダイアログ・ボックス

- 7-1 「参照定義」フォーム

- 7-2 「Remote Manager」フォーム

- 8-1 「アダプタ・ファクトリ」フォーム

- 8-2 「アダプタ・マネージャ」フォーム

- 8-3 「エラー・メッセージ定義」フォーム

- 9-1 Identity Connector Frameworkのデプロイメント

- 9-2 ICFとコネクタ・バンドルの互換性

- 9-3 同じターゲットの複数のバージョンをサポートするデプロイメント方法

- 9-4 コネクタ・サーバーのリモート・システム・フレームワーク

- 9-5 ICFフレームワーク

- 9-6 ICFコネクタおよびコネクタ・サーバー

- 10-1 Design ConsoleのITリソース・タイプ定義

- 10-2 Design Consoleの「リソース・オブジェクト」

- 10-3 Design Consoleの「参照定義」

- 10-4 Design Consoleの2番目の「参照定義」

- 10-5 Design Consoleの「フォーム・デザイナ」

- 10-6 Design Consoleの「フォーム・デザイナ」のプロパティ

- 10-7 Design Consoleの「アダプタ・ファクトリ」の変数リスト

- 10-8 Design Consoleの「アダプタ・ファクトリ」

- 10-9 Design Consoleの「プロセス定義」

- 10-10 Design Consoleのタスクの編集画面

- 10-11 Design Consoleの「統合」タブ

- 10-12 Design Consoleでのレスポンスの構成

- 10-13 タスクとオブジェクトのステータス・マッピング

- 10-14 「スケジュール済タスク」画面

- 10-15 Design Consoleのオブジェクト・リコンシリエーション

- 10-16 Design Consoleのリコンシリエーション・アクション・ルール

- 10-17 Design Consoleのリコンシリエーション・フィールド・マッピング

- 10-18 リコンシリエーション一致ルールの追加

- 11-1 Design ConsoleのITリソース・タイプ定義

- 11-2 Design Consoleの「リソース・オブジェクト」

- 11-3 Design Consoleの「参照定義」

- 11-4 Design Consoleの2番目の「参照定義」

- 11-5 Design Consoleの「フォーム・デザイナ」

- 11-6 Design Consoleの「フォーム・デザイナ」のプロパティ

- 11-7 Design Consoleの「アダプタ・ファクトリ」の変数リスト

- 11-8 Design Consoleの「アダプタ・ファクトリ」

- 11-9 Design Consoleの「プロセス定義」

- 11-10 Design Consoleのタスクの編集画面

- 11-11 Design Consoleの「統合」タブ

- 11-12 Design Consoleでのレスポンスの構成

- 11-13 タスクとオブジェクトのステータス・マッピング

- 11-14 参照コード・マッピング

- 11-15 拡張コンソールの「スケジュール済タスク」画面

- 11-16 Design Consoleのオブジェクト・リコンシリエーション

- 11-17 Design Consoleのリコンシリエーション・アクション・ルール

- 11-18 Design Consoleのリコンシリエーション・フィールド・マッピング

- 11-19 リコンシリエーション一致ルールの追加

- 12-1 OIM-ICFコネクタ開発アーキテクチャ

- 12-2 Oracle Identity Managerコネクタ参照の階層

- 12-3 フィルタ構文のグラフィック表現

- 14-1 コネクタ・サーバーのロード・バランサ

- 16-1 汎用テクノロジ・コネクタの機能アーキテクチャ

- 17-1 SPMLプロビジョニング・フォーマット・プロバイダとターゲット・システムの間の通信

- 18-1 メタデータの検出プロセス

- 18-2 リコンシリエーション中のプロバイダの役割

- 18-3 プロビジョニング中のプロバイダの役割

- 19-1 「ステップ3: コネクタ構成の変更」ページ

- 19-2 フィールド追加後の「ステップ3: コネクタ構成の変更」ページ

- 21-1 ワークフローのアーキテクチャ

- 21-2 属性

- 21-3 属性の構成

- 21-4 権限のリスト

- 21-5 組織への権限の可用性

- 21-6 カタログ項目の属性

- 21-7 「パートナ・リンク」スイム・レーン

- 21-8 「パートナ・リンクの作成」ダイアログ・ボックス

- 21-9 「WSポリシーの構成」

- 21-10 AssignRequestWSURL

- 21-11 パートナ・リンクと操作

- 21-12 AssignRequestInput

- 21-13 入力マッピング

- 21-14 InvokeCatalogOperation

- 21-15 InvokeCatalogOperationの構成

- 21-16 AssignCatalogInput

- 21-17 InvokeCatalogOperationの入力マッピング

- 21-18 ビジネス・ルール・コンポーネントの追加

- 21-19 catalogData変数の入力マッピング

- 21-20 workflowtype変数の出力マッピング

- 21-21 AssignRuleInput

- 21-22 catalogData変数の出力マッピング

- 21-23 stageTypeプロパティ

- 21-24 承認ルール

- 21-25 Switchアクティビティ

- 21-26 Switch Caseステップ

- 21-27 名前変更済条件

- 21-28 デフォルト・ヒューマン・タスクのドラッグ

- 21-29 ヒューマン・タスクの追加

- 21-30 ManagerおよびReview Teamステージ

- 21-31 Manager参加者ルール

- 21-32 Review Teamステージ

- 21-33 Review Team参加者ルール

- 21-34 シリアル・ステージ

- 21-35 Managerステージのルール

- 21-36 Review Teamステージのルール

- 21-37 デフォルト承認タスク

- 21-38 参加者リスト・ルール

- 21-39 Human Taskアクティビティ

- 21-40 タスク・パラメータとBPEL変数のマッピング

- 図21-41 識別キーとリクエスタIDのマッピング

- 21-42 panelTabbedレイアウト

- 21-43 OIMビュー共有ライブラリ

- 21-44 タスク詳細DataControl

- 22-1 Oracle Identity ManagerでのSoD検証プロセス

- 22-2 Oracle Identity ManagerでのSoD実装のアーキテクチャ

- 22-3 TopologyNameパラメータ

- 22-4 非同期SoDチェックのリクエスト履歴

- 22-5 SoDCheck Webサービス・コールを含むワークフロー

- 22-6 承認タスクを含むSwitch Case

- 22-7 承認タスクの割当て

- 22-8 SoDチェックを実行するように変更されたワークフロー

- 22-9 SoDチェック・パートナ・リンク

- 22-10 最終的なAssignアクティビティ

- 22-11 「Invoke」ダイアログ・ボックス

- 22-12 「Receive」ダイアログ・ボックス

- 22-13 Switch Case

- 22-14 リクエストのためのWSポリシーの構成

- 22-15 クライアント・セキュリティ・ポリシーの選択

- 22-16 サーバー・セキュリティ・ポリシーの選択

- 22-17 競合する権限

- 22-18 リソース・プロビジョニングの詳細

- 22-19 リクエストの詳細内のSoDチェック結果

- 23-1 リコンシリエーションのアーキテクチャ

- 23-2 「リコンシリエーション・ルール」フォーム

- 23-3 <matchingRule>タグ要素

- 27-1 プラグインおよびイベント・ハンドラ

- 27-2 プラグインのエクスポート

- 28-1 編成ステージ

- 28-2 プラグインのエクスポート

- 28-3 「イベント・ハンドラ・マネージャ」フォーム

- 28-4 「データ・オブジェクト・マネージャ」フォーム

- 30-1 Oracle Identity Manager UIライブラリ

- 30-2 Oracle Web Composerアーキテクチャ

- 30-3 WebCenter Composerのオブジェクト・ライブラリ

- 30-4 構造ペイン

- 30-5 「コンポーネント・プロパティ」ダイアログ・ボックス

- 30-6 リンクを追加するパネルの選択

- 30-7 「コンテンツの追加」ダイアログ・ボックス

- 30-8 「子コンポーネント」タブ

- 30-9 承認されていないページへのリンク

- 30-10 ツールバーの「上にボックスを追加」アイコン

- 30-11 新しいコンテナ

- 30-12 「コンテンツの追加」ダイアログ・ボックス

- 30-13 Lookup.Weblciient.Questions参照コード

- 30-14 「パスワードを忘れた場合」ページに関するチャレンジ質問

- 32-1 承認ポリシー・ルールのサンプル

- 34-1 通知構成テスト

- 35-1 コールバック・サービス・プロセス

- 38-1 デプロイメント・マネージャのインポートの失敗

- 39-1 Oracle Identity Managerレポートのアーキテクチャ

表一覧

- 3-1 組織のスコープが指定された管理ロールと権限

- 3-2 グローバル管理ロールとグローバル権限

- 3-3 デフォルトの認可ポリシー

- 3-4 OESアプリケーション・ロールとポリシー

- 3-5 アプリケーション・ロールのマッピング

- 3-6 以前のロールと新しいロールとの間のマッピング

- 3-7 スコープされた組織内のユーザーを表示または検索する管理ロール

- 3-8 スコープされた組織内のユーザーを変更する管理ロール

- 3-9 リンクの表示を制御する管理ロール

- 3-10 誰がアプリケーション・インスタンスのアカウントをリクエストできるかの制御

- 3-11 アカウントを変更するための管理ロール

- 3-12 ユーザー・パスワードを変更するための管理ロール

- 3-13 選択済ユーザーに対する権限を持つ管理ロール

- 3-14 選択済アカウントに対する権限を有する管理ロール

- 3-15 リクエスト・ベースの操作

- 4-1 「ITリソース・タイプ定義」フォームのフィールド

- 4-2 「ルール・デザイナ」フォームのフィールド

- 4-3 ルール要素の編集ダイアログ・ボックスのフィールド

- 4-4 ルール・デザイナ表の情報

- 4-5 「リソース・オブジェクト」フォームのフィールド

- 4-6 ルール条件と使用可能なルール・アクション

- 5-1 「電子メール定義」フォームのフィールド

- 5-2 「プロセス定義」フォームのフィールド

- 5-3 タスクの編集ダイアログ・ボックスの「一般」タブのフィールド

- 5-4 タスクの編集ウィンドウの「割当て」タブのフィールド

- 6-1 「フォーム・デザイナ」フォームのフィールド

- 6-2 「追加列」タブのフィールド

- 6-3 「プロパティの追加」ダイアログ・ボックスのフィールド

- 6-4 「プロパティの追加」ダイアログ・ボックスのフィールド

- 7-1 「参照定義」フォームのフィールド

- 8-1 「マップ先」メニューの項目

- 8-2 オブジェクト・インスタンスの選択ウィンドウのオプション

- 8-3 アダプタ・ファクトリ・タスクの追加ウィンドウのリージョン

- 8-4 アダプタ・ファクトリ・タスクの追加ウィンドウのリージョン

- 8-5 オペランドのタイプ

- 8-6 特定の条件文から発生するアクション

- 8-7 アダプタ・ファクトリ・ロジック・タスクの追加ウィンドウのリージョン

- 8-8 FOR条件文の場合のアダプタ・ファクトリ・ロジック・タスク・パラメータの追加

- 8-9 変数のデータ・マッピング・ダイアログ・ボックスのフィールド

- 8-10 変数のデータ・マッピングの編集ダイアログ・ボックスのフィールド

- 8-11 「事前移入アダプタ」ダイアログ・ボックスのフィールド

- 8-12 アダプタ変数のマップ・ウィンドウのフィールド

- 8-13 変数のデータ・マッピング・ウィンドウのフィールド

- 8-14 「エラー・メッセージ定義」フォームのフィールド

- 9-1 ConnectorServer.propertiesファイル内のプロパティ

- 9-2 ConnectorServer.batスクリプトでサポートされているオプション

- 9-3 connectorserver.shスクリプトでサポートされているオプション

- 10-1 「フォーム・デザイナ」のフィールド

- 11-1 「フォーム・デザイナ」のフィールド

- 12-1 コネクタの参照構成

- 12-2 コネクタのユーザー管理参照構成

- 12-3 リコンシリエーション変換参照

- 12-4 リコンシリエーション検証参照

- 12-5 Lookup.CONNECTOR_NAME.UM.Recon.Defaults.Trusted属性

- 12-6 ITリソースのパラメータ

- 12-7 プロビジョニング参照属性

- 12-8 コネクタの構成参照

- 12-9 ICF共通のリコンシリエーション・パラメータ

- 12-10 共通のグループ参照パラメータ

- 12-11 Lookup.CONNECTOR_NAME.UM.ReconAttrMapの属性マッピング

- 12-12 アイデンティティ・コネクタの参照リコンシリエーション属性

- 12-13 アイデンティティ・コネクタのターゲット検索リコンシリエーション属性

- 12-14 アイデンティティ・コネクタのターゲット検索削除リコンシリエーション属性

- 12-15 アイデンティティ・コネクタのターゲット同期リコンシリエーション属性

- 12-16 フィルタ属性のキーワードと構文

- 17-1 検証プロバイダ

- 18-1 プロバイダ操作中に使用される値オブジェクト

- 18-2 サポートされる各プロバイダ・タイプに固有のロギング・モジュール

- 18-3 プロバイダXMLファイルの要素

- 19-1 「ステップ1: 基本情報の指定」ページのサンプル・エントリ

- 19-2 「ステップ2: パラメータ値の指定」ページのサンプル・エントリ

- 19-3 様々な入力条件によるデータセットおよびフィールドの表示

- 19-4 参照プロパティ

- 19-5 ResourceConnectionのメソッド

- 19-6 ITResourceパラメータ

- 19-7 GenericPoolインタフェースのメソッド

- 20-1 リコンシリエーション中に発生する一般的なエラー

- 20-2 プロビジョニング中に発生する一般的なエラー

- 21-1 Oracle Identity Managerに付属のデフォルトのリクエスト・データセット

- 22-1 割り当てる変数

- 22-2 SoDチェックのトラブルシューティング

- 23-1 リコンシリエーション・プロファイルXMLの要素

- 23-2 リコンシリエーションのステータス・イベント

- 23-3 アクション・ルール

- 23-4 変換プロパティ

- 23-5 リコンシリエーションのトラブルシューティング

- 23-6 リコンシリエーション・プロファイル構成の失敗のトラブルシューティング

- 24-1 サンプル・データベース表の構造

- 24-2 サンプル・データベース表の構造

- 24-3 サンプルの子データベース表の構造

- 24-4 サンプル・データベース表の構造

- 24-5 OIM_BLKLD_LOG表の構造

- 26-1 scheduledTasks要素のプロパティ

- 26-2 task要素のプロパティ

- 26-3 name要素のプロパティ

- 26-4 class要素のプロパティ

- 26-5 description要素のプロパティ

- 26-6 retry要素のプロパティ

- 26-7 parameters要素のプロパティ

- 26-8 string-param要素のプロパティ

- 26-9 number-param要素のプロパティ

- 26-10 boolean-param要素のプロパティ

- 26-11 カスタムのスケジュール済タスクを作成するための変数および定数

- 27-1 プラグイン・ポイント

- 28-1 イベント・ハンドラを実装するためのメソッド

- 28-2 カスタム・イベント・ハンドラを作成するためのSPI

- 28-3 eventhandlers要素内の一般的なサブ要素

- 28-4 eventhandlers要素内のサブ要素の一般的な属性

- 28-5 イベント・ハンドラのトラブルシューティング

- 28-6 「イベント・ハンドラ・マネージャ」フォームのフィールド

- 28-7 「データ・オブジェクト・マネージャ」フォームのフィールド

- 30-1 同時実行性の問題のトラブルシューティング

- 30-2 カスタマイズ可能なエンティティ・アーティファクト

- 30-3 ユーザー・コンテキストのEL式

- 30-4 RequestFormContextに関わるEL式

- 30-5 ADFバリデータ

- 30-6 検索ページのメニュー数を決定するプロパティ

- 31-1 よく使用されるサービス

- 31-2 従来のサービスと新規サービス間のマッピング

- 32-1 addRequestによるアイデンティティ作成

- 32-2 modifyRequestによるロール・メンバーシップ管理

- 32-3 deleteRequestによるロール・メンバーシップの削除

- 32-4 リクエスト・ステータスの確認

- 32-5 listTargetsによるターゲットの取得

- 32-6 suspendRequestによるユーザーの一時停止

- 32-7 resumeRequestによるユーザーの再有効化

- 32-8 activeRequestによるユーザーが一時停止されているかどうかの確認

- 32-9 resumeRequestによるユーザー名の有効性の確認

- 32-10 suggestUsernameによるユーザー名の取得

- 32-11 lookupRequestを使用したアイデンティティ/ロールの参照

- 32-12 resetPasswordRequestを使用したユーザー・パスワードのリセット

- 32-13 lookupUsernamePolicyを使用したユーザー名ポリシーの詳細の参照

- 32-14 cancelRequestを使用したリクエストのキャンセル

- 32-15 batchRequestを使用したバッチ・リクエストの実行

- 32-16 アイデンティティのPSO属性

- 32-17 employeeTypeの有効な値

- 32-18 ロールのPSO属性

- 32-19 プリファレンス属性

- 33-1 タスク・フローおよびダイレクトURL

- 35-1 Oracle Identity Managerとコールバック・サービス・ユーザー属性のマッピング

- 35-2 Oracle Identity Managerとコールバック・サービス・ロール属性のマッピング

- 35-3 コールバック開始イベント

- 35-4 コールバック・サービスのトラブルシューティング

- 36-1 Oracle Identity Managerアーティファクトおよびユーティリティのタイプ

- 38-1 パラメータのインポート・ルール

- 38-2 デプロイメント・マネージャのトラブルシューティング

- 38-3 ポリシー移行のトラブルシューティング

- A-1 Oracle Identity Managerのルールを作成するためのルール要素

- A-2 テンプレートを作成するための変数

- A-3 Oracle Identity Managerフォーム作成用のデータ型に関連付けるプロパティ

- A-4 サービス・アカウントの管理タスクと対応するAPI

- A-5 Oracle Identity Managerのアクション、条件および結果

はじめに

Oracle Fusion Middleware Oracle Identity Manager開発者ガイドでは、Oracle Identity Managerの様々なコンポーネントおよび機能を開発およびカスタマイズする方法について説明します。

対象読者

このガイドは、Oracle Identity Manager開発ツールを使用し、組織の要件に従って製品をカスタマイズする開発者を対象としています。カスタマイズには、APIの使用、リクエストおよび承認ワークフローの構成、アイデンティティ・コネクタ・フレームワーク、汎用テクノロジ・コネクタまたはアダプタ・ファクトリを使用したコネクタの開発、およびユーザー・インタフェースのカスタマイズが含まれます。

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

オラクル社のアクセシビリティへの取組みの詳細は、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 Identity Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド

- Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド

- Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middlewareスイート統合概要

- Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middleware Oracle Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド

- Oracle Fusion Middleware Oracle Identity Navigator管理者ガイド

- Oracle Fusion Middleware Authorization Policy Manager管理者ガイド

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第I部

概念

この部では、Oracle Identity Managerアーキテクチャおよびセキュリティに関連する概念を説明します。

次の章で構成されます。

- 第1章「製品の概要」

- 第2章「製品のアーキテクチャ」

- 第3章「セキュリティのアーキテクチャ」

1 製品の概要

Oracle Identity Managerは、ユーザー、ロール、アカウントおよび権限を制御することによって、社内ITリソースのユーザーのアクセス権限を管理するエンタープライズ・アイデンティティ管理システムです。プロビジョニング、アイデンティティとロールの管理、承認とリクエストの管理、ポリシーベースの権限管理、テクノロジの統合および監査とコンプライアンスの自動化の機能を持ちます。Oracle Identity Managerは、イントラネットおよびエクストラネット・ユーザー、ロール、組織のアクセス権限を、アイデンティティ管理ライフサイクル全体を通じて、社内リソース全体で管理するように設計されています。

Oracle Identity Managerプラットフォームでは、アクセス権の管理、セキュリティおよびITリソースのプロビジョニングが自動化されています。ユーザーをリソースに接続し、機密性の高い企業情報を保護するために不正アクセスを無効化し、制限します。

この章の内容は次のとおりです。

- 主な特長と利点

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

1.1 主な特長と利点

Oracle Identity Managerのアーキテクチャは柔軟でスケーラブルであり、次の特長があります。

- デプロイの容易性

- UIのカスタマイズの簡略化

- 構成の簡略化

- 柔軟性と耐性

- 既存のインフラストラクチャを最大限に再利用

- 広範なユーザー管理

- Webベースのユーザー・セルフサービス

- モジュール型のスケーラブルなアーキテクチャ

- 主要なソフトウェア開発標準への準拠

- 強力で柔軟性の高いプロセス・エンジン

- 組込みの変更管理

- ワークフローおよびポリシー

- 監査およびコンプライアンス管理

- 統合ソリューション

- ユーザー・プロビジョニング

1.1.1 デプロイの容易性

Oracle Identity Managerは柔軟なデプロイメント・マネージャ・ユーティリティを備え、複数の環境間での統合および構成情報の移行を支援します。このユーティリティは、統合および構成情報をXMLファイルとしてエクスポートします。これらのファイルは、その後、宛先の環境(ステージング環境や本番環境)にインポートされます。XMLファイルは、構成のアーカイブやバージョン管理、統合のレプリケートに使用できます。

デプロイメント・マネージャにより、インポートおよびエクスポートの対象を柔軟に選択できます。また、インポートとエクスポートのどちらの手順でも、データ・オブジェクトの依存関係を簡単に確認できます。このような柔軟性により、複数のユーザーによって行われた統合作業のマージが可能になり、移行の整合性が保証されます。

1.1.2 UIのカスタマイズの簡略化

Oracle Identity Managerでは、コードの記述が不要で、開発者に依存する必要のないブラウザベースのカスタマイズ・フレームワークが提供されています。このインタフェースはApplication Development Framework (ADF)に基づいており、すべてのカスタマイズに一貫性があり、アップグレードおよびパッチからも保護されます。ブラウザベースのカスタマイズは、Oracle Web Composerを使用して実行できます。

Oracle Identity Managerでは、ユーザーが検索頻度の高い項目の保存と再利用、検索結果表の列の構成、データのソートとフィルタ処理を実行できるため、ビジネスフレンドリなユーザー・パーソナライズが可能になります。

1.1.3 構成の簡略化

Oracle Identity Managerでは、すべてのエンティティのビジネス・ユーザーフレンドリな拡張フレームワークを使用することで、構成の複雑さを抽象化および簡略化されています。これによって、ユーザーはフォーム・デザイナを使用してユーザー、ロール、組織、カタログおよびリソース・スキーマを拡張できます。また、接続なしアプリケーションの管理については、Design Consoleで面倒な構成を行うのではなく、Webブラウザ・ベースで実行可能になります。Oracle Identity Managerに埋め込まれるSOA Tasklistによって、接続なしリソースのプロビジョニングを手動で実行する接続なしアプリケーションの履行が簡略化されます。これを行うために、SOA Tasklistでは、SOA Tasklistの追加機能(手動のアプリケーションの履行の再割当てまたは一時停止など)が活用されます。

1.1.4 柔軟性と耐性

Oracle Identity Managerは、単一のサーバー・インスタンスにも複数のサーバー・インスタンスにもデプロイできます。複数のサーバー・インスタンスは、柔軟性、パフォーマンス、制御の向上のために最適な構成オプションを提供し、地理的に分散したユーザーおよびリソースをサポートします。また、Java 2 Enterprise Edition (J2EE)アプリケーション・サーバー・モデルのOracle Identity Managerには、スケーラビリティ、フォルト・トレランス、冗長性、フェイルオーバーおよびシステム・ロード・バランシングも備わっています。デプロイが拡張するにつれて、単一サーバーから複数サーバーの実装への移行がシームレスに行われます。

1.1.5 既存のインフラストラクチャを最大限に再利用

コストを下げ、できるかぎり簡素化し、既存の投資を活用するために、Oracle Identity Managerはオープン・アーキテクチャ上に構築されています。そのため、企業のITインフラストラクチャにすでに実装されている既存のソフトウェアおよびミドルウェアにOracle Identity Managerを統合して活用できます。たとえば、既存の顧客ポータルとの統合が必要な実装の場合は、Oracle Identity Managerの高度なAPIにより、包括的なシステム機能セットへのプログラムによるアクセスが可能になります。そのため、IT担当者は、Oracle Identity Managerのプロビジョニング実装のどの部分でも企業固有のニーズに合せてカスタマイズできます。

1.1.6 広範なユーザー管理

Oracle Identity Managerでは、ユーザーの組織階層やロールを必要な数だけ定義できます。継承、カスタマイズ可能なユーザーIDポリシー管理、パスワード・ポリシー管理およびユーザー・アクセス・ポリシーをサポートし、顧客の変化するビジネス・ニーズを反映します。また、アプリケーション・パラメータおよび権限を管理し、リソース割当ての履歴を表示できます。さらに、ユーザー管理に関する包括的な権限設定が可能な委任管理も提供されます。

Oracle Identity Managerには、ユーザー管理を包括的に支援する、カスタマイズ可能なWebベースのOracle Identity Managerセルフ・サービスがあります。

1.1.7 Webベースのユーザー・セルフサービス

Oracle Identity Managerには、カスタマイズ可能なWebベースのユーザー・セルフサービス・ポータルがあります。このポータルでは、ユーザー情報の管理、パスワードの変更と同期化、忘れたパスワードのリセット、選択可能なアプリケーションのリクエスト、選択可能な権限の確認と編集、およびワークフロー・タスクの開始と対処を操作できます。

1.1.8 モジュール型のスケーラブルなアーキテクチャ

Oracle Identity Managerは、Java EEアーキテクチャに基づいて構築されています。Oracle Identity ManagerのJ2EEアプリケーション・サーバー・モデルは、スケーラビリティ、フェイルオーバー、ロード・バランシングおよびWebデプロイメントを提供します。オープンな標準ベースのテクノロジに基づいて、3層のアーキテクチャ(クライアント・アプリケーション、Oracle Identity ManagerがサポートするJ2EE準拠のアプリケーション・サーバー、ANSI SQL準拠のデータベース)で構成されています。Oracle Identity Managerでは、LDAP対応およびLDAP非対応のアプリケーションをプロビジョニングできます。

Java EEは、標準的で強力なスケーラブルかつセキュアなプラットフォームで、多くのエンタープライズ・アプリケーションの基礎を形成しています。Oracle Identity Managerは、Oracle WebLogicなどの主要なJava EE準拠のアプリケーション・サーバー・プラットフォームで稼働し、これらのサーバーにあるパフォーマンス機能およびスケーラビリティ機能を活用します。Java EEは、標準化された一連のモジュール型コンポーネントを定義し、そのコンポーネントにサービスの完全なセットを提供して、アプリケーション動作の様々な詳細を処理します。

Oracle Identity Managerが稼働するアプリケーション・サーバーでは、Oracle Identity Managerアプリケーションを構成する論理コンポーネントに対してライフサイクル管理、セキュリティ、デプロイメントおよび実行時のサービスが提供されます。これには次のサービスが含まれます。

- クラスタリングおよびフェイルオーバーによるリソースのスケーラブルな管理: Java EEアーキテクチャ内のクラスタは、Java EEに準拠する2つ以上のWebサーバーまたはアプリケーション・サーバーのグループとして定義され、これらのサーバーは、透過的なオブジェクト・レプリケーション・メカニズムを介して相互に連携し、グループ内の各サーバーが必ず同じコンテンツを表示するようにします。クラスタ内の各サーバーまたはノードは同一の構成で、単一の仮想サーバーとして機能します。クラスタ内の任意のJava EEサーバーは、この仮想サーバーに転送されたクライアント・リクエストを個別に処理できるため、クラスタでは単一のエンティティがJava EEアプリケーションをホスティングしているような印象を与えます。
高可用性とは、中間層でホスティングされているアプリケーションに、クライアントが一貫してアクセスし、操作できる機能を指します。この機能は、クラスタ内の多数のWebサーバーとアプリケーション・サーバーの冗長性によって実現され、クラスタのフェイルオーバー・メカニズムによって実装されます。アプリケーション・コンポーネントがタスクの処理に失敗した場合は、クラスタのフェイルオーバー・メカニズムがそのタスクとサポート情報を別のサーバー上のオブジェクトのコピーに再ルーティングして、タスクを続行します。Oracle Identity Managerではクラスタ環境をサポートしています。これには、オブジェクト・レプリケーションが機能するように、データの格納に使用するEJBおよび値オブジェクトがシリアライズを確実にサポートすることが含まれます。

- ロード・バランシングを介したトランザクション管理: ロード・バランシングとは、インバウンドのクライアント処理リクエストをすべてのJava EEサーバーにわたって最適にパーティション化する機能を指し、これらのJava EEサーバーは、クラスタ化された各サーバーの容量、可用性、応答時間、現在の負荷、過去のパフォーマンス、管理上の優先度などの特定の要因に基づいて1つのクラスタを構成します。ソフトウェアまたはハードウェアをベースとするロード・バランサは、インターネットと物理的サーバー・クラスタ間に位置し、仮想サーバーとして機能します。クライアント・リクエストが届くたびに、ロード・バランサはそのリクエストを満たすJava EEサーバーを判断します。

- セキュリティ管理: Oracle Identity Managerアーキテクチャは、特定のセキュリティ・サービスに関しては、総合的なセキュリティ・インフラストラクチャの一環としてアプリケーション・サーバーに依存しています。また、Oracle Identity Managerでは、Java EEセキュリティ・フレームワークを活用してセキュアなアプリケーション環境を提供しています。柔軟な権限モデルも備えており、アプリケーション内の様々な機能に対する制御を提供します。

- メッセージング: メッセージングの背景にある基本概念は、複数の分散アプリケーションがビジネス・データとルーティング・ヘッダーの自己完結型パッケージを使用して通信できることにあります。これらのパッケージはメッセージと呼ばれます。RMIとHTTPは、クライアントとサーバー間の双方向のアクティブな通信に依存しますが、メッセージングは、メッセージング・サーバーを介して非同期で(応答を待たずに)通信する2人以上の関係者に依存します。Java Messaging Service (JMS)は、メッセージ機能を標準化する方法としてJ2EE標準に組み込まれたラッパーAPIです。すべての標準的なアプリケーション・サーバーには、そのサービス・オファリングの一部として、独自のJMSサーバー実装が用意されています。

1.1.9 主要なソフトウェア開発標準への準拠

Oracle Identity Managerには、主要な業界標準が取り入れられています。たとえば、Oracle Identity Managerコンポーネントは、J2EEアーキテクチャに完全に基づいているため、顧客は標準のアプリケーション・サーバー環境内からそれらを実行できます。完全なJ2EEサポートにより、パフォーマンスやスケーラビリティの利点を得ると同時に、既存の顧客の環境に合せて内部の専門知識を利用できます。

オラクル社では、現行の標準と新しい標準を基盤としてアイデンティティ管理製品を開発しています。たとえば、オラクル社はLiberty Allianceの管理委員会メンバーであり、Liberty Allianceの成果をソリューションに取り入れています。また、Organization for the Advancement of Structured Information Standards (OASIS)の主催で運営されているProvisioning Services Technical Committee (PSTC)に参加しています。

1.1.10 強力で柔軟性の高いプロセス・エンジン

Oracle Identity Managerでは、使用しやすいアプリケーションでビジネスおよびプロビジョニングのプロセス・モデルを作成できます。プロセス・モデルには、承認ワークフローおよびエスカレーションのサポートが含まれます。イベントの現在のステータスやエラー・コードのサポートなど、各プロビジョニング・イベントの進行を追跡できます。Oracle Identity Managerでは、データ交換や依存関係を含む複雑な分岐のあるネストされたプロセスをサポートしています。プロセス・フローは完全にカスタマイズ可能で、プログラミングは不要です。

1.1.11 組込みの変更管理

Oracle Identity Managerでは、新規プロセスのパッケージ化、既存プロセスのインポートおよびエクスポート、システム間のパッケージの移動が可能です。

1.1.12 ワークフローおよびポリシー

ビジネス・プロセスおよびITプロセスを自動化するためにワークフローとポリシーを使用することで、業務効率を改善し、セキュリティの強化を図ることができ、コンプライアンス追跡のコスト効率がさらに高まります。Oracle Identity Managerは、このカテゴリの次の機能を提供します。

ポリシー管理

Oracle Identity Managerを使用すると、きめ細かな権限によってリソースのプロビジョニングをポリシーベースで自動化できます。管理者は、任意のユーザー・グループに対してプロビジョニングされるリソースごとにアクセス・レベルを指定し、各ユーザーにジョブを完了するために必要なレベルのアクセス権のみを付与することができます。これらのポリシーは、ユーザーのロールまたは属性によって決定できるため、ロールベースのアクセス制御および属性ベースのアクセス制御を実装できます。ロールベースのポリシーと属性ベースのポリシーを効果的に融合することが、スケーラブルで管理しやすい企業のプロビジョニング・ソリューションへの鍵となります。

リクエストは、実行されるまでに複数の承認を通過します。リクエストを送信する場合は、異なるレベルで承認を得る必要があります。システムでの承認は、承認ポリシーを使用して構成できます。起動する承認プロセスとポリシーに関連する承認ルールは、承認ポリシーによって定義されます。これらの承認ルールは、リクエスト・エンジンによる承認プロセスの選択に役立ちます。ビジネス・アナリストは、承認ポリシーおよび承認ルールを定義できます。

ワークフロー管理

Oracle Identity Managerでは、承認とプロビジョニングのワークフローを分離できます。承認ワークフローにより、企業はリソースのアクセス・リクエストを管理するための望ましい承認プロセスをモデル化できます。プロビジョニング・ワークフローにより、組織では最も複雑なプロビジョニング手順を使用したリソースのプロビジョニングに対するITタスクを自動化できます。

この2つのワークフローの分離により、ビジネス・プロセスとITプロセスの所有者は、プロセス間の干渉を最小限に抑えて、作業を効率的に管理できます。また、ヘルプ・デスクやHRMSなどのシステムにすでにデプロイされている既存のワークフローも活用できます。Oracle Identity Managerには、ビジネス・ユーザー、管理者および監査者がタスクの順序や依存関係を視覚化してプロセスフローを把握できるワークフロー・ビジュアライザと、プロセス・フローを編集および管理できるワークフロー・デザイナが用意されています。

動的エラー処理

Oracle Identity Managerのエラー処理機能により、プロビジョニング中に発生する例外を処理できます。リソースの欠如などの頻繁に発生する問題によって、プロビジョニング・トランザクション全体が停止したり、失敗したりすることはありません。プロビジョニング・ワークフロー内に定義するビジネス・ロジックにより、Oracle Identity Manager実装内にカスタマイズされたフェイルセーフ機能を提供します。

トランザクションの整合性

Oracle Identity Managerでは、組込みの状態管理機能に基づいて、他のきわめて重要な企業システムで必要とされる高レベルのトランザクションの整合性を提供します。Oracle Identity Managerには、ロールバック機能とリカバリ機能を備えた状態エンジンが用意されています。プロビジョニング・トランザクションが失敗または停止した場合、システムは、事前定義済のルールに従って、最後に成功したときの状態にリカバリおよびロールバックするか、別のパスに再ルーティングできます。

リアルタイムのリクエスト追跡

すべてのプロビジョニング・プロセスに対してよりよい制御を維持し、可視性を向上させるために、Oracle Identity Managerを使用するとユーザーおよび管理者は、プロビジョニング・トランザクションのどの時点でもリクエスト・ステータスをリアルタイムに追跡できます。

1.1.13 監査およびコンプライアンス管理

アイデンティティ管理は、企業の監査およびコンプライアンス・ソリューションにおける重要な要素となります。Oracle Identity Managerを使用すると、企業はリスクを最小限に抑え、社内外のガバナンスおよびセキュリティ監査に必要なコストを削減できます。この項では、監査およびコンプライアンス管理カテゴリに示すOracle Identity Managerの機能について説明します。

アイデンティティ・リコンシリエーション

リコンシリエーションはOracle Identity Managerの重要な機能の1つで、すべての管理リソースを対象としてアカウントの作成、更新および削除を監視および追跡できます。リコンシリエーションのプロセスは、リコンシリエーション・エンジンによって実行されます。Oracle Identity Managerの制御範囲外の影響をもたらすアカウントやユーザーのアクセス権に対する変更が検出された場合、リコンシリエーション・エンジンは、変更の取消しや管理者への通知などの修正措置を即座に実行できます。また、Oracle Identity Managerを使用して、ターゲット・リソースで既存のアカウントを検出およびマップできます。これは、個々の従業員、パートナまたは顧客ユーザーについて、企業全体のアイデンティティおよびアクセス・プロファイルを作成する際に役立ちます。

統制外アカウントおよび孤立アカウントの管理

統制外アカウントとは、プロセス外、つまりプロビジョニング・システムの制御範囲外で作成されるアカウントです。孤立アカウントとは、有効な所有者がいない、操作可能なアカウントです。このようなアカウントは、企業にとって深刻なセキュリティ・リスクとなります。Oracle Identity Managerでは、統制外アカウントや孤立アカウントを継続的に監視できます。このようなアカウントが検出された場合、アクセス拒否ポリシー、ワークフローおよびリコンシリエーションを組み合せることで、企業は必要な修正措置を実行できます。

サービス・アカウント

Oracle Identity Managerでは、管理者アカウントとも呼ばれる特殊なサービス・アカウントのライフ・サイクルも管理できます。このようなアカウントには、単一の割当済ユーザーのライフ・サイクルを越えて、複数の割当済ユーザーのライフ・サイクルに渡る、特別なライフ・サイクル要件があります。サービス・アカウントを適切に管理することにより、孤立アカウントを生み出す可能性があるもう1つの原因を排除できます。

包括的なレポートおよび監査機能

Oracle Identity Managerでは、プロビジョニング環境の過去と現在の両方の状態についてレポートを作成します。Oracle Identity Managerで取得されるアイデンティティ・データには、ユーザー・アイデンティティ・プロファイルの履歴、ロールのメンバーシップ履歴、ユーザーのリソース・アクセスおよび詳細な権限の履歴などがあります。また、Oracle Identity Managerのワークフロー、ポリシーおよびリコンシリエーション・エンジンによって生成されるデータも取得されます。そのデータをアイデンティティ・データと組み合せると、企業は、アイデンティティおよびアクセスに関連する監査の照会処理に必要なデータをすべて入手できます。

アテステーション

アテステーション(再証明とも呼ばれる)は、Sarbanes-Oxley法コンプライアンスの中核であり、推奨されるセキュリティのベスト・プラクティスです。多くの場合、組織では、スプレッドシート・レポートや電子メールに基づいた手動プロセスを使用して、これらのアテステーション要件を満たしています。このような手動プロセスは、断片化する傾向があり、管理が困難で管理コストが高額になり、データの整合性と監査能力はほとんどありません。

Oracle Identity Managerには、短時間でデプロイでき、レポートの自動生成、自動配信および自動通知を提供する企業全体のアテステーション・プロセスが可能なアテステーション機能があります。アテステーション・レビューアは、きめ細かな認証、却下、拒否および委任の各アクションをサポートする対話型のユーザー・インタフェースで、詳細なアクセス・レポートを検討できます。すべてのレポート・データおよびレビューアのアクションは、将来の監査要求のために保存されます。Oracle Identity Mangerのワークフロー・エンジンを構成することにより、レビューアのアクションから修正措置をトリガーすることも可能です。

注意:

アテステーション機能は、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では非推奨になりました。アテステーションは、アイデンティティの証明で代替されます。アイデンティティの証明の詳細は、次の各項を参照してください。

- Oracle Fusion MIddleware Oracle Identity Managerユーザーズ・ガイドのタスクの管理およびアイデンティティの証明の使用に関する項

- Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのアイデンティティの証明に関する項

ただし、Oracle Identity Manager Release 9.xまたは11gリリース1 (11.1.1)または11gリリース2 (11.1.2)からのアップグレードの場合は、アテステーション機能を使用できます。

アイデンティティの証明

アイデンティティの証明により、Oracle Identity Managerは、単一製品に次の機能を提供できます。

- アクセス・リクエスト: カタログからの権限のリクエスト、承認の取得

- 履行: 自動または手動によるプロビジョニング

- アクセス・レビュー: Oracle Identity Managerでのエンティティの証明

アイデンティティの証明には、さらに次の機能があります。

- 証明内の個々の行アイテムの委託により、レビューアは、複数ユーザー(同時に作業可能なユーザー)間での作業を拡大できます。これにより、企業内のアクセスのレビューを担当するユーザーは、ワークロードを分散でき、作業を迅速に完了できるようになります。

- 2段階レビューにより、1つの証明で、アクセス・レビューを通知する次の2つの主要なパースペクティブを一体化できます。

- ビジネス・レビューア。通常は、ライン・オブ・ビジネス(LOB)マネージャ

- 技術レビューア。通常は、ITエキスパートまたはアプリケーション所有者

1.1.14 統合ソリューション

スケーラブルで柔軟な統合アーキテクチャは、企業のプロビジョニング・ソリューションのデプロイを成功させるうえで非常に重要です。Oracle Identity Managerでは、実績がある統合アーキテクチャおよび事前定義済コネクタを提供し、迅速で低コストのデプロイを実現します。

アダプタ・ファクトリ

プロビジョニング・システムと管理リソースとの統合は、簡単ではありません。独自システムとの接続は、困難な場合があります。アダプタ・ファクトリにより、このような接続の作成や管理が簡単になります。Oracle Identity Managerに用意されているアダプタ・ファクトリは、コード生成ツールで、Javaクラスを作成できます。

アダプタ・ファクトリは、商用システムやカスタム・システムとの迅速な統合を実現します。ユーザーは、アダプタ・ファクトリのグラフィカル・ユーザー・インタフェースを使用し、プログラムやスクリプトを作成することなく、統合を作成または変更できます。コネクタが作成されると、その定義はOracle Identity Managerリポジトリで管理され、自己文書化ビューが作成されます。これらのビューを使用して、コネクタの拡張、メンテナンスおよびアップグレードを実行します。

事前定義済コネクタ

Oracle Identity Managerには、広く使用されている商用アプリケーションと他のアイデンティティ認識システムのための、事前定義済コネクタの豊富なライブラリがあります。これらのコネクタを使用することで、企業はアプリケーション統合において有利なスタートを切ることができます。各コネクタでは、多種多様なアイデンティティ管理機能をサポートします。これらのコネクタは、独自のものであろうと、オープン・スタンダードに基づいたものであろうと、ターゲット・リソースに対して推奨される最適な統合テクノロジを使用します。これらのコネクタにより、一連の異種ターゲット・システムとOracle Identity Managerの間ではデフォルト設定のままの統合が可能です。これらのコネクタには、もともとアダプタ・ファクトリを使用して開発されたコンポーネント・セットが用意されているため、アダプタ・ファクトリを使用してさらに変更し、各企業固有の統合要件を実現できます。

汎用テクノロジ・コネクタ

カスタム・コネクタの作成にアダプタ・ファクトリのカスタマイズ機能が不要な場合は、Oracle Identity Managerの汎用テクノロジ・コネクタ(GTC)機能を使用してコネクタを作成できます。

アイデンティティ・コネクタ

アイデンティティ・コネクタ・フレームワーク(ICF)は、Oracle Identity Managerからコネクタを分離します。その結果、任意の製品でコネクタを使用できるようになります。アイデンティティ・コネクタは、アプリケーションの実装を、そのアプリケーションが接続を試みるシステムの依存性から切り離すように設計されています。

1.1.15 ユーザー・プロビジョニング

プロビジョニングでは、Oracle Identity Managerからターゲット・システムへのユーザー情報の外部へのフローが提供されます。プロビジョニングは、リソースのユーザー情報を作成、変更または削除するためのアクションをOracle Identity Managerで開始し、リソースに渡すプロセスです。プロビジョニング・システムはリソースと通信し、アカウントに適用する変更を指定します。

プロビジョニングには、次のことが含まれます。

- ユーザー・アイデンティティおよびユーザー・アカウントのプロビジョニングの自動化: 複数のシステムやアプリケーションにわたってユーザー・アイデンティティとユーザー・アカウントを管理します。たとえば、給与処理部門に勤務する従業員が人事管理システムで作成されると、このユーザーのアカウントが、電子メール・システム、電話システム、会計システムおよび給与レポート・システムにも自動的に作成されます。

- ワークフローおよびポリシー管理: これにより、アイデンティティのプロビジョニングが可能になります。管理者は、プロビジョニング・ツールに用意されているインタフェースを使用し、セキュリティ・ポリシーに基づいてプロビジョニング・プロセスを作成できます。

- レポートおよび監査: プロビジョニング・プロセスとその実施に関するドキュメントを作成できます。このドキュメントは、監査、法規制およびコンプライアンスのために不可欠なものです。

- アテステーション: これにより、管理者はユーザーのアクセス権を定期的に確認できます。

- アクセス権のプロビジョニング解除: 企業内でユーザーのアクセス権が不要または無効になった場合、Oracle Identity Managerでは、ロール・ベースまたは属性ベースのアクセス・ポリシーに従い、必要に応じて、または自動的にアクセス権を失効します。つまり、ユーザーのアクセス権は、不要になると即座に停止されます。これにより、セキュリティ・リスクを最小限に抑えるとともに、データ・サービスなど、消費コストの高いリソースに対する無駄なアクセスを防ぐことができます。

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

Oracle Identity Managerをデプロイして使用する前に、使用する環境がインストールの最低要件を満たすことを確認する必要があります。

次のURLでは、Oracle Fusion Middlewareでサポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報を参照できます。

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

2 製品のアーキテクチャ

Oracle Identity Managerのアーキテクチャには、アイデンティティおよびアクセス管理の一部としてプロビジョニング・ソリューションをデプロイするための様々な優れた技術上の利点があります。Oracle Identity Managerは、IT要件およびビジネス要件に対処できる柔軟なアーキテクチャを持ち、既存のインフラストラクチャ、ポリシーまたは手順を変更する必要はありません。

Oracle Identity Managerアーキテクチャについては、次の各項で説明します。

- Oracle Identity Managerの仕組み: Oracle Identity Managerの層

- システム・コンポーネント

2.1 Oracle Identity Managerの仕組み: Oracle Identity Managerの層

Oracle Identity Managerは、n層J2EEアプリケーション・アーキテクチャに基づいています。Oracle Identity Managerのアーキテクチャは、次の層で構成されています。

- プレゼンテーション層

- ビジネス・サービス層

- ミドルウェア層

- データ層

図2-1に、Oracle Identity Managerのアーキテクチャを示します。

図2-1 Oracle Identity Managerのアーキテクチャ

2.1.1 プレゼンテーション層

プレゼンテーション層は、Oracle Identity Self Service、Oracle Identity System AdministrationおよびOracle Identity Manager Design Consoleの3つのクライアントで構成されています。

Oracle Identity Self Serviceは、Webベースのシン・クライアントで、任意のWebブラウザからアクセスできます。このWebクライアントは、単一のインタフェース内に、ほとんどのOracle Identity Managerユーザーに役立つユーザー・セルフサービス機能および委任管理機能を提供します。

Oracle Identity System Administrationは、管理およびシステム管理機能を提供するWebベースのシン・クライアントです。

Oracle Identity Manager Design Consoleでは、フォーム、ワークフロー設計、アダプタの作成と管理など、システムの構成および開発機能が提供されます。Design Consoleは、アプリケーション内でビジネス・サービス・レイヤーと直接通信するJava Swingクライアントとして実装されます。Oracle Identity Manager Design Consoleには、デスクトップJavaクライアントを使用してアクセスできます。

また、Oracle Identity Managerインタフェースは高度な委任管理モデルをサポートしているため、ユーザーは、権限を与えられたアプリケーション構成部分のみで作業できます。

多くの企業には、カスタム開発したクライアントをサポートするプロビジョニング・システムに対する要件があります。そのいくつかの要件は、次のとおりです。

- 既存のエンタープライズ・ポータルへのクライアントの統合、およびエンタープライズ・ポータル標準の遵守

- ユーザー相互作用に対するカスタム・フローの作成

- 一意の要件に基づいてプロビジョニング・システムから構築されるカスタム・ページの作成

カスタマイズをサポートするために、Oracle Identity Managerでは、公開されたパブリックAPIを介して必要な機能の大部分を公開しています。Oracle Identity Managerのクライアント環境は、Java APIを介してカスタマイズできます。

2.1.2 ビジネス・サービス層

ビジネス・サービス層は、Enterprise JavaBeans (EJB)アプリケーションとして実装されます。Oracle Identity Managerプラットフォームの中核機能は、高度なモジュール型オブジェクト指向の手法を使用して、Javaで実装されます。これにより、Oracle Identity Managerの柔軟性と拡張性が向上します。Oracle Identity Managerのビジネス・サービス層には、次のサービスおよび機能が含まれます。

- Oracle Identity Managerが提供するビジネス機能の中核を形成するコア・サービス(ユーザー管理サービス、ポリシー管理サービス、プロビジョニングおよびリコンシリエーション・サービスなど)。

- Oracle Identity ManagerでサポートされているAPIを記述したAPIサービス(APIサービスを使用すると、カスタム・クライアントをOracle Identity Managerに統合できます)。カスタム・クライアントによる製品のカスタマイズや、プラグインおよびアダプタの開発の際に使用できるように、Oracle Identity Managerのビジネス機能を公開する一連の豊富なAPIが含まれています。

- アダプタ・ファクトリおよびコネクタ・フレームワークに基づいた統合サービス(統合サービスでは、アダプタのメタデータ定義に従って統合コードが動的に生成されます)。

- Oracle Identity Managerが提供するビジネス機能に不可欠なプラットフォーム・サービス(リクエスト管理サービス、エンティティ・マネージャ・サービス、スケジューラ・サービスなど)。

ビジネス・サービス層については、次の各項で説明します。

- APIサービス

- 統合サービス

- プラットフォーム・サービス

2.1.2.1 APIサービス

APIサービスには、カスタム・クライアントとOracle Identity Managerとの統合を可能にする、Oracle Identity ManagerでサポートされるAPIが記述されています。カスタム・クライアントによる製品のカスタマイズや、プラグインおよびアダプタの開発の際に使用できるように、Oracle Identity Managerのビジネス機能を公開する一連の豊富なAPIが含まれています。

APIサービスの構成は、次のとおりです。

- SPML API: サービス・プロビジョニング・マークアップ言語(SPML)は、組織内および組織間でのアイデンティティ情報やシステム・リソースのプロビジョニングと割当てを管理するための標準です。Oracle Identity Managerでは、アイデンティティ管理機能をクライアントに公開するSPMLベースの一連のWebサービスをサポートしています。APIは、次の操作に対してサポートを提供します。

- アイデンティティの追加、変更および削除

- ロールの追加、変更および削除

- ロール・メンバーシップの追加と削除

これらのAPIは、Oracle Identity Managerに送信されるリクエストを管理目的でサポートし、プロビジョニング・ターゲットとの統合に使用するプロトコルであるSPMLとは区別されます。

- EJB API: プラットフォームの機能に対するきめ細かなアクセスは、一連のEJBを経由します。これらのセッションBeanは、Oracle Identity ManagerのWebアプリケーション・クライアントに実装されている機能の基盤です。また、カスタム・クライアントがOracle Identity Managerの機能にアクセスする際に使用できるインタフェースでもあります。

2.1.2.2 統合サービス

スケーラブルで柔軟な統合アーキテクチャは、企業のプロビジョニング・ソリューションのデプロイメントを成功させる上で非常に重要です。Oracle Identity Managerは、統合アーキテクチャを提供し、迅速で低コストのデプロイメントを実現します。

Oracle Identity Managerの統合サービスには、コネクタの開発、デプロイメントおよびメンテナンスのサポートに必要なすべてのコンポーネントが用意されています。統合サービスには、次のものがあります。

- コネクタ・フレームワーク

- アイデンティティ・コネクタ

- アダプタ・ファクトリ

- 汎用テクノロジ・コネクタ

- Remote Manager

2.1.2.2.1 コネクタ・フレームワーク

Oracle Identity Managerのコネクタは、ターゲット・アプリケーションにあるアイデンティティを管理するために、そのアプリケーションとの統合に使用されるパッケージ・ソリューションです。このようなターゲット・アプリケーションの例には、Microsoft Active DirectoryやOracle E-Business Suiteなどがあります。コネクタは、特定のターゲット・システム用にOracleで事前に定義されていますが、カスタム開発することもできます。

事前定義済コネクタはターゲット・アプリケーション専用に設計されているため、最も迅速な統合方法となります。これらのコネクタは、Oracle eBusiness Suite、PeopleSoft、Siebel、JD EdwardおよびSAPなどの一般的なビジネス・アプリケーションの他、Active Directory、Java Directory ServerおよびUNIXの各データベース、RSA ClearTrustなどのテクノロジ・アプリケーションもサポートします。事前定義済コネクタは、ターゲット・アプリケーション専用に設計されているため、最も迅速な統合の選択肢です。これらは、ターゲットが推奨する統合テクノロジを使用し、アプリケーション固有の属性を使用して事前に構成されています。

事前定義のコネクタで、ターゲットが推奨する統合テクノロジが使用されていない場合は、カスタム・コネクタを開発できます。Oracle Identity Manager Design Consoleのアダプタ・ファクトリ・ツールには定義ユーザー・インタフェースがあり、これを使用すると、コーディングやスクリプトを作成せずに、このようなカスタム開発を簡単に実現できます。

コネクタには、次の構成要素があります。

- コネクタ固有の複数のOracle Identity Managerエンティティ(リソース・オブジェクト、データ・フォーム、プロビジョニング・ワークフロー、アダプタなど)

- 接続性、認証、ユーザー・アカウント管理などの基礎となる機能を提供するターゲット固有のJavaライブラリ

- アイデンティティ・プロファイルの変更とポリシーの操作の両方に対してプロビジョニング操作を関連付けるイベント・トリガー

コネクタ・フレームワークは、これらのコンポーネントすべてを、手動によるユーザー相互作用またはシステム・トリガーに基づいて、適切な時期に実行される機能コネクタに結合します。特定の要件にあわせてコネクタ操作を調整できる操作可能な様々なトリガー、ポリシー・トリガーおよびフックを定義します。

2.1.2.2.2 アイデンティティ・コネクタ

Oracle Identity Managerとともにデプロイされるコネクタは、Oracle Identity Managerの様々なリリース間でのコネクタの移植性に影響を与えます。アイデンティティ・コネクタ・フレームワーク(ICF)は、Oracle Identity Managerからコネクタを分離します。その結果、任意の製品でコネクタを使用できるようになります。アイデンティティ・コネクタは、アプリケーションの実装を、そのアプリケーションが接続を試みるシステムの依存性から切り離すように設計されています。

アイデンティティ・コネクタには、次のコンポーネントがあります。

- アイデンティティ・コネクタ・フレームワーク: アプリケーションからコネクタ・バンドルを切り離すコンテナを提供します。フレームワークには一般的な機能が数多く用意されていますが、ない場合は開発者が独自に実装する必要があります。たとえば、フレームワークでは、接続プーリング、バッファ、タイムアウトおよびフィルタを提供できます。アイデンティティ・コネクタ・フレームワークは、2つの部分に分かれています。

- API: APIを使用してアプリケーションがコネクタをコールします。

- SPI: SPIを実装することで開発者がコネクタを作成できます。

- アイデンティティ・コネクタ・バンドル: 指定のリソース・ターゲットに対する固有の実装です。

- コネクタ・サーバー(オプション): 別のシステムにデプロイされている1つ以上のコネクタ・バンドルをアプリケーションからリモートで実行できます。コネクタ・サーバーはJava (tm)と.NETの両方で使用できます。.NETコネクタ・サーバーは.NETコネクタ・バンドルを使用する場合にのみ必要であり、Javaコネクタ・サーバーはJavaで記述されたコネクタ・バンドルに対して使用できます。

図2-2に、ICFアーキテクチャを示します。

図2-2 ICFアーキテクチャ

コネクタSPI

コネクタSPIインタフェースは、コネクタでサポートされる操作を表します。コネクタ開発者は、ターゲット・システム・コールをフレーム化するために1つ以上の操作インタフェースを実装することを選択できます。既存のインタフェースの拡張や新規インタフェースの作成はサポートされていません。SPIは、必須のインタフェース、機能ベースのインタフェースおよび操作のインタフェース(作成、更新、削除および検索など)に分類されます。

- 必須のインタフェースには、org.identityconnectors.framework.spi.Connectorインタフェースやorg.identityconnectors.framework.spi.Configurationインタフェースが含まれます。これらのインタフェースは、構成の実装が格納されているクラスおよび操作の実装が格納されている場所をAPIが把握するために実装する必要があります。

- 機能ベースのインタフェースには、org.identityconnectors.framework.spi.AttributeNormalizerインタフェースやorg.identityconnectors.framework.spi.PoolableConnectorインタフェースがあります。

- 操作のインタフェースは、コネクタがサポートする機能(作成、削除、検索など)を判断します。Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

コネクタAPI

コネクタAPIは、実装された操作に関係なく、一貫したコネクタの表示を提供する機能を果たします。SPI開発者の利便性のために、複数の一般的な機能がデフォルトで用意されています。ほとんどの機能では、アプリケーション開発者によるAPIの処理は不要で、APIの構成のみが必要です。次に、API機能のリストを示します。

- すべてのコネクタが接続されるわけではないため、接続プーリングは必要なコネクタにのみ提供し、APIが接続プーリングを確認しなくて済むようにします。また、コネクタが接続プーリングを使用する場合は、接続の処理もエラー発生時の接続の破棄もAPI開発者の担当ではありません。

- すべての操作にタイムアウトを提供します。デフォルトをそのまま使用しない場合は、APIコンシューマが適切なタイムアウトを構成します。各SPI開発者は、一般的なサービスを実装する必要はありません(フレームワークに実装されているため)。

- 多種多様なフィルタを受け入れる単純なインタフェース手段として検索フィルタを提供します。コネクタ開発者に唯一必要な作業は、リソースが本来サポートしているフィルタを実装することです。それ以外はフレームワークで処理されます。

- 必要な場合に問合せや更新を大量に処理できるように、検索/同期バッファを提供します。実際はフレームワーク内で処理されるため、この点についてアプリケーションで考慮する必要はありません。

- コネクタに対して、GroovyおよびBooの.NETを介してスクリプトを提供します。これによって、フレームワークでは、コネクタとターゲット・リソースの両方でスクリプトを実行できるため(サポートされている場合)、コネクタ内で高い柔軟性が得られます。

- SPI開発者は、操作に対して異なる実装を選択できます。たとえば、2つのタイプの更新があるとします。アプリケーション開発者は、基本的に同じことを実行する2つの異なる操作をコールする必要がないため、これはAPIコンシューマには非表示にされます。かわりに、コネクタがサポートする操作はフレームワークで把握され、適切なコールが実行されます。

2.1.2.2.3 アダプタ・ファクトリ

アダプタ・ファクトリはOracle Identity Managerで提供されるコード生成ツールです。これによって、Oracle Identity Managerアプリケーション開発者は、Javaクラス(アダプタとも呼ばれる)を作成できます。

リソースには関連するプロビジョニング・プロセスがあり、そのプロセスには様々なタスクが関連付けられます。同様に、各タスクにはアダプタが関連付けられ、必要な操作を実行するためにターゲット・リソースに接続されます。

アダプタには次の利点があります。

- Oracle Identity Managerの内部ロジックと機能を拡張します。

- リソースのAPIを活用してそのリソースに接続することで、ソフトウェア・リソースとインタフェースします。

- Oracle Identity Managerと外部システム間の統合を可能にします。

- 手動でコードを記述しなくても生成できます。

- アダプタのすべての定義はリポジトリに保存されるため、簡単にメンテナンスできます。このリポジトリはGUIを使用して編集できます。

- Oracle Identity Managerでは、あるユーザーが統合に関するドメインの知識を保持し、別のユーザーがアダプタをメンテナンスできます。

- 変更およびアップグレードできます。

アダプタ・ファクトリは、商用システムやカスタム・システムとの迅速な統合を実現します。ユーザーは、アダプタ・ファクトリのグラフィカル・ユーザー・インタフェースを使用し、プログラムやスクリプトを作成することなく、統合を作成または変更できます。コネクタが作成されると、Oracle Identity Managerリポジトリではその定義が管理され、自己文書化ビューが作成されます。これらのビューを使用して、コネクタの拡張、メンテナンスおよびアップグレードを実行します。

2.1.2.2.4 汎用テクノロジ・コネクタ

Oracle Identity Managerの事前定義済コネクタは、Microsoft Active DirectoryおよびPeopleSoft Enterprise Applicationsなどの、一般的に使用されているターゲット・システムにあわせて設計されています。事前定義済コネクタのアーキテクチャは、ターゲット・システムがサポートしているAPI、またはターゲット・システムがユーザー・データを格納するデータ・リポジトリのタイプおよびスキーマのいずれかに基づいています。ターゲット・システムでこれらのコネクタが使用できる場合は、統合の方法として事前定義済コネクタを使用することをお薦めします。ただし、対応する事前定義済コネクタがないターゲット・システムとOracle Identity Managerを統合する場合があります。たとえば、XYZ Travels Inc.は、顧客が航空運賃見積のリクエストに使用するカスタムのWebベース・アプリケーションを所有しています。XYZ Travelsの従業員でもあるエージェントは、これらのリクエストに対し、同じアプリケーションを使用して応答します。顧客は、自己登録によりこのアプリケーション内にアカウントを作成します。ただし、XYZ Travelsの従業員は、人事管理上の役職に基づいて自動的にプロビジョニングされたアカウントを持っている必要があります。作成、更新および削除など、アプリケーションのアカウント管理機能は、Java APIを介して使用可能です。カスタム・アプリケーションをOracle Identity Managerに統合する場合に使用できる事前定義済コネクタはありません。したがって、ターゲット・アプリケーションで公開されているJava APIをコールするカスタム・コネクタを作成する必要があります。

Oracle Identity Managerを、対応する事前定義済コネクタがないターゲット・システムと統合するには、カスタム・コネクタを作成してターゲット・システムとOracle Identity Managerをリンクできます。アダプタ・ファクトリのカスタマイズ機能が不要な場合は、Oracle Identity Managerの汎用テクノロジ・コネクタ(GTC)機能を使用してコネクタを作成できます。

基本のコネクタは、高度な機能やカスタマイズ動作を使用せず、SPML、JDBCなどの汎用接続性テクノロジを使用してすばやく簡単に作成できます。GTCはコネクタ開発に代替環境を提供するウィザードで、Oracle Identity Managerでターゲット・システム・コネクタを構成するために必要なすべての機能コンポーネントを速やかに作成します。

GTCフレームワークには基本コンポーネントが用意されており、これらのコンポーネントを使用してカスタム・コネクタを迅速に作成できます。汎用テクノロジ・コネクタのリコンシリエーション・モジュールおよびプロビジョニング・モジュールは、選択したこれらの再使用可能コンポーネントで構成されます。それぞれのコンポーネントでは、プロビジョニング時またはリコンシリエーション時に、特定の機能が実行されます。次のコンポーネントがあります。

- リコンシリエーション:

- リコンシリエーション・トランスポート・プロバイダ: このプロバイダは、リコンサイルされたデータをターゲット・システムからOracle Identity Managerに移動します。

- リコンシリエーション・フォーマット・プロバイダ: このプロバイダは、ターゲット・システムから受け取った、リコンサイル済データが含まれているメッセージを、Oracle identity Managerのリコンシリエーション・エンジンで解釈できるデータ構造に解釈します。

- 検証プロバイダ: このプロバイダは、受け取ったデータをリコンシリエーション・エンジンに渡す前にそのデータを検証します。

- プロビジョニング:

- プロビジョニング・フォーマット・プロバイダ: このプロバイダは、Oracle identity Managerのプロビジョニング・データを、ターゲット・システムでサポートされているフォーマットに変換します。

- プロビジョニング・トランスポート・プロバイダ: このプロバイダは、受け取ったプロビジョニング・メッセージをプロビジョニング・フォーマット・プロバイダからターゲット・システムに伝播します。

図2-3は、汎用テクノロジ・コネクタの機能アーキテクチャを示しています。

図2-3 汎用テクノロジ・コネクタの機能アーキテクチャ

汎用テクノロジ・コネクタには、次の機能があります。

- 次の機能は、リコンシリエーション・モジュールに固有のものです。

- 信頼できるソース・リコンシリエーションでの汎用テクノロジ・コネクタ: 汎用テクノロジ・コネクタは、信頼できるソース・リコンシリエーションに使用できます。信頼できるモードのリコンシリエーションでは、リコンシリエーション・エンジンで新規のターゲット・システム・アカウントが検出されると、対応するOIMユーザーが作成されます。リコンシリエーション・エンジンでは、既存のターゲット・システム・アカウントに対する変更が検出されると、対応するOIMユーザーに同様の変更が行われます。

- アカウント・ステータスのリコンシリエーションでの汎用テクノロジ・コネクタ: ユーザー・アカウント・ステータス情報は、ターゲット・システム・アカウントの所有者によるアカウントへのアクセスおよびアカウントの使用が許可されるかどうかの追跡に使用されます。Oracle identity Managerに格納されている形式のアカウント・ステータス情報がターゲット・システムに格納されていない場合は、事前定義済の翻訳変換プロバイダを使用して、アカウント・ステータスのリコンシリエーションを実装できます。

- 完全リコンシリエーションまたは増分リコンシリエーションでの汎用テクノロジ・コネクタ: 汎用テクノロジ・コネクタを作成する際に、コネクタを完全リコンシリエーションまたは増分リコンシリエーションに使用するように指定できます。増分リコンシリエーションでは、最後のリコンシリエーション実行後に変更されたターゲット・システムのレコードのみがOracle Identity Managerでリコンサイル(格納)されます。完全リコンシリエーションでは、すべてのリコンシリエーション・レコードがターゲット・システムから抽出されます。

- バッチ・リコンシリエーションの汎用テクノロジ・コネクタ: リコンシリエーション・プロセスを詳細に制御するために、汎用テクノロジ・コネクタを使用してリコンシリエーションのバッチ・サイズを指定できます。これにより、リコンシリエーション実行中にリコンシリエーション・エンジンがターゲット・システムからフェッチするレコードの総数をバッチに分割できます。

- 複数値属性データ(子データ)の削除のリコンシリエーションでの汎用テクノロジ・コネクタ: ターゲット・システムの複数値属性データの削除をOracle Identity Managerでリコンサイルするかどうかを指定します。

- リコンシリエーション停止の失敗しきい値での汎用テクノロジ・コネクタ: リコンシリエーションの実行時に、ターゲット・システム・データをOracle Identity Managerに格納する前に、検証プロバイダを使用してデータのチェックを実行できます。失敗しきい値を設定しておくと、検証チェックに通らなかったレコードの処理済レコードの総数に対する割合が指定のしきい値を超えた場合に、リコンシリエーションの実行を自動的に停止できます。

- 汎用テクノロジ・コネクタには、その他に次の機能があります。

- カスタム・プロバイダ: Oracle Identity Managerに付属の事前定義済プロバイダが、動作環境のトランスポート、フォーマット変更、検証または変換についての要件に対応していない場合は、カスタム・プロバイダを作成できます。

- 多言語サポート: 汎用テクノロジ・コネクタは、ASCIIとASCII以外の両方の形式のユーザー・データを処理できます。

- カスタム日付書式: 汎用テクノロジ・コネクタの作成時は、リコンシリエーション実行中に抽出されたターゲット・システム・レコードの日付の値の書式と、プロビジョニング実行中にターゲット・システムに送信する必要がある日付の値の書式を指定できます。

- OIMユーザー属性に対する変更のターゲット・システムへの伝播: 汎用テクノロジ・コネクタの作成時に、OIMユーザー属性に対する変更が自動的にターゲット・システムに伝播されるように設定できます。

2.1.2.2.5 Remote Manager

アダプタでJavaタスクを使用する場合、適切なJava APIを検索するようにOracle Identity Managerを構成する必要があります。Java APIは、Meta Data Store (MDS)のJARファイルに格納されています。サード・パーティ・システムと直接通信せずに、プロキシのように動作するOracle Identity Managerコンポーネントを使用する必要がある場合があります。このコンポーネントは、Remote Managerと呼ばれます。Remote Managerは、次の目的で使用します。

- Oracle Identity Managerを通じた非リモートAPIの呼出し

- セキュアな接続でのSecure Sockets Layer (SSL)をサポートしないAPIの呼出し

Remote Managerは、ターゲット・システムのコンピュータで動作するOracle Identity Managerサーバーのコンポーネントです。ネットワーク対応のAPIがないアプリケーションやセキュリティを提供しないアプリケーションとの統合に必要なネットワークとセキュリティ・レイヤーを提供します。これは、軽量Remote Method Invocation (RMI)サーバーとして構築されます。通信プロトコルは、Hypertext Transfer Protocol/Secure (HTTP/S)経由でトンネリングされたRMIです。

J2EE RMIフレームワークにより、事実上透過的な分散サービスおよびアプリケーションが作成できるようになります。RMIベースのアプリケーションは、場所に関係なく、相互にメソッド・コールを実行するJavaオブジェクトで構成されます。これにより、Javaオブジェクトは、同じ仮想コンピュータにあるJavaオブジェクトでメソッドをコールするのと同じ方法で、別の仮想コンピュータにある別のJavaオブジェクトでメソッドをコールできます。

図2-4に、Remote Managerのアーキテクチャの概要を示します。

図2-4 Remote Managerのアーキテクチャ

関連項目:

Remote Managerおよびその構成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のRemote Managerのインストールと構成に関する説明を参照してください。

2.1.2.3 プラットフォーム・サービス

プラットフォーム・サービスには、次の内容が含まれます。

- プラグイン・フレームワーク

- SoDエンジン・フレームワーク

2.1.2.3.1 プラグイン・フレームワーク

プラグイン・フレームワークを使用すると、Oracle Identity Managerのデフォルトの機能を簡単に拡張およびカスタマイズできます。拡張性を提供できるビジネス・ロジックの特定のプラグイン・ポイントは、この機能によって公開されます。各インタフェース定義には、このようなポイントが付随しており、プラグイン・インタフェースと呼ばれます。顧客は、これらのプラグイン・インタフェースを拡張してカスタマイズを定義するコードを、ビジネス・ニーズに基づいて作成できます。これらのプラグインは、プラグイン・マネージャを使用してOracle Identity Managerにデプロイおよび登録されます。その後、これらのプラグインは、Oracle Identity Managerによって、該当するポイント以降に処理する機能に組み込まれます。

機能の開発者は、カスタム実装の格納場所とそのロード方法を追跡する必要はありません。プラグイン・フレームワークは、クラスパス、ファイル・システムおよびデータベースからのプラグインのローディングをサポートしています。

2.1.2.3.2 SoDエンジン・フレームワーク

コンプライアンス・プラクティスの効率的な適用の試みは、職務の分離(SoD)ポリシーの定義を介して実行されます。SoDは、概して権限の矛盾するセットをユーザーが取得しないようにする方法として定義されます。この矛盾するセットは、有害な組合せとも呼ばれます。有害な組合せの例には、同一の注文に対する作成と承認の機能を1個人に付与する例があります。多くの企業には、ビジネス・アプリケーション固有のSoDエンジンがあり、そのビジネス・アプリケーション内で、ユーザーが保持する権限に対してSoDポリシーが定義および適用されます。このようなSoDエンジンの例には、OAACG、SAP GRCなどがあります。

顧客は、SoDエンジン・フレームワークを使用して、選択したSoDエンジンをOracle Identity Managerと統合し、リクエストおよびプロビジョニング・プロセスの適切なポイントでSoDチェックを有効にできます。Oracle Identity Managerは、SoD起動ライブラリ(SIL)を介してSoDチェックのリクエストをSoDエンジンに送信できます。SILは、サポート対象のSoDエンジンすべてに共通のサービス・インタフェースを提供します。Oracle Identity Manager内のビジネス・コンポーネントは、この共通のサービス・インタフェースによって抽象化されます。その結果、SoDエンジンに必要な正しいデータ形式や返された結果の解釈をSoDチェックで処理する必要がなくなります。

SoDチェックは、プロビジョニング・ライフサイクルの様々な時点(アクセスのリクエスト時、承認ワークフローの実行時、プロビジョニングの実行時など)で実行できます。違反が検出されると、リクエストまたはリソースは違反としてマークされ、承認者または管理者によって続行するかどうかが判断されます。リクエストの処理中に違反が検出された場合は、さらに高いレベルで承認できる様々な承認ワークフローを起動できます。

図2-5に、SoD検証プロセスにおけるデータ・フローを示します。

図2-5 Oracle Identity ManagerでのSoD検証プロセス

関連項目:

SoDの詳細は、第22章「職務の分離(SoD)の使用」を参照してください。

2.1.3 ミドルウェア層

Oracle Identity Managerアーキテクチャのミドルウェア層は、次のもので構成されています。

- リクエスト・サービスと承認ワークフロー

- 認可サービス

- UIカスタマイズ・フレームワーク

- スケジューラ・サービス

- レポート

2.1.3.1 リクエスト・サービスと承認ワークフロー

Oracle Identity Managerのアーキテクチャには、承認ワークフローを構成できるリクエスト・サービスが含まれています。Oracle Identity Managerでは、この機能の配信に、Oracle Service Oriented Architecture (SOA) Suiteが使用されます。

Oracle SOA Suiteを使用すると、サービス指向アプリケーションを作成し、任意のミドルウェア・プラットフォームにデプロイできます。多数のコンポーネントで構成されていますが、包括的なワークフロー機能を提供するためにOracle Identity Managerに必要なコンポーネントは、次のとおりです。

- BPEL Process Manager: Oracle BPEL Process Managerは、自動ワークフロー・ステップとヒューマン・ワークフロー・ステップの両方を使用してアプリケーション間ビジネス・プロセスを作成、デプロイおよび管理するための包括的なソリューションを提供します。完了したプロセスと実行中のプロセスの両方の監査証跡や、プロセスの改善を可能にするプロセス履歴も提供します。

- ヒューマン・リクエスト・サービス: BPEL標準では手動タスクはサポートしていませんが、非同期サービスをサポートしています。そのため、Oracle SOA Suiteでは、手動ステップを標準のBPELプロセスに挿入できるように、手動タスク・サービスであるヒューマン・リクエスト・サービスをサポートしています。Oracle Identity Self Serviceにはタスク・リストがあります(ユーザーは、このリストを使用して、ヒューマン・リクエスト・サービスの管理下にある割り当てられたタスクを表示して操作できます)。

- BPEL Designer: Oracle BPEL DesignerはJDeveloperのプラグインとして使用でき、BPELベースのプロセスを作成してデプロイするための視覚デザインのパラダイムを提供します。

Oracle Identity Managerは、SOAタスク・リストをUIに埋め込みます。これによって、SOAスイートでのユーザーの対話が最適化および簡略化されます。承認者は、埋込みSOAタスク・リストを使用してOracle Identity Managerで行われたリクエストを承認できます。

Oracle Identity Managerの埋込みSOAタスク・リストを使用すると、Oracle Identity Managerエンティティの関連データを、デフォルトのWebサービスの最上位にあるOracle Business Rules (OBR)ファクトとしてSOAインスタンスで利用可能にできます。このため、SOAワークフローで承認者と承認のルーティングを解決するために複雑なJavaコードを記述する必要はありません。次のデータは、OBRファクトとしてSOAコンポジットで使用可能です。

- リクエスタおよび受益者のユーザー属性

- リクエストされた項目のベース・エンティティに関連付けられているすべてのメタデータ

- リクエストされた項目のカタログ・エンティティに関連付けられているすべてのメタデータ

図2-6は、リクエスト・サービスとSOAの間の統合を示しています。

図2-6 リクエスト・サービスおよびSOAの統合

リクエスト・サービスには、Oracle Identity Managerでのリクエストの発行および追跡に使用されるサービスも用意されています。ユーザーは、リクエストを使用して、必要な承認を取得した後に実行するアクションや、保持されているプロセス全体の追跡レコードとそのステータスを要求できます。リクエストは、リクエスト・タイプとして定義されている様々なタイプのアクションが対象となります。リクエストのタイプは、次のいずれかです。

- エンティティの作成、変更または削除

- エンティティの有効化または無効化

- ロールのメンバーとしてのアイデンティティの追加または削除

- 権限の付与および取消し

- アプリケーション・インスタンスのプロビジョニング、プロビジョニング解除、有効化、無効化および変更

注意:

アプリケーション・インスタンスは、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)で導入された新しいエンティティです。アプリケーション・インスタンスの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のアプリケーション・インスタンスの管理に関する説明を参照してください。

リクエスト・サービスは、様々なタイプのリクエストをサポートし、複数のリクエスト・タイプに対応する機能があります。Oracle Identity Managerには、最も一般的なユースケースを対象とした事前定義の多様なリクエスト・タイプが用意されています。

リクエスト・サービスでは、同じリクエスト内で複数のタイプのエンティティを要求できる異種リクエストもサポートされています。たとえば、ロールの割当て、アプリケーション・インスタンスのプロビジョニングおよび権限の付与が、単一のリクエストでサポートされます。

リクエスト・サービスは、Oracle Identity Managerの様々なサービスを介して、リクエスト・フローにデータを提供するフロー・モデルを定義します。これには、正確な時間での承認ワークフローの起動、ワークフローのステータスの監視、承認を受領した場合のリクエストの実行などがあります。

リクエストのトランザクション・データと履歴データの両方が保持され、監査およびコンプライアンスの要件がサポートされます。

2.1.3.2 認可サービス

Oracle Identity Managerは、ユーザーがアプリケーションで表示および変更できる内容に対しては強レベルのアクセス制御が必要です。この要件を満たすために、Oracle Identity Managerでは、ユーザーが認可ポリシーを定義して特定のアクションを許可するかどうかを実行時に判断できます。この機能は、Oracle Identity Manager内に埋め込まれているOracle Entitlements Server (OES)を使用する認可サービスによって制御されます。OESは認可製品であり、権限や認可ポリシーを集中管理し、アプリケーション・コンポーネントとアプリケーション・ビジネス・オブジェクトの両方に対するアクセスをきめ細かに決定できます。

OESのアーキテクチャは、2つの主要な要素で構成されています。管理アプリケーションは、ポリシー管理ポイント(PAP)として機能し、ポリシー、構成、ロールおよび権限の管理に使用されます。2つ目の主要な構成要素は、アプリケーション・コンテナに保存されている1つ以上のセキュリティ・モジュール(SM)の活用です。これらのSMは、ポリシー決定ポイント(PDP)できめ細かなアクセス制御ポリシーを評価し、そのポリシーをポリシー強制ポイント(PEP)で適用します。

図2-7に、OESベースの認可サービスのアーキテクチャを示します。

図2-7 OESベースの認可サービス

権限チェックがリクエストされるたびに、次の処理が実行されます。

- Oracle Identity Managerは認可サービスに接続し、保護されているエンティティに対する操作に関するアクセス決定に備えます。

- 次に、サービスはリソースに適用する1つ以上のポリシーを検索して評価します。

- 実行時には、セキュリティ・モジュールによって、ポリシーの評価に必要なすべての情報が収集されます。

- ポリシーが、ロールごとに対象を参照する場合は、すべてのロールが評価され、アクセス決定が実行されます。

Oracle Identity Managerは、OESの最上部に抽象化サービスを提供し、Oracle Identity Managerのポリシーの定義を最適化および単純化します。このサービスにはポリシー定義UIが含まれており、これによって、機能に固有で、ユーザーやロールなどのエンティティに関する属性や機能のきめ細かな制御をサポートする認可ポリシーを定義できます。

2.1.3.3 UIカスタマイズ・フレームワーク

Oracle Identity ManagerはApplication Development Framework (ADF)を使用して、単純でビジネスフレンドリなUIカスタマイズ機能を提供しており、コードを記述する必要はありません。カスタマイズに使用するコンポーネントは、次のとおりです。

- Oracle Web Composer: Oracle Identity Managerでは、WebブラウザベースのUIカスタマイズ、および非IDEまたはJDeveloperベースのカスタマイズがサポートされています。JDeveloperは、ページ、ページ・フラグメント、リージョン、タブなどのUIアーティファクトを作成するために使用します。これらのアーティファクトをOracle Identity Managerにデプロイした後に、Oracle Web Composerを使用してこの新しいコンテンツをさらにカスタマイズすることができます。

注意:

JDeveloperを使用する場合は、事前定義されたページをカスタマイズするのではなく、APIを使用して最初からページを構築することができます。IDEベースのUIカスタマイズと、WebブラウザベースのUIカスタマイズの間に、相互運用性はありません。

Oracle Web Composerでは、ページのブラウザベースのランタイム・カスタマイズまたはパーソナライズ、ページ・レイアウトの変更、ページへの項目の追加、ブランド設定を実行できます。カスタマイズは、一時的に保存、確認、およびデプロイメント固有、テナント固有またはユーザー固有としてファイナライズすることができます。UIカスタマイズではコードとUIメタデータが別に保持されるため、パッチおよびアップグレード間で永続的なカスタマイズが提供されます。

- ADFビジネス・エディタ: ADFビジネス・エディタを使用すると、ユーザー、ロール、組織、カタログおよびアプリケーション・インスタンス・エンティティのカスタム属性を拡張または追加できます。また、ユーザー、リソース・オブジェクトおよびアプリケーション・インスタンスのリクエスト・データセットを構成することもできます。

- メタデータ・ストア(MDS): カスタマイズとパーソナライズは、Oracle MDSを使用してファイル・システムまたはデータベースに格納されます。

図2-8は、UIカスタマイズ・フレームワークのコンポーネントを示しています。

図2-8 UIカスタマイズ・フレームワーク

2.1.3.4 スケジューラ・サービス

ビジネス・システムでは、指定の時間に他のプログラムを実行するように構成されたスケジューリング・システムが頻繁に活用されます。スケジューリング・システムでは、レポートの生成、データの再フォーマット、または監査を実施するアプリケーションが定期的に実行されます。多くの場合、スケジューリング・システムは、定められた時間に自動的に定型作業を実行するバッチ・ジョブ(スケジュールされたジョブ)を実行します。スケジューリング・システムは、エンタープライズ・プロビジョニング・ソリューションに不可欠です。プロビジョニングには、通常、時間ベースの方法で実行するタスクが含まれています。次に例を示します。

- 管理されたアプリケーションで直接行われた変更をすべてリコンサイルする夜間ジョブの実行

- 指定の時間内に割り当てられたジョブが処理されなかった場合のエスカレーションの実行

- 特定時間に開始するリクエストの実行

Oracle Identity Managerプラットフォームには、エンタープライズ・プロビジョニング要件を満たすためのスケジュール機能を提供するスケジューラが含まれています。このサービスは、独立した製品ではなく、Oracle Identity Managerプラットフォームの一部として管理されます。図2-9に、Oracle Identity Managerスケジューラのアーキテクチャの概要を示します。

図2-9 Oracle Identity Managerスケジューラのアーキテクチャ

スケジューラ・サービスによって提供される主な機能は、次のとおりです。

- 数千のジョブを実行するための単純または複雑なスケジュールを作成する機能

- スケジューリング・サービスをクラスタ化されたサービスとして実行し、必要な高可用性機能(フェイルオーバーやロード・バランシングなど)を提供する機能

- 管理およびフェイルオーバー・サポートのためにジョブの定義を永続化する機能

- ジョブを作成、変更、有効化、無効化および削除し、個々のジョブ実行を管理UIを使用して管理する機能

- 定期的にスケジュールされた実行以外に、非定型方式でジョブを実行する機能

- エラーと障害を管理する機能

- ジョブ実行の履歴(実行の統計と結果を含む)を保持する機能

- スケジューラ・サービス自体を管理する機能

2.1.3.5 レポート作成

Oracle Identity Managerリポジトリに格納されている一連の豊富なデータは、管理要件およびコンプライアンス要件をサポートする詳細なレポートを介して表示できます。Oracle Identity Managerは、Oracle BI Publisher(すべてのレポートとビジネス文書をオーサリング、管理および配信する単一のレポート環境を提供するエンタープライズ・レポート・ソリューション)を使用したデータ・レポートをサポートしています。Microsoft Word、Microsoft ExcelまたはAdobe Acrobatなどの、一般的な一連のデスクトップ・ツールを利用して、Oracle Identity Management製品を含む様々なソースのデータに基づいてレポート・レイアウトを作成および管理できます。

Oracle Identity Managerには、標準的な一連のOracle BI Publisherレポート・テンプレートが用意されています。各テンプレートは、カスタマイズしてルック・アンド・フィールを変更できます。Oracle Identity Managerデータベース・スキーマを活用して独自のカスタム・レポートを作成することもできます。

2.1.4 データ層

Oracle Identity Managerはデータおよびメタデータによって駆動されるため、Oracle Identity Managerの機能には柔軟性と適合性が提供されます。Oracle Identity Managerリポジトリまたはデータベースで構成されたOracle Identity Managerのデータ層は、ANSI SQL 92準拠のリレーショナル・データベースおよびLDAPアイデンティティ・ストア(オプション)でOracle Identity Managerデータとメタデータを管理および格納します。

この項では、データ層について次の各トピックで説明します。

- Oracle Identity Managerデータベース

- メタデータ・ストア

- アイデンティティ・ストア

- LDAPアイデンティティ・ストアとOracle Identity Managerの統合

2.1.4.1 Oracle Identity Managerデータベース

Oracle Identity Managerリポジトリは、アイデンティティ管理およびプロビジョニング・システムの中核となる値である「いつ、誰が、何を、なぜ、どのように所持しているか」に関するデータの認証ストアです。Oracle Identity Managerデータベースに格納されるデータは、次の幅広いカテゴリに分類されます。

- エンティティ・データ: ユーザー、組織、ロール、ロール・メンバーシップ、リソース、プロビジョニング済リソース

- トランザクション・データ: リクエスト、承認ワークフロー・インスタンス、プロビジョニング・ワークフロー・インスタンス、ヒューマン・タスク

- 監査データ: リクエスト履歴、ユーザー・プロファイル履歴

高可用性

データベースは、停止時間やパフォーマンスの問題を回避するために、スケーラブルで冗長なデータ・レイヤーを提供します。信頼性、リカバリ可能性、タイムリなエラー検出および継続的稼働は、高可用性ソリューションの主な特徴です。

Oracle Identity Managerのアーキテクチャは、製品と併用されるデータベース管理システムが提供する機能に依存しています。これらの機能には、次のことが必要です。

- すべてのコンポーネントに冗長性を持たせること

- コンピュータ障害、ストレージ障害、人的エラー、データ破損、書込み欠落、システムの停止または減速、およびサイト障害からの保護および耐性を備えていること

- できるかぎり素早く透過的に停止からリカバリすること

- 計画停止時間をなくしたり短縮するソリューションを備えていること

- 一貫性のある高いパフォーマンスを備えていること

- デプロイ、管理および拡張が容易であること

- 考えられる最も低い所有者の総費用でサービス水準合意(SLA)を実現すること

多種多様な高可用性ソリューションやビジネス継続性ソリューションを使用できます。Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardなどのテクノロジを使用して、データベース可用性を最大化する方法の詳細は、次のWebサイトを参照してください。

http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

2.1.4.2 メタデータ・ストア

Oracle Identity Managerの基礎となるロジックは、メタデータ・ドリブンです。構造的および動作的な側面は、メタデータを使用して記述されます。Oracle Identity Managerのアーキテクチャでは、Oracle Metadata Services (MDS)に依存してメタデータに統一の格納場所を提供します。これにより、Oracle Identity Managerのメタデータおよび構成している他のFusion Middlewareコンポーネントのメタデータに対して、一貫した信頼性のあるアクセスが確保されます。アプリケーションの設計フェーズで使用される同じメタデータが、アプリケーションの実行時にメタデータ・サービス・レイヤーを介して使用されます。これにより、Oracle Identity Managerのライフサイクルを通じて一貫性が確保されます。MDSには、一般的なメタデータ管理ツールも用意されており、共通のリポジトリに格納されている様々なタイプのメタデータ全体に使用できます。

MDSの主要な機能およびアーキテクチャ指針には、次の内容が含まれます。

- 様々なFusion Middlewareコンポーネントで使用されるすべてのアーティファクトに対して統一された単一のリポジトリを使用した、簡素化されたリソース管理

- 開発、テスト、ステージングおよび本番の様々な段階を通して変化する、各アーティファクトのメタデータ・ライフサイクルの管理

- 複数のコンポーネントにわたるメタデータの共有と再使用

- アーティファクトの分類と再使用、再使用の奨励、および一貫性の促進

- 様々な機能の基礎を形成するバージョニング機能

- メタデータおよびアプリケーション・ロジックをメタデータの使用方法ごとに調整できる、安全にアップグレート可能な階層化されたカスタマイズ・メカニズム

- パフォーマンスを最適化するための構成可能なチューニング・オプションと一体化された高度なキャッシュおよびアセンブルの技術

MDS経由でアクセスおよび管理するメタデータは、ファイル・ベースのリポジトリまたはデータベース・ベースのリポジトリのいずれかに格納されます。Oracle Identity Managerのアーキテクチャでは、このモードで提供されるパフォーマンスおよび可用性に関する複数の高度な機能を利用するために、メタデータはOracle Identity Managerデータベース内に存在します。

MDSでは、特定のビジネス・グループの要件に合せるためのアプリケーションの変更、ユーザーの個々のプリファレンスに合せるためのアプリケーションのカスタマイズ、実行時にカスタマイズ可能なアプリケーションの作成など、カスタマイズ要件を満たすアプリケーションを作成できる機能が用意されています。MDSの機能を使用したOracle Identity Managerのカスタマイズの詳細は、「インタフェースのカスタマイズ」を参照してください。

2.1.4.3 アイデンティティ・ストア

Oracle Identity Managerには、LDAPベースのアイデンティティ・ストアをOracle Identity Managerアーキテクチャに統合する機能があります。Oracle Identity Managerから直接LDAPベースのアイデンティティ・ストアを接続および管理できます。この機能を使用すると、アイデンティティのリクエスト・ベースの作成および管理を含めたOracle Identity Managerの高度なユーザー管理機能を使用して、企業のアイデンティティ・ストア内でアイデンティティを管理できます。

このデプロイメント・アーキテクチャでは、ユーザー・アイデンティティ情報が、LDAPストアに加えてOracle Identity Managerデータベースにも格納されるため、Oracle Identity Managerが機能するために必要なリレーショナル機能がサポートされます。すべてのデータは、プロビジョニング・アクションの実行やポリシーおよびルールの設定なしで、透過的に同期が維持されます。ユーザーの作成や変更など、Oracle Identity Manager内で開始されるアイデンティティ操作は、トランザクションの整合性を維持する形で両方のストアで実行されます。さらに、Oracle Identity Manager外部で行われたLDAPストアの変更は、Oracle Identity Managerにプルされ、アイデンティティ・コンテキストの一部として使用できるようになります。

2.1.4.4 LDAPアイデンティティ・ストアとOracle Identity Managerの統合

Oracle Identity Managerのユーザーおよびロールは、Oracle Identity Managerデータベースに格納されます。ただし、Oracle Identity Managerでユーザー、ロールまたはロール・メンバーシップの変更が発生した場合、この情報はLDAPアイデンティティ・ストアに伝播されます。ユーザー、ロールまたはロール・メンバーシップの変更がLDAPで直接発生した場合、これらの変更はOracle Identity Managerに同期化されます。同期化には、次のことが含まれます。

- ユーザーの作成、変更、削除、有効または無効へのステータス変更、およびパスワード変更が、Oracle Identity Managerの内部表に加え、LDAPでも実行されます。

- ロールの作成、変更および削除アクションにより、LDAPグループがメンバーシップ変更も含めて更新されます。

- ユーザー、ロールおよびロール・メンバーシップの初期ロードが同期化されます。

- LDAPでのユーザー・プロファイルに対する直接変更がOracle Identity Managerにリコンサイルされます。

- LDAPでのロールおよびロール・メンバーシップに対する直接変更がOracle Identity Managerにリコンサイルされます。

ユーザーおよびロール・データで変更が発生すると、実際の操作はカーネル・ハンドラを活用して実行されます。これらのハンドラは、検証、前処理、アクションおよび後処理など、オーケストレーション・ライフサイクルの様々な段階を通過します。カーネル編成の様々なステージの詳細は、「イベント・ハンドラの開発」を参照してください。

Oracle Identity Managerカーネル・オーケストレーションはエンティティ・マネージャに接続し、そのエンティティ・マネージャがさらにLDAPプロバイダに接続します。LDAPプロバイダはOracle Virtual Directory (OVD)に接続します。OVDは、Oracle Internet Directory、iPlanet、Active Directoryなど、様々なディレクトリ・システムへのインタフェースです。LDAPプロバイダはOVDを使用してLDAPデータにアクセスします。図2-10に、Oracle Identity ManagerとLDAP間の通信を示します。

図2-10 Oracle Identity ManagerとLDAP

Oracle Identity ManagerとLDAPアイデンティティ・ストア間での統合の構成およびデータの同期化の詳細は、次の各項を参照してください。

- LDAPとの統合の構成

- Oracle Identity ManagerからLDAPアイデンティティ・ストアへのデータのプロビジョニング

- LDAPアイデンティティ・ストアからOracle Identity Managerへのリコンシリエーション

2.1.4.4.1 LDAPとの統合の構成

Oracle Identity ManagerとLDAP間の統合の構成は、Oracle Identity Managerのインストール時に実行されます。Oracle Identity Managerは、LDAP付きまたはLDAPなしでのインストールを選択できます。Oracle Identity ManagerをLDAP付きでインストールする場合は、OVDおよびOracle Internet Directoryをインストールして、予約されたユーザーを格納するコンテナを作成し、Oracle Identity Managerの操作を実行する新規ユーザーをOracle Identity Managerに作成し、Oracle Identity ManagerにあわせてOVDおよびOracle Internet Directoryを構成する必要があります。これらの構成設定の実行方法は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のLDAP同期化の設定に関する説明を参照してください。

LDAPが有効な状態のOracle Identity Managerをインストールした後は、次の各スケジュール済ジョブを開き、Oracle Internet Directoryの最終変更ログ番号の値を使用して、各ジョブの「最終変更番号」パラメータを更新する必要があります。

- LDAPユーザー作成および更新のリコンシリエーション

- LDAPユーザー削除のリコンシリエーション

- LDAPロール・メンバーシップのリコンシリエーション

- LDAPロール階層のリコンシリエーション

- LDAPロール作成および更新のリコンシリエーション

- LDAPロール削除のリコンシリエーション

さらに、「最終変更番号」パラメータを更新した後は、これらのスケジュール済ジョブを有効にする必要があります。これを行うには、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのジョブの無効化と有効化に関する項を参照してください。

関連項目:

スケジュール済ジョブの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。

2.1.4.4.2 Oracle Identity ManagerからLDAPアイデンティティ・ストアへのデータのプロビジョニング

Oracle Identity Managerデータベースには、ユーザーおよびロールの情報が格納されています。Oracle Identity Managerでユーザーおよびロールの情報が更新された場合は、LDAPディレクトリなどの外部リポジトリも更新する必要があります。

LDAPの変更は、Oracle Identity Managerの変更の前に実行されます。Oracle Identity Managerで変更が失敗した場合は、LDAPへの変更を元の状態に戻す必要があります。これは、有効化操作を無効化操作で、作成操作を削除操作でそれぞれ修正し、変更操作を当初の値を使用した変更操作で修正することによって実現します。

たとえば、ユーザーが作成された場合、検証段階では、パスワードや他のポリシーの検証などの検証プロセスが実行されます。前処理段階では、最初にLDAPにユーザーが作成されます。そのユーザーは、次のアクション段階で、Oracle Identity Managerに作成されます。Oracle Identity Managerでのユーザーの作成でエラーが発生した場合、Oracle Identity Managerには対応するユーザーが作成されていないため、そのユーザーはLDAPから削除する必要があります。変更を元に戻す操作は、Oracle Identity Managerに事前定義されている補正メソッドを使用したカーネル・ハンドラによって提供されます。

注意:

各ハンドラには、実行メソッドと補正メソッドが事前定義されています。実行メソッドでは、任意の操作(ユーザーの作成など)が実行されます。補正メソッドは、エラーが発生した場合にコールされ、実行メソッドが実行した操作を元に戻します。

Oracle Identity ManagerからLDAPに日付を同期化するには、LDAPの場所をOracle Identity Managerで把握している必要があります。LDAPの場所に関する情報は、DirectoryServer ITリソースとしてOracle Identity Managerに格納されています。これは、Oracle Identity Managerによって提供されるデフォルトのITリソースです。Oracle Identity Managerのインストール時に指定可能な、このITリソースの様々なパラメータを使用すると、Oracle Identity ManagerとLDAPを接続できます。

識別名(DN)およびGUID属性は、Oracle Identity ManagerとLDAPで同じエントリを識別するために使用されます。LDAPの各エントリにはDN属性があり、LDAP内でのエントリの一意の場所を示します。GUID属性は、エントリを識別するための一意のIDです。ユーザーおよびロールのDNとGUIDは、Oracle Identity Managerデータベースのユーザーおよびロールの表の列に格納されます。Oracle Identity ManagerとLDAP間でユーザー定義フィールドを同期化する方法の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity ManagerとLDAP間でのユーザー定義フィールドの同期化に関する項を参照してください。

この項の内容は次のとおりです。

- ユーザーの管理

- ロールの管理

2.1.4.4.3 ユーザーの管理

Oracle Identity ManagerからLDAPにデータを同期化するには、次のユーザー操作を実行できます。

- ユーザーの作成

- ユーザーの更新

- ユーザーの削除

- ユーザーの有効化

- ユーザーの無効化

- ユーザーのロック

- ユーザーのロック解除

- ロール・メンバーの追加

- ロール・メンバーの削除

- パスワードの変更

2.1.4.4.4 ロールの管理

Oracle Identity ManagerからLDAPにデータを同期化するには、次のロール操作を実行できます。

- ロールの作成

- ロールの更新

- ロールの削除

- メンバーへのロールの追加

- ロールの追加と更新

- メンバーからのロールの削除

- ロール階層の追加

- ロール階層の削除

2.1.4.4.5 LDAPアイデンティティ・ストアからOracle Identity Managerへのリコンシリエーション

LDAPアイデンティティ・ストアでアイデンティティが直接変更された場合は、認証ソースのリコンシリエーションを介して、その変更をOracle Identity Managerにレプリケートする必要があります。アイデンティティには、ユーザーおよびロールが含まれます。

LDAPからOracle Identity Managerへのユーザーのリコンサイルは、リコンシリエーションのスケジュール済タスクが含まれているリコンシリエーションの一般構成で機能します。

関連項目:

スケジューラおよびスケジュール済タスクの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。

注意:

LDAPからOracle Identity Managerにユーザーをリコンサイルする際に、LDAP同期化リコンシリエーション・ジョブではなく、バルク・ロード・ユーティリティを使用すると、LDAP同期化が有効な場合は、これらのユーザーに関する後続の操作に失敗する可能性があります。これを回避するには、Oracle Identity Managerにロードされているすべてのユーザーを正しいGUIDおよびDNの値で更新し、LDAP内のこれらのユーザーすべてをorclIDXPersonと呼ばれるオブジェクト・クラスで更新する必要があります。

バルク・ロード・ユーティリティの詳細は、「バルク・ロード・ユーティリティの使用」を参照してください。

ロールのリコンシリエーションは、LDAPグループでのみ機能します。ロールのリコンシリエーションでは、ロールの作成、更新および削除がサポートされています。ロール・メンバーシップのリコンシリエーションでは、外部のLDAPディレクトリで発生した変更から導出されたロール・メンバーシップの作成と削除がサポートされています。

Oracle Identity Managerにロールおよびユーザーが存在しない場合、ロール・メンバーシップのリコンシリエーションは失敗します。したがって、LDAP同期化スケジュール済ジョブは、次の順序で実行するように構成してください。

1. Fusion Applicationsロール・カテゴリ・シーディング

注意:

Fusion Applicationsロール・カテゴリ・シーディングは事前定義済のスケジュール済タスクで、LDAP同期化が有効な場合のみ、他のLDAP同期化スケジュール済ジョブとともに生成されます。このジョブは、LDAP内の異なるビジネス・カテゴリをすべて取得し、OIMロール・カテゴリとして作成します。

事前定義されたスケジュール済ジョブのリストは、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの事前定義済のスケジュール済タスクに関する項を参照してください。

2. LDAPロール作成および更新のリコンシリエーション

3. LDAPロール階層のリコンシリエーション

4. LDAPユーザー作成および更新のリコンシリエーション

5. LDAPロール・メンバーシップのリコンシリエーション

Fusion Applicationsロール・カテゴリ・シーディングを除くこれらの各ジョブには、完全リコンシリエーションを実行するためのパラレル・ジョブがあります。Fusion Applicationsロール・カテゴリ・シーディングを除くこれらすべてのジョブは、変更ログに基づいてリコンシリエーションを実行しますが、完全リコンシリエーション・ジョブは、検索ベースを使用してリコンシリエーションを実行します。

2.1.4.4.6 統合されたLDAP同期化完全リコンシリエーション

統合されたLDAP完全リコンシリエーションのスケジュール済ジョブは、次のジョブを順番に実行します。

1. LDAPユーザー作成および更新の完全リコンシリエーション

2. LDAPロール作成および更新の完全リコンシリエーション

3. LDAPロール・メンバーシップの完全リコンシリエーション

4. LDAPロール階層の完全リコンシリエーション

関連項目:

統合されたLDAP完全リコンシリエーションのスケジュール済ジョブの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのLDAPスケジュール済タスクに関する項を参照してください。

統合されたLDAP完全リコンシリエーションのスケジュール済ジョブを実行すると、次のジョブを特定の順序で実行する必要があるため、以前のジョブのジョブ・ステータスや特定ジョブのイベント・ステータスがすべてチェックされます。実行できないジョブがあれば、ジョブの停止が自動実行され、診断ログにエラー・メッセージが記録されます。

注意:

LDAPユーザー削除の完全リコンシリエーション・ジョブとLDAPロール削除の完全リコンシリエーション・ジョブは、統合されたLDAP完全リコンシリエーションの一部ではありません。これらのスケジュール済ジョブは、デフォルトで使用禁止にされています。ラジオ・ボタンを選択すると有効にでき、それぞれを実行することもできます。

統合されたLDAP同期化完全リコンシリエーション・ジョブの詳細ページのラジオ・ボタンを選択して、それぞれのジョブを実行することもできます。ジョブの詳細ページには、4種類の完全リコンシリエーションのリコンシリエーション・ジョブに対するすべての共通パラメータがあります。また、統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブの次のパラメータに対して値を指定できます。

- リコンシリエーション検索ベース: ユーザーまたはロールの完全リコンシリエーションに対する検索ベース。これにより、LDAPが検索を開始するLDAPディレクトリ内の場所が定義されます。

- リコンシリエーション・ロール検索フィルタ: ロールの完全リコンシリエーションに対する検索フィルタ。このフィルタにより、LDAPディレクトリのサブツリー内の特定のロール/グループ・エントリを可能にし、その他を除外できます。

- リコンシリエーション・ユーザー検索フィルタ: ユーザーの完全リコンシリエーションに対する検索フィルタ。このフィルタにより、LDAPディレクトリのサブツリー内の特定のユーザー・エントリを可能にし、その他を除外できます。

統合されたLDAP同期化完全リコンシリエーション・ジョブを実行すると、リコンシリエーション検索ベースおよび/またはリコンシリエーション・ユーザー検索フィルタおよびリコンシリエーション・ロール検索フィルタのパラメータに入力された値に基いて、LDAPからOracle Identity Managerにユーザー・アカウントおよびロール・アカウントが投入されます。この完全リコンシリエーションの結果、LDAPの特定のノードから削除されたエントリに対してOracle Identity Managerデータベースで削除されます。

リコンシリエーション検索ベースおよびリコンシリエーション検索フィルタのパラメータによるサポートは、次のとおりです。

- LDAPからOracle Identity Managerデータベースへのユーザー・アカウントまたはロール・アカウントのリコンサイル
これにより、特定のユーザーまたはロールのきめ細かなリコンシリエーションを実行するオプションが提供されます。リコンシリエーション検索ベース・パラメータの値は、次のようになります。

"cn=cokeuser1,cn=users,cn=subrealm1,dc=us,dc=oracle,dc=com"

- ノード下のすべてのユーザーおよびロールまたはグループのリコンサイル
リコンシリエーション検索ベースの値は、次のようになります。

"cn=tenant1,dc=us,dc=oracle,dc=com"

ここで、ユーザーの完全リコンシリエーションとロールの完全リコンシリエーションが起動されます。その結果、tenant1ノード下のすべてのユーザーおよびロールまたはグループがリコンサイルされます。

- ノード下のすべてのユーザーのリコンサイル
リコンシリエーション検索ベースの値は、次のようになります。

"cn=users,cn=tenant1,dc=us,dc=oracle,dc=com"

ここで、tenant1ノード下のすべてのユーザーがリコンサイルされます。

- ノード下のすべてのロールまたはグループのリコンサイル
リコンシリエーション検索ベース・パラメータの値は、次のようになります。

"cn=groups,cn=tenant1,dc=us,dc=oracle,dc=com"

ここで、tenant1ノード下のすべてのロールまたはグループがリコンサイルされます。

リコンシリエーション検索ベースおよびリコンシリエーション検索フィルタのパラメータは、LDAP同期化完全リコンシリエーションにはバインドされていません。リコンシリエーション検索フィルタは空白にできます。検索ベースは、Oracle Identity ManagerからLDAPへのプロビジョニングまたはエントリの投入に使用できます。一方、リコンシリエーション検索ベースは、LDAPからOracle Identity Managerデータベースへの完全リコンシリエーションの実行に使用できます。リコンシリエーション検索ベースに値が指定されない場合、プロビジョニングと完全リコンシリエーションの両方に対して「ディレクトリ・リソース」のITリソース構成から検索ベースの値が使用されます。リコンシリエーション検索ベース・パラメータのサンプル値は、次のようになります。

"cn=tenant1,dc=us,dc=oracle,dc=com"

検索ベース・パラメータのサンプル値は、次のようになります。

"dc=us,dc=oracle,dc=com"

リコンシリエーション・ユーザー検索フィルタおよびリコンシリエーション・ロール検索フィルタのパラメータのサンプル値は、次のようになります。

(objectclass=orclAPPIDPerson)
(title=foobar)

統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブに対してログ記録されたメッセージ

次のリストは、統合されたLDAP同期化完全リコンシリエーションのスケジュール済ジョブに対して、Oracle Identity Manager診断ログ・ファイルに記録されたメッセージです。

LDAP Sync Full Reconciliation Scheduler job {0} is currently Running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Stopped.
LDAP Sync Full Reconciliation Scheduler job {0} is currently being Interrupted while running.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has Failed.
Error occurred while running the LDAP Sync User Full Reconciliation scheduler job. Please refer to the OIM Server logs for more details.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running. It has been Shutdown.
LDAP Sync Full Reconciliation Scheduler job {0} is not currently Running.
SQLException has occurred.
All LDAPSync Full Reconciliation jobs ran successfully and Stopped.

2.2 システム・コンポーネント

Oracle Identity Managerは、オープンでスケーラブルな企業規模のモジュール型アーキテクチャに基づいて構築されています。各モジュールは、システムの全体の機能において重要な役割を果します。図2-11に、Oracle Identity Managerのシステム・コンポーネントを示します。

図2-11 Oracle Identity Managerのシステム・コンポーネント

Oracle Identity Managerのユーザー・インタフェースは、プロビジョニング環境を定義および管理します。Oracle Identity Managerには、次の2つのユーザー・インタフェースがあり、管理者とユーザーの両方の要件を満しています。

- 開発者およびシステム管理者のための強力なJavaベースのOracle Identity Manager Design Console

- アイデンティティ管理者およびユーザーそれぞれに対するWebベースの管理およびOracle Identity Managerセルフ・サービス・インタフェース

この項では、Oracle Identity Managerの次のコンポーネントについて説明します。

- アイデンティティ管理

- プロビジョニング

- 監査およびレポート

- リコンシリエーションおよびバルク・ロード

- 共通のサービス

- ワークフローおよびリクエスト管理

- インフラストラクチャおよびミドルウェア統合

- コネクタ・フレームワーク

アイデンティティ管理

アイデンティティ管理には、Oracle Identity Managerでのアイデンティティの作成および管理が含まれます。アイデンティティには、ユーザー、組織およびロールがあります。アイデンティティ管理では、パスワードの管理およびユーザーによるOracle Identity Managerセルフ・サービス操作も可能です。アイデンティティ管理は、Oracle Identity Manager管理、Oracle Identity Managerセルフ・サービスWebクライアントおよびSPML Webサービスを使用して実行されます。

プロビジョニング

プロビジョニング・トランザクションは、プロビジョニング・モジュールで作成および変更されます。このモジュールでは、「誰が」、「何を」プロビジョニングするかが保持されます。ユーザー・プロファイル、アクセス・ポリシーおよびリソースは、ビジネス・プロセス・ワークフローやビジネス・ルールと同様に、プロビジョニング・モジュールで定義されます。

プロビジョニング・サーバーは、Oracle Identity Managerの実行時エンジンです。これは、Oracle Identity Manager管理およびOracle Identity Manager Design Consoleを介して定義され、プロビジョニング・モジュール内に保持されているプロビジョニング・プロセス・トランザクションを実行します。

監査およびレポート

監査およびコンプライアンスの機能には、個人、組織、システム、プロセス、プロジェクトまたは製品の評価が含まれます。この機能は、スイーツのワークフロー・エンジン、ポリシー・エンジンおよびリコンシリエーション・エンジンによって生成されたデータを取得することで発生します。このデータをアイデンティティ・データと組み合せることで、企業は、アイデンティティに対する処理および関連する監査照会へのアクセスに必要な情報をすべて入手できます。監査は情報の有効性と信頼性を確認するために実施され、システムの内部制御の査定も提供します。

レポートは正式な文書を生成するプロセスで、監査の結果として作成されます。その後、レポートは、ユーザー(個人、グループ、企業、政府、一般市民など)が監査の結果に基づいて意思決定できるように、保証サービスとしてユーザーに提供されます。企業では、プロビジョニング環境の過去と現在の両方の状態についてレポートを作成できます。取得したアイデンティティ・データの中には、ユーザー・アイデンティティ・プロファイルの履歴、ロールのメンバーシップ履歴、ユーザーのリソース・アクセスおよび詳細な権限の履歴などがあります。

リコンシリエーションおよびバルク・ロード

リコンシリエーション・エンジンは、Oracle Identity Managerのプロビジョニング環境と企業内のOracle Identity Managerの管理リソースの間の整合性を保証します。また、Oracle Identity Managerの外で作成された不正アカウントを検出します。また、リコンシリエーション・エンジンは、プロビジョニング・システムの内外にあるビジネス・ロールを同期化して整合性を確認します。

組織の他のリポジトリからOracle Identity Managerに大量のデータをロードする場合は、バルク・ロード・ユーティリティを使用できます。バルク・ロード・ユーティリティは、データ・ロードでの停止時間を短縮します。さらに、バルク・ロード・ユーティリティは、Oracle Identity Managerのユーザー、ロール、メンバーシップおよびユーザーにプロビジョニングされたアカウントをインポートします。

共通のサービス

Oracle Identity Managerの他のコンポーネントで共有され、使用される様々なサービスはまとめてグループ化されます。これには次のサービスがあります。

- フォーム・デザイナ: Oracle Identity Managerにあらかじめ含まれていないプロセスおよびリソース・オブジェクトのフォームを作成できるフォーム。

- スケジューラ: 特定のスケジューラで特定のジョブを実行する機能を提供するサービス。ユーザー、アプリケーション開発者、コネクタ開発者および管理者は、このサービスを使用してジョブを作成し、指定した間隔で実行するように構成できます。このサービスでは、ジョブの機能およびそのスケジュールを管理する管理機能も提供されます。

- 通知テンプレート: Oracle Identity Managerで発生するイベントについて関係者に通知を送信するために、共通の通知サービスが他の機能コンポーネントによって使用されます。また、このサービスでは、通知テンプレートを管理する機能も提供されます。送信通知の送信には通知テンプレートが使用されます。通常、これらのテンプレートには、よりコンテキストに依存した内容を提供するために使用可能なデータを参照する変数が含まれています。

- システム・プロパティ: システム・プロパティは、アプリケーションの構成を制御するエンティティです。デフォルトのシステム・プロパティに加え、Oracle Identity Managerのシステム・プロパティも作成および管理できます。

- デプロイメント・マネージャ: デプロイメント・マネージャは、Oracle Identity Manager構成のエクスポートおよびインポートに使用するツールです。デプロイメント・マネージャを使用すると、Oracle Identity Managerの構成を形成するオブジェクトをエクスポートできます。

ワークフローおよびリクエスト管理

Oracle Identity Managerの様々な操作は直接実行できません。かわりに、操作をリクエストする必要があります。リクエスト管理サービスでは、リクエストを作成、承認および管理するためのメカニズムを提供します。リクエストは特定のアクションを実行する必要があるユーザーまたは管理者が作成したエンティティで、アクションを実行するには、誰かまたはなんらかのプロセスから事前に任意の権限を取得しておく必要があります。たとえば、ユーザーはラップトップ・コンピュータへのアクセス権を取得するためのリクエストを作成し、マネージャはリクエストを承認してオープン購買依頼を作成し、ITリソース管理者はリクエストを承認できます。

プロビジョニング・ソリューションの主要な目標は、リクエストおよびプロビジョニング・リソースを管理することです。リクエスト・サービスは、Business Process Execution Language (BPEL) 11gワークフロー・エンジンに対して抽象レイヤーを提供します。リクエスト、プロビジョニングおよび証明などの機能コンポーネントは、人による承認を得るためワークフロー・エンジンと相互に作用します。リクエスト・サービスは、ワークフロー・インスタンスおよびカテゴリを管理することでOracle Identity Managerの様々な機能コンポーネントに対応し、BPELに対して抽象レイヤーを提供します。

インフラストラクチャおよびミドルウェア統合

アダプタ・ファクトリ、カーネル・オーケストレーション・メカニズム、コンテキスト・マネージャおよびプラグイン・フレームワークは、これらのシステムとのハードコード統合の必要性を排除するように設計されています。

コネクタ・フレームワーク

Oracle Identity Managerの統合ソリューション戦略では、様々な異種アイデンティティを認識するITシステムに対するコネクタが提供されます。この戦略は、最小限のカスタム開発、最大限のコード再利用、および開発時間の短縮を目的としています。統合ソリューションの層は、次のとおりです。

- 事前定義済コネクタと事前定義済汎用テクノロジ・コネクタのプロバイダを使用する基本設定の統合

- アプリケーションの実装を、そのアプリケーションの接続試行先のシステムへの依存性から切り離すように設計されているアイデンティティ・コネクタ

- カスタムの汎用テクノロジ・コネクタのプロバイダに基づいたコネクタ

- アダプタ・ファクトリを使用するカスタム・コネクタ

3 セキュリティのアーキテクチャ

Oracle Identity Managerは、アプリケーションにおける様々な操作の実行をユーザーに許可または禁止するために、ユーザーによるアプリケーションへのアクセスを制御します。これは、Oracle Identity Managerに埋め込まれている認可エンジンによって、認可ポリシーを使用して制御されます。認可ポリシーの目的は、データ、UIおよびAPIを含む、Oracle Identity Managerアプリケーションへのユーザーのアクセスを制御することです。認可ポリシーによって、特定のアクションが許可されるかどうかが実行時に決定されます。Oracle Identity Managerでの認可要件を満たす認可ポリシーを定義できます。

Oracle Identity Managerでは、認可ポリシー管理は、管理機能として集中管理されます。Oracle Identity Managerの認可ポリシー管理と施行エンジンは、Oracleの権限管理製品である、埋込みバージョンのOracle Entitlements Server (OES)のをベースにしています。これらの認可ポリシーによって、Oracle Identity Managerアプリケーションに対するアクセス制御が保護され、アプリケーション内で誰がどのデータに対して何をできるかが定義されます。

Oracle Identity Managerでは、次がサポートされています。

- 機能セキュリティについては標準のADFセキュリティ・モデルを使用し、データ・セキュリティについてはOESベスト・プラクティスを使用します。

- Oracle Identity Managerで様々なエンティティ(ロール、組織、権限、アプリケーション・インスタンス、LDAPグループなど)の委任管理をサポートする、一貫したアーキテクチャを使用します。

- 誰が何をリクエスト可能か、誰が何を所有できるか、誰が承認を通過する必要があるかなど、様々なセキュリティ上の決定をバックエンドで行うことができる一貫したアーキテクチャを使用します。このアーキテクチャは、カタログベースのリクエスト・モジュールおよびまとまったUIのセキュリティと、セルフ・サービスと委任管理のバックエンドを支援します。

- 様々なエンティティの委任管理およびデータ・セキュリティのスコープ指定メカニズムがサポートされます。すべてのエンティティは、Oracle Identity Managerメタデータとして定義される組織構造によってスコープが指定されます。

図3-1に、OESベースの認可サービスのアーキテクチャを示します。

図3-1 OESベースの認可サービス

認可およびセキュリティ・モデルについては、次の各項で説明します。

- セキュリティ・モデル

- 機能およびデータ・セキュリティのマッピング

- 組織へのエンティティの公開

- OESポリシーの管理

- 機能セキュリティの強制

3.1 セキュリティ・モデル

セキュリティ・モデルについては、次の各項で説明します。

- 管理ロールの割当て

- ユーザー属性に対する属性レベルのセキュリティ

- ポリシーの責任

3.1.1 管理ロールの割当て

新しい認可モデルは、ユーザーに対する管理ロールの割当てをベースとして機能します。管理ロールには、グローバルおよびスコープ指定の2つのタイプがあります。グローバル管理ロール(システム管理者、システム構成管理者、カタログ・システム管理者、SPML管理者、証明管理者、証明ビューアなど)は、最上位組織のコンテキストでのみ割り当てることができます。スコープ指定された管理ロールは、最上位組織およびその他の組織のコンテキストで割り当てることができます。

最上位組織は、Oracle Identity Managerの組織階層のルートにあります。認可ポリシーは、管理ロールに従って作成されます。管理ロールはOracle Identity Managerで事前定義されており、新しい管理ロールを追加することはできません。管理ロールを作成、更新、削除、検索またはリクエストすることはできません。

管理ロールは、エンティティ・タイプごとに事前定義されています。エンティティ管理は委任管理者によって実行されるため、エンティティ・タイプの管理ロールがスコープされます。各エンティティには、次の管理ロールが定義されています。

- エンティティ管理者: エンティティのライフサイクル全体を管理し、エンティティのすべての操作を実行できます。

- エンティティ・ビューア: カタログまたはリクエスト・プロファイル内のエンティティを表示し、そのエンティティをリクエストできます。

- エンティティ認可者: カタログまたはリクエスト・プロファイル内のエンティティを表示し、それをリクエストできます(承認は必要ありません)。組織メンバーシップをリクエストすることはできないため、組織エンティティに認可者は存在しません。同様に、ユーザーに対する認可者も存在しません。ユーザー管理者とユーザー認可者は、同じです。

注意:

- エンティティは、ロール、ユーザー、組織、権限およびアプリケーション・インスタンスを指します。

- 各管理ロールの説明については、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』の管理ロールに関する説明を参照してください。

管理ロールに階層はありません。ただし、管理ロール・メンバーシップ組織のスコープ指定は階層に対応しており、子組織までカスケードされることができます。管理ロール・メンバーシップは常に組織スコープ内で指定され、システム管理者または組織管理者のみがこれを割り当てることができます。組織管理者は、組織管理者である組織に管理ロールを割り当てることができます。システム構成管理者は、管理ロールを割り当てることはできません。管理ロールは、自動グループ・メンバーシップまたはロール・メンバーシップ・ルールを持ちません。

注意:

- 管理ロールは、Oracle Identity Managerデータベースにのみ格納され、LDAPデータ・ストアには格納または同期化されません。

- 管理ロールをリクエストすることはできず、ユーザーに公開されることもありません。

システム管理者とシステム構成管理者の管理ロールは、最上位組織に対してのみ使用可能です。したがって、システム管理者およびシステム構成管理者のみがシステム管理者およびシステム構成管理者ロールを割り当てることができます(これは、システム管理者およびシステム構成管理者が最上位組織にアクセスできるためです)。

ユーザーがエンティティに対して持つ権限には、次のタイプがあります。

- 固有の権限: ユーザーがメンバーとして属する組織は、そのユーザーのホーム組織と呼ばれます。ユーザーは、そのホーム組織で使用可能なエンティティに対して特定の暗黙的な権限を持ちます。これらの権限は、ユーザーに自動的に割り当てられます。たとえば、ロール管理者が、ホーム組織で使用可能なロールを表示およびリクエストする場合に、明示的なロール・ビューア権限は必要ありません。ただし、別の組織内のロールを表示およびリクエストするには、この同じロール管理者にロール・ビューア権限を明示的に割り当てる必要があります。

- 管理階層: ユーザーAがユーザーBおよびユーザーCのマネージャの場合、ユーザーAはユーザーBおよびユーザーCに対して暗黙的な権限を持ちます。ユーザーBおよびユーザーCが異なる組織に属する場合でも、ユーザーAはユーザーBおよびユーザーCに対して暗黙的な権限を持ちます。ユーザーAは直接の部下に対して明示的な権限を必要としません(直接の部下がどの組織に属するかは関係ありません)。権限は管理階層を通してグローバルに適用可能で、すべてのマネージャは部下に対してユーザー管理操作を実行できます。

Oracle Identity Managerの各管理ロールは、OES内のアプリケーション・ロールに1対1のマッピングを持ちます。アプリケーション・ロールには、このロールに属するユーザーに許可される権限を制御するポリシーが関連付けられています。これらのポリシーで機能制約およびデータ制約を変更する場合、OESの認可ポリシー管理(APM) UIでそれぞれのポリシーを開き、ポリシーを変更する必要があります。

表3-1に、Oracle Identity Managerの管理ロールと、その管理ロールで許可される対応する権限を示します。

注意:

表3-1および表3-2には、「組織基本情報」、「ロール基本情報」、「権限基本情報」および「アプリケーション・インスタンス基本情報」という暗黙的な権限が示されています。基本情報権限では、特定のエンティティの表示-検索のみの権限が付与されます。次に例を示します。

- 組織の表示権限では、組織ビューア管理ロールに定義されるすべての権限が提供されますが、組織基本情報では組織属性の検索および表示のみの権限が提供されます。

- ユーザー・ビューア管理ロールでは、スコープが指定された組織内のロール、組織、アプリケーション・インスタンスおよび権限に対する基本情報権限が提供されます。

表3-1 組織のスコープが指定された管理ロールと権限

Oracle Identity Managerでの管理ロール

暗黙的な権限

組織のスコープが指定された権限

リクエストまたは直接的な操作

ユーザー管理者

組織ビューア

ユーザーの検索(属性レベルのセキュリティ)

該当なし

ロール・ビューア

ユーザーの表示(属性レベルのセキュリティ)

該当なし

権限ビューア

ユーザーの作成

直接

アプリケーション・インスタンス・ビューア

ユーザーの削除

直接

ユーザーの変更(属性レベルのセキュリティ)

直接

ユーザーのロック

該当なし

ユーザーのロック解除

該当なし

ユーザーの有効化

直接

ユーザーの無効化

直接

ロールの付与

直接

ロールの失効

直接

アカウントの付与

直接

アカウントの失効

直接

権限の付与

直接

権限の失効

直接

ユーザー・パスワードの変更

該当なし

アカウント・パスワードの変更

該当なし

ユーザー・アカウントの変更

直接

ユーザー・アカウントの有効化

直接

ユーザー・アカウントの無効化

直接

組織の表示

該当なし

ロールの表示

該当なし

権限の表示

該当なし

アプリケーション・インスタンスの表示

該当なし

リクエストの表示

該当なし

管理ロール・メンバーシップの表示

該当なし

ロール・メンバーシップの表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

プロキシの表示

該当なし

プロキシの追加

直接

プロキシの削除

直接

ヘルプ・デスク

組織基本情報

ユーザーの検索(属性レベルのセキュリティ)

該当なし

ロール基本情報

ユーザーの表示(属性レベルのセキュリティ)

該当なし

権限基本情報

ユーザーの有効化

リクエスト

アプリケーション・インスタンス基本情報

ユーザーの無効化

リクエスト

ユーザーのロック解除(ログインの失敗でロックされた場合のみ)

直接

ユーザー・パスワードの変更

直接

組織の表示

該当なし

ロールの表示

該当なし

権限の表示

該当なし

アプリケーション・インスタンスの表示

該当なし

リクエストの表示

該当なし

ロール・メンバーシップの表示

該当なし

プロキシの表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

ユーザー・ビューア

組織ビューア

ユーザーの作成

リクエスト

ロール・ビューア

ユーザーの削除

リクエスト

権限ビューア

ユーザーの変更(属性レベルのセキュリティ)

リクエスト

アプリケーション・インスタンス・ビューア

ユーザーの検索(属性レベルのセキュリティ)

該当なし

ユーザーの表示(属性レベルのセキュリティ)

該当なし

ユーザーの有効化

リクエスト

ユーザーの無効化

リクエスト

ロールの付与

リクエスト

ロールの失効

リクエスト

アカウントの付与

リクエスト

アカウントの失効

リクエスト

権限の付与

リクエスト

権限の失効

リクエスト

ユーザー・アカウントの変更

リクエスト

組織の表示

該当なし

ロールの表示

該当なし

権限の表示

該当なし

アプリケーション・インスタンスの表示

該当なし

リクエストの表示

該当なし

ロール・メンバーシップの表示

該当なし

プロキシの表示

該当なし

ユーザー・アカウントの有効化

リクエスト

ユーザー・アカウントの無効化

リクエスト

管理ロール・メンバーシップの表示

該当なし

管理ロールの追加

該当なし

管理ロールの削除

該当なし

管理ロール・メンバーシップの変更

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

ロール・ビューア

組織基本情報

ロールの付与

リクエスト

ユーザー基本情報

ロールの失効

リクエスト

組織の表示

該当なし

ロールの表示

該当なし

ユーザーの表示

該当なし

ロール・メンバーシップの表示

該当なし

組織ビューア

組織基本情報

組織の検索

該当なし

ユーザー基本情報

組織の表示

該当なし

アプリケーション・インスタンス情報

ユーザーの表示

該当なし

権限情報

ロールの表示

該当なし

アプリケーション・インスタンスの表示

該当なし

権限の表示

該当なし

すべてのパブリケーションの表示

該当なし

すべての組織メンバーの表示

該当なし

管理ロールおよびメンバーシップの表示

該当なし

組織にプロビジョニングされたアカウントの表示

該当なし

アプリケーション・インスタンス・ビューア

ユーザー基本情報

アプリケーション・インスタンスの検索

該当なし

組織基本情報

アプリケーション・インスタンスの表示(パスワードを除く)

該当なし

権限情報

アカウントの付与

リクエスト

アカウントの失効

リクエスト

ユーザー・アカウントの変更

リクエスト

ユーザー・アカウントの有効化

リクエスト

ユーザー・アカウントの無効化

リクエスト

組織の表示

該当なし

ユーザーの表示

該当なし

アプリケーション・インスタンスの表示

該当なし

権限の表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

権限ビューア

ユーザー基本情報

権限の検索

該当なし

組織基本情報

権限の表示

該当なし

アプリケーション・インスタンス基本情報

権限の付与

リクエスト

権限の失効

リクエスト

組織の表示

該当なし

ユーザーの表示

該当なし

アプリケーション・インスタンスの表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

ロール管理者

注意: ロール管理者の管理ロールは、その組織スコープ内のロールのライフサイクルを管理するだけで、ユーザーに対してロールの付与または失効を行う権限は持ちません。ロール管理者がこの機能を必要とする場合は、ロール・ビューア管理ロール(リクエストの承認が必要な場合)、またはロール認可者管理ロール(リクエストの承認が不要な場合)を、この機能を必要とする組織スコープ内で割り当てます。

ユーザー基本情報

ロールの検索

該当なし

組織基本情報

ロールの表示

該当なし

ロールの作成

直接

ロールの変更

直接

ロールの削除

直接

ロール・メンバーの表示

該当なし

ロール階層の管理

直接

ロールの公開(許可された組織に対してのみ)

直接

ロールの非公開(許可された組織に対してのみ)

直接

ロール・メンバーシップ・ルールの管理

直接

ロール・カテゴリの作成

直接

ロール・カテゴリの更新

直接

ロール・カテゴリの削除

直接

ユーザーの表示

該当なし

組織の表示

該当なし

ロール・メンバーシップの表示

該当なし

アプリケーション・インスタンス管理者

注意: アプリケーション・インスタンス管理者の管理ロールは、その組織スコープ内のアプリケーション・インスタンスのライフサイクルを管理するだけで、ユーザーに対してアプリケーション・インスタンスの付与または失効を行う権限は持ちません。アプリケーション・インスタンス管理者がこの機能を必要とする場合は、アプリケーション・インスタンス・ビューア管理ロール(リクエストの承認が必要な場合)、またはアプリケーション・インスタンス認可者管理ロール(リクエストの承認が不要な場合)を、この機能を必要とする組織スコープ内で割り当てます。

ユーザー基本情報

アプリケーション・インスタンスの作成

直接

組織基本情報

アプリケーション・インスタンスの変更

直接

権限管理者

アプリケーション・インスタンスの削除

直接

アプリケーション・インスタンスの検索

該当なし

アプリケーション・インスタンスの表示

該当なし

アプリケーション・インスタンスの公開(許可された組織に対してのみ)

直接

アプリケーション・インスタンスの非公開(許可された組織に対してのみ)

直接

権限の公開(許可された組織に対してのみ)

直接

権限の非公開(許可された組織に対してのみ)

直接

拡張UIへのアクセス

該当なし

アカウントの表示

該当なし

ユーザーの表示

該当なし

組織の表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

組織.管理者

ユーザー基本情報

組織の検索

該当なし

アプリケーション・インスタンス基本情報

組織の表示

該当なし

権限基本情報

組織の作成

直接

ロール基本情報

組織の変更

直接

組織の削除

直接

管理ロールのすべてのロール管理権限

直接

組織階層の更新(特定の組織に対して)

直接

パスワード・ポリシーの関連付け

直接

メンバーの表示

該当なし

公開されたロールの表示

該当なし

公開されたアプリケーション・インスタンスの表示

該当なし

公開された権限の表示

該当なし

アカウントの表示(組織にプロビジョニングされたもの)

注意: 組織へのリソースのプロビジョニングは、システム管理者のみに許可されます。

該当なし

権限管理者

注意: 権限管理者の管理ロールは、その組織スコープ内の権限のライフサイクルを管理するだけで、ユーザーに対して権限の付与または失効を行う権限は持ちません。権限管理者がこの機能を必要とする場合は、権限ビューア管理ロール(リクエストの承認が必要な場合)、または権限認可者管理ロール(リクエストの承認が不要な場合)を、この機能を必要とする組織スコープ内で割り当てます。

ユーザー基本情報

権限の検索

該当なし

アプリケーション・インスタンス基本情報

権限の表示

該当なし

組織基本情報

権限の追加(API)

直接

権限の削除(API)

直接

権限の更新(API)

直接

権限の公開(許可された組織に対してのみ)

直接

権限の非公開(許可された組織からのみ)

直接

組織の表示

該当なし

ユーザーの表示

該当なし

アプリケーション・インスタンスの表示

該当なし

アカウントの表示

該当なし

権限メンバーの表示

該当なし

組織データ・セキュリティが適用される、公開された権限の表示(API)

該当なし

カタログ・システム管理者

アプリケーション・インスタンス基本情報

カタログ・メタデータの編集

直接

権限基本情報

リクエスト・プロファイルの作成

直接

ロール基本情報

リクエスト・プロファイルの編集

直接

リクエスト・プロファイルの削除

直接

アプリケーション・インスタンスの表示

該当なし

権限の表示

該当なし

ロールの表示

該当なし

ロール認可者

ユーザー基本情報

ロールの表示

該当なし

組織基本情報

ロールの付与

直接

ロールの失効

直接

組織の表示

該当なし

ユーザーの表示

該当なし

ロール・メンバーシップの表示

該当なし

アプリケーション・インスタンス認可者

ユーザー基本情報

アプリケーション・インスタンスの検索

該当なし

組織基本情報

アプリケーション・インスタンスの表示(パスワードを除く)

該当なし

アカウントの付与

直接

アカウントの失効

直接

アカウントの変更

直接

アカウントの有効化

直接

アカウントの無効化

直接

組織の表示

該当なし

権限の表示

該当なし

ユーザーの表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

権限認可者

ユーザー基本情報

権限の検索

該当なし

組織基本情報

権限の表示

該当なし

アプリケーション・インスタンス基本情報

権限の付与

直接

権限の失効

直接

ユーザーの表示

該当なし

組織の表示

該当なし

アプリケーション・インスタンスの表示

該当なし

ユーザー・アカウントの表示

該当なし

ユーザー権限の表示

該当なし

表3-2に、Oracle Identity Managerの管理ロールと、その管理ロールで許可された対応する権限を示します。これらの管理ロールは、最上位の組織により割り当てられます。

注意:

「システム管理者」管理ロールは、表3-2にはリストされていません。「システム管理者」管理ロールには、すべての操作に対するグローバル権限があります。

表3-2 グローバル管理ロールとグローバル権限

Oracle Identity Managerでの管理ロール

暗黙的な権限

明示的な権限

リクエストまたは直接的な操作

カタログ・システム管理者

アプリケーション・インスタンス基本情報

カタログ・メタデータの編集

直接

権限基本情報

リクエスト・プロファイルの作成

直接

ロール基本情報

リクエスト・プロファイルの編集

直接

リクエスト・プロファイルの削除

直接

アプリケーション・インスタンスの表示

該当なし

ViewRentitlements

該当なし

ロールの表示

該当なし

システム構成管理者

ロール基本情報

フォームの表示

該当なし

組織基本情報

フォームの作成

該当なし

アプリケーション・インスタンス基本情報

フォームの変更

該当なし

権限基本情報

フォームの削除

該当なし

コネクタのインポート

該当なし

コネクタのエクスポート

該当なし

リソース・オブジェクトの表示

該当なし

リソース・オブジェクトの作成

該当なし

リソース・オブジェクトの変更

該当なし

リソース・オブジェクトの削除

該当なし

アプリケーション・インスタンスの表示

該当なし

アプリケーション・インスタンスの作成

該当なし

アプリケーション・インスタンスの変更

該当なし

アプリケーション・インスタンスの削除

該当なし

アプリケーション・インスタンスの公開

該当なし

権限の表示

該当なし

権限の公開

該当なし

権限の削除

(APIの使用)

該当なし

権限の変更

(APIの使用)

該当なし

権限の追加

(APIの使用)

該当なし

承認ポリシーの表示

該当なし

承認ポリシーの作成

該当なし

承認ポリシーの変更

該当なし

承認ポリシーの削除

該当なし

拡張UIへのアクセス

該当なし

パスワード・ポリシーの表示

該当なし

パスワード・ポリシーの作成

該当なし

パスワード・ポリシーの変更

該当なし

パスワード・ポリシーの削除

該当なし

通知の表示

該当なし

通知の作成

該当なし

通知の削除

該当なし

通知の変更

該当なし

通知へのロケールの追加

該当なし

通知へのロケールの削除

該当なし

非同期イベント・ハンドラの完了

該当なし

編成操作

該当なし

プラグインの登録

該当なし

プラグインの登録解除

該当なし

スケジュール済ジョブの表示

該当なし

スケジュール済ジョブの検索

スケジューラの起動

該当なし

スケジューラの停止

該当なし

タスクの追加

該当なし

タスクの編集

該当なし

タスクの削除

該当なし

トリガーの作成

該当なし

トリガーの削除

該当なし

トリガーの変更

該当なし

ジョブの表示

該当なし

ジョブの作成

該当なし

ジョブの変更

該当なし

ジョブの削除

該当なし

ジョブの有効化

該当なし

ジョブの無効化

該当なし

ジョブの即時実行

該当なし

ジョブの一時停止

該当なし

ジョブの再開

該当なし

ジョブの停止

該当なし

ステータスのリセット

該当なし

システム・プロパティの表示

該当なし

システム・プロパティの作成

該当なし

システム・プロパティの変更

該当なし

システム・プロパティの削除

該当なし

属性の表示

該当なし

属性の追加

該当なし

属性の変更

該当なし

属性の削除

該当なし

導出属性の追加

該当なし

SPML管理者

ユーザーの作成、変更および削除

リクエスト

すべての属性でのユーザーの検索

該当なし

ユーザー・ステータスの有効化

リクエスト

ユーザー・ステータスの無効化

リクエスト

ロール・メンバーシップの追加

リクエスト

ロール・メンバーシップの削除

リクエスト

すべての属性でのロールの検索

該当なし

ロールの作成、変更および削除

リクエスト

証明管理者

証明ビューア

プロキシ・ユーザーの表示

該当なし

ユーザー基本情報

ViewUser管理ロール

該当なし

ロール基本情報

ユーザー権限の表示

該当なし

組織基本情報

リクエストの表示

該当なし

アプリケーション・インスタンス基本情報

ユーザー・アカウントの表示

該当なし

権限基本情報

ユーザー・ロールの表示

該当なし

証明構成の表示

該当なし

証明構成の更新

該当なし

証明の更新

該当なし

拡張UIへのアクセス

該当なし

スケジュール済ジョブの表示

該当なし

スケジュール済ジョブの検索

該当なし

スケジューラの起動

該当なし

スケジューラの停止

該当なし

タスクの追加

該当なし

タスクの編集

該当なし

タスクの削除

該当なし

トリガーの作成

該当なし

トリガーの削除

該当なし

トリガーの変更

該当なし

ジョブの表示

該当なし

ジョブの作成

該当なし

ジョブの変更

該当なし

ジョブの削除

該当なし

ジョブの有効化

該当なし

ジョブの無効化

該当なし

ジョブの即時実行

該当なし

ジョブの一時停止

該当なし

ジョブの再開

該当なし

ジョブの停止

該当なし

証明ビューア

注意: 「証明書ビューア」管理ロールに明示的に付与される権限は、「証明の表示」のみです。その他のエンティティを表示する権限は、証明で参照されるエンティティに動的に付与され、スコープされます。

証明の表示

該当なし

注意:

Oracle Identity Managerの次の権限は、OESポリシーでは制御されません。

- アクセス・ポリシーの作成/更新/削除

- 参照の追加/変更/削除

- デプロイメント・マネージャを使用したインポート/エクスポート

- アテステーション管理

3.1.2 ユーザー属性に対する属性レベルのセキュリティ

Oracle Identity Managerは、ユーザー属性に対してのみ、属性レベルのセキュリティをサポートします。他のすべてのエンティティのセキュリティは、エンティティ-インスタンス・レベルでサポートされます。

Oracle Identity Managerには、デフォルトのユーザー・ビューア、ユーザー管理者およびユーザー・ヘルプ・デスク管理ロールとともに、OESの対応するデフォルトの認可ポリシーが含まれています。デフォルトのポリシーでは、ユーザー・ビューアおよびユーザー管理者は、ユーザー定義フィールド(UDF)として追加される属性を含むすべてのユーザー属性を表示および変更できます(デフォルト・ポリシーの変更は必要ありません)。

ユーザー・ビューア・ポリシーには、ポリシーのデフォルト制約セットのdeniedattributes責任と、デフォルトでその属性のNULLリストが含まれています。したがって、ユーザー・ビューア・ロールに属しているすべてのユーザーは、デフォルトで、すべてのユーザー属性の表示を許可されます。

ユーザー管理者ポリシーには、ポリシーのデフォルト制約セットのdeniedattributes責任と、属性のNULLリストが含まれており、ユーザー管理者ロールに属しているすべてのユーザーは、デフォルトで、すべてのユーザー属性の表示および変更を許可されます。ユーザー・ヘルプ・デスク・ポリシーには、ポリシーのデフォルト制約セットのdeniedattributes責任と、属性のNULLリストが含まれています。

新しいUDFを追加した場合に、ユーザー・ビューア・ポリシーを変更する必要はありません。これは、このポリシーにデフォルト制約セットがdeniedattributesとして存在し、デフォルトでその属性のNULLリストが含まれているためです。これによって、自動的に、ユーザー・ビューア・ロールに属するユーザーはUDFを表示可能になります。すべての属性が表示および変更可能なこの制約によって、ユーザー管理者ロールに属するユーザーは自動的にこれらのUDFを表示および変更可能になるため、ユーザー管理者ポリシーを変更する必要はありません。

特定の属性の表示または変更を制限する場合にのみ、OESでポリシーを変更してその属性を拒否リストに含めることができます。ユーザー・ビューア・ロールで表示される属性のリストを制限する場合、またはユーザー管理者ロールで表示および変更される属性のリストを制限する場合は、OESのAPM UIでそれぞれのポリシーを開き、ポリシーの拒否属性リストで制限される属性のリストを含めます。たとえば、Salaryユーザー属性を、ユーザー管理者ロールのみが使用できるように制限し、ユーザー・ビューア・ロールを対象外とする場合は、APM UIを使用してユーザー・ビューア・ロールを変更し、Salary属性を拒否リストに含めます。Oracle Identity Managerがユーザー・ビューア・ロールの属性リストを提供するためにOESに問い合せると、OESはすべてのユーザー属性を提供しますが、拒否リストに指定された属性は除外されます(この例ではSalary属性です)。ユーザー管理者ロールに属するユーザーが表示および変更するSalary情報は「すべての属性の表示および変更」によって戻されるため、ここでは、ユーザー管理ポリシーの変更は必要ありません。

拒否される属性を変更するには、APM UIで必要なOESポリシーを開きます。この例では、図3-2に示すように、ユーザー・ビューア管理ロールに関して、表示-検索ユーザーに権限を付与するOrclOIMUserViewerDirectWithObligationPolicyという名前のOESポリシーを開きます。

図3-2 OrclOIMUserViewerDirectWithObligationPolicy

編集モードでOrclOIMDeniedAttributesDirect属性をクリックして、図3-3に示すように、拒否する属性をカンマで区切って指定します。

図3-3 「責任属性の編集」ダイアログ・ボックス

3.1.2.1 ポリシー評価用の属性を渡すためのプラグインの使用

oracle.iam.platform.authopss.plugin.AttributeResolverプラグイン・ポイントを使用して、OESにポリシー評価用の属性を渡すことができます。ポリシー(条件)で使用する新しい属性を追加するには、次のメソッドを使用して、マップに属性を追加する必要があります。

ログイン・ユーザーが作業中のターゲット・エンティティの属性を解決するには、次のようにします。

public Map<String, Object> resolveResourceAttributes(String subjectId, PolicyConstants.Resources resourceType, String resourceId) throws Exception;

ログイン・ユーザーに関する属性を解決するには、次のようにします。

public Map<String, Object> resolveSubjectAttributes(String subjectId, Policy Constants.Resources resourceType) throws Exception;

プラグインの開発および使用の詳細は、第27章「プラグインの開発」を参照してください。

3.1.3 ポリシーの責任

ユーザーに、同じ状況で異なる認可ポリシーが適用可能な複数のロールがある場合、そのユーザーのアクセス権はポリシー間の権限の累積になります。たとえば、ユーザー検索の権限の認可チェックでは、責任のリストが戻されます。これは、適用可能な各認可ポリシーからの責任のリストです。複数のポリシーからの責任が組み合されて、統合された検索結果が生成されます。

次のタイプの責任が、複数の認可ポリシーの結果として戻されます。

- OrclOIMOrgScopingDirect: 目的ベースの検索用に、特定のエンティティを検索する場合に使用されます。これは、表示-検索の場合にのみサポートされます。

- OrclOIMOrgScopingWithHierarchy: 管理ロールの組織スコープ指定の階層を考慮して、下位階層のエンティティを検索できます。適用可能な場合に、ユーザーは、適切な管理ロールを持つ組織とそのサブ組織に対して、承認なしでユーザー・プロファイルの表示および変更を実行できます。これは、「階層対応」データ制約によって制御されます。

- OrclOIMNeedApproval: この責任は、認可ポリシーを適用可能かどうか、操作に承認が必要かどうかを定義します。このフラグの値がtrueの場合、リクエストが作成されます。値がfalseの場合、それは直接的な操作です。

- OrclOIMUserManagementScoping: ユーザーの管理チェーンで検索する検索基準の作成に使用されます。

- OrclOIMDeniedAttributesWithoutApproval: これは、リクエストの承認なしで変更が拒否されるユーザー属性に対する責任を定義します。

- OrclOIMDeniedAttributesDirect: 直接的な操作としてユーザーの表示操作が拒否されるユーザー属性に対する責任を定義します。

- OrclOIMDeniedAttributesWithApproval: これは、リクエストの承認ありで変更が拒否されるユーザー属性に対する責任を定義します。

次に、複数の認可ポリシーの結果として戻されるポリシー責任の例を示します。

- 組織のロール・ビューア管理ロールを持つユーザーの場合、ユーザーにロールを付与するには承認が必要です。ロール・ビューアでは、OrgScopingWithHierarchyポリシー責任の結果として、階層を持つこの組織内のすべてのユーザーを表示できます。同じ組織で、ロール認可者管理ロールを持つユーザーの場合、ユーザーにロールを付与する操作は直接的な操作となります。

- 同じ組織スコープで、ユーザーに対して、2つの管理ロールが割り当てられているとします(ユーザー・ビューアおよびユーザー管理者)。このユーザーがあるユーザーの変更を試みると、最初の管理ロール・ポリシーは承認が必要と戻し、他のポリシーは承認が不要と戻します。結果として、リクエストは発生せず、2つの承認必須の責任が累積した影響で、承認は不要になります。

- OrgScopingDirectポリシー責任の結果、ロール認可者管理ロールを持つユーザーは、組織のすべてのユーザーを表示できます。ロール認可者管理ロールを持つ同じユーザーは、DeniedAttributesWithApprovalポリシー責任によっていくつかの属性変更が拒否され、その結果、それらの属性がこのユーザーに表示されなくなる可能性があります。

- 1人のユーザーが、Org1ではロール・ビューアであり、Org2ではロール認可者であるとします。このユーザーがロールを検索すると、policy1から戻される責任は、「OrgScopingDirect = org1」および「OrgScopingDirect = org2」となります。したがって、両方の組織からロールが戻されます。

3.2 機能およびデータ・セキュリティのマッピング

表3-3に、管理ロールと、それに対応するアプリケーション・ロール、デフォルトの認可ポリシーおよびポリシー責任を示します。

表3-3 デフォルトの認可ポリシー

Oracle Identity Managerでの管理ロール

OESのアプリケーション・ロール

ポリシー名

説明

責任

認証済ロール

authenticated-role

ロール・カテゴリ表示ポリシー

このポリシーは、認証済ユーザーがロール・カテゴリを表示できるかどうかを制御します。

ロール管理者

OIMロール管理者

OIMロール・カテゴリ・ロール管理ポリシー

このポリシーは、ロール管理者の管理ロールによるロール・カテゴリの作成、変更および削除を制御します。

カタログ管理者

OIMカタログ管理者ロール

カタログ管理ポリシー

カタログ管理者はグローバル管理ロールです。カタログ管理者は、カタログ項目およびそのメタデータを管理します。このポリシーは、ロールのメンバーが実行できるアクションを指定します。

組織.管理者

OIM組織管理者

組織管理ポリシー

このポリシーは、組織管理者が実行できるアクションを指定します。このポリシーは、承認を必要とするように構成することもできます。

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMOrganizationAdminOrgsDirect

組織.管理者

OIM組織管理者

OIM組織管理者基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、組織管理者によるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationAdminOrgsWithHierarchy

組織.管理者

OIM組織管理者

OIM組織管理者基本情報ITリソース権限直接ポリシー

このポリシーは、組織管理者による権限に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMOrganizationAdminOrgsDirect

組織.管理者

OIM組織管理者

OIM組織管理者基本情報ロール直接ポリシー

このポリシーは、組織管理者によるロールに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect Attribute=OrclOIMOrganizationAdminOrgsDirect

組織.管理者

OIM組織管理者

OIM組織管理者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、組織管理者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationAdminOrgsWithHierarchy

OrclOIMDeniedAttributesDirect=

組織ビューア

OIM組織ビューア

表示アクション用組織ビューア・ポリシー

組織ビューアは、組織のスコープが指定された管理ロールです。このポリシーは、このロールのメンバーが実行できる、承認を必要としないアクションを指定します。デフォルトでは、このポリシーは、一部の表示アクションが承認を必要としないことを指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationViewerOrgsWithHierarchy

組織ビューア

OIM組織ビューア

OIM組織ビューア基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、組織ビューアによるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationViewerOrgsWithHierarchy

組織ビューア

OIM組織ビューア

OIM組織ビューア基本情報ITリソース権限直接ポリシー

このポリシーは、組織ビューアによる権限に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMOrganizationViewerOrgsDirect

組織ビューア

OIM組織ビューア

OIM組織ビューア基本情報ロール直接ポリシー

このポリシーは、組織ビューアによるロールに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationViewerOrgsWithHierarchy

組織ビューア

OIM組織ビューア

OIM組織ビューア基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、組織ビューアによるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMOrganizationViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMOrganizationViewerOrgsWithHierarchy

OrclOIMDeniedAttributesDirect=

アプリケーション・インスタンス管理者

OIMアプリケーション・インスタンス管理者ロール

アプリケーション・インスタンス管理者ポリシー

アプリケーション・インスタンス管理者の管理ロールは、組織のスコープが指定されたロールです。このポリシーは、ロールのメンバーが実行できるアクションと、そのアクションに承認が必要かどうかを制御します。

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAdminOrgsWithHierarchy

アプリケーション・インスタンス管理者

OIMアプリケーション・インスタンス管理者ロール

OIMアプリケーション・インスタンス管理者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、アプリケーション・インスタンス管理者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAdminOrgsDirect

OrclOIMDeniedAttributesDirect=

アプリケーション・インスタンス管理者

OIMアプリケーション・インスタンス管理者ロール

OIMアプリケーション・インスタンス管理者基本情報組織直接ポリシー

このポリシーは、アプリケーション・インスタンス管理者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAdminOrgsWithHierarchy

アプリケーション・インスタンス認可者

OIMアプリケーション・インスタンス認可者ロール

アプリケーション・インスタンス認可者ポリシー

アプリケーション・インスタンス認可者は、Oracle Identity Managerの管理ロールです。アプリケーション・インスタンス認可者は、承認を必要とせずにユーザー・アカウントに対してアプリケーション・インスタンスを付与、取消し、または変更できます。このポリシーは、アプリケーション・インスタンス認可者が、アプリケーション・インスタンスおよびアプリケーション・インスタンス属性を表示または検索できるかどうかを制御します。

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAuthorizerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAuthorizerOrgsDirect

アプリケーション・インスタンス認可者

OIMアプリケーション・インスタンス認可者ロール

アプリケーション・インスタンス認可者ポリシー

アプリケーション・インスタンス認可者は、承認を必要とせずにユーザー・アカウントに対してアプリケーション・インスタンスを付与、取消し、または変更できます。このポリシーは、アプリケーション・インスタンス認可者が、アプリケーション・インスタンスおよびアプリケーション・インスタンス属性を表示または検索できるかどうかを制御します。

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAuthorizerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAuthorizerOrgsDirect

OrclOIMNeedApproval=false

アプリケーション・インスタンス認可者

OIMアプリケーション・インスタンス認可者ロール

OIMアプリケーション・インスタンス認可者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、アプリケーション・インスタンス認可者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAuthorizerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAuthorizerOrgsDirect

アプリケーション・インスタンス認可者

OIMアプリケーション・インスタンス認可者ロール

OIMアプリケーション・インスタンス認可者基本情報組織直接ポリシー

このポリシーは、アプリケーション・インスタンス認可者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceAuthorizerOrgsWithHierarchy

アプリケーション・インスタンス・ビューア

OIMアプリケーション・インスタンス・ビューア・ロール

OIMアプリケーション・インスタンス・ビューア直接ポリシー

このポリシーは、アプリケーション・インスタンス・ビューアが直接実行できる操作を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceViewerOrgsDirect

アプリケーション・インスタンス・ビューア

OIMアプリケーション・インスタンス・ビューア・ロール

リクエスト・アクション用アプリケーション・インスタンス・ビューア・ポリシー

アプリケーション・インスタンス・ビューア管理ロールは、組織のスコープが指定されたロールです。このポリシーは、ロールのメンバーが実行できるアクションと、そのアクションに承認が必要かどうかを制御します。

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceViewerOrgsDirect

OrclOIMNeedApproval=true

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceViewerOrgsWithHierarchy

アプリケーション・インスタンス・ビューア

OIMアプリケーション・インスタンス・ビューア・ロール

OIMアプリケーション・インスタンス・ビューア基本情報ITリソース権限直接ポリシー

このポリシーは、アプリケーション・インスタンス・ビューアによる権限に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceViewerOrgsWithHierarchy

アプリケーション・インスタンス・ビューア

OIMアプリケーション・インスタンス・ビューア・ロール

OIMアプリケーション・インスタンス・ビューア基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、アプリケーション・インスタンス・ビューアによるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceViewerOrgsDirect

アプリケーション・インスタンス・ビューア

OIMアプリケーション・インスタンス・ビューア・ロール

OIMアプリケーション・インスタンス・ビューア基本情報組織直接ポリシー

このポリシーは、アプリケーション・インスタンス・ビューアによる組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMApplicationInstanceViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMApplicationInstanceViewerOrgsDirect

認証済ロール

authenticated-role

アプリケーション・インスタンス用ホーム組織ポリシー

このポリシーは、ユーザーのホーム組織に公開済のアプリケーション・インスタンスおよびアプリケーション・インスタンス属性を暗黙的に表示することをそのユーザーに許可します。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

認証済ロール

authenticated-role

ホーム組織用アプリケーション・インスタンス・ポリシー

このポリシーは、ユーザーのホーム組織内のアカウントに対してユーザーが実行できるアクションと、そのアクションに承認が必要かどうかを制御します。デフォルトでは、同じホーム組織内のアカウントに対する非ユーザー管理者によるアクションには承認が必要です。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

OrclOIMNeedApproval=true

システム構成管理者

OIMシステム構成者

パスワード・ポリシー管理ポリシー

このポリシーは、システム管理者またはシステム構成管理者のメンバーが実行できるパスワード・ポリシー管理アクションを制御します。

組織.管理者

OIM組織管理者

OIMパスワード・ポリシー組織管理表示検索ポリシー

このポリシーは、組織管理者によるパスワード・ポリシーに対する表示および検索権限を指定します。

権限管理者

OIM権限管理者

権限管理アクション用権限管理者ポリシー

権限管理者は、Oracle Identity Managerの組織のスコープが指定された管理ロールです。このポリシーは、承認を必要とせずにこのロールのメンバーが実行できるアクションを制御します。

OrclOIMOrgScopingDirect=OrclOIMEntitlementAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAdminOrgsWithHierarchy

権限管理者

OIM権限管理者

OIM権限管理者基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、権限管理者によるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMEntitlementAdminOrgsDirect

権限管理者

OIM権限管理者

OIM権限管理者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、権限管理者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMEntitlementAdminOrgsDirect

OrclOIMDeniedAttributesDirect=

権限管理者

OIM権限管理者

OIM権限管理者基本情報組織直接ポリシー

このポリシーは、権限管理者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMEntitlementAdminOrgsDirect

権限認可者

OIM権限認可者

表示アクション用権限認可者ポリシー

権限認可者は、Oracle Identity Managerの管理ロールです。権限認可者は、承認を必要とせずにユーザー・アカウントに対して権限を付与、取消し、または変更できます。このポリシーは、権限認可者が、権限および権限属性を表示または検索できるかどうかを制御します。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAuthorizerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMEntitlementAuthorizerOrgsDirect

権限認可者

OIM権限認可者

リクエスト・アクション用権限認可者ポリシー

権限認可者は、承認を必要とせずにユーザー・アカウントに対して権限を付与、取消し、または変更できます。このポリシーは、リクエストの一部として権限認可者が実行できるアクションを制御します。このポリシーは、権限認可者によって実行される特定のアクションが、直接であるか、リクエストを介したものであるかを判別するためにリクエスト・エンジンによって使用されます。

OrclOIMOrgScopingDirect=OrclOIMEntitlementAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAuthorizerOrgsWithHierarchy

OrclOIMNeedApproval=false

権限認可者

OIM権限認可者

OIM権限認可者基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、権限認可者によるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMEntitlementAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAuthorizerOrgsWithHierarchy

権限認可者

OIM権限認可者

OIM権限認可者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、権限認可者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingDirect=OrclOIMEntitlementAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAuthorizerOrgsWithHierarchy

権限認可者

OIM権限認可者

OIM権限認可者基本情報組織直接ポリシー

このポリシーは、権限認可者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMEntitlementAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementAuthorizerOrgsWithHierarchy

権限ビューア

OIM権限ビューア

表示アクション用権限ビューア・ポリシー

権限ビューアは、Oracle Identity Managerの組織のスコープが指定された管理ロールです。このポリシーは、承認を必要とせずに権限ビューアが権限を検索し、その属性を表示できるかどうかを指定します。デフォルトでは、承認は必要ありません。

OrclOIMOrgScopingDirect=OrclOIMEntitlementViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementViewerOrgsWithHierarchy

権限ビューア

OIM権限ビューア

リクエスト・アクション用OIM権限ビューア・ポリシー

このポリシーは、組織のスコープが指定されたポリシーであり、ロールのメンバーが、その組織に公開済の権限の付与、取消し、および変更をリクエストすることを許可します。権限ビューアによる権限の付与または取消しはリクエストになります。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMEntitlementViewerOrgsDirect

OrclOIMNeedApproval=true

権限ビューア

OIM権限ビューア

OIM権限ビューア基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、権限ビューアによるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMEntitlementViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementViewerOrgsWithHierarchy

権限ビューア

OIM権限ビューア

OIM権限ビューア基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、権限ビューアによるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementViewerOrgsWithHierarchy

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingDirect=OrclOIMEntitlementViewerOrgsDirect

権限ビューア

OIM権限ビューア

OIM権限ビューア基本情報組織直接ポリシー

このポリシーは、権限ビューアによる組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMEntitlementViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMEntitlementViewerOrgsWithHierarchy

認証済ロール

authenticated-role

権限表示用ホーム組織ポリシー

このポリシーは、ユーザーのホーム組織に公開済の権限および権限属性を暗黙的に表示することをそのユーザーに許可します。

OrclOIMOrgScopingDirect =OrclOIMUserHomeOrgs

認証済ロール

authenticated-role

権限に対するアクション用のホーム組織ポリシー

このポリシーは、同じホーム組織内の別のユーザーにプロビジョニングされた権限に対してユーザーが実行できるアクションと、そのアクションに承認が必要かどうかを指定します。デフォルトでは、承認が必要です。

OrclOIMNeedApproval=true

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

カタログ管理者

OIMカタログ管理者ロール

リクエスト・プロファイル管理ポリシー

このポリシーは、リクエスト・プロファイルを管理しているときにカタログ管理者ロールのメンバーが実行できるアクションを制御します。

認証済ロール

authenticated-role

OIMリクエスト・プロファイルのすべてのユーザーの表示検索ポリシー

このポリシーは、すべてのユーザーによるリクエスト・カタログに対する表示および検索権限を制御します。

システム構成管理者

OIMシステム構成者

OIM承認ポリシー管理者ポリシー

このポリシーは、システム構成管理者による承認ポリシー管理の権限を制御します。

システム構成管理者

OIMシステム構成者

診断ダッシュボード管理者ポリシー

診断ダッシュボードは、Oracle Identity Managerの診断ユーティリティです。このポリシーは、診断ダッシュボードにアクセスできるユーザーと、そのユーザーが実行できるアクションを指定します。

システム構成管理者

OIMシステム構成者

OIMリソース・オブジェクト管理ポリシー

このポリシーは、システム構成管理者によるリソース・オブジェクト管理の権限を制御します。

システム構成管理者

OIMシステム構成者

通知管理者ポリシー

このポリシーは、通知管理者が実行できるアクションを指定します。

システム構成管理者

OIMシステム構成者

OIMプラットフォーム・サービス管理者ポリシー

このポリシーは、プラットフォーム・サービス管理者が実行できるアクションを指定します。

システム構成管理者

OIMシステム構成者

プラグイン管理者ポリシー

このポリシーは、プラグインを登録および登録解除できるユーザーを制御します。デフォルトでは、システム管理者およびシステム構成管理者管理ロールのメンバーのみが、プラグインを登録および登録解除できます。

システム構成管理者

OIMシステム構成者

システム管理コンソール用システム構成者ポリシー

このポリシーは、システム構成管理者管理ロールのメンバーが、Oracle Identity System Administrationにアクセスできるかどうかを制御します。

アプリケーション・インスタンス管理者

OIMアプリケーション・インスタンス管理者

OIM UIアプリケーション・インスタンス管理者ポリシー

このポリシーは、アプリケーション・インスタンス管理者がそのUIで実行できるアクションを指定します。

権限管理者

OIM権限管理者

OIM UI権限管理者ポリシー

このポリシーは、権限管理者がそのUIで実行できるアクションを指定します。

アプリケーション・インスタンス管理者

システム構成管理者

OIMアプリケーション・インスタンス管理者

OIMシステム構成者

リクエスト・データセット・ポリシー

このポリシーは、システム構成管理者ロールのメンバーがリクエスト・データセットに対して実行できるアクションを制御するために使用されます。

OrclOIMOrgScopingDirect=OrclOIMSystemConfiguratorOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMSystemConfiguratorOrgsWithHierarchy

システム構成管理者

OIMシステム構成者

リコンシリエーション管理者ポリシー

リコンシリエーション管理者は、リコンシリエーション・イベントに対してアクションを実行できます。このポリシーは、リコンシリエーション管理者が実行できるアクションを制御します。

システム構成管理者

OIMシステム構成者

OIMスケジューラ管理者ポリシー

スケジューラ管理者は、スケジュール済タスクに対してアクションを実行できます。このポリシーは、スケジューラ管理者が実行できるアクションを制御します。

システム構成管理者

OIMシステム構成者

システム・プロパティ管理ポリシー

このポリシーは、アクションを指定し、Oracle Identity Managerシステム・プロパティの管理の一部として誰がそれを実行できるのかを決定します。デフォルト動作では、システム構成管理者のみがシステム・プロパティを管理できます。

システム構成管理者

OIMシステム構成者

OIMユーザー管理構成管理者ポリシー

このポリシーは、システム構成管理者ロールのメンバーが使用できるユーザー構成機能を制御します。

認証済ロール

authenticated-role

組織用ホーム組織ポリシー

このポリシーは、ユーザーのホーム組織に公開済のアプリケーション・インスタンス、アカウント、権限と権限属性、およびユーザーを暗黙的に表示することをそのユーザーに許可します。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

OrclOIMNeedApproval=true

ユーザー管理者

OIMユーザー管理

ユーザー変更用ユーザー管理ポリシー

ユーザー管理は、組織のスコープが指定された管理ロールです。このロールのメンバーはユーザーを管理し、そのアクションに承認は必要ありません。このポリシーは、ユーザー管理者がユーザー属性を変更できるかどうかと、変更できない属性、および変更に承認が必要かどうかを指定します。デフォルトでは、このロールのメンバーはすべてのユーザー属性を変更でき、そのアクションに承認は必要ありません。

OrclOIMDeniedAttributesWithoutApproval=

OrclOIMNeedApproval=false

OrclOIMOrgScopingDirect=OrclOIMUserAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserAdminOrgsWithHierarchy

ユーザー管理者

OIMユーザー管理

管理アクション用ユーザー管理者ポリシー

ユーザー管理者は、組織のスコープが指定された管理ロールです。このロールのメンバーは、承認を必要とせずに、組織のスコープ内のユーザーに対してアクションを実行できます。このポリシーは、表示アクション以外のすてのアクションに適用されます。それによって、有効化されたアクションに対して承認が必要ないことを示す責任が返されます。

OrclOIMNeedApproval=false

OrclOIMOrgScopingWithHierarchy=OrclOIMUserAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserAdminOrgsDirect

ユーザー管理者

OIMユーザー管理

OIMユーザー管理ポリシー直接(属性利用)

このポリシーは、ユーザー管理者がユーザーおよびユーザー属性に対して実行できる直接アクションを制御します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMUserAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserAdminOrgsDirect

ユーザー管理者

OIMユーザー管理

リクエスト不能アクション用ユーザー管理ポリシー

ユーザー管理者は、組織のスコープが指定された管理ロールです。このロールのメンバーはユーザーを管理し、そのアクションに承認は必要ありません。このポリシーは、このロールのメンバーがユーザーに対して実行できる、承認を必要としないアクションを指定します。

OrclOIMOrgScopingDirect=OrclOIMUserAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserAdminOrgsWithHierarchy

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

ユーザー・ステータス管理用ヘルプ・デスク・ポリシー

このポリシーは、ユーザーのアカウント・ステータスの管理の一部としてユーザー・ヘルプ・デスク管理ロールのメンバーが実行できるアクションと、そのアクションに承認が必要かどうかを制御します。デフォルトでは、このロールのメンバーは、承認を必要とせずにユーザーのステータスを有効化または無効化できます。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMNeedApproval=true

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

ユーザー・アカウントの変更用OIMユーザー・ヘルプ・デスク・ポリシー

このポリシーは、ユーザー・アカウントの変更の一部としてユーザー・ヘルプ・デスク管理ロールのメンバーが実行できるアクションを制御します。

OrclOIMNeedApproval=false

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

ユーザー検索用ヘルプ・デスク管理ポリシー

ユーザー・ヘルプ・デスクは、組織のスコープが指定された管理ロールです。このロールのメンバーは、ユーザーの検索、ユーザー・プロファイルの変更、およびユーザー・パスワードの変更を実行できます。このポリシーは、このロールのメンバーがユーザーを検索できるかどうか、およびユーザー属性を表示できるかどうかを指定します。デフォルトでは、この管理ロールのメンバーはすべてのユーザー属性を表示できます。

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

パスワード管理用ヘルプ・デスク・ユーザー・ポリシー

ユーザー・ヘルプ・デスク管理ロールのメンバーは、ユーザーの検索、ユーザー・プロファイルの変更、およびユーザー・パスワードの変更を実行できます。このポリシーは、このロールのメンバーがユーザー・パスワードを管理できるかどうか、アカウントをロックまたはロック解除できるかどうか、およびユーザーが要求したリクエストを表示できるかどうかを指定します。

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

OIMユーザー・ヘルプ・デスク・ユーザーのロック解除ポリシー直接

このポリシーは、ユーザー・ヘルプ・デスクがユーザー・アカウントを直接ロック解除できるかどうかを決定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMAllowOnlyIfLockedByFailLoginAttempts=true

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

OIMヘルプ・デスク基本情報アプリケーション・インスタンス直接ポリシー

このポリシーは、ユーザー・ヘルプ・デスク管理ロールのメンバーによるアプリケーション・インスタンスに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

OIMヘルプ・デスク基本情報ITリソース権限直接ポリシー

このポリシーは、ユーザー・ヘルプ・デスク管理ロールのメンバーによるITリソース権限に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

OIMヘルプ・デスク基本情報ロール直接ポリシー

このポリシーは、ユーザー・ヘルプ・デスク管理ロールのメンバーによるロールに対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

ユーザー・ヘルプ・デスク

OIMユーザー・パスワード管理

OIMヘルプ・デスク基本情報組織直接ポリシー

このポリシーは、ユーザー・ヘルプ・デスク管理ロールのメンバーによる組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserHelpDeskOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserHelpDeskOrgsDirect

ユーザー・ビューア

OIMユーザー・ビューア

リクエスト・アクション用ユーザー・ビューア・ポリシー

ユーザー・ビューアは、組織のスコープが指定された管理ロールです。このポリシーは、管理ロールのメンバーがユーザーのプロファイルを変更できるかどうかと、そのアクションに承認が必要かどうかを制御します。デフォルトでは、ユーザー・ビューア・ロールのメンバーによって送信されたユーザー変更リクエストは承認が必要です。

OrclOIMNeedApproval=true

OrclOIMDeniedAttributesWithApproval=

OrclOIMOrgScopingDirect=OrclOIMUserViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserViewerOrgsWithHierarchy

ユーザー・ビューア

OIMユーザー・ビューア

ユーザー管理用ユーザー・ビューア・ポリシー

このポリシーは、ユーザー・ビューア・ロールのメンバーが実行できるアクションと、そのアクションに承認が必要かどうかを制御します。

OrclOIMOrgScopingWithHierarchy=OrclOIMUserViewerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMUserViewerOrgsDirect

OrclOIMNeedApproval=true

ユーザー・ビューア

OIMユーザー・ビューア

デフォルト・ユーザー・ビューア・ポリシー

ユーザー・ビューア管理ロールは、認証されたユーザーが検索および表示できるユーザーおよびその属性と権限付与を制御します。

OrclOIMOrgScopingDirect=OrclOIMUserViewerOrgsDirect

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMUserViewerOrgsWithHierarchy

ユーザー・ビューア

OIMユーザー・ビューア

ユーザー・ビューア・ポリシー

このポリシーは、ユーザー・ビューア管理ロールのメンバーが表示できるユーザーの属性およびリレーションシップを制御します。

OrclOIMOrgScopingDirect=OrclOIMUserViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMUserViewerOrgsWithHierarchy

認証済ロール

authenticated-role

ユーザー変更用管理チェーン・ポリシー

このポリシーは、ユーザーが、そのユーザーの管理チェーン内の別のユーザーを変更できるかどうかと、そのアクションに承認が必要かどうかを指定します。このポリシーは、承認を必要としないユーザー属性も指定します。デフォルトでは、パスワードを除くすべてのユーザー属性の変更に承認が必要です。

OrclOIMUserManagementScoping=OrclOIMUserId

OrclOIMNeedApproval=true

OrclOIMDeniedAttributesWithApproval=

認証済ロール

authenticated-role

ユーザーに対するアクション用管理チェーン・ポリシー

このポリシーは、ユーザーが管理チェーン内の他のユーザーに対して実行できるアクションと、そのアクションに承認が必要かどうかを制御します。デフォルトでは、承認が必要です。

OrclOIMNeedApproval=true

OrclOIMUserManagementScoping=OrclOIMUserId

認証済ロール

authenticated-role

ユーザー検索用管理チェーン・ポリシー

このポリシーは、ユーザーが管理チェーン内の他のユーザーを検索し、許可された属性を表示することを許可します。デフォルトでは、管理チェーン内の他のユーザーのすべての属性を表示できます。

OrclOIMDeniedAttributesDirect=

OrclOIMUserManagementScoping=OrclOIMUserId

認証済ロール

authenticated-role

管理ロール・アクション用管理チェーン・ポリシー

このポリシーは、ユーザーが管理チェーン内の他のユーザーに付与された管理ロールに対して実行できるアクションを制御します。

OrclOIMUserManagementScoping=OrclOIMUserId

認証済ロール

authenticated-role

ホーム組織承認ポリシー

ホーム組織は、ユーザーが所属するデフォルト組織です。このポリシーは、所属するホーム組織内でユーザーが実行できるアクションを制御し、そのアクションに承認が必要かどうかを判別するためにリクエスト・エンジンによって使用されます。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

OrclOIMNeedApproval=true

認証済ロール

authenticated-role

ホーム組織承認(属性利用)ポリシー

このポリシーは、所属するホーム組織内でユーザーが実行できるアクションを制御し、そのアクションに承認が必要かどうかを判別するためにリクエスト・エンジンによって使用されます。

OrclOIMDeniedAttributesWithApproval=USR_PASSWORD

OrclOIMNeedApproval=true

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

認証済ロール

authenticated-role

ユーザー属性用ホーム組織ポリシー

このポリシーは、同じホーム組織内の他のユーザーのユーザー・プロファイルを検索および表示するときに、ユーザーに表示されないユーザー属性を制御します。デフォルトでは、ユーザーはすべての属性を表示できます。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

OrclOIMDeniedAttributesDirect=

認証済ロール

authenticated-role

ユーザー・アクセスの表示用ホーム組織ポリシー

このポリシーは、同じホーム組織内の別のユーザーのアクセスを表示しているときにユーザーが実行できるアクションを制御します。

OrclOIMOrgScopingDirectAttributeOrclOIMUserHomeOrgs

認証済ロール

authenticated-role

自身のユーザー・プロファイルの変更用ポリシー

このポリシーは、自身のユーザー・プロファイルでユーザーが変更できるユーザー属性と、その変更に承認が必要かどうかを指定します。デフォルトでは、ユーザーは自身のプロファイルの任意の属性を変更でき、変更には承認が必要です。

OrclOIMNeedApproval=true

OrclOIMDeniedAttributesWithApproval=

認証済ロール

authenticated-role

リクエスト・アクション用ユーザー・セルフ・サービス・ポリシー

このポリシーは、認証されたユーザーがIdentity Self Service内で実行できるアクションと、承認が必要かどうかを制御します。

OrclOIMNeedApproval=true

認証済ロール

authenticated-role

セルフ用ユーザー属性表示ポリシー

このポリシーは、認証されたユーザーが自身のユーザー属性を表示できるかどうかと、表示できない属性を指定します。デフォルトでは、すべてのユーザー属性を表示できます。

OrclOIMDeniedAttributesDirect=

認証済ロール

authenticated-role

表示アクション用ユーザー・セルフ・サービス・ポリシー

このポリシーは、ユーザーが自身のプロファイルに対して実行できるアクション(リクエストを開始しない)を指定します。

SPML管理者

OIM SPML管理

ユーザー更新用SPML管理ポリシー

SPML管理は、グローバル管理ロールです。この管理ロールは、SPML Webサービスによってユーザー管理操作を実行するために使用されます。このポリシーは、このロールのメンバーがユーザーを変更できるかどうかと、そのアクションに承認が必要かどうかを指定します。デフォルトでは、ロールのメンバーによるユーザー変更は承認が必要です。

OrclOIMOrgScopingDirect=OrclOIMSPMLAdminOrgsDirect

OrclOIMNeedApproval=true

OrclOIMDeniedAttributesWithApproval=

OrclOIMOrgScopingWithHierarchy=OrclOIMSPMLAdminOrgsWithHierarchy

SPML管理者

OIM SPML管理

ユーザーに対するアクション用SPML管理ポリシー

このポリシーは、ユーザーを管理しているときにSPML管理ロールのメンバーが実行できるアクション、および承認が必要かどうかを制御します。デフォルトでは、このロールのメンバーによって実行されるユーザー管理アクションには承認が必要です。

OrclOIMOrgScopingDirect=OrclOIMSPMLAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMSPMLAdminOrgsWithHierarchy

OrclOIMNeedApproval=true

SPML管理者

OIM SPML管理

SPML管理者ポリシー

このポリシーは、SPML管理がユーザーに対して実行できるアクションを指定します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingDirect=OrclOIMSPMLAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMSPMLAdminOrgsWithHierarchy

SPML管理者

OIM SPML管理

ロール・メンバーシップ・アクション用SPML管理ポリシー

このポリシーは、SPML管理ロールのメンバーが実行できるロール・メンバーシップ・アクションと、そのアクションに承認が必要かどうかを制御します。デフォルトでは、アクションには承認が必要です。

OrclOIMOrgScopingWithHierarchy=OrclOIMSPMLAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMSPMLAdminOrgsDirect

OrclOIMNeedApproval=true

SPML管理者

OIM SPML管理

OIMロールSPML管理ポリシー直接(属性利用)

このポリシーは、SPML管理がロールおよびロール属性に対して直接実行できるアクションを指定します。

ロール認可者

OIMロール認可者

表示アクション用ロール認可者ポリシー

ロール認可者管理ロールは、組織のスコープが指定されたロールです。このポリシーは、承認を必要とせずにロール認可者が実行できるアクションを制御します。ロール・メンバーシップの表示やロールの検索などのアクションは承認を必要としません。組織のスコープが指定されたロールの検索およびロール・メンバーの表示は承認を必要としません。

OrclOIMOrgScopingDirect=OrclOIMRoleAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAuthorizerOrgsWithHierarchy

ロール認可者

OIMロール認可者

リクエスト・アクション用ロール認可者ポリシー

このポリシーは、承認を必要とするロール認可者が実行できるアクションを制御します。デフォルトでは、このロールのメンバーによるロール・メンバーシップの付与および取消しは承認を必要としません。

OrclOIMNeedApproval=false

OrclOIMOrgScopingDirect=OrclOIMRoleAuthorizerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAuthorizerOrgsWithHierarchy

ロール認可者

OIMロール認可者

OIMロール認可者基本情報組織直接ポリシー

このポリシーは、ロール認可者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAuthorizerOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMRoleAuthorizerOrgsDirect

ロール認可者

OIMロール認可者

OIMロール認可者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、ロール認可者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMRoleAuthorizerOrgsDirect

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAuthorizerOrgsWithHierarchy

ロール・ビューア

OIMロール・ビューア

ロール・ビューア・ポリシー

ロール・ビューアは、Oracle Identity Managerの管理ロールです。このポリシーは、ロールのメンバーが実行できるアクションを制御します。デフォルトでは、このポリシーによって、この管理ロールのメンバーは、ロールの検索および表示を許可されます。

OrclOIMOrgScopingDirect=OrclOIMRoleViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleViewerOrgsWithHierarchy

ロール・ビューア

OIMロール・ビューア

ロール・メンバーシップ用ロール・ビューア・ポリシー

このポリシーは、ロール・ビューアが実行できるアクションと、そのアクションが承認を必要とするかどうかを制御します。デフォルトでは、承認が必要です。

OrclOIMOrgScopingDirect=OrclOIMRoleViewerOrgsDirect

OrclOIMNeedApproval=true

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleViewerOrgsWithHierarchy

ロール・ビューア

OIMロール・ビューア

OIMロール・ビューア基本情報組織直接ポリシー

このポリシーは、ロール・ビューアによる組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMRoleViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleViewerOrgsWithHierarchy

ロール・ビューア

OIMロール・ビューア

OIMロール・ビューア基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、ロール・ビューアによるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingDirect=OrclOIMRoleViewerOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleViewerOrgsWithHierarchy

認証済ロール

authenticated-role

ロール・メンバーシップ用ホーム組織ポリシー

このポリシーは、ユーザーがそのユーザーのホーム組織内で実行できるロール・メンバーシップの付与および取消しアクションと、それに承認が必要かどうかを制御します。デフォルトでは、承認が必要です。

OrclOIMNeedApproval=true

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

認証済ロール

authenticated-role

ロール用ホーム組織ポリシー

このポリシーは、ユーザーのホーム組織に公開済のロールおよびロール属性を暗黙的に表示することをそのユーザーに許可します。

OrclOIMOrgScopingDirect=OrclOIMUserHomeOrgs

ロール管理者

OIMロール管理者

承認ありのOIMロール管理ポリシー

ロール管理者は、組織のスコープが指定された管理ロールです。このポリシーは、承認ありでロール管理者が実行できるアクションを指定します。

OrclOIMOrgScopingDirect=OrclOIMRoleAdminOrgsDirect

OrclOIMNeedApproval=false

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAdminOrgsWithHierarchy

ロール管理者

OIMロール管理者

ロール管理者ポリシー

このポリシーは、ロール管理者管理ロールのメンバーが実行できるアクションを制御します。

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMRoleAdminOrgsDirect

ロール管理者

OIMロール管理者

OIMロール管理者基本情報組織直接ポリシー

このポリシーは、ロール管理者による組織に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAdminOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMRoleAdminOrgsDirect

ロール管理者

OIMロール管理者

OIMロール管理者基本情報ユーザー直接(属性利用)ポリシー

このポリシーは、ロール管理者によるユーザーおよびユーザー属性に対する直接表示および検索権限を指定します。

OrclOIMOrgScopingDirect=OrclOIMRoleAdminOrgsDirect

OrclOIMDeniedAttributesDirect=

OrclOIMOrgScopingWithHierarchy=OrclOIMRoleAdminOrgsWithHierarchy

システム構成管理者

OIMシステム構成者

OIMエンティティ用システム構成者ポリシー

システム構成管理者管理ロールは、グローバル・ロールです。このポリシーは、このロールのメンバーが、ユーザー、権限、ロール、組織、およびアプリケーション・インスタンスに対して実行できるアクションを制御します。メンバーは、Identity System Administrationでアプリケーション・インスタンスを管理できますが、Identity Self Serviceではビューア管理ロール機能を持ちます。

OrclOIMOrgScopingWithHierarchy=OrclOIMSystemConfiguratorOrgsWithHierarchy

OrclOIMOrgScopingDirect=OrclOIMSystemConfiguratorOrgsDirect

システム構成管理者

OIMシステム構成者

システム構成者ポリシー

このポリシーは、システム構成管理者管理ロールのメンバーが実行できるアクションを制御します。この管理ロールのメンバーは、インストール後の製品構成アクティビティを実行し、システム管理者が実行できるすべての構成アクティビティを実行できます。ただし、システム構成管理者管理ロールのメンバーは、システム管理者管理ロールのメンバーが持っている暗黙的なユーザー、ロール、アプリケーション・インスタンス管理者機能を持ちません。

システム構成管理者

OIMシステム構成者

ユーザー用システム構成者ポリシー拒否ポリシー

このポリシーは、システム構成管理者のメンバーがユーザー・エンティティに対して実行できるアクションを制御します。

カタログ管理者

OIMカタログ管理者ロール

カタログ管理者用表示ポリシー

このポリシーは、カタログ管理者のカタログ・エンティティに対する表示権限を制御します。

OrclOIMOrgScopingDirect=OrclOIMCatalogAdminOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMCatalogAdminOrgsWithHierarchy

認証済ロール

authenticated-role

ユーザーに割り当てられたOIMエンティティの直接ポリシー

このポリシーは、認証されたユーザーが、割り当てられたエンティティに対して実行できるアクションを制御します。

認証済ロール

authenticated-role

ユーザーに割り当てられたOIMエンティティの承認ポリシー

このポリシーは、認証されたユーザーが、割り当てられたエンティティに対して実行できるアクションを制御します。

OrclOIMNeedApproval=true

証明管理者

OIM証明管理者

OIM UI証明管理者ポリシー

このポリシーは、証明構成および証明定義の画面を含むアイデンティティ・システム管理者UIに対してアクセス権限を付与します。

証明管理者

OIM証明管理者

証明管理者のすべてのエンティティ検索ポリシー

このポリシーは、証明定義の設計に必要なOracle Identity Managerエンティティに対して表示および検索機能を付与します。エンティティには、アプリケーション・インスタンス、権限、組織、ユーザー、エンタープライズ・ロールおよびカタログ・アイテムが含まれます。このポリシーは、証明定義の構成に使用されます。

OrclOIMOrgScopingDirect=OrclOIMCertificationAdministratorOrgsDirect

OrclOIMOrgScopingWithHierarchy=OrclOIMCertificationAdministratorOrgsWithHierarchy

証明管理者

OIM証明管理者

証明管理者ポリシー

このポリシーは、証明構成オブジェクト(証明構成や証明定義など)に対する更新アクセス権限を付与します。

証明管理者

OIM証明管理者

スケジューラ証明管理者ポリシー

このポリシーは、スケジューラに対してアクセス権限を付与します。スケジュール済ジョブの実行により、証明定義から証明が作成されます。

証明管理者

OIM証明管理者

証明管理者ポリシー

このポリシーは、証明インスタンスに対する更新アクセス権限を付与します。

注意: レビューア(非管理ユーザー)に対する証明の表示および更新アクセス権限は、証明認可により直接付与されます。

証明ビューア

OIM証明ビューア

証明ビューア・ポリシー

このポリシーは、証明インスタンスに対して表示アクセス権限を付与します。

注意: 証明管理者は、すべての証明ビューア権限を保持しています。

OESには、Oracle Identity Managerのユーザーには付与できないため、対応する管理ロールがOracle Identity Managerにないアプリケーション・ロールがいくつかあります。これらのアプリケーション・ロールに関連付けられているポリシーは、リクエスト関連の操作に使用されます。たとえば、OIMリクエスト承認者アプリケーション・ロールと関連付けられてポリシーは、リクエストの承認者の操作を制御するために使用されます。表3-4は、Oracle Identity Managerに対応する管理ロールがないアプリケーション・ロールと、それに関連付けられているポリシーを示しています。

表3-4 OESアプリケーション・ロールとポリシー

OESのアプリケーション・ロール

ポリシー名

説明

責任

OIMリクエスト承認者

OIMリクエスト承認者ロール・ポリシー

このポリシーは、リクエスト承認者がロールを表示および検索する権限を指定します。

OIMリクエスト・リクエスタ

OIMリクエスト・リクエスタ・ロール・ポリシー

このポリシーは、リクエスタがロールを表示および検索する権限を指定します。

OIMリクエスト受益者

OIMリクエスト受益者ロール・ポリシー

このポリシーは、リクエストの受益者がロールを表示および検索する権限を指定します。

OIMリクエスト承認者

OIMリクエスト承認者アプリケーション・インスタンス・ポリシー

このポリシーは、リクエスト承認者がアプリケーション・インスタンスを表示および検索する権限を指定します。

OIMリクエスト・リクエスタ

OIMリクエスト・リクエスタ・アプリケーション・インスタンス・ポリシー

このポリシーは、リクエスタがアプリケーション・インスタンスを表示および検索する権限を指定します。

OIMリクエスト受益者

OIMリクエスト受益者アプリケーション・インスタンス・ポリシー

このポリシーは、リクエストの受益者がアプリケーション・インスタンスを表示および検索する権限を指定します。

OIMリクエスト承認者

OIMリクエスト承認者権限ポリシー

このポリシーは、リクエスト承認者が権限を表示および検索する権限を指定します。

OIMリクエスト・リクエスタ

OIMリクエスト・リクエスタ権限ポリシー

このポリシーは、リクエスタが権限を表示および検索する権限を指定します。

OIMリクエスト受益者

OIMリクエスト受益者権限ポリシー

このポリシーは、リクエストの受益者が権限を表示および検索する権限を指定します。

OIMリクエスト承認者

OIMリクエスト承認者ユーザー・ポリシー

このポリシーは、リクエスト承認者がユーザーを表示および検索する権限を指定します。

OrclOIMDeniedAttributesDirect=

OIMリクエスト・リクエスタ

OIMリクエスト・リクエスタ・ユーザー・ポリシー

このポリシーは、リクエスタがユーザーを表示および検索する権限を指定します。

OrclOIMDeniedAttributesDirect=

OIMリクエスト受益者

OIMリクエスト受益者ユーザー・ポリシー

このポリシーは、リクエストの受益者がユーザーを表示および検索する権限を指定します。

OrclOIMDeniedAttributesDirect=

OIMリクエスト委任管理

OIMリクエスト委任管理ロール・ポリシー

このポリシーは、委任管理者がロールを表示および検索する権限を指定します。

OIMリクエスト・ターゲット・エンティティ

OIMリクエスト・ターゲット・エンティティ・ロール・ポリシー

このポリシーは、リクエストのターゲット・ユーザーがロールを表示および検索する権限を指定します。

OIMリクエスト委任管理

OIMリクエスト委任管理ユーザー・ポリシー

このポリシーは、委任管理者がユーザーを表示および検索する権限を指定します。

OIMリクエスト・ターゲット・エンティティ

OIMリクエスト・ターゲット・エンティティ・ユーザー・ポリシー

このポリシーは、リクエストのターゲット・ユーザーがユーザーを表示および検索する権限を指定します。

OIMリクエスト委任管理

OIMリクエスト委任管理ITリソース権限ポリシー

このポリシーは、委任管理者がITリソース権限を表示および検索する権限を指定します。

OIMリクエスト・ターゲット・エンティティ

OIMリクエスト・ターゲット・エンティティITリソース権限ポリシー

このポリシーは、リクエストのターゲット・ユーザーがITリソース権限を表示および検索する権限を指定します。

OIMリクエスト委任管理

OIMリクエスト委任管理アプリケーション・インスタンス・ポリシー

このポリシーは、委任管理者がアプリケーション・インスタンスを表示および検索する権限を指定します。

OIMリクエスト・ターゲット・エンティティ

OIMリクエスト・ターゲット・エンティティ・アプリケーション・インスタンス・ポリシー

このポリシーは、リクエストのターゲット・ユーザーがアプリケーション・インスタンスを表示および検索する権限を指定します。

OIMリクエスト証明ビューア

OIM証明リクエスト証明者ターゲット・エンティティ・ロール・ポリシー

このポリシーは、ロール・エンティティに対して表示アクセス権限を付与します。このポリシーは、ユーザーが証明者(レビューア)となっている証明で参照されるロールを表示するためにログイン・ユーザーに動的に付与するリクエスト証明ビューアに対して付与されます。

OIMリクエスト証明ビューア

OIM証明リクエスト証明者ターゲット・エンティティ・ユーザー・ポリシー

このポリシーは、ユーザー・エンティティに対して表示アクセス権限を付与します。このポリシーは、ユーザーが証明者(レビューア)となっている証明で参照されるユーザーを表示するためにログイン・ユーザーに動的に付与するリクエスト証明ビューアに対して付与されます。

OIMリクエスト証明ビューア

OIM証明リクエスト証明者ターゲット・エンティティITResEntitlementポリシー

このポリシーは、権限エンティティに対して表示アクセス権限を付与します。このポリシーは、ユーザーが証明者(レビューア)となっている証明で参照される権限を表示するためにログイン・ユーザーに動的に付与するリクエスト証明ビューアに対して付与されます。

OIMリクエスト証明ビューア

OIM証明リクエスト証明者ターゲット・エンティティApplicationInstanceポリシー

このポリシーは、アプリケーション・インスタンス・エンティティに表示アクセス権限を付与します。このポリシーは、ユーザーが証明者(レビューア)となっている証明で参照されるアプリケーション・インスタンスを表示するためにログイン・ユーザーに動的に付与するリクエスト証明ビューアに対して付与されます。

アプリケーション・ロールのアプリケーション・ロール階層は、OESで定義されます。つまり、特定の組織のアプリケーション・ロールを付与されたユーザーは、その特定の組織階層に存在するアプリケーション・ロールのすべてのアクションを実行できます。たとえば、ユーザーが特定の組織のOrclOIMUserViewerアプリケーション・ロール(つまり、ユーザー・ビューア管理ロール)を持っている場合、そのユーザーは、その特定の組織に存在するOrclOIMApplicationInstanceViewerRole、OrclOIMEntitlementViewer、OrclOIMOrgViewer、およびOrclOIMRoleViewerアプリケーション・ロールのすべてのアクションを実行できます。

表3-5は、アプリケーション・ロールと、特定の組織における対応するアプリケーション・ロールとの間のマッピングを示しています。つまり、2列目のアプリケーション・ロールを付与されたユーザーは、1列目の対応するアプリケーション・ロールのすべてのアクションを実行できます。

表3-5 アプリケーション・ロールのマッピング

アプリケーション・ロール

アプリケーション・ロールのマップ先

OrclOIMRoleViewer

OrclOIMUserAdmin、OrclOIMUserViewer

OrclOIMOrgViewer

OrclOIMUserAdmin、OrclOIMUserViewer、OrclOIMSPMLAdmin

OrclOIMEntitlementViewer

OrclOIMUserAdmin、OrclOIMUserViewer

OrclOIMEntitlementAdministrator

OrclOIMApplicationInstanceAdministratorRole

OrclOIMApplicationInstanceViewerRole

OrclOIMUserAdmin、OrclOIMUserViewer

OrclOIMCertificationViewer

OrclOIMCertificationAdministrator

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、以前のリリースのロールのいくつかは削除されているか、別のロールに置き換えられています。表3-6は、以前のロールと新しいロールとの間のマッピングを示しています。

表3-6 以前のロールと新しいロールとの間のマッピング

以前のロール

新規ロール

スケジューラ管理者

システム構成者

デプロイメント・マネージャ管理者

システム構成者

通知テンプレート管理者

システム構成者

SOD管理者

システム管理者

ユーザー名の生成ロール

システム管理者

アイデンティティ・ユーザー管理者

ユーザー管理者

ユーザー構成管理者

システム構成者

アクセス・ポリシー管理者

システム構成者

リコンシリエーション管理者

システム管理者

リソース管理者

システム構成者

汎用コネクタ管理者

システム構成者

承認ポリシー管理者

システム構成者

リクエスト管理者

システム管理者

リクエスト・テンプレート管理者

システム構成者

プラグイン管理者

システム構成者

アテステーション構成管理者

システム構成者

アテステーション・イベント管理者

システム管理者

ロール管理者

ロール管理者

ユーザー名管理者

以前のロールは削除されたため、現在のリリースには対応するロールはありません。管理ロールに依存します。

アイデンティティ組織管理者

組織管理者

ITリソース管理者

アプリケーション・インスタンス管理者

レポート管理者

以前のロールは削除されたため、現在のリリースには対応するロールはありません。これは、Oracle Identity Managerからのレポートへのリンクがないためです。

SPMLアプリケーション・ロール

SPMLアプリケーション・ロール

このエンタープライズ・ロールに対する変更はありません。ただし、権限付きの対応するロールはOESにシードされています。

注意: このロールは、Oracle Identity Managerでは使用されません。

すべてのユーザー

すべてのユーザー

このロールはエンタープライズ・ロールのままです。したがって、OESには対応するアプリケーション・ロールがありません。

このロールは、Oracle Identity Manager Enterprise Editionではアクセス・ポリシーベースのプロビジョニング操作のために必要です。

システム構成管理者

システム構成者

このロールは、ユーザー、ロール、組織およびプロビジョニングを管理する機能を除いて、システム管理者ロールとしてのすべての権限を持っています。この管理ロールは、システム管理者ロールとしてのシステムへの完全なアクセスを必要としないシステム構成タスクに使用されます。

システム管理者

システム管理者

このロールは、システム上の完全な権限を提供するものとしてそのままになっています。このロールは、コード・レベルで適用される無制限の権限を許可します(このロールの宣言的なセキュリティ・モデルはありません)。したがって、OESには、このロールに対応するポリシーはありません。

3.3 組織へのエンティティの公開

組織にエンティティを公開すると、エンティティはその組織で使用可能になります。エンタープライズ・ロール、権限またはアプリケーション・インスタンスについては、それぞれの管理者が組織のリストに公開することによって、その組織のユーザーに付与できるようなります。エンタープライズ・ロール、権限およびアプリケーション・インスタンスは、次の目的で、組織のリストに公開されます。

- リストの組織に属するユーザーがリクエストできるようにする

- これらのロールを、リストの組織の管理者が管理できるようにする

エンティティ管理者がエンティティを作成すると、エンティティは、その管理者がエンティティ管理者ロールを持つすべての組織で自動的に使用可能になります。たとえば、ロール管理者権限を持つユーザーがエンタープライズ・ロールを作成すると、新しく作成されたロールは、そのユーザーがロール管理者として属するすべての組織で自動的に使用可能になります。これによって、管理者がエンティティを作成して、それぞれの組織(または組織階層)に公開する必要がなくなります。ただし、このエンティティをその他の組織に公開する必要がある場合は、エンティティを手動で公開する必要があります。

エンティティ管理者は、エンティティ詳細ページを使用して組織にエンティティを公開できます。たとえば、一連の組織にロールを公開するには、「ロールの詳細」ページの「組織」タブから実行します。

次のエンティティを組織に公開する方法の参照先を示します。

- 組織へのロールの公開: 『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』の組織へのロールの公開に関する説明を参照してください。

- 組織へのアプリケーション・インスタンス(権限あり/なし)の公開: 『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の組織へのアプリケーション・インスタンスの公開に関する説明を参照してください。

3.4 OESポリシーの管理

表3-3で示したように、Oracle Identity Managerの各管理ロールには、OESのポリシー・ロールとの1対1のマッピングがあり、それぞれ対応するOESポリシーがあります。デフォルトの認可ポリシーをカスタマイズするには、認可ポリシー管理(APM) UIを使用して、OESポリシーを変更できます。たとえば、特定の管理ロールによって表示される属性のリストを制限するには、APMで対応するOESポリシーのOrclOIMDeniedAttributesポリシー責任を更新できます。同様に、特定の管理ロールによって編集される属性のリストを制限する場合は、OrclOIMDeniedAttributesWithApproval責任を更新できます。

APM UIを使用してOESポリシーを管理する方法の詳細は、Oracle Fusion Middleware Oracle Authorization Policy Manager管理者ガイド(Oracle Fusion Applications Edition)のポリシーおよびポリシー・オブジェクトの管理に関する説明を参照してください。

3.4.1 認可ポリシーのカスタマイズ

Oracle Identity Managerでの認可セキュリティのデフォルト機能は、次の方法から1つ以上を使用してカスタマイズできます。

- 既存のポリシーの許可されたアクションの変更

- 責任の変更。これには、次の内容が含まれます。

- 拒否された属性リストの変更

- 承認が必要なブール・フラグのtrue/falseの変更

- スコーピング属性の変更

- ポリシー条件の変更。これには、次の内容が含まれます。

- ポリシーを無効化するためのFALSE条件の追加

- ポリシーでのデフォルト条件の変更

- リソース/動的属性の追加および既存のポリシーでの使用

- デフォルト・ポリシーの削除

次の各項では、デフォルト認可をカスタマイズするために変更可能な管理ロールと認可ポリシーとのマッピングについて説明します。

- 誰がどのユーザーを表示できるかの制御

- 誰がどのユーザーを変更できるかの制御

- 誰がどのリンクを表示できるかの制御

- 誰がアプリケーション・インスタンスのアカウントをリクエストできるかの制御

- 誰がアカウントを変更できるかの制御

- 誰がアプリケーション・インスタンスを管理できるかの制御

- 誰がユーザー・パスワードを変更できるかの制御

- 誰がアカウント・パスワードを変更できるかの制御

- どの操作が直接またはリクエスト・ベースであるかの制御

- セルフ・プロファイルの拒否属性の制御

3.4.1.1 誰がどのユーザーを表示できるかの制御

「誰がどのユーザーを表示できるかの制御」は、表3-7に示した管理ロールを使用して制御できます。これらの管理ロールにより、スコープされた組織内のユーザーを表示または検索する権限がユーザーに付与されます。

表3-7 スコープされた組織内のユーザーを表示または検索する管理ロール

管理者ロール

関連する認可ポリシー名

アプリケーション・インスタンス管理者ロール

ApplicationInstanceAdministratorBasicInfoUserDirectWithAttributesPolicy

アプリケーション・インスタンス認可者ロール

ApplicationInstanceAuthorizerBasicInfoUserDirectWithAttributesPolicy

アプリケーション・インスタンス・ビューア・ロール

ApplicationInstanceViewerBasicInfoUserDirectWithAttributesPolicy

権限管理者

EntitlementAdministratorBasicInfoUserDirectWithAttributesPolicy

権限認可者

EntitlementAuthorizerBasicInfoUserDirectWithAttributesPolicy

権限ビューア

EntitlementViewerBasicInfoUserDirectWithAttributesPolicy

組織管理者

OrgAdministratorBasicInfoUserDirectWithAttributesPolicy

組織ビューア

OrgViewerBasicInfoUserDirectWithAttributesPolicy

ロール管理者

RoleAdministratorBasicInfoUserDirectWithAttributesPolicy

ロール認可者

RoleAuthorizerBasicInfoUserDirectWithAttributesPolicy

ロール・ビューア

RoleViewerBasicInfoUserDirectWithAttributesPolicy

ユーザー管理

UserAdminDirectWithAttributesPolicy

ユーザー・ヘルプ・デスク

UserHelpDeskDirectWithAttributesPolicy

管理ロールではなく、ホーム組織

UserHomeOrgDirectWithAttributesPolicy

管理ロールではなく、管理階層向け

UserManagementChainDirectWithAttributesPolicy

SPML管理

UserSPMLAdminDirectWithAttributesPolicy

管理ロールではなく、セルフ向け

UserSelfServiceDirectWithAttributesPolicy

ユーザー・ビューア

UserViewerDirectWithAttributesPolicy

すべてのユーザーを表示できるユーザーを制御するには、表3-7に示すように、割り当てられた管理ロールを更新します。ホーム組織のユーザーを制限する場合は、認可ポリシーを変更する必要があります。

3.4.1.2 誰がどのユーザーを変更できるかの制御

表3-8に、誰がどのユーザーを変更できるかを制御する管理ロールと、関連する認可ポリシーを示します。

表3-8 スコープされた組織内のユーザーを変更する管理ロール

管理者ロール

関連する認可ポリシー名

ユーザー管理

UserAdminApprovalWithAttributesPolicy

管理ロールではなく、ホーム組織

UserHomeOrgApprovalWithAttributesPolicy

管理ロールではなく、管理階層向け

UserManagementChainApprovalWithAttributesPolicy

SPML管理

UserSPMLAdminApprovalWithAttributesPolicy

管理ロールではなく、セルフ向け

UserSelfServiceApprovalWithAttributesPolicy

ユーザー・ビューア

UserViewerApprovalWithAttributesPolicy

すべてのユーザーを変更できるユーザーを制御するには、表3-8に示すように、割り当てられた管理ロールを更新します。ホーム組織のユーザーを制限する場合は、関連する認可ポリシーを変更する必要があります。

3.4.1.3 誰がどのリンクを表示できるかの制御

表3-9に、ポリシーにより有効化された管理ロール、関連する認可ポリシーおよび対応するリンクを示します。

表3-9 リンクの表示を制御する管理ロール

管理者ロール

関連する認可ポリシー名

ポリシーにより有効化されたリンク

ユーザー管理

UserAdminApprovalPolicy

enableUserStatus、modifyUserAccounts、deleteUserAccounts、addUserEntitlements、disableUserStatus、addUserRoles、createUser、disableUserAccount、deleteUserRoles、deleteUser、deleteUserEntitlements、enableUserAccount、addUserAccounts

ユーザー・ヘルプ・デスク

UserHelpDeskApprovalPolicy

enableUserStatus、disableUserStatus

ユーザー・ヘルプ・デスク

UserHelpDeskUserAccountsPolicy

modifyUserAccounts

管理ロールではなく、ホーム組織

UserHomeOrgApprovalPolicy

enableUserStatus、modifyUserAccounts、deleteUserAccounts、addUserEntitlements、disableUserStatus、createUser、addUserRoles、disableUserAccount、deleteUserRoles、deleteUser、deleteUserEntitlements、enableUserAccount、addUserAccounts

管理ロールではなく、管理階層向け

UserManagementChainApprovalPolicy

enableUserStatus、modifyUserAccounts、deleteUserAccounts、addUserEntitlements、disableUserStatus、addUserRoles、createUser、disableUserAccount、deleteUserRoles、deleteUser、deleteUserEntitlements、enableUserAccount、addUserAccounts

管理ロールではなく、セルフ向け

UserSelfServiceApprovalPolicy

addUserRoles、deleteUserRoles、deleteUserEntitlements、deleteUserAccounts、addUserEntitlements、addUserAccounts

SPML管理

UserSPMLAdminApprovalPolicy

enableUserStatus、disableUserStatus、createUser、addUserRoles、deleteUserRoles、deleteUser

ユーザー・ビューア

UserViewerApprovalPolicy

enableUserStatus、modifyUserAccounts、deleteUserAccounts、addUserEntitlements、disableUserStatus、addUserRoles、createUser、disableUserAccount、deleteUserRoles、deleteUser、deleteUserEntitlements、enableUserAccount、addUserAccounts

表3-9で示したように、管理ロールと関連するポリシーにより、許可されたアクションに従ってリンクを有効化する権限が付与されます。ポリシーを使用して認可ポリシーの更新や有効化されたリンクの変更、またそれに応じた管理ロールの割当てを実行できます。

3.4.1.4 誰がアプリケーション・インスタンスのアカウントをリクエストできるかの制御

表3-10に、誰がアプリケーション・インスタンスのアカウントをリクエストできるかを制御する管理ロールと、関連する認可ポリシーを示します。

表3-10 誰がアプリケーション・インスタンスのアカウントをリクエストできるかの制御

管理者ロール

関連する認可ポリシー名

アプリケーション・インスタンス認可者ロール

ApplicationInstanceAuthorizerApprovalPolicy

管理ロールではなく、ユーザーのホーム組織に公開されるアプリケーション・インスタンス

ApplicationInstanceHomeOrgApprovalPolicy

アプリケーション・インスタンス・ビューア・ロール

ApplicationInstanceViewerApprovalPolicy

3.4.1.5 誰がアカウントを変更できるかの制御

表3-11に、誰がアカウントを変更できるかを制御する管理ロールと、関連する認可ポリシーを示します。

表3-11 アカウントを変更するための管理ロール

管理者ロール

関連する認可ポリシー名

アプリケーション・インスタンス認可者ロール

ApplicationInstanceAuthorizerApprovalPolicy

管理ロールではなく、ユーザーのホーム組織に公開されるアプリケーション・インスタンス

ApplicationInstanceHomeOrgApprovalPolicy

アプリケーション・インスタンス・ビューア・ロール

ApplicationInstanceViewerApprovalPolicy

管理ロールではなく、ユーザーにのみプロビジョニングされるアプリケーション・インスタンス

EntityUserAssignmentApprovalPolicy

3.4.1.6 誰がアプリケーション・インスタンスを管理できるかの制御

誰がアプリケーション・インスタンスを管理できるかの制御には、「アプリケーション・インスタンス管理者」管理ロールと、関連するApplicationInstanceAdministratorDirectPolicy認可ポリシーが使用されます。

3.4.1.7 誰がユーザー・パスワードを変更できるかの制御

表3-12に、誰がユーザーのパスワードを変更できるかを制御する管理ロールと、関連する認可ポリシーを示します。

表3-12 ユーザー・パスワードを変更するための管理ロール

管理者ロール

関連する認可ポリシー名

ユーザー管理

UserAdminDirectPolicy

ユーザー・ヘルプ・デスク

UserHelpDeskDirectPolicy

管理ロールではなく、セルフ向け

UserSelfServiceDirectPolicy

3.4.1.8 誰がアカウント・パスワードを変更できるかの制御

表3-13に、アカウント・パスワードの変更のための、選択済ユーザーに対する権限を示します。

表3-13 選択済ユーザーに対する権限を持つ管理ロール

管理ロール

関連する認可ポリシー名

ユーザー管理

UserAdminDirectPolicy

ユーザー・ヘルプ・デスク

UserHelpDeskDirectPolicy

管理ロールではなく、セルフ向け

UserSelfServiceDirectPolicy

表3-14は、管理者がアカウント・パスワードを変更する権限を有する選択済アカウントについて示しています。

表3-14 選択済アカウントに対する権限を有する管理ロール

管理ロール

関連する認可ポリシー名

アプリケーション・インスタンス認可者ロール

ApplicationInstanceAuthorizerDirectPolicy

管理ロールではなく、ユーザーのホーム組織に公開されるアプリケーション・インスタンス

ApplicationInstanceHomeOrgDirectPolicy

アプリケーション・インスタンス・ビューア・ロール

ApplicationInstanceViewerDirectPolicy

管理ロールではなく、ユーザーにのみプロビジョニングされるアプリケーション・インスタンス

EntityUserAssignmentDirectPolicy

3.4.1.9 どの操作が直接またはリクエスト・ベースであるかの制御

表3-15に示す操作と、関連する認可ポリシーにより、操作がリクエストとバインドできるようになります。approvalrequired責任を直接操作にするには、関連する認可ポリシーで変更できます。

表3-15 リクエスト・ベースの操作

リクエスト・ベースの操作

関連する認可ポリシー名

enablenApplicationInstance

ApplicationInstanceHomeOrgApprovalPolicy

revokeApplicationInstance

ApplicationInstanceHomeOrgApprovalPolicy

modifyAccountApplicationInstance

ApplicationInstanceHomeOrgApprovalPolicy

disableApplicationInstance

ApplicationInstanceHomeOrgApprovalPolicy

provisionApplicationInstance

ApplicationInstanceHomeOrgApprovalPolicy

enablenApplicationInstance

ApplicationInstanceViewerApprovalPolicy

revokeApplicationInstance

ApplicationInstanceViewerApprovalPolicy

modifyAccountApplicationInstance

ApplicationInstanceViewerApprovalPolicy

disableApplicationInstance

ApplicationInstanceViewerApprovalPolicy

provisionApplicationInstance

ApplicationInstanceViewerApprovalPolicy

deleteRoleMemberships

EntityUserAssignmentApprovalPolicy

enablenApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeApplicationInstance

EntityUserAssignmentApprovalPolicy

modifyAccountApplicationInstance

EntityUserAssignmentApprovalPolicy

disableApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeITResourceEntitlement

EntityUserAssignmentApprovalPolicy

modifyProvisionedEntitlement

EntityUserAssignmentApprovalPolicy

grantITResourceEntitlement

EntitlementHomeOrgApprovalPolicy

bulkRequestForEntitlements

EntitlementHomeOrgApprovalPolicy

revokeITResourceEntitlement

EntitlementHomeOrgApprovalPolicy

modifyProvisionedEntitlement

EntitlementHomeOrgApprovalPolicy

grantITResourceEntitlement

EntitlementViewerApprovalPolicy

bulkRequestForEntitlements

EntitlementViewerApprovalPolicy

revokeITResourceEntitlement

EntitlementViewerApprovalPolicy

modifyProvisionedEntitlement

EntitlementViewerApprovalPolicy

deleteRoleMemberships

EntityUserAssignmentApprovalPolicy

enablenApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeApplicationInstance

EntityUserAssignmentApprovalPolicy

modifyAccountApplicationInstance

EntityUserAssignmentApprovalPolicy

disableApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeITResourceEntitlement

EntityUserAssignmentApprovalPolicy

modifyProvisionedEntitlement

EntityUserAssignmentApprovalPolicy

viewPublishedAccounts

OrganizationHomeOrgDirectPolicy

viewProvisionedAccounts

OrganizationHomeOrgDirectPolicy

viewSearchEntity

OrganizationHomeOrgDirectPolicy

viewPublishedEntitlements

OrganizationHomeOrgDirectPolicy

deleteRoleMemberships

EntityUserAssignmentApprovalPolicy

enablenApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeApplicationInstance

EntityUserAssignmentApprovalPolicy

modifyAccountApplicationInstance

EntityUserAssignmentApprovalPolicy

disableApplicationInstance

EntityUserAssignmentApprovalPolicy

revokeITResourceEntitlement

EntityUserAssignmentApprovalPolicy

modifyProvisionedEntitlement

EntityUserAssignmentApprovalPolicy

deleteRoleMemberships

RoleHomeOrgApprovalPolicy

addRoleMemberships

RoleHomeOrgApprovalPolicy

deleteRoleMemberships

RoleSPMLAdminApprovalPolicy

deleteRole

RoleSPMLAdminApprovalPolicy

addRoleMemberships

RoleSPMLAdminApprovalPolicy

createRole

RoleSPMLAdminApprovalPolicy

modifyRole

RoleSPMLAdminApprovalPolicy

deleteRoleMemberships

RoleViewerApprovalPolicy

addRoleMemberships

RoleViewerApprovalPolicy

enableUserStatus

UserHelpDeskApprovalPolicy

disableUserStatus

UserHelpDeskApprovalPolicy

enableUserStatus

UserHomeOrgApprovalPolicy

modifyUserAccounts

UserHomeOrgApprovalPolicy

deleteUserAccounts

UserHomeOrgApprovalPolicy

addUserEntitlements

UserHomeOrgApprovalPolicy

disableUserStatus

UserHomeOrgApprovalPolicy

createUser

UserHomeOrgApprovalPolicy

addUserRoles

UserHomeOrgApprovalPolicy

disableUserAccount

UserHomeOrgApprovalPolicy

deleteUserRoles

UserHomeOrgApprovalPolicy

deleteUser

UserHomeOrgApprovalPolicy

deleteUserEntitlements

UserHomeOrgApprovalPolicy

enableUserAccount

UserHomeOrgApprovalPolicy

addUserAccounts

UserHomeOrgApprovalPolicy

modifyUser

UserHomeOrgApprovalWithAttributesPolicy

enableUserStatus

UserManagementChainApprovalPolicy

modifyUserAccounts

UserManagementChainApprovalPolicy

deleteUserAccounts

UserManagementChainApprovalPolicy

addUserEntitlements

UserManagementChainApprovalPolicy

disableUserStatus

UserManagementChainApprovalPolicy

addUserRoles

UserManagementChainApprovalPolicy

createUser

UserManagementChainApprovalPolicy

disableUserAccount

UserManagementChainApprovalPolicy

deleteUserRoles

UserManagementChainApprovalPolicy

deleteUser

UserManagementChainApprovalPolicy

deleteUserEntitlements

UserManagementChainApprovalPolicy

enableUserAccount

UserManagementChainApprovalPolicy

addUserAccounts

UserManagementChainApprovalPolicy

modifyUser

UserManagementChainApprovalWithAttributesPolicy

enableUserStatus

UserSPMLAdminApprovalPolicy

disableUserStatus

UserSPMLAdminApprovalPolicy

createUser

UserSPMLAdminApprovalPolicy

addUserRoles

UserSPMLAdminApprovalPolicy

deleteUserRoles

UserSPMLAdminApprovalPolicy

deleteUser

UserSPMLAdminApprovalPolicy

modifyUser

UserSPMLAdminApprovalWithAttributesPolicy

addUserRoles

UserSelfServiceApprovalPolicy

deleteUserRoles

UserSelfServiceApprovalPolicy

deleteUserEntitlements

UserSelfServiceApprovalPolicy

deleteUserAccounts

UserSelfServiceApprovalPolicy

addUserEntitlements

UserSelfServiceApprovalPolicy

addUserAccounts

UserSelfServiceApprovalPolicy

modifyUser

UserSelfServiceApprovalWithAttributesPolicy

enableUserStatus

UserViewerApprovalPolicy

modifyUserAccounts

UserViewerApprovalPolicy

deleteUserAccounts

UserViewerApprovalPolicy

addUserEntitlements

UserViewerApprovalPolicy

disableUserStatus

UserViewerApprovalPolicy

addUserRoles

UserViewerApprovalPolicy

createUser

UserViewerApprovalPolicy

disableUserAccount

UserViewerApprovalPolicy

deleteUserRoles

UserViewerApprovalPolicy

deleteUser

UserViewerApprovalPolicy

deleteUserEntitlements

UserViewerApprovalPolicy

enableUserAccount

UserViewerApprovalPolicy

addUserAccounts

UserViewerApprovalPolicy

modifyUser

UserViewerApprovalWithAttributesPolicy

直接報告先以外のユーザーのピアに対するリクエストの検索/提起を無効にするには、次の手順を実行します。

1. ユーザーのホーム組織ポリシーを無効化/非アクティブ化/削除して、ピア権限を拒否します。これらのポリシーは、次のとおりです。

- ユーザー・ホーム組織承認ポリシー

- ユーザー・ホーム組織直接ポリシー

- ユーザー・ホーム組織直接(属性利用)ポリシー

2. 間接報告先に対するリクエストの検索、表示、提起を拒否するには、次の手順を実行します。

1. デフォルトでは、Oracle Identity Managerにより、間接報告先に対するリクエストの検索、表示、提起が許可されています。間接報告先からの許可を削除するには、認可プラグインを作成後、isDirectReporteeとして属性を渡し、その値をTRUE/FALSEとして返します。

2. ポリシー条件で属性を使用するために、次のユーザー・ポリシーを更新します。

- ユーザー管理チェーン承認ポリシー

- ユーザー管理チェーン承認(属性利用)ポリシー

- ユーザー管理チェーン直接(属性利用)ポリシー

3.4.1.10 セルフ・プロファイルの拒否属性の制御

セルフ・プロファイルの拒否属性を制御するには、APMを使用して次の認可ポリシーのポリシー責任を変更します。

- OrclOIMUserHomeOrgDirectWithAttributesPolicy

- OrclOIMUserSelfServiceDirectWithAttributesPolicy

3.5 機能セキュリティの強制

次の方法で、セキュリティを強制できます。

- UIレベル・セキュリティ: UIレベルの検証を行ってセキュリティを実施する場合に使用されます。たとえば、フィールドを表示および編集する権限を持つユーザーのみがそのフィールドにアクセス可能にする場合は、フィールドレベル・セキュリティを実装できます。フィールドの権限を持たないユーザーに対しては、そのフィールドは無効化されるか、表示されません。このタイプのセキュリティ実施はUIレベルであり、APIを使用して検証を実行する場合はオーバーライドできます。

注意:

UIレベルで機能セキュリティを実施するには、次のことを理解している必要があります。

- UIコンポーネント、およびUIコンポーネントのカスタマイズ方法。詳細は、「インタフェースのカスタマイズ」を参照してください。

- 式言語(EL)の構文と使用方法。詳細は、「UIカスタマイズでの式言語の使用」を参照してください。

- バックエンド・セキュリティ: バックエンドでセキュリティを実施するには、APM UIを使用してOESポリシーを変更できます。

機能セキュリティを実装するために、最初にJAVA認可ファイルがPlatformUIで作成されます。このファイルには、各機能またはページまたはモジュールのPolicyConstants (OESポリシー)で定義されるすべての権限のUIPermission変数が含まれています。すべての認可ファイルは、JDeveloperのMainUIプロジェクトのadfc-config.xmlファイルにエントリを持ちます。

機能セキュリティの実装では、次の操作を実行します。

- タスク・フローまたはリージョンの実装

- 定義済のアクション

- フィールドレベル・セキュリティの実装

3.5.1 タスク・フローまたはリージョンの実装

このレベルの実装では、ユーザーの権限に基づいてそのユーザーに対してタスク・フロー・リージョンを非表示にするか、無効化するかが決定されます。リージョンを保護する場合は、次の例を検討してください。my-access-accounts.jsffページでは、タスク・フローdetails-information-tfが、次に示す式言語(EL)構文に従う式を使用して、エンド・ユーザーに対して選択的にレンダリングされます。

rendered="#{oimappinstanceAuth.view[bindings.appInstanceKey].allowed}"

説明:

- oimappinstanceAuthは、adfc-config.xmlファイルでの、ApplicationInstanceAuthz.java認可Beanのマップ名です。

- viewは、チェックされるUIPermissionの名前です。ApplicationInstanceAuthz.java (oimappinstanceAuthの参照用の実際のBeanファイル)で定義されている権限は次のとおりです。

private UIPermission view = new UIPermission(PolicyConstants.Resources.APPLICATION_INSTANCE.getId(), PolicyConstants.ApplicationInstanceActions.VIEW_SEARCH.getId());

- appInstanceKeyは、ユーザーが表示しようとしているアプリケーション・インスタンスのIDで、これはパラメータとして渡されます。

3.5.2 定義済のアクション

リクエストの作成、変更、無効化、有効化、失効、削除、取消しなどのアクションを、ユーザーの権限に基づいてそのユーザーに対して非表示にするか、無効化するかを決定します。たとえば、「作成」ボタンは、ユーザーを作成する権限を持つユーザーのみに表示されます。

PolicyConstantsに基づいてUserAuthz.javaで定義されている権限を次に示します。

private UIPermission create = new UIPermission (PolicyConstants.Resources.USER.getId(), PolicyConstants.UserActions.CREATE.getId());

MainUIプロジェクトのadfc-config.xmlでのUserAuthz.javaのマッピング・エントリは、次のとおりです。

<managed-bean id="__30">
<managed-bean-name id="__36">oimuserAuth</managed-bean-name>
<managed-bean-class id="__29">oracle.iam.ui.platform.view.authz.UserAuthz</managed-bean-class>
<managed-bean-scope id="__31">session</managed-bean-scope>
</managed-bean>

これで、JSFFページで定義される権限のEL式を定義できます。search-users.jsffでは、rendered属性に次のEL式を使用します(この例では「作成」ボタンです)。

<af:commandToolbarButton rendered="#{oimuserAuth.create.allowed}"

このrendered属性で定義されているEL式は、戻されるブール値に基づいてボタンを表示または非表示にします。そうしない場合は、renderedではなくdisabled属性としてEL式を定義することによって、ボタンを読取り専用にできます。これで、「作成」ボタンは、ユーザーのロールにポリシーで定義された権限が含まれる場合にのみ表示されます。

同様に、変更、有効化、無効化などのアクションのEL式を定義することもできます、EL式を使用するもう1つの例として、パスワードのリセットをヘルプデスク管理者のみが実行可能にし、その他のユーザーに対しては非表示にするか、読取り専用にすることがあります。

3.5.3 フィールドレベル・セキュリティの実装

フィールドは、ユーザーがそのフィールドを表示する権限を持つかどうかに基づいて表示されます。表示フィールドを保護する場合は、次の例を検討してください。

userdetails.jsffページの「属性」タブの、「名」、「姓」などのユーザー属性は、次のEL式で保護されています。

rendered="#{oimuserAuth.viewSearch.attributes[bindings.firstName.hints.OIM_ATTRIBUTE]}"

説明:

- oimuserAuthは、adfc-config.xml内での、UserAuthz.javaのマップ名です。

- viewsearchはUIPermission名であり、保護されるフィールドのOracle Identity Manager属性名がパラメータとして渡されます。

第II部

アプリケーション・プロビジョニング

この部では、アプリケーション固有のコネクタを構成する方法について説明します。

次の章で構成されます。

- 第4章「アプリケーション・インスタンスの開発」

- 第5章「プロビジョニング・プロセスの開発」

- 第6章「プロセス・フォームの開発」

- 第7章「参照定義およびRemote Managerの管理」

4 アプリケーション・インスタンスの開発

アプリケーション・インスタンスは、プロビジョニング可能なエンティティです。これは、ITリソース・インスタンス(ターゲット接続とコネクタ構成)と、リソース・オブジェクト(プロビジョニング・メカニズム)を組み合せたものです。アプリケーション・インスタンスは、覚えやすいビジネスフレンドリな名前を持ちます。アプリケーション・インスタンスの作成および管理は、Oracle Identity System Administrationを使用して行います。

アプリケーション・インスタンスは、接続あり、または接続なしにできます。接続アプリケーション・インスタンスは、エンティティのプロビジョニング用に定義されたコネクタを持ちます。接続なしリソースのプロビジョニングには、接続なしアプリケーション・インスタンスを使用しますが、これにはコネクタが定義されていないため、プロビジョニングは管理者が手動で行います。

アプリケーション・インスタンスの概念、およびアプリケーション・インスタンスの作成および管理方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のアプリケーション・インスタンスの管理に関する説明を参照してください。

この章では、アプリケーション開発者がリソース・オブジェクトおよびITリソースを手動で管理する方法について説明します。また、接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換する手順についても説明します。

この章では、リソース、ITリソースおよびアプリケーション・インスタンスの管理について説明し、内容は次のとおりです。

- ITリソースの作成

- ITリソースの管理

- Design Consoleを使用したリソースの管理

- 接続なしアプリケーション・インスタンスの接続アプリケーション・インスタンスへの変換

4.1 ITリソースの作成

ITリソースを作成するには、次の手順を実行します。

注意:

ITリソースを作成する前に、ITリソース・タイプを作成します。ITリソース・タイプの作成は、Design Consoleを使用して行うか、またはデプロイメント・マネージャでITリソース・タイプをインポートすることで行います。

1. Oracle Identity System Administrationにログインします。

2. 「構成」で、「ITリソース」をクリックします。「ITリソースの管理」ページが表示されます。

3. 「ITリソースの作成」をクリックします。「ITリソースの作成」ウィザードが表示されます。

4. 「ステップ1: ITリソース情報の入力」ページで、次の情報を入力します。

- ITリソース名: ITリソースの名前を入力します。

- ITリソース・タイプ: ITリソースのITリソース・タイプを選択します。
Remote ManagerタイプのITリソースを作成する場合は、「ITリソース・タイプ」リストから「Remote Manager」を選択します。

- Remote Manager: 特定のRemote ManagerにITリソースを関連付けるには、このリストからRemote Managerを選択します。Remote ManagerにITリソースを関連付けない場合は、このフィールドを空欄のままにします。

注意:

「ITリソース・タイプ」リストから「Remote Manager」を選択した場合は、「Remote Manager」リストからRemote Managerは選択できません。

5. 「続行」をクリックします。

6. 「ステップ2: ITリソース・パラメータ値の指定」ページで、ITリソースのパラメータ値を指定して、「続行」をクリックします。

7. ITリソースにロールを割り当て、そのロールのアクセス権限を設定する場合は、「ステップ3: ITリソースへのアクセス権限の設定」ページで次を実行します。
a. 「ロールの割当て」をクリックします。

b. ITリソースに割り当てるロールの場合は、「割当て」および設定するアクセス権限を選択します。たとえば、ALL USERSロールを割り当て、このロールに「読取り」および「書込み」権限を設定するには、このロールについて「割当て」チェック・ボックスを選択するのみでなく、行の各チェック・ボックスを選択する必要があります。

c. 「割当て」をクリックします。

8. ITリソースに割り当てられているロールのアクセス権限を変更する場合は、「ステップ3: ITリソースへのアクセス権限の設定」ページで次を実行します。

注意:

SYSTEM ADMINISTRATORSロールのアクセス権限は変更できません。アクセス権限を変更できるのは、ITリソースに割り当てた他のロールのみです。

a. 「権限の更新」をクリックします。

b. このページに表示されるロールに対して特定のアクセス権限を設定するか削除するかに応じて、対応するチェック・ボックスを選択または選択解除します。

c. 「更新」をクリックします。

9. ITリソースからロールの割当てを解除する場合は、「ステップ3: ITリソースへのアクセス権限の設定」ページで次を実行します。

注意:

SYSTEM ADMINISTRATORSロールの割当ては解除できません。割当てを解除できるのは、ITリソースに割り当てた他のロールのみです。

a. 割当てを解除するロールの「割当て解除」チェック・ボックスを選択します。

b. 「割当て解除」をクリックします。

10. 「続行」をクリックします。

11. 「ステップ4: ITリソースの詳細の確認」ページで、1ページ目、2ページ目、3ページ目で指定した情報を確認します。ページに入力したデータを変更する場合は、「戻る」をクリックしてそのページを戻り、必要な変更を行います。

12. 「続行」をクリックして、ITリソースの作成を続行します。

13. 「ステップ5: ITリソースの接続結果」ページに、ITリソース情報を使用して実行された接続テストの結果が表示されます。テストが成功した場合は、「作成」をクリックします。テストが失敗した場合は、次のステップのいずれかを実行できます。

- 「戻る」をクリックして前のページに戻り、ITリソースの作成情報を修正します。

- 「取消」をクリックして手順を中止し、ステップ1から始めます。

- 「続行」をクリックして、作成プロセスを進めます。後で問題を修正し、診断ダッシュボードを使用して接続テストを再実行することができます。

注意:

エラーが発生しなかった場合、ボタンのラベルは「続行」ではなく「作成」となります。

詳細は、16-11ページの「基本接続性のテスト」を参照してください。

14. 「終了」をクリックします。

4.2 ITリソースの管理

ITリソースを検索するには、次の手順を実行します。

1. Oracle Identity System Administrationの「構成」で、「ITリソース」をクリックします。「ITリソースの管理」ページが表示されます。

2. 「ITリソースの管理」ページで、次のいずれかの検索オプションを使用して、表示するITリソースを検索できます。

- ITリソース名: ITリソースの名前を入力して、「検索」をクリックします。

- ITリソース・タイプ: ITリソースのITリソース・タイプを選択して、「検索」をクリックします。

- 「検索」をクリックします。

「ITリソースの管理」ページで、検索基準を満たしているITリソースのリストが表示されます。

この時点から、ITリソースに関する次のいずれかの手順を実行できます。

- ITリソースの表示

- ITリソースの変更

- ITリソースの削除

4.2.1 ITリソースの表示

ITリソースを表示するには、次の手順を実行します。

1. 検索結果に表示されているITリソースのリストから、ITリソース名をクリックします。

注意:

ITリソースを編集する場合は、同じ行の編集アイコンをクリックします。

2. ITリソース・パラメータおよびその値を表示する場合は、ページの上部にあるリストから「詳細およびパラメータ」を選択します。同様に、ITリソースに割り当てられた管理ロールを表示する場合は、リストから「管理ロール」を選択します。

4.2.2 ITリソースの変更

ITリソースを変更するには、次の手順を実行します。

1. 検索結果に表示されているITリソースのリストから、変更するITリソースの編集アイコンをクリックします。

2. ITリソースのパラメータ値を変更する場合は、次の手順を実行します。

1. ページ上部にあるリストから「詳細およびパラメータ」を選択します。

2. パラメータ値で必要な変更を加えます。

3. 変更内容を保存するには、「更新」をクリックします。

3. ITリソースに割り当てられた管理ロールを変更する場合は、最初にページ上部のリストから「管理ロール」を選択して、必要な変更を加えます。

4. 管理ロールの割当てを解除するには、ロール名が表示されている行の「割当て解除」チェック・ボックスを選択して、「割当て解除」をクリックします。

注意:

- 「割当て解除」をクリックすると、選択した管理ロールが即時にITリソースから割当て解除されます。選択した管理ロールの割当て解除を行うかどうかの確認は求められません。

- SYSTEM ADMINISTRATORSロールの割当ては解除できません。

5. ITリソースに新規の管理ロールを割り当てる場合は、次の手順を実行します。

1. 「ロールの割当て」をクリックします。

2. ITリソースに割り当てる管理ロールの場合は、アクセス権限チェック・ボックスと「割当て」チェック・ボックスを選択します。

3. 「割当て」をクリックします。

6. 現在ITリソースに割り当てられている管理ロールのアクセス権限を変更するには、次の手順を実行します。

1. 「権限の更新」をクリックします。

2. 実行する変更内容に応じて、表のチェック・ボックスを選択または選択を解除します。

注意:

SYSTEM ADMINISTRATORSロールのアクセス権限は変更できません。

3. 変更内容を保存するには、「更新」をクリックします。

4.2.3 ITリソースの削除

ITリソースを削除するには、次の手順を実行します。

1. 検索結果に表示されているITリソースのリストから、削除するITリソースの「削除」アイコンをクリックします。

2. ITリソースの削除を確認するには、「削除の確認」をクリックします。

注意:

ITリソース・インスタンスを削除すると、対応するアプリケーション・インスタンスがソフト削除されます

4.3 Design Consoleを使用したリソースの管理

この章では、Design Consoleでのリソース管理について説明します。この章には次の項目があります。

- リソース管理の概要

- 「ITリソース・タイプ定義」フォーム

- 「ルール・デザイナ」フォーム

- 「リソース・オブジェクト」フォーム

- サービス・アカウントの管理

4.3.1 リソース管理の概要

「リソース管理」フォルダには、Oracle Identity Managerリソースを管理するためのツールが用意されています。このフォルダには、次のフォームが含まれます。

- ITリソース・タイプ定義: このフォームは、「ITリソース」フォームに参照値として表示されるリソース・タイプを作成するために使用します。

- ルール・デザイナ: このフォームは、ルールを作成するために使用します。ここで作成するルールは、パスワード・ポリシーの選択、自動ロール・メンバーシップ、プロビジョニング・プロセスの選択、タスクの割当ておよびアダプタの事前移入に適用できます。

- リソース・オブジェクト: このフォームは、リソース・オブジェクトを作成および管理するために使用します。これらのオブジェクトは、ユーザーや組織に対してどのリソースを利用可能にするかを表します。

関連項目:

アダプタとアダプタ・タスクの詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

4.3.2 「ITリソース・タイプ定義」フォーム

「ITリソース・タイプ定義」フォームは「リソース管理」フォルダにあります。「ITリソース・タイプ定義」フォームを使用すると、AD、Microsoft Exchange、SolarisなどのITリソース・タイプを分類できます。Oracle Identity Managerでは、ユーザーや組織にプロビジョニングされるリソース・オブジェクトにリソース・タイプが関連付けられます。

このフォームでITリソース・タイプを定義すると、ITリソースを定義するときにそのリソース・タイプを選択できるようになります。タイプは、拡張管理の「ITリソースの作成」および「ITリソースの管理」ページに表示されます。

ITリソース・タイプとは、それらを参照するITリソース定義用のテンプレートのことです。ITリソース定義でITリソース・タイプを参照すると、そのリソースはITリソース・タイプのすべてのパラメータと値を継承します。ITリソース・タイプは、Solarisなどの全般的なIT分類です。リソースは、Solaris for Statewide Investmentsなどのタイプのインスタンスです。すべてのITリソース定義にITリソース・タイプを関連付ける必要があります。

図4-1に、「ITリソース・タイプ定義」フォームを示します。

図4-1 「ITリソース・タイプ定義」フォーム

表4-1に、「ITリソース・タイプ定義」フォームのフィールドを示します。

表4-1 「ITリソース・タイプ定義」フォームのフィールド

フィールド名

説明

サーバー・タイプ

ITリソース・タイプの名前。

複数挿入

このITリソース・タイプを複数のITリソースで参照できるようにするかどうかを指定します。

注意:

ITリソースが外部リソースにアクセスする必要があるのに、ネットワークを使用してアクセスできない場合は、Remote Managerへの関連付けが必要です。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのRemote Managerのインストールおよび構成に関する説明を参照してください。

4.3.2.1 ITリソース用のテンプレート(リソース・タイプ)の定義

ITリソース・タイプを定義するには、次の手順を実行します。

1. サーバー・タイプ・フィールドに、SolarisなどのITリソース・タイプの名前を入力します。

2. ITリソース・タイプを複数のITリソースに対して有効にするには、「複数挿入」を選択します。

3. 「保存」をクリックします。
ITリソース・タイプが定義されます。これは、拡張管理の「ITリソースの作成」ページでITリソースを定義するときに選択できます。

4.3.2.2 「ITリソース・タイプ定義」フォームのタブ

新しいITリソース・タイプに関する基本情報を保存した後、問合せでITリソース・タイプが返されると、「ITリソース・タイプ定義」フォームの下部リージョンのタブにあるフィールドが有効化されます。

「ITリソース・タイプ定義」フォームには、次のタブがあります。

- ITリソース・タイプ・パラメータ・タブ

- 「ITリソース」タブ

4.3.2.2.1 ITリソース・タイプ・パラメータ・タブ

ITリソース・タイプ・パラメータ・タブでは、図4-1に示すように、ITリソース・タイプのすべての接続パラメータのデフォルト値と暗号化設定を指定します。パスワードや暗号化されたフィールドにはデフォルト値を指定しないことをお薦めします。このタブのパラメータと値は、このITリソース・タイプを参照するすべてのITリソースによって継承されます。

新しいパラメータを定義すると、そのパラメータと値および暗号化設定が現在のITリソース・タイプに追加され、さらにこのITリソース・タイプを参照する新規または既存のITリソース定義にも追加されます。該当するリソース定義については、拡張管理の「ITリソースの作成」および「ITリソースの管理」ページの「詳細およびパラメータ」セクションに新しいパラメータが表示されます。

注意:

ITリソースごとにこれらのパラメータの値と暗号化設定をカスタマイズできます。

ITリソース・タイプへのパラメータの追加

ITリソース・タイプにパラメータを追加するには、次の手順を実行します。

1. 「追加」をクリックします。
ITリソース・タイプ・パラメータ・タブに新しい行が表示されます。

2. 「フィールド名」フィールドに、パラメータの名前を入力します。

3. デフォルトのフィールド値フィールドに、デフォルト値を入力します。
この値は、このITリソース・タイプを参照するすべてのITリソースによって継承されます。

4. 「暗号化」オプションを選択または選択解除します。
このチェック・ボックスによって、このパラメータの値がマスクされるかどうか、つまりフォーム・フィールドでアスタリスク(*)によって表されるかどうかが決まります。

パラメータの値がマスクされるようにする場合は、このチェック・ボックスを選択します。

5. 「保存」をクリックします。

ITリソース・タイプからのパラメータの削除

ITリソース・タイプからパラメータを削除するには、次の手順を実行します。

1. 削除するパラメータを選択します。

2. 「削除」をクリックします。
パラメータとそれに関連する値がITリソース・タイプから削除され、さらにこのタイプを参照するITリソース定義からも削除されます。

4.3.2.2.2 「ITリソース」タブ

このタブには、選択したITリソース・タイプを参照するITリソースが表示されます。このタブのすべてのITリソースで同じパラメータが共有されますが、値はITリソースごとに一意にすることができます。

4.3.2.3 ITリソース・タイプ定義表

ITリソース・タイプ定義表には、次の情報が表示されます。

フィールド名

説明

サーバー・タイプ

「ITリソース・タイプ定義」フォームで定義されたリソース・アセット・タイプの名前。

複数挿入

このITリソース定義の複数のインスタンスを作成できるかどうかを示します。

4.3.3 「ルール・デザイナ」フォーム

ルールとは、条件との照合およびそれに基づいたアクションの実行にOracle Identity Managerで使用される基準のことです。ルールは、特定のリソース・オブジェクトまたはプロセスに割り当てることも、すべてのリソース・オブジェクトまたはプロセスに適用することもできます。

次に、ルールの使用例を示します。

- アプリケーション・タイプのリソース・オブジェクトに適用するパスワード・ポリシーを決定します。

- ユーザーがロールに自動的に追加されるようにします。

- リソース・オブジェクトがリクエストに割り当てられた後、そのリソース・オブジェクトに適用するプロビジョニング・プロセスを指定します。

- プロセス・タスクをユーザーに割り当てる方法を決定します。

- 特定のフォーム・フィールドに対して実行される事前移入アダプタを指定します。

関連項目:

事前移入アダプタの詳細は、Oracle Identity Manager Toolsリファレンスを参照してください。

図4-2に示す「ルール・デザイナ」フォームは「リソース管理」フォルダにあります。このフォームでは、リソースで使用されるルールを作成および管理します。

図4-2 「ルール・デザイナ」フォーム

ルールには、次の4つのタイプがあります。

一般: Oracle Identity Managerでユーザーがロールに自動的に追加されたり、リソース・オブジェクトに割り当てられるパスワード・ポリシーが決定されるようにします。

プロセス決定: リソース・オブジェクト用のプロビジョニング・プロセスを決定します。

タスクの割当て: プロセス・タスクに割り当てられるユーザーまたはロールを指定します。

事前移入: フォーム・フィールドに対して実行される事前移入アダプタを決定します。

ルールには、次の項目が含まれます。

ルール要素: 属性、演算子および値で構成されます。図4-2では、属性は「ユーザー・ログイン」、演算子は==、値はXELSYSADMです。

ネスト・ルール: あるルールを論理的に別のルール内に配置する必要がある場合、内側のルールはネスト・ルールと呼ばれます。図4-2では、「Rule to Prevent Solaris Access」が「Rule for Solaris」内にネストされています。

演算: ルールに複数のルール要素やネスト・ルールが含まれている場合、演算によって構成要素間のリレーションシップが示されます。図4-2では、AND演算を選択した場合、「ユーザー・ログイン==XELSYSADM」ルール要素と「Rule to Prevent Solaris Access」ネスト・ルールの両方がtrueでないと、ルールは成功とみなされません。

表4-2に、「ルール・デザイナ」フォームのフィールドを示します。

表4-2 「ルール・デザイナ」フォームのフィールド

フィールド名

説明

名前

ルールの名前。

AND/OR

これらのオプションでは、ルールの演算を指定します。

外側のルール要素およびネスト・ルールがすべてtrueの場合にのみ、ルールを成功とみなすには、「AND」を選択します。外側のルール要素またはネスト・ルールのいずれかがtrueの場合に、ルールを成功とみなすには、「OR」を選択します。

重要: これらのオプションは、ネスト・ルールの内側にあるルール要素の演算には反映されません。図4-2では、「AND」演算は「ユーザー・ログイン == XELSYSADM」ルール要素と「Rule to Prevent Solaris Access」ネスト・ルールに適用されます。ただし、この演算は、「Rule to Prevent Solaris Access」ルールの内側にある「オブジェクト名 != Solaris」ルール要素には影響しません。

タイプ

ルールの分類ステータス。ルールは次の4つのタイプのいずれかに属することができます。

- 一般: Oracle Identity Managerでユーザーがロールに自動的に追加されたり、リソース・オブジェクトに割り当てられるパスワード・ポリシーが決定されるようにします。

- プロセス決定: リソース・オブジェクト用のプロビジョニング・プロセスを決定します。

- タスクの割当て: プロセス・タスクに割り当てられるユーザーまたはロールを決定します。

- 事前移入: フォーム・フィールドに使用される事前移入アダプタを決定します。

サブタイプ

「プロセス決定」、「タスクの割当て」または「事前移入」タイプのルールは、次の4つのサブタイプのいずれかに分類できます。

- 組織プロビジョニング: ルールをプロビジョニング・ルールとして分類します。プロセスのプロビジョニング、タスクの割当てまたは事前移入アダプタの適用の対象となる組織を決定します。

- ユーザー・プロビジョニング: ルールをプロビジョニング・ルールとして分類します。プロセスのプロビジョニング、タスクの割当てまたは事前移入アダプタの適用の対象となるユーザーを決定します。

「タスクの割当て」または「事前移入」ルール・タイプの場合、承認項目および標準承認項目はサブタイプ・ボックスに表示されません。「一般」ルール・タイプの場合、サブタイプ・ボックスはグレー表示になります。

オブジェクト

このルールが割り当てられるリソース・オブジェクト。

すべてのオブジェクト

選択した場合、ルールはすべてのリソース・オブジェクトに割り当てることができます。

プロセス

このルールが割り当てられるプロセス。

すべてのプロセス

選択した場合、ルールはすべてのプロセスに割り当てることができます。

説明

ルールに関する説明。

4.3.3.1 ルールの作成

ルールを作成する手順は、次のとおりです。

注意:

次の手順では、ネスト・ルールの内側にあるルール要素にはオプションは適用されません。たとえば、図4-2では、「AND」演算は「ユーザー・ログイン == XELSYSADM」ルール要素と「Rule to Prevent Solaris Access」ネスト・ルールに適用されます。ただし、この演算は、「Rule to Prevent Solaris Access」ルールの内側にある「オブジェクト名 != Solaris」ルール要素には影響しません。

1. 「ルール・デザイナ」フォームを開きます。

2. 「名前」フィールドに、ルールの名前を入力します。

3. ルール要素またはネスト・ルールがすべてtrueの場合にのみ、ルールを成功とみなすには、「AND」オプションを選択します。
ルール要素またはネスト・ルールのいずれかがtrueの場合に、ルールを成功とみなすには、「OR」オプションを選択します。

4. 「タイプ」ボックスをクリックし、カスタム・メニューでルールに関連付ける分類ステータス(「一般」、「プロセス決定」、「タスクの割当て」または「事前移入」)を選択します。
「プロセス決定」の場合、「サブタイプ」をクリックし、ルールに関連付ける分類ステータス(「組織プロビジョニング」、「ユーザー・プロビジョニング」、「承認」または「標準承認」)を選択します。

「タスクの割当て」または「事前移入」の場合、「サブタイプ」をクリックし、ルールに関連付ける分類ステータス(「組織プロビジョニング」または「ユーザー・プロビジョニング」)を選択します。

「タイプ」ボックスから「一般」を選択した場合、手順7に進みます。

5. ルールを1つのリソース・オブジェクトに関連付けるには、「オブジェクト」参照フィールドをダブルクリックし、「参照」ダイアログ・ボックスでリソース・オブジェクトを選択します。

ルールをすべてのリソース・オブジェクトに対して有効にする場合は、すべてのオブジェクト・オプションを選択します。

6. ルールを1つのプロセスに割り当てるには、「プロセス」参照フィールドをダブルクリックし、「参照」ダイアログ・ボックスでルールに関連付けるプロセスを選択します。

注意:

この「参照」ウィンドウには、手順5で選択したリソース・オブジェクトに関連付けられているプロセスのみが表示されます。

ルールをすべてのプロセスに対して有効にする場合は、すべてのプロセス・オプションを選択します。

注意:

手順5でリソース・オブジェクトを選択するときにすべてのプロセス・オプションを選択した場合、選択したリソース・オブジェクトに関連付けられているすべてのプロセスに対してルールが有効になります。

7. 「説明」フィールドに、ルールに関する説明を入力します。

8. 「保存」をクリックします。

4.3.3.2 「ルール・デザイナ」フォームのタブ

「ルール・デザイナ」フォームには、次のタブがあります。

- ルール要素タブ

- 使用方法タブ

これらのタブについては、次の各項でそれぞれ説明します。

4.3.3.2.1 ルール要素タブ

このタブでは、ルールの要素やネスト・ルールを作成および管理できます。たとえば、図4-3の「Rule for Solaris」には、「ユーザー・ログイン==XELSYSADM」ルール要素が含まれています。また、「Rule to Prevent Solaris Access」がネストされています。図4-3に、「ルール・デザイナ」フォームのルール要素タブを示します。

図4-3 「ルール・デザイナ」フォームのルール要素タブ

図4-3のルールは、Solarisリソース・オブジェクトのプロビジョニング・プロセスに適用できます。このリソース・オブジェクトがリクエストに割り当てられると、ルールがトリガーされます。ターゲット・ユーザーのログインがXELSYSADMであり、リソース・オブジェクトの名前がSolarisである場合、Solarisリソース・オブジェクトがユーザーにプロビジョニングされます。それ以外の場合、ユーザーはSolarisにアクセスできません。

ルール要素またはネスト・ルールが無効になったら、ルールから削除してください。

以降の各手順では、次の方法について説明します。

- ルールへのルール要素の追加

- ルールへのネスト・ルールの追加

- ルールからのルール要素またはネスト・ルールの削除

ルールへのルール要素の追加

ルールにルール要素を追加するには、次の手順を実行します。

1. 「要素の追加」をクリックします。
ルール要素の編集ダイアログ・ボックスが表示されます。

ルール要素の編集ダイアログ・ボックスにある各ボックスのカスタム・メニューには、「ルール・デザイナ」フォームの「タイプ」およびサブタイプ・ボックスの項目が反映されます。

表4-3に、ルール要素の編集ダイアログ・ボックスのデータ・フィールドを示します。

表4-3 ルール要素の編集ダイアログ・ボックスのフィールド

名前

説明

属性ソース

このボックスでは、属性のソースを選択します。たとえば、属性として「オブジェクト名」を選択する場合は、属性ソースとして「オブジェクト情報」を選択します。

ユーザー定義フォーム

このフィールドには、隣接するボックスに表示される属性ソースに関連付けられているユーザー作成フォームが表示されます。

注意: 属性ソース・ボックスに「プロセス・データ」が表示されない場合、ユーザー定義フォーム・フィールドは空になります。

属性

このボックスでは、ルールの属性を選択します。

操作

このボックスでは、属性と属性値のリレーションシップ(==または!=)を選択します。

属性値

このフィールドには、属性の値を入力します。

注意: 属性の値では大/小文字が区別されます。

2. 図4-4に示すように、作成するルールのパラメータを設定します。

図4-4 ルール要素の編集ウィンドウ

この例では、ターゲット・ユーザーのログインIDがXELSYSADMの場合に、ルール要素はtrueになります。それ以外の場合はfalseです。

関連項目:

パラメータの詳細は、「ルール要素タブ」を参照してください。

3. ルール要素の編集ダイアログ・ボックスのツールバーで、「保存」をクリックしてから、「閉じる」をクリックします。
ルール要素が「ルール・デザイナ」フォームのルール要素タブに表示されます。

4. メイン画面のツールバーで、「保存」をクリックします。
ルール要素がルールに追加されます。

ルールへのネスト・ルールの追加

ルールの中にルールをネストするには、次の手順を実行します。

注意:

次の手順では、親ルールと同じタイプおよびサブタイプのルールのみがルールの選択ウィンドウに表示されます。

1. 「ルールの追加」をクリックします。
ルールの選択ダイアログ・ボックスが表示されます。

2. ネスト・ルールを選択し、「保存」をクリックします。

3. 「閉じる」をクリックします。
ネスト・ルールが「ルール・デザイナ」フォームのルール要素タブに表示されます。

4. メイン画面のツールバーで、「保存」をクリックします。
ネスト・ルールがルールに追加されます。

ルールからのルール要素またはネスト・ルールの削除

ルール要素またはネスト・ルールを削除するには、次の手順を実行します。

1. 削除対象のルール要素またはネスト・ルールを選択します。

2. 「削除」をクリックします。
ルール要素またはネスト・ルールがルールから削除されます。

4.3.3.2.2 使用方法タブ

このタブは「ルール・デザイナ」フォームに表示されます。使用方法タブの情報には、ルールの分類タイプが反映されます。たとえば、ルール・タイプが事前移入の場合は、このルールが適用されるユーザー作成フィールドがこのタブに表示されます。

図4-5に、使用方法タブを示します。

図4-5 「ルール・デザイナ」フォームの使用方法タブ

このタブには、次の項目が表示されます。

- ルールに関連付けられているパスワード・ポリシー、リソース・オブジェクト、プロセス、プロセス・タスク、自動ロール・メンバーシップ基準、ロール、Oracle Identity Managerフォーム・フィールドおよび事前移入アダプタ。

- ルールの分類タイプを表す1文字のコード(P=プロビジョニング)。
このコードは、プロセス決定ルールの場合にのみ表示されます。

- ルールの優先度値。

4.3.3.3 ルール・デザイナ表

図4-6に示すルール・デザイナ表には、「ルール・デザイナ」フォームで定義された使用可能なすべてのルールが表示されます。

図4-6 ルール・デザイナ表

表4-4に、ルール・デザイナ表に表示される情報を示します。

表4-4 ルール・デザイナ表の情報

フィールド名

説明

ルール名

ルールの名前。

ルール・タイプ

ルールは次の4つのタイプのいずれかに属することができます。

- 一般: Oracle Identity Managerでユーザーがロールに自動的に追加されたり、リソース・オブジェクトに割り当てられるパスワード・ポリシーが決定されるようにします。

- プロセス決定: リソース・オブジェクト用のプロビジョニング・プロセスを決定します。

- タスクの割当て: プロセス・タスクに割り当てられるユーザーまたはロール(あるいはその両方)を決定します。

- 事前移入: 特定のフォーム・フィールドに対して実行される事前移入アダプタを決定します。

ルール・サブタイプ

「プロセス決定」、「タスクの割当て」または「事前移入」タイプのルールは、次の4つのサブタイプのいずれかに分類できます。

- 組織プロビジョニング: ルールをプロビジョニング・ルールとして分類します。
このサブタイプを使用して、プロセスのプロビジョニング、タスクの割当てまたは事前移入アダプタの適用の対象となる組織を決定します。

- ユーザー・プロビジョニング: ルールをプロビジョニング・ルールとして分類します。
このサブタイプを使用して、プロセスのプロビジョニング、タスクの割当てまたは事前移入アダプタの適用の対象となるユーザーを決定します。

ルールの演算子

属性と属性値のリレーションシップは、==または!=演算子で表されます。

説明

ルールに関する説明。

最終更新

ルールが最後に更新された日付。

4.3.4 「リソース・オブジェクト」フォーム

「リソース・オブジェクト」フォームは、「リソース管理」フォルダ内にあります。このフォームでは、組織またはユーザーに対してプロビジョニングするOracle Identity Managerリソースのリソース・オブジェクトを作成および管理します。リソース・オブジェクト定義とは、リソースをプロビジョニングするためのテンプレートのことです。ただし、リソースのプロビジョニングは、リソース・オブジェクトにリンクするプロビジョニング・プロセスの設計によって異なります。

表4-5に、「リソース・オブジェクト」フォームのデータ・フィールドを示します。

表4-5 「リソース・オブジェクト」フォームのフィールド

フィールド名

説明

表名

このリソースに関連付けられているリソース・オブジェクト・フォームの名前。(実際には、フォームを表す表の名前です。)

ユーザー用リクエスト/組織用リクエスト

ユーザー用または組織用にリソース・オブジェクトをリクエストするかどうかを決定するオプション。

ユーザー用にリソース・オブジェクトをリクエストするには、「ユーザー用リクエスト」を選択します。組織用にリソース・オブジェクトをリクエストするには、「組織用リクエスト」を選択します。

タイプ

リソース・オブジェクトの分類ステータス。リソース・オブジェクトは、次のタイプのいずれかに属することができます。

- アプリケーション: このリソース・オブジェクトはアプリケーションとして分類されます。

- 一般: ビジネス関連のプロセスが含まれています。

- システム: このタイプのリソース・オブジェクトは、Oracle Identity Managerで内部的に使用されます。
システム・リソース・オブジェクトを変更する場合は、事前にOracleに相談してください。

- 切断: リソース・オブジェクトを接続なしリソースとして分類します。

リコンシリエーション順序

このチェック・ボックスを選択した場合、リコンシリエーション・イベントは作成順に処理されます。

次に、この機能の使用例を示します。

ユーザーJohn DoeのOIMユーザー・リソース・オブジェクトに対するリコンシリエーション・イベントが2つあると仮定します。1つ目のリコンシリエーション・イベント(E1)のデータは次のとおりです。

- ログイン: testuser1

- 名: John

- 姓: Doe

- 組織: Xellerateユーザー

- タイプ: エンドユーザー

- ロール: フルタイム

2つ目のリコンシリエーション・イベント(E2)のデータは次のとおりです。

- ログイン: testuser1

- 名: John1

- 姓: Doe1

- 組織: Xellerateユーザー

- タイプ: エンドユーザー

- ロール: フルタイム

1つ目と2つ目のイベント間で、ユーザーの名と姓が変更されています。

信頼できるソースのリコンシリエーション実行時に、イベントが作成順に処理される場合は、名と姓の変更はOracle Identity Managerに正しくリコンサイルされます。ただし、2つ目のイベントが1つ目のイベントの前に処理される場合は、リコンシリエーション実行の終了時にターゲット・システムのデータとOracle Identity Managerのデータが一致しなくなります。この不整合は監査表に反映され、信頼できるソースからの別のイベントがこのユーザーに対して作成されるまで残ります。

リコンシリエーション順序オプションを有効にした場合、同じエンティティ(たとえば、同じユーザーまたは同じプロセス・フォーム)のイベントが作成順に処理されるようにすることができます。

信頼できるソース

信頼できるユーザー・リコンシリエーションにリソース・オブジェクトを使用する場合は、このチェック・ボックスを選択します。

デフォルトでは、このチェック・ボックスは選択されていません。デフォルトでは、Xellerateユーザー・リソース・オブジェクトの場合にのみ選択されています。

4.3.4.1 リソース・オブジェクトの作成

リソース・オブジェクトを作成するには、次の手順を実行します。

1. 「リソース・オブジェクト」フォームを開きます。

2. 「名前」フィールドに、リソース・オブジェクトの名前を入力します。

3. ユーザー用にリソース・オブジェクトをリクエストするには、「ユーザー用リクエスト」を選択します。
組織用にリソース・オブジェクトをリクエストするには、「組織用リクエスト」を選択します。

注意:

リソース・オブジェクトは、1人のユーザーまたは1つの組織を対象としてリクエストできます。

4. 「タイプ」参照フィールドをダブルクリックします。
「参照」ダイアログ・ボックスが表示されたら、リソース・オブジェクトに関連付ける分類ステータス(「アプリケーション」、「一般」または「システム」)を選択します。

5. 信頼できるソースのユーザー・リコンシリエーションにリソース・オブジェクトを使用する場合は、信頼できるソース・オプションを選択する必要があります。それ以外の場合は、手順6に進みます。

6. 「保存」をクリックします。

リソース・オブジェクトが作成されます。

4.3.4.2 「リソース・オブジェクト」フォームのタブ

「リソース・オブジェクト」フォームを開始し、リソース・オブジェクトを作成すると、このフォームの各タブが使用可能になります。

「リソース・オブジェクト」フォームには、次のタブがあります。

- 「依存先」タブ

- オブジェクト認可者タブ

- 「プロセス決定ルール」タブ

- イベント・ハンドラ/アダプタ・タブ

- 「リソース監査目的」

- ステータス定義タブ

- 「管理者」タブ

- パスワード・ポリシー・ルール・タブ

- ユーザー定義フィールド・タブ

- 「プロセス」タブ

- オブジェクト・リコンシリエーション・タブ

4.3.4.2.1 「依存先」タブ

このタブでは、Oracle Identity Managerで現在のリソース・オブジェクトをプロビジョニングする前にプロビジョニングする必要があるリソース・オブジェクトを選択できます。「依存先」タブに表示されるリソース・オブジェクトを事前にプロビジョニングしなくても、現在のリソース・オブジェクトをプロビジョニングできる場合は、タブからそのリソース・オブジェクトを削除してください。

「依存先」タブには、次のトピックが関係します。

- 現在のリソース・オブジェクトの依存先リソース・オブジェクトの選択

- 依存先リソース・オブジェクトの削除

依存先リソース・オブジェクトの選択

依存先リソース・オブジェクトを選択するには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. リソース・オブジェクトを選択します。

3. 「OK」をクリックします。
依存先リソース・オブジェクトが選択されます。

依存先リソース・オブジェクトの削除

依存先リソース・オブジェクトを削除するには、次の手順を実行します。

1. 削除対象の依存先リソース・オブジェクトを選択します。

2. 「削除」をクリックします。
リソース・オブジェクトが「依存先」タブから削除されます。

4.3.4.2.2 オブジェクト認可者タブ

このタブでは、このリソースのオブジェクト認可者となるロールを指定できます。オブジェクト認可者ロールのメンバーであるユーザーをタスクの割当て対象として選択できます。

オブジェクト認可者タブに表示されるロールには、それぞれ優先度値が割り当てられます。優先度値は、ロールに割り当てられたタスクをアクションの欠如を理由としてエスカレートする場合にも参照できます。このタブに表示されるどのロールについても、優先度値を上げたり下げたりすることができます。

たとえば、SYSTEM ADMINISTRATORSロールのメンバーをオブジェクト認可者にするように構成するものとします。また、このリソース・オブジェクトに関連付けられているプロセス・タスクにタスク割当てルールがアタッチされているものとします。このプロセス・タスクを実行する権限を与えられた最初のユーザーには、優先度値1が割り当てられます。ユーザーがユーザー指定の時間以内にプロセス・タスクを完了しなかった場合は、Oracle Identity Managerによって、SYSTEM ADMINISTRATORSロールのユーザーのうち、次に優先度が高いユーザーにタスクが再割当てされます。

関連項目:

タスク割当てルールおよびプロセス・タスクの詳細は、「「ルール・デザイナ」フォーム」および「タスクの編集ウィンドウの「割当て」タブ」を参照してください。

リソース・オブジェクトへのロールの割当て

リソース・オブジェクトにロールを割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. ロールを選択します。

3. 「OK」をクリックします。
ロールが選択されます。

リソース・オブジェクトからのロールの削除

リソース・オブジェクトからロールを削除するには、次の手順を実行します。

1. 目的のロールを選択します。

2. 「削除」をクリックします。
ロールがオブジェクト認可者タブから削除されます。

4.3.4.2.3 「プロセス決定ルール」タブ

リソース・オブジェクトとは、ユーザーまたは組織にプロビジョニングされるリソースのテンプレートのことです。このテンプレートは、複数のプロビジョニング・プロセスにリンクできます。Oracle Identity Managerでは、リソースがリクエストされるか、または直接プロビジョニングされたときに、プロセス決定ルールに基づいてプロビジョニング・プロセスが選択されます。

プロセス決定ルールの基準は次のとおりです。

- リソースがリクエストされたときに、どのプロビジョニング・プロセスを選択するか

- リソースが直接プロビジョニングされたときに、どのプロビジョニング・プロセスを選択するか

プロビジョニング・プロセスごとにプロセス決定ルールがあります。ルールとプロセスの各組合せには、Oracle Identity Managerでの評価順を示す優先度値が割り当てられます。

ルールの条件がfalseの場合、Oracle Identity Managerでは次に優先度が高いルールが評価されます。ルールがtrueの場合、そのルールに関連付けられているプロセスが実行されます。

リソース・オブジェクトへのプロセス決定ルールの追加

リソース・オブジェクトにプロセス決定ルールを追加するには、次の手順を実行します。

1. 作成するルールとプロセスの組合せに応じて、プロビジョニング・プロセス・リージョンで「追加」をクリックします。

2. 行が表示されたら、「ルール」参照フィールドをダブルクリックします。

3. 「参照」ダイアログ・ボックスで、ルールを選択し、それをリソース・オブジェクトに割り当てます(選択できるのは、プロセス決定タイプのルールのみです)。

4. 「OK」をクリックします。

5. 隣の列で、プロセス参照フィールドをダブルクリックします。

6. 「参照」ダイアログ・ボックスで、プロセスを選択し、それをルールに割り当てます。

7. 「OK」をクリックします。

8. 「優先度」フィールドに数値を入力します。
これにより、Oracle Identity Managerでルールとプロセスの組合せが評価される順序が決まります。

9. 「保存」をクリックします。
ルールとプロセスの組合せがリソース・オブジェクトに追加されます。

リソース・オブジェクトからのプロセス決定ルールの削除

リソース・オブジェクトからプロセス決定ルールを削除するには、次の手順を実行します。

1. ルールとプロセスの組合せを選択します。

2. 「削除」をクリックします。
ルールとプロセスの組合せがリソース・オブジェクトから削除されます。

4.3.4.2.4 イベント・ハンドラ/アダプタ・タブ

リソース・オブジェクトのプロビジョニング・プロセスには、自動的に実行する必要があるタスクが含まれています。その場合、イベント・ハンドラまたはアダプタをリソース・オブジェクトに割り当てる必要があります。イベント・ハンドラとは、この特殊な情報を処理するためのソフトウェア・ルーチンのことです。アダプタとは、特殊なタイプのイベント・ハンドラのことで、Oracle Identity Managerと外部リソースとの通信および対話を可能にするJavaコードを生成します。

リソース・オブジェクトに割り当てられているイベント・ハンドラまたはアダプタが無効になったら、リソース・オブジェクトから削除してください。

この例では、adpAUTOMATEPROVISIONINGPROCESSアダプタがSolarisリソース・オブジェクトに割り当てられています。このリソース・オブジェクトがリクエストに割り当てられると、Oracle Identity Managerによってアダプタがトリガーされ、関連付けられているプロビジョニング・プロセスが自動的に実行されます。

リソース・オブジェクトへのイベント・ハンドラまたはアダプタの割当て

リソース・オブジェクトにイベント・ハンドラまたはアダプタを割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. イベント・ハンドラを選択し、それをリソース・オブジェクトに割り当てます。

3. 「OK」をクリックします。
イベント・ハンドラがリソース・オブジェクトに割り当てられます。

リソース・オブジェクトからのイベント・ハンドラまたはアダプタの削除

リソース・オブジェクトからイベント・ハンドラまたはアダプタを削除するには、次の手順を実行します。

1. イベント・ハンドラを選択します。

2. 「削除」をクリックします。
イベント・ハンドラがリソース・オブジェクトから削除されます。

4.3.4.2.5 「リソース監査目的」

Design Consoleの「リソース・オブジェクト」フォームには、「リソース監査目的」という名前のリソース属性が含まれています。このリソース属性は、リソースを規制命令にリンクするのに役立ちます。

図4-7 「リソース・オブジェクト」フォーム

「リソース監査目的」リソース属性の値には参照が定義されます。「リソース監査目的」リストには、次の値が事前に定義されています。

- SOX (財務的に重要な情報が対象)

- HIPAA (個人の医療情報が対象)

- GLB (公共のものではない情報が対象)

- 毎四半期のレビューが必要

- 毎年のレビューが必要

このリストは、Design Consoleの「参照定義」フォームを使用してLookups.Resource Audit Objective.Type参照を編集すると拡張できます。

4.3.4.2.6 ステータス定義タブ

このタブでは、リソース・オブジェクトに対してプロビジョニング・ステータスを設定できます。プロビジョニング・ステータスは、リソース・オブジェクトのライフサイクル(ターゲットのユーザーや組織にプロビジョニングされるまで)におけるステータスを示します。

リソース・オブジェクトのすべてのプロビジョニング・ステータスが関連プロビジョニング・プロセスのタスク・ステータスに関連付けられます。Oracle Identity Managerでは、リソース・オブジェクトがリクエストに割り当てられたときに、プロビジョニング・プロセスが選択されます。たとえば、「Provision for Developers」というプロセスが選択され、このプロセスのタスクが「完了」ステータスになった場合、対応するリソース・オブジェクト・ステータスを「プロビジョニング済」に設定できます。この方法で、リソース・オブジェクトとプロビジョニング・プロセスの関連性を迅速かつ簡単に確認できます。

リソース・オブジェクトのステータスとして、次のステータスが事前に定義されています。

- 待機中: このリソース・オブジェクトは、まだプロビジョニングされていない他のリソース・オブジェクトに依存します。

- 失効: このリソース・オブジェクトによって表されるリソースは、リソースの使用から恒久的にプロビジョニング解除されているユーザーまたは組織をターゲットとしてプロビジョニングされます。

- 準備完了: このリソース・オブジェクトは、他のどのリソース・オブジェクトにも依存しません。または、このリソース・オブジェクトが依存するすべてのリソース・オブジェクトがプロビジョニングされます。
リソースがリクエストに割り当てられ、リソース・オブジェクトのステータスが「準備完了」になると、Oracle Identity Managerでプロセス決定ルールが評価され、プロビジョニング・プロセスが決定されます。この際、リソース・オブジェクトのステータスが「プロビジョニング」に変更されます。

- プロビジョニング: このリソース・オブジェクトはリクエストに割り当てられ、プロビジョニング・プロセスが選択されています。

- プロビジョニング済: このリソース・オブジェクトによって表されるリソースは、ターゲットのユーザーまたは組織にプロビジョニングされています。

- 情報の指定: このリソース・オブジェクトによって表されるリソースをターゲットのユーザーまたは組織にプロビジョニングするには、追加情報が必要です。

- なし: このステータスは、リソース・オブジェクトのプロビジョニング・ステータスを表しません。むしろ、Oracle Identity Managerで選択されたプロビジョニング・プロセスに属するタスクによって、リソース・オブジェクトのステータスが影響を受けないことを示します。

- 有効: このリソース・オブジェクトによって表されるリソースは、ターゲットのユーザーまたは組織にプロビジョニングされ、これらのユーザーまたは組織はリソースにアクセスできます。

- 無効: このリソース・オブジェクトによって表されるリソースは、ターゲットのユーザーまたは組織にプロビジョニングされますが、これらのユーザーまたは組織はリソースに一時的にアクセスできなくなっています。

各プロビジョニング・ステータスには、それぞれ対応する依存の開始チェック・ボックスがあります。チェック・ボックスを選択した場合、親リソース・オブジェクトがそのプロビジョニング・ステータスになったときに、Oracle Identity Managerによって依存リソース・オブジェクトのプロビジョニングが続行されます。

たとえば、Exchangeリソース・オブジェクトがActive Directoryに依存しており、「プロビジョニング済」および「有効」プロビジョニング・ステータスの依存の開始チェック・ボックスが選択されているものとします。Active Directoryのプロビジョニング・ステータスが「プロビジョニング済」または「有効」に変わり、Exchangeのプロビジョニングがそれに対応する場合、Oracle Identity ManagerによってExchangeのプロビジョニング・プロセスが続行されます。

必要に応じて、リソース・オブジェクトに別のプロビジョニング・ステータスを追加して、プロビジョニング・プロセスの各種タスク・ステータスを反映することもできます。たとえば、プロビジョニング・プロセスに属するタスクのステータスが「却下」である場合、リソース・オブジェクトの対応するプロビジョニング・ステータスを「失効」に設定できます。

同様に、既存のプロビジョニング・ステータスが無効になったら、リソース・オブジェクトから削除してください。

次の各項では、リソース・オブジェクトにプロビジョニング・ステータスを追加する方法、およびリソース・オブジェクトからプロビジョニング・ステータスを削除する方法について説明します。

リソース・オブジェクトへのプロビジョニング・ステータスの追加

リソース・オブジェクトにプロビジョニング・ステータスを追加するには、次の手順を実行します。

1. 「追加」をクリックします。

2. 「ステータス」フィールドにプロビジョニング・ステータスを追加します。

3. リソース・オブジェクトのプロビジョニング・ステータスが追加したステータスになった時点で、その他の依存リソース・オブジェクトによってそれぞれ独自のプロビジョニング・プロセスが開始されるようにする場合は、依存の開始チェック・ボックスを選択します。それ以外の場合は、手順4に進みます。

4. 「保存」をクリックします。

プロビジョニング・ステータスがリソース・オブジェクトに追加されます。

リソース・オブジェクトからのプロビジョニング・ステータスの削除

次の手順では、リソース・オブジェクトからプロビジョニング・ステータスを削除する方法について説明します。

1. プロビジョニング・ステータスを選択します。

2. 「削除」をクリックします。
プロビジョニング・ステータスがリソース・オブジェクトから削除されます。

4.3.4.2.7 「管理者」タブ

このタブでは、現在のリソース・オブジェクトの表示、変更および削除を許可するロールを選択できます。

「書込み」チェック・ボックスを選択した場合、対応するロールが現在のリソース・オブジェクトを変更できるようになります。「削除」チェック・ボックスを選択した場合、対応するロールが現在のリソース・オブジェクトを削除できるようになります。

次の各項では、リソース・オブジェクトにロールを割り当てる方法、およびリソース・オブジェクトからロールを削除する方法について説明します。

リソース・オブジェクトへのロールの割当て

リソース・オブジェクトにロールを割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. ロールを選択し、それをリソース・オブジェクトに割り当てます。

3. 「OK」をクリックします。
ロールが「管理者」タブに表示されます。デフォルトでは、このロールのすべてのメンバーがアクティブ・レコードを表示できます。

4. このロールに現在のリソース・オブジェクトの変更を許可する場合は、対応する「書込み」チェック・ボックスを選択します。
それ以外の場合は、手順5に進みます。

5. このロールに現在のリソース・オブジェクトの削除を許可する場合は、対応する「削除」チェック・ボックスを選択します。

そうでない場合は、手順6に進みます。

6. 「保存」をクリックします。

ロールがリソース・オブジェクトに割り当てられます。

リソース・オブジェクトからのロールの削除

リソース・オブジェクトからロールを削除するには、次の手順を実行します。

1. 削除対象のロールを選択します。

2. 「削除」をクリックします。
ロールがリソース・オブジェクトから削除されます。

4.3.4.2.8 パスワード・ポリシー・ルール・タブ

「アプリケーション」タイプのリソース・オブジェクトをユーザーまたは組織にプロビジョニングする場合、そのユーザーまたは組織がリソース・オブジェクトにアクセスするときにパスワード基準への準拠を求めることができます。このパスワード基準は、パスワード・ポリシーのフォームで作成および管理します。これらのポリシーは、「パスワード・ポリシー」フォームを使用して作成します。

リソース・オブジェクト定義はリソースのプロビジョニング方法を制御するためのテンプレートにすぎないため、Oracle Identity Managerで実際の条件およびルールに基づいてリソースのプロビジョニング方法を決定できるようにする必要があります。これらの条件は、リソースが実際にリクエストされるまでわからない場合があります。そのため、リソースに関連付けられている様々なプロセスやパスワード・ポリシーにルールをリンクする必要があります。これにより、どのようなコンテキストにおいても、Oracle Identity Managerで何を呼び出せばよいかを判断できるようになります。

Oracle Identity Managerでは、特定ユーザーのアカウントの作成時または更新時に、どのパスワード・ポリシーをリソースに適用するかが決定されます。この際、リソースのパスワード・ポリシー・ルールが評価され、最初に合致したルールに関連付けられているポリシーの基準が適用されます。各ルールには、Oracle Identity Managerでの評価順を示す優先度値が割り当てられます。

次の各項では、リソース・オブジェクトにパスワード・ポリシー・ルールを追加する方法、およびリソース・オブジェクトからパスワード・ポリシー・ルールを削除する方法について説明します。

リソース・オブジェクトへのパスワード・ポリシー・ルールの追加

リソース・オブジェクトにパスワード・ポリシー・ルールを追加するには、次の手順を実行します。

1. 「追加」をクリックします。

2. 行が表示されたら、「ルール」参照フィールドをダブルクリックします。

3. 「参照」ダイアログ・ボックスで、ルールを選択し、それをリソース・オブジェクトに割り当てます。

4. 「OK」をクリックします。

5. 隣の列で、「ポリシー」参照フィールドをダブルクリックします。

6. 「参照」ダイアログ・ボックスで、関連付けられているパスワード・ポリシーを選択し、それをリソース・オブジェクトに割り当てます。

7. 「OK」をクリックします。

8. 「優先度」フィールドに数値を追加します。
このフィールドには、ルールの優先度値が格納されます。

9. 「保存」をクリックします。
パスワード・ポリシー・ルールがリソース・オブジェクトに追加されます。

注意:

- リソース・タイプが「組織用リクエスト」である場合、リソース・オブジェクトにパスワード・ポリシーをアタッチすることはできません。このルールの例外は、Xellerateユーザー・リソース・オブジェクトです。このリソース・オブジェクトのタイプは「組織用リクエスト」ですが、パスワード・ポリシーをアタッチできます。

- 複数のルールがTrueと評価された場合は、最も優先度が高いルールにアタッチされているパスワード・ポリシーが適用されます。

- Oracle Identity Managerでは、デフォルト・ルールが事前に定義されています。このルールは常にTrueと評価されます。「ルール・デザイナ」で作成されたルールが存在しない場合は、デフォルト・ルールにパスワード・ポリシーをアタッチできます。

リソース・オブジェクトからのパスワード・ポリシー・ルールの削除

リソース・オブジェクトからパスワード・ポリシーを削除するには、次の手順を実行します。

1. パスワード・ポリシー・ルールを選択します。

2. 「削除」をクリックします。
パスワード・ポリシー・ルールがリソース・オブジェクトから削除されます。

4.3.4.2.9 ユーザー定義フィールド・タブ

このタブでは、「リソース・オブジェクト」フォーム用に作成されたユーザー定義フィールドを表示してアクセスできます。作成したユーザー定義フィールドはこのタブに表示され、データを受け入れたり、提供するために使用できます。

4.3.4.2.10 「プロセス」タブ

「プロセス」タブには、現在のリソース・オブジェクトに関連付けられているすべてのプロビジョニング・プロセスが表示されます。このタブにある「デフォルト」チェック・ボックスは、リソースのデフォルトとして使用されるプロビジョニング・プロセスを示します。

注意:

「プロセス定義」フォームでプロビジョニング・プロセスを作成し、それらをリソースに関連付けます。「リソース・オブジェクト」フォームの「プロセス決定ルール」タブを使用して、各プロセスをプロセス決定ルールにリンクすることができます。

たとえば、Solarisリソース・オブジェクトに1つのプロビジョニング・プロセス(「Provision Solaris for Devel.」)が関連付けられているものとします。「Provision Solaris for Devel.」は、このリソース・オブジェクトのデフォルトのプロビジョニング・プロセスとして指定されています。

4.3.4.2.11 オブジェクト・リコンシリエーション・タブ

オブジェクト・リコンシリエーション・タブのオブジェクトの初期リコンシリエーション日フィールドには、リソースに対して初期リコンシリエーションが実行された日付が表示されます。

注意:

初期リコンシリエーションの目的は、ターゲット・システムのすべてのユーザー・アカウントをOracle Identity Managerに取り込むことです。

オブジェクトの初期リコンシリエーション日フィールドに格納される日付値は、初期リコンシリエーションとそれ以降のリコンシリエーション・イベントを区別するために使用されます。この日付値は、2つの例外レポートで使用されます。これらの例外レポートには、ユーザーに必要な権限とユーザーがターゲット・システムで実際に持つ権限の比較差異が表示されます。権限の差異は、リコンシリエーション・データとその他のデータ項目に基づいて判断されます。例外レポートでは、オブジェクトの初期リコンシリエーション日フィールドの日付以降に作成されたリコンシリエーション・イベントに関連付けられているデータのみが返されます。また、例外データが生成されるのは、オブジェクトの初期リコンシリエーション日フィールドの日付値が過去の日付になっている場合のみです。必要に応じて、例外レポートが生成されるように、このフィールドに日付値を入力することもできます。

オブジェクト・リコンシリエーション・タブには、「リコンシリエーション・フィールド」および「リコンシリエーション・アクション・ルール」という2つのサブタブがあります。

- 「リコンシリエーション・フィールド」タブでは、ターゲット・リソースまたは信頼できるソースにおいてOracle Identity Managerの情報とリコンサイルされる(たとえば、マップされる)フィールドを定義できます。

- リコンシリエーション・アクション・ルール・タブでは、特定の一致条件が満たされた場合にOracle Identity Managerで実行されるアクションを指定できます。

リソース・オブジェクトまたは関連するプロセス・フォームが変更された場合は常に、オブジェクト・リコンシリエーション・タブにあるリコンシリエーション・プロファイルの作成ボタンをクリックして、リコンシリエーション・プロファイルを生成してください。

「リコンシリエーション・フィールド」タブ

このタブでは、ターゲット・リソースまたは信頼できるソースにおいてOracle Identity Managerの情報とリコンサイルされる(たとえば、マップされる)フィールドを定義できます。ターゲット・システムまたは信頼できるソースのフィールドごとに、次の情報が表示されます。

- ターゲット・リソースまたは信頼できるソースにおいてOracle Identity Managerのデータとリコンサイルされるフィールドの名前(targetfield1など)

- フィールドに関連付けられているデータ型(Stringなど)。有効な値は複数値、文字列、数値、日付、ITリソース

- このフィールドがリコンシリエーション・イベントで必須かどうかを示すインジケータ

注意:

Oracle Identity Managerでは、拡張管理の「イベント管理」タブの「リコンシリエーション」セクションにあるフィールドがすべて処理されるまで、リコンシリエーション・イベントに対するプロビジョニング・プロセス、ユーザーまたは組織の照合は開始されません。

次に、リコンシリエーション・フィールド定義の例を示します。

TargetField1 [String], Required

「リコンシリエーション・フィールド」タブでは、次の操作を実行できます。

- リコンシリエーション・フィールドの追加
次の手順では、Oracle Identity Managerの情報とリコンサイルされるフィールドのリストに、ターゲット・システムまたは信頼できるソースのフィールドを追加します。

注意:

Oracle Identity Managerで外部のターゲット・リソースまたは信頼できるソースとのリコンシリエーションが正しく実行されるようにするには、このタブで定義したフィールドを事前に適切なOracle Identity Managerフィールドにマップしておく必要があります(リソースのデフォルトのプロビジョニング・プロセスのフィールド・マッピング・タブを使用)。

リコンシリエーション・フィールドを追加するには、次の手順を実行します。

1. 「フィールドの追加」をクリックします。
リコンシリエーション・フィールドの追加ダイアログ・ボックスが表示されます。

2. 「フィールド名」フィールドに、ターゲット・リソースまたは信頼できるソースのフィールドの名前を入力します。
Oracle Identity Managerでは、この名前によってターゲット・リソースまたは信頼できるソースのフィールドを参照します。

3. フィールド・タイプ・フィールドのメニューから、次の値のいずれかを選択します。

- 複数値
1つ以上のコンポーネント・フィールドで構成されるフィールド用です。

- String

- String

- 日付

- ITリソース
リコンシリエーション・イベントの作成時には、Oracle Identity Managerで定義されたITリソースの名前と同じ値がこのフィールドに割り当てられる必要があります。

4. 「必須」チェック・ボックスを選択します。
選択した場合、拡張管理の「イベント管理」タブの「リコンシリエーション」セクションにあるリコンシリエーション・フィールドが処理されるまで、Oracle Identity Managerでリコンシリエーション・イベントに対するプロビジョニング・プロセス、ユーザーまたは組織の照合は開始されません。このチェック・ボックスを選択解除した場合、リコンシリエーション・イベントでこのフィールドは処理されませんが、照合は実行されます。

5. 「保存」をクリックします。
リソースのデフォルトのプロビジョニング・プロセスでフィールドのマッピングが可能になります。

- リコンシリエーション・フィールドの削除
次の手順では、Oracle Identity Managerの情報とリコンサイルされるフィールドのリストから、ターゲット・システムのフィールドを削除します。信頼できるソースの場合は、ユーザー・リソース定義が対象となります。

リコンシリエーション・フィールドを削除するには、次の手順を実行します。

1. 削除対象のフィールドを選択します。

2. 「フィールドの削除」をクリックします。
選択したフィールドは、Oracle Identity Managerでターゲット・システムのデータとリコンサイルされるフィールドのリストから削除されます(ターゲット・システム自体のデータには影響しません)。

リコンシリエーション・アクション・ルール・タブ

このタブでは、リコンシリエーション・イベント・レコード内で一致が見つかった場合にOracle Identity Managerで実行されるアクションを指定できます。このタブの各レコードは次の項目の組合せです。

- 一致条件の基準

- 実行されるアクション

選択可能な条件とアクションは事前に定義されています。一致条件によっては、適用不可のアクションもあります。表4-6に、使用可能なオプションの完全なリストを示します。

表4-6 ルール条件と使用可能なルール・アクション

ルール条件

使用可能なルール・アクション

一致が見つからなかった場合

なし

ユーザーの作成(信頼できるソースでのみ使用可能)

1つのプロセス一致が見つかった場合

なし

リンクの確立

複数のプロセス一致が見つかった場合

なし

1つのエンティティ一致が見つかった場合

なし

リンクの確立

複数のエンティティ一致が見つかった場合

なし

関連項目:

前述の表に記載されているユーザーおよびロールの分類タイプの詳細は、「タスクの編集ウィンドウの「割当て」タブ」を参照してください。

リコンシリエーション・アクション・ルールの追加

リコンシリエーション・アクション・ルールを追加するには、次の手順を実行します。

1. 「フィールドの追加」をクリックします。
新規アクション・ルールの追加ダイアログ・ボックスが表示されます。

2. ルール条件メニューから目的の値を選択します。
この一致条件によって、関連付けられているアクションが実行されます。各一致条件に割り当てることができるルール・アクションは1つに制限されています。

3. ルール・アクション・メニューから値を選択します。
このアクションは、一致条件が満たされた場合に実行されます。

4. 「保存」をクリックし、新規アクション・ルールの追加ダイアログ・ボックスを閉じます。

リコンシリエーション・アクション・ルールの削除

リコンシリエーション・アクション・ルールを削除するには、次の手順を実行します。

1. 削除対象の一致アクションの組合せを選択します。

2. 「削除」をクリックします。
リコンシリエーション・アクション・ルールが削除され、その条件に関連付けられているアクションが自動的に実行されなくなります。

4.3.4.3 複数の信頼できるソースのリコンシリエーション

Xellerateユーザー・リソース・オブジェクトおよびXellerateユーザー・プロセス定義に対してリコンシリエーション・フィールド、リコンシリエーション・アクション・ルール、フィールド・マッピングおよび一致ロールを作成できます。

OIMユーザーの作成時に、2つの信頼できるソースからアイデンティティをリコンサイルできる場合、両方のソースに対して1つのリソース・オブジェクト(Xellerateユーザー)を構成することはできません。Xellerateユーザー・リソース・オブジェクトに信頼できる両方のソースのリコンシリエーション・フィールドを作成しても、Xellerateユーザー・プロセス定義には対応するリコンシリエーション・フィールド・マッピングを作成できません。

アイデンティティ・リコンシリエーション用の信頼できるソースとして、Xellerateユーザー以外のリソース・オブジェクトを構成できます。そのためには、リソース・オブジェクトの作成時に、「リソース・オブジェクト」フォームにある信頼できるソース・チェック・ボックスを選択します。

リソース・オブジェクトに信頼できるソース・フラグがアタッチされている場合は、ターゲット・システム・フィールドを表す複数のリコンシリエーション・フィールドを作成できます。また、プロセス一致が見つからなかった場合に、ユーザーを作成するか、アイデンティティ作成用のデータを管理者または認可者に送信するように、リコンシリエーション・アクション・ルールを構成することもできます。プロセス一致が見つかった場合は、リンクが確立されます。

信頼できるソース・リソースに対してプロビジョニング・プロセスを定義する場合は、ユーザー定義のプロセス・フォームをアタッチしないでください。これらのプロビジョニング・プロセスについては、リソースおよびOIMユーザー属性に定義されたリコンシリエーション・フィールド間にリコンシリエーション・フィールド・マッピングを作成できます。

注意:

リソース・オブジェクトがターゲット・リソース・リコンシリエーション用の場合は、リコンシリエーション・フィールドとプロセス・データ・フィールド間のマッピングになります。

プロビジョニング・アクティビティ用の信頼できるソースとして定義されたリソース・オブジェクトは使用しないでください。これらのリソースは、OIMユーザーのリコンシリエーションにのみ使用できます。

属性認可ソース機能は、ソースの信頼性がアイデンティティ自体ではなく、アイデンティティの属性に対してのみ適用されることを意味します。属性認可ソースのリコンシリエーションを構成するには、適切なリコンシリエーション・アクション・ルールを作成します。プロセス一致が見つからなかった場合は、管理者に割り当てられます。これにより、一致が見つからなかった場合でも、ユーザーが間違って作成されることはありません。プロセス一致が見つかった場合は、リコンシリエーション・アクション・ルールによってリンクが確立されます。

次の各項では、複数の信頼できるソースのリコンシリエーションを実装する場合の2つのユースケースについて説明します。

注意:

このドキュメントには、次のような箇所があります。

- 複数の信頼できるソースのリコンシリエーションはMTSと呼ばれています。

- フィールドおよび属性という用語が同義的に使用されています。

- 複数の信頼できるソースのリコンシリエーション - MTS互換コネクタを使用する場合

- 複数の信頼できるソースのリコンシリエーション - MTS非互換コネクタを使用する場合

注意:

どちらのユースケースの場合も、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの新しいリコンシリエーション・プロファイルの作成に関する説明を参照して、リコンシリエーション・プロファイルを作成してください。

4.3.4.3.1 複数の信頼できるソースのリコンシリエーション - MTS互換コネクタを使用する場合

注意:

コネクタがMTS互換かどうかを調べる方法は、コネクタ固有のドキュメントを参照してください。

次の各項では、MTS互換コネクタを使用して複数の信頼できるソースのリコンシリエーションを実装する場合のシナリオについて説明します。

- 信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合のMTS互換コネクタの構成

- 信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合のMTS互換コネクタの構成

信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合のMTS互換コネクタの構成

このコンテキストにおけるユーザー・タイプとは、リコンサイル対象のレコードを持つユーザーのタイプのことです。ユーザー・タイプの例としては、EmployeeやCustomerなどがあげられます。

信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行うには、該当する手順に従って信頼できるソースのリコンシリエーションを実装するときに、信頼できるソースとして構成する各ターゲット・システムのコネクタをデプロイします。

リコンシリエーション実行時には、指定したユーザー・タイプのすべてのターゲット・システム・レコードがリコンサイルされます。ターゲット・システムに複数のユーザー・タイプが存在する場合は、制限付きリコンシリエーション機能を使用して、各ターゲット・システムからリコンサイルする必要があるレコードを持つユーザー・タイプを指定できます。

信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合のMTS互換コネクタの構成

複数のターゲット・システムの特定のOIMユーザー属性に対して、信頼できるソースのリコンシリエーションを行うように構成することもできます。この場合の実装手順については、次のサンプル・シナリオを例にして説明します。

アイデンティティを1つのターゲット・システム(TS1など)からリコンサイルし、これらのアイデンティティの特定の属性(attr1、attr2、attr3など)を別のターゲット・システム(TS2など)からリコンサイルするものとします。つまり、TS1はアイデンティティについて信頼できるソースであり、TS2はアイデンティティ自体ではなく特定の属性について信頼できるソースです。OIMユーザーを正しく作成するためには、必須のOIMユーザー属性がTS1からすべて提供される必要があります。TS2から提供されるのは、TS2が信頼できるソースとなっているOIMユーザー属性のみです(必須かどうかは問いません)。必須のOIMユーザー属性をTS2からリコンサイルする場合は、この属性の値によって、TS1からのOIMユーザーの作成時にこの属性に格納される値が上書きされます。必須でないOIMユーザー属性のみをTS2からリコンサイルする場合は、OIMユーザーの作成時にこれらの属性をTS1からリコンサイルしないように指定できます。

注意:

信頼できるソースが複数存在する場合は、それらのソースからエンティティ属性をリコンサイルするロジックがコネクタによって提供されます。

TS1コネクタの場合:

1. TS1コネクタをデプロイするために必要なすべての手順を実行し、そのコネクタを信頼できるソースのリコンシリエーション用に構成します。

関連項目:

信頼できるソースのリコンシリエーションを構成する手順の詳細は、デプロイ対象のコネクタのドキュメントを参照してください。

2. オブジェクト・リコンシリエーション・ページの「リコンシリエーション・フィールド」タブで、TS2からリコンサイルするすべてのTS1属性(この場合、attr1、attr2およびattr3)を削除します。

3. 「プロセス定義」ページのリコンシリエーション・フィールド・マッピング・タブで、不要なマッピングをすべて削除します。
リコンシリエーション・フィールドを削除するかわりに、リコンシリエーションによって作成されたOIMユーザーに値をリコンサイルしないフィールドのリコンシリエーション・フィールド・マッピングを削除してもかまいません。

4. オブジェクト・リコンシリエーション・ページのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションに関して次のマッピングが存在することを確認します。
ルール条件: 一致が見つからなかった場合

アクション: ユーザーの作成

TS2コネクタの場合:

1. TS2コネクタをデプロイするために必要なすべての手順を実行し、そのコネクタを信頼できるソースのリコンシリエーション用に構成します。

関連項目:

信頼できるソースのリコンシリエーションを構成する手順の詳細は、デプロイ対象のコネクタのドキュメントを参照してください。

2. 「プロセス定義」ページのリコンシリエーション・フィールド・マッピング・タブで、不要なマッピングをすべて削除します。
リコンシリエーション・フィールドを削除するかわりに、リコンシリエーションによって作成されたOIMユーザーに値をリコンサイルしないフィールドのリコンシリエーション・フィールド・マッピングを削除するだけでもかまいません。

3. オブジェクト・リコンシリエーション・ページの「リコンシリエーション・フィールド」タブで、attr1、attr2およびattr3以外のTS2属性をすべて削除します。また、OIMユーザーと既存のTS2アカウントの照合に使用する属性は保持してください。つまり、リコンシリエーション・ルールの評価に使用される属性のみを保持します。たとえば、Oracle Identity Managerのusername属性を使用して、TS1のfirst name属性の値を照合できます。

4. オブジェクト・リコンシリエーション・ページのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションのマッピングを作成します。ルール条件とアクションのマッピングの1つを次のようにしてください。
ルール条件: 一致が見つからなかった場合

アクション: ユーザーの作成以外

4.3.4.3.2 複数の信頼できるソースのリコンシリエーション - MTS非互換コネクタを使用する場合

注意:

コネクタがMTS互換かどうかを調べる方法は、コネクタ固有のドキュメントを参照してください。

複数の信頼できるソースのリコンシリエーション設定でMTS非互換のコネクタを使用する場合は、次の前提条件を満たす必要があります。

i. 信頼できるソース・リソース・オブジェクトをXellerateユーザーに指定できるのは、いずれか1つに制限されています。現在の動作環境において、信頼できるソースのリコンシリエーション用にXellerateユーザー・リソース・オブジェクトがコネクタですでに使用されている状況で、信頼できるソースのコネクタを構成するには、新しいリソース・オブジェクトおよびプロセス定義を作成する必要があります。

ii. コネクタのスケジュール済タスクには、信頼できるソースのユーザー・リコンシリエーションに使用されるリソース・オブジェクトの名前を値として受け入れる属性が必要です。

次の各項では、MTS非互換コネクタを使用して複数の信頼できるソースのリコンシリエーションを実装する場合のシナリオについて説明します。

- 信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合のMTS非互換コネクタの構成

- 信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合のMTS非互換コネクタの構成

信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合のMTS非互換コネクタの構成

このコンテキストにおけるユーザー・タイプとは、リコンサイル対象のレコードを持つユーザーのタイプのことです。ユーザー・タイプの例としては、Contractor、Employee、Customerなどがあげられます。

動作環境においてMicrosoft Active DirectoryおよびOracle E-Business Suiteを信頼できるソースとして使用します。Active Directoryは、Contractorユーザー・タイプに属するアイデンティティに関する情報を格納するために使用します。Oracle E-Business Suiteは、CustomerおよびEmployeeユーザー・タイプに属するアイデンティティに関する情報を格納するために使用します。ContractorレコードをActive Directoryからリコンサイルし、EmployeeレコードをOracle E-Business Suiteからリコンサイルするものとします。そのための手順は、次のとおりです。

Active Directoryの場合:

1. Active Directoryコネクタをデプロイするために必要なすべての手順を実行し、そのコネクタを信頼できるソースのリコンシリエーション用に構成します。

関連項目:

信頼できるソースのリコンシリエーションを構成する手順の詳細は、デプロイ対象のコネクタのドキュメントを参照してください。

信頼できるソースのリコンシリエーション用にコネクタXMLファイルをインポートすると、Active Directoryに固有の情報がXellerateユーザー・リソース・オブジェクトおよびプロセス定義に追加されます。

2. 「リソース・オブジェクト」タブで、信頼できるソースのリコンシリエーションをActive Directoryによって行うためのActDirリソース・オブジェクトを作成します。

注意:

リソース・オブジェクトには任意の名前を割り当てることができます。この手順では、リソース・オブジェクトの名前としてActDirを割り当てて使用しています。

リソース・オブジェクトを作成する手順の詳細は、「「リソース・オブジェクト」フォーム」を参照してください。

リソース・オブジェクトの作成時に、次の手順を実行します。

1. 「リソース・オブジェクト」タブにある信頼できるソース・チェック・ボックスを選択します。

2. オブジェクト・リコンシリエーションの「リコンシリエーション・フィールド」タブで、Xellerateユーザー・リソース・オブジェクトを確認し、Active Directory固有のフィールドをリコンサイル対象としてActDirに追加します。このタブに追加するフィールドで、OIMユーザーに関するすべての必須フィールドを扱う必要があります。

3. オブジェクト・リコンシリエーションのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションのマッピングを作成します。ルール条件とアクションのマッピングの1つを次のようにしてください。
ルール条件: 一致が見つからなかった場合

アクション: ユーザーの作成

4. Active Directoryに固有のフィールドおよびそれに対応するルールをXellerateユーザー・リソース・オブジェクトから削除します。

5. 「プロセス定義」フォームでActDirプロセス定義を作成します。
プロセス定義を作成する手順の詳細は、「「プロセス定義」フォーム」を参照してください。リコンシリエーション・フィールド・マッピング・タブで、Xellerateユーザー・プロセス定義のリコンシリエーション・フィールド・マッピングを基準にして、ActDirプロセス定義のリコンシリエーション・フィールド・マッピングを追加します。

6. Xellerateユーザー・リソース・オブジェクトからActive Directory固有のフィールド・マッピングを削除します。

7. 「リコンシリエーション・ルール」ページのリコンシリエーション・ルール・ビルダー・フォームで、このコネクタのリコンシリエーション・ルールを問い合せて開き、「オブジェクト」フィールドの値を変更して、作成したリソース・オブジェクトにマップします。デフォルトでは、このフィールドの値はXellerateユーザー・リソース・オブジェクトのフィールドにマップされます。

Oracle E-Business Suiteについても、Active Directoryに対して実行したすべての手順を繰り返します。その手順をOracle e-Business Employee Reconciliationコネクタ用に変えて、次のように実行してください。

1. 「リソース・オブジェクト」タブで、信頼できるソースのリコンシリエーションをOracle E-Business Suiteによって行うためのEmpReconリソース・オブジェクトを作成します。

注意:

リソース・オブジェクトには名前を割り当てることができます。この手順では、リソース・オブジェクトの名前としてEmpReconを割り当てて使用しています。

2. オブジェクト・リコンシリエーションのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションのマッピングを作成します。ルール条件とアクションのマッピングの1つを次のようにしてください。
ルール条件: 一致が見つからなかった場合

アクション: ユーザーの作成

制限付きリコンシリエーション機能を使用して、Employeeユーザー・タイプに属するアイデンティティのみがリコンサイルされるように指定してください。

3. フィールドとリコンシリエーション・ルールを追加した後、Xellerateユーザー・リソース・オブジェクトに作成されたOracle E-Business Suite固有のフィールドおよびそれに対応するルールを削除します。

4. 「プロセス定義」フォームでEmpReconプロセス定義を作成します。プロセス定義を作成する手順の詳細は、「「プロセス定義」フォーム」を参照してください。リコンシリエーション・フィールド・マッピング・タブで、Xellerateユーザーのリコンシリエーション・フィールド・マッピングを基準にして、EmpReconプロセス定義のフィールド・マッピングを追加します。

5. Xellerateユーザー・リソース・オブジェクトからOracle E-Business Suite固有のフィールド・マッピングを削除します。

6. 「リコンシリエーション・ルール」>>リコンシリエーション・ルール・ビルダー・フォームで、このコネクタのリコンシリエーション・ルールを問い合せて開き、「オブジェクト」フィールドの値を変更して、作成したリソース・オブジェクトにマップします。デフォルトでは、このフィールドの値はXellerateユーザー・リソース・オブジェクトのフィールドにマップされます。

Active DirectoryとOracle E-Business Suiteのどちらについても、信頼できるソースのリコンシリエーションを構成するために必要な残りの手順を実行してください。たとえば、各コネクタに対してリコンシリエーションのスケジュール済タスクを構成するときに、信頼できるソースのユーザー・リコンシリエーション実行時に使用する必要がある信頼できるソース・リソース・オブジェクトの名前を指定します。

スケジュール済タスク属性の現在の値はXellerateユーザーですが、このコネクタでの信頼できるソースのユーザー・リコンシリエーション用に構成した新しいリソース・オブジェクトの名前に更新する必要があります。

図4-8に、信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合のデザインタイム実装を示します。

図4-8 信頼できるソースのリコンシリエーションをユーザー・タイプに基づいて行う場合

信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合のMTS非互換コネクタの構成

複数のターゲット・システムの特定のOIMユーザー属性に対して、信頼できるソースのリコンシリエーションを行うように構成することもできます。この場合の実装手順については、次のサンプル・シナリオを例にして説明します。

Microsoft Active DirectoryおよびIBM Lotus Notesをターゲット・システムとして使用します。アイデンティティをActive Directoryからリコンサイルし、(Active DirectoryからOracle Identity Managerにリコンサイルされた)各アイデンティティのe-mail address属性の値のみをLotus Notesからリコンサイルするものとします。そのために、次の手順を実行します。

Active Directoryコネクタの場合:

1. Active Directoryコネクタをデプロイするために必要なすべての手順を実行し、そのコネクタを信頼できるソースのリコンシリエーション用に構成します。

関連項目:

信頼できるソースのリコンシリエーションを構成する手順の詳細は、デプロイ対象のコネクタのドキュメントを参照してください。

信頼できるソースのリコンシリエーション用にコネクタXMLファイルをインポートすると、Active Directoryに固有の情報がXellerateユーザー・リソース・オブジェクトおよびプロセス定義に追加されます。

2. 「リソース・オブジェクト」タブで、信頼できるソースのリコンシリエーションをActive Directoryによって行うためのActDirリソース・オブジェクトを作成します。

注意:

リソース・オブジェクトには任意の名前を割り当てることができます。この手順では、リソース・オブジェクトの名前としてActDirを割り当てて使用しています。

リソース・オブジェクトを作成する手順の詳細は、「「リソース・オブジェクト」フォーム」を参照してください。

リソース・オブジェクトの作成時に、次の手順を実行します。

i. 「リソース・オブジェクト」タブにある信頼できるソース・チェック・ボックスを選択します。

ii. オブジェクト・リコンシリエーションの「リコンシリエーション・フィールド」タブで、Xellerateユーザー・リソース・オブジェクトを確認し、Active Directory固有のフィールドをリコンサイル対象としてActDirに追加します。このタブに追加するフィールドで、OIMユーザーに関するすべての必須フィールドを扱う必要があります。

3. オブジェクト・リコンシリエーションのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションのマッピングを作成します。ルール条件とアクションのマッピングの1つを次のようにしてください。
ルール条件: 一致が見つからなかった場合

アクション: ユーザーの作成

4. Active Directoryに固有のフィールドおよびそれに対応するルールをXellerateユーザー・リソース・オブジェクトから削除します。

5. 「プロセス定義」フォームでActDirプロセス定義を作成します。プロセス定義を作成する手順の詳細は、「「プロセス定義」フォーム」を参照してください。リコンシリエーション・フィールド・マッピング・タブで、Xellerateユーザー・プロセス定義のリコンシリエーション・フィールド・マッピングを基準にして、ActDirプロセス定義のフィールド・マッピングを作成します。

6. Xellerateユーザー・リソース・オブジェクトからActive Directory固有のフィールド・マッピングを削除します。

7. 「リコンシリエーション・ルール」>>リコンシリエーション・ルール・ビルダー・フォームで、このコネクタのリコンシリエーション・ルールを問い合せて開き、「オブジェクト」フィールドの値を変更して、作成したリソース・オブジェクトにマップします。デフォルトでは、このフィールドの値はXellerateユーザー・リソース・オブジェクトのフィールドにマップされます。

IBM Lotus Notesについても、Active Directoryに対して実行したすべての手順を繰り返します。その手順をLotus Notesコネクタ用に変えて、次のように実行してください。

1. 「リソース・オブジェクト」タブで、信頼できるソースのリコンシリエーションをLotus Notesによって行うためのLotNotesリソース・オブジェクトを作成します。

注意:

リソース・オブジェクトには名前を割り当てることができます。この手順では、リソース・オブジェクトの名前としてLotNotesを割り当てて使用しています。

2. リソース・オブジェクトの作成時には、e-mail address属性のみを追加します。

3. オブジェクト・リコンシリエーションのリコンシリエーション・アクション・ルール・タブで、ルール条件とアクションのマッピングを作成します。一致が見つからなかった場合のルール条件(ユーザーの作成以外)を作成します。一致が見つかった場合は、リンクが確立されます。

4. フィールドとリコンシリエーション・ルールを追加した後、Xellerateユーザー・リソース・オブジェクトに作成されたLotus Notes固有のフィールドおよびそれに対応するルールを削除します。

5. 「プロセス定義」フォームでLotNotesプロセス定義を作成します。プロセス定義を作成する手順の詳細は、「「プロセス定義」フォーム」を参照してください。リコンシリエーション・フィールド・マッピング・タブで、Xellerateユーザーのリコンシリエーション・フィールド・マッピングを基準にして、LotNotesプロセス定義のフィールド・マッピングを追加します。

6. Xellerateユーザー・リソース・オブジェクトからLotus Notes固有のフィールド・マッピングを削除します。

Active DirectoryとLotus Notesのどちらについても、信頼できるソースのリコンシリエーションを構成するために必要な残りの手順を実行してください。たとえば、各コネクタに対してリコンシリエーションのスケジュール済タスクを構成するときに、リコンシリエーション実行時に使用する必要がある信頼できるソース・リソース・オブジェクトの名前を指定します。

スケジュール済タスク属性の現在の値はXellerateユーザーですが、このコネクタでの信頼できるソースのユーザー・リコンシリエーション用に構成した新しいリソース・オブジェクトの名前に更新する必要があります。

図4-9に、信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合のデザインタイム実装を示します。

図4-9 信頼できるソースのリコンシリエーションを特定のOIMユーザー属性に対して行う場合

4.3.5 サービス・アカウントの管理

Oracle Identity Managerでは、サービス・アカウントがサポートされています。サービス・アカウントは一般管理者アカウント(admin1、admin2、admin3など)であり、メンテナンス用途に使用され、通常は複数のユーザーによって共有されます。サービス・アカウントの管理およびプロビジョニングのモデルは、標準のプロビジョニングとは若干異なります。

サービス・アカウントは、通常のアカウントと同様の方法でリクエスト、プロビジョニングおよび管理されます。これらは、通常アカウントと同じリソース・オブジェクト、プロビジョニング・プロセスおよびプロセス・フォームを使用します。サービス・アカウントは、内部フラグによって通常のアカウントと区別されます。

ユーザーがサービス・アカウントを使用してプロビジョニングされると、Oracle Identity Managerで、ユーザーのアイデンティティからサービス・アカウントへのマッピングが管理されます。リソースが失効された場合、またはユーザーが削除された場合、(取消しタスクが発生するはずだった)サービス・アカウントのプロビジョニング・プロセスの取消しは行われません。かわりに、(Oracle Identity Managerでの無効化および有効化アクションと同様の方法で)タスクがプロビジョニング・プロセスに挿入されます。このタスクによってユーザーからサービス・アカウントへのマッピングが削除され、サービス・アカウントが使用可能なアカウントのプールに戻されます。

この管理機能はAPIを通じて使用できます。

4.4 接続なしアプリケーション・インスタンスの接続アプリケーション・インスタンスへの変換

接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換する手順を説明するうえで、次のことを前提としています。

- 接続なしアプリケーション・インスタンスは、Oracle Identity Managerデプロイメント内に存在します(本番環境など)。この接続なしアプリケーション・インスタンスは、Oracle Identity Managerの別のデプロイメント(テスト環境)にエクスポートされ、接続アプリケーション・インスタンスに変換されます。テスト環境で接続アプリケーション・インスタンスをテストした後に、再び本番環境でインポートします。

注意:

必要に応じて、接続なしリソースを、同じ環境で接続リソースに変換できます。詳細は、「接続なしから接続ありへのアプリケーション・インスタンスの変更」を参照してください。

- 接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換しても、アプリケーション・インスタンス、プロセス定義、フォーム、ITリソース・タイプ定義、およびITリソースの名前は同じままです。

接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換するおおまかな手順を、次に示します。

- 既存の接続なしリソースを、既存の環境からテスト環境にインポートします。

- アプリケーション・インスタンス(リソース・オブジェクト定義、プロセス定義など)の実装を変更します。

- ユーザーにプロビジョニングし、有効化、無効化、失効および更新タスクの動作を検証することで、アプリケーション・インスタンスをテストします。

- テスト環境から新しい接続リソースをエクスポートし、本番環境にインポートします。

注意:

- このリソースのみが、環境間で(アプリケーション・インスタンス間ではなく)エクスポートされます。

- この項では、デプロイメント・マネージャを使用してアプリケーション・インスタンスのリソースをインポート/エクスポートする手順の概要を示します。また、コネクタ・アップグレード・ユーティリティも、リソースのインポート/エクスポートに使用できます。コネクタ・アップグレード・ユーティリティの使用の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のコネクタ・ライフサイクルの管理に関する説明を参照してください。

4.4.1 本番環境での接続なしアプリケーション・インスタンスの作成

本番環境で接続なしアプリケーション・インスタンスを作成するには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。

2. 「サンドボックス」をクリックして、サンドボックス管理にアクセスし、サンドボックスを作成し、それをアクティブにします。サンドボックスの詳細、サンドボックスの作成、アクティブ化および公開方法については、「サンドボックスの管理」を参照してください。

3. 「構成」で、「アプリケーション・インスタンス」をクリックします。ツールバーで「作成」をクリックして、「アプリケーション・インスタンスの作成」ページを開きます。

4. 「名前」および「表示名」フィールドに、LaptopAppInstanceなどの値を入力します。

5. 「切断」オプションを選択して、接続なしアプリケーション・インスタンスを指定します。「切断」オプションを選択すると、そのページの残りのフィールド、たとえば「リソース・オブジェクト」、「ITリソース・インスタンス」、「フォーム」および「親AppInstance」が無効になります。

6. 「保存」をクリックし、「OK」をクリックして、FinAppアプリケーション・インスタンスの作成を確認します。接続なしアプリケーション・インスタンスのアーティファクトが作成されます。

7. 「サンドボックスの管理」ページに移動し、サンドボックスを公開します。

アプリケーション・インスタンスの作成に成功すると、組織および権限を、必要に応じて構成できます。テストのために、4人または5人のユーザーを作成して、そのユーザーに新しく作成した接続なしアプリケーション・インスタンスをプロビジョニングします。ユーザーのアプリケーション・インスタンスのステータスが、「プロビジョニング済」、「有効」、「無効」および「失効」のいずれかであることを確認します。ユーザーのいずれかを変更して、アカウントが正常に更新されることを確認してください。

4.4.2 本番環境からの接続なしアプリケーション・インスタンスのエクスポート

接続なしアプリケーション・インスタンスを本番環境からエクスポートするには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。左側のペインの「システム管理」の下で、「エクスポート」をクリックします。「デプロイメント・マネージャ・ウィザード」が新しいウィンドウで表示されます。

2. 接続なしアプリケーション・インスタンスを検索します。そうするには、検索セクションのリストから「リソース」を選択し、接続なしアプリケーション・インスタンスの名前(LaptopApplication*など)を入力して、「検索」をクリックします。接続なしアプリケーション・インスタンスは、「検索結果」セクションに表示されます。

3. 「検索結果」セクションのLaptopApplicationInstanceを選択して、「子の選択」をクリックします。「子の選択」ページが表示されます。

4. 図4-10に示すように、必要な子属性を選択します。

図4-10 子属性

5. 「依存性の選択」をクリックします。「依存性の選択」ページが表示されます。

6. 「確認」をクリックします。「確認」ページで「エクスポート用に追加」をクリックします。

7. 図4-11に示すように、すべての必要な依存性がエクスポート・サマリーに表示されていることを確認してから、「エクスポート」をクリックします。

図4-11 エクスポート・サマリー

8. XMLファイルの名前を指定します(DisconnectedLaptopExp.xmlなど)。エクスポートが成功すると、メッセージが表示されます。

4.4.3 テスト環境での接続なしアプリケーション・インスタンスのインポート

テスト環境で接続なしアプリケーション・インスタンスをインポートするには、次の手順を実行します。

1. Oracle Identity System Administrationの左側のペインで、「システム管理」の下の「インポート」をクリックします。

2. エクスポートされたXMLファイルのパスを指定し、「OK」をクリックします。確認ページが表示されます。「ファイルの追加」をクリックします。

3. 「置換」ページで、ユーザーまたはグループの置換を指定できます。置換がない場合は、「置換の取消し」をクリックします。

4. 次に示すように、インポート・サマリーで未解決の依存関係の有無を確認してから、「インポート」をクリックします。

図4-12 インポート・サマリー

5. プロセス定義、リソース・オブジェクトおよびフォームが正常にインポートされたことを確認します。

4.4.4 接続なしから接続ありへのアプリケーション・インスタンスの変更

アプリケーション・インスタンスがインポートされた環境で、接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換するには、次の変更を行います。

1. Design Consoleにログインします。

2. 「リソース管理」を展開します。「リソース・オブジェクト」をクリックして、「リソース・オブジェクト」フォームを開きます。

3. リソース・オブジェクトのタイプを、「切断」から「アプリケーション」に変更します。

4. ITリソース・タイプ定義フォームで、必要に応じて接続リソースとともに新しいITリソース・パラメータを定義します。

5. 手順4で追加した新しいパラメータで、既存のITリソース(ITResourceが同じであると想定)を変更します。

6. 「プロセス管理」を開き、「プロセス定義」をクリックして「プロセス定義」フォームを開きます。

7. 接続なしアプリケーション・インスタンスのプロセス定義を検索します。次のタスクが表示されます。

- ManualProvisioningStart

- ManualProvisioningEnd

- ManualEnableStart

- ManualEnableEnd

- ManualDisableStart

- ManualDisableEnd

- ManualRevokeStart

- ManualRevokeEnd

8. タスクごとに、次の手順を実行します:

1. タスクの名前を変更します。たとえば、タスク名をManualProvisioningStartから、XXManualProvisioningStartに変更します。

2. 条件付きオプションが選択されていることを確認します。また、完了に必須オプションが選択されていないことを確認します。

3. タスクが有効化/無効化/失効タスクである場合、タスクの結果を「無効」に変更します。

4. 統合タブで、「削除」をクリックして、タスクにアタッチされたアダプタを解除します。

5. タスク依存性を削除します(存在する場合)。

6. 取消し/リカバリ/生成済タスクを削除します(存在する場合)。

7. オブジェクト・ステータス・マッピングがある場合は、それを「なし」に変更します。

注意:

手順6aから6gは、アプリケーション・インスタンスを接続アプリケーション・インスタンスとしてエクスポートする際に、接続なしアプリケーション・インスタンスの既存のタスクが開始されないようにするためのものです。

9. 更新されたPARENT_FORM_NAMEという名前のタスクがあります。このタスクは、親フォームが更新されると必ずトリガーされます。このタスクにアタッチされた既存のアダプタを解除し、必要に応じてタスクをカスタマイズするようにしてください。

10. この子フォームに関連したタスクがある場合は、「クリア」をクリックして、作成/更新/削除のトリガーを削除するようにします。これらのタスクを再利用しない場合は、これらにアタッチされたアダプタを解除し、タスクの名前を変更して、実行されないようにします。作成、更新および削除の各トリガーに対して新しいタスクを作成することをお薦めします。

注意:

- 必要に応じて、同じタスクを子データに対して保持することができますが、カスタム・アダプタは作成/更新/削除トリガーに対して定義する必要があります。

- 子データを持つ接続なしアプリケーション・インスタンスの場合、削除トリガーを持つタスクは、tcCompleteTaskアダプタに関連付けられます。権限または子データを適切に削除できるように、カスタム・アダプタを定義してこのタスクにアタッチするようにしてください。

11. アカウントの作成、無効化、有効化、失効および更新タスクに対してカスタム・アダプタを定義します。子表がある場合、必ず同じものに対してカスタム・アダプタを定義するようにします。

12. プロセス定義で次のタスクを作成し、対応するアダプタを各タスクに関連付けます。必要な取消し/リカバリ・タスクをマップし、オブジェクト・ステータス・マッピングを設定します。

- ユーザーの作成: タスク・プロパティで、完了に必須オプションが選択され、条件付きオプションが選択されていないことを確認します。

- ユーザーの無効化: タスクの結果が、プロセスの無効化またはアプリケーションへのアクセスであることを確認します。

- ユーザーの有効化: タスクの結果が、プロセスの有効化またはアプリケーションへのアクセスであることを確認します。

- ユーザーの削除: タスクの結果が、プロセスの失効またはアプリケーションへのアクセスであることを確認します。

- 更新されたATTRIBUTE_NAME: プロセス・フォームで定義される属性ごとに、対応する更新タスクを作成する必要があります。これらのタスクはプロセス・フォームの更新時にトリガーされます(たとえば、「更新されたAccount Name」、「更新されたAccount ID」など)。

13. 子表がある場合は、作成、更新、削除など、トリガー・タイプごとにタスクを定義します。

テスト環境で2、3人のユーザーにプロビジョニングすることによって、接続アプリケーション・インスタンスをテストします。アプリケーション・インスタンスをユーザーにプロビジョニングするために、変更されたリソース・オブジェクトおよびITリソースが含まれる新しいアプリケーション・インスタンスを定義する必要があります。

4.4.5 接続アプリケーション・インスタンスのテスト

接続なしアプリケーション・インスタンスを接続アプリケーション・インスタンスに変換した後に、次の操作を実行します。

- 変更済のリソースをテスト環境からエクスポートします。

- 変更済のリソースを本番環境にインポートします。

5 プロビジョニング・プロセスの開発

この章では、Design Consoleでのプロセス管理について説明します。内容は次のとおりです。

- プロセス管理の概要

- 「電子メール定義」フォーム

- 「プロセス定義」フォーム

5.1 プロセス管理の概要

「プロセス管理」フォルダには、Oracle Identity Managerのプロセスと電子メール・テンプレートを作成および管理するためのツールが用意されています。

このフォルダには、次のフォームが含まれます。

- 電子メール定義: このフォームでは、電子メール通知用のテンプレートを作成できます。

- プロセス定義: このフォームでは、プロビジョニング・プロセスを作成および管理できます。また、ワークフロー定義をグラフィカルに表示するワークフロー定義レンダラを起動できます。

5.2 「電子メール定義」フォーム

図5-1に示す「電子メール定義」フォームは「プロセス管理」フォルダにあります。このフォームでは、電子メール通知用のテンプレートを作成できます。これらの通知は、次の場合にユーザーに送信するように設定できます。

- タスクがユーザーに割り当てられた場合。

- タスクが特定のステータスになった場合。

図5-1 「電子メール定義」フォーム

電子メール定義の適用は、「プロセス定義」フォームの「割当て」タブで行います。

5.2.1 電子メール・サーバーの指定

「電子メール定義」フォームを使用する前に、Oracle Identity Managerでユーザーに電子メール通知を送信するために使用される電子メール・サーバーのアドレスを指定する必要があります。

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、Oracle Identity System Administrationを使用して電子メール・サーバーを指定します。電子メール・サーバーを指定するには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。

2. 「システム管理」の下で、「システム構成」をクリックします。

3. 「電子メール・サーバー」システム・プロパティを検索し、そのプロパティをクリックして詳細を開きます。

4. プロパティ名が電子メール・サーバーを表すリソース・アセット・インスタンスの名前に設定されていることを確認し、「保存」をクリックします。

注意:

「電子メール・サーバー」システム・プロパティの値は、電子メール・サーバーのホスト名ではなく、電子メール・サーバーITリソースになっている必要があります。

5. このITリソースが表示されたら、電子メール・サーバーのIPアドレス、およびこのサーバーの使用を検証するユーザーの名前とパスワードを指定します。

5.2.2 「電子メール定義」フォーム

表5-1に、「電子メール定義」フォームのフィールドを示します。

表5-1 「電子メール定義」フォームのフィールド

フィールド名

説明

名前

電子メール定義の名前。

タイプ

このリージョンには、次のことを指定する3つのオプションがあります。

- 電子メール定義をリクエスト関連またはプロビジョニング・プロセス関連として分類するかどうか。

- 電子メール定義の変数をリクエストまたはプロビジョニング・プロセスに関連付けるかどうか。

- 電子メール定義の変数を一般プロセスに関連付けるかどうか。

電子メール定義をプロビジョニング定義として分類する場合、または電子メール変数をプロビジョニング・プロセスに関連付ける場合は、プロビジョニング関連オプションを選択します。

電子メール定義を一般通知として分類する場合は、「一般」オプションを選択します。

オブジェクト名

この参照フィールドでは、電子メール定義が関連するプロビジョニング・プロセスに関連付けられるリソース・オブジェクトを選択します。

注意: 電子メール定義をすべてのリソース・オブジェクトで使用できるようにするには、この参照フィールドを空のままにしてください。

プロセス名

この参照フィールドでは、選択したリソース・オブジェクトに割り当てられているプロビジョニング・プロセスを選択します。これは、電子メール定義が関連するプロビジョニング・プロセスです。

注意: プロビジョニング関連オプションを選択しなかった場合、「オブジェクト名」参照フィールドと「プロセス名」参照フィールドはどちらもグレー表示になります。

言語

この参照フィールドでは、電子メール定義に関連付けられる言語を選択します。

リージョン

この参照フィールドでは、電子メール定義の言語に関連付けられるリージョンを選択します。

ターゲット

電子メール定義の変数のソースを選択します。たとえば、変数として「ユーザー・ログイン」を選択する場合は、ソースとして「ユーザー・プロファイル情報」を選択します。

注意: このボックスに表示される項目は、「タイプ」リージョンで選択したオプションによって変わります。

変数

このボックスでは、電子メール定義の変数(「ユーザー・ログイン」など)を選択します。このボックスに表示される変数は、「ターゲット」ボックスで選択した項目によって変わります。

差出人

このボックスでは、現在、次の2つのタイプのユーザーを選択できます。

- リクエスタ: リクエストを作成したユーザー。

- ユーザー: 電子メール・アドレスを持つあらゆるOracleユーザー(「ユーザー」フォームの「連絡先情報」タブに表示されます)。

ユーザー・ログイン

電子メール通知の差出人リージョンのユーザーのID。

注意: 差出人ボックスに「ユーザー」項目が表示されない場合、「ユーザー・ログイン」フィールドはグレー表示になります。

件名

電子メール定義のタイトル。

本文

電子メール定義の内容。

5.2.3 電子メール定義の作成

電子メール定義を作成するには、次の手順を実行します。

1. 「電子メール定義」フォームを開きます。

2. 「名前」フィールドに、電子メール定義の名前を入力します。

3. 電子メール定義をプロビジョニング・プロセスで使用する場合は、プロビジョニング関連オプションを選択します。

4. 「言語」参照フィールドをダブルクリックし、この電子メール定義に関連付ける言語を選択します。

5. 「リージョン」参照フィールドをダブルクリックし、電子メール定義の言語に関連付けるリージョンを選択します。

注意:

電子メール通知は、最初にOracle Identity Managerをインストールしたときに指定したロケールに基づきます。

6. 「保存」をクリックします。
これで、「電子メール定義」フォームの残りのデータ・フィールドが有効になります。

7. この電子メール定義を特定のリソース・オブジェクトに関連付けるには、「参照」ダイアログ・ボックスで「オブジェクト名」参照フィールドをダブルクリックします。その後、この電子メール定義が関連するプロビジョニング・プロセスに関連付けられるリソース・オブジェクトを選択します。

電子メール定義をすべてのリソース・オブジェクトで使用できるようにするには、この参照フィールドを空のままにしてください。

8. 「プロセス名」参照フィールドをダブルクリックします。
「参照」ダイアログ・ボックスで、手順7で選択したリソース・オブジェクトに割り当てられるプロビジョニング・プロセスを選択します。これは、この電子メール定義が関連するプロビジョニング・プロセスです。

注意:

プロビジョニング関連オプションを選択しなかった場合、「オブジェクト名」参照フィールドと「プロセス名」参照フィールドはどちらもグレー表示になります。

9. 差出人ボックスをクリックします。
カスタム・メニューが表示されたら、電子メール通知の差出人リージョンに表示されるユーザーのタイプを選択します(「リクエスタ」、「ユーザー」または「プロビジョニングされたユーザーのマネージャ」)。

注意:

手順3でプロビジョニング関連オプションを選択しなかった場合、差出人ボックスにプロビジョニングされたユーザーのマネージャ項目は表示されません。

10. オプション。差出人ボックスで「ユーザー」オプションを選択した場合は、「ユーザー・ログイン」参照フィールドをダブルクリックします。
「参照」ダイアログ・ボックスで、電子メール通知の差出人リージョンに表示されるユーザーIDを選択します。

差出人ボックスで「ユーザー」項目を選択しなかった場合、「ユーザー・ログイン」フィールドはグレー表示になります。

11. 件名フィールドに情報を追加します。
このフィールドには、電子メール定義のタイトルが含まれます。

12. 本文テキスト領域に情報を追加します。
このテキスト領域には、電子メール定義の内容が含まれます。

13. 必要に応じて、件名フィールドおよび本文テキスト領域に電子メール変数を移入します。
次の表に、電子メール定義用にカスタマイズ可能な電子メール変数を示します。

名前

説明

タイプ

これらのオプションでは、電子メール定義の変数をプロビジョニング・プロセスに関連付けるかどうかを指定します。

電子メール変数をプロビジョニング・プロセスに関連付けるには、プロビジョニング関連オプションを選択します。

ターゲット

このボックスでは、電子メール定義の変数のソースを選択します。たとえば、「ユーザー・ログイン」変数を使用する場合は、ソースとして「ユーザー・プロファイル情報」を選択します。

変数

このボックスでは、電子メール定義の変数(「ユーザー・ログイン」など)を選択します。

注意:

「ターゲット」ボックスのカスタム・メニューに表示される項目は、「プロビジョニング関連」と「一般」のどちらのラジオ・ボタンを選択するかによって変わります。同様に、変数ボックスのカスタム・メニューに表示される項目は、「ターゲット」、「ロケーション・タイプ」および「連絡先タイプ」の各ボックスに表示される項目に対応します。

14. 件名フィールドまたは本文テキスト領域で使用する電子メール変数を作成します。

15. 「保存」をクリックします。
電子メール定義が作成されます。

5.3 「プロセス定義」フォーム

プロセスとは、Oracle Identity Managerでのプロビジョニングの論理ワークフローを表すメカニズムのことです。プロセス定義は複数のタスクで構成されます。プロセス・タスクは、プロセスの目的を満たすために完了する必要がある手順を表します。たとえば、プロビジョニング・プロセスでは、ユーザーまたは組織がターゲット・リソースにアクセスできるようにするためにタスクが使用されます。

図5-2に示す「プロセス定義」フォームは「プロセス管理」フォルダにあります。このフォームでは、リソース・オブジェクトに関連付けるプロビジョニング・プロセスを作成および管理できます。

図5-2 「プロセス定義」フォーム

図5-2では、Xellerate Organizationプロビジョニング・プロセスが作成され、同名のリソース・オブジェクトに割り当てられています。

注意:

すべてのフォーム列が図5-2に表示されているわけではありません。「タスク」表の右側にその他のフィールド列があります。

表5-2に、「プロセス定義」フォームのフィールドを示します。

表5-2 「プロセス定義」フォームのフィールド

フィールド名

説明

名前

プロセスの名前。

タイプ

プロセス定義の分類タイプ。

オブジェクト名

プロセスが割り当てられるリソース・オブジェクトの名前。

記述フィールドのマップ

インスタンスがリソース・オブジェクトに割り当てられた後、このボタンをクリックして、プロセス定義の識別子として使用されるフィールドを選択します。

レンダラ・ワークフロー

このボタンをクリックしてWebブラウザを起動し、ワークフロー・レンダラ・ツールによって現在のワークフロー定義を表示します。

デフォルト・プロセス

このチェック・ボックスでは、現在のプロセスをそれが関連付けられたリソース・オブジェクトのデフォルトのプロビジョニング・プロセスにするかどうかを指定します。

プロセスを割当て先リソース・オブジェクトのデフォルトのプロビジョニング・プロセスとして設定するには、このチェック・ボックスを選択します。チェック・ボックスを選択解除した場合、プロセスはデフォルトではなくなります。プロセス選択ルールによって選択された場合にのみ呼び出されます。

自動保存フォーム

このチェック・ボックスでは、このプロビジョニング・プロセスに関連付けられているカスタム・フォームの表示を抑制するか、フォームを表示して、プロセスがインスタンス化されるたびにユーザーがデータを入力できるようにするかを指定します。

カスタム・プロセス・フォームを表示せずにフォームにデータが自動的に保存されるようにするには、このチェック・ボックスを選択します。このチェック・ボックスを選択した場合、ユーザーがフォームにアクセスできなくなるため、システム定義データを入力するか、必須データが確実にフォームに移入されるようにアダプタを構成する必要があります。カスタム・プロセス・フォームを表示して、ユーザーがデータをフィールドに入力できるようにするには、このチェック・ボックスを選択解除します。

自動事前移入

このチェック・ボックスでは、カスタム・フォームのフィールドへの移入をOracle Identity Managerとユーザーのどちらに任せるかを指定します。次の2つのタイプのフォームに関係します。

- プロセスに関連付けられているフォーム

- 事前移入アダプタがアタッチされているフィールドを含むフォーム

自動事前移入チェック・ボックスを選択した場合、関連付けられているカスタム・フォームが表示されると、事前移入アダプタがアタッチされたフィールドにOracle Identity Managerによってデータが移入されます。

このチェック・ボックスを選択解除した場合、ツールバーの事前移入ボタンをクリックするか、手動でデータを入力することで、ユーザーがフィールドにデータを移入する必要があります。

注意: この設定は事前移入アダプタのトリガーを制御するものではありません。アダプタの実行によって得られる内容を関連するフォーム・フィールドに表示するのが、Oracle Identity Managerとユーザーのどちらかということだけを決定するものです。

事前移入アダプタの詳細は、「事前移入アダプタに関する作業」を参照してください。

注意: このチェック・ボックスは、プロセスに関連付けられるプロセス・フォームを作成し、事前移入アダプタをそのフォームとともに使用する場合にのみ関係します。

表名

プロセス定義に関連付けられているフォームを表す表の名前。

5.3.1 プロセス定義の作成

プロセス定義を作成するには、次の手順を実行します。

1. 「プロセス定義」フォームを開きます。

2. 「名前」フィールドに、プロセス定義の名前を入力します。

3. 「タイプ」参照フィールドをダブルクリックします。
「参照」ダイアログ・ボックスが表示されたら、プロセス定義の分類タイプ(「承認」)を選択します。

4. 「オブジェクト名」参照フィールドをダブルクリックします。
「参照」ダイアログ・ボックスが表示されたら、プロセス定義に関連付けられるリソース・オブジェクトを選択します。

5. オプション。プロセスを割当て先リソース・オブジェクトのデフォルトのプロビジョニング・プロセスとして設定するには、デフォルト・プロセス・チェック・ボックスを選択します。
現在のプロセス定義をデフォルトにしない場合は、手順6に進んでください。

6. オプション。プロビジョニング・プロセスのカスタム・フォームの表示を抑制して、フォームにデータが自動的に保存されるようにするには、「自動保存フォーム」チェック・ボックスを選択します。

この設定は、プロビジョニング・プロセスにのみ適用されます。

プロビジョニング・プロセスのカスタム・フォームを表示して、ユーザーに情報の入力を求めるには、このチェック・ボックスを選択解除します。

注意:

「自動保存フォーム」チェック・ボックスを選択した場合は、関連するカスタム・プロセス・フォームのすべてのフィールドに、アダプタが関連付けられていることを確認してください。ただし、プロセス・フォームには、プロセス・データ・フロー・マッピングまたは組織デフォルトに対するデフォルトのデータまたはオブジェクトが存在することがあります。

アダプタの詳細、およびアダプタとカスタム・フォームのフィールドとのリレーションシップの詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

7. カスタム・フォームがプロセス定義に関連付けられ、このフォームに含まれるフィールドに事前移入アダプタがアタッチされている場合に、Oracle Identity Managerによってこれらのフィールドにデータが自動的に移入されるようにするには、自動事前移入チェック・ボックスを選択します。
ユーザーにこのフォームのフィールドに手動でデータを移入させる場合は(ツールバーの事前移入ボタンをクリック)、自動事前移入チェック・ボックスを選択解除します。

注意:

プロセス定義にカスタム・フォームが関連付けられていないか、このフォームのフィールドに事前移入アダプタがアタッチされていない場合は、自動事前移入チェック・ボックスを選択解除してください。事前移入アダプタの詳細は、「事前移入アダプタに関する作業」を参照してください。

8. 表名参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス定義に関連付けられているフォームを表す表を選択します。

9. 「保存」をクリックします。
プロセス定義が作成され、「記述フィールドのマップ」ボタンが有効になります。このボタンをクリックすると、「記述フィールドのマップ」ダイアログ・ボックスが表示されます。

このウィンドウでは、プロセスのインスタンスがリソース・オブジェクトに割り当てられる際にプロセス定義の識別子として使用されるフィールド(「組織名」フィールドなど)を選択できます。このフィールドとその値は、「リコンシリエーション・マネージャ」フォームに表示されます。

関連項目:

プロセスにカスタム・プロセス・フォームがアタッチされている場合は、そのフォーム上のフィールドもこのウィンドウに表示され、選択できます。

5.3.2 「プロセス定義」フォームのタブ

「プロセス定義」フォームを起動してプロセス定義を作成すると、このフォームのタブが有効になります。

「プロセス定義」フォームには、次のタブがあります。

- 「タスク」タブ

- リコンシリエーション・フィールド・マッピング・タブ

- 「管理者」タブ

それぞれのタブについて、次の各項で説明します。

5.3.2.1 「タスク」タブ

このタブでは、次のことが可能です。

- 現在のプロセス定義を構成するプロセス・タスクの作成および変更

- プロセス定義からのプロセス・タスクの削除(有効でなくなった場合)

図5-3に、「プロセス定義」フォームの「タスク」タブを示します。

図5-3 「プロセス定義」フォームの「タスク」タブ

関連項目:

プロセス・タスクを編集する方法の詳細は、「プロセス・タスクの変更」を参照してください。

5.3.2.1.1 プロセス・タスクの追加

プロセス・タスクは、プロセスの中で完了する必要がある手順を表します。

プロセス・タスクを追加するには、次の手順を実行します。

1. 「追加」をクリックします。
新しいタスクの作成ダイアログ・ボックスが表示されます。

2. 「タスク名」フィールドに、プロセス・タスクの名前を入力します。

3. 新しいタスクの作成ウィンドウのツールバーで、「保存」をクリックします。次に、「閉じる」をクリックします。
プロセス・タスクがプロセス定義に追加されます。

5.3.2.1.2 プロセス・タスクの編集

プロセス・タスクを編集および設定する手順は、「プロセス・タスクの変更」を参照してください。

5.3.2.1.3 プロセス・タスクの削除

プロセス・タスクを削除するには、次の手順を実行します。

1. 削除対象のプロセス・タスクを選択します。

2. 「削除」をクリックします。
プロセス・タスクがプロセス定義から削除されます。

5.3.2.2 リコンシリエーション・フィールド・マッピング・タブ

図5-4に示すリコンシリエーション・フィールド・マッピング・タブでは、ターゲット・システムまたは信頼できるソースのデータ要素とOracle Identity Managerのフィールドとの間のリレーションシップを定義できます。

図5-4 「プロセス定義」フォームのリコンシリエーション・フィールド・マッピング・タブ

マッピングで選択できるのは、関連付けられているリソースの「リコンシリエーション・フィールド」タブで定義したフィールドのみです。これらのマッピングにより、リコンシリエーション・イベントでターゲット・システムからの情報がOracle Identity Managerのどのフィールドに移入されるかが決まります。ターゲット・リソースの場合(信頼できるソースではない)、このタブを使用して、どのフィールドがキー・フィールドかを示すことができます。キー・フィールドとは、「リコンシリエーション・マネージャ」フォームのプロセス一致ツリー・タブで一致を生成するために、プロセス・フォームとリコンシリエーション・イベントのどの値が同じである必要があるかを決定するものです。

各マッピングについて、次の情報が表示されます。

- Oracle Identity Managerのデータとリコンサイルされるターゲット・システムまたは信頼できるソースのフィールドの名前(関連付けられているリソースの「リコンシリエーション・フィールド」タブで定義)。

- フィールドに関連付けられているデータ型(関連付けられているリソースの「リコンシリエーション・フィールド」タブで定義)。
有効な値は「複数値」、「文字列」、「数値」、「日付」および「ITリソース」です。

注意:

「ITリソース」は、キー・フィールドとしてマークする必要があります。

- 信頼できるソースの場合: ユーザー検出の場合、信頼できるソース・フィールドのデータとユーザー・フォーム上のフィールドの名前のマッピング。組織検出の場合、信頼できるソース・フィールドのデータとOracle Identity Managerの「組織」フォーム上のフィールドの名前のマッピング。
信頼できるソースでユーザー検出と組織検出を実行する場合は、組織検出を先に実行する必要があります。

関連項目:

複数の信頼できるソースのリコンシリエーション用にフィールドをマップする方法の詳細は、「複数の信頼できるソースのリコンシリエーション」を参照してください。

- ターゲット・リソースの場合: ターゲット・リソース・フィールドのデータがマップされる、リソースのカスタム(プロビジョニング)プロセス・フォーム上のフィールドの名前。

- ターゲット・リソースの場合: フィールドがこのターゲット・リソースのリコンシリエーションにおけるキー・フィールドかどうかを示すインジケータ。
リコンシリエーション・イベント・データを照合するプロビジョニング・プロセスの場合は、プロセス・フォームのキー・フィールド値がリコンシリエーション・イベントのものと一致する必要があります。

注意:

効率的な重複権限または子データ検証を有効にするように、リコンシリエーション・フィールド・マッピングの子データの権限属性およびキー属性の両方を構成することをお薦めします。権限または子データの重複検証の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の権限または子データの重複検証に関する説明を参照してください。

5.3.2.2.1 ユーザー・アカウント・ステータスのリコンシリエーション

ユーザー・アカウント・ステータスのリコンシリエーションを構成するには、次の操作を実行する必要があります。

- 信頼できるソースの場合: ターゲットのユーザーのステータスを表すリコンシリエーション・フィールド(「ステータス」など)をそれに対応する信頼できるリソース・オブジェクトに作成する必要があります。このフィールドの値は、「有効」または「無効」のいずれかにする必要があります。このリコンシリエーション・フィールドは、対応するプロセス定義のユーザー属性statusにマップする必要があります。

- ターゲット・リソースの場合: ターゲットのリソースのステータスを表すリコンシリエーション・フィールド(「ステータス」など)をそれに対応するリソース・オブジェクトに作成する必要があります。このリコンシリエーション・フィールドは、対応するプロセス定義のプロセス属性OIM_OBJECT_STATUSにマップする必要があります。ターゲット・リソース・リコンシリエーションでは、次のステータスがサポートされています。

- 失効

- プロビジョニング済

- 準備完了

- 情報の指定

- 有効

- なし

- 待機中

- プロビジョニング

- 無効

5.3.2.2.2 ターゲット・リソース・フィールドとOracle Identity Managerのマッピング

ターゲット・リソースまたは信頼できるソースのフィールド(関連付けられているリソース定義の「リコンシリエーション・フィールド」タブで定義)とOracle Identity Managerの該当するフィールドをマップすることができます。これらのマッピングにより、リコンシリエーション・イベントでOracle Identity Managerのどのフィールドが更新されるかが決まります。これらのマッピングは、「リコンシリエーション・マネージャ」フォームで次のいずれかをクリックしたときに行われます。

- 「ユーザーの作成」または「組織の作成」ボタン

- 「一致したユーザー」または「一致した組織」タブにある「リンク」ボタン

- プロセス一致ツリー・タブにあるリンクの確立ボタン

信頼できるソースのユーザー検出では、ユーザー・リソースからユーザー・プロビジョニング・プロセスのフィールドにマップされるフィールドを定義します。信頼できるソース・フィールドのマップ先のフィールド(ユーザー属性)は、「ユーザー」フォームから導出されます。

信頼できるソースの組織検出では、Oracle Identity Manager組織リソースからOracle Identity Manager組織プロビジョニング・プロセスのフィールドにマップされるフィールドを定義します。信頼できるソース・フィールドのマップ先のフィールド(組織属性)は、「組織」フォームから導出されます。

関連付けられているリソースのプロビジョニング・プロセス定義にアクセスし、リコンシリエーション・フィールド・マッピング・タブを選択した後、次の各項で説明するの2つの手順のいずれかを使用してください。

単一値フィールドのマップ

単一値フィールドをマップするには、次の手順を実行します。

1. 「フィールド・マップの追加」をクリックします。
リコンシリエーション・フィールド・マッピングの追加ダイアログ・ボックスが表示されます。

2. 「フィールド名」フィールドのメニューから、マップするターゲット・システムのフィールドを選択します。
Oracle Identity Managerで、関連付けられている「リソース・オブジェクト」フォームの入力内容に基づいて、このフィールドのフィールド・タイプが自動的に設定されます。

3. 信頼できるソースの場合:
「ユーザー属性」メニューから値を選択し、「OK」をクリックします。手順4に進みます。

ターゲット・リソースの場合:

「プロセス・データ・フィールド」をダブルクリックします。「参照」ダイアログ・ボックスで正しいマッピングを選択し、「OK」をクリックします。

4. 信頼できるソースのマッピングを定義している場合は、手順5に進みます。

ターゲット・リソースの場合にのみ、リコンシリエーション照合用キー・フィールド・チェック・ボックスを設定します。このチェック・ボックスを選択した場合、Oracle Identity Managerによって、プロビジョニング・プロセス・フォームのこのフィールドの値が、リコンシリエーション・イベントのフィールドの値と一致しているかどうかが評価されます。一致したすべてのプロセスが「リコンシリエーション・マネージャ」フォームのプロセス一致ツリー・タブに表示されます。このチェック・ボックスを選択解除した場合、Oracle Identity Managerでのプロセス照合で、このフィールドの値がプロセス・フォームやリコンシリエーション・イベントと一致する必要はありません。

注意:

フィールドをキー・フィールドとして設定するには、該当するリソースのオブジェクト・リコンシリエーション・タブで必須に設定されている必要があります。

5. 「保存」をクリックします。
選択したフィールドのマッピングは、ターゲット・リソースまたは信頼できるソースから次にリコンシリエーション・イベントを受け取ったときに適用されます。

複数値フィールドのマップ(ターゲット・リソースの場合のみ)

複数値フィールドをマップするには、次の手順を実行します。

1. 「表マップの追加」をクリックします。
リコンシリエーション表マッピングの追加ダイアログ・ボックスが表示されます。

2. 「フィールド名」フィールドのメニューから、マップするターゲット・システムの複数値フィールドを選択します。
Oracle Identity Managerで、関連付けられている「リソース・オブジェクト」フォームの入力内容に基づいて、このフィールドのフィールド・タイプが自動的に設定されます。

3. 表名メニューから、ターゲット・リソースのプロセス・フォームで定義した子表を選択します。

4. プロセス・データ・フィールドをダブルクリックし、「参照」ダイアログ・ボックスで正しいマッピングを選択し、「OK」をクリックします。

5. 保存して、リコンシリエーション表マッピングの追加ダイアログ・ボックスを閉じます。

6. マップしたばかりの複数値フィールドを右クリックし、表示されるメニューから「プロパティ・フィールド・マップの定義」を選択します。

7. マップ対象のコンポーネント(子)フィールドを選択します。
Oracle Identity Managerで、関連付けられている「リソース・オブジェクト」フォームの入力内容に基づいて、このフィールドのフィールド・タイプが自動的に設定されます。

8. 「プロセス・データ・フィールド」フィールドをダブルクリックします。
「参照」ダイアログ・ボックスで正しいマッピングを選択し、「OK」をクリックします。

9. リコンシリエーション照合用キー・フィールド・チェック・ボックスを設定します。

このチェック・ボックスを選択した場合、Oracle Identity Managerによって、プロビジョニング・プロセスの子フォームのフィールド値とリコンシリエーション・イベントのフィールド値が比較されます。一致したすべてのプロセスが「リコンシリエーション・マネージャ」フォームのプロセス一致ツリー・タブに表示されます。このチェック・ボックスを選択解除した場合、プロセス照合で、このフィールドの値がプロセス・フォームやリコンシリエーション・イベントと一致する必要はありません。各複数値フィールドの少なくとも1つのコンポーネント(子)フィールドがキー・フィールドとして設定されていることを確認してください。これにより、プロセス一致ツリー・タブで生成される一致の質が向上します。

注意:

キー・フィールドは、該当するリソースのオブジェクト・リコンシリエーション・タブで必須に設定されている必要があります。

10. 複数値フィールドで定義されている各コンポーネント(子)フィールドについて、手順6から9を繰り返します。

11. 「保存」をクリックします。
選択したフィールドのマッピングは、ターゲット・リソースから次にリコンシリエーション・イベントを受け取ったときに適用されます。

5.3.2.2.3 マッピングの削除

この手順は、Oracle Identity Managerのフィールドとターゲット・システムまたは信頼できるソースのフィールド(関連付けられているリソース定義の「リコンシリエーション・フィールド」タブで定義)の間に確立されているマッピングを削除する際に使用します。

マッピングを削除するには、次の手順を実行します。

1. 関連付けられているリソースのプロビジョニング・プロセス定義にアクセスします。

2. リコンシリエーション・フィールド・マッピング・タブを選択します。

3. 削除対象のフィールド・マッピングを選択します。

4. 「マップの削除」をクリックします。
選択したフィールドのマッピングが削除されます。

5.3.2.3 「管理者」タブ

このタブでは、現在のプロセス定義の表示、変更および削除を許可するロールを選択できます。

このタブにある「書込み」チェック・ボックスを選択した場合、対応するロールが現在のプロセス定義を読み取って変更できるようになります。「削除」チェック・ボックスを選択した場合、対応するロールが現在のプロセス定義を削除できるようになります。

5.3.2.3.1 プロセス定義へのロールの割当て

ロールを割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「グループ」ウィンドウが表示されます。

2. 未割当てのロールを選択し、それをプロセス定義に割り当てます。

3. 「OK」をクリックします。
ロールが「管理者」タブに表示されます。

4. このロールに現在のプロセス定義の表示または変更、あるいはその両方を許可するには、対応する「書込み」チェック・ボックスをダブルクリックします。それ以外の場合は、手順5に進みます。

5. このロールに現在のプロセス定義の削除を許可するには、対応する「削除」チェック・ボックスをダブルクリックします。そうでない場合は、手順6に進みます。

6. 「保存」をクリックします。

ロールがプロセス定義に割り当てられます。

5.3.2.3.2 プロセス定義からのロールの削除

ロールを削除するには、次のようにします。

1. 削除対象のロールを選択します。

2. 「削除」をクリックします。
ロールがプロセス定義から削除されます。

5.3.3 プロセス・タスクの変更

プロセス定義のプロセス・タスクを変更するには、その行ヘッダーをダブルクリックします。プロセス・タスクに関するその他の情報を含むタスクの編集ウィンドウが表示されます。

タスクの編集ウィンドウには、次のタブがあります。

- 「一般」タブ

- 統合タブ

- タスク依存性タブ

- 「レスポンス」タブ

- 取消し/リカバリ・タブ

- 「通知」タブ

- タスクとオブジェクトのステータス・マッピング・タブ

- タスクの編集ウィンドウの「割当て」タブ

5.3.3.1 「一般」タブ

このタブでは、変更対象のタスクに関する概要情報を設定できます。この例では、Solaris環境にユーザーを作成するために「ユーザーの作成」タスクが使用されています。

表5-3に、「一般」タブのフィールドを示します。

表5-3 タスクの編集ダイアログ・ボックスの「一般」タブのフィールド

フィールド名

説明

タスク名

プロセス・タスクの名前。

タスクの説明

プロセス・タスクに関する説明。

期間

現在のプロセス・タスクの予定完了時刻(日、時、分)。

条件付き

このチェック・ボックスでは、プロセスに現在のプロセス・タスクを追加するために、ある条件を満たす必要があるかどうかを指定します。

条件が満たされないとプロセスにプロセス・タスクが追加されないようにするには、このチェック・ボックスを選択します。

条件が満たされなくてもプロセスにプロセス・タスクが追加されるようにするには、このチェック・ボックスを選択解除します。

完了に必須

このチェック・ボックスでは、プロセスを完了するのに、現在のプロセス・タスクの完了を必須とするかどうかを指定します。

プロセス・タスクのステータスが「完了」にならないとプロセスを完了できないようにするには、このチェック・ボックスを選択します。

プロセス・タスクのステータスがプロセスの完了ステータスに影響しないようにするには、このチェック・ボックスを選択解除します。

一定期間

適用外

タスクの結果

このボックスでは、タスクに関連付けるプロセス・アクション(無効化や有効化など)を選択します。プロセスでは、リソースへのユーザーのアクセスを有効化または無効化できます。無効化アクションを選択すると、無効化アクションに関連付けられているすべてのタスクが挿入されます。

注意: プロセス・タスクを特定のプロセス・アクションに関連付けない場合は、ボックスから「NONE」を選択してください。

手動挿入不可

このチェック・ボックスでは、現在のプロセス・タスクをユーザーがプロセスに手動で追加できるようにするかどうかを指定します。

プロセスにプロセス・タスクを手動で追加できないようにするには、このチェック・ボックスを選択します。

ユーザーがプロセスにプロセス・タスクを追加できるようにするには、このチェック・ボックスを選択解除します。

保留中の取消しを許可

このチェック・ボックスでは、ステータスが「保留」のときにプロセス・タスクの取消しを許可するかどうかを指定します。

ステータスが「保留」のときにプロセス・タスクの取消しを許可するには、このチェック・ボックスを選択します。

ステータスが「保留」のときにプロセス・タスクの取消しを禁止するには、このチェック・ボックスを選択解除します。

複数のインスタンスを許可

このチェック・ボックスでは、現在のプロセスにプロセス・タスクを複数回挿入できるようにするかどうかを指定します。

プロセスにプロセス・タスクのインスタンスを複数追加できるようにするには、このチェック・ボックスを選択します。

現在のプロセスにプロセス・タスクを1回のみ追加できるようにするには、このチェック・ボックスを選択解除します。

再試行期間(分)

このフィールドでは、プロセス・タスクが却下された場合に、Oracle Identity Managerによってそのタスクの新規インスタンス(ステータスは「保留」)が挿入されるまでの間隔を指定します。

再試行期間(分)フィールドの値が30の場合、「ユーザーの作成」プロセス・タスクが却下されると、Oracle Identity Managerによって30分後にこのタスクの新規インスタンスが追加され、「保留」ステータスが割り当てられます。

注意: このフィールドに値を指定する場合は、次の内容を確認する必要があります。

- Task Timed Retryスケジュール済ジョブが無効化されていないこと。詳細は、『Oracle Fusion Middleware管理者ガイド』の事前定義済のスケジュール済タスクに関する項を参照してください。

- Task Timed Retryスケジュール済ジョブの頻度が、このフィールドの値を下回ること。

- 再試行されるプロセス・タスクの「複数のインスタンスを許可」チェック・ボックスを選択する必要があること。

再試行回数

却下されたタスクがOracle Identity Managerによって再試行される回数を指定します。「再試行回数」フィールドの値が5の場合、「ユーザーの作成」プロセス・タスクが却下されると、Oracle Identity Managerによってこのタスクの新規インスタンスが追加され、「保留」ステータスが割り当てられます。このプロセス・タスクが5回目に却下されると、それ以降、新規インスタンスは挿入されません。

子表/トリガー・タイプ

これらのボックスでは、現在のプロセスに関連付けられているカスタム・フォームの子表(「プロセス定義」フォームの表名フィールドに表示)に対してOracle Identity Managerによって実行されるアクションを指定します。

子表ボックスでは、Oracle Identity Managerによって実行されるアクションの対象となるカスタム・フォームの子表を選択します。

トリガー・タイプ・ボックスでは、Oracle Identity Managerによって子表に対して実行されるアクションを指定します。次のアクションがあります。

- 挿入。子表の指定した列に新しい値が追加されます。

- 更新。子表の対応する列の既存の値が変更されます。

- 削除。子表の指定した列から値が削除されます。

注意: カスタム・プロセス・フォームに子表が関連付けられていない場合、子表ボックスは空になります。また、トリガー・タイプ・ボックスはグレー表示になります。

オフライン

このフラグは、ユーザー属性伝播タスクにのみ適用されます。ユーザー属性伝播タスクに対してフラグを設定すると、タスクの挿入が非同期になります。

5.3.3.1.1 プロセス・タスクの一般情報の変更

プロセス・タスクの一般情報を変更するには、次の手順を実行します。

1. 変更対象のタスクの行ヘッダーをダブルクリックします。
タスクの編集ダイアログ・ボックスが表示されます。

2. 「一般」タブをクリックします。

3. 「説明」フィールドに、プロセス・タスクに関する説明を入力します。

4. オプション。期間領域に、プロセス・タスクの予定完了時刻(日、時、分)を入力します。

5. ある条件を満たさないとプロセス・タスクが「プロセス・インスタンス」に追加されないようにするには、条件付きチェック・ボックスを選択します。それ以外の場合は、手順6に進みます。

注意:

条件付きチェック・ボックスを選択した場合は、タスクをプロセスに追加するための必須条件を指定する必要があります。

6. プロセスの完了ステータスがプロセス・タスクの完了ステータスに依存するようにするには、完了に必須チェック・ボックスを選択します。
それにより、プロセス・タスクのステータスが「完了」にならないと、プロセスを完了できなくなります。

プロセス・タスクのステータスがプロセスの完了ステータスに影響しないようにする場合は、手順7に進みます。

7. 現在実行中のプロセスのインスタンスに、ユーザーが手動でプロセス・タスクを追加できないようにするには、「手動挿入不可」チェック・ボックスを選択します。それ以外の場合は、手順8に進みます。

8. プロセス・タスクのステータスが「保留」のときにそのプロセス・タスクの取消しをユーザーに許可するには、「保留中の取消しを許可」チェック・ボックスを選択します。保存しない場合は、手順9に進みます。

9. このタスクを単一のプロセス・インスタンスに複数回挿入できるようにするには、「複数のインスタンスを許可」チェック・ボックスを選択します。それ以外の場合は、ステップ10に進みます。

10. 「タスクの結果」ボックスをクリックします。

カスタム・メニューが表示されたら、次のいずれかを選択します。

- アプリケーションに対するプロセスまたはアクセスの有効化。有効化機能を使用してリソースを再アクティブ化した場合、この結果が設定されているすべてのタスクがプロセスに挿入されます。このオプションを選択した場合は、「複数のインスタンスを許可」チェック・ボックスも選択する必要があります。

- アプリケーションに対するプロセスまたはアクセスの無効化。無効化機能を使用してリソースを非アクティブ化した場合、この結果が設定されているすべてのタスクがプロセスに挿入されます。このオプションを選択した場合は、「複数のインスタンスを許可」チェック・ボックスも選択する必要があります。

- アプリケーションに対するプロセスまたはアクセスの失効。リソースが失効すると、プロビジョニング・プロセス内の既存のタスクを取り消すことなく失効ワークフローが実行されます。

- 無効。これは、すべてのタスクに関連付けられているデフォルトのプロセス・アクションです。このオプションを選択した場合、条件付きでないタスクは、標準のプロビジョニングの実行時にのみ挿入されます。

11. オプション。プロセス・タスクが「却下」の場合、Oracle Identity Managerによってこのプロセス・タスクの新規インスタンス(ステータスは「保留」)が挿入されるようにすることができます。
そのためには、再試行期間(分)フィールドに値を入力します。これは、Oracle Identity Managerによってこのプロセス・タスク・インスタンスが追加されるまでの待機時間(分単位)です。

「再試行回数」フィールドに、却下されたタスクがOracle Identity Managerによって再試行される回数を入力します。たとえば、「再試行回数」フィールドに3と表示されているとします。タスクが却下されると、Oracle Identity Managerによってこのタスクの新規インスタンスが追加され、「保留」ステータスが割り当てられます。このプロセス・タスクが4回目に却下されると、それ以降、新規インスタンスは挿入されません。

注意:

「再試行期間」および「再試行回数」は相互に関連しているため、一方を選択した場合は、もう一方のオプションのパラメータも指定する必要があります。

12. 子表ボックスでは、Oracle Identity Managerによって実行されるアクションの対象となるカスタム・フォームの子表を選択します。
トリガー・タイプ・ボックスでは、Oracle Identity Managerによって子表に対して実行されるアクションを指定します。次のアクションがあります。

- 挿入: 子表の指定した列に新しい値が追加されます。

- 更新: 子表の対応する列の既存の値が変更されます。

- 削除: 子表の指定した列から値が削除されます。

注意:

カスタム・プロセス・フォームに子表が関連付けられていない場合、子表ボックスは空になります。また、トリガー・タイプ・ボックスはグレー表示になります。

13. 「保存」をクリックします。
プロセス・タスクの概要情報に対する変更には、「一般」タブで行った変更が反映されます。

5.3.3.1.2 Lookup.USR_PROCESS_TRIGGERSフィールドで定義されたイベントのプロセス・タスクのトリガー

Lookup.USR_PROCESS_TRIGGERSでユーザー属性が定義されている場合、その属性が変更されるたびに、プロビジョニングされた各リソースに対して対応するプロセス・タスクがトリガーされます。これは、「名」、「姓」、「表示名」(USR_DISPLAY_NAME)ユーザー属性およびカスタム・ユーザー属性に当てはまります。ただし、Lookup.USR_PROCESS_TRIGGERSフィールドのUSR_STATUS、USR_LOCKED、USR_LOCKED_ONおよびUSR_MANUALLY_LOCKEDについては、アタッチされているプロセス・タスクはトリガーされません。

次の各項では、Lookup.USR_PROCESS_TRIGGERSフィールドのプロセス・タスクをトリガーする方法について説明します。

USR_STATUS属性の場合

USR_STATUS属性はOracle Identity Managerで個別に処理されるため、この属性については、Lookup.USR_PROCESS_TRIGGERSによってタスクを実行することはできません。この属性は、ユーザーを有効化、無効化または削除すると変更されます。これらの操作は、対応するプロセス・タスクが「タスクの結果」設定に従って開始されるため、プロビジョニングされたリソースに特別な結果をもたらします(表5-3 「タスクの編集ダイアログ・ボックスの「一般」タブのフィールド」を参照)。これらの3つの操作については、Lookup.USR_PROCESS_TRIGGERSは使用されません。したがって、ステータスが変わったときに、次の手順に従ってプロセス・タスクを実行します。

ステータスが「無効」から「有効」に遷移した場合:

1. 「プロセス定義」フォームで、「ユーザーの有効化」という名前のプロセス・タスクを作成します。

2. タスクの編集ウィンドウを開き、「一般」タブをクリックします。

3. 「タスクの結果」リストから「アプリケーションに対するプロセスまたはアクセスの有効化」を選択します。

4. 「条件付き」を選択し、タスクをプロセスに追加するための必須条件を指定します。

ステータスが「有効」から「無効」に遷移した場合:

1. 「プロセス定義」フォームで、「ユーザーの無効化」という名前のプロセス・タスクを作成します。

2. タスクの編集ウィンドウを開き、「一般」タブをクリックします。

3. 「タスクの結果」リストから「アプリケーションに対するプロセスまたはアクセスの有効化」を選択します。

4. 「条件付き」を選択し、タスクをプロセスに追加するための必須条件を指定します。

ステータスが「有効」/「無効」/「プロビジョニング済」から「失効」に遷移した場合:

1. 「プロセス定義」フォームで、「ユーザーの削除」という名前のプロセス・タスクを作成します。

2. その後、このタスクを「ユーザーの作成」タスク(通常は無条件でユーザーを作成するタスク)の取消しタスクとして設定します。

3. 「条件付き」を選択し、タスクをプロセスに追加するための必須条件を指定します。

注意:

OIMユーザーが削除されると、各リソースで完了したそれぞれのタスクに対して、Oracle Identity Managerで取消しタスクの実行が試みられます。

USR_LOCKED、USR_LOCKED_ON、USR_MANUALLY_LOCKED属性の場合

ロック操作とロック解除操作は、Oracle Identity Managerで個別の編成として処理されます。編成は次のように行います。

entity-type="User" operation="LOCK"

または

entity-type="User" operation="UNLOCK"

Lookup.USR_PROCESS_TRIGGERSの評価を行うイベント・ハンドラは次のとおりです。

oracle.iam.transUI.impl.handlers.TriggerUserProcesses

これは、次のユーザー編成でのみトリガーされます。

- MODIFY: 一般フィールドの場合

- CHANGE_PASSWORD、RESET_PASSWORD: USR_PASSWORD伝播の場合

- ENABLE、DISABLE、DELETE: プロセス・タスクの実行を処理する場合

ロック/ロック解除操作の場合、TriggerUserProcessesイベント・ハンドラはトリガーされません。したがって、ロック/ロック解除操作によって変更された属性に対しては、Lookup.USR_PROCESS_TRIGGERSはチェックされません。

これらのフィールドが変更されたときにこれらの操作のカスタム・コードを実行する場合は、イベント・ハンドラを作成し、この項で説明した編成に登録できます。

5.3.3.2 統合タブ

統合タブでは、次のことが可能です。

- イベント・ハンドラまたはタスク・アダプタをアタッチすることでプロセス・タスクを自動化します。

- タスク・アダプタの変数をマップすることで、アダプタがトリガーされたときに、Oracle Identity Managerから適切な情報が渡されるようにします。これは、プロセス・タスクのステータスが「保留」の場合に発生します。

- アダプタまたはイベント・ハンドラがプロセス・タスクに適用できなくなった場合に、アダプタ/イベント・ハンドラとプロセス・タスクの間のリンクを解除します。

たとえば、adpSOLARISCREATEUSERアダプタが「ユーザーの作成」プロセス・タスクにアタッチされているとします。このアダプタには9つのアダプタ変数があり、そのすべてが適切にマップされています(各変数名の前にYが付加されています)。

注意:

イベント・ハンドラの先頭には、tcCheckAppInstalledのように、「tc」(Thorクラス)が付加されます。これらは、オラクル社が提供しているイベント・ハンドラです。カスタマ側が作成したイベント・ハンドラの場合、名前の先頭に「tc」を付加することができません。アダプタの先頭には、adpSOLARISCREATEUSERのように、「adp」が付加されます。

関連項目:

アダプタおよびイベント・ハンドラの詳細は、第8章「アダプタ・ファクトリの使用」および第28章「イベント・ハンドラの開発」を参照してください。

5.3.3.2.1 プロセス・タスクへのアダプタまたはイベント・ハンドラの割当て

次の手順では、プロセス・タスクにアダプタまたはイベント・ハンドラを割り当てる方法について説明します。

重要:

プロセス・タスクにアダプタを割り当てる場合、アダプタ変数を正しくマップするまで、アダプタは機能しません。詳細は、「アダプタ変数のマップ」を参照してください。

プロセス・タスクにアダプタまたはイベント・ハンドラを割り当てるには、次の手順を実行します。

1. イベント・ハンドラまたはアダプタを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 統合タブをクリックします。

3. 「追加」をクリックします。
図5-5に示すように、ハンドラの選択ダイアログ・ボックスが表示されます。

4. プロセス・タスクにイベント・ハンドラを割り当てるには、「システム」オプションを選択します。
プロセス・タスクにアダプタを追加するには、「アダプタ」オプションを選択します。プロセス・タスクに割り当てることができるイベント・ハンドラまたはアダプタのリストが「ハンドラ名」リージョンに表示されます。

図5-5 ハンドラの選択ダイアログ・ボックス

5. プロセス・タスクに割り当てるイベント・ハンドラまたはアダプタを選択します。

6. ハンドラの選択ウィンドウのツールバーで、「保存」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

7. 「OK」をクリックします。
イベント・ハンドラまたはアダプタがプロセス・タスクに割り当てられます。

5.3.3.2.2 アダプタ変数のマップ

関連項目:

この手順で選択する項目の詳細は、「アダプタ・マッピング情報」を参照してください。

注意:

親フォーム・フィールドに対する変更に関連付けられているタスクをトリガーするには、タスクの名前が「更新されたfield」になっている必要があります。ここで、fieldは親フォーム・フィールドの名前です。タスクの名前がこの表記規則に従っていない場合は、フィールドが更新されてもタスクはトリガーされません。

アダプタ変数をマップするには、次の手順を実行します。

1. マップ対象のアダプタ変数を選択します。

2. マップをクリックします。
変数のデータ・マッピング・ウィンドウが表示されます。

3. 「マップ先」、「修飾子」、「ITアセット・タイプ」、「ITアセット・プロパティ」、「リテラル値」および「古い値」の各フィールドを指定します。

4. 変数のデータ・マッピング・ウィンドウのツールバーで、「保存」をクリックします。

5. 「閉じる」をクリックします。
アダプタ変数のマッピング・ステータスが「N」から「Y」に変わります。これは、アダプタ変数がマップされたことを示します。

5.3.3.2.3 プロセス・タスクからのアダプタまたはイベント・ハンドラの削除

プロセス・タスクからアダプタまたはイベント・ハンドラを削除するには、次の手順を実行します。

1. 「削除」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

2. 「OK」をクリックします。
イベント・ハンドラまたはアダプタがプロセス・タスクから削除されます。

5.3.3.3 タスク依存性タブ

タスク依存性タブでは、プロセスにおけるプロセス・タスクの論理フローを決定できます。このタブでは、次のことが可能です。

- 先行タスクをプロセス・タスクに割り当てます。
これらのタスクのステータスが「完了」になってからでないと、Oracle Identity Managerまたはユーザーは現在のプロセス・タスクをトリガーできません。

- 依存タスクをプロセス・タスクに割り当てます。
現在のプロセス・タスクのステータスが「完了」になってからでないと、Oracle Identity Managerまたはユーザーはこれらのタスクをトリガーできません。

- 先行タスクの完了ステータスと現在のタスクのトリガーに関係がなくなるように、先行タスクと現在のタスクの間のリンクを解除します。

- 現在のタスクの完了ステータスと依存タスクのトリガーに関係がなくなるように、現在のタスクと依存タスクの間のリンクを解除します。

たとえば、「ユーザーの作成」プロセス・タスクには、先行タスクはありません。タスクがプロセスに挿入されると(関連付けられているリソースがリクエストされた場合など)、Oracle Identity Managerによって常にこのタスクがトリガーされます。「ユーザーの作成」プロセス・タスクには、7つの依存タスクがあります。このプロセス・タスクが完了するまで、各依存タスクのステータスは「待機中」になります。このタスクのステータスが「完了」になると、これらのプロセス・タスクのそれぞれに「保留」ステータスが割り当てられ、Oracle Identity Managerでそれらをトリガーできるようになります。

5.3.3.3.1 プロセス・タスクへの先行タスクの割当て

プロセス・タスクに先行タスクを割り当てるには、次の手順を実行します。

1. 先行タスクを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. タスク依存性タブをクリックします。

3. 先行タスク・リージョンで、「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

4. このウィンドウで、先行タスクを選択し、それをプロセス・タスクに割り当てます。

5. 「OK」をクリックします。
先行タスクがプロセス・タスクに割り当てられます。

5.3.3.3.2 プロセス・タスクからの先行タスクの削除

プロセス・タスクから先行タスクを削除するには、次の手順を実行します。

1. 削除対象の先行タスクを選択します。

2. 先行タスク・リージョンで、「削除」をクリックします。
先行タスクがプロセス・タスクから削除されます。

5.3.3.3.3 プロセス・タスクへの依存タスクの割当て

プロセス・タスクに依存タスクを割り当てるには、次の手順を実行します。

1. 依存タスクを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. タスク依存性タブをクリックします。

3. 依存タスク・リージョンで、「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

4. このウィンドウで、依存タスクを選択し、それをプロセス・タスクに割り当てます。

5. 「OK」をクリックします。
依存タスクがプロセス・タスクに割り当てられます。

5.3.3.3.4 プロセス・タスクからの依存タスクの削除

プロセス・タスクから依存タスクを削除するには、次の手順を実行します。

1. 削除対象の依存タスクを選択します。

2. 依存タスク・リージョンで、「削除」をクリックします。
依存タスクがプロセス・タスクから削除されます。

5.3.3.4 「レスポンス」タブ

「レスポンス」タブでは、次のことが可能です。

- 特定のプロセス・タスクの実行と同時に受け取ることができるレスポンス・コードを定義します。レスポンス・コードを使用して、ターゲット・システム上の特定の条件を表すことができます。

- このプロセス・タスクの実行時にレスポンス・コードを受け取った場合に開始される条件付きタスクを定義します。これらのタスクは生成済タスクと呼ばれます。

- プロセス・タスクからレスポンスを削除します。

- プロセス・タスクから生成済タスクを削除します。

たとえば、「ユーザーの作成」プロセス・タスクが完了したときに、SUCCESSレスポンスがアクティブになります。このレスポンスにより、「ユーザーが正常に作成されました」というメッセージを含むダイアログ・ボックスが表示されます。また、Oracle Identity Managerによって「ユーザーの有効化」プロセス・タスクがトリガーされます。

注意:

デフォルトでは、各プロセス・タスクの却下に対しては不明レスポンスが定義されています。したがって、システム管理者がプロセス・タスクにレスポンスを追加しない場合でも、このタスクが却下されると、ユーザーにはダイアログ・ボックスでエラー・メッセージが通知されます。

5.3.3.4.1 プロセス・タスクへのレスポンスの追加

プロセス・タスクにレスポンスを追加するには、次の手順を実行します。

1. レスポンスを追加するプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 「レスポンス」タブをクリックします。

3. 「レスポンス」リージョンで、「追加」をクリックします。
空白行が「レスポンス」リージョンに表示されます。

4. 「レスポンス」フィールドに情報を入力します。
このフィールドには、レスポンス・コード値が含まれます。このフィールドでは、大文字/小文字が区別されます。

5. 「説明」フィールドに情報を入力します。このフィールドには、レスポンスに関する説明が含まれます。
プロセス・タスクによってレスポンスがトリガーされると、この情報がタスク情報ダイアログ・ボックスに表示されます。

6. 「ステータス」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、タスク・ステータス・レベルを選択します。レスポンス・コードを受け取ると、タスクがこのステータスに設定されます。

7. 「保存」をクリックします。
追加したレスポンスに、入力した設定が反映されるようになります。

5.3.3.4.2 プロセス・タスクからのレスポンスの削除

プロセス・タスクからレスポンスを削除するには、次の手順を実行します。

1. 削除するレスポンスを選択します。

2. 「レスポンス」リージョンで、「削除」をクリックします。
レスポンスがプロセス・タスクから削除されます。

注意:

レスポンスが既存のものであっても、新しく追加されたものであっても、プロビジョニング・インスタンスに対して呼び出されるプロセス・タスクからはレスポンスを削除できません。ただし、プロセス・タスクがどのプロビジョニング・インスタンスに対しても呼び出されない場合は、レスポンスを削除できます。

5.3.3.4.3 プロセス・タスクへの生成済タスクの割当て

プロセス・タスクに生成済タスクを割り当てるには、次の手順を実行します。

1. 生成済タスクを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 「レスポンス」タブをクリックします。

3. 生成済タスクを割り当てるレスポンス・コードを選択します。

4. 生成するタスク・リージョンで、「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

5. このウィンドウで、生成済タスクを選択し、それをプロセス・タスク・レスポンスに割り当てます。

6. 「OK」をクリックします。
生成済タスクがプロセス・タスクに割り当てられます。

5.3.3.4.4 プロセス・タスクからの生成済タスクの削除

プロセス・タスクから生成済タスクを削除するには、次の手順を実行します。

1. レスポンス・コードを選択します。

2. 削除対象の生成済タスクを選択します。

3. 生成するタスク・リージョンで、「削除」をクリックします。
生成済タスクがプロセス・タスクから削除されます。

5.3.3.5 取消し/リカバリ・タブ

取消し/リカバリ・タブでは、次のことが可能です。

- 現在のプロセス・タスクが取り消されたときにトリガーされるプロセス・タスクを定義します。これらのプロセス・タスクは取消しタスクと呼ばれます。

- 有効でなくなった取消しタスクをプロセス・タスクから削除します。

- 現在のプロセス・タスクが却下されたときにトリガーされるプロセス・タスクを定義します。これらのタスクはリカバリ・タスクと呼ばれます。

- プロセス・タスクからリカバリ・タスクを削除します。

たとえば、「ユーザーの作成」プロセス・タスクのステータスが「取消」になると、「ユーザーの削除」取消しタスクがトリガーされます。同様に、「ユーザーの作成」タスクが「却下」になると、Oracle Identity Managerによって「ユーザーの有効化」リカバリ・タスクがトリガーされます。

注意:

現在のプロセス・タスクが却下されると、そのプロセス・タスクに割り当てられているリカバリ・タスクがOracle Identity Managerによってトリガーされます。「リカバリの完了」チェック・ボックスを選択すると、生成されたすべてのリカバリ・タスクが完了したときに、現在のプロセス・タスクのステータスが「却下」から「完了に失敗」に変更されます。これによって、Oracle Identity Managerで他の依存プロセス・タスクをトリガーできるようになります。

次の各項では、現在のプロセス・タスクに取消しタスクやリカバリ・タスクを割り当てる方法、および現在のプロセス・タスクから取消しタスクやリカバリ・タスクを削除する方法について説明します。

5.3.3.5.1 プロセス・タスクへの取消しタスクの割当て

プロセス・タスクに取消しタスクを割り当てるには、次の手順を実行します。

1. 取消しタスクを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 取消し/リカバリ・タブをクリックします。

3. 取消しタスク・リージョンで、「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

4. このウィンドウで、取消しタスクを選択し、それをプロセス・タスクに割り当てます。

5. 「OK」をクリックします。
取消しタスクがプロセス・タスクに割り当てられます。

5.3.3.5.2 プロセス・タスクからの取消しタスクの削除

プロセス・タスクから取消しタスクを削除するには、次の手順を実行します。

1. 削除対象の取消しタスクを選択します。

2. 取消しタスク・リージョンで、「削除」をクリックします。
取消しタスクがプロセス・タスクから削除されます。

5.3.3.5.3 プロセス・タスクへのリカバリ・タスクの割当て

プロセス・タスクにリカバリ・タスクを割り当てるには、次の手順を実行します。

1. リカバリ・タスクを割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 取消し/リカバリ・タブをクリックします。

3. リカバリ・タスク・リージョンで、「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

4. このウィンドウで、リカバリ・タスクを選択し、それをプロセス・タスクに割り当てます。

5. 「OK」をクリックします。
リカバリ・タスクがプロセス・タスクに割り当てられます。

6. オプション。生成されたすべてのリカバリ・タスクが完了したときに、現在のプロセス・タスクのステータスを「却下」から「完了に失敗」に変更する場合は(これにより、Oracle Identity Managerで他の依存プロセス・タスクをトリガーできるようになります)、「リカバリの完了」チェック・ボックスを選択します。それ以外の場合は、このチェック・ボックスを選択しないでください。

5.3.3.5.4 プロセス・タスクからのリカバリ・タスクの削除

プロセス・タスクからリカバリ・タスクを削除するには、次の手順を実行します。

1. 削除対象のリカバリ・タスクを選択します。

2. リカバリ・タスク・リージョンで、「削除」をクリックします。
リカバリ・タスクがプロセス・タスクから削除されます。

5.3.3.6 「通知」タブ

このタブでは、現在のプロセス・タスクが特定のステータスになったときに生成される電子メール通知を指定できます。タスクに割り当てられる各ステータスについて、別々の電子メール通知を生成できます。電子メール通知が有効でなくなったら、「通知」タブから削除できます。

たとえば、「ユーザーの作成」プロセス・タスクのステータスが「完了」になると、Oracle Identity Managerによって、リソースのプロビジョニング対象となっているユーザーに対して電子メール通知「プロセス・タスクの完了」が送信されます。「ユーザーの作成」プロセス・タスクが却下されると、電子メール通知「プロセス・タスクの完了」がユーザーとそのマネージャに送信されます。

注意:

Oracle Identity Managerでユーザーに電子メール通知を送信できるようにするには、「電子メール定義」フォームを使用して電子メール・メッセージのテンプレートを事前に作成する必要があります。詳細は、「「電子メール定義」フォーム」を参照してください。

次の各項では、プロセス・タスクに電子メール通知を割り当てる方法、およびプロセス・タスクから電子メール通知を削除する方法について説明します。

5.3.3.6.1 プロセス・タスクへの電子メール通知の割当て

プロセス・タスクに電子メール通知を割り当てるには、次の手順を実行します。

1. 電子メール通知を割り当てるプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ダイアログ・ボックスが表示されます。

2. 「通知」タブをクリックします。

3. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

4. このウィンドウで、使用する電子メール・テンプレート定義を選択し、それをプロセス・タスクに割り当てます。

5. 「OK」をクリックします。
電子メール通知の名前が「通知」タブに表示されます。

6. 「ステータス」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、完了ステータス・レベルを選択します。プロセス・タスクがこのステータス・レベルになると、Oracle Identity Managerによって、関連付けられている電子メール通知が送信されます。

7. 電子メール通知を受信するユーザーを表すチェック・ボックスを選択します。
現在、電子メール通知は、次のユーザーに送信できます。

- 割当て先。このユーザーは、関連付けられているプロセス・タスクを完了する必要があります。

- リクエスタ。このユーザーは、対応するプロセス・タスクが含まれるプロセスをリクエストしました。

- ユーザー。関連付けられているプロセス・タスクが「完了」になると、このユーザーにリソースがプロビジョニングされます。

- ユーザーのマネージャ。このユーザーはユーザーのスーパーバイザであり、対応するプロセス・タスクが「完了」になると、このユーザーにリソースがプロビジョニングされます。

8. 「保存」をクリックします。
電子メール通知がプロセス・タスクに割り当てられます。

5.3.3.6.2 プロセス・タスクからの電子メール通知の削除

次の手順では、プロセス・タスクから電子メール通知を削除する方法について説明します。

プロセス・タスクから電子メール通知を削除するには、次の手順を実行します。

1. 削除対象の電子メール通知を選択します。

2. 「削除」をクリックします。
電子メール通知がプロセス・タスクから削除されます。

5.3.3.7 タスクとオブジェクトのステータス・マッピング・タブ

リソース・オブジェクトには、ユーザーやアプリケーションへのリソースのプロビジョニングに使用するデータが含まれます。

また、リソース・オブジェクトには、事前定義されたプロビジョニング・ステータスがあり、リソース・オブジェクトがターゲットのユーザーや組織にプロビジョニングされるのに応じて、そのライフサイクルを通じて様々なステータスを表します。

注意:

プロビジョニング・ステータスは、「リソース・オブジェクト」フォームのステータスの定義タブに定義されています。

リソース・オブジェクトのプロビジョニング・ステータスは、関連付けられているプロビジョニング・プロセスのステータス、およびそれらのプロセスを構成するタスクのステータスによって決まります。このため、プロセス・タスクのステータスとその割当て先リソース・オブジェクトのプロビジョニング・ステータスの間にリンクを確立する必要があります。

タスクとオブジェクトのステータス・マッピング・タブを使用して、このリンクを作成します。また、この接続が不要になったり、プロセス・タスクのステータスをリソース・オブジェクトの別のプロビジョニング・ステータスに関連付ける場合は、その時点で存在するリンクを解除する必要があります。

この例では、プロセス・タスクのステータスとリソース・オブジェクトのプロビジョニング・ステータスの間に5つのマッピングがあります。「ユーザーの作成」プロセス・タスクのステータスが「完了」になると、関連付けられているリソース・オブジェクトには「プロビジョニング済」というプロビジョニング・ステータスが割り当てられます。ただし、このタスクが取り消されると、そのリソース・オブジェクトのプロビジョニング・ステータスは「失効」になります。「なし」は、このステータスがリソース・オブジェクトのプロビジョニング・ステータスに何の影響もないことを示します。

次の各項では、プロビジョニング・ステータスにプロセス・タスクのステータスをマップする方法、およびプロビジョニング・ステータスからプロセス・タスクのステータスをマップ解除する方法について説明します。

5.3.3.7.1 プロビジョニング・ステータスへのプロセス・タスクのステータスのマップ

プロビジョニング・ステータスにプロセス・タスクのステータスをマップするには、次の手順を実行します。

1. ステータスをリソース・オブジェクトのプロビジョニング・ステータスにマップするプロセス・タスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. タスクのオブジェクト・ステータス・マッピング・タブをクリックします。

3. 目的のプロセス・タスクのステータスを選択します。

4. 「オブジェクト・ステータス」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス・タスクのステータスをマップするリソース・オブジェクトのプロビジョニング・ステータスを選択します。

5. 「OK」をクリックします。
選択したプロビジョニング・ステータスがタスクとオブジェクトのステータス・マッピング・タブに表示されます。

6. 「保存」をクリックします。
プロセス・タスクのステータスがプロビジョニング・ステータスにマップされます。

5.3.3.7.2 プロビジョニング・ステータスからのプロセス・タスクのステータスのマップ解除

プロビジョニング・ステータスからプロセス・タスクのステータスをマップ解除するには、次の手順を実行します。

1. 目的のプロセス・タスクのステータスを選択します。

2. 「オブジェクト・ステータス」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、「なし」を選択します。「なし」は、このステータスがリソース・オブジェクトのプロビジョニング・ステータスに何の影響もないことを示します。

3. 「OK」をクリックします。
プロビジョニング・ステータス「なし」がタスクとオブジェクトのステータス・マッピング・タブに表示されます。

4. 「保存」をクリックします。
プロセス・タスクのステータスがリソース・オブジェクトのプロビジョニング・ステータスからマップ解除されます。

5.3.3.8 タスクの編集ウィンドウの「割当て」タブ

このタブでは、現在のプロセス・タスクの割当てルールを指定できます。これらのルールによって、プロセス・タスクの割当て方法を決定します。

注意:

タスク割当てルールは、手動で完了する必要があるタスクに関連付けて使用すると便利です。ほとんどのプロビジョニング・プロセス・タスクは自動化されているため、タスク割当てルールは不要です。

Oracle Identity Managerでは、「Solarisプロセス・タスク - ユーザー」というルールの基準が満たされない場合に、「Solarisプロセス・タスク - グループ」というルールの基準が評価されます。そのルールの基準が満たされると、タスクはSYSTEM ADMINISTRATORSロールに割り当てられ、10分後にエスカレートされるようにマークされます。

注意:

プロセス・タスクに割り当てることができるのは、分類タイプが「タスクの割当て」のルールのみです。ルールの分類タイプを指定する方法の詳細は、「「ルール・デザイナ」フォーム」を参照してください。また、Oracle Identity Managerでは、デフォルト・ルールが事前に定義されています。このルールは常にTrueと評価されます。このため、他のルールがすべて失敗しても、少なくとも1つの事前定義のタスク割当てが実行されることを保証する安全策として使用できます。

表5-4に、「割当て」タブのフィールドを示します。

表5-4 タスクの編集ウィンドウの「割当て」タブのフィールド

フィールド名

説明

ルール

評価するタスク割当てルールの名前。

ターゲット・タイプ

現在のプロセス・タスクを完了する必要があるユーザーまたはロールの分類タイプ。現在、プロセス・タスクの割当て先候補となるのは次のとおりです。

- ユーザー。Oracle Identity Managerユーザー。

- ロール。ロール。

- 最小ロードのグループ・ユーザー。割り当てられるプロセス・タスクの数が最も少ない特定ロールのメンバー。

- リクエスト・ターゲット・ユーザーのマネージャ。リソースがプロビジョニングされるユーザーのスーパーバイザ。

- 最小ロードのオブジェクト認可ユーザー。割り当てられるプロセス・タスクの数が最も少ないロール(リソースのオブジェクト認可ロールとして指定されたもの)のメンバー。

- オブジェクト管理者。関連付けられているリソース・オブジェクトの管理者として定義されているロール。

- 最小ロードのオブジェクト管理ユーザー。割り当てられるプロセス・タスクの数が最も少ないロール(オブジェクト管理者ロールとして指定されたもの)のメンバー。

注意: オブジェクト認可者およびオブジェクト管理者の各ロールは、それぞれ「リソース・オブジェクト」フォームの「オブジェクト認可者」および「管理者」タブに定義されています。

アダプタ

アダプタの名前。このフィールドをダブルクリックすると、既存のすべてのアダプタを参照できるフォームが表示されます。

アダプタ・ステータス

アダプタのステータス。

グループ

現在のプロセス・タスクが割り当てられているロール。

ユーザー

現在のプロセス・タスクが割り当てられているユーザー。

「電子メール名」および「電子メールの送信」

電子メール名参照フィールドから電子メール通知を選択し、「電子メールの送信」チェック・ボックスを選択することにより、現在のプロセス・タスクが割り当てられたときに、Oracle Identity Managerによってユーザーまたはロールに電子メール通知が送信されるようになります。

エスカレーション時間

Oracle Identity Managerによってトリガーされるルールに関連付けられているユーザーまたはロールがプロセス・タスクを完了する必要がある制限時間(ミリ秒)。このプロセス・タスクが所定時間内に完了しない場合、Oracle Identity Managerによってタスクが別のユーザーまたはロールに再割当てされます。エスカレーション・ルールは、ターゲット・タイプ・パラメータで定義された順序に従います。

優先度

現在のプロセス・タスクに関連付けられているルールの優先度値。この値は、Oracle Identity Managerでルールが評価される順序を示します。

次の各項では、プロセス・タスクにタスク割当てルールを追加する方法、およびプロセス・タスクからタスク割当てルールを削除する方法について説明します。

5.3.3.8.1 プロセス・タスクへのルールの追加

プロセス・タスクにルールを追加するには、次の手順を実行します。

1. ルールを追加するタスクの行ヘッダーをダブルクリックします。
タスクの編集ウィンドウが表示されます。

2. 「割当て」タブをクリックします。

3. 「追加」をクリックします。
空白行が「割当て」タブに表示されます。

4. 「ルール」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス・タスクに追加するルールを選択します。次に、「OK」をクリックします。

5. 「ターゲット・タイプ」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス・タスクを完了する必要があるユーザーまたはロールの分類タイプ(「ユーザー」、「ロール」、「最小ロードのグループ・ユーザー」、「リクエスト・ターゲット・ユーザーのマネージャ」、「最小ロードのオブジェクト認可ユーザー」、「オブジェクト管理者」、「最小ロードのオブジェクト管理ユーザー」)を選択します。次に、「OK」をクリックします。

6. 「グループ」参照フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス・タスクを完了する必要があるロールを選択します。この設定が必要になるのは、「ターゲット・タイプ」フィールドで「グループ」または「最小ロードのグループ・ユーザー」を選択した場合のみです。その後、「OK」をクリックします。

または

「ユーザー」参照フィールドをダブルクリックします。「参照」ウィンドウが表示されたら、プロセス・タスクを完了する必要があるユーザーを選択します。この設定が必要になるのは、「ターゲット・タイプ」フィールドで「ユーザー」を選択した場合のみです。その後、「OK」をクリックします。

7. 電子メール名フィールドをダブルクリックします。
「参照」ウィンドウが表示されたら、プロセス・タスクが割り当てられたときに、対応するユーザーまたはロールに送信される電子メール通知を選択します。「OK」をクリックします。その後、「電子メールの送信」チェック・ボックスを選択します。

タスクが割り当てられたときにOracle Identity Managerによって電子メール通知が送信されないようにする場合は、手順8に進みます。

8. 「エスカレーション時間」フィールドに、選択したユーザーまたはロールがプロセス・タスクを完了する必要がある制限時間(ミリ秒)を入力します。
プロセス・タスクに追加するルールに制限時間を関連付けない場合は、「エスカレーション時間」フィールドを空白のままにして、手順10に進みます。

9. 「優先度」フィールドに、プロセス・タスクに追加するルールの優先度値を入力します。

10. 「保存」をクリックします。
ルールがプロセス・タスクに追加されます。

5.3.3.8.2 プロセス・タスクからのルールの削除

プロセス・タスクからルールを削除するには、次の手順を実行します。

1. 削除対象のルールを選択します。

2. 「削除」をクリックします。
ルールがプロセス・タスクから削除されます。

6 プロセス・フォームの開発

リソースをターゲット・ユーザーまたは組織にプロビジョニングするために必要な情報を既存のOracle Identity Managerフォームから取得できない場合があります。Design Consoleの「開発ツール」フォルダにある「フォーム・デザイナ」フォームを使用して、関連情報を含むフィールドを持つフォームを作成できます。作成したフォームは、ユーザーまたは組織へのリソースのプロビジョニングに関連付けられているプロセスまたはリソース・オブジェクトに割り当てます。図6-1に、「フォーム・デザイナ」フォームを示します。

Oracle Identity Managerでは、次の理由でユーザーが「フォーム・デザイナ」フォームを使用して作成したリソース・オブジェクトまたはプロセス・フォームを表示します。

プロセス・フォームが適切なプロビジョニング・プロセスにアタッチされ、「組織」フォームまたは「ユーザー」フォームの「オブジェクト・プロセス・コンソール」タブでプロセスを右クリックすることによってフォームの起動メニュー・コマンドが選択された場合。

たとえば、Oracle Identity Managerまたはそのいずれかのユーザーがリソース・オブジェクトまたはプロセスを完了しようとすると、割り当てられているフォームがトリガーされます。この場合、Oracle Identity Managerまたはユーザーによって、このフォームのフィールドにデータが移入されます。データを保存すると、対応するプロセスまたはリソース・オブジェクトは「完了」ステータスになり、Oracle Identity Managerは適切なリソースをターゲット組織またはユーザーにプロビジョニングできます。

図6-1 「フォーム・デザイナ」フォーム

たとえば、「Solaris」フォーム(「表名」フィールドでUD_SOLARISという名前で示されている)が作成され、Solarisリソース・オブジェクトとプロビジョニング・プロセスの両方に割り当てられています。

注意:

表名は、接頭辞UD_の後にフォーム名が続きます。この例では、フォーム名がSOLARISであるため、表名はUD_SOLARISとなります。

表6-1に、「フォーム・デザイナ」フォームのデータ・フィールドを示します。

表6-1 「フォーム・デザイナ」フォームのフィールド

フィールド名

説明

表名

フォームに関連付けられるデータベース表の名前。

注意: 表名は、接頭辞UD_の後にフォーム名が続きます。フォーム名がSOLARISの場合、表名はUD_SOLARISとなります。

説明

フォームに関する説明。

重要: 「説明」フィールドに表示されるテキストは、フォーム名です。

フォームのプレビュー

このボタンをクリックすると、フォームが表示されます。これにより、フォームをアクティブ化する前にフォームの外観と動作を確認できます。

フォーム・タイプ

これらのオプションは、フォームをプロセスに割り当てるかリソース・オブジェクトに割り当てるかを指定するために使用します。

「プロセス」オプションを選択した場合、フォームは承認プロセスまたはプロビジョニング・プロセスに関連付けられます。

オブジェクト名

これは、プロビジョニング可能なリソース(データベース、サーバー、ソフトウェア・アプリケーション、ファイル、ディレクトリ・アクセスなど)の名前です。リソース・オブジェクト名とも呼ばれます。

このフィールドをダブルクリックすると、使用可能なリソース・オブジェクト名が表示されます。

最新バージョン

フォームの最新バージョン。

アクティブ・バージョン

指定されたプロセスまたはリソース・オブジェクトで使用されるフォームのバージョン。

注意: アクティブ・バージョン・フィールドに表示されたフォームのバージョンは変更できません。

現行バージョン

このバージョンのフォームが現在表示されており、情報が「フォーム・デザイナ」フォームの各種タブを介して表示されます。

新しいバージョンの作成

このボタンをクリックすると、フォームの既存のバージョンに追加の名前を割り当てることができます。その結果、フォームの元のバージョンに影響を及ぼすことなく、このバージョンを変更できます。

注意: フォームの新しいバージョンを作成して「リフレッシュ」をクリックすると、このバージョンに対して指定した名前が現行バージョン・ボックスに表示されます。

バージョンをアクティブにする

このボタンをクリックすると、フォームの現行バージョンをプロセスまたはリソース・オブジェクトに割り当てるように指定できます。つまり、このバージョンがアクティブになります。

注意: アクティブになったバージョンのフォームは変更できません。かわりに、(新しいバージョンの作成ボタンをクリックして)フォームの別の追加バージョンを作成する必要があります。

次の各項で、フォームの使用方法について説明します。

- フォームの作成

- 「フォーム・デザイナ」フォームのタブ

- フォームの追加バージョンの作成

6.1 フォームの作成

フォームを作成するには、次の手順を実行します。

1. 「フォーム・デザイナ」フォームを開きます。

2. 「表名」フィールドに、フォームに関連付けるデータベース表の名前を入力します。

注意:

表名は、接頭辞UD_の後にフォーム名が続きます。フォーム名がSOLARISの場合、表名はUD_SOLARISとなります。

3. 「説明」フィールドに、フォームに関する説明を入力します。

4. 「プロセス」オプションを選択します。これは、フォームをプロビジョニング・プロセスに割り当てるためです。

5. 「保存」をクリックします。
フォームが作成されます。最新バージョン・フィールドに、初期バージョンと表示されます。このことは、「フォーム・デザイナ」フォームのタブに情報を移入でき、フォームが割り当てられたプロセスまたはリソースで動作することを意味します。

注意:

アプリケーション・インスタンスを作成してプロセス・フォームを関連付け、サンドボックスを公開し、Design Consoleでそのプロセス・フォームに新しいフィールドや事前移入アダプタの追加などの変更を行った場合、その変更はアプリケーション・インスタンスに反映されません。アプリケーション・インスタンスに変更を反映するには、新しいプロセス・フォームを作成してアプリケーション・インスタンスに関連付けます。これを実行するには、Design Consoleの「フォーム・デザイナ」フォームを使用するのではなく、Oracle Identity System Administrationのフォーム・デザイナを使用する方法をお薦めします。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のフォームの管理に関する項を参照してください。

6.2 「フォーム・デザイナ」フォームのタブ

「フォーム・デザイナ」フォームを開いてフォームを作成すると、このフォームのタブが機能するようになります。「フォーム・デザイナ」フォームには次のタブがあります。

- 「追加列」タブ

- 子表タブ

- オブジェクト権限タブ

- 「プロパティ」タブ

- 「管理者」タブ

- 「使用方法」タブ

- 「事前移入」タブ

- デフォルト列タブ

- 「ユーザー定義フィールド」タブ

6.2.1 「追加列」タブ

「追加列」タブを使用して、データ・フィールドを作成および管理します。これらのフィールドは、「フォーム・デザイナ」フォームを使用して作成された、関連付けられているフォームに表示されます。

表6-2に、「追加列」タブのデータ・フィールドを示します。

表6-2 「追加列」タブのフィールド

名前

説明

名前

データベースに表示され、Oracle Identity Managerによって認識されるデータ・フィールドの名前。

注意: この名前は、<TABLENAME_>接頭辞の後にデータ・フィールドの名前が続きます。

たとえば、「フォーム・デザイナ」フォームの「表名」フィールドの名前がUD_PASSWORDでデータ・フィールドの名前がUSERNAMEの場合、データベースに表示されてOracle Identity Managerによって認識されるデータ・フィールド名はUD_PASSWORD_USERNAMEです。

バリアント型

この参照フィールドから、データ・フィールドのバリアント型を選択します。バリアント型は、フィールドで受け入れられるデータの型を示します。

このデータ・フィールドは、9つのバリアント型(Byte、Double、Date、バイト配列、Boolean、Long、String、ShortおよびInteger)のいずれかである必要があります。

長さ

データ・フィールドの長さ(文字数)。

フィールド・ラベル

データ・フィールドに関連付けられるラベル。このラベルは、Oracle Identity Managerによって生成されたフォームのデータ・フィールドの横に表示されます。

フィールド・タイプ

この参照フィールドから、データ・フィールドのデータ型を選択します。データ型は、フィールドにおけるデータの表示方法を表します。

次のいずれかのデータ型を選択できます。

- TextField: このデータ・フィールドは、生成されたフォームにテキスト・フィールドとして表示されます。
テキスト・フィールドが表示専用である(フィールドのテキストが赤色のフォントで表示されている)場合、ユーザーはフィールドを問合せの実行のためにのみ使用できます。それ以外の場合は、フィールドに情報を移入し、データベースに保存することもできます。

- LookupField: このデータ・フィールドは、生成されたフォームに参照フィールドとして表示されます。
この参照フィールドが表示専用の場合、ユーザーはフィールドを問合せの実行のためにのみ使用できます。それ以外の場合は、関連付けられた「参照」ウィンドウの値をフィールドに移入し、その値をデータベースに保存することもできます。

- TextArea: このデータ・フィールドは、生成されたフォームにテキスト領域として表示されます。
このテキスト領域が表示専用の場合、ユーザーは表示された情報の読取りのみを行うことができます。それ以外の場合は、テキスト領域にデータを移入し、その情報をデータベースに保存することもできます。

- ITResourceLookupField: このデータ・フィールドは、生成されたフォームに参照フィールドとして表示されます。この参照フィールドから、ITリソースを表す参照値を選択し、その値をデータベースに保存できます。
注意: このデータ・フィールドを選択した場合は、「プロパティ値」フィールドでITリソースのサーバー・タイプを指定する必要があります。

データ・フィールドにプロパティ値を追加する方法の詳細は、「データ・フィールドへのプロパティおよびプロパティ値の追加」を参照してください。

- DateFieldWithDialog: このデータ・フィールドは、生成されたフォームにテキスト・フィールドとして表示されます。
このテキスト・フィールドが表示専用の場合、ユーザーはフィールドを問合せの実行のためにのみ使用できます。

それ以外の場合は、フィールドをダブルクリックし、日時ウィンドウで日付および時間を選択して、フィールドに日付および時間を移入することもできます。その後、この日付および時間をデータベースに保存できます。

- Checkbox: このデータ・フィールドは、生成されたフォームにチェック・ボックスとして表示されます。
このチェック・ボックスが表示専用の場合、ユーザーはチェック・ボックスが選択されているかどうかの確認のみを行うことができます。それ以外の場合は、チェック・ボックスを選択または選択解除し、その設定をデータベースに保存することもできます。

- PasswordField: このフィールドに入力されたテキストは、一連のアスタリスク(*)文字として表示されます。
Oracle Identity Managerは、Password Fieldというフィールド・タイプを持つフィールドによりAccountPasswordプロパティがtrueに設定されるかどうかをチェックします。設定されていれば、パスワード・ポリシーが適用されます。そのようなフィールドが存在しない場合、Oracle Identity Managerは、FORM_NAME_PASSWORD形式の名前を持つPassword Fieldタイプのフィールドがあるかどうかをチェックします。設定されていれば、パスワード・ポリシーが適用されます。

そのようなフィールドが作成されると、Oracle Identity Managerは、Password Fieldというフィールド・タイプとFORM_NAME_PASSWORD形式の名前を持つフィールドに対してAccountPassword=trueを自動的に設定します。

AccountPasswordプロパティをtrueに設定する方法の詳細は、「AccountPasswordプロパティの値の設定」を参照してください。

データ・フィールドにプロパティ値を追加する方法の詳細は、「データ・フィールドへのプロパティおよびプロパティ値の追加」を参照してください。

- RADIOBUTTON: このデータ・フィールドは、生成されたフォームにオプションとして表示されます。
ユーザーはラジオ・ボタンを選択または選択解除し、その設定をデータベースに保存できます。

- DataCombobox: このデータ・フィールドは、生成されたフォームにリストとして表示されます。
ユーザーはリストから項目を選択し、その選択をデータベースに保存できます。

- DisplayOnlyField: このデータ・フィールドにはユーザーが値を入力できません。このタイプのフィールドには、他のフィールドの値に基づいてデータが表示されるのみです。

デフォルト値

この値は、フォームの生成後、次のシナリオで他のデフォルト値が指定されていない場合に、関連付けられているデータ・フィールドに表示されます。

- フォーム・フィールドにアタッチされている事前移入アダプタが実行されています。

- あるプロセスに割り当てられているカスタム・フォームのフィールドと別のプロセスに関連付けられているカスタム・フォームのフィールドの間に、データ・フローが存在します。

- 組織に対してリクエストされたリソース・オブジェクトにカスタム・フォームがアタッチされています。さらに、このカスタム・フォームのいずれかのフィールドにデフォルト値が関連付けられています。パスワード・フィールドおよび暗号化されたフィールドにはデフォルト値を指定しないことをお薦めします。

順序

「順序」フィールドは、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では使用されません。

アプリケーション・プロファイル

このチェック・ボックスは、このフォームに関連付けられているリソースがユーザーにプロビジョニングされ、「有効」ステータスになった後、このフィールドの最新の値を「ユーザー」フォームの「オブジェクト・プロファイル」タブに表示するかどうかを示します。

このチェック・ボックスを選択すると、このフィールドのラベルおよび値は、リソースがプロビジョニングされたユーザーの「ユーザー」フォームの「オブジェクト・プロファイル」タブに表示されます。

暗号化

このチェック・ボックスは、関連付けられているデータ・フィールドに表示される情報をサーバーとクライアントの間で転送するときに暗号化するかどうかを指定します。

このチェック・ボックスを選択すると、データ・フィールドに表示される情報がサーバーとクライアントの間で転送されるときに暗号化されます。

6.2.1.1 フォームへのデータ・フィールドの追加

フォームにデータ・フィールドを追加するには、次の手順を実行します。

注意:

パスワード・フィールドは、デフォルトで暗号化されます。パスワード・フィールド・タイプのデータ・フィールドを作成した場合、値はアスタリスク(*)文字として表示され、データはデータベースで暗号化されます。

1. 「追加列」タブで、「追加」をクリックします。
「追加列」タブに空白行が表示されます。

2. 「名前」フィールドに、データベースに表示されOracle Identity Managerによって認識されるデータ・フィールドの名前を入力します。

注意:

この名前は、<TABLENAME_>接頭辞の後にデータ・フィールドの名前が続きます。

たとえば、「表名」フィールドに表示される名前がUD_PASSWORDでデータ・フィールドの名前がUSERNAMEの場合、データベースに表示されてOracle Identity Managerによって認識されるデータ・フィールド名はUD_PASSWORD_USERNAMEです。

3. バリアント型参照フィールドをダブルクリックします。
表示される「参照」ウィンドウで、データ・フィールドのバリアント型を選択します。

現在は、データ・フィールドに9つのバリアント型(Byte、Double、Date、バイト配列、Boolean、Long、String、ShortおよびInteger)のいずれかを指定できます。

4. 「長さ」フィールドに、データ・フィールドの長さ(文字数)を入力します。

5. フィールド・ラベル・フィールドに、データ・フィールドに関連付けるラベルを入力します。
このラベルは、Oracle Identity Managerによって生成されたフォームのデータ・フィールドの横に表示されます。

6. 「フィールド・タイプ」参照フィールドをダブルクリックします。
表示される「参照」ダイアログ・ボックスで、データ・フィールドのデータ型を選択します。現在は、データ・フィールドに9つのデータ型(テキスト・フィールド、参照フィールド、テキスト領域、ITリソース参照フィールド、日付フィールド、チェック・ボックス、パスワード・フィールド、ラジオ・ボタンおよびボックス)のいずれかを指定できます。

関連項目:

データ型の詳細は、表6-2を参照してください。

7. 「デフォルト値」フィールドに、フォームの生成後、他のデフォルト値が指定されていない場合に関連付けられているデータ・フィールドに表示される値を入力します。

関連項目:

デフォルト値を設定できるシナリオの詳細は、表6-2を参照してください。

8. 「順序」フィールドに、生成されたフォーム上でのデータ・フィールドの位置を表す順序番号を入力します。
たとえば、順序番号が2のデータ・フィールドは、順序番号が1のデータ・フィールドの下に表示されます。

9. 「デフォルト値」フィールドに表示される値よりも、特定の組織またはユーザーの値が優先されるようにする場合は、「アプリケーション・プロファイル」チェック・ボックスを選択します。それ以外の場合は、ステップ10に進みます。

10. データ・フィールドに表示される情報をクライアントとサーバーの間で転送するときに暗号化するには、「暗号化」チェック・ボックスを選択します。そうでない場合は、手順11に進みます。

11. 「保存」をクリックします。

6.2.1.2 フォームからのデータ・フィールドの削除

フォームからデータ・フィールドを削除するには、次の手順を実行します。

注意:

新しいフィールドを追加するときに、削除されたフィールドと同じ名前をそのフィールドに割り当てると、新しいフィールドのバリアント型(データ型)は削除されたフィールドの型と同じままになります。たとえば、Stringバリアント型が適用されているAddr1フィールドを削除したとします。同じ名前のフィールドを作成し、そのフィールドにBooleanバリアント型を適用します。ここで新しいAddr1フィールドを追加したフォームを表示または使用すると、フィールドのバリアント型はBooleanではなくStringになります。

1. 第6.2.4.3項「データ・フィールドからのプロパティおよびプロパティ値の削除」の手順に従って、削除するデータ・フィールドに関連付けられているすべてのプロパティを削除します。

2. 削除するデータ・フィールドを選択します。

3. 「削除」をクリックします。
データ・フィールドがフォームから削除されます。

新しいフィールドを追加するときに、削除されたフィールドと同じ名前をそのフィールドに割り当てると、新しいフィールドのバリアント型(データ型)は削除されたフィールドの型と同じままになります。たとえば、Stringバリアント型が適用されているAddr1フィールドを削除したとします。同じ名前のフィールドを作成し、そのフィールドにBooleanバリアント型を適用します。ここで新しいAddr1フィールドを追加したフォームを表示または使用すると、フィールドのバリアント型はBooleanではなくStringになります。

6.2.1.3 AccountPasswordプロパティの値の設定

AccountPasswordプロパティの値をtrueに設定する手順は次のとおりです。

1. 「フォーム・デザイナ」フォームでパスワードを作成します。

2. 「プロパティ」タブをクリックします。

3. パスワード・フィールドを選択して、「プロパティの追加」をクリックします。

4. 「プロパティ名」リストから、「AccountPassword」を選択します。

5. 「プロパティ値」フィールドに、trueと入力します。

6. 「保存」をクリックします。

6.2.2子表タブ

「フォーム・デザイナ」フォームを使用して作成された複数のフォームに同じデータ・フィールドを追加する必要がある場合があります。これを行うには、次の2つの方法があります。

- フォームの「追加列」タブを使用して、データ・フィールドを各フォームに手動で追加できます。

- データ・フィールドをグループ化し、1つのフォーム名で保存できます。その後、これらのデータ・フィールドを必要とする各フォームにこのフォームを割り当てることができます。

別のフォームが必要とするデータ・フィールドが含まれているフォームは、子表と呼ばれます。

子表をフォームに割り当てると、ユーザーの効率が向上します。子表を使用しない場合は、データ・フィールドを必要とするすべてのフォームについて、各フィールドにパラメータを設定する必要があります。たとえば、5つのフォームに同じデータ・フィールドが必要な場合、このフィールドのパラメータを5回(フォームごとに1回)設定する必要があります。

あるフォーム使用している子表を別のフォームに適用する場合は、Design Consoleを使用します。最初のフォームから子表を削除し、それをターゲット・フォームに割り当てます。このように、「フォーム・デザイナ」フォームで作成されたすべてのフォームで、1つのフォームに割り当てた子表を再利用できます。

子表の列で次のいずれかのアクションを実行するようにOracle Identity Managerを構成できます。

- 挿入: 子表の指定した列に新しい値が追加されます。

- 更新: 子表の対応する列の既存の値が変更されます。

- 削除: 子表の指定した列から値が削除されます。

関連項目:

子表の列に対して値を挿入、編集または削除するようにOracle Identity Managerを設定する方法の詳細は、第5.3項「「プロセス定義」フォーム」を参照してください。

たとえば、UD_SOUTH子表を「Results of 1Q 2004 Sales」フォーム(表名UD_SALES2)に割り当てるとします。このフォームを開始すると、UD_SOUTH子表のデータ・フィールドがフォームに表示されます。

次の各項で、フォームに子表を割り当てる方法およびフォームから子表を削除する方法について説明します。

注意:

子表で表されるフォームがアクティブになっていない場合は、そのフォームを親フォームに割り当てることができません。

6.2.2.1 フォームへの子表の割当て

フォームに子表を割り当てるには、次の手順を実行します。

注意:

子表で表されるフォームがアクティブになっている場合、そのフォームは「割当て」ウィンドウに表示されず、親フォームに割り当てることができません。

1. 「割当て」をクリックします。
「割当て」ウィンドウが表示されます。

2. このウィンドウで、子表を選択してフォームに割り当てます。

3. 「OK」をクリックします。
選択した子表がフォームに割り当てられます。

6.2.2.2 フォームからの子表の削除

フォームから子表を削除するには、次の手順を実行します。

1. 削除する子表を選択します。

2. 「削除」をクリックします。
子表がフォームから削除されます。

6.2.3 オブジェクト権限タブ

このタブを使用して、カスタム・フォームのインスタンス化時にそのフォームに対して情報を追加、変更および削除できるユーザー・グループを選択します。

「挿入の許可」チェック・ボックスが選択されている場合、対応するユーザー・グループはユーザー作成フォームのフィールドに情報を追加できます。このチェック・ボックスが選択されていない場合、ユーザー・グループはこのフォームのフィールドに情報を移入できません。

「更新の許可」チェック・ボックスが選択されている場合、関連付けられているユーザー・グループはユーザー作成フォームのフィールドの既存情報を変更できます。このチェック・ボックスが選択されていない場合、ユーザー・グループはこのフォームのフィールドを編集できません。

「削除の許可」チェック・ボックスが選択されている場合、対応するユーザー・グループはユーザー作成フォームのインスタンス化時にデータを削除できます。このチェック・ボックスが選択されていない場合、ユーザー・グループは(インスタンス化時に)このフォームのフィールドからデータを削除できません。

SYSTEM ADMINISTRATORSユーザー・グループが「Results of 1Q 2004 Sales」フォーム(「表名」フィールドでUD_SALES2という名前で示されている)に表示される情報を作成、変更および削除できるとします。IT DEPARTMENTユーザー・グループは、このフォームのレコードの削除のみ可能です(「挿入の許可」および「更新の許可」チェック・ボックスが選択されていない)。HR DEPARTMENTユーザー・グループは、「Results of 1Q 2004 Sales」フォーム内で情報を作成および変更できます。ただし、「削除の許可」チェック・ボックスが選択されていないため、このユーザー・グループはこの情報を削除できません。

次の項で、ユーザー作成フォームにユーザー・グループを割り当てる方法およびユーザー作成フォームからユーザー・グループを削除する方法について説明します。

6.2.3.1 ユーザー作成フォームへのユーザー・グループの割当て

ユーザー作成フォームにユーザー・グループを割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. ユーザー・グループを選択し、ユーザーが作成したフォームに割り当てます。

3. 「OK」をクリックします。
ユーザー・グループがオブジェクト権限タブに表示されます。

4. このユーザー・グループがユーザー作成フォームのレコードに情報を追加できないようにする場合は、対応する「挿入の許可」チェック・ボックスをダブルクリックします。それ以外の場合は、手順5に進みます。

5. このユーザー・グループがユーザー作成フォームのレコードの情報を変更できないようにする場合は、対応する「更新の許可」チェック・ボックスをダブルクリックします。そうでない場合は、手順6に進みます。

6. このユーザー・グループがユーザー作成フォームのレコードを削除できないようにする場合は、対応する「削除の許可」チェック・ボックスをダブルクリックします。それ以外の場合は、手順7に進みます。

7. 「保存」をクリックします。

ユーザー・グループがユーザー作成フォームに割り当てられます。

6.2.3.2 ユーザー作成フォームからのユーザー・グループの削除

ユーザー作成フォームからユーザー・グループを削除するには、次の手順を実行します。

1. 削除するユーザー・グループを選択します。

2. 「削除」をクリックします。
ユーザー・グループがユーザー作成フォームから削除されます。

6.2.4 「プロパティ」タブ

「フォーム・デザイナ」フォームの「プロパティ」タブを使用して、「フォーム・デザイナ」フォームで作成されたフォームに表示されるデータ・フィールドにプロパティおよびプロパティ値を割り当てます。

たとえば、「Results of 1Q 2004 Sales」フォームに2つのデータ・フィールド「User Name」および「Password」があるとします。各データ・フィールドのプロパティは次のとおりです。

- 必須: 生成されたフォームを保存するためにデータ・フィールドにデータを移入する必要があるかどうかを指定します。「必須」プロパティのデフォルト値はfalseです。

- 表示フィールド: Oracle Identity Managerによってフォームが生成された後、データ・フィールドをフォームに表示するかどうかを指定します。「表示フィールド」プロパティのデフォルト値は「true」です。

両方のデータ・フィールドの「必須」および「表示フィールド」プロパティの値が「true」の場合、「Results of 1Q 2004 Sales」フォームが生成されると、これらの両方のデータ・フィールドが表示されます。さらに、フォームを保存するには各フィールドにデータを移入する必要があります。

次の各項で、データ・フィールドにプロパティおよびプロパティ値を追加する方法およびデータ・フィールドからプロパティおよびプロパティ値を削除する方法について説明します。

注意:

「プロパティ」タブは、「追加列」タブを使用してフォームのデータ・フィールドを作成するまでグレー表示になります。

選択できるプロパティおよびプロパティ値の詳細は、ルール要素、変数、データ型およびシステム・プロパティに関する説明を参照してください。

6.2.4.1 データ・フィールドへのプロパティおよびプロパティ値の追加

データ・フィールドにプロパティおよびプロパティ値を追加するには、次の手順を実行します。

1. プロパティおよびプロパティ値を追加するデータ・フィールドを選択します。

2. 「プロパティの追加」をクリックします。
図6-2に示す「プロパティの追加」ダイアログ・ボックスが表示されます。

図6-2 「プロパティの追加」ダイアログ・ボックス

注意:

「列名」フィールドおよび「列の型」フィールドに表示されるテキストは、選択したデータ・フィールドの名前および型です。

この例では、「User Name」データ・フィールドが選択されています(「列名」フィールドにUser Nameと表示されています)。さらに、このフィールドのデータ型はテキスト・フィールドです。

表6-3に、「プロパティの追加」ダイアログ・ボックスのフィールドを示します。

表6-3 「プロパティの追加」ダイアログ・ボックスのフィールド

名前

説明

列名

データ・フィールドの名前

列の型

データ・フィールドのデータ型

プロパティ名

このボックスで、データ・フィールドのプロパティを選択します。

プロパティ値

このフィールドに、「プロパティ名」ボックスに表示されたプロパティに関連付けるプロパティ値を入力します。

注意:

「プロパティ名」ボックスに表示されるメニュー項目には、選択されたデータ・フィールドのデータ型が反映されます。

3. データ・フィールドに追加するプロパティおよびプロパティ値のパラメータを設定します。図6-3に、値が入力された「プロパティの追加」ダイアログ・ボックスを示します。

図6-3 値が入力された「プロパティの追加」ダイアログ・ボックス

この例では、「User Name」データ・フィールドのRequiredプロパティの値がtrueに設定されているため、関連付けられているフォームが作成されたら、このフィールドにデータを移入する必要があります。このようにしない場合は、フォームを保存できません。

関連項目:

選択するパラメータおよびプロパティ値の詳細は、ルール要素、変数、データ型およびシステム・プロパティに関する説明を参照してください。

4. 「プロパティの追加」ウィンドウのツールバーで「保存」をクリックします。

5. 「閉じる」をクリックします。
プロパティおよびプロパティ値がデータ・フィールドに追加されます。

6.2.4.2 カスタマイズされた参照問合せのプロパティおよびプロパティ値の追加

カスタマイズされた参照問合せのプロパティおよびプロパティ値を追加するには、次の手順を実行します。

1. プロパティおよびプロパティ値を追加するデータ・フィールドを選択します。

2. 「プロパティの追加」をクリックします。
図6-4に示す「プロパティの追加」ダイアログ・ボックスが表示されます。

図6-4 「プロパティの追加」ダイアログ・ボックス

注意:

「列名」フィールドおよび「列の型」フィールドに表示されるテキストは、(「フォーム・デザイナ」の「プロパティ」タブで)選択したデータ・フィールドの名前および型です。

この例では、「Name」データ・フィールドが選択されています(「列名」フィールドにNameと表示されています)。さらに、このフィールドのデータ型は参照フィールドです。

「プロパティの追加」ダイアログ・ボックスのボックスは、カスタム参照問合せのWHERE句を作成するのに役立ちます。(メニューから)各ボックスの値を選択すると、カスタム参照問合せにWHERE句が追加されます。

表6-4に、「プロパティの追加」ダイアログ・ボックスのリージョンを示します。最初は、すべてのフィールドがグレー表示されています。参照問合せを定義して「保存」をクリックすると、フィールドがアクティブになります。

表6-4 「プロパティの追加」ダイアログ・ボックスのフィールド

名前

説明

列名

データ・フィールドの名前

列の型

データ・フィールドのデータ型

プロパティ名

このリストから、データ・フィールドのプロパティを選択します。

プロパティ値

このフィールドに、「プロパティ名」ボックスに表示されたプロパティに関連付けるプロパティ値を入力します。

参照問合せの場合、問合せで参照されデータベースによって認識されるOracle Identity Managerのフォームとフィールドの両方を指定する必要があります。

たとえば、Oracle Identity Managerがユーザーのログインを参照する場合、「プロパティ値」フィールドにselect usr_key fromusrと入力します。「保存」をクリックすると、表のすべての列を含む「フィルタ列」がアクティブになります。

フィルタ列

これは、参照問合せで参照されるOracle Identity Managerフォームのフィールドであり、データベースによって認識されます。このフィールドには、「プロパティ値」フィールドで指定された表のすべての列が移入されます。問合せで複数の表が使用されている場合は、すべての表が表示されます。

たとえば、usr.USR_LOGINは、Oracle Identity Managerが参照問合せで「ユーザー」フォームの「ユーザー・ログイン」フィールドを参照することを意味します。

ソース

「フィルタ列」で変数を選択すると、「ソース」フィールドに考えられるすべての値のソースが移入されます。このフィールドの値のリストは、参照フィールドが定義されているフォームのタイプによって異なります。たとえば、参照問合せがオブジェクト・フォームの場合とプロセス・フォームの場合とでは、表示されるリストが異なります。「ソース」フィールドは、「フィルタ列」ボックスに表示される値のわかりやすい名前です。

たとえば、「リクエスタ情報」は、「フィルタ列」値のusr.USR部分を参照します。

フィールド

このフィールドには、「ソース」フィールドで選択された値に基づいてデータが移入されます。このフィールドを使用して、列名に必要なSELECT文を作成します。

たとえば、「ユーザー・ログイン」は、「フィルタ列」値の_LOGIN部分に対応します。

注意:

「プロパティ名」ボックスに表示されるメニュー項目は、選択されたデータ・フィールドのデータ型を示します。

「プロパティの追加」ダイアログ・ボックスの「ソース」および「フィールド」ボックスは、「プロパティ名」に「参照問合せ」が表示される場合にのみ適用できます。

3. データ・フィールドに追加するプロパティおよびプロパティ値のパラメータを設定します。図6-5に、「プロパティの編集」ダイアログ・ボックスを示します。

図6-5 「プロパティの編集」ダイアログ・ボックス

6.2.4.3 データ・フィールドからのプロパティおよびプロパティ値の削除

データ・フィールドからプロパティおよびプロパティ値を削除するには、次の手順を実行します。

1. 削除するプロパティおよびプロパティ値を選択します。

2. 「プロパティの削除」をクリックします。
プロパティおよび関連付けられている値がデータ・フィールドから削除されます。

6.2.5 「管理者」タブ

このタブは、ユーザーによって「フォーム・デザイナ」フォームを使用して作成されたフォームの現行レコードを表示、変更および削除できるユーザー・グループを選択するために使用します。

「書込み」チェック・ボックスが選択されている場合、対応するユーザー・グループはフォームの現行レコードの情報を表示および変更できます。このチェック・ボックスが選択されていない場合、ユーザー・グループはこのレコードの情報を表示または編集できません。

「削除」チェック・ボックスが選択されている場合、関連付けられているユーザー・グループはフォームの現行レコードから情報を削除できます。このチェック・ボックスが選択されていない場合、ユーザー・グループはこのレコードから情報を削除できません。

次の各項で、ユーザー作成フォームのレコードに対する管理権限をユーザー・グループに割り当てる方法およびその権限をユーザー・グループから削除する方法について説明します。

6.2.5.1 ユーザー作成フォームのレコードに対する権限のユーザー・グループへの割当て

ユーザー作成フォームのレコードに対する管理権限をユーザー・グループに割り当てるには、次の手順を実行します。

1. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

2. ユーザー・グループを選択し、ユーザー作成フォームのレコードに割り当てます。

3. 「OK」をクリックします。
ユーザー・グループが「管理者」タブに表示されます。

4. このユーザー・グループがユーザー作成フォームの現行レコードの情報を作成および変更できるようにする場合は、対応する「書込み」チェック・ボックスをダブルクリックします。それ以外の場合は、手順5に進みます。

5. このユーザー・グループがユーザー作成フォームの現行レコードから情報を削除できるようにする場合は、対応する「削除」チェック・ボックスをダブルクリックします。そうでない場合は、手順6に進みます。

6. 「保存」をクリックします。

これで、ユーザー作成フォームのこのレコードに対する管理権限がユーザー・グループに割り当てられました。

6.2.5.2 ユーザー作成フォームのレコードに対するユーザー・グループ権限の削除

ユーザー作成フォームのレコードに対する管理権限をユーザー・グループから削除するには、次の手順を実行します。

1. 削除するユーザー・グループを選択します。

2. 「削除」をクリックします。
ユーザー・グループにユーザー作成フォームのこのレコードに対する管理権限がなくなりました。

6.2.6 使用方法タブ

このタブでは、現行フォームが割り当てられているリソース・オブジェクトおよびプロセスを確認できます。

たとえば、「Solaris」フォーム(「表名」フィールドでUD_SOLARISという名前で示されている)が作成され、Solarisのリソース・オブジェクトとプロビジョニング・プロセスの両方に割り当てられています。

注意:

表名は、接頭辞UD_の後にフォーム名が続きます。この例では、フォーム名がSolarisであるため、表名はUD_SOLARISです。

このタブに情報が移入されるのは、「バージョンをアクティブにする」をクリックした後のみです。

6.2.7 「事前移入」タブ

このタブを使用して、次の操作を実行します。

- 事前移入アダプタをユーザー作成フォームのデータ・フィールドにアタッチします。

- このアダプタを実行して指定されたデータ・フィールドに情報を移入するかどうかを決定するルールを選択します。

- 選択したルールの優先度値を設定します。

- 事前移入アダプタのアダプタ変数を正しい場所にマップします。

関連項目:

事前移入アダプタ、ユーザー作成フォームのフィールドへの事前移入アダプタのアタッチまたは事前移入アダプタの変数のマップの詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

6.2.8 デフォルト列タブ

「フォーム・デザイナ」フォームを使用して作成されたフォームは、2つのタイプのデータ・フィールドで構成されます。

- (「追加列」タブを使用して)ユーザーによって作成されたデータ・フィールド

- Oracle Identity Managerによって作成され、フォームの作成後にフォームに追加されたデータ・フィールド

デフォルト列タブでは、ユーザー作成フォームにデフォルトで追加されるデータ・フィールドの名前、バリアント型および長さを確認できます。その結果、これらのデータ・フィールドを表示することによって、SQL*Plusまたは同様のデータベース・アプリケーションを起動しないでこのタイプのフォームのデータ・フィールドをすべて確認できます。

6.2.9 「ユーザー定義フィールド」タブ

このタブを使用して、「フォーム・デザイナ」フォームで作成されたユーザー定義フィールドを表示したり、そのフィールドにアクセスします。作成されたユーザー定義フィールドは、このタブに表示され、データを受け入れたり提供できます。

6.3 フォームの追加バージョンの作成

フォームを作成し、「フォーム・デザイナ」フォームのタブに情報を移入して、フォームが割り当てられるプロセスまたはリソース・オブジェクトを使用して動作するようにする場合、フォームの別のバージョンを作成する必要があることがあります。このようにすると、フォームの元のバージョンを変更することなくこのバージョンを変更できます。

フォームの追加バージョンを作成するには、次の手順を実行します。

1. 「フォーム・デザイナ」フォームを開きます。

2. 別のバージョンを作成する特定のフォームを検索します。

3. 現行バージョン・ボックスをクリックします。
表示されたドロップダウン・メニューから、追加バージョンを作成するフォームのバージョンを選択します。

4. 新しいバージョンの作成ボタンをクリックします。
新しいバージョンの作成ウィンドウが表示されます。

5. 「ラベル」フィールドに、フォームの追加バージョンの名前を入力します。

6. 新しいバージョンの作成ウィンドウのツールバーで「保存」をクリックします。

7. このツールバーで「閉じる」をクリックします。
フォームの追加バージョンが作成されます。現行バージョン・ボックスをクリックすると、手順5の「ラベル」フィールドに入力したバージョン名が表示されます。このバージョンを選択すると、フォームの元のバージョンを変更しないで「フォーム・デザイナ」フォームのタブに情報を移入できます。

新しいフォーム・バージョンを使用してすべてのユーザーを管理する場合、新しいフォーム・バージョンがアクティブになった後にフォーム・バージョン制御(FVC)ユーティリティを実行します。FVCユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのフォーム・バージョン制御ユーティリティの使用方法に関する項を参照してください。

7 参照定義およびRemote Managerの管理

この項では、Design Consoleを使用してOracle Identity Managerを管理する方法について説明します。内容は次のとおりです。

- 概要

- 「参照定義」フォーム

- 「Remote Manager」フォーム

7.1 概要

Design Consoleの「管理」フォルダには、システム管理者がOracle Identity Manager管理機能を管理するためのツールがあります。このフォルダには、次のフォームが含まれます。

- 参照定義: このフォームは、参照定義の作成と管理に使用します。参照定義とは、参照フィールドと、その参照フィールドからアクセスできる値を示すものです。

注意:

Oracle Identity Managerでは、Oracle Identity System Administrationを使用して参照を作成および管理することをお薦めします。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の参照の管理に関する説明を参照してください。

- Remote Manager: このフォームは、Oracle Identity Managerがサード・パーティのプログラムとの通信に使用するサーバーの情報を表示するために使用します。これらのサーバーは、Remote Managerと呼ばれます。

7.2 「参照定義」フォーム

参照定義は、次のいずれかを表します。

- テキスト・フィールドの名前と説明

- 参照フィールド、および参照フィールドをダブルクリックしてその参照フィールドからアクセス可能な値

- ボックス、およびそのボックスから選択可能なコマンド

テキスト・フィールド、参照フィールドまたはボックスに関する情報が含まれたこれらの項目は、参照値と呼ばれます。ユーザーは、次の2つのいずれかの場所から参照定義にアクセスできます。

- Oracle Identity Managerとともにパッケージ化されているフォームまたはタブ

- 「フォーム・デザイナ」フォームを使用して構築されたユーザー定義のフォームまたはタブ

図7-1に示す「参照定義」フォームは、Design Consoleの「管理」フォルダにあります。このフォームを使用して、参照定義を作成および管理します。

図7-1 「参照定義」フォーム

表7-1に、「参照定義」フォームのデータ・フィールドを示します。

表7-1 「参照定義」フォームのフィールド

フィールド名

説明

コード

参照定義の名前。

フィールド

テキスト・フィールド、参照フィールドまたはボックス・フィールドにアクセスできるフォームまたはタブの表の列名。

参照タイプ/フィールド・タイプ

このオプションでは、参照定義がテキスト・フィールド、参照フィールドまたはボックスのいずれを表すかを指定します。

フィールド・タイプ・オプションを選択した場合、参照定義はテキスト・フィールドを表します。

「参照タイプ」オプションを選択した場合、参照定義は参照フィールドまたはボックスのいずれかを表し、さらにその参照フィールドまたはボックスからアクセス可能な値を表します。

注意: Oracle Identity Managerとともにパッケージ化されているフォームまたはタブの場合、参照定義は参照フィールドまたはボックスのいずれかとしてすでに設定されています。これは変更できません。ただし、参照フィールドまたはボックスからアクセスできる値を追加または変更することはできます。

ユーザー定義のフォームまたはタブの場合は、ユーザーが「フォーム・デザイナ」フォームの追加列タブを使用して、参照定義が参照フィールドまたはボックスのいずれを表すかを指定します。

参照定義のデータ型指定の詳細は、「追加列タブ」を参照してください。

必須

このチェック・ボックスを選択すると、参照定義が必須として指定されます。その結果、その参照定義が表すフィールドまたはボックスにデータが入力されるまで、Oracle Identity Managerでは対応するフォームまたはタブの内容のデータベースへの保存が許可されません。

グループ

参照定義を表示するOracle Identity Managerフォームまたはユーザー定義フォームの名前。

次の項では、参照定義を作成する方法について説明します。

7.2.1 参照定義の作成

参照定義を作成するには、次の手順を実行します。

1. 「参照定義」フォームを開きます。

2. 「コード」フィールドに、参照定義の名前を入力します。

3. 「フィールド」フィールドに、テキスト・フィールド、参照フィールドまたはボックス・フィールドにアクセスできるOracle Identity Managerまたはユーザー作成のフォームまたはタブの表の列名を入力します。

4. 参照定義が参照フィールドまたはボックスを表す場合は、参照タイプ・オプションを選択します。
参照定義がテキスト・フィールドを表す場合は、フィールド・タイプ・オプションを選択します。

5. オプション。参照定義が表すフィールドまたはボックスにデータが入力された場合にのみこのフォームまたはタブの内容を保存するには、「必須」チェック・ボックスを選択します。そうでない場合は、手順6に進みます。

6. 「グループ」フィールドに、参照定義を表示するOracle Identity Managerフォームまたはユーザー定義フォームの名前を入力します。

「コード」、「フィールド」および「グループ」フィールドに入力するテキストは、ネーミング規則に従っている必要があります。

関連項目:

ネーミング規則の詳細は、「「参照定義」フォーム」を参照してください。

7. 「保存」をクリックします。
参照定義が作成されます。関連付けられたテキスト・フィールド、参照フィールドまたはボックスが、指定したOracle Identity Managerまたはユーザー定義のフォームまたはタブに表示されます。

7.2.2 参照コード情報タブ

参照コード情報タブは、「参照定義」フォームの下半分にあります。このタブは、選択した参照定義の詳細情報を作成および管理するために使用します。この情報には、参照定義に関連する値の名前、説明、言語コードおよび国コードが含まれます。これらの項目は参照値と呼ばれます。

次の手順では、参照値を作成、変更および削除する方法について説明します。

7.2.2.1 参照値の作成および変更

参照値を作成または変更するには、次の手順を実行します。

注意:

国際化の目的で、参照値には言語コードと国コードの両方を指定する必要があります。

新しい参照定義を作成する場合は、参照定義を保存してから参照値を追加してください。

1. 「参照定義」フォームを開きます。

2. 参照定義にアクセスします。

3. 参照値を作成する場合は、「追加」をクリックします。
参照コード情報タブに空白行が表示されます。

参照値を変更する場合は、編集する参照値を選択します。

4. コード・キー・フィールドで情報を追加または編集します。
このフィールドには参照値の名前が含まれています。

また、参照タイプ・オプションが選択されている場合、このフィールドは、ユーザーが選択を行ったときに参照フィールドまたはボックスに表示される内容も表します。

5. デコード・フィールドで情報を追加または編集します。
このフィールドには参照値の説明が含まれています。

注意:

このデコード値は、人が読むためのフィールドの説明です。このデコード値は、プロビジョニングに使用される実際のコード値です。たとえば、デコード値はLDAPグループ名、エンコード値はLDAPグループGUIDとなります。

参照タイプ・オプションが選択されている場合、このフィールドは次のいずれかも表します。

- ユーザーが対応する参照フィールドをダブルクリックした後に参照ウィンドウに表示される項目

- 関連付けられたボックスに表示されるコマンド

6. 「保存」をクリックします。
これで、作成または変更した参照値に、入力した設定が反映されます。

7.2.2.2 参照値の削除

参照値を削除するには、次の手順を実行します。

注意:

参照値を削除すると、その参照が表す内容によっては問題が発生する場合があります。たとえば、参照値が権限を表しており、それを削除する場合は、様々な場所(その権限が含まれているアクセス・ポリシーや、その権限が付与されているユーザー・アカウントなど)から削除する必要があります。このため、参照値を削除する前に、考えられる影響をすべて確認することをお薦めします。

1. 「参照定義」フォームを開きます。

2. 参照定義を検索します。

3. 削除する参照値を選択します。

4. 「削除」をクリックします。選択した参照値が削除されます。

7.2.3 ユーザーのチャレンジ質問の構成

「参照定義」フォームを使用して、ユーザーのチャレンジ質問を構成できます。これらのチャレンジ質問は、ユーザーがパスワードを忘れ、再取得しようとするときに表示されます。ユーザーは、パスワードの作成時に指定したのと同じ回答を入力する必要があります。

ユーザーのチャレンジ質問を構成するには、次の手順を実行します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」、「参照定義」に移動します。

3. チャレンジ質問の参照、つまりlookup Code = Lookup.WebClient.Questionsを検索します。

4. 参照コード情報タブで、コード・キー・フィールドとデコード・フィールドに適切な値を入力して、質問を追加します。

5. 「追加」をクリックします。

6. このキーをカスタム・リソース・バンドルに追加します。

7.3 「Remote Manager」フォーム

Remote Managerは軽量のネットワーク・サーバーであり、ネットワークで通信できないAPIを持つターゲット・システムや、ネットワーク対応であってもセキュアではないターゲット・システムとの統合を可能にします。Remote Managerはターゲット・システム上でサーバーとして動作し、Oracle Identity Managerサーバーはそのクライアントとして動作します。Oracle Identity ManagerサーバーはRemote Managerに対するリクエストを送信して、ターゲット・システム自体でターゲット・システムAPIをインスタンス化し、ターゲット・システムにかわってメソッドを起動します。

図7-2に示す「Remote Manager」フォームは、Design Consoleの「管理」フォルダにあります。次の情報が表示されます。

- Oracle Identity Managerと通信するRemote Managerの名前およびIPアドレス

- Remote Managerが稼働しているかどうか

- Oracle Identity Managerで使用できるITリソースを表しているかどうか

図7-2 「Remote Manager」フォーム

この例では、Oracle Identity Managerと通信できる1つのRemote Manager (RManager)のみを定義できます。

このRemote ManagerはOracle Identity Managerとハンドシェイクできますが、「実行中」チェック・ボックスの選択が解除されているため、使用できません。「ITリソース」チェック・ボックスが選択されているため、このRemote ManagerはOracle Identity Managerで使用できるITリソースまたはリソースを表しています。

第III部

コネクタ

この部では、Oracle Identity Manager開発者向けのツールや機能について理解することを目的とし、概念をわかりやすくするための単純な例をいくつか示します。

次の章で構成されます。

- 第8章「アダプタ・ファクトリの使用」

- 第9章「Identity Connector Frameworkの理解」

- 第10章「Javaを使用したアイデンティティ・コネクタの開発」

- 第11章「.NETを使用したアイデンティティ・コネクタの開発」

- 第12章「ICFとOracle Identity Managerの統合」

- 第13章「ICF統合のJava APIの使用」

- 第14章「ICFコネクタの構成」

- 第15章「ICFのベスト・プラクティスおよびFAQの理解」

- 第16章「汎用テクノロジ・コネクタの理解」

- 第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」

- 第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」

- 第19章「汎用テクノロジ・コネクタの作成および管理」

- 第20章「汎用テクノロジ・コネクタのトラブルシューティング」

8 アダプタ・ファクトリの使用

アダプタは、Oracle Identity Managerを他のソフトウェア・ソリューションと統合するためのJavaプログラムです。この章では、「アダプタ・ファクトリ」フォームを使用してアダプタを作成する方法について説明します。これらの項目が含まれます。

- アダプタの概要

- アダプタのタイプ

- アダプタ環境とツール

- アダプタの定義

- 「アダプタ・ファクトリ」フォームのタブ

- アダプタの無効化と再有効化

- アダプタ変数について

- アダプタ・タスクの作成

- アダプタ・タスクの変更

- タスクの順序とネストの変更

- アダプタ・タスクの削除

- レスポンスの使用

- ルール・ジェネレータおよびエンティティ・アダプタのスケジューリング

- ルール・ジェネレータ・アダプタの使用

- エンティティ・アダプタの使用

- タスク割当てアダプタの使用

- 事前移入アダプタの使用

- プロセス・タスク・アダプタの使用

- アダプタ・マッピング情報

- エラー・メッセージの定義

8.1 アダプタの概要

効率を高めるには、Oracle Identity Managerなどのアクセス権管理アプリケーションを他のソフトウェア・ソリューションと統合できる必要があります。このことが必要となるのは、数多くのリソースが提供されているものの、これらのリソースに接続するための単一の統合標準がないためです。

この課題に取り組むために、従来の方法ではすべての統合でサポートされる共通機能を使用します。これを行うには、このコードを記述できる開発者が必要です。また、既存のソフトウェア・リソースの変更や新しいソフトウェア・リソースの追加のたびに、さらにコードを記述する必要があります。

アダプタ・ファクトリは、Oracle Identity Managerによって提供されているコード生成ツールです。これは、統合の課題を簡略化するJavaクラス(アダプタと呼ばれます)を作成する場合に役立ちます。

注意:

Oracle Identity Managerは、JDBCおよびLDAPのJava APIを使用してデータベースやディレクトリ・サーバーなどの外部システムに接続できます。また、C、C++、VB、COM/DCOMなど、その他のすべてのAPIについては、Oracle Identity ManagerがAPIと直接通信できるようにJavaラッパーを作成できます。

リソースには関連するプロビジョニング・プロセスがあり、そのプロセスには様々なタスクが関連付けられます。同様に、各タスクにはアダプタが関連付けられ、必要な操作を実行するためにターゲット・リソースに接続されます。

アダプタには次の利点があります。

- Oracle Identity Managerの内部ロジックと機能を拡張します。

- ソフトウェア・リソースのAPIを使用してそのリソースに接続することにより、リソースのインタフェースとして機能します。

- Oracle Identity Managerと外部システム間の統合を可能にします。

- 手動でコードを記述しなくても生成できます。ただし、Oracle Identity Managerにより、独自のコードを記述してアダプタを作成することが制限されるわけではありません。

- 軽量であり、ニーズに対して固有に対応できます。

- アダプタのすべての定義がリポジトリに格納されているため、簡単に管理できます。このリポジトリはGUIを使用して編集できます。

- あるOracle Identity Managerユーザーが統合に関する専門知識を保持し、別のユーザーがアダプタを管理することが可能です。

- 効率的に変更およびアップグレードできます。

次に示すような様々なタスク用のアダプタを開発できます。

- プロセス・タスク・アダプタにより、Oracle Identity Managerでプロセス・タスクの完了を自動化できます。

- タスク割当てアダプタにより、Oracle Identity Managerでユーザーまたはグループへのプロセス・タスクの割当てを自動化できます。

- ルール・ジェネレータにより、Oracle Identity Managerフォームまたはユーザー定義フォーム(「フォーム・デザイナ」フォームを使用して作成します)のフィールドにビジネス・ルールが組み込まれるため、これらのフィールドに自動的に移入してOracle Identity Managerデータベースに保存できます。

注意:

「フォーム・デザイナ」フォームの詳細は、「プロセス・フォームの開発」を参照してください。

- 事前移入アダプタは、ユーザー作成フォーム・フィールドにアタッチできる特定タイプのルール・ジェネレータ・アダプタです。このタイプのアダプタによって生成されるデータは、自動または手動で表示できます。また、指定のフォーム・フィールドにどの事前移入アダプタを適用するかをOracle Identity Managerで決定するための条件が使用されます。指定のフォーム・フィールドは移入されますが、この情報はOracle Identity Managerデータベースに保存されません。

- エンティティ・アダプタは、Oracle Identity Managerまたはユーザー作成フォーム・フィールドにアタッチされます。Oracle Identity Managerでは、挿入、更新および削除の前後にエンティティ・アダプタがトリガーされます。その後、アダプタがアタッチされたフィールドは自動的に移入され、Oracle Identity Managerデータベースに保存されます。

注意:

Oracle Identity Managerでは、ユーザー、ロール、組織などのエンティティに対して後処理ハンドラを作成することもできます。

8.2 アダプタのタイプ

この項では、5つのアダプタ・タイプについて説明します。

ルール・ジェネレータ・アダプタ

フィールド検証を実行し、Oracle Identity Managerにあらかじめ含まれているフォームまたはOracle Identity Managerユーザーが作成するフォームにデフォルト値を入力するには、特定のビジネス・ルールを適用する必要があります。たとえば、「ユーザー」フォームについて、Oracle Identity Managerでユーザーの名前と姓を連結してユーザーIDを自動的に生成する場合があります。

これを行うには、フォーム内のフィールド値を変更するように設計された特定のタイプのアダプタを作成する必要があります。フォーム・フィールドの値を自動的に生成、変更または検証できるこのタイプのアダプタは、ルール・ジェネレータと呼ばれます。Oracle Identity Managerでは、ルール・ジェネレータは挿入および更新の前にトリガーされます。

このアダプタを作成してフォームにアタッチすると、Oracle Identity Managerによってそのフォームのすべてのレコードのフィールド値が自動的に更新され、この情報がOracle Identity Managerデータベースに保存されます。

アダプタ変数を含むルール・ジェネレータを作成する場合は、これらのアダプタ変数を正しい場所にマップする必要があります。そうしないと、アダプタは機能しません。

このタイプのアダプタをプロビジョニング・プロセスにアタッチすることもできます。プロセスがターゲットのユーザーや組織にプロビジョニングされると、関連付けられたルール・ジェネレータがOracle Identity Managerによってトリガーされます。

プロビジョニング・プロセスに割り当てられているルール・ジェネレータが、プロセスの完了のために必要ではなくなる場合があります。その場合は、ルール・ジェネレータをプロビジョニング・プロセスから削除できます。同様に、ルール・ジェネレータをフォーム・フィールドにアタッチした後で、別のルール・ジェネレータをそのフォーム・フィールドに接続できます。この場合は、最初に、現在フォーム・フィールドにアタッチされているルール・ジェネレータを削除する必要があります。

エンティティ・アダプタ

ルール・ジェネレータ・アダプタと同様に、エンティティ・アダプタは、フォーム・フィールド値の生成、変更または検証を自動化し、この情報をOracle Identity Managerデータベースに保存します。

注意:

Oracle Identity Manager 11g リリース2 (11.1.2.1.0)では、新しいエンティティ・アダプタの作成および既存のエンティティ・アダプタの変更はサポートされていません。ただし、Oracle Identity Managerリリース9.xからアップグレードした場合、既存のエンティティ・アダプタは、これまでどおりに機能し、既存のアダプタの変数マッピングを表示できます。

ルール・ジェネレータとエンティティ・アダプタの違いの一部は、次のとおりです。

- 実行スケジュール。エンティティ・アダプタは、挿入、更新および削除の前後にOracle Identity Managerによってトリガーできます。ルール・ジェネレータ・アダプタは、挿入および更新の前にのみ実行できます。

- 手動でのフィールド値の変更。アダプタによって、エンティティ・アダプタがアタッチされているフォーム・フィールドは移入されます。Oracle Identity Managerユーザーがこの値を編集しても、その変更はエンティティ・アダプタによって上書きされます。その結果、変更はデータベースに保存されません。
同様に、アダプタによって、ルール・ジェネレータ・アダプタがアタッチされているフォーム・フィールドも移入されます。ただし、Oracle Identity Managerユーザーがこの値を編集すると、その変更はルール・ジェネレータ・アダプタによって生成される値よりも優先されます。そのため、変更はデータベースに保存されます。

- フォーム・フィールドの背景色。ルール・ジェネレータがフォーム・フィールドにアタッチされている場合、フィールドはピンクなどの特定の背景色で表示されます。これは、フィールドにルール・ジェネレータがアタッチされていることを視覚的に示しています。これに対し、エンティティ・ジェネレータがフォーム・フィールドにアタッチされている場合、フィールドには固有の背景色はありません。

タスク割当てアダプタ

手動で完了する必要があるプロセス・タスクについて、特定のユーザーまたは特定のロールに属するユーザーへのタスクの割当てを自動化するようにOracle Identity Managerを構成できます。これは、タスク割当てアダプタを使用して行います。タスク割当てアダプタは、特定のユーザーまたはロールへタスクを割り当てるためにのみ使用します。

特定のプロビジョニング・プロセスに関連付けられたタスクをDesign Consoleの「プロセス定義」フォームの「タスク」タブを使用して作成する場合、実行に対してアダプタが取得されるかどうかを決定するルールを選択できます。このルールはDesign Consoleのルール定義フォームで定義されることに注意してください。ルールの例は、「ターゲット・ユーザーの組織名はXYZです」です。このルールが満たされると、対応するタスク割当てが取得されます。ただし、タスク割当ての決定時に複数のルールを定義して使用することができます。複数のルールがある場合、Oracle Identity Managerではタスク割当て機能に優先度が関連付けられて、ルール決定の順序が決定されます。ルールが決定されると、対応するタスク割当てが実行されます。

注意:

つまり、タスク割当てルールによって、Oracle Identity Managerはプロセス・タスクをユーザーまたはルールに割り当てるかどうかを決定できます。タスク割当てアダプタによって、Oracle Identity Managerはどのユーザーまたはロールがプロセス・タスクの割当先になるかを決定できます。

この例では、Oracle Identity ManagerによってAssociate Adapter with Userルールが最初にトリガーされます(優先度が最も高いため)。このルールの条件がTRUEの場合、ルールは成功です。その結果、Oracle Identity Managerによって、関連するタスク割当てアダプタ(Assign Task to Userアダプタ)がプロセス・タスクに関連付けられます。

一方、ルールの条件がFALSEの場合、ルールは失敗です。Oracle Identity Managerによって、次に優先度が高いルールがトリガーされます。このルールが成功すると、Oracle Identity Managerによって、指定のアダプタがターゲット・プロセス・タスクに割り当てられます。

したがって、この例では、Associate Adapter with Userルールが失敗した場合、Oracle Identity ManagerによってAssociate Adapter with Roleルールがトリガーされます。このルールが成功すると、Oracle Identity Managerによって、関連するタスク割当てアダプタ(Assign Task to Roleアダプタ)がプロセス・タスクに関連付けられます。

ルールをタスク割当てアダプタに割り当てた後、このタイプのアダプタにアダプタ変数が含まれる場合、これらの変数を適切な場所にマップする必要があります。そうしないと、アダプタは機能しません。

最終的に、タスク割当てアダプタが無効になるか、Oracle Identity Managerでプロセス・タスクをユーザーまたはグループに割り当てるために不要になった場合は、アダプタをタスクから削除する必要があります。

事前移入アダプタ

ユーザー作成フォームに、Oracle Identity Managerで移入可能なフィールドと、Oracle Identity Managerユーザーがデータを入力する必要があるフィールドの両方が含まれる場合があります。ユーザーがフィールドに入力する情報が、システム生成フィールドに表示されるデータに依存している場合は、最初にOracle Identity Managerによってこのフィールドに移入される必要があります。フォームが表示されたときに、ユーザーはシステム生成データを確認して適切なフィールドに情報を入力できます。

これを実行するには、事前移入アダプタと呼ばれるタイプのルール・ジェネレータを作成します。それをシステム生成フィールドにアタッチすることによって、Oracle Identity Managerでは、Oracle Identity Managerデータベースに保存しなくても適切な情報をこのフィールドに自動的に移入できます。

事前移入アダプタで生成されたデータは、自動的に表示するか手動で入力できます。プロビジョニング・プロセスについて「自動事前移入」チェック・ボックスを選択した場合、この情報はOracle Identity Managerによって自動的に表示されます。このチェック・ボックスが選択されていない場合、Oracle Identity Managerユーザーは事前移入アダプタで生成されるデータの表示を手動で生成する必要があります。これを行うには、フォームをユーザーにプロビジョニングするときに、Webクライアントの直接プロビジョニング・ウィザードのフォーム・セクションにある事前移入ボタンをクリックします。

同じ事前移入アダプタを異なるフォーム・フィールドに対して使用できます。また、複数の事前移入アダプタを特定のフィールドに関連付けるように指定できます。そのため、フォーム・フィールドに対してどの事前移入アダプタを選択する必要があるかをOracle Identity Managerが認識している必要があります。これには、事前移入ルールを使用する必要があります。これらのルールによって、Oracle Identity Managerで1つの事前移入アダプタを選択でき、この事前移入アダプタがフォーム・フィールドに割り当てられると、事前移入アダプタはそのフィールドに関連付けられます。

それぞれの事前移入アダプタには、事前移入ルールが関連付けられています。また、すべてのルールには優先度値があり、Oracle Identity Managerによってその順序でルールがトリガーされます。

たとえば、Rule for Uppercase User IDルールの優先度が最も高いため、Oracle Identity Managerではこのルールを最初にトリガーできます。このルールの条件がTRUEの場合、ルールは成功です。その結果、Oracle Identity Managerによって、関連する事前移入アダプタ(Display Uppercase Letters for User IDアダプタ)が「ユーザーID」フィールドにアタッチされます。

一方、ルールの条件がFALSEの場合、ルールは失敗です。Oracle Identity Managerによって、次に優先度が高いルールがトリガーされます。このルールが成功すると、Oracle Identity Managerによって、関連付けられたアダプタが指定のフィールドにアタッチされます。

したがって、この例では、Rule for Uppercase User IDルールが失敗した場合、Oracle Identity ManagerによってRule for Lowercase User IDルールがトリガーされます。このルールが成功すると、Oracle Identity Managerによって、関連する事前移入アダプタ(Display Lowercase Letters for User IDアダプタ)が「ユーザーID」フィールドにアタッチされます。

ルールを事前移入アダプタに割り当てた後、このタイプのアダプタにアダプタ変数が含まれる場合は、これらの変数を適切な場所にマップする必要があります。そうしないと、アダプタは機能しません。

最終的に、フィールドに関連付けられた事前移入アダプタが有効ではなくなった場合、アダプタをフィールドから削除する必要があります。

プロセス・タスク・アダプタ

プロセス・タスク・アダプタによって、Oracle Identity Managerではプロビジョニング・プロセスでプロセス・タスクを自動的に実行できます。

それぞれのプロセスおよびプロセス・タスクにはステータスがあり、完了の段階を示します。次の表に、プロセスまたはプロセス・タスクのステータスを重要性の高いものから順に示します。

タスク・ステータス

説明

C

完了: このプロセスまたはプロセス・タスクは正常に完了しました。

MC

手動で完了: このプロセス・タスクは、Oracle Identity Managerユーザーによって(つまり、手動で)正常に完了しました。

P

保留: このプロセスまたはプロセス・タスクは完了処理中です。先行するそれぞれのタスクおよびプロセスはすべて完了しています。

PX

取消し保留: このプロセス・タスクは取り消されますが、取り消される前に完了される必要があります。

R

却下: このプロセスまたはプロセス・タスクは、正常に完了していないか承認されていません。却下されたプロセス・タスクのステータスは、「取消」または完了に失敗にのみ変更できます。

S

一時停止: このプロセスまたはプロセス・タスクは一時的に停止しています。

UC

完了に失敗: このプロセス・タスクは、「完了」に設定されています。ただし、以前に却下されたことがあります。

W

待機中: このプロセスまたはプロセス・タスクは、先行するすべてのプロセス・タスクまたはプロセスが完了するまで、完了しません。

X

このプロセスまたはプロセス・タスクは停止しています。ステータスは変更できません。

プロセスのステータス・レベルはそのプロセス・タスクの最も重要なステータス・レベルを表しており、プロセス・タスクが完了しないとプロセスは完了しません。プロセスに3つのプロセス・タスクがあり、各プロセス・タスクのステータス・レベルが異なる場合(「完了」、「待機中」および「却下」)、プロセスが完了するには、3つのプロセス・タスクすべてが完了する必要があります。最高のタスク・ステータス・レベルは「却下」であるため、プロセスのステータス・レベルも「却下」です。

プロセス・タスクは次の方法で管理できます。

- 「組織」フォームまたは「ユーザー」フォームのオブジェクト・プロセス・コンソール・タブまたはOracle Identity Manager Webアプリケーションを使用して、手動で処理できます。

- タスクのいずれか(または複数)が「保留」ステータスになったときに自動的にトリガーされるように、Oracle Identity Managerプロセスを構成できます。

8.3 アダプタ環境とツール

この項は次のトピックで構成されています。

- アダプタ環境の構成

- Remote Manager

- アダプタ・ファクトリ

- アダプタのコンパイル

8.3.1 アダプタ環境の構成

アダプタ・タスクを構成するには、Oracle Identity ManagerがターゲットAPIのJARファイルおよび接続するサード・パーティ・アプリケーションにアクセスできることを確認してください。

アダプタでJavaタスクを使用する場合、適切なJava APIを検索するようにOracle Identity Managerを構成する必要があります。これを行うには、これらのAPIが含まれている.jarファイルをメタデータ・ストア(MDS)に置く必要があります。

関連項目:

Oracle Identity Managerメタデータを変更するユーティリティについては、第36章「カスタマイズ・タイプの理解」を参照してください。

これにより、これらのJava APIに関連付けられたJavaクラスにアクセスして、作成したJavaタスクで使用できるようになります。

Oracle Identity ManagerをJARおよびクラス・ファイルを参照するように構成する手順は、次のとおりです。

1. OIM_HOME/ディレクトリ・パスにあるJavaTasksサブディレクトリを開きます。たとえば、C:\oracle\Xellerate\JavaTasksです。

2. JARファイルをこのサブディレクトリに置きます。このファイルを使用して、サーバーを再起動せずにアダプタ内にJavaタスクを作成できます。

8.3.2 Remote Manager

サード・パーティ・システムと直接通信せずに、プロキシのように動作するOracle Identity Managerコンポーネントを使用する必要がある場合があります。このコンポーネントは、Remote Managerと呼ばれます。

Remote Managerは、次の目的で使用します。

- Oracle Identity Managerを通じた非リモートAPIの呼出し

- セキュアな接続でのSecure Sockets Layer (SSL)をサポートしないAPIの呼出し

Remote Managerを構成するには、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドの説明に従ってください。

また、コネクタ・サーバーでもアクション・スクリプトを実行できます。アイデンティティ・コネクタ・サーバーについては、「Identity Connector Frameworkの理解」を参照してください。

8.3.3 アダプタ・ファクトリ

すでに説明したように、アダプタはOracle Identity Managerユーザーがアダプタ・ファクトリで作成するJavaクラスであり、アダプタ・ファクトリにはDesign Consoleからアクセスします。

アダプタによって、Oracle Identity Managerの内部論理および機能が拡張されます。また、任意のITリソースのAPIに接続することで、そのリソースとの対話が行われます。

アダプタ・ファクトリはOracle Identity Managerで提供されるコード生成ツールであり、これを使用してユーザーはアダプタと呼ばれるJavaクラスを作成できます。図8-1に、Design Consoleの「アダプタ・ファクトリ」フォームを示します。

図8-1 「アダプタ・ファクトリ」フォーム

8.3.4 アダプタのコンパイル

Oracle Identity Managerには、次に示すような様々なコンパイル・オプションがあります。

- 個別のアダプタを1つずつコンパイル

- 一連のアダプタを一度にコンパイル

- Oracle Identity Managerデータベース内のすべてのアダプタを1クリックでコンパイル

8.3.4.1 アダプタの自動コンパイル

デプロイメント・マネージャを使用してコネクタ・ファイルをインポートすると、アダプタが自動的にコンパイルされます。コンパイルされたアダプタのクラス・ファイルは、ファイル・システムではなくOracle Identity Managerデータベースに格納され、そこから実行時にロードされます。次の2つのAPIを使用して、アダプタをプログラムでコンパイルできます。

- public void compileAdapter (String adapterName): このAPIは、1つのアダプタをコンパイルし、コンパイルしたクラス・ファイルをデータベースに格納します。アダプタの名前をパラメータとして使用します。アダプタが見つからない場合、またはエラーが発生した場合は、APIで適切な例外がスローされます。

- public void compileAll: このAPIは、システムのすべてのアダプタをコンパイルします。コンパイル時にエラーが発生した場合は、タイプtcBulkExceptionの例外がスローされます。この例外は、コンパイル時にAPIで発生した個別のすべてのエラーで構成されます。

変更する場合は、アダプタを手動で変更できます。

注意:

XL.CompilerPathシステム・プロパティのJDKディレクトリのパスを設定する必要があります。これを行わないと、デプロイメント・マネージャを使用してXMLファイルをインポートするときに、アダプタ・コンパイル・ステージでエラーが発生します。

システム・プロパティの値の設定の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドのOracle Identity Managerのシステム・プロパティに関する説明を参照してください。

8.3.4.2 アダプタの手動コンパイル

「開発ツール」フォルダに「アダプタ・マネージャ」フォームがあります。これを使用して、複数のアダプタを同時にコンパイルします。

複数のアダプタを手動でコンパイルするには、次の手順を実行します。

1. 「アダプタ・マネージャ」フォームを開きます。
「アダプタ・マネージャ」フォームは、「開発ツール」フォルダにあります。図8-2に示すように、複数のアダプタを同時にコンパイルするために使用します。

図8-2 「アダプタ・マネージャ」フォーム

2. Oracle Identity Managerデータベース内のすべてのアダプタをコンパイルするには、すべてをコンパイル・オプションを選択します。
複数のアダプタをコンパイルするには、コンパイルするアダプタを選択します。次に、選択分をコンパイル・オプションを選択します。

ステータスがOKではないすべてのアダプタをコンパイルするには、以前の失敗分をコンパイル・オプションを選択します。

3. 「起動」ボタンをクリックします。
Oracle Identity Managerにより、手順2で指定した条件に一致するアダプタがコンパイルされます。

ヒント:

Oracle Identity Managerでは、「アダプタ・マネージャ」フォームに表示されるアダプタのレコードを確認し、アダプタの詳細を参照できます。

アダプタのレコードを表示するには、該当するアダプタを選択し、行ヘッダーをダブルクリックするかアダプタを右クリックして、表示されるメニューからアダプタの起動コマンドを選択します。

8.4 アダプタの定義

アダプタを定義するには、次の手順を実行します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「アダプタ・ファクトリ」フォームを開きます。このフォームは、Design Consoleの「開発ツール」フォルダ内にあります。

3. 「アダプタ名」フィールドに、アダプタの名前(Create Solaris Userなど)を入力します。

注意:

アダプタ名には特殊文字を使用できますが、実行時エラーが発生する場合があるため、特殊文字は使用しないことをお薦めします。

4. アダプタ・タイプ参照フィールドをダブルクリックします。
参照ウィンドウが表示され、5つのタイプのOracle Identity Managerアダプタが表示されます。それらは次のとおりです。

- プロセス・タスク

- ルール・ジェネレータ

- 事前移入ルール・ジェネレータ

- エンティティ

- タスク割当て

5. プロセス・タスクを自動化するアダプタを有効にするには、プロセス・タスク(T)を選択します。
ビジネス・ルールをOracle Identity Managerまたはユーザー定義フォーム・フィールドに組み込むには、ルール・ジェネレータ(R)を選択します。たとえば、フォームの「ユーザーID」フィールドについて、ユーザーの名前と姓の頭文字を連結するようにOracle Identity Managerを構成できます。

ユーザーが作成したフォーム・フィールドに、ルール・ジェネレータ・タイプのアダプタをアタッチして、次のことを実行できます。

- アダプタによって生成されたデータを自動または手動で表示します。

- 指定のフォーム・フィールドにどのアダプタを適用するかをOracle Identity Managerで決定できるようにする条件を使用します。

Oracle Identity Managerまたはユーザー定義フォーム・フィールドにアダプタをアタッチし、挿入、更新および削除の前後にOracle Identity Managerでアダプタをトリガーするには、エンティティ(E)を選択します。

プロセス・タスクのユーザーまたはグループへの割当てをアダプタで自動化できるようにするには、タスクの割当て(A)を選択します。

ヒント:

エンティティ・アダプタを作成する場合、ファイル制限が小さいコンピュータ上でアダプタをコンパイルするときに、エラーが生成されることがあります。この問題を回避するには、/etc/security/limits.confファイルでファイル制限を次のように変更します。

soft nofile 4096

hard nofile 4096

その後、Oracle Identity Managerを再起動します。

6. アダプタのタイプ(プロセス・タスク(T)など)を選択します。次に、「OK」をクリックします。

関連項目:

「フォーム・デザイナ」フォームについては、「プロセス・フォームの開発」を参照してください。

7. 「説明」フィールドに、アダプタの説明(「このアダプタは、Solaris環境で新規ユーザーを作成するために使用します」など)を入力します。

8. ツールバーで、「保存」をクリックします。
アダプタはOracle Identity Managerデータベースに格納されます。

8.5 「アダプタ・ファクトリ」フォームのタブ

Design Consoleの「アダプタ・ファクトリ」フォームには、次のタブがあります。

- アダプタ・タスク

- 実行スケジュール

- リソース

- 変数リスト

- 使用状況参照

- レスポンス

8.5.1 アダプタ・タスク

アダプタ・タスク・タブでは、アダプタのアトミック・ファンクション・コールを作成および管理できます。これらのファンクション・コールは、アダプタ・タスクと呼ばれます。

これらのコールはJava文に変換されるため、コールの順序は重要です。つまり、Ifコールの前にElseコールを置いた場合、アダプタはコンパイルされません。また、アダプタを作成するときは、Javaプログラムの論理フローを理解する必要があります。これは、Java構文を使用するプログラムではなくアルゴリズムを記述することに似ています。

8.5.2 実行スケジュール

実行スケジュール・タブでは、Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタをトリガーするタイミングを指定できます。挿入前または更新前(あるいはその両方)にルール・ジェネレータ(アダプタ・タイプR)を実行するように、Oracle Identity Managerをスケジュールできます。エンティティ・アダプタ(アダプタ・タイプE)を挿入、更新および削除の前後に実行するように、Oracle Identity Managerを構成することもできます。

注意:

プロセス・タスクにアタッチされたプロセス・タスク・アダプタとタスク割当てアダプタは、プロセス・タスクのステータスが「保留」になるとトリガーされます。そのため、Oracle Identity Managerでこれらのタイプのアダプタをトリガーするタイミングは指定せず、Oracle Identity Managerではこれらのアダプタの実行スケジュール・タブが無効になります。

また、Oracle Identity Managerでは挿入前に常に事前移入アダプタがトリガーされるため、事前移入アダプタについてはこのタブのチェック・ボックスは無効になります。

8.5.3 リソース

「リソース」タブでは、次のことを実行できます。

- Java APIサブタブをクリックして、アダプタで使用中のJava APIを確認します。

- 「その他」サブタブをクリックして、必要に応じて、Java APIではないファイルをアダプタに記録できます。

注意:

この「リソース」タブにはリソース・オブジェクトは表示されません。

8.5.4 変数リスト

事前移入アダプタの場合、データはアダプタ入力変数に渡され、アダプタ論理を使用して処理されます。アダプタによって出力変数が返され、プロセス・フォーム・フィールドに割り当てられます。

変数リスト・タブでは、次のことを実行できます。

- アダプタ変数を作成、変更および削除します。

- 各変数のデータ型を設定し、説明を付けます。

- アダプタ変数をリテラル参照またはアダプタ参照にマップします。また、プロセス・タスクまたはフォーム・フィールドにアタッチされるまで、マッピングを延期することもできます。

アダプタ変数がプロセス・タスクにアタッチされてプロセス・タスクが実行される場合、実行時にアダプタ変数の値を解決することもできます。その結果、プロセス固有のデータをこの変数にマップできます。

8.5.5 使用状況参照

プロセス・タスク・アダプタまたはタスク割当てアダプタの場合、使用状況参照タブには、アダプタがアタッチされたプロセス・タスクおよびそのプロセス・タスクをメンバーに持つプロセスが表示されます。

ルール・ジェネレータ・アダプタまたはエンティティ・アダプタの場合、このタブには、Oracle Identity Managerフォームおよびアダプタがアタッチされた関連データ・オブジェクトが表示されます。また、アダプタの実行スケジュールが、Oracle Identity Managerによってアダプタがトリガーされる順序を表す順序番号とともに表示されます。

事前移入アダプタの場合、このタブには、ユーザー定義フォームとアダプタがアタッチされたフォーム・フィールドが表示されます。また、アダプタに関連付けられた事前移入ルールも表示されます。

8.5.6 レスポンス

「レスポンス」タブは、プロセス・タスクに対する有効なレスポンスを定義するために使用されます。これらのレスポンスは、アダプタの実行結果に基づきます。外部システムによって返される様々なエラー・メッセージは、プロセス・タスクのコンテキストにおいて意味を持つような方法でこれらのレスポンスにマップできます。プロセス・タスクにアダプタをアタッチするときに、アダプタ・レスポンス・コードに基づいて、プロセス・タスク(およびそれに続くオブジェクト・ステータス)のステータス・バケット(「保留」、「完了」および「却下」で構成されます)を設定できます。

ヒント:

Oracle Identity Managerでは、プロセス・タスク・アダプタに対してのみ「レスポンス」タブが有効になります。タスク割当てアダプタ、ルール・ジェネレータ・アダプタ、事前移入アダプタまたはエンティティ・アダプタの場合、このタブは無効です。

8.6 アダプタの無効化と再有効化

アダプタを無効化してプロセス・タスクまたはフォーム・フィールドで使用できないようにするには、アダプタの無効化オプションを選択し、アダプタを保存します。

再度有効化するには、アダプタの無効化オプションの選択を解除し、アダプタを保存します。

8.7 アダプタ変数について

新たに作成したアダプタを機能させるために、アダプタ・タスクのパラメータにデータをマップできます。その場合は、プレースホルダ(アダプタ変数とも呼ばれる)を作成して、実行時にデータがマップされるようにします。

注意:

アダプタ変数は、すべてのアダプタ・タスクで再利用できます。

アダプタの実行にアダプタ変数が不必要になった場合は、アダプタからアダプタ変数を削除できます。アダプタ変数を削除した後、アダプタを再コンパイルしてください。

8.7.1 アダプタ変数の作成

アダプタ変数を作成するには、次の手順を実行します。

1. アダプタ変数を追加するアダプタ(Create Solaris Userアダプタなど)を選択します。

2. 変数リスト・タブを選択します。

3. 「追加」をクリックします。
変数の追加ウィンドウが表示されます。

4. アダプタ変数値をアクティブ化した後にOracle Identity Managerで変更できないようにするには、最終を選択します。

5. 「変数名」フィールドに、アダプタ変数の名前(SolarisUserIDなど)を入力します。

注意:

アダプタ変数名に空白は使用できません。

6. 「タイプ」メニューから、アダプタ変数の分類タイプ(Stringなど)を選択します。使用可能な項目は次のとおりです。

- オブジェクト

- ITリソース

- String

- ブール

- Character

- Byte

- 日付

- Integer

- Float

- Long

- Short

- Double

7. 「説明」テキスト領域には、アダプタ変数の説明を入力できます。

8. 「マップ先」メニューから、アダプタ変数を表8-1の項目のいずれかにマップできます。

表8-1 「マップ先」メニューの項目

名前

説明

リテラル

このアダプタ変数は、定数(リテラル)にマップされます。

実行時に解決

このアダプタ変数のマッピングは、後から実行時に行われます。このオプションを選択すると、アダプタの再利用性が向上します。

アダプタ参照

このアダプタ変数によって、Oracle Identity Managerデータベース参照またはOracle Identity Managerデータ・オブジェクト参照にアクセスできます。

システム日付

このアダプタ変数がOracle Identity Managerによってトリガーされると、サーバーの現在の日付と時刻にマップされます。

注意: このオプションは「日付」タイプを選択した場合にのみ表示されます。

注意:

「オブジェクト」タイプを選択すると、「修飾子」メニューが変数の追加ウィンドウに表示されます。このメニューから、次のいずれかを選択できます。

- データベース参照。この項目を選択すると、アダプタ変数は、Oracle Identity Managerが現在実行されている対象のデータベースの参照にマップされます。

- データ・オブジェクト参照。この項目を選択すると、アダプタ変数は、Oracle Identity Managerデータ・オブジェクトにマップされます。

注意:

「ITリソース」タイプを選択すると、「リソース・タイプ」メニューが変数の追加ウィンドウに表示されます。このメニューから、ITリソース・タイプの定義フォームを使用して作成されたITリソース・タイプのいずれかを選択できます。そうすることで、このITリソース・タイプのパラメータにアダプタ変数をマップできます。

9. 変数の追加ウィンドウのツールバーで、「保存」をクリックします。アダプタ変数の情報が、Oracle Identity Managerデータベースに格納されます。
変数の追加ウィンドウを閉じてメイン画面をアクティブにします。作成したアダプタ変数の名前、分類タイプ、マッピング選択および説明が、変数リスト・タブの子表に表示されます。

これで、このアダプタ変数が「アダプタ・ファクトリ」フォームのアダプタに加わりました。Oracle Identity Managerデータベースに保存され、アダプタ変数が使用可能になります。

8.7.2 アダプタ変数の変更

アダプタ変数を変更するには、次の手順を実行します。

1. 編集するアダプタ変数を含むアダプタ(Create Solaris Userアダプタなど)を選択します。

2. 変数リスト・タブをクリックし、変更するアダプタ変数の行ヘッダーをダブルクリックします。変数の編集ウィンドウが表示され、アダプタ変数の情報が表示されます。

3. アダプタ変数のデータ型をStringからCharacterに変更するなど、必要な編集を行います。

4. 変数の編集ツールバーで、「保存」をクリックします。アダプタ変数に関して変更された情報が、Oracle Identity Managerデータベースに格納されます。

5. 変数の編集ウィンドウを閉じてメイン画面をアクティブにします。変更したアダプタ変数が、「アダプタ・ファクトリ」フォームの子表に表示されます。

注意:

アダプタ変数のデータ型を変更した場合は特に、データ・マッピングを確認し、アダプタを再コンパイルしてください。

8.7.3 アダプタ変数の削除

アダプタの実行にアダプタ変数が不要になった場合は、アダプタからアダプタ変数を削除できます。これを行うには、次の手順を実行します。

1. 削除するアダプタ変数を含むアダプタ(Create Solaris Userアダプタなど)を選択します。

2. 変数リスト・タブを選択します。

3. このタブのリストから、削除するアダプタ変数を選択します。

4. 「削除」をクリックします。

5. 変数を削除した後、アダプタを再コンパイルします。

アダプタ変数が子表に表示されなくなります。アダプタ変数は削除されました。

8.8 アダプタ・タスクの作成

アダプタの構成と変数の作成が終了すると、アダプタのアトミック・ファンクション・コールを作成できます。これらのファンクション・コールは、アダプタ・タスクと呼ばれます。

この項では、アダプタ・タスクとタスクの作成方法について説明します。

- アダプタ・タスクのタイプ

- Javaタスクの作成

- リモート・タスクの作成

- ストアド・プロシージャ・タスクの作成

- ユーティリティ・タスクの作成

- Oracle Identity Manager APIタスクの作成

- アダプタ変数の値の再割当て

- エラー・ハンドラ・タスクの追加

- ロジック・タスクの作成

8.8.1 アダプタ・タスクのタイプ

Oracle Identity Managerでは、次のアダプタ・タスクを作成できます。

- Javaタスク: Java APIを起動することで、アダプタと外部ソースとの通信を可能にします。

- リモート・タスク: アダプタによるAPIのメソッドの呼出しを可能にします。このAPIは、Oracle Identity Managerの外部にあるコンピュータに常駐します。
このタイプのタスクは、ほとんどの場合、ネットワーク対応ではないサード・パーティAPIの統合で使用されます。Remote Managerによって、リモート・コンピュータに配置されているリモートAPIメソッドが実行されます。また、サード・パーティAPIがSSLを使用しない場合、Remote Managerを使用して、SSLで保護された通信でサード・パーティAPIを起動できます。リモート・タスクは、ネットワーク対応だがスケーラビリティ目的でOracle Identity Managerサーバーに置かれていない、サード・パーティAPIの統合でも使用できます。リモートAPIメソッドは、Remote Managerによって実行されます。ただし、サード・パーティAPIがネットワーク対応しているため、Remote Managerがターゲット・システムに存在する必要はありません。

- ストアド・プロシージャ・タスク: Oracle Identity Managerで特定のデータベース・スキーマ内にあるSQLプログラムにマップして実行できます。これらのプログラムはストアド・プロシージャと呼ばれます。効率を高めるために事前にコンパイルされたSQL文などの情報が含まれています。
ストアド・プロシージャ・タスクをアダプタに組み込み、このアダプタをプロセス・タスクにアタッチすることで、Oracle Identity Managerでは、ネットワーク上でアクセス可能なOracle DatabaseまたはMicrosoft SQL Serverデータベースにストアド・プロシージャを組み込むことができます。これには、ストアド・プロシージャからのプリミティブ値の取得が含まれます。

- ユーティリティ・タスク: Oracle Identity ManagerにパッケージされたメソッドおよびAPIをアダプタに移入できます。また、このタイプのタスクを使用すると、Java標準ライブラリAPIにアクセスできます。

- Oracle Identity Manager APIタスク: アダプタ・タスクからOracle Identity Managerで公開されたAPIにアクセスできます。これにより、アダプタ・コードの移植性が高まります。

- 変数設定タスク: アダプタ内に変数を設定できます。

- エラー・ハンドラ・タスク: 実行時に発生したアダプタ関連のエラーを表示できます。また、エラーの理由および考えられる解決策を表示できます。

- ロジック・タスク: アダプタ内に条件文を構築できます。

次のタイプのロジック・タスクを作成できます。

- FORループ

- WHILEループ

- IF文

- ELSE文

- ELSE IF文

- BREAK文

- RETURN文

- CONTINUE文

- SET VARIABLE文

- Handle Error文

関連項目:

構築できるロジック・タスクのタイプの詳細は、第8.8.9項「ロジック・タスクの作成」を参照してください。

区別しやすくするために、Oracle Identity Managerでは、アダプタ・タスクのタイプがそれぞれアイコンで表示されます。タスク名の先頭にあるアイコンは、タスクのタイプを視覚的に示しています。たとえば、JはJavaタスクを表し、LTはロジック・タスクを表します。

アイコンのリストを表示するには、アダプタ・タスク・タブを選択し、「凡例」をクリックします。「凡例」ウィンドウが表示され、次のアイコンのリストが表示されます。

- 関数タスク

- Java

- リモート

- ストアド・プロシージャ

- ユーティリティ・タスク

- ユーティリティ

- Oracle Identity Manager API

- 論理タスク

8.8.2 Javaタスクの作成

Oracle Identity Managerでは、Java APIを使用して外部ソースとハンドシェイクできます。このためには、Oracle Identity Managerによってトリガーされた場合に外部ソースとの通信を開始するタスクを、アダプタに追加する必要があります。このタイプのタスクはJavaタスクと呼ばれます。

Javaタスクを作成するには、次の手順を実行します。

1. Javaタスクを追加するアダプタ(Update Solaris Passwordアダプタなど)を選択します。

2. アダプタ・タスク・タブを選択します。

3. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されたら、関数タスク・オプションを選択します。

4. このオプションの右側の表示領域からJava項目を選択し、「続行」をクリックします。
オブジェクト・インスタンスの選択ウィンドウが表示されます。

表8-2に、オブジェクト・インスタンスの選択ウィンドウのオプションを示します。

表8-2 オブジェクト・インスタンスの選択ウィンドウのオプション

オプション

説明

新規オブジェクト・インスタンス

このオプションをクリックして、新規Javaオブジェクト・インスタンスを作成します。

永続インスタンス

このオプションをクリックし、隣接するコンボ・ボックスをクリックして、ドロップダウン・メニューからオブジェクト・インスタンスを選択すると、永続オブジェクトにメソッドをコールできます。

タスク戻り値インスタンス

このオプションをクリックし、コンボ・ボックスをクリックして、ドロップダウン・メニューからアダプタ・タスクを選択すると、先に定義したアダプタ・タスクによって返されたオブジェクトにこのメソッドをコールできます。

注意:

永続インスタンス・オプションがグレー表示されている場合は、アダプタに永続オブジェクトが定義されていません。同様に、タスク戻り値インスタンス・オプションがグレー表示されている場合は、タスクに関連付けられたJavaオブジェクトの戻り値がありません。

5. オプション(新規オブジェクト・インスタンスなど)をクリックして、「続行」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。
表8-3に、アダプタ・ファクトリ・タスクの追加ウィンドウの様々なリージョンを示します。

表8-3 アダプタ・ファクトリ・タスクの追加ウィンドウのリージョン

名前

説明

タスク名

このフィールドにはJavaタスクの名前が表示されます。

永続インスタンス

このJavaオブジェクトが再利用される場合は、チェック・ボックスが選択され、タスク・インスタンスの名前が隣のフィールドに入力されます。

APIソース

このコンボ・ボックスには、アクセス可能なすべてのJARファイルおよびクラス・ファイルのリストが表示されます。

アプリケーションAPI

このコンボ・ボックスには、アクセス可能であり、APIソース・リストで選択したJARファイルに属するすべてのクラス・ファイルのリストが表示されます。

コンストラクタ

このテキスト領域には、Javaオブジェクトで使用可能なすべてのコンストラクタが表示されます。

メソッド

このテキスト領域には、Javaオブジェクトで使用可能なすべてのメソッドのリストが表示されます。

アプリケーション・メソッド・パラメータ

この領域には、選択したコンストラクタおよびメソッドのパラメータが表示されます。これらのパラメータは、アダプタ変数とOracle Identity Managerコンポーネントにマップされます。

6. 「タスク名」フィールドに、作成するタスクの名前(Update Passwordなど)を入力します。

7. (オプション。)Javaオブジェクトを再利用可能にするには、永続インスタンスを選択し、チェック・ボックスの右側にあるテキスト・フィールドに、このタスクのインスタンスの名前を入力します。

注意:

インスタンス名に空白が含まれていないことを確認してください。

注意:

ターゲット・リソースとのセッションを、アダプタの使用中に1回のみではなく複数回参照するには、永続インスタンスを選択します。

ヒント:

Javaオブジェクトを永続するように設定すると、Javaオブジェクトを次に作成するときに、オブジェクト・インスタンスの選択ウィンドウの永続インスタンス・リストに表示されます。また、同一Javaオブジェクトのすべてのアダプタ・タスクにコンストラクタをマップする必要はありません。

8. APIソースを選択します。Oracle Identity ManagerがOIM_HOME/ディレクトリ・パスのJavaTasksサブディレクトリ(C:\oracle\Xellerate\JavaTasksなど)から参照するJARファイルが表示されます。

関連項目:

Oracle Identity Managerでサード・パーティJARファイルをJavaタスクとともに使用する方法については、第8.3.1項「アダプタ環境の構成」を参照してください。

9. アプリケーションAPIを選択します。APIソースで選択したJARファイルに属するクラス・ファイルが表示されます。

10. コンストラクタ領域から、選択したJavaクラスの初期化に使用するメソッドを選択します。

11. メソッド領域から、Javaタスクで使用するメソッドを選択します。

12. ツールバーで、「保存」をクリックします。
Javaタスクに関する情報が、Oracle Identity Managerデータベースに格納されます。Javaタスクのコンストラクタおよびメソッドのパラメータにアクセスできるようになります。これらのパラメータは、アダプタ・ファクトリ・タスクの追加ウィンドウのアプリケーション・メソッド・パラメータ・リージョンに表示されます。

13. マッピングを設定する必要があるJavaクラスのコンストラクタおよびメソッドを表示するには、コンストラクタおよびメソッド・アイコンの左側にある「+」アイコンをクリックします。

14. マッピングを設定する必要があるコンストラクタまたはメソッドのパラメータを選択します。

15. 「説明」テキスト領域に、このマッピングの説明を入力できます。

16. 「マップ先」コンボ・ボックスをクリックし、コンストラクタまたはメソッドのパラメータにマップできる項目(「アダプタ変数」など)を選択します。

17. 適切なマッピングを設定します。

関連項目:

設定するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

18. 設定をクリックします。
選択したコンストラクタまたはメソッドのパラメータが青で表示されます。これはマップ済であることを表します。

ヒント:

パラメータのマッピングを削除するには、そのパラメータを右クリックし、表示されるポップアップ・メニューからパラメータのマッピング解除を選択します。

19. アプリケーション・メソッド・パラメータ・リージョンに表示されるコンストラクタおよびメソッドのすべてのパラメータに対して、手順15から18を繰り返します。

20. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。Javaタスクに関する情報が、Oracle Identity Managerデータベースに格納されます。

21. ツールバーで「閉じる」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成したJavaタスク(Update Passwordなど)が、「アダプタ・ファクトリ」フォームに表示されます。

22. (オプション。)アダプタに対して追加のJavaタスクを作成するには、手順3から21を繰り返します。

ヒント:

様々なタイプのアダプタ・タスクを作成してアダプタに追加できます。

アダプタが論理的に完全で、アダプタ・タスクのすべての変数がマップ済の場合、アダプタをコンパイルして、プロセス・タスクまたはフォーム・フィールドで使用できます。

23. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

24. (オプション。)Oracle Identity Managerで生成されたコードを表示するには、ツールバーの「注意」をクリックします。
Oracle Identity Managerで生成されたコードを含む「注意」ウィンドウが表示されます。

注意:

「ビルド」をクリックした後に、コンパイルのステータス・フィールドにCODE GEN ERRORが表示される場合は、アダプタの検証およびコンパイル中に、Oracle Identity Managerで次の2つのタイプのエラーのいずれかが発生しています。

- 検証エラー
Oracle Identity Managerでアダプタをチェックし、有効であることを検証しているときに、エラーが検出されました。このエラーは、アダプタ・タスクのパラメータがマップされていない場合、パラメータが正しくマップされていない場合、または配置されたアダプタ・タスクが使用できない場合に発生します。

Oracle Identity Managerでは、アダプタの検証が終了してからアダプタのコードが生成されるため、Oracle Identity Managerで検証エラーが発生すると、コードは作成されません。

- Javaコンパイル・エラー
Oracle Identity Managerによって、アダプタは有効であることが検証されました。ただし、Oracle Identity Managerでアダプタのコンパイル中に、エラーが検出されました。このエラーは、アダプタ・タスク・パラメータに割り当てられたデータ型が正しくない場合に発生します。

Oracle Identity Managerでアダプタが検証されているため、コードが生成されます。ただし、コンパイル中にOracle Identity Managerでエラーが発生した時点で、コードの生成は停止されます。

ヒント:

Javaタスクを作成してアダプタに追加すると、「アダプタ・ファクトリ」フォームの「リソース」タブにアクセスして、次の情報を確認できます。

- Javaタスクの作成に使用されたJARファイルおよびクラス・ファイル

- これらのJARファイルおよびクラス・ファイルを含むディレクトリ・パスを表す名前

8.8.3 リモート・タスクの作成

リモート・タスクを使用すると、アダプタでRemote Managerを使用してAPIメソッドを起動できます。このAPIは、Oracle Identity Managerの外部にあるコンピュータに常駐します。この項では、リモート・タスクの作成方法について説明します。

注意:

リモート・タスクを作成する前に、分類タイプが「ITリソース」のアダプタ変数を定義し、ITリソース・タイプの定義フォームを使用して作成したITリソースのいずれかを選択してください。

1. リモート・タスクを追加するアダプタを選択します。

2. アダプタ・タスク・タブをクリックします。

3. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されます。

4. 関数タスク・オプションを選択します。

5. ボタンの右側の表示領域から、リモート・タスクを作成するリモート項目を選択します。次に、「続行」をクリックします。
オブジェクト・インスタンスの選択ウィンドウが表示されます。

注意:

このウィンドウの選択肢の詳細は、第8.8.2項「Javaタスクの作成」を参照してください。

6. 「続行」をクリックします。
アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。

7. 「タスク名」フィールドに、作成するリモート・タスクの名前を入力します。

8. (オプション。)リモート・タスクを再利用可能にする場合は、永続インスタンス・オプションを選択します。次に、チェック・ボックスの右側にあるテキスト・フィールドに、このタスクのインスタンスの名前を入力します。

注意:

インスタンス名に空白が含まれていないことを確認してください。

関連項目:

アダプタ・ファクトリ・タスクの追加ウィンドウのリージョンの詳細は、第8.8.2項「Javaタスクの作成」を参照してください。

Oracle Identity Managerでサード・パーティJARファイルをJavaタスクとともに使用できるようにする方法の詳細は、第8.3.1項「アダプタ環境の構成」を参照してください。

9. アダプタ・ファクトリ・タスクの追加ウィンドウから、JARファイル、クラス・ファイル、コンストラクタおよびメソッドを選択します。次に、コンストラクタおよびメソッドのパラメータのマッピングを設定します。

注意:

入力パラメータの1つに、分類タイプ「ITリソース」が含まれています。このパラメータを、タイプ「ITリソース」のアダプタ変数と関連付ける必要があります。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

10. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。
リモート・タスクに関する情報が、Oracle Identity Managerデータベースに格納されます。

11. このウィンドウのツールバーで、「閉じる」をクリックします。
アダプタ・ファクトリ・タスクの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成したリモート・タスクが「アダプタ・ファクトリ」フォームに表示されます。

12. (オプション。)アダプタに対して追加のリモート・タスクを作成するには、手順3から11を繰り返します。
これで、アダプタをコンパイルし、プロセス・タスクまたはフォーム・フィールドで使用できます。

13. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチして、Oracle Identity Managerが外部APIと通信できるようになります。

8.8.4 ストアド・プロシージャ・タスクの作成

Oracle Identity Managerでは、特定のデータベース・スキーマ内にあるSQLプログラムにマップして、そのSQLプログラムを実行できます。これらのSQLプログラムは、ストアド・プロシージャと呼ばれます。ストアド・プロシージャには、効率を高めるために事前にコンパイルされたSQL文などの情報が含まれています。

そのためには、ストアド・プロシージャ・タスクをアダプタに追加する必要があります。Oracle Identity Managerでトリガーされると、このタスクによって、ネットワーク上でアクセス可能なOracle DatabaseまたはMicrosoft SQL Serverデータベースにストアド・プロシージャが組み込まれます。これには、ストアド・プロシージャからのプリミティブ値の取得が含まれます。

ストアド・プロシージャ・タスクを作成するには、次の手順を実行します。

注意:

データベース・スキーマのパラメータ値とサーバー・タイプは、「ITリソース」フォームで設定します。

スキーマのサーバー・タイプは、「データベース」に設定する必要があります。それ以外では、ストアド・プロシージャ・タスクの作成または実行(あるいはその両方)の際に、Oracle Identity Managerでデータベース・スキーマを参照できません。

また、Oracle Identity Managerでは、パラメータで表される値(データベース名やURLなど)を使用してスキーマに接続します。その結果、スキーマに含まれるストアド・プロシージャを実行できます。

1. Oracle Databaseを使用するOracle Identity Managerインストールの場合、ojdbc14.jarファイルをOIM_HOME/ext/ディレクトリからOIM_DC_HOME/xlclient/extディレクトリにコピーします。
Microsoft SQL Serverを使用するOracle Identity Managerインストールの場合、次のファイルをMicrosoftから入手し、OIM_DC_HOME/xlclient/extディレクトリにコピーする必要があります。

- msbase.jar

- mssqlserver.jar

- msutil.jar

2. ストアド・プロシージャ・タスクを追加するアダプタ(Update User IDアダプタなど)を選択します。

3. アダプタ・タスク・タブをクリックします。

4. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されます。

5. 関数タスク・オプションを選択します。

6. オプションの右側の表示領域からストアド・プロシージャを選択し、「続行」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。
次の表に、アダプタ・ファクトリ・タスクの追加ウィンドウのリージョンを示します。

表8-4 アダプタ・ファクトリ・タスクの追加ウィンドウのリージョン

名前

説明

タスク名

ストアド・プロシージャ・タスクの名前が表示されます。

説明

ストアド・プロシージャ・タスクに関する説明が表示されます。

データベース

「ITリソース」フォームで定義されたデータベースがリストされます。

重要: サーバー・タイプが「データベース」であるITリソースのみが「データベース」リストに表示されます。

スキーマ

「データベース」リストに表示されるデータベースに関連付けられたスキーマがリストされます。

プロシージャ

スキーマ・リストに表示されるデータベース・スキーマに常駐するストアド・プロシージャがリストされます。

接続ステータス

Oracle Identity Managerとターゲット・ストアド・プロシージャを含むデータベース間の接続のステータスが表示されます。

Oracle Identity Managerがデータベースに接続可能な場合は、接続ステータス・リージョンに接続が確立されましたと表示されます。

注意: Oracle Identity Managerが接続できない場合は、表示領域に接続に失敗しましたと表示されます。また、アダプタ・ファクトリ・タスクの追加ウィンドウの「注意」ボタンが有効になります。このボタンをクリックすると、次の例に示すように、接続を確立できなかった理由が表示されます。

例外タイプ:

java.lang.ClassNotFoundExceptionMessage:

java.lang.ClassNotFoundException:

oracle.jdbc.driver.OracleDriver

この例では、特定のJavaクラスが見つからなかったため、Oracle Identity Managerは指定されたデータベースに接続できませんでした。

パラメータ

ストアド・プロシージャにマップできるパラメータが表示されます。これらのパラメータは、データベース、スキーマおよびストアド・プロシージャを選択し、この情報をOracle Identity Managerデータベースに保存した後で表示されます。

7. 「タスク名」フィールドに、作成するストアド・プロシージャ・タスクの名前(Update IDなど)を入力します。

8. 「説明」テキスト領域に、このストアド・プロシージャ・タスクの説明を入力できます。

9. 「データベース」リストをクリックします。「ITリソース」フォームで定義されたデータベースが表示されます。

注意:

選択したデータベースにOracle Identity Managerが接続できない場合は、表示領域に接続に失敗しましたと表示されます。また、アダプタ・ファクトリ・タスクの追加ウィンドウの「注意」ボタンが有効になります。このボタンをクリックすると、接続を確立できなかった理由が表示されます。

ヒント:

スキーマおよびストアド・プロシージャは、Oracle Identity Managerで接続できるデータベースを選択した後にのみ表示されます。この選択に基づいて、関連するスキーマおよびプロシージャが、対応するコンボ・ボックスに表示されます。

10. スキーマ・リストをクリックします。選択したデータベースに関連付けられたスキーマが表示されます。

11. プロシージャ・リストをクリックします。スキーマ・コンボ・ボックスから選択したデータベース・スキーマに常駐するストアド・プロシージャが表示されます。

12. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。ストアド・プロシージャ・タスクに関する情報が、Oracle Identity Managerデータベースに保存されます。
これで、ストアド・プロシージャのパラメータにマッピングを設定できます。これらのパラメータは、アダプタ・ファクトリ・タスクの追加ウィンドウの「パラメータ」リージョンに表示されます。

注意:

選択したストアド・プロシージャのデータベースおよびスキーマは、Oracle Identity Managerによって自動的にマップされます。ただし、Oracle Identity Managerでこれらのマッピングをオーバーライドできます。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

13. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。ストアド・プロシージャ・タスクのパラメータに設定したマッピングが、Oracle Identity Managerデータベースに格納されます。

14. このウィンドウのツールバーで、「閉じる」をクリックします。
アダプタ・ファクトリ・タスクの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成したストアド・プロシージャ・タスク(Update IDなど)が、「アダプタ・ファクトリ」フォームに表示されます。

15. (オプション。)アダプタに追加のストアド・プロシージャ・タスクを作成するには、手順3から13を繰り返します。

16. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチでき、選択したストアド・プロシージャをOracle Identity Managerでマップおよび実行できます。

8.8.5 ユーティリティ・タスクの作成

アダプタ・ファクトリは、アダプタ開発の効率を高めるユーティリティ・クラスおよびメソッドのライブラリとともに出荷されています。

これらのユーティリティ・クラスとメソッドは、xlUtils.jar、xlIntegration.jarおよびrt.jarファイル内にあります。これらのJARファイルのいずれかのクラスまたはメソッドを使用して作成したJavaタスクは、ユーティリティ・タスクと呼ばれます。

関連項目:

xlUtils.jar、xlAPI.jar、xlIntegration.jarおよびrt.jarファイルを含むクラス・ファイルの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

1. ユーティリティ・タスクを追加するアダプタ(Update Solaris User Groupアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されます。

4. ユーティリティ・タスク・オプションを選択します。

5. オプションの右側の表示領域からユーティリティを選択し、「続行」をクリックします。オブジェクト・インスタンスの選択ウィンドウが表示されます。

関連項目:

このウィンドウの選択肢の詳細は、「Javaタスクの作成」を参照してください。

6. 「続行」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。

7. 「タスク名」フィールドに、作成するユーティリティ・タスクの名前(Update User Groupなど)を入力します

8. (オプション。)ユーティリティ・タスクを再利用可能にする場合は、永続インスタンスを選択し、チェック・ボックスの右側にあるテキスト・フィールドに、このタスクのインスタンスの名前を入力します。

注意:

インスタンス名に空白が含まれていないことを確認してください。

関連項目:

アダプタ・ファクトリ・タスクの追加ウィンドウのリージョンの詳細は、「Javaタスクの作成」を参照してください。

「アダプタ環境の構成」を参照してください。

9. アプリケーションAPIリストをクリックします。xlUtils.jar、xlIntegration.jarおよびrt.jarファイルに属するクラス・ファイルが表示されます。

注意:

xlUtils.jar、xlIntegration.jarおよびrt.jarファイルには、ユーティリティ・タスクで使用できるすべてのクラス・ファイルが含まれています。したがって、APIソース・リストにアクセスする必要はありません。

10. アダプタ・ファクトリ・タスクの追加ウィンドウから、コンストラクタおよびメソッドを選択します。次に、コンストラクタおよびメソッドのパラメータのマッピングを設定します。

11. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。ユーティリティ・タスクに関する情報が、Oracle Identity Managerデータベースに格納されます。

12. このウィンドウのツールバーで、「閉じる」をクリックします。
アダプタ・ファクトリ・タスクの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成したユーティリティ・タスク(Update User Groupなど)が、「アダプタ・ファクトリ」フォームに表示されます。

13. (オプション。)アダプタに追加のユーティリティ・タスクを作成するには、手順3から12を繰り返します。
これで、アダプタをコンパイルし、プロセス・タスクまたはフォーム・フィールドで使用できます。

14. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

8.8.6 Oracle Identity Manager APIタスクの作成

アダプタ・コードの移植性を高めるために、Oracle Identity Manager APIタスクでは、Oracle Identity Managerによって公開されたAPIをアダプタ・タスクで呼び出すことができます。これは、ハードコードされたSQL文を介してOracle Identity Managerデータに直接アクセスするよりもよい方法です。

アダプタ・ファクトリは、Oracle Identity Manager APIタスクを含むアダプタの開発の効率を高めるユーティリティ・クラスおよびメソッドのライブラリとともに出荷されています。これらのユーティリティ・クラスとメソッドは、xlAPI.jarファイル内にあります。

関連項目:

xlUtils.jar、xlAPI.jar、xlIntegration.jarおよびrt.jarファイルを含むクラス・ファイルの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

このタイプのアダプタ・タスクを作成するには、次の手順を実行します。

1. Oracle Identity Manager APIタスクを追加するアダプタ(Get User's Passwordアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されます。

4. ユーティリティ・タスク・オプションを選択します。

5. オプションの右側の表示領域からXellerate APIを選択し、「続行」をクリックします。オブジェクト・インスタンスの選択ウィンドウが表示されます。

関連項目:

このウィンドウの詳細は、「Javaタスクの作成」を参照してください。

6. 「続行」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。

7. 「タスク名」フィールドに、作成するOracle Identity Manager APIタスクの名前(Retrieve Passwordなど)を入力します。

8. (オプション。)Oracle Identity Manager APIタスクを再利用可能にする場合は、永続インスタンスを選択します。次に、チェック・ボックスの右側にあるテキスト・フィールドに、このタスクのインスタンスの名前を入力します。

ヒント:

インスタンス名に空白が含まれていないことを確認してください。

関連項目:

アダプタ・ファクトリ・タスクの追加ウィンドウのリージョンの詳細は、「Javaタスクの作成」を参照してください。

Oracle Identity Managerでサード・パーティJARファイルをJavaタスクとともに使用できるようにする方法の詳細は、「アダプタ環境の構成」を参照してください。

9. アプリケーションAPIリストをクリックします。xlAPI.jarファイルに属するクラス・ファイルが表示されます。

注意:

xlAPI.jarファイルには、Oracle Identity Manager APIタスクで使用できるすべてのクラス・ファイルが含まれています。したがって、APIソース・リストにアクセスする必要はありません。

10. アダプタ・ファクトリ・タスクの追加ウィンドウから、クラス・ファイル、コンストラクタおよびメソッドを選択します。次に、コンストラクタおよびメソッドのパラメータのマッピングを設定します。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

11. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。Oracle Identity Manager APIタスクに関する情報が、Oracle Identity Managerデータベースに格納されます。

12. アダプタ・ファクトリの追加ウィンドウを閉じてメイン画面をアクティブにします。作成したOracle Identity Manager APIタスク(Retrieve Passwordなど)が、「アダプタ・ファクトリ」フォームに表示されます。

13. (オプション。)アダプタに追加のOracle Identity Manager APIタスクを作成するには、手順3から12を繰り返します。
これで、アダプタをコンパイルし、プロセス・タスクまたはフォーム・フィールドで使用できます。

14. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチして、Oracle Identity Managerがサード・パーティ・アプリケーションと通信できるようになります。

8.8.7 アダプタ変数の値の再割当て

アダプタが必要な目的を完了できるように、アダプタ変数の値を、別のアダプタ変数、異なるタイプのアダプタ・タスクまたは定数(リテラル)に再割当てする必要がある場合があります。アダプタ変数値の再割当てを可能にするタスクは、変数設定タスクと呼ばれます。

関連項目:

アダプタ変数の詳細は、「アダプタ変数について」を参照してください。

たとえば、ユーザーIDの長さが11文字未満の場合に、アダプタ変数の戻り値をアダプタ・タスク(UserName)の出力と等しくなるように設定する変数設定タスクを作成できます。

変数設定タスクを作成するには、次の手順を実行します。

1. 変数設定タスクを追加するアダプタ(Check the Solaris User IDアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 「追加」をクリックします。アダプタ・タスクの選択ウィンドウが表示されます。

4. ロジック・タスク・オプションを選択します。

5. 表示領域からSET VARIABLEを選択し、「続行」をクリックします。変数設定タスク・パラメータの追加ウィンドウが表示されます。

6. 「変数名」リストから、再割当てする値(アダプタ戻り値など)を持つアダプタ変数を選択します。

7. オペランド・タイプ・リストから、変数に値を提供するオペランドのタイプを選択します。

ヒント:

アダプタ変数の値を、別のアダプタ変数、異なるタイプのアダプタ・タスクまたはリテラルに再割当てできます。

表8-5を使用して、様々なオペランドのタイプについて理解してください。

表8-5 オペランドのタイプ

オペランド名

説明

変数

このオペランド・タイプを選択すると、アダプタ変数がオペランド修飾子リストに表示されます。このリストから、再割当て値を提供する特定のアダプタ変数を選択します。

注意: オペランド修飾子コンボ・ボックスには、「変数名」コンボ・ボックスに表示されるアダプタ変数と同じデータ型のアダプタ変数のみが表示されます。

アダプタ・タスク

このオペランド・タイプを選択すると、アダプタ・タスクがオペランド修飾子コンボ・ボックスに表示されます。このコンボ・ボックスから、再割当て値を提供する特定のアダプタ・タスクを選択します。

注意: オペランド修飾子コンボ・ボックスには、「変数名」コンボ・ボックスに表示されるアダプタ・タスクと同じデータ型のアダプタ・タスクのみが表示されます。

リテラル

このオペランド・タイプを選択すると、リテラルのタイプがオペランド修飾子コンボ・ボックスに表示されます。このコンボ・ボックスから、再割当て値を提供するリテラルのタイプを選択します。次に、コンボ・ボックスの下に表示されるフィールドに特定のリテラルを入力します。

次のタスクでは、アダプタ変数の戻り値をUserNameアダプタ変数と等しくなるように設定します。

1. 変数設定タスク・パラメータの追加ウィンドウのツールバーで、「保存」をクリックします。作成した変数設定タスクが、Oracle Identity Managerデータベースに格納されます。

2. 変数設定タスク・パラメータの追加ウィンドウのツールバーで、「閉じる」をクリックします。変数設定タスク・パラメータの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成した変数設定タスク(Set Adapter return value = UserNameなど)が、「アダプタ・ファクトリ」フォームに表示されます。

3. (オプション。)アダプタに追加の変数設定タスクを作成するには、手順3から9を繰り返します。
これで、アダプタをコンパイルし、プロセス・タスクまたはフォーム・フィールドで使用できます。

4. アダプタをコンパイルするには、「ビルド」をクリックします。コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。Oracle Identity Managerによってアダプタがコンパイルされ、エラーは検出されませんでした。アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

8.8.8 エラー・ハンドラ・タスクの追加

エラー・ハンドラ・タスクを追加するには、次の手順を実行します。

1. アダプタ・タスクからエラーが返される場合があります。これが発生すると、アダプタがアタッチされたプロセス・タスクまたはフォーム・フィールドは拒否されます。
独自のカスタマイズ可能なエラー・メッセージをアタッチして、ユーザーに表示することができます。これらのメッセージはエラー・ハンドラ・タスクと呼ばれます。

たとえば、ユーザーIDの長さが10文字を超える場合にエラー・メッセージを表示するエラー・ハンドラ・タスクをアダプタにアタッチできます。

2. エラー・ハンドラ・タスクを追加するアダプタ(Check the Solaris User IDアダプタなど)を選択します。

3. アダプタ・タスク・タブをクリックします。

4. 「追加」をクリックします。
アダプタ・タスクの選択ウィンドウが表示されます。

5. ロジック・タスク・オプションを選択します。

6. 表示領域からエラー処理を選択し、「続行」をクリックします。アダプタ・ファクトリ・タスクの追加ウィンドウが表示されます。

7. このウィンドウの参照フィールドをダブルクリックします。アダプタに追加できるエラー・ハンドラ・タスクが表示された「参照」ウィンドウが表示されます。

注意:

この「参照」ウィンドウには、ADAPTERで始まるエラー・ハンドラ・タスク(ADAPTER.USERIDLENERRなど)のみが表示されます。

アダプタに組み込むエラー・ハンドラ・タスクがない場合は、「エラー・メッセージ定義」フォームにアクセスして作成できます。「エラー・メッセージの定義」を参照してください。

8. 使用するエラー・ハンドラ・タスク(ADAPTER.USERIDLENERRなど)を選択します。

9. 「OK」をクリックします。「参照」ウィンドウが閉じ、アダプタ・ファクトリ・タスクの追加ウィンドウがアクティブになります。また、選択したエラー・ハンドラ・タスクが、このウィンドウのフィールドに表示されます。

10. アダプタ・ファクトリ・タスクの追加ウィンドウのツールバーで、「保存」をクリックします。アダプタに組み込んだエラー・ハンドラ・タスクが、Oracle Identity Managerデータベースに格納されます。

11. このウィンドウのツールバーで、「閉じる」をクリックします。
アダプタ・ファクトリ・タスクの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。追加したエラー・ハンドラ・タスク(Handle Error.ADAPTER.USERIDLENERRなど)が、「アダプタ・ファクトリ」フォームの子表に表示されます。

12. (オプション。)アダプタに追加のエラー・ハンドラ・タスクを作成するには、手順3から10を繰り返します。
アダプタが論理的に完全で、アダプタ・タスクのすべての変数がマップ済の場合、アダプタをコンパイルして、プロセス・タスクまたはフォーム・フィールドで使用できます。

13. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

関連項目:

「エラー・メッセージ定義」フォームを使用したエラー・メッセージの作成の詳細は、「エラー・メッセージの定義」を参照してください。

8.8.9 ロジック・タスクの作成

アダプタを定義するときに、アダプタに条件文を追加して論理フローを管理できます。これらの条件文は、ロジック・タスクと呼ばれます。たとえば、ユーザーIDの長さが10文字を超える場合にアクションをトリガーするロジック・タスクを作成できます。

ロジック・タスクを作成するには、次の手順を実行します。

1. ロジック・タスクを追加するアダプタ(Check the Solaris User IDアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 「追加」をクリックします。アダプタ・タスクの選択ウィンドウが表示されます。

4. ロジック・タスク・オプションを選択します。

5. 表示領域から、作成するロジック・タスクのタイプを選択します。次に、「続行」をクリックします。

注意:

条件式を選択して「続行」をクリックすると、次のいずれかのアクションが発生します。

Oracle Identity Managerによって、条件文がアダプタに直接追加されます。

構成できる条件式に関するフィールドを含むセカンダリ・ウィンドウが表示されます。

特定の条件文を選択した場合に発生する内容については、表8-6を参照してください。

表8-6 特定の条件文から発生するアクション

条件文

文がアダプタに直接追加される

セカンダリ・ウィンドウが表示される

FOR

X

WHILE

X

IF

X

ELSE

X

ELSE IF

X

BREAK

X

RETURN

X

CONTINUE

X

表8-7に、アダプタ・ファクトリ・ロジック・タスク・パラメータの追加ウィンドウの様々なリージョンを示します。

表8-7 アダプタ・ファクトリ・ロジック・タスクの追加ウィンドウのリージョン

名前

説明

オペランド・タイプ

これらのコンボ・ボックスには、アダプタ・タスクやアダプタ変数など、オペランドのタイプが表示されます。

コンパレータ・コンボ・ボックス

このコンボ・ボックスから、2つのオペランドの関係(<、=、>など)を設定できます。

オペランド修飾子

これらのコンボ・ボックスには、オペランドの修飾子が表示されます。

リテラル・テキスト・ボックス

「リテラル」オペランド・タイプを選択した場合は、このフィールドに特定のリテラルを入力します。

注意:

FOR条件文を選択すると、アダプタ・ファクトリ・ロジック・タスク・パラメータの追加ウィンドウが表示されます。ただし、異なるテキスト・ボックスとコンボ・ボックスが表示されます。

FOR条件式の場合は、表8-8を使用して、このアダプタ・ファクトリ・ロジック・タスク・パラメータの追加ウィンドウの様々なリージョンについて理解してください。

表8-8 FOR条件文の場合のアダプタ・ファクトリ・ロジック・タスク・パラメータの追加

名前

説明

オペランド・タイプ

これらのコンボ・ボックスには、アダプタ・タスクやアダプタ変数など、オペランドのタイプが表示されます。

コンパレータ・コンボ・ボックス

このコンボ・ボックスから、2つのオペランドの関係(<、=、>など)を設定できます。

オペランド修飾子

これらのコンボ・ボックスには、オペランドの修飾子が表示されます。

増分コンボ・ボックス

この領域で、初期値の増減とその量を設定できます。

注意:

ELSE、BREAK、RETURNまたはCONTINUE条件式を選択した場合は、手順8に進んでください。

6. 条件式にパラメータを設定します。
このロジック・タスクでは、ユーザーIDの長さが10文字を超えているかどうかが確認されます。

7. アダプタ・ファクトリ・ロジック・タスク・パラメータの追加ウィンドウのツールバーで、「保存」をクリックします。
作成したロジック・タスクが、Oracle Identity Managerデータベースに格納されます。

8. このウィンドウのツールバーで、「閉じる」をクリックします。アダプタ・ファクトリ・ロジック・タスク・パラメータの追加ウィンドウが閉じ、メイン画面が再びアクティブになります。作成したロジック・タスク(If (Check ID Length > 10)など)が、「アダプタ・ファクトリ」フォームに表示されます。

9. (オプション。)アダプタに追加のロジック・タスクを作成するには、手順3から8を繰り返します。

注意:

ロジック・タスクの条件で実行されるすべてのアダプタ・タスクは、そのロジック・タスクの下に正しくネストされている必要があります。

関連項目:

タスクのネストの詳細は、第8.10項「タスクの順序とネストの変更」を参照してください。

これで、アダプタをコンパイルし、プロセス・タスクまたはフォーム・フィールドで使用できます。

10. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

8.9 アダプタ・タスクの変更

次の手順では、変更が必要になった場合のアダプタ・タスクの編集方法について説明します。アダプタ・タスクを変更するには、次の手順を実行します。

1. 編集するアダプタ・タスクを含むアダプタ(Update Solaris User Groupアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 変更するアダプタ・タスクをダブルクリックします。
選択したアダプタ・タスクに関する情報を示すアダプタ・ファクトリ・タスク・パラメータの編集ウィンドウが表示されます。このウィンドウで、必要な変更を行います。

4. アダプタ・ファクトリ・タスク・パラメータの編集ウィンドウのツールバーで、「保存」をクリックします。
変更した情報が、Oracle Identity Managerデータベースに格納されます。

5. ツールバーで「閉じる」をクリックします。
アダプタ・ファクトリ・タスク・パラメータの編集ウィンドウが閉じます。メイン画面が再びアクティブになります。変更したタスクが、「アダプタ・ファクトリ」フォームの子表に表示されます。プロセス・タスクまたはフォーム・フィールドで使用できるように、アダプタを再コンパイルする必要があります。

6. アダプタを再コンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

注意:

Java、Xellerate APIまたはユーティリティ・タスク内のAPIコールは変更できません。アダプタ・タスクを削除し、再作成する必要があります。また、コンパイルのステータス・フィールドにCODE GEN ERRORが表示される場合は、アダプタのコンパイル中にOracle Identity Managerでエラーが発生しました。エラーを修正し、必要に応じてアダプタ・タスクを再度変更し、アダプタを再コンパイルしてください。

8.10 タスクの順序とネストの変更

複数のタスクをアダプタに追加する場合、アダプタが機能するように、タスクの実行順序を変更するか、あるタスクを別のタスク内に入れることができます。

次の手順では、タスクの順序とネストを変更する方法について説明します。

注意:

アダプタ・タスクのマッピングの依存性を理解したうえで、アダプタ・タスクの順序とネストを変更してください。

タスクの順序とネストを変更するには、次の手順を実行します。

1. 順序またはネスト(あるいはその両方)を変更するタスクを含むアダプタ(Check the Solaris User IDアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。
現在のアダプタに属するタスクが表示されます。

この例では、次のように変更する必要があります。

- エラー・ハンドラ・タスクをIF (Check ID Length > 10)ロジック・タスク内にネストする必要があります。

- 変数設定タスクをELSEロジック・タスク内にネストする必要があります。

- IFロジック・タスクをELSEロジック・タスクより前にします。

そのため、最初にロジック・タスクを再編成する必要があります。次に、エラー・ハンドラ・タスクと変数設定タスクをIFおよびELSEロジック・タスク内にそれぞれネストする必要があります。タスクを再編成するには、次の手順を実行します。

3. 別のタスクの前に実行する必要があるタスクを選択し、上へ矢印ボタンをクリックします。選択したタスクの位置が、その前のタスクと入れ替わります。
または

別のタスクの後に実行する必要があるタスクを選択し、下へ矢印ボタンをクリックします。強調表示されたタスクが、下にあったタスクの下に表示されます。

タスクをネストするか、またはタスクのネストを削除するには、次の手順を実行します。

4. 別のタスク内に置く必要があるタスクを選択し、右矢印ボタンをクリックします。選択したタスクが、その上に表示されるタスク内にネストされます。
または

別のタスク内にネストしないようにするタスクを選択し、左矢印ボタンをクリックします。強調表示されたタスクが、その上に表示されるタスク内にネストされなくなります。

5. ツールバーで「保存」をクリックします。
アダプタのタスクの順序とネストが、Oracle Identity Managerデータベースに格納されます。アダプタが論理的に完全で、アダプタ・タスクのすべての変数がマップ済の場合、アダプタをコンパイルして、プロセス・タスクまたはフォーム・フィールドで使用できます。

6. アダプタをコンパイルするには、「ビルド」をクリックします。
コンパイルのステータス・フィールドのテキストが、再コンパイルから「OK」に変わります。これは、Oracle Identity Managerによってアダプタがコンパイルされ、エラーが検出されなかったことを示します。これで、アダプタをプロセス・タスクまたはフォーム・フィールドにアタッチできます。

注意:

コンパイルのステータス・フィールドにCODE GEN ERRORが表示される場合は、アダプタのコンパイル中にOracle Identity Managerでエラーが検出されました。エラーを修正し、必要に応じてアダプタ・タスクを再度変更し、アダプタを再コンパイルしてください。

8.11 アダプタ・タスクの削除

アダプタの実行にアダプタ・タスクが不要になった場合は、アダプタからアダプタ・タスクを削除する必要があります。アダプタ・タスクを削除するには、次の手順を実行します。

1. 削除するタスクを含むアダプタ(Update Solaris User Groupアダプタなど)を選択します。

2. アダプタ・タスク・タブをクリックします。

3. 削除するタスク(CONTINUEロジック・タスクなど)を選択します。

4. 「削除」をクリックします。
選択したタスクが削除され、子表に表示されなくなります。

5. ツールバーで「保存」をクリックします。

6. アダプタを再コンパイルします。

注意:

アダプタ・タスクを削除する場合は、アダプタのロジックが矛盾なく維持されていることを確認してください。

8.12 レスポンスの使用

アダプタには様々な結果があり、レスポンスと呼ばれます。これらのレスポンスに基づいて、アダプタで他のプロセス・タスクをトリガーできます。

たとえば、アダプタからTrueレスポンスが返された場合、プロセス・タスクのステータスを自動的に「完了」に設定できます。ただし、アダプタからFalseレスポンスが返された場合は、プロセス・タスクのステータスを自動的に却下に設定し、別のプロセス・タスクをトリガーできます。

これらのレスポンスは、「アダプタ・ファクトリ」フォームの「レスポンス」タブで追加、変更または削除できます。

次の手順では、レスポンスを作成、変更および削除する方法について説明します。

注意:

プロセス・タスク・アダプタはプロセス・タスクにアタッチされているため、レスポンスはこれらのアダプタでのみ使用されます。ルール・ジェネレータ、事前移入アダプタおよびエンティティ・アダプタは、プロセスに関連付けられません。また、タスク割当てアダプタはレスポンスに関連付けられません。そのため、アクティブなアダプタがタスク割当てアダプタ、ルール・ジェネレータ、事前移入アダプタまたはエンティティ・アダプタである場合、Oracle Identity Managerで「レスポンス」タブは無効になります。

8.12.1 レスポンスの作成

1. レスポンスを追加するアダプタ(Create Solaris Userアダプタなど)を選択します。

2. 「レスポンス」タブをクリックします。

3. 「追加」をクリックします。
「レスポンス」タブに空の行が挿入されます。

4. コード名列内に表示されるフィールドをクリックします。

5. 生成可能なレスポンス・タイプを表すコード(Trueなど)を入力します。

6. 「説明」列内に表示されるフィールドをクリックします。

7. このレスポンスの説明(「ユーザーは正常に作成されました。」など)を入力します。

8. 「ステータス」列内に表示されるフィールドをダブルクリックします。
レスポンスに関連付け可能な様々なステータス・レベルを示す「参照」ポップアップ・ウィンドウが表示されます。

注意:

Oracle Identity Managerのステータス・レベルの詳細は、4-1ページの第4章「プロセス・タスク・アダプタについて」を参照してください。

9. 目的のステータス・レベル(完了(C)など)をクリックします。次に、「OK」をクリックします。
「参照」ウィンドウが閉じ、「レスポンス」タブが再びアクティブになります。

10. 「追加」ボタンをクリックし、コード名フィールドおよび「説明」フィールドにそれぞれFalseおよび「ユーザーは正常に作成されませんでした。」と入力して、別のレスポンスを作成します。次に、「参照」ウィンドウにアクセスし、却下(R)ステータス・レベルをこのレスポンスに割り当てます。

11. ツールバーで「保存」をクリックします。
このアダプタに対して作成したレスポンスが、Oracle Identity Managerデータベースに格納されました。このアダプタをプロセス・タスクにアタッチすると、これらのレスポンスは「プロセス定義」フォームのタスクの編集ウィンドウの「レスポンス」タブに表示されます

8.12.2 レスポンスの変更

次の手順では、レスポンスを編集する方法について説明します。

1. 編集するレスポンスを含むアダプタ(Create Solaris Userアダプタなど)を選択します。

2. 「レスポンス」タブをクリックします。

3. 変更する情報を含むレスポンスのフィールドをダブルクリックします。

1. フィールドがテキスト・フィールドの場合、Oracle Identity Managerでフィールドが有効になります。これで、このフィールドの内容を編集できます。

2. フィールドが参照フィールドの場合、レスポンスに関連付け可能な様々なステータス・レベルを示す「参照」ポップアップ・ウィンドウが表示されます。目的のステータス・レベルをクリックし、「OK」をクリックします。

たとえば、Falseレスポンスの「ステータス」列をダブルクリックし、一時停止(S)ステータス・レベルを選択して「OK」をクリックします。

4. ツールバーで「保存」をクリックします。
レスポンスに対して変更した情報が、Oracle Identity Managerデータベースに格納されます。

8.12.3 レスポンスの削除

レスポンスが不要になった場合は、アダプタから削除できます。

1. 削除するレスポンスを含むアダプタを選択します。

2. 「レスポンス」タブをクリックします。

3. 削除するレスポンスを選択します。

4. 「削除」をクリックします。

レスポンスが表示されなくなります。これは、Oracle Identity Managerによってレスポンスが削除されたことを示します。

8.13 ルール・ジェネレータおよびエンティティ・アダプタのスケジューリング

Oracle Identity Managerでは、プロセス・タスク・アダプタまたはタスク割当てアダプタがプロセス・タスクにアタッチされ、プロセス・タスクのステータスが保留である場合、これらは自動的にトリガーされます。また、Oracle Identity Managerでは、挿入前に常に事前移入アダプタがトリガーされます。そのため、プロセス・タスク・アダプタ、タスク割当てアダプタまたは事前移入アダプタがいつ実行されるかは、スケジュールしません。

一方、ルール・ジェネレータおよびエンティティ・アダプタは、フォーム・フィールドにアタッチされます。Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタを実行するには、これらがいつトリガーされるかを指定する必要があります。これは、実行スケジュール・タブで実行します。

注意:

エンティティ・アダプタがフィールド値の検証用にプロセス・フォームまたはオブジェクト・フォームにアタッチされている場合、ダイレクト・プロビジョニングまたはリクエスト・プロビジョニングの完了後にこれらのフォームのデータを編集すると、これらのアダプタがトリガーされます。

このタブを使用して、挿入前または更新前にOracle Identity Managerによってルール・ジェネレータまたはエンティティ・アダプタがトリガーされるように設定できます。また、削除前、挿入後、更新後および削除後にエンティティ・アダプタが実行されるようにスケジュールすることもできます。

この手順では、ルール・ジェネレータまたはエンティティ・アダプタをトリガーするようにOracle Identity Managerを構成する方法について説明します。

8.13.1 ルール・ジェネレータおよびエンティティ・アダプタのスケジューリング

ルール・ジェネレータおよびエンティティ・アダプタをスケジュールするには、次の手順を実行します。

1. Oracle Identity Managerでトリガーするルール・ジェネレータまたはエンティティ・アダプタ(Solaris User ID Generatorなど)を選択します。

注意:

プロセス・タスク・アダプタまたは事前移入アダプタを使用する場合、実行スケジュール・タブは使用しません。したがって、このタブとその内容はグレー表示されています。

2. 実行スケジュール・タブをクリックします
実行スケジュール・タブの内容が表示されます。

次の表は、実行スケジュール・タブの様々なチェック・ボックスを理解するのに役立ちます。

名前

説明

挿入前

このチェック・ボックスをクリックすると、レコードがデータベースに挿入される前に、Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタをトリガーできます。

更新前

このチェック・ボックスをクリックすると、レコードがデータベースで更新される前に、Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタをトリガーできます。

削除前

このチェック・ボックスをクリックすると、レコードがデータベースから削除される前に、Oracle Identity Managerでエンティティ・アダプタをトリガーできます。

挿入後

このチェック・ボックスをクリックすると、レコードがデータベースに挿入された後に、Oracle Identity Managerでエンティティ・アダプタをトリガーできます。

更新後

このチェック・ボックスをクリックすると、レコードがデータベースで更新された後に、Oracle Identity Managerでエンティティ・アダプタをトリガーできます。

削除後

このチェック・ボックスをクリックすると、レコードがデータベースから削除された後に、Oracle Identity Managerでエンティティ・アダプタをトリガーできます。

注意:

実行スケジュール・タブのチェック・ボックスをクリックして、Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタをいつトリガーできるかを定義します。「データ・オブジェクト・マネージャ」フォームでは、Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタがいつトリガーされるかを指定できます。

「データ・オブジェクト・マネージャ」フォームの詳細は、「ルール・ジェネレータ・アダプタ変数のマッピング」を参照してください。

3. 目的のチェック・ボックスを有効にします。次に、ツールバーで、「保存」をクリックします。
Oracle Identity Managerでルール・ジェネレータまたはエンティティ・アダプタを実行するように設定した条件が、Oracle Identity Managerデータベースに格納されます。

8.14 ルール・ジェネレータ・アダプタの使用

この項では、ルール・ジェネレータ・アダプタの使用方法について説明します。内容は次のとおりです。

- ルール・ジェネレータのアダプタ変数のマッピング

- ルール・ジェネレータとプロセスの関連付け

- ルール・ジェネレータのフォーム・フィールドからの削除

8.14.1 ルール・ジェネレータのアダプタ変数のマッピング

ルール・ジェネレータの作成後、アダプタが確実に動作するように、ルール・ジェネレータのアダプタ変数を正しい場所にマップする必要があります。

アダプタ変数をマップするには、Design Consoleの「開発ツール/ビジネス・ルール定義」フォルダから「データ・オブジェクト・マネージャ」フォームにアクセスします。

ルール・ジェネレータのアダプタ変数を正しい場所にマップするには、次の手順を実行します。

1. 「データ・オブジェクト・マネージャ」フォームを開きます。Design Consoleワークショップに、「データ・オブジェクト・マネージャ」フォームが表示されます。
次の表に、「データ・オブジェクト・マネージャ」フォームの様々なリージョンとその説明を示します。

名前

説明

フォームの説明フィールド

この参照フィールドで、ルール・ジェネレータをアタッチするフィールドを含むフォームを選択します。

データ・オブジェクト・フィールド

このフィールドには、選択したフォームで表されるデータ・オブジェクトの名前が表示されます。

ハンドラのアタッチ・タブ

このタブには次の項目が表示されます。

- 選択したフォームにアタッチされたルール・ジェネレータ

- このフォームに関連付けたルール・ジェネレータの実行スケジュール

- ルール・ジェネレータがOracle Identity Managerで実行される順序

- ロールの挿入、更新および削除の権限

アダプタのマップ・タブ

このタブには次の項目が表示されます。

- フォームに関連付けられたルール・ジェネレータの名前

- アダプタのステータス

- ルール・ジェネレータのアダプタ変数の名前、説明およびマッピング・ステータス

注意: アダプタのマップ・タブは、アダプタが現在のデータ・オブジェクトに割り当てられるまで無効になっています。

2. フォームの説明フィールドをダブルクリックします。ルール・ジェネレータをアタッチできるフォームを示す「参照」ダイアログ・ボックスが表示されます。

3. 使用するフォーム(Solarisなど)を選択します。次に、「OK」をクリックします。

4. ツールバーで「保存」をクリックします。
選択したフォーム、フォームのデータ・オブジェクトおよびフォームに関連付けられたルール・ジェネレータ・アダプタが表示されます。また、Oracle Identity Managerでアダプタのマップ・タブが有効になります。

この例では、Solarisフォームが選択されています。そのデータ・オブジェクトThor.CarrierBase.tcUD_SOLARISと、それに関連付けられた4つのルール・ジェネレータ・アダプタ(adpCONVERTTOLOWERCASE、adpSOLARISHMDSTRINGGEN、adpSETSOLARISASSETおよびadpSETPASSWORDFROMMAIN)が表示されます。Oracle Identity Managerは、これらの4つのルール・ジェネレータを挿入前にトリガーします。

アダプタの順序番号に基づき、Oracle Identity Managerは、まずadpCONVERTTOLOWERCASEアダプタをトリガーし、それからadpSOLARISHMDSTRINGGEN、adpSETSOLARISASSETおよびadpSETPASSWORDFROMMAINアダプタの順にトリガーします。

ヒント:

ルール・ジェネレータのトリガー順を変更するには、次の手順を実行します。

1. 「割当て」をクリックします。「イベント・ハンドラ」ダイアログ・ボックスが表示されます。

2. ルール・ジェネレータを選択します。

3. 上矢印および下矢印ボタンをクリックし、ルール・ジェネレータの順序を変更します。

これらのルール・ジェネレータを正常に動作させるには、アダプタ変数を正しい場所にマップする必要があります。

5. アダプタのマップ・タブをクリックします。

6. 「名前」コンボ・ボックスで、マッピング可能なアダプタ変数を含むルール・ジェネレータ(adpCONVERTTOLOWERCASEルール・ジェネレータなど)を選択します。
アダプタのマップ・タブには次の項目が表示されます。

- フォームにアタッチするルール・ジェネレータの名前

- ルール・ジェネレータのステータス

- ルール・ジェネレータのアダプタ変数の名前、説明およびマッピング・ステータス

関連項目:

アダプタの様々なマッピング・ステータスの詳細は、「プロセス・タスク・アダプタのプロセス・タスクへのアタッチ」を参照してください。

7. アダプタのマップ・タブの「アダプタ変数」リージョンに表示される各変数にマッピングを設定します。それには、マップする変数の行ヘッダー(Dataなど)をダブルクリックします。変数のデータ・マッピング・ダイアログ・ボックスが表示されます。
表8-9に、変数のデータ・マッピング・ダイアログ・ボックスの様々なフィールドを示します。

表8-9 変数のデータ・マッピング・ダイアログ・ボックスのフィールド

フィールド名

説明

変数名

このフィールドには、マッピングを設定するアダプタ変数の名前(Dataなど)が表示されます。

データ型

このフィールドには、アダプタ変数のデータ型が表示されます(たとえば、Dataアダプタ変数のデータ型はStringです)。

マップ先

このフィールドには、アダプタ変数(User Definitionなど)に設定可能なマッピングのソースおよびターゲットの場所が含まれます。

アダプタ変数を場所または連絡先にマップする場合、Oracle Identity Managerでは隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする場所または連絡先の特定のタイプを選択します。

アダプタ変数を場所または連絡先にマップしない場合、このコンボ・ボックスは無効です。

修飾子

このフィールドには、「マップ先」コンボ・ボックスで選択したマッピングの修飾子が含まれます(「ユーザー・ログイン」など)。

ITアセット・タイプ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、特定のITリソース(Solarisなど)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

ITアセット・プロパティ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、マッピングの結果を受け取る特定のフィールド(「ユーザー名」など)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

重要: 「ITアセット・タイプ」および「ITアセット・プロパティ」フィールドは、下位互換性のためにこのウィンドウに含まれています。アダプタ変数を「ITリソース」データ型で作成することをお薦めします。この場合、これらのフィールドは表示されません。

リテラル値

アダプタ変数をリテラルにマップする場合、このフィールドに特定のリテラル名(IBMなど)を入力します。

アダプタ変数をリテラルにマップしない場合、このフィールドは表示されません。

「マップ先」、「修飾子」、「ITアセット・タイプ」、「ITアセット・プロパティ」および「リテラル値」のすべてのフィールドに入力します。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

8. 「保存」をクリックします。次に、「閉じる」をクリックします。
変数のデータ・マッピング・ウィンドウが閉じます。アダプタのマップ・タブが再びアクティブになります。

9. メイン画面のツールバーで「保存」をクリックします。

マッピング可能なすべてのアダプタ変数について、手順7と8を繰り返します。

「ステータス」フィールドの内容が、「マッピングが不完全」から「準備完了」に変わります。アダプタ変数のマッピング・ステータスも、「いいえ(N)」から「はい(Y)」に変わります。

これは、ルール・ジェネレータ・アダプタのすべてのアダプタ変数が、正常にマップされたことを示します。これで、このルール・ジェネレータをプロビジョニング・プロセスにアタッチし、プロセスをターゲット・ユーザーまたは組織にプロビジョニングした後でルール・ジェネレータをトリガーできます。

ヒント:

フォームに関連付けられたルール・ジェネレータにすべてのアダプタ変数をマップすると、「アダプタ・ファクトリ」フォームの使用方法の参照タブにアクセスすることで、アタッチしたフォームおよびルール・ジェネレータの実行スケジュールを簡単に確認できます。

ルール・ジェネレータがプロセスに割り当てられ、プロセスがプロビジョニングされると、Oracle Identity Managerによってルール・ジェネレータが実行されます。

8.14.2 ルール・ジェネレータとプロセスの関連付け

ルール・ジェネレータのアダプタ変数を正しい場所にマップした後、ルール・ジェネレータをプロビジョニング・プロセスにアタッチする必要があります。プロセスをターゲット・ユーザーまたは組織へプロビジョニングすると、Oracle Identity Managerにより関連付けられているルール・ジェネレータがトリガーされます。

同様に、プロビジョニング・プロセスに割り当てたルール・ジェネレータがプロセスを完了するために不要になった場合は、ルール・ジェネレータをプロビジョニング・プロセスから削除する必要があります。

ルール・ジェネレータをプロビジョニング・プロセスに割り当てるか、またはルール・ジェネレータをプロビジョニング・プロセスから削除するには、「プロセス定義」フォームの「イベント・ハンドラ/アダプタ」タブにアクセスします。このフォームは「プロセス管理」フォルダ内にあります。

8.14.3 ルール・ジェネレータのフォーム・フィールドからの削除

フォーム・フィールドにルール・ジェネレータをアタッチしてから、そのフォーム・フィールドに別のルール・ジェネレータを関連付けることができる場合もあります。このような場合は、まず現在フォーム・フィールドにアタッチしているルール・ジェネレータを削除する必要があります。

注意:

フォームのデータ・オブジェクトのクラス名がプロビジョニング・プロセスの表名と一致する場合に、ルール・ジェネレータをフォームから削除すると、そのプロビジョニング・プロセスにルール・ジェネレータを割り当てることができなくなります。

たとえば、adpCONVERTTOLOWERCASEルール・ジェネレータをSolarisフォームから削除したとします。フォームに関連付けられたデータ・オブジェクトのクラス名がUD_SOLARISである場合、UD_SOLARISの表名を持つプロビジョニング・プロセスにルール・ジェネレータを割り当てることはできません。

ルール・ジェネレータをフォーム・フィールドから削除するには、次の手順を実行します。

1. 「データ・オブジェクト・マネージャ」フォームを開きます。

2. 削除するルール・ジェネレータを含むフォームを選択します。

3. 選択したフォームとそのルール・ジェネレータが、「データ・オブジェクト・マネージャ」フォームに表示されます。

4. フォーム・フィールドから削除するルール・ジェネレータをクリックします。

5. 「削除」をクリックします。

選択したルール・ジェネレータが、「データ・オブジェクト・マネージャ」フォームに表示されなくなります。これは、ルール・ジェネレータがフォーム・フィールドから削除されたことを意味します。

注意:

ルール・ジェネレータをフォーム・フィールドから削除するときに、エラー・ボックスが表示される場合、アダプタはすでにプロビジョニング・プロセスに関連付けられています。まず、ルール・ジェネレータをプロセスからデタッチしてください。その後、フォーム・フィールドから削除できます。

8.15 エンティティ・アダプタの使用

エンティティ・アダプタの使用の詳細は、次の各項を参照してください。

注意:

Oracle Identity Manager 11g リリース2 (11.1.2.1.0)では、新しいエンティティ・アダプタの作成および既存のエンティティ・アダプタの変更はサポートされていません。ただし、Oracle Identity Managerリリース9.xからアップグレードした場合、既存のエンティティ・アダプタは、これまでどおりに機能し、既存のアダプタの変数マッピングを表示できます。

- 「アダプタのタイプ」のエンティティ・アダプタに関する説明。

- Oracle Identity Managerのフォームおよびプロビジョニング・プロセスによるエンティティ・アダプタの変数のマッピングの詳細は、「ルール・ジェネレータ・アダプタの使用」の手順を参照してください。

8.16 タスク割当てアダプタの使用

この項は次のトピックで構成されています。

- タスク割当てアダプタのプロセス・タスクへのアタッチ

- タスク割当てアダプタのプロセス・タスクからの削除

8.16.1 タスク割当てアダプタのプロセス・タスクへのアタッチ

タスク割当てアダプタの作成後、ユーザーまたはロールへのタスク割当てをOracle Identity Managerで自動化できるようにするために、タスク割当てアダプタをプロセス・タスクにアタッチする必要があります。

タスク割当てアダプタをプロセス・タスクに関連付けるには、(「プロセス定義」フォームから)「割当て」タブにアクセスします。このタブでは、アダプタ変数を適切な場所にマップすることもできます。

次の手順では、タスク割当てアダプタをプロセス・タスクにアタッチする方法について説明します。

1. 「プロセス管理」フォルダにある「プロセス定義」フォームを開きます。
Oracle Identity Managerワークスペースに「プロセス定義」フォームが表示されます。

2. アダプタをアタッチするタスクを含むプロセスを選択します。
選択したプロセスとそのタスクが、「プロセス定義」フォームに表示されます。

3. タスク割当てアダプタをアタッチするタスクの行ヘッダーをダブルクリックします。
タスク(Get Solaris UUIDプロセス・タスクなど)の情報を含むタスクの編集ウィンドウが表示されます。

4. 「割当て」タブをクリックします。「割当て」ダイアログ・ボックスが表示されます。

5. このタブで、「追加」をクリックします。
「割当て」タブ内に空白行が表示されます。

次の表に、「割当て」タブの関連フィールドを示します。

フィールド名

説明

優先度

このフィールドで、関連付けられたタスク割当てルールの優先度値を設定します。

ルール

この参照フィールドで、ユーザーまたはロールへのプロセス・タスクの割当てを自動化するために、関連付けられたアダプタを使用するかどうかを決定するルールを選択します。

ターゲット・タイプ

この参照フィールドで、タスクをOracle Identity Managerのユーザーまたはロールに割り当てるかどうかを指定します。

アダプタ

この参照フィールドで、指定したタスク割当てルールに関連付けるアダプタを選択します。

アダプタ・ステータス

このフィールドには、アダプタ変数のマッピング・ステータスが表示されます。

アダプタの様々なマッピング・ステータスの詳細は、「プロセス・タスク・アダプタのプロセス・タスクへのアタッチ」を参照してください。

6. 「優先度」フィールドをダブルクリックします。このフィールドで、関連付けられたタスク割当てルールの優先度値を設定します。

7. 「ルール」参照フィールドをダブルクリックします。表示される「参照」ダイアログ・ボックスで、ユーザーまたはロールへのプロセス・タスクの割当てを自動化するために、関連付けられたアダプタを使用するかどうかを決定するルールを選択します。

8. 「ターゲット・タイプ」参照フィールドをダブルクリックします。表示される「参照」ダイアログ・ボックスで、タスクをOracle Identity Managerユーザーまたはロールに割り当てるかどうかを指定します。

9. 「アダプタ」参照フィールドをダブルクリックします。表示される「参照」ダイアログ・ボックスで、手順7で選択したルールに関連付けるタスク割当てアダプタを指定します。

10. 「割当て」タブに表示されるツールバーで「保存」をクリックします。
タスク割当てアダプタ変数のマッピング・ステータスが、「アダプタ・ステータス」フィールドに表示されます。次の表を使用し、アダプタのマッピング・ステータスに基づいて実行するアクションを決定してください。

マッピング・ステータス

アクション

準備完了

アダプタにはマップできる変数はありません。つまり、いずれのアダプタ変数も戻り変数ではないか、実行時に解決として指定されていません。この場合は、手順14に進みます。

マッピングが不完全

1つ以上のアダプタ変数にマッピングが必要です。この場合は、手順11に進みます。

アダプタが使用不可

アダプタは、正常にコンパイルされた後に変更されました。その結果、アダプタの再コンパイルが必要です。

注意:

アダプタの様々なマッピング・ステータスの詳細は、「プロセス・タスク・アダプタのプロセス・タスクへのアタッチ」を参照してください。

11. マップをクリックします。
「アダプタ変数」ウィンドウが表示されます。次の情報が表示されます。

- プロセス・タスクにアタッチされたタスク割当てアダプタの名前

- アダプタのステータス

- アダプタ変数のマッピングのステータス、名前および説明

12. このウィンドウの「アダプタ変数」リージョンに表示される各変数にマッピングを設定します。それには、マップする変数の行ヘッダー(UUIDなど)をダブルクリックします。
変数のデータ・マッピングの編集ダイアログ・ボックスが表示されます。

表8-10に、変数のデータ・マッピングの編集ダイアログ・ボックスのフィールドを示します。

表8-10 変数のデータ・マッピングの編集ダイアログ・ボックスのフィールド

フィールド名

説明

変数名

このフィールドには、マッピングを設定するアダプタ変数の名前(UUIDなど)が表示されます。

データ型

このフィールドには、アダプタ変数のデータ型が表示されます(たとえば、UUID変数のデータ型はStringです)。

マップ先

このフィールドには、アダプタ変数に設定可能なマッピング型(「IT リソース」など)が含まれます。

アダプタ変数を場所または連絡先にマップする場合、Oracle Identity Managerでは隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする場所または連絡先の特定のタイプを選択します。

また、アダプタ変数をカスタム・プロセス・フォームにマップし、そのフォームに子表が含まれる場合、Oracle Identity Managerでフォームに隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする子表を選択します。場所、連絡先またはカスタム・プロセス・フォームの子表にアダプタ変数をマップしない場合、このコンボ・ボックスは無効になります。

修飾子

このフィールドには、「マップ先」コンボ・ボックスで選択したマッピングの修飾子が含まれます(ITアセットなど)。

ITアセット・タイプ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、特定のITリソース(Solarisなど)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

ITアセット・プロパティ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、マッピングの結果を受け取る特定のフィールド(一意のIDなど)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

重要: 「ITアセット・タイプ」および「ITアセット・プロパティ」フィールドは、下位互換性のためにこのウィンドウに含まれています。アダプタ変数を「ITリソース」データ型で作成することをお薦めします。この場合、これらのフィールドは表示されません。

リテラル値

アダプタ変数をリテラルにマップする場合、このフィールドでリテラル値を指定します。

アダプタ変数をリテラルにマップしない場合、このフィールドは表示されません。

古い値

このチェック・ボックスを選択して、選択した「修飾子」フィールドの変更前の値に、アダプタ変数をマップします。

プロセス・タスクに関連付けられたプロセス・タスク・アダプタは、プロセス・フォームのフィールドの一部が変更されると、条件付きでトリガーされる場合があります。「古い値」オプションをクリックし、プロセス・タスクを条件付きとしてマークした場合、以前のフィールドの値がアダプタに渡されます。これは、パスワードを使用するフィールドの場合に役立ちます。

たとえば、パスワードに同じ値の設定を許可しない場合、比較に古い値を使用できます。

カスタム・プロセス・フォームの子表に属するフィールドにアダプタ変数をマップしない場合、このチェック・ボックスは無効になります。

13. 「マップ先」、「修飾子」、「ITアセット・タイプ」、「ITアセット・プロパティ」、「リテラル値」および「古い値」のすべてのフィールドに入力します。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

14. ツールバーで「保存」をクリックします。次に、「閉じる」をクリックします。
変数のデータ・マッピングの編集ウィンドウが閉じます。「アダプタ変数」ダイアログ・ボックスが再びアクティブになります。

「ステータス」フィールドの内容が、「マッピングが不完全」から「準備完了」に変わります。アダプタ変数のマッピング・ステータスも、「いいえ(N)」から「はい(Y)」に変わります。

15. 「保存」をクリックします。次に、「閉じる」をクリックします。
「アダプタ変数」ダイアログ・ボックスが閉じ、「割当て」タブが再びアクティブになります。

プロセス・タスク(Assign Solarisタスクなど)に割り当てたアダプタのステータスが、「準備完了」になります。

16. 「割当て」タブに表示されるツールバーで、「保存」および「閉じる」をクリックします。
「割当て」タブが閉じ、メイン画面が再びアクティブになります。これは、タスク割当てアダプタが、プロセス・タスクにアタッチされたことを意味します。

注意:

タスク割当てアダプタをプロセス・タスクにアタッチすると、「アダプタ・ファクトリ」フォームの使用方法の参照タブにアクセスすることで、関連付けられたプロセスおよびタスクを簡単に確認できます。

8.16.2 タスク割当てアダプタのプロセス・タスクからの削除

Oracle Identity Managerでプロセス・タスクをユーザーまたはロールに割り当てるためのタスク割当てアダプタが無効または不要になった場合は、アダプタをタスクから削除する必要があります。

8.16.2.1 タスク割当てアダプタのプロセス・タスクからの削除

タスク割当てアダプタをプロセス・タスクから削除するには、次の手順を実行します。

1. 「プロセス定義」フォームを開きます。
Design Consoleワークスペースに、「プロセス定義」フォームが表示されます。

2. アダプタを削除するタスクを含むプロセス(Solaris 8プロセスなど)を選択します。
選択したプロセスとそのタスクが、「プロセス定義」フォームに表示されます。

3. アダプタを削除するプロセス・タスク(Get Solaris UUIDタスクなど)の行ヘッダーをダブルクリックします。
プロセス・タスクの情報を含むタスクの編集ダイアログ・ボックスが表示されます。

4. 「割当て」タブをクリックします。
プロセス・タスクにアタッチされたアダプタの情報を示す「割当て」タブが表示されます。

5. プロセス・タスクから削除するアダプタを含む行を選択します。

6. 「削除」をクリックします。アダプタが「割当て」タブに表示されなくなります。

7. 「保存」をクリックします。次に、「閉じる」をクリックします。
「割当て」タブが閉じ、メイン画面が再びアクティブになります。これは、タスク割当てアダプタがプロセス・タスクから削除されたことを意味します。

8.17 事前移入アダプタの使用

この項は次のトピックで構成されています。

- 事前移入アダプタのフォーム・フィールドへのアタッチ

- 事前移入アダプタのフォーム・フィールドからの削除

8.17.1 事前移入アダプタのフォーム・フィールドへのアタッチ

事前移入アダプタをフォーム・フィールドにアタッチするには、次の手順を実行します。

1. 事前移入アダプタをアタッチするフィールドを選択します。

2. 指定したフィールドに情報を移入するためにアダプタを使用するかどうかを決定するルールを選択します。

3. 指定したフィールドに関連付けるアダプタを選択します。

4. 選択したルールに優先度値を設定します。

5. 事前移入アダプタのアダプタ変数を正しい場所にマップします。

注意:

事前移入アダプタをフォーム・フィールドにアタッチするには、次の点を確認する必要があります。

- フォームがアクティブな状態ではないこと。あてはまらない場合は、新しいフォーム・バージョンを作成します。

- アタッチしたアダプタを使用する前に、フォームをアクティブ化する必要があります。

6. 「フォーム・デザイナ」フォームを開きます。

7. 事前移入アダプタをアタッチするフォーム(Solarisなど)を問い合せます。

8. 「事前移入」タブをクリックします。
問い合せたフォームにすでにアタッチされている事前移入アダプタが、タブ内に表示されます。

注意:

フォーム・フィールドにアタッチされているアダプタがない場合、「事前移入」タブには何も表示されません。

9. 「追加」をクリックします。
「事前移入アダプタ」ダイアログ・ボックスが表示されます。

表8-11に、「事前移入アダプタ」ダイアログ・ボックスのフィールドを示します。

表8-11 「事前移入アダプタ」ダイアログ・ボックスのフィールド

名前

説明

フィールド名

このコンボ・ボックスには、事前移入アダプタをアタッチできるすべてのフォーム・フィールドのリストが表示されます。

ルール

この参照フィールドで、指定したフォーム・フィールドに情報を移入するために関連付けられたアダプタを使用するかどうかを決定するルールを選択します。

アダプタ

この参照フィールドで、指定したフィールドに関連付けるアダプタを選択します。

順序

このフィールドで、選択したルールの優先度値を設定します。

アダプタ・ステータス

このフィールドには、アダプタ変数のマッピング・ステータスが表示されます。

アダプタの様々なマッピング・ステータスの詳細は、「プロセス・タスク・アダプタのプロセス・タスクへのアタッチ」を参照してください。

アダプタ変数

この領域には、次の項目が表示されます。

- マップ済: アダプタ変数のマッピング・ステータス。Yはアダプタ変数が正しくマップされたことを表し、Nはこの変数が正しくマップされなかったことを表します。

- 名前: アダプタ変数の名前。

- マップ先: 変数がマップされるフォーム・フィールド。アダプタ変数がマップされていない場合、列内の対応するセルは空白です。

10. 「フィールド名」コンボ・ボックスから、事前移入アダプタをアタッチするフォーム・フィールド(「ユーザーID」など)を選択します。

11. 「ルール」参照フィールドをダブルクリックします。表示される「参照」ダイアログ・ボックスで、指定したフォーム・フィールドに情報を移入するために関連付けられたアダプタを使用するかどうかを決定するルール(Rule for Lowercase User IDなど)を選択します。

12. 「アダプタ」参照フィールドをダブルクリックします。表示される「参照」ダイアログ・ボックスで、手順10で選択したフィールドに関連付けるアダプタ(Display Lowercase Letters for User IDなど)を選択します。

13. 「順序」フィールドに、手順11で選択したルールの優先度値(2など)を入力します。

14. 「事前移入アダプタ」ウィンドウのツールバーで「保存」をクリックします。

15. 「マッピングが不完全」が「アダプタ・ステータス」フィールドに表示されます。これは、選択したアダプタに、正しくマップされていない変数が含まれていることを示しています。変数を正しい場所にマップする必要があります。そうしない場合、アダプタは動作しません。

16. 「事前移入アダプタ」ウィンドウの「アダプタ変数」リージョンに表示される各変数にマッピングを設定します。それには、マップする変数の行ヘッダー(UserIDなど)をダブルクリックします。
アダプタ変数のマップ・ウィンドウが表示されます。

表8-12に、アダプタ変数のマップ・ウィンドウのフィールドを示します。

表8-12 アダプタ変数のマップ・ウィンドウのフィールド

フィールド名

説明

変数名

このフィールドには、マッピングを設定するアダプタ変数の名前(UserIDなど)が表示されます。

データ型

このフィールドには、アダプタ変数のデータ型が表示されます(たとえば、UserIDアダプタ変数のデータ型はStringです)。

マップ先

このフィールドには、アダプタ変数に設定可能なマッピング型(「プロセス・データ」など)が含まれます。

アダプタ変数を場所または連絡先にマップする場合、Oracle Identity Managerでは隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする場所または連絡先の特定のタイプを選択します。

アダプタ変数を場所または連絡先にマップしない場合、このコンボ・ボックスは無効です。

修飾子

このフィールドには、「マップ先」コンボ・ボックスで選択したマッピングの修飾子が含まれます(「ユーザーID」など)。

ITアセット・タイプ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、特定のITリソース(Solarisなど)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

ITアセット・プロパティ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、マッピングの結果を受け取る特定のフィールド(「ユーザー名」など)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

重要: 「ITアセット・タイプ」および「ITアセット・プロパティ」フィールドは、下位互換性のためにこのウィンドウに含まれています。アダプタ変数を「ITリソース」データ型で作成することをお薦めします。この場合、これらのフィールドは表示されません。

リテラル値

アダプタ変数をリテラルにマップする場合、このフィールドでリテラル値を指定します。

アダプタ変数をリテラルにマップしない場合、このフィールドは表示されません。

17. 「マップ先」、「修飾子」、「ITアセット・タイプ」、「ITアセット・プロパティ」および「リテラル値」のすべてのフィールドに入力します。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

18. アダプタ変数のマップ・ウィンドウのツールバーで「保存」をクリックします。次に、「閉じる」をクリックします。
アダプタ変数のマップ・ウィンドウが閉じます。「事前移入アダプタ」ウィンドウが再びアクティブになります。

「アダプタ・ステータス」フィールドのテキストが、「マッピングが不完全」から「準備完了」に変わります。アダプタ変数のマッピング・ステータスも、「いいえ(N)」から「はい(Y)」に変わります。

19. 「事前移入アダプタ」ウィンドウのツールバーで「閉じる」をクリックします。

「事前移入アダプタ」ウィンドウが閉じ、「フォーム・デザイナ」フォームが再びアクティブになります。「ユーザーID」フォーム・フィールドにアタッチした事前移入アダプタ(Display Lowercase Letters for User ID)が、2003年第1四半期売上の結果フォームの「事前移入」タブに表示されます。

このフォームを参照するプロセスを、ターゲット・ユーザーまたは組織にプロビジョニングすると、フォームが表示されます。Oracle Identity Managerにより、優先度が最も高い事前移入ルールが有効かどうかが確認されます。有効な場合、Oracle Identity Managerでは関連付けられた事前移入アダプタを指定するフィールド(「ユーザーID」)に割り当てて実行します。この時点で、次のアクションのいずれか1つが発生します。

- 「自動事前移入」チェック・ボックスをプロビジョニング・プロセスで選択した場合、事前移入アダプタで生成されたデータが自動的にOracle Identity Managerで表示されます。

- 「自動事前移入」チェック・ボックスが選択されていない場合、Oracle Identity Managerユーザーは、事前移入アダプタで生成されたデータの表示を手動でトリガーする必要があります。このためには、管理者はフォームをユーザーにプロビジョニングするときに、Webクライアントのダイレクト・プロビジョニング・ウィザードのフォーム・セクションにある事前移入ボタンをクリックする必要があります。

ヒント:

事前移入アダプタをフォーム・フィールドに割り当て、事前移入ルールをアダプタに割り当てると、「アダプタ・ファクトリ」フォームの使用方法の参照タブにアクセスすることで、アダプタ、フォーム・フィールドおよびルールの関連付けを簡単に確認できます。

8.17.2 事前移入アダプタのフォーム・フィールドからの削除

フォーム・フィールドに関連付けられた事前移入アダプタが有効ではなくなった場合、アダプタをフィールドから削除する必要があります。

注意:

事前移入アダプタをフォーム・フィールドから削除する前に、新しいバージョンのフォームを作成してください。

事前移入アダプタをフォーム・フィールドから削除するには、次の手順を実行します。

1. 削除する事前移入アダプタを選択します。

2. 「削除」をクリックします。事前移入アダプタがフォーム・フィールドから削除されます。フォームが起動している場合は、トリガーできません。

3. アダプタを削除した後に、フォームをアクティブ化する必要があります。

8.18 プロセス・タスク・アダプタの使用

この項は次のトピックで構成されています。

- プロセス・タスク・アダプタを使用するためのガイドライン

- プロセス・タスク・アダプタのプロセス・タスクへのアタッチ

- プロセス・タスク・アダプタのプロセス・タスクからの削除

8.18.1 プロセス・タスク・アダプタを使用するためのガイドライン

プロセス・タスク・アダプタを作成したら、「プロセス定義」フォームの統合タブを使用してアダプタを適切なプロセス・タスクにアタッチします。このタブでは、実行時に解決またはアダプタ戻り変数のいずれかとして指定されたアダプタ変数を、適切な場所にマップすることもできます。たとえば、adpSOLARISPASSWORDUPDATEDという名前のアダプタが、SolarisプロセスのPassword Updatedタスクに関連付けられているとします。アダプタを機能させるためにアダプタをプロセス・タスクにアタッチすると、別のフォームのフィールドからデータが必要になる場合があります。この例では、次の情報を取得するまでadpSOLARISPASSWORDUPDATEDアダプタは動作しません。

- ユーザーのOracle Identity Manager IDおよびパスワード

- ユーザーのSolaris IDおよびパスワード

- Solarisが位置するIPアドレス

そのため、UserID、Passwd、SolarisUserID、SolarisUserPasswdおよびServerAddressアダプタ変数から、それぞれ情報を取得する必要があります。この5つの変数は、「アダプタ・ファクトリ」フォームを使用して作成されます。それぞれのアダプタ変数の先頭のYは、アダプタが正常にマップされたことを表します。プロセスが必要な情報を取得するために使用するプロセス固有フィールドを作成するためのフォームは「フォーム・デザイナ」と呼ばれます。作成したフィールドは、Oracle Identity Managerにより表に格納されます。次に、この表をプロセスに関連付けると(「プロセス定義」フォームの表名参照フィールドを使用)、このプロセスのタスクにアタッチされたアダプタは、この表を使用して適切なデータを検索します。この表を変更するには、「フォーム・デザイナ」フォームを使用します。UD_SOLARIS表には、UD_SOLARIS_USERIDとUD_SOLARIS_PASSWDという2つのフィールドがあります。「フォーム・デザイナ」フォームのこのレコードにアクセスすると、表のフィールドを編集できます。

プロセス・タスク・アダプタを依存プロセス・タスクにアタッチすると、このプロセス・タスクのステータスは「保留」になり(先行するプロセス・タスクのステータスは「完了」)、Oracle Identity Managerにより自動的にアダプタがトリガーされます。プロセス・タスクが独立したタスクの場合、Oracle Identity Managerにより、プロセスがリクエストされた時点でアダプタが実行されます。実行されたアダプタの結果は、プロセス・タスクのステータスを表します。アダプタが正常に終了した場合、アダプタをアタッチしたプロセス・タスクのステータスは「完了」です。一方、アダプタで指定された機能が実行できない場合、アダプタをアタッチしたプロセス・タスクのステータスは「却下」です。エラーの原因を突き止めることで、正常に実行されるようにプロセス・タスクまたはアダプタ(あるいはその両方)を変更できます。

注意:

プロセス・タスクが失敗した原因を確認するには、次の手順を実行します。

プロセス・タスクを探します。プロセス・タスクをターゲット・ユーザーまたは組織にプロビジョニングしていない場合は、「To-Doリスト」または「保留中の承認」の中にあります。タスクを検出するには、次の手順を実行します。

1. ユーザーとしてログインします。

2. ウィンドウの左側の「To-Doリスト」リンクまたは「保留中の承認」リンクを選択します。

8.18.2 プロセス・タスク・アダプタのプロセス・タスクへのアタッチ

前の章では、プロセス・タスク・アダプタの作成方法について説明しました。プロセス・タスクを自動的に実行するためには、プロセス・タスク・アダプタをプロセス・タスクにアタッチする必要があります。アダプタをプロセス・タスクに関連付けるには、(「プロセス定義」フォームから)統合タブにアクセスします。このタブでは、アダプタ変数を適切な場所にマップすることもできます。次の手順では、プロセス・タスク・アダプタをプロセス・タスクにアタッチする方法について説明します。

1. 「プロセス管理」フォルダにある「プロセス定義」フォームを開きます。
Oracle Identity Managerワークスペースに「プロセス定義」フォームが表示されます。

2. アダプタをアタッチするタスクを含むプロセスを選択します。選択したプロセスとそのタスクが、「プロセス定義」フォームに表示されます。この例では、Solarisプロセスが選択されています。

3. アダプタをアタッチするタスクの行ヘッダーをダブルクリックします。タスク(Password Updatedプロセス・タスクなど)の情報を含むタスクの編集ウィンドウが表示されます。

4. 統合タブをクリックします。

5. 「追加」をクリックします。
ハンドラの選択ウィンドウが表示されます。

6. 「アダプタ」オプションをクリックして、Oracle Identity Managerのアダプタにアクセスします。
プロセス・タスクをアタッチできるアダプタが表示されます。

7. このリージョンから、プロセス・タスクにアタッチするアダプタ(adpSOLARISPASSWORDUPDATEDアダプタなど)を選択します。

ヒント:

各アダプタの名前は、区別しやすいよう、最初の3文字がadpです。各アダプタの名前は、区別しやすいよう、最初の3文字がadpです。

8. ハンドラの選択ウィンドウのツールバーで、「保存」をクリックします。
アダプタが正常にプロセス・タスクにアタッチされたことを示すダイアログ・ボックスが表示されます。

9. 「OK」をクリックします。
ダイアログ・ボックスが閉じ、統合タブがアクティブになります。タブには次の項目が表示されます。

- プロセス・タスクにアタッチされたアダプタの名前

- アダプタのステータス

- アダプタ変数の名前、説明およびマッピング・ステータス

注意:

アダプタのマッピング・ステータスは、次の3つのいずれかです。

準備完了: アダプタは正常にコンパイルされ、すべての変数が正常にマップされています。

マッピングが不完全: アダプタは正常にコンパイルされましたが、1つ以上の変数が正常にマップされていません。

アダプタが使用不可: アダプタは、正常にコンパイルされた後、変更および再コンパイルされました。

注意:

アダプタにマップ可能な変数がない場合、「アダプタ変数」リージョンは空白です。また、「ステータス」フィールドには、アダプタを再コンパイルする必要があるかどうかによって、「準備完了」または「アダプタが使用不可」のいずれかが表示されます。

注意:

マップ可能なアダプタ変数は、実行時に解決に指定されているか、アダプタ戻り変数のいずれかです。

注意:

アダプタをプロセス・タスクにアタッチすると、アダプタに定義したレスポンスがタスクの編集ウィンドウの「レスポンス」タブに表示されます。

10. 統合タブの「アダプタ変数」リージョンに表示される各変数にマッピングを設定します。それには、マップする変数の行ヘッダー(SolarisUserIDなど)をダブルクリックします。
変数のデータ・マッピング・ウィンドウが表示されます。

表8-13に、変数のデータ・マッピング・ウィンドウのフィールドを示します。

表8-13 変数のデータ・マッピング・ウィンドウのフィールド

フィールド名

説明

変数名

このフィールドには、マッピングを設定するアダプタ変数の名前(SolarisUserIDなど)が表示されます。

データ型

このフィールドには、アダプタ変数のデータ型が表示されます(たとえば、SolarisUserID変数のデータ型はStringです)。

マップ先

このフィールドには、アダプタ変数に設定可能なマッピング型(「IT リソース」など)が含まれます。アダプタ変数を場所または連絡先にマップする場合、Oracle Identity Managerで隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする場所または連絡先の特定のタイプを選択します。また、アダプタ変数をカスタム・プロセス・フォームにマップし、そのフォームに子表が含まれる場合、Oracle Identity Managerでフォームに隣接するコンボ・ボックスが有効になります。このコンボ・ボックスから、アダプタ変数をマップする子表を選択します。場所、連絡先またはカスタム・プロセス・フォームの子表にアダプタ変数をマップしない場合、このコンボ・ボックスは無効になります。

修飾子

このフィールドには、「マップ先」コンボ・ボックスで選択したマッピングの修飾子が含まれます(ITアセットなど)。

ITアセット・タイプ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、特定のITリソース(Solarisなど)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

ITアセット・プロパティ

このフィールドでは、アダプタ変数をITリソースにマップし、この変数のデータ型がStringである場合に、マッピングの結果を受け取る特定のフィールド(「ユーザー名」など)を選択できます。

アダプタ変数をITリソースにマップしない場合、またはアダプタ変数のデータ型がStringではない場合、このフィールドは表示されません。

重要: 「ITアセット・タイプ」および「ITアセット・プロパティ」フィールドは、下位互換性のためにこのウィンドウに含まれています。アダプタ変数を「ITリソース」データ型で作成することをお薦めします。この場合、これらのフィールドは表示されません。

リテラル値

アダプタ変数をリテラルにマップする場合、このフィールドでリテラル値を指定します。

アダプタ変数をリテラルにマップしない場合、このフィールドは表示されません。

古い値

このチェック・ボックスを選択して、選択した「修飾子」フィールドの変更前の値に、アダプタ変数をマップします。

プロセス・タスクに関連付けられたプロセス・タスク・アダプタは、プロセス・フォームのフィールドの一部が変更されると、条件付きでトリガーされる場合があります。「古い値」オプションをクリックし、プロセス・タスクを条件付きとしてマークした場合、フィールドを変更する前の値がアダプタに渡されます。これは、パスワードを使用するフィールドの場合に役立ちます。たとえば、パスワードに同じ値の設定を許可しない場合、比較に古い値を使用できます。

カスタム・プロセス・フォームの子表に属するフィールドにアダプタ変数をマップしない場合、このチェック・ボックスは無効になります。

11. 「マップ先」、「修飾子」、「ITアセット・タイプ」、「ITアセット・プロパティ」、「リテラル値」および「古い値」のすべてのフィールドに入力します。

関連項目:

選択するマッピングの詳細は、「アダプタ・マッピング情報」を参照してください。

12. ツールバーで「保存」をクリックします。次に、「閉じる」をクリックします。
変数のデータ・マッピング・ウィンドウが閉じます。統合タブが再びアクティブになります。

13. タスクの編集ウィンドウのツールバーで「保存」をクリックします。
「ステータス」フィールドの内容が、「マッピングが不完全」から「準備完了」に変わります。アダプタ変数のマッピング・ステータスも、「いいえ(N)」から「はい(Y)」に変わります。

14. ツールバーで「閉じる」をクリックします。
タスクの編集ウィンドウが閉じ、メイン画面が再びアクティブになります。Password Updatedタスクに追加したアダプタ(adpSOLARISPASSWORDUPDATED)が、「プロセス定義」フォームに表示されます。これは、adpSOLARISPASSWORDUPDATEDプロセス・タスク・アダプタがPassword Updatedプロセス・タスクにアタッチされたことを意味します。

ヒント:

プロセス・タスク・アダプタをプロセス・タスクにアタッチすると、「アダプタ・ファクトリ」フォームの使用方法の参照タブにアクセスすることで、関連付けられたプロセスおよびタスクを簡単に確認できます。

8.18.3 プロセス・タスク・アダプタのプロセス・タスクからの削除

Oracle Identity Managerで、プロセス・タスクを自動的に完了するためのプロセス・タスク・アダプタが不要になった場合、または別のアダプタをプロセス・タスクにアタッチする場合は、まずプロセス・タスクにアタッチしたアダプタを削除する必要があります。次の手順では、プロセス・タスク・アダプタをプロセス・タスクから削除する方法について説明します。

8.18.3.1 プロセス・タスク・アダプタのプロセス・タスクからの削除

1. 「プロセス定義」フォームを開きます。
Design Consoleワークスペースに、「プロセス定義」フォームが表示されます。

2. アダプタを削除するタスクを含むプロセス(Solarisプロセスなど)を選択します。
選択したプロセスとそのタスクが、「プロセス定義」フォームに表示されます。

3. アダプタを削除するプロセス・タスク(Password Updatedタスクなど)の行ヘッダーをダブルクリックします。
プロセス・タスクの情報を含むタスクの編集ウィンドウが表示されます。統合タブをクリックします。

4. 統合タブをクリックします。
統合タブに、プロセス・タスクにアタッチされたアダプタの情報が表示されます。

5. 「削除」をクリックします。
アダプタをプロセス・タスクから削除することを確認するダイアログ・ボックスが表示されます。

6. 「OK」をクリックします。
アダプタがプロセス・タスクから削除されたことを示すダイアログ・ボックスが表示されます。

7. 「OK」をクリックします。
アダプタの内容が統合タブに表示されなくなります。

8. ツールバーで「閉じる」をクリックします。
タスクの編集ウィンドウが閉じ、メイン画面が再びアクティブになります。Password Updatedタスクに関連付けられていたアダプタ(adpSOLARISPASSWORDUPDATED)が、「プロセス定義」フォームの子表に表示されなくなります。

これは、アダプタがプロセス・タスクから削除されたことを意味します。

8.19 アダプタ・マッピング情報

アダプタはアダプタ・ファクトリによって生成されるJavaクラスで、Oracle Identity Managerと外部JARファイル、ターゲットITリソース(リソース・アセットなど)またはユーザー定義フォームとのやり取りを可能にします。アダプタ・ファクトリはOracle Identity Managerで提供されるコード生成ツールで、これによりユーザー管理者がJavaクラスを作成できます。

アダプタにより、Oracle Identity Managerの内部ロジックと機能が拡張されます。プロセス・タスクが自動化され、Oracle Identity Manager内のフィールドに含まれるデータの自動生成と検証を行うためのルールが定義されます。アダプタには、タスク割当てアダプタ、タスク・アダプタ、ルール・ジェネレータ・アダプタ、事前移入アダプタおよびエンティティ・アダプタの5つのタイプがあります。

この項で説明する項目は、次のとおりです。

- アダプタ・タスク・マッピング情報

- アダプタ変数マッピング情報

8.19.1 アダプタ・タスク・マッピング情報

アダプタ・タスクはアダプタ内コンポーネントの1つです。これはアダプタ内の論理ステップで、プログラミング言語のメソッドの呼出しに相当します。使用可能なアダプタ・タスクのタイプは、関数タスク(Javaタスク、リモート・タスクおよびストアド・プロシージャ・タスク)、ユーティリティ・タスク(ユーティリティ・タスクおよびOracle Identity Manager APIタスク)およびロジック・タスク(変数設定タスクおよびエラー・ハンドラ・タスク)です。

この項では、アダプタ・タスクのパラメータに設定できるマッピングについて、次の項で示します。

- アダプタ変数

- アダプタ・タスク

- リテラル

- アダプタ参照

- 組織定義

- プロセス定義

- ユーザー定義

8.19.1.1 アダプタ変数

次の表に、Data Mapping for Variableウィンドウの「マップ先」リスト・ボックス、およびアダプタ・タスクに対するアダプタ変数のパラメータをマップする「名前」リスト・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「名前」コンボ・ボックス

説明

アダプタ変数

アダプタ変数のリストが表示されます。

このアダプタに作成したアダプタ変数に、パラメータをマップできます。

注意: アダプタ変数の分類タイプが「オブジェクト」の場合、プロセス・タスク・アダプタには使用できません。

注意: アダプタ変数の分類タイプが「ITリソース」の場合、「属性」コンボ・ボックスが表示されます。このコンボ・ボックスから、パラメータをマップするITリソースの属性を選択します。

8.19.1.2 アダプタ・タスク

次の表に、アダプタ・タスクのパラメータをマップする「アダプタ・ファクトリ」フォームの「マップ先」、「名前」および「Output」コンボ・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「名前」コンボ・ボックス

出力コンボ・ボックス

説明

アダプタ・タスク

アダプタ・タスクのリストが表示されます。

選択したアダプタ・タスクに関連する出力変数のリストが表示されます。

このアダプタに作成したアダプタ・タスクに、パラメータをマップできます。

8.19.1.3 リテラル

次の表に、アダプタ・タスクの定数(リテラル)をマップする「アダプタ・ファクトリ」フォームの「マップ先」、「タイプ」コンボ・ボックスおよび「値」フィールドの項目と説明を示します。

「マップ先」コンボ・ボックス

「タイプ」コンボ・ボックス

「値」フィールド

説明

リテラル

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

リテラルの値をこのフィールドに入力します。

パラメータをString、Boolean、Character、Byte、Date、Integer、Float、Long、ShortまたはDoubleデータ型にそれぞれマップできます。

8.19.1.4 アダプタ参照

次の表に、アダプタ・タスクのアダプタ参照をマップする「アダプタ・ファクトリ」フォームの「マップ先」および「タイプ」コンボ・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「タイプ」コンボ・ボックス

説明

アダプタ参照

イベント・ハンドラ名またはDatabase Reference

パラメータをアクティブ・アダプタにマップできます。

8.19.1.5 組織定義

次の表に、アダプタ・タスクに対する組織定義のパラメータをマップする「アダプタ・ファクトリ」フォームの「マップ先」および「フィールド」コンボ・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「フィールド」コンボ・ボックス

説明

組織定義

組織名

パラメータを「組織」フォームの「組織名」フィールドにマップできます。

組織タイプ

パラメータを「組織」フォームの「タイプ」フィールドにマップできます。

組織ID

パラメータを「組織」フォームの「組織#」フィールドにマップできます。

親組織

パラメータを「組織」フォームの「親組織」フィールドにマップできます。

組織ステータス

パラメータを「組織」フォームの「ステータス」フィールドにマップできます。

親組織ID

パラメータをACTデータベース表のparent_keyフィールドにマップできます。

「組織」フォームの「ユーザー定義フィールド」タブに表示される任意のフィールド

パラメータを選択したユーザー定義フィールドにマップできます。

8.19.1.6 プロセス定義

次の表に、アダプタ・タスクに対するプロセス定義のパラメータをマップする「アダプタ・ファクトリ」フォームの「マップ先」および「フィールド」コンボ・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「フィールド」コンボ・ボックス

説明

プロセス定義

名前

パラメータを「プロセス定義」フォームの「名前」フィールドにマップできます。

タイプ

パラメータを「プロセス定義」フォームの「タイプ」フィールドにマップできます。

8.19.1.7 ユーザー定義

次の表に、アダプタ・タスクに対するユーザー定義のパラメータをマップする「アダプタ・ファクトリ」フォームの「マップ先」および「フィールド」コンボ・ボックスの項目と説明を示します。

「マップ先」コンボ・ボックス

「フィールド」コンボ・ボックス

説明

ユーザー定義

ユーザー・キー

パラメータを「ユーザー」フォームの一意のレコードを表すキーにマップできます。

名

パラメータを「ユーザー」フォームの「名」フィールドにマップできます。

ミドル・ネームのイニシャル

パラメータを「ユーザー」フォームの「ミドル・ネーム」フィールドにマップできます。

姓

パラメータを「ユーザー」フォームの「姓」フィールドにマップできます。

ユーザー・ログイン

パラメータを「ユーザー」フォームの「ユーザーID」フィールドにマップできます。

パスワード

パラメータを「ユーザー」フォームのユーザー・パスワードにマップできます。

タイプ

パラメータを「ユーザー」フォームの「Xellerateタイプ」フィールドにマップできます。

ユーザー・ステータス

パラメータを「ユーザー」フォームの「ステータス」フィールドにマップできます。

ロール

パラメータを「ユーザー」フォームの「ロール」フィールドにマップできます。

アイデンティティ

パラメータを「ユーザー」フォームの「アイデンティティ」フィールドにマップできます。

無効

パラメータを「ユーザー」フォームの「ユーザーの無効化」チェック・ボックスにマップできます。

組織

パラメータを「ユーザー」フォームの「組織」フィールドにマップできます。

マネージャ

パラメータを「ユーザー」フォームの「マネージャ」フィールドにマップできます。

開始日

パラメータを「ユーザー」フォームの「開始日」フィールドにマップできます。

終了日

パラメータを「ユーザー」フォームの「終了日」フィールドにマップできます。

電子メール

パラメータを「ユーザー」フォームの「電子メール」フィールドにマップできます。

プロビジョニング日

パラメータを「ユーザー」フォームの「プロビジョニング日」フィールドにマップできます。

プロビジョニングされた日

パラメータを「ユーザー」フォームの「プロビジョニングされた日」フィールドにマップできます。

プロビジョニング解除日

パラメータを「ユーザー」フォームの「プロビジョニング解除日」フィールドにマップできます。

プロビジョニング解除された日

パラメータを「ユーザー」フォームの「プロビジョニング解除された日」フィールドにマップできます。

「ユーザー」フォームの「ユーザー定義フィールド」タブに表示される任意のフィールド

パラメータを選択したユーザー定義フィールドにマップできます。

8.19.2 アダプタ変数マッピング情報

新たに作成したアダプタを機能させるために、アダプタ・タスクのパラメータにデータをマップすることもできます。その場合は、プレースホルダ(アダプタ変数とも呼ばれる)を作成して、実行時にデータがマップされるようにします。アダプタの実行にアダプタ変数が不必要になった場合は、アダプタからアダプタ変数を削除できます。アダプタ変数を削除した後には、アダプタを再コンパイルしてください。

アダプタ変数がアダプタの戻り変数でないか、または「実行時に解決」として指定されていない場合、アダプタ変数は「アダプタ・ファクトリ」フォームの「変数リスト」タブ内でマップする必要があります。これに対し、アダプタ変数がアダプタの戻り変数として指定されているか、または「実行時に解決」に設定されている場合は、Oracle Identity Manager内の他の場所でマップできます。この場所はアダプタのタイプに依存します。たとえば、プロセス・タスク・アダプタの変数は、事前定義アダプタの変数とは異なる場所でマップされます。次の表に、変数のアダプタ・タイプごとの、マップ可能な場所を示します。

アダプタ・タイプ

場所

プロセス・タスク

タスクの編集ウィンドウの「統合」タブ

タスク割当て

タスクの編集ウィンドウの「割当て」タブ

ルール・ジェネレータ

「データ・オブジェクト・マネージャ」フォームの「アダプタのマップ」タブ

事前移入

「フォーム・デザイナ」フォームの「事前移入」タブ

エンティティ

「データ・オブジェクト・マネージャ」フォームの「アダプタのマップ」タブ

この項で説明する項目は、次のとおりです。

- 「変数リスト」タブ

- プロセス・タスク・アダプタ変数マッピング

- タスク割当てアダプタ変数マッピング

- ルール・ジェネレータおよびエンティティ・アダプタ変数マッピング

- 事前移入アダプタ変数マッピング

8.19.2.1 「変数リスト」タブ

次の表に、「変数リスト」タブから設定できるマッピングを示します。

変数タイプ

マップ先

修飾子/リソース・タイプ

オブジェクト

アダプタ参照

データベース参照

データ・オブジェクト参照

実行時に設定(タスク割当てアダプタの場合のみ)

データベース参照

データ・オブジェクト参照

ITリソース

実行時に解決

「ITリソース・タイプ定義」フォームの「表」に表示されるITリソース・タイプ

文字列、文字、バイト、整数、Float、Long、Short、Double

リテラル

アダプタ変数をリテラルにマップする場合は、「リソース・タイプ」コンボ・ボックスの下に「リテラル値」フィールドが表示されます。このフィールドに、このリテラルの値を入力します。

実行時に解決

該当なし

アダプタ参照

イベント・ハンドラ名

注意: アダプタ変数のデータ型がStringでない場合、「マップ先」コンボ・ボックスから「アダプタ参照」は選択できません。

ブール

リテラル

ブール値。このリソース・タイプを選択すると、「リソース・タイプ」コンボ・ボックスの下に、TrueとFalseの2つのリテラル値のオプションが表示されます。

アダプタ変数の値に対応するオプションを選択します。

実行時に解決

該当なし

日付

リテラル

アダプタ変数をリテラルにマップする場合は、「リソース・タイプ」コンボ・ボックスの下に「リテラル値」参照フィールドが表示されます。

この参照フィールドをダブルクリックします。表示された日時ウィンドウから、このリテラルの値となる日付と時間を選択します。

実行時に解決

該当なし

システム日付

該当なし

注意: この変数の値には、Oracle Identity Managerの日付と時間が反映されます。そのため、この変数に対してはマップは行いません。

8.19.2.2 プロセス・タスク・アダプタ変数マッピング

次の表に、プロセス・タスク・アダプタ変数マッピングを示します。

変数タイプ

マップ先

修飾子/説明

オブジェクト(アダプタの戻り変数)

プロセス・データ

パラメータを、関連するカスタム・プロセス・フォームまたはこのフォームに属する子表のフィールドにマップできます。

レスポンス・コード

該当なし

タスク情報

注意。パラメータを「タスク・リスト」フォームの「注意」タブにマップできます。

理由。パラメータを「エラーの詳細」ウィンドウにマップできます。このウィンドウにアクセスするには、「タスク・リスト」フォームに表示されたタスクをダブルクリックします。

プロセス定義

名前。パラメータを「プロセス定義」フォームの「名前」フィールドにマップできます。

タイプ。パラメータを「プロセス定義」フォームの「タイプ」参照フィールドにマップできます。

オブジェクト(アダプタの戻り変数)

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

注意: アダプタ変数のデータ型がObjectであるため、「修飾子」コンボ・ボックスから「組織ID」は選択できません。

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

ITリソース

ITリソース

パラメータをITリソースにマップできます。このITリソースは「ITリソース」タイプのメンバーで、「データ型」フィールド内から丸カッコ内に表示されます。

プロセス・データ

パラメータを、関連するプロセス固有のフォームのフィールドにマップできます。

注意: このコンボ・ボックスに表示される唯一のフィールド名は、「ITリソース」の参照フィールドのデータ型のものです。

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

プロセス・データ

パラメータを、関連するカスタム・プロセス・フォームまたはこのフォームに属する子表のフィールドにマップできます。

タスク情報

注意。パラメータを「タスク・リスト」フォームの「注意」タブにマップできます。

理由。パラメータを「エラーの詳細」ウィンドウにマップできます。このウィンドウにアクセスするには、「タスク・リスト」フォームに表示されたタスクをダブルクリックします。

プロセス定義

名前。パラメータを「プロセス定義」フォームの「名前」フィールドにマップできます。

タイプ。パラメータを「プロセス定義」フォームの「タイプ」参照フィールドにマップできます。

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

リテラル

アダプタ変数をリテラルにマップし、変数のデータ型がString、Character、Byte、Integer、Float、Long、ShortまたはDoubleの場合、「修飾子」コンボ・ボックスの下に「リテラル値」フィールドが表示されます。フィールドに、このリテラルの値を入力します。

アダプタ変数をリテラルにマップし、変数のデータ型がBooleanの場合、「修飾子」コンボ・ボックスの下に、TrueとFalseの2つのリテラル値のオプションが表示されます。アダプタ変数の値に対応するオプションを選択します。

アダプタ変数をリテラルにマップする場合で、かつ変数のデータ型がDateの場合、「修飾子」コンボ・ボックスの下に「リテラル値」参照フィールドが表示されます。この参照フィールドをダブルクリックします。表示された日時ウィンドウから、このリテラルの値となる日付と時間を選択します。

String

ITリソース

アダプタ変数をITリソースにマップする場合、「修飾子」、「ITアセット・タイプ」および「ITアセット・プロパティ」の3つのコンボ・ボックスが「マップ先」コンボ・ボックスの下に表示されます。これらのコンボ・ボックスから、マッピングの修飾子、ITリソースの特定の名前およびマッピングの結果を受け取るITリソースのフィールドを選択します。

注意: アダプタ変数のデータ型がStringでない場合、「マップ先」コンボ・ボックスから「ITリソース」は選択できません。

8.19.2.3 タスク割当てアダプタ変数マッピング

次の表に、タスク割当てアダプタ変数マッピングを示します。

変数タイプ

マップ先

修飾子/説明

ITリソース

オブジェクト・データ

パラメータをITリソースのインスタンス・キーにマップできます。このITリソースは「ITリソース」タイプのメンバーで、「データ型」フィールド内から丸カッコ内に表示されます。

ITリソース

パラメータをITリソースにマップできます。

オブジェクト(アダプタの戻り値)

オブジェクト・データ

パラメータを、関連するカスタム・リソース・オブジェクト・フォームまたはこのフォームに属する子表のフィールドにマップできます。

レスポンス・コード

該当なし

タスク情報

アダプタ変数をマップする「タスク・リスト」フォームのフィールド。

プロセス定義

アダプタ変数をマップする「プロセス定義」フォームのフィールド。

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

オブジェクト・データ

パラメータをリソース・オブジェクトのインスタンス・キーにマップできます。

タスク情報

アダプタ変数をマップする「タスク・リスト」フォームのフィールド。

プロセス定義

アダプタ変数をマップする「プロセス定義」フォームのフィールド。

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

情報のリクエスト

リクエストID。パラメータを「リクエスト」フォームの「リクエストID」フィールドにマップできます。

リクエスト・アクション。パラメータを「リクエスト」フォームの「リクエスト・アクション」フィールドにマップできます。

リクエスト優先度。パラメータを「リクエスト」フォームの「リクエスト優先度」フィールドにマップできます。

リクエスト・ターゲット・ユーザー

アダプタ変数をマップする「ユーザー」フォームのフィールド。

リクエスト・ターゲット組織

アダプタ変数をマップする「組織」フォームのフィールド。

リクエスタ情報

アダプタ変数をマップする「ユーザー」フォームのフィールド。

リテラル

アダプタ変数をリテラルにマップする場合は、「修飾子」コンボ・ボックスの下に「リテラル値」フィールドが表示されます。フィールドに、このリテラルの値を入力します。

注意: アダプタ変数のデータ型がBooleanの場合、フィールドのかわりにTrueとFalseの2つのオプションが表示されます。アダプタ変数の値を反映するオプションを選択します。

注意: アダプタ変数のデータ型がObjectの場合、「マップ先」コンボ・ボックスから「リテラル」は選択できません。

String

ITリソース

リソース・インスタンス。パラメータをITリソースのインスタンス・キーにマップできます。このITリソースは「ITリソース」タイプのメンバーで、「データ型」フィールド内から丸カッコ内に表示されます。

ITアセット・タイプ。パラメータをITリソース・タイプにマップできます。

String

ITリソース

ITアセット・プロパティ。このパラメータを、選択したITリソース・タイプを構成するプロパティの1つにマップできます。

8.19.2.4 ルール・ジェネレータおよびエンティティ・アダプタ変数マッピング

次の表に、ルール・ジェネレータおよびエンティティ・アダプタ変数マッピングを示します。

変数タイプ

マップ先

修飾子/説明

オブジェクト(アダプタの戻り変数)、ITリソース、String、Boolean、Character、Byte、Date、Integer、Float、Long、Short

リテラル

アダプタ変数をリテラルにマップする場合は、「修飾子」コンボ・ボックスの下に「リテラル値」フィールドが表示されます。フィールドに、このリテラルの値を入力します。

注意: アダプタ変数のデータ型がObjectの場合、「マップ先」コンボ・ボックスから「リテラル」は選択できません。

エンティティ・フィールド

アダプタ変数を、関連するプロセス・フォームのフィールドにマップできます。このフォームの名前は、「データ・オブジェクト・マネージャ」フォームの「フォームの説明」フィールドに表示されます。

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

注意: アダプタ変数のデータ型がObjectでない場合、「修飾子」コンボ・ボックスから「組織ID」および「親組織ID」は選択できません。

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

8.19.2.5 事前移入アダプタ変数マッピング

次の表に、事前移入アダプタ変数マッピングを示します。

変数タイプ

マップ先

修飾子/説明

ITリソース

ITリソース

パラメータをITリソースにマップできます。このITリソースは「ITリソース」タイプのメンバーで、「データ型」フィールド内から丸カッコ内に表示されます。

プロセス・データ

パラメータを、関連するプロセス固有のフォームのフィールドにマップできます。

注意: このコンボ・ボックスに表示される唯一のフィールド名は、「ITリソース」の参照フィールドのデータ型のものです。

Object、String、Boolean、Character、Byte、Date、Integer、Float、Long、Short、Double

プロセス・データ

パラメータを、関連するプロセス固有のフォームのフィールドにマップできます。

組織定義

アダプタ変数をマップする「組織」フォームのフィールド。

ユーザー定義

アダプタ変数をマップする「ユーザー」フォームのフィールド。

文字列、ブール、文字、バイト、日付、整数、Float、Long、Short、Double

リテラル

アダプタ変数をリテラルにマップし、変数のデータ型がString、Character、Byte、Integer、Float、Long、ShortまたはDoubleの場合、「修飾子」コンボ・ボックスの下に「リテラル値」フィールドが表示されます。フィールドに、このリテラルの値を入力します。

アダプタ変数をリテラルにマップし、変数のデータ型がBooleanの場合、「修飾子」コンボ・ボックスの下に、TrueとFalseの2つのリテラル値のオプションが表示されます。アダプタ変数の値に対応するオプションを選択します。

アダプタ変数をリテラルにマップする場合で、かつ変数のデータ型がDateの場合、「修飾子」コンボ・ボックスの下に「リテラル値」参照フィールドが表示されます。この参照フィールドをダブルクリックします。表示された日時ウィンドウから、このリテラルの値となる日付と時間を選択します。

String

ITリソース

アダプタ変数をITリソースにマップする場合、「修飾子」、「ITアセット・タイプ」および「ITアセット・プロパティ」の3つのコンボ・ボックスが「マップ先」コンボ・ボックスの下に表示されます。これらのコンボ・ボックスから、マッピングの修飾子、ITリソースの特定の名前およびマッピングの結果を受け取るITリソースのフィールドを選択します。

注意: アダプタ変数のデータ型がStringでない場合、「マップ先」コンボ・ボックスから「ITリソース」は選択できません。

8.20 エラー・メッセージの定義

図8-3に示す「エラー・メッセージ定義」フォームは、Design Consoleの「開発ツール」フォルダにあります。次の目的で使用します。

- 特定の問題が発生した場合にダイアログ・ボックスに表示されるエラー・メッセージを作成します。

- ユーザーが「アダプタ・ファクトリ」フォームを使用してエラー・ハンドラ・タスクを作成するときにアクセスできるエラー・メッセージを定義します。
作成したエラー・メッセージは、失敗の状態に基づいてエラー・ハンドラ・ロジック・タスクを使用して新しいアダプタを作成しているときにアダプタ定義に追加されと、Identity Self ServiceまたはIdentity System Administrationに表示されます。

注意:

フィールド値の検証のためにエンティティ・アダプタがプロセス・フォームまたはオブジェクト・フォームにアタッチされている場合、ダイレクト・プロビジョニングまたはリクエスト・プロビジョニングの完了後にこれらのフォームのデータを編集すると、これらのアダプタが実行されます。

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、新しいエンティティ・アダプタの作成はサポートされていません。

図8-3 「エラー・メッセージ定義」フォーム

表8-14に、「エラー・メッセージ定義」フォームのデータ・フィールドを示します。

表8-14 「エラー・メッセージ定義」フォームのフィールド

フィールド名

説明

キー

システムによって生成された、エラー・メッセージ定義の一意のID番号

コード

エラー・メッセージ定義を表すコード

カウントのリセット

このボタンをクリックすると、Oracle Identity Managerによってカウンタがゼロにリセットされます。このカウンタは、エラー・メッセージの表示回数です。

説明

エラー・メッセージの説明

処置

エラー・メッセージが表示される原因となった状態を修正する方法に関する説明

ヘルプURL

このエラー・メッセージに関するオンライン・ヘルプ・トピックを含むURLへのリンク

アクション

エラー・メッセージが表示される原因となった状態の重大度を表す1文字のコード。

エラー・メッセージの重大度には、「エラー」(E)、拒否(R)、致命的拒否(F)の3つのレベルがあります。

重大度

エラー・メッセージが表示される原因となった状態の重大度をさらに分類できます。

エラー・メッセージの重大度には、「なし」(N)、「低」(L)、「中」(M)、「高」(H)、クラッシュ(C)の5つのサブレベルがあります。

注意

エラー・メッセージに関する説明

エラー・メッセージを作成すると、Oracle Identity Managerによって「キー」フィールドに一意のID番号が移入されます。エラー・メッセージが表示される原因となる状態が発生すると、「説明」フィールドのテキストがダイアログ・ボックスに表示されます。

注意:

エラー・メッセージ定義の作成後、エラー・メッセージの表示回数をリセットするには、「カウントのリセット」ボタンをクリックします。これにより、カウントがゼロにリセットされます。

エラー・メッセージを作成するには、次の手順を実行します。

1. 「エラー・メッセージ定義」フォームを開きます。

2. 「コード」フィールドに、エラー・メッセージ定義を表すコードを入力します。

3. 「説明」フィールドに、エラー・メッセージの説明を入力します。

4. 処置フィールドに、エラー・メッセージが表示される原因となった状態を修正する方法に関する説明を入力できます。

5. 「ヘルプURL」フィールドに、このエラー・メッセージに関するオンライン・ヘルプ・トピックを含むURLへのリンクを入力できます。

6. (オプション)アクションの参照フィールドをダブルクリックします。
表示される「参照」ダイアログ・ボックスから、エラー・メッセージが表示される原因となった状態の重大度を表すコードを選択できます。これらのコードを重大度の低い順に示します。

- エラー(E)。エラー・メッセージが格納され、関連する操作のトリガーが阻止されます。かわりに、操作が前の操作にロールバックされます。

- 却下(R)。拒否メッセージが格納されますが、後続の操作の実行は阻止されません。

- 致命的拒否(F)。拒否メッセージが格納され、後続の操作のトリガーが阻止されます。ただし、致命的拒否までに実行されたすべての操作は格納されます。

7. (オプション)重大度の参照フィールドをダブルクリックします。表示された「参照」ダイアログ・ボックスから、コード(「なし」(N)、「低」(L)、「中」(M)、「高」(H)またはクラッシュ(C))を選択できます。このコードは、「アクション」参照フィールドに表示されるコードの詳細な分類です。

8. 「注意」フィールドに、エラー・メッセージに関する説明を入力します。

9. 「保存」をクリックします。
エラー・メッセージが作成されます。

「エラー・メッセージ定義」フォームを使用してエラー・メッセージを作成した後に、Oracle Identity ManagerのcustomResources.propertiesリソース・バンドルに新しいエラー・コードおよび忠告メッセージを追加する必要があります。これらのローカライズされたコードおよび忠告メッセージは、Identity Self ServiceまたはIdentity System Administrationに表示されます。

9 Identity Connector Frameworkの理解

アイデンティティ・コネクタは、Oracle Identity Managerをアプリケーション、ディレクトリおよびデータベースの外部ストアとリンクする目的で開発されたコンポーネントです。Oracle Identity Managerでは、Identity Connector Framework (ICF)を使用してアイデンティティ・コネクタを開発および構築できます。ICFにより、Oracle Identity Managerが接続先の他のアプリケーションから切り離されます。そのため、アイデンティティ・コネクタを構築およびテストしてから、Oracle Identity Managerと統合できます。この章は、概念情報およびコード例を示す次の項で構成されます。

- ICFの利点

- ICFアーキテクチャの概要

- ICF APIの使用

- ICF SPIの概要

- アイデンティティ・コネクタ・バンドルの拡張

- アイデンティティ・コネクタ・サーバーの使用

注意:

以前のリリースのOracle Identity Managerでは、他のオプションによってアイデンティティ・コネクタを構築していました。これらのオプションも引き続きサポートされていますが、ICFを使用して新しいアイデンティティ・コネクタを構築することをお薦めします。

9.1 ICFの利点

ICFには次の利点があります。

- 単一のプラットフォーム: アイデンティティ・コネクタは、Oracle Identity ManagerおよびOracle Waveset (OW)間で共有されており、OIMおよびOWの両方に単一のコネクタを使用して外部アイデンティティ対応のアプリケーションと通信できるように、同じプラットフォーム上に構築されています。

- 単純なインストール: ICFは、インストール中の手動の構成として、コネクタ・ファイルおよびコード・ファイルのコピーがICFによって自動的に処理されるなど、単純なインストールを提供します。

- 設計上ステートレス: アイデンティティ・コネクタは、設計上ステートレスです。アイデンティティ・コネクタには何も格納されません。コール側アプリケーションからコネクタに構成値(ターゲット・アプリケーションに接続するために必要な情報を含む)が提供されます。これは、アイデンティティ・コネクタがステートレスであるため、各バンドル実装はできるだけ単純な状態に保たれ、コール側アプリケーションの実装との結合も回避されます。

- ICF共通: ICFでは、OIMのICFベースのコネクタに共通のコネクタ統合レイヤーを提供し、ICF共通を開発するための開発作業は必要ありません。

- リモート実行: ICFでは、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行がサポートされています。

- JVMの独立性: リモートICFにより、JVMの独立性が提供され、異なるホストでのJavaコネクタの実行によるJVM競合を防止します。

- 再利用: 将来的に、他の製品でアイデンティティ・コネクタを再利用できます。

9.2 ICFアーキテクチャの概要

アイデンティティ・コネクタにより、Oracle Identity Managerが企業内のターゲット・システムでユーザーのプロビジョニングおよびリコンシリエーションの処理を実行できるようになります。ICFを使用すると、Oracle Identity Managerなどのコール側アプリケーションがコネクタの実装から切り離されます。同様に、コネクタの実装がコール側アプリケーションから切り離されます。同じコネクタ実装を複数の異なるコール側アプリケーションと連携させることができます。図9-1では、Oracle Identity Managerとターゲット・システムの間にICF APIおよびSPIを配置することによって、これを実現しています。

API実装では、必ず、SPI Search処理によって返された結果が後処理されます。コネクタ・バンドルによってすべてのフィルタ・タイプが実装されるわけではない場合、またはフィルタ・タイプがすべての属性に対して適切に実装されるわけではない場合、これがSPI実装の二重チェックになります。SPI Searchの実装によって、指定したタイプのすべてのオブジェクトが返される場合、API実装によって、指定したフィルタに一致しないすべてのオブジェクトが破棄されます。API実装における後処理は処理時間とネットワーク帯域幅の面でコスト高になるため、ターゲット・アプリケーションでネイティブにサポートできるすべてのタイプのフィルタ(検索述語や論理演算子)を各コネクタ・バンドルでサポートすると、より効率的です。詳細は、「共通クラス」のFilterTranslatorを参照してください。

図9-1では、コール側アプリケーションはICF APIのみを認識しています。ICF APIでは各コネクタ・バンドルに専用のクラスローダーが割り当てられるため、コネクタ・バンドル(SPI)の実装におけるクラスやライブラリにコール側アプリケーションは公開されません。バンドル・クラスローダーは、バンドル間を確実に分離するだけでなく、バンドルされたライブラリを対象のコネクタ・バンドルのみに公開して、依存関係による競合を防止する役割も担います。

図9-1 Identity Connector Frameworkのデプロイメント

図9-2に、ICFの下位互換性を示します。新しいバンドルをデプロイしても、既存のバンドルには影響しません。また、新しいバージョンのICFには、一般に既存のバンドルとの下位互換性があります。したがって、すべてのコネクタは、新しいバージョンのフレームワークで作業する必要があります。

図9-2 ICFとコネクタ・バンドルの互換性

図9-3は、ICFのデプロイメント方法を示しています。フレームワークでは、LCMでのコネクタのクローニングをサポートしており、同じターゲットの複数のバージョンをサポートします。また、フレームワークは接続プーリングもサポートします。

図9-3 同じターゲットの複数のバージョンをサポートするデプロイメント方法

図9-4は、リモート・システムにインストールされたフレームワークを示しています。これにより、ターゲットがコネクタ・バンドルに対してローカルでもリモートでも、Javaまたは.NET実装を使用したコネクタ・サーバーのリモート実行が可能になります。これは、アプリケーション内でコネクタ・バンドルが直接実行できない場合に必要で、ICFにより、アプリケーションが外部的にデプロイされたバンドルと通信できるようになります。また、コネクタ・アーティファクトは、ローカル・システムとリモート・システムで同じにできます。

図9-4 コネクタ・サーバーのリモート・システム・フレームワーク

図9-5は、ICFフレームワークを示しており、Oracle Identity ManagerおよびOracle Waveset (OW)コネクタを単一のコネクタに集中することができます。

図9-5 ICFフレームワーク

9.3 ICF APIの使用

org.identityconnectors.framework.apiパッケージには、ICF APIが含まれています。Oracle Identity Managerでは、このAPIを使用して、コネクタ実装をコールします。このAPIは、サポートされている処理に関係なく、実装されているコネクタに関して一貫した外観を提供します。次の各項では、これらのインタフェースおよびクラスについて説明します。

- ConnectorInfoManagerFactoryクラス

- ConnectorInfoManagerインタフェース

- ConnectorKeyクラス

- ConnectorInfoインタフェース

- APIConfigurationインタフェース

- ConfigurationPropertiesインタフェース

- ConnectorFacadeFactoryクラス

- ConnectorFacadeインタフェース

9.3.1 ConnectorInfoManagerFactoryクラス

ConnectorInfoManagerFactoryクラスは、Oracle Identity Managerが一連のバンドルからコネクタ・クラスをロードすることを可能にします。静的なgetInstanceメソッドは、ConnectorInfoManagerFactoryタイプのオブジェクトを返します。このオブジェクトを使用して、ConnectorInfoManagerへの参照を取得できます。(詳細は、第9.3.2項「ConnectorInfoManagerインタフェース」を参照してください。)例9-1に、ConnectorInfoManagerFactoryの実装を示します。

例9-1 ConnectorInfoManagerFactoryの実装

//create ConnectorInfoManagerFactory
ConnectorInfoManagerFactory cInfoManagerFactory =
ConnectorInfoManagerFactory.getInstance();

9.3.2 ConnectorInfoManagerインタフェース

ConnectorInfoManagerインタフェースは、ConnectorInfoインスタンスのリストを管理します。各インスタンスがアイデンティティ・コネクタを表します。ConnectorInfoManagerFactoryに対してgetLocalManagerメソッドをコールすると、ConnectorInfoManagerが取得され、それにバンドルURLのリストが渡されます。ConnectorInfoManagerは、ConnectorInfoManagerFactoryに対してgetRemoteManagerメソッドをコールすることによっても取得できます。getRemoteManagerメソッドは、コネクタ・サーバーにデプロイされたコネクタに関する情報を取得するために使用されるRemoteFrameworkConnectionInfoandのインスタンスを受け入れます。

例9-2では、cInfoManagerFactoryがConnectorInfoManagerFactoryのインスタンスであり、bundleURLがバンドルURL (JARバンドルまたはそれを解凍した内容で構成されるディレクトリをポイントするURL)のリストです。

例9-2 ConnectorInfoManagerの実装

//get the ConnectorInfoManager
ConnectorInfoManager cInfoManager =
cInfoManagerFactory.getLocalManager(bundleURL);

9.3.3 ConnectorKeyクラス

ConnectorKeyは、インストール環境内でConnectorインスタンスを一意に識別します。ConnectorKeyクラスには、例9-3に示すように、bundleName(コネクタ・バンドルの名前)、bundleVersion(コネクタ・バンドルのバージョン)およびconnectorName(コネクタ・バンドルの名前)を指定します。

例9-3 ConnectorKeyの実装

//get the ConnectorKey reference
ConnectorKey flatFileConnectorKey =
new ConnectorKey(bundleName, bundleVersion, connectorName);

9.3.4 ConnectorInfoインタフェース

ConnectorInfoインタフェースは、特定のアイデンティティ・コネクタに関する情報を格納します。格納されるのは、特定のアイデンティティ・コネクタに関する表示名、キーおよびメッセージの詳細です。例9-4に、ConnectorInfoを実装する方法を示します。

例9-4 ConnectorInfoの実装

//get the ConnectorInfo
ConnectorInfo info =
cInfoManager.findConnectorInfo(flatFileConnectorKey);

例では、cInfoManagerがConnectorInfoManagerであり、flatFileConnectorKeyがアイデンティティ・コネクタ・キーです。

9.3.5 APIConfigurationインタフェース

APIConfigurationインタフェースは、SPI側とAPI側の両方の構成プロパティを示します。getConfigurationPropertiesメソッドは、コネクタの構成実装に基づいてConfigurationPropertiesインスタンスを返し、このインスタンスはデフォルトに初期化されます。その後、コール元は必要に応じてプロパティを変更できます。例9-5に、これを示します。

例9-5 APIConfiguration定義

APIConfiguration apiConfig =
info.createDefaultAPIConfiguration();

9.3.6 ConfigurationPropertiesインタフェース

ConfigurationPropertiesインタフェースは、SPI構成をカプセル化し、リフレクションを使用して、アプリケーションで操作できる個々のプロパティを識別します。例9-6の定義に従って、setPropertyValueメソッドを使用してアイデンティティ・コネクタのすべての構成プロパティを設定します。

例9-6 setPropertyValueメソッド・シグネチャ

public void setPropertyValue
(java.lang.String name, java.lang.Object value)

例9-7に、ConfigurationPropertiesインタフェースの実装を示します。

例9-7 ConfigurationPropertiesの実装

//get the default APIConfiguration
ConfigurationProperties flatFileConfigProps =
apiConfig.getConfigurationProperties();

9.3.7 ConnectorFacadeFactoryクラス

ConnectorFacadeFactoryクラスは、アプリケーションがコネクタ・インスタンスを取得したり、コネクタ・インスタンスのプールを管理することを可能にします。例9-8に、ConnectorFacadeFactoryの定義を示します。

例9-8 ConnectorFacadeFactoryの定義

//get a reference to ConnectorFacadeFactory
ConnectorFacadeFactory facadeFactory =
ConnectorFacadeFactory.getinstance();

9.3.8 ConnectorFacadeインタフェース

ConnectorFacadeインタフェースは、ターゲット・システムでAPI側の特定のアイデンティティ・コネクタを表すことによってアイデンティティ・コネクタ処理を呼び出すために使用されます。例9-9に、ConnectorFacadeの実装を示します。

例9-9 ConnectorFacadeの実装

//create a ConnectorFacade (nothing but a reference to Connector on SPI side)
ConnectorFacade connectorFacade = facadeFactory.newInstance(apiConfig)

9.4 ICF SPIの概要

開発者は、ICF SPIを実装してアイデンティティ・コネクタを作成します。ICF SPIは多数のインタフェースで構成されますが、開発者が実装する必要があるのは、ターゲット・システムでサポートされているインタフェースのみです。SPIは、さらに必須インタフェース、処理インタフェースおよび機能ベースのインタフェースに分類できます。必須インタフェースは、サポートされている処理に関係なく実装する必要があり、コネクタの作成やターゲット・システムとの接続の維持に利用されるのに対し、処理インタフェースはコネクタで各種処理をサポートするために利用されます。機能ベースのインタフェースは、ICFでサポートされている特定の機能に対応しています。

詳細は、次の各項を参照してください。

- 必須インタフェースの実装

- 機能ベースのインタフェースの実装

- 処理インタフェースの実装

- 共通クラス

9.4.1 必須インタフェースの実装

2つのインタフェースの実装には、すべてのアイデンティティ・コネクタが必要になります。これらの2つのインタフェースは、ターゲット・システムとのアイデンティティ・コネクタを宣言し、初期化します。詳細は、次の各項を参照してください。

- org.identityconnectors.framework.spi.Connector

- org.identityconnectors.framework.spi.Configuration

9.4.1.1 org.identityconnectors.framework.spi.Connector

これはアイデンティティ・コネクタを宣言するためのメイン・インタフェースです。コネクタの多くは、接続が必要になったときにターゲット・システムとの接続を確立し、処理が終了したら接続を解除し、使用していたリソースをすべて解放します。インタフェースには、この目的のためにinitとdisposeのライフサイクル・メソッドが用意されています。

注意:

コネクタ実装には、configurationClassおよびdisplayNameKeyの情報を提供することによって、org.identityconnectors.framework.spi.ConnectorClassタイプでアノテーションを付ける必要があります。displayNameKeyは、Messages.propertiesファイルに定義されたキーにする必要があります。

すべてのコネクタ実装に@ConnectorClassというアノテーションを付ける必要があります。ICFではコネクタ・バンドル内の最上位にあるすべての.classファイルをスキャンし、@ConnectorClassというアノテーションが付いたクラスを探すため、このアノテーションは必須です(これにより、バンドルに定義されたコネクタは自動的に検出されます)。このアノテーションには、次の要素が必要です。

- configurationClass: このコネクタ用の構成クラス。このクラスにはターゲットに関するすべての情報が保持され、コネクタはこの情報を使用してターゲットに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行できます。構成クラスを実装する方法の詳細は、「org.identityconnectors.framework.spi.Configuration」を参照してください。

- displayNameKey: メッセージ・カタログに存在する必要がある表示名キー。

例9-10に、コネクタ実装のサンプルを示します。

例9-10 フラット・ファイル・コネクタの実装

/**
* Flat file connector implementation. This connector supports create,
* delete, search and update operations.
*/
@ConnectorClass
(configurationClass=FlatFileConfigurationImpl.class,
displayNameKey="FLAT_FILE_CONNECTOR")
public class FlatFileConnector implements Connector,
CreateOp, DeleteOp,SearchOp<Map<String, String>>,UpdateOp{

次に、例9-10について説明します。

- CreateOp: コネクタがターゲット・システムにエンティティを作成できるようにします。

- DeleteOp: コネクタがターゲット・システムのエンティティを削除できるようにします。

- SearchOp: コネクタがターゲット・システムのエンティティを検索できるようにします。

- UpdateOp: コネクタがターゲット・システムの既存のエンティティを更新できるようにします。

詳細は、「処理インタフェースの実装」を参照してください。

次の各項では、コネクタ・メソッドを実装する方法を例示する情報とコード例を示します。コネクタ実装に関する完全なコードは、「フラット・ファイル・コネクタの開発」を参照してください。

- initメソッドの実装

- disposeメソッドの実装

- getConfigurationメソッドの実装

9.4.1.1.1 initメソッドの実装

initメソッドは、コネクタを初期化します。コネクタは、@ConnectorClassというアノテーションが付いた構成インスタンスを使用して自分自身を初期化します。initメソッドには、引数として構成オブジェクトを指定します。構成オブジェクトには、コネクタがターゲット・システムに接続するために必要なすべての情報が保持されています。

例9-11に、JDK 1.6でインタフェースのinitメソッドを実装する方法を示します。

注意:

このドキュメントで紹介されているすべてのコード例において、JDK 1.6でインタフェースを実装するメソッドが使用されています。

例9-11 initメソッドの実装

@Override
public void init(Configuration config) {
this.flatFileConfig = (FlatFileConfiguration) config;

FlatFileIOFactory flatFileIOFactory =
FlatFileIOFactory.getInstance(flatFileConfig);
this.flatFileMetadata = flatFileIOFactory.getMetadataInstance();
this.flatFileParser = flatFileIOFactory.getFileParserInstance();
this.flatFileWriter = flatFileIOFactory.getFileWriterInstance();
log.ok("Initialization done");
}

注意:

FlatFileIOFactory、FlatFileMetadata、FlatFileParserおよびFlatFileWriterはサポート・クラスであり、ICFには含まれていません。これらのクラスの実装は、「フラット・ファイル・コネクタの開発」に例示されています。

例9-11に示すinitメソッドの実装では、次のことを行います。

- ターゲット・システムの構成情報を格納します。これは後で処理を実行するときに使用できます。

- プロビジョニングおよびリコンシリエーションの処理を実行するときに使用されるすべてのサポート・クラスを初期化します。

9.4.1.1.2 disposeメソッドの実装

disposeメソッドは、このコネクタ・インスタンスによって使用されていたリソースをすべて解放します。メソッドがコールされると、コネクタ・インスタンスが破棄され、使用できなくなります。例9-12に、disposeメソッドを実装する方法を示します。

例9-12 disposeメソッドの実装

/**
* Disposes any resource used by the connector.
*/
@Override
public void dispose() {
//close any open FileReader or FileWriter instances.

//close connection with the target

//close connection if any with database
}

9.4.1.1.3 getConfigurationメソッドの実装

getConfigurationメソッドは、initメソッドの使用時にコネクタに渡された構成インスタンスを返します。例9-13に、getConfigurationメソッドを実装する方法を示します。

例9-13 getConfigurationメソッドの実装

/**
* returns the Configuration of this connector
*/
@Override
public Configuration getConfiguration() {
return this.flatFileConfig;
}

注意:

コンポーネントは、初期化後に構成インスタンスにアクセスできる必要がある場合があります。これはアクセッサ・メソッドgetConfiguration()によってサポートされています。

9.4.1.2 org.identityconnectors.framework.spi.Configuration

このインタフェースの実装は、コネクタの構成をカプセル化します。構成実装にはターゲット・システムに関して必要なすべての情報が保持され、コネクタ実装はこの情報を使用してターゲット・システムに接続し、プロビジョニングおよびリコンシリエーションの各種処理を実行します。実装には、setterとgetterがプロパティに定義されたデフォルトのコンストラクタが必要です。宣言されたすべてのプロパティが必要になるわけではありませんが、必須のプロパティについては、アノテーションorg.identityconnectors.framework.spi.ConfigurationPropertyによって必須としてマークする必要があります。構成実装はJava beanであり、すべてのインスタンス変数(必須かどうかは問わない)がデフォルト値を持ちます。たとえば、文字列userNameはターゲット・システムに接続するために使用され、必須の属性です。このデフォルト値はNULLです。userNameが必須の属性である場合、ICFはOracle Identity Managerから値が提供されるものと想定します。言い換えると、Oracle Identity Managerはこのパラメータを見落としてはなりません。見落とされた場合、コネクタからConfigurationExceptionがスローされます。

実装自体がコネクタに渡される前に、その実装によってすべての必須プロパティが存在し、検証されたことがチェックされる必要があります。インタフェースには、この目的のためにvalidateメソッドが用意されています。たとえば、ターゲットのIPアドレス、ターゲットに接続するときのユーザー名、そのユーザーのパスワードなど、必須の構成パラメータが3つ存在するものとします。validateメソッドでは、regexを使用して、NULL以外の値および有効なIPアドレスをチェックできます。

注意:

ICFには、構成オブジェクトを拡張できる便利なベース・クラスorg.identityconnectors.framework.spi.AbstractConfigurationも用意されています。

例9-14 構成実装

/**
* Configuration implementation for the flat file connector.
*/
public class FlatFileConfigurationImpl extends AbstractConfiguration{

次の各項では、構成メソッドを実装する方法を例示する情報とコード例を示します。

構成実装では、次のメソッドの実装を提供する必要があります。

- validate()メソッド

- setConnectorMessages()メソッド

- getConnectorMessages()メソッド

9.4.1.2.1 validate()メソッド

validateメソッドは、すべての必須プロパティの値が設定されていることをチェックします。また、構成プロパティの値がすべて有効であることを検証します。言い換えると、構成プロパティのすべての値が期待される範囲内にあり、期待される形式になっていることを検証します。構成が有効でない場合、実装によって最も固有のRuntimeExceptionが生成されます。固有の例外が利用不可の場合、実装ではConfigurationExceptionをスローできます。例9-15に、validateメソッドを実装する方法を示します。

例9-15 validateメソッドの実装

@Override
public void validate() {
// Validate if file exists and is usable
boolean validFile = (this.storeFile.exists() &&
this.storeFile.canRead() &&
this.storeFile.canWrite() &&
this.storeFile.isFile());
if (!validFile)
throw new ConfigurationException("User store file not valid");
FlatFileIOFactory.getInstance(this);
}

ここでは、指定されたターゲット・フラット・ファイルが有効かどうか(ファイルであるか、書込み可能か、読取り可能かなど)がチェックされます。有効でない場合は、例外が生成されます。

validateメソッドの実装では、プロパティの検証時にターゲット・システムに接続しないでください。

注意:

この実装は、インスタンス変数(private File storeFile)およびサポート・クラス(FlatFileIOFactory)に依存します。完全な実装は、「フラット・ファイル・コネクタの開発」に例示されています。

9.4.1.2.2 setConnectorMessages()メソッド

setConnectorMessagesメソッドは、org.identityconnectors.framework.common.objects.ConnectorMessagesメッセージ・カタログ・インスタンスを設定し、コネクタがメッセージをローカライズすることを可能にします。例9-16に、setConnectorMessagesメソッドの定義を示します。

例9-16 setConnectorMessagesメソッドの定義

public final void setConnectorMessages(ConnectorMessages messages) {_connectorMessages = messages;}

9.4.1.2.3 getConnectorMessages()メソッド

getConnectorMessagesメソッドは、setConnectorMessagesメソッドによって設定されたConnectorMessagesを返します。例9-17に、getConnectorMessagesメソッドの定義を示します。

例9-17 getConnectorMessagesメソッドの定義

public final ConnectorMessages getConnectorMessages() {return _connectorMessages;}

9.4.2 機能ベースのインタフェースの実装

次の各項では、アイデンティティ・コネクタ・プーリングや属性の正規化を有効にするときに使用されるインタフェースについて説明します。

- org.identityconnectors.framework.spi.PoolableConnector

- org.identityconnectors.framework.spi.AttributeNormalizer

9.4.2.1 org.identityconnectors.framework.spi.PoolableConnector

ICFによる接続プーリングは、フレームワークでコネクタ・インスタンスのプールを管理し、プロビジョニングおよびリコンシリエーションの処理の実行時にそれらのコネクタ・インスタンスを使用できるようにする機能です。単純なConnectorインタフェースのかわりにPoolableConnectorインタフェースを実装することによって、コネクタでプーリングを使用できるようになります。この機能を使用するには、PoolableConnectorインタフェースを実装します。Connectorインタフェースを実装した場合、ICFは処理ごとに新しいコネクタ・インスタンスを作成し、ターゲットとの新しい接続を確立し、プロビジョニング/リコンシリエーションの処理を実行し、ターゲット・システムとの接続を解除し、最後にこのコネクタ・インスタンスを破棄します。したがって、PoolableConnectorを実装すると、構成可能なコネクタ・インスタンスのプールが管理され、多くの処理に再利用されるという利点があります。

構成可能なオプションの一部を次に示します。

- プール内のアイドル状態およびアクティブ状態のコネクタ・オブジェクトの最大数(_maxObjects)

- アイドル状態のコネクタ・オブジェクトの最大数(_maxIdle)

- 未使用のオブジェクトが利用可能になるのをプールで待つ最大時間(この時間が経過すると、オブジェクトを放棄)(_maxWait)

- アイドル状態のオブジェクトを追い出すまでの最小待機時間(_minEvictableIdleTimeMillis)

- アイドル状態のオブジェクトの最小数(_minIdle)

これらの値はコネクタAPI開発者が設定する必要があり、設定しなかった場合は、次のデフォルト値が使用されます。

- _maxObjects = 10

- _maxIdle = 10

- _maxWait = 150 * 1000 ms

- _minEvictableIdleTimeMillis = 120 * 1000 ms

- _minIdle = 1

PoolableConnectorインタフェースはConnectorインタフェースを拡張します。これを実装すると、ICFが提供するアイデンティティ・コネクタ・プーリングが有効になります。ICFでは、コネクタ・インスタンスが使用される前に、そのインスタンスが動作していることを確認する必要があります。インタフェースには、この目的のためにcheckAliveメソッドが用意されています。例9-18に、フラット・ファイルPoolableConnectorの実装のサンプルを示します。

例9-18 フラット・ファイルPoolableConnectorの実装

/**
* Flat file connector implementation. This is a poolable connector
which supports create, delete, search and update operations.
*/
@ConnectorClass
(configurationClass=FlatFileConfigurationImpl.class,
displayNameKey="FLAT_FILE_CONNECTOR")
public class FlatFileConnector implements PoolableConnector,
CreateOp, DeleteOp,SearchOp<Map<String, String>>,UpdateOp{

PoolableConnectorインタフェースを実装するには、第9.4.1.1項「org.identityconnectors.framework.spi.Connector」で説明したすべてのメソッドに加えて、checkAliveメソッドの実装を提供します。checkAliveメソッドは、コネクタ・インスタンスが動作しているかどうかを確認するためのもので、ターゲット・システムでの処理用に使用できます。checkAliveは頻繁にコールできるため、開発者は実装を高速化する必要があります。メソッドは、コネクタが動作しなくなったときに、固有のRuntimeException(利用可能な場合)をスローする必要があります。例9-19に、checkAliveメソッドを実装する方法を示します。

例9-19 checkAliveメソッドの実装

/**
* Checks if this connector is alive, if not throws a RuntimeException
*/
@Override
public void checkAlive() {
//check if the connector is still connected to target
}

9.4.2.2 org.identityconnectors.framework.spi.AttributeNormalizer

このインタフェースは、コネクタに渡される属性を正規化する必要がある場合に、実装する必要があります。正規化では、表示、消費または比較用に値が標準形式に変換されます。たとえば、正規化では、テキスト値を大文字または小文字に変換したり、空白の切捨てを行ったり、DNの要素を特定の方法で並べることができます。

インタフェースには、この目的のためにnormalizeAttributeメソッドが定義されています。このメソッドには、引数としてObjectClassと正規化対象の属性を指定し、戻り値は正規化した属性になります。属性の正規化は、次のような様々な項目を処理するときに適用されます。

- SearchOpに渡されるフィルタ

- SearchOpから返される結果

- SyncOpから返される結果

- UpdateAttributeValuesOpに渡される属性

- UpdateAttributeValuesOpから返されるUid

- UpdateOpに渡される属性

- UpdateOpから返されるUid

- CreateOpに渡される属性

- CreateOpから返されるUid

- DeleteOpに渡されるUid

例9-20に、normalizeAttributeメソッドの定義を示します。

例9-20 normalizeAttributeメソッドの定義

public Attribute normalizeAttribute (ObjectClass oClass, Attribute attribute) {
if (attribute instanceof Uid) {
return new Uid(LdapUtil.createUniformUid((String)newValues.get(0), configuration.getSuffix()));
}
}

9.4.3 処理インタフェースの実装

処理インタフェースごとに、コネクタがターゲット・システムで実行できるアクション(サポートされている場合)が定義されています。処理インタフェースは、org.identityconnectors.framework.spi.operationsパッケージに属しています。これらの処理インタフェースの名前は次のとおりですが、各インタフェースの詳細は後続の項を参照してください。

- AuthenticateOp

- CreateOp

- DeleteOp

- ResolveUsernameOp

- SchemaOp

- ScriptOnConnectorOp

- ScriptOnResourceOp

- SearchOp<T>SyncOp

- TestOp

- UpdateAttributeValuesOp

- UpdateOp

次の各項では、これらの処理のいくつかについて詳しく説明します。

- SchemaOpインタフェースの実装

- CreateOpインタフェースの実装

- DeleteOpインタフェースの実装

- SearchOpインタフェースの実装

- UpdateOpインタフェースの実装

9.4.3.1 SchemaOpインタフェースの実装

SchemaOpインタフェースを実装すると、ターゲット・システムで処理できるオブジェクトをコネクタが表すことが可能になります。コネクタから返されるスキーマは、コネクタが管理用に公開するオブジェクト・クラスを表します。各オブジェクト・クラスは、名前、説明および一連の属性定義を持ちます。各属性定義には、名前、構文の他、複数値、単一値、読取り可能、書込み可能などのプロパティを表す特定のフラグが含まれます。

コネクタから返されるスキーマは、コネクタが公開する各タイプのオブジェクトの属性を表します。内部表現からこのスキーマ形式への変換が必要になる場合もあります。それ以外に、スキーマは、ターゲットAPIへのコールを通じてのみネイティブに利用できる情報を属性として表す場合もあります。SPI実装でネイティブ表現とそれに対応するConnectorObjectの間のマッピングがどのように行われるかに関係なく、スキーマはメタデータを提供し、このメタデータを通じて、各タイプ(objectClass)のConnectorObject内に含まれるものとクライアントが想定する情報を表します。

このインタフェースを実装するには、例9-21の定義に従って、schemaメソッドの実装を提供します。

例9-21 schemaメソッド・シグネチャ

public Schema schema

実装では、このアイデンティティ・コネクタでサポートされるオブジェクトのタイプを含むスキーマを返す必要があります。

例9-22 schemaメソッドの実装

@Override
public Schema schema() {
SchemaBuilder flatFileSchemaBldr = new SchemaBuilder(this.getClass());
Set<AttributeInfo> attrInfos = new HashSet<AttributeInfo>();
for (String fieldName : flatFileMetadata.getOrderedTextFieldNames()) {
AttributeInfoBuilder attrBuilder = new AttributeInfoBuilder();
attrBuilder.setName(fieldName);
attrBuilder.setCreateable(true);
attrBuilder.setUpdateable(true);
attrInfos.add(attrBuilder.build());
}

// Supported class and attributes
flatFileSchemaBldr.defineObjectClass
(ObjectClass.ACCOUNT.getDisplayNameKey(), attrInfos);
return flatFileSchemaBldr.build();
}

注意:

返されるスキーマにUidが含まれないようにする必要があります。

9.4.3.2 CreateOpインタフェースの実装

CreateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの作成が可能になります。このインタフェースを実装するには、例9-23に示すように、create()メソッドの実装を提供します。

例9-23 createメソッド・シグネチャ

public Uid create
(ObjectClass objectClass, Set<Attribute> attributes,
OperationOptions options)

このメソッドには、ObjectClass(アカウントやグループなど)、一連のオブジェクト属性および処理オプションを指定します。実装では、渡されたオブジェクト属性とObjectClassで定義されたオブジェクト・タイプを使用して、ターゲット・システムにオブジェクトを作成します。ObjectClass引数では、作成対象のオブジェクトのクラスを指定します。作成対象のオブジェクトのクラスは、作成処理に対する入力の1つです。例9-24に示すように、ObjectClassはcreate()メソッドの最初の引数です。

例9-24 createメソッドの実装

@Override
public Uid create(ObjectClass arg0, Set<Attribute> attrs,
OperationOptions ops) {

System.out.println("Creating user account " + attrs);
assertUserObjectClass(arg0);
try {
FlatFileUserAccount accountRecord = new FlatFileUserAccount(attrs);
// Assert uid is there
assertUidPresence(accountRecord);

// Create the user
this.flatFileWriter.addAccount(accountRecord);

// Return uid
String uniqueAttrField = this.flatFileConfig
.getUniqueAttributeName();
String uniqueAttrVal = accountRecord
.getAttributeValue(uniqueAttrField);
System.out.println("User " + uniqueAttrVal + " created");

return new Uid(uniqueAttrVal);
} catch (Exception ex) {

// If account exists
if (ex.getMessage().contains("exists"))
throw new AlreadyExistsException(ex);

// For all other causes
System.out.println("Error in create " + ex.getMessage());
throw ConnectorException.wrap(ex);
}
}

処理が成功すると、ターゲット・システム上でのオブジェクト識別子を表すUidインスタンスが作成され、返されます。コール元は、このUidを使用して、作成されたオブジェクトを参照できます。

9.4.3.3 DeleteOpインタフェースの実装

DeleteOpインタフェースを実装すると、ターゲット・システムからのオブジェクトの削除が可能になります。このインタフェースを実装するには、例9-25の定義に従って、deleteメソッドの実装を提供します。

例9-25 deleteメソッド・シグネチャ

public void delete
(ObjectClass objectClass, Uid uid, OperationOptions options)

このメソッドには、ObjectClass(アカウントやグループなど)、ターゲット・システムから削除するオブジェクトのUidおよび処理オプションを指定します。実装では、指定されたUidで識別されるオブジェクトをターゲット・システムから削除します。オブジェクトがターゲット・システムに存在しない場合は、org.identityconnectors.framework.common.exceptions.UnknownUidExceptionが生成されます。例9-26に、deleteメソッドを実装する方法を示します。

例9-26 deleteメソッドの実装

@Override
public void delete(ObjectClass arg0, Uid arg1, OperationOptions arg2) {
final String uidVal = arg1.getUidValue();
this.flatFileWriter.deleteAccount(uidVal);
log.ok("Account {0} deleted", uidVal);
}

注意:

削除処理が失敗すると、ICFはRuntimeExceptionのサブクラスを生成します。詳細は、Oracle Fusion Middleware Java APIリファレンス(Identity Connector Framework用)を参照してください。

9.4.3.4 SearchOpインタフェースの実装

SearchOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの検索が可能になります。この場合、検索処理では次のことが行われます。

- 一般に指定される検索条件を実装するためのネイティブ・フィルタが作成されます。

- 実際の問合せが実行されます。

SPIでこれらのメソッドを実装すると、APIで検索をサポートできるようになります。APIでは、指定されたフィルタ条件をネイティブ検索条件に変換することなどによって、コネクタで実行されないすべてのフィルタを(結果の後処理を通じて)実行します。

このインタフェースを実装するには、次の各項にまとめられたcreateFilterTranslatorメソッドおよびexecuteQueryメソッドの実装を提供します。

- createFilterTranslatorメソッドの実装

- executeQueryメソッドの実装

9.4.3.4.1 createFilterTranslatorメソッドの実装

createFilterTranslatorメソッドは、API側から渡されたICFフィルタ・オブジェクトをネイティブ問合せに変換するFilterTranslator実装のインスタンスを返します。変換後、ICFは問合せをexecuteQueryメソッドに渡します。例9-27に、createFilterTranslatorメソッドの定義を示します。

例9-27 createFilterTranslatorメソッド・シグネチャ

public FilterTranslator createFilterTranslator
(ObjectClass oClass, OperationsOptions options)

注意:

NULLの戻り値は許可されていません。

例9-28に、createFilterTranslatorメソッドの実装を示します。

例9-28 createFilterTranslatorメソッドの実装

@Override
public FilterTranslator<Map<String, String>> createFilterTranslator
(ObjectClass arg0, OperationOptions arg1) {
return new ContainsAllValuesImpl() {
};
}

この例では、単一タイプの検索述語(ContainsAllValues)のみがサポートされています。ContainsAllValuesImplの実装例は、「AbstractFilterTranslator<T>の実装」を参照してください。ContainsAllValuesの実装では、条件の形式をネイティブ形式に変換します。属性Aには、すべての値V(1)、V(2) ... V(N)が含まれます。

org.identityconnectors.framework.common.objects.filter.FilterTranslatorの詳細は、「共通クラス」を参照してください。

9.4.3.4.2 executeQueryメソッドの実装

executeQueryメソッドは、FilterTranslatorの実装(「createFilterTranslatorメソッドの実装」を参照)によって生成されるすべての問合せに対してコールされます。例9-29に示すように、ObjectClass(アカウントやグループなど)、問合せ、見つかったオブジェクトを処理するときにコールバックとして使用されるResultsHandlerのインスタンスおよび処理オプションを指定します。

例9-29 executeQueryメソッド・シグネチャ

public void executeQuery
(ObjectClass oClass, T query,
ResultsHandler handler, OperationOptions options)

executeQueryメソッドの実装では、渡された問合せを使用してターゲット・オブジェクトを検索し、見つかったターゲット・オブジェクトごとにConnectorObjectのインスタンスを作成し、ResultsHandlerを使用してConnectorObjectを処理します。ConnectorObjectは、ターゲット・リソース・オブジェクトのICF表現です。ObjectClass、Uid、名前、一連の属性などの情報が保持されます。ConnectorObjectは検索の中心となります。executeQueryは、ConnectorObjectをストリームとしてResultsHandlerに送り、そしてクライアントに送ります。例9-30に、exectueQueryメソッドを実装する方法を示します。

例9-30 executeQueryメソッドの実装

@Override
public void executeQuery(ObjectClass objectClass,
Map<String, String> matchSet, ResultsHandler resultHandler,
OperationOptions ops) {

// searches the flat file for accounts which fulfil the condition 'matchSet' created by FilterTranslator
Iterator<FlatFileUserAccount> userAccountIterator = this.flatFileParser
.getAccountIterator(matchSet);

boolean handleMore = true;
while (userAccountIterator.hasNext() && handleMore) {
FlatFileUserAccount userAcc = userAccountIterator.next();
ConnectorObject userAccObject = convertToConnectorObject(userAcc);
// Let the client handle the result by doing callback
handleMore = resultHandler.handle(userAccObject);
}
while (userAccountIterator.hasNext()) {
FlatFileUserAccount userAcc = userAccountIterator.next();
ConnectorObject userAccObject = convertToConnectorObject(userAcc);
if (!resultHandler.handle(userAccObject)) {
System.out.println("Not able to handle " + userAcc);
break;
}
}
}

9.4.3.5 UpdateOpインタフェースの実装

UpdateOpインタフェースを実装すると、ターゲット・システムでのオブジェクトの更新が可能になります。このインタフェースを実装するには、例9-31の定義に従って、updateメソッドの実装を提供します。

例9-31 updateメソッド・シグネチャ

public Uid update(ObjectClass oClass, Uid uid,
Set<Attribute> attributes, OperationOptions options)

このメソッドには、ObjectClass(アカウントやグループなど)、更新対象のオブジェクトのUid、更新対象の一連のオブジェクト属性および処理オプションを指定します。実装では、ターゲット・システム上でUidによって識別されるオブジェクトを新しい属性値で更新します。Uidによって識別されるオブジェクトがターゲット・システムに存在しない場合は、UnknowUidExceptionが生成されます。例9-32に、updateメソッドを実装する方法を示します。

例9-32 updateメソッドの実装

@Override
public Uid update(ObjectClass arg0, Uid arg1,
Set<Attribute> arg2, OperationOptions arg3) {
String accountIdentifier = arg1.getUidValue();
// Fetch the account
FlatFileUserAccount accountToBeUpdated = this.flatFileParser
.getAccount(accountIdentifier);

// Update
accountToBeUpdated.updateAttributes(arg2);
this.flatFileWriter
.modifyAccount(accountIdentifier, accountToBeUpdated);
log.ok("Account {0} updated", accountIdentifier);

// Return new uid
String newAccountIdentifier = accountToBeUpdated
.getAttributeValue
(this.flatFileConfig.getUniqueAttributeName());
return new Uid(newAccountIdentifier);
}

9.4.4 共通クラス

前の各項で示したように、ICFには多数のクラスが用意されています。最も重要なクラスは次のとおりです。

- org.identityconnectors.framework.common.objects.Attribute
属性は、ターゲット・システム・オブジェクト内の値の名前付きコレクションです。ターゲット・システム・オブジェクトには多数の属性が保持され、それぞれの属性が多数の値を持つ場合があります。最も単純な形式の属性は、ターゲット・システム・オブジェクトの名前/値ペアとみなすことができます。空の値およびNULL値がサポートされています。開発者は、org.identityconnectors.framework.common.objects.AttributeBuilderを使用して、属性インスタンスを構築する必要があります。

注意:

このモデルでは、すべての属性が構文的に複数値になります。単一値になる特定の属性は、セマンティック制限のみです。

- org.identityconnectors.framework.common.objects.Uid
ターゲット・リソース上でのオブジェクトの一意の識別子を表す単一値属性です(Uidは属性のサブクラスです)。理想的には、不変である必要があります。

注意:

単一値属性は、特に一意の識別子となるUIDに関連します。

- org.identityconnectors.framework.common.objects.ObjectClass
ObjectClassは、ターゲット・システム上のオブジェクトのタイプを定義します。このようなタイプの例としては、アカウント、グループまたは組織があります。ICFでは、アカウントのObjectClassとしてObjectClass.ACCOUNT、グループのObjectClassとしてObjectClass.GROUPが事前に定義されています。

- org.identityconnectors.framework.common.objects.ConnectorObject
ConnectorObjectは、ターゲット・システム上のオブジェクト(アカウントやグループなど)を表します。開発者は、org.identityconnectors.framework.common.objects.ConnectorObjectBuilderを使用して、ConnectorObjectを構築する必要があります。

- org.identityconnectors.common.security.GuardedString
ガード文字列は、パスワードをメモリーにプレーン文字列形式で格納するという問題を解決するセキュアな文字列実装です。パスワードは、暗号化された形式でバイトとして格納されます。暗号化鍵はランダムに生成されます。

- org.identityconnectors.framework.common.objects.filter.FilterTranslator
FilterTranslaterオブジェクトは、検索処理の実行時に、ICFのAPI側で指定されたすべてのフィルタをネイティブ問合せに変換します。ICFフィルタでは、検索述語と論理演算子の両方がサポートされています。

- 検索述語では、指定した属性の値に基づいてオブジェクトを照合します。たとえば、EqualsFilterは、少なくとも1つの属性値が指定した値と等しい場合に、trueを返します。

- 論理演算子ANDおよびORでは、検索述語を結合して、複雑な式を作成します。たとえば、「A AND B」という形式の式は、AとBの両方がtrueの場合にのみtrueになります。「A OR B」という形式の式は、AとBの少なくとも一方がtrueの場合にtrueになります。

ICFが提供するAbstractFilterTranslator<T>ベース・クラスを使用すると、検索の実装が容易になります。FilterTranslatorサブクラスは、次のものを可能なかぎりオーバーライドする必要があります。

- createAndExpression(T, T)

- createOrExpression(T, T)

- createContainsExpression(ContainsFilter, boolean)

- createEndsWithExpression(EndsWithFilter, boolean)

- createEqualsExpression(EqualsFilter, boolean)

- createGreaterThanExpression(GreaterThanFilter, boolean)

- createGreaterThanOrEqualExpression(GreaterThanOrEqualFilter, boolean)

- createStartsWithExpression(StartsWithFilter, boolean)

- createContainsAllValuesExpression(ContainsAllValuesFilter, boolean)

詳細は、第9.4.3.4項「SearchOpインタフェースの実装」を参照してください。

- org.identityconnectors.framework.common.objects.ResultsHandler
これは、処理で1つ以上の結果が返される場合のコールバック・インタフェースです。サブクラスはメソッドを処理するための実装を提供する必要があるのに対し、コール元は結果に対する処理を決めることができます。現在、これはSearchOpインタフェースでのみ使用されます。詳細は、第9.4.3.4項「SearchOpインタフェースの実装」を参照してください。

9.5 アイデンティティ・コネクタ・バンドルの拡張

アイデンティティ・コネクタ・バンドルは、特定のターゲット・システムに固有の実装です。バンドルは、アイデンティティ・コネクタがターゲット・システムに接続し、処理を実行するために必要なすべてのファイルを含むJavaアーカイブ(JAR)として提供されます。ICFで認識される特別な属性(MANIFESTファイルで定義)も含まれます。それらは次のとおりです。

- ConnectorBundle-FrameworkVersionは、このアイデンティティ・コネクタ・バンドルを動作させるために最低限必要なICFのバージョンです。新しいICFバージョンには下位互換性があります。

- ConnectorBundle-Nameは、このアイデンティティ・コネクタ・バンドルの一意の名前です。一般に、パッケージ名になります。

- ConnectorBundle-Versionは、このバンドルのバージョンです。Oracle Identity Managerの特定のデプロイメント内で、ConnectorBundle-NameとConnectorBundle-Versionの組合せが一意になるようにする必要があります。

共通クラスを再利用する場合などに、アイデンティティ・コネクタ・バンドルを拡張します。AbtractDatabaseConnectorがよい例です。異なるタイプのコネクタで、JDBCを使用してデータベース表にアクセスする同一の基本ロジックを再利用できるためです。データベース表用のコネクタは、この共通コードをOracle Databaseユーザー用のコネクタ、IBM DB2データベース・ユーザー用のコネクタおよびMySQLユーザー用のコネクタと共有できます。

特定のコネクタを拡張するには、拡張したバンドルを新しいバンドルの/libディレクトリに追加し、ターゲット・クラスをサブクラス化する新しいクラスを作成します。この方法は、AbstractDatabaseConnectorバンドルを使用して例示できます。共通ロジックは、次のように共通バンドルに含まれます。

注意:

元のバンドルは拡張しません。かわりに、元のバンドルをラップする新しいバンドルの中に元のバンドルを組み込むことで、コネクタを拡張します。

- META-INF/MANIFEST.MF

- ConnectorBundle-FrameworkVersion: 1.0

- ConnectorBundle-Name: org.identityconnectors.database.common

- ConnectorBundle-Version: 1.0

- org.identityconnectors/database/common/AbstractDatabaseConnector.class

注意:

このアイデンティティ・コネクタには、@ConnectorClassというアノテーションは付きません。

- org/identityconnectors/database/common/*(その他の共通ソース・ファイル)

- lib/

データベース(リソース)に固有のバンドルを必要な数だけ使用できます。例:

- META-INF/MANIFEST.MF

- ConnectorBundle-FrameworkVersion: 1.0

- ConnectorBundle-Name: org.identityconnectors.database.mysql

- ConnectorBundle-Version: 1.0

- org/identityconnectors/database/mysql/MySQLConnector.class (AbstractDatabaseConnectorのサブクラス)

注意:

このアイデンティティ・コネクタには、@ConnectorClassというアノテーションが付きます。

- org/identityconnectors/database/mysql/*(その他のMySQLソース・ファイル)

- lib/org.identityconnectors.database.common-1.0.jar(前述の親バンドル)

- lib/*(特定のデータベース・ドライバおよびライブラリ(必要に応じて))

9.6 アイデンティティ・コネクタ・サーバーの使用

アイデンティティ・コネクタ・バンドルがアプリケーション内で直接実行されない場合は、アイデンティティ・コネクタ・サーバーが必要です。ICFアーキテクチャでは、1つ以上のアイデンティティ・コネクタ・サーバーを使用することで、アプリケーションと外部にデプロイされたアイデンティティ・コネクタ・バンドルとの通信が可能になります。アイデンティティ・コネクタ・サーバーは、Java (tm)およびMicrosoft .NET Frameworkアプリケーションに対応しています。

単一のコネクタ・サーバーで複数のICFコネクタをサポートでき、これらのICFコネクタのタイプもそれぞれ異なっていてかまいません。単一のICFコネクタを使用して、複数のターゲットと通信できます。

図9-6に、Oracle Identity ManagerコネクタがICFコネクタを介してリソースと統合される仕組みを示します。

図9-6 ICFコネクタおよびコネクタ・サーバー

次に、図9-6について説明します。

- Oracle Identity Managerコネクタは、ターゲット・リソースと直接対話することはありません。かわりに、適切なICFコネクタを介して、作成、読取り、更新、削除および問合せ(CRUDQ)の各処理が実行されます。

- 単一のICFコネクタを使用して、リソース・タイプが同じ複数のリソースに接続できます。図9-6では、LDAP用のICFコネクタを使用して、ローカルLDAPリソースとリモートLDAPリソースの両方に接続しています。

- .NETコネクタ・サーバーを使用して、.NET ICFコネクタをターゲット・ホストにデプロイします。この方法でActive Directoryリソースが接続されます。

- Google Apps用のICFコネクタは、インターネット上のGoogle Appsとの接続に使用されます。

- 図には示されていませんが、コネクタ・サーバーではリソース・タイプが異なる複数のICFコネクタをサポートできます。

コネクタ・サーバーのタイプについては、次の各項で説明します。

- Javaコネクタ・サーバーの使用

- Microsoft .NET Frameworkコネクタ・サーバーの使用

ヒント:

どちらのコネクタ・サーバーを構成する場合も、次の情報(インストール時に定義)を準備してください。

- ホスト名およびIPアドレス

- コネクタ・サーバー・ポート

- コネクタ・サーバー・キー

- SSL対応

9.6.1 Javaコネクタ・サーバーの使用

アプリケーションと同じJava仮想マシン(JVM)でJavaコネクタ・バンドルを実行しない場合は、Javaコネクタ・サーバーを使用します。バンドルを管理対象ターゲット・システムと同じホストにデプロイすると、動作速度が向上するため、このデプロイメントはパフォーマンスの面で有効です。また、Javaコネクタ・サーバーを使用すると、JNIベースのコネクタの障害が原因でアプリケーションJVMがクラッシュする可能性を排除できます。

Javaコネクタ・サーバーの使用方法については、次の各項で説明します。

- Javaコネクタ・サーバーのインストールおよび構成

- Microsoft WindowsでのJavaコネクタ・サーバーの実行

- SolarisおよびLinuxでのJavaコネクタ・サーバーの実行

- Javaコネクタ・サーバーへのアイデンティティ・コネクタのインストール

- SSLを使用したコネクタ・サーバーとの通信

9.6.1.1 Javaコネクタ・サーバーのインストールおよび構成

Javaコネクタ・サーバーをインストールおよび構成するには、次の手順を実行します。

1. Javaコネクタ・サーバーをインストールするコンピュータに新しいディレクトリを作成します。この項では、このディレクトリをCONNECTOR_SERVER_HOMEとしています。

2. 手順1で作成した新しいディレクトリにJavaコネクタ・サーバー・パッケージを解凍します。Javaコネクタ・サーバーは、次のURLにあるOracle Technology Network Webサイトからダウンロードできます。
http://www.oracle.com/technetwork/index.html

3. conf/ディレクトリにあるConnectorServer.propertiesファイルで、デプロイメントで必要になるプロパティを設定します。表9-1に、ConnectorServer.propertiesファイル内のプロパティを示します。

表9-1 ConnectorServer.propertiesファイル内のプロパティ

プロパティ

説明

connectorserver.port

Javaコネクタ・サーバーがリクエストをリスニングするポート。デフォルト値は8759です。

connectorserver.bundleDir

コネクタ・バンドルがデプロイされるディレクトリ。デフォルト値はbundlesです。

connectorserver.libDir

依存ライブラリを配置するディレクトリ。デフォルト値はlibです。

connectorserver.usessl

trueに設定すると、Javaコネクタ・サーバーでSSLを使用してセキュアな通信が実現されます。デフォルト値はfalseです。

trueを指定する場合は、Javaコネクタ・サーバーの起動時にコマンドラインで次のオプションを使用してください。

- -Djavax.net.ssl.keyStore

- -Djavax.net.ssl.keyStoreType(オプション)

- -Djavax.net.ssl.keyStorePassword

connectorserver.ifaddress

バインド・アドレス。このプロパティを設定する場合は、必要に応じてファイル内でプロパティのコメントアウトを解除してください。バインド・アドレスは、コンピュータにその他のNICが取り付けられている場合に役立ちます。

connectorserver.key

Javaコネクタ・サーバー・キー。

4. ConnectorServer.propertiesファイル内のプロパティを次のように設定します。

- connectorserver.keyを設定するには、/setKeyオプションを指定してJavaコネクタ・サーバーを実行します。詳細は、「Microsoft WindowsでのJavaコネクタ・サーバーの実行」および「SolarisおよびLinuxでのJavaコネクタ・サーバーの実行」を参照してください。

- その他すべてのプロパティについては、ConnectorServer.propertiesファイルを手動で編集します。

5. confディレクトリにはlogging.propertiesファイルもあり、デプロイメントで必要になる場合は編集できます。

9.6.1.2 Microsoft WindowsでのJavaコネクタ・サーバーの実行

Microsoft WindowsでJavaコネクタ・サーバーを実行するには、次のようにConnectorServer.batスクリプトを使用します。

1. 「Javaコネクタ・サーバーのインストールおよび構成」の説明に従って、デプロイメントで必要になるプロパティをConnectorServer.propertiesファイルで設定したことを確認します。

2. CONNECTOR_SERVER_HOME\binディレクトリに移動し、ConnectorServer.batスクリプトを探します。
表9-2に、ConnectorServer.batスクリプトでサポートされているオプションを示します。

表9-2 ConnectorServer.batスクリプトでサポートされているオプション

オプション

説明

/install [serviceName] ["-J java-option"]

Javaコネクタ・サーバーをMicrosoft Windowsサービスとしてインストールします。

必要に応じて、サービス名およびJavaオプションを指定できます。サービス名を指定しない場合は、ConnectorServerJavaがデフォルトの名前として使用されます。

/run ["-J java-option"]

コンソールからJavaコネクタ・サーバーを実行します。

必要に応じて、Javaオプションを指定できます。たとえば、Javaコネクタ・サーバーをSSL対応として実行するには、次のようにします。

ConnectorServer.bat /run
"-J-Djavax.net.ssl.keyStore=mykeystore.jks"
"-J-Djavax.net.ssl.keyStorePassword=password"

/setKey [key]

Javaコネクタ・サーバー・キーを設定します。ConnectorServer.batスクリプトでは、ConnectorServer.propertiesファイル内のconnectorserver.keyプロパティにキーのハッシュ値を格納します。

/uninstall [serviceName]

Javaコネクタ・サーバーをアンインストールします。サービス名を指定しない場合は、スクリプトによってConnectorServerJavaサービスがアンインストールされます。

3. Javaコネクタ・サーバーを停止する必要がある場合は、対応するMicrosoft Windowsサービスを停止します。

9.6.1.3 SolarisおよびLinuxでのJavaコネクタ・サーバーの実行

SolarisおよびLinuxでJavaコネクタ・サーバーを実行するには、次のようにconnectorserver.shスクリプトを使用します。

1. 「Javaコネクタ・サーバーのインストールおよび構成」の説明に従って、デプロイメントで必要になるプロパティをConnectorServer.propertiesファイルで設定したことを確認します。

2. CONNECTOR_SERVER_HOME/binディレクトリに移動します。

3. chmodコマンドを使用して、connectorserver.shスクリプトを実行可能にするための権限を設定します。

4. connectorserver.shスクリプトを実行します。
表9-3に、connectorserver.shスクリプトでサポートされているオプションを示します。

表9-3 connectorserver.shスクリプトでサポートされているオプション

オプション

説明

/run [ -Jjava-option ]

コンソールからJavaコネクタ・サーバーを実行します。必要に応じて、1つ以上のJavaオプションを指定できます。たとえば、Javaコネクタ・サーバーをSSL対応として実行するには、次のようにします。

./connectorserver.sh /run
-J-Djavax.net.ssl.keyStore=mykeystore.jks
-J-Djavax.net.ssl.keyStorePassword=password

/start [ -Jjava-option ]

Javaコネクタ・サーバーをバックグラウンドで実行します。必要に応じて、1つ以上のJavaオプションを指定できます。

/stop

プロセスが終了するまで最大で5秒間待ってから、Javaコネクタ・サーバーを停止します。

/stop n

プロセスが終了するまで最大でn秒間待ってから、Javaコネクタ・サーバーを停止します。

/stop -force

Javaコネクタ・サーバーを停止します。最大で5秒間待った後もまだプロセスが実行されている場合は、kill -KILLコマンドを使用します。

/stop n -force

Javaコネクタ・サーバーを停止します。最大でn秒間待った後もまだプロセスが実行されている場合は、kill -KILLコマンドを使用します。

/setKey key

Javaコネクタ・サーバー・キーを設定します。connectorserver.shスクリプトでは、ConnectorServer.propertiesファイル内のconnectorserver.keyプロパティにキーのハッシュ値を格納します。

9.6.1.4 Javaコネクタ・サーバーへのアイデンティティ・コネクタのインストール

この項では、Javaコネクタ・サーバーにJavaコネクタ・バンドルをデプロイする手順について説明します。

1. Javaコネクタ・サーバー・ディレクトリのbundlesディレクトリに移動します。

2. Javaコネクタ・バンドルJARをbundlesディレクトリにコピーします。

3. アイデンティティ・コネクタで必要になるサード・パーティJARファイルが存在する場合は、それらをlibディレクトリに追加します。

4. Javaコネクタ・サーバーを再起動します。

9.6.1.5 SSLを使用したコネクタ・サーバーとの通信

Secure Sockets Layer (SSL)を使用してコネクタ・サーバーと通信するには、次の手順を実行します。

1. コネクタ・サーバーのシステムにSSL証明書をデプロイします。

2. SSLソケットを提供するようにコネクタ・サーバーを構成します。

3. SSLを使用してコネクタ・サーバーと通信するようにアプリケーションを構成します。
アイデンティティ・コネクタ・サーバーとの接続構成に固有の注意事項は、ターゲット・システムのマニュアルを参照してください。各SSL対応コネクタ・サーバーとの接続を確立するときにはSSL接続が必要になることをアプリケーションに指示します。さらに、コネクタ・サーバーで使用されるSSL証明書のいずれかが非標準認証局によって発行される場合は、追加の認証局を考慮するようにアプリケーションを構成する必要があります。認証局に関する注意事項は、該当するマニュアルを参照してください。

注意:

Javaアプリケーションにおいて非標準認証局に関する問題を解決するには、アプリケーションの起動時に次のJavaシステム・プロパティが渡されるようにします。

- javax.net.ssl.trustStorePassword
例:

-Djavax.net.ssl.trustStorePassword=changeit

- javax.net.ssl.trustStore
例:

-Djavax.net.ssl.trustStore=/usr/myApp_cacerts

また、非標準認証局を標準の${JAVA_HOME}/lib/security/cacertsディレクトリにインポートすることもできます。

9.6.2 Microsoft .NET Frameworkコネクタ・サーバーの使用

アプリケーションがJavaで記述されていて、コネクタ・バンドルがC#で記述されている場合は、Microsoft .NET Framework(.NET)コネクタ・サーバーを使用すると便利です。Java Platform, Enterprise Edition (JEE (tm))アプリケーションではC#クラスをロードできないため、.NETコネクタ・サーバーの配下にC#バンドルをデプロイできます。これにより、Javaアプリケーションはネットワーク上でC#(.NET)コネクタ・サーバーと通信できるようになります。C#(.NET)コネクタ・サーバーは、C#バンドルへの認証アプリケーション・アクセスを実現するプロキシとして機能します。次の各項では、追加情報を示します。

- .NETコネクタ・サーバーのインストール

- .NETコネクタ・サーバーの構成

- トレース設定の構成

- .NETコネクタ・サーバーの実行

- .NETコネクタ・サーバーへの複数のコネクタのインストール

9.6.2.1 .NETコネクタ・サーバーのインストール

.NETコネクタ・サーバーを実行するための最低要件は次のとおりです。

- Microsoft Windows Server 2003または2008

- Microsoft .NET Framework 3.5以上

追加要件の有無は、特定の.NETアイデンティティ・コネクタのドキュメントを参照してください。

.NETコネクタ・サーバーをインストールするには、ServiceInstall.msiファイルを実行し、インストール・ウィザードに表示される指示に従います。インストールが完了すると、コネクタ・サーバーはWindowsサービスとしてインストールされます。

9.6.2.2 .NETコネクタ・サーバーの構成

.NETコネクタ・サーバーを構成するには、次の手順を実行します。共通構成には、ポート、トレース、SSL設定およびコネクタ・サーバー・キーが含まれます。

1. Microsoftサービス・コンソールを起動します。

2. コネクタ・サーバーが現在実行されているかどうかを確認します。実行されている場合は停止します。

3. コマンド・プロンプトを使用して、コネクタ・サーバーにキーを設定します。
このキーは、クライアントがこのコネクタ・サーバーに接続するときに必要になります。

1. コネクタ・サーバーがインストールされているディレクトリに移動します。
デフォルト: \Program Files\Identity Connectors\Connector Server

2. 次のコマンドを実行します。
ConnectorServer /setkey NEWKEY

ここで、NEWKEYはキーの値です。

4. connectorserver.exe.config内の設定を調べて、その他のプロパティを構成します。
connectorserver.exe.configファイルには、コネクタ・サーバーに関する情報が含まれています。最もよく変更するのは、ポート、SSL構成およびトレース設定です。ポートおよびSSL設定は、次のようにAppSettingsというタグ内にあります。

<add key="connectorserver.port" value="8759" />
<add key="connectorserver.usessl" value="false" />
<add key="connectorserver.certificatestorename" value="ConnectorServerSSLCertificate" />
<add key="connectorserver.ifaddress" value="0.0.0.0" />

ポートを設定するには、connectorserver.portの値を変更します。SSLを使用するには、connectorserver.usesslの値をtrueに設定し、connectorserver.certifacatestorenameの値を証明書ストアの名前に設定します。リスニング・ソケットは特定のアドレスにバインドすることも、0.0.0.0のままにすることもできます。コネクタ・サーバーをSSL対応として構成する方法の詳細は、第9.6.1.5項「SSLを使用したコネクタ・サーバーとの通信」を参照してください。トレース設定の構成の詳細は、第9.6.2.3項「トレース設定の構成」を参照してください。

9.6.2.3 トレース設定の構成

コネクタ・サーバーでは、標準の.NETトレース・メカニズムが使用されます。トレース設定は、connectorserver.exe.config構成ファイルに定義されています。例9-33に、定義の例を示します。

例9-33 トレース設定の定義

<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<remove name="Default" />
<add name="myListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\connectorserver2.log"
traceOutputOptions="DateTime">
<filter type="System.Diagnostics.EventTypeFilter"
initializeData="Information" />
</add>
</listeners>
</trace>
</system.diagnostics>

デフォルト設定でも十分適していますが、これらの設定を次のように変更してもかまいません。

- トレース量を減らすには、フィルタ・タイプのinitializeData設定をWarningまたはErrorに変更します。

- より詳細なロギングを行うには、値をVerboseまたはAllに設定します。

注意:

ロギングの量は、コネクタ・サーバーのパフォーマンスに直接影響します。

構成を変更する場合は、コネクタ・サーバーの停止と再起動が必要になります。

注意:

トレース・オプションの詳細は、System.Diagnosticsに関するMicrosoft .NETドキュメントを参照してください。

9.6.2.4 .NETコネクタ・サーバーの実行

.NETコネクタ・サーバーを実行する最適な方法は、Windowsサービスとして実行することです。インストール時に、コネクタ・サーバーはWindowsサービスとしてインストールされます。これが環境に適さない場合は、コマンド・プロンプトで/installまたは/uninstall引数を使用して、コネクタ・サーバーをWindowsサービスとしてインストールまたはアンインストールできます。

コネクタ・サーバーを対話形式で実行するには、ConnectorServer /runコマンドを実行します。

9.6.2.5 .NETコネクタ・サーバーへの複数のコネクタのインストール

新しいアイデンティティ・コネクタをインストールするには、コネクタ・サーバーがインストールされているディレクトリに移動し、このディレクトリに新しいアイデンティティ・コネクタのZIPを解凍してから、コネクタ・サーバーを再起動します。

10 Javaを使用したアイデンティティ・コネクタの開発

この章は、Identity Connector Framework (ICF)とOracle Identity Managerメタデータを使用してアイデンティティ・コネクタを開発するのに必要な手順全体を確認するチュートリアルとなります。ここには、重要なICFクラスとインタフェース、コネクタ・バンドルおよびコネクタ・サーバーについての情報と、フラット・ファイル・アイデンティティ・コネクタの実装のコード例や、ユーザー・プロビジョニングとリコンシリエーションのプロセス用にOracle Identity Managerメタデータを作成するコード例が含まれています。この章には次の項目があります。

- フラット・ファイル・コネクタの開発

- Oracle Identity Managerデータベースへのアイデンティティ・コネクタ・バンドルのアップロード

- フラット・ファイル・アカウントのプロビジョニング

- Javaコネクタ・サーバーのSSLの構成

10.1 フラット・ファイル・コネクタの開発

フラット・ファイル・コネクタは、構成インタフェースの実装を開発し、その後、コネクタ・クラスを実装するという手順で開発します。開始する前に、フラット・ファイル・コネクタのすべての操作用のIO表現モジュールを準備する必要があります。このことには、次のすべてまたは一部が含まれる場合があります。

- フラット・ファイルの列名を読み込み、メタデータ情報を準備します。

- 指定のデリミタで区切られた、対応する列値を含むレコードをフラット・ファイルに追加します。

- UID値に基づいて、フラット・ファイルへのレコードを削除します。

- フラット・ファイルで検索操作を実行します。

このチュートリアルではアイデンティティ・コネクタの開発に焦点を当てているため、これらの準備の詳細は説明していません。

注意:

次のサポート・クラスが、アイデンティティ・コネクタ操作時のファイル入力および出力の処理に使用されます。

- org.identityconnectors.flatfile.io.FlatFileIOFactory

- org.identityconnectors.flatfile.io.FlatFileMetadata

- org.identityconnectors.flatfile.io.FlatFileParser

- org.identityconnectors.flatfile.io.FlatFileWriter

入力および出力処理のサポート・クラスの実装については、「ファイル入力および出力処理用のサポート・クラス」を参照してください。

フラット・ファイル・コネクタを開発するには、次の手順を実行します。

1. org.identityconnectors.framework.spi.AbstractConfigurationベース・クラスを拡張して、フラット・ファイル・コネクタ用の構成クラスを実装します。
例10-1に、このサンプルを示します。詳細は、第9.4.1.2項「org.identityconnectors.framework.spi.Configuration」を参照してください。

例10-1 AbstractConfigurationの実装

package org.identityconnectors.flatfile;
import java.io.File;
import org.identityconnectors.flatfile.io.FlatFileIOFactory;
import org.identityconnectors.framework.common.exceptions.ConfigurationException;
import org.identityconnectors.framework.spi.AbstractConfiguration;
import org.identityconnectors.framework.spi.ConfigurationProperty;
/**
* Class for storing the flat file configuration
*/
public class FlatFileConfiguration extends AbstractConfiguration {
/*
* Storage file name
*/
private File storeFile;
/*
* Delimeter used
*/
private String textFieldDelimeter;
/*
* Unique attribute field name
*/
private String uniqueAttributeName = "";
/*
* Change attribute field name. Should be numeric
*/
private String changeLogAttributeName = "";

public File getStoreFile() {
return storeFile;
}

public String getTextFieldDelimeter() {
return textFieldDelimeter;
}

public String getUniqueAttributeName() {
return uniqueAttributeName;
}

public String getChangeLogAttributeName() {
return changeLogAttributeName;
}

/**
* Set the store file
* @param storeFile
*/
@ConfigurationProperty(order = 1, helpMessageKey = "USER_ACCOUNT_STORE_HELP",
displayMessageKey = "USER_ACCOUNT_STORE_DISPLAY")
public void setStoreFile(File storeFile) {
this.storeFile = storeFile;
}

/**
* Set the text field delimeter
* @param textFieldDelimeter
*/
@ConfigurationProperty(order = 2,
helpMessageKey = "USER_STORE_TEXT_DELIM_HELP",
displayMessageKey = "USER_STORE_TEXT_DELIM_DISPLAY")
public void setTextFieldDelimeter(String textFieldDelimeter) {
this.textFieldDelimeter = textFieldDelimeter;
}

/**
* Set the field whose values will be considered as unique attributes
* @param uniqueAttributeName
*/
@ConfigurationProperty(order = 3, helpMessageKey = "UNIQUE_ATTR_HELP",
displayMessageKey = "UNIQUE_ATTR_DISPLAY")
public void setUniqueAttributeName(String uniqueAttributeName) {
this.uniqueAttributeName = uniqueAttributeName;
}

/**
* Set the field name where change number should be stored
* @param changeLogAttributeName
*/
@ConfigurationProperty(order = 3, helpMessageKey = "CHANGELOG_ATTR_HELP",
displayMessageKey = "CHANGELOG_ATTR_DISPLAY")
public void setChangeLogAttributeName(String changeLogAttributeName) {
this.changeLogAttributeName = changeLogAttributeName;
}
@Override
public void validate() {

// Validate if file exists and is usable
boolean validFile = (this.storeFile.exists() &&
this.storeFile.canRead() &&
this.storeFile.canWrite() &&
this.storeFile.isFile());

if (!validFile)
throw new ConfigurationException("User store file not valid");

// Validate if there is a field on name of unique attribute field name
// Validate if there is a field on name of change attribute field name
FlatFileIOFactory.getInstance(this);
// Initialization does the validation
}

}

2. org.identityconnectors.framework.spi.Connectorインタフェースを実装して、フラット・ファイル・コネクタのコネクタ・クラスを作成します。
例10-2では、CreateOp、DeleteOp、SearchOpおよびUpdateOpの各インタフェースを実装するため、4つの操作すべてをサポートします。FlatFileMetadata、FlatFileParserおよびFlatFileWriterの各クラスは、サポート・クラスです。これらの実装は、ICFに属していないため表示されません。

例10-2 PoolableConnectorの実装

package org.identityconnectors.flatfile;

import java.util.HashSet;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Set;

import org.identityconnectors.flatfile.io.FlatFileIOFactory;
import org.identityconnectors.flatfile.io.FlatFileMetadata;
import org.identityconnectors.flatfile.io.FlatFileParser;
import org.identityconnectors.flatfile.io.FlatFileWriter;
import org.identityconnectors.framework.api.operations.GetApiOp;
import org.identityconnectors.framework.common.exceptions.AlreadyExistsException;
import org.identityconnectors.framework.common.exceptions.ConnectorException;
import org.identityconnectors.framework.common.objects.Attribute;
import org.identityconnectors.framework.common.objects.AttributeInfo;
import org.identityconnectors.framework.common.objects.AttributeInfoBuilder;
import org.identityconnectors.framework.common.objects.ConnectorObject;
import org.identityconnectors.framework.common.objects.ConnectorObjectBuilder;
import org.identityconnectors.framework.common.objects.ObjectClass;
import org.identityconnectors.framework.common.objects.OperationOptions;
import org.identityconnectors.framework.common.objects.ResultsHandler;
import org.identityconnectors.framework.common.objects.Schema;
import org.identityconnectors.framework.common.objects.SchemaBuilder;
import org.identityconnectors.framework.common.objects.Uid;
import org.identityconnectors.framework.common.objects.filter.AbstractFilterTranslator;
import org.identityconnectors.framework.common.objects.filter.FilterTranslator;
import org.identityconnectors.framework.spi.Configuration;
import org.identityconnectors.framework.spi.ConnectorClass;
import org.identityconnectors.framework.spi.PoolableConnector;
import org.identityconnectors.framework.spi.operations.CreateOp;
import org.identityconnectors.framework.spi.operations.DeleteOp;
import org.identityconnectors.framework.spi.operations.SchemaOp;
import org.identityconnectors.framework.spi.operations.SearchOp;
import org.identityconnectors.framework.spi.operations.UpdateOp;

/**
* The main connector class
*/
@ConnectorClass(configurationClass = FlatFileConfiguration.class, displayNameKey = "FlatFile")
public class FlatFileConnector implements SchemaOp, CreateOp, DeleteOp,
UpdateOp, SearchOp<Map<String, String>>, GetApiOp, PoolableConnector {

private FlatFileConfiguration flatFileConfig;
private FlatFileMetadata flatFileMetadata;
private FlatFileParser flatFileParser;
private FlatFileWriter flatFileWriter;
private boolean alive = false;

@Override
public Configuration getConfiguration() {
return this.flatFileConfig;
}

@Override
public void init(Configuration config) {
this.flatFileConfig = (FlatFileConfiguration) config;

FlatFileIOFactory flatFileIOFactory =
FlatFileIOFactory.getInstance(flatFileConfig);
this.flatFileMetadata = flatFileIOFactory.getMetadataInstance();
this.flatFileParser = flatFileIOFactory.getFileParserInstance();
this.flatFileWriter = flatFileIOFactory.getFileWriterInstance();
this.alive = true;
System.out.println("init called: Initialization done");
}

@Override
public void dispose() {
this.alive = false;
}

@Override
public Schema schema() {
SchemaBuilder flatFileSchemaBldr = new SchemaBuilder(this.getClass());
Set<AttributeInfo> attrInfos = new HashSet<AttributeInfo>();
for (String fieldName : flatFileMetadata.getOrderedTextFieldNames()) {
AttributeInfoBuilder attrBuilder = new AttributeInfoBuilder();
attrBuilder.setName(fieldName);
attrBuilder.setCreateable(true);
attrBuilder.setUpdateable(true);
attrInfos.add(attrBuilder.build());
}

// Supported class and attributes
flatFileSchemaBldr.defineObjectClass
(ObjectClass.ACCOUNT.getDisplayNameKey(),attrInfos);
System.out.println("schema called: Built the schema properly");
return flatFileSchemaBldr.build();
}

@Override
public Uid create(ObjectClass arg0, Set<Attribute> attrs,
OperationOptions ops) {

System.out.println("Creating user account " + attrs);
assertUserObjectClass(arg0);
try {
FlatFileUserAccount accountRecord = new FlatFileUserAccount(attrs);
// Assert uid is there
assertUidPresence(accountRecord);

// Create the user
this.flatFileWriter.addAccount(accountRecord);

// Return uid
String uniqueAttrField = this.flatFileConfig
.getUniqueAttributeName();
String uniqueAttrVal = accountRecord
.getAttributeValue(uniqueAttrField);
System.out.println("User " + uniqueAttrVal + " created");

return new Uid(uniqueAttrVal);
} catch (Exception ex) {

// If account exists
if (ex.getMessage().contains("exists"))
throw new AlreadyExistsException(ex);

// For all other causes
System.out.println("Error in create " + ex.getMessage());
throw ConnectorException.wrap(ex);
}
}

@Override
public void delete(ObjectClass arg0, Uid arg1, OperationOptions arg2) {
final String uidVal = arg1.getUidValue();
this.flatFileWriter.deleteAccount(uidVal);
System.out.println("Account " + uidVal + " deleted");
}

@Override
public Uid update(ObjectClass arg0, Uid arg1, Set<Attribute> arg2,
OperationOptions arg3) {
String accountIdentifier = arg1.getUidValue();
// Fetch the account
FlatFileUserAccount accountToBeUpdated = this.flatFileParser
.getAccount(accountIdentifier);

// Update
accountToBeUpdated.updateAttributes(arg2);
this.flatFileWriter
.modifyAccount(accountIdentifier, accountToBeUpdated);
System.out.println("Account " + accountIdentifier + " updated");

// Return new uid
String newAccountIdentifier = accountToBeUpdated
.getAttributeValue(this.flatFileConfig.getUniqueAttributeName());
return new Uid(newAccountIdentifier);
}

@Override
public FilterTranslator<Map<String, String>> createFilterTranslator(
ObjectClass arg0, OperationOptions arg1) {
// TODO: Create a fine grained filter translator

// Return a dummy object as its not applicable here.
// All processing happens in the execute query
return new AbstractFilterTranslator<Map<String, String>>() {
};
}

@Override
public ConnectorObject getObject(ObjectClass arg0, Uid uid,
OperationOptions arg2) {
// Return matching record
String accountIdentifier = uid.getUidValue();
FlatFileUserAccount userAcc = this.flatFileParser
.getAccount(accountIdentifier);
ConnectorObject userAccConnObject = convertToConnectorObject(userAcc);
return userAccConnObject;
}

/*
* (non-Javadoc)
* This is the search implementation.
* The Map passed as the query here, will map to all the records with
* matching attributes.
*
* The record will be filtered if any of the matching attributes are not
* found
*
* @see
* org.identityconnectors.framework.spi.operations.SearchOp#executeQuery
* (org.identityconnectors.framework.common.objects.ObjectClass,
* java.lang.Object,
* org.identityconnectors.framework.common.objects.ResultsHandler,
* org.identityconnectors.framework.common.objects.OperationOptions)
*/
@Override
public void executeQuery(ObjectClass objectClass,
Map<String, String> matchSet, ResultsHandler resultHandler,
OperationOptions ops) {

System.out.println("Inside executeQuery");

// Iterate over the records and handle individually
Iterator<FlatFileUserAccount> userAccountIterator = this.flatFileParser
.getAccountIterator(matchSet);

while (userAccountIterator.hasNext()) {
FlatFileUserAccount userAcc = userAccountIterator.next();
ConnectorObject userAccObject = convertToConnectorObject(userAcc);
if (!resultHandler.handle(userAccObject)) {
System.out.println("Not able to handle " + userAcc);
break;
}
}
}

private void assertUserObjectClass(ObjectClass arg0) {
if (!arg0.equals(ObjectClass.ACCOUNT))
throw new UnsupportedOperationException(
"Only user account operations supported.");

}

private void assertUidPresence(FlatFileUserAccount accountRecord) {
String uniqueAttrField = this.flatFileConfig.getUniqueAttributeName();
String uniqueAttrVal = accountRecord.getAttributeValue(uniqueAttrField);

if (uniqueAttrVal == null) {
throw new IllegalArgumentException("Unique attribute not passed");
}
}

private ConnectorObject convertToConnectorObject(FlatFileUserAccount userAcc) {
ConnectorObjectBuilder userObjBuilder = new ConnectorObjectBuilder();
// Add attributes
List<String> attributeNames = this.flatFileMetadata
.getOrderedTextFieldNames();
for (String attributeName : attributeNames) {
String attributeVal = userAcc.getAttributeValue(attributeName);
userObjBuilder.addAttribute(attributeName, attributeVal);

if (attributeName.equals(this.flatFileConfig
.getUniqueAttributeName())) {
userObjBuilder.setUid(attributeVal);
userObjBuilder.setName(attributeVal);
}
}
return userObjBuilder.build();
}

@Override
public void checkAlive() {
if (!alive)
throw new RuntimeException("Connection not alive");
}

}

3. このコネクタは、ContainsAllValuesFilter操作のみをサポートします。ContainsAllValuesFilter操作を実装します(例10-3に、フィルタ操作を定義するorg.identityconnectors.framework.common.objects.filter.AbstractFilterTranslator<T>のサンプル実装を示します)。

例10-3 AbstractFilterTranslator<T>の実装

package org.identityconnectors.flatfile.filteroperations;

import java.util.HashMap;
import java.util.Map;

import org.identityconnectors.framework.common.objects.Attribute;
import org.identityconnectors.framework.common.objects.filter.AbstractFilterTranslator;
import org.identityconnectors.framework.common.objects.filter.ContainsAllValuesFilter;

public class ContainsAllValuesImpl extends AbstractFilterTranslator<Map<String, String>>{
@Override
protected Map<String, String> createContainsAllValuesExpression(
ContainsAllValuesFilter filter, boolean not) {
Map<String, String> containsAllMap = new HashMap<String, String>();
Attribute attr = filter.getAttribute();
containsAllMap.put(attr.getName(), attr.getValue().get(0).toString());
return containsAllMap;
}
}

4. コネクタ・バンドルJARを作成します。MANIFEST.MFファイルには、次のエントリが含まれている必要があります。

- ConnectorBundle-FrameworkVersion

- ConnectorBundle-Name

- ConnectorBundle-Version

例10-4に、MANIFEST.MFファイルの内容を示します。

例10-4 MANIFEST.MFファイル

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 14.1-b02 (Sun Microsystems Inc.)
ConnectorBundle-FrameworkVersion: 1.0
ConnectorBundle-Name: org.identityconnectors.flatfile
ConnectorBundle-Version: 1.0
Build-Number: 609
Subversion-Revision: 4582

5. 手順4で作成したコネクタ・バンドルJARを更新します。これを行うには、次の手順を実行します。

1. コネクタ・バンドルJARを目的の場所に抽出します。

2. JARを抽出したディレクトリ内にlibディレクトリを作成します。

3. 依存しているサード・パーティのJARをこのlibディレクトリに追加します。

4. ディレクトリ全体をJARします。

注意:

MANIFEST.MFファイルには、手順4で示したエントリが含まれている必要があります。

10.1.1 ファイル入力および出力処理のサポート・クラス

この項では、ファイル入力および出力処理用の次のサポート・クラスの実装について説明します。

- 例10-5「FlatFileIOFactory」

- 例10-6「FlatFileMetadata」

- 例10-7「FlatFileParser」

- 例10-8「FlatFileWriter」

- 例10-9「FlatfileLineIterator」

- 例10-10「FlatfileUserAccount」

- 例10-11「FlatfileAccountConversionHandler」

- 例10-12「Messages.Properties」

例10-5に、FlatFileIOFactoryサポート・クラスの実装を示します。

例10-5 FlatFileIOFactory

package org.identityconnectors.flatfile.io;

import org.identityconnectors.flatfile.FlatFileConfiguration;

public class FlatFileIOFactory {

private FlatFileMetadata flatFileMetadata;
private FlatFileConfiguration flatFileConfig;

/**
* Provides instance of the factory
* @param flatfileConfig Configuration bean for the flat file
*/
public static FlatFileIOFactory getInstance(FlatFileConfiguration fileConfig) {
return new FlatFileIOFactory(fileConfig);
}

/**
* Making it private to avoid public instantiation. Encouraging use of getInstance
* @param fileConfig
*/
private FlatFileIOFactory(FlatFileConfiguration fileConfig) {
this.flatFileConfig = fileConfig;
this.flatFileMetadata = new FlatFileMetadata(flatFileConfig);
System.out.println("Metadata set");
}

/**
* Returns the metadata instance
* @return
*/
public FlatFileMetadata getMetadataInstance() {
return this.flatFileMetadata;
}

/**
* Returns the FlatFileParser instance
* @return
*/
public FlatFileParser getFileParserInstance() {
return new FlatFileParser(this.flatFileMetadata, this.flatFileConfig);
}

/**
* Returns the FlatFileWriter instance
* @return
*/
public FlatFileWriter getFileWriterInstance() {
return new FlatFileWriter(this.flatFileMetadata, this.flatFileConfig);
}
}

例10-6に、FlatFileMetaDataサポート・クラスの実装を示します。

例10-6 FlatFileMetadata

package org.identityconnectors.flatfile.io;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.StringTokenizer;

import org.identityconnectors.flatfile.FlatFileConfiguration;

/**
* This class contains all the metadata related information Example: Ordering of
* columns, Number of columns etc.
*
* @author harsh
*
*/
public class FlatFileMetadata {

private FlatFileConfiguration fileConfig;

private List<String> orderedTextFieldNames;

private String changeLogFieldName;
private String uniqueAttributeFiledName;

/**
* Instantiates the class with the file configuration.
* Making it package private to encourage instantiation from Factory class
* @param fileConfig
*/
FlatFileMetadata(FlatFileConfiguration fileConfig) {
/*
* Ideally you should not take connector specific configuration class in
* flat file resource classes. Change if this has to go to production.
* Probably make another configuration class for flat file with same
* signatures.
*/
this.fileConfig = fileConfig;

initializeMetadata();
validateConfigProps();
}

/**
* Returns the text field names in the order of their storage
*
* @return
*/
public List<String> getOrderedTextFieldNames() {
return this.orderedTextFieldNames;
}

/**
* Returns the number of columns
*/
public int getNumberOfFields() {
int numberOfTextFields = this.orderedTextFieldNames.size();
return numberOfTextFields;
}

/**
* Specifies if number of tokens are matching with the standard length of metadata
* @param countTokens
* @return
*/
public boolean isDifferentFromNumberOfFields(int countTokens) {
return (getNumberOfFields() != countTokens);
}

/**
* Reads the header line and sets the metadata
*/
private void initializeMetadata() {
// Read the file.
File recordsStore = this.fileConfig.getStoreFile();

try {
BufferedReader storeFileReader = new BufferedReader(new FileReader(
recordsStore.getAbsolutePath()));

// Read the header line
String headerString = storeFileReader.readLine();

// Tokenize the headerString
StringTokenizer tokenizer = new StringTokenizer(headerString,
fileConfig.getTextFieldDelimeter());

this.orderedTextFieldNames = new ArrayList<String>();
while (tokenizer.hasMoreTokens()) {
String header = tokenizer.nextToken();
this.orderedTextFieldNames.add(header);
}

System.out.println("Columns read - " + this.orderedTextFieldNames);
} catch (IOException e) {
throw new RuntimeException("How can I read a corrupted file");
}

// Store the change log and unique attribute field names
this.changeLogFieldName = fileConfig.getChangeLogAttributeName();
this.uniqueAttributeFiledName = fileConfig.getUniqueAttributeName();
}

/**
* Validate if the attribute names in config props object are present in the
* column names
*
* @throws RuntimeException
*             if validation fails
*/
private void validateConfigProps() {
// Check if unique attribute col name is present
if (!this.orderedTextFieldNames.contains(this.changeLogFieldName))
throw new RuntimeException("Change log field name "
+ this.changeLogFieldName + " not found in the store file ");

// Check if change col name is present
if (!this.orderedTextFieldNames.contains(this.uniqueAttributeFiledName))
throw new RuntimeException("Unique attribute field name "
+ this.uniqueAttributeFiledName
+ " not found in the store file");
}
}

例10-7に、FlatFileParserサポート・クラスの実装を示します。

例10-7 FlatFileParser

package org.identityconnectors.flatfile.io;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;

import org.identityconnectors.flatfile.FlatFileConfiguration;
import org.identityconnectors.flatfile.FlatFileUserAccount;
import org.identityconnectors.flatfile.utils.AccountConversionHandler;

public class FlatFileParser {

private File recordsStore;
private FlatFileConfiguration fileConfig;
private FlatFileMetadata metadata;
private AccountConversionHandler accountConverter;

/**
* Instantiates the parser class. Making it package private to encourage
* instantiation from Factory class
*
* @param metadata
* @param fileConfig
*/
FlatFileParser(FlatFileMetadata metadata, FlatFileConfiguration fileConfig) {
this.fileConfig = fileConfig;
this.recordsStore = fileConfig.getStoreFile();
this.accountConverter = new AccountConversionHandler(metadata,
fileConfig);
this.metadata = metadata;
}

/**
* Returns all accounts in the file
*
* @return
*/
public List<FlatFileUserAccount> getAllAccounts() {
try {
BufferedReader userRecordReader = new BufferedReader(
new FileReader(recordsStore.getAbsolutePath()));
String recordStr;

// Skip headers
userRecordReader.readLine();

// Loop over records and make list of objects
List<FlatFileUserAccount> allAccountRecords = new ArrayList<FlatFileUserAccount>();
while ((recordStr = userRecordReader.readLine()) != null) {
try {
FlatFileUserAccount accountRecord = accountConverter
.convertStringRecordToAccountObj(recordStr);
allAccountRecords.add(accountRecord);
} catch (RuntimeException e) {
System.out.println("Invalid entry " + e.getMessage());
}
}
userRecordReader.close();

return allAccountRecords;
} catch (IOException e) {
throw new RuntimeException("How can I read a corrupted file");
}
}

/**
* Gets the account of matching account identifier
*
* @param accountIdentifier
* @return
*/
public FlatFileUserAccount getAccount(String accountIdentifier) {

/*
* I know its not right to get all account details. Don't want to focus
* on efficiency and scalability as this is just a sample.
*/
// Iterate over all records and check for matching account
Map<String, String> matchSet = new HashMap<String, String>();
matchSet.put(fileConfig.getUniqueAttributeName(), accountIdentifier);
for (FlatFileUserAccount userRecord : getAllAccounts()) {
if (userRecord.hasMatchingAttributes(matchSet))
return userRecord;
}

// Got nothing..
return null;
}

/**
* Returns all records with matching Attributes If more than attributes are
* passed. it will check all the attributes
*
* @param matchSet
*            Checks if all provided attributes are matched
*/
public List<FlatFileUserAccount> getAccountsByMatchedAttrs(
Map<String, String> matchSet) {
/*
* I know its not right to get all account details. Don't want to focus
* on efficiency and scalability as this is just a sample.
*/
// Iterate over all records and check for matching account
List<FlatFileUserAccount> matchingRecords = new ArrayList<FlatFileUserAccount>();
for (FlatFileUserAccount userRecord : getAllAccounts()) {
if (userRecord.hasMatchingAttributes(matchSet))
matchingRecords.add(userRecord);
}

return matchingRecords;
}

/**
* Returns the records that fall after the specified change number This
* function helps in checking the function of sync
*
* @param changeNumber
*            the change number for the last search
*/
public List<FlatFileUserAccount> getUpdatedAccounts(int changeNumber) {
/*
* I know its not right to get all account details. Don't want to focus
* on efficiency and scalability as this is just a sample.
*/
// Iterate over all records and check for matching account
List<FlatFileUserAccount> matchingRecords = new ArrayList<FlatFileUserAccount>();
String changeLogAttrName = fileConfig.getChangeLogAttributeName();
for (FlatFileUserAccount userRecord : getAllAccounts()) {
int recordChangeNumber = userRecord
.getChangeNumber(changeLogAttrName);
if (recordChangeNumber >= changeNumber)
matchingRecords.add(userRecord);
}
return matchingRecords;

}

/**
* Returns an iterator that iterates over the records. This is provided for
* dynamic retrieval of records
*
* @param matchSet
*            Filters the records by matching the given attributes. Use null
*            or empty set to avoid filtering
* @return
*/
public Iterator<FlatFileUserAccount> getAccountIterator(
Map<String, String> matchSet) {
Iterator<FlatFileUserAccount> recordIterator = new FlatFileLineIterator(
this.metadata, this.fileConfig, matchSet);

return recordIterator;
}

/**
* Gives the next change number. Logic is max of existing change numbers + 1
* @return
*/
public int getNextChangeNumber() {
int maximumChangeNumber = 0;

/*
* I know its not right to get all account details. Don't want to focus
* on efficiency and scalability as this is just a sample.
*/
// Iterate over all records and check for matching account
String changeLogAttrName = fileConfig.getChangeLogAttributeName();
for (FlatFileUserAccount userRecord : getAllAccounts()) {
int changeNumber = userRecord.getChangeNumber(changeLogAttrName);

if (changeNumber >= maximumChangeNumber) {
maximumChangeNumber = changeNumber + 1;
}
}
return maximumChangeNumber;
}
}

例10-8に、FlatFileWriterサポート・クラスの実装を示します。

例10-8 FlatFileWriter

package org.identityconnectors.flatfile.io;

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;

import org.identityconnectors.flatfile.FlatFileConfiguration;
import org.identityconnectors.flatfile.FlatFileUserAccount;
import org.identityconnectors.flatfile.utils.AccountConversionHandler;

/**
* Class for searching operations on files
*
* @author Harsh
*/
public class FlatFileWriter {

private File recordsStore;
private FlatFileParser recordParser;
private FlatFileConfiguration fileConfig;
private AccountConversionHandler accountConverter;

/**
* Initializes the writer with the configuration Making it package private
* to encourage use of Factory class for global instantiation
*
* @param metadata
* @param fileConfig
*/
FlatFileWriter(FlatFileMetadata metadata, FlatFileConfiguration fileConfig) {
this.fileConfig = fileConfig;

this.recordsStore = fileConfig.getStoreFile();
recordParser = new FlatFileParser(metadata, fileConfig);
accountConverter = new AccountConversionHandler(metadata, fileConfig);
}

/**
* Appends the user record at the end of
*
* @param accountRecord
*/
public void addAccount(FlatFileUserAccount accountRecord) {
try {
BufferedWriter userRecordWriter = new BufferedWriter(
new FileWriter(this.recordsStore.getAbsolutePath(), true));

// Set the latest changelog number
int latestChangeNumber = recordParser.getNextChangeNumber();
accountRecord.setChangeNumber(fileConfig
.getChangeLogAttributeName(), latestChangeNumber);

// Validate if same account id doesn't exist
String accountUid = accountRecord.getAttributeValue(fileConfig
.getUniqueAttributeName());
FlatFileUserAccount accountByAccountId = recordParser
.getAccount(accountUid);

if (accountByAccountId != null)
throw new RuntimeException("Account " + accountUid
+ " already exists");

// Put the user record in formatted way
String userRecordAsStr = accountConverter
.convertAccountObjToStringRecord(accountRecord);
userRecordWriter.write("\n" + userRecordAsStr);

// Close the output stream
userRecordWriter.close();
} catch (IOException e) {// Catch exception if any
throw new RuntimeException("How can I write on a corrupted file");
}
}

/**
* Removes the entry for respective account identifier
*
* @param accountIdentifier
*/
public void deleteAccount(String accountIdentifier) {
String blankRecord = "";
this.modifyAccountInStore(accountIdentifier, blankRecord);
}

/**
* Updates the entry with respective account identifier
*
* @param accountIdentifier
* @param updatedAccountRecord
* @return new accountIdentifier
*/
public String modifyAccount(String accountIdentifier,
FlatFileUserAccount updatedAccountRecord) {

// Frame a record string and update back to file
int nextChangeNumber = recordParser.getNextChangeNumber();

String changeNumberFieldName = fileConfig.getChangeLogAttributeName();
updatedAccountRecord.setChangeNumber(changeNumberFieldName,
nextChangeNumber);

String newRecordAsStr = accountConverter
.convertAccountObjToStringRecord(updatedAccountRecord);
// Update to the file
this.modifyAccountInStore(accountIdentifier, newRecordAsStr);

// Return new UID
String uniqueAttrFieldName = fileConfig.getUniqueAttributeName();
String newAccountIdentifier = updatedAccountRecord
.getAttributeValue(uniqueAttrFieldName);
return newAccountIdentifier;
}

/**
* Returns the complete flat file as string.
*
* @return
*/
private String getCompleteFlatFileAsStr() {
try {
BufferedReader userRecordReader = new BufferedReader(
new FileReader(recordsStore.getAbsolutePath()));
String recordStr;

// Loop over records and make list of objects
StringBuilder flatFileStr = new StringBuilder();
while ((recordStr = userRecordReader.readLine()) != null) {
if (!recordStr.isEmpty())
flatFileStr.append(recordStr + "\n");
}
userRecordReader.close();

return flatFileStr.toString();
} catch (IOException e) {
throw new RuntimeException("How can I read a corrupted file");
}
}

/**
* Updates the account with the new record. this can also be used for delete
*
* @param accountIdentifier
* @param updatedRecord
*/
private void modifyAccountInStore(String accountIdentifier,
String updatedRecord) {
try {
// Load the complete flat file
String completeFlatFile = this.getCompleteFlatFileAsStr();

// Construct the string to be removed and replace it with blank
FlatFileUserAccount accountToBeRemoved = recordParser
.getAccount(accountIdentifier);
String updatableString = accountConverter
.convertAccountObjToStringRecord(accountToBeRemoved);
String updatedFlatFile = completeFlatFile.replaceAll(
updatableString, updatedRecord);

// Rewrite the file
BufferedWriter userRecordWriter = new BufferedWriter(
new FileWriter(this.recordsStore.getAbsolutePath(), false));
userRecordWriter.write(updatedFlatFile);

/*** debug ***/
System.out.println("Old string " + updatableString);
System.out.println("New String" + updatedRecord);
System.out.println("new file - " + updatedFlatFile);

/******/
// Close the output stream
userRecordWriter.close();
} catch (IOException e) {// Catch exception if any
throw new RuntimeException("How can I write on a corrupted file");
}
}
}

例10-9 FlatfileLineIterator

package org.identityconnectors.flatfile.io;
.
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.Iterator;
import java.util.Map;
.
import org.identityconnectors.flatfile.FlatFileConfiguration;
import org.identityconnectors.flatfile.FlatFileUserAccount;
import org.identityconnectors.flatfile.utils.AccountConversionHandler;
.
/**
* Iterator class to fetch the records dynamically during search operations
This
* is needed to prevent VM overloading when all records are stored in memory
*
* @author admin
*
*/
public class FlatFileLineIterator implements Iterator<FlatFileUserAccount> {
.
private File recordsStore;
private AccountConversionHandler accountConverter;
private FlatFileUserAccount nextRecord;
private BufferedReader userRecordReader;
private Map<String, String> attrConstraints;
.
/**
* Making it package private to prevent global initialization
*
* @param metadata
* @param fileConfig
* @param attributeValConstraints
*            Iterator will apply this constraint and filter the result
*/
FlatFileLineIterator(FlatFileMetadata metadata,
FlatFileConfiguration fileConfig,
Map<String, String> attributeValConstraints) {
this.recordsStore = fileConfig.getStoreFile();
this.accountConverter = new AccountConversionHandler(metadata,
fileConfig);
this.attrConstraints = attributeValConstraints;
.
initializeReader();
this.nextRecord = readNextValidRecord();
}
.
private void initializeReader() {
try {
userRecordReader = new BufferedReader(new FileReader(recordsStore
.getAbsolutePath()));
.
// Skip headers
userRecordReader.readLine();
.
} catch (IOException io) {
throw new IllegalStateException("Unable to read "
+ recordsStore.getName());
}
}
.
@Override
public boolean hasNext() {
return (nextRecord != null);
}
.
@Override
public FlatFileUserAccount next() {
FlatFileUserAccount currentRecord = this.nextRecord;
this.nextRecord = readNextValidRecord();
return currentRecord;
}
.
@Override
public void remove() {
// Nothing to do here
}
.
/**
* Returns next valid record. This happens after applying
*
* @return
*/
private FlatFileUserAccount readNextValidRecord() {
try {
FlatFileUserAccount userAccObj = null;
String recordStr;
// Match the constraints or read next line
do {
System.out.println("Before record string");
recordStr = getNextLine();
.
// No more records ??
if (recordStr == null)
return null;
.
userAccObj = accountConverter
.convertStringRecordToAccountObj(recordStr);
} while (!userAccObj.hasMatchingAttributes(attrConstraints));

return userAccObj;
} catch (Exception e) {
System.out.println("Error reading record" + e.getMessage());
e.printStackTrace();
return null;
}
}
.
private String getNextLine() throws IOException {
String nextLine = userRecordReader.readLine();
.
// No records ??
if (nextLine == null) {
this.userRecordReader.close();
return null;
}
.
if (nextLine.trim().isEmpty()) {
return getNextLine();
}
.
return nextLine;
}
}

例10-10 FlatfileUserAccount

package org.identityconnectors.flatfile;
.
import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
.
import org.identityconnectors.framework.common.objects.Attribute;
.
/**
* Object representing a user entity
*
* @author admin
*
*/
public class FlatFileUserAccount {
.
/*
* Mandatory attribute names
*/
private Set<String> mandatoryAttrNames = new HashSet<String>();
.
/*
* Attributes making the account
*/
private Map<String, String> attributes = new HashMap<String, String>();
.
/**
* Instantiates the attribute value map
*
* @param mandatoryAttributeNames
*            Names of the attributes that are necessary
* @param attributeValMap
*            Name value map for the attributes.
* @throws IllegalStateException
*             If mandatory attributes are not found in attribute val map
*/
public FlatFileUserAccount(Set<String> mandatoryAttributeNames,
Map<String, String> attributeValMap) {
// Check if mandatory attribute values are passed
Set<String> attrValuesKeySet = attributeValMap.keySet();
if (!attrValuesKeySet.containsAll(mandatoryAttributeNames))
throw new IllegalStateException("Mandatory attributes missing");
.
// Initialize
this.mandatoryAttrNames = mandatoryAttributeNames;
this.attributes = attributeValMap;
.
}

/**
* Instantiates the attribute value map.
* Considers all attributes to be mandatory
* @param attributeValMap
*/
public FlatFileUserAccount(Map<String, String> attributeValMap) {
this.mandatoryAttrNames = attributeValMap.keySet();
this.attributes = attributeValMap;
}

/**
* Instantiates the attribute value map
* @param attrs
*/
public FlatFileUserAccount(Set<Attribute> attrs) {
for(Attribute attr: attrs) {
String attrName = attr.getName();

//Consider first value. Multivalued not supported
String attrVal = (String) attr.getValue().get(0);
this.attributes.put(attrName, attrVal);
}
}
.
/**
* Updates the set of attributes. If new attributes present, they are
added,
* If old attributes are present in the parameter set, values are updated
*
* @param updatedAttributeValMap
*/
public void updateAttributes(Map<String, String> updatedAttributeValMap)
{
this.attributes.putAll(updatedAttributeValMap);
}

/**
* Updates the set of attributes.
* @param upatedAttributes
*/
public void updateAttributes(Set<Attribute> upatedAttributes) {
Map<String, String> updatedAttributeValMap = new HashMap<String,
String>();
for(Attribute attr: upatedAttributes) {
String attrName = attr.getName();

//Consider first value. Multivalued not supported
String attrVal = (String) attr.getValue().get(0);
updatedAttributeValMap.put(attrName, attrVal);
}
this.attributes.putAll(updatedAttributeValMap);
}
.
/**
* Deletes the attributes with given name.
*
* @param attributeKeys
*            Set of the attribute names that are needed
* @throws UnsupportedOperationException
*             if delete for mandatory attributes is attempted
*/
public void deleteAttributes(Set<String> attributeKeys) {
// Check if mandatory attributes are not there.
for (String attrKey : attributeKeys) {
if (this.mandatoryAttrNames.contains(attrKey))
throw new UnsupportedOperationException(
"Delete for mandatory attributes not supported. Try
update");
// Not deleting here as it might result inconsistent
}
// Remove the attributes
for (String attrKey : attributeKeys) {
this.attributes.remove(attrKey);
}
}
.
/**
* Gets the attribute of a given name
*
* @param attributeName
* @return
* @throws IllegalArgumentException
*             if attribute is not there for a given name
*/
public String getAttributeValue(String attributeName) {
return this.attributes.get(attributeName);
}
.
/**
* Returns the current set of attributes
*
* @return
*/
public Map<String, String> getAllAttributes() {
return this.attributes;
}
.
/**
* Returns true if all passed attributes are matching for this object
*
* @param attrValMap
* @return
*/
public boolean hasMatchingAttributes(Map<String, String> attrValMap) {
boolean noFilterSupplied = (attrValMap == null )||
(attrValMap.isEmpty());
if (noFilterSupplied)
// No filter. Everything matches
return true;

// Iterate to match attributes one by one
Set<String> keySet = attrValMap.keySet();
for (String attrName : keySet) {
String objAttrVal = this.attributes.get(attrName);
String passedValue = attrValMap.get(attrName);
.
if (!objAttrVal.equals(passedValue))
// This attribute is not same
return false;
}
.
// All attributes are same
return true;
}
.
/**
* Returns the change log number
*
* @param changeLogAttrName
*            attribute representing the number
* @return
*/
public int getChangeNumber(String changeLogAttrName) {
String changeNumStr = this.attributes.get(changeLogAttrName);
int changeNumber = 0;
.
try {
changeNumber = Integer.parseInt(changeNumStr);
} catch (Exception e) {
System.out.println("Not a valid change log number "
+ changeLogAttrName + " :" + changeNumStr);
}
.
return changeNumber;
}

/**
* Sets the given attribute with a new value
* @param attrName
* @param attrVal
*/
public void setAttribute(String attrName, String attrVal) {
this.attributes.put(attrName, attrVal);
}

/**
* Updates the changelog number
* @param changeLogAttrName
* @param newChangeNumber
*/
public void setChangeNumber(String changeLogAttrName, int
newChangeNumber) {
String changeNumberValStr = "" + newChangeNumber;
this.attributes.put(changeLogAttrName, changeNumberValStr);
}
.
@Override
public String toString() {
// Just print the attributes
return this.attributes.toString();
}
.
}

例10-11 FlatfileAccountConversionHandler

package org.identityconnectors.flatfile.utils;
.
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.StringTokenizer;
.
import org.identityconnectors.flatfile.FlatFileConfiguration;
import org.identityconnectors.flatfile.FlatFileUserAccount;
import org.identityconnectors.flatfile.io.FlatFileMetadata;
.
/**
* Class for the utility functions
*
* @author Admin
*
*/
public class AccountConversionHandler {
.
private FlatFileConfiguration fileConfig;
private FlatFileMetadata metadata;
.
/**
* Instantiates the handler class. But needs the configuration
*
* @param metadata
* @param fileConfig
*/
public AccountConversionHandler(FlatFileMetadata metadata,
FlatFileConfiguration fileConfig) {
this.fileConfig = fileConfig;
this.metadata = metadata;
}
.
/**
* Converts strings records to the user account objects.
*
* @param accountRecord
* @return
* @throws RuntimeException
*             If string is not formatted as per accepted standards
*/
public FlatFileUserAccount convertStringRecordToAccountObj(
String accountRecord) {
.
StringTokenizer tokenizer = new StringTokenizer(accountRecord,
fileConfig.getTextFieldDelimeter());
.
// Assert number of columns matching with number of tokens
if (metadata.isDifferentFromNumberOfFields(tokenizer.countTokens()))
throw new RuntimeException(
"Number of tokens doesn't match number of columns");
.
// Get the attributes
List<String> attrNames = metadata.getOrderedTextFieldNames();
Map<String, String> attrValMap = new HashMap<String, String>();
.
// Number of tokens are same. Same loop will work
for (String attrName : attrNames) {
String attrVal = "";
if (tokenizer.hasMoreTokens())
attrVal = tokenizer.nextToken();
.
attrValMap.put(attrName, attrVal);
}
.
// Assumption : All attributes are mandatory for user. Change with
the
// change in assumption
Set<String> mandatoryAttributeNames = attrValMap.keySet();
FlatFileUserAccount userAccountRecordObj = new FlatFileUserAccount(
mandatoryAttributeNames, attrValMap);
return userAccountRecordObj;
.
}
.
/**
* Converts account objects to storable string records
*
* @param accountObj
* @return
*/
public String convertAccountObjToStringRecord(
FlatFileUserAccount accountObj) {
StringBuilder strRecord = new StringBuilder();
.
// Build the string record from the object
List<String> attrNames = metadata.getOrderedTextFieldNames();

int index=0;
for (String attrName: attrNames) {
String attrVal = accountObj.getAttributeValue(attrName);
strRecord.append(attrVal);

// Add delimeter
if (index < attrNames.size()-1) {
strRecord.append(fileConfig.getTextFieldDelimeter());
index++;
} else {
// Record ended
String newLineCharacter = "\n";
strRecord.append(newLineCharacter);
break;
}
}
return strRecord.toString();
}
.
/**
* Asserts if given object is not null
*
* @param message
* @param obj
*/
public void assertNotNull(String message, Object obj) {
if (obj == null)
throw new RuntimeException(message);
}

}

例10-12 Messages.Properties

USER_ACCOUNT_STORE_HELP=File in which user account will be stored
USER_ACCOUNT_STORE_DISPLAY=User Account File
USER_STORE_TEXT_DELIM_HELP=Text delimeter used for separating the columns
USER_STORE_TEXT_DELIM_DISPLAY=Text Field Delimeter
UNIQUE_ATTR_HELP=The name of the attribute which will act as unique identifier
UNIQUE_ATTR_DISPLAY=Unique Field
CHANGELOG_ATTR_HELP=The name of the attribute which will act as changelog
CHANGELOG_ATTR_DISPLAY=Changelog Field

10.2 Oracle Identity Managerデータベースへのアイデンティティ・コネクタ・バンドルのアップロード

アイデンティティ・コネクタ・バンドルは、Oracle Identity ManagerデータベースのICFで使用できる必要があります。ICFアイデンティティ・コネクタをOracle Identity Managerと統合するには、次に示す項に従います。これらの手順の一部には、Oracle Identity Manager Design Consoleを使用して行う構成が含まれています。

- Oracle Identity Managerへのコネクタ・バンドルの登録

- 基本的なアイデンティティ・コネクタ・メタデータの作成

- プロビジョニング・メタデータの作成

- リコンシリエーション・メタデータの作成

10.2.1 Oracle Identity Managerへのコネクタ・バンドルの登録

コネクタ・バンドルは、Oracle Identity Managerに対してローカルなコネクタ・サービスで使用できる必要があります。このことを実現する手順は、次のとおりです。

1. Oracle Identity Managerがインストールされているマシンに、コネクタ・バンドルJARをコピーします。

2. 次のコマンドを実行して、JARをアップロードします。
$MW_HOME/server/bin/UploadJars.sh

注意:

この章では、DW_HOMEは$MW_HOME/Oracle_IDM1を表します。

3. ICFBundleをJARタイプとして選択します。

4. コネクタ・バンドルJARの場所を入力します。

5. [Enter]を押します。

10.2.2 基本的なアイデンティティ・コネクタ・メタデータの作成

このメタデータ構成は、プロビジョニングとリコンシリエーションの両方で必要となります。この項における一連の手順は、Oracle Identity Manager Design Consoleを使用して完了します。

- ITリソース・タイプ定義の作成

- リソース・オブジェクトの作成

- メインの構成参照の作成

- オブジェクト・タイプの構成参照の作成

10.2.2.1 ITリソース・タイプ定義の作成

ITリソース・タイプ定義は、リソースの接続情報の表現です。ITリソース・タイプ定義内の構成パラメータは、コネクタ・バンドルの構成パラメータと一致する必要があります。ITリソース内のパラメータの値は、バンドル構成で設定されます。

注意:

バンドル構成によって使用されないパラメータを含めることができます。これらは、バンドル操作に悪影響は与えません。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下のITリソース・タイプ定義をクリックします。

3. 「サーバー・タイプ」をFlat Fileとして定義して、新しいITリソース・タイプ定義を作成します。

4. 図10-1に示すように、次のパラメータを追加します。

- Configuration Lookupは、リソース用のメインの構成参照のマーカーです。パラメータの名前は、Configuration Lookupである必要があります。「デフォルトのフィールド値」に値を追加することをお薦めします。

- textFieldDelimeterは、バンドル構成のtextFieldDelimeterパラメータにマップされます。このパラメータの値が渡されます。

- storeFileは、バンドル構成のstoreFileパラメータにマップされます。このパラメータの値が渡されます。

図10-1 Design ConsoleのITリソース・タイプ定義

10.2.2.2 リソース・オブジェクトの作成

リソース・オブジェクトは、Oracle Identity Managerでのリソースの表現です。コネクタ・バンドルは、リソース・オブジェクトに関連付けられています。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下の「リソース・オブジェクト」をクリックします。

3. FLATFILEROという名前で新しいリソース・オブジェクトを作成します。
リソース・オブジェクトはターゲット・リソースであるため、図10-2に示すように、「信頼できるソース」ボックスは選択しません。

図10-2 Design Consoleの「リソース・オブジェクト」

10.2.2.3 参照の作成

コネクタ・バンドルでサポートされている様々なオブジェクトに対して個別の参照を定義する必要があります。この参照には、これらのオブジェクトのプロビジョニングおよびリコンシリエーションに関連する情報を含めることができます。メインの構成参照は、これらの参照へのポインタが含まれているため、オブジェクト固有の参照のルートになります。次の項では、参照の作成方法について説明します。

- メインの構成参照の作成

- オブジェクト・タイプの構成参照の作成

10.2.2.3.1 メインの構成参照の作成

(第10.2.2.1項「ITリソース・タイプ定義の作成」で定義した)構成参照には、接続情報とは見なされないコネクタ・バンドル構成が保持されます。ITリソース・タイプ定義で構成パラメータが見つからない場合、Oracle Identity Managerは構成参照を検索します。メインの構成参照には、バンドル・プロパティおよびバンドル構成が含まれています。バンドル・プロパティ・パラメータは、正しいバンドルの識別に必要であるため、必須です。ITリソース・タイプ定義の一部として定義されていないバンドル構成(第10.2.2.1項「ITリソース・タイプの定義の作成」を参照)は、ここで宣言できます。

注意:

コード・キーの値は、図と完全に一致する必要があります。デコードの値は、コネクタ・バンドルに固有です。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」の下の「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FF.Configurationをコードの値として追加します。

4. 図10-3に示すように、次の参照コード情報を追加します。

- VERSIONを必須バンドル・バージョンとして追加します。

- org.identityconnectors.flatfileを必須バンドル名として追加します。

- org.identityconnectors.flatfile.FlatFileConnectorを必須コネクタ名として追加します。

- AccountIdをuniqueAttributeNameの値として追加します。AccountIdは、プロビジョニングまたはリコンサイルされるアカウントを表す一意の文字列識別子です。フラット・ファイル内の列の名前です。AccountIdは、一意であり、ユーザー(アカウントの詳細)を一意に表すために使用されます。

- ChangeNumberをchangeLogAttributeNameの値として追加します。アカウントが作成されると、作成されたアカウントの合計数を示すために番号が付加されます。この値は、ChangeNumberと呼ばれる変数で保持されます。

- OBJECT_TYPE_NAME Configuration Lookupは、特定のオブジェクト・タイプの構成参照です。この例では、User Configuration Lookupが定義されているため、オブジェクト・タイプはUserになります。

図10-3 Design Consoleの「参照定義」

10.2.2.3.2 オブジェクト・タイプの構成参照の作成

オブジェクト・タイプの構成参照には、特定のオブジェクト・タイプに固有のパラメータが含まれています。オブジェクト・タイプは、アイデンティティ・コネクタが動作するエンティティです。ICF ObjectClassにマップされます。第10.2.2.3.1項「メインの構成参照の作成」でUser Configuration Lookupが参照されているため、Userがオブジェクト・タイプとなり、この場合はObjectClass.ACCOUNTにマップされています。(RolesとUserJobDataが、その他の2つのオブジェクト・タイプです。)オブジェクト・タイプ名は、アイデンティティ・コネクタ・バンドルでサポートされているオブジェクト・クラス名と一致する必要があります。Userオブジェクト・タイプは事前定義済のObjectClass.ACCOUNTにマップされ、Groupオブジェクト・タイプは事前定義済ObjectClass.GROUPにマップされます。アイデンティティ・コネクタが複数のオブジェクトをサポートしている場合、この手順をそれぞれに対して繰り返す必要があります。

注意:

これらのユースケースは基本機能のみを対象としているため、この構成は必須属性として保持されます。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」の下の「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FF.UM.Configurationをコードとして追加します。

4. 図10-4に示すように、次の属性を設定します。

注意:

このチュートリアルは、アイデンティティ・コネクタの実行に最低限必要な構成に焦点を当てています。

- プロビジョニング属性マップの値はLookup.FF.UM.ProvAttrMapとします。この参照には、Oracle Identity Managerフィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、プロビジョニング時に使用されます。

- リコンシリエーション属性マップの値はLookup.FF.UM.ReconAttributeMapとします。この参照には、Oracle Identity Managerリコンシリエーション・フィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、リコンシリエーション時に使用されます。

図10-4 Design Consoleの2番目の「参照定義」

10.2.3 プロビジョニング・メタデータの作成

次の項は、フラット・ファイル・プロビジョニング用にOracle Identity Managerを構成するために実行する必要があります。

- プロセス・フォームの作成

- アダプタの作成

- プロセス定義の作成

- プロビジョニング属性マッピング参照の作成

10.2.3.1 プロセス・フォームの作成

プロセス・フォームは、Oracle Identity Managerでのオブジェクト属性の表現として使用されます。これにより、操作のためにオブジェクト属性がコネクタ・バンドルに渡される前に、ユーザーが設定を容易に入力できます。

プロセス・フォームで定義された属性は、規則ではありません。このフォームは、アイデンティティ・コネクタに渡される必要がある属性に対するチャレンジの方法です。一般的に、アイデンティティ・コネクタのサポートされている各属性に対して属性を定義します。

注意:

アイデンティティ・コネクタ属性で1対1のマッピングを設定することをお薦めします。

対応するITリソース・タイプ定義に関連付ける必要があるITリソースを問い合せるためのフィールドが存在する必要があります。各フィールドの変数タイプは、オブジェクト属性のタイプにマップする必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「フォーム・デザイナ」をクリックします。

3. 図10-5に示すように、「表名」がUD_FLAT_FILである新しいフォームを作成します。

図10-5 Design Consoleの「フォーム・デザイナ」

4. 表10-1に示されているように、コネクタ・スキーマで定義されている属性を追加します。

表10-1 「フォーム・デザイナ」のフィールド

名前

バリアント

フィールド・ラベル

フィールド・タイプ

UD_FLAT_FIL_FIRSTNAME

String

First Name

TextField

UD_FLAT_FIL_UID

String

Universal ID

TextField

UD_FLAT_FIL_CHANGENO

String

Change Number

TextField

UD_FLAT_FIL_MAILID

String

Email ID

TextField

UD_FLAT_FIL_SERVER

long

Server

ITResource

UD_FLAT_FIL_LASTNAME

String

Last Name

TextField

UD_FLAT_FIL_ACCOUNTID

String

Account ID

TextField

UD_FLAT_FIL_RETURN

String

Return ID

TextField

注意:

フラット・ファイルの列名は、FirstName、ChangeNo、EmailID、Server、LastNameおよびAccountIDです。

5. 「Properties」タブをクリックします。

6. 図10-6に示しているように、次のプロパティをServer(ITResourceLookupField)に追加します。

- Required = true

- Type = Flat File

図10-6 Design Consoleの「フォーム・デザイナ」のプロパティ

7. フォームを保存します。

8. バージョンのアクティブ化をクリックします。

10.2.3.2 アダプタの作成

コネクタ・バンドルでサポートされているすべての操作(作成、更新、削除など)に対してアダプタを作成する必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「アダプタ・ファクトリ」をクリックします。

3. 新しいアダプタを作成し、「アダプタ名」としてFFCreateUserを追加します。

4. 「アダプタ・タイプ」として「プロセス・タスク」を追加します。

5. アダプタを保存します。

6. 図10-7に示すように、変数リスト・タブをクリックして、次の変数を追加します。

- 「タイプ」が「文字列」で、マップが実行時に解決であるobjectType。

- 「タイプ」が「ロング」で、マップが実行時に解決であるprocessInstanceKey。

- 「タイプ」が「文字列」で、マップが実行時に解決であるitResourceFieldName。

図10-7 Design Consoleの「アダプタ・ファクトリ」の変数リスト

7. 図10-8に示すように、次のサブ手順を実行して、Java機能タスクをアダプタに追加します。

1. アダプタ・タスク・タブをクリックします。

2. アダプタを選択し、「追加」をクリックします。

3. タスク・オプションからJavaを選択します。

4. APIソースから「icf-oim-intg.jar」を選択します。

5. APIソースとして「oracle.iam.connetors.icfcommon.prov.ICProvisioninManager」を選択します。

6. タスクのメソッドとして「createObject」を選択します。

7. 構成を保存します。

8. (すでに変数リストに追加した)変数を、適切なメソッド入力および出力にマップします。

9. 構成パラメータを、適切なメソッド入力および出力にマップします。
データベース参照はデータベース参照(アダプタ参照)にマップし、戻り変数は戻り変数(アダプタ変数)にマップします。

図10-8 Design Consoleの「アダプタ・ファクトリ」

8. アダプタを保存してビルドします。

10.2.3.3 プロセス定義の作成

プロセス定義では、特定の操作用のコネクタ・バンドルの動作を定義します。すべての操作には、関連付けられている対応タスクがあります。この手順では、作成操作のプロセス定義、およびプロセス・タスクの統合を構成します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「プロセス管理」タブの「プロセス定義」をクリックします。

3. 図10-9に示すように、新しいプロセス定義を作成し、それにFlat Fileという名前を付けます。

図10-9 Design Consoleの「プロセス定義」

4. プロセスのタイプとして「プロビジョニング」を選択します。

5. アイデンティティ・コネクタのリソース・オブジェクト名を指定します(この例ではFLATFILERO)。

6. プロセス・フォームの表名を指定します(この例ではUD_FLAT_FIL)。

7. プロセス・タスクを追加してCreate Userという名前を付けます。

8. 図10-10に示すように、「Create User」をダブルクリックして、編集します。

図10-10 Design Consoleのタスクの編集画面

9. 統合タブをクリックします。

10. 図10-11に示すように、「追加」をクリックして、リストからFFCreateUserアダプタを選択します。
このアダプタは、コンパイルされた後にのみ使用できます。

図10-11 Design Consoleの「統合」タブ

11. 次のように変数をマップして、アイデンティティ・コネクタによって返されるレスポンス・コードを設定します。

- Adapter Return Variable - レスポンス・コード

- Object Type - [Literal:String] User(オブジェクト・タイプの名前)

- Process Instance Key - [Process Data] プロセス・インスタンス

- IT Resource Field Name - [Literal:String] UD_FLAT_FIL_SERVER (ITリソース情報が含まれたフォーム・フィールド名)

12. 図10-12に示すように、「レスポンス」タブをクリックして、レスポンスを構成します。

- UNKNOWNを、ステータスがR(拒否)の不明なレスポンスの受信として指定できます。

- SUCCESSを、ステータスがC(完了)の操作の完了として指定できます。

- ERRORを、ステータスがRのエラーの発生として指定できます。

図10-12 Design Consoleでのレスポンスの構成

13. タスクのオブジェクト・ステータス・マッピング・タブをクリックします。

14. 図10-13に示すように、オブジェクト・ステータスをステータスがCのProvisionedに更新します。

図10-13 タスクとオブジェクトのステータス・マッピング

15. プロセス・タスクを保存します。

10.2.3.4 プロビジョニング属性マッピング参照の作成

プロビジョニング属性マッピング参照には、アイデンティティ・コネクタ・バンドル属性へのOracle Identity Managerフィールドのマッピングが含まれます。プロビジョニング属性マッピング参照の説明を次に示します。

- コード・キーは、プロセス・フォームのフィールド・ラベルです。

- デコードは、アイデンティティ・コネクタ・バンドル属性です。

- 子フォーム属性は、入力での埋込みオブジェクトとして構成できます。

- アイデンティティ・コネクタのプロビジョニング操作は、レスポンスでUIDを返します。これは、アイデンティティ・コネクタ・バンドル属性に対してコーディングして、フォーム・フィールドに設定できます。

プロビジョニング属性マッピング参照を作成する手順は、次のとおりです。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」タブの「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FF.UM.ProvAttrMapという名前を付けます。
参照の名前は、オブジェクト・タイプの構成参照から参照されます。第10.2.2.3.2項「オブジェクト・タイプの構成参照の作成」を参照してください。

4. フォーム・フィールド・ラベルをコード・キーとして追加し、アイデンティティ・コネクタ・バンドル属性をデコードとして追加します。

- Return ID : __UID__

- Account ID: AccountId

- Change Number: ChangeNumber

- First Name: FirstName

- Last Name: LastName

- Email ID: MailId

10.2.3.4.1 プロビジョニング属性マップで使用されるフィールド・フラグ

プロビジョニング属性マッピングの場合、次のフィールド・フラグをコード・キーに追加できます。

- LOOKUP: これは、参照リコンシリエーション・ジョブの実行によって値が取得されるすべてのフィールドに指定する必要があります。参照リコンシリエーション・ジョブから取得された値には、ITリソース名/キーが追加されています。このフラグを指定すると、追加された値をバンドルに渡す直前にICF統合で削除するのに役立ちます。たとえば、ラベルがDatabaseで、参照リコンシリエーション・ジョブの実行により値が取得されたフィールドのコード・キーは、Database[LOOKUP]のようになります。

注意:

LOOKUPフラグは、プロビジョニングとリコンシリエーション両方の属性マップに指定できます。プロビジョニングの場合、ITリソース名/ITリソース・キー接頭辞を削除する必要があります。リコンシリエーションの場合、ITリソース名/ITリソース・キー接頭辞を追加する必要があります。

- IGNORE: これは、値が無視され、バンドルに送信されないすべてのフィールドに指定する必要があります。たとえば、ラベルがDatabaseで、値をバンドルに送信する必要がないフィールドのコード・キーは、Database[IGNORE]のようになります。

- WRITEBACK: これは、作成操作または更新操作の直後に値をプロセス・フォームに書き戻す必要があるすべてのフィールドに指定する必要があります。このフラグを追加すると、ICF統合レイヤー・コールICF Get APIが、WRITEBACKフラグのマークがある属性の値を取得するようになります。たとえば、ラベルがDatabaseで、作成/更新の直後に値がプロセス・フォームに書き戻される必要があるフィールドのコード・キーは、Database[WRITEBACK]のようになります。これが機能するには、コネクタはGetApiOpインタフェースを実装し、ConnectorObject getObject(ObjectClass objClass、Uid uid、OperationOptionsオプション)APIに実装を提供する必要があります。このAPIは、Uidが渡されたUidと同じであるアカウントのターゲットを検索し、プロセス・フォームに書き戻されるすべての属性(およびその値)が含まれたコネクタ・オブジェクトをビルドします。

注意:

コネクタがGetApiOpインタフェースを実装していない場合、WRITEBACKフラグは機能せず、エラーが生成されます。

- DATE: これは、タイプがDateと見なされる必要があるフィールドに指定する必要があり、これがない場合、値は標準の文字列と見なされます。たとえば、ラベルがTodayで、値が日付形式で表示される必要があるフィールドのコード・キーは、Today[DATE]のようになります。

- PROVIDEONPSWDCHANGE: これは、パスワード更新が発生した場合に、バンドル(ターゲット)に提供する必要があるすべてのフィールドに指定する必要があります。一部のターゲットは、追加の属性がすべてのパスワード変更で指定されると予測します。PROVIDEONPSWDCHANGEフラグを指定することで、パスワード変更がリクエストされた場合は必ずすべての追加フィールドまたは属性を送信するようICF統合に伝えます。たとえば、ラベルがExtra Attribute Needed for Password Changeで、パスワード更新時に値をバンドル(ターゲット)に提供する必要があるフィールドのコード・キーは、Extra Attribute Needed for Password Change[PROVIDEONPSWDCHANGE]のようになります。

10.2.4 リコンシリエーション・メタデータの作成

この項では、フラット・ファイルのレコードのリコンシリエーションを構成する手順について説明します。ターゲット・リコンシリエーションを例として使用しますが、信頼できるリコンシリエーションも同様の方法で構成できます。リストされている順序で手順を実行してください。

1. リコンシリエーション・スケジュール・タスクの作成

2. リコンシリエーション・プロファイルの作成

3. リコンシリエーション・アクション・ルールの設定

4. リコンシリエーション・マッピングの作成

5. リコンシリエーション一致ルールの定義

10.2.4.1 リコンシリエーション・スケジュール・タスクの作成

デフォルトでは、リコンシリエーションはコネクタ・バンドルで検索操作を使用します。この操作は、Oracle Identity Managerを使用して構成されたスケジュール・タスクで呼び出されます。この手順は、次のサブ手順で構成されています。

1. スケジュール・タスクの定義

2. スケジュール済タスクの作成

10.2.4.1.1 スケジュール・タスクの定義

スケジュール済タスクを定義するには、次の手順を実行します。

1. 例10-13に示すように、スケジュール済タスク詳細が含まれたデプロイメント・マネージャXMLファイルを作成します。データベースの値を、使用しているデータベースに必ず更新してください。

例10-13 スケジュール済タスク詳細が含まれたデプロイメント・マネージャXML

<?xml version = '1.0' encoding = 'UTF-8'?>
<xl-ddm-data version="2.0.1.0" user="XELSYSADM" database="jdbc:oracle:thin:@localhost:5524/estView.regress.rdbms.dev.mycompany.com" exported-date="1307546406635" description="FF">
<scheduledTask repo-type="MDS" name="Flat File Connector User Reconciliation" mds-path="/db" mds-file="Flat File Connector User Reconciliation.xml">
<completeXml>
<scheduledTasks xmlns="http://xmlns.oracle.com/oim/scheduler">
<task>
<name>Flat File Connector User Reconciliation</name>
<class>oracle.iam.connectors.icfcommon.recon.SearchReconTask</class>
<description>Flat File Connector User Reconciliation</description>
<retry>0</retry>
<parameters>
<string-param required="false" encrypted="false" helpText="Filter">Filter</string-param>
<string-param required="false" encrypted="false" helpText="Incremental Recon Date Attribute">Incremental Recon Date Attribute</string-param>
<string-param required="false" encrypted="false" helpText="IT Resource Name">IT Resource Name</string-param>
<string-param required="false" encrypted="false" helpText="Object Type">Object Type</string-param>
<string-param required="false" encrypted="false" helpText="Latest Token">Latest Token</string-param>
<string-param required="false" encrypted="false" helpText="Resource Object Name">Resource Object Name</string-param>
</parameters>
</task>
</scheduledTasks>
</completeXml>
</scheduledTask>
</xl-ddm-data>

2. このファイルをFlat File Connector User Reconciliation.xmlとして保存します。

3. Oracle Identity System Administrationにログインします。「システム管理」の下で、「インポート」をクリックします。

4. Flat File Connector User Reconciliation.xmlファイルを選択し、「インポート」をクリックします。

5. ウィザードのステップを完了します。

10.2.4.1.2 スケジュール済タスクの作成

この手順では、スケジュール済タスクの作成方法について説明します。

1. Oracle Identity Manager拡張管理にログインします。

2. 「システム管理」タブの「スケジューラ」をクリックします。

3. 図10-14に示すように、スケジュール・タスクを追加し、タイプとしてFlat File Connector User Reconciliationを追加します。

図10-14 「スケジュール済タスク」画面

4. パラメータを次のように設定します。

- 「ITリソース名」の値はFlat Fileとします。

- リソース・オブジェクト名の値はFLATFILEROとします。

- 「オブジェクト・タイプ」の値は「ユーザー」とします。

5. 「適用」をクリックします。

10.2.4.2 リコンシリエーション・プロファイルの作成

リコンシリエーション・プロファイルでは、リコンシリエーション時のオブジェクト属性の構造を定義します。リコンシリエーション・プロファイルには、リコンシリエーションをサポートしているすべての属性が含まれている必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下の「リソース・オブジェクト」をクリックします。

3. 「FLATFILERO」リソース・オブジェクトを開きます。

4. 図10-15に示すように、オブジェクト・リコンシリエーション・タブをクリックします。

図10-15 Design Consoleのオブジェクト・リコンシリエーション

5. 次のリコンシリエーション・フィールドを追加します。

- First Name [String]

- Universal ID [String]

- Email ID [String]

- IT Resource Name [String]

- Last Name [String]

- Account ID [String]、必須

6. 構成を保存します。

10.2.4.3 リコンシリエーション・アクション・ルールの設定

リコンシリエーション・アクション・ルールでは、リコンシリエーションの動作を定義します。この手順では、一致が見つかった場合に行われるアクションを定義します。この手順では、Oracle Identity Manager Design Consoleにログインしていることを前提にしています。

1. 「FLATFILERO」リソース・オブジェクトを開きます。

2. オブジェクト・リコンシリエーション・タブをクリックします。

3. 右側のフレームのリコンシリエーション・アクション・ルール・タブをクリックします。

図10-16 Design Consoleのリコンシリエーション・アクション・ルール

4. 1つのプロセス一致が見つかった場合(「ルール条件」)およびリンクの確立(「アクション」)として定義したアクション・ルールを追加します。

5. 1つのエンティティ一致が見つかった場合(「ルール条件」)およびリンクの確立(「アクション」)として定義したアクション・ルールを追加します。

6. リコンシリエーション・プロファイルの作成をクリックします。

7. 「保存」をクリックします。

10.2.4.4 リコンシリエーション・マッピングの作成

リコンシリエーション・マッピングは、プロセス定義で実行する必要があります。これは、サポートされているリコンシリエーション・フィールドを(リソース・オブジェクトから)プロセス・フォーム・フィールドにマッピングすることです。このマッピングは、ターゲット・リコンシリエーションを構成する場合にのみ必要となります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「プロセス管理」の下の「プロセス定義」をクリックします。

3. Flat Fileプロセス定義を開きます。

4. 図10-17に示すように、リコンシリエーション・フィールド・マッピング・タブをクリックします。

図10-17 Design Consoleのリコンシリエーション・フィールド・マッピング

5. リコンシリエーション・プロファイル・フィールドとプロセス・フォーム・フィールドとの間のマッピングを追加します。

- First Name[String] = UD_FLAT_FIL_FIRSTNAME

- Email ID[String] = UD_FLAT_FIL_MAILID

- IT Resource Name[String] = UD_FLAT_FIL_SERVER

- Last Name[String] = UD_FLAT_FIL_LASTNAME

- Account ID [String] = UD_FLAT_FIL_ACCOUNTID <KEY>
<KEY>は、Account IDをキー・フィールドとして設定します。

6. 構成を保存します。

10.2.4.4.1 リコンシリエーション属性マップで使用されるフィールド・フラグ

リコンシリエーション属性マッピングの場合は、次のフィールド・フラグをコード・キーに追加できます。

- TRUSTED: これは、アカウントのステータスを表すフィールドのリコンシリエーション属性マップで指定する必要があります。このフラグは、信頼できるリコンシリエーションにのみ指定する必要があります。これが指定されている場合、アカウントのステータスは「アクティブ」または「無効」のいずれかになります。それ以外の場合、ステータスは「有効」または「無効」のいずれかになります。たとえば、ラベルがStatusで、値が「アクティブ」または「無効」のいずれかである必要があるフィールドのコード・キーは、Status[TRUSTED]のようになります。

- DATE: これは、リコンシリエーション属性マップにおいて、タイプがDateと見なされる必要があるフィールドに指定する必要があります。たとえば、ラベルがTodayで、値が日付形式で表示される必要があるフィールドのコード・キーは、Today[DATE]のようにする必要があります。

10.2.4.5 リコンシリエーション一致ルールの定義

リコンシリエーション一致ルールでは、ユーザー一致の計算用の式を定義します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「リコンシリエーション・ルール」フォームを開きます。

3. 「ルールの追加」をクリックします。

図10-18 リコンシリエーション一致ルールの追加

4. リソース・オブジェクト「FLATFILERO」を選択します。

5. このルール要素を保存して追加します。
ユーザー・プロファイル・データの「ユーザー・ログイン」は、「アカウントID」リソース属性と同等です。

6. ルールを保存します。

10.3 フラット・ファイル・アカウントのプロビジョニング

フラット・ファイル・コネクタの準備は整っています。ユーザーは、Oracle Identity Managerにログインし、次の手順を使用してITリソース(ターゲット)を作成する必要があります。

- タイプがFlat FileであるITリソースを作成します。

- 必要に応じて、ITリソース・パラメータを指定します。

- 必要に応じて、Lookup.FF.Configurationに構成パラメータを指定します。

10.4 Javaコネクタ・サーバーのSSLの構成

Javaコネクタ・サーバーのSSLを有効化する手順は次のとおりです。

1. $CONNECTOR_SERVER_HOME/conf/ConnectorServer.propertiesを次のように編集します。

connectorserver.usessl=true
connectorserver.keyStore={full path to your keystore file}
connectorserver.keyStoreType=JKS (optionally you can set key store type, if
not set JSK is used by default)

2. 次の手順でキー・ストア・パスワードを指定します。

1. ConnectorServer.propertiesにキー・ストア・パスワードを設定します。

2. ConnectorServer.propertiesにconnectorserver.promptKeyStorePassword=falseを設定します。

3. 次のように、パスワードを設定します。

cd $CONNECTOR_SERVER/bin

UNIXの場合

connectorserver.sh /setKeyStorePassword thepassword

Windowsの場合

ConnectorServer.bat /setKeyStorePassword thepassword

このコマンドにより、ConnectorServer.propertiesの暗号化された値が「connectorserver.keyStorePassword」に設定されます。

3. コネクタ・サーバーがConnectorServer.propertiesにconnectorserver.promptKeyStorePassword=trueの設定を開始するたびに、キー・ストア・パスワードが要求されます。
次の例スニペットは、Javaコネクタ・サーバーに同梱のConnectorServer.propertiesを示しています。

.
##
## The port we are to run on
##
connectorserver.port=8759
##
## The bundle directory in which to find the bundles
##
connectorserver.bundleDir=bundles
.
##
## The bundle directory in which to find any libraries needed by bundles at
runtime
##
connectorserver.libDir=lib
.
##
## Set to true to use SSL.
## NOTE: Check also the following settings which are related to SSL:
## connectorserver.promptKeyStorePassword
## connectorserver.keyStore
## connectorserver.keyStoreType
## connectorserver.keyStorePassword
connectorserver.usessl=false
.
##
## If set to true the user is prompted for key store password at startup.
## If set to false the key store password needs to be set with
-setKeyStorePassword command first.
##
connectorserver.promptKeyStorePassword=true
.
##
## Full path to key store.
##
connectorserver.keyStore=/tmp/KeyStore.jks
.
##
## KeyStore type
##
#connectorserver.keyStoreType=JKS
.
##
## Encrypted password. Set this by using the -setKeyStorePassword flag.
## It is used only if connectorserver.promptKeyStorePassword is set to false.
##
connectorserver.keyStorePassword=
.
##
## Optionally specify a specific address to bind to
##
#connectorserver.ifaddress=localhost
.
##
## Secure hash of the gateway key. Set this by using the
## -setKey flag
##
connectorserver.key=lmA6bMfENJGlIDbfrVtklXFK32s\=
.
##
## Use standard JDK logging
##
connectorserver.loggerClass=org.identityconnectors.common.logging.impl.JDKLogger

11 .NETを使用したアイデンティティ・コネクタの開発

この章は、Identity Connector Framework (ICF)とOracle Identity Managerメタデータを使用して.NETでアイデンティティ・コネクタを開発するのに必要な手順全体を確認するチュートリアルとなります。ここには、重要なICFクラスとインタフェース、コネクタ・バンドルおよびコネクタ・サーバーについての情報と、フラット・ファイル.NETアイデンティティ・コネクタの実装のコード例や、ユーザー・プロビジョニングとリコンシリエーションのプロセス用にOracle Identity Managerメタデータを作成するコード例が含まれています。この章には次の項目があります。

- 第11.1項「フラット・ファイル.NETコネクタの開発」

- 第11.2項「.NETコネクタ・サーバーでのアイデンティティ・コネクタ・バンドルのデプロイ」

- 第11.3項「フラット・ファイル・アカウントのプロビジョニング」

11.1 フラット・ファイル.NETコネクタの開発

フラット・ファイル・コネクタは、構成インタフェースの実装を開発し、その後、コネクタ・クラスを実装するという手順で開発します。このドキュメントでは、作成、削除、更新および検索操作のフラット・ファイル・コネクタのサンプル実装について説明します。実装およびドキュメントを単純化するために、コネクタによってサポートされる構成プロパティおよびスキーマは最小限に維持されています。このコネクタの実装は、実際のコネクタの作成に役立つサンプルとしてのみ使用してください。

コネクタの実装を単純にするために、フラット・ファイルには名前、性別、資格、年齢属性のみが含まれていると仮定します。2つの構成ファイルの場所およびデリミタがあります。残りの構成は、サンプルにハードコードされています。

1. Microsoft Visual Studioでコネクタを使用して、プロジェクトを設定します。

1. タイプ・ライブラリの新しいVisual Studioプロジェクトを作成します。

2. 参照として次のdllが追加されていることを確認します。
- Common.dll

- Framework.dll

- FrameworkInternal.dll

- System.dll

- System.Core.dll

これらのdllは、.NETコネクタ・サーバーで使用可能である必要があります。

2. Org.IdentityConnectors.Framework.Spi.AbstractConfigurationベース・クラスを拡張して、フラット・ファイル・コネクタ用の構成クラスを実装します。

例11-1 AbstractConfigurationの実装

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Org.IdentityConnectors.Framework.Spi;?
using Org.IdentityConnectors.Framework.Common.Exceptions;?
using System.IO;

namespace Org.IdentityConnector.FlatFileConnector?
{
/// <summary>
/// Configuration class for flat file connector representing target system information?
/// </summary>
public class FlatFileConfiguration : AbstractConfiguration?
{
#region FileName
/// <summary>
/// Target file name
/// </summary>
/// <value>
/// File name with complete path. As for executing the .NET Connector bundle we need .NET Connector Server, hence the file should reside
/// on the machine where the connector server is present.
/// </value>
[ConfigurationProperty(Required = true, Order = 1)]
public String FileName { get; set; }
#endregion

#region Delimiter
/// <summary>
/// Delimiter used within the target flat file
/// </summary>
/// <value>
/// Delimter
/// </value>
[ConfigurationProperty(Required = true, Order = 2)]
public String Delimiter { get; set; }
#endregion

#region
/// <summary>
/// Validates if the configuration properties provided are as requiered, if not throw ConfigurationException
/// </summary>
public override void Validate()
{
if (this.FileName == null || this.FileName.Length == 0)
{
throw new ConfigurationException("Configuration property FileName cannot be null or empty");
}
if (!File.Exists(this.FileName))
{
throw new ConfigurationException("Target file " + this.FileName + " does not exist");
}
if (this.Delimiter == null || this.Delimiter.Length == 0)
{
throw new ConfigurationException("Configuration property Delimiter cannot be null or empty");
}
}
#endregion
}
}

3. 異なるSPIインタフェースOrg.IdentityConnectors.Framework.Spiを実装することで、フラット・ファイル・コネクタにコネクタ・クラスを作成します。

例11-2では、PoolableConnector,CreateOp,SchemaOp,TestOp,DeleteOp,UpdateOp,SearchOp<String>インタフェースを実装するため、すべてのCRUD操作をサポートします。

例11-2 PoolableConnectorの実装

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Org.IdentityConnectors.Framework.Spi;
using System.IO;
using Org.IdentityConnectors.Framework.Common.Exceptions;
using System.Security.AccessControl;
using Org.IdentityConnectors.Framework.Spi.Operations;
using Org.IdentityConnectors.Framework.Common.Objects;
using Org.IdentityConnectors.Common;

namespace Org.IdentityConnector.FlatFileConnector
{
/// <summary>
/// FlatFileConnector showing implementation of SchemaOp, test, create, delete, update and search operations.
/// </summary>
[ConnectorClass("FlatFileConnector_DisplayNameKey",typeof(FlatFileConfiguration))]
public class FlatFileConnector : PoolableConnector,CreateOp,SchemaOp,TestOp,DeleteOp,UpdateOp,SearchOp<String>
{

/// <summary>
/// Flat file configuration instance. This instance has the target system information.
/// </summary>
private FlatFileConfiguration config;

#region Init
/// <summary>
/// Create a connection to target and store it for later use. But here we just set attributes of target file
/// name to Normal
/// </summary>
/// <param name="config">Configuration Object</param>
public void Init(Configuration config)
{
this.config = (FlatFileConfiguration)config;
File.SetAttributes(this.config.FileName, FileAttributes.Normal);
}
#endregion

#region CreateOp Members
/// <summary>
/// This creates a new row in the target file with the data as sent in the 'attrs'
/// </summary>
/// <param name="objClass">The ObjectClass. Here we support only Account</param>
/// <param name="attrs">Attributes of this Account that need to be created on target</param>
/// <param name="options">Will always be empty</param>
/// <returns>Unique id Uid, representing the Account which was just created</returns>
public Uid Create(ObjectClass objClass, ICollection<ConnectorAttribute> attrs, OperationOptions options)
{
ConnectorAttribute NameAttribute = ConnectorAttributeUtil.Find(Name.NAME, attrs);
ConnectorAttribute AgeAttribute = ConnectorAttributeUtil.Find("Age", attrs);
ConnectorAttribute QualificationAttribute = ConnectorAttributeUtil.Find("Qualification", attrs);
ConnectorAttribute GenderAttributute = ConnectorAttributeUtil.Find("Gender", attrs);
StreamWriter writer = File.AppendText(this.config.FileName);
writer.WriteLine("\nName:" + ConnectorAttributeUtil.GetAsStringValue(NameAttribute) + this.config.Delimiter + "Age:" + ConnectorAttributeUtil.GetAsStringValue(AgeAttribute) + this.config.Delimiter + "Qualification:" + ConnectorAttributeUtil.GetAsStringValue(QualificationAttribute) + this.config.Delimiter + "Gender:" + ConnectorAttributeUtil.GetAsStringValue(GenderAttributute));
writer.Flush();
writer.Dispose();
writer.Close();
return new Uid(ConnectorAttributeUtil.GetAsStringValue(NameAttribute));
}
#endregion

#region DeleteOp Members
/// <summary>
/// Deletes an entity from target flat file. We support only ACCOUNT object class.
/// If the Uid (user name) is not found then UnknownUidException is thrown
/// </summary>
/// <param name="objClass"></param>
/// <param name="uid"></param>
/// <param name="options"></param>
public void Delete(ObjectClass objClass, Uid uid, OperationOptions options)
{
String[] allLines = File.ReadAllLines(this.config.FileName);
String[] newLines = new String[allLines.Length];
Boolean userExisted = false;
for (int i = 0; i < allLines.Length; i++)
{
char[] separator = new char[] { '$' };
String[] thisLineSplit = allLines[i].Split(separator);

String name = "";
foreach (String str in thisLineSplit)
{
if (str.StartsWith("Name"))
{
name = str;
break;
}
}
if (!name.Equals("Name" + ":" + uid.GetUidValue()))
{
newLines[i] = allLines[i];
}
else
{
userExisted = true;
}

}
if (userExisted)
{
File.WriteAllText(this.config.FileName, String.Empty);
File.WriteAllLines(this.config.FileName, newLines);
}
else
{
throw new UnknownUidException("Uid "+uid.GetUidValue()+" not found");
}
}
#endregion

#region UpdateOp Members
/// <summary>
/// Updates information of an existing user on the target flat file
/// </summary>
/// <param name="objclass">The ObjectClass. Here we support only user</param>
/// <param name="uid">Unique id of the user using which we can find out the user on target. This is the returned vaue by CreateOp implementation</param>
/// <param name="replaceAttributes">Updated attributes of user which should replace all existing user information on target</param>
/// <param name="options">This will always be empty</param>
/// <returns>Updated uid. It can be the same value which was provided to this method.</returns>
public Uid Update(ObjectClass objclass, Uid uid, ICollection<ConnectorAttribute> replaceAttributes, OperationOptions options)
{
String uidValue = uid.GetUidValue();
String[] allLines = File.ReadAllLines(this.config.FileName);
String[] updatedLines = new String[allLines.Length];
Boolean userExists = false;
Uid updatedUid = uid;
for(int i = 0; i < allLines.Length; i++)
{
String[] thisLineSplit = allLines[i].Split(new char[] { '$' });
String name = "";
foreach (String str in thisLineSplit)
{
if (str.StartsWith("Name"))
{
name = str;
break;
}
}
String nameToBeUpdated = "Name:" + uidValue;
if (!name.Equals(nameToBeUpdated))
{
updatedLines[i] = allLines[i];
}
else
{
ConnectorAttribute NameAttribute = ConnectorAttributeUtil.Find(Name.NAME, replaceAttributes);
ConnectorAttribute AgeAttribute = ConnectorAttributeUtil.Find("Age", replaceAttributes);
ConnectorAttribute QualificationAttribute = ConnectorAttributeUtil.Find("Qualification", replaceAttributes);
ConnectorAttribute GenderAttribute = ConnectorAttributeUtil.Find("Gender", replaceAttributes);
updatedLines[i] = "Name:"+NameAttribute.Value.First().ToString()+this.config.Delimiter+
AgeAttribute.Name+":"+AgeAttribute.Value.First().ToString()+this.config.Delimiter+
QualificationAttribute.Name+":"+QualificationAttribute.Value.First().ToString()+this.config.Delimiter+
GenderAttribute.Name+":"+GenderAttribute.Value.First().ToString();
userExists = true;
updatedUid = new Uid(NameAttribute.Value.First().ToString());
}

}
File.WriteAllText(this.config.FileName, String.Empty);
File.WriteAllLines(this.config.FileName, updatedLines);
if (!userExists)
{
throw new UnknownUidException("User "+uid.GetUidValue()+" not found");
}
return updatedUid;
}

#endregion

#region SearchOp<string> Members

/// <summary>
/// Returns a filter translator used by ExecuteQuery. The functionality of filter translator is to translate any filters provided by calling application (OIM/OW/OPAM) to native queries.
/// </summary>
/// <param name="oclass">The ObjectClass. We support only ACCOUNT</param>
/// <param name="options">Options</param>
/// <returns>FilterTranslator instance</returns>

public Org.IdentityConnectors.Framework.Common.Objects.Filters.FilterTranslator<string> CreateFilterTranslator(ObjectClass oclass, OperationOptions options)
{
return new FlatFileFilterTranslator();
}

/// <summary>
/// Performs search on target based on query. Uses the handler instance to return back the searched result.
/// </summary>
/// <param name="oclass">The ObjectClass. This tells if we have to search for user (ACCOUNT) or group (GROUP). We support only user</param>
/// <param name="query">Query as returned by FilterTranslator</param>
/// <param name="handler">handler to return back result to caller</param>
/// <param name="options">Options containing what attributes of entity to return back</param>
public void ExecuteQuery(ObjectClass oclass, string query, ResultsHandler handler, OperationOptions options)
{

String[] results = GetResults(query);
foreach (String result in results)
{
Console.WriteLine("Result = "+result);
String result1 = result.Trim();
if (result1.Length > 0)
{
Console.WriteLine("Submitting result = " + result1);
SubmitConnectorObject(result1, handler);
}
}
}

#region SchemaOp Members
/// <summary>
/// Defines the schema supported by this connector
/// </summary>
/// <returns>Schema</returns>
public Schema Schema()
{
SchemaBuilder schemaBuilder = new SchemaBuilder(SafeType<Connector>.Get(this));
ICollection<ConnectorAttributeInfo> connectorAttributeInfos = new List<ConnectorAttributeInfo>();
connectorAttributeInfos.Add(ConnectorAttributeInfoBuilder.Build("Name"));
connectorAttributeInfos.Add(ConnectorAttributeInfoBuilder.Build("Age"));
connectorAttributeInfos.Add(ConnectorAttributeInfoBuilder.Build("Qualification"));
connectorAttributeInfos.Add(ConnectorAttributeInfoBuilder.Build("Gender"));
schemaBuilder.DefineObjectClass(ObjectClass.ACCOUNT_NAME, connectorAttributeInfos);
return schemaBuilder.Build();
}

#endregion

#region TestOp Members
/// <summary>
/// Should ideally test the connecttion with target. But here we just print something as we have assumed that target file is on same machine
/// </summary>
public void Test()
{
Console.Write("Tested connection!");
}

#endregion

#region CheckAlive
/// <summary>
/// Check connection to target system is alive or not. But here we just check if target file name
/// provided in the FlatFileConfiguration is available or not.
/// </summary>
public void CheckAlive()
{
if (!File.Exists(this.config.FileName))
{
throw new ConnectorException("Target file " + this.config.FileName + " does not exist");
}
}
#endregion

#region Dispose
/// <summary>
/// Remove connection from target, dispose any of the resources used. But here we just chill.
/// </summary>
public void Dispose()
{
//chill :)
}
#endregion

private void SubmitConnectorObject(String result, ResultsHandler handler)
{
ConnectorObjectBuilder cob = new ConnectorObjectBuilder();
String[] resultSplit = result.Split(new char[]{'$'});
ICollection<ConnectorAttribute> attrs = new List<ConnectorAttribute>();
foreach (String str in resultSplit)
{
ConnectorAttributeBuilder cab = new ConnectorAttributeBuilder();
cab.AddValue(str.Split(new char[] { ':' })[1]);
if (str.StartsWith("Name"))
{
cob.SetName(Name.NAME);
cob.SetUid(str.Split(new char[] { ':' })[1]);
cab.Name = Name.NAME;
}
else
{
cab.Name = str.Split(new char[] { ':' })[0];
}
attrs.Add(cab.Build());
}
cob.AddAttributes(attrs);
handler(cob.Build());
}

private String[] GetResults(String query)
{
String[] allLines = File.ReadAllLines(this.config.FileName);
String[] results = allLines;
if (query != null)
{
for (int i = 0; i < allLines.Length; i++)
{
String[] thisLineSplit = allLines[i].Split(new char[]{'$'});
Boolean foundResult = false;
foreach (String str in thisLineSplit)
{
if (str.StartsWith("Name") && str.Equals(query))
{
foundResult = true;
break;
}
}
if (foundResult)
{
return new String[] {allLines[i]};
}
}
}

return results;
}

#endregion
}
}

4. このコネクタは、CreateEqualsExpression操作のみをサポートします。CreateEqualsExpressionを実装します。例11-3に、フィルタ操作を定義するOrg.IdentityConnectors.Framework.Common.Objects.Filters.AbstractFilterTranslator<T>のサンプル実装を示します。

例11-3 AbstractFilterTranslator<T>の実装

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Org.IdentityConnectors.Framework.Common.Objects.Filters;
using Org.IdentityConnectors.Framework.Common.Objects;

namespace Org.IdentityConnector.FlatFileConnector
{
/// <summary>
/// FlatFileFilterTranslator. This translator converts the equalsFilter provided by the calling application to native query which can be used by the connector while searching.
/// The implementation shown supports only equals filter. i.e it has provided implementation for only CreateEqualsExpression, this means that if any other filter is provided
/// by the calling application, it would not be translated as a native query and search implementation gets all users and filtering will be done by ICF with all results.
///
/// </summary>
public class FlatFileFilterTranslator : AbstractFilterTranslator<String>
{
/// <summary>
/// Creates a native query for equals filter and returns it only if equals filter is constructed for Name attribute and not for any other attributes.
/// </summary>
/// <param name="filter">Filter provided by calling application</param>
/// <param name="not"></param>
/// <returns></returns>
protected override string CreateEqualsExpression(EqualsFilter filter, bool not)
{
ConnectorAttribute attr = filter.GetAttribute();
if (attr.Name.Equals(Name.NAME))
{
return "Name:" + attr.Value.First().ToString();
}
return null;
}
}
}

5. 異なるクラスを実装します(手順2、3および4を参照)。

6. プロジェクトのAssemblyInfo.csに存在するAssemblyVersionをメモします。
サンプルのAssemblyInfo.csファイル:

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("FlatFileConnector")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Oracle Corporation")]
[assembly: AssemblyProduct("FlatFileConnector")]
[assembly: AssemblyCopyright("Copyright © Oracle Corporation 2012")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(true)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("79eec317-62bd-49a5-9512-88d61135684c")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

7. プロジェクトを作成します。プロジェクトは、コネクタDLLを作成する必要があります。

11.2 .NETコネクタ・サーバーでのアイデンティティ・コネクタ・バンドルのデプロイ

.NETに実装されているすべてのコネクタで、コネクタを実行する.NETコネクタ・サーバーを持つ必要があります。コネクタ・バンドルはOracle Identity Manager内にデプロイすることはできません。したがって、ICF .NETアイデンティティ・コネクタとOracle Identity Managerを統合するために次の手順を実行する必要があります。

- 第11.2.1項「.NETコネクタ・サーバーへのコネクタ・バンドルの登録」

- 第11.2.2項「基本的なアイデンティティ・コネクタ・メタデータの作成」

- 第11.2.3項「プロビジョニング・メタデータの作成」

- 第11.2.4項「リコンシリエーション・メタデータの作成」

11.2.1 .NETコネクタ・サーバーへのコネクタ・バンドルの登録

.NETコネクタ・サーバーでコネクタ・バンドルを登録またはデプロイするには、次の手順を実行します。

1. .NETコネクタ・サーバーをインストールします。.NETコネクタ・サーバーのインストールの詳細は、第9.6.2.1項「.NETコネクタ・サーバーのインストール」を参照してください。

2. コネクタ・サーバーを停止します。コネクタ・サーバー・サービスが実行していないことを確認してください。

3. CONNECTOR_SERVER_HOMEの場所でコネクタDLLをコピーします。CONNECTOR_SERVER_HOMEは、.NETコネクタ・サーバーのインストール後に、ConnectorServer.exeおよびファイルに関連するその他のコネクタ・サーバーが存在する場所です。

4. .NETコネクタ・サーバーを起動します。

11.2.2 基本的なアイデンティティ・コネクタ・メタデータの作成

このメタデータ構成は、プロビジョニングとリコンシリエーションの両方で必要となります。Oracle Identity ManagerのDesign Consoleを使用して、次の手順を実行します。

- 第11.2.2.1項「ITリソース・タイプ定義の作成」

- 第11.2.2.2項「リソース・オブジェクトの作成」

11.2.2.1 ITリソース・タイプ定義の作成

ITリソース・タイプ定義は、リソースの接続情報の表現です。ITリソース・タイプ定義内の構成パラメータは、コネクタ・バンドルの構成パラメータと一致する必要があります。ITリソース内のパラメータの値は、バンドル構成で設定されます。

注意:

バンドル構成によって使用されないパラメータを含めることができます。これらは、バンドル操作に悪影響は与えません。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下で、ITリソース・タイプ定義をクリックします。

3. 「サーバー・タイプ」をFlat Fileとして定義して、新しいITリソース・タイプ定義を作成します。

4. 図11-1に示すように、次のパラメータを追加します。

- Configuration Lookupは、リソース用のメインの構成参照のマーカーです。パラメータの名前は、Configuration Lookupである必要があります。「デフォルトのフィールド値」に値を追加することをお薦めします。

- デリミタは、バンドル構成のデリミタ・パラメータにマップします。このパラメータの値が渡されます。

- FileNameは、バンドル構成のFileNameパラメータにマップします。このパラメータの値が渡されます。

- Connector Server Nameは、.NETコネクタ・サーバーが実行中のコネクタ・サーバーのITリソース名を指定します。

図11-1 Design ConsoleのITリソース・タイプ定義

11.2.2.2 リソース・オブジェクトの作成

リソース・オブジェクトは、Oracle Identity Managerでのリソースの表現です。コネクタ・バンドルは、リソース・オブジェクトに関連付けられています。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下の「リソース・オブジェクト」をクリックします。

3. Flat Fileという名前で新しいリソース・オブジェクトを作成します。
リソース・オブジェクトはターゲット・リソースであるため、図11-2に示すように、「信頼できるソース」ボックスは選択しません。

図11-2 Design Consoleの「リソース・オブジェクト」

11.2.2.3 参照の作成

コネクタ・バンドルでサポートされている様々なオブジェクトに対して個別の参照を定義する必要があります。この参照には、これらのオブジェクトのプロビジョニングおよびリコンシリエーションに関連する情報を含めることができます。メインの構成参照は、これらの参照へのポインタが含まれているため、オブジェクト固有の参照のルートになります。次の項では、参照の作成方法について説明します。

- メインの構成参照の作成

- オブジェクト・タイプの構成参照の作成

11.2.2.3.1 メインの構成参照の作成

(第11.2.2.1項「ITリソース・タイプ定義の作成」で定義した)構成参照には、接続情報とは見なされないコネクタ・バンドル構成が保持されます。ITリソース・タイプ定義で構成パラメータが見つからない場合、Oracle Identity Managerは構成参照を検索します。メインの構成参照には、バンドル・プロパティおよびバンドル構成が含まれています。バンドル・プロパティ・パラメータは、正しいバンドルの識別に必要であるため、必須です。ITリソース・タイプ定義の一部として定義されていないバンドル構成(第11.2.2.1項「ITリソース・タイプの定義の作成」を参照)は、ここで宣言できます。

注意:

コード・キーの値は、図と完全に一致する必要があります。デコードの値は、コネクタ・バンドルに固有です。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」の下の「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FlatFile.Configurationをコードの値として追加します。

4. 図11-3に示すように、次の参照コード情報を追加します。

- AssemblyVersionを必須バンドル・バージョンとして追加します。

- FlatFile.Connectorを必須バンドル名として追加します。バンドル名は、コネクタのdll名から識別できます。コネクタDLLは、BUNDLE_NAME.dll形式です。

- Org.IdentityConnector.FlatFileConnector.FlatFileConnectorを必須コネクタ名として追加します。

- OBJECT_TYPE_NAME Configuration Lookupは、特定のオブジェクト・タイプの構成参照です。この例では、User Configuration Lookupが定義されているため、オブジェクト・タイプはUserになります。

図11-3 Design Consoleの「参照定義」

11.2.2.3.2 オブジェクト・タイプの構成参照の作成

オブジェクト・タイプの構成参照には、特定のオブジェクト・タイプに固有のパラメータが含まれています。オブジェクト・タイプは、アイデンティティ・コネクタが動作するエンティティです。ICF ObjectClassにマップされます。第11.2.2.3.1項「メインの構成参照の作成」でUser Configuration Lookupが参照されているため、Userがオブジェクト・タイプとなり、この場合はObjectClass.ACCOUNTにマップされています。(RolesとUserJobDataが、その他の2つのオブジェクト・タイプです。)オブジェクト・タイプ名は、アイデンティティ・コネクタ・バンドルでサポートされているオブジェクト・クラス名と一致する必要があります。Userオブジェクト・タイプは事前定義済のObjectClass.ACCOUNTにマップされ、Groupオブジェクト・タイプは事前定義済ObjectClass.GROUPにマップされます。アイデンティティ・コネクタが複数のオブジェクトをサポートしている場合、この手順をそれぞれに対して繰り返す必要があります。

注意:

これらのユースケースは基本機能のみを対象としているため、この構成は必須属性として保持されます。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」の下の「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FlatFile.UM.Configurationをコードとして追加します。

4. 図11-4に示すように、次の属性を設定します。

注意:

このチュートリアルは、アイデンティティ・コネクタの実行に最低限必要な構成に焦点を当てています。

- プロビジョニング属性マップの値はLookup.FlatFile.UM.ProvAttrMapとします。この参照には、Oracle Identity Managerフィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、プロビジョニング時に使用されます。

- リコンシリエーション属性マップの値はLookup.FlatFile.UM.ReconAttributeMapとします。この参照には、Oracle Identity Managerリコンシリエーション・フィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、リコンシリエーション時に使用されます。

図11-4 Design Consoleの2番目の「参照定義」

11.2.3 プロビジョニング・メタデータの作成

次の項は、フラット・ファイル・プロビジョニング用にOracle Identity Managerを構成するために実行する必要があります。

- 第11.2.3.1項「プロセス・フォームの作成」

- 第11.2.3.2項「アダプタの作成」

- 第11.2.3.3項「プロセス定義の作成」

- 第11.2.3.4項「プロビジョニング属性マッピング参照の作成」

11.2.3.1 プロセス・フォームの作成

プロセス・フォームは、Oracle Identity Managerでのオブジェクト属性の表現として使用されます。これにより、操作のためにオブジェクト属性がコネクタ・バンドルに渡される前に、ユーザーが設定を容易に入力できます。

プロセス・フォームで定義された属性は、規則ではありません。このフォームは、アイデンティティ・コネクタに渡される必要がある属性に対するチャレンジの方法です。一般的に、アイデンティティ・コネクタのサポートされている各属性に対して属性を定義します。

注意:

アイデンティティ・コネクタ属性で1対1のマッピングを設定することをお薦めします。

対応するITリソース・タイプ定義に関連付ける必要があるITリソースを問い合せるためのフィールドが存在する必要があります。各フィールドの変数タイプは、オブジェクト属性のタイプにマップする必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「フォーム・デザイナ」をクリックします。

3. 図11-5に示すように、「表名」がUD_FLATFILEである新しいフォームを作成します。

図11-5 Design Consoleの「フォーム・デザイナ」

4. 表11-1に示されているように、コネクタ・スキーマで定義されている属性を追加します。

表11-1 「フォーム・デザイナ」のフィールド

名前

バリアント

フィールド・ラベル

フィールド・タイプ

UD_FLATFILE_NAME

String

名前

TextField

UD_FLATFILE_AGE

String

年齢

TextField

UD_FLATFILE_QUALIFICATION

String

資格情報

TextField

UD_FLATFILE_GENDER

String

性別

LookupField

UD_FLATFILE_RETURNIDQ

String

Return Id

DOField

UD_FLATFILE_ITRESOURCE

Long

ITリソース

ITResourceLookup

注意:

フラット・ファイルの列名は、FirstName、ChangeNo、EmailID、Server、LastNameおよびAccountIDです。

5. 「Properties」タブをクリックします。

6. 図11-6に示しているように、次のプロパティをServer(ITResourceLookupField)に追加します。

- Required = true

- Type = Flat File

図11-6 Design Consoleの「フォーム・デザイナ」のプロパティ

7. フォームを保存します。

8. バージョンのアクティブ化をクリックします。

11.2.3.2 アダプタの作成

コネクタ・バンドルでサポートされているすべての操作(作成、更新、削除など)に対してアダプタを作成する必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「アダプタ・ファクトリ」をクリックします。

3. 新しいアダプタを作成して、アダプタ名として、フラット・ファイルの作成ユーザーを追加します。

4. 「アダプタ・タイプ」として「プロセス・タスク」を追加します。

5. アダプタを保存します。

6. 図11-7に示すように、「変数リスト」タブをクリックして、次の変数を追加します。

- 「タイプ」が「文字列」で、マップが実行時に解決であるobjectType。

- 「タイプ」が「ロング」で、マップが実行時に解決であるprocessInstanceKey。

- 「タイプ」が「文字列」で、マップが実行時に解決であるitResourceFieldName。

図11-7 Design Consoleの「アダプタ・ファクトリ」の変数リスト

7. 図11-8に示すように、次のサブ手順を実行して、Java機能タスクをアダプタに追加します。

1. アダプタ・タスク・タブをクリックします。

2. アダプタを選択し、「追加」をクリックします。

3. タスク・オプションからJavaを選択します。

4. APIソースから「icf-oim-intg.jar」を選択します。

5. APIソースとして「oracle.iam.connetors.icfcommon.prov.ICProvisioninManager」を選択します。

6. タスクのメソッドとして「createObject」を選択します。

7. 構成を保存します。

8. (すでに変数リストに追加した)変数を、適切なメソッド入力および出力にマップします。

9. 構成パラメータを、適切なメソッド入力および出力にマップします。
データベース参照はデータベース参照(アダプタ参照)にマップし、戻り変数は戻り変数(アダプタ変数)にマップします。

図11-8 Design Consoleの「アダプタ・ファクトリ」

8. アダプタを保存してビルドします。

11.2.3.3 プロセス定義の作成

プロセス定義では、特定の操作用のコネクタ・バンドルの動作を定義します。すべての操作には、関連付けられている対応タスクがあります。この手順では、作成操作のプロセス定義、およびプロセス・タスクの統合を構成します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「プロセス管理」タブの「プロセス定義」をクリックします。

3. 図11-9に示すように、新しいプロセス定義を作成し、それにFlat Fileという名前を付けます。

図11-9 Design Consoleの「プロセス定義」

4. プロセスのタイプとして「プロビジョニング」を選択します。

5. アイデンティティ・コネクタのリソース・オブジェクト名を指定します(この例ではフラット・ファイル)。

6. プロセス・フォームの表名を指定します(この例ではUD_FLATFILE)。

7. プロセス・タスクを追加してCreate Userという名前を付けます。

8. 図11-10に示すように、「Create User」をダブルクリックして、編集します。

図11-10 Design Consoleのタスクの編集画面

9. 統合タブをクリックします。

10. 図11-11に示すように、「追加」をクリックして、リストからadpFLATFILECREATEUSERアダプタを選択します。
このアダプタは、コンパイルされた後にのみ使用できます。

図11-11 Design Consoleの「統合」タブ

11. 次のように変数をマップして、アイデンティティ・コネクタによって返されるレスポンス・コードを設定します。

- Adapter Return Variable - レスポンス・コード

- Object Type - [Literal:String] User(オブジェクト・タイプの名前)

- Process Instance Key - [Process Data] プロセス・インスタンス

- IT Resource Field Name - [Literal:String] UD_FLATFILE_ITRESOURCE (ITリソース情報が含まれたフォーム・フィールド名)

12. 図11-12に示すように、「レスポンス」タブをクリックして、レスポンスを構成します。

- UNKNOWNを、ステータスがR(拒否)の不明なレスポンスの受信として指定できます。

- SUCCESSを、ステータスがC(完了)の操作の完了として指定できます。

- ERRORを、ステータスがRのエラーの発生として指定できます。

図11-12 Design Consoleでのレスポンスの構成

13. タスクのオブジェクト・ステータス・マッピング・タブをクリックします。

14. 図11-13に示すように、オブジェクト・ステータスをステータスがCのProvisionedに更新します。

図11-13 タスクとオブジェクトのステータス・マッピング

15. プロセス・タスクを保存します。

11.2.3.4 プロビジョニング属性マッピング参照の作成

プロビジョニング属性マッピング参照には、アイデンティティ・コネクタ・バンドル属性へのOracle Identity Managerフィールドのマッピングが含まれます。プロビジョニング属性マッピング参照の説明を次に示します。

- コード・キーは、プロセス・フォームのフィールド・ラベルです。

- デコードは、アイデンティティ・コネクタ・バンドル属性です。

- 子フォーム属性は、入力での埋込みオブジェクトとして構成できます。

- アイデンティティ・コネクタのプロビジョニング操作は、レスポンスでUIDを返します。これは、アイデンティティ・コネクタ・バンドル属性に対してコーディングして、フォーム・フィールドに設定できます。

プロビジョニング属性マッピング参照を作成する手順は、次のとおりです。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「管理」タブの「参照定義」をクリックします。

3. 新しい参照を作成し、Lookup.FlatFile.UM.ProvAttrMapという名前を付けます。
参照の名前は、オブジェクト・タイプの構成参照から参照されます。第11.2.2.3.2項「オブジェクト・タイプの構成参照の作成」を参照してください。

4. 図11-14に示すように、フォーム・フィールド・ラベルをコード・キーとして追加し、アイデンティティ・コネクタ・バンドル属性をデコードとして追加します。

- 名前: __NAME__

- 性別: Gender

- Return Id: __UID__

- 年齢: Age

- 資格情報: Qualification

図11-14 参照コード・マッピング

11.2.3.4.1 プロビジョニング属性マップで使用されるフィールド・フラグ

注意:

これらのプロパティは、高度なオプションで、コネクタの現在の実装では省略できます。

プロビジョニング属性マッピングの場合、次のフィールド・フラグをコード・キーに追加できます。

- LOOKUP: これは、参照リコンシリエーション・ジョブの実行によって値が取得されるすべてのフィールドに指定する必要があります。参照リコンシリエーション・ジョブから取得された値には、ITリソース名/キーが追加されています。このフラグを指定すると、追加された値をバンドルに渡す直前にICF統合で削除するのに役立ちます。たとえば、ラベルがDatabaseで、参照リコンシリエーション・ジョブの実行により値が取得されたフィールドのコード・キーは、Database[LOOKUP]のようになります。

注意:

LOOKUPフラグは、プロビジョニングとリコンシリエーション両方の属性マップに指定できます。プロビジョニングの場合、ITリソース名/ITリソース・キー接頭辞を削除する必要があります。リコンシリエーションの場合、ITリソース名/ITリソース・キー接頭辞を追加する必要があります。

- IGNORE: これは、値が無視され、バンドルに送信されないすべてのフィールドに指定する必要があります。たとえば、ラベルがDatabaseで、値をバンドルに送信する必要がないフィールドのコード・キーは、Database[IGNORE]のようになります。

- WRITEBACK: これは、作成操作または更新操作の直後に値をプロセス・フォームに書き戻す必要があるすべてのフィールドに指定する必要があります。このフラグを追加すると、ICF統合レイヤー・コールICF Get APIが、WRITEBACKフラグのマークがある属性の値を取得するようになります。たとえば、ラベルがDatabaseで、作成/更新の直後に値がプロセス・フォームに書き戻される必要があるフィールドのコード・キーは、Database[WRITEBACK]のようになります。これが機能するには、コネクタはGetApiOpインタフェースを実装し、ConnectorObject getObject(ObjectClass objClass、Uid uid、OperationOptionsオプション)APIに実装を提供する必要があります。このAPIは、Uidが渡されたUidと同じであるアカウントのターゲットを検索し、プロセス・フォームに書き戻されるすべての属性(およびその値)が含まれたコネクタ・オブジェクトをビルドします。

注意:

コネクタがGetApiOpインタフェースを実装していない場合、WRITEBACKフラグは機能せず、エラーが生成されます。

- DATE: これは、タイプがDateと見なされる必要があるフィールドに指定する必要があり、これがない場合、値は標準の文字列と見なされます。たとえば、ラベルがTodayで、値が日付形式で表示される必要があるフィールドのコード・キーは、Today[DATE]のようになります。

- PROVIDEONPSWDCHANGE: これは、パスワード更新が発生した場合に、バンドル(ターゲット)に提供する必要があるすべてのフィールドに指定する必要があります。一部のターゲットは、追加の属性がすべてのパスワード変更で指定されると予測します。PROVIDEONPSWDCHANGEフラグを指定することで、パスワード変更がリクエストされた場合は必ずすべての追加フィールドまたは属性を送信するようICF統合に伝えます。たとえば、ラベルがExtra Attribute Needed for Password Changeで、パスワード更新時に値をバンドル(ターゲット)に提供する必要があるフィールドのコード・キーは、Extra Attribute Needed for Password Change[PROVIDEONPSWDCHANGE]のようになります。

11.2.4 リコンシリエーション・メタデータの作成

この項では、フラット・ファイルのレコードのリコンシリエーションを構成する手順について説明します。ターゲット・リコンシリエーションを例として使用しますが、信頼できるリコンシリエーションも同様の方法で構成できます。リストされている順序で手順を実行してください。

- 第11.2.4.1項「リコンシリエーション・スケジュール・タスクの作成」

- 第11.2.4.2項「リコンシリエーション・プロファイルの作成」

- 第11.2.4.3項「リコンシリエーション・アクション・ルールの設定」

- 第11.2.4.4項「リコンシリエーション・マッピングの作成」

- 第11.2.4.5項「リコンシリエーション一致ルールの定義」

11.2.4.1 リコンシリエーション・スケジュール・タスクの作成

デフォルトでは、リコンシリエーションはコネクタ・バンドルで検索操作を使用します。この操作は、Oracle Identity Managerを使用して構成されたスケジュール・タスクで呼び出されます。この手順は、次のサブ手順で構成されています。

1. 第11.2.4.1.1項「スケジュール・タスクの定義」

2. 第11.2.4.1.2項「スケジュール済ジョブの作成」

11.2.4.1.1 スケジュール・タスクの定義

スケジュール済タスクを定義するには、次の手順を実行します。

1. 例11-4に示すように、スケジュール済タスク詳細が含まれたデプロイメント・マネージャXMLファイルを作成します。データベースの値を、使用しているデータベースに必ず更新してください。

例11-4 スケジュール済タスク詳細が含まれたデプロイメント・マネージャXML

<?xml version = '1.0' encoding = 'UTF-8'?>
<xl-ddm-data version="2.0.1.0" user="XELSYSADM" database="jdbc:oracle:thin:@localhost:5524/estView.regress.rdbms.dev.mycompany.com" exported-date="1307546406635" description="FF">
<scheduledTask repo-type="MDS" name="Flat File Connector User Reconciliation" mds-path="/db" mds-file="Flat File Connector User Reconciliation.xml">
<completeXml>
<scheduledTasks xmlns="http://xmlns.oracle.com/oim/scheduler">
<task>
<name>Flat File Connector User Reconciliation</name>
<class>oracle.iam.connectors.icfcommon.recon.SearchReconTask</class>
<description>Flat File Connector User Reconciliation</description>
<retry>0</retry>
<parameters>
<string-param required="false" encrypted="false" helpText="Filter">Filter</string-param>
<string-param required="false" encrypted="false" helpText="Incremental Recon Date Attribute">Incremental Recon Date Attribute</string-param>
<string-param required="false" encrypted="false" helpText="IT Resource Name">IT Resource Name</string-param>
<string-param required="false" encrypted="false" helpText="Object Type">Object Type</string-param>
<string-param required="false" encrypted="false" helpText="Latest Token">Latest Token</string-param>
<string-param required="false" encrypted="false" helpText="Resource Object Name">Resource Object Name</string-param>
</parameters>
</task>
</scheduledTasks>
</completeXml>
</scheduledTask>
</xl-ddm-data>

2. このファイルをFlat File Connector User Reconciliation.xmlとして保存します。

3. Identity System Administrationにログインします。「システム管理」の下で、「インポート」をクリックします。

4. Flat File Connector User Reconciliation.xmlファイルを選択し、「インポート」をクリックします。

5. ウィザードのステップを完了します。

11.2.4.1.2 スケジュール済ジョブの作成

この手順では、スケジュール済タスクの作成方法について説明します。

1. Oracle Identity Manager拡張管理にログインします。

2. 「システム管理」タブの「スケジューラ」をクリックします。

3. 「新規」をクリックして、新しいスケジュール済ジョブを作成します。その後、ジョブ名をFlat Fileとして指定し、「タスク」フィールドで、参照から値をフラット・ファイル・コネクタ・ユーザー・リコンシリエーションとして選択します。ジョブの作成後、図11-15に示すようにジョブに値を指定します。スケジュール済タスクを追加して、図11-15に示すように、タイプにフラット・ファイル・コネクタ・ユーザー・リコンシリエーションを追加します。

図11-15 拡張コンソールの「スケジュール済タスク」画面

4. パラメータを次のように設定します。

- 「ITリソース名」の値はFlat Fileとします。

- リソース・オブジェクト名の値はFLATFILEとします。

- 「オブジェクト・タイプ」の値は「ユーザー」とします。

5. 「適用」をクリックします。

11.2.4.2 リコンシリエーション・プロファイルの作成

リコンシリエーション・プロファイルでは、リコンシリエーション時のオブジェクト属性の構造を定義します。リコンシリエーション・プロファイルには、リコンシリエーションをサポートしているすべての属性が含まれている必要があります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「リソース管理」の下の「リソース・オブジェクト」をクリックします。

3. 「Flat File」リソース・オブジェクトを開きます。

4. 図11-16に示すように、オブジェクト・リコンシリエーション・タブをクリックします。

図11-16 Design Consoleのオブジェクト・リコンシリエーション

5. 次のリコンシリエーション・フィールドを追加します。

- Return Id [String]、必須

- 名前 [String]、必須

- 性別 [String]

- 年齢 [String]

- 性別 [String]

- ITリソース名 [IT Resource]、必須

6. 構成を保存します。

11.2.4.3 リコンシリエーション・アクション・ルールの設定

リコンシリエーション・アクション・ルールでは、リコンシリエーションの動作を定義します。この手順では、一致が見つかった場合に行われるアクションを定義します。この手順では、Oracle Identity Manager Design Consoleにログインしていることを前提にしています。

1. 「Flat File」リソース・オブジェクトを開きます。

2. オブジェクト・リコンシリエーション・タブをクリックします。

3. 右側のフレームのリコンシリエーション・アクション・ルール・タブをクリックします。

図11-17 Design Consoleのリコンシリエーション・アクション・ルール

4. 1つのプロセス一致が見つかった場合(「ルール条件」)およびリンクの確立(「アクション」)として定義したアクション・ルールを追加します。

5. 1つのエンティティ一致が見つかった場合(「ルール条件」)およびリンクの確立(「アクション」)として定義したアクション・ルールを追加します。

6. リコンシリエーション・プロファイルの作成をクリックします。

7. 「保存」をクリックします。

11.2.4.4 リコンシリエーション・マッピングの作成

リコンシリエーション・マッピングは、プロセス定義で実行する必要があります。これは、サポートされているリコンシリエーション・フィールドを(リソース・オブジェクトから)プロセス・フォーム・フィールドにマッピングすることです。このマッピングは、ターゲット・リコンシリエーションを構成する場合にのみ必要となります。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「プロセス管理」の下の「プロセス定義」をクリックします。

3. Flat Fileプロセス定義を開きます。

4. 図11-18に示すように、リコンシリエーション・フィールド・マッピング・タブをクリックします。

図11-18 Design Consoleのリコンシリエーション・フィールド・マッピング

5. リコンシリエーション・プロファイル・フィールドとプロセス・フォーム・フィールドとの間のマッピングを追加します。

- ReturnId[String] = UD_FLATFILE_RETURNID

- Name[String] = UD_FLATFILE_NAME, <KEY>

- Age[String] = UD_FLATFILE_AGE

- Gender[String] = UD_FLATFILE_GENDER

- Qualification[String] = UD_FLATFILE_QUALIFICATION

- IT Resource Name[IT Resource] = UD_FLATFILE_ITRESOURCE,<KEY>

6. 構成を保存します。

11.2.4.4.1 リコンシリエーション属性マップで使用されるフィールド・フラグ

9

注意:

これらのプロパティは、高度なオプションで、コネクタの現在の実装では省略できます。

リコンシリエーション属性マッピングの場合は、次のフィールド・フラグをコード・キーに追加できます。

- TRUSTED: これは、アカウントのステータスを表すフィールドのリコンシリエーション属性マップで指定する必要があります。このフラグは、信頼できるリコンシリエーションにのみ指定する必要があります。これが指定されている場合、アカウントのステータスは「アクティブ」または「無効」のいずれかになります。それ以外の場合、ステータスは「有効」または「無効」のいずれかになります。たとえば、ラベルがStatusで、値が「アクティブ」または「無効」のいずれかである必要があるフィールドのコード・キーは、Status[TRUSTED]のようになります。

- DATE: これは、リコンシリエーション属性マップにおいて、タイプがDateと見なされる必要があるフィールドに指定する必要があります。たとえば、ラベルがTodayで、値が日付形式で表示される必要があるフィールドのコード・キーは、Today[DATE]のようにする必要があります。

11.2.4.5 リコンシリエーション一致ルールの定義

リコンシリエーション一致ルールでは、ユーザー一致の計算用の式を定義します。

1. Oracle Identity Manager Design Consoleにログインします。

2. 「開発ツール」の下の「リコンシリエーション・ルール」フォームを開きます。

3. 「ルールの追加」をクリックします。

図11-19 リコンシリエーション一致ルールの追加

4. リソース・オブジェクトFlat Fileを選択します。

5. リコンシリエーション・ルール要素が追加されてから、リコンシリエーション・ルールがアクティブになっているように「アクティブ」フラグを確認します。

6. このルール要素を保存して追加します。
ユーザー・プロファイル・データの「ユーザー・ログイン」は、「名前」リソース属性と同等です。

7. ルールを保存します。

注意:

リコンシリエーション・ルールに変更を行った場合は必ず、リコンシリエーション・プロファイルを再作成する必要があります。

11.3 フラット・ファイル・アカウントのプロビジョニング

フラット・ファイル・コネクタが動作する準備が整ったため、ユーザーは、Oracle Identity Managerにログインし、次の手順を使用してITリソース(ターゲット)を作成する必要があります。

- タイプがFlat FileであるITリソースを作成します。

- 必要に応じて、ITリソース・パラメータを指定します。

- 必要に応じて、Lookup.FlatFile.Configurationに構成パラメータを指定します。

12 ICFとOracle Identity Managerの統合

Oracle Identity Managerの目的は、アイデンティティ管理のビジネス・ロジックを管理し、プロビジョニングおよびリコンシリエーション操作の実行をIdentity Connector Framework (ICF)に委任することです。Oracle Identity Manager (OIM)でのICFは、すべてのスケジュール済タスクとICFベースのコネクタのプロビジョニング・タスクを結合します。

この章は、ICF-OIM統合の概念情報を示す次の項で構成されています。

- 第12.1項「ICF共通」

- 第12.2項「統合アーキテクチャ」

- 第12.3項「Oracle Identity Managerのグローバル参照」

- 第12.4項「ITリソース」

- 第12.5項「プロビジョニング」

- 第12.6項「ICF共通でのリコンシリエーションの概念」

- 第12.7項「事前定義済のスケジュール済タスク」

- 第12.8項「ICFフィルタの構文」

12.1 ICF共通

OIM ICF統合レイヤーは、片面にICF APIが実装され、もう片面でOIM API (icf-oim-intg.jar)を起動します。これにより、API抽象化が提供されるため、コネクタ開発者の複雑性が削減されます。また、プロビジョニングおよびリコンシリエーション操作もサポートします。ICF共通を使用したプロビジョニングおよびリコンシリエーションの詳細は、第12.5項「プロビジョニング」および第12.6項「ICF共通でのリコンシリエーションの概念」を参照してください。

12.2 統合アーキテクチャ

ICF-OIM統合アーキテクチャは次のとおりです。

図12-1 OIM-ICFコネクタ開発アーキテクチャ

12.3 Oracle Identity Managerのグローバル参照

OIM構成メタデータの格納に参照が使用されます。ITリソースのパラメータ構成参照は、Oracle Identity Manager固有のすべての構成情報をカプセル化するメインの構成参照をポイントします。

参照構成に基づいて、プロパティを次の3つのクラスに分類できます。

- ITリソース: 接続性プロパティ: ターゲット・システムへの接続の確立に使用するすべてのプロパティが含まれます。

- メインの構成参照の構成プロパティ: リコンシリエーションまたはプロビジョニングのモードを変更する非接続性プロパティが含まれており、接続には必要ありません。接続性と構成のプロパティにはわずかな違いがあるため、1つのプロパティを両方に割り当てることができます。

- オブジェクト・タイプ: 特定の参照(たとえば、ユーザー管理構成)、特定のオブジェクト・タイプのマッピング参照(たとえば、ユーザー、グループ、組織単位)。

注意:

LOADFROMURLフラグは、たとえば、sampleProperty[LOADFROMURL]などのコード(キー)・フィールドのITリソースまたはメインの構成参照で使用できます。これがマーク付けされているプロパティでは、値(デコード値)はURLです。ICF統合は、特定のURLに格納されたファイルのコンテンツを読み込み、実行時に特定のプロパティの値として使用します。これは、直接参照には適合しない大きい値に役立ちます。

図12-2に、ほとんどのコネクタがユーザー管理参照を使用するOracle Identity Managerグローバル参照を示します。

図12-2 Oracle Identity Managerコネクタ参照の階層

このセクションのトピックは次のとおりです:

- 第12.3.1項「メインの参照構成」

- 第12.3.2項「ユーザー管理構成」

- 第12.3.3項「リコンシリエーション変換参照(Lookup.CONNECTOR_NAME.UM.ReconTransformation)」

- 第12.3.4項「リコンシリエーション検証参照(Lookup.CONNECTOR_NAME.UM.ReconValidation)」

- 第12.3.5項「オプションのデフォルト参照」

12.3.1 メインの参照構成

ITリソースのパラメータ構成参照は、OIM固有のすべての構成情報をカプセル化するメインの構成参照をポイントします。

Lookup.CONNECTOR_NAME.Configurationとして示される構成参照は、リコンシリエーションおよびプロビジョニング用に下位参照を参照する最上位レベルのエントリです。構成参照の構造は次のとおりです。

表12-1 コネクタの参照構成

構成キー

値

説明

コネクタ名

org.identityconnectors.CONNECTOR_NAME.Connector

アイデンティティ・コネクタのメイン・クラス。これは、ICFフレームワークのSPI操作を実装するクラスです。

バンドル名

org.identityconnectors.CONNECTOR_NAME

アイデンティティ・コネクタのバンドル名

バンドル・バージョン

11.1.1.5.x

アイデンティティ・コネクタのバンドル・バージョン

ユーザー構成参照

注意: 一般的なLDAPコネクタ、グループ構成参照、OU構成参照などには他のオブジェクト・タイプが定義されている場合があります。

Lookup.CONNECTOR_NAME.UM.Configuration

ユーザー固有の構成参照にリンクします。注意: ユーザーはオブジェクト・タイプである必要があります。他のオブジェクト・タイプをサポートする必要がある場合は、OBJECT_TYPE構成参照をキーとして使用できます。

12.3.2 ユーザー管理構成

これらの参照は、プロビジョニングおよびリコンシリエーション用のマッピングを制御します。また、これらの参照は、変換および検証を構成する場合があります。

この参照には、次のキーが含まれています。

- Before Create Action Language: Lookup.CONNECTOR_NAME.UM.Configurationにこのキーが存在する場合、言語がこのキーの値であるスクリプトがあることがICFに通知されます。このキーの値(Groovy/cmd)は、作成操作の前にICFによって実行される必要のあるスクリプトの言語を示します。

- Before Create Action File: Lookup.CONNECTOR_NAME.UM.Configurationにこのキーが存在する場合、このキーの値によって示されたスクリプトが作成アクション前にICFによって実行される必要があることが通知されます。このスクリプトは、Oracle Identity Managerサーバーにアクセス可能である必要があります。

- Before Create Action Target: Lookup.CONNECTOR_NAME.UM.Configurationにこのキーが存在する場合、前述の2つのキーによって定義されたスクリプトをリソースまたはコネクタ上のいずれかで実行する必要があることがICFに通知されます。この構成に応じて、ICF API runScriptOnConnectorまたはrunScriptOnResourceが実行されます。

図12-1は、ユーザー管理参照構成を説明しています。

表12-2 コネクタのユーザー管理参照構成

構成キー

値

必須フィールド・タイプ

説明

プロビジョニング属性マップ

Lookup.CONNECTOR_NAME.UM.ProvAttrMap

Y

この参照には、Oracle Identity Managerフィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、プロビジョニング時に使用されます。

リコンシリエーション属性マップ

Lookup.CONNECTOR_NAME.UM.ReconAttrMap

Y

この参照には、Oracle Identity Managerリコンシリエーション・フィールドとアイデンティティ・コネクタ属性との間のマッピングが含まれています。このマッピングは、リコンシリエーション時に使用されます。

リコンシリエーション属性デフォルト

Lookup.CONNECTOR_NAME.UM.ReconDefaults

N

このマッピングには、OIM属性のデフォルト値が含まれており、リコンシリエーション中にコネクタによって値が指定されない場合に置換されます。

リコンシリエーション変換参照

Lookup.CONNECTOR_NAME.UM.ReconTransformation

N

リコンシリエーション・タスクを実行による変換の参照。変換は、LookupReconTask以外のすべてのリコンシリエーション・タスクで使用されます。

リコンシリエーション検証参照

Lookup.CONNECTOR_NAME.UM.ReconValidation

N

リコンシリエーション・タスクを実行して検証に使用する参照。検証は、LookupReconTask以外のすべてのリコンシリエーション・タスクで使用されます。

リコンシリエーション除外リスト

Lookup.CONNECTOR_NAME.UM.ReconExclusionList

N

除外リストは、コネクタの管理されていないアカウントを処理する方法の1つです。リコンシリエーション/プロビジョニング中、除外リストと一致するものは、OIMによって処理されません。

除外リストによってサポートされる2つのタイプのルールがあります。

- 一致ルール
直接一致ルール

コード・キー: リコンシリエーション・フィールド名

デコード・キー: 除外フィールド値

- パターン一致ルール

[PATTERN]タグ接尾辞を付け、パターン一致を可能にします。

コード・キー: ReconFieldName[PATTERN]

デコード・キー: 除外パターン

除外パターンは、java.util.regex.Patternで定義された命名体系に従う必要があります。

この表のリコンシリエーション除外リスト・キーを参照してください。

プロビジョニング除外リスト

Lookup.CONNECTOR_NAME.UM.ProvExclusionList

N

プロビジョニングでは、コード・キーがフォーム・ラベル名で、デコード・キーが除外値/パターンです。

プロビジョニング検証参照

Lookup.CONNECTOR_NAME.UM.ProvValidation

N

プロビジョニングによる検証の参照。

ICFは、追加のパラメータ・リストで、すべての操作に送信できるOperationOptionの概念を定義します。コネクタ実装によって、これらの操作オプションの使用が定義されます。

操作オプション・マップ

Lookup.CONNECTOR_NAME.UM.OperationOptions

N

コード・キーは、定数Operation Options Mapです。操作オプションのマップとして使用される参照のデコード値名。

たとえば、Lookup.Domino.UM.OperationOptionsでは、コード・キーがCACertifier[UPDATE,DELETE]、デコード値がCACertifierで、これは、更新および削除操作のコールに追加の操作オプションとしてこの属性が送信されることを意味します。

アクション実行を構成する場合、スクリプトに3つのパラメータを指定する必要があります。

- 言語

- ファイル

- ターゲット

スクリプト作成属性

スクリプトのトリガー時間は、参照キーの次のラベルによって制御されます。

- Before

- After

スクリプトにアタッチされているプロビジョニング操作タイプは、次のラベルによって制御されます。

- Create

- Update

- Delete

Before Create Action Language

SCRIPTING_LANGUAGE_NAME

N

Groovy/cmdなど、実行されるアクションの言語。アクションの実行を構成する場合、3つのオプションLanguage/File/Targetを指定する必要があります。プロビジョニング操作Create/Update/Deleteに、Before/Afterアクションを構成できます。

Before Create Action File

FILE_PATH

N

実行する必要のあるスクリプトを含むファイル。このファイルは、Oracle Identity Managerサーバーにアクセス可能である必要があります。

Before Create Action Target

コネクタまたはリソース

N

アクションのターゲットは、コネクタまたはリソースです。この構成に応じて、ICF APIのrunScriptOnConnectorまたはrunScriptOnResourceが使用されます。

12.3.3 リコンシリエーション変換参照(Lookup.CONNECTOR_NAME.UM.ReconTransformation)

変換コードは、Oracle Identity Managerの外部Javaタスクで、LookupReconTask以外のすべてのリコンシリエーション・タスクで使用されます。これは、Oracle Identity Managerリポジトリにアップロードされる(リコンシリエーション中にターゲット・システムから取得されるデータを変換する)Javaクラスです。

変換を実行するJavaクラスには、署名public Object transform(HashMap arg0, HashMap arg1, String arg2)を持つメソッドが実装されている必要があります。ICFは、正確な署名を使用して、このメソッドを検索します。

変換javaクラスのテンプレートは、次のとおりです。

public class MyTransformer implements oracle.iam.connectors.common.transform.Transformation {
public Object transform(java.util.HashMap hmUserDetails, java.util.HashMap hmEntitlementDetails, String sField) {
String sFirstName= (String)hmUserDetails.get("First Name");
String sLastName= (String)hmUserDetails.get("Last Name");
String sFullName=sFirstName+"."+sLastName;
return sFullName;
}
}

リコンシリエーション変換参照を格納する参照の名前は、表12-3で示されているように、メイン構成参照(Lookup.CONNECTOR_NAME.Configuration)で定義されています。

表12-3 リコンシリエーション変換参照

キー

値

説明

リコンシリエーション・フィールド名

<transformationClassName>

com.validationexample.MyTransform

このリコンシリエーション・フィールドの変換を実行するJavaクラス。

12.3.4 リコンシリエーション検証参照(Lookup.CONNECTOR_NAME.UM.ReconValidation)

検証コードは、Oracle Identity Managerの外部Javaタスクで、リコンシリエーション中にターゲット・システムから取得されるデータの検証に使用されます。これは、Oracle Identity Managerリポジトリにアップロードされる(リコンシリエーション中にターゲット・システムから取得されるデータを変換する)Javaクラスです。

検証を実行するJavaクラスには、署名public boolean validate (HashMap arg0, HashMap arg1, String arg2)を持つメソッドが実装されている必要があります。ICFは、正確な署名を使用して、このメソッドを検索します。

検証Javaクラスのテンプレートは次のとおりです。

public class MyValidator implements oracle.iam.connectors.common.validate.Validator {
public boolean validate(java.util.HashMap hmUserDetails, java.util.HashMap hmEntitlementDetails,String sField) throws oracle.iam.connectors.common.ConnectorException {
boolean isValid = false;
// validation code goes HERE
return isValid;
}
}

リコンシリエーション検証参照を格納する参照の名前は、表12-4で示されているように、メイン構成参照(Lookup.CONNECTOR_NAME.Configuration)で定義されています。

表12-4 リコンシリエーション検証参照

キー

値

説明

リコンシリエーション・フィールド名

<transformationClassName>

com.validationexample.MyValidator

このリコンシリエーション・フィールドの検証を実行するJavaクラス。

12.3.5 オプションのデフォルト参照

リコンシリエーション用の欠落した値は、次の表で定義されたデフォルト値で置換されます。ユーザー・タイプは、必須のOIM属性で、通常、ターゲット・リソースには含まれていません。デフォルト値を設定できます。

たとえば、信頼できるリコンシリエーションでは、コネクタからの一連の属性に空でない値が必要です。ただし、すべてのリソースがこれらすべての属性タイプを指定できるわけではないため、一部デフォルト値を指定する必要があります。表12-5には、リコンシリエーションの必須属性および使用できるデフォルト値がリストされています。

コネクタがリコンシリエーションに必要なすべての属性を指定できる場合、この表はオプションになります。

表12-5 Lookup.CONNECTOR_NAME.UM.Recon.Defaults.Trusted属性

キー

値

姓

CONNECTOR_DEPENDENT_VALUE

組織

Xellerate users

ユーザー・タイプ

End-User

従業員タイプ

Full-Time

名

CONNECTOR_DEPENDENT_VALUE

注意:

これらのデフォルト値は、単一値フィールドでのみサポートされており、これは、複数値または子表属性がサポートされていないことを意味します。

12.4 ITリソース

ITリソースには、ターゲット・システムの接続パラメータが含まれています。これらのパラメータは、ICF統合を使用するすべてのコネクタに必須です。

表12-6は、共通のITリソース・パラメータを説明しています。

関連項目:

ターゲット・システムおよびコネクタ・サーバーのITリソース・パラメータの詳細は、デプロイ対象のコネクタのドキュメントを参照してください。

表12-6 ITリソース・パラメータ

パラメータ

説明

コネクタ・サーバー名

コネクタ・サーバーのITリソース名。ITリソースは、タイプがコネクタ・サーバーである必要があります。このフィールドは、必須フィールドですが、値はオプションです。

構成参照

メイン構成参照の名前。このフィールドは必須フィールドです。

12.5 プロビジョニング

この項の項目は次のとおりです。

- 第12.5.1項「ICFプロビジョニング・マネージャ」

- 第12.5.2項「プロビジョニング参照」

- 第12.5.3項「ユーザー以外のオブジェクト・タイプ」

- 第12.5.4項「プロビジョニングのオプションの参照」

- 第12.5.5項「プロビジョニング属性マップの参照でのオプション・フラグ」

- 第12.5.6項「プロビジョニング属性マップでの複合属性」

12.5.1 ICFプロビジョニング・マネージャ

ICFプロビジョニング・マネージャは、コネクタのプロビジョニング・メソッドへのアクセスを、すべてのコネクタを処理する1つのJavaタスクに結合します。

パブリック・メソッドは4つのグループに分けられます。

- 第12.5.1.1項「プロビジョニング用のAPI」

- 第12.5.1.2項「アカウント関連の操作」

- 第12.5.1.3項「複数値の操作」

- 第12.5.1.4項「その他の操作」

12.5.1.1 プロビジョニング用のAPI

単一値のCRUDオブジェクト・タイプは次のとおりです。

createObject

ターゲット・リソースに指定したタイプのオブジェクトを作成すると、現在のフォームから値が取得されます。

シグネチャ: public String createObject(String objectType)l

deleteObject

ターゲット・リソースの指定したタイプのオブジェクトを削除します。

シグネチャ: public String deleteObject(String objectType)

updateAttributeValue

ターゲット・リソースでのオブジェクトの更新では、指定されたラベルを持つ属性のみが更新されます。

シグネチャ: public String updateAttributeValue(String objectType, String attrFieldName)

updatePassword

古いパスワード値を指定する必要のある場合のみ、アダプタでこのメソッドを使用します(現在、formAPIを使用して古い値を取得する方法はありません)。パスワードを変更するために古いパスワード値が必要ない場合、かわりに#updateAttributeValue(String, String)メソッドを使用します。

シグネチャ: public String updatePassword(String objectType, String pswdFieldLabel, String oldPassword)

12.5.1.2 アカウント関連の操作

プロビジョニング操作に関連するアカウントは次のとおりです。

enableUser

非推奨、かわりにenableObject()を使用。

シグネチャ: public String enableUser()

disableUser

非推奨、かわりにdisableObject()を使用。

シグネチャ: public String disableUser()

enableObject

User: enableObject("User")の使用例。

シグネチャ: public String enableObject(String objectType)

disableObject

シグネチャ: public String disableObject(String objectType)

12.5.1.3 複数値の操作

プロビジョニングで使用する複数値操作は次のとおりです。

updateAttributeValues

フィールドのグループ更新がある場合に、このメソッドを使用します。これは、一連の属性を一度に更新する場合に役立ちます。

シグネチャ: public String updateAttributeValues(String objectType, String[] labels) public String updateAttributeValues(String objectType, Map<String, String> fields) public String updateAttributeValues(String objectType, Map<String, String> fields, Map<String, String> oldFields)}}}

addChildTableValue

子表に新しく追加された行を追加することで、ターゲットを更新します。

シグネチャ: public String addChildTableValue(String objectType, String childTableName, long childPrimaryKey)

removeChildTableValue

子表から削除された行を削除して、ターゲットを更新します。

シグネチャ: public String removeChildTableValue(String objectType, String childTableName, Integer taskInstanceKey)

updateChildTableValue

削除された行を削除し、新しく作成された行を追加することで、ターゲットを更新します。

シグネチャ: public String updateChildTableValue(String objectType, String childTableName, Integer taskInstanceKey, long childPrimaryKey)

updateChildTableValue

ターゲット・リソースの子表で指定された値を更新します。

シグネチャ: public String updateChildTableValues(String objectType, String childTableName)

12.5.1.4 その他の操作

プロビジョニングで使用されるその他の操作は次のとおりです。

setEffectiveITResourceName

コネクタがプロビジョニング操作で、異なるITリソースを使用する必要がある場合、このメソッドで設定できます。

シグネチャ: public void setEffectiveITResourceName(String itResourceName)

12.5.2 プロビジョニング参照

Lookup.CONNECTOR_NAME.UM.ProvAttrMapには、2つのクラスの属性の単純な属性マッピングが含まれています。

- 単一値属性: 単純な文字列キー + 値の組合せ

- 複数値の属性(Oracle Identity Managerの子表): これらは階層の深さによってさらに分けられます。

- 単純な複数値の属性: 子表に格納されているデータのレコードを示します(表12-7の2行目を参照)。

- 複雑な複数値の属性: 組込みオブジェクトの複数のレベル(表12-7の最後の行を参照)。

表12-7 プロビジョニング参照属性

キー

値

説明

フォーム・フィールド・ラベル

ConnectorAttributeName

これは、単純なフォーム・ラベル名から単一値コネクタ属性名への基本的なマッピング・タイプです。

子フォーム名>~<子フォーム・フィールド・ラベル

ConnectorAttributeName

これは、子フォーム・フィールドを複数値ConnectorAttributeNameにマップします。

子フォーム名>~<子フォーム・フィールド・ラベル

ConnectorAttributeName>~<EmbeddedObjectClass>~<EmbeddedAttributeName

これは、子フォーム・フィールドを組込みオブジェクトのEmbeddedAttributeにマップし、これのオブジェクト・クラスはEmbeddedObjectClassで、ConnectorAttributeNameに含まれています。

12.5.3 ユーザー以外のオブジェクト・タイプ

たとえば、LDAP組織単位(OUとも呼ばれる)、LDAPグループ、グループなど、プロビジョニングできるその他のエンティティも多数あります。この場合、次の例のOBJECT_TYPEを記入する必要があります。

メイン構成参照Lookup.CONNECTOR_NAME.Configuration

表12-8 コネクタの構成参照

キー

値

説明

objectType構成参照

Lookup.<ConnectorName>.<objectType>.ProvAttrMap

グループ構成参照

Lookup.LDAP.Group.ProvAttrMap

LDAPグループの例

プロビジョニング参照Lookup.CONNECTOR_NAME.OBJECT_TYPE.ProvAttrMap

キー

値

説明

FORM_FIELD_LABEL_ON_THE_PROCESS_FORM

ターゲット・システム属性名

Oracle Identity Managerとコネクタ間での属性マッピング。

12.5.4 プロビジョニングのオプションの参照

キー

値

説明

FORM_FIELD_NAME [Create, Update, Delete]

ConnectorOperationOptionName

このフィールドは、汎用的な定義に使用されます。

たとえば、フィールドがmyOperationOptionという名前のコネクタに送信されるCreateOpの操作オプションにマップされる場合です。

myField[Create]

myOperationOption

12.5.4.1 プロビジョニング検証参照

検証コードは、OIM外部Javaタスクで、OIMリポジトリにアップロードされるJavaクラスです。検証Javaクラス・テンプレート:

public class MyValidator implements oracle.iam.connectors.common.validate.Validator {
public boolean validate(java.util.HashMap hmUserDetails, java.util.HashMap hmEntitlementDetails,String sField) throws oracle.iam.connectors.common.ConnectorException {
boolean isValid = false;
// validation code goes HERE
return isValid;
}
}

リコンシリエーション検証参照を格納する参照の名前は、メイン構成参照(Lookup.CONNECTOR_NAME.Configuration)で定義されています。

キー

値

説明

フォーム・フィールド・ラベル

validatorClassName

com.validationexample.MyValidator

このリコンシリエーション・フィールドの検証を実行するJavaクラス。

12.5.5 プロビジョニング属性マップの参照でのオプション・フラグ

ICF-OIM統合により、プロビジョニングの方法を変更する高度なフラグが提供されます。参照キーのフラグの形式の例は次のとおりです。

<key value>[<flag>]
<key value>[<flag1, flag2, flag3>]

UnixGroupコネクタ属性にマップされるグループOIM属性があると仮定します。このOIM属性は、UI参照によって移入されます。プロビジョニング参照の正しい行は次のとおりです。

nullLookup key: Group[LOOKUP]
Lookup value: UnixGroup }}}

次にフラグとその影響のリストを示します。

プロビジョニング参照フラグ: TRUSTED

一部の属性(たとえば、信頼できるリコンシリエーションの__ENABLE__属性)では、操作の信頼できるターゲット・モードに異なる値を渡す必要があります。ステータス「リコンシリエーション」をサポートするほとんどのコネクタでは、コード・キー: Status[Trusted]、およびデコード値: __ENABLE__が使用されます。

プロビジョニング参照フラグ: IGNORE

IGNOREとしてマーク付けされている属性は、プロビジョニング中無視されます。

プロビジョニング参照フラグ: WRITEBACK

フィールドがWRITEBACKプロパティを持つ場合、そのフォーム・フィールドの更新は次のようになります:

1. ターゲット・システムの値の更新

2. ターゲット・システムから戻された値の問合せ(正規化された値を取得するため)

3. ユーザー・フォームでのこの正規化された値の更新

プロビジョニング参照フラグ: DATE

このフラグを使用して、日付フィールドをマーク付けします。Oracle Identity Managerは、これらのフィールドにローカライズされた日付形式を適用します。

プロビジョニング参照フラグ: PROVIDEONPSWDCHANGE

このフラグを使用して、パスワード変更操作に必要な追加の属性をマーク付けします。デフォルトでは、フラグが適用されていない場合、__PASSWORD__属性のみが送信されます。

12.5.6 プロビジョニング属性マップでの複合属性

ICF共通では、右辺にGroovy式を使用でき、プロビジョニングされた属性の複数のフィールドに基づいた計算を可能にします。たとえば、Active Directoryコネクタでは、名前フィールドのデコード値は次のとおりです。

__NAME__=CN=${Common_Name},${Organization_Name}

12.6 ICF共通でのリコンシリエーションの概念

ICF共通は、Oracle Identity Managerサーバーで定義されたリコンシリエーションの定義およびタイプを利用します。ITリソースの名前/リソース・オブジェクト名およびオブジェクト・タイプは、ICF共通を使用した必須の属性リコンシリエーションです。ずべてのターゲット・システム属性は、最新のトークン属性として使用できます。

この項には次のトピックが含まれます:

- 第12.6.1項「リコンシリエーションのタイプ」

- 第12.6.2項「Oracle Identity Managerのリコンシリエーション・アーティファクトのリスト」

12.6.1 リコンシリエーションのタイプ

リコンシリエーションには、リソース(ターゲットとも呼ばれる)から宛先(Oracle Identity Manager)へのアイデンティティを取得することが含まれます。リコンシリエーションは次の基準に基づいて分類できます。

- 宛先タイプ: 信頼できる、ターゲット・リコンシリエーション。

- スコープ: 完全、増分リコンシリエーション。

表12-9は、共通のリコンシリエーション・パラメータを説明しています。

表12-9 ICF共通のリコンシリエーション・パラメータ

パラメータ

フィールド設定

説明

フィルタ

オプション

フィルタ処理して、リコンサイルされるアカウントの数を制限するかまたは特定の一連のユーザーを選択します。

ITリソース名

必須

リコンシリエーションを実行するITリソース・インスタンスの名前。

オブジェクト・タイプ

定数

ユーザー・オブジェクト・クラス

リソース・オブジェクト名

定数

リコンシリエーションに使用するOIMリソース・オブジェクトを決定します。

12.6.1.1 ターゲットおよび信頼できるリコンシリエーション

信頼できる、ターゲットなどのキーワードを含むスケジュール済タスク名で、宛先のタイプを決定します。スケジュール済タスクを選択することで、信頼できるリコンシリエーションを開始するかまたはターゲット・リコンシリエーションを開始するかが決定されます。

12.6.1.2 完全リコンシリエーションおよび増分リコンシリエーション

完全リコンシリエーションでは、既存のすべてのユーザー・レコードをターゲット・システムからOracle Identity Managerへリコンサイルします。完全リコンシリエーション中、スケジュール済タスクが初めて開始されると、完全リコンシリエーション・モードで実行され、その次からは増分モードで実行されます。スケジュール済タスクの「最新のトークン」フィールドを空にすることで、手動で完全/増分リコンシリエーション・モードを切り替えることができます。

増分リコンシリエーション日付属性および増分リコンシリエーション属性に値が指定されていない場合は、リコンシリエーションはターゲット・リコンシリエーションとしてみなされます。

次のスケジュール済タスクは、オプションの増分リコンシリエーションを提供します。

- Connector Target User Reconciliation

- Connector Trusted User Reconciliation

12.6.1.3 高度な増分リコンシリエーション

最新のトークンの書式は、「リコンシリエーション日付書式」スケジュール済タスク・パラメータを設定すると変更されます。書式文字列は、Javaで使用される標準パターンに従う必要があります。Javaで使用される書式文字列の詳細は、Oracle Technology NetworkのJavaのドキュメントを参照してください。

デフォルトでは、最新のトークンは、Unix/POSIX時間を保持するlong値です。

12.6.1.4 リコンシリエーションの削除

一部のコネクタでは、削除されたアカウントの信頼できるリコンシリエーションおよびターゲット・リコンシリエーションの両方をサポートします。ターゲット・リコンシリエーションは、リソースでアカウントを消失したOIMユーザーを評価し、Oracle Identity Managerでこのリソースを割当て解除します。信頼できる削除リコンシリエーションでは、さらにOIMユーザーを削除します。

12.6.1.5 グループ参照リコンシリエーション

一部のコネクタでは、グループまたは参照への他のオブジェクト・クラスのリコンシリエーションをサポートする場合があります。

コネクタでのプロビジョニングを初めて使用する前に、参照リコンシリエーションを開始することをお薦めします。このリコンシリエーションでは、Lookup.CONNECTOR_NAME.ObjectType表に、リコンサイルされるITリソースで使用可能なグループを移入します。リコンシリエーションは、コネクタ参照リコンシリエーションのスケジュール済タスクによって実行されます。

ITリソースのパラメータ名、を設定する必要があり、残りのパラメータは、表12-9で示されるように定数です。

表12-10は、共通のリコンシリエーション・パラメータを示します。

表12-10 共通のグループ参照パラメータ

コード・キー

デコード・キー

オブジェクト・タイプ

フォーム・フィールド名

コネクタ属性

グループまたはその他

たとえば、コネクタによって返された名前のリストを使用して、プロビジョニング用の参照を移入します。新しいユーザーがプロビジョニングされたとき、グループ・フィールドに使用可能なグループのリストが表示されます。

12.6.2 Oracle Identity Managerのリコンシリエーション・アーティファクトのリスト

Oracle Identity Managerでは、リコンシリエーションを制御する2つの方法があります。

- リコンシリエーションの参照: マッピング、属性の変換を定義します。

- スケジュール済タスク - コネクタ側でのリコンシリエーションの実行方法を定義するか、またはリコンシリエーションのアカウント/参照モードを決定します。

12.6.2.1 リコンシリエーションの参照

リコンシリエーションの参照は次のとおりです。

リコンシリエーション属性マップ参照

リコンシリエーション属性マップには、次の組合せが含まれます。

- コード・キー: リソース・オブジェクトのリコンシリエーション・フィールド名

- デコード: ターゲット・システム属性名

表12-11は、リコンシリエーションを実行するスケジュール済タスクによって使用されるこのマッピング(Lookup.CONNECTOR_NAME.UM.ReconAttrMap)を示しています。

注意:

リソース・オブジェクトは、信頼できるリコンシリエーション・モードとターゲット・リコンシリエーション・モードで異なります。

表12-11 Lookup.CONNECTOR_NAME.UM.ReconAttrMapの属性マッピング

キー

値

説明

リコンシリエーション・フィールド名

ConnectorAttributeName

これは、単一値コネクタ属性名から単純なリコンシリエーション・フィールドへの基本的なマッピング・タイプです。

リコンシリエーション・フィールド名~子リコンシリエーション・フィールド名

ConnectorAttributeName

これは、複数値のConnectorAttributeNameを子リコンシリエーション・フィールドへマップします。

リコンシリエーション・フィールド名~子リコンシリエーション・フィールド名

ConnectorAttributeName~EmbeddedObjectClass~EmbeddedAttribute

これは、組込み属性を子リコンシリエーション・フィールドにマップします。

Design Consoleを更新して、子表でリコンシリエーションを設定する例

次の例では、Design Consoleを更新して、子表でリコンシリエーションを設定します。

- 子表の名前: UD_FF_CHILD

- 列名: UD_FF_CHILD_ROLE

- フィールド・ラベル: Role
前述の子表を使用して、リコンシリエーションを設定するには:

1. 「リソース管理」の下の「リソース・オブジェクト」を開きます。

2. 「オブジェクト・リコンシリエーション」タブの下に、新しいリコンシリエーション・データ・フィールドを作成します。

注意:

新しいリコンシリエーション・データ・フィールドの作成中に、フィールド名がロールで、フィールド・タイプが複数値属性であることを確認する必要があります。これは、UD_FF_CHILD全体として子表を表します。

3. 新しく作成したリコンシリエーション・データ・フィールドで右クリックして、新しいプロパティ・フィールドを「ロール」として定義します。これは、子表UD_FF_CHILD_ROLEの実際の列を表します。

4. 「プロセス定義」の下でリコンシリエーション・フィールド・マッピングを開きます。

5. 表マップの追加をクリックします。

6. 「フィールド名」を「ロール」として選択します。

7. 表名をUD_FF_CHILDとして選択します。

8. 新しく作成したフィールド名Rolesを右クリックして、適切なフィールド名の定義をクリックします。

9. フィールド名にRoleを選択します。

10. UD_FF_CHILD_ROLEとしてプロセス・データ・フィールドを選択します。

11. Lookup.CONNECTOR_NAME.UM.ReconAttrMapを更新して、新しい参照フィールドにコード・キー = Roles~Roleおよびデコード = Role (これはコンテナ側の属性名です)を含めます。

12. 「リソース・オブジェクト」に戻り、リコンシリエーション・プロファイルを作成します。

13. キャッシュをクリアします。

12.7 事前定義済のスケジュール済タスク

ICF-OIM統合は、コネクタがサポートする事前定義済タスクの次のリストを提供します。

- 第12.7.1項「LookupReconTask」

- 第12.7.2項「SearchReconTask」

- 第12.7.3項「SearchReconDeleteTask」

- 第12.7.4項「SyncReconTask」

12.7.1 LookupReconTask

このスケジュール済タスクはICF SearchOpベースのリコンシリエーションに基づいています。Oracle Identity Managerのタイプ参照のフォーム・フィールドには、事前定義済の一連の値が格納されています。これらの値は、コネクタの検索問合せから生成されます。コード・キー属性は、フォーム・フィールドの名前で、デコード属性は、ターゲット・システム(コネクタとも呼ばれる)上の属性の名前です。

内部的には、このタスクは、最終的にICFクラスに変換される特定のオブジェクト・タイプのコネクタで検索操作を呼び出します。

表12-12 アイデンティティ・コネクタの参照リコンシリエーション属性

キー

値

ITリソース名

ターゲット・システム・インストール用のITリソースの名前を指定します。

オブジェクト・タイプ

ユーザー

参照名

この属性は、値のフェッチ元である必要のあるデータ・ソースに各参照定義をマップする参照定義の名前を保持します。

デコード属性

参照定義のデコード・キー列を指定します。

コード・キー属性

参照定義のコード・キー列を指定します。

フィルタ

スケジュール済タスクの実行のスピード・アップ/絞込みのための高度なフィルタ式の作成ができます。

12.7.2 SearchReconTask

ICF SearchOpベースのリコンシリエーションは次のとおりです。

表12-13 アイデンティティ・コネクタのターゲット検索リコンシリエーション属性

キー

値

ITリソース名

ターゲット・システム・インストール用のITリソースの名前を指定します。

リソース・オブジェクト名

リコンシリエーションに使用するリソース・オブジェクトの名前を指定します。

オブジェクト・タイプ

ユーザー

フィルタ

スケジュール済タスクの実行のスピード・アップ/絞込みのための高度なフィルタ式の作成ができます。

最新のトークン

増分リコンシリエーションの基準の1つとしてフィルタで使用します。ずべてのターゲット・システム属性は、最新のトークン属性として使用できます。この値は次のように計算されます。

リコンシリエーションによって100のレコードがフェッチされ、タイムスタンプが増分リコンシリエーション属性として選択されると、最新のトークン = 100のレコードすべての最大タイムスタンプとなります。スケジュール済タスクの実行終了タイムスタンプではありません。

増分リコンシリエーション日付属性(オプションで日付を入力)

最新のトークンの更新に使用する属性。

注意: 増分リコンシリエーション日付属性に値が指定されていない場合は、リコンシリエーションはターゲット・リコンシリエーションとしてみなされます。

増分リコンシリエーション属性(オプションでlongを入力)

最新のトークンの更新に使用する属性。

注意: 増分リコンシリエーション属性に値が指定されていない場合、リコンシリエーションはターゲット・リコンシリエーションとしてみなされます。

12.7.3 SearchReconDeleteTask

このスケジュール済タスクは、ICF SearchOpベースのリコンシリエーションで使用されます。

表12-14 アイデンティティ・コネクタのターゲット検索削除リコンシリエーション属性

キー

値

ITリソース名

ターゲット・システム・インストール用のITリソースの名前を指定します。

リソース・オブジェクト名

リコンシリエーションに使用するリソース・オブジェクトの名前を指定します。

オブジェクト・タイプ

ユーザー

フィルタ

スケジュール済タスクの実行のスピード・アップ/絞込みのための高度なフィルタ式の作成ができます。

12.7.4 SyncReconTask

このスケジュール済タスクは、ICF SyncOpベースのリコンシリエーションに使用されます。「同期トークン」フィールドは、最後の同期のトークンを保持します。

表12-15 アイデンティティ・コネクタのターゲット同期リコンシリエーション属性

キー

値

ITリソース名

ターゲット・システム・インストール用のITリソースの名前を指定します。

リソース・オブジェクト名

リコンシリエーションに使用するリソース・オブジェクトの名前を指定します。

オブジェクト・タイプ

ユーザー

フィルタ

スケジュール済タスクの実行のスピード・アップ/絞込みのための高度なフィルタ式の作成ができます。

同期トークン

最後に行われた同期のトークン。

12.8 ICFフィルタの構文

GroovyFilterBuilderによって、スケジュール済タスクの実行のスピード・アップ/絞込みのための高度なフィルタ式の作成ができます。

警告:

GroovyFilterBuilderは、フィルタ処理にコネクタ属性名を使用します。属性名については、コネクタのドキュメントを参照してください。

例

次の例では、リコンサイルされるアカウントを「a」から始まるアカウント名のみに制限でき、このフィルタは次の式によって示されます。

startsWith('__NAME__', 'a')

アカウント名が「z」で終わるアカウント名のみにフィルタ処理するにはより高度な検索が必要となり、フィルタは次のようになります。

startsWith('__NAME__', 'a') & endsWith('__NAME__', 'z')

図12-3は、フィルタ構文のグラフィカル・スキームを示しています。

図12-3 フィルタ構文のグラフィック表現

また、and/or演算子にショートカットを使用することもできます。

たとえば、and (<filter1>, <filter2>)ではなく、<filter1> & <filter2>とすることができ、同様に、orを|に置き換えることもできます。

EBNF形式の定義:

リコンシリエーションでのフィルタの検索に使用する式言語のExtended Backus–Naur Form (EBNF)の記述は次のとおりです。

syntax = expression ( operator expression )*
operator = 'and' | 'or'
expression = ( 'not' )? filter
filter = ('equalTo' | 'contains' | 'containsAllValues' | 'startsWith' | 'endsWith'  | 'greaterThan' | 'greaterThanOrEqualTo' | 'lessThan' | 'lessThanOrEqualTo' )  '(' 'attributeName' ',' attributeValue ')'
attributeValue = singleValue  |  multipleValues
singleValue = 'value'
multipleValues = '[' 'value_1' (',' 'value_n')* ']'

表12-16に、使用可能なフィルタ構文と、対応する説明およびサンプル値を示します。

注意:

ワイルドカード文字のあるフィルタはサポートされません、

表12-16 フィルタ属性のキーワードと構文

フィルタ構文

説明

文字列フィルタ

startsWith('ATTRIBUTE_NAME','PREFIX')

指定された接頭辞で始まる属性値のあるレコードがリコンサイルされます。

例: startsWith('userPrincipalName','John')

この例では、userPrincipalNameが「John」で始まるすべてのレコードがリコンサイルされます。

endsWith('ATTRIBUTE_NAME','SUFFIX')

指定された接尾辞で終わる属性値のあるレコードがリコンサイルされます。

例: endsWith('sn','Doe')

この例では、姓が「Doe」で終わるすべてのレコードがリコンサイルされます。

contains('ATTRIBUTE_NAME','STRING')

指定された文字列が属性の値に含まれるレコードがリコンサイルされます。

例: contains('displayName','Smith')

この例では、表示名に「Smith」を含むすべてのレコードがリコンサイルされます。

containsAllValues('ATTRIBUTE_NAME',['STRING1','STRING2', . . . ,'STRINGn'])

指定の属性に対して指定された文字列をすべて含むレコードがリコンサイルされます。

例: containsAllValues('objectClass',['person','top'])

この例では、「top」と「person」の両方を含むobjectClassのすべてのレコードがリコンサイルされます。

等価フィルタと非等価フィルタ

equalTo('ATTRIBUTE_NAME','VALUE')

構文に指定された値と等しい属性値のあるレコードがリコンサイルされます。

例: equalTo('sAMAccountName','Sales Organization')

この例では、sAMAccountNameが販売組織であるすべてのレコードがリコンサイルされます。

greaterThan('ATTRIBUTE_NAME','VALUE')

構文に指定された値よりも(辞書順または番号順で)大きい属性値(文字列または数字)のあるレコードがリコンサイルされます。

例1: greaterThan('cn','bob')

この例では、共通名「bob」よりも辞書順(つまりアルファベット順)で後に共通名があるすべてのレコードがリコンサイルされます。

例2: greaterThan('employeeNumber','1000')

この例では、従業委員番号が1000番以降のすべてのレコードがリコンサイルされます。

greaterThanOrEqualTo('ATTRIBUTE_NAME','VALUE')

構文で指定された値よりも辞書順または番号順で上回るまたは等しい属性値(文字列または数字)のあるレコードがリコンサイルされます。

例1: greaterThanOrEqualTo('sAMAccountName','S')

この例では、sAMAccountNameが辞書順で「S」と等しいまたは「S」以降であるすべてのレコードがリコンサイルされます。

例2: greaterThanOrEqualTo('employeeNumber','1000')

この例では、従業員番号が1000番以降のすべてのレコードがリコンサイルされます。

lessThan('ATTRIBUTE_NAME','VALUE')

構文で指定された値よりも(辞書順または番号順で)小さい属性値(文字列または数値)のあるレコードがリコンサイルされます。

例1: lessThan('sn','Smith')

この例では、辞書順(つまりアルファベット順)で姓「Smith」より前に姓があるすべてのレコードがリコンサイルされます。

例2: lessThan('employeeNumber','1000')

この例では、従業員番号が1000番未満のすべてのレコードがリコンサイルされます。

lessThanOrEqualTo('ATTRIBUTE_NAME','VALUE')

構文に指定された値よりも辞書順または番号順で下回るまたは等しい属性値(文字列または数字)があるレコードがリコンサイルされます。

例1: lessThanOrEqualTo('sAMAccountName','A')

この例では、sAMAccountNameが辞書順で「A」と等しいまたは「A」よりも若いすべてのレコードがリコンサイルされます。

例2: lessThanOrEqualTo('employeeNumber','1000')

この例では、従業員番号が1000番以下のすべてのレコードがリコンサイルされます。

複合フィルタ

<FILTER1> & <FILTER2>

FILTER1とFILTER2の条件をどちらも満たすレコードがリコンサイルされます。この構文では、2つのフィルタの結合に論理演算子&(アンパサンド記号)が使用されます。

例: startsWith('cn', 'John') & endsWith('sn', 'Doe')

この例では、共通名が「John」で始まり、姓が「Doe」で終わるすべてのレコードがリコンサイルされます。

<FILTER1> | <FILTER2>

FILTER1またはFILTER2の条件のどちらかを満たすレコードがリコンサイルされます。この構文では、2つのフィルタの結合に論理演算子 | (縦線)が使用されます。

例: contains('sAMAccountName', 'Andy') | contains('sn', 'Brown')

この例では、sAMAccountName属性に「Andy」を含むすべてのレコードまたは姓に「Brown」を含むすべてのレコードがリコンサイルされます。

not(<FILTER>)

指定のフィルタ条件を満たさないレコードがリコンサイルされます。

例: not(contains('cn', 'Mark'))

この例では、共通名「Mark」を含まないすべてのレコードがリコンサイルされます。

13 ICF統合のJava APIの使用

カスタム・コネクタを構築するには、まず、ICF SPIを実装することで、アイデンティティ・コネクタ(ICFベースのコネクタ)を実装する必要があります。この後、OIMアーティファクトを作成して、アイデンティティ・コネクタをOracle Identity Managerに統合し、アダプタ・タスクでICProvisioningManager (ICF統合の一部)を再利用して、アイデンティティ・コネクタでプロビジョニング操作を呼び出し、ICF統合で実装されるリコンシリエーション・タスクを再利用することもできます。したがって、ICF統合を使用すると、Javaで統合コードを記述する必要がなく、ICF統合ではICF APIを使用して、アイデンティティ・コネクタにアクセスします。

ICF統合に関するAPIの詳細は、Oracle Fusion Middleware Java APIリファレンス(Identity Connector Framework用)を参照してください。

Oracle Identity Managerに関するAPIの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

14 ICFコネクタの構成

この章では、すべてのICFコネクタに実行する必要のある一般的なカスタマイズ手順について説明します。

この章の内容は、次のとおりです。

- 第14.1項「コネクタ・ロード・バランサの構成」

- 第14.2項「リコンシリエーションおよびプロビジョニング中のデータ検証の構成」

- 第14.3項「ユーザー・リコンシリエーション中のデータ変換の構成」

- 第14.4項「リソース除外リストの構成」

- 第14.5項「コネクタ・サーバーおよびOIMのSSLの設定」

- 第14.6項「ターゲット・システム属性の追加」

14.1 コネクタ・ロード・バランサの構成

コネクタ・サーバーは、アイデンティティ・コネクタのリモート実行を可能にするアプリケーションです。コネクタ・サーバーが複数ある場合、アイデンティティ・コネクタのリモート実行およびフェイルオーバー管理用にコネクタ・サーバーの高可用性を確保する必要があります。したがって、Oracle Identity Managerには、コネクタ・サーバー用のロード・バランサがあります。図14-1にコネクタ・サーバーのクラスタの一般的な構成を示します。図のフローは、必須のコネクタ・バンドルがすべてのコネクタ・サーバー間にデプロイされているという仮定に基づいています。

図14-1 コネクタ・サーバーのロード・バランサ

コネクタ・サーバーのロード・バランサを構成するには:

関連項目:

これらの構成の詳細は、コネクタのドキュメントのコネクタ・サーバーのインストールおよび構成に関する説明、コネクタ・サーバーへのITリソースの構成に関する説明を参照してください。

1. コネクタ・バンドルが含まれているノードにコネクタ・サーバーをインストールします。これには、すべてのノードのサーバー・バイナリのコピーおよび実行が含まれています。

2. 手順1で作成したノード全体で、ポート8759 (コネクタ・サーバーのデフォルトで構成可能)のすべてのリクエストがロード・バランシングされるようにロード・バランサを設定します。

3. コネクタ・サーバーのITリソースを作成して、ロード・バランサでデプロイされたホストに指定します。

4. 次の詳細を使用して、コネクタITリソースを構成します。

- ホスト: ターゲット・アドレス

- コネクタ・サーバー名: 手順3で作成した名前を使用します。

注意:

ダブルクリックして、ロード・バランサの受信ポートがコネクタ・サーバーのITリソースの受信ポートと同じであることを確認する必要があります。また、クラスタ・ノードに設定されたポートがロード・バランサの構成に使用されたポートと一致することも確認する必要があります。

14.2 リコンシリエーションおよびプロビジョニング中のデータ検証の構成

Lookup.CONNECTOR_NAME.ProvValidationsおよびLookup.CONNECTOR_NAME.UM.ReconValidations参照定義は、プロビジョニングおよびリコンシリエーション操作中に検証される単一値データを保持します。

たとえば、「名」属性からフェッチしたデータを検証して、そのデータに番号記号(#)が含まれていないことを確認します。また、プロセス・フォームの「名」フィールドに入力したデータを検証して、プロビジョニング操作中にターゲット・システムに番号記号(#)が送信されないようにします。

注意:

Lookup.CONNECTOR_NAME.UM.ProvValidationsおよびLookup.CONNECTOR_NAME.UM.ReconValidations参照定義はオプションで、デフォルトでは存在しません。

これらの参照をデコード値としてLookup.CONNECTOR_NAME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。ユーザー操作への参照定義の設定の詳細は、それぞれのコネクタ・ガイドを参照してください。

データの検証を構成するには:

1. org.identityconnectors.CONNECTOR_NAME.extension.CONNECTOR_NAMEValidatorなどの完全修飾ドメイン名(FQDN)を持つJavaクラスで必須の検証ロジックを実装するコードを記述します。
この検証クラスには、検証メソッドを実装する必要があります。次のサンプル検証クラスは、「名」属性の値に番号記号(#)が含まれるかどうかを確認します。

package com.validationexample;

import java.util.HashMap;

public class MyValidator {
public boolean validate(HashMap hmUserDetails, HashMap hmEntitlementDetails, String sField) throws ConnectorException {

/* You must write code to validate attributes. Parent
* data values can be fetched by using hmUserDetails.get(field)
* For child data values, loop through the
* ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
* Depending on the outcome of the validation operation,
* the code must return true or false.
*/
/*
* In this sample code, the value "false" is returned if the field
* contains the number sign (#). Otherwise, the value "true" is
* returned.
*/
boolean valid = true;
String sFirstName = (String) hmUserDetails.get(sField);
for (int i = 0; i < sFirstName.length(); i++) {
if (sFirstName.charAt(i) == '#') {
valid = false;
break;
}
}
return valid;

}
}

2. Design Consoleにログインします。

3. 次のいずれかの新しい参照定義を作成します。

- リコンシリエーション用のデータの検証を構成するには:
Lookup.CONNECTOR_NAME.UM.ReconValidations

- プロビジョニング用のデータの検証を構成するには:
Lookup.CONNECTOR_NAME.UM.ProvValidations

4. コード・キー列で、検証するリソース・オブジェクト・フィールド名を入力します。たとえば、Aliasです。

5. デコード列で、クラス名を入力します。たとえば、org.identityconnectors.CONNECTOR_NAME.extension.CONNECTOR_NAMEValidatorです。

6. 参照定義に変更を保存します。

7. Lookup.CONNECTOR_NAME.UM.Configuration参照定義を検索して、開きます。

8. コード・キー列で、次のエントリのいずれかを入力します。

- リコンシリエーション用のデータの検証を構成するには:
リコンシリエーション検証参照

- プロビジョニング用のデータの検証を構成するには:
プロビジョニング検証参照

9. デコード列で、次のエントリのいずれかを入力します。

- リコンシリエーション用のデータの検証を構成するには:
Lookup.CONNECTOR_NAME.UM.ReconValidations

- プロビジョニング用のデータの検証を構成するには:
Lookup.CONNECTOR_NAME.UM.ProvValidations

10. 参照定義に変更を保存します。

11. クラスを使用してJARを作成し、次のようにOracle Identity Managerデータベースにアップロードします。
Oracle Identity Manager JARアップロード・ユーティリティを実行して、手順7で作成したJARファイルをOracle Identity Managerデータベースに投稿します。このユーティリティは、Oracle Identity Managerのインストール時に次の場所にコピーされます。

注意:

このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。

Microsoft Windowsの場合:

OIM_HOME/server/bin/UploadJars.bat

UNIXの場合:

OIM_HOME/server/bin/UploadJars.sh

ユーティリティを実行すると、Oracle Identity Manager管理者のログイン資格証明、Oracle Identity Managerホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプおよびJARファイルがアップロードされる場所の入力を求めるプロンプトが表示されます。JARタイプの値として1を選択します。

関連項目:

JARアップロード・ユーティリティの詳細は、「JARおよびリソース・バンドルの移行」を参照してください。

12. PurgeCacheユーティリティを実行して、サーバー・キャッシュからのデータセットのリクエストに関連するコンテンツをクリアします。

13. リコンシリエーションまたはプロビジョニングを実行して、Aliasなどのフィールドの検証を確認します。

14.3 ユーザー・リコンシリエーション中のデータ変換の構成

Lookup.CONNECTOR_NAME.UM.ReconTransformations参照定義は、リコンシリエーション操作中に変換される単一値のユーザー・データを保持します。たとえば、「名」および「姓」値を使用して、Oracle Identity Managerの「氏名」フィールドの値を作成できます。

注意:

Lookup.CONNECTOR_NAME.UM.ReconTransformations参照定義は、オプションでデフォルトでは存在しません。

この参照をデコード値としてLookup.CONNECTOR_NAME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。ユーザー操作への参照定義の設定の詳細は、それぞれのコネクタ・ガイドを参照してください。

リコンシリエーション中にフェッチした単一値のユーザー・データの変換を構成するには:

1. org.identityconnectors.CONNECTOR_NAME.extension.CONNECTOR_NAMETransformationなどの完全修飾ドメイン名(FQDN)を持つJavaクラスで必須の変換ロジックを実装するコードを記述します。
この変換クラスは、変換メソッドを実装する必要があります。次のサンプル変換クラスは、ターゲット・システムの「名」および「姓」属性からフェッチした値を使用して、「氏名」属性の値を作成します。

package com.transformationexample;

import java.util.HashMap;

public class MyTransformer {
public Object transform(HashMap hmUserDetails, HashMap hmEntitlementDetails, String sField) throws ConnectorException {
/*
* You must write code to transform the attributes.
* Parent data attribute values can be fetched by
* using hmUserDetails.get("Field Name").
* To fetch child data values, loop through the
* ArrayList/Vector fetched by hmEntitlementDetails.get("Child          Table")
* Return the transformed attribute.
*/
String sFirstName = (String) hmUserDetails.get("First Name");
String sLastName = (String) hmUserDetails.get("Last Name");
return sFirstName + "." + sLastName;

}
}

2. Design Consoleにログインします。

3. 新しい参照定義Lookup.CONNECTOR_NAME.UM.ReconTransformationsを作成します。

4. コード・キー列に、変換するリソース・オブジェクト・フィールド名を入力します。たとえば、Aliasです。

5. デコード列で、クラス名を入力します。たとえば、org.identityconnectors.CONNECTOR_NAME.extension.CONNECTOR_NAMETransformationです。

6. 参照定義に変更を保存します。

7. Lookup.CONNECTOR_NAME.UM.Configuration参照定義を検索して、開きます。

8. コード・キー列に、リコンシリエーション変換参照を入力します。

9. デコード列に、Lookup.CONNECTOR_NAME.UM.ReconTransformationsを入力します。

10. 参照定義に変更を保存します。

11. クラスを使用してJARを作成し、次のようにOracle Identity Managerデータベースにアップロードします。
Oracle Identity Manager JARアップロード・ユーティリティを実行して、手順7で作成したJARファイルをOracle Identity Managerデータベースに投稿します。このユーティリティは、Oracle Identity Managerのインストール時に次の場所にコピーされます。

注意:

このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。

Microsoft Windowsの場合:

OIM_HOME/server/bin/UploadJars.bat

UNIXの場合:

OIM_HOME/server/bin/UploadJars.sh

ユーティリティを実行すると、Oracle Identity Manager管理者のログイン資格証明、Oracle Identity Managerホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプおよびJARファイルがアップロードされる場所の入力を求めるプロンプトが表示されます。JARタイプの値として1を選択します。

関連項目:

このユーティリティの詳細は、「JARおよびリソース・バンドルの移行」を参照してください。

12. PurgeCacheユーティリティを実行して、サーバー・キャッシュからのデータセットのリクエストに関連するコンテンツをクリアします。

13. リコンシリエーションを実行して、Aliasなどのフィールドの変換を検証します。

14.4 リソース除外リストの構成

Lookup.CONNECTOR_NAME.UM.ProvExclusionListおよびLookup.CONNECTOR_NAME.UM.ReconExclusionList参照定義は、プロビジョニングおよびリコンシリエーション操作を実行しないターゲット・システム・アカウントのユーザーIDを保持します。

注意:

Lookup.CONNECTOR_NAME.UM.ProvExclusionListおよびLookup.CONNECTOR_NAME.UM.ReconExclusionList参照定義はオプションで、デフォルトでは存在しません。

これらの参照をデコード値としてLookup.CONNECTOR_NAME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。ユーザー操作への参照定義の設定の詳細は、それぞれのコネクタ・ガイドを参照してください。

これらの参照に格納されている値の形式は次のとおりです。

コード・キー

デコード

サンプル値

ユーザー・ログインIDリソース・オブジェクト・フィールド名

ユーザーのユーザーID

コード・キー: ユーザー・ログインID

デコード: User001

[PATTERN]接尾辞を持つユーザー・ログインIDリソース・オブジェクト・フィールド名

java.util.regex.Patternクラスの表現によってサポートされる正規表現

コード・キー: ユーザー・ログインID[PATTERN]

ユーザーID User001、User002、User088のいずれかに一致するユーザーを除外するには:

デコード: User001|User002|User088

ユーザーIDが00012で始まるユーザーを除外するには:

デコード: 00012*

関連項目: サポートされるパターンの詳細は、http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.htmlを参照してください。

プロビジョニング操作中に除外する参照にエントリを追加するには:

1. Design Consoleで、「管理」を開き、「参照定義」をダブルクリックします。

2. 新しい参照定義Lookup.CONNECTOR_NAME.UM.ProvExclusionListを作成します。

注意:

リコンシリエーション操作中に除外するユーザーIDを指定するには、Lookup.CONNECTOR_NAME.UM.ReconExclusionListという新しい参照定義を作成して、その参照にエントリを追加します。

3. 「追加」をクリックします。

4. コード・キーおよびデコード列に、除外する1つ目のユーザーIDを入力します。

注意:

コード・キーはプロビジョニング操作中に適用される除外リストのリソース・オブジェクト・フィールド名を表します。

5. 除外する残りのユーザーIDに手順3および4を繰り返します。
たとえば、ユーザーIDがUser001、User002およびUser088のユーザーをプロビジョニングしない場合、参照定義に次の値を移入します。

コード・キー

デコード

ユーザー・ログインID

User001

ユーザー・ログインID

User002

ユーザー・ログインID

User088

また、パターン一致を実行して、ユーザー・アカウントを除外することもできます。java.util.regex.Patternクラスの表現によってサポートされる正規表現を指定できます。

関連項目:

サポートされるパターンの詳細は、http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.htmlを参照してください。

たとえば、ユーザーIDがUser001、User002およびUser088に一致するユーザーをプロビジョニングしない場合、参照定義に次の値を移入します。

コード・キー

デコード

ユーザー・ログインID[PATTERN]

User001|User002|User088

ユーザーIDが00012から始まるユーザーをプロビジョニングしない場合は、次の値で参照定義を移入します。

コード・キー

デコード

ユーザー・ログインID[PATTERN]

00012*

6. 「保存」をクリックします。

14.5 コネクタ・サーバーおよびOIMのSSLの設定

コネクタ・サーバーおよびOracle Identity Manager間でのSSL通信を設定するには:

1. 新しいSSLキーを生成します(または、既存のキーを再利用することもできます):

keytool -genkey -alias keyconnserv -keyalg dsa -keystore <yourKeyStore.jks> -storepass <yourPassword> -validity 360

2. 新しく生成した公開鍵をエクスポートします。

keytool -export -keystore <yourKeyStore.jks> -storepass <yourPassword> -alias keyconnserv -file icfkey-public.cer

3. SSLにコネクタ・サーバーを構成して、手順1で設定した新しいキーストアを使用して開始します。

4. 手順2で生成した公開鍵(icfkey-public.cer)をOIMキーストアにインポートします。

5. ホスト、ポートなどのITリソースを構成します。これらのパラメータは、コネクタ・サーバー(ITリソースの追加フィールド)に渡されます。

6. SSLを使用してコネクタ・サーバーを構成します:

1. コネクタ・サーバーのシステムにSSL証明書をデプロイします。

2. SSLソケットを提供するようにコネクタ・サーバーを構成します。

3. SSLを使用してコネクタ・サーバーと通信するようにアプリケーションを構成します。
アイデンティティ・コネクタ・サーバーとの接続構成に固有の注意事項は、ターゲット・システムのマニュアルを参照してください。各SSL対応コネクタ・サーバーとの接続を確立するときにはSSL接続が必要になることをアプリケーションに指示します。さらに、コネクタ・サーバーで使用されるSSL証明書のいずれかが非標準認証局によって発行される場合は、追加の認証局を考慮するようにアプリケーションを構成する必要があります。認証局に関する注意事項は、該当するマニュアルを参照してください。

注意:

Javaアプリケーションにおいて非標準認証局に関する問題を解決するには、アプリケーションの起動時に次のJavaシステム・プロパティが渡されるようにします。

- javax.net.ssl.trustStorePassword
例:

-Djavax.net.ssl.trustStorePassword=changeit

- javax.net.ssl.trustStore
例:

-Djavax.net.ssl.trustStore=/usr/myApp_cacerts

また、非標準認証局を標準の${JAVA_HOME}/lib/security/cacertsディレクトリにインポートすることもできます。

7. 手順2で生成した公開鍵をOIMキーストアにインポートします。
デフォルトのWeblogicキーストアの選択を継続する場合、次を実行します。

keytool -import -trustcacerts -alias icfkey -file icfkey-public.cer -keystore <pathToYouKeystore>

デフォルトのWeblogicキーストアの例は、server/lib/DemoTrust.jks and server/lib/DemoIdentity.jksです。

14.5.1 SSLのトラブルシューティング

コネクタ・サーバー・ログの例外の例を次に示します。

java.net.SocketException: Default SSL context init failed: null

これは、キーストアへのパスが不正であることを意味します。この例外を処理するには、次のフル/絶対パスを指定します。

UNIXの場合

./connectorserver.sh /run "-J-Djavax.net.ssl.keyStore=/path/to/mykeystore.jks" "-J-Djavax.net.ssl.keyStorePassword=changeit"

Windowsの場合

./connectorserver.sh /run "-J-Djavax.net.ssl.keyStore=C:\path\to\mykeystore.jks" "-J-Djavax.net.ssl.keyStorePassword=changeit"

また、次のチェック・ポイントを確認する必要があります。

- SSLを使用するコネクタ・サーバー構成の設定の構成フォルダを確認します。

- 公開鍵がOIMキーストアに存在する場合、コネクタ・サーバーから公開鍵をインポートした後、WLSを再起動します。

14.6 ターゲット・システム属性の追加

ターゲット・システム属性の追加の内容は、次のとおりです。

- 第14.6.1項「プロビジョニングに関するターゲット・システム属性の追加」

- 第14.6.2項「ターゲット・リコンシリエーションに関するターゲット・システム属性の追加」

- 第14.6.3項「信頼できるリコンシリエーションに関するターゲット・システム属性の追加」

注意:

データ型フィールドに属性を追加する場合、参照定義コード・キーに[Date]接尾辞を追加してください。

たとえば、_LAST_PASSWORD_CHANGE_DATE_を追加した場合、Lookup.CONNECTOR_NAME.UM.ReconAttrMapまたはLookup.CONNECTOR_NAME.UM.ProvAttrMapのコード・キーに変更を行う際に、次のように属性を指定します。

_LAST_PASSWORD_CHANGE_DATE_[Date]

14.6.1 プロビジョニングに関するターゲット・システム属性の追加

デフォルトでは、ターゲット・システム属性が、Oracle Identity Managerとターゲット・システム間のプロビジョニング用にマップされます。必要に応じて、次の手順を実行して、追加属性をプロビジョニング用にマップできます。

注意:

この項では、属性という用語はユーザー・データを格納するIDデータ・フィールドを指します。

プロビジョニング用にターゲット・システム属性を追加するには、次の手順に従います。

1. 新しいフォーム・フィールドを追加します。プロセス・フォームに新しいフィールドを追加するには:

1. 「フォーム・デザイナ」フォームを開きます。このフォームは、Oracle Identity Manager Design Consoleの「Development Tools」フォルダ内にあります。

2. UD_CONNECTOR_NAMECONフォームを問い合せます。

3. 「新しいバージョンの作成」をクリックします。「Create a New Version」ダイアログ・ボックスが表示されます。

4. 「ラベル」フィールドで、バージョンの名前を入力します。

5. 「Save」をクリックして、ダイアログ・ボックスを閉じます。

6. 「現行バージョン」ボックスから、手順4の「ラベル」フィールドに入力したバージョン名を選択します。

7. 「Additional Columns」タブで、「Add」をクリックします。

8. 新しいフィールド名とその他の値を指定します。

9. 「保存」をクリックします。

10. 「バージョンをアクティブにする」をクリックして、新しいフォーム・フィールドをユーザーに表示します。
Oracle Identity Managerに移動して、コネクタに新しいユーザーをプロビジョニングする場合、新しいフォーム・フィールドを表示する必要があります。次に、プロビジョニング・マッピング参照に新しいフォーム・フィールドを追加する必要があります。

2. プロビジョニング・マッピング参照に新しいフィールドを追加します。新しいフォーム・フィールドの作成後、次のように、そのフィールドをプロビジョニング・マッピング参照に追加する必要があります。

1. 「Administration」を開き、「Lookup Definition」をダブルクリックします。

2. 「参照定義」ウィンドウで、CONNECTOR_NAMEを検索します。
Design Consoleは、Lookup.CONNECTOR_NAME.UM.ProvAttrMapを返します。

3. 参照定義表タブを選択して、Lookup.CONNECTOR_NAME.UM.ProvAttrMapを選択します。
参照コード情報タブは、Oracle Identity Managerのフォーム・フィールド名およびCONNECTOR_NAMEアイデンティティ・コネクタ属性をマップします。コード・キー列には、Oracle Identity Managerフィールド・ラベルが含まれており、デコード列には、CONNECTOR_NAMEアイデンティティ・コネクタによってサポートされる属性名が含まれています。

4. 新しいフォーム・フィールドに新しいレコードを追加します。コード・キー列に新しいフォーム・フィールド名を入力し、デコード列にCONNECTOR_NAMEアイデンティティ・コネクタ属性名を入力します。

5. 「保存」をクリックします。
新しいCONNECTOR_NAMEユーザーを作成する場合、作成操作の一部として、コネクタは新しい属性を取得します。

この時点では、プロセス・タスクでは作成のみを処理します。次に、プロセス・タスクを変更して、更新も処理できるようにする必要があります。手順は次のとおりです。

3. 次のように、プロセス・タスクを変更して、更新を処理するようにします。

1. Design Consoleで、「プロセス管理」を展開してから、「プロセス定義」をダブルクリックします。

2. プロセスCONNECTOR_NAME Userを検索および選択します。

3. 「タスク」列で、そのエントリを追加および選択する更新タスクと同様な更新タスクを検索します。

4. 「追加」をクリックします。

5. 新しいタスクの作成ダイアログで、「一般」タブを選択して「タスク名」および「タスクの説明」を入力します。
「タスク名」はフォーム名フィールドとなるため重要です。タスクで処理するイベントが含まれていることを確認します。たとえば、プロビジョニングにBuildingフィールドを追加する場合は、Building Updatedタスクを追加します。この更新イベントは、Buildingフィールドが更新される際にトリガーされます。

6. 「タスク・プロパティ」セクションで、次に示されているようにプロパティを設定します。
-条件付き: 有効

-完了に必須: 無効

-手動挿入不可: 無効

-保留中の取消しを許可: 有効

-複数のインスタンスを許可: 有効

残りのプロパティを変更する必要はありません。

7. 変更を保存します。

8. 「イベント・ハンドラ」を追加するには、統合タブを選択してから、「追加」をクリックします。

9. ハンドラの選択ダイアログ・ボックスが表示されてから、ハンドラ・タイプとしてアダプタを選択して、次の手順を実行します。
アダプタadpCONNECTOR_NAMECONNECTORUPDATEATTRIBUTEVALUEを選択して、「保存」をクリックします。

イベント・アダプタに構成されているすべての変数をマップします。

「アダプタ変数」セクションで、変数名をダブルクリックして、変数のデータ・マッピングの編集ダイアログ・ボックスを開きます。変数ごとに次の値を順番に指定します。マッピング後には、必ず変更を保存してください。

変数名

マップ先

修飾子

リテラル値

itResourceFieldName

リテラル

String

UD_CONNECTOR_NAMECON_SERVER

processInstanceKey

プロセス・データ

プロセス・インスタンス

アダプタの戻り値

レスポンス・コード

objectType

リテラル

String

ユーザー

attrName

リテラル

String

新しいラベルを入力します。

10. 新しいタスクの作成ダイアログを保存して閉じます。

11. 「プロセス定義」タブの「タスク」列を確認して、新しいプロセス・タスクがリストされていることを確認します。また、新しいフォーム・フィールドが使用可能で、Oracle Identity Managerで動作していることも確認します。

14.6.2 ターゲット・リコンシリエーションに関するターゲット・システム属性の追加

デフォルトでは、ターゲット・システム属性が、Oracle Identity Managerとターゲット・システム間のリコンシリエーション用にマップされます。必要に応じて、この項で説明されているように、追加属性をターゲット・リコンシリエーション用にマップできます。

注意:

- この手順は、リコンシリエーションに新しいターゲット・システム属性を追加する場合にのみ実行します。

- 次の手順では、BUILDINGという新しい属性が追加され、そのコネクタ属性名はBUILDINGで、フォーム・フィールド名はBuildingです。名前は、大文字と小文字が区別されます。

ターゲット・リコンシリエーション用にターゲット・システム属性を追加するには、次の手順に従います。

1. 次のようにして、リソース・オブジェクトの定義に、新しい属性に対応するリコンシリエーション・フィールドを追加します。

1. 「リソース・オブジェクト」フォームを開きます。このフォームは「Resource Management」フォルダにあります。

2. 「Query for Records」をクリックします。

3. 「リソース・オブジェクト表」タブで、CONNECTOR_NAME Userリソース・オブジェクトをクリックし、編集のために開きます。

4. 「Object Reconciliation」タブで、「ADD Field」をクリックして、「Add Reconciliation Field」ダイアログ・ボックスを開きます。

5. フィールド名の値、つまりフォームの新しい属性の名前を指定します。
例: Building

6. 「フィールド・タイプ」リストから、フィールドのデータ型を選択します。
例: String

7. 入力した値を保存し、ダイアログ・ボックスを閉じます。

8. 必要に応じて、手順dからgを繰り返してフィールドをさらにマップします。

9. リコンシリエーション・プロファイルの作成をクリックします。これにより、リソース・オブジェクトに行われた変更がMDSにコピーされます。

2. 対応するフィールドがプロセス・フォームに存在しない場合は、次のように、プロセス・フォームに新しい列を追加します。

1. 「フォーム・デザイナ」フォームを開きます。このフォームは「Development tools」フォルダにあります。

2. UD_CONNECTOR_NAMECONフォームを問い合せます。

3. 「新しいバージョンの作成」をクリックします。「Create a New Version」ダイアログ・ボックスが表示されます。

4. 「ラベル」フィールドで、バージョンの名前を入力します。

5. 「Save」をクリックして、ダイアログ・ボックスを閉じます。

6. 「現行バージョン」ボックスから、手順3の「ラベル」フィールドに入力したバージョン名を選択します。

7. 「Additional Columns」タブで、「Add」をクリックします。

8. 「名前」フィールドに、データ・フィールドの名前を入力してから、フィールドのその他の詳細を入力します。
注意: 属性をさらに追加する場合は、手順gおよびhを繰り返します。

9. 「保存」をクリックして、バージョンをアクティブにするをクリックします。

3. プロセス定義を修正して、新しく追加された属性と、対応するリコンシリエーション・フィールドとの間のマッピングを追加します。

1. 「プロセス定義」フォームを開きます。このフォームはDesign Consoleの「Process Management」フォルダにあります。

2. 「Query for Records」アイコンをクリックします。

3. プロセス定義表タブで、CONNECTOR_NAME Userプロセス定義をダブルクリックします。

4. 「Reconciliation Field Mappings」タブで、「Add Field Map」をクリックして、「Add Reconciliation Field Mapping」ダイアログ・ボックスを開きます。

5. 「フィールド名」リストから、手順2eで追加したリソース・オブジェクトの名前を選択します。

6. プロセス・データ・フィールドをダブルクリックし、「検索」ダイアログ・ボックスから対応するプロセス・フォーム・フィールドを選択します。次に、「OK」をクリックします。

7. 「Save」をクリックして、ダイアログ・ボックスを閉じます。

8. 必要に応じて、手順cからgを繰り返してフィールドをさらにマップします。

4. リコンシリエーション参照Lookup.CONNECTOR_NAME.UM.ReconAttrMapに移動して、次の値を使用して新しい属性に新しいレコードを追加します。

- コード・キー - リコンシリエーション・フィールドの名前

- デコード - CONNECTOR_NAME属性の名前

5. Design Consoleで、リソース・オブジェクトにリコンシリエーション・プロファイルを再生成します。

14.6.3 信頼できるリコンシリエーションに関するターゲット・システム属性の追加

デフォルトでは、信頼できるソース・リコンシリエーションの属性が、Oracle Identity Managerとターゲット・システム間にマップされます。必要に応じて、この項で説明されているように、追加属性を信頼できるリコンシリエーション用にマップできます。

注意:

- この手順は、リコンシリエーションに新しいターゲット・システム属性を追加する場合にのみ実行します。

- 次の手順では、BUILDINGという新しい属性が追加され、そのコネクタ属性名はBUILDINGで、フォーム・フィールド名はBuildingです。名前は、大文字と小文字が区別されます。

信頼できるリコンシリエーション用にターゲット・システム属性を追加するには、次の手順に従います。

1. 次のようにして、リソース・オブジェクトの定義に、新しい属性に対応するリコンシリエーション・フィールドを追加します。

1. 「リソース・オブジェクト」フォームを開きます。このフォームは「Resource Management」フォルダにあります。

2. 「Query for Records」をクリックします。

3. 「リソース・オブジェクト表」タブで、CONNECTOR_NAME Trusted Userリソース・オブジェクトをクリックし、編集のために開きます。

4. 「Object Reconciliation」タブで、「ADD Field」をクリックして、「Add Reconciliation Field」ダイアログ・ボックスを開きます。

5. フィールド名の値、つまりフォームの新しい属性の名前を指定します。
例: Building

6. 「フィールド・タイプ」リストから、フィールドのデータ型を選択します。
例: String

7. 入力した値を保存し、ダイアログ・ボックスを閉じます。

8. 必要に応じて、手順dからgを繰り返してフィールドをさらにマップします。

9. リコンシリエーション・プロファイルの作成をクリックします。これにより、リソース・オブジェクトに行われた変更がMDSにコピーされます。

2. 対応するフィールドがプロセス・フォームに存在しない場合は、次のように、プロセス・フォームに新しい列を追加します。

1. 「フォーム・デザイナ」フォームを開きます。このフォームは「Development tools」フォルダにあります。

2. UD_CONNECTOR_NAMECONフォームを問い合せます。

3. 「新しいバージョンの作成」をクリックします。「Create a New Version」ダイアログ・ボックスが表示されます。

4. 「ラベル」フィールドで、バージョンの名前を入力します。

5. 「Save」をクリックして、ダイアログ・ボックスを閉じます。

6. 「現行バージョン」ボックスから、手順3の「ラベル」フィールドに入力したバージョン名を選択します。

7. 「Additional Columns」タブで、「Add」をクリックします。

8. 「名前」フィールドに、データ・フィールドの名前を入力してから、フィールドのその他の詳細を入力します。
注意: 属性をさらに追加する場合は、手順gおよびhを繰り返します。

9. 「保存」をクリックし、「バージョンをアクティブにする」をクリックします。

3. プロセス定義を修正して、新しく追加された属性と、対応するリコンシリエーション・フィールドとの間のマッピングを追加します。

1. 「プロセス定義」フォームを開きます。このフォームはDesign Consoleの「Process Management」フォルダにあります。

2. 「Query for Records」アイコンをクリックします。

3. プロセス定義表タブで、CONNECTOR_NAME Trusted Userプロセス定義をダブルクリックします。

4. 「Reconciliation Field Mappings」タブで、「Add Field Map」をクリックして、「Add Reconciliation Field Mapping」ダイアログ・ボックスを開きます。

5. 「フィールド名」リストから、手順2eで追加したリソース・オブジェクトの名前を選択します。

6. プロセス・データ・フィールドをダブルクリックし、「検索」ダイアログ・ボックスから対応するプロセス・フォーム・フィールドを選択します。次に、「OK」をクリックします。

7. 「Save」をクリックして、ダイアログ・ボックスを閉じます。

8. 必要に応じて、手順cからgを繰り返してフィールドをさらにマップします。

4. リコンシリエーション参照Lookup.CONNECTOR_NAME.UM.ReconAttrMap.Trustedに移動して、次の値を使用して新しい属性に新しいレコードを追加します。

- コード・キー - リコンシリエーション・フィールドの名前

- デコード - CONNECTOR_NAME属性の名前

15 ICFのベスト・プラクティスおよびFAQの理解

この章には、ICFに関するベスト・プラクティスおよびよくある質問(FAQ)が登録されています。次の各項で、リストについて説明します。

- 第15.1項「ICFのベスト・プラクティス」

- 第15.2項「ICFのFAQ」

15.1 ICFのベスト・プラクティス

ICFの使用時に従う必要のあるベスト・プラクティスは次のとおりです。

- 共通のスケジュール済タスクおよびICProvisioningManagerを使用します。

- ITリソース・パラメータの数を最小限にし、ITリソースには、接続に関するパラメータのみを含め、残りはメイン・コネクタ構成参照に含めます。

- ICFコネクタへのログイン:
Oracle Identity ManagerのICF統合は、ICFコネクタ・インタフェースへのすべてのコールのすべての入出力パラメータを記録します。記録中は、必ず次のことを考慮してください。

- 必要に応じて、詳細ロギング・メッセージでロギングを拡張できます。

- パスワード情報または機密データを含むメッセージは記録しないでください。

- ConnectorExceptionエラーが発生した場合は、ターゲット固有の例外をラップして、追加の詳細を指定します。

- oracle.iam.connectors.icfcommon.のロギングをオンにすることで、ICF共通のロギングをオンにします。

- コネクタのロード・バランサ

- Oracle Identity Managerとコネクタ・サーバー間でSSL暗号化通信を使用する場合、すべてのコネクタ・サーバー・ノードのSSLキーストアをコピーして、SSLキーの変更時に一貫性を維持する必要があります。

- コネクタ・サーバーは、専用(非HTTP)のプロトコルおよびSSL暗号化を使用します。

- ロード・バランサの下のすべてのコネクタ・サーバー・ノードには、同じ一連のバンドルが含まれています。

15.2 ICFのFAQ

ICFに関するFAQは次のとおりです。

- 参照リコンシリエーションにチルダ(~)が含まれているのはなぜですか。
参照リコンシリエーションのチルダ(~)表記は、異なるITリソースの参照を区切るためのものです。次の例では、キーはプログラム的なキーで、値はわかりやすい表示名です。

Lookup Key: <IT Resource Key>~<Lookup key>

Lookup Value: <IT Resource Name>~<Lookup value>

- バルク属性更新とは何ですか、またどのように設定するのですか。
OIMのバルク属性更新とは、属性ごとに個別に更新する(デフォルトのオプション)かわりに、変更されたすべての属性を1つのメソッド・コールでコネクタに送信します。

コネクタでバルク属性更新を有効にするには、次のことを確認します。

- すべての属性に、個々の更新(通常はATTRIBUTE_NAME updated)に固有のプロセス・タスクがある。

- UD_FORM_NAME updatedという追加のプロセス・タスクがある。このタスクは、バルク更新に使用されます。

- 検索ベースのリコンシリエーションと同期ベースのリコンシリエーションは、どのような場合にどちらを使用するのですか。
コネクタ/ターゲット・リソースの機能に基づきます。ほとんどのコネクタでは検索をサポートし、一部のコネクタ(LDAP)では同期操作もサポートします。使用可能な場合は、同期ベースのリコンシリエーションの方が効率的であるため推奨されます。

同期ベースのリコンシリエーションは、1回の実行で追加/削除を処理できるため、検索ベースのリコンシリエーションより効率的です。検索ベースのリコンシリエーションでは、まず検索リコンシリエーションを実行してから検索削除リコンシリエーションを実行する必要があり、処理が2倍になります。

- コネクタ・プーリングはどのように構成するのですか。
コネクタ・プーリングおよびその構成の詳細は、リリース11.1.1.5.0バージョンのコネクタのドキュメントを参照してください。

- Groovyを使用して、コネクタの機能を拡張するにはどのようにするのですか。
拡張可能なコネクタを持つには、ScriptOnConnectorまたはScriptOnResource ICF SPIを実装する必要があります。コネクタによっては、ターゲット・リソースの機能に基づき、様々なスクリプト言語をサポートします。デフォルトでは、ICFはすべてのJavaベースのコネクタ用に、ScriptOnConnectorの使用によるgroovyスクリプトをサポートします。特定のコネクタのスクリプト言語を理解するには、常にコネクタのドキュメントを参照する必要があります。コネクタのカスタマイズ方法の詳細は、第14章「ICFコネクタの構成」を参照してください。

- コネクタ・サーバーの基本的な要件(メモリー、ディスク領域、CPUなど)は何ですか。
コネクタ・サーバーはJava 6以上のすべての環境で実行できます。要件は、JavaおよびOracle Identity Managerと同様です。

JDKおよびOracle Identity Managerのサポートされるバージョンの詳細は、リリース11.1.1.5.0バージョンのコネクタのドキュメントを参照してください。

- 1つのコネクタ・サーバーのバージョンですべてのICFコネクタのバージョンをサポートできますか。
コネクタ・サーバーのバージョンは、ICFのバージョンと同等です。ICFには、以前リリースされたコネクタのバージョンとの下位互換性があります。

- コネクタ・サーバーに関する問題をトラブルシューティングするにはどのようにするのですか。
コネクタ・サーバーのロギング構成ファイルでログ・レベルをFINESTに設定します。デフォルト・ポート8759を取得する場合、コネクタ・サーバー構成に異なるポート番号を設定します。

- コネクタをコネクタ・サーバーにデプロイするタイミングおよびコネクタをローカルでOracle Identity Managerにデプロイするタイミングはいつですか。
コネクタ・サーバーが必要となるのは.NETコネクタのみで、他のものは直接Oracle Identity Managerにデプロイできます。

16 汎用テクノロジ・コネクタの理解

この章では、汎用テクノロジ・コネクタと、汎用テクノロジ・コネクタを使用するためにOracle Identity Managerで提供される機能について説明します。

この章の内容は次のとおりです。

- 汎用テクノロジ・コネクタの必要性

- 汎用テクノロジ・コネクタの機能アーキテクチャ

- 汎用テクノロジ・コネクタの機能

- 汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト

- このマニュアルでの汎用テクノロジ・コネクタに関する情報のロードマップ

16.1 汎用テクノロジ・コネクタの必要性

Oracle Identity Managerの事前定義済コネクタは、Microsoft Active DirectoryおよびPeopleSoft Enterprise Applicationsなどの、一般的に使用されているターゲット・システムにあわせて設計されています。事前定義済コネクタはアダプタ・ファクトリ機能を使用して開発され、そのアーキテクチャは、ターゲット・システムがサポートしているAPI、またはターゲット・システムがユーザー・データを格納するデータ・リポジトリのタイプおよびスキーマのいずれかに基づきます。

事前定義済コネクタは、アダプタ・ファクトリを使用して開発されるため、高度なワークフローおよびアダプタのカスタマイズ機能を備えています。ターゲット・システムでこれらのコネクタが使用できる場合は、統合の方法として事前定義済コネクタの使用をお薦めします。

対応する事前定義済コネクタがないターゲット・システムとOracle Identity Managerを統合する場合があります。その例として、次のようなシナリオについて考えます。

シナリオ1: Acme Inc.のすべての従業員は、バックアップ・サーバーにディスク領域を割り当てられています。従業員は、バックアップ・サーバー上の従業員アカウントを管理するようにシステム管理者にリクエストを送信します。システム管理者は、従業員からのリクエストを取得、確認および処理するWebベース・アプリケーションを開発しています。このアプリケーションのフロント・エンドは、CSV形式のデータを受け取って格納するWebサービスです。バックエンドに格納される従業員アカウント・データは、XMLファイルとして指定の場所にエクスポートできます。

シナリオ2: Ceeam Travels Inc.では、顧客が航空運賃の見積りのリクエストに使用できるカスタムのWebベース・アプリケーションを所有しています。Ceeam Travelsの従業員でもあるエージェントは、これらのリクエストに対し、同じアプリケーションを使用して応答します。顧客は、自己登録によりこのアプリケーション内にアカウントを作成します。ただし、Ceeam Travelsの従業員は、人事管理上の役職に基づいて自動的にプロビジョニングされたアカウントを持っている必要があります。アプリケーションのアカウント管理機能(作成、更新および削除など)は、Java APIを介して使用可能です。

これらのいずれのシナリオでも、ターゲット・システムとOracle Identity Managerをリンクするためのカスタム・コネクタを作成する必要があります。カスタム・コネクタを作成する簡単な方法を模索しており、アダプタ・ファクトリのカスタマイズ機能は必要ないという場合には、コネクタの作成にOracle Identity Managerの汎用テクノロジ・コネクタ機能を使用できます。16.2項「汎用テクノロジ・コネクタの機能アーキテクチャ」で説明しているように、プロバイダは汎用テクノロジ・コネクタのビルディング・ブロックです。

- シナリオ1では、事前定義済の共有ドライブ・リコンシリエーション・トランスポート・プロバイダおよびCSVリコンシリエーション・フォーマット・プロバイダを使用することにより、フラット・ファイルとして格納されているデータをOracle Identity Managerに対してリコンサイルする汎用テクノロジ・コネクタを作成できます。

- シナリオ2では、カスタム・アプリケーションをOracle Identity Managerに統合する場合に使用できる事前定義済プロバイダはありません。この場合、第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」に記載の手順を使用して、ターゲット・アプリケーションにより公開されたJava APIをコールするカスタム・プロバイダを作成できます。

16.2 汎用テクノロジ・コネクタの機能アーキテクチャ

事前定義済コネクタと同様に、汎用テクノロジ・コネクタは、Oracle Identity Managerとターゲット・システムの間でリコンシリエーションおよびプロビジョニング操作を仲介する役割をはたします。機能的に、汎用テクノロジ・コネクタは、リコンシリエーション・モジュールとプロビジョニング・モジュールに分けられます。汎用テクノロジ・コネクタを作成する際には、リコンシリエーション・モジュールとプロビジョニング・モジュールをともに組み込むか、どちらか一方のみ組み込むかを指定できます。

事前定義済コネクタは、同一のターゲットのコンテキストでリコンシリエーション機能とプロビジョニング機能を備えています。それに対して、汎用テクノロジ・コネクタのリコンシリエーション・モジュールおよびプロビジョニング・モジュールは、選択した再使用可能コンポーネントで構成されます。それぞれのコンポーネントでは、プロビジョニング時またはリコンシリエーション時に、特定の機能が実行されます。たとえば、フラット・ファイルから信頼できるソース・リコンシリエーションを実行するとともに、SPMLプロトコルを使用したSPML対応ターゲットへのターゲット・リソース・プロビジョニングを実行するコネクタを作成できます。

このマニュアルでは、汎用テクノロジ・コネクタを構成するコンポーネントをプロバイダと呼びます。

各プロバイダは、入力として受け取るデータに対するトランスポート機能、フォーマット変更機能、検証機能または変換機能を実行します。つまり、プロバイダにより処理されたデータ項目は新しい場所に移動されるか、指定された基準に照らして検証されるか、構造または値の変更が行われます。このガイドでは、データセットという用語は、レイヤー形式で配置されたデータ構造を表すために使用されます。データは、プロビジョニングおよびリコンシリエーション中にレイヤー間を流れます。

汎用テクノロジ・コネクタを作成する場合、各データセットに含まれる必要があるフィールド(ユーザー・アイデンティティ・メタデータ)を指定できます。また、異なるデータセットのフィールド間にマッピングを定義することもできます。マッピングは、次のいずれかを目的としています。

- プロビジョニングまたはリコンシリエーションで使用するための、2つのデータセットのフィールド間のデータ・フロー・パスの確立。
このタイプのマッピングに基づいて、ターゲット・システムからフェッチされたデータの検証または変換が行われます。

- 2つのデータセットのフィールド値の比較(一致)の基盤の構築。

図16-1は、汎用テクノロジ・コネクタの機能アーキテクチャを示しています。

図16-1 汎用テクノロジ・コネクタの機能アーキテクチャ

次の各項では、汎用テクノロジ・コネクタを構成するプロバイダおよびデータセットについて説明します。

- リコンシリエーション・モジュールのプロバイダおよびデータセット

- プロビジョニング・モジュールのプロバイダおよびデータセット

- Oracle Identity Managerデータセット

16.2.1 リコンシリエーション・モジュールのプロバイダおよびデータセット

リコンシリエーション・モジュールは、次のプロバイダおよびデータセットで構成されています。

- リコンシリエーション・トランスポート・プロバイダ
リコンシリエーション・トランスポート・プロバイダでは、ターゲット・システムのリコンシリエーション・データがOracle Identity Managerへ伝播されます。このプロバイダがリコンシリエーション・データを伝播する方法は、プロバイダの実装によって異なります。たとえば、リコンシリエーション・トランスポート・プロバイダは、ファイルからのデータの読取り、Webサービスからのデータの受取り、またはデータベースへの問合せが可能です。

- リコンシリエーション・フォーマット・プロバイダ
リコンシリエーション・フォーマット・プロバイダでは、リコンシリエーション・トランスポート・プロバイダによりフェッチされたリコンシリエーション・データが解析され、このデータがOracle Identity Managerに格納できるデータ構造に変換されます。

- ソース
「ソース」データセットには、リコンシリエーション・フォーマット・プロバイダにより処理されたデータが保持されます。このデータセットは、子データセットを持つことが可能です。

- 検証プロバイダ
検証プロバイダでは、「ソース」データセット内のデータが指定した基準を満たしているかどうかが確認され、その後データがOracle Identity Managerのリコンシリエーション・エンジンに渡されます。

注意:

1つの汎用テクノロジ・コネクタには、複数の検証プロバイダを組み込むことができます。

- 変換プロバイダ
リコンシリエーション・モジュールに組み込まれている変換プロバイダでは、検証プロバイダから受け取ったデータが変更され、その後データがリコンシリエーション・イベントを作成するためにOracle Identity Managerへ渡されます。

変換プロバイダ機能の例を、次に説明します。

ターゲット・システムの2つのフィールドに、次のように値が設定されているとします。

名: John

姓: Doe

変換プロバイダを使用すると、次のようなリコンシリエーション・フィールドを出力できます。

ログインID: John.Doe

- リコンシリエーション・ステージング
「リコンシリエーション・ステージング」データセットには、検証プロバイダおよび変換プロバイダによって処理されたユーザー・データが保持されます。このデータセットは、子データセットを持つことが可能です。

16.2.2 プロビジョニング・モジュールのプロバイダおよびデータセット

プロビジョニング・モジュールは、次のプロバイダおよびデータセットで構成されています。

- 変換プロバイダ
変換プロバイダを使用すると、次の段階でデータ項目を変更できます。

- プロビジョニング・モジュールに組み込まれている変換プロバイダでは、Oracle Identity Managerプロセス・フォームに入力されたデータが変更され、その後データがターゲット・システムに送信されます。

- プロビジョニング・ステージング
「プロビジョニング・ステージング」データセットには、プロビジョニング・フォーマット・プロバイダに送信される前のユーザー・データが保持されます。このデータは、Oracle Identity Managerに格納されている、信頼できるソースのユーザー・データまたはターゲット・システムのアカウント・データに対して変換機能を実行した場合の出力です。このデータセットは、子データセットを持つことが可能です。

- プロビジョニング・フォーマット・プロバイダ
プロビジョニング・フォーマット・プロバイダでは、(変換プロバイダから受け取った)Oracle Identity Managerのプロビジョニング・データが、ターゲット・システムでサポートされているフォーマットに変換されます。

- プロビジョニング・トランスポート・プロバイダ
プロビジョニング・トランスポート・プロバイダでは、プロビジョニング・フォーマット・プロバイダからターゲット・システムへプロビジョニング・データが伝播されます。このプロバイダがリコンシリエーション・データを伝播する方法は、プロバイダの実装によって異なります。たとえば、プロバイダでは、ファイルへのデータのコピー、Webサービスへのデータの送信、またはデータベースへのデータのポストが可能です。

16.2.3 Oracle Identity Managerデータセット

Oracle Identity Managerデータセットは、Oracle Identity Managerに格納されているデータを表します。これらのデータセットはリコンシリエーション・モジュールまたはプロビジョニング・モジュールには含まれませんが、これらのデータセットにフィールドを追加して、これらのデータセットとその他のデータセットのフィールド間のマッピングを作成できるため、汎用テクノロジ・コネクタの一部と見なされます。Oracle Identity Managerデータセットを次に示します。

- OIM - ユーザー
「OIM - ユーザー」データセットには、Oracle Identity Managerユーザーを定義するメタデータ(アイデンティティ・フィールドのセット)が保持されます。信頼できるソース・リコンシリエーションの場合、このデータセットは、「リコンシリエーション・ステージング」データセットから、新規作成または変更されたユーザー・アカウント情報を受け取ります。ターゲット・リソース・リコンシリエーションの場合は、「OIM - ユーザー」データセットのフィールドを使用して、ターゲット・システムのユーザー・アカウントと既存のOracle Identity Managerユーザーを一致させることができます。このデータセットは、子データセットを持つことはできません。

- OIM - アカウント
「OIM - アカウント」データセットには、Oracle Identity Managerの「プロセス・フォーム」フィールドに格納されているユーザー・アカウント情報が保持されます。このユーザー・アカウント情報は、「リコンシリエーション・ステージング」データセットから受け取ります。「OIM - アカウント」データセットは、子データセットを持つことが可能です。

16.3 汎用テクノロジ・コネクタの機能

次の各項では、汎用テクノロジ・コネクタの機能について説明します。

- リコンシリエーション・モジュールに固有の機能

- その他の機能

16.3.1 リコンシリエーション・モジュールに固有の機能

次の機能は、リコンシリエーション・モジュールに固有のものです。

- 信頼できるソース・リコンシリエーション

- アカウント・ステータスのリコンシリエーション

- 完全リコンシリエーションおよび増分リコンシリエーション

- バッチ・リコンシリエーション

- 複数値属性データ(子データ)の削除のリコンシリエーション

- リコンシリエーション停止の失敗しきい値

16.3.1.1 信頼できるソースのリコンシリエーション

汎用テクノロジ・コネクタは、信頼できるソース・リコンシリエーションに使用できます。信頼できるモードでのリコンシリエーションでは、次が実行されます。

- リコンシリエーション・エンジンでは、新規のターゲット・システム・アカウントが検出されると、対応するOracle Identity Managerユーザーが作成されます。

- リコンシリエーション・エンジンでは、既存のターゲット・システム・アカウントに対する変更が検出されると、対応するOracle Identity Managerユーザーに同様の変更が行われます。

注意:

汎用テクノロジ・コネクタの作成時に「信頼できるソース・リコンシリエーション」オプションを選択しない場合は、ターゲット・リソース・リコンシリエーションが有効になります。ターゲット・リソース・リコンシリエーションでは、ターゲット・システム・アカウントに対する変更のみがリコンサイルされます。リコンシリエーション時に検出された新規のターゲット・システム・アカウントが、Oracle Identity Managerで自動的に作成されることはありません。

信頼できるソース・リコンシリエーションに使用する汎用テクノロジ・コネクタは、プロビジョニングには使用できません。このような設計機能が組み込まれているのは、信頼できるソースとして指定されたターゲット・システム上のユーザー・アカウント情報を、Oracle Identity Managerを介して作成または変更できないようにするためです。

ITリソースおよびリソース・オブジェクトなどのコネクタ・オブジェクトは、汎用テクノロジ・コネクタの作成プロセスの最後に自動的に作成されます。デフォルトでは、汎用テクノロジ・コネクタのリソース・オブジェクトは、信頼できるリソース・オブジェクトです。つまり、汎用テクノロジ・コネクタはあらかじめ、複数の信頼できるソースのリコンシリエーション機能と互換性があります。この機能については、第5章「プロビジョニング・プロセスの開発」を参照してください。

注意:

信頼できるソース・リコンシリエーションでは、複数値(子)データのリコンシリエーションはサポートされていません。

16.3.1.2 アカウント・ステータスのリコンシリエーション

ユーザー・アカウント・ステータス情報は、ターゲット・システム・アカウントの所有者によるアカウントへのアクセスおよびアカウントの使用が許可されるかどうかの追跡に使用されます。Oracle identity Managerに格納されている形式のアカウント・ステータス情報がターゲット・システムに格納されていない場合は、事前定義済の翻訳変換プロバイダを使用して、アカウント・ステータスのリコンシリエーションを実装できます。

注意:

ユーザー・アカウント・ステータスのリコンシリエーションは、信頼できるソース・リコンシリエーションを選択するかターゲット・リソース・リコンシリエーションを選択するかに関係なく実装できます。

Design Consoleには、翻訳変換プロバイダを使用せずにアカウント・ステータスのリコンシリエーションを実装するための機能が用意されています。詳細は、5.3.2.2項「リコンシリエーション・フィールド・マッピングタブ」を参照してください。

16.3.1.3 完全リコンシリエーションおよび増分リコンシリエーション

汎用テクノロジ・コネクタを作成する際に、コネクタを完全リコンシリエーションまたは増分リコンシリエーションに使用するよう指定できます。

最後のリコンシリエーション実行後に変更されたレコードをリコンシリエーション・エンジンで識別する方法がターゲット・システムでサポートされている場合は、増分リコンシリエーションを選択します。たとえば、ターゲット・システムでユーザー・レコードの作成または変更にタイムスタンプが付けられている場合、リコンシリエーション・エンジンでは、最後のリコンシリエーション実行後に追加または変更されたレコードを識別できます。増分リコンシリエーションでは、最後のリコンシリエーション実行後に変更されたターゲット・システムのレコードのみがOracle Identity Managerでリコンサイル(格納)されます。

次のいずれかの条件に該当する場合は、完全リコンシリエーションを選択します。

- 最後のリコンシリエーション実行後に変更されたレコードをリコンシリエーション・エンジンで識別する方法がターゲット・システムでサポートされていない場合。

- ターゲット・システムのすべてのユーザー・アカウント・レコードに初めてリコンシリエーションを実行する場合。

完全リコンシリエーションでは、すべてのリコンシリエーション・レコードがターゲット・システムから抽出されます。ただし、最適化リコンシリエーション機能により、Oracle Identity Managerですでにリコンサイル済のレコードが識別されて無視されます。これは、リコンシリエーション・データで占有される領域を削減するために役立ちます。この機能がない場合、Oracle Identity Managerデータベースに格納されるデータ容量は、リコンシリエーションを実行するたびに急速に増加することになります。

注意:

完全リコンシリエーションと増分リコンシリエーションの結果は同じです。

- 最初のリコンシリエーション実行時に、すべてのターゲット・システム・レコードがリコンサイルされます。

- 2回目のリコンシリエーション以降は、最後のリコンシリエーション実行後に作成または更新されたターゲット・システムのレコードが、Oracle Identity Managerによってリコンサイルされます。

16.3.1.4 バッチ・リコンシリエーション

リコンシリエーションのバッチ・サイズを指定できます。これにより、リコンシリエーション実行中にリコンシリエーション・エンジンがターゲット・システムからフェッチするレコードの総数をバッチに分割できます。この機能により、リコンシリエーション・プロセスをさらにきめ細かく制御できるようになります。

16.3.1.5 複数値属性データ(子データ)の削除のリコンシリエーション

ターゲット・システムの複数値属性データの削除をOracle Identity Managerでリコンサイルするかどうかを指定します。

注意:

汎用テクノロジ・コネクタでは、親データの削除のリコンシリエーションはサポートされていません。たとえば、ユーザーJohn Doeのアカウントがターゲット・システムから削除された場合、汎用テクノロジ・コネクタを使用してこのユーザー・アカウントの削除をOracle Identity Managerでリコンサイルすることはできません。

16.3.1.6 リコンシリエーション停止の失敗しきい値

リコンシリエーションの実行中、ターゲット・システム・データをOracle Identity Managerに格納する前に、検証プロバイダでデータのチェックを実行できます。失敗しきい値を設定しておくと、検証チェックに通らなかったレコードの処理済レコードの総数に対する割合が指定のしきい値を超えた場合に、リコンシリエーションの実行を自動的に停止できます。

16.3.2 その他の機能

次の機能は、リコンシリエーション・モジュールまたはプロビジョニング・モジュールに固有のものではありません。

- カスタム・データ・フィールドおよびフィールド・マッピング

- カスタム・プロバイダ

- 多言語サポート

- カスタム日付書式

- Oracle Identity Managerユーザー属性に対する変更のターゲット・システムへの伝播

16.3.2.1 カスタム・データ・フィールドおよびフィールド・マッピング

汎用テクノロジ・コネクタを作成する場合、リコンシリエーションおよびプロビジョニングの実行中に使用する必要があるアイデンティティ・フィールドおよびフィールド・マッピング(データ・フロー・パス)を指定できます。

16.3.2.2 カスタム・プロバイダ

Oracle Identity Managerに付属の事前定義済プロバイダが、動作環境のトランスポート、フォーマット変更、検証または変換についての要件に対応していない場合は、カスタム・プロバイダを作成できます。

16.3.2.3 多言語サポート

汎用テクノロジ・コネクタでは、ユーザー、アカウントまたはその他のタイプのプロビジョニング済リソース・オブジェクトを表す、ASCIIデータおよび非ASCIIデータ(マルチバイト・キャラクタ)の両方を処理できます。

16.3.2.4 カスタム日付書式

汎用テクノロジ・コネクタの作成時は、次のような書式を指定できます。

- リコンシリエーション実行中に抽出されたターゲット・システム・レコードの日付の値の書式

- プロビジョニング実行中にターゲット・システムへ送信する必要がある日付の値の書式

16.3.2.5 Oracle Identity Managerユーザー属性に対する変更のターゲット・システムへの伝播

汎用テクノロジ・コネクタの作成時、Oracle Identity Managerユーザー属性に対する変更が自動的にターゲット・システムへ伝播されるように設定できます。

16.4 汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト

汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクトのリストは、「ステップ1: 基本情報」ページで選択した「リコンシリエーション」オプションおよび「プロビジョニング」オプションの組合せによって異なります。

- 「リコンシリエーション」と「プロビジョニング」の両方の選択

- 「リコンシリエーション」のみの選択

- 「プロビジョニング」のみの選択

注意:

フォーム名を除き、汎用テクノロジ・コネクタ・オブジェクトの名前はGTC_NAME_GTCの形式になります。GTC_NAMEは、コネクタに割り当てた名前です。

たとえば、作成する汎用テクノロジ・コネクタの名前としてDBTables_connを指定すると、すべてのコネクタ・オブジェクト(フォーム以外)の名前はDBTables_conn_GTCとなります。

16.4.1 「リコンシリエーション」と「プロビジョニング」の両方の選択

「ステップ1: 基本情報」ページで「リコンシリエーション」オプションおよび「プロビジョニング」オプションの両方を選択した場合、次のオブジェクトが作成されます。

- ITリソース・タイプ
ITリソース・タイプのパラメータは、最初のページで選択した、リコンシリエーションとプロビジョニングの両方のフォーマット・プロバイダとトランスポート・プロバイダのランタイム・パラメータです。

- ITリソース
ITリソースは、ITリソース・タイプのインスタンスです。これには、プロバイダのランタイム・パラメータ値が格納されます。

- リソース・オブジェクト
リソース・オブジェクトは、「リコンシリエーション・ステージング」親データセットを構成するフィールドの値を保持します。各「リコンシリエーション・ステージング」子データセットでは、複数レベルのリコンシリエーション・フィールドが、(対応する子フィールドを属性として)自動的に作成されます。

注意:

「信頼できるソース・リコンシリエーション」オプションを選択した場合、信頼できるリソース・オブジェクトは、コネクタ作成プロセスの最後に自動的に作成されるオブジェクトの1つになります。

- アプリケーション・インスタンス
これは、ITリソース(ターゲット接続とコネクタ構成)と、リソース・オブジェクト(プロビジョニング・メカニズム)を組み合せたものです。これは、プロビジョニング可能なエンティティです。

- 親フォームと子フォーム
親フォームと子フォームは「OIM - アカウント」データセットおよびその子データセットにそれぞれ基づいています。デフォルトでは、フォームの名前は対応するデータセットの名前と同じです。「ステップ3: フォーム名の検証」ページで、必要に応じてフォーム名を変更できます。

- プロセス定義
プロセス定義には、リコンシリエーション・フィールド・マッピングと、システム定義およびプロビジョニング固有のプロセス・タスクが含まれます。プロセス定義に含まれるプロセス・タスクの詳細は、19.2.6項「プロビジョニングの構成」を参照してください。

- 汎用アダプタ
汎用アダプタには、汎用テクノロジ・コネクタが行うすべてのプロビジョニング機能に対するコードが含まれています。

- スケジュール済タスク
リコンシリエーションの実行中、スケジュール済タスクは事前定義済の順序でリコンシリエーション・プロセスをトリガーします。スケジュール済タスクの設定の詳細は、19.2.5項「リコンシリエーションの構成」を参照してください。

- リコンシリエーション・ルール
リコンシリエーション・ルールはルール要素で構成されています。単一ルール要素は、「リコンシリエーション・ステージング」データセットと「OIM - ユーザー」データセットのフィールド間で作成されたマッピングを表します。

- アクション・ルール
ターゲット・リソースのリコンシリエーションのために、次のデフォルトのアクション・ルールのいずれかが作成されます。

ルール条件

アクション

1つのエンティティ一致が見つかった場合

リンクの確立

1つのプロセス一致が見つかった場合

リンクの確立

信頼できるソースのリコンシリエーションのために、次のデフォルトのアクション・ルールのいずれかが作成されます。

ルール条件

アクション

一致が見つからなかった場合

ユーザーの作成

1つのエンティティ一致が見つかった場合

リンクの確立

1つのプロセス一致が見つかった場合

リンクの確立

汎用テクノロジ・コネクタの作成者が属するユーザー・グループは、汎用テクノロジ・コネクタの作成プロセス中に自動的に作成される次のコネクタ・オブジェクトの管理者となります。

- ITリソース

- リソース・オブジェクト(管理者およびオブジェクト認可者)

- すべてのフォーム

- プロセス定義

- リコンシリエーション・フィールド

- リコンシリエーション・フィールド・マッピング

16.4.2 「リコンシリエーション」のみの選択

「リコンシリエーション」オプションおよび「プロビジョニング」オプションの両方を選択した場合に作成されるオブジェクトのリストは、「「リコンシリエーション」と「プロビジョニング」の両方の選択」を参照してください。「ステップ1: 基本情報」ページで「リコンシリエーション」オプションのみを選択した場合、そのリストの中の次のオブジェクトは作成されません。

- 汎用アダプタ

- プロビジョニング固有のプロセス・タスク
ただし、プロセス定義自体とそれを構成するシステム定義プロセス・タスクは作成されます。

16.4.3 「プロビジョニング」のみの選択

「リコンシリエーション」オプションおよび「プロビジョニング」オプションの両方を選択した場合に作成されるオブジェクトのリストは、「「リコンシリエーション」と「プロビジョニング」の両方の選択」を参照してください。「ステップ1: 基本情報」ページで「プロビジョニング」オプションのみを選択した場合、そのリストの中の次のオブジェクトは作成されません。

- スケジュール済タスク

- リコンシリエーション・ルール

- リコンシリエーション・フィールド

- リコンシリエーション・フィールド・マッピング

16.5 このマニュアルでの汎用テクノロジ・コネクタに関する情報のロードマップ

汎用テクノロジ・コネクタに関するその他の章および付録の概要を次に示します。

- 第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」では、共有ドライブ・リコンシリエーション・トランスポート・プロバイダ、CSVリコンシリエーション・フォーマット・プロバイダ、SPMLプロビジョニング・フォーマット・プロバイダ、Webサービス・プロビジョニング・トランスポート・プロバイダ、変換プロバイダおよび検証プロバイダを含む、使用可能なプロバイダの詳細について説明します。

- 第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」では、プロビジョニングおよびリコンシリエーション中のプロバイダの役割およびカスタム・プロバイダの作成方法について説明します。

- 第19章「汎用テクノロジ・コネクタの作成および管理」では、汎用テクノロジ・コネクタの作成方法と管理方法およびカスタム・コネクタでの汎用接続プール・フレームワークの使用方法について説明します。

- 第20章「汎用テクノロジ・コネクタのトラブルシューティング」では、汎用テクノロジ・コネクタに関連する一般的な問題と構成上の問題およびそれらの問題のトラブルシューティング方法について説明します。

17 汎用テクノロジ・コネクタ用事前定義済プロバイダ

Oracle Identity Managerには、次の事前定義済プロバイダが含まれています。

関連項目:

Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイドの統合ソリューションに関する説明を参照してください。

注意:

使用するプロバイダ用のパラメータの値を決定する必要があります。この値は、Oracle Identity System Administrationを使用して汎用テクノロジ・コネクタを作成する間に使用します。

- 共有ドライブ・リコンシリエーション・トランスポート・プロバイダ

- CSVリコンシリエーション・フォーマット・プロバイダ

- SPMLプロビジョニング・フォーマット・プロバイダ

- Webサービス・プロビジョニング・トランスポート・プロバイダ

- 変換プロバイダ

- 検証プロバイダ

17.1 共有ドライブ・リコンシリエーション・トランスポート・プロバイダ

共有ドライブ・リコンシリエーション・トランスポート・プロバイダは、ステージング・ディレクトリに格納されたフラット・ファイルからデータを読み取り、そのファイルをアーカイブ・ディレクトリに移動します。ステージング・ディレクトリとアーカイブ・ディレクトリを共有して、Oracle Identity Managerサーバーからアクセスできるようにする必要があります。

このプロバイダのパラメータを次に示します。

- ステージング・ディレクトリ(親アイデンティティ・データ)
このパラメータを使用して、親データを含むファイルを格納するディレクトリのパスを指定します。このパラメータ値の指定は必須です。これはランタイム・パラメータです。

このマニュアルでは、親データとは、ターゲット・システムに格納されているユーザー・アカウント情報を意味します。

このパラメータのサンプル値は次のとおりです。

T:/TargetSystemDirectory/ParentData

注意:

Oracle Identity Managerがインストールされているサーバー上にステージング・ディレクトリがない場合、そのディレクトリを共有にして、Oracle Identity Managerサーバー上にネットワーク・ドライブとしてマップする必要があります。

親データファイルに格納されるデータは、次の規則に準拠する必要があります。

- ファイルの1行目
親データファイルの1行目は、ファイルの内容を示すファイル・ヘッダーである必要があります。

ファイル・ヘッダーの前に、番号記号(#)で始まる任意の数の行を置くことができます。この記号はファイルの読取り時には無視されます。ただし、ヘッダーの先頭に空白がないようにしてください。英語以外の言語を使用している場合、この行に非ASCII文字は入力できません。

注意:

1行目に非ASCII文字を入力しないようにするチェック機能はありません。また、汎用テクノロジ・コネクタ・フレームワークでは非ASCII文字を解析できます。ただし、非ASCII文字を使用すると、作成した汎用テクノロジ・コネクタのコネクタ・オブジェクトが自動的に作成される時点で問題が発生します。

- ファイルの2行目
親データファイルの2行目には、ファイル内のデータのフィールド名(メタデータ)を入力する必要があります。

注意:

汎用テクノロジ・コネクタのコンテキストでは、メタデータという用語はユーザー・アカウント情報を構成する一連のアイデンティティ・フィールドを意味します。

英語以外の言語を使用している場合、この行に非ASCII文字は入力できません。この制限事項の詳細は、1行目に関する「注意」を参照してください。

- ファイルの3行目以降
親データファイルの3行目以降には、Oracle Identity Managerに対して選択した言語でデータを入力できます。この言語としては、ASCIIキャラクタ・セットと非ASCIIキャラクタ・セットの両方を使用できます。この制限事項の詳細は、「多言語サポート」を参照してください。

3行目以降にデータがなくても、リコンシリエーションが実行され、ファイルがアーカイブされます。

次に、サンプル親データファイルの内容を示します。

##Active Directory user
Name TD,Address TD,User ID TD
John Doe,Park Street,jodoe
Jane Doe,Mark Street,jadoe

関連項目:

「ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限」

- ステージング・ディレクトリ(複数値アイデンティティ・データ)
このパラメータを使用して、複数値(または子)アカウントまたはアイデンティティ・データ(ロール・メンバーシップのデータなど)を含むファイルを格納するディレクトリのパスを指定します。このパラメータ値の指定は必須ではありません。これはランタイム・パラメータです。

注意:

このマニュアルでは、複数値アカウントまたはアイデンティティ・データと子データという用語は、同義的に使用されています。

このパラメータのサンプル値は次のとおりです。

T:/TargetSystemDirectory/ChildData

注意:

- 親データファイルのステージング・ディレクトリを複数値ユーザー・データファイルのステージング・ディレクトリと同じにすることはできません。また、Oracle Identity Managerがインストールされているのと同じサーバー上にステージング・ディレクトリがない場合、そのディレクトリを共有にして、Oracle Identity Managerサーバー上にネットワーク・ドライブとしてマップする必要があります。

- 「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「ステージング・ディレクトリ(複数値アイデンティティ・データ)」パラメータの値は指定できません。これは、信頼できるソース・リコンシリエーションでは、複数値(子)データのリコンシリエーションがサポートされていないためです。

それぞれの型の複数値アカウントまたはアイデンティティ・データに対し、共有ディレクトリに個別のファイルが必要です。たとえば、特定のターゲット・システムの複数値ユーザー・データがグループ・メンバーシップ・データとロール・データである場合、グループ・メンバーシップ・データのファイルとロール・データのファイルが別々に必要です。

子データファイルに格納されているデータは、親データファイルに指定されている規則(1行目、2行目、3行目以降)に準拠する必要があります。

また、同じ一意のフィールドが親データファイルとそれぞれの子データファイルに存在する必要があります。このフィールドは、子データファイルの各レコードを親データファイルのシングル・レコードに一意にリンクするために使用されます。この構造は、RDBMSの整合性制約(主キーと外部キー)の概念に類似しています。

注意:

一意のフィールドは、子データファイルの最初のフィールドである必要があります。

次に示すサンプルの子データファイルには、前述のサンプル親データファイルにリンクされるロール情報が含まれています。

###Role
User ID TD,Role Name TD,Role Type TD
jodoe,admin1,admin
jadoe,admin2,admin

次に示すサンプルの子データファイルには、前述のサンプル親データファイルにリンクされるグループ・メンバーシップ情報が含まれています。

###Group Membership
User ID TD,Group Name TD,Group Type TD
jodoe,OracleDev1,OracleDev
jadoe,OracleDev2,OracleDev
jadoe,OracleDev3,OracleDev
jadoe,OracleDev4,OracleDev
jadoe,OracleDev5,ConnectorDev

一意のフィールドの名前User ID TDは、子データファイルと親データファイルで同じであることに注意してください。

「「ステップ3: コネクタ構成の変更」ページ」で説明されている「ステップ3: コネクタ構成の変更」ページでは、子データセットの名前は子データファイルで指定したヘッダーと同じです。前述のサンプルの子データファイルの場合、子データセットのラベルはRoleとGroup Membershipになります。また、「ステップ4: コネクタ・フォーム名の検証」ページでは、子データセットに対応するフォームに表示されるデフォルト名はRoleとGroup Membershipになります。「「ステップ4: コネクタ・フォーム名の検証」ページ」で説明されているように、デフォルトのフォーム名を使用することも、変更することもできます。

関連項目:

「ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限」

- アーカイブ・ディレクトリ
このパラメータを使用して、すでにリコンサイルした親および子データファイルを格納するディレクトリのパスを指定します。これはランタイム・パラメータです。

このパラメータ値の指定は必須です。

リコンシリエーション実行終了時に、データファイルはアーカイブ・ディレクトリにコピーされ、ステージング・ディレクトリから削除されます。

アーカイブ・ディレクトリに移動したファイルにタイムスタンプまたはマークは付きません。このため、アーカイブ・ディレクトリのパスを指定するときは、次のガイドラインに注意してください。

- 指定するアーカイブ・ディレクトリ・パスは、ステージング・ディレクトリ・パスと同じものにしないでください。同じパスを指定すると、アーカイブ・ディレクトリ内の既存のファイルがリコンシリエーションの実行終了時に削除されます。

- 前回のリコンシリエーション実行で使用されたファイルと同じ名前のデータファイルがステージング・ディレクトリに配置されていると、アーカイブ・ディレクトリ内の既存のファイルが、現在のリコンシリエーションの実行終了時に、ステージング・ディレクトリからの新しいファイルで上書きされます。

この点については、「「ステップ2: パラメータ値の指定」ページ」にも記載されています。

関連項目:

「ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限」

- ファイルの接頭辞
このパラメータを使用して、親データファイルと子データファイルの両方について、ステージング・ディレクトリ内のファイルの名前をフィルタするために使用する接頭辞を指定します。リコンシリエーション中は、ファイル拡張子に関係なく、指定した接頭辞で始まる名前を持つ(ステージング・ディレクトリ内の)すべてのファイルが処理されます。これはランタイム・パラメータです。

例:

「ファイルの接頭辞」パラメータの値としてusrdataを指定すると、複数値(子)ユーザー・データファイルに関して、ステージング・ディレクトリに配置された次のファイルのデータが解析されます。

usrdataRoleData.csv
usrdataGroupMembershipData.txt

同じディレクトリにある次のファイルからはデータは抽出されません。これは、ファイル名がusrdataで始まらないためです。

RoleData.csv
GroupMembershipData.txt

- 指定されたデリミタ
このパラメータを使用して、親および子データファイルでデリミタ文字として使用する文字を指定します。このパラメータの値として指定できるのは1文字のみです。これはランタイム・パラメータです。このパラメータは「タブ区切り」パラメータよりも優先されます。

注意:

空白( )はデリミタとして使用できません。

また、指定する文字が、そのデータファイルでデリミタとしてのみ使用されることを確認する必要があります。この文字がデータ自体にも含まれる場合、データ行(レコード)は正しく解析されません。たとえば、カンマ(,)がデータ値に含まれる場合は、デリミタとしてカンマを使用できません。

- タブ区切り
このパラメータを使用して、ファイルがタブ区切りかどうかを指定します。これはランタイム・パラメータです。「指定されたデリミタ」パラメータの値を指定すると、このパラメータは無視されます。

- 固定列幅
入力ファイルに固定幅データが含まれる場合は、このパラメータを使用してデータ列の文字の幅を指定します。これはランタイム・パラメータです。

注意:

ここでは、固定幅という用語は、データ・フィールドのバイト長ではなく文字数を意味します。たとえば、幅という意味ではシングルバイト・データ4文字とマルチバイト・データ4文字は同じになります。

「指定されたデリミタ」または「タブ区切り」パラメータの値を指定すると、このパラメータは無視されます。

- 一意の属性(親データ)
複数値ユーザー・データの場合は、このパラメータを使用して、親と子の両方のデータファイルに共通するフィールドを指定します。前述の例では、一意の属性に対する要件は、親と子の両方のデータファイルに存在するUser ID TDフィールドで満たされます。これはランタイム・パラメータです。

注意:

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「一意の属性(親データ)」パラメータの値は指定できません。これは、信頼できるソース・リコンシリエーションでは、複数値(子)データのリコンシリエーションがサポートされていないためです。

- ファイル・エンコーディング
このパラメータを使用して、親およびデータファイルで使用されるキャラクタ・セット・エンコーディングを指定します。これは設計パラメータです。

言語設定が英語のオペレーティング・システムを実行しているコンピュータでは、データファイルにCp1251を指定します。これは、汎用テクノロジ・コネクタ・フレームワークでサポートされるjava.io APIの正規名です。「多言語サポート」の項に示されたリストからその他の言語を選択する場合は、次のWebページを参照して、対応するjava.io APIの正規名を指定する必要があります。

http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html

注意:

APIに指定する正規名は、このWebページに表示されているとおりに入力する必要があります。正規名の大/小文字は変更しないでください。

たとえば、Microsoft Windowsコンピュータで繁体字中国語のエンコーディング・セットを指定する場合は、「ファイル・エンコーディング」パラメータの値としてMS950を指定します。

ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限

ステージング・ディレクトリとアーカイブ・ディレクトリに必要な権限が設定されていることを確認してください。次の表に、ステージングおよびアーカイブのデータファイルの保持に使用される共有ディレクトリに対する様々な権限の影響を示します。

記憶域エンティティ

アクセス権

アクセス権が必要な理由

親データファイルのステージング・ディレクトリ

読取り

この権限は、リコンシリエーションの実行に必要です。この権限が適用されない場合、エラー・メッセージがログに記録されます。

親データファイルのステージング・ディレクトリ

書込み

この権限は、アーカイブ・プロセスの最後にデータファイルを親ステージング・ディレクトリから削除するために必要です。

親データファイルのステージング・ディレクトリ

実行

適用外

子データファイルのステージング・ディレクトリ

読取り

この権限は、子データのリコンシリエーションに必要です。この権限が適用されない場合、エラー・メッセージがログに記録されます。

子データファイルのステージング・ディレクトリ

書込み

この権限は、アーカイブ・プロセスの最後にデータファイルを子ステージング・ディレクトリから削除するために必要です。

子データファイルのステージング・ディレクトリ

実行

適用外

アーカイブ・ディレクトリ

書込み

この権限は、アーカイブ・プロセス中に親および子データファイルをアーカイブ・ディレクトリにコピーするために必要です。この権限が適用されなくても、次の処理が行われます。

- 親および子データのリコンシリエーションが実行されます。

- 親および子ステージング・ディレクトリに必要な権限が設定されていない場合、ファイルはこれらのディレクトリから削除されます。

アーカイブ・ディレクトリ

実行

適用外

ステージング・ディレクトリ内の親または子データファイル

読取り

この権限は、ファイル内のデータのリコンシリエーションに必要です。この権限が適用されない場合、エラー・メッセージがログに記録されます。

ステージング・ディレクトリ内の親または子データファイル

書込み

この権限は、アーカイブ・プロセスの最後にデータファイルを削除するために必要です。この権限が適用されない場合、エラー・メッセージがログに記録されます。ただし、このファイル内のデータはリコンサイルされます。

ステージング・ディレクトリ内の親または子データファイル

実行

適用外

注意:

ステージング・ディレクトリ内のデータファイルは、いずれかのエディタで開かれているか他のプログラムによる書込みのために開かれていると、削除できません。

17.2 CSVリコンシリエーション・フォーマット・プロバイダ

CSVリコンシリエーション・フォーマット・プロバイダは、文字区切り、タブ区切りまたは固定長形式のリコンシリエーション・データをOracle Identity Managerでサポートされている形式に変換します。

CSVリコンシリエーション・フォーマット・プロバイダはスタンドアロン・プロバイダとしてパッケージ化されていますが、そのパラメータはすべて共有ドライブ・トランスポート・プロバイダにバンドルされています。「ステップ1: 基本情報の指定」ページで共有ドライブ・トランスポート・プロバイダを選択した場合は、CSVフォーマット・プロバイダを選択する必要があります。このプロバイダを選択すると、そのパラメータが共有ドライブ・トランスポート・プロバイダのパラメータとともに表示されます。

17.3 SPMLプロビジョニング・フォーマット・プロバイダ

SPMLプロビジョニング・フォーマット・プロバイダは、Oracle Identity Manager上でのプロビジョニング操作中に生成されたプロビジョニング・データをSPML対応のターゲット・システムで処理できるSPMLリクエストに変換します。

注意:

各SPMLリクエストはSOAPメッセージで送信されます。SOAPヘッダーには、リクエストの認証情報が含まれます。SPMLリクエストの実際のデータは、SOAPメッセージ本文に含まれます。

SPML-SOAPメッセージの構造の詳細は、第32章「SPMLサービスの使用」を参照してください。

サンプルSOAPメッセージは、次のディレクトリにあります。

OIM_HOME/GTC/Samples/spml

SPML仕様の詳細は、OASISのWebサイトの次のWebページを参照してください。

http://www.oasis-open.org/specs/index.php#spmlv2.0

図17-1に、SPMLプロビジョニング・フォーマット・プロバイダがリクエスト局(RA)として機能し、ターゲット・システムがプロビジョニング・サービス・プロバイダ(PSP)およびプロビジョニング・サービス・ターゲット(PST)を提供するシステムの設定を示します。

図17-1 SPMLプロビジョニング・フォーマット・プロバイダとターゲット・システムの間の通信

実際のプロビジョニング中は、SOAP-SPMLリクエストの作成にVelocityテンプレート・エンジンが使用されます。次のプロセスでは、プロバイダがSPML 2.0 DSMLプロファイルに基づいてSOAPリクエストを生成します。

- リクエストの追加

- 次のOracle Identity Managerプロセス・タスクに対するリクエストの変更:

- フィールドの更新

- 子データの追加

- 子データの変更

- 子データの削除

- リクエストの一時停止(Oracle Identity Managerプロセス・タスクの無効化)

- リクエストの再開(Oracle Identity Managerプロセス・タスクの有効化)

- リクエストの削除

「組織の作成」、「組織の更新」および「組織の削除」はサポートされていません。これは、汎用テクノロジ・コネクタ用に作成されたリソース・オブジェクトでは組織用のプロビジョニング操作がサポートされていないためです。「グループの作成」、「グループの更新」および「グループの削除」操作はサポートされていません。これは、グループのプロビジョニング操作がOracle Identity Managerでサポートされていないためです。

このプロバイダを選択すると、デフォルトでは、「「ステップ3: コネクタ構成の変更」ページ」で説明されている「ステップ3: コネクタ構成の変更」ページに、次のアイデンティティ・フィールドが「ID」フィールドとともに表示されます。

- objectClass

- containerID

各プロビジョニング・タスク(「ユーザーの作成」や「ユーザーの変更」など)について、このプロバイダによってリクエストが事前定義済の形式で生成されます。

次の各項では、このプロバイダのパラメータについて説明します。

- ランタイム・パラメータ

- 設計パラメータ

使用するアプリケーション・サーバーによっては、一部のランタイム・パラメータと設計パラメータは必須になり、一部のパラメータは固定値になります。次の各項では、これらのパラメータについて説明します。

- 必須でないパラメータ

- 値が事前定義済のパラメータ

17.3.1 ランタイム・パラメータ

SPMLプロビジョニング・フォーマット・プロバイダのランタイム・パラメータを次に示します。

- ターゲットID
この値により、プロビジョニング操作のターゲット・システムを一意に識別します。

- ユーザー名(認証)
これは、Webサービス・インタフェース(PSP)を介してターゲット・システム(PST)に接続するために必要なアカウントのユーザー名です。

- ユーザー・パスワード(認証)
これは、Webサービス・インタフェース(PSP)を介してターゲット・システム(PST)に接続するために必要なユーザー・アカウントのパスワードです。

17.3.2 設計パラメータ

SPMLプロビジョニング・フォーマット・プロバイダの設計パラメータを次に示します。

関連項目:

この項で説明するSOAP要素および属性の詳細は、次のWebサイトを参照してください。

http://www.w3.org/TR/wsdl20/

- WebサービスのSOAPアクション
WSDLファイルでは、これはoperation要素のsoapAction属性の値になります。

- SPML WebサービスのWSSEが構成されていますか。
WS-Security資格証明を使用して着信リクエストを認証するようにWebサービスが構成されている場合は、このチェック・ボックスを選択します。

- カスタム認証資格証明ネームスペース

注意:

「SPML WebサービスWSSEが構成されていますか。」チェック・ボックスを選択した場合は、このパラメータの値を指定する必要はありません。

これは、Webサービス用に定義した資格証明ネームスペースの名前です。多くの場合、このネームスペースはターゲット・ネームスペースと同じになります。

- カスタム認証ヘッダー要素

注意:

「SPML WebサービスWSSEが構成されていますか。」チェック・ボックスを選択した場合は、このパラメータの値を指定する必要はありません。

これは、ターゲット・システムへの接続に使用されるユーザー・アカウントの資格証明が格納される要素の名前です。つまり、SOAPメッセージ・ヘッダーのカスタム認証セクション内の親要素です。

- ユーザー名を格納するカスタム要素

注意:

「SPML WebサービスWSSEが構成されていますか。」チェック・ボックスを選択した場合は、このパラメータの値を指定する必要はありません。

これは、「ユーザー名(認証)」パラメータの値として指定するユーザー名が格納されるカスタム認証セクション内の要素の名前です。

- パスワードを格納するカスタム要素

注意:

「SPML WebサービスWSSEが構成されていますか。」チェック・ボックスを選択した場合は、このパラメータの値を指定する必要はありません。

これは、「ユーザー・パスワード(認証)」パラメータの値として指定するユーザー名が格納されるカスタム認証セクション内の要素の名前です。

- SPML Webサービスのバインディング・スタイル(DOCUMENTまたはRPC)
WSDLファイルでは、これはbinding要素のstyle属性の値になります。DOCUMENTまたはRPCを入力する必要があります。

注意:

値DOCUMENTまたはRPCを入力する必要があります。指定する値に小文字は使用しないでください。

- SPML Webサービスの複合データ型
WSDLファイルでは、これはcomplexType要素のname属性の値になります。このパラメータは、バインディング・スタイルがDOCUMENTの場合にのみ適用されます。ターゲットWebサービスがOracle WebLogic Server上で実行されている場合は、このパラメータの値を指定する必要があります。

- SPML Webサービス操作名
WSDLファイルでは、これはoperation要素のname属性の値になります。このパラメータは、バインディング・スタイルがRPCの場合にのみ適用されます。

- SPML Webサービスのターゲット・ネームスペース
WSDLファイルでは、これはdefinition要素のtargetNamespace属性の値になります。

- SPML WebサービスのSOAPメッセージ本文の接頭辞
これは、SOAPメッセージ本文を含んでいるカスタム接頭辞要素の名前です。ターゲットWebサービスがOracle WebLogic Server、IBM WebSphere Application Server、JBoss Application ServerまたはOracle Application Server上で実行されている場合は、このパラメータの値を指定する必要はありません。ただし、別のアプリケーション・サーバーを使用している場合は、カスタム接頭辞要素の名前を入力する必要があります。次に、WebサービスがOracle WebLogic Server上で実行されている場合の接頭辞要素を示します。

<SPMLv2Document xmlns="http://xmlns.oracle.com/OIM/provisioning">

- グループ・メンバーシップ情報を保持している子データセットのID属性
これは、グループ・メンバーシップ情報を保持しているプロビジョニング・ステージング子データセットの一意のアイデンティティ・フィールドの名前です。このフィールドを含む子データセットに対するプロビジョニング操作では、SOAPパケットにグループ操作のSPMLコードが含まれます。次に、この型のグループ操作のSPMLコード・ブロックを示します。

<modification modificationMode="add">
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference" mustUnderstand="true">
<reference typeOfReference="memberOf" xmlns="urn:oasis:names:tc:SPML:2:0:reference">
<toPsoID ID="Groups:1" targeted="120"/>
</reference>
</capabilityData>
</modification>

このフィールドを含まない子データセットに対するプロビジョニング操作では、SOAPパケットに通常のSPMLコードが含まれます。次に、この型のグループ操作のSPMLコード・ブロックを示します。

<modification>
<dsml:modification name="Group Membership" operation="add">
<dsml:value>AdminOra, System Admins, USA</dsml:value>
</dsml:modification>
</modification>

17.3.3 必須でないパラメータ

Oracle WebLogic Serverでは、次のパラメータ値を指定する必要はありません。

- SPML Webサービスの複合データ型

- SPML WebサービスのSOAPメッセージ本文の接頭辞

- グループ・メンバーシップ情報を保持している子データセットのID属性

17.3.4 値が事前定義済のパラメータ

Oracle WebLogic Serverでは、次のパラメータに事前定義済の値を指定できます。

- WebサービスURL: http://IP_address:port_number/spmlws/OIMProvisioning

- SPML Webサービスのバインディング・スタイル(DOCUMENTまたはRPC): RPC

- SPML Webサービス操作名: processRequest

17.4 Webサービス・プロビジョニング・トランスポート・プロバイダ

Webサービス・プロビジョニング・トランスポート・プロバイダは、Webサービス・クライアントとして機能し、プロビジョニング・リクエスト・データをOracle Identity Managerからターゲット・システムWebサービスに転送します。

次のタイプのターゲット・システムWebサービスがサポートされています。

- RPCリテラル

- RPCエンコード

- DOCUMENTリテラル

Webサービス・プロビジョニング・トランスポート・プロバイダのパラメータを次に示します。

WebサービスURL

このパラメータを使用して、ターゲット・システムへのプロビジョニング・リクエストの送信に使用するWebサービスのURLを指定します。これはランタイム・パラメータです。WSDLファイルでは、WebサービスURLはwsdlsoap:address要素のlocation属性の値になります。

作成する汎用テクノロジ・コネクタにWebサービス・プロビジョニング・トランスポート・プロバイダを含める場合は、ターゲット・システムとOracle Identity Managerの間にSecure Sockets Layer (SSL)通信を構成する場合があります。次の項では、この手順の詳細を説明します。

17.4.1 Oracle Identity Managerとターゲット・システムWebサービスの間のSSL通信の構成

この項では、Oracle Identity Managerがインストールされているアプリケーション・サーバーをSSL通信用に構成する手順について説明します。

この手順は、次の条件をすべて満たす場合にのみ実行できます。

- 作成する汎用テクノロジ・コネクタにWebサービス・プロビジョニング・トランスポート・プロバイダを含める場合。

- ターゲットWebサービスがSSL対応アプリケーション・サーバー上で実行されている場合。

Oracle Identity Managerとターゲット・システムWebサービスの間のSSL通信を構成するには、次の手順を実行します。

注意:

この手順は、汎用テクノロジ・コネクタを作成する前に実行できます。

1. 次のようにしてターゲット・アプリケーション・サーバーの証明書をエクスポートします。

- JBoss Application ServerまたはOracle WebLogic Server上にデプロイされているターゲット・システムWebサービスの場合は、次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool -export -alias default -file exported-certificate-file -keystore app-server-specific-keystore  -storetype jks –storepass keystore-password –provider sun.security.provider.Sun

このコマンドでは、次のように指定します。

- JAVA_HOMEを、SUN JDKディレクトリのフルパスに置換します。

- exported-certificate-fileを、エクスポートした証明書を格納するファイルの名前に置換します。

- app-server-specific-keystoreを、アプリケーション・サーバーのキーストアのパスに置換します。

- keystore-passwordを、キーストアのパスワードに置換します。

- IBM WebSphere Application ServerまたはAIX上のOracle WebLogic Server上にデプロイされているターゲット・システムWebサービスの場合は、次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool -export -alias default -file exported-certificate-file -keystore app-server-specific-keystore -storetype jks –storepass keystore-password -provider com.ibm.crypto.provider.IBMJCE

このコマンドでは、次のように指定します。

- JAVA_HOMEを、IBM JDKディレクトリのフルパスに置換します。

- exported-certificate-fileを、エクスポートした証明書を格納するファイルの名前に置換します。

- app-server-specific-keystoreを、アプリケーション・サーバーのキーストアのパスに置換します。

- keystore-passwordを、キーストアのパスワードに置換します。

コマンドを実行すると、エクスポートされた証明書ファイルはexported-certificate-fileの値で指定したファイルに格納されます。

2. 次のようにして、前の手順でエクスポートした証明書ファイルをOracle Identity Managerのトラストストアにインポートします。

1. 前の手順でエクスポートした証明書ファイルを、Oracle Identity Managerサーバーの一時ディレクトリにコピーします。

2. 次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool -import -trustcacerts -alias servercert -noprompt -keystore OIM_HOME\config\.xlkeystore -file certificate_file

このコマンドでは、次のように指定します。

- JAVA_HOMEを、JDKディレクトリのフルパスに置換します。IBM WebSphere Application ServerにデプロイされているOracle Identity Management Serverの場合は、IBM JDKディレクトリのパスにする必要があります。JBoss Application ServerまたはOracle WebLogic ServerにデプロイされているOracle Identity Managerの場合は、SUN JDKディレクトリのパスにする必要があります。

- OIM_HOMEを、Oracle Identity Managerホーム・ディレクトリのパスに置換します。

- certificate_fileを、証明書ファイルをコピーした一時ディレクトリのパスに置換します。

注意:

アプリケーション・サーバーで一方向SSL通信が有効化されている場合は、残りの手順を実行する必要はありません。

3. 次のようにして、Oracle Identity Managerの証明書をターゲット・システム・アプリケーション・サーバーのトラストストアにインポートします。

注意:

次の手順は、アプリケーション・サーバーで双方向SSL通信が有効化されている場合にのみ実行します。

1. Oracle Identity Managerの証明書ファイルをエクスポートします。
Oracle WebLogic ServerにデプロイされているOracle Identity Managerの場合は、次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool -export -alias xell -file OIM_HOME\config\xell.cert -keystore OIM_HOME\config\.xlkeystore -storetype jks –provider sun.security.provider.Sun

このコマンドでは、次のように指定します。

- JAVA_HOMEを、SUN JDKディレクトリのフルパスに置換します。

- OIM_HOMEを、Oracle Identity Managerホーム・ディレクトリのパスに置換します。

2. 次のようにして、手順3aでエクスポートした証明書ファイルをアプリケーション・サーバーのトラストストアにインポートします。
エクスポートしたOracle Identity Managerの証明書ファイルを、ターゲット・アプリケーション・サーバー上の一時ディレクトリにコピーします。

次に、ターゲット・アプリケーション・サーバーで次のコマンドを実行します。

- ターゲット・アプリケーション・サーバーがJBoss Application ServerまたはOracle WebLogic Serverである場合は、次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool –import –alias alias -trustcacerts  -file OIM-certificate-file -keystore app-server-specific-truststore  -storetype jks –storepass truststore-password –provider sun.security.provider.Sun

このコマンドでは、次のように指定します。

* JAVA_HOMEを、SUN JDKディレクトリのフルパスに置換します。

* aliasを、ターゲット・アプリケーション・サーバーのトラストストアにある証明書の別名に置換します。

* OIM-certificate-fileを、エクスポートしたOracle Identity Manager証明書ファイルの名前に置換します。

* app-server-specific-truststoreを、ターゲット・アプリケーション・サーバーのトラストストアのパスに置換します。

* truststore-passwordを、ターゲット・アプリケーション・サーバーのトラストストアのパスワードに置換します。

- ターゲット・アプリケーション・サーバーがIBM WebSphere Application Serverである場合は、次のコマンドを実行します。

JAVA_HOME/jre/bin/keytool -import -alias alias -trustcacerts -file OIM-certificate-file -keystore app-server-specific-truststore -storetype pkcs12 –storepass truststore-password -provider com.ibm.crypto.provider.IBMJCE

このコマンドでは、次のように指定します。

* JAVA_HOMEを、SUN JDKディレクトリのフルパスに置換します。

* aliasを、ターゲット・トラストストアにある証明書の別名に置換します。

* OIM-certificate-fileを、エクスポートした
Oracle Identity Manager証明書ファイルの名前に置換します。

* app-server-specific-truststoreを、ターゲット・アプリケーション・サーバーのトラストストアのパスに置換します。

* truststore-passwordを、ターゲット・アプリケーション・サーバーのトラストストアのパスワードに置換します。

関連項目:

ターゲット・アプリケーション・サーバーについては、SSL構成のドキュメントを参照してください。

17.5 変換プロバイダ

注意:

この項に示す情報は、第19.2.4.3項「「ステップ3: コネクタ構成の変更」ページ」に記載されている手順を実行するときに使用してください。

変換プロバイダは、次の表に示すソース・データセットと宛先データセットの間で移動中のユーザー・データを変換するために使用されます。

ソース・データセット

宛先データセット

変換の目的

ソース

リコンシリエーション・ステージング

リコンシリエーション・イベントの作成に使用する前にデータを変換します。

Oracle Identity Manager

プロビジョニング・ステージング

ターゲット・システムに送信されるプロビジョニング・リクエストの作成に使用する前にデータを変換します。

Oracle Identity Managerでは、次の事前定義済変換プロバイダが使用できます。

- 連結変換プロバイダ

- 翻訳変換プロバイダ

17.5.1 連結変換プロバイダ

連結変換プロバイダは、データセットの2つのフィールドの値を連結して、別のデータセットの単一フィールドへの入力を作成するために使用します。

次の例では、このプロバイダの出力形式について説明します。

入力値がソース・データセットの次のフィールドであるとします。

- 名: John

- 姓: Doe

連結変換プロバイダをこの2つのフィールドに適用すると、出力値は次のようになります。

John Doe

注意:

前述の例に示すように、連結変換プロバイダでは2つの入力フィールドの値の間に空白が追加されます。

次の手順では、汎用テクノロジ・コネクタの作成中に連結変換プロバイダを追加する方法について説明します。

注意:

この手順では、第19.2.4.3.1項「データセットのフィールドの追加または編集」の手順5に記載されている手順を詳しく説明しています。ここでは、「ステップ1: フィールド情報」ページの「アクションのマッピング」リストから「連結」オプションを選択し、その項の手順2と3をすでに実行したことを前提にしています。

ポップアップ・ウィンドウの「ステップ2: マッピング」ページで、次の手順を実行します。

1. 「入力1」リージョンの「データセット」リストから、連結する最初のフィールドを含むデータセットを選択します。「フィールド名」リストから最初のフィールドを選択します。または、「リテラル」オプションを使用してリテラル(固定)値を最初の連結入力として指定することも可能です。
前述の例の場合は、「入力1」リージョンの「データセット」リストから、「名」フィールドを含むデータセットを選択します。次に、「フィールド名」リストから「名」を選択します。

2. 「入力2」リージョンの「データセット」リストから、連結する2番目のフィールドを含むデータセットを選択します。次に、「フィールド名」リストから2番目のフィールドを選択します。または、「リテラル」オプションを使用してリテラル(固定)値を2番目の連結入力として指定することも可能です。
前述の例の場合は、「入力2」リージョンの「データセット」リストから、「姓」フィールドを含むデータセットを選択します。次に、「フィールド名」リストから「姓」を選択します。

17.5.2 翻訳変換プロバイダ

変換操作では、特定の(リテラル)値を入力として受け入れ、それを別の値に変換します。

次に変換操作の例を示します。

「ソース」データセットに「国」フィールドが含まれており、このフィールドに格納されているデータ値が次のいずれかの値を取ることができるとします。

- オーストリア

- フランス

- ドイツ

- インド

- 日本

これらの値をリコンシリエーション・ステージング・データセットに伝播する場合、それぞれの値を次のように変換するとします。

- AT

- FR

- DE

- IN

- JP

この変換を自動化するには、翻訳変換プロバイダを使用できます。

翻訳変換プロバイダを使用するには、次の手順を実行します。

1. Design Consoleを使用して、入力およびデコード値を格納する参照定義を作成します。

関連項目:

第7.2.1項「参照定義の作成」

注意:

参照定義を「参照定義」フォームで作成する場合は、フィールド・タイプ・オプションではなく参照タイプ・オプションを選択する必要があります。

前述の「国」フィールドの例では、コード・キーおよびデコードは次の表に示す値になります。

コード・キー

デコード

オーストリア

AT

フランス

FR

ドイツ

DE

インド

IN

日本

JP

2. 変換対象の入力フィールドと出力フィールドの間の変換マッピングを定義します。前述のとおり、変換は次のデータセットのペア間で設定できます。

- 「ソース」と「リコンシリエーション・ステージング」

- 「Oracle Identity Manager」とプロビジョニング・ステージング

注意:

この手順では、第19.2.4.3.1項「データセットのフィールドの追加または編集」の手順5に記載されている手順を詳しく説明しています。ここでは、「ステップ1: フィールド情報」ページの「アクションのマッピング」リストから「連結」オプションを選択し、その項の手順2と3をすでに実行したことを前提にしています。

1. 「ステップ3: マッピング」ページで、「入力」リージョンの「データセット」リストから、変換操作を行う入力値を提供するフィールドのあるデータセットを選択します。次に、「フィールド名」リストからフィールド自体を選択します。
前述の「国」フィールドの例では、「国」フィールドがあるデータセットを選択してから、「国」フィールドを選択します。

2. 「参照コード名」リージョンで、「リテラル」を選択し、前の手順で作成した参照定義の名前を入力します。

注意:

「参照コード名」リージョンではデータセット名およびフィールドを指定しないでください。データセット名およびフィールドの選択を無効にする検証は行われませんが、実際のリコンシリエーションまたはプロビジョニングの操作時に変換操作に失敗します。

これについては、「マッピング」にも記載されています。

前述の「国」フィールドの例では、「リテラル」を選択し、手順1で作成した参照定義を選択します。

17.5.2.1 アカウント・ステータスのリコンシリエーションの構成

ユーザー・アカウント・ステータス情報は、ターゲット・システム・アカウントの所有者によるアカウントへのアクセスおよびアカウントの使用が許可されるかどうかの追跡に使用されます。必要に応じて、翻訳変換プロバイダを使用してアカウント・ステータス情報をリコンサイルできます。

注意:

Design Consoleでは、アカウント・ステータスのリコンシリエーションを構成する別の方法が提供されます。この方法では、汎用テクノロジ・コネクタは使用しません。第5.3.2.2.1項「ユーザー・アカウント・ステータスのリコンシリエーション」に、この方法の説明があります。

翻訳変換プロバイダを使用する必要があるのは、ターゲット・システムで使用されるアカウント・ステータスの値が、Oracle Identity Managerで使用される値と同じでない場合のみです。ターゲット・リソースに対して、Oracle Identity Managerでは次の値が使用されます。

- 有効状態: Enabled

- 無効状態: Disabled

信頼できるソースに対しては、Oracle Identity Managerでは次の値が使用されます。

- 有効状態: Active

- 無効状態: Disabled

次に、アカウント・ステータスのリコンシリエーションを構成する手順を簡単に説明します。

注意:

これらの手順の詳しい説明はこの項で後述します。

1. ターゲット・システムで使用されるステータス値とOracle Identity Managerで使用される値をマップする参照定義を作成します。

2. 汎用テクノロジ・コネクタを作成する際に、翻訳変換プロバイダを使用して、「ソース」データセットとリコンシリエーション・ステージング・データセットのアカウント・ステータス値を含むフィールド間に変換マッピングを作成します。
次に、実行する必要があるアクションの例を示します。

アカウント・ステータス値を保持するために次のフィールドが使用されているとします。

- 「ソース」データセットの「ユーザー・ステータス」フィールドには、True (Enabled状態のユーザー)とFalse (Disabled状態のユーザー)の値が含まれます。

- リコンシリエーション・ステージング・データセットの「ユーザー・ステータス」フィールドは、次のいずれかの組合せの値を保持する必要があります。

- ターゲット・リソースのリコンシリエーションでは、このフィールドはEnabledまたはDisabledを含む必要があります。

- 信頼できるソースのリコンシリエーションでは、このフィールドはActiveまたはDisabledを含む必要があります。

「ソース」データセットの「ユーザー・ステータス」フィールドのTrue/False値をEnabled/Disabled値またはActive/Disabled値に変換する変換マッピングを作成する必要があります。リコンシリエーション時には、これらの変換された値がリコンシリエーション・ステージング・データセットの「ユーザー・ステータス」フィールドに送信されます。

3. リコンシリエーション・ステージング・データセットでアカウント・ステータス値を保持するフィールドと、次のいずれかのフィールドの間のマッピングを作成します。

- 「OIM - アカウント」データセットの「OIMオブジェクト・ステータス」フィールド(ターゲット・リソースのリコンシリエーションの場合)

- 「OIM - ユーザー」データセットの「ステータス」フィールド(信頼できるソースのリコンシリエーションの場合)

リコンシリエーション時には、このマッピングが使用されて、リコンシリエーション・ステージング・データセットのステータス値が「OIM - アカウント」または「OIM - ユーザー」データセットに伝播されます。

アカウント・ステータスのリコンシリエーションを構成する詳しい手順を次に示します。

1. ターゲット・システムで使用されるステータス値とOracle Identity Managerで使用される値をマップする参照定義を作成します。

関連項目:

第7.2項「「参照定義」フォーム」

参照定義のコード・キーの値は、ターゲット・システムでアカウント・ステータスを表すために使用されている値と同じである必要があります。信頼できるリソースとターゲット・リソースの両方のリコンシリエーションのコード・キーおよびデコードの値を次の表に示します。

コード・キー

デコード(信頼できるソースのリコンシリエーションの場合)

デコード(ターゲット・リソースのリコンシリエーションの場合)

Enabled状態のユーザー・アカウントのターゲット・システム・ステータス値

Active

Enabled

Disabled状態のユーザー・アカウントのターゲット・システム・ステータス値

Disabled

Disabled

コード・キー値の例には、True/False、Yes/Noおよび1/0があります。デコードの値は、表に示すとおり(大/小文字も含めて)正確に設定する必要があります。

注意:

参照定義を「参照定義」フォームで作成する場合は、フィールド・タイプ・オプションではなく参照タイプ・オプションを選択する必要があります。

2. 汎用テクノロジ・コネクタを作成する手順は、第19章「汎用テクノロジ・コネクタの作成および管理」で説明されています。汎用テクノロジ・コネクタを作成するときは、次の手順を「ステップ3: コネクタ構成の変更」ページで実行します。

注意:

次の手順は、第19.2.4.3.1項「データセットのフィールドの追加または編集」に示された手順を簡略にまとめたものです。ここで説明している用語やGUI要素の詳細は、この項を参照してください。

1. ターゲット・システムのステータス・フィールドが「ステップ3: コネクタ構成の変更」ページに表示されている場合は、リコンシリエーション・ステージング・データセットのフィールドに対する「編集」アイコンをクリックします。
フィールドが表示されていない場合は、リコンシリエーション・ステージング・データセットの「追加」アイコンをクリックします。

2. 「ステップ1: フィールド情報」ページで次のGUI要素の値を指定します。

- フィールド名: フィールドを追加する場合は、そのフィールドの名前を指定します。非ASCII文字は使用できないため、指定するフィールド名にはASCII文字のみを使用します。

- アクションのマッピング: このリストで「変換ありでマッピングの作成」を選択します。

- 一致のみ: このチェック・ボックスは選択しないでください。

- エンドツーエンド・マッピングの作成: フィールドを追加する場合は、このチェック・ボックスを選択します。

- 複数値フィールド: このチェック・ボックスは選択しないでください。

- データ型: フィールドのデータ型を選択します。

- 長さ: フィールドの文字の長さを指定します。

- 必須: フィールドに値が常に入力されるようにするには、このチェック・ボックスを選択します。

- 暗号化: このチェック・ボックスは選択しないでください。

- パスワード・フィールド: このチェック・ボックスは選択しないでください。

3. 「続行」をクリックします。

4. 「ステップ3: マッピング情報の指定」ページで次の手順を実行します。
「入力」リージョンで次のようにします。

- 「データセット」リストで「ソース」を選択します。

- 「フィールド名」リストで、ステータス値を含むフィールドを選択します。

「参照コード名」リージョンで、「リテラル」を選択し、手順1で作成した参照定義の名前を入力します。

5. 必要な場合は、フィールドの検証チェックを選択して「追加」をクリックします。つまり、使用する検証プロバイダを選択します。

6. 「続行」をクリックし、「閉じる」をクリックします。

3. リコンシリエーション・ステージング・データセットのステータス・フィールドと、「OIM - アカウント」データセットの「OIMオブジェクト・ステータス」フィールドまたは「OIM - ユーザー」データセットの「ステータス」フィールドのいずれかの間で、次のようにマッピングを作成します。

注意:

次の手順は、第19.2.4.3.1項「データセットのフィールドの追加または編集」に示された手順を簡略にまとめたものです。

1. ターゲット・リソースのリコンシリエーションの場合は、「OIM - アカウント」データセットの「OIMオブジェクト・ステータス」フィールドの編集アイコンをクリックします。
ターゲット・リソースのリコンシリエーションの場合は、「OIM - ユーザー」データセットの「ステータス」フィールドの編集アイコンをクリックします。

注意:

リコンシリエーション・ステージング・データセットのステータス・フィールドと、「OIMオブジェクト・ステータス」フィールドまたは「ステータス」フィールドの間にマッピングがすでに存在する場合は、必要な場合にのみこの手順を使用します。

2. 「ステップ1: フィールド情報」ページで次のGUI要素の値を指定します。

- アクションのマッピング: このリストで「変換なしでマッピングの作成」を選択します。

- 一致のみ: このチェック・ボックスは選択しないでください。

3. 「続行」をクリックします。

4. 「ステップ3: マッピング」ページの「入力」リージョンで、リコンシリエーション・ステージング・データセットのステータス・フィールドを選択します。

5. 「続行」をクリックし、さらに「続行」をクリックしてから、「閉じる」をクリックします。

6. 「ステップ3: コネクタ構成の変更」ページに表示されるその他のフィールドを追加または編集するには、第19.2.4.3.1項「データセットのフィールドの追加または編集」に示されている手順を実行します。

17.6 検証プロバイダ

表17-1に、Oracle Identity Managerに含まれている検証プロバイダを示します。

注意:

日付書式の検証プロバイダを除き、この表のすべてのプロバイダはApache Jakarta Commons APIのGenericValidatorクラスのメソッドの実装です。

表17-1 検証プロバイダ

検証プロバイダ

説明

IsBlankOrNull

フィールド値がNULLであり空白ではない場合にtrueを返します。

IsInRange

フィールド値が最小値と最大値のペアで指定された範囲内である場合にtrueを返します。

IsByte

フィールド値を基本型byteに変換できるかどうかをチェックします。

IsDouble

フィールド値を基本型doubleに変換できるかどうかをチェックします。

IsFloat

フィールド値を基本型floatに変換できるかどうかをチェックします。

IsInteger

フィールド値を基本型integerに変換できるかどうかをチェックします。

IsLong

フィールド値を基本型longに変換できるかどうかをチェックします。

IsShort

フィールド値を基本型shortに変換できるかどうかをチェックします。

MatchRegexp

フィールド値が指定の正規表現と一致するかどうかをチェックします。

注意: 正規表現は、一連の文字列を特定の構文ルールに従って記述または一致させるために使用する文字列です。

MaxLength

フィールド値の長さが指定値以下かどうかをチェックします。

MinLength

フィールド値の長さが指定値以上かどうかをチェックします。

日付書式の検証

ターゲット・システム・レコード内の日付値を、Oracle Identity Managerへのリコンサイル前に検証します。

「ソース日付書式」パラメータの値が検証の基礎として使用されます。この検証プロバイダは、「ステップ2: パラメータ値の指定」ページで「ソース日付書式」パラメータの値を指定した場合、このプロバイダを「ステップ3: コネクタ構成の変更」ページで選択するかどうかに関係なく適用されます。

注意: この表の他のプロバイダとは異なり、「日付書式の検証」はApache Jakarta Commons APIのGenericValidatorクラスのメソッドの実装ではありません。

18 汎用テクノロジ・コネクタ用カスタム・プロバイダの作成

事前定義済プロバイダで対応できないプロバイダ要件に対して、カスタム・プロバイダを作成する必要があります。この章では、カスタム・プロバイダの作成手順について説明します。

内容は次のとおりです。

- プロバイダの役割

- カスタム・プロバイダの作成

- プロバイダの再利用

- カスタム・プロバイダのデプロイ

18.1 プロバイダの役割

次の各項では、汎用テクノロジ・コネクタの作成中および使用中におけるプロバイダの役割を説明します。

- 汎用テクノロジ・コネクタ作成中のプロバイダの役割

- リコンシリエーション中のプロバイダの役割

- プロビジョニング中のプロバイダの役割

18.1.1 汎用テクノロジ・コネクタ作成中のプロバイダの役割

「アイデンティティ・システム管理」を使用して、汎用テクノロジ・コネクタを作成します。コネクタ作成手順のタスクの1つとして、データセットおよびデータセット間のデータ・フローが定義されます。このタスクは、メタデータの検出プロセスにより容易になります。

汎用テクノロジ・コネクタのコンテキストでは、メタデータという用語はユーザー・アカウント情報を構成する一連のアイデンティティ・フィールドを意味します。メタデータの検出という用語は、プロバイダによるターゲット・システムのメタデータ読込みおよび解析を指します。

メタデータの検出機能は、すべてのタイプのプロバイダでサポートされます。つまり、カスタム・プロバイダの作成時に、メタデータ読込み機能をプロバイダに組み込むことができます。

注意:

Javadocでは、メタデータの検出という用語のかわりにメタデータ定義という用語が使用されています。

図18-1に、メタデータの検出プロセスを示します。

図18-1 メタデータの検出プロセス

次の一連の手順で、メタデータの検出プロセスについて説明します。この一連の手順は、汎用テクノロジ・コネクタの作成時に「リコンシリエーション」オプションと「プロビジョニング」オプションの両方を選択するという想定に基づいています。いずれのオプションも選択しない場合は、対応する手順が実行されません。

関連項目:

次の手順で示されているSPIメソッドおよび値オブジェクトの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

Javadocでは、メタデータの検出という用語とメタデータ定義という用語が同義的に使用されています。

1. リコンシリエーション・トランスポート・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

2. リコンシリエーション・フォーマット・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

3. リコンシリエーション・トランスポート・プロバイダのgetMetadataメソッドが呼び出され、ターゲット・システムからメタデータがフェッチされます。このメソッドの出力はTargetSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。

4. リコンシリエーション・フォーマット・プロバイダのparseMetadataメソッドが呼び出され、ターゲット・システムからフェッチしたメタデータが解析されます。このメソッドの出力はOIMSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。

注意:

OIMSchema値オブジェクトは、第16.2.1項「リコンシリエーション・モジュールのプロバイダおよびデータセット」で説明しているソース・データセットに対応します。

5. プロビジョニング・トランスポート・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

6. プロビジョニング・フォーマット・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

7. リコンシリエーション・トランスポート・プロバイダおよびリコンシリエーション・フォーマット・プロバイダでメタデータを検出できない場合、プロビジョニング・トランスポート・プロバイダおよびプロビジョニング・フォーマット・プロバイダについて手順1から4が繰り返されます。

注意:

プロバイダは初期化した後、次のいずれかのイベントが発生するまでOracle Identity Managerのキャッシュに格納されています。

- キャッシュのパージ。

- Oracle Identity Managerの再起動。

- 汎用テクノロジ・コネクタの作成後の変更。

検証プロバイダおよびトランスフォーメーション・プロバイダは、必要な場合にのみインスタンス化されます。キャッシュには格納されません。

共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダでは、ターゲット・システムからメタデータを検出できます。ただし、Webサービス・プロビジョニング・トランスポート・プロバイダおよびSPMLプロビジョニング・フォーマット・プロバイダでは、この機能はサポートされていません。

18.1.2 リコンシリエーション中のプロバイダの役割

図18-2は、リコンシリエーション中のプロバイダの役割を示しています。

図18-2 リコンシリエーション中のプロバイダの役割

次の各手順で、リコンシリエーション中のプロバイダの役割について説明します。

1. リコンシリエーション・トランスポート・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

2. リコンシリエーション・フォーマット・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

3. 「アイデンティティ・システム管理」で汎用テクノロジ・コネクタを作成している場合、リコンシリエーション実行のバッチ・サイズを指定できます。このパラメータを使用して、リコンシリエーション実行中にリコンシリエーション・エンジンがターゲット・システムからフェッチするレコードの総数をバッチに分割します。このパラメータのデフォルト値はAllです。
バッチ・サイズを指定しない場合、リコンシリエーションのこの段階でリコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用に準備されているターゲット・システム・レコードの全体がフェッチされます。

バッチ・サイズを指定すると、リコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用にターゲット・システム・レコードの最初のバッチがフェッチされます。リコンシリエーション用のターゲット・システム・レコードのバッチが複数ある場合は、同一プロバイダのgetNextPageメソッドが(必要に応じて複数回)呼び出されます。

4. リコンシリエーション・フォーマット・プロバイダのparseRecordsメソッドが呼び出され、TargetRecord値オブジェクト配列の各レコードが処理されます。このメソッドの出力はOIMRecord値オブジェクトの配列です。

5. 汎用テクノロジ・コネクタの作成時に、「ソース」データセットから「リコンシリエーション・ステージング」データセットへのデータの移動中にデータを検証するため検証プロバイダを選択すると、次のように実行されます。

1. 検証プロバイダのインスタンスが作成されます。

2. OIMRecord値オブジェクト配列の各レコードに指定された属性に対して、それぞれの検証プロバイダのvalidateメソッドが実行されます。

汎用テクノロジ・コネクタの作成時に検証プロバイダを選択しない場合、手順5は実施されず、OIMRecord値オブジェクト配列の各要素は手順6に進みます。

6. 汎用テクノロジ・コネクタの作成時に、「ソース」データセットから「リコンシリエーション・ステージング」データセットへのデータの移動中のデータを変更するため変換プロバイダを選択してある場合、次のように実行されます。

1. 変換プロバイダのインスタンスが作成されます。

2. 変換プロバイダのtransformDataメソッドにより、次のいずれかの出力として生成されたOIMRecord値オブジェクト配列が処理されます。

- 各検証プロバイダのvalidateメソッド(検証プロバイダを選択した場合)

- リコンシリエーション・フォーマット・プロバイダのparseRecordsメソッド(検証プロバイダを選択しなかった場合)

汎用テクノロジ・コネクタの作成時に変換プロバイダを選択しない場合、手順6は実施されず、前の手順(手順4または手順5)で得られたOIMRecord値オブジェクト配列の各要素は手順7に進みます。

7. この段階では、OIMRecord値オブジェクト配列は、第16.2.1項「リコンシリエーション・モジュールのプロバイダおよびデータセット」で説明する「リコンシリエーション・ステージング」データセットに対応します。OIMRecord値オブジェクト配列の各要素がリコンシリエーション・エンジンに渡されます。

8. リコンシリエーション手順の終了時には、リコンシリエーション・トランスポート・プロバイダのendメソッドが呼び出されます。このメソッドから、汎用テクノロジ・コネクタ・フレームワークでITリソースのTimestampパラメータに格納される文字列値が戻されます。このフレームワークでは、リコンシリエーションの実行が完了した段階がTimestampパラメータにより追跡されます。

18.1.3 プロビジョニング中のプロバイダの役割

図18-3は、プロビジョニング中のプロバイダの役割を示しています。

図18-3 プロビジョニング中のプロバイダの役割

次の各手順で、プロビジョニング中のプロバイダの役割について説明します。

1. プロビジョニング・トランスポート・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

2. プロビジョニング・フォーマット・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。

3. 汎用テクノロジ・コネクタの作成時に作成されるコネクタ・オブジェクトの1つに、汎用テクノロジ・コネクタ・アダプタがあります。このアダプタにより、プロビジョニング・データ・レコードが名前/値ペアのハッシュマップに変換されます。このハッシュマップにはプロセス・インスタンスのデータが含まれています。各ハッシュマップは、OIMRecord値オブジェクトの要素に変換されます。この段階では、OIMRecord値オブジェクト配列は、第16.2.3項「Oracle Identity Managerデータセット」で説明する「Oracle Identity Manager」データセットに対応します。

4. 汎用テクノロジ・コネクタの作成時に、「Oracle Identity Manager」データセットから「プロビジョニング・ステージング」データセットへのデータの移動中のデータを変更するため変換プロバイダを選択すると、次のように実行されます。

1. 変換プロバイダのインスタンスが作成されます。

2. 変換プロバイダのtransformDataメソッドにより、入力したOIMRecord値オブジェクトの指定の属性が処理され、これらのレコードが出力のOIMRecord値オブジェクトに変換されます。この段階では、OIMRecord値オブジェクトは、第16.2.2項「プロビジョニング・モジュールのプロバイダおよびデータセット」で説明する「プロビジョニング・ステージング」データセットに対応します。

5. プロビジョニング・フォーマット・プロバイダのformatDataメソッドが呼び出され、OIMRecord値オブジェクトが処理されます。このプロセスの出力は、TargetOperation値オブジェクトです。

6. プロビジョニング・トランスポート・プロバイダのsendDataメソッドが呼び出され、TargetOperation値オブジェクトがターゲット・システムに送信されます。

7. プロビジョニング操作が作成リクエストの場合、結果は次のイベントのいずれかになります。

- ターゲット・システムで作成操作が正常に完了した時点で、新しく作成されたユーザー・アカウントに割り当てられる「ID」フィールド値が、sendDataメソッドから戻されます。この値はその後、汎用テクノロジ・コネクタ・フレームワークに渡され、このフレームワークによってデータベースにポストされます。

- 「ID」フィールド値が返されない場合は、作成操作が失敗したとみなされます。エラー・メッセージは、「アイデンティティ・システム管理」に表示されます。

- 名前/値ペアの作成後のいずれかの段階で操作が失敗すると、「アイデンティティ・システム管理」にエラー・メッセージが表示されます。

プロビジョニング操作が更新または削除リクエストの場合、「ID」フィールドは名前/値ペアの1つです。このタイプのプロビジョニング・リクエストが送信された場合、結果は次のイベントのいずれかになります。

- 名前/値ペアの作成後のいずれかの段階で操作が失敗すると、「アイデンティティ・システム管理」にエラー・メッセージが表示されます。

- 「ID」フィールドの値は、更新操作または削除操作が正常に完了した時点で、プロビジョニング・トランスポート・プロバイダの実装に応じて返される場合と返されない場合があります。
どちらの場合も、汎用テクノロジ・コネクタ・フレームワークでは「ID」フィールド値は必要ありません。

18.2 カスタム・プロバイダの作成

カスタム・プロバイダの作成は次の各手順で構成されます。

1. プロバイダ要件の確認

2. プロバイダ・パラメータの識別

3. 値オブジェクトのJavaコード実装の開発

4. プロバイダSPIメソッドのJavaコード実装の開発

5. ロギングおよび例外処理のJavaコードの開発

6. プロバイダXMLファイルの作成

7. プロバイダのリソース・バンドル・エントリの作成

8. プロバイダのデプロイ

18.2.1 プロバイダ要件の確認

プロバイダ要件を判断するためのガイドラインは、次のとおりです。

- リコンシリエーション・プロバイダ要件の確認

- プロビジョニング・プロバイダ要件の確認

18.2.1.1 リコンシリエーション・プロバイダ要件の確認

リコンシリエーション・プロバイダ要件の確認には、次のガイドラインが適用されます。

- ターゲット・システムをOracle Identity Managerのユーザー・アカウント情報のソースとしてのみ使用する場合、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダのみが必要です。プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダは必要ありません。
汎用テクノロジ・コネクタにリコンシリエーション・モジュールを含める場合、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの両方を(いずれかのプロバイダが不要な場合にも)含める必要があります。

リコンシリエーション・フォーマット・プロバイダの機能は、ターゲット・システムのデータをOracle Identity Managerでサポートされている形式に変換するものです。ターゲット・システムで、Oracle Identity Managerのサポートする形式でデータが生成される場合にも、汎用テクノロジ・コネクタの作成時にはリコンシリエーション・フォーマット・プロバイダを含める必要があります。

- 事前定義済プロバイダで対応できないプロバイダ要件に対してのみ、カスタム・プロバイダの作成が必要になります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義済プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。

たとえば、ターゲット・システムでカンマ区切り形式のリコンシリエーション・データファイルを生成できる場合は、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダを使用できます。カスタム・リコンシリエーション・プロバイダを作成する必要はありません。

関連項目:

第18.3項「プロバイダの再利用」

18.2.1.2 プロビジョニング・プロバイダ要件の確認

プロビジョニング・モジュール用プロビジョニング・プロバイダの要件の確認には、次のガイドラインが適用されます。

- ターゲット・システムをOracle Identity Managerで開始されるプロビジョニング操作のターゲットとしてのみ使用する場合、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダのみが必要です。リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダは必要ありません。
汎用テクノロジ・コネクタにプロビジョニング・モジュールを含める場合、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの両方を(いずれかのプロバイダが不要な場合にも)含める必要があります。このガイドラインについては次の例で説明します。

プロビジョニング・フォーマット・プロバイダの機能は、Oracle Identity Managerのデータをターゲット・システムでサポートされている形式に変換するものです。ターゲット・システムでOracle Identity Managerの出力データ・フォーマットがサポートされている場合にも、汎用テクノロジ・コネクタの作成時にはプロビジョニング・フォーマット・プロバイダを含める必要があります。

- 事前定義済プロバイダで対応できないプロバイダ要件に対してのみ、カスタム・プロバイダの作成が必要になります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義済プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。

たとえば、ターゲット・システムがWebサービスであり、SOAPメッセージにパッケージ化されたSPMLベースのプロビジョニング・リクエストの受入れや解析が可能な場合は、SPMLプロビジョニング・フォーマット・プロバイダとWebサービス・プロビジョニング・トランスポート・プロバイダを使用できます。カスタム・プロビジョニング・プロバイダを作成する必要はありません。

関連項目:

プロバイダの再利用

18.2.2 プロバイダ・パラメータの識別

プロバイダ・パラメータとは、プロバイダが目的の機能を実行するために必要な値です。たとえば、プロビジョニング・リクエスト・ファイルをターゲット・システム・サーバーにコピーするプロビジョニング・トランスポート・プロバイダには、ターゲット・システムへの接続に接続パラメータが必要になります。

汎用テクノロジ・コネクタの作成時に、その汎用テクノロジ・コネクタ用に選択するプロバイダのパラメータ値を指定します。

カスタム・プロバイダを作成する場合、そのプロバイダが機能するために必要なパラメータをすべて識別する必要があります。また、このようなパラメータをランタイム・パラメータと設計パラメータに分類する必要もあります。

ランタイム・パラメータは、プロバイダの設計に制約されない値を示します。たとえば、リコンサイルするデータファイルが格納されているディレクトリの場所がランタイム・パラメータ値となります。設計パラメータは、プロバイダ設計の一部として定義される1つまたは複数の値を表します。たとえば、リコンシリエーション・フォーマット・プロバイダで解析可能なキャラクタ・セット・エンコーディングのフォーマットなどは、そのプロバイダの設計パラメータに分類されます。

18.2.3 値オブジェクトのJavaコード実装の開発

表18-1に示す値オブジェクトのJavaコード実装を開発します。前述したように、このような値オブジェクトはプロバイダ操作の様々な段階で使用されます。

注意:

汎用テクノロジ・コネクタに含めない値オブジェクトのJavaコード実装については、開発する必要はありません。

表18-1 プロバイダ操作中に使用される値オブジェクト

使用領域

値オブジェクト

Javadocパッケージ

メタデータの検出

TargetSchema

com.thortech.xl.gc.vo.designtime

OIMSchema

com.thortech.xl.gc.vo.designtime

プロビジョニング

TargetOperation

com.thortech.xl.gc.vo.runtime

リコンシリエーション

TargetRecord

com.thortech.xl.gc.vo.runtime

OIMRecord

com.thortech.xl.gc.vo.runtime

18.2.4 プロバイダSPIメソッドのJavaコード実装の開発

プロバイダ操作中に使用されるSPIメソッドのJavaコード実装を開発します。前述したように、SPIメソッドはプロバイダ操作の様々な段階で呼び出されます。各プロバイダのSPIメソッドの情報へのリンクは、JavadocのPackage com.thortech.xl.gc.spiのページを参照してください。

注意:

汎用テクノロジ・コネクタに含めないプロバイダのSPIメソッドのJavaコード実装については、開発する必要はありません。

18.2.5 ロギングおよび例外処理のJavaコードの開発

値オブジェクトおよびSPIメソッドのJavaコード実装には、ロギング機能を組み込むことをお薦めします。これにより、プロバイダ使用時に発生する可能性のあるエラーのトラブルシューティングを簡略化できます。

汎用テクノロジ・コネクタ・フレームワーク用のロギング・モジュールは、Oracle Identity Managerのロギング拡張機能です。表18-2に、サポートされている各プロバイダ・タイプ固有のモジュールを示します。

表18-2 サポートされる各プロバイダ・タイプに固有のロギング・モジュール

ロギング・モジュール

汎用テクノロジ・コネクタ・フレームワークの機能モジュール

XELLERATE.GC.PROVIDER.PROVISIONINGFORMAT

プロビジョニング・フォーマット・プロバイダ

XELLERATE.GC.PROVIDER.PROVISIONINGTRANSPORT

プロビジョニング・トランスポート・プロバイダ

XELLERATE.GC.PROVIDER.RECONCILIATIONTRANSPORT

リコンシリエーション・トランスポート・プロバイダ

XELLERATE.GC.PROVIDER.RECONCILIATIONFORMAT

リコンシリエーション・フォーマット・プロバイダ

XELLERATE.GC.PROVIDER.TRANSFORMATION

変換プロバイダ

XELLERATE.GC.PROVIDER.VALIDATION

検証プロバイダ

カスタム・プロバイダの組込み例外処理の詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

18.2.6 プロバイダXMLファイルの作成

プロバイダXMLファイルには、汎用テクノロジ・コネクタ・フレームワークにプロバイダを登録するために必要なデータが含まれます。プロバイダXMLファイルは必ず作成してください。表18-3に、カスタム・プロバイダのプロバイダXMLファイルに含める要素を示します。

注意:

1つのプロバイダXMLファイルを使用して複数のプロバイダを定義できます。また、作成する各プロバイダについて、それぞれプロバイダXMLファイルを作成することもできます。

プロバイダXMLファイルは、MDSにあるスキーマ定義に従っている必要があります。スキーマおよびプロバイダ定義XMLファイルは、次の場所にあります。

PROVIDER_DEF_XSD_LOCATION = "/db/GTC/Schema";

PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions";

表18-3 プロバイダXMLファイルの要素

要素

説明

Provider

プロバイダXMLファイルのルート要素

Reconciliation

リコンシリエーション・プロバイダの記述に使用する構成要素の親要素

Provisioning

プロビジョニング・プロバイダの記述に使用する構成要素の親要素

Transformation

変換プロバイダの記述に使用する構成要素の親要素

Validation

検証プロバイダの記述に使用する構成要素の親要素

ReconTransportProvider

リコンシリエーション・トランスポート・プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

name: プロバイダの名前

class: プロバイダ実装のJavaクラスの名前

ReconFormatProvider

リコンシリエーション・フォーマット・プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

name: プロバイダの名前

class: プロバイダ実装のJavaクラスの名前

ProvFormatProvider

プロビジョニング・フォーマット・プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

- name: プロバイダの名前

- class: プロバイダ実装のJavaクラスの名前

ProvTransportProvider

プロビジョニング・トランスポート・プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

- name: プロバイダの名前

- class: プロバイダ実装のJavaクラスの名前

TransformationProvider

変換プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

- name: プロバイダの名前

- class: プロバイダ実装のJavaクラスの名前

ValidationProvider

検証プロバイダの記述に使用する構成要素の親要素

この要素には次の属性があります。

- name: プロバイダの名前

- class: プロバイダ実装のJavaクラスの名前

Configuration

あらゆるタイプのプロバイダの構成要素の親要素

Parameter

プロバイダのパラメータに関する情報を提供する要素

Parameter要素には次の属性があります。

- type: パラメータのタイプ(RuntimeまたはDesigntime)。

- datatype: パラメータのデータ型(StringまたはBoolean)。ブール以外のデータ型のパラメータはすべて文字列で表す必要があります。

- required: パラメータが必須であるかどうかの指定。

- encrypted: パラメータの表示を暗号化するかどうかの指定。

- name: パラメータの名前。

- datalength: パラメータ値の文字数。

DefaultAttribute

Configuration要素の子要素

この要素は、ProvFormatProvider要素にのみ含める必要があります。属性は次のとおりです。

- datatype: パラメータのデータ型(StringまたはBoolean)。ブール以外のデータ型のパラメータはすべて文字列で表す必要があります。

- name: パラメータの名前。

- encrypted: パラメータの表示を暗号化するかどうかの指定。

- size: デフォルトの属性のサイズ。

プロビジョニング・リクエストに含めるデータ属性の一部は、プロビジョニング操作を正常に完了するために不可欠なものです。プロビジョニング・フォーマット・プロバイダでは最終的なプロビジョニング入力データ・フォーマットが生成されるため、このプロバイダの定義にはこのような必須データ属性を含める必要があります。したがって、このような属性がターゲット・システムで必要な場合は、プロビジョニング・フォーマット・プロバイダXMLファイルでDefaultAttribute要素を使用して定義する必要があります。

Response

Configuration要素の子要素

この要素はProvFormatProvider、ProvTransportProvider、TransformationProviderおよびValidationProvider要素にのみ含める必要があります。この要素は、プロビジョニング・エンジンによって呼び出されたプロバイダから返されたレスポンスを表します。このレスポンスは、「アイデンティティ・システム管理」に表示されます。この要素には次の属性があります。

- code: Oracle Identity Managerで生成されるプロセス・タスクのレスポンス・コードに対応

- description: Oracle Identity Managerで生成されるプロセス・タスクのレスポンス・コードの説明に対応

注意:

プロビジョニング・フォーマット・プロバイダやプロビジョニング・トランスポート・プロバイダでは、ProvFormatProvider要素またはProvTransportProvider要素のname属性の文字数と、Response要素の文字数の合計を70文字以下にする必要があります。文字数の合計が70文字を超えると、レスポンス・コードをデータベースに格納できなくなり、エラーが発生します。

関連項目:

ファイルのエクスポートおよびOracle Identity Managerメタデータの変更の詳細は、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。

18.2.7 プロバイダのリソース・バンドル・エントリの作成

リソース・バンドルとは、ロケール固有のテキスト文字列を含むファイルのことです。このようなテキスト文字列は、実行時にOracle Identity Managerで読み込まれ、「アイデンティティ・システム管理」にGUI要素のラベルやメッセージとして表示されます。リソース・バンドルのファイル拡張子は.propertiesです。

サポートされる各言語のリソース・バンドルは、Oracle Identity Managerのインストール中にOracle Identity Managerサーバーにコピーされます。これには事前定義済プロバイダのリソース・バンドルも含まれます。

カスタム・プロバイダの場合、使用する各ロケールに応じたリソース・バンドル・エントリを作成する必要があります。リソース・バンドルの作成手順の概要を次に示します。

1. テキスト・エディタで新規ファイルを開きます。

2. このファイルに、次のテキスト文字列のエントリを作成します。

注意:

- リソース・バンドルでは、各行の一部として等号記号(=)の後にローカライズしたテキストを記述します。

- この項で説明するProvider_Type、Parameter_NameおよびRESPONSE_CODEのそれぞれの値は、第18.2.6項「プロバイダXMLファイルの作成」で説明する手順の実行時にプロバイダXMLファイルに指定する値と同じである必要があります。

- プロバイダ名
プロバイダ名は次の形式で記述します。

gc.provider.Provider_Type.Provider_Name=Label_string_in_the_required_language

プロビジョニング・フォーマット・プロバイダのプロバイダ名エントリは、英語では次のようになります。

gc.provider.ProvFormatProvider.SPML=SPML

- プロバイダ・パラメータのラベルおよび説明
プロバイダのパラメータのラベルおよびその説明は、次の形式で記述します。

gc.Provider_Type.Provider_Name.Parameter_Name.label=Parameter_label_in_the_required_language
gc.Provider_Type.Provider_Name.Parameter_Name.description=Parameter_description_in_the_required_language

プロビジョニング・フォーマット・プロバイダのプロバイダ・パラメータのラベルおよびその説明エントリは、英語では次のようになります。

gc.ProvFormatProvider.SPML.targetID.label=Target ID
gc.ProvFormatProvider.SPML.targetID.description=Target ID of the provisioning target

- レスポンス・コードおよび説明
レスポンス・コードおよび説明は、次の形式で記述します。

GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE=Response_code_in_the_required_language
GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE.description=Description_in_the_required_language

プロビジョニング・フォーマット・プロバイダのレスポンス・コードおよび説明のエントリは、英語では次のようになります。

GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ=SPML Velocity Properties Not Read
GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ.description=Necessary SPML template properties could not be read.

- メタデータの検出のエラー・メッセージ
メタデータの検出のエラー・メッセージは、次の形式で記述します。

gc.error.Provider_Type.Provider_Name.ERROR_CODE=Error_Description

ここで、ERROR_CODEは例外クラスのコンストラクタに引数として渡されるerrorCode文字列の値と同じである必要があります。たとえば、ReconciliationTransportExceptionクラスのコンストラクタの1つを次に示します。

ReconciliationTransportException(java.lang.String errorCode, java.lang.String isMessage)

リソース・バンドルでは、errorCode文字列に考えられるすべての値のための行を追加する必要があります。

リコンシリエーション・トランスポート・プロバイダのメタデータの検出エラー・メッセージは、英語では次のようになります。

gc.error.ReconTransportProvider.SharedDrive.NO_READ_FILE=There are no readable files to detect metadata.

3. リソース・バンドルを保存して閉じます。

18.2.8 プロバイダのデプロイ

プロバイダをデプロイするには、次の手順を実行します。

1. JARファイルを次のようにデプロイします。

1. Javaコード・ファイルをすべてコンパイルし、JARファイルにパッケージ化します。

2. JARファイルを次のディレクトリにコピーします。

OIM_HOME/JavaTasks

また、JARファイルをOracle Identity Managerデータベースにアップロードします。詳細は、「カスタム・プロバイダのデプロイ」を参照してください。

注意:

クラスタ化されている環境では、作成するそれぞれのファイルをクラスタの各ノードの対応ディレクトリにコピーする必要があります。

2. プロバイダXMLファイルを次のようにデプロイします。

1. プロバイダXMLファイルを次の場所のMDSにアップロードします。
PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions":

2. Oracle Identity Managerを再起動します。

3. 次のようにプロバイダXMLファイルが正しく登録されているかどうかを確認します。
i. Oracle Identity System Administrationにログインします。

ii. 「構成」の下で、「汎用コネクタ」をクリックします。「作成」をクリックします。プロバイダXMLファイルでエラーが発生した場合は、エラー・メッセージが表示されます。

エラー・メッセージが表示される場合、XMLファイル内で問題を修正し、Oracle Identity Managerを再起動して手順iと手順iiを繰り返します。

この手順は「作成」をクリックしてもエラー・メッセージが表示されなくなるまで繰り返します。

3. プロバイダのリソース・バンドルを次のようにデプロイします。

1. OIM_HOME/bin/ディレクトリにあるUploadResourceBundles.shユーティリティを使用して、リソース・バンドルをMDSにアップロードします。ユーティリティの実行の詳細は、「JARおよびリソース・バンドルの移行」を参照してください。

2. 新しいリソース・バンドル・エントリを有効にするには、PurgeCacheスクリプトを実行するか、アプリケーション・サーバーを再起動します。

18.3 プロバイダの再利用

フォーマット・プロバイダとトランスポート・プロバイダはペアで機能します。リコンシリエーション中、リコンシリエーション・トランスポート・プロバイダの出力がリコンシリエーション・フォーマット・プロバイダに渡されます。プロビジョニングの実行中には、プロビジョニング・フォーマット・プロバイダの出力がプロビジョニング・トランスポート・プロバイダに渡されます。つまり、トランスポート・プロバイダとフォーマット・プロバイダの実装は、この間で渡される値オブジェクトの実装を介してリンクしています。この依存性は、フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインの基礎となります。

一方、検証プロバイダまたは変換プロバイダには、このような他のプロバイダへの依存性はありません。このため、検証プロバイダおよび変換プロバイダの再利用に関するガイドラインはありません。事前定義済およびカスタムの変換プロバイダと検証プロバイダのアクションはターゲット・システムのデータ・フォーマットやデータ転送メカニズムに固有のものではないため、これらのプロバイダの両方を再利用できます。

フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインは、次の各項に分けて説明します。

- リコンシリエーション・プロバイダの再利用

- プロビジョニング・プロバイダの再利用

18.3.1 リコンシリエーション・プロバイダの再利用

第18.1.2項「リコンシリエーション中のプロバイダの役割」で説明するように、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの間のデータ交換には、TargetRecord値オブジェクトが使用されます。リコンシリエーション・トランスポート・プロバイダにより、リコンシリエーション中にフェッチされたターゲット・システム・レコードに対してTargetRecord値オブジェクトの配列が作成されます。その後、リコンシリエーション・フォーマット・プロバイダにより、値オブジェクト配列のデータが処理され、リコンシリエーション・エンジンに渡されます。

ユーザーの組織の操作環境に、TS1およびTS2という2つのターゲット・システムがあるとします。TS1では、リコンシリエーション中のデータ抽出にWebベースのインタフェースを利用できます。TS2では、そのアイデンティティ・ストアのデータを他のアプリケーションで読み取れるようにするAPIが用意されています。どちらのターゲット・システムでも同じデータ・フォーマットがサポートされています。両方のターゲット・システムのユーザー・データをリコンサイルする場合、各ターゲット・システムに対して汎用テクノロジ・コネクタを1つずつ作成する必要があります。それぞれの汎用テクノロジ・コネクタには、リコンシリエーション・トランスポート・プロバイダを作成する必要があります。ただし、リコンシリエーション・フォーマット・プロバイダは、それぞれの汎用テクノロジ・コネクタに対して作成するのではなく、1つのみ作成してそれを再利用できます。同様に、TS1およびTS2で(同じデータ・フォーマットをサポートしていない場合でも)同じデータ転送メカニズムがサポートされていれば、リコンシリエーション・トランスポート・プロバイダを再利用して別のリコンシリエーション・フォーマット・プロバイダを作成することが可能です。

リコンシリエーション・トランスポート・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・フォーマット・プロバイダで実行される関数に固有のコードが含まれないようにしてください。リコンシリエーション・フォーマット・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・トランスポート・プロバイダで実行される関数に固有のコードが含まれないようにしてください。

事前定義リコンシリエーション・プロバイダの再利用

共有ドライブ・リコンシリエーション・トランスポート・プロバイダおよびCSVリコンシリエーション・フォーマット・プロバイダの実装は事前定義済プロバイダであり、データ・フォーマットと単一のデータ転送メカニズムの固定の組合せ向けに作成されています。共有ドライブ・リコンシリエーション・トランスポート・プロバイダでは、フラット・ファイルからデータを読み取り、CSVリコンシリエーション・フォーマット・プロバイダにTargetRecord値オブジェクトの配列を渡します。

共有ドライブ・リコンシリエーション・トランスポート・プロバイダの実装は、ページ化リコンシリエーションと複数値(子)データ・リコンシリエーションという2つの要素に基づきます。これらの要素では、TargetRecord値オブジェクトの配列を作成する前に、プロバイダでのターゲット・システムのデータ解析を可能にする必要があります。つまり、共有ドライブ・リコンシリエーション・トランスポート・プロバイダではターゲット・システム・データの特定の型を解析でき、CSVリコンシリエーション・フォーマット・プロバイダには共有ドライブ・リコンシリエーション・トランスポート・プロバイダから提供される出力のみを使用できるため、相互依存の関係になっています。そのため、CSVリコンシリエーション・フォーマット・プロバイダのパラメータは、共有ドライブ・リコンシリエーション・トランスポート・プロバイダのパラメータとバンドルされています。

このような理由のため、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとカスタム・リコンシリエーション・フォーマット・プロバイダは併用できず、またCSVフォーマット・プロバイダとカスタム・リコンシリエーション・トランスポート・プロバイダは併用できません。

18.3.2 プロビジョニング・プロバイダの再利用

第18.1.3項「プロビジョニング中のプロバイダの役割」で説明するように、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの間のデータ交換には、TargetOperation値オブジェクトが使用されます。プロビジョニング・フォーマット・プロバイダで、ターゲット・システムへの送信用にプロビジョニング・データからTargetOperation値オブジェクトが作成されます。次にプロビジョニング・トランスポート・プロバイダで、この値オブジェクトがターゲット・システムに渡されます。

ユーザーの組織の操作環境に、TS1およびTS2という2つのターゲット・システムがあるとします。TS1では、プロビジョニング・リクエスト・データの受信にWebベースのインタフェースを利用できます。TS2では、そのアイデンティティ・ストアにプロビジョニング・データを書き込めるようにするAPIが用意されています。どちらのターゲット・システムでも同じデータ・フォーマットがサポートされています。両方のターゲット・システムでプロビジョニング操作を実行する場合、各ターゲット・システムに対して汎用テクノロジ・コネクタを1つずつ作成する必要があります。それぞれの汎用テクノロジ・コネクタには、プロビジョニング・トランスポート・プロバイダを作成する必要があります。ただし、プロビジョニング・フォーマット・プロバイダは、各汎用テクノロジ・コネクタに対して作成するのではなく、1つのみ作成してそれを再利用できます。

TS1およびTS2でサポートされているデータ転送メカニズムが同じであり、データ・フォーマットがそれぞれ異なる場合、プロビジョニング・トランスポート・プロバイダを再利用して別のプロビジョニング・フォーマット・プロバイダを作成できます。

プロビジョニング・トランスポート・プロバイダを再利用する場合は、TargetOperation値オブジェクトの実装に、プロビジョニング・フォーマット・プロバイダで実行される関数に固有のコードが含まれないようにしてください。プロビジョニング・フォーマット・プロバイダを再利用する場合は、TargetOperation値オブジェクトの実装に、プロビジョニング・トランスポート・プロバイダで実行される関数に固有のコードが含まれないようにしてください。

事前定義プロビジョニング・プロバイダの再利用

ターゲット・システムがWebサービスである場合は、作成したカスタム・プロビジョニング・フォーマット・プロバイダとWebサービス・プロビジョニング・トランスポート・プロバイダを使用できます。次に、この例を示します。

このマニュアルで前述したように、SPMLプロビジョニング・フォーマット・プロバイダではSPML仕様に従って記述されているプロビジョニング操作のサブセットのみがサポートされます。あらゆるSPMLプロビジョニング操作をサポートする、カスタム・プロビジョニング・フォーマット・プロバイダを開発できます。ターゲット・システムがWebサービスの場合、Webサービス・プロビジョニング・トランスポート・プロバイダを使用して、カスタム・プロビジョニング・フォーマット・プロバイダからターゲット・システムにSPMLリクエストを送信できます。

同様に、SPMLプロビジョニング・フォーマット・プロバイダとカスタム・プロビジョニング・トランスポート・プロバイダを併用して、SPMLリクエストをSPMLベースのターゲット・システムに送信することもできます。

SPMLプロビジョニング・フォーマット・プロバイダで作成され、Webサービス・プロビジョニング・トランスポート・プロバイダの入力として使用されるTargetOperation値オブジェクトの実装について、次に示します。

com.thortech.xl.gc.impl.prov.WSTransportTargetOperation

このクラスの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

SPMLプロビジョニング・フォーマット・プロバイダを再利用する場合、このクラスのインスタンスを入力として受け入れ、関連するsetメソッドを呼び出すカスタム・トランスポート・プロバイダを作成する必要があります。同様に、Webサービス・プロビジョニング・トランスポート・プロバイダを再利用する場合、このクラスのインスタンスを作成し、関連するgetメソッドを呼び出すカスタム・プロビジョニング・フォーマット・プロバイダを作成する必要があります。

18.4 カスタム・プロバイダのデプロイ

カスタム・プロバイダをデプロイするには、次の手順を実行します。

1. プロバイダ定義XMLファイルをMDSの場所/db/GTC/ProviderDefinitionsにアップロードします。Oracle Identity Managerでは、MDSリポジトリとの間でデータをエクスポート/インポートするためのユーティリティが提供されます。
MDSユーティリティの詳細は、第36章「カスタマイズ・タイプの理解」を参照してください。

2. プロバイダ・リソース・バンドルおよびJARファイルをOracle Identity Managerデータベースにアップロードする必要があります。リソース・バンドルおよびJARファイルをOracle Identity Managerデータベースにアップロードするユーティリティは、OIM_HOME/bin/ディレクトリにあります。
リソース・バンドルのアップロード・ユーティリティおよびJARユーティリティの詳細は、第37章「カスタマイズのデプロイおよびアンデプロイ」を参照してください。

19 汎用テクノロジ・コネクタの作成および管理

この章では、汎用テクノロジ・コネクタを作成および管理する方法について説明します。これらの項目が含まれます。

- 概要

- 汎用テクノロジ・コネクタの作成

- 汎用テクノロジ・コネクタの管理

- カスタム・コネクタでの汎用接続プール・フレームワークの使用

- ベスト・プラクティス

19.1 概要

プロバイダは、汎用テクノロジ・コネクタを作成するための開始点となります。Oracle Identity Managerには、汎用テクノロジ・コネクタのビルディング・ブロックとして使用できるプロバイダの標準セットが用意されています。これらのプロバイダの詳細は、第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」を参照してください。

適切なプロバイダがない場合は、要件に合せてプロバイダを作成できます。詳細は、第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」を参照してください。

最後に、汎用テクノロジ・コネクタが統合要件を満たさない場合は、アダプタで利用可能なプログラム的なオプションを使用できます。詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

19.2 汎用テクノロジ・コネクタの作成

この項では、汎用テクノロジ・コネクタを作成する方法について説明します。

汎用テクノロジ・コネクタの作成手順は、次のステップで構成されています。

- プロバイダ要件の確認

- 組み込むプロバイダの選択

- 前提条件への対応

- Identity System Administrationを使用したコネクタの作成

- リコンシリエーションの構成

- プロビジョニングの構成

- フォームの作成とアプリケーション・インスタンスの公開

- ロギングの有効化

19.2.1 プロバイダ要件の確認

第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」で説明したように、作成する汎用テクノロジ・コネクタのビルディング・ブロックとして次のプロバイダを使用できます。

- リコンシリエーション・トランスポート・プロバイダ

- リコンシリエーション・フォーマット・プロバイダ

- プロビジョニング・トランスポート・プロバイダ

- プロビジョニング・フォーマット・プロバイダ

- 変換プロバイダ

- 検証プロバイダ

これらのプロバイダの定義については、第16.2項「汎用テクノロジ・コネクタの機能アーキテクチャ」を参照してください。次に、ターゲット・システムがサポートしているデータ形式とデータ・トランスポート・メカニズムの知識に基づいて、作成する汎用テクノロジ・コネクタに組み込む必要のあるプロバイダを識別します。ターゲット・システムが複数のデータ形式とデータ・トランスポート・メカニズムをサポートしている場合は、最初の章で説明したトランスポート・プロバイダとフォーマット・プロバイダの1つの組合せを選択する必要があります。たとえば、1つの汎用テクノロジ・コネクタに複数のリコンシリエーション・フォーマット・プロバイダを組み込むことはできません。

関連項目:

第19.2.1項「プロバイダ要件の確認」

19.2.2 組み込むプロバイダの選択

プロバイダ要件に適合する事前定義済のプロバイダを識別します。事前定義済プロバイダの詳細は、第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」を参照してください。

事前定義済プロバイダでプロバイダ要件のすべてに対応できる場合は、カスタム・プロバイダを作成する必要はありません。事前定義済プロバイダで対応できないプロバイダ要件に対してのみ、カスタム・プロバイダの作成が必要になります。カスタム・プロバイダの作成方法は、第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」を参照してください。

19.2.3 前提条件への対応

次の前提条件に対応する必要があります。

- 本番サーバーで汎用テクノロジ・コネクタを作成する場合は、次のキャッシュ・カテゴリのキャッシュを有効化します。

- GenericConnector

- GenericConnectorProviders

- ターゲット・システム・サーバーとOracle Identity Managerサーバーの接続性のテスト
ターゲット・システム・サーバーとOracle Identity Managerサーバーの間で接続を確立できるようにする必要があります。たとえば、UNIX環境では、ターゲット・システム・サーバーの/etc/hostsファイルにOracle Identity Managerサーバーの完全修飾ホスト名を入力する必要があります。

- 汎用テクノロジ・コネクタの作成に使用するユーザー・アカウントの作成
Oracle Identity ManagerのSYSTEM ADMINISTRATORSグループに属するすべてのユーザーが汎用テクノロジ・コネクタを作成できます。また、必要なメニュー項目と権限を割り当てられているグループのメンバーが汎用テクノロジ・コネクタを作成できます。

必要なメニュー項目は次のとおりです。

- 汎用テクノロジ・コネクタの作成メニュー項目

- 汎用テクノロジ・コネクタの管理メニュー項目

必要な権限は次のとおりです。

- フォーム・デザイナ(挿入の許可、書込み権限、削除権限)

- 構造ユーティリティ.追加列(挿入の許可、書込み権限、削除権限)

- メタ表の階層(挿入の許可、書込み権限、削除権限)

これらの権限がグループに適切に割り当てられていない場合は、汎用テクノロジ・コネクタを作成する際に、Identity System Administrationの最後のページで「作成」ボタンをクリックするとエラーが発生します。

19.2.4 Identity System Administrationを使用したコネクタの作成

汎用テクノロジ・コネクタを作成するIdentity System Administrationの最初のページに移動するには、Identity System Administrationにログインして、「構成」の下の「汎用コネクタ」をクリックします。「コネクタの管理」ページで、「作成」をクリックします。

これ以降の後続の項でページごとに説明します。

- 「ステップ1: 基本情報の指定」ページ

- 「ステップ2: パラメータ値の指定」ページ

- 「ステップ3: コネクタ構成の変更」ページ

- 「ステップ4: コネクタ・フォーム名の検証」ページ

- 「ステップ5: コネクタ情報の検証」ページ

19.2.4.1 「ステップ1: 基本情報の指定」ページ

作成する汎用テクノロジ・コネクタの基本情報を指定するには、このページを使用して次の手順を実行します。

1. 「名前」フィールドで汎用テクノロジ・コネクタの名前を指定します。
汎用テクノロジ・コネクタの名前選択に関するガイドラインを次に示します。

- このOracle Identity Managerインストールで使用されている他のコネクタ(事前定義済コネクタまたは汎用テクノロジ・コネクタ)と同じ名前を指定することはできません。

- このOracle Identity Managerインストールで使用されている他のコネクタ・オブジェクト(リソース・オブジェクト、ITリソース、プロセス・フォームなど)と同じ名前を指定することはできません。

注意:

既存のコネクタと同じ名前を指定するとエラー・メッセージが表示されます。ただし、既存のコネクタ・オブジェクトと同じ名前を指定してもエラー・メッセージは表示されません。そのため、指定する名前が既存のコネクタ・オブジェクトの名前と同じでないことを確認する必要があります。

汎用テクノロジ・コネクタの作成プロセスの一環として自動作成されるコネクタ・オブジェクトの詳細は、第16.4項「汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト」を参照してください。

- Oracle Identity Managerではコネクタ名が非ASCII文字に対応していないため、コネクタ名に非ASCII文字は使用できません。ただし、アンダースコア文字(_)は名前に使用できます。

関連項目:

汎用テクノロジ・コネクタの名前に関する制限事項については、第20.2.1項「汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前」を参照してください。

2. リコンシリエーションに汎用テクノロジ・コネクタを使用する場合は、「リコンシリエーション」を選択して次の手順を実行します。

- このコネクタで使用するリコンシリエーション・トランスポート・プロバイダは、「トランスポート・プロバイダ」リストで選択します。このリストには、事前定義済のリコンシリエーション・トランスポート・プロバイダと作成するリコンシリエーション・トランスポート・プロバイダが表示されます。

- このコネクタで使用するリコンシリエーション・フォーマット・プロバイダは、「フォーマット・プロバイダ」リストで選択します。このリストには、事前定義済のリコンシリエーション・フォーマット・プロバイダと作成するリコンシリエーション・フォーマット・プロバイダが表示されます。

注意:

共有ドライブ・リコンシリエーション・トランスポート・プロバイダを選択する場合は、CSVリコンシリエーション・フォーマット・プロバイダも選択する必要があります(これは、このプロバイダのすべてのパラメータが、共有ドライブ・リコンシリエーション・トランスポート・プロバイダのパラメータにバンドルされているためです)。

- コネクタを使用して信頼できるソース・リコンシリエーションをターゲット・システムに対して実行する場合は、「信頼できるソース・リコンシリエーション」を選択します。

注意:

「信頼できるソース・リコンシリエーション」チェック・ボックスを選択すると、このページの「プロビジョニング」リージョンは無効になります。これは、信頼できるソースとして指定したターゲット・システムではプロビジョニングを実行できないためです。信頼できるソースによるデータのリコンサイルのみが可能です。

3. プロビジョニングに汎用テクノロジ・コネクタを使用する場合は、「プロビジョニング」を選択して次の手順を実行します。

注意:

「リコンシリエーション」のみ、「プロビジョニング」のみ、または「リコンシリエーション」と「プロビジョニング」の両方を選択できます。

- このコネクタで使用するプロビジョニング・トランスポート・プロバイダは、「トランスポート・プロバイダ」リストで選択します。このリストには、事前定義済のプロビジョニング・トランスポート・プロバイダと作成するプロビジョニング・トランスポート・プロバイダが表示されます。
Webサービス・プロビジョニング・トランスポート・プロバイダを選択し、ターゲットのWebサービスでSecure Sockets Layer (SSL)が有効化されている場合は、第17.4.1項「Oracle Identity Managerとターゲット・システムWebサービスの間のSSL通信の構成」に記載されている手順を実行する必要があります。

- このコネクタで使用するプロビジョニング・フォーマット・プロバイダは、「フォーマット・プロバイダ」リストで選択します。このリストには、事前定義済のプロビジョニング・フォーマット・プロバイダと作成するプロビジョニング・フォーマット・プロバイダが表示されます。
SPMLプロビジョニング・フォーマット・プロバイダを選択する場合は、Webサービス・プロビジョニング・トランスポート・プロバイダも選択する必要があります(これは、このプロバイダのパラメータが、Webサービス・プロビジョニング・トランスポート・プロバイダのパラメータに関連しているためです)。

4. 「続行」をクリックします。

表19-1に、「ステップ1: 基本情報の指定」ページのGUI要素のサンプル・エントリを示します。

表19-1 「ステップ1: 基本情報の指定」ページのサンプル・エントリ

「ステップ1: 基本情報の指定」ページのラベル

サンプル値またはアクション

参照情報

「名前」フィールド

MyGTC2

該当なし

「リコンシリエーション」チェック・ボックス

チェック・ボックス選択

該当なし

「トランスポート・プロバイダ」リスト

共有ドライブ

共有ドライブ・リコンシリエーション・トランスポート・プロバイダ

「フォーマット・プロバイダ」リスト

CSV

CSVリコンシリエーション・フォーマット・プロバイダ

「プロビジョニング」チェック・ボックス

チェック・ボックス選択

該当なし

「トランスポート・プロバイダ」リスト

Webサービス

Webサービス・プロビジョニング・トランスポート・プロバイダ

「フォーマット・プロバイダ」リスト

SPML

SPMLプロビジョニング・フォーマット・プロバイダ

19.2.4.2 「ステップ2: パラメータ値の指定」ページ

このページを使用して、「ステップ1: 基本情報の指定」ページで選択したプロバイダのパラメータ値を指定します。

このページでは、プロバイダのパラメータは次の2つのカテゴリに分けられます。

- ランタイム・パラメータ

関連項目:

「ステップ1: 基本情報の指定」ページで選択する事前定義済プロバイダのランタイム・パラメータの詳細は、第17章「汎用テクノロジ・コネクタ用事前定義済プロバイダ」を参照してください。

ランタイム・パラメータは、前のページで選択したプロバイダの入力変数です。ランタイム・パラメータは、プロバイダの設計に制約されない値を示します。たとえば、リコンサイルするデータファイルが格納されているディレクトリの場所がランタイム・パラメータ値となります。

- 設計パラメータ
この項に示すパラメータは、プロバイダの設計パラメータ、またはすべての汎用テクノロジ・コネクタに共通するリコンシリエーション固有パラメータです。設計パラメータは、プロバイダ設計の一部として定義される1つまたは複数の値を表します。

関連項目:

「ステップ1: 基本情報の指定」ページで選択する事前定義済プロバイダの設計パラメータの詳細は、第17章「汎用テクノロジ・コネクタの事前定義済プロバイダ」を参照してください。

例:

フォーマット・プロバイダで解析可能なデータファイルの形式がこのプロバイダの設計パラメータとなります。プロバイダの設計時に、そのプロバイダが解析可能な一連の形式を定義します。「ステップ2: パラメータ値の指定」ページで、フォーマット・プロバイダのインスタンスが解析する必要のある特定の形式を(サポートしている形式のセットの中から)指定します。

次に、リコンシリエーション固有の設計パラメータを示します。

注意:

前のページで「リコンシリエーション」オプションを選択していない場合、リコンシリエーション固有の設計パラメータはこのページに表示されません。

- バッチ・サイズ
このパラメータを使用して、リコンシリエーション実行のバッチ・サイズを指定します。このパラメータを使用することで、各リコンシリエーションの実行中に、リコンシリエーション・エンジンによりターゲット・システムからフェッチされるレコードの合計数をバッチに分けられます。

このパラメータのデフォルト値はAllです。

- リコンシリエーション停止のしきい値
リコンシリエーション中、検証プロバイダは、リコンシリエーション・フォーマット・プロバイダからのデータを入力として受け入れます。一部のリコンシリエーション・データ・レコードは、検証チェックを通らない場合があります。「リコンシリエーション停止のしきい値」パラメータを使用すると、処理済のリコンシリエーション・レコード総数に対する検証チェックを通らなかったレコードの割合が指定値を超えた場合に、リコンシリエーションを自動的に停止できます。

次に、このパラメータの使用例を示します。

「リコンシリエーション停止のしきい値」パラメータの値として20を指定したとします。この場合は、処理済のレコード総数に対する失敗したレコードの割合が20%以上になるとリコンシリエーションが停止されます。2番目と8番目のレコードが検証チェックに失敗したとします。この段階で失敗したレコードの数は2、処理されたレコードの総数は8です。失敗したレコードの割合は25%になり、指定したしきい値の20を上回ります。そのため、リコンシリエーションは8番目のレコードの処理後に停止します。

注意:

- 「ステップ3: コネクタ構成の変更」ページで検証プロバイダを選択した場合にのみ、リコンシリエーション中に「リコンシリエーション停止のしきい値」パラメータが使用されます。

- 失敗したレコードの実際の割合が指定した割合を超えたためにリコンシリエーションが停止しても、Oracle Identity Managerにすでにリコンサイルされているレコードは削除されません。

このパラメータのデフォルト値はNoneです。このデフォルト値では、リコンシリエーションの実行中、チェックに失敗したレコード数に関係なくターゲット・システムのレコードをすべて処理するように指定します。

- 停止しきい値最小レコード
「リコンシリエーション停止のしきい値」パラメータを使用した場合、リコンシリエーション実行の開始直後に無効レコードが発生するという問題が発生することがあります。たとえば、「リコンシリエーション停止のしきい値」パラメータの値として40を指定したとします。リコンシリエーションが開始され、最初のレコードが検証チェックに失敗します。この段階で、処理されたレコードの総数に対する失敗したレコードの割合は100%に達します。そのため、リコンシリエーションは最初のレコードの処理後ただちに停止されます。

このような状況を避けるために、「停止しきい値最小レコード」パラメータを「リコンシリエーション停止のしきい値」パラメータと併用できます。「リコンシリエーション停止のしきい値」を有効化する前に、「停止しきい値最小レコード」パラメータで検証プロバイダが処理する必要のあるレコード数を指定します。

次に、このパラメータの使用例を示します。

次の値を指定したとします。

リコンシリエーション停止のしきい値: 20

停止しきい値最小レコード: 80

このように値を指定すると、81番目以降のレコードに対して「リコンシリエーション停止のしきい値」の検証が有効化されます。つまり、80番目のレコードが処理された後にレコードが検証チェックに失敗すると、処理された総レコード数に対する失敗したレコードの割合がリコンシリエーション・エンジンによって計算されます。

このパラメータのデフォルト値はNoneです。

注意:

- 「ステップ3: コネクタ構成の変更」ページで検証プロバイダを選択した場合のみ、リコンシリエーション中に「停止しきい値最小レコード」パラメータが使用されます。

- 「リコンシリエーション停止のしきい値」パラメータの値を指定する場合は、「停止しきい値最小レコード」パラメータの値も指定する必要があります。

- リコンシリエーション・タイプ
このパラメータを使用して、リコンシリエーション・エンジンで増分リコンシリエーションと完全リコンシリエーションのどちらを実行するかを指定します。

注意:

完全リコンシリエーションと増分リコンシリエーションの結果は同じです。すなわち、最後のリコンシリエーション実行後に作成または更新されたターゲット・システムのレコードは、Oracle Identity Managerによってリコンサイルされます。

増分リコンシリエーションでは、前回のリコンシリエーションの実行後に新しく追加または変更されたターゲット・システム・レコードのみが、Oracle Identity Managerにリコンサイルされます。リコンシリエーション・イベントは、これらの各レコードに対して作成されます。

完全リコンシリエーションでは、すべてのターゲット・システム・レコードがOracle Identity Managerにリコンサイルされます。すでにリコンサイル済のレコードは、最適化リコンシリエーション機能によって識別され、無視されます。リコンシリエーション・イベントは、残りのレコードに対して作成されます。

次のいずれかの条件に該当する場合は、増分リコンシリエーションを選択してください。

- ターゲット・システムで生成されるファイルまたは個々のデータ・レコードにタイムスタンプが付けられるか、またはなんらかの方法によって一意のマークが付けられ、タイムスタンプまたはマークが付けられたレコードをリコンシリエーション・トランスポート・プロバイダが認識できる場合
例:

ターゲット・システムでは、ユーザー・データ・レコードの作成または変更時にタイムスタンプを付けることができます。このタイムスタンプ情報の読取りが可能なカスタム・リコンシリエーション・トランスポート・プロバイダを作成すると、新規追加または変更されたデータ・レコードのみがリコンシリエーション中にOracle Identity Managerに転送されます。

- ターゲット・システムが、最後のリコンシリエーション実行後に新規追加または変更されたデータ・レコードのみを提供する場合

いずれの条件にも該当しない場合は、完全リコンシリエーションを選択する必要があります。

- 複数値属性データの削除の調整
このパラメータを使用して、ターゲット・システムの複数値属性データ(子データ)の削除をOracle Identity Managerでリコンサイルするかどうかを指定します。

次に、この設計パラメータの使用例を示します。

ターゲット・システムにユーザーJohn Doeのアカウントがあります。このユーザーは、ターゲット・システムの2つのユーザー・グループ、CREATE USERSとREVIEW PERMISSIONSのメンバーです。このユーザー・アカウント(およびグループ・メンバーシップ情報)は、Oracle Identity Managerにも存在します。

ターゲット・システムでこのユーザーをREVIEW PERMISSIONSグループから削除したとします。次のリコンシリエーション実行中にOracle Identity Managerが行うアクションは、「複数値属性データの削除の調整」チェック・ボックスを選択したかどうかによって異なります。

- このチェック・ボックスを選択した場合、ターゲット・システムのREVIEW PERMISSIONSグループのメンバーであるこのユーザーの情報はOracle Identity Managerデータベースから削除されます。ターゲット・システムのこのユーザー・アカウントに加えられた他の変更もすべてリコンサイルされます。

- このチェック・ボックスを選択しない場合、ターゲット・システムのREVIEW PERMISSIONSグループのメンバーであるこのユーザーの情報はOracle Identity Managerデータベースから削除されません。ただし、ターゲット・システムのこのユーザー・アカウントに加えられた他の変更はすべてリコンサイルされます。

- ソース日付書式
このパラメータを使用して、日付値がターゲット・システムに格納される書式を指定します。

指定する書式は、リコンシリエーション時にフェッチされる日付値を検証し、その日付値をOracle Identity Managerの内部で使用される書式に変換するために使用されます。

日付書式の検証プロバイダは、事前定義されている検証プロバイダの1つです。日付書式の検証プロバイダは、リコンシリエーション実行時に、ターゲット・システムからフェッチした日付値をソース日付書式を使用して検証します。ソース日付書式と一致する日付値のみが、Oracle Identity Managerで使用される日付書式に変換され、リコンサイルされます。このような書式の検証と変換は、ターゲット・システムのすべての日付フィールド(生年月日や入社日など)に適用されます。

関連項目:

検証プロバイダの詳細は、「検証プロバイダ」を参照してください。

指定可能な日付書式の詳細は、Sun Java Webサイトの次のページを参照してください。

http://java.sun.com/docs/books/tutorial/i18n/format/simpleDateFormat.html

注意:

第19.2.4.3.1項「データセットのフィールドの追加または編集」で説明している手順の実行時に、ソース日付書式を日付検証で使用するには、次のようにする必要があります。

- 「ソース」データセットの日付フィールドを「リコンシリエーション・ステージング」データセットの日付フィールドにマップする。

- 「リコンシリエーション・ステージング」データセットの各日付フィールドを編集し、データ型を「日付」データ型に設定する。

「ソース日付書式」パラメータのデフォルト値は、XL.DefaultDateFormatシステム・プロパティの値として指定された日付書式です。「ソース日付書式」パラメータに値を指定しないと、リコンシリエーション時の日付検証でデフォルト日付書式が使用されます。

関連項目:

Oracle Identity Managerのシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する説明を参照してください。

次に「ソース日付書式」パラメータの使用例を示します。

ターゲット・システムに、次のように日付値が設定されているとします。

- Date 1: 05/04/2007 06:25:44 PM

- Date 2: 05/06/2007 07:31:44 PM

- Date 3: Thu, Apr 9, '98

- Date 4: 07/03/2008 02:15:55 PM

使用例1:

コネクタを作成するときに、「ソース日付書式」パラメータに次の値を入力しました。

MM/dd/yyyy hh:mm:ss a

リコンシリエーション実行時に、Date 3の値を含むレコードは、指定したソース日付書式と一致しないためリコンサイルされません。

使用例2:

コネクタを作成するときに、「ソース日付書式」パラメータの値を入力していません。このため、リコンシリエーション実行時に、4つのレコードすべてがXL.DefaultDateFormatシステム・プロパティの値として指定された日付書式に対して検証されます。

次に、プロビジョニング固有の設計パラメータを示します。

注意:

前のページで「プロビジョニング」オプションを選択していない場合、このプロビジョニング固有の設計パラメータは表示されません。

- ターゲット日付書式
このパラメータを使用して、プロビジョニング操作時に日付値をターゲット・システムに送信する書式を指定します。

プロビジョニング操作時には、日付値が「ターゲット日付書式」パラメータの値として指定した書式に変換されます。このような書式の変換は、プロビジョニング操作で使用されるすべての日付フィールド(生年月日や入社日など)に適用されます。

指定可能な日付書式の詳細は、Sun Java Webサイトの次のページを参照してください。

http://java.sun.com/docs/books/tutorial/i18n/format/simpleDateFormat.html

日付書式を指定しない場合は、次の日付書式がこのパラメータのデフォルト値として使用されます。

yyyy/MM/dd hh:mm:ss z

次に「ターゲット日付書式」パラメータの使用例を示します。

プロビジョニング操作では、入力したすべての日付値がyyyy/MM/dd hh:mm:ss z書式になります。

使用例1:

コネクタを作成するときに、「ターゲット日付書式」パラメータに次の値を入力しました。

yyyy.MM.dd G 'at' hh:mm:ss z

プロビジョニング操作では、Oracle Identity Managerの日付値(たとえば2007/05/04 06:25:44 IST)はターゲット日付書式(たとえば2007.05.04 AD at 06:25:44 IST)に変換され、ターゲット・システムに送られます。

使用例2:

コネクタを作成するときに、「ターゲット日付書式」パラメータの値を入力していません。プロビジョニング操作では、日付値はターゲット・システムにデフォルトのyyyy/MM/dd hh:mm:ss z書式で送られます。

ランタイム・パラメータと設計パラメータの値の指定が完了したら、「続行」をクリックします。

注意:

このページで指定した値が正しくない場合は、「続行」をクリックするとページの上部にエラー・メッセージが表示されます。その場合は、パラメータ値を修正してから「続行」を再度クリックします。

表19-2に、「ステップ2: パラメータ値の指定」ページのサンプル・エントリを示します。このページに表示されるGUI要素は、「ステップ1: 基本情報の指定」ページのエントリに基づきます。

表19-2 「ステップ2: パラメータ値の指定」ページのサンプル・エントリ

「ステップ2: パラメータ値の指定」ページのラベル

サンプル値またはアクション

参照情報

共有ドライブ・リコンシリエーション・トランスポート・プロバイダのランタイム・パラメータ

第17.1項「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」

「ステージング・ディレクトリ(親アイデンティティ・データ)」フィールド

D:\gctestdata\commaDelimited\parent

該当なし

「ステージング・ディレクトリ(複数値アイデンティティ・データ)」フィールド

D:\gctestdata\commaDelimited\child

該当なし

「アーカイブ・ディレクトリ」フィールド

D:\gctestdata\commaDelimited\archive

該当なし

「ファイルの接頭辞」フィールド

file

該当なし

「指定されたデリミタ」フィールド

,

該当なし

「タブ区切り」チェック・ボックス

チェック・ボックス選択解除

該当なし

「固定列幅」フィールド

該当なし

「一意の属性(親データ)」フィールド

UserIDTD

該当なし

Webサービス・プロビジョニング・トランスポート・プロバイダのランタイム・パラメータ

第17.4項「Webサービス・プロビジョニング・トランスポート・プロバイダ」

「WebサービスURL」フィールド

http://acme123:8080/spmlws/services/HttpSoap11

該当なし

SPMLプロビジョニング・フォーマット・プロバイダのランタイム・パラメータ

第17.3項「SPMLプロビジョニング・フォーマット・プロバイダ」

「ターゲットID」フィールド

target

該当なし

「ユーザー名(認証)」フィールド

xelsysadm

該当なし

「ユーザー・パスワード(認証)」フィールド

該当なし

共有ドライブ・リコンシリエーション・トランスポート・プロバイダの設計パラメータ

第17.1項「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」

「ファイル・エンコーディング」フィールド

Cp1251

該当なし

Webサービス・プロビジョニング・トランスポート・プロバイダの設計パラメータ

第17.4項「Webサービス・プロビジョニング・トランスポート・プロバイダ」

「WebサービスのSOAPアクション」フィールド

http://xmlns.oracle.com/OIM/provisioning/processRequest

該当なし

SPMLプロビジョニング・フォーマット・プロバイダの設計パラメータ

第17.3項「SPMLプロビジョニング・フォーマット・プロバイダ」

「SPML WebサービスのWSSEが構成されていますか。」チェック・ボックス

チェック・ボックス選択解除

該当なし

「カスタム認証資格証明ネームスペース」フィールド

http://xmlns.oracle.com/OIM/provisioning

該当なし

「カスタム認証ヘッダー要素」フィールド

OIMUser

該当なし

「ユーザー名を格納するカスタム要素」フィールド

OIMUserId

該当なし

「パスワードを格納するカスタム要素」フィールド

OIMUserPassword

該当なし

「SPML Webサービスのバインディング・スタイル(DOCUMENTまたはRPC)」フィールド

RPC

該当なし

「SPML Webサービスの複合データ型」フィールド

該当なし

「SPML Webサービス操作名」フィールド

processRequest

該当なし

「SPML Webサービスのターゲット・ネームスペース」フィールド

http://xmlns.oracle.com/OIM/provisioning

該当なし

「SPML WebサービスのSOAPメッセージ本文の接頭辞」フィールド

該当なし

「グループ・メンバーシップ情報を保持している子データセットのID属性」フィールド

該当なし

汎用設計パラメータ

該当なし

「ターゲット日付書式」フィールド

yyyy-MM-dd hh:mm:ss.fffffffff

該当なし

「バッチ・サイズ」フィールド

すべて

該当なし

「リコンシリエーション停止のしきい値」フィールド

なし

該当なし

「停止しきい値最小レコード」フィールド

なし

該当なし

「ソース日付書式」フィールド

yyyy/MM/dd hh:mm:ss z

該当なし

「複数値属性データの削除の調整」チェック・ボックス

チェック・ボックス選択

該当なし

「リコンシリエーション・タイプ」リスト

増分

該当なし

19.2.4.3 「ステップ3: コネクタ構成の変更」ページ

このページを使用して、データセットやデータセットのフィールド間のマッピングを定義します。つまり、次の処理を行うユーザー・データ・フィールドをこのページで指定します。

- リコンシリエーション時のターゲット・システムからOracle Identity Managerへの伝播

- プロビジョニング時のOracle Identity Managerからターゲット・システムへの伝播

汎用テクノロジ・コネクタのコンテキストでは、メタデータという用語は、ターゲット・システム上のユーザー・アカウント情報を構成する一連のアイデンティティ・フィールドを意味します。

「名」、「姓」、「入社日」および「部門ID」は、メタデータを構成するユーザー・データ・フィールドの例です。これらのフィールドに割り当てられる値が、ターゲット・システムのユーザー・データを構成します。たとえば、ターゲット・システム上のユーザーJohn Doeのアイデンティティ情報は次のようなフィールドで構成されます。

- 名: John

- 姓: Doe

- 入社日: 04-December-2007

- 部門ID: Sales

- . . .

「ステップ2: パラメータ値の指定」ページで「続行」ボタンをクリックした後に「ステップ3: コネクタ構成の変更」ページに表示されるメタデータは、次の要因によって決まります。

- 「ステップ1: 基本情報の指定」ページおよび「ステップ2: パラメータ値の指定」ページの入力内容

- ターゲット・システムのサンプル・データの可用性

注意:

汎用テクノロジ・コネクタのコンテキストでは、メタデータの検出という用語は、サンプルのユーザー・データがターゲット・システムから読み取られ、対応するメタデータ(アイデンティティ・フィールド名)が「ステップ3: コネクタ構成の変更」ページに表示されるプロセスを意味します。

Oracle Identity Managerでは、メタデータの検出の試行中に次の手順が実行されます。

1. リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダでは、ターゲット・システムからメタデータのフェッチおよび解析が試行されます。
同時に、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダでは、ターゲット・システムからメタデータを検出できます。カスタム・プロバイダで同じ機能を実行する場合は、次の要件を満たす必要があります。

- リコンシリエーション・トランスポート・プロバイダのJavaコードに、ReconTransportProviderインタフェースのgetMetadata()メソッドが実装されていること

- リコンシリエーション・フォーマット・プロバイダのJavaコードに、ReconFormatProviderインタフェースのparseMetadata()メソッドが実装されていること

関連項目:

第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」

これらのプロバイダがターゲット・システムからメタデータをフェッチして解析すると、Oracle Identity Managerはこれらのプロバイダが戻した情報を使用してメタデータを表示し、この場合、次の手順は実行されません。

2. リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダで、ターゲット・システムからメタデータをフェッチおよび解析できない場合は、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダでこの機能の実行が試行されます。
Webサービス・プロビジョニング・トランスポート・プロバイダとSPMLプロビジョニング・フォーマット・プロバイダでは、ターゲット・システムからメタデータを検出できません。カスタム・プロバイダでメタデータを検出できるようにするには、次の要件を満たす必要があります。

- プロビジョニング・トランスポート・プロバイダのJavaコードに、ProvisioningTransportProviderインタフェースのdefineMetadata()メソッドが実装されていること

- プロビジョニング・フォーマット・プロバイダのJavaコードに、ProvisioningFormatProviderインタフェースのparseMetadata()メソッドが実装されていること

プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダがターゲット・システムからメタデータをフェッチおよび解析すると、Oracle Identity Managerはこれらのプロバイダが戻した情報を使用してメタデータを表示します。これらのプロバイダが失敗した場合、選択したプロビジョニング固有のプロバイダのいずれかに定義されたデフォルト・フィールドのみが表示されます。たとえば、「OIM - アカウント」データセットのIDフィールドや、「プロビジョニング・ステージング」データセットのobjectClassフィールドおよびcontainerIDフィールドがデフォルトで表示されます。これらのデータセットおよびフィールドについては後述します。

図19-1の「ステップ3: コネクタ構成の変更」ページは、「「ステップ1: 基本情報の指定」ページ」と「「ステップ2: パラメータ値の指定」ページ」の最後に記載したサンプル・エントリを示しています。

図19-1 「ステップ3: コネクタ構成の変更」ページ

- データセット

- マッピング

データセット

「ステップ3: コネクタ構成の変更」ページに表示されているデータセットは、次のカテゴリに分けられます。

- ソース
「ソース」データセットは、「プロビジョニング」オプションの選択に関係なく、最初のページで「リコンシリエーション」オプションを選択した場合にのみ表示されます。

- リコンシリエーション・ステージング
「リコンシリエーション・ステージング」データセットは、「プロビジョニング」オプションの選択に関係なく、「ステップ1: 基本情報の指定」ページで「リコンシリエーション」オプションを選択した場合にのみ表示されます。

- Oracle Identity Manager
「Oracle Identity Manager」データセットは、「ステップ1: 基本情報の指定」ページで選択したオプションに関係なく常に表示されます。ただし、「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「OIM - アカウント」データセットとその子データセットは表示されません。この問題に対処するには、次の手順を実行する必要があります。

1. 汎用テクノロジ・コネクタを開き、Jgraph画面に移動します。

2. Jgraph画面の「リコンシリエーション・ステージング」で、日付値を保持するフィールドすべてに対してフィールドのデータ型を「日付」に変更します。

3. コネクタを保存します。

「OIM - ユーザー」データセットに表示されるフィールドは、Oracle Identity Managerユーザーに対して事前定義されています。「OIM - ユーザー」データセットの上部にある矢印アイコンをクリックすると、このデータセットのリストの全体表示と最小表示を切り替えることができます。データセットを最小化した状態では、次のフィールドが表示されます。

- ユーザーID

- 電子メール

- パスワード

- 名

- 姓

注意:

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合は、「OIM - ユーザー」データセットのすべてのフィールドが表示され、この場合、矢印アイコンを使用して表示を最小化することはできません。

これらのフィールドによって、値の定義が必要なOracle Identity Managerユーザー・フィールドの最小セットが構成されます。「OIM - ユーザー」データセットの残りのフィールドの一部または全部をOracle Identity Managerインストールにおける必須のOracle Identity Managerユーザー・フィールドとして指定できます。これを行うには、Oracle Identity Managerユーザーの作成時にこれらのフィールドに必ず値が入力されるようにします。

注意:

一定の領域を超えるデータセットおよびフィールドの名前は切り捨てられ、切り捨てた箇所の後にはドットが表示されます。たとえば、「OIM - ユーザー」データセットの「デプロビジョニング日」フィールドは次のように表示されます。

Deprovisioning Da..

フィールドの完全名を表示するには、このフィールドまたはこのフィールドがマップされているフィールドの編集アイコンをクリックします。ポップアップ・ウィンドウでは、確認するフィールド名がそのフィールドが属するデータセットに応じて最初のページまたは2番目のページに表示されます。

Design Consoleを使用すると、事前定義済のOracle Identity Managerユーザー・フィールドのリストにユーザー定義フィールド(UDF)を追加できます。これらのUDFは、「ステップ3: コネクタ構成の変更」ページの「OIM - ユーザー」データセットに表示されます。

「ステップ1: 基本情報の指定」ページで選択したオプションによっては、次のフィールドが「ステップ3: コネクタ構成の変更」ページにデフォルトで表示されます。

- IDフィールド
IDフィールドは、「ステップ1: 基本情報の指定」ページで「リコンシリエーション」オプションまたは「プロビジョニング」オプションを選択したかどうかに関係なく、「OIM - アカウント」データセットにデフォルトで表示されます。アカウントの作成時、このフィールドには、Oracle Identity Managerとターゲット・システムでそのアカウントを一意に識別する値が格納されます。特定のユーザーについては、変更、削除、有効化、無効化などの他の操作、および子データ操作を指示する際にこの一意のフィールドが使用されます。

すべてのターゲット・システムは、ユーザー・アカウントの作成と更新を追跡するために一意のフィールドを備えています。カスタム・プロビジョニング・トランスポート・プロバイダの作成時には、「ユーザーの作成」操作の終了時にプロバイダがこの一意のフィールドの値をターゲット・システムから取得していることを確認する必要があります。その後、この値は、「OIM - アカウント」データセットのIDフィールドへの移入に使用されます。

リコンシリエーション中、IDフィールドの値は「リコンシリエーション・ステージング」データセットの対応する一意のフィールドから取得する必要があります。この操作を設定するには、この2つのフィールド間のマッピングを作成します。マッピングの作成手順については、この項で後述します。

注意:

汎用テクノロジ・コネクタの作成時に「プロビジョニング」と「リコンシリエーション」の両方のオプションを選択しても、IDフィールドとターゲット・システムの一意のフィールドの間にマッピングを作成しない場合は、リコンシリエーションによってリンクされているレコードをプロビジョニング操作(変更、削除、有効化、無効化、子データ操作など)に使用できません。これは、リンクされているレコードがIDフィールドに移入されていないためです。

- objectClassフィールド
objectClassフィールドは、「ステップ1: 基本情報の指定」ページでSPMLプロビジョニング・フォーマット・プロバイダを選択した場合にのみ、「OIM - アカウント」データセットと「プロビジョニング・ステージング」データセットにデフォルトで表示されます。

- containerIDフィールド
containerIDフィールドは、「ステップ1: 基本情報の指定」ページでSPMLプロビジョニング・フォーマット・プロバイダを選択した場合にのみ、「OIM - アカウント」データセットと「プロビジョニング・ステージング」データセットにデフォルトで表示されます。

- プロビジョニング・ステージング
「プロビジョニング・ステージング」データセットは、「リコンシリエーション」オプションの選択に関係なく、最初のページで「プロビジョニング」オプションを選択した場合にのみ表示されます。

「ステップ3: コネクタ構成の変更」ページに表示されるデータセットは、「ステップ1: 基本情報の指定」ページと「ステップ2: パラメータ値の指定」ページの入力内容によって異なります。データセット内に表示されるフィールドは、メタデータの検出の有無によって決まります。

注意:

次のいずれかの条件に該当する場合、メタデータの検出は行われません。

- ターゲット・システムのサンプル・データ(メタデータを含む)を使用できない場合

- 選択したトランスポート・プロバイダやフォーマット・プロバイダが、ターゲット・システムのサンプル・データからメタデータを検出できない場合

次に、この例を示します。

「ステップ1: 基本情報の指定」ページで「リコンシリエーション」オプションのみを選択したとします。また、メタデータの検出は行われなかったとします。この条件で、「ステップ3: コネクタ構成の変更」ページに表示されるデータセットおよびフィールドは、次のように要約できます。

次のデータセットが表示されます。

- ソース

- リコンシリエーション・ステージング

- Oracle Identity Manager

これらのデータセットを構成するフィールドは表示されません。

さらに、「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「OIM - アカウント」データセットとその子データセットは表示されません。

表19-3の使用例1は、この一連の入力条件の結果を示しています。この表の他の使用例は、表の最初の行と列に記載されている入力条件の組合せによって表示されるデータセットとフィールドを示しています。

表19-3 様々な入力条件によるデータセットおよびフィールドの表示

「リコンシリエーション」オプションのみ選択

「リコンシリエーション」と「プロビジョニング」の両方のオプションの選択

「プロビジョニング」オプションのみ選択

メタデータの検出なし

使用例1

次のデータセットが表示されます。

- ソース

- リコンシリエーション・ステージング

- Oracle Identity Manager

これらのデータセットを構成するフィールドは表示されません。

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「OIM - アカウント」データセットとその子データセットは表示されません。

使用例2

次のデータセットが表示されます。

- ソース

- リコンシリエーション・ステージング

- Oracle Identity Manager

- プロビジョニング・ステージング

これらのデータセットを構成するフィールドは表示されません。

使用例3

次のデータセットが表示されます。

- Oracle Identity Manager

- プロビジョニング・ステージング

これらのデータセットを構成するフィールドは表示されません。

メタデータの検出あり

使用例4

次のデータセットが表示されます。

- ソース

- リコンシリエーション・ステージング

- Oracle Identity Manager

これらのデータセットを構成するフィールドが表示されます。

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「OIM - アカウント」データセットとその子データセットは表示されません。

使用例5

次のデータセットが表示されます。

- ソース

- リコンシリエーション・ステージング

- Oracle Identity Manager

- プロビジョニング・ステージング

これらのデータセットを構成するフィールドが表示されます。

使用例6

次のデータセットが表示されます。

- Oracle Identity Manager

- プロビジョニング・ステージング

これらのデータセットを構成するフィールドが表示されます。

関連項目:

このページの非ASCII文字の表示に関する制限事項については、第20.1.2項「他言語サポート」を参照してください。

マッピング

「ステップ3: コネクタ構成の変更」ページに表示されている流れ線は、異なるデータセットの2つのフィールド間のマッピング(リンク)をそれぞれ示しています。マッピングは、次のいずれかを目的としています。

- プロビジョニングまたはリコンシリエーションを目的とする、2つのデータセットのフィールド間のデータ・フロー・パスの確立
このタイプのマッピングに基づいて、データの検証または変換が行われます。

- 2つのデータセットのフィールド値の比較(一致)の基盤の構築
次に、一致のみのマッピングの例を示します。

- 「リコンシリエーション・ステージング」データセットと「OIM - ユーザー」データセットのフィールド間に作成されたマッピングは、リコンシリエーション・ルールの基礎を成します。

- 「リコンシリエーション・ステージング」データセットの一意のフィールドと「OIM - アカウント」データセットのIDフィールドの間のマッピングを作成すると、リコンシリエーション一致のキー・フィールドの識別が容易になります。IDフィールドに加えて、「OIM - アカウント」データセットの他のフィールドを「リコンシリエーション・ステージング」データセットの対応するフィールドに(一致のみで)マップして、リコンシリエーション一致のコンポジット・キー・フィールドを作成できます。

「ステップ3: コネクタ構成の変更」ページでは、次のアクションを実行できます。

- データセットのフィールドの追加または編集

- データセットのフィールドの削除

- フィールド間のマッピングの削除

- 子データセットの削除

19.2.4.3.1 データセットのフィールドの追加または編集

メタデータ検出で検出されたアイデンティティ・フィールドは、「ステップ3: コネクタ構成の変更」ページに表示されます。これらのフィールドやフィールド間のマッピングを変更できます。必要に応じて、このページで新しいフィールドの追加や、フィールド間のマッピングの作成を行うこともできます。

「ステップ3: コネクタ構成の変更」ページでフィールドの追加や編集の際に実行できるアクションの概要を次に示します。

注意:

これらのアクションは、この後の手順で詳しく説明しています。この手順では、一部のアクションを実行する前に満たす必要がある条件についても説明しています。

- デフォルトの属性(データ型や長さなど)が、表示されるフィールドにメタデータ検出によって割り当てられます。これらのフィールドを編集して必要な属性を設定する必要があります。

注意:

Oracle Identity Managerが、リコンシリエーション時にフェッチされた日付値を認識できるのは、「リコンシリエーション・ステージング」データセットのフィールドに「日付」データ型を設定した場合のみです。また、「ステップ2: パラメータ値の指定」ページで「ソース日付書式」パラメータの値を指定した場合は、「ソース」データセットの日付フィールドを「リコンシリエーション・ステージング」データセットの対応する日付フィールドにマップする必要があります。

「ソース日付書式」パラメータについては、第19.2.4.2項「「ステップ2: パラメータ値の指定」ページ」で説明しています。

- 変換プロバイダを使用してフィールド間の変換マッピングを作成できます。このアクションを実行するときは、事前定義済の連結変換プロバイダまたは翻訳変換プロバイダ、あるいは自ら作成したカスタム変換プロバイダを使用できます。

- 「リコンシリエーション・ステージング」データセットと「Oracle Identity Manager」データセットのフィールド間に一致のみのマッピングを作成できます。「リコンシリエーション・ステージング」データセットと「OIM - ユーザー」データセットの間に作成する一致のみのマッピングが、リコンシリエーション・ルールになります。「リコンシリエーション・ステージング」データセットと「OIM - アカウント」データセットの間に作成する一致のみのマッピングでは、リコンシリエーション一致のキー・フィールドが指定されます。

- 既存のデータセットに子データセットを追加できます。

- プロセス・フォームとデータベースの両方でフィールドの値を暗号化することができます。

- フィールドを参照フィールドに指定して、フィールドの入力ソースを選択できます。入力ソースには、参照定義かOracle Identity Managerデータベース表の列の組合せを指定できます。

- ユーザー・アカウント・ステータスのリコンシリエーションを構成できます。
ユーザー・アカウント・ステータスのリコンシリエーションを構成する場合は、「アカウント・ステータスのリコンシリエーションの構成」を参照してください。

データセットのフィールドを追加または編集するには、次の手順を実行します。

注意:

次の手順で説明するGUI要素とページの表示は、フィールドを追加または編集するデータセットによって異なります。たとえば、「ソース」データセットのフィールドを追加または編集する場合、「必須」チェック・ボックスと「暗号化」チェック・ボックスは表示されません。

1. フィールドの追加または編集のいずれかに応じて、データセットの「追加」アイコン、またはフィールドの編集アイコンをクリックします。

2. 「ステップ1: フィールド情報」ページで次のGUI要素の値を指定します。

関連項目:

フィールド名に適用される検証の詳細は、第19.2.4.3項「「ステップ3: コネクタ構成の変更」ページ」を参照してください。

- フィールド名: フィールドを追加する場合は、そのフィールドの名前を指定します。非ASCII文字は使用できないため、指定するフィールド名にはASCII文字のみを使用します。

- アクションのマッピング: マッピングの宛先フィールドとしてこのフィールドで作成するマッピングのタイプを選択します。次のいずれかのマッピング・アクションを選択できます。

- ソース(入力)フィールドと追加または編集するフィールドの間で1対1マッピングのみを作成し、変換プロバイダを使用しない場合は、「変換なしでマッピングの作成」を選択します。

- フィールドを編集し、そのフィールドを宛先フィールドとするマッピングを削除する場合は、「マッピングの削除」オプションを選択します。マッピングの削除手順の詳細は、「フィールド間のマッピングの削除」を参照してください。

- 「アクションのマッピング」リストの変換マッピングのオプションは、事前定義された変換プロバイダと作成したカスタム変換プロバイダに基づいて表示されます。次のメニュー・オプションは、事前定義済の変換プロバイダに対応しています。
* 連結ありでマッピングの作成

* 変換ありでマッピングの作成

関連項目:

これらの事前定義済の変換プロバイダの詳細は、第17.5項「変換プロバイダ」を参照してください。

変換マッピングの選択時には、次のガイドラインが適用されます。

- 変換マッピングは、次のデータセットのフィールド間でのみ作成可能です。
-「ソース」と「リコンシリエーション・ステージング」

- 「Oracle Identity Manager」と「プロビジョニング・ステージング」

したがって、たとえば「リコンシリエーション・ステージング」データセットと「Oracle Identity Manager」データセットのフィールド間では変換マッピングを作成できません。

次のソース・フィールドと宛先フィールドで1対2マッピングを作成することはできません。

ソース・フィールド: 「リコンシリエーション・ステージング」データセットの一意のフィールド

宛先フィールド: 「OIM - ユーザー」データセットのUser IDフィールドおよび「OIM - アカウント」データセットのIDフィールド

このマッピングはサポートされていません。かわりに、「リコンシリエーション・ステージング」データセットの一意のフィールドとUser IDフィールド(「OIM - ユーザー」データセット)またはIDフィールド(「OIM - アカウント」データセット)の間の1対1のマッピングを作成する必要があります。

- 「プロビジョニング・ステージング」データセットのすべてのフィールドは、「OIM - ユーザー」データセットおよび「OIM - アカウント」データセットの対応するフィールドにマップしてください。

- ソース・フィールドまたは宛先フィールドとして「OIM - ユーザー」データセットのフィールドを指定したマッピングを作成すると、「OIM - ユーザー」データセットのフィールド・リストの表示はそのマッピングの作成時の位置(展開または最小化)で固定されます。「OIM - ユーザー」データセットの固定表示を解除して矢印アイコンを使用可能にするには、ソース・フィールドまたは宛先フィールドとして「OIM - ユーザー」データセットのフィールドを指定したマッピングをすべて削除する必要があります。

- 変換フィールドの入力フィールドの1つとしてリテラル・フィールドを使用できます。「リテラル」オプションを選択した場合は、そのフィールドに値を入力する必要があります。このオプションの選択後は、リテラル・フィールドを空白にしないでください。

変換マッピングの作成に関する制限事項は、第19.2.4.3項「「ステップ3: コネクタ構成の変更」ページ」を参照してください。

- 一致のみ: 一致のみのマッピングの宛先フィールドとしてフィールドを使用する場合は、このチェック・ボックスを選択します。すでに説明したように、次のタイプの一致のみのマッピングを作成できます。

注意:

親と子の両方のデータセットで一致のみのマッピングを作成する必要があります。

- リコンシリエーション・ルールを作成するには、「リコンシリエーション・ステージング」データセットのフィールドと「OIM - ユーザー」データセットのフィールド間で一致のみのマッピングを作成します。各マッピングがリコンシリエーション・ルールの要素を表します。子データセットがある場合は、一致のみのマッピングの入力フィールドとなる「リコンシリエーション・ステージング」データセットのフィールドの名前が、リコンシリエーション・ステージングの子データセットで使用されていないことを確認してください。

- リコンシリエーション一致のキー・フィールドを指定するには、「リコンシリエーション・ステージング」データセットの一意のフィールドと「OIM - アカウント」データセットの「ID」フィールドの間に一致のみのマッピングを作成します。IDフィールドに加えて、「OIM - アカウント」データセットの他のフィールドを「リコンシリエーション・ステージング」データセットの対応するフィールドに(一致のみで)マップして、リコンシリエーション一致のコンポジット・キー・フィールドを作成できます。

注意:

一致のみのマッピングで使用された「リコンシリエーション・ステージング」フィールドの名前が、リコンシリエーション・ステージングの子データセットのフィールド名として再利用されると、リコンシリエーション実行時に一致が行われません。

この既知の問題については、コネクタ構成の変更ページの項で説明しています。

- エンドツーエンド・マッピングの作成: フィールドを追加している場合に、フィールドの追加先のデータセットの右側に表示されるすべてのデータセットにも同じフィールドを追加するには、このチェック・ボックスを選択します。

- 複数値フィールド: 子データセットを追加する場合は、このチェック・ボックスを選択します。このチェック・ボックスを選択すると、「フィールド名」フィールドで指定する名前が子データセットの名前として使用されます。

注意:

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」チェック・ボックスを選択した場合、このチェック・ボックス(選択または選択解除の状態)は無視されます。これは、信頼できるソース・リコンシリエーションでは、複数値(子)データのリコンシリエーションがサポートされていないためです。

- データ型: フィールドのデータ型を選択します。
メタデータの検出後は、「リコンシリエーション・ステージング」および「OIM - アカウント」データセットのすべてのフィールドにStringデータ型がデフォルトで適用されます。状況によっては、「データ型」リストを使用して各フィールドの実際のデータ型を指定する必要があります。

- 長さ: フィールドの文字の長さを指定します。

- 必須: フィールドに値が常に入力されるようにするには、このチェック・ボックスを選択します。

- 暗号化: フィールドの値を暗号化形式でOracle Identity Managerデータベースに格納する必要がある場合は、このチェック・ボックスを選択します。

- パスワード・フィールド: フィールドの値をプロセス・フォームで暗号化する必要がある場合は、このチェック・ボックスを選択します。このチェック・ボックスを選択したフィールドの値は、アスタリスク(*)としてプロセス・フォームに表示されます。

注意:

「暗号化」および「パスワード・フィールド」チェック・ボックスを選択する場合は、順守する必要のあるガイドラインについて第19.5.3.3項「パスワード型フィールド」を参照してください。

- 参照フィールド: フィールドを参照フィールドにする場合は、このチェック・ボックスを選択します。

3. 「続行」をクリックします。

4. 「ステップ1: フィールド情報」ページで「参照フィールド」チェック・ボックスを選択すると、「ステップ2: 参照プロパティ」ページが表示されます。このページでは、表19-4に記載されている参照プロパティの任意の組合せの値を選択および指定できます。

表19-4 参照プロパティ

参照プロパティ

値

列名

「プロパティ値」フィールドに、参照ウィンドウでの表示が必要な値を格納するデータベース列の名前を入力します。必要に応じて、複数のデータベース列名をカンマで区切って入力できます。

注意: 「参照列名」プロパティを選択する場合は、この「列名」プロパティも選択する必要があります(「参照列名」プロパティについてはこの表で後述します)。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

次のSQLクエリを使用すると、「列名」および「参照列名」プロパティの使用方法を示すことができます。

SELECT USR_FIRST_NAME, USR_LOGIN, USR_LAST_NAME FROM USR

この2つのプロパティの値を次のように設定したとします。

- 列名: USR_FIRST_NAME, USR_LAST_NAME

- 参照列名: USR_LOGIN

このユーザーがUSR_FIRST_NAME, USR_LAST_NAMEの特定の組合せを参照ウィンドウから選択すると、対応するUSR_LOGINの値がデータベースに格納されます。

列見出し

「プロパティ値」フィールドに、参照ウィンドウでの表示が必要な列ヘッダーの名前を入力します。参照ウィンドウに複数の列を表示する場合は、カンマで区切った複数の列見出しを入力します(例: 組織名,組織ステータス)。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

列幅

「プロパティ値」フィールドに、参照ウィンドウでの表示が必要な列の文字幅を入力します。この値は、データ値を抽出して参照フィールドに移入するための基礎となるフィールドまたは列の最大長と同じにする必要があります。

参照ウィンドウに複数の列を表示する場合は、カンマで区切った複数の列幅を入力します。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

参照問合せ

「参照問合せ」プロパティの値を指定するには、次の手順を実行します。

1. 「プロパティ値」フィールドに、(WHERE句を指定せずに)SQL問合せを入力します。この問合せは、ユーザーが参照フィールドをダブルクリックすると実行され、参照ウィンドウに表示されるデータ列に値が移入されます。

2. 「送信」をクリックします。

3. 「ステップ2: 検証の追加」ページで次のリストから値を選択し、ステップ1で指定したSELECT文のWHERE句を作成します。
- フィルタ列

- ソース

- フィールド名

選択した値によって、WHERE句が次のように作成されます。

WHERE Filter_Column=Source.Field_Name

4. 「保存」をクリックします。

問合せから戻されるデータを正しく表示するには、lookupfield.headerプロパティをxlWebAdmin_locale.propertiesファイルに追加する必要があります。

たとえば、次のSQL問合せについて考えます。

SELECT usr_status FROM usr

この問合せから戻されるデータを表示するには、xlWebAdmin_locale.propertiesファイルに次のエントリを追加する必要があります。

lookupfield.header.users.status=User Status

指定した問合せのxlWebAdmin_locale.propertiesファイルにlookupfield.headerプロパティが含まれていない場合は、対応する「参照」アイコンをクリックすると、Identity System Administrationに参照ウィンドウが表示されます。

lookupfield.headerプロパティの構文は次のとおりです。

lookupfield.header.column_code=display value

このエントリのcolumn_codeの部分には小文字を使用し、空白はアンダースコア文字(_)に置き換える必要があります。

デフォルトでは、参照フィールドの列ヘッダーとして次のエントリをxlWebAdmin_locale.propertiesファイルで使用できます。

lookupfield.header.lookup_definition.lookup_code_information
.code_key=Value
lookupfield.header.lookup_definition.lookup_code_information
.decode=Description
lookupfield.header.users.manager_login=User ID
lookupfield.header.organizations.organization_name=Name
lookupfield.header.it_resources.key=Key
lookupfield.header.it_resources.name=Instance Name
lookupfield.header.users.user_id=User ID
lookupfield.header.users.last_name=Last Name
lookupfield.header.users.first_name=First Name
lookupfield.header.groups.group_name=Group Name
lookupfield.header.objects.name=Resource Name
lookupfield.header.access_policies.name=Access Policy Name

参照コード

「プロパティ値」フィールドに、参照定義コード名を入力します。このコードは、参照値や参照値の選択時に参照フィールドに表示されるテキストなど、参照フィールドに関する全情報を生成します。参照定義コードの分類タイプは参照タイプである必要があります(つまり、「参照定義」フォームで「参照タイプ」オプションを選択する必要があります)。

参照コードを入力するには、「参照定義」フォームを開いて必須コードの問合せを実行し、そのコードを「プロパティ値」フィールドにコピーします。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

注意:

「参照コード」プロパティを使用すると、「列見出し」、「列名」、「列幅」、「参照列名」、「名前」、「参照問合せ」の各プロパティの組合せを置き換えることができます。さらに、「参照コード」プロパティで指定されている情報は、これらの5つの参照プロパティで設定されている値よりも優先されます。

参照フィールド・リコンシリエーションを実行する場合は、参照コードへの移入を行うスケジュール済タスクを作成します。

参照列名

「プロパティ値」フィールドに、参照ウィンドウでユーザーが選択した「列名」値に対応する値を格納するデータベース列の名前を入力します。必要に応じて、複数のデータベース列名をカンマで区切って入力できます。

注意: 「列名」プロパティを選択する場合は、この「参照列名」プロパティも選択する必要があります。これらの2つのプロパティの使用方法については、この表の「参照列名」行を参照してください。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

オートコンプリート

「プロパティ値」フィールドにTrueを入力すると、ユーザーは選択する値の最初の数文字を入力して参照フィールドをダブルクリックすることにより、参照ウィンドウに表示される値をフィルタ処理できます。このアクションにより、ユーザーが入力した文字で始まる参照値のみが参照ウィンドウに表示されます。たとえば、「State」参照フィールドでは、ユーザーはNewと入力できます。ユーザーが「State」参照フィールドをダブルクリックすると、Newで始まる州(New Hampshire、New Jersey、New Mexico、New Yorkなど)のみが参照ウィンドウに表示されます。

参照フィールド値表示のユーザーによるフィルタ処理を許可しない場合は、「プロパティ値」にFalseを入力します。

「オートコンプリート」プロパティのデフォルト値はFalseです。

「プロパティ値」フィールドに値を入力したら、「送信」をクリックします。

「ステップ2: 参照プロパティ」ページの表に表示されているプロパティの値を編集するには、そのプロパティの編集オプションを選択して「編集」をクリックします。この表に表示されているプロパティを削除するには、そのプロパティの削除オプションを選択して「削除」をクリックします。

参照フィールドのプロパティの指定が完了したら、「続行」をクリックします。

5. 「ステップ1: フィールド情報」ページの「アクションのマッピング」リストで変換オプションを選択すると、「ステップ3: マッピング」ページが表示されます。このページを使用して、追加するフィールドの入力データに対して実行する変換機能を定義します。実行する手順は、前のページで選択した変換プロバイダのオプション(連結、翻訳またはカスタム変換プロバイダ)によって異なります。
事前定義済の変換プロバイダ(変換、連結または翻訳)を選択する場合、事前定義済の変換プロバイダのパラメータ値の指定方法の詳細は、「変換プロバイダ」を参照してください。この項でも、ユーザー・アカウント・ステータスのリコンシリエーションの構成について詳しく説明しています。

ユーザー・アカウント・ステータス情報のリコンシリエーションを構成する場合は、翻訳変換プロバイダを使用する必要があります。この手順は、第17.5.2項「翻訳変換プロバイダ」で説明しています。

変換プロバイダの値の指定が完了したら、「続行」をクリックします。

6. 必要な場合は、フィールドの検証チェックを選択して「追加」をクリックします。 つまり、使用する検証プロバイダを選択します。
このリストの検証オプションは、事前定義された検証プロバイダと作成したカスタム検証プロバイダに基づいて表示されます。

7. 「続行」をクリックし、「閉じる」をクリックします。

8. 「ステップ3: コネクタ構成の変更」ページで他のアクションを実行しない場合は、このページの上部にある「閉じる」ボタンをクリックします。この「閉じる」ボタンをクリックするには、その前の手順を実行しておく必要があります。

19.2.4.3.2 データセットのフィールドの削除

データセットからフィールドを削除するには、次の手順を実行します。

1. そのフィールドの「削除」アイコンをクリックします。

2. 「ステップ3: コネクタ構成の変更」ページで他のアクションを実行しない場合は、このページの上部にある「閉じる」ボタンをクリックします。

19.2.4.3.3 フィールド間のマッピングの削除

マッピングを削除するには、次の手順を実行します。

1. 削除するマッピングの宛先フィールドで編集アイコンをクリックします。

注意:

この宛先フィールドが別のマッピングのソース・フィールドである場合、そのマッピングは削除されません。

2. 「ステップ1: フィールド情報」ページの「変換」リストから「マッピングの削除」を選択します。

3. 「続行」をクリックします。

4. 最後のページで「閉じる」をクリックします。

5. 「ステップ3: コネクタ構成の変更」ページで他のアクションを実行しない場合は、このページの上部にある「閉じる」ボタンをクリックします。

19.2.4.3.4 子データセットの削除

子データセットを削除するには、次の手順を実行します。

1. そのデータセットの「削除」アイコンをクリックします。

2. 「ステップ3: コネクタ構成の変更」ページで他のアクションを実行しない場合は、このページの上部にある「閉じる」ボタンをクリックします。

図19-2は、「OIM - アカウント」データセットおよび「プロビジョニング・ステージング」データセットにMyFieldフィールドを追加した後の「ステップ3: コネクタ構成の指定」ページを示しています。

図19-2 フィールド追加後の「ステップ3: コネクタ構成の変更」ページ

19.2.4.4 「ステップ4: コネクタ・フォーム名の検証」ページ

このページを使用して、「OIM - アカウント」データセットとその子データセットに対応するプロセス・フォームのフォーム名を指定します。

注意:

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択した場合、「OIM - アカウント」データセットとその子データセットは作成されません。そのため、「信頼できるソース・リコンシリエーション」オプションを選択すると、このページは表示されません。

汎用テクノロジ・コネクタの作成に必要な情報をすべて送信すると、汎用テクノロジ・コネクタ・フレームワークによって特定のオブジェクトが自動的に作成されます。自動作成されるオブジェクトの例として、「OIM - アカウント」データセットに対応する親と子のプロセス・フォームがあります。特定のOracle Identity Managerインストールの各プロセス・フォームは、一意の名前を必要とします。

関連項目:

第16.4項「汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト」

「ステップ4: コネクタ・フォーム名の検証」ページでは、汎用テクノロジ・コネクタ・フレームワークにより、対応するデータセットの名前に基づくプロセス・フォームのデフォルト名が表示されます。これらのフォーム名を検証し、必要な場合は、このOracle Identity Managerインストールで一意になるようにフォーム名を変更します。フォーム名の変更には、ASCII文字のみを使用する必要があります。一意でないフォーム名や非ASCII文字を含む名前を指定すると、エラー・メッセージが表示されます。

注意:

このページに戻ることはできません。そのため、指定したフォーム名が要件をすべて満たしていることを確認してから「続行」をクリックしてください。

フォーム名の指定が完了したら、「続行」をクリックします。

「続行」をクリックするかわりに、「戻る」をクリックして「ステップ2: パラメータ値の指定」ページに戻ることもできます。ただし、このページで変更を加えて「続行」ボタンをクリックしても、メタデータの検出は行われません。これは、このページの最初のパススルーで実行したデータセット構造とマッピングのカスタマイズが上書きされないようにするためです。「ステップ3: コネクタ構成の変更」ページでは、フィールドおよびマッピングを手動で追加または編集できます。

19.2.4.5 「ステップ5: コネクタ情報の検証」ページ

このページを使用して、この時点までに指定した汎用テクノロジ・コネクタの作成に関する情報を確認します。これ以降は、既述ページで許可されている変更についてページごとに説明します。

- 「ステップ1: 基本情報の指定」ページ
「表示」リンクまたは「戻る」ボタンを使用すると、「ステップ1: 基本情報の指定」ページで指定した情報を再度表示して確認できます。この情報を変更すると新しい汎用テクノロジ・コネクタを作成することになるため、このページに表示される情報は変更できません。

- 「ステップ2: パラメータ値の指定」ページ
「変更」リンクまたは「戻る」ボタンを使用すると、このページを再度表示できます。このページではパラメータ値を変更できます。ただし、変更した値を送信しても、メタデータの検出は行われません。これは、このページの最初のパススルーで実行したデータセット構造とマッピングのカスタマイズが上書きされないようにするためです。「ステップ3: コネクタ構成の変更」ページでは、フィールドおよびマッピングを手動で追加または編集できます。

- 「ステップ3: コネクタ構成の変更」ページ
「変更」リンクを使用すると、このページを再度表示してフィールドやマッピングを追加または編集できます。

- 「ステップ4: コネクタ・フォーム名の検証」ページ
このページに戻ることはできません。

「ステップ5: コネクタ情報の検証」ページに表示されている情報をすべて検証したら、「作成」をクリックします。

この段階で、汎用テクノロジ・コネクタ・フレームワークにより、指定した情報に基づいてすべての標準コネクタ・オブジェクトが作成されます。これらのオブジェクトのリストには、自動的に作成され、Oracle Identity ManagerにインポートされるコネクタXMLファイルが含まれます。フォーム名を除き、コネクタ・オブジェクトの名前はGTCname_GTCの形式になります。

たとえば、作成する汎用テクノロジ・コネクタの名前としてDB_connを指定すると、すべてのコネクタ・オブジェクト(フォーム以外)の名前はDB_CONN_GTCとなります。

関連項目:

第16.4項「汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト」

プロセスの最後に、コネクタが正常に作成されたことを通知するメッセージがこのページに表示されます。

注意:

作成プロセスに失敗しても、作成されるオブジェクトは自動的に削除されません。この点については、第20.1.1項「作成の問題」にも記載されています。

作成プロセスに関連するエラー・メッセージのリストについては、第20.2.3項「コネクタ作成中のエラー」を参照してください。

19.2.5 リコンシリエーションの構成

注意:

「ステップ1: 基本情報の指定」ページで「プロビジョニング」オプションのみを選択した場合は、リコンシリエーションの構成が不要のため、このセクションをスキップできます。

リコンシリエーションのスケジュール済タスクは、汎用テクノロジ・コネクタの作成時に自動的に作成されます。このスケジュール済タスクを構成して実行するには、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの作成と管理の手順に従います。

注意:

スケジュール済タスクの名前は次の形式になります。

GTC_Name_GTC

たとえば、汎用テクノロジ・コネクタの名前がWebConnである場合、スケジュール済タスクの名前はWebConn_GTCとなります。

19.2.6 プロビジョニングの構成

注意:

「ステップ1: 基本情報の指定」ページで「リコンシリエーション」オプションのみを選択した場合は、プロビジョニングの構成が不要のため、この項をスキップできます。

プロセス定義は、汎用テクノロジ・コネクタの作成時に自動的に作成されるオブジェクトの1つです。プロセス定義の名前は次の形式になります。

GTC_name_GTC

たとえば、汎用テクノロジ・コネクタの名前がWebConnである場合、プロセス定義の名前はWebConn_GTCとなります。

このプロセス定義を構成するプロセス・タスクには、次の2種類があります。

- システム定義プロセス・タスク
システム定義プロセス・タスクは、新規に作成されるすべてのプロセス定義にデフォルトで含まれます。

- プロビジョニング固有のプロセス・タスク
プロビジョニング固有のプロセス・タスクは、「リコンシリエーション」オプションの選択に関係なく、「ステップ1: 基本情報の指定」ページで「プロビジョニング」オプションを選択した場合にのみ、汎用テクノロジ・コネクタのプロセス定義に含まれます。

次に、プロビジョニング固有のプロセス・タスクを示します。

- ユーザーの作成

- ユーザーの削除

- ユーザーの有効化

- ユーザーの無効化

- 更新されたField_Name(このタスクはIDフィールドを除く、「OIM - アカウント」データセットの各フィールドに対して作成されます。)

- 「OIM - ユーザー」データセットと「プロビジョニング・ステージング」データセットのフィールド間で作成されたマッピングでは、次のプロセス・タスクが作成されます。

- User_data_set_field_nameの変更

- Provisioning_Staging_field_nameの編集

たとえば、「OIM - ユーザー」データセットの「姓」フィールドと「プロビジョニング・ステージング」データセットの「LName」フィールドの間のマッピングを作成したとします。プロビジョニング固有のその他のプロセス・タスクとともに、次のプロセス・タスクが自動的に作成されます。

- 姓の変更

- LNameの編集

さらに、次のプロビジョニング固有のプロセス・タスクが「OIM - アカウント」データセットの子データセットごとに作成されます。

- 子表のChild_Form_Name行の挿入

- 子表のChild_Form_Name行の更新

- 子表のChild_Form_Name行の削除

すべてのプロビジョニング固有のプロセス・タスクには、次のデフォルト割当てがあります。

- ターゲット・タイプ: Group User With Highest Priority

- グループ: SYSTEM ADMINISTRATORS

- ユーザー: XELSYSADM

これらのデフォルトの割当ては、必要に応じて、「プロセス・タスクの変更」の手順に従って変更できます。

19.2.7 フォームの作成とアプリケーション・インスタンスの公開

フォームを作成し、「ステップ1: 基本情報」ページで「リコンシリエーション」オプションおよび「プロビジョニング」オプションの両方を選択した場合に作成されるアプリケーション・インスタンスを公開するには、次の手順を実行します。

1. GTCリソース・オブジェクトに固有のフォームを作成します。

2. フォームをGTCアプリケーション・インスタンスにアタッチします。

3. GTCアプリケーション・インスタンスを必須の組織に公開します。

注意:

新しいUIでプロビジョニングされたアカウントを表示するには、プロセス・フォームにITリソースのフィールドがある必要があります。このITリソース・フィールドの値は、リコンシリエーションの実行中に移入される必要があります。

19.2.8 ロギングの有効化

注意:

このステップはオプションです。この項で説明した手順は、汎用テクノロジ・コネクタのロギングを有効化する場合にのみ実行してください。

Oracle Identity Managerのロギングの有効化の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・ロギングの有効化に関する説明を参照してください。

19.3 汎用テクノロジ・コネクタの管理

汎用テクノロジ・コネクタのフレームワークには、汎用テクノロジ・コネクタを変更できる機能が用意されています。また、デプロイメント・マネージャを使用して、汎用テクノロジ・コネクタのエクスポートまたはインポートが可能です。

この項は次のトピックで構成されています。

- 汎用テクノロジ・コネクタの変更

- 汎用テクノロジ・コネクタのエクスポート

- 汎用テクノロジ・コネクタのインポート

19.3.1 汎用テクノロジ・コネクタの変更

注意:

汎用テクノロジ・コネクタの作成プロセスの最後に自動的に作成されるコネクタ・オブジェクトは、Design Consoleを使用して変更できます。Design Consoleでこの汎用テクノロジ・コネクタのコネクタ・オブジェクトがカスタマイズされている場合に、「汎用テクノロジ・コネクタの管理」機能を使用して汎用テクノロジ・コネクタを変更すると、Design Consoleを使用して行われたすべてのカスタマイズが上書きされます。そのため、次のガイドラインのいずれかを適用することをお薦めします。

- Design Consoleを使用して、汎用テクノロジ・コネクタ・オブジェクトを変更しないでください。
ITリソースについてはこのガイドラインは適用されません。ITリソースのパラメータは、Design Consoleを使用して変更できます。ただし、変更を有効にするには、ITリソース・パラメータの変更前または後にキャッシュをパージする必要があります。

- Design Consoleを使用して汎用テクノロジ・コネクタ・オブジェクトを変更する場合、汎用テクノロジ・コネクタの変更に「汎用テクノロジ・コネクタの管理」機能を使用しないでください。

フレームワークによって自動的に作成されるコネクタ・オブジェクトの詳細は、第16.4項「汎用テクノロジ・コネクタ・フレームワークで作成されるコネクタ・オブジェクト」を参照してください。

また、同時に変更できるコネクタは1つのみです。同じコンピュータ上で、2つの異なるコネクタに「変更」ページを同時に使用しようとすると、「変更」機能が正しく動作しません。

これらの点については、付録20「汎用テクノロジ・コネクタのトラブルシューティング」を参照してください。

汎用テクノロジ・コネクタを変更するには、次の手順を実行します。

1. Identity System Administrationにログインします。

2. 「構成」の下で、「汎用コネクタ」をクリックします。

3. 変更するコネクタを検索します。検索を容易にするため、このページで提供される検索条件を組み合せることができます。また、このOracle Identity Managerのインストールで作成されたすべての汎用テクノロジ・コネクタを表示するには、検索条件を指定せずに「コネクタの検索」をクリックします。

4. 表示される結果から、変更する汎用テクノロジ・コネクタをクリックします。

5. 「パラメータの編集」をクリックします。コネクタ作成プロセスの「ステップ2: パラメータ値の指定」ページが表示されます。これ以降は、「ステップ2」の項に記載されている手順に従ってください。

注意:

この手順は、既存の汎用テクノロジ・コネクタを変更する際に自動のメタデータの検出が行われない点のみ、汎用テクノロジ・コネクタ作成の手順とは異なります。

注意:

「OIM - アカウント」データセットまたはその子データセットのフィールド属性を変更する場合、これらのデータセットについて、Oracle Identity Managerデータベース・エントリで対応する変更は加えられません。また、エラー・メッセージも表示されません。

そのため、「OIM - アカウント」データセットのフィールドや子データセットを変更しないことをお薦めします。

この点については、第20.2.2項「「ステップ3: コネクタ構成の変更」ページ」にも記載されています。

19.3.2 汎用テクノロジ・コネクタのエクスポート

汎用テクノロジ・コネクタのXMLファイルはエクスポートできます。このXMLファイルには、コネクタを構成するすべてのオブジェクトの定義が含まれています。新しくOracle Identity Managerをインストールする際に同じ汎用テクノロジ・コネクタを使用する場合、まずXMLファイルをエクスポートし、これを新しいOracle Identity Managerインストールにインポートします。

コネクタのXMLファイルをエクスポートするには、次の手順を実行します。

1. Oracle Identity Manager拡張管理で、「システム管理」の下の「デプロイメント・マネージャ・ファイルのエクスポート」をクリックします。

2. デプロイメント・マネージャ・ウィザードの最初のページで、リストから「汎用コネクタ」を選択し、「検索」をクリックします。

3. 検索結果から、XMLファイルをエクスポートする汎用テクノロジ・コネクタを選択します。

4. 「子の選択」をクリックします。

5. 選択した汎用テクノロジ・コネクタに対して、エクスポートする子エンティティを選択し、「依存性の選択」をクリックします。

6. エクスポートする依存性を選択し、「確認」をクリックします。

7. ページに表示された要素がエクスポートの要件を満たしていることを確認したら、「エクスポート用に追加」をクリックします。

8. 「ウィザードを終了し、すべての選択を表示します」をクリックし、続いて「OK」をクリックします。

19.3.3 汎用テクノロジ・コネクタのインポート

汎用テクノロジ・コネクタを別のOracle Identity Managerのインストールにコピーするには、次の手順を実行します。

1. コネクタがカスタム・プロバイダを使用する場合、プロバイダ作成中に作成されたファイルをコピー先となるOracle Identity Managerインストール上の適切なディレクトリにコピーする必要があります。

関連項目:

これらのプロバイダ・ファイルおよびそのコピー先となるディレクトリの詳細は、第18章「汎用テクノロジ・コネクタ用カスタム・プロバイダの作成」を参照してください。

2. コピー元となるOracle Identity Managerインストール上で、コネクタXMLファイルをエクスポートします。

3. コピー先となるOracle Identity Managerインストール上で、コネクタXMLファイルをインポートします。

注意:

ステージング・サーバー上の汎用テクノロジ・コネクタおよびそれを構成するオブジェクト用に選択する名前は、本番サーバー上の既存のコネクタやオブジェクトの名前と競合しないようにする必要があります。

次のシナリオで、このガイドラインの順守が必要な理由を説明します。

ステージング・サーバー上で汎用テクノロジ・コネクタを作成し、このコネクタを本番サーバーにインポートするとします。ステージング・サーバー上で汎用テクノロジ・コネクタを作成する際、汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前がそのサーバー上で一意であることを確認します。同時に、これらの名前が本番サーバーのコネクタおよびコネクタ・オブジェクトの名前と同じではないことも確認する必要があります。

同じ名前がある場合は、コネクタXMLファイルをステージング・サーバーから本番サーバーへインポートする際、古いオブジェクトが新しいオブジェクトによって上書きされます。上書き処理中はメッセージが表示されないため、該当するコネクタが最終的に失敗します。

これについては、第20.2.1項「汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前」でも説明しています。

オブジェクトが上書きされたとき、正常に機能する状態に戻せるようにするには、コネクタXMLファイルをインポートする前に、インポート先のOracle Identity Managerデータベースのバックアップを取得する必要があります。

コネクタのXMLファイルをインポートするには、次のようにします。

1. Oracle Identity Manager拡張管理で、「システム管理」の下のデプロイメント管理ファイルのインポートをクリックします。ファイルを検索するダイアログ・ボックスが表示されます。

2. コネクタXMLファイルのコピー先ディレクトリから、このファイルを検索して開きます。

3. 「ファイルの追加」をクリックします。

4. 「次へ」→「次へ」→「スキップ」とクリックします。

5. 「選択内容の表示」をクリックします。
コネクタXMLファイルの内容が「インポート」ページに表示されます。複数のノードのある十字のアイコンが表示される場合があります。これらのノードは、冗長なOracle Identity Managerエンティティを示しています。コネクタXMLファイルをインポートする前に、ノードごとに右クリックし、「削除」を選択してこれらのエンティティを削除する必要があります。

6. 「インポート」をクリックします。コネクタのファイルがOracle Identity Managerにインポートされます。

コネクタXMLファイルをインポートした後、汎用テクノロジ・コネクタのランタイム・パラメータを更新する必要があります。

注意:

これらの値は、コネクタXMLファイルをエクスポートしても、そこにはコピーされません。

ランタイム・パラメータの値を更新するには、第19.5.7項「汎用テクノロジ・コネクタの変更」で説明する手順を実行してください。

19.4 カスタム・コネクタでの汎用接続プール・フレームワークの使用

カスタム・コネクタで、接続プーリングのニーズに対して汎用接続プール・フレームワーク(GCPとも呼ばれる)の使用を選択できます。

内部的に、汎用接続プール・フレームワークではOracleユニバーサル接続プール(UCP)をデフォルトの接続プーリング・メカニズムとして使用します。汎用接続プールをカスタム・コネクタで使用する基本的な手順は次のとおりです。

1. ResourceConnectionインタフェースの具体的な実装を指定します。
実装には、デフォルト・コンストラクタ(パラメータなし)も必要です。

2. ITResource定義で追加のフィールドを定義します。

3. 汎用接続プールを呼び出し、プールから接続を取得およびリリースします。

このセクションの内容は次のとおりです。

- ResourceConnectionインタフェースの具体的な実装の指定

- 追加のITResourceパラメータの定義

- プールからの接続の取得およびリリース

- サード・パーティ・プールの使用

- 例: ResourceConnectionの実装

19.4.1 ResourceConnectionインタフェースの具体的な実装の指定

接続プールでは、ResourceConnectionの具体的な実装を使用して、接続の作成とクローズ、およびターゲットへの接続の検証が行われます。そのため、この具体的な実装クラスがJavaTasksフォルダの下でjarファイルとして使用できることを確認する必要があります。

表19-5に、ResourceConnectionの主要メソッドの説明を示します。

表19-5 ResourceConnectionのメソッド

メソッド

説明

Create Connection

このメソッドは、(接続の初期数を作成するために)プールの初期化中、および必要に応じてプールのライフサイクル・イベントに対して呼び出されます。itResourceInfoMapという名前のハッシュマップを、このメソッドに対するITResource値を持つパラメータとして使用できます。

このメソッドは、ターゲットへの実際の物理接続であるResourceConnectionを返します。

Close Connection

このメソッドは、プールのライフサイクル・イベントの過程で接続をクローズする必要がある場合にプールによって呼び出されます。

Heartbeat

このメソッドは、ターゲットへの接続のTCPハートビート(またはTCPキープアライブ)を維持するために使用されます。このメソッドにより、接続がターゲット側からタイムアウトしないように、TCP接続が維持されます。

Validate

このメソッドは、接続がまだ有効であるかどうかを示すtrueまたはfalseを返します。

このメソッドは、「流用時の接続の検証」がtrueに設定されている場合、汎用接続プールによって呼び出されます。しばらくの間プール内にあった接続に対して呼び出されます。

このメソッドがfalseを返す場合、プールはその接続を破棄し、新規接続を作成してリクエスタに返します。

19.4.2 追加のITResourceパラメータの定義

表19-6に、適切な値を指定する必要があるその他のITResourceパラメータを示します。

表19-6 ITResourceパラメータ

フィールド

説明

サンプル値および注意

中止した接続のタイムアウト

中止した接続の接続タイムアウト(秒)。タイムアウトの経過後、接続は再要求されます。

900

接続待機タイムアウト

接続の確立を待機する時間(秒)。

60

非アクティブ接続タイムアウト

プール内のアイドル状態の非アクティブ接続の接続タイムアウト(秒)。注意: これらは流用された接続ではありません。

300

初期プール・サイズ

プール内の接続の初期数。

3

最大プール・サイズ

プールで作成できる接続の最大数。

30

最小プール・サイズ

プールで保持する必要がある接続の最小数。

2

貸出し時の接続の検証

接続を検証する必要があるかどうかを示します。詳細は、表19-5を参照してください。

trueまたはfalse

タイムアウト・チェック間隔

タイムアウト・プロパティをチェックする頻度(秒)。

30

プール・プリファレンス

優先されるプーリング・メカニズムを示します。デフォルトのプール実装はUCPです。

デフォルト(UCPの場合)。ネイティブ(ネイティブ実装の場合)

接続プーリングをサポート

プーリングがサポートされるかどうかを示します。プーリングがサポートされない場合、返される接続はプールされた接続ではありません。デフォルト(推奨)はtrueです。

trueまたはfalse

ターゲットで1つの接続のみをサポート

ターゲット・システムで一度に1つの接続のみがサポートされるかどうかを示します。trueに設定すると、他のプロパティに関係なく、次のプール・パラメータが使用されます。

- 最小プール・サイズ = 0

- 初期プール・サイズ = 0

- 最大プール・サイズ = 1

デフォルト(推奨)はfalseです。

ターゲットで1つの接続のみが処理される場合はtrue、それ以外の場合はfalse。

ResourceConnectionクラス定義

ResourceConnectionクラスの具体的な実装

com.oracle.oim.ad.ADResourceConnectionImpl

ネイティブ接続プール・クラス定義

GenericPoolを実装するネイティブ・プール・メカニズムのラッパー。「プール・プリファレンス」がネイティブに設定されている場合にのみ値を設定します。

com.oracle.oim.ad.ADNativePool

プール除外フィールド

接続の作成に不要なフィールドのカンマ区切りのリスト。指定したいずれかのフィールドが更新された場合には、GCPプールはリフレッシュされません。

注意: このリストのフィールドは、createConnectionメソッドへのHashMapパラメータの一部として使用できません。

Recon TimeStamp,ADSync Enabled

次の点に注意してください。

- Design ConsoleからITResourceパラメータを更新しても、プールはリフレッシュされません。Identity System AdministrationまたはAPIを介して値を更新します。

- プールが使用されているときは値を更新しないでください。

19.4.3 プールからの接続の取得およびリリース

汎用接続プールのコンシューマは、ConnectionServiceを呼び出して、ターゲットへのプールされた接続を取得し、プールに接続を戻すことができます。

このコード例は、ITResource名に基づいてプールから接続を取得し、戻します。

import com.oracle.oim.gcp.exceptions.ConnectionServiceException;
import com.oracle.oim.gcp.pool.ConnectionService;
import com.oracle.oim.gcp.resourceconnection.ResourceConnection;

public class ConnectionPoolClient {

public void testConnection(String itResName)
{
try{
//Request for connection from the connection pool
ConnectionService service = new ConnectionService();
ResourceConnection myConnection =
service.getConnection(itResName);

//"myConnection" is the connection
//use the connection...

//Release connection back to the connection pool
//Connections should always be returned this way.

service.releaseConnection(myConnection);
}
catch(ConnectionServiceException e)
{
//handle
}
}

ITResourceキーを使用して、ターゲットへの接続をリクエストすることもできます。次に例を示します。

ConnectionService service = new ConnectionService();
ResourceConnection myConnection = service.getConnection(itResourceKey);

19.4.4 サード・パーティ・プールの使用

この項で前述したように、カスタム・コネクタにいずれかのサード・パーティ・プールを使用できます。ただし、前述の手順に加えて、サード・パーティ・プールのラッパーとしてGenericPoolインタフェースの具体的な実装を指定する必要があります。

注意:

カスタム・コネクタでUCPプールを使用しない場合、カスタム・コネクタではネイティブ・オプションでGCPの使用を選択できますが、この選択に大きな利点はありません。ネイティブ・プール・プリファレンスでは、プールの維持と実装はカスタム・コネクタによって行われます。

表19-7に、GenericPoolインタフェースの呼び出されるメソッドを示します。

表19-7 GenericPoolインタフェースのメソッド

メソッド

目的

initializePool(PoolConfiguration poolConfig)

プールを初期化します。PoolConfigurationデータ・オブジェクトには、すべてのプール関連のパラメータが含まれます。

borrowConnectionFromPool()

接続をリクエストします。

returnConnectionToPool(ResourceConnection resConn)

接続をプールへ返します。

refreshPool(PoolConfiguration newPoolConfig)

更新された値でプールをリフレッシュします。

destroyPool()

プールを削除します(ITResourceが削除された場合など)。

19.4.5 例: ResourceConnectionの実装

次の例は、ResourceConnectionインタフェースの実装を示しています。主要メソッドは強調表示されています。

例19-1 ResourceConnection実装の例

/**
* Sample implementation for Socket Connections:
*/
import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.net.SocketException;
import java.net.UnknownHostException;

import com.oracle.oim.gcp.exceptions.ResourceConnectionCloseException;
import com.oracle.oim.gcp.exceptions.ResourceConnectionCreateException;
import com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception;
import com.oracle.oim.gcp.resourceconnection.ResourceConnection;

public class SocketResourceConnectionImpl extends Socket implements ResourceConnection {
public SocketResourceConnectionImpl() {
super();

}
/**
* Sample: Concrete implementation for closing a socket connection
*/
public void closeConnection() throws ResourceConnectionCloseException{
if(!this.isClosed()){
try {
this.close();
} catch (IOException e) {
throw new
ResourceConnectionCloseException("[Client
ResourceConnection implementation]
Failed to close socket connection! ");
}
}
}
/**
* Sample : Concrete implementation for creating a socket connection.
* The return value is the actual physical socket connection
*
*/
public ResourceConnection createConnection(HashMap itResInfoMap)
throws ResourceConnectionCreateException {
ResourceConnection r = null;
SocketResourceConnectionImpl i = new
SocketResourceConnectionImpl();

try {
//HashMap has all ITResource related information that is needed
//for connecting to target.
String serverAddress= ((String) itResInfoMap.get
("Server Address")).trim();
//utility method getIntValue returns an int for a String

int port =                        getIntValue(((String)itResInfoMap.get("Port")).trim());

System.out.println("Connecting to Socket with IP Address "
+ serverAddress+" at port "+ port);
InetSocketAddress inet = new                         InetSocketAddress(serverAddress,port);
i.connect(inet);
if(!i.isConnected()){
throw new ResourceConnectionCreateException
(" Failed to create socket: connection failure");
}
r = (ResourceConnection)i;
} catch (UnknownHostException e) {
throw new ResourceConnectionCreateException("
[Client ResourceConnection implementation]
Failed to create socket connection!", e);
} catch (IOException e) {
throw new ResourceConnectionCreateException("
[Client ResourceConnection implementation]
Failed to create socket connection! ",e);
}

return r;
}
/**
* Sample : Concrete implementation for heartbeat of a socket connection
*/
public void heartbeat() throws ResourceConnectionValidationxception {
try {
this.setKeepAlive(true);

} catch (SocketException e) {
throw new
ResourceConnectionValidationxception
("[Client ResourceConnection implementation]
Failed to set heartbeat ");
}

}
/**
* Sample: Concrete implementation for validating connection
*/
public boolean isValid() {
if(this.isBound()){

return true;

}else{
return false;
}
}
}

19.5 ベスト・プラクティス

この項は次のトピックで構成されています。

- 「基本情報の指定」ページの使用

- 「パラメータ値の指定」ページの使用

- 「コネクタ構成の変更」ページの使用

- 共有ドライブ・リコンシリエーション・トランスポート・プロバイダの使用

- カスタム・プロバイダの使用

- コネクタ・オブジェクトの使用

- 汎用テクノロジ・コネクタの変更

19.5.1 「基本情報の指定」ページの使用

汎用テクノロジ・コネクタの名前を指定する場合は次のガイドラインを適用します。

- サマリー:
名前にはASCII文字のみを使用するようにします。アンダースコア(_)文字は使用できますが、それ以外の非ASCII文字は名前に使用しないでください。

説明:

コネクタ作成プロセスの終了時に自動的に作成されるコネクタ・オブジェクトの大部分では、オブジェクト自体の名前の一部に汎用テクノロジ・コネクタの名前が使用されます。たとえば、汎用テクノロジ・コネクタの名前がWebConnである場合、スケジュール済タスクの名前はWebConn_GTCとなります。

Oracle Identity Managerデータベースでは、非ASCII文字の名前が指定されたオブジェクトを格納するプロビジョニングは実行されません。そのため、汎用テクノロジ・コネクタの名前を指定するときに非ASCII文字を入力すると、エラー・メッセージが表示されます。

- Oracle Identity Managerインストールで使用されているコネクタまたはコネクタ・オブジェクトの名前と同じ名前を指定しないでください。

- ステージング・サーバー上で汎用テクノロジ・コネクタを作成して本番サーバーに移動する場合は、汎用テクノロジ・コネクタの名前が本番サーバー上の既存のコネクタまたはコネクタ・オブジェクトの名前と競合しないようにしてください。

- ステージング・サーバー上に作成した汎用テクノロジ・コネクタを本番サーバーにインポートする前には、宛先のOracle Identity Managerデータベースのバックアップを作成して、コネクタ・オブジェクトが上書きされた場合に作業状態に戻れるようにしてください。

- 共有ドライブ・トランスポート・プロバイダを選択する場合は、CSVフォーマット・プロバイダを選択する必要があります。

- SPMLプロビジョニング・フォーマット・プロバイダを選択する場合は、Webサービス・プロビジョニング・トランスポート・プロバイダを選択する必要があります。

- 共有ドライブ・リコンシリエーション・トランスポート・プロバイダを選択する場合は、リコンシリエーション用にターゲット・システムから提供される親データおよび子データのファイルにおいて、少なくとも最初の2行に所定のフォーマットのデータがあることを確認してください。データの所定のフォーマットの詳細は、第17.1項「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」で説明しています。

- 共有ドライブ・リコンシリエーション・トランスポート・プロバイダを選択する場合は、リコンシリエーションの開始前に、ステージング・ディレクトリおよびアーカイブ・ディレクトリに必要な権限が設定されていることを確認してください。必要な権限の詳細は、「ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限」で説明しています。

- 一度に複数の汎用テクノロジ・コネクタを作成しようとしないでください。同じOracle Identity ManagerインストールのIdentity System Administrationで、別のセッションから作成する場合も同様です。

19.5.2 「パラメータ値の指定」ページの使用

ここでは、「ステップ2: パラメータ値の指定」ページで指定する入力に関する既知の問題について説明します。

- サマリー:
共有ドライブ・リコンシリエーション・トランスポート・プロバイダを使用する場合、次の点に注意します。

- ステージング・ディレクトリとアーカイブ・ディレクトリに同じパスを指定しないでください。両方のディレクトリに同じパスを指定すると、アーカイブ・ディレクトリの既存のファイルが削除されます。

- ステージング・ディレクトリ内のファイルの名前が、アーカイブ・ディレクトリ内のファイルの名前と異なるようにしてください。ファイル名が同一になると、アーカイブ・ディレクトリ内の既存のファイルがリコンシリエーション実行の終了時に上書きされます。

説明:

共有ドライブ・リコンシリエーション・トランスポート・プロバイダを使用する場合、各リコンシリエーション実行の後にデータファイルがステージング・ディレクトリからアーカイブ・ディレクトリに移動します。アーカイブ・ディレクトリに移動したファイルにタイムスタンプまたはマークは付きません。そのため、共有ドライブ・トランスポート・プロバイダの使用時には、次のガイドラインに注意してください。

- 指定するアーカイブ・ディレクトリのパスおよび名前は、ステージング・ディレクトリのパスおよび名前と同じものにしないでください。同じパスおよび名前を指定すると、アーカイブ・ディレクトリ内の既存のファイルがリコンシリエーション実行の終了時に削除されます。

- 現行のリコンシリエーション実行時に、最後のリコンシリエーション実行で使用されたファイルと同じ名前のデータファイルがステージング・ディレクトリに配置されていると、アーカイブ・ディレクトリ内の既存のファイルが、ステージング・ディレクトリからの新しいファイルで上書きされます。次に、この例を示します。
最後のリコンシリエーションの実行終了時に、ステージング・ディレクトリからアーカイブ・ディレクトリに次の各ファイルが自動的に移動したとします。

usrdataParentData.csv
usrdataRoleData.csv
usrdataGroupMembershipData.txt

現行のリコンシリエーションの実行用に、ステージング・ディレクトリに次の各ファイルを配置します。

usrdataParentData.csv
usrdataRoleData_04Feb07.csv
usrdataGroupMembershipData_04Feb07.txt

これらのファイルは、現行のリコンシリエーションの実行終了時にアーカイブ・ディレクトリに移動します。その際、古いusrdataParentData.csvファイルが新しいファイルで上書きされます。

そのため、アーカイブ・ディレクトリ内のファイルがリコンシリエーション実行の終了時に上書きされないようにするには、ステージング・ディレクトリ内のファイルの名前がアーカイブ・ディレクトリ内のファイルの名前と同一にならないようにする必要があります。

- サマリー:
「ステップ2: パラメータ値の指定」ページに戻っても、2回目にはメタデータの検出は行われません。そのため、必要に応じて「ステップ3: コネクタ構成の変更」ページに表示されるフィールドおよびフィールド・マッピングを手動で変更する必要があります。

説明:

「ステップ2: パラメータ値の指定」ページで指定した値を変更するとします。このページには、「ステップ4: コネクタ・フォーム名の検証」ページまたは「ステップ5: コネクタ情報の検証」ページから戻れます。ただし、プロバイダ・パラメータ値を変更した後に「続行」ボタンをクリックしても、2回目にはメタデータの検出は行われません。これは、「ステップ3: コネクタ構成の変更」ページで手動で行われた可能性のある変更の保護を目的とした機能です。

この機能が適用されるため、既存の汎用テクノロジ・コネクタを変更しても、メタデータの検出は行われません。

19.5.3 「コネクタ構成の変更」ページの使用

ここでは、次の領域に関するベスト・プラクティスについて説明します。

- フィールドの名前

- パスワード・フィールド

- パスワード型フィールド

- マッピング

- Oracle Identity Managerデータセット

19.5.3.1 フィールドの名前

フィールドの追加時または編集時にフィールド名を指定する場合、次の検証が適用されることに注意してください。

- 同じデータセット(親または子)に属する2つのフィールドには同じ名前を指定できません。

- 同じ親データセットの2つの子データセットには同じ名前を指定できません。

- 親データセットのフィールドの名前には、その子データセットのいずれかと同じ名前は指定できません。

- その2つの子データセットが同じ親データセットに属しているかどうかに関係なく、2つの異なる子データセットに同じ名前のフィールドをそれぞれ指定することは可能です。たとえば、UsrIDという名前のフィールドをGroupMembershipデータセットとRoleデータセットのそれぞれに指定できます。

- 2つの異なる親データセットに同じ名前のフィールドをそれぞれ指定することは可能です。同様に、これらのデータセットに同じ名前の子データセットをそれぞれ指定することも可能です。

- 子データセットの名前には、そのフィールドのいずれかと同じ名前を指定できます。

19.5.3.2 パスワード・フィールド

パスワードの安全性を確保するため、パスワード情報は汎用テクノロジ・コネクタでリコンサイルしないでください。つまり、「ソース」データセットおよび「リコンシリエーション・ステージング」データセットには「パスワード」フィールドが含まれないようにします。また、「リコンシリエーション・ステージング」データセットのフィールドを「OIM - ユーザー」データセットの「パスワード」フィールドにマップしないでください。

19.5.3.3 パスワード型フィールド

パスワード型フィールドは、「暗号化」属性および「パスワード・フィールド」属性を(「暗号化」チェック・ボックスおよび「パスワード・フィールド」チェック・ボックスを選択して)設定するフィールドです。「OIM - アカウント」データセットに追加するフィールドにこれらの2つの属性を設定すると、パスワード型フィールドを作成できます。

パスワード型フィールドの内容を保護するため、これらのフィールドの追加時または編集時には次のガイドラインに注意してください。

- 「パスワード・フィールド」チェック・ボックスおよび「暗号化」チェック・ボックスを使用すると、Oracle Identity Managerでのパスワード情報の表示および格納を保護できます。ただし、パスワード型フィールドを「プロビジョニング・ステージング」データセットのフィールドにマップする場合は、これらのフィールドに伝播されるデータを保護するため、必要なすべての予防措置をとってください。たとえば、このデータがプロビジョニング操作の終了時にターゲット・システムのプレーン・テキスト・ファイルに格納されないようにする必要があります。
「OIM - アカウント」データセットと「プロビジョニング・ステージング」データセットのパスワード・フィールド間には、1対1のマッピングのみ作成することをお薦めします。つまり、このパスワード・フィールドを、「プロビジョニング・ステージング」フィールドとの変換マッピングの入力フィールドとして使用しないようにしてください。「OIM - ユーザー」データセットの「パスワード」フィールドについても同様の予防措置をとる必要があります。

- 前述したとおり、「パスワード」フィールドは「OIM - ユーザー」データセットの事前定義済フィールドの1つです。このフィールドには「パスワード・フィールド」属性および「暗号化」属性が設定されます。Design Consoleを使用すると、作成するUDFに「パスワード・フィールド」属性および「暗号化」属性を設定できます。このように設定すると、新規作成されるUDFに既存の「パスワード」フィールドと同じプロパティが指定されます。ただし、汎用テクノロジ・コネクタ・フレームワークは、このフィールドを他のテキスト・フィールド(Stringデータ型を持つ)と同じように扱い、Identity Self Service、Identity System Administrationまたはデータベースでコンテンツはカプセル化されません。
第20.1項「汎用テクノロジ・コネクタに関する一般的な問題」も参照してください。

19.5.3.4 マッピング

「Oracle Identity Manager」データセットのフィールドを使用する場合は次のベスト・プラクティスに従います。

- サマリー:
翻訳変換プロバイダを選択してマッピングを作成する場合、「参照コード名」リージョンに参照定義の名前を指定してください。データセット名およびフィールドを「参照コード名」リージョンに指定すると、実際のリコンシリエーションまたはプロビジョニングの操作時に変換に失敗します。

説明:

マッピングの作成時に翻訳変換プロバイダを選択すると、「ステップ2: マッピング」ページに、データセットからフィールドを選択してリテラルを指定するオプションが表示されます。翻訳変換プロバイダを使用しているため、「リテラル」オプションを選択して、変換用のコード・キーおよびデコードの値を含む参照定義の名前を入力する必要があります。「参照コード名」リージョンにデータセット名およびフィールドを選択しないでください。データセット名およびフィールドの選択を無効にする検証は行われませんが、実際のリコンシリエーションまたはプロビジョニングの操作時に変換操作に失敗します。

- 「OIM - アカウント」データセットのIDフィールドと、「リコンシリエーション・ステージング」データセットのレコードを一意に識別するフィールドとのマッピングを作成します。

- IDフィールドに加えて、「OIM - アカウント」データセットの他のフィールドを「リコンシリエーション・ステージング」データセットの対応するフィールドに(一致のみで)マップして、リコンシリエーション一致のコンポジット・キー・フィールドを作成できます。

- 「プロビジョニング・ステージング」データセットのすべてのフィールドと、「Oracle Identity Manager」データセットの対応するフィールドとのマッピングを作成します。

- リコンシリエーション・ルールを作成するには、リコンシリエーション・ステージング・データセットのフィールドと「OIM - ユーザー」データセットのフィールド間で一致のみのマッピングを作成します。子データセットがある場合は、一致のみのマッピングの入力フィールドとなる「リコンシリエーション・ステージング」データセットのフィールドの名前が「リコンシリエーション・ステージング」の子データセットで使用されていないことを確認してください。このガイドラインに従っていないと、リコンシリエーションは失敗します。
これについては、「「ステップ3: コネクタ構成の変更」ページ」にも記載されています。

- 変換マッピングの入力フィールドの1つとしてリテラル・フィールドを使用できます。「リテラル」オプションを選択した場合は、そのフィールドに値を入力する必要があります。このオプションの選択後は、リテラル・フィールドを空白にしないでください。

19.5.3.5 「Oracle Identity Manager」データセット

「Oracle Identity Manager」データセットのフィールドを使用する場合は次のベスト・プラクティスに従います。

- 信頼できるソースのリコンシリエーションでは、「OIM - ユーザー」データセットの次の各フィールドに常に値が保持されている必要があります。

- ユーザーID

- 名

- 姓

- 組織名

- Xellerateのタイプ

- ロール

また、この他に選択できる「OIM - ユーザー」のフィールドにも、ユーザー・アカウントがリコンシリエーションを通じて作成された場合に入力が必要なものがあります。これらの各フィールドに対し、「リコンシリエーション・ステージング」データセットの対応するフィールドとのマッピングを作成する必要があります。リコンシリエーションの実行中は、これらのフィールドのソースとなるターゲット・システムのフィールドに、常に値が保持されているようにしてください。

プロビジョニングに選択できる「OIM - ユーザー」データセットまたは「OIM - アカウント」データセットのフィールドには、ターゲット・システムへの値の伝播が必要なものがあります。これらのフィールドは、特定した後に、「プロビジョニング・ステージング」データセットの対応するフィールドとのマッピングを作成してください。プロビジョニング操作中に、これらの各フィールドに値を入力する必要があります。

- 必要に応じて、事前定義済の「OIM - ユーザー」データセット・フィールドのリストにユーザー定義フィールド(UDF)を追加します。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザー属性の構成に関する説明を参照してください。

- 既存の汎用テクノロジ・コネクタで、「OIM - アカウント」データセットのフィールドの属性を変更または削除しないでください。

19.5.4 共有ドライブ・リコンシリエーション・トランスポート・プロバイダの使用

サマリー

親レコードと子データ・レコードが作成され、ターゲット・システムおよびOracle Identity Managerの両方でリンクされる場合は、各リコンシリエーション実行の開始時に、親データと子データ両方のファイルがステージング・ディレクトリに格納されていることを確認してください。

説明

ターゲット・システムに、子データ・レコードに関連付けられた親データ・レコードがあるとします。これらのレコードをOracle Identity Managerにリコンサイルするには、これらのレコードを含む親データファイルおよび子データファイルをステージング・ディレクトリに配置します。リコンシリエーション実行中に、子データ・レコードがその対応する親データ・レコードにリンクされます。後続のリコンシリエーション実行を開始する前に、ステージング・ディレクトリから子データファイルを削除すると、このような形の子データ・レコードの削除に対してリコンシリエーション・イベントは作成されません。特定の親データ・レコードの子データ・レコードを削除する場合は、子データファイルから子データ・レコードを削除する必要があります。子データファイルに子データ・レコード(3行目以降)がない場合にも、各リコンシリエーション実行時には、子データファイルがステージング・ディレクトリに配置されていることを確認してください。

19.5.5 カスタム・プロバイダの使用

カスタム・プロバイダを使用する場合は次のガイドラインを適用します。

カスタム・プロビジョニング・トランスポート・プロバイダのコードを開発する場合、「ユーザーの作成」操作の終了時にプロバイダが一意のフィールドの値を戻すことを確認してください。この機能は、プロビジョニング・トランスポート・プロバイダのsendDataメソッドによって実装されます。詳細は、「プロビジョニング中のプロバイダの役割」を参照してください。

19.5.6 コネクタ・オブジェクトの使用

汎用テクノロジ・コネクタの作成時に自動的に作成されたコネクタ・オブジェクトを使用する場合は、次のガイドラインを適用します。

- サマリー:
リコンシリエーションのみの汎用テクノロジ・コネクタ用に自動的に作成されたリソース・オブジェクトは、プロビジョニングに使用しようとしないでください。

説明:

汎用テクノロジ・コネクタの作成時に「リコンシリエーション」オプションのみを選択したとします。作成プロセスの終了時に、この汎用テクノロジ・コネクタ用に自動的に作成されるオブジェクトの1つとして、リソース・オブジェクトが作成されます。ただし、リコンシリエーションのみの汎用テクノロジ・コネクタには汎用アダプタが作成されないため、このリソース・オブジェクトはいずれのユーザーにもプロビジョニングできません。

- サマリー:
汎用テクノロジ・コネクタのリソース・オブジェクトを、Oracle Identity Managerで定義されている組織にプロビジョニングしようとしないでください。

説明:

リソース・オブジェクトは、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトの1つです。このリソース・オブジェクトは、Oracle Identity Managerユーザーにのみプロビジョニングできます。Oracle Identity Managerで定義されている組織にはプロビジョニングしようとしないでください。

これについては、「コネクタ・オブジェクト」にも記載されています。

- Design Consoleを使用すると、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトをカスタマイズできます。コネクタ・オブジェクトをカスタマイズした後に「汎用テクノロジ・コネクタの管理」操作を実行すると、そのコネクタ・オブジェクトに対して行ったすべてのカスタマイズが上書きされます。そのため、次のガイドラインのいずれかを適用することをお薦めします。

- Design Consoleを使用して、汎用テクノロジ・コネクタ・オブジェクトを変更しないでください。
ITリソースについてはこのガイドラインは適用されません。ITリソースのパラメータは、Design Consoleを使用して変更できます。ただし、GenericConnectorカテゴリおよびGenericConnectorProvidersカテゴリのキャッシュを有効にしている場合は、ITリソースのパラメータを変更する前後のいずれかにキャッシュをパージする必要があります。

- Design Consoleを使用して汎用テクノロジ・コネクタ・オブジェクトを変更する場合、汎用テクノロジ・コネクタの変更に「汎用テクノロジ・コネクタの管理」機能を使用しないでください。

これについては、第19.5.6項「コネクタ・オブジェクトの使用」にも記載されています。

- 事前移入アダプタは、汎用テクノロジ・コネクタの作成時に自動的に作成されるコネクタ・オブジェクトのセットの一部ではありません。ただし、汎用テクノロジ・コネクタの作成中に、プロビジョニングの入力をリテラル・フィールドおよびユーザー・データ・フィールドにマップすることはできます。この機能を使用してもユーザー定義フォームへの事前移入はできませんが、プロビジョニング・データ・パケットに事前移入することは可能です。

19.5.7 汎用テクノロジ・コネクタの変更

汎用テクノロジ・コネクタを変更する場合は次のベスト・プラクティスに従います。

一度に複数の汎用テクノロジ・コネクタを変更しようとしないでください。同じOracle Identity ManagerインストールのIdentity System Administrationで、別のセッションから作成する場合も同様です。

20 汎用テクノロジ・コネクタのトラブルシューティング

この章では、開発時に発生する可能性がある問題をトラブルシューティングする方法について説明します。これらの項目が含まれます。

- 汎用テクノロジ・コネクタに関する一般的な問題

- 汎用テクノロジ・コネクタの構成に関する問題

20.1 汎用テクノロジ・コネクタに関する一般的な問題

この項では、汎用テクノロジ・コネクタに関する一般的な問題について説明します。内容は次のとおりです。

- 作成の問題

- 多言語サポート

- その他の一般的な問題

20.1.1 作成の問題

この項では、次のような汎用テクノロジ・コネクタ・フレームワークにより自動的に作成されるコネクタ・オブジェクトに関連する既知の問題について説明します。

- サマリー:

- 汎用テクノロジ・コネクタに指定した名前が既存のコネクタ・オブジェクトと同一の名前でも、警告が表示されません。

- コネクタXMLファイルのインポート時に既存のコネクタ・オブジェクトが新規コネクタ・オブジェクトで上書きされても、警告が表示されません。

説明:

この点については、「汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前」でも説明しています。

- サマリー:
汎用テクノロジ・コネクタの作成中にエラーが発生した後、「ステップ5: コネクタ情報の検証」ページの「戻る」をクリックして「ステップ4: コネクタ・フォーム名の検証」ページに戻ると、ページ上にフォーム名が表示されません。

これは意図的なものであり、ソフトウェアの問題や制限に起因するものではありません。

説明:

このマニュアルで前述したとおり、汎用テクノロジ・コネクタの作成プロセスが失敗した場合でも、一部のコネクタ・オブジェクトは自動的に作成されます。このようなコネクタ・オブジェクトには、「ステップ4: コネクタ・フォーム名の検証」ページで名前を指定したプロセス・フォームも含まれます。コネクタの作成プロセスが失敗した場合は、「ステップ4: コネクタ・フォーム名の検証」ページに表示される空白のフィールドに新規フォーム名を入力するよう求められます。これにより、新規フォーム名を送信する際、プロセス・フォーム名が一意かどうかのチェックが必ず行われます。

前のページに戻って汎用テクノロジ・コネクタ作成に必要なデータを入力するかわりに、再度「ステップ1: 基本情報の指定」ページから開始して、汎用テクノロジ・コネクタを作成しなおすこともできます。

- サマリー:
汎用テクノロジ・コネクタのリソース・オブジェクトは、Oracle Identity Managerで定義されている組織にプロビジョニングできません。

説明:

リソース・オブジェクトは、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトの1つです。このリソース・オブジェクトは、Oracle Identity Managerユーザーにのみプロビジョニングできます。Oracle Identity Managerで定義されている組織にはプロビジョニングしようとしないでください。

- サマリー:
「汎用テクノロジ・コネクタの管理」操作を実行すると、汎用テクノロジ・コネクタのオブジェクトに対するカスタマイズが上書きされます。

説明:

Design Consoleを使用すると、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトをカスタマイズできます。ただし、コネクタ・オブジェクトをカスタマイズした後に「汎用テクノロジ・コネクタの管理」操作を実行すると、そのコネクタ・オブジェクトに対して行ったカスタマイズが上書きされます。そのため、次のガイドラインのいずれかを適用することをお薦めします。

- Design Consoleを使用して、汎用テクノロジ・コネクタ・オブジェクトを変更しないでください。
ITリソースについてはこのガイドラインは適用されません。ITリソースのパラメータは、Design Consoleを使用して変更できます。ただし、GenericConnectorカテゴリおよびGenericConnectorProvidersカテゴリのキャッシュを有効にしている場合は、ITリソースのパラメータを変更する前後のいずれかにキャッシュをパージする必要があります。

- Design Consoleを使用して汎用テクノロジ・コネクタ・オブジェクトを変更する場合、汎用テクノロジ・コネクタの変更に「汎用テクノロジ・コネクタの管理」機能を使用しないでください。

- 自動的に作成されたコネクタ・オブジェクトは、汎用テクノロジ・コネクタの作成プロセスが失敗した場合でも削除されません。

20.1.2 多言語サポート

この項では、次のような多言語サポート機能に関連する既知の問題について説明します。

- サマリー:
ステージング・ディレクトリにあるデータファイルの1行目または2行目に非ASCII文字があっても、警告は表示されません。

説明:

ターゲット・システム・ユーザー・データのメタデータでは、非ASCIIデータはサポートされていません。CSVリコンシリエーション・フォーマット・プロバイダを使用する場合は、このような制限があるため、ステージング・ディレクトリに格納する親データファイルや子データファイルのメタデータ行(2行目)には非ASCII文字を使用できません。

この制約は、次の理由により設定されています。

汎用テクノロジ・コネクタ・フレームワークでは、Oracle Identity Managerでユーザー定義プロセス・フォームが作成され、入力したメタデータに基づいてフォームとフィールドに名前が指定されます。また、これらのフォームおよびそのフィールドに対して、それぞれデータベース表および列が作成されます。ただし、データベース・オブジェクト名には非ASCII文字を使用できないため、ターゲット・システムのメタデータでも非ASCII文字はサポートされません。

汎用テクノロジ・コネクタ・フレームワークでは、データファイルの1行目および2行目にある非ASCII文字を解析し、正しく表示する場合もあります。ただし、コネクタ・オブジェクトが正しく作成されるようにするには、データファイルの1行目および2行目に非ASCII文字を使用しないようにする必要があります。

注意:

データファイルの3行目以降は、フィールド・データ値に非ASCII文字を使用できます。これらのデータ値はリコンサイルされ、Oracle Identity Managerデータベースに格納されます。

- サマリー:
Oracle Identity Managerでサポートされている任意の言語について、ブラウザの言語設定がOracle Identity Managerサーバーのオペレーティング・システムの言語設定と一致しない場合、「ステップ3: コネクタ構成の変更」ページにデータが正しく表示されません。

説明:

「ステップ3: コネクタ構成の変更」ページには、汎用テクノロジ・コネクタ・フレームワークによって動的に作成されるイメージが表示されます。このページでのローカライズされたテキスト項目の表示には、次のような制限があります。

フィールド・ラベルの表示に使用する言語は、次の言語設定と一致している必要があります。

- Oracle Identity Managerの言語

- オペレーティング・システムの言語

- ブラウザの言語

ブラウザの言語設定がOracle Identity Managerサーバーのオペレーティング・システムの言語設定と同じであれば、すべてのテキスト項目(フィールド名およびGUI要素ラベル)は目的の言語で表示されます。

注意:

- ローカライズされたGUI要素ラベルは、このようなGUI要素についてローカライズされたラベルを含むリソース・バンドルを作成し、使用している場合のみ表示されます。

- 繁体字中国語または簡体字中国語を使用する場合、すべてのテキスト項目を目的の言語で表示するには、ブラウザのロケール(言語および国/地域)がオペレーティング・システムのロケールと同じである必要があります。

ブラウザの言語がオペレーティング・システムの言語と異なる場合は、次の静的ラベルが(ブラウザの言語に関係なく)英語で表示されます。

- 「OIM - ユーザー」データセットおよび「OIM - アカウント」データセットのラベル: 「ユーザー」および「アカウント」

- 「OIM - ユーザー」データセットに含まれるフィールドのラベル:

- 「ユーザーID」

- 「電子メール」

- 「名」

- 「姓」

「ステップ3: コネクタ構成の変更」ページのその他の項目のラベルについては、非ASCII言語は正しく表示されません。

- サマリー:
「ステップ3: コネクタ構成の変更」ページのテキスト項目の一部は、常に英語で表示されます。

説明:

「ステップ3: コネクタ構成の変更」ページに表示される静的テキスト項目の一部がローカライズされていません。たとえば、MyGTCという名前の汎用テクノロジ・コネクタを作成するとします。このコネクタのリソース・オブジェクトをあるユーザーにプロビジョニングした場合、ページに次のテキストが表示されます。

Provisioning form for MyGTC

Child Form of MyGTC representing child-dataset: child_data_set_name

このテキストの静的部分は常に英語で表示されます。

必要であれば、次の手順に従って静的テキストをローカライズできます。

1. テキストをローカライズする言語について、対応するcustomResources.propertiesファイルをMDSからインポートして開きます。Oracle Identity Managerでサポートされている各言語に対応するファイルは、すべてMDSに格納されています。MDSからcustomResources.propertiesファイルをインポートするには、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。
次に、この手順の操作の一例を示します。

汎用テクノロジ・コネクタの作成時に、次のような値を指定したとします。

- コネクタ名: MyGTC

- 親フォーム名: ADUser

- 子データセット名: ADUserRole

- 子フォーム名: ADURole1

静的テキストをスペイン語で表示する場合は、customResources_es.propertiesファイルを開きます。このファイルはMDSに格納されています。

2. 目的の言語に対応するcustomResources.propertiesファイルに、次の行を追加します。

注意:

必要な言語に対応するcustomResources.propertiesファイルは、次のURLのOracle Technology Network (OTN) WebサイトにあるOracle Identity Managerページから入手できます。

http://www.oracle.com/technetwork/index.html

global.UD_PARENT_FORM_NAME.description=Localized_text_for_"Provisioning form for" GTC_name

global.UD_CHILD_FORM_NAME.description=Localized_text_for_"Child Form of" GTC_name Localized_text_for_"representing the child data set": child_data_set_name

この2つの行で、次のように置換します。

- PARENT_FORM_NAMEの親フォーム名への置換
Oracle Identity Managerでは、親フォーム名はすべて大文字に変換されます。そのため、名前は大文字で入力する必要があります。

- Localized_text_for_"Provisioning form for"の「Provisioning form for」部分のローカライズ・テキストへの置換

- GTC_nameの汎用テクノロジ・コネクタ名への置換

- CHILD_FORM_NAMEの子フォーム名への置換
Oracle Identity Managerでは、子フォーム名はすべて大文字に変換されます。そのため、名前は大文字で入力する必要があります。

- Localized_text_for_"Child Form of"の「Child Form of」部分のローカライズ・テキストへの置換

- child_data_set_nameの子データセット名への置換

例:

スペイン語の場合、customResources_es.propertiesファイルに、次の行を追加します。

global.UD_ADUSER.description=Spanish_text_for_"Provisioning form for" MyGTC

global.UD_ADUROLE1.description=Spanish_text_for_"Child Form of" MyGTC Spanish_text_for_"representing the child data set": ADUserRole

20.1.3 その他の一般的な問題

この項では、前述のどのカテゴリにも該当しない次のような既知の問題について説明します。

- サマリー:
汎用テクノロジ・コネクタの作成プロセス中に安全でないファイル名の例外がスローされる場合があります。

説明:

Oracle WebLogic ServerおよびOracle Application Serverでは、汎用テクノロジ・コネクタの作成プロセス中に安全でないファイル名の例外がスローされる場合があります。この例外は無視してかまいません。汎用テクノロジ・コネクタの作成プロセスは、これらの例外が発生しても影響を受けません。この問題は、IBM WebSphere Application ServerおよびJBoss Application Serverでは発生しません。

- 汎用テクノロジ・コネクタでは、親データの削除のリコンシリエーションはサポートされていません。
親データの削除をリコンサイルする場合、汎用テクノロジ・コネクタは使用できません。たとえば、ユーザーJohn Doeのアカウントがターゲット・システムから削除された場合、汎用テクノロジ・コネクタを使用してこのユーザーの削除をOracle Identity Managerでリコンサイルすることはできません。

- サマリー:
Design Consoleを使用して「パスワード・フィールド」属性および「暗号化」属性がフィールドに設定された場合、UDFの内容は暗号化されません。

説明:

前述したとおり、「パスワード」フィールドは「OIM - ユーザー」データセットの事前定義済フィールドの1つです。このフィールドには「パスワード・フィールド」属性および「暗号化」属性が設定されます。Design Consoleを使用すると、作成するUDFに「パスワード・フィールド」属性および「暗号化」属性を設定できます。このように設定すると、新規作成されるUDFに既存の「パスワード」フィールドと同じプロパティが指定されます。ただし、汎用テクノロジ・コネクタ・フレームワークは、このフィールドを他のテキスト・フィールド(Stringデータ型を持つ)と同じように扱い、Identity System Administrationまたはデータベースでコンテンツはカプセル化されません。

- Design Consoleでリコンシリエーション・ルールの作成に使用できる機能の一部が、汎用テクノロジ・コネクタ・フレームワークでは使用できません。次のパターンのリコンシリエーション・ルールのみを作成できます。
A equals B

"and"

C equals D

"and"

E equals F

- 汎用テクノロジ・コネクタを作成する際、ターゲット・システムとの通信にRemote Managerを使用するようには指定できません。そのため、汎用テクノロジ・コネクタではRemote Managerを使用できません。

- プロビジョニング中にターゲット・システムへ送信する必要がある日付の値の書式を指定する場合は、「ターゲット日付書式」パラメータを使用します。日付を数値形式で入力すると、このパラメータの日付の検証は行われません。指定可能な日付書式の詳細は、次のWebページを参照してください。
http://java.sun.com/docs/books/tutorial/i18n/format/simpleDateFormat.html#datepattern

- 現在実行されていないスケジュール済タスクのステータスはINACTIVEです。これらのタスクは、次の指定の日時に実行されます。ある特定の条件下では、スケジュール済タスクにNONEステータスが自動的に割り当てられます。ただし、このステータスへの変更はタスクの機能には反映されず、機能は継続して指定の日時に実行されます。

- 「OIM - アカウント」データセットのフィールドのデータ型を変更すると、汎用テクノロジ・コネクタの管理操作の際に、「ステップ5: コネクタ情報の検証」ページで「作成」をクリックしたときにエラーがスローされます。

20.2 汎用テクノロジ・コネクタの構成に関する問題

この項は次のトピックで構成されています。

- 汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前

- 「ステップ3: コネクタ構成の変更」ページ

- コネクタ作成中のエラー

- リコンシリエーション中のエラー

- プロビジョニング中のエラー

20.2.1 汎用テクノロジ・コネクタおよびコネクタ・オブジェクトの名前

ここでは、次のような汎用テクノロジ・コネクタおよびコネクタ・オブジェクトに対して指定する名前に関連する既知の問題について説明します。

サマリー:

- 汎用テクノロジ・コネクタに指定した名前が既存のコネクタ・オブジェクトと同一の名前でも、警告が表示されません。

- コネクタXMLファイルのインポート時に既存のコネクタ・オブジェクトが新規コネクタ・オブジェクトで上書きされても、警告が表示されません。

説明:

汎用テクノロジ・コネクタの作成中や変更中は、汎用テクノロジ・コネクタ・フレームワークによって様々なオブジェクトが自動的に作成または変更されます。その際、汎用テクノロジ・コネクタとプロセス・フォームに対して名前を指定するよう求められます。その他のオブジェクトの名前は、フレームワークによって自動的に生成されます。自動生成される名前は、汎用テクノロジ・コネクタに指定した名前に基づきます。

汎用テクノロジ・コネクタに対して名前を指定する場合、名前がそのOracle Identity Managerインストールのすべてのオブジェクト・カテゴリ(リソース・オブジェクトやITリソースなど)において一意である必要があります。同様に、プロセス・フォーム名も一意である必要があります。このガイドラインは、汎用テクノロジ・コネクタXMLファイルを別のOracle Identity Managerインストールにインポートする際にも順守する必要があります。XMLファイルに定義されているオブジェクト名は、インポート先となるOracle Identity Managerインストールでの同じカテゴリに属するオブジェクト名と重複しないようにします。たとえば、XMLファイルに定義されているスケジュール済タスクの名前は、インポート先となるOracle Identity Managerインストール上の他のスケジュール済タスクの名前と同一にはできません。

このガイドラインは、インポート先となるOracle Identity Managerインストールにおいて、オブジェクトが事前定義済コネクタ、あるいは汎用テクノロジ・コネクタに使用されるかどうかに関係なく、すべてのコネクタ・オブジェクトに適用されます。

このガイドラインを順守しない場合、XMLファイルのインポート中、インポートされるオブジェクトと同じ名前の既存オブジェクトは上書されます。上書き処理中はメッセージが表示されないため、該当するコネクタが最終的に失敗します。

この点については、コネクタ・オブジェクトに関する項でも説明しています。

20.2.2 「ステップ3: コネクタ構成の変更」ページ

ここでは、「ステップ3: コネクタ構成の変更」ページでの入力に関する既知の問題について説明します。

- サマリー:
既存の汎用テクノロジ・コネクタを変更する際、「OIM - アカウント」データセットのフィールドまたは子データセットを変更しても、これらのデータセットに基づくフォームのOracle Identity Managerデータベース・エントリに対応する変更が加えられません。また、エラー・メッセージも表示されません。

説明:

「ステップ3: コネクタ構成の変更」ページには、フィールドおよびフィールド・マッピングの追加、変更および削除の機能があります。これらの機能を使用すると、「OIM - アカウント」データセットまたはその子データセット内のフィールドの長さおよびデータ型を変更できます。ただし、このような変更は、このデータセットに対するOracle Identity Managerデータベース・エントリに対する変更として反映されません。また、エラー・メッセージも表示されません。

したがって、「OIM - アカウント」データセットのフィールドや子データセットを変更しないようにしてください。

- サマリー:
汎用テクノロジ・コネクタを作成して、それをプロビジョニングまたはリコンシリエーションに使用し、その後で「OIM - アカウント」データセットのフィールドまたは子データセットを削除するとします。次にプロビジョニングまたはリコンシリエーションを実行するときに同じ汎用テクノロジ・コネクタを使用すると、エラーが発生します。

説明:

汎用テクノロジ・コネクタを作成し、それをプロビジョニングまたはリコンシリエーションに使用するとします。さらに、この汎用テクノロジ・コネクタの「OIM - アカウント」データセットのフィールドまたは子データセットを一部削除するとします。次回、同じ汎用テクノロジ・コネクタを使用してプロビジョニングまたはリコンシリエーションを実行すると、例外がスローされます。

一度でも汎用テクノロジ・コネクタを使用してプロビジョニングまたはリコンシリエーションを実行すると、「OIM - アカウント」データセットのフィールドまたは子データセットを削除する操作は無効になります。これは、削除しようとしているフィールドまたは子データセットにリンクしているデータが、すでにOracle Identity Managerデータベースに格納されているためです。

このため、すでに汎用テクノロジ・コネクタを使用してプロビジョニングまたはリコンシリエーションを実行している場合は、「OIM - アカウント」データセットのフィールドまたは子データセットは削除しないでください。

- サマリー:
一致のみのマッピングで使用されたリコンシリエーション・ステージング・フィールドの名前が、リコンシリエーション・ステージング子データセットのフィールドの名前として再利用されると、リコンシリエーションに失敗します。

説明:

リコンシリエーション・ステージング・データセットと「OIM - ユーザー」データセットのフィールド間で一致のみのマッピングを作成すると、リコンシリエーション・ルールが作成されます。子データセットがある場合は、一致のみのマッピングの入力フィールドとなるリコンシリエーション・ステージング・データセットのフィールドの名前が、リコンシリエーション・ステージング子データセットで使用されていないことを確認してください。一致のみのマッピングで使用されたリコンシリエーション・ステージング・フィールドの名前が、リコンシリエーション・ステージング子データセットのフィールドの名前として再利用されると、リコンシリエーションに失敗します。

次に、このシナリオの具体例を示します。

AD_Userデータセットはリコンシリエーション・ステージング親データセットです。このデータセットには、次のようなフィールドがあります。

- ユーザーID

- 名前

- 職種

- 場所

Admin_Groupsデータセットは、AD_Userデータセットの子データセットです。AD_Userデータセットの「ユーザーID」フィールドを使用して、「OIM - ユーザー」データセットとの一致のみのマッピングを作成する場合、Admin_Groupsデータセット内のフィールドに「ユーザーID」という名前は使用できません。この子データセットに「ユーザーID」という名前のフィールドがある場合、リコンシリエーションに失敗します。

- サマリー:
「パスワード」フィールドがリコンシリエーション・エンジンでリコンサイルされていなくても、このフィールドは「OIM - ユーザー」データセットに表示されます。

説明:

「ステップ1: 基本情報の指定」ページで「信頼できるソース・リコンシリエーション」オプションを選択すると、「パスワード」フィールドはリコンシリエーション・エンジンでリコンサイルされていなくても、「ステップ3: コネクタ構成の変更」ページの「OIM - ユーザー」データセットに表示されます。このフィールドとリコンシリエーション・ステージング・データセット内の対応するターゲット・システム・フィールドとの間にマッピングを作成すると、自動的に生成されるリコンシリエーション・フィールド・マッピングにより、このフィールドの「パスワード」フィールドへのマッピングが試行されます。このため、リコンシリエーション・イベントが失敗します。

- 次のデータセット間のトランスフォーメーション・マッピング作成には制限があります。

- 「ソース」と「リコンシリエーション・ステージング」

- 「Oracle Identity Manager」とプロビジョニング・ステージング

制限は次のとおりです。

- 「ソース」データセットまたは「Oracle Identity Manager」データセットの子データセットと、リコンシリエーション・ステージング・データセットまたはプロビジョニング・ステージング・データセットの異なる(つまり対応しない)子データセットの間には、トランスフォーメーション・マッピングを作成できません。これは、1つの親データセットに含まれる複数の子データセットから、別の親データセットに含まれる1つの子データセットへの多対1マッピングは作成できないことも意味します。
次の例でこの制限について説明します。

「ソース」親データセットに、次のような子データセットがあるとします。

MyGTC:グループ・データセット

- フィールド1: グループ名

- フィールド2: グループ・タイプ

MyGTC:ロール・データセット

- フィールド1: ロール名

- フィールド2: ロール・タイプ

リコンシリエーション・ステージング親データセットに、次のような子データセットがあるとします。

MyGTC:グループ・データセット

- フィールド1: グループ名

- フィールド2: グループ・タイプ

MyGTC:ロール・データセット

- フィールド1: ロール定義

この制限により、たとえば「ソース」データセットの「グループ名」フィールドとリコンシリエーション・ステージング・データセットのロール定義フィールドの間には、トランスフォーメーション・マッピングを作成できません。

ただし、たとえば「ソース」データセットの「ロール名」フィールドおよびロール・タイプ・フィールドと、リコンシリエーション・ステージング・データセットのロール定義フィールドの間に多対1マッピングを作成することはできます。

- 「ソース」親データセットまたは「Oracle Identity Manager」親データセットと、リコンシリエーション・ステージング子データセットまたはプロビジョニング・ステージング子データセットの間には、トランスフォーメーション・マッピングを作成できません。
次の例でこの制限について説明します。

次のような「Oracle Identity Manager」データセットおよびそのフィールドがあるとします。

「OIM - アカウント」データセット

- フィールド1: 名前

- フィールド2: 住所

- フィールド3: ユーザーID

- .. .

次のようなプロビジョニング・ステージング子データセットおよびそのフィールドがあるとします。

「グループ」データセット

- フィールド1: グループ名

- フィールド2: グループ・タイプ

この制限により、たとえば「OIM - アカウント」データセットの「名前」フィールドと「グループ」データセットの「グループ名」フィールドの間には、トランスフォーメーション・マッピングを作成できません。

- リコンシリエーション・ルールを作成するには、リコンシリエーション・ステージング・データセットのフィールドと「OIM - ユーザー」データセットのフィールド間で一致のみのマッピングを作成します。子データセットがある場合は、一致のみのマッピングの入力フィールドとなるリコンシリエーション・ステージング・データセットのフィールドの名前が、リコンシリエーション・ステージング子データセットで使用されていないことを確認してください。
このガイドラインに従っていないと、リコンシリエーションは失敗します。

- 子フォームでフィールドに「日付」データ型を設定するとします。子レコード削除のプロビジョニング操作時にこのフィールドに日付値があると、操作が失敗します。

20.2.3 コネクタ作成中のエラー

次のエラー・メッセージは、汎用テクノロジ・コネクタ作成プロセスの最後に表示される可能性があります。各メッセージでは、エラーの原因となる事象やエラー・メッセージが表示されるタイミングについて説明します。

- 汎用テクノロジ・コネクタconnector_nameのインポートXMLファイルの生成中にエラーが発生しました

- 汎用テクノロジ・コネクタconnector_nameのランタイム・プロバイダ・パラメータに指定された値でITリソース・パラメータを更新中にエラーが発生しました。

- 汎用テクノロジ・コネクタconnector_nameのXMLファイルの生成中、またはOracle Identity Managerデータベースでの同ファイルの保存中にエラーが発生しました。

- 汎用テクノロジ・コネクタconnector_nameのXMLファイルのインポート中にエラーが発生しました。インポート操作に必要なロックを取得できませんでした。

- 汎用テクノロジ・コネクタconnector_nameの情報を保存中にエラーが発生しました。詳細はアプリケーション・ログを確認してください。

- 汎用テクノロジ・コネクタconnector_nameのリソース・オブジェクトの作成中にエラーが発生しました。このリソース・オブジェクトに割り当てられた名前と同じ名前を持つ既存のリソース・オブジェクトが存在します。

20.2.4 リコンシリエーション中のエラー

表20-1に、リコンシリエーション・プロセスに関連して一般的に発生する問題の解決方法を示します。

注意:

これらのエラーがロギングされるのは、共有ドライブ・リコンシリエーション・トランスポート・プロバイダおよびCSVリコンシリエーション・フォーマット・プロバイダを使用している場合のみです。

これらのいずれかのエラーが発生した場合、エラー・メッセージはアプリケーション・サーバーのログ・ファイルに書き込まれます。

表20-1 リコンシリエーション中に発生する一般的なエラー

問題の説明(エラー・メッセージ)

解決策

使用可能なランタイム・プロバイダ・パラメータがありません

「汎用テクノロジ・コネクタの管理」機能を使用して、ランタイム・パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

使用可能な設計時プロバイダ・パラメータがありません

「汎用テクノロジ・コネクタの管理」機能を使用して、設計パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

ステージング・ディレクトリの場所が定義されていません

「汎用テクノロジ・コネクタの管理」機能を使用して、「ステージング・ディレクトリ(親アイデンティティ・データ)」パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

ファイル・エンコーディングが定義されていません

「汎用テクノロジ・コネクタの管理」機能を使用して、ファイル・エンコーディング(親データ)パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

アーカイブ・ディレクトリの場所が定義されていません

「汎用テクノロジ・コネクタの管理」機能を使用して、「アーカイブ・ディレクトリ」パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

固定幅区切りが定義されていないため、ファイルを処理できません

「汎用テクノロジ・コネクタの管理」機能を使用して、次のいずれかのパラメータに値が指定されているかどうかを確認します。

- 指定されたデリミタ

- タブ区切り

- 固定列幅

その後、リコンシリエーションを再試行します。

ステージング・ディレクトリに親ファイルがありません

読取り用のファイルがありません

「ステージング・ディレクトリ(親アイデンティティ・データ)」パラメータの値として指定されたディレクトリにデータファイルがあることを確認します。その後、リコンシリエーションを再試行します。

ステージング・ディレクトリに子データがありません

読取り用のファイルがありません

「ステージング・ディレクトリ(複数値アイデンティティ・データ)」パラメータの値として指定されたディレクトリにデータファイルがあることを確認します。その後、リコンシリエーションを再試行します。

ステージング・ディレクトリにアクセスできません。ディレクトリ・パスが存在しないか、必要なアクセス権限がありません

パラメータ値として指定されたディレクトリに必要な権限があることを確認します。必要な権限の詳細は、第17.1章「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」を参照してください。その後、リコンシリエーションを再試行します。

使用されているファイル・エンコーディングがサポートされていないため、データ・ファイルを読み取れませんでした

「汎用テクノロジ・コネクタの管理」機能を使用して、「ファイル・エンコーディング」パラメータに指定された値を確認します。その後、リコンシリエーションを再試行します。

メタデータを解析できません

親データファイルおよび子データファイルにあるメタデータ(2行目の内容)を確認します。ファイルで使用されている区切りに問題がある可能性があります。問題を解決してから、リコンシリエーションを再試行します。

ヘッダーを解析できません

データファイルのヘッダー(1行目の内容)を確認します。ヘッダーの形式に問題がある可能性があります。ヘッダーの形式の詳細は、第17.1項「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」を参照してください。

問題を解決してから、リコンシリエーションを再試行します。

現行のレコードに問題があるため解析できません

アプリケーション・サーバーのログ・ファイルに書き込まれているエントリを確認します。解析できないエラーが含まれている可能性があります。問題を解決してから、リコンシリエーションを再試行します。

20.2.5 プロビジョニング中のエラー

表20-2に、プロビジョニング・プロセスに関連して一般的に発生する問題の解決方法を示します。

注意:

これらのエラーのほとんどがロギングされるのは、Webサービス・プロビジョニング・トランスポート・プロバイダおよびSPMLプロビジョニング・フォーマット・プロバイダを使用している場合のみです。

これらのいずれかのエラーが発生すると、エラー・メッセージがUIに表示され、アプリケーション・ログ・ファイルに書き込まれます。

表20-2 プロビジョニング中に発生する一般的なエラー

問題の説明

解決策

レスポンス・コード:

SPMLのVelocityプロパティを読み取れません

レスポンスの説明:

SPMLのテンプレート・プロパティを読み取れませんでした。

Oracle Identity Managerインストールに問題があります。Oracleサポート・サービスに連絡して、この問題に関する情報と、表示されるレスポンス・コードおよび説明を送ってください。また、ロギングをDEBUGレベルに設定してOracle Identity Managerを実行した後、生成された関連するログも送ってください。

レスポンス・コード:

SPMLのテンプレートを読み取れません

レスポンスの説明:

SPMLのテンプレート・ファイルが見つかりませんでした。

Oracle Identity Managerインストールに問題があります。Oracleサポート・サービスに連絡して、この問題に関する情報と、表示されるレスポンス・コードおよび説明を送ってください。また、ロギングをDEBUGレベルに設定してOracle Identity Managerを実行した後、生成された関連するログも送ってください。

レスポンス・コード:

SPMLの不明な操作

レスポンスの説明:

このプロビジョニング操作は、許可されている操作(作成、削除、有効化、無効化、変更の操作、または子表に関する操作)ではありません。

Oracle Identity Managerインストールに問題があります。Oracleサポート・サービスに連絡して、この問題に関する情報と、表示されるレスポンス・コードおよび説明を送ってください。また、ロギングをDEBUGレベルに設定してOracle Identity Managerを実行した後、生成された関連するログも送ってください。

レスポンス・コード:

SPMLのプロビジョニングの入力がNULLです

レスポンスの説明:

SPMLのプロビジョニングの入力データがNULLです。

プロバイダ・パラメータを正しく指定したかどうかを確認します。

プロビジョニングがダイレクト・プロビジョニングまたはリクエスト・プロビジョニングのどちらによって開始されたかを確認します。ダイレクト・プロビジョニングのオプションを使用して手順を再試行します。

レスポンス・コード:

SPMLのテンプレート・コンテキスト処理エラー

レスポンスの説明:

SPMLリクエスト生成用のテンプレート・コンテキストの処理中にエラーが発生しました。

Oracle Identity Managerインストールに問題があります。Oracleサポート・サービスに連絡して、この問題に関する情報と、表示されるレスポンス・コードおよび説明を送ってください。また、ロギングをDEBUGレベルに設定してOracle Identity Managerを実行した後、生成された関連するログも送ってください。

レスポンス・コード:

SPMLのプロビジョニングの操作名がありません

レスポンスの説明:

プロビジョニングの操作名がありません。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。構成(プロバイダ)のセットは変えずに属性を減らして別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

レスポンス・コード:

SPMLのプロビジョニングの子の名前がありません

レスポンスの説明:

子の名前がありません。

このエラーが発生した場合、特定のタイプの複数値属性(たとえば、ロールまたはメンバーシップ)に対してプロビジョニングを試行していた可能性があります。

コネクタが正しく作成されていない可能性があります。構成(プロバイダ)のセットは変えずに、複数値属性を1つのみ(最初に失敗した属性)にして、別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

レスポンス・コード:

SPMLのプロビジョニングの子のメタデータがNULLです

レスポンスの説明:

子のメタデータ・リストがNULLです。

このエラーが発生した場合、特定のタイプの複数値属性(たとえば、ロールまたはメンバーシップ)に対してプロビジョニングを試行していた可能性があります。

コネクタが正しく作成されていない可能性があります。構成(プロバイダ)のセットは変えずに、複数値属性を1つのみ(最初に失敗した属性)にして、別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

レスポンス・コード:

SPMLのプロビジョニングの子のメタデータの問題

レスポンスの説明:

子のメタデータ・リストのソート中にエラーが発生しました。

このエラーが発生した場合、特定のタイプの複数値属性(たとえば、ロールまたはメンバーシップ)に対してプロビジョニングを試行していた可能性があります。

コネクタが正しく作成されていない可能性があります。プロビジョニング・フィールドに対して設定された順序に問題があります。関連する複数値フィールドの属性を減らして別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。プロビジョニングが正常に終了するたびに「汎用テクノロジ・コネクタの管理」手順を実行して、フィールドを1つずつ追加してみてください。この問題が再び再び出現した時点で、順序が正しくないフィールドが明らかになります。

レスポンス・コード:

SPMLのプロビジョニングのIDがありません

レスポンスの説明:

一意のIDがありません。

作成済ユーザーに対して操作を実行しようとしています。ただし、「ユーザーの作成」操作そのものが正常に実行されていない可能性があり、レスポンスとして予期される一意のID (psoID)が受信されていません。このため、プロビジョニング済インスタンス・データがOracle Identity Managerで更新されませんでした。この操作が失敗した原因を確認します。

レスポンス・コード:

SPMLのプロビジョニング・ターゲットIDがありません

レスポンスの説明:

一意のターゲットIDがありません。

入力されたプロバイダ・パラメータを確認します。ターゲットIDがない可能性があります。

レスポンス・コード:

OIM APIエラー

レスポンスの説明:

Oracle Identity Manager APIレイヤーでエラーが発生しました。

Oracle Identity Managerが他の操作で正しく動作しているかどうかを確認します。Oracle Identity Managerフロント・エンドとデータベースの間の接続を確認します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

OIMプロセス・フォームが見つかりません

レスポンスの説明:

Oracle Identity Managerにプロセス・フォームが見つかりませんでした。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。同じ構成のセットを使用して別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

OIMプロセス・フォーム・インスタンスが見つかりません

レスポンスの説明:

指定されたフォームのプロセス・フォーム・インスタンスが更新中に見つかりませんでした。

Oracle Identity Managerデータベースのプロビジョニング済インスタンスの情報が破損している可能性があります。ダイレクト・プロビジョニングを試行します。

問題が解消されない場合は、汎用テクノロジ・コネクタに問題がある可能性があります。同じ構成のセットを使用して別の汎用テクノロジ・コネクタを作成します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

OIMアトミック・プロセス・インスタンスが見つかりません

レスポンスの説明:

検出されたプロセス・インスタンスはアトミック・プロセスではありません。

Oracle Identity Managerデータベースのプロビジョニング済インスタンスの情報が破損している可能性があります。ダイレクト・プロビジョニングを試行します。

問題が解消されない場合は、汎用テクノロジ・コネクタに問題がある可能性があります。同じ構成のセットを使用して別の汎用テクノロジ・コネクタを作成します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

列が見つかりません

レスポンスの説明:

必要な列が結果セットに見つかりませんでした。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。同じ構成のセットを使用して別のコネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

無効なプロバイダ

レスポンスの説明:

指定されたプロバイダ名が無効です。

使用しているプロビジョニング・フォーマット、変換またはプロビジョニング・トランスポートのいずれかのプロバイダが正しく登録されていない可能性があります。プロバイダの登録手順を正しく実行したかどうかを確認します。事前定義済プロバイダの使用時にこのエラーが表示される場合は、Oracle Identity ManagerサーバーのディレクトリでこれらのプロバイダのXMLファイルを確認します。これらのXMLファイルはMDSに格納されています。スキーマおよびプロバイダ定義XMLファイルは、次の場所にあります。

PROVIDER_DEF_XSD_LOCATION = "/db/GTC/Schema";

PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions";

レスポンス・コード:

ITリソース・インスタンスが見つかりません

レスポンスの説明:

Oracle Identity ManagerにITリソース・インスタンスが見つかりませんでした。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。同じ構成のセットを使用して別の汎用テクノロジ・コネクタを作成してみてください。ダイレクト・プロビジョニングを試行します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

バージョンが見つかりません

レスポンスの説明:

必要なプロセス・フォーム・バージョンがOracle Identity Managerに見つかりませんでした。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。同じ構成のセットを使用して別のコネクタを作成してみてください。新しいフィールドを既存のデータセットに追加して既存のコネクタを編集した場合、その操作が失敗している可能性があります。コネクタで再度同じ変更を行ってみてください。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

バージョンが定義されていません

レスポンスの説明:

必要なプロセス・フォームのバージョンがOracle Identity Managerに定義されていませんでした。

汎用テクノロジ・コネクタが正しく作成されていない可能性があります。同じ構成のセットを使用して別のコネクタを作成してみてください。新しいフィールドを既存のデータセットに追加して既存のコネクタを編集した場合、その操作が失敗している可能性があります。コネクタで再度同じ変更を行ってみてください。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

Webサービスが見つかりません

レスポンスの説明:

ターゲット・サーバーにWebサービスが見つかりませんでした。サービス名とIPアドレスを確認してください。

WebサービスのURLに指定したサービス名とIPアドレスを確認します。これらが正しい場合は、Webサービスが稼働しているかどうかを確認します。

レスポンス・コード:

Webサービス接続が拒否されました

レスポンスの説明:

Webサービス接続を確立できませんでした。サーバーが稼働中で、指定されたポートが正しいことを確認してください。

Webサービスが稼働中かどうかを確認します。

レスポンス・コード:

Webサービスにそのようなメソッドはありません

レスポンスの説明:

Webサービスのメソッドを開始できませんでした。操作名とパラメータを確認してください。

操作名とパラメータを確認してください。

レスポンス・コード:

Webサービスのパラメータ値がNULLです

レスポンスの説明:

Webサービスに渡されたパラメータ値がNULLです。

プロビジョニング・プロセスが正しく実行されたかどうかを確認します。プロビジョニング・フォーマット・プロバイダが正しく実行されなかったためにNULL出力を生成した可能性があります。

レスポンス・コード:

WebサービスのHTTPライブラリがありません

レスポンスの説明:

クラスパスにWebサービスのHTTPライブラリが含まれていません。

Oracle Identity Managerインストールに問題があります。Oracleサポート・サービスに連絡して、この問題に関する情報と、表示されるレスポンス・コードおよび説明を送ってください。また、ロギングをDEBUGレベルに設定してOracle Identity Managerを実行した後、生成された関連するログも送ってください。

レスポンス・コード:

Webサービスの結果値がNULLです

レスポンスの説明:

Webサービスの結果値がNULLです。

Webサービスが正しく稼働しているかどうかを確認します。現時点で、Webサービスは、Oracle Identity Managerプロビジョニング・リクエストへのレスポンスとしてNULL出力を生成しています。

レスポンス・コード:

Webサービス呼出しの問題

レスポンスの説明:

Webサービスの呼出し中にエラーが発生しました。

Webサービスの資格証明を確認します。

レスポンス・コード:

WebサービスのターゲットURLがありません

レスポンスの説明:

Webサービスの呼出しに必要なWebサービスのターゲットURLがありません。

プロバイダ・パラメータの値を確認します。WebサービスのURLがない場合があります。汎用テクノロジ・コネクタを変更して、再度この値を指定しなおします。

レスポンス・コード:

Webサービスのターゲット・メソッド名がありません

レスポンスの説明:

Webサービスの呼出しに必要なWebサービスのターゲット・メソッド名がありません。

プロバイダ・パラメータの値を確認します。Webサービスの操作名がない場合があります。汎用テクノロジ・コネクタを変更して、再度この値を指定しなおします。

レスポンス・コード:

WebサービスのレスポンスのXML解析エラー

レスポンスの説明:

WebサービスのレスポンスのXML解析中にエラーが発生しました。

Webサービスが正しく稼働しているかどうかを確認します。Webサービス・プロバイダに対して指定された形式に準拠しないSPMLレスポンスを生成しています。

レスポンス・コード:

WebサービスのレスポンスIDエラー

レスポンスの説明:

Webサービスから一意のIDが生成されていないか、レスポンスXMLファイルの属性名が不適切なため、値が解析されませんでした。

Webサービスが正しく稼働しているかどうかを確認します。「ユーザーの作成」操作で、Webサービスが、指定された形式に準拠しないSPMLレスポンスを生成しています。また、ターゲット・システムで作成されたpsoIDを戻していません。Webサービス・プロバイダのプロバイダ指定ではpsoIDフィールドを戻すように指定されています。

レスポンス・コード:

Webサービスのプロトコル接続エラー

レスポンスの説明:

Oracle-SOAP HTTP接続でエラーが発生しました。

WebサービスのURLに指定したサービス名とIPアドレスを確認します。これらが正しい場合は、Webサービスが稼働しているかどうかを確認します。操作名とパラメータを確認してください。

レスポンス・コード:

Webサービスのプロトコル処理エラー

レスポンスの説明:

Oracle-SOAP APIのコール中にエラーが発生しました。

WebサービスのURLに指定したサービス名とIPアドレスを確認します。これらが正しい場合は、Webサービスが稼働しているかどうかを確認します。操作名とパラメータを確認してください。

レスポンス・コード:

日付を解析できません

レスポンスの説明:

日付の解析中にエラーが発生しました。

「ターゲット日付書式」パラメータに指定した値が正しくありません。指定可能な日付書式の詳細は、次のWebページを参照してください。

http://java.sun.com/docs/books/tutorial/i18n/format/simpleDateFormat.html#datepattern

レスポンス・コード:

データ・アクセス・エラー

レスポンスの説明:

問合せの実行中または結果セットのロード中にデータ・アクセス・エラーが発生しました。

Oracle Identity Managerが他の操作で正しく動作しているかどうかを確認します。Oracle Identity Managerフロント・エンドとデータベースの間の接続を確認します。

注意: このエラーは、使用しているプロバイダには関係ありません。

レスポンス・コード:

SSLハンドシェイクは実行されませんでした

レスポンスの説明:

ターゲットWebサービスとのセキュアな通信中にSSLハンドシェイクは実行されませんでした。

Oracle Identity Managerとターゲット・システムの間のSecure Sockets Layer (SSL)構成が正しく完了しているかどうかを確認します。必要に応じて手順を再度実行します。

レスポンス・コード:

SSL関連プロパティの初期化でエラーが発生しました

レスポンスの説明:

SSL関連プロパティの初期化中にエラーが発生しました。関連する値は、MDSにあるoim-config.xmlファイルの"RMSecurity"要素から読み取られます。

oim-config.xmlファイルのRMSecurity要素に対応する構成エントリを確認します。

レスポンス・コード:

Webサービスのキーストアまたはパスワードが無効です

レスポンスの説明:

MDSにあるoim-config.xmlファイルで無効なキーストアの名前またはパスワードが見つかりました。"RMSecurity"要素に対応する構成エントリを確認してください。

oim-config.xmlファイルのRMSecurity要素に対応する構成エントリを確認します。

レスポンス・コード:

Webサービスのキーストア初期化中にエラーが発生しました

レスポンスの説明:

キーストアの初期化に失敗しました。キーストアの資格証明は、oim-config.xmlファイルの"RMSecurity"要素の下に示されています。

oim-config.xmlファイルのRMSecurity要素に対応する構成エントリを確認します。

レスポンス・コード:

IDが無効です

レスポンスの説明:

入力SPMLリクエストに無効なIDがあります。

「ターゲットID」パラメータに指定した値を確認します。

レスポンス・コード:

オブジェクトはすでに存在します

レスポンスの説明:

このオブジェクトはターゲット・システムにすでに存在します。

作成しようとしているオブジェクトがすでにターゲット・システムに存在していないかどうかを確認します。

レスポンス・コード:

操作はサポートされていません

レスポンスの説明:

リクエストされたプロビジョニング操作はサポートされていません。

リクエストしたプロビジョニング操作がターゲット・システムでサポートされているかどうかを確認します。SPMLプロビジョニング・フォーマット・プロバイダを使用して実行できるSPMLプロビジョニング操作のタイプの詳細は、「SPMLプロビジョニング・フォーマット・プロバイダ」を参照してください。

レスポンス・コード:

入力SPMLリクエストのIDタイプが無効です

レスポンスの説明:

入力SPMLリクエストに無効なIDタイプがあります。

送ったリクエストのタイプに対応するサンプルSPMLリクエストを確認し、ターゲット・システムでそのリクエストに含まれていたすべてのID値がサポートされているかどうかを確認します。

レスポンス・コード:

入力SPMLリクエストにあるIDがターゲット・システムに存在しません

レスポンスの説明:

入力SPMLリクエストにあるIDがターゲット・システムに存在しません。

リクエストで送ったpsoID値がターゲット・システムに存在することを確認します。

レスポンス・コード:

リクエストされた実行モードはサポートされていません

レスポンスの説明:

リクエストされた実行モードはサポートされていません。

同期モードでのリクエストの実行が、ターゲット・システムでサポートされていることを確認します。

レスポンス・コード:

無効なコンテナ

レスポンスの説明:

指定されたコンテナにオブジェクトを追加できません。詳細はログ・ファイルを参照してください。SPMLレスポンスにある要素"errorMessage"の値を確認します。

リクエストで指定したコンテナIDに対応するコンテナが、ターゲット・システムに存在するかどうかを確認します。

レスポンス・コード:

非標準のSPMLのエラーが発生しました

レスポンスの説明:

ターゲット固有のエラーが発生しました。詳細はログ・ファイルを参照してください。SPMLレスポンスにある要素"errorMessage"の値を確認します。

SPMLレスポンスのerrorMessage要素の値を確認します。この要素には、エラーの発生時に生成された、ターゲット・システムのエラー・メッセージが含まれます。

レスポンス・コード:

SPMLレスポンスは非同期モードです

レスポンスの説明:

SPMLレスポンスは非同期モードですが、サポートされていません。

リクエスト実行の同期モードに対応するレスポンスが、ターゲット・システムから送信されていることを確認します。

レスポンス・コード:

WebサービスURLの構成要素の解析中にエラーが発生しました

レスポンスの説明:

WebサービスURLの構成要素の解析中にエラーが発生しました。指定したURLにプロトコル、ホスト名、ポートおよびエンドポイントが含まれているかどうかを確認してください。コネクタ作成中にプロバイダ・パラメータ値を指定するとき、関連WSDLファイルからURLをコピーすることをお薦めします。

指定したURLにプロトコル、ホスト名、ポートおよびエンドポイントが含まれているかどうかを確認します。コネクタ作成中にプロバイダ・パラメータ値を指定するとき、関連WSDLファイルからURLをコピーすることをお薦めします。

レスポンス・コード:

SPMLレスポンスは、V2スキーマ検証に失敗しました

レスポンスの説明:

受信したSPMLレスポンスは、SPML V2標準仕様に準拠していません。

ターゲット・システムによって戻されたSPMLレスポンスが、SPML V2標準仕様に準拠していることを確認します。

第IV部

リクエストおよび承認プロセス

この部は、リクエストおよびSOAコンポジットの構成方法について説明する各章で構成されています。

次の章で構成されます。

- 第21章「承認および手動プロビジョニングのワークフローの開発」

- 第22章「職務の分離(SoD)の使用」

21 承認および手動プロビジョニングのワークフローの開発

この章では、Oracle Identity Managerのワークフローの概念、機能およびアーキテクチャについて説明します。ワークフローのユースケース、最初のワークフローの設計、実装およびデプロイの手順を示します。また、この章では、プラグイン・ポイントを使用してリクエスト管理操作を拡張する方法についても説明します。

この章の内容は次のとおりです。

- ワークフローの概要

- 新しいSOAコンポジットの作成

- ワークフローの開発: Vision社のリクエストのチュートリアル

- デフォルトのリクエスト・レベルおよび操作レベルの承認コンポジットの構成

- カスタム・タスク詳細タスクフローの作成およびデプロイ

- リクエスト・データセットの理解

- リクエスト管理操作の拡張

- 自己登録リクエストの自動承認の有効化

21.1 ワークフローの概要

この項では、主なワークフローの概念について、次の各項で説明します。

- ワークフローの概要

- ワークフローの概念

- ワークフローのアーキテクチャ

21.1.1 ワークフローの概要

ユーザー・アクセスを管理し、ビジネス・プロセスを編成して、ユーザーが適切なアクセス権を取得できるようにすることが、アイデンティティ制御の主要機能となります。ユーザーのアクセスを変更するプロセスは、ポリシーをトリガーするHRのイベントを介してユーザーが開始するか、または管理者が開始することができます。アクセスの変更がどのように開始されるかに関係なく、組織には次の要件があります。

- 開始されるビジネス・プロセスは柔軟で、組織の変化するビジネス・ルールに適合できる必要があります。

- ビジネス・プロセスでは、即時アクセス権を付与するか、アクセス権を付与する前に手動操作の手順を導入して承認を求めるかを決定できる必要があります。

- ビジネス・プロセスは、リクエストされた内容、リクエスト者、リクエストの対象者およびコンテキストに関する職務の分離(SoD)チェックなど、検証を実行できる必要があります。

- 手動操作が必要な場合、ビジネス・プロセスには、ユーザーまたはユーザー・グループに割り当てる機能、および応答がタイミングよく受信されなかったときにエスカレーション、再割当てまたは期限切れの処理を行う機能が必要です。

- 手動操作の場合、ビジネス・プロセスには、承認者から、コメントや添付ファイルなどの情報を収集する機能が必要です。

- アクセス権の自動付与が不可能な場合、または組織のルールによって手動によるアクセス権付与が必要な場合、ビジネス・プロセスでは、外部システム(チケット発行システムなど)と対話できる必要があります。

- すべての決定およびアクションを監査し、報告可能な方法で利用可能にして、組織がプロセスのパフォーマンスを計測したり、監査者がコンプライアンス要件を満たすことができるようにする必要があります。

Oracle Identity Managerでは、組織がこれらの要件を満たすことができる、柔軟かつ強力なアクセス・リクエスト機能が提供されています。

21.1.2 ワークフローの概念

Oracle Identity Managerのワークフローの主要概念として、次のような用語があります。

- リクエスト
Oracle Identity Managerでは、リクエストは、あるアイデンティティまたはアカウントで操作を実行する必要がある場合に起動されるビジネス・プロセスを指します。これらの操作の例として、ユーザーの作成、アカウントのプロビジョニング、ユーザーへのロールの付与があります。リクエストには、すぐに履行可能な場合(直接的な操作)と、承認の形式で手動操作が必要な場合(リクエストベースの操作)があります。ユーザーが操作を実行しようとすると、Oracle Identity Managerは、その操作が直接的であるか、ログイン中のユーザーの認可ポリシーに基づくリクエストベースであるかを確認します。

- リクエスト・レベルの承認
リクエストは、履行に進む前に、2つの独立した承認プロセスを通過する必要があります。リクエスト・レベル承認および操作レベル承認です。リクエスト・レベル承認は最初に起動され、操作レベル承認が後に続きます。リクエスト・レベル承認は主にバルク・リクエストに使用されますが、バルク・リクエストには複数のターゲット・ユーザー、複数のリクエストされたエンティティ、またはその両方の任意の組合せが関係します。

バルク承認の場合は、リクエスト・レベル承認が受信されると、リクエスト・エンジンによって、リクエストが個々のターゲット・ユーザーおよびリクエストされた操作またはエンティティの組合せに分割され、組合せごとに操作の承認が起動されます。

- 操作レベルの承認
操作レベル承認は、2番目の承認プロセスであり、リクエスト承認の一環として起動されます。操作の承認は、常に単一のターゲット・ユーザーおよび単一の操作またはリクエストされたエンティティに対して行われます。

- 承認ポリシー
承認ポリシーは、リクエスト・エンジンが、起動するSOAコンポジットを選択できるルールです。承認ポリシーは、リクエスト・レベルまたは操作レベルで構成できます。これらでは、リクエスト・レベルおよび操作レベルで使用可能なすべてのデータを使用してルールを構築できます。このルールを使用して、リクエスト・エンジンは、そのリクエストを自動承認するのか、SOAコンポジットを起動する必要があるのかを決定します。

- SOAコンポジット
SOAコンポジットは、単一のアプリケーション内に一括して設計されデプロイされた複数のサービス、サービス・コンポーネントおよび参照の集合です。このサービス、サービス・コンポーネントおよび参照間のワイヤリングによってメッセージ通信が可能となります。コンポジットにより、メッセージに記述された情報が処理されます。

- パートナ・リンク
パートナ・リンクを使用すると、BPELプロセス・サービス・コンポーネントと対話する外部サービスを定義できます。パートナ・リンクは、SOAコンポジット・エディタまたはOracle BPELデザイナのBPELプロセス・サービス・コンポーネント内にサービスまたは参照(JCAアダプタ経由など)として定義できます。

- BPELプロセス
BPELプロセスは、プロセスの編成と、同期または非同期プロセスの保存に使用されます。一連のビジネス・アクティビティとサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計します。

- ITプロビジョナ
ITプロビジョナは、履行ユーザーまたはヘルプ・デスク・ユーザーとも呼ばれ、手動のプロビジョニング・リクエストの履行を担当する人です。

- リクエストWebサービス
リクエストWebサービスは、Oracle Identity Managerに付属するWebサービスです。顧客がリクエスト、ユーザー、ロール、組織、アカウント、権限、アプリケーション・インスタンスおよびカタログ情報を公開できるようにし、承認ワークフローによってデータ・ドリブンのルーティング決定が実行されるようにします。

- リクエスト・コールバック
リクエスト・コールバックは、承認結果(承認/拒否)の受信時にSOAコンポジットによって起動されるWebサービスです。リクエスト・エンジンは、承認の目的でSOAコンポジットを起動すると、このコンポジットがリクエスト・コールバックを起動して承認または拒否の決定を提供するまで、リクエストを一時停止します。この決定によって、リクエスト・エンジンは、リクエストの履行(承認された場合)、リクエストの拒否(拒否された場合)に進むことができます。

- プロビジョニング・コールバック
プロビジョニング・コールバックは、接続なしのプロビジョニングの一部として起動されるWebサービスです。ITプロビジョナまたは履行ユーザーが、接続なしのプロビジョニング・リクエストを履行し、タスクを完了とマークすると、SOAコンポジットはプロビジョニング・コールバックを起動して、プロビジョニング・ワークフローの完了を許可するプロビジョニング・ステータスを送信します。

- リクエスト・ペイロード
リクエスト・エンジンはSOAコンポジットを起動して、それにリクエスト、リクエスタおよびターゲット・ユーザーに関するいくつかの基本情報を渡します。この情報をリクエスト・ペイロードと呼びます。

- ヒューマン・タスク
ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。

21.1.3 ワークフローのアーキテクチャ

ワークフローは、Oracle Identity Managerで次の目的に使用されます。

- 承認のために、承認者にリクエストをルーティングする

- 履行のために、ITプロビジョナまたはヘルプ・デスクに手動のプロビジョニング・タスクをルーティングする

図21-1に、Oracle Identity Managerのワークフローの概要を示します。

図21-1 ワークフローのアーキテクチャ

図21-1では、次のアクションが発生しています。

1. ユーザーは、結果としてリクエストになる操作を開始します。そのような操作の例を次に示します。

- 自己登録

- ユーザー・プロファイルの変更(ただし、ロックの、ロック解除およびパスワードの管理操作を除く)

- ロール付与操作

- アプリケーション・インスタンス操作(接続なしのプロビジョニングを含む)

- 権限操作

- バルク操作

2. リクエストが作成されます。適切な検証の後に、リクエスト・エンジンは承認ポリシーを評価し、起動するSOAコンポジットを選択します。

3. 承認ポリシーが構成されていない場合、リクエスト・レベル承認に対してはデフォルトのリクエスト・レベルSOAコンポジットが選択され、操作レベル承認に対してはデフォルトの操作レベルSOAコンポジットが選択されます。

4. SOAコンポジットには、Business Process Execution Language (BPEL)プロセスが含まれています。

5. BPELプロセスは、Webサービスを起動して、リクエストに関する次のような詳細を取得します。

注意:

このステップはオプションです。これは、BPELプロセスで様々なエンティティに関連する追加情報が必要な場合にのみ、必要です。

- カタログからの項目の詳細

- ターゲット・ユーザー情報

- リクエスタ情報

6. BPELプロセスは、優先度、承認者および通知などのプロパティを計算するために、追加のロジックを起動します。

7. 承認および手動の履行中など、手動操作が必要な場合、プロセスはヒューマン・タスクを起動します。
ヒューマン・タスクには、ユーザーまたはロールに対して承認タスクの割当て、期限切れ、エスカレーションを実行するためのロジックが含まれます。ヒューマン・タスクは、ユーザーおよびロールを静的または動的に割り当てることができます。静的割当ての場合、BPELプロセスで承認者を決定し、パラメータとしてヒューマン・タスクに渡すことができます。動的割当ての場合、Oracle Business Rules (OBR)で作成されたルールを使用して、承認者が動的に決定されます。

通常、BPELプロセスには1つのヒューマン・タスクが含まれます。インスタンスによっては、BPELプロセスで複数のヒューマン・タスクのうちの1つを選択するデシジョン・ポイントが起動される場合があります。

8. ヒューマン・タスクが完了すると、(承認の)承認または拒否のレスポンス、あるいは(手動履行の)完了のレスポンスが、Oracle Identity Managerへのコールバック・サービスを介して戻され、操作が再開されます。

21.2 新しいSOAコンポジットの作成

承認プロセスとして使用できる新規SOAコンポジットを作成するには、次の手順を実行します。

1. 新しいSOAコンポジットの作成

2. SOAコンポジットのOracle SOAサーバーへのデプロイ

3. SSLモードでのOracle Identity Managerとの通信のための前提条件

21.2.1 新しいSOAコンポジットの作成

SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。このような基準によって、リクエスト・サービスはコンポジットを適切にインスタンス化し、管理できます。基準は、次のとおりです。

- 次の属性はBPELプロセスに必須です。

- タイプが文字列のRequestID

- タイプが文字列のRequestModel

- タイプが文字列のRequestTarget

- タイプが文字列のURL

- XML要素のRequesterDetails

- XML要素のBeneficiaryDetails

- XML要素のObjectDetails

- XML要素のOtherDetails

RequestID、RequestModel、RequestTargetおよびURL属性には、常に、すべてのタイプのリクエストの有効な値が設定されます。

RequesterDetailsはXML要素です。この要素には、認証を必要とするすべてのリクエストの有効な値が入力されます。タイプが自己登録ユーザーのリクエストは、リクエスタが匿名ユーザーのため、リクエスタの詳細が空です。

BeneficiaryDetailsはXML要素です。この要素には、「リソースのプロビジョニング」、「ロールの割当て」など、受益者があるすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1人の受益者に関連している場合にのみ入力されます。リクエストが複数の受益者に関連している場合、BeneficiaryDetailsは空になります。BeneficiaryDetails要素には、常に、受益者がある単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1人の受益者にのみ関連付けられているためです。

ObjectDetailsはXML要素です。この要素には、リソース・エンティティに関連付けられているすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1つのリソースに関連している場合にのみ入力されます。リクエストが複数のリソースに関連している場合、ObjectDetailsは空になります。ObjectDetails要素には、常に、リソースに関連付けられている単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1つのリソースにのみ関連付けられているためです。

- BPELプロセスに必須のすべての属性は、RequestDetails.xsdおよびApprovalProcess.xsdから参照されます。これらのファイルは、変更または削除できないテンプレートSOAコンポジットにあります。

Oracle Identity Managerでは、カスタムSOAコンポジットを作成するヘルパー・ユーティリティが提供されます。このユーティリティでは、必要な基準のすべてに準拠したテンプレートSOAプロジェクトが作成されます。このユーティリティは、OIM_HOME/workflows/new-workflowディレクトリに配置されています。

注意:

- JAVA_HOME環境変数を設定してから、このユーティリティを実行する必要があります。

- このユーティリティには、Apache Antバージョン1.7以上が必要です。

ヘルパー・ユーティリティを実行してカスタムSOAコンポジットを作成するには、次の手順を実行します。

1. 次のコマンドを実行します。

cd OIM_HOME/workflows/new-workflow
ant -f new_project.xml

2. 次のプロンプトが表示されたら、JDeveloperアプリケーション名を入力します。
Please enter application name

3. 次のプロンプトが表示されたら、JDeveloperプロジェクト名を入力します。
Please enter project name

4. 次のプロンプトが表示されたら、コンポジットのADFバインディング・サービスの名前を入力します。
Please enter the service name for the composite. This needs to be unique across applications

OIM_HOME/workflows/new-workflow/process-template/ディレクトリに新規アプリケーションが作成されます。新規アプリケーションは、JDeveloperで開いて変更できます。

テンプレートSOAコンポジットのヒューマン・タスクは、ヒューマン・タスクの割当て先に通知を送信するよう構成されています。作成されたカスタム・コンポジットでは、要件に応じて通知メッセージを変更できます。承認者に送信されるすべての通知は、SOAコンポジットで構成する必要があります。通知を送信するようにOracle SOAサーバーを構成する方法は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する説明を参照してください。

テンプレートSOAコンポジットのヒューマン・タスクは、SYSTEM ADMINISTRATORSロールに割り当てられるよう構成されています。

21.2.2 SOAコンポジットのOracle SOAサーバーへのデプロイ

BPELへのワークフロー・コンポジットのデプロイの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

注意:

コンポジットがSOAで再デプロイされる場合、コンポジットによって開始されたOracle Identity Managerの保留中のすべての承認が失効となり、ユーザーのTaskListから削除されます。既存のSOAコンポジットのデプロイの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のOracle JDeveloperでの既存のSOAアーカイブのデプロイに関する説明を参照してください。

21.2.3 SSLモードでのOracle Identity Managerとの通信のための前提条件

Oracle Identity Managerとの通信でSSLモードを使用している場合は、次を実行する必要があります。

注意:

非SSL接続の場合は、この項をスキップしてください。

- TRUSTSTORE_LOCATION環境変数を設定します(TRUSTSTORE_LOCATIONは信頼できるキー・ストア・ファイルの場所です)。

- t3プロトコルではなくt3sプロトコルを使用します。たとえば、Oracle Identity ManagerのURLは次のようになります。
t3s://HOST_NAME:PORT

21.3 ワークフローの開発: Vision社のリクエストのチュートリアル

この項では、最初のワークフローを設計する方法について、次の各項で説明します。

- チュートリアルの概要

- 前提条件

- アプリケーション・インスタンスの作成

- カタログでのFinAppの構成

- 承認用SOAコンポジットの作成と構成

21.3.1 チュートリアルの概要

このチュートリアルは、次のユースケースに基づいています。

- Vision Corp社は、FinApp(メインフレームベースのアプリケーション)を使用しています。このアプリケーションは、リモートから起動可能なAPIを持ちません。したがって、アカウントはヘルプ・デスクによって手動で管理されます。

- Vision Corp社の従業員は、アクセス・リクエスト・カタログを使用して、アプリケーションでアカウントおよび権限をリクエストします。

- 承認は、リクエストされているアクセスのリスク・レベルに基づいて行われます。リスク・レベルが低い場合、必要なのは受益者のマネージャの承認のみです。リスク・レベルが中の場合、受益者のマネージャまたは認証者の承認が必要です。リスク・レベルが高の場合、受益者のマネージャおよび監査レビュー・チームの承認が必要です。

- 承認の後、リクエストはアセット管理チームのメンバーによって履行される必要があります。

このチュートリアルでは、アプリケーションとワークフローの作成方法、およびアプリケーションでの承認および履行の構成方法について説明します。

このチュートリアルでは、次の結果が得られます。

- アプリケーション・インスタンス

- 次で構成される、承認用のSOAコンポジット

- 1つのBPELプロセス

- 複数のヒューマン・タスク

- 事前定義された接続なしのプロビジョニングSOAコンポジットの変更

21.3.2 前提条件

このチュートリアルでは、次を前提としています。

- Oracle SOA Suiteは、SOAインフラストラクチャが構成されているホストにインストールされています。

- JDeveloper 11.1.1.6と、SOA Design Time 11.1.1.6が使用可能です。

- BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数について理解しているユーザーを対象にしています。

- SOAコンポジット・エディタとOracle BPELデザイナ(BPELプロセスを設計およびデプロイするための環境)を熟知している必要があります。

- 2つのロール(監査レビュー・チームおよびアセット管理チーム)が作成され、メンバーが割り当てられています。

- リクエストWebサービスがデプロイされ、構成されています。リクエストWebサービスのデプロイの詳細は、「リクエストWebサービスのデプロイ」を参照してください。

- Visionという名前の組織が作成されています。

- 監査レビュー・チームという名前のロールが作成されています。

21.3.2.1 リクエストWebサービスのデプロイ

リクエストWebサービスをデプロイするには、次の手順を実行します。

1. Oracle Enterprise Managerにログインします。

2. 左側のペインで、「WebLogicドメイン」を開きます。

3. そのドメイン(たとえばiam_domain)をクリックします。

4. ドメイン名の下の「WebLogicドメイン」をクリックし、「アプリケーションのデプロイ」、「デプロイ」を選択します。

5. 「アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。」オプションを選択します。

6. 「参照」をクリックしてファイル・ブラウザ・ポップアップを開き、次のWebサービスを選択します。
OIM_HOME/server/webapp/optional/reqsvc.ear.

7. ターゲット・サーバーにoim_server1を選択し、表示される指示に従ってWebサービスをデプロイします。

21.3.2.2 Webサービスの保護

リクエストWebサービスは、wss_username_token_service_policyセキュリティ・ポリシーで保護されています。したがって、Webサービスに対するクライアントとして動作するコンポジットは、認証のためにユーザー名およびパスワードを検証して渡す必要があります。つまり、CSFにシステム管理者の資格証明を格納する必要があります。

CSFに資格証明を格納するには、次の手順を実行します。

1. Oracle Enterprise Managerにログインします。

2. 左側のペインで、「WebLogicドメイン」を開きます。

3. 「WLS_DOMAIN」を右クリックします。「セキュリティ」→「資格証明」の順に選択します。

4. oracle.wsm.securityを選択し、「キーの作成」をクリックします。「キーの作成」ダイアログ・ボックスが表示されます。

5. 次の詳細を入力します。

- マップの選択: oracle.wsm.security

- キー: requestwskey

- タイプ: パスワード

- ユーザー名: Oracle Identity Managerシステム管理者のログインID

- パスワード: Oracle Identity Managerシステム管理者のパスワード

6. 「OK」をクリックします。

21.3.3 アプリケーション・インスタンスの作成

この項には次のトピックが含まれます:

- FinAppアプリケーション・インスタンスの作成

- アプリケーション・インスタンス属性の定義とフォームの作成

- 1つ以上の組織へのアプリケーション・インスタンスの公開

- アプリケーション・インスタンスへの権限のリンク

- カタログへのアプリケーション・インスタンスおよび権限の公開

21.3.3.1 FinAppアプリケーション・インスタンスの作成

FinAppアプリケーション・インスタンスを作成するには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。

2. 「サンドボックス」をクリックして、サンドボックス管理にアクセスし、サンドボックスを作成し、それをアクティブにします。サンドボックスの詳細、サンドボックスの作成、アクティブ化および公開方法については、「サンドボックスの管理」を参照してください。

3. 「構成」で、「アプリケーション・インスタンス」をクリックします。ツールバーで「作成」をクリックして、「アプリケーション・インスタンスの作成」ページを開きます。

4. 「名前」および「表示名」に、FinAppと入力します。

5. 「切断」オプションを選択して、接続なしアプリケーション・インスタンスを指定します。

6. 「保存」をクリックし、「OK」をクリックして、FinAppアプリケーション・インスタンスの作成を確認します。

21.3.3.2 アプリケーション・インスタンス属性の定義とフォームの作成

アプリケーション・インスタンスの属性を定義し、フォームを作成するには、次の手順を実行します。

1. 「構成」で、「フォーム・デザイナ」をクリックします。

2. FinAppフォームを検索して選択します。このフォームは、接続なしアプリケーション・インスタンスを保存すると自動的に作成されます。

注意:

フォームを作成して編集するには、アクティブなサンドボックスで作業している必要があります。

3. 「フィールド」タブをクリックし、ツールバーで「編集」アイコンをクリックします。
デフォルトでは、次のフィールドが作成され、使用可能になります。

フィールド

説明

ITリソース

アカウントが作成されるITリソース・インスタンス

アカウント・ログイン

アプリケーションのログイン

パスワード

アプリケーションへのログイン中に使用されるパスワード

アカウントID

アカウントの作成時に、アプリケーションによって生成される一意の識別子

サービス・アカウント

アクセス・リクエスト中のみに使用されるフラグ

注意:

「アカウントID」および「ITリソース」などの属性は、通常、アクセス・リクエスト・ユーザー・インタフェースには表示されません。ユースケースによっては、これらの属性と関係がない場合があります(たとえば、携帯電話リクエスト)。これらの属性を非表示にする場合は、フォームをカスタマイズできます。フォームをカスタマイズする方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のカスタム属性の構成に関する説明を参照してください。

4. 属性を追加します。この例では、次の属性を追加します。
Account Description: データ型はTextです。

Default Profile: データ型はLookupです。

5. 属性を追加した後に、構成が図21-2と同様であることを確認します。

図21-2 属性

6. ユーザーが権限をリクエストするのを許可するには、子オブジェクトを追加し、権限としてタグ付けされる属性を追加する必要があります。これを行うには、次の手順を実行します。

1. 「子オブジェクト」タブをクリックし、ツールバーで「追加」をクリックします。

2. プロファイルおよび子オブジェクト名を入力し、「OK」をクリックして子オブジェクトを作成します。

3. 子オブジェクトをクリックして、それに属性を追加します。Lookup型のProfile Nameという名前の属性を追加します。

4. 「バルクで使用」を選択して、複数のユーザーのアクセスをリクエストするときに、リクエスタによる値の指定を許可します。

5. Default Profile属性をLookup型として作成する際に、Lookup.FinApp.Profilesと呼ばれる新しいLookup型を作成します。

6. 次に示すように、新しいLookupを作成し、値を指定します。
Meaning: Lookup.FinApp.Profile

Description: Lookup.FinApp.Profile

7. 次の表に示す値を使用して、3つの参照コードを作成します。

意味

コード

FinAppユーザー

FinAppUser

FinApp管理者

FinAppAdministrator

FinAppオペレータ

FinAppOperator

注意:

スケジュール済タスクと参照APIを使用して、参照定義を移入することもできます。

8. 「検索可能」、「権限」および「「検索可能」ピックリスト」オプションを選択します。属性構成が図21-3と同様であることを確認します。

図21-3 属性の構成

7. 「親オブジェクトに戻る」をクリックします。

8. 「ビューの再生成」をクリックして、新しい属性でUIフォームを再作成します。

9. すべてのタブを閉じます。

10. サンドボックスを公開します。

21.3.3.3 1つ以上の組織へのアプリケーション・インスタンスの公開

1つ以上の組織にアプリケーション・インスタンスを公開するには、次の手順を実行します。

1. FinAppアプリケーション・インスタンスの詳細ページを開き、「組織」タブをクリックします。

2. 「割当て」をクリックします。「組織の選択」ダイアログ・ボックスで、アプリケーション・インスタンスを公開する組織を1つ以上選択します。

3. アプリケーション・インスタンスをその組織と子組織に公開する場合は、「階層」オプションを選択します。

4. 「OK」をクリックします。

21.3.3.4 アプリケーション・インスタンスへの権限のリンク

権限をアプリケーション・インスタンスにリンクするには、次の手順を実行します。

1. 「システム管理」で「スケジューラ」をクリックします。

2. 権限リスト・スケジュール済ジョブを検索し、「即時実行」をクリックします。

3. 「構成」で「アプリケーション・インスタンス」をクリックし、FinAppアプリケーション・インスタンスに移動します。

4. 図21-4に示すように、「権限」タブをクリックして、権限が表示されることを確認します。

図21-4 権限のリスト

5. 図21-5に示すように、権限を選択し、それがアプリケーション・インスタンスと同じ組織に公開されていることを確認します。

図21-5 組織への権限の可用性

6. 1つ以上の権限を編集し、ビジネス・フレンドリな説明を入力します。必要に応じて、表示名も同様に変更します。

21.3.3.5 カタログへのアプリケーション・インスタンスおよび権限の公開

カタログにアプリケーション・インスタンスとその権限を公開するには、次の手順を実行します。

1. 「システム管理」で「スケジューラ」をクリックします。

2. カタログの同期化スケジュール済ジョブを検索し、「即時実行」をクリックします。

21.3.4 カタログでのFinAppの構成

カタログでアプリケーション・インスタンスとその権限を構成するには、次の手順を実行します。

1. Oracle Identity Self Serviceにカタログ管理者としてログインします。

2. 「リクエスト」で「カタログ」をクリックします。

3. 「カタログ」ページで、アプリケーション・インスタンスを検索します。

4. アプリケーション・インスタンスを選択し、カタログ項目の詳細を編集します。

5. デフォルト属性の値を提供します。このチュートリアルでは、リスク・レベルと手動の履行に基づいてワークフロー・ルーティングが行われるため、「リスク・レベル」と「履行ロール」属性の値を指定する必要があります。ただし、その他の属性の値も指定することをお薦めします(特に「ユーザー定義タグ」)。
図21-6は、カタログ項目の属性を示しています。

図21-6 カタログ項目の属性

21.3.5 承認用SOAコンポジットの作成と構成

この項には次のトピックが含まれます:

- 承認ワークフローの作成

- WSDLおよびXSDファイルのコピー

- パートナ・リンクの構成

- BPELプロセスに対するリクエストおよびカタログ・データの使用可能化

- ワークフローの選択の構成

- ヒューマン・タスクの構成

- ヒューマン・タスクとBPELのマッピングの構成

- SOAコンポジットのデプロイ

- 承認ポリシーの作成

21.3.5.1 承認ワークフローの作成

新しい承認ワークフローを作成するには、次の手順を実行します。

1. WebLogic Serverのインストール・ディレクトリの/server/bin/サブディレクトリにあるsetWLSEnv.shスクリプトを実行して、JAVA_HOME環境変数を設定します。

2. ANT_HOME環境変数をMIDDLEWARE_HOME/modules/org.apache.ant_1.7.1に設定します。

3. PATH環境変数を$JAVA_HOME/bin:$ANT_HOME/bin:$PATHに設定します。

4. OIM_HOME/server/workflows/new_workflowに移動します。

5. 次のコマンドを実行します。

comment ant-f new_project.xml

6. アプリケーション名としてAddAccessApprovalApplicationを指定します。

7. プロジェクト名としてAddAccessApprovalを指定します。

8. サービス名としてAddAccessを指定します。

9. ユーティリティによってコンポジットを含む新しいJDeveloperワークスペースが生成されるまで待ちます。ワークスペースは、/server/workflows/new-workflow/process-template内に生成されます。

10. そのディレクトリをJDeveloperからアクセス可能な場所にコピーします。

21.3.5.2 WSDLおよびXSDファイルのコピー

WSDLおよびXSDファイルをコピーするには、次の手順を実行します。

1. リクエストWebサービスEARのreqsvc.earを、OIM_HOME/webapp/optional/から、SOAコンポジットをコピーした場所にコピーします。

2. そのreqsvc.warファイルの名前をreqsvc.zipに変更して解凍します。

3. 解凍したreqsvc.war内で、/reqsvc/reqsvc/WEB-INF/wsdl/に移動します。

4. xsdディレクトリおよびwsdlファイルを/JDeveloper/mywork/AddAccessApprovalApp/AddAccessApproval/ディレクトリにコピーします。

5. xsdディレクトリで、テキスト・エディタを使用して新しいファイルを作成し、それにBusinessRule.xsdという名前を付けます。次のコードをBusinessRule.xsdファイル内にコピーします。

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://oracle.businessrule"
targetNamespace="http://oracle.businessrule"
elementFormDefault="qualified">
<xsd:complexType name="stage">
<xsd:sequence>
<xsd:element name="stageType" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="StageOutput" type="stage"/>
</xsd:schema>

6. BusinessRule.xsdを保存して閉じます。

21.3.5.3 パートナ・リンクの構成

パートナ・リンクを構成するには、次の手順を実行します。

1. AddAccessApproval JDeveloperプロジェクトを開きます。

2. SOAコンポジットをダブルクリックして開きます。

3. ApprovalProcess BPELプロセスをダブルクリックします。

4. パートナ・リンクを作成するには、図21-7に示すように、「パートナ・リンク」スイム・レーンを右クリックし、「パートナ・リンクの作成」をクリックします。

図21-7 「パートナ・リンク」スイム・レーン

5. 「パートナ・リンクの作成」ダイアログ・ボックスで、名前としてRequestWSPartnerLinkを入力します。

6. WSDL URLを指定するには、図21-8に示すように「SOAリソース・ブラウザ」アイコンをクリックし、requestdataservice.wsdlを選択します。

図21-8 「パートナ・リンクの作成」ダイアログ・ボックス

7. 次の値を入力してパートナ・リンクを作成し、「適用」→「OK」の順にクリックします。

- WSDL URL: requestdataservice.wsdl

- パートナ・ロール: RequestDataServiceProvider

8. 「コンポジット」ビューに切り替えます。図21-9に示すように、新しく作成したパートナ・リンクを右クリックし、「WSポリシーの構成」を選択します。「SOA WSポリシーの構成」ダイアログ・ボックスが表示されます。

図21-9 「WSポリシーの構成」

9. 「セキュリティ」セクションで「追加」アイコンをクリックします。クライアント・セキュリティ・ポリシーの選択ダイアログ・ボックスが表示されます。

10. oracle/wss_username_token_client_policyを選択し、「OK」をクリックします。

11. 「セキュリティ」セクションに追加したポリシーを選択します。

12. 「編集」アイコンをクリックします。オーバーライド・プロパティの構成ダイアログ・ボックスが表示されます。

13. CSFキー・パラメータを選択し、その値としてrequestwskeyを入力し、「OK」をクリックします。
リクエストWebサービスが構成されます。

21.3.5.4 BPELプロセスに対するリクエストおよびカタログ・データの使用可能化

BPELプロセスに対してリクエストおよびカタログ・データを使用可能にするには、次の手順を実行します。

1. assignアクティビティを追加して、図21-10に示すようにAssignRequestWSURLという名前を付けます。

図21-10 AssignRequestWSURL

2. そのアクティビティを選択し、「ソース」ビューでBPELプロセスを開きます。

3. <assign name="AssignRequestWSURL"/>行を次と置き換えます。

<assign name="AssignRequestWSURL">
<copy>
<from><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address/>
</EndpointReference>
</from>
<to variable="partnerLink"/>
</copy>
<copy>
<from expression="concat(substring-before(bpws:getVariableData('inputVariable','payload','/ns3:process/ns4:url'),'workflowservice'),'reqsvc/reqsvc')"/>
<to variable="partnerLink" query="/ns14:EndpointReference/ns14:Address"/>
</copy>
<copy>
<from variable="partnerLink"/>
<to partnerLink="RequestWSPartnerLink"/>
</copy>
</assign>

4. 「設計」ビューに戻ります。

5. コンポーネント・パレットからinvokeアクティビティをドラッグして、AssignRequestWSURLアクティビティの後にドロップします。名前をInvokeRequestDetailsOperationに変更します。

6. 「InvokeRequestDetailsOperation」を右クリックし、「編集」を選択します。

7. 図21-11に示すように、「パートナ・リンク・チューザ」からパートナ・リンクとしてRequestWSPartnerLinkを、操作としてgetRequestDetailsを選択します。

図21-11 パートナ・リンクと操作

8. 「変数」セクションの「入力」および「出力」フィールドでプラス(+)アイコンをクリックして、入力変数および出力変数を作成します。入力変数にrequestDetails_InputVariable、出力変数にrequestDetails_OutputVariableという名前を付けます。「適用」をクリックし、「OK」をクリックします。

9. assignアクティビティをドラッグ・アンド・ドロップし、名前をAssignRequestInputに変更し、図21-12に示すようにInvokeRequestDetailsOperation invokeアクティビティの前に配置します。

図21-12 AssignRequestInput

10. AssignRequestInputを右クリックし、図21-13に示すようにInvokeRequestDetailsOperationの入力をマップします。

図21-13 入力マッピング

11. 図21-14に示すように、InvokeアクティビティをInvokeRequestDetailsOperationの後に追加します。そのアクティビティにInvokeCatalogOperationという名前を付けます。

図21-14 InvokeCatalogOperation

12. InvokeCatalogOperationを編集し、図21-15に示すように構成します。

図21-15 InvokeCatalogOperationの構成

13. 図21-16に示すように、AssignアクティビティをInvokeCatalogOperationの後に追加します。そのアクティビティにAssignCatalogInputという名前を付けます。

図21-16 AssignCatalogInput

14. assignアクティビティを右クリックして編集し、図21-17に示すように入力をInvokeCatalogOperationにマップします。

図21-17 InvokeCatalogOperationの入力マッピング

21.3.5.5 ワークフローの選択の構成

ワークフロー選択ルールを定義するには、次の手順を実行します。

1. catalogDataという変数を定義します。これを行うには、「変数」アイコンをクリックし、「変数」ダイアログ・ボックスの「作成」アイコンをクリックします。
この変数には、InvokeCatalogDetailsステップの出力として返されるカタログ詳細が格納されます。

2. 変数workflowtypeを定義します。この変数には、呼び出されるワークフローのタイプが格納されます。

3. 「SOAコンポジット」ビューに移動し、図21-18に示すようにビジネス・ルール・コンポーネントを追加します。

図21-18 ビジネス・ルール・コンポーネントの追加

4. 「ビジネス・ルールの作成」ダイアログ・ボックスで、ルール・ディクショナリの名前としてWorkflowSelectionを指定します。

5. 入力としてcatalogDataを、出力としてworkflowstageを指定します。

6. BPELプロセスに切り替えます。

7. SOAコンポーネントを開き、ビジネス・ルール・コンポーネントを追加します。

8. そのルールを編集し、WorkflowSelectionという名前に変更します。

9. 「ルール」ダイアログ・ボックスで、「ディクショナリ」タブをクリックし、手順4で定義したWorkflowSelectionディレクトリを選択します。

10. 図21-19に示すように、catalogData変数をルールの入力にマップします。

図21-19 catalogData変数の入力マッピング

11. 図21-20に示すように、workflowtype変数をルールの出力にマップします。

図21-20 workflowtype変数の出力マッピング

12. 図21-21に示すように、WorkflowSelectionルールの前にAssignアクティビティを追加し、その名前をAssignRuleInputに変更します。

図21-21 AssignRuleInput

13. 図21-22に示すように、InvokeCatalogOperationの出力をcatalogData変数にマップします。

図21-22 catalogData変数の出力マッピング

14. 「SOAコンポジット」ビューに切り替えます。

15. ビジネス・ルール・コンポーネントを右クリックし、「編集」を選択します。

16. 「ルールの作成」をクリックします。

17. そのルールの名前をRule1からAuto Approvalに変更します。

18. ルールを編集し、図21-23に示すように、「プロパティ」ダイアログ・ボックスでstageTypeプロパティを指定します。

図21-23 stageTypeプロパティ

19. 同様に、図21-24に示すように、「マネージャ」、「シリアル」、および「パラレル」承認ルールを作成します。

図21-24 承認ルール

20. BPELプロセスに切り替えます。

21. 図21-25に示すように、WorkflowSelectionルールの後にswitchアクティビティを追加します。

図21-25 switchアクティビティ

22. そのSwitchアクティビティを選択し、図21-26に示すように2つのSwitch Caseステップを追加します。

図21-26 Switch Caseステップ

23. 図21-27に示すように、条件の名前をSerial Approval、Parallel Approval、Manager Approvalに変更します。

図21-27 名前変更済条件

24. 図21-28に示すように、デフォルト・ヒューマン・タスクをManager Switch Caseにドラッグします。

図21-28 デフォルト・ヒューマン・タスクのドラッグ

25. 「SOAコンポジット」ビューに切り替えます。

26. 図21-29に示すように、SerialApprovalとParallelApprovalの2つのヒューマン・タスクを追加します。

図21-29 ヒューマン・タスクの追加

27. BPELプロセスに切り替えます。

28. Manager Approval Switch Caseを編集し、次の式を追加します。

bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType')='Manager'

最初に、新しく追加したタスクを構成し、次にそれらをBPELプロセスに書き込む必要があります。

21.3.5.6 ヒューマン・タスクの構成

ヒューマン・タスクを構成する手順は次のとおりです。

- パラレル・ヒューマン・タスクの構成

- シリアル承認タスクの構成

- デフォルト承認タスクの構成

21.3.5.6.1 パラレル・ヒューマン・タスクの構成

パラレル・ヒューマン・タスクを構成するには、次の手順を実行します。

1. パラレル承認タスクを編集します。

2. 「データ」タブをクリックし、次の表に示す属性を追加します。

パラメータ

データ型

RequestID

{http://www.w3.org/2001/XMLSchema}string

RequestModel

{http://www.w3.org/2001/XMLSchema}string

RequestTarget

{http://www.w3.org/2001/XMLSchema}string

RequesterDetails

{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails

BeneficiaryDetails

{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails

ObjectDetails

{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails

OtherDetails

{http://xmlns.oracle.com/request/RequestDetails}OtherDetails

url

{http://xmlns.oracle.com/request/RequestDetails}url

Catalogdata

{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData

RequesterDisplayName

{http://www.w3.org/2001/XMLSchema}string

BeneficiaryDisplayName

{http://www.w3.org/2001/XMLSchema}string

Requester

{http://www.w3.org/2001/XMLSchema}string

3. 「データ」タブでタスク・パラメータを確認します。

4. 「一般」タブをクリックします。

5. 「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。

6. 「タスク所有者」を「グループ」およびSYSTEM ADMINISTRATORSに設定します。

7. 「通知」タブをクリックし、次に「詳細」をクリックします。

8. 「通知をアクション可能にする」オプションを選択します。

9. 「割当て」タブをクリックします。

10. パラレル・ステージを追加します。これを行うには、プラス(+)アイコンをクリックし、「パラレル・ステージ」を選択します。

11. ステージを選択し、「編集」をクリックします。名前としてManagerを指定します。

12. 図21-30に示すように、もう一方のステージを選択し、名前としてReview Teamを指定します。

図21-30 ManagerおよびReview Teamステージ

13. 2つのステージの後の鉛筆アイコンをクリックします。

14. 「投票結果」ダイアログ・ボックスで、投票結果をAPPROVEに設定します。デフォルト結果をREJECTに設定します。これは、両方の承認者がタスクを拒否した場合、リクエストが、デフォルト結果に基づいて完了状態に移動するためです。

15. 「添付ファイルとコメントの共有」オプションを選択します。

16. 「最小のパーセントに達するとただちに投票結果がトリガーされます」オプションが選択されていることを確認します。

17. Managerステージを編集します。

18. 「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定します。「参加者のリストの作成で使用」リストから、 「ルールベース」を選択し、ルールを使用して参加者リストを作成します。

19. 図21-31に示すように、ルールを作成します。

図21-31 Manager参加者ルール

20. 同様に、図21-32に示すように、Review Teamステージを構成します。

図21-32 Review Teamステージ

21. 図21-33に示すように、参加者ルールを作成します。

図21-33 Review Team参加者ルール

21.3.5.6.2 シリアル承認タスクの構成

シリアル承認タスクを構成するには、次の手順を実行します。

1. 「データ」タブをクリックします。

2. 次の表に示すパラメータを追加します。

パラメータ

データ型

RequestID

{http://www.w3.org/2001/XMLSchema}string

RequestModel

{http://www.w3.org/2001/XMLSchema}string

RequestTarget

{http://www.w3.org/2001/XMLSchema}string

RequesterDetails

{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails

BeneficiaryDetails

{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails

ObjectDetails

{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails

OtherDetails

{http://xmlns.oracle.com/request/RequestDetails}OtherDetails

url

{http://xmlns.oracle.com/request/RequestDetails}url

Catalogdata

{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData

RequesterDisplayName

{http://www.w3.org/2001/XMLSchema}string

BeneficiaryDisplayName

{http://www.w3.org/2001/XMLSchema}string

Requester

{http://www.w3.org/2001/XMLSchema}string

3. 「データ」タブでタスク・パラメータを確認します。

4. 「一般」タブをクリックします。

5. 「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。

6. 「タスク所有者」を「グループ」およびSYSTEM ADMINISTRATORSに設定します。

7. 「通知」タブをクリックし、次に「詳細」をクリックします。

8. 「通知をアクション可能にする」オプションを選択します。

9. 「割当て」タブをクリックします。

10. シリアル・ステージを追加し、図21-34に示すように、ステージの名前をManagerおよびReview Teamに変更します。

図21-34 シリアル・ステージ

11. Managerステージを編集します。

12. 「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定し、ルールを使用して参加者リストを作成します。

13. 図21-35に示すように、参加者リスト・ルールを作成します。

図21-35 Managerステージのルール

14. 同様に、Review Teamステージを構成します。

15. 図21-36に示すように、参加者リスト・ルールを作成します。

図21-36 Review Teamステージのルール

21.3.5.6.3 デフォルト承認タスクの構成

デフォルト承認タスクを構成するには、次の手順を実行します。

1. 図21-37に示すように、タスクのタイトルを設定します。

図21-37 デフォルト承認タスク

2. 「割当て」をクリックします。

3. 図21-38に示すように、参加者リスト・ルールを作成します。

図21-38 参加者リスト・ルール

21.3.5.7 ヒューマン・タスクとBPELのマッピングの構成

ヒューマン・タスクとBPELのマッピングを構成する手順は次のとおりです。

- シリアル承認ヒューマン・タスクの構成

- パラレル・ヒューマン・タスクの構成

- 自動承認の構成

21.3.5.7.1 シリアル承認ヒューマン・タスクの構成

シリアル承認ヒューマン・タスクを構成するには、次の手順を実行します。

1. 次の条件を、Serial Approvalスイッチに追加します。

bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Serial'

2. 図21-39に示すように、Human TaskアクティビティをSOAコンポーネントからSerial Approvalスイッチにドラッグ・アンド・ドロップします。

図21-39 Human Taskアクティビティ

3. ヒューマン・タスクを編集し、「ヒューマン・タスク」ダイアログ・ボックスで、シリアル承認ヒューマン・タスク定義を選択します。

4. 図21-40に示すように、タスク・パラメータをBPEL変数にマップします。

図21-40 タスク・パラメータとBPEL変数のマッピング

5. 「詳細」タブをクリックします。

6. 図21-41に示すように、識別キーをリクエストIDにマップします。

図21-41 識別キーとリクエスタIDのマッピング

7. イニシエータをリクエスタ・ログインにマップし、「適用」および「OK」をクリックします。

8. タスク結果はREJECTのSwitch caseを選択します。

9. 既存の条件スクリプトを次のように置き換えます。

bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'REJECT'

10. タスク結果はREJECTの下のAssignアクティビティを選択します。

11. 1つを除くすべてのコピー・ルールを削除します。残すコピー・ルールは「ソース」ビューで置換できるため、どれでもかまいません。

12. 保存して「ソース」タブをクリックします。

13. copyアクティビティを選択します。

14. そのアクティビティを、次のものに置き換えます。

<sequence>
<assign>
<copy>
<from expression="string('rejected')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('rejected')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>

15. タスク結果はAPPROVEに対してこの手順を繰り返します。Switch Caseを選択し、「条件」フィールドに次のものをコピーします。

bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'APPROVE'

16. 承認結果の下のAssignアクティビティを選択し、そのコピー・ルールを次のものに置き換えます。

<sequence>
<assign>
<copy>
<from expression="string('approved')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('approved')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>

17. Otherwise結果の下のAssignアクティビティを選択し、そのコピー・ルールを次のものに置き換えます。

<sequence>
<assign>
<copy>
<from expression="bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:state')"/>
<to variable="outputVariable" part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:state')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>

21.3.5.7.2 パラレル・ヒューマン・タスクの構成

パラレル・ヒューマン・タスクを構成するには、次の手順を実行します。

1. 次の条件を、Parallel Approvalスイッチ・アクティビティに追加します。

bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Parallel'

2. Human TaskアクティビティをSOAコンポーネントからParallel Approvalスイッチにドラッグ・アンド・ドロップします。

3. パラレル承認ヒューマン・タスクを選択します。

4. シリアル・ヒューマン・タスクと同様の方法で、ヒューマン・タスク・パラメータをマップします。

5. シリアル・ヒューマン・タスクの同等物と同じ方法で、APPROVE結果のAssignアクティビティをマップします。

6. シリアル・ヒューマン・タスクの同等物と同じ方法で、REJECT結果のAssignアクティビティをマップします。

7. シリアル・ヒューマン・タスクの同等物と同じ方法で、Otherwise結果のAssignアクティビティをマップします。

注意:

copyアクティビティで適切なグローバル変数(ParallelApproval1_globalVariable)を指定する必要があります。

21.3.5.7.3 自動承認の構成

自動承認を構成するには、次の手順を実行します。

1. Otherwise switch caseで、Assignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティを選択し、「ソース」ビューに切り替えます。

3. 次のものをAssignアクティビティに追加します。

<sequence>
<assign>
<copy>
<from expression="string('approved')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('approved')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>

21.3.5.8 SOAコンポジットのデプロイ

SOAコンポジットをデプロイするには、次の手順を実行します。

1. 「ファイル」、「すべて保存」を選択して、作業を保存します。

2. プロジェクトを右クリックし、「デプロイ」、「COMPOSITE_NAME」、「アプリケーション・サーバーにデプロイ」の順に選択します。

注意:

- デフォルトのバージョンは1.0です。既存のコンポジット・インスタンスが実行されている場合は、バージョンを変更することもできます。

- コンポジットを再デプロイする場合に1つ以上のヒューマン・タスクを追加または削除した場合は、異なるバージョンでデプロイすることをお薦めします。

21.3.5.9 承認ポリシーの作成

作成したSOAコンポジットは、自己登録、作成、変更、無効化、有効化、削除など、ユーザー操作意外のすべてのリクエストに使用できます。ユーザー操作以外のすべてのリクエストでこのコンポジットが起動されるようにするには、Oracle Identity Managerで承認ポリシーを作成する必要があります。Oracle Identity Managerで承認ポリシーを作成するには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。

2. 「ポリシー」で「承認ポリシー」を選択します。

3. Provision Application Instanceのリクエスト・レベル承認ポリシーを作成し、それを自動承認に設定します。

4. Provision Application Instanceの操作レベル承認ポリシーを作成し、「承認プロセス」をクリックします。

5. デプロイしたSOAコンポジットを選択します。

6. スコープ・タイプに「すべて」を指定します。

7. 次のように、デフォルトの承認ルールを作成します。
Request.Request Type = Provision Application Instance

8. この承認ポリシーを保存します。

9. 次のリクエスト・タイプに対して手順5から8を繰り返し、すべての非ユーザー操作リクエストによってSOAコンポジットが起動されるようにします。

- アカウントの変更 - 権限のプロビジョニング

- アカウントの有効化 - 権限の失効

- アカウントの無効化 - ロール付与

- アカウントの失効 - ロールの失効

注意:

各タイプのリクエストに対して複数のSOAコンポジットを作成可能ですが、こチュートリアルで示すように単一のSOAコンポジットを使用して、複数のヒューマン・タスクを作成することをお薦めします。Oracle Business Rulesで作成したルールを使用すると、このチュートリアルで示すように、ヒューマン・タスクを選択できます。

ヒント:

SOAコンポジットBPELプロセスであるリクエストWebサービスにサポートされるエンティティ(カタログ、ユーザー、ロールまたは組織など)のカスタム属性の値にアクセスできます。カスタム属性またはUDFはCustomAttribute要素の一部です。UDFを含むカタログ・エンティティのインスタンスは次のとおりです。

<ns12:CustomAttribute Name="ApproverRolePhoneNumber">
<ns5:Value>1234</ns5:Value>
</ns12:CustomAttribute>
<ns12:CustomAttribute Name="ApproverRoleEmailId">
<ns5:Value>approver@oracle.com</ns5:Value>
</ns12:CustomAttribute>

たとえば、BPELプロセスでApproverRolePhoneNumberカタログのUDF値にアクセスするには、次のように指定します。

bpws:getVariableData('catalogDetails','CatalogData','/ns22:CatalogData/ns22:CustomAttribute[@Name = string("ApproverRolePhoneNumber")]/ns24:Value')

21.4 デフォルトのリクエスト・レベルおよび操作レベルの承認コンポジットの構成

oim-config.xmlファイルにDefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティを設定すると、デフォルトのリクエスト・レベルおよび操作レベルのコンポジットを作成できます。これらのプロパティは、Oracle Enterprise ManagerのSystem MBean Browserを使用して編集できます。これらのプロパティのデフォルト値は、それぞれdefault/DefaultRequestApproval!2.0とdefault/DefaultOperationalApproval!2.0になります。

これらのプロパティの値は、次の形式で入力します。

NAMESPACE/COMPOSITE_NAME!VERSION

例:

default/AddAccessApproval!2.0

DefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティのデフォルト値を変更する場合は、Oracle Identity Managerを再起動する必要があります。

注意:

デフォルトのリクエスト・レベルとして構成されたコンポジットとオペレーション・レベルのコンポジットは、すべてのリクエスト・タイプに適用できます。そのため、これらのコンポジットはすべてのリクエスト・タイプに対応するように設計する必要があります。

21.5 カスタム・タスク詳細タスクフローの作成およびデプロイ

デフォルトでは、すべてのタスクは、保留中の承認のデフォルト・タスク詳細ページを使用するように構成されています。このタスクフローはカスタマイズできません。ただし、タスク詳細ページのUIをカスタマイズしたり、その他の情報を表示することはできます。この項では、独自のタスクフローを作成し、DefaultRequestApprovalコンポジットのヒューマン・タスクを構成して、そのカスタム・タスクフローを呼び出す方法を説明します。

この項には次のトピックが含まれます:

- カスタム・タスク詳細タスクフローを開発するための前提条件

- カスタム・タスク詳細タスクフローの開発

- 電子メール通知のカスタム・タスク詳細の開発(オプション)

- タスク詳細タスクフローのデプロイ

- ヒューマン・タスクとタスクフロー権限の構成

- カスタム・タスクフローのテスト

21.5.1 カスタム・タスク詳細タスクフローを開発するための前提条件

カスタム・タスク詳細タスクフローを開発する前に、コンピュータに次のソフトウェアをインストールしておく必要があります。

- Oracle Identity Manager 11gリリース2 (11.1.2.1.0)

- Oracle SOA 11g (11.1.1.6.0)

- Oracle SOAコンポジット・エディタ拡張機能を備えたJDeveloper 11g (11.1.1.6.0)

21.5.2 カスタム・タスク詳細タスクフローの開発

DefaultRequestApprovalコンポジットのヒューマン・タスクのカスタム・タスクフローを作成するには、次の手順を実行します。

1. Jdeveloperを開き、新規汎用アプリケーションを作成します。これを行うには、次の手順を実行します。

1. アプリケーション名としてRequestApprovalTaskDetailsAppを入力し、「次へ」をクリックします。

2. プロジェクト名としてRequestApprovalTaskDetailsを入力します。プロジェクト・テクノロジは選択しないでください。

3. 「終了」をクリックします。

2. Oracle Identity Manager共有ライブラリを追加します。これを行うには、次の手順を実行します。

1. RequestApprovalTaskDetailsプロジェクトを右クリックして、「プロジェクト・プロパティ」→「ライブラリとクラスパス」の順に選択します。

2. 「ライブラリの追加」をクリックします。

3. 「ディレクトリ」をクリックします。

4. IAM_HOME/server/jdev.lib/ディレクトリに移動し、「選択」をクリックします。

注意:

IAM_HOMEはOracle Identity Managerのホーム・ディレクトリのパスで、たとえばBEA_HOME/Oracle_IDM1/のようになります。ここでは、BEA_HOMEは、Oracle Identity Managerインストールのミドルウェア・ディレクトリのパスです。

5. OIMビュー共有ライブラリ→OIMモデル共有ライブラリを選択し、「OK」をクリックします。

6. 「OK」をクリックします。

3. タスク詳細タスクフローを作成します。これを行うには、次の手順を実行します。

1. shiphome内の次ディレクトリに移動します。
IAM_HOME/server/workflows/composites/

2. DefaultRequestApproval.zipファイルを解凍します。

3. Jdeveloperに戻り、RequestApprovalTaskDetailsを右クリックして、「新規作成」を選択します。

4. ヒューマン・タスクに基づいて、「Web層」、「JSF」、ADFタスクフローを選択します。

5. ファイル・ブラウザで、DefaultRequestApproval.zipを解凍したディレクトリに移動します。DefaultRequestApproval/ApprovalTask.taskファイルを選択します。

6. 「タスク・フローの作成」ダイアログ・ボックスで、次の値を指定します。
ファイル名: request-approval-details-tf.xml

タスク・フローID: request-approval-details-tf

7. 「OK」をクリックします。

4. hwtaskflow.xmlを削除します。これを行うには、RequestApprovalTaskDetailsプロジェクトの下の「アプリケーション・ソース」に進み、hwtaskflow.xmlを削除します。

5. タスク詳細ページを作成します。これを行うには、次の手順を実行します。

1. request-approval-details-tf.xmlを開きます。Designerモードに切り替えます。

2. taskdetails1_jspx viewアクティビティの名前をrequest-approval-detailsに変更します。

3. request-approval-details viewアクティビティを右クリックし、「ページの作成」を選択します。次の値を入力します。
ファイル名: request-approval-details.jspx

初期ページ・レイアウトおよびコンテンツ: 空白ページ

4. 「OK」をクリックします。

6. このページのマネージドBeanを追加します。これを行うには、次の手順を実行します。

1. RequestApprovalTaskDetailsプロジェクトを右クリックして、「新規作成」→「Javaクラス」を選択します。次の値を入力します。
名前: RequestApprovalDetailsStateBean

パッケージ: oracle.iam.ui.custom.view.backing

2. 「OK」をクリックします。

3. 次のコードをマネージドBeanに追加します。

package oracle.iam.ui.custom.view.backing;

import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;

import javax.faces.application.Application;
import javax.faces.context.FacesContext;

import oracle.iam.ui.platform.model.config.ConstantsDefinition;

public class RequestApprovalDetailsStateBean implements java.io.Serializable{
public RequestApprovalDetailsStateBean() {
super();
}

private String requestAction = ConstantsDefinition.REQUEST_ACTION_APPROVAL_UPDATE;
private String requestType = ConstantsDefinition.REQUEST_TYPE_VIEW_DETAIL;

public void setRequestAction(String requestAction) {
this.requestAction = requestAction;
}

public String getRequestAction() {
return requestAction;
}

public void setRequestType(String requestType) {
this.requestType = requestType;
}

public String getRequestType() {
return requestType;
}

public String getUserIds() {
Object benefDisplayName = getValueFromELExpression("#{bindings.DisplayName.inputValue}");
//benefDisplayName would be "None" if beneficiary does not exist
if (benefDisplayName != null &&             !ConstantsDefinition.NONE_BENEF_DISPLAY_NAME.equalsIgnoreCase(benefDisplayName.toString()))
return benefDisplayName.toString();

Object requestTarget = getValueFromELExpression("#{bindings.RequestTarget.inputValue}");
if (requestTarget != null)
return requestTarget.toString();

return "";
}

private Object getValueFromELExpression(String expression) {
FacesContext facesContext = FacesContext.getCurrentInstance();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExp =
elFactory.createValueExpression(elContext, expression,
Object.class);
return valueExp.getValue(elContext);
}

}

4. 「概要」モードでrequest-approval-details-tf.xmlを開きます。「マネージドBean」セクションを選択し、次の詳細でマネージドBeanを登録します。
名前: requestApprovalDetailsStateBean

クラス: oracle.iam.ui.custom.view.backing.RequestApprovalDetailsStateBean

スコープ: pageFlow

7. 詳細ページ構造を作成します。これを行うには、次の手順を実行します。

1. request-approval-details.jspxを開きます。

2. 「コンポーネント・パレット」から、panelStretchLayoutをページに追加します。「プロパティ・インスペクタ」で、panelStretchLayoutに対してTopHeght==autoを設定します。

3. 「アプリケーション・ナビゲータ」で、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。「データ・コントロール」からpanelStretchLayoutのトップ・ファセットにタスクをドラッグ・アンド・ドロップします。コンテキスト・メニューから、「ヒューマン・タスク」→「タスク・アクション」を選択します。ヒューマン・タスク・アクションが、トップ・ファセットに追加されます。

4. 「コンポーネント・パレット」から、panelTabbedレイアウトをpanelStretchLayoutの「center」ファセットに追加します。

5. 「コンポーネント・パレット」から、2つのshowdetailItemコンポーネントをpanelTabbedに追加します。プロパティ・インスペクタから、これらのコンポーネントのテキスト名としてRequest InformationとTask Informationを設定します。

6. 「リクエスト情報」タブをクリックします。プロパティ・インスペクタから、属性stretchChildren=firstを設定します。

7. 「リクエスト情報」タブで、もう1つのpanelStretchLayoutを追加します。このpanelStretchLayoutに対して属性topHeight==autoを設定し、「作成」→「リージョン」を選択します。図21-42は、「リクエスト情報」および「タスク情報」タブを示しています。

図21-42 panelTabbedレイアウト

8. 「リクエスト情報」タブに移入します。これを行うには、次の手順を実行します。

1. 「ナビゲータの表示オプション」に移動し、図21-43に示す「ライブラリの表示」を選択します。これにより、「アプリケーション・ナビゲータ」にOIMビュー共有ライブラリが表示されます。

図21-43 OIMビュー共有ライブラリ

2. 「アプリケーション・ナビゲータ」で、OIMビュー共有ライブラリ→WEB-INF/oracle/iam/ui/catalog/tfsを開きます。request-summary-information-tf.xmlを、手順7gで追加したPanelStretchLayoutのトップ・ファセットにドラッグ・アンド・ドロップします。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。タスクフローのパラメータは後から指定できます。したがって「OK」をクリックします。

3. 同様に、catalog-tf.xmlを、手順7gで追加したPanelStretchLayoutの「center」ファセットにドラッグ・アンド・ドロップします。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。「OK」をクリックします。

4. ページの下部にある「バインディング」タブをクリックし、バンディングを表示します。プラス(+)記号をクリックして、次のようにバインディングを追加します。
i) 次のように入力して、「OK」をクリックします。

カテゴリ: 一般バインディング

作成するアイテム: attributeValues

ii) 「データソースの追加」をクリックします。「RequestApprovalDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。「OK」をクリックします。

iii) 属性としてRequestIDを指定し、「OK」をクリックします。

5. 「実行可能ファイル」の下でtaskflow-requestsummaryinformationtf1を選択します。「プロパティ・インスペクタ」で、プラス(+)記号をクリックしてタスクフロー・パラメータを追加します。次のようにrequestIdを指定します。
requested, Value= #{bindings.RequestID.inputValue}

6. プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。
i) 次のように入力して、「OK」をクリックします。

カテゴリ: 一般バインディング

作成するアイテム: attributeValues

ii) 「データソースの追加」をクリックします。「RequestApprovalDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」→「BeneficiaryDetails」を選択します。「OK」をクリックします。

iii) 属性としてDisplayNameを指定し、「OK」をクリックします。

7. プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。
i) 次のように入力して、「OK」をクリックします。

カテゴリ: 一般バインディング

作成するアイテム: attributeValues

ii) リストから、データソース「RequestApprovalDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。

iii) 属性としてRequestTargetを指定し、「OK」をクリックします。

8. taskflow-catalogtf1を選択し、プロパティ・インスペクタを使用して次のタスクフロー・パラメータを追加します。

- Id=requestId, Value= #{bindings.RequestID.inputValue}

- Id=requestType, Value=#{pageFlowScope.requestApprovalDetailsStateBean.requestType}

- Id=requestAction, Value=#{pageFlowScope.requestApprovalDetailsStateBean.requestAction}

- Id=userIds, Value=#{pageFlowScope.requestApprovalDetailsStateBean.userIds}

9. 「タスク情報」タブに移入します。これを行うには、次の手順を実行します。

1. 設計モードに切り替えます。「タスク情報」タブをクリックします。

2. アプリケーション・ナビゲータで、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。「タスク情報」タブでタスクをドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。図21-44に示すように、「ヒューマン・タスク」→「ペイロードのない完了済タスク」を選択します。

図21-44 タスク詳細DataControl

3. panelGroupLayout内にラップされているpanelHeaderが、「タスク情報」タブに追加されます。panelHeaderに移動し、panelHeaderのツールバー・ファセットを削除します。タスク・アクションは、すでに手順7cにあります。さらに、タスク詳細、タスク履歴、コメント、および添付ファイルも、「タスク情報」タブに追加されています。

4. 作業内容を保存します。

21.5.3 電子メール通知のカスタム・タスク詳細の開発(オプション)

デフォルトでは、電子メール通知の送信について、電子メール用に別のページがない場合は、「電子メール通知のカスタム・タスク詳細の開発(オプション)」で開発した同じ詳細ページが電子メール通知で送信されます。

場合によっては、電子メール通知で送信する情報を制限する必要があります。そのような場合は、電子メール通知用に別のページを開発できます。電子メール・ページも、同じタスク詳細タスクフローの一部になります。

電子メール用カスタム・タスクフローの作成の詳細は、Oracle Fusion Middleware Oracle SOA Suite開発者ガイドの電子メール通知の作成に関する項を参照してください。

21.5.4 タスク詳細タスクフローのデプロイ

タスク詳細タスクフローをデプロイするには、次の手順を実行します。

1. ADFライブラリJARとしてタスク詳細をデプロイします。これを行うには、次の手順を実行します。

1. 「RequestApprovalTaskDetails」を右クリックして、「プロジェクト・プロパティ」→「デプロイメント」の順に選択します。

2. 「新規」をクリックします。「デプロイメント・プロファイルの作成」ダイアログ・ボックスが表示されます。

3. 次の値を指定し、「OK」をクリックします。
アーカイブ・タイプ: ADFライブラリJARファイル

名前: adflibRequestApprovalTaskDetails

4. 「RequestApprovalTaskDetails」を右クリックして、「デプロイ」→「adflibRequestApprovalTaskDetails」を選択します。

5. 「デプロイメント・アクション」ポップアップで、「終了」をクリックします。

2. カスタム共有ライブラリでadflibRequestApprovalTaskDetails.jarをパッケージ化します。これを行うには、次の手順を実行します。

1. IAM_HOME/server/apps/ディレクトリに移動します。

2. 次のディレクトリ構造を作成します。
WEB-INF/lib/

3. WEB-INF/lib/ディレクトリにadflibRequestApprovalTaskDetails.jarをコピーします。

4. IAM_HOME/server/apps/ oracle.iam.ui.custom-dev-starter-pack.warを更新し、adflibRequestApprovalTaskDetails.jarを追加します。例:

jar uvf oracle.iam.ui.custom-dev-starter-pack.war WEB-INF/*

3. Oracle Identity Manager管理対象サーバーを再起動して、カスタム共有ライブラリへの変更を反映します。

21.5.5 ヒューマン・タスクとタスクフロー権限の構成

ヒューマン・タスクとタスクフロー権限を構成するには、次の手順を実行します。

1. 認可ポリシー・マネージャ(APM)を使用して、カスタム・タスクフローの表示権限を追加します。これを行うには、次の手順を実行します。

1. WebLogicユーザーとしてAPMアプリケーションにログインします。

2. 「アプリケーション」→「OracleIdentityManager」→「リソース・タイプ」に移動します。「開く」をクリックします。

3. 「新規作成」をクリックして、新しいリソース・タイプを作成します。次の情報を指定します。
表示名: ADFタスク・フロー

名前: ADFタスク・フロー

アクション: パーソナライズ、カスタマイズ、付与、表示 (「新規作成」をクリックして各アクションを追加します)

リソース階層のサポート: いいえ

リソース・デリミタ: スラッシュ(/)

評価ロジック: 権限クラス

権限クラス: oracle.adf.controller.security.TaskFlowPermission

アクション名デリミタ: カンマ(,)

4. 「保存」をクリックします。

5. 「アプリケーション」→「OracleIdentityManager」→デフォルト・ポリシー・ドメイン→リソース・カタログ→「リソース」に移動します。「開く」をクリックします。

6. OIMシステム管理者のポリシーを選択し、「開く」をクリックします。

7. 「ターゲットの追加」をクリックします。「ターゲットの検索」ポップアップが表示されます。

8. 「リソース」タブをクリックします。リソース・タイプとして「ADFタスク・フロー」を指定し、「検索」をクリックします。

9. リクエスト承認詳細タスクフローを選択します。「選択済の追加」をクリックします。

10. 「ターゲットの追加」をクリックします。リソースが「ターゲット」表に追加されます。

11. リクエスト承認詳細タスクフローを開きます。「表示」を選択します。「適用」をクリックします。

2. カスタム・タスクフローを使用するようにヒューマン・タスクを構成します。これを行うには、次の手順を実行します。

1. WebLogicユーザーとしてOracle Enterprise Managerにログインします。

2. 「Farm_IAM_DOMAIN」→「SOA」→「soa_infra (SOA_SERVER」)→「デフォルト」→「DefaultRequestApproval [1.0]」に移動します。

3. 「コンポーネント・メトリック」→「承認タスク」をクリックします。

4. 「管理」タブをクリックします。

5. 次に示すように、既存のエントリのURIを、カスタム・タスクフローを指すように変更します。
/identity/faces/adf.task-flow?_id=request-approval-details-tf&_document=WEB-INF/request-approval-details-tf.xml

21.5.6 カスタム・タスクフローのテスト

カスタム・タスクフローをテストするには、次の手順を実行します。

1. エンド・ユーザーとしてOracle Identity Self Serviceにログインします。

2. 「本人情報」に移動し、「電話」属性の値を変更します。リクエストが作成され、タスクがシステム管理者に割り当てられます。

3. システム管理者としてOracle Identity Self Serviceにログインします。

4. 「保留中の承認」に移動します。

5. 対応するリクエストの「タスクの詳細」リンクをクリックします。カスタム・タスク詳細ページが表示されます。

21.6 リクエスト・データセットの理解

リクエスト・データセットは、特定のタイプのリクエストと関連付けることができるデータを格納するXMLファイルです。

注意:

この項の情報は参照用です。リクエスト・データセットの変更、エクスポート、およびインポートは行わないことをお薦めします。ユーザーおよびアプリケーション・インスタンス定義を拡張するには、Oracle Identity System Administrationのフォーム・デザイナを使用します。フォーム・デザイナの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のフォームの管理に関する項を参照してください。

表21-1に、リクエスト・タイプおよび関連付けられるOracle Identity Managerに付属のデフォルトのリクエスト・データセット・ファイル名を示します。

表21-1 Oracle Identity Managerに付属のデフォルトのリクエスト・データセット

リクエスト・タイプ

デフォルトのデータセット・ファイル名

エンティティ

ユーザーの作成

CreateUserDataSet.xml

ユーザー

ユーザーの削除

DeleteUserDataset.xml

ユーザー

ユーザーの有効化

EnableUserDataset.xml

ユーザー

ユーザーの無効化

DisableUserDataset.xml

ユーザー

ユーザー・プロファイルの変更

ModifyUserDataset.xml

ユーザー

セルフ・プロファイルの変更

ModifyUserDataset.xml

ユーザー

ロールの作成

CreateRoleDataSet.xml

ロール

ロールの変更

ModifyRoleDataSet.xml

ロール

ロールの削除

DeleteRoleDataSet.xml

ロール

ロールの割当て

AssignRolesDataset.xml

ロール

ロールからの削除

RemoveRolesDataset.xml

ロール

21.7 リクエスト管理操作の拡張

リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。

ここでは、プラグイン・ポイントについて次の各項で説明します。

- リクエスト・ステータス変更に基づくカスタム・コードの実行

- リクエスト・データの検証

- リクエスト作成時の属性値の事前移入

21.7.1 リクエスト・ステータス変更に基づくカスタム・コードの実行

Oracle Identity Managerでは、リクエストのライフサイクルの各ステージでステータスが変更されます。リクエスト・エンジンによって、リクエスト・ステータスの変更時にカスタム・コードを実行できるプラグイン・ポイントが公開されます。このプラグイン・ポイントを拡張するカスタム・コードを含むプラグインを実装し、コードを実行するために登録できます。プラグイン・ポイントは、public void followUpActions(String reqId)メソッドを含むoracle.iam.request.plugins.StatusChangeEventインタフェースです。このメソッドはリクエストIDパラメータで構成され、これとリクエスト管理APIを使用してリクエスト詳細を取得できます。

関連項目:

プラグインおよびプラグイン・ポイントの詳細は、第27章「プラグインの開発」を参照してください。

ステータス変更時に実行するコードは、oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するプラグイン・クラスのfollowUpActions()メソッドで実装する必要があります。plugin.xmlファイルでこのプラグインをどのリクエスト・ステータス変更時に実行するかを指定する必要があります。

たとえば、Oracle Identity Managerでリクエストが「リクエストに失敗しました」ステータスに移行した場合、管理者に通知を送信するカスタム・コードを実行できます。これを行うには、次の手順を実行します。

1. oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するRequestFailedChangeEventという名前の新しいプラグイン・クラスを作成します。このクラスには、followUpActions(String reqId)メソッドで管理者に通知を送信するロジックが必要です。

2. プラグイン・フレームワークで指定されている次の標準形式でplugin.xmlを定義します。

<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.request.plugins.StatusChangeEvent">
<plugin pluginclass="com.mycompany.RequestFailedChangeEvent" version="1.0" name="RequestFailedChangeEvent">
<metadata name="status">
<value>Request Failed</value>
</metadata>
</plugin>
</oimplugins>

このXML定義では、プラグインを実行する必要があるステージをメタデータ部分で指定しています。メタデータ値をRequest Failedとして指定し、これはリクエストが「リクエストに失敗しました」ステータスに移行したときにcom.mycompany.RequestFailedChangeEventプラグインが実行されることを意味します。

3. プラグインをOracle Identity Managerに登録します。Oracle Identity Managerにプラグインを登録する方法の詳細は、プラグインの登録に関する説明を参照してください。

21.7.2 リクエスト・データの検証

RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。このプラグインのプラグイン・ポイントは、public void validate(RequestData requesterData)メソッドを含むoracle.iam.request.plugins.RequestDataValidatorインタフェースです。

特定のプラグインに関連付けられているデータセット・バリデータおよび事前移入アダプタを定義できます。プラグインに関連付けられるリクエスト・データセットは、プラグイン登録時に定義できます。plugin.xmlファイルは、プラグインとデータセット・バリデータまたは事前移入アダプタの間の関連付けを定義するために使用します。<plugins>要素に付加されている<metadata>ノードは、データ・バリデータと事前移入アダプタの間の関連付けを定義するために使用します。

注意:

データセットに対して指定されているDataSetValidatorプラグインは、plugin.xml自体でバリデータ・メタデータを指定するプラグイン拡張によってオーバーライドすることはできません。たとえば、デフォルト・バリデータに付属している事前定義済データセットModifyUserDatasetは、カスタム実装クラスによってオーバーライドされません。したがって、データセットのバリデータが優先され、それをオーバーライドするオプションは現時点ではありません。

例21-1は、プラグインをデータ・バリデータおよび事前移入アダプタに関連付けできる方法を示しています。

例21-1 プラグインとデータ・バリデータおよび事前移入アダプタの関連付け

<?xml version="1.0" encoding="UTF-8"?>
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.request.plugins.RequestDataValidator">
<plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstanceDataValidator" version="1.0" name="AppInstDataValidator">
<metadata name="DataValidator">
<value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value>
</metadata>
</plugin>
</plugins>
</oimplugins>

この例の次のコード行は、プラグインがリクエスト・データ・バリデータ・データセットに関連付けられていることを示すメタデータxml要素の定義を示しています。

<metadata name="DataValidator">

このメタデータ要素のAttribute name="DataValidator"は、リクエスト・データ・バリデータに関連付けられているプラグインを示すことに注意してください。

現在のプラグインに関連付けられているデータセットの名前の定義は、次の行で示されます。

<value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value>

注意:

リクエスト・データセット名は、単一のパイプ文字(|)で区切る必要があります。

次のようなシナリオを想定してください。

AD User APACターゲットにユーザーをプロビジョニングするように、Oracle Identity Managerが構成されているとします。RequestDataValidatorは、次に示すように、ADUserDataValidatorを対応するリクエスト・データセットに対して構成することを指定します。

<plugin pluginclass= "oracle.iam.plugin.appinst.ADUserDataValidator" version="1.0" name="ADUserDataValidator">
<metadata name="DataValidator">
<value>ADUserAPACDataSet</value>
</metadata>
</plugin>

後で、AD User EMEAターゲットにユーザーがプロビジョニングされるように、システム・コンフィギュレータがOracle Identity Managerを構成する場合、システム・コンフィギュレータは新しいアプリケーション・インスタンスを作成し、UIフォームをそれに関連付けようとします。リクエスト・データセットは、プロセスで自動生成されます。データ・バリデータをこのリクエスト・データセットに対して再利用する場合、次の操作を実行します。

1. ADUserDataValidatorのplugin.xmlを編集します。

2. <metadata> <value>サブタグに、新しいリクエスト・データセットの名前をデリミタで区切って追加します。例:

<value>ADUserAPACDataSet|ADUserEMEADataSet</value>

3. データ・バリデータ・プラグインを再登録します。

21.7.3 リクエスト作成時の属性値の事前移入

事前移入プラグインは、リクエスト・データセットの属性参照または属性に関連付けられます。これを使用すると、リクエストの作成時にカスタム・コードを実行して、属性値を事前移入できます。リクエスタは、必要に応じて事前移入する値を変更できます。

このプラグインのプラグイン・ポイントは、public Serializable prepopulate(RequestData requestData)メソッドを含むoracle.iam.request.plugins.PrePopulationAdapterインタフェースです。このプラグインは、次のリクエスト・タイプにのみ使用します。

リソースのプロビジョニング、リソースの自己リクエスト、ユーザーの作成、ユーザーの自己登録

次の行は、事前移入データを満たすためのリクエスト・データセット属性に、プラグインがマップされることを示すメタデータ要素の定義を示しています。

<metadata name="PrePopulationAdapater">

関連付けは、データセット名と属性名を次の形式で組み合せることによって定義されます。

<DATASET_NAME>::<ATTRIBUTE_NAME>

例:

AppInstanceDataSet::First Name

複数の属性を同じ事前移入プラグインに関連付けることが可能ですが、その際は、各関連付けを単一のパイプ文字(|)で区切ります。例:

<datasetname1>::<attribute1> | <datasetname2>::<attributename2>|<datasetname3>::<attribute3>

事前移入プラグインの例を次に示します。

<plugins pluginpoint="oracle.iam.request.plugins.PrePopulationAdapter">
<plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstancePrePopulateAdapter" version="1.0" name="AppInstPrepopAdapter">
<metadata name="PrePopulationAdapater">
<value>
AppInstanceDataSet::First Name|ADAppDataSet::Last Name
</value>
</metadata>
</plugin>
</plugins>

注意:

カタログ・フォーム・デザイナでリクエスト・データセットを作成する他に、リクエスト・データセットをMDSに手動でアップロードすることができます。リクエスト・データセット内にDataSetValidatorまたはPrepopulationAdapter要素を定義することもできます。データセット内で構成されるこれらのデータセット・バリデータまたは事前移入アダプタは、他の構成よりも最優先されます。

たとえば、プラグインEBSUserDataValidatorは、リクエスト・データセットEBSUSerDataSetと関連付けるために登録されますが、そのデータセットは作成されていないか、アップロードされていないとします。もう1つのプラグインADUserDataValidatorが登録されていますが、どのリクエスト・データセットにも関連付けられていません。後でリクエスト・データセットEBSUSerDataSetを作成して、リクエストの作成に使用すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorがコールされます。そこで、手動で作成したリクエスト・データセットEBSUSerDataSetに、DataSetValidator要素を追加して、別のプラグインADUserDataValidatorを指定します。EBSUSerDataSetを使用してリクエストを作成すると、プラグインADUserDataValidatorがコールされます。これは、ADUserDataValidatorがリクエスト・データセットの一部として構成されたためです。DataSetValidatorエントリをEBSUSerDataSetから削除すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorが起動されます。

21.8 自己登録リクエストの自動承認の有効化

承認ポリシーは、リクエスト・レベルまたは操作レベルで構成できます。これらでは、リクエスト・レベルおよび操作レベルで使用可能なすべてのデータを使用してルールを構築できます。このルールを使用して、そのリクエストを自動承認するのか、SOAコンポジットを起動する必要があるのかを決定します。リクエスト・レベルおよび操作レベルの自動承認の有効化の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の承認ポリシーの作成に関する項を参照してください。

承認ポリシーの更新後は、次の手順を実行して自己登録リクエスト用に自動承認を有効化します。

1. 組織を自動的に割り当てるには、オーケストレーションで組織の値を設定する前処理ハンドラを追加します。承認関連のハンドラより前に実行されるように順序を設定する必要があります。CreateUserPreProcessHandlerのすぐ後に実行されるように設定してください。オーケストレーションおよびイベント・ハンドラの詳細は、第28章「イベント・ハンドラの開発」を参照してください。

2. デフォルトでは、自己登録リクエストに設定されているロールおよびユーザー・タイプは「パートタイムの従業員」です。この値を上書きする場合は、SelfCreateUserDataset.xmlデータセットで構成されているプラグインを変更します。

3. 必要な値やロジックについて新規プラグイン実装を作成し、データセットで構成されているプラグインを変更することで、新しいプラグイン実装を反映できます。新しいプラグインではoracle.iam.request.plugins.PrePopulationAdapterが実装されている必要があります。

4. プラグイン登録ユーティリティを使用して、作成したプラグインを登録します。詳細は、「プラグイン登録ユーティリティを使用したプラグインの登録および登録解除」を参照してください。

5. リクエスト・データセットを更新するには、次の手順を実行します。

1. 「MDSへのメタデータ・ファイルのエクスポート」の説明に従って、MDSから/metadata/iam-features-requestactions/model-data/SelfCreateUserDataset.xmlリクエスト・データセットをエクスポートします。

2. Role属性に構成されているプラグイン名を次のように更新します。

<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false"
type="String" length="255" widget="dropdown" lookup-code="Lookup.Users.Role"
required="true">
<PrePopulationAdapter
classname="oracle.iam.selfservice.uself.uselfmgmt.plugins.RolePrepopulateAdapter"
name="RolePrepopulateAdapter"/>
</AttributeReference>

3. 「MDSからのメタデータ・ファイルのインポート」の説明に従って、更新されたリクエスト・データセットをMDSにインポートします。

22 職務の分離(SoD)の使用

職務の分離(SoD)の概念は、ビジネス・プロセスにチェック・アンド・バランスを適用することを目的としています。ビジネス・プロセスの各段階では、複数の個人の関与が必要になる場合があります。組織では、ユーザー・プロビジョニング・ソリューションの一部としてSoDを実装することにより、こうした状況をIT対応のビジネス・プロセスの要件に変換できます。SoDの全体的な利点は、組織のリソースが意図的または偶発的に悪用されることにより生じるリスクを軽減できる点です。

この章では、次の各項でSoDについて説明します。

- SoD検証プロセスの理解

- SoD起動ライブラリの概要

- SoD対応コネクタのインストール

- SILおよびSILプロバイダのデプロイ

- SoDエンジンの構成

- SoDの有効化および無効化

- SSL通信の有効化

- SoD非対応コネクタでのワークフローの構成

- 権限データを保持する子プロセス・フォーム表のマーク

- ターゲット・システムおよびSoDエンジンのカスタムの組合せ

- Oracle Identity AnalyticsによるロールSoDチェックの実行

- プロビジョニング・ワークフローでのSoDの使用

- SoD関連イベントのロギングの有効化

- SoDチェックのトラブルシューティング

22.1 SoD検証プロセスの理解

Oracle Identity Managerは、権限リクエストの検証および管理にも使用できるユーザー・プロビジョニング・ソリューションです。Oracle Identity ManagerのSoD実装では、ユーザーによるIT権限(権限)リクエストがSoDエンジンおよび他のユーザーによってチェックされ、承認されます。システムと人による複数レベルのチェックにより、たとえ元のリクエストに変更が加えられても、リクエストがクリアされる前に必ず入念に検査されるようにすることができます。この予防方法は、リクエストされた権限が割り当てられる前に、権限割当てで競合する可能性のあるものを特定し、修正するうえで役立ちます。

Oracle Identity ManagerでのSoD検証プロセスは、ユーザーが特定のターゲット・システムでの権限に対するリクエストを作成すると開始されます。リクエストはリソース承認ワークフローを通り、その初期ワークフローをパスした場合はプロビジョニング・ワークフローを通ります。

- リソース承認ワークフローは、SoDエンジンによりリアルタイムでこのリクエストを検証するように構成できます。SoDエンジンでは、事前定義のルールを使用して、権限割当てがSoD違反につながるかどうかを確認します。この確認が行われた後、その結果がOracle Identity Managerに返されます。

- リソース・プロビジョニング・ワークフローは、リソース承認ワークフローをパスした権限リクエストをターゲット・システムにプロビジョニングします。

ユーザーのリクエストがSoD検証にパスし、承認者がリクエストを承認した場合、リソース・プロビジョニング・ワークフローが開始されます。リクエストがSoD検証に失敗した場合、改善ステップが行われるようにリソース承認ワークフローを構成できます。

注意:

SoDコンプライアンスを保証するために、権限割当てがターゲット・システムにプロビジョニングされる直前に、SoD検証を再実行するようにリソース・プロビジョニング・ワークフローを構成できます。

Oracle Identity Managerは、SoDエンジンとターゲット・システムの両方と通信します。また、ターゲット・システムとSoDエンジンは、権限データの同期化が有効になるように相互に通信します。図22-1に、SoD検証プロセスにおけるデータ・フローを示します。

図22-1 Oracle Identity ManagerでのSoD検証プロセス

22.2 SoD起動ライブラリの概要

SoD起動ライブラリ(SIL)は、Oracle Identity ManagerでのSoD実装の基礎となります。SILはJavaベースのアダプタの集合で、事前に定義されたOracle Identity Managerコネクタとの統合を可能にします。その結果、コネクタは、Oracle Identity Managerをターゲット・システムと結び付けます。次のOracle Identity Managerコネクタが、SoD検証用に事前にアダプタに構成されています。

- Oracle E-Business User Managementリリース9.1.0以上

- SAP User Managementリリース9.1.2.5以上

注意:

SAP UM 9.1.2.5の場合、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)で権限のリクエストが機能しません。

SILは、SILとSoDエンジンを統合する専用アダプタの基礎の役割も果たします。これらのアダプタは、SILプロバイダと呼ばれます。SILプロバイダは、SILと特定のSoDエンジンとのインタフェースの機能を果たします。次のSoDエンジン用に事前に定義されたSILプロバイダがあります。

- SAP GRC用SILプロバイダ
このプロバイダは、SAP GRC SILプロバイダとしても知られています。動作保証されたSAP GRCのバージョンは、バージョン5.2 SP4以上および5.3 SP5以上です。

- Oracle Application Access Controls Governor (OAACG)リリース8.6.3用SILプロバイダ
このプロバイダは、OAACG SILプロバイダとしても知られています。

注意:

Oracle Identity ManagerでSoDの実装および使用を開始する前に、OAACGの最新のパッチ・セットをインストールしてください。詳細は、Oracleサポートに連絡してください。

- Oracle Identity Analytics (OIA) 11gリリース1パッチ・セット1バンドル・パッチ2 (11.1.1.5.2)用SILプロバイダ
このプロバイダは、OIA SILプロバイダとしても知られています。

注意:

OIAの現行バージョンは、次のURLに移動してパッチ13641335を検索することによってMy Oracle Support Webサイトからダウンロードできます。

https://support.oracle.com

図22-2に、Oracle Identity ManagerでのSoD実装のアーキテクチャを示します。

図22-2 Oracle Identity ManagerでのSoD実装のアーキテクチャ

Oracle Identity Managerコネクタは、必要に応じて、SAP GRC SILプロバイダ、OAACG SILプロバイダまたはOIA SILプロバイダのいずれとも構成できます。たとえば、PeopleSoft User ManagementコネクタとOAACG SILプロバイダを使用すれば、PeopleSoft Enterpriseアプリケーションで権限に対するリクエストのSoD検証を自動化できます。

カスタムSoDエンジン用SILプロバイダを作成し、事前に構成されたOracle Identity Managerコネクタ、またはSoD検証用に構成したOracle Identity Managerコネクタのいずれかとともに使用することもできます

22.3 SoD対応コネクタのインストール

次に示すSoD対応コネクタのインストール手順は、特定のコネクタのドキュメントを参照してください。Oracle Identity Managerコネクタのドキュメント・ページは、次のURLにあります。

http://download.oracle.com/docs/cd/E11223_01/index.htm

- Oracle E-Business User Managementリリース9.1.0以上

- SAP User Managementリリース9.1.2.5以上

22.4 SILおよびSILプロバイダのデプロイ

SIL登録は、デフォルトで、一部のターゲット・システムおよびSoDエンジンに対して提供されています。これらのターゲット・システムおよびSoDエンジンのデフォルトの組合せの場合は、デプロイメント・ステップは不要です。SIL登録が提供されているターゲット・システムには次のものがあります。

- EBSおよびOAACG

- PSFTおよびOAACG

- SAPおよびSAP-GRC

- OIA
OIA SoDエンジンは、他のターゲット・システムではなくOracle Identity Managerとの間でデータを同期化するため、OIAに対して登録されるトポロジは、Oracle Identity Managerで構成されている任意のコネクタで使用できます。OIAはOracle Identity Managerからすべてのデータをインポートします。したがって、OIAの視点からは、Oracle Identity Managerはターゲット・システムになります。

ターゲット・システムまたはSoDエンジンの他の組合せを使用する場合は、SIL登録プロセスを実行する必要があります。詳細は、第22.10項「ターゲット・システムおよびSoDエンジンのカスタムの組合せ」を参照してください。

22.5 SoDエンジンの構成

ターゲット・システムからSoDエンジンに権限データをインポートする必要があります。必要に応じて、SoDエンジンでSoD検証ルールも構成します。次の各項では、事前に構成されたSoDエンジンに対するこれらの手順を説明します。

- Oracle Application Access Controls Governorの構成

- SAP GRCの構成

- Oracle Identity Analyticsの構成

22.5.1 Oracle Application Access Controls Governorの構成

Oracle Application Access Controls Governor (OAACG)の構成には、次の手順が必要です。

- Oracle Application Access Controls Governorのインストール

- SoD処理用のOracle Application Access Controls Governorアカウントの作成

- Oracle E-Business Suiteのロールおよび職責データのOracle Application Access Controls Governorへの同期化

- Oracle Application Access Controls Governorでのアクセス・ポリシーの定義

Oracle Application Access Controls Governorのインストール

OAACG 8.6.3.xはOracle Identity Manager 11gリリース2 (11.1.2.1.0)以上でサポートされています。最初にOAACG 8.6.3 GAをインストールする必要があります。さらに、Oracle Identity Manager SoDはOAACG 8.6.3.6012で動作保証されているため、OAACG 8.6.3.6012にアップグレードする必要があります。

OAACG 8.6.3 GAをインストールするには、次の手順を実行します。

1. My Oracle Supportにログインします。

2. 「パッチと更新版」タブをクリックします。

3. 「拡張検索」をクリックします。

4. 「製品ファミリ」で「Oracle Application Access Controls Governor」を選択し、リリースとしてAACG 8.6.3を選択します。適切なプラットフォームを選択し、「検索」をクリックします。次のパッチおよびその他の最新のパッチが表示されます。

- 8.6.3 GA - 12724066 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3

- 8.6.3.2000 - 12945100 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.2000 - パスワードで保護されており、サポートからのパスワードが必要です

- 8.6.3.3000 - 12963883 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.3000 - パスワードで保護されており、サポートからのパスワードが必要です

- 8.6.3.3500 - 12993066 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.3500 - パスワードで保護されており、サポートからのパスワードが必要です

- 8.6.3.4000 - 13015405 ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.4000

- 8.6.3.5000 - 13507234 ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.5000

- 8.6.3.6000 - 13699560 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.6000

- 8.6.3.6001 - 13872240 - ORACLE ENTERPRISE TRANSACTIONS CONTROLS GOVERNOR 8.6.3.6001

- 8.6.3.6012 - 13931550 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.6012

5. パッチ12724066をダウンロードします。

6. OAACGインストレーション・ガイドを参照して、OAACGのアップグレードまたはインストールを実行します。
同様に、他の必須バージョンのパッチをダウンロードして順番に適用します。デプロイメントごとに、アクティブなデータ・ソースに対してAccess ETLを再実行する必要があります。

OAACG 8.6.3GAをOAACG 8.6.3.6012にアップグレードする必要があります。アップグレードの順序は、次のとおりです。

8.6.3GA、8.6.3.4000、8.6.3.5000、8.6.3.6000、8.6.3.6001、8.6.3.6012(最後)

これらのすべてのパッチに対し、OracleサポートからダウンロードするためのパッチIDが手順4に記載されてます。

SoD処理用のOracle Application Access Controls Governorアカウントの作成

SoD検証処理用に基本タイプのアカウントを作成します。「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。

アカウント作成の詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。

Oracle E-Business Suiteのロールおよび職責データのOracle Application Access Controls Governorへの同期化

Oracle E-Business Suiteからロールおよび職責データをOracle Application Access Controls Governorにインポート(同期化)する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。

詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。

Oracle Application Access Controls Governorでのアクセス・ポリシーの定義

ロールおよび職責データのインポート後、Oracle Application Access Controls Governorでアクセス・ポリシーを設定します。これらのアクセス・ポリシーは、ロールおよび職責の様々な組合せに基づいています。

詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。

22.5.2 SAP GRCの構成

SAP GRCでは、SAP R/3のユーザー、ロールおよびプロファイル・データを使用して、アカウント、ロールおよび職責に対するリクエストを検証します。SAP GRCの構成には、次の手順が必要です。

- SoD処理用のSAP GRCアカウントの作成

- キーストアの生成

- Risk Terminatorの構成

- SAP ERPのユーザー、ロールおよびプロファイル・データのSAP GRCへの同期化

- SAP GRCでのリスク・ポリシーの定義

SoD処理用のSAP GRCアカウントの作成

SoD処理用のSAP GRCアカウントを作成する必要があります。SoD処理中、SAP GRC Webサービスのコールにこのアカウントが使用されます。

このユーザー・アカウントの作成時に、アカウントを次のグループに割り当てる必要があります。

- すべての人

- 認証済ユーザー

このアカウントにはロールを割り当てないでください。

キーストアの生成

キーストアを生成するには、次のようにします。

1. Webブラウザで、SAP GRC Access Controlの「Web Services Navigator」ページを開きます。URLは次のようなものです。

https://SAP_GRC_HOST:PORT_NUMBER/VirsaCCRiskAnalysisService/Config1?wsdl

2. 証明書をエクスポートします。

3. 証明書をSAP GRCのJDKインストール・ディレクトリ内のbinディレクトリにコピーします。

4. 次のコマンドを実行し、ダウンロードした証明書ファイルからキーストアを作成します。

keytool -import -v -trustcacerts -alias sapgrc -file CERTIFICATE_FILENAME -keystore sgil.keystore -keypass changeit -storepass changeit

注意:

このサンプル・コマンドで、キーストア・ファイル名はsgil.keystoreです。

5. キーストアのパスワードを要求されたら、changeitを指定します。これは、デフォルトのキーストア・パスワードです。

6. 証明書を信頼するかどうかの指定を要求されたら、yesを入力します。

7. sgil.keystoreファイルは、binディレクトリに作成されます。ファイルをOIM_HOME/configディレクトリにコピーします。

Risk Terminatorの構成

Risk Terminatorは、GRC Access Controlの機能です。これは、SAP GRCのSoD検証機能のメイン・コンポーネントです。ロールがプロファイル・ジェネレータで作成されたり、ユーザーに割り当てられたりすると、Risk Terminatorにより、このロールの作成または割当てがSoD違反になるかどうかが検証されます。

詳細は、Risk Terminator構成のドキュメントを参照してください。

SAP ERPのユーザー、ロールおよびプロファイル・データのSAP GRCへの同期化

ユーザー、ロールおよびプロファイル・データは、SAP ERPからSAP GRCにインポート(同期化)する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。

SAP GRCでのリスク・ポリシーの定義

ロールおよび職責データのインポート後、SAP GRCのRisk Analysis and Remediation機能を使用して、職務の分離タイプのリスク・ポリシーを定義します。

詳細は、SAP GRCのドキュメントを参照してください。

22.5.3 Oracle Identity Analyticsの構成

Oracle Identity Analyticsの構成には、次の手順が必要です。

- SoD処理用のOracle Identity Analyticsアカウントの作成

- Oracle Identity ManagerメタデータのOracle Identity Analyticsとの同期化

- Oracle Identity AnalyticsでのID監査ポリシーの定義

注意:

Oracle Identity Analytics 11.1.1.5.0パッチ・セット2は、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)で動作することが保証されています。

SoD処理用のOracle Identity Analyticsアカウントの作成

Oracle Identity Analyticsでアカウントを作成し、それをSoD検証処理用にSRM管理ロールに割り当てます。「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。

アカウント作成の詳細は、Oracle Identity Analyticsのドキュメントを参照してください。

Oracle Identity Analytics 11.1.1.5.2は、競合の原因となった権限に関する情報を提供します。この情報は、SoDの詳細の下に表示されます。SoDの詳細の下では、権限がエンコードされた形式(たとえば、4~695~24123)で表示されます。これは、その方法でポリシーがOIA上に作成されているためです。

注意:

ユーザー名がrbacxadminのOracle Identity Analytics管理アカウントを使用することもできます。

Oracle Identity ManagerメタデータのOracle Identity Analyticsとの同期化

Oracle Identity ManagerからOracle Identity Analyticsにリソース・メタデータおよびリソースをインポートします。

詳細は、Oracle Identity Analyticsのドキュメントを参照してください。

Oracle Identity AnalyticsでのID監査ポリシーの定義

Oracle Identity Analyticsを使用して、ID監査ルールおよびポリシーを設定します。ルールはリソースの属性に基づいて作成されます。権限SoDチェック時には、Oracle Identity Managerでのとおりに、エンコードされた値をロールおよび職責に指定します。

詳細は、Oracle Identity Analyticsのドキュメントを参照してください。

22.6 SoDの有効化および無効化

次の各項では、SoDの有効化および無効化について説明します。

- SoDの有効化

- SoDの無効化

22.6.1 SoDの有効化

SoD機能を有効にするには、次の手順を実行します。

1. 「職務の分離(SOD)チェックは必須です」システム・プロパティをtrueに設定します。システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。

2. コネクタITリソース・インスタンスのtopologyNameパラメータをSILConfig.xml内に存在する値に設定します。デフォルトのSIL登録を使用している場合は、コネクタITリソースのtopologyNameパラメータを次のいずれかに設定します。

- sodoaacg: EBSコネクタと、SoDエンジンとしてOAACGを使用している場合

- oaacgpsft: PSFTコネクタと、SoDエンジンとしてOAACGを使用している場合

- sodgrc: SoDエンジンとしてGRCを使用している場合

- sodoia: SoDエンジンとしてOIAを使用している場合

注意:

すべてのユーザーがITリソース情報にアクセスできるように、コネクタITリソースにはALL USERSロールが付与されている必要があります。ユーザーが要求したSODリクエストにはこれが必要です。

3. SILおよびSILプロバイダのデプロイ
ターゲット・システムおよびSoDエンジンのデフォルトの組合せに対してSILおよびSILプロバイダをデプロイするには、次の手順を実行します。

1. Sodエンジンの新しいITリソースを次の名前(タイプ)で作成します。

- EBS-OAACGの場合: OAACG-ITRes (eBusiness Suite OAACG)

- SAP-GRCの場合: GRC-ITRes (SoDプロバイダ)

- OIAの場合: OIA-ITRes (OIA)という名前のITリソースが事前に定義されています。

- PSFT-OAACGの場合: PSFT-OAACG-ITRes(OAACG)という名前のITリソースが事前に定義されています。

2. 「SoDエンジンの情報を保持するためのITリソースの作成」の説明に従って、作成したITリソースを編集します。

注意:

- OAACG 8.5以上と構成するには、このITリソースにsodServerURLという名前とhttp(s)://HOST_NAME:PORT/URIという値を持つ新しいフィールドを追加します(この場合、URLはgrcc/services/GrccServiceになります)。OAACG8.2.1の場合、URLの値はags/services/AGServiceになります。

- システム・プロパティの値を設定する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。

4. ダイレクト・プロビジョニングおよびアクセス・ポリシー・ベースのプロビジョニングでのSoDの有効化:
SoDは、HolderおよびSODCheckerタスクがプロビジョニング・ワークフロー内に存在する場合にのみ有効にできます。

リクエスト・プロビジョニングでのSoDの有効化:

手順1および2により承認中のデフォルトのSoDチェックが有効になります。デフォルトのSoDチェックは、承認される前に実行されます。1つの承認レベルの後でSoDチェックが必要になった場合、デフォルトのSoDチェック承認ワークフローであるDefaultSODApprovalが、承認ポリシーの作成によりアタッチされる必要があります。SoDチェックは、任意の承認ワークフローでオンデマンドで実行することもできます。これは、BPELからSoDチェックWebサービスをコールすることによって行うことができます。詳細は、「SoD用の承認ワークフローの変更」を参照してください。

注意:

DefaultSODApprovalワークフローが承認の操作レベルにアタッチされている場合、システム管理者が最初に承認した後で、SoDチェックのみが実行されます。SoDチェックが実行された後、システム管理者による承認が必要です。このワークフローに従って、システム管理者に割り当てられている最初の承認タスクが生成され、次にSoDチェックが実行されてから、承認タスクが生成されます。システム管理者ロールのメンバーであればどのユーザーでも、SoDチェック結果を表示した後、2番目の承認タスクを承認できます。

5. SoDチェックのCSF資格証明の追加:

1. Enterprise Managerにログインし、左側のタブで「WebLogicドメイン」を開きます。

2. base_domainを開きます。

3. 右側のペインの上部で、「WebLogicドメイン」リストから「セキュリティ」を選択し、「資格証明」を開きます。

4. 「キーの作成」オプションを選択してから、マップ'oim'を選択します。

5. キーをsodcheck.credentialsとして指定し、「タイプ」を「パスワード」として指定します。

6. 「ユーザー名」をoiminternalとして指定し、パスワードを「未使用」として指定します。「OK」をクリックして、キーを保存します。

22.6.2 SoDの無効化

SoDは次のいずれかを実行して無効にできます。

- 「職務の分離(SOD)チェックは必須です」システム・プロパティをfalseに設定します。

- コネクタITリソースのtopologyNameパラメータの値を削除し、その値が空白に設定されるようにします。ITリソースのtopologyNameパラメータがNoneに設定されていると、SoDチェックは実行されません。

ダイレクト・プロビジョニングおよびアクセス・ポリシー・ベースのプロビジョニングでのSoDの有効化

HolderおよびSODCheckerプロセス・タスクを無効にします。

関連項目:

これらのプロセス・タスクの無効化の詳細は、コネクタのガイドを参照してください。

リクエスト・プロビジョニングでのSoDの無効化

承認中のデフォルトのSoDチェックを無効にするには、いずれかの手順を実行してSoDを無効にします。BPELで、承認中のデフォルトのSoDチェックを実行し、SoDチェックのみを無効にする場合は、SoDの承認ポリシーを削除するか、承認ワークフローからSoDチェックWebサービスのコールを削除します。

22.7 SSL通信の有効化

次の各項では、SoDの様々な用途のためのSecure Sockets Layer (SSL)通信の有効化について説明します。

- Oracle Application Access Controls GovernorとOracle Identity Manager間のSSLの有効化

- SAP GRCとOracle Identity Manager間のSSLの有効化

- SSL経由でのSoDチェックWebサービスのコール

22.7.1 Oracle Application Access Controls GovernorとOracle Identity Manager間のSSLの有効化

Oracle Application Access Controls GovernorとOracle Identity Manager間のSSL通信を有効にするには、次の手順を実行します。

注意:

登録プロセス中にsslEnableをtrueに設定したものと仮定します。

1. 次のようにしてOracle Application Access Controls Governorホスト・コンピュータで証明書をエクスポートします。

注意:

手順1で、JAVA_HOMEはOracle Application Access Controls Governorホスト・コンピュータ上のディレクトリを示しています。

1. JAVA_HOME/binディレクトリから次のコマンドを実行します。

keytool -genkey -alias tomcat -keyalg RSA -keystore JAVA_HOME/lib/security/.keystore
keytool -certreq -alias tomcat -file JAVA_HOME/lib/security/xell.cvs -keystore JAVA_HOME/lib/security/.keystore
keytool -export -alias tomcat -file JAVA_HOME/lib/security/server.cert -keystore JAVA_HOME/lib/security/.keystore

これらのコマンドを実行した後、サーバー証明書(server.cert)がJAVA_HOME/lib/securityディレクトリ内に作成されます。

2. TOMCAT_HOME/conf/server.xmlファイルで、キーストアの詳細をConnector要素の属性として入力します。次の例を参照してください。

<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile="JAVA_HOME/lib/security/.keystore">

3. Oracle Application Access Controls Governorを再起動します。

2. 次のようにしてOracle Identity Managerホスト・コンピュータに証明書をインポートします。

注意:

手順2で、JAVA_HOMEはOracle Identity Managerホスト・コンピュータ上のディレクトリを指しています。

1. Oracle Application Access Controls Governorホスト・コンピュータで作成されたサーバー証明書を、Oracle Identity Managerホスト・コンピュータのJAVA_HOME/lib/securityディレクトリにコピーします。

2. JAVA_HOME/binディレクトリから次のコマンドを実行します。

keytool -import -alias oaacg_trusted_cert  -file JAVA_HOME/lib/security/server.cert -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit

22.7.2 SAP GRCとOracle Identity Manager間のSSLの有効化

SAP GRCとOracle Identity Manager間のSSL通信を有効にするには、SAP GRCホスト・コンピュータで次のようにして証明書をエクスポートします。

注意:

ここでは、JAVA_HOMEは、アプリケーション・サーバーの実行に使用されるOracle Identity Managerホスト・コンピュータ上のディレクトリを指しています。

1. Webブラウザで、SAP GRC Access Controlの「Web Services Navigator」ページを開きます。URLは次のようなものです。

https://mysapserver01:50001/VirsaCCRiskAnalysisService/Config1?wsdl

2. 次の手順は、使用しているブラウザによって異なります。

- Microsoft Internet Explorerの場合: 「セキュリティの警告」ダイアログ・ボックスで、「証明書の表示」をクリックします。ダイアログ・ボックスの「詳細」タブで「このファイルをコピーする」ボタンを使用して、証明書をエクスポートします。

- Mozilla Firefoxの場合: 証明書を.pemファイルとしてエクスポートします。この手順を実行するには、Mozilla Webサイトから証明書ビューア拡張機能をダウンロードし、インストールすることが必要となる場合があります。

3. Oracle Identity Managerをホストするアプリケーション・サーバーによって使用されるJAVA_HOME/lib/securityディレクトリに、証明書をコピーします。

4. 端末ウィンドウで、JAVA_HOME/binディレクトリに移動します。

5. 次のコマンドを実行して、GRC証明書をcacertsにインポートします。

keytool -import -alias sapgrc_trusted_cert -file JAVA_HOME/lib/security/CERTIFICATE_FILENAME -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit

このコマンドでは、次のように指定します。

- CERTIFICATE_FILENAMEは、SAP GRCホスト・コンピュータからエクスポートした証明書の名前です。

- -storepass changeit句は、cacertsキーストアのパスワードを指定します。

6. 証明書を信頼するかどうかの指定を要求されたら、yesを入力します。
証明書がキーストアに追加されたことを示すメッセージが表示されます。

22.7.3 SSL経由でのSoDチェックWebサービスのコール

SOAでは、oim-config.xmlファイル内でoimFrontEndURLとして指定されているURL (Oracle Identity Manager UIへのアクセスに使用されるURL)経由で、Oracle Identity Manager Webサービスをコールします。デフォルトではこれはHTTP URLです。通信がSSL経由で行われるように、これをHTTPSに変更できます。Oracle Identity ManagerのSSLポートは、WebLogic管理コンソールで確認できます。

SSL経由でSoDチェックWebサービスをコールするには、次の手順を実行します。

1. Oracle Identity ManagerのSSLポートを特定します。これを行うには、次の手順を実行します。

1. WebLogic管理コンソールにログインします。

2. 「サーバー」→「oim_server1」に移動します。「SSLリスニング・ポート」が有効になっています。

2. Enterprise ManagerのMBeanブラウザでoimFrontEndURLを変更します。これを行うには、次の手順を実行します。

1. Enterprise Managerにログインします。

2. 「oim_server1」に移動します。

3. ペインの上部にあるリストから、システムMBeanブラウザを選択します。

4. アプリケーション定義のMBean→「oracle.iam」→「サーバー: oim_server1」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.DiscoveryConfig」→「検出」に移動します。属性が右側に表示されます。

5. 「oimFrontEndURL」をクリックし、値を次のように変更します。
https://HOST_NAME:SSL_PORT

注意:

oimFrontEndURLの値は、Oracle Identity Managerのインストール時に設定することもできます。

3. Oracle Identity Managerを再起動します。

4. SoD対応リソースに対するリクエストを作成します。新しいワークフロー・インスタンスはEnterprise Managerで確認できます。SSLポートでWebサービスがコールされるようになります。

注意:

Oracle Identity ManagerおよびSOAが同じJava Runtime Environment (JRE)で実行されているものと仮定します。SOAとOracle Identity Managerが異なるJREで実行されている場合、SSL通信を行うためにはWebLogic証明書の交換が必要になります。詳細は、次のURLを使用してOracle Technology Network (OTN) WebサイトにあるOracle WebLogic Server 10gリリース3 (10.3)のドキュメントを参照してください。

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

22.8 SoD非対応コネクタでのワークフローの構成

この項で説明されている手順は、事前に構成されたSoD互換コネクタ(Oracle E-Business User ManagementおよびSAP User Management)の1つを使用しない場合のみ実行してください。この項の内容は次のとおりです。

- SoD用の承認ワークフローの変更

- SoD用のプロビジョニング・ワークフローの変更

22.8.1 SoD用の承認ワークフローの変更

SoD用の承認ワークフローを変更するには、次の手順を実行します。

注意:

フォームは、コネクタ・プロセス・フォームに基づいてUIで作成されます。リクエスト・データセットは、Oracle Identity Managerでは必要なくなりました。

1. コネクタのITリソースで、まだ存在しない場合はTopologyNameパラメータを作成します。図22-3に、このパラメータが追加されたサンプルのITリソースを示します。

図22-3 TopologyNameパラメータ

コネクタITリソースでSoDチェック・プロパティがtrueに設定され、topologyNameパラメータが適切な値に設定されている場合、承認ワークフローの前処理ステージでデフォルトのSoDチェックが実行されます。リクエストが作成された後、リクエスト・ステータスが、非同期SoDチェックの場合は「SoDチェック結果が保留中です」、同期SoDチェックの場合は「SoDチェックが完了しました」ステータスになります。非同期SoDチェックの場合、SoDチェックを完了するにはSoDチェック結果の取得(承認)スケジュール済ジョブが実行されている必要があります。

注意:

SoDチェックの実行中にエラーが発生した場合は、リクエスト・データセット内の「SoDチェックのステータス」属性が「SoDチェックがエラーで完了しました」に設定され、リクエストが承認に送られます。SoDチェックが正常に実行されていなくてもリクエストを承認するかどうかについての最終的な決定は、承認者が下します。

図22-4に、非同期SODチェックのリクエスト履歴を示します。

図22-4 非同期SoDチェックのリクエスト履歴

2. あらゆるレベルの承認の前にデフォルトでトリガーされるSoDチェックに加え、事前定義されたDefaultSODApprovalワークフローをアタッチすることによってもSoDチェックをトリガーできます。ワークフローを承認の操作レベルにアタッチするには、承認ポリシーを作成します。

注意:

Oracle Identity Manager 11gでは、SoDワークフローが機能するためにはSOAおよびWebLogic Serverにパッチが必要でした。現在、Oracle Identity Managerにパッチは必要ありません。

デフォルト・ワークフローの使用の詳細は、「承認ポリシーを使用したワークフローの適用」を参照してください。このワークフローには、システム管理者に割り当てられる承認タスクが含まれています。この承認タスクの後で、SoDチェック結果を戻すために、SoDCheck Webサービスがコールされます。図22-5に、SoDCheck Webサービス・コールを含むワークフローを示します。

注意:

すべてのリクエストには、テンプレート・レベル承認、リクエスト・レベル承認および操作レベル承認の、3つの承認レベルがあります。DefaultSODApprovalワークフローをアタッチできるのは、承認レベルのみです。バルク・リクエストでは、すべてのリソースおよびユーザーについて、リクエスト・レベル承認が一般的です。このレベルの承認後、リソースとユーザーの組合せごとに個別のリクエストが作成されます。ワークフローでは、リソースとユーザーごとに、個別にSoDチェックが実行されます。

ワークフローは、リクエスト・レベル承認の後でSoDチェックが必要な場合に役立ちます。一例として、承認者によりコネクタITリソース情報が入力される場合があります。この場合、リクエスト・データセットのITリソース・フィールドは、次に示すように承認者専用に設定されます。

<AttributeReference name="EBS Server" attr-ref="EBS Server" type="String" length="50" widget="itresource-lookup" available-in-bulk="true" itresource-type="eBusiness Suite UM" required="true" approver-only="true"/>

この例では、リクエストの要求時にはITリソース情報は使用できません。これは、承認者による入力後に初めて使用できるようになります。リクエスト・レベル承認時にこれが入力された場合は、DefaultSODApprovalワークフローを操作レベルで使用できます。

承認のみのフィールドは、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)でサポートされていません。

図22-5 SoDCheck Webサービス・コールを含むワークフロー

この後、承認タスクを含むswitch caseがシステム管理者ロールに割り当てられます。このロールを持つすべてのユーザーは、タスクを要求して承認できます。図22-6に示すように、switchは、SoDチェックの結果が成功か失敗かに基づきます。

図22-6 承認タスクを含むSwitch Case

図22-7に、承認タスクの割当てを示します。

図22-7 承認タスクの割当て

承認ワークフローは、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)でBPELに移行されたため、デフォルト・ワークフローを表示または変更するには、JDeveloperを使用する必要があります。デフォルトのSoDワークフローは、OIM_HOME/workflows/composites/DefaultSODApproval.zipファイルに含まれています。このファイルを解凍し、JDeveloperでDefaultSODApproval.jprを開くことができます。さらに、デフォルトの承認ワークフローを変更して新しいワークフローを作成し、SoDチェックWebサービスをコールしてオンデマンドでSoDチェックを開始できます。これを行うには、次の手順を実行します。

SOAでのワークフローの作成とデプロイ

1. OIM_HOME/workflows/new-workflow/new_project.xmlを実行して、新しいワークフロー・プロジェクトを作成します。
説明:

- WEBLOGIC_HOMEは、Oracle WebLogic Serverがインストールされているディレクトリです。

- NEW_PROJECTは、作成する新規プロジェクトの名前です。

新しいワークフロー・プロジェクトを作成するには、次のコマンドを実行します。

ant -f new_project.xml

これにより、新しいワークフロー名のプロジェクト名、アプリケーション名およびサービス名を入力するよう要求されます。この3つすべてに、SODWorkflowのような任意の名前を指定します。これにより、指定された名前を持つ新規プロジェクトがworkflows/new-workflow/process-template/ディレクトリに作成されます。

2. JDevepolerでprocess-template/APPLICATION_NAME/PROJECT_NAME/にナビゲートし、PROJECT_NAME.jprを開きます(ここで、APPLICATION_NAMEおよびPROJECT_NAMEは、それぞれアプリケーションおよびプロジェクトの名前です)。
PROJECT_NAME.jprワークフローは、DefaultRequestApprovalワークフローと同じです。SoDCheck Webサービスをコールするように、このワークフローを変更できます。図22-8に、人による承認後にSoDチェックを実行するように変更された、デフォルト・ワークフローを示します。

図22-8 SoDチェックを実行するように変更されたワークフロー

3. OIM_HOME/workflows/composites/DefaultSODApproval.zipを解凍し、asyncsod.wsdlを解凍されたディレクトリからOIM_HOME/workflows/ process-template/APPLICATION_NAME/PROJECT_NAME/にコピーします。SODCheckService1などのWebサービスをcomposite.xmlに追加し、asyncsod.wsdlをWSDLファイルとして提供します。SoDCheckパートナ・リンクは、図22-9のようになります。

注意:

BPELは、パートナ・リンクを介してすべての外部エンティティに接続します。

図22-9 SoDチェック・パートナ・リンク

4. ApprovalProcess.bpel設計に、次のBPELアクティビティを含めます。

- ASSIGN: assignアクティビティは、SoDチェックWebサービスをコールする前に追加する必要があります。このアクティビティにより、Webサービスをコールするために必要なパラメータが初期化されます。assignアクティビティを作成するには、次の手順を実行します。
i) JDeveloperで開いたBPELプロセスにアクティビティをドラッグ・アンド・ドロップします。

ii) アクティビティが作成されたら、アクティビティをダブルクリックし、「コピー操作」タブをクリックします。

iii) 「追加」をクリックして「コピー操作」を選択します。表22-1に示すように、変数の値を指定します。

表22-1 割り当てる変数

コピー元

コピー先

XML Fragment

<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address/>
</EndpointReference>

変数

partnerlink

Expression

concat(substring-before(bpws:getVariableData('inputVariable','payload','/client:process/ns1:url'), "/workflowservice/CallbackService"), '/sodcheck/SoDCheckInitiateService')

Partnerlink, EndpointReference, Address

変数

partnerlink

Partner Link

SODCheckService1

変数

Payload, RequestId

変数

SODInvoke_initiate_InputVariable。SODInvoke_initiate_InputVariableは、Invoke BPELアクティビティで定義された変数です。

次の各図に、追加される値を示します。

図22-10に、最終的なassignアクティビティを示します。

図22-10 最終的なAssignアクティビティ

- INVOKE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink

パートナ・リンク: SODCheckService

操作: Initiate

入力変数: SODInvoke_initiate_InputVariable

図22-11に、フィールドにサンプル値が入力された「Invoke」ダイアログ・ボックスを示します。

図22-11 「Invoke」ダイアログ・ボックス

- RECEIVE: このアクティビティの詳細は次のとおりです。
相互作用タイプ: Partnerlink

パートナ・リンク: SODCheckService

操作: Result

変数: SODResultReceive_result_InputVariable

図22-12に、フィールドにサンプル値が入力された「Receive」ダイアログ・ボックスを示します。

図22-12 「Receive」ダイアログ・ボックス

- SWITCH: このアクティビティは、SODCheckの結果に基づいてワークフローをスイッチするためのものです。switch caseは、図22-13のようになります。

図22-13 Switch Case

- 新規ヒューマン・タスク: 新規ヒューマン・タスクを作成して、システム管理者以外の承認者に割り当てることができます。新規承認タスクは、ワークフローにすでに存在する古いものと同じですが、承認者が異なります。このヒューマン・タスクはswitch caseで使用されます。たとえば、SoDチェックが成功した場合に、承認タスクをロールに割り当てることができます。SoDチェックが失敗した場合は、承認タスクをシステム管理者ロールに割り当てることができます。DefaultSODApprovalでは常に、承認タスクをシステム管理者ロールに割り当てます。

注意:

SoDCheck Webサービスは複数回コールできます。

5. AsyncSoD WebサービスのリクエストとコールバックのためのSAMLポリシーの適用:
Security Assertion Markup Language (SAML)に基づいたメッセージ保護ポリシー付きOWSM SAMLトークンは、SOAコンポジットからOracle Identity ManagerへのSoDチェックの非同期コールにおいて、メッセージ保護のセキュリティ・ポリシーとして使用されます。非同期SoDチェックWebサービスでは、この項で説明するように、リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンおよびコールバックのためのメッセージ保護サービス・ポリシー付きSAMLトークンを使用する必要があります。

リクエストのためのメッセージ保護クライアント・ポリシー付きSAMLトークンを適用するには、次の手順を実行します。

i) 図22-14に示すように、AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「リクエスト対象」を選択します。

図22-14 リクエストのためのWSポリシーの構成

ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。

iii) 図22-15に示すように、クライアント・セキュリティ・ポリシーの選択ダイアログ・ボックスで「wss11_saml _token_with_message_protection_client_policy」を選択し、「OK」をクリックします。

図22-15 クライアント・セキュリティ・ポリシーの選択

コールバックのためのメッセージ保護サービス・ポリシー付きSAMLまたはユーザー名トークンを適用するには、次の手順を実行します。

i) AsynchSoD Webサービスを右クリックし、「WSポリシーの構成」を選択して、「コールバック対象」を選択します。

ii) 「SOA WSポリシーの構成」ダイアログ・ボックスの「セキュリティ」セクションで、正符号(+)のアイコンをクリックしてセキュリティ・ポリシーを追加します。

iii) 図22-16に示すように、サーバー・セキュリティ・ポリシーの選択ダイアログ・ボックスで「wss11_saml _or_username_token_with_message_protection_service_policy」を選択し、「OK」をクリックします。

図22-16 サーバー・セキュリティ・ポリシーの選択

6. プロジェクトをコンパイルして、エラーがないか確認します。エラーがない場合は、プロジェクトを右クリックし、「デプロイ」を選択します。表示されるダイアログ・ボックスで、次のいずれかのオプションを選択します。

- アプリケーション・サーバーにデプロイ: このオプションを選択してから、適切なサーバーを選択します。ワークフローは、アプリケーション・サーバーに直接デプロイされます。

- JARにデプロイ: JDeveloperのデプロイ・ディレクトリの下に、sca_PROJECT_NAME_rev1.0.jarという名前でJARファイルが作成されます(ここで、PROJECT_NAMEはプロジェクトの名前です)。

7. SOA_HOME/bin/ディレクトリから、次のコマンドを実行してSOAサーバーにワークフローをデプロイします。

注意:

- このガイドでは、SOA_HOMEはSOAサーバーがインストールされているディレクトリを指します。

- このコマンドを実行する前に、SOAサーバーが稼働していることを確認してください。

ant -f ant-sca-deploy.xml -DserverURL=http://SOA_SERVER_HOSTNAME:SOA_PORT
-DsarLocation=JDeveloper/deploy/sca_PROJECT_NAME_rev1.0.jar -Duser=SOA_USER -Dpassword=SOA_PASSWORD

注意:

次の項目を有効な値で置き換える必要があります。

- SOA_SERVER_HOSTNAME

- SOA_PORT

- PROJECT_NAME

- SOA_USER

- SOA_PASSWORD

これにより、SOAサーバーに新規コンポジットがデプロイされます。次のURLにナビゲートすると、コンポジットがデプロイされたかどうかを確認できます。

http://SOA_SERVER_HOSTNAME:SOA_PORT/soa-infra

URLのSOA_SERVER_HOSTNAMEはSOAサーバーのホスト名で、SOA_PORTはSOAサーバーがインストールされているポートで置き換えてください。

8. SOAサーバーを再起動します。

関連項目:

新しいワークフローの一般的な作成手順の詳細は、「承認および手動プロビジョニングのワークフローの開発」を参照してください。

ワークフローの登録

1. OIM_HOME/workflows/registration/ディレクトリに、DefaultRequestApproval.propsをコピーしてNEW_PROJECT_NAME.propsファイルを作成します。名前属性を変更して、NEW_PROJECT_NAME.propsを変更します。
ここで、NEW_PROJECT_NAMEは作成した新規プロジェクトの名前です。

NEW_PROJECT_NAME.propsファイルの内容は次のとおりです。

#This is is the input file for registering the default workflow
# <new project name>
name=NEW_PROJECT_NAME
category=Approval
providerType=BPEL
serviceName=RequestApprovalService
domainName=default
version=1.0
payLoadID=payload
operationID=process
listOfTasks=ApprovalTask

各構成要素は次のとおりです。

- versionパラメータは、BPELにデプロイされたワークフローのバージョンです。

- listOfTasksパラメータは、承認タスクのコロン区切りリストです。たとえば、新規承認タスクをApproval_Task1として追加する場合は、ApprovalTask:ApprovalTask1をこのパラメータの値として指定する必要があります。

2. 次のようにしてOIM_HOME/workflows/registration /registerworkflows-mp.xmlを実行します。
ant -f registerworkflows-mp.xml register

このコマンドにより、次の項目を入力するよう要求されます。

ユーザー名: Oracle Identity Manager管理者のユーザー名を入力します。

パスワード: Oracle Identity Manager管理者のパスワードを入力します。

OIMサーバーのt3 URL: t3://OIM_HOST_NAME/OIM_MANAGED_SERVER_PORTと入力します。ここで、OIM_HOST_NAMEはOracle Identity Managerがインストールされているコンピュータのホスト名で、OIM_MANAGED_SERVER_PORTはOracle Identity Managerがインストールされているポートで置き換えます。

プロパティ・ファイルの入力パス(完全なファイル名): OIM_HOME/workflows/registration/NEW_PROJECT_NAME.props。ここで、NEW_PROJECT_NAMEは作成したプロジェクトの名前で置き換えます。

承認ポリシーを使用したワークフローの適用

1. SoDワークフローを適用するリクエスト・モデル用の承認ポリシーを作成します。たとえば、リソースのプロビジョニング中にSoDチェックを実行するには、「リソースのプロビジョニング」リクエスト・モデル用のポリシーを作成します。承認ポリシーの作成の詳細は、Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイドの承認ポリシーの作成に関する説明を参照してください。

注意:

- SoDはリソースごとに個別にトリガーされるため、SoDワークフローは必ず承認の操作レベルでアタッチしてください。

- SoDエンジンが非同期であるか同期であるかにかかわらず、SoDチェックWebサービスは常に非同期であり、ワークフローの変更は両方に対して同じになります。

22.8.2 SoD用のプロビジョニング・ワークフローの変更

各プロセス定義には、権限をユーザーにプロビジョニングするために、1つのプロセス・タスクがアタッチされています。SoD検証プロセスは、このタスクをトリガーする前、ターゲット・システムで権限を保持する子表にすべてのデータを挿入した直後に実行する必要があります。したがって、子表にデータを挿入した後、SoD検証プロセスが完了するまで、このプロセス・タスクを保持する必要があります。これを実行するには、ユーザーへの権限のプロビジョニングに先行するHolderタスクを作成します。

Holderタスクは、SoD検証プロセスが完了する前に、ユーザーにリソースをプロビジョニングすることを防ぐために追加されます。ユーザー権限は、このタスクが完了した場合にのみプロビジョニングされます。SoDエンジンで、権限の割当てがSoDポリシーまたはルールに違反していないことが検証されると、このタスクは完了します。

SoD検証プロセスが承認ワークフローで実行された場合、プロビジョニング・レベルでSoD検証プロセスが有効になっている場合であっても、SoD検証プロセスを再実行する必要はありません。SoD検証プロセスを実行する必要があるかないかは、プロビジョニング・レベルでのSoD検証プロセスの前に、次のチェックを行うことにより評価できます。

- プロビジョニングはリクエストに関連がありますか。

- 関連がある場合、SoDCheckStatusフィールドはSoDCheckCompletedに設定されていますか。

- 設定されている場合、権限のプロビジョニング中にSoD検証プロセスを実行しないでください。

注意:

SoD検証プロセスは、プロセス子フォームが権限の追加、更新または削除のために編集された場合のみ再実行されます。

SoD検証用プロビジョニング・ワークフローを変更するには、次の手順を実行します。

1. Holderタスクをプロビジョニング・ワークフローに追加します。このタスクは条件付きにし、「複数のインスタンスを許可」オプションを選択する必要があります。
次の図は、このHolderタスクを示しています。

2. コネクタの権限の挿入、更新および失効タスクを、Holderタスクに依存させます。
次の図は、Holderタスクに依存するOracle E-Business User Managementコネクタのすべての権限タスクを示しています。

次の図は、Add Responsibility to Userタスクに先行するタスクとしてのHolderタスクを示しています。

3. SODCheckerタスク(名前がSODCheckerで始まる任意のタスク)を追加します。このタスクは条件付きにする必要があります。
次の図は、このSODCheckerタスクを示しています。

4. InitiateSODCheckプロセス・タスク・アダプタをSoDCheckerタスクにアタッチします。
次のレスポンス・コードをSODCheckerタスクにアタッチします。

レスポンス・コード

タスク・ステータス

説明

SODCheckResultPending

P

SoD検証プロセスが開始され、結果待ちの状態です。

注意: このレスポンス・コードはSoDエンジン用で、レスポンスが非同期的に返されます。

SODCheckCompleted

C

SoD検証プロセスの結果が返され、レスポンスはSoD違反がないことを示します。

SODCheckViolation

C

SoD検証プロセスの結果が返され、レスポンスはSoD違反があることを示します。

注意: 競合する権限を持つEBS 9.1.0.7.0リソースのリクエスト・プロビジョニングについては、プロセス・フォームのSodCheckViolationフィールドは更新されません。権限の違反は、SoDCheckEntitlementViolationラベルが付いたフィールドにマップされますが、EBSリソースにあるのは、SoDCheckViolationラベルが付いたフィールドです。したがって、マッピングは行われません。ダイレクト・プロビジョニングおよびアクセス・ポリシーを介したプロビジョニングが、SoDCheckViolationフィールド・ラベルで正常に行われます。リクエスト・プロビジョニングについてこの問題を回避するには、Design Consoleを使用して、EBSフォームのSoDCheckViolationフィールド・ラベルをSoDCheckEntitlementViolationに変更します。

注意: 値がSoDCheckEntitlementViolationの場合は、リクエスト、直接、アクセス・ポリシーなどあらゆるタイプのプロビジョニングが正常に行われます。したがって、値を変更せずに、SoDCheckEntitlementViolationとして値を保持できます。

SODCheckNotInitiated

C

Oracle Identity ManagerでSoDが有効になっていないため、SoD検証プロセスは開始されていません。

次の図に、これらのレスポンス・コードを示します。

22.9 権限データを保持する子プロセス・フォーム表のマーク

子プロセス・フォーム表では、異なるタイプの複数値データ(ロール・データ、プロファイル・データおよびアドレス情報など)を保持できます。SoD処理に使用する権限データを保持している子プロセス・フォーム表をマークする必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の子プロセス・フォームでの権限属性のマークに関する説明を参照してください。

この項には次のトピックが含まれます:

- 権限データを保持するリクエスト・データセット属性のマーク

- 権限データを保持する子プロセス・フォーム表のマーク

22.9.1 権限データを保持するリクエスト・データセット属性のマーク

権限を保持するリクエスト・データセット属性を、権限プロパティをtrueに設定してマークします。次に例を示します。

<AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true" entitlement="true">
<lookupQuery lookup-query="select lkv_encoded as lkv_encoded,lkv_decoded as lkv_decoded from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and
lku_type_string_key='Lookup.EBS.Responsibility' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
</AttributeReference>

22.9.2 権限データを保持する子プロセス・フォーム表のマーク

子プロセス・フォーム表では、異なるタイプの複数値データ(ロール・データ、プロファイル・データおよびアドレス情報など)を保持できます。SoD処理に使用する権限データを保持している子プロセス・フォーム表をマークする必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の子プロセス・フォームでの権限属性のマークに関する説明を参照してください。

22.10 ターゲット・システムおよびSoDエンジンのカスタムの組合せ

この項には次のトピックが含まれます:

- カスタム・ターゲット・システムの使用

- カスタムSoDエンジンの追加

22.10.1 カスタム・ターゲット・システムの使用

注意:

この項で説明する手順は、Oracle E-Business SuiteおよびSAP R3以外のターゲット・システムを使用する場合にのみ実行します。Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合は、「カスタムSoDエンジンの追加」の手順も実行する必要があります。

この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。

次に、新規ターゲット・システム用のSILを構成する手順のサマリーを示します。

1. 「前提条件への対応」の項に示されている手順に従います。

2. コネクタ用にIdMvsSoDDataTransformationOperインタフェースのJavaクラス実装を作成します。手順は、「変換レイヤーの作成」を参照してください。

3. 変換サービス・コンポーネントをデプロイします。「変換レイヤーのデプロイ」を参照してください。

4. 登録XMLファイルに新規ターゲット・システムのエントリを追加します。手順は、「登録XMLファイルの変更」を参照してください。

5. 「SoD非対応コネクタでのワークフローの構成」の手順を実行します。

6. 権限データを保持する子プロセス・フォームをマークします。手順は、「権限データを保持する子プロセス・フォーム表のマーク」を参照してください。

7. 新規ターゲット・システムを登録します。手順は、「新規ターゲット・システムの登録」を参照してください。

22.10.1.1 前提条件への対応

次の前提条件を満たしていることを確認します。

1. ターゲット・システムからSoDエンジンに権限データをロードします。
詳細は、SoDエンジンのベンダーのドキュメントを参照してください。

2. ターゲット・システム用のOracle Identity Managerコネクタをデプロイします。詳細は、コネクタのドキュメントを参照してください。

22.10.1.2 変換レイヤーの作成

変換レイヤーは、ターゲット・システムの属性値を、SoDエンジンで使用可能な値に変換するために使用されます。変換レイヤーは、すべての新規SoDエンジンまたはターゲット・システム・タイプに対して作成する必要があります。

IdMvsSoDDataTransformationOperインタフェースの実装として、変換レイヤーを作成する必要があります。transformInputおよびtransformSoDAnalysisInputメソッドの実装は、IdMvsSoDDataTransformationOperインタフェースの実装クラスで作成します。

関連項目:

実装メソッドの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

Oracle Identity Managerの以前のリリースでは、承認ワークフロー・データはオブジェクト・フォームから読み取られます。Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、オブジェクト・フォームは承認プロセス内のリクエスト・データセットに置き換えられています。そのため、権限データがオブジェクト・フォームではなくリクエスト・データセットから読み取られるように、変換レイヤーを変更する必要があります。

変換レイヤーでは、リクエスト・モデルもチェックする必要があります。リクエスト・モデルがリソースのプロビジョニングである場合、データはリクエスト・データセットからのみ読み取る必要があります。一方、リクエスト・モデルがプロビジョニング済リソースの変更である場合は、データはリクエスト・データセットとプロセス・フォームの両方から読み取る必要があります。

22.10.1.3 変換レイヤーのデプロイ

変換サービス・コンポーネントは、次のようにデプロイされます。

1. IdMvsSoDDataTransformationOperサービス・コンポーネント・タイプの実装用に作成したJavaクラスのJARファイルを作成します。

2. UploadJarユーティリティを使用して、JARファイルをThirdPartyとしてアップロードします。

注意:

UploadJar.shまたはUploadJar.batユーティリティは、OIM_HOME/bin/ディレクトリにあります。この場所からユーティリティを実行して、作成したJARファイルをMDSにアップロードします。

22.10.1.4 登録XMLファイルの変更

registration.xmlファイルで、次のようにして変換レイヤーの詳細を入力します。

1. MDSからRegistration.xmlファイルをインポートします。Registration.xmlファイルは、ネームスペース/metadata/iam-features-sil/db/Registration.xmlでMDS内に存在します。

2. テキスト・エディタでRegistration.xmlファイルを開きます。

3. SystemType要素およびServiceComponent要素を、このXML行ブロックのように追加します。

注意:

設定が必要な値は、太字で強調されています。このXMLブロックの後に、ガイドラインとサンプル値を示します。

<SystemType name="SYSTEM_TYPE_NAME" type="Sod Source DataStore"></SystemType>

<ServiceComponent type="IdMvsSoDDataTransformationOper" name="NAME_FOR_IMPLEMENTATION"
<Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class>
<IdMSystemType>OIM</IdMSystemType>
<SoDEngineType>SoD_ENGINE</SoDEngineType>
<srcSystemType>SYSTEM_TYPE_NAME</srcSystemType>

<DataTransformation>
<AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM"  sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/>
<AttrSoD type="user" name="firstname"  sourceIdMAttrName="firstname" isSourceKey="false"/>
<AttrSoD type="user" name="lastname"  sourceIdMAttrName="lastname" isSourceKey="false"/>
<AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE"  name="accessorigid"  sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/>
</DataTransformation>

<DataTransformation>
. . .
</DataTransformation>

<DataTransformation>
. . .
</DataTransformation>
</ServiceComponent>

registration.xmlファイルでSystemType要素とServiceComponent要素を追加する際、次のガイドラインに従います。

- プレースホルダを次の値に置き換えます。

- SYSTEM_TYPE_NAME: システム・タイプの名前を指定します。

- <SystemType>タグのタイプには、カスタム・ターゲット・システムの場合はSoD Source DataStore値を、カスタムSoDエンジンの値としてはSoD Engineを指定できます。

- NAME_FOR_IMPLEMENTATION: サービス・コンポーネントの名前を指定します。たとえば、DBToOAACGのように指定します。

- NAME_OF_IPMLEMENTATION_CLASS: 「変換レイヤーの作成」の手順に従って作成したクラスに設定した名前を指定します。たとえば、oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACGのように指定します。

- SoD_ENGINE: SoDエンジンとしてOracle Application Access Controls Governorを使用する場合は、OAACGを入力します。SoDエンジンとしてSAP GRCを使用する場合は、GRCを入力します。カスタムSILプロバイダを使用する場合は、そのSoDエンジンに設定した名前を入力します。

関連項目:

「カスタムSoDエンジンの追加」

- SYSTEM_TYPE_NAME: 先に入力したシステム・タイプ名を指定します。

- NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: ターゲット・システムの属性の名前を指定します。

- NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: SoDエンジンの対応する属性の名前を指定します。

- ENTITLEMENT_TYPE: 権限のタイプを入力します。たとえば、ROLEのように指定します。

- ENTITLEMENT_NAME: 権限の1つのインスタンスの名前を入力します。たとえば、Resource Managerのように指定します。

- 作成する属性マッピングごとに1つのDataTransformation要素を追加します。

4. Registration.xmlファイルを保存して閉じます。

5. Registration.xmlファイルをエクスポートしてMDSに戻します。

22.10.1.5 新規ターゲット・システムの登録

新規ターゲット・システムを登録するには、次の各項に記載されている手順を実行します。

- 登録スクリプトの実行と登録情報の指定

- システム・タイプ名の記録

22.10.1.5.1 登録スクリプトの実行と登録情報の指定

登録スクリプト(registration.shおよびregistration.bat)により、登録プロセスが進められます。このスクリプトを実行すると、必要な情報を入力するよう要求されます。スクリプトにより最初に表示される一連のプロンプトは、registration.xmlファイルから読み取られます。登録スクリプトはOIM_HOME/binディレクトリにあります。registration.xmlファイルはMDSにあります。

注意:

- このユーティリティを実行する前に、APP_SERVER、OIM_ORACLE_HOME、JAVA_HOME、MW_HOME、WL_HOME、およびDOMAIN_HOMEを設定します。

- Oracle Identity Managerインストールのライフサイクル中はいつでも、登録スクリプトを複数回実行できます。たとえば、新規のSoDエンジンを登録するとします。スクリプトの実行時に、プロンプトを使用して、入力を行うセクションに移動します(一連のプロンプト)。残りのセクションはスキップできます。
登録スクリプトの実行例は、例22-1を参照してください。この例では、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。

スクリプトを実行し、Oracle Identity Managerインストール、SoDエンジンおよびターゲット・システムの登録情報を指定するには、次の手順を実行します。

1. MDSからSILConfig.xmlファイルをエクスポートします。SILConfig.xmlファイルは、ネームスペース/metadata/iam-features-sil/db/SILConfig.xmlで、MDS内に存在します。

2. テキスト・エディタでSILConfig.xmlファイルを開き、DOMBuilderFactoryImpl要素の値を指定します。
DOMBuilderFactoryImpl要素の値は、使用するJREによって異なります。

- Sun JREまたはOracle JRockit JREを使用する場合は、次の値を含むDOMBuilderFactoryImpl要素のコメントアウトを解除します。

com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

- IBM JREを使用する場合は、次の値を含むDOMBuilderFactoryImpl要素のコメントアウトを解除します。

org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

3. コマンド・ウィンドウで、OIM_HOME/binディレクトリに移動し、登録スクリプトを実行します。
Oracle Identity Managerのログイン情報を入力します。ユーザー名、パスワードおよびURLの値を入力するよう要求されます。サンプルの実行セグメントを次に示します。

[Enter the admin username:]OIM_ADMINISTRATOR_LOGIN
[Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD
[Enter the service url:]t3://OIM_HOST_NAME:OIM_PORT_NO

次の項目に対して有効な値を指定します。

- OIM_ADMINISTRATOR_LOGIN

- OIM_ADMINISTRATOR_PASSWORD

- OIM_HOST_NAME

- OIM_PORT_NO

T3 URLの例は次のとおりです。

t3://localhost:14000

登録を続行するかどうかの指定を要求されます。

Do you want to proceed with registration? (y/n)

注意:

ここから先は、スクリプトで表示される各プロンプトの説明の後に、プロンプトの実際のメッセージが続きます。このドキュメントでは、実際のメッセージは固定幅フォントで示されます。

4. 登録を続行するには、yを入力します。Oracle Identity Managerインストールを登録するかどうかの指定を要求されます。

Register System Instance for type OIM?(y/n)

5. nを入力します。

注意:

ここから先は、Oracle E-Business SuiteおよびOracle Application Access Controls Governorインストールの登録固有の流れになります。流れは、SAP R/3およびSAP GRCインストールの場合とほぼ同じです。

6. Oracle E-Business Suiteインストールを登録するかどうかの指定を要求されます。

Register System Instance for type EBS? (y/n)

7. デフォルトで登録されている既存のOracle E-Business Suiteを使用する場合は、nを入力します。Oracle Identity Managerの別のITリソースを含む新規EBSインスタンスを登録するには、yを入力します。

8. yを入力すると、Oracle E-Business Suiteインストールのインスタンス名の入力を要求されます。

Provide instance name

Oracle E-Business Suiteインストールの名前を入力します。例:

ebs2

9. Oracle Application Access Controls Governorインストールを登録するかどうかの指定を要求されます。

Register System Instance for type OAACG? (y/n)

デフォルトで登録されている既存のOAACGを使用する場合は、nを入力します。Oracle Identity Managerの別のITリソースを含む新規OAACGインスタンスを登録するには、yを入力します。

10. yを入力すると、Oracle Application Access Controls Governorインストールのインスタンス名の入力を要求されます。

Provide instance name

Oracle Application Access Controls Governorインストールの名前を入力します。例:

oaacg01

11. 作成したITリソース名の入力を要求されます。

OIM ITResource Instance Name:

作成したITリソース名OAACG ITR2を入力します。

12. 登録するSoDコンポーネント(システム・インスタンス)が他にない場合は、残りのプロンプトでnを入力します。そうでない場合は、SAPおよびGRCインスタンスに対して同様の手順に従います。この後で、Registration.xmlに追加したカスタム・システム・タイプ(たとえば、NEW)の入力を要求されます。

Register System Instance for type NEW? (y/n)

13. yを入力します。カスタム・タイプのインスタンス名の入力を次のように要求されます。

Provide instance name

14. インストールの名前を、new1のように入力します。追加したシステム・タイプがSoDエンジンである場合は、作成したITリソースの名前の入力を要求されます。

OIM ITResource Instance Name:

15. 作成したITリソース名ITR_NEWを入力します。

16. テキスト・エディタでSILConfig.xmlファイルを開き、Topologies要素の値を指定します。トポロジの値の詳細は、「システム・タイプ名の記録」を参照してください。
次のXMLブロックは、Topologies要素とその子要素を示しています。

注意:

ターゲット・システムとSoDエンジンの組合せが複数ある場合、Topologies要素内に複数のTopology要素を追加できます。

<Topologies>
<Topology>
<name>@topologyName</name>
<IdmId>@Idm RegistrationId</IdmId>
<SodId>@Sod RegistrationId</SodId>
<SDSId>@Sds RegistrationId</SDSId>
</Topology>
</Topologies>

Topologies要素の次の子要素の値を入力します。

- @topologyName: トポロジ名を入力します。

注意:

TopologyName ITリソース・パラメータの値として、Topology要素と同じ名前を設定します。

- @Idm RegistrationId: Oracle Identity Managerインストールの登録IDを入力します。

- @Sod RegistrationId: SoDエンジンの登録IDを入力します。

- @Sds RegistrationId: ターゲット・システムの登録IDを入力します。

関連項目:

Topologies要素の子要素の詳細は、「システム・タイプ名の記録」の手順2を参照してください。

17. SILConfig.xmlをエクスポートしてMDSに戻します。

例22-1に、登録スクリプトの実行例の出力を示します。ここでは、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。

例22-1 登録スクリプトの実行例

sh registration.sh
Enter data related to login to OIM Server
[Enter the admin username:]OIM_ADMINISTRATOR_LOGIN
[Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD
[Enter the service url:]t3://localhost:14000
Do you want to proceed with registration? (y/n)
y
Register System Instance for type OIM ?(y/n)
n
Register System Instance for type EBS ?(y/n)
n
Register System Instance for type OAACG ?(y/n)
n
Register System Instance for type SAP ?(y/n)
n
Register System Instance for type GRC ?(y/n)
n
Register System Instance for type NEW ?(y/n)
y
Provide instance name
new1
OIM ITResource Instance Name:
ITR_NEW

22.10.1.5.2 システム・タイプ名の記録

登録プロセスの最後に、システム・タイプ名がOracle Identity Managerデータベースで設定されます。これらの名前は、登録スクリプトを使用してデータベースから取得できます。取得したら、これらの名前をSILConfig.xmlファイルに入力する必要があります。

サービス・コンポーネント名を取得して記録するには、次の手順を実行します。

1. コマンド・ウィンドウで、次のディレクトリに移動します。
OIM_HOME/bin/

2. 次のコマンドのいずれかを実行します。
Microsoft Windowsの場合:

registration.bat printRegistrationIDs

UNIXの場合:

registration.sh printRegistrationIDs

このコマンドの出力例は、次のとおりです。

-----------------------------------------------
System Type     Instance Name  Registration ID
-----------------------------------------------
OIM                 oim                     1
EBS                 Ebs                     2
OAACG               oaacg                   3

3. これらのインスタンス名を参照のためにコピーします。

22.10.2 カスタムSoDエンジンの追加

注意:

この項で説明する手順は、Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合にのみ実行します。Oracle E-Business SuiteおよびSAP R3以外のターゲット・システムを使用する場合は、「カスタム・ターゲット・システムの使用」の手順も実行する必要があります。

SILプロバイダの作成を開始する前に、SoDエンジンをインストールする必要があります。

この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。

次に、SILプロバイダを作成する手順のサマリーを示します。

1. 「前提条件への対応」の項に示されている手順に従います。

2. SoDエンジンの情報を保持するためのITリソースを作成します。「SoDエンジンの情報を保持するためのITリソースの作成」を参照してください。

3. SILプロバイダ用インタフェースのJavaクラス実装を作成します。手順は、「プロバイダ用サービス・コンポーネントの実装」を参照してください。

4. サービス・コンポーネントをデプロイします。「サービス・コンポーネントのデプロイ」を参照してください。

5. 登録XMLファイルに、新規SoDエンジンのエントリを追加します。手順は、「新規SoDエンジン用登録XMLファイルの変更」を参照してください。

6. 新規SoDエンジンを登録します。手順は、「新規SILプロバイダの登録」を参照してください。

22.10.2.1 前提条件への対応

次の前提条件を満たしていることを確認します。

1. ターゲット・システムからSoDエンジンに権限データをロードします。この手順を実行するために、任意のETLユーティリティを使用できます。詳細は、SoDエンジンのベンダーのドキュメントを参照してください。

2. SoDエンジンで、ターゲット・システムからロードしたデータを使用して、ポリシー定義またはリスク定義を作成します。

3. ターゲット・システム用のOracle Identity Managerコネクタをデプロイします。詳細は、コネクタのドキュメントを参照してください。

22.10.2.2 SoDエンジンの情報を保持するためのITリソースの作成

SoDエンジンの情報を保持するには、ITリソースを作成する必要があります。

ITリソース・タイプ(まだ存在しない場合)およびITリソースの作成の詳細は、第4章「アプリケーション・インスタンスの開発」を参照してください。ITリソース・タイプおよびITリソースには任意の名前を指定できます。次の表は、ITリソースに含める必要のあるパラメータの名前を示しています。

パラメータ

説明

サンプル値

Source Datastore Name

SoDエンジンで定義したソース・データ・ストア(ターゲット・システム)の名前を入力します。

ソース・データ・ストア名は、「Oracle Application Access Controls Governorの構成」の項で説明されている手順の実行中に指定します。

EBS STMD122

dbuser

SoDエンジンで使用されるデータベース上のスキーマ所有者のユーザー名を入力します。

このアカウントは、SoD処理中にApplication Access Controls Governorデータベースへのアクセスに使用されます。

注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。

databaseusr1

dbpassword

SoDエンジンで使用されるデータベース上のスキーマ所有者のパスワードを入力します。

注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。

Cryp100ne

jdbcURL

SoDエンジンで使用されるデータベースに接続するためのJDBC URLを入力します。

注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。

jdbc:oracle:thin:@10.123.123.123

password

APIコール用にSoDエンジンで作成されたアカウントのパスワードを入力します。

K1rb1r0s

port

SoDエンジンがリスニングを行うポートの番号を入力します。

8090

server

SoDエンジンが稼働しているホスト・コンピュータのIPアドレスを入力します。

10.231.231.231

sslEnable

SoDエンジンでHTTPS通信リクエストのみを受け入れる場合、trueを入力します。それ以外の場合はfalseを入力します。

false

username

SoDエンジンで作成されたアカウントのユーザー名を入力します。このアカウントは、SoD検証中に使用されるSoDエンジンAPIのコールのために使用されます。

jdoe

sodServerURL

SoDサーバーのURLを次の形式で入力します。

http(s)://HOST_NAME:PORT_NUMBER/URL

http://10.231.231.231:8090/grcc/services/GrccService

注意:

複数のSoDエンジンを使用する場合は、同じITリソース・タイプで複数のITリソースを作成してください。

22.10.2.3 プロバイダ用サービス・コンポーネントの実装

次のサービス・コンポーネントのJava実装を作成します。

関連項目:

Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンス

- SoDAnalysisExecutionOper: SoD分析レイヤーを、デフォルトで提供されていないカスタムSoDエンジン用に実装する必要があります。

- IdMvsSoDDataTransformationOper: ターゲット・システムの属性値を、SoDエンジンで使用可能な値に変換するために使用されます。変換レイヤーは、すべての新規SoDエンジンまたはターゲット・システム・タイプに対して作成する必要があります。

- CallBackIdMOper(オプション): Oracle Identity Managerにアクセスするために、SoD分析レイヤーからのコールバックが必要な場合に実装されます。

- SoDDataValidationOper(オプション): SoD分析レイヤーで指定された属性に対して検証を提供するために実装されます。

22.10.2.4 サービス・コンポーネントのデプロイ

「プロバイダ用サービス・コンポーネントの実装」で作成されたサービス・コンポーネントは、次のようにデプロイされます。

1. サービス・コンポーネントの実装用に作成したJavaクラスのJARファイルを作成します。

2. UploadJarユーティリティを使用して、JARファイルをThirdPartyとしてアップロードします。

注意:

UploadJar.shまたはUploadJar.batユーティリティは、OIM_HOME/binにあります。この場所からユーティリティを実行して、作成したJARファイルをMDSにアップロードします。

22.10.2.5 新規SoDエンジン用登録XMLファイルの変更

Registration.xmlファイルで、次のようにして変換レイヤーの詳細を入力します。

1. MDSからRegistration.xmlファイルをインポートします。Registration.xmlファイルは、ネームスペース\metadata\iam-features-sil\db\Registration.xmlでMDS内に存在します。

2. テキスト・エディタでRegistration.xmlファイルを開きます。

3. SoDエンジン用のSystemType要素を次のように追加します。

<SystemType name="SYSTEM_TYPE_NAME" type="SYSTEM_TYPE" isSynch="IS_SYNCH">
<!-- The Parameters which are required to connect the Sod Engine. -->
<Parameter name="PARAM_NAME1" required="true" />
<Parameter name="PARAM_NAME2" required="true" />
...
</SystemType>

ここで、次のように値を置き換えます。

- SYSTEM_TYPE_NAMEをシステム・タイプ名で置き換えます。

- SYSTEM_TYPEをSoDエンジンで置き換えます。

- IS_SYNCHを、SoDエンジンが同期か非同期かに応じて、trueまたはfalseで置き換えます。

- PARAM_NAMEを、SoDエンジンに接続するために使用するパラメータ名で置き換えます。これらのパラメータ値は、SoDエンジンの登録中に指定する必要があります。これらは、SoDエンジンに接続するために、サービス・コンポーネント実装クラスで読み取られます。

4. 実装されたすべてのサービス・コンポーネントを次のように追加します。

<ServiceComponent type="SERVICECOMPONENT_TYPE" name="NAME_FOR_IMPLEMENTATION"
<Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class>
<IdMSystemType>SYSTEM_TYPE_NAME_FOR_IDM</IdMSystemType>
<SoDEngineType>SYSTEM_TYPE_NAME_FOR_SOD_ENGINE</SoDEngineType>
<srcSystemType>SYSTEM_TYPE_NAME_FOR_TARGET_SYSTEM</srcSystemType>

<!-- AttrSoD tag is only required for Sod Analysis Service Component-->
<AttrSoD type="user" isKey="true" name="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE">
<!-- "name" attribute of the "Validation" element should be same as the "name" of one of the registered "ServiceComponent" of type "SoDDataValidationOper" -->
<Validation name="NAME_FOR_VALIDATION_ON_ATTRIBUTE"/>
</AttrSoD>

<AttrSoD type="duty" isKey="true" dutyType="ENTITLEMENT_TYPE" name="NAME_OF_ENTITLEMENT_ON_SOD_ENGINE"><Validation name="isNotNullOAACG"/>
</AttrSoD>

<AttrSoD...>
...
</AttrSoD>

<!-- DataTransformation tag is only required for transformation Service component-->
<DataTransformation>
<AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM"  sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/>
<AttrSoD type="user" name="firstname"  sourceIdMAttrName="firstname" isSourceKey="false"/>
<AttrSoD type="user" name="lastname"  sourceIdMAttrName="lastname" isSourceKey="false"/>
<AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE"  name="accessorigid"  sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/>
</DataTransformation>

</ServiceComponent>

ここで、次のように値を置き換えます。

- SERVICECOMPONENT_TYPE: サービス・コンポーネントのタイプに応じて、CallBackIdMOper、SoDAnalysisExecutionOper、SoDDataValidationOperまたはIdMvsSoDDataTransformationOperなどの値を指定できます。

- NAME_FOR_IMPLEMENTATION: サービス・コンポーネントの名前をDBToOAACGのように指定します。

- NAME_OF_IPMLEMENTATION_CLASS: 「変換レイヤーの作成」の手順に従って作成したクラスに設定した名前を指定します。たとえば、oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACGのように指定します。

- SOD_ENGINE: SoDエンジンとしてOracle Application Access Controls Governorを使用する場合は、OAACGを入力します。SoDエンジンとしてSAP GRCを使用する場合は、GRCを入力します。カスタムSILプロバイダを使用する場合は、そのSoDエンジンに設定した名前を入力します。

関連項目:

「カスタムSoDエンジンの追加」

- SYSTEM_TYPE_NAME: 先に入力したシステム・タイプ名を指定します。

- NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: ターゲット・システムの属性の名前を指定します。

- NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: SoDエンジンの対応する属性の名前を指定します。

- ENTITLEMENT_TYPE: 権限のタイプを、ROLEのように入力します。

- ENTITLEMENT_NAME: 権限の1つのインスタンスの名前を、Resource Managerのように入力します。

5. Registration.xmlファイルを保存して閉じます。

6. Registration.xmlファイルをエクスポートしてMDSに戻します。

22.10.2.6 新規SILプロバイダの登録

新規SILプロバイダを登録するには、次の各項で説明されている手順を実行します。

1. 登録スクリプトの再実行の詳細は、「登録スクリプトの実行と登録情報の指定」を参照してください。スクリプトのここでの実行では、登録済のサービス・コンポーネントの値を入力しないでください。

2. SILConfig.xmlファイルでの新規ターゲット・システムに関するデータの入力の詳細は、「システム・タイプ名の記録」を参照してください。

22.11 Oracle Identity AnalyticsによるロールSoDチェックの実行

ロールSoDチェックは、ユーザーにロールを割り当てるリクエストまたはユーザーからロールを削除するリクエストが要求された場合に実行されます。Oracle Identity AnalyticsによるロールSoDチェックは、リクエストが要求された場合にのみ実行され、ロールが直接割り当てられた場合または削除された場合は実行されません。

- ロールSoDチェックの有効化

- ロールSoDチェックの使用

注意:

Oracle Identity AnalyticsによるSoDチェックを実行するには、Oracle Identity ManagerとOracle Identity Analyticsが統合されていることが前提条件です。

22.11.1 ロールSoDチェックの有効化

Oracle Identity AnalyticsによるロールSoDチェックを有効化するには、次の手順を実行する必要があります。

1. XL.SoDCheckSystemPropertyシステム・プロパティの値をTRUEに設定します。システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。

2. RoleSoDCheckTopologyNameシステム・プロパティの値をsodoiaに設定します。このトポロジは事前定義され、登録されています。

3. OIA-ITRes ITリソースでOIA接続の詳細を、次の図に示すように設定します。

22.11.2 ロールSoDチェックの使用

次の各項では、ロールSoD機能を実装する方法について説明します。

- ユーザーがロールをリクエストする場合のSoDチェック

- ユーザーがロールを削除する場合のSoDチェック

- 管理者がロールの割当てをリクエストする場合のSoDチェック

- 管理者がロールの削除をリクエストする場合のSoDチェック

22.11.2.1 ユーザーがロールをリクエストする場合のSoDチェック

次の手順は、ユーザーがロールに対するリクエストを要求した場合に実行されます。SoDチェックは、有効化されている場合に実行されます。この手順の例では、ユーザーにRole3がすでに割り当てられていることを前提としています。

次のステップを実行します。

1. ユーザーとしてOracle Identity Self Serviceにログインします。

2. 「プロファイル」の下で、「マイ・アクセス」をクリックします。「ロール」タブをクリックしてから、「ロールのリクエスト」をクリックします。リクエストするロールを検索できる「カタログ」ページが表示されます。

3. ebsRole1など、ユーザーに割り当てる特定のロールを検索します。

4. 「カートに追加」をクリックします。これによって、カートに1つの項目が表示されます。次に、「チェックアウト」をクリックします。

5. 「送信」をクリックして、ロールのリクエストを送信します。リクエストが作成されます。

6. 「リクエスト」→「リクエストのトラッキング」に移動します。

7. 作成したリクエストを検索します。次の図に示すように、リクエストを開いてSoDチェック結果を確認します。

8. 次の図に示すように、「SODステータス」をクリックしてSoDチェック結果を確認します。

SoDチェック結果が「失敗」となっているのは、リクエストを要求したebsRole1ロールと、ユーザーがすでに所有するRole3が競合しているためです。

SoDチェック結果は、リクエスト・レベル承認の前に使用できます。この場合、SoDチェックに失敗しましたが、管理者は競合するロールをユーザーに割り当てるリクエストを承認できます。

22.11.2.2 ユーザーがロールを削除する場合のSoDチェック

この手順では、削除されるロールがユーザーにすでに割り当てられていることを前提としています。

次のステップを実行します。

1. ユーザーとしてOracle Identity Self Serviceにログインします。

2. 「プロファイル」→「マイ・アクセス」に移動し、「ロール」タブをクリックします。ユーザーに割り当てたロールが表示されます。

3. 削除するロールを選択して、「ロールの削除」をクリックします。「ロールの削除」ページが表示され、選択したロールがカート項目として表示されます。

4. 「送信」をクリックします。リクエストが作成されます。
次の図に示すように、リクエストの詳細を開いてSoDチェック結果を確認できます。

競合するロールが削除されたため、SoDチェック結果が「成功」になりました。

22.11.2.3 管理者がロールの割当てをリクエストする場合のSoDチェック

この手順により、システム管理者はユーザーにロールを割り当てることができます。

1. システム管理者としてOracle Identity Self Serviceにログインします。

2. 「管理」→「ユーザー」に移動し、選択したユーザーの詳細を開きます。

3. 「ロール」タブをクリックしてから、「ロールのリクエスト」をクリックします。「カタログ」ページが表示されます。

4. ebsRole1ロールおよびRole3ロールを検索して、カートに追加します。「チェックアウト」をクリックします。次の図に示すように、カートの詳細が表示されます。

5. 「送信」をクリックします。リクエストが作成されます。これはバルク・リクエストのため、これに対するSoDチェックは開始されません。

6. Oracle Identity Self Serviceにシステム管理者としてログインし、「リクエスト」→「保留中の承認」に移動し、リクエストを承認します。2つの子リクエストが作成され、それぞれの子リクエストに対してSoDチェックが実行されます。

7. 「リクエストのトラッキング」に移動し、それぞれの子リクエストを開いてSoDの詳細を確認します。次の図は、ebsRole1ロールに対して作成されたリクエストのSoDの詳細を示しています。

次の図は、Role3ロールに対して作成されたリクエストのSoDの詳細を示しています。

22.11.2.4 管理者がロールの削除をリクエストする場合のSoDチェック

この手順により、システム管理者はユーザーからロールを削除できます。

1. システム管理者としてOracle Identity Self Serviceにログインします。

2. 「管理」→「ユーザー」に移動し、選択したユーザーの詳細を開きます。

3. 「ロール」タブをクリックして、削除するロールを選択し、「ロールの削除」をクリックします。

注意:

複数のロールを削除するためにリクエストが作成されます。単一のロールの場合はリクエストが作成されないため、SoDチェックは実行されません。

4. 「ロールの削除」ページで、「送信」をクリックします。リクエストが作成されます。

5. リクエストを承認します。2つのリクエストが作成され、それぞれのリクエストに対してSoDチェックが実行されます。次の図は、ebsRole1ロールに対して作成されたリクエストのSoDチェック結果を示しています。

次の図は、Role3ロールに対して作成されたリクエストのSoDチェック結果を示しています。

システム管理者によってリクエストが要求され、SoDの競合もないため、両方の子リクエストがデフォルトで承認されます。

注意:

デフォルトでは、競合が検出されたためにSoDチェック結果が「失敗」となった場合にのみ、システム管理者が要求したリクエストに対して操作レベル承認がトリガーされます。

22.12 プロビジョニング・ワークフローでのSoDの使用

この項では、SoDに関連する様々なユースケースについて説明します。

注意:

この項の手順は、OAACGなどの同期SoDエンジン用であり、同期SoDエンジンでSoDチェックを完了するには、スケジュール済ジョブを実行する必要はありません。

- アプリケーション・インスタンスと子データのプロビジョニング

- アプリケーション・インスタンスの変更による子データの追加または削除

- ユーザーへの権限のプロビジョニング

- ユーザーの権限の失効

- ロールおよび権限のリクエスト

- ロールおよびアプリケーション・インスタンスと子データのリクエスト

- DefaultSODApprovalワークフローによるリクエスト・プロビジョニング

- アクセス・ポリシーがアタッチされたロールのリクエスト

- 承認なしのアクセス・ポリシーに基づくプロビジョニング

- 承認ありのアクセス・ポリシーに基づくプロビジョニング

- 2つのアプリケーション・インスタンスからの権限のリクエスト

22.12.1 アプリケーション・インスタンスと子データのプロビジョニング

システム管理者としてアプリケーション・インスタンスをプロビジョニングするには、次の手順を実行します。

1. ターゲット・システムにアカウントを作成するユーザーを作成します。

2. 「ユーザーの詳細」ページで「アカウント」タブをクリックし、「アカウントのリクエスト」をクリックします。「カタログ」ページが表示されます。

3. EBSなど、アプリケーション・インスタンスを検索します。

4. アプリケーション・インスタンスをカートに追加し、チェックアウトします。
アプリケーション・インスタンスに追加されたフォームが、「カート詳細」ページに表示されます。このフォームには、デフォルトのSoDチェック・フィールド(SoDCheckStatus、SoDCheckTrackingID、SoDCheckResult、SoDCheckTimestamp、SoDCheckEntitlementViolationなど)が含まれます。これらのフィールドには、SoDチェックの値が移入されます。

5. フォームで必要な詳細を指定します。子フォームに権限を入力したことを確認します。入力されていない場合、SoDは競合する権限をチェックするためにのみ必要なため、SoDチェックは実行されません。

6. 「送信準備ができています」をクリックして、リクエストを送信します。これは単一のアプリケーション・インスタンスの単一のユーザーに対するリクエストのため、リクエストは作成されず、アプリケーション・インスタンスはユーザーに直接割り当てられます。
同期SoDチェックが行われたため、「アカウントの詳細」ページでSoDチェック結果を確認できます。競合する権限を選択した場合、SoDチェックは失敗し、ターゲット・システムで権限はプロビジョニングされません。図22-17は、SoDチェック結果を示しています。

図22-17 競合する権限

リソース履歴を開くと、Holderタスクが「取消」の状態で表示されますが、これはSoDチェックの結果、競合があったためです。また、SoDCheckerタスクは「完了」の状態ですが、これはSoDチェックが完了したことを示します。図22-18は、リソース・プロビジョニングの詳細を示しています。

図22-18 リソース・プロビジョニングの詳細

アプリケーション・インスタンスをプロビジョニングする手順がビューア管理ロールを持つユーザーによって実行された場合は、リクエストが作成されます。SoDチェック結果がこのリクエストに表示されます。承認者には、SoDチェック結果を確認した後にリクエストを承認または却下する権限があります。図22-19は、リクエストの詳細内のSoDチェック結果を示しています。

図22-19 リクエストの詳細内のSoDチェック結果

22.12.2 アプリケーション・インスタンスの変更による子データの追加または削除

ユーザーの詳細を開いてプロビジョニング済のアカウントを選択し、子フォームで権限の追加、更新または削除を行うことによってこのアカウントを変更しようとすると、常にSoDチェックがトリガーされます。この操作がシステム管理者によって実行された場合は、新しいHolderタスクとSoDCheckerタスクが生成されます。新しい権限が古い権限と競合する場合、新しい権限はプロビジョニングされません。そうでない場合は、新しい権限がターゲット・システムでプロビジョニングされます。

ビュー管理ロールを持つユーザーによって操作が実行された場合、アプリケーション・インスタンスを変更するための新しいリクエストが作成されます。SoDチェック結果がこのリクエストに表示されます。

22.12.3 ユーザーへの権限のプロビジョニング

権限は、Oracle Identity Managerの第1レベルのエンティティです。そのため、権限は次のように直接リクエストできます。

- システム管理者がユーザーの単一の権限をリクエストする場合: SoDチェックが実行され、権限が既存の権限と競合しない場合は、ユーザーにその権限が付与されます。SoDチェック結果は、「アカウントの詳細」ページに表示されます。SoDチェックを実行するためにHolderタスクとSoDCheckerタスクが作成されます。

- システム管理者が複数の権限をリクエストする場合: バルク操作に対して、リクエストが作成されます。そのため、システム管理者が2つの権限をリクエストした場合は、リクエストr1が作成されます。SoDチェックは常に子リクエスト・レベルで実行されるため、r1に対してSoDチェックは実行されません。r1に対してリクエスト・レベル承認が取得された後、2つの子リクエストr2およびr3が作成されます。両方の子リクエストに対してSoDチェックが実行されます。結果は、「リクエストの詳細」に表示されます。

- ユーザーが単一の権限をリクエストする場合: この場合、ユーザーは権限を直接取得できないため、リクエストが作成されます。承認者がこれを承認する必要があります。リクエストに対してSoDチェックが実行されます。HolderタスクおよびSODCheckerタスクは作成されません。

22.12.4 ユーザーの権限の失効

権限の失効のユースケースは、「ユーザーへの権限のプロビジョニング」で説明されている権限のプロビジョニングと同様です。ユーザーから最後の権限が失効されると、ユーザーに権限がないため、SoDチェックは実行されません。

22.12.5 ロールおよび権限のリクエスト

Oracle Identity Managerでは、権限とともにロールをリクエストできる異種リクエストがサポートされています。これを行うには、「カタログ」ページを開いて必要なエンティティを検索し、エンティティを選択して送信します。これによってリクエストが作成されます。このリクエストが承認されると、リクエストされたエンティティに対して子リクエストが作成されます。それぞれの子リクエストに対してSoDチェックが実行されます。ロールおよび権限が、個別のSoDチェック用に送信されます。

注意:

SoDチェックの競合は、ロールとターゲット・システムの権限間では検出されません。この2つに対してリクエストが要求された場合は、個別のSoDチェックが実行されます。

22.12.6 ロールおよびアプリケーション・インスタンスと子データのリクエスト

これは、「ロールおよび権限のリクエスト」で説明されているロールおよび権限のリクエストに類似しています。アプリケーション・インスタンスとロールに対して個別のSoDチェックが実行されます。

22.12.7 DefaultSODApprovalワークフローによるリクエスト・プロビジョニング

承認ポリシーを使用してDefaultSODApprovalワークフローが指定されている場合は、リクエスト・プロビジョニングのための次の手順を実行します。

1. 操作レベルでDefaultSODApprovalワークフローを指定します。つまり、承認の操作レベルより前の手順は同じままです。

2. DefaultSODApprovalワークフローによって、リクエストが承認の操作レベルに送られると、承認タスクがシステム管理者ロールに割り当てられます。管理者がこのタスクを承認すると、SoDチェックWebサービスがロードされ、SoDチェックが開始されます。
これは、リクエスト・ステータス(「SoDチェックが完了しました」である必要があります)をチェックすることにより確認できます。

3. システム管理者に再度割り当てられる承認タスクが生成されます。

4. タスクを承認する前に、リクエストの詳細でSoDチェックの結果を確認してください。タスクが承認されている場合、アカウント、権限またはその両方のプロビジョニングが続けられます。

このユースケースでは、SoDチェックは2回実行されます。1回目はあらゆるレベルの承認の前に行われるデフォルトのSoDチェックであり、2回目のSoDチェックはDefaultSODApprovalワークフローにより開始されます。

22.12.8 アクセス・ポリシーがアタッチされたロールのリクエスト

ユーザーがロールをリクエストし、これが複数のロールに対するリクエストである場合は、ロールに対してSoDチェックが最初に実行されます。リクエストが承認されてユーザーにロールが割り当てられた後、ユーザー・ポリシーの評価スケジュール・ジョブを実行してアクセス・ポリシーを評価します。その後、アカウントのプロビジョニングがトリガーされます。これによって、再度、プロビジョニングされているアカウントに対するSoDチェックが実行されます(子データがリクエストされた場合)。SoDチェック結果は、「アカウントの詳細」ページに表示されます。アカウントが子データなしでプロビジョニングされる場合、SoDチェックは実行されません。

注意:

ユーザー・ポリシーの評価スケジュール・ジョブの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の事前定義済のスケジュール済タスクに関する説明を参照してください。

22.12.9 承認なしのアクセス・ポリシーに基づくプロビジョニング

アクセス・ポリシーに基づくプロビジョニングを行うには、次の手順を実行します。

1. 新規ロールを作成します。

2. アクセス・ポリシー(承認なし)を作成し、新規ロールに対してSoD対応リソースをプロビジョニングします。子フォームに権限を入力したことを確認します。

3. 新しく作成したユーザーにこのロールを割り当てます。ユーザー・ポリシーの評価スケジュール済ジョブを実行してアクセス・ポリシーをトリガーし、ターゲット・システムでアカウントをプロビジョニングします。ただし、権限のプロビジョニングはSoDチェック後に行われます。

4. 「アカウントの詳細」をチェックしてSoDCheckStatusフィールド値を確認します。SoDチェックが正常に完了した場合、SoDCheckStatusフィールドの値は「SoDチェックが完了しました」となり、SoDCheckerタスクは「完了」の状態になります。
Holderタスクのステータスは、SoDチェック結果によって異なります。SoDチェックに成功すると、Holderタスクが完了し、権限がプロビジョニングされます。そうでない場合は、Holderタスクが取り消され、権限はプロビジョニングされません。

22.12.10 承認ありのアクセス・ポリシーに基づくプロビジョニング

アクセス・ポリシーが承認とともに作成されると、アカウントのプロビジョニングのリクエストが作成されます。ユーザーにロールが割り当てられ、ユーザー・ポリシーの評価スケジュール・ジョブが実行された後、ユーザーに対してアカウントをプロビジョニングするためのリクエストが作成されます。このリクエストに対してSoDチェックが実行されます。

22.12.11 2つのアプリケーション・インスタンスからの権限のリクエスト

異なるアプリケーション・インスタンスからの2つの権限(Sodチェックが有効化されている権限およびSodチェックが有効化されていない権限)に対してリクエストを要求できます。この場合、SoDチェックが有効化されている権限に対してSoDチェックが実行されます。

注意:

異なるアプリケーション・インスタンスからの権限間でのSoDチェックはサポートされていません。たとえば、EBS権限とPSFT権限間でのSoDチェックはサポートされません。

22.13 SoD関連イベントのロギングの有効化

すべてのSoD関連イベントのロギングを有効にするには、次の手順を実行します。

1. テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/oim_server1/logging.xmlファイルを開きます。

2. <loggers>要素を見つけます。次にサンプルの<loggers>要素を示します。

<loggers>
<logger name="" level="WARNING:1">
<handler name="odl-handler"/>
<handler name="wls-domain"/>
<handler name="console-handler"/>
</logger>

ロギング・レベルを、INCIDENT_ERROR:1、ERROR:1、NOTIFICATION:1、NOTIFICATION:16、TRACE:1、TRACE:16またはTRACE:32に変更できます。デフォルト・ロギング・レベルでは、エラーおよび警告メッセージが出力されます。

22.14 SoDチェックのトラブルシューティング

表22-2に、SoDチェックの実行中にエラーが発生した場合に実行できるトラブルシューティング手順を示します。

表22-2 SoDチェックのトラブルシューティング

問題

解決策

プロセス・フォームのSoDCheckStatusフィールドに値が表示されないか、デフォルト値が表示されます。EBSコネクタのフィールドでは、「SoDチェックが開始されていません」がデフォルト値です。また、SoDCheckResultフィールドに値が移入されません。

これは、SoD構成が正しくないことを意味します。「職務の分離(SOD)チェックは必須です」システム・プロパティがtrueに設定されているかどうかを確認します。設定されている場合は、コネクタITリソース・フィールドでtopologyNameの値を確認します。

デフォルトの登録が使用されている場合、topologyNameパラメータの値はsodoaacg (OAACG SoDエンジンの場合)およびsodgrc (SAP GRCの場合)です。登録が手動で行われている場合は、対応するトポロジがSILConfig.xmlファイルで定義されており、このファイルが変更後にMDSにシードされているかどうかを確認してください。

プロセス・フォームまたはリクエスト・データセットのSoDCheckStatusフィールドに「SoDチェックがエラーで完了しました」と表示されます。

SoDCheckResultフィールドには「SoDエンジンのエラー」と表示されます。

SoD構成は正しいがSoDエンジンの接続情報が正しくない可能性があるか、SoDエンジンでエラーが発生しました。SoDエンジンのエラーは、次のような理由により発生することがあります。

- SoDエンジンまたは対応するデータベースがダウンしています。

- SoDエンジンが、ターゲット・システムと完全に同期していません。そのため、SoDチェックが行われる特定の権限がSoDエンジンに存在しない可能性があります。

SoDエンジン・ログで、その他のエラーがないかを確認します。SoDエンジンによりトラッキングIDが返されない場合、シミュレーションは正常に開始されていません。

プロセス・フォームのSoDCheckStatusフィールドがSoDの結果が保留中ですステータスになっており、スケジュール済ジョブを実行しても「SoDチェックが完了しました」ステータスになりません。

承認用のスケジュール済ジョブではなく、SoDチェック結果の取得(プロビジョニング)スケジュール済ジョブを実行していることを確認します。スケジュール済ジョブがトリガーされていることを確認します。デバッグ・レベルのロギングを有効化して、これを確認できます。

スケジュール済ジョブが実行されてもSoDチェックが完了しない場合は、SoDエンジンでエラーが発生しています。SoDエンジン・ログで詳細を確認してください。

SoD対応リソースをリクエストする際、リクエストを作成してもデータセットにSoDフィールドが表示されず、リクエストはリクエスト・レベル承認に直接送られます。

このエラーは、SoD構成が正しくないことを意味します。「職務の分離(SOD)チェックは必須です」システム・プロパティがtrueに設定されているかどうかを確認します。設定されている場合は、コネクタITリソース・フィールドでtopologyNameの値を確認します。

デフォルトの登録が使用されている場合、topologyNameパラメータの値はsodoaacg (OAACG SoDエンジンの場合)およびsodgrc (SAP GRCの場合)です。

登録が手動で行われている場合は、対応するトポロジがSILConfig.xmlファイルで定義されており、このファイルが変更後にMDSにシードされているかどうかを確認してください。

リクエスト・データセットのSoDCheckStatusフィールドがSoDの結果が保留中ですステータスになっており、スケジュール済ジョブを実行しても「SoDチェックが完了しました」ステータスになりません。

承認用のスケジュール済ジョブではなく、SoDチェック結果の取得(承認)スケジュール済ジョブを実行していることを確認します。スケジュール済ジョブがトリガーされていることを確認します。デバッグ・レベルのロギングを有効化して、これを確認できます。

スケジュール済ジョブが実行されてもSoDチェックが完了しない場合は、SoDエンジンでエラーが発生しています。SoDエンジン・ログで詳細を確認してください。

リクエスト・プロビジョニング中にSoDチェックが正常に実行されましたが、ユーザー・プロファイルのリソース状態に「プロビジョニング済」と表示されません。そのため、リクエストが「操作が開始されました」ステータスになっています。

リソース履歴でプロセス・タスクを確認します。System Validationタスクのみが表示されている場合、必要なデータがこのフォームに保存されていない可能性があります。編集モードでフォームを開き、「保存」をクリックすると、手動でフォームを保存できる場合があります。以降のリクエストのために、プロセス定義で自動保存オプションを有効化してください。

ターゲット・システムでアカウントを作成するためのタスクなど、その他のタスクがリソース履歴に表示されている場合は、タスクの詳細をチェックして、ターゲット・システムのエラーがないかどうかを確認してください。たとえば、作成中のアカウントがターゲット・システムにすでに存在しています。

ダイレクト・プロビジョニング中にSoDチェックが正常に実行されましたが、ユーザー・プロファイルのリソース状態が「プロビジョニング済」ではありません。

リソース履歴でプロセス・タスクを確認します。System Validationタスクのみが表示されている場合、必要なデータがこのフォームに保存されていない可能性があります。これは、プロセス定義で自動保存オプションがオンになっている場合に発生することがあり、そのため、ダイレクト・プロビジョニング中にフォームが表示されません。編集モードでフォームを開き、「保存」をクリックすると、手動でフォームを保存できる場合があります。以降のリクエストのために、プロセス定義で自動保存オプションを無効化してください。

ターゲット・システムでアカウントを作成するためのタスクなど、その他のタスクがリソース履歴に表示されている場合は、タスクの詳細をチェックして、ターゲット・システムのエラーがないかどうかを確認してください。たとえば、作成中のアカウントがターゲット・システムにすでに存在しています。

リクエスト・プロビジョニングは正常に実行され、リクエスト・データセットに該当する値が表示されましたが、SoDステータスと結果がプロセス・フォームに反映されません。

プロセス・フォームでSoDフィールド・ラベルを確認してください。これらは、SoDCheckStatus、SoDCheckTrackingID、SoDCheckResult、SoDCheckTimestampおよびSoDCheckEntitlementViolationである必要があります。これらのフィールド・ラベルを変更すると、SoDフィールドがリクエスト・データセットからプロセス・フォームにマップされません。

特定のSoDリクエストが複数回試行され、エラーが生成されます。

SoD構成に問題があるか、特定のリクエストで発行されたデータにエラーがある可能性があります。SoD構成が正しいにもかかわらず、リクエストにエラーのトレースがあり、その特定のリクエストを無視するには、WebLogic管理コンソールからOIMSODQueueの「再配信の制限」を変更して、そのリクエストに関連するJMSメッセージが複数回試行されないようにできます。これを行うには、次の手順を実行します。

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「メッセージング」→「JMSモジュール」→「OIMJMSModule」の順に移動します。すべてのキューのリストが表示されます。

3. 「oimSODQueue」をクリックし、「配信の失敗」をクリックします。

4. 「再配信の制限」の値を、-1から正の値に変更します。これにより、SoD JMSメッセージの再試行回数が決定されます。

タスク割当てルールの評価にエラーがあります。ユーザーnullのタスク割当てルールの評価にエラーがあります。エラーは次のとおりです。「構成"{1}"の"{0}"の所有者を取得中のエラー。構成"jazn.com"の"SOD ADMINISTRATORS"の所有者を取得中にエラーが発生しました。グループ名が有効であり、所有者が関連付けられていることを確認してください。エラーを修正できない場合は、Oracleサポートに連絡してください。ユーザーnullに指定されたルールが有効であることを確認してください。」

このエラーは無視してください。このエラーの原因は、OIMDBProviderではロールの所有者の取得がサポートされていないことです。そのため、SOAではこのエラーがログに記録されます。

DefaultSODApprovalワークフローを使用してSoDチェックを実行しようとすると、次のエラー・メッセージが表示されます。

Unknown Credential type to find the password for the given map : oim key : sodcheck.credentials

「SoDの有効化」の手順5の説明に従って、sodcheck.credentialsを追加してください。

次のエラーが表示されます。

[exec] Caused By: Thor.API.Exceptions.tcITResourceNotFoundException
[exec] at com.thortech.xl.ejb.beansimpl.tcITResourceInstanceOperationsBean.getITResourceInstanceParametersData

SoDエンジンITリソースが作成されていません。そのため、使用するSoDエンジンに応じたITリソースを作成する必要があります。たとえば、OAACGの場合はOAACG-ITResを作成します。

OAACGとOIAなど、複数のSoDエンジンに対してSoDが有効化されている場合に、OIAを使用してSoDチェックを開始しようとすると、OAACGファイルからエラーがログに記録されることがあります。

この問題は、SILConfig.xmlファイル内のトポロジ・エントリが正しくない場合に発生します。これらのエントリを確認するには、MDSからSILConfig.xmlファイルをエクスポートします。デフォルト・プロバイダの場合、SILConfig.xmlファイルにはトポロジ名に対応するSIL登録IDが含まれています。SILConfig.xmlのIDと、SIL登録スクリプトから返されるIDは同じである必要があります。たとえば、SILConfig.xmlに含まれるsodoiaトポロジのIDは次のようになります。

<IdmId>1</IdmId>
<SodId>7</SodId>
<SDSId>6</SDSId>

この場合、登録スクリプトにより返されるIDは次のようになります。

1 oimInstance
6 oimSDSInstance
7 oiaInstance

これらが異なる場合、SILConfig.xmlファイルでIDを変更し、MDSユーティリティを使用してファイルを再インポートしてください。

第V部

データ同期

この部は、リコンシリエーションのカスタマイズおよびLDAPコンテナとスケジュール済タスクの開発について説明する各章で構成されています。

次の章で構成されます。

- 第23章「リコンシリエーションのカスタマイズ」

- 第24章「バルク・ロード・ユーティリティの使用」

- 第25章「LDAPコンテナ・ルールの構成」

- 第26章「スケジュール済タスクの開発」

23 リコンシリエーションのカスタマイズ

この章では、リコンシリエーションの機能およびアーキテクチャと、リコンシリエーション操作のカスタマイズの様々な側面について、次の各項で説明します。

- リコンシリエーションの機能

- リコンシリエーションのアーキテクチャ

- リコンシリエーション・ルールの定義

- リコンシリエーションのスケジュール済タスクの開発

- リコンシリエーション・プロファイルの手動による更新

- リコンシリエーションAPIの理解

- 信頼できるリコンシリエーションの後処理

- リコンシリエーションのトラブルシューティング

- RECON_EXCEPTIONS表へのデータ移入

- リコンシリエーションのベスト・プラクティス

- DMSを使用したリコンシリエーション・パフォーマンスの監視

23.1 リコンシリエーションの機能

リコンシリエーション機能は、次のカテゴリに分類できます。

- パフォーマンス強化の機能

- Webベースのイベント管理インタフェース

- その他の機能

23.1.1 パフォーマンス強化の機能

次の機能は、リコンシリエーション時のパフォーマンスの向上に役立ちます。

- 新しいメタデータ・モデル - プロファイル

- 制御フローとイベントの処理のパラメータ

- リコンシリエーション実行によるイベントのグループ化

- バッチによるイベントのグループ化

- リコンシリエーション・エンジン・ロジックのデータベースでの実装

- 改善されたJavaエンジン

- 改善されたデータベース・スキーマ

23.1.1.1 新しいメタデータ・モデル - プロファイル

メタデータがリコンシリエーション・ターゲットに関連付けられていると、同じターゲットに対して複数のジョブを実行して様々なタイプのリコンシリエーションを行う機能が制限されます。そのため、Oracle Identity Managerの各種コンポーネントのすべての構成は、MDSと呼ばれるXMLストアに集中的に格納されています。

下位互換性のために、現在のデプロイメントは、Oracle Identity Manager Design Consoleを介して継続して構成を管理し、構成は引き続きOracle Identity Managerデータベースに格納されます。Oracle Identity Managerでは、構成APIは構成を表から自動的に読み取り、それをデフォルト・プロファイルと呼ばれるXMLプロファイルに変換し、そのプロファイルを既存のリコンシリエーションの実行に関連付けます。

すべてのメタデータは、Oracle Identity Manager Design Consoleを使用して管理されます。Oracle Identity Manager Design Consoleを使用して、デフォルトのリコンシリエーション・プロファイルを生成できます。Oracle Identity Manager Design Consoleからリコンシリエーション構成を変更する場合は、このデフォルトのプロファイルを使用してプロファイルを再生成できます。デプロイメント・マネージャから構成をインポートする場合は、デフォルトでプロファイルが生成されます。

デフォルト以外のすべてのプロファイルは、任意のXMLエディタを使用してすべて管理できます。

関連項目:

リコンシリエーション・プロファイルの詳細は、「リコンシリエーション・プロファイル」を参照してください。

23.1.1.2制御フローとイベントの処理のパラメータ

この項の内容は次のとおりです。

- 制御イベント処理のパラメータ

- 自動再試行を制御するシステム・プロパティ

制御イベント処理のパラメータ

BatchSizeは、イベント処理を制御するパラメータです。これはバッチのサイズを決定します。バッチ・サイズが1の場合、一度に1つのイベントが処理されます。バッチ・サイズはシステム・プロパティとして利用でき、Oracle Identity Manager Design Consoleから管理できます。そのプロパティ名は、OIM.ReconBatchSizeです。システムのBatchSizeパラメータのデフォルト値は500です。システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する説明を参照してください。

自動再試行を制御するシステム・プロパティ

「リコンシリエーション・イベントの再試行回数」システム・プロパティは、リコンシリエーション・エンジンがエラーとしてフラグを付けるか手動キューに送信する前に項目を再試行する回数を指定して、自動再試行を制御します。このプロパティの値が0の場合は、自動再試行オプションが構成されていないことを意味します。

関連項目:

自動再試行の詳細は、「競合状態の処理」を参照してください。

23.1.1.3 リコンシリエーション実行によるイベントのグループ化

リコンシリエーション・データベースで作成されるすべてのイベントは、リコンシリエーション実行によってグループ化されます。リコンシリエーション実行のすべてのイベントは、共通のリコンシリエーション実行IDによってグループ化されます。各リコンシリエーション実行はプロファイルと関連付けられているため、リコンシリエーション実行のすべてのイベントは、同じプロファイルを使用して処理されます。これにより、構成はリコンシリエーション実行ごとに一度のみ取得されるため、パフォーマンスの最適化に役立ちます。

各プロファイルはそれぞれ異なるバッチ・サイズを使用できます。そのため、各ターゲット・リコンシリエーションに適したバッチ・サイズに調整することで、システム・パフォーマンスを向上させることができます。

23.1.1.4 バッチによるイベントのグループ化

バッチは、リコンシリエーション時のシステム・パフォーマンスを向上させるために導入されました。バッチには多数のイベントが含まれます。これはリコンシリエーション・エンジンの処理の単位です。バッチのサイズは設定可能です。リコンシリエーション実行は、固定サイズのバッチに分割されます。たとえば、リコンシリエーション実行が9900のイベントで構成され、バッチ・サイズが1000の場合、そのリコンシリエーション実行は、各サイズ1000のバッチと最後のサイズ900のバッチの計10個のバッチに分割されます。

バッチを1つの単位として処理すると、一度に1つのイベントを処理する際のオーバーヘッドを排除でき、システム・パフォーマンスが最適化されます。またこれにより、可能な場合にはバルク操作も実行できます。バッチを並列で実行して、ハードウェア・リソースをバランスよく使用することもできます。

23.1.1.5 リコンシリエーション・エンジン・ロジックのデータベースでの実装

以前のリリースでは、すべてのエンジン・ロジックはJavaで実装されており、一度に1つのイベントが処理されていました。11gリリース2 (11.1.2.1.0)では、イベントを処理するロジックのほとんどは、ストアド・プロシージャとして実装されています。バッチ・レベルでの処理とPLSQLで実装されたロジックの組合せにより、SQLレイヤーでバルク操作を実行できるようになりました。次の手順は、バルク(一度に1つのバッチ)で実行されます。

- 必要なデータのチェック

- 一致ルールの適用

- アクション・ルールの適用

23.1.1.6 改善されたJavaエンジン

ストアド・プロシージャで実行できず、Javaレイヤーで実行する必要のある処理でも、次の理由により、以前のリリースのエンジンよりも優れたパフォーマンスが得られます。

- 次の場合、Javaエンジンはデフォルトでバルク操作を実行します。

- イベントをバッチでデータベースに送信

- アクションに応じたバルク後処理編成の送信

- 可能なかぎり、バルク操作を実行します。

23.1.1.7 改善されたデータベース・スキーマ

11gリリース2 (11.1.2.1.0)の新しいデータベース・スキーマによる顕著なパフォーマンスの向上は、単一の垂直表のかわりに水平表を使用して各種ターゲットのイベント詳細を格納することで実現されます。水平表はプロファイルごとに使用されます。

関連項目:

水平表の詳細は、「ステージング表」を参照してください。

23.1.2 Webベースのイベント管理インタフェース

Oracle Identity Managerには、Webベースのイベント管理インタフェースが付属しており、Webからイベントを管理できます。認可されたユーザーは、イベントとユーザーを検索し、イベントをユーザーおよびアカウントにリンクして例外を処理できます。イベントのクローズ、失敗したイベントの再評価の強制、および非定型リンクも実行できます。

非定型リンクは、「イベント管理」セクションの認可されたユーザーに提供される機能を参照して、イベントをOracle Identity Managerのいずれかのユーザーにリンクします。リコンシリエーション・エンジンによってそのイベントに対するユーザー一致が検出された場合でも、この非定型リンク機能により、ユーザーはその一致を無視して別のユーザーを選択できるようになります。これにより、誤った一致によって生じる例外を処理できます。

関連項目:

リコンシリエーション・イベントを管理するために実行されるタスクの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のリコンシリエーションの管理に関する説明を参照してください。

23.1.3 その他の機能

その他のリコンシリエーションの機能について、次の各項で説明します。

- ステージング表

- 競合状態の処理

- 非定型リンク

23.1.3.1 ステージング表

以前のバージョンのOracle Identity Managerでは、様々なターゲットから取得したすべてのイベント詳細が、リコンシリエーション・スキーマの1つの表に格納されます。各種リコンシリエーション・イベントに含まれる属性およびその名前とタイプのリストは、ターゲットによって異なる場合があります。つまり、あるターゲットのイベントに含まれるデータ・セットが、別のターゲットのイベントに含まれるものと異なる場合があります。このようなイベントのデータを1つの表に格納する唯一の方法は、1行に1つの属性を格納することです。そのため、以前のリリースでは、イベント詳細表の各行が、リコンシリエーション・イベント・データの1つの属性に相当しています。各属性行には、その属性が属するイベント、属性の名前、タイプ、値が格納されます。このような表のことを、このドキュメントでは垂直表とも呼びます。垂直表は、柔軟性と拡張性の面では利点がありますが、パフォーマンスの観点からはイベント・レコードを格納する効率的な方法とはいえません。

垂直表での格納が、水平表またはステージング表と呼ばれるターゲットごとの個別表で置き換えられました。イベントの属性を表内の行として垂直に格納する(属性の数が行数になる)のではなく、イベントの属性を列として格納するため、水平表と呼ばれます。つまり、ターゲットの属性数と同じ数の列が存在します。各イベントは、行として格納されます。異なるターゲットは異なる属性セットを持つことがあるため、各ターゲットは、イベントの詳細を格納するリコンシリエーション・スキーマ内に個別の表を持ちます。子表内の行として格納される複数値属性を処理する要件のために、1つのターゲットに複数の表が存在することがあります。

特定のプロファイルに対するイベント詳細表の各行には、1つのイベントのリコンシリエーション・フィールドのリストが格納されます。たとえば、信頼できるユーザーのリコンシリエーションで姓、名、電子メール属性がリコンサイルされる場合、RA_XELLERATE_USERステージング表に次の列が含まれます。

RE_KEY、RECON_FIRSTNAME、RECON_LASTNAME、RECON_EMAI

ステージング表の作成と管理

ステージング表は、ターゲットをOracle Identity Managerに対してデプロイしている場合のみ作成できます。これは、ターゲットのデプロイ時に、リコンシリエーション・システムがリコンサイルする必要のあるターゲットの属性とそのタイプのリストを把握しているためです。

デプロイメント・マネージャから構成をインポートしたり、Oracle Identity Manager Design Consoleから変更を行ったりした場合には、ステージング表が更新されます。Oracle Identity Manager Design Consoleからステージング表を生成するには、オブジェクト・リコンシリエーション・フォームで、リコンシリエーション・プロファイルの生成をクリックします。

23.1.3.2 競合状態の処理

以前のリリースのOracle Identity Managerでは、イベントをリコンサイルする際に、そのイベントをリコンサイルする前に別のイベントをリコンサイルする必要があるために、リコンシリエーション・エンジンがそのイベントを正常に処理できないことがありました。たとえば、リコンシリエーション・エンジンは、アカウントを作成するイベントをリコンサイルする前に、ユーザーを作成するイベントをリコンサイルする必要があります。これを競合状態と呼びます。

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、「リコンシリエーション・イベントの再試行回数」システム・プロパティの値を設定することによって競合状態が処理されます。自動再試行を構成するには、このプロパティに0より大きい値を指定します。自動再試行を構成しない場合は、「リコンシリエーション・イベントの再試行回数」システム・プロパティの値に0を指定します。

自動再試行を構成する場合、リコンシリエーション・エンジンは競合状態をチェックします。競合状態が見つかると、リコンシリエーション・エンジンは、再試行回数に達するまでリコンシリエーション・イベントを再評価キューに入れます。

リコンシリエーションの再試行スケジュール済タスクは、再試行を待っているイベントがないか、そして再評価される準備ができているかどうかを定期的にチェックし、ある場合は、それをリコンシリエーション・エンジン処理用のキューに入れます。このスケジュール済タスクは、デフォルトで構成されています。

注意:

自動再試行回数に達すると、リコンシリエーション・エンジンはイベントの処理をやめ、一致ルールによってステータスを設定します。ただし、「イベント管理」から再評価をリクエストすれば、手動で再試行できます。イベントの再評価の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のイベントの再評価に関する説明を参照してください。

自動再試行は次の競合状態を処理できます。

- ユーザーを作成するイベントがまだ処理されていないために、Oracle Identity Managerのアカウントを作成するアカウント・イベントが、このイベントのユーザーが作成される前に処理されます。

- Oracle Identity ManagerのXellerateユーザーを作成するユーザー・イベントが、このユーザーが属する組織が作成される前に処理されます。

すべての自動再試行パラメータは、リコンシリエーション・プロファイルの一部として格納されます。つまり、あるリコンシリエーション実行に属するイベントに自動再試行が構成されていて、別のリコンシリエーション実行に属するイベントでは自動再試行が構成されていないこともあります。

Oracle Identity Managerでは、このプロファイル内のパラメータを管理するUIがないため、XMLエディタを使用してXMLプロファイルを直接編集してパラメータを管理する必要があります。XMLプロファイルの編集については、「リコンシリエーション・プロファイルの作成および更新」を参照してください。

23.1.3.3 非定型リンク

リコンシリエーション・エンジンで一致ルールに基づいて所有者を決定できない場合は、Oracle Identity Manager拡張管理を使用してアカウントをユーザーに手動でリンクできます。その後のアカウントに対する変更は、そのアカウントに自動的にリンクされます。

非定型リンクは、ユーザー・イベントおよびアカウント・イベントでサポートされています。リコンシリエーション・エンジンで一致ルールに基づいて所有者を決定できない場合は、ユーザー・イベントまたはアカウント・イベントをユーザーに手動でリンクできます。

関連項目:

非定型リンクの実行方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の非定型リンクに関する説明を参照してください。

23.2 リコンシリエーションのアーキテクチャ

リコンシリエーションは、2つのシステム間のエンティティ・データが整合性のある状態で維持されるように、エンティティ・データをターゲット・システムからOracle Identity Managerに取得するプロセスです。図23-1に、リコンシリエーションに関係するOracle Identity Managerの様々なコンポーネント、およびこれらのコンポーネント間の相互作用を示します。

図23-1 リコンシリエーションのアーキテクチャ

リコンシリエーションのアーキテクチャを次のステップで説明します。

1. 各コネクタには、スケジュール済タスクが関連付けられます。スケジューラがコネクタのスケジュール済タスクをトリガーし、このタスクによってイベントを生成するためのリコンシリエーションAPIが起動されます。イベントのタイプは、標準、変更ログまたは削除のいずれかです。
スケジューラの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のスケジューラの管理に関する説明を参照してください。スケジュール済タスクの詳細は、「リコンシリエーションのコネクタ」を参照してください。

2. リコンシリエーション・イベントがリコンシリエーション・イベント・リポジトリ(Oracle Identity Managerデータベース)に格納されます。

3. バッチ・サイズが適合する場合は、イベントのバッチをまとめて処理する非同期メッセージが送信されます。スケジュール済タスクの終了時に、最後のバッチのイベントを処理する目的で、別の非同期メッセージが送信されます。

注意:

- 図23-1では、リコンシリエーション・エンジンがアクションJAVAレイヤーおよびリコンシリエーション・イベント・リポジトリの一部をカプセル化し、この図の矢印のすべてをオーケストレートしています。

- このリリースでは、信頼できるソース・リコンシリエーションはユーザーに対してのみサポートされています。ロール、ロール・メンバーシップおよびロール階層のリコンシリエーションはサポートされていません。

- このリリースのOracle Identity Managerでは、組織に対して、信頼できるソース・リコンシリエーションとアカウント・リコンシリエーションがサポートされています。

4. 処理には、データの検証、エンティティの照合およびアクション(作成、更新、削除など)が含まれます。その後、カーネル・オーケストレーションを介した後処理が続きます。アクション・モジュールの詳細は、「アクション・モジュール」を参照してください。リコンシリエーション・プロファイルの詳細は、「新しいメタデータ・モデル - プロファイル」を参照してください。

5. デフォルトでは、リコンシリエーションのイベント処理は大量に発生するため、後処理までのすべてのステップは、PL/SQLストアド・プロシージャで実行されます。次のシナリオでは、イベントを一度に1つずつ処理できます(この場合、照合までのすべてのステップはPL/SQLで処理され、アクションはJavaレイヤーで実行されます)。

- イベントがイベント管理UIから処理される場合

- 失敗したイベントが、定期的に実行される再試行のスケジュール済タスクによって再試行される場合

単一のイベントを処理するリコンシリエーションの場合、アクションおよび後処理はカーネル経由で実行されます。

6. リコンシリエーション・イベントは、リコンシリエーション管理サービスの別のAPIコールによって、イベント管理UIに対して使用可能になります。

リコンシリエーション・サービスの様々なコンポーネントの機能は、次の各項を参照してください。

- リコンシリエーション・プロファイル

- リコンシリエーション・メタデータ

- リコンシリエーション・ターゲット

- リコンシリエーション実行

- リコンシリエーションAPI

- リコンシリエーション・スキーマ

- リコンシリエーション・エンジン

- リコンシリエーションのコネクタ

- アーカイブ

- 下位互換性

- リコンシリエーション・イベントの管理

23.2.1 リコンシリエーション・プロファイル

リコンシリエーション・プロファイルは、特定のリソースに対するリコンシリエーションの実行方法を管理するために定義された構成です。特定のリソースに複数のリコンシリエーション・プロファイルを指定し、それぞれに一致ルール、アクション・ルールおよびフィールド・マッピングを定義し、その際、リソースに対応する各プロファイルには異なる定義を指定できます。たとえば、削除を1日1回のみ実行する必要がある場合は、一方のリコンシリエーションの実行で新規および変更されたアカウントのリコンシリエーションを実行し、もう一方のリコンシリエーションの実行でアカウントの削除をリコンサイルできます。この例では、2つのリコンシリエーション実行と2つのプロファイルを定義します。各プロファイルはそれぞれのリコンシリエーションの実行に関連付けられ、各プロファイルには独自のリコンシリエーション・ルールがあります。

プロファイルはXMLベースの構成ファイルで、Oracle Identity Manager MetaData Store (MDS)に格納されます。例23-1に、リコンシリエーション・プロファイルのサンプルを示します。

例23-1 リコンシリエーション・プロファイルのサンプル

<?xml version='1.0' encoding='UTF-8'?>
<profile xmlns="http://www.oracle.com/oracle/iam/reconciliation/config" ownerType="User" changeType="CHANGELOG" auditEnabled="true" batchSize="500" resourceType="Account" name="Modified AD User" configure="true" active="true">
<matchingRule>((UPPER(USR.usr_udf_obguid)=UPPER(RA_ADUSERE469E5C8.RA_OBJECTGUID)))</matchingRule>
<form oimTableName="UD_ADUSER" stagingTableName="RA_ADUSERE469E5C8" name="Modified AD User" mlsOimTable="mlsOIMTableIfAny" mlsStagingTable="mlsStagingTableIfmlsOIMTable">
<matchingRule>(UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSERE469E5C8.RA_OBJECTGUID)</matchingRule>
<targetAttributes>
<targetAttribute type="String" name="Status">
<stagingField type="String" length="256" name="RA_STATUS"/>
</targetAttribute>
<targetAttribute type="String" name="copyStatus" ref="Status" mls="true">
<stagingField type="String" length="256" name="COPY_STATUS"/>
<oimAttribute type="String" fieldName="OIM_OBJECT_STATUS" fieldType="String" name="OIM_OBJECT_STATUS"/>
</targetAttribute>
<targetAttribute type="String" name="password" encrypted="true" keyField="false" required="false">
<stagingField type="String" length="256" name="PASSWORD"/>
<oimAttribute type="String" fieldName="UD_ADUSER_PASSWORD" fieldType="String" name="AD Password"/>
</targetAttribute>
<targetAttribute type="Date" name="accountExpires">
<stagingField type="Date" name="RA_ACCOUNTEXPIRES"/>
<oimAttribute type="Date" fieldName="UD_ADUSER_DATE" fieldType="Date" name="Account Expiration Date"/>
</targetAttribute>
<targetAttribute type="ITResource" name="IT Resource" keyField="false">
<stagingField type="ITResource" length="19" name="RA_ITRESOURCE15641F83"/>
<oimAttribute type="Number" fieldName="UD_ADUSER_AD" fieldType="Number" name="AD Server"/>
</targetAttribute>
<targetAttribute type="String" keyField="true" name="objectGUID">
<stagingField type="String" length="32" name="RA_OBJECTGUID"/>
<oimAttribute type="String" fieldName="UD_ADUSER_OBJECTGUID" fieldType="String" name="Object GUID"/>
</targetAttribute>
</targetAttributes>
<form oimTableName="UD_ADUSRC" stagingTableName="RA_ADUSERGROUPDETA902DB909" name="memberOf">
<matchingRule>(UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_ADUSERGROUPDETA902DB909.RA_MEMBEROF)</matchingRule>
<targetAttributes>
<targetAttribute type="String" keyField="true" name="memberOf">
<stagingField type="String" length="256" name="RA_MEMBEROF"/>
<oimAttribute type="String" fieldName="UD_ADUSRC_GROUPNAME" fieldType="String" name="UD_ADUSRC_GROUPNAME"/>
</targetAttribute>
</targetAttributes>
</form>
</form>
<actionRules>
<actionRule condition="One Entity Match Found" action="Establish Link"/>
</actionRules>
</profile>

表23-1に、リコンシリエーション・プロファイルXMLファイルの要素および構造を示します。

表23-1 リコンシリエーション・プロファイルXMLの要素

要素レベル1

サブ要素レベル2

サブ要素レベル3

サブ要素レベル4

サブ要素レベル5

説明

<profile>

リコンシリエーション構成プロファイルのルート要素またはオブジェクト。

<ownerType>

ロール階層、ロール・メンバーシップ、アカウントのみに対して、それぞれRole、Role、Userの値が移入されます。

<changeType>

デフォルトでは(または要素が存在しない場合)、値はCHANGELOGです。それ以外の場合、値はREGULAR、CHANGELOGまたはDELETEとなります。

<auditEnabled>

アカウント・タイプのプロファイルのみで使用されます。デフォルトでは(または要素が存在しない場合)、値はfalseで、リソース・オブジェクトの監査が停止されます。

<batchSize>

バッチごとのリコンシリエーション・イベントのサイズまたは数を変更します。デフォルトでは(または要素が存在しない場合)、バッチ・サイズは500です。

<resourceType>

値は、Account、User、Role、RoleRole、RoleUser、Organizationのいずれかです。

<name>

これは、リソース・オブジェクト名です。

<configure>

デフォルトでは(または要素が存在しない場合)、値はfalseです。システムでリコンシリエーション構成を作成または更新する場合は、これをtrueとしてマークする必要があります。プロファイルのすべての手動修正の後、この属性をtrueとしてマークする必要があります。本番のテストの場合は、ターゲット・システムにインポートする前にこの要素をtrueとしてマークします。

<active>

デフォルトでは(または要素が存在しない場合)、値はtrueです。破損したプロファイルまたは無効なプロファイルの場合、値はfalseで、プロファイルが使用不可とマークされます。このようなプロファイルは、システムにロードされません。プロファイルのすべての手動修正の後、この属性を削除するか、trueとしてマークする必要があります。

<matchingRule>

ロール階層、ロール・メンバーシップ、アカウントのみに対して、所有者一致ルールが移入されます。それ以外の場合、要素は存在しません。

<form>

プロファイルごとに1つの親フォームを指定します。

<oimTableName>

データのリコンサイル先のOracle Identity Manager表。

<stagingTableName>

ターゲット・システムのデータが処理前に格納されるステージング表。

<name>

親フォームの場合はプロファイル名と同じであり、子フォームの場合は複数値属性名と同じです。

<mlsOimTable>

リソース・オブジェクトがMLA対応の場合は、データのリコンサイル先である多言語サポート(MLS) Oracle Identity Manager表。

<mlsStagingTable>

リソース・オブジェクトがMLS対応の場合は、ターゲット・システムのデータが処理前に格納されるMLSステージング表。

<matchingRule>

フォーム(プロファイルに関連付けられているリソース・オブジェクト)の一致ルールであり、必須です。

<targetAttributes>

すべてのターゲット属性をグループ化します。

<targetAttribute>

ターゲット・システムの属性ごとに1つ。

<type>

ターゲット属性のデータ・タイプ。

<keyfield>

デフォルト値はfalseです。アカウント・リソース・タイプの一致ルールで使用されます。

<name>

リコンシリエーションを開始するコネクタによって提供される、ターゲット・システムの属性の名前。

<required>

属性が必須の場合、この要素が存在する必要があります。

<encrypted>

値がtrueの場合、属性値は暗号化されてステージング表およびOracle Identity Manager表に格納されます。

<ref>

値がコピーされてこの属性に格納される、同じフォーム内のターゲット属性の名前。

<stagingField>

ターゲット属性に対応する、ステージング表の列を指定します。これには、次の要素が含まれます。

<type>: ステージング表の列のデータ・タイプ。

<length>: ステージング表の列またはフィールドの長さまたはサイズ。

<name>: ステージング表の列の名前。

<oimAttribute>

マップされたOracle Identity Managerドメイン属性名を指定します。この要素は、ターゲット属性がマップされる場合にのみ存在します。これには、次の要素が含まれます。

<name>: Oracle Identity Manager属性名

<type>: Oracle Identity Manager属性タイプ

<fieldName>: Oracle Identity Managerのマップ済属性に対応するOracle Identity Manager表の列名

<fieldType>: Oracle Identity Managerのマップ済属性に対応するOracle Identity Manager表の列の型

<form>

子フォームか、親フォームまたはルート・フォームのフォームを指定します。複数値属性に対応します。

<matchingRule>

子フォームの一致ルール。

<targetAttributes>

これは、親の<targetAttributes>要素と同じ要素です。この要素は、複数回ネストできます(例: <form><targetAttributes><form><targetAttributes>)。

<actionRules>

リソース・オブジェクトのすべてのアクション・ルールをグループ化します。

<actionRule>

アクション・ルールごとのactionRule要素。

<condition>

値は、No Matches Found、One Entity Match Found、Multiple Entity Matches Found、One Process Match Found、Multiple Process Matches Foundのいずれかです。

<action>

プロファイルXSDに基づいて任意に指定できます。

リソース・オブジェクトには、リコンシリエーション構成に関連付けられたデフォルトのプロファイルが常に存在します。デフォルトのプロファイルは、開発者の環境のOracle Identity Manager Design Consoleから明示的に生成するか、デプロイメント・マネージャからのインポート時に暗黙的に生成できます。プロファイルを作成および更新する方法の詳細は、「リコンシリエーション・プロファイルの手動による更新」を参照してください。

23.2.2 リコンシリエーション・メタデータ

リコンシリエーション・メタデータは、リコンシリエーション・イベントの作成と処理で使用する様々な構成で構成されます。リコンシリエーション・メタデータは、プロファイルと呼ばれる論理的なコンテナに格納されます。リコンシリエーション・プロファイルの詳細は、「リコンシリエーション・プロファイル」を参照してください。

次に、リコンシリエーション・メタデータの例を示します。

- マッピング・ルール: ターゲット・システムから受け取ったデータを、そのターゲット・システムに関して管理されている、Oracle Identity Managerのデータにマップする際に使用されます。

- 一致ルール: イベント・データと特定のアカウント、ユーザーまたはロールを相互に関連付けるために、各リコンシリエーション・イベントの処理時に使用されます。

- アクション・ルール: リコンシリエーション・イベントの処理結果に基づいてOracle Identity Managerが実行するアクションを指定するために使用されます。

- ターゲット属性のリスト: リコンシリエーションを介してターゲット・システムから受け取ったデータ属性の定義に使用されます。マッピング・ルールで使用され、Oracle Identity Manager Design Consoleを使用して構成されます。

リコンシリエーション・イベントの作成と処理で使用する様々な構成は、Oracle Identity Manager Design Consoleを使用して管理され、下位互換性のために、Oracle Identity Managerリリース9.1.0と同じOracle Identity Managerの表に格納されます。さらに、これらの構成はリコンシリエーション・プロファイルにも格納されます。

注意:

Oracle Identity Managerでのリコンシリエーションには、メタデータ・モデルが使用されます。Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・イベントの管理に関する項を参照してください。

23.2.3 リコンシリエーション・ターゲット

リコンシリエーション・ターゲットとは、Oracle Identity Managerの変更のソースとして機能するアプリケーションのインスタンスです。リコンシリエーション・ターゲットの例には、Oracle Identity Managerのアイデンティティのソースとして機能する人事管理システムがあります。リコンシリエーション・ターゲットのソースは、ユーザーまたはアカウントのいずれかです。

23.2.4 リコンシリエーション実行

リコンシリエーション実行とは、リコンシリエーション・コネクタと関連する構成の組合せを意味し、スケジュール済タスクによって実行される場合は、関連する構成に定義されているルールに基づいてリコンシリエーションを実行します。スケジューラは、リコンシリエーションを固定間隔で定期的に実行します。リコンシリエーション実行はOracle Identity Managerのスケジューラでスケジュールされ、指定した頻度で実行されます。リコンシリエーション実行時に作成されたすべてのイベントは、一意のリコンシリエーション実行IDに従ってグループ化されます。

23.2.5 リコンシリエーションAPI

リコンシリエーションAPIは、リコンシリエーション・データをリコンシリエーション・イベントの形式でOracle Identity Managerに提供するために公開された一連のAPIです。コネクタは、このAPIを使用して、リコンシリエーション・イベント・リポジトリにデータをプッシュできます。リコンシリエーションをスケジュールに従って実行する場合は、APIを実行するスケジュール済タスクを設定できます。既存のAPIがサポートされているため、既存のコネクタを変更する必要はありません。

23.2.6 リコンシリエーション・スキーマ

リコンシリエーション用にターゲット・システムから受け取ったデータは、リコンシリエーション・スキーマに格納されます。このデータには、Oracle Identity Managerとリコンサイルする変更も含まれています。

リコンシリエーション・スキーマとは、リコンシリエーション・データを格納する一連のスキーマ表です。リコンシリエーション・スキーマは、パフォーマンス上の理由および将来の拡張性に備えて再設計されています。リコンシリエーション・スキーマの詳細は、「改善されたデータベース・スキーマ」を参照してください。

23.2.7 リコンシリエーション・エンジン

リコンシリエーション・エンジンでは、構成可能なすべてのコンポーネントが使用され、これらのコンポーネントを使用して入力データをアクション・アイテムのリストに変換するデータ・プロセッサとルール・エバリュエータが組み込まれています。ルールのコンテキストに基づいてアクションを自動化できるかどうかを判断するコンポーネントも組み込まれています。アクションが自動または手動で実行されると、エンジンは適切な更新とプロビジョニング・アクションを実行します。

リコンシリエーション・エンジンのメイン・タスクは、比較を実施して、実行するアクションを判断し、そのアクションをOracle Identity Managerで適用することです。2つのモジュールがあり、各モジュールについては、次の各項で説明します。

- 照合モジュール

- アクション・モジュール

23.2.7.1 照合モジュール

プロファイルで指定した照合ルールは、検索対象レコードがOracle Identity Managerにあるかどうかを識別するために使用されます。一致ルールは、Oracle Identity Managerにすでにレコードがあるアイデンティティに対応するデータであるかどうかを識別するためのルール、あるいはOracle Identity Managerでアカウントの所有者を識別するためのルールです。

アカウントのエンティティでは、レコードが見つからない場合は、次に所有者の照合が実行され、アカウントの所有者が識別されます。

ロール階層イベントでは、親ロールおよび子ロールを識別する照合が実行されます。

注意:

ロール階層およびロール・メンバーシップのリコンシリエーションの実行では、照合基準に、ネームスペースとロール名の両方が含まれている必要があります。次に、照合ルールの例を示します。

((UGP.ugp_rolename=x) and (UGP.ugp_namespace=y))

xはロール名にマップされているステージング表名の列の名前で、yはネームスペースにマップされるステージング列の名前です。

評価が終了すると、照合表には、イベントの基準を満たし、Oracle Identity Manager内で検出された考えられる適合すべてが格納され、イベントの状態は表23-2に示すいずれかのステータスに更新されます。

表23-2 リコンシリエーションのステータス・イベント

ステータス・イベント

説明

データを受信しました

イベント・データがデータベースに作成され、次の処理に対する準備が整っています。

イベントを受信しました

リコンシリエーション・イベントが作成され、次の処理に対する準備が整っています。finishReconciliationEvent APIはコールされていません。

データ検証に失敗しました

リコンシリエーション・イベント・レコードは無効です。たとえば、ロール・カテゴリが無効なロール・イベントは検証に失敗します。(この状況は競合状態を示している可能性があります。)RE_NOTEフィールドには失敗の詳細が表示され、ユーザー・インタフェースにも表示されます。

データ検証に成功しました

イベント・データが正常に検証され、イベントはエンジンで支障なく処理できます。

複数のアカウントの一致が見つかりました

現在の一致ルールでは、データと一致する複数のアカウント・レコードが見つかりました。

アカウントの一致が見つかりません

現在の一致ルールでは、データと一致するアカウント・レコードは見つかりません。

単一のアカウントの一致が見つかりました

現在の一致ルールでは、データと一致する単一のアカウント・レコードが見つかりました。

複数の組織の一致が見つかりました

現在の一致ルールでは、データと一致する複数の組織レコードが見つかりました。

組織の一致が見つかりません

現在の一致ルールでは、データと一致する組織レコードは見つかりません。

単一の組織の一致が見つかりました

現在の一致ルールでは、データと一致する単一の組織レコードが見つかりました。

複数のロール付与の一致が見つかりました

ロール内のユーザー・メンバーシップと一致する複数のレコードが見つかりました。

ロール付与の一致が見つかりません

ロール内のユーザー・メンバーシップと一致するレコードは見つかりません。

単一のロール付与の一致が見つかりました

ロール内のユーザー・メンバーシップと一致する単一のレコードが見つかりました。

複数のロールの一致が見つかりました

現在の一致ルールでは、データと一致する複数のロール・レコードが見つかりました。

ロールの一致が見つかりません

現在の一致ルールでは、データと一致するロール・レコードは見つかりません。

単一のロールの一致が見つかりました

現在の一致ルールでは、データと一致する単一のロール・レコードが見つかりました。

ロール・メンバーが見つかりませんでした

現在の一致ルールでは、データと一致するロール・メンバーは見つかりません。

ロールの親が見つかりません

現在の一致ルールでは、データと一致するロールは見つかりません。

複数のロール関係の一致が見つかりました

現在の一致ルールでは、イベントのデータと一致する複数のロール対ロールの関係が見つかりました。

ロール関係の一致が見つかりません

現在の一致ルールでは、イベントのデータと一致するロール対ロールの関係は見つかりません。

単一のロール関係の一致が見つかりました

現在の一致ルールでは、イベントのデータと一致する単一のロール対ロールの関係が見つかりました。

複数のユーザーの一致が見つかりました

現在の一致ルールでは、データと一致する複数のユーザー・レコードが見つかりました。

ユーザーの一致が見つかりません

現在の一致ルールでは、データと一致するユーザー・レコードは見つかりません。

単一のユーザーの一致が見つかりました

現在の一致ルールでは、データと一致する単一のユーザー・レコードが見つかりました。

無効なイベント・データが渡されました

イベントに無効なデータが含まれています。

再評価中です

リコンシリエーション・イベントは、現在、リコンシリエーション・イベント管理UIで再評価されています。

再試行中です

リコンシリエーション・イベントは、現在、自動的に再試行されています。このステータス・イベントは非推奨になりました。

作成に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に作成されていません。

作成に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に作成されました。

削除に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に削除されていません。

削除に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に削除されました。

イベントがクローズされました

リコンシリエーション・イベントは、リコンシリエーション・イベント管理UIからクローズされました。変更は完了しています。

更新に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に更新されていません。

更新に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に更新されました。

23.2.7.2 アクション・モジュール

このモジュールでは、表23-3に示すように、イベントの状態、エンティティ・タイプおよびアクション・ルールに基づいてアクションが適用されます。

表23-3 アクション・ルール

イベントの状態

エンティティ・タイプ

アクション

説明

ユーザーの一致が見つかりません

ユーザー

なし

アクションは実行されません。

ユーザーの作成

Oracle Identity Managerのユーザーを作成します。

アカウントの一致が見つかりません

アカウント

なし

アクションは実行されません。

単一のユーザーが一致しました

ユーザーまたはアカウント

なし

アクションは実行されません。

ユーザー

リンクの確立

変更タイプに基づいて一致したユーザーを変更または削除します。

アカウント

リンクの確立

所有者が識別され、アカウントが作成されます。

複数のユーザーが一致しました

ユーザーまたはアカウント

なし

アクションは実行されません。

単一のアカウントが一致しました

アカウント

なし

アクションは実行されません。

リンクの確立

変更タイプに基づいてアカウントを変更または失効します。

複数のアカウントが一致しました

なし

アクションは実行されません。

ロールの一致が見つかりません

ロール

なし

アクションは実行されません。

単一のロールの一致が見つかりました

ロール

なし

アクションは実行されません。

リンクの確立

ロールを変更または削除します。

ロール・メンバーシップ

ロール・メンバーシップの作成

ロール・メンバーをOracle Identity Managerに付与します。

ロール・メンバーシップの削除

ロール・メンバーをOracle Identity Managerから削除します。

なし

アクションは実行されません。

ロール階層

ロール階層の作成

Oracle Identity Managerにロール階層を作成します。

ロール階層の削除

Oracle Identity Managerのロール階層を削除します。

なし

アクションは実行されません。

複数のロールが一致しました

ロール、ロール・メンバーシップおよびロール階層

なし

アクションは実行されません。

ロール付与の一致が見つかりません

ロール・メンバーシップ

なし

アクションは実行されません。

ロール・メンバーの作成

Oracle Identity Managerにロール・メンバーを作成します。

単一のロール付与の一致が見つかりました

ロール・メンバーシップ

なし

アクションは実行されません。

リンクの確立

ロール・メンバーの削除

複数のロール付与の一致が見つかりました

ロール・メンバーシップ

なし

アクションは実行されません。

注意: ロール付与の照合は主キー(ユーザー・キーとグループ・キーの組合せ)を検索することで処理されるため、この状態は発生しません。

ロールの親の一致が見つかりません

ロール階層

なし

アクションは実行されません。

ロールの親の作成

Oracle Identity Managerにロールの親を作成します。

単一のロールの親の一致が見つかりました

ロール階層

なし

アクションは実行されません。

リンクの確立

ロールの親を削除します。

複数のロールの親の一致が見つかりました

ロール階層

なし

アクションは実行されません。

データ検証に失敗しました

ロール、ロール階層、ロール・メンバー

競合状態

アクションは実行されません。イベントを再評価する必要があります。

親ロールが見つかりません

ロール階層

競合状態

アクションは実行されません。イベントを再評価する必要があります。

ロール・メンバーが見つかりません

ロール・メンバーシップ

競合状態

アクションは実行されません。イベントを再評価する必要があります。

23.2.8 リコンシリエーションのコネクタ

コネクタとは、ターゲット・システムから変更を抽出し、リコンシリエーションAPIをコールしてリコンシリエーション・スキーマにイベントを作成するソフトウェアです。使用するコネクタが事前定義済リコンシリエーション・モジュールに付属している場合は、スケジュール済タスク定義を使用できます。このコンポーネントを使用して、データおよび他のコネクタ固有のパラメータを追跡するために、ターゲット・システムで変更がポーリングされる頻度を制御します。

リコンシリエーションのコネクタは、デプロイメント・マネージャを使用してデプロイされます。コネクタがデプロイされると、そのコネクタの対応するリコンシリエーション・プロファイルがメタデータ・ストア(MDS)に作成され、イベント・データを格納する水平表も作成されます。

注意:

リコンシリエーションの実行中は、リコンシリエーション・プロファイルを手動で更新したり、デプロイメント・マネージャまたはOracle Identity Manager Design Consoleからリコンシリエーション構成を更新しないでください。これは、リコンシリエーションの実行中にリコンシリエーション・フィールドが削除または更新されると、イベント・データが無効になる可能性があるためです。

コネクタの構成の詳細は、Oracle Identity Managerのコネクタのドキュメントを参照してください。

関連項目:

- MDSの詳細は、「リコンシリエーション・メタデータ」を参照してください。

- ステージング表の詳細は、「ステージング表」を参照してください。

23.2.9 アーカイブ

リコンシリエーション・アーカイブ・ユーティリティを使用すると、処理したイベントをアクティブ・リコンシリエーション表からアーカイブ表に移動できます。移動するイベントは、時間の範囲に基づいて選択できます。アーカイブできるのは、リンクしたイベントおよびクローズしたイベント(つまり、正常に処理されたか、管理者がクローズしたイベント)のみです。

関連項目:

リコンシリエーション・アーカイブ・ユーティリティの使用方法は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のリコンシリエーション・アーカイブ・ユーティリティの使用に関する説明を参照してください。

23.2.10 下位互換性

新規のリコンシリエーション・サービスを活用するために、既存のリコンシリエーション構成またはスケジュール済タスクを変更する必要はありません。

Oracle Identity Managerの以前のリリースでのリコンシリエーション設定に関する既存の構成は、11gリリース2 (11.1.2.1.0)にアップグレードした後も引き続き機能します。アップグレードの一環として、リコンサイル対象の既存のオブジェクト・タイプごとに、対応するリコンシリエーション・イベントの表が作成されます。

23.2.11 リコンシリエーション・イベントの管理

リコンシリエーション・イベントは、Oracle Identity System Administrationの「イベント管理」セクションを使用して管理されます。「イベント管理」セクションでは、Oracle Identity Managerリコンシリエーション・エンジンによって生成されたリコンシリエーション・イベントを表示および管理できます。これらのイベントは、スケジュール済リコンシリエーション実行を介して生成されます。「イベント管理」セクションには、リコンシリエーション実行およびイベントの検索機能が用意されています。「イベント管理」セクションを使用すると、生成されたイベントに対してリコンシリエーションを手動で実行できます。

関連項目:

Oracle Identity System Administrationでのリコンシリエーション・イベントの管理の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のリコンシリエーション・イベントの管理に関する説明を参照してください。

23.3 リコンシリエーション・ルールの定義

次のインスタンスで起動されるリコンシリエーション・ルールを定義できます。

- 信頼できるソースへの変更に関連付けられているユーザーまたは組織のレコードをOracle Identity Managerにより判別する場合。これらのルールは、「リコンシリエーション・マネージャ」フォームの「リコンシリエーション・データ」タブで、リコンシリエーション・イベントのすべての必須フィールドが処理された時点で評価されます。

- (たとえば、システムで変更が検出されたことを受けて)どのユーザー・レコードまたは組織レコードがターゲット・リソースで検出されたアカウントの所有者かをOracle Identity Managerにより判別する場合。これらのルールは、「リコンシリエーション・マネージャ」フォームの「リコンシリエーション・データ」タブで、リコンシリエーション・イベントのすべての必須フィールドが処理され、同フォームのプロセス一致ツリー・タブのイベントと一致するプロセスがなかった場合のみ評価されます。

Design Consoleの「リコンシリエーション・ルール」フォームは、Oracle Identity Managerのリコンシリエーション・ルールを作成および管理するために使用します。このフォームは、「開発ツール」フォルダにあります。図23-2に、「リコンシリエーション・ルール」フォームを示します。

図23-2 「リコンシリエーション・ルール」フォーム

前述のように、このフォームを使用して定義されたルールは、信頼できるソースまたはターゲットのリソースでの変更に関連付けられているユーザーまたは組織いずれかとの一致に使用されます。これらのタイプのルールは、それぞれユーザー一致ルールまたは組織一致ルールと呼ばれます。これらのルールは、「ルール・デザイナ」フォームを使用して定義できるルールと似ていますが、「リコンシリエーション・ルール」フォームを使用して作成されたルールは、(単一のターゲット・リソースに関連するため)リソース・オブジェクト固有で、リコンシリエーション関連の機能のみに影響します。

リコンシリエーション・ルールの使用に関するトピックは次のとおりです。

- リコンシリエーション・ルールの定義

- ルール要素の追加

- ルール内でのルールのネスト

- ルール要素またはルールの削除

23.3.1 リコンシリエーション・ルールの定義

次の手順では、リコンシリエーション・ルールの定義方法について説明します。

注意:

次の手順では、必ず「アクティブ」チェック・ボックスが選択されていることを確認してください。このチェック・ボックスが選択されていない場合、リソースに関連するリコンシリエーション・イベントの処理時に、Oracle Identity Managerのリコンシリエーション・エンジンによってルールが評価されません。ただし、このチェック・ボックスを選択できるのは、Oracle Identity Managerによって「valid」システム・チェック・ボックスが選択されている場合のみです。「valid」チェック・ボックスは、1つ以上のルール要素が作成され、そのルール要素のロジックが有効であるとOracle Identity Managerによって判断された後でのみ選択可能です。

ユーザーの一致または組織の一致用にリコンシリエーション・ルールを定義するには、次の手順を実行します。

1. 「リコンシリエーション・ルール」フォームに移動します。

2. 「名前」フィールドに、ルール名を入力します。

3. 「オブジェクト」フィールドで、このルールを関連付けるターゲット・リソースを選択します。

4. 「説明」フィールドにルールの説明を入力します。
ルールに使用する「および」演算子または「または」演算子を選択します。「および」を選択した場合は、ルールのすべての要素(およびルールがネストされている場合はそれらのルール)が一致しないかぎり、ルールがtrueと評価されません。「または」を選択した場合は、ルールのいずれかの要素(またはルールがネストされている場合はそのいずれか)が一致すると、trueと評価されます。

5. 「保存」をクリックします。
ルール定義が保存されます。次に、このルールのルール要素を作成する必要があります。

23.3.2 ルール要素の追加

リコンシリエーション・ルールの個々の要素を定義するには、次の手順を実行します。

1. 要素を追加するルール定義に移動します。

2. 「ルール要素」タブのルール要素の追加をクリックします。
ルール要素の追加ダイアログ・ボックスが表示されます。

3. 「ルール要素」タブをクリックします。

4. 「ユーザー・データ」メニューからユーザー関連のデータ項目を選択します。
これが、ルール要素の評価時にOracle Identity Managerによって調査されるユーザー・データ要素になります。このメニューには、Oracleユーザー・フォームのすべてのフィールド(作成済のユーザー定義フィールドを含む)が表示されます。

注意:

組織の一致のためのルールを定義する場合、使用可能なデータおよびメニュー名は、ユーザーではなく組織に関連付けられます。

5. 「演算子」メニューから演算子を選択します。
これは、ルール要素の評価時に、選択したデータ項目の属性にOracle Identity Managerによって適用される条件です。有効な演算子は次のとおりです。

- 次と等しい: このオプションを選択した場合、ユーザーまたは組織のレコードのデータ要素は、選択された属性と完全に一致する必要があります。

注意:

- ユーザーの信頼できるソースのリコンシリエーションを構成する場合は、Oracle Identity Managerユーザー・アカウントの「ユーザーID」フィールドがリコンシリエーション一致ルールで使用されていることを確認する必要があります。

- 組織の信頼できるソースのリコンシリエーションを構成する場合は、Oracle Identity Managerユーザー・アカウントの「組織名」フィールドがリコンシリエーション一致ルールで使用されていることを確認する必要があります。

- 次を含む: このオプションを選択した場合、ユーザーまたは組織のレコードのデータ要素は選択された属性と完全に一致するのではなく、この属性を含んでいる必要があります。

- 次で始まる: このオプションを選択した場合、ユーザーまたは組織のレコードのデータ要素は、選択された属性で始まる必要があります。

- 次で終わる: このオプションを選択した場合、ユーザーまたは組織のレコードのデータ要素は、選択された属性で終わる必要があります。

6. 「属性」メニューから値を選択します。このメニューの値は、ルールに関連付けられているリソースに対して、「リコンシリエーション・フィールド」タブで定義されたフィールドです。そのリソースのリコンシリエーション・フィールドが指定されていない場合、値は選択できません。

注意:

(信頼できるソースとは対照的に)ターゲット・リソースのルール要素を定義する際には、リソースのカスタム・プロセス・フォームの親表に関連付けられているフィールドのみが、「属性」フィールドで選択可能になります。

7. 「属性」フィールド内のデータに対して(演算子を適用する前に)Oracle Identity Managerで特定の変換処理が実行されるようにするには、変換メニューから目的の変換処理を選択します。

注意:

このメニューで「なし」以外の値を選択した場合は、Oracle Identity Managerによって変換処理が正しく実行されるように、「保存」をクリックした後でタブを選択し、適切なプロパティを設定する必要があります。

表23-4に、実行できる変換処理を示します。

表23-4 変換プロパティ

変換

ルール要素プロパティ・タブで設定するプロパティ

部分文字列

開始ポイント、終了ポイント

終了文字列

開始ポイント

トークン化

デリミタ、トークン番号、スペース・デリミタ

8. 大文字/小文字を区別チェック・ボックスを選択します。
このチェック・ボックスを選択した場合、ルール要素が条件と一致するには、「属性」フィールドで選択された値と、リコンシリエーション・イベント・レコードで評価される値の大/小文字が一致している必要があります。このチェック・ボックスの選択を解除した場合、「属性」フィールドで選択された値と、リコンシリエーション・イベント・レコードで評価される値の大/小文字が一致する必要はありません。

9. 「保存」をクリックします。

10. 変換メニューで(「なし」以外の)値が選択されていても、変換処理のプロパティが設定されていない場合は、プロパティが設定されていますチェック・ボックスは選択されません。
その場合は、ルール要素プロパティ・タブを選択し、適切なプロパティを設定して、再度「保存」をクリックする必要があります。

ルール要素がルールに追加されます。

11. ルールに追加するルール要素ごとに、この手順全体を繰り返します。

注意:

「アクティブ」チェック・ボックスが選択されていることを確認してください。

23.3.3 ルール内でのルールのネスト

ルールの中に既存のルールをネストできます。Oracle Identity Managerでは、ネストされたルールの条件は、他のルールの要素と同様に評価されます。

注意:

ダイアログ・ボックスで選択できるのは、同じリソース・オブジェクトに関連付けられているリコンシリエーション関連のルールのみです。

ルールの中にルールをネストするには、次の手順を実行します。

1. 別のルールが追加されるルールに移動します。

2. 「ルール要素」タブの「ルールの追加」をクリックします。

3. ルールの選択参照ダイアログ・ボックスが表示されます。
目的のルールの場所を特定し、選択します。

4. 「OK」をクリックします。
選択したリコンシリエーション・ルールがルールに追加されます。

5. ルールにネストするルールごとに、手順2から4を繰り返します。

23.3.4 ルール要素またはルールの削除

ルール要素またはルールを削除するには、次の手順を実行します。

1. 要素を削除するルールに移動します。

2. 「ルール要素」タブで、削除するルール要素またはルールを選択します。

3. 「削除」をクリックします。

23.4 リコンシリエーションのスケジュール済タスクの開発

Oracle Identity Managerでは、Microsoft Active Directory、Sun Java System Directory、Oracle Internet Directory、Oracle E-Business Suiteなどの様々なターゲット・システムからユーザーやアカウントをリコンシリエーションするためのコネクタを提供しています。これらのコネクタの詳細は、次のURLのOracle Technology Network (OTN) WebサイトにあるOracle Identity Managerコネクタのドキュメントを参照してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html

ただし、カスタム・コネクタを作成するには、次を実行する新しいスケジュール済タスクを開発する必要があります。

1. ターゲット・システムからユーザーやアカウント情報を取得します。

2. リコンシリエーションAPIを使用して、イベント・データを送信するリコンシリエーション・イベントを作成します。

3. エンティティを作成、変更または削除するためのイベントを作成します。

関連項目:

スケジュール済タスクの開発の詳細は、第26章「スケジュール済タスクの開発」を参照してください。

特定のターゲット・システムに接続するには、次のことを実行する必要があります。

- 新規ITリソース・タイプの作成

- 新規ITリソースの定義

- スケジュール済タスクの入力パラメータとしてITリソースを使用

関連項目:

ITリソース定義を参照するためのAPIの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

Oracle Identity Managerでは、プロビジョニング・プロセスとプロセス・インスタンスは、ユーザーまたはアカウントに関係するアクティビティに関連付けられています。これにより、様々なアクションに対するカスタマイズを追加するためのフックまたはポイントが提供されます。

ユーザー状態またはアカウント状態に対する変更が、直接APIまたはリコンシリエーションを介して発生する場合があります。変更には、次のように様々なタイプがあります。

関連項目:

リコンシリエーションAPIの詳細は、「リコンシリエーションAPIの理解」を参照してください。

- ユーザーまたはアカウント・プロファイルでのデータ変更

- 有効化や無効化などのステータス変更

- アテステーション・プロセスに基づくユーザーへの変更

- 組織の変更

- 属性の伝播

- パスワードの伝播

これらの各変更の場合は、プロセス定義により、これらのいずれかの変更時に実行されるフックを追加する機能が提供されます。リコンシリエーションの場合は、プロセス定義により、次の条件付きタスクの形式でフックが提供されます。

- 受信したリコンシリエーションの挿入: この条件付きタスクは、アカウントがリコンシリエーションを介して作成された場合に挿入されます。

- 受信したリコンシリエーションの更新: この条件付きタスクは、ユーザーにリンクされている既存のアカウントがリコンシリエーションを介して更新された場合に挿入されます。プロセス・フォーム内のデータ、またはアカウントのステータスが更新されます。

- 受信したリコンシリエーションの削除: この条件付きタスクは、既存のアカウントがリコンシリエーションを介して失効された場合に挿入されます。

これらのタスクでは、ワークフローの開始ポイントを提供します。プロビジョニング・プロセスにカスタム・ワークフローを作成したり、リコンシリエーション・トリガー・タスクとワークフロー間の依存性を作成できます。これにより、ワークフローが個別のトリガーで実行されるようになります。

ユーザーまたはアカウントに正常にリンクされているすべてのリコンシリエーション・イベントが、条件付きタスクからの単一トリガーを挿入します。ユーザー・プロファイルおよびアカウント・プロファイル内のすべてのデータが、これらの依存タスクのいずれかにアタッチされているアダプタで状況依存データとして使用できます。

関連項目:

条件付きタスク、アダプタおよび依存性の作成の詳細は、第III部「コネクタ」および第IV部「リクエストおよび承認プロセス」を参照してください。

23.5 リコンシリエーション・プロファイルの手動による更新

この項では、リコンシリエーション・プロファイルの手動による更新について、次の各項で説明します。

- リコンシリエーション・プロファイルの作成および更新

- プロファイル・モードの変更

23.5.1 リコンシリエーション・プロファイルの作成および更新

リソース・オブジェクトに基づいたリコンシリエーションでは、プロファイル名はリソース・オブジェクトの名前と同じです。たとえば、リソース・オブジェクト名がtestresourceとすると、デフォルトのプロファイル名もtestresourceになります。対応するリコンシリエーション・ステージング表の名前は、プロファイルで使用できます。リソースに多言語サポート(MLS)データが含まれる場合は、MLSステージング表名およびOracle Identity Manager表名もプロファイルで使用できます。リコンシリエーション・プロファイルの構造および要素の詳細は、表23-1「リコンシリエーション・プロファイルXMLの要素」を参照してください。

リソース・オブジェクトに子フォームが含まれる場合は、子フォームごとに、Oracle Identity Manager表名とステージング表名をプロファイルで使用できます。各ステージング表には、対応するエンティティ定義XMLファイルがあります(名前はステージング表名と同じでドットxml拡張子(.xml)が付き、MDSに格納されています)。

batch size属性など、リコンシリエーション・プロファイル内でなんらかの変更を行う場合は、手動により、またはDesign Consoleを使用してプロファイルを更新できます。リコンシリエーション・プロファイルを更新するには、次の手順を実行します。

注意:

Design Consoleを使用してリコンシリエーション・プロファイルを変更した場合は、Design Consoleのオブジェクト・リコンシリエーション・タブのリコンシリエーション・プロファイルの作成ボタンをクリックして、リコンシリエーション・プロファイルを再生成する必要があります。

1. MDSから/db/PROFILE_NAMEプロファイル・ドキュメントをエクスポートします。

2. XMLファイルを修正します。たとえば、バッチ・サイズの値を変更します。

3. configure属性の値をtrueに設定します。この属性の詳細は、表23-1「リコンシリエーション・プロファイルXMLの要素」を参照してください。

4. 更新したプロファイルをMDSにインポートします。MDSとの間のメタデータのエクスポートおよびインポートの詳細は、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。
これによって、ステージング表および対応するステージング表のエンティティ定義が自動的に更新されます。

23.5.2 プロファイル・モードの変更

次のいずれかの方法を使用して、プロファイル・モードのプロパティをCHANGELOGからREGULARに変更できます。

関連項目:

変更ログおよび定期リコンシリエーション・モードの詳細は、Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイドのリコンシリエーションのモードに関する項を参照してください。

- 次の例のように、プロファイルのchangeType属性の値を変更します。

<profile xmlns="http://www.oracle.com/oracle/iam/reconciliation/config" changeType="REGULAR" batchSize="500" resourceType="Organization" name="Xellerate Organization">

- 次の方法で、イベント作成時に属性を変更します。
Oracle Identity Manager 11gリリース2 (11.1.2.1.0)で導入されたイベント作成APIには、3つのパラメータが含まれています。最初の2つのパラメータは、以前の作成イベントAPIで使用されるパラメータと同じです。3番目のパラメータは、dateFormat、changeType、eventFinished、actionDateなどの属性を持つことができます。

このAPIを使用してchangeTypeを次のように設定できます。

public long createReconciliationEvent(String objName, Map<String, Object>inputData, EventAttributes eventAttribs);

注意:

APIを使用したchangeType属性の設定は、プロファイルで設定されたchangeType属性の値より優先されます。

23.6 リコンシリエーションAPIの理解

リコンシリエーションAPIは、単一値や複数値の属性データおよびその他の機能でリコンシリエーション・イベントを作成するために使用できる一連の公開APIです。

リコンシリエーション・コネクタの開発者は、これらのAPIを使用して、リコンシリエーション・イベント・リポジトリにデータをプッシュする必要があります。

関連項目:

Oracle Identity ManagerでのAPIの使用の詳細は、第31章「APIの使用」を参照してください。

これらのAPIのほとんどが、以前のバージョンのOracle Identity Managerに存在していました。ただし、11gリリース2 (11.1.2.1.0)では、実装が変更され、このリリースで導入された新しいリコンシリエーション・アーキテクチャに基づいています。

以前のAPIが引き続きサポートされているため、既存の標準コネクタでもこれらのAPIが使用され、これらのコネクタに対する変更は必要ありません。

callingEndOfJobAPIは、11gリリース2 (11.1.2.1.0)における唯一の新しいリコンシリエーションAPIです。

コネクタの各実行は、ジョブと呼ばれます。11gリリース2 (11.1.2.1.0)では、リコンシリエーション・イベントはリコンシリエーション・エンジンにバッチ送信されます。ジョブが終了すると、(コネクタのスケジュール済タスクを実行する)スケジューラはリスナーを実行し、リスナーはcallingEndOfJOBAPIを呼び出します。このAPIは、すべてのオープン・バッチを処理のためにリコンシリエーション・エンジンに送信します。

このAPIコールは、多言語サポート(MLS)データと非MLSデータで類似しています。コネクタは、HashMapとしてリコンサイルされるデータを渡します。相違点は、属性がMLS対応である場合、キーが属性名で、値がMLSデータの別のHashMapであることです。このMLS固有のHashMapのキーは言語コードで、値はターゲット・システムから取得された対応するロケール固有データです。定義されたロケールがないMLSデータがターゲット・システムに存在する場合、そのデータはMLS入力データHashMapでキーbaseを使用して渡されます。

23.6.1 ReconOperationsService API

oracle.iam.reconciliation.api.ReconOperationsServiceのAPIには、次のタスクが必要です。

- イベントの無視

- イベントの作成(単一/バルク)

- プロセス・イベント

- 削除の検出

関連項目:

oracle.iam.reconciliation.api.ReconOperationsServiceのAPIの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

優先APIとそのAPI呼出しの順序は、次のとおりです。

1. イベントの無視: Oracle Identity Managerにすでに存在するイベント作成やターゲット・システム・データの処理を回避する方法です。API呼出しは次のようになります。

boolean ignoreEvent(String resourceObjectName, Map inputData, String dateFormat) throws tcObjectNotFoundException, tcAPIException

このAPIを使用して、指定されたオブジェクトに対してリコンシリエーション作成イベントを要求する必要があるかどうかが検証されます。このAPIによりtrueが返されると、イベント作成をスキップでき、データベースに追加のイベント作成が保存されます。

ignoreEvent API同様、ignoreEventAttributeDataメソッドを使用して、ターゲット・システムから入力される単一値および複数値のデータに対してリコンシリエーション作成イベント・フローを要求する必要があるかどうかが検証されます。このリリースでこのようなデータがあるのは、アカウント・エンティティ・タイプに限られます。APIは次のようになります。

boolean ignoreEventAttributeData(String resourceObjectName, Map inputData, String multiValueFieldName, Map[] childDataList, String dateFormat) throws tcAPIException, tcObjectNotFoundException

注意:

ignoreEventまたはignoreEventAttributeDataが呼び出される必要があります。APIはどちらも呼出しに必要ありません。

2. イベントの作成: 単一イベント作成APIまたはバルク・イベント作成APIを使用して実行できます。このフローにより、ターゲット・システム・データがステージング表に簡単に格納されます。このデータの処理は後で非同期に行われます。
イベントの作成(単一): 次のAPIで構成されています。

- createReconciliationEventメソッド。リコンシリエーション・イベントを作成するためのデータを指定します。子データまたは複数値のデータがある場合は、eventAttribs.eventFinishedフラグの値をfalseに設定します。それ以外の場合は、値をtrueに設定します。作成されたイベントのeventIdが返されます。

long createReconciliationEvent(String resourceObjectName, Map<String, Object> inputData, EventAttributes eventAttribs)

- addMultiAttributeDataメソッド。子データを指定します。子データがない場合、またはeventAttribs.eventFinishedフラグがtrueに設定されている場合は、こをAPIを呼び出すことはできません。

long addMultiAttributeData(long eventId, String resourceObjectName, Map inputData) throws tcAPIException, tcEventNotFoundException, tcEventDataReceivedException, tcAttributeNotFoundException

注意:

バルク複数値属性または単一の子レコードではなく複数の子レコードのデータを使用して性能を向上するために、次のAPIを使用します。

void addDirectBulkMultiAttributeData(long reconciliationEventKey, long reconciliationAttributeKey, String tableFieldName, List dataList,String dateFormat) throws tcAPIException, tcEventNotFoundException, tcAttributeNotFoundException, tcEventDataReceivedException,tcInvalidAttributeException

- providingAllMultiAttributeDataメソッド。指定される複数値のデータがデータの完全リストであるかまたは追加/更新された変更セットのみであるかを指定します。デフォルトでは、allDataFlagの値はfalseです。子データがない場合、またはeventAttribs.eventFinishedフラグがtrueに設定されている場合は、こをAPIを呼び出すことはできません。

void providingAllMultiAttributeData(long eventId, String resourceObjectName, boolean allDataFlag) throws tcAPIException

- finishReconciliationEventメソッド。イベント作成フローの最後にマークを付けます。特定のイベント・ステータスがデータを受信しましたに更新されます。これは、子データ(あれば)を含むすべての特定イベントのデータが指定されたことを意味します。eventAttribs.eventFinishedフラグがtrueに設定されている場合は、このAPIを呼び出すことはできません。

void finishReconciliationEvent(long eventId) throws tcAPIException, tcEventNotFoundException, tcEventDataReceivedException

- callingEndOfJobAPIメソッド。ジョブ内のすべてのリコンシリエーション・バッチを処理します。スケジュール済ジョブの場合、ジョブ終了時にこのAPIが自動的に呼び出されます。このAPIは、非スケジュール済ジョブのAPI呼出しに対して明示的に呼び出される必要があります。

void callingEndOfJobAPI() throws tcAPIException

イベントの作成(バルク): 次のAPIで構成されています。

ReconciliationResult createReconciliationEvents(BatchAttributes batchAttribs, InputData... input)

これは、バルク作成APIです。入力データに渡されたデータのバルク・リコンシリエーション・イベントを作成します。複数値属性を含むすべてのデータを確定し、データのサイズがバッチ・サイズ以下の場合に1パッチとして処理するために送信します。それ以外の場合は、複数バッチのデータを送信します。これ以降、他のAPIを呼び出す必要はありません。

3. プロセス・イベント: 作成済イベントのバックエンド処理を強制する方法です。processReconciliationEvent(eventId) APIは、作成イベント・フローの完了後に呼び出されます。作成済イベントにも同様の処理が必要です。このAPIは特定のイベントのみ処理するため、バッチ・ステータスまたはジョブ・ステータスは更新されません。バッチ・ステータスも同様に更新する必要がある場合は、この後callingEndOfJobAPI APIを呼び出します。このAPIはバッチ処理ではなくデータを1つずつ同期処理するため、このAPIの使用はお薦めしません。

4. 削除の検出: ターゲット・システムに存在しないOracle Identity Managerでの余分なデータを削除する方法です。次のAPIで構成されています。

- provideDeletionDetectionDataメソッド。リソース・オブジェクトの既存のターゲット・システム・データのリストをすべて入力データとして受け取り、Oracle Identity Managerで見つかった一致データのリストを返します。

Set provideDeletionDetectionData(String resourceObjectName, Map[] inputData) throws tcAPIException, tcIDNotFoundException, tcMultipleMatchesFoundException

- getMissingAccountsメソッド。Oracle Identity Managerで確認済データのリスト・キーを受け取り、ターゲット・システムではなくOracle Identity Managerにある追加データのリストを返します。Oracle Identity Managerのすべてのキーを検索し、provideDeletionDetectionDataメソッドにより返された設定にあるキーと比較します。

Thor.API.tcResultSet getMissingAccounts(String objectName, Set accountsFound) throws tcAPIException, tcIDNotFoundException, tcDataNotProvidedException

- deleteDetectedAccountsメソッド。Oracle Identity Managerでのみ見つかったデータのリストを入力データとして受け取り、削除タイプの作成リコンシリエーション・イベントAPIコールを1つずつ呼び出します。getMissingAccountsメソッドにより返されたtcResultSetは、このAPIにパラメータとして渡されます。

long[] deleteDetectedAccounts(Thor.API.tcResultSet poDetectedAccounts) throws tcAPIException, tcAPIException

23.6.2 マルチスレッド環境における非スケジュール済タスクベース・リコンシリエーションの呼出し

例23-2に、マルチスレッド環境で非スケジュール済タスクベース・リコンシリエーションを呼び出すサンプル・コードを示します。

例23-2 マルチスレッド環境における非スケジュール済タスクベース・リコンシリエーションの呼出し

public class UserNonSTBasedRecon{

private AtomicInteger threadCount =new AtomicInteger(0);

@Test
public void testCreateUsersUsingNonScheduleTaskConnectorWithThreads() throws Exception {

Thread t = new CreateEvent();
t.start();
Thread t2 = new CreateEvent();
t2.start();

while (true) {
Thread.currentThread().sleep(5000);
if (threadCount.get() == 2){
ReconOperationsService reconServ = getService(ReconOperationsService.class);
reconServ.callingEndOfJobAPI();
break;
}
}
}

public class CreateEvent extends Thread {

Override
public void run() {

String ctxFactory = "weblogic.jndi.WLInitialContextFactory";
OIMProfileReader reader = new OIMProfileReader();
String appServerType = reader.getString("appserver.type");
String hostName = reader.getString("weblogic.host");
String port = reader.getString("weblogic.port");
String serverURL = "t3://" + hostName + ":" + port;
System.out.println("Server URL is : " + serverURL);
System.out.println("Context Factory is : " + ctxFactory);
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(OIMClient.JAVA_NAMING_PROVIDER_URL, serverURL);
env.put(OIMClient.JAVA_NAMING_FACTORY_INITIAL, ctxFactory);

OIMClient client = new OIMClient(env);
String username = "xelsysadm";
String password = "Welcome1";
try {
client.login(username , password.toCharArray());
} catch (LoginException e1) {
throw new SuperRuntimeException(e1.getMessage(), e1);
}

String uniq2 = getRandomLong(10000).toString();
long jobId = getRandomLong(10000);
ContextManager.setValue(Constants.JOB_HISTORY_ID, new ContextAwareNumber(jobId));
ContextManager.setValue(Constants.JOB_NAME_CONTEXT, new ContextAwareString(jobId +""));
ReconOperationsService recon;
try {
recon = getService(ReconOperationsService.class);
int count = 50;
HashMap<String, String> hm = new HashMap<String, String>();
ArrayList<Long> eventKeys = new ArrayList<Long>();
for (int i = 0; i < count; i++) {
hm.put("UserLogin", uniq2 + "ThreadTest" + i);
hm.put("FirstName", uniq2 + "Thread" + i);
hm.put("lastname", "Test");
hm.put("Type", "End-User");
hm.put("OrganizationName", "Xellerate Users");
hm.put("EmpType", "Full-Time");
hm.put("Middlename", "MID");
System.out.println("Creating Recon event i ="+ i);
long rceKey = recon.createReconciliationEvent("Xellerate User", hm, true);
eventKeys.add(rceKey);
}
assertEquals(count, eventKeys.size());
} catch (Exception e) {
throw new SuperRuntimeException(e.getMessage(), e);
} finally {
threadCount.set(threadCount.get()+1);
ContextManager.popContext();
}
}
}
}

23.7 信頼できるリコンシリエーションの後処理

信頼できるリコンシリエーションにユーザー・ログインが渡されない場合は、ログイン・ハンドラがユーザー・ログインを生成します。パスワードは、後処理イベント・ハンドラで生成されます。このことを示す通知を送信するようにOracle Identity Managerを構成できます。

通知は、Recon.SEND_NOTIFICATIONシステム・プロパティの値がtrueに設定されている場合にのみ送信されます。Recon.SEND_NOTIFICATIONシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する説明を参照してください。

SSOが無効な環境では、リコンシリエーションを介したユーザー作成の場合、ユーザー・ログインとパスワードの両方が後処理ハンドラで生成され、単一の通知がユーザー・ログインとパスワードの両方に送信されます。

SSOが有効な環境では、パスワードは生成されないため、ログインが後処理ハンドラで生成されると、通知はユーザー・ログインに対してのみ送信されます。

23.8 リコンシリエーションのトラブルシューティング

リコンシリエーションに関連する問題をトラブルシューティングする前に、リコンシリエーション・ロギング・レベルをINFOに変更します。これを行うには、Oracle Enterprise Managerを使用して次のロガーを追加します。

- 名前: oracle.iam.reconciliation

- Oracle Diagnostic Loggingレベル(Javaレベル): NOTIFICATION:1(INFO)

ロガーを追加する手順の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のロギングの構成に関する項を参照してください。

注意:

ロギング・レベルを変更するために、/domains/DOMAIN_NAME/config/fmwconfig/servers/OIM_SERVER/logging.xmlファイルを変更することもできます。これを行うには、次の手順を実行します。

1. 次に示すように、logging.xmlファイルに新しいロガーを追加します。

<LOGGER NAME="oracle.iam.reconciliation" LEVEL="INFO"/>

2. 'console-handler' log_handlerのロギング・レベルをINFOに変更します。

3. Oracle Identity Managerを再起動します。

この項では、リコンシリエーション問題のトラブルシューティングについて次の各項で説明します。

- 一般的なリコンシリエーション問題のトラブルシューティング

- データベース関連のリコンシリエーション問題のトラブルシューティング

- リコンシリエーション・プロファイル構成の失敗のトラブルシューティング

23.8.1 一般的なリコンシリエーション問題のトラブルシューティング

表23-5に、リコンシリエーション・エラーが発生した場合に実行できるトラブルシューティング手順を示します。

表23-5 リコンシリエーションのトラブルシューティング

問題

解決策

イベント処理での失敗

エラーの詳細は、リコンシリエーション表から次のように取得できます。

- バッチ処理の場合、例外はRECON_BATCHES.RB_NOTE列に格納されています。

- 単一イベントの処理の場合、例外はRECON_EVENTS.RE_NOTE列に格納されています。

カーネル編成ハンドラで発生した失敗

編成IDは、リコンシリエーション表で追跡でき、この表をさらに使用して、次のように関連ハンドラのステータスを確認できます。

- バッチ処理の場合、後処理のみの編成IDをRECON_BATCHES.RB_NOTE列から読み取ることができます。

- 単一イベントの処理の場合、エンドツーエンド編成IDをRECON_EVENTS.RE_NOTE列から読み取ることができます。

リコンシリエーション時にLDAP同期を表示するUIはありません。したがって、LDAPの成功または失敗は、RB_NOTE/RE_NOTE列で使用可能なIDに基づいて、編成内のLDAP同期イベント・ハンドラのステータスを確認することによってのみ追跡できます。

ジョブの実行後、多数のイベントが「データを受信しました」ステータスになる

次の文を使用して、関連するバッチが処理の準備完了ステータスであるかどうかを確認します。

select rb_batch_status, rb_note from recon_batches where rb_batch_status = 'Ready For Processing' and rj_key = JOB_ID_ON_UI

また、RECON_BATCHES.RB_NOTEには、接続の問題などの一般的な例外が含まれています。問題を修正し、次のいずれかを実行します。

- 多数のデータがある場合は、リコンシリエーション・ジョブを返します。

- このような失敗したバッチを手動で再試行するために提供されているスケジュール済タスク、「リコンシリエーション・バッチの再試行」があります。これは、特定のバッチの再試行にのみ使用できます。カンマ区切りの複数のバッチがサポートされています。このスケジュール済タスクに関連付けられている事前定義済ジョブはありません。必要に応じて、ジョブを作成できます。

競合状態: 一部の依存属性がまだリコンサイルされていないため(ユーザーより先にユーザーのマネージャ/組織をリコンサイルする必要があるなど)、イベントが失敗ステータスにある

- データのサイズが小さい場合は、リコンシリエーションを再試行すると自動的に競合状態が処理されますが、低速です。

- データのサイズが大きい場合は、リコンシリエーションを2回実行します。1回目の完全リコンシリエーションで依存フィールドのマッピングを削除し、次に依存フィールド・マッピングを追加してから2回目の完全リコンシリエーションを実行します。

信頼できるソースのリコンシリエーションの場合にユーザー更新を実行すると、次のエラーが生成される

ORA Error Code =>ORA-00001: unique constraint (.) violated

信頼できるソースのリコンシリエーションでは、一致ルールがUsr_loginに基づいている場合、その一致ルールでは大文字/小文字が区別されていないことが必要です。そうでないと、ユーザーの更新がユーザーの作成として機能し、エラーが生成される場合があります。

23.8.2 データベース関連のリコンシリエーション問題のトラブルシューティング

この項では、次のデータベース関連のリコンシリエーション問題について説明します。

Oracle Database 11gリリース1の重要な個別パッチの欠落

RDBMS個別パッチ# 7614692が欠落している場合は、次のエラーがログに記録されます。

ORA-02291: INTEGRITY CONSTRAINT (FK_RECON_EVENTS_USR) VIOLATED - PARENT KEY NOT FOUND
[EXEC] ORA-06512: AT "OIM_SP_RECONBLKUSERCRUD"
[EXEC] ORA-06512: AT "OIM_SP_RECONBLKUSRMLSWRAPPER"
[EXEC] ORA-06512:

この問題を解決するには、次のパッチがOracle Database 11gリリース1 (11.1.0.7.0)にインストールされている必要があります。

- p7614692_111070

- p7000281_111070

- p8327137_111070

- p8617824_111070

注意:

次のURLからすべての個別パッチをダウンロードできます。

http://support.oracle.com

Oracle Database 11gリリース2の重要な個別パッチの欠落

一部のSQLスクリプトを実行すると、Oracle Database 11gリリース2 (11.2.0.2.0)で誤った結果または矛盾した結果が生成される場合があり、これは以前のリリースのOracle Databaseでは発生しませんでした。

この問題を解決するには、Oracle Database 11gリリース2用のパッチ# 10259620がインストールされている必要があります。

低速なリコンシリエーションおよびエラー・ログ内の類似トレース

SQLスクリプトに大量の一致ルールがある場合、エンティティ表が低速になるのは、データベースでの全表スキャンや最適化されていないSQL計画が原因であると考えられます。

リコンシリエーションは、一致ルールの列が適切に索引付けされていなかったり、スキーマ統計が古いと、低速になる場合があります。低速の結果として、次のようなエラー・ログが記録されます。

oracle.iam.platform.utils.SuperRuntimeException: java.sql.SQLException:
ORA-01013: user requested cancel of current operation
ORA-06512: at "XL_SP_RECONBLKROLEMATCH"
ORA-06512: at "OIM_SP_RECONBLKROLEMLSWRAPPER"
ORA-06512:

at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkMana gerImpl.java)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java)
at weblogic.work.ExecuteThread.run(ExecuteThread.java)
Caused by: java.sql.SQLException: ORA-01013: user requested cancel of current operation
ORA-06512: at "XL_SP_RECONBLKROLEMATCH"
ORA-06512: at "OIM_SP_RECONBLKROLEMLSWRAPPER"
ORA-06512:
.
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java)

この問題の解決方法:

1. 一致ルールの列に対して適切な索引がすべて作成されていることを確認します。

2. データベースのスキーマ統計がガイドラインに従って収集されていることを確認します。

関連項目:

リコンシリエーション用の索引の作成およびデータベース統計の収集の詳細は、「リコンシリエーションのベスト・プラクティス」を参照してください。

23.8.3 リコンシリエーション・プロファイル構成の失敗のトラブルシューティング

プロファイル構成の失敗に関連する問題が発生した場合、Oracle Enterprise Managerで使用可能なvalidateProfile Mbeanを使用してプロファイルを検証します。プロファイルが無効である場合、プロファイルとともにそのプロファイルが無効である理由が表示されます。

表23-6に、リコンシリエーション・エラーが発生した場合に実行できるトラブルシューティング手順を示します。

表23-6 リコンシリエーション・プロファイル構成の失敗のトラブルシューティング

問題

解決策

プロファイルが無効なため、次の例外でロードに失敗します。

oracle.iam.reconciliation.exception.ConfigNotFoundExceptionまたは

oracle.iam.reconciliation.exception.Configおよび内部例外org.xml.sax.SAXParseException

次のいずれかを実行します。

- 正確な問題は、スキーマ検証メッセージを確認することによって診断および修正できます。

- Oracle Enterprise ManagerのMBeanまたは診断ダッシュボードの「リコンシリエーション・プロファイルの検証」テストを使用して、リコンシリエーション・プロファイルXMLを検証します。

- プロファイルおよびXSDをXMLスキーマ対応のエディタにインポートしてリコンシリエーション・プロファイルを検証し、このエディタでそのスキーマに対して検証すると、失敗の正確な原因が示される可能性があります。

有効なリコンシリエーション・プロファイルXMLをシステムにインポートする際に、必要な構成の作成に失敗します。

profile.configure属性を確認します。この属性の値は、trueである必要があります。

profile.active属性を確認します。これの値は、trueである必要があります。または、この属性が存在しない場合、profile.activeがtrueであることを意味します。

次のエラーが生成されます。

oracle.iam.reconciliation.exception.ReconciliationException: Exception occurred while inserting data into table STAGING_TABLE_NAME due to STAGING_TABLE_NAME

これは、有効なリコンシリエーション・プロファイルがロードされており、このプロファイルによってOracle Identity Managerで構成が作成されていないことを意味します。

profile.configure属性およびprofile.active属性を確認します。

注意:

validateProfile Mbeanはリコンシリエーション・プロファイルの検証のために用意されています。このMBeanは、Oracle Enterprise Managerを使用してアクセスできます。

23.9 RECON_EXCEPTIONS表へデータ移入

Oracle Identity Managerデータベース内のRECON_EXCEPTIONS表は、アカウント・リコンシリエーション中に生成されるエラー・メッセージを取得するために使用されます。このデータは、レポートの生成目的で収集されます。

関連項目:

アカウント・リコンシリエーションの詳細は、Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイドのアカウント・リコンシリエーションに関する項を参照してください。

リコンシリエーションが削除されたユーザーに一致することが検出された場合は、USER_DELETEDをREX_EXCEPTION列に、削除されたユーザーのキーをRECON_EXCEPTIONS表のUSR_KEY列に挿入する必要があります。

一致が検出されなかった場合は、USER_NOT_FOUNDをREX_EXCEPTION列に挿入します。

アカウント一致が検出された場合は、アカウントがすでにプロビジョニング解除されているかどうかチェックします。それからプロビジョニングされるユーザーに対して、RECON_EXCEPTIONS表のREX_EXCEPTION列に値RESOURCE_DEPROVISIONEDを挿入します。

RECON_EXEPTIONS表に例外データを移入するには:

1. 変更タイプ!= ('Modify' , 'Delete')でイベント・ステータスが('Single User Match Found', 'Single Org Match Found')のイベントをすべてフェッチします。

2. 次の手順を実行して、エンティティに対してリソース・オブジェクトをプロビジョニングします。

1. RECON_EXCEPTION DB表から例外データを収集します。これを行うには、次のいずれかを実行します。

- XL.EnableExceptionReportsプロパティの値がTRUEかどうかをチェックします。これがTRUEに設定されている場合は、次のステップに進みます。そうでない場合は、例外データを収集しないでください。

- プロビジョニングされたリソース・オブジェクトに対してobj表のobj_initial_recon_dateを選択し、今日の日付以前かどうかチェックします。以前の日付が表示される場合は、次のステップに進みます。そうでない場合は、例外データを収集しないでください。

2. リソース・オブジェクトをユーザーにプロビジョニングするときには、Oracle Identity Managerでリソース・オブジェクトがすでにプロビジョニング解除されているかどうかチェックします。:

- リソース・オブジェクトがすでにプロビジョニング解除されている場合は、プロビジョニングされるユーザーに対して、RECON_EXCEPTIONS表のREX_EXCEPTION列に値RESOURCE_DEPROVISIONEDを挿入します。

- リソース・オブジェクトがプロビジョニング解除されていない場合は、プロビジョニングされるユーザーに対して、RECON_EXCEPTIONS表のREX_EXCEPTION列に値RESOURCE_NEVER_PROVISIONEDを挿入します。

23.10 リコンシリエーションのベスト・プラクティス

この項では、コネクタ表およびリコンシリエーション表に必要な索引を指定してパフォーマンスを向上させる方法について説明します。内容は次のとおりです。

- 照合モジュールの追加の索引要件

- リコンシリエーション・パフォーマンスに関するデータベース・スキーマ統計の収集

注意:

効率的な重複権限または子データ検証を有効にするように、リコンシリエーション・フィールド・マッピングの子データの権限属性およびキー属性の両方を構成することをお薦めします。権限または子データの重複検証の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の権限または子データの重複検証に関する説明を参照してください。

23.10.1 照合モジュールの追加の索引要件

Oracle Identity Managerをインストールすると、必要な索引がOracle Identity Managerデータベース・スキーマに作成されます。ただし、Oracle Identity Managerのいくつかの機能の動的な性質のために、追加の索引が必要になる場合があります。これは、特にリコンシリエーションに当てはまります。

リコンシリエーションでは、照合アルゴリズムを使用して、変更がリクエストされたユーザー、アカウント、ロールまたは組織がOracle Identity Managerにすでに存在するかどうかが検索されます。照合アルゴリズムでは、Oracle Identity Managerの一連の列のデータとターゲット水平表の列のデータが比較されます。一致ルールを格納する列は、リコンシリエーション・プロファイルに定義されます。照合操作のパフォーマンスを迅速に改善するためには、照合ルールの列に正しい索引が作成されている必要があります。

適切な索引を識別する推奨方法を示すために、メタデータ・ストア(MDS)リポジトリに存在するサンプルActive Directory (ADUser)プロファイルを例として取り上げます。

リコンシリエーションに対する索引の選択

一致ルール基準に基づいて索引を選択するには、次の手順を実行します。

1. テキスト・エディタでADプロファイル・ファイルを開きます。

注意:

「ユーザーが修正可能なメタデータ・ファイルの移行」の説明に従い、Oracle Enterprise Managerを使用してADユーザー・プロファイルをMDSからインポートする必要があります。

2. 図23-3に示すように、ADプロファイル内のすべての<matchingRule>タグ要素を検索します。

図23-3 <matchingRule>タグ要素

3. それぞれの一致ルールを構成する列を識別した後は、それに応じて索引を作成します。

注意:

- キー・フィールドがOracle Identity Managerで大/小文字を区別しないように定義されている場合は、そのキー・フィールドに対して関数ベースの索引を作成する必要があります。たとえば、コネクタ・コードで姓名の名の検索を内部的に実行する場合(FIRST_NAMEがキーの場合)は、適切な索引付けが必要です。

- ユーザーの参照で複数のキーまたはコンポジット・キーが使用される場合は、個々の索引またはコンポジット索引を選択します。

- 必要な索引のポインタは、Oracle Enterprise Managerなどのパフォーマンス・モニタリング・ツールを使用するか、またはOracle Database 11gで使用可能な自動ワークロード・リポジトリ(AWR)のレポートを介して、データベース側からリコンシリエーション・プロセスのリアルタイム実行を監視することで取得することもできます。

- Design Consoleまたはデプロイメント・マネージャのインポート経由で作成または更新されたプロファイルについては、索引の作成がある程度自動化されています。この自動的に作成された索引を、この項で定義されているルールごとに検証します。問題がある場合は、索引を手動で修正する必要があります。手動で作成または更新されたプロファイルについては、索引は自動的に作成されず、手動で作成する必要があります。また、「一致ルール」フィールドが変更された場合、索引は自動的には削除されません。索引の削除は手動で行う必要があります。

- 既存の索引の一覧は、validateProfile Mbeanを使用してOracle Enterprise Managerで表示できます。

23.10.2 リコンシリエーション・パフォーマンスに関するデータベース・スキーマ統計の収集

データベース統計は、SQL問合せの実行時にOracleオプティマイザが最適な計画を選択するために不可欠な情報です。Oracle Identity Managerスキーマの統計は、定期的に収集することをお薦めします。Oracle Identity Manager 11g リリース2 (11.1.2.1.0)では、リコンシリエーション・プロセスに多数のデータベースSQL機能が使用されるため、スキーマ統計が更新されていることを確認してからリコンシリエーションを実行してください。

注意:

- DBMS_STATS.GATHER_SCHEMA_STATS APIでは、環境、データ・プロファイル、Oracle DBエディションおよび基礎となるハードウェア機能に基づいて、他のオプション(DEGREE、ESTIMATE_PERCENTなど)を必要に応じて使用できます。

- データベース・スキーマ統計の収集の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのデータベース・パフォーマンスの監視に関する項を参照してください。

また、Oracle Identity Managerリコンシリエーション・プロセスは、データ量が多く、大量のデータが高速で移動するため、データベース統計によって基礎となるデータが正確に表現される必要があります。そのためには、次のガイドラインを参考にしてください。

- 統計が、Oracle Identity Managerスキーマの新規の設定のリコンシリエーション、または既存のデータがない(あるとしてもわずかな)少量のリコンシリエーションを対象として収集されるようにします。Oracle Identity Managerの関連する表の最大行数は、100から1000までの行にする必要があります。表の例には、信頼できるソース・リコンシリエーションのUSR表や、ターゲット・リソースのリコンシリエーションの親アカウント表があります。

- 20000を超えるユーザーやアカウントなど、大量のデータの移動が予想されるリコンシリエーションが開始した後も、統計が適切な表現のデータ配信になるために、次のようにしてOracle Identity Managerスキーマ統計を収集してください。

1. リコンシリエーションが正常に開始して、しばらく実行されていた場合にのみ、初期コレクション後の統計を収集するように計画します。これを確認するには、信頼できるソース・リコンシリエーションのUSR表や、ターゲット・リソースのリコンシリエーションの親アカウント(UD_*)表など、Oracle Identity Managerスキーマで主要な複数の表の件数をチェックします。

2. リコンシリエーションによってUSR表または親アカウント表で約20000から25000行が移動した後で、統計を収集します。

注意:

- 統計は、リコンシリエーションの実行と同時に収集できます。

- ガイドラインに指定されている行数は例であり、収集する統計に応じて別の行数にできます。

- 統計を収集した後、パフォーマンスは即時には改善されない可能性があります。ただし、Oracle Databaseの共有プールから以前のSQL計画が消去され、さらに効率的な新しい計画が作成されるに従って、パフォーマンスは向上します。

23.11 DMSを使用したリコンシリエーション・パフォーマンスの監視

ダイナミック・モニタリング・サービス(DMS)コマンドは、パフォーマンス・メトリックの表示およびイベント・トレースの構成に使用します。次のDMSメトリックは、リコンシリエーション・パフォーマンスの監視に適しています。

- OIM_ScheduledJob: 特定のスケジュール済ジョブの実行にかかった時間です。

- リコンシリエーション・サービス(ReconOperationsServiceまたはtcReconciliationOpIntf): リコンシリエーション・サービスでイベントを作成するために各APIでかかった時間です。コネクタのスループットは、「スケジュール済ジョブ時間の合計 - イベントの作成にかかった合計時間」で計算できます。

- OIM_JMS: ActionTaskは、実際のリコンシリエーション処理(ストアド・プロシージャ)時間に関する情報を提供します。OrchestrationAsyncTaskは、オーケストレーションの後処理全体についての情報を提供します。XLAuditMessageは、実際の監査処理についての情報を提供します。

- OIM_EventHandlers: オーケストレーション内の各イベント・ハンドラにかかった時間です。

- DMSダンプ: パフォーマンスおよび機能の問題を解決できない場合、分析のためにDMSダンプを提出する必要があります。コマンドは次のとおりです。

${mwhome}/oracle_common/common/bin/wlst>>dms.log
Connect('adminusername','adminpassword');
dumpMetrics(format='xml');
Exit();

このコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「DMSカスタムWLSTコマンド」のdumpMetricsに関する項を参照してください。

24 バルク・ロード・ユーティリティの使用

Oracle Identity Managerは、組織内で多数あるエンティティ・データのリポジトリの1つである場合があります。Oracle Identity Managerの使用を開始するとき、他のリポジトリのデータをOracle Identity Managerにロードすることが必要になる場合があります。バルク・ロード・ユーティリティは、このような要件の解決策となります。

バルク・ロード・ユーティリティは、大量のデータをOracle Identity Managerにロードするプロセスを自動化することを目的としています。データのロードに必要な停止時間の短縮に役立ちます。このユーティリティは、Oracle Identity Managerのインストール後に使用することも、Oracle Identity Managerの本番期間中に随時使用することもできます。バルク・ロード・ユーティリティでは、ユーザー、アカウント、ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロードを実行します。

このドキュメントの内容は次のとおりです。

- バルク・ロード・ユーティリティの機能

- バルク・ロード・ユーティリティ実行の前提条件

- ユーティリティの実行

- OIMユーザー・データのロード

- アカウント・データのロード

- ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロード

- 操作中に記録されるデータ

- バルク・ロード操作からの診断データの収集

- バルク・ロード操作後のクリーンアップ

24.1 バルク・ロード・ユーティリティの機能

バルク・ロード・ユーティリティの機能は次のとおりです。

- このユーティリティは、Oracle Identity Managerリリース9.1.0以上と互換性があります。

- データは、OIMユーザー、OIMユーザーに割り当てられた(プロビジョニングされた)アカウント、ロール、ロール階層、ロール・メンバーシップまたはロール・カテゴリとして、Oracle Identity Managerにロードできます。

- データは、1つまたは複数のCSVファイル、または1つのデータベース表からロードできます。Oracle Identity Managerにインポートされたデータは、OIMユーザー、OIMユーザーにプロビジョニングされたアカウント、ロール、ロール階層、ロール・メンバーシップまたはロール・カテゴリに自動的に変換されます。

- データは、1つまたは複数の信頼できるソースからロードできます。

- データは、空のOracle Identity Managerリポジトリ、またはすでにOIMユーザーおよびリソースに関するデータが含まれているOracle Identity Managerリポジトリにロードできます。つまり、ユーザー・データは、Oracle Identity Managerのインストール直後か、またはシステムがすでに本番状態にある場合にいつでもロードできます。

- ユーザー・データのロード中に生成された例外は処理され、プロセスのロードに失敗したレコードはロードを再試行できます。

- ユーザーのバルク・ロード操作後に、監査スナップショットを生成できます。

- 操作中にはダミー・パスワードが使用されるため、OIMユーザー・データのバルク・ロード後、最初のログイン時にパスワードの変更を要求されます。

注意:

このユーティリティはユーザー属性の暗号化に使用できません。つまり、Oracle Identity Managerでユーザー・フィールドが暗号化されている場合、このユーティリティを使用して、そのフィールドにロードされたデータを暗号化することはできません。

24.2 バルク・ロード・ユーティリティ実行の前提条件

バルク・ロード・ユーティリティの実行の前提条件は次のとおりです。

- バルク・ロード・ユーティリティのインストール

- バルク・ロード操作用のデータベースの準備

24.2.1 バルク・ロード・ユーティリティのインストール

このユーティリティをインストールするには、次の手順を実行します。

1. インストール・パッケージの次のディレクトリを圧縮し、Oracle Identity Managerデータベース・ホスト・コンピュータ上のディレクトリにコピーします。
MIDDLEWARE_HOME/Oracle_IDM1/server/db/oim/oracle/Utilities/oimbulkload

注意:

ユーティリティは、リモート・ホストから実行できます。Oracle Identity Managerデータベース・ホストのディレクトリからこのユーティリティを実行することは、必須ではありません。

ユーティリティをMIDDLEWARE_HOME/Oracle_IDM1/server/db/oim/oracle/Utilities/oimbulkload/ディレクトリから直接実行することもできます。

2. ZIPファイルの内容を抽出します。
ZIPファイルの内容を抽出すると、oimbulkloadディレクトリが作成されます。このディレクトリ内に、次のディレクトリが作成されます。

- sqls: このディレクトリには、バルク・ロード操作中に使用されるSQLスクリプトが含まれています。

- scripts: このディレクトリには、バルク・ロード操作中に使用される.shスクリプトと.batスクリプトが含まれています。

- csv_files: 入力ソースとして1つまたは複数のCSVファイルを使用する場合、CSVファイルはこのディレクトリに格納する必要があります。

- lib: このディレクトリには、oimBulkLoad.jarファイルが含まれています。

- sample_data: このディレクトリには、次のサンプルCSVファイルが含まれています。

- OIMユーザーのロード操作の場合:
master.txt

OIDusers.csv

HRusers.csv

- アカウントのロード操作の場合:
parentAD.csv

childAD.csv

- ロールに関連したロード操作の場合:
Role.csv(ロール・ロード)

Rolec.csv(ロール・カテゴリ)

Roleh.csv(ロール階層)

Rolem.csv(ロール・メンバーシップ)

- Logs_ YYYYMMDD_hhmi: このログ・ディレクトリには、バルク・ロード操作のサマリーが格納されるログ・ファイルが含まれています。このディレクトリは実行時に作成されます。

次の項では、ユーティリティおよびバルク・ロード操作の詳細を説明します。

- ユーティリティを構成するスクリプト

- バルク・ロード操作中に使用される一時表

- ユーティリティで提供されるオプション

24.2.1.1 ユーティリティを構成するスクリプト

ユーティリティを構成する主なスクリプトは次のとおりです。

- oim_blkld.bat and oim_blkld.sh
このスクリプトには、バルク・ロード操作を実行するためのコードが含まれています。このスクリプトを実行すると、他のスクリプトやストアド・プロシージャがコールされます。

- oim_blkld_setup.sql
このスクリプトは、Oracle Identity Manager表領域にデータファイルを追加するために使用されます。詳細は、このドキュメントの「Oracle Identity Manager表領域でのデータファイルの作成」で説明します。

24.2.1.2 バルク・ロード操作中に使用される一時表

バルク・ロード操作中には、次の一時表が使用されます。

- OIM_BLKLD_TMP_SUFFIX
入力ソースとしてCSVファイルを使用する場合、ユーティリティによってOIM_BLKLD_TMP_SUFFIX表が自動的に作成され、最初にCSVファイルのデータがこの表にロードされます。表名の接尾辞は、次のように決定されます。

- ファイル名の最初の6文字が考慮されます。

- 最初の6文字を判断する際には、ファイル名の特殊文字およびファイル拡張子(.csv)は無視されます。

- 最初の6文字に一意の数字が追加されます。

- たとえば、ファイル名がacc_Data.csvの場合、バルク・ロード操作中に作成される表の名前はoim_blkld_tmp_accDat1となります。

複数のCSVファイルがある場合、ファイルごとに1つの表が作成されます。各CSVファイル名の最初の6文字が表名に追加されるため、各ファイル名の最初の6文字が必ず一意になるようにします。このガイドラインについては、このドキュメントで後述します。

注意:

入力ソースとしてデータベース表を使用する場合、その表には任意の名前を指定できます。この表の名前を、ユーティリティの入力パラメータの1つとして指定します。

- OIM_BLKLD_EX_SUFFIX
OIM_BLKLD_EX_SUFFIX表は、バルク・ロード操作中に失敗した(Oracle Identity Managerにロードされなかった)データ・レコードを保持するために使用されます。OIM_BLKLD_TMP_SUFFIX表ごとに、1つのOIM_BLKLD_EX_SUFFIX表が作成されます。表のEXCEPTION_MSG列には、表内の各レコードの失敗の理由が格納されます。

入力ソースとしてCSVファイルを使用する場合、CSVファイル名の最初の6文字は、表名に接尾辞として追加されます。たとえば、CSVファイルの名前がusrdt120508.csvの場合、表名はOIM_BLKLD_EX_ usrdt1となります。複数のCSVファイルがある場合、CSVファイルごとに1つの一時表が作成されます。

注意:

複数のCSVファイルがある場合、各CSVファイル名の最初の6文字が必ず一意になるようにします。

- OIM_BLKLD_LOG
バルク・ロード操作中、ユーティリティにより、進捗メッセージおよびエラー・メッセージがOIM_BLKLD_LOG表に挿入されます。この表に問い合せることで、バルク・ロード操作の進捗を監視できます。この手順の詳細は、このドキュメントで後述します。

24.2.1.3 ユーティリティで提供されるオプション

バルク・ロード・ユーティリティを実行すると、次のオプションのいずれかを選択するように要求されます。

注意:

選択するオプションによっては、ユーティリティからさらに入力を要求されます。

- ユーザー・データのロード
ユーティリティでOIMユーザー・データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity ManagerのUSR表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- アカウント・データのロード
ユーティリティでアカウント・データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity Managerの関連するUD_表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- ロール・データのロード
ユーティリティでロール・データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity ManagerのUGP表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- ロール・メンバーシップのロード
ユーティリティでロール・メンバーシップ・データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity ManagerのUSG表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- ロール階層のロード
ユーティリティでロール階層データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity ManagerのGPG表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- ロール・カテゴリのロード
ユーティリティでロール・データをロードする場合は、このオプションを選択します。つまり、データはOracle Identity ManagerのROLE_CATEGORY表にインポートされます。また、ロードするデータの入力ソース(CSVファイルまたはデータベース表)を選択できます。

- 監査スナップショットの生成
ユーティリティでロードしたユーザーの監査スナップショットを生成する場合は、このオプションを選択します。

24.2.2 バルク・ロード操作用のデータベースの準備

バルク・ロード操作用にデータベースを準備する場合は、次の項目を実行します。

- 一時表の表領域の作成

- Oracle Identity Manager表領域でのデータファイルの作成

24.2.2.1 一時表の表領域の作成

「バルク・ロード操作中に使用される一時表」で説明したとおり、バルク・ロード操作中には一時データベース表が使用されます。Oracle Identity Managerデータベースのデフォルトの表領域を使用するかわりに、これらの一時表を収容する表領域を作成することをお薦めします。

データベースのドキュメントの表領域作成手順に従ってください。

24.2.2.2 Oracle Identity Manager表領域でのデータファイルの作成

Oracle Identity Managerのインストール中に作成されるOracle Identity Manager表領域のデータファイルのデフォルトのサイズは、500MBです。ロードするデータを収容するために、このデータファイルへの領域の追加が必要になる場合があります。または、データファイルを作成します。

Oracle Identity Manager表領域でデータファイルを作成するには、次の手順を実行します。

1. SQL*Plusセッションを開始します。

2. Oracle Identity ManagerデータベースにSYSDBAとして接続します。

3. oim_blkld_setup.sqlスクリプトを実行します。スクリプトから次の情報の入力を要求されます。

- Oracle Identity Manager表領域の名前

- Oracle Identity Manager表領域に追加されるデータファイルのフルパスおよび名前

- Oracle Identity Managerデータベースのユーザー名

24.3 ユーティリティの実行

注意:

既存の表と競合する名前がある場合、ユーティリティにより、既存の一時表が各実行の開始時に上書きされます。必要に応じて、ユーティリティの前の実行時に作成された一時データベース表の名前を変更します。

ユーティリティを実行するには:

1. Oracle Identity Managerを停止します。

2. 次のいずれかのスクリプトを実行します。

注意:

非ASCIIデータが含まれているCSVファイルをロードするには、oim_blkld.shスクリプトまたはoim_blkld.batスクリプトを実行する前に、NLS_LANG環境パラメータを次の形式のUTF8キャラクタ・セットに設定します。

NLS_LANG = LANGUAGE_TERRITORY.UTF8

例:

NLS_LANG = American_America.UTF8

- UNIXコンピュータの場合:
OIMBulkload/script/oim_blkld.sh

- Microsoft Windowsコンピュータの場合:
OIMBulkload\script\oim_blkld.bat

3. 「ユーティリティで提供されるオプション」の説明に従って、ユーザー、アカウント、ロール関連のデータなど、ロードするデータに応じてメイン・メニューのオプションのいずれか1つを選択します。

4. 2番目のメニューから、次のように選択します。

- 入力ソースとしてCSVファイルを使用する場合、CSVファイルを選択します。

- 入力ソースとしてデータベース表を使用する場合、DB表を選択します。

5. 要求されたら、「ユーティリティの入力パラメータの値の確認」で説明されている入力パラメータの値を指定します。

注意:

OIMユーザー・データのロードに必要な入力パラメータの詳細は、「ユーティリティの入力パラメータの値の確認」を参照してください。アカウント、ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロードに必要な入力パラメータの詳細は、対応する項を参照してください。

6. 「操作の進捗の監視」で説明する手順に従い、操作のパフォーマンスを監視します。

24.4 OIMユーザー・データのロード

OIMユーザー・データをロードする手順の概要は次のとおりです。

1. バルク・ロード用のデータベースを準備していない場合は、準備します。詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

2. パスワードが、バルク・ロード操作中に作成されるすべてのOIMユーザーに対してデフォルトのパスワードとして使用されるOIMユーザーを作成します。

3. バルク・ロード操作の入力ソースを作成します。
データベース表を入力ソースとして使用する場合は、表を作成して、ユーザー・データを表にコピーします。

CSVファイルを入力ソースとして使用する場合は、CSVファイルを作成し、このファイルにユーザー・データをコピーします。また、データのロード順にロード元となるファイルの名前が含まれるmaster.txtファイルを作成します。

4. ユーティリティの入力パラメータの値を確認します。

5. Oracle Identity Managerを停止します。

6. oim_blkld.shスクリプトまたはoim_blkld.batスクリプトを実行します。oim_blkld.shスクリプトまたはoim_blkld.batスクリプトの実行の詳細は、「ユーティリティの実行」を参照してください。

7. バルク・ロード操作の進捗を監視します。

8. バルク・ロード操作の結果を確認します。

9. 必要に応じて、最初の実行でロードされなかったデータをリロードします。

10. Oracle Identity Managerを再起動します。

11. バルク・ロード操作の結果を検証します。

12. 操作から診断データを収集します。

13. 操作中に作成された一時表およびファイルを削除します。

14. 監査スナップショットを生成します。

次の項では、OIMユーザー・データのロードに必要な手順の詳細について説明します。

- ユーティリティによって追加されたOIMユーザーのデフォルト・パスワードの設定

- バルク・ロード操作用の入力ソースの作成

- ユーティリティの入力パラメータの値の確認

- 操作の進捗の監視

- 操作中に記録された例外の処理

- 例外の修正およびデータ・レコードのリロード

- バルク・ロード操作の結果の検証

- 監査スナップショットの生成

24.4.1 ユーティリティによって追加されたOIMユーザーのデフォルト・パスワードの設定

このユーティリティでは、バルク・ロード操作中に作成されたOIMユーザーに割り当てるパスワードを暗号化しません。かわりに、操作中に作成されたすべてのOIMユーザーに、既存のOIMユーザーのパスワードを割り当てます。

注意:

各OIMユーザーは、最初のログインでパスワードを変更する必要があります。

ユーティリティを実行すると、パスワードを新規OIMユーザーのデフォルトのパスワードとして使用する既存のOIMユーザーのログイン名を指定するように要求されます。ユーティリティを実行する前に、このOIMユーザーを次のように作成します。

注意:

Oracle Identity Managerでは、バルク・ロード操作専用のユーザーを作成し、後で必要でなくなったときにこのユーザーを削除できます。このようにしない場合は、既存の任意のOIMユーザーを使用して、バルク・ロード操作を実行できます。

1. Oracle Identity Self Serviceに、ユーザーの作成権限を持つユーザーとしてログインします。

2. 「管理」をクリックします。

3. 「ようこそ」ページで「ユーザーの作成」をクリックします。

4. 次のフィールドの値を指定します。

- ユーザー・ログイン

- 名(オプション)

- 姓

- 組織: 「Xellerateユーザー」を選択します。

- パスワード

- パスワードの確認

5. 「保存」をクリックします。

24.4.2 バルク・ロード操作用の入力ソースの作成

使用する入力ソースに応じて、次のいずれかの項で示されているガイドラインに従います。

- 入力ソースとしてのCSVファイルの使用

- 入力ソースとしてのデータベース表の作成

24.4.2.1 入力ソースとしてのCSVファイルの使用

バルク・ロード操作用の入力ソースとしてCSVファイルを使用する場合は、CSVファイルの作成時に次のガイドラインに従います。

- CSVファイルは、oimbulkload/csv_filesディレクトリに置く必要があります。

- CSVファイルの1行目は制御行と呼ばれます。この行には、Oracle Identity ManagerデータベースにおけるUSR表の列名のカンマ区切りリストが含まれている必要があります。

注意:

「パスワード」列または暗号化されたその他の列が、列リストに含まれていないことを確認してください。このドキュメントで前述したように、ユーティリティでは、Oracle Identity ManagerにロードするすべてのOIMユーザーに、指定した既存のOIMユーザーのパスワードが割り当てられます。

- ファイルの2行目以降には、制御行にある列の値が含まれている必要があります。1行目の列の順序と、残りの行の値が同じである必要があります。
CSVファイルの内容のサンプルを次に示します。

USR_LOGIN,USR_FIRST_NAME,USR_LAST_NAME,UD_ADUSER_OBJECTGUID
john_doe, John, Doe, jdoe
jane_doe, Jane, Doe, janedoe
richard_roe, Richard, Roe, rroe

- 列にカンマを含む値がある場合は、その値を二重引用符(")で囲む必要があります。

- CSVファイルには、USR表で必須と指定されているすべての列の値が含まれている必要があります。次の表に、USR表のロードに必要な必須列を示します。

必須列

説明

USR_FIRST_NAME

ユーザーの名

USR_LAST_NAME

ユーザーの姓

注意:

- USR_LOGINは、Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では必須列ではありません。

- 一部のキー必須列は無視できます。たとえば、ORG_NAMEによって移入されるUSR表のACT_KEY列です。

- CSVファイルの各行では、USR表のUSR_LOGIN列に一意の値が必要です。複数のファイルがある場合、USR_LOGINの値がCSVファイル全体にわたり一意であることを確認します。USR_LOGIN値の一意性のチェックは、Oracle Identity Managerの既存のOIMユーザーについても行う必要があります。
USR_LOGIN値が一意であることを確認する作業には、時間がかかる場合があります。別の方法として、最初にバルク・ロード操作を実行し、一意でないUSR_LOGIN値を修正してから、変更されたユーザー・レコードについてロード操作を再試行できます。ユーティリティでは、実行時にUSR_LOGIN値の一意性をチェックし、このチェックにパスしなかったレコードをOIM_BLKLD_EX表にコピーするので、これが可能になります。最初の実行でロードされなかったレコードについて、バルク・ロード操作を再試行する手順については、このドキュメントで後述します。

- 各ユーザー・レコードに組織名を含める場合、制御行にORG_NAMEを追加し、2行目以降でユーザーごとに組織名を入力します。ORG_NAMEが含まれていない場合は、ユーザーをXellerateユーザー組織に割り当てる必要があります。

注意:

CSVファイルのORG_NAME列に表示されているすべての組織名が、Oracle Identity Managerに存在する必要があります。

- 各ユーザー・レコードにマネージャ名を含める場合、制御行にMANAGER_NAMEを追加し、2行目以降でユーザーごとにマネージャのUSR_LOGIN値を入力します。
すべてのCSVファイルからすべてのユーザー・データをOracle Identity Managerにロードした後、ユーティリティでは、マネージャを調べるためにUSR_LOGIN値を参照します。MANAGER_NAME列で指定したUSR_LOGIN値がOracle Identity Managerに存在しない場合、ユーザー・レコードの参照は失敗し、レコードは例外表のOIM_BLKLD_EXにコピーされます。バルク・ロード操作の最後に、「例外の修正およびデータ・レコードのリロード」で説明する手順を実行すると、最初の実行で失敗したユーザー・レコードをリロードできます。

- CSVファイルに次の列の値が含まれていない場合、次のデフォルト値がOracle Identity Managerに挿入されます。
ORG_NAME: Xellerate Users

USR_TYPE: End-User

USR_STATUS: Active

USR_EMP_TYPE: Full-Time

- ロードするユーザー・データが含まれるCSVファイルの名前を含むマスターTXTファイルを作成します。このファイルには任意の名前(master.txtなど)を指定できます。マスター・ファイルをoimbulkload/csv_filesディレクトリに保存します。
複数のCSVファイルをロードする場合は、マスター・ファイルの別々の行に各データCSVファイルの名前を入力します。CSVファイル名のリストを、ユーティリティでファイルからデータをロードする順序に並べ替えます。たとえば、3つのデータCSVファイル(London_Users.csv、NewYork_Users.csvおよびTokyo_Users.csv)を作成したとします。マスター・ファイルで、データCSVファイルの名前を次の順序で入力します。

Tokyo_Users.csv
London_Users.csv
NewYork_Users.csv

ユーティリティを実行すると、データはこの順序でロードされます。これは、LondonおよびNew Yorkのユーザー・データがTokyoユーザーに依存している可能性があるためです。これは、マネージャ-ユーザー階層を保証するためです。

- CSVファイルがMicrosoft Windowsで生成され、Linux環境でロードされる場合は、\n\rなどの特殊文字を削除して実行時エラーを回避します。

24.4.2.2 入力ソースとしてのデータベース表の作成

OIMユーザー・データのロード用の入力ソースとしてデータベース表を使用する場合は、データベース表の作成時に次のガイドラインに従います。

- Oracle Identity Managerデータベースに表を作成します。

- 表には、次の主キー列が含まれている必要があります。
OIM_BLKLD_USRSEQ NUMBER(19)

ユーティリティでは、この列が主キーとして使用されます。必要に応じて、データベース順序を使用して、この列に値を移入できます。

- 残りの列は、使用するUSR表の列と同じである必要があります。つまり、作成する表に含めないオプションのUSR_列は無視します。

- 表に次の列の値が含まれていない場合、次のデフォルト値がOracle Identity Managerに挿入されます。
ORG_NAME: Xellerate Users

USR_TYPE: End-User

USR_STATUS: Active

USR_EMP_TYPE: Full-Time

- 各ユーザー・レコードに組織名を含める場合、制御行にORG_NAMEを追加し、2行目以降でユーザーごとに組織名を入力します。ORG_NAMEが含まれていない場合は、ユーザーをXellerateユーザー組織に割り当てる必要があります。

- 各ユーザー・レコードにマネージャ名を含める場合、制御行にMANAGER_NAMEを追加し、2行目以降でユーザーごとにマネージャのUSR_LOGIN値を入力します。

表24-1に、サンプル・データベース表の構造を示します。

表24-1 サンプル・データベース表の構造

名前

NULLかどうか

タイプ

USR_LOGIN

NOT NULL

VARCHAR2(256)

USR_FIRST_NAME

VARCHAR2(150)

USR_LAST_NAME

NOT NULL

VARCHAR2(150)

. . .

. . .

. . .

OIM_BLKLD_USRSEQ

NOT NULL

NUMBER(19)

24.4.3 ユーティリティの入力パラメータの値の確認

ユーティリティの入力パラメータは次のとおりです。

- Oracleホーム
Oracle Identity Managerデータベース用のホスト・コンピュータでのORACLE_HOME環境変数の値。

- データベース接続文字列
データベースに接続するための接続文字列。次の形式で入力する必要があります。

//HOST_IP_ADDRESS:PORT_NUMBER/SERVICE_NAME

- OIM DBユーザー
Oracle Identity Managerデータベース・ユーザーのデータベース・ログインID。

- OIM DBパスワード
Oracle Identity Managerデータベース・ユーザーのパスワード。

データベース・ユーザー・パスワードは、要求されたときに2回入力します。

- マスター・ファイル名
ロードされるCSVデータファイルの名前を含むファイルの名前。

このパラメータは、入力ソースが1つまたは複数のCSVファイルの場合のみ使用されます。マスター・ファイルとCSVデータファイルは、oimbulkload/csv_filesディレクトリに置きます。詳細は、「入力ソースとしてのCSVファイルの使用」を参照してください。

- 一時表名
入力ソースとして使用される一時表の名前。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。詳細は、「入力ソースとしてのデータベース表の作成」を参照してください。

- 制御行
データベース表からOracle Identity Managerにロードされる列の名前のカンマ区切りリスト。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。

- 表領域名
バルク・ロード操作中に一時表が作成される表領域の名前。ユーザーが表領域名を指定しない場合は、デフォルトの表領域が使用されます。

詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

- 日付書式
CSVファイルの日付列で使用される日付書式。

このパラメータは、入力ソースが1つまたは複数のCSVファイルの場合のみ使用されます。

日付書式は、次の項目に一致する必要があります。

- dd-mm-yyyyやMM-DD-YYYYなど、Oracleでサポートされている日付書式

- CSVファイルで指定されている日付書式

- バッチ・サイズ
ユーティリティで単一トランザクションとして処理する必要のあるユーザー・レコード数。

バッチ・サイズは、バルク・ロード操作のパフォーマンスに影響を与える可能性があります。このパラメータのデフォルト値は10000です。

- デバッグ・フラグ
このパラメータの値として、YまたはNを指定できます。このパラメータをYに設定すると、ユーティリティでは、バルク・ロード操作中に発生したイベントに関する詳細な情報が記録されます。詳細は、「操作中に記録されるデータ」を参照してください。

- デフォルト・パスワードのユーザーID
「ユーティリティによって追加されたOIMユーザーのデフォルト・パスワードの設定」で説明した手順を実行して作成するOIMユーザーのログイン名。

24.4.4 操作の進捗の監視

バルク・ロード操作中に、操作の進捗に関する情報をOIM_BLKLD_LOG表に問い合せることができます。たとえば、次の問合せを実行すると、OIMユーザー・データをロードするバルク・ロード操作中に生成される進捗メッセージを確認できます。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'USER' AND LOG_LEVEL = 'PROGRESS_MSG'
ORDER BY MSG_SEQ_NO;

バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'USER' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

24.4.5 操作中に記録された例外の処理

バルク・ロード処操作理の最後に、ユーティリティでは、次のファイルに操作に関連する統計を記録します。

oimbulkload/logs_YYYYMMDD_hhmm/oim_blkld_user_load_summary.log

操作中に例外が発生したかどうかを確認するには、このログ・ファイルを開き、Number of Records Rejectedラベルの数を確認します。拒否レコードの数がゼロより大きい場合、操作中に例外がスローされたことになります。ユーティリティに拒否されたユーザー・レコードは、例外表(OIM_BLKLD_EX_SUFFIX)に記録されます。拒否レコードごとに、そのレコードをロードできなかった理由に関する情報が、OIM_BLKLD_EX_SUFFIX表のEXCEPTION_MSG列に格納されます。

例24-1に、OIMユーザー・データを格納するバルク・ロード操作の最後にログ・ファイルに記録される統計の例を示します。

例24-1 OIMユーザー・データのロード後に生成されるログ・ファイルの例

****************************************************************

Processing File: u10.csv
================================================================
U S E R    L O A D    S T A T I S T I C S    F O R   F I L E : u10.csv
================================================================
Start Time:   08-AUG-08 11.44.12.228000 AM
End Time:     08-AUG-08 11.44.13.368000 AM
Number of Records Processed:  10
Number of Records Loaded:     8
Number of Records Rejected:   2
================================================================
The name of the TMP table used during the load:
OIM_BLKLD_TMP_U101

The name of the Exception table used during the load:
OIM_BLKLD_EX_U101

****************************************************************
Processing File: u10b.csv

================================================================
U S E R    L O A D    S T A T I S T I C S    F O R   F I L E : u10b.csv
================================================================
Start Time:   08-AUG-08 11.44.15.368000 AM
End Time:     08-AUG-08 11.44.15.540000 AM
Number of Records Processed:  16
Number of Records Loaded:     15
Number of Records Rejected:   1
================================================================
The name of the TMP table used during the load:
OIM_BLKLD_TMP_U10B2

The name of the Exception table used during the load:
OIM_BLKLD_EX_U10B2
================================================================

================================================================
Time taken in re-building indexes and enabling FK constraints
================================================================
Start time:      08-AUG-08 11.44.15.556000 AM
End Time:        08-AUG-08 11.46.50.586000 AM
================================================================

この例では、拒否レコードの数は2です。すべてのレコードがユーティリティによって拒否されたことがログ・ファイルに示されている場合、これらのレコードのロード操作の再試行の詳細は、「例外の修正およびデータ・レコードのリロード」を参照してください。

注意:

各バルク・ロード操作の最後に、例外表のバックアップを作成することをお薦めします。

24.4.6 例外の修正およびデータ・レコードのリロード

前述のように、バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'USER' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

例外表OIM_BLKLD_EX_SUFFIXは、バルク・ロード操作中に入力ソースとして使用したデータ表ごとに作成されます。操作基準を満たさないレコードは、この例外表にコピーされます。各例外表の名前に追加される接尾辞は、対応するデータ表の名前に追加される接尾辞と同じです。

拒否レコードをリロードするには、次の手順を実行します。

1. 拒否レコードが格納されている例外表のバックアップを作成します。

注意:

この手順はオプションですが、バックアップを作成することをお薦めします。

2. 例外表の各レコードを確認し、EXCEPTION_MSG列に記録されているメッセージに基づいて、データのエラーを修正します。

3. 例外表のすべての拒否レコードのエラーを修正したら、表名をOIM_BLKLD_TMP_SUFFIXに変更し、これを入力ソースとして使用します。

4. ユーティリティを実行して、OIM_BLKLD_TMP_SUFFIX表からレコードをロードします。詳細は、「ユーティリティの実行」を参照してください。

5. oim_blkld_user_load_summary.logファイルでNumber of Records Rejectedラベルの値が0になるまで、手順1から4を繰り返します。

6. Oracle Identity Managerを再起動します。

24.4.7 バルク・ロード操作の結果の検証

バルク・ロード操作の結果を検証するには、ユーティリティによって追加されたOIMユーザーの1人について、次の手順を実行できるかどうかをチェックします。

注意:

これらの手順ではシステムにフットプリントが残るため、バルク・ロードの検証は、テスト・ユーザーを使用して実行する必要があります。システムにフットプリントが残らないようにするには、変更を元に戻します。たとえば、リソースをOIMユーザーにプロビジョニングした場合は、バルク・ロード操作の結果のテスト後に、リソースをプロビジョニング解除します。

- OIMユーザーとしてログインします。パスワードの変更を要求されます。

- OIMユーザー用のリソースをプロビジョニングします。

- OIMユーザーをロールに追加します。

- OIMユーザーのアカウント・プロファイルを変更します。

- OIMユーザーにプロビジョニングされたリソースを失効させます。

- 前にOIMユーザーを追加したロールからそのユーザーの割当てを解除します。

- アカウント・プロファイルを再び変更し、プロファイルを元の状態に戻します。

- そのユーザーに関する「ユーザー・リソース・アクセス」レポート(操作上のレポート)および「ユーザー・リソース・アクセス履歴」レポートを生成できるかどうかをチェックします。

- アテステーションを作成し、診断ダッシュボードを使用してそのステータスをチェックします。

24.4.8 監査スナップショットの生成

必要に応じて、バルク・ロード操作後またはバルク・ロード操作中にいつでも、Oracle Identity Managerデータの監査スナップショットを生成できます。監査スナップショットは、バルク・ロード・ユーティリティのオプション7を選択して生成することもできます。ユーティリティでは、Oracle Identity Managerとともに出荷されている監査エンジンを使用します。内部的には、監査ユーティリティの実行時に、GenerateSnapshotスクリプトがコールされます。同様に、監査スナップショットを生成するオプションを選択すると、GenerateSnapshotスクリプトがコールされます。

注意:

監査ユーティリティの実行時には、Oracle Identity Managerが起動し、稼働中であることが必要です。

監査スナップショットを生成する前に、実行中のGenerateSnapshotスクリプトに次の環境変数を設定する必要があります。

- OIM_ORACLE_HOME: c:\work1\Oracle_IDM1

- JAVA_HOME: C:\jdk160

- MW_HOME: c:\work1

- WL_HOME: c:\work1\wlserver_10.3

- DOMAIN_HOME: C:\work1\user_projects\domains\base_domain

注意:

C:\work1\は、MW_HOMEのサンプル・ディレクトリ・パスです。

監査スナップショットの生成手順の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の監査の構成に関する説明を参照してください。

24.5 アカウント・データのロード

アカウント・データをロードする手順の概要は次のとおりです。

1. バルク・ロード操作用のデータベースを準備していない場合は、準備します。詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

2. バルク・ロード操作の入力ソースを作成します。
データベース表を入力ソースとして使用する場合は、表を作成して、アカウント・データを表にコピーします。

CSVファイルを入力ソースとして使用する場合は、CSVファイルを作成し、このファイルにアカウント・データをコピーします。

3. ユーティリティの入力パラメータの値を確認します。

4. Oracle Identity Managerを停止します。

5. oim_blkld.shスクリプトまたはoim_blkld.batスクリプトを実行します。

6. バルク・ロード操作の進捗を監視します。

7. バルク・ロード操作の結果を確認します。

8. 必要に応じて、最初の実行でロードされなかったデータをリロードします。

9. Oracle Identity Managerを再起動します。

10. バルク・ロード操作の結果を検証します。

11. 操作から診断データを収集します。

12. 操作中に作成された一時表およびファイルを削除します。

アカウント・データのバルク・ロード操作の要件および機能

アカウント・データのバルク・ロード操作の要件および機能は次のとおりです。

- リコンシリエーションを設定し、ターゲット・システムからいくつかのアカウントをインポートすることによって、リコンシリエーションをテストできるようにする必要があります。

- 対応するOIMユーザーがあるアカウントのみをロードできます。

- 複数のITリソースが必要なターゲット・システムはサポートされません。

- バルク・ロード操作中には、重複したアカウントを検出できません。入力ソースで同じアカウントについて複数のエントリがある場合、対応するOIMユーザーに複数のアカウントが作成されます。

- 特定のターゲット・システムの場合、Oracle Identity Managerに複数のプロビジョニング・プロセスまたはプロセス・フォームがあると、リソース・オブジェクトのデフォルトのプロビジョニング・プロセスがユーティリティによって使用されます。

- 以前のバルク・ロード操作がどのステージまで進行したかに関する情報は格納されていません。つまり、ユーティリティはバルク・ロード操作を再開できません。バルク・ロード操作前に、Oracle Identity Managerデータベースをバックアップする必要があります。バルク・ロード操作を再試行する場合、最初にデータベースをリストアしてから、手順を再実行します。

- バルク・ロード・ユーティリティは、アカウント・データのロードのための入力として、対応するアプリケーション・インスタンス名を取得します。アプリケーション・インスタンス名が不明な場合、ロードするアカウント・データに基づいて、バルク・ロード・ユーティリティは、リソース・オブジェクト名およびITリソース名の入力を求めます。

次の項では、アカウント・データのロードに必要な手順の詳細について説明します。

- バルク・ロード操作用の入力ソースの作成

- ユーティリティの入力パラメータの値の確認

- 操作の進捗の監視

- 操作中に記録された例外の処理

- 例外の修正およびデータ・レコードのリロード

- バルク・ロード操作の結果の検証

24.5.1 バルク・ロード操作用の入力ソースの作成

使用する入力ソースに応じて、次のいずれかの項で示されているガイドラインに従います。

- 入力ソースとしてのCSVファイルの使用

- 入力ソースとしてのデータベース表の作成

24.5.1.1 入力ソースとしてのCSVファイルの使用

バルク・ロード操作用の入力ソースとしてCSVファイルを使用する場合は、CSVファイルの作成時に次のガイドラインに従います。

- CSVファイルは、oimbulkload/csv_filesディレクトリに置く必要があります。

- CSVファイルの1行目は制御行と呼ばれます。この行には、アカウント・データをロードするアカウント(UD_*)表の列名のカンマ区切りリストが含まれている必要があります。UD_表を検索するには、Design Consoleのプロセス・フォームに移動します。プロセス・フォームの詳細は、第5章「プロビジョニング・プロセスの開発」を参照してください。

注意:

「パスワード」列または暗号化されたその他の列が、列リストに含まれていないことを確認してください。

- ファイルの2行目以降には、制御行にある列の値が含まれている必要があります。1行目の列の順序と、残りの行の値が同じである必要があります。

- 列にカンマを含む値がある場合は、その値を二重引用符(")で囲む必要があります。

- CSVファイルには、アカウント表で必須と指定されているすべての列の値が含まれている必要があります。アカウント表のキー必須列は無視する必要があります。

- 親表および子表にアカウント・データをロードする場合、1つの親CSVファイルと、子表ごとに1つのCSVファイルを作成する必要があります。たとえば、1つの親表と3つの子表にデータをロードする場合、1つの親CSVファイルと3つの子CSVファイルを作成する必要があります。

- アカウント・データを親表および子表にロードする場合、少なくとも1つの列を両方の表で同じにします。この列は、親CSVファイルと子CSVファイル間のリンク属性に対応します。次の例では、この方法が示されています。
親CSVファイルの内容のサンプルを次に示します。

UD_ADUSER_UID,UD_ADUSER_ORGNAME,UD_ADUSER_FNAME,UD_ADUSER_LNAME,UD_ADUSER_MNAME,UD_ADUSER_FULLNAME,UD_ADUSER_OBJECTGUID
ADTEST1,"7~CN=ForeignSecurityPrincipals,DC=vivek01,DC=com",adtest1,adtest1,,adtest1,102

注意:

UD_ADUSER_OBJECTGUID列は、バルク・ロード操作で使用するアカウントをロードするための親CSVファイルに必須です。この列は、データベース内でNULL値が許容される列であるかどうかにかかわらず、親CSVファイルに追加する必要があります。

子CSVファイルの内容のサンプルを次に示します。

UD_ADUSER_UID,UD_ADUSER_ORGNAME,UD_ADUSRC_GROUPNAME
ADTEST1,"7~CN=ForeignSecurityPrincipals,DC=vivek01,DC=com",group2

UD_ADUSER_UID列は、親ファイルと子ファイルの両方で共通です。

- CSVファイルがMicrosoft Windowsで生成され、Linux環境でロードされる場合は、\n\rなどの特殊文字を削除して実行時エラーを回避します。

24.5.1.2 入力ソースとしてのデータベース表の作成

アカウント・データのロード用の入力ソースとしてデータベース表を使用する場合は、データベース表の作成時に次のガイドラインに従います。

- Oracle Identity Managerデータベースに表を作成します。

- 表には、次の主キー列が含まれている必要があります。
OIM_BLKLD_USRSEQ NUMBER(19)

ユーティリティでは、この列が主キーとして使用されます。必要に応じて、データベース順序を使用して、この列に値を移入できます。

- 残りの列は、使用するアカウント(UD_)表の列と同じである必要があります。つまり、作成する表に含めないオプションのUD_列は無視します。

表24-2に、サンプルの親表の構造を示します。

表24-2 サンプル・データベース表の構造

名前

NULLかどうか

タイプ

UD_ADUSER_UID

VARCHAR2(20)

UD_ADUSER_ORGNAME

VARCHAR2(256)

UD_ADUSER_FNAME

VARCHAR2(80)

UD_ADUSER_LNAME

VARCHAR2(80)

UD_ADUSER_MNAME

VARCHAR2(80)

UD_ADUSER_FULLNAME

VARCHAR2(240)

OIM_BLKLD_SEQ

NOT NULL

NUMBER(19)

表24-3に、サンプルの子表の構造を示します。

表24-3 サンプルの子データベース表の構造

名前

NULLかどうか

タイプ

UD_ADUSER_UID

VARCHAR2(20)

UD_ADUSER_ORGNAME

VARCHAR2(256)

UD_ADUSRC_GROUPNAME

VARCHAR2(32)

OIM_BLKLD_SEQ

NOT NULL

NUMBER(19)

24.5.2 ユーティリティの入力パラメータの値の確認

ユーティリティの入力パラメータは次のとおりです。

- Oracleホーム
Oracle Identity Managerデータベース用のホスト・コンピュータでのORACLE_HOME環境変数の値。

- データベース接続文字列
データベースに接続するための接続文字列。次の形式で入力する必要があります。

//HOST_IP_ADDRESS:PORT_NUMBER/SERVICE_NAME

- OIM DBユーザー
Oracle Identity Managerデータベース・ユーザーのデータベース・ログインID。

- OIM DBパスワード
Oracle Identity Managerデータベース・ユーザーのパスワード。

- アプリケーション・インスタンス名(APP_INSTANCE)
ロードされるアカウント・データに対応するアプリケーション・インスタンスの名前。ユーザーがアプリケーション・インスタンス名を知らない場合、アカウント・バルクロード・ユーティリティはリソース・オブジェクト名およびITリソース名の入力を求めます。プロンプトを次に示します。

Do you know the Application Instance name? (Y,y,N,n)

Yまたはyを入力する場合、アプリケーション・インスタンス名の入力が求められます。Nまたはnを入力する場合、次の入力が求められます。

- リソース・オブジェクト名(OBJ_NAME)
ユーザーがアプリケーション・インスタンス名を知らない場合、バルク・ロード・ユーティリティは、ロードするアカウント・データに対応するリソース・オブジェクト名の入力を求めます。

- ITリソース名
ターゲット・システム用に作成されたITリソースの名前。これは、ユーザーがアプリケーション・インスタンス名を知らない場合にのみ必要です。アカウント・バルクロード・ユーティリティは、はじめにリソース・オブジェクト名の入力を求め、次にITリソース名の入力を求めます。

- CSVファイル名
入力ソースとして使用されるCSVファイルの名前。

このパラメータは、入力ソースがCSVファイルの場合のみ使用されます。詳細は、「入力ソースとしてのCSVファイルの使用」を参照してください。親CSVファイルおよび子CSVファイルからデータをロードする場合、カンマ区切りリストを使用して、ファイル名を入力します。親CSVファイルの名前を最初に指定し、その後に子CSVファイルの名前を指定する必要があります。

- 一時表名
入力ソースとして使用される一時表の名前。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。詳細は、「入力ソースとしてのデータベース表の作成」を参照してください。

- 制御行
データベース表からOracle Identity Managerにロードされる列の名前のカンマ区切りリスト。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。

- 表領域名
バルク・ロード操作中に一時表が作成される表領域の名前(エンドユーザーが表領域名を指定しない場合、デフォルトの表領域が使用されます)。

詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

- 日付書式
CSVファイルの日付列で使用される日付書式。

このパラメータは、入力ソースが1つまたは複数のCSVファイルの場合のみ使用されます。

日付書式は、次の項目に一致する必要があります。

- dd-mm-yyyyやMM-DD-YYYYなど、Oracleでサポートされている日付書式

- CSVファイルで指定されている日付書式

- バッチ・サイズ
ユーティリティで単一トランザクションとして処理する必要のあるユーザー・レコード数。

バッチ・サイズは、バルク・ロード操作のパフォーマンスに影響を与える可能性があります。このパラメータのデフォルト値は10000です。

- デバッグ・フラグ
このパラメータの値として、YまたはNを指定できます。このパラメータをYに設定すると、ユーティリティでは、バルク・ロード操作中に発生したイベントに関する詳細な情報が記録されます。詳細は、「操作中に記録されるデータ」を参照してください。

- アプリケーション・インスタンス(APP_INSTANCE)
ロードされるアカウント・データに対応するアプリケーション・インスタンスの名前。

ユーザーがアプリケーション・インスタンス名を知らない場合、アカウント・バルクロード・ユーティリティはオブジェクト名(OBJ_NAME)の入力を求めます。

24.5.3 操作の進捗の監視

バルク・ロード操作中に、操作の進捗に関する情報をOIM_BLKLD_LOG表に問い合せることができます。たとえば、次の問合せを実行すると、アカウント・データをロードするバルク・ロード操作中に生成される進捗メッセージを確認できます。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ACCOUNT' AND LOG_LEVEL = 'PROGRESS_MSG'
ORDER BY MSG_SEQ_NO;

たとえば、次の問合せを実行すると、アカウント・データをロードするバルク・ロード操作中に生成される進捗メッセージを確認できます。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ACCOUNT' AND LOG_LEVEL = 'PROGRESS_MSG'
ORDER BY MSG_SEQ_NO;

バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ACCOUNT' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

24.5.4 操作中に記録された例外の処理

バルク・ロード処操作理の最後に、ユーティリティでは、次のファイルに操作に関連する統計を記録します。

oimbulkload/logs_YYYYMMDD_hhmm/oim_blkld_account_load_summary.log

操作中に例外が発生したかどうかを確認するには、このログ・ファイルを開き、Number of Records Rejectedラベルの数を確認します。拒否レコードの数がゼロより大きい場合、操作中に例外がスローされたことになります。ユーティリティに拒否されたユーザー・レコードは、例外表(OIM_BLKLD_EX_SUFFIX)に記録されます。拒否レコードごとに、そのレコードをロードできなかった理由に関する情報が、OIM_BLKLD_EX_SUFFIX表のEXCEPTION_MSG列に格納されます。

例24-2に、アカウント・データを格納するバルク・ロード操作の最後にログ・ファイルに記録される統計の例を示します。

例24-2 アカウント・データのロード後に生成されるログ・ファイルの例

=============================================================
A C C O U N T    L O A D    S T A T I S T I C S
=============================================================
Start Time:   22-JUL-08 03.59.30.206000 PM
End Time:     22-JUL-08 04.03.21.126000 PM
Number of Records Processed:  100026
Number of Records Loaded:     100000
Number of Records Rejected:   26
=============================================================

The names of the TMP tables used during the load:
OIM_BLKLD_TMP_P100001
OIM_BLKLD_TMP_C100002
The names of the Exception tables used during the load:
OIM_BLKLD_EX_P100001
OIM_BLKLD_EX_C100002

この例では、拒否レコードの数は26です。すべてのレコードがユーティリティによって拒否されたことがログ・ファイルに示されている場合、これらのレコードのロード操作の再試行の詳細は、「例外の修正およびデータ・レコードのリロード」を参照してください。

注意:

各バルク・ロード操作の最後に、例外表のバックアップを作成することをお薦めします。

24.5.5 例外の修正およびデータ・レコードのリロード

注意:

複数のターゲット・システムのCSVファイルからデータをロードする場合、次の方法のいずれかを使用できます。

- 方法1: CSVファイルのすべてのセットに対してユーティリティを実行し、この項で説明する手順を実行します。

- 方法2: CSVファイルの1つのセットに対してユーティリティを実行し、この項で説明する手順を実行します。その後、次のセットのCSVファイルに対してこの手順を繰り返します。

前述のように、バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ACCOUNT' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

例外表OIM_BLKLD_EX_SUFFIXは、バルク・ロード操作中に入力ソースとして使用したデータ表ごとに作成されます。操作基準を満たさないレコードは、この例外表にコピーされます。各例外表の名前に追加される接尾辞は、対応するデータ表の名前に追加される接尾辞と同じです。

拒否レコードをリロードするには、次の手順を実行します。

1. 拒否レコードが格納されている例外表のバックアップを作成します。

注意:

この手順はオプションですが、バックアップを作成することをお薦めします。

2. 例外表の各レコードを確認し、EXCEPTION_MSG列に記録されているメッセージに基づいて、データのエラーを修正します。

3. 例外表のすべての拒否レコードのエラーを修正したら、表名をOIM_BLKLD_TMP_SUFFIXに変更し、これを入力ソースとして使用します。

4. ユーティリティを実行して、OIM_BLKLD_TMP_SUFFIX表からレコードをロードします。詳細は、「ユーティリティの実行」を参照してください。

5. oim_blkld_account_load_summary.logファイルでNumber of Records Rejectedラベルの値が0になるまで、手順1から4を繰り返します。

6. Oracle Identity Managerを再起動します。

24.5.6 バルク・ロード操作の結果の検証

バルク・ロード操作の結果を検証するには、ユーティリティによってアカウントが追加されたOIMユーザーの1人について、次の手順を実行できるかどうかをチェックします。

- OIMユーザーとしてログインし、新規に作成されたアカウントが、そのユーザーのリソース・プロファイルに表示されているかどうかをチェックします。

- 新規に作成されたアカウントの資格証明を使用して、ターゲット・システムにログインします。

24.6 ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロード

ロール関連データをロードする手順の概要は次のとおりです。

1. バルク・ロード操作用のデータベースを準備していない場合は、準備します。詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

2. バルク・ロード操作の入力ソースを作成します。
データベース表を入力ソースとして使用する場合は、表を作成して、ロール関連データを表にコピーします。

CSVファイルを入力ソースとして使用する場合は、CSVファイルを作成し、このファイルにロール関連データをコピーします。また、データのロード順にロード元となるファイルの名前が含まれるmaster.txtファイルを作成します。

3. ユーティリティの入力パラメータの値を確認します。

4. Oracle Identity Managerを停止します。

5. oim_blkld.shスクリプトまたはoim_blkld.batスクリプトを実行します。

6. バルク・ロード操作の進捗を監視します。

7. バルク・ロード操作の結果を確認します。

8. 必要に応じて、最初の実行でロードされなかったデータをリロードします。

9. Oracle Identity Managerを再起動します。

10. バルク・ロード操作の結果を検証します。

11. 操作から診断データを収集します。

12. 操作中に作成された一時表およびファイルを削除します。

次の項では、OIMユーザー・データのロードに必要な手順の詳細について説明します。

- バルク・ロード操作用の入力ソースの作成

- ユーティリティの入力パラメータの値の確認

- 操作の進捗の監視

- 操作中に記録された例外の処理

- 例外の修正およびデータ・レコードのリロード

- バルク・ロード操作の結果の検証

24.6.1 バルク・ロード操作用の入力ソースの作成

使用する入力ソースに応じて、次のいずれかの項で示されているガイドラインに従います。

- 入力ソースとしてのCSVファイルの使用

- 入力ソースとしてのデータベース表の作成

- ロール・ロード後に生成されるUGP_NAMEの確認

24.6.1.1 入力ソースとしてのCSVファイルの使用

バルク・ロード操作用の入力ソースとしてCSVファイルを使用する場合は、CSVファイルの作成時に次のガイドラインに従います。

- CSVファイルは、oimbulkload/csv_filesディレクトリに置く必要があります。

- CSVファイルの1行目は制御行と呼ばれます。

- この行には、Oracle Identity Managerデータベースにおける選択したロール・アップロード(ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ)に基づく列名のカンマ区切りリストが含まれている必要があります。

- ファイルの2行目以降には、制御行にある列の値が含まれている必要があります。1行目の列の順序と、残りの行の値が同じである必要があります。ロール(UGP) CSVファイルの内容のサンプルを次に示します。

UGP_ROLENAME,UGP_NAMESPACE,USR_LOGIN,ORG_NAME,INCLUDE_HIERARCHY
"Finance Controllers",Default,XELSYSADM,Finance,YES
"Finance Controllers",Default,XELSYSADM,Requests,YES

- ロール・ロードでは、階層に含まれるオプションを指定したOracle Identity Managerのセキュリティ・モデルに従い、組織にロールを公開できます。
ORG_NAMEパラメータの値として、FinanceまたはRequestsなど、ロールを公開する組織名を指定します。指定した組織とそのサブ組織にロールを公開する場合、INCLUDE_HIERARCHYにYESを指定します。指定した組織のみにロールを公開し、そのサブ組織には公開しない場合、INCLUDE_HIERARCHYにNULLまたはNOを指定します。ORG_NAMEおよびINCLUDE_HIERARCHYパラメータに値を指定しない場合、デフォルトでは、階層の最上位組織にロールが公開されます。

- 列にカンマを含む値がある場合は、その値を二重引用符(")で囲む必要があります。

- CSVファイルには、各ロール表で必須と指定されているすべての列の値が含まれている必要があります。

- CSVファイルには、アップロード・ロール・データ、ロール階層、ロール・メンバーシップ・データおよびロール・カテゴリ・データに応じて、必須と指定されているすべての列の値が含まれている必要があります。

- Role UGP): UGP_ROLENAME,UGP_NAMESPACE,USR_LOGIN,ORG_NAME,INCLUDE_HIERARCHY (UGP_NAMESPACE,ORG_NAME,INCLUDE_HIERARCHY
必要ない場合は、INCLUDE_HIERARCHYをnullのままにすることができます。

- ロール階層(GPG): UGP_NAME、GPG_UGP_NAME

- ロール・メンバーシップ(USG): UGP_NAME、USR_LOGIN

- ロール・カテゴリ(ROLE_CATEGORY): ROLE_CATEGORY_NAME

CSVファイルの各行では、必須列の組合せの一意の値が必要です。

- CSVファイルに次の列の値が含まれていない場合、次のデフォルト値がOracle Identity Managerに挿入されます。

- ロール(UGP)の場合
ROLE_CATEGORY_NAME: Default

UGP_DISPLAY_NAME: UGP_NAMEがデフォルトとなります。

ORG_NAME: TOP

INCLUDE_HIERARCHY: YES

- ロール階層(GPG)の場合
なし

- ロール・メンバーシップ(USG)の場合
RUL_KEY: RUL_NAMEがデフォルトのRUL表からのRUL_KEY。

USG_PRIORITY: アップロード用に指定されている行に基づくUGP_KEYに基づくグループおよびランク。

- ロール・カテゴリ(ROLE CATEGORY)
なし

- ロードするロール・データが含まれるCSVファイルの名前を含むマスターTXTファイルを作成します。このファイルには任意の名前(master.txtなど)を指定できます。マスター・ファイルをoimbulkload/csv_filesディレクトリに保存します。
複数のCSVファイルをロードする場合は、マスター・ファイルの別々の行に各データCSVファイルの名前を入力します。CSVファイル名のリストを、ユーティリティでファイルからデータをロードする順序に並べ替えます。たとえば、3つのデータCSVファイル( Role1.csv、Role2.csvおよびRole3.csv)を作成したとします。マスター・ファイルで、データCSVファイルの名前を次の順序で入力します。

Role1.csv

Role2.csv

Role3.csv

ユーティリティを実行すると、データはこの順序でロードされます。

- CSVファイルがMicrosoft Windowsで生成され、Linux環境でロードされる場合は、\n\rなどの特殊文字を削除して実行時エラーを回避します。

24.6.1.2 入力ソースとしてのデータベース表の作成

OIMユーザー・データのロード用の入力ソースとしてデータベース表を使用する場合は、データベース表の作成時に次のガイドラインに従います。

- Oracle Identity Managerデータベースに表を作成します。

- 表には、次の主キー列が含まれている必要があります。
OIM_BLKLD_USRSEQ NUMBER(19)

ユーティリティでは、この列が主キーとして使用されます。必要に応じて、データベース順序を使用して、この列に値を移入できます。

- 残りの列は、使用する各ロール表の列と同じである必要があります。

表24-4に、サンプル・データベース・ロール表の構造を示します。

表24-4 サンプル・データベース表の構造

ロール

NULL

タイプ

UGP_ROLENAME

NOT NULL

VARCHAR2(2000)

UGP_NAMESPACE

VARCHAR2(512)

ORG_NAME

NOT NULL

VARCHAR2(256)

INCLUDE_HIERARCHY

NOT NULL

VARCHAR2(256)

...

...

...

OIM_BLKLD_USRSEQ

NOT NULL

NUMBER(19)

注意:

ORG_NAMEおよびINCLUDE_HIERARCHYは、ロールのロードにのみ必要で、ロール階層、ロール・メンバーシップおよびロール・カテゴリには必要ありません。

24.6.1.3 ロール・ロード後に生成されるUGP_NAMEの確認

バルクロード・ユーティリティは、ロール・ロード中にUGP_NAMEを次の形式で生成します。

UGP_NAMESPACE.UGP_ROLENAME

CSVファイルのUGP_NAMESPACEの値を指定しない場合、デフォルトでは、UGP_NAMESPACEの値はDefaultです。生成されたUGP_NAMEを決定するには:

1. CSVファイルで、UGP_NAMESPACEがnullの場合、ネームスペース値はDefaultで、生成されるUGP_NAMEは、UGP_ROLENAMEの値と同じです。

2. UGP_NAMESPACEがnullではなく、CSVファイルに定義済の値がある場合、生成されたUGP_NAMEはUGP_NAMESPACE.UGP_ROLENAMEの値と同じです。

データベースに直接アクセスできない場合でも、UGP_NAMEの生成方法に基づいて、ロール階層、ロール・メンバーシップおよびロール・カテゴリの次のロードのためのUGP_NAME値を決定できます。そうでない場合、UGP表のUGP_NAMEの生成された値を確認します。

24.6.2 ユーティリティの入力パラメータの値の確認

ユーティリティの入力パラメータは次のとおりです。

- Oracleホーム
Oracle Identity Managerデータベース用のホスト・コンピュータでのORACLE_HOME環境変数の値。

- データベース接続文字列
データベースに接続するための接続文字列。次の形式で入力する必要があります。

//HOST_IP_ADDRESS:PORT_NUMBER/SERVICE_NAME

- OIM DBユーザー
Oracle Identity Managerデータベース・ユーザーのデータベース・ログインID。

- OIM DBパスワード
Oracle Identity Managerデータベース・ユーザーのパスワード。

- CSVファイル名
入力ソースとして使用されるCSVファイルの名前。

このパラメータは、入力ソースがCSVファイルの場合のみ使用されます。詳細は、「入力ソースとしてのCSVファイルの使用」を参照してください。親CSVファイルおよび子CSVファイルからデータをロードする場合、カンマ区切りリストを使用して、ファイル名を入力します。親CSVファイルの名前を最初に指定し、その後に子CSVファイルの名前を指定する必要があります。

- 一時表名
入力ソースとして使用される一時表の名前。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。詳細は、「入力ソースとしてのデータベース表の作成」を参照してください。

- 制御行
データベース表からOracle Identity Managerにロードされる列の名前のカンマ区切りリスト。

このパラメータは、バルク・ロード操作用の入力ソースがデータベース表である場合にのみ使用されます。

- 表領域名
バルク・ロード操作中に一時表が作成される表領域の名前(エンドユーザーが表領域名を指定しない場合、デフォルトの表領域が使用されます)。

詳細は、「バルク・ロード操作用のデータベースの準備」を参照してください。

- 日付書式
CSVファイルの日付列で使用される日付書式。これは、ロール・ロードでのみ求められ、ロール階層、ロール・メンバーシップおよびロール・カテゴリでは求められません。

このパラメータは、入力ソースが1つまたは複数のCSVファイルの場合のみ使用されます。

日付書式は、次の項目に一致する必要があります。

- dd-mm-yyyyやMM-DD-YYYYなど、Oracleでサポートされている日付書式

- CSVファイルで指定されている日付書式

- バッチ・サイズ
ユーティリティで単一トランザクションとして処理する必要のあるユーザー・レコード数。

バッチ・サイズは、バルク・ロード操作のパフォーマンスに影響を与える可能性があります。このパラメータのデフォルト値は10000です。

- デバッグ・フラグ
このパラメータの値として、YまたはNを指定できます。このパラメータをYに設定すると、ユーティリティでは、バルク・ロード操作中に発生したイベントに関する詳細な情報が記録されます。詳細は、「操作中に記録されるデータ」を参照してください。

24.6.3 操作の進捗の監視

バルク・ロード操作中に、操作の進捗に関する情報をOIM_BLKLD_LOG表に問い合せることができます。たとえば、次の問合せを実行すると、OIMロール・データをロードするバルク・ロード操作中に生成される進捗メッセージを確認できます。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ROLE' AND LOG_LEVEL = 'PROGRESS_MSG'
ORDER BY MSG_SEQ_NO;

バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ROLE' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

24.6.4 操作中に記録された例外の処理

バルク・ロード処操作理の最後に、ユーティリティでは、次のファイルに操作に関連する統計を記録します。

oimbulkload/logs_YYYYMMDD_HHMM/oim_blkld_ENTITY_NAME_load_summary.log

ログ・ファイル名のENTITY_NAMEは、ロードされるエンティティを表します。例:

- ロールの場合、ログ・ファイル名はoim_blkld_role_load_summary.logです。

- ロール・メンバーシップの場合、ログ・ファイル名はoim_blkld_rolemem_load_summary.logです。

操作中に例外が発生したかどうかを確認するには、このログ・ファイルを開き、Number of Records Rejectedラベルの数を確認します。拒否レコードの数がゼロより大きい場合、操作中に例外がスローされたことになります。ユーティリティに拒否されたユーザー・レコードは、例外表(OIM_BLKLD_EX_SUFFIX)に記録されます。拒否レコードごとに、そのレコードをロードできなかった理由に関する情報が、OIM_BLKLD_EX_SUFFIX表のEXCEPTION_MSG列に格納されます。

例24-3に、OIMロール・データを格納するバルク・ロード操作の最後にログ・ファイルに記録される統計の例を示します。

例24-3 OIMロール・データのロード後に生成されるログ・ファイルの例

***************************************************************************************************
Processing File: Role.csv
==========================================================================================
R O L E    L O A D    S T A T I S T I C S    F O R   F I L E : Role.csv
==========================================================================================
Start Time:   17-NOV-09 02.48.18.447767 AM
End Time:     17-NOV-09 02.48.19.228710 AM
Number of Records Processed:  2
Number of Records Loaded:     2
Number of Records Rejected:   0
==========================================================================================

The name of the TMP table used during the load:
OIM_BLKLD_TMP_ROLE1

The name of the Exception table used during the load:
OIM_BLKLD_EX_ROLE1
==========================================================================================
===============================================================================
Time taken in re-building indexes and enabling FK constraints
===============================================================================

Start time:      17-NOV-09 02.48.19.243781 AM

この例では、拒否ロードの数は2です。すべてのレコードがユーティリティによって拒否されたことがログ・ファイルに示されている場合、これらのレコードのロード操作の再試行の詳細は、「例外の修正およびデータ・レコードのリロード」を参照してください。

注意:

このユーティリティを使用して、リモートのOracle Identity Managerデータベースにデータをロードすることはできません。

24.6.5 例外の修正およびデータ・レコードのリロード

前述のように、バルク・ロード操作中に発生するエラーは、OIM_BLKLD_LOG表に問い合せることで表示できます。次に、エラー・メッセージを取得する問合せの例を示します。

SELECT MSG FROM OIM_BLKLD_LOG
WHERE MODULE = 'ROLE' AND LOG_LEVEL = 'ERROR'
ORDER BY MSG_SEQ_NO;

例外表OIM_BLKLD_EX_SUFFIXは、バルク・ロード操作中に入力ソースとして使用したデータ表ごとに作成されます。操作基準を満たさないレコードは、この例外表にコピーされます。各例外表の名前に追加される接尾辞は、対応するデータ表の名前に追加される接尾辞と同じです。

拒否レコードをリロードするには、次の手順を実行します。

1. 拒否レコードが格納されている例外表のバックアップを作成します。

注意:

この手順はオプションですが、バックアップを作成することをお薦めします。

2. 例外表の各レコードを確認し、EXCEPTION_MSG列に記録されているメッセージに基づいて、データのエラーを修正します。

3. 例外表のすべての拒否レコードのエラーを修正したら、表名をOIM_BLKLD_TMP_SUFFIXに変更し、これを入力ソースとして使用します。

4. ユーティリティを実行して、OIM_BLKLD_TMP_SUFFIX表からレコードをロードします。詳細は、「ユーティリティの実行」を参照してください。

5. oim_blkld_role_load_summary.logファイルまたはロール・メンバーシップ、ロール階層およびロール・カテゴリについて、対応するログ・ファイルでNumber of Records Rejectedラベルの値が0になるまで、手順1から4を繰り返します。

6. Oracle Identity Managerを再起動します。

24.6.6 バルク・ロード操作の結果の検証

バルク・ロード操作の結果を検証するには、ユーティリティによって追加されたOIMロールの1つについて、次の手順を実行できるかどうかをチェックします。

1. Oracle Identity Self Serviceにログインし、新規に作成されたロールがロールの検索結果に表示されていることを確認します。

2. 新規に作成されたロール階層およびロール・メンバーの場合は、ロールの詳細ページでそれぞれ「階層」タブおよび「メンバー」タブをクリックします。

3. 新規に作成されたロール・カテゴリを検証するには、Oracle Identity Administrationの「ようこそ」ページで「拡張検索 - ロール・カテゴリ」をクリックします。拡張検索を実行して、新規に作成されたロールを見つけます。

24.7 操作中に記録されるデータ

バルク・ロード操作中、ユーティリティにより、進捗メッセージおよびエラー・メッセージがOIM_BLKLD_LOG表に挿入されます。この表のデータは、新規バルク・ロード操作の開始時に削除されません。この表の列の1つには、この表にメッセージが記録されたときのタイムスタンプが保持されます。

表24-5に、OIM_BLKLD_LOG表の構造を示します。

表24-5 OIM_BLKLD_LOG表の構造

列

NULL

タイプ

説明

MSG_SEQ_NO

NULL

NUMBER(19)

この列には、メッセージがこの表に挿入される順序を示す番号が格納されます。この列には、OIM_BLKLD_LOG_SEQ順序を使用して、値が移入されます。この列を使用すると、メッセージを表に記録された順序で問い合せることができます。

MODULE

NOT NULL

VARCHAR2(20)

この列には、次の値のいずれかが格納されます。

ROLE: この値は、OIMロール・データのロード中にメッセージが記録されたことを示します。

ROLE HIERARCHY: この値は、ロール階層データのロード中にメッセージが記録されたことを示します。

ROLE MEMBERSHIP: この値は、OIMロール・メンバーシップ・データのロード中にメッセージが記録されたことを示します。

ROLE CATEGORY: この値は、OIMロール・カテゴリ・データのロード中にメッセージが記録されたことを示します。

LOG_LEVEL

NOT NULL

VARCHAR2(20)

この列には、次の値のいずれかが格納されます。

ERROR: デバッグに役立つ詳細な情報イベントを示します。

DEBUG: アプリケーションの続行が可能なエラー・イベントを示します。エラーを使用して、すべての未処理例外がログに記録されます。

PROGRESS_MSG: 中間の進捗メッセージを示します。

LOAD_SOURCE

NOT NULL

VARCHAR2(40)

この列は、行が挿入されたバルク・ロード操作用のデータのソースを示します。値は、次のいずれかです。CSV File: FILE_NAME

DB Table

MSG

NOT NULL

VARCHAR2(4000)

この列には、LOG_LEVEL列に格納されている値に対応するメッセージが格納されます。

CREATE_DATE

DATE

この列には、レコードが作成されたときのタイムスタンプが格納されます。この列のエントリの形式は次のとおりです。

yyyy/mm/dd hh24:mi:ss

例:

2008/06/23 21:49:16:32

24.8 バルク・ロード操作からの診断データの収集

このドキュメントで前述したように、バルク・ロード操作中に、次のログ・ファイルが作成されます。

- OIMユーザーの場合:
oimbulkload/logs_YYYYMMDD_HHMM/oim_blkld_user_load_summary.log

- アカウントの場合:
oimbulkload/logs_YYYYMMDD_HHMM/oim_blkld_account_load_summary.log

- ロール、ロール階層、メンバーシップおよびロール・カテゴリの場合:
oimbulkload/logs_YYYYMMDD_HHMM/oim_blkld_ENTITY_NAME_load_summary.log

ログ・ファイル名のENTITY_NAMEは、ロードされるエンティティを表します。例:

- ロールの場合、ログ・ファイル名はoim_blkld_role_load_summary.logです。

- ロール・メンバーシップの場合、ログ・ファイル名はoim_blkld_rolemem_load_summary.logです。

このファイルに記録されたレコードは、バルク・ロード操作に関するパフォーマンス関連の情報の照合に使用できます。バルク・ロード操作後には、次の情報を収集できます。

- 開始時間

- 入力ソース

- ロード前のシステム内のレコード数

- ロードに成功したレコード数

- 拒否されたレコード数

- 合計所要時間

この情報は、ユーティリティの今後の実行時に使用できます。

関連項目:

エラー・イベントを格納するログ・レベルの詳細は、表24-5「OIM_BLKLD_LOG表の構造」を参照してください。

24.9 バルク・ロード操作後のクリーンアップ

バルク・ロード操作の結果を保存しない場合は、次のようにします。

- OIM_BLKLD_TMP_SUFFIX表、OIM_BLKLD_EX_SUFFIX表およびOIM_BLKLD_LOG表を削除します。

- 操作中に作成または使用したファイルをすべて削除します。

- 操作用の表領域を作成した場合、その表領域を削除します。

- logs_timestampディレクトリに作成されたログ・ファイルを削除する前に、「バルク・ロード操作からの診断データの収集」を参照してください。

注意:

まだOracle Identity Managerを再起動していない場合、この時点で再起動できます。

25 LDAPコンテナ・ルールの構成

以前のバージョンのOracle Identity Managerでは、ロール名(データベースのUGP.UGP_NAME)が一意です。エンタープライズの規模が大きい場合、数多くのロールが存在する可能性があるため、この制限がありますが、管理者は名前が同じで目的の異なる複数のロールをOracle Identity Managerで作成する必要がある場合があります。

Oracle Identity Managerは、LDAP同期を有効にしてインストールできます。リコンシリエーションによってLDAPからロールを取得するときに、複数のロールの名前が同じである場合があります。LDAPでは、ロールが2つの異なる組織単位(OU)に配置されている場合、同じ名前を持つ2つのロールがサポートされます。

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、同じ名前を持つ2つのロールを処理するネームスペースが導入されています。同じ名前を持つロールは、ネームスペースが異なる場合にサポートされます。ただし、同じネームスペースの同じ名前を持つ複数のロールはサポートされていません。

LDAPをOracle Identity Managerと統合すると、ネームスペースはOUにマッピングします。デフォルトの構成では、Defaultと呼ばれるネームスペースが1つだけあるため、ロール名は一意です。複数のネームスペースを構成するには、LDAPContainerRules.xmlという名前のXMLファイルを作成して、メタデータ・ストア(MDS)にロードする必要があります。LDAPContainerRules.xmlによって、ロール属性に基づいてロールのネームスペースも指定されます。

LDAP同期が有効であり、ユーザーを作成する場合は、プラグインによってユーザーを作成するコンテナが決定されます。同様に、ロールを作成する場合は、このプラグインによって、ロールを作成するコンテナが決定されます。この場合、Oracle Identity Managerがoracle.iam.ldapsync.LDAPContainerMapperインタフェースを実装するプラグインを呼び出します。ユーザー/ロールのすべての属性がこのプラグインに渡され、プラグインはLDAPコンテナのドメイン名(DN)を返します。独自のプラグインを記述し、Oracle Identity Managerにこのプラグインを登録して、LDAPContainerMapperPluginシステム・プロパティを設定することによってこのプラグインを使用するようOracle Identity Managerを構成できます。このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する説明を参照してください。

Oracle Identity Managerでは、LDAPに同期化されるユーザーまたはロールの属性に基づいてユーザー/ロールのLDAPコンテナを決定するデフォルト・プラグインが提供されます。このデフォルト・プラグインは、XMLファイルからルールを読み取り、LDAPコンテナを決定します。XMLファイルは/db/LDAPContainerRules.xmlとしてMDSにデプロイされる必要があります。Oracle Identity ManagerをLDAP同期を有効にしてインストールすると、インストーラによってユーザーおよびロールのコンテナ値を要求されます。これらの値は、式がDefaultのコンテナの/db/LDAPContainerRules.xmlファイルに格納されています。次に、例を示します。

<container-rules>
<user>
<rule>
<expression>Country=US, Locality Name=AMER</expression>
<container>l=amer,dc=oracle,dc=com</container>
</rule>
<rule>
<expression >Country=IN, Locality Name=APAC</expression>
<container>l=apac,dc=oracle,dc=com</container>
</rule>
<rule>
<expression>Default</expression>
<container>l=users,dc=oracle,dc=com</container>
</rule>
</user>
<role>
<rule>
<expression>Role Description=AMER</expression>
<description>AMER</description>
<container>l=amer,ou=role,dc=oracle,dc=com</container>
</rule>
<rule>
<expression >Role Description=APAC</expression >
<description>APAC</description>
<container>l=apac,ou=role,dc=oracle,dc=com</container>
</rule>
<rule>
<expression>Default</expression>
<description>Default</description>
<container>l=roles,dc=oracle,dc=com</container>
</rule>
</role>
</container-rules>

LDAPContainerRules.xmlファイルでは、各ルールに次のセクションが含まれています。

- expression: LDAPのネームスペースおよびOUの検索に使用する実際のルールを指定します。
ユーザー/ロールの属性に基づいて<expression>タグが定義されている必要があります。<expression>タグでは、「次と等しい」(=)演算子のみがサポートされます。この例に示すように式は複数の属性に基づくことができ、LDAPコンテナはすべての定義済属性のAND演算子に基づいて決定されます。いずれのルールも満たされていない場合、ユーザーまたはロールは式がDefaultのコンテナに配置されます。

- description: Role Namespace属性に使用されるネームスペースです。
デフォルトの式に関連付けられている説明(ネームスペース)は、常にDefaultを使用します。デフォルトでは、ロールには意味のある式を作成するための属性が数多くありません。このため、Role Location属性など、新しいUser Defined Field (UDF)属性を追加する必要があります。この例では、Role Description属性を使用してルールが定義されています。

- container: LDAPでユーザーまたはロールを作成する場所を確認するために使用するOUです。
属性Country=USおよびLocality Name=AMERを使用してユーザーを作成すると仮定します。このユーザーはコンテナl=amer,dc=oracle,dc=comに作成されます。ユーザーがCountry=FranceおよびLocality Name=FRに作成される場合は、これら2つの属性に一致する式がなく、デフォルト・コンテナが選択されるため、このユーザーはコンテナl=users,dc=oracle,dc=comに作成されます。

26 スケジュール済タスクの開発

Oracle Identity Managerには、ジョブ実行としてスケジュールできる一連のスケジュール済タスクが含まれています。例として、パスワードの期限切れをユーザーに電子メールで送信するパスワード警告タスクをあげることができます。

Oracle Identity Managerには、独自のスケジュール済タスクを作成する機能もあります。事前定義されたスケジュール済タスクがニーズに適合しない場合は、要件に合せてスケジュール済タスクを作成できます。

たとえば、ターゲット・システムで定期的に新しい情報をチェックしてOracle Identity Managerに同じデータを複製するスケジュール済タスクを使用して、リコンシリエーション実行を構成できます。

この章では、カスタム・スケジュール済タスクを作成および実装する方法について説明します。内容は次のとおりです。

- タスク作成の概要

- スケジュール済タスクのメタデータの定義

- スケジュール済タスクXMLファイルの構成

- スケジュール済タスク・クラスの開発

- プラグインXMLファイルの構成

- スケジュール済タスクのディレクトリ構造の作成

- スケジュール済タスクの構成ファイル

- カスタムのスケジュール済タスクを作成するためのベスト・プラクティス

- isStop()メソッドの使用

26.1 タスク作成の概要

この項では、スケジュール済タスクの作成における重要な手順を概説し、プロセスを示す例を紹介します。この後の項では、各手順について詳しく説明します。

- タスク作成の手順

- スケジュール済タスクの例

26.1.1 タスク作成の手順

新しいスケジュール済タスクを作成する基本手順は、次のとおりです。

1. Oracle Identity Managerの事前定義されたスケジュール済タスクを確認して、カスタム・タスクが必要かどうかを決定します。
事前定義されたタスクの詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドのスケジュール済タスクの管理に関する説明を参照してください。

2. タスク名、タスクが実行するアクションを制御するパラメータなど、スケジュール済タスクの主要な機能を決定します。
詳細は、第26.2項「スケジュール済タスクのメタデータの定義」を参照してください。

3. タスク・メタデータをスケジュール済タスクXMLファイルに追加します。
詳細は、第26.3項「スケジュール済タスクXMLファイルの構成」を参照してください。

4. スケジュール済タスクJavaクラスを開発します。
詳細は、第26.4項「スケジュール済タスク・クラスの開発」を参照してください。

5. 新しいスケジュール済タスクをプラグインとして宣言します。
詳細は、第26.5項「プラグインXMLファイルの構成」を参照してください。

6. Oracle Identity Managerがファイルを検出し、タスクをジョブで使用できるようにするために、タスク・ファイルをパッケージ化します。
詳細は、第26.6項「スケジュール済タスクのディレクトリ構造の作成」を参照してください。

26.1.2 スケジュール済タスクの例

スケジュール済タスクの開発の手順を示すために、特定のITリソースの特定の部門に属する従業員レコードを取得するスケジュール済タスク例を使用します。

また、このスケジュール済タスクでは、ユーザーが取得するレコード数や、無効なレコードを取得に含めるかどうかを指定できる必要があります。

26.2 スケジュール済タスクのメタデータの定義

各スケジュール済タスクは、次のメタデータ情報を含みます。

- スケジュール済タスクの名前

- スケジュール済タスクを実装するJavaクラスの名前

- 説明

- 再試行間隔

- (オプション)スケジュール済タスクを受け入れるパラメータ。各パラメータには次の追加情報が含まれます。

- パラメータ名

- パラメータのデータ型

- 必須/オプション・パラメータ

- ヘルプ・テキスト

26.3 スケジュール済タスクXMLファイルの構成

スケジュール済タスクXMLファイルの構成では、カスタム・スケジュール済タスクの定義が含まれたXMLファイルの更新が伴います。この項では、新しいカスタム・スケジュール済タスクの詳細を使用してタスクXMLファイルを更新する方法について説明します。

Oracle Identity Manager MDSスキーマの/dbネームスペースにあるtask.xmlファイルを変更するか、またはカスタム・スケジュール済タスク・ファイルを作成できます。カスタム・ファイルを作成する場合、そのファイル名はスケジュール済タスク名と同じで、拡張子が.xmlである必要があります。Oracle Identity Manager MDSスキーマの/dbネームスペースに、カスタム・スケジュール済タスク・ファイルをインポートする必要があります。

関連項目:

プラグインの例は、第27章「プラグインの開発」を参照してください。

注意:

Oracle Enterprise Managerを使用して、スケジュール済タスクXMLファイルをMDSにインポートできます。クラスタ環境では、MDSにファイルを含めることで、クラスタの各ノード上のファイルをコピーする必要がなくなります。

MDSへのファイルのインポートの詳細は、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。

XMLファイル内の要素は、第26.2項「スケジュール済タスクのメタデータの定義」で説明したタスク・パラメータを反映します。

例26-1に、前述の段落で説明したスケジュール済タスクのサンプルXMLコードを示します。この例では、すべてのパラメータが必須パラメータとして宣言されていることに注意してください。

例26-1 スケジュール済タスクのサンプルXML

<scheduledTasks xmlns="http://xmlns.oracle.com/oim/scheduler">
<task>
<name>Test_scheduled_task</name>
<class>oracle.iam.scheduler.TestScheduler</class>
<description>Retrieve Employee Records For Given Department</description>
<retry>5</retry>
<parameters>
<string-param required="true" helpText="Name of the department">Department Name</string-param>
<string-param required="true" encrypted="false" helpText="Name of the department">Department Name</string-param>
<number-param required="true" helpText="Number of Records to Be Retrieved">Number of Records</number-param>
<boolean-param required="false" helpText="Retrieve disabled employee records?">Get Disabled Employees</boolean-param>
</parameters>
</task>
</scheduledTasks>

関連項目:

スケジュール済タスクの構成ファイル内の要素の詳細は、「スケジュール済タスクの構成ファイル」を参照してください。

これは、基本的に、MDSからtask.xmlをエクスポートし、それに必須タグを追加して、MDSにインポートして戻す作業となります。

注意:

プラグインで定義されたタスクでは、MDSへシードするためにメタデータXMLは必要ありません。これは、プラグインZIPファイルのMETA-INFフォルダに含めることができます。詳細は、「スケジュール済タスクのディレクトリ構造の作成」を参照してください。

MDSからtask.xmlファイルをエクスポートし、このファイルに必須タグを追加した後、MDSにインポートして戻す必要があります。MDSファイルのエクスポートおよびインポートの詳細は、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。

26.4 スケジュール済タスク・クラスの開発

次の手順では、Javaクラスを作成して、メタデータがXMLファイルで定義されたタスクを実行します。スケジュール済タスクを実装するJavaクラスは、スケジュール済タスク・クラスと呼ばれます。

スケジュール済タスクのJavaクラスを開発するには、次の手順を実行します。

1. oracle.iam.scheduler.vo.TaskSupportクラスを拡張したJavaクラス・ファイルを作成し、要件に基づいた処理ロジックでexecute()メソッドをオーバーライドします。

2. 作成したJavaクラスのJARファイルを作成します。JARをカスタム・スケジュール済タスクに簡単に関連付けできる名前をJARに付けます。
JARファイルには、Javaクラスの依存クラスを含めることができます。依存クラスに対して個別のJARファイルを作成し、それをlib/ディレクトリに配置することもできます。

3. JARファイルをlib/ディレクトリにコピーします。

4. 作成する各Javaクラスに対して手順1から3を繰り返します。

26.5 プラグインXMLファイルの構成

スケジュール済タスクをプラグインとして宣言するには、plugin.xmlファイルを構成する必要があります。プラグインの詳細は、第27章「プラグインの開発」を参照してください。

注意:

1つのスケジュール済タスクに対して1つのplugin.xmlファイルを作成することをお薦めします。これは、プラグインが登録解除されると、対応するパッケージが削除されるためです。

plugin.xmlファイルを構成するには、次の手順を実行します。

1. 任意のテキスト・エディタを使用して、plugin.xmlファイルを作成します。

注意:

plugin.xmlファイルは、そのようなファイルがない場合にのみ作成します。既存のプラグインがある場合は、新しいプラグイン用の新しいプラグイン要素を追加します。

2. プラグイン要素のpluginpoint属性の値をoracle.iam.scheduler.vo.TaskSupportに変更して、スケジュール済タスクのプラグイン・ポイントを指定します。
plugin.xmlファイルの次のXMLコード・ブロックは、プラグイン要素内に入力された値を示しています。

<plugins pluginpoint="oracle.iam.scheduler.vo.TaskSupport">

注意:

スケジュール済タスクの場合、<plugins>要素は、すべてのスケジュール済タスクで同じままです。

3. <plugin>要素を、追加する各スケジュール済タスクに追加します。

プラグイン(この場合はスケジュール済タスク)を実装するクラスを指定するには、プラグイン要素のpluginclass属性の値を、スケジュール済タスクを実装するJavaクラスの名前に変更します。plugin.xmlファイルの次のXMLコード・ブロックは、プラグイン要素内に入力されたサンプル値を示しています。

<plugin pluginclass= "oracle.iam.scheduler.TestScheduler" version="1.0.1" name="scheduler element"/>

変更後、plugin.xmlファイルは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.scheduler.vo.TaskSupport">
<plugin pluginclass= "oracle.iam.scheduler.TestScheduler"
version="1.0.1" name="scheduler element">
</plugin>
</plugins>
</oimplugins>

4. plugin.xmlファイルを保存して閉じます。

26.6 スケジュール済タスクのディレクトリ構造の作成

スケジュール済タスクの構成の最後の手順は、例26-2で指定したディレクトリ構造のplugin.zipファイルを作成することです。この例では単一のプラグインが追加されますが、複数のプラグインをplugin.zipファイルに含めることができます。スケジューラでは、ファイルが、特定の構造で圧縮され、特定のネーミング規則に従って命名されている必要があります。これにより、Oracle Identity Managerがカスタム・スケジュール済タスクを識別し、ジョブの作成中にOracle Identity System Administrationで使用可能になることを確認できます。

例26-2 スケジュール済タスクのディレクトリ構造

plugin/
lib/
PLUGIN.JAR
plugin.xml
META-INF (optional)
METADATA.xml

次のことに注意してください。

- プラグインのXMLファイルは、plugin.xmlという名前である必要があります。

- lib/ディレクトリには.JARファイルのみが含まれている必要があります。lib/ディレクトリは、プラグイン・ロジックを実装するクラスが含まれたJARファイル、および依存ライブラリのJARファイルで構成されています。ほとんどの場合、このディレクトリは、plugin.xmlに指定されたすべてのプラグインの実装を含む1つのJARファイルで構成されます。ディレクトリ構造の詳細は、「プラグインの開発」を参照してください。

- スケジュール済タスクのディレクトリには、次のファイルが格納されている必要があります。

- プラグイン用のXML

- JARファイル

- 作成するすべてのプラグインに対して1つのplugin.zipファイルが存在します。

- META-INFフォルダは、メタデータ(タスク定義)ファイルを格納できるオプションのフォルダです。このファイルがMETA-INFフォルダに配置されている場合、MDSにシードする必要はありません。

- META-INFフォルダが存在しない場合、またはメタデータ・ファイルがMETA-INFフォルダに配置されていない場合は、ファイルをMDSにシードします。

前述の例では、CLASS_NAME.JARが、第26.4項「スケジュール済タスク・クラスの開発」で作成したJARファイルです。

plugin.zipファイルを作成した後でクラスタ環境にデプロイする場合は、適切なAPIを使用して、そのプラグインをデータベースに登録します。APIを使用してOracle Identity Managerにプラグインを登録する方法の詳細は、APIを使用したプラグインの登録および登録解除に関する説明を参照してください。

注意:

プラグインのXMLは、plugin.xmlという名前である必要があります。libディレクトリにJARファイルのみが含まれていることを確認してください。

26.7 スケジュール済タスクの構成ファイル

この付録では、スケジューラ・タスクの定義を含むXMLファイルの構造および構成要素について説明します。

- スケジューラXMLファイルの構造

- scheduledTasks要素

- task要素

- name要素

- class要素

- description要素

- retry要素

- parameters要素

- string-param要素

- number-param要素

- boolean-param要素

26.7.1 スケジューラXMLファイルの構造

次に、構成XMLファイル内の要素のリストを示します。

<scheduledTasks xmlns="http://xmlns.oracle.com/oim/scheduler">
<task>
<name>
<class>
<description>
<retry>
<parameters>
<string-param>
.....
</string-param>

<number-param>
.......
</number-param>

<boolean-param>
.......
</boolean-param>
</parameters>
</task>
</scheduledTasks>

26.7.2 scheduledTasks要素

scheduledTasks要素は、スケジュール済タスクの定義に使用されるXMLのルート要素です。

表26-1に、scheduledTasks要素のプロパティの概要を示します。

表26-1 scheduledTasks要素のプロパティ

プロパティ

値

親要素

該当なし

属性

次のように、XML名前空間をscheduledTasks要素の属性として指定します。

<scheduledTasks xmlns="http://xmlns.oracle.com/oim/scheduler">

注意: xmlnsパラメータは必須です。

子要素

タスク

出現回数

作成するスケジュール済タスクXMLファイルごとに1つ

要素値

該当なし

必須かオプションか

必須

26.7.3 task要素

task要素は、scheduledTasks要素の子要素です。

task要素は、スケジュール済タスクを定義するために使用します。task要素には、スケジュール済タスクの名前、クラス、説明、再試行回数などの情報が含まれます。

表26-2に、task要素のプロパティの概要を示します。

表26-2 task要素のプロパティ

プロパティ

値

親要素

scheduledTasks

属性

なし

子要素

name、class、description、retryおよびparameters

出現回数

作成するタスクごとに1つ

注意: 単一のスケジュール済タスクXMLファイルに複数のタスクを定義する場合は、定義するスケジュール済タスクごとに1つのtask要素を使用する必要があります。

要素値

該当なし

必須かオプションか

必須

26.7.4 name要素

name要素は、task要素の子要素です。name要素は、作成するスケジュール済タスクの名前を指定するために使用します。

表26-3に、name要素のプロパティの概要を示します。

表26-3 name要素のプロパティ

プロパティ

値

親要素

タスク

属性

なし

子要素

なし

出現回数

1回

要素値

作成するスケジュール済タスクの名前。

注意: スケジュール済タスクの名前は一意にする必要があります。

必須かオプションか

必須

26.7.5 class要素

class要素(必須)は、task要素の子要素です。class要素は、スケジュール済タスクを実行するJavaクラスの名前を指定するために使用します。

表26-4に、class要素のプロパティの概要を示します。

表26-4 class要素のプロパティ

プロパティ

値

親要素

タスク

属性

なし

子要素

なし

出現回数

1回

要素値

スケジュール済タスクを実行するJavaクラスの名前。スケジュール済タスクのクラスを開発する方法の詳細は、「スケジュール済タスク・クラスの開発」を参照してください。

必須かオプションか

必須

26.7.6 description要素

description要素(必須)は、task要素の子要素です。description要素は、作成するタスクの説明を追加するために使用します。

表26-5に、description要素のプロパティの概要を示します。

表26-5 description要素のプロパティ

プロパティ

値

親要素

タスク

属性

なし

子要素

なし

出現回数

1回

要素値

作成するタスクの説明

必須かオプションか

必須

26.7.7 retry要素

表26-6に、retry要素のプロパティの概要を示します。

表26-6 retry要素のプロパティ

プロパティ

値

親要素

タスク

属性

なし

子要素

なし

出現回数

1回

要素値

スケジューラによってタスクが再スケジュールされるまでの待機時間(秒数)

必須かオプションか

必須

26.7.8 parameters要素

スケジュール済タスクでジョブを正常に実行するために必要なパラメータを実行時に指定する場合は、parameters要素を使用する必要があります。たとえば、取得するレコードの数を実行時にユーザーに指定させるスケジュール済タスクを作成できます。

この要素の中で指定するパラメータは、「ジョブの作成」ページの「パラメータ」セクションに表示されます。

表26-7に、parameters要素のプロパティの概要を示します。

表26-7 parameters要素のプロパティ

プロパティ

値

親要素

タスク

属性

なし

子要素

string-param、number-param、boolean-param

出現回数

1回

要素値

該当なし

必須かオプションか

オプション

26.7.9 string-param要素

string-param要素は、文字列データ型の値をとるフィールドの名前を指定するために使用します。言い換えると、string-param要素では、文字列データ型の値を保持できるフィールドのラベルを指定します。

表26-8に、string-param要素のプロパティの概要を示します。

表26-8 string-param要素のプロパティ

プロパティ

値

親要素

パラメータ

属性

required、helpText、encrypted

子要素

なし

出現回数

Stringデータ型のパラメータごとに1つ

要素値

文字列パラメータの名前

必須かオプションか

オプション

表26-8に示すように、string-param要素には次の属性が含まれています。

- required
これは必須の属性で、値はtrueまたはfalseのいずれかです。

required属性の値がtrueの場合は、パラメータの値を実行時に必ず入力する必要があります。

required属性の値がfalseの場合は、パラメータの値を実行時に入力することは必須ではありません。

- helpText
この属性では、フィールドへの入力内容をユーザーが把握できるように、実行時に表示するテキストを指定します。通常は、パラメータによって作成されるフィールドの説明を指定します。

- encrypted
デフォルトでは、値はfalseになりますが、trueまたはfalseのどちらも指定できます。

encrypted属性の値がtrueの場合は、実行時に入力されるパラメータ値は暗号化された形式で格納されます。

required属性の値がfalseの場合は、実行時に入力されるパラメータ値はプレーン・テキストで格納されます。

26.7.10 number-param要素

number-param要素は、longデータ型の値をとるフィールドの名前を指定するために使用します。

表26-9に、number-param要素のプロパティの概要を示します。

表26-9 number-param要素のプロパティ

プロパティ

値

親要素

パラメータ

属性

required、helpText

子要素

なし

出現回数

longデータ型のパラメータごとに1つ

要素値

longデータ型を保持できるフィールドの名前

必須かオプションか

オプション

require属性とhelpText属性の動作および説明は、number-param要素とstring-param要素で同じです。require属性とhelpText属性の詳細は、「string-param要素」を参照してください。

26.7.11 boolean-param要素

boolean-param要素は、ブール・データ型の値をとるフィールドの名前を指定するために使用します。

表26-10に、boolean-param要素のプロパティの概要を示します。

表26-10 boolean-param要素のプロパティ

プロパティ

値

親要素

パラメータ

属性

required、helpText

子要素

なし

出現回数

ブール・データ型のパラメータごとに1つ

要素値

ブール・データ型を保持できるフィールドの名前

必須かオプションか

オプション

required属性とhelpText属性の動作および説明は、boolean-param要素とstring-param要素で同じです。require属性とhelpText属性の詳細は、「string-param要素」を参照してください。

26.8 カスタムのスケジュール済タスクを作成するためのベスト・プラクティス

表26-11に、カスタムのスケジュール済タスクの作成に変数/定数を使用するためのガイドラインを示します。

表26-11 カスタムのスケジュール済タスクを作成するための変数および定数

タイプ

例

値の格納/検索元

ターゲット・システム接続の詳細

ホスト名、ポート番号、SSL

ITリソース/アプリケーション・インスタンス

ターゲット・システムの構成

属性マッピング、一意属性、ユーザー・オブジェクト・クラス

参照

スケジュール済ジョブ固有の変数/定数

アプリケーション・インスタンス名、ITリソース名、ファイル・パス、検索フィルタ、バッチ・サイズ、再試行

スケジュール済ジョブ

スケジュール済ジョブの詳細構成変数/定数

属性マッピング、ターゲット・システムの日付書式、定数、属性トランスフォーメーション・クラス

参照

Oracle Identity Manager固有のシステム・ワイドの非常に静的な構成プロパティ/定数/変数

デフォルトの日付書式、ユーザー名生成に関するデフォルト・ポリシー

システム・プロパティ

電子メール通知

件名、本文、宛先、差出人

電子メール・テンプレート

26.9 isStop()メソッドの使用

Oracle Identity System Administrationの「スケジューラ」セクションからジョブが停止されても、ジョブは停止されず、そのまま実行されます。スケジュール済タスクを停止するには、次の手順を実行します。

カスタムのスケジュール済タスクを開発すると、実行メソッド内部の様々なステージでisStop()メソッドまたはisStopped()メソッドを呼び出すことができます。このメソッドがtrueを返す場合は、実行メソッドから返されます。実行メソッド内部にループがあれば、ループの反復ごとにisStop()メソッドまたはisStopped()メソッドが必ず呼び出されます。

実行メソッドでは、ジョブ・ステータスを取得するためのチェックを追加します。これは、com.thortech.xl.scheduler.tasks.SchedulerBaseTaskクラスのisStopped()メソッドを呼び出すことで取得できます。isStopped()メソッドによりTRUEが返されると、スケジュール済タスクに対して何も実行せずに実行メソッドが返されます。このコード・スニペットを次に示します。

if(isStopped())
return;

Oracle Identity Manager 11g リリース1 (11.1.1)または11g リリース2 (11.1.2)のTaskSupportクラスを拡張してカスタムのスケジュール済タスクを開発する場合は、実行メソッドでisStop()メソッドを呼び出します。

カスタムのスケジュール済タスク・コードがOracle Identity Managerリリース9.xのレガシーcom.thortech.xl.scheduler.tasks.SchedulerBaseTaskクラスを拡張する場合、実行メソッドでisStopped()メソッドを呼び出します。

第VI部

カスタム操作

この部は、Oracle Identity Managerでのカスタマイズされた操作の開発方法について説明する各章で構成されています。

次の章で構成されます。

- 第27章「プラグインの開発」

- 第28章「イベント・ハンドラの開発」

- 第29章「コンテキストの理解」

27 プラグインの開発

この章では、プラグインに関連する概念、プラグインを開発および使用する方法について、次の各項で説明します。

- プラグインおよびプラグイン・ポイント

- デプロイメントでのプラグインの使用

- プラグイン・ポイント

- プラグインの構成

- カスタム・プラグインの開発

- プラグインの登録

- プラグインの移行

27.1 プラグインおよびプラグイン・ポイント

プラグインは、Oracle Identity Managerによって提供される機能の機能性を拡張する論理的なコンポーネントです。プラグイン・フレームワークにより、各機能によって提供される機能性を拡張するプラグインを定義、登録および構成できます。プラグインは、事前定義またはカスタム開発でき、プラグイン・ポイントで使用できます。プラグイン・ポイントは、拡張性を追加できる、ビジネス・ロジック内の特定のポイントです。そのようなポイントには、プラグイン・インタフェースと呼ばれるインタフェース定義が付随しています。ビジネス要件に基づいてプラグイン・インタフェースを拡張し、プラグインとして登録できます。これを行うには、プラグインJavaクラスを開発し、JARファイルへのアーカイブ、XMLファイルでのプラグイン・メタデータの定義およびデプロイの準備ができたプラグイン・パッケージとしてのこれらのアーティファクトの圧縮を行う前にコンパイルします。

たとえば、ユーザーの作成は、Oracle Identity Managerのビジネス操作です。ただし、この操作はユーザー名の生成のプラグイン・ポイントを公開します。ユーザー名生成のカスタム・ロジックをモデル化する場合、プラグイン・ポイントの仕様を識別し、プラグインを適宜開発する必要があります。

プラグインに関連する概念は、次の項で説明されています。

- プラグインおよびイベント・ハンドラ

- プラグイン・ストア

27.1.1 プラグインおよびイベント・ハンドラ

ユーザー作成、ユーザーへのロールの割当て、ユーザーのアクティブ化などOracle Identity Managerのビジネス操作のほとんどは、編成として実行されます。そのため、これらの操作または編成のカスタム・ロジックに起因する要件がある場合、カスタマイズがサポートされている検証、前処理および後処理などのステージのイベント・ハンドラとしてそのロジックをモデル化できます。ただし、そのような操作でカスタム・ロジックに起因するプラグインを公開するかどうかも分析できます。プラグイン・ポイントが使用可能な場合、基礎となる編成を操作するのではなく、プラグイン・ポイントを利用できます。たとえば、ユーザー作成編成でイベント・ハンドラとして記述せずに、公開されたプラグインを使用することで、ユーザー名生成を実装することができます。

図27-1は、プラグインおよびイベント・ハンドラをダイアグラムで表しています。

図27-1 プラグインおよびイベント・ハンドラ

27.1.2 プラグイン・ストア

プラグイン・フレームワークでは、次の2つのタイプのストアにプラグインを格納できます。

- ファイル・システム

- Oracle Identity Managerデータベース

プラグインを検索する場合は、フレームワークによって、データベースに登録されているプラグインが最初に調べられてから、ファイル・システムが調べられます。

27.1.2.1 ファイル・ストア

ファイル・ストアは、Oracle Identity Managerホスト上の1つ以上のディレクトリで構成されており、主に開発環境で使用されます。このタイプのストアは、本番環境には適していません。ファイル記憶域は、開発したプラグインをファイル・ストアに明示的に登録する必要がないため、開発者にとって便利です。ユーザーは、プラグインzipまたは展開されたプラグイン・ディレクトリを指定の場所にドロップインするだけです。

デフォルトでは、プラグインはプラグイン・フレームワークによってOIM_HOME/pluginsディレクトリで検索されます。プラグイン・ディレクトリを追加指定することもできます。

監視スレッドが有効な場合は、プラグイン・フレームワークによって、ファイル・システム内の登録済プラグイン・ディレクトリでプラグインzipファイルのすべての追加、変更および削除が監視され、プラグインは自動的にリロードされます。名前、バージョン、IDなどのプラグイン・メタデータがプラグインzipから読み取られ、メモリー内で維持されます。このメタデータは、ファイルの変更に基づいて更新されます。最新のプラグインzipファイルが、現行バージョンのプラグインとみなされます。ファイル・ストアの構成方法の詳細は、「プラグインの構成」を参照してください。

注意:

本番状態のファイル・ストアを使用することは推奨されていません。ファイル・ストアは、プラグインの変更が簡単で、ファイル・システムのファイルのみを変更するため、プラグインの開発に適しています。登録する必要はありません。ただし、本番では、プラグインは頻繁に変更されず、特定のデメリットがあるため、ファイル・ストアの使用は避けてください。ファイル・ストアの監視のオーバーヘッドを追加します。また、プラグインは、Oracle Identity Managerのクラスタ化されたデプロイメントのクラスタのすべてのノードでレプリケートする必要があります。

27.1.2.2 データベース・ストア

プラグインはOracle Identity Managerデータベースに格納できるため、クラスタ内の任意のノードからアクセスできます。プラグイン・フレームワークでは、データベース・ストアとして業務系DBが使用されます。このタイプのストアは、本番環境に適しています。

データベースに格納されるプラグインは、明示的に登録する必要があります。コマンドライン・ツールであるプラグイン登録ユーティリティを使用して、プラグインを登録および登録解除できます。また、registerPlugin APIをこの用途に使用することもできます。プラグインの登録の詳細は、「APIを使用したプラグインの登録および登録解除」を参照してください。

注意:

プラグインを登録した後で、サーバーを再起動する必要があります。ただし、サーバーの再起動は、プラグイン・ポイントを定義する機能に依存する場合もあります。

27.2 デプロイメントでのプラグインの使用

このドキュメントで前述したように、プラグインは、Oracle Identity Managerデプロイメントのデフォルト機能のカスタマイズに使用されます。サポートされるプラグイン・ポイントの数は、定義済で、制限されています。そのため、プラグイン・ポイントを使用して、サポートされるプラグイン・ポイントのリストに関してのみ、機能を拡張することができます。サポートされるプラグイン・ポイントのリストは、「プラグイン・ポイント」を参照してください。

27.3 プラグイン・ポイント

表27-1に、Oracle Identity Managerでプラグイン・ポイントとして機能するJavaインタフェースを示します。

表27-1 プラグイン・ポイント

プラグイン・ポイント

説明

oracle.iam.ldapsync.LDAPContainerMapper

これは、LDAPでユーザーまたはロールを作成するために使用する必要があるユーザー・コンテナまたはロール・コンテナを決定するために、LDAP同期によって使用されます。

oracle.iam.platform.kernel.spi.EventHandler

これは、カーネル・イベント・ハンドラです。カーネル・イベント・ハンドラの詳細は、第28章「イベント・ハンドラの開発」を参照してください。

oracle.iam.platform.auth.api.LoginMapper

これは、JAASユーザー・プリンシパル名を対応するOracle Identity Managerユーザー名にマップするLoginMapperの実装です。このプラグイン・ポイントは、SSOシナリオのJAASユーザー・プリンシパル名からOracle Identity Managerユーザー名へのデフォルトのマッピングをオーバーライドするために使用されます。デフォルトの実装では、JAASユーザー・プリンシパル名と同じ値が返されます。このプラグイン・ポイントは、通常、JAASユーザー・プリンシパル名とOracle Identity Managerユーザー名が異なる場合があるSSOシナリオで使用されます。たとえば、SSOシステムで電子メールがJAASユーザー名として設定される場合がありますが、そのユーザー名を持つユーザーはOracle Identity Managerには存在しません。Oracle Identity Managerでそのユーザーが認識されるには、JAASユーザー・プリンシパル名をOracle Identity Managerユーザー名にマップする必要があります。これを実行するには、次に示すように、LoginMapperのプラグインを実装します。

public class CustomLoginMapper implements LoginMapper{
public String getOIMUserID(String jaasPrincipal) throws MappingException {
return getUserName(jassPrincipal);
}

private String getUserName(String emailID){
String userName = null;

//Use usermgmt APIs to get the username corresponding to this email id
return userName;
}
}

oracle.iam.identity.usermgmt.api.PasswordVerifier

これは、ユーザーのパスワード変更時に古いパスワードを検証するために使用されます。この検証に使用されるクラスは、OIM.OldPasswordValidatorシステム・プロパティで構成します。デフォルトでは、古いパスワードの検証にはコンテナ・ベースの認証を使用します。

oracle.iam.request.plugins.StatusChangeEvent

これにより、リクエスト・ステータス変更中にカスタム・コードを実行できます。

oracle.iam.request.plugins.RequestDataValidator

これは、送信後のリクエスト・データのカスタム検証に使用されます。

oracle.iam.request.plugins.PrePopulationAdapter

これは、リクエスト作成中にカスタム・コードを実行することで属性値を事前移入するために使用されます。

oracle.iam.scheduler.vo.TaskSupport

これは、コンテキストでジョブを実行するために使用されます。タスクの実行メソッドがプラグインによって取得され、ロードされます。

oracle.iam.identity.usermgmt.api.UserNamePolicy

これは、ユーザー名の生成および検証に使用されるユーザー名ポリシーの実装です。

oracle.iam.identity.usermgmt.api.ReservationInLDAP

これは、LDAPでのユーザー属性の予約の実装です。

27.4 プラグインの構成

MDS内のoim-config.xmlファイルを使用して、次のものを構成します。

関連項目:

oim-config.xmlファイルの構成の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのoim-config.xmlファイルの構成に関する説明を参照してください。

- ファイル・ストアによってプラグインが検索されるディレクトリ。

- ファイル・ストアに変更があるかどうかを監視するスレッドをアクティブにするかどうか(このスレッドによって、すべてのプラグイン・ディレクトリ内のzipファイルまたは展開されたファイルが確認されます)。
監視スレッドは、動的開発環境ではプラグインが追加または変更されているため通常はアクティブ化されており、一連のプラグインが含まれている本番システムでは非アクティブにすることができます。これは、reloadingEnabled属性を使用して追跡できます。

- 監視スレッドがウェイクアップして変更を検索する間隔。

次に、oim-config.xmlファイルのコード・スニペットを示します。

<pluginConfig storeType="common">

<storeConfig reloadingEnabled="true"

reloadingInterval="20">

<!--

Plugins present in the OIM_HOME/plugins directory are added by default.

For adding more plugins, specify the plugin directory as below:

<registeredDirs>/scratch/oimplugins</registeredDirs>

<registeredDirs>/scratch/custom</registeredDirs>

-->

</storeConfig>

</pluginConfig>

この例の内容は次のとおりです。

- commonストア指定によって、フレームワークはデータベースとファイル・ストアの両方を監視するように指定されます。

注意:

commonはすべての環境で適切であるため、Store値は変更しないでください。

- 1つのディレクトリが構成されますが、<registeredDirs>タグを追加することによって追加ディレクトリを構成できます。

- デフォルトで、監視スレッドがアクティブであり、プラグインの変更が20秒ごとに検索されます。
監視は、通常は開発環境のみでアクティブです。アクティブと非アクティブを切り替える場合は、アプリケーション・サーバーを再起動して変更を有効にする必要があります。

注意:

oim-config.xmlファイルのプラグイン・データのあらゆる変更に、アプリケーション・サーバーの再起動が必要です。

27.5 カスタム・プラグインの開発

この項では、カスタム・プラグインの開発方法について説明します。この章には次の項目があります。

- プラグインの開発

- プラグインの宣言

27.5.1 プラグインの開発

プラグインを開発するには:

1. 拡張するプラグイン・ポイントを識別します。

2. プラグイン・ポイント・インタフェースを実装するJavaクラスを識別します。Javaクラスおよびその他の依存クラスをJARファイルにパッケージ化します。JARファイルをlib/ディレクトリに置きます。

3. plugin.xmlファイルを作成します。詳細は、「プラグインの宣言」を参照してください。

4. プラグインに必要なリソース・ファイル(プロパティ・ファイル、リソース・バンドル、画像ファイルなど)を識別します。

5. パッケージ全体をZipに圧縮します。
Oracle Identity Managerプラグインは、指定されたディレクトリ構造でZIPファイルとして配布されます。そのディレクトリ構造は次のとおりです。

- plugin.xmlファイル: XMLファイルには、すべてのプラグインに関連付けられたメタデータ(拡張されるプラグイン・ポイント、プラグインを実装するクラス、名前、バージョン番号など)が含まれています。XML内のすべてのフィールドは、名前を除いて必須です。名前を指定しない場合は、プラグイン・クラス名が名前として使用されます。

- lib/ディレクトリ: lib/ディレクトリは、プラグイン・ロジックを実装するクラスを含むJARファイルおよび依存ライブラリJARファイルで構成されています。ほとんどの場合、このディレクトリは、plugin.xmlに指定されたすべてのプラグインの実装を含む1つのJARファイルで構成されます。

- resources/ディレクトリ: プラグインに必要なリソース・ファイル(プロパティ・ファイル、リソース・バンドル、画像ファイルなど)が含まれています。プラグインzipのresourcesディレクトリに指定されたこれらのリソースには、次のようにアクセスできます。

this.getClass().getClassLoader().getResourceAsStream(<resource_name>);

- META-INF/ディレクトリ: イベント・ハンドラのプラグイン・ポイントを示すXMLファイルが含まれています。通知サービスなどの一部のサービスは、MDSまたはプラグインのMETA-INF/ディレクトリからこのXMLファイルを読み取ります。

同じプラグイン・ポイントを実装する複数のプラグインを、同じZIPファイルの一部にすることができます。

プラグインには、プラグイン・ポイント・インタフェースを実装するJavaクラスがあります。プラグイン・ライブラリ(JAR)にその他の依存クラスも含めることができますが、プラグインを実装するクラスは、機能に対して公開される1つのみです。このクラスをplugin.xmlで指定する必要があります。

6. ZIPファイルをファイル・ストア(OIM_HOME/plugins/ディレクトリ)またはデータベース・ストアに配置します。

7. ZIPをデータベース・ストアに置く場合は、「プラグインの登録」で説明するように、プラグイン登録ユーティリティを使用してプラグインを登録します。

27.5.2 プラグインの宣言

Oracle Identity Managerで提供される機能を拡張するために、アプリケーションに対してプラグインを宣言できます。

プラグインには、プラグイン・ポイント・インタフェースを実装するJavaクラスがあります。特定のプラグイン・ポイントに関連付けられるすべてのプラグインに、一意の名前を割り当ててください。プラグイン名が一意でないと、プラグインの登録時に例外がスローされます。

プラグインをplugin.xmlファイルで宣言します。例:

<?xml version="1.0" encoding="UTF-8"?>
<oimplugins>
....
<plugins pluginpoint="oracle.iam.sample.passwdmgmt.service.PasswordElement">
<plugin pluginclass=
"oracle.iam.sample.passwdmgmt.custom.NumCustomPasswordElement"
version="1.0.1" name="num pwd element"/>
<plugin pluginclass=
"oracle.iam.sample.passwdmgmt.custom.DictionaryPasswordElement"
version="1.0.1" name="Dictionary password element" />
</plugins>
....
</oimplugins>

注意:

複数のバージョンのプラグインを格納でき、機能によって特定のバージョンのプラグインをプラグイン・フレームワークからリクエストできます。デフォルトでは、現在のすべてのプラグイン・ポイントがプラグインの最新のバージョンをロードします。

このXMLには、2つのプラグイン宣言があります。両方のプラグインが同じプラグイン・ポイントから拡張されます。

27.6 プラグインの登録

APIおよびプラグイン登録ユーティリティを使用して、プラグインを登録できます。

- APIを使用したプラグインの登録および登録解除

- プラグイン登録ユーティリティを使用したプラグインの登録および登録解除

27.6.1 APIを使用したプラグインの登録および登録解除

登録関連のタスクには、次のAPIを使用できます。

- PlatformService.registerPlugin

- PlatformService.unRegisterPlugin

次に例を示します。

ClientPlatform platform = OIMClient.getInstance();
platform.login("username", "password");
PlatformService service = platform.getService(PlatformService.class);
File zipFile = new File(fileName);
FileInputStream fis = new FileInputStream(zipFile);
int size = (int) zipFile.length();
byte[] b = new byte[size];
int bytesRead = fis.read(b, 0, size);
while (bytesRead < size) {
bytesRead += fis.read(b, bytesRead, size - bytesRead);
}
fis.close();
service.registerPlugin(b);
service.unRegisterPlugin(pluginID, version);

27.6.2 プラグイン登録ユーティリティを使用したプラグインの登録および登録解除

プラグインの登録および登録解除にプラグイン登録ユーティリティを使用できます。このユーティリティでは、次のファイルが使用されます。

- pluginregistration.xml

- ant.properties

これらのファイルは、OIM_HOME/plugin_utility/ディレクトリにあります。

注意:

プラグイン登録ユーティリティには、Apache Antバージョン1.7以上が必要です。

このユーティリティを使用する前に、次のことを実行します。

1. ant.propertiesのWLS_HOMEおよびOIM_HOMEの値を設定します。
例:

WLS_HOME =.../middleware/wlserver_10.3
OIM_HOME =..../middleware/Oracle_IDM1/server

さらに、ant.propertiesファイル内でMW_HOMEのパスを設定します。

2. Oracle WebLogic serverでwlfullclient.jarをビルドします。

1. ディレクトリをWLS_HOME/server/libに変更します。

2. 次のコマンドを実行します。

java -jar ../../../modules/com.bea.core.jarbuilder_1.3.0.0.jar

注意:

JARファイルの正確なバージョンは、WLSによって異なる場合があります。WLS_HOME/../modules/ディレクトリにあるcom.bea.core.jarbuilderという名前の対応するファイルを使用します。

プラグインの登録

プラグインを登録する手順は、次のとおりです。

1. antターゲットの登録を実行します。

ant -f  pluginregistration.xml register

2. これにより、Oracle Identity Managerのユーザー名およびパスワードとサーバー情報およびプラグインzipファイルの場所が要求されます。zipファイルの場所の完全なパスを入力します。

プラグインの登録解除

プラグインを登録解除するには、次の手順を実行します。

1. antターゲットの登録解除を実行します。

ant -f  pluginregistration.xml unregister

2. これにより、Oracle Identity Managerのユーザー名およびパスワードとサーバー情報およびプラグイン・クラスのクラス名が要求されます。完全なパッケージを含むクラス名を入力します。

27.7 プラグインの移行

デプロイメント・マネージャでは、Oracle Identity Managerのあるデプロイメントから他のデプロイメントへのプラグインの移行をサポートしています。たとえば、イベント・ハンドラをテスト環境で実装した後、デプロイメント・マネージャを使用して本番環境に移行することができます。図27-2に、デプロイメント・マネージャを使用したプラグインのエクスポートを示します。

図27-2 プラグインのエクスポート

関連項目:

デプロイメント・マネージャの詳細は、「構成およびカスタマイズの移行」を参照してください。

28 イベント・ハンドラの開発

この章では、編成に関する概念と、Oracle Identity Managerの機能を拡張するためのカスタム・イベント・ハンドラの作成方法について説明します。内容は次のとおりです。

- 編成の概念

- カスタム・イベント・ハンドラの使用

- カスタム・イベント・ハンドラの開発

- イベント・ハンドラの実行の順序付け

- カスタム検証イベント・ハンドラの作成

- ベスト・プラクティス

- イベント・ハンドラの移行

- イベント・ハンドラのトラブルシューティング

- Design Consoleを使用したイベント・ハンドラの管理

28.1 編成の概念

Identity Managementシステムでは、ユーザーまたはシステムによって実行されるアクションは、操作と呼ばれます。操作には、ユーザーの作成、ロールの変更、パスワード・ポリシーの作成などがあります。事前に定義された一連のステージを進み、各ステージでなんらかのビジネス・ロジックを実行するOracle Identity Manager操作を編成と呼びます。編成によって変更されるオブジェクトのタイプを編成ターゲットと呼びます。編成操作の実行に必要なデータを編成パラメータと呼びます。

バルク編成は、複数のエンティティで同じ操作を編成するプロセスです。たとえば、複数ユーザーの組織を更新する場合にバルク編成を送信できます。その結果、すべてのエンティティに対する操作が1回のコールで実行されます。

注意:

ロック/ロック解除操作に対してカスタムのイベント・ハンドラの導入が必要な場合は、バルク編成を実装する必要があります。シングル・ユーザーのロック/ロック解除操作のバルク編成は、UIから起動されます。

編成は、ステージと呼ばれる事前に定義されたステップに分割されます。すべての操作は、終了処理に到達するまで、これらのステージを移動します。編成には次のステージがあります。

- 検証: 編成パラメータの整合性など、編成に対する検証を実行するステージ。編成パラメータは、編成操作を実行するために必要なデータです。

- 前処理: 編成パラメータ操作の実行、承認の取得または職務の分離チェックを実行するステージ。

- アクション: アクションを実行するステージ。

- 監視: 操作の監視が実行されるステージ。

- 後処理: 現行の操作に関連する結果としての操作が実行されるステージ。結果としての操作には、自動ロール・メンバーシップや、ユーザー作成に対するポリシー評価があります。

- 終了処理: クリーン・アップを実行する、プロセスの最後のステージ。

実行される各操作には、ユーザーやその他のエンティティに影響を及ぼすものもあります。たとえば、ユーザーを作成するとそのユーザーに対するリソースのプロビジョニングが発生し、新規パスワード・ポリシーを作成すると特定のユーザー・パスワードが無効になって次のログイン時に変更を要求される場合があります。結果としての各操作は編成として表されます。遅延された結果としての処理は、現行の編成の終了処理の前に実行されます。即時結果は、現行のイベント・ハンドラが戻された直後、現行の編成の次のイベント・ハンドラに進む前に実行されます。ユーザーの作成、変更、削除、有効化、無効化、ロック、ロック解除などのいくつかの操作の結果は、後続の項に示すとおり、イベント・ハンドラを作成することによってカスタマイズできます。

後処理ステージが開始点となる編成もあります。信頼できるソースからユーザーを調整する場合や、ユーザーをバルク・ロードしてこのデータをそのままOracle Identity Managerに追加する場合です。データがOracle Identity Managerにある場合は、ユーザーに対する後処理操作を実行し、自動グループ・メンバーシップの計算やポリシーの評価ができます。その結果、リコンシリエーション・エンジンやバルク・ロード・ユーティリティによって後処理専用の編成が送信されます。

イベント・ハンドラ は、様々なステージで編成に登録されるコードです。これらのイベント・ハンドラは、関連する編成ステージが実行されたときに起動されます。イベント・ハンドラは、同期がとられる場合と非同期の場合があります。同期イベント・ハンドラはすぐにレスポンスを返しますが、非同期イベント・ハンドラは後のステージで完了します。イベント・ハンドラは条件付きにすることができ、これは、特定の条件が満たされた場合に実行されることを意味します。

編成の各ステージにおける処理は、そのステージに配置されているブランチおよびイベント・ハンドラ(存在する場合)によって決定されます。ステージにブランチがある場合は、イベント・ハンドラからのレスポンスによって、使用するブランチが決まります。ステージにイベント・ハンドラがない場合、またはイベント・ハンドラからのレスポンスに推奨パスがない場合、操作はデフォルトのパスに従って次のステージに移ります。ただし、イベント・ハンドラが無効な場合や取り消された場合、プロセスは帯域外ステージに移ることができます。次のステージがあります。

- 無効: 編成の検証に失敗した場合、プロセスはこのステージに移ります。

- 拒否: 前処理イベント・ハンドラが拒否された場合、プロセスはこのステージに移ります。たとえば、承認者によって承認が却下された場合、編成は拒否されます。

- 取消し: 取消しメソッドをコールすることによって操作が停止された場合、プロセスはこのステージに移ります。

- 補正: 補正メソッドをコールすることによって操作がロールバックされた場合、プロセスはこのステージに移ります。

図28-1に、様々な編成ステージを示します。

図28-1 編成ステージ

28.2 カスタム・イベント・ハンドラの使用

Oracle Identity Managerを使用すると、編成操作の機能をカスタマイズするためにService Provider Interfaces (SPI)を実装できます。エンティティ編成の操作でサポートされるのは、前処理、後処理、検証および終了処理ステージのカスタマイズのみです。

イベント・ハンドラの実装の例を次に示します。

- ユーザーの作成時、アカウントのステータス(有効または無効)が同じルールに基づいて設定されます。これを実行するために前処理イベント・ハンドラを実装できます。

- 契約者というタイプのユーザーを作成するときは、このユーザーに電子メール・アドレスが必要です。その他のユーザーは、電子メール・アドレスがなくても作成できます。ユーザーが契約者かどうかを検証する場合に検証イベント・ハンドラを使用でき、検証結果に基づいてユーザー作成を許可または禁止します。

- エージェントというタイプのユーザーを作成した後に、このユーザーの代替電子メール・アドレスで通知を受け取るようにします。これは、後処理イベント・ハンドラを実装することによって実行できます。

後処理イベント・ハンドラは、ビジネス要件を満たすために最も一般的に実装されます。後処理イベント・ハンドラの実装によって特定の要件を満たすことができる例を次に示します。

要件

エンタープライズ・ユーザーが契約者の場合、Oracle Identity Managerでユーザーを作成した後、ユーザーは、外部アプリケーションである契約者登録システムに登録される必要があります。これはデータベース・アプリケーションです。データベースには、ユーザーのユーザーID、契約者ID、名、姓の各属性を格納する構造があります。正常に登録された後は、Oracle Identity Managerのユーザー・プロファイルでユーザーの契約者IDが取得され、更新される必要があります。

解決策

このユースケースはプラグインとして開発でき、Oracle Identity Managerにデプロイできます。プラグインは、契約者IDや指定したデータベース表からの構成済の列名の取得、およびOracle Identity Managerでのユーザー・プロファイルの更新に使用できます。後処理イベント・ハンドラは、ユーザー・エンティティの作成操作用に実装および登録できます。これは、条件付きのイベント・ハンドラで、タイプが契約者であるユーザーに対してのみ実行されます。ユーザー・タイプが契約者の場合、イベント・ハンドラは外部アプリケーションに接続し、Oracle Identity ManagerのユーザーIDに基づいて契約者IDを取得し、契約者IDを使用してOracle Identity Managerでユーザー・プロファイルを更新します。

次に、イベント・ハンドラの後処理実装の例をもう1つ示します。

Oracle Identity Managerでリコンサイルされるデータが、すべてのユースケースを実装するには不十分で、リコンサイルしたデータに基づいて追加の属性を生成する必要がある場合のカスタム属性の生成です。これは、特にカスタム属性がロール・メンバーシップ・ルールまたはアクセス・ポリシーで使用される場合に一般的なユースケースです。

28.3 カスタム・イベント・ハンドラの開発

イベント・ハンドラは、次のもので構成されます。

- Javaコード: 操作の実装

- XML定義: 適切なステージでの関連する編成との関連付け

- プラグイン定義: Oracle Identity Managerプラグイン・フレームワークへのイベント・ハンドラおよび拡張コードの登録

カスタム・イベント・ハンドラの開発では、Javaコードを使用した操作の実装、XML定義の記述、プラグインの作成と登録が行われます。これについて次の項で説明します。

- SPIの実装およびJARの作成

- カスタム・イベント定義XMLの定義

- プラグインZIPの作成および登録

28.3.1 SPIの実装およびJARの作成

この項では、SPIの実装によるJavaコードの作成と、JARファイルの作成方法について説明します。

- 開発に関する考慮事項

- メソッドおよび引数

- コード例

- カスタム・イベント・ハンドラ・コードを使用したJARファイルの作成

28.3.1.1 開発に関する考慮事項

カスタム・イベント・ハンドラを作成する際、次の事項を考慮する必要があります。

- カスタム・イベント・ハンドラを登録できる編成ステージは、検証、前処理および後処理です。

- 検証、前処理および後処理イベント・ハンドラは条件付きにできます。これは、特定の条件が満たされた場合にのみイベント・ハンドラが実行されるという意味です。
イベント・ハンドラを条件付きにするには、oracle.iam.platform.kernel.spi.ConditionalEventHandlerインタフェースとそのisApplicableメソッドを実装します。このメソッドでは、コンテキスト・データと編成パラメータが使用可能です。条件付きイベント・ハンドラの場合、操作の開始時にイベント・ハンドラの適用性が計算されます。したがって、編成フローの中でコンテキストまたは編成パラメータが変更されると、実行してはいけないイベント・ハンドラが実行される場合があります。

- イベント・ハンドラは、単一のエンティティもバルク・エンティティも処理できます。

- イベント・ハンドラは、親ハンドラでの特定の操作をコールバックする、関連付けられた失敗ハンドラを持つことができます。

- イベント・ハンドラの再試行がサポートされているため、イベント・ハンドラはリエントラントです。

- リコンシリエーションによって後処理編成が送信される場合、バルク編成が送信されます。イベント・ハンドラに対するbulkExecuteメソッドは、これらの編成に対してコールされます。したがって、必ずこのメソッドを実装してください。

- カスタム・イベント・ハンドラ間でデータが渡される場合は、イベント間データを使用して渡すことができます。編成に対してgetInterEventData()メソッドをコールすると、ハッシュマップが返されます。このマップでは、カスタムで始まるキーを持つオブジェクトを配置でき、後続のカスタム・ハンドラでこのデータにアクセスできます。同じハッシュマップに含まれる事前定義されたイベント間データは変更または削除しないでください。

- 書込みまたは削除操作のためにイベント・ハンドラ内部でAPIコールを行うには、Platform.getServiceForEventHandlersメソッドを使用してAPIサービスを取得します。このメソッドを使用して取得したサービスを使用して行われたAPIコールは、後処理を含め、同期をとって実行されます。

- 検証ハンドラを除くイベント・ハンドラの戻りタイプを次の表に示します。

イベント・ハンドラのタイプ

成功時

失敗時

同期

executeメソッドの新規EventResult()と、バルク・バージョンのexecuteメソッドの新規BulkEventResult()

EventFailedException

非同期

nullを返します

EventFailedException

- イベント・ハンドラでオブジェクト・レベル変数を定義しないでください。

28.3.1.2 メソッドおよび引数

表28-1に、様々な編成ステージで実装できるメソッドを示します。

表28-1 イベント・ハンドラを実装するためのメソッド

メソッド

適用可能な編成ステージ

説明

initialize

前処理、後処理

このメソッドは、接続を開き、状態またはリソースをプールするために使用します。

execute for single entity

前処理、後処理

このメソッドは、基礎となる操作の入力属性を読み取り、(必要に応じて)別の値に更新する場合に使用します。

execute for bulk orchestration

前処理、後処理

このメソッドは、基礎となる複数の操作の入力属性を読み取り、(必要に応じて)別の値に更新する場合に使用します。

isApplicable

条件付き

このメソッドは、条件付きハンドラで、イベント・ハンドラ実行の前提条件が満たされるかどうかを判別するために使用します。

validate

validation

このメソッドは、検証ハンドラで入力データを検証する場合に使用します。

cancel

前処理、後処理

このメソッドは、編成操作が取り消される場合にコールされます。

compensate

前処理、後処理

このメソッドは、編成操作が補正される場合にコールされます。

executeなどのメソッドでは、次の引数値が使用可能です。

- トラブルシューティングのためにコードに含めることができるID:

- プロセスID: 編成インスタンスのID

- イベントID: イベント・ハンドラ・インスタンスのID

- 基礎となるエンティティ・インスタンスの詳細情報で構成される編成オブジェクト。次のもので構成されます。

- 基礎となるエンティティの入力属性の読取り元となるENTITY_ATTRIBUTE、VALUEを含むマップ(キー値ペア)。

- エンティティID: 同じエンティティまたは異なるエンティティの値を元に戻すには、エンティティ・マネージャAPIを使用して、エンティティIDおよびデータを渡します。バルク編成の場合、複数のエンティティIDとマップを取得します。

注意:

Platform.getServiceForEventHandlersを使用して、イベント・ハンドラで作成、更新および削除操作をコールするサービスを取得します。

28.3.1.3 コード例

この項では、様々な種類のイベント・ハンドラを作成する方法を説明するコード例を示します。

例1: カスタム電子メール検証

例28-1に、ユーザーの電子メールIDにアンパサンド(@)が使用されていることを確認する、カスタム検証ハンドラのコード例の一部を示します。

例28-1 カスタム電子メール検証

public void validate(long processId, long eventId, Orchestration orchestration) throws ValidationException, ValidationFailedException {
HashMap<String, Serializable> parameters = orchestration.getParameters();
String email = (parameters.get("Email") instanceof ContextAware) ? (String) ((ContextAware) parameters
.get("Email")).getObjectValue() : (String) parameters
.get("Email");
if (!(email.contains("@"))) {
throw new ValidationFailedException("Email doesn't contain @");
}
}

例2: ミドル・ネームを設定するカスタム前処理イベント・ハンドラ

例28-2に、ミドル・ネームに値が指定されていない場合に、ミドル・ネームを名の最初の文字に設定するカスタム前処理イベント・ハンドラのコード例の一部を示します。

例28-2 ミドル・ネームを設定するカスタム前処理イベント・ハンドラ

// the middle initial when the user doesn't have a middle name
public EventResult execute(long processId, long eventId,
Orchestration orchestration) {
HashMap<String, Serializable> parameters = orchestration
.getParameters();
// If the middle name is empty set the first letter of the first name
// as the middle initial
String middleName = getParamaterValue(parameters, "Middle Name");
if ((middleName == null) || middleName.equals("")) {
String firstName = getParamaterValue(parameters, "First Name");
middleName = firstName.substring(0, 1);
orchestration.addParameter("Middle Name", middleName);
}
return new EventResult();
}

private String getParamaterValue(HashMap<String, Serializable> parameters,
String key) {
if(parameters.containsKey(key)){
String value = (parameters.get(key) instanceof ContextAware) ? (String) ((ContextAware) parameters
.get(key)).getObjectValue() : (String) parameters.get(key);
return value;
}
else{
return null;
}
}

例3: リソース・オブジェクトをプロビジョニングするカスタム後処理イベント・ハンドラ

例28-3に、ロールがROLE 005であるユーザーにリソース・オブジェクトOBJ005をプロビジョニングするカスタム後処理イベント・ハンドラのコード例の一部を示します。

例28-3 カスタム後処理イベント・ハンドラの例

// This custom post process event handler provisions resource object 'OBJ005'
// to a user who has role 'ROLE 005'
public EventResult execute(long processId, long eventId,
Orchestration orchestration) {
tcUserOperationsIntf userOperationsService =
Platform.getService(tcUserOperationsIntf.class);
try {
String userKey = getUserKey(processId, orchestration);
if (hasRole(userKey, "ROLE 005")) {
long objKey = findObject("OBJ001");
userOperationsService.provisionResource(Long.getLong(userKey), objKey);
}
} catch (Exception e) {
throw new EventFailedException("Error occurred ", e);
}

return new EventResult();
}

// This method retrieves the key of the user entity on which an operation
// is performed
// This method shows how to retrieve the operation being performed, entity type
// and the associated value objects
private String getUserKey (long processID, Orchestration orchestration) {
String userKey;
String entityType = orchestration.getTarget().getType();
EventResult result = new EventResult();

if (!orchestration.getOperation().equals("CREATE")) {
userKey = orchestration.getTarget().getEntityId();
} else {
OrchestrationEngine orchEngine = Platform.getService(OrchestrationEngine.class);
userKey = (String) orchEngine.getActionResult(processID);
}
return userKey;
}

// This method checks if a given user has a given role.
// It demonstrates how to invoke a OIM 11g API from a custom event handler
private boolean hasRole(String userKey, String roleName)
throws Exception {
RoleManager roleManager = Platform.getService(RoleManager.class);
List<Identity> roles = roleManager.getUserMemberships(userKey);

for (Iterator iterator = roles.iterator(); iterator.hasNext();) {
Role role = (Role) iterator.next();
if (roleName.equals((String)role.getAttribute("Role Name"))) {
return true;
}

}
return false;
}

// This method finds details about a resource object with the given name.
// It demonstrates how to invoke a 9.1.x API from a custom event handler
private long findObject(String objName) throws Exception {
long objKey = 0;
tcObjectOperationsIntf objectOperationsService =
Platform.getService(tcObjectOperationsIntf.class);
HashMap params = new HashMap();
params.put("Objects.Name", objName);
tcResultSet objects = objectOperationsService.findObjects(params);
for (int i = 0; i < objects.getRowCount(); i++) {
objects.goToRow(i);
if (objects.getStringValue("Objects.Name").equals(objName)) {
objKey = objects.getLongValue("Objects.Key");
}
}
return objKey;
}

例4: bulkExecuteメソッドを使用するカスタム・ユーザー後処理イベント・ハンドラ

例28-4に、バルク・ユーザー作成編成に含まれるユーザーをループする方法を示します。

例28-4: bulkExecuteメソッドを使用するカスタム・ユーザー後処理イベント・ハンドラ

public BulkEventResult execute(long processId, long eventId, BulkOrchestration orchestration){

HashMap<String, Serializable>[] orchParamArray = orchestration.getBulkParameters();

// Array of user keys
String [] entityIds = orchestration.getTarget().getAllEntityId();
for(int i=0; i< entityIds.length; i++){
}

}

例5: isApplicableメソッドでのコンテキストの使用

Oracle Identity Managerでの操作は、複数のコンテキストで実行できます。たとえば、ユーザーの作成は、管理者がユーザーをダイレクト操作として作成する場合、管理者がリクエストを送信することによってユーザーを作成する場合、自己登録によってユーザーを作成する場合、および信頼できるソース・リコンシリエーションによってユーザーを作成する場合という4つのコンテキストで発生する可能性があります。これらのすべてのシナリオで、Oracle Identity Managerは、同じデータ型で、同じパラメータ名と値を持つ、同じユーザー作成編成を送信します。

例28-5には、イベント・ハンドラの適応性を示すためにこの操作を実行するコンテキストの検出方法を示します。

例28-5 isApplicableメソッドでのコンテキストの使用

public boolean isApplicable(AbstractGenericOrchestration orchestration) {    // Request Context
if (ContextManager.getContextType() == ContextTypes.REQUEST) {
}
// Recon context
if (ContextManager.getContextType() == ContextTypes.RECON) {
}

}

関連項目:

コンテキストから取得できる情報の詳細は、「コンテキストの理解」を参照してください。

28.3.1.4 カスタム・イベント・ハンドラ・コードを使用したJARファイルの作成

カスタム・イベント・ハンドラ・コードを使用してJARを作成するには:

1. 表28-2に示すSPIのいずれかを実装して、カスタム前処理、後処理または検証ハンドラを作成します。

表28-2 カスタム・イベント・ハンドラを作成するためのSPI

ステージ

実装するSPI

前処理

oracle.iam.platform.kernel.spi.PreProcessHandler

後処理

oracle.iam.platform.kernel.spi.PostProcessHandler

検証

oracle.iam.platform.kernel.spi.ValidationHandler

終了処理

oracle.iam.platform.kernel.spi.FinalizationHandler

関連項目:

表28-2に示すSPIの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。

2. カスタム・クラスをコンパイルするクラス・パスに次のJARファイルを含めます。
OIM_ORACLE_HOME/server/platform/ディレクトリから:

- iam-platform-kernel.jar

- iam-platform-utils.jar

- iam-platform-context.jar

- iam-plaftorm-authz-service.jar

OIM_ORACLE_HOME/designconsole/lib/ディレクトリから:

- oimclient.jar

- xlAPI.jar

コンパイルに他のOracle Identity Manager JARファイルが必要な場合は、この手順に示すディレクトリにあります。

3. カスタム・クラスのJARファイルを作成します。

28.3.1.5 例外の処理

イベント・ハンドラの例外処理では、条件付きのJAVA例外処理メソッドを使用する必要があります。失敗時の処理には次のガイドラインを参照してください。

- イベント・ハンドラ・コードで、失敗を示す適切な引数を指定してEventFailedExceptionをスローします。

- 失敗は、失敗ハンドラを登録することによって処理できます。失敗ハンドラの一部として、失敗を修正するために必要なロジックを実装できます。失敗ハンドラは、レスポンスとして次のオプションを持つFailedEventResultを返す必要があります。

- CANCEL: 操作を取り消す必要があることを示します。これまでに実行され完了したすべてのイベント・ハンドラに対するCancelメソッドは、カーネルによって実行とは逆の順にコールされます。

- COMPENSATE: 操作をロールバックする必要があることを示します。これまでに実行され完了したすべてのイベント・ハンドラに対するCompensateメソッドは、カーネルによって実行とは逆の順にコールされます。

- MANUAL_COMPLETE: 失敗したハンドラは手動で完了され、残りのイベント・ハンドラが処理されることを示します。

- RETRY: 失敗したイベント・ハンドラを再試行する必要があることをカーネルに示します。

- NULL: 失敗したハンドラによるレスポンスや推奨がないことを示します。

28.3.1.6 トランザクションの管理

イベント・ハンドラのXMLファイルで、tx属性をtrueに設定します。イベント・ハンドラで例外がスローされると、トランザクションはロールバックまたはコミットされます。

28.3.2 カスタム・イベント定義XMLの定義

次の項で、カスタム・イベント定義XMLについて説明します。

- イベント・ハンドラXMLファイルの要素

- イベント定義の例

28.3.2.1 イベント・ハンドラXMLファイルの要素

この項では、イベント・ハンドラXMLファイル内の、一部の要素および要素の属性について説明します。また、イベント・ハンドラXML定義の必須の名前空間についても説明します。

要素

イベント・ハンドラXMLファイルのトップレベル(親)要素は、eventhandlersです。表28-3に、eventhandlers親要素内に一般的に定義されるサブ要素を示します。

表28-3 eventhandlers要素内の一般的なサブ要素

サブ要素

説明

validation-handler

編成に対して実行される検証を識別します。

action-handler

前処理、後処理およびアクション・ステージで実行される操作を識別します。

failed-handler

デフォルトのフローでイベント・ハンドラが失敗した場合に実行されるイベント・ハンドラを識別します。

finalization-handler

編成の最後に実行されるイベント・ハンドラを識別します。終了処理は、編成の最後のステージです。

change-failed

影響の編成が失敗した場合に親編成で実行されるイベント・ハンドラを識別します。

out-of-band-handler

拒否や取消しなどの帯域外編成フローのイベント・ハンドラを定義します。

compensate-handler

編成の補正フローで実行されるイベント・ハンドラを識別します。

要素の属性

イベント・ハンドラXMLファイル内の要素には、属性が含まれています。表28-4に、要素内に一般的に定義される属性を示します。

表28-4 eventhandlers要素内のサブ要素の一般的な属性

要素の属性

説明

名前

イベント・ハンドラの名前。

class

イベント・ハンドラを実装するJavaクラスのフル・パッケージ名。

entity-type

イベント・ハンドラの実行対象のエンティティのタイプを識別します。値ANYを設定すると、イベント・ハンドラはすべてのエンティティに対して実行されます。最も一般的に定義されるエンティティ・タイプは、user、role、rolerole (ロール階層)およびroleuser (ユーザー・ロール・メンバーシップ)です。

operation

イベント・ハンドラの実行対象の操作のタイプを識別します。値ANYを設定すると、イベント・ハンドラはすべての操作に対して実行されます。通常の操作は、作成、変更および削除です。

order

イベント・ハンドラが実行される順序を識別します。順序の値は、エンティティ、操作およびステージの範囲内にあります。この範囲にある各イベント・ハンドラの順序の値は一意である必要があります。競合があると、この競合のあるイベント・ハンドラは無作為な順に実行されます。

サポートされる値は、FIRST (Integer.MIN_VALUEと同じ)、LAST (Integer.MAX_VALUEと同じ)または数値です。

orch-target

編成のタイプ(エンティティ編成、Toplink編成など)を識別します。次の値がサポートされています。

- oracle.iam.platform.kernel.vo.EntityOrchestration

- oracle.iam.platform.kernel.vo.MDSOrchestration

- oracle.iam.platform.kernel.vo.RelationOrchestration

- oracle.iam.platform.kernel.vo.ToplinkOrchestration

デフォルト値はoracle.iam.platform.kernel.vo.EntityOrchestrationです。カスタム・イベント・ハンドラの作成用にサポートされている唯一のタイプです。

sync

この属性は、action-handlerおよびchange-failed要素のみで機能します。sync属性は、イベント・ハンドラが同期か非同期かを示します。サポートされている値は、TRUEまたはFALSEです。TRUE(同期)に設定した場合、カーネルではイベント・ハンドラによってEventResultが返されることを予期します。FALSE(非同期)に設定した場合、イベント結果としてNULLを返し、イベント結果について後でカーネルに通知する必要があります。

注意: validation-handler要素の場合、sync属性はTRUEに設定する必要があります。

stage

この属性は、out-of-band-handler、action-handlerおよびfailed-handler要素のみで機能します。stage属性は、イベント・ハンドラが実行されるステージを示します。次の値がサポートされています。

- 前処理

- アクション

- 監査

- 後処理

- 拒否

- 取消し

tx

この属性は、out-of-band-handler、action-handler、compensate-handlerおよびfinalization-handler要素のみで機能します。tx属性は、イベント・ハンドラが独自のトランザクションで実行されるかどうかを示します。サポートされている値は、TRUEまたはFALSEです。デフォルト値はFALSEです。

<eventhandlers>要素の名前空間要件

すべてのイベント・ハンドラ定義には、次の必須名前空間定義が必要です。

<eventhandlers xmlns="http://www.oracle.com/schema/oim/platform/kernel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/schema/oim/platform/kernel
orchestration-handlers.xsd">

28.3.2.2 イベント定義の例

表28-4に示す、すべてのカスタム・イベントの定義を含むメタデータXMLファイルを作成します。

例28-6 カスタム・イベント定義のサンプル・メタデータXMLファイル

<?xml version='1.0' encoding='utf-8'?>
<eventhandlers xmlns="http://www.oracle.com/schema/oim/platform/kernel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/schema/oim/platform/kernel
orchestration-handlers.xsd">

<!-- Custom preprocess event handlers -->
<action-handler
class="oracle.oim.extensions.preprocess.SamplePreprocessExtension"
entity-type="User"
operation="CREATE"
name="SetUserMiddleName"
stage="preprocess"
order="1000"
sync="TRUE"/>

<!-- Custom postprocess event handlers -->
<action-handler
class="oracle.oim.extensions.postprocess.SamplePostprocessExtension"
entity-type="User"
operation="CREATE"
name="SamplePostprocessExtension"
stage="postprocess"
order="1000"
sync="TRUE"/>

<action-handler
class="oracle.oim.extensions.postprocess.SamplePostprocessExtension"
entity-type="User"
operation="MODIFY"
name="CustomResourceProv"
stage="postprocess"
order="1000"
sync="TRUE"/>

<!-- Custom validation event handlers -->
<validation-handler
class="oracle.oim.extensions.validation.SampleValidationExtension"
entity-type="User"
operation="CREATE"
name="ValidateUserEmail"
order="1000"/>
</eventhandlers>

28.3.3 プラグインZIPの作成および登録

カスタム・イベント・ハンドラを含むプラグインを作成するには、適切なイベント・ハンドラ・クラスを開発する必要があります。プラグインおよびプラグイン・ポイントの詳細は、「プラグインの開発」を参照してください。

プラグインZIPを作成して登録するには:

1. イベント・ハンドラ・プラグイン・ポイントを含むプラグインXMLを定義します。

注意:

プラグイン定義で使用されるプラグイン・ポイントがoracle.iam.platform.kernel.spi.EventHandlerに設定されていることを確認してください。

プラグインXMLファイルの例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<oimplugins>
<plugins pluginpoint="oracle.iam.platform.kernel.spi.EventHandler">
<plugin pluginclass=
"oracle.oim.extensions.preprocess.SamplePreprocessExtension"
version="1.0"
name="SamplePreprocessExtension">
</plugin>
<plugin pluginclass=
"oracle.oim.extensions.postprocess.SamplePostprocessExtension"
version="1.0"
name="SamplePostprocessExtension">
</plugin>
<plugin pluginclass=
"oracle.oim.extensions.validation.SampleValidationExtension"
version="1.0"
name="SampleValidationExtension">
</plugin>
</plugins>
</oimplugins>

2. カスタム・クラスを含むプラグインXMLおよびJARファイルをプラグインZIPファイルにパッケージ化します。

3. 「カスタム・イベント定義XMLの定義」に示す情報を使用して定義されたイベント・ハンドラXMLを同じzipのMETA-INFというディレクトリにパッケージ化します。

4. プラグイン登録ユーティリティを使用してプラグインを登録します。追加情報については、「プラグインの登録」を参照してください。

28.4 イベント・ハンドラの実行の順序付け

デプロイおよび登録したカスタム・イベント・ハンドラのリストは、Oracle Enterprise Managerを使用して表示できます。イベント・ハンドラは、起動順に表示されます。このイベント・ハンドラのリストを使用すると、イベント・ハンドラの実行順序を指定できます。

カスタム・イベント・ハンドラの順序を指定するには、既存のイベント・ハンドラのリストと特定の操作におけるその順序を把握している必要があります。そのためには、次の手順を実行して、Enterprise ManagerからMBeanを起動する必要があります。

1. Enterprise Managerにログインします。

2. 左側にあるナビゲーション・ペインで、「WebLogicドメイン」を展開して「OIM DOMAIN」を選択します。

3. ドメイン名を右クリックして、「システムMBeanブラウザ」を選択します。

4. 「アプリケーション定義のMBean」でoracle.iamを展開します。

5. 「OIM_SERVER_NAME」、「oim」、「IAMAppDesignMBean」、「ConfigQueryMBeanName」の順にナビゲートします。

6. 「操作」タブをクリックします。

7. getEventHandlersメソッドをクリックします。

8. p1パラメータのエンティティ名およびp2パラメータの操作名を指定して、「起動」をクリックします。パラメータ値は大/小文字を区別しません。指定可能なパラメータ値は次のとおりです。

- エンティティ名: 値は、User、RoleまたはRoleUserのいずれかです。

- 操作: 値は、CREATE、MODIFYまたはDELETEのいずれかです。

28.5 カスタム検証イベント・ハンドラの作成

承認者は、リクエストを承認する前に属性値を更新できます。承認者が入力したデータの清浄化を保証するために、承認者がリクエストを更新したときに、Oracle Identity Managerは再度検証ハンドラを起動します。これは、リクエストが送信され、承認者が承認ワークフローでそのリクエストを変更した場合に、特定のエンティティおよび操作用に構成された検証ハンドラが1つのリクエスト・フローの中で複数回起動されることを意味します。

たとえば、自己登録リクエストが送信されると、USER CREATE用に構成された一連の検証ハンドラが実行されます。次に、承認者が組織またはその他のユーザー属性を移入するようにリクエストを変更すると、これらの検証ハンドラが再実行されます。

したがって、カスタム検証ハンドラは1つのリクエスト・フローで複数回起動されることから、このカスタム検証ハンドラはリエントラントな検証ロジックで開発される必要があります。

次のサンプル・ユースケースについて考えてみます。

部門番号フィールドの値にランダムな番号を付与して、HR Employee Number UDFを生成する必要があります。ユーザー作成リクエストまたは自己登録リクエストが送信されると、カスタム・ロジックに基づいてHR Employee Number UDFが自動的に生成されます。承認者が承認時にリクエストを編集し、部門番号の値を変更すると、部門番号に割り当てられた新しい値を使用して、HR Employee Number UDFが再計算される必要があります。ただし、承認者が部門番号を変更しなかった場合は、リクエストの送信時に生成された以前の値が使用されます。

このため、部門番号とランダムな番号を付与することによってHR Employee Number UDFを生成するための新しい検証ハンドラを開発する必要があります。前処理ハンドラがリクエストのライフサイクルで起動されるのは1回だけであるため、このロジックを前処理ハンドラで作成することはできません。この検証ハンドラのロジックを次に示します。

package custom.handlers;

import java.io.Serializable;
import java.util.HashMap;
import java.util.Random;

import oracle.iam.identity.usermgmt.api.UserManagerConstants;
import oracle.iam.identity.utils.Utils;
import oracle.iam.platform.kernel.ValidationException;
import oracle.iam.platform.kernel.ValidationFailedException;
import oracle.iam.platform.kernel.spi.ValidationHandler;
import oracle.iam.platform.kernel.vo.BulkOrchestration;
import oracle.iam.platform.kernel.vo.Orchestration;

public class EmployeeNumberGenerationHandler implements ValidationHandler {

@Override
public void initialize(HashMap<String, String> parameters) {

}

@Override
public void validate(long processId, long eventId, Orchestration orchestration) throws ValidationException, ValidationFailedException {

HashMap<String, Serializable> contextParams = orchestration.getParameters();
//1. Generate UDF Employee number during request submission as Department Number and a random number
//2. If request is in approval stage, then control has come here since approver has modified the request
//2a: Check if approver has modified Department Number. If yes, then re-generate
if( !Utils.isRequestInApprovalStage()) //Utility method to find if request is in approval stage or not? If it returns true, it means that approver is attempting to update the request during approval
{

//Step 1:
String dept = contextParams.get(UserManagerConstants.AttributeName.DEPARTMENT_NUMBER.getId()).toString();
String en = dept+"_"+random();
contextParams.put("SSN", en);

}
else
{
String dept = contextParams.get(UserManagerConstants.AttributeName.DEPARTMENT_NUMBER.getId()).toString();
//compare with department number with which request was submitted, if modified by approver; the regenerate SSN
if( Utils.isAttributeModifiedByApprover(orchestration , UserManagerConstants.AttributeName.DEPARTMENT_NUMBER.getId()) )

// //Utility method to find if approver has edited the particular attribute or not , during approval?
{
String en = dept+"_"+random();
contextParams.put("SSN", en);
}

}

}

private String random() {
Random random = new Random();
String randomStr = "" + random.nextLong();
randomStr = randomStr.replaceAll("-", "");
return randomStr;
}

@Override
public void validate(long processId, long eventId,
BulkOrchestration orchestration) throws ValidationException,
ValidationFailedException {

}

}

28.6 ベスト・プラクティス

イベント・ハンドラを開発して実装する前に、操作を分析することをお薦めします。操作用のプラグインがサポートされている場合は、イベント・ハンドラを開発するのではなく、プラグインを使用してカスタマイズします。たとえば、ユーザー名の生成は、使用可能なプラグインを使用して実装する必要があり、ユーザーの作成編成でイベント・ハンドラとして作成しようとしないでください。

イベント・ハンドラの開発における考慮事項については、「開発に関する考慮事項」を参照してください。

28.7 イベント・ハンドラの移行

デプロイメント・マネージャでは、Oracle Identity Managerのデプロイメント間でのプラグインおよびプラグインに登録されたイベント・ハンドラの移行をサポートしています。たとえば、イベント・ハンドラをテスト環境で実装した後、デプロイメント・マネージャを使用して本番環境に移行することができます。図28-2に、デプロイメント・マネージャを使用したプラグインのエクスポートを示します。

図28-2 プラグインのエクスポート

関連項目:

デプロイメント・マネージャの詳細は、「構成およびカスタマイズの移行」を参照してください。

28.8 イベント・ハンドラのトラブルシューティング

表28-5に、一般的な問題、および操作の実行時にイベント・ハンドラがトリガーされなかった場合のトラブルシューティングに役立つ原因と解決策を示します。

表28-5 イベント・ハンドラのトラブルシューティング

問題

原因/解決策

リコンシリエーションによってユーザーを作成すると、カスタム前処理イベント・ハンドラはトリガーされません。

開始ステージが後処理の場合、リコンシリエーションは後処理のみの編成を送信します。

リコンシリエーションによってユーザーを作成すると、カスタム後処理イベント・ハンドラはトリガーされますが、実行メソッドのロジックはトリガーされません。

リコンシリエーションはバルク編成を送信します。したがって、必ずbulkExecuteメソッドを実装してください。

編成操作の完了に非常に長い時間がかかります。

イベント・ハンドラごとにかかる時間を確認します。

1. WebLogic管理者としてhttp://OIM_HOST:OIM_PORT/dms/Spyに接続します。

2. メトリック表で、「OIM_EventHandler」をクリックします。各イベント・ハンドラにどれだけ時間がかかっているかがprocessTime列に表示されます。

28.9 Design Consoleを使用したイベント・ハンドラの管理

注意:

この項は、Oracle Identity Manager Release 9.xのイベント・ハンドラにのみ該当します。編成に基づくイベント・ハンドラについては、前の項を参照してください。

Design Consoleの「開発ツール/ビジネス・ルール定義」フォルダでは、システム管理者および開発者がOracle Identity Managerのイベント・ハンドラおよびデータ・オブジェクトを管理するツールが提供されます。

このフォルダには、次のフォームが含まれます。

- イベント・ハンドラ・マネージャ: このフォームでは、Oracle Identity Managerで使用されるイベント・ハンドラを作成および管理できます。詳細は、「「イベント・ハンドラ・マネージャ」フォーム」を参照してください。

- データ・オブジェクト・マネージャ: このフォームでは、データ・オブジェクトを定義し、そのオブジェクトにイベント・ハンドラとアダプタを割り当て、関連するアダプタ変数をマップできます。詳細は、「「データ・オブジェクト・マネージャ」フォーム」を参照してください。

28.9.1 「イベント・ハンドラ・マネージャ」フォーム

このフォームは、「開発ツール/ビジネス・ルール定義」フォルダに表示されます。このフォームを使用して、ユーザー定義またはシステム生成のアクション(またはイベント)を処理するJavaクラスを管理します。これらのクラスはイベント・ハンドラと呼ばれます。新規イベント・ハンドラをOracle Identity Managerに追加する場合は、Oracle Identity Managerで認識されるようにするために、最初にそのイベント・ハンドラをここで登録する必要があります。

イベント・ハンドラには次の2種類があります。

- 「アダプタ・ファクトリ」フォームを使用して作成されるイベント・ハンドラ。名前の先頭の文字はadpです。これらはアダプタと呼ばれます。

- Oracle Identity Managerで内部的に作成されるイベント・ハンドラ。名前の先頭の文字はtcです。これらは、システム・イベント・ハンドラと呼ばれます。

「イベント・ハンドラ・マネージャ」フォームを使用して、Oracle Identity Managerによりいつイベント・ハンドラがトリガーされるかを指定できます。イベント・ハンドラの実行は、次のようにスケジュールできます。

- 挿入前: 情報がデータベースに追加される前

- 更新前: 情報がデータベース内で更新される前

- 削除前: 情報がデータベースから削除される前

- 挿入後: 情報がデータベースに追加された後

- 更新後: 情報がデータベース内で更新された後

- 削除後: 情報がデータベースから削除された後

図28-3に、「イベント・ハンドラ・マネージャ」フォームを示します。

図28-3 「イベント・ハンドラ・マネージャ」フォーム

表28-6に、「イベント・ハンドラ・マネージャ」フォームのフィールドの説明を示します。

表28-6 「イベント・ハンドラ・マネージャ」フォームのフィールド

フィールド名

説明

イベント・ハンドラ名

イベント・ハンドラの名前。

パッケージ

イベント・ハンドラが属するJavaパッケージ。

挿入前

このチェック・ボックスを選択すると、データベースに情報が追加される前に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

更新前

このチェック・ボックスを選択すると、データベースで情報が変更される前に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

削除前

このチェック・ボックスを選択すると、データベースから情報が削除される前に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

挿入後

このチェック・ボックスを選択すると、データベースに情報が追加された後に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

更新後

このチェック・ボックスを選択すると、データベースで情報が変更された後に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

削除後

このチェック・ボックスを選択すると、データベースから情報が削除された後に、Oracle Identity Managerによってイベント・ハンドラがトリガーされます。

注意

イベント・ハンドラに関する追加情報。

次の各項では、イベント・ハンドラの作成および変更の方法について説明します。

注意:

イベント・ハンドラを使用するには、「データ・オブジェクト・マネージャ」フォームを使用して、イベント・ハンドラをデータ・オブジェクトにアタッチする必要があります。イベント・ハンドラのデータ・オブジェクトへの割当ての詳細は、「「データ・オブジェクト・マネージャ」フォーム」を参照してください。

注意:

名前の先頭の文字がadpであるイベント・ハンドラは、すべてアダプタに関連付けられているため、変更できません。ただし、システム・イベント・ハンドラは変更可能です。これらのイベント・ハンドラは名前の先頭の文字がtcです。

イベント・ハンドラの追加または変更

イベント・ハンドラを追加または変更するには、次の手順を実行します。

1. 「イベント・ハンドラ・マネージャ」フォームを開きます。

2. Oracle Identity Managerにイベント・ハンドラを追加するには、「イベント・ハンドラ名」参照フィールドにイベント・ハンドラの名前を入力します。
イベント・ハンドラを変更するには、「イベント・ハンドラ名」参照フィールドをダブルクリックします。

表示される「参照」ダイアログ・ボックスで、編集するイベント・ハンドラを選択します。

3. パッケージ・フィールドで、イベント・ハンドラがそのメンバーであるJavaパッケージの名前を追加または編集します。

4. どの時点でOracle Identity Managerによりイベント・ハンドラをトリガーするかに応じて、該当するチェック・ボックスを選択します。
イベント・ハンドラは、挿入前、更新前、削除前、挿入後、更新後および削除後に実行されるようにスケジュールできます。

注意:

チェック・ボックスを選択しても、イベント・ハンドラがその時点で(たとえば挿入前に)トリガーされるわけではありません。これは、その時点でのイベント・ハンドラの実行が可能であることを意味しています。

5. 「注意」領域で、イベント・ハンドラに関する説明を追加または編集します。

6. 「保存」をクリックします。
イベント・ハンドラが追加または編集されます。

28.9.2 「データ・オブジェクト・マネージャ」フォーム

「データ・オブジェクト・マネージャ」フォームは、「開発ツール/ビジネス・ルール定義」フォルダに表示されます。このフォームを使用して、次の操作を実行できます。

- データベースのデータを追加、変更または削除できるオブジェクトに、ルール・ジェネレータ・アダプタ、エンティティ・アダプタまたはイベント・ハンドラを割り当てます。このタイプのオブジェクトは、データ・オブジェクトと呼ばれます。

- スケジュール(挿入前、更新前、削除前、挿入後、更新後または削除後)に従って実行されるように、アダプタまたはイベント・ハンドラのスケジュールを設定します。

- 同じ実行スケジュールに属するアダプタまたはイベント・ハンドラが、Oracle Identity Managerによってトリガーされる順序を調整します。

- 現在のデータ・オブジェクトを追加、変更および削除できるユーザー・グループを表示します。

- アダプタ変数を適切なソースの場所およびターゲットの場所にマップします。

関連項目:

アダプタ変数、ルール・ジェネレータ・アダプタおよびエンティティ・アダプタの詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

図28-4に、「データ・オブジェクト・マネージャ」フォームを示します。

図28-4 「データ・オブジェクト・マネージャ」フォーム

表28-7に、「データ・オブジェクト・マネージャ」フォームのフィールドの説明を示します。

表28-7 「データ・オブジェクト・マネージャ」フォームのフィールド

フィールド

説明

フォームの説明

データ・オブジェクトに関連付けられているフォームの名前。

データ・オブジェクト

イベント・ハンドラ、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタを割り当てるデータ・オブジェクトの名前。

次の項では、ルール・ジェネレータ・アダプタ、エンティティ・アダプタまたはイベント・ハンドラを割り当てるターゲット・データ・オブジェクトの選択方法について説明します。

ターゲット・データ・オブジェクトの選択

ターゲット・データ・オブジェクトを選択するには、次の手順を実行します。

1. 「データ・オブジェクト・マネージャ」フォームを開きます。

2. フォームの説明フィールドをダブルクリックします。
表示される「参照」ダイアログ・ボックスで、イベント・ハンドラ、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタを割り当てるデータ・オブジェクトに関連付けられているフォームの名前を選択します。

フォームを選択すると、対応するデータ・オブジェクトの名前がデータ・オブジェクト・フィールドに表示されます。

3. 「保存」をクリックします。
ターゲット・データ・オブジェクトが選択されます。これで、ルール・ジェネレータ・アダプタ、エンティティ・アダプタおよびイベント・ハンドラを割り当てられるようになりました。

28.9.2.1 「データ・オブジェクト・マネージャ」フォームのタブ

「データ・オブジェクト・マネージャ」フォームを起動してターゲット・データ・オブジェクトを選択すると、このフォームのタブが使用できるようになります。

「データ・オブジェクト・マネージャ」フォームには、次のタブが含まれます。

- ハンドラのアタッチ、アダプタのマップ

それぞれのタブについて、次の各項で説明します。

- ハンドラのアタッチ・タブ

- アダプタのマップ・タブ

28.9.2.1.1 ハンドラのアタッチ・タブ

このタブを使用して、データ・オブジェクトに割り当てるか、データ・オブジェクトから削除するルール・ジェネレータ・アダプタ、エンティティ・アダプタまたはイベント・ハンドラを選択します。次の情報が含まれます。

- 割り当てられたイベント・ハンドラまたはアダプタが、Oracle Identity Managerによって(挿入前、更新前、削除前、挿入後、更新後または削除後の)いつトリガーされるかを指定します。同じ実行スケジュールに属するアダプタまたはイベント・ハンドラがOracle Identity Managerによってトリガーされる順序を設定します。

イベント・ハンドラ、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタをOracle Identity Managerによってトリガーする必要がなくなった場合は、データ・オブジェクトからそれを削除する必要があります。

たとえば、adpCONVERTTOLOWERCASE、adpSOLARISHMDSTRINGGEN、adpSETSOLARISASSETおよびadpSETPASSWORDFROMMAINの各アダプタが、挿入前にOracle Identity Managerによってトリガーされるとします。これらのアダプタの順序番号に基づき、Oracle Identity Managerは、まずadpCONVERTTOLOWERCASEアダプタをトリガーし、それからadpSOLARISHMDSTRINGGEN、adpSETSOLARISASSETおよびadpSETPASSWORDFROMMAINアダプタの順にトリガーします。

注意:

現在のデータ・オブジェクトを追加、変更および削除できるユーザー・グループを表示するには、権限の挿入、「権限の更新」または権限の削除の各タブをそれぞれクリックします。

次の各項では、これらの手順について説明します。

- データ・オブジェクトへのイベント・ハンドラ、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタの割当て。イベント・ハンドラまたはアダプタの実行スケジュールの構成。データ・オブジェクトからのイベント・ハンドラ、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタの削除。

28.9.2.1.2 データ・オブジェクトへのイベント・ハンドラまたはアダプタの割当て

イベント・ハンドラまたはアダプタを割り当てるには、次の手順を実行します。

1. アダプタまたはイベント・ハンドラをいつトリガーするかに応じて、該当する「データ・オブジェクト・マネージャ」フォームのタブを選択します。
たとえば、挿入前にOracle Identity Managerでアダプタをアクティブ化する場合は、挿入前タブを選択します。

2. 選択したタブで、「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

3. イベント・ハンドラまたはアダプタを選択し、データ・オブジェクトに割り当てます。

4. 「OK」をクリックします。
イベント・ハンドラまたはアダプタがデータ・オブジェクトに割り当てられます。

28.9.2.1.3 イベント・ハンドラまたはアダプタの実行スケジュールの構成

実行スケジュールを構成するには、次の手順を実行します。

1. 実行スケジュールを変更するイベント・ハンドラまたはアダプタを選択します。

2. 「割当て」をクリックします。
「割当て」ダイアログ・ボックスが表示されます。

3. イベント・ハンドラまたはアダプタを選択します。

4. 上をクリックすると、選択したイベント・ハンドラまたはアダプタの位置と順序番号が、その前のイベント・ハンドラまたはアダプタと入れ替わります。
下をクリックすると、選択したイベント・ハンドラまたはアダプタの位置と順序番号が、その次のイベント・ハンドラまたはアダプタと入れ替わります。

5. すべてのイベント・ハンドラとアダプタの順序番号が適切に設定されるまで、手順3と4を繰り返します。

6. 「OK」をクリックします。
イベント・ハンドラおよびアダプタは、実行スケジュールまたは独自に構成したスケジュールで正しい順序でトリガーされます。

28.9.2.1.4 データ・オブジェクトからのイベント・ハンドラまたはアダプタの削除

イベント・ハンドラまたはアダプタを削除するには、次の手順を実行します。

1. イベント・ハンドラまたはアダプタを選択します。

2. 「削除」をクリックします。
イベント・ハンドラまたはアダプタが削除されます。

28.9.2.1.5 アダプタのマップ・タブ

アダプタのマップ・タブは、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタをデータ・オブジェクトに割り当てた後でのみ使用できます。

このタブを使用して、ルール・ジェネレータ・アダプタまたはエンティティ・アダプタの変数を、それぞれに適したソースの場所およびターゲットの場所にマップします。たとえば、adpSOLARISUSERIDGENERATORアダプタにfirstname、Adapter return valueおよびlastnameの3つの変数があるとします。各アダプタ変数のマップ済列にYが表示されている場合は、3つの変数がすべて正しい場所にマップされており、アダプタのステータスが「準備完了」に変わります。

注意:

アダプタのステータスは、次の3つのいずれかになります。

- 準備完了: このアダプタは正常にコンパイルされており、すべての変数が正しくマップされています。

- マッピングが不完全: このアダプタは正常にコンパイルされていますが、正しくマップされていない変数が1つ以上あります。

- マッピングが不完全: このアダプタは正常にコンパイルされていますが、正しくマップされていない変数が1つ以上あります。

アダプタのコンパイルおよびアダプタ変数のマッピングの詳細は、第8章「アダプタ・ファクトリの使用」を参照してください。

注意:

データ・オブジェクトにアダプタが割り当てられていない場合は、アダプタのマップ・タブは無効になります。

29 コンテキストの理解

コンテキストは、Oracle Identity Managerの操作が実行される環境です。たとえば、Oracle Identity Self Serviceで行われるユーザー作成の操作は、Webコンテキストで実行されます。この操作が実行されるコンテキストまたは環境は、次のとおりです。

- 操作を実行するユーザー

- リクエストの送信日時

- アプリケーション・サーバーへのアクセスに使用されるプロキシ

たとえば、バルク・ロード・ユーティリティを実行してユーザーを作成する場合は、バルク・ロード・ユーティリティを起動したユーザー、操作を実行するコンピュータなどがコンテキストに含まれます。

コンテキストは、メイン・メモリーで保持されます。一連のコンテキスト変数で構成されており、各コンテキスト変数には名前と値の両方が含まれています。操作に関連のある各機能コンポーネント(リクエスト管理、リコンシリエーション、通知など)では、コンテキストに値を追加できます。コンテキストの値は、設定のみ可能であり、変更はできません。コンテキストの値は、操作に関連のあるコンポーネント間で情報をやりとりする手段として機能します。

コンテキストの変数値は、必要な場合にのみ、メモリーにロードされます。これにより、パフォーマンスが向上します。コンテキストは、イベント・ハンドラにより要求される一般的な値のキャッシュとしても機能します。これにより、必要な値を毎回、リポジトリからフェッチする必要がなくなります。

- 子コンテキスト

- コンテキスト・タイプ

29.1 子コンテキスト

子コンテキストは、操作の進行中に開始されるサブコンテキストです。たとえば、ユーザー作成の操作にアクセス・ポリシーを介したリソースのプロビジョニングが含まれている場合、リソース・プロビジョニングはアクセス・ポリシー・コンテキストで実行され、これはユーザーが作成されるコンテキストの子コンテキストとなります。これは、コンテキストのネストおよびコンテキストのスタックが可能であることを意味します。機能コンポーネントによって新規コンテキストが作成され、作成された新しいコンテキストを使用して追加の処理を開始できます。

29.2 コンテキスト・タイプ

コンテキスト・マネージャでは、次のコンテキスト・タイプがサポートされています。

- SELF: 操作は、Oracle Identity Self Serviceを介して開始されます。

- ADMIN: 操作は、Oracle Identity System Administrationを介して開始されます。これがデフォルトのコンテキストです。

- RECON: 操作は、リコンシリエーションによって実行されます。

- REQUEST: 操作は、リクエストによって実行されます。

- POLICY: 操作は、アクセス・ポリシーがあるために実行されます。

ContextManager.getContextType()のコールでは、コンテキストのタイプを伝える必要があります。様々なコンテキストで取得できる情報の一部を次に示します。

- ADMINコンテキストで実行されるスケジュール済タスク: 取得できる情報の一部を次に示します。

- ジョブ名: ContextManager.getValue("JOBNAME")

- タスク名: ContextManager.getValue("TASKNAME")

- リコンシリエーション・コンテキスト: リコンシリエーション・イベントの作成元であるプロファイルを、ContextManager.getValue("profileName")メソッド・コールにより取得できます。

- リクエスト・コンテキスト: 次のコードを使用してリクエスト・キーを取得できます。

HashMap<String, ContextAware> requestContext = (HashMap<String, ContextAware>) ContextManager.getValue("requestData", true);
requestContext.get("requestKey");

- ポリシー・コンテキスト: ContextManager.getContextKey()は、評価されるポリシーを提供します。複数のポリシーが適用可能な場合は、優先度が最も高いポリシー・キーが返されます。

第VII部

カスタマイズ

この部では、Oracle Identity Managerで使用できるユーザー・インタフェースのカスタマイズ方法について説明します。

次の章で構成されています。

- 第30章「インタフェースのカスタマイズ」

30 インタフェースのカスタマイズ

この章では、Oracle Identity Managerで使用可能なユーザー・インタフェースの様々な側面のカスタマイズ方法について説明します。

注意:

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)には、暫定UIと呼ばれる、従来のUIテクノロジに基づく多数のUIページが含まれています。技術上の相違のために、暫定UIはポップアップ・ウィンドウに表示され、そのルック・アンド・フィールは異なります。これらのUIについては、この章の関連する項で説明します。

Oracle Identity ManagerのIdentity Self Serviceユーザー・インタフェース(UI)は、Application Development Framework (ADF)に基づいており、カスタマイズの一貫性が保証されます。ADFによって、パッチおよびアップグレードから保護されたUIカスタマイズが可能になります。つまり、Oracle Identity Managerにパッチを適用したり、Oracle Identity Managerをアップグレードした後でも、UIカスタマイズが保持されることを意味します。

この章では、UIの様々な側面のカスタマイズについて、次の各項で説明します。

- カスタマイズの概念

- サンドボックスの管理

- Oracle Identity Managerでのスキンのカスタマイズ

- 実行時のページのカスタマイズ

- UIコンポーネントの保護

- Oracle Identity Managerヘルプのカスタマイズ

- ホーム・ページのカスタマイズ

- チャレンジ質問のカスタマイズ

- 暫定UIのカスタマイズ

- マネージドBeanおよびタスク・フローの開発

- UIカスタマイズの移行

- UIカスタマイズのベスト・プラクティス

- UIカスタマイズのロールバック

30.1 カスタマイズの概念

この項では、UIカスタマイズに関連する概念について、次の各項で説明します。

- UIライブラリおよびアプリケーションのデプロイ

- MDSカスタマイズの概要

- Web Composerの概要

30.1.1 UIライブラリおよびアプリケーションのデプロイ

ADFは、組込みのカスタマイズおよびMDSカスタマイズをサポートします。新しいUIアーティファクトまたはスキンを開発し、それをカスタム・ライブラリWARファイルにパッケージ化することによって、カスタマイズが実現されます。スキンおよびスタイルシートは、UIのルック・アンド・フィールをカスタマイズできるメカニズムです。スタイルシートの変更やカスタム・スキンを使用する利点は、これらの変更が集中管理されており、簡単に管理できる点です。

図30-1は、様々なOracle Identity Manager UIライブラリと、その従属構造を示しています。

図30-1 Oracle Identity Manager UIライブラリ

カスタム・ライブラリは、デフォルトのライブラリを使用して構築する新しいタスク・フローを追加する場合に使用できるプレースホルダ・ライブラリです。セルフ・サービスEARでは、ライブラリ参照名oracle.iam.ui.customへのweblogic.xmlの依存が宣言されます。このライブラリは、oracle.iam.ui.custom-dev-starter-pack.warによって提供されます。組織のネーミング規則ごとに、カスタム・ライブラリのWARファイル名を変更できます。ただし、デプロイメント名(MANIFEST.MFのライブラリ拡張名)は、oracle.iam.ui.customとして保持される必要があります。そうでない場合、セルフ・サービスearはデプロイされません。

Oracle Identity Analytics (OIA)のデプロイメント名は、oracle.iam.ui.oia-viewです。

30.1.2 MDSカスタマイズの概要

MDSのカスタマイズ機能を使用して、次のカスタマイズ・パターンのアプリケーションを作成できます。

- シード・カスタマイズ: アプリケーションのシード・カスタマイズとは、汎用化されたアプリケーションを特定のグループ(特定の業界やサイトなど)の要件に合せて変更するプロセスです。シード・カスタマイズはデプロイされたアプリケーションの一部として存在し、特定のデプロイ期間中保持されます。

- ユーザー・カスタマイズ: ユーザー・カスタマイズでは、エンド・ユーザーは実行時に個々のプリファレンス(表にどの列を表示するかなど)に合せてアプリケーションの内容を変更できます。また、変更内容が、次回そのアプリケーションを開くときに保持されているようにできます。

- 実行時カスタマイズ: Oracle WebCenterの機能を使用して、実行時にカスタマイズ可能なアプリケーションを作成できます。これにより、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。

MDSでのアプリケーションのカスタマイズの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のMDSによるアプリケーションのカスタマイズに関する説明を参照してください。

30.1.3 Web Composerの概要

Oracle Web Composerは、デプロイ済で使用中のアプリケーションまたはポータルのカスタマイズやパーソナライズを可能にする革新的なコンポーネントです。Oracle Web Composerはすべての最新のWebブラウザで動作し、ビジネス・ディクショナリまたはリソース・カタログから情報およびコンポーネントを選択することによって、JSFアプリケーションとポータル・ページを編集できます。

Web Composerのカスタマイズ機能には、自社に合せたロゴの挿入や色の変更、複雑なカスタマイズ、ページへの項目の追加、ページのレイアウト変更、提供されたプロセスの変更、提供されたアプリケーションまたはポータルのビジネス要件に合せた特殊な調整などがあります。これらのカスタマイズは、Oracle Metadata Services (MDS)を使用してOracle Identity Managerデータベースに格納できます。たとえば、データベースにカスタマイズを格納するために、Web Composerはページの編集中に、ページのコピーまたはサンドボックスを作成します。このサンドボックスは、ランタイム・ページ・カスタマイズの保存、他のユーザーへの公開、または破棄が行われるまで、そのカスタマイズのグループを保存しておく一時記憶領域です。このように、カスタマイズは他のユーザーがプレビューすることができ、すべてのユーザーが参照できるようになる前に使用することを承認できます。サンドボックスの詳細は、「サンドボックスの管理」を参照してください。

パーソナライズでは、インタフェースまたはアプリケーション・ページの表示を変更します。1人のユーザーが行った変更が他のユーザーに影響することはありません。ページのパーソナライズは、個々のユーザーが任意の組合せのコンポーネントをページに追加することで、必要なときに、他のユーザーのページに影響を与えることなく実行できます。

Oracle Web Composerは、Oracle WebCenter FrameworkおよびWebCenter Servicesと統合されています。Oracle Web Composerコンポーネントを自分のJSFアプリケーション・ページに追加し、ユーザーがこれらのページを実行時に編集できるようにすることができます。このコンポーネントは、開発ライフサイクル中にいつでも必要に応じて追加できます。また、ページ・サービスを使用すると、ユーザーは実行時にページを作成できるようになります。Oracle Web Composerは、Oracle WebCenter Spaces内部で広く使用されており、ユーザーによるパーソナルおよびグループ・スペースのカスタマイズとパーソナライズが可能になっています。Oracle WebCenter Spacesアプリケーションは、ユーザーが自身の要件に合せて彼らの作業環境の管理および変更に積極的な役割を担う方法を実現しています。図30-2は、Oracle Web Composerアーキテクチャを示しています。

図30-2 Oracle Web Composerアーキテクチャ

30.2 サンドボックスの管理

すべてのカスタマイズとフォーム管理は、サンドボックスで実行されます。サンドボックスを使用すると、他のユーザーの環境に影響を与えることなく、カスタマイズを分離し、テストすることができます。サンドボックスに加えたユーザー・インタフェースの変更は、サンドボックス内でのみ参照可能です。カスタマイズおよびフォーム管理機能の使用を開始するには、サンドボックスを作成してアクティブにする必要があります。フォームのカスタマイズおよび拡張が完了したら、サンドボックスを公開してそのカスタマイズを他のユーザーが使用できるようにします。

いくつかのサンドボックス操作を、次に示します。

- アクティブ化: サンドボックスを使用するには、それをアクティブにする必要があります。サンドボックスをアクティブにした後、UIメタデータ・オブジェクトへの変更はすべて(たとえば、ページやフォームなど)、サンドボックスにのみ格納されます。アクティブなサンドボックスは、一度に1つのみ存在できます。アクティブなサンドボックスに関する情報は、セッションに格納されます。したがって、カスタマイズを続行するには、Oracle Identity Managerにログインするたびに、サンドボックスをアクティブにする必要があります。

注意:

サンドボックスを作成した後に、それをアクティブにする必要があります。サンドボックスをアクティブにしない場合、後でサンドボックスに対して操作を実行できなくなるか、必要な結果が得られない場合があります。たとえば、サンドボックスを作成してもそれをアクティブにしていない場合に、接続なしアプリケーション・インスタンスを作成し、カタログ同期のスケジュール済ジョブを実行し、Identity System Administrationにログインし、「カタログ」ページで接続なしアプリケーション・インスタンスのチェックアウトを試行すると、エラーが生成されます。サンドボックスを作成後、およびIdentity Self ServiceまたはIdentity System Administrationへの各ログイン後にアクティブ化した場合は、エラーなしでこの操作を実行できます。

- 非アクティブ化: サンドボックスのアクティブに対する逆の操作です。アクティブなサンドボックスがない場合、メタデータ・オブジェクトへの変更は許可されず、UIカスタマイズも許可されません。

- 公開: サンドボックスに格納されている変更をメインラインにマージして、それを他のユーザーに使用可能にするには、サンドボックスを公開する必要があります。サンドボックスを公開すると、その変更はメインラインにマージされ、元に戻すことはできません。そのサンドボックスは、アクティブ化、非アクティブ化、エクスポートまたは削除できなくなります。

注意:

サンドボックスを公開する前に、Identity Self ServiceまたはIdentity System Administrationのすべてのタブおよびページを閉じ、サンドボックスをZIPファイルにエクスポートして、完了済のUIカスタマイズのバックアップを作成します。

すべてのサンドボックスについて、その公開前にMDSのバックアップを作成することをお薦めします。MDSバックアップは、Oracle Enterprise Managerなどのツールを使用して作成できます。Oracle Enterprise Managerを使用したMDSのバックアップの作成の詳細は、「MDSバックアップの作成」を参照してください。

- エクスポート: サンドボックス・メタデータなど、サンドボックスに格納されているすべての変更を、ZIPファイルにエクスポートできます。これらの変更は、同じ環境または別の環境にインポートできます。

- インポート: サンドボックス・アーカイブ(ZIPファイル)を、任意の環境にインポートできます。通常、インポートされたサンドボックスは、その環境で作成されたように使用できます。サンドボックスをインポートすると、同じ名前を持つ使用可能なすべてのサンドボックスが、インポートされるサンドボックスによって上書きされることに注意してください。

注意:

同じ名前を持つ使用可能なすべてのサンドボックスが、インポートされるサンドボックスによって上書きされます。

サンドボックスの管理およびサンドボックスの操作は、同時バージョニング・システムでの操作に似ています。サンドボックスをバージョニング・システムのブランチと見なすことができます。サンドボックスの作成方法は、ブランチの作成方法に似ています。サンドボックスのアクティブ化はブランチの最上位での変更と似ており、サンドボックスの公開はメイン・ブランチ(トランクと呼ばれる場合もある)にブランチ・コンテンツをマージすることと似ています。

注意:

サンドボックスを作成すると、新しいブランチが作成されます。そのブランチ内でMDSの内容を変更できます。後で作成してメイン・ブランチに公開した、他のサンドボックスで行った変更を表示することはできません。同様に、このサンドボックスをマージしようとすると、同時変更例外が生成されます。サンドボックスの内容を手動で編集し、競合するファイル削除することをお薦めします。ただし、手動による編集ができない場合は、新しいサンドボックスを再度作成し、変更をやり直します。

この項では、サンドボックスを管理する方法について、次の各項で説明します。

- 同時実行の競合への対処

- サンドボックスの作成

- サンドボックスのアクティブ化および非アクティブ化

- サンドボックス詳細の表示および変更

- サンドボックスのエクスポートおよびインポート

- サンドボックスの公開

- カートからのアイテムのチェックアウト

- サンドボックスの削除

- 変更をデフォルト設定に戻す

30.2.1 同時実行の競合への対処

複数のユーザーが、サンドボックスを使用してアプリケーションをカスタマイズできます。その場合、次のタイプの同時実行の競合が発生する可能性があります。

- サンドボックス内の競合: ユーザーが、他のユーザーによって作成された変更を、直接的に同じアーティファクトを変更するか、間接的にアーティファクト間で共有されるファイルに影響を与えることによって上書きする場合。
複数のユーザーが同時に同じサンドボックスを使用してアプリケーションをカスタマイズしている場合に、複数のユーザーが同じアーティファクトをカスタマイズしようとしたか、または他の共有ファイルに間接的に影響を与えるカスタマイズ・タスクを実行したことが原因で、サンドボックス内の競合が発生する可能性があります。直接的な競合の1つの例は、異なるユーザーが同じレイヤー内の同じページ、同じフラグメント、または同じメタデータ・ファイルをカスタマイズしようとした場合です。間接的な競合の1つの例は、2人のユーザーが、それぞれ自分自身のオブジェクトを作成中に、どちらも同時間帯に自分の変更を保存したことによって、新しいオブジェクトの作成を追跡するメタデータ・ファイルで競合が発生した場合です。ユーザーが翻訳可能な文字列を追加または編集する操作を実行した場合など、ユーザーが共有アーティファクトの編集中に競合が発生することもあります。たとえば、あるユーザーがフィールドの表示ラベルやヘルプ・テキスト、検証ルールのエラー・メッセージを編集している一方で、別のユーザーが同時間帯に翻訳可能な文字列に同様に影響を与える操作を実行することがあります。共有アーティファクトの競合のもう1つの例として、アプリケーション全体で共有されるナビゲータ・メニューで複数のユーザーが作業する場合があります。

- 公開を目的とするサンドボックス間の競合: メインラインに公開される同じカスタマイズ済アーティファクトを持つ複数のサンドボックスがある場合。
公開を目的とする使用中のサンドボックスが複数存在する場合、サンドボックス間に競合が発生する可能性があります。同じアーティファクトに対する競合するカスタマイズ変更が2つのサンドボックスに含まれるときに、その両方を公開しようとすると、後に公開するサンドボックスについては公開が許可されず、競合について説明するエラーが表示されます。このような競合を回避するには、一度に1つのサンドボックスのみを作成して使用することをお薦めします。この種の競合は、翻訳可能な文字列を格納するリソース・バンドルなど、共有メタデータ・ファイルで発生する可能性もあります。

複数のユーザーが単一のサンドボックスで作業する場合、次のガイドラインに従う必要があります。

- 同じサンドボックスの複数の同時ユーザーは、別の無関係なオブジェクトのみを操作する必要があります。たとえば、user1がobject1を更新する場合、user2はobject2を更新できますが、object1は更新しないでください。両方の修正に、翻訳可能な文字列に対する変更が含まれている場合、別々のオブジェクトに対する変更でも同時間帯に保存すると、翻訳可能な文字列を格納するリソース・バンドルで競合が発生する可能性があることに注意してください。

- 同じサンドボックスのユーザーは、お互いが作成した変更を確認できます。各オブジェクトの最新バージョンは、それが最初に表示されるときにオンデマンドでロードされます。ADF Business Componentsのカスタマイズがある場合、ユーザーはログアウトしてから再度ログインし、変更がUIに反映されていることを確認する必要があります。

複数のユーザーが複数のサンドボックスで作業している場合は、単一のサンドボックスで作業する複数のユーザーに適用されるすべてのガイドラインに加えて、次のガイドラインに従う必要があります。

- テストのみのサンドボックスについては、任意の数のサンドボックスが同時に存在できます。これらのサンドボックスが公開されない場合でも、複数のユーザーがテスト用の複数のサンドボックスを同時に使用できます。テストのみに使用される、公開されないサンドボックスは相互に競合を引き起こしませんが、単一のサンドボックスで動作している複数のユーザーを対象とするすべてのガイドラインに従う必要があります。ただし、サンドボックスが削除されると、すべての変更が失われます。

- 公開されるサンドボックスについては、互いに排他的なアーティファクトで動作する場合にのみ、複数のサンドボックスを同時に持つことができます。たとえば、タスク・フローを追加するためにカスタマイズするページが含まれるサンドボックスと、異なるアプリケーションからの異なるページが含まれるサンドボックスを持つことができます。

- 1つのアーティファクトがメインラインとサンドボックスの両方(または2つの異なるサンドボックス)で更新された場合に、そのサンドボックスを公開すると、その競合が検出され、エラーが生成されます。

30.2.1.1 同時実行性の問題のトラブルシューティング

表30-1に、サンドボックスの使用法に同時実行性の競合がある場合に直面する問題点および考えられる解決策を示します。

表30-1 同時実行性の問題のトラブルシューティング

使用例

問題

解決策

同時公開のため複数のサンドボックスで作業:

サンドボックスS1を作成し、サンドボックスS2を作成し、S2に変更を加え、S2を公開し、S1に変更を加え、S1を公開します。

S1の公開を試行すると、エラーがスローされます。

新しいサンドボックスを作成して、変更をやり直します。

正常に動作しないサンドボックスの移行:

環境1で、サンドボックスS1を作成し、S1に変更を加え、S1をエクスポートおよび公開します。S2に対しても同様の操作を繰り返します。

環境2で、S2をインポートし、S2を公開します。その後、S1をインポートし、S1を公開します。

サンドボックスS1とサンドボックスS2は異なる順序で公開されます。

S1とS2の間で重複がある場合(たとえば、2つのサンドボックスが同じMDSドキュメントを更新した場合)、S2の一部として加えられた変更がS1により上書きされます。

たとえば、ADコネクタ・フォームがS1の一部として作成され、EBSコネクタ・フォームがS2の一部として作成されている場合、CatalogAM.xml.xmlおよびBizEditorリソース・バンドル・ファイルの間に重複が生じます。移行後、CatalogAM.xml.xmlおよびBizEditorリソース・バンドルには、S1の一部として開発されたADコネクタの変更のみ含まれます。

正しい順序でサンドボックスを公開します。これにより、再公開できます。

移行時のサンドボックスのスキップ:

環境1で、サンドボックスS1を作成し、S1に変更を加え、S1をエクスポートおよび公開します。S2に対しても同様の操作を繰り返します。

環境2で、S2をインポートし、S2を公開します。S1は移行しません。

環境1で公開されるS1は環境2へ移行しません。

S2が、S1の一部として加えられた変更に依存している場合、それらの変更は環境2では失われます。

両方のサンドボックスを公開します。これにより、再公開できます。

複数のソース環境からのサンドボックスの移行:

環境1で、サンドボックスS1を作成し、S1に変更を加え、S1をエクスポートおよび公開します。

環境2で、サンドボックスS2を作成し、S2に変更を加え、S2をエクスポートおよび公開します。

環境3で、S1をインポートし、S1を公開します。S2をインポートし、S2を公開します。

S1とS2の間で重複がある場合(たとえば、2つのサンドボックスが同じMDSドキュメントを更新した場合)、S1の一部として加えられた変更が失われます。

たとえば、ADコネクタ・フォームがS1の一部として作成され、EBSコネクタ・フォームがS2の一部として作成されている場合、CatalogAM.xml.xmlおよびBizEditorリソース・バンドル・ファイルの間に重複が生じます。移行後、CatalogAM.xml.xmlおよびBizEditorリソース・バンドルには、S2の一部として開発されたEBSコネクタの変更のみ含まれます。

手動により、サンドボックスを1つにマージします。

30.2.2 サンドボックスの作成

サンドボックスを作成するには、次の手順を実行します。

1. Oracle Identity Self ServiceまたはOracle Identity System Administrationにログインします。

2. 上部のナビゲーション・バーで、「サンドボックス」をクリックします。「サンドボックスの管理」ページが表示されます。このページには次のセクションがあります。

- 使用可能なサンドボックス: UIカスタマイズをテストするために使用可能なすべてのサンドボックス(未公開)を表示します。

- 公開済サンドボックス: 公開されたすべてのサンドボックスを表示します。

3. ツールバーで、「サンドボックスの作成」をクリックします。「サンドボックスの作成」ダイアログ・ボックスが表示されます。

4. 「サンドボックス名」フィールドに、サンドボックスの名前を入力します。これは必須フィールドです。

5. 「サンドボックスの説明」フィールドに、サンドボックスの説明を入力します。これはオプションのフィールドです。

6. 「保存して閉じる」をクリックします。メッセージに、サンドボックス名と作成ラベルが表示されます。

注意:

「サンドボックスのアクティブ化」オプションを選択すると、「サンドボックスの管理」タブ以外の開いているすべてのタブが閉じ、作成されたサンドボックスがアクティブになります。

7. 「OK」をクリックします。このサンドボックスが、「サンドボックスの管理」ページの「使用可能なサンドボックス」セクションに表示されます。

30.2.3 サンドボックスのアクティブ化および非アクティブ化

サンドボックスをアクティブにするには、次の手順を実行します。

注意:

サンドボックスをアクティブ化または非アクティブ化する前に、「セルフ・サービス」または「システム管理」インタフェースですべてのタブを閉じる必要があります。

1. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表から、アクティブにするサンドボックスを選択します。

2. ツールバーで、「サンドボックスのアクティブ化」をクリックします。
表がリフレッシュされ、「アクティブ」列にマーカーが表示されます。また、上部のナビゲーション・バーの「サンドボックス」リンクに、カッコ内にアクティブなサンドボックス名が表示されます。

注意:

サンドボックスをアクティブにする前に「サンドボックスの管理」タブ以外のタブが開いている場合、Oracle Identity Managerからすべてのタブを閉じてからサンドボックスをアクティブにするように求められます。

サンドボックスを非アクティブ化するには、次の手順を実行します。

1. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表から、非アクティブにするアクティブなサンドボックスを選択します。

2. ツールバーで、「サンドボックスの非アクティブ化」をクリックします。ページがリフレッシュされ、「アクティブ」表のマーカーが非表示になります。

注意:

サンドボックスをアクティブにする前に「サンドボックスの管理」タブ以外のタブが開いている場合、Oracle Identity Managerからすべてのタブを閉じてからサンドボックスをアクティブにするように求められます。

30.2.4 サンドボックスの詳細の表示および変更

サンドボックスの詳細を表示し、詳細を変更するには、次の手順を実行します。

1. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表で、サンドボックス名リンクをクリックします。サンドボックスの詳細が示されるダイアログ・ボックスが表示されます。

2. 次の変更を行います。

- 「説明」フィールドに、サンドボックスの説明を入力できます。

- 「詳細の変更」表のサンドボックスに対するすべての変更が表示されます。

- フィルタ・サンドボックスは「レイヤー名」、「レイヤー値」および「タイプの変更」リストおよび「フィルタ」ツールバー・アイコンを使用して変更します。

- 表で変更を選択し、「カスタマイズの削除」をクリックして、サンドボックスで行った変更を削除します。

- サンドボックスに変更が含まれる場合に、「サンドボックスのエクスポート」をクリックしてサンドボックスをエクスポートします。

30.2.5 サンドボックスのエクスポートおよびインポート

Oracle Identity Managerデプロイメント間から別のデプロイメントにサンドボックスをエクスポートするには、次の手順を実行します。

1. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表から、エクスポートするサンドボックスを選択します。

2. ツールバーで、「サンドボックスのエクスポート」をクリックします。
サンドボックスに変更が含まれる場合、サンドボックスのコンテンツZIPファイルがダウンロードを開始します。これでZIPファイルを取得し、同じ環境または別の環境にそれをインポートすることができます。

注意:

サンドボックスZIPファイルの名前は、サンドボックス名ではありません。サンドボックス名は通常、IdM_で始まり、/mdssys/sandbox/ディレクトリのZIP内にあるXMLファイルで指定されています。

注意:

サンドボックスのコンテンツZIPファイルがインポートされるデプロイメントに、すでに同じ名前のサンドボックスが含まれている場合、そのサンドボックスは上書きされます。

Oracle Identity Managerデプロイメントから別のデプロイメントにサンドボックスをインポートするには、次の手順を実行します。

1. ツールバーで、「サンドボックスのインポート」をクリックします。「サンドボックスのインポート」ダイアログ・ボックスが表示されます。

2. 「サンドボックス・アーカイブ」フィールドに、エクスポートしたサンドボックス・アーカイブへのパスを入力します。

3. 「インポート」をクリックします。
サンドボックスはターゲット・デプロイメントにインポートされ、「使用可能なサンドボックス」タブに表示されます。

30.2.6 サンドボックスの公開

サンドボックスを公開するには、次の手順を実行します。

注意:

サンドボックスを公開する前に、MDSのバックアップを作成することをお薦めします。MDSのバックアップは、Oracle Enterprise Managerを使用して作成できます。Oracle Enterprise Managerを使用したMDSのバックアップの作成の詳細は、「MDSバックアップの作成」を参照してください。

1. サンドボックスを公開する前に、すべての開いているタブおよびページを閉じます。

2. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表から、公開するサンドボックスを選択します。

3. ツールバーで、「サンドボックスの公開」をクリックします。確認を求めるメッセージが表示されます。

4. 「はい」をクリックして確認します。サンドボックスが公開され、それに含まれるカスタマイズがメインラインとマージされます。

5. 「公開済サンドボックス」タブをクリックすると、公開されたサンドボックスのリストを表示できます。

30.2.7 カートからのアイテムのチェックアウト

カートからアイテムをチェックアウトするには、次の手順を実行します。

1. Oracle Identity Self Serviceにログインします。

2. サンドボックスを作成します。サンドボックスの作成の詳細は、「サンドボックスの作成」を参照してください。

3. 作成したサンドボックスをアクティブ化します。サンドボックスのアクティブ化の詳細は、「サンドボックスのアクティブ化および非アクティブ化」を参照してください。

注意:

サンドボックスをアクティブ化しないでアプリケーション・インスタンスをカタログに追加しようとすると、エラーが発生します。

4. 接続なしアプリケーション・インスタンスdisc1を作成します。デフォルトでは、これが先頭で公開されます。接続なしアプリケーション・インスタンスの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の接続なしアプリケーション・インスタンスの作成に関する項を参照してください。

5. サンドボックスを発行します。サンドボックスの公開の詳細は、「サンドボックスの公開」を参照してください。

6. カタログ同期化ジョブを実行します。

7. Oracle Identity System Administrationにログインします。

8. 「カタログ」をクリックし、disc1を検索します。

9. 「追加」をクリックし、アイテムをカートに追加します。

10. カートからチェックアウトをクリックします。

30.2.8 サンドボックスの削除

サンドボックスを削除するには、次の手順を実行します。

1. 「サンドボックスの管理」ページの使用可能なサンドボックスが表示される表から、削除するサンドボックスを選択します。

2. ツールバーで、「サンドボックスの削除」をクリックします。確認を求めるメッセージが表示されます。

3. 「はい」をクリックして確認します。サンドボックスが削除され、「サンドボックスの管理」ページに表示されなくなります。

30.2.9 変更をデフォルト設定に戻す

すべてのカスタマイズを1つのサンドボックスで実行する必要があります。サンドボックスが公開されるまでは、変更はそのユーザーのみが表示可能で、このサンドボックスを非アクティブ化または削除することで簡単に元に戻すことができます。サンドボックスが公開された後は、実行された変更を元に戻すことはできません。

次の方法のいずれかで、サンドボックスから特定の変更を削除できます。

- サンドボックスをエクスポートし、手動でそれを変更します。

- 「サンドボックスの管理」ページに移動し、サンドボックスの詳細を開き、変更を選択し、「カスタマイズの削除」をクリックして削除します。

MDSサンドボックスを公開すると、それらのドキュメントがメインラインにコミットされます。これらのドキュメントを使用してアプリケーションがただちに起動され、サンドボックスを公開した効果がアプリケーション・ユーザーに表示されます。場合によっては、意図せずに不完全なまたは誤ったサンドボックスを公開してしまうことがあります。そのような場合、誤ったサンドボックスを作成する直前の状態にメインラインを戻すことができます。

たとえば、時刻T1にShowAdminFeatureというサンドボックスを作成し、その中で時刻T2に公開したJSFFフラグメントをカスタマイズしたとします。公開したサンドボックスが誤りであった場合、時刻T1の状態を戻すことが必要になります。これを行うには、次の手順を実行します。

1. Oracle Enterprise Managerにログインします。

2. 左側のペインで、「アプリケーションのデプロイ」→ 「リソース・アダプタ」を開き、oracle.iam.ui.console.self-serviceアプリケーションを選択します。

3. 右側のペインの上部で、「アプリケーションのデプロイ」をクリックし、「MDS構成」を選択します。

4. 右側のペインの下部で、「ランタイムMBeanブラウザ」リンクをクリックします。画面が更新されます。

5. 「操作」タブをクリックします。

6. 下方向にスクロールしてlistMetadataLabels MBean操作を選択し、「起動」をクリックします。サンドボックスの作成前ラベルおよび公開後ラベルがすべて表示されます。事前に作成されたサンドボックスのうちのどれにリストアするのかを選択し、それをクリップボードにコピーします。

7. 「戻る」をクリックし、操作に戻ります。

8. promoteMetadataLabel MBean操作を選択し、手順6でコピーした値を指定することでそれを呼び出します。

9. oim_server1を再起動します。
MDSメインラインが、サンドボックスの作成時の状態に戻ります。

注意:

最後に成功したサンドボックスのポスト・ラベルにリストアすることで、公開したそのサンドボックスにリストアすることもできます。

30.3 Oracle Identity Managerでのスキンのカスタマイズ

Oracle ADFでは、アプリケーションの外観をカスタマイズするためにスタイルとともにスキンを使用します。これらの概念は、暫定UIのポップアップを除き、Oracle Identity Managerのすべてのインタフェースに適用されます。

関連項目:

スタイルシートをカスタマイズする前に、次のURLでFusion Middleware Webユーザー・インタフェース開発者ガイドのスタイルおよびスキンを使用した外観のカスタマイズに関する説明を参照してください。

http://download.oracle.com/docs/cd/E15523_01/web.1111/b31973/toc.htm

次のURLでは、スタイルシートをカスタマイズするために使用できるCSSスタイル・セレクタすべてがリストされています。

http://download.oracle.com/docs/cd/E15523_01/apirefs.1111/e15862/toc.htm

trinidad-config.xmlで新規スキンを構成します。Oracle Identity Managerのデフォルトのスキンは、fusionです。

<?xml version="1.0" encoding='utf-8'?>
<trinidad-config xmlns="http://myfaces.apache.org/trinidad/config">
<skin-family>fusion</skin-family>
</trinidad-config>

コンソール固有のtrinidad-config.xmlファイルは、2つあります。これらのファイルは、次のディレクトリ・パスにあります。

- oracle.iam.console.identity.self-service.ear/oracle.iam.console.identity.self-service.war/WEB-INF/

- oracle.iam.console.identity.sysadmin.ear/oracle.iam.console.identity.sysadmin.war/WEB-INF/

- oim.ear/iam-consoles-faces.war/WEB-INF/

30.3.1 新しいスキンの構成

新しいスキンを作成するには、次の手順を実行します。

1. WEB-INFディレクトリにはそれぞれ、次に示すようにtrinidad-skins.xmlファイルを作成します。

<?xml version="1.0" encoding='utf-8'?>
<skins xmlns="http://myfaces.apache.org/trinidad/skin">
<skin>
<id>myskin.desktop</id>
<family>myskin</family>
<extends>fusionFx-v1.desktop</extends>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>skins/myskin/myskin.css</style-sheet-name>
</skin>
</skins>

2. 次のシステム・プロパティを構成します。

- OIM UIのスキン・ファミリ: アプリケーションが実行時に使用するOracle Identity Manager UIのADFスキン・ファミリ。

- OIM UIのスキン・バージョン: Oracle Identity Manager UIに使用されるスキン・ファミリのスキン・バージョン(存在する場合)。

関連項目:

「OIM UIのスキン・ファミリ」および「OIM UIのスキン・バージョン」システム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のOracle Identity Managerのシステム・プロパティに関する説明を参照してください。

これらのプロパティの値をカスタム・スキンに変更します。これらのプロパティの値を設定する前に、カスタムADFスキンを開発し、Oracle Identity Managerにデプロイする必要があります。

Oracle ADF Facesは、カスタム・スキンで拡張するように設計された、簡略化されたデフォルトのスキン(fusionFx-simple-v2.desktopなど)を提供します。作成するADFスキンは、Oracle ADFによって提供されるADFスキン、または作成した既存のADFスキンのいずれかを拡張したものである必要があります。スキンは再使用可能なコンポーネントであり、それ自体のJDeveloperプロジェクトまたはワークスペースで作成される必要があります。ADF Facesコンポーネントが実行時にレンダリングされる方法を定義するADFスキン・ファイルを、ADFスキン・エディタで作成できます。

関連項目:

- Oracle ADFが提供するADFスキンの間の継承関係の詳細は、『OracleFusion Middleware Oracle Application Development Frameworkスキン・エディタ・ユーザーズ・ガイド』のOracle ADFによって提供されるADFスキンの継承関係に関する説明を参照してください。

- Oracle ADFによって提供されるADFスキン内のカスタマイズ・レベル、および拡張するADFスキンに関する推奨事項については、『Oracle Fusion Middleware Oracle Application Development Frameworkスキン・エディタ・ユーザーズ・ガイド』のOracle ADFによって提供されるADFスキンに関する説明を参照してください。

- ADFカスタム・スキン開発およびデプロイメントの詳細は、『Oracle Fusion Middleware Oracle Application Development Frameworkスキン・エディタ・ユーザーズ・ガイド』および『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。

3. 必要に応じて、次の新しいロゴ・イメージに合せて上部のブランド・バーの高さを調節します。

oracle.iam.console.identity.self-service.ear/oracle.iam.console.identity.self-service.war/oracle/iam/ui/main

ログイン・ページの場合(signin.jspx):

<f:attribute name="globalBrandingSize" value="64"/>

チャレンジ質問を表示するページの場合(firstlogin.jspx):

<f:attribute name="globalHeaderSize" value="64"/>

Identity Self Serviceのページの場合(identity.jspx):

<f:attribute name="globalHeaderSize" value="64"/>

4. oracle.iam.console.identity.self-service.ear/oracle.iam.console.identity.self-service.war/Web-INF/web.xmlファイルに、次の設定を含めます。

<context-param>
<description>No obfuscation of CSS.</description>
<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<description>If this parameter is true, there will be an automatic check of the modification date of your JSPs, and saved state will be discarded when JSP's change. It will also automatically check if your skinning css files have changed without you having to restart the server. This makes development easier, but adds overhead. For this reason this parameter should be set to false when your application is deployed.</description>
<param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>
<param-value>true</param-value>
</context-param>

30.3.2 レガシー拡張コンソールのスキンの構成

fusionスキンによるデフォルトを保持して、特定のスタイルシート要素をオーバーライドするには、次の手順を実行します。

1. trinidad-skins.xmlファイルでスキンを作成します。次に示すように、新規ファイルoim.ear/iam-consoles-faces.war/WEB-INF/trinidad-skins.xmlでスキンを宣言します。

<?xml version="1.0" encoding='utf-8'?>
<skins xmlns="http://myfaces.apache.org/trinidad/skin">
<skin>
<id>myskin.desktop</id>
<family>myskin</family>
<extends>fusion.desktop</extends>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>skins/myskin/myskin.css</style-sheet-name>
<bundle-name>oracle.iam.consoles.faces.resources.AdfComponentsMessageBundle</bundle-name>
</skin>
</skins>

2. 次に示すように、/WEB-INF/trinidad-config.xmlファイルとiam-consoles-faces.war/WEB-INF/trinidad-config.xmlファイルの両方で、新しい「myskin」を登録します。

<?xml version="1.0" encoding='utf-8'?>
<trinidad-config xmlns="http://myfaces.apache.org/trinidad/config">
<skin-family>myskin</skin-family>
</trinidad-config>

3. 新しいスキンのCSSファイルoim.ear/iam-consoles-faces.war/skins/myskin/myskin.cssを作成します。

4. myskin.cssでは、デフォルトからオーバーライドされる必要があるスタイルシート要素を指定します。たとえば、ブランド・テキストの色を変更するには、次を追加します。

.AFBrandingBarTitle, .xdj
{
color:#800080;
}

5. Oracle WebLogic Server管理コンソールを使用して、Oracle Identity Managerデプロイメントを再デプロイ(または更新)します。

注意:

ブランド情報を変更する場合に、「ブランドおよびロゴの変更」の方法のかわりに、カスタム・スキンを作成して、この項のURLで示した適切なスタイル・クラスを使用する方法があります。

30.3.3 ブランドおよびロゴの変更

UIアーティファクト(ロゴ、ボタン、メニュー項目など)のカスタマイズまたは変更は、Oracle WebCenter Composerを使用して実行時に実行できます。

注意:

この項で説明する手順は、Oracle Identity Self Serviceをカスタマイズすることでブランドおよびロゴを変更するためのものです。Oracle Identity System Administrationから開くウィンドウ(たとえば、「システム管理」の下の「システム構成」をクリックしたときに開くウィンドウ)のUIアーティファクトをカスタマイズする場合は、次のURLのブランドのカスタマイズに関する項を参照してください。

http://docs.oracle.com/cd/E21764_01/doc.1111/e14309/uicust.htm#BABFCFID

ロゴ・イメージを変更するには、次の手順を実行します。

1. システム管理者としてOracle Identity Self Serviceにログインします。

2. サンドボックスを作成し、アクティブにします。

注意:

Web Composerを使用してUIをカスタマイズするには、サンドボックスの作成およびアクティブ化が必須です。アクティブなサンドボックスがないと、Oracle Identity Managerでページをカスタマイズ・モードで開くことができません。

3. 「カスタマイズ」をクリックします。Oracle WebCenter Composerが開きます。ページの上部に、「編集中のページ」と表示されます。

4. 「表示」リストから、「ソース」を選択します。オブジェクト・ツリーが、上部のペインに表示されます。オブジェクト・ツリーに、ページのすべてのADFコンポーネントが表示されます。

5. ロゴをクリックします。図30-3に示すように、オブジェクト・ツリーでロゴ・オブジェクトが選択されます。

図30-3 WebCenter Composerのオブジェクト・ライブラリ

図30-4に示すように、オブジェクト・ツリーに表示されるADFコンポーネントは、JDeveloperの構造ペインと似ています。

図30-4 構造ペイン

6. 「編集」をクリックします。「コンポーネント・プロパティ」ダイアログ・ボックスが表示されます。

7. 「スタイル」タブをクリックします。

8. 「背景イメージ」フィールドで、設定するロゴ・イメージへのパスを、url(/identity/faces/images/mylogo.jpg)のように入力します。

ヒント:

- イメージ・ファイルをOIM_ORACLE_HOME/server/apps/oim.ear/xlWebApp.warに配置し、URLで参照します(たとえば、url(/xlWebApp/mylogo.png)とします)。これは、Oracle Identity Managerのクラスタ化デプロイメントの各ノードで個別に実行する必要があります。

- デフォルトでは、Oracleロゴは119x25ピクセルです。したがって、同じ寸法のカスタム・ロゴを使用できます。これよりも大きいロゴを使用する場合は、CSSを変更する必要があります。

図30-5は、「コンポーネント・プロパティ」ダイアログ・ボックスの「スタイル」タブを示しています。

図30-5 「コンポーネント・プロパティ」ダイアログ・ボックス

ヒント:

「コンポーネント・プロパティ」ダイアログ・ボックスの「スタイル」タブを使用することで、いずれかのADFコンポーネントのフォントを指定する場合は、ターゲット・ブラウザおよびプラットフォームで、その特定のフォント名がサポートされていることを確認してください。Mozilla Firefoxに対してサポートされているリストを調べるには、「ツール」→「オプション」→「コンテンツ」→「フォントと配色」を選択します。Microsoft Internet Explorerの場合は、「ツール」→「インターネット オプション」→「全般」→「フォント」を選択します。

9. Identity Self Serviceのグローバル・バナーを変更するには、Identity Self Serviceのテキストをクリックし、手順5から7を繰り返します。

ヒント:

Oracle Identity Managerログイン・ページのバナーを変更するには、ログイン・ページをカスタマイズ・モードで開く必要があります。ただし、ログイン・ページに「カスタマイズ」リンクはありません。したがって、カスタマイズ・モードでログイン・ページを開くには、次の手順を実行します。

1. UIをカスタマイズする権限を持つ管理者として、Oracle Identity Self Serviceにログインします。

2. アクティブなサンドボックスで、「カスタマイズ」リンクをクリックします。Oracle Identity Self Serviceは、カスタマイズ・モードになりました。

3. 「ユーザー登録とその他の認証されていないページのカスタマイズ」に記載された手順を実行します。

10. 「保存」をクリックして、ロゴとグローバル・バナーの変更を保存します。

11. 「閉じる」をクリックして、WebCenter Composerを閉じます。

12. サンドボックスを公開します。

注意:

実行時UIカスタマイズによって、バナー・テキストが変更されます。ただし、それによってブラウザ・タイトル(たとえば、ブラウザ・ウィンドウに表示されるタイトル、HTML>HEAD>TITLEテキスト、またはタブを使用している場合はブラウザ・タブ・タイトル)を変更することはできません。ブラウザ・テキスト・タイトルを変更する場合は、次のように、リソース・バンドル・ファイルOIMUIBundle_*.propertiesの値を手動で編集し、再デプロイする必要があります。

oracle.iam.ui.view.war/WEB-INF/lib/adflibCommonUI.jar/oracle/iam/ui/OIMUIBundle_en.properties:

IDENTITY_SELF_SERVICE_TITLE=Identity Self Service

カスタム・リソース・バンドルの作成および使用方法の詳細は、「リソース文字列の国際化」を参照してください。

30.4 実行時のページのカスタマイズ

Oracle Identity Managerのカスタマイズを大きく分類すると、UIのカスタマイズ、またはユーザー、ロール、カタログおよびプロビジョニング・ターゲット・リソース・エンティティのオブジェクト定義の拡張に分けられます。

表30-2に、各エンティティのカスタマイズ可能なアーティファクトを示します。

表30-2 カスタマイズ可能なエンティティ・アーティファクト

エンティティ

アーティファクト

ユーザー

「作成」ページ

「変更」ページ

ユーザー属性の詳細

「拡張検索」インタフェース

本人情報

自己登録

ロール

「作成」ページ

「変更」ページ

「拡張検索」インタフェースとその内容:

- 問合せ基準

- 結果表の列

カタログ

カタログ検索ページとその内容:

- 結果表の列

- カタログ項目詳細

ターゲット・リソースのプロビジョニング

ターゲット・リソース作成フォームのプロビジョニング

ターゲット・リソース変更フォームのプロビジョニング

ターゲット・リソース・バルク・フォームのプロビジョニング

関連項目:

フォーム・デザイナを使用したフォームの作成および管理の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のフォームの管理およびカスタム属性の構成に関する説明を参照してください。

この項には次のトピックが含まれます:

- UIカスタマイズでの式言語の使用

- UIコンポーネントの条件付き表示または非表示

- リクエスト・プロファイルの条件付き表示

- ADFバリデータを使用した入力データの検証

- 必要に応じた入力属性のマーキング

Web Composerは、実行時にUIをカスタマイズ可能にします。この項では、次のUIのカスタマイズについて説明します。

- リンクまたはボタンの追加

- ADFコンポーネントの非表示および削除

- 属性の表示および非表示

- ユーザー登録とその他の認証されていないページのカスタマイズ

- 証明ページのカスタマイズ

30.4.1 UIカスタマイズでの式言語の使用

式言語(EL)は、JavaBeansコンポーネントに格納されているアプリケーション・データへのアクセスを許可します。ELおよびEL式構文の概要については、次のURLを参照してください。

http://developers.sun.com/docs/jscreator/help/2update1/jsp-jsfel/jsf_expression_language_intro.html

30.4.1.1 ユーザー・コンテキストで使用可能なEL式

OIMContext Beanは、プロジェクトのadfc-config.xmlのADFセッション・スコープBeanとして定義されます。表30-3に、Oracle Identity Managerユーザー・コンテキストで使用可能なEL式を示します。

表30-3 ユーザー・コンテキストのEL式

EL

説明

#{oimcontext.currentUser['ATTRIBUTE_NAME']}

ログイン中のユーザーのATTRIBUTE_NAME属性の値にアクセスします。ユーザー・エンティティに定義されたデフォルトの属性のリストについては、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の属性の定義に関する説明を参照してください。

#{oimcontext.currentUser['UDF_NAME']}

ログイン中のユーザーのUDF_NAME属性の値にアクセスします。UDF属性は、フォーム・デザイナを使用して定義できます。

#{oimcontext.currentUser.roles}

ログイン中のユーザーに割り当てられているロールを含むROLE_NAMEおよびRoleEntityマッピングにアクセスします。RoleEntityは、name、description、keyおよびdisplayNameプロパティがあるJava Beanです。

#{oimcontext.currentUser.roles['SYSTEM ADMINISTRATORS'] != null}

ログイン中のユーザーがシステム管理者の管理ロールを持つ場合にtrueと評価されるブールEL。同様に、その他のロールを持つかどうかを調べるようにELを変更することもできます。

#{oimcontext.currentUser.adminRoles['OrclOIMSystemAdministrator'] != null}

ログイン中のユーザーがOrclOIMSystemAdministrator管理ロールを持つ場合にtrueと評価されるブールEL。同様に、その他の管理ロールを持つかどうかを調べるようにELを変更することもできます。

次の例に示すように、EL式を使用して、oimcontext Beanからすべての使用可能なユーザー属性値を取得することができます。

- 現在ログイン中のユーザーのユーザー・キーを取得するには、次の手順を実行します。

#{oimcontext.currentUser.usr_key}

または

#{oimcontext.currentUser['usr_key']}

- 現在ログイン中のユーザーのロール名のリストを取得するには、次の手順を実行します。

#{oimcontext.currentUser.roles}

- 現在ログイン中のユーザーの管理ロール名のリストを取得するには、次の手順を実行します。

#{oimcontext.currentUser.adminRoles}

たとえば、ユーザーがOracle Identity Self Serviceにログインするときにユーザー・ログイン名を含むメッセージを表示する場合は、EL式を使用して現在ログイン中のユーザーのログイン名を取得し、それをページに表示できます。ユーザー・ログイン名を取得する式を次に示します。

#{oimcontext.currentUser['User Login']}

30.4.1.2 RequestFormContextで使用可能なEL式

RequestFormContextは、エンティティ・フォーム詳細タスク・フローのpageFlowScopeで使用可能なBeanです。エンティティ・フォームには、ユーザー・フォーム、アプリケーション・インスタンス・フォーム、ロール・フォームおよび権限フォームが含まれます。RequestFormContextは、様々なコンテキスト情報を提供します。このコンテキスト情報を使用すると、特定のビジネス要件に基づいてフォームをカスタマイズできます。

表30-4に、RequestFormContextに関わるEL式を示します。

表30-4 RequestFormContextに関わるEL式

EL

説明

#{pageFlowScope.requestFormContext}

RequestFormContextの現在のインスタンスにアクセスします。

#{pageFlowScope.requestFormContext.operation}

エンティティで実行されている操作タイプにアクセスします。可能な値はCREATEおよびMODIFYです。

#{pageFlowScope.requestFormContext.operation == 'MODIFY'}

エンティティで実行中の現在の操作がMODIFYである場合にtrueと評価されるブールEL。

#{pageFlowScope.requestFormContext.actionType}

エンティティ・フォームが表示されている場合に、ユーザーが実行中のアクションにアクセスします。可能な値は、APPROVAL、FULFILL、REQUEST、VIEWおよびSUMMARYです。

#{pageFlowScope.requestFormContext.actionType == 'REQUEST'}

エンティティ・フォームが表示される場合にユーザーが実行中のアクションがREQUESTの場合、たとえば、ロールまたはアプリケーション・インスタンスをリクエストする場合に、trueと評価されるブールEL。

#{pageFlowScope.requestFormContext.bulk}

実行中の操作がバルク操作である場合、たとえば、一度に複数のアプリケーション・インスタンスをリクエストする場合に、trueと評価されるブールEL。

#{pageFlowScope.requestFormContext.beneficiaryIds}

受益者またはターゲット・ユーザーIDのリストにアクセスします。たとえば、ユーザーJohn Doe用のアプリケーション・インスタンスをリクエストしている場合、リストにはJohn DoeのユーザーIDが含まれます。

注意: Javaコードを使用して、リストにアクセスし、それに対して操作を実行することをお薦めします。詳細は、該当する説明を参照してください。

#{pageFlowScope.requestFormContext.cartItemIds}

カート・アイテムIDのリストにアクセスします。たとえば、ユーザーのアプリケーション・インスタンスをリクエストしている場合、リストにはリクエスト中のアプリケーション・インスタンスIDが含まれます。

注意: Javaコードを使用して、リストにアクセスし、それに対して操作を実行することをお薦めします。詳細は、該当する説明を参照してください。

#{pageFlowScope.requestFormContext.requestEntityType}

リクエストされているエンティティ・タイプを取得します。可能な値は、ROLE、ENTITLEMENT、APP_INSTANCEおよびUSERです。

#{pageFlowScope.requestFormContext.requestEntityType == 'APP_INSTANCE'}

リクエストされているエンティティ・タイプがAPP_INSTANCEの場合にtrueと評価されるブールEL。

#{pageFlowScope.requestFormContext.requestEntitySubType}

リクエスト中のエンティティのサブタイプにアクセスします。たとえば、APP_INSTANCEをリクエスト中の場合、requestEntitySubTypeがアプリケーション・インスタンス・キーです。

#{pageFlowScope.requestFormContext.instanceKey}

変更中のインスタンスのキーにアクセスします。

30.4.1.3 リソース文字列の国際化

Oracle Identity Managerでは、カスタム・リソース・バンドルを作成し、それらをUIで参照できます。ラベル、ヘッダーなどの事前定義済UI要素または特定のページに表示される値(たとえば、「リクエスト・サマリー」ページの「ステータス」フィールドに表示される値)のいくつかを変更する場合は、この項で説明する手順を実行します。

カスタム・リソース・バンドルを作成するには、次の手順を実行します。

1. カスタム・プロジェクトWARファイル(oracle.iam.ui.custom-dev-starter-pack.war)を開きます。

2. WEB-INF/classes/oracle/iam/ui/custom/ディレクトリに新規CustomResourceBundle.propertiesファイルを作成します。

3. その新しいファイル内に、たとえば次のようにキーと値のペアを入力します。

CUSTOMRB_BANNER_TEXT=My Identity and Access

4. ローカライズ済ファイル(たとえば、CustomResourceBundle_it.propertiesおよびCustomResourceBundle_es.properties)はすべて同じディレクトリ内に作成します。

5. カスタムWARを再パッケージし、サーバー内のカスタムWARデプロイメントを更新します。

リソース・バンドルを使用するには、次の手順を実行します。

1. Oracle Identity Self Serviceで、サンドボックスを作成し、「カスタマイズ」をクリックします。

2. 「コンポーネント・プロパティ」ダイアログ・ボックスで、特定のプロパティに対して式エディタを開き、たとえば次のように式を指定します。

#{adfBundle['oracle.iam.ui.custom.CustomResourceBundle'].CUSTOMRB_BANNER_TEXT}

3. 式をテストするには、「テスト」をクリックします。「OK」をクリックし、「適用」をクリックします。

4. 「OK」をクリックして「コンポーネント・プロパティ」ダイアログ・ボックスを閉じます。

5. サンドボックスをエクスポートし、サンドボックスを公開します。

注意:

サンドボックスのエクスポートはオプションですが、推奨される手順です。

30.4.2 UIコンポーネントの条件付き表示または非表示

条件付きでUIコンポーネントを表示または非表示にするには、コンポーネントのrenderedプロパティを使用して、ブール値に評価されるEL式を割り当てます。EL式がtrueと評価された場合に、コンポーネントが表示されます。次に例を示します。

注意:

コンポーネントのrenderedプロパティは、Oracle Web Composerの「コンポーネントの表示」オプションに対応します。

- ログイン中のユーザーがシステム管理者の管理ロールを持つ場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser.roles['SYSTEM ADMINISTRATORS'] != null}

同様に、ログイン中のユーザーがその他のロールを持つかどうかを調べるように、EL式を変更することもできます。

- サインイン済のユーザーがシステム管理者の管理ロールを持つ場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser.adminRoles['OrclOIMSystemAdministrator'] != null}

同様に、ログイン中のユーザーがその他の管理ロールを持つかどうかを調べるように、EL式を変更することもできます。

- ログイン中のユーザーのusr_key属性が1の場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser['usr_key'] == 1}

- ログイン中のユーザーの姓がDoeの場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser['Last Name'] == 'Doe'}

- ログイン中のユーザーがXellerateユーザー組織に属している場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser['Organization Name'] == 'Xellerate Users'}

- ユーザーのUDF_NAMEというUDF属性がUDF_VALUEである場合にUIコンポーネントを表示するには、次の手順を実行します。

#{oimcontext.currentUser['UDF_NAME'] == 'UDF_VALUE'}

注意:

「コンポーネントの条件付き表示」では、カスタム・マネージドBeanを実装することで、特定の条件に基づいてコンポーネントを表示する方法について説明しています。

30.4.3 リクエスト・プロファイルの条件付き表示

条件付きでカタログ・リクエスト・プロファイルを表示するには、次の手順を実行します。

1. Oracle Identity Self Serviceにログインします。

2. サンドボックスをアクティブにします。

3. 「カタログ」ページに移動します。

4. 「カスタマイズ」をクリックします。「表示」リストから、「ソース」を選択します。

5. ソース・ツリーを使用して、「リクエスト・プロファイル」のイテレータ・コンポーネントに移動します。イテレータ・コンポーネントには、単一のリクエスト・プロファイルを表すpanelGroupLayoutサブコンポーネントがあります。

6. ブールEL式をrenderedプロパティに割り当てます。これは、Web Composerの「コンポーネントの表示」です。
たとえば、Suppliers組織のみのユーザーにProfileと呼ばれるリソース・プロファイルを表示し、他のユーザーには他のプロファイルを表示する場合は、次の式を使用します。

#{(row.profileName == 'Profile' && oimcontext.currentUser['Organization Name'] == 'Suppliers') || row.profileName != 'Profile'}

EL式は、使用可能なすべてのプロファイルに対して評価されます。同様に、他のプロファイルを条件付きで表示するように、EL式を変更/拡張することもできます。

30.4.4 ADFバリデータを使用した入力データの検証

事前定義されたADFバリデータを使用して入力コンポーネント・データを検証するには、JSFFページ・フラグメントを変更し、入力コンポーネントの子要素としてADFバリデータのいずれかを含める必要があります。表30-5に、ADFバリデータを示します。

表30-5 ADFバリデータ

バリデータ

説明

<af:validateByteLength>

エンコード時に文字列のバイト長を検証します。

<af:validateDateRestriction>

入力された日付が、指定された制限内かどうかを検証します。

<af:validateDateTimeRange>

入力された日付が、指定された範囲内かどうかを検証します。

<af:validateDoubleRange>

入力された日付が、指定された範囲内かどうかを検証します。

<af:validateLength>

入力された値が、指定された長さに収まっているかどうかを検証します。

<af:validateLongRange>

入力された値が、指定された範囲内かどうかを検証します。

<af:validateRegExp>

Javaの正規表現構文を使用して式を検証します。

たとえば、「ユーザー・ログイン」属性に許可された文字が英数字ASCII文字のみであることを検証するために、「ユーザー・ログイン」入力コンポーネントの子要素として次のRegExpバリデータを含めることができます。

<af:validateRegExp pattern="[a-zA-Z0-9]*"/>

ADFバリデータは、Web Composerを使用して直接追加することはできません。かわりに、別のコンポーネント(たとえば、別の入力テキスト)を、「ユーザー・ログイン」コンポーネントの子コンポーネントとして追加することができます。その後、この変更を含むサンドボックスをエクスポートできます。最後に、エクスポートされたサンドボックス内のフォームのJSFFページ・フラグメントを更新し、そのサンドボックスをインポートします。

注意:

「カスタム・フィールド検証の実装」では、カスタム・マネージドBeanを使用してカスタム・フィールド・バリデータを実装する方法について説明しています。

30.4.5 必要に応じた入力属性のマーキング

条件付きで入力フィールドを必須にするには、コンポーネントのrequiredプロパティを使用して、それにブールEL式を割り当てることができます。EL式がtrueと評価された場合に、コンポーネントは必須とマークされ、必要な検証がトリガーされます。

EL式の例については、「UIコンポーネントの条件付き表示または非表示」を参照してください。

フィールドを別のフィールドの値に基づいて条件付きで必須にする方法の詳細は、「条件付き必須フィールドの設定」を参照してください。

30.4.6 リンクまたはボタンの追加

Oracle Identity Self Serviceにリンクを追加するには、次の手順を実行します。

1. Oracle Identity Self Serviceの任意のページから、WebCenter Composerを開きます。

2. リンクを含める上部パネルを選択します。そのADFコンポーネントがオブジェクト・ツリーで選択されます。
図30-6は、選択された上部パネルと、オブジェクト・ツリーでの対応するADFコンポーネントを示しています。

図30-6 リンクを追加するパネルの選択

3. 「コンテンツの追加」をクリックします。図30-7に示すように、「コンテンツの追加」ダイアログ・ボックスが表示されます。

図30-7 「コンテンツの追加」ダイアログ・ボックス

4. 追加するリンク・コンポーネントを検索し、同じ行で「追加」をクリックします。リンクが、選択したパネルに追加されます。

5. 「保存」をクリックして変更を保存し、WebCenter Composerを閉じます。

注意:

詳細は、次の項を参照してください。

- 「タスク・フローの起動」

- 「外部リンクの作成」

Oracle Identity Managerでは、goLink、commandLink、commandButtonなどの独自のUIまたはタスクフローを追加したり、タスクフローを起動したりできます。

カスタムUIまたはタスクフローを追加するには、次の手順を実行します。

1. マネージドBeanを作成し、oracle.iam.ui.custom-dev-starter-pack.warのadfc-config.xmlを使用して登録します。

2. Web Composerを使用して、リンクまたはボタンを表示するページに、新しいcommandLinkまたはcommandButtonを追加します。

3. actionListenerメソッドを指すように、追加したリンクまたはボタン・コンポーネントのactionListenerプロパティを設定します。

4. マネージドBeanを使用してコンテキスト・イベントを発生させます。これは、Oracle Identity Managerによって処理されます。

シェルによって、タスクフローが起動されます。

30.4.7 ADFコンポーネントの非表示および削除

ADFコンポーネントを非表示にすると、そのUIアーティファクトはユーザーから非表示になります。ADFコンポーネントを非表示にするには、次の手順を実行します。

1. Oracle Identity Self Serviceで、コンポーネントを非表示にするページに移動します。

2. 「カスタマイズ」をクリックして、WebCenter Composerを開きます。

3. 「表示」メニューから、「ソース」を選択します。オブジェクト・ツリーが表示されます。

4. 非表示にするページ上のコンポーネントをクリックします。オブジェクト・ツリーで対応するADFコンポーネントが選択されます。

5. オブジェクト・ツリーで選択されたADFコンポーネントを右クリックし、「非表示」を選択します。

ADFコンポーネントを削除するには、次の手順を実行します。

1. UIコンポーネントを削除するOracle Identity Self Serviceページから、Web Composerを開きます。

2. 「表示」メニューから、「ソース」を選択します。オブジェクト・ツリーが表示されます。

3. 削除するページ上のコンポーネントをクリックします。オブジェクト・ツリーで対応するADFコンポーネントが選択されます。

4. オブジェクト・ツリーで選択されたADFコンポーネントを右クリックし、「削除」を選択します。

30.4.8 属性の表示および非表示

ページの属性を表示または非表示にするには、次の手順を実行します。

1. 属性を表示または非表示にするページに移動します。たとえば、「電話」フィールドを表示または非表示にする場合、Oracle Identity Self Serviceで「本人情報」ページに移動します。

2. 「カスタマイズ」をクリックして、Web Composerを開きます。

3. 「表示」メニューから、「ソース」を選択します。オブジェクト・ツリーが表示されます。

4. 非表示または表示する属性を含むリージョンまたはセクションをクリックします。
「タスク・フローの編集を確認」メッセージ・ボックスが表示されます。

5. 「編集」をクリックします。選択したリージョンのADFコンポーネントが、オブジェクト・ツリーで選択されます。

6. ツールバーで、「編集」をクリックします。「コンポーネント・プロパティ」ダイアログ・ボックスが表示されます。

7. 「子コンポーネント」タブをクリックします。選択されたリージョンのすべてのUIコンポーネントが表示されます。図30-8は、「コンポーネント・プロパティ」ダイアログ・ボックスのサンプル「子コンポーネント」タブを示しています。

図30-8 「子コンポーネント」タブ

8. 表示または非表示にする属性に対応するチェック・ボックスをそれぞれ選択するか、選択を解除します。

注意:

このリストに属性が見つからない場合は、フォームに属性を追加する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のカスタム属性の追加に関する項を参照してください。

9. 「適用」をクリックします。選択した属性は、選択内容に基づいて非表示または表示されます。

10. 「OK」をクリックし、ツールバーの「保存」をクリックします。

30.4.9 ユーザー登録とその他の認証されていないページのカスタマイズ

Identity Self Serviceのユーザー登録とその他の認証されていないページをカスタマイズする手順は次のとおりです。

1. システム管理者としてOracle Identity Self Serviceにログインします。

2. サンドボックスを作成して、アクティブ化し、「カスタマイズ」をクリックします。

3. 「表示」→「ソース」を選択します。左側のナビゲーション・ペインで、最後に表示されたリンク(たとえば、「オープン・タスク」)をクリックします。

注意:

タブは開かないでください。左側のナビゲーション・ペイン自体をカスタマイズする必要があります。

4. タスク・フローを編集するために確認します。ソース・ツリー・ペインを使用し、下方向にスクロールして、グレーアウトされた項目「認証されていないページ」を検索します。

5. 承認されていないページを右クリックして、コンポーネントの表示を選択します。図30-9に示すように、承認されていないページへ移動するリンクが左側のナビゲーション・ペインに表示されます。

図30-9 承認されていないページへのリンク

6. 「表示」→「設計」に選択します。左側のナビゲーション・ペインで、「新規ユーザーの登録」リンクをクリックします。「新規ユーザーの登録」画面へリダイレクトされます。

7. 必須フィールドに情報を入力したら、「表示」→「ソース」を選択します。コンテンツの追加をクリックし、データ・コンポーネント→「ユーザー登録」→UserVO1を使用して、新規フィールドを追加します。

8. 「取消」をクリックして、ホームページに戻ります。終了後、忘れずに左側のナビゲーション・ペインで承認されていないリンクを非表示にします。その後、承認されていないページをクリックし、コンポーネントの非表示を選択します。

30.4.10 証明ページのカスタマイズ

受信ボックスの証明表で選択した行からの情報は、表の下部にある詳細ペインのカスタマイズに使用できます。この項の手順を使用して、ユーザー証明詳細ペインをカスタマイズできます。どの証明タイプでも、同様の手順が実行されます。

カスタマイズ・モードで、次の手順を実行します。

1. ユーザーの詳細情報を含むpanelFormLayoutを編集します。

2. 「コンテンツの追加」をクリックします。

3. データ・コンポーネント→「証明」を選択します。

4. 「UserCertificationUserVO1」を選択します。

5. 追加する属性(たとえば、「タイトル」)を検索して、「追加」をクリックします。

6. 「ラベル・コンポーネント付きのADF読取り専用入力テキスト」を選択します。
入力コンポーネントがページに追加されますが、その値は表示されません。属性の名前を示すラベルが追加されます。

7. ページ・ソース・パネルでinputTextコンポーネントを選択して、「編集」をクリックします。「コンポーネント・プロパティ」ダイアログ・ボックスが表示されます。

8. 下方向にスクロールし、Value属性を検索して、「式ビルダー」を開きます。

9. 式の値を編集して、次のように設定します。

#{pageFlowScope.p1_row_idcTitle}

10. 変更内容を保存し、Web Composerを閉じます。表内の行を選択します。
表から行を選択すると、その情報がpageFlowScopeに格納されます。この情報を詳細ペインに表示するには、手順1から10に従い、正確なデータを抽出する必要があります。ELの形式は次のとおりです。

#{pageFlowScope.p1_row_ATTRIBUTE_NAME}

30.5 UIコンポーネントの保護

この項には次のトピックが含まれます:

- APMを使用したカスタム・タスクフローの保護

- EL式を使用したタスク・フロー・リージョンの保護

30.5.1 APMを使用したカスタム・タスクフローの保護

タスクフローを保護するために、認可ポリシー・マネージャ(APM) UIを使用して、カスタム・タスクフローに権限を追加できます。これを行うには、次の手順を実行します。

1. 次のURLに移動して、認可ポリシー・マネージャにWebLogicユーザーとしてログインします。
http://ADMIN_HOST:ADMIN_PORT/apm

2. 「アプリケーション」→「OracleIdentityManager」→「リソース・タイプ」に移動します。「開く」をクリックします。

3. 「新規作成」をクリックして、新しいリソース・タイプを作成します。次の詳細を入力して、「保存」をクリックします。
表示名: このリソースの表示名(たとえば、ADFタスクフロー)

名前: このリソースの名前(たとえば、ADFTaskflows)

アクション: パーソナライズ、カスタマイズ、付与、表示。各アクションを追加するには、「新規」をクリックします。

リソース階層のサポート: いいえ

リソース・デリミタ: スラッシュ(/)

評価ロジック: 権限クラス

権限クラス: oracle.adf.controller.security.TaskFlowPermission

アクション名デリミタ: カンマ(,)

4. 「アプリケーション」→「OracleIdentityManager」→デフォルト・ポリシー・ドメイン→リソース・カタログ→「リソース」に移動します。「開く」をクリックします。

5. 「新規」をクリックして、新規リソースを作成します。次の値を入力して、「保存」をクリックします。
リソース・タイプ: 手順3で作成したリソース・タイプを選択します。

表示名: カスタム・タスクフローの表示名を入力します。

名前: カスタム・タスクフローの名前を次の形式で入力します。

TASKFLOW_DOCUMENT#TASKFLOW_ID

例:

/WEB-INF/request-approval-details-tf.xml#request-approval-details-tf

説明: カスタム・タスクフローの説明を入力します。

注意:

手順5で説明したように、カスタム・タスクフローには、それぞれリソースを作成する必要があります。すべてのカスタム・タスクフローに対して、手順3で作成したリソース・タイプと同じものを使用できます。

6. 「アプリケーション」→「Oracle Identity Manager」→デフォルト・ポリシー・ドメイン→「認可ポリシー」に移動します。「開く」をクリックします。

7. カスタム・タスクフローのポリシーを追加する場所(たとえば、OIMシステム管理のポリシー)を選択します。「開く」をクリックします。

8. 「ターゲットの追加」をクリックします。ターゲットの検索ダイアログ・ボックスが表示されます。

9. 「リソース」タブをクリックします。手順3で定義したリソース・タイプを指定して、「検索」をクリックします。

10. 手順5で作成したリソースを選択します。「選択した項目の追加」をクリックします。

11. 「ターゲットの追加」をクリックします。リソースが「ターゲット」表に追加されます。

12. 表に追加したリソースを展開します。タスクフローに適用する権限を選択します。

13. 「適用」をクリックします。

30.5.2 EL式を使用したタスク・フロー・リージョンの保護

次の例に示すように、新しいタスク・フローそれぞれに対するエントリがjazn-data.xmlファイルにあります。

<permission>
<class>oracle.adf.controller.security.TaskFlowPermission</class>
<name>/WEB-INF/oracle/iam/ui/catalog/tfs/request-summary-details-tf.xml#request-summary-details-tf</name>
<actions>view</actions>
</permission>

これは、任意のタスク・フローがIdentity Self Service UIで表示されるために必要な基本的な権限レベルです。管理ロールに依存する高度な権限の場合は、機能セキュリティの強制にEL式を使用できます。

タスク・フローを保護するには、タスク・フローを親JSFFファイル内のリージョンとして使用する必要があります。リージョンに対してEL式を定義すると、ログイン中のユーザーに対するタスク・フローの表示または非表示を、ユーザーの権限に基づいて実施できるようになります。

リージョンを保護する場合は、次の例を検討してください。

my-access-accounts.jsffページで、details-information-tfタスク・フローは、次のEL式を使用してユーザーに対して選択的にレンダリングされます。

rendered="# {oimappinstanceAuth.view [bindings.appInstanceKey].allowed}"

説明:

- oimappinstanceAuthは、adfc-config.xmlファイルでの、ApplicationInstanceAuthz.java認可Beanのマップ名です。

- viewは、チェックする必要があるUIPermissionの名前です。oimappinstanceAuth参照用の実際のBeanファイルであるApplicationInstanceAuthz.javaでは、次の権限が定義されています。

Private UIPermission view = new UIPermission (PolicyConstants.Resources.APPLICATION_INSTANCE.getId(), PolicyConstants.ApplicationInstanceActions.VIEW_SEARCH.getId());

- appInstanceKeyは、ユーザーが表示しようとしているアプリケーション・インスタンスのIDで、これはパラメータとして渡されます。

30.6 Oracle Identity Managerヘルプのカスタマイズ

Oracle Identity Managerは、Oracle Identity Self ServiceとOracle Identity System Administrationで次のオンライン・ヘルプ・システムを開発して使用できます。

- カスタム・ヘルプ・トピックの追加

- インライン・ヘルプの追加

30.6.1 カスタム・ヘルプ・トピックの追加

Oracle Identity Managerヘルプ・トピックに加えて、カスタム・ヘルプ・トピックを作成して使用することもできます。

カスタム・ヘルプ・トピックを表示するには、次の手順を実行します。

1. Oracle Identity Self Serviceにログインします。

2. 上部のナビゲーション・バーで、「ヘルプ」をクリックします。Oracle Help for the Webウィンドウが表示されます。

3. ブック・リストから、Oracle Identity Managerのカスタム・ヘルプ・トピックを選択します。

4. 目次を開いて、ヘルプ・トピックを表示します。

カスタム・ヘルプ・ブックは、別のJARファイルとして提供されます。これは、OIM_HOME/help/CUSTOMOHW.jarファイルです。独自のヘルプ・トピックおよびカスタム・ヘルプ・ブックJARを作成し、UIでこのカスタム・ヘルプ・トピックが表示されるようにCUSTOMOHW.jarファイルを置き換えます。

Oracle Help for the Web (OHW)を使用して、カスタム・ヘルプ・トピックを作成します。カスタムOHWヘルプ・トピックの作成方法の詳細は、Oracle Fusion Middleware Oracle Help開発者ガイドを参照してください。

新しいカスタム・ヘルプ・ブックを作成した後に、OIM_HOME/help/ディレクトリの次の構成ファイルを変更して、新しいヘルプ・ブックが参照されるようにします。

- ohwconfig_identity.xml: Oracle Identity Self Serviceのカスタム・ヘルプ・トピックの構成ファイル

- ohwconfig_sysadmin.xml: Oracle Identity System Administrationのカスタム・ヘルプ・トピックの構成ファイル

注意:

Oracle Identity Managerをアップグレードするとこの構成ファイルが上書きされるため、カスタム・ヘルプ・ブックを参照するには再び構成ファイルを変更する必要があります。

カスタム・ヘルプ・トピックを作成した後に、カスタム・ヘルプJARファイルを作成し、CUSTOMOHW.jarファイルを新しいJARファイルと置き換えます。これで、このUIページに関するカスタム・ヘルプ・トピックを追加できます。次の手順は、Oracle Identity Self Serviceでカスタム・ヘルプ・トピックをホーム・ページのGetting Started with Helpコンテナに追加する方法を示しています。

1. Oracle Identity Self Serviceのホーム・ページで、「カスタマイズ」をクリックします。

2. 「スタート・ガイドのヘルプ・トピック」コンテナをクリックします。

3. 「表示」メニューから、「ソース」を選択します。オブジェクト・ツリーが表示されます。

4. 「コンテンツの追加」をクリックします。「コンテンツの追加」ダイアログ・ボックスが表示されます。

5. コマンド・イメージ・リンクを選択し、同じ行の「追加」をクリックします。選択したコンポーネントは、「スタート・ガイドのヘルプ・トピック」セクションに追加されます。

6. 「編集」をクリックします。「コンポーネント・プロパティ」ダイアログ・ボックスが表示されます。

7. 「表示オプション」タブをクリックします。

8. 「テキスト」フィールドに、ページに表示されるヘルプ・トピックのテキストを入力します。

9. 「イメージ」フィールドに、ヘルプ・アイコン・イメージのパスおよびファイル名を入力します。

10. アクション・リスナー・フィールドに、カスタム・ヘルプ・トピックのHelpTopicIDを含むURLを入力します。

11. 「適用」をクリックした後、「OK」をクリックします。

12. 保存し、カスタマイズ・モードを閉じます。ヘルプ・トピックは、ホーム・ページのGetting Started with Helpコンテナに追加されます。ヘルプ・トピックをクリックすると、カスタム・ヘルプ・ブックJARファイルのヘルプ・トピックが表示されます。

30.6.2 インライン・ヘルプの追加

Oracle Identity Managerは、デフォルトではインライン・ヘルプを提供しません。ただし、フィールドおよびボタンのツールチップ・テキストの追加など、様々なUIコンポーネントに対してインライン・ヘルプを追加できます。

インライン・ヘルプのコンテンツは、カスタムWARライブラリ(oracle.iam.ui.custom-dev-starter-pack.war)のファイルから取得されます(/oracle/iam/ui/custom/help/CustomHelpResourceBundle.propertiesファイルなど)。

カスタムWARライブラリ名を変更できます。その場合は、Manifest.MFのWARファイルのそのエントリで、同じライブラリ名を指定してください。

CustomHelpResourceBundle.propertiesファイルのエントリを使用して、インライン・ヘルプ・コンテンツを指定できます。エントリには、CUSTOMRB接頭辞が付き、次の接尾辞のいずれか1つが付きます。

- _DEFINITION: これは、インライン・ヘルプをフィールドまたはUIコンポーネントに対して指定します。例:
CUSTOMRB_EMAIL_DEFINITION=使用可能な場合は、公式な電子メールIDを入力してください。

EMAILはフィールド名で、このエントリの値はマウス・ポインタをこのフィールド上に置いたときに表示されるインライン・ヘルプ・テキストです。

- _INSTRUCTIONS: これはページ・レイアウトに対するインライン・ヘルプを指定します。例:
CUSTOMRB_MY_INFO_INSTRUCTIONS=プロファイルの更新は承認後に反映されます。

MY_INFOはページであり、このエントリの値はページ上部に表示されるインライン・ヘルプ・テキストです。

たとえば、次の手順はOracle Identity Self Serviceの「本人情報」ページの「電話」フィールドに対してインライン・ヘルプを追加する方法を示しています。

1. Oracle Identity Self Serviceで、「本人情報」ページに移動し、「基本ユーザー情報」セクションを展開します。

2. 「カスタマイズ」をクリックします。

3. 「表示」メニューから、「ソース」を選択します。オブジェクト・ツリーが表示されます。

4. 「電話」フィールドをクリックします。

5. 「編集」をクリックします。「電話」フィールドの「コンポーネント・プロパティ」ダイアログ・ボックスが表示されます。

6. ヘルプ・トピックIDフィールドに、CUSTOMRB_TELEPHONEなど、「電話」フィールドと関連付けるインライン・ヘルプのヘルプ・トピックIDを入力します。
_DEFINITION接尾辞の指定は、必須ではありません。

7. 「適用」をクリックした後、「OK」をクリックします。

8. 保存し、カスタマイズ・モードを閉じます。マウス・ポインタを「電話」フィールドに置くと、インライン・ヘルプ・テキストが表示されます。

関連項目:

ヒントおよびメッセージの定義、ADFコンポーネントのヘルプ情報の提供の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のヒント、メッセージおよびヘルプの表示に関する説明を参照してください。

30.7 ホーム・ページのカスタマイズ

ホーム・ページでは、Oracle Identity Self Serviceの様々な機能が一目でわかります。このホーム・ページは、コンテナを追加、削除および再編成してパーソナライズすることができます。詳細は、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のホーム・ページのパーソナライズに関する説明を参照してください。

コンテナを追加した場合、それを使用するにはこのコンテナにUIコンポーネントを追加する必要があります。ホーム・ページにコンテナを追加し、UIコンポーネントを追加するには、次の手順を実行します。

注意:

コンテナの追加および削除、レイアウトの変更などのパーソナライズ機能は、認可ポリシーでは制御されません。ただし、追加の際に各ユーザーが使用できるコンテンツは、認可ポリシーによって制御されます。

1. Oracle Identity Self Serviceにログインし、ホーム・ページに移動します。

2. 「パーソナライズ」をクリックします。ホームは、アイコンで構成されるツールバーがあるカスタマイズ・モードで表示されます。

3. ツールバーで「上にボックスを追加」アイコンをクリックします。図30-10は、ツールバーの「上にボックスを追加」アイコンを示しています。

図30-10 ツールバーの「上にボックスを追加」アイコン

コンテナの下、右または左にボックスを追加するには、そのコンテナ内の対応するアイコンをクリックします。

アイコンをクリックすると、図30-11に示すように、ホーム・ページにコンテナが追加されます。

図30-11 新しいコンテナ

4. 「コンテンツの追加」をクリックします。「コンテンツの追加」ダイアログ・ボックスが表示され、コンテナに追加できるホームページ・タスク・フローのリストが表示されます。図30-12は、「コンテンツの追加」ダイアログ・ボックスを示しています。

図30-12 「コンテンツの追加」ダイアログ・ボックス

5. ホームページ・タスク・フローを選択し、「追加」をクリックします。その後、「コンテンツの追加」ダイアログ・ボックスを閉じます。

6. 上部のナビゲーション・バーの「閉じる」をクリックして、カスタマイズ・モードを終了します。

30.8 チャレンジ質問のカスタマイズ

チャレンジ質問の数をUIの複数のページでカスタマイズできます。そうするには、PCQ.NO_OF_QUESシステム・プロパティの値を変更して、ユーザーに表示するチャレンジ疑問の数を指定します。また、追加または削除したチャレンジ質問を表示または非表示にする場合にも、ページをそれぞれカスタマイズします。

チャレンジ質問の数を設定するには、次の手順を実行します。

1. Oracle Identity System Administrationにログインします。

2. 左側のペインの「システム管理」の下で、「システム構成」をクリックします。「システム構成」タブが新しいウィンドウで表示されます。

3. PCQ.NO_OF_QUESキーワードを持つ「質問数」システム・プロパティを検索して開きます。

4. 値を3から5に変更し、「保存」をクリックします。

5. 新しいウィンドウを閉じます。

6. Oracle Identity System Administrationの「構成」の下で、「参照」をクリックし、Lookup.WebClient.Questionsコードを検索します。

図30-13 Lookup.Weblciient.Questions参照コード

7. 参照タイプを編集して、追加の質問を追加します。

注意:

en_USバンドルの質問のローカライズについては、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』でチャレンジ質問およびレスポンスのローカライズに関する説明を参照してください。

Oracle Identity Self ServiceまたはOracle Identity System Administrationにログインしているユーザーに関するチャレンジ質問を設定するには、次の手順を実行します。

1. Oracle Identity Self Serviceにシステム管理者としてログインし、ホーム・ページで「サンドボックス」をクリックします。

2. ホーム・ページで上部ナビゲーション・バーの「サンドボックス」をクリックします。「サンドボックスの管理」ページが表示されます。

3. ツールバーで、「サンドボックスの作成」をクリックします。「サンドボックスの作成」ダイアログ・ボックスに、サンドボックス名(ChallengeQなど)を入力し、「保存して閉じる」をクリックします。
「サンドボックスのアクティブ化」チェック・ボックスは選択したままにします。

4. 確認ダイアログ・ボックスで、「OK」をクリックします。アクティブなサンドボックスが「サンドボックスの管理」ページの表に表示されます。「サンドボックスの管理」ページを閉じます。

5. 「本人情報」ページを開きます。「基本情報」セクションを閉じ、「チャレンジ質問」セクションを展開します。

6. 「カスタマイズ」をクリックします。ツールバーで、「表示」、「ソース」を選択します。

7. 3つ目の質問をクリックし、「OK」をクリックしてタスク・フローの編集を確認します。

8. ソース・ツリーで、3つ目の質問の直後のグレー表示されたpanelGroupLayoutを選択します。これには、4つ目の質問が含まれます。このpanelGroupLayoutを右クリックし、「コンポーネントの表示」を選択します。

9. 同様に、5つ目の質問を表示します。

10. ツールバーで、「閉じる」をクリックします。

11. 次のURLにブラウザを移動するとチャレンジ質問が表示される、その他の3つのページに対して、手順4から9を繰り返します。

- 「ユーザー登録」ページ: /identity/faces/register

- 「パスワードを忘れた場合」ページ: /identity/faces/forgotpassword

- ユーザーの初回ログイン時の「ログイン」ページ: /identity/faces/firstlogin?action=setchallenges

設計上、様々なバリエーションがある点に注意してください(たとえば、図30-14に示すように、「パスワードを忘れた場合」ページに関する質問は、リストではなくoutputTextとしてレンダリングされます)。

図30-14 「パスワードを忘れた場合」ページに関するチャレンジ質問

12. サンドボックスを公開し、ログアウトします。

30.9 暫定UIのカスタマイズ

Identity Self Serviceの暫定UIページでは、アクセス・ポリシーの管理などのタスクを実行するメニュー項目をクリックすると、検索ページが表示されます。たとえば、「アクセス・ポリシー」メニュー項目の下で「管理」リンクをクリックすると、アクセス・ポリシーを検索するための2つのドロップダウン・メニューを含む「アクセス・ポリシーの管理」ページが表示されます。ドロップダウン・メニューの数およびドロップダウン・メニュー項目をカスタマイズできます。

検索結果が表示されたら、各ページに表示される結果表の最大行数を決定できます。ユーザーが結果表から項目を選択すると、詳細ページ(「リソースの詳細」ページなど)が表示されます。詳細ページには、追加の詳細メニューが含まれています。これらのメニュー項目をカスタマイズできます。

この項には次のトピックが含まれます:

- 検索ドロップダウン項目のカスタマイズ

- 検索ドロップダウン項目数および検索結果数のカスタマイズ

30.9.1 検索ドロップダウン項目のカスタマイズ

Design Consoleを使用して、検索ページの検索コードおよび追加詳細を変更します。ドロップダウンをカスタマイズするには、次の手順を実行します。

1. Design Consoleにログインします。

2. 「管理」→「参照定義」に移動して、「参照定義」フォームを開きます。

3. 必要な検索定義を検索して特定します。

ヒント:

検索基準について、lookup.webclient*検索を使用して検索ページを見つけるか、または*additional_detailsを使用して追加詳細を見つけます。

4. 検索コードに対して必要な変更を行い、各検索ページのドロップダウン・メニューに表示されるオプションを設定します。

- コード・キーは各列のメタデータです。

- デコード値は、Identity Self ServiceまたはIdentity System Administrationで表示されるものです。

- コード・キー・リストに表示される項目の順序は、Identity Self Serviceのドロップダウン・リストに表示される順序です。エントリを削除し、再度追加すると、そのエントリはリストの最後に表示されます。

5. 変更を保存します。

30.9.2 検索ドロップダウン項目数および検索結果数のカスタマイズ

ドロップダウン・メニューの数および各ページの検索結果の最大数を変更するには、xlDefaultAdmin.propertiesファイルを編集します。

ドロップダウン・メニューの数を設定するには、次の手順を実行します。

1. xlDefaultAdmin.propertiesファイルを開きます。

2. 表30-6でプロパティを特定し、必要に応じてそれを編集します。

表30-6 検索ページのメニュー数を決定するプロパティ

プロパティ名

デフォルト

ページ

global.property.numsearchaccesspolicyfields

2

アクセス・ポリシー

global.property.numsearchresourcefields

2

リソース検索

global.property.numsearchattestationprocessfields

3

アテステーション・プロセス

3. 各ページの検索結果の最大数を変更するには、プロパティglobal.displayrecordNum.valueの値を必要な値に変更します。デフォルト値は10です。

4. ファイルを保存します。

5. Oracle Identity Managerを再起動します。

30.10 マネージドBeanおよびタスク・フローの開発

Oracle Identity Managerに高度なカスタマイズを実装するには、JDeveloper IDEを使用して新しいタスク・フローおよびマネージドBeanを開発し、カスタムWARファイルにパッケージ化します。

関連項目:

図30-1、「Oracle Identity Manager UIライブラリ」は、様々なOracle Identity Manager UIライブラリと、その従属構造を示しています。

次のタイプのBeanがあります。

- リクエストBean: Beanの新しいインスタンスをrequest.jsffコンポーネント・バインディングごとに作成し、通常はリスナーをリクエストBeanにバインドします。

- 状態Bean: アプリケーション、ユーザー・セッションまたは特定のフローの状態を保持するBean。コンポーネントの値(af: inputTextなど)は、状態Beanにバインドできます。ADFがリクエスト間でこれらのBeanをシリアライズ/シリアライズ解除するため、状態Beanはシリアライズ可能(java.io.Serializableを実装)である必要があります。

この項では、マネージドBeanの開発方法について、次の各項で説明します。

- ViewControllerプロジェクトの設定

- モデル・プロジェクトの設定

- カスタム・マネージドBeanの追加

- Oracle Identity Managerへのカスタム・コードのデプロイ

- マネージドBeanの使用

- リクエスト属性を移入するためのマネージドBeansの使用

30.10.1 ViewControllerプロジェクトの設定

マネージドBeanは、ViewControllerプロジェクトで作成します。すべてのカスタム・タスク・フロー、ページおよびマネージドBeanが、ViewControllerプロジェクトに存在する必要があります。

ViewControllerプロジェクトを設定するには、次の手順を実行します。

1. 新しいJDeveloperアプリケーションを作成します。これを行うには、次の手順を実行します。

1. JDeveloperを起動します。

2. 「ファイル」、「新規」を選択します。

3. 「汎用アプリケーション」を選択し、「OK」をクリックします。

4. アプリケーション名およびディレクトリを指定し、「終了」をクリックします。アプリケーションは、サンプル・プロジェクトを使用して作成されます。

5. サンプル・プロジェクトを削除するには、プロジェクトを右クリックして「削除」を選択します。

2. ViewControllerプロジェクトを設定します。これを行うには、次の手順を実行します。

1. 「ファイル」、「新規」を選択します。

2. 「ADF ViewControllerプロジェクト」を見つけて選択し、「OK」をクリックします。

3. プロジェクト名(CustomUIなど)およびプロジェクト・ディレクトリを指定し、「次へ」をクリックします。

4. デフォルトのパッケージ名をoracle.iam.ui.customとして入力し、「終了」をクリックします。新しいプロジェクトが作成されます。

3. Oracle Identity Managerライブラリをプロジェクト・クラスパスに追加します。これを行うには、次の手順を実行します。

1. 新しいプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

2. 左側のナビゲーション・バーで、「ライブラリとクラスパス」を選択します。

3. 「ライブラリの追加」をクリックします。

4. 「ディレクトリ」をクリックし、パスをIDM_HOME/server/jdev.libとして指定し、「OK」をクリックします。

5. ライブラリのリストから、次を選択します。

- OIMビュー共有ライブラリ

- OIMモデル共有ライブラリ

- OIMクライアント・ライブラリ

6. 「OK」をクリックします。

4. 新しく作成されたViewControllerプロジェクトのデプロイメント・プロファイルを定義します。これを行うには、次の手順を実行します。

1. プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 左側のナビゲーション・バーで、「デプロイメント」を選択します。

3. 既存のデプロイメント・プロファイルを削除します。

4. 「新規」をクリックし、アーカイブ・タイプとして「ADFライブラリのJARファイル」を選択します。

注意:

ADFライブラリのJARファイルとJARファイル・アーカイブ・タイプは異なります。必ず、「ADFライブラリのJARファイル」アーカイブ・タイプを選択してください。

5. adflibCustomUIなど、アーカイブ名を指定して確認し、「OK」をクリックします。

ViewControllerプロジェクトの設定は完了です。これで、カスタム・タスク・フロー、ページおよびマネージドBeanの追加を開始できます。

30.10.2 モデル・プロジェクトの設定

Oracle Identity Manager APIと直接対話するすべてのカスタムEO/VOおよびクラスが、モデル・プロジェクト内に存在する必要があります。モデル・プロジェクトを設定するには、次の手順を実行します。

1. 「ファイル」、「新規」をクリックします。

2. 「ADFモデル・プロジェクト」を見つけて選択し、「OK」をクリックします。

3. 「プロジェクト名」(CustomModelなど)および「プロジェクト・ディレクトリ」を指定し、「次へ」をクリックします。

4. デフォルトのパッケージ名をoracle.iam.ui.customとして入力し、「終了」をクリックします。新しいプロジェクトが作成されます。

5. Oracle Identity Managerライブラリをプロジェクト・クラスパスに追加します。

1. プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 左側のナビゲーション・バーで、「ライブラリとクラスパス」を選択します。

3. 「ライブラリの追加」をクリックします。

4. 「ディレクトリ」をクリックし、パスをIDM_HOME/server/jdev.libとして指定し、「OK」をクリックします。

5. ライブラリのリストから、次を選択します。

- OIMモデル共有ライブラリ

- OIMクライアント・ライブラリ

6. 「OK」をクリックします。

6. 新しく作成されたモデル・プロジェクトのデプロイメント・プロファイルを定義します。これを行うには、次の手順を実行します。

1. プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 左側のナビゲーション・バーで、「デプロイメント」を選択します。

3. 既存のデプロイメント・プロファイルを削除します。

4. 「新規」をクリックし、アーカイブ・タイプとして「ADFライブラリのJARファイル」を選択します。

注意:

ADFライブラリのJARファイルとJARファイル・アーカイブ・タイプは異なります。必ず、「ADFライブラリのJARファイル」アーカイブ・タイプを選択してください。

5. adflibCustomModelなど、アーカイブ名を指定して確認し、「OK」をクリックします。

モデル・プロジェクトの設定は完了です。これで、Oracle Identity Manager APIと対話するためのカスタムEO、VOおよびクラスの追加を開始できます。

30.10.3 カスタム・マネージドBeanの追加

カスタム・マネージドBeanを追加するには、次の手順を実行します。

1. ViewControllerプロジェクトを右クリックし、「新規」を選択します。

2. Javaクラス・カテゴリを選択します。

3. クラス名(CustomReqBean、CustomStateBeanなど)、およびパッケージ名を指定します。

4. クラスの作成後に、タスク・フローに登録するには、次の手順を実行します。

1. 独自のバインド・タスク・フローを開発する場合は、タスク・フロー定義ファイルに移動し、それを開きます。それ以外の場合は、ViewControllerプロジェクトのadfc-config.xmlファイルを見つけ、それを開きます。

2. 「概要」タブをクリックし、次に「マネージドBean」を選択します。

3. 新しいマネージドBeanエントリを追加します。これを行うには、次の手順を実行します。
i) マネージドBean名を指定します(customReqBean、customStateBeanなど)。この名前は、後でこのBeanのインスタンスを参照するために使用します。

ii) マネージドBeanのクラス名を指定します。

iii) スコープを指定します。リクエストBeanの場合は、backingBeanスコープを使用します。状態Beanの場合は、pageFlowスコープを使用します。

注意:

- pageFlowスコープBeanは、それが定義されるタスク・フローでのみ参照可能です。

- JSFF/タスク・フロー定義またはその他の場所からマネージドBeanを参照する場合は、EL式を使用できます。たとえば、BeanをcustomReqBeanという名前で登録し、backingBeanスコープに入れた場合、次のEL式を使用してこのBeanを参照することができます。

#{backingBeanScope.customReqBean}

BeanをpageFlowスコープに入れた場合は、次のEL式を使用してこのBeanを参照できます。

#{pageFlowScope.customStateBean}

30.10.4 Oracle Identity Managerへのカスタム・コードのデプロイ

カスタム・モデルまたはViewControllerプロジェクトで生成されたADFライブラリJARファイルをデプロイするには、次の手順を実行します。

1. oracle.iam.ui.custom共有ライブラリ(oracle.iam.ui.custom-dev-starter-pack.war)を特定します。共有ライブラリは、IDM_HOME/server/apps/ディレクトリにあります。

2. WARをパッケージ化し、ADFライブラリをWEB-INF/lib/に含めます。

3. 共有ライブラリを再デプロイします。

30.10.5 マネージドBeanの使用

この項では、Oracle Identity ManagerインタフェースをカスタマイズするためのマネージドBeanの開発について、次の各ユースケースを示します。

- コンポーネントの条件付き表示

- フィールドの条件付き事前移入

- 条件付き必須フィールドの設定

- カスタム・フィールド検証の実装

- カスタム・カスケードLOVの実装

- RequestFormContextを使用したフォームのカスタマイズ

- リクエスト・カタログの「送信」ボタンのオーバーライド

- ホーム・ページ・ポートレットの開発

- タスク・フローの起動

- 外部リンクの作成

注意:

この項の例では、FacesUtilsクラスを使用します。このクラスの詳細は、「FacesUtilsクラス」を参照してください。

30.10.5.1 コンポーネントの条件付き表示

他のフィールドの値に基づいて、条件付きで特定のフィールドを表示または非表示にできます。たとえば、「ユーザー・タイプ」が「フルタイムの従業員」である場合にのみ、「ユーザーの作成」ページで「連絡先情報」パネルを表示するには、次の手順を実行します。

1. カスタム・リクエストBeanでは、「ユーザー・タイプ」フィールドと、「連絡先情報」パネルの任意の親コンポーネント(フォーム・ルート・パネルなど)のコンポーネント・バインディングのプロパティを定義します。それには、次のコードを使用します。

private UIComponent rootPanelPGL;
private UIComponent userTypeSOC;

public void setRootPanelPGL(UIComponent rootPanelPGL) {
this.rootPanelPGL = rootPanelPGL;
}

public UIComponent getRootPanelPGL() {
return rootPanelPGL;
}

public void setUserTypeSOC(UIComponent userTypeSOC) {
this.userTypeSOC = userTypeSOC;
}

public UIComponent getUserTypeSOC() {
return userTypeSOC;
}

2. ユーザーが「ユーザー・タイプ」リストで新しい値を選択すると起動される既存のvalueChangeListenerを作成するか、拡張します。それには、次のコードを使用します。

注意:

リスナーは、このフォームをリフレッシュします。

public void valueChangeListener(ValueChangeEvent valueChangeEvent) {
if (valueChangeEvent.getSource().equals(userTypeSOC)) {
// refresh form
FacesUtils.partialRender(rootPanelPGL);
}
}

3. ブール値を戻すメソッドを作成します。ページのレンダリング時に「連絡先情報」パネルが表示されるかどうかが、このメソッドによって決定されます。この例では、「ユーザー・タイプ」が「フルタイムの従業員」の場合に、「連絡先情報」パネルが表示されます。
メソッドは次のとおりです。

private static final String USER_TYPE_ATTRIBUTE = "usr_emp_type__c";

public boolean isFullTimeEmployeeUserTypeSelected() {
// return true if value of "usr_emp_type__c" binding attribute equals to "Full-Time"
// "usr_emp_type__c" binding attribute is used to display value of User Type in the User Type drop-down
return "Full-Time".equals(FacesUtils.getListBindingValue(USER_TYPE_ATTRIBUTE, String.class));
}

4. コードをJSFFとバインドするには、次の手順を実行します。

1. 定義したプロパティを指すように、「ユーザー・タイプ」リストと、ルート・パネル・コンポーネントのコンポーネント・バインディングを設定します。

2. 「ユーザー・タイプ」リストに対して、valueChangeListenerを定義します。

注意:

「ユーザー・タイプ」リストに対してautosubmitプロパティがtrueに設定されていることを確認します。

3. 手順3で定義したisFullTimeEmployeeUserTypeSelected()メソッドを指すように、「連絡先情報」パネルのrenderedプロパティ(Web Composerでの「コンポーネントの表示」)に、EL式を設定します。

30.10.5.2 フィールドの条件付き事前移入

他のフィールドの値に基づいて、特定のフィールドを事前移入します。たとえば、「名」および「姓」フィールドの値に基づいて、「ユーザーの作成」ページの「ユーザー・ログイン」および「電子メール」フィールドに値を事前移入するには、次の手順を実行します。

1. カスタム・リクエストBeanで、「名」および「姓」フィールドと、「ユーザー・ログイン」および「電子メール」フィールドの任意の親コンポーネント(フォーム・ルート・パネルなど)のコンポーネント・バインディングのプロパティを定義します。それには、次のコードを使用します。

private UIComponent firstNameIT;
private UIComponent lastNameIT;
private UIComponent rootPanelPGL;

public void setFirstNameIT(UIComponent firstNameIT) {
this.firstNameIT = firstNameIT;
}

public UIComponent getFirstNameIT() {
return firstNameIT;
}

public void setLastNameIT(UIComponent lastNameIT) {
this.lastNameIT = lastNameIT;
}

public UIComponent getLastNameIT() {
return lastNameIT;
}

public void setRootPanelPGL(UIComponent rootPanelPGL) {
this.rootPanelPGL = rootPanelPGL;
}

public UIComponent getRootPanelPGL() {
return rootPanelPGL;
}

2. ユーザーが「名」または「姓」フィールドを更新すると起動される既存のvalueChangeListenerを作成するか、拡張します。それには、次のコードを使用します。

注意:

リスナーはそれに応じて「ユーザー・ログイン」および「電子メール」を更新し、フォームをリフレッシュします。

private static final String USER_LOGIN_ATTRIBUTE = "usr_login__c";
private static final String EMAIL_ATTRIBUTE = "usr_email__c";
private static final String LAST_NAME_ATTRIBUTE = "usr_last_name__c";
private static final String FIRST_NAME_ATTRIBUTE = "usr_first_name__c";

public void valueChangeListener(ValueChangeEvent valueChangeEvent) {
if (valueChangeEvent.getSource().equals(firstNameIT)) {
// get new value of first name from the event
String firstName = (String)valueChangeEvent.getNewValue();
// get existing value of last name through binding
String lastName = FacesUtils.getAttributeBindingValue(LAST_NAME_ATTRIBUTE, String.class);
setUserLoginAndEmail(firstName, lastName);
} else if (valueChangeEvent.getSource().equals(lastNameIT)) {
// get existing value of first name through binding
String firstName = FacesUtils.getAttributeBindingValue(FIRST_NAME_ATTRIBUTE, String.class);
// get new value of last name from the event
String lastName = (String)valueChangeEvent.getNewValue();
setUserLoginAndEmail(firstName, lastName);
}
// refresh form
FacesUtils.partialRender(rootPanelPGL);
}

private void setUserLoginAndEmail(String firstName, String lastName) {
StringBuilder sb = new StringBuilder();
if (firstName != null) {
sb.append(firstName);
}
if (firstName != null && !firstName.isEmpty() && lastName != null && !lastName.isEmpty()) {
sb.append(".");
}
if (lastName != null) {
sb.append(lastName);
}
String userLogin = sb.toString();
// set new value for User Login and E-mail through binding
FacesUtils.setAttributeBindingValue(USER_LOGIN_ATTRIBUTE, userLogin);
FacesUtils.setAttributeBindingValue(EMAIL_ATTRIBUTE, userLogin + "@acme.com");
}

3. JSFFにコードを追加します。これを行うには、次の手順を実行します。

1. 定義したプロパティを指すように、「名」、「姓」およびルート・パネルのコンポーネント・バインディングを設定します。

2. 「名」および「姓」入力テキストのvalueChangeListenerを定義して、両方の入力テキストでautosubmitプロパティがtrueに設定されるようにします。

30.10.5.3 条件付き必須フィールドの設定

別のフィールドの値に基づいて、フィールドを条件付きで必須とすることができます。たとえば、「ユーザー・タイプ」が「インターン」の場合にのみ、「ユーザーの作成」ページの「マネージャ」フィールドを必須にするには、次の手順を実行します。

注意:

Web Composerの必須プロパティを設定することで、フィールド検証を実行することはできません。この項で説明するように、マネージドBeanを開発して、フィールド検証を実行する必要があります。

1. カスタム・リクエストBeanでは、「ユーザー・タイプ」フィールドと、「マネージャ」フィールドの任意の親コンポーネント(フォーム・ルート・パネルなど)のコンポーネント・バインディングのプロパティを定義します。それには、次のコードを使用します。

private UIComponent rootPanelPGL;
private UIComponent userTypeSOC;

public void setRootPanelPGL(UIComponent rootPanelPGL) {
this.rootPanelPGL = rootPanelPGL;
}

public UIComponent getRootPanelPGL() {
return rootPanelPGL;
}

public void setUserTypeSOC(UIComponent userTypeSOC) {
this.userTypeSOC = userTypeSOC;
}

public UIComponent getUserTypeSOC() {
return userTypeSOC;
}

2. ユーザーが「ユーザー・タイプ」リストで新しい値を選択すると起動される既存のvalueChangeListenerを作成するか、拡張します。それには、次のコードを使用します。

注意:

リスナーは、このフォームをリフレッシュします。

public void valueChangeListener(ValueChangeEvent valueChangeEvent) {
if (valueChangeEvent.getSource().equals(userTypeSOC)) {
// refresh form
FacesUtils.partialRender(rootPanelPGL);
}
}

3. ブール値を戻すメソッドを作成します。このメソッドは、フィールドが必須かどうかを決定します。この例では、「ユーザー・タイプ」が「インターン」の場合に、「マネージャ」フィールドが必須とマークされます。
メソッドは次のとおりです。

public boolean isInternUserTypeSelected() {
// return true if value of "usr_emp_type__c" binding attribute equals to "Intern"
// "usr_emp_type__c" binding attribute is used to display value of User Type in the User Type drop-down
return "Intern".equals(FacesUtils.getValueFromELExpression("#{bindings.usr_emp_type__c.attributeValue}"));
}

4. JSFFにコードを追加します。これを行うには、次の手順を実行します。

1. 定義したプロパティを指すように、「ユーザー・タイプ」リストと、ルート・パネル・コンポーネントのコンポーネント・バインディングを設定します。

2. 「ユーザー・タイプ」リストに対して、valueChangeListenerを定義します。「ユーザー・タイプ」リストに対してautosubmitプロパティがtrueに設定されていることを確認します。

3. 手順3で定義したisInternUserTypeSelected()メソッドを指すように、「マネージャ」フィールドの必要なプロパティにEL式を設定します。

30.10.5.4 カスタム・フィールド検証の実装

カスタム・フィールド・バリデータを導入できます。たとえば、「ユーザーの作成」ページの「アカウントの有効日」パネルの「開始日」および「終了日」フィールドに対して、次の検証を実装できます。

- 「開始日」は、「終了日」の後にはできません。

- 「契約者」の場合は、「開始日」と「終了日」の間隔が180日を超えることはできません。

カスタム・バリデータを実装するには、次の手順を実行します。

1. カスタム・リクエストBeanでは、次に示すように、「開始日」および「終了日」フィールドのコンポーネント・バインディングのプロパティを定義します。

private UIComponent startDateID;
private UIComponent endDateID;

public void setStartDateID(UIComponent startDateID) {
this.startDateID = startDateID;
}

public UIComponent getStartDateID() {
return startDateID;
}

public void setEndDateID(UIComponent endDateID) {
this.endDateID = endDateID;
}

public UIComponent getEndDateID() {
return endDateID;
}

2. ユーザーが「開始日」または「終了日」フィールドに新しい値を選択した場合に起動される既存のバリデータを作成するか、拡張します。このバリデータは、検証が失敗した場合にエラー・メッセージを生成し、更新されるフィールドにそれを付加します。それには、次のコードを使用します。

private static final String START_DATE_END_DATE_VALIDATION_MSG = "Start Date - End Date interval cannot exceed 180 days for Contractors.";
private static final String START_DATE_AFTER_END_DATE_VALIDATION_MSG = "Start Date cannot be after End Date.";

private static final String USER_TYPE_ATTRIBUTE = "usr_emp_type__c";
private static final String START_DATE_ATTRIBUTE = "usr_start_date__c";
private static final String END_DATE_ATTRIBUTE = "usr_end_date__c";

public void validator(FacesContext facesContext, UIComponent uiComponent, Object object) {
if (uiComponent.equals(startDateID)) {
// get value of End Date through binding
oracle.jbo.domain.Date jboEndDate = FacesUtils.getAttributeBindingValue(END_DATE_ATTRIBUTE, oracle.jbo.domain.Date.class);
// only validate if both Start Date and End Date are set
if (jboEndDate != null) {
// value of Start Date is passed to validator
Date startDate = ((oracle.jbo.domain.Date)object).getValue();
Date endDate = jboEndDate.getValue();
validateStartDateEndDate(facesContext, uiComponent, startDate, endDate);
}
} else if (uiComponent.equals(endDateID)) {
// get value of Start Date through binding
oracle.jbo.domain.Date jboStartDate = FacesUtils.getAttributeBindingValue(START_DATE_ATTRIBUTE, oracle.jbo.domain.Date.class);
// only validate if both Start Date and End Date are set
if (jboStartDate != null) {
Date startDate = jboStartDate.getValue();
// value of End Date is passed to validator
Date endDate = ((oracle.jbo.domain.Date)object).getValue();
validateStartDateEndDate(facesContext, uiComponent, startDate, endDate);
}
}
}

private void validateStartDateEndDate(FacesContext facesContext, UIComponent uiComponent, Date startDate, Date endDate) {
Date startDatePlus180Days = new Date(startDate.getTime() + 180L * 24 * 60 * 60 * 1000);
if (startDate.after(endDate)) {
// queue error message for the component which is being validated (either Start Date or End Date)
facesContext.addMessage(uiComponent.getClientId(facesContext),
new FacesMessage(FacesMessage.SEVERITY_ERROR, START_DATE_AFTER_END_DATE_VALIDATION_MSG, null));
} else if (isContractorUserTypeSelected() && startDatePlus180Days.before(endDate)) {
// queue error message for the component which is being validated (either Start Date or End Date)
facesContext.addMessage(uiComponent.getClientId(facesContext),
new FacesMessage(FacesMessage.SEVERITY_ERROR, START_DATE_END_DATE_VALIDATION_MSG, null));
} else {
// re-render -- in case there was an error message in queue for any of the two components it will be released
FacesUtils.partialRender(startDateID);
FacesUtils.partialRender(endDateID);
}
}

public boolean isContractorUserTypeSelected() {
// return true if value of "usr_emp_type__c" binding attribute equals to "Contractor"
// "usr_emp_type__c" binding attribute is used to display value of User Type in the User Type drop-down
return "Contractor".equals(FacesUtils.getListBindingValue(USER_TYPE_ATTRIBUTE, String.class));
}

3. JSFFにコードをバインドします。これを行うには、次の手順を実行します。

1. 定義したプロパティを指すように、「開始日」および「終了日」フィールドのコンポーネント・バインディングを設定します。

2. 手順2で定義したバリデータ・メソッドを指すように、「開始日」および「終了日」フィールドのバリデータ・プロパティに、EL式を定義します。

30.10.5.5 カスタム・カスケードLOVの実装

カスケードLOVとは、1つのコンポーネントの値リストが別のコンポーネントで現在選択されている値に依存するLOVコンポーネントです。たとえば、「ユーザーの作成」ページ上の「ユーザー・タイプ」リストの選択された値に基づいて、「ジョブ・コード」リストまたは別のLOVコンポーネントを表示する場合があります(その値リストは「ユーザー・タイプ」リストで現在選択されている値に依存します)。

カスタム・カスケードLOVを実装する高度なガイドラインを次に示します。

1. 「ユーザー・タイプ」フィールドと「ジョブ・コード」の任意の親コンポーネント(フォーム・ルート・パネルなど)のコンポーネント・バインディングを定義します。

2. 次の要件を確実に満たして、「ジョブ・コード」LOVコンポーネントのモデルを実装します。

- このモデルは、「ユーザー・タイプ」フィールドの現在の値を考慮する必要があります。

- af: selectOneChoiceに対して、List<javax.faces.model.SelectItem>を戻すメソッドを実装する必要があります。

- af: inputListOfValuesに対して、oracle.adf.view.rich.model.ListOfValuesModeのインスタンスを戻すメソッドを実装する必要があります。

関連項目:

LOVコンポーネントを使用して、ユーザーが値を選択できるオブジェクトのモデルドリブン・リストを表示する方法については、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の値リスト・コンポーネントの使用に関する説明を参照してください。

3. 「ユーザー・タイプ」フィールドに対して、valueChangeListenerを実装します。「ユーザー・タイプ」フィールドのautosubmitプロパティをtrueに設定します。
valueChangeListenerは、「ジョブ・コード」LOVコンポーネントのモデルを、「ユーザー・タイプ」フィールドの現在の値で更新する必要があります。また、「ジョブ・コード」LOVコンポーネントが現在の値リストで更新されるように、valueChangeListenerはフォームを再レンダリングする必要があります。

30.10.5.6 RequestFormContextを使用したフォームのカスタマイズ

RequestFormContextは、エンティティ・フォーム詳細タスク・フローのpageFlowScopeで使用可能なBeanです。エンティティ・フォームには、ユーザー・フォーム、アプリケーション・インスタンス・フォーム、ロール・フォームおよび権限フォームが含まれます。このインスタンスは、様々なコンテキスト情報を提供します。このコンテキスト情報を使用すると、特定のビジネス要件に基づいて様々なフォームをカスタマイズできます。

次に示すように、Javaコードを使用してクラスのインスタンスを取得できます。

RequestFormContext.getCurrentInstance();

次に示すように、ELを使用してクラスのインスタンスを取得することもできます。

#{pageFlowScope.requestFormContext}

RequestFormContextは、次のコンテキスト情報を提供します。

- operation: エンティティで実行中の操作。可能な値はCREATEおよびMODIFYです。

- actionType: エンティティ・フォームが表示されている場合に、ユーザーが実行中のアクション。可能な値は、APPROVAL、FULFILL、REQUEST、VIEW、SUMMARYです。

- bulk: バルク操作であるかどうか。

- beneficiaryIds: 受益者またはターゲット・ユーザーIDのリスト。たとえば、ユーザーJohn Doe用のアプリケーション・インスタンスをリクエストしている場合、リストにはJohn DoeのユーザーIDが含まれます。

- cartItemIds: カート・アイテムIDのリスト。たとえば、ユーザーのアプリケーション・インスタンスをリクエストしている場合、リストにはリクエスト中のアプリケーション・インスタンスIDが含まれます。

- requestEntityType: リクエスト中のエンティティ・タイプ(ROLE、ENTITLEMENT、APP_INSTANCE、USERのいずれか)。

- requestEntitySubType: リクエスト中のエンティティのサブタイプ。たとえば、アプリケーション・インスタンスをリクエスト中の場合、requestEntitySubTypeはアプリケーション・インスタンス・キーです。

- instanceKey: 変更中のインスタンスのキー。

RequestFormContextの使用例を次に示します。

「アプリケーション・インスタンスの作成」フォームに新しい「事前移入」ボタンを追加し、ターゲット・ユーザーが1人だけの場合にのみ、このボタンを表示可能にします。このボタンをクリックすると、アプリケーション・インスタンス・フィールドの一部(「ユーザー・ログイン」、「名」、「姓」など)が、現在のターゲット・ユーザーに基づいて事前移入されます。これを実行する手順を次に示します。

1. カスタム・リクエストBeanでは、次に示すように、「事前移入」ボタンおよびフォーム・ルート・パネルのコンポーネント・バインディングのプロパティを定義します。

private UIComponent rootPanel;
private UIComponent prepopulateButton;

public void setRootPanel(UIComponent rootPanel) {
this.rootPanel = rootPanel;
}

public UIComponent getRootPanel() {
return rootPanel;
}

public void setPrepopulateButton(UIComponent prepopulateButton) {
this.prepopulateButton = prepopulateButton;
}

public UIComponent getPrepopulateButton() {
return prepopulateButton;
}

2. 「事前移入」ボタンがクリックされると起動するactionListenerを実装します。Oracle Identity Manager APIを使用することで、actionListenerはターゲット・ユーザーIDを使用して、ユーザー・データ(「名」、「姓」など)をフェッチします。フェッチしたデータを使用して、属性バインディングを介して特定のアプリケーション・インスタンス属性を設定し、最後にフォームをリフレッシュして新しい値を表示します。actionListenerを次に示します。

public void actionListener(ActionEvent e) {
if (e.getSource().equals(prepopulateButton)) {
RequestFormContext requestFormContext = RequestFormContext.getCurrentInstance();
List<String> beneficiaryIds = requestFormContext.getBeneficiaryIds();
if (beneficiaryIds.size() == 1) {
// prepopulate fields based on selected beneficiary
User user = getUser(beneficiaryIds.get(0));
FacesUtils.setAttributeBindingValue(ACCOUNT_LOGIN_ATTRIBUTE, user.getLogin());
FacesUtils.setAttributeBindingValue(ACCOUNT_ID_ATTRIBUTE, user.getId());
FacesUtils.setAttributeBindingValue(FIRST_NAME_ATTRIBUTE, user.getFirstName());
FacesUtils.setAttributeBindingValue(LAST_NAME_ATTRIBUTE, user.getLastName());
}
}
FacesUtils.partialRender(rootPanel);
}

private User getUser(String userId) {
UserManager userManager = OIMClientFactory.getUserManager();
try {
return userManager.getDetails(userId, null, false);
} catch (NoSuchUserException e) {
throw new RuntimeException(e);
} catch (UserLookupException e) {
throw new RuntimeException(e);
}
}

3. ブール値を戻すメソッドを作成します。フォームのレンダリング時に「事前移入」ボタンが表示されるかどうかが、このメソッドによって決定されます。この例では、ターゲット・ユーザーの数が1と等しい場合に、「事前移入」ボタンが表示されます。メソッドは次のとおりです。

public boolean isPrepopulateButtonRendered() {
RequestFormContext requestFormContext = RequestFormContext.getCurrentInstance();
return requestFormContext.getActionType() == RequestFormContext.ActionType.REQUEST && requestFormContext.getBeneficiaryIds().size() == 1;
}

4. コードをJSFFとバインドします。これを行うには、次の手順を実行します。

1. 「事前移入」ボタンを「アプリケーション・インスタンスの作成」フォームに追加します。

2. 「事前移入」ボタンとルート・パネルのバインディングを設定します。

3. 手順2で実装したactionListenerメソッドを指すように、「事前移入」ボタンのactionListenerプロパティを設定します。

4. 手順3で実装したisPrepopulateButtonRendered()メソッドを指すように、renderedプロパティを設定します。

30.10.5.7 リクエスト・カタログの「送信」ボタンのオーバーライド

リクエスト・カタログの「送信」ボタンをオーバーライドし、要件に基づいて追加のロジックを実行できます。たとえば、リクエストの送信時に、ターゲット・ユーザーまたは受益者の数を追加でチェックし、受益者の数が5人以下の場合にリクエストの送信を許可するには、次の手順を実行します。

1. 元の「送信」ボタンをオーバーライドするactionListenerを実装します。
ユーザーがこの「送信」ボタンをクリックすると、actionListenerが起動されます。actionListenerは追加チェックを実行し、エラー・メッセージを表示するか、または「送信」ボタンにバインドされている元のactionListenerを実行します。元の「送信」ボタンのactionListenerは、次のEL式を使用して実行できます。

#{backingBeanScope.cartReqBean.submitActionListener}

actionListenerのコードを次に示します。

public void submitButtonActionListener(ActionEvent e) {
// only submit request if there is no more than 5 beneficiaries
Boolean moreThanFiveTargetUsers = FacesUtils.getValueFromELExpression("#{backingBeanScope.cartReqBean.targetUserSize > 5}", Boolean.class);
if (moreThanFiveTargetUsers) {
// display error message
FacesMessage fm = new FacesMessage();
fm.setSeverity(FacesMessage.SEVERITY_ERROR);
fm.setSummary(MORE_THAN_FIVE_TARGET_USERS_MSG);
FacesUtils.showFacesMessage(fm);
} else {
// execute original submit button action listener
MethodExpression originalActionListener =
FacesUtils.getMethodExpressionFromEL("#{backingBeanScope.cartReqBean.submitActionListener}", null, new Class[] { ActionEvent.class });
originalActionListener.invoke(FacesUtils.getELContext(), new Object[] { e });
}
}

2. 新しいactionListenerの実装を指すように、「送信」ボタンのactionListenerプロパティを更新します。

30.10.5.8 ホーム・ページ・ポートレットの開発

ホーム・ページ・ポートレットは、Oracle Identity Self Serviceでユーザーのホーム・ページに追加できる通常のバインド・タスク・フローです。ホーム・ページ・ポートレットはViewControllerプロジェクトで作成する必要があります。ViewControllerプロジェクトには、タイプがADFライブラリJARファイルのデプロイメント・プロファイルが必要です。ViewControllerプロジェクトの設定の詳細は、「ViewControllerプロジェクトの設定」を参照してください。カスタム・マネージドBeanの追加の詳細は、「カスタム・マネージドBeanの追加」を参照してください。

関連項目:

ADFタスク・フローの開発の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFタスク・フローの作成に関する説明を参照してください。

バインド・タスク・フローを開発した後に、それをデプロイする必要があります。バインド・タスクフローのデプロイの詳細は、「Oracle Identity Managerへのカスタム・コードのデプロイ」を参照してください。

すべての新しいタスク・フローには、それをIdentity Self Serviceで参照可能にする権限を付与する必要があります。詳細は、「APMを使用したカスタム・タスクフローの保護」を参照してください。

ホーム・ページ・ポートレット開発の最後の手順は、ホーム・ページのリソース・カタログを更新することです。これによって、ユーザーがホームページにポートレットを追加できるようになります。ホーム・ページのリソース・カタログを更新するには、次の手順を実行します。

1. oracle.iam.ui.custom共有ライブラリ(oracle.iam.ui.custom-dev-starter-pack.war)を特定します。これは、DM_HOME/server/apps/ディレクトリで使用可能です。

2. WARを解凍し、oracle/adf/rc/metadata/custom-catalog.xmlファイルを見つけます。

3. ファイルを更新し、新しく追加されたバインド・タスク・フローに、参照を含めます。エントリは次のようになります。

<resource id="helloWorld" name="Hello World"
description="Hello World Taskflow Reference"
repository="application.classpath"
path="adflibHomepagePortletsUI.jar/ADF_TaskFlow/WEB-INF+oracle+iam+ui+sample+homepage+tfs+hello-world-tf.xml#hello-world-tf">
<attributes>
<attribute value="coreDefault" attributeId="attr.background" isKey="false"/>
</attributes>
</resource>

注意:

pathプロパティの形式が正しいことを確認します。形式は、手順3で示したパターンと同じである必要があります。また、repositoryプロパティの値がapplication.classpathであることを確認します。このファイルの形式の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイドのカタログ定義属性の項のリソースに関する説明を参照してください。

4. 共有ライブラリを再デプロイします。

注意:

ホーム・ページのリソース・カタログを更新する手順を実行しても、「コンテンツの追加」ボタンをクリックしたときにリソース・カタログにカスタム・タスク・フローが表示されない場合、次の点を確認してください。

- タスク・フロー権限が適切に定義されていることを確認します。詳細は、「APMを使用したカスタム・タスクフローの保護」を参照してください。

- タスク・フローが格納されているADFライブラリJARファイルにMETA-INF/task-flow-registry.xmlファイルが含まれており、カスタム・タスク・フローへの参照がそのファイルに含まれていることを確認してください。このファイルがない場合、そのカスタム・タスク・フローを含む特定のJDeveloperプロジェクトのみを再作成し、それで問題が解決されるかどうか確認します。特定のJDeveloperプロジェクトのみを再作成するには、JDeveloperでそのカスタム・タスク・フローを含むViewControllerプロジェクトを右クリックし、「デプロイメント」を選択して、デプロイメント・プロファイルを選択します。デプロイメント・プロファイルのタイプはADFライブラリJARファイルでなければなりません。

30.10.5.9 タスク・フローの起動

「セルフ・サービス」インタフェースでタスク・フローを起動できます。たとえば、タブ内で動作するバインド・タスク・フローを持つタブを起動する場合は、次の手順を実行します。

1. 次のメソッドを使用して、カスタム・マネージドBeanを開発します。

public void launchMyTaskFlow(ActionEvent evt){

User  user = OIMClientFactory.getAuthenticatedService().getProfileDetails(null);
String taskFlowId = "/WEB-INF/oracle/iam/ui/manageusers/tfs/user-details-tf.xml#user-details-tf";
// This id uniquely identifies the taskflow after launch. Add a suffix, for example entityPrimaryKey, to make it unique.
String id = "user-detail-tf;
String name = user.getDisplayName() ;  // this is shown as the tab title
String description = ""; // Add any suitable description
String icon = "/images/user.png";
String  helpTopicId = ConstantsDefinition.DEFAULT_HELP_TOPIC_ID; // Or your custom OHW integrated help topic id
boolean inDialog = false;
Map params = new HashMap();  // These are your taskflow's input parameters being passed from this launcher method
params.put("userLogin",  user.getLogin());
param.put("usr_key", user.getId());

String jsonPayLoad = TaskFlowUtils.createContextualEventPayLoad(id, taskFlowId, name, icon, description, helpTopicId, inDialog, params);
TaskFlowUtils.raiseContextualEvent(TaskFlowUtils.RAISE_TASK_FLOW_LAUNCH_EVENT, jsonPayLoad);
}

「マネージドBeanおよびタスク・フローの開発」で説明したように、マネージドBeanをパッケージ化し、デプロイします。

2. サンドボックスおよびWeb Composerのカスタマイズの使用により、ADF CommandLinkを適切なページ(JSFFファイル)に追加して、サンドボックスをエクスポートします。サンドボックスのzipを開き、jsff.xmlファイルを編集して、そのリンクのactionListenerをマネージドBeanメソッドにバインドします。

3. jsffのページ定義にraiseTaskFlowLaunchEventバインディングがあることを確認します。ページ定義ファイルの名前を検索するには、まず最初に、起動リンクのあるjsffページの名前を把握する必要があります。
jsffページが既存の左側のナビゲーション・ページの場合、名前はleft-nav.jsffとなります。このjsffページのページ定義ファイルは、left-nav_pageDef.xmlです。このページ定義XMLファイルにはすでにeventBindingが含まれているため、何も変更する必要はありません。

ご使用の起動リンクがカスタムjsffページにある場合(たとえば、ご使用のページ名がmy-custom.jsffの場合)、同じJDevプロジェクト内のmy-custom_pageDef.xmlという名前のファイルを検索します。JDevは、各jsffに対して、このファイルを自動的に作成します。このpageDef xmlファイルに次のeventBindingを追加する必要があります。

<eventBinding id="raiseTaskFlowLaunchEvent">
<events xmlns="http://xmlns.oracle.com/adfm/contextualEvent">
<event name="oracle.idm.shell.event.TaskFlowLaunchEvent"/>
</events>
</eventBinding>

注意:

既存のOracle Identity Managerページには、すでにeventBindingが含まれています。自身で作成したJSFFページに対して、eventBindingを定義する必要があります。

30.10.5.10 外部リンクの作成

特定のURLにユーザーをリダイレクトするリンクまたはボタンを追加するには、次の手順を実行します。

1. カスタム・リクエストBeanで、ユーザーがリンクまたはボタンをクリックすると起動される次のactionListenerを作成します。

public void actionListener(ActionEvent e) {
FacesUtils.redirect("http://www.oracle.com");
}

2. Web Composerを使用して、リンクまたはボタンを表示するページに、新しいcommandLinkまたはcommandButtonを追加します。詳細は、「リンクまたはボタンの追加」を参照してください。

3. actionListenerメソッドを指すように、追加したリンクまたはボタン・コンポーネントのactionListenerプロパティを設定します。

30.10.6 リクエスト属性を移入するためのマネージドBeansの使用

この項では、リクエスト属性を移入するための次のアプローチについて説明します。

- マネージドBeansを使用したリクエスト属性の移入

- 事前移入プラグインを使用したリクエスト属性の移入

30.10.6.1 マネージドBeansを使用したリクエスト属性の移入

このアプローチにより、ユーザーがカスタム・ボタンをクリックすると呼び出されるマネージドBeanが作成されます。マネージドBeanは、Oracle Identity Managerのカスタマイズ・プレースホルダ・ライブラリ(oracle.iam.ui.custom-dev-starter-pack.war)にデプロイされる必要があります。「事前移入」ボタンと呼ばれるボタンは、UIカスタマイズの一部で、Web Composerを使用して手動でページに追加する必要があります。

マネージドBeanコードは、リクエスト・フォームに移入される情報のフェッチを行います。Oracle Identity Manager APIを使用して、リクエストやユーザー管理レイヤーから受益者情報を入手します。また、JSF/ADF APIを使用して、リクエスト・フォームのUIコンポーネントを更新します。

マネージドBeansおよびUIカスタマイズを使用してリクエスト属性を移入する手順は次のとおりです。

1. JDevアプリケーション・ワークスペースとプロジェクトを作成します。詳細は、「ViewControllerプロジェクトの設定」を参照してください。

2. Javaクラスを作成します。この例では、完全なクラス名はcom.oracle.demo.iam.prepop.view.PrePopulateMBeanです。このクラスには、次の内容が含まれます。

- UIコンポーネント、カスタムの「事前移入」ボタンとその親コンテナへの参照を保持する2つのメンバー変数

- 変数メンバー変数のアクセッサ・メソッド(getおよびset)

- ユーザーがカスタムの「事前移入」ボタンをクリックすると呼び出されるアクション・リスナー・タイプ・メソッド

- カスタムの「事前移入」ボタンの無効化が必要なタイミングを決定するブール値を返すメソッド

この例のカスタム・コードを次に示します。

public class PrePopulateMBean {

private UIComponent rootPanel;
private UIComponent prepopulateButton;

public PrePopulateMBean() {
super();
}

public void setRootPanel(UIComponent rootPanel) {
this.rootPanel = rootPanel;
}

public UIComponent getRootPanel() {
return rootPanel;
}

public void setPrepopulateButton(UIComponent prepopulateButton) {
this.prepopulateButton = prepopulateButton;
}

public UIComponent getPrepopulateButton() {
return prepopulateButton;
}

public boolean isPrepopulateButtonRendered() {

boolean ret = false;
RequestFormContext requestFormContext = RequestFormContext.getCurrentInstance();
if (requestFormContext != null) {

boolean isActionRequest   = (requestFormContext.getActionType() == RequestFormContext.ActionType.REQUEST);
boolean singleUserRequest = false;

if (requestFormContext.getBeneficiaryIds()!=null) {
singleUserRequest = (requestFormContext.getBeneficiaryIds().size() == 1);
}
ret = isActionRequest && singleUserRequest;
}
return (ret);
}

public void actionListener(ActionEvent e) {

if (e.getSource().equals(prepopulateButton)) {

RequestFormContext requestFormContext = RequestFormContext.getCurrentInstance();
List<String> beneficiaryIds = requestFormContext.getBeneficiaryIds();

if (beneficiaryIds.size() == 1) {

try {
User user = getUser(beneficiaryIds.get(0));
FacesUtils.setAttributeBindingValue("UD_OID_USR_FNAME__c", user.getFirstName());
FacesUtils.setAttributeBindingValue("UD_OID_USR_LNAME__c", user.getLastName());

} catch (NoSuchUserException f) {
f.printStackTrace();
} catch (UserLookupException f) {
f.printStackTrace();
}
}
}
FacesUtils.partialRender(rootPanel);
}

private User getUser(String userKey) throws NoSuchUserException, UserLookupException {

UserManager userMgr = OIMClientFactory.getUserManager();

HashSet<String> searchAttrs = new java.util.HashSet<String>();
searchAttrs.add(AttributeName.USER_LOGIN.getId());
searchAttrs.add(AttributeName.LASTNAME.getId());
searchAttrs.add(AttributeName.FIRSTNAME.getId());

return userMgr.getDetails(userKey,searchAttrs, false);
}
}

Javaクラスのコードでは、次のようになります。

- RequestContextが使用可能な場合やリクエスト受益者が1人のみの場合、isPrepopulateButtonRenderedメソッドはtrueを返します。カスタマイズ時の問題点を回避するために、RequestContext可用性のチェックが必要です。このメソッドは、カスタムの「事前移入」ボタンのロード時またはそのコンテナのリフレッシュ時に呼び出されます。

- actionListenerメソッドは、リクエスト受益者情報を使用するgetUserメソッドを呼び出して、Oracle Identity Managerでユーザー検索を実行します。その後、ユーザー検索から返された情報を使用してUD_OID_USR_FNAME__cおよびUD_OID_USR_LNAME__cのUIコンポーネントに値を直接設定し、rootPanelで部分レンダリングを呼び出します。このパネルは、カスタム・ボタンとリクエスト・フォームを保持しています。部分レンダリングにより、それぞれのフィールドに値が表示されます。このカスタム・コードにUIコンポーネントへの直接参照が含まれ、直接参照はサンドボックスのエクスポートにより見つけることができることをここで説明することが重要です。このメソッドは、カスタムの「事前移入」ボタンのロード時またはそのコンテナのリフレッシュ時に呼び出されます。

- FacesUtilクラスは、UI変更のレンダリングを行います。このクラスのコードについては、付録B「FacesUtilsクラス」を参照してください。

3. JDevプロジェクトで、PrePopulateMBeanクラスをマネージドBeanとして宣言します。これによりMBeanはUIで使用できるようになり、その結果、EL式を使用した呼出しが可能になります。この構成には、View ControllerプロジェクトのマネージドBeansセクションで次の値を指定します。

- 名前: prepopMBean

- クラス(class): com.oracle.demo.iam.prepop.view.PrePopulateMBean

- スコープ: backingBean

4. View ControllerプロジェクトをADFライブラリJARファイルとしてデプロイします。このタイプのデプロイメントは、デプロイメント・プロファイル・オプションによりJDeveloperで作成されます。デプロイメントにより、JARファイルが生成されます。このファイルを、Oracle Identity Managerプレースホルダ・ライブラリであるoracle.iam.ui.custom-dev-starter-pack.warにコピーします。このファイルは、他のOracle Identity Managerアプリケーション・パッケージ(EARファイルやWARファイルなど)とともに、$OIM_ORACLE_HOME/server/apps/ディレクトリにあります。このファイルを変更する前に、バックアップを作成します。

5. カスタム・コードをデプロイする手順は次のとおりです。

1. oracle.iam.ui.custom-dev-starter-pack.warを一時的な場所にコピーします。

2. oracle.iam.ui.custom-dev-starter-pack.warを開きます。

3. カスタムjarファイルをWEB-INF/libディレクトリに追加します。libディレクトリが存在しない場合は、作成します。

4. oracle.iam.ui.custom-dev-starter-pack.warファイルを保存します。

5. oracle.iam.ui.custom-dev-starter-pack.warファイルのコピーを$OIM_ORACLE_HOME/server/apps/ディレクトリ内の元の場所に戻します。

6. Oracle Identity Manager管理対象サーバーを停止します。

7. WebLogic管理コンソールで、oracle.iam.ui.customライブラリ・デプロイメントを更新し、変更をアクティブにします。

8. Oracle Identity Manager管理対象サーバーを起動します。

6. UIをカスタマイズします。これを行うには、次の手順を実行します。

1. サンドボックスを作成し、アクティブにします。この例では、サンドボックス名はRequestPrePopです。

2. Oracle Identity Self Serviceにログインし、「カタログ」ページに移動します。

3. カスタマイズする特定のアプリケーション・インスタンスを検索します。この例では、アプリケーション・インスタンスは「ローカルOID」です。ショッピング・カートにアプリケーション・インスタンスを追加して、チェックアウトします。

4. 「カスタマイズ」をクリックします。

5. 「表示」→「ソース」を選択します。

6. そのページの「カート項目」セクションおよび「詳細」セクションで、「詳細」ラベルの近くをクリックします。showDetailHeader:Detailsコンポーネントが選択されていることを確認します。

7. 左上の「編集」をクリックします。表示されたダイアログ・ボックスで、Bindingプロパティを編集し、式ビルダーを使用して次のELを構成します。

#{backingBeanScope.prepopMBean.rootPanel}

この式バインドにより、UIはカスタムのマネージドBeanのsetRootPanelメソッドを呼び出します。「OK」をクリックします。

8. showDetailHeader:Detailsコンポーネントが選択されたことを確認します。「コンテンツの追加」をクリックします。

9. 下方向にスクロールして、「Webコンポーネント」セクションを開きます。

10. コマンド・ツールバー・ボタン・コンポーネントの右の「追加」をクリックします。「詳細」セクションにボタンが追加されます。

11. ボタンをクリックして、「編集」をクリックします。

12. Textプロパティを編集し、ラベルとして「事前移入」を設定します。

13. Bindingプロパティを編集し、式ビルダーを使用して次のELを構成します。

#{backingBeanScope.prepopMBean.prepopulateButton}

このバインドは、カスタムのマネージドBeanのsetPprepopulateButtonメソッドを呼び出します。「OK」をクリックします。

14. Disabledプロパティを編集し、式ビルダーを使用して次のELを構成します。

#{!backingBeanScope.prepopMBean.prepopulateButtonRendered}

このバインドは、カスタムのマネージドBeanのisPrepopulateButtonRenderedメソッドを呼び出します。「OK」をクリックします。

15. 「スタイル」タブをクリックします。Widthプロパティを100に設定し、Margin - Leftプロパティを100に設定します。「OK」をクリックします。この構成により、UIに「事前移入」ボタンが適切に配置されます。

16. 「閉じる」をクリックして、カスタマイズ・モードを終了します。

7. 「事前移入」ボタンのプロパティを手動で構成する手順は次のとおりです。

1. 「サンドボックス」ページに移動します。サンドボックスを非アクティブ化し、エクスポートします。

2. ローカルのファイル・システムにサンドボックスのZIPファイルを保存します。

3. ZIPファイルを解凍します。テキスト・エディタで、カスタマイズに対応するXMLファイルを開きます。この例では、ファイルはoracle/iam/ui/runtime/form/view/pages/mdssys/cust/site/site/OIDUserFormCreateForm.jsff.xmlです。

4. 次のような、カスタムの「事前移入」ボタンを定義するセクションを検索します。

<af:commandToolbarButton xmlns:af="http://xmlns.oracle.com/adf/faces/rich" id="e8829502064" binding="#{backingBeanScope.prepopMBean.prepopulateButton}" text="PrePopulate"

5. 次のように、actionListenerプロパティをカスタムの「事前移入」ボタンに追加します。

actionListener="#{backingBeanScope.prepopMBean.actionListener}

6. ファイルを保存し、ZIPを再パッケージ化します。内容の再パッケージ化時にパスが保存されたことを確認してください。

7. サンドボックスをインポートして、ZIPファイルをインポートします。インポート時にサンドボックスがアクティブではないことを確認してください。

8. サンドボックスをアクティブにします。

8. カスタマイズをテストします。これを行うには、次の手順を実行します。

1. 「カタログ」に移動し、アプリケーション・インスタンスを検索し、ショッピング・カートに追加します。

2. カートのサマリー・ページに、カスタムの「事前移入」ボタンが表示されます。このボタンをクリックすると、「名」フィールドと「姓」フィールドが受益者の情報に更新されます。

3. 「事前移入」ボタンをクリックします。「名」フィールドと「姓」フィールドが受益者の情報に更新されます。

9. サンドボックスを公開します。

30.10.6.2 事前移入プラグインを使用したリクエスト属性の移入

事前移入プラグインは、UIとAPIリクエスト作成に対して同じロジックが実行される場合や、UI相互作用が不要な場合にも使用できます。このアプローチでは、リクエストに事前移入する必要がある各属性に対してプラグインがあります。リソースや属性が異なっても同一のプラグインを使用できます。

プラグイン・コードは、oracle.iam.request.plugins.PrePopulationAdapterインタフェースを実装しています。次にコード例を示します。

package com.oracle.demo.iam.prepop.plugin;

import java.io.Serializable;

import java.util.HashSet;
import java.util.List;

import oracle.iam.identity.usermgmt.api.UserManager;
import oracle.iam.identity.usermgmt.api.UserManagerConstants.AttributeName;
import oracle.iam.identity.usermgmt.vo.User;
import oracle.iam.platform.Platform;
import oracle.iam.request.vo.Beneficiary;
import oracle.iam.request.vo.RequestData;

public class UserLoginPrePop implements oracle.iam.request.plugins.PrePopulationAdapter {

public UserLoginPrePop() {
super();
}

public Serializable prepopulate(RequestData requestData) {

String prePopUserId = null;

List<Beneficiary> benList = requestData.getBeneficiaries();

if(benList.size()==1){

UserManager  usersvc = Platform.getService(UserManager.class);

for(Beneficiary benf: benList){

HashSet<string> searchAttrs = new java.util.HashSet<String>();
searchAttrs.add(AttributeName.USER_LOGIN.getId());

try {
User userBenef = usersvc.getDetails(benf.getBeneficiaryKey(),searchAttrs, false);
if (userBenef!= null) {
prePopUserId = userBenef.getLogin();
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
return prePopUserId;
}
}

事前移入プラグインは、Oracle Identity Managerのその他のプラグインと似ています。プラグイン・クラスは、コンパイルされ、JARファイルにデプロイされます。JARファイルは、libディレクトリのZIPファイルに追加される必要があります。ZIPファイルは、ルート・パスにプラグインを宣言するXMLファイルが含まれている必要があります。この例で使用されるXMLは次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.request.plugins.PrePopulationAdapter">
<plugin pluginclass= "com.oracle.demo.iam.prepop.plugin.UserLoginPrePop" version="1.0" name="UserLoginPrePop">
<metadata name="PrePopulationAdapater">
<value>OracleDBUMForm::Username|OIDUserForm::User ID</value>
</metadata>
</plugin>
</plugins>
</oimplugins>

XMLコードでは、次のようになります。

- XMLにxmlnsタグ属性があることが必要です。タグ属性がない場合、Oracle Identity Managerによるプラグインの呼出しは行われません。

- pluginpoint要素の値は、oracle.iam.request.plugins.PrePopulationAdapterであることが必要です。

- メタデータ・タグには、値の子ノードが含まれます。この値の子ノードには、FormName::AttributeNameのペアを含める必要があります。それぞれのペアは、事前移入プラグインによって移入されるフォーム属性を示しています。この例では、OracleDBUMFormフォームの「ユーザー名」およびOIDUserFormフォームの「ユーザーID」がそのような属性に該当します。フォーム名は、Oracle Identity Managerへのコネクタのインポート時に作成されるプロセス・フォームではなく、ApplicationInstancesやそのフォームが作成される場合に構成されます。

事前移入プラグインは、$OIM_HOME/server/plugins/ディレクトリにデプロイできます。また、プラグイン登録スクリプトを使用して登録できます。本番環境では、プラグインのZipファイルがデータベースにアップロードされるように、常に、コマンドラインを使用したプラグインをデプロイすることをお薦めします。

30.11 UIカスタマイズの移行

あるOracle Identity Manager環境から別の環境、つまりテスト環境から本番環境(T2P)へのUIカスタマイズの移行は、次の使用例のヘルプを使用して説明します。

使用例1: 増分T2P

開発サイクルの間、構成の増分構築や、あるOracle Identity Manager設定から別の設定へ引き続き構成を移動します。これを実現するには、第38章「構成およびカスタマイズの移行」に説明されているように、デプロイメント・マネージャを使用します。しかし、デプロイメント・マネージャを使用したデータのエクスポートおよびインポートには、UIカスタマイズは含まれません(リソース・バンドルの移行は除く)。このため、Oracle Identity Managerではサンドボックスが用意されています。これにより、サンドボックスでバインドされたカスタマイズを作成し、テストし、最終的に増分ベースでのエクスポート/インポートが可能になります。

ただし、カスタマイズの増分移行には問題があります。あらかじめサンドボックスをエクスポートしておく必要があるうえに、公開されるのは変更点のみです。変更点をテストできるのは、公開後に限られます。しかし、すでに変更点が公開されていると、エクスポートできません。これは既知の問題です。

使用例2: Fusion Middlewareフレームワーク・ベースの完全T2P

開発サイクルおよびテスト・サイクルが完了すると、実際のデプロイメントの初日に本番環境を設定します。テスト環境から本番環境へすべての構成およびカスタマイズを移動します。

Fusion Middlewareフレームワーク・ベースのユーティリティを使用したOracle Identity Managerの完全T2Pは、UIカスタマイズの移動もサポートしています。Fusion Middlewareフレームワーク・ベースの完全T2Pは、Fusion Middleware T2Pユーティリティ(copyBinary、pasteBinary、copyconfig、extractMoveplan、pasteconfigなど)を使用して実行されます。デプロイメント・マネージャは使用しません。完全T2Pの詳細は、『Oracle Fusion Middleware管理者ガイド』のテスト環境から本番環境への移動に関する項を参照してください。

T2Pで、公開済サンドボックスのリストが表示されなくても、問題ではありません。宛先または本番環境ではなく、テスト環境(T2Pソース)で公開済/非公開の変更のトラッキングが行われていると考えられるためです。

ソースまたはテスト環境での非公開サンドボックスでは、次のことが当てはまります。

- これらのサンドボックスの有効範囲を拡大した後、非公開サンドボックスを増分ワークとして後から移動することが考えられますが、それらは現在、本番環境には含まれていません。

- 非公開サンドボックスはテストされていないため、本番環境には含めません。

30.12 UIカスタマイズのベスト・プラクティス

サンドボックスの作成時に、詳細説明を付けて作成し、作成中のサンドボックスの対象のエンティティをすべてリストします。たとえば、アプリケーション・インスタンスを作成中の場合は、アプリケーション・インスタンスの作成用にこのサンドボックスを作成していることをメモしておきます。アプリケーション・インスタンスの作成時にこのサンドボックスを公開し、Identity Self Serviceに移動してUIカスタマイズを実行する別のサンドボックスを作成します。これは、2人以上のユーザーが異なるサンドボックスを作成して、同じエンティティを作成し(この例ではアプリケーション・インスタンス)、それを異なるタイミングで公開した場合の問題を回避するためです。

30.13 UIカスタマイズのロールバック

インタフェースのカスタマイズおよびサンドボックスの公開後にOracle Identity System Administrationにログインできない場合は、次の手順を実行します。

1. Oracle Enterprise Managerにログインします。

2. 「アプリケーション・デプロイメント」で、oracle.iam.ui.console.self-service.earを選択します。

3. そのページの右上の「アプリケーション・デプロイメント」をクリックし、リストから「MDS構成」を選択します。

4. 画面下部で、「拡張構成」セクションの下の「ランタイムMBeanブラウザ」を選択します。画面の右側がリフレッシュされます。

5. 「操作」タブをクリックします。

6. 下方向にスクロールし、listMetadataLabels MBean操作を特定して、呼び出します。パラメータを必要としないMBean操作を選択します。リストア対象の事前に作成されたサンドボックスを選択し、クリップボードにコピーします。
たとえば、コピーする値はCreation_IdM_test_09:25:00となります。

7. 「戻る」をクリックして、「操作」タブに戻ります。

8. promoteMetadataLabel MBean操作を検索します。

9. promoteMetadataLabel MBean操作を呼び出し、手順6でコピーした値を入力します。

10. Oracle Identity Managerを再起動します。

11. Oracle Identity System Administrationにログインします。

第VIII部

他のアプリケーションと統合するインタフェース

この部では、Oracle Identity ManagerでサポートされているAPIおよびWebサービスについて説明します。

次の章で構成されます。

- 第31章「APIの使用」

- 第32章「SPMLサービスの使用」

- 第33章「URLの使用」

31 APIの使用

オラクル社では、Oracle Identity Managerで使用可能なサービス(以前のリリースではユーティリティと呼ばれていました)を公開する目的で、ネットワーク対応型のJavaベースのApplication Program Interface (API)を提供しています。このAPIはPlain Old Java Objects (POJO)に基づき、Oracle Identity Managerと対話するために必要なすべての処理を行います。このAPIは、Oracle Identity Managerのクライアントを構築する場合や、サード・パーティ製品をOracle Identity Managerプラットフォームに統合する場合に使用できます。

この章では、次の内容を説明します。

- Oracle Identity Managerサービスへのアクセス

- Oracle Identity Managerサービス

- よく使用されるサービス

- Oracle Identity Manager用クライアントの開発

- 従来のOracle Identity Manager APIの使用

- コード例

31.1 Oracle Identity Managerサービスへのアクセス

Oracle Identity Managerサービスへのエントリ・ポイントは、oracle.iam.platform.OIMClientクラスです。以前のリリースで使用されていたThor.API.tcUtilityFactoryもサポートされます。Oracle Identity Managerと統合するためのクライアントの開発には、oracle.iam.platform.OIMClientを使用することをお薦めします。

この項の内容は次のとおりです。

- OIMClientの使用

- tcUtilityFactoryの使用

31.1.1 OIMClientの使用

OIMClientは、Oracle Identity Managerで使用可能なサービスにアクセスするためのエントリ・ポイントです。OIMClientを使用するには、次の手順を実行します。

1. Oracle Identity Managerアプリケーションへの接続に必要な環境情報を持つOIMClientのインスタンスを作成します。

Hashtable env = new Hashtable();

env.put(OIMClient.JAVA_NAMING_FACTORY_INITIAL, "weblogic.jndi.WLInitialContextFactory");
env.put(OIMClient.JAVA_NAMING_PROVIDER_URL, http://OIM_HOSTNAME:OIM_PORT);
OIMClient oimClient = new OIMClient(env);

ここで、OIM_HOSTNAMEをOracle Identity Managerがデプロイされているホスト名に、OIM_PORTをポート番号に置き換えます。

2. 適切な資格証明を使用してOracle Identity Managerにログインします。

oimClient.login(OIM_USERNAME, OIM_PASSWORD);

3. サービスを参照します。

UserManager usermgr = oimClient.getService(UserManager.class);
OR
tcLookupOperationsIntf lookupIntf = oimClient.getService(tcLookupOperationsIntf.class);

4. サービスでメソッドをコールします。

HashMap userAttributes = new HashMap();
……………..
UserManagerResult result = userMgr.create(new User(null, userAttributes));

31.1.2 tcUtilityFactoryの使用

Oracle Identity Managerの以前のリリースでは、Oracle Identity Managerサービス(従来のリリースではユーティリティと呼ばれていたもの)へのアクセスでtcUtilityFactoryがサポートされていました。tcUtilityFactoryは引き続きサポートされます。ただし、前述のとおり、Oracle Identity Manager用のあらゆるクライアント・アプリケーションの作成でOIMClientを使用することをお薦めします。

tcUtilityFactoryを使用するには、次の手順を実行します。

1. ユーザー名やパスワードなどの環境情報を持つtcUtilityFactoryのインスタンスを作成します。

tcUtilityFactory ioUtilityFactory = new tcUtilityFactory(env, "OIM_USERNAME", "OIM_PASSWORD");

2. ユーティリティの完全修飾名を指定して、ユーティリティまたはサービスを参照します。

tcUserOperationsIntf moUserUtility = (tcUserOperationsIntf)ioUtilityFactory.getUtility("Thor.API.Operations.tcUserOperationsIntf");

3. ユーティリティで次の操作を実行します。

Hashtable mhSearchCriteria = new Hashtable();
mhSearchCriteria.put("Users.First Name", psFirstName);
tcResultSet moResultSet = moUserUtility.findUsers(mhSearchCriteria);

31.2 Oracle Identity Managerサービス

Oracle Identity Manager APIを使用して、Oracle Identity Managerで使用可能なサービスにアクセスできます。Oracle Identity Manager 11gリリース1 (11.1.1)のAPIと従来のAPIとでは使用されている表記規則が異なるため、この項ではこれらについて次の各トピックで個別に説明します。

- Oracle Identity Manager 11gのサービス

- 従来のサービスまたはユーティリティ

31.2.1 Oracle Identity Manager 11gのサービス

Oracle Identity Manager 11g以降のサービスでは、次の表記規則に従います。

- パッケージ名: サービスは、名前がapiで終わるパッケージに含まれます。次に例を示します。

oracle.iam.request.api
oracle.iam.identity.usermgmt.api

- サービス・インタフェース名: 11gで導入されたサービスは通常、*Serviceというネーミング規則を使用します。次に例を示します。

oracle.iam.request.api.RequestService
oracle.iam.selfservice.self.selfmgmt.api.AuthenticatedSelfService

一部のアイデンティティ管理APIでは、APIに*Managerというネーミング規則を使用します。次に例を示します。

oracle.iam.identity.usermgmt.api.UserManager

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)で導入された新しいサービスの一部は次のとおりです。

oracle.iam.api.OIMService
oracle.iam.platform.authopss.api.AuthorizationService
oracle.iam.provisioning.api.ProvisioningService
oracle.iam.provisioning.api.ApplicationInstanceService

31.2.2 従来のサービスまたはユーティリティ

ユーティリティとも呼ばれる従来のサービスでは、次のネーミング規則に従います。

- パッケージ名: 従来のAPIはすべてThor.API.Operationsパッケージに含まれます。

- サービス・インタフェース名: サービス名の形式は、*Intfです。たとえば、Thor.API.Operations.tcImportOperationsIntfとなります。

関連項目:

Oracle Identity Managerで使用可能な全サービスのリストは、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。前述のネーミング規則を使用して、APIを検索できます。

31.3 よく使用されるサービス

表31-1に、Oracle Identity Managerでよく使用されるサービスの一部を示します。

表31-1 よく使用されるサービス

サービス名

説明

UserManager

ユーザーの作成、検索、変更、削除などのユーザー管理操作を提供します。

RequestService

リクエストの発行、取消し、クローズおよび検索操作を提供します。

RoleManager

ロールの作成、検索、変更、削除などのロール管理操作を提供します。このサービスでは、ロール・メンバーおよびロール間の関係の管理操作も提供されます。

OrganizationManager

組織の作成、検索、変更、削除、有効化、無効化などの組織管理操作を提供します。

oracle.iam.api.OIMService

Oracle Identity Managerで操作を実行するメソッドを提供します。このサービスのAPIのコール中に、目的を渡すことができます。ここでの目的とは、リクエストまたは指示です。

31.3.1 従来のサービスと新規サービス間のマッピング

Oracle Identity Managerでは、従来のAPIの一部が新規アーキテクチャを使用して再作成されており、対応するユーティリティ・サービスまたはインタフェース・クラスが変更されています。表31-2に、従来のインタフェースと新規インタフェース間の対応の概要を示します。

表31-2 従来のサービスと新規サービス間のマッピング

従来のサービス

新規サービス

Thor.API.Operations.tcUserOperationsIntf

oracle.iam.identity.usermgmt.api.UserManager

Thor.API.Operations.tcGroupOperationsIntf

注意: 管理を追加および削除するためのグループ・マネージャAPI関連のすべての委任管理APIは非推奨になりました。

oracle.iam.identity.rolemgmt.api.RoleManager

Thor.API.Operations.tcOrganizationOperationsIntf

oracle.iam.identity.orgmgmt.api.OrganizationManager

Thor.API.Operations.tcRequestOperationsIntf

oracle.iam.request.api.RequestService

Thor.API.Operations.tcSchedulerOperationsIntf

oracle.iam.scheduler.api.SchedulerService

Thor.API.Operations.tcEmailOperationsIntf

oracle.iam.notification.api.NotificationService

31.4 Oracle Identity Manager用クライアントの開発

この項の内容は次のとおりです。

- クライアント開発の前提条件

- 設定と構成

31.4.1 クライアント開発の前提条件

Oracle Identity Manager用クライアントを開発するには、次の前提条件を満たしている必要があります。

- Java Development Kit (JDK) 1.6がインストールされており、パス内に設定されていること

- ANT 1.7がインストールされており、パス内に設定されていること

31.4.2 設定と構成

Oracle Identity Managerパッケージには、クライアントの開発に必要なライブラリと構成ファイルを含むZIPファイルが含まれています。

Oracle Identity Manager用のアプリケーション・クライアントを実行するには、次の手順を実行します。

1. OIM_ORACLE_HOME/server/client/oimclient.zipを、クライアントを開発するコンピュータ(oimclient/ディレクトリなど)にコピーします。このドキュメントでは、このディレクトリをOIM_CLIENT_HOMEと呼びます。ZIPファイルを解凍します。oimclient.zipファイルは、conf、lib、およびoimclient.jarで構成されています。

2. アプリケーション・サーバー固有のクライアント・ライブラリをOIM_CLIENT_HOME/lib/ディレクトリにコピーします。Oracle WebLogic Serverでは、wlfullclient.jarがクライアント・ライブラリです。これは、MIDDLEWARE_HOME/WL_HOME/server/lib/ディレクトリ(たとえば、/scratch/beahome/wlserver_10.3/server/lib/)に作成されます。wlfullclient.jarが存在するかどうかを確認します。存在しない場合は、jarbuilderツールを使用して生成する必要があります。wlfullclient.jarの生成方法は、Oracle WebLogic Serverのドキュメントを参照してください。

3. 次のシステム・プロパティを実行中のAPIクライアントに渡します。

- java.security.auth.login.config=OIM_CLIENT_HOME/conf/authwl.conf

- APPSERVER_TYPE=wls

4. クラス・パスに次のjarがあることを確認します。

- commons-logging.jar

- spring.jar

- oimclient.jar

- wlfullclient.jar

- jrf-api.jar

31.5 従来のOracle Identity Manager APIの使用

この項の内容は次のとおりです。

- 結果セット・オブジェクトの使用方法

- Oracle Identity Manager例外の処理

- クリーンアップ

31.5.1 結果セット・オブジェクトの使用方法

従来のOracle Identity Manager APIでは、多くの場合tcResultSetインタフェースを使用します。Thor.API.tcResultSetインタフェースは、データベースから取得したレコードを格納するデータ構造です。データセットを戻す必要のあるOracle Identity Manager APIのメソッドでは、結果セットが使用されます。この結果セットは、列が属性に対応し、行がエンティティに対応する2次元データ構造です。たとえば、ユーザーを検索するメソッドにより戻される結果セットの場合、各行が1人のユーザーに関するデータを表し、行内の各列がそのユーザーの属性を表します。

付属する様々なメソッドを使用して、結果セット内をスクロールし、特定の属性に対応する個々のエントリを取得できます。結果セット内の特定の行を検索するには、行番号をパラメータとしてgoToRow()メソッドを使用します。行から列の値を取得するには、getStringValue()などの適切なアクセッサ・メソッドを使用します。特定の列から値を取得するには、列名をパラメータとしてアクセッサ・メソッドに渡します。列名は、Oracle Identity Managerメタデータ・システムで定義されている説明的なコードです。

次の表に、サンプル・メタデータ値の一部を示します。このマッピングは参照コードに基づいており、Design Consoleで「参照定義」フォームを使用して参照できます。

列コード

説明

IT Resources.Name

ITリソースの名前

Process Definition.Name

プロビジョニング・プロセスの名前

注意:

既存のレコードを更新する際に必要となるため、取得した結果セット・オブジェクトの状況を常に把握してください。

結果セットの使用方法の例を次に示します。この例では、findAllUsers()メソッドをコールして結果セットを取得します。このメソッドでは、特定の基準に一致するユーザーをすべて検出します。

tcResultSet moResultSet = moUserUtility.findAllUsers(mhAttribs);

findAllUsers()メソッドでレコードが戻されたかどうかをチェックするには、次のようにisEmpty()メソッドを使用します。

boolean mbEmpty = moResultSet.isEmpty();

検出されたレコード数を取得するには、getRowCount()メソッドを使用します。レコードが見つからない場合、このメソッドは0を返します。次に、例を示します。

int mnNumRec = moResultSet.getRowCount();

システム内の特定のレコードを選択するには、次のようにgoToRow()メソッドを使用します。

moResultSet.goToRow(5);

現在の行から属性値を取得するには、次のように適切なアクセッサ・メソッドを使用します。

String msUserLastName = moResultSet.getStringValue("Users.Last Name");

31.5.2 Oracle Identity Manager例外の処理

APIのメソッドでは、Oracle定義のJava例外がスローされます。捕捉した例外オブジェクトでgetMessage()メソッドを使用するかわりに、isMessage内部変数にアクセスして例外メッセージを取得できます。

31.5.3 クリーンアップ

tcUtilityFactoryクラスによって、ユーティリティまたはファクトリ・インスタンスで使用されるすべてのリソースが管理され、使用後のリソースを解放する手段が提供されます。

ユーティリティ・クラス・インスタンスを取得し、このユーティリティ・クラスに関連付けられているリソースを解放するために、tcUtilityFactoryをインスタンス化して使用する場合は、ファクトリ・クラスでclose(utility Object)メソッドをコールします。セッションが終了している場合は、ファクトリ・インスタンスでclose()メソッドをコールして、すべてのユーティリティ・クラス、セッション・オブジェクトおよびデータベース・オブジェクトを解放します。

静的コールを使用してユーティリティ・クラスを直接取得した場合は、ユーティリティ・オブジェクトが不要になった後に、そのユーティリティ・オブジェクトのclose(object)メソッドをコールします。

31.6 コード例

例31-1に、Oracle Identity Manager情報の取得方法を示します。この例では、ファクトリ・クラスのインスタンスが作成されます。次に、個々のユーティリティ・クラスを取得し、それらを使用してOracle Identity Managerの情報を取得するために、インスタンスが複数回コールされます。

例31-1 Oracle Identity Manager情報の取得

/*
This class is intented to showcase some of OIM API's. These API's are
specific to OIM 11g release. As an example, Legacy API's usage for
Organization is also shown.
*/

package oracle.iam.samples;

// Role related API's
import oracle.iam.identity.rolemgmt.api.RoleManager;
import oracle.iam.identity.rolemgmt.vo.Role;
import oracle.iam.identity.exception.RoleSearchException;
import oracle.iam.identity.rolemgmt.api.RoleManagerConstants.RoleAttributeName;
import oracle.iam.identity.rolemgmt.api.RoleManagerConstants.RoleCategoryAttributeName;

// User related API's
import oracle.iam.identity.usermgmt.api.UserManager;
import oracle.iam.identity.usermgmt.vo.User;
import oracle.iam.identity.exception.UserSearchException;
import oracle.iam.identity.usermgmt.api.UserManagerConstants.AttributeName;

// Organization Legacy API's
import Thor.API.Operations.tcOrganizationOperationsIntf;
import Thor.API.tcResultSet;
import Thor.API.Exceptions.tcAPIException;
import Thor.API.Exceptions.tcColumnNotFoundException;
import Thor.API.Exceptions.tcOrganizationNotFoundException;

import oracle.iam.platform.OIMClient;
import oracle.iam.platform.authz.exception.AccessDeniedException;
import oracle.iam.platform.entitymgr.vo.SearchCriteria;

import java.util.*;

import javax.naming.NamingException;
import javax.security.auth.login.LoginException;

public class Sample {

private static OIMClient oimClient;

/*
* Initialize the context and login with client supplied environment
*/
public void init() throws LoginException {
System.out.println("Creating client....");
String ctxFactory = "weblogic.jndi.WLInitialContextFactory";
String serverURL = "t3://OIM_HOSTNAME:OIM_PORT";
String username = "xelsysadm";
String password = "xelsysadm";
Hashtable env = new Hashtable();
env.put(OIMClient.JAVA_NAMING_FACTORY_INITIAL,ctxFactory);
env.put(OIMClient.JAVA_NAMING_PROVIDER_URL, serverURL);

oimClient = new OIMClient(env);
System.out.println("Logging in");
oimClient.login(username, password);
System.out.println("Log in successful");
}

/**
* Retrieves User login based on the first name using OIM 11g
* UserManager service API.
*/
public List getUserLogin(String psFirstName) {
Vector mvUsers = new Vector();
UserManager userService = oimClient.getService(UserManager.class);
Set<String> retAttrs = new HashSet<String>();

// Attributes that should be returned as part of the search.
// Retrieve "User Login" attribute of the User.
// Note: Additional attributes can be specified in a
// similar fashion.
retAttrs.add(AttributeName.USER_LOGIN.getId());

// Construct a search criteria. This search criteria states
// "Find User(s) whose 'First Name' equals 'psFirstName'".
SearchCriteria criteria;
criteria = new SearchCriteria(AttributeName.FIRSTNAME.getId(), psFirstName, SearchCriteria.Operator.EQUAL);
try {
// Use 'search' method of UserManager API to retrieve
// records that match the search criteria. The return
// object is of type User.
List<User> users = userService.search(criteria, retAttrs, null);

for (int i = 0; i < users.size(); i++) {
//Print User First Name and Login ID
System.out.println("First Name : " + psFirstName + "  --  Login ID : " + users.get(i).getLogin());
mvUsers.add(users.get(i).getLogin());
}
} catch (AccessDeniedException ade) {
// handle exception
} catch (UserSearchException use) {
// handle exception
}
return mvUsers;
}

/**
* Retrieves the administrators of an Organization based on the
* Organization name. This is Legacy service API usage.
*/
public List getAdministratorsOfOrganization(String psOrganizationName) {
Vector mvOrganizations = new Vector();
tcOrganizationOperationsIntf moOrganizationUtility = oimClient.getService(tcOrganizationOperationsIntf.class);
Hashtable mhSearchCriteria = new Hashtable();
mhSearchCriteria.put("Organizations.Organization Name", psOrganizationName);
try {
tcResultSet moResultSet = moOrganizationUtility.findOrganizations(mhSearchCriteria);
tcResultSet moAdmins;
for (int i = 0; i < moResultSet.getRowCount(); i++) {
moResultSet.goToRow(i);
moAdmins = moOrganizationUtility.getAdministrators(moResultSet.getLongValue("Organizations.Key"));
mvOrganizations.add(moAdmins.getStringValue("Groups.Group Name"));
System.out.println("Organization Admin Name : " + moAdmins.getStringValue("Groups.Group Name"));
}
} catch (tcAPIException tce) {
// handle exception
} catch (tcColumnNotFoundException cnfe) {
// handle exception
} catch (tcOrganizationNotFoundException onfe) {
// handle exception
}
return mvOrganizations;
}

/**
* Retrieves Role Display Name based on Role name and Role Category
* using OIM 11g RoleManager service API. This example shows how
* to construct compound search criteria.
*/
public List getRoleDisplayName(String roleName, String roleCategory ) {
Vector mvRoles = new Vector();
RoleManager roleService = oimClient.getService(RoleManager.class);
Set<String> retAttrs = new HashSet<String>();

// Attributes that should be returned as part of the search.
// Retrieve the "Role Display Name" attribute of a Role.
// Note: Additional attributes can be specified in a
// similar fashion.
retAttrs.add(RoleAttributeName.DISPLAY_NAME.getId());

// Construct the first search criteria. This search criteria
// states "Find Role(s) whose 'Name' equals 'roleName'".
SearchCriteria criteria1;
criteria1 = new SearchCriteria(RoleAttributeName.NAME.getId(), roleName, SearchCriteria.Operator.EQUAL);

// Construct the second search criteria. This search criteria
// states "Find Role(s) whose 'category' equals 'roleCategory'".
SearchCriteria criteria2;
criteria2 = new SearchCriteria(RoleCategoryAttributeName.NAME.getId(), roleCategory, SearchCriteria.Operator.EQUAL);

// Construct the compound search criteria using 'criteria1' and
// 'criteria2' as arguments. This showcases how to construct
// compound search criterias.
SearchCriteria criteria = new SearchCriteria(criteria1, criteria2, SearchCriteria.Operator.AND);
try {
// Use 'search' method of RoleManager API to retrieve
// records that match the search criteria. The return
// object is of type Role.
List<Role> roles = roleService.search(criteria, retAttrs, null);

for (int i = 0; i < roles.size(); i++) {
//Print Role Display Name
System.out.println("Role Display Name : " +
roles.get(i).getDisplayName());
mvRoles.add(roles.get(i).getDisplayName());
}
} catch (AccessDeniedException ade) {
// handle exception
} catch (RoleSearchException use) {
// handle exception
}
return mvRoles;
}

// Main method invocation
// Following assumptions are made
//1. A User "Joe Doe" already exists in OIM
//2. An Organization  "Example Organization" already exists in OIM
//3. A Role "Foobar" already exists in OIM
public static void main(String args[]) {
List moList = null;

try {
Sample oimSample = new Sample();

// initialize resources
oimSample.init();
// retrieve User logins with first name 'Joe'
moList=oimSample.getUserLogin("Joe");
// retrieve User logins with first names starting with 'J'
moList=oimSample.getUserLogin("J*");
// retrieve the administrators of an Organization with name
// 'Example Organization'
moList=oimSample.getAdministratorsOfOrganization(
"Example Organization");
// retrieve Role display name with role name 'FooBar'
// and role category as 'Defaut'
moList=oimSample.getRoleDisplayName("foobar", "Default");
// release resources
oimClient.logout();
} catch (Exception e) {
e.printStackTrace();
}
}
}

次に、サンプルの出力を示します。

[java] Creating client....
[java] Logging in
[java] Log in successful
[java] First Name : Joe  --  Login ID : JDOE
[java] First Name : J*  --  Login ID : JHOND
[java] First Name : J*  --  Login ID : JDOE
[java] Organization Admin Name : SYSTEM ADMINISTRATORS
[java] Role Display Name : foobar

32 SPMLサービスの使用

Oracle Identity Managerでは、クライアント・アプリケーションに対して、Service Provisioning Markup Language (SPML)を使用するアイデンティティ管理サービスを提供します。

この章では、Oracle Identity ManagerでサポートされるSPML XSD Webサービス・インタフェースについて説明します。内容は次のとおりです。

- 概要

- 一般的な考慮事項

- アイデンティティの作成(SPMLコア・サービス: addRequest)

- ユーザー、ロール、属性およびロール・メンバーシップの変更(SPMLコア・サービス: modifyRequest)

- アイデンティティまたはロールの削除(SPMLコア・サービス: deleteRequest)

- リクエスト・ステータスの確認(SPMLコア・サービス: statusRequest)

- 使用可能なターゲットのリスト(SPMLコア・サービス: listTargets)

- ユーザーの無効化(SPML一時停止サービス: suspendRequest)

- ユーザーの有効化(SPML一時停止サービス: resumeRequest)

- ユーザーがアクティブであるかどうかの確認(SPML一時停止サービス: activeRequest)

- ユーザー名の検証(SPMLユーザー名サービス: validateUsername)

- ユーザー名の取得(SPMLユーザー名: suggestUsername)

- アイデンティティまたはロールの参照(SPMLコア・サービス: lookupRequest)

- パスワードのリセット(SPMLコア・サービス: resetPasswordRequest)

- ユーザー名ポリシーの参照(SPMLユーザー名サービス: lookupUsernamePolicy)

- リクエストの取消し(SPML非同期サービス: cancelRequest)

- バッチ・リクエスト(SPMLバッチ・リクエスト・サービス: batchRequest)

- SPML Webサービスの保護

- サポートされていない操作

- SPML属性とLDAPマッピング、およびOracle Identity Managerの属性

- SPMLの例

32.1 概要

この項では、Oracle Identity ManagerでのXSDプロファイルを使用したSPMLサービスの使用について説明します。

32.1.1 SPMLの相互作用について

Oracle Identity Managerでは、クライアント・アプリケーションでアイデンティティ(ユーザーおよびロール)を管理できるようにする、アイデンティティ管理サービスを提供します。このサービスでは、ユーザー、リソースおよびサービス・プロビジョニング情報の交換のための、OASIS委員会の仕様に基づくXMLフレームワークである、Service Provisioning Markup Language (SPML)が使用されます。

このドキュメントでは、Oracle Identity ManagerでサポートされるSPMLの相互作用をリストおよび説明します。

プロファイル・サポート

SPMLには、XSDプロファイルとDSMLプロファイルの2つのプロファイルがあります。このリリースのOracle Identity Managerでは、XSDプロファイルを使用します。

相互作用のタイプ

SPML仕様では、同期または非同期の相互作用が可能です。

Oracle Identity Managerでは、リクエストの追加、変更、削除、参照、一時停止および再開のための非同期相互作用のみがサポートされています。ユーザー名サービスの場合、すべてのサービスが同期となります。参照は、同期方式でのユーザーおよびロールに対してサポートされており、エンティティ・キー、一意ユーザー/ロール名、LDAP GUIDおよびLDAP DNを使用して実行できます。このうちLDAP GUIDとLDAP DNは、LDAP同期が有効な場合に適用できます。Oracle Identity Managerが保留のステータスで即時に応答し、リクエスタがstatusRequestを発行して現在の状態を取得します。

検索API

アイデンティティ管理レルムの検索APIについては、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスのOracle Identity Management APIを参照してください。

32.1.2 統合インタフェース

統合インタフェースは、Service Provisioning Markup Language (SPML)の観点から定義されています。Oracle Identity Managerでは、SPMLの実装によって、アイデンティティとロールの管理およびユーザー名の予約機能がサポートされています。

非同期と同期の両方の実行モードがサポートされていますが、すべてのサービスで両方のモードがサポートされているわけではありません。リクエストで無効なモードが指定されていると、サービスは、unsupportedExecutionMode SPMLエラー・コードを戻します。

SPMLサービスを使用するには、アプリケーションでWebサービス・クライアントを作成する必要があります。このクライアントのWSDLは、次のURLから入手可能です。

http://OIM_HOST:OIM_PORT/spml-xsd/SPMLService?WSDL

別の方法として、ホストされたSPML WebサービスのエンドポイントURLを使用して、WSDLおよびXMLのスキーマ定義に移動することもできます。

XSD (oracle_common_pso.xsd)は、$OIM_HOME/features/spml-xsd.jarから入手可能です。

32.2 一般的な考慮事項

次を実行して、SPMLがOracle Identity Managerと連動することを確認します。

- ユーザーへのSPML管理者ロールの割当て

- 自動承認ポリシーの作成

32.2.1 ユーザーへのSPML管理者ロールの割当て

Oracle Identity Managerでは、SPMLの管理ロールが提供されます。この管理ロールを持つユーザーは、すべてのユースケースのSPMLリクエストを実行できます。SPML管理ロールの名前は、SPML管理者です。

SPML管理者の管理ロールには、次の権限があります。

- リクエストを介したユーザーの作成、変更および削除

- すべての属性でのユーザーの検索

- リクエストを介したユーザー・ステータスの有効化

- リクエストを介したユーザー・ステータスの無効化

- リクエストを介したロール・メンバーシップの追加

- リクエストを介したロール・メンバーシップの削除

- すべての属性でのロールの検索

- リクエストを介したロールの作成、変更および削除

SPML管理者の管理ロールは、最上位組織に公開されるグローバル管理ロールです。そのため、最上位組織のシステム管理者または組織管理者のみが、最上位組織のスコープ内で任意のユーザーにこの管理ロールを割り当てることができます。

Oracle Identity Managerの新しいデプロイメントの場合、デフォルトではSPML管理者の管理ロールはどのユーザーにも割り当てられません。したがって、最上位組織のシステム管理者または組織管理者は、関連するユーザーにこのロールを手動で割り当てる必要があります。また、「階層を含める」または「下位組織を含める」オプションを有効にして、最上位組織のスコープ内でSPML管理者の管理ロールを割り当てることもできます。その結果、SPML管理者の管理ロールのすべての権限が、Oracle Identity Managerのすべての組織を対象として、ユーザーに割り当てられます。

注意:

Oracle Identity Managerのデプロイメントをアップグレードした場合は、SPML管理者の管理ロールを割り当てるために既存のSPMLユーザーがアップグレードされるため、これらのユーザーは引き続きSPMLリクエストを実行できます。

ユーザーにSPML管理者の管理ロールを割り当てるには、次の手順を実行します。

1. Oracle Identity Self Serviceにログインします。SPML管理者の管理ロールを新しいユーザーに割り当てる場合は、そのユーザーを作成します。

2. 最上位組織を開いて「管理ロール」タブをクリックします。

3. SPML管理者の管理ロールを選択し、ユーザーにこのロールを割り当てます。

4. 新たに追加したメンバーシップを変更して「下位組織を含める」オプションを選択し、「適用」をクリックします。

32.2.2 自動承認ポリシーの作成

SPMLリクエストが自動承認されるようにするには、自動承認ポリシー・ルールが必要です。Oracle Identity Manager 11gリリース2 (11.1.2.1.0)には、リクエスト・テンプレートがありません。そのため、各SPMLユーザーに対し、システム管理者が手動で自動承認ポリシー・ルールを作成する必要があります。

作成する自動承認ポリシーはユーザー・ログインに基づくことができ、各ポリシーの承認プロセス構成は「自動承認」として選択する必要があります。各SPML操作(ユーザーの作成、ユーザーの変更、ロールの作成など)に対してSPMLユーザーが要求するすべてのSPMLリクエストがリクエスト・レベルおよび操作レベルで承認されるように、これらの操作ごとに自動承認ポリシーを作成する必要があります。

注意:

ロールの作成、ロールの変更、ロールの削除操作には、リクエスト・レベルの承認ポリシーのみが必要です。

自動承認ポリシー・ルールを作成するには、次の手順を実行します。

1. 次に対して新しい自動承認ポリシー・ルールを作成します。

- ユーザーの作成(リクエスト・レベル)

- ユーザーの作成(操作レベル)

- ユーザーの変更(リクエスト・レベル)

- ユーザーの変更(操作レベル)

- ユーザーの削除(リクエスト・レベル)

- ユーザーの削除(操作レベル)

- ユーザーの有効化(リクエスト・レベル)

- ユーザーの有効化(操作レベル)

- ユーザーの無効化(リクエスト・レベル)

- ユーザーの無効化(操作レベル)

- ロールの割当て(リクエスト・レベル)

- ロールの割当て(操作レベル)

- ロールの削除(リクエスト・レベル)

- ロールの削除(操作レベル)

- ロールの作成(リクエスト・レベル)

- ロールの変更(リクエスト・レベル)

- ロールの削除(リクエスト・レベル)

2. ユーザー・ログインに基づいて各ポリシーのルールを作成します。ユーザー・ログインの評価で大/小文字が区別されることを確認してください。図32-1に、サンプル・ルールを示します。

図32-1 承認ポリシー・ルールのサンプル

注意:

ユーザー・ログインに基づき、SPMLユーザーに対して作成された自動承認ポリシーでは、リクエストがSPML、UIまたはその他のフローを介して要求されているかに関係なく、ユーザーが要求したすべてのリクエストが自動承認されます。

32.3 アイデンティティの作成(SPMLコア・サービス: addRequest)

ユーザー属性またはロール属性を使用してアイデンティティを作成するには、非同期実行モードがサポートされているaddRequest操作を実装します。リクエスト送信が正常に行われると、リクエスト送信トラッキングIDが戻され、リクエスト・ステータスが保留としてリストされます。

ユーザーを作成するときに、addRequest操作を使用して、ロール・メンバーシップをそのユーザーに割り当てることもできます。そのためには、typeOfReferenceがmemberOfに設定されたSPML参照機能を使用してロールGUIDをPSO参照IDとして組み込む必要があります。

注意:

- ユーザー名属性またはパスワード属性が指定されていない場合、適切なプラグインがインストールされていると、これらの属性をOracle Identity Managerで自動生成できます。

- パスワードを指定してユーザーを作成する場合、SPMLユーザー作成ペイロード内にユーザー・パスワードをBase64エンコード・フォーマットで指定します。例:

<pso:password>
<pso:value>V2VsY29tZTc=</pso:value>
</pso:password>

文字列にBase64でエンコードされた値を取得するには、任意の標準Javaライブラリを使用できます。そのようなライブラリの例が次のApache Commonsライブラリです。 - org.apache.commons.codec.binary.Base64. encodeBase64("PASSWORD".getBytes())

- SPML管理者ロールを持つユーザーによって作成されたロールは、最上位組織とそのサブ組織に自動公開されます。

表32-1に、addRequest操作によるアイデンティティ作成の機能を示します。

表32-1 addRequestによるアイデンティティ作成

項目/機能

説明

SPML実行モード

非同期のみ。

入力

[SPMLv2]で定義されたaddRequest要素。

オプション(ロール・メンバーシップの参照機能)。

出力

[SPMLv2]で定義されたaddResponse要素。

処理

追加操作を使用して、アイデンティティを追加できます。必要に応じて、既存のロールをアイデンティティに割り当てる場合があります。

customError SPMLカスタム・エラー・コードを使用すると、ランタイム・エラーが報告されます。レスポンスでは、検証エラーのみが戻されます。リクエストIDは戻されません。

例

これらの例については、次の付録を参照してください。

- 「SPMLの例-ユーザーの追加」

- 「SPMLの例-ロール割当てによるユーザーの追加」

32.4 ユーザー、ロール、属性およびロール・メンバーシップの変更(SPMLコア・サービス: modifyRequest)

次のタスクのためのSPML modifyRequestサービスを実装します。

- ロール・メンバーシップの既存のユーザー(アイデンティティ)への割当てまたは既存のユーザーからの取消し

- 既存のロールの変更

- ユーザー属性の変更

表32-2に、modifyRequest操作によるロール・メンバーシップ管理の機能を示します。

表32-2 modifyRequestによるロール・メンバーシップ管理

項目/機能

説明

SPML実行モード

非同期

入力

[SPMLv2]で定義されたmodifyRequest要素。

ロール・メンバーシップを削除するにはmodificationMode="delete"を使用し、ロール・メンバーシップを追加するにはmodificationMode="add"を使用します。

参照機能(typeOfReference="inheritsFrom")およびPSO IDとしてのロールGUIDを使用して宣言されたロール・メンバーシップ。

出力

[SPMLv2]で定義されたmodifyResponse要素。

処理

modifyRequest操作を使用して、既存のアイデンティティまたは既存のロールを変更できます。

この操作では、アイデンティティとロールの両方について、SPML実行モードを確認します。実行モードが無効な場合は、unsupportedExecutionMode SPMLエラー・コードが戻されます。

変更リクエストにアイデンティティPSOオブジェクトが含まれていないか、または無効なGUIDが含まれている場合、この操作により、malformedRequestまたはinvalidIdentifier SPML不正リクエスト・エラーがそれぞれ戻されます。

customError SPMLカスタム・エラー・コードを使用すると、その他のランタイム・エラーが報告されます。

例

これらの例については、次の付録を参照してください。

- 「SPMLの例 - ロール・メンバーシップの割当て」

- 「SPMLの例 - ロール・メンバーシップの失効」

32.5 アイデンティティまたはロールの削除(SPMLコア・サービス: deleteRequest)

表32-3の説明に従って、SPML deleteRequestサービスを実装し、既存のロールまたはユーザーを削除します。

表32-3 deleteRequestによるロール・メンバーシップの削除

項目/機能

説明

SPML実行モード

非同期

入力

[SPMLv2]で定義されたdeleteRequest要素。

出力

[SPMLv2]で定義されたdeleteResponse要素。

処理

deleteRequest操作を使用して、既存のアイデンティティまたは既存のロールを削除できます。

この操作では、アイデンティティとロールの両方について、SPML実行モードを確認します。実行モードが無効な場合は、unsupportedExecutionMode SPMLエラー・コードが戻されます。

削除リクエストにアイデンティティPSOオブジェクトが含まれていないか、または無効なGUIDが含まれている場合、この操作により、malformedRequestまたはinvalidIdentifier SPML不正リクエスト・エラーがそれぞれ戻されます。

customError SPMLカスタム・エラー・コードを使用すると、その他のランタイム・エラーが報告されます。

例

「SPMLの例-ロールの削除」の例を参照してください。

32.6 リクエスト・ステータスの確認(SPMLコア・サービス: statusRequest)

ステータス操作を使用すると、リクエスタは、非同期操作が次のステータスであるかどうかを確認できます。

- 失敗

- 保留

- 正常終了

非同期操作の場合、リクエストが送信されると、検証エラー後のエラーをレスポンスで戻すことができません。発生したエラーはステータス・レスポンスで戻されます。statusRequestによってリクエスト・ステータスが失敗として戻される場合、statusResponseによってエラー・メッセージも表示されます。

表32-4に、statusRequest操作の機能を示します。

表32-4 リクエスト・ステータスの確認

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたstatusRequest要素。

出力

[SPMLv2]で定義されたstatusResponse要素。

処理

ステータス操作では、非同期操作の識別子を含む属性asyncRequestIDが使用されます。

操作識別子が無効な場合、noSuchIdentifierエラー・コードが戻されます。

ステータス操作の結果は、statusResponse要素のステータス属性に指定されます。

例

「SPMLの例 - ステータス・リクエスト」の例を参照してください。

32.7 使用可能なターゲットのリスト(SPMLコア・サービス: listTargets)

SPML listTargetsサービスを使用すると、リクエスタは、プロバイダがプロビジョニングに使用できる一連のターゲットを取得できます。サービスによって、次のものも戻されます。

- 各ターゲットでサポートされているオブジェクト・タイプ

- 各ターゲットのそれぞれのオブジェクトに対してプロバイダでサポートされている一連の機能

現在サポートされているターゲットはOracle Identity Managerのみであり、サポートされているオブジェクト・タイプはOracle Identity Managerのすべてのオブジェクト・タイプです。

表32-5に、listTargetsによるターゲットの取得の機能を示します。

表32-5 listTargetsによるターゲットの取得

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたlistTargetsRequest要素。

出力

[SPMLv2]で定義されたlistTargetsResponse要素。

処理

XMLスキーマのプロファイルのみがサポートされています。別のプロファイル・リクエストの場合には、unsupportedProfileエラー・コードが表示されて失敗します。

単一で静的なプロビジョニング・ターゲットOracle Identity Managerがサポートされています。

PSOオブジェクト・スキーマ、各PSOに対してサポートされている機能のリストおよび操作データ機能のスキーマをlistTargetsResponse要素に挿入することによって、レスポンスが生成されます。

32.8 ユーザーの無効化(SPML一時停止サービス: suspendRequest)

一時停止操作を使用すると、リクエスタはユーザーを一時停止できます。

表32-6に、suspendRequest操作の機能を示します。

表32-6 suspendRequestによるユーザーの一時停止

項目/機能

説明

SPML実行モード

非同期

入力

[SPMLv2]で定義されたsuspendRequest要素。

出力

[SPMLv2]で定義されたsuspendResponse要素。

処理

この操作には、有効なユーザーPSO IDおよび必要に応じて有効な一時停止日付が必要です。

PSO識別子が無効な場合は、noSuchIdentifierエラー・コードが戻されます。

一時停止操作はユーザーに対してのみ適用できます。PSOオブジェクトがアイデンティティでない場合は、unsupportedOperationエラーが戻されます。

例

「SPMLの例-ユーザーの一時停止」の例を参照してください。

32.9 ユーザーの有効化(SPML一時停止サービス: resumeRequest)

resumeRequest操作を使用すると、リクエスタは一時停止されたユーザーを再開したり有効化できます。

表32-7に、resumeRequest操作の機能を示します。

表32-7 resumeRequestによるユーザーの再有効化

項目/機能

説明

SPML実行モード

非同期

入力

[SPMLv2]で定義されたresumeRequest要素。

出力

[SPMLv2]で定義されたresumeResponse要素。

処理

この操作には、有効なユーザーPSO IDが必要であり、必要に応じて有効な再開日付を指定します。

PSO識別子が無効な場合は、noSuchIdentifierエラー・コードが戻されます。

再開操作はユーザーに対してのみ適用できます。PSOオブジェクトがアイデンティティでない場合は、unsupportedOperationエラーが戻されます。

例

「SPMLの例-ユーザーの再開」の例を参照してください。

32.10 ユーザーがアクティブであるかどうかの確認(SPML一時停止サービス: activeRequest)

activeRequest操作を使用すると、リクエスタは、指定されたユーザーがアクティブであるか、または一時停止されているかを確認できます。

表32-8に、activeRequest操作の機能を示します。

表32-8 activeRequestによるユーザーが一時停止されているかどうかの確認

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたactiveRequest要素。

出力

[SPMLv2]で定義されたactiveResponse要素。

処理

この操作には、有効なユーザーPSO IDが必要です。

PSO識別子が無効な場合は、noSuchIdentifierエラー・コードが戻されます。

リクエストが有効であり、指定されたユーザーが存在する場合、プロバイダはユーザー・ステータスを取得する必要があります。

activeRequest操作はユーザーに対してのみ適用できます。PSOオブジェクトがアイデンティティでない場合は、unsupportedOperationエラーが戻されます。

例

「SPMLの例-ユーザーがアクティブであるかどうかの確認」の例を参照してください。

32.11 ユーザー名の検証(SPMLユーザー名サービス: validateUsername)

validateUsername操作を使用すると、リクエスタは、ユーザー名がすでに存在するか、または予約されているかどうかを確認できます。

表32-9に、resumeRequest操作の機能を示します。

表32-9 resumeRequestによるユーザー名の有効性の確認

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたvalidateUsernameRequest要素。

userNameは受け入れられる唯一の入力パラメータです。

出力

[SPMLv2]で定義されたvalidateUsernameResponse要素。

処理

この操作では、ユーザー名を取得して、このユーザー名が存在しているかどうかを確認します。

処理エラーがSPML customErrorコードとともに報告されます。

例

「SPMLの例-ユーザー名の検証」の例を参照してください。

32.12 ユーザー名の取得(SPMLユーザー名: suggestUsername)

suggestUsername操作を使用すると、リクエスタは、指定されたポリシーに対する有効なユーザー名を取得できます。

表32-10に、suggestUsername操作の機能を示します。

表32-10 suggestUsernameによるユーザー名の取得

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたsuggestUsernameRequest要素。

出力

[SPMLv2]で定義されたsuggestUsernameResponse要素。

処理

この操作では、ユーザー情報を取得し、取得した情報を使用して、適用可能なユーザー名ポリシーに基づいたユーザー名を構成します。

処理エラーがSPML customErrorコードとともに報告されます。

例

「SPMLの例-ユーザー名の提示」の例を参照してください。

32.13 アイデンティティまたはロールの参照(SPMLコア・サービス: lookupRequest)

lookupRequest操作を使用すると、リクエスタは、エンティティ・キー、ユーザー/ロール名、LDAP GUID、LDAP DNのいずれか1つを使用して、システムのユーザーまたはロールを参照できます。このうちLDAP GUIDとLDAP DNは、LDAP同期が有効な環境にのみ適用できます。参照は、同期モードでのみサポートされています。

リクエスタは、returnData属性(デフォルト値はeverything)を使用して、レスポンスのフィルタも選択できます。returnData属性には、次の値を設定できます。

- returnData='identifier': プロバイダは、リクエストされたオブジェクトの識別子のみを返します。

- returnData='data': プロバイダは、リクエストされたオブジェクトの識別子と、そのオブジェクトに関連するすべての属性を返します。

- returnData='everything': プロバイダは、リクエストされたオブジェクトの識別子、そのオブジェクトに関連するすべての属性、リクエストされたオブジェクトに関連する機能データを返します。アイデンティティの参照の場合、機能データにはユーザーが所有する直接ロールまたは間接ロールが含まれます。ロールの参照の場合、機能データには親ロールと、直接子ロールまたは間接子ロールが含まれます。

すべてのユーザーは、SPMLインタフェースを使用して参照を実行できます。認可に基いて、リクエスタはユーザーまたはロールを参照できます。適切な認可権限がない場合は、SPMLレスポンスにエラー・コードが返されます。リクエスタが表示する権限を保持している認可済属性のみ、レスポンスに返されます。

表32-11に、lookupRequest操作の機能を示します。

表32-11 lookupRequestを使用したアイデンティティ/ロールの参照

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたlookupRequest要素

出力

[SPMLv2]で定義されたlookupResponse要素

処理

この操作では、次の形式の有効なユーザーPSO IDが必要です。

psoID ID="ENTITY_TYPE:PSO_ID_TYPE:LOOKUP_VALUE"

説明:

ENTITY_TYPEは、アイデンティティまたはロールです。この値は必須です。

PSO_ID_TYPEは、キー、DN、GUIDまたは名前です。この値はオプションです。

LOOKUP_VALUEは、参照するために有効な値です。この値は必須です。

次に値の例を示します。

psoID ID="identity:key:6"
psoID ID="identity:6"
psoID ID="identity:name:JohnSmith"
psoID ID="identity:dn: cn=john,cn=Users,dc=us,dc=oracle,dc=com"
psoID ID="identity:guid: CEF2C4F20E5BF04DE040F20A9681408D"
psoID ID="role:key:6"
psoID ID="role:6"
psoID ID="role:name:ManagerRole"
psoID ID="role:dn: cn= ManagerRole,cn=Groups,dc=us,dc=oracle,dc=com"
psoID ID="role:guid: CEF2C4F20E5BF04DE040F20A9681408D"

PSO識別子が存在しない場合は、エラー・コードが返されます。リクエストが有効で指定されたユーザー/ロールが存在する場合は、returnData属性に応じて、結果がlookupResponseに返されます。

例

「SPMLの例 - アイデンティティ/ロールの参照」の例を参照してください。

32.14 パスワードのリセット(SPMLコア・サービス: resetPasswordRequest)

resetPasswordRequest操作を使用すると、リクエスタは、ユーザーのパスワードをリセットできます。

表32-12に、resetPasswordRequest操作の機能を示します。

表32-12 resetPasswordRequestを使用したユーザー・パスワードのリセット

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたresetPasswordRequest要素

エンド・ユーザーの電子メール通知を制御するためのオプションの通知データ

出力

[SPMLv2]で定義されたresetPasswordRequest要素

処理

ユーザー・キーまたはユーザーGUIDを入力として受け取り、ランダムに作成されたパスワードを使用してパスワードをリセットします。

オプションで、通知データは次の入力として送信できます。

- SentNotification: 通知を送信するかどうかを決定するブール・フラグ

- SendNotificationTo: カンマで区切られた電子メール・アドレス

処理エラーがSPML customErrorコードとともに報告されます。

例

次の例を参照してください。

- 「SPMLの例 - パスワードのリセット」

- 「SPMLの例 - 通知を使用したパスワードのリセット」

32.15 ユーザー名ポリシーの参照(SPMLユーザー名サービス: lookupUsernamePolicy)

lookupUsernamePolicy操作を使用すると、リクエスタは、Oracle Identity Managerで構成されたユーザー名ポリシーの詳細を取得できます。リクエストでロケールを指定して、指定のロケールの詳細を取得することもできます。

表32-13に、lookupUsernamePolicy操作の機能を示します。

表32-13 lookupUsernamePolicyを使用したユーザー名ポリシーの詳細の参照

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたlookupUsernamePolicyRequest要素

出力

[SPMLv2]で定義されたlookupUsernamePolicyResponse要素

処理

Oracle Identity Managerで構成されたユーザー名ポリシーに関する情報を返します。

例

「SPMLの例 - ユーザー名ポリシーの参照」の例を参照してください。

32.16 リクエストの取消し(SPML非同期サービス: cancelRequest)

cancelRequest操作を使用すると、リクエスタは、指定されたリクエストIDを取り消すことができます。リクエストが正常に取り消されると、保留中の承認もすべて取り消されます。リクエストを取り消すことができるのは、リクエストを送信したリクエスタのみです。

表32-14に、cancelRequest操作の機能を示します。

表32-14 cancelRequestを使用したリクエストのキャンセル

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたcancelRequest要素

出力

[SPMLv2]で定義されたcancelResponse要素

処理

指定されたリクエストを取り消します。customError SPMLカスタム・エラー・コードを使用して、ランタイム・エラーが報告されます。

例

「SPMLの例 - リクエストのキャンセル」を参照してください。

32.17 バッチ・リクエスト(SPMLバッチ・リクエスト・サービス: batchRequest)

バッチ操作は、個々のリクエストをいくつも組み合せてSPML v2で定義された単一のリクエストにします。単一のリクエストにできる個々のリクエストの例としては、単一リクエストでのユーザーRobert Kleinの作成、ユーザーTerrence Hillの更新、ユーザーJohn Doeの削除およびユーザーJane Doeのパスワードのリセットなどがあります。

バッチ・リクエストは、トランザクション・セマンティクスをサポートしていません。このため、ネステッド・リクエストの障害により完了済のネステッド・リクエストが元に戻されることがあります。個々のレスポンスはそれぞれ、対応する個々のリクエストが<batchRequest>内に配置される<batchResponse>の範囲内の同じ位置に配置されます。

パラレル処理のみ("processing='parallel'")をサポートし、<batchRequest>内で順不同にネステッド・リクエストを実行します。エラー条件が発生すると、「onError='resume'」で指定された後続のサブリクエストの処理を続けます。1つのリクエストの処理が失敗すると、次のリクエストが処理されます。バッチ処理で1つ以上のネステッド・リクエストが失敗すると、正常に行われたリクエストがあっても、「status='failure'」のある<batchResponse>が返されます。

表32-15に、batchRequest操作の機能を示します。

表32-15 batchRequestを使用したバッチ・リクエストの実行

項目/機能

説明

SPML実行モード

同期

入力

[SPMLv2]で定義されたbatchRequest要素

出力

[SPMLv2]で定義されたbatchResponse要素

処理

この操作では、4種類のサブ・リクエスト(アイデンティティのaddRequest、アイデンティティのmodifyRequest、アイデンティティのdeleteRequest、resetPasswordRequest)のみがサポートされいます。

例

「SPMLの例 - バッチ・リクエスト」を参照してください。

32.18 SPML Webサービスの保護

この項では、SPML Webサービスを保護する方法について説明します。内容は次のとおりです。

- Webサービスのセキュリティについて

- リクエストの例

- ポリシーの適用

32.18.1 Webサービスのセキュリティについて

SPML XSD Webサービスでは、Oracle Web Services Security Managerを使用してセキュリティが提供されています。SPML Webサービスは、次のポリシーを使用して保護されています。

注意:

SPML XSDプロファイルのWebサービスをロードできるのは、SPML_App_Roleのメンバーであるユーザーによってのみです。これは、追加されたセキュリティに対してのみ行われます。

Webサービスに対するMBeanの構成の詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。

- SAMLまたはユーザー名トークン・サービス・ポリシー(メッセージ保護付き):

oracle/wss11_username_token_with_message_protection_client_policy

- ユーザー名トークンおよびメッセージ保護セキュリティを使用したFusion Applications環境:

oracle/wss11_username_token_with_message_protection_client_policy

デフォルトのポリシーは、Oracle Enterprise Manager Fusion Middleware Controlを使用して変更できます。

32.18.2 リクエストの例

サンプルのリクエストは次のようになります。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" >
<soap:Header>
<ns1:Security>
<ns1:UsernameToken>
<ns1:Username>weblogic</ns1:Username>
<ns1:Password>weblogic1</ns1:******>
</ns1:UsernameToken>
</ns1:Security>
</soap:Header>
<soap:Body xmlns:ns1="urn:oasis:names:tc:SPML:2:0">
<ns1:listTargetsRequest />
</soap:Body>
</soap:Envelope>

32.18.3 ポリシーの適用

デプロイメント時に、管理者はOracle Enterprise Manager Fusion Middleware Controlコンソールを使用して適切なセキュリティ・ポリシーを適用し、サービスを保護できます。Fusion Middleware Controlの使用の詳細は、次のドキュメントを参照してください。

Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドのセキュリティおよび管理ツールへのアクセスに関する説明

32.19 サポートされていない操作

Oracle Identity Manager 11gリリース2 (11.1.2.1.0)では、XSDプロファイルの一部として次のSPML操作はサポートされていません。

- ユーザーの検索

- ロールの検索

- 組織に対するあらゆる操作(作成、変更、削除または検索など)

32.20 SPML属性とLDAPマッピング、およびOracle Identity Managerの属性

SPML XSD Webサービスは、Oracle Identity Managerをバックエンド・サービスとして使用して、Fusionアプリケーションにプロビジョニング機能を提供します。SPML Webサービスの主要ビルディング・ブロックは、プロビジョニング対象となるオブジェクトを定義するSPML Provisioning Service Object (PSO)です。PSOの例としては、アイデンティティやロールがあげられます。

この付録では、サポートされているPSO属性とそのLDAPマッピングを示し、Oracle Identity Managerの属性における文字制限について説明します。最後に、アプリケーションからSPML Webサービスに渡すことができるその他の操作データについて説明します。この章には次の項目があります。

- アイデンティティのPSO属性

- ロールのPSO属性

- プリファレンス属性

- Oracle Identity Managerの属性における特殊文字制限

- 操作データ

32.20.1 アイデンティティのPSO属性

表32-16に、Oracle Identity ManagerでのSPML実装でサポートされているアイデンティティ属性、およびこれらの属性とLDAPオブジェクト/属性のマッピングを示します。

注意:

「構文」列は、関連する属性プロパティ(型、必須かどうかなど)を示しています。

表32-16 アイデンティティのPSO属性

SPML属性名

構文

説明

LDAPマッピング(Oracle Internet Directory)

ID

文字列、読取り専用、必須、単一

変更リクエストでユーザーを識別するために使用される識別子。

orclUserV2: orclguid

activeEndDate

タイムスタンプ、単一

ユーザーの終了日時。

orclUserV2: orclActiveEndDate

activeStartDate

タイムスタンプ、単一

ユーザーのアクティブ化日時。

orclUserV2: orclActiveStartDate

commonName

文字列、

必須

個人の共通名(通常は、個人のフルネームに同じバリエーションを加えたものです)。

person: cn

countryName

文字列、単一

個人の勤務先の国(2文字の[ISO3166]国コードで表されます)。

orclUserV2: c

departmentNumber

文字列、単一

この個人が所属する組織内の部門コード。数字のみまたは英数字を指定できます。

inetOrgPerson: departmentNumber

description

文字列、単一

個人に関する判読可能な説明。

person: description

displayName

文字列、単一、MLS

個人のエントリを表示するときに使用する優先名。

多言語サポート(MLS)に対応しており、ロケールの言語値(「en」や「fr」など)も指定できます。

inetOrgPerson: displayName

employeeNumber

文字列、単一

個人に割り当てられる数字または英数字の識別子(通常は、入社順や組織との関連に基づきます)。

inetOrgPerson: employeeNumber

employeeType

文字列、単一

従業員のタイプを識別します。有効な値のリストは、表32-17を参照してください。

inetOrgPerson: employeeType

facsimileTelephoneNumber

文字列、単一

個人の業務用FAX端末の電話番号。

organizationalPerson: facsimileTelephoneNumber

generationQualifier

文字列、単一

一般に個人名の接尾辞部となる名前文字列(「III」、「3rd」、「Jr.」など)。

N/A

givenName

文字列、単一

個人名の一部となる名前文字列(姓以外、名など)。

inetOrgPerson: givenName

hireDate

タイムスタンプ、単一

入社日。

orclUserV2: orclHireDate

homePhone

単純、文字列

個人に関連付けられている自宅電話番号。

inetOrgPerson:homePhone

homePostalAddress

単純、文字列

個人の自宅住所。

inetOrgPerson: homePostalAddress

initials

文字列、単一

個人名の一部またはすべて(姓以外)。

inetOrgPerson: initials

localityName

単純、文字列

勤務先の地域や場所の名前(市区町村、郡、その他の地理的地域など)。

N/A

mail

単純、文字列

個人の業務用インターネット・メール・アドレス(メールボックス[RFC2821]形式)。

inetOrgPerson: mail

manager

単純、文字列

個人のマネージャ。

N/A

middleName

文字列、単一

個人のミドル・ネーム。

orclUserV2: middleName

mobile

単純、文字列

個人に関連付けられている携帯電話番号。

inetOrgPerson: mobile

organization

文字列、単一

組織の名前(my_companyなど)。

organization

organizationUnit

文字列、単一

組織内の単位の名前(IT Supportなど)。

organizationalUnitName

pager

単純、文字列

個人の業務用ページャ電話番号。

inetOrgPerson: pager

password

文字列、単一

ユーザーのパスワード。

person: userPassword

postalAddress

文字列、単一

郵便業務で個人にサービスを提供するために使用される勤務先住所。

organizationalPerson: postalAddress

postalCode

文字列、単一

郵便業務で個人の勤務先の郵便ゾーンを識別するために使用されるコード。

organizationalPerson: postalCode

postOfficeBox

文字列、単一

郵便業務で使用される私書箱識別子(カスタマは、郵便局の敷地内で私書箱を通じて郵便物を受け取るように手配することができます)。

organizationalPerson: postOfficeBox

preferredLanguage

文字列、単一

個人の優先文字言語または優先会話言語。これは、国際化対応や人間とコンピュータの対話に役立ちます。この属性タイプの値は、[RFC2068]に定義されたAccept-Languageヘッダー・フィールドの定義に準拠する必要があります(ただし、1つの例外として、シーケンス"Accept-Language" ":"は省略してください)。

inetOrgPerson: preferredLanguage

state

文字列、単一

個人の勤務先の都道府県の完全名。

organizationalPerson: st

street

文字列、単一

個人の勤務先住所の場所情報(つまり、通り名、土地、番地)。

organizationalPerson: street

surname

文字列、単一

個人の姓の名前文字列。

person: sn

telephoneNumber

文字列、単一

個人の勤務先電話番号。

organizationalPerson: telephoneNumber

title

文字列、単一

組織における個人の役職。

organizationalPerson: title

username

文字列、単一

個人に関連付けられているコンピュータ・システム・ログイン名。

uid

userType

文字列、単一

ユーザーのタイプ。この属性は、エンドユーザーにDesign Consoleへのアクセスを提供するために使用します。使用可能な値はtrueとfalseです。

表32-17に、employeeType属性の有効な値を示します。

表32-17 employeeTypeの有効な値

値

意味

Full-Time

フルタイムの従業員

Part-Time

パートタイムの従業員

Temp

Temp

Intern

Intern

Consultant

Consultant

Contractor

Contractor

EMP

従業員

CWK

派遣就業者

NONW

非就業者

OTHER

その他の従業員タイプ

注意:

Oracle Identity Managerによって渡されるのは、「値」列に示すコードのみです。各コードの意味を参考のために記載しています。

32.20.1.1 カスタム・アイデンティティ属性

Oracle Identity Managerの機能をサポートするためのカスタム属性が用意されています。これらの属性は、Oracle Identity Managerに存在し(ユーザー定義のフィールドを追加した場合など)、PSOには存在しません。

マッピングをエンドツーエンドで機能させるには、カスタム属性名を対応するリクエスト・データセットで指定された属性名と一致させる必要があります。

次に、カスタム属性の例をいくつか紹介します。

...
<data>
<pso:identity>
<pso:attributes>
<pso:attr name="Number Format">
<pso:value>#,##0.##[.,]</pso:value>
</pso:attr>
<pso:attr name="Currency">
<pso:value>USD</pso:value>
</pso:attr>
</attributes>
...

32.20.2 ロールのPSO属性

表32-18に、Oracle Identity ManagerでのSPML実装でサポートされているロール属性、およびこれらの属性とLDAPオブジェクト/属性のマッピングを示します。

表32-18 ロールのPSO属性

属性名

構文

説明

ID

文字列、読取り専用、必須、単一

ロールを一意に識別するPSO識別子。通常はディレクトリのGUIDです。

commonName

文字列、必須、MLS

ロールの共通名。

description

単一

ロールに関する判読可能な説明。

displayName

文字列、単一、MLS

ロールのエントリを表示するときに使用する優先名。

32.20.2.1 カスタム・ロール属性

Oracle Identity Managerの機能をサポートするためのカスタム属性が用意されています。これらの属性は、Oracle Identity Managerに存在し、PSOには存在しません。

マッピングをエンドツーエンドで機能させるには、カスタム属性名を対応するリクエスト・データセットで指定された属性名と一致させる必要があります。

次に、カスタム・ロール属性の例を紹介します。

...
<pso:attributes>
<pso:attr name="Role Category Name">
<pso:value>Cat1</pso:value>
</pso:attr>
...

Role Category Nameは特別なカスタム・ロール属性です。これはロールの名前空間です。それぞれのロールがいずれかのロール・カテゴリに属しています。新しいロールの作成時に指定できます。指定しなかった場合は、デフォルトのロール・カテゴリが選択されます。各ロール・カテゴリおよびロール名によってロールが一意に識別されます。

32.20.3 プリファレンス属性

表32-19に、Oracle Identity ManagerでのSPML実装でサポートされているプリファレンス属性を示します。

表32-19 プリファレンス属性

属性名

構文

説明

LDAPマッピング

数値書式

String

数値の表示書式

orclNumberFormat

値は次のとおりです。

#,##0.##[.,]

#,##0.###[\u00A0,]

#,##0.###

#,##0.###;#,##0.###-

#,##0.###[.,]

#,##0.###;(#,##0.###)[.,]

#,##0.##[\u00A0,]

#,##0.###['.]

#,##0.###[',]

通貨

String

通貨に使用する必要がある記号

orclCurrency

値の例は次のとおりです。

USD

YUN

NZD

INR

日付書式

String

日付の表示書式

orclDateFormat

値は次のとおりです。

MM-dd-yyyy

MM-dd-yy

MM.dd.yyyy

MM.dd.yy

MM/dd/yyyy

MM/dd/yy

M-d-yyyy

M-d-yy

M.d.yyyy

M.d.yy

M/d/yyyy

M/d/yy

dd-MM-yyyydd-MM-yy

d-M-yyyy

d-M-yy

dd.MM.yyyy

dd.MM.yy

d.M.yyyy

d.M.yy

dd/MM/yyyy

dd/MM/yy

d/M/yyyy

d/M/yy

yyyy-MM-dd

yy-MM-dd

yyyy-M-d

yy-M-d

yyyy.MM.dd

yy.MM.dd

yyyy.M.d

yy.M.d

yy. M. d

yyyy/MM/dd

yy/MM/dd

yyyy/M/d

yy/M/d

時間書式

String

時間の表示書式

orclTimeFormat

値は次のとおりです。

HH.mm

HH.mm.ss

HH:mm

HH:mm:ss

H:mm

H:mm:ss

H.mm

H.mm.ss

a hh.mm

a hh.mm.ss

a hh:mm

a hh:mm:ss

ah:mm

ah:mm:ss

hh.mm a

hh.mm.ss a

hh:mm a

hh:mm:ss a

埋込みヘルプ

String

埋込みヘルプを表示するかどうか

orclEmbeddedHelp

値は次のとおりです。

true

false

フォント・サイズ

String

フォントのサイズ

orclFontSize

値は次のとおりです。

LARGE

MEDIUM

色のコントラスト

String

色のコントラスト

orclColorContrast

値は次のとおりです。

STANDARD

HIGH

アクセシビリティ・モード

String

ユーザーのアクセシビリティ・モード

orclAccessibilityMode

値は次のとおりです。

screenReader

inaccessible

default

FA言語

String

デフォルトの優先言語

orclFALanguage

ユーザー名優先言語

String

ユーザーの表示名を示すためだけに使用される優先言語

注意: この属性の設定値はOracle Identity Managerでは使用されません。

orclDisplayNameLanguagePreference

32.20.4 Oracle Identity Managerの属性における特殊文字制限

この項では、Oracle Identity Managerの属性に適用される文字制限を示します。これらの制限に従わないと、属性を使用して操作を実行したときにエラーが発生します。

- すべての属性で使用可能な文字

- パスワード・フィールドにおける特殊文字

- 一重引用符の使用

- セミコロンの使用

- サポートされていない特殊文字

32.20.4.1 すべての属性で使用可能な文字

英数字(aからz、AからZ、および0から9)とアンダースコア文字(_)は、すべてのOracle Identity Manager属性で使用できます。

32.20.4.2 パスワード・フィールドにおける特殊文字

Passwordフィールドでは次の特殊文字を使用できます。

- パーセント記号(%)

- プラス記号(+)

- 等号(=)

- カンマ(,)

- 円記号(\)

- 一重引用符(')

- スラッシュ(/)

- 縦線(|)

32.20.4.3 一重引用符の使用

一重引用符(')は、次の属性でのみ使用できます。

- ログイン

- マネージャID

- 名

- 姓

- ミドル・ネーム

- グループ名

- 組織名

- リソース名

32.20.4.4 セミコロンの使用

セミコロン(;)はアクセス・ポリシー名でのみ使用できます。

32.20.4.5 サポートされていない特殊文字

次の特殊文字は、Oracle Identity Managerのどの属性でもサポートされていません。

- ピリオド(.)

- シャープ記号(#)

- スラッシュ(/)

- パーセント記号(%)

- 等号(=)

- 縦線(|)

- プラス記号(+)

- カンマ(,)

- 円記号(\)

- 二重引用符(")

- 小なり記号(<)

- 大なり記号(>)

32.20.5 操作データ

HCM Fusionアプリケーションなどのリクエスト・アプリケーションは、SPMLリクエスタとして動作します。アプリケーションでは、PSOデータ以外に、いくつかの操作データをSPML Webサービスに渡すことができます。この項では、アプリケーションが操作データを渡す仕組みについて説明します。

- 操作データを渡す場合

- 参照データを渡す場合

32.20.5.1 操作データを渡す場合

操作ごとにリクエスタIDを渡すことができます。Fusionアプリケーションがリクエストで提示する資格証明は、アプリケーションIDです。監査の目的で、リクエスタIDを渡すこともできます。Oracle Identity Managerでは、操作の実際のリクエスタとして、アプリケーションIDのかわりにこのIDが監査されます。

リクエスタIDと一緒に、リクエストの理由も指定できます。

次に、操作データの例を示します。

...
</pso:identity>
</data>
<capabilityData
capabilityURI="http://xmlns.oracle.com/idm/identity/OperationData"
mustUnderstand="true">
<operationData
xmlns="http://xmlns.oracle.com/idm/identity/OperationData" requestorGUID="1"
justification="i need this account">
</capabilityData>
</addRequest>

32.20.5.2 参照データを渡す場合

アプリケーションは、なんらかの参照データをSPMLに渡すことで、コールバックを受け取ったときに、コンテキストでそのコールバックに対して参照データによって識別されるようにする必要もあります。これはパススルー・データであり、Oracle Identity Managerでは無視されますが、コールバックには返されます。

次に、<LdapRequestId>を扱った例を示します。

...
...
</pso:identity>
</data>
<capabilityData
capabilityURI="http://xmlns.oracle.com/idm/identity/OperationData"
mustUnderstand="true">
<operationData
xmlns="http://xmlns.oracle.com/idm/identity/OperationData" requestorGUID="1"
justification="i need this account">
<LdapRequestId
xmlns="http://xmlns.oracle.com/apps/hcm/users/ldapRequestService/">102329090340
</operationData>
</capabilityData>
</addRequest>

32.21 SPMLの例

この付録では、次のSPML XSDの例を紹介します。

- SPMLの例 - ユーザーの追加

- SPMLの例 - ユーザーの削除

- SPMLの例 - ユーザーの変更

- SPMLの例 - ユーザーの再開

- SPMLの例 - ユーザー名の提案

- SPMLの例 - ユーザーの一時停止

- SPMLの例 - ユーザー名の検証

- SPMLの例 - ユーザーがアクティブかどうかのチェック

- SPMLの例 - ユーザー名ポリシーの参照

- SPMLの例 – ユーザーの追加とロールの割当て

- SPMLの例 - ロール・メンバーシップの割当て

- SPMLの例 – ロール・メンバーシップの失効

- SPMLの例 - ロールの追加

- SPMLの例 - 親を持つロールの追加

- SPMLの例 - ロールの変更

- SPMLの例 - ロールへの親の追加

- SPMLの例 - ロールの付与

- SPMLの例 - ロールの削除

- SPMLの例 - ステータスのリクエスト

- SPMLの例 - アイデンティティ/ロールの参照

- SPMLの例 - パスワードのリセット

- SPMLの例 - 通知を使用したパスワードのリセット

- SPMLの例 - ユーザー名ポリシーの参照

- SPMLの例 - リクエストのキャンセル

- SPMLの例 - リクエストのキャンセル

32.21.1 SPMLの例 - ユーザーの追加

次に、リクエストを示します。

<addRequest xmlns="urn:oasis:names:tc:SPML:2:0" xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous" locale="en" policyURI="http://www.sample.com/string/string" requestID="string" returnData="identifier" targetID="string">
<!--Zero or more repetitions:-->
<data>
<!--You have a CHOICE of the next 3 items at this level-->
<pso:identity>
<!--Optional:-->
<pso:attributes>
<!--Here, My Attribute is a UDF, with 'My Attribute' also added in CreateUserDataset.xml -->
<pso:attr name="My Attribute">
<pso:value>New Value</pso:value>
</pso:attr>
</pso:attributes>
<!--Optional:-->
<pso:activeEndDate>2009-06-12T16:00:00</pso:activeEndDate>
<!--Optional:-->
<pso:activeStartDate>2009-06-11T18:00:00</pso:activeStartDate>
<pso:commonName>
<pso:value>All Optional Values</pso:value>
</pso:commonName>
<!--Optional:-->
<pso:countryName>India</pso:countryName>
<!--Optional:-->
<pso:departmentNumber>
<!--1 or more repetitions:-->
<pso:value>123456</pso:value>
</pso:departmentNumber>
<!--Optional:-->
<pso:description>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>All Optional Fields Profile</pso:value>
</pso:values>
</pso:description>
<!--Optional:-->
<pso:displayName>
<!--1 or more repetitions:-->
<pso:value locale="en">All Optional Values</pso:value>
</pso:displayName>
<!--Optional:-->
<pso:employeeNumber>24073</pso:employeeNumber>
<!--Optional:-->
<pso:employeeType>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>Part-Time</pso:value>
</pso:values>
</pso:employeeType>
<!--Optional:-->
<pso:facsimileTelephoneNumber>
<!--1 or more repetitions:-->
<pso:number>08041085304</pso:number>
</pso:facsimileTelephoneNumber>
<!--Optional:-->
<pso:generationQualifier>
<!--1 or more repetitions:-->
<pso:value>II</pso:value>
</pso:generationQualifier>
<!--Optional:-->
<pso:givenName>
<!--1 or more repetitions:-->
<pso:value>OptionalGivenName</pso:value>
</pso:givenName>
<!--Optional:-->
<pso:hireDate>2009-06-11T16:00:00</pso:hireDate>
<!--Optional:-->
<pso:homePhone>
<!--1 or more repetitions:-->
<pso:number>9999999999</pso:number>
</pso:homePhone>
<!--Optional:-->
<pso:homePostalAddress>
<!--1 or more repetitions:-->
<pso:value>marathahalli</pso:value>
</pso:homePostalAddress>
<!--Optional:-->
<pso:initials>
<!--1 or more repetitions:-->
<pso:value>SJ</pso:value>
</pso:initials>
<!--Optional:-->
<pso:localityName>
<!--1 or more repetitions:-->
<pso:value>Munekolala</pso:value>
</pso:localityName>
<!--Optional:-->
<!--pso:mail>
<pso:value>jdong12@mycompany.com</pso:value>
</pso:mail-->
<!--Optional:-->
<pso:middleName>MiddleName</pso:middleName>
<!--Optional:-->
<pso:mobile>
<!--1 or more repetitions:-->
<pso:number>9886078373</pso:number>
</pso:mobile>
<!--Optional:-->
<pso:organization>
<pso:value>2</pso:value>
</pso:organization>
<!--Optional:-->
<pso:organizationUnit>
<pso:value>Marketing</pso:value>
</pso:organizationUnit>
<!--Optional:-->
<pso:pager>
<!--1 or more repetitions:-->
<pso:number>7777</pso:number>
</pso:pager>
<!--Optional:-->
<pso:password>
<!--1 or more repetitions:-->
<pso:value>saijha</pso:value>
</pso:password>
<!--Optional:-->
<pso:postalAddress>
<!--1 or more repetitions:-->
<pso:value>Marathahalli</pso:value>
</pso:postalAddress>
<!--Optional:-->
<pso:postalCode>
<!--1 or more repetitions:-->
<pso:value>560037</pso:value>
</pso:postalCode>
<!--Optional:-->
<pso:postOfficeBox>
<!--1 or more repetitions:-->
<pso:value>999</pso:value>
</pso:postOfficeBox>
<!--Optional:-->
<pso:preferredLanguage>en</pso:preferredLanguage>
<!--Optional:-->
<pso:state>
<!--1 or more repetitions:-->
<pso:value>Karnataka</pso:value>
</pso:state>
<!--Optional:-->
<pso:street>
<!--1 or more repetitions:-->
<pso:value>Satyam Street</pso:value>
</pso:street>
<!--Optional:-->
<pso:surname>
<pso:values>
<!--1 or more repetitions:-->
<pso:value>Jha</pso:value>
</pso:values>
</pso:surname>
<!--Optional:-->
<pso:telephoneNumber>
<!--1 or more repetitions:-->
<pso:number>08041085304</pso:number>
</pso:telephoneNumber>
<!--Optional:-->
<pso:title>
<pso:value>Mr</pso:value>
</pso:title>
<!--Optional:-->
<pso:username>
<!--1 or more repetitions:-->
<pso:value>jsmith</pso:value>
</pso:username>
<pso:manager>5</pso:manager>
</pso:identity>
</data>
</addRequest>

次に、ユーザー・ログインがすでに存在する場合のユーザーの追加レスポンスの例を示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/>
<env:Body>
<ns3:addResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:names:spml:ws:header" status="failure" error="malformedRequest" extendedError="IAM-3076048">
<ns3:errorMessage>username jsmith already exists.</ns3:errorMessage>
</ns3:addResponse>
</env:Body>
</env:Envelope>

次に、単一値のみを受け入れる属性に対して複数値が渡された場合のユーザーの追加レスポンスの例を示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns3:addResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:names:spml:ws:header" status="pending" requestID="5" error="malformedRequest" extendedError="IAM-3071022"><ns3:errorMessage>The attribute commonName is not multi-language enabled in OIM. Only the value John Smith will be saved.</ns3:errorMessage>
<ns3:errorMessage>The attribute organization is not multi-language enabled in OIM. Only the value 1 will be saved.
</ns3:errorMessage>
</ns3:addResponse>
</env:Body>
</env:Envelope>

注意:

- ユーザーの追加リクエストのステータスを調べる方法は、「SPMLの例 - ステータスのリクエスト」を参照してください。

- displayName属性は多言語サポート(MLS)に対応しており、言語値として「en」、「fr」などを指定できます。

32.21.2 SPMLの例 - ユーザーの削除

次に、リクエストを示します。

<deleteRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="en" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier" targetID="string">
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
</deleteRequest>

次に、レスポンスを示します。

<ns9:ResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="19" status="pending"/>

32.21.3 SPMLの例 - ユーザーの変更

次に、リクエストを示します。

<modifyRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="string" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier">
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true" />
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
<modification modificationMode="add">
<component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<data>
<pso:identity>
<pso:initials>
<!--1 or more repetitions:-->
<pso:value>J S</pso:value>
</pso:initials>
</pso:identity>
</data>
</modification>
<modification modificationMode="replace">
<component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<data>
<pso:identity>
<pso:localityName>
<!--1 or more repetitions:-->
<pso:value>new_locality</pso:value>
</pso:localityName>
<pso:homePhone>
<!--1 or more repetitions:-->
<pso:number>0123456789</pso:number>
</pso:homePhone>
<pso:commonName>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>FR Alice Krug1</pso:value>
</pso:values>
</pso:commonName>
</pso:identity>
</data>
</modification>
<modification modificationMode="delete">
<component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<data>
<pso:identity>
<pso:pager>
<!--1 or more repetitions:-->
<pso:number>333</pso:number>
</pso:pager>
</pso:identity>
</data>
</modification>
</modifyRequest>

次に、レスポンスを示します。

<ns9:ModifyResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="15" status="pending"/>

32.21.4 SPMLの例 - ユーザーの再開

次に、リクエストを示します。

<resumeRequest xmlns="urn:oasis:names:tc:SPML:2:0:suspend"
requestID="120">
<psoID ID="6C9B96E99FC8DC32E040E50A3D5252F5" />
</resumeRequest>

次に、レスポンスを示します。

<ns9:ResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:names:spml:ws:header" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="120" status="pending"/>

32.21.5 SPMLの例 - ユーザー名の提案

次に、リクエストを示します。

<ns4:suggestUsernameRequest
xmlns:ns4="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns3="http://xmlns.oracle.com/idm/identity/PSO">
<ns2:identity>
<ns3:givenName>
<ns3:value>testfn</ns3:value>
</ns3:givenName>
<ns3:surname>
<ns3:values>
<ns3:value>testln</ns3:value>
</ns3:values>
</ns3:surname>
</ns2:identity>
</ns4:suggestUsernameRequest>

次に、レスポンスを示します。

<ns9:SuggestUsernameResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns7="urn:names:spml:ws:header"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns9="oasis:names:tc:SPML:2:0" status="success">
<ns3:username>testfn.testln@mycompany.com</ns3:username>
</ns9:SuggestUsernameResponseType>

32.21.6 SPMLの例 - ユーザーの一時停止

次に、リクエストを示します。

<suspendRequest xmlns="urn:oasis:names:tc:SPML:2:0:suspend"
requestID="139">
<psoID ID="6C9B96E99FC8DC32E040E50A3D5252F5"/>
</suspendRequest>

次に、レスポンスを示します。

<ns9:ResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:names:spml:ws:header" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="28"
status="pending"/><ns9:ResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:names:spml:ws:header" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="139" status="pending"/>

32.21.7 SPMLの例 - ユーザー名の検証

次に、リクエストを示します。

<validateUsernameRequest
xmlns="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username">
<username>testfn.testln</username>
</validateUsernameRequest>

次に、レスポンスを示します。

<ns9:ValidateUsernameResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns7="urn:names:spml:ws:header"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns9="oasis:names:tc:SPML:2:0" valid="true" status="success"/>

32.21.8 SPMLの例 - ユーザーがアクティブかどうかのチェック

次に、リクエストを示します。

<activeRequest xmlns="urn:oasis:names:tc:SPML:2:0:suspend" requestID="143">
<psoID ID="5" targetID="string"/>
</activeRequest>

次に、レスポンスを示します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns4:ResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns3="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns4="oasis:names:tc:SPML:2:0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:ActiveResponseType" active="true" requestID="143"
status="success" />

32.21.9 SPMLの例 - ユーザー名ポリシーの参照

次に、リクエストを示します。

<lookupUsernamePolicyRequest
xmlns="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username">
</lookupUsernamePolicyRequest>

次に、レスポンスを示します。

<ns9:LookupUsernamePolicyResponseType
xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns7="urn:names:spml:ws:header"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns9="oasis:names:tc:SPML:2:0" status="success"
<ns3:description>Generates user name based on email id if it is available, else generate based on first name and last name appended with domain name.</ns3:description>
>

注意:

ポリシーの説明を特定のロケールで表示するには、ペイロードにロケール属性を設定します。このロケールがサポートされていない場合は、デフォルトでは、次に示すようにサーバー・ロケールで表示されます。

<lookupUsernamePolicyRequest locale="th"
xmlns="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username">
</lookupUsernamePolicyRequest>

32.21.10 SPMLの例 - ユーザーの追加とロールの割当て

次に、ユーザー(アイデンティティ)の作成リクエストを示します。

注意:

- reference要素の下位にはtoPsoID要素を1つだけ含めることができます。複数のロールが存在する場合は、それぞれ個別のreference要素を使用する必要があります。

- GUIDはどのリクエストでも32文字にする必要があります。

<addRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:spml="urn:oasis:names:tc:SPML:2:0"
executionMode="asynchronous"
policyURI="create_identity_policy_prc02.xml">
<spml:data xsi:type="spml:PSOType">
<identity
xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO">
<pso:commonName>
<pso:values>
<pso:value>John Doe</pso:value>
</pso:values>
</pso:commonName>
<pso:displayName>
<pso:value>John Doe</pso:value>
</pso:displayName>
<pso:givenName>
<pso:value>John</pso:value>
</pso:givenName>
<pso:mail>
<pso:value>john.doe@acme.com</pso:value>
</pso:mail>
<pso:middleName/>
<pso:organization>
<pso:values>
<pso:value>ACME, Inc.</pso:value>
</pso:values>
</pso:organization>
<pso:password>
<pso:value>qwert</pso:value>
</pso:password>
<pso:surname>
<pso:values>
<pso:value>Doe</pso:value>
</pso:values>
</pso:surname>
<pso:username>
<pso:value>jdoe</pso:value>
</pso:username>
</identity>
</spml:data>
<spml:capabilityData
capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true" >
<reference xmlns="urn:oasis:names:tc:SPML:2:0:reference"
typeOfReference="memberOf">
<toPsoID ID="15"/>
<!--To make the user a member of a default role-->
</reference>

<reference xmlns="urn:oasis:names:tc:SPML:2:0:reference"
typeOfReference="memberOf">
<toPsoID ID="6C9B96E99FC8DC32E040E50A3D5252F5"/>
</reference>
</spml:capabilityData>
</addRequest>

次に、レスポンスを示します。

<spml:addResponse
xmlns:spml="urn:oasis:names:tc:SPML:2:0"
status="pending"
requestID="10821"/>

次に、一部のロールが無効な場合のユーザーの追加とロールの割当てレスポンスの例を示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns3:addResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:names:spml:ws:header" status="pending" requestID="5" error="malformedRequest" extendedError="IAM-3071022">
<ns3:errorMessage>Request contains an invalid Id/Guid identifier - xyzxyzxyz.</ns3:errorMessage>
</ns3:addResponse>
</env:Body>
</env:Envelope>

32.21.11 SPMLの例 - ロール・メンバーシップの割当て

次に、リクエストの例を示します。

注意:

SPMLのロール・メンバーシップの追加を介してユーザーに付与できるのは、次のいずれかのロールのみです。

- 階層の最上位組織に公開されている

- SPMLを介してロールを付与するユーザーの1つ以上のメンバー組織に公開されている

SPMLを介した他のすべてのロール付与の試行は、認可チェックに失敗します。SPMLのロール付与が機能するには、UIまたはAPIを使用して関連する組織にこれらのロールを明示的に公開する必要があります。

<modifyRequest
xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO"
executionMode="asynchronous"
locale="en"
policyURI="gant_role_01">
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
<modification modificationMode="add">
<capabilityData
capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true">
<reference
xmlns="urn:oasis:names:tc:SPML:2:0:reference"
typeOfReference="memberOf">
<toPsoID ID="6C9B96E99FC8DC32E040E50A3D5252F5" />
</reference>
</capabilityData>
</modification>
</modifyRequest>

次に、レスポンスの例を示します。

<spml:modifyResponse
xmlns:spml="urn:oasis:names:tc:SPML:2:0"
status="pending"
requestID="10822"/>

32.21.12 SPMLの例 - ロール・メンバーシップの失効

次に、リクエストを示します。

<modifyRequest
xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO"
executionMode="asynchronous"
locale="en"
policyURI="revoke_role_01">
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
<modification modificationMode="delete">
<capabilityData
capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true">
<reference
xmlns="urn:oasis:names:tc:SPML:2:0:reference"
typeOfReference="memberOf">
<toPsoID ID="6C9B96E99FC8DC32E040E50A3D5252F5" />
</reference>
</capabilityData>
</modification>
</modifyRequest>

次に、レスポンスを示します。

<spml:modifyResponse
xmlns:spml="urn:oasis:names:tc:SPML:2:0"
status="pending"
requestID="10826"/>

32.21.13 SPMLの例 - ロールの追加

次に、リクエストを示します。

<addRequest xmlns="urn:oasis:names:tc:SPML:2:0" xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous" locale="en_us" policyURI="Role Creation" requestID="string"  returnData="identifier" targetID="string">
<!--Zero or more repetitions:-->
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"  mustUnderstand="true" />
<data>
<!--You have a CHOICE of the next 3 items at this level-->
<pso:role>
<pso:attributes>
<pso:attr name="Role Category Name">
<!-- pso:value>OIM Roles</pso:value-->
<pso:value>Default</pso:value>
</pso:attr>
</pso:attributes>
<pso:commonName>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>TempAdmin</pso:value>
</pso:values>
</pso:commonName>
<pso:description>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>Temporary Administrator</pso:value>
</pso:values>
</pso:description>
<pso:displayName>
<!--pso:value locale="en">Alice Krug_en_US</pso:value-->
<!--pso:value locale="fr">Alice Kru_fr</pso:value-->
<pso:value locale="base">Alice Kru_base</pso:value>
</pso:displayName>
</pso:role>
</data>
</addRequest>

次に、レスポンスを示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<ns3:addResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0"    xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:names:spml:ws:header" status="pending" requestID="21792"/>
</env:Body>
</env:Envelope>

32.21.14 SPMLの例 - 親を持つロールの追加

次に、リクエストを示します。

<addRequest xmlns="urn:oasis:names:tc:SPML:2:0"                        xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="en" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier" targetID="string">
<data>
<!--You have a CHOICE of the next 3 items at this level-->
<pso:role>
<pso:commonName>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>TempAdmin</pso:value>
</pso:values>
</pso:commonName>
<pso:description>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>Temporary Administrator</pso:value>
</pso:values>
</pso:description>
</pso:role>
</data>
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference" mustUnderstand="true">
<reference typeOfReference="inheritsFrom" xmlns="urn:oasis:names:tc:SPML:2:0:reference">
<toPsoID ID="6C9B96E99F77DC32E040E50A3D5252F5" />
</reference>
</capabilityData>
</addRequest>

次に、レスポンスを示します。

<ns9:AddResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="22" status="pending"/>

32.21.15 SPMLの例 - ロールの変更

次に、リクエストを示します。

<modifyRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="string" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier">
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true" />
<psoID ID="role:6C9B96E99FC8DC32E040E50A3D5252F5" />
<modification modificationMode="replace">
<component path="/role" namespaceURI="http://www.w3.org/TR/xpath20" />
<data>
<pso:role>
<pso:description>
<!--1 or more repetitions:-->
<pso:values>
<pso:value>UK Updated Administrator</pso:value>
</pso:values>
</pso:description>
</pso:role>
</data>
</modification>
</modifyRequest>

次に、レスポンスを示します。

<ns9:ModifyResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="24" status="pending"/>

32.21.16 SPMLの例 - ロールへの親の追加

次に、リクエストを示します。

<modifyRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="string" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier">

<psoID ID="role:26" targetID="target" />
<modification modificationMode="modify">
<component path="/role" namespaceURI="http://www.w3.org/TR/xpath20" />
<data>
<pso:role>
<pso:description>
<!--1 or more repetitions:-->
<pso:values>
<!--1 or more repetitions:-->
<pso:value>UK Updated Administrator</pso:value>
</pso:values>
</pso:description>
</pso:role>
</data>

<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true">
<reference typeOfReference="inheritsFrom"
xmlns="urn:oasis:names:tc:SPML:2:0:reference">
<toPsoID ID="25" />
</reference>
</capabilityData>
</modification>
</modifyRequest>

次に、レスポンスを示します。

<ns9:ModifyResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="25" status="pending"/>

32.21.17 SPMLの例 - ロールの付与

SPMLペイロードを使用して複数のアイデンティティにロールを割り当てることはできません。複数のアイデンティティを指定した場合、ロールは最後のアイデンティティのみに割り当てられます。残りのアイデンティティはペイロードから削除してください。

次に、リクエストを示します。

<modifyRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="string" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier">
<!--Zero or more repetitions:-->
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true" />
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
<psoID ID="identity:6C9B96E99FC8DC32E040E50A3D5252F5" />
<!--1 or more repetitions:-->
<modification modificationMode="add">
<capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference"
mustUnderstand="true">
<reference xmlns="urn:oasis:names:tc:SPML:2:0:reference"
typeOfReference="memberOf">
<toPsoID ID="6C9B96E99FC8DC32E040E50A3D5252F5" />
</reference>
</capabilityData>
</modification>
</modifyRequest>

次に、レスポンスを示します。

<ns9:ResponseType xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:names:spml:ws:header"
xmlns:ns7="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns9="oasis:names:tc:SPML:2:0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns4:ActiveResponseType" requestID="143" status="failure"/>

32.21.18 SPMLの例 - ロールの削除

次に、リクエストを示します。

<deleteRequest xmlns="urn:oasis:names:tc:SPML:2:0"
xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" executionMode="asynchronous"
locale="en" policyURI="http://www.sample.com/string/string"
requestID="string" returnData="identifier" targetID="string">
<psoID ID="role:6C9B96E99FC8DC32E040E50A3D5252F5" />
</deleteRequest>

次に、レスポンスを示します。

<ns9:ResponseType xmlns="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns2="urn:oasis:names:tc:SPML:2:0"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns5="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns7="urn:names:spml:ws:header" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="oasis:names:tc:SPML:2:0" requestID="18" status="pending"/>

32.21.19 SPMLの例 - ステータスのリクエスト

次に、リクエストを示します。

<statusRequest xmlns="urn:oasis:names:tc:SPML:2:0:async"
requestID="3456563"
asyncRequestID="75779"/>

次に、レスポンスを示します。

<statusResponse xmlns="urn:oasis:names:tc:SPML:2:0:async"
requestID="3456563" status="success">
<addResponse requestID="75779" status="pending"/>
</statusResponse>

次に、別のリクエストを示します。

<statusRequest xmlns="urn:oasis:names:tc:SPML:2:0:async"    requestID="12" asyncRequestID="1" returnResults="true" />

この場合、returnResults=trueを使用しています。したがって、レスポンスにはリクエストのすべての属性が含まれます。

次に、レスポンスを示します。

<ns9:StatusResponseType xmlns="urn:oasis:names:tc:SPML:2:0" xmlns:ns2="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns3="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns5="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns7="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns8="urn:names:spml:ws:header" xmlns:ns9="oasis:names:tc:SPML:2:0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:StatusResponseType" requestID="12" status="success">
<ns2:addResponse requestID="14" status="success">
<pso>
<psoID targetID="Identity"/>
<data>
<ns4:Identity xmlns:ns4="oasis:names:tc:SPML:2:0" xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns5="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns6="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:suspend">
<ns2:attributes>
<ns2:attr xmlns="" xmlns:ns11="urn:oasis:names:tc:SPML:2:0" name="Organization">
<ns2:value>1</ns2:value>
</ns2:attr>
</ns2:attributes>
<ns2:activeEndDate>2009-12-25T16:00:00.000Z</ns2:activeEndDate>
<ns2:activeStartDate>2009-12-24T18:00:00.000Z</ns2:activeStartDate>
<ns2:commonName>
<ns2:values>
<ns2:value>Alice Krug</ns2:value>
</ns2:values>
</ns2:commonName>
<ns2:countryName>Canada</ns2:countryName>
<ns2:departmentNumber>
<ns2:value>123</ns2:value>
</ns2:departmentNumber>
<ns2:description>
<ns2:values>
<ns2:value>Alice Krugs profile</ns2:value>
</ns2:values>
</ns2:description>
<ns2:displayName>
<ns2:value>Alice Krug</ns2:value>
</ns2:displayName>
<ns2:employeeNumber>333</ns2:employeeNumber>
<ns2:employeeType>
<ns2:values>
<ns2:value>Full-Time</ns2:value>
</ns2:values>
</ns2:employeeType>
<ns2:facsimileTelephoneNumber>
<ns2:number>6506072253</ns2:number>
</ns2:facsimileTelephoneNumber>
<ns2:generationQualifier>
<ns2:value>II</ns2:value>
</ns2:generationQualifier>
<ns2:givenName>
<ns2:value>Alice</ns2:value>
</ns2:givenName>
<ns2:hireDate>1999-12-24T16:00:00.000Z</ns2:hireDate>
<ns2:homePhone>
<ns2:number>8888888888</ns2:number>
</ns2:homePhone>
<ns2:homePostalAddress>
<ns2:value>Baker street</ns2:value>
</ns2:homePostalAddress>
<ns2:initials>
<ns2:value>J S</ns2:value>
</ns2:initials>
<ns2:localityName>
<ns2:value>SFO</ns2:value>
</ns2:localityName>
<ns2:middleName>A</ns2:middleName>
<ns2:mobile>
<ns2:number>4083485309</ns2:number>
</ns2:mobile>
<ns2:organization>
<ns2:values>
<ns2:value>1</ns2:value>
</ns2:values>
</ns2:organization>
<ns2:organizationUnit>
<ns2:values>
<ns2:value>Sales</ns2:value>
</ns2:values>
</ns2:organizationUnit>
<ns2:pager>
<ns2:number>333</ns2:number>
</ns2:pager>
<ns2:postalAddress>
<ns2:value>Baker street 222</ns2:value>
</ns2:postalAddress>
<ns2:postalCode>
<ns2:value>4081</ns2:value>
</ns2:postalCode>
<ns2:postOfficeBox>
<ns2:value>333n</ns2:value>
</ns2:postOfficeBox>
<ns2:preferredLanguage>en</ns2:preferredLanguage>
<ns2:state>
<ns2:value>CA</ns2:value>
</ns2:state>
<ns2:street>
<ns2:value>Baker</ns2:value>
</ns2:street>
<ns2:surname>
<ns2:values>
<ns2:value>Krug</ns2:value>
</ns2:values>
</ns2:surname>
<ns2:telephoneNumber>
<ns2:number>6506072253</ns2:number>
</ns2:telephoneNumber>
<ns2:title>
<ns2:values>
<ns2:value>Mr</ns2:value>
</ns2:values>
</ns2:title>
<ns2:username>
<ns2:value>akrug3478</ns2:value>
</ns2:username>
<ns2:userType>End-User</ns2:userType>
</ns4:Identity>
</data>
</pso>
</ns2:addResponse>
</ns9:StatusResponseType>

32.21.20 SPMLの例 - アイデンティティ/ロールの参照

次に、リクエストを示します。

<ns1:lookupRequest xmlns:ns1="urn:oasis:names:tc:SPML:2:0" returnData="everything">
<ns1:psoID ID="identity:key:1" />
</ns1:lookupRequest>

次に、レスポンスを示します。

<ns3:lookupResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO"
xmlns:ns3="urn:oasis:names:tc:SPML:2:0"
xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch"
xmlns:ns10="urn:names:spml:ws:header">
<ns3:capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference" mustUnderstand="true">
<ns7:reference typeOfReference="memberOf"><ns7:toPsoID ID="1"/>
</ns7:reference>
</ns3:capabilityData><ns3:pso>
<ns3:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:ProvisioningObjectType">
<ns2:identity><ns2:attributes><ns2:attr name="usr_disabled">
<ns2:value>0</ns2:value></ns2:attr><ns2:attr name="Display Name">
<ns2:value>zh-TW=System Administrator</ns2:value><ns2:value>pt-BR=System Administrator</ns2:value>
<ns2:value>base=System Administrator</ns2:value><ns2:value>fr=System Administrator</ns2:value>
<ns2:value>en=System Administrator</ns2:value>
<ns2:value>zh-CN=System Administrator</ns2:value>
</ns2:attr><ns2:attr name="usr_locked">
<ns2:value>0</ns2:value>
</ns2:attr><ns2:attr name="usr_created">
<ns2:value>Mon Dec 03 03:42:21 PST 2012</ns2:value>
</ns2:attr><ns2:attr name="Full Name">
<ns2:value>base=null</ns2:value>
</ns2:attr><ns2:attr name="usr_pwd_expire_date">
<ns2:value>Tue Apr 02 03:42:21 PDT 2013</ns2:value>
</ns2:attr><ns2:attr name="Email">
<ns2:value>donotreply@oracle.com</ns2:value>
</ns2:attr><ns2:attr name="usr_data_level">
<ns2:value>2</ns2:value></ns2:attr>
<ns2:attr name="usr_login_attempts_ctr">
<ns2:value>0</ns2:value></ns2:attr>
<ns2:attr name="Last Name">
<ns2:value>Administrator</ns2:value>
</ns2:attr><ns2:attr name="First Name">
<ns2:value>System</ns2:value>
</ns2:attr><ns2:attr name="usr_createby">
<ns2:value>1</ns2:value></ns2:attr>
<ns2:attr name="usr_updateby">
<ns2:value>1</ns2:value>
</ns2:attr><ns2:attr name="User Login">
<ns2:value>XELSYSADM</ns2:value>
</ns2:attr><ns2:attr name="Role">
<ns2:value>Full-Time</ns2:value>
</ns2:attr><ns2:attr name="usr_pwd_warn_date">
<ns2:value>Tue Mar 26 03:42:21 PDT 2013</ns2:value>
</ns2:attr><ns2:attr name="Organization Name">
<ns2:value>Xellerate Users</ns2:value></ns2:attr>
<ns2:attr name="usr_update"><ns2:value>Mon Dec 03 03:42:21 PST 2012</ns2:value>
</ns2:attr><ns2:attr name="usr_pwd_reset_attempts_ctr">
<ns2:value>0</ns2:value></ns2:attr><ns2:attr name="usr_create">
<ns2:value>Mon Dec 03 03:42:21 PST 2012</ns2:value>
</ns2:attr><ns2:attr name="Xellerate Type">
<ns2:value>End-User Administrator</ns2:value>
</ns2:attr><ns2:attr name="Common Name">
<ns2:value>System Administrator</ns2:value></ns2:attr>
<ns2:attr name="act_key">
<ns2:value>1</ns2:value>
</ns2:attr><ns2:attr name="usr_key">
<ns2:value>1</ns2:value></ns2:attr>
<ns2:attr name="Common Name Generated">
<ns2:value>0</ns2:value>
</ns2:attr><ns2:attr name="Status">
<ns2:value>Active</ns2:value>
</ns2:attr></ns2:attributes>
<ns2:commonName>
<ns2:values><ns2:value>System Administrator</ns2:value>
</ns2:values></ns2:commonName>
<ns2:displayName>
<ns2:value locale="zh-TW">System Administrator</ns2:value><ns2:value locale="pt-BR">System Administrator</ns2:value><ns2:value locale="base">System Administrator</ns2:value>
<ns2:value locale="fr">System Administrator</ns2:value><ns2:value locale="en">System Administrator</ns2:value><ns2:value locale="zh-CN">System Administrator</ns2:value>
</ns2:displayName><ns2:employeeType>
<ns2:values>
<ns2:value>Full-Time</ns2:value></ns2:values>
</ns2:employeeType>
<ns2:givenName>
<ns2:value>System</ns2:value></ns2:givenName>
<ns2:mail>
<ns2:value>donotreply@oracle.com</ns2:value>
</ns2:mail><ns2:surname><ns2:values>
<ns2:value>Administrator</ns2:value></ns2:values>
</ns2:surname>
<ns2:userId><ns2:value>XELSYSADM</ns2:value>
</ns2:userId><ns2:userType>End-User Administrator</ns2:userType>
</ns2:identity>
</ns3:data>
</ns3:pso>
</ns3:lookupResponse>

次に、別のリクエストを示します。

<ns1:lookupRequest xmlns:ns1="urn:oasis:names:tc:SPML:2:0" returnData="everything">
<ns1:psoID ID="role:name: FinanceRole " />
</ns1:lookupRequest>

次に、レスポンスを示します。

<ns3:lookupResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend"
xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username"
xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password"
xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference"
xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async"
xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch"
xmlns:ns10="urn:names:spml:ws:header">
<ns3:capabilityData capabilityURI="urn:oasis:names:tc:SPML:2:0:reference" mustUnderstand="true">
<ns7:reference typeOfReference="inheritsFrom">
<ns7:toPsoID ID="10"/>
</ns7:reference>
<ns7:reference typeOfReference="inheritsFrom">
<ns7:toPsoID ID="7"/>
</ns7:reference><ns7:reference typeOfReference="memberOf">
<ns7:toPsoID ID="8"/></ns7:reference>
</ns3:capabilityData><ns3:pso>
<ns3:data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:ProvisioningObjectType">
<ns2:role><ns2:attributes>
<ns2:attr name="Role Display Name">
<ns2:value>FinanceRole</ns2:value>
</ns2:attr><ns2:attr name="Role Unique Name">
<ns2:value>FinanceRole</ns2:value>
</ns2:attr><ns2:attr name="Owner Login">
<ns2:value>XELSYSADM</ns2:value>
</ns2:attr><ns2:attr name="ugp_createby">
<ns2:value>1</ns2:value></ns2:attr>
<ns2:attr name="ugp_create">
<ns2:value>Wed Nov 21 23:28:42 PST 2012</ns2:value>
</ns2:attr><ns2:attr name="Role Owner Key">
<ns2:value>1</ns2:value></ns2:attr>
<ns2:attr name="Role Description">
<ns2:value>desc</ns2:value>
</ns2:attr><ns2:attr name="Role Name">
<ns2:value>FinanceRole</ns2:value>
</ns2:attr><ns2:attr name="ugp_update">
<ns2:value>Wed Nov 21 23:28:42 PST 2012</ns2:value></ns2:attr>
<ns2:attr name="Owner Email">
<ns2:value>donotreply@oracle.com</ns2:value></ns2:attr>
<ns2:attr name="Role Namespace"><ns2:value>Default</ns2:value></ns2:attr>
<ns2:attr name="Owner Display Name">
<ns2:value>System Administrator</ns2:value>
</ns2:attr><ns2:attr name="Role Key">
<ns2:value>6</ns2:value>
</ns2:attr>
<ns2:attr name="ugp_updateby">
<ns2:value>1</ns2:value>
</ns2:attr>
<ns2:attr name="Role Category Key">
<ns2:value>2</ns2:value>
</ns2:attr><ns2:attr name="Owner Last Name">
<ns2:value>Administrator</ns2:value>
</ns2:attr><ns2:attr name="Role Email">
<ns2:value>email@email.com</ns2:value>
</ns2:attr><ns2:attr name="Owner First Name">
<ns2:value>System</ns2:value></ns2:attr>
<ns2:attr name="Role Category Name">
<ns2:value>OIM Roles</ns2:value>
</ns2:attr>
</ns2:attributes>
<ns2:commonName>
<ns2:values>
<ns2:value>FinanceRole</ns2:value>
</ns2:values></ns2:commonName>
<ns2:description>
<ns2:values>
<ns2:value>desc</ns2:value></ns2:values>
</ns2:description>
<ns2:displayName><ns2:value>FinanceRole</ns2:value>
</ns2:displayName></ns2:role>
</ns3:data>
</ns3:pso>
</ns3:lookupResponse>

32.21.21 SPMLの例 - パスワードのリセット

次に、リクエストを示します。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<soap:Header>
<ns1:Security>
<ns1:UsernameToken>
<ns1:Username>SYSTEM_ADMINISTRATOR_LOGIN</ns1:Username>
<ns1:Password>SYSTEM_ADMINISTRATOR_PASSWORD</ns1:Password>
</ns1:UsernameToken>
</ns1:Security>
</soap:Header>
<soap:Body   xmlns="urn:oasis:names:tc:SPML:2:0">
<resetPasswordRequest xmlns="urn:oasis:names:tc:SPML:2:0:password">

executionMode="asynchronous"
locale="en_US">
<psoID ID="BD7A621E8C7147D2E040E50AFC801934"></psoID>
</resetPasswordRequest>
</soap:Body>
</soap:Envelope>

次に、レスポンスを示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/><env:Body><ns6:resetPasswordResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch" xmlns:ns10="urn:names:spml:ws:header" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns6:ResetPasswordResponseType" status="success"/></env:Body></env:Envelope>

32.21.22 SPMLの例 - 通知を使用したパスワードのリセット

次に、リクエストを示します。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<soap:Header>
<ns1:Security>
<ns1:UsernameToken>
<ns1:Username>SYSTEM_ADMINISTRATOR_LOGIN</ns1:Username>
<ns1:Password>SYSTEM_ADMINISTRATOR_PASSWORD</ns1:Password>
</ns1:UsernameToken>
</ns1:Security>
</soap:Header>
<soap:Body   xmlns="urn:oasis:names:tc:SPML:2:0">
<resetPasswordRequest xmlns="urn:oasis:names:tc:SPML:2:0:password">

executionMode="asynchronous"
locale="en_US">
<psoID ID="BD7A621E8C7147D2E040E50AFC801934"></psoID>
<notificationData>
<sendNotification>true</sendNotification>
<sendNotificationTo><emailAddress>john.doe@mycompany.com,jane.doe@mycompany.com,terrence.hill@mycompany.com</emailAddress></sendNotificationTo>
</notificationData>
</resetPasswordRequest>
</soap:Body>
</soap:Envelope>

次に、レスポンスを示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/><env:Body><ns6:resetPasswordResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch" xmlns:ns10="urn:names:spml:ws:header" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns6:ResetPasswordResponseType" status="success"/></env:Body></env:Envelope>

32.21.23 SPMLの例 - ユーザー名ポリシーの参照

次に、リクエストを示します。

<ns2:lookupUsernamePolicyRequest xmlns:ns2="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" requestID=""
executionMode="synchronous" locale="en" policyURI="" xmlns:ns3="urn:oasis:names:tc:SPML:2:0">
</ns2:lookupUsernamePolicyRequest>

次に、レスポンスを示します。

<ns5:lookupUsernamePolicyResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch" xmlns:ns10="urn:names:spml:ws:header" status="success"><ns5:description>Generates user name based on email id if it is available, else if first name is present then &lt;first name&gt;.&lt;last name&gt;@&lt;domain&gt;, else &lt;last name&gt;@&lt;domain&gt;</ns5:description></ns5:lookupUsernamePolicyResponse>

32.21.24 SPMLの例 - リクエストのキャンセル

次に、リクエストを示します。

<ns1:cancelRequest xmlns:ns1="urn:oasis:names:tc:SPML:2:0:async" asyncRequestID="162"/>

次に、レスポンスを示します。

次に、正常に取り消されたリクエストを示します。

<ns8:cancelResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch" xmlns:ns10="urn:names:spml:ws:header" asyncRequestID="162" status="success"/>

次に、正常に取り消されなかったリクエストを示します。

<ns8:cancelResponse xmlns:ns2="http://xmlns.oracle.com/idm/identity/PSO" xmlns:ns3="urn:oasis:names:tc:SPML:2:0" xmlns:ns4="urn:oasis:names:tc:SPML:2:0:suspend" xmlns:ns5="http://xmlns.oracle.com/idm/identity/spmlv2custom/Username" xmlns:ns6="urn:oasis:names:tc:SPML:2:0:password" xmlns:ns7="urn:oasis:names:tc:SPML:2:0:reference" xmlns:ns8="urn:oasis:names:tc:SPML:2:0:async" xmlns:ns9="urn:oasis:names:tc:SPML:2:0:batch" xmlns:ns10="urn:names:spml:ws:header" asyncRequestID="161" status="failure" error="malformedRequest" extendedError="IAM-3076087"><ns3:errorMessage>User cannot withdraw specified request.</ns3:errorMessage></ns8:cancelResponse>

32.21.25 SPMLの例 - バッチ・リクエスト

次に、リクエストを示します。

<urn1:batchRequest processing="parallel" onError="resume" xmlns:urn1="urn:oasis:names:tc:SPML:2:0:batch" xmlns:urn2="urn:oasis:names:tc:SPML:2:0" xmlns:pso="http://xmlns.oracle.com/idm/identity/PSO" xmlns:urn3="urn:oasis:names:tc:SPML:2:0:password" >
<!--Zero or more repetitions:-->
<urn1:addRequest requestID="?" executionMode="asynchronous" locale="en" policyURI="User Creation" targetID="?" returnData="identifier">
<urn2:data>
<!--You may enter ANY elements at this point-->
<!--You have a CHOICE of the next 3 items at this level-->
<pso:identity>
<pso:commonName>
<pso:values locale="en">
<pso:value>John Smith</pso:value>
</pso:values>
</pso:commonName>
<pso:countryName>Canada</pso:countryName>
<pso:departmentNumber>
<pso:value>123</pso:value>
</pso:departmentNumber>
<pso:description>
<pso:values>
<pso:value>John Smiths profile</pso:value>
</pso:values>
</pso:description>
<pso:displayName>
<pso:value>John Smith</pso:value>
</pso:displayName>
<pso:employeeNumber>333</pso:employeeNumber>
<pso:employeeType>
<pso:values>
<pso:value>Full-Time</pso:value>
</pso:values>
</pso:employeeType>
<pso:facsimileTelephoneNumber>
<pso:number>6506072253</pso:number>
</pso:facsimileTelephoneNumber>
<pso:generationQualifier>
<pso:value>II</pso:value>
</pso:generationQualifier>
<pso:givenName>
<pso:value>John</pso:value>
</pso:givenName>
<pso:hireDate>1999-12-24T16:00:00</pso:hireDate>
<pso:homePhone>
<pso:number>8888888888</pso:number>
</pso:homePhone>
<pso:homePostalAddress>
<pso:value>Baker street</pso:value>
</pso:homePostalAddress>
<pso:initials>
<pso:value>J S</pso:value>
</pso:initials>
<pso:jpegPhoto>
<pso:value>c3RyaW5n</pso:value>
</pso:jpegPhoto>
<pso:localityName>
<pso:value>SFO</pso:value>
</pso:localityName>
<pso:mail>
<pso:value>jsmith@oracle.com</pso:value>
</pso:mail>
<pso:middleName>Park</pso:middleName>
<pso:mobile>
<pso:number>4083485309</pso:number>
</pso:mobile>
<pso:organization>
<pso:values locale="en">
<pso:value>1</pso:value>
</pso:values>
</pso:organization>
<pso:organizationUnit>
<pso:values locale="en">
<pso:value>Sales</pso:value>
</pso:values>
</pso:organizationUnit>
<pso:pager>
<pso:number>333</pso:number>
</pso:pager>
<pso:password>
<pso:value>V2VsY29tZTE=</pso:value>
</pso:password>
<pso:postalAddress>
<pso:value>Baker street 222</pso:value>
</pso:postalAddress>
<pso:postalCode>
<pso:value>4081</pso:value>
</pso:postalCode>
<pso:postOfficeBox>
<pso:value>333n</pso:value>
</pso:postOfficeBox>
<pso:preferredLanguage>en-US</pso:preferredLanguage>
<pso:state>
<pso:value>CA</pso:value>
</pso:state>
<pso:street>
<pso:value>Baker</pso:value>
</pso:street>
<pso:surname>
<pso:values locale="en">
<pso:value>Smith</pso:value>
</pso:values>
</pso:surname>
<pso:telephoneNumber>
<pso:number>6506072253</pso:number>
</pso:telephoneNumber>
<pso:title>
<pso:values locale="en">
<pso:value>Mr</pso:value>
</pso:values>
</pso:title>
<pso:username>
<pso:value>jsmith</pso:value>
</pso:username>
</pso:identity>
</urn2:data>
</urn1:addRequest>
<urn1:modifyRequest executionMode="asynchronous">
<urn2:psoID ID="9924000" />
<urn2:modification modificationMode="add">
<urn2:component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<urn2:data>
<pso:identity>
<pso:initials>
<pso:value>X Y</pso:value>
</pso:initials>
</pso:identity>
</urn2:data>
</urn2:modification>
<urn2:modification modificationMode="replace">
<urn2:component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<urn2:data>
<pso:identity>
<pso:localityName>
<!--1 or more repetitions:-->
<pso:value>new_locality</pso:value>
</pso:localityName>
<pso:homePhone>
<!--1 or more repetitions:-->
<pso:number>0123456789</pso:number>
</pso:homePhone>
</pso:identity>
</urn2:data>
</urn2:modification>
<urn2:modification modificationMode="delete">
<urn2:component path="/identity" namespaceURI="http://www.w3.org/TR/xpath20" />
<urn2:data>
<pso:identity>
<pso:pager>
<pso:number>333</pso:number>
</pso:pager>
</pso:identity>
</urn2:data>
</urn2:modification>
</urn1:modifyRequest>
<urn1:deleteRequest executionMode="asynchronous"  locale="en" policyURI="http://www.sample.com/string/string"  requestID="string" returnData="identifier" targetID="string">
<urn2:psoID ID="9924000" />
</urn1:deleteRequest>
<urn1:resetPasswordRequest executionMode="asynchronous">
<urn3:psoID ID="924000" />
<urn3:notificationData>
<urn2:sendNotification>true</urn2:sendNotification>
<urn2:sendNotificationTo>
<urn2:emailAddress>john@oracle.com</urn2:emailAddress>
</urn2:sendNotificationTo>
</urn3:notificationData>
</urn1:resetPasswordRequest>
</urn1:batchRequest>

次に、レスポンスを示します。

<urn:batchResponse xmlns:urn="urn:oasis:names:tc:SPML:2:0:batch" xmlns:urn1="urn:oasis:names:tc:SPML:2:0">
<!--Zero or more repetitions:-->
<urn:addResponse status="pending" requestID="1234"/>
<urn:modifyResponse status="pending" requested="2345"/>
<urn:deleteResponse status="pending" requestID="3456"/>
<urn:resetPasswordResponse status="success" />
</urn:batchResponse>

33 URLの使用

他のWebアプリケーションにおいて、アイデンティティ・セルフ・サービスおよびアイデンティティ管理の要件により、エンド・ユーザーおよび管理者をOracle Identity Self Serviceタスク・フローにリダイレクトする必要がある場合があります。

表33-1に示されているタスク・フローに対し、Oracle Identity Self Serviceでは他のWebアプリケーション・ページへのリンクとして埋め込むことが可能なダイレクトURLを公開します。

表33-1 タスク・フローおよびダイレクトURL

タスク・フロー・タイトル

ダイレクトURL (https://OIMHOST:PORTに対する相対URL)

説明

ホーム

/identity/faces/home?tf=home

ホーム・ページ・タスク・フローを表示します。

本人情報

/identity/faces/home?tf=my_information

ユーザー・プロファイル、パスワードの変更、チャレンジ質問、プロキシおよび直属の部下を表示します。

マイ・アクセス・ロール

/identity/faces/home?tf=my_access_roles

「ロールのリクエスト」アクションとともに、エンタープライズ・ロール・メンバーシップを表示します。

マイ・アクセス管理ロール

/identity/faces/home?tf=my_access_admin_roles

管理ロール・メンバーシップを表示します。

マイ・アクセス・アカウント

/identity/faces/home?tf=my_access_accounts

「アカウントのリクエスト」アクションとともに、割り当てられているアカウントを表示します。

マイ・アクセス権限

/identity/faces/home?tf=my_access_entitlements

「権限のリクエスト」アクションとともに、割り当てられている権限を表示します。

承認の詳細

/identity/faces/home?tf=approval_details

保留中の承認タスクを表示します。

リクエストの詳細

/identity/faces/home?tf=request_details&requestId=<Request Id>

リクエストIDは必須です。これはリクエストの送信に基づいて生成されたIDです。

組織

/identity/faces/home?tf=organizations

組織検索ページを表示します。

ロール

/identity/faces/home?tf=roles

ロール検索ページを表示します。

ロール・カテゴリ

/identity/faces/home?tf=role_categories

ロール・カテゴリの検索ページを表示します。

第IX部

通知サービス

この部は、通知サービスおよびコールバック・サービスについて説明する各章で構成されています。

次の章で構成されます。

- 第34章「通知イベントの開発」

- 第35章「コールバック・サービスの使用」

34 通知イベントの開発

この章では、通知イベントを開発する方法について説明します。この章には次の項目があります。

- 通知の概念

- カスタム通知の開発

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

34.1 通知の概念

Oracle Identity Managerの様々な操作のカスタム通知を開発するために、通知エンジンは、通知イベントおよび通知テンプレートの作成をサポートしています。

イベントとは、Oracle Identity Managerで発生する操作で、ユーザー作成、リクエスト開始またはユーザーが作成した任意のカスタム・イベントなどが含まれます。イベントは、ビジネス操作の一部として、またはエラー生成を介して生成されます。イベント定義は、イベントを記述するメタデータです。イベントのメタデータを定義するには、機能コンポーネントでサポートされるすべてのイベント・タイプを識別することが重要です。たとえば、スケジューラ・コンポーネントの一部として、スケジュール済ジョブ実行の失敗とスケジューラの停止に対してメタデータを定義できます。ジョブの失敗またはスケジューラの停止のたびにイベントが発生し、イベントに関連付けられている通知が送信されます。

通知テンプレートは、特定のイベントと関連付けられています。テンプレートは、通知の書式の定義に使用します。Oracle Identity Managerでは、事前定義済またはデフォルトの通知テンプレートが提供されます。また、新しい通知テンプレートを作成することもできます。

一部のイベントでは、デフォルトでOracle Identity Managerから通知が送信されます。たとえば、UIまたはリコンシリエーションを介してユーザー名およびパスワードなしでユーザーを作成した場合、ユーザーおよびユーザーのマネージャにログイン資格証明が通知されます。

新しい通知テンプレートを作成して、それを既存のイベントにリンクできます。また、後続の項で説明されるように、通知APIおよびリゾルバ・クラスを使用して、新しい通知イベントを定義できます。カスタム通知の要件の例を次に示します。

- ユーザーをロールに割り当てます。ユーザーおよびロールの所有者は通知されます。

- リコンシリエーションの一部として財務的に重要な新しいアプリケーション・インスタンスをユーザーに割り当てます。アプリケーション・インスタンスの所有者およびコンプライアンス責任者は、統制外試行の可能性がある場合に通知されます。

34.2 カスタム通知の開発

カスタム通知の開発については、次の各項で説明します。

- 通知ロジックの構築

- リゾルバ・クラスを含むプラグイン・パックの作成

- 起動ロジックの構築

- 通知サービスの構成

34.2.1 通知ロジックの構築

通知ログインを構築するには、次の項で説明するように、イベント・メタデータXMLを定義し、リゾルバ・クラスを作成します。

- イベント・メタデータの定義

- リゾルバ・クラスの作成

34.2.1.1 イベント・メタデータの定義

各イベントに対して、通知エンジンで定義される特定のスキーマを持つXMLファイルを作成する必要があります。そのスキーマ(.xsdファイル)に準拠して、イベントの概要を定義するXMLファイルが作成されます。イベントが定義されると、そのイベントの通知テンプレートを定義できます。

イベント・ファイルは通知エンジンで定義されるスキーマ、NotificationEvent.xsdに準拠している必要があります。イベント・ファイルにはイベントに関する基本情報が含まれます。

注意:

NotificationEvent.xsdファイルは、MDSのiam\iam-product\features\notification\metadataディレクトリにあります。

次にイベントXMLファイルのサンプルを示します。

<?xml version="1.0" encoding="UTF-8"?>
<Events xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../metadata/NotificationEvent.xsd">
<EventType name="User Created">
<StaticData>
<Attribute DataType="X2-Entity" EntityName="User" Name="Granted User"/>
<Attribute DataType="X2-Entity" EntityName="User" Name="Grantee User"/>
<Attribute DataType="91-Entity" EntityName="User Group" Name="User Grp"/>
</StaticData>
<Resolver class="oracle.iam.notification.DemoResolver">
<Param DataType="91-Entity" EntityName="Resource" Name="ResourceInfo"/>
</Resolver>
</EventType>
</Events>

このイベントXMLファイルには、次の要素があります。

- EventType name: イベントに通知テンプレートを作成する際に利用できるイベントの名前。

- StaticData: 静的パラメータのリスト。ユーザーは、このパラメータ・セットに、データ依存ではないパラメータを追加できます。つまり、この要素では、通知テンプレートが構成されるときに表示される静的データを定義します。たとえば、ユーザー・エンティティはデータ依存ではなく、解決されたときに、すべてのイベント・インスタンスおよび通知テンプレートに対して同じ属性セットを持ちます。

- Param DataType: 動的パラメータのリスト。ユーザーは、このパラメータ・セットに、データ依存のパラメータを追加できます。たとえば、Resourceエンティティはデータ依存です。このフィールドに対応する参照がUIに表示されます。ユーザーがこのリソース・オブジェクトを選択すると、そのコールは、ツリー(ユーザーはここからテンプレートで使用する属性を選択します)に表示されるフィールドを取得するために提供されているリゾルバ・クラスに向かいます。

注意:

使用可能なデータとは、テンプレートにトークンとして組み込むことのできる属性のリストです。これらのトークンは、ランタイム時にリゾルバ・クラスによって渡される値と置き換えられます。トークンの例は、Oracle Fusion Middleware Oracle Identity Manager開発者ガイドの通知テンプレートの作成に関する説明の手順7を参照してください。

使用できるデータは、Oracle Fusion Middleware Oracle Identity Manager開発者ガイドの通知テンプレートの作成に関する説明に示されるように、通知テンプレートの作成中にドロップダウン・リストに表示されます。

選択されたデータは単一の属性であり、ユーザーが属性名をコピーして通知テンプレートに貼り付ける際に役立ちます。選択されたデータの属性名は、「使用可能なデータ」リストで選択されたものと同じです。

検索でサポートされる動的エンティティは、ユーザー、リソースおよび組織です。これらのエンティティ名をParam DataType要素で指定する必要があります。

注意:

<Param DataType>要素は、必須要素ではありません。ただし、使用する際は、エンティティ名にUser、ResourceまたはOrganizationを指定する必要があります。

- Resolver class: リゾルバ・クラスは、通知ごとに定義する必要があります。これは、通知作成画面で使用できるパラメータと、それらのパラメータを通知の送信時に置き換える方法を定義します。つまり、リゾルバ・クラスは、ランタイム時にデータを動的に解決し、UIに属性を表示します。リゾルバ・クラスの実装の詳細は、「リゾルバ・クラスの作成」を参照してください。

通知サービスは、XMLファイルをMDSから、またはプラグインのMETA-INFフォルダから読み取ります。イベントXMLファイルは、Oracle Enterprise Managerを使用してMDSにアップロードできます。詳細は、「通知イベントのデプロイ」を参照してください。

イベントXMLの推奨の使用方法は、プラグインのMETA-INFディレクトリに配置することです。このプラグインの構造は次のとおりです。

- lib/ディレクトリ

- PLUG_IN.jar

- META-INFディレクトリ

- metadata.xml

- plugin.xml

プラグインJARの作成およびプラグイン登録ユーティリティを使用したデプロイの詳細は、プラグインの開発に関する説明を参照してください。

34.2.1.1.1 通知イベントのデプロイ

通知イベントをデプロイするには、次の手順を実行します。

1. Oracle Enterprise Managerを使用して、イベント・メタデータXMLファイルをメタデータ・ストア(MDS)にアップロードします。
MDSリポジトリとの間のデータのエクスポートおよびインポートの詳細は、「ユーザーが修正可能なメタデータ・ファイルの移行」を参照してください。

2. リゾルバ・クラスを含むJARファイルを、Oracle Identity Managerデータベースにアップロードします。リソース・バンドルおよびJARファイルをOracle Identity Managerデータベースにアップロードするためのユーティリティは、OIM_HOME/bin/ディレクトリにあります。
リソース・バンドルおよびJARユーティリティのアップロードの詳細は、「JARおよびリソース・バンドルの移行」を参照してください。

34.2.1.2 リゾルバ・クラスの作成

すべてのクラスが、NotificationEventResolverインタフェースを実装する必要があります。このインタフェースは、次のメソッドを提供します。

getAvailableDataメソッド

public List<NotificationAttribute> getAvailableData(String eventType, Map<String, Object> params);

このAPIは、使用可能なデータ変数のリストを戻します。この変数は、テンプレートの作成時や変更時にUI上で使用でき、ユーザーはこの変数を選択して、この変数をテンプレート上のメッセージの一部にすることができます。

eventTypeパラメータは、テンプレートが読み取られるイベント名を指定します。

paramsパラメータは、使用可能なデータがフェッチされるエンティティ名および対応する値を持つマップです。次に例を示します。

map.put("Resource", "laptop");

これは、リゾルバ・クラスで指定したコードに従って、laptopリソースまたはその他のデータに関連付けられたフィールドをフェッチする際に役立ちます。

サンプル・コードを次に示します。

/**
* this is a dummy implementation and uses hardcoded values
* Implementors need to iterate the XML as found through the event type
* params : will have all the specific values that your resolver needs
* for instance resource name = "laptop" that you may want here to be resolved through your custon implementation
*/

List<NotificationAttribute> list = new ArrayList<NotificationAttribute>(); NotificationAttribute subatr = new NotificationAttribute(); subatr.setName("Dynamic1"); subatr.setType("91-Entity"); subatr.setEntityName("Resource"); subatr.setRequired(false); subatr.setSearchable(true); subatr.setSubtree(lookup91EntityMetaData("resource"), params.get(0)); list.add(subatr);

メイン・ツリーにはエンティティ情報が含まれ、サブツリーにはUIで使用可能なすべてのノードが含まれます。サブツリー内の各ノードからの名前フィールドは、UI上で選択できます。

getReplacedDataメソッド

HashMap<String, String> getReplacedData(String eventType, Map<String, Object> params);

このAPIは、通知を送信するときに、実行時にテンプレートで提示された変数の解決された値を戻します。

eventTypeパラメータは、テンプレートが読み取られるイベント名を指定します。

paramsパラメータは、テンプレート内の残りの変数を解決するためにリゾルバで必要とされるベース値(usr_key、obj_keyなど)を持つマップです。

サンプル・コードを次に示します。

HashMap<String, Object> resolvedData = new HashMap<String, Object>(); resolvedData.put("shortDate", new Date()); resolvedData.put("longDate", new Date());
String firstName = getUserFirstname(params.get("usr_key")); resolvedData.put("fname", firstName); resolvedData.put("lname", "lastname"); resolvedData.put("count", "1 million");
return resolvedData;

例: カスタム・リゾルバ・クラスの作成

プロキシとして、追加されたユーザーに電子メール通知を送信するOracle Identity Managerの例を考えてみます。通知電子メールの日付書式を変更する必要がある場合は、次のように実行します。

1. プロキシを追加する際に、通知用の新しいリゾルバ・クラス・ファイル(AddProxyResolverModifiedなど)を作成します。AddProxyResolverModifiedリゾルバ・クラスのコードは次のとおりです。

package oracle.iam.selfservice.notification;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Date;
import java.util.logging.Level;
import java.text.ParseException;
import java.text.SimpleDateFormat;

import static oracle.iam.identity.utils.Constants.PROXY_START_DATE;
import static oracle.iam.identity.utils.Constants.PROXY_END_DATE;
import static oracle.iam.identity.utils.Constants.PROXY_ORIGINAL_USR_NAME;
import static oracle.iam.identity.utils.Constants.PROXY_ORIG_USER_LOGIN;
import static oracle.iam.identity.utils.Constants.FIRSTNAME;
import static oracle.iam.identity.utils.Constants.LASTNAME;
import oracle.iam.notification.impl.NotificationEventResolver;
import oracle.iam.notification.vo.NotificationAttribute;

/* $Header: iam/iam-product/features/selfservice/src/main/oracle/iam/selfservice/notification/AddProxyResolver.java /main/2 2012/02/13 20:46:50 shaimish Exp $ */

/* Copyright (c) 2010, 2012, Oracle and/or its affiliates.
All rights reserved. */

/*
DESCRIPTION
<short description of component this file declares/defines>

PRIVATE CLASSES
<list of private classes defined - with one-line descriptions>

NOTES
<other useful comments, qualifications, etc.>

MODIFIED    (MM/DD/YY)
supandit    04/19/10 - Creation
*/

/**
*  @version $Header: iam/iam-product/features/selfservice/src/main/oracle/iam/selfservice/notification/AddProxyResolver.java /main/2 2012/02/13 20:46:50 shaimish Exp $
*  @author  supandit
*  @since   release specific (what release of product did this appear in)
*/

public class AddProxyResolverModified implements NotificationEventResolver {
public List<NotificationAttribute> getAvailableData(String eventType, Map<String, Object> params) throws Exception {
return null;
}

public HashMap<String, Object> getReplacedData(String eventType, Map<String, Object> params)throws Exception {

SimpleDateFormat sdfSource = new SimpleDateFormat("MMMMMMMM DD,yyyy HH:mm:ss a z");
SimpleDateFormat sdfDestination = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z");
Date sdate = null;
Date edate = null;

HashMap<String, Object> resolvedData = new HashMap<String, Object>();
resolvedData.put("firstName",params.get(FIRSTNAME));
resolvedData.put("lastName",params.get(LASTNAME));
resolvedData.put("originalusername",params.get(PROXY_ORIG_USER_LOGIN));

String proxy_startDate = (String )params.get(PROXY_START_DATE);
System.out.println("proxy_startDate : " + proxy_startDate);
String proxy_endDate = (String)  params.get(PROXY_END_DATE);
System.out.println("proxy_endDate : " + proxy_endDate);

sdate = sdfSource.parse(proxy_startDate);
edate = sdfSource.parse(proxy_endDate);

proxy_startDate = sdfDestination.format(sdate);
System.out.println("proxy_startDate : " + proxy_startDate);
proxy_endDate = sdfDestination.format(edate);
System.out.println("proxy_endDate : " + proxy_endDate);

resolvedData.put("proxystartdate", proxy_startDate);
resolvedData.put("proxyenddate", proxy_endDate);
return resolvedData;
}
}

これにより、通知電子メールの書式が変更されます。元の書式は次のとおりです。

September 13, 2012 7:00:00 AM GMTからSeptember 14, 2012 7:00:00 AM GMTまでのtestuser1 testuser1 [TESTUSER1]のプロキシを作成しました。

変更後は次のとおりです。

Fri, 13 Jan 2012 23:00:00 -0800からSat, 14 Jan 2012 23:00:00 -0800までのtestuser1 testuser1 [TESTUSER1]のプロキシを作成しました。

2. プラグインZIPファイルをOIM_HOME/server/plugins/にコピーします。

3. 次のコードを含むAddProxyUser.xmlを作成します。

<?xml version='1.0' encoding='UTF-8'?>
<Events xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../notification/metadata/NotificationEvent.xsd" xmlns="http://xmlns.oracle.com/oim/notificationevent">
<EventType name="AddProxy">
<Resolver class="oracle.iam.selfservice.notification.AddProxyResolverModified">
<Param Name="AddProxy" DataType="X2-Entity" EntityName="AddProxy"/>
</Resolver>
</EventType>
</Events>

4. MDSで宣言されている元のリゾルバが優先されます。したがって、AddProxyUser.xmlファイルを/metadata/iam-features-selfservice/notification/にあるMDSにインポートします。

34.2.2 リゾルバ・クラスを含むプラグイン・パックの作成

リゾルバ・クラスの作成後、プラグインJARファイルにパッケージ化し、プラグイン登録ユーティリティを使用してJARファイルをデプロイします。プラグインJARの作成およびプラグイン登録ユーティリティを使用したデプロイの詳細は、プラグインの開発に関する説明を参照してください。

34.2.3 起動ロジックの構築

イベント・メタデータXMLを定義し、リゾルバ・クラスを作成することで、通知ロジックを構築した後、Oracle Identity Managerの特定の操作で通知ロジックをコールできます。これは、イベント・ハンドラを使用することで実行できます。

通知の起動ロジックは、カスタム・イベント・ハンドラとして構築されます。カスタム・イベント・ハンドラは、関連する操作の適切なステージに構成されます。カスタム・イベントは、プラグイン登録ユーティリティを使用してデプロイされます。イベント・ハンドラの開発の詳細は、「イベント・ハンドラの開発」を参照してください。

34.2.4 通知サービスの構成

通知のインフラストラクチャレベルの構成の作成には、次のオプションがあります。

- Oracle Identity Managerでのインフラストラクチャレベルの構成の作成: 電子メール・サーバーは、Oracle Identity Managerのデフォルトのモードとしてサポートされています。

- SOAでのインフラストラクチャレベルの構成の作成: SOAですべての通知モードがサポートされています。したがって、SOAでユーザー・メッセージング・サービス(UMS)を使用するように、通知サービスを構成できます。

通知サービスの構成の詳細は、Oracle Fusion Middleware Oracle Identity Manager開発者ガイドの通知プロバイダの管理に関する説明を参照してください。

注意:

Design Consoleの「電子メール定義」フォームを使用したプロビジョニング・プロセスで使用する電子メール定義を構成できます。詳細は、「「電子メール定義」フォーム」を参照してください。

34.3 通知のトラブルシューティング

通知の構成後、「診断ダッシュボード」で使用可能な「通知構成テスト」を使用して、構成をテストできます。そのためには、「診断ダッシュボード」コンソールからこのテスト用のパラメータとして有効なユーザー・ログインを指定します。

有効な電子メールIDが指定されたログインに存在し、テストの結果が図34-1と同様である場合、ダミーのユーザー作成メールが送信されます。

図34-1 通知構成テスト

この項では、UMS構成で発生する可能性のある次の問題および対応する解決策について説明します。

- 誤ったURLに関連する問題

- 送信サーバーの電子メール・ドライバの誤ったプロパティ

- SOAサーバーで生成されるエラー

- 認証の失敗

- EMを介してレポートされない失敗した電子メール配信に関する問題

34.3.1 誤ったURLに関連する問題

問題

Oracle Identity Managerログに次のエラーが表示されます。

<Jun 13, 2012 12:53:25 AM PDT> <Warning> <oracle.adfinternal.view.faces.renderkit.rich.SelectItemUtils> <ADF_FACES-30118> <No help provider found for helpTopicId=create_user.>
java.net.MalformedURLException: For input string: "SOA_PORT"
at java.net.URL.<init>(URL.java:601)
at java.net.URL.<init>(URL.java:464)
at java.net.URL.<init>(URL.java:413)
at java.net.URI.toURL(URI.java:1081)
at oracle.j2ee.ws.common.transport.HttpTransport.transmit(HttpTransport.java:61)
at oracle.j2ee.ws.common.async.MessageSender.call(MessageSender.java:64)
at oracle.j2ee.ws.common.async.Transmitter.transmitSync(Transmitter.java:134)
at oracle.j2ee.ws.common.async.Transmitter.transmit(Transmitter.java:90)
at oracle.j2ee.ws.common.async.RequestorImpl.transmit(RequestorImpl.java:273)
at oracle.j2ee.ws.common.async.RequestorImpl.invoke(RequestorImpl.java:94)
at oracle.j2ee.ws.client.jaxws.DispatchImpl.invoke(DispatchImpl.java:811)
at oracle.j2ee.ws.client.jaxws.OracleDispatchImpl.synchronousInvocationWithRetry(OracleDispatchImpl.java:235)
at oracle.j2ee.ws.client.jaxws.OracleDispatchImpl.invoke(OracleDispatchImpl.java:106)
at oracle.j2ee.ws.client.jaxws.WsClientProxyInvocationHandler.invoke(WsClientProxyInvocationHandler.java:254)
at $Proxy422.send(Unknown Source)
at oracle.ucs.messaging.ws.MessagingClient.send(MessagingClient.java:299)
at oracle.iam.notification.provider.UMSEmailServiceProvider.sendMessage(UMSEmailServiceProvider.java:188)
at oracle.iam.notification.provider.UMSEmailServiceProvider.sendNotification(UMSEmailServiceProvider.java:173)
at oracle.iam.notification.impl.NotificationServiceImpl.sendEmailNotification(NotificationServiceImpl.java:601)
at oracle.iam.notification.impl.NotificationServiceImpl.notify(NotificationServiceImpl.java:540)
at oracle.iam.notification.impl.NotificationServiceImpl.notify(NotificationServiceImpl.java:271)
<Jun 13, 2012 12:53:31 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Provider UMSEmailServiceProvider has encountered exception : null>
<Jun 13, 2012 12:53:31 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Sending notification with Provider UMSEmailServiceProvider has encountered exception : Error occured while Sending Notification through Provider UMSEmailServiceProvider : null>
<Jun 13, 2012 12:53:31 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Sending notification with Provider UMSEmailServiceProvider detailed exception : null>

解決策

これは、不正なURLが原因のエラーです。この問題を解決するには、Enterprise Manager (EM)のSOA_PORTおよびSOA_HOSTに正しい値を指定します。

問題

Oracle Identity Managerログに次のエラーが表示されます。

<Jun 13, 2012 3:14:14 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Provider UMSEmailServiceProvider has encountered exception : javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Bad response: 404 Not Found from url http://myhost.mycompany.com:8003/ucs/messaging/webservice>
<Jun 13, 2012 3:14:14 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Sending notification with Provider UMSEmailServiceProvider has encountered exception : Error occured while Sending Notification through Provider UMSEmailServiceProvider : javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Bad response: 404 Not Found from url http://myhost.mycompany.com:8003/ucs/messaging/webservice>
<Jun 13, 2012 3:14:14 AM PDT> <Error> <oracle.iam.notification.impl> <BEA-000000> <Sending notification with Provider UMSEmailServiceProvider detailed exception : javax.xml.soap.SOAPException: javax.xml.soap.SOAPException: Bad response: 404 Not Found from url http://myhost.mycompany.com:8003/ucs/messaging/webservice>

解決策

これは、不正なURLが原因のエラーです。この問題を解決するには、EMに正しいURLを指定します。

34.3.2 送信サーバーの電子メール・ドライバの誤ったプロパティ

問題

次のエラーが生成されます。

<Jun 13, 2012 3:39:14 AM PDT> <Error> <oracle.sdp.messaging.driver.email> <SDP-25700> <An unexpected exception was caught.
javax.mail.MessagingException: Unknown SMTP host: abc.oracle.com;
nested exception is:
java.net.UnknownHostException: abc.oracle.com
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1389)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: java.net.UnknownHostException: abc.oracle.com
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:195)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:163)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1359)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>

解決策

この問題は、送信サーバーの電子メール・ドライバの誤ったプロパティが原因で発生します。この問題を修正するには、正しいサーバー・アドレスを指定し、サーバーが実行していることを確認します。

34.3.3 SOAサーバーで生成されるエラー

問題

次のエラーが生成されます。

<Jun 13, 2012 3:53:20 AM PDT> <Error> <oracle.sdp.messaging.driver.email> <SDP-25700> <An unexpected exception was caught.
javax.mail.MessagingException: Could not connect to SMTP host: stbeehive.oracle.com, port: 25;
nested exception is:
java.net.ConnectException: Connection refused
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1391)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy345.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:163)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1359)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy345.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>

解決策

これは、SOAサーバーのエラーです。この問題を修正するには、送信サーバー・ポートおよび送信サーバー・セキュリティが適切であることを確認します。

34.3.4 認証の失敗

問題

次のエラーが生成されます。

javax.mail.AuthenticationFailedException

または

<Jun 13, 2012 4:30:41 AM PDT> <Error> <oracle.sdp.messaging.driver.email> <SDP-25700> <An unexpected exception was caught.
javax.mail.MessagingException: Exception reading response;
nested exception is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1611)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1369)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1731)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1170)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:785)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:110)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:88)
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1589)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1369)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:323)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:217)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1170)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:785)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:110)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:88)
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1589)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1369)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:318)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:217)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1170)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:785)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:110)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:88)
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1589)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1369)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:412)
at javax.mail.Service.connect(Service.java:310)
at javax.mail.Service.connect(Service.java:169)
at javax.mail.Service.connect(Service.java:118)
at oracle.sdpinternal.messaging.driver.email.EmailDriver.send(EmailDriver.java:780)
at oracle.sdpinternal.messaging.driver.email.EmailManagedConnection.send(EmailManagedConnection.java:50)
at oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy349.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
>

解決策

次の項目を必ず実行してください。

- ユーザー名およびパスワードが正しく指定されていること。

- DemoTrust.jksのエンティティがsetDomainEnvスクリプトから削除されていること。

- アプリケーション・サーバーが正しく構成されていること。

- 証明書の交換が完了していること。

34.3.5電子メール配信の失敗がEMを介してレポートされない問題

問題

Enterprise Manager (EM) Usermessagingserverメッセージ・ステータスでは、電子メールが無効であっても、ステータス・コードが常にDELIVERY_TO_GATEWAY_SUCCESSになります。ユーザーが電子メールを受信しない場合でも、このステータス・コードが更新されて失敗になることはありません。

解決策

ドライバ構成の次の受信設定が適切に構成されていることを確認します。

- MailAccessProtocol

- ReceiveFolder

- IncomingMailServer

- IncomingMailServerPort

- IncomingMailServerSSL

- IncomingMailIDs

- IncomingUserIDs

- IncomingUserPasswords

- ImapAuthPlainDisable

詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する項を参照してください。

35 コールバック・サービスの使用

コールバック・サービスは、Oracle Identity Managerのイベント処理中に、事前定義済ポイントでデプロイ固有のロジックを呼び出します。コールバック・サービスについては、次の項で説明します。

- コールバック・サービスの概要

- Oracle Identity Manager属性のマッピング

- イベント・コールバックの送信

- コールバック・サービスの構成

- コールバック・サービスのトラブルシューティング

35.1 コールバック・サービスの概要

コールバック・サービスは、外部アプリケーションがOracle Identity Managerのイベント処理の一環としてなんらかのアクションを実行できるようにする通知およびコールバックをトリガーします。たとえば、Oracle Identity Managerを使用してユーザーが作成された場合、このタイプのプロビジョニング・イベントの通知を受け取るよう登録されている外部アプリケーションに通知され、これによりアプリケーションは、同じユーザー情報を独自のローカル・データ・ストアに追加できます。これは通知と呼ばれます。通知により、アプリケーションは変更内容とデータを同期できます。

注意:

外部アプリケーションのWebサービス・エンドポイントは、コールバック・サービス構成に登録されている必要があります。詳細は、「コールバック・サービスの構成」を参照してください。

外部アプリケーションがOracle Identity Managerでユーザー・プロビジョニング・イベントを開始した場合、このタイプのプロビジョニング・イベントの通知を受け取るよう登録されているその他の外部アプリケーションは、Oracle Identity Managerから通知を受け取ります。Oracle Identity Manager自体がプロビジョニング・プロセスの一環として外部アプリケーションによって呼び出された場合、その通知はコールバックと呼ばれます。したがって、コールバックとは、単に、外部アプリケーションの通知の後に、Oracle Identity Managerへのコールバックが続くものです。コールバックは、すべての登録済パーティとOracle Identity Managerとの間のイベントに関する情報を同期します。コールバックでは、イベントの成功または失敗のステータスを示すこともできます。

注意:

コールバック・サービス・インフラストラクチャは、コールバックと通知の両方を処理します。このドキュメントでは、コールバックはこの両方を示しています。

コールバック・サービスによって処理されるコールバック・タイプは複数あります。これらを次に示します。

- 外部アプリケーションに返される後処理コールバック。たとえば、構成済のOracle Identity Managerデータ・ストア内のユーザー・プロファイルをプロビジョニングするリクエストは、Webサービス・コールとして外部アプリケーションからOracle Identity Managerに送信されます。プロファイルが作成され、後処理コールバックがアプリケーションに返されて、プロファイル作成が確定します。これらのコールバックは、Oracle Identity Managerの構成に応じて、同期または非同期となります。

- リクエスト・ステータスになんらかの変更があると、ステータス変更コールバックが関連するパーティに送信されます。たとえば、ユーザーのプロビジョニング・リクエストのステータスが完了または失敗に変更された場合、または職務の分離(SoD)チェックによりリクエスト・ステータスの変更が認識された場合、ステータス変更コールバックが送信されます。

注意:

この機能は、以前は完了コールバックと呼ばれていました。

- コールバック・レスポンスが、サード・パーティによって生成され、後処理コールバックへのレスポンスが返されることをOracle Identity Managerに通知します。このコールバック・レスポンス・サービスは、「コールバック・サービスの構成」で説明されているように手動で構成されます。

コールバック・サービスは、ユーザー・インタフェース、Oracle Identity ManagerリクエストAPI、Service Provisioning Markup Language (SPML)クライアントを含むあらゆるソースからのイベントに対してコールバックを呼び出すように構築されています。これは、非同期クライアント・コールバックへのレスポンスを受信するリスナー・サービスです。クライアントWebサービスが呼び出されると、Oracle Identity Managerは一意の識別子を生成し、それをコールとともに送信します。クライアントは、応答時にこの識別子を使用して、レスポンスと元のWebサービス・リクエストを相関させる必要があります。コールバック・サービスは、クライアント・レスポンスに基づいて適切なアクションを実行します。次の項では、コールバック・サービスのコンポーネントについて詳しく説明します。

- コールバックの使用

- イベント処理の理解

- コールバックの再試行

35.1.1 コールバックの使用

この項では、Oracle Identity Managerコールバックのユースケースについて説明します。このユースケースは、職務の分離(SoD)ステータス変更通知に固有のものです。このユースケースは、既存のユーザーで、POApproverロールのメンバーであるJames Northに関するものです。Jamesは、POCreatorおよびBuyerという2つの追加ロールをリクエストしています。このリクエストは、次のプロセスに従って処理されます。

1. Oracle Identity Managerは、リクエストを受信し、IDが21の「ロールの割当て」リクエストを作成します。
リクエストIDは、Oracle Identity Managerによって生成される一意の識別子であり、リクエストを今後のレスポンスと通信に相関させるために使用されます。

2. Oracle Identity Managerは、Oracle Applications Access Control Governor (OAACG)を使用してSoD検証を開始します。

3. Oracle Identity Managerリクエスト・ステータスが変更され、「SODチェック中です」を示すコールバックがコールバック登録Webサービスに返されます。このコールバックには、リクエストID、リクエストされた操作(MODIFY)、ターゲット・タイプ(IDENTITY)、ターゲットGUID (JNORTH)およびロケール(en_US)が含まれています。

4. OAACGは、Buyerロールは許容できるが、POCreaterロールはJamesの既存のPOApproverロールが原因で違反していることを示す「条件付承認」レスポンスを返します。

5. Oracle Identity Managerリクエスト・ステータスが変更され、「SOD改善中です」を示す2番目のコールバックがコールバック登録Webサービスに返されます。前のコールバックと同じ識別情報が含まれています。

6. CFOOVERRIDEという名前のタグが拒否ノートに配置され、最高財務責任者(CFO)がこの違反を選択的ケースで承認できることを示します。
OVERRIDEが最後に付くタグが拒否ノートに配置されている場合に例外承認を呼び出すようにOBRルールを構成する必要があります。

7. AMXルールがタグを解読し、CFOの肩書きを持つ人物にタスクが割り当てられるようにするにはCFO承認が必要であることを判断します。

8. CFOがリクエストを承認または拒否します。

1. リクエストが拒否されると、Oracle Identity Managerリクエスト・ステータスが変更され、3番目のコールバックが「SOD改善が却下されました」として返されます。これで、Oracle Identity Managerリクエストは、「SOD改善が却下されました」ステータスでクローズされます。

注意:

リクエストの一部分が拒否されると、そのリクエスト全体が拒否されます。したがって、この例では、BuyerロールにSoD違反はありませんが、ユーザーにプロビジョニングされません。

2. リクエストが承認されると、Oracle Identity Managerリクエスト・ステータスが変更され、3番目のコールバックが「SOD改善が承認されました」として返されます。Oracle Identity Managerリクエストは、「SOD改善が承認されました」ステータスで更新されます。OAACGおよびリクエスト側アプリケーションに承認が通知され、ロールがプロビジョニングされます。

9. Oracle Identity Managerリクエスト・ステータスが「リクエストが完了しました」に変更されると、「リクエストが完了しました」ステータスでリクエストが完了したことを示す最後のコールバックが、すべてのコールバック登録Webサービスに送信されます。

35.1.2 イベント処理の理解

図35-1に、イベントが処理される方法を示します。Oracle Identity Managerは非同期呼出しを使用しますが、これにより、ヒューマン承認ワークフローの開始など、必要に応じてイベントを処理する柔軟性がコール側アプリケーションに提供されます。

図35-1 コールバック・サービス・プロセス

このリリースのコールバック・サービスでは、ハンドラおよびプラグイン・イベントがサポートされています。これらを次に示します。

- 後処理ハンドラ: イベントが処理された後、かつリクエストが完了としてマークされる前に呼び出されます。デフォルトの後処理ハンドラは、コールバック・サービス構成に基づいて複数のコールバックを呼び出します。

- ステータス変更プラグイン: リクエスト・ステータスに変更があった場合(ユーザー・プロビジョニング・リクエストのステータスが完了や失敗に変更された場合など)、または職務の分離(SOD)チェックによりリクエスト・ステータス変更が認識された場合に呼び出され、ステータス変更コールバックが送信されます。デフォルトのステータス変更プラグインは、コールバック・サービス構成に基づいて複数のコールバックを呼び出す場合があります。

35.1.3 コールバックの再試行

コールバック・サービスは、サービスを呼び出すときにネットワーク・エラーがあった場合は、コールバックを再試行します。Oracle Identity Managerは、固定された間隔である5秒後に、固定された回数である3回のコールバックを再試行します。これらの値は構成できません。

35.2 Oracle Identity Manager属性のマッピング

Oracle Identity Managerで使用される属性の名前は独自の名前です。たとえば、サード・パーティのアプリケーションではユーザーの姓をsurnameと呼ぶ場合がある一方で、Oracle Identity Managerでは「姓」を使用します。このため、属性マッピングが不可欠です。

注意:

コールバック・サービスでは、Oracle Identity ManagerのService Provisioning Markup Language (SPML)レイヤーで定義されているのと同じ属性を使用します。これらは、(単称として)SPMLプロビジョニング・サービス・オブジェクト(PSO)と呼ばれます。詳細は、「SPML属性とLDAPマッピング、およびOracle Identity Managerの属性」を参照してください。

マッピングされた属性名は、送信されたメッセージおよびコールバック構成(特にConstraintAttributeパラメータ)で使用されます。表35-1では、Oracle Identity Managerユーザー・タイプ属性が、SPML PSOを使用してコールバックでどのように表されるかを定義しています。

表35-1 Oracle Identity Managerとコールバック・サービス・ユーザー属性のマッピング

コールバック・サービス属性(PSO)

Oracle Identity Managerユーザー属性

activeEndDate

終了日

activeStartDate

開始日

commonName

一般名

countryName

国

departmentNumber

部門番号

description

説明

displayName

氏名

employeeNumber

従業員番号

employeeType

ロール

facsimileTelephoneNumber

FAX

generationQualifier

世代修飾子

hireDate

入社日

homePhone

自宅電話番号

homePostalAddress

自宅住所

initials

イニシャル

localityName

地方名

mail

電子メール

middleName

ミドル・ネーム

mobile

モバイル

organization

LDAP組織

organizationUnit

LDAP組織単位

pager

ページャ

password

パスワード

postalAddress

住所

postalCode

郵便番号

postOfficeBox

私書箱

preferredLangauage

言語

state

都道府県

street

番地

surname

姓

telephoneNumber

電話番号

title

役職

userId

usr_key

userName

ユーザー・ログイン

表35-2は、Oracle Identity Managerロール・タイプ属性が、SPML PSOを使用してコールバックでどのように表されるかを定義しています。

表35-2 Oracle Identity Managerとコールバック・サービス・ロール属性のマッピング

コールバック・サービス属性(PSO)

Oracle Identity Managerロール属性

commonName

ロール名

description

ロールの説明

displayName

表示名

属性名がこれらの表のいずれにもない場合は、そのOracle Identity Manager属性で参照されます。

35.3 イベント・コールバックの送信

デフォルトでは、コールバックは、EventHandlers.xml(プロビジョニング・プロセスの後処理ステージで編成エンジンによって呼び出されるハンドラ)にリストされているすべてのOracle Identity Managerイベントに対して有効化されています(送信されます)。各イベントにより、適用可能なエンティティ・タイプおよび操作が指定されます。構成を変更することで、特定のコールバックを無効化できます。表35-3に、Oracle Identity Managerがコールバックを作成するユーザーとロールのイベント、およびコールバックで返される情報についてまとめます。

表35-3 コールバック開始イベント

エンティティ/操作

イベント・イニシエータ

後処理ハンドラで返される情報

ステータス変更プラグイン・コールバックで返される情報

ユーザー作成

サード・パーティ・リクエストのみ。ユーザーが、コンソールを使用して、またはリコンシリエーション・イベントを介して作成された場合、コールバックは発生しません。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 作成された属性および値(パスワードとチャレンジ質問は除く)が含まれたプロビジョニング・サービス・オブジェクト(PSO)
注意: PSOは作成操作に使用されます。変更オブジェクトは変更操作に使用されます。

- ユーザーに割り当てられたロール

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー変更

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 変更された属性および値(パスワードとチャレンジ質問は除く)が含まれた変更オブジェクト*

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー削除

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー一時停止(無効化)

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー再開(有効化)

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー割当てロール - memberOfの追加

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 割当て済ロールのGUIDが含まれた変更オブジェクト*

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ユーザー失効ロール - memberOfの削除

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 割当て済ロールのGUIDが含まれた変更オブジェクト*

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ロール追加

サード・パーティ・リクエストのみ。ロールが、コンソールを使用して、またはリコンシリエーション・イベントを介して作成された場合、コールバックは発生しません。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 作成された属性および値が含まれたPSO*

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ロール変更

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- 変更された属性および値が含まれた変更オブジェクト*

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

ロール削除

すべてのソース: サード・パーティ・リクエスト、コンソール、およびリコンシリエーション・イベント経由。

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

- OIMリクエスト・ステータス

- ターゲット・タイプ

- ターゲットGUID

- 操作

- リクエストID

35.4 コールバック・サービスの構成

コールバック・サービスの構成では、1つ以上のコールバックが呼び出される方法およびタイミングを指定します。次の項では、構成ファイル、およびこのファイルをメタデータ・サービス・リポジトリにインポートする手順について説明します。

- CallbackConfiguration.xmlの理解

- CallbackConfiguration.xmlのインポート

- OIM.DefaultTenantGUIDシステム・プロパティの追加

35.4.1 CallbackConfiguration.xmlの理解

構成は、CallbackConfiguration.xmlと呼ばれる単一ファイルに格納されています。構成ファイルは、Oracle Identity Managerメタ・ディレクトリ・リポジトリにあります。デフォルトのイベント・ハンドラおよび検証プラグインによって使用されます。次のパラメータを構成できます。

- Policy name: コールバック・ポリシーの名前を定義します。値は、プロビジョニング・リクエストから取得されます。これは、Oracle Identity Manager固有であり、文字列値を使用します。

- Entity type: コールバック・ポリシーを適用できるエンティティ・タイプのことです。必須で、単一の値です。可能な値は、User、RoleおよびRoleUserです。

- Operation: コールバック・ポリシーを適用できるデータベース操作のことです。必須値は、CreateまたはDeleteのいずれかです。

- Description: ポリシーの説明である、ローカライズされた文字列を使用します。

- ConstraintAttributeおよびConstraintAttributeValue: 指定されたオブジェクトに対して特定のコールバックを呼び出すかどうかをハンドラおよびプラグイン・コードが決定できる、単純な制約を指定するフィールドです。この属性は、編成データまたはRequestDataのいずれかの形式で、ハンドラに対して使用可能になっているエンティティ・データで検索されます。データが存在しない場合、この制約は適用されません。

- ConstraintAttribute: 制約が指定される属性の名前を値として使用します。この名前は、Oracle Identity Manager側で定義された名前ではなく、アプリケーション側で定義された属性名である必要があります。詳細は、「Oracle Identity Manager属性のマッピング」を参照してください。

- ConstraintAttributeValue: ConstraintAttributeでの値と同じ値を使用します。ここでの値は、編成データまたはリクエスト・データに存在するConstraintAttributeの値と同じである必要があります。データに複数の値がある場合は、少なくとも1つが一致する必要があります。このパラメータは、ConstraintAttribute自体に値がある場合にのみ関係します。

注意:

ConstraintAttributeおよびConstraintAttributeValueは、コールバック・ポリシーの複数値属性ではありません。したがって、コールバック・ポリシーごとに1つのみのconstraintAttributeおよびconstraintAttributeValue属性を指定します。1つのコールバック・ポリシーに複数のconstraintAttributeおよびconstraintAttributeValueを指定すると、すべての制約が一致しない場合でもコールバックがトリガーされます。

- テナントGUID: Oracle Identity Managerのマルチテナント(MT)・モードで適用できるコールバック・ポリシーのテナントGUIDを示します。MTモードのポリシーのコールバックURLはそれぞれ異なるため、テナントGUIDは、コールバックが送信されるテナントを一意に識別できるように指定する必要があります。このタグの使用方法の例は、<tenantGUID>202</tenantGUID>です。このタグは、非MTモードでは使用されません。

- Provisioning Steps: このコールバック・ポリシーを使用する必要がある編成手順を指定します。可能な値は次のとおりです。

- validation

- preProcessing

- approval

- postProcessing

- completion

- stepName: 外部アプリケーションのWebサービス・エンドポイントのことです。

- description: Webサービス・エンドポイントの説明を示す、ローカライズされた文字列を使用します。

- InvokeOnChange: 値として1つ以上の属性名を使用し、変更操作にのみ適用可能です。このコールバックは、このパラメータの値としてリストされているいずれかの属性が変更された場合にのみ呼び出されます。この値は、Oracle Identity Manager側で定義された名前ではなく、アプリケーション側で定義された属性名である必要があります。詳細は、「Oracle Identity Manager属性のマッピング」を参照してください。

- CallbackOnly: Oracle Identity Managerが外部アプリケーションからのレスポンスを待機するかどうかを指定します。可能な値はtrueまたはfalseです。trueの場合、Oracle Identity Managerはアプリケーションからのレスポンスを待機し、編成プロセスはレスポンスが受信されるまで待機します。falseの場合、Oracle Identity Managerはコールバック・レスポンスを待機せず、編成プロセスは続行されます。

- targetIDAttribute: メッセージでターゲットGUIDとして使用される属性を値として使用します。この値は、Oracle Identity Manager側で定義された名前ではなく、アプリケーション側で定義された属性名である必要があります。詳細は、「Oracle Identity Manager属性のマッピング」を参照してください。デフォルト値はLDAP GUIDです。

- roleIDAttribute: メッセージでロールGUIDとして使用されるロール属性を値として使用します。この値は、Oracle Identity Manager側で定義された名前ではなく、アプリケーション側で定義された属性名である必要があります。詳細は、「Oracle Identity Manager属性のマッピング」を参照してください。デフォルト値はLDAP GUIDです。

例35-1は、サンプル構成ファイルです。

例35-1 サンプルCallbackConfiguration.xml

<?xml version='1.0' encoding='UTF-8'?>
<callbackConfiguration xmlns="http://www.oracle.com/schema/oim/callback_config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/schema/oim/callback_config">
<policy>
<policyName>User Creation1</policyName>
<entityType>User</entityType>
<operation>Create</operation>
<description>Policy to create  a user in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>User Enable1</policyName>
<entityType>User</entityType>
<operation>Enable</operation>
<description>Policy to enable  a user in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>User Delete1</policyName>
<entityType>User</entityType>
<operation>Delete</operation>
<description>Policy to delete  a user in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>User Disable1</policyName>
<entityType>User</entityType>
<operation>Disable</operation>
<description>Policy to disable  a user in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>User Modify1</policyName>
<entityType>User</entityType>
<operation>Modify</operation>
<description>First Policy to modify  a user in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>Role Assign1</policyName>
<entityType>RoleUser</entityType>
<operation>CREATE</operation>
<description>Policy to assign roles to the user</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>Role Revoke1</policyName>
<entityType>RoleUser</entityType>
<operation>Delete</operation>
<description>Policy to revoke role from the user</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>Role Creation1</policyName>
<entityType>Role</entityType>
<operation>Create</operation>
<description>Policy to create  a role in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>Role Delete1</policyName>
<entityType>Role</entityType>
<operation>Delete</operation>
<description>Policy to delete  a role in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
<policy>
<policyName>Role Modify1</policyName>
<entityType>Role</entityType>
<operation>Modify</operation>
<description>Policy to modify  a role in the store</description>
<provisioningSteps>
<postProcessing>
<asyncSteps>
<stepName>http://myhost.mycompany.com:7001/testCallbackService/
PostProcessingPluginRequestPortImplTest</stepName>
<description>Webservice url for this policy</description>
</asyncSteps>
</postProcessing>
</provisioningSteps>
</policy>
</callbackConfiguration>

35.4.2 CallbackConfiguration.xmlのインポート

コールバック・サービスを構成する手順は、次のとおりです。CallbackConfiguration.xmlファイルのインポートを伴います。このファイルには、指定されたエンティティ・タイプまたは操作用のコールバック・ポリシーのリストが含まれています。

1. マップ名oimおよびキーappid.keycredentialsを使用して、資格証明ストア・フレームワーク(CSF)で資格証明エントリを作成します。
このエントリには、コールバックに対してOracle Identity Managerが自身を識別するために使用する、ユーザー名とパスワードが格納されています。CSFは、Oracle Identity Managerのインストール時にドメイン作成の一部として利用可能です。

関連項目:

資格証明ストア・フレームワークの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

2. Oracle Enterprise Managerを使用して、CallbackConfiguration.xmlをメタデータ・サービス(MDS)・リポジトリにインポートします。
/metadata/iam-features-callbacks/sample_data/ネームスペースにロードされます。

CallbackConfiguration.xmlをインポートする場合の考慮事項は、次のとおりです。

- CallbackConfiguration.xmlファイルが、MDSリポジトリの正しいメタデータ・ネームスペース(/metadata/iam-features-callbacks/sample_data/)にインポートされたことを確認します。

- 他のメタデータ・ネームスペースにある古いCallbackConfiguration.xmlファイルを削除します。たとえば、/metadata/iam-features-callbacks/old_config/CallbackConfiguration_st3b16.xmlや/metadata/iam-features-callbacks/old_config/CallbackConfiguration.xmlは、有効ではありません。weblogicDeleteMetadata.shを使用して、MDSリポジトリで見つかった無効なエントリをすべて削除します。

- インポート後にCallbackConfiguration.xmlに変更が加えられた場合は、変更されたファイルを説明に従って再インポートし、OIM_HOME/server/bin/ディレクトリにあるPurgeCache.shユーティリティを使用して、Oracle Identity Managerキャッシュをパージします。

35.4.3 OIM.DefaultTenantGUIDシステム・プロパティの追加

Oracle Identity Managerの非MTモードでは、OIM.DefaultTenantGUIDシステム・プロパティを、テナントGUIDの値を必要とするアプリケーションのテナントGUIDとして機能する値に設定する必要があります。このサンプル値は、201です。Oracle Identity Managerは、プロパティが設定されていない場合にはコールバックを送信しません。コールバックを受信するアプリケーションに固有のテナントGUIDが必要ない場合は、任意のランダムな値を指定します。

このシステム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の表5-2 デフォルト以外のシステム・プロパティを参照してください。

35.5 コールバック・サービスのトラブルシューティング

表35-4に、コールバック・サービス・エラーが発生した場合に実行できるトラブルシューティング手順を示します。

表35-4 コールバック・サービスのトラブルシューティング

問題

解決策

SPMLリクエストを送信できません(失敗した認証)。

SPMLリクエストが、有効なSPMLユーザー(SPML_App_Roleグループのメンバー)により、正しい資格証明を使用して送信されていることを確認します。

リクエストがクライアントAPIから送信されている場合は、互換性のあるクライアント・ポリシーが適用されている必要があることに注意してください。

次に、SPMLリクエストが不正な資格証明で送信された場合に表示されるサンプル・エラー・レスポンスを示します。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header/><env:Body><env:Fault xmlns:ns0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><faultcode>ns0:FailedAuthentication</faultcode><faultstring>FailedAuthentication : The security token cannot be authenticated.</faultstring><faultactor/></env:Fault></env:Body></env:Envelope>

ロールの割当てなど、所定のリクエスト・タイプの場合、Oracle Identity Managerは、policyNameが一致するのが1つのコールバック・サービスであっても、複数のコールバックWebサービスに対する複数のコールバックを作成します。

これは、callbackOnlyが、適格なエンティティ・タイプおよび操作(ロールの割当てリクエスト・タイプなど)すべてに関してfalseに設定されていると、一致するすべてのエンティティ・タイプおよび操作に対してコールバックがトリガーされるためです。

PolicyNameの一致は、callbackOnly属性がfalseに設定されている場合は無視されます。

callbackOnly属性がtrueに設定されている場合は、ポリシー名がチェックされます。そのポリシーに存在するすべてのコールバックWebサービスURLは、エンティティ・タイプおよび操作条件も満たされている場合にトリガーされます。

そのポリシーに存在するすべてのコールバックWebサービスURLは、エンティティ・タイプおよび操作条件も満たされている場合にトリガーされます。

ポリシー参照URI oracle/wss_saml_or_username_token_service_policyは、有効ではありません。

WSMポリシー・マネージャがデプロイされ、Oracle Identity ManagerやSPMLリクエスト開始サーバーなどの対話サーバーをターゲットにしていることを確認します。また、WSMポリシー・マネージャがアクティブ・モードで、リクエストに対応する準備ができていることを確認します。

SPML APPIDおよびOracle Identity Manager APPIDが何であるか、およびこれらのAPPIDをどこに作成するかがわかりません。

SPML APPIDは、SPMLリクエストをOracle Identity Managerに送信するために使用されます。Oracle Identity Managerによるユーザー・プロビジョニング・サービスを必要とするクライアントは、そのリポジトリにSPML APPIDが格納されている必要があります。たとえば、Fusion ApplicationsがOracle Identity Managerのクライアントである場合、Fusion Applicationsは通常、そのリポジトリとしてLDAPディレクトリを使用します。

Oracle Identity Manager APPIDは、所定のSPMLリクエスト・タイプのCallbackConfiguration.xmlファイルに登録されているすべてのWebサービスにコールバックを送信するために使用されます。

Oracle Identity Managerリポジトリまたはデータベースには、SPML APPIDのみが格納されています。Oracle Identity Manager APPIDはOracle Identity Managerリポジトリには存在せず、資格証明ストア・フレームワーク(CSF)に、マップ名がoim、キーがappid.credentialsとして存在します。

SPMLリポジトリまたはLDAPには、SPML APPIDとOracle Identity Manager APPIDの両方が含まれています。

Fusion Applicationsは、SPMLリクエストをOracle Identity Managerに送信する場合、SPML APPIDを使用してOracle Identity Managerと通信します。SPML APPIDは、SPMLリポジトリまたはLDAPに存在します。このユーザーは、Oracle Identity Manager側でデータベースに対して認証されます。したがって、Oracle Identity ManagerデータベースにはSPML APPIDが含まれています。

Oracle Identity Managerは、Fusion Applicationsと通信する場合、Oracle Identity Manager APPIDを使用してFusion Applicationsと通信します。Oracle Identity Manager APPIDは、CSFに存在します。このユーザーは、LDAPリポジトリ内のOracle Identity Manager APPIDを確認することで、Fusion Applications側でLDAPに対して認証されます。したがって、LDAPにはOracle Identity Manager APPIDが含まれています。

第X部

カスタマイズ・ライフサイクル

この部では、Oracle Identity Managerによって提供されるカスタマイズ・ユーティリティの使用方法およびあるデプロイメントから他のデプロイメントへのカスタマイズの移行方法について説明します。

次の章で構成されます。

- 第36章「カスタマイズのタイプの理解」

- 第37章「カスタマイズのデプロイおよびアンデプロイ」

- 第38章「構成およびカスタマイズの移行」

36 カスタマイズのタイプの理解

Oracle Identity Managerのすべてのカスタマイズは、次のタイプのユーティリティを使用して管理されます。

- デプロイおよびアンデプロイ・ユーティリティ: デプロイおよびアンデプロイ目的に、次のタイプのユーティリティを使用できます。

- データベース固有のユーティリティ: これらは、Oracle Identity Managerのユーティリティであり、入力カスタマイズを使用して、関連するデータベース表に挿入することができます。たとえば、プラグイン登録ユーティリティは、プラグイン・パックを使用して、Oracle Identity Managerデータベースのプラグイン表に挿入します。プラグイン登録ユーティリティの詳細は、「プラグインの開発」を参照してください。

- SOA ANTベースのユーティリティ: SOAコンポジットまたは承認ワークフローのデプロイまたはアンデプロイのためのSOA SuiteからのANTベースのユーティリティがいくつかあります。SOA ANTベースのユーティリティの詳細は、SOAのドキュメントを参照してください。

- OPSSポリシー移行ツール: このツールは、高度な認可カスタマイズに基づいて変更したOracle Identity Manager認可OESポリシーの移行に使用されます。

- Oracle Enterprise Manager: Enterprise Manager (EM)は、Fusion Middlewareの診断および監視アプリケーションです。EMを使用して、メタデータ・ストア(MDS)のカスタマイズおよびSOAコンポジットまたは承認ワークフローをデプロイまたはアンデプロイできます。
EMを使用して、データをMDSに挿入できます。たとえば、EMを使用して、MDSにLDAP同期ユーザー属性マッピングXMLを挿入できます。MDS間でのメタデータ・ファイルのエクスポートおよびインポートの詳細は、「カスタマイズのデプロイおよびアンデプロイ」を参照してください。

- IDE: Jdeveloperなどの統合開発環境(IDE)では、SOAコンポジットまたは承認ワークフローのデプロイ方法を提供します。

- テストから本番へのユーティリティ: これは、あるOracle Identity Managerデプロイメントから他のデプロイメントへのカスタマイズの移行に使用されるユーティリティのことです。たとえば、テスト環境でOracle Identity Managerをカスタマイズしてから、カスタマイズを本番環境へ移行できます。これは、「構成およびカスタマイズの移行」に説明されているように、デプロイメント・マネージャを使用して行われます。
テストから本番へのユーティリティの他の例は、サンドボックスで、あるデプロイメントから他のデプロイメントへのUIカスタマイズの移行に使用されます。サンドボックスの詳細は、「サンドボックスの管理」を参照してください。

表36-1は、デプロイ/アンデプロイ・ユーティリティおよびテストから本番へのユーティリティを介して移行できるOracle Identity Managerアーティファクトを示しています。

表36-1 Oracle Identity Managerアーティファクトおよびユーティリティのタイプ

コンポーネント

デプロイ/アンデプロイ用のアーティファクト

テストから本番およびデプロイ/アンデプロイ用のアーティファクト

アイデンティティ管理

エンタープライズ・ロール

権限

ロール・カテゴリ

カタログ項目

組織

(Oracle Identity Managerプラグインとしての)スケジュール済タスク

アクセス・ポリシー

SOAコンポジット(ワークフロー)

リクエスト・プロファイル

汎用テクノロジ・コネクタ(GTC)プロバイダ

参照コード

(Oracle Identity Managerプラグインとしての)イベント・ハンドラ

アテステーション・プロセス

リソース・バンドル

OESポリシー

Oracle Identity Managerプラグイン

ユーザー、ロール、組織、カタログおよびリソースのユーザー定義フィールド(UDF)

プロビジョニング・カスタマイズ(JARファイル)

スケジュール済ジョブ

(Oracle Identity Managerプラグインとしての)通知イベント

ITリソース・タイプ

コールバック・ポリシー

ITリソース

UIカスタマイズ

アプリケーション・インスタンス

サード・パーティのJARファイル

リソース・オブジェクト

カスタムJAASログイン・モジュール

プロセス・フォーム

リコンシリエーション・プロファイル

プロビジョニング・ワークフローおよびプロセス・タスク・アダプタ

データ・オブジェクト定義

ルール

OBRルール

通知テンプレート

エラー・コード

システム・プロパティ

電子メール定義

UMSベースの通知(Oracle Identity Managerアーティファクト)

UMSベースの通知(EMアーティファクト)

パスワード・ポリシー

GTC

承認ポリシー

アダプタ

Webサービス・セキュリティ構成

Oracle Identity Managerサーバー上のコネクタからのアーティファクト

Remote Managerのアーティファクト

コネクタと関連付けられているスクリプト/実行可能ファイル

OIMConfig.xmlへの変更

診断フレームワークに追加されたカスタム診断テスト

レポート

Oracle Identity ManagerのHTTPS構成

CSFファイルのエントリ

Oracle Identity ManagerおよびRemote Manager間でのSSL構成

セキュアなcookie

LDAP同期

OVDアダプタ

LDAPコンテナ・ルール

idmConfigTool.shによるOracle Identity Manager、OVDおよびLDAPでの構成

LDAPリコンシリエーション・プロファイル

LDAP属性マッピング

Webアクセス管理

LDAP同期のすべてのアーティファクト

idmConfigTool.shによって行われる構成

Oracle Identity Manager WLS/WAS層 - IAプロバイダおよびその他の構成

Identity Analytics/Compliance

Oracle Identity Managerのストアド・プロシージャ変更

OIA構成 - Oracle Identity Manager JARファイル、XMLファイル変更、プロビジョニング・サーバー接続

職務の分離(SoD)

カタログ項目

SIL構成

SIL登録アーティファクト

SILプロバイダ - JAR

SILプロバイダ - XML

37 カスタマイズのデプロイおよびアンデプロイ

この章は、次の項で構成されています。

- ユーザーが修正可能なメタデータ・ファイルの移行

- JARおよびリソース・バンドルの移行

37.1 ユーザーが修正可能なメタデータ・ファイルの移行

Oracle Enterprise Managerを使用すると、ユーザー修正可能なメタデータXMLファイルを、MDSにエクスポート、MDSからインポート、MDSから削除することができます。

この項には次のトピックが含まれます:

- MDSへのメタデータ・ファイルのエクスポート

- MDSからのメタデータ・ファイルのインポート

- MDSからのメタデータ・ファイルの削除

- ユーザーが修正可能なメタデータ・ファイル

- MDSのバックアップの作成

37.1.1 MDSへのメタデータ・ファイルのエクスポート

メタデータXMLファイルをMDSにエクスポートするには:

1. MDSランタイムmbeansに移動します。これを行うには、次の手順を実行します。

1. 管理ユーザーとしてOracle Enterprise Managerにログインします。

2. 開始ページで、oracle.iam.console.identity.self-service.ear(V2.0)をクリックします。

3. 上部の「アプリケーション・デプロイメント」メニューから、MDS構成を選択します。

4. ランタイムMBeanブラウザをクリックしてから、「操作」タブをクリックします。

2. 操作を使用してメタデータをエクスポートします。これを行うには、次の手順を実行します。

1. リストの1つ目のexportMetadata操作を選択します。

2. toLocationに、このファイルがエクスポートされる一時ディレクトリへのパスを指定します。このファイルは、Oracle Identity Managerが実行中のコンピュータにエクスポートされます。したがって、指定したディレクトリ・パスがそのコンピュータ上に存在することを確認してください。

3. docsで、鉛筆アイコンをクリックし、「追加」をクリックして、要素ボックスに、エクスポートするファイルのフル・パスを指定します。「追加」をクリックすると、複数のdocsへのパスを指定できます。

4. 操作を呼び出します。

37.1.2 MDSからのメタデータ・ファイルのインポート

MDSからメタデータXMLファイルをインポートするには:

1. 管理ユーザーとしてOracle Enterprise Managerにログインします。

2. 「WebSphereセル」→「アプリケーション定義のMBean」→「oracle.mds.lcm」→「サーバー: OIM_SERVER_NAME」→「アプリケーション: oim」→「MDSAppRuntime」に移動します。

3. 「操作」タブをクリックします。

4. 操作を使用してメタデータをエクスポートします。これを行うには、次の手順を実行します。

1. 「操作」タブで、リストの1つ目のimportMetadata操作を選択します。

2. fromLocationに、ドキュメントがインポートされるOracle Identity Managerホストのディレクトリ・パスを指定します。

3. docsで、鉛筆アイコンをクリックし、「追加」をクリックして、要素ボックスに、インポートするファイルのフル・パスを指定します。「追加」をクリックすると、複数のdocsへのパスを指定できます。値が指定されない場合、fromLocationディレクトリの下のすべてのものが再帰的にインポートされます。

37.1.3 MDSからのメタデータ・ファイルの削除

MDSからメタデータXMLファイルを削除するには:

1. 「MDSへのメタデータ・ファイルのエクスポート」の手順1で説明されているように、MDSランタイムmbeansに移動します。

2. 操作を使用してメタデータをエクスポートします。これを行うには、次の手順を実行します。

1. 「操作」タブで、リストの1つ目のimportMetadata操作を選択します。

2. docsで、鉛筆アイコンをクリックし、「追加」をクリックして、要素ボックスに、削除するファイルのフル・パスを指定します。「追加」をクリックすると、削除する複数のdocsへのパスを指定できます。

37.1.4 ユーザーが修正可能なメタデータ・ファイル

次のメタデータを使用して、LDAPでユーザーおよびロールがどのコンテナに作成されるかを設定するLDAPコンテナ・ルールを構成します。

注意:

Oracle Identity Managerでは、/metadata、/dbまたは/customで始まるファイル・パスのMDSのみを確認します。XMLドキュメントのパスまたはディレクトリ名の先頭は、/customにする必要があります。

/db/LDAPContainerRules.xml

次のメタデータには、Oracle Identity Managerの操作の事前定義済イベント・ハンドラ定義が含まれています。

注意:

これらは読取り専用ドキュメントです。これらのメタデータ・ファイルで定義されているイベント・ハンドラを変更および削除する必要がある場合は、Oracleサポートに連絡してください。

/db/ldapMetadata/EventHandlers.xml
/metadata/iam-features-OIMMigration/EventHandlers.xml
/metadata/iam-features-Scheduler/EventHandlers.xml
/metadata/iam-features-accesspolicy/event-definition/EventHandlers.xml
/metadata/iam-features-asyncwsclient/EventHandlers.xml
/metadata/iam-features-autoroles/event-definition/EventHandlers.xml
/metadata/iam-features-callbacks/event_configuration/EventHandlers.xml
/metadata/iam-features-configservice/event-definition/EventHandlers.xml
/metadata/iam-features-identity/event-definition/EventHandlers.xml
/metadata/iam-features-notification/EventHandlers.xml
/metadata/iam-features-passwordmgmt/event-definition/EventHandlers.xml
/metadata/iam-features-reconciliation/event-definition/EventHandlers.xml
/metadata/iam-features-request/event-definition/EventHandlers.xml
/metadata/iam-features-requestactions/event-definition/EventHandlers.xml
/metadata/iam-features-selfservice/event-definition/EventHandlers.xml
/metadata/iam-features-sod/EventHandlers.xml
/metadata/iam-features-system-configuration/EventHandlers.xml
/metadata/iam-features-tasklist/EventHandlers.xml
/metadata/iam-features-templatefeature/EventHandlers.xml
/metadata/iam-features-transUI/EventHandlers.xml
/metadata/iam-features-spmlws/EventHandlers.xml
/db/ssointg/EventHandlers.xml
/metadata/iam-features-catalog/EventHandlers.xml
/metadata/iam-features-provisioning/event-definition/EventHandlers.xml
/metadata/iam-features-requestprofile/event-definition/EventHandlers.xml
/metadata/iam-features-rolesod/EventHandlers.xml

37.1.5 MDSのバックアップの作成

場合によっては、カスタマイズを実行する前に、MDSのバックアップを作成しておく必要があります。Oracle Enterprise Managerを使用してMDSのバックアップを作成するには、次の手順を実行します。

1. 管理者としてOracle Enterprise Managerにログインします。

2. 開始ページで、oracle.iam.console.identity.self-service.ear(V2.0)をクリックします。

3. 上部の「アプリケーション・デプロイメント」メニューから、MDS構成を選択します。

4. 「エクスポート」の下で「このWebブラウザが稼働しているマシンにあるアーカイブにメタデータ・ドキュメントをエクスポートします。」オプションを選択し、「エクスポート」をクリックします。
すべてのメタデータがZIPファイルでエクスポートされます。

37.2 JARおよびリソース・バンドルの移行

テスト環境から本番環境に移行するときに、すべてのコネクタ・アーティファクトをそれぞれのデータベース表に移行する必要があり、これはJARファイルおよびリソース・バンドルを移行する次のユーティリティを使用して実行できます。

- JARのアップロード・ユーティリティ

- JARのダウンロード・ユーティリティ

- JARの削除ユーティリティ

- リソース・バンドルのアップロード・ユーティリティ

- リソース・バンドルのダウンロード・ユーティリティ

- リソース・バンドルの削除ユーティリティ

注意:

- JARおよびリソース・バンドルのアップロード・ユーティリティはすべてOIM_HOME/bin/ディレクトリから実行する必要があります。

- これらのユーティリティを実行する前に、wlfullclient.jarが生成されていることを確認します。

- スクリプトを実行する前に、APP_SERVER、OIM_ORACLE_HOME、JAVA_HOME、MW_HOME、WL_HOMEおよびDOMAIN_HOMEを設定します。

- JARファイルおよびリソース・バンドル用のすべてのスクリプトでは、対話モードでの使用とコマンドライン・モードでの使用の両方がサポートされます。ただし、安全でパスワードがコンソールにエコーされない対話モードを使用することをお薦めします。

- スクリプトをコマンドライン・モードで実行するには、-help引数を指定します。例:

sh UploadJars.sh -help

JARファイルをサイレント・モードでアップロードするには、次の手順を実行します。

UploadJars.sh [-username USERNAME] [-password PASSWORD] [-serverURL <t3://OIM_HOSTNAME:OIM_PORT>] [-ctxFactory <weblogic.jndi.WLInitialContextFactory>] [-JavaTasks LOCATION_OF_JAVA_TASK_JAR]

JARファイルをアップロードおよびダウンロードするためのユーティリティの構成およびSSLを介したリソース・バンドルの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのユーティリティに対するSLLの構成に関する項を参照してください。

複数のJARファイルをサイレント・モードでアップロードするには、次の手順を実行します。

UploadJars.sh [-username USERNAME] [-password PASSWORD] [-serverURL <t3://OIM_HOSTNAME:OIM_PORT>] [-ctxFactory <weblogic.jndi.WLInitialContextFactory>] [-JavaTasks LOCATION_OF_JAVA_TASK_JAR] [-ScheduleTask LOCATION_OF_SCHEDULED_TASK_JAR] [-ThirdParty LOCATION_OF_THIRD_PARTY_JAR] [-ICFBundle LOCATION_OF_ICF_BUNDLE_JAR]

- JARおよびリソース・バンドルのユーティリティは対話モードで使用するのが安全な実行方法であり、推奨されているため、このドキュメントでは対話モードでの使用について説明します。
JARまたはリソース・バンドルのユーティリティを対話モードで実行するには、引数を指定しないでスクリプトを実行します。例:

sh UploadJars.sh

37.2.1 JARのアップロード・ユーティリティ

UploadJars.shおよびUploadJars.batスクリプトはOIM_HOME/bin/ディレクトリで使用できます。これらのスクリプトを実行すると、JARファイルがデータベースにアップロードされます。

このユーティリティの起動例を次に示します。

[Enter Xellerate admin username :]ADMISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimportno for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://xyz.com:14000
[[Enter context (Ex. weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the jar type
1.JavaTasks
2.ScheduleTask
3.ThirdParty
4.ICFBundle
1
Enter the path/location of jar file :
/tmp/example.jar
Do u want to load more jars [y/n] :n

注意:

14000はOracle Identity Managerポートです。

37.2.2 JARのダウンロード・ユーティリティ

DownloadJars.shおよびDownloadJars.batスクリプトはOIM_HOME/bin/ディレクトリで使用できます。これらのスクリプトを実行すると、JARファイルがデータベースからダウンロードされます。

このユーティリティの起動例を次に示します。

[Enter Xellerate admin username :]ADMINISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimport for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://localhost:14000
[[Enter context (i.e.: weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the jar type
1.JavaTasks
2.ScheduleTask
3.ThirdParty
4.ICFBundle
1
Enter the full path of the download directory :
/home/joe/tmp
Enter the name of jar file to be downloaded from DB :
example.jar
Do u want to download more jars [y/n] :n

注意:

14000はOracle Identity Managerポートです。

37.2.3 JARの削除ユーティリティ

DeleteJars.shおよびDeleteJars.batスクリプトはOIM_HOME/bin/ディレクトリで使用できます。これらのスクリプトを実行すると、JARファイルがデータベースから削除されます。

このユーティリティの起動例を次に示します。

[Enter Xellerate admin username :]ADMINISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimport for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://localhost:14000
[[Enter context (i.e.: weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the jar type
1.JavaTasks
2.ScheduleTask
3.ThirdParty
4.ICFBundle
1
Enter the name of jar to be deleted from DB :
example.jar
Do u want to delete more jars [y/n] :n

37.2.4 リソース・バンドルのアップロード・ユーティリティ

UploadResourceBundles.shおよびUploadResourceBundles.batスクリプトはOIM_HOME/server/bin/ディレクトリで使用できます。これらのスクリプトを実行すると、コネクタまたはカスタム・リソースがデータベースにアップロードされます。

このユーティリティの起動例を次に示します。

Enter Xellerate admin username :]ADMINISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimportno for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://localhost:14000
[[Enter context (i.e.: weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the resource bundle type
1.Custom Resource
2.Connector Resource
2
Enter the path/location of resource bundle file :
/tmp/example.properties
Do u want to load more resource bundles [y/n] :n

37.2.5 リソース・バンドルのダウンロード・ユーティリティ

DownloadResourceBundles.shおよびDownloadResourceBundles.batスクリプトはOIM_HOME/bin/ディレクトリで使用できます。これらのスクリプトを実行すると、リソース・バンドルがデータベースからダウンロードされます。

このユーティリティの起動例を次に示します。

[Enter Xellerate admin username :]ADMINISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimportno for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://localhost:14000
[[Enter context (i.e.: weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the resource bundle type
1.Custom Resource
2.Connector Resource
2
Enter the full path of the download directory :
/home/joe/tmp
Enter the name of resource bundle file :
example.properties
Do u want to download more resource bundles [y/n] :n

37.2.6 リソース・バンドルの削除ユーティリティ

DeleteResourceBundles.shおよびDeleteResourceBundles.batは、OIM_HOME/bin/ディレクトリで使用できます。これらのユーティリティを実行すると、リソース・バンドルがデータベースから削除されます。

このユーティリティの起動例を次に示します。

[Enter Xellerate admin username :]ADMINISTRATOR_LOGIN
[Enter the admin password :]ADMINISTRATOR_PASSWORD
[[Enter serverURL (Ex. t3://oimhostname:oimportno for weblogic or corbaloc:iiop:localhost:2801 for websphere)]:]t3://localhost:14000
[[Enter context (i.e.: weblogic.jndi.WLInitialContextFactory for weblogic or com.ibm.websphere.naming.WsnInitialContextFactory for websphere)]:]weblogic.jndi.WLInitialContextFactory
Enter the resource bundle type
1.Custom Resource
2.Connector Resource
2
Enter the name of resource bundle file to be deleted from DB:
example.properties
Do u want to delete more resource bundles [y/n] :n

38 構成およびカスタマイズの移行

Oracle Identity Managerでの構成およびカスタマイズにより、あるデプロイメントから別のデプロイメントへ移行できます。たとえば、テスト環境から本番環境へ構成およびカスタマイズを移行する場合があります。これを本番操作テスト(T2P)と言います。

T2Pを実行するには、次の方法があります。

- 増分T2P: このタイプのT2Pでは、Oracle Identity Managerの構成およびカスタマイズのエクスポートおよびインポートにデプロイメント・マネージャ・ツールを使用します。デプロイメント・マネージャを使用すると、Oracle Identity Manager構成を形成しているオブジェクトをエクスポートできます。詳細は、「デプロイメント・マネージャの使用方法」を参照してください。

- 完全T2P: このタイプのT2Pには、Fusion Middlewareフレームワーク・ベースの移動スクリプトを使用します。このスクリプトは、環境固有の属性なしで、ある環境のプロパティすべてを別の環境に移動するために使用されるもので、再構成できます。詳細は、「移動スクリプトを使用したテスト環境から新たな本番環境への移動」を参照してください。

- ポリシー移行: Oracle Platform Securityによって提供されるコマンドライン・ユーティリティを使用して、あるOracle Identity Managerデプロイメントから別のデプロイメント(たとえば、テスト環境から本番環境)へポリシーを移行できます。詳細は、「ポリシーの移行」を参照してください。

この章は、次の項で構成されています。

- デプロイメント・マネージャの使用

- 移動スクリプトを使用したテスト環境から新たな本番環境への移動

- ポリシーの移行

38.1 デプロイメント・マネージャの使用

デプロイメント・マネージャは、Oracle Identity Manager構成およびカスタマイズのエクスポートおよびインポートに使用するツールです。デプロイメント・マネージャを使用すると、Oracle Identity Manager構成を形成しているオブジェクトをエクスポートできます。デプロイメント・マネージャは通常、あるデプロイメントから別のデプロイメントへ、たとえばテスト・デプロイメントから本番デプロイメントへの構成の移行や、システムのバックアップの作成に使用します。

重要:

デプロイメント・マネージャを使用するには、Oracle Identity System Administrationを実行するコンピュータにJRE 1.4.2以上のバージョンがインストールされている必要があります。

構成内のオブジェクトの一部またはすべてを保存することができます。これにより、テスト環境で構成を開発およびテストしてから、テスト済オブジェクトを本番環境にインポートすることができます。オブジェクトとその依存オブジェクトや関連オブジェクトすべてを同時にエクスポートおよびインポートできます。または、各オブジェクトを個別にエクスポートおよびインポートすることも可能です。

デプロイメント・マネージャにより、ソース・システムから構成情報およびバイナリ・データを取り出し、XMLファイルに情報を格納し、それからXMLファイルからターゲット・システムに情報をインポートできます。バイナリ・データには、プラグイン、JARおよびカスタム・リソース・バンドルが含まれています。デプロイメント・マネージャにより、Oracle Identity Managerデータベース、メタデータ・ストア(MDS)リポジトリまたはAPIリポジトリからデータをインポートできます。結果として、これらのリポジトリから、システム・プロパティ、ジョブ、スケジュール済タスクなど、同じリポジトリにないあらゆるタイプのオブジェクトをインポートできます。たとえば、データベースのかわりにMDSリポジトリにあるスケジュール済タスクをインポートすることも可能です。

あるタイプのリポジトリからエクスポートされたオブジェクトは、それと同じタイプのリポジトリにインポートされます。たとえば、スケジュール済タスクがMDSリポジトリからエクスポートされた場合、そのスケジュール済タスクはターゲット・システムの同じリポジトリ、つまりMDSにインポートされます。

注意:

デプロイメント・マネージャに加えて、サンドボックス機能を使用して、あるデプロイメントから他のデプロイメントへ構成およびカスタマイズを移行できます。サンドボックスの使用の詳細は、「サンドボックスの管理」を参照してください。

この項の内容は次のとおりです。

- デプロイメント・マネージャの機能

- デプロイメントのエクスポート

- デプロイメントのインポート

- デプロイメント・マネージャの使用に関連するベスト・プラクティス

38.1.1 デプロイメント・マネージャの機能

Oracle Identity Managerデプロイメントをあるサーバー環境から別のサーバー環境に移行する場合、たとえばテスト環境からステージング環境、あるいはステージング環境から本番環境に移行する場合には、デプロイメント・マネージャを使用します。

デプロイメント・マネージャにより、次のことが可能になります。

- デプロイの個々のコンポーネントを、異なるテスト環境で更新します。

- エクスポートするコンポーネントに関連するオブジェクトを特定し、リソースに含めることができます。

- エクスポート済ファイルの情報を提供します。

- コメントを追加します。

デプロイメント・マネージャは、次のタイプの情報を処理します。

- アプリケーション・インスタンス

- カタログ定義

- プラグイン

- JARファイル

- カスタム・リソース・バンドル

- ロール

- 組織

- アクセス・ポリシー

- アテステーション・プロセス

- ユーザー・メタデータ

- ロール・メタデータ

- 組織メタデータ

- スケジュール済タスク

- スケジュール済ジョブ

- ITリソース

- リソース・オブジェクト

- 参照定義

- プロセス・フォーム

- プロビジョニング・ワークフローおよびプロセス・タスク・アダプタ

- データ・オブジェクト定義

- ルール

- 通知テンプレート

- 汎用テクノロジ・コネクタ(GTC)

- GTCプロバイダ

- エラー・コード

- システム・プロパティ

- 電子メール定義

- パスワード・ポリシー

- ITリソース定義

- リクエスト・データセット

- 承認ポリシー

- イベント・ハンドラ

- 事前移入アダプタ

- プロセス定義

デプロイメント・マネージャには、次のような制限があります。

- マージ・ユーティリティ: デプロイメント・マネージャはマージ・ユーティリティではありません。
本番環境とテスト環境の両方の変更の処理はできません。ターゲット・システムのオブジェクトはXML内のオブジェクトに置き換えられます。

- バージョン管理ユーティリティ: デプロイメント・マネージャでは、インポートしたファイルのバージョンを追跡せず、ロールバック機能は提供されません。
環境間でデータを移動する手段としてのみ使用します。

38.1.2 デプロイメントのエクスポート

オブジェクトは、Oracle Identity Managerシステムからエクスポートして、XMLファイルに保存できます。デプロイメント・マネージャにあるエクスポート・ウィザードを使用して、エクスポート・ファイルを作成することができます。オブジェクトをタイプ別に、一度に1タイプずつ、たとえばロール、フォーム、プロセスなどの順で追加します。

注意:

アプリケーション・インスタンスは、データセットなしでエクスポートおよびインポートされます。データセットは、UIカスタマイズの一部として移行されます。

子オブジェクトや依存性を持つオブジェクトを選択した場合は、それらを追加するかどうかを選択できます。1つのタイプのオブジェクトを追加したら、戻って別のオブジェクトをXMLファイルに追加できます。必要なオブジェクトをすべて追加すると、デプロイメント・マネージャによりすべてのオブジェクトが1つのXMLファイルに保存されます。

注意:

ユーザー定義フィールドが特定のリソース・オブジェクトに関連付けられている場合、エクスポート・プロセス中に、次のいずれかのイベントが発生します。

- ユーザー定義フィールドに値(入力された情報)が含まれている場合、デプロイメント・マネージャはそれを依存性とみなします。

- ユーザー定義フィールドに値が含まれていない場合(フィールドは空)、デプロイメント・マネージャはそれを依存性とみなしません。

デプロイメントをエクスポートするには:

1. Oracle Identity System Administrationにログインします。

2. 左側のペインの「システム管理」の下で、「エクスポート」をクリックします。「デプロイメント・マネージャ」が開き、エクスポート・ウィザードのオブジェクトの検索ページが表示されます。

注意:

Mozilla Firefox Webブラウザを使用して「デプロイメント・マネージャ」を開く場合は、追加認証ダイアログ・ボックスが表示されることがあります。このダイアログ・ボックスで認証が行われると、デプロイメント・マネージャにアクセスできるようになります。この追加認証を回避するには、次のようにします。

1. Mozilla Firefox Webブラウザの「ツール」メニューから、「オプション」を選択します。「オプション」ダイアログ・ボックスが表示されます。

2. 「プライバシー」をクリックします。

3. 「サードパーティのCookieも保存する」オプションを選択します。

4. 「OK」をクリックします。

Microsoft Internet Explorer、Google ChromeおよびApple Safari Webブラウザを使用してデプロイメント・マネージャを開く場合は、追加認証は必要ありません。

3. オブジェクトの検索ページで、メニューからオブジェクト・タイプを選択し、検索基準を入力します。基準フィールドを空のままにしておくと、自動的にアスタリスク(*)が表示され、選択したタイプのすべてのオブジェクトが検索されます。
デプロイメント・マネージャによって移行がサポートされているすべてのオブジェクトをエクスポートに使用できます。デプロイメント・マネージャによって移行がサポートされているオブジェクトのリストは、「デプロイメント・マネージャの機能」を参照してください。

4. 「検索」をクリックすると、選択したタイプのオブジェクトが検索されます。
オブジェクトを選択するには、オブジェクトのオプションを選択します。

5. 「子の選択」をクリックします。
「子の選択」ページに、選択したオブジェクトとそのすべての子オブジェクトが表示されます。

6. エクスポートする子オブジェクトを選択します。
項目を選択または削除するには、適切なオプションを選択します。

「戻る」 をクリックすると、オブジェクトの検索ページに戻ります。

7. 「依存性の選択」をクリックします。
「依存性の選択」ページに、選択したオブジェクトで必要とされるすべてのオブジェクトが表示されます。

8. エクスポートする依存オブジェクトを選択します。
項目を選択または削除するには、項目のオプションを選択します。

「戻る」をクリックすると「子の選択」ページに戻ります。

9. 「確認」をクリックします。
確認ページが表示されます。

10. 必要な項目がすべて選択されていることを確認し、「エクスポート用に追加」をクリックします。
「エクスポート用に追加」をクリックした後でも、このエクスポート・ファイルに項目をさらに追加することができます。

さらに追加を選択し、「OK」をクリックして検索オブジェクト・ページに進み、エクスポートするオブジェクトをさらに追加します。

11. ウィザードを使用して項目をさらに追加し、完了したらウィザードを終了します。目的のオプションを選択し、「OK」をクリックします。
さらに追加を選択した場合は、ステップ2から7を繰り返します。選択していない場合は、「エクスポート」ページが表示されます。

「エクスポート」ページに現在のエクスポート項目が表示されます。選択項目の横にあるアイコンは、選択されているオブジェクトのタイプを示しています。サマリー情報ペインに、エクスポートするオブジェクトが表示されます。「未選択の依存性」ペインには、エクスポート用に選択されなかった依存オブジェクトまたは子オブジェクトのリストが表示されます。

12. エクスポート・ファイルに変更を加えるには、次の手順を実行します。

- フォームをクリアするには「リセット」をクリックします。

- アイコン定義を表示するには「凡例」をクリックします。

- 「オブジェクトの追加」をクリックしてウィザードを再起動し、エクスポート・ファイルにさらに項目を追加します。

オブジェクトを「現在の選択」リストから削除するには:

- 削除するオブジェクトを右クリックし、ショートカット・メニューから「削除」を選択します。オブジェクトに子オブジェクトがある場合は、ショートカット・メニューから「子も含めて削除」を選択し、子オブジェクトを一度にすべて削除します。

- 「削除」をクリックして確認します。オブジェクトが、選択した項目の子または依存性の場合は、「未選択の子」または「未選択の依存性」リストに追加されます。

オブジェクトを「未選択の子」または「未選択の依存性」リストから「現在の選択」リストに戻すには、次のようにします。

1. オブジェクトを右クリックして、「追加」を選択します。

2. 「確認」をクリックします。
確認ページが表示されます。

3. 「エクスポート用に追加」をクリックします。

13. 「エクスポート」をクリックします。
説明の追加ダイアログ・ボックスが表示されます。

14. ファイルの説明を入力します。
この説明は、ファイルがインポートされるときに表示されます。

15. 「エクスポート」をクリックします。
「別名で保存」ダイアログ・ボックスが表示されます。

16. ファイル名を入力します。
参照してファイルの場所を探すことができます。

17. 「保存」をクリックします。
エクスポート完了ダイアログ・ボックスが表示されます。

18. 「閉じる」をクリックします。

38.1.3 デプロイメントのインポート

デプロイメント・マネージャを使用してXMLファイルにエクスポートしたオブジェクトは、デプロイメント・マネージャを使用してOracle Identity Managerにインポートできます。XMLファイルの全部または一部をインポートすることも、複数のXMLファイルを同時にインポートすることもできます。デプロイメント・マネージャは、インポートするオブジェクトの依存性が、インポート時に、または使用するシステムで確実に利用できるかどうかを確認します。インポート中、システム内のオブジェクトをインポート中のオブジェクトに置換できます。たとえば、システムのグループをXMLファイル内で指定されているグループに置換できます。

注意:

- ユーザーが、「インポート」メニュー項目が割り当てられているグループに属している場合、そのユーザーは、インポートするオブジェクトに対して必要な権限も持っている必要があります。これらのオブジェクト固有の権限がない場合、インポート操作は失敗します。メニュー権限付与モデルに基づいてUIで「デプロイメント・マネージャ」メニュー項目を確認するには、ユーザーはデプロイメント・マネージャ管理者である必要があります。

- デプロイメント・マネージャを使用して1000を超えるリソース、プロセス定義、親フォーム、子フォーム、アクセス・ポリシー、ロール、ルールをインポートする場合、EIF表のサイズが大きくなります。EIFから「削除」などの簡単なSQL問合せを実行することにより、この表からデータを切り捨てることができます。

XMLファイルをインポートするには:

注意:

メニュー項目への参照を含むデータをインポートする場合は、まずターゲット・システムでそのメニュー項目を作成してからインポートする必要があります。

1. Oracle Identity System Administrationにログインします。

2. 左側のペインの「システム管理」の下で、「インポート」をクリックします。「デプロイメント・マネージャ」が開き、エクスポート・ウィザードのオブジェクトの検索ページが表示されます。

注意:

Mozilla Firefox Webブラウザを使用して「デプロイメント・マネージャ」を開く場合は、追加認証ダイアログ・ボックスが表示されることがあります。このダイアログ・ボックスで認証が行われると、デプロイメント・マネージャにアクセスできるようになります。この追加認証を回避するには、次のようにします。

1. Mozilla Firefoxの「ツール」メニューから、「オプション」を選択します。「オプション」ダイアログ・ボックスが表示されます。

2. 「プライバシー」をクリックします。

3. 「サードパーティのCookieも保存する」オプションを選択します。

4. 「OK」をクリックします。

Microsoft Internet Explorer、Google ChromeおよびApple Safari Webブラウザを使用してデプロイメント・マネージャを開く場合は、追加認証は必要ありません。

3. ファイルを選択します。
「インポート」ダイアログ・ボックスが表示されます。

4. 「開く」をクリックします。
「ファイル・プレビュー」ページが表示されます。

5. 「ファイルの追加」をクリックします。
「置換」ページが表示されます。

6. 名前を置換するには、置換する項目に隣接した「新しい名前」フィールドをクリックし、名前を入力します。
ターゲット・システムに存在する項目のみ置換できます。

7. 「次へ」をクリックします。ITリソース・インスタンスをエクスポートする場合、「ITリソース・インスタンス・データの提供」ページが表示されます。それ以外の場合は、「確認」ページに切り替わります。

8. 現在のリソース・インスタンスの値を変更して「次へ」をクリックするか、「スキップ」をクリックして現在のリソース・インスタンスをスキップするか、「新規インスタンス」をクリックして新しいリソース・インスタンスを作成します。
確認ページが表示されます。

9. 「確認」ページに表示される情報が正しいことを確認します。
戻って変更するには「戻る」をクリックします。それ以外の場合は「選択内容の表示」をクリックします。

デプロイメント・マネージャの「インポート」ページに現在の選択項目が表示されます。

「インポート」ページでは、現在の選択項目の横にアイコンが表示されます。このアイコンは、選択されているオブジェクトのタイプを示しています。右側のアイコンは選択項目のステータスを示しています。選択されたファイルの名前、インポートするオブジェクトのサマリー情報および置換情報がページの左側に表示されます。右側には、「インポートから削除したオブジェクト」リストにインポートされないXML内のすべてのオブジェクトが表示されます。

10. 必要に応じて次の調整を行います。

- フォームをクリアするには「リセット」をクリックします。

- アイコン定義を表示するには「凡例」をクリックします。

- 「現在の選択」リストからオブジェクトを削除するには、オブジェクトを右クリックしてショートカット・メニューから「削除」を選択し、「削除」をクリックしてオブジェクトの削除を確認します。
オブジェクトに子オブジェクトがある場合、ショートカット・メニューから「子も含めて削除」を選択し、子オブジェクトを一度にすべて削除します。項目が「インポートから削除したオブジェクト」リストに追加されます。

- 「現在の選択」リストに項目を戻すには、リストを右クリックして、「追加」をクリックします。
オブジェクトに子オブジェクトがある場合、ショートカット・メニューから「子も含めて追加」を選択してすべての子オブジェクトを一度に追加します。

- 置換するには、「置換の追加」をクリックします。

- 別のXMLファイルからオブジェクトを追加するには、「ファイルの追加」をクリックして、ステップ2 - 7を繰り返します。

- インポートした情報に関する情報を表示するには、「情報の表示」をクリックします。
「情報」ページが表示されます。

詳細情報を表示するには、「情報レベル・メッセージの表示」オプションを選択し、「メッセージの表示」をクリックします。「閉じる」をクリックして「情報」ページを閉じます。

11. 現在の選択項目をインポートするには、「インポート」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

12. 「インポート」をクリックします。
インポート完了ダイアログ・ボックスが表示されます。

13. 「OK」をクリックします。
オブジェクトがOracle Identity Managerにインポートされます。

38.1.4 デプロイメント・マネージャの使用に関連するベスト・プラクティス

デプロイメント・マネージャの使用に関する推奨プラクティスと注意点を次に示します。

- 必要な場合にのみ行うシステム・オブジェクトのエクスポート

- 関連するオブジェクトのグループのエクスポート

- 定義データおよび操作データの個別のグループ化

- フォーム・バージョンに対する論理的なネーミング規則の使用

- ルートのエクスポートによる完全な組織階層の保持

- わかりやすいエクスポートの説明

- インポート前のすべての警告のチェック

- データ・エクスポート前の依存性のチェック

- 一致するスケジュール済タスク・パラメータ

- スケジュール済タスクの再インポート時のデプロイメント・マネージャの動作

- アダプタのコンパイルおよびスケジュール済タスクの有効化

- エンティティ・アダプタの個別のエクスポート

- ロールの権限のチェック

- データベースのバックアップ

- システム静止中のデータのインポート

- カスタム・データ・オブジェクトの移行

- 依存性としてイベント・ハンドラをインポートする前のデータ・オブジェクト・フィールドの削除

38.1.4.1 必要な場合にのみ行うシステム・オブジェクトのエクスポート

リクエスト、Xellerateユーザー、システム管理者などのシステム・オブジェクトのエクスポートまたはインポートは、本当に必要な場合にのみ行ってください。システム・オブジェクトをテスト環境やステージング環境から本番環境にエクスポートすると、問題が発生する場合があります。可能であれば、データのエクスポートまたはインポートの際には、システム・オブジェクトを除外してください。

Xellerateユーザー・リソース・オブジェクトで信頼できるソースのリコンシリエーションを定義する場合などに、システム・オブジェクトをエクスポートまたはインポートすることがあります。

注意:

デプロイメント・マネージャでは、インポートしたコンポーネントおよび構造を追跡しますが、終了したインポートの追跡は行いません。インポートが完了した後は、前のバージョンにロールバックできません。新たにインポートする必要があります。

38.1.4.2 関連するオブジェクトのグループのエクスポート

デプロイメント・マネージャを使用して、関連するオブジェクトをセットにしてエクスポートすることをお薦めします。グループ化する論理項目を1つにまとめて、エクスポートの単位にしてください。

1回の操作でデータベース内のすべてをエクスポートしたり、1回に項目を1つずつエクスポートすることは避けてください。たとえば、プロセス、リソース・オブジェクト、アダプタ、ITリソース・タイプ定義、ITリソース定義、スケジュール済タスクなどを含むターゲット・システムと、Oracle Identity Managerとの間の統合を管理するとします。このような環境では、エクスポートの前に関連するオブジェクトのグループを作成します。

たとえば、複数の統合で同一の電子メール定義を使用する場合、電子メール定義を1つの単位としてエクスポートし、統合は別の単位としてエクスポートする必要があります。これにより、電子メール定義の変更を、ターゲット・システム統合の変更とは別にインポートできます。また、複数のリソースで同一のITリソース・タイプ定義を使用する場合、タイプ定義をその他のデータとは別個にエクスポートおよびインポートできます。

エクスポート済データの1つ以上のセットを一度にインポートできます。たとえば、リソース・オブジェクト定義、電子メール定義およびITリソース・タイプ定義を、1回の操作でインポートできます。

38.1.4.3 定義データおよび操作データの個別のグループ化

定義データおよび操作データは、別々のグループに分けてエクスポートしてください。

定義データはテスト環境およびステージング環境で構成します。定義データには、リソース・オブジェクト、プロセスおよびルールが含まれます。

一般的に、操作データは、本番環境で構成します。操作データには、グループおよびグループ権限が含まれます。テスト・サーバーおよびステージング・サーバーには、通常このデータは含まれません。

変更される場所に応じてデータをグループ化すると、どのデータがテストおよびステージングに属し、どのデータが本番に属するかを判別できます。たとえば、本番で承認プロセスが変更された場合、承認プロセスをグループ化してその他の操作データと一緒にエクスポートします。

38.1.4.4 フォーム・バージョンに対する論理的なネーミング規則の使用

エクスポートする前に、フォームを何度も修正することがあります。「v23」のような一般的な名前で、フォームのバージョンを区別しないでください。「Before Production」または「After Production Verification」など、意味のある名前を作成します。バージョン名には二重引用符などの特殊文字を使用しないでください。

38.1.4.5 ルートのエクスポートによる完全な組織階層の保持

組織階層内のリーフや組織をエクスポートすると、1つの依存性レベルのみがエクスポートされます。組織階層を完全にエクスポートするには、階層のルートをエクスポートする必要があります。

38.1.4.6 わかりやすいエクスポートの説明

デプロイメント・マネージャでは、エクスポート日、エクスポートの実行者、ソース・データベースなどの一部の情報は自動的に記録されます。また、「xxx属性がリコンシリエーションに追加された後のリソース定義」など、エクスポートのコンテンツのわかりやすい説明も指定する必要があります。ファイルのインポート担当者は、これを元にインポートされるデータのコンテンツを把握します。

38.1.4.7 インポート前のすべての警告のチェック

本番環境に情報をインポートする場合、インポート操作が完了する前にすべての警告をチェックしてください。すべての警告に慎重に対応します。

38.1.4.8 データ・エクスポート前の依存性のチェック

右上ペインのウィザードには、ターゲット・システムで使用可能であることが必要なリソースが表示されます。

次のタイプの依存性について考慮します。

- ターゲット・システムですでに使用可能なリソースは、エクスポートする必要がありません。

- (ターゲット・システムにない)新規のリソースは、エクスポートする必要があります。

- 再利用される参照、ITリソース定義またはその他のリソースがターゲット・システムに含まれていない場合は、必要に応じてインポートできるように、データを記録して別個のファイルでエクスポートします。

注意:

リソースをエクスポートする際に、そのフォームに対してデータ・オブジェクト権限を持つグループはリソースと一緒にエクスポートされません。

38.1.4.9 一致するスケジュール済タスク・パラメータ

スケジュール済タスクが正しく実行されるかどうかは、特定のパラメータに依存します。スケジュール済タスクのパラメータを、本番サーバーにインポートできます。表38-1に、スケジュール済タスクのインポート方法を決定するためのルールを示します。パラメータは、ターゲット・システムに存在しないタスクでも使用できる場合があります。

表38-1 パラメータのインポート・ルール

ターゲット・システムにパラメータがある

XMLファイルにパラメータがある

動作

はい

いいえ

パラメータをターゲット・システムから削除します。

いいえ

はい

XMLファイルのパラメータおよび現行の値を追加します。

はい

はい

パラメータのより新しい値を使用します。

38.1.4.10 スケジュール済タスクの再インポート時のデプロイメント・マネージャの動作

スケジュール済タスクは、デプロイメント・マネージャを使用してインポートできるオブジェクトの1つです。通常、スケジュール済タスクをOracle Identity Manager環境にインポートし、実際の本番環境にあわせて後からスケジュールされた属性の値を変更します。ただし、同じOracle Identity Managerサーバーに同一のスケジュール済タスクをインポートするのが2回目である場合、デプロイメント・マネージャはデータベースにある属性値を上書きしません。その場合、デプロイメント・マネージャは再インポートしたXMLファイルの属性値を、対応するデータベース内の属性値と比較します。

次の表に、スケジュール済タスクの再インポート時にデプロイメント・マネージャによって実行される動作についてまとめます。

スケジュール済タスクのインポートするXMLファイルに属性値があるか

対応する属性値がデータベースにあるか

デプロイメント・マネージャの動作

はい

いいえ

属性値をデータベースに格納します

いいえ

はい

データベース内の既存の属性値を削除します

はい

はい(タイムスタンプで示される新しい属性値)

データベースは変更されません

はい(タイムスタンプで示される新しい属性値)

はい

新しい属性値でデータベースを更新します。

38.1.4.11 アダプタのコンパイルおよびスケジュール済タスクの有効化

インポート操作の後、アダプタは再コンパイルするように設定され、スケジュール済タスクは無効化されます。クラスをインポートしてタスク属性を調整してから、手動でアダプタを再コンパイルし、スケジュール済タスクを有効化してください。

38.1.4.12 エンティティ・アダプタの個別のエクスポート

エンティティ・アダプタを変更すると、エンティティ・アダプタのみが更新され、使用方法は更新されません。エンティティ・アダプタの使用方法をエクスポートする場合は、データ・オブジェクトをエクスポートすることにより、各使用方法をデータ・オブジェクトとともに個別にエクスポートする必要があります。データ・オブジェクトをエクスポートすると、オブジェクトにアタッチされたすべてのアダプタとイベント・ハンドラ、およびオブジェクトに対する権限がエクスポートされます。データ・オブジェクトのエクスポートには、細心の注意が必要です。たとえば、フォームをエクスポートする場合、フォームに関連するデータ・オブジェクトも必ず追加するようにしてください。これにより、関連付けられたエンティティ・アダプタでフォームを使用できます。

38.1.4.13 ロールの権限のチェック

ロールをエクスポートする際に、異なるデータ・オブジェクトに対するロール権限もエクスポートされます。ただし、データをインポートする際は、欠落しているデータ・オブジェクトに対する権限はすべて無視されます。ロール権限の設定をエクスポートする手段としてロールをエクスポートする場合は、権限の要件が満たされるように、警告を慎重にチェックしてください。たとえば、ロールにオブジェクトA、B、Cに対する権限があるが、ターゲット・システムにはオブジェクトA、Bしかない場合、オブジェクトCの権限は無視されます。後でオブジェクトCを追加した場合、Cのロール権限を手動で追加するか、ロールを再インポートする必要があります。

特定のレポートの表示権限を持つロールのエクスポートでは、そのレポートがターゲット環境に存在することを確認してください。レポートがない場合、ロールのエクスポートの前に権限を削除することを考慮してください。

38.1.4.14 データベースのバックアップ

データを本番環境にインポートする前に、データベースをバックアップします。これにより、インポートで問題が発生しても、データをリストアできます。データベースをバックアップしておくことは、大きな変更を行う前の大切な予防措置です。

注意:

フォームおよびユーザー定義フィールドをインポートする際は、データベースにエントリを追加します。これらのデータベース・エントリは、ロールバックまたは削除できません。各インポート操作の前に、フォームの正しいバージョンがアクティブになっていることを確認してください。

38.1.4.15 システム静止中のデータのインポート

インポート操作はスキーマの変更を伴うため、単一のトランザクションでは完了できません。これらの変更は、現在システムで実行中のトランザクションに影響を与えます。インポート操作の影響を抑えるためには、一般使用のためのWebアプリケーションを一時的に無効化し、システムのアクティビティが低下する夜間などに操作を行うようにしてください。

38.1.4.16 カスタム・データ・オブジェクトの移行

SDK表には、ユーザー定義データ・オブジェクトのメタデータ定義が含まれます。XMLファイルからSDK表にデータをインポートすると、SDK_SCHEMA列の値は、XMLファイルが作成されたソース・システムのスキーマ名で変更されることがあります。このため、XMLファイルからSDK表にデータをインポートした後には、SDK_SCHEMA列のスキーマ名をチェックし、必要に応じてOracle Identity Managerデータベースが稼働しているターゲット・システムのスキーマ名に手動で変更してください。SDK_SCHEMA列のスキーマ名を更新するには、Oracle Databaseインストール環境でSQL*Plusを使用するか、Microsoft SQL Serverインストール環境でSQL Query Analyzerを使用して、次のようなSQL問合せを実行します。

UPDATE SDK SET SDK_SCHEMA='target system schema name'

SDK_SCHEMA列のスキーマ名を更新しない場合は、ユーザー定義フィールド(UDF)の定義を変更する別のXMLファイルのインポート時に次のようなエラーが生成されることがあります。

CREATE SEQUENCE UGP_SEQ
java.sql.SQLException: ORA-00955: name is already used by an existing object

38.1.4.17 依存性としてイベント・ハンドラをインポートする前のデータ・オブジェクト・フィールドの削除

イベント・ハンドラを依存性としてインポートする場合、デプロイメント・マネージャでは、データ・オブジェクト・フィールドを含むイベント・ハンドラはインポートされません。このため、デプロイメント・マネージャを使用して、依存性としてインポートする必要があるすべてのイベント・ハンドラからデータ・オブジェクト・フィールドを削除してください。

38.1.5 デプロイメント・マネージャのトラブルシューティング

この項には次のトピックが含まれます:

- デプロイメント・マネージャの問題のトラブルシューティング

- デプロイメント・マネージャのロギングの有効化

38.1.5.1 デプロイメント・マネージャの問題のトラブルシューティング

デプロイメント・マネージャを使用したデータのインポート中に、インポートの失敗に関する次の情報がUIに表示されます。

- インポートが失敗したエンティティ

- インポートが失敗したエンティティのタイプ

- 例外オブジェクト固有のエラー・メッセージ

この情報は、例外トレースとともにログでも出力されます。

図38-1に、デプロイメント・マネージャのインポートの失敗時に表示されるサンプルのエラー・メッセージを示します。

図38-1 デプロイメント・マネージャのインポートの失敗

これは、ユーザーが、失敗したエンティティおよびその原因の識別するために役立ち、ユーザーは、その特定のエンティティを削除し、ターゲット・システムでインポートする必要がない場合は、インポートを再試行できます。これは、サポート・チームおよび開発者が問題の発生時に問題を識別するために役立ちます。

表38-2に、障害が発生した場合に実行できるトラブルシューティングの手順を示します。

表38-2 デプロイメント・マネージャのトラブルシューティング

問題

解決策

Oracle Identity Manager 11g リリース2 (11.1.2.1.0)では、スケジュール済ジョブはスケジュール済タスクに依存しています。したがって、スケジュール済ジョブの前にスケジュール済タスクをインポートする必要があります。この結果、XMLファイルでスケジュール済タスク・エントリより前にスケジュール済ジョブ・エントリがある場合、デプロイメント・マネージャを使用したXMLのインポートが失敗し、次のエラー・メッセージが表示されます。

[exec] Caused By: oracle.iam.scheduler.exception.SchedulerException: InvalidScheduleTask definition
[exec] com.thortech.xl.ddm.exception.DDMException

XMLファイルを開き、すべてのスケジュール済タスク・エントリをスケジュール済ジョブ・エントリの上に移動します。

デプロイメント・マネージャで、エクスポートがいずれのオブジェクトに対しても失敗します。ユーザーには「エクスポートに失敗しました」ダイアログ・ボックスが表示されますが、サーバー・ログに例外は見つかりません。

JREコンソールを確認すると、次のように表示されています。

java.security.AccessControlException: access denied (java.io.FilePermission PATH_AND_NAME_OF_THE_FILE)

次のステップを実行します。

1. JRE_HOME/lib/security/ディレクトリでjava.policyを変更します。

2. 既存のポリシー・ファイルの内容を次のように置き換えます。

grant{
permission java.security.AllPermission;
};

3. ブラウザを再起動してポリシーを再度ロードします。データをエクスポートできるようになります。

XMLファイルのインポート中に次のエラーが発生します。

Caused by:
oracle.iam.reconciliation.exception.ConfigException: Profile :Xellerate User InvalidAttributes :

次のいずれかを実行します。

- エラーが生成された属性をXMLから削除し、インポートを試します。

- 構成サービスを使用して、欠落しているUDFまたは他の属性を作成し、インポートを再び試します。

- 欠落している依存性として示されるUDFをエクスポートします。現在のXMLをインポートする前に、まずこのUDFをインポートします。

承認ポリシーのインポートにより、次のエラーが発生することがあります。

weblogic.kernel.Default (self-tuning)'] [userId: xelsysadm] [ecid:
f9e72ab2a292a346:-188377b2:12f96ae9676:-8000-0000000000000047,0] [APP:
oim#11.1.1.3.0] Exception thrown {0}[[
oracle.iam.platform.entitymgr.ProviderException: USER_NOT_FOUND

承認ポリシー・ルールは、Oracle Identity Managerに存在しないエンティティ(ユーザーまたは組織)を指す場合、無効です。これらの無効な承認ルールは、インポートする前に有効なエンティティ(ユーザーまたは組織)を指すように修正する必要があります。

38.1.5.2 デプロイメント・マネージャのロギングの有効化

デプロイメント・マネージャのロギングを有効化するには:

1. 次のディレクトリ・パスにあるlogging.xmlファイルを編集して、デプロイメント・マネージャに新しいロガーを追加します。
DOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/

インスタンスで、デプロイメント・マネージャに通知レベルのロギングを有効化するには、<loggers>セクション内に次のロガーを追加します。

<logger name='XELLERATE.DDM' level='NOTIFICATION:1' />

2. 関連する<log_handler>で定義されたログ・レベルを変更します。

関連項目:

Oracle Identity Managerのロギング・レベルおよびログ・ハンドラの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのロギングの構成に関する説明を参照してください。

38.2 移動スクリプトを使用したテスト環境から新たな本番環境への移動

Oracle Identity Managerは、Fusion Middleware環境の一部です。テスト環境から本番環境へOracle Identity Managerを移動するには、移動スクリプトを使用します。このスクリプトは、Oracle Identity Managerのバイナリ、アーティファクトおよび構成をコピーし、新たなエンドポイントのある本番Oracle Identity Managerを構成します。移動スクリプトは、テスト環境および本番環境でOracle Identity Managerアーティファクトと相互に作用し、本番環境を更新してOracle Identity Managerを本番環境で機能させます。移動スクリプトの詳細は、『Oracle Fusion Middleware管理者ガイド』のテスト環境から本番環境への移動に関する項を参照してください。Oracle Identity Managerコンポーネントを移動するための手順の詳細は、『Oracle Fusion Middleware管理者ガイド』の新規ターゲット環境へのIdentity Managementコンポーネントの移動に関する項を参照してください。

移動スクリプトを使用するうえでの前提条件として、My Oracle SupportのWebサイト(次のURLを参照)からSOAパッチ14501468をダウンロードし、適用してください。

https://support.oracle.com

詳細は、『Oracle Fusion Middlewareリリース・ノート』のテスト環境から本番環境への移動での制限事項に関する項を参照してください。

Oracle Identity Managerのソース設定をターゲット設定に移行する手順は次のとおりです。

1. 『Oracle Fusion Middleware管理者ガイド』の新規ターゲット環境へのID管理の移動に関する項の「タスク4 Oracle Identity Managerの前提タスクの実行」の説明に従って、expdp/impdp (Data Pumpユーティリティ)を使用して、ソースからターゲットのDBホストにOracle Identity Managerデータベース・スキーマのデータを移行します。

注意:

FMW T2Pユーティリティ実行の前提条件である、Oracle Platform Security Services (OPSS)スキーマを移行する必要があります。OPSSデータの移行の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Platform Security Servicesデータの移動に関する項を参照してください。

2. FMW T2Pユーティリティを使用して、ターゲット設定を作成します。これを行うには、次の手順を実行します。

1. ORACLE_COMMON_HOME/bin/ディレクトリから次のコマンドを実行します。

注意:

- Microsoft Windowsでは、.cmd拡張子の付いたコマンド(copyBinary.cmdやpasteBinary.cmdなど)を実行します。たとえば、copyBinaryスクリプトは、UNIXの場合はORACLE_COMMON_HOME/bin/copyBinary.sh、Microsoft Windowsの場合はORACLE_COMMON_HOME/bin/copyBinary.cmdになります。

- 引数によっては、Windowsオペレーティング・システムには無効のものもあります。たとえば、-ipl PATH_TO_ORACLE_INVENTORY_POINTER引数は、Windowsでは動作しません。

- このドキュメントでは、copyBinaryスクリプト、copyConfigスクリプト、extractMovePlanスクリプトおよびpasteBinaryスクリプトを実行する構文について説明しています。これらのスクリプト、パラメータおよび使用例の詳細は、『Oracle Fusion Middleware管理者ガイド』の移動スクリプトの使用方法に関する項を参照してください。

./copyBinary.sh -javaHome PATH_TO_JDK -al ARCHIVE_LOCATION -smw SOURCE_MW_HOME -silent false -idw true -ipl PATH_TO_ORACLE_INVENTORY_POINTER -silent true -ldl PATH_TO_LOG_DIRECTORY

./copyConfig.sh -javaHome PATH_TO_JDK -archiveLoc ARCHIVE_LOCATION -sourceDomainLoc SOURCE_DOMAIN_LOCATION -sourceMWHomeLoc MIDDLEWARE_HOME_LOCATION -domainHostName DOMAIN_HOST_NAME -domainPortNum DOMAIN_PORT_NUMBER -domainAdminUserName DOMAIN_ADMIN_USERNAME -domainAdminPassword DOMAIN_ADMIN_PASSWORD_FILE -silent true -ldl PATH_TO_LOG_DIRECTORY

./extractMovePlan.sh -javaHome PATH_TO_JDK -archiveLoc ARCHIVE_LOCATION -planDirLoc MOVE_PLAN_DIRECTORY

./pasteBinary.sh -javaHome PATH_TO_JDK -al ARCHIVE_LOCATION -tmw TARGET_MW_HOME -silent false -idw true -esp true -ipl PATH_TO_ORACLE_INVENTORY_POINTER -ldl PATH_TO_LOG_DIRECTORY -silent true

extractMovePlanスクリプトとpasteConfigスクリプトの実行の間に、ターゲットを構成するための新しい値にmoveplanを更新します。moveplanの一般的な変更の詳細は、『Oracle Fusion Middleware管理者ガイド』の移行プランの変更に関する項を参照してください。moveplanプロパティの説明は、『Oracle Fusion Middleware管理者ガイド』の表20-22 Oracle Identity ManagerのMove Planプロパティを参照してください。

注意:

moveplanの編集時に、Oracle Identity Manager管理対象サーバーの詳細でターゲットのリスニング・アドレスを指定します。

2. TARGET_MIDDLEWARE_HOME/bin/ディレクトリに移動して、次のコマンドを実行します。

./pasteConfig.sh -javaHome PATH_TO_JDK -archiveLoc ARCHIVE_LOCATION -targetDomainLoc TARGET_DOMAIN_PATH -targetMWHomeLoc TARGET_MIDDLEWARE_HOME_PATH -movePlanLoc MOVE_PLAN_PATH -domainAdminPassword DOMAIN_ADMIN_PASSWORD_FILE -silent true -ldl PATH_TO_LOG_DIRECTORY

注意:

- TARGET_MIDDLEWARE_HOMEでの権限やJARが配置されているターゲット・ディレクトリを変更する必要がある場合があります。

- 各パラメータに対して一貫性のあるディレクトリ・パスを指定します。たとえば、MIDDLEWARE_HOMEの絶対パスを使用している場合は、あらゆる場所でこのパスを同じように指定します。

3. 完全T2Pの移行後、次の構成を確認または変更します。

- xlclient.cmdファイルでは、Design Consoleを使用してソースで構成されたJDKライブラリがターゲットでアクセスできない場合、JDKパスを更新します。
config/xlconfig.xmlファイルでは、アプリケーションJNDI URLを更新して、ソース・アプリケーションのURLではなくターゲット・アプリケーションのURLを指定します。

- ITリソース構成は、T2P手順のmoveplanの一部ではありません。T2P手順の完了後およびターゲット設定でサーバーを起動後、本番設定ごとにITリソース・パラメータを構成できます。Oracle Identity System Administrationの「構成」で、「ITリソース」をクリックします。「ITリソースの管理」ページで、変更するITリソースの編集アイコンをクリックします。

- T2P手順の間、トランザクション・データと見なされるため、ソースからターゲットへ移行されないエンティティ(ユーザーやプロビジョニングされたアカウントなど)もあります。そのため、ユーザーのパーソナライズ設定(ソート順序、保存済の検索、レイアウト変更など)は、ターゲット設定では見つかりません。

- ロール所有者など一部のユーザーは、Oracle Identity Managerの多くの場所で参照されます。完全T2Pの移行後、そのようなユーザーへの参照は、SYSTEM_ADMINISTRATOR_USERNAME (Oracle Identity Managerシステム管理者)への参照に置換されます。

38.3 ポリシーの移行

Oracle Platform Securityによって提供されるmigrateSecurityStore WLSTコマンド・ユーティリティを使用して、あるOracle Identity Managerデプロイメントから他のデプロイメント(たとえば、テスト環境から本番環境)へポリシーを移行できます。たとえば、Oracle Identity Managerのすべての承認ポリシーをソースからターゲットへ移行するには、WLSTプロンプトから上書きモードで次の移行コマンドを実行します。

migrateSecurityStore(type="appPolicies",configFile="<configuration file path>", src="DBsourceContext", dst="DBdestinationContext", srcApp="OIM", dstApp="OIM", overWrite="true")

migrateSecurityStoreコマンドで使用される様々なパラメータおよびユーティリティの使用オプションの詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス11gリリース2 (11.1.2)のインフラストラクチャ・セキュリティ・カスタムWLSTコマンドに関する説明を参照してください。

構成ファイルの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・ガイド11gリリース1 (11.1.1)』の手動でのポリシーの移行に関する説明を参照してください。

注意:

Oracle Identity Managerポリシーの移行用に構成ファイルを作成する際、ソース・システムおよびターゲット・システムに次のプロパティが設定されていることを確認してください。

<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>

次のディレクトリ・パスのドメインのjps-config.xmlファイルから、これらの値を取得できます。

DOMAIN_HOME/config/fmwconfig/

ドメイン・ホームのjps-config.xmlでプロパティ名を検索して、この構成ファイルに値をコピーします。

ソース・システム値をソース・システムのドメイン・ホームで検索して、同様にターゲット・システムでも検索します。

38.3.1 ポリシー移行のトラブルシューティング

表38-3にポリシーの移行に関する問題が発生した場合に実行できるトラブルシューティング手順を示します。

表38-3 ポリシー移行のトラブルシューティング

問題

解決策

次のエラーが表示されます。

oracle.security.jps.service.policystore.PolicyStoreIncompatibleVersionException: JPS-06100: Policy Store version 11.0 and Oracle Platform Security Services Version 11.1.1.6.0 are not compatible

このエラー・メッセージの原因として、ポリシー・ストアに接続できないまたは見つからないということは考えられます。この問題をトラブルシューティングするには、構成ファイルで、データベースの接続性の詳細、ルート名およびソースおよびターゲットのファーム名を確認します。

第XI部

レポートおよび監査

この部では、監査エンジンおよびOracle Identity Managerでのレポートの構成方法について説明します。

次の章で構成されます。

- 第39章「レポートの構成」

- 第40章「監査の理解」

39 レポートの構成

この章では、Oracle Identity Managerレポートについて説明し、内容は次のとおりです。

- Oracle Identity Managerレポートについて

- Oracle BI Publisherについて

- ライセンス

- Oracle Identity Managerレポートのデプロイ

- Oracle Identity Managerレポートの構成

- Oracle Identity Managerレポートの生成

39.1 Oracle Identity Managerレポートについて

Oracle Identity Managerレポートは、Oracle BI PublisherをOracle Identity Management製品のレポート・ソリューションとして使用することを可能にします。

注意:

Oracle Identity Managerレポートは、機能領域に基づいて分類されます。たとえば、アクセス・ポリシー・レポート、アテステーション・リクエストおよび承認レポート、パスワード・ポリシー・レポートなどがあります。操作や履歴という名前ではなくなりました。

Oracle Identity Managerレポートにより、Oracle BI Publisherの制限付き使用ライセンス、および複数のOracle Identity Management製品用の簡単に使用できるレポート・パッケージが提供されます。

図39-1に示すように、Oracle Identity Managerレポートは、Oracle BI Publisherを使用してOracle Identity Management製品データベースの情報について問合せおよびレポートを行います。最小限の設定で、Oracle Identity Managerレポートを作成、管理および配信するための一般的な方法を提供します。

図39-1 Oracle Identity Managerレポートのアーキテクチャ

Oracle Identity Managerレポートに含まれているレポート・テンプレートは、標準のOracle BI Publisherテンプレートです。ただし、各テンプレートをカスタマイズしてそのルック・アンド・フィールを変更できます。Oracle Identity Management製品のスキーマ定義を利用できる場合は、その情報を使用して独自のカスタム・レポートを作成できます。

注意:

テンプレートをカスタマイズする前に、元のデフォルト・レポート・テンプレートのバックアップ・コピーを作成することをお薦めします。

39.2 Oracle BI Publisherについて

Oracle BI Publisherはオラクル社のエンタープライズ・レポート・ソリューションの1つで、すべてのレポートおよびビジネス文書を作成、管理および配信するための、単一のレポート環境を提供します。Microsoft Word、Microsoft ExcelまたはAdobe Acrobatなどの、一般的な一連のデスクトップ・ツールを利用して、Oracle Identity Management製品を含む様々なソースのデータに基づいてレポート・レイアウトを作成および管理できます。

関連項目:

Oracle BI Publisherの機能の詳細は、Oracle Business Intelligence Publisherのドキュメントを参照してください。

39.3 ライセンス

Oracle Identity Managerは、Oracle Application ServerまたはWebLogic版から独立して、別途ライセンスを取得できます。Oracle Identity Managerのライセンスを別途取得した場合は、次のようなBI Publisherが含まれます。

- 付属のBI Publisherレポート。レイアウトの変更は許可されます。

- 付属の、または新規作成されたBI Publisherレポート(カスタマイズされていない既存のアイデンティティ管理スキーマからデータにアクセスするように変更されているもの)。

39.4 Oracle Identity Managerレポートのデプロイ

この項では、Oracle Identity Manager Reports 11gリリース2 (11.1.2.1.0)のデプロイ方法について、次の各項で説明します。

- メタデータ・リポジトリの作成

- BI Publisher 11g (11.1.1.6)のインストール

39.4.1 メタデータ・リポジトリの作成

各Oracle Business Intelligenceシステム(BIドメイン)には、それ専用のデータベース・スキーマのセットが必要です。複数のシステムで、スキーマまたはリポジトリの同じセットを共有することはできません。

BI Publisher 11g (11.1.1.6)をインストールする前に、リポジトリ構成ユーティリティ(RCU)を使用して、データベースにリポジトリを作成する必要があります。これには、RCUユーティリティが必要ですが、次のURLを使用してOracle Webサイトからダウンロードすることができます。

http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/downloads/bi-downloads-1525270.html

BI Publisher 11g (11.1.1.6)をインストールするには、次のメタデータ・リポジトリが必要です。

- メタデータ・ストア(MDS)

- ビジネス・インテリジェンス・プラットフォーム(BIプラットフォーム)

RCUユーティリティを使用してデータベースにリポジトリを作成するには、次の手順を実行します。

1. データベースにSYSDBAとしてログインします。
RCUを実行するには、DBA権限を持つ必要があります。したがって、SYSDBAとしてログインする必要があります(たとえば、ユーザーSYSとして)。

2. RCU_HOME/bin/ディレクトリに移動します。

3. RCUを起動するには、次のようにします。

- UNIXの場合は、次のスクリプトを実行します。
./rcu

- Microsoft Windowsの場合は、次のスクリプトを実行します。
rcu.bat

4. 表示される「ようこそ」画面で、「次へ」をクリックします。リポジトリ作成ユーティリティ・ウィザードが表示されます。

5. このウィザードのステップ1で、「作成」を選択し、「次へ」をクリックします。「ステップ2/7: データベース接続の詳細」ページが表示されます。

6. 次の表に示すように、接続の詳細を指定します。

フィールド

入力するデータ

データベース・タイプ

Oracle Database

ホスト名

データベースのデプロイ先のホストの名前。

ポート

「ホスト名」フィールドで識別されるホストに接続するポート番号。

サービス名

インストールまたはデータベースの作成時に入力された、データベース名とドメイン名の組合せであるグローバル・データベース名の文字列。グローバル・データベース名が不明な場合は、データベース初期化ファイル(INITSID.ORA)のSERVICE_NAMESパラメータの連結値から取得できます。たとえば、サービス名はSALES.COMのようになります(SALESがデータベース名で、COMがドメインです)。

ユーザー名

Oracle Identity Managerへのアクセス権を持つデータベース・スキーマ・ユーザーのユーザー名(SYSなど)。

パスワード

「ユーザー名」フィールドで識別されたユーザーのパスワード。

ロール

DBA権限を持つロール(SYSDBAなど)。

7. 「次へ」をクリックします。「ステップ3/7: コンポーネントの詳細」ページが表示されます。

8. Oracle Business Intelligenceコンポーネントを選択します。この操作を行うと、「AS共通スキーマ」グループのMDSスキーマが自動的に選択されます。このスキーマはOracle Business Intelligenceでも必要です。

9. 「次へ」をクリックします。「ステップ4/7: スキーマ・パスワード」ページが表示されます。

10. スキーマに対して同じパスワードを指定します。

11. 「次へ」をクリックします。「ステップ5/7: 表領域のマップ」ページが表示されます。

12. 「次へ」をクリックします。検証が完了すると、メッセージが表示されます。

13. 「OK」をクリックします。「ステップ6/7: サマリー」ページに、コンポーネント、スキーマ所有者、表領域タイプおよび表領域名の詳細が表示されます。

14. 「次へ」をクリックします。「ステップ7/7: 完了サマリー」ページが表示されます。

15. 「閉じる」をクリックします。メタデータ・リポジトリがデータベースに作成されます。

ヒント:

ログ・ファイルが、RCU_HOME\log\ディレクトリに保存されます。

39.4.2 BI Publisher 11g (11.1.1.6)のインストール

Oracle Business Intelligence製品は、すべてOracle WebLogic Serverドメインで実行されます。したがって、BI Publisher 11g (11.1.1.6)をインストールする前に、Oracle WebLogic Serverをインストールして構成する必要があります。

Oracle WebLogic Serverがインストールされていない場合、OBIEE 11gはデフォルトではWebLogic Serverをインストールし、user_projects/domainsディレクトリの下にbifoundation_domainという名前のbiドメインを作成します。

BI Publisher 11g (11.1.1.6)のインストールについては、次の各項で説明します。

- Oracle Business Intelligenceウィザードの起動

- Oracle WebLogic Serverがインストールされていない場合のBI Publisher 11g (11.1.1.6)のインストール

- Oracle WebLogic Serverがインストールされている場合のBI Publisher 11g (11.1.1.6)のインストール

Oracle Business Intelligenceウィザードの起動

Oracle Business Intelligenceウィザードを起動するには、bishiphome/Disk1/ディレクトリに移動して、次を実行します。

UNIXの場合:

./runInstaller

Microsoft Windowsの場合:

setup.exe

Oracle WebLogic Serverがインストールされていない場合のBI Publisher 11g (11.1.1.6)のインストール

Oracle Business Intelligenceウィザードを起動した後に、次の手順を実行します。

1. ウィザードの「ステップ1/15: ようこそ」ページが表示されたら、「次へ」をクリックします。「ステップ2/15: タイプ・インストール」ページが表示されます。

2. 「ソフトウェア更新のインストール」オプションを選択し、「次へ」をクリックします。「ステップ3/15: インストール・タイプの選択」ページが表示されます。

3. エンタープライズ・インストール・オプションを選択し、「次へ」をクリックします。「ステップ4/15: 前提条件チェック」ページが表示されます。

4. 「次へ」をクリックします。「ステップ5/15: BIシステムの作成またはスケール」ページが表示されます。

5. 新規BIシステムの作成オプションを選択します。次のフィールドに値を入力します。
ユーザー名: WebLogicユーザー名を入力します。

パスワード: WebLogicユーザーのパスワードを入力します。

パスワードの確認: WebLogicユーザーのパスワードを再入力します。

ドメイン名: WebLogicドメインの名前(デフォルトではbifoundation_domain)。

6. 「次へ」をクリックします。「ステップ6/15: インストール場所の指定」ページが表示されます。

7. インストールのディレクトリ・パスを入力し、「次へ」をクリックします。

8. 「次へ」をクリックします。「ステップ7/12: コンポーネントの構成」ページが表示されます。

9. 「次へ」をクリックします。「ステップ8/12: データベースの詳細」ページが表示されます。

10. 「メタデータ・リポジトリの作成」の手順5で指定した資格証明を持つデータベースの詳細を入力します。

11. 「次へ」をクリックして、ウィザードの残りのステップを完了します。

Oracle WebLogic Serverがインストールされている場合のBI Publisher 11g (11.1.1.6)のインストール

BI Publisher 11g (11.1.1.6)がすでにインストールされている場合は、Oracle Business Intelligenceウィザードで次の手順を実行します。

1. 「ステップ2/15: タイプ・インストール」ページで、「簡易インストール」オプションを選択し、「次へ」をクリックします。「ステップ3/15: 前提条件チェック」ページが表示されます。

2. 「次へ」をクリックします。「ステップ4/12: ミドルウェア・ホーム」ページが表示されます。

3. ミドルウェア・ホームのディレクトリ・パスを、末尾にスペースを入れずに入力します(たとえば、/u01/app/ Oracle_IDM1/Middelware/)。

4. 「次へ」をクリックします。「ステップ5/12: 管理者の詳細」ページが表示されます。

5. 管理ユーザー名およびパスワードを入力します。このアカウントは、WebLogic ServerおよびEnterprise Managerの管理に使用されます。

6. 「次へ」をクリックします。「ステップ6/12: コンポーネントの構成」ページが表示されます。

7. 「次へ」をクリックします。「ステップ7/12: データベースの詳細」ページが表示されます。

8. 「メタデータ・リポジトリの作成」の手順5で指定した資格証明を持つデータベースの詳細を入力します。

9. 「次へ」をクリックして、ウィザードの残りのステップを完了します。

39.5 Oracle Identity Managerレポートの構成

この項では、BI Publisher 11g (11.1.1.6)の構成について、次の各項で説明します。

- BI Publisher 11g (11.1.1.6)でのセキュリティの構成

- Oracle Identity Managerレポートの実行のためのデータソースの構成

39.5.1 BI Publisher 11g (11.1.1.6)でのセキュリティの構成

BI Publisher 11g (11.1.1.6)でセキュリティを構成するには、次の手順を実行します。

1. Oracle_IDM1/Middleware/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Reports/ディレクトリに、新しいディレクトリを作成し、Oracle Identity Managerという名前を付けます。

注意:

BI Publisher 11g (11.1.1.6)のインストール後に、Oracle_IDM1/Middleware/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Reports/ディレクトリがWebLogicドメインに作成されます。

2. oim_product_BIP11gReports_11_1_2_1_0.zipファイルの内容を、新しく作成したOracle Identity Managerディレクトリに解凍します。

3. BI Publisherにログインします。これを行うには、次の手順を実行します。

1. Webブラウザで、次の形式のURLを入力します。
http://HOST_NAME:PORT_NUMBER/xmlpserver/

たとえば、http://localhost:7001/xmlpserver/とします。

2. Oracle BI Publisherのログイン・ページで、WebLogicの権限を持つユーザー名およびパスワードを入力します。

4. 「管理」、「セキュリティ・センター」の順に選択します。次に、「セキュリティ構成」をクリックします。

5. 「セキュリティ・モデル」ページに移動し、実装に従ってセキュリティ・モデルを選択します。OBIEEのデフォルトのセキュリティ・モデルは、Oracle Fusion Middleware Security Modelです。Oracle Fusion Middlewareセキュリティ・モデルの構成の詳細は、次のURLを参照してください。
http://docs.oracle.com/cd/E21764_01/bi.1111/e13880/T526682T559093.htm#ofm1

6. 選択したセキュリティ・モデルに従って、管理者またはOIMユーザーとしてBI Publisherにログインします。「ホーム」ページが表示されます。

7. Oracle Identity ManagerレポートをBI Publisherにアップロードします。これを行うには、次の手順を実行します。

1. 「管理」→「システム・メンテナンス」を選択し、「サーバー構成」をクリックします。

2. 「カタログ」セクションまで下方向にスクロールし、「BI Publisherリポジトリ」フィールド内のリポジトリ・フォルダのパスが正しいことを確認します。

3. BIプレゼンテーション・カタログへのアップロードをクリックし、Oracle Identity ManagerレポートをBI Publisherにアップロードします。

4. 必要に応じて、変更内容を反映するためにBI Publisher管理対象サーバーと管理サーバーの両方を再起動します。

5. BI Publisherに再度ログインし、カタログをクリックします。左側のペインにある共有フォルダ・ツリーを開き、レポートが表示されることを確認します。

39.5.2 Oracle Identity Managerレポートの実行のためのデータソースの構成

Oracle Identity Managerレポートについては、次の項で説明するJDBC接続が必要となります。

- Oracle Identity Manager JDBC接続の構成

- BPELベースのJDBC接続の構成

39.5.2.1 Oracle Identity Manager JDBC接続の構成

Oracle Identity Manager JDBC接続を構成するには、次の手順を実行します。

1. ホーム・ページの上部で、「管理」リンクをクリックします。BI Publisherの「管理」ページが表示されます。

2. 「データソース」で「JDBC接続」をクリックします。「Data Sources」ページが表示されています。

3. 「JDBC」タブで、「データソースの追加」をクリックして、データベースへのJDBC接続を作成します。「データソースの追加」ページが表示されます。

4. 次のフィールドに値を入力します。

- データソース名: Oracle Identity Manager JDBC接続名を指定します(OIM JDBCなど)。

- ドライバ・タイプ: データベースに適したドライバ・タイプを選択します。たとえば、データベースに合せてOracle 10gまたはOracle 11gを選択することができます。

- データベース・ドライバ・クラス: データベースに適したドライバ・クラスを指定します(oracle.jdbc.driver.OracleDriverなど)。

- 接続文字列: データベース接続の詳細を、jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER:SIDの形式で指定します。たとえば、jdbc:oracle:thin:@localhost:7003:orclとします。

- ユーザー名: Oracle Identity Managerデータベースのユーザー名を指定します。

- パスワード: Oracle Identity Managerデータベースのユーザー・パスワードを指定します。

5. 「テスト」をクリックして接続を確認し、「適用」をクリックして接続を確立します。

6. データベースへの接続が確立されると、成功を示す確認メッセージが表示されます。「適用」をクリックします。
「JDBC」ページのJDBCデータソースのリストに、新しく定義されたOracle Identity Manager JDBC接続が表示されます。

39.5.2.2 BPELベースのJDBC接続の構成

BI Publisherでは、1つのレポートに1つのデータソースのみを割り当てることができます。最初のデータソースは、Oracle Identity Managerデータソースです。次のレポートには、BPELデータベースに接続してBPELデータを取得するセカンダリ・データソースがあります。

- タスク割当て履歴

- リクエストの詳細

- リクエスト・サマリー

- 承認アクティビティ

BPELベースのレポート用のセカンダリ・データソースを構成するには、次の手順を実行します。

1. BI Publisherのホーム・ページで「管理」をクリックします。BI Publisherの「管理」ページが表示されます。

2. 「データソース」で「JDBC接続」をクリックします。「Data Sources」ページが表示されています。

3. 「JDBC」タブで、「データソースの追加」をクリックして、データベースへのJDBC接続を作成します。「データソースの追加」ページが表示されます。

4. 次のフィールドに値を入力します。

- データソース名: BPEL JDBC接続名を指定します(BPEL JDBCなど)。

- ドライバ・タイプ: データベースに適したドライバ・タイプを選択します。たとえば、データベースに合せてOracle 10gまたはOracle 11gを選択することができます。

- データベース・ドライバ・クラス: データベースに適したドライバ・クラスを指定します(oracle.jdbc.driver.OracleDriverなど)。

- 接続文字列: データベース接続の詳細を、jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER:SIDの形式で指定します。たとえば、jdbc:oracle:thin:@localhost:7003:orclとします。

- ユーザー名: SOAデータベースのユーザー名を指定します。

- パスワード: SOAデータベースのユーザー・パスワードを指定します。

5. 「テスト」をクリックして接続を確認し、「適用」をクリックして接続を確立します。

6. データベースへの接続が確立されると、成功を示す確認メッセージが表示されます。「適用」をクリックします。
「JDBC」ページのJDBCデータソースのリストに、新しく定義されたBPEL JDBC接続が表示されます。

39.6 Oracle Identity Managerレポートの生成

この項では、Oracle Identity Managerレポートの生成方法について説明し、内容は次のとおりです。

- サンプル・データソースに対するサンプル・レポートの生成

- Oracle Identity Manager JDBCデータソースに対するレポートの生成

- BPELベースのJDBCデータソースに対するレポートの生成

注意:

Oracle Identity Self ServiceまたはOracle Identity System AdministrationからBI Publisherにアクセスすることはできません。BI Publisherを明示的に開いて、Oracle Identity Manager 11gのレポートにアクセスする必要があります。

39.6.1 サンプル・データソースに対するサンプル・レポートの生成

本番JDBCデータソースに対してレポートを実行せずにレポート・データの例を表示して外観を確認するには、サンプル・データソースに対してサンプル・レポートを生成します。サンプル・レポートを生成するには、まずサンプル・データソースを作成する必要があります。サンプル・データソースの作成の詳細は、使用するOracle Identity Management製品に応じて、「Oracle Identity Managerレポートの構成」の該当する項を参照してください。

サンプル・データソースを作成したら、次の手順を実行してサンプル・レポートを生成できます。

1. Oracle BI Publisherにログインします。Oracle BI Publisherへのログインの詳細は、「BI Publisher 11g (11.1.1.6)でのセキュリティの構成」の手順3を参照してください。

2. 「共有フォルダ」、Oracle Identity Managerレポートの順にクリックし、サンプル・レポートを選択します。

3. 生成するサンプル・レポートについて「表示」をクリックします。

4. サンプル・レポートの出力フォーマットを選択して「表示」をクリックします。
サンプル・レポートが生成されます。

39.6.2 Oracle Identity Manager JDBCデータソースに対するレポートの生成

Oracle Identity Manager JDBCデータソースに対してレポートを生成するには、次の手順を実行します。

1. Oracle BI Publisherにログインします。Oracle BI Publisherへのログインの詳細は、「BI Publisher 11g (11.1.1.6)でのセキュリティの構成」の手順3を参照してください。

2. Oracle Identity Managerレポートに移動します。これを行うには、次の手順を実行します。

1. BI Publisherのホーム・ページの「参照/管理」の下で、「カタログ・フォルダ」をクリックします。または、ページの上部で「カタログ」をクリックすることもできます。
「カタログ」ページでは、ページの左側にはツリー構造が、右側には詳細が表示されます。

2. 左側のペインで「共有フォルダ」を展開し、Oracle Identity Managerに移動します。Oracle Identity Managerフォルダのすべてのオブジェクトが表示されます。
BI Publisher 11gに移動して、Oracle Identity Manager BI Publisherレポートを使用することができます。

3. 生成するレポートについて「表示」をクリックします。

4. レポートの出力フォーマットを選択して「表示」をクリックします。
レポートが生成されます。

関連項目:

Oracle BI Publisherの詳細は、Oracle Business Intelligence Publisherのドキュメントを参照してください。

39.6.3 BPELベースのJDBCデータソースに対するレポートの生成

次の4つのレポートには、BPELデータベースに接続してBPELデータを取得するセカンダリ・データソースがあります。

- タスク割当て履歴

- リクエストの詳細

- リクエスト・サマリー

- 承認アクティビティ

これらのレポートには、BPELベースのJDBCデータソースでBPEL JDBCと呼ばれるセカンダリ・データソースがあります。

BPELベースのJDBCデータソースに対してレポートを生成するには、次の手順を実行します。

1. BPELデータソースがBI Publisherに存在することを確認します。このBPELデータソースはBPELデータベースを示す必要があります。BPELデータソースの作成の詳細は、「BPELベースのJDBC接続の構成」を参照してください。

2. Oracle BI Publisherにログインします。Oracle BI Publisherへのログインの詳細は、「BI Publisher 11g (11.1.1.6)でのセキュリティの構成」の手順3を参照してください。

3. Oracle Identity Managerレポートに移動します。これを行うには、次の手順を実行します。

1. BI Publisherのホーム・ページの「参照/管理」の下で、「カタログ・フォルダ」をクリックします。または、ページの上部で「カタログ」をクリックすることもできます。
「カタログ」ページでは、ページの左側にはツリー構造が、右側には詳細が表示されます。

2. 左側のペインで「共有フォルダ」を展開し、Oracle Identity Managerに移動します。Oracle Identity Managerフォルダのすべてのオブジェクトが表示されます。
BI Publisher 11gに移動して、Oracle Identity Manager BI Publisherレポートを使用することができます。

4. 生成するレポートについて「表示」をクリックします。

5. レポートの出力フォーマットを選択して「表示」をクリックします。
BPELベースのJDBCデータソースに基づいてレポートが生成されます。

40 監査の理解

ユーザー・プロファイル監査は、ユーザー・プロファイルの属性、ユーザー・メンバーシップ、リソース・プロビジョニング、アクセス・ポリシーおよびリソース・フォームに対する変更を対象としています。

監査エンジンは、Oracle Identity Managerの監査情報を収集します。プロファイルが変更されるたびに、監査エンジンは変更(デルタ)を収集してユーザーおよびロールのプロファイルのスナップショットを更新(存在しない場合は生成)し、これらのスナップショットおよびデルタをXML形式で格納します。また、監査エンジンには、生成されたXMLに基づいて関連データをレポート表に移入するポストプロセッサがあります。高いパフォーマンスを維持するため、デフォルトでは、監査エンジンは、アプリケーション・サーバーに装備されている基礎となるJava Message Service (JMS)を使用して、これらのタスクを非同期オフライン方式で実行します。

この章では、次の項目について説明します。

- 監査レベル

- 監査者に関する情報の格納に使用される表

- 監査メッセージの発行

40.1 監査レベル

この章で前述したように、Oracle Identity Managerをインストールすると、デフォルトでユーザー・プロファイル監査機能が有効になり、監査レベルは「リソース・フォーム」に設定されます。監査レベルを変更する場合は、GenerateSnapshot.shスクリプト(UNIXの場合)またはGenerateSnapshot.batスクリプト(Microsoft Windowsの場合)を実行する必要があります。このスクリプトは、IDM_HOME/server/binディレクトリにあります。スクリプトでは、Oracle Identity Managerデータベース内のすべてのユーザーを調査し、新しいスナップショットを新しい監査レベルに基づいて生成します。

注意:

監査レベルを変更する場合は、必ずGenerateSnapshotスクリプトを実行してからユーザーにシステムへのアクセスを許可してください。

監査エンジンの「監査の詳細のレベル」を構成し、その監査レベルを拡張管理のXL.UserProfileAuditDataCollectionシステム・プロパティの値として指定できます。

関連項目:

このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する項を参照してください。

次の監査レベルがサポートされています。

- プロセス・タスク: リソース・ライフサイクル・プロセスでユーザー・プロファイル・スナップショット全体をまとめて監査します。

- リソース・フォーム: ユーザー・レコード、ロール・メンバーシップ、プロビジョニングされたリソースおよびリソースに関連付けられたすべてのフォーム・データを監査します。

- リソース: ユーザー・レコード、ロール・メンバーシップおよびプロビジョニングされたリソースを監査します。

- メンバーシップ: ユーザー・レコードおよびロール・メンバーシップのみを監査します。

- コア: ユーザー・レコードのみを監査します。

- なし: 監査データは格納されません。

注意:

特定の監査レベルを指定すると、下位の優先順位レベルにある監査レベルはすべて自動的に有効になります。たとえば、Membership監査レベルを指定すると、Core監査レベルは自動的に有効になります。

監査レベルの指定では、大/小文字が区別されます。監査レベルを指定する際は、監査レベルの大/小文字を変更しないでください。

40.2 監査者に関する情報の格納に使用される表

監査者に関する情報は、データベース内の次の表に格納されます。

- AUD: この表には、Oracle Identity Managerで定義されたすべての監査者に関するメタデータが格納されます。

- aud_jms: この表には、監査エンジンおよび最終的には監査者が使用するデータが格納されます。操作可能な中間ステージング表です。
この表のキーは、JMSに送信されます。Oracle Identity Managerでは、複数の変更が同じユーザーに加えられたときに、この表を使用して変更順序を制御します。スケジュール済タスクIssue Audit Messages Taskを使用すると、処理されていないメッセージの再発行を自動化できます。このスケジュール済タスクの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のスケジューラの管理に関する説明を参照してください。

40.3 監査メッセージの発行

Oracle Identity Managerには、監査メッセージの発行タスクというスケジュール済タスクがあります。このスケジュール済タスクは、監査メッセージの詳細をaud_jms表から取り出し、aud_jms表の特定の識別子および監査者のエントリについてJMSメッセージを1つ送信します。MDBで対応する監査メッセージが処理されます。

このタスクの属性は、次のとおりです。

Max Records

Max Records属性を使用し、指定したスケジュール済タスクの実行について処理される監査メッセージの最大数を指定します。この属性のデフォルト値は、400です。

aud_jms表に監査メッセージのバックログがある場合は、Max Records属性の値を増やすことができます。設定する値は、スケジュール済タスクのデフォルトの実行間隔の間にJMSエンジンが処理できるメッセージ数に依存します。その数は、アプリケーション・サーバーおよびデータベースのパフォーマンスによって決まります。Max Records値を増やす前に、アプリケーション・サーバーの管理コンソールを使用するなどして、JMS宛先(oimAuditQueue)での監査メッセージ数の処理にかかる時間を割り出す必要があります。必要な時間がスケジュール済タスクの間隔より短い場合は、Max Records属性の値をその分だけ増やすことができます。

第XII部

付録

この部は、次の付録で構成されています。

- 付録A「一般的なカスタマイズの概念」

- 付録B「FacesUtilsクラス」

A 一般的なカスタマイズの概念

Design Consoleは、フォームやワークフローの設計、アダプタの作成と管理など、構成や設計のための各種機能を備え、Oracle Identity Managerのカスタマイズに使用できます。Design Consoleでは、アプリケーション構成の特定領域を扱うための権限をユーザーに付与できます。

この付録の内容は次のとおりです。

- ルール要素、変数、データ型およびシステム・プロパティ

- サービス・アカウント

- Design Consoleのアクション

A.1 ルール要素、変数、データ型およびシステム・プロパティ

Design Consoleでは、ルールのルール要素の追加と変更、電子メール定義の作成または編集、フォームの作成など、Oracle Identity Managerのカスタマイズ・タスクを行うことができます。これらのカスタマイズ・タスクでは、パラメータ、変数およびデータ型を設定する必要があります。この項では、これらのパラメータ、変数およびデータ型について説明します。

「ルール・デザイナ」フォームの「ルール要素」タブでは、ルールの要素およびネストしたルールを作成および管理できます。表A-1に、「ルール・デザイナ」フォームでOracle Identity Managerのルールの作成に使用できるルール要素を示します。

表A-1 Oracle Identity Managerのルールを作成するためのルール要素

タイプ

サブタイプ

属性ソース

変数

一般

NA

ユーザー・プロファイル・データ

電子メール

終了日

名

アイデンティティ

姓

表示名

マネージャ

ミドル・ネーム

組織名

ユーザー・ロール名

開始日

一般

該当なし

ユーザー・プロファイル・データ

ユーザー・タイプ

アイデンティティ・ステータス

ユーザー・ログイン

Design Consoleのアクセス

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

プロセス決定

組織プロビジョニング

リクエスタ情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

プロセス決定

組織プロビジョニング

オブジェクト情報

オブジェクト名

オブジェクト・タイプ

リクエスト・ターゲット情報

組織カスタマ・タイプ

組織名

組織ステータス

親組織

「組織」フォームの「ユーザー定義フィールド」タブに表示される任意のフィールド

オブジェクト・データ情報

リソース・オブジェクトに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

プロセス・データ情報

プロセスに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

ユーザー・プロビジョニング

リクエスタ情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

ユーザー・タイプ

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

FormMetadata.xmlユーザー自己登録内、およびユーザー・プロファイル変更セクションでプロパティuseInRuleがtrueに設定されている任意のフィールド

オブジェクト情報

オブジェクト名

オブジェクト・タイプ

リクエスト・ターゲット情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

ユーザー・タイプ

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

FormMetadata.xmlユーザー自己登録内、およびユーザー・プロファイル変更セクションでプロパティuseInRuleがtrueに設定されている任意のフィールド

プロセス決定

ユーザー・プロビジョニング

リクエスタ情報; リクエスト・ターゲット情報

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

オブジェクト情報

オブジェクト名

オブジェクト・タイプ

オブジェクト・データ情報

リソース・オブジェクトに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

プロセス・データ情報

プロセスに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

タスクの割当て

組織のプロビジョニング; ユーザーのプロビジョニング

タスク情報

保留中の取消しを許可

複数のインスタンスを許可

マネージャへのタスクの割当て

手動挿入不可

タスク(条件付き)

タスク・データ・ラベル

タスクのデフォルト割当て先

タスク名

完了する必要があるタスク

タスク順序

プロセス情報

オブジェクト名

プロセス名

プロセス・タイプ

オブジェクト情報

オブジェクト名

オブジェクト・タイプ

リクエスタ情報

電子メール

終了日

名

アイデンティティ

タスクの割当て

組織のプロビジョニング; ユーザーのプロビジョニング

リクエスタ情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

ユーザー・タイプ

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

オブジェクト・データ情報

リソース・オブジェクトに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

プロセス・データ情報

プロセスに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

事前移入

組織のプロビジョニング; ユーザーのプロビジョニング

リクエスタ情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

ユーザー・タイプ

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

リクエスト情報

リクエスト作成日

リクエストID

リクエスト・オブジェクト・アクション

リクエスト優先度

リクエスタ

オブジェクト情報

オブジェクト名

オブジェクト・タイプ

オブジェクト・データ情報

リソース・オブジェクトに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

プロセス・データ情報

プロセスに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

組織プロビジョニング

リクエスト・ターゲット情報

組織カスタマ・タイプ

組織名

組織ステータス

親組織

「組織」フォームの「ユーザー定義フィールド」タブに表示される任意のフィールド

ユーザー・プロビジョニング

リクエスト・ターゲット情報

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ・ログイン

事前移入

ユーザー・プロビジョニング

リクエスト・ターゲット情報

表示名

電子メール

終了日

名

アイデンティティ

姓

マネージャの氏名

マネージャ

ミドル・ネーム

組織名

ユーザー・タイプ

開始日

アイデンティティ・ステータス

ユーザー・ロール名

ユーザー・ログイン

Design Consoleのアクセス

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

「電子メール定義」フォームを使用して、ユーザーに送信される電子メール通知のテンプレートを作成できます。表A-2に、「電子メール定義」フォームを使用した電子メールのテンプレートの作成に使用できる変数を示します。

表A-2 テンプレートを作成するための変数

タイプ

ターゲット

ロケーション・タイプ

連絡先タイプ

変数

プロビジョニング関連

ユーザー・プロファイル情報; 割当て先プロファイル情報

該当なし

該当なし

名

アイデンティティ

姓

マネージャ・ログイン

ミドル・ネーム

ロール

ステータス

終了日

ユーザー・グループ名

ユーザー・ログイン

ユーザー・マネージャ

開始日

Oracle Identity Managerタイプ

マネージャの氏名

組織名

電子メール

プロビジョニング関連

ユーザー・プロファイル情報; 割当て先プロファイル情報

該当なし

該当なし

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

オブジェクト情報

該当なし

該当なし

オブジェクト名

オブジェクト・ターゲット・タイプ

オブジェクト・タイプ

プロセス情報

該当なし

該当なし

オブジェクト名

プロセス名

プロセス・タイプ

オブジェクト・データ情報

該当なし

該当なし

リソース・オブジェクトに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

プロセス・データ情報

該当なし

該当なし

プロセスに関連付けられたカスタム・フォームについて「フォーム・デザイナ」フォームの「追加列」タブに表示される任意のフィールド

一般

ユーザー・プロファイル情報

該当なし

該当なし

名

アイデンティティ

姓

電子メール・アドレス

マネージャ・ログイン

ミドル・ネーム

ロール

ステータス

ユーザー終了日

ユーザー・グループ名

ユーザー・ログイン

ユーザー・マネージャ

ユーザー開始日

Oracle Identity Managerタイプ

「ユーザー」フォームの「ユーザー・プロファイル」タブの「ユーザー定義フィールド」リージョンに表示される任意のフィールド

表A-3に、「フォーム・デザイナ」フォームを使用したOracle Identity Managerフォームの作成に使用されるデータ型に関連付けられるプロパティを示します。

表A-3 Oracle Identity Managerフォーム作成用のデータ型に関連付けるプロパティ

データ型

データ・プロパティ

説明

テキスト・フィールド

必須

フォームの保存にこのテキスト・フィールドの入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能

Oracle Identity Managerでフォームが生成された際にこのテキスト・フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

参照フィールド

オートコンプリート

対応する「プロパティ値」フィールドにtrueと入力すると、Oracle Identity Managerで参照フィールドがフィルタ処理されます。ユーザーは、ダブルクリックする前に参照フィールドに文字を追加できます。これにより、これらの文字と一致する参照値のみが参照ウィンドウに表示されます。

たとえば、「State」参照フィールドの場合、ユーザーはこのフィールドにnewと入力できます。ユーザーが参照フィールドをダブルクリックすると、newで始まる州(New Hampshire、New Jersey、New MexicoおよびNew Yorkなど)のみが参照ウィンドウに表示されます。Oracle Identity Managerで参照フィールドのフィルタ処理をしない場合は、対応する「プロパティ値」フィールドにfalseと入力します。

「オートコンプリート」プロパティのデフォルト・プロパティ値は、falseです。

列見出し

対応する「プロパティ値」フィールドに、ユーザーが参照フィールドをダブルクリックしたときに参照ウィンドウに表示される列見出しの名前を入力します。参照ウィンドウに複数の列がある場合は、各列見出しを「Organization Name, Organization Status」のようにカンマで区切って「プロパティ値」フィールドに入力します。

参照フィールド

列名

対応する「プロパティ値」フィールドに、参照ウィンドウに表示する列見出しを表すデータベース列の名前を入力します。

参照ウィンドウに複数の列がある場合は、各データベース列をカンマで区切って「プロパティ値」フィールドに入力します。

列幅

対応する「プロパティ値」フィールドに、参照ウィンドウに表示される列の幅を入力します。

参照ウィンドウに複数の列がある場合は、各列の幅を「20,20」のようにカンマで区切って「プロパティ値」フィールドに入力します。

参照列名

対応する「プロパティ値」フィールドに、参照列の名前をデータベースで表示されるとおりに入力し、これをデータベースに保存する必要があります。

参照問合せ

対応する「プロパティ値」フィールドに、ユーザーが参照フィールドをダブルクリックしたときに実行されるSQL問合せの名前を入力します。この結果、該当する参照列が参照ウィンドウに表示されます。

問合せから返されるデータを正しく表示するには、xlWebAdmin_locale.propertiesファイルにlookupfield.headerプロパティを追加する必要があります。たとえば、select usr_status from usrというSQL問合せの場合を考えます。この問合せから返されるデータを表示するには、xlWebAdmin_ locale.propertiesファイルに次のエントリを追加する必要があります。

lookupfield.header.users.status=User Status

指定した問合せのxlWebAdmin_locale.propertiesファイルにlookupfield.headerプロパティが含まれていない場合は、対応する「参照」アイコンをクリックすると、Identity System Administrationに参照ウィンドウが表示されます。

lookupfield.headerプロパティの構文は次のとおりです。

lookupfield.header.column_code=display value

エントリのcolumn_code部分は小文字で、空白はアンダースコア(_)に置き換えます。

参照フィールドの列ヘッダーに対する次のエントリが、デフォルトでシステム・リソース・バンドルで使用可能です。

lookupfield.header.lookup_definition.lookup_ code_information
.code_key=Value
lookupfield.header.lookup_definition.lookup_code_information
.decode=Description
lookupfield.header.users.manager_login=User ID
lookupfield.header.organizations.organization_ name=Name
lookupfield.header.it_resources.key=Key
lookupfield.header.it_resources.name=Instance Name
lookupfield.header.users.user_id=User ID
lookupfield.header.users.last_name=Last Name
lookupfield.header.users.first_name=First Name
lookupfield.header.groups.group_name=Group Name
lookupfield.header.objects.name=Resource Name
lookupfield.header.access_policies.name=Access Policy Name

参照フィールド

参照コード

対応する「プロパティ値」フィールドに、参照定義コードを入力します。このコードには、参照値や参照値が選択されたときに参照フィールドに表示されるテキストなどの参照フィールドに関係するすべての情報が含まれます。

重要: 「参照コード」データ・プロパティは、「列見出し」、「列名」、「列幅」、「参照列名」および「参照問合せ」プロパティのかわりに使用できます。また、これらの5つのデータ・プロパティの値セットは、「参照コード」プロパティに含まれる情報によって無効になります。

ヒント: 参照コードを入力する簡単な方法は、「参照定義」フォームを起動して目的のコードを問い合せ、このコードをクリップボードにコピーして「参照コード」フィールドに貼り付けることです。

注意: 参照定義コードの分類タイプは、参照タイプ(「参照定義」フォームの「参照タイプ」ラジオ・ボタンを選択)である必要があります。

必須

フォームの保存にこの参照フィールドの入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこの参照フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

テキスト領域

行数

対応する「プロパティ値」フィールドに、テキスト領域の行の長さを入力します。テキスト領域の長さを5行にする場合は、「プロパティ値」フィールドに5と入力します。

必須

フォームの保存にこのテキスト領域の入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのテキスト領域が表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

ITリソース参照フィールド

タイプ

このデータ・プロパティを選択すると、「プロパティ値」フィールドにボックスが表示されます。このボックスから、ITリソースのサーバーのタイプを選択します。

重要: このプロパティは必須です。

必須

フォームの保存にこの参照フィールドの入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこの参照フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

日時ウィンドウ

必須

フォームの保存にこのテキスト・フィールドの入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このテキスト・フィールドに入力するには、これをダブルクリックし、表示された日時ウィンドウから日付と時間を選択します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのテキスト・フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

パスワード・フィールド

必須

フォームの保存にこのテキスト・フィールドの入力が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのテキスト・フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

参照フィールド

参照コード

対応する「プロパティ値」フィールドに、参照定義コードを入力します。このコードには、参照値や参照値が選択されたときに参照フィールドに表示されるテキストなどの参照フィールドに関係するすべての情報が含まれます。

参照問合せ

対応する「プロパティ値」フィールドに、ユーザーが参照フィールドをダブルクリックしたときに実行されるSQL問合せの名前を入力します。この結果、該当する参照列が参照ウィンドウに表示されます。

問合せから返されるデータを正しく表示するには、xlWebAdmin_locale.propertiesファイルにlookupfield.headerプロパティを追加する必要があります。たとえば、select usr_status from usrというSQL問合せの場合を考えます。この問合せから返されるデータを表示するには、xlWebAdmin_ locale.propertiesファイルに次のエントリを追加する必要があります。

lookupfield.header.users.status=User Status

指定した問合せのxlWebAdmin_locale.propertiesファイルにlookupfield.headerプロパティが含まれていない場合は、対応する「参照」アイコンをクリックすると、Identity System Administrationに参照ウィンドウが表示されます。

lookupfield.headerプロパティの構文は次のとおりです。

lookupfield.header.column_code=display value

エントリのcolumn_code部分は小文字で、空白はアンダースコア(_)に置き換えます。

参照フィールドの列ヘッダーに対する次のエントリが、デフォルトでシステム・リソース・バンドルで使用可能です。

lookupfield.header.lookup_definition.lookup_ code_information
.code_key=Value
lookupfield.header.lookup_definition.lookup_code_information
.decode=Description
lookupfield.header.users.manager_login=User ID
lookupfield.header.organizations.organization_ name=Name
lookupfield.header.it_resources.key=Key
lookupfield.header.it_resources.name=Instance Name
lookupfield.header.users.user_id=User ID
lookupfield.header.users.last_name=Last Name
lookupfield.header.users.first_name=First Name
lookupfield.header.groups.group_name=Group Name
lookupfield.header.objects.name=Resource Name
lookupfield.header.access_policies.name=Access Policy Name

列名

対応する「プロパティ値」フィールドに、参照ウィンドウに表示する列見出しを表すデータベース列の名前を入力します。

参照ウィンドウに複数の列がある場合は、各データベース列をカンマで区切って「プロパティ値」フィールドに入力します。

ラジオ・ボタン

必須

フォームの保存にこのラジオ・ボタンの選択が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのラジオ・ボタン(または、ラジオ・ボタンのグループ)が表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

チェック・ボックス

必須

フォームの保存にこのチェック・ボックスの選択が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのチェック・ボックスが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

コンボ・ボックス

参照コード

対応する「プロパティ値」フィールドに、参照定義コードを入力します。このコードには、ボックス項目や参照値が選択されたときにボックスに表示されるテキストなどのボックスに関係するすべての情報が含まれます。

重要: 「参照コード」データ・プロパティは、「列見出し」、「列名」、「列幅」、「参照列名」および「参照問合せ」プロパティのかわりに使用できます。また、これらの5つのデータ・プロパティの値セットは、「参照コード」プロパティに含まれる情報によって無効になります。

ヒント: 参照コードを入力する簡単な方法は、「参照定義」フォームを起動して目的のコードを問い合せ、このコードをクリップボードにコピーして「参照コード」フィールドに貼り付けることです。

注意: 参照定義コードの分類タイプは、参照タイプ(「参照定義」フォームの「参照タイプ」オプションを選択)である必要があります。

必須

フォームの保存にこのボックス・フィールドからの項目の選択が必要な場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、falseです。

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのボックスが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

テキスト・フィールド(表示のみ)

表示可能フィールド

Oracle Identity Managerでフォームが生成された際にこのテキスト・フィールドが表示されるようにする場合は、対応する「プロパティ値」フィールドにtrueと入力します。そうでない場合は、このフィールドにfalseと入力します。

注意: このデータ・プロパティのデフォルト値は、trueです。

A.2 サービス・アカウント

サービス・アカウントは、メンテナンス目的で使用される一般的な管理者アカウントです。通常、一連のユーザーによって共有されます。サービス・アカウントは、通常のアカウントと同様の方法でリクエスト、プロビジョニングおよび管理されます。サービス・アカウントは、内部フラグによって通常のアカウントと区別されます。

ユーザーがサービス・アカウントを使用してプロビジョニングされると、Oracle Identity Managerで、ユーザーのアイデンティティからサービス・アカウントへのマッピングが管理されます。このユーザーは、サービス・アカウントの所有者とみなされます。ユーザーが削除された、またはリソースが失効された場合、取消しタスクが発生するはずだったサービス・アカウントのプロビジョニング・プロセスの取消しは行われません。かわりに、Oracle Identity Managerでの無効化および有効化アクションと同様の方法で、タスクがプロビジョニング・プロセスに挿入されます。このタスクによってユーザーからサービス・アカウントへのマッピングが削除され、サービス・アカウントが使用可能なアカウントのプールに戻されます。この管理機能は、APIを通じて公開されています。

表A-4に、サービス・アカウントの管理タスクとこれに対応するAPIを示します。

表A-4 サービス・アカウントの管理タスクと対応するAPI

タスク

説明

APIメソッド

サービス・アカウントの変更

既存の通常アカウントをサービス・アカウントに変更することも、既存のサービス・アカウントを通常アカウントに変更することもできます。どちらの場合も、サービス・アカウントの変更タスクがプロビジョニング・プロセスに挿入され、「プロセス定義」の「タスク」タブでアクティブになります。このプロビジョニング・プロセスに関連付けられている任意のアダプタが実行されます。アダプタがない場合は、事前定義されたレスポンス・コードが追加されます。

tcUserOperationsIntf.changeFromServiceAccount

tcUserOperationsIntf.changeToServiceAccount

サービス・アカウント・アラート

サービス・アカウントがリンクされているユーザーが削除または無効化された場合、「サービス・アカウント・アラート」タスクがサービス・アカウント・インスタンスのプロビジョニング・プロセスに挿入されます。このタスクを使用して、ユーザーに対して発生したイベントに応じた適切なアクションを開始できます。

該当なし

移動したサービス・アカウント

サービス・アカウントの所有権を、あるユーザーから別のユーザーに移すことができます。これによって、プロビジョニング・インスタンスは新しい所有者のリソース・プロファイルに表示され、古いユーザーのリソース・プロファイルには表示されなくなります。アカウントの移動後に、リソース・インスタンスのプロビジョニング・プロセスに「移動したサービス・アカウント」タスクが挿入されます。このプロビジョニング・プロセスに関連付けられている任意のアダプタが実行されます。アダプタがない場合は、事前定義されたレスポンス・コードが追加されます。

tcUserOperationsIntf.moveServiceAccount

A.2.1 サービス・アカウントのカスタマイズ: シナリオ1

次のシナリオでは、ユーザーがActive Directoryに対してサービス・アカウントをリクエストできるようにする方法について説明します。サービス・アカウントを作成するには、最初に通常アカウントを作成してから、changeToServiceAccount APIを使用してその通常アカウントをサービス・アカウントに変更します。次に、このプロセスを示します。

1. ユーザーがログインし、サービス・アカウントをリクエストします。

2. システムがActive Directoryスーパーバイザに承認を求めます。

3. Active Directoryスーパーバイザがリクエストを承認します。

4. サービス・アカウントが作成されます。

5. リクエストが承認されたことを示す通知が従業員に送信されます。

6. 後で、サービス・アカウント所有者のオフボーディングが行われると、その所有者のスーパーバイザがサービス・アカウントの新しい所有者として割り当てられ、新しい所有者に通知が送信されます。

このシナリオを実装するには、次の手順を実行します。

1. Active Directoryオブジェクト・フォームで、チェック・ボックス・フィールドを追加して、サービス・アカウントと通常アカウントのどちらをリクエストするかをユーザーが選択できるようにします。

2. Active Directoryプロセス・フォームを変更して、チェック・ボックス・フィールドを組み込み、データ・フローを確立します。

3. オブジェクト・フォームを更新するための権限をユーザーに付与します。
サービス・アカウントのリクエスト・プロセスは、ユーザーのセルフ・リクエスト・プロセスと同じです。リクエストは通常の方法で作成および承認されます。

4. アカウントの作成後に挿入されるプロビジョニング・プロセス(プロセス・フォームのサービス・アカウント・フラグをチェックし、現在のアカウントのoiu_keyを使用してchangeToServiceAccount() APIを呼び出すプロセス)に条件付きタスクを追加します。
プロビジョニングが開始されると、プロビジョニング・プロセスによってフラグがチェックされ、changeToServiceAccount() APIがロードされます。

タスクでは、タスク完了時に電子メール通知を送信できます。

5. ユーザーのオフボーディングが行われたら、アダプタを「サービス・アカウント・アラート」タスクにアタッチすることで、システムによって現在のユーザーの識別、そのユーザーのマネージャまたはスーパーバイザの参照、およびtcUserOperationsIntf.moveServiceAccount() APIのロードを通じて、サービス・アカウントの所有権が適切に再割当てされるようにします。

A.2.2 サービス・アカウントのカスタマイズ: シナリオ2

この項では、別のユーザーのサービス・アカウントの所有権をリクエスト・ユーザーに譲渡するようリクエストできるようにする方法について簡単に説明します。次に、このプロセスを示します。

1. ユーザーがOracle Identity Managerにログインし、特定のActive Directoryサービス・アカウントの所有権が現在のユーザーからリクエスト・ユーザーに譲渡されるようリクエストします。

2. リクエストが承認のために現在のサービス・アカウント所有者に転送されます。

3. 現在の所有者の承認を受けて、サービス・アカウントがリクエスト・ユーザーに譲渡されます。

このシナリオを実装するには、次の手順を実行します。

注意:

このユースケースでは、多くのカスタマイズが必要です。

1. Oracle Identity Managerユーザー・インタフェースではアカウント所有権の譲渡リクエストはサポートされていないため、ダミー・リソースを作成し、システムに存在するサービス・アカウントに対して特定のリソース・オブジェクトを問い合せるカスタム・ロジックを割り当てます。

2. このシナリオにおける承認者はサービス・アカウント所有者です。したがって、タスク割当てアダプタを使用して、最初にサービス・アカウント所有者を取得してから、その所有者にタスクを割り当てます。
前のシナリオで示したように、タスクではタスク完了時に電子メール通知を送信できます。

3. 承認を得たら、moveServiceAccount() APIをロードしてサービス・アカウントの所有権をリクエスタに譲渡します。

A.3 Design Consoleのアクション

表A-5に、Oracle Identity Managerのアクションと、その条件および結果を示します。

表A-5 Oracle Identity Managerのアクション、条件および結果

アクション

条件

結果

ユーザーの削除。

Oracle Identity Managerで、プロセス・インスタンスの既存のすべてのタスクが取り消されます。タスクに取消しタスクが定義されている場合は、これが挿入されます。

この場合、このタスクに対する条件が満たされ(ユーザーが失効され)、Oracle Identity Managerでタスクが既存のプロセスに挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

ユーザーの無効化。

Oracle Identity Managerで、「タスクの結果」コンボ・ボックスに「無効化」の選択肢が表示されるタスクに対する各プロセスがチェックされます。

この場合、このタスクに対する条件が満たされ(ユーザーが無効化され)、Oracle Identity Managerでタスクが既存のプロセスに挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

ユーザーの有効化。

Oracle Identity Managerで、「タスクの結果」コンボ・ボックスに「有効化」の選択肢が表示されるタスクに対する各プロセスがチェックされます。

この場合、このタスクに対する条件が満たされ(ユーザーが有効化され)、Oracle Identity Managerでタスクが既存のプロセスに挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

ユーザーのパスワードが「ユーザー」フォームで変更

Oracle Identity Managerで、各プロセスが「ユーザー・パスワードの変更」タスクを持つかどうかがチェックされます。

この場合、このタスクに対する条件が満たされ(ユーザーのパスワードが変更され)、Oracle Identity Managerで、タスクが定義されている既存のすべてのプロセスにタスクが挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

アプリケーション・プロセス・フォームのデータ・フィールドの変更。

Oracle Identity Managerで、各プロセスがfield label Updated命名規則で始まるタスク(HomeDirectory Updatedなど)を持つかどうかがチェックされます。

このタスクに対する条件が満たされ(プロセス・タスクはfield label Updated命名規則で始まる)ます。Oracle Identity Managerで、このタスクが定義されている既存のすべてのプロセスにタスクが挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

ユーザーのプロファイル情報が他の組織に移動。

Oracle Identity Managerで、各プロセスがMove Userで始まるタスクを持つかどうかがチェックされます。

このタスクに対する条件が満たされ(ユーザーのプロファイル情報が他の組織に移動)ます。Oracle Identity Managerでタスクが既存のプロセスに挿入されます。タスクに付加されているアダプタがある場合は、これが実行されます。

B FacesUtilsクラス

FacesUtilsクラスは、「マネージドBeanの使用」で示されているカスタマイズのユースケースで使用されます。このクラスには、コンポーネントの再レンダリング、EL式の評価およびバインディングを介した属性へのアクセスを行う様々なヘルパー・メソッドが含まれています。

例B-1は、一部のメソッドが実装されたFacesUtilsクラスのコード・スニペットを示しています。

例B-1 サンプルのFacesUtilsクラス

package oracle.iam.ui.sample.common.view.utils;

import java.io.IOException;

import java.util.Map;
import java.util.ResourceBundle;

import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.MethodExpression;
import javax.el.ValueExpression;

import javax.faces.application.Application;
import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;

import oracle.adf.model.BindingContext;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCControlBinding;
import oracle.adf.view.rich.context.AdfFacesContext;

import oracle.binding.AttributeBinding;
import oracle.binding.ControlBinding;

import oracle.iam.ui.platform.utils.TaskFlowUtils;

import oracle.javatools.resourcebundle.BundleFactory;

import oracle.jbo.uicli.binding.JUCtrlActionBinding;
import oracle.jbo.uicli.binding.JUCtrlListBinding;
import oracle.jbo.uicli.binding.JUEventBinding;

public class FacesUtils {

private FacesUtils() {
// do not instantiate
throw new AssertionError();
}

/*
* Re-render the component.
*/
public static void partialRender(UIComponent component) {
if (component != null) {
AdfFacesContext.getCurrentInstance().addPartialTarget(component);
}
}

/*
* Sets attribute value through attribute binding.
*/
public static void setAttributeBindingValue(String attributeName,
Object value) {
AttributeBinding binding = getAttributeBinding(attributeName);
if (binding != null) {
binding.setInputValue(value);
} else {
throw new IllegalArgumentException("Binding " + attributeName +
" does not exist.");
}
}

/*
* Gets attribute value using attribute binding.
*/
public static <T> T getAttributeBindingValue(String attributeName,
Class<T> clazz) {
AttributeBinding binding = getAttributeBinding(attributeName);
if (binding != null) {
return (T)binding.getInputValue();
} else {
throw new IllegalArgumentException("Binding " + attributeName +
" does not exist.");
}
}

/*
* Gets attribute value using list binding.
*/
public static <T> T getListBindingValue(String attributeName,
Class<T> clazz) {
ControlBinding ctrlBinding = getControlBinding(attributeName);
if (ctrlBinding instanceof JUCtrlListBinding) {
JUCtrlListBinding listBinding = (JUCtrlListBinding)ctrlBinding;
return (T)listBinding.getAttributeValue();
} else {
throw new IllegalArgumentException("Binding " + attributeName +
" is not list binding.");
}
}

public static ControlBinding getControlBinding(String name) {
ControlBinding crtlBinding = getBindings().getControlBinding(name);
if (crtlBinding == null) {
throw new IllegalArgumentException("Control Binding '" + name +
"' not found");
}
return crtlBinding;
}

public static AttributeBinding getAttributeBinding(String name) {
ControlBinding ctrlBinding = getControlBinding(name);
AttributeBinding attributeBinding = null;
if (ctrlBinding != null) {
if (ctrlBinding instanceof AttributeBinding) {
attributeBinding = (AttributeBinding)ctrlBinding;
}
}
return attributeBinding;
}

public static DCBindingContainer getBindings() {
FacesContext fc = FacesContext.getCurrentInstance();
ExpressionFactory exprfactory =
fc.getApplication().getExpressionFactory();
ELContext elctx = fc.getELContext();

ValueExpression valueExpression =
exprfactory.createValueExpression(elctx, "#{bindings}",
Object.class);

DCBindingContainer dcbinding =
(DCBindingContainer)valueExpression.getValue(elctx);

return dcbinding;
}

/*
* Evaluates EL expression and returns value.
*/
public static <T> T getValueFromELExpression(String expression,
Class<T> clazz) {
FacesContext facesContext = FacesContext.getCurrentInstance();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExp =
elFactory.createValueExpression(elContext, expression, clazz);
return (T)valueExp.getValue(elContext);
}

/*
* Gets MethodExpression based on the EL expression. MethodExpression can then be used to invoke the method.
*/
public static MethodExpression getMethodExpressionFromEL(String expression,
Class<?> returnType,
Class[] paramTypes) {
FacesContext facesContext = FacesContext.getCurrentInstance();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
MethodExpression methodExp =
elFactory.createMethodExpression(elContext, expression, returnType,
paramTypes);
return methodExp;
}

public static ELContext getELContext() {
return FacesContext.getCurrentInstance().getELContext();
}

/*
* Shows FacesMessage. The message will not be bound to any component.
*/
public static void showFacesMessage(FacesMessage fm) {
FacesContext.getCurrentInstance().addMessage(null, fm);
}

/*
* Launch bounded taskFlow based on provided parameters.
*/
public static void launchTaskFlow(String id, String taskFlowId,
String name, String icon,
String description, String helpTopicId,
boolean inDialog,
Map<String, Object> params) {
// create JSON payload for the contextual event
String jsonPayLoad =
TaskFlowUtils.createContextualEventPayLoad(id, taskFlowId,
name, icon, description,
helpTopicId, inDialog,
params);

// create and enqueue contextual event
DCBindingContainer bc =
(DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
DCControlBinding ctrlBinding = bc.findCtrlBinding(TaskFlowUtils.RAISE_TASK_FLOW_LAUNCH_EVENT);
// support both bindings - using eventBinding as well as methodAction
if (ctrlBinding instanceof JUEventBinding) {
JUEventBinding eventProducer = (JUEventBinding) ctrlBinding;
bc.getEventDispatcher().queueEvent(eventProducer, jsonPayLoad);
} else if (ctrlBinding instanceof JUCtrlActionBinding) {
JUCtrlActionBinding actionBinding = (JUCtrlActionBinding) ctrlBinding;
bc.getEventDispatcher().queueEvent(actionBinding.getEventProducer(), jsonPayLoad);
} else {
throw new IllegalArgumentException("Incorrect binding for " + TaskFlowUtils.RAISE_TASK_FLOW_LAUNCH_EVENT);
}
bc.getEventDispatcher().processContextualEvents();
}

/*
* Redirect to a provided url.
*/
public static void redirect(String url) {
try {
FacesContext fctx = FacesContext.getCurrentInstance();
fctx.getExternalContext().redirect(url);
fctx.responseComplete();
} catch (IOException ex) {
throw new RuntimeException(ex);
}
}

/**
* Retrieve value in ressource bundle
* @param key
* @return
*/
public static String getBundleValue(String bundleName, String key) {
FacesContext ctx = FacesContext.getCurrentInstance();
try {
ResourceBundle bundle =
BundleFactory.getBundle(bundleName, ctx.getViewRoot().getLocale());
return bundle.getString(key);
} catch (Exception e) {
return "";
}
}
}

索引
A B C D E F G H I J K L M N O P R S T U V W X

A

ユーザー・アカウント・ステータスのリコンシリエーション, 16.3.1.2

「アクション」フィールド, 8.20

アクション, 3.5.2

activeRequest, 32.10

アダプタ, 8.19, 8.19.1

マッピング, 8.19

アダプタ・ファクトリ, 1.1.14, 2.1.2.2.3 アダプタ・マッピング情報, 8.19 アダプタ変数, 8.7 アダプタ, 8.4 アダプタ

コンパイル, 38.1.4.11

エンティティ・アダプタ変数マッピング, 8.19.2.4

リテラル, 8.19.1.3

組織定義, 8.19.1.5

事前定義アダプタ変数マッピング, 8.19.2.5

プロセス定義, 8.19.1.6

プロセス・タスク・アダプタ変数マッピング, 8.19.2.2

参照, 8.19.1.4

ルール・ジェネレータ・アダプタ変数マッピング, 8.19.2.4

タスク, 8.19.1

タスク割当てアダプタ変数マッピング, 8.19.2.3

タスク・マッピング, 8.19.1

タスク, 8.19.1.2

ユーザー定義, 8.19.1.7

変数, 8.19.2

変数マッピング, 8.19.2

変数, 8.19.1.1

追加

カスタムSoDエンジン, 22.10.2

addRequest, 32.3 ADFコンポーネント

非表示および削除, 30.4.7

管理ロール, 3.1.1 APIサービス, 2.1.2.1 API, 31

よく使用されるサービス, 31.3

Oracle Identity Manager用クライアントの開発, 31.4

従来のAPI, 31.5

OIMclient, 31.1.1

Oracle Identity Managerサービス, 31.1, 31.2

リコンシリエーション, 23.6

tcUtilityFactory, 31.1.2

アプリケーション・インスタンス, 4

接続あり, 4

接続なし, 4

approval

操作レベル, 21.1.2

リクエスト・レベル, 21.1.2

承認ポリシー, 21.1.2 承認ワークフロー, 2.1.3.1 アーキテクチャ, 2

ビジネス・サービス層, 2.1.2

データ層, 2.1.4

プラットフォーム・サービス, 2.1.2.3

プレゼンテーション層, 2.1.1

リコンシリエーション, 23.2

層, 2.1

「アーカイブ・ディレクトリ」パラメータ, 17.1 アーカイブ・ディレクトリ, 権限, 17.1 イベント・ハンドラまたはアダプタの割当て, 4.3.4.2.4 非同期SoD検証プロセス, 22.8.2 事前移入アダプタのアタッチ, 8.17.1 プロセス・タスク・アダプタのプロセス・タスクへのアタッチ, 8.18.2 タスク割当てアダプタのプロセス・タスクへのアタッチ, 8.16.1 アテステーション

定義, 1.1.13

属性レベルのセキュリティ, 3.1.2

拒否される属性, 3.1.2

属性, 新規追加, 14.6.2 監査およびコンプライアンス管理

アテステーションの自動化, 1.1.13

包括的なレポート, 1.1.13

アイデンティティ・リコンシリエーション, 1.1.13

統制外および孤立アカウント, 1.1.13

監査およびレポート, 2.2 監査エンジン, 40 監査レベル, 40.1 監査管理, 1.1.13 監査

監査レベル, 40.1

監査メッセージ, 40.3

認可ポリシー, 2.1.3.2

B

バックエンド・セキュリティ, 3.5

「バッチ・サイズ」パラメータ, 19.2.4.2

バッチ・リコンシリエーション, 16.3.1.4, 19.2.4.2

batchRequest, 32.17

バッチサイズ・パラメータ, 23.1.1.2

ベスト・プラクティス

デプロイメント・マネージャ, 38.1.4

イベント・ハンドラ, 28.6

リコンシリエーション, 23.10

BPELプロセス, 21.1.2 バルク・ロード, 2.2 バルク・ロード・ユーティリティ, 24

クリーンアップ, 24.9

データファイルの作成, 24.2.2.2

表領域の作成, 24.2.2.1

入力ソースの作成, 24.4.2

機能, 24.1

例外の修正, 24.4.6

パフォーマンス・データの収集, 24.8

監査スナップショットの生成, 24.4.8

例外の処理, 24.4.5

入力パラメータ, 24.4.3

インストール, 24.2.1

アカウント・データのロード, 24.5

OIMユーザー・データのロード, 24.4

ロール、ロール階層、ロール・メンバーシップおよびロール・カテゴリ・データのロード, 24.6

進捗状況の監視, 24.4.4

オプション, 24.2.1.3

データベースの準備, 24.2.2

実行, 24.3

スクリプト, 24.2.1.1

デフォルト・パスワードの設定, 24.4.1

一時表, 24.2.1.2

結果の検証, 24.4.7

バルク編成, 28.1 バルク・リコンシリエーション, 23.1.1.5

C

コールバック

定義, 35.1

コールバック・サービス, 35

構成, 35.4

イベント処理, 35.1.2

属性のマッピング, 35.2

概要, 35.1

再試行, 35.1.3

コールバックの送信, 35.3

トラブルシューティング, 35.5

CallbackConfiguration.xml, 35.4 コールバック, 35

コールバック・サービス, 35

イベント処理, 35.1.2

cancelRequest, 32.16 チャレンジ質問

カスタマイズ, 30.8

子データセット, 16.2.1, 16.2.1, 16.2.2, 16.2.3, 16.2.3, 19.2.4.3.1, 19.2.4.3.4, 19.5.3.1, 20.2.2 コード, 8.20 共通のサービス, 2.2 コンポーネント, 2.2 連結変換プロバイダ, 17.5.1 構成

コールバック, 35.4

構成

LDAPとの統合, 2.1.4.4.1

プラグイン, 27.4

レポート, 39.5

スケジュール済タスクのplugin.xml, 26.5

スケジュール済タスクXMLファイル, 26.3

SoDエンジン, 22.5

LDAPコンテナ・ルールの構成, 25 接続アプリケーション・インスタンス, 4 コネクタ・フレームワーク, 2.1.2.2.1 コネクタのロード・バランサ, 14.1 コネクタ・オブジェクト, 16.4, 19.2.4.5, 19.3.3, 19.5.6 コネクタ・パフォーマンス

索引, 23.10

コネクタ・サーバー, 14.1 コネクタ, 2.1.2.2.1 containerIDフィールド, 19.2.4.3 コンテキスト, 29 接続なしアプリケーション・インスタンスから接続ありへの変換, 4.4 作成, 5.3.1

プロセス定義, 5.3.1

スケジュール済タスク, 26.1.1

変換レイヤー, 22.10.1.2

リモート・タスクの作成, 8.8.3 レスポンスの作成, 8.12.1 ストアド・プロシージャ・タスクの作成, 8.8.4 ユーティリティ・タスクの作成, 8.8.5 Oracle Identity Manager APIタスクの作成, 8.8.6 ディレクトリ構造の作成

スケジュール済タスク, 26.6

アダプタ・タスクの作成, 8.8 ITリソースの作成, 4.1 SOAコンポジットの作成, 21.2.1 CSVファイル, 20.1.2 CSVリコンシリエーション・フォーマット・プロバイダ, 17.2, 18.1.1, 18.3.1 「カスタム認証資格証明ネームスペース」パラメータ, 17.3.2 「カスタム認証ヘッダー要素」パラメータ, 17.3.2 「パスワードを格納するカスタム要素」パラメータ, 17.3.2 「ユーザー名を格納するカスタム要素」パラメータ, 17.3.2 カスタム・イベント・ハンドラ, 28.2 カスタム・イベント定義XML, 28.3.2 カスタム・ヘルプ・トピック

追加, 30.6.1

カスタム後処理イベント・ハンドラ, 28.3.1.3 カスタム・プロバイダ, 16.3.2.2, 18, 19.5.5 カスタムSoDエンジン, 22.2 カスタマイズ

インタフェース, 30

リコンシリエーションの処理, 23.4

UI, 30

カスタマイズ

インタフェース, 30

チャレンジ質問のカスタマイズ, 30.8 ヘルプのカスタマイズ, 30.6

D

データ・オブジェクト・マネージャ, 28.9

データセット, 19.2.4.3

子, 16.2.1, 16.2.1, 16.2.2, 16.2.3, 16.2.3, 19.2.4.3.1, 19.2.4.3.4, 19.5.3.1, 20.2.2

フィールド, 追加または編集, 19.2.4.3.1

OIM, 19.2.4.3, 19.2.4.4, 19.5.3.5

OIM - アカウント, 20.2.2, 20.2.2

「OIM - アカウント」データセット, 16.2.3

OIM - ユーザー, 20.2.2

「OIM - ユーザー」データセット, 16.2.3

「OIM」データセット, 16.2.3

プロビジョニング・ステージング, 19.2.4.3

「プロビジョニング・ステージング」データセット, 16.2.2

リコンシリエーション・ステージング, 16.2.1, 19.2.4.3, 20.2.2

ソース, 19.2.4.3

「ソース」データセット, 16.2.1

データ型, A.1, A.1 データベース, 2.1.4.1 データベースのバックアップ, 38.1.4.14 日付書式, 16.3.2.4 宣言

プラグイン, 27.5.2

暗黙的な宣言, 27.5.2

メタデータの定義

スケジュール済タスク, 26.2

イベント・メタデータの定義, 34.2.1.1 ITリソースの定義, 4.3.2.1 定義データ, 38.1.4.3 管理の委任, 1.1.6 レスポンスの削除, 8.12.3 deleteRequest, 32.5 アダプタ・タスクの削除, 8.11 ITリソースの削除, 4.2.3 拒否される属性, 3.1.2 デプロイ

レポート, 39.4

サービス・コンポーネント, 22.10.2.4

SOAコンポジット, 21.2.2

変換レイヤー, 22.10.1.3

SOAコンポジットのデプロイ, 21.3.5.8 リクエストWebサービスのデプロイ, 21.3.2.1 デプロイメント・マネージャ, 1.1.1, 38.1

ベスト・プラクティス, 38.1.4

デプロイメントのエクスポート, 38.1.2

システム・オブジェクトのエクスポート, 38.1.4.1

機能, 38.1.1

デプロイメントのインポート, 38.1.3

制限, 38.1.1

トラブルシューティング, 38.1.5

「説明」フィールド, 8.20 Design Console, A 設計パラメータ, 19.2.4.2 開発

Oracle Identity Managerのクライアント, 31.4

イベント・ハンドラ, 28

LDAP同期操作, 25

プラグイン, 27 スケジュール済タスク, 26 スケジュール済タスク・クラス, 26.4 開発

.NETを使用したアイデンティティ・コネクタ, 11

フラット・ファイル.NETコネクタの開発, 11.1 通知イベントの開発, 34 使用禁止化

SoD, 22.6.2

アダプタの無効化, 8.6 接続なしアプリケーション・インスタンス, 4

接続ありアプリケーション・インスタンスへの変換, 4.4

E

EL, 30.4.1

EL式, 30.4.1

「電子メール定義」フォーム, 5.2

電子メール通知, 5.3.3.6.1

割当て, 5.3.3.6.1

使用可能化

SoD, 22.6.1

ロギングの有効化

SoD関連イベント, 22.13

資格

フィールドのマーク, 22.9

エンティティ・アダプタ, 8.13 エンティティ・アダプタ, 38.1.4.12 イベント・コールバック

送信, 35.3

イベント・ハンドラ, 28.1

ベスト・プラクティス, 28.6

カスタム・イベント・ハンドラ, 28.2

開発, 28

LDAP同期操作の開発, 25

移行, 28.7

後処理, 28.3.1.3

実行順序の指定, 28.4

トラブルシューティング, 28.8

XML定義, 28.3.2

「イベント・ハンドラ・マネージャ」フォーム, 28.9.1 イベント・ハンドラ, 4.3.4.2.4 イベント・メタデータ

定義, 34.2.1.1

例外処理, 18.2.5 除外リスト, 14.4 実行スケジュール, 8.5.2 エクスポートの説明, 38.1.4.6 データのエクスポート

依存性, 38.1.4.8

拡張

リクエスト管理操作

属性の事前移入, 21.7.3

カスタム・コードの実行, 21.7.1

リクエスト・データの検証, 21.7.2

F

FacesUtilsクラス, B

リコンシリエーション停止の失敗しきい値, 16.3.1.6

機能, 1.1

フィールドレベル・セキュリティ, 3.5.3

「ファイル・エンコーディング」パラメータ, 17.1

「ファイルの接頭辞」パラメータ, 17.1

「固定列幅」パラメータ, 17.1

フラット・ファイル.NETコネクタ, 11.1

フォーム名, 17.1, 19.2.4.4, 20.2.1

完全リコンシリエーション, 16.3.1.3

機能およびデータ・セキュリティのマッピング, 3.2

G

「一般」タブ, 5.3.3.1

生成

Oracle Identity Managementレポート, 39.6

レポートの生成

サンプル・データソース, 39.6.1

BPELベースのJDBCデータソース, 39.6.3

本番JDBCデータソース, 39.6.2

汎用テクノロジ・コネクタ, 2.1.2.2.4 汎用テクノロジ・コネクタ

コネクタ・オブジェクト, 16.4, 19.2.4.5, 19.3.3

汎用テクノロジ・コネクタ・フレームワーク

機能, 16.3

汎用テクノロジ・コネクタ

ユーザー・アカウント・ステータスのリコンシリエーション, 16.3.1.2

アーキテクチャ, 16.2

バッチ・リコンシリエーション, 16.3.1.4

作成, 19.2

データセット

「データセット」を参照

日付書式, 16.3.2.4 エクスポート, 19.3.2 機能, 16.3 完全リコンシリエーション, 16.3.1.3 機能アーキテクチャ, 16.2 インポート, 19.3.3, 20.2.1 増分リコンシリエーション, 16.3.1.3 管理, 19.3 マッピング, 目的, 16.2 変更, 19.3.1, 19.5.7 必要性, 16.1 プロバイダ

「プロバイダ」を参照

プロビジョニング・モジュール, 16.2.2, 16.2.2 複数値属性データの削除のリコンシリエーション, 16.3.1.5 トラブルシューティング, 20

構成の問題, 20.2

一般的な問題, 20.1

信頼できるソースのリコンシリエーション, 16.3.1.1 GTC, 2.1.2.2.4

H

競合状態の処理, 23.1.3.2

ヘルプ, 30.6

インライン・ヘルプの追加, 30.6.2

カスタム・ヘルプ・トピック, 30.6.1

ヘルプURL, 8.20 高可用性, 2.1.4.1 ホーム・ページのカスタマイズ, 30.7 水平表, 23.1.1.7, 23.1.3.1 プロセス・タスク・アダプタの仕組み, 8.18.1 ヒューマン・タスク, 21.1.2

I

ICF, 2.1.2.2.2

ベスト・プラクティスおよびFAQ, 15

フィルタ構文, 12.8

GroovyFilterBuilder, 12.8

Oracle Identity Managerとの統合, 12

アーキテクチャ, 12.2

Java API, 13

事前定義済のスケジュール済タスク, 12.7

「グループ・メンバーシップ情報を保持している子データセットのID属性」パラメータ, 17.3.2 IDフィールド, 19.2.4.3, 19.2.4.3, 19.2.6 アイデンティティ管理, 2.2 アイデンティティの証明, 1.1.13 アイデンティティ・コネクタ, 2.1.2.2.2

一般的なカスタマイズ, 14

コネクタのロード・バランサ, 14.1

コネクタ・サーバー, 14.1

.NETを使用したアイデンティティ・コネクタの開発, 11

ICFプロビジョニング・マネージャ, 12.5.1

Oracle Identity Managerの参照, 12.3

リソース除外リスト, 14.4

コネクタ・サーバーおよびOracle Identity Manager間のSSL, 14.5

ターゲット・システムの属性, 14.6

ユーザー・リコンシリエーション中のデータの変換, 14.3

リコンシリエーションおよびプロビジョニング中のデータの検証, 14.2

アイデンティティ・コネクタ・フレームワーク, 2.1.2.2.2

アイデンティティ・コネクタ, 2.1.2.2.2

Identity Connector Framework

バンドルJAR, 9.5

Javaコネクタ・サーバー, 9.6.1

.NETコネクタ・サーバー, 9.6.2

サーバー, 9.6

SSL, 9.6.1.5

アイデンティティ・ストア, 2.1.4.3 タスク・フロー・リージョンの実装, 3.5.1 データのインポート, 38.1.4.15 増分リコンシリエーション, 16.3.1.3 インライン・ヘルプ

追加, 30.6.2

統合ソリューション

アダプタ・ファクトリ, 1.1.14

事前定義済コネクタ, 1.1.14

統合, 5.3.3.2 統合

Oracle Identity ManagerとLDAP, 2.1.4.4

統合サービス, 2.1.2.2 統合ソリューション, 1.1.14 監査メッセージの発行タスク, 40.3 「ITリソース・タイプ定義」フォーム, 4.3.2 ITリソース, 作成, 4.1 ITリソース, 削除, 4.2.3 ITリソース, 管理, 4.2 ITリソース, 変更, 4.2.2 ITリソース, 表示, 4.2.1

J

Javaコネクタ・サーバー, 9.6.1

K

「キー」フィールド, 8.20

L

LDAP, 2.1.4.3, 2.1.4.4

コンテナ・ルール, 25

LDAPコンテナ・ルール

構成, 25

LDAPアイデンティティ・ストア, 2.1.4.4

プロビジョニング, 2.1.4.4.2

リコンシリエーション, 2.1.4.4.5

LDAP統合

構成, 2.1.4.4.1

LDAP同期操作

イベント・ハンドラの開発, 25

listTargets, 32.7 ロギング, 18.2.5, 18.2.5 「参照定義」フォーム, 7.1, 7.2 参照フィールド, 19.2.4.3.1 参照問合せ, A.1 lookupRequest, 32.13 lookupUsernamePolicy, 32.15

M

マネージドBean, 30.10

ITリソースの管理, 4.2

サンドボックスの管理, 30.2

マッピング

Identity ManagerおよびSPML属性, 35.2

ルール・ジェネレータ・アダプタ変数のマッピング, 8.14.1 マッピング, 16.3.2.1, 19.2.4.3, 19.2.4.3.1, 19.5.3.4

例, 19.2.4.3

制限, 20.2.2

変換マッピング, 20.2.2

権限としてのフィールドのマーク, 22.9 MDS, 2.1.4.2 MDSのバックアップ, 37.1.5 メニュー項目, 汎用テクノロジ・コネクタの作成, 19.2.3 メタデータ, 19.2.4.3

MDSからの削除, 37.1.3

MDSへのエクスポート, 37.1.1

MDSからのインポート, 37.1.2

メタデータの定義

「メタデータの検出」を参照

メタデータの検出, 18.1.1, 19.2.4.2, 19.2.4.3, 19.3.1, 19.5.2, 20.2.4 メタデータ・ストア, 2.1.4.2 変更

SoD用の承認ワークフロー, 22.8.1

SoD用のプロビジョニング・ワークフロー, 22.8.2

登録XMLファイル, 22.10.1.4

SoDエンジン用登録XMLファイル, 22.10.2.5

レスポンスの変更, 8.12.2 アダプタ変数の変更, 8.7.2 アダプタ・タスクの変更, 8.9 ITリソースの変更, 4.2.2 プロセス・タスクの変更, 5.3.3 modifyRequest, 32.4 多言語サポート, 16.3.2.3, 18.2.7, 20.1.2 複数のサーバー・インスタンス, 1.1.4 複数の信頼できるソースのリコンシリエーション, 4.3.4.3

N

ネーミング規則, 38.1.4.4

.NETコネクタ・サーバー, 9.6.2

.NETコネクタ・サーバー

コネクタ・バンドルのデプロイ, 11.2

「注意」フィールド, 8.20 通知

カスタム通知, 34.2

定義, 35.1

イベント・メタデータXML, 34.2.1

トラブルシューティング, 34.3

通知イベント, 34.1

開発, 34

「通知」タブ, 5.3.3.6 通知テンプレート, 34.1

O

OAACG SILプロバイダ, 22.2, 22.2, 22.2, 22.2

objectClassフィールド, 19.2.4.3

OES, 3

OESポリシー, 3.4

OIA SILプロバイダ, 22.2

「OIM - アカウント」データセット, 16.2.3, 20.2.2, 20.2.2

「OIM - ユーザー」データセット, 16.2.3, 20.2.2

「OIM」データセット, 16.2.3

OIMデータセット, 19.2.4.3, 19.2.4.4, 19.5.3.5

OIMユーザー, 16.3.2.5

オープン・アーキテクチャ, 1.1.5

操作データ, 38.1.4.3

操作レベルの承認, 21.1.2

Oracle Application Access Controls Governor, 22.2, 22.5.1, 22.7.1, 22.10.1, 22.10.1.4, 22.10.1.5.1, 22.10.2, 22.10.2.2, 22.10.2.5

Oracle E-Business Suite, 22.5.1, 22.10.1, 22.10.1.5.1, 22.10.2

Oracle E-Business User Management, 22.2, 22.8, 22.8.2

Oracle Entitlements Server, 3

Oracle Identity Analytics, 22.5.3

Oracle Identity Managementレポート, 39.1

Oracle Identity Manager

アーキテクチャ, 2

コンポーネント, 2.2

コネクタ, 2.1.2.2.1

機能, 1.1

LDAP統合, 2.1.4.4

セキュリティのアーキテクチャ, 3

セキュリティ・モデル, 3.1

システム要件, 1.2

アーキテクチャの層, 2.1

Oracle Identity Manager API, 31 Oracle Identity Managerレポート, 2.1.3.5 編成, 28.1 組織プロビジョニング, A.1 組織階層

エクスポート, 38.1.4.5

P

パートナ・リンク, 21.1.2

パスワード・フィールド, 19.5.3.2, 20.1.3

パスワード型フィールド, 19.5.3.3, 20.1.3

権限, 汎用テクノロジ・コネクタの作成, 19.2.3

プラグイン

構成, 27.4

プラグイン・ストア

データベース・ストア, 27.1.2.2

ファイル・ストア, 27.1.2.1

プラグイン・ストア, 27.1.2 プラグイン・フレームワーク, 2.1.2.3.1 プラグイン

宣言, 27.5.2

暗黙的な宣言, 27.5.2

開発, 27 ディレクトリ構造, 27.5.1 登録, 27.6

APIの使用, 27.6.1

登録ユーティリティの使用, 27.6.2

ポリシー移行, 38.3 ポリシーの責任, 3.1.3 事前に構成されたSoDコネクタ

Oracle E-Business User Management, 22.2, 22.8, 22.8.2

SAP User Managementコネクタ, 22.2, 22.8

事前定義済プロバイダ

CSVリコンシリエーション・フォーマット・プロバイダ, 17.2, 18.1.1, 18.3.1

共有ドライブ・リコンシリエーション・トランスポート・プロバイダ, 17.1, 18.3.1, 19.5.2, 19.5.2, 19.5.4

SPMLプロビジョニング・フォーマット・プロバイダ, 17.3, 18.1.1, 18.2.1.2, 18.3.2

変換プロバイダ, 17.5

検証プロバイダ, 17.6

Webサービス・プロビジョニング・トランスポート・プロバイダ, 17.4, 18.2.1.2, 18.3.2

事前定義済のリクエスト・データセット, 21.6 「プロセス定義」フォーム, 5.3 プロセス・エンジン, 1.1.10 プロセス・フォーム, 17.1, 19.2.4.4, 20.1.2, 20.2.1 プロバイダ

定義, 16.2

パラメータ, 設計, 19.2.4.2

パラメータ, ランタイム, 19.2.4.2

プロビジョニング・フォーマット・プロバイダ, 16.2.2, 18.1.1, 19.2.4.1

プロビジョニング・トランスポート・プロバイダ, 16.2.2, 18.1.1, 19.2.4.1

リコンシリエーション・フォーマット・プロバイダ, 16.2.1, 18.1.1, 18.2.1.1, 19.2.4.1

リコンシリエーション・トランスポート・プロバイダ, 16.2.1, 18.1.1, 18.2.1.1, 19.2.4.1

リソース・バンドル, 18.2.7

再利用, 18.3

ロール, 18.1

選択, 19.2.4.1

変換プロバイダ, 16.2.2

変換プロバイダ, 16.2.1, 19.2.4.3.1

検証プロバイダ, 16.2.1, 19.2.4.3.1

XMLファイル, 18.2.6, 18.2.6

「事前定義済プロバイダ」を参照

プロビジョニング, 1.1.15, 2.2

アプリケーション・インスタンス, 4

Oracle Identity ManagerからLDAP, 2.1.4.4.2

プロビジョニング・コールバック, 21.1.2 プロビジョニング・フォーマット・プロバイダ, 16.2.2, 18.1.1, 19.2.4.1 プロビジョニング・ステージング, 16.2.2 「プロビジョニング・ステージング」データセット, 19.2.4.3 プロビジョニング・トランスポート・プロバイダ, 16.2.2, 18.1.1, 19.2.4.1 PSO

マッピング関連, 35.2

エンティティのパブリッシュ, 3.3

R

「複数値属性データの削除の調整」パラメータ, 19.2.4.2

リコンシリエーション

アクション・モジュール, 23.2.7.2

アクション・ルール, 23.2.2, 23.2.7.2

新規属性の追加, 14.6.2

非定型リンク, 23.1.2, 23.1.3.3

API, 23.2.5

アーキテクチャ, 23.2

アーカイブ, 23.2.9

自動再試行, 23.1.1.2, 23.1.3.2

下位互換性, 23.2.10

バッチ, 23.1.1.4

ベスト・プラクティス, 23.10

バルク, 23.1.1.5

コネクタ, 23.2.8

エンジン, 23.2.7

エラー・メッセージ, 23.9

機能, 23.1

水平表, 23.1.1.7, 23.1.3.1

インタフェース, 23.2.11

Javaエンジン, 23.1.1.6

LDAPからOracle Identity Manager, 2.1.4.4.5

マッピング・ルール, 23.2.2

照合モジュール, 23.2.7.1

一致ルール, 23.2.2

メタデータ, 23.2.2

パラメータ, 23.1.1.2

バッチサイズ, 23.1.1.2

パフォーマンスの向上, 23.1.1 プロファイル, 23.2.1 競合状態, 23.1.3.2 RECON_EXCEPTIONS表, 23.9 実行, 23.2.4 スキーマ, 23.2.6 ターゲット, 23.2.3 ターゲット属性, 23.2.2 トラブルシューティング, 23.8 リコンシリエーション・エンジン, 2.2 リコンシリエーション・エンジン, 23.2.7

アクション・モジュール, 23.2.7.2

照合モジュール, 23.2.7.1

リコンシリエーション・フォーマット・プロバイダ, 16.2.1, 18.1.1, 18.2.1.1, 19.2.4.1 複数値属性データの削除のリコンシリエーション, 16.3.1.5 リコンシリエーションの処理

カスタマイズ, 23.4

リコンシリエーション・プロファイル, 23.5

プロファイル・モードの変更, 23.5.2

更新, 23.5

「リコンシリエーション・ステージング」データセット, 16.2.1, 19.2.4.3, 20.2.2 リコンシリエーション・トランスポート・プロバイダ, 16.2.1, 18.1.1, 18.2.1.1, 19.2.4.1 「リコンシリエーション・タイプ」パラメータ, 19.2.4.2 登録

新規ターゲット・システム, 22.10.1.5

プラグイン, 27.6

APIの使用, 27.6.1

登録ユーティリティの使用, 27.6.2

SILプロバイダ, 22.10.2.6 登録XMLファイル

変更, 22.10.1.4

オブジェクトの関連グループ

エクスポート, 38.1.4.2

処置フィールド, 8.20 Remote Manager, 2.1.2.2.5 「Remote Manager」フォーム, 7.1, 7.3 電子メール通知の削除, 5.3.3.6.2 プロセス・タスク・アダプタのプロセス・タスクからの削除, 8.18.3 ルール・ジェネレータのフォーム・フィールドからの削除, 8.14.3 タスク割当てアダプタのプロセス・タスクからの削除, 8.16.2 JDBCベースのJDBCデータソースの名前変更, 39.6.3 レポート権限, 38.1.4.13 レポート, 2.1.3.5 レポート, 39.1

構成, 39.5

デプロイ, 39.4

生成, 39.6

Oracle BI Publisher, 39.2

リポジトリ, 2.1.4.1 リクエスト, 21.1.2 リクエスト・コールバック, 21.1.2 リクエスト・データセット, 21.6

事前定義済 21.6

リクエスト管理操作, 21.7

拡張, 21.7

属性の事前移入, 21.7.3

カスタム・コードの実行, 21.7.1

リクエスト・データの検証, 21.7.2

リクエスト・ペイロード, 21.1.2 リクエスト・サービス, 2.1.3.1, 2.1.3.1 リクエストWebサービス, 21.1.2 リクエスト・レベルの承認, 21.1.2 カウントのリセット・フィールド, 8.20 resetPasswordRequest, 32.14 リソース・バンドル, 18.2.7 「リソース・オブジェクト」フォーム, 4.3.1 リソース, 8.5.3 レスポンス, 8.5.6 resumeRequest, 32.9 プロバイダの再利用, 18.3 ロール権限, 38.1.4.13 「ルール・デザイナ」フォーム, 4.3.1 ルール要素, A.1, A.1 ランタイム・パラメータ, 19.2.4.2

S

サンプルXML

スケジュール済タスク, 26.3

サンドボックス, 30.2 サンドボックス

アクティブ化, 30.2

アクティブ化, 30.2.3

同時実行の競合, 30.2.1

作成, 30.2.2

非アクティブ化, 30.2

非アクティブ化, 30.2.3

削除, 30.2.8

エクスポート, 30.2

エクスポート, 30.2.5

インポート, 30.2

インポート, 30.2.5

管理, 30.2

公開, 30.2

公開, 30.2.6

変更を元に戻す, 30.2.9

表示と変更, 30.2.4

SAP CUA, 22.10.1.5.1 SAP GRC, 22.2, 22.5.2, 22.7.2, 22.10.1, 22.10.2 SAP GRC SILプロバイダ, 22.2, 22.2, 22.2 SAP R/3, 22.5.2, 22.10.1.5.1 SAP User Managementコネクタ, 22.2, 22.8 スケジュール済タスク

XMLファイルの構成, 26.3

作成, 26.1.1

ディレクトリ構造の作成, 26.6

メタデータの定義, 26.2

開発, 26

スケジュール済タスク・クラスの開発, 26.4

監査メッセージの発行タスク, 40.3

サンプルXMLファイル, 26.3

スケジュール済タスクのplugin.xml

構成, 26.5

スケジュール済タスク, 38.1.4.11

パラメータの一致, 38.1.4.9

スケジューラ・サービス, 2.1.3.4 ルール・ジェネレータのスケジューリング, 8.13 SDK表

更新, 38.1.4.16

セキュリティ

アクション, 3.5.2

属性レベルのセキュリティ, 3.1.2

バックエンド・セキュリティ, 3.5

フィールドレベル・セキュリティ, 3.5.3

機能およびデータ・セキュリティのマッピング, 3.2

タスク・フロー・リージョンの実装, 3.5.1

OESポリシー, 3.4

ポリシーの責任, 3.1.3

エンティティのパブリッシュ, 3.3

UIレベルのセキュリティ, 3.5

セキュリティのアーキテクチャ, 3 セキュリティ・モデル, 3.1 職務の分離, 2.1.2.3.2 サービス・アカウント

管理タスク, A.2

サービス・アカウント, A.2, A.2 サービス・コンポーネント

デプロイ, 22.10.2.4

「重大度」フィールド, 8.20 共有ドライブ・リコンシリエーション・トランスポート・プロバイダ, 17.1, 18.3.1, 19.5.2, 19.5.2, 19.5.4 SIL, 22.2 SILプロバイダ, 22.2

登録, 22.10.2.6

SILプロバイダ, 22.2, 22.4, 22.10.1.4, 22.10.2.5

OAACG, 22.2, 22.2, 22.2

OIA, 22.2

SAP, 22.2, 22.2

SILConfig.xml, 22.10.1.5.1, 22.10.1.5.1, 22.10.1.5.2, 22.10.2.6 SOAコンポジット, 21.1.2

作成, 21.2.1

デプロイ, 21.3.5.8

SOAコンポジット

デプロイ, 21.2.2

SoD, 2.1.2.3.2, 22

カスタム・ターゲット・システム, 22.10.1

無効化, 22.6.2

有効化, 22.6.1

ロギングの有効化, 22.13

承認ワークフローの変更, 22.8.1

プロビジョニング・ワークフローの変更, 22.8.2

プロビジョニング・ワークフロー, 22.12

DefaultSoDApprovalによるリクエスト・プロビジョニング, 22.12.7

SoD起動ライブラリ, 22.2 トラブルシューティング, 22.14 検証プロセス, 22.1 SoDチェックWebサービス, 22.7.3 SoDエンジン

構成, 22.5

カスタム, 22.10.2

登録XMLファイルの変更, 22.10.2.5

SoDエンジン

Oracle Application Access Controls Governor, 22.2, 22.5.1, 22.7.1, 22.10.1, 22.10.1.4, 22.10.1.5.1, 22.10.2, 22.10.2.2, 22.10.2.5

Oracle Identity Analytics, 22.5.3

SAP GRC, 22.2, 22.5.2, 22.7.2, 22.10.1, 22.10.2

SoDターゲット・システム

Oracle E-Business Suite, 22.5.1, 22.10.1, 22.10.1.5.1, 22.10.2

SAP CUA, 22.10.1.5.1

SAP R/3, 22.5.2, 22.10.1.5.1

ソース, 16.2.1 「ソース」データセット, 19.2.4.3 「ソース日付書式」パラメータ, 19.2.4.2 「指定されたデリミタ」パラメータ, 17.1 SPML, 32

activeRequest, 32.10

addRequest, 32.3

属性とLDAPマッピング, 32.20

batchRequest, 32.17

cancelRequest, 32.16

deleteRequest, 32.5

例, 32.21

一般的な考慮事項, 32.2

listTargets, 32.7

lookupRequest, 32.13

lookupUsernamePolicy, 32.15

modifyRequest, 32.4

resetPasswordRequest, 32.14

resumeRequest, 32.9

Webサービスの保護, 32.18

statusRequest, 32.6

suggestUsername, 32.12

suspendRequest, 32.8

validateUsername, 32.11

XSD, 32

SPML属性, 35.2 SPML操作, サポート, 17.3 SPMLプロビジョニング・フォーマット・プロバイダ, 17.3, 18.1.1, 18.2.1.2, 18.3.2 「SPML Webサービスのバインディング・スタイル(DOCUMENTまたはRPC)」パラメータ, 17.3.2 「SPML Webサービスの複合データ型」パラメータ, 17.3.2 「SPML Webサービス操作名」パラメータ, 17.3.2 「SPML WebサービスのSOAPメッセージ本文の接頭辞」パラメータ, 17.3.2 「SPML Webサービスのターゲット・ネームスペース」パラメータ, 17.3.2 SSL

Identity Connector Framework, 9.6.1.5

コネクタ・サーバーおよびOracle Identity Manager間の通信, 14.5

SSL, SoD検証用の構成, 22.10.2.2 SSL, Webサービス用の構成, 17.4.1 「ステージング・ディレクトリ(複数値アイデンティティ・データ)」パラメータ, 17.1 「ステージング・ディレクトリ(親アイデンティティ・データ)」パラメータ, 17.1 ステージング・ディレクトリ, 権限, 17.1 標準ターゲット・システム属性, 14.6.1 statusRequest, 32.6 「ステップ1 基本情報の指定」ページ, 16.4, 17.2, 19.2.4.1, 19.2.4.5, 19.5.1 「ステップ2 パラメータ値の指定」ページ, 19.2.4.2, 19.2.4.5, 19.5.2, 19.5.2 「ステップ3 コネクタ構成の変更」ページ, 17.1, 19.2.4.3, 19.2.4.5, 19.5.3, 20.1.2, 20.1.2 「ステップ4 コネクタ・フォーム名の検証」ページ, 17.1, 19.2.4.4, 19.2.4.5, 20.1.1 「ステップ5 コネクタ情報の検証」ページ, 19.2.4.5, 20.1.1 「リコンシリエーション停止のしきい値」パラメータ, 19.2.4.2 「停止しきい値最小レコード」パラメータ, 19.2.4.2 suggestUsername, 32.12 suspendRequest, 32.8 システム・オブジェクト

エクスポート, 38.1.4.1

システム要件, 1.2

T

「タブ区切り」パラメータ, 17.1

「アダプタ・ファクトリ」フォームのタブ, 8.5

「ターゲット日付書式」パラメータ, 19.2.4.2

「ターゲットID」パラメータ, 17.3.1

ターゲット・システム

登録, 22.10.1.5

タスク依存性タブ, 5.3.3.3 タスク・フロー

保護, 30.5.2

タスク・フロー・リージョン, 3.5.1 タスクフロー, 30.10 変換, 14.3 変換レイヤー

作成, 22.10.1.2

デプロイ, 22.10.1.3

変換プロバイダ, 16.2.1, 16.2.2, 17.5

連結変換プロバイダ, 17.5.1

翻訳変換プロバイダ, 17.5.2

変換プロバイダ, 19.2.4.3.1 翻訳変換プロバイダ, 17.5.2 トラブルシューティング

コールバック, 35.5

デプロイメント・マネージャ, 38.1.5

イベント・ハンドラ, 28.8

通知, 34.3

リコンシリエーション, 23.8

信頼できるソース・リコンシリエーション, 16.3.1.1, 19.2.4.1

U

UDF, 20.1.3

UIのカスタマイズ, 30

リンクの追加, 30.4.6

ブランドおよびロゴ, 30.3.3

概要, 30.1

ホーム・ページのカスタマイズ, 30.7

スキンのカスタマイズ, 30.3

マネージドBeanの開発, 30.10

EL式, 30.4.1

ADFコンポーネントの非表示および削除, 30.4.7

ページ, 30.4

タスク・フローの保護, 30.5.2

属性の表示および非表示, 30.4.8

コンポーネントの表示および非表示, 30.4.2

リクエスト・プロファイルの条件付き表示, 30.4.3

タスクフロー, 30.10

暫定UI, 30.9

Webコンポーザ, 30.1.3

UIレベルのセキュリティ, 3.5 「一意の属性(親データ)」パラメータ, 17.1 更新

リコンシリエーション・プロファイル, 23.5

使用状況参照, 8.5.5 ユーザー・アカウントのメニュー項目, 19.2.3 ユーザー・アカウント権限, 19.2.3 ユーザー・アカウント・ステータスのリコンシリエーション, 17.5.2.1, 17.5.2.1, 19.2.4.3.1, 19.2.4.3.1 ユーザーが修正可能なメタデータ・ファイル, 37.1.4 「ユーザー名(認証)」パラメータ, 17.3.1 「ユーザー・パスワード(認証)」パラメータ, 17.3.1 ユーティリティ, 36

バルク・ロード, 24

JARの削除, 37.2.3

リソース・バンドルの削除, 37.2.6

デプロイおよびアンデプロイ, 36

JARのダウンロード, 37.2.2

リソース・バンドルのダウンロード, 37.2.5

テストから本番へ, 36

JARのアップロード, 37.2.1

リソース・バンドルのアップロード, 37.2.4

V

validateUsername, 32.11

検証プロバイダ, 16.2.1, 19.2.4.3.1

検証プロバイダ, 事前定義済, 17.6

値オブジェクト, 18.2.3

変数リスト, 8.5.4

変数, A.1, A.1

ITリソースの表示, 4.2.1

W

警告, 38.1.4.7

Webコンポーザ, 30.1.3

「WebサービスのSOAPアクション」パラメータ, 17.3.2

「WebサービスURL」パラメータ, 17.4

Webサービス・プロビジョニング・トランスポート・プロバイダ, 17.4, 18.2.1.2, 18.3.2

Webサービス, SSLの構成, 17.4.1

Webベースのユーザー・セルフサービス, 1.1.7

ワークフロー

アーキテクチャ, 21.1.3

BPELプロセス, 21.1.2

概要, 21.1.2

SOAコンポジットのデプロイ, 21.3.5.8

リクエストWebサービスのデプロイ, 21.3.2.1

ワークフローの開発, 21.3

ヒューマン・タスク, 21.1.2

概要, 21.1.1

パートナ・リンク, 21.1.2

プロビジョニング・コールバック, 21.1.2

リクエスト・コールバック, 21.1.2

リクエスト・ペイロード, 21.1.2

リクエストWebサービス, 21.1.2

SOAコンポジット, 21.1.2

ワークフローおよびポリシー

プロビジョニング解除, 1.1.15

動的エラー処理, 1.1.12

ポリシー管理, 1.1.12

プロビジョニング, 1.1.15

リクエスト追跡, 1.1.12

トランザクションの整合性, 1.1.12

ワークフロー管理, 1.1.12

ワークフローおよびリクエスト・サービス, 2.2 ワークフローのアーキテクチャ, 21.1.3 ワークフロー, 21.1.1 レスポンスの使用, 8.12 「SPML WebサービスのWSSEが構成されていますか。」パラメータ, 17.3.2

X

XMLファイル

汎用テクノロジ・コネクタ, 19.2.4.5

プロバイダ, 18.2.6

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2013, 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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。