Fusion Middleware Oracle Identity Managerユーザーズ・ガイド

11g リリース1(11.1.1)

B66706-01(原本部品番号:E14316-08)

目次

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

第I部 概念

1 機能の概要

- 1.1 Oracle Identity Managerの機能

- 1.1.1 ユーザー管理

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

- 1.1.3 パスワード管理

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

- 1.1.5 統合ソリューション

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

- 1.1.7 組織およびロール管理

2 アーキテクチャ

- 2.1 主な特長と利点

- 2.1.1 デプロイの容易性

- 2.1.2 柔軟性と耐性

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

- 2.1.4 広範なユーザー管理

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

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

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

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

- 2.1.9 組込みの変更管理

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

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

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

- 2.2.2.1 APIサービス

- 2.2.2.2 統合サービス

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

- 2.2.3 データ層

- 2.2.3.1 Oracle Identity Managerデータベース

- 2.2.3.2 メタデータ・ストア

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

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

3 ユーザー・インタフェース

- 3.1 Oracle Identity Manager管理およびユーザー・コンソールの概要

- 3.1.1 ユーザー・セルフサービス

- 3.1.1.1 ユーザー・セルフサービスの機能

- 3.1.2 Oracle Identity Administration

- 3.1.2.1 Oracle Identity Administrationの機能

- 3.1.3 Oracle Identity Manager拡張管理

- 3.1.3.1 Oracle Identity Manager拡張管理の機能

- 3.1.4 Oracle Identity Manager管理およびユーザー・コンソールのカスタマイズ

- 3.1.5 ユーザー・インタフェースのローカライズ

- 3.2 Oracle Identity Manager Design Consoleの概要

- 3.2.1 Oracle Identity Manager Design Consoleの機能

- 3.3 SPML Webサービス

4 デプロイメント構成

- 4.1 プロビジョニング構成

- 4.2 リコンシリエーション構成

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

- 4.2.1.1 リコンサイル対象オブジェクトに基づくリコンシリエーション

- 4.2.1.2 リコンシリエーションのモード

- 4.2.1.3 リコンシリエーションに使用されるアプローチ

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

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

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

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

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

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

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

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

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

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

- 4.2.2.10 アーカイブ

- 4.2.2.11 下位互換性

- 4.2.2.12 リコンシリエーション・マネージャ

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

- 4.3.1 LDAPとの統合の構成

- 4.3.2 Oracle Identity ManagerからLDAPアイデンティティ・ストアへのデータのプロビジョニング

- 4.3.2.1 ユーザーの管理

- 4.3.2.2 ロールの管理

- 4.3.3 LDAPアイデンティティ・ストアからOracle Identity Managerへのリコンシリエーション

5 統合ソリューション

- 5.1 事前定義済コネクタ

- 5.2 汎用テクノロジ・コネクタ

- 5.3 カスタム・コネクタ

- 5.4 すべてのコネクタに共通するコンポーネント

- 5.4.1 プロビジョニング・プロセス・タスク

- 5.4.2 リコンシリエーション関連プロビジョニング・プロセス・タスク

- 5.5 コネクタのインストール

6 監査

- 6.1 概要

- 6.1.1 監査の設計要素

- 6.1.2 プロファイル監査機能

- 6.1.3 標準レポートとカスタマイズ・レポート

- 6.2 監査エンジン

- 6.2.1 監査レベル

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

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

- 6.3 ユーザー・プロファイル監査機能

- 6.3.1 監査用に収集されるデータ

- 6.3.1.1 ユーザー・プロファイル監査データの取得

- 6.3.1.2 スナップショットの保存

- 6.3.1.3 スナップショット取得のトリガー

- 6.3.2 ユーザー・プロファイル監査に使用されるポストプロセッサ

- 6.3.3 ユーザー・プロファイル監査に使用される表

- 6.3.4 アーカイブ

- 6.4 ロール・プロファイル監査機能

- 6.4.1 監査用に収集されるデータ

- 6.4.1.1 ロール・プロファイル監査データの取得とアーカイブ

- 6.4.1.2 スナップショットの保存

- 6.4.1.3 スナップショット取得のトリガー

- 6.5 監査機能の有効化と無効化

- 6.5.1 監査機能の無効化

- 6.5.2 監査機能の有効化

第II部 Oracle Identity Managerセルフサービス

7 セルフサービス登録の構成および使用

- 7.1 セルフサービス登録の使用

- 7.1.1 Oracle Identity Manager管理およびユーザー・コンソールへのログイン

- 7.1.2 登録リクエストの送信

- 7.1.3 登録リクエストのトラッキング

- 7.2 自己登録に対する自動承認の構成

8 プロファイルの管理

- 8.1 プロファイル属性の管理

- 8.2 ロール割当ての管理

- 8.2.1 ロールのリクエスト

- 8.2.2 ロールの削除

- 8.3 リソース・プロファイルの管理

- 8.3.1 リソースのリクエスト

- 8.3.2 リソースの変更

- 8.3.3 リソースの詳細の表示

- 8.4 プロキシの管理

- 8.4.1 プロキシの追加

- 8.4.2 プロキシの編集

- 8.4.3 プロキシの削除

- 8.5 セキュリティの管理

- 8.5.1 パスワードの変更

- 8.5.2 チャレンジ質問および回答の設定

- 8.5.2.1 チャレンジ質問および回答のローカライズ

- 8.6 忘れたパスワードのリセット

9 タスクの管理

- 9.1 承認タスクの管理

- 9.1.1 承認タスクの検索

- 9.1.2 タスクの詳細の表示

- 9.1.3 タスクの要求

- 9.1.4 タスクの承認

- 9.1.5 タスクの却下

- 9.1.6 タスクの再割当て

- 9.1.7 詳細情報のリクエスト

- 9.1.8 情報の送信

- 9.2 プロビジョニング・タスクの管理

- 9.2.1 プロビジョニング・タスクの検索

- 9.2.2 プロビジョニング・タスクの詳細の表示

- 9.2.3 タスクに対するレスポンスの設定

- 9.2.4 タスクへのメモの追加

- 9.2.5 タスクの再割当て

- 9.2.6 タスク割当て履歴の表示

- 9.2.7 フォームの詳細の表

- 9.2.8 フォームの詳細の変更

- 9.2.9 タスクの再試行

- 9.3 アテステーション・タスクの管理

- 9.3.1 アテステーション・タスクの検索

- 9.3.2 アテステーション・リクエスト詳細の表示

10 リクエストの管理

- 10.1 リクエストのステージ

- 10.2 バルク・リクエストと子リクエスト

- 10.3 リクエスト・モデル

- 10.4 自分および他のユーザーのためのリクエストの作成

- 10.4.1 Oracle Identity Managerでの自身を登録するリクエストの作成

- 10.4.2 Oracle Identity Managerセルフサービスからのリクエストの作成

- 10.4.2.1 Oracle Identity Managerセルフサービスの「ようこそ」ページからのリクエストの作成

- 10.4.2.2 「マイ・リクエスト」ページからのリクエストの作成

- 10.4.2.3 「マイ・プロファイル」ページからのリクエストの作成

- 10.5 リクエストの検索

- 10.5.1 リクエスタとしてのリクエスト検索

- 10.5.1.1 リクエストされたロール/リクエストされたリソース/ユーザー

- 10.5.1.2 リクエストのコメント

- 10.5.1.3 リクエスト履歴

- 10.5.1.4 承認タスク

- 10.5.1.5 子リクエスト

- 10.5.2 受益者としてのリクエスト検索

- 10.5.3 承認者別のリクエストの検索

- 10.5.4 認証されていないユーザー別のリクエストの検索

- 10.6 リクエストの取消し

- 10.7 タスク・リストを使用したリクエスト関連タスクの実行

- 10.8 リクエストのクローズ

第III部 アイデンティティ管理

11 ユーザーの管理

- 11.1 ユーザー・ライフサイクル

- 11.1.1 OIMアカウント

- 11.1.2 組織

- 11.1.3 ロール

- 11.2 ユーザー・エンティティ定義

- 11.3 ユーザー管理タスク

- 11.3.1 ユーザーの検索

- 11.3.1.1 単純検索

- 11.3.1.2 拡張検索

- 11.3.2 ユーザーの作成

- 11.3.3 ユーザー情報の表示と変更

- 11.3.3.1 「ユーザーの詳細」ページ

- 11.3.3.2 ユーザー変更

- 11.3.3.3 単一ユーザー操作

- 11.3.3.4 バルク・ユーザー変更

- 11.4 ユーザー管理の認可

- 11.4.1 権限

- 11.4.2 属性

- 11.4.3 データ制約

- 11.4.4 複数のポリシーを使用する認可

- 11.4.4.1 複数の認可ポリシーを使用する検索操作の認可

- 11.4.4.2 複数の認可ポリシーを使用する変更操作の認可

- 11.5 ユーザー名の予約

- 11.5.1 ユーザー名の予約の有効化と無効化

- 11.5.2 ユーザー名ポリシーの構成

- 11.5.3 ユーザー名の解放

- 11.5.4 Microsoft Active Directoryサポートのためのユーザー名生成の構成

- 11.6 共通名の生成

- 11.6.1 ユーザー作成操作での共通名の生成

- 11.6.2 ユーザー変更操作での共通名の生成

12 ロールの管理

- 12.1 ロール・メンバーシップの継承

- 12.2 ロール権限の継承

- 12.3 ロール・エンティティ定義

- 12.3.1 ロール・エンティティ

- 12.3.2 ロール・カテゴリ・エンティティ

- 12.3.3 ロール付与関係

- 12.3.4 ロール親関係

- 12.4 デフォルト・ロール

- 12.5 ロール管理タスク

- 12.5.1 ロールの作成

- 12.5.2 ロールの管理

- 12.5.2.1 ロールの参照

- 12.5.2.2 ロールの検索

- 12.5.2.3 ロールの削除

- 12.5.2.4 ロールの表示と管理

- 12.5.2.5 メニュー項目の表示

- 12.5.2.6 アクセス・ポリシーの表示、割当ておよび失効

- 12.5.2.7 メンバーシップ・ルールの表示、割当ておよび失効

- 12.5.2.8 データ・オブジェクト権限の更新

- 12.5.3 ロール・カテゴリの作成と管理

- 12.5.3.1 ロール・カテゴリの作成

- 12.5.3.2 ロール・カテゴリの検索

- 12.5.3.3 ロール・カテゴリの変更

- 12.5.3.4 ロール・カテゴリの削除

- 12.6 ロールに対する認可の管理

- 12.7 リクエスト・ベースのロールの付与

13 組織の管理

- 13.1 組織エンティティ定義

- 13.2 組織管理タスク

- 13.2.1 組織の検索

- 13.2.1.1 単純検索の実行

- 13.2.1.2 拡張検索の実行

- 13.2.2 組織の参照

- 13.2.3 組織の作成

- 13.2.4 組織の表示と変更

- 13.2.4.1 組織の属性の変更

- 13.2.4.2 子組織の表示

- 13.2.4.3 ユーザー情報の表示

- 13.2.4.4 リソースの変更

- 13.2.5 組織の有効化と無効化

- 13.2.6 管理ロールの管理

- 13.2.7 許可されたリソースの管理

- 13.2.8 組織の削除

- 13.3 組織管理の認可

14 リクエストの作成と検索

- 14.1 Oracle Identity Manager拡張管理を使用したリクエストの作成

- 14.1.1 ユーザーを作成するリクエストの作成

- 14.1.2 ユーザーにリソースをプロビジョニングするリクエストの作成

- 14.1.3 リソースをプロビジョニング解除するリクエストの作成

- 14.2 リクエストの検索とトラッキング

- 14.2.1 リクエストの検索

- 14.2.2 リクエスト詳細の表示

- 14.2.2.1 「リクエストされたリソース」または「ユーザー」または「リクエストされたロール」タブ

- 14.2.2.2 「リクエストのコメント」タブ

- 14.2.2.3 「リクエスト履歴」タブ

- 14.2.2.4 「承認タスク」タブ

- 14.2.2.5 「子リクエスト」タブ

第IV部 ポリシー管理

15 認可ポリシーの管理

- 15.1 認可ポリシー

- 15.2 認可ポリシーの作成および管理

- 15.2.1 認可ポリシーの検索

- 15.2.1.1 単純検索

- 15.2.1.2 拡張検索

- 15.2.2 カスタム認可ポリシーの作成

- 15.2.2.1 ユーザー管理に対する認可ポリシーの作成

- 15.2.2.2 ロール管理に対する認可ポリシーの作成

- 15.2.2.3 認証済ユーザー・セルフサービスに対する認可ポリシーの作成

- 15.2.3 既存のポリシーに基づいた認可ポリシーの作成

- 15.2.4 認可ポリシーの表示と変更

- 15.2.5 認可ポリシーの削除

- 15.3 Oracle Identity Manager機能に対する認可ポリシー

- 15.3.1 ユーザー管理

- 15.3.1.1 割当て先

- 15.3.1.2 機能セキュリティ

- 15.3.1.3 データ・セキュリティ

- 15.3.1.4 デフォルト認可ポリシー

- 15.3.2 認証済ユーザー・セルフサービス

- 15.3.2.1 プロファイル属性に対する認可

- 15.3.2.2 ロール・リクエストに対する認可

- 15.3.2.3 リソース・リクエストに対する認可

- 15.3.2.4 プロキシに対する認可

- 15.3.2.5 デフォルト認可ポリシー

- 15.3.3 ロール管理

- 15.3.3.1 割当て先

- 15.3.3.2 機能セキュリティ

- 15.3.3.3 データ・セキュリティ

- 15.3.3.4 デフォルト認可ポリシー

- 15.3.4 認可ポリシー管理

- 15.3.5 ユーザー管理構成

- 15.3.6 リコンシリエーション管理

- 15.3.6.1 割当て先

- 15.3.6.2 機能セキュリティ

- 15.3.6.3 データ・セキュリティ

- 15.3.6.4 デフォルト認可ポリシー

- 15.3.7 スケジューラ

- 15.3.8 リクエスト・テンプレート管理

- 15.3.9 リクエスト・テンプレートを使用したリクエスト作成

- 15.3.10 承認ポリシー管理

- 15.3.11 通知管理

- 15.3.12 システム・プロパティ

- 15.3.13 診断ダッシュボード

- 15.3.14 プラグイン

16 アクセス・ポリシーの管理

- 16.1 アクセス・ポリシーで使用される用語

- 16.2 アクセス・ポリシーの機能

- 16.2.1 プロビジョニング・オプション

- 16.2.2 ポリシーの失効

- 16.2.3 リソースの拒否

- 16.2.4 ポリシーの評価

- 16.2.5 アクセス・ポリシーの優先度

- 16.2.6 アクセス・ポリシー・データ

- 16.2.7 アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

- 16.3 アクセス・ポリシーの作成

- 16.4 アクセス・ポリシーの管理

- 16.5 アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

- 16.5.1 単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成

- 16.5.2 複数アカウント・プロビジョニングの有効化

- 16.5.3 複数ターゲット・システムへのリソースの複数インスタンスのプロビジョニング

- 16.5.4 アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングの制限

17 リクエスト・テンプレートの管理

- 17.1 リクエスト・テンプレートの作成

- 17.1.1 「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

- 17.1.2 「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

- 17.2 リクエスト・テンプレートの検索と変更

- 17.2.1 「許可されているリソース」または「許可されているロール」

- 17.2.2 属性制限

- 17.2.3 追加属性

- 17.2.4 テンプレート・ユーザー・ロール

- 17.3 テンプレートのクローニング

- 17.4 テンプレートの削除

18 承認ポリシーの管理

- 18.1 承認の選択方法

- 18.1.1 リクエスト・レベルの方法

- 18.1.2 操作レベルの方法: 組織ベースの選択

- 18.1.3 操作レベルの方法: リソース・ベースの選択

- 18.1.4 操作レベルの方法: ロール・ベースの選択

- 18.2 承認ポリシーの作成

- 18.3 承認ポリシーの検索

- 18.4 承認ポリシーの変更

- 18.5 承認ポリシーの優先度の変更

- 18.6 承認ポリシーの削除

19 アテステーション・プロセスの管理

- 19.1 アテステーションについて

- 19.1.1 アテステーション・プロセスの定義

- 19.1.1.1 アテステーション・プロセスの制御

- 19.1.2 アテステーション・タスクのコンポーネント

- 19.1.2.1 アテステーション受信ボックス

- 19.1.3 アテステーション・リクエスト

- 19.1.4 委任

- 19.1.5 アテステーション・ライフサイクル・プロセス

- 19.1.5.1 第1段階: アテステーション・タスクの作成

- 19.1.5.2 第2段階: アテステーション・タスクに関する作業

- 19.1.5.3 第3段階: 送信されたアテステーション・タスクの処理

- 19.1.6 アテステーション・エンジン

- 19.1.7 アテステーション・スケジュール済タスク

- 19.1.8 アテステーションドリブンのワークフロー機能

- 19.1.9 アテステーションの電子メール

- 19.1.9.1 アテステーション・レビューアへの通知

- 19.1.9.2 委任されたレビューアへの通知

- 19.1.9.3 拒否されたアテステーション権限についてのプロセス所有者への通知

- 19.1.9.4 電子メールが定義されていないレビューアについてのプロセス所有者への通知

- 19.2 アテステーション・プロセスの設定

- 19.2.1 メニュー構造

- 19.2.2 システム制御

- 19.3 アテステーション・プロセスの作成

- 19.4 アテステーション・プロセスの管理

- 19.4.1 アテステーション・プロセスの編集

- 19.4.2 アテステーション・プロセスの無効化

- 19.4.3 アテステーション・プロセスの有効化

- 19.4.4 アテステーション・プロセスの削除

- 19.4.5 アテステーション・プロセスの実行

- 19.4.6 アテステーション・プロセス管理者の管理

- 19.4.7 アテステーション・プロセス実行履歴の表示

- 19.5 アテステーション・ダッシュボードの使用

- 19.5.1 アテステーション・リクエスト詳細の表示

- 19.5.2 電子メール通知

- 19.5.3 アテステーション猶予期間チェッカー・スケジュール済タスク

第V部 レポート

20 レポート機能の使用

- 20.1 レポート機能

- 20.2 Oracle Identity Managerレポートの開始

- 20.3 Oracle Identity Managerレポートの実行

- 20.4 サポートされている出力形式

- 20.5 Oracle Identity Managerのレポート

- 20.5.1 アクセス・ポリシー・レポート

- 20.5.1.1 アクセス・ポリシー詳細

- 20.5.1.2 ロール別のアクセス・ポリシー・リスト

- 20.5.2 アテステーション、リクエストおよび承認レポート

- 20.5.2.1 承認アクティビティ

- 20.5.2.2 アテステーション・プロセス・リスト

- 20.5.2.3 アテステーション・リクエストの詳細

- 20.5.2.4 プロセス別のアテステーション・リクエスト

- 20.5.2.5 レビューア別のアテステーション・リクエスト

- 20.5.2.6 リクエストの詳細

- 20.5.2.7 リクエスト・サマリー

- 20.5.2.8 タスク割当て履歴

- 20.5.3 ロールおよび組織レポート

- 20.5.3.1 ロール・メンバーシップ履歴

- 20.5.3.2 ロール・メンバーシップ・プロファイル

- 20.5.3.3 ロール・メンバーシップ

- 20.5.3.4 組織の詳細

- 20.5.3.5 ユーザー・メンバーシップ履歴

- 20.5.4 パスワード・レポート

- 20.5.4.1 パスワード有効期限サマリー

- 20.5.4.2 パスワード・リセット・サマリー

- 20.5.4.3 リソース・パスワード有効期限

- 20.5.5 リソースおよび権限レポート

- 20.5.5.1 リソースのアカウント・アクティビティ

- 20.5.5.2 リソース別の委任管理者および権限

- 20.5.5.3 リソース別の委任管理者

- 20.5.5.4 権限アクセス・リスト

- 20.5.5.5 権限アクセス・リスト履歴

- 20.5.5.6 財務的に重要なリソースの詳細

- 20.5.5.7 リソース別のファイングレイン権限例外

- 20.5.5.8 オフライン・リソース・プロビジョニング・メッセージ

- 20.5.5.9 孤立アカウント・サマリー

- 20.5.5.10 リソース・アクセス・リスト履歴

- 20.5.5.11 リソース・アクセス・リスト

- 20.5.5.12 リソース・アカウント・サマリー

- 20.5.5.13 リソース・アクティビティ・サマリー

- 20.5.5.14 リソース別の統制外アカウント

- 20.5.5.15 ユーザー・リソース・アクセス履歴

- 20.5.5.16 ユーザー・リソース・アクセス

- 20.5.5.17 ユーザー・リソース権限

- 20.5.5.18 ユーザー・リソース権限履歴

- 20.5.6 ユーザー・レポート

- 20.5.6.1 ユーザー・プロファイル履歴

- 20.5.6.2 ユーザー・サマリー

- 20.5.6.3 削除済ユーザー

- 20.5.6.4 無効化されたユーザー

- 20.5.6.5 ロック解除済ユーザー

- 20.6 例外レポート

- 20.7 サード・パーティ製ソフトウェアを使用したレポートの作成

- 20.8 BI Publisherレポートの必須のスケジュール済タスク

索引

図一覧

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

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

- 2-3 リモート・マネージャのアーキテクチャ

- 2-4 OESベースの認可サービス

- 2-5 Oracle Identity Managerスケジューラのアーキテクチャ

- 2-6 Oracle Identity Managerのシステム・コンポーネント

- 4-1 プロビジョニング構成

- 4-2 プロビジョニングおよびリコンシリエーション

- 4-3 単一および複数の認証ソースからの信頼できるソース・リコンシリエーション

- 4-4 ターゲット・システムからのアカウント・リコンシリエーション

- 4-5 アイデンティティ・リコンシリエーションとアカウント・リコンシリエーション

- 4-6 リコンシリエーション・プロセス・フロー

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

- 4-8 Oracle Identity ManagerとLDAP

- 5-1 Oracle Identity Managerの3段階の統合ソリューション方式

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

- 6-1 監査プロセスの設計要素

- 9-1 RFIタスク

- 9-2 RFIタスクの使用可能オプション

- 9-3 RFIのタスク詳細

- 9-4 「タスクへの注意の追加」ウィンドウ

- 9-5 「タスクの割当先ユーザーの選択」ウィンドウ

- 9-6 「タスクの履歴」ウィンドウ

- 9-7 「アテステーション・リクエストの詳細」ウィンドウ

- 10-1 リクエスト・プロセス・フロー

- 10-2 リクエストのステージ

- 10-3 バルク・リクエストと子リクエストのステージ

- 10-4 「リクエストの詳細」タブ

- 10-5 「リクエストされたロール」タブ

- 10-6 「ユーザー」タブ

- 10-7 「ユーザーの詳細」ウィンドウ

- 10-8 「リクエスト履歴」タブ

- 10-9 自分のために要求されたリクエスト

- 11-1 ユーザー・ライフサイクル

- 11-2 単純検索結果

- 11-3 非表示の列がある拡張検索結果

- 11-4 拡張検索結果

- 11-5 サンプル・プロセス・データ

- 11-6 「パスワードのリセット」ダイアログ・ボックス

- 11-7 「システム・プロパティ詳細」ページ

- 11-8 デフォルト・ユーザー名ポリシーの構成

- 12-1 ロール・メンバーシップおよびロール権限の継承

- 13-1 再帰的な組織メンバーシップ

- 13-2 組織の検索結果

- 13-3 拡張検索

- 13-4 組織の参照リスト

- 13-5 「組織の作成」ページ

- 13-6 「検索: 組織」ダイアログ・ボックス

- 13-7 「組織の詳細」ページ

- 13-8 管理ロールの割当て

- 13-9 許可されたリソースの割当て

- 14-1 拡張検索の結果

- 14-2 「リクエストされたロール」タブ

- 14-3 「リソースの詳細」ウィンドウ

- 14-4 「リクエストのコメント」タブ

- 14-5 「リクエスト履歴」タブ

- 14-6 「承認タスク」タブ

- 15-1 認可ポリシーの単純検索

- 15-2 認可ポリシーの拡張検索

- 15-3 「基本ポリシー情報」ページ

- 15-4 「権限」ページ

- 15-5 「データの制約」ページ

- 15-6 「ポリシー割当て」ページ

- 17-1 「リクエスト・テンプレートの詳細の設定」ページ

- 17-2 「制限する属性の選択」ページ

- 17-3 「属性制限の設定」ページ

- 17-4 「追加属性の設定」ページ

- 17-5 「テンプレート・ユーザー・ロールの設定」ページ

- 17-6 「リクエスト・テンプレート・サマリーの確認」ページ

- 17-7 リクエスト・テンプレートの拡張検索結果

- 17-8 「許可されているリソース」タブ

- 17-9 「属性制限」タブ

- 17-10 「追加属性」タブ

- 17-11 「テンプレート・ユーザー・ロール」タブ

- 18-1 承認ポリシーの検索結果

- 18-2 承認ポリシーの拡張検索

- 19-1 アテステーションの委任

- 19-2 アテステーション・タスクの作成: ワークフロー

- 19-3 レビューアが権限に対するレスポンスを送信する場合のイベントのフロー

- 19-4 アテステーション・タスクのレスポンス送信後のイベント・フロー

- 19-5 フォローアップ・アクション・サブフロー

表一覧

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

- 4-2 標準リコンシリエーション・モードと変更ログ・リコンシリエーション・モード

- 4-3 リコンシリエーションのステータス・イベント

- 4-4 アクション・ルール

- 5-1 コネクタ・コンポーネント

- 5-2 プロビジョニング・プロセス・タスク

- 5-3 リコンシリエーション関連プロビジョニング・プロセス・タスク

- 6-1 ユーザー・グループ・メンバーシップの表

- 6-2 ユーザー・リソース・インスタンスの表

- 6-3 リソース・ライフサイクル・プロセスの表

- 6-4 UPA表の定義

- 6-5 ユーザー・プロファイル監査の表

- 6-6 GPA表の定義

- 8-1 プロファイル管理権限

- 9-1 完全タスクリスト・ビュー表の列

- 9-2 プロビジョニング・タスク検索結果表のフィールド

- 9-3 「タスクの詳細」ウィンドウのフィールド

- 9-4 「タスクの履歴」ウィンドウのフィールド

- 9-5 アテステーション・タスク検索結果表のフィールド

- 9-6 「アテステーション・リクエストの詳細」ウィンドウのフィールド

- 10-1 リクエストのステージ

- 10-2 デフォルトの操作およびリクエスト・モデル

- 10-3 リクエスト情報を表示する表の列

- 11-1 ユーザー・ライフサイクルとビジネス目的のサンプル・シナリオ

- 11-2 ユーザー・エンティティに対して定義されている属性

- 11-3 拡張検索のコンパレータ

- 11-4 デフォルトの検索属性

- 11-5 「ユーザーの作成」ページのフィールド

- 11-6 「バルク変更」ページのフィールド

- 11-7 ユーザー管理の認可権限

- 11-8 事前定義済のユーザー名ポリシー

- 11-9 ポリシーIDを表す定数

- 11-10 RDN変更のシナリオ

- 12-1 ロール・エンティティのデフォルト属性

- 12-2 ロール・カテゴリ・エンティティのデフォルト属性

- 12-3 ロール付与関係のデフォルト属性

- 12-4 ロール親関係のデフォルト属性

- 12-5 Oracle Identity Managerのデフォルト・ロール

- 12-6 「ロールの作成」ページのフィールド

- 12-7 明示的な挿入/更新/削除権限が必要なデータ・オブジェクト

- 12-8 ロール管理の権限

- 13-1 組織エンティティのデフォルト属性

- 13-2 「組織の作成」ページのフィールド

- 14-1 「リクエストの詳細」ページのフィールド

- 17-1 デフォルトのリクエスト・テンプレート

- 17-2 「テンプレートの詳細」セクションのフィールド

- 20-1 BI Publisherレポートのスケジュール済タスク

Oracle® Fusion Middleware

Oracle Identity Managerユーザーズ・ガイド

11g リリース1(11.1.1)

B66706-01(原本部品番号:E14316-08)

2011年12月

Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド, 11g リリース1 (11.1.1)

B66706-01

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

原本著者:  Debapriya Datta

原本協力著者:  Prakash Hulikere

原本協力者:  Sid Choudhury

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

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

はじめに

『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』では、Oracle Identity Managerセルフサービス・タスクおよび委任管理機能について説明します。

対象読者

このガイドは、Oracle Identity ManagerにログインしてOracle Identity Managerセルフサービス操作を実行し、ロールやリソースをリクエストしたり、承認、プロビジョニングおよびアテステーションに関する様々なタスクを管理できるユーザーを対象としています。また、アイデンティティ管理タスクを実行したり、管理権限を委任するための認可ポリシーを定義できる委任管理者も対象としています。さらに、任意のロールが指定されたユーザーは、Oracle Identity Managerの概要と概念を理解するためにこのガイドを参照できます。

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

オラクル社のアクセシビリティへの取組みの詳細は、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 Identity Managementのドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Fusion Middleware Oracle Identity Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Manager開発者ガイド

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

- Oracle Identity ManagementのOracle Fusion Middlewareクイック・インストレーション・ガイド

- 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を紹介し、Oracle Identity Managerに関連する概念について説明します。

次の章で構成されます。

- 第1章「機能の概要」

- 第2章「アーキテクチャ」

- 第3章「ユーザー・インタフェース」

- 第4章「デプロイメント構成」

- 第5章「統合ソリューション」

- 第6章「監査」

1 機能の概要

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。

ユーザー・アイデンティティのプロビジョニングを自動化すると、情報テクノロジ(IT)の管理コストを削減し、セキュリティを高めることができます。プロビジョニングは、法規制コンプライアンスにおいても重要な役割を果たします。Oracle Identity Managerの主要機能には、パスワード管理、ワークフローとポリシーの管理、アイデンティティ・リコンシリエーション、レポートと監査、拡張性などがあります。

1.1 Oracle Identity Managerの機能

Oracle Identity Managerの機能は、次のカテゴリに分類できます。

- ユーザー管理

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

- パスワード管理

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

- 統合ソリューション

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

- 組織およびロール管理

1.1.1 ユーザー管理

セルフサービス機能のデプロイおよび管理機能の委任により、企業はユーザーの生産性、ユーザー満足度、および業務効率を向上させることができます。

Oracle Identity Managerのセルフサービスによるプロファイル管理

ユーザーは、Oracle Identity Managerのセルフサービス・インタフェースを使用して、自分のプロファイルの表示や編集ができます。これにより、管理オーバーヘッドが軽減され、ユーザーが自分のアイデンティティ・プロファイルを管理できるようになります。

管理プロファイルの管理

Oracle Identity Manager管理のユーザー・インタフェースを使用すると、アクセス権限に従って他のユーザーのプロファイルを表示および管理できます。ユーザー・プロファイルの作成と編集、ユーザーのパスワードの変更、委任された他の管理タスクを実行できます。

リクエスト管理

セルフサービス・インタフェースにより、ユーザーはきめ細かな権限、プロファイル管理リクエストおよびロール・メンバーシップ・リクエストを使用して、リソースに対するプロビジョニング・リクエストを作成することもできます。業務の承認者(チーム・リーダー、ライン管理者および部長など)は、同じWebベースのインタフェースを使用して着信リクエストを検討し、承認できます。これにより、企業は労力とコストを削減できます。

委任管理

Oracle Identity Managerは、任意のグループまたはユーザーへのほとんどの管理機能の委任をサポートする、柔軟性に富んだセキュリティ・フレームワークを特長としています。管理ポイントをできるかぎりユーザーに近づけることにより、企業は生産性を高めながら、緊密な管理とセキュリティの強化を実現できます。

1.1.2 ワークフローおよびポリシー

ビジネス・プロセスおよび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.3 パスワード管理

現在、パスワード管理は企業にとって最も重要な問題の1つです。パスワード管理ソリューションを実装すると、チケットの生成やヘルプ・デスクへのコールに関連するコストおよびオーバーヘッドが削減されます。この項で説明するOracle Identity Managerのパスワード管理機能は、この分野で企業を支援することを目的としています。

セルフサービスのパスワード管理

ユーザーは、自分のエンタープライズ・パスワードを管理し、個々の管理アカウントの構成方法に従って管理アカウントとパスワードを同期化できます。エンタープライズ・パスワードは、Oracle Identity Managerのセルフサービス機能を使用して管理されます。ユーザーがパスワードを忘れた場合、Oracle Identity Managerでは、カスタマイズ可能なチャレンジ質問を表示して、セルフサービスのアイデンティティ検証とパスワードのリセットを可能にします。調査によると、ヘルプ・デスクへのコールの大部分はパスワードのリセットとアカウントのロックアウトに関連する内容です。このセルフサービス機能により、必要なヘルプデスクへのコールが減少し、コストが削減されます。

高度なパスワード・ポリシー管理

ほとんどのベスト・プラクティスが購入後すぐに使用でき、直感的に操作できるユーザー・インタフェースを使用して構成できます。サポートされるパスワードの複雑性の要件には、パスワードの長さ、英数字および特殊文字の使用、大/小文字の使用、ユーザー名の全部または一部除外、パスワードの最小期間、および履歴パスワードが含まれます。Oracle Identity Managerでは、ユーザーによるパスワードの設定を制御する複雑なパスワード・ポリシーを定義できます。さらに、リソースごとに複数のポリシーを適用できます。たとえば、権限のレベルが低いユーザーを制約の緩いパスワード・ポリシーの対象とする一方で、権限を持つ管理者を制約の厳しいポリシーの対象とすることができます。

パスワードの同期化

Oracle Identity Managerでは、管理リソース全体でパスワードを同期化またはマップして、これらのリソース間でパスワード・ポリシーの相違を強制できます。さらに、企業がMicrosoft Windowsのデスクトップベースのパスワード・リセット機能を使用している場合は、Oracle Identity ManagerのActive Directory(AD)コネクタがADサーバーでパスワード変更を捕捉し、ポリシーに従って他の管理リソースにその変更を伝播できます。ディレクトリ・サーバーとメインフレーム用のほとんどのOracle Identity Managerコネクタには、同様の双方向パスワード同期化機能が装備されています。

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

アイデンティティ管理は、企業の監査およびコンプライアンス・ソリューションにおける重要な要素となります。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のワークフロー・エンジンを構成することにより、レビューアのアクションから修正措置をトリガーすることも可能です。

1.1.5 統合ソリューション

スケーラブルで柔軟な統合アーキテクチャは、企業のプロビジョニング・ソリューションのデプロイを成功させるうえで非常に重要です。Oracle Identity Managerでは、実績がある統合アーキテクチャおよび事前定義済コネクタを提供し、迅速で低コストのデプロイを実現します。

アダプタ・ファクトリ

プロビジョニング・システムと管理リソースとの統合は、簡単ではありません。独自システムとの接続は、困難な場合があります。アダプタ・ファクトリにより、このような接続の作成や管理が簡単になります。Oracle Identity Managerに用意されているアダプタ・ファクトリは、コード生成ツールで、Javaクラスを作成できます。

アダプタ・ファクトリは、商用システムやカスタム・システムとの迅速な統合を実現します。ユーザーは、アダプタ・ファクトリのグラフィカル・ユーザー・インタフェースを使用し、プログラムやスクリプトを作成することなく、統合を作成または変更できます。コネクタが作成されると、その定義はOracle Identity Managerリポジトリで管理され、自己文書化ビューが作成されます。これらのビューを使用して、コネクタの拡張、メンテナンスおよびアップグレードを実行します。

事前定義済コネクタ

Oracle Identity Managerには、広く使用されている商用アプリケーションと他のアイデンティティ認識システムのための、事前定義済コネクタの豊富なライブラリがあります。これらのコネクタを使用することで、企業はアプリケーション統合において有利なスタートを切ることができます。各コネクタでは、多種多様なアイデンティティ管理機能をサポートします。これらのコネクタは、独自のものであろうと、オープン・スタンダードに基づいたものであろうと、ターゲット・リソースに対して推奨される最適な統合テクノロジを使用します。これらのコネクタにより、一連の異種ターゲット・システムとOracle Identity Managerの間ではデフォルト設定のままの統合が可能です。これらのコネクタには、もともとアダプタ・ファクトリを使用して開発されたコンポーネント・セットが用意されているため、アダプタ・ファクトリを使用してさらに変更し、各企業固有の統合要件を実現できます。

汎用テクノロジ・コネクタ

カスタム・コネクタの作成にアダプタ・ファクトリのカスタマイズ機能が不要な場合は、Oracle Identity Managerの汎用テクノロジ・コネクタ(GTC)機能を使用してコネクタを作成できます。GTCの詳細は、「汎用テクノロジ・コネクタ」を参照してください。

関連項目:

汎用テクノロジ・コネクタの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

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

プロビジョニングでは、Oracle Identity Managerからターゲット・システムへのユーザー情報の外部へのフローが提供されます。プロビジョニングは、リソースのユーザー情報を作成、変更または削除するためのアクションをOracle Identity Managerで開始し、リソースに渡すプロセスです。プロビジョニング・システムはリソースと通信し、アカウントに適用する変更を指定します。

プロビジョニングには、次のことが含まれます。

- ユーザー・アイデンティティおよびユーザー・アカウントのプロビジョニングの自動化: 複数のシステムやアプリケーションにわたってユーザー・アイデンティティとユーザー・アカウントを管理します。たとえば、給与処理部門に勤務する従業員が人事管理システムで作成されると、このユーザーのアカウントが、電子メール・システム、電話システム、会計システムおよび給与レポート・システムにも自動的に作成されます。

- ワークフローおよびポリシー管理: これにより、アイデンティティのプロビジョニングが可能になります。管理者は、プロビジョニング・ツールに用意されているインタフェースを使用し、セキュリティ・ポリシーに基づいてプロビジョニング・プロセスを作成できます。

- レポートおよび監査: プロビジョニング・プロセスとその実施に関するドキュメントを作成できます。このドキュメントは、監査、法規制およびコンプライアンスのために不可欠なものです。

- アテステーション: これにより、管理者はユーザーのアクセス権を定期的に確認できます。

- アクセス権のプロビジョニング解除: 企業内でユーザーのアクセス権が不要または無効になった場合、Oracle Identity Managerでは、ロール・ベースまたは属性ベースのアクセス・ポリシーに従い、必要に応じて、または自動的にアクセス権を失効します。つまり、ユーザーのアクセス権は、不要になると即座に停止されます。これにより、セキュリティ・リスクを最小限に抑えるとともに、データ・サービスなど、消費コストの高いリソースに対する無駄なアクセスを防ぐことができます。

1.1.7 組織およびロール管理

組織エンティティは、Oracle Identity Managerの他のエンティティ(ユーザー、ロール、ポリシーなど)の論理的なコンテナを示します。つまり、組織は委任管理モデルに使用できるコンテナです。さらに、Oracle Identity Managerの他のエンティティ(ユーザーなど)のスコープも定義します。Oracle Identity Managerでは、フラットな組織構造または階層的な構造(組織に他の組織を含めることができることを意味する)をサポートしています。階層は、エンティティの管理を容易にするために、部門、地理的な地域または他の論理的な区分を表現できます。

ロールは、Oracle Identity Manager内でアクセス権を割り当てたり、リソースを自動的にプロビジョニングしたり、承認やアテステーションなどの共通のタスクで使用できるユーザーの論理的なグループです。ロールは、組織に依存しないロール、複数の組織にわたるロール、または1つの組織のユーザーのみを含むロールのいずれかです。

2 アーキテクチャ

Oracle Identity Managerのアーキテクチャには、アイデンティティおよびアクセス管理アーキテクチャの一部としてプロビジョニング・ソリューションをデプロイするための様々な優れた技術上の利点があります。

Oracle Identity Managerプラットフォームでは、アクセス権の管理、セキュリティおよびITリソースのプロビジョニングが自動化されています。Oracle Identity Managerはユーザーをリソースに接続し、機密性の高い企業情報を保護するために不正アクセスを失効および制限します。

この章の項目は次のとおりです。

- 主な特長と利点

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

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

2.1 主な特長と利点

Oracle Identity Managerのアーキテクチャは柔軟でスケーラブルであり、次の特長があります。

- デプロイの容易性

- 柔軟性と耐性

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

- 広範なユーザー管理

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

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

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

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

- 組込みの変更管理

2.1.1 デプロイの容易性

Oracle Identity Managerは柔軟なデプロイメント・マネージャ・ユーティリティを備え、複数の環境間での統合および構成情報の移行を支援します。このユーティリティは、統合および構成情報をXMLファイルとしてエクスポートします。これらのファイルは、その後、宛先の環境(ステージング環境や本番環境)にインポートされます。XMLファイルは、構成のアーカイブやバージョン管理、統合のレプリケートに使用できます。

デプロイメント・マネージャにより、インポートおよびエクスポートの対象を柔軟に選択できます。また、インポートとエクスポートのどちらの手順でも、データ・オブジェクトの依存関係を簡単に確認できます。このような柔軟性により、複数のユーザーによって行われた統合作業のマージが可能になり、移行の整合性が保証されます。

2.1.2 柔軟性と耐性

Oracle Identity Managerは、単一のサーバー・インスタンスにも複数のサーバー・インスタンスにもデプロイできます。複数のサーバー・インスタンスは、柔軟性、パフォーマンス、制御の向上のために最適な構成オプションを提供し、地理的に分散したユーザーおよびリソースをサポートします。また、Java 2 Enterprise Edition(J2EE)アプリケーション・サーバー・モデルのOracle Identity Managerには、スケーラビリティ、フォルト・トレランス、冗長性、フェイルオーバーおよびシステム・ロード・バランシングも備わっています。デプロイが拡張するにつれて、単一サーバーから複数サーバーの実装への移行がシームレスに行われます。

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

コストを下げ、できるかぎり簡素化し、既存の投資を活用するために、Oracle Identity Managerはオープン・アーキテクチャ上に構築されています。そのため、企業のITインフラストラクチャにすでに実装されている既存のソフトウェアおよびミドルウェアにOracle Identity Managerを統合して活用できます。たとえば、既存の顧客ポータルとの統合が必要な実装の場合は、Oracle Identity Managerの高度なAPIにより、包括的なシステム機能セットへのプログラムによるアクセスが可能になります。そのため、IT担当者は、Oracle Identity Managerのプロビジョニング実装のどの部分でも企業固有のニーズに合せてカスタマイズできます。

2.1.4 広範なユーザー管理

Oracle Identity Managerでは、ユーザーの組織階層やロールを必要な数だけ定義できます。継承、カスタマイズ可能なユーザーIDポリシー管理、パスワード・ポリシー管理およびユーザー・アクセス・ポリシーをサポートし、顧客の変化するビジネス・ニーズを反映します。また、アプリケーション・パラメータおよび権限を管理し、リソース割当ての履歴を表示できます。さらに、ユーザー管理に関する包括的な権限設定が可能な委任管理も提供されます。

Oracle Identity Managerには、ユーザー管理を包括的に支援する、カスタマイズ可能なWebベースのOracle Identity Managerセルフサービスがあります。

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

Oracle Identity Managerには、カスタマイズ可能なWebベースのユーザー・セルフサービス・ポータルがあります。このポータルでは、ユーザー情報の管理、パスワードの変更と同期化、忘れたパスワードのリセット、選択可能なアプリケーションのリクエスト、選択可能な権限の確認と編集、およびワークフロー・タスクの開始と対処を操作できます。

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

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サーバー実装が用意されています。

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

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)に参加しています。

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

Oracle Identity Managerでは、使用しやすいアプリケーションでビジネスおよびプロビジョニングのプロセス・モデルを作成できます。プロセス・モデルには、承認ワークフローおよびエスカレーションのサポートが含まれます。イベントの現在のステータスやエラー・コードのサポートなど、各プロビジョニング・イベントの進行をトラッキングできます。Oracle Identity Managerでは、データ交換や依存関係を含む複雑な分岐のあるネストされたプロセスをサポートしています。プロセス・フローは完全にカスタマイズ可能で、プログラミングは不要です。

2.1.9 組込みの変更管理

Oracle Identity Managerでは、新規プロセスのパッケージ化、既存プロセスのインポートおよびエクスポート、システム間のパッケージの移動が可能です。

2.2 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 Oracle Identity Managerのアーキテクチャ」の説明

2.2.1 プレゼンテーション層

プレゼンテーション層は、Oracle Identity Manager管理およびユーザー・コンソールとOracle Identity Manager Design Consoleの2つのクライアントで構成されています。

Oracle Identity Manager管理およびユーザー・コンソールは、Webベースのシン・クライアントで、任意のWebブラウザからアクセスできます。このWebクライアントは、Oracle Identity Managerのほとんどのユーザーに役立つユーザー・セルフサービス機能および委任管理機能を提供します。

Oracle Identity Manager Design Consoleは、フォーム・デザイナ、ワークフロー・デザイナ、アダプタ・ファクトリなどのOracle Identity Managerの一連のシステム構成および開発機能を提供します。Oracle Identity Manager Design Consoleには、デスクトップJavaクライアントを使用してアクセスできます。

Oracle Identity Manager Design Consoleは、アプリケーション内でビジネス・サービス・レイヤーと直接通信するJava Swingクライアントとして実装されます。また、高度な委任管理モデルをサポートしているため、ユーザーは、権限を与えられたアプリケーション構成部分のみで作業できます。

関連項目:

Oracle Identity Manager管理およびユーザー・コンソール、Oracle Identity Manager Design Consoleの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドおよび『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

多くの企業には、カスタム開発したクライアントをサポートするプロビジョニング・システムに対する要件があります。そのいくつかの要件は、次のとおりです。

- 既存のエンタープライズ・ポータルへのクライアントの統合、およびエンタープライズ・ポータル標準の遵守

- ユーザー相互作用に対するカスタム・フローの作成

- 一意の要件に基づいてプロビジョニング・システムから構築されるカスタム・ページの作成

カスタマイズをサポートするために、Oracle Identity Managerでは、公開されたパブリックAPIを介して必要な機能の大部分を公開しています。Oracle Identity Managerのクライアント環境は、Java APIを介してカスタマイズできます。

2.2.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が提供するビジネス機能に不可欠なプラットフォーム・サービス(リクエスト管理サービス、エンティティ・マネージャ・サービス、スケジューラ・サービスなど)。

2.2.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.2.2.2 統合サービス

スケーラブルで柔軟な統合アーキテクチャは、企業のプロビジョニング・ソリューションのデプロイメントを成功させる上で非常に重要です。Oracle Identity Managerは、統合アーキテクチャを提供し、迅速で低コストのデプロイメントを実現します。

Oracle Identity Managerの統合サービスには、コネクタの開発、デプロイメントおよびメンテナンスのサポートに必要なすべてのコンポーネントが用意されています。統合サービスには、次のものがあります。

- コネクタ・フレームワーク

- アダプタ・ファクトリ

- 汎用テクノロジ・コネクタ

- リモート・マネージャ

関連項目:

アダプタ・ファクトリを使用したアダプタの定義方法の詳細は、「統合ソリューション」を参照してください。

2.2.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.2.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アーキテクチャ

「図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リファレンスを参照してください。

コネクタSPIの実装によるアイデンティティ・コネクタの開発の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のアイデンティティ・コネクタ・フレームワークに関する項を参照してください。

コネクタAPI

コネクタAPIは、実装された操作に関係なく、一貫したコネクタの表示を提供する機能を果たします。SPI開発者の利便性のために、複数の一般的な機能がデフォルトで用意されています。ほとんどの機能では、アプリケーション開発者によるAPIの処理は不要で、APIの構成のみが必要です。次に、API機能のリストを示します。

- すべてのコネクタが接続されるわけではないため、接続プーリングは必要なコネクタにのみ提供し、APIが接続プーリングを確認しなくて済むようにします。また、コネクタが接続プーリングを使用する場合は、接続の処理もエラー発生時の接続の破棄もAPI開発者の担当ではありません。

- すべての操作にタイムアウトを提供します。デフォルトをそのまま使用しない場合は、APIコンシューマが適切なタイムアウトを構成します。各SPI開発者は、一般的なサービスを実装する必要はありません(フレームワークに実装されているため)。

- 多種多様なフィルタを受け入れる単純なインタフェース手段として検索フィルタを提供します。コネクタ開発者に唯一必要な作業は、リソースが本来サポートしているフィルタを実装することです。それ以外はフレームワークで処理されます。

- 必要な場合に問合せや更新を大量に処理できるように、検索/同期バッファを提供します。実際はフレームワーク内で処理されるため、この点についてアプリケーションで考慮する必要はありません。

- コネクタに対して、GroovyおよびBooの.NETを介してスクリプトを提供します。これによって、フレームワークでは、コネクタとターゲット・リソースの両方でスクリプトを実行できるため(サポートされている場合)、コネクタ内で高い柔軟性が得られます。

- SPI開発者は、操作に対して異なる実装を選択できます。たとえば、2つのタイプの更新があるとします。アプリケーション開発者は、基本的に同じことを実行する2つの異なる操作をコールする必要がないため、これはAPIコンシューマには非表示にされます。かわりに、コネクタがサポートする操作はフレームワークで把握され、適切なコールが実行されます。

2.2.2.2.3 アダプタ・ファクトリ

アダプタ・ファクトリはOracle Identity Managerで提供されるコード生成ツールです。これによって、Oracle Identity Managerアプリケーション開発者は、Javaクラス(アダプタとも呼ばれる)を作成できます。

リソースには関連するプロビジョニング・プロセスがあり、そのプロセスには様々なタスクが関連付けられます。同様に、各タスクにはアダプタが関連付けられ、必要な操作を実行するためにターゲット・リソースに接続されます。

アダプタには次の利点があります。

- Oracle Identity Managerの内部ロジックと機能を拡張します。

- リソースのAPIを活用してそのリソースに接続することで、ソフトウェア・リソースとインタフェースします。

- Oracle Identity Managerと外部システム間の統合を可能にします。

- コードを手動で記述せずに生成できます。

- アダプタのすべての定義はリポジトリに保存されるため、簡単にメンテナンスできます。このリポジトリはGUIを使用して編集できます。

- Oracle Identity Managerでは、あるユーザーが統合に関するドメインの知識を保持し、別のユーザーがアダプタをメンテナンスできます。

- 変更および更新できます。

アダプタ・ファクトリは、商用システムやカスタム・システムとの迅速な統合を実現します。ユーザーは、アダプタ・ファクトリのグラフィカル・ユーザー・インタフェースを使用し、プログラムやスクリプトを作成することなく、統合を作成または変更できます。コネクタが作成されると、Oracle Identity Managerリポジトリではその定義が管理され、自己文書化ビューが作成されます。これらのビューを使用して、コネクタの拡張、メンテナンスおよびアップグレードを実行します。

関連項目:

アダプタ・ファクトリを使用したアダプタの定義方法は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

2.2.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では、コネクタ内に定義されているデータ・フローを表示する、Webベースのグラフィカルなウィザードが使用されます。コネクタのGTCビューを再ロードして、進行中のコネクタを同じグラフィカルな環境でメンテナンスできるように、コネクタに関する構成情報はすべてメタデータに保存されます。GTCでは、標準的なコネクタ・フレームワークを使用してコネクタが作成されるため、アプリケーション開発者は、標準のOracle Identity Manager開発環境にアクセスして、生成されたコネクタに変更を追加できます。ただし、この方法でGTCベースのコネクタをカスタマイズすると、そのコネクタは、GTCを使用して管理またはメンテナンスできなくなります。

関連項目:

GTCの機能アーキテクチャおよび機能の詳細は、「汎用テクノロジ・コネクタ」を参照してください。

2.2.2.2.5 リモート・マネージャ

アダプタでJavaタスクを使用する場合、適切なJava APIを検索するようにOracle Identity Managerを構成する必要があります。Java APIは、Meta Data Store (MDS)のJARファイルに格納されています。サード・パーティ・システムと直接通信せずに、プロキシのように動作するOracle Identity Managerコンポーネントを使用する必要がある場合があります。このコンポーネントは、リモート・マネージャと呼ばれます。リモート・マネージャは、次の目的で使用します。

- Oracle Identity Managerを通じた非リモートAPIの呼出し

- セキュアな接続でのSecure Sockets Layer (SSL)をサポートしないAPIの呼出し

リモート・マネージャは、ターゲット・システムのコンピュータで動作するOracle Identity Managerサーバーのコンポーネントです。ネットワーク対応のAPIがないアプリケーションやセキュリティを提供しないアプリケーションとの統合に必要なネットワークとセキュリティ・レイヤーを提供します。これは、軽量Remote Method Invocation (RMI)サーバーとして構築されます。通信プロトコルは、Hypertext Transfer Protocol/Secure (HTTP/S)経由でトンネリングされたRMIです。

J2EE RMIフレームワークにより、事実上透過的な分散サービスおよびアプリケーションが作成できるようになります。RMIベースのアプリケーションは、場所に関係なく、相互にメソッド・コールを実行するJavaオブジェクトで構成されます。これにより、Javaオブジェクトは、同じ仮想コンピュータにあるJavaオブジェクトでメソッドをコールするのと同じ方法で、別の仮想コンピュータにある別のJavaオブジェクトでメソッドをコールできます。

図2-3に、リモート・マネージャのアーキテクチャの概要を示します。

図2-3 リモート・マネージャのアーキテクチャ

「図2-3 リモート・マネージャのアーキテクチャ」の説明

関連項目:

リモートマネージャおよびその構成の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリモート・マネージャのインストールと構成に関する項を参照してください。

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

プラットフォーム・サービスには、次の内容が含まれます。

- リクエスト・サービス

- 認可サービス

- プラグイン・フレームワーク

- SoDエンジン・フレームワーク

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

2.2.2.3.1 リクエスト・サービス

Oracle Identity Managerのアーキテクチャには、承認ワークフローを構成できるリクエスト・サービスが含まれています。Oracle Identity Managerでは、この機能の配信に、Oracle Service Oriented Architecture (SOA) Suiteが使用されます。

Oracle SOA Suiteを使用すると、サービス指向アプリケーションを作成し、任意のミドルウェア・プラットフォームにデプロイできます。Oracle SOA Suiteは多数のコンポーネントで構成されていますが、包括的なワークフロー機能を提供するためにOracle Identity Managerに必要なコンポーネントは、次のとおりです。

- BPEL Process Manager: Oracle BPEL Process Managerは、自動ワークフロー・ステップとヒューマン・ワークフロー・ステップの両方を使用してアプリケーション間ビジネス・プロセスを作成、デプロイおよび管理するための包括的なソリューションを提供します。完了したプロセスと実行中のプロセスの両方の監査証跡や、プロセスの改善を可能にするプロセス履歴も提供します。

- ヒューマン・リクエスト・サービス: BPEL標準では手動タスクはサポートしていませんが、非同期サービスをサポートしています。そのため、Oracle SOA Suiteでは、手動ステップを標準のBPELプロセスに挿入できるように、手動タスク・サービスであるヒューマン・リクエスト・サービスをサポートしています。Oracle Identity Manager管理およびユーザー・コンソールにはタスク・リストがあります(ユーザーは、このリストを使用して、ヒューマン・リクエスト・サービスの管理下にある割り当てられたタスクを表示して操作できます)。

- BPEL Designer: Oracle BPEL DesignerはJDeveloperのプラグインとして使用でき、BPELベースのプロセスを作成してデプロイするための視覚デザインのパラダイムを提供します。

Oracle Identity Managerは、SOAスイートの最上部に抽象化サービスを提供し、SOAスイートに対するユーザーの操作を最適化および単純化します。このサービスには、Oracle Identity Managerで使用するBPELコンポジットを登録する機能、BPELおよびヒューマン・ワークフローのモジュールで使用するパラメータ化した変数を定義する機能、およびタスク・リストとカスタム開発で使用されるAPIが含まれています。

関連項目:

ワークフローおよびBPELコンポジットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認ワークフローに関する項を参照してください。

リクエスト・サービスには、Oracle Identity Managerでのリクエストの発行およびトラッキングに使用されるサービスも用意されています。ユーザーは、リクエストを使用して、必要な承認を取得した後に実行するアクションや、保持されているプロセス全体のトラッキング・レコードとそのステータスを要求できます。リクエストは、リクエスト・タイプとして定義されている様々なタイプのアクションが対象となります。リクエストのタイプは、次のいずれかです。

- エンティティの作成、変更または削除

- エンティティの有効化または無効化

- ユーザーまたは一連のユーザーに対するリソースのプロビジョニング

- ロールのメンバーとしてのアイデンティティの追加または削除

リクエスト・サービスは、様々なタイプのリクエストをサポートし、複数のリクエスト・タイプに対応する機能があります。Oracle Identity Managerには、最も一般的なユースケースを対象とした事前定義の多様なリクエスト・タイプが用意されています。また、リクエスト・サービスにはリクエスト・テンプレートに対するサポートも用意されており、特定の要件に対してリクエストのタイプをカスタマイズできます。

リクエスト・サービスは、Oracle Identity Managerの様々なサービスを介して、リクエスト・フローにデータを提供するフロー・モデルを定義します。これには、正確な時間での承認ワークフローの起動、ワークフローのステータスの監視、承認を受領した場合のリクエストの実行などがあります。

リクエストのトランザクション・データと履歴データの両方が保持され、監査およびコンプライアンスの要件がサポートされます。

関連項目:

Oracle Identity Managerセルフサービスのタスク・リストでのリクエストの作成およびリクエスト関連操作の実行の詳細は、「リクエストの管理」を参照してください。

2.2.2.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-4に、OESベースの認可サービスのアーキテクチャを示します。

図2-4 OESベースの認可サービス

「図2-4 OESベースの認可サービス」の説明

権限チェックがリクエストされるたびに、次の処理が実行されます。

- Oracle Identity Managerは認可サービスに接続し、保護されているエンティティに対する操作に関するアクセス決定に備えます。

- 次に、サービスはリソースに適用する1つ以上のポリシーを検索して評価します。

- 実行時には、セキュリティ・モジュールによって、ポリシーの評価に必要なすべての情報が収集されます。

- ポリシーが、ロールごとに対象を参照する場合は、すべてのロールが評価され、アクセス決定が実行されます。

Oracle Identity Managerは、OESの最上部に抽象化サービスを提供し、Oracle Identity Managerのポリシーの定義を最適化および単純化します。このサービスにはポリシー定義UIが含まれており、これによって、機能に固有で、ユーザーやロールなどのエンティティに関する属性や機能のきめ細かな制御をサポートする認可ポリシーを定義できます。認可ポリシーの構造化コンポーネントおよび認可ポリシーの作成方法と管理方法の詳細は、「認可ポリシーの作成および管理」を参照してください。

2.2.2.3.3 プラグイン・フレームワーク

プラグイン・フレームワークを使用すると、Oracle Identity Managerのデフォルトの機能を簡単に拡張およびカスタマイズできます。拡張性を提供できるビジネス・ロジックの特定のプラグイン・ポイントは、この機能によって公開されます。各インタフェース定義には、このようなポイントが付随しており、プラグイン・インタフェースと呼ばれます。顧客は、これらのプラグイン・インタフェースを拡張してカスタマイズを定義するコードを、ビジネス・ニーズに基づいて作成できます。これらのプラグインは、プラグイン・マネージャを使用してOracle Identity Managerにデプロイおよび登録されます。その後、これらのプラグインは、Oracle Identity Managerによって、該当するポイント以降に処理する機能に組み込まれます。

機能の開発者は、カスタム実装の格納場所とそのロード方法をトラッキングする必要はありません。プラグイン・フレームワークは、クラスパス、ファイル・システムおよびデータベースからのプラグインのローディングをサポートしています。

関連項目:

プラグイン・フレームワークの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプラグインの開発に関する項を参照してください。

2.2.2.3.4 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チェックは、プロビジョニング・ライフサイクルの様々な時点(アクセスのリクエスト時、承認ワークフローの実行時、プロビジョニングの実行時など)で実行できます。違反が検出されると、リクエストまたはリソースは違反としてマークされ、承認者または管理者によって続行するかどうかが判断されます。リクエストの処理中に違反が検出された場合は、さらに高いレベルで承認できる様々な承認ワークフローを起動できます。

関連項目:

SoDの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

2.2.2.3.5 スケジューラ・サービス

ビジネス・システムでは、指定の時間に他のプログラムを実行するように構成されたスケジューリング・システムが頻繁に活用されます。スケジューリング・システムでは、レポートの生成、データの再フォーマット、または監査を実施するアプリケーションが定期的に実行されます。多くの場合、スケジューリング・システムは、定められた時間に自動的に定型作業を実行するバッチ・ジョブ(スケジュールされたジョブ)を実行します。スケジューリング・システムは、エンタープライズ・プロビジョニング・ソリューションに不可欠です。プロビジョニングには、通常、時間ベースの方法で実行するタスクが含まれています。次に例を示します。

- 管理されたアプリケーションで直接行われた変更をすべてリコンサイルする夜間ジョブの実行

- 指定の時間内に割り当てられたジョブが処理されなかった場合のエスカレーションの実行

- 特定時間に開始するリクエストの実行

Oracle Identity Managerプラットフォームには、エンタープライズ・プロビジョニング要件を満たすためのスケジュール機能を提供するスケジューラが含まれています。このサービスは、独立した製品ではなく、Oracle Identity Managerプラットフォームの一部として管理されます。図2-5に、Oracle Identity Managerスケジューラのアーキテクチャの概要を示します。

図2-5 Oracle Identity Managerスケジューラのアーキテクチャ

「図2-5 Oracle Identity Managerスケジューラのアーキテクチャ」の説明

スケジューラ・サービスによって提供される主な機能は、次のとおりです。

- 数千のジョブを実行するための単純または複雑なスケジュールを作成する機能

- スケジューリング・サービスをクラスタ化されたサービスとして実行し、必要な高可用性機能(フェイルオーバーやロード・バランシングなど)を提供する機能

- 管理およびフェイルオーバー・サポートのためにジョブの定義を永続化する機能

- ジョブを作成、変更、有効化、無効化および削除し、個々のジョブ実行を管理UIを使用して管理する機能

- 定期的にスケジュールされた実行以外に、非定型方式でジョブを実行する機能

- エラーと障害を管理する機能

- ジョブ実行の履歴(実行の統計と結果を含む)を保持する機能

- スケジューラ・サービス自体を管理する機能

関連項目:

- スケジューラ・サービスの詳細およびカスタム・スケジュール済タスクの作成および実装の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの「スケジュール済タスクの管理」の章を参照してください。

2.2.3 データ層

Oracle Identity Managerはデータおよびメタデータによって駆動されるため、Oracle Identity Managerの機能には柔軟性と適合性が提供されます。Oracle Identity Managerリポジトリまたはデータベースで構成されたOracle Identity Managerのデータ層は、ANSI SQL 92準拠のリレーショナル・データベースおよびLDAPアイデンティティ・ストア(オプション)でOracle Identity Managerデータとメタデータを管理および格納します。

この項では、データ層について次の各トピックで説明します。

- Oracle Identity Managerデータベース

- メタデータ・ストア

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

2.2.3.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

レポート

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.2.3.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データベース内に存在します。

2.2.3.3 アイデンティティ・ストア

Oracle Identity Manager 11g リリース1 (11.1.1)には、LDAPベースのアイデンティティ・ストアをOracle Identity Managerアーキテクチャに統合する機能があります。リリース9.xでは、Oracle Identity Managerアイデンティティ・ストアはOracle Identity Managerデータベースにあります。したがって、Oracle Identity Managerはプロビジョニング・ターゲットとしてLDAPと統合され、つまり、Oracle Identity ManagerユーザーとLDAPユーザー間のカスタム統合を構築できます。一方、11g リリース1 (11.1.1)では、Oracle Identity Managerから直接LDAPベースのアイデンティティ・ストアに接続して管理できます。この機能を使用すると、アイデンティティのリクエスト・ベースの作成および管理を含めたOracle Identity Managerの高度なユーザー管理機能を使用して、企業のアイデンティティ・ストア内でアイデンティティを管理できます。

このデプロイメント・アーキテクチャでは、ユーザー・アイデンティティ情報が、LDAPストアに加えてOracle Identity Managerデータベースにも格納されるため、Oracle Identity Managerが機能するために必要なリレーショナル機能がサポートされます。すべてのデータは、プロビジョニング・アクションの実行やポリシーおよびルールの設定なしで、透過的に同期が維持されます。ユーザーの作成や変更など、Oracle Identity Manager内で開始されるアイデンティティ操作は、トランザクションの整合性を維持する形で両方のストアで実行されます。さらに、Oracle Identity Manager外部で行われたLDAPストアの変更は、Oracle Identity Managerにプルされ、アイデンティティ・コンテキストの一部として使用できるようになります。

関連項目:

LDAPストアの統合および構成の詳細は、「LDAPアイデンティティ・ストアとOracle Identity Managerの統合」を参照してください。

2.3 システム・コンポーネント

Oracle Identity Managerは、オープンでスケーラブルな企業規模のモジュール型アーキテクチャに基づいて構築されています。各モジュールは、システムの全体の機能において重要な役割を果します。図2-6に、Oracle Identity Managerのシステム・コンポーネントを示します。

図2-6 Oracle Identity Managerのシステム・コンポーネント

「図2-6 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 Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・イベントの管理に関する項を参照してください。

組織の他のリポジトリからOracle Identity Managerに大量のデータをロードする場合は、バルク・ロード・ユーティリティを使用できます。バルク・ロード・ユーティリティは、データ・ロードでの停止時間を短縮します。さらに、バルク・ロード・ユーティリティは、Oracle Identity Managerのユーザー、ロール、メンバーシップおよびユーザーにプロビジョニングされたアカウントをインポートします。

関連項目:

バルク・ロード・ユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のバルク・ロード・ユーティリティに関する項を参照してください。

共通のサービス

Oracle Identity Managerの他のコンポーネントで共有され、使用される様々なサービスはまとめてグループ化されます。これには次のサービスがあります。

- フォーム・デザイナ: Oracle Identity Managerにあらかじめ含まれていないプロセスおよびリソース・オブジェクトのフォームを作成できるフォーム。フォーム・デザイナの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のフォーム・デザイナのフォームに関する項を参照してください。

- スケジューラ: 特定のスケジューラで特定のジョブを実行する機能を提供するサービス。ユーザー、アプリケーション開発者、コネクタ開発者および管理者は、このサービスを使用してジョブを作成し、指定した間隔で実行するように構成できます。このサービスでは、ジョブの機能およびそのスケジュールを管理する管理機能も提供されます。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの「スケジュール済タスクの管理」の章を参照してください。

- 通知テンプレート: Oracle Identity Managerで発生するイベントについて関係者に通知を送信するために、共通の通知サービスが他の機能コンポーネントによって使用されます。また、このサービスでは、通知テンプレートを管理する機能も提供されます。送信通知の送信には通知テンプレートが使用されます。通常、これらのテンプレートには、よりコンテキストに依存した内容を提供するために使用可能なデータを参照する変数が含まれています。詳細は、「通知テンプレートの作成および管理」の章を参照してください。

- システム・プロパティ: システム・プロパティは、アプリケーションの構成を制御するエンティティです。デフォルトのシステム・プロパティに加え、Oracle Identity Managerのシステム・プロパティも作成および管理できます。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの「システム・プロパティの管理」の章を参照してください。

- デプロイメント・マネージャ: デプロイメント・マネージャは、Oracle Identity Manager構成のエクスポートおよびインポートに使用するツールです。デプロイメント・マネージャを使用すると、Oracle Identity Managerの構成を形成するオブジェクトをエクスポートできます。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのデプロイメント・マネージャを使用したデータのインポートおよびエクスポートに関する項を参照してください。

ワークフローおよびリクエスト管理

Oracle Identity Managerの様々な操作は直接実行できません。かわりに、操作をリクエストする必要があります。リクエスト管理サービスでは、リクエストを作成、承認および管理するためのメカニズムを提供します。リクエストは特定のアクションを実行する必要があるユーザーまたは管理者が作成したエンティティで、アクションを実行するには、誰かまたはなんらかのプロセスから事前に任意の権限を取得しておく必要があります。たとえば、ユーザーはラップトップ・コンピュータへのアクセス権を取得するためのリクエストを作成し、マネージャはリクエストを承認してオープン購買依頼を作成し、ITリソース管理者はリクエストを承認できます。

プロビジョニング・ソリューションの主要な目標は、リクエストおよびプロビジョニング・リソースを管理することです。リクエスト・サービスは、Business Process Execution Language (BPEL) 11gワークフロー・エンジンに対して抽象レイヤーを提供します。リクエスト、プロビジョニング、アテステーションなどの機能コンポーネントは、ワークフロー・エンジンと相互作用して対象者を承認します。リクエスト・サービスは、ワークフロー・インスタンスおよびカテゴリを管理することでOracle Identity Managerの様々な機能コンポーネントに対応し、BPELに対して抽象レイヤーを提供します。Oracle Identity Managerへのワークフローの登録の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

インフラストラクチャおよびミドルウェア統合

アダプタ・ファクトリ、カーネル・オーケストレーション・メカニズム、コンテキスト・マネージャおよびプラグイン・フレームワークは、これらのシステムとのハードコード統合の必要性を排除するように設計されています。

Oracle Identity Managerとミドルウェア・アプリケーションの統合の詳細は、「統合ソリューション」を参照してください。

コネクタ・フレームワーク

コネクタ・フレームワークの説明は、「統合サービス」を参照してください。

3 ユーザー・インタフェース

Oracle Identity Managerには、様々なタスクの実行に使用できるユーザー・インタフェースがあります。それは、Oracle Identity Manager管理およびユーザー・コンソールとOracle Identity Manager Design Consoleです。これらのインタフェースは、Oracle Identity Managerのプレゼンテーション層またはクライアント層にあります。Oracle Identity Managerには、インバウンド・プロビジョニング・リクエストをサポートするSPML Webサービス・インタフェースも用意されています。

この章では、Oracle Identity Managerのインタフェースを紹介し、各機能について簡単に説明します。また、SPML Webサービスについても簡単に紹介します。この章では、次の項目について説明します。

- Oracle Identity Manager管理およびユーザー・コンソールの概要

- Oracle Identity Manager Design Consoleの概要

- SPML Webサービス

3.1 Oracle Identity Manager管理およびユーザー・コンソールの概要

Oracle Identity Managerは、企業アプリケーションや管理システムへのアクセスを自動的に許可および取り消すための、高度で柔軟なプロビジョニング・システムです。Oracle Identity Manager管理およびユーザー・コンソールは、組織のスタッフやパートナに組織のリソースへのアクセスを提供し、これらのリソースに関連付けられたアクセス・ポリシーを強制できます。

Oracle Identity Manager管理およびユーザー・コンソールを使用すると、ユーザー・アカウントの表示、プロファイルの変更、リクエスト・ステータスの表示、パスワードの変更など、様々な機能を実行できます。また、この項で後述するように、Oracle Identity Manager管理およびユーザー・コンソールはカスタマイズできます。

注意:

ユーザーによっては使用できない機能もあります。Oracle Identity Managerで表示および使用できる機能は、割り当てられている権限によって異なります。

Oracle Identity Manager管理およびユーザー・コンソールは、次の主要な領域で構成されています。

- ユーザー・セルフサービス

- Oracle Identity Administration

- Oracle Identity Manager拡張管理

- Oracle Identity Manager管理およびユーザー・コンソールのカスタマイズ

- ユーザー・インタフェースのローカライズ

3.1.1 ユーザー・セルフサービス

未認証ユーザー・セルフサービス(つまり、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セルフサービスの機能について説明します。

3.1.1.1 ユーザー・セルフサービスの機能

Oracle Identity Managerセルフサービスを使用して、次の機能を実行します。

- Oracle Identity Managerへの自己登録
Oracle Identity Managerのアカウントがない場合は、未認証ユーザー・セルフサービスからOracle Identity Managerに自己登録して、アカウントを作成する必要があります。システムの構成状況によっては、管理者にアカウント作成を依頼する必要があります。

Oracle Identity Managerに初めてログインする際に、チャレンジ質問のプロンプトが表示された場合は質問に回答します。このチャレンジ質問および回答は、パスワードを忘れた場合にアカウントを認証するために使用されます。

- 自己登録リクエストのトラッキング
自己登録リクエストの送信時に生成される登録トラッキングIDを活用し、自己登録リクエストをトラッキングできます。

- 忘れたパスワードの取得
パスワードを忘れた場合は、チャレンジ質問に正しく回答することで忘れたパスワードを取得できます。

関連項目:

未認証ユーザー・セルフサービス・インタフェースの詳細は、第7章「セルフサービス登録の構成および使用」を参照してください。

- 自己プロファイルの管理
ユーザー・セルフサービスを使用して、Oracle Identity Managerユーザー・プロファイルに関連付けられた基本情報を変更できます。自己プロファイルの管理には、自分のユーザー属性の更新、ロールおよびリソースのリクエストと削除が含まれます。

- プロキシの管理
ユーザー・セルフサービスでは、病気や休暇で不在の場合に、タスク承認の職責を別のユーザーに委任できます。

- パスワード管理
また、パスワードも自由に、またはシステム要件に応じてその都度変更できます。

- リソースおよびリクエストの表示
ユーザー・セルフサービスを使用して、自分に対してプロビジョニングされたリソースを表示できます。このWebクライアントでは、自分が送信したリソース・リクエストと、自分宛てに他のユーザーが作成したリソース・リクエストもすべて表示できます。新しいリソースのプロビジョニングをリクエストすることもできます。他のユーザーのリソースやロールも同様にリクエストできます。また、権限によってはユーザーの作成および変更のリクエストも送信できます。

- タスクリストのタスクの管理
リクエストおよび関連するリソースの承認プロセスは、プロビジョニングでリクエストおよびリソースが使用できるように、複数のタスクで構成されます。タスクリストは、次の要素で構成されます。

- 承認タスク: 自分または自分の保留中のアクションに割り当てられている任意のタイプのリクエストに関連する(プロビジョニング・リソースのみに関連しているわけではない)タスク

- プロビジョニング・タスク: 自分または自分の保留中のアクションに割り当てられているプロビジョニング・タスクに関連するタスク

- アテステーション・タスク: 自分または自分の保留中のアクションに割り当てられているアテステーション・プロセスに関連するタスク

関連項目:

Oracle Identity Managerセルフサービスを使用したタスクの完了の詳細は、第II部「Oracle Identity Managerセルフサービス」を参照してください。

3.1.2 Oracle Identity Administration

Oracle Identity Administrationでは、ユーザー、ロールおよび組織の作成や管理など、アイデンティティ管理タスクを実行できます。Oracle Identity Managerでの様々な構成要素および機能のアクセスを制御する承認ポリシーを定義することもできます。

3.1.2.1 Oracle Identity Administrationの機能

Oracle Identity Administrationを使用して、次の機能を実行します。

- レコードの検索
Oracle Identity Managerの多くのフィールドには検索機能があります。検索機能は、レコードを検索するときに使用します。レコードを検索するには、1つ以上のフィールドにデータを入力し、検索で取得するレコードを制限する必要があります。フィールドに入力するデータの他に、ワイルドカード文字も使用できます。

注意:

検索の作成および実行方法は、実行する検索のタイプによって異なります。取得される結果は、検索を実行する状況に基づきます。

Oracle Identity Managerでは、単純検索と拡張検索をサポートしています。単純検索操作では、検索属性として指定する検索文字列に基づいてレコードを検索できます。この操作は、単純検索またはクイック検索とも呼ばれます。拡張検索操作には、単純検索操作より複雑な検索基準を指定できるフォームがあります。

- ユーザー・レコードの作成および管理
Oracle Identity Administrationを使用して、ユーザー・レコードを作成および管理できます。

- 組織の作成と管理
Oracle Identity Administrationを使用して、組織レコードを作成および管理できます。また、リソース、組織およびサブ組織の有効化、無効化、失効およびプロビジョニングが可能です。

- ロールの作成および管理
Oracle Identity Administrationを使用すると、Oracle Identity Manager内でアクセス権を割り当てたり、リソースを自動的にプロビジョニングしたり、承認やアテステーションなどの共通のタスクで使用できるユーザーの論理的なグループを表すロールを定義することができます。ロールは、組織に依存しないロール、複数の組織にわたるロール、または1つの組織のユーザーのみを含むロールのいずれかです。

- 認可ポリシーの作成および管理
認可ポリシー管理は、管理機能として集中管理されています。これはOracle Identity ManagerとOracle Entitlements Server (OES)を認可システムとして統合することで実現し、アプリケーションに対するアクセス制御を保証します。さらに、Oracle Identity Managerの様々な機能に対してコンテキスト依存の認可ポリシーを作成できます。認可ポリシーは、アプリケーションの様々な操作に対するユーザーの実行を許可または阻止することで、アプリケーションへのアクセスを制御します。

3.1.3 Oracle Identity Manager拡張管理

Oracle Identity Manager 拡張管理を使用すると、リクエスト、リコンシリエーション・イベントおよびポリシーの作成や管理などの様々な管理機能を実行できます。

3.1.3.1 Oracle Identity Manager拡張管理の機能

Oracle Identity Manager拡張管理を使用して、次の機能を実行します。

- 管理機能:

- リクエストの作成および追跡
Oracle Identity Managerでは、リソースのプロビジョニング、ユーザーや他のユーザーのロールの作成や管理など、様々な操作またはアクションのリクエストを作成および管理できます。Oracle Identity Managerで付与された権限に基づいて、拡張管理を使用してリクエストを作成およびトラッキングできます。リクエストのトラッキングでは、基本情報、リクエスト履歴、リクエストのコメント、リクエスト承認タスクなど、リクエストの詳細を表示できます。

- レポートの生成
要件に基づいて拡張管理を使用し、Oracle Identity Manager 11g リリース1 (11.1.1)のレポート・ソリューションであるBI Publisherでレポートを生成できます。アクセス・ポリシー・レポート、アテステーション・レポート、リクエストおよび承認レポート、パスワード・ポリシー・レポートなど、レポートは機能領域に基づいて分類されます。

- イベント管理機能:

- リコンシリエーション・イベントの管理
リコンシリエーション・プロセスには、Oracle Identity Managerに適用されるイベントの生成が含まれます。このイベントには、ターゲット・システムでのアトミック変更が反映され、変更されたデータ、変更のタイプおよびその他の情報が含まれます。拡張管理では、保存されたイベントを問い合せ、イベント詳細を表示して、イベントの問題の解決に必要なアクションを実行することで、リコンシリエーション・イベントを管理できます。

- アテステーションのタスクおよびプロセスの表示
拡張管理を使用して、割り当てられたアテステーション・レポートを表示し、レポート内の個々の項目に対してアテステーション・レスポンスを用意できます。

Oracle Identity Managerのアテステーションは、スケジュールされたアテステーション・プロセスの定義を介してサポートされます。アテステーション・プロセスは、構成可能なビジネス・プロセスとしてOracle Identity Managerに実装され、ユーザーのアテステーション・タスクを作成します。レビューアを務めるユーザーは、このプロセスを完了して正確な監査情報を提供する必要があります。

- ポリシー機能:

- アクセス・ポリシーの作成および管理
ユーザーに対してどのようなリソースが自動的にプロビジョニングまたはプロビジョニング解除されるかを定義するアクセス・ポリシーは、ビジネス・ルールに基づいて作成および管理できます。拡張管理のアクセス・ポリシー・ウィザードを使用すると、アクセス・ポリシーが付加されたロールのメンバーであるユーザーにリソースをプロビジョニングするアクセス・ポリシーを定義できます。アクセス・ポリシーでは、プロビジョニングで作成されたアカウントにプロビジョニングする権限も指定できます。拡張管理を使用して、既存のアクセス・ポリシーの情報を変更することもできます。

- 承認ポリシーの作成および管理
承認ポリシーはリクエスト管理の構成可能なエンティティで、リクエスト・レベルおよび操作レベルの承認専用にリクエスト・サービスに定義された承認プロセスに対して様々なリクエスト・タイプを関連付けるのに役立ちます。拡張管理を使用して、承認ポリシーを作成、変更および削除できます。

- アテステーション・プロセスの作成および管理
拡張管理では、新規アテステーション・プロセスの定義、既存のアテステーションの管理、および非定型アテステーション・プロセスの開始を操作できます。拡張管理のアテステーション・ダッシュボード機能を使用して、アテステーション・プロセスを作成、変更、無効化、有効化、実行および削除できます。

- 構成機能:

- ユーザー管理の構成
Oracle Identity Managerのユーザー管理機能は、構成管理機能を使用して構成およびカスタマイズされます。構成管理を使用して、Oracle Identity Manager管理およびユーザー・コンソールでのユーザー・レコードの表示方法をカスタマイズしたり、ユーザー・エンティティの操作および属性を構成できます。Oracle Identity Manager管理では、エンティティで実行される操作に基づいて、属性セットがユーザーに示されます。拡張管理を使用して、ユーザー・エンティティのデータ構造を定義し、ユーザー管理操作および操作の属性を構成できます。

- リソースの管理
拡張管理のリソース管理機能を使用して、組織または個人ユーザーについてリソース・オブジェクトを管理できます。リソースの管理には、次のアクティビティがあります。

- リソースの検索および詳細の表示

- リソース管理者およびリソース認可者グループの管理

- ワークフローの表示および編集

- リソース監査目的の定義

- ITリソースの定義および管理

- スケジュール済タスクの定義および管理

- リクエスト・テンプレートの作成および管理
リクエスト・テンプレートを使用すると、目的のリクエスト・タイプをカスタマイズできます。すべてのリクエスト・タイプにはデフォルトのテンプレートがあり、このテンプレートを削除したり、名前を変更することはできません。デフォルトのテンプレート名はリクエスト・タイプと同じです。拡張管理を使用してカスタム・リクエスト・テンプレートを作成および管理し、要件に従ってリクエスト・タイプをカスタマイズできます。

- 汎用コネクタの作成および管理
基本のコネクタは、高度な機能やカスタマイズ動作を使用せず、SPML、JDBCなどの汎用接続性テクノロジを使用してすばやく簡単に作成できます。拡張管理を使用して、汎用テクノロジ・コネクタを作成および変更したり、コネクタの一部でありオブジェクトすべての定義が格納されているコネクタXMLファイルをインポートおよびエクスポートできます。

関連項目:

汎用テクノロジ・コネクタの作成方法および管理方法は、『Oracle Fusion Middleware 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.1.4 Oracle Identity Manager管理およびユーザー・コンソールのカスタマイズ

Oracle Identity Manager管理およびユーザー・コンソールの様々な側面をカスタマイズできます。Oracle Identity Managerを使用して、組織の要件を満たすように、ブランド情報、メニュー・オプション、検索結果表の列などのUI要素をカスタマイズできます。

Oracle Identity Manager管理およびユーザー・コンソールの次の構成要素はカスタマイズできます。

- ブランド・テキスト、ロゴ・イメージ、ロゴ・マウスオーバー・テキストなどのブランド情報

- ボタンのラベル

- メニューおよびタブ

- 検索結果表の列

- フォーム・テンプレート

- カスタムURL

- ポップアップ・プロパティ

- 色、フォントおよび位置揃え

関連項目:

Oracle Identity Manager管理およびユーザー・コンソールの様々な構成要素のカスタマイズ方法は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

3.1.5 ユーザー・インタフェースのローカライズ

ローカライズは、ロケール設定に基づいてユーザー・インタフェース(UI)をエンド・ユーザーにレンダリングするプロセスです。Oracle Identity Managerでは、次の順にロケール設定を使用します。

1. Oracle Access Manager (OAM)保護環境 - OAMログイン画面に言語選択オプションがあるときに、ユーザーが言語を選択すると、その言語には最高の優先度が適用されます。

2. ブラウザのロケール - このロケールの取得で問題が検出された場合は、次のオプションが評価されます。

3. サーバーのロケール - サーバーのインストールに使用されたロケールです。

関連項目:

ユーザー・インタフェースのローカライズの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザーの言語の設定に関する項を参照してください。

3.2 Oracle Identity Manager Design Consoleの概要

Oracle Identity Manager Design Consoleは、主にシステム設定の構成に使用されます。これらの設定は、Oracle Identity Managerのシステム全体にかかわる動作を制御するため、ユーザーに影響を及ぼします。この項では、Oracle Identity Manager Design Consoleの基本的な機能について説明します。

3.2.1 Oracle Identity Manager Design Consoleの機能

次のOracle Identity Manager Design Consoleの機能を使用して、様々なタスクを実行できます。

- フィールド・タイプ
Oracle Identity Manager Design Consoleの基本機能の動作は、すべてのフォームを使用しやすくするための標準です。データ・フィールドにはレコードを表示できます。また、参照フィールドを使用して値を検索することもできます。たとえば、Date & Timeウィンドウを使用すると、日、月および時刻を選択できます。

また、Notesウィンドウにはレコードの補足情報を入力できます。Oracle Identity Manager Design Consoleを使用して、有効なエンティティを選択し、レコードに割り当てることもできます。

- 検索機能
Oracle Identity Manager Design Consoleを使用すると、データベース内のレコードに対して検索(問合せとも呼ばれる)を実行できます。Oracle Identity Manager Design Consoleのすべてのフォームには、検索機能が用意されています。フォームのフィールドで検索条件をフィルタ処理することができます。これにより、返される結果は、入力した条件と一致するレコードのみに限定されます。

検索ではワイルドカードも使用できます。ワイルドカード文字のアスタリスク(*)は、検索条件の特定されていない部分を表します。たとえば、Oracle Identity Manager Design Consoleフォームの「場所」フィールドに「B*」と入力して検索を実行すると、文字Bから始まる地名のレコード(Burbank、Boston、Bristolなど)がすべて返されます。

注意:

データベース内の複数のレコードが検索条件と一致する場合は、各レコードの詳細を表示できます。

- ユーザー管理
Oracle Identity Manager Design Consoleでは、次のユーザー管理機能を実行できます。

- 組織レベルでの特定のプロセス・フォーム・パラメータのデフォルト値の定義

- ポリシーにより各ユーザーに許可または拒否されているリソースの表示

- Oracle Identity Manager Design Consoleのどのようなフォームおよびフォルダを、どのロールに許可するかの定義

また、ターゲット・リソースおよび信頼できるソースから受け取ったリコンシリエーション・イベントの情報の表示、分析、修正、リンクおよび管理も実行できます。

- リソース管理
Oracle Identity Manager Design Consoleを使用すると、Oracle Identity Managerのリソースを管理できます。リソース管理で実行できる様々なタスクには、次のものがあります。

- ITリソース・フォームに参照値として表示されるリソース・タイプの作成

- パスワード・ポリシーの選択、自動グループ・メンバーシップ、プロビジョニング・プロセス選択、タスク割当ておよびアダプタへの事前移入に適用できるルールの作成

- リソース・オブジェクトの作成および管理

- プロセス管理
プロセス管理では、Oracle Identity Managerプロセスと電子メール通知のテンプレートの作成および管理を行います。

Oracle Identity Managerプロセスは、承認またはプロビジョニングの論理ワークフローを表すためのメカニズムです。プロセス定義は、プロセスの完了のために実行する必要があるタスクで構成されます。Oracle Identity Manager Design Consoleを使用すると、リソース・オブジェクトに関連付ける承認プロセスとプロビジョニング・プロセスを作成および管理できます。

- Oracle Identity Managerの管理
Oracle Identity Manager Design Consoleには、Oracle Identity Managerの管理機能を管理するためのツールが用意されています。これらのツールを使用して、Oracle Identity Managerの様々な管理タスクを実行できます。Oracle Identity Manager Design Consoleを使用すると、参照フィールドとその値、およびユーザー定義フィールドを作成して管理することもできます。

このコンソールを使用して、クライアントおよびサーバーの動作を制御するプロパティの値を指定できます。Oracle Identity Managerでサード・パーティのプログラムとの通信に使用されるサーバーに関する情報も表示できます。さらに、タスクを実行する日時に合せてスケジュールを設定できます。

- 開発ツール
Oracle Identity Manager Design Consoleには一連の開発ツールが用意されており、管理者や開発者は、これらのツールを使用してOracle Identity Managerをカスタマイズできます。

Oracle Identity ManagerがITリソースのAPIと接続し、そのリソースと通信できるようにするコードを作成および管理できます。このコードはアダプタと呼ばれます。また、複数のアダプタを同時にコンパイルできます。

Oracle Identity Manager Design Consoleを使用すると、特定の問題が発生した場合に表示するエラー・メッセージを作成できます。また、Oracle Identity Managerで使用されるイベント・ハンドラ、データ・オブジェクトおよびリコンシリエーション・ルールを作成および管理できます。

関連項目:

Oracle Identity Manager Design Consoleの機能および特徴の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

3.3 SPML Webサービス

Oracle Identity Managerは、クライアント・アプリケーションに対してService Provisioning Markup Language (SPML)を利用するアイデンティティ管理サービスを提供します。SPML Webサービスは、インバウンドSPMLベースのプロビジョニング・リクエストのインタフェースです。SPMLにはXSDプロファイルとDSMLプロファイルの2つのプロファイルがあります。このリリースのOracle Identity ManagerではXSDプロファイルを利用します。参照の管理(たとえば、ロール・メンバーシップの割当てと失効、SPMLを介した親ロールの追加や削除によるロール階層の変更)、ユーザー・パスワードのリセット、およびユーザー・アカウントの無効化と再有効化を操作する機能が用意されています。

関連項目:

SPML Webサービスの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のSPMLサービスに関する項を参照してください。

4 デプロイメント構成

この章では、Oracle Identity Managerの次のデプロイ構成について説明します。

- プロビジョニング構成

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

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

4.1 プロビジョニング構成

プロビジョニングとは、プロビジョニング・システム(Oracle Identity Manager)で開始されたアクション(ターゲット・システム・アイデンティティの作成、変更または削除)が、ターゲット・システムに通信されるプロセスです。アイデンティティに対する変更により、一連のプロビジョニング・アクションがトリガーされます。Oracle Identity Manager自体のリポジトリにアイデンティティが格納されているOracle Identity Managerのデプロイメントでは、アイデンティティ属性に対する変更が検出されると、それに応じてプロビジョニング・アクションがトリガーされます。

Oracle Identity Managerを使用すると、ターゲット・システム上でユーザーを作成、メンテナンスおよび削除できます。この構成では、Oracle Identity Managerは、ターゲット・システムですべてのユーザー・データを管理するためのフロントエンド・エントリ・ポイントとして機能します。アカウントがプロビジョニングされると、アカウントがプロビジョニングされたユーザーは、Oracle Identity Managerと対話しなくてもターゲット・システムにアクセスできます。これが、Oracle Identity Managerのプロビジョニング構成です。

プロビジョニングの目的は、ターゲット・システムでのユーザーの作成およびメンテナンスを自動化することです。プロビジョニングは、そのプロビジョニングのライフ・サイクルの構成要素となりうるワークフローの承認および監査の要件に対応するためにも使用されます。図4-1に、プロビジョニング・モジュールの仕組みを示します。

図4-1 プロビジョニング構成

「図4-1 プロビジョニング構成」の説明

プロビジョニング・イベントは、次の方法のいずれかで起動できます。

- リクエスト・ベースのプロビジョニング
リクエストは、管理者(場合によってはユーザー自身)が手動で作成できます。承認ワークフローはリクエストの送信後に開始され、承認済アカウント・プロファイルのプロビジョニングは承認の完了後に開始されます。

- ポリシー・ベースのプロビジョニング
このタイプのプロビジョニングは、アクセス・ポリシーを介したユーザーへのターゲット・リソースの付与の自動化を意味します。アクセス・ポリシーは、ロールとターゲット・リソースの間の関連を定義するために使用されます。デフォルトでは、これらのロールの各メンバーは、ターゲット・リソースの事前定義済アカウントを取得します。

- ダイレクト・プロビジョニング
このタイプのプロビジョニングは、特殊な管理者専用機能です。認可されている管理者はアカウントを作成できます。承認プロセスを待機しなくても、ターゲット・システムで特定のユーザーのアカウントを作成できます。

4.2 リコンシリエーション構成

リコンシリエーションとは、ターゲット・システムで開始された操作(ユーザーの作成、変更または削除など)が、Oracle Identity Managerに通信されるプロセスです。リコンシリエーション・プロセスは、Oracle Identity Managerリポジトリとターゲット・システム・リポジトリのエントリを比較して、2つのリポジトリの相違を判断し、最新の変更内容をOracle Identity Managerリポジトリに適用するプロセスです。

ロールのリコンシリエーション、ロール・メンバーシップのリコンシリエーションおよびロール階層の変更のリコンシリエーションは、個別のリコンシリエーション・イベントとして処理されます。理想的には、競合状態を回避するためにロール・イベントを最初に送信し、次にメンバーシップ・イベントのみを送信する必要があります。競合状態の場合は、自動再試行ロジックにより、リコンシリエーション・エンジンでの処理が可能です。詳細は、競合状態の項に記載されています。ロール、ロール・メンバーシップおよびロール階層の詳細は、「ロールの管理」を参照してください。

関連項目:

競合状態の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの競合状態の処理に関する項を参照してください。

図4-2は、プロビジョニングおよびリコンシリエーションが、Oracle Identity Managerからターゲット・システム、またはターゲット・システムからOracle Identity Managerへの同期化に関与する様子を示しています。プロビジョニング・システムでは、プロビジョニングおよびリコンシリエーションを使用して、ターゲット・システムに管理対象アイデンティティを作成したり、ターゲット・システムにすでに存在している場合は、管理対象アイデンティティをレプリケートできます。

図4-2 プロビジョニングおよびリコンシリエーション

「図4-2 プロビジョニングおよびリコンシリエーション」の説明

図4-2では、新しい従業員の入社時に、人事担当によってユーザーが作成されます。ユーザーは、信頼できるソース・リコンシリエーションによってOracle Identity Managerにリコンサイルされます。Oracle Identity Managerでユーザーが作成されると、ユーザーのアカウントはターゲット・システムにプロビジョニングされます。ターゲット・システムでは、ターゲット・システム管理者がそのアカウントに変更を追加できますが、その変更はOracle Identity Managerにリコンサイルする必要があります。

データ・フローに関しては、プロビジョニングではプッシュ・モデルを使用してプロビジョニング・システムから外部へのフローが提供され、これによってプロビジョニング・システムは変更の実施をターゲット・システムに示します。リコンシリエーションでは、プッシュ・モデルまたはプル・モデルを使用してプロビジョニング・システムの内側へのフローが提供され、これによってプロビジョニング・システムはターゲット・システムのアクティビティを検出します。

リコンシリエーション・プロセスには、Oracle Identity Managerに適用されるイベントの生成が含まれます。このイベントには、ターゲット・システムでのアトミック変更が反映され、変更されたデータ、変更のタイプおよびその他の情報が含まれます。ターゲット・システムで発生している変更に起因して結果的に生成されるリコンシリエーション・イベントは、これらのイベント管理ニーズに対応するOracle Identity Manager管理コンソールのリコンシリエーション・イベント・マネージャを使用して管理されます。

関連項目:

Oracle Identity Manager管理コンソールを使用したリコンシリエーション・イベントの管理の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーションの管理に関する項を参照してください。

この項には、次の項目が含まれます。

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

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

4.2.1 リコンシリエーションのタイプ

表4-1に示すように、リコンシリエーションには様々なタイプがあります。

表4-1 リコンシリエーションのタイプ

分類基準

リコンシリエーション・タイプ

リコンサイル対象オブジェクト

リコンサイル対象アイデンティティに基づいて、ユーザー、アカウント、ロール、関係(ロール階層やロール・メンバーシップを含む)など

注意: Oracle Identity Managerでは、組織のリコンシリエーションはサポートしていません。

リコンシリエーションのモード

変更ログ

標準

リコンシリエーションに使用されるアプローチ

増分リコンシリエーション

完全リコンシリエーション

この項の内容は次のとおりです。

- リコンサイル対象オブジェクトに基づくリコンシリエーション

- リコンシリエーションのモード

- リコンシリエーションに使用されるアプローチ

4.2.1.1 リコンサイル対象オブジェクトに基づくリコンシリエーション

リコンサイル対象のエンティティ・オブジェクトに基づいたリコンシリエーションです。Oracle Identity Managerでは、次のエンティティがリコンサイルされます。

- ユーザー: ユーザーは、Oracle Identity Manager内に存在し、Oracle Identity Managerを介して管理されるアイデンティティです。

- アカウント: アカウントはユーザーに付与され、ユーザーのOracle Identity ManagerへのログインとOracle Identity Managerの機能へのアクセスを可能にします。これらの機能には、少なくともセルフ・サービスとリクエストが含まれます。アカウントには、ワークフローの定義、ユーザー、組織、ロールなどの各種エンティティの委任管理を含め、追加の権限を付与できます。

- ロール: ロールは、Oracle Identity Manager内でアクセス権を割り当てたり、リソースを自動的にプロビジョニングしたり、承認やアテステーションなどの共通のタスクで使用できるユーザーの論理的なグループです。

- ロール階層: ロール階層は、親ロールから子ロールへの継承です。親ロールには、継承されるロールと同じ、メンバーに対する権限があります。

- ロール・メンバーシップ: ロール・メンバーシップは、継承先ロールのメンバーが継承元ロールから継承されることを意味します。メンバーシップおよび権限の継承の詳細は、「ロールの管理」を参照してください。

このセクションのトピックは次のとおりです:

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

- アカウント・リコンシリエーション

- リコンシリエーション・プロセス・フロー

4.2.1.1.1 信頼できるソース・リコンシリエーション

Oracle Identity Managerのユーザー、ロール、ロール・メンバーシップまたはロール階層の作成に対応するシステムからデータがリコンサイルされる場合、そのリコンシリエーション・モードは、アイデンティティ・リコンシリエーション、認証ソースのリコンシリエーションまたは信頼できるソース・リコンシリエーションと呼ばれます。リコンサイルの適用対象システムは、エンタープライズ・アイデンティティの認証ソースとも呼ばれ、人事管理システムまたは企業ディレクトリなどが該当します。

注意:

信頼できるリコンシリエーションに対してユーザー・ログインが渡されない場合、ログイン・ハンドラはユーザー・ログインを生成します。パスワードは、後処理イベント・ハンドラで生成され、そのパスワードの通知が送信されます。イベント・ハンドラの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリコンシリエーション操作のカスタマイズに関する項を参照してください。

図4-3に示すように、アイデンティティには複数の認証ソースを指定できます。様々な認証ソースを、カテゴリの異なるユーザー・アイデンティティに対するリコンシリエーションのソースや、様々な属性のセットに対するリコンシリエーションのソースにできます。リコンシリエーション・エンジンによって生成された各種のイベントは、追加、変更および削除されます。

図4-3 単一および複数の認証ソースからの信頼できるソース・リコンシリエーション

「図4-3 単一および複数の認証ソースからの信頼できるソース・リコンシリエーション」の説明

図4-3は、単一の認証ソースと複数の認証ソースからの信頼できるソース・リコンシリエーションを示しています。ユーザー・エンティティの作成は、複数の認証ソースからリコンサイルできます。複数の異なる認証ソースから異なる属性をリコンサイルすることもできます。たとえば、ある認証ソースはユーザーIDと電子メールIDを提供し、別の認証ソースがロール属性を提供するようにできます。

ターゲット・システムがアイデンティティおよびアカウントのソースである場合は、信頼できるソース・リコンシリエーションの後にアカウント・リコンシリエーションが続く必要があります。たとえば、Active Directoryが企業のLDAPリポジトリで、そこにユーザー情報が格納されている場合は、ユーザー情報がActive Directoryターゲット・システムからリコンサイルされます。その後、Active Directoryのアカウントが、異なるコネクタを使用してOracle Identity Managerにリコンサイルされます。アイデンティティ・リコンシリエーションは、信頼できるソースに固有のコネクタを使用して、信頼できるソースからのみ発生します。

注意:

リコンシリエーション・コネクタは、特定のターゲット・システムからアイデンティティまたはアカウントをリコンサイルするように開発されたコンポーネントです。通常、リコンシリエーション・コネクタはスケジュール済タスクとして実行するように構成されます。ただし、リコンシリエーションをトリガーするためのスケジュール済タスクがない、PeopleSoft HRコネクタなどのプッシュ・ベースのコネクタも存在します。

4.2.1.1.2 アカウント・リコンシリエーション

ターゲット・システムのアイデンティティがOracle Identity Managerにリコンサイルされるアカウントである場合、それはターゲット・リソース・リコンシリエーションまたはアカウント・リコンシリエーションです。このタイプのリコンシリエーションは、管理対象のターゲット・システムを表す特定のリソース・オブジェクトをリコンサイルします。この場合は、対応するプロビジョニング・フローが常に存在します。ターゲット・システムから取得されるアイデンティティは、ユーザーまたは組織にプロビジョニングされたリソース・オブジェクト・インスタンスにマップされます。

アカウント・リコンシリエーションは、次のシナリオで発生します。

シナリオI

アイデンティティが、認証ソースからOracle Identity Managerに作成されます。アイデンティティは、ターゲット・システムのリソースを使用してプロビジョニングされます。ターゲット・システムに対する変更は、Oracle Identity Managerとリコンサイルされます。図4-4に、ターゲット・システムからのアカウント・リコンシリエーションを示します。

図4-4 ターゲット・システムからのアカウント・リコンシリエーション

「図4-4 ターゲット・システムからのアカウント・リコンシリエーション」の説明

シナリオII

このシナリオでは、ターゲット・システムが当初、認証ソースの役割を果たします。その後、通常のプロビジョニング・ターゲットの役割を果たします。一連のステップは次のとおりです。

1. アイデンティティが、ターゲット・システム・エンティティの詳細に基づいてOracle Identity Managerに作成されます。そのエンティティに対して、対応するアカウントも作成されます。

2. エンティティは、プロビジョニングされたエンティティとしてターゲット・システムで更新されます。

3. ターゲット・システムのリソース管理者は、アカウントに対する変更を適用します。

4. ターゲット・システムで行われた変更は、Oracle Identity Managerとリコンサイルされます。

図4-5に、アイデンティティ・リコンシリエーションおよびその後に続くアカウント・リコンシリエーションを示します。

図4-5 アイデンティティ・リコンシリエーションとアカウント・リコンシリエーション

「図4-5 アイデンティティ・リコンシリエーションとアカウント・リコンシリエーション」の説明

注意:

XL.UserProfileAuditDataCollectionプロパティの値が監査日収集レベルに設定されている場合は、アカウント・リコンシリエーションによってバッチ・レベルでデータベース・レイヤーでの照合が実行され、プロビジョニングAPIを使用してイベント・アクションが実行されます。これによって、アカウント・リコンシリエーション用の監査イベント・ハンドラがトリガーされます。デフォルトでは、このプロパティの値は「リソース・フォーム」に設定されます。Oracle Identity Managerのシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

4.2.1.1.3 リコンシリエーション・プロセス・フロー

図4-6に、リコンシリエーション・プロセス・フローを示します。

図4-6 リコンシリエーション・プロセス・フロー

「図4-6 リコンシリエーション・プロセス・フロー」の説明

リコンシリエーション・プロセスには次のステップが含まれます。

1. ターゲット・システムでの変更: ターゲット・システムで発生する可能性のある様々なアクティビティには、ユーザー、アカウント、ロール、ロール・メンバーシップまたはロール階層の作成、変更または削除があります。

注意:

外部システムでエンティティを作成し、すぐ後にそのエンティティを変更すると、リコンシリエーションでのエンティティの作成ステップは処理されますが、エンティティの変更ステップは「作成に失敗しました」イベント・ステータスで失敗となります。これは、リコンシリエーションでは、同一バッチ処理内の同じエンティティに対して作成と変更のアクションを処理できないためです。

ただし、次のいずれかのビルトイン・メカニズムを使用して、リコンシリエーションのエンティティ変更アクションを後で再送信できます。

- 失敗した非同期タスクの自動再試行スケジュール済タスクを実行し、失敗したイベントを手動操作なしで再度処理します。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの自動再試行のエラー処理メカニズムに関する項を参照してください。

- 手動による再試行エラー処理メカニズムがトリガーされる場合は、失敗したイベントが再度処理されます。詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの手動による再試行エラー処理メカニズムに関する項を参照してください。

同じバッチ処理での処理の競合に起因するリコンシリエーションの失敗メッセージは、単なる一時的な失敗とみなすことができます。

2. リコンシリエーション・データのプロビジョニング: 作成、変更または削除のイベントが発生すると、そのイベントに関するデータは、リコンシリエーションAPIを使用してリコンシリエーション・サービスに送信されます。

注意:

リコンシリエーション・サービスとは、リコンシリエーション・エンジン、リコンシリエーションAPIおよび関連するメタデータやスキーマの集合を意味します。

3. リコンシリエーション・イベント・レコードの作成: リコンシリエーション・イベントのデータがリコンシリエーション・サービスに提供される場合、そのイベントのレコードはOracle Identity Managerリポジトリに格納されます。

4. リコンシリエーション・イベント・データの処理: 受け取ったデータはその後評価され、ターゲット・システムでの変更内容に基づいてOracle Identity Managerで実行する実際の操作が判断されます。評価には、次の目的に役立つ特定のルールセットが利用されます。

1. Oracle Identity Managerにすでに存在するデータのレコードが、アカウントまたはアイデンティティのいずれのデータであるかの識別

2. データが表すアカウントまたはアイデンティティの所有者の識別

3. 実行するコンテキスト依存アクションの定義

4. 評価終了時のイベントのステータス、およびリコンシリエーション・エンジンが対応する必要があるアクションの設定

5. イベントに対するアクションの実行: リコンシリエーション・イベント・データの処理の評価結果に基づいて、目的のアクションが実行されます。実行されるアクションには、次のような様々なものがあります。

注意:

イベントに対するアクションは、UIを使用して手動で実行するか、自動アクションにできます。

- 新規アカウントの作成と適切な所有者アイデンティティとの関連付け

- 一致したアカウントの更新

- 一致したアカウントの削除

- Oracle Identity Managerでの新しいユーザーの作成

- Oracle Identity Managerでの既存のユーザーの変更

- 既存のユーザーの削除

- ステータス属性の更新によるアカウント・ステータスの有効化と無効化

- ユーザーの有効化と無効化

- ロールの作成、更新または削除

- メンバーシップの作成または削除

- ロール階層の作成または削除

関連項目:

ロール・メンバーシップおよびロール階層の詳細は、「リコンシリエーション・エンジン」を参照してください。

6. リコンシリエーション・イベントによってトリガーされたアクションのフォロー・アップ: アクションが実行された後は、リコンシリエーション・イベントに基づいてフォロー・アップ・タスクを開始できます。フォロー・アップ・タスクまたは後処理タスクの例には、ユーザー作成イベントの後、ラップトップ・コンピュータなどのリソースをプロビジョニングするリクエストの作成があります。

4.2.1.2 リコンシリエーションのモード

リコンシリエーションのモードは、使用するコネクタに従ってプルまたはプッシュになります。Active Directoryなどの大半のコネクタはプル・モデルを使用します。プル・モデルでは、プル・リコンシリエーション・タスクがIAMスケジューラでスケジュールされます。タスクは一定間隔で実行されます。

関連項目:

IAMスケジューラの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。

通常、プル・ベースのリコンシリエーション・コネクタは、スケジュール済タスク内でリコンシリエーション・イベントを送信します。スケジュール済タスクを実行するたびに、新規リコンシリエーションの実行がトリガーされ、リコンシリエーション・イベントがバッチで作成されます。バッチ・サイズが適合する場合は、そのバッチが送信され、処理されます。スケジュール済タスクの終了時に、サイズが適合しないすべてのバッチを送信するジョブ終了リスナーがトリガーされます。

PeopleSoftコネクタなどのリコンシリエーション・コネクタは、プッシュ・モデルを使用します。コネクタは、PeopleSoftによって送信される非同期メッセージを検出するHTTPリスナーで構成されます。メッセージの受信時に、リスナーがリコンシリエーションAPIをコールして、リコンシリエーション・イベントを送信します。バッチ・サイズが適合する場合、イベントは、リコンシリエーション・エンジンによりバッチで処理されます。バッチ・サイズが適合しないバッチについては、スケジュール済タスクが定期的に実行され、リコンシリエーション処理のバッチが送信されます。

プルまたはプッシュ・モデルは、ターゲット・システムの性質およびターゲット・システムでの変更の検出方法に基づいて使用されます。しかし、使用されるプッシュまたはプル・モデルに関係なく、リコンシリエーションは、IAMスケジューラで実行されるスケジュール済タスクを使用して実行されます。

注意:

リコンシリエーション・イベントは、リコンシリエーションAPIを使用して直接作成することもできます。

変更ログ・リコンシリエーションは、デフォルトのリコンシリエーション・モードです。このモードでは、変更された属性のみがリコンサイルされます。未指定のフィールドは無視されます。変更された属性のリストをコネクタが認識する場合は、通常、変更ログ・リコンシリエーション・モードを使用します。変更された属性に加えて、Oracle Identity Managerには、照合に必要なフィールドのリストも必要です。Oracle Identity Managerの以前のリリースでは変更ログ・リコンシリエーションをサポートしていたため、すべてのコネクタはこのモードで動作します。

標準リコンシリエーションは、リコンシリエーション・エンジンがエンティティの既存のスナップショットを完全に置換する、このリリースで導入された新しいリコンシリエーション・モードです。通常、このリコンシリエーション・モードは、変更された属性をコネクタで判断できない場合に使用するため、エンティティの完全なスナップショットを送信します。新しいコネクタの場合、このモードは、完全リコンシリエーションを実行する場合に指定できます。標準リコンシリエーション・モードを使用すると、イベントがより速やかに処理されるため、パフォーマンスが向上します。

注意:

リコンシリエーションのモードは、コネクタの実装によって異なります。コネクタ情報の詳細は、「リコンシリエーションのコネクタ」を参照してください。

表4-2に、標準リコンシリエーション・モードと変更ログ・リコンシリエーション・モードの相違を示します。

表4-2 標準リコンシリエーション・モードと変更ログ・リコンシリエーション・モード

標準

変更ログ

マップされた属性の完全なセットを渡す必要があります。

特定のプロファイルやルールの照合に必要なマップされた属性のサブセットを渡す必要があります。

バッチ処理モードでの実行に適しています(単一のイベント処理モードの場合とパフォーマンスに違いはない)。

すべてのフィールドが作成および更新されます。

指定されたフィールドのみが作成および更新され、その他のフィールドはすべて変更されません。

関連項目:

リコンシリエーション・モードの変更の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのプロファイル・モードの変更に関する項を参照してください。

4.2.1.3 リコンシリエーションに使用されるアプローチ

ターゲット・システムで初めてリコンシリエーションを実行すると、デフォルトでは、ターゲット・システムのすべてのユーザーおよびアカウントがOracle Identity Managerにリコンサイルされます。これは、完全リコンシリエーションと呼ばれます。完全リコンシリエーションを実行するために、コネクタはターゲット・システムの各エンティティに対してリコンシリエーション・イベントを送信します。リコンシリエーション・エンジンでは、そのエンティティがOracle Identity Managerにすでに存在するかしないかに応じて、イベントを作成イベントまたは更新イベントとして処理します。また、コネクタは、削除されたすべてのエントリを識別し、削除イベントをOracle Identity Managerに送信します。

通常は完全リコンシリエーションの終了時に、コネクタが最終実行時間パラメータをリコンシリエーションの実行の終了時間に設定します。リコンシリエーションの次回実行では、リコンシリエーションの初回実行の終了後に追加、変更または削除されたエンティティのレコードのみが、リコンシリエーション対象としてフェッチされます。これは、増分リコンシリエーションと呼ばれます。

タイムスタンプITリソース・パラメータを0の値に設定することで、増分リコンシリエーションから完全リコンシリエーションに手動で切替えできます。

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

リコンシリエーションは、2つのシステム間のエンティティ・データが整合性のある状態で維持されるように、エンティティ・データをターゲット・システムからOracle Identity Managerに取得するプロセスです。図4-7に、リコンシリエーションに関係するOracle Identity Managerの様々なコンポーネント、およびこれらのコンポーネント間の相互作用を示します。

図4-7 リコンシリエーションのアーキテクチャ

「図4-7 リコンシリエーションのアーキテクチャ」の説明

リコンシリエーションのアーキテクチャを次のステップで説明します。

1. 各コネクタには、スケジュール済タスクが関連付けられます。スケジューラがコネクタのスケジュール済タスクをトリガーし、このタスクによってイベントを生成するためのリコンシリエーションAPIが起動されます。イベントのタイプは、標準、変更ログまたは削除のいずれかです。スケジューラの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。スケジュール済タスクの詳細は、「リコンシリエーションのコネクタ」を参照してください。

2. リコンシリエーション・イベントがリコンシリエーション・イベント・リポジトリ(Oracle Identity Managerデータベース)に格納されます。

3. バッチ・サイズが適合する場合は、イベントのバッチをまとめて処理する非同期メッセージが送信されます。スケジュール済タスクの終了時に、最後のバッチのイベントを処理する目的で、別の非同期メッセージが送信されます。

注意:

- 図4-7では、リコンシリエーション・エンジンがアクションJAVAレイヤーおよびリコンシリエーション・イベント・リポジトリの一部をカプセル化し、この図の矢印のすべてをオーケストレートしています。

- このリリースでは、信頼できるソース・リコンシリエーションはユーザーに対してのみサポートされています。ロール、ロール・メンバーシップおよびロール階層のリコンシリエーションはサポートされていません。

- このリリースのOracle Identity Managerでは、組織に対して、信頼できるソース・リコンシリエーションとアカウント・リコンシリエーションがサポートされています。

4. 処理には、データの検証、エンティティの照合およびアクション(作成、更新、削除など)が含まれます。その後、カーネル・オーケストレーションを介した後処理が続きます。アクション・モジュールの詳細は、「アクション・モジュール」を参照してください。リコンシリエーション・プロファイルの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの新しいメタデータ・モデル - プロファイルに関する項を参照してください。

5. デフォルトでは、リコンシリエーションのイベント処理は大量に発生するため、後処理までのすべてのステップは、PL/SQLストアド・プロシージャで実行されます。次のシナリオでは、イベントを1度に1つずつ処理できます(この場合、照合までのすべてのステップはPL/SQLで処理され、アクションはJavaレイヤーで実行されます)。

- イベントがリコンシリエーション管理コンソールから処理される場合

- 失敗したイベントが、定期的に実行される再試行のスケジュール済タスクによって再試行される場合

単一のイベントを処理するリコンシリエーションの場合、アクションおよび後処理はカーネル経由で実行されます。

6. リコンシリエーション・イベントは、リコンシリエーション管理サービスの別のAPIコールによって、リコンシリエーション管理コンソールに対して使用可能になります。

リコンシリエーション・サービスの様々なコンポーネントの機能は、次の各項を参照してください。

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

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

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

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

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

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

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

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

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

- アーカイブ

- 下位互換性

- リコンシリエーション・マネージャ

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

リコンシリエーション・プロファイルは、特定のリソースに対するリコンシリエーションの実行方法を管理するために定義された構成です。特定のリソースに複数のリコンシリエーション・プロファイルを指定し、それぞれに照合ルール、アクション・ルールおよびフィールド・マッピングを定義し、その際、リソースに対応する各プロファイルには異なる定義を指定できます。たとえば、削除を1日1回のみ実行する必要がある場合は、一方のリコンシリエーションの実行で新規および変更されたアカウントのリコンシリエーションを実行し、もう一方のリコンシリエーションの実行でアカウントの削除をリコンサイルできます。この例では、2つのリコンシリエーション実行と2つのプロファイルを定義します。各プロファイルはそれぞれのリコンシリエーションの実行に関連付けられ、各プロファイルには独自のリコンシリエーション・ルールがあります。

プロファイルはXMLベースの構成ファイルで、Oracle Identity Manager MetaData Store (MDS)に格納されます。

リソース・オブジェクトには、リコンシリエーション構成に関連付けられたデフォルトのプロファイルが常に存在します。デフォルトのプロファイルは、開発者の環境のOracle Identity Manager Design Consoleから明示的に生成するか、デプロイメント・マネージャからのインポート時に暗黙的に生成できます。プロファイルの作成方法および更新方法の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・イベントの管理に関する項を参照してください。

4.2.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管理者ガイドのリコンシリエーション・イベントの管理に関する項を参照してください。

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

リコンシリエーション・ターゲットとは、Oracle Identity Managerの変更のソースとして機能するアプリケーションのインスタンスです。リコンシリエーション・ターゲットの例には、Oracle Identity Managerのアイデンティティのソースとして機能する人事管理システムがあります。リコンシリエーション・ターゲットのソースは、ユーザーまたはアカウントのいずれかです。

4.2.2.4 リコンシリエーション実行

リコンシリエーション実行とは、リコンシリエーション・コネクタと関連する構成の組合せを意味し、スケジュール済タスクによって実行される場合は、関連する構成に定義されているルールに基づいてリコンシリエーションを実行します。スケジューラは、リコンシリエーションを固定間隔で定期的に実行します。リコンシリエーション実行はOracle Identity Managerのスケジューラでスケジュールされ、指定した頻度で実行されます。リコンシリエーション実行時に作成されたすべてのイベントは、一意のリコンシリエーション実行IDに従ってグループ化されます。

4.2.2.5 リコンシリエーションAPI

リコンシリエーションAPIは、リコンシリエーション・データをリコンシリエーション・イベントの形式でOracle Identity Managerに提供するために公開された一連のAPIです。コネクタは、このAPIを使用して、リコンシリエーション・イベント・リポジトリにデータをプッシュできます。リコンシリエーションをスケジュールに従って実行する場合は、APIを実行するスケジュール済タスクを設定できます。既存のAPIがサポートされているため、既存のコネクタを変更する必要はありません。

4.2.2.6 リコンシリエーション・スキーマ

リコンシリエーション用にターゲット・システムから受け取ったデータは、リコンシリエーション・スキーマに格納されます。このデータには、Oracle Identity Managerとリコンサイルする変更も含まれています。

リコンシリエーション・スキーマとは、リコンシリエーション・データを格納する一連のスキーマ表です。リコンシリエーション・スキーマは、パフォーマンス上の理由および将来の拡張性に備えて再設計されています。リコンシリエーション・スキーマの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの改善されたデータベース・スキーマに関する項を参照してください。

4.2.2.7 リコンシリエーション・エンジン

リコンシリエーション・エンジンでは、構成可能なすべてのコンポーネントが使用され、これらのコンポーネントを使用して入力データをアクション・アイテムのリストに変換するデータ・プロセッサとルール・エバリュエータが組み込まれています。ルールのコンテキストに基づいてアクションを自動化できるかどうかを判断するコンポーネントも組み込まれています。アクションが自動または手動で実行されると、エンジンは適切な更新とプロビジョニング・アクションを実行します。

リコンシリエーション・エンジンのメイン・タスクは、比較を実施して、実行するアクションを判断し、そのアクションをOracle Identity Managerで適用することです。2つのモジュールがあり、各モジュールについては、次の各項で説明します。

- 照合モジュール

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

4.2.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内で検出された考えられる適合すべてが格納され、イベントの状態は表4-3に示すいずれかのステータスに更新されます。

表4-3 リコンシリエーションのステータス・イベント

ステータス・イベント

説明

データを受信しました

イベント・データがデータベースに作成され、次の処理に対する準備が整っています。

イベントを受信しました

リコンシリエーション・イベントが作成され、次の処理に対する準備が整っています。finishReconciliationEvent APIはコールされていません。

データ検証に失敗しました

リコンシリエーション・イベント・レコードは無効です。たとえば、ロール・カテゴリが無効なロール・イベントは検証に失敗します。(この状況は競合状態を示している可能性があります。)RE_NOTEフィールドには失敗の詳細が表示され、ユーザー・インタフェースにも表示されます。

データ検証に成功しました

イベント・データが正常に検証され、イベントはエンジンで支障なく処理できます。

複数のアカウントの一致が見つかりました

現在の照合ルールでは、データと一致する複数のアカウント・レコードが見つかりました。

アカウントの一致が見つかりません

現在の照合ルールでは、データと一致するアカウント・レコードは見つかりません。

単一のアカウントの一致が見つかりました

現在の照合ルールでは、データと一致する単一のアカウント・レコードが見つかりました。

複数の組織の一致が見つかりました

現在の照合ルールでは、データと一致する複数の組織レコードが見つかりました。

組織の一致が見つかりません

現在の照合ルールでは、データと一致する組織レコードは見つかりません。

単一の組織の一致が見つかりました

現在の照合ルールでは、データと一致する単一の組織レコードが見つかりました。

複数のロール付与の一致が見つかりました

ロール内のユーザー・メンバーシップと一致する複数のレコードが見つかりました。

ロール付与の一致が見つかりません

ロール内のユーザー・メンバーシップと一致するレコードは見つかりません。

単一のロール付与の一致が見つかりました

ロール内のユーザー・メンバーシップと一致する単一のレコードが見つかりました。

複数のロールの一致が見つかりました

現在の照合ルールでは、データと一致する複数のロール・レコードが見つかりました。

ロールの一致が見つかりません

現在の照合ルールでは、データと一致するロール・レコードは見つかりません。

単一のロールの一致が見つかりました

現在の照合ルールでは、データと一致する単一のロール・レコードが見つかりました。

ロール・メンバーが見つかりませんでした

現在の照合ルールでは、データと一致するロール・メンバーは見つかりません。

ロールの親が見つかりません

現在の照合ルールでは、データと一致するロールは見つかりません。

複数のロール関係の一致が見つかりました

現在の照合ルールでは、イベントのデータと一致する複数のロール対ロールの関係が見つかりました。

ロール関係の一致が見つかりません

現在の照合ルールでは、イベントのデータと一致するロール対ロールの関係は見つかりません。

単一のロール関係の一致が見つかりました

現在の照合ルールでは、イベントのデータと一致する単一のロール対ロールの関係が見つかりました。

複数のユーザーの一致が見つかりました

現在の照合ルールでは、データと一致する複数のユーザー・レコードが見つかりました。

ユーザーの一致が見つかりません

現在の照合ルールでは、データと一致するユーザー・レコードは見つかりません。

単一のユーザーの一致が見つかりました

現在の照合ルールでは、データと一致する単一のユーザー・レコードが見つかりました。

無効なイベント・データが渡されました

イベントに無効なデータが含まれています。このステータスは、電子メール属性に関係があります。

再評価中です

リコンシリエーション・イベントは、現在、リコンシリエーション管理コンソールで再評価されています。

再試行中です

リコンシリエーション・イベントは、現在、自動的に再試行されています。このステータス・イベントはすでに廃止されています。

作成に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に作成されていません。

作成に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に作成されました。

削除に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に削除されていません。

削除に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に削除されました。

イベントがクローズされました

リコンシリエーション・イベントは、リコンシリエーション管理コンソールからクローズされました。変更は完了しています。

更新に失敗しました

ユーザー、アカウントまたはロールのエンティティが、正常に更新されていません。

更新に成功しました

ユーザー、アカウントまたはロールのエンティティは、正常に更新されました。

4.2.2.7.2 アクション・モジュール

このモジュールでは、表4-4に示すように、イベントの状態、エンティティ・タイプおよびアクション・ルールに基づいてアクションが適用されます。

表4-4 アクション・ルール

イベントの状態

エンティティ・タイプ

アクション

説明

ユーザーの一致が見つかりません

ユーザー

アクションなし

アクションは実行されません。

ユーザーの作成

Oracle Identity Managerのユーザーを作成します。

アカウントの一致が見つかりません

アカウント

アクションなし

アクションは実行されません。

単一のユーザーが一致しました

ユーザーまたはアカウント

アクションなし

アクションは実行されません。

ユーザー

リンクの確立

変更タイプに基づいて一致したユーザーを変更または削除します。

アカウント

リンクの確立

所有者が識別され、アカウントが作成されます。

複数のユーザーが一致しました

ユーザーまたはアカウント

アクションなし

アクションは実行されません。

単一のアカウントが一致しました

アカウント

アクションなし

アクションは実行されません。

リンクの確立

変更タイプに基づいてアカウントを変更または失効します。

複数のアカウントが一致しました

アクションなし

アクションは実行されません。

ロールの一致が見つかりません

ロール

アクションなし

アクションは実行されません。

単一のロールの一致が見つかりました

ロール

アクションなし

アクションは実行されません。

リンクの確立

ロールを変更または削除します。

ロール・メンバーシップ

ロール・メンバーシップの作成

ロール・メンバーをOracle Identity Managerに付与します。

ロール・メンバーシップの削除

ロール・メンバーをOracle Identity Managerから削除します。

アクションなし

アクションは実行されません。

ロール階層

ロール階層の作成

Oracle Identity Managerにロール階層を作成します。

ロール階層の削除

Oracle Identity Managerのロール階層を削除します。

アクションなし

アクションは実行されません。

複数のロールが一致しました

ロール、ロール・メンバーシップおよびロール階層

アクションなし

アクションは実行されません。

ロール付与の一致が見つかりません

ロール・メンバーシップ

アクションなし

アクションは実行されません。

ロール・メンバーの作成

Oracle Identity Managerにロール・メンバーを作成します。

単一のロール付与の一致が見つかりました

ロール・メンバーシップ

アクションなし

アクションは実行されません。

リンクの確立

ロール・メンバーを削除します。

複数のロール付与の一致が見つかりました

ロール・メンバーシップ

アクションなし

アクションは実行されません。

注意: ロール付与の照合は主キー(ユーザー・キーとグループ・キーの組合せ)を検索することで処理されるため、この状態は発生しません。

ロールの親の一致が見つかりません

ロール階層

アクションなし

アクションは実行されません。

ロールの親の作成

Oracle Identity Managerにロールの親を作成します。

単一のロールの親の一致が見つかりました

ロール階層

アクションなし

アクションは実行されません。

リンクの確立

ロールの親を削除します。

複数のロールの親の一致が見つかりました

ロール階層

アクションなし

アクションは実行されません。

データ検証に失敗しました

ロール、ロール階層、ロール・メンバー

競合状態

アクションは実行されません。イベントを再評価する必要があります。

親ロールが見つかりません

ロール階層

競合状態

アクションは実行されません。イベントを再評価する必要があります。

ロール・メンバーが見つかりません

ロール・メンバーシップ

競合状態

アクションは実行されません。イベントを再評価する必要があります。

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

この項では、コネクタ表およびリコンシリエーション表に必要な索引を指定してパフォーマンスを向上させる方法について説明します。内容は次のとおりです。

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

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

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

Oracle Identity Managerをインストールすると、必要な索引がOracle Identity Managerデータベース・スキーマに作成されます。ただし、Oracle Identity Managerのいくつかの機能の動的な性質のために、追加の索引が必要になる場合があります。これは、特にリコンシリエーションに当てはまります。

リコンシリエーションでは、照合アルゴリズムを使用して、変更がリクエストされたユーザー、アカウント、ロールまたは組織がOracle Identity Managerにすでに存在するかどうかが検索されます。照合アルゴリズムでは、Oracle Identity Managerの一連の列のデータとターゲット水平表の列のデータが比較されます。照合ルールを格納する列は、リコンシリエーション・プロファイルに定義されます。照合操作のパフォーマンスを迅速に改善するためには、照合ルールの列に正しい索引が作成されている必要があります。

適切な索引を識別する推奨方法を示すために、メタデータ・ストア(MDS)リポジトリに存在するサンプルActive Directory (AD)ユーザー・プロファイルを例として取り上げます。この例では、信頼できるソース・リコンシリエーションおよびターゲット・リソースのリコンシリエーションについて説明します。

信頼できるソース・リコンシリエーションに対する索引の選択

信頼できるソースおよびターゲット・リソースのリコンシリエーションで、照合ルール基準に基づいて索引を選択する手順は、次のとおりです。

1. テキスト・エディタでADユーザーのプロファイル・ファイルを開きます。

注意:

ADユーザーのプロファイルは、MDSユーティリティを使用してMDSからインポートする必要があります。MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティとユーザーが修正可能なメタデータ・ファイルに関する項を参照してください。

2. 次のコード・サンプルに表示されているように、すべてのエンティティを対象としてownerMatchingRuleWhereClauseを検索します。

次に、ownerMatchingRuleWhereClauseを示します。

ownerMatchingRuleWhereClause = (((UPPER(USR.USR_LOGIN)=UPPER(RA_ADUSER7.RECON_USERID5A729570)) OR (UPPER(USR.USR_UDF_OBGUID)=UPPER(RA_ADUSER7.RECON_OBJECTGUID))))

3. ユーザー・エンティティの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。

注意:

- キー・フィールドがOracle Identity Managerで大/小文字を区別しないように定義されている場合は、そのキー・フィールドに対して関数ベースの索引を作成する必要があります。たとえば、コネクタ・コードで姓名の名の検索を内部的に実行する場合(FIRST_NAMEがキーの場合)は、適切な索引付けが必要です。

- ユーザーの参照で複数のキーまたはコンポジット・キーが使用される場合は、個々の索引またはコンポジット索引を選択します。

ターゲット・リソースのリコンシリエーションに対する索引の選択

ターゲット・リソースのリコンシリエーションで、照合ルール基準に基づいて索引を選択する手順は、次のとおりです。

1. テキスト・エディタでADユーザーのプロファイル・ファイルを開きます。

注意:

ADユーザーのプロファイルは、MDSユーティリティを使用してMDSからインポートする必要があります。MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティとユーザーが修正可能なメタデータ・ファイルに関する項を参照してください。

2. 次の図に表示されているように、アカウント検索タグ<matchingruleWhereClause>を検索します。

次に、<matchingruleWhereClause>を示します。

<matchingruleWhereClause>((UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSER7.RECON_OBJECTGUID))</matchingruleWhereClause>

3. ユーザー・エンティティの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。

複数値データがあるターゲット・リソースのリコンシリエーションに対する索引の選択

複数値データがあるターゲット・リソースのリコンシリエーションで、照合ルール基準に基づいて索引を選択する手順は、次のとおりです。

1. テキスト・エディタでADユーザーのプロファイル・ファイルを開きます。

注意:

ADユーザーのプロファイルは、MDSユーティリティを使用してMDSからインポートする必要があります。MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティとユーザーが修正可能なメタデータ・ファイルに関する項を参照してください。

2. 権限について、<childreconeventdata>の下にある<matchingruleWhereClause>タグを検索します。

次に、<matchingruleWhereClause>タグを示します。

<matchingruleWhereClause>((UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_UD_ADUSRC.RECON_MEMBEROF))</matchingruleWhereClause>

3. ユーザー・エンティティの照合ルールを構成する列を識別した後は、それに応じて索引を作成します。

注意:

必要な索引のポインタは、Oracle Enterprise Managerコンソールなどのパフォーマンス・モニタリング・ツールを使用するか、またはOracle Database 11gで使用可能な自動ワークロード・リポジトリ(AWR)のレポートを介して、データベース側からリコンシリエーション・プロセスのリアルタイム実行を監視することで取得することもできます。

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

データベース統計は、SQL問合せの実行時にOracleオプティマイザが最適な計画を選択するために不可欠な情報です。Oracle Identity Managerスキーマの統計は、定期的に収集することをお薦めします。Oracle Identity Manager 11g リリース1 (11.1.1)では、リコンシリエーション・プロセスに多数のデータベース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計画が消去され、さらに効率的な新しい計画が作成されるに従って、パフォーマンスは向上します。

4.2.2.9 リコンシリエーションのコネクタ

コネクタとは、ターゲット・システムから変更を抽出し、リコンシリエーションAPIをコールしてリコンシリエーション・スキーマにイベントを作成するソフトウェアです。使用するコネクタが事前定義済リコンシリエーション・モジュールに付属している場合は、スケジュール済タスク定義を使用できます。このコンポーネントを使用して、データおよび他のコネクタ固有のパラメータをトラッキングするために、ターゲット・システムで変更がポーリングされる頻度を制御します。

リコンシリエーションのコネクタは、デプロイメント・マネージャを使用してデプロイされます。コネクタがデプロイされると、そのコネクタの対応するリコンシリエーション・プロファイルがメタデータ・ストア(MDS)に作成され、イベント・データを格納する水平表も作成されます。

注意:

リコンシリエーションの実行中は、リコンシリエーション・プロファイルを手動で更新したり、デプロイメント・マネージャまたはOracle Identity Manager Design Consoleからリコンシリエーション構成を更新しないでください。これは、リコンシリエーションの実行中にリコンシリエーション・フィールドが削除または更新されると、イベント・データが無効になる可能性があるためです。

コネクタの構成の詳細は、Oracle Identity Managerのコネクタのドキュメントを参照してください。

関連項目:

- MDSの詳細は、「リコンシリエーション・メタデータ」を参照してください。

- 水平表の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの水平表に関する項を参照してください。

4.2.2.10 アーカイブ

リコンシリエーション・アーカイブ・ユーティリティを使用すると、処理したイベントをアーカイブ・リコンシリエーション表からアーカイブ表に移動できます。移動するイベントは、時間の範囲に基づいて選択できます。アーカイブできるのは、リンクしたイベントおよびクローズしたイベント(つまり、正常に処理されたか、管理者がクローズしたイベント)のみです。

関連項目:

リコンシリエーション・アーカイブ・ユーティリティの使用方法は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・アーカイブ・ユーティリティの使用に関する項を参照してください。

4.2.2.11 下位互換性

新規のリコンシリエーション・サービスを活用するために、既存のリコンシリエーション構成またはスケジュール済タスクを変更する必要はありません。

Oracle Identity Managerの以前のリリースでのリコンシリエーション設定に関する既存の構成は、11g リリース1 (11.1.1)にアップグレードした後も引き続き機能します。アップグレードの一環として、リコンサイル対象の既存のオブジェクト・タイプごとに、対応するリコンシリエーション・イベントの表が作成されます。

4.2.2.12 リコンシリエーション・マネージャ

リコンシリエーション・マネージャはWebベースのUIで、Oracle Identity Manager管理およびユーザー・コンソールの一部です。リコンシリエーション・マネージャでは、Oracle Identity Managerリコンシリエーション・エンジンによって生成されたリコンシリエーション・イベントを表示および管理できます。これらのイベントは、スケジュール済リコンシリエーション実行を介して生成されます。リコンシリエーション・マネージャには、リコンシリエーション実行およびイベントの検索機能が用意されています。リコンシリエーション・マネージャを使用すると、生成されたイベントに対してリコンシリエーションを手動で実行できます。

関連項目:

リコンシリエーション・マネージャの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・イベントの管理に関する項を参照してください。

4.3 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 Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

Oracle Identity Managerカーネル・オーケストレーションはエンティティ・マネージャに接続し、そのエンティティ・マネージャがさらにLDAPプロバイダに接続します。LDAPプロバイダはOracle Virtual Directory (OVD)に接続します。OVDは、Oracle Internet Directory、iPlanet、Active Directoryなど、様々なディレクトリ・システムへのインタフェースです。LDAPプロバイダはOVDを使用してLDAPデータにアクセスします。図4-8に、Oracle Identity ManagerとLDAP間の通信を示します。

図4-8 Oracle Identity ManagerとLDAP

「図4-8 Oracle Identity ManagerとLDAP」の説明

Oracle Identity ManagerとLDAPアイデンティティ・ストア間での統合の構成およびデータの同期化の詳細は、次の各項を参照してください。

- LDAPとの統合の構成

- Oracle Identity ManagerからLDAPアイデンティティ・ストアへのデータのプロビジョニング

- LDAPアイデンティティ・ストアからOracle Identity Managerへのリコンシリエーション

4.3.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 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管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。

4.3.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間でのユーザー定義フィールドの同期化に関する項を参照してください。

この項の内容は次のとおりです。

- ユーザーの管理

- ロールの管理

4.3.2.1 ユーザーの管理

Oracle Identity ManagerからLDAPにデータを同期化するには、次のユーザー操作を実行できます。

- ユーザーの作成

- ユーザーの更新

- ユーザーの削除

- ユーザーの有効化

- ユーザーの無効化

- ユーザーのロック

- ユーザーのロック解除

- ロール・メンバーの追加

- ロール・メンバーを削除します。

- パスワードの変更

4.3.2.2 ロールの管理

Oracle Identity ManagerからLDAPにデータを同期化するには、次のロール操作を実行できます。

- ロールの作成

- ロールの更新

- ロールの削除

- メンバーへのロールの追加

- ロールの追加と更新

- メンバーからのロールの削除

- ロール階層の追加

- ロール階層の削除

4.3.3 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と呼ばれるオブジェクト・クラスで更新する必要があります。

バルク・ロード・ユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のバルク・ロード・ユーティリティに関する項を参照してください。

ロールのリコンシリエーションは、LDAPグループでのみ機能します。ロールのリコンシリエーションでは、ロールの作成、更新および削除がサポートされています。ロール・メンバーシップのリコンシリエーションでは、外部のLDAPディレクトリで発生した変更から導出されたロール・メンバーシップの作成と削除がサポートされています。

関連項目:

ロール、ロール・メンバーシップおよびロール階層の詳細は、第12章「ロールの管理」を参照してください。

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ロール・カテゴリ・シーディングを除くこれらすべてのジョブは、変更ログに基づいてリコンシリエーションを実行しますが、完全リコンシリエーション・ジョブは、検索ベースを使用してリコンシリエーションを実行します。

5 統合ソリューション

Oracle Identity Managerでは、3段階の統合ソリューション方式を採用し、様々な異種アイデンティティ認識ITシステムへのコネクタを提供します。この3層の戦略は、最小限のカスタム開発、最大限のコード再利用、および開発時間の短縮を目的としています。この3つの層を次に示します。

- 事前定義済コネクタと事前定義済汎用テクノロジ・コネクタのプロバイダを使用する基本設定の統合

- カスタムの汎用テクノロジ・コネクタのプロバイダに基づいたコネクタ

- アダプタ・ファクトリを使用するカスタム・コネクタ

図5-1に、Oracle Identity Managerの3段階の統合ソリューション方式を示します。

図5-1 Oracle Identity Managerの3段階の統合ソリューション方式

「図5-1 Oracle Identity Managerの3段階の統合ソリューション方式」の説明

この章では、次の項目について説明します。

- 事前定義済コネクタ

- 汎用テクノロジ・コネクタ

- カスタム・コネクタ

- すべてのコネクタに共通するコンポーネント

- コネクタのインストール

5.1 事前定義済コネクタ

ターゲット・リソースで事前定義済コネクタを使用できる場合、推奨される統合方法は事前定義済コネクタによる統合です。事前定義済コネクタはターゲット・アプリケーション専用に設計されているため、最も迅速な統合方法となります。これらのコネクタは、Oracle eBusiness Suite、PeopleSoft、Siebel、JD EdwardおよびSAPなどの一般的なビジネス・アプリケーションの他、Active Directory、Java Directory ServerおよびUNIXの各データベース、RSA ClearTrustなどのテクノロジ・アプリケーションもサポートします。事前定義済コネクタは、ターゲット・アプリケーション専用に設計されているため、最も迅速な統合の選択肢です。このコネクタはターゲットの推奨される統合テクノロジを使用し、アプリケーション固有の属性によって事前に構成されています。

関連項目:

事前定義済コネクタのインストールの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの事前定義済のスケジュール済タスクに関する項を参照してください。

5.2 汎用テクノロジ・コネクタ

事前定義済コネクタと同様に、汎用テクノロジ・コネクタは、Oracle Identity Managerとターゲット・システムの間でリコンシリエーションおよびプロビジョニング操作を仲介する役割を担います。機能面から見ると、汎用テクノロジ・コネクタは、リコンシリエーション・モジュールとプロビジョニング・モジュールに分けられます。汎用テクノロジ・コネクタを作成する際には、リコンシリエーション・モジュールとプロビジョニング・モジュールをともに組み込むか、どちらか一方のみ組み込むかを指定できます。

GTCフレームワークには基本コンポーネントが用意されており、これらのコンポーネントを使用してカスタム・コネクタを迅速に作成できます。汎用テクノロジ・コネクタのリコンシリエーション・モジュールおよびプロビジョニング・モジュールは、選択したこれらの再使用可能コンポーネントで構成されます。それぞれのコンポーネントでは、プロビジョニング時またはリコンシリエーション時に、特定の機能が実行されます。次のコンポーネントがあります。

- リコンシリエーション:

- リコンシリエーション・トランスポート・プロバイダ: このプロバイダは、リコンサイルされたデータをターゲット・システムからOracle Identity Managerに移動します。

- リコンシリエーション・フォーマット・プロバイダ: このプロバイダは、ターゲット・システムから受け取った、リコンサイル済データが含まれているメッセージを、Oracle identity Managerのリコンシリエーション・エンジンで解釈できるデータ構造に解釈します。

- 検証プロバイダ: このプロバイダは、受け取ったデータをリコンシリエーション・エンジンに渡す前にそのデータを検証します。

- プロビジョニング:

- プロビジョニング・フォーマット・プロバイダ: このプロバイダは、Oracle identity Managerのプロビジョニング・データを、ターゲット・システムでサポートされているフォーマットに変換します。

- プロビジョニング・トランスポート・プロバイダ: このプロバイダは、受け取ったプロビジョニング・メッセージをプロビジョニング・フォーマット・プロバイダからターゲット・システムに伝播します。

図5-2は、汎用テクノロジ・コネクタの機能アーキテクチャを示しています。

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

「図5-2 汎用テクノロジ・コネクタの機能アーキテクチャ」の説明

関連項目:

汎用テクノロジ・コネクタの機能アーキテクチャ、構成および機能性の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

汎用テクノロジ・コネクタには、次の機能があります。

- 次の機能は、リコンシリエーション・モジュールに固有のものです。

- 信頼できるソース・リコンシリエーションでの汎用テクノロジ・コネクタ: 汎用テクノロジ・コネクタは、信頼できるソース・リコンシリエーションに使用できます。信頼できるモードのリコンシリエーションでは、リコンシリエーション・エンジンで新規のターゲット・システム・アカウントが検出されると、対応するOIMユーザーが作成されます。リコンシリエーション・エンジンでは、既存のターゲット・システム・アカウントに対する変更が検出されると、対応するOIMユーザーに同様の変更が行われます。

- アカウント・ステータスのリコンシリエーションでの汎用テクノロジ・コネクタ: ユーザー・アカウント・ステータス情報は、ターゲット・システム・アカウントの所有者によるアカウントへのアクセスおよびアカウントの使用が許可されるかどうかのトラッキングに使用されます。Oracle identity Managerに格納されている形式のアカウント・ステータス情報がターゲット・システムに格納されていない場合は、事前定義済の翻訳変換プロバイダを使用して、アカウント・ステータスのリコンシリエーションを実装できます。

- 完全リコンシリエーションまたは増分リコンシリエーションでの汎用テクノロジ・コネクタ: 汎用テクノロジ・コネクタを作成する際に、コネクタを完全リコンシリエーションまたは増分リコンシリエーションに使用するように指定できます。増分リコンシリエーションでは、最後のリコンシリエーション実行後に変更されたターゲット・システムのレコードのみがOracle Identity Managerでリコンサイル(格納)されます。完全リコンシリエーションでは、すべてのリコンシリエーション・レコードがターゲット・システムから抽出されます。

- バッチ・リコンシリエーションの汎用テクノロジ・コネクタ: リコンシリエーション・プロセスを詳細に制御するために、汎用テクノロジ・コネクタを使用してリコンシリエーションのバッチ・サイズを指定できます。これにより、リコンシリエーション実行中にリコンシリエーション・エンジンがターゲット・システムからフェッチするレコードの総数をバッチに分割できます。

- 複数値属性データ(子データ)の削除のリコンシリエーションでの汎用テクノロジ・コネクタ: ターゲット・システムの複数値属性データの削除をOracle Identity Managerでリコンサイルするかどうかを指定します。

- リコンシリエーション停止の失敗しきい値での汎用テクノロジ・コネクタ: リコンシリエーションの実行時に、ターゲット・システムデータをOracle Identity Managerに格納する前に、検証プロバイダを使用してデータのチェックを実行できます。失敗しきい値を設定しておくと、検証チェックに通らなかったレコードの処理済レコードの総数に対する割合が指定のしきい値を超えた場合に、リコンシリエーションの実行を自動的に停止できます。

- 汎用テクノロジ・コネクタには、その他に次の機能があります。

- カスタム・プロバイダ: Oracle Identity Managerに付属の事前定義済プロバイダが、動作環境のトランスポート、フォーマット変更、検証または変換についての要件に対応していない場合は、カスタム・プロバイダを作成できます。

- 多言語サポート: 汎用テクノロジ・コネクタは、ASCIIとASCII以外の両方の形式のユーザー・データを処理できます。

- カスタム日付書式: 汎用テクノロジ・コネクタの作成時は、リコンシリエーション実行中に抽出されたターゲット・システム・レコードの日付の値の書式と、プロビジョニング実行中にターゲット・システムに送信する必要がある日付の値の書式を指定できます。

- OIMユーザー属性に対する変更のターゲット・システムへの伝播: 汎用テクノロジ・コネクタの作成時に、OIMユーザー属性に対する変更が自動的にターゲット・システムに伝播されるように設定できます。

5.3 カスタム・コネクタ

ターゲット・リソースにテクノロジ・インタフェースまたはアクセス可能なユーザー・リポジトリがない場合、顧客はカスタム・コネクタを作成できます。Oracle Identity Manager Design Consoleのアダプタ・ファクトリ・ツールには定義ユーザー・インタフェースがあり、これを使用すると、コーディングやスクリプトを作成せずに、このようなカスタム開発を簡単に実現できます。

関連項目:

アダプタ・ファクトリを使用したアダプタの定義方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のアダプタに関する項を参照してください。

5.4 すべてのコネクタに共通するコンポーネント

表5-1に、コネクタXMLファイルに含まれるコネクタ・コンポーネントの定義を示します。これらは、すべてのコネクタに共通するコンポーネントです。

表5-1 コネクタ・コンポーネント

コンポーネント

説明

リソース・オブジェクト

これは、アカウントをプロビジョニングするターゲット・アプリケーションの仮想表現です。プロビジョニング・プロセスおよびプロセス・フォームを関連付ける親レコードです。

プロビジョニング・プロセス

このプロセス定義は、ターゲット・システムでアカウントを作成、メンテナンスおよび削除するために使用されます。ターゲット・システムで自動機能を実行するために使用される個々のタスクの定義で構成されます。各コネクタには、単一のプロビジョニング・プロセスがパッケージ化されます。プロビジョニング・プロセスは、手動で追加作成できます。

注意: プロビジョニング・プロセスの詳細は、表5-2および表5-3を参照してください。

プロセス・フォーム

このフォームは、ターゲット・システムで作成、更新または削除されるユーザー・アカウントに関する情報を指定するために使用されます。また、プロビジョニング・プロセス・タスクで使用されるデータを取得するため、またはリアルタイム・データを示すメカニズムをユーザーに提供するためにも使用されます。

このフォームは、リコンシリエーションを実行するときに広範に使用されます。このフォームに関連付けられた表構造により、ターゲット・システムのユーザー・アカウントをアーカイブおよび監査できます。

各プロセス・フォームは、標準のコネクタに必要なフィールド定義で構成されます。その他のフィールドが必要な場合は、別のバージョンのフォームを作成して、必要なフィールドを追加できます。

各コネクタには、特定のデフォルト・プロセス・フォームが同梱されています。プロセス・フォームは、手動で追加作成できます。

ITリソース・タイプ

このコンポーネントは、コネクタに関連付けられたすべてのITリソース定義のテンプレートです。ITリソース・タイプは、その特定のITリソース・タイプのすべてのITリソース・インスタンス(サーバー、コンピュータなど)に共通するパラメータを指定します。

この定義に指定されているパラメータは、該当するタイプのすべてのITリソース定義によって継承されます。たとえば、Solaris 8 ITリソース・タイプは、IP Addressというパラメータを保持できます。このパラメータの値は、Target_Solaris ITリソース・インスタンスの場合、192.168.50.25に設定できます。

アダプタ

これには、ターゲット・アプリケーションで共通機能を実行するために必要なすべてのアダプタが含まれます。各アダプタは、特定のマッピングおよび機能とともに事前定義されています。これらのアダプタは、プロビジョニング・プロセスのタスクおよびプロセス・フォームのフィールドと統合できます。

注意: アダプタの詳細は、Oracle Identity Manager Toolsリファレンスを参照してください。

スケジュール済タスク(該当する場合)

使用するコネクタに事前定義済リコンシリエーション・モジュールが同梱されている場合、スケジュール済タスク定義が提供されます。このコンポーネントを使用して、追跡対象データへの変更についてターゲット・システムをポーリングする頻度を管理します。

5.4.1 プロビジョニング・プロセス・タスク

表5-2に、プロビジョニング・プロセス・コンポーネントに含まれる事前定義済タスク(または同等のもの)を示します。

表5-2 プロビジョニング・プロセス・タスク

プロビジョニング・プロセス・タスク

用途

ユーザーの作成

新しいユーザー・アカウントをターゲット・アプリケーションに作成します(ユーザーをアカウントとともにプロビジョニングします)。

ユーザーの無効化

ターゲット・アプリケーションのユーザー・アカウントを一時的に無効にします。

ユーザーの有効化

ターゲット・アプリケーションの無効なユーザー・アカウントを再度有効にします。

ユーザーの削除

ターゲット・アプリケーションのユーザー・アカウントを削除します(ユーザーのアカウントを取り消します)。

ユーザーの更新

ターゲット・アプリケーションのユーザー・アカウントの権限またはプロファイルを変更します。

5.4.2 リコンシリエーション関連プロビジョニング・プロセス・タスク

前の項で示したタスクの他に、プロビジョニング・プロセス・コンポーネントには、リコンシリエーション関連タスクも含まれます。表5-3に、これらのタスクを示します。

注意:

Oracle Identity Managerがリコンシリエーション・イベントを受信すると、プロビジョニング・プロセス内のプロビジョニング関連タスクはすべて抑止され、適切なリコンシリエーション関連タスクが挿入されます。

表5-3 リコンシリエーション関連プロビジョニング・プロセス・タスク

プロビジョニング・プロセス・タスク(リコンシリエーション関連)

用途

リコンシリエーションの挿入を受信しました

このタスクは、ターゲット・システムから受信したリコンシリエーション・イベントがユーザー・アカウントまたは組織アカウントの作成を表すとOracle Identity Managerで判断された場合に、ユーザーまたは組織に関連付けられたプロビジョニング・プロセス・インスタンスに挿入されます。

また、リコンシリエーション・イベント・レコードの情報は、プロビジョニング・プロセスに設定されたマッピングに基づいてプロセス・フォームに格納されます。

リコンシリエーションの更新を受信しました

このタスクは、ターゲット・システムから受信したリコンシリエーション・イベントが既存のユーザー・アカウントまたは組織アカウントの更新を表すとOracle Identity Managerで判断された場合に、ユーザーまたは組織に関連付けられたプロビジョニング・プロセス・インスタンスに挿入されます。

また、リコンシリエーション・イベント・レコードの情報は、プロビジョニング・プロセスに設定されたマッピングに基づいてプロセス・フォームに格納されます。

リコンシリエーションの削除を受信しました

このタスクは、ターゲット・システムから受信したリコンシリエーション・イベントが既存のユーザー・アカウントまたは組織アカウントの削除を表すとOracle Identity Managerで判断された場合に、ユーザーまたは組織に関連付けられたプロビジョニング・プロセス・インスタンスに挿入されます。

5.5 コネクタのインストール

Oracle Identity Managerには、コネクタをインストールするための機能が用意されています。コネクタをインストールする前に対処すべき一般的な考慮事項を次に示します。

- 一部のコネクタには、正常に機能するためにJARファイル形式の外部ライブラリが必要です。これらのJARファイルは、各ベンダーから購入できます。これらのJARファイルを取得したら、必要に応じてOracle Identity Managerを構成してください。たとえば、CLASSPATH環境変数を更新できます。

- 一部のコネクタには、外部ソフトウェアをターゲット・システムにインストールする必要があります。たとえば、Bourne(sh)シェルをSolarisで使用する場合は、WBEM ServicesをターゲットのSolarisコンピュータにインストールして起動する必要があります。そうしないと、Oracle Identity Managerを使用してSolarisのユーザーをプロビジョニングできません。

- 事前パッケージ済コネクタの最適なパフォーマンスを得るには、ターゲット・システムを個別に構成する必要があります。必要な場合は、コネクタのデプロイメント・ガイドにその手順が説明されています。

- Oracle Identity Managerをクラスタ環境にインストールするときは、インストール・ディレクトリの内容をクラスタの各ノードにコピーします。同様に、コネクタのデプロイ・プロセス時にOracle Identity ManagerにコピーするJARファイルはすべて、クラスタの各ノードの対応するディレクトリにコピーする必要があります。

6 監査

Oracle Identity Managerは、監査およびコンプライアンスのために広範囲にわたるデータを収集する強力な監査エンジンを備えています。監査機能を使用して、コンプライアンスの監視、IT中心のプロセスおよびフォレンジック監査のためのエンティティおよびトランザクション・データを収集、アーカイブおよび表示できます。そのため、Oracle Identity Managerでは、監査モジュールおよびコンプライアンス・モジュールを使用して、プロファイル監視機能、レポート機能およびアテステーション機能を提供しています。履歴データは、ライフ・サイクル全体で取得、トランスポート、格納、検索および削除できます。セキュリティは、データのライフ・サイクルの各ステージで維持されます。アテステーション・プロセスの詳細は、「アテステーション・プロセスの管理」を参照してください。

この章は次のトピックで構成されます。

- 概要

- 監査エンジン

- ユーザー・プロファイル監査機能

- ロール・プロファイル監査機能

- 監査機能の有効化と無効化

6.1 概要

ここでは、監査機能の概要について次の各項で説明します。

- 監査の設計要素

- プロファイル監査機能

- 標準レポートとカスタマイズ・レポート

6.1.1 監査の設計要素

図6-1に、Oracle Identity Managerの監査プロセスの設計要素を示します。

図6-1 監査プロセスの設計要素

「図6-1 監査プロセスの設計要素」の説明

Oracle Identity Manager内でユーザーが実行したアクションは、アプリケーション・プログラミング・インタフェース(API)コールまたはメッセージを取得してアクションを処理するメッセージ・ドリブンBean(MDB)に変換されます。1つのアクションから複数の変更が発生することがあります。すべての変更は、1つの監査トランザクションにまとめられます。データ・オブジェクトを変更できるAPIメソッドはそれぞれ、APIコールの最初に監査エンジンのstartTransactionメソッドをコールし、APIコールの最後にendTransactionメソッドをコールします。これにより、監査トランザクションの境界が定義されます。監査エンジンは、トランザクションで行われた変更を識別するためにトランザクションIDを生成します。

6.1.2 プロファイル監査機能

Oracle Identity Managerには、プロファイル情報の監査および履歴のアーカイブが用意されています。プロファイルのスナップショットを取得してデータベースの監査表に格納し、プロファイル・データの変更のたびにスナップショットを更新します。プロファイル監査機能関係では、スナップショットという用語は、データが変更されるたびに作成されるプロファイル・データ全体のコピーを意味します。

6.1.3 標準レポートとカスタマイズ・レポート

BI Publisherには、アーカイブ・データを表示するための標準レポートが付属しています。また、カスタマイズ・レポートを作成することもできます。

レポートの詳細は、次を参照してください。

- レポート機能の使用

- レポートの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のレポートに関する項

6.2 監査エンジン

ユーザー・プロファイル監査は、ユーザー・プロファイルの属性、ユーザー・メンバーシップ、リソース・プロビジョニング、アクセス・ポリシーおよびリソース・フォームに対する変更を対象としています。

監査エンジンは、Oracle Identity Managerの監査情報を収集します。プロファイルが変更されるたびに、監査エンジンは変更(デルタ)を収集してユーザーおよびロールのプロファイルのスナップショットを更新(存在しない場合は生成)し、これらのスナップショットおよびデルタをXML形式で格納します。また、監査エンジンには、生成されたXMLに基づいて関連データをレポート表に移入するポストプロセッサがあります。高いパフォーマンスを維持するため、デフォルトでは、監査エンジンは、アプリケーション・サーバーに装備されている基礎となるJava Message Service(JMS)を使用して、これらのタスクを非同期オフライン方式で実行します。

このセクションのトピックは次のとおりです:

- 監査レベル

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

- 監査メッセージの発行

6.2.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監査レベルは自動的に有効になります。

監査レベルの指定では、大/小文字が区別されます。監査レベルを指定する際は、監査レベルの大/小文字を変更しないでください。

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

監査者に関する情報は、データベース内の次の表に格納されます。

- AUD: この表には、Oracle Identity Managerで定義されたすべての監査者に関するメタデータが格納されます。

- aud_jms: この表には、監査エンジンおよび最終的には監査者が使用するデータが格納されます。操作可能な中間ステージング表です。
この表のキーは、JMSに送信されます。Oracle Identity Managerでは、複数の変更が同じユーザーに加えられたときに、この表を使用して変更順序を制御します。スケジュール済タスクIssue Audit Messages Taskを使用すると、処理されていないメッセージの再発行を自動化できます。このスケジュール済タスクの詳細は、「監査メッセージの発行」を参照してください。

6.2.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属性の値をその分だけ増やすことができます。

6.3 ユーザー・プロファイル監査機能

ユーザー・プロファイル監査は、ユーザー・プロファイルの属性、ユーザー・メンバーシップ、リソース・プロビジョニング、アクセス・ポリシーおよびリソース・フォームに対する変更を対象としています。

このセクションのトピックは次のとおりです:

- 監査用に収集されるデータ

- ユーザー・プロファイル監査に使用されるポストプロセッサ

- ユーザー・プロファイル監査に使用される表

- アーカイブ

6.3.1 監査用に収集されるデータ

Oracle Identity Managerをインストールすると、デフォルトでユーザー・プロファイル監査機能が有効になり、監査レベルは「リソース・フォーム」に設定されます。この監査レベルは、フォーム・データのアテステーションに必要な最低レベルを指定します。

拡張管理のシステム構成部の監査レベルは、XL.UserProfileAuditDataCollectionシステム・プロパティを使用して構成します。

関連項目:

監査レベルの詳細は、「監査レベル」を参照してください。

XL.UserProfileAuditDataCollectionシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する項を参照してください。

このセクションのトピックは次のとおりです:

- ユーザー・プロファイル監査データの取得

- スナップショットの保存

- スナップショット取得のトリガー

6.3.1.1 ユーザー・プロファイル監査データの取得

ユーザー・プロファイルの変更のたびに、Oracle Identity Managerでは、ユーザー・プロファイルのスナップショットを取得してデータベースの監査表に格納します。

また、ユーザー・プロファイルに監査が必要な変更があるときは、たとえ最初のスナップショットが存在しなくても、スナップショットが生成されます。現在のスナップショットが最初のスナップショットとして取り扱われます。

次に、ユーザー・プロファイルの構成要素とこれらの構成要素を格納する表を示します。

注意:

ユーザー・プロファイル表の列名や使用方法などの詳細は、Oracle Identity Managerに付属のスキーマ・ドキュメントを参照してください。

- ユーザー・レコード: USR表(すべてのユーザー定義フィールド(UDF)を含む)に格納されます。
USR表にはユーザー属性が格納されます。ユーザーを作成すると、Oracle Identity Managerにより、この表にエントリが追加されます。

- ユーザー・ロール・メンバーシップ: RUL表、UGP表およびUSG表(表6-1を参照)に格納されます。

表6-1 ユーザー・グループ・メンバーシップの表

表名

説明

RUL

ルール定義を格納します。

UGP

システムのグループおよびロールを定義します。

USG

どのユーザーがどのグループに属するかを定義し、特定のグループのユーザーについてプロパティをリストします。これらのプロパティは、グループにタスク割当てを作成するときに、Oracle Identity Managerによって使用されます。たとえば、優先度が最も高いユーザーにプロセス・タスクを割り当てることができます。さらに、ロールまたはグループがルールを介して付与されている場合は、特定のルールがリストされます。

- ユーザー・ポリシー・プロファイル: 次の表に格納されます。

- UPD: ユーザー・ポリシー・プロファイル・データが格納されます。これは、ユーザーにプロビジョニングされるリソースのポリシー中心の表示です。

- UPP: ユーザー・ポリシー・プロファイル関連の詳細が格納されます。これは、ユーザーに適用可能なすべてのポリシーと、ユーザーが許可または拒否するリソースに関するユーザー中心の表示です。

注意:

管理およびユーザー・コンソールを使用してロール名を変更すると、ユーザーの次のスナップショットまで、データベース内のユーザー・プロファイル監査(UPA)の表にその変更は反映されません。

- ユーザー・リソース・プロファイル: この構成要素は、次のサブ構成要素に分類できます。

- ユーザー・リソース・インスタンス: OBI表、OBJ表およびOIU表(表6-2を参照)に格納されます。

表6-2 ユーザー・リソース・インスタンスの表

表名

説明

OBI

リソース(オブジェクト)インスタンス情報を格納します。Oracle Identity Managerは、リソースがプロビジョニングされるたびにリソース・インスタンスを作成します。このインスタンスには、リソース・キー(リソースがリクエストを介してプロビジョニングされた場合)、対応するプロセス・インスタンス、インスタンス・ステータスなど、プロビジョニングされたインスタンスに関連する一般情報がすべて保存されます。

OBJ

リソース名、自動保存および自動事前移入が設定されているかどうか、リソース・オブジェクトで複数インスタンスを許可するかどうかなど、リソースに関する詳細を含めたリソース・オブジェクト・データを表します。

OIU

プロビジョニングの実行時に、適用可能なユーザー情報をリソース・オブジェクト・インスタンスに関連付けます。さらに、特定のリソース・インスタンスについてポリシー関連情報が保存されます。

- リソース・ライフサイクル(プロビジョニング)プロセス: MIL表、ORC表、OSI表、PKG表、SCH表およびTOS表(表6-3を参照)に格納されます。

表6-3 リソース・ライフサイクル・プロセスの表

表名

説明

MIL

プロセス・タスク定義を定義します。各エントリは1つのプロセス・タスクに相当します。プロセス定義(PKG表)は、複数のタスクで構成され、各タスクは定義の様々なワークフローの一部です。

ORC

プロビジョニングの実行時にプロセス・インスタンス情報を格納します。プロビジョニングが開始すると、Oracle Identity Managerにより、関連するプロセス(またはワークフロー)インスタンスが生成され、プロビジョニング・インスタンスに固有のプロセス関連情報が保存されます。

OSI

プロセス・インスタンスに対して作成されたタスクに関する情報を格納します。

PKG

プロセスまたはワークフローを、プロセス名、プロセス・タイプ、付加フィールド・マッピング、関連するリソースやプロセス・フォームなどのプロセスの詳細も含めて、Oracle Identity Managerに定義します。

SCH

タスク・ステータス、ステータス・バケット、アダプタの実行開始または終了のタイミングなど、特定のタスク・インスタンスの実行に関連する情報を格納します。

TOS

アトミック・プロセス情報を格納します。

- リソース状態(プロセス)フォーム: この情報は、UDの親表および子表に格納されます。UD_*表は、アカウントの状態を格納するユーザー定義フィールドの表です。

6.3.1.2 スナップショットの保存

Oracle Identity Managerでユーザー・プロファイルのスナップショットを取得すると、そのスナップショットはUPA表に格納されます。UPA表の構造は、表6-4に示すとおりです。

表6-4 UPA表の定義

列

データ型

説明

UPA_KEY

NUMBER (19,0)

監査レコードのキー

USR_KEY

NUMBER (19,0)

このエントリにスナップショットが記録されるユーザーのキー

EFF_FROM_DATE

TIMESTAMP (6)

スナップショット・エントリが有効になった日時

EFF_TO_DATE

TIMESTAMP (6)

スナップショット・エントリが無効になった日時

つまり、これは次のスナップショット・エントリが作成された日時です。最新のユーザー・プロファイルを表すエントリの場合、終了日列の値はNULLに設定されます。

SRC

VARCHAR2 (4000)

変更の責任を負うユーザーのユーザーID、および変更の実行に使用されたAPI

SNAPSHOT

CLOB

スナップショットのXML表現

DELTAS

CLOB

スナップショットに対して行われた変更に対応する新旧の値のXML表現

SIGNATURE

CLOB

スナップショットのデジタル署名を格納するために使用できる列(否認防止用)

注意:

Oracle Identity Managerでのデフォルト・ユーザーに対する初期の監査スナップショットはUTF-8エンコードではありません。一方、これらのユーザーに対するその後の変更の監査は、UTF-8エンコード・スナップショットになります。

6.3.1.3 スナップショット取得のトリガー

ユーザー・プロファイルのデータ要素が変更されると、Oracle Identity Managerではスナップショットが作成されます。

次のイベントにより、ユーザー・プロファイル・スナップショットの作成がトリガーされます。

- あらゆる種類のユーザー・レコードに対する変更(リコンシリエーション、ダイレクト・プロビジョニングなどによる変更)

- ユーザーに対するロール・メンバーシップの変更

- ユーザーに適用されるポリシーの変更

- ユーザーへのリソースのプロビジョニング

- ユーザーに対するリソースのデプロビジョニング

- プロビジョニングされたリソースに対するプロビジョニング関連イベント

- リソース・ステータスの変更

- プロビジョニング・プロセスへのプロビジョニング・タスクの追加

- プロビジョニング・プロセスのプロビジョニング・タスクに対する更新(ステータス変更、エスカレーションなど)

- プロセス・フォーム・データの作成または更新

6.3.2 ユーザー・プロファイル監査に使用されるポストプロセッサ

ユーザー・プロファイルの監査者は、スナップショットのXMLをレポート表UPA_USR、UPA_FIELDS、UPA_GRP_MEMBERSHIP、UPA_RESOURCE、UPA_UD_FORMSおよびUPA_UD_FORMFIELDSに正規化する内部ポストプロセッサを保持します。これらの表は、レポート・モジュールで適切なレポートを生成するために使用されます。

6.3.3 ユーザー・プロファイル監査に使用される表

表6-5に、ユーザー・プロファイル監査で使用するデータベースの表を示します。

注意:

ユーザー・プロファイル監査表の列名や使用方法などの詳細は、Oracle Identity Managerに付属のスキーマ・ドキュメントを参照してください。

表6-5 ユーザー・プロファイル監査の表

表名

説明

AUD

Oracle Identity Managerでサポートされているすべての監査者(例: ユーザー・プロファイル監査者)の詳細情報を格納します。現在、使用可能なエントリはUserProfileAuditのみです。

AUD_JMS

ビジネス・トランザクションの一環として適用された変更の情報を格納するステージング表です。これは、監査エンジンが使用する前にデータ変更ログ・データを一時的に保存するための中間表です。監査メッセージが正常に処理されると、対応するレコードが表から削除されます。

注意: この表は、エンド・ユーザーの使用を意図していないため、直接使用しないでください。

UPA

すべてのスナップショットおよびユーザー・プロファイルに適用された変更を格納するためのメイン監査表です。

UPA_FIELDS

ユーザー・プロファイル監査履歴の変更を非正規化(垂直)形式で格納します。

UPA_GRP_MEMBERSHIP

グループ・メンバーシップ履歴を非正規化形式で格納します。

UPA_RESOURCE

ユーザー・プロファイル・リソース履歴を非正規化形式で格納します。

UPA_USR

ユーザー・プロファイル履歴を非正規化形式で格納します。

UPA_UD_FORMS

UPA_UD_FORMFIELDS表とともに、ユーザーのアカウント・プロファイル(プロセス・フォーム)への変更に関する情報を格納します。この表は、トランザクションで変更される様々なフォーム(親または子フォームなど)の変更の経過を管理します。アカウントまたは権限の属性の変更は、UPA_UD_FORMFIELDS表に格納されます。

UPA_UD_FORMFIELDS

修正されたアカウント名または権限プロファイルのフィールド名を格納します。この表には、変更されたフィールドの古い値と新しい値も記録されます。

注意:

- UPA_UD_FORMS表とUPA_UD_FORMFIELDS表には、ユーザーのアカウント・プロファイルの変更に対する監査証跡が非正規化形式で格納されます。これらの表は、監査に関連する様々なレポートに使用できます。

- UPA_UD_FORMS表とUPA_UD_FORMFIELDS表には、システム・プロパティXL.EnableExceptionReportsがTRUEに設定されている場合にのみデータが移入されます。このプロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する項を参照してください。

6.3.4 アーカイブ

ユーザー・プロファイル監査データは監査レベルの設定に応じて増加し、ほとんどのデプロイメントにとって増加は深刻です。

また、将来の増加に対応できるように古いユーザー・プロファイル監査データを削除またはアーカイブする要件も存在します。監査アーカイブおよびパージ・ユーティリティを使用して、これらの要件を満たすことができます。このユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの監査アーカイブおよびパージ・ユーティリティの使用に関する項を参照してください。

6.4 ロール・プロファイル監査機能

ロール・プロファイル監査は、ロール・プロファイルの属性、ロール管理者および直接サブロールに対する変更を対象としています。

この項では、次の項目について説明します。

- 監査用に収集されるデータ

6.4.1 監査用に収集されるデータ

ユーザー監査とは異なり、ロール・プロファイル監査には独立した監査レベルは定義されません。かわりに、ユーザー・プロファイル監査に対して定義された監査レベルがロール・プロファイル監査に使用されます。ユーザー・プロファイル監査レベルに対して定義された監査レベルが、メンバーシップ・レベルか、それより1レベル高い場合にのみ、ロール・プロファイル監査は実施されます。Oracle Identity Managerをインストールすると、デフォルトでユーザー・プロファイル監査機能が有効になり、監査レベルは「リソース・フォーム」に設定されます。その結果、ユーザー・プロファイル監査のデフォルトの監査レベルは「リソース・フォーム」であり、「メンバーシップ」より高いため、ロール・プロファイル監査もデフォルトで有効になります。

このセクションのトピックは次のとおりです:

- ロール・プロファイル監査データの収集とアーカイブ

- スナップショットの保存

- スナップショット取得のトリガー

6.4.1.1 ロール・プロファイル監査データの取得とアーカイブ

ロール・プロファイルの変更のたびに、Oracle Identity Managerでは、ロール・プロファイルのスナップショットを取得してデータベースの監査表に格納します。

Oracle Identity Managerでは、ロールに対する監査が作成されると、最初のスナップショットが存在していない場合も、スナップショットが生成されます。現在のスナップショットが最初のスナップショットとして取り扱われます。

次に、ロール・プロファイルの構成要素とその要素を構成する表を示します。

- ユーザー・ロール・レコード: UGP表(グループのすべてのUDFを含む)

- サブロール情報: GPG表

6.4.1.2 スナップショットの保存

Oracle Identity Managerでロール・プロファイルのスナップショットを取得すると、そのスナップショットはGPA表に格納されます。この表の構造は、表6-6に示すとおりです。

表6-6 GPA表の定義

列

データ型

説明

GPA_KEY

NUMBER (19,0)

監査レコードのキー

UGP_KEY

NUMBER (19,0)

ロール・スナップショットが記録されるロールのキー

EFF_FROM_DATE

TIMESTAMP (6)

スナップショット・エントリが有効になった日時

EFF_TO_DATE

TIMESTAMP (6)

スナップショット・エントリが無効になった日時

つまり、これは次のスナップショット・エントリが作成された日時です。最新のユーザー・プロファイルを表すエントリの場合、終了日列の値はNULLに設定されます。

SRC

VARCHAR2 (4000)

エントリのソース、変更責任者のユーザーID、および変更の実行に使用されたAPI

SNAPSHOT

CLOB

スナップショットのXML表現

DELTAS

CLOB

スナップショットに対して行われた変更に対応する新旧の値のXML表現

SIGNATURE

CLOB

スナップショットのデジタル署名を格納するために使用できる列(否認防止用)

6.4.1.3 スナップショット取得のトリガー

ロール・プロファイル・スナップショットのデータ要素が変更されると、Oracle Identity Managerではスナップショットが作成されます。

ロール・プロファイル・スナップショットの作成は、次のいずれかで変更が発生するイベントによりトリガーされます。

- ロール・プロファイル・データ

- サブロール情報

6.5 監査機能の有効化と無効化

ここでは、Oracle Identity Managerで監査機能を有効および無効にする方法について次の各項で説明します。

- 監査機能の無効化

- 監査機能の有効化

6.5.1 監査機能の無効化

Oracle Identity Managerで監査機能を無効にする手順は、次のとおりです。

1. Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの変更に関する項に記載されているように、「ユーザー・プロファイル監査データ収集レベル」(XL.UserProfileAuditDataCollection)システム・プロパティの値を「なし」に設定します。

2. Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのジョブの無効化と有効化に関する項に記載されているように、監査メッセージの発行タスク・スケジュール済タスクを無効にします。
保留中の監査変更を監査表に記録する必要がある場合は、保留中の監査変更がすべて処理された後にスケジュール済タスクを無効にします。

6.5.2 監査機能の有効化

Oracle Identity Managerで監査機能を有効にする手順は、次のとおりです。

1. 「ユーザー・プロファイル監査データ収集レベル」(XL.UserProfileAuditDataCollection)システム・プロパティの値を「監査レベル」に定義されているいずれかのレベルに設定します。
システム・プロパティ値の変更の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの変更に関する項を参照してください。

2. Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのジョブの無効化と有効化に関する項に記載されているように、監査メッセージの発行タスク・スケジュール済タスクを有効にします。

3. スナップショットを生成するには、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の監査スナップショットの生成に関する項に記載されているように、GenerateSnapshotスクリプトを実行します。
コマンドラインでは、GenerateSnapshotスクリプトを次のように使用します。

./GenerateSnapshot.sh -username OIM_ADMIN_USERNAME -numOfThreads 8 -serverURLt3://WLS_SERVER:PORT -ctxFactory weblogic.jndi.WLInitialContextFactory[-inputFile fileWithUserKeys]

各変数は次のとおりです。

- OIM_ADMIN_USERNAMEは、Oracle Identity Manager管理者のユーザー名です。

- WLS_SERVERは、Oracle WebLogic Serverの名前です。

- PORTは、WebLogic Serverのポート番号です。

第II部

Oracle Identity Managerセルフサービス

この部では、Oracle Identity Managerで実行できる様々なセルフサービス・タスクについて説明します。

次の章で構成されます。

- 第7章「セルフサービス登録の構成および使用」

- 第8章「プロファイルの管理」

- 第9章「タスクの管理」

- 第10章「リクエストの管理」

7 セルフサービス登録の構成および使用

この章では、セルフサービス登録を使用して実行できるタスク、およびセルフ登録に対する自動承認の構成方法について、次の各項で説明します。

- セルフサービス登録の使用

- 自己登録に対する自動承認の構成

7.1 セルフサービス登録の使用

ログイン・ページでは、ログインするための機能、およびすべての未認証操作の開始点が提供されます。このページは、Oracle Identity Managerに対してネイティブ認証を実行しないか、またはSSOを使用しないでOracle Identity Manager管理およびユーザー・コンソールにアクセスした場合に表示されます。

Oracle Identity Manager管理およびユーザー・コンソールにログインする前に実行できるタスクは通常、次のとおりです。

- Oracle Identity Manager管理およびユーザー・コンソールへのログイン

- 登録リクエストの送信

- 登録リクエストのトラッキング

7.1.1 Oracle Identity Manager管理およびユーザー・コンソールへのログイン

Oracle Identity Manager管理およびユーザー・コンソールにログインする手順は、次のとおりです。

注意:

- Oracle Identity Managerがネイティブ認証をサポートするよう構成されている場合に「ログイン」リンクをクリックすると、Oracle Identity Managerのユーザー名とパスワードを使用して認証できるフォームにリダイレクトされます。

- Oracle Identity Managerがシングル・サインオン(SSO)をサポートするよう構成されている場合に「ログイン」リンクをクリックすると、SSOアプリケーションのログイン・ページにリダイレクトされます。

1. 「Oracle Identity Manager管理およびユーザー・コンソール」ログイン・ページに移動します。

2. 「ユーザーID」フィールドに、ユーザー名を入力します。

3. 「パスワード」フィールドに、パスワードを入力します。

4. 「サインイン」をクリックします。認証が正常に行われるとログインし、認証されたコンテキストのメイン・ページに移動します。
次の理由により、ログイン操作でエラーとなる場合があります。

- 不正な資格証明: 入力したユーザー名およびパスワードが正しくない場合、エラー・メッセージが表示されます。次の理由が考えられます。

- ユーザー名が存在しない

- パスワードが正しくない

- ユーザー名は存在するがユーザーが削除されている

注意:

- システム構成プロパティの「ログインの最大試行回数」によって、OIMアカウントがロックされるまでの認証の失敗回数が指定されます。デフォルトでは、この値は10です。ログイン・バックエンドでは、アカウントで発生したログインの失敗回数のカウンタを保持する必要があります。ログインに失敗すると、バックエンドによりカウンタが増分されます。アカウントがロックされていない間に認証に成功すると、カウンタが0（ゼロ）にリセットされます。カウンタがロックアウトされるまでのログイン失敗回数構成プロパティの値を超えると、アカウントがロックされます。さらに、アカウント・ロック日時属性の値が現在のタイムスタンプに設定され、「手動ロック」属性の値が「いいえ」に設定されます。

- 構成プロパティが0（ゼロ）または負の数値に設定されている場合は、ログインの失敗回数に関係なくアカウントはロックされません。

- ロックされたアカウント: アカウントがロックされた場合は、資格証明が正しくてもログインできません。ロックされているアカウントを使用してログインを試みると、「無効なサインイン。」メッセージが表示されます。アカウントがロックされている場合は、Oracleヘルプデスクに連絡してください。

ヒント:

Oracle WebLogicでは、ログインを最大回数失敗したユーザーをソフト・ロックするように構成できます。この構成は、Oracle Identity Managerのログインの最大試行回数の構成とは関係なく、ユーザーをソフト・ロックする時期と期間を決定します。ユーザーがWebLogicによってソフト・ロックされるログイン失敗の最大回数は、デフォルトでは誤ったパスワードによる5回連続のログイン失敗で、ロックされる期間は30分です。この構成を変更するには、WebLogic管理コンソールの次の場所にナビゲートします。

(WLSコンソール)「ホーム」→「セキュリティ・レルム」→「myrealm」→「ユーザーのロックアウト」

したがって、正しいユーザー名と誤ったパスワードを使用してOracle Identity Manager管理およびユーザー・コンソールへのログインを6回以上10回未満試行すると、そのユーザーのアカウントはWebLogicセキュリティ・レルムによってソフト・ロックされますが、Oracle Identity Managerではロックされないままです。Oracle Identity Managerではこのアカウントは使用可能でロックされていませんが、正しいパスワードを入力しても30分間はログインできず、構成された時間(30分など)より前にアカウントのロックを解除することはできません。

誤ったパスワードでの試行が10回を超えると、アカウントはWebLogicとOracle Identity Managerの両方でロックされます。そのため、Oracle Identity Manager管理者がアカウントをリセットまたはロック解除した場合も、WebLogicによってソフト・ロックされているため、30分をすぎるまではログインできません。

- 無効なユーザー: ユーザー・アカウントが無効になっている場合は、ログインできません。

5. パスワードが期限切れの場合は、「パスワードの変更」ページが表示されます。パスワードを変更しないとコンソールのメイン・ページに進むことはできません。新規パスワードを入力し、「適用」をクリックします。

6. システム構成プロパティの「起動時に質問を設定するよう強制」が「はい」に設定されている場合は、プロファイルで必要なチャレンジ・レスポンスが設定されているかどうかがログイン・フローで確認されます。設定されていない場合は、チャレンジ・レスポンスを設定するフォームが表示されます。チャレンジ・レスポンスが設定されている場合、または構成プロパティが「いいえ」に設定されている場合は、このステップがスキップされます。フォームでチャレンジ・レスポンスを設定し、「送信」をクリックします。
または、チャレンジ質問の設定を後にする場合は、「後で通知」をクリックしてOracle Identity Managerセルフサービスへのログインを続行できます。

注意:

「起動時に質問を設定するよう強制」という名前のPCQ.FORCE_SET_QUESシステム・プロパティでは、最初のログオン時にチャレンジ質問の設定が必要かどうかを指定します。チャレンジ質問の設定が必要でない場合は、「後で通知」ボタンが表示されます。このボタンをクリックすると、チャレンジ質問を設定しなくても管理およびユーザー・コンソールにログインできます。

ログイン以外のOracle Identity Manager UIページにアクセスしようとした時点でログイン済でない場合は、ログイン・ページにリダイレクトされます。この項で説明しているログイン手順に従ってOracle Identity Managerにログオンします。正常にログインすると、アクセスしようとしていた元のページにリダイレクトされます。

7. 初めてログインすると、「パスワードの変更」ページが表示されます。これは、初めてログインした後は、パスワードを変更する必要があるためです。パスワードを変更した後、再度ログインします。

注意:

Oracle Identity Manager 11g リリース1 (11.1.1)では、XL.ForcePasswordChangeAtFirstLoginシステム・プロパティは現在使用されていません。このため、初回のログイン時にユーザーにパスワードの変更を要求するよう構成することはできません。デフォルトでは、次の場合、ユーザーはパスワードを変更する必要があります。

- 新規ユーザーがOracle Identity Managerに初めてログインする場合

- パスワードが管理者によってリセットされた後にユーザーがOracle Identity Managerに初めてログインする場合

- ユーザーのパスワードの有効期限が切れた場合

7.1.2 登録リクエストの送信

Oracle Identity Managerセルフサービスで特定のタスクを実行するには、Oracle Identity Managerのアイデンティティに自身を登録する必要があります。ユーザー自身をOracle Identity Managerに登録するには、次の手順を実行します。

1. 「Oracle Identity Manager管理およびユーザー・コンソール」ログイン・ページで、「登録」をクリックします。ユーザー登録ウィザードの基本情報ページが表示されます。

注意:

ユーザー登録ウィザードで要求された情報は、「ユーザーの自己登録」リクエスト・データセットによって管理されます。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

2. 名、ミドル・ネーム、姓および電子メールをそれぞれのフィールドに入力し、「次」をクリックします。ログイン情報およびセキュリティ情報ページが表示されます。
このUIでは、許可されている文字数を超えて入力することはできません。自己登録時に入力する値の最大長は、「名」、「ミドル・ネーム」、「姓」および「共通名」では80文字、「表示名」では382文字と指定されています。

「ユーザーの自己登録」リクエスト・データセットを変更して他の属性をセルフサービスUIに追加した場合、その値は明示的に検証されません。UIのフィールドには、UIの長さフィールドに指定した文字数を入力できます。

これらの各フィールドに入力できる文字に制限はありません。これらの各フィールドの入力には、ハッシュ(#)、パーセント(%)などの特殊文字を含めることができます。

電子メールは、システム・プロパティの「XL.EmailValidationPattern」で規定されているパターンどおりに指定する必要があります。電子メールが不適切な場合は、次のエラーが表示されます: 「電子メールIDが無効です。有効な電子メールIDを入力してください。」指定した電子メールIDがシステム内の他のユーザーによってすでに使用されている場合は、次のエラーが表示されます: 「電子メールID <email id>はすでに取得されています。別の電子メールIDを入力してください。」

3. 「ユーザーIDおよびパスワードの選択」セクションで、ユーザー・ログイン、パスワード、確認パスワードを入力します。入力したパスワードは、パスワード・ポリシーの対象になります。次のページでは、パスワード・フィールドの横にパスワード・ポリシーが表示されます。パスワードがパスワード・ポリシーの基準を満たさない場合は、満たす必要がある基準を記載したエラーが表示されます。パスワード・ポリシーの詳細は、「パスワード管理」を参照してください。
パスワードを入力しないと、システムでパスワードが自動的に生成され、「ユーザー登録」ページの最初のページで入力した電子メール・アドレスにパスワードが送信されます。

注意:

- 登録フォームには、自己登録テンプレートの属性が事前に移入されます。

- 管理者は、URLリンクにカスタムの登録テンプレート名を指定することでカスタム登録フォームを作成できます。ユーザーが使用するURLリンクによって、登録時に使用するテンプレートとフォームが決まります。したがって、複数のURLリンクを使用して複数の登録フォームをサポートできます。登録のURLリンクは、UIで構成することも、ユーザーに登録をリクエストする電子メールに含めることもできます。

4. 「チャレンジ質問および回答の設定」セクションで、チャレンジ質問を選択し、質問ごとに回答を設定します。チャレンジ質問と回答でチェックされる内容は、次のとおりです。

- 異なるチャレンジ質問が選択されていない

- 各チャレンジ質問に対して異なる回答が指定されていない

これらの条件のいずれかが検出された場合は、エラーが表示されます。

5. 「登録」をクリックします。リクエストのトラッキングに使用できる、登録リクエストのトラッキングIDが提供されます。

注意:

- チャレンジ質問および回答は、その属性が自己登録のテンプレートに定義されている場合に尋ねられます。

- Oracle Identity Managerデプロイメントの一部は自己登録をサポートしません。これは、従業員および契約社員のアイデンティティを管理する内部デプロイメントに特に当てはまり、そこでは自己登録ではなくリコンシリエーションでアイデンティティが追加されます。

- Oracle Identity Managerには、自己登録を有効にする「自己登録は許可されているか」システム・プロパティがあります。未認証のセルフサービス・コンソールには、「登録」リンクが常に表示されます。このプロパティが「False」に設定されている場合は、「登録」リンクをクリックすると、「自己登録は使用できません。」というエラーが表示されます。「True」に設定されている場合は、自己登録が許可されます。

7.1.3 登録リクエストのトラッキング

Oracle Identity Managerへのアイデンティティの登録リクエストはトラッキングできます。現在のステータスが「成功」を示している場合は、Oracle Identity Manager管理およびユーザーコンソールに移動し、ユーザー名とパスワードを入力してOracle Identity Managerセルフサービスにログインできます。

登録をトラッキングするには、次の手順を実行します。

1. 「Oracle Identity Manager管理およびユーザー・コンソール」ログイン・ページで、「登録のトラッキング」をクリックします。リクエスト・ステータス・ページが表示されます。

2. 「トラッキングID」フィールドに、登録リクエストに割り当てられたトラッキングIDを入力します。次に、「送信」をクリックします。次の詳細を示す自己登録のステータス・ページが表示されます。

- リクエストID

- リクエストの送信日
リクエストが送信されて承認が実行されていない場合、表示される日付はリクエストの送信日です。いずれの場合も、日付は常に、最終更新日を反映します。

- 現行のステータス
送信されたすべての自己登録リクエストは、承認を通過して完全に処理される必要があります。様々な承認レベルの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認レベルに関する項を参照してください。

ユーザーがリクエストの現在のステータスをトラッキングすると、ステータスがリクエストが存在するステージの詳細とともに表示されます。ステータスは次のいずれかになります。

- 保留: この状態は、送信されたリクエストの承認が保留中であることを示しています。デフォルトの承認の場合は、次のステータス・メッセージが表示されます。
登録に対するリクエストレベルの承認を取得しています。マネージャはこのリクエストを承認する必要があります。

リクエスト・レベルの承認が保留中の場合。リクエスト・レベルの承認が取得されると、次のステータス・メッセージが表示されます。

登録に対する操作レベルの承認を取得しています。

- 却下: この状態は、承認時にリクエストが却下されたことを示しています。説明により、却下の事由が示されます。デフォルトの承認レベルの場合は、リクエストがリクエスト承認レベルで却下されると、次のステータス・メッセージが表示されます。
リクエスト承認が登録を却下されました。

リクエストが操作承認レベルで却下されると、次のステータス・メッセージが表示されます。

操作承認が登録を却下されました。

- 完了: この状態は、リクエストが完了したことを示しています。すべてが承認されてリクエストが正常に完了すると、次のステータス・メッセージが表示されます。
登録リクエストが完了しました。

- 失敗: この状態は、送信時にリクエストが失敗したことを示しています。リクエストの送信が失敗すると、次のステータス・メッセージが表示されます。
リクエストの登録に失敗しました。

注意:

このページからトラッキングできるのは、自己登録リクエストのステータスのみです。

7.2 自己登録に対する自動承認の構成

エンドユーザーの自己登録は、新しい登録が管理者操作なしで自動承認されるように構成できます。

デフォルトの「自己登録」リクエスト・データセットであるSelfCreateUserDataset.xmlの「組織」フィールドは、承認専用フィールドとして指定されています。これは、承認者がリクエスト承認時に「組織」フィールドに手動で値を指定する必要があることを意味します。登録が自動承認されるように「自己登録」リクエスト・データセットを構成するには、デフォルトのデータセットをコピーし、「自己登録」リクエスト・データセットの「組織」フィールドの承認専用フラグを削除して、新しいテンプレートへのリンクを指定します。

自己登録に対する自動承認を構成する手順は、次のとおりです。

注意:

このタスクを開始する前に、第10章「リクエストの管理」で説明されている概念を理解する必要があります。

1. デフォルトのテンプレートをコピーして、自己登録ユーザー用の新しいリクエスト・テンプレートを作成します。組織属性を含めますが、使用する必要がある組織を指定して制限を追加します。
リクエスト・テンプレートの構成の詳細は、第17章「リクエスト・テンプレートの管理」を参照してください。

2. ユーザーの自己作成データセットを変更して、組織属性の承認専用フラグを削除します。
リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリソース用のリクエスト・データセットの作成に関する項を参照してください。

MDSへのデータセットのアップロードの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSへのリクエスト・データセットのアップロードに関する項を参照してください。

3. 自己登録および自動承認構成のために、リクエスト・レベルと操作レベルの2つの新しい承認ポリシーを作成します。
承認ポリシー・ルールの作成については、「承認ポリシーの作成」を参照してください。

4. 自己登録用に新しく作成したテンプレートを使用するには、次の内容を参照してください。

- システムでは、自己登録用のカスタム・テンプレートを使用するためにパラメータのT_ID=<template name>が取得されます。ユーザーが「登録」リンクをクリックすると、次のページが表示されます。
http://host:port/oim/faces/pages/USelf.jspx?E_TYPE=USELF&OP_TYPE=SELF_REGISTRATION

このページは、デフォルトのテンプレートを使用します。

- カスタム・テンプレートを使用するには、リクエストの末尾にT_IDを使用します(次に例を示します)。
http://host:port/oim/faces/pages/USelf.jspx?E_TYPE=USELF&OP_TYPE=SELF_REGISTRATION&T_ID=<new_template>

これによって、デフォルトのページではなく「new_template」のように自己登録ページが表示されます。

8 プロファイルの管理

プロファイル・ページでは、個人詳細を表示および変更できます。ユーザー・プロファイルの管理時に実行するアクションは、セルフサービス・ユーザー管理に対して定義された認可ポリシーによって決定します。これらの認可ポリシーは、Oracle Identity Managerに対して定義されてOracle Entitlements Server (OES)に格納されます。

すべての認可権限は、認可ポリシーによって制御されます。付与されるすべての権限は、その権限の使用が許可されているかどうかをチェックするために検証されます。表8-1に、プロファイル管理操作用の権限を示します。

表8-1 プロファイル管理権限

権限

説明

VIEW_USER_DETAILS

この権限は、「マイ・プロファイル」ページの「属性」タブにあるユーザー・プロファイル属性を表示できるかどうかを決定します。この権限では、詳細な属性レベルのアクセス制御がサポートされ、これによって、その操作に適用する特定の属性を選択できます。

MODIFY_USER_DETAILS

この権限は、「マイ・プロファイル」ページの「属性」タブでユーザー・プロファイル属性を変更できるかどうかを決定します。この権限では、詳細な属性レベルのアクセス制御がサポートされ、これによって、その操作に適用する特定の属性を選択できます。属性に対する表示および変更権限がある場合、その属性は、「マイ・プロファイル」ページに編集可能属性として表示されます。属性に対する表示権限のみがある場合、その属性は、「マイ・プロファイル」ページに読取り専用属性として表示されます。

MODIFY_SELF_USER_PROXY_PROFILE

この権限は、「マイ・プロファイル」ページの「プロキシ」タブでプロキシを追加、変更および削除できるかどうかを決定します。

関連項目:

- プロファイル属性の認可ポリシーおよび認可の詳細は、第15章「認可ポリシーの管理」を参照してください。

- リクエスト・テンプレートの詳細は、第17章「リクエスト・テンプレートの管理」を参照してください。

- リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリクエストの構成に関する項を参照してください。

「プロファイル」セクションを表示する手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスにログインします。

2. 「プロファイル」タブをクリックします。

「プロファイル」ページには、次のセクションがあります。

- プロファイル属性の管理

- ロール割当ての管理

- リソース・プロファイルの管理

- プロキシの管理

- セキュリティの管理

- 忘れたパスワードのリセット

8.1 プロファイル属性の管理

「マイ・プロファイル」ページの最初のタブは、「属性」タブです。このタブには、ユーザーのプロファイル属性が表示されます。表示される属性は、ユーザーが表示可能なプロファイル属性を決定するフィールド・レベルの認可ポリシーによって制御されます。

デフォルトでは、すべてのプロファイル属性がユーザーに表示されます。ユーザー・エンティティに追加した新しい属性は、デフォルトでは、明示的に表示可能にするまで非表示に設定されます。プロファイル属性へのアクセスは、認可ポリシーによって制御されます。この機能に対する認可ポリシーの詳細は、「認証済ユーザー・セルフサービス」を参照してください。

さらに、フィールド・レベルの認可は、属性をユーザー自身が編集できるかどうかを決定します。編集可能属性は、編集可能テキスト・ボックスまたは適切なUIウィジェット(参照フィールドなど)に表示されます。新しい値を入力して「適用」ボタンをクリックし、変更内容を送信します。

プロファイルの更新が送信されると、すべての属性を変更するためのリクエストが作成されます。

- リクエストを要求する属性が、リクエストのトラッキング番号とともに表示されます。ワークフロー・ルールによって、属性の変更を許可する前に承認を開始して取得する承認ワークフローが決定します。リクエストのステータスは、セルフサービス・ページの「リクエスト」タブで参照できます。リクエスト・タブおよび「ユーザーの変更」リクエストの詳細は、第10章「リクエストの管理」を参照してください。

- 「属性」タブの「プリファレンス」セクションでは、ユーザー・プリファレンスにアクセスできます。このオプションを使用すると、製品の動作方法に関するプリファレンスを設定できます。
Oracle Identity Managerのユーザー・プリファレンスは、ユーザーのプロファイルの一部として格納されている属性です。デフォルトでは、次の属性がUIに表示されます。

- ロケール: Oracle Identity Managerでサポートされている言語に基づいて、通知メッセージの言語プリファレンスを選択できます。管理者は、デプロイメント構成の一部としてインストールでサポートされている言語を定義します。選択できるのは、デプロイメントで構成された言語の限定セットからのみです。

注意:

Oracle Identity Manager 11g リリース1 (11.1.1.4)では、UIに対するユーザーの言語プリファレンスは、セルフサービスの「プリファレンス」セクションで指定したロケールに基づいて設定されません。UIロケールは、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザーの言語の設定に関する項で説明されているとおりに決定されます。

- タイムゾーン: 表示されるすべてのデータのタイムゾーンを指定できます。

- 注意:

- 他のデフォルト属性を追加するには、Oracle Identity Administrationのセルフサービス・ユーザー管理の管理ポリシーでユーザー・プロファイルを変更します。「マイ・プロファイル」の他の属性を表示および変更するには、カスタム・ポリシーを作成する必要があります。

- ユーザー定義フィールド(UDF)を追加するには、Oracle Identity Administrationのセルフサービス・ユーザー管理の管理ポリシーでポリシーを作成して属性を追加します。「属性」タブに表示および変更用のユーザー定義属性を追加するには、これらのUDFをセルフサービスの「ユーザーの変更」リクエスト・データセットに追加する必要があります。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリクエストの構成に関する項を参照してください。
また、これらの属性を表示または変更(あるいはその両方)する権限を付与するには、セルフサービス・ユーザー管理でカスタム・ポリシーを作成する必要があります。認可ポリシーの詳細は、「認可ポリシーの作成および管理」を参照してください。

8.2 ロール割当ての管理

「ロール」タブには、自分が直接または間接的にメンバーとなっているロールが表示されます。次の情報が表示されます。

- ロール表示名: ロール名が表示されます。

- 説明:ロールの説明が表示されます。

- メンバーシップ・タイプ: メンバーシップ・タイプ(「直接ロール」または「間接ロール」)が表示されます。

- 割当て日: 自分がロールに割り当てられた日付が表示されます。

このタブには、次のロール管理操作を開始するためのオプションもあります。

- ロールのリクエスト

- ロールの削除

8.2.1 ロールのリクエスト

ロールをリクエストする手順は、次のとおりです。

1. 「マイ・プロファイル」→「ロール」の順に移動します。

2. 「アクション」リストから「ロールのリクエスト」を選択します。ロールのリクエスト・ウィザードの「ロールの選択」ページが表示されます。「ロールのリクエスト」ページのロールのリストでエンド・ユーザーが使用できるロールは、リクエスト・テンプレートで提供されているロールと、ユーザーに検索権限があるロールの共通部分です。

注意:

デフォルトのリクエスト・テンプレートではなく、他のリクエスト・テンプレートに対するアクセス権が付与されている場合は、テンプレートを選択するように求められます。事前定義のテンプレートに対するアクセス権のみが付与されている場合、このステップはスキップされます。

3. 「ロール名」フィールドに、リクエストするロールの名前を入力します。「ロール名」フィールドの横にあるアイコンを使用して使用可能なロールのリストを表示することで、ロール名または表示名(あるいはその両方)に基づいてロールを検索することもできます。

4. 「使用可能なロール」リストからリクエストするロールを1つ以上選択し、「移動」アイコンをクリックして、それらのロールを「選択したロール」リストに移動します。

5. 「次」をクリックします。「理由」ページが表示されます。

6. 「有効日」フィールドおよび「理由」フィールドに値を入力し、ロールをアクティブにする日付およびリクエストの理由を説明するコメントをそれぞれ指定します。

7. 「終了」をクリックします。Oracle Identity Managerセルフサービスの「リクエスト」タブにリクエストのステータスを表示できます。リクエスト・ステータスの詳細は、第10章「リクエストの管理」を参照してください。

8.2.2 ロールの削除

ロールを削除するには、次のようにします。

1. 「マイ・プロファイル」→「ロール」の順に移動します。ロールのリストが表に表示されます。

2. 削除するロールを表から選択し、「アクション」リストから「ロールの削除」を選択します。ロールの削除ウィザードの「ロールの選択」ページが表示されます。

注意:

デフォルトのリクエスト・テンプレートではなく、他のリクエスト・テンプレートに対するアクセス権が付与されている場合は、リクエスト・テンプレートを選択するように求められます。デフォルトのリクエスト・テンプレートに対するアクセス権のみが付与されている場合、このステップはスキップされます。

3. 「ロール名」ボックスに、削除するロールの名前を入力します。「ロール名」フィールドの横にあるアイコンを使用して使用可能なロールのリストを表示することで、ロール名を検索することもできます。

4. 「使用可能なロール」リストから削除するロールを1つ以上選択し、「移動」アイコンをクリックして、それらのロールを「選択したロール」リストに移動します。このステップは、カスタム・リクエスト・テンプレートが「ロールの自己削除」操作用に構成されている場合にのみ適用可能で、ユーザーは複数のテンプレートの中からいずれかを選択します。

5. 「次」をクリックします。「理由」ページが表示されます。

6. 「有効日」フィールドおよび「理由」フィールドに値を入力し、ロールを削除する日付および削除の理由を説明するコメントをそれぞれ指定します。

7. 「終了」をクリックします。リクエストのステータスは、セルフサービス・ページの「リクエスト」タブで参照できます。リクエスト・タブの詳細は、第10章「リクエストの管理」を参照してください。

8.3 リソース・プロファイルの管理

「リソース」タブには、自分に現在プロビジョニングされているリソースが表示されます。リスト内の各リソースについて、そのリソースに関連付けられている次の情報を表示できます。

- リソース名

- ステータス

- 識別情報

- サマリー情報のブロックおよびその他の情報

プロビジョニングされているリソースの詳細を表示するページにドリルダウンできます。このページで「リソースの変更」ボタンをクリックすると、リソースを変更できます。これによって、受益者がユーザー自身に事前設定され、リソース・インスタンスも事前設定された状態のリソースの変更リクエスト・ウィザードにリダイレクトされます。リクエストする更新および関連情報を指定する処理を完了できます。リクエストのトラッキング番号が生成されます。

セルフサービス・リクエストで変更できるのは、同時に1つのリソース・インスタンスのみで、バルク・リクエストはサポートされていません。別のリソース・インスタンスを変更する場合は、別のリクエストを要求する必要があります。

「リソース」タブで、次のことを実行できます。

- リソースのリクエスト

- リソースの変更

- リソースの詳細の表示

8.3.1 リソースのリクエスト

リソースをリクエストする手順は、次のとおりです。

1. 「マイ・プロファイル」→「リソース」の順に移動します。

2. 「アクション」リストから「リソースのリクエスト」を選択します。「リクエスト・テンプレートの選択」ページが表示されます。

注意:

このページは、デフォルトのリクエスト・テンプレートではなく、他のリクエスト・テンプレートに対するアクセス権が付与されている場合のみ表示されます。リクエスト・テンプレートを選択するように求められます。デフォルトのリクエスト・テンプレートに対するアクセス権のみが付与されている場合、このページはスキップされます。

3. 「リクエスト・テンプレート」リストから、リソースに割り当てられているリクエスト・テンプレートを選択し、「次」をクリックします。リソースのリクエスト・ウィザードの「リソースの選択」ページが表示されます。

4. 「リソース名」フィールドに、リクエストするリソースの名前を入力します。「リソース名」フィールドの横にあるアイコンを使用して使用可能なリソースのリストを表示することで、リソース名を検索することもできます。

注意:

この画面に表示されるリソースは、使用可能なリソースのリストと、使用されているリクエスト・テンプレートで制限されているリソースのリストの組合せです。たとえば、使用可能なリソースがActive Directory、ExchangeおよびUNIXで、テンプレートではリソースがActive DirectoryとExchangeに制限されている場合、この画面にはActive DirectoryとExchangeのみが表示されます。

リクエスト・テンプレートで制限するリソースが選択されていない場合は、使用可能なすべてのリソースが表示されます。

5. 使用可能なリソース・リストからリクエストするリソースを選択し、「移動」アイコンをクリックして、そのリソースを「選択したリソース」リストに移動します。

注意:

バルク・リクエストの場合は、2つ以上のリソースを選択する必要があります(2つ以上の子リクエストが作成されます)。手順の残りは、バルク・リクエストと同じです。

6. 「次」をクリックします。「リソース・データの入力」フォームが表示されます。

7. リソースに関連する適切な詳細を入力し、「次」をクリックします。「理由」ページが表示されます。

8. 「有効日」フィールドおよび「理由」フィールドに値を入力し、リソースをアクティブにする日付およびリクエストの理由を説明するコメントをそれぞれ指定します。

9. 「終了」をクリックします。リクエストのステータスは、セルフサービス・ページの「リクエスト」タブで参照できます。リクエスト・タブの詳細は、第10章「リクエストの管理」を参照してください。

8.3.2 リソースの変更

リソースを変更する手順は、次のとおりです。

1. 「マイ・プロファイル」→「リソース」の順に移動します。

2. 「アクション」リストから「リソースの変更」を選択します。「リクエスト・テンプレートの選択」ページが表示されます。

注意:

このページは、デフォルトのリクエスト・テンプレートではなく、他のリクエスト・テンプレートに対するアクセス権が付与されている場合のみ表示されます。リクエスト・テンプレートを選択するように求められます。デフォルトのリクエスト・テンプレートに対するアクセス権のみが付与されている場合、このページはスキップされます。

3. 「リクエスト・テンプレート」リストから、リソースに割り当てられているリクエスト・テンプレートを選択し、「次」をクリックします。リソースのリクエスト・ウィザードの「リソースの選択」ページが表示されます。「リソースの選択」ページが表示されます。

4. 「リソース名」フィールドに、変更するリソースの名前を入力します。「リソース名」フィールドの横にあるアイコンを使用して使用可能なリソースのリストを表示することで、リソース名を検索することもできます。

5. 使用可能なリソース・リストからリクエストするリソースを1つ以上選択し、「移動」アイコンをクリックして、それらのリソースを「選択したリソース」リストに移動します。

6. 「次」をクリックします。リソースの詳細を変更できるリソース関連ページが表示されます。リクエストする更新および関連情報を入力します。

注意:

リソース・インスタンスを変更するためのリクエストは同時に1つのみ要求でき、このモデルではバルク・リクエストはサポートされていません。別のリソース・インスタンスを変更する場合は、別のリクエストを要求する必要があります。

7. 「次」をクリックします。「理由」ページが表示されます。

8. 「有効日」フィールドおよび「理由」フィールドに値を入力し、リソースをアクティブにする日付およびリクエストの理由を説明するコメントをそれぞれ指定します。

9. 「終了」をクリックします。リクエストのステータスは、セルフサービス・ページの「リクエスト」タブで参照できます。リクエスト・タブの詳細は、第10章「リクエストの管理」を参照してください。

8.3.3 リソースの詳細の表示

リソースの詳細を表示する手順は、次のとおりです。

1. 「マイ・プロファイル」→「リソース」の順に移動します。

2. リソース情報表から、リソースを選択します。

3. 「アクション」リストから「リソースの詳細を開く」を選択します。選択したリソースのリソース名、説明、タイプ、ステータス、サービス・アカウント、プロビジョニングされた日などの詳細が含まれた「リソースの詳細」フォームが表示されます。

8.4 プロキシの管理

「プロキシ」タブでは、プロキシ情報を表示および管理できます。Oracle Identity Manager内に現在設定されているプロキシが表示され、以前設定したプロキシを表示することもできます。「過去のプロキシ」ビューは読取り専用で、変更は許可されません。

既存のプロキシ・ビューでは、開始日が将来の今後のプロキシを取り消すことができます。開始日が過去で、終了日が将来か指定されていない進行中のプロキシは、終了日のみを編集できます。

「プロキシ」タブで、新しいプロキシを追加することもできます。新しいプロキシを追加する場合は、開始日、終了日およびプロキシ・ユーザーを指定する必要があります。

この項には次のトピックが含まれます:

- プロキシの追加

- プロキシの編集

- プロキシの削除

8.4.1 プロキシの追加

プロキシを追加する手順は、次のとおりです。

1. 「マイ・プロファイル」→「プロキシ」の順に移動します。

2. 「現行のプロキシ」セクションで、「アクション」リストから「プロキシの追加」を選択します。「プロキシの追加」ウィンドウが表示されます。

3. 「プロキシ名」フィールドで「マネージャ」を選択し、プロキシとしてマネージャを指定します。それ以外の場合は、「他のユーザー」を選択し、プロキシとして他のユーザーを指定します。これを行うには、参照アイコンをクリックして、プロキシとして指定するユーザーを検索します。

注意:

ユーザーの検索結果は、認可ポリシーによって管理されます。詳細は、第15章「認可ポリシーの管理」を参照してください。

4. 「開始日」フィールドに、開始日を指定します。

5. 「終了日」フィールドに、終了日を指定します。

6. 「適用」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

7. 「はい」をクリックします。

注意:

Oracle Identity Managerでは、既存のプロキシと開始日および終了日が重複している別のプロキシを追加することはできません。

8.4.2 プロキシの編集

プロキシを編集する手順は、次のとおりです。

1. 「マイ・プロファイル」→「プロキシ」の順に移動します。

2. 「現行のプロキシ」セクションで、「アクション」リストから「プロキシの詳細を開く」を選択します。「プロキシ詳細」ウィンドウが表示されます。

3. 「プロキシ名」フィールドで「マネージャ」を選択し、プロキシとしてマネージャを指定します。それ以外の場合は、「他のユーザー」を選択し、プロキシとして他のユーザーを指定します。ユーザー名を検索できます。

注意:

プロキシ・ユーザーを変更する際に検索できるのは、検索権限があるユーザーのみです。

4. 「編集」をクリックします。アクティブ・プロキシの場合、プロキシ名と開始日は編集できませんが、開始されていないプロキシの場合は、プロキシ・ユーザー、開始日および終了日を変更できます。

5. 「適用」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

6. 「はい」をクリックします。

8.4.3 プロキシの削除

プロキシを編集する手順は、次のとおりです。

1. 「マイ・プロファイル」→「プロキシ」の順に移動します。プロキシのリストの表が表示されます。

2. 削除するプロキシを選択します。

3. 「現行のプロキシ」セクションで、「アクション」リストから「プロキシの削除」を選択します。「プロキシの削除」ウィンドウが表示されます。

4. 「削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

5. 「はい」をクリックします。

8.5 セキュリティの管理

「セキュリティ」タブでは、パスワード・セキュリティに関連するプロファイル属性を変更できます。このタブを使用して、次のタスクを実行できます。

- パスワードの変更

- チャレンジ質問および回答の設定

8.5.1 パスワードの変更

この機能を使用すると、エンタープライズ・パスワードをリセットできます。新しいパスワードを指定するには、新しいパスワードを入力し、そのパスワードを再確認します。新しいパスワードは、「パスワードの変更」ページに表示される適用可能なパスワード・ポリシーへの準拠について評価されます。新しいパスワードがパスワード・ポリシーに準拠していない場合は、パスワードの変更が却下され、失敗の状況が通知されます。すべてのポリシーと照合してパスワードが正常と評価された場合は、エンタープライズ・パスワードが変更されます。

パスワードを変更する手順は次のとおりです。

1. 「マイ・プロファイル」ページに移動し、「セキュリティ」タブをクリックします。

2. 「パスワード」セクションで、「パスワードの変更」をクリックします。「パスワードの変更」ウィンドウが、適用可能なパスワード・ポリシーとともに表示されます。

3. 「旧パスワード」フィールドに、既存のパスワードを入力します。

4. 「新規パスワード」フィールドに、設定する新しいパスワードを入力します。

5. 「新規パスワードの再入力」フィールドに、新しいパスワードを再入力します。

6. 「適用」をクリックします。旧パスワードが有効で、新しいパスワードがパスワード・ポリシーに準拠している場合、パスワードは変更されます。有効でない場合は、エラー・メッセージが表示されます。

8.5.2 チャレンジ質問および回答の設定

チャレンジ-回答サービスを使用すると、ユーザーのアイデンティティの検証に使用する一連のチャレンジ質問を設定できます。チャレンジ質問に対する正しい回答は、そのユーザーのみが認識している必要があります。

質問と回答は、名前と値のペア・リスト(名前は質問、値はその質問に対する回答)で、ユーザーのプロファイルの一部として格納されます。たとえば、ユーザーJohn Doeの場合、チャレンジ-回答のセットは次のようになります。

チャレンジ

レスポンス

好きな色は何ですか。

青

ペットの名前は何ですか。

Rex

出生地はどこですか。

New York

注意:

チャレンジ質問に対する回答は、そのユーザーに関する情報をインターネットまたは公的なソースから収集して容易に推測できないように定義することをお薦めします。

ユーザーのアイデンティティを認証スキームに依存せずに検証する必要がある場合は、チャレンジ質問が表示され、ユーザーは必要な数の正しい回答を入力する必要があります。

この機能に対するOracle Identity Managerの構成プロパティは、次のとおりです。

- PCQ.USE_DEF_QUES: エンドユーザーが独自のチャレンジ質問を作成できるようにOracle Identity Managerをカスタマイズしている場合は、このプロパティによって、ユーザーが事前定義のリストからチャレンジ質問を選択する必要があるかどうか、またはユーザーが独自のチャレンジ質問を作成する必要があるかどうかを指定します。デフォルトの値はTRUEです(ユーザーは事前定義のリストからチャレンジ質問を選択する必要があります)。ユーザーが独自のチャレンジ質問を入力する必要がある場合は、この値をFALSEに設定します。

注意:

エンドユーザーが独自のチャレンジ質問を作成する機能は、標準のすぐに使用できるユーザー・インタフェースではサポートされていません。

- PCQ.NO_OF_QUES: ユーザーが完了する必要のあるチャレンジ質問の数を設定します。デフォルト値は3です。

- PCQ.FORCE_SET_QUES: 新しいユーザーが初めてアプリケーションにログインしたときにチャレンジ質問を設定する必要があるかどうか、またはこのステップをスキップして後で設定できるかどうかを決定します。新しいユーザーは、チャレンジ質問を選択できるSelf.jspxページにリダイレクトされます。このページには、チャレンジ質問の設定プロセスをスキップできる「スキップ」ボタンが表示されます。

注意:

別のタブではAdmin.jspxページにアクセスできます。このページは、Oracle Identity Manager管理およびユーザー・コンソールでパスワード検証を実行する際にチャレンジ質問を設定するページと同じです。

- PCQ.NO_OF_CORRECT_ANSWERS: ユーザー・パスワードをリセットするために、ユーザーが正解する必要のある質問の数を表します。

チャレンジ質問および回答を設定する手順は、次のとおりです。

1. 「マイ・プロファイル」ページに移動し、「セキュリティ」タブをクリックします。

2. 「チャレンジ質問」セクションで、「質問1」、「質問2」および「質問3」フィールドから質問を選択します。

3. 対応する「回答1」、「回答2」および「回答3」フィールドで、回答を選択します。

4. 「適用」をクリックします。

8.5.2.1 チャレンジ質問および回答のローカライズ

次のデフォルトのチャレンジ質問は、Oracle Identity Manager内で自動的にローカライズされます。

- ペットの名前は何ですか。

- 出生地はどこですか。

- 好きな色は何ですか。

- 母親の旧姓は何ですか。

ローカライズされたデフォルトのチャレンジ質問は、xlWebAdmin_LANG.propertiesファイルに配置されます。ここで、LANGはロケール・コードです。

カスタムのチャレンジ質問をOracle Identity Manager Design Consoleの参照コードLookup.WebClient.Questionsに追加する場合は、対応するプロパティをカスタム・リソース・バンドルに追加して、質問テキストをサポート対象言語でローカライズします。対応する翻訳は、次のファイルに保存する必要があります。

CustomResource_LANG.properties

たとえば、新しいチャレンジ質問の「好きなスポーツは何ですか。」を追加できます。このテキストをローカライズするには、プロパティ・ファイルにプロパティを次の形式で追加します。

global.Lookup.WebClient.Questions.question-text=value

質問テキスト内の空白はハイフン(-)に置換します。たとえば、「好きなスポーツは何ですか。」というチャレンジ質問をフランス語にローカライズするには、次のプロパティをcustomResources_fr.propertiesファイルに追加します。

global.Lookup.WebClient.Questions.What-is-your-favorite-sport?= Quel est votre sport favori?

デフォルトのチャレンジ質問のテキストを変更するには、対応するプロパティをカスタム・リソース・バンドルに追加します。たとえば、「好きな色は何ですか。」という質問のテキストを変更して、米語のスペル(color)のかわりに英語のスペル(colour)を使用するには、CustomResource_en.propertiesファイルに次の新しいプロパティを追加します。

global.Lookup.WebClient.Questions.What-is-your-favorite-color?=What is your favourite colour?

特定のロケール用にデフォルトのチャレンジ質問のテキストを変更するには、変更した質問のプロパティをcustomResources.propertiesファイルと、ロケールの言語を表すcustomResource_lang.propertiesファイルに追加します。たとえば、日本語版のプロパティはcustomResources_ja.propertiesファイルに定義します。

8.6 忘れたパスワードのリセット

Oracle Identity Managerパスワードを忘れた場合は、一連のチャレンジ質問に対する回答を入力することでリセットできます。

忘れたパスワードをリセットするには、次の手順を実行します。

1. 「Oracle Identity Manager管理およびユーザー・コンソール」ログイン・ページで、「パスワードを忘れた場合」をクリックします。パスワードを忘れた場合ウィザードの「ユーザー・ログインを入力してください」ページが表示されます。

2. 「ユーザー・ログイン」フィールドに、ユーザー・ログインを入力して、Oracle Identity Managerでユーザー・レコードを見つけます。次に、「次」をクリックします。チャレンジ質問の回答ページが表示されます。

3. このページでは、ユーザー・アイデンティティを確認するために、ユーザー登録時に設定した、またはセルフサービスを使用して編集したチャレンジ質問がウィザードに表示されます。このページには、適用可能なパスワード・ポリシーも表示されます。チャレンジ質問の回答を入力し、「次」をクリックします。「新規パスワードの設定」ページが表示されます。

関連項目:

Oracle Identity Managerへの登録の詳細は、第7章「セルフサービス登録の構成および使用」を参照してください。

4. このステップでは、設定する新しいパスワードを入力し、「保存」をクリックします。次の結果が考えられます。

- 新しいパスワードが構成済のパスワード・ポリシーを満たさない場合は、指定したパスワードが満たしていないパスワード・ポリシーのルールを記載したエラー・メッセージが表示されます。また、パスワードのリセットの最大試行回数を超えた場合は、この操作を実行できなくなります。「ユーザーはパスワード・リセットの最大許容試行回数を超えました。」というエラー・メッセージが表示されます。

- アイデンティティの検証基準を満たし、パスワードが正常に設定された場合は、パスワードがリセットされたことを示すメッセージが表示され、セルフサービス・コンソールに自動的にログインします。

- ユーザー・アカウントが無効か、このアカウントに対してチャレンジ質問が定義されていない場合は、パスワードのリセットに失敗します。

注意:

「チャレンジ質問および回答の設定」で説明されているパスワードを忘れた場合ウィザードのチャレンジ質問を制御するPCQ.NO_OF_QUES構成プロパティは、次のとおりです。

- 尋ねるチャレンジ質問数: ウィザードに表示してその回答を収集するためのチャレンジ質問数を示す数字。

- 必要な正しい回答数: アイデンティティ検証テストに合格するために、正解する必要があるチャレンジ質問数を示す数字。この数は、以前の構成プロパティの数を超えることはできません。

9 タスクの管理

Oracle Identity Managerセルフサービスの「ようこそ」ページで、「タスク」をクリックすると、「マイ・タスク」ページが表示されます。このページには、特定のタイプのタスク・インスタンスが表示されます。これらのタイプは、特定のOracle Identity Managerコンポーネントに関連付けられています。タスク・タイプは、承認、プロビジョニングおよびアテステーションです。「マイ・タスク」ページは、管理者とエンドユーザーの両方が使用できます。たとえば、従業員にラップトップを配送するIT部門の担当者は、Oracle Identity Manager管理者ではありませんが、プロビジョニング・タスクを表示および変更する必要があります。

Oracle Identity Managerでは、次のタスク・タイプがサポートされています。

- 承認タスク: これらのタスクは、リクエスト・サービスによってインスタンス化され、承認するユーザーまたは管理者のキューにある関連リクエストに対応します。承認タスクの詳細は、「承認タスクの管理」を参照してください。

- プロビジョニング・タスク: これらのタスクは、ユーザーや管理者のキューで保留中の手動プロビジョニング・タスク、または失敗した自動プロビジョニング・タスクに対応します。プロビジョニング・タスクの詳細は、「プロビジョニング・タスクの管理」を参照してください。

- アテステーション・タスク: これらのタスクは、ユーザーまたは管理者のキューの未処理アテステーション・プロセスに対応します。アテステーション・タスクの詳細は、「アテステーション・タスクの管理」を参照してください。

注意:

Oracle Service Oriented Architecture (SOA)サーバーからフェッチされるのは承認タスクのみで、残りのタスクはOracle Identity Managerから取得されます。

9.1 承認タスクの管理

Oracle Identity Managerリクエスト・サービスは、SOAサーバーと相互作用して、Oracle Identity Managerワークフローにおけるユーザー相互作用の様々な側面を処理します。このリクエスト・サービスは、ユーザーやロールなどのアイデンティティにタスクを割り当てるために使用されます。ユーザーは、自分に割り当てられているタスクに対して様々な操作を実行できます。たとえば、タスクを承認、却下または要求したり、詳細情報をリクエストできます。対応するOracle Identity Managerワークフローのプロセス・フローは、特定のタスクの結果に依存します。

関連項目:

承認ワークフローの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認ワークフローに関する項を参照してください。

リクエストを送信すると、Oracle SOAサーバーでは、リクエスト・サービスによって承認がタスクとして開始されます。このタスクは、承認者に割り当てられます。リクエスト・サービスによるこのリクエストのその後の処理は、対応するタスクの結果に依存するため、保留のままとなります。承認者は、自分に割り当てられているすべてのタスクがリストされる、「すべてのタスク」セクションの「承認」タブにアクセスできる必要があります。承認者は、このタスクを実行してその結果を設定できます(承認や却下など)。タスク結果が設定されると、リクエスト・サービスは、タスク結果に基づいてリクエストの処理を再開します。

リクエストの送信が成功すると、リクエスト・サービスは、SOAにヒューマン・タスクを作成するリクエスト・サービスを起動し、それをOracle Identity Managerのユーザーまたはロールに割り当てます。認証されたユーザーは、アクションを待機しているタスクを「承認」タブに表示できます。Oracle Identity Managerセルフサービスで「タスク」をクリックすると、デフォルトで「承認」タブが開きます。

「承認」タブでは、次のタスクを実行できます。

- 承認タスクの検索

- タスクの詳細の表示

- タスクの要求

- タスクの承認

- タスクの却下

- タスクの再割当て

- 詳細情報のリクエスト

- 情報の送信

9.1.1 承認タスクの検索

「承認」タブでは、タスク名、リクエストID、開始日および終了日に基づいてリクエストを検索できます。検索結果は、「承認」タブの下部にある表に表示されます。「割り当てられたタスクの表示」リストから、次の項目を選択できます。

- 自分のみ: 自分に割り当てられている承認タスクのみが表示されます。

- 自分が所有するロール: 自分がメンバーとなっているロールに割り当てられているリクエストが表示されます。

- 自分および自分が所有するロール: 自分および自分がメンバーとなっているロールに割り当てられているリクエストが表示されます。

- 自分が管理するユーザー: 報告者に割り当てられているリクエストが表示されます。

「承認」タブの下部の表には、自分および自分のロールに割り当てられているすべてのタスクがデフォルトでリストされます。この表を使用すると、タスクに対して操作を実行したり、タスクの詳細を表示できます。タスクの詳細は、「タスクの詳細の表示」を参照してください。

表9-1に、完全タスクリスト・ビュー表の列を示します。

表9-1 完全タスクリスト・ビュー表の列

列

説明

リクエストID

承認タスクに関連付けられたリクエストのID。

リクエスト・タイプ

リクエストのタイプ。

受益者

リクエストの受益者。

リクエスト・ターゲット

リクエストに関連付けられたターゲット・エンティティ。ロール名、リソース名またはユーザー名のいずれかになります。

例1: リクエストが「ロールの割当て」タイプの場合は、ロール名です。

例2: リクエストが「リソースのプロビジョニング」タイプの場合は、リソース名です。

例3: リクエストが「ユーザーの変更」タイプの場合は、ユーザー表示名です。

リクエスタ

リクエストを作成および送信したユーザー。

割当て先

承認タスクが割り当てられたユーザーまたはロール。

割当て日

このタスクがユーザーまたはロールに割り当てられた日付。

9.1.2 タスクの詳細の表示

表内の承認タスクの「リクエストID」リンクをクリックすると、その承認タスクのタスク詳細が表示されます。

「タスクの詳細」ページの「基本の詳細」および「リクエスト情報」セクションには、リクエストの詳細ビューが表示されます。リストされているタスクを完全に管理できます。タスクの詳細ビューを表示するには、完全タスクリスト表の行を選択して、「アクション」リストから「タスクの詳細を開く」を選択します。

リクエスト・データセットの一部の属性が承認者専用とマークされている場合は、「承認者からの追加データ」という追加セクションが表示されます。承認者はこのセクションでデータを入力でき、このセクションがない場合(フィールドが必須とマークされている場合)、承認者はリクエストを承認できません。承認の次のレベルで、承認者は必要に応じてデータを変更できます。同様に、承認者が詳細情報をリクエストするためにタスクを別のユーザーに送信すると(「詳細情報のリクエスト」操作を使用)、割り当てられたユーザーは、「タスクの詳細」で「追加のリクエスト情報」という追加セクションを表示できるため、このユーザーはリクエストされた情報に対するレスポンスを送信できます。

さらに、次のタブには、リクエストに関連する詳細が表示されます。

- リソース、ユーザー、ロール: 「リソース」タブは、リクエスト・タイプに基づいて動的に生成されます。また、受益者のリスト、ターゲット・リソース名、およびターゲット・リソースに関する詳細を表示するためのリンクが表示されます。
「ユーザー」タブには、リクエストの一部であるユーザーの詳細が表示されます。たとえば、「ユーザーの作成」の場合、「ユーザー」タブにはユーザー名が表示され、「詳細の表示」リンクには、リクエスト作成時に入力したユーザーの属性が表示されます。

「ロール」タブには、リクエストの一部であるロールの詳細が表示されます。たとえば、追加または削除するロール名が表示されます。

- リクエストのコメント: このタブには、リクエストに関連付けられたリクエスト・コメントが表示されます。記録されるコメントは、「詳細情報のリクエスト」に対する質問と回答です。たとえば、承認者がユーザーに追加情報をリクエストしたコメントと、その問合せに対してユーザーが入力した回答のコメントがこのセクションに記録されます。

- リクエスト履歴: このタブには、実行プロセスを通じてリクエストに加えられた様々な変更が表示されます。

「タスクの詳細」ページで実行できるのは、タスク詳細の変更のみです。次の変更がサポートされています。

- 承認者は、対応するタスクを承認する前に一部の必須リクエスト情報を入力することが必要な場合があります。そのために、「タスクの詳細」ページに「承認者からの追加データ」セクションが表示され、承認者はこのセクションで必須情報を入力できます。

- 承認者は、タスクにコメントを明示的に追加できます。すべてのリクエスト・コメントは、「タスクの詳細」ページの「リクエストのコメント」タブに表示されます。詳細情報のリクエスト時または情報の送信時に、タスクにコメントを間接的に追加することもできます。詳細情報のリクエストおよび情報の送信については、それぞれ「詳細情報のリクエスト」および「情報の送信」を参照してください。

9.1.3 タスクの要求

タスクがロールに割り当てられている場合は、そのロールに属するすべてのユーザーのキューにそのタスクが表示されます。自分のロールに割り当てられているタスクを要求して、後で承認できます。たとえば、ユーザーにラップトップをプロビジョニングするためのリクエストが作成されると、リクエスト・レベルの承認はリクエスタのマネージャが実行するように構成され、操作レベルの承認は、リソースのIT管理者グループのメンバーであるユーザーが実行するように構成されます。したがって、リクエスト・レベルの承認が取得された後に、操作レベルの承認のためにリクエストが送信されます。この場合、リソースのIT管理者ロールのメンバーであるユーザーは、最初にタスクを要求して、後でそのタスクを承認または却下できる必要があります。

タスクを要求する手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスの「ようこそ」ページで、「タスク」をクリックします。

2. 「割り当てられたタスクの表示」リストから「自分が所有するロール」を選択します。自分がメンバーであるロールに割り当てられているタスクが、検索結果表に表示されます。

3. 要求するタスクを選択します。

4. 「アクション」リストから「タスクの要求」を選択します。タスクが正常に要求されたことを示すメッセージが表示されます。

9.1.4 タスクの承認

「承認」表に表示される「承認タスク」には、次の2つのレベルの承認があります。

- テンプレート・レベル

- リクエスト・レベル

- 操作レベル

注意:

テンプレート・レベルの承認では、「承認者からの追加データ」に属性の値を入力できます。

自分に割り当てられているリクエスト・レベル・タスクを承認する手順は、次のとおりです。

1. 「タスク」→「承認」の順に移動し、「検索」をクリックします。タスクを承認する前に情報を入力する必要がある場合、承認者は「タスクの詳細」ページの「承認者からの追加データ」セクションにその情報を入力します。

注意:

承認前に情報が必要なタスクに情報を入力していない場合は、「承認者からの追加データ」セクションに情報を入力するまでリクエストを承認できません。これが適用されるのは、リクエスト・データセットで必須とマークされているフィールドのみです。

2. 完全タスクリスト・ビュー表でリクエストを選択します。

3. 「アクション」リストから「タスクの承認」を選択します。リクエストが承認されて、完全タスクリスト・ビュー表に表示されなくなります。

自分に割り当てられている操作レベル・タスクを承認する手順は、次のとおりです。

1. 「タスク」→「承認」の順に移動し、「検索」をクリックします。操作レベル・リクエストが表示されます。

2. 完全タスクリスト・ビュー表でリクエストを選択します。

3. 「アクション」リストから「承認」を選択します。リクエストが承認されて、完全タスクリスト・ビュー表に表示されなくなります。

9.1.5 タスクの却下

自分に割り当てられているリクエストを却下する手順は、次のとおりです。

1. 「タスク」→「承認」の順に移動し、「検索」をクリックします。

2. 完全タスクリスト・ビュー表でリクエストを選択します。

3. 「アクション」リストから「タスクの却下」を選択します。リクエストの却下に関するコメントを入力するように求められます。

4. コメントを入力し、「却下」をクリックします。タスクが却下されて、完全タスクリスト・ビュー表に表示されなくなります。ここに入力したコメントは、「タスクの詳細」ページの「リクエストのコメント」セクションに記録されます。

9.1.6 タスクの再割当て

自分に割り当てられているリクエストを再割当てする手順は、次のとおりです。

1. 「タスク」→「承認」の順に移動し、「検索」をクリックします。

2. 完全タスクリスト・ビュー表でリクエストを選択します。

3. 「アクション」リストから「再割当て」を選択します。「タスクの再割当て」ダイアログ・ボックスが表示されます。

4. タスクを再割当てするユーザーまたはロールを検索して選択します。

5. 「再割当て」をクリックします。

注意:

Oracle Identity Managerタスク・リストでサポートされる機能は、SOAヒューマン・ワークフロー・コンポーネントで提供される機能のサブセットです。

9.1.7 詳細情報のリクエスト

承認者は、タスクに関連付けられているリクエストに関する詳細情報をリクエスタまたは他のユーザー(Oracle Identity Managerのユーザー)にリクエストできます。このアクションを実行すると、タスクは「情報のリクエスト」(RFI)タイプのタスクに変換されて、指定したユーザーに割り当てられます。このアクションは、「タスクの詳細」ビューでのみ実行できます。承認者とユーザー間での情報の交換は、「タスクの詳細」ページの「コメント」タブに追加されます。

タスクに関する詳細情報をリクエストする手順は、次のとおりです。

1. 「タスク」→「承認」の順に移動し、「検索」をクリックします。

2. 検索結果でリクエストIDリンクをクリックし、「タスクの詳細」ウィンドウを開きます。

3. タスクの「タスクの詳細」ウィンドウで、「アクション」リストから「詳細情報のリクエスト」を選択します。「詳細情報のリクエスト」ダイアログ・ボックスが表示されます。

4. 「宛先」フィールドでリクエスタを選択するか、タスクに関する詳細情報をリクエストする他のユーザーを検索して選択します。

5. 必要な情報の詳細を入力します。

6. 「リクエストの送信」をクリックします。追加情報用のタスクが送信されたことを示すメッセージが表示されます。

7. 「OK」をクリックします。

図9-1に示すように、情報のリクエスト先のユーザーがOracle Identity Managerセルフサービスの「承認」タブ・ページでそのリクエストを表示すると、RFIがタスク・プレビューに追加されています。

図9-1 RFIタスク

「図9-1 RFIタスク」の説明

9.1.8 情報の送信

このアクションは、「RFI」タイプのタスクにのみ適用できます。リクエストされた情報をタスク・コメントを使用して入力した後は、このアクションを使用してその情報を送信します。このアクションを実行すると、タスクは元の承認タスクに再度変換されます。これは、詳細情報をリクエストした元のユーザーに再割当てされ、そこからタスク承認フローが続行されます。このアクションは、「タスクの詳細」ビューでのみ実行できます。

ユーザーは、このアクションを使用して、承認者がリクエストした追加情報を送信できます。リクエストされた問合せが表示され、ユーザーは詳細を入力する必要があります。情報の交換は、コメントとして記録されます。

タスクを選択して「アクション」メニューを展開した場合、「タスクの承認」、「タスクの却下」、「タスクの再割当て」および「タスクの要求」オプションは使用できませんが、これは、これらのアクションを実行する前に、リクエストされた情報を入力する必要があるためです。図9-2に示すように、使用できるのは「タスクの詳細」オプションのみのため、タスクの詳細を表示して、リクエストされた情報を入力します。

図9-2 RFIタスクの使用可能オプション

「図9-2 RFIタスクの使用可能オプション」の説明

情報を送信する手順は、次のとおりです。

1. 「タスクの詳細: 承認」タブで、RFIタスクの「リクエストID」リンクをクリックします。または、RFIタスクを選択して、「アクション」メニューから「タスクの詳細を開く」を選択します。図9-3に示すように、RFIタスクの「タスクの詳細」ビューが表示されます。

図9-3 RFIのタスク詳細

「図9-3 RFIのタスク詳細」の説明

2. 「追加のリクエスト情報」セクションの「レスポンス」フィールドに、タスクに関してリクエストされた情報を入力します。

3. 「承認者への送信」をクリックします。追加情報が正常に送信されたことを示すメッセージが表示されます。

4. 「OK」をクリックします。

承認者に送信されると、このタスクは元の承認者に再割当てされます。承認者は、このタスクを承認、却下、再割当てまたは要求できます。

送信されたリクエストの追加情報はすべて、「タスクの詳細」ページの「リクエストのコメント」タブに表示できます。

9.2 プロビジョニング・タスクの管理

このタブには、自分に割り当てられたすべてのプロビジョニング・タスク、または受信ボックス内にある保留中のアクションが表示されます。さらに、修正措置を実行するために確認する必要がある失敗した自動プロビジョニング・タスクが、受信ボックスに表示されます。これらのタスクに対して再試行や手動による完了などの修正措置を実行する必要があります。

プロビジョニング・タスク機能は管理者およびユーザーが使用します。たとえば、従業員にラップトップ・コンピュータを配送するIT管理の担当者は、Oracle Identity Manager管理者ではありませんが、プロビジョニング・タスクを表示および変更する必要があります。

「プロビジョニング」タブでは、次のタスクを実行できます。

- プロビジョニング・タスクの検索

- プロビジョニング・タスクの詳細の表示

- タスクへのメモの追加

- タスクの再割当て

- タスク割当て履歴の表示

- フォームの詳細の表示

- フォームの詳細の変更

- タスクの再試行

9.2.1 プロビジョニング・タスクの検索

「プロビジョニング」タブ・ページの最初のセクションでは、自分に割り当てられている、およびアクションが保留中のプロビジョニング・タスクを検索できます。プロビジョニング・タスクを検索するには、次のフィールドに値を指定します。

- 一致: 指定した検索基準のすべてに一致する必要がある場合は、「すべて」を選択します。指定した検索基準のいずれかに一致する必要がある場合は、「いずれか」を選択します。

- タスク名: 検索するタスク名を指定します。これを行うには、「次と等しい」、「次を含む」、「次で始まる」または「次で終わる」検索操作のいずれかを選択します。

- リソース名: 検索するプロビジョニング・タスクのリソース名を指定します。これを行うには、「次と等しい」、「次を含む」、「次で始まる」または「次で終わる」検索操作のいずれかを選択します。

- ステータス: アクションが保留中のタスクまたは却下されたタスクを検索する場合は、「保留」または「却下」をそれぞれ選択します。

検索基準を指定して「検索」をクリックすると、検索結果表が表示されます。表9-2に、検索結果表のフィールドを示します。

表9-2 プロビジョニング・タスク検索結果表のフィールド

フィールド

説明

タスク名

タスクの名前。

タスク・ステータス

タスクのステータス(「保留」または「却下」)。

リソース名

タスクによって影響を受けるリソースの名前。

受益者

このタスクのために影響を受けるプロビジョニング・リソースのユーザー。

割当て日

プロビジョニング・タスクが割当て先に割り当てられた日付と時刻。

割当て先

タスクが割り当てられたユーザー。

9.2.2 プロビジョニング・タスクの詳細の表示

プロビジョニング・タスクの詳細を表示する手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、詳細を表示するタスクを選択します。

3. 「アクション」リストから「タスクの詳細を開く」を選択します。

表9-3に、「タスクの詳細」ウィンドウのフィールドを示します。

表9-3 「タスクの詳細」ウィンドウのフィールド

フィールド

説明

タスク名

タスクの名前。

リソース名

タスクによって影響を受けるリソースの名前。

説明

タスクの説明。

ユーザー

受益者のユーザー名。

ステータス

タスクのステータス(「保留」または「却下」)。

レスポンス

「レスポンスの設定」ページでユーザーが設定したレスポンス。

注: レスポンス設定の詳細は、「タスクに対するレスポンスの設定」を参照してください。

レスポンスの説明

Oracle Identity Manager Design Consoleのタスク定義セクションの「レスポンス」タブで定義したレスポンスの説明。

注意

承認者が入力した追加コメント。

割当て先

このタスクが割り当てられたユーザーまたはロール。

注: タスクがロールに割り当てられた場合、このプロパティは「ロールに割当て済」となり、ロールの詳細が表示されます。

エラーの詳細

レスポンス設定時のエラー(ある場合)。

開始予定

タスクの開始が予定されている日付。

終了予定

タスクの終了が予定されている日付。

実際の開始

タスクが開始された日付。

実際の終了

タスクが終了した日付。

最終更新日

タスクが最後に更新された日付。

9.2.3 タスクに対するレスポンスの設定

承認者は、タスクを処理する際にタスクに対するレスポンスを設定できます。タスクに対するレスポンスを設定する手順は、次のとおりです。

注意:

対応するタスクにレスポンス・コードが定義されていない場合は、レスポンスを設定できません。レスポンス・コードは、Oracle Identity Manager Design Consoleを使用して定義します。レスポンス・コードの定義の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、詳細を表示するタスクを選択します。

3. 「アクション」リストから「タスクの詳細を開く」を選択します。「タスクの詳細」ウィンドウが表示されます。

4. 「タスクのレスポンスの指定」ページで、定義されている複数のレスポンスのいずれかを選択し、「レスポンスの設定」をクリックします。

9.2.4 タスクへのメモの追加

メモは、承認者が入力する追加コメントです。これらのコメントはオプションです。

タスクにメモを追加する手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、詳細を表示するタスクを選択します。

3. 「アクション」リストから「タスクの詳細を開く」を選択します。「タスクの詳細」ウィンドウが表示されます。

4. 「タスクの詳細」ウィンドウで、「注意の追加」をクリックします。図9-4に示すように、「タスクへの注意の追加」ウィンドウが表示されます。

図9-4 「タスクへの注意の追加」ウィンドウ

「図9-4 「タスクへの注意の追加」ウィンドウ」の説明

5. 「追加の注意の入力」フィールドに、タスクに追加するメモを入力します。

6. 「注意の追加」をクリックします。

9.2.5 タスクの再割当て

承認者は、タスクに対して適切なアクションを実行する別のユーザーまたはロールにタスクを再割当てできます。タスクを別のユーザーに再割当てすると、割当て先が承認者になります。タスクをロールに再割当てすると、そのロールのメンバーの一人がタスクを承認または却下できます。

タスクを別のユーザーまたはロールに再割当てする手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、詳細を表示するタスクを選択します。

3. 「アクション」リストから「タスクの詳細を開く」を選択します。「タスクの詳細」ウィンドウが表示されます。

4. 「タスクの詳細」ウィンドウで、「再割当て」をクリックします。図9-5に示すように、「タスクの割当先ユーザーの選択」ウィンドウが表示されます。

図9-5 「タスクの割当先ユーザーの選択」ウィンドウ

「図9-5 「タスクの割当先ユーザーの選択」ウィンドウ」の説明

5. 検索する内容に従って、「ユーザー」または「ロール」を選択します。選択に応じて、ユーザーまたはロールのリストが表示されます。フィルタ処理の基準を指定するか、「フィルタ条件」フィールドに値を入力して、検索をフィルタ処理することもできます。

6. 「再割当て」列で、タスクを割り当てるユーザーまたはロールを選択します。

7. 「再割当て」をクリックします。

8. 「再割当てするタスクの確認」ページで、実行するアクションの詳細を確認し、「再割当てタスクの確認」を選択してタスクを再割当てするか、「再割当てタスクの取消し」を選択してタスクの再割当てを取り消します。

9. 前述の再割当てアクションに従って、「割当て先」セクションの値が適切に更新されているかどうかを確認します。

9.2.6 タスク割当て履歴の表示

タスクの割当て履歴を表示する手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、詳細を表示するタスクを選択します。

3. 「アクション」リストから「タスクの詳細を開く」を選択します。「タスクの詳細」ウィンドウが表示されます。

4. 「タスクの詳細」ウィンドウで、「タスク割当て履歴」をクリックします。図9-6に示すように、「タスクの履歴」ウィンドウが表示されます。

図9-6 「タスクの履歴」ウィンドウ

「図9-6 「タスクの履歴」ウィンドウ」の説明

表9-4に示すように、各フィールドにはタスク割当て履歴が表示されます。

表9-4 「タスクの履歴」ウィンドウのフィールド

フィールド

説明

タスク・ステータス

タスクのステータス(「保留」または「却下」)。

タスク・アクション

タスクのソース詳細で、たとえば、最初に作成されたタスクは「エンジン」になります。ユーザーがこのタスクを再割当てすると、「ユーザー」になります。

割当てタイプ

タスクの割当て先のタイプで、たとえば、初めて割り当てられたタスクは、「デフォルトのタスク割当て」になります。タスクが再割当てされると、その値はユーザーまたはロールになります。

ユーザーに割当て済

タスクが割り当てられたユーザー。

ロールに割当て済

タスクが割り当てられたロール。

割当て元

タスクを割り当てたユーザー。

割当て日

タスクが割り当てられた日付。

9.2.7 フォームの詳細の表示

タスクに付加されているプロセス・フォームを表示できます。これらは、基礎となるプロセス定義に関連付けられているプロセス・フォームです。タスクは、プロセス定義に埋め込まれています。

タスクに付加されているプロセス・フォームを表示する手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、プロセス・フォームを表示するタスクを選択します。

3. 「アクション」リストから「フォームを開く」を選択します。「フォームの表示」ウィンドウが表示されます。

9.2.8 フォームの詳細の変更

プロセス・フォームの詳細を変更する手順は、次のとおりです。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、プロセス・フォームを変更するタスクを選択します。

3. 「アクション」リストから「フォームの編集」を選択します。

4. 必要な詳細を変更し、「保存」をクリックします。

9.2.9 タスクの再試行

承認者は、最初の試行でレスポンスを設定した際にエラーが生成された場合、タスクを再試行できます。タスクを再試行する手順は、次のとおりです。

注意:

再試行できるのは自動タスクのみで、アダプタをタスクに添付する必要があります。手動タスクは再試行できません。

1. 「タスク」→「プロビジョニング」の順に移動し、「検索」をクリックします。

2. 「プロビジョニング」タブの検索結果表で、再試行するタスクを選択します。

3. 「アクション」リストから「タスクの再試行」を選択します。タスクが正常に試行されたかどうかのステータスを示すメッセージが表示されます。

9.3 アテステーション・タスクの管理

アテステーションを使用すると、レビューアとして指定されたユーザーは、レビューする必要のあるレポートについて通知を受けることができます。これらのレポートには、他のユーザーのプロビジョニング済リソースについて記述されています。レビューアは、レスポンスを入力することにより、権限の正確さをアテストすることができます。アテステーション・アクションは、レビューアが入力したレスポンス、関連コメント、およびレビューアが参照してアテストするデータの監査ビューとともにトラッキングと監査を受け、アカウンタビリティの完全な証跡を残します。Oracle Identity Managerでは、このプロセスはアテステーション・タスクと呼ばれます。

アテステーション・プロセスは、アテステーション・タスクを設定するメカニズムです。アテステーション・プロセスに必要な入力内容には、アテステーション・タスクを構成するコンポーネントの定義方法、およびタスクを実行する必要のあるスケジュールとアテステーション・タスクを関連付ける方法に関する情報が含まれます。この定義も、アテステーション・タスクを必要なときに開始するための基盤です。

Oracle Identity Managerセルフサービスの「アテステーション」タブには、自分に割り当てられている、または受信ボックス内のアクションが保留中のアテステーション・プロセスすべてが表示されます。「マイ・タスク」セクションで、「アテステーション」タブをクリックすると、「アテステーション」ページが表示されます。

注意:

Oracle Identity Analytics (OIA)と統合されたOracle Identity Managerを使用する場合は、アテステーション機能が置換されます。

「アテステーション」タブでは、次のタスクを実行できます。

- アテステーション・タスクの検索

- アテステーション・リクエスト詳細の表示

9.3.1 アテステーション・タスクの検索

アテステーション・タスクを検索する手順は、次のとおりです。

1. 「タスク」→「アテステーション」の順に移動します。

2. 「アテステーション」タブの「タスクの検索」セクションで、「すべて」を選択して指定した基準すべてに一致するタスクを検索します。それ以外の場合は、「いずれか」を選択して基準のいずれかに一致するタスクを検索します。

3. 「タスク名」フィールドに、検索するタスクの名前を入力します。これを行うには、「次と等しい」、「次を含む」、「次で始まる」または「次で終わる」検索演算子を選択します。

4. 「開始日」フィールドで、このフィールドの横にある「開始日」アイコンを使用してタスクの開始日を指定します。これを行うには、「次より後」、「次と等しい」または「次より前」検索演算子を選択します。

5. 「検索」をクリックします。検索基準に一致するアテステーション・タスクが検索結果表に表示されます。表9-5に、検索結果表のフィールドを示します。

表9-5 アテステーション・タスク検索結果表のフィールド

フィールド

説明

タスク名

タスクの名前。

プロセス・コード

ユーザーが入力したタスクの一意の識別子。

開始日

アテステーション・タスクの開始日。

タイプ

タスクのタイプ。これは、「アクセス権」としてハードコードされます。

レコード数

検索結果として表示されるレコード数。

9.3.2 アテステーション・リクエスト詳細の表示

アテステーション・リクエスト詳細を表示する手順は、次のとおりです。

1. 「タスク」→「アテステーション」の順に移動します。

2. 「アテステーション」タブで、リクエスト詳細を表示するアテステーション・タスクを選択します。

3. 「アクション」リストから「アテステーション・リクエストの詳細」を選択します。図9-7に示すように、「アテステーション・リクエストの詳細」ウィンドウが表示されます。

注意:

レビューアとして指定された複数のユーザーが、アテステーション・リクエストの詳細を表示できます。ただし、アテステーションを送信できるのは、最初に送信したユーザーのみです。

図9-7 「アテステーション・リクエストの詳細」ウィンドウ

「図9-7 「アテステーション・リクエストの詳細」ウィンドウ」の説明

表9-6に、「アテステーション・リクエストの詳細」ウィンドウのフィールドを示します。

表9-6 「アテステーション・リクエストの詳細」ウィンドウのフィールド

フィールド

説明

プロセス

作成されたアテステーション・プロセスの名前。

リクエスト時間

リクエストが作成された時間。

すでにアクションが指定されている場合はレコードを非表示にします

アクションが指定されているレコードをアテステーション・リクエストのリストで非表示にする必要があるかどうか。

ユーザー

権限がアテスト対象となっているユーザー。データはリンクとして表示されます。このリンクをクリックすると、「ユーザー・プロファイル」ページが表示され、アテステーション日のユーザーの詳細が表示されます。

リソース

アテストされる権限の基盤であるリソース。データはリンクとして表示されます。リンクをクリックすると、ページが表示され、アテステーション日の権限のプロセス・フォーム・データが表示されます。

記述データ

プロビジョニング・リソース・インスタンスの説明。

最終アテスト日

アテステーションに対して入力された最後のレスポンス。

コメント

レビューア・コメント。「既存のコメントおよび委任情報を更新」をクリックすると、このフィールドのコメントが更新されます。長いコメントは切り捨てられ、ツールチップを使用してコメントの全文が表示されます。

アクション

リクエストに対して実行するアクション。次のいずれかの値を使用できます。

- 認証

- 却下

- 拒否

- 委任

アテステーションの送信

アテステーション・リクエストを送信する場合は、このボタンをクリックします。

保存

アテステーション・リクエストを今後送信するために保存する場合は、このボタンをクリックします。

10 リクエストの管理

Oracle Identity Managerでは、ユーザーの作成やリソースのプロビジョニングなどの様々な操作をリクエストを介して実行できます。リクエストは特定のアクションを実行するユーザーまたは管理者が作成したエンティティで、アクションを実行するには、誰かまたはなんらかのプロセスから事前に任意の権限を取得しておく必要があります。たとえば、ユーザーはラップトップ・コンピュータへのアクセス権を取得するためのリクエストを作成し、マネージャはそのリクエストに基づいてオープン購買依頼を作成できます。

リクエストでは、リクエスタ、受益者(オプション)およびターゲット・エンティティを使用します。リクエスタは、リクエストを作成または要求するエンティティです。リクエスタは、ユーザーまたはシステム自体の場合があります。システム生成リクエストのリクエスタは、機能コンポーネントによって決定されます。システム生成リクエストの例には、アクセス・ポリシーに基づいてシステムが作成するリクエストがあります。この場合、機能コンポーネントはアクセス・ポリシーです。未認証リクエストの場合、リクエスタはOracle Identity Managerに対して認証されないため、システムに存在しません。

受益者は、リクエストの完了後に実行されたアクションから利益を得るエンティティですが、このリクエストが完了するのは、リクエストが正常に実行された場合のみです。

Oracle Identity Managerでは、ユーザー、組織、ロールおよびリソースなどの用語はエンティティとして定義されます。各エンティティは、それぞれに属する属性のリストを保守します。各エンティティは、サポートする操作のリストも定義します。

ターゲット・エンティティは、受益者のためにリクエストされるリソースです。

たとえば、ユーザーJohn DoeにUNIXアカウントをプロビジョニングするリクエストを作成します。この場合、自分はリクエスタ、John Doeは受益者、UNIXアカウントはJohn Doeのためにリクエストされるターゲット・エンティティです。

各リクエストは、システムで作成された後、特定のライフサイクルを通過します。このライフサイクルは、リクエスト・サービスによって管理および制御されます。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対して使用可能な操作、およびその時点で遷移が可能なステージが決定します。図10-1に、リクエストのプロセス・フローの概要を示します。

図10-1 リクエスト・プロセス・フロー

「図10-1 リクエスト・プロセス・フロー」の説明

リクエスト・プロセス・フローの説明では、リクエストを介してユーザーにラップトップ・コンピュータをプロビジョニングする例を使用します。ステップは次のとおりです。

1. リクエスタは、リクエストUIを使用して、ユーザーにラップトップ・コンピュータを割り当てるリクエストを要求します。

注意:

リクエストは、Oracle Identity ManagerセルフサービスまたはOracle Identity Managerアイデンティティ管理を使用して要求できます。

2. リクエストは、リクエスト・サービスに送信されます。

3. リクエストは、Oracle Identity Managerデータベースにも格納されます。

4. テンプレート・レベルの承認ワークフローは、サービス指向アーキテクチャ(SOA)のリクエスト・サービスによって開始されます。

5. テンプレートに承認プロセスがある場合、承認ワークフローはテンプレート・レベルで開始されます。テンプレートに承認プロセスがない場合、リクエストは自動承認されます。

6. リクエスト・レベルの承認ワークフローは、サービス指向アーキテクチャ(SOA)のリクエスト・サービスによって開始されます。ワークフロー構成に基づいて、関連するタスクは対応する承認者に割り当てられます。

関連項目:

承認レベルおよび承認ワークフローの詳細は、Oracle identity Manager開発者ガイドの承認ワークフローに関する項を参照してください。

7. リクエスト・レベルの承認者は、Oracle Identity Managerセルフサービスのタスクリストを使用してリクエストを承認します。この例では、リクエスタのマネージャ(承認者1)が、ユーザー1にラップトップを割り当てるかどうかを決定するリクエスト・レベルの承認者です。リクエスト・レベルの承認者がリクエストを却下すると、リクエストは「却下」ステージに移動します。

8. 承認者1が自身のロールを承認者2に指定している場合は、承認者2が、ユーザー1にラップトップを割り当てるかどうかを決定するリクエスト・レベルの承認者です。承認者2がリクエストを却下すると、リクエストは「却下」ステージに移動します。

9. 操作レベルの承認者は、タスクリストを使用してリクエストを承認します。この例では、組織のIT管理者がユーザーへのラップトップの発行を担当する操作レベルの承認者(承認者2)です。操作レベルの承認者がリクエストを却下すると、リクエストは「却下」ステージに移動します。

注意:

リクエストがリクエスト・レベルで却下された場合、操作レベルのリクエストは開始されません。

10. リクエスト操作はリクエスト・サービスで開始されて、リクエストが実行されます。

11. リクエスト操作が完了します。このステージで、リクエスト操作が「完了」ステータスになります。

12. リクエスト・ステータスが、Oracle Identity Managerデータベースで更新されます。

この章では、リクエスト管理について次の各項で説明します。

- リクエストのステージ

- バルク・リクエストと子リクエスト

- リクエスト・モデル

- 自分および他のユーザーのためのリクエストの作成

- リクエストの検索

- リクエストの取消し

- タスク・リストを使用したリクエスト関連タスクの実行

- リクエストのクローズ

10.1 リクエストのステージ

各リクエストは、システムで作成された後、特定のライフサイクルを通過します。このライフサイクルは、リクエスト・サービスによって管理および制御されます。ライフサイクルによって、リクエストは様々なステージに遷移します。リクエストが存在するステージによって、コントローラがそのステップで実行するアクション、リクエストに対してその時点で使用可能な操作、および遷移が可能なステージが決定します。図10-2に、リクエスト・サービスにおけるリクエストのライフサイクル・フローの概要を示します。

図10-2 リクエストのステージ

「図10-2 リクエストのステージ」の説明

注意:

リクエストが正常に送信されない場合は、エラー・メッセージがUIに表示されます。SPML開始リクエストの場合は、エラー・メッセージがSPMLにスローされます。

図10-2は、リクエストが通過できるすべてのステージを示しています。この図は、単純なリクエストの各ステージを示しています。バルク・リクエストの詳細は、「図10-3 バルク・リクエストと子リクエストのステージ」を参照してください。

各ステージは、リクエスト・ライフサイクルにおける論理的な次のステップを表しています。リクエストが1つのステージから次のステージに移動できるのは、操作が正常に実行された場合のみです。

表10-1に、ライフサイクルの様々なステージでのリクエストの機能、およびリクエストのこれらのステージへの到達方法を示します。

表10-1 リクエストのステージ

リクエストのステージ

説明

作成

正常に送信されたリクエストは、「作成」ステージに移動します。

承認の取得

作成されたリクエストに承認が定義されている場合は、リクエスト・エンジンがそのリクエストを承認の取得ステージに自動的に移動します。このステージでは、リクエスト・エンジンが最初にリクエスト・テンプレートを参照して、承認が定義されているかどうかを検索します。承認が検出された場合は、対応する承認がリクエスト・サービスを介して開始されます。完了と同時に、リクエスト・エンジンは、このリクエストに定義されているモデルを参照して承認の選択方法を検索し、インスタンス化する正確な承認プロセスを検出します。

リクエスト・エンジンは、開始する必要のある承認を検出すると、リクエスト・サービスを再度コールしてワークフローをインスタン化します。

このステージでリクエストが取り消されるかクローズされた場合、リクエスト・エンジンはワークフロー・インスタンスごとにワークフローの取消しをコールします。タスクの取消しに関する通知が承認者に送信されます。

注: 通知の構成は、SOAコンポジットのヒューマン・タスクで実行できます。

次のリクエスト・ステータスが承認の取得ステージに関連付けられています。

- テンプレート承認を取得しています

- リクエスト承認を取得しています

- 操作承認を取得しています

これらのリクエスト・ステータスの詳細は、「バルク・リクエストと子リクエスト」を参照してください。

これらのステータスを正常に完了したリクエストは、リクエスト承認済ステージに到達します。

リクエストが正常に作成された後に検証チェックがプラグインされる場合、リクエストは次のステータスに関連付けられます。

- SoDチェックが開始されていません
リクエストに基づいたリソースのプロビジョニングに対してSoD検証が開始されない場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

- SoDチェックが開始されました
リクエストに基づいたリソースのプロビジョニングに対してSoD検証が非同期で開始された場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

- SoDチェックが完了しました
リクエストに基づいたリソースのプロビジョニングに対してSoD検証が完了した場合、リクエストはこのステージに到達します。リクエスト・エンジンは、リクエストの送信後かつ承認の取得前に、リクエストをこのステージに移動します。

注意: これらのリクエスト・ステータスが可能なのは、リクエストがリソースのプロビジョニング・リクエストであるか、リクエストでリソースのプロビジョニング・リクエストを変更する場合です。

承認

操作承認が承認された場合のみ、リクエストは次のステージに移動し、リクエスト・エンジンは現在のステータスで更新されます。リクエスト・エンジンが検出する結果は、「承認」、「却下」または「保留」です。

次のリクエスト・ステータスがこのステージに関連付けられています。

- テンプレート承認が承認されました

- リクエスト承認が承認されました

- 操作承認が承認されました

却下

ワークフロー・インスタンスが更新されるたびに、リクエスト・サービスは、リクエスト・エンジンをそのインスタンスの現在のステータスで更新します。リクエスト・エンジンが想定しているリクエスト・サービスからの結果は、「承認」または「却下」です。インスタン化されたワークフロー・インスタンスが却下された場合、リクエスト・エンジンはリクエストを「却下」ステージに移動します。任意のワークフロー・インスタンスが却下された場合、コントローラはすべての保留中のワークフローを取り消して、リクエストを「却下」ステージに移動します。

次のリクエスト・ステータスがこのステージに関連付けられています。

- テンプレート承認が却下されました

- リクエスト承認が却下されました

- 操作承認が却下されました

操作が開始されました

リクエストが承認されると、リクエスト・エンジンはリクエストを「操作が開始されました」ステージに移動して、操作を開始します。

次のリクエスト・ステータスがこのステージに関連付けられています。

- 操作が完了しました
実際のリクエスト操作が完了すると、リクエスト・エンジンはリクエストを「操作が完了しました」ステージに移動します。これは、「操作が開始されました」ステータスの後に発生し、「完了」ステージに関連付けられます。

- ポスト操作処理が開始されました
実際のリクエスト操作が完了した後、実行する必要がある追加操作が後処理として存在する場合、リクエスト・エンジンは、その操作を開始する前に、リクエストを「ポスト操作処理が開始されました」ステージに移動します。これが実行されるのは、「操作が完了しました」ステータスの後です。

失敗

リクエストに指定されている関連操作の実行に失敗した場合、リクエストは保留中の操作を取り消して「リクエストに失敗しました」ステージに移動します。このステージに関連付けられているリクエスト・ステータスは「リクエストに失敗しました」および「リクエストの一部が失敗しました」で、これらはリクエストに指定されている関連操作のすべてが失敗か、一部が失敗かに基づいて設定されます。

取消し済

リクエスタはリクエストを取り消すことができます。このステージでは、リクエストが「リクエストが取り消されました」ステータスに関連付けられ、図10-2の複数のエントリ・ポイントで示されているように、すべての承認の開始が取り消されます。

注意:

- リクエストを取り消すことができるのは、「操作が開始されました」ステージの前です。「操作が開始されました」ステージに到達したリクエストは、取り消すことができません。

- リクエストは、Oracle Identity Managerセルフサービスからはいつでも取り消すことができますが、拡張管理からは取り消すことができません。

完了

リクエストに指定されたすべての操作の実行が完了すると、リクエスト・エンジンはリクエストを「リクエストが完了しました」ステージに移動します。

次のリクエスト・ステータスがこのステージに関連付けられています。

- リクエストがエラーで完了しました
実際のリクエスト操作が正常に実行されても後処理操作のいずれかの実行に失敗した場合、リクエストはこのステータスに到達します。「リクエストがエラーで完了しました」ステージは「失敗」ステージに関連付けられています。

- リクエストが完了しました
実際のリクエスト操作がエラーなしに正常に実行された場合、リクエストはこのステータスに到達します。

- リクエストが完了待ちです
リクエストが将来の日付で実行するようにスケジュールされている場合、リクエストは「リクエストが完了待ちです」ステータスに到達し、操作が有効日に完了するまで待機します。

ステージに正常に到達すると、リクエストのステータスも対応するステータスに更新されます。

操作は、手動で実行するか、イベントに対応してシステムで自動的に実行できます。手動操作の例を次に示します。

- リクエストの送信。

- リクエストのクローズ/取消し。

- 承認ワークフローが正常に承認されたことがサービスに通知されたときのリクエストの承認。

自動操作の例を次に示します。

- リクエストが送信されたときの承認の開始。

- リクエストが承認され、かつ実行日が過去または指定されていない場合のリクエストの実行。

10.2 バルク・リクエストと子リクエスト

バルク・リクエストは、複数の受益者または複数のターゲット・エンティティ(あるいはその両方)を含むリクエストです。たとえば、ユーザーJohn Doeに複数のロールを割り当てるリクエストでは、バルク・リクエストが生成されます。ユーザーJohn DoeおよびJane DoeにADユーザーなどのリソースをプロビジョニングするプロビジョニング・リクエストでも、バルク・リクエストが生成されます。バルク・リクエストには、2つの部分があります。

- 親リクエスト: 複数の受益者または複数のターゲット・エンティティ(あるいはその両方)を含めて送信されたリクエストは、親リクエストです。

- 子リクエスト: 親リクエストに対してリクエスト・レベルの承認が発生した場合は、複数の子リクエストが作成されます。親リクエストは、1人の受益者と1つのターゲット・エンティティ(つまり、両方)を含む複数の子リクエストに分割されます。

バルク・リクエストのエンティティ・データは、リクエストに指定されている異なる受益者間で同じである必要があります。たとえば、プロビジョニング解除のバルク・リクエストの場合、リクエスタは、異なる受益者間で異なるリソース・インスタンスをプロビジョニング解除することを選択できます。そのような状況では、リソース・インスタンスとその受益者間の関連付けは維持されます。

生成される子リクエスト数は、各受益者に関連付けられているターゲット・エンティティの数に依存します。各受益者の関連するターゲット・エンティティの1つを使用して、各子リクエストが生成されます。子リクエストには、1人の受益者と1つのターゲット・エンティティのみが含まれます。

受益者が含まれていないリクエストの場合は、ターゲット・エンティティごとに各子リクエストが生成されます。次に例を示します。

ユーザーの修正バルク・リクエストで、2つのユーザー・インスタンスを変更します。このリクエストの場合、各ユーザー・インスタンスにそれぞれ対応する2つの子リクエストが起動されます。

別の例について考えてみます。プロビジョニング解除のバルク・リクエストに2人の受益者が存在します。2つのリソース・インスタンスを受益者ごとにプロビジョニング解除します。このシナリオでは、最初の受益者に対して2つの子リクエストがあり、2番目の受益者に対して2つの子リクエストがあります。各子リクエストには、各リソース・インスタンスとそれに関連する受益者が存在します。したがって、このバルク・リクエストには、1つの親リクエストと4つの子リクエストの合計が存在します。

テンプレート・レベルの承認は、親リクエストの一部として実行されます。リクエストの作成に使用するリクエスト・テンプレートに関連する承認プロセスがある場合、リクエストは「テンプレート承認を取得しています」ステージに移動します。テンプレートに承認プロセスがない場合、リクエストはテンプレート・レベルで自動承認されて「リクエスト承認を取得しています」ステージに移動します。

リクエスト・レベルの承認は、親リクエストの一部として実行されます。親リクエストは子リクエストを生成した後、子リクエストが操作レベルの承認を完了するまで「操作が開始されました」ステージに移動して待機します。親リクエストと子リクエストの両方でリクエスタが同じ場合は、すべての子リクエストが完了すると、親リクエストは「完了」ステージに移動します。

操作レベルの承認は、子リクエストに対してのみ実行されます。承認者は、子リクエストを個別に承認または却下できます。すべての子リクエストが承認または却下された場合、親リクエストは「完了」ステージに到達します。子リクエストの1つが失敗した場合、親リクエストは「一部が失敗しました」ステージに到達します。すべての子リクエストが失敗した場合、親リクエストは「失敗」ステージに到達します。

図10-3に、リクエスト・サービスにおけるリクエストのライフサイクル・フローの概要を示します。

図10-3 バルク・リクエストと子リクエストのステージ

「図10-3 バルク・リクエストと子リクエストのステージ」の説明

関連項目:

- バルク・リクエストをサポートするリクエスト・モデルの詳細は、「表17-1 デフォルトのリクエスト・テンプレート」を参照してください。

- リクエストのステージの詳細は、「表10-1 リクエストのステージ」を参照してください。

10.3 リクエスト・モデル

リクエスト・モデルは、特定のリクエスト・タイプに対して特定の方法で動作するようにリクエスト管理エンジンに指示する仕様です。各リクエストには、リクエスト・モデルを関連付ける必要があります。リクエスト・モデルとリクエスト・タイプ間には1対1の関係があります。リクエスト・モデルによって、収集する情報、承認の取得方法および実行するアクションが示されます。たとえば、「ユーザーの作成」リクエスト・モデルと「ユーザーの変更」リクエスト・モデルに定義されている情報は異なり、結果としてリクエスト・タイプに対するアクションはそれぞれ異なります。

注意:

Oracle Identity Managerでは、デフォルトでリクエスト・モデルが提供されます。リクエスト・モデルは変更できません。

Oracle Identity Managerには、事前に定義された一連のリクエスト・モデルがあります。表10-2に、Oracle Identity Managerがデフォルトでサポートしている操作およびリクエスト・モデルを示します。

表10-2 デフォルトの操作およびリクエスト・モデル

カタログ

リクエスト・モデル

バルク

自身または管理者

受益者

ユーザー管理

ユーザーの作成

N

管理者

N

ユーザーの自己登録

N

自身

N

セルフ・プロファイルの変更

N

自身

N

ユーザー・プロファイルの変更

Y

管理者

N

ユーザーの有効化

Y

管理者

N

ユーザーの無効化

Y

管理者

N

ユーザーの削除

Y

管理者

N

プロビジョニング

リソースのプロビジョニング

Y

管理者

Y

リソースの自己リクエスト

Y

自身

Y

プロビジョニング済リソースの変更

Y

管理者

Y

プロビジョニング済リソースの有効化

Y

管理者

Y

プロビジョニング済リソースの無効化

Y

管理者

Y

リソースのプロビジョニング解除

Y

管理者

Y

プロビジョニング済リソースの自己変更

N

自身

Y

リソースの自己プロビジョニング解除

Y

自身

Y

ロール管理

ロールの作成

N

管理者

N

ロールの削除

Y

管理者

N

ロールの変更

N

管理者

Y

ロールの割当て

Y

管理者

Y

ロールからの削除

Y

管理者

Y

ロールの自己割当て

Y

自身

Y

ロールの自己削除

Y

自身

Y

注意:

「ロールの作成」、「ロールの削除」および「ロールの変更」リクエスト・モデルの場合は、APIを使用したリクエストの作成のみがサポートされ、UIからの作成はサポートされていません。

表10-2の「バルク」列は、リクエスト・モデルでバルク操作がサポートされているかどうかを示しています。バルク・リクエストは、複数の受益者または複数のターゲット・エンティティ(あるいはその両方)を含むリクエストです。たとえば、ユーザーJohn Doeに複数のロールをプロビジョニングするリクエストでは、バルク・リクエストが生成されます。マネージャ・グループにユーザーJohn DoeおよびJane Doeを追加するプロビジョニング・リクエストでも、バルク・リクエストが生成されます。

リクエスト・モデルは、リクエストの送信後のフロー方法、必須の承認、およびリクエスタが要求するデータを指定するXMLファイルです。次の情報が含まれます。

- モデルの名前

- ターゲット・エンティティが必須かどうか。

- ユーザーにリソースをプロビジョニングするリクエストには受益者がいます。このタイプのリクエストの例には、エンティティを作成して、そのエンティティとユーザーまたは組織間の関係を作成するリクエストがあります。つまり、関係を含める必要があります。

- ユーザーの作成などのリクエストではエンティティの作成が必要ですが、必ずしも他のエンティティとの関係を含める必要があるとはかぎりません。

- 対応する受益者タイプ(ユーザー)。

- モデルに関連付けられたエンティティ・タイプと、そのエンティティが汎用であるかどうか。

- 汎用エンティティ・タイプは親エンティティ・タイプで、特定のサブタイプが選択されないかぎり、エンティティを作成できません。たとえば、リソースが汎用エンティティで、電子メールとラップトップがサブタイプです。

- サブタイプを定義せずに作成可能なエンティティ・タイプは、汎用エンティティ(ユーザーなど)ではありません。

- モデルが作成モデルかどうか。作成モデルではエンティティが作成されます。エンティティ、およびそのエンティティとユーザーまたは組織の関連が作成されます。作成以外のモデルでは、ターゲット・エンティティを選択する必要があります。

- データ収集への参照。モデルには、収集する必要があるデータを決定するために、XML要素への暗黙的な接続が含まれています。汎用エンティティの場合は、実行時に選択したエンティティ・サブタイプを使用して最終的な参照を作成することで、様々なエンティティ・サブタイプの異なるデータを収集できます。

- 承認ワークフローの選択。モデルには、リクエストに関連付ける承認プロセスを選択する際に使用するアルゴリズムへの参照が含まれています。アルゴリズムに渡すパラメータも含まれています。

- モデルがバルク・モードで実行する操作をサポートしているかどうか。

- 認証が必須かどうか。Trueの場合、リクエストを作成するすべての認証済ユーザーがモデルを作成できます。Falseの場合、モデルは未認証セルフサービスを介してのみ使用でき、認証済セルフサービスでは使用できません。

10.4 自分および他のユーザーのためのリクエストの作成

Oracle Identity Managerにログインしたユーザーは、セルフサービスおよび拡張管理からリクエストを作成できます。この項では、Oracle Identity Managerセルフサービスを使用してリクエストを作成する方法について、次の各トピックで説明します。

- Oracle Identity Managerでの自身を登録するリクエストの作成

- Oracle Identity Managerセルフサービスからのリクエストの作成

関連項目:

拡張管理UIを使用して、リクエスト管理者としてリクエストを作成する方法は、「Oracle Identity Manager拡張管理を使用したリクエストの作成」を参照してください。

10.4.1 Oracle Identity Managerでの自身を登録するリクエストの作成

Oracle Identity Managerセルフサービスのログイン・ページを使用して、Oracle Identity Managerに自身を登録するリクエストを作成できます。これは、自己登録リクエストと呼ばれ、Oracle Identity Managerに存在しないユーザー(匿名ユーザー)が要求できます。

自己登録リクエストを作成する手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスのログイン・ページで、「登録」をクリックします。ユーザー登録ウィザードの「ステップ1: 基本情報」ページが表示されます。

2. 名、姓および電子メールIDをそれぞれのフィールドに入力し、「次」をクリックします。「ステップ2: ログイン情報およびセキュリティ情報」ページが表示されます。

3. 「ユーザーIDおよびパスワードの選択」セクションで、ログインID、パスワードおよび確認パスワードをそれぞれのフィールドに入力します。

4. 「チャレンジ質問および回答の設定」セクションで、チャレンジ質問を選択し、質問の回答を入力します。これらの質問と回答は、パスワードを忘れてリセットする必要がある場合に使用します。

5. 「登録」をクリックします。登録リクエストが作成されたことを示す確認ページが表示されます。このページには、リクエスト・ステータスを確認するために使用できる、リクエスト・トラッキング番号が表示されます。

6. 「登録のトラッキング」をクリックして、自己登録リクエストをトラッキングします。

10.4.2 Oracle Identity Managerセルフサービスからのリクエストの作成

Oracle Identity Managerセルフサービスを使用すると、次の各項で説明されているように、「ようこそ」ページ、「マイ・リクエスト」ページおよび「マイ・プロファイル」ページからリクエストを作成できます。

- Oracle Identity Managerセルフサービスの「ようこそ」ページからのリクエストの作成

- 「マイ・リクエスト」ページからのリクエストの作成

- 「マイ・プロファイル」ページからのリクエストの作成

10.4.2.1 Oracle Identity Managerセルフサービスの「ようこそ」ページからのリクエストの作成

Oracle Identity Managerセルフサービス・コンソールの「ようこそ」ページを使用して、ログイン・ユーザーは、自身のリクエストまたは他のユーザーのリクエスト(権限が付与されている場合)を作成できます。

Oracle Identity Managerセルフサービスの「ようこそ」ページからリクエストを作成する手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスの「ようこそ」ページで、「リクエストの作成」をクリックします。リクエスト受益者の選択ページが表示されます。

2. 「自分のためのリクエスト」または「他のユーザーのためのリクエスト」を選択して、「次」をクリックします。「リクエスト・テンプレートの選択」ページが表示されます。

注意:

- 「自分のためのリクエスト」オプションを選択した場合は、ユーザーがアクセス可能な自己リクエスト・タイプに関連するすべてのテンプレートが表示されます。

- 「他のユーザーのためのリクエスト」オプションを選択した場合は、ユーザーがアクセス可能な自己以外のリクエスト・タイプに関連するすべてのテンプレートが表示されます。そのようなテンプレートが存在しない場合は、このオプションを使用してリクエストを作成できません。

3. 「リクエスト・テンプレート」ボックスに、リクエスト・テンプレート名を入力します。または、表からリクエスト・テンプレート選択します。次に、「次」をクリックします。
テンプレートを選択すると、リクエスト作成の各ステップが動的に生成されます。「ユーザーの作成」リクエスト・テンプレートを選択した場合は、後続のステップが表示されます。

4. 使用可能な詳細リストで、姓を入力して「組織」、「Design Consoleのアクセス」および「ユーザー・タイプ」の順に選択し、「次」をクリックします。「理由の入力」ページが表示されます。

5. リクエストの作成日時と理由を入力し、「終了」をクリックします。リクエストIDが作成されて表示されます。

6. リクエストIDをクリックします。リクエストの詳細が表示されます。

10.4.2.2 「マイ・リクエスト」ページからのリクエストの作成

Oracle Identity Managerセルフサービスの上部にある「リクエスト」をクリックすると、「マイ・リクエスト」ページが表示されます。

「マイ・リクエスト」ページの「マイ・リクエストの検索」セクションでは、「リクエストの検索」セクションのフィールドを使用してリクエストを検索できます。自分が要求したリクエストまたは自分に対して要求されたリクエストがリストされた表が、ページに表示されます。

表10-3に、リクエスト情報を表示する表の列を示します。

表10-3 リクエスト情報を表示する表の列

列

説明

リクエスト・タイプ

リクエストのタイプ、またはリクエストを要求して実行する操作。

リクエストID

リクエストを識別するための一意のID。

ステータス

リクエストの現在の状態を示す説明。

リクエスト日

リクエストが要求された日付と時刻。

リクエスタ

リクエストを作成および送信したユーザーまたはシステム・コンポーネント。

リクエストを作成する手順は、次のとおりです。

1. 「アクション」リストから「リクエストの作成」を選択します。「リクエスト受益者」ページが表示されます。

2. 「自分のためのリクエスト」または「他のユーザーのためのリクエスト」を選択して、「次」をクリックします。「リクエスト・テンプレートの選択」ページが表示されます。

注意:

- 「自分のためのリクエスト」オプションを選択した場合は、ユーザーがアクセス可能な自己リクエスト・タイプに関連するすべてのテンプレートが表示されます。

- 「他のユーザーのためのリクエスト」オプションを選択した場合は、ユーザーがアクセス可能な自己以外のリクエスト・タイプに関連するすべてのテンプレートが表示されます。そのようなテンプレートが存在しない場合は、このオプションを使用してリクエストを作成できません。

3. 「リクエスト・テンプレート」ボックスに、リクエスト・テンプレート名を入力します。または、表からリクエスト・テンプレート選択します。次に、「次」をクリックします。
テンプレートを選択すると、リクエスト作成の各ステップが動的に生成されます。「ユーザーの作成」リクエスト・テンプレートを選択した場合は、後続のステップが表示されます。

4. 使用可能な詳細リストで、姓を入力して「組織」、「Design Consoleのアクセス」および「ユーザー・タイプ」の順に選択し、「次」をクリックします。「理由の入力」ページが表示されます。

5. リクエストの作成日時と理由を入力し、「終了」をクリックします。リクエストIDが作成されて表示されます。

6. リクエストIDをクリックします。リクエストの詳細が表示されます。

「マイ・リクエスト」ページでは、リクエストを選択して「取消」リクエストを選択すると、リクエストを取り消すこともできます。リクエストの取消しの詳細は、「リクエストの取消し」を参照してください。

「マイ・リクエスト」ページで、「リクエストID」列のリンクをクリックすると、そのリクエストのリクエスト詳細が表示されます。「リクエストの詳細」ページおよびこのページで実行可能な操作の詳細は、「リクエストの検索」を参照してください。

10.4.2.3 「マイ・プロファイル」ページからのリクエストの作成

Oracle Identity Managerセルフサービスの「マイ・プロファイル」ページからリクエストを作成できます。次のリクエスト・タイプを使用できます。

- ロールのリクエスト: 詳細は、「ロールのリクエスト」を参照してください。

- ロールの削除: 詳細は、「ロールの削除」を参照してください。

- リソースのリクエスト: 詳細は、「リソースのリクエスト」を参照してください。

- リソースの変更: 詳細は、「リソースの変更」を参照してください。

10.5 リクエストの検索

Oracle Identity Managerセルフサービスを使用して、様々なロールは、リクエストの検索およびトラッキングを実行します。

- リクエスタとしてのリクエスト検索

- 受益者としてのリクエスト検索

- 承認者別のリクエストの検索

- 認証されていないユーザー別のリクエストの検索

関連項目:

拡張管理UIでのリクエストの検索については、「リクエストの検索」を参照してください。

10.5.1 リクエスタとしてのリクエスト検索

認証されていないユーザーは、Oracle Identity Managerセルフサービスの「リクエスト」タブで、要求したリクエストを表示できます。「リクエスト」をクリックすると、「マイ・リクエスト」ページに検索機能と要求したリクエストのリストが表示されます。次の項目を検索できます。

- 自分で要求したリクエスト: ログインしたユーザーが作成したリクエストが返されます。

- 自分に対して要求されたリクエスト: ログインしたユーザーが受益者またはターゲット・ユーザーとして存在するリクエストが返されます。

「リクエスト」ページの「リクエストの検索」セクションでは、リクエストID、リクエスト・タイプ、ステータス、開始日および終了日に基づいてリクエストを検索できます。リクエストをリクエストID、リクエスト・タイプ、ステータス、リクエスト日およびリクエスタに基づいてソートすることもできます。

注意:

リクエストIDに基づくソートは、数値ベースではなく文字列ベースです。

検索結果は、表に表示されます。「表示」リストから「自分で要求したリクエスト」を選択すると、自分がリクエスタであるリクエストを表示できます。それ以外の場合は、「自分に対して要求されたリクエスト」を選択して、自分が受益者であるリクエストを表示します。

注意:

「マイ・リクエスト」ページでは、リクエストに対するアクションを受益者として実行することはできません。リクエスタはリクエストを取り消すことができます。リクエストの取消しの詳細は、「リクエストの取消し」を参照してください。

表でリクエストを選択すると、図10-4に示すように、「リクエストの詳細」タブに、リクエストの詳細が表示されます。

図10-4 「リクエストの詳細」タブ

「図10-4 「リクエストの詳細」タブ」の説明

「リクエストの詳細」ページの「リクエスト情報」セクションには、リクエストの詳細が表示されます。「ステータス」フィールドには、現在のリクエスト・ステータスが表示されます。図10-4に示すように、ステータスが「リクエストに失敗しました」または「リクエストがエラーで完了しました」の場合はリンクが表示され、そのリンクをクリックすると、失敗の理由が表示されます。

さらに、次のタブには、リクエストに関連する詳細が表示されます。

- リクエストされたロール/リクエストされたリソース/ユーザー

- リクエストのコメント

- リクエスト履歴

- 承認タスク

- 子リクエスト

10.5.1.1 リクエストされたロール/リクエストされたリソース/ユーザー

「リクエストされたロール」タブは、ロール管理リクエスト・タイプに関連付けられているリクエストに対してのみ表示されます。リクエスト・タイプがプロビジョニングに関連付けられている場合は、「リクエストされたリソース」タブが表示されます。リクエスト・タイプがユーザー管理に関連付けられている場合は、「ユーザー」タブが表示されます。

「リクエストされたロール」タブには、受益者およびロール表示名が表示されます。バルク・リクエストの場合、このタブの表には、図10-5に示すように、すべての受益者と、各受益者に対応するロール名が表示されます。

図10-5 「リクエストされたロール」タブ

「図10-5 「リクエストされたロール」タブ」の説明

「ユーザーの作成」または「リソースのプロビジョニング」リクエスト・タイプのリクエスト詳細を開くと、「ユーザー」タブまたは「リクエストされたリソース」タブには、それぞれ「詳細の表示」リンクが表示されます。図10-6に、「ユーザー」タブの「詳細の表示」リンクを示します。

図10-6 「ユーザー」タブ

「図10-6 「ユーザー」タブ」の説明

「詳細の表示」リンクをクリックすると、図10-7に示すように、ウィンドウにユーザーまたはリソースの詳細が表示されます。

図10-7 「ユーザーの詳細」ウィンドウ

「図10-7 「ユーザーの詳細」ウィンドウ」の説明

10.5.1.2 リクエストのコメント

このタブには、リクエストに関連付けられたコメント(ある場合)が表示されます。リクエスト・ライフサイクルの様々なステージで追加したコメントのすべてを表示したり、新しいコメントを追加することもできます。たとえば、リクエスタがリクエストを取り消す前にコメントを追加したり、管理者がリクエストをクローズする前にコメントを追加したり、承認者またはリクエスタが承認の達成の一部としてコメントを追加できます。

10.5.1.3 リクエスト履歴

このタブには、実行プロセスを通じてリクエストに加えられた様々な変更で構成されたリクエスト履歴が表示されます。リクエスト履歴では、リクエストに対するステータスの変更のみが表示またはトラッキングされます。このタブの表には、図10-8に示すように、リクエストのステータス、リクエストの更新日、およびリクエストの更新ユーザーが表示されます。

図10-8 「リクエスト履歴」タブ

「図10-8 「リクエスト履歴」タブ」の説明

10.5.1.4 承認タスク

このタブには、リクエストに関連付けられているすべての承認タスク(保留中や完了)が表示されます。

10.5.1.5 子リクエスト

このタブは、バルク・リクエストまたは親リクエストに対してのみ表示されます。ここには、バルク・リクエストまたは親リクエストに対して作成された子リクエストが表示されます。

10.5.2 受益者としてのリクエスト検索

受益者としてリクエストを表示する手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスにログインします。

2. 「リクエスト」をクリックします。「マイ・リクエスト」ページが表示されます。

3. 「表示」リストから「自分に対して要求されたリクエスト」を選択します。図10-9に示すように、自分のために要求されたリクエストが表に表示されます。

図10-9 自分のために要求されたリクエスト

「図10-9 自分のために要求されたリクエスト」の説明

4. リクエストを選択して、「リクエストの詳細」タブにそのリクエストの詳細を表示します。

「マイ・リクエスト」ページでは、リクエストに対するアクションを受益者として実行することはできません。

10.5.3 承認者別のリクエストの検索

承認者は、Oracle Identity Managerセルフサービスの「マイ・タスク」セクションで、承認を待機しているリクエストを表示できます。

「承認」タブの「タスクの検索」セクションでは、リクエストID、タスク名、開始日および終了日に基づいてリクエストを検索できます。検索結果は、表に表示されます。「割り当てられたタスクの表示」リストから、次の項目を選択できます。

- 自分のみ: 自分に割り当てられているリクエストのみにソートされます。

- 自分が所有するロール: 自分がメンバーとなっているロールに割り当てられているリクエストにソートされます。

- 自分および自分が所有するロール: 自分に割り当てられているリクエストと自分がメンバーとなっているロールに割り当てられているリクエストにソートされます。

- 自分が管理するユーザー: 自分が管理するユーザーに割り当てられているリクエストにソートされます。

検索結果表からリクエストを選択すると、「タスクの詳細」ページに、リクエストの詳細が表示されます。

「基本の詳細」セクションと「リクエスト情報」セクションには、リクエストの詳細が表示されます。

リクエスト・タイプ/データセットの一部の属性が承認者専用とマークされている場合は、「承認者からの追加データ」という追加セクションが表示されます。承認者はこのセクションでデータを入力でき、このセクションがない場合(フィールドが必須とマークされている場合)、承認者はリクエストを承認できません。承認者の次のレベルで、承認者は必要に応じてデータを変更できます。同様に、承認者が追加情報をリクエストするためにタスクをユーザーに送信すると、受信ユーザーのタスク詳細には、「追加のリクエスト情報」という追加セクションが表示されます。このセクションで、受信ユーザーはリクエストされた情報を入力できます。

さらに、次のタブには、リクエストに関連する詳細が表示されます。

- リクエストされたリソース、ユーザー、リクエストされたロール: 「リソース」タブは、リクエスト・タイプに基づいて動的に生成されます。また、受益者のリスト、ターゲット・リソース名、およびターゲット・リソースに関する詳細を表示するためのリンクが表示されます。
「ユーザー」タブには、リクエストの一部であるユーザーの詳細が表示されます。たとえば、「ユーザーの作成」の場合、「ユーザー」タブにはユーザー名が表示され、「詳細の表示」リンクには、リクエスト作成時に入力したユーザーの属性が表示されます。

「ロール」タブには、リクエストの一部であるロールの詳細が表示されます。たとえば、追加または削除するロール名が表示されます。

- リクエストのコメント: このタブには、リクエストに入力したコメントまたは理由が表示されます。

- リクエスト履歴: 実行プロセスを通じてリクエストにすでに加えられている様々な変更。

「マイ・タスク」タブおよび「リクエストの詳細」タブから、リクエストの承認、要求、却下および再割当てや詳細情報のリクエストなど、リクエスト操作を実行できます。この手順の詳細は、第9章「タスクの管理」を参照してください。

10.5.4 認証されていないユーザー別のリクエストの検索

認証されていないユーザーがトラッキングできるのは、自己登録のリクエストのみです。自己登録リクエストを作成して送信すると、リクエストIDが表示されます。このリクエストIDを使用して、リクエストをトラッキングできます。

関連項目:

自己登録リクエストのトラッキングの詳細は、「未承認ユーザー・セルフサービス」の章の「登録リクエストのトラッキング」を参照してください。

10.6 リクエストの取消し

リクエスタはリクエストを取り消すことができますが、取り消すことができるのは実行フェーズが開始されていないリクエストのみです。また、受益者はリクエストを取り消すことができません。取り消すことができるのは、次のステージにあるリクエストです。

- 承認の取得

- 承認

リクエストを取り消す手順は、次のとおりです。

1. Oracle Identity Managerセルフサービスで、「リクエスト」をクリックします。

2. Oracle Identity Managerセルフサービスの「マイ・リクエスト」ページで、取り消すリクエストを選択します。

3. 「アクション」リストから「リクエストの取消し」を選択します。

4. 確認メッセージ・ボックスで「OK」をクリックします。リクエストが取り消され、リクエストの受益者およびリクエスタに通知が送信されます。取消しが成功した場合、リクエストは「リクエストが取り消されました」ステージに移動します。リクエストに関連付けられている保留中の承認タスクは取り消されます。

注意:

通知の構成は、SOAコンポジットのヒューマン・タスクで実行できます。

10.7 タスク・リストを使用したリクエスト関連タスクの実行

タスク・リストを使用したリクエストの承認、タスクの要求、詳細情報のリクエスト、情報の送信、タスクの却下およびタスクの再割当てなどのリクエスト関連のタスクの詳細は、「認証済ユーザー・セルフサービス」の章の「タスクの詳細の表示」を参照してください。

10.8 リクエストのクローズ

リクエスト管理者(リクエスト管理者ロールが付与されたユーザー)は、実行フェーズを開始していないリクエストを途中でクローズできます。これには、承認を待機しているすべてのリクエスト、または承認を完了しているが操作を開始していないすべてのリクエストが含まれます。次の状態のリクエストをクローズできます。

- 承認の取得

- 承認

注意:

- リクエストのリクエスタまたは受益者は、リクエストをクローズできません。

- 承認の取得ステージに存在するリクエストをクローズした場合は、承認者のタスク・リストにある保留中のすべての承認が削除されます。

リクエストをクローズする手順は、次のとおりです。

1. Oracle Identity Manager拡張管理に移動します。

2. 「リクエスト」セクションの左ペインで、クローズするリクエストを検索します。

3. 検索結果表からリクエストを選択します。

4. 「アクション」リストから「リクエストのクローズ」を選択します。「リクエストのクローズ」ダイアログ・ボックスが表示されます。

5. リクエストをクローズする理由を入力し、「リクエストのクローズ」をクリックします。リクエストのクローズが成功したことを示すメッセージ・ボックスが表示されます。

6. 「OK」をクリックします。リクエストが正常にクローズされると、リクエストは「リクエストがクローズされました」ステージに移動します。リクエストがクローズされたことの通知が、このリクエストのリクエスタとターゲット・ユーザーに送信されます。

注意:

通知の構成は、SOAコンポジットのヒューマン・タスクで実行できます。

第III部

アイデンティティ管理

この部では、アイデンティティ管理機能を使用したOracle Identity Manager委任管理機能について説明します。

次の章で構成されます。

- 第11章「ユーザーの管理」

- 第12章「ロールの管理」

- 第13章「組織の管理」

- 第14章「リクエストの作成と検索」

11 ユーザーの管理

Oracle Identity Managerのユーザー管理機能には、ユーザー・アカウントの作成、更新、削除、有効化と無効化、ロックおよびロック解除が含まれます。この機能については、次の各項で説明します。

- ユーザー・ライフサイクル

- ユーザー・エンティティ定義

- ユーザー管理タスク

- ユーザー管理の認可

- ユーザー名の予約

- 共通名の生成

11.1 ユーザー・ライフサイクル

ユーザー・ライフサイクルとは、特定のイベントや時間的要因に基づいて、システム内でユーザー・エンティティを作成、管理および終了するプロセス・フローを表す語です。

ユーザー・エンティティは、ライフ・サイクル内の様々なステージを通過します。ステージは、「存在しない」、「無効」、「アクティブ」および「削除」です。図11-1に、ライフサイクルの各種ステージ、可能なすべての遷移、およびそれらの遷移を設定する操作を示します。

図11-1 ユーザー・ライフサイクル

「図11-1 ユーザー・ライフサイクル」の説明

ユーザー・ライフサイクルの各遷移に対して、プロセス・ルールやビジネス要件が定義される場合があります。表11-1に示すサンプル・シナリオを使用して、ユーザー・ライフサイクルの遷移とビジネス目的との間の関係を説明します。

表11-1 ユーザー・ライフサイクルとビジネス目的のサンプル・シナリオ

現行の状態

操作

サンプル・シナリオ

プロセスの説明

存在しない

作成

HRは、新規採用者のユーザー・プロファイル情報を入力します。新規採用者をシステムに即時に組み込まない場合、HRはそのユーザーに将来の開始日を設定します。

開始日が将来の日付でない場合、ユーザーは「アクティブ」状態でシステムに組み込まれます。開始日が将来の日付の場合、作成プロセスではそのユーザーを「無効」状態で作成します。

無効

有効化

ユーザーの開始日が有効になります。システムでは、新規採用者に対するプロビジョニングが開始されます。

ユーザーはシステム内で有効とマークされ、システムにログインしてシステムを使用できるようになります。デフォルトでは、必要なすべてのメンバーシップおよびアカウントがワークフロー内で確立されます。

アクティブ

変更

ユーザーが新しい職階に昇格します。この結果、HRはそのユーザーの役職を変更します。

新しいリソースがユーザーにプロビジョニングされ、古い不適切なリソースはユーザーからプロビジョニング解除されます。

アクティブ

無効化

ユーザーが会社から1年間の長期有給休暇を取ります。HRは、ユーザーの最後の勤務日にそのユーザーを手動で無効にします。一定期間の後に、ユーザーは会社に復職します。HRは、ユーザーを再度「アクティブ」にできます。

ユーザーはシステムで無効とマークされ、システムにログインできなくなります。無効化されたユーザーは、再度「アクティブ」にできます。

アクティブ

削除

ユーザーが会社を退職します。HRは、ユーザーの最後の勤務日にそのユーザーを手動で削除します。

ユーザーはシステムで無効とマークされ、システムにログインできなくなります。デフォルトでは、ユーザーのすべてのアカウントがワークフロー内でプロビジョニング解除されます。

ユーザー・ライフサイクル管理には、次の概念が不可欠です。

- OIMアカウント

- 組織

- ロール

11.1.1 OIMアカウント

OIMアカウントは、Oracle Identity Managerへのアクセスを認証する方法として使用する抽象的なアカウントです。Oracle Identity Managerでは、ユーザーとOIMアカウント間の関係を示すカーディナリティは1対1です。デフォルトでは、ユーザーは、ユーザーにOracle Identity Managerへのアクセスを許可するOIMアカウントに関連付けられます。ただし、ユーザーがOracle Identity Managerにアクセスする必要がない場合は、OIMアカウントをプロビジョニングしないことも可能です。

ロックやロック解除などのユーザー操作は、明示的なアカウント操作です。ユーザーに対してロックまたはロック解除を行う場合は、そのユーザーのOIMアカウントをロックまたはロック解除します。

Oracle Identity Manager内の各ユーザーには、ユーザーのOIMアカウントを制御する「Design Consoleのアクセス」属性があります。UIでユーザーの「Design Consoleのアクセス」オプションが選択されている場合、そのユーザーはエンドユーザー管理者です。このオプションが選択されていない場合、そのユーザーはエンドユーザーです。

11.1.2 組織

組織とは、認可および権限データの論理的なコンテナです。Oracle Identity Managerのユーザーは、1つの組織のみに所属する必要があります。Oracle Identity Managerにおける組織の詳細は、第13章「組織の管理」を参照してください。

11.1.3 ロール

Oracle Identity Managerでは、ロールを使用して権限管理を容易に制御できます。ロールとは、ユーザーや他のロールに付与する、関連する権限の名前付きグループです。ロールは、エンド・ユーザー・システムとスキーマ・オブジェクト権限の管理を容易にするために設計されています。ロールの詳細は、第12章「ロールの管理」を参照してください。

11.2 ユーザー・エンティティ定義

Oracle Identity Managerでは、ユーザー・エンティティに対して属性が定義されます。これらの属性は、すべてのエンティティで同一です。ユーザー・エンティティには独自の属性を追加できます。

Oracle Identity Managerでは、エンティティの各属性に対して、次のプロパティが定義されます。

- 属性名: 属性の名前。

- カテゴリ: すべてのエンティティ属性は1つのカテゴリに分類されます。この分類は、UIでデータを編成するために使用されます。カテゴリはUIでの表示用にのみ使用され、他の用途には使用されません。デフォルトのカテゴリは次のとおりです。

- 基本ユーザー情報: このカテゴリには、ユーザーの姓と名、電子メール、マネージャ、組織、ユーザー・タイプなど、基本ユーザー属性が含まれます。

- アカウント設定: このカテゴリには、ユーザー・ログイン、アイデンティティ・ステータス、アカウント・ステータス、グローバル一意識別子(GUID)など、アカウント関連の属性が含まれます。

- アカウントの有効日: このカテゴリには、アカウントの開始日および終了日属性が含まれます。

- プロビジョニング日: このカテゴリには、プロビジョニング日およびプロビジョニング解除日属性が含まれます。

- ライフサイクル: このカテゴリでは、手動ロック、ロック日時、自動削除日など、ユーザー・アカウントに関連するフラグが表示されます。
カテゴリ内のすべての属性はデフォルトで非表示なので、カテゴリも表示されません。

- システム: このカテゴリには、作成日、パスワード有効期限日、パスワードのリセット試行回数など、ユーザー・エンティティのシステム制御属性が含まれます。

- その他のユーザー属性: このカテゴリには、すべてのFAおよびLDAP関連属性のリストが含まれます。

- カスタム属性: これは空のカテゴリで、ユーザーはすべての新規カスタム属性を追加できます。

- プリファレンス: このカテゴリには、ユーザー・プリファレンスに関連する属性が含まれます。ロケール、タイムゾーン、通貨、日付書式など、様々な属性が含まれます。

- タイプ: 属性内のデータのタイプを示します。サポートされているタイプは、文字列、数値、日付およびブールです。

- プロパティ: 属性ごとに、次のプロパティを定義できます。

- 必須: リポジトリ内のすべてのユーザーがこの属性に対してnullでない値を持つ必要があるかどうかを決定します。

- システム制御: 値はシステム自体による設定および編集のみ可能かどうかを決定します。

- システムによるデフォルト設定が可能: 値が入力されない場合に、システムによる値のデフォルト設定が可能かどうかを決定します。

- 暗号化: リポジトリに格納される値を暗号化するかどうかを決定します。「True」の場合、値は暗号化されますが、暗号化された値は復号化して元の値に戻すことができます。「False」の場合、値はクリアとして格納され、格納した値は暗号化されません。

- ユーザー検索可能: 検索で値が使用可能かどうかを決定します。

- バルク更新可能: 複数ユーザーのバルク変更の中で、フィールドが変更可能かどうかを決定します。ユーザー名、名前フィールド、パスワードなどユーザーに一意とみなされるフィールドでは、バルク更新がサポートされていません。「システム制御」が「はい」、または「一意」が「はい」に設定されたフィールドの場合、このプロパティは「はい」に設定できません。属性のプロパティの設定については、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザー属性の構成に関する項を参照してください。

- 表示タイプ: ユーザーを作成および変更するUIにフィールドを表示する方法を決定します。次のいずれかの値になります。
TEXT、TEXTAREA、NUMBER、DOUBLE、CHECKBOX、DATE_ONLY、SECRET、LOV、ENTITY。

- 複数値: 属性が複数値かどうかを決定します。このプロパティの値は「True」または「False」のいずれかになります。Oracle Identity Managerでは複数値をサポートしていないため、すべてのユーザー属性でこのプロパティは「False」に設定されます。

- 最大サイズ: 指定した属性で可能な最大長を指定します。

- 読取り専用: 属性が読取り専用権限のみを持つか、編集可能かを指定します。

- カスタム: 属性がデフォルト属性か、ユーザー定義属性かを決定します。

- 表示可能: ユーザーに属性を表示するかどうかを決定します。

表11-2に、Oracle Identity Managerでユーザー・エンティティに対して定義されている属性を示します。

表11-2 ユーザー・エンティティに対して定義されている属性

属性名

カテゴリ

説明

データ型

プロパティ

LOV(デフォルト値は太字)

usr_key

アカウント設定

ユーザーのGUID。ユーザーの作成時に自動生成されます。

数値

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: ENTITY

なし

act_key

基本ユーザー情報

ユーザーが所属する組織のGUID。これは必須フィールドです。

数値

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 19

表示可能: はい

表示タイプ: ENTITY

なし

姓

基本ユーザー情報

ユーザーの姓。これは必須フィールドです。

文字列

必須: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

名

基本ユーザー情報

ユーザーの名前

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

ミドル・ネーム

基本ユーザー情報

ユーザーのミドル・ネーム。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

完全名

基本ユーザー情報

ユーザーの完全名。完全名は、アカウントの作成時にローカライズされて格納されます。

文字列

必須: いいえ

MLS: いいえ

多表現: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 164

表示可能: いいえ

表示タイプ: TEXT

なし

表示名

基本ユーザー情報

ユーザーの表示名。指定しない場合は、ユーザーの作成時に自動生成されます。

文字列

必須: いいえ

MLS: いいえ

多表現: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 382

表示可能: はい

表示タイプ: TEXT

なし

Xellerateタイプ

基本ユーザー情報

ユーザーのタイプ(エンドユーザーまたは管理者)。

文字列

必須: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 30

表示可能: はい

表示タイプ: CHECKBOX

Lookup.Users.XellerateType

エンドユーザー

エンドユーザー管理者

usr_password

アカウント設定

ユーザーのパスワードを指定します。暗号化された値として格納されます。

文字列

必須: はい

システム制御: いいえ

暗号化: 暗号化

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 128

表示可能: はい

表示タイプ: SECRET

なし

usr_disabled

アカウント設定

ユーザーが有効か無効かを示します。

0の場合、ユーザーは有効です。1の場合、ユーザーは無効です。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: はい

読取り専用: はい

最大サイズ: 1

表示可能: はい

表示タイプ: CHECKBOX

なし

ステータス

アカウント設定

ユーザーのステータス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: はい

最大サイズ: 25

表示可能: はい

表示タイプ: LOV

Lookup.WebClient.Users.Status

アクティブ

無効

削除

開始日まで無効

ロール

基本ユーザー情報

ユーザーがメンバーであるロール。

文字列

必須: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 255

表示可能: はい

表示タイプ: LOV

Lookup.Users.Role

フルタイム

パートタイム

派遣社員

インターン

コンサルタント

従業員

派遣就業者

非就労者

その他

契約者

ユーザー・ログイン

アカウント設定

ユーザーのログインID。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

usr_manager_key

基本ユーザー情報

ユーザーのマネージャのGUID。

数値

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 19

表示可能: はい

表示タイプ: ENTITY

なし

開始日

アカウントの有効日

ユーザーの開始日。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: -

表示可能: はい

表示タイプ: DATE_ONLY

なし

終了日

アカウントの有効日

ユーザーの終了日。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: -

表示可能: はい

表示タイプ: DATE_ONLY

なし

usr_provisioning_date

プロビジョニング日

Oracle Identity Managerでユーザー・プロファイルが作成された日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: -

表示可能: はい

表示タイプ: DATE_ONLY

なし

usr_deprovisioning_date

プロビジョニング日

リソースがユーザーからプロビジョニング解除される日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: -

表示可能: はい

表示タイプ: DATE_ONLY

なし

usr_provisioned_date

システム

リソースがユーザーにプロビジョニングされた日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_deprovisioned_date

システム

リソースがユーザーからプロビジョニング解除された日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

電子メール

基本ユーザー情報

ユーザーの電子メール・アドレス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

usr_locked

アカウント設定

ユーザー・アカウントがロックされているか、ロック解除されているかを示します。

値が0の場合、アカウントはロック解除されています。

値が1の場合、アカウントはロックされています。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: はい

表示タイプ: LOV

Users.Lock User

0

1

ロック日時

ライフサイクル

ユーザー・アカウントがロックされた日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

自動削除日

ライフサイクル

ユーザー・アカウントが自動的に削除される日付。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

検索可能: はい

バルク更新可能: はい

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

手動ロック

ライフサイクル

ユーザー・アカウントが自動的にロックされるか、手動でロックされるかを示します。

1の場合、アカウントは管理者が手動でロックします。

0の場合、アカウントは自動的にロックされます(たとえば、誤ったパスワードによるログイン試行の最大回数を超えた場合)。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: TEXT

なし

usr_login_attempts_ctr

システム

ユーザーが誤ったパスワードを使用してログインを試行した回数。これは、正常にログインされるたびに0に設定されます。

数値

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: NUMBER

なし

usr_create

システム

ユーザーが作成された日付。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_update

システム

ユーザーが最後に更新された日付。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_timezone

プリファレンス

ユーザーのタイムゾーン・プリファレンス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 100

表示可能: はい

表示タイプ: TIME_ZONE

なし

usr_locale

プリファレンス

ユーザーのロケール・プリファレンス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 100

表示可能: はい

表示タイプ: LOV

Notification.Languages

英語

フランス語

ドイツ語

イタリア語 スペイン語

ポルトガル語(ブラジル)

日本語

韓国語

簡体字中国語

繁体字中国語

アラビア語

チェコ語

デンマーク語

オランダ語

フィンランド語

ギリシャ語

ヘブライ語

ハンガリー語

ノルウェー語

ポーランド語

ポルトガル語

ルーマニア語

ロシア語

スロバキア語

スウェーデン語

タイ語

トルコ語

usr_pwd_cant_change

システム

現在、このフィールドは使用されていません。

文字列

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: CHECKBOX

なし

usr_pwd_must_change

システム

現在、このフィールドは使用されていません。

値が0の場合、パスワードを変更する必要はありません。

値が1の場合、ユーザーはパスワードを変更する必要があります。

文字列

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: CHECKBOX

なし

usr_pwd_never_expires

システム

現在、このフィールドは使用されていません。

値が0の場合、パスワードに有効期限があります。

値が1の場合、パスワードに有効期限はありません。

文字列

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: はい

表示タイプ: CHECKBOX

なし

usr_pwd_expire_date

システム

パスワードの有効期限の日付。「パスワードの有効期限なし」が0の場合のみ有効です。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_pwd_warn_date

システム

ユーザーがパスワードを変更するように警告される日付。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_pwd_expired

システム

パスワードが有効期限切れであるかどうかを示します。その場合、パスワードはリセットされます。

値が0の場合、パスワードは有効期限切れではありません。

値が1の場合、パスワードは有効期限切れです。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: CHECKBOX

なし

usr_pwd_warned

システム

ユーザーがパスワードを変更するように警告されたかどうかを示します。

0の場合、ユーザーはパスワードを変更するようにまだ警告されていません。

1の場合、ユーザーはパスワードを変更するように警告されました。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: CHECKBOX

なし

usr_pwd_reset_attempts_ctr

システム

ユーザーがチャレンジ質問に誤った回答をしてパスワードのリセットを試行した回数。これは、パスワードが正常にリセットされるたびに0に設定されます。

数値

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: NUMBER

なし

usr_change_pwd_at_next_logon

システム

ユーザーが次のログイン時にパスワードを変更する必要があるかどうかを示します。

値が1の場合、ユーザーは次のログイン時にパスワードをリセットする必要があります。値が0の場合、ユーザーは次のログイン時にパスワードをリセットする必要はありません。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: CHECKBOX

なし

usr_data_level

システム

このレコードに対してサポートされている操作の種類(追加、変更、削除など)を示します。

この列の有効な値は次のとおりです。

0: この行は更新または削除できることを示します。

1: この行は更新および削除できないことを示します。

2: この行は変更のみできますが、削除はできないことを示します。

3: この行は削除のみできますが、変更はできないことを示します。

文字列

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: TEXT

なし

usr_pwd_min_age_date

システム

日付を設定した場合、その日付までユーザー・パスワードは変更できないことを示します。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: -

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_createby

システム

このユーザーを作成したユーザーのGUID。

数値

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: ENTITY

なし

usr_updateby

システム

このユーザーを更新したユーザーのGUID。

数値

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: ENTITY

なし

usr_created

システム

現在、これはOracle Identity Managerで使用されていません。

日付

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 19

表示可能: いいえ

表示タイプ: DATE_ONLY

なし

usr_policy_update

システム

ユーザーのポリシーを再評価するために使用します。現在のポリシーを適用するすべてのユーザーについてオブジェクト・ポリシーを再評価するには、UPP表およびUPD表を評価して、現在のポリシーのユーザー・リストを取得します。検出されたユーザーごとに、policy_updateフラグを設定します。post-insert、post-updateおよびpost_deleteイベント・ハンドラをtcPOPに付加します。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: はい

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: TEXT

なし

国

その他のユーザー属性

ユーザーの国。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 100

表示可能: はい

表示タイプ: TEXT

なし

部門番号

その他のユーザー属性

ユーザーの部門番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

説明

その他のユーザー属性

ユーザーの説明。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 2000

表示可能: はい

表示タイプ: TEXT

なし

共通名

その他のユーザー属性

ユーザーの共通名。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 240

表示可能: はい

表示タイプ: TEXT

なし

従業員番号

その他のユーザー属性

ユーザーの従業員番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

FAX

その他のユーザー属性

ユーザーのFAX番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

生成修飾子

その他のユーザー属性

ユーザーの生成修飾子。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

入社日

その他のユーザー属性

ユーザーの入社日。

日付

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: -

表示可能: はい

表示タイプ: DATE_ONLY

なし

自宅電話番号

その他のユーザー属性

ユーザーの自宅電話番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

地方名

その他のユーザー属性

ユーザーの地方名。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

モバイル

その他のユーザー属性

ユーザーのモバイル番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

ページャ

その他のユーザー属性

ユーザーのページャ番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

自宅住所

その他のユーザー属性

ユーザーの自宅住所。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

住所

その他のユーザー属性

ユーザーの住所。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

郵便番号

その他のユーザー属性

ユーザーの郵便番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 230

表示可能: はい

表示タイプ: TEXT

なし

私書箱

その他のユーザー属性

ユーザーの私書箱。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

都道府県

その他のユーザー属性

ユーザーの都道府県。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

番地

その他のユーザー属性

ユーザーの住所の番地。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

電話番号

その他のユーザー属性

ユーザーの電話番号。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: はい

表示タイプ: TEXT

なし

役職

その他のユーザー属性

ユーザーの役職。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

イニシャル

その他のユーザー属性

ユーザーのイニシャル。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 10

表示可能: はい

表示タイプ: TEXT

なし

生成されたパスワード

システム

このフラグは、ユーザーに対してパスワードが自動生成されたかどうかを示します。

文字列

必須: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: はい

最大サイズ: 1

表示可能: いいえ

表示タイプ: TEXT

なし

LDAP組織

その他のユーザー属性

LDAPのユーザー組織名。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

LDAP組織単位

その他のユーザー属性

LDAPのユーザー組織単位(部門、大規模エンティティのサブエンティティなど)。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 80

表示可能: はい

表示タイプ: TEXT

なし

LDAP GUID

その他のユーザー属性

LDAPのユーザーのグローバル一意識別子。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

LDAP DN

その他のユーザー属性

LDAPのユーザーの識別名。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 256

表示可能: はい

表示タイプ: TEXT

なし

FA言語

プリファレンス

LDAP環境でのユーザーの言語。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 100

表示可能: いいえ

表示タイプ: TEXT

該当なし

埋込みヘルプ

その他のユーザー属性

ロールオーバー時にヘルプ・ポップアップを非表示にするかどうかを示します。この属性はOracle Identity Managerで解釈されないため、LDAPで値を保持するために使用されます。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 10

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.EmbeddedHelp

True

False

数値書式

その他のユーザー属性

ユーザーの数値書式プリファレンス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 30

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.NumberFormat

#,##0.##[.,]

#,##0.###[\u00A0,]

#,##0.###

#,##0.###;#,##0.###-

#,##0.###[.,]

#,##0.###;(#,##0.###)[.,]

#,##0.##[\u00A0,]

#,##0.###['.]

#,##0.###[',]

日付書式

その他のユーザー属性

ユーザーの日付書式プリファレンス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.DateFormat

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-yyyy

dd-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

時間書式

その他のユーザー属性

ユーザーの時間書式プリファレンス。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.TimeFormat

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

通貨

その他のユーザー属性

ユーザーの優先通貨。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.Currency

フォント・サイズ

その他のユーザー属性

ユーザーの優先フォント・サイズ(大、中など)。これは、アクセシビリティ機能に関連しています。この属性はOracle Identity Managerで解釈されないため、LDAPで値を保持するために使用されます。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 10

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.FontSize

大

中

カラー・コントラスト

その他のユーザー属性

ユーザーの優先カラー・コントラスト(標準、高など)。これは、アクセシビリティ機能に関連しています。この属性はOracle Identity Managerで解釈されないため、LDAPで値を保持するために使用されます。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 10

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.ColorContrast

標準

高

アクセシビリティ・モード

その他のユーザー属性

ユーザーの優先アクセシビリティ機能(最適化されたスクリーン・リーダー、標準アクセシビリティなど)。この属性はOracle Identity Managerで解釈されないため、LDAPで値を保持するために使用されます。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 20

表示可能: いいえ

表示タイプ: LOV

Lookup.Users.AccessibilityMode

スクリーン・リーダー

アクセス不可

デフォルト

FA地域

プリファレンス

LDAP環境でのユーザーの地域。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

読取り専用: いいえ

最大サイズ: 100

表示可能: いいえ

表示タイプ: LOV

該当なし

ユーザー名優先言語

プリファレンス

ユーザーの表示名のみをその言語で表示するために使用する、ユーザーのプリファレンス言語。

注意: このプリファレンスはOracle Identity Managerに格納できますが、Oracle Identity ManagerのUIには適用されません。

文字列

必須: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

読取り専用: いいえ

最大サイズ: 20

表示可能: いいえ

表示タイプ: LOV

mls_locale_code順(昇順)に並べたlocale_flagが0または1のmls_localeから、MLS_LOCALE_CODEをUSR_NAME_PREFERRED_LANGとして選択します。

11.3 ユーザー管理タスク

Oracle Identity Administrationでは、次のユーザー管理タスクを実行できます。

- ユーザーの検索

- ユーザーの作成

- ユーザー情報の表示と変更

11.3.1 ユーザーの検索

Oracle Identity Manager管理では、ユーザー・エンティティに対して次のタイプの検索操作を実行できます。

- 単純検索

- 拡張検索

11.3.1.1 単純検索

検索操作によって、検索属性として指定した検索文字列に基づいてユーザー・エンティティを検索できます。この操作は、単純検索またはクイック検索とも呼ばれます。

検索機能については、次の各トピックで説明します。

- 検索可能な属性

- 検索コンパレータ

- 検索文字列

- 論理積演算子

- 検索結果

- 検索結果に対する操作

- 単純検索の実行

11.3.1.1.1 検索可能な属性

検索対象になる属性のデフォルト・セットは次のとおりです。

- ユーザー・ログイン

- 名

- 姓

- 表示名

11.3.1.1.2 検索コンパレータ

検索操作の検索コンパレータは、「次で始まる」に設定されます。検索コンパレータとワイルドカード文字を組み合せて、検索条件を指定できます。アスタリスク(*)文字をワイルドカード文字として使用します。

11.3.1.1.3 検索文字列

検索文字列は大/小文字が区別されません。検索文字列のワイルドカード文字としてサポートされているのはアスタリスク(*)文字のみです。Oracle Identity Manager管理では、検索文字列の先頭または末尾にある空白は削除されます。パフォーマンス上の理由から、検索文字列の先頭にあるアスタリスク(*)は削除されます。

11.3.1.1.4 論理積演算子

検索操作の論理積演算子は、デフォルトで「OR」に設定されます。

次の問合せ構成式を使用して、検索属性、検索コンパレータ、検索文字列および論理積演算子の関係を説明します。

Query begins with ((attribute 1 begins with 'search string') or (attribute 2 begins with 'search string') or …)

たとえば、検索テキストとして「Jo*」と入力した場合、検索操作では、「ユーザー・ログイン」が「Jo*」で始まるか、「名」が「Jo*」で始まるか、「姓」が「Jo*」で始まるか、または「表示名」が「Jo*」で始まる、という内部問合せが形成されます。その結果、ユーザー名、名または姓が「Jo」で始まるすべてのユーザーが表示されます。

11.3.1.1.5 検索結果

結果属性は、検索操作によって返される属性セットを定義します。ただし、実際の結果属性セットは、ユーザーの権限に基づいて動的に決まります。

注意:

検索結果に、削除されたユーザー(ステータスが「削除」のユーザー)は含まれません。

制限された検索結果表には、完全な検索結果表の列のサブセットが表示されます。検索結果に表示する列、および制限された検索結果表に表示するサブセットは、ユーザー構成によって指定されます。構成管理の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザー属性の構成に関する項を参照してください。

単純検索結果表には、「表示名」属性のみが表示されます。つまり、検索結果には、「表示名」、「ユーザー・ログイン」、「名」または「姓」属性の値が検索テキストと一致するすべてのユーザーの表示名が表示されます。

検索結果表に表示されたデータのソートおよびページングを実行できます。

ヒント:

上下にスクロールすると、ページ索引が変わります。各ページには、固定のエントリ・セットが含まれます。ページ索引が変わり、次に必要なページがUIに表示されない場合、UIではイベントがトリガーされます。このイベントに応答して、結果ページが表示されます。

検索結果表の各属性には、上下矢印が表示されます。属性の上下矢印をクリックすると、ソート属性およびソート順を指定できます。

11.3.1.1.6 検索結果に対する操作

この項では、検索結果表で選択した行に対して実行できる操作について説明します。これは、単一選択操作とバルク(複数)選択操作に区分できます。

検索結果表から1名のユーザーを選択して、次の単一選択操作を実行できます。

- 詳細の表示

- 変更(ユーザー・ステータスが「アクティブ」の場合のみ)

- 有効化(ユーザー・ステータスが「無効」の場合のみ)

- 無効化(ユーザー・ステータスが「有効」の場合のみ)

- ロック(選択したユーザーのアカウントがロック解除されている場合のみ)

- ロック解除(選択したユーザーのアカウントがロックされている場合のみ)

- パスワードのリセット

- 削除

検索結果表から複数のユーザーを選択して、次のバルク(複数)選択操作を実行できます。

- 有効化(ユーザー・ステータスが「無効」の場合のみ)

- 無効化(ユーザー・ステータスが「有効」の場合のみ)

- ロック(選択したユーザーのアカウントがロック解除されている場合のみ)

- ロック解除(選択したユーザーのアカウントがロックされている場合のみ)

- 削除

11.3.1.1.7 単純検索の実行

単純検索を実行してユーザーの詳細を表示する手順は、次のとおりです。

1. Oracle Identity Manager管理にログインします。

2. ユーザーを検索するには、左ペインにあるドロップダウン・リストから「ユーザー」を選択します。

3. 検索フィールドに検索基準を入力します。検索基準にはワイルドカード文字(*)を使用できます。

4. 検索フィールドの右側にあるアイコンをクリックします。左ペインに検索結果が表示され、指定した検索基準に一致するユーザーの表示名が表示されます。図11-2に、検索結果を示します。

図11-2 単純検索結果

「図11-2 単純検索結果」の説明

11.3.1.2 拡張検索

拡張検索オプションは、Oracle Identity Manager管理の右ペインに表示されます。拡張検索では、単純検索の基準より複雑な検索基準を指定できます。結果は検索結果表に表示されます。

拡張検索操作については、次の各項で説明します。

- 「拡張検索」ページ

- 検索コンパレータ

- 論理積演算子

- 検索可能な属性

- 検索結果

- 拡張検索操作の実行

11.3.1.2.1 「拡張検索」ページ

「拡張検索」ページで検索基準を指定します。このページでは、複数の基準で構成される検索問合せを作成できます。各基準は次の内容で構成されます。

- 検索対象の属性

- 検索コンパレータ(「次と等しい」、「次で始まる」など)

- 検索する値

複数の値が必要なコンパレータの場合は、複数の値を指定できます。数値フィールドの範囲検索、日付フィールドの日付範囲検索など、コンパレータで複数の値が必要な場合は、複数の検索基準を指定できます。複数の検索基準を指定する場合は、検索操作に対して「AND」または「OR」論理積演算子を指定する必要があります。

11.3.1.2.2 検索コンパレータ

「拡張検索」ページでサポートされる検索コンパレータは、Oracle Identity Managerに事前定義されています。各コンパレータでは、サポートする属性の種類(データ型)、および必要な入力データ・フィールドの数を指定します。

表11-3に、拡張検索でサポートされているコンパレータを示します。

表11-3 拡張検索のコンパレータ

コンパレータ

サポートされているフィールド・タイプ

次と等しい

テキスト、日付、数値、ブール

次で始まる

テキスト

11.3.1.2.3 論理積演算子

検索操作の論理積演算子は次のとおりです。

- すべて: 検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。

- いずれか: 検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。

11.3.1.2.4 検索可能な属性

検索可能な属性によって、「拡張検索」ページで使用できる属性のセットを定義します。検索基準を作成するときは、このベース・リストから検索対象の属性を選択できます。

デフォルトで「拡張検索」ページに表示されるのは、表11-4の「デフォルト・フィールド」に示す検索可能な属性のサブセットのみです。検索可能な属性をページに追加するには、「フィールドの追加」機能を使用します。属性ごとに、サポートするコンパレータも指定します。

表11-4 デフォルトの検索属性

属性

使用可能なコンパレータ

デフォルト・フィールド

表示名

次で始まる、次と等しい

はい

ユーザー・ログイン

次で始まる、次と等しい

はい

名

次で始まる、次と等しい

はい

姓

次で始まる、次と等しい

はい

アイデンティティ・ステータス

次と等しい、次と等しくない

はい

組織

次と等しい、次で始まる

はい

電子メール

次で始まる、次と等しい

はい

開始日

次と等しい、次より前、次より後、範囲

はい

終了日

次と等しい、次より前、次より後、範囲

はい

注意:

ユーザー管理構成には、検索可能な属性を構成できます。

拡張検索用に構成した検索可能な属性は、「検索可能」プロパティが「はい」にマークされているユーザー・エンティティに対して定義した属性のサブセットである必要があります。

11.3.1.2.5 検索結果

検索結果表は「拡張検索」ページと同じタブに表示されるため、ユーザーは検索で使用した問合せとともにその検索結果を表示できます。右ペインの表は常に、完全な検索結果表として表示されます。

検索で返された情報が多すぎる場合は、検索結果表の1つ以上の列を非表示にできます。たとえば、表に20列ある場合は、最も重要な8列のみを表示すると、あまり重要でない情報をスクロールする必要がなくなります。

1つ以上の列を非表示にするには、「検索結果」ペインを開き、「表示」をクリックして、非表示にする列の選択を解除します。特定の表ビューでは、現在非表示になっている列の数を示すステータス・メッセージが、すべての検索表の下部に表示されます。図11-3は、ユーザーが3つの列を非表示にしていることを示します。

図11-3 非表示の列がある拡張検索結果

削除されたユーザーは検索結果で返されませんが、ユーザーが「拡張検索」ページで「ステータス」属性を明示的に選択し、「ステータス」に「削除」値を指定した場合を除きます。その場合は、削除されたユーザーも検索結果の一部として返されます。

11.3.1.2.6 拡張検索操作の実行

拡張検索操作を実行して検索結果を表示する手順は、次のとおりです。

1. Oracle Identity Manager管理の「ようこそ」ページで、「ユーザー」の下にある「拡張検索 - ユーザー」をクリックします。または、「管理」をクリックし、「参照」タブの下で「拡張検索: ユーザー」をクリックします。

2. 「すべて」または「いずれか」論理積演算子を選択します。これらの演算子については、「論理積演算子」を参照してください。

3. フィールドに検索基準を指定します。検索基準にはワイルドカード文字(*)を使用できます。パフォーマンス上の理由から、先頭(接頭辞)のワイルドカードは削除されます。フィールドの横にあるリストから検索コンパレータを選択します。拡張検索のコンパレータについては、「表11-3 拡張検索のコンパレータ」を参照してください。

注意:

「アイデンティティ・ステータス」フィールドでアスタリスク・ワイルドカード文字(*)を使用した場合は、「アクティブ」、「無効」および「開始日まで無効」ステータスのユーザーのみが返され、「削除」ステータスのユーザーは返されません。「削除」ステータスのユーザーを検索するには、「アイデンティティ・ステータス」フィールドに「削除」と入力する必要があります。

検索基準にフィールドを追加するには、「フィールドの追加」をクリックし、リストからフィールド名を選択します。

4. 「検索」をクリックします。図11-4に示すように、検索基準に一致するユーザー・レコードが検索結果表に表示されます。

図11-4 拡張検索結果

「図11-4 拡張検索結果」の説明

11.3.2 ユーザーの作成

「ユーザーの作成」ページを使用して、Oracle Identity Managerに新規ユーザーを作成できます。このページは、Oracle Identity Managerの組織において、ユーザーの作成権限に関する認可ポリシーでユーザーを作成する権限が付与されている場合のみ開くことができます。

ユーザーを作成する手順は、次のとおりです。

1. Oracle Identity Manager管理にログインします。

2. 「ユーザーの作成」ページを開きます。これを行うには、次のいずれかを実行します。

- 「ようこそ」ページで、「ユーザー」の下にある「ユーザーの作成」をクリックします。

- ツールバーにある「管理」タブをクリックし、「ようこそ」ページで、「ユーザー」の下にある「ユーザーの作成」をクリックします。

- 「検索結果」タブをクリックし、「アクション」メニューから「ユーザーの作成」を選択します。

- 「検索結果」タブで、ツールバーにある「ユーザーの作成」アイコンをクリックします。

「ユーザーの作成」ページには、ユーザー・プロファイル属性の入力フィールドが表示されます。「ユーザーの作成」ページに表示される属性は、ユーザー管理構成での「ユーザーの作成」ページの構成によって決まります。この構成で、ユーザー・エンティティに対して定義された各属性は「ユーザーの作成」ページで使用可能とマークされます。

関連項目:

「ユーザーの作成」ページの構成については、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザー属性の構成に関する項を参照してください。

3. 「ユーザーの作成」ページに、ユーザーの詳細を入力します。表11-5に、「ユーザーの作成」ページのフィールドを示します。

表11-5 「ユーザーの作成」ページのフィールド

セクション

フィールド

説明

基本ユーザー情報

名

ユーザーの名。

ミドル・ネーム

ユーザーのミドル・ネーム。

姓

ユーザーの姓。

Design Consoleのアクセス

ユーザーのOIMユーザー・タイプ。有効な値は「エンドユーザー」と「エンドユーザー管理者」で、この2つの値のいずれかになります。OIMユーザー・タイプによって、ユーザーがOracle Identity Manager Design Consoleにログインできるかどうかが決まります。「Design Consoleのアクセス」チェック・ボックスが選択され、ユーザー・タイプが「エンドユーザー管理者」の場合、そのユーザーはDesign Consoleにアクセスできます。

電子メール

ユーザーの電子メール・アドレス。

マネージャ

ユーザーのレポート・マネージャ。

組織

ユーザーが所属する組織。

ユーザー・タイプ

従業員のタイプ(フルタイムの従業員、インターン、契約者、パートタイムの従業員、コンサルタント、派遣社員など)。

表示名

ローカライズされた値で、追加するには「ローカライゼーションの管理」をクリックし、言語リストから値を選択します。表示名は33の言語で表示可能です。

アカウント設定

ユーザー・ログイン

管理コンソールにログインするために指定するユーザー名。

パスワード

管理コンソールにログインするために指定するパスワード。

パスワードの確認

確認のために再入力するパスワード。

アカウントの有効日

開始日

ユーザーがシステムでアクティブ化される日付。

終了日

ユーザーがシステムで非アクティブ化される日付。

プロビジョニング日

プロビジョニング日

ユーザーがシステムにプロビジョニングされる日付。

プロビジョニング解除日

ユーザーがシステムからプロビジョニング解除される日付。

その他のユーザー属性

国

ユーザーが常駐する国。

部門番号

ユーザーの部門番号。

共通名

ユーザーの共通名。

従業員番号

ユーザーの従業員番号。

FAX

ユーザーのFAX番号。

生成修飾子

ユーザーが生成に適格かどうか。

入社日

ユーザーの入社日。

自宅電話番号

ユーザーの自宅電話番号。

地方名

ユーザーが常駐する地方の名前。

モバイル

ユーザーのモバイル番号。

ページャ

ユーザーのページャ番号。

自宅住所

ユーザーの自宅住所。

住所

ユーザーの住所。

郵便番号

ユーザーの住所の郵便番号。

私書箱

ユーザーの住所の私書箱番号。

都道府県

ユーザーの都道府県名。

番地

ユーザーが常駐する住所の番地。

電話番号

ユーザーの住所の電話番号。

役職

ユーザーの役職。

イニシャル

ユーザーのイニシャル。

ユーザー、組織、ロールなどのエンティティを作成または更新するためのページでは、複数の言語で属性値を入力できます。

4. ユーザー情報を入力した後に、「保存」をクリックしてユーザーを作成します。

ヒント:

ユーザーは次のいずれかの方法で作成できます。

- Oracle Identity Administrationを使用

- 自己登録

- リクエストを作成

- SPML WebサービスまたはAPIを使用

前述のすべての方法について、Oracle Identity Managerでは、デフォルト・パスワード・ポリシー、またはデフォルト・ルールに対するパスワード・ポリシーが使用されます。別のパスワード・ポリシーを使用する場合は、Design Consoleを使用して、新しいパスワード・ポリシーをデフォルト・ルールに付加する必要があります。これを行う場合は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのパスワード・ポリシーの管理に関する項を参照してください。

11.3.3 ユーザー情報の表示と変更

ユーザーの表示操作では、「ユーザーの詳細」ページで詳細なユーザー・プロファイル情報を表示できます。このページは、認可ポリシーでユーザー詳細の表示権限によりユーザーのプロファイルを表示する権限が付与されている場合に開くことができます。ユーザーの変更権限がある場合は、このページを使用してユーザーを変更できます。

ユーザーの詳細を表示するには、次のいずれかを実行します。

- 単純検索の検索結果表で「ユーザー・ログイン」リンクをクリックします。

- 単純検索および拡張検索の両方について、ユーザーの検索結果表でレコードを選択し、「アクション」メニューの「ユーザーの変更」を選択します。または、ツールバーにある「ユーザーの変更」をクリックします。

表示および変更操作については、次の各項で説明します。

- 「ユーザーの詳細」ページ

- ユーザー変更

- 単一ユーザー操作

- バルク・ユーザー変更

11.3.3.1 「ユーザーの詳細」ページ

ユーザー・エンティティの「ユーザーの詳細」ページは、構成および認可に基づいて自動生成されます。このページは次のタブで構成されています。

- 「属性」タブ

- 「ロール」タブ

- 「リソース」タブ

- 「プロキシ」タブ

- 直属の部下

- 「リクエスト」タブ

11.3.3.1.1 「属性」タブ

このタブには、基本ユーザー情報、アカウント設定およびその他のユーザー属性に関する詳細を含めて、属性プロファイルが表示されます。属性プロファイル情報を変更するには、任意のフィールドを変更して「適用」をクリックします。

このページで加えた変更を取り消すには、「元に戻す」をクリックします。

11.3.3.1.2 「ロール」タブ

このタブには、ユーザーが属するロールのリストが表示されます。各ロールをクリックすると、そのロールのサマリー情報を表示できます。リスト内の各ロールに関して、次の情報が表示されます。

- 表示名: UIに表示される名前。

- ロール名: ユーザーに割り当てられたロールの名前。

- ロール・ネームスペース: ロールが割り当てられているネームスペース。

- 説明: ロールの説明。

「ロール」タブでは、ユーザーにロールを割り当てたり、ユーザーからロールを削除できます。詳細は、「ロールの追加と削除」を参照してください。

11.3.3.1.3 「リソース」タブ

このセクションには、ユーザーにプロビジョニングされたリソースのリストが表示されます。リスト内の各リソースに関して、次の情報が表示されます。

- リソース名: ユーザーに割り当てられたリソースの名前

- リクエストID: プロビジョニング済インスタンスがリクエストに関連付けられている場合

- サービス・アカウント: アカウントがサービス・アカウントとしてプロビジョニングされた場合は「はい」、そうでない場合は「いいえ」。

- 説明: プロビジョニング済インスタンス(ある場合)の説明

- タイプ: リソースのタイプ

- ステータス: リソースのステータス(「プロビジョニング済」、「有効」、「無効」など)

- プロビジョニング日: リソースがユーザーにプロビジョニングされた日付。

11.3.3.1.4 「プロキシ」タブ

このタブには、ユーザーに現在設定されているすべてのプロキシが表示されます。リスト内の各プロキシに関して、次の情報が表示されます。

- プロキシ名: プロキシ・ユーザーの表示名

- 開始日: プロキシ・ユーザーの開始日

- 終了日: プロキシ・ユーザーの終了日

- ステータス: プロキシ・ユーザーのステータス

- 関係: プロキシ・ユーザーとオープン・ユーザー(マネージャなど)の関係

- 最終更新: プロキシ・ユーザーが最後に更新された日付

このセクションには、終了日が表示されたユーザーのプロキシ情報の履歴も表示されます。「現行のプロキシ」には、ユーザーの現行のプロキシが表示されます。「過去のプロキシ」には、ユーザーのプロキシ履歴が表示されます。「過去のプロキシ」表に「ステータス」列は表示されません。

プロキシ情報が表示された表で行を選択すると、プロキシに関するサマリー情報が表示され、プロキシ名、ユーザーとの関係、開始日および終了日を編集できます。

「プロキシ」タブでは、ユーザーにプロキシを追加したり、ユーザーからプロキシを削除できます。プロキシの追加および削除については、「プロキシの詳細の変更」を参照してください。

11.3.3.1.5 直属の部下

このタブには、このユーザーをマネージャとして設定しているユーザーの読取り専用の表が表示されます。つまり、このタブには、ユーザーの直属の部下がリストされます。表内の各ユーザーに関して、次の情報が表示されます。

- 表示名

- ユーザー・ログイン

- ステータス

- 組織

表で行を選択すると、直属の部下に関するサマリー情報が下部に表示されます。

「直属の部下」では、直属の部下のユーザー詳細を開くことができます。これを行うには、直属の部下の表で行を選択し、「アクション」メニューから「ユーザーを開く」を選択します。または、ツールバーにある「ユーザーを開く」をクリックします。

11.3.3.1.6 「リクエスト」タブ

このタブには、ユーザーが要求したリクエスト(ユーザーがリクエスタの場合)、およびユーザーに対して要求されたリクエスト(ユーザーがターゲット・ユーザーの受益者の場合)が表示されます。各リクエストに関して、次の詳細が表示されます。

- リクエストID: リクエストを一意に識別するためのID

- モデル名: リクエストのモデル名

- ステータス: リクエストの現在の状況が表示されます

- リクエスト者: リクエストを要求したリクエスタ

- 親ID: リクエストが子リクエストの場合、親リクエスト(ある場合)のID

- リクエスト日: リクエストが作成された日付

関連項目:

リクエスト、リクエスト・タイプ、親リクエストおよび子リクエストについては、第14章「リクエストの作成と検索」を参照してください。

このタブでは、リクエストIDをクリックして、リクエストの詳細を開くことができます。

11.3.3.2 ユーザー変更

ユーザー詳細から管理ユーザー変更タスクを実行できます。変更はユーザー詳細が表示されているページの複数のタブで個別に行うため、各タブで実行した変更は他のタブに影響を与えず、変更内容は個別に保存する必要があります。各タブで実行できる変更について、次の各項で概略を説明します。

- 属性プロファイルの変更

- ロールの追加と削除

- リソースの追加と削除

- リソースの有効化と無効化

- リソースの詳細の表示

- リソース履歴の表示

- プロキシの詳細の変更

11.3.3.2.1 属性プロファイルの変更

属性プロファイル情報は、「ユーザーの詳細」ページの「属性」タブに表示されます。属性プロファイルを変更するには、「属性」タブでフィールドを編集し、「適用」をクリックします。

11.3.3.2.2 ロールの追加と削除

ロールを追加するには:

1. 「ロール」タブで、「アクション」メニューから「ロールの割当て」を選択します。または、ツールバーにある「ロールの割当て」をクリックします。「ロールの割当て先: ユーザー」ウィンドウが表示されます。

2. 「ロールの検索」リストから、ロールのタイプ、つまりロール・カテゴリを選択します。デフォルトのロール・カテゴリは「OIMロール」と「デフォルト」です。また、カスタムのロール・カテゴリを作成できます。ロール・カテゴリの詳細は、「ロール・カテゴリの作成と管理」を参照してください。

3. 次のフィールドで検索を実行できます。

- 表示名

- 名前

- ロール・ネームスペース

「すべて」または「いずれか」論理積演算子を選択します。これらの演算子については、「論理積演算子」を参照してください。

4. 検索フィールドに検索基準を入力します。検索基準にアスタリスク(*)ワイルドカード文字を指定できます。次に、「検索」アイコンをクリックします。選択したカテゴリに属するすべてのロールが「使用可能なロール」リストに表示されます。

5. 「使用可能なロール」リストから1つまたは複数のロールを選択します(連続した行を選択する場合は[Shift]を押しながらクリック、連続していない行を選択する場合は[Ctrl]を押しながらクリックします)。次に、「移動」または「すべて移動」ボタンをクリックして、選択したロールを「割当て対象ロール」リストに移動します。

関連項目:

Oracle Identity Managerのデフォルト・ロールについては、表12-5「Oracle Identity Managerのデフォルト・ロール」を参照してください。

6. 「OK」をクリックします。確認メッセージが表示され、選択したロールがユーザーに割り当てられます。

「ロール」タブでは、リストから1つまたは複数のロールを選択して削除できます。ロールを削除するには、次のようにします。

1. 削除するロールを1つまたは複数選択します。

2. 「アクション」メニューから「ロールの失効」を選択します。または、ツールバーにある「ロールの失効」をクリックします。確認を求めるメッセージが表示されます。

3. 「OK」をクリックします。ロールの割当てが成功すると、「ユーザーの詳細」ページに成功のメッセージが表示されます。

11.3.3.2.3 リソースの追加と削除

「リソース」タブでは、リストから1つまたは複数のリソースを選択して、リソースの追加と削除、リソースの有効化と無効化、リソースの詳細と履歴の表示など、様々な操作を実行できます。

ユーザーにリソースを追加する手順は、次のとおりです。

1. 「リソース」タブで、「アクション」メニューから「追加」を選択します。または、ツールバーにある「リソースの追加」をクリックします。「ユーザーへのリソースのプロビジョニング」ウィザードが表示されます。

2. 「ステップ1: リソースの選択」ページで、プロビジョニングするリソースを選択します。

3. 「続行」をクリックします。「ステップ2: リソースの選択の検証」ページが表示されます。このページには、ターゲット・ユーザーへのプロビジョニング対象として選択したリソースが表示されます。

4. 「続行」をクリックします。「ステップ3: プロセス・データ」ページが表示されます。

5. フィールドに値を入力して、選択したリソースに関する情報を指定します。

6. 「続行」をクリックします。「ステップ4: プロセス・データの検証」ページに、リソースに関する詳細が表示されます。
図11-5は「ステップ4: プロセス・データの検証」ページを示しており、ユーザーJohn Doe(ユーザーIDはJohnD)にプロビジョニングされたE-Business SuiteユーザーTCA Foundationリソースのサンプル値が表示されています。

図11-5 サンプル・プロセス・データ

「図11-5 サンプル・プロセス・データ」の説明

7. このページに表示される情報を編集するには、ページの右上隅にある「編集」をクリックします。「ステップ3: プロセス・データの指定」ページが表示され、プロセス・データを編集できます。終了後、「続行」をクリックして「ステップ4: プロセス・データの検証」ページに戻ります。
すべての情報を確認して、「続行」をクリックします。

警告:

「続行」をクリックする前に、必ずプロセス・データを確認してください。これは、「続行」をクリックするとプロビジョニングが開始されるためです。

8. 「続行」をクリックすると、選択したリソースのユーザーへのプロビジョニングが開始されます。プロビジョニングが開始されたことを示すメッセージが表示されます。

ユーザーからリソースを削除する手順は、次のとおりです。

1. 「リソース」タブで、削除するリソースを選択します。

2. 「アクション」メニューから「リソースの削除」を選択します。または、ツールバーにある「失効」をクリックします。確認メッセージが表示されます。

3. 「OK」をクリックします。リソースが削除され、成功のメッセージが表示されます。

11.3.3.2.4 リソースの有効化と無効化

リソースを有効化できるのは、選択したリソースのステータスが「無効」または「プロビジョニング済」の場合です。リソースを有効化する手順は、次のとおりです。

1. 「リソース」タブで、有効化するリソースを選択します。

2. 「アクション」メニューから「有効化」を選択します。確認メッセージが表示されます。

3. 「OK」をクリックします。リソースが有効化され、成功のメッセージが表示されます。

リソースを無効化できるのは、選択したリソースのステータスが「有効」の場合です。リソースを無効化する手順は、次のとおりです。

1. 「リソース」タブで、無効化するリソースを選択します。

2. 「アクション」メニューから「無効化」を選択します。確認メッセージが表示されます。

3. 「OK」をクリックします。リソースが無効化され、成功のメッセージが表示されます。

11.3.3.2.5 リソースの詳細の表示

リソースの詳細を表示する手順は、次のとおりです。

1. 「リソース」タブで、詳細を表示するリソースを選択します。

2. 「アクション」メニューから「開く」を選択します。ページにリソースの詳細が表示されます。このページで、リソースの詳細を編集できます。変更終了後、「保存」をクリックします。

11.3.3.2.6 リソース履歴の表示

リソース履歴を表示する手順は、次のとおりです。

1. 「リソース」タブで、履歴を表示するリソースを選択します。

2. 「アクション」メニューから「リソース履歴」を選択します。ページにリソースのプロビジョニングの詳細が表示されます。詳細には、タスク名、タスク詳細、割当て日、およびタスクが割り当てられるユーザーが含まれます。また、「再試行」チェック・ボックスも表示されます。失敗したすべてのタスクを再試行するには、これを選択する必要があります。

11.3.3.2.7 プロキシの詳細の変更

「プロキシ」タブでは、プロキシを追加したり、リストから1つまたは複数のプロキシを選択して次の操作を実行できます。

- プロキシの編集(単一ユーザーが選択されている場合のみ)

- プロキシの削除

プロキシを追加する手順は、次のとおりです。

1. 「プロキシ」タブで、「アクション」メニューから「追加」を選択します。「プロキシの追加」ダイアログ・ボックスが表示されます。

2. 「プロキシ名」フィールドで、適切なプロキシを選択します。プロキシには任意のユーザーを指定できます。「プロキシ名」フィールドの下にある検索フィールドでプロキシ・ユーザーの名前を検索するか、または「マネージャ」を選択してマネージャをプロキシとして追加します。

3. プロキシが代理で機能する開始日と終了日を指定します。

4. 「OK」をクリックします。確認を求めるメッセージが表示されます。

5. 「OK」をクリックします。プロキシが割り当てられたことを示す確認メッセージが表示されます。

プロキシを削除するには、「プロキシ」タブでプロキシを選択し、「プロキシの削除」をクリックします。

プロキシの詳細を変更する手順は、次のとおりです。

1. プロキシ情報が表示されている表で行を選択します。ページの下部に、プロキシの詳細が表示されます。

2. フィールドを編集して、プロキシ情報を変更します。

3. 「保存」をクリックします。

11.3.3.3 単一ユーザー操作

単一ユーザーに対するユーザー管理操作は、ユーザーの詳細が表示されているページから実行できます。操作は次のとおりです。

- ユーザーの有効化

- ユーザーの無効化

- ユーザーのロック

- ユーザーのロック解除

- ユーザーのパスワードのリセット

- ユーザーの削除

11.3.3.3.1 ユーザーの有効化

この操作は、ユーザー・ステータスが「無効」の場合のみ実行できます。ユーザーを有効化する手順は、次のとおりです。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「ユーザーの有効化」を選択します。または、ツールバーにある「ユーザーの有効化」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「ユーザーの有効化」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

3. 「OK」をクリックして処理を確認します。ユーザーが有効化されたことを示す確認メッセージが表示されます。
「ユーザーの詳細」ページからユーザーを有効化する場合は、正常に終了すると「属性」タブがリフレッシュされます。この操作をユーザー・リスト(単純検索や拡張検索の結果など)から実行すると、リスト内の対応する行がリフレッシュされます。

11.3.3.3.2 ユーザーの無効化

この操作は、ユーザー・ステータスが「有効」の場合のみ実行できます。ユーザーを無効化する手順は、次のとおりです。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「ユーザーの無効化」を選択します。または、ツールバーにある「ユーザーの無効化」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「ユーザーの無効化」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

3. 「OK」をクリックして処理を確認します。ユーザーが無効化されたことを示す確認メッセージが表示されます。
「ユーザーの詳細」ページからユーザーを無効化する場合は、正常に終了すると「属性」タブがリフレッシュされます。この操作をユーザー・リスト(単純検索や拡張検索の結果など)から実行すると、リスト内の対応する行がリフレッシュされます。

11.3.3.3.3 ユーザーのロック

この操作は、ユーザー・アカウントがロック解除されている場合のみ実行できます。ユーザーをロックする手順は、次のとおりです。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「アカウントのロック」を選択します。または、ツールバーにある「アカウントのロック」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「アカウントのロック」をクリックします。確認を求めるメッセージが表示されます。

3. 「OK」をクリックします。ユーザーが正常にロックされたことを示す確認メッセージが表示されます。
「ユーザーの詳細」ページからアカウントをロックする場合は、正常に終了すると「属性」タブがリフレッシュされます。この操作をユーザー・リスト(単純検索や拡張検索の結果など)から実行すると、リスト内の対応する行がリフレッシュされます。

11.3.3.3.4 ユーザーのロック解除

この操作は、ユーザー・アカウントがロックされている場合のみ実行できます。ユーザーをロック解除する手順は、次のとおりです。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「アカウントのロック解除」を選択します。または、ツールバーにある「アカウントのロック解除」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「アカウントのロック解除」をクリックします。確認を求めるメッセージが表示されます。

3. 「OK」をクリックします。ユーザーが正常にロック解除されたことを示す確認メッセージが表示されます。
「ユーザーの詳細」ページからアカウントをロック解除する場合は、正常に終了すると「属性」タブがリフレッシュされます。この操作をユーザー・リスト(単純検索や拡張検索の結果など)から実行すると、リスト内の対応する行がリフレッシュされます。

11.3.3.3.5 ユーザーのパスワードのリセット

次のいずれかを実行して、ユーザーのパスワードをリセットできます。

- パスワードを手動で生成: ユーザーがパスワードを忘れたためヘルプデスクに連絡してきた場合など、パスワードをすぐにリセットする必要がある場合は、ユーザーのパスワードを手動でリセットできます。ヘルプデスクではパスワードを入力することによって即時にパスワードをリセットでき、ユーザーは新しいパスワードを使用してログインできます。この方法によって、ユーザーは電子メールによる通知を待つより迅速に問題を解決できます。

- ランダム・パスワードの生成: ターゲット・ユーザー以外のユーザー(たとえば、管理者)がパスワードをリセットする必要がある場合、ランダム・パスワードを生成すると、パスワードを変更したユーザーは新しいパスワードがわからないため便利です。ランダム・パスワードは次の場合に生成できます。

- ユーザーがパスワードを忘れたため、パスワードをリセットする必要があります。

- パスワードの有効期限が切れました。ユーザーがロックされました。

- ユーザーがロックされました。

このような場合、パスワードをリセットすると、Oracle Identity Managerでは指定のパスワード・ポリシーに準拠した新しいランダム・パスワードを自動的に生成できます。また、パスワードをリセットするとき、管理者はチェック・ボックスを選択して、ユーザーにパスワード変更を通知する電子メールを送信することもできます。この方法によって、他人が簡単に推測できない一時的なパスワードをランダムに生成できます。ランダム・パスワードを生成した後、ユーザーは次のログイン時に、ランダム生成されたパスワードをリセットするように要求されます。

ユーザーのパスワードをリセットする手順は、次のとおりです。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「パスワードのリセット」を選択します。または、ツールバーにある「パスワードのリセット」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「パスワードのリセット」をクリックします。図11-6に示すように、「パスワードのリセット」ダイアログ・ボックスが表示されます。

図11-6 「パスワードのリセット」ダイアログ・ボックス

「図11-6 「パスワードのリセット」ダイアログ・ボックス」の説明

3. ユーザーのパスワードを手動で変更する手順は、次のとおりです。

1. 「パスワードを手動で変更」オプションを選択します。

2. 「新規パスワード」フィールドに、「パスワード・ポリシー」セクションに表示されたパスワード・ポリシーに準拠する新しいパスワードを入力します。
「パスワード・ポリシー」セクションには、ユーザーに割り当てられたパスワード・ポリシーが表示されます。パスワード・ポリシーが定義されていない場合、このセクションにパスワード・ポリシーは表示されません。パスワード・ポリシーについては、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのパスワード・ポリシーの管理に関する項を参照してください。

3. 「新規パスワードの確認」フィールドに、パスワードを再入力します。

4. ランダム・パスワードを生成するには、「パスワードの自動生成(ランダム生成)」オプションを選択します。

5. 新規パスワードがユーザーに電子メールで送信されるように、「新規パスワードをユーザーに電子メールで送信します。」オプションが選択されていることを確認します。

6. 「パスワードのリセット」をクリックします。パスワードが正常に変更されたことを示す確認メッセージが表示されます。

ヒント:

ユーザーがパスワードを忘れた場合は、パスワードを取得するためのチャレンジ質問がユーザーに提示されます。ユーザーは、パスワードの作成時に指定したのと同じ回答を入力する必要があります。ユーザーに対するチャレンジ質問は、Oracle Identity Manager Design Consoleを使用して構成できます。『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のユーザーに対するチャレンジ質問の構成に関する項を参照してください。

11.3.3.3.6 ユーザーの削除

この操作は、ユーザー・ステータスが「削除」でない場合のみ実行できます。

ユーザーが現在は無効で、「自動削除日」属性が将来の日付に設定されている場合、無効化操作は失敗し、ユーザーは将来の日付に削除されるように現在スケジュールされているため削除できないことを示すメッセージが表示されます。

ユーザーを削除するには、次の手順を実行します。

1. Oracle Identity Manager管理の左ペインにあるユーザー検索結果で、ユーザーを選択します。または、拡張検索の検索結果からユーザーを選択します。さらに、この操作は、ユーザーの詳細が表示されているページからも実行できます。

2. 「アクション」メニューから「ユーザーの削除」を選択します。または、ツールバーにある「ユーザーの削除」アイコンをクリックします。ユーザーの「ユーザーの詳細」ページを開いている場合は、ツールバーにある「ユーザーの削除」をクリックします。確認を求めるメッセージが表示されます。

3. 「OK」をクリックします。ユーザーが正常に削除されたことを示す確認メッセージが表示されます。

4. 「OK」をクリックしてメッセージ・ボックスを閉じます。
「ユーザーの詳細」ページからユーザーを削除する場合は、正常に終了すると「属性」タブがリフレッシュされます。この操作をユーザー・リスト(単純検索や拡張検索の結果など)から実行すると、リスト内の対応する行がリフレッシュされます。

削除操作によってユーザーを即時に削除しない場合があります。かわりに、削除操作では、事前定義された期間内はユーザーを無効にし、その期間中は削除操作を取り消すことができるようにします。事前定義された期間を経過すると、ユーザーは削除されます。これを遅延削除と呼びます。

Oracle Identity Managerで遅延削除を構成するには、「遅延ユーザー削除までの期間」構成プロパティを定義して、削除操作を保留する事前定義の待機期間を指定します。遅延削除を構成しない場合は、ユーザー削除の遅延期間構成プロパティの値を0または負の数値に設定します。ユーザーが削除された後、ユーザーが完全に削除される日時を指定した日付カウンタがあるユーザー・エンティティを無効化する場合は、ユーザー削除の遅延期間構成プロパティの値を0より大きい数値に設定します。

注意:

遅延削除を構成する手順は、次のとおりです。

1. Oracle Identity Manager管理の「ようこそ」ページで、「システム管理」の下にある「システム構成」をクリックします。

2. 左ペインで、システム・プロパティを検索します。

3. 検索結果から、ユーザー削除の遅延期間プロパティを選択します。

4. プロパティ値を編集して、ユーザー削除の遅延期間を指定します。

5. プロパティを保存します。

システム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

遅延削除の結果は次のとおりです。

- 「無効化」ステータスは通常の無効化操作と同様で、ユーザーはOracle Identity Managerにログインできず、プロビジョニングされたリソースは無効化されます。

- ユーザーが「無効化」ステータスの場合は、そのユーザーを有効化すると削除操作は取り消されます。ユーザーが削除される日付はユーザー・プロファイルに表示されます。

- ユーザーが無効化されたままで事前定義された期間を経過すると、ユーザーはその時点で削除されます。

11.3.3.4 バルク・ユーザー変更

バルク操作は、単純検索および拡張検索の検索結果から実行できます。複数のユーザーを選択し、「アクション」メニューから使用可能なオプションを選択できます。次のバルク操作を実行できます。

- ユーザーの有効化: 選択したすべてのユーザーが「無効」状態の場合

- ユーザーの無効化: 選択したすべてのユーザーが「有効」状態の場合

- ユーザーのロック: 選択したすべてのユーザーが「ロック解除」状態の場合

- ユーザーのロック解除: 選択したすべてのユーザーが「ロック」状態の場合

- ユーザーの削除: 選択したすべてのユーザーが「削除」状態でない場合

注意:

すべてのバルク変更操作について、認可が必要であり、複数のユーザーを選択する必要があります。

「バルク変更」ページを使用すると、複数のユーザーを同時に変更できます。このページは、Oracle Identity Managerの組織において、認可ポリシーでユーザー・プロファイルの変更権限によりユーザーを変更する権限が付与されている場合に開くことができます。

「バルク変更」ページは、次のいずれかの方法で開くことができます。

- ユーザー検索結果ページで、「アクション」メニューから「バルク変更」を選択し、複数のユーザーを選択します。

- ユーザー検索結果ページで、ツールバーにある「バルク変更」を選択し、複数のユーザーを選択します。

表11-6に、「バルク変更」ページの各セクションにあるフィールドを示します。

表11-6 「バルク変更」ページのフィールド

セクション

フィールド

説明

基本ユーザー情報

Design Consoleのアクセス

ユーザーがDesign Consoleにログインできるかどうかを指定する「Design Consoleのアクセス」チェック・ボックス。

マネージャ

選択したユーザーのレポート・マネージャ。

組織

選択したユーザーが所属する組織。

ユーザー・タイプ

選択した従業員のタイプ(フルタイムの従業員、インターン、契約者、パートタイムの従業員、コンサルタント、派遣社員など)。

アカウントの有効日

開始日

選択したユーザーがシステムでアクティブ化される日付。

終了日

選択したユーザーがシステムで非アクティブ化される日付。

プロビジョニング日

プロビジョニング日

ユーザーがプロビジョニングされる日付。

プロビジョニング解除日

ユーザーがプロビジョニングされる日付。

「バルク変更」ページにフィールドとして表示されるのは、ユーザー管理構成で変更操作の一部として構成された属性のみです。表示される属性は、ユーザー・エンティティ定義でバルク更新のサポート・プロパティを「はい」に設定して定義した属性に制限されます。さらに、変更権限がある選択済ユーザーに対して属性を指定する認可ポリシーに基づいて、属性がフィルタ処理されます。

権限は認可ポリシーに基づいています。たとえば、認可ポリシーで、あるユーザーは名のみ変更でき、別のユーザーは姓のみ変更できると定義されている場合は、選択したユーザーに基づいてこれらのユーザーの姓名と属性を選択してページに表示しようとしても、表示されるフィールドがない場合があります。その結果、「バルク変更」ページには、選択したユーザーの属性を一括で変更できないため、ユーザーの選択項目を変更する必要があることを示すエラー・メッセージが表示されます。

11.4 ユーザー管理の認可

ランタイム・セキュリティは、認可ポリシーを使用してユーザー管理サービスに適用されます。Oracle Identity Managerの各ロールは、1つ以上の認可ポリシーに関連付けることができます。ロールのメンバーであるユーザーには、関連付けられた認可ポリシーによってロールに付与された権限に基づいて、様々なユーザー・タスクを実行する権限が付与されます。1名のユーザーが複数のロールを持つ場合があるため、割り当てられた複数のロールの権限が累積されてユーザーの権限になります。

アクセス制御は、Oracle Entitlements Server (OES)で管理される認可ポリシーの形式で実装されます。これらのポリシーでは、ロールおよびターゲットに関する制御を定義します。ターゲットとは、権限、エンティティおよびエンティティ属性の組合せです。

関連項目:

Oracle Identity Managerの認可ポリシーの詳細は、第15章「認可ポリシーの管理」を参照してください。

ユーザーに、同じ状況で異なる認可ポリシーが適用可能な複数のロールがある場合、そのユーザーのアクセス権はポリシー間の権限の累積になります。つまり、読取り権限を持つポリシーがロールに付与され、書込み権限を持つポリシーが別のロールに付与されている場合、両方のロールを持つユーザーは読取り権限と書込み権限を持ちます。

認可モデルについては、次の各トピックで説明します。

- 権限

- 属性

- データ制約

- 複数のポリシーを使用する認可

11.4.1 権限

すべての認可権限は、認可ポリシーによって制御されます。Oracle Identity Managerでは、アプリケーションで各種操作を実行するために、アクセス権を制御する権限を明示的に定義します。

表11-7に、認可ポリシーの定義でロールに割り当てることができ、Oracle Identity Managerのユーザー管理機能で使用可能な認可権限を示します。

注意:

エンティティ・インスタンス・レベルでは、すべての権限について、ログイン・ユーザーが権限を持つユーザーを決定する修飾子が必要です。

表11-7 ユーザー管理の認可権限

権限

説明

ユーザーの検索

この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。この修飾子の定義については、第15章「認可ポリシーの管理」を参照してください。

注意:

- ユーザーの検索権限は、ユーザー詳細の表示権限に基づいて、ユーザー検索の検索結果に含めることができる属性と検索基準に含めることができる属性を決定します。このため、ユーザーの検索権限を付与するユーザー管理ポリシーでは、ユーザー詳細の表示権限も付与する必要があります。ユーザー詳細の表示権限には、「ユーザー・ログイン」、「アカウント・ステータス」、「アイデンティティ・ステータス」および「表示名」の各属性を含める必要があります。これらの属性を含めないと、ユーザーが表示や編集を完全に実行できない場合があります。

- また、ユーザーがユーザー属性に基づいて検索を実行できるようにするには、ユーザー構成で属性を「検索可能」として構成する必要があります。

検索操作用に、ユーザーが検索可能な対象を決定するためのデフォルト認可ポリシーが用意されています。ユーザー管理のデフォルト認可ポリシーについては、「ユーザー管理」を参照してください。

ユーザー詳細の表示

この権限は、検索結果表からユーザーの「ユーザーの詳細」ページを表示できるかどうかを決定します。

この権限では、次の詳細なアクセス制御がサポートされています。

- エンティティ・インスタンス・レベル: 組織メンバーシップまたは管理チェーン(あるいはその両方)に関して修飾子を定義できます。これらの修飾子を定義する方法の詳細は、「ユーザー管理に対する認可ポリシーの作成」を参照してください。ユーザー管理の認可ポリシーで使用するデータ制約については、「データ制約」を参照してください。

- 属性レベル: 「ユーザーの詳細」ページに属性を表示するための権限を決定する修飾子が必要です。この修飾子には、ユーザー・エンティティ定義から表示可能なすべての属性がリストされる必要があります。

注意: ユーザー詳細の表示権限では、ユーザーが表示できる詳細セクションを指定できません。この権限は、すべてのセクションを含む完全な「ユーザーの詳細」ページを表示できるかどうかを決定します。「ユーザーの詳細」ページが表示できる場合、この権限はユーザーの属性プロファイルに表示される属性を決定します。

ユーザー・プロファイルの変更

この権限は、「ユーザーの詳細」ページでユーザーのユーザー・プロファイル属性を変更できるかどうかを決定します。

この権限では、次の詳細なアクセス制御がサポートされています。

- エンティティ・インスタンス・レベル: 組織、ロール・メンバーシップまたは属性ベース・ルールに関して修飾子を定義できます。

- 属性レベル: 「ユーザーの詳細」ページで属性を変更するための権限を決定する修飾子が必要です。この修飾子には、ユーザー・エンティティ定義から編集可能なすべての属性がリストされる必要があります。また、すべての属性に対するユーザー詳細の表示権限を付与する必要があります。

ユーザーへのリソースのプロビジョニング

この権限は、「ユーザーの詳細」ページの「リソース・プロファイル」セクションでユーザーにリソースをプロビジョニングまたはプロビジョニング解除できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

ユーザー・プロキシ・プロファイルの変更

この権限は、「ユーザーの詳細」ページの「プロキシ詳細」セクションでユーザーのプロキシ詳細を変更できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

ユーザー・ステータスの変更

この権限は、ユーザーを有効化または無効化できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

OIMアカウント・ステータスの変更

この権限は、ユーザーをロックまたはロック解除できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

ユーザーの削除

この権限は、ユーザーを削除できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

パスワードの変更

この権限は、ユーザーのエンタープライズ・パスワードを変更できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

ユーザーの作成

この権限は、Oracle Identity Managerでユーザーを作成できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織に関して定義する必要があります。

アクセス・ポリシーの評価

この権限は、ユーザーのアクセス・ポリシー評価を必要なときに開始できるかどうかを決定します。

注意: オンデマンドのアクセス・ポリシー評価を開始するためのUI操作はありません。

ユーザー・リクエストの表示

この権限は、ユーザーに要求されたリクエストを表示できるかどうかを決定します。

ユーザー・パスワードの変更

この権限は、ユーザーのパスワードを変更できるかどうかを決定します。ログイン・ユーザーがこの権限を持つユーザーを決定する修飾子が必要です。この修飾子は、組織、ロール・メンバーシップまたは属性ベース・ルールに関して定義できます。

注意:

ロール管理のロール・メンバーシップの変更権限は、ユーザーが「ユーザーの変更」ページの「ロール」タブからロール操作の追加または削除を実行できるかどうかを決定します。この権限の詳細は、「ロールに対する認可の管理」を参照してください。

11.4.2 属性

属性に対する読取り/書込み権限は、表示操作または変更操作の際に実際に読取りまたは変更可能な属性のセットを定義します。

11.4.3 データ制約

次のデータ制約は、ユーザー管理の認可ポリシーで使用されます。

- 組織のリスト: 割当て先の権限の範囲を、リストされた組織のみに制限します。組織メンバーシップは、認可ポリシーUIの「階層対応」オプションで制御できます。

- 「階層対応」オプションが「False」に設定されている場合、権限の範囲は組織の直接メンバーであるユーザーのみになります。たとえば、「開発センター」という組織があり、下位組織として「米国開発センター」と「中国開発センター」がある場合、権限の範囲は「開発センター」の直属のユーザーに適用されます。

- 「階層対応」オプションが「True」に設定されている場合、権限の範囲は、リストされている組織の直接メンバーであるユーザー、およびその組織の下位組織のメンバーであるユーザーに適用されます。たとえば、「開発センター」という組織があり、下位組織として「米国開発センター」と「中国開発センター」がある場合、権限の範囲はこれらすべての組織のユーザーに適用されます。

- 割当て先が同じ組織内: このフラグは、割当て先の権限の範囲を割当て先の組織のみに制限します。たとえば、ポリシーの組織リストが米国、中国およびカナダであるとします。このフラグが設定され、割当て先の組織が米国の場合、権限の範囲は米国組織のみに適用されます。

- ユーザーの管理チェーン: このフラグは、割当て先の権限の範囲を、割当て先の直属の部下および間接的な部下のみに制限します。次に例を示します。
DR1、DR2およびDR3はM1の直属の部下です。

DR1_1、DR1_2、DR1_3およびDR1_4はDR1の直属の部下です。

DR2_1、DR2_2およびDR2_3はDR2の直属の部下です。

DR2_2_1およびDR2_2_2はDR2_2の直属の部下です。

「ユーザーの管理チェーン」オプションが選択されている場合、M1の権限の範囲は、DR1、DR2、DR3およびその直属の部下と間接的な部下すべてに適用されます。

11.4.4 複数のポリシーを使用する認可

ユーザーに、同じ状況で異なる認可ポリシーが適用可能な複数のロールがある場合、そのユーザーのアクセス権はポリシー間の権限の累積になります。

ユーザーの検索権限に対する認可チェックでは、責任のリストが返されます。これは、適用可能な各認可ポリシーからの責任のリストです。複数のポリシーからの責任が組み合されて、統合された検索結果が生成されます。

この項では、様々なユーザー管理操作に対する責任の処理方法を説明します。内容は次のとおりです。

- 複数の認可ポリシーを使用する検索操作の認可

- 複数の認可ポリシーを使用する変更操作の認可

11.4.4.1 複数の認可ポリシーを使用する検索操作の認可

検索操作に対して、次のタイプの責任があります。

- 組織のリスト: 組織のリストには、「階層対応」データ制約で制御される、組織の直接メンバーシップまたは間接メンバーシップのリストがあります。特殊な値として、Oracle Identity Managerの全組織のリストがあります。ログイン・ユーザーは、この組織セット内のみ検索できます。

- 同じ組織内: この責任は、ログイン・ユーザーが自分の組織内のユーザーのみを検索できることを意味します。

- 管理階層内: この責任は、ログイン・ユーザーが自分の管理階層内の全ユーザーを検索できることを意味します。

- 表示可能な属性: この責任には、認可された表示可能な属性のリストが含まれます。検索操作は、これらの属性に対してのみ実行できます。

ユーザーに検索権限を付与する認可ポリシーが複数ある場合、検索は次のように動作します。

1. ログイン・ユーザーによる検索が可能なユーザーは、各ポリシーによって検索権限が付与されたユーザーの集合になります。

2. 検索結果の一部として返される属性は、各ポリシーによってユーザー詳細の表示権限が付与された属性の集合になります。

次の例を使用して説明します。

Policy1は、「名」、「姓」および「ミドル・ネーム」属性を返し、Policy2は「ユーザー・ログイン」、「ユーザー・タイプ」および「OIMユーザー・タイプ」属性を返します。両方のポリシーからの責任が適用されると、返される属性リストには、すべてのユーザーの「名」、「姓」、「ミドル・ネーム」、「ユーザー・ログイン」、「ユーザー・タイプ」および「OIMユーザー・タイプ」が含まれます。ユーザーが結果の一部として選択されているため、ポリシーはチェックされません。したがって、検索結果に機密データを表示する構成サービスからは属性を構成しないでください。

別の例では、検索操作に対して3つの認可ポリシーが定義されているとします。次の表に、サンプルの認可ポリシーの詳細を示します。

ポリシー名

エンティティ名

権限

データ制約

割当て

Policy1

ユーザー管理

検索

ユーザー・プロファイルの変更。属性には「名」、「姓」および「ミドル・ネーム」が含まれます。

ユーザー詳細の表示。属性には「表示名」、「名」、「姓」および「ミドル・ネーム」が含まれます。

ユーザーはOrg1およびOrg2組織のメンバー。階層対応(すべての子組織を含める) = True。

ロール: Role1

ユーザーの管理チェーン = FALSE

割当て先はユーザーの組織のメンバーである必要があります = True

Policy2

ユーザー管理

検索

ユーザー・プロファイルの変更。属性には「ユーザー・タイプ」が含まれます。

ユーザー詳細の表示。属性には「ユーザー・ログイン」、「ユーザー・タイプ」および「OIMユーザー・タイプ」が含まれます。

ユーザーはOrg3組織のメンバー。階層対応(すべての子組織を含める) = FALSE。

ロール: Role2

ユーザーの管理チェーン = FALSE

割当て先はユーザーの組織のメンバーである必要があります = FALSE

Policy3

ユーザー管理

検索

ユーザー・プロファイルの変更。属性には職種が含まれます。

ユーザー詳細の表示。属性には「ユーザー・ログイン」、「ユーザー・タイプ」、「OIMユーザー・タイプ」および職種が含まれます。

すべてのユーザー。

ロール: Role2

ユーザーの管理チェーン = True

割当て先はユーザーの組織のメンバーである必要があります = FALSE

この例では、次のようになります。

- Org1には、子組織としてOrg1Child1とOrg1Child2があります。

- Org1Child1には、子組織としてOrg1Child1_Child1があります。

- Org3には、子組織としてOrg3Child1とOrg3Child2があります。

次のシナリオを検討してください。

シナリオI:

User1はRole1のみを持ち、Org1Child1組織に所属しています。このユーザーは次のことができます。

- Org1Child1組織のメンバーであるユーザーを検索します。検索は、ユーザー属性「名」、「姓」、「ミドル・ネーム」および「表示名」に基づいて実行でき、検索結果にこれらの属性のサブセットを表示できます。

- Org1Child1組織のユーザー属性「名」、「姓」および「ミドル・ネーム」を変更します。

シナリオII:

User2はRole1とRole2を持ち、Org2組織に所属しています。User2には、直属の部下として、Org2組織に所属するDR1とDR2がいます。このユーザーは次のことができます。

- Policy2に基づいて、Org3組織のユーザー属性「ユーザー・ログイン」、「ユーザー・タイプ」および「OIMユーザー・タイプ」を表示します。

- Policy2に基づいて、Org3組織の「ユーザー・タイプ」属性を変更します。

- Policy1に基づいて、Org2組織のユーザー属性「名」、「姓」および「ミドル・ネーム」を表示します。

- Policy1に基づいて、Org2組織のユーザー属性「名」、「姓」および「ミドル・ネーム」を変更します。

- Policy3に基づいて、ユーザーの直属の部下全員のユーザー属性「ユーザー・ログイン」、「ユーザー・タイプ」、「OIMユーザー・タイプ」および職種を表示します。

- Policy3に基づいて、ユーザーの直属の部下全員の職種属性を変更します。

変更対象のユーザーがDR1の場合、変更可能な属性のリストには、Policy1に基づいて「名」、「姓」、「ミドル・ネーム」、およびPolicy3に基づいて職種が含まれます。

Org3の子組織であるOrg3Child1およびOrg3Child2のユーザーは、ユーザーの表示、変更および検索はできません。

これらのシナリオに基づいて、検索操作では、3つの認可ポリシーに従って表示可能な属性の集合がユーザーに表示されます。つまり、認可ポリシーに関係なく、ユーザーは検索結果で「ユーザー・ログイン」、「ユーザー・タイプ」、「OIMユーザー・タイプ」、「名」、「姓」、「ミドル・ネーム」、「表示名」および職種属性を確認できます。職種属性は、User2の直属の部下であるDR1とDR2だけでなく、すべてのユーザーに対して結果に表示されます。

11.4.4.2 複数の認可ポリシーを使用する変更操作の認可

ログイン・ユーザーが複数のポリシーの定義に従ってユーザー・プロファイルの変更を許可されている場合は、各ポリシーからの属性の集合を使用して操作を実行できます。適用可能な認可ポリシーが複数ある場合の変更操作に関する例については、「複数の認可ポリシーを使用する検索操作の認可」の「シナリオII」を参照してください。

11.5 ユーザー名の予約

Oracle Identity ManagerセルフサービスまたはOracle Identity Manager管理から、ユーザーを作成するリクエストを要求できます。リクエストの送信時には、次のようなシナリオが考えられます。

- リクエストが保留中の間に、同じユーザー名で別のユーザー作成リクエストが送信されました。2番目のリクエストが承認されてユーザーが作成されると、1番目のリクエストは、ユーザー名がすでにOracle Identity Managerに存在するため、承認時に失敗します。

- リクエストが保留中の間に、同じユーザー名の別のユーザーがLDAPアイデンティティ・ストアに直接作成されました。ユーザー作成リクエストが承認され、ユーザー・エンティティをLDAPにプロビジョニングするときに、同じユーザー名のエントリがすでにLDAPに存在するため、リクエストは失敗します。

これらの問題を回避するには、ユーザー作成リクエストが承認のために保留中の間、Oracle Identity ManagerとLDAPの両方でユーザー名を予約できます。同じユーザー名のユーザーを作成するリクエストが作成されると、エラー・メッセージが表示され、そのユーザー作成リクエストは作成されません。

関連項目:

ユーザーを作成する作成リクエストについては、「ユーザーを作成するリクエストの作成」を参照してください。

ユーザー名を予約するには、次のことが必要です。

- 「ユーザー属性予約有効」システム・プロパティを「True」に設定して、機能を有効化する必要があります。システム・プロパティの検索と変更については、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

- LDAPで予約が行われるのは、予約機能が有効化され、LDAPがOracle Identity Managerデータベースと同期化している場合のみです。Oracle identity ManagerとLDAPアイデンティティ・ストアの同期化については、「LDAPアイデンティティ・ストアとOracle Identity Managerの統合」を参照してください。

注意:

- LDAPプロバイダが構成されていない場合、予約はOracle Identity Managerでのみ行われます。

- LDAPの同期化およびユーザー属性の予約機能が有効な場合は、ディレクトリ・サーバーでUID一意性を有効化することをお薦めします。そうしないと、ユーザーが予約コンテナに予約されているときに、同じユーザーIDのユーザーをユーザー・コンテナに作成できるため、ディレクトリ内でユーザーの予約が適切に機能しません。この結果、Oracle Identity Managerでユーザーを予約コンテナからユーザー・コンテナに移動するときに、ユーザー作成が失敗します。

ユーザー属性の予約が有効な場合、予約は2つのフェーズで行われます。

最初のフェーズでは、エントリがOracle Identity Managerデータベースに作成され、ユーザーが予約コンテナに作成されます。Oracle Identity Managerデータベース内のこのエントリは、ユーザーが正常に作成された後、承認者によって却下された後、またはリクエストが失敗した後に削除されます。

2番目のフェーズでは、LDAPでユーザーが正常に作成されると、ユーザーが予約コンテナに移動します。他の状況(承認者による却下、リクエストの失敗など)の場合、ユーザーは予約コンテナから削除されます。

ユーザー作成リクエストがリクエスト・レベルおよび操作レベルで承認された後は、LDAPのユーザー名コンテナにユーザー名は予約されません。ユーザー名は、既存のユーザーが格納されているコンテナに移動します。また、ユーザーはOracle Identity Managerでも作成されます。

この項には、次の項目が含まれます。

- ユーザー名の予約の有効化と無効化

- ユーザー名ポリシーの構成

- ユーザー名の解放

- Microsoft Active Directoryサポートのためのユーザー名生成の構成

11.5.1 ユーザー名の予約の有効化と無効化

Oracle Identity Managerでは、デフォルトで、ユーザー名の予約機能が有効化されます。これを行うには、「ユーザー属性予約有効」システム・プロパティの値を「True」に設定します。このシステム・プロパティの値は、Oracle Identity Manager管理の「システム構成」セクションで確認できます。

ユーザー名の予約を無効化する手順は、次のとおりです。

1. 管理およびユーザー・コンソールにログインします。

2. 拡張管理をクリックします。

3. 「システム管理」をクリックします。

4. 「システム構成」をクリックします。

5. 左ペインで「検索」アイコンをクリックして、既存のすべてのシステム・プロパティを検索します。システム・プロパティのリストが検索結果表に表示されます。

6. 「ユーザー属性予約有効」をクリックします。図11-7に示すように、選択したシステム・プロパティの「システム・プロパティ詳細」ページが表示されます。

図11-7 「システム・プロパティ詳細」ページ

「図11-7 「システム・プロパティ詳細」ページ」の説明

7. 「値」フィールドに「False」と入力します。

8. 「保存」をクリックします。ユーザー名の予約機能が無効化されます。

11.5.2 ユーザー名ポリシーの構成

ユーザー名ポリシーは、ユーザー名操作(ユーザー名の生成や検証など)のためのプラグイン実装です。ポリシーは、Oracle Identity Managerのプラグイン・フレームワークに従っています。独自のポリシーを追加するには、Oracle Identity Administrationの「システム構成」セクションで、新規プラグインを追加してデフォルト・ポリシーを変更します。

関連項目:

プラグイン・フレームワークについては、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプラグインの開発に関する項を参照してください。

ユーザー作成リクエストの場合、プラグインが起動するのはユーザー・ログインが入力されない場合のみです。この場合、起動されるプラグインは、「ユーザー名の生成に関するデフォルト・ポリシー」システム・プロパティから取得されます。

表11-8に、Oracle Identity Managerで提供される事前定義済のユーザー名ポリシーを示します。この表で、生成されるユーザー名に含まれるドル記号($)はランダムなアルファベットを示します。

表11-8 事前定義済のユーザー名ポリシー

ポリシー名

必要な情報

生成されるユーザー名

oracle.iam.identity.usermgmt.impl.plugins.EmailUserNamePolicy

電子メール

電子メールを入力すると、電子メールがユーザー名として生成されます。

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstInitialLocalePolicy

名、姓およびロケール

last name + first initial_locale、last name + middle initial + first initial_locale、last name + $ + first initial_locale(すべてのアルファベットからランダムな1文字)、last name + $$ + first initial_locale

oracle.iam.identity.usermgmt.impl.plugins.FirstInitialLastNameLocalePolicy

名、姓、ロケール

first initial + lastname_locale、first initial + middle initial + first name_locale、first initial + $ + lastname_locale、first initial + $$ + lastname_locale

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstInitialPolicy

名、姓

lastname+firstInitial、lastname+middleinitial+firstInitial、lastname+$+firstInitial(すべてのアルファベットからランダムな1文字)、lastname+$$+firstInitial

oracle.iam.identity.usermgmt.impl.plugins.FirstInitialLastNamePolicy

名、姓

firstInitial+lastname、firstInitial+middleInitial+firstname、firstInitial+$+lastname、firstInitial+$$+lastname

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicy

名、姓

lastname.firstname、lastname.middleinitial.firstname、lastname.$.firstname(すべてのアルファベットからランダムな1文字)、lastname.$$.firstname

oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicy

名、姓

firstname.lastname、firstname.middleinitial.lastname、firstname.$.lastname(すべてのアルファベットからランダムな1文字)、firstname.$$.lastname

oracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicy

電子メール

電子メールを入力すると、ユーザー名は電子メールに基づいて生成されます。電子メールを使用できない場合は、名と姓に基づき、ユーザー・ドメインを付加してユーザー名が生成されます。ユーザー・ドメインは「デフォルト・ユーザー名ドメイン」システム・プロパティとして構成され、デフォルト値は「@oracle.com」です。

oracle.iam.identity.usermgmt.impl.plugins.LastNamePolicy,

姓

lastname、middle initial + lastname、$ + lastname、$$ + lastname

oracle.iam.identity.usermgmt.impl.plugins.LastNameLocalePolicy

姓、ロケール

lastname_locale、middle initial + lastname_locale、$ + lastname_locale、$$ + lastname_locale

oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyForAD

名、姓

firstname+lastname、firstnameの部分文字列+lastname+$、firstnameの部分文字列+lastnameの部分文字列+$

oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicyForAD

姓、名

lastname+firstname、lastname+firstnameの部分文字列+$、lastnameの部分文字列+firstnameの部分文字列+$

ユーザー名生成形式のすべてのパラメータに対して値を入力する必要があります。入力されないパラメータがあると、Oracle Identity Managerでエラーが発生します。たとえば、firstname.lastnameポリシーが構成され、firstnameが入力されない場合は、次のエラーが表示されます: 「ユーザー名の生成中にエラーが発生しました。firstname.lastnameポリシーで必要なfirstnameを指定してください。」

UserManagerでは、ユーザー名操作用にAPIが公開されます。APIでは、ユーザー・データを入力として取得し、生成されたユーザー名を返します。APIでは、ユーザー名を返すプラグインをコールします。これによって、ユーザー名操作の実装で、デフォルト・ポリシーをカスタム・プラグインに置換できます。

注意:

- UserManagerでは、ユーザー名の生成および検証用にパブリックAPIが公開されます。

- ポリシーを作成するときは、ユーザー名の生成で使用する属性がリクエスト・データセットに定義されていることを確認してください。リクエスト・データセットについては、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリクエスト・データセットに関する項を参照してください。

次に示すように、プラグイン・インタフェースを実装して、独自のユーザー名ポリシーをプラグインできます。

package oracle.iam.identity.usermgmt.api;
public interface UsernamePolicy {
public String getUserNameFromPolicy(HashMap<String, String> reqData) throws UserNameGenerationException;

public boolean isUserNameValid(String userName, HashMap<String, String> reqData);
public String getDescription(Locale locale);
}

このプラグイン・ポイントは、リクエスト・データを入力として取得し、ユーザー名を返すカーネル・プラグインとして公開されます。各プラグインでは情報の入力が必要で、入力された情報に基づいてユーザー名が生成されます。ポリシー実装によって、ユーザー名を生成してその可用性をチェックし、ユーザー名が使用できない場合は表11-8で説明した順序でポリシーに基づいて別のユーザー名を生成し、この手順を繰り返します。生成されるユーザー名に含まれるドル記号($)はランダムなアルファベットを示します。必要な情報が欠落している場合は、ポリシーでエラーが発生します。

ユーザー・マネージャでは、ユーザー名生成がパブリックAPIとして公開されています。Oracle Identity Managerでは、ユーザー名の生成機能にアクセスするためのユーティリティ・クラスが用意されています。ユーティリティ・メソッドが含まれるクラスを次に示します。

oracle.iam.identity.usermgmt.api.UserManager

このクラスによって、次の主要メソッドが公開されます。

//Method that will generate username based on default policy
public String generateUserName(HashMap<String, String> requestData)
throws UserNameGenerationException

//Method that will generate username based on policy
public String generateUserName(String policyID, HashMap requestData)                                    throws UserNameGenerationException

//Method that will check whether username is valid against default policy
public boolean isUserNameValid(String userName,                          HashMap<String, String> reqData)

//Method that will check whether username is valid against given policy
public boolean isUserNameValid(String userName, String userNamePolicyPluginID, HashMap<String, String> requestData)

//Method to return all policies (including customer written)
public List<Map<String, String>> getAllUserNamePolicies(Locale locale)

//Method that will return policy description in given locale
public String getPolicyDescription(String policyID, Locale locale)

表11-9に、デフォルト・ユーザー名ポリシーのポリシーIDを表すためにUserManagerクラスに定義されている定数を示します。

表11-9 ポリシーIDを表す定数

ポリシー名

定数

EmailUserNamePolicy

EMAIL_ID_POLICY

LastNameFirstInitialLocalePolicy

FIRSTNAME_LASTNAME_POLICY

FirstInitialLastNameLocalePolicy

LASTNAME_FIRSTNAME_POLICY

LastNameFirstInitialPolicy

FIRSTINITIAL_LASTNAME_POLICY

FirstInitialLastNamePolicy

LASTNAME_FIRSTINITIAL_POLICY

LastNameFirstNamePolicy

FIRSTINITIAL_LASTNAME_LOCALE_POLICY

FirstNameLastNamePolicy

LASTNAME_FIRSTINITIAL_LOCALE_POLICY

DefaultComboPolicy

DEFAULT_COMBO_POLICY

LastNamePolicy

LASTNAME_POLICY

LastNameLocalePolicy

LASTNAME_LOCALE_POLICY

FirstNameLastNamePolicyForAD

FIRSTNAME_LASTNAME_POLICY_FOR_AD

LastNameFirstNamePolicyForAD

LASTNAME_FIRSTNAME_POLICY_FOR_AD

ポリシー・クラスでは、コールされてユーザー名を生成するときに、「oracle.iam.identity.utils class.Constants」で定義されたキー定数を使用して、マップに属性値が設定されている必要があります。これは、パラメータに対して定義された適切な定数(たとえば、「FirstName」パラメータに対して定義された定数)を使用して、正しいパラメータ値が渡されてメソッドがコールされる必要があることを意味します。

デフォルト・ユーザー名ポリシーは、Oracle Identity Manager管理を使用して構成できます。手順は次のとおりです。

1. 「システム構成」にナビゲートします。

2. すべてのシステム・プロパティを検索します。

3. 「ユーザー名の生成に関するデフォルト・ポリシー」をクリックします。図11-8に示すように、選択したプロパティの「システム・プロパティ詳細」ページが表示されます。

図11-8 デフォルト・ユーザー名ポリシーの構成

「図11-8 デフォルト・ユーザー名ポリシーの構成」の説明

デフォルト・ポリシー実装を取得するために、「XL.DefaultUserNameImpl」システム・プロパティが入力されています。これは、デフォルトでは、「値」フィールドに表示されているデフォルト・ユーザー名ポリシーの「oracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicy」をポイントします。

4. 「値」フィールドに、「oracle.iam.identity.usermgmt.impl.plugins.POLICY」と入力します。ここで、POLICYはいずれかのポリシー実装です。

注意:

すべてのプラグインは、/identity/metadata/plugin.xmlファイルを使用してOracle Identity Managerに登録される必要があります。サンプルのplugin.xmlファイルを次に示します。

<plugins pluginpoint="oracle.iam.identity.usermgmt.api.UserNamePolicy">        <plugin
pluginclass="oracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicy"
version="1.0" name="LastNameFirstNamePolicy"/>
</plugins>

5. 「保存」をクリックします。

11.5.3 ユーザー名の解放

ユーザー名は、次のシナリオで解放されます。

- リクエストが承認され、ユーザーがOracle Identity Managerで正常に作成されてLDAPにプロビジョニングされると、予約表からユーザー名が削除されます。予約されていたユーザー名は、承認後にユーザーが正常に作成されると削除されます。LDAPで予約されていたエントリは削除され、実際のユーザーが作成されます。

- リクエストが却下されると、LDAPおよびOracle Identity Managerで予約されていたユーザー名のエントリは削除されます。

- Oracle Identity ManagerまたはLDAPでユーザーを作成中または作成前にリクエストが失敗すると、予約されていたユーザー名は削除されます。

11.5.4 Microsoft Active Directoryサポートのためのユーザー名生成の構成

LDAPとの同期が有効化されたOracle Identity Managerデプロイメントで、Microsoft Active Directory(AD)がデータ・ストアの場合、Oracle Identity Managerの「ユーザー・ログイン」属性はLDAPの「uid」属性にマップされ、さらに、その「uid」属性は「sAMAccountName」属性にマップされます。「sAMAccountName」属性は、ADベースのすべてのアプリケーションでログインとして使用されます。ADでは、「sAMAccountName」属性に格納される値に対してサポートされている最大長に制限があります。これは、20文字を超えることはできません。

Oracle Identity Managerでは、ユーザー作成時にユーザー名を入力として受け取り、ユーザー名が20文字を超えることも可能です。ADでは20文字を超えるユーザー名がサポートされていないため、Oracle Identity Managerでは、20文字以下のユーザー名が生成されるように構成できます。

ADがデータ・ストアとして使用されている場合は、「XL.DefaultUserNamePolicyImpl」システム・プロパティの値を次のいずれかに設定して、ユーザー名の自動生成を構成できます。

- FirstNameLastNamePolicyForAD: 名の部分文字列を姓の部分文字列の接頭辞として付加することによって、ユーザー・ログインを生成します。

- LastNameFirstNamePolicyForAD: 姓の部分文字列を名の部分文字列の接頭辞として付加することによって、ユーザー・ログインを生成します。

「XL.DefaultUserNamePolicyImpl」システム・プロパティ、およびシステム・プロパティの値の設定については、システム・プロパティの管理に関する項を参照してください。

注意:

ADがデータ・ストアの場合は、「FirstNameLastNamePolicyForAD」または「LastNameFirstNamePolicyForAD」のいずれかのポリシーを使用する必要があります。その他のユーザー名生成ポリシーを使用してユーザー名を生成しようとしても失敗します。

11.6 共通名の生成

Oracle Identity Managerでの「共通名」ユーザー属性値の生成については、次の各項で説明します。

- ユーザー作成操作での共通名の生成

- ユーザー変更操作での共通名の生成

11.6.1 ユーザー作成操作での共通名の生成

Oracle Identity ManagerのLDAP対応デプロイメントでは、Human Capability Management(HCM)などのFusionアプリケーションはSPMLリクエストを介して共通名を渡しません。LDAPで共通名が必須属性で、Oracle Identity Managerが共通名をRDNとして使用するように設定されている場合、Oracle Identity Managerでは一意の共通名を生成する必要があります。

共通名の説明に基づいて、名と姓で構成されるユーザーの表示名が共通名になります。この場合、Oracle Identity Managerでは、「firstname lastname」形式で共通名を指定する共通名生成ポリシーを使用して、共通名が生成されます。

Oracle Identity Managerに共通名の生成を構成するには、次の値を設定します: XL.DefaultCommonNamePolicyImplシステム・プロパティをoracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyにします。次に関する情報の参照先: XL.DefaultCommonNamePolicyImpl」システム・プロパティおよびシステム・プロパティの値の設定については、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

「FirstNameLastNamePolicy」の詳細は次のとおりです。

- 必要な情報: 名、姓

- 生成される共通名: firstname.lastname、firstname.$.lastname(すべてのアルファベットからランダムな1文字)、firstname.$$.lastnameなど、共通名が一意になるように生成されます。

注意:

リクエストによってユーザーが作成されるまで共通名は予約されるため、同じ名と姓を使用した複数のリクエストが同時に生成された場合でも、同じ共通名は生成されません。

11.6.2 ユーザー変更操作での共通名の生成

ユーザー・プロファイルが変更されると、1つ以上の属性が変更される可能性があります。HCMでは、変更前のユーザー属性を保持しておらず、どの属性が変更されたかを判断できないため、変更されたデータのみをフィルタ処理してOracle Identity Managerに送信できません。このため、共通名(CN)を含むすべての属性がSPMLリクエストを介してOracle Identity Managerに渡されます。CNが変更されると、Oracle Identity Managerではディレクトリ内で変更操作(modrdn)が実行されるため、DNが変更される結果になります。この意図しないDN変更によって、グループ・メンバーシップのDNが失効し、ユーザーはそのグループのメンバーシップを失います。この結果、認可が失敗します。これは、LDAPサーバーで参照整合性がオフの場合に発生し、ユーザーのRDNが変更されたときに参照先グループが更新されません。したがって、ターゲットLDAPサーバーで参照整合性をオンにする必要があります。そうしないと、グループ・メンバーシップが失効します。参照整合性の問題はロールにも該当します。グループが他のグループのメンバーでもある場合、RDNの変更は同様に影響を与えます。

参照整合性をオンにするには、「XL.IsReferentialIntegrityEnabled」システム・プロパティの値を「TRUE」に設定します。このシステム・プロパティについては、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

表11-10に、RDNが変更される場合のシナリオを示します。

表11-10 RDN変更のシナリオ

LDAPでの参照整合性

XL.IsReferentialIntegrityEnabled

変更操作(modrdn)の結果

無効

FALSE

Oracle Identity Managerでエラーが発生し、操作は失敗します。

無効

TRUE

Oracle Identity Managerからの変更操作が正常に実行され、LDAPでRDNが変更されます。ただし、グループ参照は更新されずに失効します。この構成はお薦めしません。

有効

FALSE

Oracle Identity Managerでエラーが発生し、変更操作は失敗します。LDAPで参照整合性が有効であるため、Oracle Identity Managerでこのプロパティを「TRUE」に設定する必要があります。

有効

TRUE

変更操作が正常に実行され、RDNが更新されます。さらに、LDAPでDNの参照が更新されます。

各ディレクトリにロールおよびユーザーが格納された複数のディレクトリ。

ここでは参照整合性プロパティは関係ありません。

FALSE

Oracle Identity Managerからの変更操作が失敗します。これはLDAPでサポートされていません。このため、Oracle Identity Managerでは、このプロパティの値を「FALSE」に設定することをお薦めします。

各ディレクトリにロールおよびユーザーが格納された複数のディレクトリ。

ここでは参照整合性プロパティは関係ありません。

TRUE

変更操作が正常に実行され、RDNが変更されます。ただし、LDAPでは複数のディレクトリでの参照整合性をサポートしていないため、グループ参照は失効し、手動で更新する必要があります。

12 ロールの管理

管理者はロールを使用して、アクセス権、ロール、権限などの共通機能にアクセスできるユーザーの集合のレコードを作成および管理します。

ロールは、組織に依存しないロール、複数の組織にわたるロール、または1つの組織のユーザーのみが含まれたロールのいずれかです。

ロールを使用すると、次の操作が可能です。

- ユーザーがOracle Identity Manager管理のWebインタフェースを使用してアクセスできるメニュー項目を表示します。

- ロールにユーザーを割り当てます。

- 親ロールにロールを割り当てます。

- プロセス・タスクに対して定義済レスポンスを指定できるようにするためのステータスをユーザーに指定します。

- データ・オブジェクトの権限を変更します。

- ロールのプロビジョニング・ポリシーを指定します。これらのポリシーは、ロールのメンバーに対して、あるリソース・オブジェクトをプロビジョニングするか、リクエストによりプロビジョニングするかを決定します。

- ロールに対して、メンバーシップ・ルールを追加または削除します。これらのルールは、ロールに対して、どのユーザーを直接メンバーシップとして割り当てたり削除できるかを決定します。

- ロールを介してユーザーをアクセス・ポリシーにマップして、ユーザーへのターゲット・システムのプロビジョニングを自動化します。詳細は、第16章「アクセス・ポリシーの管理」を参照してください。

この章では、ロールおよびロールに関連する機能について次の各項で説明します。

- ロール・メンバーシップの継承

- ロール権限の継承

- ロール・エンティティ定義

- デフォルト・ロール

- ロール管理タスク

- ロールに対する認可の管理

- リクエスト・ベースのロールの付与

12.1 ロール・メンバーシップの継承

メンバーシップの継承とは、継承元ロールから継承先ロールにメンバーを継承することを意味します。次に例を示します。

注意:

親ロールからメンバーシップを継承する子ロールを継承先ロールと呼びます。継承先ロールがメンバーシップを継承する親ロールを継承元ロールと呼びます。

- ロールBはロールAからメンバーシップを継承します。ロールBはロールAの親ロールです。

- ロールCもロールAからメンバーシップを継承します。ロールCもロールAの親ロールです。

この例の場合、ロールAの全メンバーはロールBおよびロールCの暗黙的、つまり間接的なメンバーでもありますが、ロールBのメンバーはロールAのメンバーに自動的にはなりません。つまり、ロールBおよびロールCはロールAの親です。同様に、ロールAはロールBおよびロールCの子です。実際の例では、従業員ロール(ロールB)はマネージャ・ロール(ロールA)からメンバーシップを継承します。

ロール・メンバーシップの継承について、次のシナリオを使用して説明します。

- CEOロールは、マネージャ・ロールの親ロールです。

- マネージャ・ロールは従業員ロールの親ロールです。

- ソフトウェア・アーキテクト・ロールはソフトウェア・エンジニア・ロールの親ロールです。

- ソフトウェア・エンジニア・ロールは従業員ロールの親ロールです。

- 従業員ロールには、マネージャ・ロールとソフトウェア・エンジニア・ロールの2つの親ロールがあります。

図12-1に、この例に示す親ロールと子ロール、およびメンバーシップの継承を示します。

図12-1 ロール・メンバーシップおよびロール権限の継承

「図12-1 ロール・メンバーシップおよびロール権限の継承」の説明

親ロールの各ユーザーは、そのすべての子ロールのメンバーに自動的になります。ユーザーは、その子ロール自体を親にして、さらに子ロールを追加できます。このように、必要な子ロールを追加していきます。たとえば、CEOはマネージャであり、マネージャ・ロールのメンバーに自動的になります。同様に、マネージャは自動的に従業員になります。このように、親ロールに追加されたメンバーは、その子ロールを継承します。したがって、従業員ロールの直接メンバーシップは存在せず、メンバーシップの継承関係から考えると、従業員ロールは他のすべてのロールよりメンバーが多くなります。

12.2 ロール権限の継承

権限の継承とは、継承元ロールから継承先ロールに権限を継承することを意味します。次に例を示します。

- ロールBはロールAから権限を継承します。

- ロールCもロールAから権限を継承します。

この例では、ロールBおよびロールCはロールAの子です。同様に、ロールAはロールBおよびロールCの親です。

実際の例では、マネージャ・ロールは従業員ロールから権限を継承します。

管理およびユーザー・コンソールでは、「階層」タブの次の各セクションにロール権限の継承が表示されます。

関連項目:

「階層」タブの詳細は、「「階層」タブ」を参照してください。

- 継承元: 開いているロールが継承される親ロールが表示されます。基本ロールが持つメンバーに対する権限および特権は、継承されたロールと同じです。基本ロールからは継承されたロールのみを追加または削除できますが、継承されたロールからは基本ロールを追加または削除することはできません。

- 継承先: 開いているロールから継承された子ロールがリストされます。ここには、ロールが読取り専用で表示されます。「ロールを開く」アクションを使用して、基本ロールからの関係を変更できます。

たとえば、role1、role2およびrole3の3つのロールを作成するとします。role3を開き、role2を親ロールとして割り当てます。同様に、role2を開き、role1を親ロールとして割り当てます。role3を開くと、「継承元」セクションにはrole2親ロールが表示され、role1がrole2の下に表示されます。role1を開くと、「継承先」セクションにはrole2子ロールが表示され、role3がrole2の下に表示されます。

ユーザーは、次のいずれかの方法でロールのメンバーになることができます。

- 親ロールからメンバーが継承されます(間接メンバーシップと呼ばれます)。

- ユーザーがロールに直接割り当てられます(直接メンバーシップと呼ばれます)。

- 「ロールの詳細」ページで「XL.RM_REQUEST_ENABLED」および「XL.RM_ROLE_ASSIGN_TEMPLATE」システム・プロパティを設定し、リクエストを使用してユーザーを直接割り当てます(これも直接メンバーシップと呼ばれます)。システム・プロパティについては、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

間接メンバーを直接メンバーとして割り当てることができます。ユーザーの直接メンバーシップが削除されても、継承によってユーザーは依然としてロールのメンバーであるため、そのロールのすべてのメンバーシップは変更ありません。

図12-1に示すように、従業員の権限はマネージャの権限に含まれます。同様に、マネージャの権限はCEOの権限に含まれます。このように、権限は上位の方向に継承されます。さらに、親ロールは複数の子ロールから権限を継承します。たとえば、CEOはマネージャ・ロールとソフトウェア・アーキテクト・ロールの権限を継承します。したがって、メンバーシップの継承と権限の継承は反対の方向に進められます。

12.3 ロール・エンティティ定義

Oracle Identity Managerでは、ロール・エンティティに対して属性が定義されます。これらの属性は、すべてのエンティティ(ユーザー、組織、ロール、ロール階層、ロール・メンバーシップなど)で同じです。エンティティに対して定義される属性のリストは、「ユーザー・エンティティ定義」を参照してください。

注意:

ロール・エンティティには独自の属性を追加できません。

この項では、次のエンティティのデフォルト属性定義について説明します。

- ロール・エンティティ

- ロール・カテゴリ・エンティティ

- ロール付与関係

- ロール親関係

12.3.1 ロール・エンティティ

Role.xmlファイルには、ロール・エンティティの属性定義が格納されています。ロール・エンティティには独自の属性を追加できます。

表12-1に、ロール・エンティティのデフォルト属性を示します。

表12-1 ロール・エンティティのデフォルト属性

属性名

カテゴリ

タイプ

データ型

プロパティ

LOV

キー

基本

単一

数値

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール一意名

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: いいえ

バルク更新可能: いいえ

該当なし

ロール表示名

基本

単一

テキスト(多言語)

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール・ネームスペース

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール名

基本

単一

テキスト(多言語)

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロールの説明

基本

単一

テキスト(多言語)

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

LDAP GUID

LDAP

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

LDAP DN

LDAP

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール・カテゴリ・キー

基本

単一

ロール・カテゴリへの参照

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

該当なし

ロール所有者キー

基本

単一

ロール所有者への参照

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: はい

該当なし

ロールの電子メール

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

12.3.2 ロール・カテゴリ・エンティティ

RoleCategory.xmlファイルには、ロール・カテゴリ・エンティティの属性定義が格納されています。ロール・カテゴリ・エンティティには独自の属性を追加できません。

表12-2に、ロール・カテゴリ・エンティティのデフォルト属性を示します。

表12-2 ロール・カテゴリ・エンティティのデフォルト属性

属性名

カテゴリ

タイプ

データ型

プロパティ

LOV

ロール・カテゴリ・キー

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール・カテゴリ名

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

ロール・カテゴリの説明

基本

単一

テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

12.3.3 ロール付与関係

RoleRoleRelationship.xmlファイルには、ロール付与関係の属性定義が格納されています。ロール付与関係には独自の属性を追加できません。

表12-3に、ロール付与関係のデフォルト属性を示します。

表12-3 ロール付与関係のデフォルト属性

属性名

カテゴリ

タイプ

データ型

プロパティ

LOV

UGP_KEY

基本

単一

ロールへの参照

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

USR_KEY

基本

単一

ユーザーへの参照

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

12.3.4 ロール親関係

RoleUserMembership.xmlファイルには、ロール親関係の属性定義が格納されています。ロール親関係には独自の属性を追加できません。

表12-4に、ロール親関係のデフォルト属性を示します。

表12-4 ロール親関係のデフォルト属性

属性名

カテゴリ

タイプ

データ型

プロパティ

LOV

UGP_KEY

基本

単一

ロールへの参照

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

GPG_UGP_KEY

基本

単一

ロールへの参照

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

バルク更新可能: いいえ

該当なし

注意:

UGP_KEYは親ロールへの参照です。GPG_UGP_KEYは子ロールへの参照です。

12.4 デフォルト・ロール

表12-5に、Oracle Identity Managerのデフォルト・ロールを示します。

表12-5 Oracle Identity Managerのデフォルト・ロール

ロール

説明

ユーザー構成管理者

このロールのメンバーは、ユーザー管理のエンティティ属性を作成および管理するための各種タスクを実行できるUIにアクセスできます。

システム構成管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、システム構成に関連する各種タスク(システム・プロパティ、スケジュール済ジョブ、通知テンプレートなど)を実行できるUIにアクセスできます。

システム管理者

このロールのメンバーは、Oracle Identity Managerでレコード(システム・レコード以外)を作成、編集および削除できる完全な権限を持っています。このグループのユーザーは、他のユーザーの権限を制御したり、割り当てられないタスクについてもプロセス・タスクのステータスを変更して、最も高いレベルからシステムを管理できます。

ユーザー名管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。

SPML_App_Role

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、SPMLインタフェースを介してリクエストを送信するためのアクセス権があります。

SOD管理者

このロールのメンバーは、SoDチェック・タスクを要求して承認できます。デフォルトの承認タスクがこのロールに割り当てられます。

セルフ・オペレータ

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。これにはXELSELFREGという1人のユーザーが含まれ、Oracle Identity Manager内で他のユーザーが自己登録アクションを実行するときに必要な権限の変更を担当します。

注意: Oracle Identity Managerでは、セルフ・オペレータ・ユーザー・ロールに関連付けられている権限を変更しないことをお薦めします。さらに、他のユーザーをこのロールに割り当てることはできません。

スケジューラ管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールを持つユーザーは、すべてのスケジューラ・ジョブ管理を実行できます。

ロール管理者

このロールのメンバーは、Oracle Identity Managerでロールを管理できるUIにアクセスできます。

リソース管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、リソースを管理するための各種タスクを実行できるUIにアクセスできます。

リクエスト・テンプレート管理者

このロールを持つユーザーは、すべてのリクエスト・テンプレート管理を実行できます。

リクエスト管理者

このロールのメンバーは、リソースを作成および管理するための各種タスクを実行できるUIにアクセスできます。

レポート管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、BI Publisherでレポートを管理するための各種タスクを実行できるUIにアクセスできます。

リコンシリエーション管理者

このロールを持つユーザーは、リコンシリエーション管理を実行できます。

プラグイン管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、Oracle Identity Managerに対してプラグインを登録および登録解除する権限を持ちます。

オペレータ

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、組織、ユーザーおよびタスク・リストに関連するページにアクセスできます。このロールのユーザーは、これらのページの一部の機能を実行できます。

通知テンプレート管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、通知テンプレートを作成および管理するための各種タスクを実行できるUIにアクセスできます。

ITリソース管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、ITリソースを作成および管理するための各種タスクを実行できるUIにアクセスできます。

アイデンティティ・ユーザー管理者

このロールのメンバーは、Oracle Identity Managerでユーザーを作成および管理するための各種タスクを実行できるUIにアクセスできます。

アイデンティティ組織管理者

このロールのメンバーは、Oracle Identity Managerで組織を作成および管理するための各種タスクを実行できるUIにアクセスできます。

汎用コネクタ管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、汎用コネクタを構成するための各種タスクを実行できるUIにアクセスできます。

デプロイメント・マネージャ管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、Oracle Identity Managerデプロイメント間でデプロイメント構成をインポートおよびエクスポートできるデプロイメント・マネージャにアクセスできます。

管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。これは、SOA用の管理者ロールです。

アテステーション・イベント管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、アテステーション・イベントを管理するための各種タスクを実行できるUIにアクセスできます。

アテステーション構成管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、アテステーションを構成するための各種タスクを実行できるUIにアクセスできます。

承認ポリシー管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、承認ポリシーを作成および管理するための各種タスクを実行できるUIにアクセスできます。

すべてのユーザー

このロールのメンバーは権限が最小ですが、自身のユーザー・レコードにアクセスできるなどの機能があります。デフォルトでは、各ユーザーはすべてのユーザー・ロールに所属します。

アクセス・ポリシー管理者

これは内部使用のみのロールで、OIMユーザー用に使用され、他のユーザーはUIでのみ表示できます。このロールのメンバーは、アクセス・ポリシーを管理するための各種タスクを実行できるUIにアクセスできます。

デフォルト・ロールに関連付けられた権限は変更できます。追加のロールを作成することもできます。ただし、すべてのロールに対して、メニュー項目を割り当てたり削除することはできません。

12.5 ロール管理タスク

このセクションのトピックは次のとおりです:

- ロールの作成

- ロールの管理

- ロール・カテゴリの作成と管理

注意:

- すべてのユーザー・ロールからユーザーを削除することはできません。

- セルフ・オペレータ・ロールは、デフォルトでOracle Identity Managerに追加されます。このロールにはXELSELFREGという1人のユーザーが含まれ、管理コンソールで自己登録を実行するためのユーザー権限の変更を担当します。
セルフ・オペレータ・ロールに関連付けられている権限を変更しないこと、およびこのロールにユーザーを割り当てないことをお薦めします。

12.5.1 ロールの作成

新規のロールを初めて作成する場合は、「ロールの詳細」ページにロール名が表示されます。「ロールの管理」の説明に従い、「追加詳細」メニューを使用してロールに情報を追加できます。

ロールを作成するには、次のようにします。

1. Oracle Identity Administrationにログインします。

2. 「ようこそ」ページで、「ロール」の下にある「新規ロールの作成」をクリックします。
または、左ペインの「参照」タブで「ロール」を展開し、「アクション」メニューから「ロールの作成」を選択します。あるいは、ツールバーにある「ロールの作成」アイコンをクリックします。

ロールの作成ページが表示されます。

3. フィールドに値を入力します。表12-6に、「ロールの作成」ページのフィールドを示します。

表12-6 「ロールの作成」ページのフィールド

フィールド

説明

ロール名

ロールの名前

表示名

UIに表示されるロール名

電子メール

ロールの電子メールID

説明

ロールの説明

ロール・カテゴリ

ロールが属しているカテゴリ

このフィールドにロール・カテゴリが指定されていない場合、ロールは「デフォルト」カテゴリに作成されます。ロール・カテゴリについては、「ロール・カテゴリの作成と管理」を参照してください。

所有者

ロールの所有者

ロールの所有者とは、カスタム認可ポリシーを作成せずに、ロールを表示、変更および削除できる権限を持つユーザーです。ロール管理の認可ポリシーについては、「ロールに対する認可の管理」を参照してください。

「ローカライゼーションの管理」には、多言語フィールドとして複数の「表示名」フィールドが表示されることに注意してください。これは、属性値を複数の言語で入力して保存できることを意味します。

4. 「保存」をクリックします。ロールが正常に作成され、ロール名、ロール・ネームスペース、LDAP属性(LDAP GUID、LDAP DNなど)が新しいページに表示されます。

12.5.2 ロールの管理

ロールの検索、ロールへの情報の追加、およびロールに対するその他の管理機能を実行できます。

このセクションのトピックは次のとおりです:

- ロールの参照

- ロールの検索

- ロールの削除

- ロールの表示と管理

- メニュー項目の表示

- アクセス・ポリシーの表示、割当ておよび失効

- メンバーシップ・ルールの表示、割当ておよび失効

- データ・オブジェクト権限の更新

12.5.2.1 ロールの参照

Oracle Identity Managerに存在するロールは、「ロール」タブで参照できます。ロールを参照する手順は、次のとおりです。

1. Oracle Identity Administrationの左ペインで、「参照」タブをクリックします。

2. 「OIMロール」を展開します。ロール・カテゴリが表示されます。ロール・カテゴリの詳細は、「ロール・カテゴリの作成と管理」を参照してください。

「参照」タブで、ロールおよびロール・カテゴリに関連する各種タスクを実行できます。詳細は、「ロールの表示と管理」を参照してください。

12.5.2.2 ロールの検索

Oracle Identity Management管理を使用して、ロールに対して次のタイプの検索操作を実行できます。

- ロールの単純検索の実行

- ロールの拡張検索の実行

12.5.2.2.1 ロールの単純検索の実行

ロールの単純検索を実行する手順は、次のとおりです。

1. Oracle Identity Administrationの左ペインで、「検索」の下にある「ロール」を選択します。

2. リストの横にあるフィールドに検索基準を指定します。検索基準にはワイルドカード文字(*)を使用できます。パフォーマンス上の理由から、先頭(接頭辞)のワイルドカードは削除されます。ただし、末尾(接頭辞)のワイルドカードはすべての検索に追加されます。

注意:

Oracle Identity Management管理で許容されているワイルドカード検索文字は「*」のみです。

3. フィールドの右側にある「検索」アイコンをクリックします。検索基準に一致するロールのリストが「検索結果」タブに表示されます。
「検索結果」タブで、ロールを編集したり削除できます。詳細は、「ロールの表示と管理」および「ロールの削除」を参照してください。

12.5.2.2.2 ロールの拡張検索の実行

ロールの拡張検索を実行する手順は、次のとおりです。

1. 「ようこそ」ページで、「ロール」の下にある「拡張検索 - ロール」をクリックします。
または、左ペインのロールの「参照」タブで、ツールバーにある「拡張検索: ロール」アイコンをクリックします。

「拡張検索: ロール」ページが表示されます。

2. 次のオプションのいずれかを選択します。

- すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。

- いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。

3. 「名前」フィールドに、検索するロール名を入力します。検索基準にはワイルドカード文字を使用できます。「名前」フィールドの横にあるリストから検索コンパレータを選択します。デフォルトの検索コンパレータは「次で始まる」です。かわりに、プルダウン・リストからコンパレータ「次と等しい」を選択することもできます。

4. 同様に、その他のすべてのフィールドに検索基準を入力します。「拡張検索: ロール」ページにフィールドを追加できます。これを行うには、「フィールドの追加」をクリックし、リストからフィールド名を選択します。

5. 「検索」をクリックします。検索基準に一致するロールが検索結果表に表示されます。

注意:

値を指定せずに「検索」をクリックすると、すべてのロールが返されます。

6. 検索結果に追加の列を表示するには、「表示」をクリックして「列」を選択します。

7. 検索結果の列を並べ替えるには、「表示」をクリックし、列の並替えをクリックします。

「拡張検索: ロール」ページの検索結果から、新規ロールの作成、ロールの編集、およびロールの削除を実行できます。詳細は、「ロールの作成」、「ロールの表示と管理」および「ロールの削除」を参照してください。

12.5.2.3 ロールの削除

ロールを削除するには、次の手順を実行します。

1. 「ロールの検索」の説明に従ってロールを検索します。または、左ペインにあるロールの「参照」タブをクリックします。

2. 削除するロールを選択します。

3. 「アクション」リストから「削除」を選択します。
または、ツールバーにある削除アイコンをクリックします。確認を求めるメッセージ・ボックスが表示されます。

4. 「OK」をクリックして処理を確認します。

注意:

他のロールの親または子であるロールは削除できません。このようなロールを削除するには、最初に、関連付けられている親子ロール関係を削除する必要があります。ロールがすべてのロール関係に含まれなくなると、そのロールを削除できます。

12.5.2.4 ロールの表示と管理

ロールの詳細を開き、ロールの属性を編集したり、ロールの継承やメンバーシップを変更できます。ロールの詳細を開いて変更するには、次のいずれかを実行します。

- ロールの参照ツリーで、開くロールを選択します。「アクション」メニューから「開く」を選択します。または、ツールバーにある「ロールまたはカテゴリの詳細を開く」アイコンをクリックします。

- 左ペインの「検索結果」タブで、開くロールを選択します。「アクション」メニューから「開く」を選択します。または、ツールバーにある「ロールの詳細を開く」アイコンをクリックします。

- 「拡張検索: ロール」ページで、開くロールを選択します。「アクション」メニューから「開く」を選択します。または、ツールバーにある「ロールを開く」をクリックします。

ページにロールの詳細が表示されます。ページの上部にロールの表示名が表示されます。このページの次のタブで、ロールの詳細を表示し、ロール情報を変更できます。

- 「属性」タブ

- 「階層」タブ

- 「メンバー」タブ

12.5.2.4.1 「属性」タブ

「属性」タブでは、次のセクションにロールの属性が表示されます。

- 基本ロール情報: このセクションには、ロール名、ロール・ネームスペース、表示名、電子メール、説明などのロールの基本属性が表示されます。

- その他の情報: このセクションには、ロールが属しているカテゴリおよびロールの所有者に関する情報が表示されます。

- カスタム属性: このセクションには、ユーザー定義フィールド(UDF)に関する情報が表示されます。

- LDAP属性: このセクションには、LDAP GUIDおよびLDAP DNに関する情報が表示されます(Oracle Identity ManagerがLDAPと統合されている場合)。これらの属性は読取り専用です。

「属性」タブのフィールドは、「ロールの作成」ページで使用可能なフィールドと同じです。「属性」タブのすべてのフィールドについては、「表12-6 「ロールの作成」ページのフィールド」を参照してください。

12.5.2.4.2 「階層」タブ

「階層」タブでは、次のセクションにロール階層情報が表示されます。

- 継承元: このセクションには、開いているロールが継承される親ロールが表示されます。基本ロールが持つメンバーに対する権限および特権は、継承されたロールと同じです。基本ロールからは継承されたロールのみを追加または削除できますが、継承されたロールからは基本ロールを追加または削除することはできません。

- 継承先: このセクションには、開いているロールから継承された子ロールがリストされます。ここには、ロールが読取り専用で表示されます。「ロールを開く」アクションを使用して、基本ロールからの関係を変更できます。

「階層」タブでは、次の操作を実行できます。

- 子ロールへの親ロールの追加

- ロールからの親ロールの削除

- 親/子ロールを開く

12.5.2.4.3 子ロールへの親ロールの追加

子ロールに親ロールを追加する手順は、次のとおりです。

1. ロールを開きます。

2. 「階層」タブをクリックします。

3. 「継承元」セクションがアクティブであることを確認します。

4. 「アクション」メニューから「親ロールの追加」を選択します。または、ツールバーにある「親ロールの追加」をクリックします。「継承されたロールの追加先」ダイアログ・ボックスが表示されます。

5. 「ロールの検索」リストから、検索するロールのロール・カテゴリを選択します。

6. 検索フィールドに検索基準を指定します。検索基準にはワイルドカード文字(*)を使用できます。次に、「検索」アイコンをクリックします。検索基準に一致するロールのリスト、および選択したロール・カテゴリが「使用可能なロール」リストに表示されます。

注意:

Oracle Identity Management管理で許容されているワイルドカード検索文字は「*」のみです。

7. 「使用可能なロール」リストから、親ロールとして追加するロールを1つ以上選択します。次に、「移動」または「すべて移動」をクリックして、選択したロールを「追加するロール」リストに移動します。

8. 「保存」をクリックします。開いているロールに選択したロールが親ロールとして追加され、ロール階層が「階層」タブの「継承元」セクションに表示されます。

9. 追加された継承元ロールを選択します。選択したロールのサマリー情報が表の下に表示されます。

12.5.2.4.4 ロールからの親ロールの削除

ロールから親ロールを削除する手順は、次のとおりです。

1. 「階層」タブの「継承元」セクションで、削除するロールを選択します。

2. 「アクション」メニューから「親ロールの削除」を選択します。または、ツールバーにある「親ロールの削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

3. 「OK」をクリックします。「階層」タブの「継承元」セクションから、継承元ロールが削除されます。

12.5.2.4.5 親/子ロールを開く

「階層」タブの「継承元」セクションから親ロールを、「継承先」セクションから子ロールを開くことができます。

また、現在開いているロールの親ロールおよび子ロールにリンクしているロール(祖父母ロールおよび孫ロールと同様)も、それぞれ「階層」タブの「継承元」セクションおよび「継承先」セクションにある「ロールを開く」リンクを使用して開くことができます。

親ロールを開く手順は、次のとおりです。

1. 「階層」タブの「継承元」セクションで、開くロールを選択します。

2. 「アクション」メニューから「開く」(「ロールの詳細を開く」)を選択します。または、ツールバーにある「開く」(「ロールの詳細を開く」)をクリックします。ページに継承元ロールに関する詳細が表示されます。このページで、ロールの属性の表示と編集、ロールの継承とメンバーシップの変更、メンバーシップ・ルール、アクセス・ポリシーおよび権限の割当てと削除、権限の更新、割り当てられたメニュー項目の表示を行うことができます。

子ロールを開く手順は、次のとおりです。

1. 「階層」タブの「継承元」または「継承先」セクションで、開くロールを選択します。

2. 「アクション」メニューから「開く」(「ロールの詳細を開く」)を選択します。または、ツールバーにある「開く」(「ロールの詳細を開く」)をクリックします。ページに継承元ロールに関する詳細が表示されます。

12.5.2.4.6 「メンバー」タブ

「メンバー」タブには、開いているロールに割り当てられたメンバーが表示されます。この情報は、次の各セクションに表示されます。

- すべてのメンバー: このセクションには、開いているロールに割り当てられたすべてのメンバー(直接メンバーおよび間接メンバー)が表示されます。

- 直接メンバー: このセクションには、開いているロールに直接割り当てられたメンバーが表示されます。また、メンバーシップ・ルールを介して割り当てられたすべてのメンバーも表示されます。

- 間接メンバー: このセクションには、ロールによって間接的に継承されたメンバーが表示されます。

「メンバー」タブでは、次の操作を実行できます。

- ロールへのメンバーの割当て

- ロールからのメンバーの失効

- メンバーの詳細を開く

12.5.2.4.7 ロールへのメンバーの割当て

ロールにメンバーを割り当てる手順は、次のとおりです。

1. 「メンバー」タブのいずれかのセクションで、「アクション」メニューから「割当て」(「ユーザーの割当て」)を選択します。または、ツールバーにある「ユーザーの割当て先」をクリックします。「ユーザーの割当て先」ダイアログ・ボックスが表示されます。

2. 「ユーザーの検索」フィールドに検索基準を指定し、「検索」アイコンをクリックして、ユーザーを検索します。検索基準に一致するユーザーのリストが「使用可能」リストに表示されます。

注意:

間接メンバーを直接メンバーとして割り当てることができます。

3. 開いているロールに割り当てるユーザーを1人以上選択します。次に、「移動」または「すべて移動」をクリックして、選択したユーザーを「選択済」リストに移動します。

4. 「保存」をクリックします。「XL.RM_REQUEST_ENABLED」および「XL.RM_ROLE_ASSIGN_TEMPLATE」システム・プロパティが設定されている場合は、「保存」をクリックした後に、確認メッセージとリクエストIDが「ロールの詳細」ページに表示されます。そうでない場合は、確認メッセージのみが表示されます。
リクエストが作成されている場合は、そのリクエストが承認された後にのみ、ユーザーがメンバーとして「直接メンバー」セクションに表示されます。そうでない場合、ユーザーはメンバーとして「直接メンバー」セクションに即時に表示されます。また、ユーザーが「すべてのメンバー」セクションにも表示されることに注意してください。

ヒント:

- メンバー・ユーザーを追加した後、そのメンバー・ユーザーが「メンバー」タブに即時に表示されない場合は、表示をリフレッシュしてください。

- メンバーシップ・ルールの基準に一致するようにユーザーを作成または更新した場合、そのユーザーはこのロールに直接割り当てられ、メンバーが「すべてのメンバー」および「直接メンバー」セクションの両方に表示されるように表をリフレッシュする必要があります。

12.5.2.4.8 ロールからのメンバーの失効

ロールからメンバーを失効する手順は、次のとおりです。

1. 「メンバー」タブのいずれかのセクションで、失効するメンバーを選択します。

2. 「アクション」メニューから「失効」(「メンバーの失効」)を選択します。または、ツールバーにある「メンバーの失効元」をクリックします。「ユーザーの失効元」ダイアログ・ボックスが表示されます。

3. 「ユーザーの検索」フィールドに検索基準を指定し、「検索」アイコンをクリックして、メンバーを検索します。検索基準に一致するメンバーのリストが「使用可能」リストに表示されます。

注意:

失効できるのは、メンバーシップ・ルールを介して割り当てられたメンバーを除く直接メンバーのみです。

4. 開いているロールから失効するメンバーを1人以上選択します。次に、「移動」または「すべて移動」をクリックして、選択したメンバーを「選択済」リストに移動します。

5. 「保存」をクリックします。「ロールの詳細」ページに確認メッセージが表示されます。

6. 失効したメンバーは、「メンバー」タブのメンバー・リストから削除されます。

12.5.2.4.9 メンバーの詳細を開く

開いているロールのメンバー・ユーザーの詳細を開く手順は、次のとおりです。

1. 「メンバー」タブのいずれかのセクションで、詳細を開くメンバーを選択します。

2. 「アクション」メニューから「開く」(「メンバーの詳細を開く」)を選択します。または、ツールバーにある「ユーザーを開く」をクリックします。メンバーの「ユーザーの詳細」ページが表示され、メンバーの詳細を表示および変更できます。

12.5.2.5 メニュー項目の表示

ロールに許可されているすべてのメニュー項目を表示できます。11g リリース1 (11.1.1)では、新しいメニュー項目を任意のロールに割り当てることはできません。Oracle Identity Managerでは、デフォルトで、メニュー項目はいくつかのデフォルト・ロールにすでに割り当てられています。

注意:

既存のメニュー項目は失効できません。

ロールに対するメニュー項目を表示する手順は、次のとおりです。

1. 左ペインにあるロールの参照ツリーで、許可されているメニュー項目を表示するロールを選択します。

2. 「アクション」メニューから「メニュー項目」を選択します。「ロールの詳細 >> メニュー項目」ページに、選択したロールに許可されているメニュー項目のリストが表示されます。

12.5.2.6 アクセス・ポリシーの表示、割当ておよび失効

このロールで使用できるすべてのアクセス・ポリシーを表示したり、ロールに対してアクセス・ポリシーを割り当てたり失効することができます。

ロールにアクセス・ポリシーを割り当てる手順は、次のとおりです。

1. 左ペインにあるロールの参照ツリーで、アクセス・ポリシーを割り当てるロールを選択します。

2. 「アクション」メニューまたは「ロールの詳細」ページから「アクセス・ポリシー」を選択します。「アクセス・ポリシー」ページが表示されます。

3. 新しいアクセス・ポリシーを割り当てるには、「ポリシーの割当て」をクリックします。「アクセス・ポリシーの割当て」ページが表示されます。
このページには、ポリシー名とポリシーの簡単な説明が表示されます。

4. このロールに割り当てるアクセス・ポリシーの「割当て」オプションを選択し、「割当て」をクリックします。「確認」ページが表示されます。

5. アクセス・ポリシーを割り当てるには、「割当ての確認」をクリックします。「アクセス・ポリシー」ページが表示されます。

6. このアクセス・ポリシーを削除するには、このロールから削除するアクセス・ポリシーの「削除」オプションを選択し、「削除」をクリックします。確認ページで「削除の確認」をクリックすると、このロールからアクセス・ポリシーが削除されます。

12.5.2.7 メンバーシップ・ルールの表示、割当ておよび失効

このロールで使用できるすべてのメンバーシップ・ルールの表示、ロールに対する新しいメンバーシップ・ルールの割当て、およびメンバーシップ・ルールの削除を行うことができます。

メンバーシップ・ルールに関連する操作を行うには、次の手順を実行します。

1. ロールの参照ツリーで、メンバーシップ・ルールを割り当てるか、または失効するロールを選択します。

2. 「アクション」メニューから「メンバーシップ・ルール」を選択します。「メンバーシップ・ルール」ページが表示されます。

3. 新しいメンバーシップ・ルールを割り当てるには、「ルールの割当て」をクリックします。「メンバーシップ・ルールの割当て」ページが表示されます。このページには、メンバーシップ・ルールの名前が表示されます。

4. このロールに割り当てるメンバーシップ・ルールの「割当て」オプションを選択し、「割当て」をクリックします。「確認」ページが表示されます。

5. メンバーシップ・ルールを割り当てるには、「割当ての確認」をクリックします。これを行わない場合は、「取消」をクリックします。「メンバーシップ・ルール」ページが表示されます。

6. このメンバーシップ・ルールを失効するには、このロールから削除するメンバーシップ・ルールの「削除」オプションを選択し、「削除」をクリックします。確認ページで「削除の確認」をクリックすると、このロールからルールが削除されます。

12.5.2.8 データ・オブジェクト権限の更新

Oracle Identity Managerにおける権限は、そのほとんどがデータ・オブジェクトに関するものです。データ・オブジェクトは、Oracle Identity Managerデータ・モデルにおける表の内部オブジェクト表現として定義できます。このモデルではビジネス・ロジックが実行され、データ・ストアにおけるデータの挿入、更新、および削除が行われます。これらのアクションに対する権限は、ロール・レベルで定義されます。表またはデータ・オブジェクトに応じて、これらの権限は次のように分類できます。

- 明示的な挿入/更新/削除権限が必要なデータ・オブジェクト

- 明示的な権限が不要なデータ・オブジェクト

12.5.2.8.1 明示的な挿入/更新/削除権限が必要なデータ・オブジェクト

明示的な挿入、更新または削除権限が必要とされるデータ・オブジェクトとは、そのエンティティを作成、変更および削除するためにOracle Identity Manager管理およびユーザー・コンソールの「ロールの詳細」ページの「権限」を使用して挿入、更新または削除権限を指定する必要があるデータ・オブジェクトです。

たとえば、あるユーザーが複数のロールに属し、データ・オブジェクトがこれらすべてのロールに割り当てられている例を考えてみます。このデータ・オブジェクト・タイプのエンティティを削除するとします。これを行うには、すべてのロールにデータ・オブジェクトに対する更新権限が付与されていることを確認する必要があります。

あるユーザーがリクエスト・テンプレート管理者ロールとリクエスト管理者ロールに属し、データ・オブジェクトがこれら両方のロールに割り当てられているとします。このデータ・オブジェクト・タイプのエンティティを削除するとします。これを行うには、リクエスト・テンプレート管理者ロールとリクエスト管理者ロールの両方にデータ・オブジェクトに対する更新権限が付与されていることを確認する必要があります。

表12-7に、このカテゴリに含まれるデータ・オブジェクト、およびそのデータ・オブジェクトのエンティティを示します。

表12-7 明示的な挿入/更新/削除権限が必要なデータ・オブジェクト

データ・オブジェクト・タイプ

エンティティ

com.thortech.xl.dataobj.tcACS

組織.Lnk_Act_Svr

com.thortech.xl.dataobj.tcADL

アダプタ・ファクトリ.ロジック/変数設定タスク

com.thortech.xl.dataobj.tcADM

アダプタ・ファクトリ.入力/出力パラメータ

com.thortech.xl.dataobj.tcADP

アダプタ定義

com.thortech.xl.dataobj.tcADS

アダプタ・ファクトリ・ストアド・プロシージャ・タスク

com.thortech.xl.dataobj.tcADT

アダプタ・タスク

com.thortech.xl.dataobj.tcADU

アダプタ・ファクトリWebサービス・タスク

com.thortech.xl.dataobj.tcADV

アダプタ・ファクトリ.変数

com.thortech.xl.dataobj.tcAPA

アテステーション・プロセス管理者

com.thortech.xl.dataobj.tcARS

アダプタ・ステータス

com.thortech.xl.dataobj.tcATP

アダプタ・ファクトリ.パラメータ・タスク表

com.thortech.xl.dataobj.tcDAV

データ・オブジェクト.アダプタ変数

com.thortech.xl.dataobj.tcDVT

データ・オブジェクトに関連付けられたイベント・ハンドラ

com.thortech.xl.dataobj.tcEMD

電子メール定義

com.thortech.xl.dataobj.tcERR

エラー・メッセージ定義

com.thortech.xl.dataobj.tcEVT

イベント・ハンドラ

com.thortech.xl.dataobj.tcGPY

ロール・プロパティ

com.thortech.xl.dataobj.tcLKU

参照定義

com.thortech.xl.dataobj.tcLKV

参照用の参照値

com.thortech.xl.dataobj.tcOBA

リソース・オブジェクト認可者

com.thortech.xl.dataobj.tcODF

オブジェクトからプロセスへのデータ・フロー

com.thortech.xl.dataobj.tcODV

リソース・オブジェクト・イベント

com.thortech.xl.dataobj.tcOOD

リソース・オブジェクト.組織オブジェクトの依存性

com.thortech.xl.dataobj.tcOUD

リソース・オブジェクト.ユーザー・オブジェクトの依存性

com.thortech.xl.dataobj.tcPDF

プロセス統合.データ・フロー・マッピング

com.thortech.xl.dataobj.tcPKH

パッケージ階層

com.thortech.xl.dataobj.tcPOC

アクセス・ポリシー子表データ

com.thortech.xl.dataobj.tcPOF

ポリシー親データ

com.thortech.xl.dataobj.tcPOG

アクセス・ポリシーに定義されたロール

com.thortech.xl.dataobj.tcPOL

アクセス・ポリシー定義

com.thortech.xl.dataobj.tcPOP

アクセス・ポリシーの割当て済オブジェクト

com.thortech.xl.dataobj.tcPRF

プロセス・リコンシリエーション・フィールド・マッピング

com.thortech.xl.dataobj.tcPTY

システム構成

com.thortech.xl.dataobj.tcPWP

ポリシー・プロセス・ターゲット

com.thortech.xl.dataobj.tcPWR

パスワード・ポリシー

com.thortech.xl.dataobj.tcPWT

ポリシー・ユーザー・ターゲット

com.thortech.xl.dataobj.tcRAV

事前移入アダプタのマッピング

com.thortech.xl.dataobj.tcRCA

リコンシリエーションが一致した組織

com.thortech.xl.dataobj.tcRCH

リコンシリエーション・イベントのアクション履歴

com.thortech.xl.dataobj.tcRCP

一致したリコンシリエーション・イベント・プロセス

com.thortech.xl.dataobj.tcRCU

一致したリコンシリエーション・イベント・ユーザー

com.thortech.xl.dataobj.tcRCX

リコンシリエーション例外

com.thortech.xl.dataobj.tcRES

アダプタ・ファクトリ.リソース

com.thortech.xl.dataobj.tcRGP

ロール・メンバーシップ・ルール

com.thortech.xl.dataobj.tcRML

タスクの割当てルール

com.thortech.xl.dataobj.tcRPG

ロールに関するレポート

com.thortech.xl.dataobj.tcRUL

ルール

com.thortech.xl.dataobj.tcRUE

ルール要素

com.thortech.xl.dataobj.tcSDC

システム・ユーザー定義フォームのユーザー定義列

com.thortech.xl.dataobj.tcSDH

ユーザー定義フォームの親子階層

com.thortech.xl.dataobj.tcSDL

フォーム定義バージョン・ラベル

com.thortech.xl.dataobj.tcSDP

フォーム定義プロパティ

com.thortech.xl.dataobj.tcSPD

ITリソース・タイプ・パラメータ定義

com.thortech.xl.dataobj.tcSRE

ユーザー定義列と事前移入アダプタの関連付け

com.thortech.xl.dataobj.tcSRS

ITリソース・リンク

com.thortech.xl.dataobj.tcSUG

ITリソース.管理者

com.thortech.xl.dataobj.tcSVD

ITリソース・タイプ定義

com.thortech.xl.dataobj.tcTDV

プロセス・イベント・ハンドラ

com.thortech.xl.dataobj.tcTLG

システム・ログ

com.thortech.xl.dataobj.tcTSA

スケジュール・タスク属性

com.thortech.xl.dataobj.tcTSK

スケジュール済タスク

com.thortech.xl.dataobj.tcUHD

ユーザー.オブジェクト.履歴の詳細

com.thortech.xl.dataobj.tcUPL

ユーザー定義フィールド参照

com.thortech.xl.dataobj.tcUPT

ユーザー定義フィールド値

com.thortech.xl.dataobj.tcUPY

システム構成.ユーザー

com.thortech.xl.dataobj.tcWIN

フォーム情報

12.5.2.8.2 明示的な権限が不要なデータ・オブジェクト

明示的な権限が不要なデータ・オブジェクトとは、強制される権限がないか、または単に親データ・オブジェクトの権限に従うため、権限を定義する必要がないデータ・オブジェクトです。親データ・オブジェクトの権限を使用するデータ・オブジェクトは、ロールが親データ・オブジェクトに対して更新権限を持つ場合、そのロールは子データ・オブジェクトに対しても挿入、更新および削除権限を持つという単純な原則に従います。

明示的な権限が必要なのは、「表12-7 明示的な挿入/更新/削除権限が必要なデータ・オブジェクト」で説明したオブジェクトのみです。その他のデータ・オブジェクトは、権限が導出されるか、または暗黙的な権限を持ちます。

Oracle Identity Managerでは、データ・オブジェクトまたはファイングレイン権限をロールに割り当てる際、次のような権限モデルが使用されます。

- データの挿入権限を変更するには、ログイン中のユーザーが挿入および更新権限を持っている必要があります。

- データの更新権限を変更するには、ログイン中のユーザーが更新権限を持っている必要があります。

- データの削除権限を変更するには、ログイン中のユーザーが挿入、更新および削除権限を持っている必要があります。

12.5.3 ロール・カテゴリの作成と管理

ロール・カテゴリは、ナビゲーションおよび認可の目的でロールを分類するために使用します。ロール・カテゴリはロールの属性としてOracle Identity Managerに内部的に格納され、LDAPアイデンティティ・ストアの複数値ビジネス・カテゴリ属性とリコンサイルされます。LDAPの値が空の場合、ロールはシステム管理の未分類ロール・カテゴリに割り当てられます。LDAPの値が複数値、または未分類の単一値の場合、Oracle Identity Managerでは、ロール・リコンシリエーション・プロセスでロールをリコンサイルせず、リコンシリエーション・エラーが生成されます。

Oracle Identity Managerのデフォルト・ロール・カテゴリは次のとおりです。

- OIMロール: Oracle Identity Managerのすべての事前定義済ロールはこのカテゴリに割り当てられます。これらのロールは、Oracle Identity Managerにデフォルトで存在し、主に権限の管理で使用されます。これらの事前定義済ロールに対応するエンティティはLDAPストアにありません。

- デフォルト: 新規に作成されたロールはこのロール・カテゴリである必要があります。したがって、ロールの作成時にロール・カテゴリが指定されていない場合、そのロールはデフォルトでこのカテゴリに割り当てられます。

この項の内容は次のとおりです。

- ロール・カテゴリの作成

- ロール・カテゴリの検索

- ロール・カテゴリの変更

- ロール・カテゴリの削除

12.5.3.1 ロール・カテゴリの作成

ロール・カテゴリを作成する手順は、次のとおりです。

1. Oracle Identity Administrationにログインします。

2. 「ようこそ」ページで、「ロール」の下にある「ロール・カテゴリの作成」をクリックします。
または、左ペインの「参照」タブで「ロール」を展開し、「アクション」メニューから「カテゴリの作成」を選択します。あるいは、ツールバーにある「カテゴリの作成」アイコンをクリックします。

「ロール・カテゴリの作成」ページが表示されます。

3. 「カテゴリ名」ボックスに、ロール・カテゴリの名前を入力します。

4. 「説明」ボックスに、ロール・カテゴリの説明を入力します。このステップはオプションです。

5. 「保存」をクリックします。ページが表示され、ページの上部に、ロール・カテゴリが作成されたことを示すメッセージが表示されます。このページは「属性」タブと「ロール」タブで構成されます。
「属性」タブには、ロール・カテゴリの属性が表示されます。ロール・カテゴリを編集するには、このタブのフィールドを編集します。

「ロール」タブには、ロール・カテゴリに属するロールのリストが表示されます。

12.5.3.2 ロール・カテゴリの検索

ロール・カテゴリを検索する手順は、次のとおりです。

1. 「ようこそ」ページで、「ロール」の下にある「拡張検索 - ロール・カテゴリ」をクリックします。「拡張検索: カテゴリ」ページが表示されます。

2. 「カテゴリ名」フィールドに検索基準を入力します。検索基準にアスタリスク・ワイルドカード文字(*)を入力できます。

3. 「カテゴリ名」フィールドの横にあるリストから検索コンパレータを選択します。デフォルトの検索コンパレータは「次で始まる」です。ただし、「次と等しい」検索コンパレータも使用できます。

4. 検索条件にフィールドを追加する場合は、「フィールドの追加」をクリックします。リストから「説明」を選択します。「説明」フィールドが「拡張検索: カテゴリ」ページに追加されます。説明による検索を行うには、「説明」フィールドに検索基準を指定します。
検索基準から「説明」フィールドを削除するには、「説明」フィールドの横にある「X」アイコンをクリックします。

5. 「検索」をクリックします。指定した検索基準に一致するカテゴリが検索結果表に表示されます。

12.5.3.3 ロール・カテゴリの変更

ロール・カテゴリを変更する手順は、次のとおりです。

1. 左ペインの「参照」タブで「ロール」を展開します。

2. 変更するロール・カテゴリを選択します。

3. 「アクション」メニューから「開く」を選択します。または、ツールバーにある「ロールまたはカテゴリの詳細を開く」アイコンをクリックします。ページにロール・カテゴリに関する詳細が表示されます。

4. デフォルトで「属性」タブが開きます。このタブのフィールドを編集して、名前や説明などの基本カテゴリ情報を変更します。完了したら、「適用」をクリックします。

5. 「ロール」タブをクリックします。このタブでは、このカテゴリに割り当てられたすべてのロールを表示できます。
ロール・カテゴリに割り当てられたロールの詳細を表示する手順は、次のとおりです。

1. 「ロール・カテゴリの詳細」ページの「ロール」タブで、詳細を表示するロールを選択します。

2. 「アクション」メニューから「開く」(「ロールの詳細を開く」)を選択します。または、ツールバーにある「開く」(「ロールの詳細を開く」)をクリックします。選択したロールの「ロールの詳細」ページが表示されます。

12.5.3.4 ロール・カテゴリの削除

ロール・カテゴリを削除する手順は、次のとおりです。

1. 左ペインにあるロールの参照ツリーで、削除するロール・カテゴリを選択します。

2. 「アクション」メニューから「削除」を選択します。または、ツールバーにある「削除」アイコンをクリックします。「ロール・カテゴリの詳細」ページが開いている場合は、ツールバーにある「ロール・カテゴリの削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

3. 「はい」をクリックします。ロール・カテゴリが削除されます。

12.6 ロールに対する認可の管理

ユーザーがOracle Identity Managerにログインすると、そのユーザーが実行可能なアクションに関連付けられたリンク、ボタンおよびメニューが表示されます。たとえば、ユーザーにロールの拡張検索を実行する権限がある場合は、Oracle Identity Manager管理の「ようこそ」ページに「拡張検索 - ロール」リンクが表示されます。ユーザーに実行する権限があるアクションは、認可ポリシーによって決まります。これらの認可ポリシーは、Oracle Identity Managerに対して定義されてOracle Entitlements Server (OES)に格納されます。ポリシーは実行時に適用され、UIで各種タスクを実行するための認可を制御します。

関連項目:

認可ポリシーの詳細は、第15章「認可ポリシーの管理」を参照してください。

認可ポリシーは、権限とともに使用して、各種操作へのアクセス権を制御します。表12-8に、ロール管理操作に対する権限を示します。

表12-8 ロール管理の権限

権限

説明

ロールの作成

ユーザーがロールを作成できるかどうかを決定します

注意: この権限は、特定のロールに関連付けられません。

ロール詳細の変更

ユーザーが特定のロールを更新できるかどうかを決定します

ロールの削除

ユーザーが特定のロールを削除できるかどうかを決定します

ロール詳細の表示

ユーザーが特定のロールおよび特定のロールの完全な階層を表示できるかどうかを決定します

ロールの検索

ユーザーがロールを検索できるかどうかを決定します

注意: この権限は、特定のロールに関連付けられません。

ロール・メンバーシップの変更

ユーザーが特定のロールをユーザーに付与したり失効させたりできるかどうかを決定します

ロール階層の変更

ユーザーが特定のロールに対して子ロールを追加または削除できるかどうかを決定します

ロール・メンバーシップの表示

特定のロールが付与されているユーザーを決定します

ロール・カテゴリの作成

ユーザーがロール・カテゴリを作成できるかどうかを決定します

注意: この権限は、特定のロール・カテゴリまたは特定のロールに関連付けられません。

ロール・カテゴリの変更

ユーザーがロール・カテゴリを更新できるかどうかを決定します

注意: この権限は、特定のロール・カテゴリまたは特定のロールに関連付けられません。

ロール・カテゴリの削除

ユーザーがロール・カテゴリを削除できるかどうかを決定します

注意: この権限は、特定のロール・カテゴリまたは特定のロールに関連付けられません。

ロール・カテゴリ詳細の表示

ユーザーがロール・カテゴリの詳細を表示できるかどうかを決定します

注意: この権限は、特定のロール・カテゴリまたは特定のロールに関連付けられません。

ロール・カテゴリの検索

ユーザーがロール・カテゴリを検索できるかどうかを決定します

注意: この権限は、特定のロール・カテゴリまたは特定のロールに関連付けられません。

注意:

特定のロールをユーザーに付与するときは、付与するそのロールにロール・メンバーシップの変更権限が付与されている必要があります。

権限を付与する方法を規制する認可ポリシーによって、権限が適用されます。ロール管理機能のデフォルト認可ポリシーによって、Oracle Identity Managerは正常に機能します。これらのポリシーがないと、Oracle Identity Managerでタスクにアクセスしたり、タスクを実行することができません。これは、管理者およびユーザーにも適用されます。

Oracle Identity Administrationの「認可ポリシー」を使用して、カスタム認可ポリシーを作成し、委任管理を適用できます。認可ポリシーの作成時には、次のことを指定する必要があります。

- ポリシーの名前と説明

- ポリシーの作成対象になるOracle Identity Manager機能

- 各種アクションに関連付けられた一連の権限

- ロールにポリシーが割り当てられ、ロール・メンバーシップによって権限が付与されるユーザー

- ポリシーで指定されたアクションを実行できる一連のロールを示すデータ制約。階層ではデータ制約がサポートされています。したがって、階層に含まれるすべてのロールは、データ制約に含まれます。これによって、制約には少数のロールのみがリストされているが、階層に基づいて多数のロールが含まれる単一のポリシーを作成できます。

関連項目:

- この機能に対するデフォルト認可ポリシーについては、「ロール管理」を参照してください。

- ロール管理のカスタム認可ポリシーの作成については、「ロール管理に対する認可ポリシーの作成」を参照してください。

12.7 リクエスト・ベースのロールの付与

ロール付与の実行時にリクエストを生成するようにOracle Identity Managerを構成できます。このリクエストは承認が必要であるため、ロール付与リクエストが承認された場合のみロール付与が実行されます。さらに、ロール付与に対する職務の分離(SoD)チェックが有効な場合は、リクエスト・ベースのロール付与を構成する必要があります。ただし、ロール付与に対するSoDチェックを有効にしなくても、リクエスト・ベースのロール付与は有効にできます。

関連項目:

SoDについては、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の職務の分離(SoD)の使用に関する項を参照してください。

リクエスト・ベースのロール付与を構成するには、「XL.RM_REQUEST_ENABLED」および「XL.RM_ROLE_ASSIGN_TEMPLATE」システム・プロパティの値を設定する必要があります。これらのシステム・プロパティと有効な値については、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する項を参照してください。

「XL.RM_REQUEST_ENABLED」システム・プロパティが存在しない場合、またはこのプロパティに有効な値が指定されていない場合は、リクエストが生成されずにロール付与が実行されます。「XL.RM_REQUEST_ENABLED」が「true」で、「XL.RM_ROLE_ASSIGN_TEMPLATE」が設定されていないか値が無効な場合は、エラー・メッセージが表示され、ロール付与は実行されず、ロール・リクエストは生成されません。

ロール付与リクエストが生成された後に、リクエストIDが管理およびユーザー・コンソールに表示されます。これは、セルフサービスまたは拡張管理でリクエストをトラッキングするためです。

ロール付与リクエストの詳細は次のとおりです。

- リクエストID: 自動生成

- リクエスト・タイプ: リクエスト・テンプレートに基づく

- リクエスト・ステータス: 割当て済

- リクエスト日: 現在のタイムスタンプ

- 有効日: 現在のタイムスタンプ

- リクエスタ: Null

- 受益者: Null

- 理由: Null

13 組織の管理

Oracle Identity Managerでは、組織エンティティは、ユーザー、他の組織などのエンティティの論理的なコンテナを表します。

組織は、委任管理モデルで使用できるコンテナです。さらに、Oracle Identity Managerの他のエンティティ(ユーザーなど)のスコープも定義します。Oracle Identity Managerでは、フラットな組織構造または階層的な構造(組織に他の組織を含めることができることを意味する)を構成できます。Oracle Identity Managerのエンティティの管理を容易にするために、階層は部門、地理的な地域、またはその他の論理的な部署を表します。

委任管理を使用して大規模な組織の多数のロールや個人を管理できるように、Oracle Identity Managerでは、階層内のオブジェクトのメンバーシップに基づいて委任管理ポリシーを定義できます。これは、図13-1に示す階層のように、再帰的な組織メンバーシップもサポートしています。

図13-1 再帰的な組織メンバーシップ

「図13-1 再帰的な組織メンバーシップ」の説明

階層的な委任管理ポリシーを定義して委任管理者1に「Engineering」以下のパスワードをリセットする権限を付与した場合、この権限は「Employee1」、「Employee2」、「Employee3」および「Employee4」に付与されます。メンバーシップ・ルートが「Development」の場合、Bobには、「Employee2」と「Employee3」のみに対する権限が付与されます。

組織のサービス、およびそのサービスをサポートするUIコンポーネントの機能については、次の各項で説明します。

- 組織エンティティ定義

- 組織管理タスク

- 組織管理の認可

13.1 組織エンティティ定義

Oracle Identity Managerでは、組織エンティティに対してデフォルトで属性が定義されています。これらの属性は、すべてのエンティティ(ユーザー、組織、ロール、ロール階層、ロール・メンバーシップなど)で同じです。エンティティに対して定義される属性のリストは、「ユーザー・エンティティ定義」を参照してください。

表13-1に、組織エンティティのデフォルト属性を示します。

表13-1 組織エンティティのデフォルト属性

属性名

カテゴリ

タイプ

データ型

表示タイプ

プロパティ

組織名

基本

単一

文字列

単一行テキスト

必須: はい

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

タイプ

基本

単一

文字列

LOV

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

親組織

基本

単一

文字列

単一行テキスト

必須: いいえ

システムによるデフォルト設定が可能: いいえ

システム制御: いいえ

暗号化: クリア

ユーザー検索可能: はい

ステータス

基本

単一

文字列

単一行テキスト

必須: はい

システムによるデフォルト設定が可能: はい

システム制御: はい

暗号化: クリア

ユーザー検索可能: はい

13.2 組織管理タスク

組織管理に関連するタスクは、Oracle Identity Management管理の「組織管理」セクションで実行します。タスクについては、次の各項で説明します。

- 組織の検索

- 組織の参照

- 組織の作成

- 組織の表示と変更

- 組織の有効化と無効化

- 組織の削除

13.2.1 組織の検索

Oracle Identity Administrationを使用して、次のタイプの組織検索操作を実行できます。

- 単純検索の実行

- 拡張検索の実行

注意:

組織を検索したときに検索結果に表示される組織は、「XL.EnableOrgPermissionCheck」システム・プロパティによって制御されます。このシステム・プロパティについては、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのOracle Identity Managerのシステム・プロパティに関する項を参照してください。

13.2.1.1 単純検索の実行

単純検索操作によって、検索属性として指定した検索文字列に基づいて組織エンティティを検索できます。この操作は、単純検索またはクイック検索とも呼ばれます。

組織の単純検索を実行する手順は、次のとおりです。

1. Oracle Identity Administrationにログインします。

2. 左ペインの「管理」タブで、ドロップダウン・リストから「組織」を選択します。

3. 「検索」フィールドに、検索基準として組織名を入力します。検索基準にはワイルドカード文字(*)を使用できます。パフォーマンス上の理由から、先頭(接頭辞)のワイルドカードは削除されます。ただし、末尾(接頭辞)のワイルドカードはすべての検索に追加されます。

4. 「検索」アイコンをクリックします。「検索結果」タブに検索結果の表が表示され、検索基準に一致する組織名が表示されます。図13-2に、検索結果表を示します。

図13-2 組織の検索結果

「図13-2 組織の検索結果」の説明

13.2.1.2 拡張検索の実行

組織の拡張検索では、単純検索操作より複雑な検索基準を指定できます。結果は検索結果表に表示されます。

組織の拡張検索を実行する手順は、次のとおりです。

1. Oracle Identity Administrationにログインします。

2. 「ようこそ」ページで、「組織」の下にある「拡張検索 - 組織」をクリックします。右ペインに「拡張検索」ページが表示されます。

3. 次のいずれかを選択します。

- すべて: 検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。

- いずれか: 検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。

4. 「組織名」フィールドに、検索する組織名の検索属性を入力します。これを行うには、検索コンパレータを選択します。デフォルトの検索コンパレータは「次で始まる」です。かわりに、プルダウン・リストからコンパレータ「次と等しい」を選択することもできます。検索コンパレータの詳細は、「検索コンパレータ」を参照してください。
ワイルドカード文字を使用して、組織名を指定できます。

5. 「組織カスタマ・タイプ」リストから組織タイプを選択します。組織タイプには、「支店」、「部門」または「会社」があります。

6. 「フィールドの追加」ボタンから「組織ステータス」を選択します。

7. 「組織ステータス」リストから組織ステータス(「アクティブ」、「削除」または「無効」)を選択します。

8. 「検索」をクリックします。図13-3に示すように、検索結果表に結果が表示されます。検索結果表には、組織名、親組織、組織カスタマ・タイプおよび組織ステータスが表示されます。

図13-3 拡張検索

「図13-3 拡張検索」の説明

13.2.2 組織の参照

Oracle Identity Manager管理の「組織」セクションで、データを参照できます。参照機能はUIの左ペインで使用できます。

参照操作を使用して、システム内の組織ツリーをルート組織から移動できます。複数の組織ツリーがある場合は、すべてのツリーが表示されます。各ツリーの先頭は、親組織を持たないルート組織ノードです。組織に定義されたユーザーは、ツリー内のノードとして表示されません。

組織を参照するには、Oracle Identity Manager管理の左ペインの「参照」タブで「組織」をクリックします。図13-4に示すように、Oracle Identity Managerのすべての組織が参照リストに表示されます。

図13-4 組織の参照リスト

「図13-4 組織の参照リスト」の説明

組織の参照リストには、ルートおよび子組織が表示された組織ツリーが表示されます。

組織の参照リストでは、次の操作を実行できます。

- 組織を作成します。「組織の作成」を参照してください。

- 組織の詳細を開きます。「組織の表示と変更」を参照してください。

- 組織を削除します。「組織の削除」を参照してください。

- 管理ロールを管理します。「管理ロールの管理」を参照してください。

13.2.3 組織の作成

組織を作成するには、「組織の作成」ページを使用します。このページには、組織を作成する権限がある場合のみアクセスできます。

注意:

1つ以上の組織に対して組織の作成権限がある場合のみ、組織の作成が許可されます。

組織を作成するには、次の手順を実行します。

1. 「組織の作成」ページを開きます。これを行うには、次のいずれかを実行します。

- Oracle Identity Manager管理の「ようこそ」ページで、「組織」の下にある「新規組織の作成」をクリックします。

- 左ペインで「参照」タブをクリックします。「組織」の下で、「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」アイコンをクリックします。

- 左ペインで「検索結果」タブをクリックし、検索リストで「組織」を選択します。「アクション」メニューから「作成」を選択します。または、ツールバーにある「作成」アイコンをクリックします。

- 「拡張検索: 組織」ページで、「アクション」メニューから「組織の作成」を選択するか、またはツールバーにある「作成」をクリックします。

図13-5に、「組織の作成」ページを示します。

図13-5 「組織の作成」ページ

「図13-5 「組織の作成」ページ」の説明

2. 「組織の作成」ページのフィールドに値を入力します。表13-2に、「組織の作成」ページのフィールドを示します。

表13-2 「組織の作成」ページのフィールド

フィールド

説明

名前

組織の名前

タイプ

組織のタイプ(「会社」、「部門」または「支店」のいずれか)

親組織

新規作成した組織が所属する組織

3. 「名前」フィールドに、組織の名前を入力します。

4. 「タイプ」フィールドで、組織のタイプ(「会社」、「部門」または「支店」)を選択します。

5. 新規作成した組織が所属する親組織を指定します。手順は次のとおりです。

1. 「親組織」フィールドの横にある「検索」アイコンをクリックします。図13-6に示すように、「検索: 組織」ダイアログ・ボックスが表示されます。

図13-6 「検索: 組織」ダイアログ・ボックス

「図13-6 「検索: 組織」ダイアログ・ボックス」の説明

2. 次のオプションのいずれかを選択します。

- すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。

- いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。

3. 「組織名」フィールドに、検索する組織名を入力します。検索基準にはワイルドカード文字を使用できます。「組織名」フィールドの横にあるリストから検索条件を選択します。検索条件は「次と等しい」または「次で始まる」です。

4. 「組織カスタマ・タイプ」フィールドに、親組織の組織タイプを入力します。検索基準にはワイルドカード文字を使用できます。「組織カスタマ・タイプ」フィールドの横にあるリストから検索条件を選択します。

5. 「検索」をクリックします。指定した検索基準に一致する組織が検索結果表に表示されます。

6. 検索結果表から、親組織として指定する組織を選択します。

7. 「終了」をクリックします。選択した組織が親組織として追加されます。

6. 「保存」をクリックして組織を作成します。

13.2.4 組織の表示と変更

組織の表示操作では、「ユーザーの詳細」ページで詳細な組織プロファイル情報を表示できます。このページは、認可ポリシーで組織の詳細の表示権限により組織プロファイルを表示する権限が付与されている場合のみ表示できます。また、組織の変更権限がある場合は、このページを使用して組織を変更できます。

注意:

組織エンティティの「組織の詳細」ページは、構成および詳細な認可に基づいてシステムで自動生成されます。Oracle Identity Managerでは、システム生成ページをカスタム定義ページで上書きするメカニズムはありません。

組織の詳細を開くには、次のいずれかを実行します。

- Oracle Identity Manager管理の左ペインで、「参照」タブをクリックします。「組織」の下で、詳細を表示する組織を選択します。「アクション」メニューから「開く」を選択します。または、ツールバーにある「開く」アイコンをクリックします。

- 詳細を表示する組織の単純検索を実行します。検索結果から組織を選択します。「アクション」メニューから「開く」を選択します。または、ツールバーにある「開く」アイコンをクリックします。

- 詳細を表示する組織の拡張検索を実行します。拡張検索結果から組織を選択し、「アクション」メニューから「組織の更新」を選択します。または、ツールバーにある「開く」をクリックします。

図13-7に示すように、「組織の詳細」ページが表示されます。

図13-7 「組織の詳細」ページ

「図13-7 「組織の詳細」ページ」の説明

「組織の詳細」ページでは、管理組織の変更を実行できます。変更は「組織の詳細」ページの複数のセクションで個別に行うため、各セクションで行った変更は他のセクションに影響を与えず、変更内容は個別に保存する必要があります。各セクションで行う変更については、次の各項で説明します。

注意:

組織を更新したり削除するには、組織の作成権限が必要です。

- 組織の属性の変更

- 子組織の表示

- ユーザー情報の表示

- リソースの変更

13.2.4.1 組織の属性の変更

図13-7に示すように、「組織の詳細」ページの「属性」タブには、組織の属性が表示されます。認可ポリシーで組織プロファイルの変更権限により組織プロファイルを変更する権限が付与されている場合は、「組織の詳細」ページが編集可能モードで開き、組織情報を変更できます。属性の値を変更し、「保存」をクリックして変更内容を保存します。

ログイン・ユーザーが組織を変更できるかどうかは、認可ポリシーによって制御されます。組織の変更を許可されていない場合、「組織の詳細」ページは読取り専用モードで表示され、編集可能なフィールドはありません。組織管理機能の認可については、「組織管理の認可」を参照してください。

注意:

「組織の詳細」ページの「ステータス」属性は読取り専用です。

13.2.4.2 子組織の表示

「階層」タブは読取り専用タブで、選択した組織に所属する子組織のリストが表示されます。リスト内の各子組織に関して、次の情報が表示されます。

- 組織名

- タイプ

- ステータス

「階層」タブから子組織の詳細を開くには、組織を選択し、「アクション」メニューから「開く」を選択します。または、ツールバーにある「開く」をクリックするか、単に組織の名前をクリックします。

子組織を変更するには、変更する子組織の名前をクリックします。選択した組織の「組織の詳細」ページが表示され、このページを使用してその組織の詳細を変更できます。

13.2.4.3 ユーザー情報の表示

「メンバー」タブは読取り専用タブで、選択した組織のユーザーのリストが表示されます。リスト内の各ユーザーに関して、次の情報が表示されます。

- ユーザー名

- 名

- 姓

- マネージャ名

「メンバー」タブからユーザーの詳細を開くには、ユーザーを選択し、「アクション」メニューから「開く」を選択します。または、ツールバーにある「開く」をクリックするか、単にユーザーの名前をクリックします。

ヒント:

「ユーザーの詳細」ページの「属性」タブを使用して、組織に対してユーザーを追加または削除できます。詳細は、「「属性」タブ」を参照してください。

13.2.4.4 リソースの変更

「リソース」タブには、選択した組織に対して許可されたリソースが表示されます。リストから1つまたは複数のリソースを選択して、次のことを実行できます。

- リソースのプロビジョニング

- リソースの失効

13.2.4.4.1 リソースのプロビジョニング

組織にリソースをプロビジョニングする手順は、次のとおりです。

1. 「アクション」メニューから「プロビジョニング」を選択します。または、ツールバーにある「プロビジョニング」をクリックします。これによって、ウィザードの「ステップ1: リソースの選択」が起動します。

2. プロビジョニングするリソースを選択します。リソースを選択し、「続行」をクリックします。

3. 「ステップ2: リソースの選択の検証」ページに、組織に追加する対象として選択したリソースが表示されます。情報を検証し、「続行」をクリックします。選択したリソースの組織へのプロビジョニングが開始されます。

4. 組織にリソースをプロビジョニング・ウィザードを閉じます。リソースが「階層」タブに追加されます。

ヒント:

プロビジョニングされたリソースが「階層」タブに表示されない場合は、ツールバーにある「リフレッシュ」をクリックします。

13.2.4.4.2 リソースの失効

リソースを失効する手順は、次のとおりです。

1. 削除するリソースを選択します。

2. 「アクション」リストから「失効」を選択します。または、ツールバーにある「失効」をクリックします。確認を求めるメッセージが表示されます。

3. 「OK」をクリックして処理を確認します。

13.2.5 組織の有効化と無効化

注意:

- 子組織またはユーザーが含まれる組織は無効化できません。「ORG.DISABLEDELETEACTIONENABLED」システム・プロパティを「true」に設定した場合のみ、強制的に削除できます。このプロパティを設定した場合は、親組織が削除されるとユーザーおよび下位組織も削除されます。

- 組織を無効化できるのは、その組織に対する書込み権限がある場合のみです。

「有効」状態の組織を無効化する手順は、次のとおりです。

1. 「組織の詳細」ページで、ページの上部にある「組織の無効化」をクリックします。確認を求めるメッセージが表示されます。または、組織の単純検索結果から組織を選択し、「アクション」メニューから「無効化」を選択します。

2. 「OK」をクリックして処理を確認します。組織が正常に無効化されたことを示すメッセージが表示されます。

3. 「OK」をクリックします。

「無効」状態の組織を有効化する手順は、次のとおりです。

1. 「組織の詳細」ページで、ページの上部にある「組織の有効化」をクリックします。または、組織の単純検索結果から組織を選択し、「アクション」メニューから「有効化」を選択します。確認を求めるメッセージが表示されます。

2. 「OK」をクリックして処理を確認します。組織が正常に有効化されたことを示すメッセージが表示されます。

3. 「OK」をクリックします。

注意:

組織を有効化できるのは、その組織に対する書込み権限がある場合のみです。

13.2.6 管理ロールの管理

「組織の詳細」ページでは、選択した組織を管理できる管理ロールおよび関連付けられた権限のリストを表示および定義できます。組織に管理ロールを割り当てるには、組織を作成するための適切な権限が必要です。組織を作成する権限を割り当てる手順は、次のとおりです。

1. 組織に対する管理権限を割り当てるロールの「ロールの詳細」ページで、「データ・オブジェクトの権限」をクリックします。「ロールの詳細 >> 権限」ページが表示されます。

2. 「割当て」をクリックします。「割当て権限」ページに、選択してロールに割当て可能な権限の名前のリストが表示されます。

3. 組織権限に対して、「挿入の許可」オプションを選択します。これによって、組織の作成権限がorgadminロールに付与されます。次に、組織権限の右側にある「割当て」オプションを選択します。

4. 「割当て」をクリックします。確認を求めるメッセージが表示されます。

5. 「割当ての確認」をクリックします。権限がロールに割り当てられます。

組織に管理ロールを割り当てる手順は、次のとおりです。

注意:

挿入権限は、書込み権限および削除権限の前提条件です。挿入権限を拡張して、新規組織を作成できます。書込み権限によって、組織を更新、有効化および無効化できます。削除権限によって、組織を削除できます。

1. 次のいずれかを選択して、「管理ロール」ページを開きます。

- 組織の単純検索結果から組織を選択します。「アクション」メニューから「管理ロール」を選択します。

- 左ペインの「参照」タブで、組織を選択します。「アクション」メニューから「管理ロール」を選択します。

- 「組織の詳細」ページで、「管理ロール」をクリックします。

2. 「管理ロール」ページで、「ロール名によるフィルタ」に検索基準を入力して、組織を管理できる管理ロールを検索します。次に、「検索」をクリックします。ロールおよび関連付けられた権限のリストが表示されます。

3. 組織からロールを割当て解除するには、管理ロールの右側にある「割当て解除」オプションを選択し、「割当て解除」をクリックします。

4. 組織に管理ロールを割り当てる手順は、次のとおりです。

1. 「割当て」をクリックします。「割当て」ページに、使用可能なロールのリストが表示されます。
「ロール名によるフィルタ」ボックスに検索基準を入力して「検索」をクリックすると、ロール名でフィルタ処理できます。

「読取り」オプションは、すべてのロールでデフォルトで選択されていることに注意してください。

2. 管理ロールの「書込み」、「削除」および「割当て」オプションを選択し、それぞれ書込み、削除および割当て管理権限を付与します。

3. 「割当て」をクリックします。

5. 管理ロールの権限を更新する手順は、次のとおりです。

1. 「権限の更新」をクリックします。「更新」ページに、権限を変更可能な管理ロールのリストが表示されます。
「ロール名によるフィルタ」ボックスに検索基準を入力して「検索」をクリックすると、ロール名でフィルタ処理できます。

「読取り」オプションは、すべてのロールでデフォルトで選択されていることに注意してください。

2. 管理ロールの「書込み」および「削除」オプションを選択または選択を解除して、それぞれ書込みおよび削除権限を変更します。

3. 「更新」をクリックします。

6. 終了後、「管理ロール」ページを閉じます。図13-8に、「管理ロール」ページを示します。

図13-8 管理ロールの割当て

13.2.7 許可されたリソースの管理

「許可されたリソース」ページでは、選択した組織のユーザーに許可されたリソースのリストを割り当てたり、許可されたリソースを更新できます。

1. 選択した組織のユーザーに許可されたリソースを割り当てる手順は、次のとおりです。

1. 左ペインの「参照」タブで、組織を選択します。「アクション」メニューから「開く」を選択します。

2. 「組織の詳細」ページで、「許可されたリソース」をクリックします。

3. 「許可されたリソース」ページで、リソースを選択して「割当て」をクリックします。

2. 選択した組織に許可されているリソースを更新する手順は、次のとおりです。

1. 左ペインの「参照」タブで、組織を選択します。「アクション」メニューから「開く」を選択します。

2. 「組織の詳細」ページで、「許可されたリソース」をクリックします。

3. 「許可されたリソース」ページで、リソースを選択して「更新」をクリックします。

図13-9に、許可されたリソースの割当てページを示します。

図13-9 許可されたリソースの割当て

13.2.8 組織の削除

注意:

- 子組織またはユーザーが含まれる組織は削除できません。「ORG.DISABLEDELETEACTIONENABLED」システム・プロパティを「true」に設定した場合のみ、強制的に削除できます。このプロパティを設定した場合は、親組織が削除されるとユーザーおよび下位組織も削除されます。

- 組織を削除できるのは、その組織に対する削除権限がある場合のみです。

- 削除されたデータは、「削除」とマークされてデータベース内に引続き存在します。

組織を削除するには、次の手順を実行します。

1. 組織の拡張検索結果から、削除する組織を選択します。

2. 「アクション」メニューから「削除」を選択します。確認を求めるメッセージが表示されます。または、組織の単純検索結果で、「アクション」メニューから「削除」を選択します。それ以外に、「参照」タブで「アクション」メニューから「削除」するか、「組織の詳細」ページで「組織の削除」をクリックします。

3. 「OK」をクリックして処理を確認します。組織が正常に削除されたことを示すメッセージが表示されます。

4. 「OK」をクリックします。

13.3 組織管理の認可

組織管理機能の認可は、組織管理ロールに基づきます。組織を管理するには、ロールに次の権限セットが必要です。

- ロールには、組織エンティティに対する次のデータ・オブジェクト権限が必要です。

- 挿入 - このロールを持つユーザーは、新規組織を作成して管理できます。

- 有効化/無効化/更新

これらの権限は、特定の組織に固有ではありません。

- ロールが組織の管理ロールとして割り当てられている場合は、次の権限が必要です。

- 読取りおよび表示権限(管理ロールであるため暗黙的に必要)

- 書込み

- 削除

これらの権限は組織ごとに構成します。

Oracle Identity ManagerセルフサービスからOracle Identity Manager管理にアクセスする権限は、メニュー項目権限によって管理されます。ユーザーにOracle Identity Manager管理へのアクセス権がある場合、そのユーザーはユーザー、ロールおよび組織を参照できます。

ユーザーおよびロール・エンティティに対する編集、表示および削除アクション用の第2レベル・メニューは、ユーザーおよびロールに対する作成、更新、削除など対応するOESポリシーから導出されます。

同様に、組織を編集、表示および削除するための第2レベル・メニューは、orgadminロール、および組織エンティティ・タイプに対するデータ・オブジェクト権限から導出されます。

Oracle Identity Manager 11g リリース1 (11.1.1)では、Oracle Entitlements Server (OES)の認可ポリシーを使用して委任管理権限が管理されます。ユーザー管理のOESポリシーを使用すると、次の内容を制御できます。

関連項目:

OESの認可ポリシーの詳細は、第15章「認可ポリシーの管理」を参照してください。

- ユーザーを作成または変更できる組織

- 複数の組織(階層の有無に関係なく)のユーザーを変更できるデータ制約を指定可能

さらに、これらの機能によって委任管理モデルが提供されます。

組織の委任管理者を構成する手順は、次のとおりです。

1. カスタム認可ポリシーを定義して、ユーザーを管理し、組織制約を設定します。組織制約は階層対応が可能です。カスタム認可ポリシーの作成およびデータ制約の設定については、「カスタム認可ポリシーの作成」を参照してください。

2. カスタム・ポリシーで指定したロールにユーザーを追加します。ロールへのユーザーの追加については、「ロールの追加と削除」を参照してください。

3. ロールを組織管理者として設定するには、最初にロールを作成します。「ロールの作成」を参照してください。
orgadminロールを作成すると、このロールの「ロールの詳細」ページが表示されます。

4. このorgadminロールに、組織タイプに対するデータ・オブジェクト権限を割り当てます。このデータ・オブジェクト権限を使用して、このロールを持つユーザーは新規組織を作成して管理できます。ロールへの組織の作成権限の割当てについては、「管理ロールの管理」を参照してください。

5. 組織を選択し、その組織の管理ロールとしてorgadminロールを割り当てます。このステップによって、ユーザーは選択した組織を管理できるようになります。管理権限には、更新、有効化、無効化および削除が含まれます。組織への管理ロールの割当てについては、「管理ロールの管理」を参照してください。

14 リクエストの作成と検索

Oracle Identity Managerのユーザーは、リクエスト管理者グループに属している場合、Oracle Identity Manager拡張管理からリクエストの作成や検索などリクエストに関する操作を実行してリクエストを管理できます。

この章では、リクエスト管理機能について次の各項で説明します。

関連項目:

リクエスト管理の概念およびタスクについては、「リクエストの管理」を参照してください。

- Oracle Identity Manager拡張管理を使用したリクエストの作成

- リクエストの検索とトラッキング

14.1 Oracle Identity Manager拡張管理を使用したリクエストの作成

ロールに適切な権限が付与されている場合は、Oracle Identity Manager拡張管理にログインして、自分および他のユーザーのためにリクエストを作成できます。また、Oracle Identity Managerセルフサービスを使用してリクエストを作成することもできます。

リクエストの作成について、次の各シナリオを使用して説明します。

- ユーザーを作成するリクエストの作成

- ユーザーにリソースをプロビジョニングするリクエストの作成

- リソースをプロビジョニング解除するリクエストの作成

14.1.1 ユーザーを作成するリクエストの作成

ユーザーを作成するリクエストを作成する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理で、「管理」タブをクリックし、次に「リクエスト」をクリックします。

2. 左ペインの「アクション」メニューから「リクエストの作成」を選択します。または、ツールバーにある「リクエストの作成」アイコンをクリックします。リクエストの作成ウィザードの「リクエスト・テンプレートの選択」ページが表示されます。

注意:

リクエストの作成ウィザードの各ステップは、第1ステップで選択するリクエスト・テンプレートに基づいて動的に生成されます。

3. 「リクエスト・テンプレート」リストから、リクエストの作成のベースになるリクエスト・テンプレートを選択します。ドロップダウン・リストには、すべてのデフォルト・リクエスト・テンプレート、およびリクエスト・タイプに基づいて作成されるカスタム・テンプレートが表示されます。たとえば、「契約者の作成」を選択し、「次」をクリックします。

注意:

- 「契約者の作成」リクエスト・テンプレートはデフォルト・リクエスト・テンプレートではなく、付与されている権限に基づいて同じ名前のリクエスト・テンプレートが作成されている場合に、選択対象として有効になります。これはこのシナリオ用に作成されるリクエスト・テンプレートで、契約従業員のユーザー・アカウントを作成するために「ユーザーの作成」リクエスト・タイプに基づいて作成されます。このリクエスト・テンプレートの作成については、「「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」を参照してください。

- 「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・テンプレートは、「リクエスト・テンプレート」リストでは使用できません。これは、「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・タイプに基づいたリクエスト・テンプレートを使用したリクエストの作成は、UIではなく、APIからサポートされるためです。ただし、「リクエスト・テンプレート」タブではこれらのリクエスト・テンプレートを検索できます。さらに、「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・タイプは、承認ポリシーおよび新規リクエスト・テンプレートの作成に使用できます。

4. 「詳細の入力」ページで、ユーザー属性の値を指定します。ユーザー属性のフィールドは、「契約者の作成」リクエスト・テンプレートの定義に従って表示されます。たとえば、「ミドル・ネーム」属性の値がテンプレート・レベルですでに指定されている場合、この属性は表示されません。「組織」属性の場合は、テンプレート・レベルで値が定義されているLOVが使用可能になります。これらの値の指定に関する詳細は、「「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」を参照してください。
ユーザー属性の値を指定した後に、「次」をクリックします。

5. 「追加データの入力」ページで、このリクエストの作成に使用するリクエスト・テンプレートで追加データとして指定されている属性の値を入力します。たとえば、リクエスト・テンプレートで「生年月日」が追加属性として指定されているとします。「生年月日」フィールドに値を入力し、「次」をクリックします。

注意:

「追加データの入力」ページは、リクエスト・テンプレートで指定されている追加データに基づいて動的に表示されます。

6. 「確認」ページで、「有効日」および「理由」フィールドの値を指定します。有効日とは、リクエストが承認後にアクティブになる日付です。たとえば、ユーザー作成リクエストが承認されると、「有効日」フィールドに指定した日にユーザーがOracle Identity Managerに作成されます。「理由」フィールドはリクエストを作成する理由を示し、承認者がリクエストを承認または却下する際に役立ちます。
「終了」をクリックすると、「契約者の作成」リクエスト・テンプレートに基づいてユーザーを作成するリクエストが作成されます。

14.1.2 ユーザーにリソースをプロビジョニングするリクエストの作成

1人以上のユーザーにリソースをプロビジョニングするリクエストを作成する手順は、次のとおりです。

注意:

次のリクエスト・タイプは、リクエストの作成および実行に関して特性が類似しています。

- リソースのプロビジョニング

- プロビジョニング済リソースの変更

1. Oracle Identity Manager拡張管理で、「管理」タブをクリックし、次に「リクエスト」タブをクリックします。

2. 左ペインの「アクション」メニューから「リクエストの作成」を選択します。リクエストの作成ウィザードの「リクエスト・テンプレートの選択」ページが表示されます。このウィザードのステップは、第1ステップで選択するリクエスト・テンプレートに基づいて動的に生成されます。

3. 「リクエスト・テンプレート」リストから、リクエストの作成のベースになるリクエスト・タイプまたはリクエスト・テンプレートを選択します。たとえば、「E-Businessリソースのプロビジョニング」を選択し、「次」をクリックします。

注意:

「E-Businessリソースのプロビジョニング」リクエスト・テンプレートはデフォルト・リクエスト・テンプレートではなく、付与されている権限に基づいて同じ名前のリクエスト・テンプレートが作成されている場合に、選択対象として有効になります。これはこのシナリオ用に作成されるリクエスト・テンプレートで、ユーザーにE-Businessリソースをプロビジョニングするために「リソースのプロビジョニング」リクエスト・タイプに基づいて作成されます。このリクエスト・テンプレートの作成については、「「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」を参照してください。

4. 「ユーザーの選択」ページで、リソースをプロビジョニングするユーザーを検索するためのフィールドに検索基準を指定し、「検索」をクリックします。指定した検索基準に一致するユーザーのリストが「使用可能なユーザー」リストに表示されます。

5. 「使用可能なユーザー」リストから、リソースをプロビジョニングするユーザーを1人以上選択します。直属の部下であるユーザーを1人以上選択できます。つまり、ユーザーのプロファイルで自分がマネージャと指定されているユーザーを1人以上選択できます。
「移動」をクリックして、選択内容を「選択したユーザー」リストに移動し、「次」をクリックします。

注意:

このページには、ユーザー・エンティティの認可ポリシーに基づいて「使用可能なユーザー」リストが表示されます。リクエスト・テンプレートからユーザーを制限することはできません。

6. 「リソースの選択」ページで、使用可能なリソースを検索します。使用可能なリソース・リストからプロビジョニングするリソースを選択し、「移動」をクリックして、選択したリソースを「選択したリソース」リストに移動します。たとえば、プロビジョニングするリソースとして「E-Business RO」を選択し、「次」をクリックします。

注意:

「E-Businessリソースのプロビジョニング」リクエスト・テンプレートはE-Businessリソースをプロビジョニングするためにのみ作成されているため、「選択したリソース」リストに表示されるのは「E-Business RO」リソースのみです。リクエスト・テンプレートで選択したリソースに基づいて、リソースが使用可能なリソース・リストに表示されます。

7. 「リソースの詳細」ページで、リソースの属性の値を指定します。
たとえば、選択したユーザー(1人または複数)にプロビジョニングするE-Businessリソースの存続期間を選択できます。「存続期間タイプ」参照で、短期間、中期間、長期間などの存続期間タイプを選択します。「サーバー」参照では、接続するE-Businessサーバーの名前を選択します。「Oracle Appsユーザーの職責」親属性では、「職責開始日」、「職責終了日」および「職責名」子属性に対して複数の値セットを入力できます。これを行うには、各フィールドで値を選択し、「追加」をクリックします。「職責開始日」、「職責終了日」および「職責名」フィールドに別の値セットを入力して「追加」をクリックする操作を繰り返します。親属性および子属性の定義については、「「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」を参照してください。

注意:

このページでは、属性がリクエスト・データセットから取得されます。リクエスト・データセットについては、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

他のすべてのリソース属性に値を指定し、「次」をクリックします。

「リソースの選択」ページで複数のリソースを選択すると、選択した各リソースの「リソースの詳細」ページが1つずつ表示されます。たとえば、「リソースの選択」ページで、E-BusinessリソースとActive Directoryリソースを選択したとします。E-Businessリソースの「リソースの詳細」ページが表示されます。E-Businessリソースのすべての属性について値を入力し、「次」をクリックします。次に、Active Directoryリソースの「リソースの詳細」ページが表示されます。Active Directoryリソースのすべての属性について値を指定し、「次」をクリックします。

8. 選択したリソースに依存リソースがある場合は、依存リソースを選択するステップが表示されます。依存リソースを選択し、「次」をクリックします。
リソース・オブジェクトは、他のリソース・オブジェクトに依存している場合があります。リソースのプロビジョニング・リクエスト(自分または他のユーザー用)の作成時に、依存リソースがまだプロビジョニングされていない場合、その依存リソースはリクエストに自動的に追加されます。これは、「リソースのプロビジョニング」およびリソースの自己プロビジョニング・リクエスト・タイプにも適用されます。

次のタイプの依存リソースがあります。

- 単一受益者: 単一ユーザーに対するリソースのプロビジョニング・リクエストの作成時に、依存リソースがまだプロビジョニングされていない場合、その依存リソースはリクエストに自動的に追加されます。
リソース・オブジェクト「DB」、「AD」および「Exchange」は、「Exchange」が「AD」に依存し、「AD」が「DB」に依存するように作成されているとします。単一受益者依存リソースについては、次の例を使用して説明します。

- 例1: ユーザーJaneにリソースはありません。Janeは、リソースの自己プロビジョニング・リクエスト時に、「リソースの選択」ステップでリソースとして「Exchange」を選択します。Janeには依存リソース「AD」および「DB」がないため、リクエストUIによって、リソース「Exchange」とともにリソース「AD」および「DB」のリソース詳細収集ステップが自動的に追加されます。

- 例2: ユーザーJohnには「DB」リソースがプロビジョニングされています。リソース「Exchange」をJohnにプロビジョニングするとします。リソースのプロビジョニング・リクエスト時に、「ユーザーの選択」ステップでJohnを選択し、「リソースの選択」ステップで「Exchange」を選択します。Johnには依存リソース「AD」がプロビジョニングされていないため、リクエストUIによって、リソース「Exchange」とともにリソース「AD」のリソース詳細収集ステップが自動的に追加されます。Johnにはリソース「DB」がすでにプロビジョニングされているため、リソース「DB」は追加されません。

- 例3: ユーザーBradにリソースはありません。Bradは、リソースの自己プロビジョニング・リクエスト時に、「リソースの選択」ステップでリソースとして「DB」を選択します。「DB」には依存リソースがないため、リソース「DB」のリソース詳細収集ステップのみが表示されます。

- 複数受益者: 複数ユーザーに対するリソースのプロビジョニング・リクエストの作成時に、ユーザーに依存リソースがまだプロビジョニングされていない場合、その依存リソースはリクエストに自動的に追加されます。依存リソースは、まだその依存リソースがプロビジョニングされていない受益者にのみ追加されます。
リソース・オブジェクト「DB」、「AD」および「Exchange」は、「Exchange」が「AD」に依存し、「AD」が「DB」に依存するように作成されているとします。複数受益者依存リソースについては、次の例を使用して説明します。

- 例1: ユーザーJaneとJohnにリソースはプロビジョニングされていません。リソース「Exchange」をJaneとJohnにプロビジョニングするとします。リソースのプロビジョニング・リクエスト時に、「ユーザーの選択」ステップでJaneとJohnを選択し、「リソースの選択」ステップで「Exchange」を選択します。両方の受益者には依存リソース「AD」および「DB」がプロビジョニングされていないため、リクエストUIによって、リソース「Exchange」とともにリソース「AD」および「DB」のリソース詳細収集ステップが自動的に追加されます。このリクエストでは、リソース「AD」および「DB」がJaneとJohnの両方の受益者に追加されます。

- 例2: ユーザーJerryにリソースはプロビジョニングされていません。ユーザーKatieにはリソース「DB」がプロビジョニングされています。リソース「Exchange」をJerryとKatieにプロビジョニングするとします。リソースのプロビジョニング・リクエスト時に、「ユーザーの選択」ステップでJerryとKatieを選択し、「リソースの選択」ステップで「Exchange」を選択します。Jerry(受益者の1人)には依存リソース「AD」および「DB」がプロビジョニングされていないため、リクエストUIによって、リソース「Exchange」とともにリソース「AD」および「DB」のリソース詳細収集ステップが自動的に追加されます。このリクエストでは、リソース「AD」がJerryとKatieの両方の受益者に追加されます。ただし、Katieにはリソース「DB」がすでにプロビジョニングされているため、リソース「DB」はJerryにのみ追加され、Katieには追加されません。

9. 「理由」ページで、次のフィールドの値を指定し、「終了」をクリックしてリクエストを送信できます。

- 有効日: 承認後にリクエストの基礎となる操作が実行される日付を入力します。たとえば、ユーザーにラップトップをプロビジョニングする有効日として9月15日を指定した場合、リクエストが承認されても、9月15日より前にラップトップはユーザーにプロビジョニングされません。リソースは9月15日にプロビジョニングされます。リクエストが9月15より後に承認された場合、リソースは即時にプロビジョニングされます。

- 理由: リクエストを作成する理由を入力します。

1人のユーザーを選択してリソースをプロビジョニングする場合は、リクエストを承認対象にすることができます。複数のユーザーを選択してリソースをプロビジョニングする場合、リクエストは操作レベルの承認用に複数の子リクエストに分割され、各子リクエストが個別に承認または却下されます。

14.1.3 リソースをプロビジョニング解除するリクエストの作成

1つ以上のリソースをプロビジョニング解除するリクエストを作成する手順は、次のとおりです。

注意:

次のリクエスト・タイプは、リクエストの作成および実行に関して特性が類似しています。

- プロビジョニング済リソースの有効化

- プロビジョニング済リソースの無効化

- リソースのプロビジョニング解除

1. Oracle Identity Manager拡張管理の「ようこそ」ページで、「管理」の下にある「リクエストの検索」をクリックします。または、「管理」タブをクリックし、「リクエスト」をクリックします。

2. 「アクション」メニューから「リクエストの作成」を選択します。または、ツールバーにある「リクエストの作成」アイコンをクリックします。リクエストの作成ウィザードの「リクエスト・テンプレートの選択」ページが表示されます。このウィザードのステップは、第1ステップで選択するリクエスト・テンプレートに基づいて動的に生成されます。

3. 「リクエスト・テンプレート」リストから「リソースのプロビジョニング解除」を選択します。「次」をクリックします。

4. 「ユーザーの選択」ページで、ユーザーを検索します。「使用可能なユーザー」リストから、リソースをプロビジョニング解除するユーザーを1人以上選択します。「移動」をクリックして、ユーザーを「選択したユーザー」リストに移動し、「次」をクリックします。

5. 「リソースの選択」ページで、リソースを検索します。プロビジョニング解除するリソースを1つ以上選択します。「移動」をクリックして、リソースを「リソースの選択」リストに移動します。「次」をクリックします。「理由」ページが表示されます。

6. 「有効日」フィールドで、リソースをプロビジョニング解除する日付を指定します。

7. 「理由」フィールドに、プロビジョニング解除操作の理由を入力します。

8. 「終了」をクリックします。1つ以上のリソースをプロビジョニング解除するリクエストが作成されます。

注意:

「リソースの選択」ページの「リソース検索」には、「ユーザーの選択」ページで選択したユーザーにプロビジョニングされているすべてのリソースがリストされます。複数のユーザーが選択されている場合は、選択されたすべてのユーザーにプロビジョニングされている共通リソースが検索で表示されます。

14.2 リクエストの検索とトラッキング

Oracle Identity Manager管理にログインし、リクエストを検索して、リクエストのリストを表示できます。リクエストに対して単純検索および拡張検索を実行できます。また、各リクエストの詳細を表示できます。

この項には次のトピックが含まれます:

- リクエストの検索

- リクエスト詳細の表示

14.2.1 リクエストの検索

リクエストの単純検索を実行する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理にログインします。

2. 「ようこそ」ページで、「管理」の下にある「リクエストの検索」をクリックします。または、「管理」タブの下にある「リクエスト」サブタブをクリックします。

3. 左ペインで、「検索」フィールドの横にあるアイコンをクリックします。左ペインの検索結果表に使用可能なリクエストのリストが表示され、リクエストID、リクエスト・タイプ、リクエスト・ステータスなどの詳細も表示されます。リクエストは、リクエストIDおよびリクエスト・タイプに基づいてソートできます。

注意:

- リクエストIDに基づくソートは、数値ベースではなく文字列ベースです。

- 「リクエスタ」または「受益者」フィールドに基づくリクエスト検索の場合は、リクエスタまたは受益者のユーザー・ログインIDを入力します。

リクエストの拡張検索を実行する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理の「リクエスト」セクションの左ペインで、「拡張検索」をクリックします。「拡張検索」ページが表示されます。

2. 次の一致オプションのいずれかを選択します。

- すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準に一致するリクエストが検索結果に表示されます。

- いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定されたいずれかの検索基準に一致するリクエストが検索結果に表示されます。

3. フィールドに値を検索基準として指定します。各フィールドに対して、演算子(「次と等しい」、「次を含む」、「次で始まる」など)を選択します。

4. 検索基準にフィールドを含めるには、「フィールドの追加」をクリックし、リストからフィールドを選択します。「フィールドの追加」を使用して追加したフィールドのみ、「X」アイコンが表示されます。このようなフィールドを検索から破棄するには、フィールドの横にある「X」アイコンをクリックします。

5. 「検索」をクリックします。図14-1に示すように、検索結果表に、リクエストID、リクエスト・タイプ、ステータス、リクエスト日およびリクエスタに関する詳細が表示されます。リクエストは、リクエストID、リクエスト・タイプ、リクエスト・ステータスおよびリクエスト日に基づいてソートできます。

注意:

リクエストIDに基づくソートは、数値ベースではなく文字列ベースです。

図14-1 拡張検索の結果

「図14-1 拡張検索の結果」の説明

14.2.2 リクエスト詳細の表示

単純検索および拡張検索の検索結果表から、トラッキング対象のリクエストの詳細を表示できます。これを行うには、検索結果表でリクエストを選択します。「アクション」メニューから「リクエストの詳細を開く」を選択します。選択したリソースの「リクエストの詳細」ページが表示されます。

図14-1に、「リクエストの詳細」ページの「リクエスト情報」セクションのフィールドを示します。

表14-1 「リクエストの詳細」ページのフィールド

フィールド

説明

リクエストID

リクエストを一意に識別するためのID

リクエスト・タイプ

リクエストのタイプ、またはリクエストの作成のベースになるリクエスト・タイプ

ステータス

リクエストの現在のステータス

注意: 「ステータス」には、現在のリクエスト・ステータスが表示されます。ステータスが「リクエストに失敗しました」または「リクエストがエラーで完了しました」の場合はリンクが表示され、そのリンクをクリックすると失敗の理由が表示されます。

リクエスト日

リクエストの作成日付

有効日

リクエストされた操作がアクティブになる日付

リクエスタ

リクエストを作成したユーザー

受益者

リクエストが作成される対象のユーザー

理由

リクエストを作成する理由

親リクエストID

親リクエストのリクエストID(詳細が表示されているリクエストが子リクエストの場合)

注意:

「リクエストの詳細」ページで、ページの上部にある「アクション」メニューから「リクエストのクローズ」を選択して、リクエストを閉じることができます。リクエストのクローズについては、「リクエストのクローズ」を参照してください。

「リクエストの詳細」ページには、次の各タブが表示されます。

- 「リクエストされたリソース」または「ユーザー」または「リクエストされたロール」タブ

- 「リクエストのコメント」タブ

- 「リクエスト履歴」タブ

- 「承認タスク」タブ

- 「子リクエスト」タブ

14.2.2.1 「リクエストされたリソース」または「ユーザー」または「リクエストされたロール」タブ

このタブは、リクエストのタイプに応じて「リクエストの詳細」ページに表示されます。たとえば、リクエスト・タイプが「リソースのプロビジョニング」の場合は、「リクエストされたリソース」タブが「リクエストの詳細」ページに表示されます。同様に、リクエスト・タイプが「ユーザーの作成」または「ロールの割当て」の場合は、それぞれ「ユーザー」または「リクエストされたロール」タブが表示されます。

図14-2に、「リクエストされたロール」タブを示します。

図14-2 「リクエストされたロール」タブ

「図14-2 「リクエストされたロール」タブ」の説明

リソースのリクエスト・タイプに対して表示される「リクエストされたリソース」タブでは、リクエストに関連付けられたリソースの詳細を表示できます。詳細には、受益者、リソース名、およびリソースの詳細が含まれます。リソースの詳細を表示するには、特定のリソースの「詳細の表示」リンクをクリックします。図14-3に示すように、「リソースの詳細」ウィンドウが表示されます。

図14-3 「リソースの詳細」ウィンドウ

「図14-3 「リソースの詳細」ウィンドウ」の説明

14.2.2.2 「リクエストのコメント」タブ

このタブにはリクエストに付随するリクエスト・コメントが表示され、承認者がリクエストに対して操作を実行するのに役立ちます。また、このタブでは、新規コメントをリクエストに追加することもできます。コメントを追加するには:

1. 「リクエストのコメント」タブで、「アクション」メニューから「コメントの追加」を選択します。「新規コメント」ダイアログ・ボックスが表示されます。

2. 「コメント」フィールドに、リクエストのコメントを入力します。

3. 「保存」をクリックします。図14-4に示すように、コメントが追加されて「リクエストのコメント」タブに表示されます。

図14-4 「リクエストのコメント」タブ

「図14-4 「リクエストのコメント」タブ」の説明

14.2.2.3 「リクエスト履歴」タブ

このタブには、リクエストの履歴(リクエスト・ステータス、リクエストが更新された日付、リクエストの更新者など)が表示されます。

図14-5に、「リクエスト履歴」タブを示します。

図14-5 「リクエスト履歴」タブ

「図14-5 「リクエスト履歴」タブ」の説明

注意:

リクエストに対して承認者が指定されていない場合、「リクエスト履歴」タブの「更新者」列には内部ユーザーが表示されます。これはOIMINTERNALユーザーで、Oracle Identity Managerシステム・ユーザーです。リクエスト・ステータスのすべての内部更新は、内部ユーザーとして実行されます。

14.2.2.4 「承認タスク」タブ

このタブには、リクエストに関連して個人に割り当てられたタスクのステータスが表示されます。

図14-6に、「承認タスク」タブを示します。「リクエストID 82のリクエスタ・マネージャの承認」および「リクエストID 82の受益者マネージャの承認」の2つのタスクが表示されています。複数の承認者に順番に割り当てられた(つまり、割当て先1の次に割当て先2)タスクの場合、「割当て先」列には、現在、タスクが割り当てられている個人の名前のみが表示されます(タスクの順番が最後まで達した場合は、そのタスクで作業した最後の個人の名前が表示されます)。

図14-6 「承認タスク」タブ

「図14-6 「承認タスク」タブ」の説明

14.2.2.5 「子リクエスト」タブ

このタブは、バルク・リクエストまたは親リクエストに対してのみ表示されます。ここには、バルク・リクエストまたは親リクエストに対して作成された子リクエストが表示されます。

第IV部

ポリシー管理

この部では、ポリシー管理機能を使用して、Oracle Identity Manager委任管理機能について説明します。

次の章で構成されます。

- 第15章「認可ポリシーの管理」

- 第16章「アクセス・ポリシーの管理」

- 第17章「リクエスト・テンプレートの管理」

- 第18章「承認ポリシーの管理」

- 第19章「アテステーション・プロセスの管理」

15 認可ポリシーの管理

Oracle Identity Managerは、アプリケーションにおける様々な操作の実行をユーザーに許可または禁止するために、ユーザーによるアプリケーションへのアクセスを制御します。これは、Oracle Identity Managerに埋め込まれている認可エンジンによって、認可ポリシーを使用して制御されます。認可ポリシーの目的は、データ、UIおよびAPIを含む、Oracle Identity Managerアプリケーションへのユーザーのアクセスを制御することです。認可ポリシーによって、特定のアクションが許可されるかどうかが実行時に決定されます。Oracle Identity Manager内の認可要件を満たす認可ポリシーを定義できます。

以前のリリースのOracle Identity Managerでは、Oracle Identity Managerの各機能によって、その固有の認可ポリシーUIとバックエンド実装が定義および管理されます。Oracle Identity Manager 11g リリース1 (11.1.1)では、認可ポリシー管理は、管理機能として集中管理されます。Oracle Identity Managerの認可ポリシー管理と施行エンジンは現在、Oracleの業界最先端のきめ細かな権限管理製品である、Oracle Entitlements Server (OES)の埋込みバージョンに基づいています。これらの認可ポリシーによって、Oracle Identity Managerアプリケーションに対するアクセス制御が保護され、アプリケーション内で誰が何をできるかが定義されます。この集中管理された認可ポリシーの定義によって、次の各項で説明する各機能に対して、コンテキスト依存の認可が継続的に提供されます。

- 認可ポリシー

- 認可ポリシーの作成および管理

- Oracle Identity Manager機能に対する認可ポリシー

15.1 認可ポリシー

Oracle Identity Administrationの「認可ポリシー」セクションで、認可ポリシーを定義および管理できます。このセクションは、認可ポリシーの管理権限があるユーザーが使用できます。

関連項目:

ロールおよび権限の割当ての詳細は、「ロールの追加と削除」および「ロールの表示と管理」を参照してください。

次に、認可ポリシーの構造化コンポーネントを示します。

- 識別の詳細: 各認可ポリシーに名前と説明が必要です。

- Oracle Identity Manager機能: 各認可ポリシーは、Oracle Identity Managerの特定の機能に対して定義されます。機能は、ユーザー管理やロール管理など、Oracle Identity Manager内の明確に定義されたコンポーネントです。複数機能の認可要件を、単一の認可ポリシーで処理することはできません。

- 割当て先: これは、ポリシーによって権限が付与されるロール(複数の場合あり)です。各ポリシーに対して、1つ以上のロールに権限を付与できます。認可ポリシーによって、ロールのすべての(直接または継承による間接)メンバーに権限が付与されます。ユーザー管理機能の場合、マネージャ関係に基づくルールがサポートされます。この場合、処理対象のユーザーの管理チェーンに属するすべてのユーザーが認可ポリシーの割当て先です。

注意:

- ロール・メンバーシップの継承の詳細は第12章「ロールの管理」を参照してください。

- ユーザー属性に基づいてポリシーを割り当てるために、自動グループ・メンバーシップ・ルールを構成し、ポリシーをそのロールに割り当てることができます。詳細は、「メンバーシップ・ルールの表示、割当ておよび失効」を参照してください。

割当て先には、割当て先が満たす必要がある追加条件を含めることができます。これは、認可ポリシーをコンテキスト対応にする1つの方法です。たとえば、ユーザー管理機能の場合、割当て先が権限を取得するには、その割当て先が、データ・セキュリティにリストされている同じ組織のメンバーである必要があるという条件を明確に示すことができます。

- 権限: これらは、割当て先に付与される権限です。権限のリストは、このポリシーの定義対象の機能によって定義されます。たとえば、ユーザー管理機能では、ユーザーの検索、ユーザー詳細の表示、ユーザー・プロファイルの変更などの権限が定義されます。ユーザー管理機能に対する権限の完全なリストは、「権限」を参照してください。
一部の権限では、機能の中で特定のどのエンティティ属性を割当て先にさらに付与するかを定義する詳細な属性レベルのアクセス制御もサポートされます。たとえば、ユーザー詳細の表示権限の場合、ポリシーによって、割当て先が実行時にユーザー・エンティティ上のどの属性を表示できるかをさらに定義できます。属性レベルの詳細はすべての権限でサポートされるわけではありません。たとえば、ユーザーの削除権限では、属性レベルの詳細は必要なく、サポートされません。

- データ・セキュリティ: これらは、割当て先への権限付与の対象となる機能によって管理されるエンティティです。このセクションはオプションであり、認可ポリシーの定義対象である機能でデータ・セキュリティがサポートされているかどうかに基づきます。データ・セキュリティは、権限付与の対象となるエンティティの決定に使用されるエンティティ選択基準または検索基準の形式で表されます。データ・セキュリティは、特定のエンティティのリストにもできます。データ・セキュリティの機能性は、機能によって異なります。たとえば、基準によって、組織のリストに属しているユーザーに対する権限が割当て先に付与されることを指定できます。この基準では、データ・セキュリティに適用する追加のセキュリティ設定を提供できます。たとえば、ユーザー管理機能では、指定した組織とすべての子組織のユーザーがこのデータ・セキュリティ・ポリシーの範囲となるように、組織条件を下位の階層まで適用することを指示できます。

15.2 認可ポリシーの作成および管理

管理およびユーザー・コンソールを使用して、認可ポリシーに関連する次のタスクを実行できます。

- 認可ポリシーの検索

- カスタム認可ポリシーの作成

- 既存のポリシーに基づいた認可ポリシーの作成

- 認可ポリシーの表示と変更

- 認可ポリシーの削除

注意:

認可ポリシーの作成、変更または削除はすぐには有効にならず、有効になるまでに約5から10秒かかります。

15.2.1 認可ポリシーの検索

既存の認可ポリシーに対して、単純検索(クイック検索)、および拡張検索を実行できます。これらの操作については、次の各項で説明します。

- 単純検索

- 拡張検索

15.2.1.1 単純検索

認可ポリシーの単純検索を実行する手順は、次のとおりです。

1. 認可ポリシーの管理権限のある資格証明を使用して、管理コンソールにログインします。

2. 左ペインで、「認可ポリシー」タブをクリックします。

3. 参照で「ポリシー」が選択されていることを確認します。

4. テキスト・ボックスに、認可ポリシーの検索基準を入力します。たとえば、検索する認可ポリシーの名前を入力できます。また、検索基準で、すべての認可ポリシーを検索するアスタリスク(*)文字など、ワイルドカード文字を使用することもできます。

5. 検索アイコンをクリックします。検索基準にはワイルドカード文字(*)を使用できます。パフォーマンス上の理由から、先頭(接頭辞)のワイルドカードは削除されます。ただし、末尾(接頭辞)のワイルドカードはすべての検索に追加されます。

注意:

認可ポリシー検索は大文字と小文字が区別されるため、検索基準の入力時は、大/小文字が正しいことを確認する必要があります。

図15-1に、認可ポリシーの単純検索の結果を示します。

図15-1 認可ポリシーの単純検索

「図15-1 認可ポリシーの単純検索」の説明

15.2.1.2 拡張検索

認可ポリシーの拡張検索を実行する手順は、次のとおりです。

1. 「ようこそ」ページで、「認可ポリシー」の下にある「拡張検索 - 認可ポリシー」をクリックします。または、「認可ポリシー」タブをクリックして、左ペインにある「拡張検索」リンクをクリックすることもできます。「拡張検索」ページが表示されます。

2. 次のオプションのいずれかを選択します。

- すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準を満たす場合のみ検索操作が成功します。

- いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定された選択基準のいずれかに一致する場合に検索操作が成功します。

3. 「ポリシー名」フィールドに、検索する認可ポリシー名を入力します。これを行うには、「ポリシー名」フィールドの横にあるリストから検索コンパレータを選択します。デフォルトの検索コンパレータは「次を含む」です。他のかわりのコンパレータは、プルダウン・リストから使用できます。

4. 「ロール名」フィールドに、ポリシーが割り当てられているロールの名前を入力します。検索基準にはワイルドカード文字を使用できます。「ロール名」フィールドの横にあるリストから検索条件を選択します。

5. 「エンティティ・タイプ」フィールドで、認可ポリシーが定義されているエンティティ・タイプを選択します。

6. 「検索」をクリックします。図15-2に示すように、検索結果表に検索結果が表示されます。

図15-2 認可ポリシーの拡張検索

「図15-2 認可ポリシーの拡張検索」の説明

15.2.2 カスタム認可ポリシーの作成

Oracle Identity Manager管理を使用すると、次のOracle Identity Managerコンポーネントに対するカスタム認可ポリシーを作成できます。

- ユーザー管理

- ロール管理

- 認証済セルフサービス・ユーザー管理

この項では、認可ポリシーの作成について次の各トピックで説明します。

- ユーザー管理に対する認可ポリシーの作成

- ロール管理に対する認可ポリシーの作成

- 認証済ユーザー・セルフサービスに対する認可ポリシーの作成

15.2.2.1 ユーザー管理に対する認可ポリシーの作成

ユーザー管理に対するカスタム認可ポリシーを作成すると、ユーザー管理操作へのアクセスを制御できます。たとえば、特定のロールに属するユーザーが、すべてのユーザーまたは特定の組織に属するユーザーを検索できること、および選択したユーザー属性のセットを表示できることを指定できます。

ユーザー管理に対する認可ポリシーを作成する手順は、次のとおりです。

1. 管理およびユーザー・コンソールにログインし、「管理」をクリックします。

注意:

認可ポリシーを作成、変更、削除、検索するには、システム管理者ロールのメンバーである必要があります。

2. 「ようこそ」ページで、「認可ポリシー」の下にある「認可ポリシーの作成」をクリックします。または、「認可ポリシー」タブをクリックして、ツールバーにある「認可ポリシーの作成」アイコンをクリックするか、または「アクション」メニューから「作成」を選択することもできます。図15-3に示すように、ポリシーの作成ウィザードの「基本ポリシー情報」ページが表示されます。

図15-3 「基本ポリシー情報」ページ

「図15-3 「基本ポリシー情報」ページ」の説明

注意:

ポリシーの作成ウィザードの「基本ポリシー情報」ページでは、「基本ポリシー情報」、「ポリシー設定」および「確認」のノードのみがページ上部に表示されます。ウィザードの他のノードは、「エンティティ名」フィールドの選択に基づいて動的に生成されます。

3. 「ポリシー名」フィールドに、認可ポリシーの名前を入力します。

4. 「説明」フィールドに、認可ポリシーの説明を入力します。

5. ユーザー管理に対する認可ポリシーを作成するには、「エンティティ名」フィールドで「ユーザー管理」を選択します。

6. 「次」をクリックします。図15-4に示すように、「権限」ページが表示されます。

図15-4 「権限」ページ

「図15-4 「権限」ページ」の説明

このページで、認可ポリシーで有効化する権限を選択できます。

7. 「権限」表で、「有効化」列のチェック・ボックスを選択します。認可ポリシーに対してすべての権限を有効化する場合は、表の上部にある「すべての権限の有効化」を選択します。
権限が特定の属性セットでのみ使用されるようにするには、「属性の編集」をクリックできます。

8. 「次」をクリックします。図15-5に示すように、認可ポリシー・ウィザードの「データの制約」ページが表示されます。

図15-5 「データの制約」ページ

「図15-5 「データの制約」ページ」の説明

このページには、ステップ1の「エンティティ名」フィールドで選択した機能に対するオプションが表示されます。

9. 次のいずれかのオプションを選択します。

- すべてのユーザー: 認可ポリシーの作成対象としてOracle Identity Manager内のすべてのユーザーを指定するには、このオプションを選択します。

- 選択した組織のメンバーであるユーザー: 組織を指定して、そのメンバーを認可ポリシーの作成対象とするには、このオプションを選択します。

10. 「選択した組織のメンバーであるユーザー」オプションを選択した場合は、1つ以上の組織を指定する必要があります。手順は次のとおりです。

1. 「組織の追加」をクリックします。「組織の追加」ダイアログ・ボックスが表示されます。

2. 「検索」アイコンをクリックして、「使用可能な組織」リストに組織のリストを表示します。

3. 「使用可能な組織」リストから組織を1つ以上選択し、「移動」または「すべて移動」ボタンを使用して、選択した組織を「追加する組織」リストに移動します。

4. 「保存」をクリックします。選択した組織が「データの制約」ページ内の表に追加されます。

11. 「組織のセキュリティ設定」で、選択した組織の全子組織のメンバーであるユーザーに認可ポリシーを適用することを指定するには、「階層対応(すべての子組織を含める)」を選択します。

12. 「次」をクリックします。図15-6に示すように、認可ポリシー・ウィザードの「ポリシー割当て」ページが表示されます。

図15-6 「ポリシー割当て」ページ

「図15-6 「ポリシー割当て」ページ」の説明

13. 「ルールによる割当て」で、ユーザーの直接および間接マネージャを認可ポリシーに割り当てるには、「ユーザーの管理チェーン」を選択します。

14. ロールを認可ポリシーに割り当てる手順は、次のとおりです。

1. 「追加」をクリックします。「ロールの割当て」ダイアログ・ボックスが表示されます。

2. 「検索」アイコンをクリックして、「使用可能なロール」リストにロールのリストを表示します。

3. 「使用可能なロール」リストからロールを1つ以上選択し、「移動」または「すべて移動」ボタンを使用して、選択したロールを「追加する組織」リストに移動します。

4. 「保存」をクリックします。選択したロールが「割当て」ページ内の表に追加されます。

注意:

「割当て」ページ内の表からロールを削除するには、「削除」をクリックします。

15. 「割当てのセキュリティ設定」で、ポリシーが適用される同じ組織のメンバーであるユーザーに対してのみ認可ポリシーを適用することを指定するには、「割当て先はユーザーの組織のメンバーである必要があります」を選択します。

16. 「次」をクリックします。認可ポリシー・ウィザードの「確認」ページが表示され、ウィザードのステップで指定した詳細が示されます。

17. 「終了」をクリックします。認可ポリシーが作成されます。

15.2.2.2 ロール管理に対する認可ポリシーの作成

ロール管理に対するカスタム認可ポリシーを作成すると、ロール管理操作へのアクセスを制御できます。たとえば、特定のロールに属するユーザーが、ロールとロール・カテゴリを検索できること、およびすべてのロールまたは一部の選択したロールに対するロール詳細とロール・カテゴリ詳細を表示できることを指定できます。ただし、その特定のロールに属するユーザーは、他のロール管理操作の実行は許可されません。

Oracle Identity Managerロール管理機能に対する認可ポリシーを作成する手順は、次のとおりです。

1. Oracle Identity Administrationの「ようこそ」ページで、「認可ポリシー」の下にある「新規ポリシーの作成」をクリックします。または次の方法を使用できます。

- 「認可ポリシー」タブをクリックして、ツールバーにある「認可ポリシー」アイコンをクリックします。

- 「アクション」メニューから「作成」を選択します。

認可ポリシー・ウィザードの「基本ポリシー情報」ページが表示されます。

注意:

ポリシーの作成ウィザードのページは、「基本ポリシー情報」ページの「エンティティ名」の選択に基づいて動的に生成されます。

2. 「ポリシー名」フィールドに、認可ポリシーの名前を入力します。

3. 「説明」フィールドに、認可ポリシーの説明を入力します。

4. 「エンティティ名」フィールドで、割当て先に設定する認可機能に基づいて、エンティティ名を選択します。ロール管理に対する認可ポリシーを作成するには、「ロール管理」を選択します。

5. 「次」をクリックします。「権限」ページが表示されます。

6. 認可ポリシーに対して有効化する権限を選択します。すべての権限を選択するには、表の上部にある「すべての権限の有効化」を選択します。

7. 「次」をクリックします。「データの制約」ページが表示されます。

8. 次のオプションのいずれかを選択します。

- すべてのロール: すべての子ロールを含め、Oracle Identity Manager内のすべてのロールに認可ポリシーを適用することを指定する場合。

- 選択したロール: 選択したロールにのみ認可ポリシーを適用することを指定する場合。

「データの制約」ページで選択したロールは、アクションの実行対象となるロールです。

9. 「選択したロール」オプションを選択した場合は、認可ポリシーの作成対象となるロールを選択する必要があります。手順は次のとおりです。

1. 「ロールの追加」をクリックします。「ロールの割当て」ダイアログ・ボックスが表示されます。

2. 「検索」アイコンをクリックして、「使用可能なロール」リストにすべてのロールを表示します。

3. 認可ポリシーを適用するロールを選択します。

4. 「移動」または「すべて移動」ボタンを使用して、ロールを「割当て対象ロール」リストに移動します。

5. 「保存」をクリックします。選択したロールが認可ポリシー・ウィザードの「データの制約」ページに追加されます。

10. 選択したロールを「データの制約」ページから削除する手順は、次のとおりです。

1. ロールを選択し、「削除」をクリックします。確認を求めるメッセージ・ボックスが表示されます。

2. 「OK」をクリックして処理を確認します。

11. 「データの制約」ページで、「ロールのセキュリティ設定」の下にある「階層対応(すべての親ロールを含める)」を選択して、認可ポリシーが、親ロールとして追加されるロールに適用されることを指定します。

12. 「次」をクリックします。「ポリシー割当て」ページが表示されます。このページで、ステップ10および11で説明したロールを追加および削除できます。
「ポリシー割当て」ページで選択したロールは、その直接および間接メンバーがポリシーに基づいてアクションを実行するロールです。

13. 「次」をクリックします。「確認」ページが表示され、基本ポリシー情報と、権限、データの制約および割当に関する詳細が示されます。

14. 「終了」をクリックします。認可ポリシーが作成されます。

15.2.2.3 認証済ユーザー・セルフサービスに対する認可ポリシーの作成

認証済ユーザー・セルフサービスに対するカスタム認可ポリシーを作成すると、ユーザー・セルフサービス操作のアクセスを制御できます。たとえば、いくつかのセルフ・プロファイル属性をユーザーまたはユーザーのグループが変更できるようにするが、他のセルフ・プロファイル属性は変更できないようにする場合は、ユーザー・プロファイル属性のセットを変更する権限を指定してユーザー・セルフサービスに対するカスタム認可ポリシーを作成し、ロールをポリシーに割り当てます。割り当てられたロールに属しているユーザーには、認可ポリシーで指定したセルフ・プロファイル属性を変更する権限が付与されます。

認証済ユーザー・セルフサービスに対する認可ポリシーを作成する手順は、次のとおりです。

1. Oracle Identity Administrationの「ようこそ」ページで、「認可ポリシー」の下にある「新規ポリシーの作成」をクリックします。または次の方法を使用できます。

- 「認可ポリシー」タブをクリックして、ツールバーにある「認可ポリシー」アイコンをクリックします。

- 「アクション」メニューから「作成」を選択します。

認可ポリシー・ウィザードの「基本ポリシー情報」ページが表示されます。

注意:

ポリシーの作成ウィザードのページは、「基本ポリシー情報」ページの「エンティティ名」の選択に基づいて動的に生成されます。

2. 「ポリシー名」フィールドに、認可ポリシーの名前を入力します。

3. 「説明」フィールドに、認可ポリシーの説明を入力します。

4. 「エンティティ名」フィールドで、割当て先に設定する認可機能に基づいて、エンティティ名を選択します。ロール管理に対する認可ポリシーを作成するには、「セルフサービス・ユーザー管理」を選択します。

5. 「次」をクリックします。「権限」ページが表示されます。

6. 認可ポリシーに対して有効化する権限を選択します。たとえば、セルフ・プロファイルの変更をユーザーに許可する場合は、「ユーザー・プロファイルの変更」を選択します。
すべての権限を選択するには、表の上部にある「すべての権限の有効化」を選択します。

7. 属性レベルの設定がある一部の権限を変更できます。手順は次のとおりです。

1. 「ユーザー・プロファイルの変更」などの権限を選択し、ツールバーにある「属性の編集」をクリックします。「属性の設定」ウィンドウが表示され、すべてのユーザー属性のリストが示されます。

2. ユーザーに変更を許可する属性を選択し、「保存」をクリックします。

8. 「次」をクリックします。「ポリシー割当て」ページが表示され、このポリシーに割り当てられるロールを含む表が示されます。

9. ロールをポリシーに追加するには、「追加」をクリックします。または、「アクション」メニューから「追加」を選択します。
「ロールの割当て」ウィンドウが表示されます。

10. 「ロールの割当て」ウィンドウでロールを検索し、ポリシーに割り当てるロール(複数可)を選択して「追加」をクリックします。ロールがポリシー割当表に追加されます。
認可ポリシーは、割り当てられたロールのすべてのメンバーに対して有効化されます。

ポリシーからロールを削除するには、ポリシー割当表でロールを選択し、「削除」をクリックします。

11. 「次」をクリックします。「確認」ページが表示され、基本ポリシー情報と、権限、データの制約および割当に関する詳細が示されます。

12. 「終了」をクリックします。認可ポリシーが作成されます。

15.2.3 既存のポリシーに基づいた認可ポリシーの作成

Oracle Identity Managerにすでに存在している別の認可ポリシーの一般情報、権限、データの制約および割当の情報を使用して、認可ポリシーを作成できます。手順は次のとおりです。

1. 別のポリシーを作成するために、情報を使用する認可ポリシーを検索します。

2. ポリシーを選択します。「アクション」メニューから「類似作成」を選択します。認可ポリシー・ウィザードが表示されます。

3. 「基本ポリシー情報」ページで、「ポリシー名」、「説明」および「エンティティ名」の各フィールドを編集して、新しい値を指定します。

4. 「カスタム認可ポリシーの作成」の説明に従って、ステップを実行してウィザードを完了します。

15.2.4 認可ポリシーの表示と変更

認可ポリシーを表示および変更し、認可ポリシーの一般情報、権限、データの制約および割当を変更できます。手順は次のとおりです。

注意:

認可ポリシー変更用のオプションは、ポリシーに対して選択したエンティティ・タイプに基づいて動的に変わります。この手順では、ロール管理に対する認可ポリシーの例を使用します。

1. 左ペインにある管理コンソールの「認可ポリシー」タブで、認可ポリシーを検索します。検索基準に一致するポリシーが検索結果表に表示されます。

2. 認可ポリシーをクリックします。または、認可ポリシーを選択して、「アクション」メニューから「開く」を選択することもできます。認可ポリシーの詳細を表示および変更できるページが表示されます。ページの「全般」タブがデフォルトで表示され、ポリシー名、説明、エンティティ名、権限、データの制約および割当に関する詳細が示されます。

3. 「ポリシー名」および「説明」フィールドを編集して、認可ポリシー名と説明を更新します。

注意:

認可ポリシーのエンティティ名は、ポリシーの作成後は変更できません。

4. 「アクセス権」タブをクリックします。このタブで、このポリシーで有効化する権限を選択できます。これを行うには、表から権限を選択するか、または「すべての権限の有効化」を選択してすべての権限を有効化します。
一部の権限には、属性レベルの設定があります。属性レベルの設定を変更するには、「属性の編集」をクリックします。

5. 「データの制約」タブをクリックします。このタブで、この認可ポリシーに対してユーザーがメンバーである必要があるロールを変更できます。

6. 次のオプションのいずれかを選択します。

- すべてのロール: すべての子ロールを含め、Oracle Identity Manager内のすべてのロールに認可ポリシーを適用することを指定する場合。

- 選択したロール: 選択したロールにのみ認可ポリシーを適用することを指定する場合。

7. 「選択したロール」オプションを選択した場合は、認可ポリシーの作成対象となるロールを選択する必要があります。このタブで、選択したロールを削除することもできます。ロールを追加または削除するには、「ロール管理に対する認可ポリシーの作成」のステップ10または11でそれぞれ説明されているステップを実行します。

8. 「階層対応(すべての親ロールを含める)」を選択して、選択したロールのすべての親ロールが認可に対して選択される必要があることを指定します。

注意:

ステップ6から8は、ロールに対する認可ポリシーに適用されます。

9. 「割当て」タブをクリックします。このタブには、このポリシーに割り当てられるロールが表示されます。
「カスタム認可ポリシーの作成」および「ロール管理に対する認可ポリシーの作成」のステップ10または11をそれぞれ実行すると、割当を追加または削除できます。

10. 「適用」をクリックして、変更を保存します。
または、「元に戻す」をクリックして、古い値でページをリフレッシュします。

関連項目:

認可ポリシーを使用した機能の無効化または非表示の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の認可ポリシーを使用した機能へのアクセスの無効化に関する項を参照してください。

15.2.5 認可ポリシーの削除

認可ポリシーを削除する手順は、次のとおりです。

1. 管理コンソールの「認可ポリシー」タブで、削除する認可ポリシーを検索します。

2. ポリシーを選択します。「アクション」メニューから「削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。

3. 「OK」をクリックして、削除を確定します。

15.3 Oracle Identity Manager機能に対する認可ポリシー

この項では、次のOracle Identity Managementの各機能に対する認可ポリシー・コンポーネントについて説明します。

- ユーザー管理

- 認証済ユーザー・セルフサービス

- ロール管理

- 認可ポリシー管理

- ユーザー管理構成

- リコンシリエーション管理

- スケジューラ

- リクエスト・テンプレート管理

- リクエスト・テンプレートを使用したリクエスト作成

- 承認ポリシー管理

- 通知管理

- システム・プロパティ

- 診断ダッシュボード

- プラグイン

15.3.1 ユーザー管理

ユーザー管理機能に対して定義されている認可ポリシーのコンポーネント、およびデフォルト認可ポリシーについて、次の各項で説明します。

- 割当て先

- 機能セキュリティ

- データ・セキュリティ

- デフォルト認可ポリシー

関連項目:

ユーザー管理機能の詳細は、第11章「ユーザーの管理」を参照してください。

15.3.1.1 割当て先

ポリシーの割当て先には、ロールのセットを指定できます。ポリシーは、ポリシーのセットで各ロールに割り当てられます。さらに、割当て先として管理されるユーザーの管理チェーンを選択するためのルールがサポートされています。これを、管理されるユーザーの直接マネージャのみに制限する機能はありません。

「割当て先は...のメンバーである必要があります」というセキュリティ設定によって、権限付与の対象となる組織またはロールのメンバーでもあるユーザーに権限付与が制限されます。割当て先が複数の組織階層に属している場合は、少なくとも1つの組織階層と一致した場合に権限が付与される必要があります。

15.3.1.2 機能セキュリティ

ユーザー管理機能に対して、ユーザーの検索、ユーザー詳細の表示などの複数の権限が定義されています。

注意:

- ユーザーの検索権限を提供するユーザー管理ポリシーは、ユーザー詳細の表示権限も提供する必要があります。

- ユーザー管理機能に対する権限の完全なリストは、「権限」を参照してください。

次の各権限では詳細な属性レベルのアクセス制御がサポートされ、これによって、ユーザーはその操作に適用可能な特定の属性を選択できます。

- ユーザー詳細の表示

- ユーザー・プロファイルの変更

属性のリストは、ユーザー・エンティティに対して定義されている属性のリストに基づきます。

15.3.1.3 データ・セキュリティ

ユーザー管理機能の場合、データ・セキュリティは組織のリストとして定義され、その組織のメンバーに対する権限が割当て先に付与されます。認可ポリシーによって管理されるユーザーのセットは、属性フィルタリングでは指定できません。

「階層対応」オプションが選択されている場合は、データ・セキュリティの決定時に、組織およびロールの階層が考慮されます。

15.3.1.4 デフォルト認可ポリシー

ユーザー管理機能には、デフォルト認可ポリシーが2つあります。ユーザーは、これらのポリシーを変更または削除できません。ユーザーの検索権限を提供するユーザー管理ポリシーは、ユーザー詳細の表示権限も提供する必要があります。ユーザー詳細の表示権限には、「ユーザー・ログイン」、「アカウント・ステータス」、「アイデンティティ・ステータス」、「氏名」および「表示名」の各属性が含まれている必要があります。これらの属性が指定されない場合は、ユーザーが完全に表示可能または編集可能にならない場合があります。

次の表に、ユーザー管理に対するデフォルト認可ポリシーの詳細を示します。

ポリシー名

割当て先

機能セキュリティ

データ・セキュリティ

説明

ユーザー管理の管理ポリシー

システム管理者およびアイデンティティ・ユーザー管理者ロール

権限は次のとおりです。

ユーザー・パスワードの変更

ユーザーの作成

ユーザーの削除

アクセス・ポリシーの評価

OIMアカウント・ステータスの変更

ユーザー・プロファイルの変更

ユーザー・プロキシ・プロファイルの変更

ユーザー・ステータスの変更

ユーザーへのリソースのプロビジョニング

ユーザーの検索

ユーザー詳細の表示

ユーザー・リクエストの表示

注意: 「ユーザー・プロファイルの変更」および「ユーザー詳細の表示」には、関連する属性設定があります。両方の権限に対して、属性設定はすべての属性です。

すべてのユーザー組織

割当て先はユーザーの組織のメンバーである必要があります: いいえ

階層対応: はい

システム管理者またはアイデンティティ・ユーザー管理者ロールを持つユーザーが、すべてのユーザー管理アクションにアクセスできるようにします。

ユーザー管理の検索ポリシー

リクエスト・テンプレート管理者、リクエスト管理者、承認ポリシー管理者およびリコンシリエーション管理者ロール

権限は次のとおりです。

ユーザーの検索

ユーザー詳細の表示: 関連する属性設定があります。これらは次のとおりです。

表示名、名、氏名、GUID、姓、組織、ユーザー・ログイン

すべての組織

割当て先はユーザーの組織のメンバーである必要があります: いいえ

階層対応: はい

リクエスト管理者、リコンシリエーション管理者、リクエスト・テンプレート管理者または承認ポリシー管理者ロールを持つユーザーが、GUIDおよびユーザー・ログインに基づいて検索できるようにします。

ユーザー管理のすべてのユーザー・ポリシー

すべてのユーザー・ロール

権限は次のとおりです。

ユーザー詳細の表示: 関連する属性設定があります。これらは次のとおりです。

表示名、名、氏名、GUID、姓、組織、ユーザー・ログイン

すべての組織

割当て先はユーザーの組織のメンバーである必要があります: いいえ

階層対応: はい

すべてのユーザー・ロールを持つユーザーが、すべてのユーザー管理アクションにアクセスできるようにします。

管理者のユーザー管理ポリシー

すべてのユーザー・ロール

権限は次のとおりです。

ユーザーの検索

ユーザー詳細の表示

すべての組織

割当て先はユーザーの組織のメンバーである必要があります: いいえ

階層対応: はい

管理者が、自分の報告者を検索および表示できるようにします。

15.3.2 認証済ユーザー・セルフサービス

認可ポリシーは、認証済セルフサービスの次の領域を制御するために使用されます。

- プロファイル属性に対する認可

- ロール・リクエストに対する認可

- リソース・リクエストに対する認可

- プロキシに対する認可

- デフォルト認可ポリシー

関連項目:

認証済ユーザー・セルフサービス機能の詳細は、第8章「プロファイルの管理」、第9章「タスクの管理」および第10章「リクエストの管理」を参照してください。

15.3.2.1 プロファイル属性に対する認可

Oracle Identity Managerセルフサービスの「マイ・プロファイル」ページに表示される属性は、セルフサービス・ユーザー管理のOES認可ポリシーからのVIEW_USER_DETAILSおよびMODIFY_USER_DETAILS権限を使用して制御されます。複数のポリシーが適用可能な場合、ユーザーに権限が付与される属性のリストは、個々のポリシーによって決定される属性の結合です。

デフォルトでは、すべてのユーザーおよびシステム管理者ロールに、属性のセットを表示および変更する権限があります。すべてのユーザーおよびシステム管理者ロールには、次の属性を表示する権限があります。

電子メール、表示名、名、姓、ロケール、ミドル・ネーム、電話番号、タイムゾーン、ユーザー・ログイン、マネージャ、アイデンティティ・ステータス、アカウント・ステータス

すべてのユーザーおよびシステム管理者ロールには、次の属性を変更する権限があります。

電子メール、表示名、名、姓、ロケール、ミドル・ネーム、電話番号、タイムゾーン、ユーザー・ログイン

ユーザーに属性に対する表示および変更権限がある場合、その属性は、「マイ・プロファイル」ページに編集可能な状態で表示されます。属性に対する表示権限のみがある場合、その属性は読取り専用で表示されます。セルフ・プロファイルを変更するためのリクエストは、「セルフ・プロファイルの変更」リクエスト・テンプレートを使用して送信されます。このリクエスト・テンプレートに対するリクエスト・データセットは、「ユーザーの変更」リクエスト・テンプレートに対するリクエスト・データセットと同じです。

関連項目:

リクエスト・モデル、リクエスト・テンプレートおよびリクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリクエストの構成に関する項を参照してください。

ユーザーのプロファイルに追加属性を表示する手順は、次のとおりです。

1. デフォルトまたはカスタム追加属性が設定された表示または変更(あるいはその両方)のユーザー・プロファイル権限を含むカスタム・セルフサービス認可ポリシーを作成します。カスタム認可ポリシーの作成の詳細は、「カスタム認可ポリシーの作成」を参照してください。

2. カスタム認可ポリシーをすべてのユーザーおよびシステム管理者ロールに割り当てます(管理者ユーザーにはデフォルトですべてのユーザー・ロールは設定されていないため)。

3. ポリシー内のユーザー・プロファイル権限を変更するための追加属性が設定される場合は、「セルフ・プロファイルの変更」用のリクエスト・データセットを更新(つまり、ModifyUserDataset.xmlに属性を含めるように更新)します。属性が「セルフ・プロファイルの変更」ページにレンダリングされるように、データセット内のエントリが作成されます。

注意:

追加属性に表示可能プロパティが設定されていることを確認してください。

15.3.2.2 ロール・リクエストに対する認可

セルフサービス操作としてロールをリクエストおよび表示するための権限は定義されていません。ただし、ロールのリクエスト時に、ユーザーにアクセス権限があるリクエスト・テンプレートのみが表示されます。これは、リクエスト管理機能によって制御されます。リクエスト操作時のロールの検索時に、ユーザーは、ユーザーに検索および表示権限があるロールからのみ選択できます。これは、ロール管理ポリシーによって制御されます。

「ロールのリクエスト」ページのロールのリストでユーザーが使用できるロールは、リクエスト・テンプレートで提供されているロールと、ユーザーに検索権限があるロールの共通部分です。たとえば、リクエスト・テンプレートにロールRole1、Role2およびRole3があり、ユーザーにRole2とRole3の検索権限がある場合は、Role2とRole3がロールのリストに表示されます。同様に、ユーザーにRole1、Role2およびRole3に対する検索権限があり、リクエスト・テンプレートにロールRole2とRole3がある場合は、Role2とRole3がロールのリストに表示されます。

ユーザーは、検索権限があるすべてのロールをリクエストできます。これは、ロール管理で定義される一般認可ポリシーによって制御されます。ロールのリクエスト作成時に、ユーザーは、ロールを検索して選択する必要があります。

15.3.2.3 リソース・リクエストに対する認可

セルフサービス操作としてリソースをリクエストおよび表示するための権限は定義されていません。ただし、リソースをリクエストおよび表示するために、リソースのセルフ・リクエストが許可されるようにそのリソースを構成する必要があります。これを行うには、Oracle Identity Manager Design Consoleの「リソース・オブジェクト」フォームの「セルフ・リクエストを許可」オプションを選択します。

関連項目:

Oracle Identity Manager Design Consoleの「リソース・オブジェクト」フォームの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

15.3.2.4 プロキシに対する認可

プロキシ操作を追加、変更および削除するには、セルフサービス・ユーザー管理に対するデフォルト認可ポリシーの新しいMODIFY_SELF_USER_PROXY_PROFILE権限とともに、認証済セルフサービスAPIで認可チェックが必要です。認証済セルフサービスAPIによって、最初にこの権限がチェックされます。ユーザーにプロキシ操作を実行する権限がある場合は、認証済セルフサービスAPIによって、ユーザー管理用の対応するAPIがコールされます。

関連項目:

Oracle Identity Manager APIの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』を参照してください。

プロキシの追加、変更および削除を許可するには、セルフ・ユーザー・プロキシ・プロファイルの変更権限が必要です。

15.3.2.5 デフォルト認可ポリシー

次の表に、認証済セルフサービスに対するデフォルト認可ポリシーの詳細を示します。

ポリシー名

割当て先

機能セキュリティ

データ・セキュリティ

説明

ロールの自己割当て

すべてのユーザー・ロール

権限は次のとおりです。

リクエストの開始

なし

すべてのユーザー・ロールを持つユーザーが、「ロールの自己割当て」リクエスト・テンプレートにアクセスできるようにします。

リソースの自己プロビジョニング解除

すべてのユーザー・ロール

権限は次のとおりです。

リクエストの開始

なし

すべてのユーザー・ロールを持つユーザーが、「プロビジョニング済リソースの自己変更」リクエスト・テンプレートにアクセスできるようにします。

プロビジョニング済リソースの自己変更

すべてのユーザー・ロール

権限は次のとおりです。

リクエストの開始

なし

すべてのユーザー・ロールを持つユーザーが、「ロールの自己削除」リクエスト・テンプレートにアクセスできるようにします。

ロールの自己削除

すべてのユーザー・ロール

権限は次のとおりです。

リクエストの開始

なし

すべてのユーザー・ロールを持つユーザーが、「ロールの自己割当て」リクエスト・テンプレートにアクセスできるようにします。

セルフサービス・ユーザー管理のすべてのユーザー・ポリシー

すべてのユーザーおよびシステム管理者ロール

権限は次のとおりです。

セルフ・ユーザー・プロキシ・プロファイルの変更

ユーザー・プロファイルの変更: 関連する属性設定があります。これらは、「表示名」、「電子メール」、「名」、「姓」、「ロケール」、「ミドル・ネーム」、「電話番号」、「タイムゾーン」および「ユーザー名優先言語」です。

ユーザー詳細の表示: 関連する属性設定は、「アカウント・ステータス」、「表示名」、「電子メール」、「名」、「アイデンティティ・ステータス」、「姓」、「ロケール」、「マネージャ」、「ミドル・ネーム」、「パスワードの有効期限日」、「パスワードの有効期限切れ」、「パスワードの警告日」、「パスワードの警告」、「電話番号」、「タイムゾーン」、「ユーザー・ログイン」および「ユーザー名優先言語」です。

なし

すべてのユーザーが、特定のセルフサービス・ユーザー管理アクションにアクセスできるようにします。

リソースの自己リクエスト

すべてのユーザー・ロール

権限は次のとおりです。

リクエストの開始

なし

すべてのユーザー・ロールを持つユーザーが、「リソースの自己リクエスト」リクエスト・テンプレートにアクセスできるようにします。

15.3.3 ロール管理

ロール管理機能に対して定義されている認可ポリシーのコンポーネント、およびこの機能に対するデフォルト認可ポリシーについて、次の各項で説明します。

- 割当て先

- 機能セキュリティ

- データ・セキュリティ

- デフォルト認可ポリシー

関連項目:

ロール管理機能の詳細は、第12章「ロールの管理」を参照してください。

15.3.3.1 割当て先

ポリシーの割当て先には、ロールまたはロールのセットを指定できます。

15.3.3.2 機能セキュリティ

ロール管理機能に対して複数の権限が定義されています。権限では、詳細な属性レベルのアクセス制御はサポートされません。

15.3.3.3 データ・セキュリティ

ロール管理機能の場合、データ・セキュリティは、割当て先への権限付与の対象となるロールのリストとして定義されます。

「割当て先は...のメンバーである必要があります。」という条件によって、権限付与の対象となるロールのメンバーでもある割当て先に権限付与が制限されます。

「階層対応」設定によって、データ・セキュリティの決定時にロール階層が考慮されます。

15.3.3.4 デフォルト認可ポリシー

この機能に対して定義されるデフォルト認可ポリシーは、ユーザーが変更または削除することはできません。ポリシーについて次の表で説明します。

ポリシー名

割当て先

機能セキュリティ

データ・セキュリティ

説明

ロール管理の管理ポリシー

システム管理者およびロール管理者ロール

権限は次のとおりです。

ロールの作成

ロール・カテゴリの作成

ロールの削除

ロール・カテゴリの削除

ロールの変更

ロール・カテゴリの変更

ロール階層の変更

ロール・メンバーシップの変更

ロールの検索

ロール・カテゴリの検索

ロール・カテゴリ詳細の表示

ロール詳細の表示

ロール・メンバーシップの表示

すべてのロール

これは、ロール管理者およびシステム管理者ロールに関連付けられた事前定義済の認可ポリシーです。

ロール管理の「すべてのユーザー」ポリシー

すべてのユーザー・ロール

権限は次のとおりです。

ロールの検索

ロール・カテゴリの検索

ロール詳細の表示

ロール・カテゴリ詳細の表示

すべてのロール(この場合、認可はロールに属しているユーザーに適用されます)

選択したロール(この場合、この認可についてユーザーがメンバーである必要があるロールを選択できます)

これは、すべてのユーザー・ロールに関連付けられた事前定義済の認可ポリシーです。

ロール管理ロール所有者ポリシー

すべてのユーザー・ロール

権限は次のとおりです。

ロールの削除

ロールの変更

ロール階層の変更

ロール・メンバーシップの変更

ロールの検索

ロール・カテゴリの検索

ロール・カテゴリ詳細の表示

ロール詳細の表示

ロール・メンバーシップの表示

割当て先がその所有者であるすべてのロール。ユーザーがロールを作成するとき、作成されたロールを付与された個人がロール所有者になります。

これは、ロール所有者がそのロールを制御できるようにする事前定義済の認可ポリシーです。

ロール管理の承認およびリクエスト・ポリシー

承認ポリシー管理者、リクエスト・テンプレート管理者およびリクエスト管理者ロール

権限は次のとおりです。

ロールの検索

ロール・カテゴリの検索

ロール・カテゴリ詳細の表示

ロール詳細の表示

すべてのロール

これは、承認ポリシー管理者、リクエスト管理者およびリクエスト・テンプレート管理者ロールに関連付けられた事前定義済の認可ポリシーです。

ロール管理の委任管理ポリシー

ロール管理者ロール

権限は次のとおりです。

ロール・メンバーシップの変更

ロールの検索

ロール・カテゴリの検索

ロール・カテゴリ詳細の表示

ロール詳細の表示

ロール・メンバーシップの表示

すべてのロール

このポリシーを委任ロール管理者ペルソナの例として使用できます。必要な場合は、割当て先およびデータ制約を変更できます。

ロール管理の階層管理ポリシー

ロール管理者ロール

権限は次のとおりです。

ロールの変更

ロール階層の変更

ロールの検索

ロール・カテゴリの検索

ロール・カテゴリ詳細の表示

ロール詳細の表示

ロール・メンバーシップの表示

すべてのロール

このポリシーをロール階層管理者ペルソナの例として使用できます。必要な場合は、割当て先およびデータ制約を変更できます。

15.3.4 認可ポリシー管理

認可ポリシー管理機能へのアクセスは、デフォルト認可ポリシーによって制御されます。このポリシーは、システム管理者ロールに属するユーザーに、認可ポリシーの検索、およびカスタム認可ポリシーの作成、変更、削除など、認可ポリシーの操作を実行する権限を付与します。

注意:

削除または無効化アクションは機能固有のUIコードで制御され、UIコードによって、AuthorizationService APIがコールされ、そのアクションの実行をユーザーに許可するかどうかが調べられます。ユーザーに権限がある場合は、UIの左ペインの「アクション」リストで、ユーザーは「削除」または「無効化」オプションが有効化されていることを確認できます。

この機能に対するデフォルト認可ポリシーの詳細は、次のとおりです。

- ポリシー名: 認可管理の管理ポリシー

- 割当て先: システム管理者ロール

- 機能セキュリティ: サポートされている権限は次のとおりです。

- 認可ポリシーの作成

- 認可ポリシーの削除

- 認可ポリシーの変更

- 認可ポリシーの検索

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: この認可ポリシーでは、データ・セキュリティはサポートされません。認可ポリシーを管理する権限があるすべてのユーザーが、すべての認可ポリシーを管理できます。

15.3.5 ユーザー管理構成

ユーザー管理構成機能に対するデフォルト認可ポリシーは、システム管理者およびユーザー構成管理者ロールを持つユーザーが、すべてのユーザー管理構成操作にアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

ユーザー管理構成機能の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのユーザー属性の構成に関する項を参照してください。

- ポリシー名: ユーザー管理構成の管理ポリシー

- 割当て先: システム管理者およびユーザー構成管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- カテゴリの追加

- 導出属性の追加

- 属性の作成

- 属性の削除

- カテゴリの削除

- 検索属性の設定

- 検索属性の設定

- 属性の更新

- カテゴリの更新

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: なし

- 説明: このポリシーは、システム管理者またはユーザー構成管理者ロールを持つユーザーが、すべてのユーザー管理構成アクションにアクセスできるようにします。

注意:

ユーザーを作成および変更するページにすべての属性を表示する権限がユーザーにあるとき、ユーザー管理構成を介してUDFが作成されている場合は、ユーザーを作成および変更するページにUDFが表示されます。

15.3.6 リコンシリエーション管理

リコンシリエーション管理機能に対して定義されている認可ポリシーのコンポーネント、およびこの機能に対するデフォルト認可ポリシーについて、次の各項で説明します。

- 割当て先

- 機能セキュリティ

- データ・セキュリティ

- デフォルト認可ポリシー

関連項目:

リコンシリエーション機能の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのリコンシリエーション・イベントの管理に関する項、および第4章「デプロイメント構成」を参照してください。

15.3.6.1 割当て先

ポリシーの割当て先には、ロールまたはロールのセットを指定できます。

15.3.6.2 機能セキュリティ

リコンシリエーション管理機能では、認可ポリシー管理領域からの複数の権限が定義されます。これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

15.3.6.3 データ・セキュリティ

この認可ポリシーでは、データ・セキュリティはサポートされません。リコンシリエーション・イベントを管理する権限があるユーザーは、すべてのリコンシリエーション・イベントを管理できます。

15.3.6.4 デフォルト認可ポリシー

次の表に、リコンシリエーション管理機能に対するデフォルト認可ポリシーを示します。

ポリシー名

割当て先

機能セキュリティ

データ・セキュリティ

説明

リコンシリエーション管理の管理ポリシー

システム管理者およびリコンシリエーション管理者ロール

権限は次のとおりです。

割当て

バルク操作

アカウントの作成

ユーザーの作成

アカウントのリンク

ユーザーのリンク

検索

イベント詳細の表示

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

なし

リコンシリエーション管理者またはシステム管理者ロールを持つユーザーが、すべてのリコンシリエーション管理アクションにアクセスできるようにします。

リコンシリエーションAPIポリシー

システム管理者およびリコンシリエーション管理者ロール

権限は次のとおりです。

リコンシリエーション・イベントの作成

検出アカウントの削除

欠落アカウントの取得

イベントの無視

イベントのユーザー・リソースへのリンク

イベントのユーザーへのリンク

リコンシリエーション・イベントの処理

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

なし

リコンシリエーション管理者またはシステム管理者ロールを持つユーザーが、すべてのリコンシリエーション管理アクションにアクセスできるようにします。

15.3.7 スケジューラ

スケジューラ機能に対するデフォルト認可ポリシーは、システム管理者およびスケジューラ管理者ロールを持つユーザーが、すべてのスケジューラ操作にアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

スケジューラ機能の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのスケジュール済タスクの管理に関する項を参照してください。

- ポリシー名: スケジューラ管理ポリシー

- 割当て先: システム管理者およびスケジューラ管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- ジョブの作成

- ジョブの削除

- ジョブの無効化

- ジョブの有効化

- ジョブのフィルタ

- ジョブの変更

- ジョブの一時休止

- ジョブの再開

- ジョブの即時実行

- ジョブの検索

- ジョブの停止

- ステータスのリセット

- スケジューラ検索

- スケジューラの開始

- スケジューラの停止

- トリガーの作成

- トリガーの削除

- トリガーの変更

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: なし

- 説明: システム管理者またはスケジューラ管理者ロールを持つユーザーが、すべてのスケジューラ・アクションにアクセスできるようにします。

15.3.8 リクエスト・テンプレート管理

リクエスト・テンプレート管理者ロールを持つユーザーは、リクエスト・テンプレートの作成、削除、変更、検索など、リクエスト・テンプレートに関連するすべての管理操作にアクセスできます。デフォルト認可ポリシーの詳細は、「リクエスト・テンプレートを使用したリクエスト作成」を参照してください。

15.3.9 リクエスト・テンプレートを使用したリクエスト作成

各リクエスト・テンプレートをロールのセットと関連付けることができます。これらのいずれかのロールを持つユーザーのみが、このテンプレートを使用してリクエストを作成できます。新しいリクエスト・テンプレートが関連ロールのリストとともに作成されると、新しい認可ポリシーが内部的に作成されます。さらに、既存のリクエスト・テンプレートとのロール関連が変更(新しいロールの追加または既存ロールの削除)されると、このテンプレートに対する既存の認可ポリシーが変更されます。

関連項目:

リクエスト作成用のリクエスト・テンプレートの作成および管理の詳細は、第17章「リクエスト・テンプレートの管理」を参照してください。

リクエスト・テンプレートを使用したリクエスト作成に対するデフォルト認可ポリシーは、リクエスト・テンプレート管理者ロールを持つユーザーが、リクエスト・テンプレートに関連するすべての操作にアクセスできるようにします。ポリシーの詳細は次のとおりです。

- ポリシー名: リクエスト・テンプレート管理ポリシー

- 割当て先: リクエスト・テンプレート管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- 作成

- 削除

- 変更

- 検索

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: なし

- 説明: リクエスト・テンプレート管理者またはシステム管理者ロールを持つユーザーが、すべてのリクエスト・テンプレート・アクションにアクセスできるようにします。

15.3.10 承認ポリシー管理

承認ポリシー管理機能に対するデフォルト認可ポリシーは、承認ポリシー管理者ロールを持つユーザーが、すべての承認ポリシー管理操作にアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

承認ポリシー管理機能の詳細は、第18章「承認ポリシーの管理」を参照してください。

- ポリシー名: 承認ポリシー管理ポリシー

- 割当て先: 承認ポリシー管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- 作成

- 削除

- 変更

- 検索

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: なし

- 説明: 承認ポリシー管理者またはシステム管理者ロールを持つユーザーが、すべての承認ポリシー管理アクションにアクセスできるようにします。

15.3.11 通知管理

通知管理機能に対するデフォルト認可ポリシーは、通知テンプレート管理者ロールを持つユーザーが、すべての通知管理操作にアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

通知管理機能の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの通知テンプレートの管理に関する項を参照してください。

- ポリシー名: 通知管理の管理ポリシー

- 割当て先: システム管理者および通知テンプレート管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- ロケールの追加

- 作成

- 削除

- フィルタ

- 参照

- 変更

- ロケールの削除

- 検索

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データ・セキュリティ: なし

- 説明: システム管理者または通知テンプレート管理者ロールを持つユーザーが、すべての通知テンプレート管理アクションにアクセスできるようにします。

15.3.12 システム・プロパティ

システム・プロパティ機能に対するデフォルト認可ポリシーは、システム管理者およびシステム構成管理者ロールを持つユーザーが、システム・プロパティに関連するすべての操作にアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

システム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

- ポリシー名: システム・プロパティの管理ポリシー

- 割当て先: システム管理者およびシステム構成管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- 作成

- 削除

- フィルタ

- 参照

- 変更

- 検索

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データの制約: なし

- 説明: システム管理者またはシステム構成管理者ロールを持つユーザーが、すべてのシステム・プロパティ・アクションにアクセスできるようにします。

15.3.13 診断ダッシュボード

診断ダッシュボード機能に対するデフォルト認可ポリシーは、システム管理者ロールを持つユーザーが、診断ダッシュボードにアクセスできるようにします。このポリシーの詳細は次のとおりです。

関連項目:

診断ダッシュボードの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの診断ダッシュボードの使用に関する項を参照してください。

- ポリシー名: 診断ダッシュボード・ポリシー

- 割当て先: システム管理者ロール

- 機能セキュリティ: 失敗したタスクの管理権限(詳細な属性レベルのアクセス制御なし)

- データの制約: なし

- 説明: システム管理者ロールを持つユーザーが、診断ダッシュボードにアクセスできるようにします。

15.3.14 プラグイン

プラグイン機能に対するデフォルト認可ポリシーは、プラグイン管理者ロールを持つユーザーが、ポリシーを登録/登録解除できるようにします。このポリシーの詳細は次のとおりです。

関連項目:

プラグインの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプラグインの開発に関する項を参照してください。

- ポリシー名: プラグイン管理者ポリシー

- 割当て先: プラグイン管理者およびシステム管理者ロール

- 機能セキュリティ: 権限は次のとおりです。

- プラグインの登録

- プラグインの登録解除

これらの権限では、詳細な属性レベルのアクセス制御はサポートされません。

- データの制約: なし

- 説明: プラグイン管理者またはシステム管理者ロールを持つユーザーが、プラグインを登録/登録解除できるようにします。

16 アクセス・ポリシーの管理

アクセス・ポリシーとは、ロールと、ロールに対してプロビジョニングまたはプロビジョニング解除されるリソースのリストです。アクセス・ポリシーは、ユーザーへのターゲット・システムのプロビジョニングを自動化するために使用されます。これについて、次の例を使用して説明します。

あるユーザーがOracle Identity Managerで作成された複数のロールに属しています。ロールRole1には、メンバーシップ・ルールが割り当てられているとします。メンバーシップ・ルールは、"Organization Name = "Org1"など、ユーザーが属している組織に基づいて設計できます。ロールにはアクセス・ポリシーを割り当てることができます。アクセス・ポリシーでは、アクセス・ポリシーの適用時に、ロールに対してプロビジョニングまたは拒否(あるいはその両方)されるリソースが示されます。この結果、ユーザーがOrg1組織に作成された場合は、メンバーシップ・ルールが満たされ、Role1ロールがユーザーに付与されます。次に、ロールに割り当てられているアクセス・ポリシーがトリガーされ、アクセス・ポリシーに記述されているリソースがプロビジョニングまたは拒否されます。

この章では、Oracle Identity Managerでユーザーおよびリソースに対してアクセス・ポリシーを作成、使用する方法について説明します。この章には次の項目があります。

- アクセス・ポリシーで使用される用語

- アクセス・ポリシーの機能

- アクセス・ポリシーの作成

- アクセス・ポリシーの管理

- アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

16.1 アクセス・ポリシーで使用される用語

次に、アクセス・ポリシーに関連する用語を示します。

リソース

リソースは、Oracle Identity Managerのユーザーまたは組織にプロビジョニングできる、Oracle Identity Managerの論理エンティティです。たとえば、Microsoft Active Directory (AD)、Microsoft Exchange、SAP、UNIXおよびデータベースは、Oracle Identity Managerのリソースとしてモデル化されます。

リソースは、テンプレート化された定義であり、Oracle Identity Managerでプロビジョニング・プロセスと呼ばれる1つ以上のワークフローに関連付けられ、このワークフローによって、プロビジョニング、失効、有効化、無効化方法などのライフサイクル管理がモデル化されます。

リソースには、フォームと呼ばれるエンティティも関連付けられます。フォームは、リソースに関連付けられる属性の集合を表します。たとえば、ADサーバーに関連付けられるフォームには、「SAMアカウント名」、「共通名」および「ユーザー・プリンシパル名」などの属性が含まれています。フォームには、タイプ「ITリソース」の属性も含まれています(詳細は「ITリソース・タイプ」を参照)。

リソースには「複数を許可」のマークを付けることができ、この場合、ユーザーまたは組織にリソースの複数インスタンスがプロビジョニングされます。

アカウント

アカウントは、Oracle Identity Managerで作成され、ユーザーまたは組織にプロビジョニングされるリソースの実際のインスタンスです。たとえば、Exchangeサーバー上の電子メール・アカウントは、リソース・タイプExchangeのアカウント(インスタンス)です。

アカウントには、関連フォームの属性に対して特定の値があります。

ITリソース・タイプ

ITリソース・タイプは、物理ターゲットとそのすべての属性のモデル化に使用されるOracle Identity Managerの論理エンティティであり、属性には、物理コンピュータへの接続に必要な接続情報や資格証明などがあります。たとえば、ITリソース・タイプ「ADサーバー」は、実際のADサーバーをモデル化するために使用されます。

ITリソース・インスタンス

これらは、実際の物理ターゲットを表す、特定のITリソース・タイプの実際のインスタンスです。これらには、IPアドレス、ポート、ユーザー名、パスワードなど、物理ターゲットのすべての属性に対する特定の値もあります。デプロイメント内の2つの物理ADサーバーは、ITリソース・タイプ「ADサーバー」の2つのインスタンスで表されます。

アカウント識別子

アカウント識別子は、アカウントが作成される論理エンティティを一意に識別する、フォーム上の属性の集合です。この用語は、大まかにターゲットと呼ばれる場合があります。たとえば、ADサーバーの場合、アカウント識別子は、「ADサーバー」(タイプ「ITリソース」の属性)と「組織名」の組合せにできます。

通常、アカウント識別子は、タイプ「ITリソース」の属性です。

属性にアカウント識別子のマークを付けるには、「フォーム」フィールドのアカウント識別子プロパティを「True」に設定します。

16.2 アクセス・ポリシーの機能

ここでは、ポリシー・エンジンによって提供される様々な機能について次の各項で説明します。

- プロビジョニング・オプション

- ポリシーの失効

- リソースの拒否

- ポリシーの評価

- アクセス・ポリシーの優先度

- アクセス・ポリシー・データ

- アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

16.2.1 プロビジョニング・オプション

アクセス・ポリシーが適用されるたびに、次のいずれかの方法でリソースのプロビジョニングが発生します。

- リソースは、リクエストが生成されることなく、ユーザーに直接プロビジョニングされます。

- リクエストが作成され、リソースのプロビジョニングはリクエスト承認を必要とします。

管理およびユーザー・コンソールを使用して、アクセス・ポリシーをリクエスト承認ありで作成するか、リクエスト承認なしで作成するかを指定できます。

リクエストを使用するアクセス・ポリシーの場合

- アクセス・ポリシーのデフォルト・プロセス・フォームがサポートされています。つまり、アクセス・ポリシーの作成時にデフォルト・プロセス・フォームに入力されたデータが、リクエスト・データセットの移入に使用されます。

- リクエスト・データセットの必須フィールドは、次のいずれかで移入する必要があります。

- アクセス・ポリシー定義時のアクセス・ポリシーのプロセス・フォーム・デフォルト: これは、対応するリクエスト・データセットの移入にプロセス・フォームのアクセス・ポリシー・デフォルトが使用されるためです。

- リクエスト・データセットに対して定義された事前移入アダプタ。

- リクエスト・データセットのデフォルト・データ。

- アクセス・ポリシー・ベースのリクエストは、リクエスト・データベースのすべての必須フィールドが、プロセス・フォームのデフォルト、事前移入アダプタまたはリクエスト・データセットのデフォルト・データのいずれかによって移入されない場合は、作成されません。

- 特定のリソースに対してあるユーザーのリクエストがすでに作成されていて、次のいずれかのステータスではない場合、同じユーザーとリソースの組合せに対する新しいリクエストは作成されません。

- リクエストがクローズされました

- リクエストが完了しました

- リクエストが取り消されました

- リクエストに失敗しました

- テンプレート承認が却下されました

- リクエスト承認が却下されました

- 操作承認が却下されました

16.2.2 ポリシーの失効

Oracle Identity Managerのアクセス・ポリシーは、サブロールには適用されません。ポリシーは、そのアクセス・ポリシーに定義されているロールの直下のメンバーシップ・ユーザー(サブロールのメンバーではないユーザー)にのみ適用されます。ポリシーが適用されなくなった場合に、そのポリシー内のリソースを失効させるかどうかを指定できます。失効させる場合、ユーザーにポリシーが適用されなくなると、これらのリソースは、Oracle Identity Managerによりそのユーザーに対して自動的に失効されます。

16.2.3 リソースの拒否

アクセス・ポリシーの作成中には、ロールに対してプロビジョニングするリソースに加え、拒否するリソースを選択できます。プロビジョニングするリソースとして一旦選択したリソースを、後で拒否するリソースとして選択すると、そのリソースはOracle Identity Managerによりプロビジョニングするリソースのリストから削除されます。1つのロールに2つのポリシーが定義されており、一方のポリシーではプロビジョニングするように指定されているリソースが、もう一方のポリシーでは拒否するように指定されている場合、2つのポリシーの優先度に関係なく、Oracle Identity Managerではそのリソースはプロビジョニングされません。

16.2.4 ポリシーの評価

Oracle Identity Managerでは、次のようなシナリオでアクセス・ポリシーを評価できます。

- ユーザーがロールに追加、またはロールから削除された場合
そのユーザーに対するポリシーは、追加または削除の操作の一部として評価されます。

- ポリシーに更新フラグが設定されている場合
これらの評価は、アクションの直後には行われません。かわりに、ユーザー・ポリシーの評価スケジュール・タスクの次回実行時に行われます。評価は次のようなシナリオで行われます。

- 更新フラグがONに設定されるように、ポリシーの定義が更新された場合。ポリシーの評価は、該当するすべてのユーザーに対して行われます。

- ロールがポリシーの定義に追加、またはポリシーの定義から削除された場合。ポリシーの評価は、追加または削除されたロールに対してのみ行われます。

- リソースが追加または削除された場合、あるいはそのリソースに対する「適用しない場合は失効」フラグの値が変更された場合。
以前のリリースのOracle Identity Managerでは、アクセス・ポリシーで「適用しない場合は失効」オプションが選択されていて、そのポリシーが適用されなくなった場合は、アクセス・ポリシーに関連付けられているアカウントと権限(子レコード)の両方が失効します。ただし、フラグが選択されていない場合にポリシーが適用されなくなったときは、アカウントはそのまま残り、権限は失効します。したがって、権限は、ポリシーに対して設定されている「適用しない場合は失効」オプションの値に関係なく、ポリシーの適用が終了すると失効します。

Oracle Identity Manager 11g リリース1 (11.1.1)では、「適用しない場合は失効」オプションは、アカウント・レベルのみでなく権限レベルでも機能するため、オプションが選択されていない場合、権限は失効しません。この拡張が機能するには、XL.AccessPolicyRevokeIfNoLongerAppliesEnhancementシステム・プロパティの値をtrueに設定する必要があります。

XL.AccessPolicyRevokeIfNoLongerAppliesEnhancementシステム・プロパティの値がtrueの場合、「適用しない場合は失効」オプションは、「適用しなくなった場合はリソースと資格を失効」に変わります。このシステム・プロパティの値がfalseの場合、「適用しない場合は失効」オプションはそのままです。デフォルトで、両方のオプションが選択されます。このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

- ポリシー・データが更新または削除された場合。これには、親と子の両方のフォーム・データが含まれます。ポリシーの評価は、該当するすべてのユーザーに対して行われます。

16.2.5 アクセス・ポリシーの優先度

ポリシー優先度は、作成する各アクセス・ポリシーに対する一意の数値を含む数値フィールドです。数値が小さいほどアクセス・ポリシーの優先度が高くなります。たとえば、優先度に1を指定すると、ポリシーの優先度が最も高いことを意味します。Oracle Identity Manager管理およびユーザー・コンソールを使用してアクセス・ポリシーを定義する場合は、現行の最低優先度の値に必ず値1が加算され、結果の値が「優先度」フィールドに自動的に移入されます。この値を別の数値に変更すると、他のすべてのアクセス・ポリシーの優先度が再調整され、優先度の一貫性が保証されます。優先度値には次のアクションが関連付けられています。

- 入力された優先度値が1より小さい場合、その値はOracle Identity Managerにより1(最も高い優先度)に変更されます。

- 入力された優先度値がMより大きい場合(Mは現在最も低い優先度)、その値はOracle Identity ManagerによりM+1以下として指定されます。

- 2つのアクセス・ポリシーに同じ優先度値は指定できません。そのため、あるアクセス・ポリシーに既存の優先度値を割り当てた場合、それより優先度が低いポリシーはすべて、優先度が1つずつ下がることになります。

複数のアクセス・ポリシーが同じユーザーに適用されていると、競合が発生する場合があります。アクセス・ポリシーを介してユーザーにプロビジョニングされるリソースのインスタンスは1つであるため、Oracle Identity Managerでは最も優先度が高いポリシー・データが親フォームに使用されます。子フォームには、該当するポリシーすべての累積レコードが使用されます。

16.2.6 アクセス・ポリシー・データ

プロビジョニング時のリソースにプロセス・フォーム・データが提供される場合、複数の方法があります。Oracle Identity Managerに組み込まれた優先度の順序は次のとおりです。

1. フォームの定義によるデフォルト値

2. 組織のデフォルト

3. データセットからプロセス・フォームへのデータ・フローで取得された値

4. 事前移入アダプタ

5. アクセス・ポリシー・データ(ポリシーに基づいてリソースがプロビジョニングされる場合)

6. プロセス・タスクまたはエンティティ・アダプタにより更新されたデータ

指定したオプションが使用可能な場合、それ以外の使用頻度の低いオプションは無視されます。たとえば、オプション4が使用可能な場合は、オプション3、2および1は無視されます。

16.2.7 アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

以前のリリースのOracle Identity Managerでは、アクセス・ポリシーはリソース・オブジェクトに対する単一アカウントの管理にのみ使用できます。つまり、リソースをすでにユーザーにプロビジョニングしている(アカウントがターゲット・システムに作成されている)場合に、同じリソースの別のインスタンスをアクセス・ポリシーを介して同じユーザーにプロビジョニングする場合、これは以前のリリースのOracle Identity Managerでは実行できません。リソースの複数インスタンスをユーザーにプロビジョニングする機能を実行するには、Oracle Identity Manager 11g リリース1 (11.1.1)でアクセス・ポリシーを拡張する前に、Oracle Identity Managerでターゲット・システムを表すコネクタをクローンする必要があります。コネクタのクローニングは、クローンされたリソースのテスト/メンテナンス用に多数の作業を必要とする、エラーが発生しやすい処理でした。Oracle Identity Manager 11g リリース1 (11.1.1)におけるリソースの複数インスタンスのプロビジョニングに対して行われたアクセス・ポリシー拡張によって、コネクタのクローニングに要する時間と作業が節約されます。

UNIXサーバー、Active Directory(AD)サーバー、データベース、SAPまたはJD Edwardsなどのターゲット・システムは、Oracle Identity Managerでユーザーにプロビジョニングする必要がある、Oracle Identity Managerの外部システムです。ターゲット・システムは、Oracle Identity Managerでリソースと呼ばれるエンティティで表されます。ターゲット・システムがインストールされているサーバーは、Oracle Identity ManagerではITリソースで表されます。また、このターゲット・システムにアクセスするユーザーに提供されるログイン資格証明は、Oracle Identity Managerではアカウントで表されます。ユーザーは、単一のターゲット・システム上で複数のアカウントを使用できます。たとえば、1つのアカウントをサービス(管理)アカウント用、もう1つを標準アカウント用にできます。したがって、単一のターゲット・システムで同じユーザーに対して2つのアカウントが必要です。さらに、複数のUNIXサーバー、データベース・サーバー、ADサーバーなど、ターゲット・システムに別々のインスタンスを設定することが可能です。この結果、同じユーザーに対して、ターゲット・システムの各インスタンスにアカウントを作成する必要があります。実装の詳細は、「単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成」を参照してください。

Oracle Identity Manager 11g リリース1 (11.1.1)では、アクセス・ポリシーによって、同じターゲット・システム内における複数アカウントのプロビジョニング、および同じターゲット・システムの複数インスタンスにおける単一アカウントのプロビジョニングが可能です。アクセス・ポリシーの評価時およびユーザーへのリソースのプロビジョニング時に、Oracle Identity Managerによって、リソースがユーザーにすでにプロビジョニングされているかどうかがチェックされます。これは、ユーザーにプロビジョニングされたリソースのリソース・キー(OBJ_KEY)をチェックして判断されます。アクセス・ポリシーを介して複数インスタンスをプロビジョニングするには、同じリソースの複数インスタンスを識別するために、OBJ_KEYに加えて、アカウント識別子と呼ばれる別の基準が必要です。したがって、アクセス・ポリシーでは、リソース・キーとアカウント識別子がチェックされ、リソースがプロビジョニングされているかどうかが判定されます。

アカウント識別子は、同じユーザーの2つのアカウントを識別する、プロセス・フォーム上のフィールド(アカウント・データ)であり、同じターゲット・システム上または異なるターゲット・システム上に存在できます。次に例を示します。

- ユーザーJane.Doeに、2つの異なるUNIXサーバー上の2つのアカウントがプロビジョニングされている場合は、ITリソースをアカウント識別子として使用できます。

- ユーザーJohn.Doeに、同じデータベース・インスタンス上の2つのアカウントがプロビジョニングされている場合は、異なるログインIDをアカウント識別子として使用できます。

アクセス・ポリシー評価のために、プロビジョニングする必要があるリソースが複数ある場合は、単一のバルク・リクエストが作成されます。バルク・リクエストには、単一のリクエスト・レベルの承認が必要ですが、承認者が各リクエストを操作レベルで個別に承認できる複数の操作レベルの承認も必要です。

関連項目:

- バルク・リクエストの詳細は、「バルク・リクエストと子リクエスト」を参照してください。

- 様々なレベルのリクエスト承認の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認レベルに関する項を参照してください。

- 複数のターゲット・システムからデータをプロビジョニングする手順は、「アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング」を参照してください。

16.3 アクセス・ポリシーの作成

アクセス・ポリシー・ウィザードを使用して、ポリシーに定義されているロールがあるユーザーに、リソースをプロビジョニングするためのアクセス・ポリシーを定義できます。

アクセス・ポリシーを作成するには、次の手順を実行します。

1. Oracle Identity Manager管理およびユーザー・コンソールにログインし、拡張管理にナビゲートします。

2. 「アクセス・ポリシーの作成」ページを開くには、「ポリシー」の下にある「アクセス・ポリシーの作成」をクリックします。

3. アクセス・ポリシー名や説明など、アスタリスク(*)で示されている必須フィールドに情報を入力します。

注意:

次の特殊文字はアクセス・ポリシー名で使用できません。

セミコロン(;)

ハッシュ(#)

パーセンテージ(%)

等しい(=)

バー(|)

プラス(+)

カンマ(,)

スラッシュ(/)

円記号(¥)

一重引用符(')

二重引用符(")

小なり記号(<)

大なり記号(>)

4. 「プロビジョニング」フィールドで、次のいずれかのオプションを選択します。

- 承認なし: このオプションを選択すると、リクエスト承認なしのアクセス・ポリシーが作成されます。リソースは、リクエストが生成されることなく、ユーザーに直接プロビジョニングされます。

- 承認あり: このオプションを選択すると、リクエスト承認ありのアクセス・ポリシーが作成されます。アクセス・ポリシーの作成時に、リクエストが作成され、リソースのプロビジョニングはリクエスト承認を必要とします。

5. アクセス・ポリシーの作成時に更新するようにするには、「アクセス・ポリシーの更新」を選択します。

注意:

「アクセス・ポリシーの更新」を選択した場合、アクセス・ポリシーは、この手順のステップ13で選択するすべての既存ロールに適用されます。

このオプションを選択しない場合、既存のロール・メンバーシップは考慮されません。

6. 「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ2: リソースの選択(プロビジョニング)」ページが表示されます。

7. このアクセス・ポリシーに対してプロビジョニングするリソースを指定します。
フィルタ検索のメニューを使用してリソースを検索します。

- 結果表からリソース名を選択して、「追加」をクリックします。

- プロビジョニングする目的のリソースの名前が「選択済」リストに表示されます。リソースを拒否するだけのアクセス・ポリシーを作成する場合は、リソースを選択しないで「続行」をクリックします。

- 選択されているリソースの割当てを解除するには、「選択済」リストでリソースを選択し、「削除」をクリックします。

8. 「続行」をクリックします。
このリソースに関連付けられたフォームがある場合は、後続のページに必須フィールドが表示されます。それ以外の場合は、「アクセス・ポリシーの作成 - ステップ2: 失効するリソースの選択」ページが表示されます。パスワードおよび暗号化された属性に対しては、ポリシーのデフォルトを指定しないことをお薦めします。

9. 適用されなくなったアクセス・ポリシーを失効させるかどうかを指定します。
結果表で、自動的に失効させるリソースのチェック・ボックスを選択します。

10. 「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ3: リソースの選択(拒否)」ページが表示されます。

11. このページを使用して、このアクセス・ポリシーにより拒否されるリソースを選択します。
拒否されるリソースを選択するには、次の手順を実行します。

1. 結果表からリソースを選択します。

2. 「選択済」リストにリソースを移動するには、「追加」をクリックします。
プロビジョニングするリソースを選択しなかった場合は、拒否するリソースを少なくとも1つ選択する必要があります。プロビジョニングするものと同じリソースを拒否対象に選択すると、プロビジョニングするリソースとしての割当ては解除されます。

同様に、ステップaで、すでに拒否するように選択したものと同じリソースをプロビジョニング対象に割り当てると、拒否対象に選択されたリソースから自動的に削除されます。拒否対象として選択済のリソースを削除できます。これは、「選択済」リストから削除するリソースを選択し、「削除」をクリックして実行します。

3. 「続行」をクリックします。

「アクセス・ポリシーの作成 - ステップ4: ロールの選択」ページが表示されます。

12. 「アクセス・ポリシーの作成 - ステップ4: グループの選択」ページを使用して、グループをアクセス・ポリシーに関連付けます。

13. ロールをこのアクセス・ポリシーに関連付ける方法は、次のとおりです。

- 結果表からロールを選択して、「追加」をクリックします。少なくとも1つのロールを選択する必要があります。選択したロールの名前が、「選択済」リストに表示されます。

- ロール名を削除するには、「削除」をクリックします。

14. 「続行」をクリックします。
「アクセス・ポリシーの作成 - ステップ5: アクセス・ポリシー情報の検証」ページが表示されます。

15. この手順のこれより前のステップで選択した内容を変更する場合は、「変更」をクリックして、ウィザードの対応するページに移動します。必要な変更が終了したら、「続行」をクリックして、「ステップ5: アクセス・ポリシー情報の検証」ページに戻ります。

16. 「アクセス・ポリシーの作成」をクリックして、アクセス・ポリシーを作成します。

注意:

プロセス・フォームに「パスワード」フィールドが含まれているリソースにアクセス・ポリシーを作成した場合、パスワード・ポリシーは評価されません。パスワード・ポリシーの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。

16.4 アクセス・ポリシーの管理

Oracle Identity Manager管理およびユーザー・コンソールを使用すると、既存のアクセス・ポリシーの情報を変更できます。

アクセス・ポリシーを管理するには、次の手順を実行します。

1. 「ポリシー」メニューの下の「アクセス・ポリシーの管理」をクリックします。
「アクセス・ポリシーの管理」ページが表示されます。

検索基準フィールドのメニューを使用して、アクセス・ポリシー属性を選択します。アスタリスク(*)ワイルドカード文字を使用すると、選択した属性に任意の値を持つすべてのアクセス・ポリシー・インスタンスを検索できます。「アクセス・ポリシーの検索」をクリックします。

「アクセス・ポリシーの管理」ページに検索結果が表示されます。

2. 目的のアクセス・ポリシーの詳細を表示するには、「アクセス・ポリシー名」をクリックします。
「アクセス・ポリシー詳細」ページが表示されます。

このアクセス・ポリシーを変更するには、各選択カテゴリの末尾にある「変更」リンクを使用します。

3. 必要な変更が終了したら、「アクセス・ポリシーの更新」をクリックします。
このアクセス・ポリシーが更新され、更新された情報が「アクセス・ポリシー詳細」ページに表示されます。

16.5 アクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング

アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニングの内容は、次のとおりです。

- 単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成

- 複数アカウント・プロビジョニングの有効化

- 複数ターゲット・システムへのリソースの複数インスタンスのプロビジョニング

- アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングの制限

16.5.1 単一ターゲット・システムにおける同じユーザーおよび同じリソースに対する個別アカウントの作成

アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。たとえば、単一のADインスタンス上に、ユーザー・アカウントとサービス・アカウントの2つのアカウントを作成する必要があるとします。Active Directoryターゲット・システムは、Oracle Identity ManagerではADユーザー・リソースで表されます。これは、次の方法で実装されます。

1. ADユーザー・リソースを作成します。

2. JohnDなどのユーザーを作成します。

3. プロセス・フォームで、UD_ADUSERとUD_ADUSER_UIDに識別子フィールドのマークを付けて、2つの異なるアカウントに別々のログインIDが設定されるようにします。

4. 2つのアクセス・ポリシーを次のように作成します。

- 標準アカウント用
アクセス・ポリシー名: AP1

関連付けられるロール: Role1

プロビジョニングするリソース: ADユーザー

識別子フィールドを設定するプロセス・フォーム: ユーザーID(UD_ADUSER_UID)

アクセス・ポリシーのデフォルト値: Account1

- サービス・アカウント用
アクセス・ポリシー名: AP2

関連付けられるロール: Role2

プロビジョニングするリソース: ADユーザー

識別子フィールドを設定するプロセス・フォーム: ユーザーID(UD_ADUSER_UID)

アクセス・ポリシーのデフォルト値: Account2

注意:

「ユーザーID」に対する値を生成するためにデータセットと関連付ける事前移入アダプタを作成して、このフィールドに一意の値が生成されるようにする必要があります。

5. Role1とRole2をJohnDに割り当てます。
Role1がJohnDに割り当てられると、AP1アクセス・ポリシーを介して、Account1アカウントがADユーザー・ターゲット・システムに作成されます。Role2がJohnDに割り当てられると、AP2を介して、Account2アカウントがADユーザーに作成されます。この結果、アクセス・ポリシーを介して、単一ターゲット・システム上に同じユーザーおよび同じリソースに対する2つの異なるアカウントを作成できます。

16.5.2 複数アカウント・プロビジョニングの有効化

デフォルトでは、Oracle Identity Managerで複数アカウント・プロビジョニングはサポートされていません。複数アカウント・プロビジョニングを有効化する手順は、次のとおりです。

1. XL.AccessPolicyMultipleResourceEnhancementシステム・プロパティの値をTRUEに設定します。
このシステム・プロパティの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドの事前定義システム・プロパティに関する項を参照してください。システム・プロパティの値の設定に関する詳細は、同じガイドのシステム・プロパティの作成と管理に関する項を参照してください。

2. システム・プロパティの変更を有効にするために、Oracle Identity Managerを再起動します。

複数アカウント・プロビジョニングが有効化されている場合は、適切なアカウント識別子属性を定義する必要があります。手順は次のとおりです。

1. Design Consoleにログインします。

2. プロセス・フォームを次のように更新します。

1. 「開発ツール」を開き、「フォーム・デザイナ」をダブルクリックします。

2. プロセス・フォームを検索して開きます。

3. 「Form Designer」タブで、「Create New Version」をクリックします。

4. 「Create a New Version」ダイアログ・ボックスで、「Label」フィールドにラベルを入力して「Save」をクリックします。

5. 「Current Version」リストから、作成したバージョンを選択します。

6. 「Properties」タブで、識別子フィールドとして指定するフィールドを選択して「Add Property」をクリックします。

7. 「Add Property」ダイアログ・ボックスで、プロパティ名として「Account Discriminator」を選択し、「Property Value」フィールドに「True」と入力して「Save」をクリックします。

8. 「Make Version Active」をクリックし、「OK」をクリックします。

9. 「Save」をクリックします。

3. 既存のプロセス・フォームを変更した場合は、フォーム・バージョン制御(FVC)ユーティリティを実行します。FVCユーティリティの実行の詳細は、「フォーム・バージョン制御ユーティリティの使用」を参照してください。

16.5.3 複数ターゲット・システムへのリソースの複数インスタンスのプロビジョニング

次に、アクセス・ポリシーを介して、リソース・オブジェクトの複数インスタンスを複数ターゲット・システムにプロビジョニングする手順の概要を示します。

1. Oracle Identity Manager Design Consoleで、「ITリソース・タイプ定義」フォームを使用して、ITリソース・タイプを作成します。このフォームの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の「ITリソース・タイプ定義」フォームに関する項を参照してください。

2. ステップ1で作成したITリソース・タイプのITリソース・インスタンスを複数作成します。ITリソースの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のITリソースの作成に関する項を参照してください。
ここで、ITリソース・インスタンスはアカウント識別子です。アカウント識別子の詳細は、「アカウント識別子の使用によるアクセス・ポリシーを介した同じリソースの複数インスタンスのプロビジョニング」を参照してください。

3. ステップ1で作成したタイプのフィールドを含むプロセス・フォームを作成します。プロセス・フォームの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプロセス・フォームの開発に関する項を参照してください。

4. リソース・オブジェクトを作成します。リソース・オブジェクトの作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリソース・オブジェクトの作成に関する項を参照してください。

5. プロセス定義を作成し、リソース・オブジェクトとプロセス・フォームを関連付けます。プロセス定義の作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のプロセス定義の作成に関する項を参照してください。

6. ロールとリソース・オブジェクトを関連付けるアクセス・ポリシーを作成します。詳細は、「アクセス・ポリシーの作成」を参照してください。

異なる物理サーバー上に同じリソースのインスタンスが2つある場合は、アクセス・ポリシーを使用して、リソースの両方のインスタンスを同じユーザーであるJohnDにプロビジョニングできます。これについて、次のシナリオを使用して説明します。

2つのADインスタンスがあり、1つはIPが10.151.14.82のサーバーで管理され、もう1つはIPが130.35.66.254のサーバーで管理されています。アクセス・ポリシー・ベースのプロビジョニングを介して、ユーザーには両方のインスタンスがプロビジョニングされます。この手順は、次のとおりです。

1. ADユーザー・リソースを作成します。

2. IPアドレスが10.151.14.82のサーバーを表す、ADServer1という名前のITリソースを作成します。

3. IPアドレスが130.35.66.254のサーバーを表す、ADServer2という名前のITリソースを作成します。

4. 「ADサーバー」(UD_ADUSER_AD)プロセス・フォーム・フィールドに、識別子フィールドのマークを付けます。

5. 2つのアクセス・ポリシーを次のように作成します。

- ADServer1で作成されるアカウント用
アクセス・ポリシー名: AP3

関連付けられるロール: Role3

プロビジョニングするリソース: ADユーザー

識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_AD)

ITResourceLookupフィールドのデフォルト値: ADServer1

- ADServer2で作成されるアカウント用
アクセス・ポリシー名: AP4

関連付けられるロール: Role4

プロビジョニングするリソース: ADユーザー

識別子フィールドを設定するプロセス・フォーム: ADサーバー(UD_ADUSER_AD)

ITResourceLookupフィールドのデフォルト値: ADServer2

6. Role3とRole4をユーザーJohnDに割り当てます。
Role3がJohnDに割り当てられると、AP3アクセス・ポリシーを介して、アカウントがADServer1上のターゲット・システムに作成されます。Role4がJohnDに割り当てられると、AP4アクセス・ポリシーを介して、アカウントがADServer2上のターゲット・システムに作成されます。この結果、アクセス・ポリシーを介して、ターゲット・システムの2つの異なるインスタンス上に、同じユーザーおよび同じリソースに対する2つの異なるアカウントが作成されます。

16.5.4 アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングの制限

アクセス・ポリシーを介したリソースの複数インスタンスのプロビジョニングには、次の制限があります。

- 単一のアクセス・ポリシーで、リソースの複数インスタンスをユーザーにプロビジョニングすることはできません。リソースの複数インスタンスをプロビジョニングするには、複数のアクセス・ポリシーを作成する必要があります。プロビジョニングする同じリソースのインスタンスと同じ数のアクセス・ポリシーを作成する必要があります。

- リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがある場合は、これらのフィールドの値を、そのリソースをプロビジョニングするアクセス・ポリシーで指定する必要があります。これを実行しないと、ポリシーが次回評価されるときに複数のアカウントがプロビジョニングされるなど、不確定な動作が発生する可能性があります。

- リソース・オブジェクトに、アカウント識別子フィールドとマークされているフィールドを含むプロセス・フォームがあり、アクセス・ポリシー・エンジンを使用してこのリソースを1人以上のユーザーにプロビジョニングする場合、アカウント識別子フィールドの値は、アカウントのライフサイクルを通じて一定のままである必要があります。つまり、アカウント識別子フィールドの値は変更しないでください。これは、アクセス・ポリシー・エンジンで、新しいアカウントをユーザーにプロビジョニングするかどうかを決定するために、リソース・オブジェクト・キーおよびアカウント識別子の値が使用されるためです。
アカウント識別子の値を変更すると、プロビジョニングの決定が行われる基礎を変更することになるため、アクセス・ポリシー・エンジンの動作が不確定になります。したがって、アカウント識別子の値は変更しないことをお薦めします。また、アカウント識別子フィールドのプロセス・フォームの値は変更しないでください。

- アクセス・ポリシーが異なるアカウント識別子の値で構成されている場合は、異なるアカウントがユーザーにプロビジョニングされます。このタイプのリソース・オブジェクトでは、「複数を許可」フラグが設定されている必要があります。それ以外の場合、プロビジョニングは失敗します。

注意:

大文字/小文字のみが異なるアカウント識別子の値(例: abcとaBc)も異なる値として処理されます。このデータの場合、2つのアカウントがエンド・ユーザーにプロビジョニングされます。

次のシナリオについて考えてみます。2つのアクセス・ポリシーで、同じアカウント識別子データがある同じリソースをプロビジョニングしています。ポリシーは、リクエストを介して適用されます。

これらの2つのポリシーはユーザーに適用され、ユーザーに対して再評価されます。この場合、1つのリソースのみがリクエストを介してユーザーにプロビジョニングされます。今度は、リクエスト承認が進行中であるとします。その間に、これらの2つのポリシーの優先度が交換され、優先度の高いポリシーが優先度の低いポリシーになり、もう一方が優先度の高いポリシーになるとします。リクエストが進行している間に、ポリシーがユーザーに対して再評価される場合は、同じリソースをプロビジョニングする2番目のリクエストが作成されますが、これは現在の高い優先度のポリシーによって行われます。この問題は、現在ポリシー・エンジンによって処理されません。この問題を回避するには、(リクエストを介する場合は特に)リソースをプロビジョニングするアクセス・ポリシーの優先度を変更する前に、特定のリソースに対する保留中のすべてのリクエストが承認または却下されていることを確認する必要があります。

17 リクエスト・テンプレートの管理

リクエスト・テンプレートを使用して、目的のリクエスト・タイプをカスタマイズできます。つまり、UIの様々な機能を制御することで、リクエストの属性を制御できます。たとえば、全契約社員に対してユーザー作成のリクエストを作成し、特定の値が設定された属性を指定する場合は、「ユーザーの作成」リクエスト・タイプをカスタマイズして、リクエストのカスタマイズが可能なリクエスト・テンプレートを作成できます。リクエスト・テンプレートを作成することで、全従業員に「XYZ Inc.」という組織を適用したり、契約社員すべてのユーザー・タイプが「パート従業員」となるように指定できます。

リクエスト作成用テンプレートに対するアクセス権は、テンプレートに定義されたロール割当てに基づきます。リクエスト・テンプレートの作成後、そのテンプレートを使用できるのは、テンプレートに割り当てられているロールを持つユーザーのみです。

デフォルトのテンプレートは、各リクエスト・タイプにあらかじめ定義されています。これらの事前定義テンプレートを削除したり、名前を変更することはできません。これらの事前定義テンプレートには、対応するモデルと同じ名前が指定されています。

リクエスト・テンプレートは、次の目的に使用できます。

- テンプレート・レベル承認の追加: テンプレートの作成時に、リクエスト・レベルおよび操作レベルとは別に、その他の承認レベルを追加できます。

- 制限の追加: 次のことができます。

- エンティティ制限の追加: リクエスト・テンプレートを使用して選択できるエンティティ・タイプの制限を指定できます。たとえば、「リソースのプロビジョニング」というリクエスト・タイプのテンプレートでは、このテンプレートを使用して選択できる有効なリソースの数を指定できるとします。これにより、汎用リクエストの場合に、テンプレートの使用を特定のタイプのエンティティに制限します。たとえば、プロビジョニング・リクエスト・タイプについて定義されたテンプレートでは、このテンプレートをActive Directory、ExchangeおよびUNIXのリソースにのみ使用するように指定できます。

注意:

テンプレートでエンティティ・タイプが制限されていない場合は、このテンプレートを使用してリクエストを作成する際、使用可能なすべてのエンティティ・タイプがリクエスタに表示されます。

一方、リクエスト・ライフサイクルの様々なフェーズで収集されるデータは、リクエスト・データセットによって制御されます。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

- 属性のデータ値の制限: 属性に単一の値を指定すると、属性のそのデフォルト値が設定され、その属性はUIに表示されません。複数の値を指定すると、値は値リスト(LOV)としてユーザーに表示され、ユーザーはこのリストから値を選択できます。
属性の制限は、次のタイプになります。

- リクエスト・テンプレートで、属性に単一のデフォルト値を指定します。このテンプレートを使用してリクエストを作成している間、この属性はリクエスタに表示されません。この属性および対応する値は、リクエスト・データに自動的に設定されます。

- リクエスト・テンプレートで、複数の値を使用して属性を制限します。このような複数の値を指定すると、値は値リスト(LOV)として表示され、このテンプレートを使用してリクエストを作成するときに、リクエスタはこのリストから値を選択できます。

- 「ユーザーがこの属性の値を入力できないようにします」オプションを選択することで、リクエスト・テンプレートで、値を使用せずに属性を制限します。このタイプの制限は、必須以外の属性に対してのみ使用できます。この制限では、このテンプレートを使用してリクエストを作成している間、この属性はリクエスタに表示されません。この属性は、リクエスト・データの要素ではなくなります。

- その他のデータ収集属性の追加: これらの属性はエンティティには関連付けられません。このメカニズムを使用して収集されたデータは、リクエストの実行時には使用できません。ただし、レポート目的、リクエストの検証、および送信後データ・アクション・ハンドラに使用できます。
その他のデータ収集ステップで、リクエスト作成時にリクエスタに表示されるリクエスト・テンプレートに新しい属性を定義できます。これらの属性は、このテンプレートに固有で、エンティティには関連付けられません。

- エンド・ユーザーの使用を制限するためのテンプレートへのロールの割当て: テンプレートに対して適切なロールが割り当てられているメンバーのみが、そのテンプレートを使用してリクエストを作成できます。

要約すると、リクエスト・テンプレートを使用して、次のことができます。

- 制限されたエンティティ・タイプを指定できます。

- エンティティに対するリクエストの一部としての収集が不要な制限された属性を指定できます。

- 属性を単一の値または値リストに制限できます。単一の値のみを指定すると、リクエストの送信時に、その属性はリクエスタには表示されません。値リストを指定した場合は、リクエスタが値リストから単一の値を選択する必要があります。

- その他のデータ収集属性を指定できます。

- エンド・ユーザーによる使用を制限するために、ロールをテンプレートに割り当てることができます。

テンプレート管理サービスでは、誰がどのような操作を実行できるかを判断するために、Oracle Entitlements Server (OES)を内部的に使用します。リクエスト・テンプレート認可のOESポリシーにより、リクエスト・テンプレート管理者ロールを持つユーザーにのみ、リクエスト・テンプレートの作成またはクローン、検索、変更および削除を認可するように指定されます。リクエスト・テンプレートの認可ポリシーの詳細は、「リクエスト・テンプレートを使用したリクエスト作成」を参照してください。

このセクションのトピックは次のとおりです:

- リクエスト・テンプレートの作成

- リクエスト・テンプレートの検索と変更

- テンプレートのクローニング

- テンプレートの削除

17.1 リクエスト・テンプレートの作成

リクエスト・テンプレート管理者ロールに属しているユーザーは、リクエスト管理のUIでリクエスト・テンプレートの作成ウィザードを使用してリクエスト・テンプレートを作成できます。ウィザードの各ステップは、第1ステップでのリクエスト・タイプの選択と、リソース・ベースのリクエスト・タイプに対するリソースの選択に基づいて動的に生成されます。

リクエスト・テンプレートの作成について、次のシナリオを使用して説明します。

- 「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

- 「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

17.1.1 「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

「ユーザーの作成」リクエスト・タイプに基づいてリクエスト・テンプレートを作成する手順は、次のとおりです。

1. リクエスト・テンプレートを作成する権限のある資格証明を使用して、Oracle Identity Manager管理およびユーザー・コンソールにログインします。

注意:

リクエスト・テンプレート管理者ロールのメンバーであるユーザーは、リクエスト・テンプレートを作成できます。適切なロールがユーザーに割り当てられていない場合、ユーザーはリクエスト・テンプレートを作成するために必要なUIオプションを使用できません。

2. 「拡張」をクリックして、Oracle Identity Manager拡張管理を開きます。

3. 「構成」タブをクリックし、次に「リクエスト・テンプレート」をクリックします。または、「ようこそ」ページの「構成」の下にある「リクエスト・テンプレートの検索」リンクをクリックします。

4. 左ペインの「アクション」メニューから、「作成」を選択します。または、ツールバーにある「リクエスト・テンプレートの作成」アイコンをクリックします。リクエスト・テンプレートの作成ウィザードの「リクエスト・テンプレートの詳細の設定」ページが表示されます。

5. 次のフィールドに値を入力し、「次」をクリックします。

- リクエスト・テンプレート名: 作成するテンプレートの名前を入力します(例: 契約者の作成)。

- リクエスト・タイプ: リクエスト・テンプレートを作成するリクエストのタイプを選択します(例: ユーザーの作成)。

- 説明: 作成しているリクエスト・テンプレートの説明を入力します。

- テンプレート・レベルの承認プロセス: 「ユーザーの作成」リクエストに承認プロセスを指定する場合は、承認ワークフロー名を指定します。これは、リクエスト・レベルの承認と操作レベルの承認に加え、テンプレート・レベルの承認です。契約社員のユーザーを作成する場合は、すべての契約社員の採用について責任を負う人事担当者が、ユーザーの作成を承認する必要があることを指定できます。承認レベルの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認レベルに関する項を参照してください。

関連項目:

デフォルトの承認プロセスの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の第25章「ワークフローの構成」を参照してください。

図17-1に、リクエスト・テンプレートの作成ウィザードの「リクエスト・テンプレートの詳細の設定」ページを示します。

図17-1 「リクエスト・テンプレートの詳細の設定」ページ

「図17-1 「リクエスト・テンプレートの詳細の設定」ページ」の説明

6. 「制限する属性の選択」ページで、ユーザーが値を入力できるようにする「ユーザーの作成」タイプの属性を選択します。リクエスト・テンプレートによって制限された属性は、ユーザーに表示されないか、事前定義のLOVでのみ選択できます。ユーザーは値を入力できません。図17-2に、「制限する属性の選択」ページを示します。

図17-2 「制限する属性の選択」ページ

「図17-2 「制限する属性の選択」ページ」の説明

このページには、「ユーザーの作成」リクエスト・タイプのデータセットに基づいて属性が表示されます。「ユーザーの作成」リクエスト・テンプレートを使用してリクエストが作成される場合は、これらのデフォルトの属性すべてに値を指定できます。これらの属性の一部を制限する場合や、いくつかの属性の値をリクエスタが入力するようにする場合は、このページでその属性を選択できます。たとえば、「ミドル・ネーム」属性に値を指定する必要がある場合は、この属性を選択できます。この例では、「ミドル・ネーム」、「組織」、「ユーザー・タイプ」、「ユーザー・マネージャ」および「国」属性を選択できます。

注意:

- データセット属性がPrePopulationAdapterで構成される場合も、リクエスト・テンプレートで属性を制限できます。この場合、事前移入は発生せず、テンプレートで制限されている値は「リクエスト作成」のUIに表示されます。したがって、属性に事前移入が必要な場合は、テンプレートで制限しないようにする必要があります。

- この項で前述したように、ウィザードの各ステップは、リクエスト・タイプと、リソース・ベースのリクエスト・タイプに対するリソースの選択に基づいて動的に生成されます。ステップは、タブの上部に表示されます。

7. 「属性制限の設定」ページで、「制限する属性の選択」ページで選択した属性に対する制限を指定します。制限を指定する手順は、次のとおりです。

注意:

このステップは、対応するリクエスト・データセットに属性が指定されている場合にのみ生成されます。

1. 「ユーザー・ログイン」属性に、次のいずれかを選択します。
- ユーザーがこの属性の値を入力できないようにします: ユーザーが属性に値を入力できないようにする場合は、このオプションを選択します。このオプションを選択すると、ユーザーを作成するときに属性はUIに表示されません。必須属性には値を指定する必要があるため、このオプションは必須属性に対しては表示されません。

- この属性を次の値に制限します: 属性に1つ以上の値を指定する場合は、このオプションを選択します。たとえば、「部門番号」属性に「ソフトウェア・エンジニアリング」などの値を指定すると、属性のデフォルト値は「ソフトウェア・エンジニアリング」に設定され、このテンプレートを使用してリクエストを作成する場合に、属性はUIに表示されません。また、「+」(プラス)アイコンを使用することで、属性に複数の値を指定できます。複数の値を指定すると、このテンプレートを使用してリクエストを作成するときに、値がLOVとしてユーザーに表示され、ユーザーはLOVから値を選択できます。

ヒント:

「部門番号」属性は、リクエスト・データセットにテキスト・ボックスとして指定されているため、これらのオプションはこの属性には表示されません。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

2. 「組織」属性に1つ以上の値を指定します。これを行うには、「組織」フィールドの横にある検索アイコンをクリックし、「使用可能な組織」リストから組織名を1つ以上選択して、「移動」ボタンをクリックします。

ヒント:

「組織」属性は、リクエスト・データセットにエンティティとして指定されているため、既存の組織名を検索して値を選択する必要があるフィールドとして表示されます。組織はOracle Identity Managerで作成されるため、これは動的LOVです。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のリクエスト・データセットに関する項を参照してください。

3. 「ユーザー・タイプ」属性の値を指定します。これを行うには、使用可能なユーザー・タイプ・リストから値を1つ以上選択し、「移動」ボタンをクリックします。

ヒント:

「ユーザー・タイプ」属性は、リクエスト・データセットに静的LOVとして指定されているため、静的LOVとして表示されます。ユーザーは使用可能なユーザー・タイプから選択する必要があり、新規ユーザー・タイプを作成できないため、これは静的LOVです。リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

4. 「ユーザー・マネージャ」属性と「国」属性の値を指定し、「次」をクリックします。
図17-3に、「属性制限の設定」ページを示します。

図17-3 「属性制限の設定」ページ

「図17-3 「属性制限の設定」ページ」の説明

注意:

ステップ5、6および7は、すべてのリクエスト・テンプレートの作成に共通です。

8. 「追加属性の設定」ページで、属性に関する追加の情報を指定できます。これらの情報は、作成しているテンプレートに基づいて収集する必要がありますが、エンティティ・マッピングには使用されません。

注意:

追加の属性データはリクエスト実行時には使用されません。このデータは承認者にも表示されません。

この例では、追加の属性名として生年月日を指定しています。「データ型」に「数値」、「表示タイプ」に「テキスト・フィールド」を選択し、「追加」をクリックします。複数の属性を指定するには、「追加」ボタンをクリックします。終了したら、「次へ」をクリックします。

関連項目:

基礎となるOracle Identity Managerエンティティにマップされない追加の属性の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。

図17-4に、「追加属性の設定」ページを示します。

図17-4 「追加属性の設定」ページ

「図17-4 「追加属性の設定」ページ」の説明

9. 「テンプレート・ユーザー・ロールの設定」ページで、1つ以上のロール(たとえば、AD管理者)を選択できます。そのロールのメンバーは、作成されたテンプレートを使用してリクエストを作成できます。この例では、「使用可能なロール」リストから、契約者管理者などのロールを選択します。「移動」をクリックして、選択したロールを「選択したロール」リストに移動し、「次」をクリックします。

注意:

選択されたロールのメンバーのみが、そのリクエスト・テンプレートを使用してリクエストを作成できます。これは、リクエスト・テンプレートを使用してリクエストを作成するための認可ポリシーで管理されます。リクエスト・テンプレートを使用したリクエストの作成の詳細は、「リクエスト・テンプレートを使用したリクエスト作成」を参照してください。

図17-5に、「テンプレート・ユーザー・ロールの設定」ページを示します。

図17-5 「テンプレート・ユーザー・ロールの設定」ページ

「図17-5 「テンプレート・ユーザー・ロールの設定」ページ」の説明

10. 「リクエスト・テンプレート・サマリーの確認」ページ(図17-6を参照)で、「リクエスト・テンプレート名」、「リクエスト・タイプ」、「説明」、「テンプレート・レベルの承認プロセス」に入力したデータを確認し、「終了」をクリックします。

図17-6 「リクエスト・テンプレート・サマリーの確認」ページ

「図17-6 「リクエスト・テンプレート・サマリーの確認」ページ」の説明

11. 「OK」をクリックして、テンプレートの作成を確認します。

リクエスト・テンプレートの作成ウィザードの次の各ステップは、選択したリクエスト・タイプや定義したリクエスト・データセットに関係なく共通です。

- 「リクエスト・テンプレートの詳細の設定」ページでのリクエスト詳細の指定。「リクエスト・テンプレートの作成」のステップ5を参照してください。

- 「追加属性の設定」ページでの追加属性の設定。ステップ8を参照してください。

- 「テンプレート・ユーザー・ロールの設定」ページでのテンプレートに対するロールの設定。ステップ9を参照してください。

- 「リクエスト・テンプレート・サマリーの確認」ページにあるリクエスト・テンプレート情報。ステップ10を参照してください。

17.1.2 「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートの作成

「リソースのプロビジョニング」リクエスト・タイプに基づいている「リソースのプロビジョニング」デフォルト・リクエスト・テンプレートを使用して、リソースをユーザーにプロビジョニングできます。しかし、リクエストの作成をカスタマイズしてユーザーに固有のリソースをプロビジョニングする必要がある場合は、「リソースのプロビジョニング」リクエスト・タイプに基づいたリクエスト・テンプレートを作成できます。

「リソースのプロビジョニング」リクエスト・タイプに基づいてリクエスト・テンプレートを作成する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理で、「構成」タブをクリックし、次に「リクエスト・テンプレート」タブをクリックします。または、「ようこそ」ページの「構成」の下にある「リクエスト・テンプレートの検索」リンクをクリックします。

注意:

リクエスト・テンプレート管理者ロールのメンバーであるユーザーは、リクエスト・テンプレートを作成できます。適切なロールがユーザーに割り当てられていない場合、ユーザーはリクエスト・テンプレートを作成するために必要なUIオプションを使用できません。

2. 左ペインの「アクション」メニューから、「作成」を選択します。または、ツールバーにある「リクエスト・テンプレートを作成します」アイコンをクリックします。リクエスト・テンプレートの作成ウィザードの「リクエスト・テンプレートの詳細の設定」ページが表示されます。

3. 次のフィールドに値を入力し、「次」をクリックします。

- リクエスト・テンプレート名: リクエスト・テンプレート名を入力します(例: E-Businessリソースのプロビジョニング)。

- リクエスト・タイプ: リクエスト・タイプを選択します(例: リソースのプロビジョニング)。

注意:

リクエスト・テンプレートの作成ウィザードの各ステップは、ウィザードの第1ステップで「リクエスト・テンプレート基本情報」を指定した後、「次」をクリックすると動的に生成されます。

- 説明: 作成しているリクエスト・テンプレートの説明を入力します。

- 承認プロセス: 承認ワークフローの名前を入力します。このフィールドの詳細は、「「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」のステップ4を参照してください。

4. 「許可されているリソースの選択」ページで「検索」をクリックし、使用可能なすべてのリソースを検索します。

5. 使用可能なリソース・リストからリソースを1つ以上選択し、「移動」をクリックして、選択したリソースを「選択したリソース」リストに移動します。この例では、「E-Business RO」リソースを選択し、「次」をクリックします。

注意:

- このテンプレートを使用したリクエストの作成時には、このステップで選択したリソースのみがリクエスタに表示されます。ここでリソースを選択しなかった場合は、リクエストの作成時にOracle Identity Managerのすべてのリソースが表示されます。

- テンプレートでエンティティ・タイプが制限されていない場合は、このテンプレートを使用してリクエストを作成する際、使用可能なすべてのエンティティ・タイプがリクエスタに表示されます。

6. 「制限する属性の選択」ページで、制限する必要がある、E-Businessリソースに関連付けられている属性を選択します。これらの属性は、E-Businessリソースをプロビジョニングするために、リクエスト・データセットに定義されます。属性の詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のステップ1: リソース用のリクエスト・データセットの作成に関する項を参照してください。
「許可されているリソースの選択」ページで複数のリソースを選択すると、すべてのリソースに関連付けられている属性が「制限する属性の選択」ページに表示されます。制限するリソースの属性をすべて選択し、「次」をクリックします。

7. 「属性制限の設定」ページで、値を制限する属性に値を指定します。たとえば、「FAX」属性に対してユーザーが属性の値を指定できないようにする場合は、「ユーザーがこの属性の値を入力できないようにします」オプションを選択します。値を選択できるようにする場合は、「この属性を次の値に制限します」オプションを選択し、「FAX」属性に1つ以上の値を指定します。これらのオプションおよび属性に対する制限の設定の詳細は、「「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」を参照してください。
「ユーザーがこの属性の値を入力できないようにします」オプションは、「サーバー」属性および「存続期間タイプ」属性には使用できないことに注意してください。これは、これらの属性がリクエスト・データセットで必須に指定されているためです。必須プロパティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成に関する項を参照してください。

すべての属性について制限値を選択し、「次」をクリックします。

ヒント:

複数のリソースをユーザーにプロビジョニングするリクエストのリクエスト・テンプレートを作成している場合は、「次のリソース」ボタンと「前のリソース」ボタンをクリックして、すべてのリソースに対して属性の制限を設定します。

注意:

「属性制限」ページにシャトルとして表示される属性には、最大200件の結果が一度に表示されます。関連する検索結果を取得するために、適切な検索パターンを用意する必要があります。

8. 「「ユーザーの作成」リクエスト・タイプに基づいたリクエスト・テンプレートの作成」のステップ8から10を実行し、ウィザードを完了します。

注意:

リクエスト・テンプレートの作成ウィザードで、リソースを選択するステップと属性の制限を設定するステップは、リクエスト・タイプによって異なります。残りのステップは同じです。

リクエスト・テンプレートの作成時に、リクエスト・データセットが定義されていないリソースを選択すると、ユーザーに対して収集対象属性を制限できなくなります。これは、選択されたリソースについてユーザーから収集するデータの情報が指定されていないためです。その結果、制限されるデータがない場合、これらのステップの属性はリクエスト・データセットによって定義されるため、リクエスト・テンプレートの作成ウィザードの「ステップ3: 属性」および「ステップ4: 制限」は適用されません。ただし、リクエスト・データセットがないリソースを選択した場合、「サービス・アカウント」属性は共通のリクエスト・データセットによって定義されるため、この属性が「ステップ3: 属性」に表示されます。共通リクエスト・データセットの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の共通リクエスト・データセットに関する項を参照してください。

17.2 リクエスト・テンプレートの検索と変更

リクエスト・テンプレート管理者ロールの権限がある場合は、Oracle Identity Manager管理を使用してリクエスト・テンプレートの単純検索および拡張検索を実行できます。

リクエスト・テンプレートの単純検索を実行する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理で、「構成」タブをクリックし、次に「リクエスト・テンプレート」タブをクリックします。または、「ようこそ」ページの「構成」の下にある「リクエスト・テンプレートの検索」リンクをクリックします。

2. 「リクエスト・テンプレート」セクションの左ペインで、「検索」フィールドに検索基準を入力します。「検索」フィールドには、ワイルドカード文字のアスタリスク(*)を使用できます。

注意:

リクエスト・テンプレートの単純検索および拡張検索では、翻訳されたリクエスト・テンプレート名での検索はサポートされていません。デフォルトのリクエスト・テンプレートの場合、データベースに格納されている英語のテンプレート名でのみ検索できます。ただし、別の言語でテンプレート名を指定してリクエスト・テンプレートを作成した場合は、同じ文字列(その他の言語でなく)を使用してテンプレートを検索できます。

3. 「検索」フィールドの横にあるアイコンをクリックして、デフォルトおよびデフォルト以外のリクエスト・テンプレートのリストを表示します。
デフォルトのリクエスト・テンプレートはすべて、リクエスト・タイプの最上部にあるカスタマイズされていない空白のテンプレートです。表17-1に、デフォルトのリクエスト・テンプレートを示します。

表17-1 デフォルトのリクエスト・テンプレート

リクエスト・テンプレート

説明

ロールの割当て

ロールをユーザーに割り当てるためのデフォルト・テンプレート

ユーザーの作成

ユーザーを作成するためのデフォルト・テンプレート

リソースのプロビジョニング解除

リソースのプロビジョニングを解除するためのデフォルト・テンプレート

ユーザーの削除

ユーザーを削除するためのデフォルト・テンプレート

プロビジョニング済リソースの無効化

プロビジョニング済リソースを無効化するためのデフォルト・テンプレート

ユーザーの無効化

ユーザーを無効化するためのデフォルト・テンプレート

プロビジョニング済リソースの有効化

無効化されたリソースを有効化するためのデフォルト・テンプレート

ユーザーの有効化

ユーザーを有効化するためのデフォルト・テンプレート

プロビジョニング済リソースの変更

プロビジョニング済リソースを変更するためのデフォルト・テンプレート

セルフ・プロファイルの変更

セルフ・プロファイルを変更するためのデフォルト・テンプレート

ユーザー・プロファイルの変更

ユーザー・プロファイルを変更するためのデフォルト・テンプレート

リソースのプロビジョニング

リソースをプロビジョニングするためのデフォルト・テンプレート

ロールからの削除

ユーザーをロールから削除するためのデフォルト・テンプレート

ユーザーの自己登録

ユーザーを自己登録するためのデフォルト・テンプレート

リソースの自己リクエスト

リソースを自己リクエストするためのデフォルト・テンプレート

注意:

表17-1に記載されている各リクエスト・テンプレートには、SPML Webサービスによって使用されるデフォルトのコールバック・ポリシーがあります。

リクエスト・テンプレートの拡張検索を実行する手順は、次のとおりです。

1. 「リクエスト・テンプレート」セクションの左ペインで、「拡張検索」をクリックします。「拡張検索: リクエスト・テンプレート」ページが表示されます。

2. 次の一致オプションのいずれかを選択します。

- すべて: このオプションを選択すると、検索はAND条件で実行されます。つまり、指定されたすべての検索基準に一致するリクエスト・テンプレートが検索結果に表示されます。

- いずれか: このオプションを選択すると、検索はOR条件で実行されます。つまり、指定されたいずれかの検索基準に一致するリクエスト・テンプレートが検索結果に表示されます。

3. フィールドに値を検索基準として指定します。各フィールドに対して、演算子(「次と等しい」、「次を含む」、「次で始まる」など)を選択します。

4. 「検索」をクリックします。検索結果表に、リクエスト・テンプレート名、リクエスト・タイプ、承認プロセスおよび説明に関する詳細が表示されます。

図17-7 リクエスト・テンプレートの拡張検索結果

「図17-7 リクエスト・テンプレートの拡張検索結果」の説明

リクエスト・テンプレートを変更する手順は、次のとおりです。

1. 検索結果表でテンプレート名を選択します。「アクション」メニューから「開く」を選択します。「テンプレートの詳細」ページに、テンプレートに関する詳細が表示されます。

2. 表17-2に示すように、「テンプレートの詳細」セクションのフィールドにテンプレートの詳細が表示されます。

表17-2 「テンプレートの詳細」セクションのフィールド

フィールド

説明

リクエスト・テンプレート名

リクエスト・テンプレートの名前(例: ユーザーの作成)

リクエスト・タイプ

リクエストのタイプ(例: ユーザーの作成)

テンプレート・レベルの承認プロセス

このリクエスト・テンプレートを使用して作成されるリクエストに対して起動する追加の承認プロセス

説明

リクエスト・テンプレートの説明

注意:

リクエスト・テンプレート名およびリクエスト・タイプの変更はサポートされていないため、これらのフィールドはテンプレート詳細に読取り専用として表示されます。

リクエスト・テンプレートを作成し、リクエスト・テンプレートを検索すると、作成したテンプレートは、左ペインの検索結果表にも表示されます。作成したテンプレートの詳細を確認できます。たとえば、「契約者の作成」というリクエスト・テンプレートを選択し、「アクション」メニューから「開く」を選択すると、「契約者の作成」リクエスト・テンプレートの「テンプレートの詳細」ページが表示されます。

「テンプレートの詳細」セクションに表示されるタブは、テンプレートの作成ウィザードのステップに相当します。ウィザードのステップと同様に、「テンプレートの詳細」ページのタブは動的に生成され、各タブはテンプレートの作成ウィザードのステップに相当します。通常、リクエスト・テンプレートの詳細ページには、次のタブがあります。

- 「許可されているリソース」または「許可されているロール」

- 属性制限

- 追加属性

- テンプレート・ユーザー・ロール

注意:

これらのタブは、リクエスト・テンプレートに関連付けられているリクエスト・タイプに基づいて動的に生成されます。つまり、リクエスト・テンプレートの詳細ページに表示される各タブは、リクエスト・テンプレートの作成ウィザードのステップに相当します。

17.2.1 「許可されているリソース」または「許可されているロール」

「許可されているリソース」タブまたは「許可されているロール」タブは、リクエスト・タイプがリソースまたはロールに関連付けられている場合にのみ表示されます。図17-8に、「許可されているリソース」タブを示します。

図17-8 「許可されているリソース」タブ

「図17-8 「許可されているリソース」タブ」の説明

このタブで使用可能なオプションを使用して、リソースまたはロールを編集および削除できます。リソースまたはロールを編集する手順は、次のとおりです。

1. 変更するリクエスト・テンプレートをOracle Identity Manager拡張管理で開きます(または編集します)。

2. リクエスト・テンプレートの詳細ページの「許可されているリソース」タブで、編集するリソースまたはロールを選択します。

3. 「アクション」リストから「編集」を選択します。「許可されているリソース」ダイアログ・ボックスが表示されます。

4. 編集するリソースまたはロールを検索します。

5. 使用可能なリソース・リストからリソースを1つ以上選択し、「移動」または「すべて移動」をクリックして、それらのリソースを「選択したリソース」リストに移動します。

6. 「実行」をクリックします。リソースが「許可されているリソース」タブにリストされます。

リソースまたはロールを削除する手順は、次のとおりです。

1. 削除するリソースまたはロールを選択します。

2. 「アクション」リストから「削除」を選択します。削除を確認するメッセージ・ボックスが表示されます。

3. 「OK」をクリックします。

17.2.2 属性制限

このタブがある場合、タブには属性制限が表示されます。図17-9に、「属性制限」タブを示します。

図17-9 「属性制限」タブ

「図17-9 「属性制限」タブ」の説明

このタブを使用して、追加の制限が汎用リクエスト・タイプに関連付けられている場合は、エンティティ・タイプを選択して追加の制限を指定できます。手順は次のとおりです。

1. 変更するリクエスト・テンプレートをOracle Identity Manager拡張管理で開きます(または編集します)。

2. 上部のセクションで、制限する新しい属性を選択するか、既存の属性(制限されたユーザーまたはリソースの任意のエンティティに対する制限)の選択を解除します。

3. 下部のセクションで、制限された属性の値を変更します。

4. 「次のリソース」をクリックします。次のリソースの属性が表示されます。複数のリソースが制限されている場合は、「前のリソース」ボタンと「次のリソース」ボタンを使用して、複数のリソースの属性の制限にナビゲートできます。

注意:

リクエスト・テンプレートの使用による承認者専用属性の制限はサポートされていません。

17.2.3 追加属性

このタブは常に表示されます。図17-10に、「追加属性」タブを示します。

図17-10 「追加属性」タブ

「図17-10 「追加属性」タブ」の説明

このタブを使用して、データ収集のための追加属性をテンプレート・レベルで指定できます。これらの属性は、ユーザーがリクエストを作成するときに収集されます。このデータは、リクエスト実行時には使用できません。新しいテンプレート属性を追加したり、既存のテンプレート属性を削除できます。

データ収集に追加の属性を指定する手順は、次のとおりです。

1. 変更するリクエスト・テンプレートをOracle Identity Manager拡張管理で開きます(または編集します)。

2. 「追加属性」タブの「属性名」フィールドに、属性の名前を入力します。

3. 「データ型」リストで「文字列」、「数値」、「日付」または「ブール」から値を選択します。

4. 「表示タイプ」リストから、「テキスト・フィールド」、「日付フィールド」、「チェック・ボックス」など、この属性に対して表示するフィールドのタイプを選択します。

5. 「追加」をクリックします。属性が「追加属性」セクションに追加されます。

追加属性を削除するには、属性を選択して、「アクション」リストから「削除」を選択します。

17.2.4 テンプレート・ユーザー・ロール

このタブを使用してロールを選択し、リクエスト・テンプレートに割り当てることができます。ロールが割り当てられているユーザーのみが、テンプレートを使用してリクエストを作成できます。図17-11に、「テンプレート・ユーザー・ロール」タブを示します。

図17-11 「テンプレート・ユーザー・ロール」タブ

「図17-11 「テンプレート・ユーザー・ロール」タブ」の説明

リクエスト・テンプレートに割り当てるロールを選択する手順は、次のとおりです。

1. 変更するリクエスト・テンプレートをOracle Identity Manager拡張管理で開きます(または編集します)。

2. 「テンプレート・ユーザー・ロール」タブの「使用可能なロール」リストから、このテンプレートを使用してリクエストを作成するロールを選択します。

3. 「移動」または「すべて移動」をクリックして、ロールを「選択したロール」リストに移動します。

17.3 テンプレートのクローニング

リクエスト・テンプレートのクローニングとは、既存のリクエスト・テンプレートのすべてのプロパティを継承して、新規のリクエスト・テンプレートを作成する手続きです。

注意:

テンプレートのクローニングでは、「リクエスト・タイプ」フィールドを変更できません。新しいテンプレートの「リクエスト・タイプ」は、既存のテンプレートと同じになります。

リクエスト・テンプレートをクローニングする手順は、次のとおりです。

1. Oracle Identity Manager拡張管理に移動します。

2. 「テンプレートの詳細」ページの拡張検索結果から、クローニングするリクエスト・テンプレートを選択します。

3. 「アクション」メニューから「クローン」を選択します。「テンプレートのクローン」ページに、クローニングのために選択したリクエスト・テンプレートの詳細が表示されます。

4. 新しいリクエスト・テンプレートを作成するために、必要なリクエスト・テンプレートの詳細を変更します。

5. 「保存」をクリックして、新しいリクエスト・テンプレートを作成します。

17.4 テンプレートの削除

テンプレート管理者ロールのメンバーとしてテンプレートを削除する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理の「リクエスト・テンプレート」タブで、既存のリクエスト・テンプレートを検索します。

2. 検索結果表から、削除するテンプレートを選択します。

3. 「アクション」リストから「削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。

4. 「はい」をクリックして確認します。

注意:

削除するテンプレートが既存のリクエストによって参照される場合、そのテンプレートは削除できません。そのようなテンプレートの削除を試みた場合は、エラー・メッセージがUIに表示されます。

18 承認ポリシーの管理

承認ポリシーはリクエスト管理の構成可能なエンティティで、リクエスト・レベルおよび操作レベルの承認のみに対してリクエスト・サービスで定義された承認プロセスに、各種リクエスト・タイプを関連付けるのに役立ちます。これは、リクエスト・タイプに対して、リクエスト・レベルまたは操作レベルで開始される承認ワークフローを関連付けます。承認ポリシーを使用して、SOAベース・ワークフローである様々な承認プロセスに各種リクエスト・タイプを関連付けることができます。承認ポリシーによって、リクエスト・データ評価に基づいてどの承認プロセスを起動するかが制御されます。

1つのリクエスト・タイプに対して複数の承認ポリシーを定義できます。各承認ポリシーは1つの承認プロセスに関連付けられます。承認開始フェーズでリクエストが送信されると、そのリクエスト・タイプに関連付けられたすべての承認プロセスが動的に取得されます。各承認ポリシーには、バックエンドに優先度が設定されます。各承認ポリシーでは、承認ポリシー優先度および承認ポリシー・ルールに基づいて、起動するプロセスを決定します。

承認ポリシー優先度は、次に基づいています。

- リクエスト・レベルの場合: リクエスト・タイプ + リクエスト・レベル

- 操作レベルの場合: リクエスト・タイプ + 操作レベル + スコープ(リクエストに関連付けられた特定のエンティティ)

リクエスト・エンジンは、承認ワークフローを開始するとき、そのリクエスト・タイプに対して使用可能なすべての承認ポリシーを優先度順に取得します。優先度の最も高い承認ポリシーが取得され、その承認ポリシー・ルールが評価されます。その評価が失敗すると、優先度が次に高い承認ポリシーの承認ポリシー・ルールが評価されます。評価の結果が「True」の場合は、承認ポリシーに関連付けられた対応する承認プロセスが、そのリクエストのワークフローとして選択されます。承認ポリシー・ルールの作成については、「承認ポリシーの作成」を参照してください。

注意:

1つの承認ポリシーに対して承認ポリシー・ルールは1つのみです。ルールは、複数の条件や他のルールが含まれて複雑になる可能性があります。ルールは独立したエンティティとして存在しないため、他の承認ポリシーで再利用できません。承認ポリシーに対するデフォルト・ルールはありません。

この章の項目は次のとおりです。

- 承認の選択方法

- 承認ポリシーの作成

- 承認ポリシーの検索

- 承認ポリシーの変更

- 承認ポリシーの優先度の変更

- 承認ポリシーの削除

注意:

承認ポリシー管理者ロールのメンバーであるユーザーのみ、承認ポリシーを作成、検索、変更および削除する権限があります。承認ポリシーの認可の詳細は、「承認ポリシー管理」を参照してください。

18.1 承認の選択方法

承認プロセスの選択方法とは、開始する承認ワークフローを選択するアルゴリズムです。リクエスト・エンジンは、リクエスト・タイプおよび承認レベルに基づいて、使用する方法を決定し、それに従って承認プロセスを評価します。

リクエスト・レベルで承認が定義されていない場合は、デフォルト承認プロセスが起動されます。デフォルト承認プロセスはOracle Identity Managerに付属しており、管理者に割り当てられます。操作レベルで承認が定義されていない場合は、デフォルト承認プロセスが起動されます。テンプレート・レベルの承認が定義されていない場合、そのレベルでの承認は不要とみなされます。

次の方法が使用されます。

- リクエスト・レベルの方法

- 操作レベルの方法: 組織ベースの選択

- 操作レベルの方法: リソース・ベースの選択

- 操作レベルの方法: ロール・ベースの選択

18.1.1 リクエスト・レベルの方法

この方法は、すべてのリクエスト・タイプに対して、承認のリクエスト・レベルで使用されます。リクエスト・レベルの選択方法の決定アルゴリズムは次のとおりです。

1. リクエスト・レベル、およびリクエストが関連付けられたリクエスト・タイプに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。

1. 各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエスト・レベルの承認は自動的に承認されます。

2. 承認ポリシー・ルールを満たす承認ワークフローがない場合は、リクエスト・レベルで構成された承認ワークフローがないとみなされます。

2. 該当する承認ワークフローがない場合は、デフォルト・リクエスト・レベルの承認が選択されます。

18.1.2 操作レベルの方法: 組織ベースの選択

この方法は、ユーザー関連のすべてのリクエスト・タイプ(「ユーザーの作成」、「ユーザーの変更」、「ユーザーの無効化」、「ユーザーの有効化」、「ユーザーの削除」など)に対して、承認の操作レベルで使用されます。操作レベルでの組織ベースの選択方法の決定アルゴリズムは次のとおりです。

1. リクエストが作成される、ユーザーの組織エンティティを取得します。

2. 操作レベル、リクエストに関連付けられたリクエスト・タイプ、またはすべての組織に対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。

1. 各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。

2. 承認ポリシー・ルールを満たす承認ワークフローがない場合、この組織の操作レベルで構成された承認ワークフローはないとみなされます。

3. その組織エンティティに対して構成された承認ワークフローがない場合は、ルート・ノードまたはドメイン境界(組織階層のルート組織)まで組織階層を移動します。組織ノードごとにステップ2を繰り返します。

4. 該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。

18.1.3 操作レベルの方法: リソース・ベースの選択

この方法は、リソース関連のすべてのリクエスト・タイプに対して、承認の操作レベルで使用されます。操作レベルでのリソース・ベースの選択方法の決定アルゴリズムは次のとおりです。

1. リクエストに関連付けられたリソース・エンティティを取得します。

2. 操作レベル、リクエストに関連付けられたリクエスト・タイプ、またはリクエストに関連付けられたすべてのリソースに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。

1. 各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。

2. 承認ポリシー・ルールを満たす承認ワークフローがない場合、このリソースの操作レベルで構成された承認ワークフローはないとみなされます。

3. 該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。

18.1.4 操作レベルの方法: ロール・ベースの選択

この方法は、ロール関連のすべてのリクエスト・タイプに対して、承認の操作レベルで使用されます。操作レベルでのロール・ベースの選択方法の決定アルゴリズムは次のとおりです。

1. ユーザーに割り当てられるか、またはユーザーから削除されるロール・エンティティを取得します。

2. 操作レベル、リクエストに関連付けられたリクエスト・タイプ、または割り当てるか削除されるすべてのロールに対して構成されているすべての承認ポリシーを、承認ポリシー優先度順(昇順)に検索します。この基準に一致する承認ポリシーが検出された場合は、次の処理が実行されます。

1. 各承認ポリシーに関連付けられた承認ポリシー・ルールを評価して、承認ワークフローを決定します。承認ポリシー・ルールを評価して、評価結果が「True」になった最初の承認ポリシー・ルールについて、その承認ポリシーに関連付けられた対応する承認ワークフローが選択されます。承認ポリシーで自動承認が指定されている場合、リクエストは操作レベルで自動的に承認されます。

2. 承認ポリシー・ルールを満たす承認ワークフローがない場合、このロールの操作レベルで構成された承認ワークフローはないとみなされます。

3. 該当する承認ワークフローがない場合は、デフォルト操作レベルの承認が選択されます。

18.2 承認ポリシーの作成

承認ポリシーを作成する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理で、「ポリシー」タブをクリックし、「承認ポリシー」をクリックします。または、「ようこそ」ページで、「ポリシー」の下にある「承認ポリシーの検索」をクリックします。

2. 左ペインの「アクション」メニューから「作成」を選択します。または、ツールバーにあるプラス(+)記号が付いたアイコンをクリックして、承認ポリシーの作成ウィザードを開始することもできます。ステップ1.承認ポリシーの詳細の設定ページ(承認ポリシーの作成ウィザード)が表示されます。

3. 次のフィールドに値を入力し、「次」をクリックします。

- ポリシー名: 承認ポリシーの名前を入力します。これは必須属性です。

- 説明: この承認ポリシーの機能について説明を入力します。

- リクエスト・タイプ: LOVからリクエスト・タイプ(「ロールの割当て」など)を選択します。これは必須属性です。

- レベル: この承認ポリシーに対して実装する承認レベルを選択します。これは必須属性です。承認レベルの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』の承認レベルに関する項を参照してください。

- スコープ・タイプ: 選択したリクエスト・タイプに基づいて自動的に設定されます。次に例を示します。

- リクエスト・タイプを「ユーザーの作成」に設定すると、「スコープ・タイプ」は「組織」に自動的に設定されます。

- リクエスト・タイプを「リソースのプロビジョニング」に設定すると、「スコープ・タイプ」は「リソース」に自動的に設定されます。

- リクエスト・タイプを「ロールの割当て」に設定すると、「スコープ・タイプ」は「ロール」に自動的に設定されます。

注意:

「スコープ・タイプ」、「すべてのスコープ」および「スコープ」フィールドは、「レベル」フィールドを「操作レベル」に設定した場合のみ有効になります。「レベル」フィールドを「リクエスト・レベル」に設定した場合、これらのフィールドは無効になります。

- すべてのスコープ: このオプションを選択して、特定のエンティティ・タイプのすべてのエンティティに関連付ける承認ポリシーを指定します。たとえば、「ユーザーの作成」リクエスト・タイプの場合、「スコープ・タイプ」は「組織」です。「すべてのスコープ」を選択すると、この承認ポリシーはOracle Identity Managerのすべての組織に適用可能になります。これは、スコープが「リソース」および「ロール」の場合も同様です。

- スコープ: このオプションを選択して、特定のエンティティ・タイプの特定のエンティティに関連付ける承認ポリシーを指定します。承認ポリシーは、「スコープ・タイプ」に基づいて特定のスコープに関連付けることができます。
「スコープ」フィールドは、「すべてのスコープ」フィールドが設定されると無効になります。「すべてのスコープ」フィールドが設定されない場合、このフィールドは必須になり、値を設定する必要があります。

- 自動承認: このオプションを選択して、「レベル」フィールドでの選択に基づき、リクエスト・レベルまたは操作レベルでの自動承認を指定します。

- 承認プロセス: この承認ポリシーに関連付けるワークフローを選択します。このフィールドは、「自動承認」が選択されると無効になり、値を設定できません。「自動承認」が設定されない場合、このフィールドは必須になります。

4. ステップ2.承認ルールおよびコンポーネントの設定ページで、「ルール名」フィールドに承認ポリシー・ルールの名前(例: RuleTest1)を入力します。

5. 「ルール・コンポーネント」セクションで、承認ポリシー・ルールのパラメータを定義できます。これを行うには、「表示」リストの横にあるアイコンをクリックします。「単純ルールの追加」ダイアログ・ボックスが表示されます。このダイアログ・ボックスで、次のフィールドの値を選択し、「保存」をクリックします。

- エンティティ: 承認ポリシー・ルールが関連付けられるエンティティ(「リクエスタ」、「受益者」、「リソース」など)。これは、選択したリクエスト・タイプおよび承認レベルに基づいて決まります。

- 属性: 前述の選択したエンティティの属性。

- 条件: 承認ポリシー・ルールの条件(「次と等しい」、「次と等しくない」、「次で始まる」など)。

- 値: 条件の値。

注意:

ルール式で「ユーザー・ログイン」属性を使用する場合は、対応する「ユーザー・ログインID」の値をすべて大文字で入力する必要があり、そうしないと、式で「True」と評価されません。

- 親ルール・コンテナ: この承認ポリシー・ルールを関連付ける必要があるルール・コンテナ。

注意:

単純ルール式を記述するとき、エンティティ属性にエンコード値がある場合は、参照コード定義ではなくエンコード値を使用して式が作成されます。たとえば、「アカウント・ステータス」属性の場合、デコード値の「ロック」または「ロック解除」ではなく、エンコード値の1または0を使用して式が作成されます。

6. ルール・コンテナは、「AND」と「OR」を組み合せて複雑な条件をモデル化するために使用できます。承認ポリシー・ルールのルール・コンテナを追加するには、「ルール・コンポーネント」セクションで、「アクション」メニューから「ルール・コンテナの追加」を選択します。「ルール・コンテナの追加」ダイアログ・ボックスが表示されます。このダイアログ・ボックスで、次のフィールドの値を入力または選択し、「追加」をクリックします。

- ルール・コンテナ名: ルール・コンテナの名前。

- 親ルール・コンテナ: このルール・コンテナを作成するルール・コンテナの名前。ルール・コンテナには、別のルール・コンテナを含めたり、「AND」や「OR」演算子を使用してルール要素を階層的に順番に含めることができます。

- 演算子: 演算子は「AND」および「OR」です。

7. 承認ルールの作成の完了後に、「次」をクリックします。

8. ステップ3.承認ポリシー・サマリーの確認ページで、承認ポリシーに関して指定した情報を確認します。必要な場合は、「戻る」ボタンをクリックして情報を変更できます。「終了」をクリックして、承認ポリシーを作成します。

9. 承認ポリシーが作成されたことを確認するメッセージが表示されます。「OK」をクリックします。

18.3 承認ポリシーの検索

承認ポリシーを検索する手順は、次のとおりです。

1. Oracle Identity Manager拡張管理で、「承認ポリシー」タブの左ペインにある「検索」フィールドに、承認ポリシーを検索するための検索基準を入力します。アスタリスク(*)ワイルドカード文字を指定して、検索基準を指定できます。

注意:

承認ポリシーの単純検索および拡張検索では、翻訳された承認ポリシー名での検索はサポートされていません。Oracle Identity Managerでは、承認ポリシーについて英語の文字列検索のみサポートされています。デフォルトの承認ポリシーの場合は、データベースに格納されている英語のポリシー名で検索できます。ただし、別の言語でポリシー名を指定して承認ポリシーを作成した場合は、同じ文字列(その他の言語でなく)を使用してポリシーを検索できます。

2. 検索アイコンをクリックします。検索結果表に、次のフィールドを含む承認ポリシーのリストが表示されます。

- ポリシー名: 承認ポリシーの名前。

- リクエスト・タイプ: 承認ポリシーに関連付けられたリクエスト・タイプの名前。

- スコープ: 関連付けられたリソース、組織またはロールの名前。スコープは、操作レベルのリクエストに関連付けられた承認ポリシーの場合のみ表示されます。

- レベル: 承認レベル。

- ルール名: 承認ポリシー・ルールの名前。

- 承認プロセス: 承認ポリシーに関連付けられた承認プロセス。

- 優先度: 承認ポリシーの優先度。

図18-1に、承認ポリシーの検索結果を示します。

図18-1 承認ポリシーの検索結果

「図18-1 承認ポリシーの検索結果」の説明

「承認ポリシー」タブの「拡張検索」オプションを使用して、拡張検索基準に基づいて承認ポリシーを検索することもできます。手順は次のとおりです。

1. 「承認ポリシー」タブの左ペインで、「拡張検索」をクリックします。「拡張検索: 承認ポリシー」ページが表示されます。

2. フィールドに値を入力して検索基準を指定します。検索基準を指定する際には、承認ポリシー名、承認ポリシーに関連付けられたリクエスト・タイプの名前、承認レベル、スコープ・タイプ(リソース、組織、ロールなど)およびスコープを組み合せて指定できます。

3. 「検索」をクリックします。図18-2に示すように、検索結果に承認ポリシーのリストが表示され、優先度、ポリシー名、リクエスト・タイプ、スコープ、レベル、ルール名および承認プロセスの情報が表示されます。

図18-2 承認ポリシーの拡張検索

「図18-2 承認ポリシーの拡張検索」の説明

18.4 承認ポリシーの変更

承認ポリシーを変更する手順は、次のとおりです。

1. 検索結果表で、ポリシーを選択します。

2. 「アクション」メニューから「開く」を選択します。「承認ポリシーの詳細」フォームが表示されます。

3. 「ポリシーの詳細」セクションで、フィールドを編集して承認ポリシーを変更します。

注意:

承認ポリシー・ルール名および承認ポリシー優先度属性は変更できません。

4. 必要に応じて、「承認ルール」セクションで承認ポリシー・ルールを変更します。承認ポリシー・ルールを変更するには、単純ルールの追加、ルール・コンテナの追加、ルール・コンポーネントの変更またはルール・コンポーネントの削除を行うことができます。承認ポリシー・ルールおよびルール・コンテナの追加方法の詳細は、「承認ポリシーの作成」のステップ5から7を参照してください。

5. ルール・コンポーネントを変更する手順は、次のとおりです。

1. 承認ポリシー・ルールを選択します。

2. 「アクション」メニューから「ルール・コンポーネントの変更」を選択します。「ルール・コンポーネントの変更」ダイアログ・ボックスが表示されます。

3. 表示されたフィールドの値を編集し、「適用」をクリックします。

6. ルール・コンポーネントを削除する手順は、次のとおりです。

1. 削除する承認ポリシー・ルールを選択します。

2. 「アクション」メニューから「ルール・コンポーネントの削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。

3. 「はい」をクリックして削除を確認します。

7. 「保存」をクリックして、承認ポリシーに対する変更内容を保存します。

18.5 承認ポリシーの優先度の変更

承認ポリシーの優先度を変更する手順は、次のとおりです。

1. 承認ポリシーの検索結果から、優先度を変更するポリシーを選択します。

2. 「アクション」メニューから「優先度の設定」を選択します。承認ポリシー優先度の変更ウィザードが表示されます。

3. ポリシーの詳細の設定ページで、必須フィールドに値を指定します。このページのフィールドについては、「承認ポリシーの作成」のステップ4を参照してください。次に、「次」をクリックします。

4. ポリシー優先度の設定ページで、承認ポリシーの優先度を指定する数値を入力します。次に、「次」をクリックします。

5. 確認および確定ページに、設定したポリシー名と優先度が確認のために表示されます。現在の優先度を変更する場合は、「戻る」をクリックします。
それ以外の場合は、「終了」をクリックします。承認ポリシー優先度が正常に変更されたことを示すメッセージが表示されます。

6. 「OK」をクリックします。

注意:

Oracle Identity Managerでは検証が実行されないため、同じ優先度を複数の承認ポリシーに設定することが可能です。同じ優先度を複数の承認ポリシーに設定することはお薦めしません。

18.6 承認ポリシーの削除

承認ポリシーを削除する手順は、次のとおりです。

1. 承認ポリシーの検索結果から、削除する承認ポリシーを選択します。

2. 「アクション」メニューから「削除」を選択します。確認を求めるメッセージ・ボックスが表示されます。

3. 「はい」をクリックして削除を確認します。

19 アテステーション・プロセスの管理

この章の内容は、次のとおりです。

- アテステーションについて

- アテステーション・プロセスの設定

- アテステーション・プロセスの作成

- アテステーション・プロセスの管理

- アテステーション・ダッシュボードの使用

19.1 アテステーションについて

アテステーションを使用すると、レビューアとして指定されたユーザーは、レビューする必要のあるレポートについて通知を受けることができます。これらのレポートには、他のユーザーの権限について記述されています。レビューアは、レスポンスを入力することにより、これらの権限の正確さをアテストすることができます。アテステーション・アクションは、レビューアが入力したレスポンス、関連コメント、およびレビューアが参照してアテストするデータの監査ビューとともにトラッキングと監査を受け、アカウンタビリティの完全な証跡を残します。Oracle Identity Managerでは、このプロセスをアテステーション・タスクと呼びます。

Oracle Identity Managerのアテステーションは、スケジュールされたアテステーション・プロセスの定義を介してサポートされます。アテステーション・プロセスは、Oracle Identity Managerワークフローとは異なります。アテステーション・プロセスは、構成可能なビジネス・プロセスとしてOracle Identity Managerに実装され、ユーザーのアテステーション・タスクを作成します。レビューアを務めるユーザーは、このプロセスを完了して正確な監査情報を提供する必要があります。

プロビジョニング済リソース・インスタンスのアテステーション・アクティビティのトラッキングは、リソース・オブジェクトのプロビジョニング・プロセス内のタスクにより実行されます。アテステーション・アクションに基づいてワークフロー・アクティビティを開始することができます。開始される追加アクティビティと、プロセス定義フォームやワークフロー・デザイナでモデリング可能なワークフローは、初期アテステーション・アクションに基づいて開始できます。これは、Oracle Identity Managerで定義されているプロビジョニング・プロセス内のアテステーション・サブフローにより実現されています。

アテステーション・アクティビティは、定期的にまたは必要に応じて開始できます。

レビューアは、アテステーション・タスク内の特定の権限を、レビューのため他のユーザーに委任することができます。このアクションは、別のアテステーション・タスクが作成され、委任されたユーザーに割り当てられることで行われます。

この項では、次の項目について説明します。

- アテステーション・プロセスの定義

- アテステーション・タスクのコンポーネント

- アテステーション・リクエスト

- 委任

- アテステーション・ライフサイクル・プロセス

- アテステーション・エンジン

- アテステーション・スケジュール済タスク

- アテステーションドリブンのワークフロー機能

- アテステーションの電子メール

19.1.1 アテステーション・プロセスの定義

アテステーション・プロセスは、アテステーション・タスクを設定するメカニズムです。アテステーション・プロセスに必要な入力内容には、アテステーション・タスクを構成するコンポーネントの定義方法、およびタスクを実行する必要のあるスケジュールとアテステーション・タスクを関連付ける方法に関する情報が含まれます。この定義も、アテステーション・タスクを必要なときに開始するための基盤です。アテステーション・プロセスの定義には次の項目が含まれています。

- ユーザー・スコープまたはリソース・スコープ: アテステーション・プロセスのターゲット・ユーザー権限を決定するアルゴリズムを定義します。

- レビューア設定: 他のユーザーの権限をアテストするレビューアを指定します。アテステーション・プロセスでは、特定のユーザーをレビューアとして指定することも、レビューアの選択方法を抽象的に指定することもできます。たとえば、レビューアを、ユーザーのマネージャ、リソースの管理者、リソースへのアクセスの認可者、または権限を付与するロールのメンバーとして指定できます。

- アテステーション・スケジュールの定義: アテステーション・プロセスを実行するスケジュールを指定します。

- プロセス所有者: プロセスに関連するアクティビティの監視を割り当てられているユーザーのグループです。

- このユーザーには、プロセス実行時に発生する問題がすべて通知されます。

- プロセス定義を表示する権限はありますが、デフォルトでは管理権限はありません。

- 必要に応じていつでもプロセスを実行できます。

プロセスが一連のレビューアを定義している場合、単一のアテステーション・プロセスから複数のアテステーション・タスクが発生することもあります。このような場合、プロセスから、各レビューアに対して1つずつアテステーション・タスクが発生することになります。

19.1.1.1 アテステーション・プロセスの制御

次の各項では、アテステーション・プロセスの制御方法について説明します。

19.1.1.1.1 プロセスの無効化

システム管理者は、アテステーション・プロセスが事前定義済スケジュールどおりに実行されないように、プロセスを無効化できます。これにより、管理者は環境を制御しやすくなります。システム管理者のアテステーション・プロセスは有効化できますが、次回実行時間の値を過ぎると有効化できません。アテステーション・プロセスを有効化するユーザーは、次の実行予定時刻を未来に設定する必要があります。

19.1.1.1.2 プロセスの削除

アテステーション・プロセスは削除できます。これは、ソフト削除と呼ばれます。レコードは監査のために保持する必要があるため、これによってレコードが実際に削除されることはありません。かわりに、アテステーション・プロセスは削除とマークされます。

削除されたプロセスはOracle Identity Manager管理およびユーザー・コンソールに表示されません。プロセス名とコードは一意であるため、一度使用した名前が使用不可になると、その名前で新しいアテステーション・プロセスを作成することはできません。

19.1.2 アテステーション・タスクのコンポーネント

アテステーション・プロセスの基本目的は、Oracle Identity Managerにアテステーション・タスクを設定することです。アテステーション・タスクはOracle Identity Managerセルフサービスのタスクリストの「アテステーション」タブに表示され、このタスクを自分で管理することも、他のユーザーに管理を委任することもできます。アテステーション・タスクの基本コンポーネントを次に示します。

- レビューア: アテステーションを実行するユーザーを指定します。

- タスク・ソース: アテステーション・タスクがプロセスの結果として発生したのか、別のレビューアの委任によって発生したのかを指定します。委任の場合は、タスクを委任したレビューアが誰で、どのタスクが権限のソースであるかをトラッキングする必要があります。

- アテステーション・データ: アテステーション・スコープ内のユーザー権限の詳細データです。このデータは、プロビジョニングされたリソース・インスタンスのプロセス・フォームからのデータです。

- アテステーション日: アテステーション・タスクを開始する日付を定義します。

- アテステーション・アクション: レビューアがアテステーション・スコープで行うアクションです。アクションはアテステーション・タスク全体のレベルではなく、アテステーション・スコープ内の各権限に対して行われます。アテステーション・アクションには次のものがあります。

- 認証: レビューアは、特定データや詳細な権限を含む現在のフォームの権限の保持をレビュー対象ユーザーに許可することに同意しています。

- 却下: レビューアは、フォームのこの権限をユーザーが持つ必要がないと考えています。

- 拒否: レビューアは権限のアテスト業務を引き受けられません。このアクションは通常、プロセスが適切に構成されていない場合のためのもので、公開後の早い段階で有用です。
レビューアは、他の誰かにタスクの処理を求める場合にタスクを拒否します。タスクが拒否されると、そのタスクはシステム管理者ロールの任意のユーザーに割り当てられます。

- 委任: レビューアは別の有資格者にこの権限のアテステーションを再割当てすることを考えています。

注意:

アテステーション・タスクは、Oracle Identity Manager定義におけるワークフロー・タスクではありません。ワークフローの一部としては作成されません。アテステーション・タスクは、ワークフロー・エンジンがサポートする動的割当て、エスカレーション、プロキシ管理などのすべてのタスク管理機能をサポートしません。

19.1.2.1 アテステーション受信ボックス

レビューアは、セルフサービスのタスクリストの「アテステーション」タブから各アテステーション・タスクの詳細を表示できます。アテステーション・タスクで、レビューアは、個々の権限に対するレスポンスやコメントを入力できます。

19.1.3 アテステーション・リクエスト

アテステーション・プロセスが実行されると、アテステーション・リクエストが作成され、Oracle Identity Managerデータベースに記録されます。このリクエストは、アテステーション・プロセスが実行される際の監査のために記録されます。アテステーション・リクエスト・レコードは、レポートで使用される、基本的な識別データと監査データ、および統計データから構成されています。データには次の項目が含まれています。

- リクエスID: 各アテステーション・リクエストには一意の識別子があります。リクエストの結果としてOracle Identity Managerが作成する各アテステーション・タスクには、関連付けられたアテステーション・リクエストのリクエストIDがそのレコードの一部として格納されます。

- プロセス実行の日付と時刻

- プロセス完了の日付と時刻: プロセス完了の日付と時刻は、そのリクエストの日付と時刻とみなされます。

- アテステーションで識別されている権限の総数。
アテステーション・プロセスの特定の実行で(アテステーション・プロセスのリソース・スコープの)選択基準に一致したプロビジョニング済リソースの数。

- 認証された権限の数

- 却下された権限の数

- 拒否された権限の数

19.1.4 委任

アテステーション・タスクに割り当てられたレビューアが、タスク内のすべての権限をアテストできない場合があります。これには様々な理由が考えられます。次に例を示します。

- アテステーション・タスク内の、ユーザーと権限が多すぎます。

- レビューアが、権限をプロビジョニングされた理由を明確に知りません。

こうした場合、レビューアが他のユーザーをレビューに参加させたいと考えることがあります。レビューアは、タスク内の一部の権限のアテステーションを委任できます。

アテステーションを委任するには、レビューアがタスク内で権限のセットを選択し、それを他のユーザーに委任します。これにより新しいアテステーション・タスクが作成され、選択されたレビューアに割り当てられます。

この新しいタスクには、元のレビューアが選択した権限のみが含まれます。元のレビューアは、それらの権限に対するアテステーション・レスポンスを用意する責任がなくなります。委任先に割り当てられた新しいアテステーション・タスクは、その委任を実行したレビューア、その委任の作成元タスク、および他のいくつかの情報(リクエストIDなど)をトラッキングします。この新しいアテステーション・タスクは、他のアテステーション・タスクと同じ方法で処理されます。このタスクをさらに委任することもできます。図19-1に、アテステーション・ページを示します。

図19-1 アテステーションの委任

19.1.5 アテステーション・ライフサイクル・プロセス

Oracle Identity Managerにおけるアテステーション・ライフサイクルについて、次に説明します。

19.1.5.1 第1段階: アテステーション・タスクの作成

この段階は、アテステーション・プロセスの実行時に開始されます。図19-2に、この段階に含まれるワークフローを示します。

図19-2 アテステーション・タスクの作成: ワークフロー

「図19-2 アテステーション・タスクの作成: ワークフロー」の説明

アテステーション・プロセスが実行されると、最初に、対応するアテステーション・プロセス・インスタンスが作成されます。次に、このプロセスを実行したレビューアが識別されます。ほとんどの場合、レビューアは1人のみです。ただし、一連のレビューアが存在する可能性もあります。

無効なレビューアが検出された場合は、常に新しいレビューアがプロセス所有者グループから取得されます。Oracle Identity Managerにより、可能な場合は、プロセス所有者グループのメンバーのうち、レビューアとして使用されていないメンバーがこのアテステーション・リクエストに対して選択されます。これが可能でない場合は、プロセス所有者グループのすでにレビューアとして選択されているメンバーが選択されます。プロセス所有者グループのメンバーが見つからない場合は、システム管理者(XELSYSADM)がこのアテステーション・タスクのレビューアに割り当てられます。

プロセスでは、そのプロセスに定義されたアテステーション・スコープによる決定に従って、そのタスクの一環としてレビューアがアテストする必要があるすべてのユーザー権限が有効なレビューアごとに計算されます。次に、それらのユーザー権限に関連する参照および情報がタスクのアテステーション・データに追加されます。また、そのタスクの対象とする権限の数が、プロセス・インスタンスでアテステーションに対して識別された権限の総数を示す統計フィールドに追加されます。次に、電子メールがレビューアに送信されます。また、電子メール・アドレスが定義されていないレビューアについては、プロセス所有者に電子メールが送信されます。

この段階の終了時、アテステーション・タスクはすべて、レビューアのアテステーション受信ボックスにあります。

19.1.5.2 第2段階: アテステーション・タスクに関する作業

アテステーション・タスクがレビューアに割り当てられると、レビューアは電子メールを受信し、タスクは各レビューアのアテステーション受信ボックスに表示されます。レビューアは自分の受信ボックスでタスクの詳細を参照します。

レビューアは、タスク詳細のページから各権限に対して、レスポンスおよび必要に応じてコメントを入力します。これにより、タスク内のアテステーション権限の詳細に、「レスポンス入力済」のマークが付けられます。

レビューアのレスポンスに、特定の権限のアテステーション・アクティビティの委任が含まれている場合は、レビューアは委任するユーザーを入力する必要があります。レビューアはオプションとして、なぜそのユーザーにアテステーション・アクティビティを委任するか説明するコメントを入力することができます。

レビューアは、すべての権限にレスポンスを入力した後、すべてのレスポンスを送信することによって、アテステーション・タスクのアクションをコミットすることができます。

図19-3 レビューアが権限に対するレスポンスを送信する場合のイベントのフロー

「図19-3 レビューアが権限に対するレスポンスを送信する場合のイベントのフロー」の説明

この時点で、次の段階であるアテステーション・ビジネス・プロセスが開始されます。

19.1.5.3 第3段階: 送信されたアテステーション・タスクの処理

アテステーション・タスクは「送信済」とマークされています。この時点でアテステーション・タスクは凍結され、それ以上作業できません。アテステーション・タスクの各権限について、レスポンスがシステムによって調査されます。レスポンスが認証または却下の場合、その権限に対応するプロビジョニング済のリソース・インスタンスが、それに応じて更新されます。プロビジョニング済のリソース・インスタンスのレベルで、最後のアテステーション結果、最後のアテステーションの発生時刻、および誰がレビューアであったかが記録されます。レスポンスが拒否または委任だった場合、プロビジョニング済リソース・レベルでのアテステーション詳細は変更されません。

「ユーザー・アテステーション・イベントが発生しました」タスクが、リソース・インスタンスのプロビジョニング・プロセスに挿入されます。これにより、定義されている場合にはアテステーション・ドリブンのワークフローが開始されます。コメントはすべてタスクのメモ・フィールドに保存されます。

タスクのアテステーション権限の詳細に、レスポンス送信済のマークが付けられます。図19-4に、アテステーション・タスクのレスポンス送信後のイベント・フローを示します。

図19-4 アテステーション・タスクのレスポンス送信後のイベント・フロー

「図19-4 アテステーション・タスクのレスポンス送信後のイベント・フロー」の説明

次の統計情報が、プロセス・インスタンスに基づいて更新されます。

- 認証された権限の数

- 却下された権限の数

- 拒否された権限の数

- 委任された権限の数

すべての権限を処理した後で、フォローアップ・アクションのサブフローが開始されます。このフローでは、プロセスによって、タスクの権限のいずれかに対するレスポンスが拒否されたかどうかが調べられます。そのような権限があった場合、プロセスは拒否アクションの詳細を概説した電子メールをプロセス所有者に送信します。

次に、タスクの権限のいずれかに対するレスポンスが委任されたかどうかが調べられます。そのような権限があった場合、レビューアが委任先として選択したすべてのユーザーが識別され、それぞれのアテステーション・タスクが作成されます。各アテステーション・タスクは、レビューアがそのユーザーに委任した権限のみに関するものです。委任されたユーザーは、電子メールで委任を通知されます。

委任されたアテステーション・タスクがすべて作成されると、サブフローは終了し、メイン・フローに合流します。図19-5に、フォローアップ・アクション・サブフローのイベントのフローを示します。

図19-5 フォローアップ・アクション・サブフロー

「図19-5 フォローアップ・アクション・サブフロー」の説明

フォローアップ・サブフローが完了すると、アテステーション・タスクには「完了」のマークが付けられます。

19.1.6 アテステーション・エンジン

アテステーション・エンジンにはアテステーション・ライフサイクルが実装されます。これはOracle Identity Managerアーキテクチャのサービスで、指示を受信して特定のアテステーション・プロセスを開始するためのAPIを公開します。このAPIは、アテステーション・スケジュール済タスクに加えて、「アテステーション・プロセスの詳細」ページの「即時実行」ボタンからもコールされて、オンデマンドの実行をサポートします。アテステーション・プロセスを開始する両方のドライバをサポートしています。

アテステーション・エンジンでは、JMSメッセージ・サービスを使用して、オフラインの待機中プロセスを実行します。これにより、パフォーマンスが向上します。

注意:

アテステーションはユーザー・プロファイル監査データのエントリに依存します。アテステーション・プロセスに含まれるユーザーの監査エントリが生成されていない場合、レビューアは、アテステーションでユーザーおよびプロセス・フォーム情報を表示できません。このような状況を避けるため、アテステーションを実行する前に、「監査メッセージの発行タスク」スケジュール済タスクが実行されていることを確認してください。

19.1.7 アテステーション・スケジュール済タスク

この新しいシステムのスケジュール済タスクは、Oracle Identity Managerで定義されているアテステーション・プロセスの調査と、システムで必要なアテステーション・タスクの作成を担当します。

このスケジュール済タスクの機能は次のとおりです。

- デフォルトでは、このスケジュール済タスクは毎晩実行されるように設定されています。このスケジュールは、必要に応じて変更できます。

- このスケジュール済タスクは、すべてのアクティブな(システム管理者でない)アテステーション・プロセスに対するアテステーション・プロセス定義表を調査します。

- プロセスの次のスケジュール済タスクの実行時間が経過していることが検出された場合、タスクはアテステーション・エンジンへの呼出しを送信して、アテステーション・プロセスを開始します。

19.1.8 アテステーションドリブンのワークフロー機能

アテステーション・アクティビティからのトリガーをリスニングするように、Oracle Identity Managerで事前定義されているプロビジョニング・プロセスを拡張できます。これにより、プロビジョニング・ワークフローの一部として、アテステーションの発生(拒否の場合は発生しない)に対応し、したがってアテステーションの発生時に開始される、カスタムのワークフローを定義できます。これは2つの目的に役立ちます。

- フローのデフォルトのアテステーション・タスク(「ユーザー・アテステーション・イベントが発生しました」)は、特定のユーザー権限のアテステーション履歴の監査証跡を提供します。

- リソース・インスタンスが適切なタイプのアテステーション・プロセスによってアテストされるたびに、このタスクのインスタンスが1つ発生します。

- タスク上に設定されたレスポンス・コードは、レビューアが入力したレスポンスの種類を示しています。

- タスク作成者のタグを付けられたユーザーは、レビューアが誰であるかを示しています。

- ユーザーが入力したコメントはすべて、タスクのメモ・フィールドに入ります。

- レスポンスが生成したタスクを使用すると、デフォルト・タスクがワークフローを開始して、受け取った特定のアテステーション・レスポンスに対応することができます。このため、特定のリソースについて、却下のレスポンスによってプロビジョニング・プロセスの該当するワークフロー・タスク(たとえばアカウントの無効化など)が開始されるように指定できます。

19.1.9 アテステーションの電子メール

アテステーション・エンジンは、アテステーション・プロセスの一環として、各種の関係者に電子メールを送信します。電子メールの内容を構成できるようにするために、Oracle Identity Managerの「電子メール定義」ストアの「一般」タイプの電子メール・テンプレートが使用可能になります。コンテキストに依存するよう、電子メールでは、必要な値に置き換えられる各種の変数が含まれます。

19.1.9.1 アテステーション・レビューアへの通知

このテンプレートは、アテステーション・タスクが割り当てられているレビューアに送信する電子メールを作成するために使用されます。

19.1.9.1.1 変数

「Notify Attestation Reviewer」テンプレートの変数を次に示します。

変数

説明

Attestation Definition.Process Name

アテステーション・プロセスの名前

Attestation Definition.Process Code

アテステーション・プロセスのコード

Attestation Task.Task Assigned Date

アテステーション・タスクが割り当てられた日付

19.1.9.1.2 件名行

「Notify Attestation Reviewer」テンプレートにより定義された電子メール・メッセージの件名行を次に示します。

A new attestation task for attestation process Attestation Definition.Process Name has been added to your attestation inbox

19.1.9.1.3 本文

電子メール・メッセージの本文には次の情報が含まれます。

The attestation task details are as follows
Process Name: Attestation Definition.Process Name
Process Code: Attestation Definition.Process Code
Data Type: Access Rights
Assigned Date: Attestation Task.Task Assigned Date

19.1.9.2 委任されたレビューアへの通知

このテンプレートは、アテステーション・タスクを委任されたレビューアに送信する電子メールを作成するために使用されます。

19.1.9.2.1 変数

「Notify Delegated Reviewers」テンプレートの変数を次に示します。

変数

説明

Attestation Definition.Process Name

アテステーション・プロセスの名前

Attestation Definition.Process Code

アテステーション・プロセスのコード

Attestation Task.Task Assigned Date

アテステーション・タスクが割り当てられた日付

Attestation Task.Delegated By First Name

委任を行ったレビューアの名

Attestation Task.Delegated By Last Name

委任を行ったレビューアの姓

Attestation Task.Delegated By User Id

委任を行ったレビューアのユーザーID

19.1.9.2.2 件名行

「Notify Delegated Reviewers」テンプレートにより定義された電子メール・メッセージの件名行を次に示します。

Attestation Task.Delegated By User Id has delegated to you an attestation task from attestation process Attestation Definition.Process Name

19.1.9.2.3 本文

メッセージの本文には次の情報が含まれます。

The attestation task details are as follows
Process Name: Attestation Definition.Process Name
Process Code: Attestation Definition.Process Code
Data Type: Access Rights
Assigned Date: Attestation Task.Task Assigned Date
Delegated By: Attestation Task.Delegated By First Name Attestation Task.Delegated By Last Name [Attestation Task.Delegated By User Id]

19.1.9.3 拒否されたアテステーション権限についてのプロセス所有者への通知

「Notify Declined Attestation Entitlements」テンプレートは、拒否された権限アテステーション・タスクについてプロセス所有者に通知するために送信する電子メールを作成するために使用されます。

19.1.9.3.1 変数

「Notify Process Owner about Declined Attestation Entitlements」テンプレートの変数を次に示します。

変数

説明

Attestation Request.Request Id

アテステーション・リクエストのID

Attestation Definition.Process Name

アテステーション・プロセスの名前

Attestation Task.Reviewer First Name

レビューアの名

Attestation Task.Reviewer Last Name

レビューアの姓

Attestation Task.Reviewer User Id

レビューアのユーザーID

Attestation Data.Provisioned User First Name

アテストされるユーザーの名

Attestation Data.Provisioned User Last Name

アテストされるユーザーの姓

Attestation Data.Provisioned User Id

証明されるユーザーのユーザーID

Attestation Data.Resource Name

アテストされるリソースの名前

Attestation Data.Entitlement Descriptive Data

アテストされる権限の説明データ

19.1.9.3.2 件名行

「Notify Process Owner about Declined Attestation Entitlements」テンプレートにより定義された電子メール・メッセージの件名行を次に示します。

User access rights in attestation request Attestation Request.Request Id have been declined by Attestation Task.Reviewer User Id

19.1.9.3.3 本文

メッセージの本文は次のとおりです。

Attestation of the following user access rights were declined by the reviewer.
Reviewer: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id]
Attestation Process: Attestation Definition.Process Name
Attestation Request ID: request Attestation Request.Request Id
Access Rights Data: Attestation Data.Provisioned User First Name Attestation Data.Provisioned User Last Name [Attestation Data.Provisioned User User Id] - Attestation Data.Resource Name - Attestation Data.Entitlement Descriptive Data

19.1.9.3.4 スペシャル・コメント

権限データ項目はそれぞれ新しい行に表示されます。

19.1.9.4 電子メールが定義されていないレビューアについてのプロセス所有者への通知

「Attestation Reviewers With No Email Defined」テンプレートは、電子メール・アドレスが定義されていないレビューアについて、プロセス所有者に通知するために送信する電子メールを作成するために使用されます。

19.1.9.4.1 変数

「Notify Process Owner About Reviewers with No Email Defined」テンプレートの変数は次のとおりです。

変数

説明

Attestation Request.Request Id

アテステーション・リクエストのID

Attestation Definition.Process Name

アテステーション・プロセスの名前

Attestation Request.Request Creation Date

アテステーション・リクエストが作成された日付

Attestation Task.Reviewer First Name

無効なレビューアの名

Attestation Task.Reviewer Last Name

無効なレビューアの姓

Attestation Task.Reviewer User Id

無効なレビューアのユーザーID

19.1.9.4.2 件名行

「Notify Process Owner About Reviewers with No Email Defined」テンプレートにより定義される電子メールの件名行を次に示します。

E-mail address is not defined for some of the reviewers in attestation process Attestation Definition.Process Name, request Attestation Request.Request Id

19.1.9.4.3 本文

メッセージの本文は次のとおりです。

The following attestation reviewers do not have e-mail addresses defined. Attestation requests have been generated for these reviewers and can be accessed by logging in to Oracle Identity Manager. However, notification e-mails were not sent.
Attestation process: Attestation Definition.Process Name
Attestation Request ID: request Attestation Request.Request Id
Request date: Attestation Request.Request Creation Date
Reviewers Without Email: Attestation Task.Reviewer First Name Attestation Task.Reviewer Last Name [Attestation Task.Reviewer User Id]

19.1.9.4.4 スペシャル・コメント

レビューアの詳細はそれぞれ新しい行に表示されます。

19.2 アテステーション・プロセスの設定

Oracle Identity Manager管理およびユーザー・コンソールのメニュー項目から、アテステーション・プロセスの構成ページにアクセスできます。Oracle Identity Manager管理者は、このページを使用して次を実行できます。

- 新しいアテステーション・プロセスの定義

- 既存のプロセスの管理

- 非定型アテステーション・プロセスの開始

19.2.1 メニュー構造

最上位の「アテステーション」メニューには、Oracle Identity Manager拡張管理の「ポリシー」セクションへの次のリンクが表示されます。

- アテステーション・プロセスの作成

- アテステーション・プロセスの管理

これらのメニュー項目は、拡張管理のすべてのメニュー項目を管理する同一の委任管理権限により管理されています。

これらのメニュー項目は定義済ですが、Oracle Identity Managerのグループには割り当てられていません。監査コンプライアンス・コンポーネントがインストールされている場合、それらはOracle Identity Managerの「システム管理者」グループに割り当てられます。

19.2.2 システム制御

アテステーションには次の依存性があります。

- ユーザー・プロファイル監査機能を有効にする必要があります。

- 履歴データは、少なくともプロセス・フォーム・レベルまで収集する必要があります。

監査レベルが必要なレベルより下に設定されている場合、アテステーションに関連するメニュー項目のリンクをクリックすると「アテステーション機能は使用できません」ページが生成され、ユーザーによるアテステーション・プロセスの定義ができなくなります。

監査レベルはXL.UserProfileAuditDataCollectionというシステム・プロパティで制御されており、アテステーション機能では、この値が少なくとも「リソース・フォーム」に設定される必要があります。

19.3 アテステーション・プロセスの作成

注意:

この項で説明する手順には、Oracle Identity Managerの権限モデルが適用されています。このモデルではターゲット(たとえばユーザー)のリストを、ログインしているユーザーが読取りアクセス権を持っているターゲットのみに制限します。

アテステーション・プロセスを作成するには、次の手順を実行します。

1. Oracle Identity Manager拡張管理の「ようこそ」ページの「アテステーション構成」リストで、「作成」をクリックします。
「ステップ1: プロセスの定義」ページが表示されます。

2. フィールドに値を入力して「続行」をクリックします。次の表にフィールドの説明を示します。

フィールド

説明

名前

アテステーション・プロセスの一意の名前。名前は、システム管理者であるアテステーション・プロセスおよび削除されたアテステーション・プロセスの中で一意である必要があります。

コード

プロセスの識別コード(32文字以下)。コードは、システム管理者であるアテステーション・プロセスおよび削除されたアテステーション・プロセスの中で一意である必要があります。

注意: コードを使用すると、アテステーション・プロセスの定義をより詳細に識別できます。ただし、「コード」フィールドに値を指定しない場合、アテステーション・プロセスは一意の名前により識別されます。

説明

アテステーション・プロセスの詳細説明です。

3. 「ステップ2: ユーザー・スコープの定義」ページ:

1. 「属性」リストから属性を選択します。「属性」リストには、FormMetaData.xmlファイルで指定されたユーザー属性およびユーザー・フォームのユーザー定義属性が表示されます。選択した属性は、アテステーション・プロセスが適用されるユーザーが合致する必要のある基準を指定するために使用されます。

2. 「条件」リストから条件を選択します。「条件」リストに表示される値は、選択した属性のタイプに応じて異なります。たとえば、「属性」フィールドで「ユーザーID」を選択した場合、条件として「含む」、「含まない」、「完全一致」および「完全一致でない」が表示されます。また「開始日」属性を選択した場合、条件として「前」、「後」および「間」が表示されます。

3. 「値」フイールドに、ユーザー属性の値を入力します。

4. 「再帰的」オプションを選択します。「再帰的」チェック・ボックスは、ユーザー・スコープを定義する際に子エンティティを含めるエンティティに対して使用します。たとえば、ユーザー・スコープで「組織」を選択し、次に「再帰的」を選択すると、すべての下位組織も操作の対象となります。

5. 「追加」をクリックしてユーザー・スコープ表に新規行を追加し、「続行」をクリックします。ユーザー・スコープ表に複数の行を追加した場合、アテステーション・プロセスは、ユーザー・スコープのすべての属性条件に一致するユーザーにのみ適用されます。

4. 「ステップ3: リソース・スコープの定義」ページで、次のようにアテステーション・プロセスのリソースを選択します。

1. 「属性」リストから、次の表で示したリソース属性のいずれかを選択します。

属性

式

説明

名前

フルテキストまたはワイルドカード

リソースの名前。

タイプ

「すべて」または「サブセット」の選択オプションを持つ参照値

リソースのタイプ。

リソース監査目的

「すべて」または「サブセット」の選択オプションを持つ参照値

プロビジョニングされるリソースに割り当てられる監査目的。たとえば、そのリソースが財務的に意味を持つかどうかを示す。

「リソース監査目的」の詳細は、「リソースの詳細の表示」を参照してください。

管理者ユーザー・グループ

「すべて」または「サブセット」の選択オプションを持つ参照値

リソースの管理権限を持つユーザー・グループ。

認可ユーザー・グループ

「すべて」または「サブセット」の選択オプションを持つ参照値

リソースの認可者または承認者であるユーザー・グループ。

リソース・ステータス

フルテキストまたはワイルドカード

リソースがユーザーにプロビジョニングされる際に表示されるステータス(「認証」、「却下」、「オープン」、「クローズ」など)。

2. 「条件」リストから検索条件を選択します。

3. 「値」フイールドに、リソース属性の値を入力します。

4. 「追加」をクリックしてリソース・スコープ表に新規行を追加し、「続行」をクリックします。リソース・スコープ表に複数の行を追加した場合、アテステーション・プロセスは、リソース・スコープのすべての属性条件に一致するリソースにのみ適用されます。

5. 「ステップ4: 管理詳細の定義」ページで、次の手順を実行して、データをアテストするレビューア、アテステーション・プロセスのスケジュール、猶予期間およびプロセス所有者を定義します。

1. 「レビューア」リストから、アテステーション・プロセスのレビューアのタイプ(ある特定のユーザー、ロール・メンバー、リソース管理者など)を選択します。次に、隣にある「参照フィールド」からレビューアを選択します。
レビューアのタイプとして「ロール・メンバー」を選択した場合は、特定のアテステーション・タスクをレビューするロールを選択する必要があります。作成されて実行されたアテステーション・タスクは、次の条件に基づいて、選択したロールに割り当てられます。

- アテステーション・タスクは、「無効」および「削除」状態でないすべてのユーザーに割り当てられます。

- そのロールのレビューアが受益者でもある場合、アテステーション・タスクはそのユーザーには割り当てられません。

- 前述のチェック後、ロールに適格なユーザーがいない場合は、システム管理者ロールのすべてのユーザーにタスクが割り当てられます。

2. アテステーション・プロセスを1回実行するか、または特定の日数、月数または年数ごとに繰り返し実行するかといったアテステーション・プロセスのスケジュールを指定します。

3. 猶予期間、つまり、このアテステーション・プロセスで生成されたアテステーション・タスクに各レビューアが応答する必要がある期間の日数を指定します。

4. 「開始日」フィールドで、アテステーション・プロセスの開始日を指定します。

5. 「プロセス所有者グループ」参照フィールドで、アテステーション・プロセスの所有者であるグループを指定します。

6. アテステーション・プロセスがレビューアに拒否された場合に、プロセス所有者に電子メールで通知するには、「レビューアがアテステーション・リクエストを拒否した場合、プロセス所有者に電子メール」を選択します。次に、「続行」をクリックします。

6. 「ステップ5: 情報検証ページ」で、アテステーション・プロセスの詳細を確認した後、「プロセスの作成」をクリックします。
アテステーション・プロセス定義が正常に作成されたことを示すメッセージが表示されるページに切り替わります。プロセス名をクリックすると、「アテステーション・プロセスの詳細」ページが表示されます。別のアテステーション・プロセスを作成するには、「別のアテステーション・プロセス定義を作成」をクリックします。

「アテステーション・プロセスの詳細」ページの詳細は、「アテステーション・プロセスの管理」を参照してください。

19.4 アテステーション・プロセスの管理

アテステーション・プロセスを管理するには次の手順を実行します。

1. 「ようこそ」ページで、「アテステーション・プロセスの管理」をクリックし、次に「管理」をクリックします。「アテステーション・プロセスの管理」ページが表示されます。

2. 「アテステーション・プロセスの管理」ページで、管理するアテステーション・プロセスの検索基準を入力します。アテステーション・プロセス名、プロセス・コード、レビューア・タイプまたはプロセス所有者で検索できます。検索基準を入力した後、「検索」をクリックします。検索基準に一致するアテステーション・プロセスが「アテステーション・プロセスの詳細」ページに表示されます。表示されるのは、ログインした管理者が権限に基づいてまたはプロセス所有者グループのメンバーであるという理由で表示を許可されているアテステーション・プロセスです。このページには削除されたプロセスは表示されません。このページに表示される列を次の表に示します。

列

説明

名前

プロセスの名前を指定します。

コード

アテステーション・プロセスのコードを指定します。

説明

プロセスの説明を指定します。

ステータス

アテステーション・プロセスが有効であるかシステム管理者であるかを示します。

タイプ

リソースのタイプを指定します。

ユーザー・スコープ

アテステーション・プロセスの一部となるユーザーのスコープを指定します。

リソース・スコープ

アテステーション・プロセスのスコープ内にあるリソースを指定します。

レビューア・タイプ

レビューアのタイプを示します。

レビューア名

レビューアの名前を示します。

スケジュール

プロセスが1回のみ、または毎日、毎月または毎年といったスケジュールで実行されるかを示します。

最終開始

アテステーション・プロセスが最後に実行されたタイミングを指定します。

次回開始

スケジュールによりプロセスが次回実行されるタイミングを指定します。

プロセス所有者グループ

プロセス所有者グループを示します。また、アテステーション・リクエストがレビューアに拒否された場合に、プロセス所有者に電子メールで通知するかどうかも示します。

前回の完了

このプロセスのインスタンスが最後に完了したタイミングを指定します。

ここでは次のトピックについて説明します。

- アテステーション・プロセスの編集

- アテステーション・プロセスの無効化

- アテステーション・プロセスの有効化

- アテステーション・プロセスの削除

- アテステーション・プロセスの実行

- アテステーション・プロセス管理者の管理

- アテステーション・プロセス実行履歴の表示

19.4.1 アテステーション・プロセスの編集

アテステーション・プロセスを編集するには次の手順を実行します。

1. 「アテステーション・プロセスの詳細」ページで、「編集」をクリックします。

2. 「アテステーション・プロセスの編集」ページでアテステーション・プロセスに必要な変更を加え、「保存」をクリックします。
「アテステーション・プロセスの編集」ページのフィールドは、「アテステーション・プロセスの作成」で表示されるフィールドと同じです。

19.4.2 アテステーション・プロセスの無効化

アクティブなアテステーション・プロセスを削除するには、次の手順を実行します。

1. 「アテステーション・プロセスの詳細」ページで、「無効化」をクリックします。
「無効化」ボタンが表示されるのは、プロセスがアクティブである場合のみです。

2. 「アテステーションの無効化の確認」ページで「無効化の確認」をクリックします。

19.4.3 アテステーション・プロセスの有効化

アテステーション・プロセスを有効化できるのは、次の開始時刻が未来で、プロセスが無効化されている場合のみです。

アテステーション・プロセスを有効化するには次の手順を実行します。

1. 「アテステーション・プロセスの詳細」ページで、「有効化」をクリックします。
「有効化」ボタンが表示されるのは、プロセスが無効化されている場合のみです。

2. 「アテステーションの有効化の確認」ページで「有効化の確認」をクリックします。

19.4.4 アテステーション・プロセスの削除

アテステーション・プロセスの編集、無効化および削除を実行できるのは、必要な権限を持つプロセス管理者のみです。

アテステーション・プロセスを削除するには次の手順を実行します。

1. 「アテステーション・プロセスの詳細」ページで、「削除」をクリックします。

2. ページで「削除の確認」をクリックします。

19.4.5 アテステーション・プロセスの実行

この機能を使用すると、未スケジュールのアテステーション・プロセスを実行できます。アテステーション・プロセスを実行するには、「アテステーション・プロセスの詳細」ページで「即時実行」をクリックします。これにより、アテステーション・スケジュールとは独立してアテステーション・プロセスが開始されます。

未スケジュールのアテステーション・プロセスを開始できるのは、プロセス所有者グループのユーザーのみです。

19.4.6 アテステーション・プロセス管理者の管理

アテステーション・プロセスのための管理グループの追加、削除および更新のタスクは、ユーザーおよび組織のために管理グループを更新するタスクに類似しています。

アテステーション・プロセスの管理者を管理するには、「アテステーション・プロセスの詳細」ページの「追加詳細」リストから「管理者」を選択します。「管理グループ」ページが表示されます。このページを使用して、アテステーション・プロセスのための管理者の追加や削除、および管理者権限の更新を行うことができます。

アテステーション・プロセス定義の権限モデルは次のとおりです。

- アテステーション・プロセス定義を表示するには、ユーザーは次のいずれかである必要があります。

- 「管理者グループ」において適切な読取り権限を持つグループのメンバー

- プロセス所有者であるグループのメンバー

- アテステーション・プロセス定義を編集するには、ユーザーは、「管理者グループ」において必要な書込み権限を持つグループのメンバーである必要があります。

- アテステーション・プロセス定義を削除するには、ユーザーは、「管理者グループ」において必要な削除権限を持つグループのメンバーである必要があります。

19.4.7 アテステーション・プロセス実行履歴の表示

アテステーション・プロセスの実行履歴を表示するには、「アテステーション・プロセスの詳細」ページの「追加詳細」リストから「実行履歴」を選択します。「アテステーション・プロセス実行履歴」ページが表示されます。

「アテステーション・プロセス実行履歴」表には次の列があります。

列

説明

リクエストID

実行されたアテステーション・プロセス・インスタンスのID。

レビューア

アテステーション・プロセスのレビューアの名前。

開始日

リクエストが開始された日付と時刻。

完了日

リクエストが完了した日付と時刻。

リクエストが保留中の場合は、「未完了」と表示されます。

「アテステーション・プロセス実行履歴」ページで、「リクエストID」リンクをクリックすると「リクエストの詳細」ページが開きます。このページでは、状態が認証済か、却下されたか、オープンか、クローズかに応じてリクエストをフィルタリングできます。

19.5 アテステーション・ダッシュボードの使用

自分がメンバーであるグループが所有するアテステーション・プロセスの状態を表示するには、アテステーション・ダッシュボードを使用します。

アテステーション・ダッシュボードを使用するには、拡張管理の「ようこそ」ページで、「イベント管理」の下にある「アテステーション・ダッシュボードの起動」をクリックします。または、「イベント管理」タブをクリックし、「アテステーション」リストから「アテステーション・ダッシュボード」を選択します。「アテステーション・ダッシュボード」ページには、自分がメンバーであるグループが所有するアテステーション・プロセスの状態がリストされた表が表示されます。「アテステーション・ダッシュボード」表には、次の表に示す列が表示されます。

列

説明

プロセス・コード

アテステーション・プロセス・コード。

プロセス名

プロセスの名前。アテステーション・プロセス名のリンクをクリックすると「アテステーション・プロセスの詳細」ページが表示されます。

前回の完了

最後のインスタンスの前に実行されたインスタンスが完了した日付と時刻。存在しない場合、値は「なし」です。これは、目的のアテステーション・リクエストの「アテステーション・リクエストの詳細」ページに移動するリンクです。

現在のリクエスト日

このプロセスの最後のインスタンスが実行された日付と時刻。実行されていない場合、値は「新規」です。これは、目的のアテステーション・リクエストの「アテステーション・リクエストの詳細」ページに移動するリンクです。

現在完了

最後に実行されたインスタンスが完了した日付と時刻。完了していない場合、値は「保留」です。

全レコード

アテステーションに対して識別されている権限および最後のプロセス・インスタンスの一部としてアテステーションの対象とされている権限の総数。

認証済

最後のアテステーション・プロセス・インスタンスで認可された権限の数。

却下

最後のアテステーション・プロセス・インスタンスで却下された権限の数。

オープン

レビューアによりレスポンスが入力されなかったすべてのオープン・レコード。

19.5.1 アテステーション・リクエスト詳細の表示

「アテステーション・ダッシュボード」ページからドリルダウン・ページにアクセスできます。ドリルダウン・ページには、アテステーション・プロセスの特定の実行で処理するすべての権限のアテステーション詳細が表示されます。

アテステーション・リクエスト詳細を表示するには、次の手順を実行します。

1. 「アテステーション・ダッシュボード」ページの表に表示された「前回の完了」フィールドまたは「現在のリクエスト・ページ」フィールドのリンクをクリックします。
「アテステーション・リクエストの詳細」ページには、選択したアテステーション・プロセスのリクエスト詳細が、次の列を含む表とともに表示されます。

列

説明

ユーザー

権限がアテスト対象となっているユーザー。データはリンクとして表示されます。このリンクをクリックすると、「ユーザー・プロファイル」ページが表示され、アテステーション日のユーザーの詳細が表示されます。

リソース

アテストされる権限の基盤であるリソース。データはリンクとして表示されます。リンクをクリックすると、ページが表示され、アテステーション日の権限のプロセス・フォーム・データが表示されます。

記述データ

プロビジョニング・リソース・インスタンスの説明。

コメント

リクエストのコメントまたはステータス。この値は次のいずれかです。

- 認証

- 却下

- オープン

- クローズ

アテステーション結果

アテステーションに対して入力された最後のレスポンス。

レビューア

レスポンスを入力したユーザー。データはリンクとして表示されます。このリンクをクリックすると、「ユーザー・プロファイル」ページが表示され、現在のユーザーの詳細が表示されます。

委任パス

権限のアテステーションが委任を経由して実行された場合、この列の「表示」リンクを使用して、「委任パスの詳細」ページを表示できます。委任が発生しなかった場合、「なし」と表示されます。

コメント

レビューア・コメント。長いコメントは切り捨てられ、ツールチップを使用してコメントの全文が表示されます。

2. 委任が必要なアテステーション・リクエストには、「委任パス」列にリンクが含まれます。
リンクをクリックすると、「委任パス」ページに、アテステーション・リクエストの委任パスに関する情報が表示されます。

「アテストされたデータ」フィールドには、アテスト対象権限の詳細が表示されます。値は、ユーザー情報、リソース名および記述データをまとめて次の形式で構成されます。

User_First_Name User_Last_Name [User_ID] - Resource_Name - Descriptive_Data

「委任パス」ページの表にあるフィールドは次のとおりです。

列

説明

レビューア

アテストする権限が割り当てられたレビューア。データはリンクとして表示されます。このリンクをクリックすると、現在のユーザー・プロファイル・データが表示されます。

アテステーション結果

レビューアにより行われるアクション。最初のレコードを除き、値は常に「委任済」です。

アテステーション日

レビューアのアテステーション・レスポンスの日付と時刻。

コメント

レビューア・コメント。長いコメントは切り捨てられ、ツールチップを使用してコメントの全文が表示されます。

19.5.2 電子メール通知

アテステーション・プロセスの一部として、アテステーション・エンジンは様々な段階で電子メールを関係者に送信します。電子メールの内容は、Oracle Identity Managerの「電子メール定義」ストアの「一般」タイプの電子メール・テンプレートを使用して構成できます。

テンプレートでは、フォーム・ユーザーはXELSYSADMと定義されます。これは別のユーザーに変更できます。電子メール・アドレスが、このテンプレートを使用するように選択されたユーザーに対して定義されていることを確認してください。定義されていない場合、通知の送信に失敗することがあります。

次の電子メール通知テンプレートを使用できます。

- Notify Attestation Reviewer: アテステーション・タスクがレビューアに割り当てられたときに電子メールを送信するために使用されます。

- Notify Delegated Reviewers: アテステーション・タスクがレビューアに委任されたときにレビューアに電子メールを送信するために使用されます。

- Notify Declined Attestation Entitlements: レビューアが権限を拒否した場合に、「プロセス所有者グループ」のユーザーに電子メールを送信するために使用されます。

- Attestation Reviewers With No Email Defined: どのレビューアにも電子メール・アドレスが定義されていない場合に、「プロセス所有者グループ」のユーザーに電子メールを送信するために使用されます。

19.5.3 アテステーション猶予期間チェッカー・スケジュール済タスク

アテステーション猶予期間チェッカーと呼ばれるシステムのスケジュール済タスクは、Oracle Identity Managerで定義されているアテステーション・プロセスを調査し、必要なアテステーション・タスクを作成するために使用されます。

アテステーション猶予期間チェッカー・スケジュール済タスクの機能は次のとおりです。

- このスケジュール済タスクが、デフォルトで30分間隔で実行されるように設定されています。これは、必要に応じて変更できます。

- このスケジュール済タスクでは、すべてのアクティブなアテステーション・プロセスを調査します。

第V部

レポート

この部では、レポート機能を使用したOracle Identity Manager委任管理機能について、次の章で説明します。

- 第20章「レポート機能の使用」

20 レポート機能の使用

この章では、次の項目について説明します。

- レポート機能

- Oracle Identity Managerレポートの開始

- Oracle Identity Managerレポートの実行

- サポートされている出力形式

- Oracle Identity Managerのレポート

- 例外レポート

- サード・パーティ製ソフトウェアを使用したレポートの作成

- BI Publisherレポートの必須のスケジュール済タスク

注意:

- Oracle Identity Managerレポートにより、Oracle BI PublisherをOracle Identity Management製品のレポート・ソリューションとして使用できます。

- Oracle Identity Managerレポートは、機能領域に基づいて分類されます。たとえば、アクセス・ポリシー・レポート、アテステーション、リクエストおよび承認レポート、パスワード・ポリシー・レポートなどです。「操作レポート」や「履歴レポート」という名前は使用しなくなりました。

- Oracle Identity Managerレポートにより、Oracle BI Publisherの制限付使用ライセンス、および複数のOracle Identity Management製品用の簡単に使用できるレポート・パッケージが提供されます。

- 大規模なデプロイの場合、特にOracle Identity Managerの広範な監査機能を利用しているデプロイでは、エンタープライズ規模の専用レポート・ソリューションをデプロイすることを強くお薦めします。Oracle Business Intelligence Enterprise Editionなどのツールに基づいたソリューションは、大規模な組織に必要な柔軟性、自動化機能およびパフォーマンスを備えています。

20.1 レポート機能

Oracle Identity Managerのレポート機能は、次のとおりです。

- BI Publisherの事前定義済リストからレポートを選択および表示します。

- レポート情報をフィルタ処理します。

- 任意の形式で画面にレポートを表示します。

- インタラクティブ・レポートを提供します。

20.2 Oracle Identity Managerレポートの開始

BI Publisherを開始する手順は、次のとおりです。

1. 「開始」→Oracle BI Publisherデスクトップ→Oracle - BIPHome10134の順にナビゲートし、BI Publisherの開始をクリックします。
Oracle BI Publisherホーム・ページが表示されます。

2. ユーザー名とパスワードを入力します。

3. 「サインイン」をクリックします。

20.3 Oracle Identity Managerレポートの実行

レポートを実行するには、次の手順を実行します。

注意:

BI Publisherには、Oracle Identity Manager管理およびユーザー・コンソールからアクセスできません。BI Publisherを明示的に開いて、Oracle Identity Manager 11gのレポートにアクセスする必要があります。

1. Oracle Identity Managerレポートを開始します。詳細は、第20.2項「Oracle Identity Managerレポートの開始」を参照してください。

2. 共有フォルダの下にある詳細リンクをクリックします。

3. 次のいずれかを実行して、レポートにアクセスします。

- Oracle Identity Managerレポートをクリックします。

- Oracle Identity Managerレポートの下にある詳細リンクをクリックします。

結果ページに、機能領域に従って分類されたOracle Identity Managerレポートが表示されます。

4. レポートを表示するには:

1. レポートの名前をクリックして選択します。

2. 「表示」をクリックします。

レポート入力パラメータ・ページが表示されます。このページに、レポートの実行に必要な入力パラメータが表示されます。レポート入力パラメータは、フィルタ基準として機能します。

場合によっては、少なくとも1つ以上のパラメータ・フィールドが必須フィールドになります。入力パラメータが不要なレポートもあります。そうでない場合も、1つ以上のフィールドに入力しないとレポートを実行できません。

注意:

入力パラメータ・フィールドを空白のままにして「表示」をクリックすると、そのレポートに関連するすべての情報が表示されます。

5. レポートに含まれている情報を識別するために必要な情報を入力します。

6. 「表示」をクリックして、レポートを実行します。
レポートが表示されます。

20.4 サポートされている出力形式

BI Publisherでは、複数のレポート出力形式をサポートしています。すべてのレポートはネイティブXML形式で生成され、異なる他の出力形式に変換できます。次の形式をサポートしています。

- HTML

- PDF

- RTF

- MHTML

20.5 Oracle Identity Managerのレポート

日付タイプ入力パラメータを含むすべてのレポートでは、日付タイプ入力パラメータに次のデフォルト日付範囲が表示されます。

日付範囲: システム日付の30日前からシステム日付まで

別の日付範囲でレポートを実行する場合は、日付タイプ入力パラメータを任意の日付範囲に変更してください。

Oracle Identity Managerレポートは、機能領域に基づいて分類されるようになりました。たとえば、アクセス・ポリシー・レポート、アテステーション、リクエストおよび承認レポート、パスワード・ポリシー・レポートなどです。「操作レポート」や「履歴レポート」という名前は使用しなくなりました。

Oracle Identity Managerレポートは、機能領域に基づいて次のカテゴリに分類されます。

- アクセス・ポリシー・レポート

- アテステーション、リクエストおよび承認レポート

- ロールおよび組織レポート

- パスワード・レポート

- リソースおよび権限レポート

- ユーザー・レポート

20.5.1 アクセス・ポリシー・レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のアクセス・ポリシー・レポートが提供されます。

- アクセス・ポリシー詳細

- ロール別のアクセス・ポリシー・リスト

20.5.1.1 アクセス・ポリシー詳細

管理者または監査者は、Oracle Identity Managerシステムで定義されているすべてのポリシーの現在のスナップショットを、各ポリシーに関する主要な情報、および各ポリシーがアクティブ化されているインスタンス数とともに表示できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

アクセス・ポリシー名

アクセス・ポリシーの名前

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

説明

ポリシーの説明

承認が必要

ポリシーに対して承認が必要

作成日

ポリシーが作成された日付

アクセス・ポリシーの更新

アクセス・ポリシーの更新

作成者

ポリシー作成者の名前

優先度

ポリシーの優先度

列

次の表に、レポートの列を示します。

レポートの列

説明

リソース名

リソース名

20.5.1.2 ロール別のアクセス・ポリシー・リスト

Oracle Identity Managerシステムに定義されているすべてのポリシーをロール別にリストします。このレポートは、操作およびコンプライアンスのために使用できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ロール名

ロールの名前

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

説明

ポリシーの説明

承認が必要

ポリシーに対して承認が必要

作成日

ポリシーが作成された日付

アクセス・ポリシーの更新

アクセス・ポリシーの更新

作成者

ポリシー作成者の名前

優先度

ポリシーの優先度

列

次の表に、レポートの列を示します。

レポートの列

説明

ロール名

ロールの名前

20.5.2 アテステーション、リクエストおよび承認レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のアテステーション、リクエストおよび承認レポートが提供されます。

- 承認アクティビティ

- アテステーション・プロセス・リスト

- アテステーション・リクエストの詳細

- プロセス別のアテステーション・リクエスト

- レビューア別のアテステーション・リクエスト

- リクエストの詳細

- リクエスト・サマリー

- タスク割当て履歴

20.5.2.1 承認アクティビティ

このレポートにより、管理者は承認、却下または保留されたリクエストを含む承認アクティビティを表示できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

承認者の名

承認者の名

承認者の姓

承認者の姓

承認者のユーザーID

承認者のユーザーID

組織

組織の名前

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

承認者の名

承認者の名

承認者の姓

承認者の姓

承認者のユーザーID

承認者のユーザーID

組織

承認者の組織

受理された承認

受理された承認の件数

却下された承認

却下された承認の件数

保留中の承認

保留中の承認の件数

承認リクエスト合計

承認リクエストの合計数

20.5.2.2 アテステーション・プロセス・リスト

このレポートには、すべてのアテステーション・プロセスの詳細が表示されます。セキュリティ・モデルはこのレポートで実装されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

アテステーション・プロセス名

アテステーション・プロセスの名前

アテステーション・プロセス所有者

アテステーション・プロセスの所有者

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

アテステーション・プロセス名

アテステーション・プロセスの名前

所有者のユーザーID

アテステーション・プロセスの所有者のID

現在のリクエストの日付

リクエストが作成された日付

最終完了の日付

リクエストが完了した日付

認証済

認証されたアテステーション・プロセス

却下

却下されたアテステーション・プロセス

拒否

拒否されたアテステーション・プロセス

委任済

委任されたアテステーション・プロセス

合計

認証済、却下および拒否の合計

20.5.2.3 アテステーション・リクエストの詳細

選択されたOracle Identity Managerアテステーション・リクエストの詳細がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

アテステーション・プロセス名

アテステーション・プロセスの名前

アテステーション・リクエストID

アテステーション・プロセスのID

リクエスト開始日範囲開始

アテステーション・リクエストの開始日

リクエスト開始日範囲終了

アテステーション・リクエストの終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

アテステーション・プロセス名

アテステーション・プロセスの名前

アテステーション・リクエストID

アテステーション・リクエストのID

リクエスト開始日

リクエストが開始される日付

完了

リクエストが完了する日付

認証済

認証されたアテステーション・プロセス

却下

却下されたアテステーション・プロセス

委任済

委任されたアテステーション・プロセス

アクションなし

アクションが実行されないアテステーション・プロセスの数

列

次の表に、レポートの列を示します。

レポートの列

説明

名

アテステーション・リクエストを開始するユーザーの名

姓

アテステーション・リクエストを開始するユーザーの姓

ユーザーID

アテステーション・リクエストを開始するユーザーのID

リソース

リソース名

記述データ

リクエストが完了する日付

レビューアの名

レビューアの名

レビューアの姓

レビューアの姓

レビューアのユーザーID

レビューアのID

アクション

レビューアが実行するアクション

20.5.2.4 プロセス別のアテステーション・リクエスト

このレポートには、ログインしたユーザーが管理者またはアテステーション・プロセスの所有者ロールのメンバーである各プロセスに対するすべてのアテステーション・プロセスおよびリクエストの詳細が表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

アテステーション・プロセス名

アテステーション・プロセスの名前

アテステーション・プロセス所有者

アテステーション・プロセスの所有者

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

アテステーション所有者

アテステーション・プロセス所有者の名前

リクエストの合計数

リクエストの合計数

最終完了日

アテステーションが完了する必要がある日付

現在のリクエストの開始日

アテステーションが開始される日付

列

次の表に、レポートの列を示します。

レポートの列

説明

リクエストID

アテステーション・リクエストのID

開始日

アテステーションが開始される日付

完了日

アテステーションが完了する必要がある日付

認証済

認証されたアテステーション・プロセス

却下

却下されたアテステーション・プロセス

拒否

拒否されたアテステーション・プロセス

委任済

委任されたアテステーション・プロセス

合計アテスト数

認証済レコード、却下レコードおよび拒否レコードの合計

20.5.2.5 レビューア別のアテステーション・リクエスト

アテステーション・リクエストのリストがレビューア別に表示されます。レポートには、各レビューアに関連付けられているリクエストの数および各リクエストの情報が含まれます。さらに、リクエストの作成および完了の時刻も表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

レビューアの名

レビューアの名

レビューアの姓

レビューアの姓

レビューアのユーザーID

レビューアのユーザーID

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

レビューアの名

レビューアの名

レビューアの姓

レビューアの姓

レビューアのユーザーID

レビューアのユーザーID

リクエストの合計数

確認するリクエストの件数

列

次の表に、レポートの列を示します。

レポートの列

説明

リクエストID

アテステーション・リクエストのID

プロセス名

プロセス名。

開始日

アテステーションが開始される日付

完了日

アテステーションが完了する必要がある日付

認証済

認証されたアテステーション・プロセス

却下

却下されたアテステーション・プロセス

拒否

拒否されたアテステーション・プロセス

委任済

委任されたアテステーション・プロセス

合計アテスト数

アテストするリクエストの件数

20.5.2.6 リクエストの詳細

このレポートにより、管理者はすべてのリクエストの詳細(リクエスタ、現在の承認者など)を入力現行ステータスとともに表示できます。また、このレポートにはリクエスト承認の結果としてプロビジョニングされるすべてのユーザーの詳細(ユーザー名、組織、マネージャ詳細、ユーザー・ステータスなど)も表示されます。これにより、管理者は保留リクエストの終了を処理できるように、操作アクティビティを計画して優先順位を付けることができます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リクエスタ・ユーザーの名

リクエスタの名

リクエスタ・ユーザーの姓

リクエスタの姓

リクエスト・ユーザーID

リクエスタのID

リクエストID

リクエストID

リクエスト親ID

リクエストの親ID

リクエスト・ステータス

リクエストのステータス

リクエスト・タイプ

リクエストのタイプ

リクエスト日開始

リクエストの開始日

リクエスト日終了

リクエストの終了日

受益者ユーザーの名

受益者の名

受益者ユーザーの姓

受益者の姓

受益者ユーザーID

受益者のID

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リクエストID

リクエストID

リクエスト・タイプ

リクエストのタイプ

リクエスタ・ユーザーID

リクエスタのID

リクエスト日

リクエストが開始される日付

承認者ユーザーID

承認者のID

現行のステータス

リクエストのステータス

親リクエストID

親リクエスタのID

列

次の表に、受益者が存在する場合のレポートの列を示します。

レポートの列

説明

名

受益者の名

姓

受益者の姓

ユーザーID

受益者のID

ユーザー・タイプ

ユーザーのタイプ

ユーザー・ステータス

受益者のステータス

組織

受益者の組織

リクエスト値

リソースのリクエスト値

次の表に、受益者が存在しない場合のレポートの列を示します。

レポートの列

説明

リクエスト名

リクエストの名前

リクエスト値

リクエストの値

20.5.2.7 リクエスト・サマリー

このレポートにより、管理者は指定した時間間隔に要求されたすべてのリクエストの現行ステータスを表示できます。これにより、管理者は保留リクエストの終了を処理できるように、操作アクティビティを計画して優先順位を付けることができます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リクエスト・タイプ

リクエストのタイプ

リクエスト日開始

リクエストの開始日

リクエスト日終了

リクエストの終了日

組織

組織の詳細

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

リクエストID

リクエストID

親リクエストID

親リクエスタのID

リクエスト・タイプ

リクエストのタイプ

リクエスト・ステータス

リクエストのステータス

リクエスタ・ユーザーID

リクエスタのID

受益者ユーザーID

受益者のID

リクエストの詳細

リクエストの詳細

承認者ユーザーID

承認者のID

リクエスト日

リクエストの日付

20.5.2.8 タスク割当て履歴

すべてのタスク割当ての履歴がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

ユーザーID

受益者のID

割当て先の名

割当て先の名

割当て先の姓

割当て先の姓

割当て先ユーザーID

割当て先のID

割当て先ロール名

割当て先のロール名

割当て先ユーザー名

割当て先のユーザー名

従業員タイプ

従業員のタイプ

20.5.3 ロールおよび組織レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のロールおよび組織レポートが提供されます。

- ロール・メンバーシップ履歴

- ロール・メンバーシップ・プロファイル

- ロール・メンバーシップ

- 組織の詳細

- ユーザー・メンバーシップ履歴

20.5.3.1 ロール・メンバーシップ履歴

このレポートには、すべてのロールのメンバーシップ履歴が表示されます。レポートには間接メンバーシップは表示されません。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ロール名

ロールの名前

ロール・カテゴリ

ロールのカテゴリ

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

従業員ステータス

従業員のステータス: アクティブ、無効、削除、開始日まで無効

メンバーシップ・ステータス

メンバーシップのステータス: 失効、アクティブ

有効期間開始

ロール・メンバーシップの有効期間開始日付

有効期間終了

ロール・メンバーシップの有効期間終了日付

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

作成者

ロール作成者の名前

作成日

ロールが作成された日付

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

従業員タイプ

従業員のタイプ

従業員ステータス

従業員のステータス

メンバーシップ・ステータス

ユーザーのメンバーシップ日付

有効期間開始

ユーザーのメンバーシップ開始日

有効期間終了

ユーザーのメンバーシップ終了日

マネージャの名

マネージャの名

マネージャの姓

マネージャの姓

マネージャのユーザーID

マネージャのID

20.5.3.2 ロール・メンバーシップ・プロファイル

このレポートには、ロール数に存在するユーザー数、およびロールのカウント数に属するユーザーの詳細が表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

組織

ユーザーの組織

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ロール数のメンバーシップ

ロール数のメンバーの数

ユーザー数

ロールのユーザー数

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

20.5.3.3 ロール・メンバーシップ

このレポートには、すべてのロールのメンバーシップ詳細が表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ロール名

ロールの名前

ロール・カテゴリ

ロールのカテゴリ

組織

組織の名前

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

従業員ステータス

従業員のステータス: アクティブ、無効、削除、開始日まで無効

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

作成者

ユーザー作成者の名前

作成日

ユーザーが作成された日付

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

メンバー開始

ユーザーの参加日

マネージャの名

マネージャの名

マネージャの姓

マネージャの姓

マネージャのユーザーID

マネージャのID

20.5.3.4 組織の詳細

階層的組織構造および組織内のユーザーに関する詳細がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

組織名

組織の名前

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

親組織名

親組織の名前

列

次の表に、レポートの列を示します。

レポートの列

説明

ロール

管理者ユーザー・ロールの名前

名

組織内のユーザーの名

姓

組織内のユーザーの姓

ユーザーID

ユーザーのID

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

開始日

ユーザーの参加日

終了日

ユーザーの終了日

20.5.3.5 ユーザー・メンバーシップ履歴

このレポートには、ログインしたユーザーおよびそのメンバーシップ履歴がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

姓

ユーザーの名

名

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

従業員のステータス: アクティブ、無効、削除、開始日まで無効

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

ユーザーの名

ユーザーの名

ユーザーの姓

ユーザーの姓

組織

ユーザーの組織

従業員ステータス

従業員のステータス: アクティブ、無効、削除、開始日まで無効

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

列

次の表に、レポートの列を示します。

レポートの列

説明

ユーザー・ロール

ユーザー・ロールの名前

メンバーシップ・ステータス

メンバーシップのステータス

有効期間開始

メンバーシップが有効になる日付

20.5.4 パスワード・レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のパスワード・レポートが提供されます。

- パスワード有効期限サマリー

- パスワード・リセット・サマリー

- リソース・パスワード有効期限

20.5.4.1 パスワード有効期限サマリー

このレポートには、指定された期間内にOracle Identity Managerパスワードの有効期限が近づいているすべてのアクティブ・ユーザーのリストが表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

姓

ユーザーの姓

名

ユーザーの名

ユーザーID

ユーザーのID

組織

ユーザーの組織

有効期限日範囲開始

有効期限日の開始日

有効期限日範囲終了

有効期限日の終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートのフィールド

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

従業員タイプ

従業員のタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

従業員ステータス

従業員のステータス: アクティブ、無効、削除、開始日まで無効

組織

ユーザーの組織

パスワード有効期限日

パスワードの有効期限が切れる日付。

20.5.4.2 パスワード・リセット・サマリー

このレポートにより、ユーザー自身によってまたはユーザーにかわって試行されたパスワード変更に関する集計メトリックを表示できます。このメトリックには、すべてのパスワード変更試行、パスワード変更試行の成功または失敗結果、複数のパスワード変更試行が同時に失敗したためにロックされたユーザーが含まれます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

集計の頻度

生成するレポートの頻度

日付範囲開始

生成するレポートの開始日

日付範囲終了

生成するレポートの終了日

組織

組織の名前

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

集計の頻度

生成するレポートの頻度

列

次の表に、レポートの列を示します。

レポートの列

説明

期間

リセット試行を実行する日時

リセット試行

リセット試行の回数

失敗したリセット試行

失敗したリセット試行の回数

失敗したリセット試行のためにロックされたユーザー

失敗したリセット試行のためにロックされたユーザーの数

非受益者によるリセット

非受益者によるリセットの回数

20.5.4.3 リソース・パスワード有効期限

指定された期間内にリソース・パスワードが期限切れになるユーザーがリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

ユーザー・ステータス

ユーザーのステータス

パスワード有効期限日開始

パスワード有効期限開始日

パスワード有効期限日終了

パスワード有効期限終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートのフィールド

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス: アクティブ、無効、削除、開始日まで無効

ユーザー・タイプ

ユーザーのタイプ: フルタイム、パートタイム、派遣社員、インターン、コンサルタント、契約者

パスワード有効期限日

パスワードの有効期限が切れる日付。

20.5.5 リソースおよび権限レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のリソースおよび権限レポートが提供されます。

- リソースのアカウント・アクティビティ

- リソース別の委任管理者および権限

- リソース別の委任管理者

- 権限アクセス・リスト

- 権限アクセス・リスト履歴

- 財務的に重要なリソースの詳細

- リソース別のファイングレイン権限例外

- オフライン・リソース・プロビジョニング・メッセージ

- 孤立アカウント・サマリー

- リソース・アクセス・リスト履歴

- リソース・アクセス・リスト

- リソース・アカウント・サマリー

- リソース・アクティビティ・サマリー

- リソース別の統制外アカウント

- ユーザー・リソース・アクセス履歴

- ユーザー・リソース・アクセス

- ユーザー・リソース権限

- ユーザー・リソース権限履歴

20.5.5.1 リソースのアカウント・アクティビティ

各リソースのすべてのアカウント・アクティビティがリストされます。また、そのリソースの特定のアクティビティと各ユーザーの関連付けに関する情報も表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

日付範囲開始

レポートが表示される開始日

日付範囲終了

レポートが表示される終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース名

リソース名

アクティビティ・タイプ

アクティビティのタイプ

リソース認可者ユーザー・ロール

ロールを認可するロールの名前

リソース管理者ユーザー・ロール

リソースを認可するロールの名前

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

ユーザー・ステータス

ユーザーのステータス: アクティブ、無効、削除、開始日まで無効

組織

ユーザーの組織

マネージャのユーザーID

マネージャのID

タイムスタンプ

レポートが作成された日付

20.5.5.2 リソース別の委任管理者および権限

このレポートには、リソースの管理者であるユーザー・ロールのリストが書込み権限および削除権限とともに表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート・パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

管理者ロール名

管理者ロールの名前

管理者ロール情報

管理者ロールに関する情報

読取り権限

リソースに読取り権限があるかどうかを示します

書込み権限

リソースに書込み権限があるかどうかを示します

削除権限

リソースに削除権限があるかどうかを示します

認可者ロール

認可者ロール名

名前付き優先度

リソースの優先度

作成者

リソース作成者の名前

作成日

リソース作成日

20.5.5.3 リソース別の委任管理者

レポートには、リソースの管理者または認可者であるユーザー・ロールとそのロールのメンバーのリストが表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

リソース・タイプ

リソースのタイプ

リソース監査目的

リソースに対して監査を実行する目的

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

ターゲット

リソースが組織またはユーザーのターゲットかどうかを示します

書込み権限

リソースに書込み権限があるかどうかを示します

削除権限

リソースに削除権限があるかどうかを示します

作成者

リソース作成ソース

作成日

リソースが作成された日付

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

メンバー開始

ユーザーの参加日

マネージャの名

マネージャの名

マネージャの姓

マネージャの姓

マネージャのユーザーID

マネージャのID

20.5.5.4 権限アクセス・リスト

このレポートにより、管理者または監査者は指定した権限を持つすべての既存ユーザーを問い合せることができます。このレポートは、操作およびコンプライアンスのために使用できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

権限コード

権限のコード

リソース名

リソース名

組織

ユーザーの組織

ロール名

ロールの名前

ユーザー・ステータス

ユーザーのステータス: アクティブ、無効、削除、開始日まで無効

ユーザー・タイプ

ユーザーのタイプ

プロビジョニング日開始

リソースをユーザーにプロビジョニングする開始日

プロビジョニング日終了

リソースをユーザーにプロビジョニングする終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

権限コード

権限のコード

権限名

権限の名前

権限ステータス

権限のステータス

リソース名

リソース名

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

ユーザーID

ユーザーのID

名

ユーザーの名

姓

ユーザーの姓

ユーザー・ステータス

ユーザー・ステータス

ユーザー・タイプ

ユーザーのタイプ

組織

ユーザーの組織

有効終了日

権限の有効開始日

有効開始日

権限の有効終了日

20.5.5.5 権限アクセス・リスト履歴

このレポートにより、管理者または監査者はライフサイクル全体にわたって権限にプロビジョニングされたすべての既存ユーザーを問い合せることができます。これは、リソースのアクセス・リストまたは権限の全履歴を示す存続期間レポートです。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

権限コード

権限のコード

リソース名

リソース名

組織

ユーザーの組織

ロール名

ロールの名前

ユーザー・ステータス

ユーザーのステータス: アクティブ、無効、削除、開始日まで無効

ユーザー・タイプ

ユーザーのタイプ

有効期間開始日付

権限の有効期間開始日付

有効期間終了日付

権限の有効期間終了日付

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

権限コード

権限のコード

権限名

権限の名前

リソース名

リソース名

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

ユーザーID

ユーザーのID

名

ユーザーの名

姓

ユーザーの姓

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

有効期間開始

権限の有効期間開始日付

有効期間終了

権限の有効期間終了日付

20.5.5.6 財務的に重要なリソースの詳細

このレポートにより、管理者は財務的に重要なリソースのリストを取得し、様々な管理アクティビティおよびクリーンアップ・アクティビティに優先順位を付けます。また、コンプライアンス/プライバシおよびセキュリティ担当者は、財務的に重要なリソースの予防的および発見的制御の有効性を評価し、監査者は財務データをホストするITリソースを理解できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート・パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

ユーザー・ロール

リソース管理者ユーザー・ロールがリストされます

20.5.5.7 リソース別のファイングレイン権限例外

このレポートにより、管理者、署名担当者、内部および外部監査者は、様々なプロセス・フォームと様々なリソースの関連子表の違いを分析し、改善アクティビティによってリソース内の重大な弱点を緩和できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート・パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

従業員タイプ

従業員のタイプ(フルタイム、パートタイムなど)

組織名

組織の名前

ロール名

ロールの名前

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース名

リソース名

ユーザーID

ユーザーのID

列

次の表に、レポートの列を示します。

レポートの列

説明

フォーム名

フォームの名前

フォーム・タイプ

フォームのタイプ

注意:

このレポートを実行する前に、アカウント監査およびリコンシリエーション例外のデータを移入する必要があります。

アカウント監査およびリコンシリエーション例外のデータを移入する手順は、次のとおりです。

1. 「XL.EnableExceptionReports」システム・プロパティの値を「True」に設定します。

2. ユーザーを任意のターゲットにプロビジョニングします。

3. ターゲット内のユーザーの任意の属性を変更し、ユーザーをリコンサイルします。

4. UPA_UD_FORMFIELDS表およびUPA_UD_FORMS表でデータを検索します。

5. Oracle Identity Mangerサーバーに移動し、RefreshMaterializedViewSchedulerタスクを実行します。

6. BIPにログインし、レポートを表示します。

20.5.5.8 オフライン・リソース・プロビジョニング・メッセージ

オフライン・プロビジョニング機能拡張により、Oracle Identity Managerでのオフライン・プロビジョニングの実行、リソース・インスタンスの有効化、無効化および失効が可能になり、その結果、パラレル実行によってパフォーマンスが向上したり、トランザクション・タイムアウトも回避できるようになります。この機能は、特定のアクションの発生時にJMSメッセージを送信することにより実施され、実際の実行はメッセージ処理の一部として発生します。そのようなJMSメッセージは、なんらかの理由により処理中に失敗する場合があります。このレポートでは、そのような失敗時のオフライン・メッセージの詳細をすべてリストしています。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ユーザーの名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

リソース名

リソース名

アクション

リソースが実行するアクション

日付範囲開始

開始日

日付範囲終了

終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーの名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

リソース名

リソース名

リソースの説明

リソースの説明

アクション

リソースが実行するアクション

リクエスト・キー

リクエストのキー

作成日

プロビジョニング作成日

列

次の表に、レポートの列を示します。

レポートの列

説明

理由

オフライン・リソース・プロビジョニングの理由

例外

オフライン・リソース・プロビジョニングでの例外

20.5.5.9 孤立アカウント・サマリー

ユーザーはターゲット・システムに存在していたが、アカウントのプロビジョニングの対象となる関連ユーザーがOracle Identity Managerに存在しなかった入力リソースの統制外アカウントがリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート・パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

リコンシリエーション日範囲開始

リコンシリエーションの開始日

リコンシリエーション日範囲終了

リコンシリエーションの終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

リソース

リソース名

アカウント情報

孤立アカウントの情報

リコンシリエーション日

リコンシリエーションの日付

20.5.5.10 リソース・アクセス・リスト履歴

このレポートにより、管理者または監査者はライフサイクル全体にわたってリソースにプロビジョニングされたすべての既存ユーザーを問い合せることができます。これは、リソースのアクセス・リストまたは権限の全履歴を示す存続期間レポートです。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

スナップショット日開始

ユーザーに対するリソース・アクセスの有効期間開始日

スナップショット日終了

ユーザーに対するリソース・アクセスの有効期間終了日

変更日開始

ユーザーに対するリソース変更開始日

変更日終了

ユーザーに対するリソース変更終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

リソース記述データ

リソースの説明

ユーザー・ステータス

ユーザーのステータス

リソース・ステータス

リソースのステータス

有効期間開始

有効期間開始日

有効期間終了

有効期間終了日

20.5.5.11 リソース・アクセス・リスト

このレポートにより、管理者または監査者は指定したリソースにプロビジョニングされたすべての既存ユーザーを問い合せることができます。このレポートは、操作およびコンプライアンスのために使用できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

プロビジョニング日開始

リソース・プロビジョニング開始日

プロビジョニング日終了

リソース・プロビジョニング終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

ユーザー・タイプ

ユーザーのタイプ

ユーザー・ステータス

ユーザーのステータス

組織

ユーザーの組織

プロビジョニング日

リソースがプロビジョニングされる日付

20.5.5.12 リソース・アカウント・サマリー

このレポートには、各リソース内のステータスごとのユーザー数がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

リソース・タイプ

リソースのタイプ

アカウント・ステータス

アカウントのステータス

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

ユーザーの合計数

アカウントに関連付けられたユーザーの合計数

列

次の表に、レポートの列を示します。

レポートの列

説明

アカウント・ステータス

アカウントのステータス

ユーザー数

そのアカウント・ステータスのユーザーの数

20.5.5.13 リソース・アクティビティ・サマリー

リソースのプロビジョニングおよび承認のすべてのアクティビティの履歴がリストされます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

日付範囲開始

開始日

日付範囲終了

終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

アカウント・プロビジョニング済

プロビジョニングされたアカウントの数

アカウント・プロビジョニング解除済

プロビジョニング解除されたアカウントの数

承認リクエスト

承認リクエストの数

受理された承認

承認されたリクエストの数

却下された承認

却下されたリクエストの数

20.5.5.14 リソース別の統制外アカウント

このレポートには、入力リソースのすべての統制外アカウントが含まれます。このレポートには、統制外アカウントがシステム内の未処理例外と受理済例外のどちらを表すかを分析するための対応するアテステーション・データも含まれます。これにより、管理者、署名担当者、内部および外部監査者はリソース内の重大な弱点を識別し、改善アクティビティによる緩和を計画できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

リソース名

リソース名

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織名

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

リソース・タイプ

リソースのタイプ

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

例外タイプ

例外のタイプ

アテステーションで承認された例外

例外が承認されるかどうかを示します

レビューアの名

レビューアの名

レビューアの姓

レビューアの姓

レビューアのユーザーID

レビューアのユーザーID

20.5.5.15 ユーザー・リソース・アクセス履歴

このレポートにより、管理者または監査者はユーザーのライフサイクル全体にわたってユーザーのリソース・アクセス履歴を表示できます。このレポートは、コンプライアンスおよびフォレンジック監査の目的に使用できます。これは、ユーザー・アクセス・プロファイルのスナップショット・レポートではありません。これは、ユーザーの権限の全履歴を示す存続期間レポートです。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

ユーザーの名

ユーザーの名

ユーザーの姓

ユーザーの姓

マネージャ・ユーザーID

レポート・マネージャのID

マネージャの名

レポート・マネージャの名

マネージャの姓

レポート・マネージャの姓

組織

ユーザーの組織

従業員ステータス

従業員のステータス

従業員タイプ

従業員のタイプ

アイデンティティ作成日

ユーザー作成日

列

次の表に、レポートの列を示します。

レポートの列

説明

リソース名

リソース名

リソース記述データ

リソースの説明

プロビジョニングされた日

リソースがプロビジョニングされる日付

プロビジョニング実行者

リソースをプロビジョニングした実行者の名前

有効期間開始

ユーザーに対するリソース・アクセスの有効期間開始日

有効期間終了

ユーザーに対するリソース・アクセスの有効期間終了日

20.5.5.16 ユーザー・リソース・アクセス

このレポートにより、管理者または監査者は指定したリソースにプロビジョニングされたすべての既存ユーザーを問い合せることができます。このレポートは、操作およびコンプライアンスのために使用できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

従業員のステータス

従業員タイプ

従業員のタイプ

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

ユーザーの名

ユーザーの名

ユーザーの姓

ユーザーの姓

マネージャ・ユーザーID

レポート・マネージャのID

マネージャの名

レポート・マネージャの名

マネージャの姓

レポート・マネージャの姓

組織

ユーザーの組織

従業員ステータス

従業員のステータス

従業員タイプ

従業員のタイプ

アイデンティティ作成日

ユーザー作成日

列

次の表に、レポートの列を示します。

レポートの列

説明

リソース名

リソース名

リソース記述データ

リソースの説明

リソース・ステータス

リソースのステータス

プロビジョニングされた日

リソースがプロビジョニングされる日付

20.5.5.17 ユーザー・リソース権限

このレポートにより、管理者または監査者は指定したユーザーにプロビジョニングされたすべての既存権限を問い合せることができます。このレポートは、操作およびコンプライアンスのために使用できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ユーザーID

ユーザーのID

名

ユーザーの名

姓

ユーザーの姓

電子メール

ユーザーの電子メール

リソース名

リソース名

組織

ユーザーの組織

ロール名

ロールの名前

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

名

ユーザーの名

ミドル・ネーム

ユーザーのミドル・ネーム

姓

ユーザーの姓

電子メール

ユーザーの電子メール

組織

ユーザーの組織

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

マネージャの名

マネージャの名

マネージャの姓

マネージャの姓

開始日

リソースの権限の開始日

終了日

リソースの権限の終了日

列

次の表に、レポートの列を示します。

レポートの列

説明

権限コード

権限のコード

権限名

権限の名前

権限ステータス

権限のステータス

リソース

リソースのタイプ

プロビジョニング開始

リソースをユーザーにプロビジョニングする開始日

有効開始日

リソースの権限の有効開始日

20.5.5.18 ユーザー・リソース権限履歴

このレポートにより、管理者または監査者はユーザーのライフサイクル全体にわたってユーザーのリソース権限履歴を表示できます。このレポートは、コンプライアンスおよびフォレンジック監査の目的に使用できます。これは、ユーザー・アクセス・プロファイルのスナップショット・レポートではありません。これは、ユーザーの権限の全履歴を示す存続期間レポートです。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

ユーザーID

ユーザーのID

名

ユーザーの名

姓

ユーザーの姓

電子メール

ユーザーの電子メール

リソース名

リソース名

組織

ユーザーの組織

ロール名

ロールの名前

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

有効期間開始日付

リソース権限の有効期間開始日

有効期間終了日付

リソース権限の有効期間終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

名

ユーザーの名

姓

ユーザーの姓

ユーザー・ステータス

ユーザーのステータス

ユーザー・タイプ

ユーザーのタイプ

組織

ユーザーの組織

電子メール

ユーザーの電子メール

開始日

リソース権限の開始日

終了日

リソース権限の終了日

アイデンティティ作成日

アイデンティティ作成の日付

マネージャの名

マネージャの名

マネージャの姓

マネージャの姓

列

次の表に、レポートの列を示します。

レポートの列

説明

権限コード

権限のコード

権限名

権限の名前

リソース

リソースのタイプ

有効期間開始日付

リソース権限の有効期間開始日

有効期間終了日付

リソース権限の有効期間終了日

20.5.6 ユーザー・レポート

Oracle Identity Manager BI Publisherレポートでは、Oracle Identity Managerの次のユーザー・レポートが提供されます。

- ユーザー・プロファイル履歴

- ユーザー・サマリー

- 削除済ユーザー

- 無効化されたユーザー

- ロック解除済ユーザー

20.5.6.1 ユーザー・プロファイル履歴

このレポートには、入力パラメータに基づいてすべてのユーザーとその詳細が表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

ロール名

ユーザーのロール

マネージャ・ユーザーID

ユーザーがレポートするマネージャのID

従業員ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ

変更日範囲開始

変更の有効期間開始日

変更日範囲終了

変更の有効期間終了日

スナップショット日範囲開始

ユーザーに対するリソース・アクセスの有効期間開始日

スナップショット日範囲終了

ユーザーに対するリソース・アクセスの有効期間終了日

フィールド

次の表に、レポートのフィールドを示します。

レポートのフィールド

説明

ユーザーID

ユーザーのID

ユーザーの名

ユーザーの名

ユーザーの姓

ユーザーの姓

マネージャ・ユーザーID

レポート・マネージャのID

マネージャの名

レポート・マネージャの名

マネージャの姓

レポート・マネージャの姓

組織

ユーザーの組織

従業員ステータス

従業員のステータス

従業員タイプ

従業員のタイプ

アイデンティティ作成日

ユーザー作成日

列

次の表に、レポートの列を示します。

レポートの列

説明

プロファイル・パラメータ

ユーザー・プロファイルの名前

値

ユーザー・プロファイルの値

有効期間開始日付

有効期間開始日付

有効期間開始時刻

有効期間開始時刻

20.5.6.2 ユーザー・サマリー

指定された期間内に作成されたすべてのOracle Identity Managerユーザーがリストされます。さらに、ユーザーが手動で作成されたか、または信頼できるリコンシリエーションをよって作成されたかに関する情報も表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

従業員ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ

作成日開始

ユーザー・サマリーの開始日

作成日終了

ユーザー・サマリーの終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ

マネージャID

ユーザーがレポートするマネージャのID

ソース

ユーザー作成ソース

作成日

ユーザーが作成された日付

20.5.6.3 削除済ユーザー

このレポートには、入力パラメータに基づいてすべての削除済ユーザーとその詳細が表示されます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員タイプ

従業員のタイプ

削除日開始

削除済ユーザーのサマリーの開始日

削除日終了

削除済ユーザーのサマリーの終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員タイプ

従業員のタイプ

マネージャID

ユーザーがレポートするマネージャのID

ソース

ユーザー作成ソース

削除日

ユーザーが削除された日付

20.5.6.4 無効化されたユーザー

このレポートにより、アカウントが無効になっているユーザーの詳細を表示できます。アカウントは様々な理由で無効にできます。たとえば、アテステーションの却下、ログインまたはパスワード・リセットの試行の失敗などがあります。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員タイプ

従業員のタイプ

無効化日開始

ユーザーの無効化の開始日

無効化日終了

ユーザーの無効化の終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

従業員の現行のステータス

従業員タイプ

従業員のタイプ

マネージャID

ユーザーがレポートするマネージャのID

ソース

ユーザー作成ソース

無効化日

ユーザーが無効化された日付

20.5.6.5 ロック解除済ユーザー

このレポートにより、無効化されたアカウントが管理者によってロック解除されたユーザーの詳細を表示できます。ユーザーが属する組織の委任管理者はアカウントを有効化できます。

入力パラメータ

次の表に、データをサブセット化するための基準の指定に使用するレポート入力パラメータを示します。

レポート・パラメータ

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員タイプ

従業員のタイプ

ロック解除日開始

ユーザーのロック解除の開始日

ロック解除日終了

ユーザーのロック解除の終了日

フィールド

なし

列

次の表に、レポートの列を示します。

レポートの列

説明

名

ユーザーの名

姓

ユーザーの姓

ユーザーID

ユーザーのID

組織

ユーザーの組織

従業員ステータス

ユーザーのステータス

従業員タイプ

従業員のタイプ

マネージャID

ユーザーがレポートするマネージャのID

ソース

ユーザー作成ソース

ロック解除日

ユーザーがロック解除された日付

20.6 例外レポート

Oracle Identity Managerでの例外とは、ユーザーに権限が付与されているアカウントとユーザーに実際に割り当てられているアカウントとの相違を指します。これらのアカウントは、アクセス・ポリシー、リソースのプロビジョニング、承認リクエストおよびリコシリエーション・イベントの結果としてユーザーに割り当てられます。ターゲット・システムのユーザーに割り当てられたこれらのアカウントと、Oracle Identity Managerのユーザーに割り当てられたアカウントの相違が、例外となります。

アカウント監査およびリコンシリエーション例外レポートのデータを移入する手順は、次のとおりです。

1. 「XL.EnableExceptionReports」システム・プロパティの値を「True」に設定します。システム・プロパティについては、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのシステム・プロパティの管理に関する項を参照してください。

2. リソース・オブジェクトのオブジェクトの最初のリコンシリエーション日フィールドがシステム日付より前の日付であることを確認します。

次の例外レポートがこのリリースで導入されました。

- リソース別の統制外アカウント
このレポートは、リソースに存在するすべての統制外アカウントのリストを返します。次の例外がレポートされます。

- ターゲット・システムに存在するが、Oracle Identity Managerの対応するユーザーにプロビジョニングされていないアカウント

- ターゲット・システムに存在するが、Oracle Identity Managerの対応するユーザーにプロビジョニング解除されているアカウント

- 孤立アカウント・サマリー・レポート: ターゲット・システムに存在するが、アカウントがプロビジョニングされるOracle Identity Managerの対応するユーザーが削除されているアカウント。指定の入力リソースについて、ターゲット・システムに存在するが、アカウントがプロビジョニングされるOracle Identity Managerの対応するユーザーが存在しなかった統制外アカウントがリストされます。

- リソース別のファイングレイン権限例外
このレポートは、リコンサイルされるプロセス・フォーム・データが想定値と異なるリソースのすべてのアカウントのリストを返します。つまり、このレポートは、ターゲット・システムに存在し、Oracle Identity Managerの対応するユーザーにプロビジョニングされるが、プロセス・データが一致しないアカウントを返します。

注意:

- 最初のターゲット・リコンシリエーションの終了後は、ターゲット・リソースで直接に実行されるアカウント関連のすべてのアクティビティが例外アクティビティとして追跡されます。アカウント関連のアクティビティには、アカウントの作成、アカウントの変更および権限の割当てと失効が含まれます。例外レポートは、ターゲット・リソースでのすべてのアカウント関連のアクティビティを常にOracle Identity Managerで開始することが組織ポリシーで強制されている場合にのみ使用する必要があります。また、例外の検出および記録はアカウント・データ・リコンシリエーションの拡張機能であるため、リコンシリエーションのパフォーマンス低下の原因となる場合があります。

- すべての例外レポートはリコンシリエーション・データに依存しています。そのため、対応するリコンシリエーション・イベントがアーカイブされると、これらのレポートにデータは表示されません。

20.7 サード・パーティ製ソフトウェアを使用したレポートの作成

Oracle Identity Managerは、Crystal Reportsなどのサード・パーティ製ツールを使用したレポートの作成をサポートしています。サード・パーティ製ツールを使用して、第20.5項「Oracle Identity Managerのレポート」に記載されているレポートを作成できます。

注意:

サード・パーティ製ソフトウェアを使用してレポートを作成する方法の詳細は、サード・パーティ製ソフトウェアのマニュアルを参照してください。

20.8 BI Publisherレポートの必須のスケジュール済タスク

表20-1に、Oracle Identity Manager BI Publisherレポートで必須のスケジュール済タスクを示します。

表20-1 BI Publisherレポートのスケジュール済タスク

レポート名

スケジュール済タスク名

説明

リソース別のファイングレイン権限例外

RefreshMaterializedView

このレポートで使用するマテリアライズド・ビューを最新データでリフレッシュします

ユーザー・プロファイル履歴

IssueAuditTask

監査表に最新データを移入します

ロック解除済ユーザー

IssueAuditTask

監査表に最新データを移入します

ユーザー・メンバーシップ履歴

IssueAuditTask

監査表に最新データを移入します

ロール・メンバーシップ履歴

IssueAuditTask

監査表に最新データを移入します

リソース・アクセス・リスト履歴

IssueAuditTask

監査表に最新データを移入します

ユーザー・リソース・アクセス履歴

IssueAuditTask

監査表に最新データを移入します

リソース・アクティビティ・サマリー

IssueAuditTask

監査表に最新データを移入します

パスワード・リセット・サマリー

IssueAuditTask

監査表に最新データを移入します

権限レポート

権限リスト

権限リスト表にマーク付き権限を移入します

権限割当て

権限割当て表に割当て済権限を移入します

権限更新

任意の権限が任意のユーザーに定期的または後で割り当てられる場合は、権限割当て表に最新データを移入します。

索引

A  B  C  D  E  F  G  H  I  L  M  O  P  R  S  T  U  V  W  X

A

アクセス・ポリシー, 16, 16, 16

作成, 16.3

機能, 16.2

管理, 16.4, 16.4

アクセス・ポリシー・ウィザード, 3.1.3.1 アカウント・リコンシリエーション, 4.2.1.1.2 アダプタ・ファクトリ, 1.1.5, 2.2.2.2.3 管理コンソール

機能, 3.1.3.1

管理およびユーザー・コンソール, 3.1

カスタマイズ可能なコンポーネント, 3.1.4

カスタマイズ, 3.1.4

ログイン, 7.1.1

登録, 7.1.2

登録リクエスト, 7.1.2

登録リクエストのトラッキング, 7.1.3

管理機能, 3.2.1 拡張管理, 3.1.3 拡張検索

承認ポリシー, 18.3

認可ポリシー, 15.2.1.2

論理積演算子, 11.3.1.2.3

組織, 13.2.1.2

ページ, 11.3.1.2.1

リクエスト・テンプレート, 17.2

リクエスト, 14.2.1

結果, 11.3.1.2.5

ロール, 12.5.2.2.2

検索コンパレータ, 11.3.1.2.2

検索可能な属性, 11.3.1.2.4

ユーザー, 11.3.1.2, 11.3.1.2.6

APIサービス, 2.2.2.1 承認ポリシー

拡張検索, 18.3

作成, 18.2

削除, 18.6

管理, 18

優先度の変更, 18.5

変更, 18.4

検索, 18.3

単純検索, 18.3

承認ポリシー, 18 承認タスク, 9.1

承認, 9.1.4

要求, 9.1.3

再割当て, 9.1.6

却下, 9.1.5

詳細情報のリクエスト, 9.1.7

情報の送信, 9.1.8

タスクの詳細, 9.1.2

承認ワークフロー, 2.2.2.3.1 承認

選択方法, 18.1

アーキテクチャ, 2

ビジネス・サービス層, 2.2.2

データ層, 2.2.3

プラットフォーム・サービス, 2.2.2.3

プレゼンテーション層, 2.2.1

リコンシリエーション, 4.2.2

層, 2.2

アテステーション, 19

定義, 1.1.4

アテステーション・ダッシュボード, 19.5

電子メール通知, 19.5.2

スケジュール済タスク, 19.5.3

使用, 19.5

アテステーション・リクエスト詳細の表示, 19.5.1

アテステーション・プロセス, 19.2

アテステーション・ダッシュボード, 19.5

アテステーション・エンジン, 19.1.6

アテステーション受信ボックス, 19.1.2.1

アテステーション・リクエスト, 19.1.3

構成, 19.2

作成, 19.3

拒否されたアテステーション権限, 19.1.9.3

スケジュールの定義, 19.1.1

定義, 19.1.1

委任, 19.1.4

削除, 19.1.1.1.2, 19.4.4

無効化, 19.1.1.1.1, 19.4.2

編集, 19.4.1

電子メール, 19.1.9

有効化, 19.4.3

ライフサイクル, 19.1.5

管理, 19.4

管理者の管理, 19.4.6

委任されたレビューアへの通知, 19.1.9.2

レビューアへの通知, 19.1.9.1

プロセス所有者, 19.1.1

レビューア設定, 19.1.1

レビューア, 19.1.9.4

実行, 19.4.5

スケジュール済タスク, 19.1.7

スコープ, 19.1.1

タスク・コンポーネント, 19.1.2

実行履歴の表示, 19.4.7

アテステーション・タスク

作成, 19.1.5.1

アテステーション・タスクのコンポーネント

アテステーション・アクション, 19.1.2

アテステーション・データ, 19.1.2

アテステーション日, 19.1.2

レビューア, 19.1.2

タスク・ソース, 19.1.2

アテステーション・タスク, 9.3

アクション, 19.1.5.2

アテステーション・ドリブンのワークフロー機能, 19.1.8

送信したタスクの処理, 19.1.5.3

リクエストの詳細, 9.3.2

権限に対するレビューア・レスポンス, 19.1.5.2

検索, 9.3.1

ワークフロー・ダイアグラム, 19.1.5.1

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

アテステーションの自動化, 1.1.4

包括的なレポート, 1.1.4

アイデンティティ・リコンシリエーション, 1.1.4

統制外および孤立アカウント, 1.1.4

監査およびレポート, 2.3 監査エンジン, 6, 6.2 監査レベル, 6.2.1 監査管理, 1.1.4 監査, 6

監査レベル, 6.2.1

監査メッセージ, 6.2.3

プロファイル監査機能, 6.1.2

ロール・プロファイル監査機能, 6.4

ユーザー・プロファイル監査機能, 6.3

認証済セルフサービス, 3.1.1 認可

組織管理, 13.3

ロール管理, 12.6

ユーザー管理, 11.4

認可ポリシー, 2.2.2.3.2, 15.1

拡張検索, 15.2.1.2

承認ポリシー管理, 15.3.10

割当て先, 15.1

認証済セルフサービス, 15.3.2

認可ポリシー管理, 15.3.4

既存のポリシーに基づいた, 15.2.3

作成, 15.2.2

データ・セキュリティ, 15.1

削除, 15.2.5

診断ダッシュボード, 15.3.13

管理, 15

通知管理, 15.3.11

プラグイン, 15.3.14

Oracle Identity Manager機能に対するポリシー, 15.2.5

権限, 15.1

リコンシリエーション管理, 15.3.6

リクエスト・テンプレートを使用したリクエスト作成, 15.3.9

リクエスト・テンプレート管理, 15.3.8

ロール管理, 15.3.3

スケジューラ, 15.3.7

検索, 15.2.1

単純検索, 15.2.1.1

システム・プロパティ, 15.3.12

ユーザー管理, 15.3.1

ユーザー管理構成, 15.3.5

表示と変更, 15.2.4

B

受益者, 10

BI Publisher, 20

開始, 20.2

バルク・ロード, 2.3 バルク・リクエスト, 10.2

C

チャレンジ質問および回答, 8.5.2

子リクエスト, 10.2

クラスタ環境, 5.5

共通名, 11.6

共通名の生成, 11.6

共通のサービス, 2.3

コンポーネント, 2.3

構成

LDAPとの統合, 4.3.1

ユーザー名ポリシー, 11.5.2

コネクタ・フレームワーク, 2.2.2.2.1 コネクタ・パフォーマンス

索引, 4.2.2.8

コネクタ, 2.2.2.2.1

カスタム, 5.3

汎用テクノロジ・コネクタ, 5.2

インストール, 5.5

事前定義済 5.1

作成

アクセス・ポリシー, 16.3

承認ポリシー, 18.2

カスタム認可ポリシー, 15.2.2

組織, 13.2.3

リクエスト・テンプレート, 17.1

リクエスト, 14.1

ロール, 12.5.1

ユーザー, 11.3.2

D

データ収集, 6.3.1, 6.4.1

アーカイブ, 6.4.1.1

取得, 6.3.1.1, 6.4.1.1

データ・オブジェクト, 12.5.2.8, 12.5.2.8 データベース, 2.2.3.1 デフォルト・ロール, 12.4 委任管理, 1.1.1, 2.1.4 削除

承認ポリシー, 18.6

認可ポリシー, 15.2.5

遅延削除, 11.3.3.3.6

組織, 13.2.8

リクエスト・テンプレート, 17.4

ロール, 12.5.2.3

ユーザー, 11.3.3.3.6

コネクタのデプロイ

一般的な考慮事項, 5.5

デプロイメント・マネージャ, 2.1.1, 3.1.3.1 Design Console, 3.2 開発ツール, 3.2.1 ダイレクト・プロビジョニング, 4.1 無効化

組織, 13.2.5

ユーザー名の予約, 11.5.1

ユーザー, 11.3.3.3.2

E

有効化

組織, 13.2.5

ユーザー名の予約, 11.5.1

ユーザー, 11.3.3.3.1

エンティティ定義

組織, 13.1

ロール, 12.3

ユーザー, 11.2

例外, 20.6 例外レポート, 20.6 外部ライブラリ, 5.5 外部ソフトウェア, 5.5

F

機能, 2.1

G

汎用テクノロジ・コネクタ, 2.2.2.2.4, 5.2

GTC, 2.2.2.2.4, 5.2

H

高可用性, 2.2.3.1

I

ICF, 2.2.2.2.2

アイデンティティ管理, 2.3

アイデンティティ・コネクタ, 2.2.2.2.2

アイデンティティ・コネクタ・フレームワーク, 2.2.2.2.2

アイデンティティ・コネクタ, 2.2.2.2.2

アイデンティティ・ストア, 2.2.3.3 コネクタのインストール, 5.5 統合ソリューション, 5

アダプタ・ファクトリ, 1.1.5

事前定義済コネクタ, 1.1.5

統合

Oracle Identity ManagerとLDAP, 4.3

統合サービス, 2.2.2.2 統合ソリューション, 1.1.5 監査メッセージの発行タスク, 6.2.3 ITリソース・タイプ, 5.4

L

LDAP, 2.2.3.3, 4.3

LDAPアイデンティティ・ストア, 4.3

プロビジョニング, 4.3.2

リコンシリエーション, 4.3.3

LDAP統合

構成, 4.3.1

ローカライズ, 3.1.5 レコードの検索, 3.1.2.1 ロック

ユーザー, 11.3.3.3.3

M

管理

アクセス・ポリシー, 16.4

承認ポリシー, 18

承認タスク, 9.1

アテステーション・タスク, 9.3

認可ポリシー, 15

組織, 13

プロビジョニング・タスク, 9.2

リクエスト・テンプレート, 17

リクエスト, 10

ロール, 12, 12.5.2

タスク, 9

ユーザー・プロファイル, 8

ユーザー, 11

プロセスの管理, 3.2.1 リソースの管理, 3.2.1 MDS, 2.2.3.2 メタデータ・ストア, 2.2.3.2 リコンシリエーションのモード, 4.2.1.2 変更

承認ポリシー, 18.4

承認ポリシー優先度, 18.5

認可ポリシー, 15.2.4

組織, 13.2.4

リクエスト・テンプレート, 17.2, 17.2

ユーザー情報, 11.3.3

複数のサーバー・インスタンス, 2.1.2

O

OIMアカウント, 11.1.1

オープン・アーキテクチャ, 2.1.3

Oracle Identity Administration, 3.1.2

Oracle Identity Manager, 1

アーキテクチャ, 2

アテステーション, 19.1

コンポーネント, 2.3

コネクタ, 2.2.2.2.1

機能, 2.1

LDAP統合, 4.3

レポート, 20

アーキテクチャの層, 2.2

Oracle identity Manager

登録, 7.1.2

Oracle Identity Managerのアーキテクチャ, 2 Oracle Identity Managerプロセス, 3.2.1 Oracle Identity Managerレポート, 2.2.3.1, 20.5 組織, 11.1.2 組織およびロール管理, 1.1.7 組織, 13

管理ロール, 13.2.6

拡張検索, 13.2.1.2

属性, 13.2.4.1

認可ポリシー, 13.3

参照, 13.2.2

子組織, 13.2.4.2

作成, 13.2.3

削除, 13.2.8

有効化と無効化, 13.2.5

エンティティ定義, 13.1

管理, 13

メンバー, 13.2.4.3

許可されたリソース, 13.2.7

リソースのプロビジョニングおよび失効, 13.2.4.4

検索, 13.2.1

単純検索, 13.2.1.1

表示と変更, 13.2.4

P

親リクエスト, 10.2

パスワード管理, 1.1.3

高度, 1.1.3

セルフサービス, 1.1.3

同期化, 1.1.3

検索の実行, 3.2.1 プラグイン・フレームワーク, 2.2.2.3.3 ポリシー・ベースのプロビジョニング, 4.1 ポストプロセッサ, 6.3.2 事前定義済コネクタ, 5.1 プロセス・エンジン, 2.1.8 プロセス・フォーム, 5.4 プロセス

管理, 3.2.1

プロファイル監査機能, 6.1.2 プロビジョニング, 1.1.6, 2.3, 4.1

ダイレクト, 4.1

複数ターゲット・システムへの複数リソース・オブジェクト, 16.5.3

Oracle Identity ManagerからLDAP, 4.3.2

ポリシー・ベース, 4.1

リクエスト・ベース 4.1

プロビジョニング・プロセス・コンポーネント, 5.4.1 プロビジョニング・タスク, 9.2

メモの追加, 9.2.4

割当て履歴, 9.2.6

フォームの詳細, 9.2.7

フォームの詳細の変更, 9.2.8

再割当て, 9.2.5

再試行, 9.2.9

検索, 9.2.1

レスポンスの設定, 9.2.3

タスクの詳細, 9.2.2

R

リコンシリエーション, 4.2

アカウント・リコンシリエーション, 4.2.1.1.2

アクション・モジュール, 4.2.2.7.2

アクション・ルール, 4.2.2.2, 4.2.2.7.2

API, 4.2.2.5

アプローチ, 4.2.1.3

アーキテクチャ, 4.2.2

アーカイブ, 4.2.2.10

下位互換性, 4.2.2.11

変更ログ, 4.2.1.2

コネクタ, 4.2.2.9

エンジン, 4.2.2.7

インタフェース, 4.2.2.12

LDAPからOracle Identity Manager, 4.3.3

マッピング・ルール, 4.2.2.2

照合モジュール, 4.2.2.7.1

照合ルール, 4.2.2.2

メタデータ, 4.2.2.2

モード, 4.2.1.2

プロセス・フロー, 4.2.1.1.3

プロファイル, 4.2.2.1

プッシュまたはプル・モデル, 4.2.1.2

標準, 4.2.1.2

実行, 4.2.2.4

スキーマ, 4.2.2.6

ターゲット, 4.2.2.3

ターゲット属性, 4.2.2.2

信頼できるソース, 4.2.1.1.1

タイプ, 4.2.1

リコンシリエーション・エンジン, 2.3 リコンシリエーション・エンジン, 4.2.2.7

アクション・モジュール, 4.2.2.7.2

照合モジュール, 4.2.2.7.1

リコンシリエーション関連タスク, 5.4.2 レコード

表示, 3.2.1

標準リコンシリエーション, 4.2.1.2 リモート・マネージャ, 2.2.2.2.5 レポート, 2.2.3.1, 20

BI Publisher, 20

機能, 20.1

レポート, 20.5

アクセス・ポリシー・レポート, 20.5.1

アテステーション、リクエストおよび承認レポート, 20.5.2

Crystal Reports, 20.7

例外レポート, 20.6

パスワード・レポート, 20.5.4

リソースおよび権限レポート, 20.5.5

ロールおよび組織レポート, 20.5.3

実行, 20.3

ユーザー・レポート, 20.5.6

リポジトリ, 2.2.3.1 リクエスト

検索, 10.5

リクエスト・モデル, 10.3 リクエスト・サービス, 2.2.2.3.1, 2.2.2.3.1 リクエストのステージ, 10.1 リクエスト・テンプレート, 17

追加属性, 17.2.3

拡張検索, 17.2

許可されたリソース, 17.2.1

許可されたロール, 17.2.1

属性制限, 17.2.2

クローニング, 17.3

作成, 17.1

削除, 17.4

管理, 17

変更, 17.2

検索と変更, 17.2

単純検索, 17.2

テンプレート・ユーザー・ロール, 17.2.4

リクエスト・トラッキング, 10.5 リクエスト・ベースのプロビジョニング, 4.1 リクエスタ, 10 リクエスト, 10

拡張検索, 14.2.1

受益者, 10

バルク・リクエスト, 10.2

子リクエスト, 10.2

クローズ, 10.8

作成, 14.1

管理, 10

親リクエスト, 10.2

プロセス・フロー, 10

リクエストの詳細, 14.2.2

リクエスト・モデル, 10.3

リクエスト・テンプレート, 17

リクエスタ, 10

検索とトラッキング, 14.2

単純検索, 14.2.1

ステージ, 10.1

ターゲット・エンティティ, 10

タスク・リスト, 10.7

トラッキング, 10.5

取消し, 10.6

リソース・オブジェクト, 5.4 リソース

管理, 3.2.1

表示, 3.1.1.1

RFIタスク, 9.1.7 ロール・プロファイル監査機能, 6.4 ロール, 11.1.3, 12, 12.5.2.8

拡張検索, 12.5.2.2.2

属性, 12.5.2.4.1

認可ポリシー, 12.6

参照, 12.5.2.1

作成, 12.5.1

デフォルト, 12.4

削除, 12.5.2.3

エンティティ定義, 12.3

階層, 12.5.2.4.2

継承先, 12.2, 12.5.2.4.2

継承元, 12.2, 12.5.2.4.2

管理, 12, 12.5.2

メンバー, 12.5.2.4.6

メンバーシップの継承, 12.1

権限の継承, 12.2

検索, 12.5.2.2

単純検索, 12.5.2.2.1

表示と管理, 12.5.2.4

S

スケジュール済タスク, 5.4

監査メッセージの発行タスク, 6.2.3

スケジューラ・サービス, 2.2.2.3.5 検索

「拡張検索」ページ, 11.3.1.2.1

承認ポリシー, 18.3

アテステーション・タスク, 9.3.1

認可ポリシー, 15.2.1

論理積演算子, 11.3.1.1.4

論理積演算子, 11.3.1.2.3

結果に対する操作, 11.3.1.1.6

組織, 13.2.1

プロビジョニング・タスク, 9.2.1

リクエスト・テンプレート, 17.2

リクエスト, 10.5, 14.2

結果, 11.3.1.2.5

ロール, 12.5.2.2

検索コンパレータ, 11.3.1.1.2, 11.3.1.2.2

検索結果, 11.3.1.1.5

検索文字列, 11.3.1.1.3

検索可能な属性, 11.3.1.1.1, 11.3.1.2.4

ユーザー, 11.3.1, 11.3.1.1.7, 11.3.1.2.6

職務の分離, 2.2.2.3.4 セルフ・サービス

認証済, 3.1.1

未認証, 3.1.1

セルフサービス機能, 1.1.1

プロファイル管理, 1.1.1

リクエスト管理, 1.1.1

単純検索

承認ポリシー, 18.3

認可ポリシー, 15.2.1.1

論理積演算子, 11.3.1.1.4

結果に対する操作, 11.3.1.1.6

組織, 13.2.1.1

リクエスト・テンプレート, 17.2

リクエスト, 14.2.1

ロール, 12.5.2.2.1

検索コンパレータ, 11.3.1.1.2

検索結果, 11.3.1.1.5

検索文字列, 11.3.1.1.3

検索可能な属性, 11.3.1.1.1

ユーザー, 11.3.1.1, 11.3.1.1.7

スナップショット

格納, 6.3.1.2, 6.4.1.2

SoD, 2.2.2.3.4 SPML Webサービス・インタフェース, 3.3

T

ターゲット・エンティティ, 10

タスク

管理, 9

RFI, 9.1.7

タスク・リスト, 10.7 タスクリスト, 9 タスク, 9

承認タスク, 9, 9.1

アテステーション・タスク, 9, 9.3

プロビジョニング・タスク, 9, 9.2

3層の方式, 5 信頼できるソース・リコンシリエーション, 4.2.1.1.1 チューニング

コネクタ・パフォーマンス

チューニング, 4.2.2.8

U

未認証セルフサービス, 3.1.1

ロック解除

ユーザー, 11.3.3.3.4

ユーザー属性, 11.2 ユーザー・インタフェース, 3

管理およびユーザー・コンソール, 3.1

Design Console, 3.2

ユーザー・プロファイル

チャレンジ質問および回答, 8.5.2

管理, 8

プロファイル属性, 8.1

プロキシ, 8.4

パスワードのリセット, 8.6

リソース・プロファイル, 8.3

ロール割当て, 8.2

セキュリティ, 8.5

ユーザー・プロファイル監査の表, 6.3.3 ユーザー・プロファイル監査機能, 6.3

データ収集, 6.3.1, 6.4.1

ポストプロセッサ, 6.3.2

XL.UserProfileAuditDataCollection, 6.3.1

ユーザー・プロファイル監査

使用される表, 6.3.3

ユーザー・プロファイル・スナップショット

トリガー, 6.3.1.3, 6.4.1.3

ユーザー名, 11.5

ポリシー構成, 11.5.2

解放, 11.5.3

ユーザー名の予約, 11.5

有効化と無効化, 11.5.1

ユーザー, 11

リソースの追加と削除, 11.3.3.2.3

ロールの追加と削除, 11.3.3.2.2

拡張検索, 11.3.1.2

属性プロファイル, 11.3.3.2.1

属性, 11.2

認可ポリシー, 11.4

バルク操作, 11.3.3.4

作成, 11.3.2

遅延削除, 11.3.3.3.6

削除, 11.3.3.3.6

無効化, 11.3.3.3.2

有効化, 11.3.3.3.1

リソースの有効化と無効化, 11.3.3.2.4

エンティティ定義, 11.2

ライフサイクル, 11.1

ロック, 11.3.3.3.3

管理, 11

OIMアカウント, 11.1.1

プロキシの詳細, 11.3.3.2.7

パスワードのリセット, 11.3.3.3.5

リソースの詳細, 11.3.3.2.5

リソース履歴, 11.3.3.2.6

検索, 11.3.1, 11.3.1.1.7, 11.3.1.2.6

単純検索, 11.3.1.1

ロック解除, 11.3.3.3.4

ユーザーの詳細, 11.3.3.1

表示と変更, 11.3.3

V

表示

認可ポリシー, 15.2.4

組織, 13.2.4

ユーザー情報, 11.3.3

レコードの表示, 3.2.1 リソースの表示, 3.1.1.1

W

Webベースのユーザー・セルフサービス, 2.1.5

ワイルドカード, 3.2.1

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

プロビジョニング解除, 1.1.6

動的エラー処理, 1.1.2

ポリシー管理, 1.1.2

プロビジョニング, 1.1.6

リクエスト・トラッキング, 1.1.2

トランザクションの整合性, 1.1.2

ワークフロー管理, 1.1.2

ワークフローおよびリクエスト・サービス, 2.3

X

XL.UserProfileAuditDataCollection, 6.3.1

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