| Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド 11g リリース1 (11.1.1) B65032-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド 11g リリース1 (11.1.1) B65032-05 |
|
前 |
次 |
オラクル社では、異なる使用例に応じて最適化された2つの補完的なプロビジョニング製品を提供しています。
Oracle Identity Manager: ディレクトリ、データベース、メインフレーム、独自のテクノロジ、フラット・ファイルなどを含む高度な異種テクノロジによる複合環境の管理を目的として設計されたエンタープライズ・プロビジョニング・プラットフォームです。Oracle Identity Managerでは、豊富な一連の監査およびコンプライアンス機能とともに、フル装備のワークフローおよびポリシー機能を提供します。
Oracle Directory Integration Platform(Identity Managementインフラストラクチャのコンポーネント): ディレクトリ中心の環境でディレクトリ同期だけでなくプロビジョニング・タスクも実行するように設計されたメタディレクトリ・テクノロジです。Oracle Directory Integration Platformは、ディレクトリや互換性のあるOracle製品で構成される、より同質的な環境を管理できるように設計されています。Oracle Directory Integration Platformでは、データ同期を使用してプロビジョニング・タスクを実行し、ワークフローやフル機能のポリシー・エンジンが不要な場合には小規模なデプロイ・フットプリントを提供します。
|
注意:
|
この章では、Oracle Directory Integration Platformプロビジョニングについて説明します。この章には次の項目があります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「プロビジョニング統合アプリケーションの開発」の章。 |
プロビジョニングとは、ユーザー、グループ、およびその他のオブジェクトに対し、エンタープライズ環境で使用する可能性のあるアプリケーションや他のリソースへのアクセスを提供するプロセスです。プロビジョニング統合アプリケーションとは、プロビジョニング・イベント用に、Oracle Unified DirectoryまたはOracle Internet Directoryバックエンド・ディレクトリにプロビジョニング統合プロファイルが登録されているアプリケーションです。アプリケーション固有のディレクトリにあるすべてのユーザー・エントリをバックエンド・ディレクトリのエントリと同期化するだけでなく、特定のアプリケーションをプロビジョニングしてエントリの一部のみに関する通知を受信することが可能です。たとえば、Oracle Human Resourcesのディレクトリには、通常、企業のすべての従業員のデータが含まれており、そのすべてのデータをOracle Unified DirectoryまたはOracle Internet Directoryバックエンド・ディレクトリと同期するのが普通です。ただし、他のアプリケーション(Oracle Emailなど)をプロビジョニングして、メンバーが特定グループに加入するか、そのグループから脱退した場合にのみ通知を受けることも可能です。
Oracle Identity Managementのデプロイでアプリケーションにユーザー・アカウントをプロビジョニングするには、まずそのアカウントをバックエンド・ディレクトリに作成しておく必要があります。ユーザー・アカウントは、次のツールまたは方法を使用してOracleバックエンド・ディレクトリに作成します。
Oracle Directory Service Manager
provProfileBulkProvコマンド行インタフェースを使用したバルク・プロビジョニング
他のOracleディレクトリおよびサード・パーティ・ディレクトリとの同期
LDAPコマンド行ツール
Oracle Directory Integration Platform Serviceは、バックエンド・ディレクトリでのユーザー・エントリの作成方法にかかわらず、任意のエントリに対して起動できます。ただし、Oracleバックエンド・ディレクトリにユーザー・エントリを作成すれば、Oracle Identity Management環境のすべてのアプリケーションにアクセスできるわけではありません。ユーザー・アカウントは、管理者が手動でプロビジョニングするか、アプリケーションのプロビジョニング・ポリシーに従って自動でプロビジョニングする必要があります。アプリケーションのデフォルト・プロビジョニング・ポリシーは、次のいずれかです。
すべてのユーザーをプロビジョニングします。
ユーザーをプロビジョニングしません。
プロビジョニング・ポリシーの評価後にユーザーをプロビジョニングします。
プロビジョニング・ポリシーは、エンタープライズ環境ごとの要件に全面的に依存します。たとえば、ある組織では、すべてのユーザーを電子メール・アプリケーションにアクセスできるようプロビジョニングする一方で、人事管理アプリケーションにアクセス可能なプロビジョニング・ユーザーを制限することが可能です。
Oracle Directory Integration Platform Serviceの構成要素は、次のとおりです。
この項では、Oracle Directory Integration Platformプロビジョニングでアプリケーションがどのようにプロビジョニングされるかについて説明します。内容は次のとおりです。
プロビジョニング統合アプリケーションでは、バックエンド・ディレクトリまたは接続リポジトリでユーザー情報を管理できます。バックエンド・ディレクトリにユーザー情報を保持するアプリケーションは、データ・アクセスJavaプラグインを使用して、バックエンド・ディレクトリで変更が発生するたびにユーザー・エントリを作成、変更および削除できます。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』のデータ・アクセス・プロビジョニング・プラグインに関する項。 |
データ・アクセスJavaプラグインは、LDAPコマンド行ツールなどのOracle Identity Managementから、直接起動できます。このため、データ・アクセスJavaプラグインを使用してプロビジョニングできるアプリケーションは同期的にプロビジョニングされ、個別のプロビジョニング・イベントをOracle Directory Integration Platformからアプリケーションに送信する必要はありません。データ・アクセスJavaプラグインは、Oracle Directory Integration PlatformにSUCCESSまたはFAILUREのいずれかを返します。実行ステータスSUCCESSがデータ・アクセスJavaプラグインに返される場合、プロビジョニング・ステータスも返され、特定のプロビジョニング統合アプリケーション用にバックエンド・ディレクトリのユーザーのプロビジョニング・ステータス属性に記録されます。ステータスFAILUREが新しいユーザー割当てリクエストに返される場合、ユーザーのプロビジョニング・ステータスは、値PROVISIONING_FAILUREに割り当てられます。プロビジョニング・ステータスのリストは、「Oracleバックエンド・ディレクトリのプロビジョニング・ステータス」を参照してください。
同期プロビジョニングは、次のプロセスに従って行われます。
次のソースのいずれかに基づいて、バックエンド・ディレクトリに新規ユーザー・エントリが作成されます。
Oracle Enterprise Managerユーザー・インタフェース
provProfileBulkProvコマンドを使用したバルク・プロビジョニング
接続されているOracleディレクトリおよびサード・パーティ・ディレクトリとの同期
新規ユーザー・エントリを作成したOracle Identity Managementコンポーネントは、データ・アクセスJavaプラグインを起動します。
データ・アクセスJavaプラグインは、アプリケーションに新規ユーザー・アカウントをプロビジョニングします。
図15-1に、LDAPコマンド行ツールを使用してアプリケーションが同期的にプロビジョニングされる場合のプロセスを示します。
LDAPコマンド行ツールを使用した同期プロビジョニングは、次のプロセスに従います。
LDAPコマンド行ツールによって、バックエンド・ディレクトリに新規ユーザー・エントリが作成されます。
次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがバックエンド・ディレクトリに存在することを確認します。
Oracle Directory Integration Platformは、データ・アクセスJavaプラグインを起動します。
データ・アクセスJavaプラグインは、アプリケーションに新規ユーザー・アカウントをプロビジョニングします。
Oracle Directory Integration Platformは、PL/SQLイベントをプロビジョニング統合アプリケーションに伝播した後、このアプリケーションがイベントを処理するためにPL/SQLプラグインを実行します。PL/SQLプラグインの実行は、アプリケーション・リポジトリ内で発生し、任意のOracle Identity Managementコンポーネントのアドレス空間では発生しません。プロビジョニングは、任意のOracle Identity ManagementのコンポーネントではなくPL/SQLプラグインによって処理されるため、PL/SQLプラグインを実装するプロビジョニング統合アプリケーションは、非同期的にプロビジョニングされます。PL/SQLプラグインは、Oracle Directory Integration PlatformにSUCCESSまたはFAILUREのステータスを返します。ステータスSUCCESSがPL/SQLプラグインに返される場合、プロビジョニング・ステータスも返され、特定のプロビジョニング統合アプリケーション用にバックエンド・ディレクトリのユーザーのプロビジョニング・ステータス属性に記録されます。ステータスFAILUREが新しいユーザー割当てリクエストに返される場合、ユーザーのプロビジョニング・ステータスは、値PROVISIONING_FAILUREに割り当てられます。プロビジョニング・ステータスのリストは、「Oracleバックエンド・ディレクトリのプロビジョニング・ステータス」を参照してください。
非同期プロビジョニングは、次のプロセスに従って行われます。
次のソースのいずれかに基づいて、バックエンド・ディレクトリに新規ユーザー・エントリとアプリケーション固有のユーザー・プリファレンスを含む関連エントリが作成されます。
Oracle Enterprise Managerユーザー・インタフェース
provProfileBulkProvコマンドを使用したバルク・プロビジョニング
接続されているOracleディレクトリおよびサード・パーティ・ディレクトリとの同期
次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがバックエンド・ディレクトリに存在することを確認します。
Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。
図15-2に、LDAPコマンド行ツールを使用してアプリケーションが非同期的にプロビジョニングされる場合のプロセスを示します。
図15-2に示されているとおり、LDAPコマンド行ツールを使用した非同期プロビジョニングは、次のプロセスに従います。
LDAPコマンド行ツールを使用して、Oracle Unified DirectoryまたはOracle Internet Directoryバックエンド・ディレクトリに新規ユーザー・エントリが作成されます。
次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがバックエンド・ディレクトリに存在することを確認し、アプリケーション固有のユーザー・プリファレンスを含む関連エントリを作成します。
Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。
プロビジョニングが同期的か非同期的かにかかわらず、アプリケーションでは、プロビジョニング・インテリジェンス機能を拡張してビジネス・ポリシーを実装するために、プレデータ・エントリ・プラグインとポストデータ・エントリ・プラグインを起動できます。どちらのプラグインも、provProfileBulkProvコマンドを使用したバルク・プロビジョニングによって起動されます。
プレデータ・エントリ・プラグインは、プロビジョニング・ポリシーに基づいてフィールドの移入を行います。このプラグインの主な目的は、アプリケーションにユーザーをプロビジョニングするかどうかを決定することです。たとえば、財務管理アプリケーションにはマネージャのみをプロビジョニングするというポリシーを持つ組織の場合、プレデータ・エントリ・プラグインを使用することで、どのユーザー・エントリをプロビジョニングするかを判別できます。共通のユーザー属性はこのプラグインの起動時にすでに移入されているため、プロビジョニングの決定を行うための十分な情報がすでに存在していることになります。
ポストデータ・エントリ・プラグインは、主に、ユーザーによって入力された共通属性とアプリケーション固有属性に関するデータを検証します。プロビジョニングを続けるためには、このプラグインでの検証に成功する必要があります。
図15-3に、プレデータ・エントリおよびポストデータ・エントリ・プラグインを使用したプロビジョニングのデータ・フローを示します。
図15-3に示されているとおり、プロビジョニングのデータ・フローは、次のプロセスに従います。
ベース・ユーザー情報が作成されます。
プレデータ・エントリ・プラグインが起動し、ポリシーに基づいてフィールドの移入が行われます。
ポストデータ・エントリ・プラグインが起動し、ユーザーが入力したデータが検証されます。
プロビジョニング方式に応じて、非同期または同期プロビジョニング・プロシージャが起動します。
この項では、Oracle Identity Managementでユーザーをプロビジョニングする手順について説明します。内容は次のとおりです。
Oracle Unified DirectoryまたはOracle Internet Directoryが中央リポジトリとして使用され、エンタープライズ・ユーザー・エントリが接続ディレクトリからバックエンド・ディレクトリに同期化される場合、各ユーザー・アイデンティティは、プロビジョニング統合アプリケーションごとのデフォルト・プロビジョニング・ポリシーに従って自動的にプロビジョニングされます。
オラクル社、または標準のLDAPコマンド行構文を利用するサード・パーティ・ベンダーによって開発された任意のツールを使用して、バックエンド・ディレクトリにユーザー・エントリを作成できます。外部ソースから同期化されたユーザー・エントリの場合と同様に、LDAPコマンド行ツールまたはその他の方法によって作成されたユーザー・エントリは、プロビジョニング統合アプリケーションごとのデフォルト・プロビジョニング・ポリシーに従ってプロビジョニングされます。
ORACLE_HOME/binディレクトリにあるprovProfileBulkProvユーティリティを使用して、プロビジョニング・プロファイルのために、LDIFファイルからバックエンド・ディレクトリへの初期のデータ移行を実行します。
|
注意:
|
provProfileBulkProv
provProfileBulkProv -h HOST -p PORT -D wlsuser -file LDIF_FILE -realm REALM_DN [-ssl -keystorePath PATH_TO_KEYSTORE -keystoreType TYPE] [-encoding INPUT_ENCODING] [-help]
-h | -host
Oracle Directory Integration PlatformがデプロイされているOracle WebLogic Serverホスト。
-p | -port
Oracle Directory Integration PlatformがデプロイされているOracle WebLogic管理対象サーバーのリスニング・ポート。
-D | -wlsuser
Oracle WebLogic ServerのログインID。
|
注意: Oracle WebLogic Serverのログイン・パスワードを要求されます。パスワードをコマンド行引数として指定することはできません。最良のセキュリティ・プラクティスは、コマンドからの要求への応答としてのみ、パスワードを入力することです。スクリプトからprovProfileBulkProvを実行する必要がある場合、Oracle WebLogic Serverパスワードを含むファイルから、入力をリダイレクトできます。ファイル権限を使用してファイルを保護し、不要になったら権限を削除します。 |
-f | -file
移行されるデータを含むLDIFファイル。
-realm
ユーザーがプロビジョニングされるレルム。
-ssl
SSLモードでコマンドを実行します。
|
注意: Oracle Directory Integration PlatformがデプロイされているOracle WebLogic管理対象サーバーは、SSLモードでこのコマンドを実行するようにSSLに対して構成されている必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「SSLの構成」を参照してください。 |
-keystorePath
キーストアへのフルパス。
-keystoreType
-keystorePathで識別されるキーストアのタイプ。たとえば、-keystorePath jksまたは-keystorePath PKCS12などです。
-encoding
入力ファイル・エンコーディング。
-help
コマンドの使用方法のヘルプを提供します。
オンデマンド・プロビジョニングは、ユーザーがアプリケーションにアクセスし、そのアプリケーションのリポジトリにユーザーの情報が存在しない場合に発生します。アプリケーションは、デフォルト・プロビジョニング・ポリシーに基づいてユーザー・アカウントをプロビジョニングするかどうかを決定します。リポジトリにユーザー・アカウントをプロビジョニングした後、アプリケーションは、バックエンド・ディレクトリのユーザー・エントリのプロビジョニング・ステータスを更新します。
この項では、Oracle Unified DirectoryまたはOracle Internet Directoryバックエンド・ディレクトリのユーザー・プロファイルの構成について説明します。内容は次のとおりです。
Oracle Directory Integration Platformプロビジョニングは、個人情報と、ユーザーがプロビジョニングされる様々なアプリケーション用の設定を含む属性で構成されるディレクトリ情報ツリー(DIT)のユーザー・プロファイルに依存します。Oracle Directory Integration Platform Serviceのこれらのユーザー属性は、次のように分類されます。
すべてのユーザー・エントリで使用されるベース属性
ユーザーがアプリケーションにプロビジョニングされる場合にのみ使用されるアプリケーション固有属性
ベース・ユーザー属性は、主にorganizationalPersonやinetOrgPersonなどの標準LDAPオブジェクト・クラスに属し、氏名、電子メール・アドレスおよび電話番号を含む個人の詳細情報で構成されます。ベース・ユーザー属性は、orclUserV2補助クラスに属するOracleアプリケーション固有の属性でも構成されます。
バックエンド・ディレクトリは、ベース属性およびアプリケーション固有属性の両方のプライマリ・リポジトリです。両方のタイプの属性は、各ユーザーのプロファイルに格納されています。ただし、アプリケーションは、プロビジョニング・イベント通知サービスで更新されるユーザー属性をキャッシュできます。図15-4に示すように、ユーザー属性はDITの2つの場所に格納されています。ベース・ユーザー・エントリ(inetorgpersonおよびorcluserv2に属す属性を含む)は、cn=users,Realm DNに格納されます。各ユーザー・エントリのプロビジョニング・ステータスも、ベース・ユーザー・エントリに格納されています。アプリケーション固有の属性は、アプリケーション・コンテナの個別のエントリに存在します。アプリケーション固有の属性定義に関連するLDAPスキーマおよびオブジェクト・クラスは、インストール処理またはアップグレード処理で作成されます。アプリケーション固有の属性は補助オブジェクト・クラスで修飾されるため、エントリのアプリケーション固有のユーザー・プロパティの検索が有効になります。デフォルトでは、アプリケーション固有のエントリは、cn=User Properties, cn=Application Type, cn=Products,cn=OracleContext, Realm DNコンテナにorclOwnerGUID=GUID of the Base Userとして格納されています。一部のアプリケーションは、自身のアプリケーション属性を管理してデータ・アクセスJavaプラグインを実装します(詳細は、「プロビジョニング概念の理解」で説明しています)。Oracle Directory Integration Platformサービスは、ベース・ユーザー属性またはアプリケーション固有の属性が変更される場合、常にこのプラグインを起動します。
図15-4 Oracleバックエンド・ディレクトリのベース・ユーザー属性とアプリケーション固有の属性
この項では、Oracle Unified DirectoryまたはOracle Internet Directoryのユーザー・プロビジョニング・ステータスについて説明します。内容は次のとおりです。
Oracleプロビジョニング・サービスでは、プロビジョニング統合アプリケーションごとに、ユーザーのプロビジョニング・ステータスがバックエンド・ディレクトリに記録されます。プロビジョニング・ステータスは、Oracle Directory Integration Platform、provProfileBulkProvコマンドによるバルク・プロビジョニング、またはプロビジョニング統合アプリケーションによって設定されます。表15-1に、プロビジョニング・ステータスを示します。
表15-1 バックエンド・ディレクトリのプロビジョニング・ステータス
| 内部ステータス | GUIステータス | 説明 |
|---|---|---|
|
プロビジョニング・ステータス |
||
|
|
保留 |
プロビジョニングが必要です。このステータスは、管理者が選択するか、アプリケーションのプロビジョニング・ポリシーに従って設定されます。このステータスにより、ユーザーがプロビジョニングされているかどうかが決定することに注意してください。 |
|
|
進行中 |
プロビジョニングが進行中です。スケジュールされた間隔でアプリケーションによりプロビジョニングが実行される場合、現行のステータスがこのステータスであれば、ユーザーはアプリケーションにアクセスできます。アプリケーションでは、ユーザーをオンデマンドでプロビジョニングすることが可能です。 |
|
|
成功 |
プロビジョニングに成功しました。このステータスは、Oracle Directory Integration Platform、provProfileBulkProvコマンドによるバルク・プロビジョニング、またはプロビジョニング統合アプリケーションによって自動的に更新されます。 |
|
|
リクエストなし |
プロビジョニングは必要ありません。このステータスは、管理者が選択するか、アプリケーションのプロビジョニング・ポリシーに従って設定されます。このステータスにより、ユーザーが今後プロビジョニングされるかどうかが決定することに注意してください。 |
|
|
失敗 |
プロビジョニングに失敗しました。このステータスは、Oracle Directory Integration Platform、provProfileBulkProvコマンドによるバルク・プロビジョニング、またはプロビジョニング統合アプリケーションによって自動的に更新されます。このステータスである場合、ユーザーはアプリケーションにアクセスできません。 |
|
プロビジョニング解除ステータス |
||
|
|
プロビジョニング解除が保留中です |
プロビジョニング解除が必要です。このステータスである場合、ユーザーはまだプロビジョニングされています。 |
|
|
プロビジョニング解除が進行中です |
プロビジョニング解除が進行中です。 |
|
|
正常にプロビジョニング解除されました |
プロビジョニング解除に成功しました。このステータスである場合、ユーザーはアプリケーションにアクセスできません。 |
|
|
プロビジョニング解除に失敗しました |
プロビジョニング解除に失敗しました。このステータスである場合、ユーザーはまだプロビジョニングされています。 |
|
アップグレード・ステータス |
||
|
|
アップグレードが保留中です |
プロビジョニングのアップグレードが保留中です。 |
|
|
アップグレードが進行中です |
プロビジョニングのアップグレードが進行中です。 |
|
|
アップグレードに失敗しました |
プロビジョニングのアップグレードに失敗しました。 |
各アプリケーションのプロビジョニング・ステータスは、ユーザー・エントリのorclUserApplnProvStatus属性に格納されます。この属性は、バックエンド・ディレクトリで索引付けされており、検索可能です。プロビジョニング統合アプリケーションごとに、サブタイプのorclUserApplnProvStatus属性が作成されます。たとえば、次の文には、電子メール・アプリケーションとスケジュール・アプリケーションに対するユーザーのプロビジョニング・ステータスが格納されています。電子メール・アプリケーションに対するユーザーのプロビジョニング・ステータスはPROVISIONING_SUCCESSですが、スケジュール・アプリケーションに対するプロビジョニング・ステータスはPROVISIONING_FAILUREです。
orclUserApplnProvStatus;CORP-MAIL_E-MAIL:PROVISIONING_SUCCESS orclUserApplnProvStatus;CORP-SCHEDULE_CALENDAR:PROVISIONING_FAILURE
アプリケーションのユーザーのプロビジョニング・ステータスについての追加情報はorclUserApplnProvStatusDesc属性に格納され、各アプリケーションのプロビジョニングの失敗アカウントはorclUserApplnProvFailureCount属性に格納されています。orclUserApplnProvStatus属性と同様に、個別のorclUserApplnProvStatusDesc属性およびorclUserApplnProvFailureCount属性は、各プロビジョニング統合アプリケーション用に作成されます。orclUserApplnProvStatusDesc属性の書式はorclUserApplnProvStatus属性と同じですが、次のように、タイムスタンプおよび説明文がアプリケーション名およびタイプに追加されます。
orclUserApplnProvStatusDesc;CORP-MAIL_E-MAIL:20040101010101^Missing employee ID
orclUserApplnProvStatus、orclUserApplnProvStatusDescおよびorclUserApplnProvFailureCount属性は、オプション属性としてorclUserProvStatusオブジェクト・クラスに格納されます。
表15-2に、有効なプロビジョニング・ステータスの遷移を示します。
表15-2 バックエンド・ディレクトリでの有効なプロビジョニング・ステータスの遷移
| 内部ステータス | GUIステータス | 有効な遷移元 |
|---|---|---|
|
プロビジョニング・ステータス |
||
|
|
保留 |
初期不明状態
|
|
|
進行中 |
|
|
|
成功 |
|
|
|
リクエストなし |
初期不明状態 |
|
|
失敗 |
|
|
プロビジョニング解除ステータス |
||
|
|
プロビジョニング解除が保留中です |
|
|
|
プロビジョニング解除が進行中です |
|
|
|
正常にプロビジョニング解除されました |
|
|
|
プロビジョニング解除に失敗しました |
|
図15-5に、有効なプロビジョニング・ステータスの遷移を示します。
Oracle Identity Managementでは、バックエンド・ディレクトリ内の1つのユーザー・エントリが、複数のLDAPエントリによって物理的に示されることがあります。ベース・ユーザー・エントリ以外に、プロビジョニング統合アプリケーションごとに複数の独立したLDAPエントリが存在する可能性があります。
Oracle Identity Managementの通常のアップグレードでは、複数の中間層は同時にアップグレードされません。つまり、Oracle Identity Managementのアップグレード後も、旧バージョンの中間層とアップグレード・バージョンの中間層を同時に実行する必要がある場合があります。中間層をアップグレードすると、アプリケーションのメタデータ・リポジトリに格納されていたユーザーのアプリケーション固有データは、すべて必要に応じて移行されます。Oracle Directory Integration Platformは、アップグレード前からバックエンド・ディレクトリに存在しているユーザー・エントリごとに新規ユーザー・イベントを起動し、各ユーザー・エントリにPENDING_UPGRADEというプロビジョニング・ステータスを割り当てます。新規ユーザー・エントリが、古い中間層や一部のサポートされない手順(標準のLDAP SDKを使用した既存アプリケーションなど)によって作成されると、プロビジョニング・ステータス属性は失われます。この場合も、Oracle Directory Integration Platformは、新規ユーザー・イベントを起動し、各ユーザー・エントリにPENDING_UPGRADEというプロビジョニング・ステータスを割り当てます。
イベントを受信したプロビジョニング統合アプリケーションは、ユーザーがプロビジョニングされているかどうかを示すレスポンスをOracle Directory Integration Platformに返します。Oracle Directory Integration Platformは、そのレスポンスに従ってユーザー・エントリのプロビジョニング・ステータスを更新します。
ユーザー・インタフェースで作成されたか、外部データソースを使用した同期を通して作成された新しいユーザー・エントリが、特定のアプリケーションでユーザーをプロビジョニングするための十分な情報を含まない場合、プロビジョニングは失敗する場合があります。プロビジョニングは、その他の様々な理由で失敗する可能性もあります。Oracle Directory Integration Platform Serviceは、ユーザー・プロビジョニングの失敗を例外として識別します。アプリケーションがUSER_ADDイベントに失敗のステータスで応答する場合、Oracle Directory Integration Platformは常にユーザーのプロビジョニング・ステータスをPROVISIONING_FAILUREに変更します。次に、Oracle Directory Integration Platformは、この失敗を新しいユーザーの場合と同様にアプリケーションに通知します。これは、プロビジョニング要求の再試行として機能します。ユーザーのプロビジョニング・ステータスは、ユーザー・インタフェースに表示されます。管理者は問題の修正に必要な変更を行うことができ、プロビジョニングは自動的に再試行されます。これによって、プロビジョニングが同期的な場合にデータ・アクセス・プラグインが起動されます。一方、プロビジョニングが非同期的な場合はイベントが伝播されます。この一連のステップはユーザーが正常にプロビジョニングされない間再試行されます。
この項では、様々なプロビジョニング・シナリオでの情報および制御のフローについて説明します。内容は次のとおりです。
11gリリース1(11.1.1)の時点では、次の手順に従って、Oracle Enterprise Manager Fusion Middleware Controlを使用してプロビジョニング・プロファイルを表示および編集します。
Webブラウザを開き、使用している環境のOracle Enterprise Manager Fusion Middleware ControlのURLを入力します。Oracle Enterprise Manager Fusion Middleware ControlのURLの形式は、https://host:port/emです。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。
左のナビゲーション・パネルで、「Identity and Access」エントリをクリックするか展開し、続いて、表示または編集するプロファイルを含むDIPコンポーネントを選択します。
「DIPサーバー」メニューから「管理」→「プロビジョニング・プロファイル」を選択します。「プロビジョニング・プロファイルの管理」画面が表示され、既存のプロビジョニング・プロファイルが表示されます。
表示されるプロビジョニング・プロファイルの属性を変更するには、「表示」→「列」をクリックして、表示または非表示にする属性を選択します。また、「表示」→「列の並替え」をクリックすると、プロビジョニング・プロファイルの列を並べ替えることができます。
プロビジョニング・プロファイルを有効または無効にするには、適切なプロファイルをクリックして「有効化」または「無効化」をクリックします。
プロビジョニング・プロファイルを編集するには、編集するプロファイルをクリックして「編集」をクリックします。プロファイルの属性が表示されます。必要に応じて設定を編集し、「OK」をクリックして変更を保存します。表15-3に、プロビジョニング・プロファイルのフィールドおよび説明を示します。
表15-3 プロビジョニング・プロファイルのフィールド
| フィールド名 | 説明 |
|---|---|
|
プロファイル名 |
編集するプロファイルの名前。作成後にプロファイル名を編集することはできません。このフィールドは、編集するプロファイルを識別するためにのみ提供されています。 |
|
アプリケーション名 |
プロビジョニング・プロファイルが適用されるアプリケーションの名前。 |
|
プロファイルのバージョン |
プロビジョニング・プロファイルのバージョン。 |
|
「アプリケーションからOIDへ」または「アプリケーションからOUDへ」 |
アプリケーションとOracleバックエンド・ディレクトリ間の関係において、プロビジョニング・プロファイルを「構成済」または「有効」に設定するためのオプション。 |
|
「OIDからアプリケーションへ」または「OUDからアプリケーションへ」 |
アプリケーションとOracleバックエンド・ディレクトリ間の関係において、プロビジョニング・プロファイルを「構成済」または「有効」に設定するためのオプション。 |
|
スケジュール済の間隔(HH: MM: SS) |
接続ディレクトリとアプリケーションとバックエンド・ディレクトリ間の関係のプロビジョニングの、試行間隔の時間数、分数および秒数を指定します。 |
|
最終実行 |
前回のプロビジョニング試行のステータス(「成功」または「失敗」)および実行時間を表示します。 |
デプロイでは、多くの場合サード・パーティのエンタープライズ・ユーザー・リポジトリなどの外部ソースからユーザーをプロビジョニングすると予想されます。このようなタイプのデプロイでは、サード・パーティ・リポジトリによってバックエンド・ディレクトリがブートストラップされます。Oracle Directory Integration Platformでは、バックエンド・ディレクトリと接続リポジトリ間の継続的な同期を提供します。接続ユーザー・リポジトリの例には、Human Resourcesや、Microsoft Active Directory、Oracle Directory Server Enterprise Edition(旧称Sun Java System Directory Server)、Novell eDirectory、IBM Tivoli Directory ServerおよびOpenLDAPなどのLDAPディレクトリがあります。
Oracle Directory Synchronization Serviceは、バックエンド・ディレクトリにユーザー・エントリを作成します。外部ソースから取得される情報は、様々なアプリケーションにユーザーをプロビジョニングするには不十分である可能性があるため、アプリケーション情報の作成にはアプリケーションのデフォルトが使用されます。
Oracle Directory Synchronization Serviceでは、次のようにユーザーが作成されます。
Oracle Directory Synchronization Serviceは、アプリケーションで指定されたプロビジョニング・ポリシーを評価し、ユーザーをアプリケーションにプロビジョニングするかどうかを決定します。
Oracle Directory Synchronization Serviceは、アプリケーションに登録されているその他のプラグインを評価します。
Oracle Directory Integration Platform Serviceは、PL/SQLプラグインまたはデータ・アクセスJavaプラグインを起動して、ユーザー情報をアプリケーションに送信します。
イベント・インタフェースの使用により、アプリケーションからユーザーのプロビジョニング・ステータスが返されます。
Oracle Directory Integration Platform Serviceは、アプリケーション用のユーザーのプロビジョニング・ステータスを更新します。
Oracle Delegated Administration Servicesの管理権限は、各管理者に委任される権限によって異なります。管理者は、次のシナリオで説明されているように、ユーザーの管理およびプロビジョニング、またはアプリケーションの管理を行う権限を付与されるか、またはこれらの権限の組み合せたものを付与されます。
|
注意:
|
プロビジョニング管理モデル
次のタイプのプロビジョニング情報は、Oracle Internet Directoryバックエンド・ディレクトリで管理されます。
ベース・ユーザー情報。
アプリケーション固有情報。
各プロビジョニング統合アプリケーションのユーザー・プロビジョニング・ステータス。この情報は、ベース・ユーザー・エントリに格納されますが、個別に管理されます。
管理者とユーザーには、それぞれ次のタイプの権限が必要です。
管理者は、ベース・ユーザー属性とアプリケーション固有情報を管理するための権限が必要です。
ユーザーは、自分自身のベース属性とアプリケーション固有情報を管理するための権限が必要です。
管理権限を保持するユーザー・アカウントは、cn=User Provisioning Admins,cn=Groups,cn=OracleContextというグループ・エントリによって示されます。アプリケーション固有情報を管理するため、アプリケーションでは、cn=User Provisioning Admins,cn=Groups,cn=OracleContextグループに権限を付与する必要があります。アプリケーションですでに管理権限を保持するグループを定義している場合は、その権限を保持するグループのメンバーとしてこのグループを追加する必要があります。
