(57)【特許請求の範囲】
【請求項１】
アイデンティティ・マネージャの分散型トポロジ・イネーブラが、
複数のアイデンティティ・マネージャ（ＩＭ）ノードからの既存のアイデンティティ管理情報を結合するステップと、
前記複数のＩＭノードからの前記結合された情報を提示するステップと、
前記アイデンティティ管理情報を変更するためのプロビジョニング・リクエストを受信するステップと、
複数の別々のサブ・リクエストを形成するために、前記プロビジョニング・リクエストを分解するステップと、
前記サブ・リクエストを処理する１つ以上のＩＭノードを特定するステップと、
前記サブ・リクエストを、前記１つ以上のＩＭノードに並行して発行するステップと、
前記サブ・リクエストそれぞれのステータスを、当該サブ・リクエストを処理している前記１つ以上のＩＭノードそれぞれから受信するステップと、
前記受信されたステータスを結合するステップと、
前記結合されたステータスを、前記プロビジョニング・リクエストのステータスとして返すステップと、
を含む方法。
【請求項２】
少なくとも１つのＩＭノードが利用不可能であると判断し、前記リクエストを、後で提出するためにキューに入れるステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
前記プロビジョニング・リクエストは、アカウントまたはアクセスの作成、アカウントの修正、アカウントの一時停止、アカウントの回復、アカウントまたはアクセスの削除、未処理のｔｏ  ｄｏ項目の承認または拒否、未処理のｔｏ  ｄｏ項目についてのより多くの情報の提供、および未処理のリクエストの中断のうちの１つを実行することである、請求項１に記載の方法。
【請求項４】
前記アイデンティティ管理情報に関するクエリであって、アカウント情報、リクエスト情報、およびｔｏ  ｄｏ情報のうちの１つに関する、前記クエリを受信するステップと、
前記クエリを処理する１つ以上のＩＭノードを特定するステップと、
前記受信されたクエリを、複数の別々のサブ・クエリを形成するために分解するステップと、
前記サブ・クエリを、前記１つ以上のＩＭノードに並行して発行するステップと、
前記１つ以上のＩＭノードから結果を受信するステップと、
前記受信された結果を結合するステップと、
前記結合された結果を返すステップと、
をさらに含む、請求項１に記載の方法。
【請求項５】
アイデンティティ情報を見るためのリクエストをユーザから受信するステップと、
メインのＩＭノードから前記アイデンティティ情報を読み出すステップと、
前記アイデンティティ情報に対する変更を、前記ユーザから受信するステップと、
前記変更を前記メインのＩＭノードに提出するステップであって、前記メインのＩＭノードは、前記変更を他のＩＭノードに発行し、前記メインのＩＭノード上のノーティファイア・モジュールは、オブジェクト・スタブに関する通知パケットを発行する、前記ステップと、
前記通知パケットの受信に応答して、ディレクトリ・サーバ内の前記オブジェクト・スタブを更新するステップと、
をさらに含む、請求項１に記載の方法。
【請求項６】
アイデンティティ情報に対する変更を、アイデンティティ・フィードから受信するステップと、
メインのＩＭノードにて前記変更を加えるステップであって、前記メインのＩＭノードは、前記変更を他のＩＭノードに発行し、前記メインのＩＭノード上のノーティファイア・モジュールは、オブジェクト・スタブに関する通知パケットを発行する、前記ステップと、
前記通知パケットの受信に応答して、ディレクトリ・サーバ内の前記オブジェクト・スタブを更新するステップと、
をさらに含む、請求項１に記載の方法。
【請求項７】
請求項１〜６の何れか１つに記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項８】
プロセッサと、
前記プロセッサに連結され、動作を実行する、アイデンティティ・マネージャの分散型トポロジ・イネーブラ（ＤＴＥＩＭ）システムと、
を含むシステムであって、前記動作は、
複数のアイデンティティ・マネージャ（ＩＭ）ノードからの既存のアイデンティティ管理情報を結合すること、
前記複数のＩＭノードからの前記結合された情報を提示すること、
前記アイデンティティ管理情報を変更するためのプロビジョニング・リクエストを受信すること、
複数の別々のサブ・リクエストを形成するために、前記プロビジョニング・リクエストを分解すること、
前記サブ・リクエストを処理する１つ以上のＩＭノードを特定すること、
前記サブ・リクエストを、前記１つ以上のＩＭノードに並行して発行すること、
前記サブ・リクエストそれぞれのステータスを、当該サブ・リクエストを処理している前記１つ以上のＩＭノードそれぞれから受信すること、
前記受信されたステータスを結合すること、および
前記結合されたステータスを、前記プロビジョニング・リクエストのステータスとして返すこと、
を含む、システム。
【請求項９】
前記プロビジョニング・リクエストは、アカウントまたはアクセスの作成、アカウントの修正、アカウントの一時停止、アカウントの回復、アカウントまたはアクセスの削除、未処理のｔｏ  ｄｏ項目の承認または拒否、未処理のｔｏ  ｄｏ項目についてのより多くの情報の提供、および未処理のリクエストの中断のうちの１つを実行することである、請求項８に記載のシステム。
【請求項１０】
前記動作は、
前記アイデンティティ管理情報に関するクエリであって、アカウント情報、リクエスト情報、およびｔｏ  ｄｏ情報のうちの１つに関する、前記クエリを受信すること、
前記クエリを処理する１つ以上のＩＭノードを特定すること、
前記受信されたクエリを、複数の別々のサブ・クエリを形成するために分解すること、
前記サブ・クエリを、前記１つ以上のＩＭノードに並行して発行すること、
前記１つ以上のＩＭノードから結果を受信すること、
前記受信された結果を結合すること、および
前記結合された結果を返すこと、
をさらに含む、請求項８に記載のシステム。
【請求項１１】
前記動作は、
アイデンティティ情報を見るためのリクエストをユーザから受信すること、
メインのＩＭノードから前記アイデンティティ情報を読み出すこと、
前記アイデンティティ情報に対する変更を、前記ユーザから受信すること、
前記変更を前記メインのＩＭノードに提出することであって、前記メインのＩＭノードは、前記変更を他のＩＭノードに発行し、前記メインのＩＭノード上のノーティファイア・モジュールは、オブジェクト・スタブに関する通知パケットを発行する、前記提出すること、および
前記通知パケットの受信に応答して、ディレクトリ・サーバ内の前記オブジェクト・スタブを更新すること、
をさらに含む、請求項８に記載のシステム。
【請求項１２】
前記動作は、
アイデンティティ情報に対する変更を、アイデンティティ・フィードから受信すること、
メインのＩＭノードにて前記変更を加えることであって、前記メインのＩＭノードは、前記変更を他のＩＭノードに発行し、前記メインのＩＭノード上のノーティファイア・モジュールは、オブジェクト・スタブに関する通知パケットを発行する、前記加えること、および
前記通知パケットの受信に応答して、ディレクトリ・サーバ内の前記オブジェクト・スタブを更新すること、
をさらに含む、請求項８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、種々のアイデンティティ・マネージャ（ＩＭ：Ｉｄｅｎｔｉｔｙ  Ｍａｎａｇｅｒ）システムへのユーザ・アクセスを制御する、アイデンティティ・マネージャの分散型トポロジ・イネーブラ（ｄｉｓｔｒｉｂｕｔｅｄ  ｔｏｐｏｌｏｇｙ  ｅｎａｂｌｅｒ  ｆｏｒ  ａｎ  ｉｄｅｎｔｉｔｙ  ｍａｎａｇｅｒ）に関する。
【背景技術】
【０００２】
アイデンティティ・マネージャ（ＩＭ）システムは、種々のシステムへのユーザ・アクセスを制御する。システムは、ユーザ識別（ｕｓｅｒｉｄ）管理を必要とする「エンド・ポイント」と表現することもできる。システムには、コンピュータ、コンピュータ・アプリケーション、ネットワーク・デバイス、ヒューマン・インターフェイス・デバイス、アプライアンスなどの任意の組み合わせがあり得る。
【０００３】
典型的には、分散型ＩＭノードの実装には、例として次を含む要求がある。
・毎日２４時間、利用可能であること
・何百万ものユーザ／アカウント
・何千もの管理対象プラットフォーム
・分散したアドミニストレーションおよび管理
・分散したメンテナンス
【発明の概要】
【発明が解決しようとする課題】
【０００４】
これらの要求は、従来のＩＭシステムにおける運用上の課題を提示する。例えば、従来のＩＭシステムでは、何万ものサービスの調整負荷およびスケジューリングを管理する要求、これらのサービスのＩＭ設定タスクを分散させる必要性、およびＩＭ機能性全体を停止することなくシステム・メンテナンス・アクティビティのローリング・スケジュールを提供する必要性が、難題となっている。従来のＩＭシステムには、パフォーマンスを改善してフェイルオーバを提供するためにクラスタに展開され得るものもあるが、従来のＩＭシステムは、非常に大規模な構成において、メンテナンスもしくはアップグレード期間も、調整負荷管理に対する制御も、または分散化されたアドミニストレーションおよびメンテナンスも提供しない。
【０００５】
したがって、非常に大規模な実装における既存のＩＭソリューションには欠点がある。例えば、クラスタにノードを追加することによる拡張性がもたらされ得るが、このソリューションは、単一のデータ・リポジトリというボトルネックをかかえると考えられる。さらに、機能停止またはメンテナンス期間が、ＩＭインフラストラクチャ全体を停止させることもある。さらに、設定タスクは、単一のアプリケーション上で管理および実装され、設定負荷が一点に置かれる。
【課題を解決するための手段】
【０００６】
複数のアイデンティティ・マネージャ（ＩＭ）ノードからの既存のアイデンティティ管理情報を結合する方法、コンピュータ・プログラム、およびシステムが提供される。複数のＩＭノードからの結合された情報が提示される。アイデンティティ管理情報を変更するプロビジョニング・リクエスト（ｐｒｏｖｉｓｉｏｎｉｎｇ  ｒｅｑｕｅｓｔ）が受信される。プロビジョニング・リクエストは、複数の別々のサブ・リクエストを形成するために分解される。サブ・リクエストを処理するために１つ以上のＩＭノードが特定される。サブ・リクエストは、並行して該１つ以上のＩＭノードに発行（ｉｓｓｕｅ）される。サブ・リクエストそれぞれのステータスが、当該サブ・リクエストを処理している該１つ以上のＩＭノードそれぞれから受信される。受信されたステータスが結合される。結合されたステータスが、プロビジョニング・リクエストのステータスとして返される。
【図面の簡単な説明】
【０００７】
【図１】特定の実施形態によるシステム・アーキテクチャを示す。
【図２】特定の実施形態によるアイデンティティ・マネージャの分散型トポロジ・イネーブラ（ＤＴＥＩＭ：Ｄｉｓｔｒｉｂｕｔｅｄ  Ｔｏｐｏｌｏｇｙ  Ｅｎａｂｌｅｒ  ｆｏｒ  Ｉｄｅｎｔｉｔｙ  Ｍａｎａｇｅｒ）アーキテクチャを示す。
【図３】特定の実施形態による例示としてのＤＴＥＩＭログイン・スクリーンを示す。
【図４】特定の実施形態による、ユーザ・インターフェイス（ＵＩ：Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）スクリーン内の例示としてのＤＴＥＩＭホーム・ページを示す。
【図５】特定の実施形態による、ＵＩスクリーン内の例示としてのＤＴＥＩＭアドミニストレーション・ページを示す。
【図６】特定の実施形態による、ＵＩスクリーン内の「グローバルＩＭからトポロジをインポート」機能の選択を示す。
【図７】特定の実施形態による、ＵＩスクリーン内のノード・サービス閲覧タブの選択を示す。
【図８】特定の実施形態による、ＵＩスクリーン内のＤＴＥＩＭアドミン・メニューおよびＩＭノード追加タブの選択を示す。
【図９】特定の実施形態による、ＵＩスクリーン内のパーソナル情報管理メニューおよびパーソナル情報タブの選択を示す。
【図１０】特定の実施形態による、ＵＩスクリーン内のアカウント管理メニューの選択を示す。
【図１１】特定の実施形態による、ＵＩスクリーン内の新アカウント追加メニューの選択を示す。
【図１２】特定の実施形態による、ＵＩスクリーン内のアクセス管理メニューの選択を示す。
【図１３】特定の実施形態による、ＵＩスクリーン内のパスワード管理メニューの選択を示す。
【図１４】特定の実施形態による、ＵＩスクリーン内のリクエスト管理ページを示す。
【図１５】特定の実施形態による、ＵＩスクリーン内のＴｏ  Ｄｏ項目管理ページを示す。
【図１６】特定の実施形態による、ＵＩスクリーン内のグループ化された再認証リクエストのレビューを示す。
【図１７】特定の実施形態による、認証のためにＤＴＥＩＭ  ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ：アプリケーション・プログラミング・インターフェイス）を使用する例であるコード・スニペットを示す。
【図１８】特定の実施形態による、ＤＴＥＩＭライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）データ・ストアからユーザのアカウント・スタブおよびアカウント・データを読み出すためにＤＴＥＩＭデータ・サービスＡＰＩを使用する例であるコード・スニペットを示す。
【図１９】特定の実施形態による、アカウント・スタブを読み出すためにＤＴＥＩＭデータ・サービスＡＰＩを使用する例であるコード・スニペットを示す。
【図２０】特定の実施形態による、アカウントの更新または作成の例であるコード・スニペットを示す。
【図２１】特定の実施形態による、アカウントのユーザの、権限を与えられたサービスを読み出す例であるコード・スニペットを示す。
【図２２】特定の実施形態による、個人のポピュレートされたフォームを得る例であるコード・スニペットを示す。
【図２３】特定の実施形態による、パスワード・ルールを得る例であるコード・スニペットを示す。
【図２４】特定の実施形態による、パスワード変更の例であるコード・スニペットを示す。
【図２５】特定の実施形態による、参加しているＩＭノードから「ｔｏ  ｄｏ」項目のリストを得る例であるコード・スニペットを示す。
【図２６】特定の実施形態によるＤＴＥＩＭデータ・ストアを示す。
【図２７】特定の実施形態によるスキーマを示す。
【図２８】特定の実施形態によるスキーマを示す。
【図２９】特定の実施形態によるスキーマを示す。
【図３０】特定の実施形態によるユーザ・インターフェイス内のアカウント・スタブの例を示す。
【図３１】特定の実施形態によるユーザ・インターフェイス内の個人スタブ（ｐｅｒｓｏｎ  ｓｔｕｂ）の例を示す。
【図３２】特定の実施形態によるウェブ・サービス・アーキテクチャを示す。
【図３３】特定の実施形態による、ウェブ・サービスを使用して、ＩＭノードに対し認証を行いユーザの個人オブジェクトを取得する例であるコード・スニペットを示す。
【図３４】特定の実施形態による、ＩＭノード・トポロジを発見するためにＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図３５】特定の実施形態による、ユーザによって開始された変更に関する各ＩＭノード上のアイデンティティ情報の同期のためにＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図３６】特定の実施形態による、アイデンティティ・フィード（ｉｄｅｎｔｉｔｙ  ｆｅｅｄ）を介して開始された変更に関する各ＩＭノード上のアイデンティティ情報の同期のためにＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図３７】特定の実施形態による、複数のＩＭノードからのＩＭ情報を結合するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図３８】特定の実施形態による、複数のＩＭノードからのＩＭ情報を結合するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図３９】特定の実施形態による、複数のＩＭノードに並行して情報に関するクエリを発行するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４０】特定の実施形態による、複数のＩＭノードに並行して情報に関するクエリを発行するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４１】特定の実施形態による、ユーザ・リクエストの処理のためにＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４２】特定の実施形態による、変更のリクエストを並行して発行するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４３】特定の実施形態による、変更のリクエストを並行して発行するようＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４４】特定の実施形態による、ＩＭノードに直接追加されたユーザ・アカウントに関してＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４５】特定の実施形態による、ＩＭノード上で直接行われたアカウント修正またはパスワード変更に関してＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４６】特定の実施形態による、ＩＭノード上のアカウント一時停止に関してＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４７】特定の実施形態による、ＩＭノード上のアカウント回復に関してＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４８】特定の実施形態による、ＩＭノード上のアカウント削除に関してＤＴＥＩＭエンジンによって実行される論理をフロー図で示す。
【図４９】特定の実施形態により使用され得るコンピュータ・アーキテクチャを示す。
【発明を実施するための形態】
【０００８】
以下、図面を参照する。図面では、同じ参照番号は、全体にわたって対応する部分を表す。
【０００９】
以下の記載では、添付の図面を参照する。図面は、本願明細書の一部を構成し、本発明のいくつかの実施形態を示す。当然のことながら、本発明の範囲から逸脱することなく、他の実施形態が利用されても、構造および動作上の変更が加えられてもよい。
【００１０】
実施形態は、アイデンティティ・マネージャ（ＩＭ）ノードの展開に、分散型アプローチを取り入れる。分散型アプローチは、複数のＩＭノードの上に、アイデンティティ・マネージャの分散型トポロジ・イネーブラ（ＤＴＥＩＭ）ノード（すなわち管理ノード）を提供して、複数のＩＭノード（例えば数百または数千のサービスをホストしている）にわたってサービス作業負荷を分割することに基づく。実施形態は、エンタープライズの複数のＩＭノードにまたがるユーザのアイデンティティおよびアカウント情報の結合された管理およびビューのために、ＤＴＥＩＭノードを提供する一方で、ＩＭノードの設定およびアドミニストレーション・タスクを分散化する。ＤＴＥＩＭノードは、ユーザ・リクエストを適切なＩＭノードへルーティングする。続いて、ＤＴＥＩＭノードは、種々のＩＭノードから受信される情報を結合して、この結合された情報をエンド・ユーザに提示する。様々な実施形態において、「ユーザ」という用語は、人間であるユーザ、コンピュータ・プログラム、ハードウェア・デバイスなどを表し得る。
【００１１】
図１は、特定の実施形態によるシステム・アーキテクチャを示す。アイデンティティ・マネージャの分散型トポロジ・イネーブラ（ＤＴＥＩＭ）ノード１００は、ＤＴＥＩＭサーバ１１０およびＤＴＥＩＭディレクトリ・サーバ１４０を含む。ＤＴＥＩＭサーバ１１０は、ＤＴＥＩＭエンジン１２０を含む。ＤＴＥＩＭノード１００は、アイデンティティ・マネージャ（ＩＭ）ノード１５０のネットワークに連結されている。特定の実施形態では、ＩＭノード１５０は、ＩＭシステムと呼ばれることもある。
【００１２】
特定の実施形態では、ＤＴＥＩＭアーキテクチャという用語は、各ＤＴＥＩＭコンポーネントを含む、抽象的なＤＴＥＩＭインフラストラクチャ全体を指す。特定の実施形態では、ＤＴＥＩＭトポロジという用語は、ＤＴＥＩＭエンジン１２０に制御されているＩＭノード１５０のコレクションを指す。
【００１３】
実施形態は、アイデンティティ情報およびサービスを複数のＩＭノード１５０にわたって分散させることによって、非常に大きなＩＭ実装における、徐々に拡張可能なソリューションを提供する。特定の実施形態では、ＩＭ実装は、ＩＭノードのハードウェア／ソフトウェアのサイズではなく、ユーザ、サービスなどの数を含む、ＩＭソリューションのサイズに関係する。
【００１４】
特定の実施形態では、ＤＴＥＩＭサーバ（ＤＴＥＩＭサーバ１１０など）にてＤＴＥＩＭエンジン１２０を使用することで、以下が提供される。
・ＩＭノード１５０をサービスのサブセット専用とすることによる改善されたパフォーマンス。すなわち、各ＩＭノード１５０は、サービスのサブセットをホストする。さらに、各ＩＭノード１５０は、人員（ｐｅｏｐｌｅ）のサブセットを有してもよい。
・追加のエンド・ポイントを追跡するために、新たなサービスが取り入れられるときにＩＭノード１５０を追加することによる改善された拡張性。
・１つのＩＭノード１５０上でのモノリシックな設定ではなく、複数のＩＭノード１５０にわたる分散化アドミニストレーションおよび設定。
・種々のＩＭノード１５０が種々のプラットフォーム上にあることを可能にし、さらに種々のＩＭバージョンも可能にする、異種ＤＴＥＩＭ機能。ＤＴＥＩＭエンジン１２０が、ＩＭノード１５０に対して「バージョンを意識した」動作を実行する。
・ＩＭインフラストラクチャ全体をシャット・ダウンさせることなく、メンテナンスおよびアップグレードを個々のＩＭノード１５０上で実行可能である。
・ＩＭの抽象化を可能にする。ＩＭレイヤの上にあるＤＴＥＩＭレイヤを、ユーザ・リクエストの処理のために使用可能である。
・ＩＭノード１５０および各ＩＭノード１５０上のサービスを発見する機能を含む。
・外部のアプリケーションがＤＴＥＩＭエンジン１２０とインターフェイスをとることを可能にするＤＴＥＩＭモデル・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）を含む。
・ＤＴＥＩＭエンジン１２０と、ＩＭノード１５０との間で、ウェブ・サービス・ベースの通信を使用する。
・エンド・ユーザ・ベースの機能性をＤＴＥＩＭエンジン１２０上で提供する。アドミニストレータ機能性は、分散化され、ＩＭノード１５０上で実行される。
【００１５】
ＤＴＥＩＭエンジン１２０により、非常に大規模なユーザおよびサービス・ベースに徐々に拡張可能なソリューションを提供するための分散型ＩＭアーキテクチャが存在する。特定の実施形態では、ＤＴＥＩＭトポロジは、ＤＴＥＩＭサーバ１１０を介してアクセスされる疎結合ＩＭノード１５０から成る。特定の実施形態では、ＤＴＥＩＭエンジン１２０は、複合型のリバース・プロキシ・サーバ兼情報・応答結合器として機能上動く、ＪＡＶＡ（Ｒ）２プラットフォーム・エンタープライズ・エディション（Ｊ２ＥＥ（ＪＡＶＡ（Ｒ）２  Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）（Ｒ））アプリケーションとしてもよい。ＤＴＥＩＭエンジン１２０は、１つ以上のターゲット・サービスに基づき、多数のＩＭメンバ・ノードのうちの１つにユーザ・リクエストを分散させ（例えばスプレー（ｓｐｒａｙ）し）、アイデンティティ・マネージャ情報および複数のＩＭノードからのエンド・ユーザへの応答を結合する。（ＪＡＶＡおよびＪ２ＥＥは、米国、その他の国々、または両方における、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓの商標である）。
【００１６】
ＤＴＥＩＭエンジン１２０は、ＤＴＥＩＭサービスを提供し、ＡＰＩ実装を提供する。ＡＰＩは、種々のＩＭノード１５０からのユーザ情報を結合し、ウェブ・サービス・インターフェイスを使用してＩＭノード１５０と通信し、ＩＭノード１５０におけるサービスを発見し、サービス対ＩＭノードのマッピングを維持し、ＩＭセルフ・サービス機能と似た機能性を提供し、ローカルＤＴＥＩＭサーバを利用してノード、個人およびアカウントの関係を得る。
【００１７】
ＤＴＥＩＭエンジン１２０は、種々のＩＭからの応答を結合して、エンド・ユーザに提示する。ＤＴＥＩＭエンジン１２０はさらに、分散型ＩＭ  ＡＰＩ（ＤＴＥＩＭ  ＡＰＩ）モジュールをホストし、これは、カスタム・ユーザ・インターフェイス（ＵＩ）を提供するために外部のウェブ・アプリケーションによって使用されること、またはＪＡＶＡ（Ｒ）クライアントによって呼び出されることが可能である。下記で、ＤＴＥＩＭユーザ・インターフェイス（ＵＩ）ウェブ・アプリケーションが、ＤＴＥＩＭ機能およびＡＰＩの使用法を説明するために提供されており、これを、カスタムＵＩをセットアップするためのベースとして使用することができる。
【００１８】
特定の実施形態において、ＤＴＥＩＭアーキテクチャは：
・個々のＩＭノード１５０が、サービスのサブセット用に指定されるようにし、したがって、サービス境界に基づき負荷を分散させる。
・ＩＭプラットフォームの異種混合を可能にし、その結果ＩＭノード１５０は、様々なオペレーティング・システム上に展開され得る（例えば、ＷＩＮＤＯＷＳ（Ｒ）オペレーティング・システム、ＵＮＩＸ（Ｒ）オペレーティング・システム、ＬＩＮＵＸ（Ｒ）オペレーティング・システム、またはこれらの任意の混合）。（ＷＩＮＤＯＷＳ（Ｒ）は、米国、その他の国々、または両方における、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎの商標である。ＵＮＩＸ（Ｒ）は、米国、その他の国々、または両方における、Ｔｈｅ  Ｏｐｅｎ  Ｇｒｏｕｐの商標である。ＬＩＮＵＸ（Ｒ）は、米国、その他の国々、または両方における、Ｌｉｎｕｓ  Ｔｏｒｖａｌｄｓの商標である）。すなわち、ＩＭノード１５０は、複数のプラットフォームおよび複数のＩＭバージョンにわたる、異種のものでもよい。
・ＩＭバージョンの異種混合を可能にし、ノードの機能を判断するために各ＩＭノード１５０のバージョンを認識する。
・ＩＭ機能性全体に影響することなく、個々のＩＭノード１５０がアップグレードまたはパッチ適用可能なように、時間差または「ローリング」アップグレードおよびメンテナンス機能を可能にする。
・新たに定義されたＩＭノード１５０上のサービスを発見する。
・新たなサービスが展開されるときに新たなＩＭノードをＤＴＥＩＭアーキテクチャに追加できるように、分散型のサービス・モデルを使用して徐々にスケーリングすることを可能にする。第１のＩＭノード１５０を、ＤＴＥＩＭアーキテクチャにマイグレートできる。さらに、このためにマイグレーション・ツールが提供される。
・サービス定義およびポリシに関して、各ＩＭノード１５０上のサービスのサブセットを設定する別々のアドミニストレータにより、アドミニストレーションを分散化する。
・すべてのＩＭノード１５０にわたって何らかの共通情報を維持する。
・ＩＭ−ＩＭアダプタを活用して、参加しているＩＭノード１５０に個人オブジェクトを分散させる。
【００１９】
ＤＴＥＩＭトポロジは、独立して管理される疎結合ＩＭノード１５０から成るため、このＤＴＥＩＭトポロジは、個々のＩＭノード１５０のローカルのＩＭオブジェクトが、ＤＴＥＩＭトポロジへの負担とはならずに、ＩＭノード１５０自体において設定および管理されることを可能にする。ＤＴＥＩＭサーバ１１０の焦点は、ＤＴＥＩＭエンジン１２０を使用して、ＤＴＥＩＭアーキテクチャ中でエンド・ユーザ・サービスを提供することである。ＤＴＥＩＭアーキテクチャは、高度の分散化を提供し、その一方でエンド・ユーザは、複数のＩＭノード１５０にわたる分散型サービスの統一ビューを得る。
【００２０】
ＤＴＥＩＭアーキテクチャはさらに、ＩＭノード１５０が種々の個人集団を有することを可能にし、ＤＴＥＩＭアーキテクチャは、複数のＩＭノード１５０にわたるユーザのフットプリント（ｆｏｏｔｐｒｉｎｔ）を記録する（例えば、ユーザが参加するＩＭノード１５０）。
【００２１】
ＤＴＥＩＭアーキテクチャ
ＤＴＥＩＭアーキテクチャは、１つ以上の独立したＩＭメンバ・ノードと対話する「グローバル」ＤＴＥＩＭ管理ノード（ＤＴＥＩＭサーバおよびＤＴＥＩＭディレクトリ・サーバ）から成る。ＤＴＥＩＭ管理ノードは、複数のＩＭノード１５０からのアイデンティティ管理データを、ユーザに提示するために結合し、ユーザからリクエストを受信し、リクエストを、そのリクエストのターゲットを担当する１つ以上のメンバＩＭノード１５０へルーティングする。メンバＩＭノード１５０はそれぞれ、この分散型システムが管理するサービスのサブセットを担当する、完全にクラスタ化されたＩＭノード１５０とすることができる。ＤＴＥＩＭ  ＵＩアプリケーションも、高スループットをもたらしフェイルオーバを提供するためにクラスタ化されることが可能である。ＤＴＥＩＭノード１００は、ＩＭノード情報を管理し、リクエストをルーティングし、結果を結合し、ユーザ・インターフェイスの開発のためのＡＰＩを提示する機能を提供する。特定の実施形態では、ＤＴＥＩＭノード１００は、ローカルのライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）データ・ストアまたはＬＤＡＰディレクトリ・サーバを使用して、設定情報と、エンティティ・オブジェクトのオブジェクト・スタブとを保持し、オブジェクト・スタブは、当該エンティティ・オブジェクトの分散した位置をポイントする。オブジェクト・スタブは、人員（すなわち人員スタブ）、アカウント（すなわちアカウント・スタブ）、サービス（すなわちサービス・スタブ）などに関するとよい。各オブジェクト・スタブは、ＩＭノード１５０に記憶されている完全なエンティティ・オブジェクト（人員、アカウント、サービスなどに関する）をポイントする。
【００２２】
ＩＭノード１５０のうちの１つは、メイン「人員」ノードとして指定される。ＤＴＥＩＭノード１００をバイパスして、このメイン「人員」ノードに、アイデンティティ／人材（ＨＲ：Ｈｕｍａｎ  Ｒｅｓｏｕｒｃｅ）フィードが入力されるとよい。ＩＭ−ＩＭアダプタは、メインのＩＭノード１５０から他のＩＭノード１５０へ、ポリシ設定を用いて個人オブジェクトを分散させるために活用される。すなわち、各ＩＭノード１５０は、メインのＩＭノード１５０からＩＭ−ＩＭアダプタを介してアイデンティティ・フィードを得る。子ＩＭノード１５０はそれぞれ、メインのＩＭノード１５０内の管理対象プラットフォームのように見える。ＩＭポリシおよび自動エンタイトルメント（ｅｎｔｉｔｌｅｍｅｎｔ）が、個人基準に基づき個人オブジェクトを子ＩＭノードに分散させるよう設定されるとよい。特定の実施形態では、ＩＭ−ＩＭアダプタは、標準のアダプタ・フレームワークを使用する。
【００２３】
特定の実施形態では、ＤＴＥＩＭノードは、ＩＭ  ＡＰＩのウェブ・サービス・ベースの抽象化を使用することによって、ＩＭノードと通信する。例えば、ＤＴＥＩＭノードは、ユーザ・リクエストを、ウェブ・サービス・インターフェイス上で適切なＩＭノードへルーティングする。ＤＴＥＩＭ分散は、各ＩＭノードの前方にインストールされたＩＭウェブ・サービス・コネクタを含む。これは、ＩＭノードと通信するときのＩＭ  ＡＰＩおよびウェブ・サービス・バージョン依存をなくし、ライトウェイトで標準の通信の、ハイパーテキスト転送プロトコル（ＨＴＴＰ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ベースのプロトコルを、他のプロトコル（例えば、ＩＭ  ＡＰＩによって使用される、ＪＡＶＡ（Ｒ）リモート・メソッド呼び出し（ＲＭＩ：Ｒｅｍｏｔｅ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ）インターフェイス・オーバ・インターネット・インターＯｒｂプロトコル（ＩＩＯＰ：Ｉｎｔｅｒｎｅｔ  Ｉｎｔｅｒ−Ｏｒｂ  Ｐｒｏｔｏｃｏｌ）（ＲＭＩオーバＩＩＯＰとも呼ばれる））の代わりに提供する。
【００２４】
ＩＭノード上で独立して、またはＤＴＥＩＭノードから開始された動作の結果として生じる個人およびアカウント変更については、ＤＴＥＩＭインフラストラクチャの一部としてＩＭノード上にインストールされているＤＴＥＩＭノーティファイア・モジュール（ｎｏｔｉｆｉｅｒ  ｍｏｄｕｌｅ）を介してＤＴＥＩＭノードに通知が返される。ＤＴＥＩＭノーティファイア・モジュールは、ＩＭノードからＤＴＥＩＭノードへの通信に、ウェブ・サービス・ベースの通信を使用する。
【００２５】
図２は、特定の実施形態によるＤＴＥＩＭアーキテクチャを示す。図２では、ＤＴＥＩＭアーキテクチャのアーキテクチャ上のコンポーネントは、ＤＴＥＩＭレイヤ２００にあるＤＴＥＩＭサーバ１１０およびＤＴＥＩＭディレクトリ・サーバ１４０、ならびにＩＭレイヤ２５０の各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにそれぞれあるＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎから成る。ＤＴＥＩＭサーバ１１０にあるＤＴＥＩＭリスナは、各ＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎからの通知をリッスンする。図２の例では、ＤＴＥＩＭレイヤは、ＤＴＥＩＭサーバ１１０で実行されているＤＴＥＩＭエンジン１２０から成る。特定の実施形態では、ＤＴＥＩＭエンジン１２０は、Ｊ２ＥＥ（Ｒ）アプリケーションであり、ＤＴＥＩＭディレクトリ・サーバ１４０は、ＬＤＡＰデータ・ストアまたはＬＤＡＰディレクトリ・サーバである。ＤＴＥＩＭ  ＬＤＡＰデータ・ストアは、複数のＤＴＥＩＭノードにわたるすべてのサービスおよびアカウントのサービス・オブジェクトおよびアカウント・オブジェクトのオブジェクト・スタブを含む。ＬＤＡＰデータ・ストアはさらに、メインのＩＭノード２６０ａ上の個人オブジェクトをポイントするオブジェクト・スタブを含む。ＤＴＥＩＭ  ＬＤＡＰデータ・ストアは、ルックアップ用のオブジェクト・スタブのステージング・リポジトリである。ＤＴＥＩＭ構成およびＩＭトポロジも、ＬＤＡＰデータ・ストアに記憶される。
【００２６】
ＤＴＥＩＭエンジン１２０は、個人情報を、メインのＩＭノード２６０ａから読み出す（スタブ・リファレンスをたどって）。次に、変更がメインのＩＭノード２６０ａに再び書き込まれ、メインのＩＭノード２６０ａは、その変更を参加しているＩＭノード２６０ｂ．．．２６０ｎに、ＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎを介して分散させる。ＤＴＥＩＭエンジン１２０は、アカウント・スタブ・リファレンスをたどることによって、アカウント・オブジェクトを読み出して更新する。ＤＴＥＩＭエンジン１２０は、他のオブジェクトを、参加しているＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎから並行して読み出す。したがって、オブジェクトを読み出す時間は、単一の任意のＩＭから読み出すのにかかる最も長い時間と同じ長さである。メインのＩＭノード２６０ａは、アイデンティティ・リポジトリ、さらに任意選択でサービスのサブセットをホストすることもできる。アイデンティティ・リポジトリは、個人エンティティのコレクションを記憶する。
【００２７】
ＩＭレイヤ２５０は、１つ以上のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎから成る。ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎは、地理的に離れていてもよい。各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎは、それぞれ、ＩＭサーバ２６２ａ、２６２ｂ、．．．２６２ｎ、ＩＭディレクトリ・サーバ２６４ａ、２６４ｂ、．．．２６４ｎ、ＩＭデータベース２６６ａ、２６６ｂ、．．．２６６ｎ、ＩＭウェブ・サービス２６８ａ、２６８ｂ．．．２６８ｎ、およびエンド・ポイント２７０ａ、２７０ｂ、．．．２７０ｎを含む。
【００２８】
ＩＭノードの１つであるＩＭノード２６０ａは、メインのＩＭノードとして指定され、ＩＭデータベース２６６ａ（または他のデータ・ストア）においてすべてのアイデンティティを維持する。アイデンティティ・フィードは、メインのＩＭノード２６０ａ上でアイデンティティ・フィード２１０を介して実行される。
【００２９】
他のＩＭノード２６０ｂ．．．２６０ｎはそれぞれ、ＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎを含む。
【００３０】
ＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎは、ワークフロー・プロキシ・モジュールであり、それぞれ各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにインストールされ、ＤＴＥＩＭエンジン１２０に、個人およびアカウント・オブジェクト作成または削除について通知する。この通知は、ＩＭウェブ・サービス２６８ａ、２６８ｂ、．．．２６８ｎを介して送信されてもよい。
【００３１】
各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎは、ＤＴＥＩＭエンジン１２０に、アカウントおよび個人変更を、ウェブ・サービス・インターフェイスを使用して、ノーティファイア・モジュールを介して通知する。例えば、エンティティ・オブジェクトの追加および削除が通知される。特定の実施形態では、一時停止／回復以外の属性変更は通知されない。
【００３２】
ＩＭウェブ・サービスは、ＩＭ  ＡＰＩのウェブ・サービス・ラッパ（ｗｅｂ  ｓｅｒｖｉｃｅｓ  ｗｒａｐｐｅｒ）と表現することもできる。ＤＴＥＩＭアーキテクチャは、ＩＭウェブ・サービス２６８ａ、２６８ｂ、．．．２６８ｎのＩＭ  ＡＰＩウェブ・サービス・ラッパを活用してＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎと通信し、標準のＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎを活用して個人情報をＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに分散させる。
【００３３】
図２では、ＤＴＥＩＭエンジン１２０は、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎを管理する。ノード−１は、メインのＩＭノード２６０ａであり、サービスのサブセットを管理する。ノード−２およびノード−ｎは、その個別のサービスのサブセットを管理するＩＭノード２６０ｂ、２６０ｎである。
【００３４】
各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎは、ＩＭプラットフォームに対するＤＴＥＩＭエンジン１２０による呼び出しをリッスンするＩＭウェブ・サービス２６８ａ、２６８ｂ、．．．２６８ｎを有する。特定の実施形態では、ＤＴＥＩＭエンジン１２０は、標準のハイパーテキスト転送プロトコル・セキュア（ＨＴＴＰ／Ｓ：ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｅ）またはシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）ｏｖｅｒ  ＨＴＴＰＳによってＩＭウェブ・サービス２６８ａ、２６８ｂ、．．．２６８ｎと通信する。ＩＭウェブ・サービス２６８ａ、２６８ｂ、．．．２６８ｎは、内部でＩＭ  ＡＰＩを使用して呼び出しを処理し、ウェブ・サービス応答を返送するとよい。非ＪＡＶＡ（Ｒ）クライアント（例えば、．ｎｅｔクライアント）も、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎと通信できる。ＩＭ  ＡＰＩの複雑さは、ウェブ・サービス機能ＡＰＩによって抽象化される。
【００３５】
マスタ−子またはピア・ツー・ピア
ＤＴＥＩＭトポロジは、マスタ−子トポロジまたはピア・ツー・ピア・トポロジのいずれかとして構成可能である。
【００３６】
ピア・ツー・ピア・トポロジでは、各ＩＭノードが、信頼できるソースからの独立したアイデンティティ・フィードを有する。異なるＩＭノードの共通の個人は、同じ固有の識別属性を１つ以上有する。
【００３７】
図２は、マスタ−子トポロジを示す。マスタ−子トポロジでは、ＩＭノードのうちの１つであるＩＭノード２６０ａが、メイン（すなわち、マスタ）のＩＭノードとして指定され、エンタープライズ内のすべての人員が、アイデンティティ・フィード２１０（例えば、信頼できるソースからの）を介してメインのＩＭノードにおいてポピュレートされる。特定の実施形態では、メインのＩＭノード２６０ａ上の人員は、メインのＩＭノード２６０ａにおける役割（ｒｏｌｅ）割り当てまたは手動リクエストによって、ＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎを介して他のＩＭノード２６０ｂ．．．２６０ｎにプロビジョニングされる。
【００３８】
マスタ−子トポロジでは、ユーザが、同じ認証情報を用いてＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎのいずれかにおいて認証されることが可能なように、各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎが共通の認証プロバイダを使用すると、ＤＴＥＩＭエンジン１２０は想定する。このタイプの認証は、典型的には、エンタープライズ・ディレクトリなどの外部の認証リポジトリを使用して実現される。特定の代わりの実施形態では、ＤＴＥＩＭエンジン１２０およびＩＭノードが、シングル・サイン・オン（ＳＳＯ：Ｓｉｎｇｌｅ  Ｓｉｇｎ  Ｏｎ）機能を提供するアクセス制御製品を活用し、認証がアクセス制御製品に委任されてもよい。
【００３９】
エンド・ユーザは、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに対して使用し得るのと同じ認証を用いて、ＤＴＥＩＭエンジン１２０にログオンする（例えば、シンプル認証、シングル・サイン・オン（ＳＳＯ）、クライアント証明書による認証など）。ＤＴＥＩＭエンジン１２０は、メインのＩＭノード２６０ａに対し認証を行う（またはセッションを確立する）。特定の実施形態では、エンド・ユーザは、メインのＩＭノード２６０ａ上およびユーザがアカウントを管理したいその他任意のＩＭノード２６０ｂ、．．．２６０ｎ上にＩＭアカウントを有する。
【００４０】
個人修正
エンド・ユーザによる個人修正リクエストは、ＤＴＥＩＭエンジン１２０によって、メインのＩＭノード２６０ａから処理される。そこでリクエストが実行された後、ＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎフレームワークが、影響を受けるＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに変更を分散させる（例えば、スプレーする）。個人がＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに追加されるか、またはそこから消去されると、そのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上のＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎがＤＴＥＩＭエンジン１２０に通知し、ＤＴＥＩＭエンジン１２０は、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上の該個人のオブジェクトを参照するオブジェクト・スタブを、ＤＴＥＩＭディレクトリ・サーバ１４０に追加するか、またはそこから消去する。
【００４１】
特定の実施形態では、特定のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上でのみ個人修正がある。そのような実施形態では、ＩＭ−ＩＭアダプタ２７２ｂ．．．２７２ｎを使用して、各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎが、メインのＩＭノード２６０ａ上のサービスとして表される。ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上のユーザの個人オブジェクトは、アイデンティティ・アカウントとして表される。ＤＴＥＩＭエンジン１２０を使用して、ユーザは、任意のＩＭノードからのアイデンティティ・アカウントを選ぶことによってこのアカウントを管理できる。
【００４２】
アカウントおよびパスワード管理
ＤＴＥＩＭエンジン１２０は、個人によって所有されているすべてのアカウントのオブジェクト・スタブを維持する。ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上のＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎは、アカウント・オブジェクト作成および削除通知をＤＴＥＩＭエンジン１２０に送信する。ＤＴＥＩＭエンジン１２０は、一度にユーザが、すべてのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上のアカウント、または選択的に１つのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上のアカウントを管理することを許可する。
【００４３】
１つ以上のサービスに関するプロビジョニング・リクエストがＤＴＥＩＭエンジン１２０に提出されると、ＤＴＥＩＭエンジン１２０は、そのサービスを管理するＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎを判断し、このアカウント・リクエストを、このサービスを担当するＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎへルーティングする。特定の実施形態では、サービスは、「エンド・ポイント」（すなわち、ＩＭノードによって管理されるシステム）を表すものとして表現することもできる。そこでリクエストが実行された後、ＤＴＥＩＭノーティファイア・モジュール２３０ａ、２３０ｂ、．．．２３０ｎは、通知をＤＴＥＩＭエンジン１２０に送信し、ＤＴＥＩＭエンジン１２０は、アカウント・スタブをＤＴＥＩＭディレクトリ・サーバ１４０内に作成する。特定の実施形態では、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ内のアカウント・オブジェクトに対する単純な属性変更は、ＤＴＥＩＭディレクトリ・サーバ１４０上のＤＴＥＩＭオブジェクト・スタブに返送されず、そのため、それらがＤＴＥＩＭ−ＩＭトラフィックを増大させることはない。
【００４４】
ユーザが既存のアカウントを閲覧または修正したい場合、ＤＴＥＩＭエンジン１２０は、アカウント・スタブを展開して（ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにアクセスすることにより）、アカウント情報をエンド・ユーザに対してレンダリングする。
【００４５】
ＤＴＥＩＭエンジン１２０は、パスワード変更リクエストを、ターゲットＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに並行して分散させる（例えば、スプレーする）。ユーザにとって便利なように、ＤＴＥＩＭエンジン１２０は、パスワード変更リクエスト内のターゲット・アカウントが複数のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上にあれば、パスワード・ルールをＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにわたって結合する。
【００４６】
アクセス情報は、参加しているＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎから並行して読み出される。アクセスは、読み出し、プロビジョニング、または消去されることが可能である。
【００４７】
リクエストおよび割り当て管理
ＤＴＥＩＭエンジン１２０は、ユーザが参加しているすべてのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎから並行してリクエスト情報または割り当て情報（ａｓｓｉｇｎｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ）を得る。特定の実施形態では、ＤＴＥＩＭエンジン１２０は、ユーザが参加していないＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎには接続しない。複数のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎからのリクエストまたは割り当てが並行して読み出されるため、読み出すための時間は、任意の１つのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎから読み出すのにかかる最も長い時間と同じだけの長さである（プラス小さなスレッド管理オーバーヘッド）。さらに、割り当て項目は、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにわたって単一のアクションでまとめて実行されてもよい。割り当て項目は、参加者に関する「ｔｏ  ｄｏ」項目と表現することもできる（例えば、別のユーザに関するプロビジョニング・リクエストの未処理の承認／拒否項目、プロビジョニング・リクエストについてより多くの情報を提供する未処理のリクエスト、など）。
【００４８】
ＩＭノード・アドミニストレーション
特定の実施形態では、ＤＴＥＩＭアーキテクチャは、ＩＭノードの非常に緩やかな結合を可能にするため、ＤＴＥＩＭレイヤ２００では、何らのポリシ、役割、または他の設定項目も、定義または設定されない。ＩＭアドミニストレータ（例えば、システム・アドミニストレータまたは他のユーザ）は、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎを、アイデンティティ管理の現在の機能を使用して設定する。特定の実施形態では、設定ステップの多くは、任意のＩＭノードに対して実行され得るように実行されるとよい。この設定には、以下が含まれる：
・パスワード・チャレンジ設定。これは、マスタ−子トポロジのメインのＩＭノード２６０ａ上で設定される。
・個人ワークフロー・カスタマイズは、メインのＩＭノード２６０ａ上で設定される。個人ワークフロー・カスタマイズは、他のＩＭノード２６０ｂ．．．２６０ｎのローカルのオブジェクトにアクセスするカスタム動作ワークフローが当該ＩＭノード２６０ｂ．．．２６０ｎ上で必要であれば、任意選択で当該ＩＭノード２６０ｂ．．．２６０ｎ上で設定可能である。
・サービス・プロファイルは、それに関するサービスをホストするＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上にインストールされる。
・プロビジョニング・ポリシは、ターゲット・サービスをホストするＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で定義される。特定の実施形態では、プロビジョニング・ポリシは、当該ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎでホストされていないサービスはターゲットにしない。特定の実施形態では、別々のプロビジョニング・ポリシが別々のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で設定されてもよい。特定の実施形態では、サービス選択ポリシの複数のターゲットが、同じＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上にある。
・ＩＭアカウント（すなわち、システム・ユーザ・オブジェクト）が、メインのＩＭノード２６０ａ、およびユーザが管理する必要があるすべてのＩＭノード２６０ｂ．．．２６０ｎ上にプロビジョニングされる。
・エンタイトルメント・ワークフローは、そのエンタイトルメントをターゲットとするプロビジョニング・ポリシを保持するＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で定義される。エンタイトルメントは、エンド・ポイント上にｕｓｅｒｉｄを有するための、個人の権限と表現することもできる。エンタイトルメント・ワークフローは、個人がエンド・ポイント上でｕｓｅｒｉｄを得る権限を与えられている場合に、その個人がそのエンド・ポイント上でｕｓｅｒｉｄの作成または修正をリクエストすると実行される。
・パスワードおよびアイデンティティ・ポリシは、ターゲット・サービスをホストするＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で定義される。グローバル（すべてのサービス）パスワードまたはアイデンティティ・ポリシが必要であれば、グローバル・パスワードが、メインのＩＭノード２６０ａ上、さらに他のＩＭノード２６０ｂ．．．２６０ｎ上で定義される。ＤＴＥＩＭアドミニストレーション機能が、グローバル・パスワードおよびアイデンティティ・ポリシを、すべてのＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに対して複製する。
・パスワード編集およびパスワード同期機能は、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにわたって全く同じに定義されるが、これは、ＤＴＥＩＭエンジン１２０が、プロビジョニング・リクエストをＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎに送る前にそれらを必要とするためである。
・パスワード・インターセプト・エージェントが、ＤＴＥＩＭレイヤ２００にてサポートされてもよい。この機能性は、パスワード同期のために有用である。
【００４９】
ＤＴＥＩＭアーキテクチャのさらなる詳細
ＤＴＥＩＭエンジン１２０は、エンド・ユーザ機能性を提供する。特定の実施形態では、分散化のために、アドミニストレーション上のタスクおよび設定タスクは、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で実行される。特定の実施形態では、ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ内で、通知のポスト・オフィス・コンソリデーション（ｐｏｓｔ  ｏｆｆｉｃｅ  ｃｏｎｓｏｌｉｄａｔｉｏｎ）が行われる。ポスト・オフィスは、同じユーザへの頻繁な複数の電子メール通知を１つに結合して電子メール・トラフィックを削減する、電子メール通知コンソリデーション機能と表現することもできる。ポスト・オフィス・コンソリデーションは、ＩＭノードの機能であってもよく、ＤＴＥＩＭエンジン１２０によって直接影響されない。特定の実施形態では、プロビジョニング・ポリシは、異なるＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎのサービスをターゲットとせず、各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎにおいて別々のプロビジョニング・ポリシが設定される。
【００５０】
特定の実施形態では、すべてのサービス・インスタンスが同じＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎになければ、パスワードおよびアイデンティティ・ポリシは、サービス・プロファイルをターゲットとしない。特定の代わりの実施形態では、すべてのサービス・インスタンスが同じＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎになく、相反するポリシに関する混乱を避けるためにポリシが各ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で同一であれば、パスワードおよびアイデンティティ・ポリシはサービス・プロファイルをターゲットとする。
【００５１】
特定の実施形態では、アカウント関係を含む個人アクセス制御項目（ＡＣＩｓ：Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｉｔｅｍｓ）が、そのアカウントに関するサービスをホストするＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上でセットアップされる。ＡＣＩは、ＩＭデータに誰がどの程度アクセスできるかを制御する。データが、同じノード上にない複数のアカウントから参照される一部の実施形態では、個人ＡＣＩフィルタ・オプションは使用されない。
【００５２】
特定の実施形態では、カスタム・ワークフローは、当該ＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上でホストされていないサービスを参照するための動作アクティビティを使用しない。カスタム・ワークフローは、サービスおよび関係のあるオブジェクトをホストする１つ以上のＩＭノード２６０ａ、２６０ｂ、．．．２６０ｎ上で作成される。特定の実施形態では、サービスは、同じノード内の他のサービスを必須として列挙してもよい。
【００５３】
ＤＴＥＩＭリファレンス・ユーザ・インターフェイス（ＵＩ）
ＤＴＥＩＭリファレンスＵＩは、エンド・ユーザＵＩである。ＤＴＥＩＭリファレンスＵＩは、セルフ・サービス・ユーザ機能を提供する（すなわち、アドミニストレーション・タスクがローカルＩＭノード上に分散化される）。ＤＴＥＩＭリファレンスＵＩは、ＤＴＥＩＭ機能性を示すためにＤＴＥＩＭエンジン１２０とともに提供される。特定の実施形態では、ＤＴＥＩＭリファレンスＵＩは、ＤＴＥＩＭ  ＡＰＩのリファレンス実装である。ＤＴＥＩＭリファレンスＵＩは、ＤＴＥＩＭ  ＡＰＩの利用法を示す。様々な実施形態において、他のＵＩが、ＤＴＥＩＭ  ＡＰＩに対して書かれることができ、または、ＤＴＥＩＭリファレンスＵＩが、組織の要求に従ってＵＩを供給するための基礎として使用されることができる。
【００５４】
特定の実施形態では、ＤＴＥＩＭリファレンスＵＩは、ビューの処理にＪＡＶＡ（Ｒ）サーバ・フェイシズ（ＪＳＦ：ＪＡＶＡ（Ｒ）Ｓｅｒｖｅｒ  Ｆａｃｅｓ）を使用し、ＩＭノードとの通信にＤＴＥＩＭ  ＡＰＩを使用する。ＤＴＥＩＭリファレンスＵＩは、ＤＴＥＩＭリファレンスＵＩをカスタマイズするのに使用可能なソース・コードおよびＪＡＶＡ（Ｒ）ドキュメンテーションを含む。
【００５５】
ＤＴＥＩＭリファレンスＵＩの機能性は、エンド・ユーザがＩＭ  ＵＩ内で見ることになる機能性に基づく。ＤＴＥＩＭエンジン１２０は、エンド・ユーザ機能を対象としているため、ＤＴＥＩＭリファレンスＵＩは、アドミニストレーション上の機能は含まない。ＤＴＥＩＭアーキテクチャでは、アドミニストレーション上の機能は分散化され、アドミニストレータによってＩＭノード上で直接実行される。
【００５６】
インストール後、ＤＴＥＩＭリファレンスＵＩは、特定の位置または統一資源位置指定子（ＵＲＬ：Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）（例えばｈｔｔｐ：／／ｈｏｓｔＮａｍｅ：ｐｏｒｔＮｕｍｂｅｒ／ＤＴＥＩＭ／ｉｎｄｅｘ．ｈｔｍｌ）へとナビゲートすることによってアクセス可能である。
【００５７】
以下のスクリーン・ショットは、ＤＴＥＩＭリファレンスＵＩスクリーンの一部を示す。
【００５８】
図３は、特定の実施形態による例示としてのＤＴＥＩＭログイン・スクリーン３００を示す。ログイン機能は、メインのＩＭノードに対するユーザ認証を行う。パスワード・チャレンジも、メインのＩＭノードに対して認証が行われる。認証は、例えば、シンプル認証、シングル・サイン・オン（ＳＳＯ）、クライアント証明書による認証などを使用してもよい。
【００５９】
図４は、特定の実施形態による、ＵＩスクリーン４００内の例示としてのＤＴＥＩＭホーム・ページを示す。ＤＴＥＩＭホーム・ページは、ユーザのＩＭアクティビティおよびアカウントの概要を示す。ログインしたユーザのフットプリントが示されている。特定の実施形態では、ユーザは１つ以上のＩＭノードに存在してもよい。ＤＴＥＩＭホーム・ページは、アカウントおよび未処理の項目を示す。
【００６０】
図５は、特定の実施形態による、ＵＩスクリーン５００内の例示としてのＤＴＥＩＭアドミニストレーション・ページを示す。ＤＴＥＩＭアドミニストレーション・ページは、分散型トポロジに参加しているすべてのＩＭノードを列挙する。ＩＭノードは、非アクティブにセットされることが可能であり、ＤＴＥＩＭエンジン１２０は、そのＩＭノードをＩＭ動作から除外するか、またはそのＩＭノードが再アクティブ化されるまで動作を遅延させる。ＤＴＥＩＭアドミニストレーション・ページは、ノードのリストの設定を可能にする。１つ以上のノードが、メンテナンスのために非アクティブ化され得る（例えば、ｒｅｄノードは非アクティブであり、そのｒｅｄノードの「テスト」ボタンは選択できない）。
【００６１】
図６は、特定の実施形態による、ＵＩスクリーン６００内の「グローバルＩＭからトポロジをインポート」機能の選択を示す。「グローバルＩＭからトポロジをインポート」機能は、ＤＴＥＩＭトポロジ全体をメインのＩＭノードから自動的にインポートする。（ＤＴＥＩＭは、ＩＭ−ＩＭアダプタ・プロファイルのサービス・インスタンスを使用して、それらをＤＴＥＩＭ内のＩＭノードとしてインポートする）。ノード問い合わせ機能（Ｉｎｔｅｒｒｏｇａｔｅ  Ｎｏｄｅ  ｆｕｎｃｔｉｏｎ）は、ノードのＩＭサービス、ならびにＩＭバージョンおよびフィックスパック・レベルを問い合わせる。サービスのオブジェクト・スタブは、ＤＴＥＩＭ  ＬＤＡＰデータ・ストアに記憶されている。ＩＭバージョン・レベルは、ノード上での実行が可能である後の機能を決定する。
【００６２】
図７は、特定の実施形態による、ＵＩスクリーン７００内のノード・サービス閲覧タブの選択を示す。ノード・サービス閲覧タブは、ＩＭノードのいずれかのサービスを示す（ＩＭノード問い合わせ機能を介して各ＩＭノードに問い合わせることにより、ＤＴＥＩＭエンジン１２０により認識されている）。ノード・サービス閲覧タブは、ＩＭノード上で利用可能なサービスを示す。ＤＴＥＩＭエンジン１２０は、ローカル・データ・ストアを有し、これをＤＴＥＩＭエンジン１２０が、ＩＭノード問い合わせ動作中にＩＭノードのサービスによりポピュレートする。
【００６３】
図８は、特定の実施形態による、ＵＩスクリーン８００内のＤＴＥＩＭアドミン・メニューおよびＩＭノード追加タブの選択を示す。一部の図面では、選択されているオプションが点線で示されている（例えば、図８のＤＴＥＩＭアドミン）。ＩＭノード追加タブにより、新たなＩＭノードをＤＴＥＩＭ構成に手動で追加できる。特定の実施形態では、ＩＭノードがＤＴＥＩＭアーキテクチャに追加される前に、ＩＭソフトウェアがＩＭノード上にインストールされる。新たなＩＭノードの追加は、ＤＴＥＩＭノード・アーティファクト（すなわち、ノーティファイア・モジュールおよびＩＭ−ＩＭアダプタ）のインストールを伴うこともある。
【００６４】
図９は、特定の実施形態による、ＵＩスクリーン９００内のパーソナル情報管理メニューおよびパーソナル情報タブの選択を示す。パーソナル情報管理メニューは、メインのＩＭノードから個人情報を読み出す。ＤＴＥＩＭエンジン１２０は、このＩＭ  ＵＩに似た個人情報を表示する。ＩＭにおける個人フォーム変更は、リアルタイムでＤＴＥＩＭエンジン１２０によって追跡される。パーソナル情報タブは、ＩＭフォーム定義を使用してレンダリングされてもよい。
【００６５】
図１０は、特定の実施形態による、ＵＩスクリーン１０００内のアカウント管理メニューの選択を示す。アカウント管理スクリーンは、すべてのＩＭノードにわたるすべてのアカウントを結合し、それらをエンド・ユーザに示す。ユーザが、ダウンしている（非アクティブ）ＩＭノード上にアカウントを保持する場合、そのアカウントは列挙されるが、ＩＭ動作からは除外されるか、または遅延させられる。アカウントは、１つ以上のＩＭノードから選択されてもよい。
【００６６】
図１１は、特定の実施形態による、ＵＩスクリーン１１００内の新アカウント追加メニューの選択を示す。ＤＴＥＩＭエンジン１２０は、ユーザがアカウントをリクエストできる、権限を与えられているサービスすべてを列挙する。権限を与えられているサービスのリストは、ユーザがフットプリントを有するすべてのＩＭノードから結合される。ＤＴＥＩＭエンジン１２０はさらに、サービスが存在するノードと、ノードのＩＭバージョンとを列挙する。特定の実施形態では、サービスは、ＷＩＮＤＯＷＳ（Ｒ）サービスまたはＬＩＮＵＸ（Ｒ）サービスとしてもよい。
【００６７】
図１２は、特定の実施形態による、ＵＩスクリーン１２００内のアクセス管理メニューの選択を示す。アクセス管理機能は、ユーザによって保持されているアクセスを示す。リストは、ＩＭノードから読み出され得る。これは、新たなアクセスのプロビジョニングをサポートする。アクセスは、エンド・ポイント上の既存のｕｓｅｒｉｄに加えて、より粒度の細かいアクセス・レベルの論理的プロビジョニングを意味するＩＭ用語と表現することもできる。
【００６８】
図１３は、特定の実施形態による、ＵＩスクリーン１３００内のパスワード管理メニューの選択を示す。パスワード管理機能により、ユーザは、１つ以上のアカウントに対しパスワードをセットできる。ＤＴＥＩＭエンジン１２０は、パスワード・ルールを各ＩＭノードにわたって結合し、パスワードの妥当性を確保する。複数のＩＭノードにわたるアカウントに対してユーザがパスワード変更を提出すると、ＤＴＥＩＭエンジン１２０は、リクエストを、ＩＭノード毎にサブ・リクエストに分解し、別々のＩＭノードに対するパスワード変更動作を提出する。さらに、ＤＴＥＩＭエンジン１２０は、この複数のＩＭノードにわたってパスワード・ルールをマージしてもよい。
【００６９】
図１４は、特定の実施形態による、ＵＩスクリーン１４００内のリクエスト管理ページを示す。リクエスト管理ページは、完了した、または未処理のリクエストを読み出すために使用され得、未処理のリクエストは、複数のＩＭノードにわたって中断されることもできる。
【００７０】
図１５は、特定の実施形態による、ＵＩスクリーン１５００内のＴｏ  Ｄｏ項目管理ページを示す。Ｔｏ  Ｄｏ項目管理ページは、個々の項目、ならびにグループ化された項目を提供し、複数のＩＭノードにわたる一括承認および拒否を提供する。ＤＴＥＩＭエンジン１２０は、ＩＭノード毎に承認および拒否動作を分解し、それらを別々のＩＭノードに並行して提出する。
【００７１】
図１６は、特定の実施形態による、ＵＩスクリーン１６００内のグループ化された再認証リクエストのレビュー・ページを示す。グループ化された再認証リクエストのレビュー・ページは、一括承認／拒否の例を提供している。
【００７２】
ＤＴＥＩＭ  ＡＰＩ
ＤＴＥＩＭエンジン１２０は、ＤＴＥＩＭエンジン１２０と通信するためにカスタム・ユーザ・インターフェイスまたはＪａｖａクライアント・アプリケーションによる使用が可能なＡＰＩを提供する。ＤＴＥＩＭリファレンスＵＩは、ＤＴＥＩＭ  ＡＰＩを使用する外部アプリケーションの例である。
【００７３】
ＤＴＥＩＭ  ＡＰＩは、ＪＡＶＡ（Ｒ）ベースとしてもよい。ＤＴＥＩＭ  ＡＰＩは、トポロジ透過ＡＰＩを提供する。ＤＴＥＩＭ  ＡＰＩを用いると、クライアントは、ＩＭノードの分散を意識する必要がない。ＤＴＥＩＭ  ＡＰＩは、セルフ・サービス機能を提供する。ＤＴＥＩＭ  ＡＰＩは、ＤＴＥＩＭエンジン１２０と通信するために、カスタムＵＩまたはＪＡＶＡ（Ｒ）クライアント・アプリケーションによって使用可能である。
【００７４】
ＤＴＥＩＭデータ・サービスＡＰＩ
ＤＴＥＩＭデータ・サービスＡＰＩは、ＤＴＥＩＭ  ＬＤＡＰデータ・ストア内のＤＴＥＩＭデータ・オブジェクトを表し、エンティティおよび検索動作を提供する。
【００７５】
ＤＴＥＩＭプロバイダＡＰＩ
ＤＴＥＩＭプロバイダＡＰＩは、ＤＴＥＩＭ動作へのアクセスを提供する。ＤＴＥＩＭプロバイダＡＰＩは、エンド・ユーザ機能性の提供に限られる。特定の実施形態では、ＤＴＥＩＭプロバイダＡＰＩは、アドミニストレーション上の機能性および設定機能性は提供しない。特定の実施形態では、ＤＴＥＩＭプロバイダＡＰＩは、以下のプロバイダから成る：
・アカウント・サービス・プロバイダ−アカウントおよびアクセスに関係するＡＰＩを提供する。
・認証プロバイダ−認証およびセッションに関係するＡＰＩを提供する。
・フォーム・プロバイダ−フォームを得て構文解析するためのＡＰＩを提供する。
・Ｏｒｇ（ｏｒｇａｎｉｚａｔｉｏｎａｌ：組織）コンテナ・サービス・プロバイダ−組織コンテナをトラバースするＡＰＩ。
・個人サービス・プロバイダ−ＩＭ個人に関係するＡＰＩを提供。
・リクエスト・サービス・プロバイダ−エンド・ユーザの範囲のリクエストに関係するＡＰＩを提供する。
・役割サービス・プロバイダ−エンド・ユーザの範囲の組織役割に関係するＡＰＩを提供する。
・サービス・サービス・プロバイダ−ＩＭサービスに関係するＡＰＩを提供する。
・システム・ユーザ・プロバイダ−システム・ユーザ（ＩＭサービス・アカウント）に関係するＡＰＩを提供する。
・ＴｏＤｏＰｒｏｖｉｄｅｒ−割り当ておよびＩＭ「ｔｏ  ｄｏ」に関係するＡＰＩを提供する。
【００７６】
ＤＴＥＩＭノードはさらに、ＤＴＥＩＭアドミニストレーションおよび認証のためにエンタープライズＪＡＶＡ（Ｒ）ビーン（ＥＪＢ：Ｅｎｔｅｒｐｒｉｓｅ  ＪＡＶＡ（Ｒ）Ｂｅａｎ）レイヤ・インターフェイスを提供する：
・認証マネージャ−認証に関係する機能を管理する（認証プロバイダのＥＪＢラッパ）。
・スタブ・マネージャ−ＤＴＥＩＭディレクトリ・サーバ内のスタブを管理する。
【００７７】
ＤＴＥＩＭ  ＡＰＩの使用例
本願明細書の例は、ＤＴＥＩＭ  ＡＰＩの説明に役立つものであり、ＤＴＥＩＭ  ＡＰＩ全体の例の包括的なリストではない。
【００７８】
図１７は、特定の実施形態による、認証のためにＤＴＥＩＭ  ＡＰＩを使用する例であるコード・スニペット１７００を示す。
【００７９】
図１８は、特定の実施形態による、ＤＴＥＩＭ  ＬＤＡＰデータ・ストアからユーザのアカウント・スタブおよびアカウント・データを読み出すためにＤＴＥＩＭデータ・サービスＡＰＩを使用する例であるコード・スニペット１８００を示す。これらのアカウント・スタブは、種々のＩＭノードにわたってアカウント・データを備えるアカウントをポイントする。
【００８０】
図１９は、特定の実施形態による、アカウント・スタブを読み出すためにＤＴＥＩＭデータ・サービスＡＰＩを使用する例であるコード・スニペット１９００を示す。
【００８１】
図２０は、特定の実施形態による、アカウントの更新または作成の例であるコード・スニペット２０００を示す。
【００８２】
図２１は、特定の実施形態による、アカウントのユーザの、権限を与えられたサービスを読み出す例であるコード・スニペット２１００を示す。このＤＴＥＩＭ  ＡＰＩ呼び出しは、ユーザがアカウントを得る資格を有するサービス（複数のＩＭノードにわたる）の統合されたリストをもたらす。
【００８３】
図２２は、特定の実施形態による、個人のポピュレートされたフォームを得る例であるコード・スニペット２２００を示す。ＤＴＥＩＭエンジン１２０は、個人に関してポピュレートされたフォームを含むＤＴＥＩＭＦｏｒｍオブジェクトを提供する。ＤＴＥＩＭＦｏｒｍオブジェクトは、ＤＴＥＩＭＦｏｒｍＴａｂオブジェクトを含み、そのそれぞれが、ＤＴＥＩＭＦｏｒｍＥｌｅｍｅｎｔオブジェクトを含む。各ＤＴＥＩＭＦｏｒｍＥｌｅｍｅｎｔは、属性名、値、およびフォーマット情報を含む。ＤＴＥＩＭエンジン１２０は、フォーム構成要素内の制御をサポートする（検索制御、検索一致、ドロップ・ダウン・リストなど）。これらの特性は、Ｊ２ＥＥビュー技術を使用するフォームのレンダリングを制御するために使用可能である。ＤＴＥＩＭリファレンスＵＩは、ＪＡＶＡ（Ｒ）サーバ・フェイシズ（ＪＳＦ）およびフェイスレットを使用して、メタ・フォーム構成要素タグを定義し、ＤＴＥＩＭＦｏｒｍＥｌｅｍｅｎｔオブジェクトをレンダリングのために渡す。
【００８４】
図２３は、特定の実施形態による、パスワード・ルールを得る例であるコード・スニペット２３００を示す。ＤＴＥＩＭエンジン１２０は、１つ以上のアカウントのパスワード・ルールを得るためのＡＰＩを提供する。これらのアカウントが種々のＩＭノード上の複数のサービス上でホストされていれば、ＤＴＥＩＭエンジン１２０は、パスワード・ルールを返す前に、各ノードにわたってルールをマージする。
【００８５】
図２４は、特定の実施形態による、パスワード変更の例であるコード・スニペット２４００を示す。ＤＴＥＩＭエンジン１２０は、パスワード変更リクエストを提出する前に新たなパスワードが妥当かどうか確認するためのＡＰＩを提供する。これは、複数のサービス／ノードにわたってパスワードを変更するときに役立ち、無効なパスワードによるリクエストの失敗を防止する。パスワード検証中に生成されたオブジェクトは、ｎｏｄｅＡｗａｒｅＡｃｃｏｕｎｔＭＯｓコレクションにおけるパスワード変更中に再利用される。
【００８６】
図２５は、特定の実施形態による、参加しているＩＭノードから「ｔｏ  ｄｏ」項目のリストを得る例であるコード・スニペット２５００を示す。
【００８７】
ＤＴＥＩＭ  ＬＤＡＰデータ・ストア
図２６は、特定の実施形態によるＤＴＥＩＭ  ＬＤＡＰデータ・ストア２６００を示す。
【００８８】
図２７、２８、および２９は、特定の実施形態によるスキーマ２７００、２７１０、２７２０を示す。
【００８９】
図３０は、特定の実施形態によるユーザ・インターフェイス２８００内のアカウント・スタブの例を示す。ｎｏｄｅｇｌｏｂａｌｉｄ属性は、もとのアカウント・オブジェクトの相対識別名（ＲＤＮ：Ｒｅｌａｔｉｖｅ  Ｄｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅ）であり、オブジェクトのもとのＲＤＮを使用し、そのＲＤＮに、Ａｔ＜ｎｏｄｅＩｄ＞のサフィックスを付けることによって、一意性を確保するためにＤＴＥＩＭエンジン１２０によって生成される。アカウント・スタブは、ｕｓｅｒｉｄ（すなわちＵＩＤ）以外には何らのアカウント特有属性も含まない。特定の実施形態では、ＤＴＥＩＭエンジン１２０は、メインのＩＭノード上のＩＭアカウントのみを追跡するため、ＩＭサービス・アカウントはノード・サフィックスを含まない。
【００９０】
図３１は、特定の実施形態によるユーザ・インターフェイス２９００内の個人スタブの例を示す。ｎｏｄｅｇｌｏｂａｌｉｄ属性は、個人オブジェクトのＲＤＮであり、オブジェクトのもとのＲＤＮを使用し、そのＲＤＮに、Ａｔ＜ｎｏｄｅＩｄ＞のサフィックスを付けることによって、一意性を確保するためにＤＴＥＩＭエンジン１２０によって生成される。
【００９１】
特定の実施形態では、ウェブ・サービスは、ＩＭノードと同一場所に配置されたウェブ・アプリケーションとして実行される。ウェブ・サービスは、単純なクライアントおよびデータ・モデルを使用するとよい。ウェブ・サービス記述言語（ＷＳＤＬ：Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）ファイルを、ウェブ・サービス・クライアントおよびデータ・モデルを生成するために使用可能である。ＷＳＤＬは、非ＪＡＶＡ（Ｒ）クライアントを生成するために使用されてもよい。さらに、特定の実施形態では、事前生成されたＪＡＶＡ（Ｒ）クライアントが提供される。ウェブ・サービスは、セッション識別子（ＩＤ：ｉｄｅｎｔｉｆｉｅｒ）を確立することによってスレッド会話を提供する。
【００９２】
図３２は、特定の実施形態によるウェブ・サービス・アーキテクチャ３０００を示す。特定の実施形態では、コンソール・アプリケーションは、ＪＡＶＡ（Ｒ）コンソール・アプリケーションである。特定の実施形態では、アプリケーション・サーバは、ＷＥＢＳＰＨＥＲＥ（Ｒ）アプリケーション・サーバである。（ＷＥＢＳＰＨＥＲＥは、米国、その他の国々、または両方における、インターナショナル・ビジネス・マシーンズ（ＩＢＭ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ）コーポレーションの商標である）。
【００９３】
特定の実施形態では、ウェブ・サービス・スイートは、機能的に独立したサービスから成り、単一のプロキシ・ファサードを備える：
・セッション・サービス
・アカウント・サービス
・フォーム・サービス
・組織コンテナ・サービス
・パスワード・サービス
・リクエスト・サービス
・役割サービス
・サービス・サービス（すなわち、ＩＭサービスを制御するウェブ・サービス）。
・データ検索サービス
・システム・ユーザ・サービス
・Ｔｏ  Ｄｏサービス
・アクセス・サービス
・プロビジョニング・ポリシ・サービス
・ＩＭサービス（結合された単一のプロキシ・サービス）
【００９４】
特定の実施形態では、事前生成されたウェブ・サービス・クライアントが、ウェブ・サービス・ファクトリ（クラス）を提供する。ウェブ・サービス・ファクトリは、各ウェブ・サービスを「公開」し、クライアントがサービス・アドレスを判断する必要性をなくす。ウェブ・サービス・ファクトリは、ＩＭウェブ・サービスの任意のもののインスタンスを提供することができる。ウェブ・サービスの取得は、機能的に単純である（例えば、ｗｅｂＳｅｒｖｉｃｅＦａｃｔｏｒｙ．ｇｅｔＷＳＰａｓｗｏｒｄＳｅｒｖｉｃｅ（））。
【００９５】
図３３は、特定の実施形態による、ＩＭノードに対し認証を行ってユーザの個人オブジェクトを取得するために、ウェブ・サービスを使用する例であるコード・スニペット３１００を示す。
【００９６】
図３４は、特定の実施形態による、ＩＭノード・トポロジを発見するためにＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。図３４では、ＤＴＥＩＭエンジン１２０は、設定タスクを実行しており、発見されたノードおよびサービスをＬＤＡＰ内に記憶している。制御は、ブロック３２００にて始まり、ＤＴＥＩＭアドミニストレータが、メインのＩＭノードから設定を開始する。ブロック３２０２において、ＤＴＥＩＭエンジン１２０は、メインのＩＭノードを、他のＩＭノードを発見するために検索する。ブロック３２０４において、ＤＴＥＩＭエンジン１２０は、各ＩＭノードに、当該ＩＭノードによってサポートされているサービスのリストを取得するべく問い合わせを行う。ブロック３２０６において、ＤＴＥＩＭエンジン１２０は、複数のＩＭノードに対する並行したサブ・クエリを使用して、ユーザ・クエリを処理する。並行したユーザ・クエリの処理のさらなる詳細は、図３９、４０を参照して記載する。ブロック３２０８において、ＤＴＥＩＭエンジン１２０は、「ノードを意識した（ｎｏｄｅ  ａｗａｒｅ）」サービス・オブジェクト・スタブをＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバ内に作成して、サービス・トポロジを作成する。
【００９７】
図３５は、特定の実施形態による、ユーザによって開始された変更に関する各ＩＭノード上のアイデンティティ情報の同期のためにＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック３３００にて始まり、ユーザが、ＤＴＥＩＭエンジン１２０内のアイデンティティ（個人）情報を見ることをリクエストする。ブロック３３０２において、ＤＴＥＩＭエンジン１２０は、メインのＩＭノードから個人情報を読み出す。ブロック３３０４において、ユーザは、個人属性において、追加／修正／削除／一時停止／回復の変更を加え（例えば、情報を追加／修正／削除／一時停止／回復する）、個人修正リクエストをＤＴＥＩＭエンジン１２０に提出する。ブロック３３０６において、ＤＴＥＩＭエンジン１２０は、個人修正リクエストを、メインのＩＭノードにウェブ・サービスによって提出する。ブロック３３０６から、処理は、ブロック３３０８および３３１２の両方に進む。
【００９８】
ブロック３３０８では、メインのＩＭノードが、ＩＭ−ＩＭアダプタを使用して、個人修正を参加しているすべてのＩＭノードに送信する。ブロック３３１０において、個人修正を受信する各ＩＭノードが、当該ＩＭノードにある情報を更新する。さらに、個人変更を受信する各ＩＭノードが、追加／削除／一時停止／回復リクエストをＤＴＥＩＭエンジン１２０にルーティングする。
【００９９】
ブロック３３１２では、メインのＩＭノード上のＤＴＥＩＭノーティファイア・モジュールが、個人追加／削除／一時停止／回復の通知パケットを作成し、ノードｉｄを追加し、オブジェクト・スタブをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック３３１４において、ＤＴＥＩＭエンジン１２０は通知を受信する。ブロック３３１６において、ＤＴＥＩＭエンジン１２０は、ノードｉｄを備える個人オブジェクト・スタブの追加／削除／一時停止／回復を、ＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバに対し行う。
【０１００】
図３６は、特定の実施形態による、アイデンティティ・フィードを介して開始された変更に関する各ＩＭノード上のアイデンティティ情報の同期のためにＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック３４００にて始まり、ユーザ（例えば、顧客）が、メインのＩＭノードへのアイデンティティ・フィードを設定する。ブロック３４０２において、メインのＩＭノードは、このアイデンティティ・フィードに従い、個人追加／修正／削除／一時停止／回復の変更を複数加える。ブロック３４０２から、処理はブロック３４０４および３４０８の両方に続く。追加／削除／一時停止／回復リクエストは、ＤＴＥＩＭエンジン１２０および他のＩＭノード両方へルーティングされる。一方、属性修正は他のＩＭノードへルーティングされるが、これらの通知がＤＴＥＩＭエンジン１２０に返される必要はない。
【０１０１】
ブロック３４０４では、メインのＩＭノードが、ＩＭ−ＩＭアダプタを使用して、個人変更を参加しているすべてのＩＭノードに送信する。ブロック３４０６において、個人変更を受信する各ＩＭノードが、当該ＩＭノードにある情報を更新する。さらに、個人変更を受信する各ＩＭノードが、追加／削除／一時停止／回復リクエストをＤＴＥＩＭエンジン１２０にルーティングする。
【０１０２】
ブロック３４０８では、メインのＩＭノード上のＤＴＥＩＭノーティファイア・モジュールが、個人追加／削除／一時停止／回復のための通知パケットを作成し、ノードｉｄを追加し、オブジェクト・スタブをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック３４１０において、ＤＴＥＩＭエンジンは通知を受信する。ブロック３４１２において、ＤＴＥＩＭエンジン１２０は、ノードｉｄを備える個人オブジェクト・スタブの追加／一時停止／回復／削除を、ＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバに対し行う。
【０１０３】
図３７、３８は、特定の実施形態による、複数のＩＭノードからのＩＭ情報を結合するようＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。図３７、３８は１つの図を表す。制御は、ブロック３５００にて（図３７）始まり、ユーザが、ＤＴＥＩＭエンジン１２０へのログインをリクエストする。ブロック３５０２において、ＤＴＥＩＭエンジン１２０は、企業リポジトリに対してユーザ認証を行う。特定の実施形態では、ユーザがｕｓｅｒｉｄおよびパスワードを提供し、これらが企業リポジトリに対する認証のために使用される。ブロック３５０４において、ＤＴＥＩＭエンジン１２０は、ＩＭトポロジ上のユーザのフットプリントをＤＴＥＩＭ  ＬＤＡＰから得て（オブジェクト・スタブを調べてそのユーザがプロビジョニングされているＩＭノードを発見することによって）、認証情報キャッシュを作成する。例えば、２０のＩＭノードが存在し、ユーザが５つのＩＭノードに参加する場合、認証情報キャッシュは、その５つのＩＭノードのうちの任意のものと通信するために使用される認証情報を記憶するために使用され得る。ブロック３５０６において、ＤＴＥＩＭエンジン１２０は、ユーザの「ノードを意識した」アカウント・オブジェクト・スタブを、ＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバから読み出す。ブロック３５０６から（図３７）、処理はブロック３５０８に続く（図３８）。
【０１０４】
ブロック３５０８において、ＤＴＥＩＭエンジン１２０は、ユーザが、「リクエスト」データのクエリを行ったかどうかを判断する。そうであれば、処理はブロック３５１０に続き、そうでなければ、処理はブロック３５１２に続く。ブロック３５１０において、ＤＴＥＩＭエンジン１２０は、複数のＩＭノードに対する並行したサブ・クエリを使用して、クエリを処理する。並行したクエリの処理のさらなる詳細は、図３９、４０を参照して記載する。ブロック３５１０から、処理はブロック３５１２に続く。
【０１０５】
ブロック３５１２において、ＤＴＥＩＭエンジン１２０は、ユーザが「ｔｏ  ｄｏ」データのクエリを行ったかどうかを判断する。そうであれば、処理はブロック３５１４に続き、そうでなければ、処理はブロック３５１６に続く。ブロック３５１４において、ＤＴＥＩＭエンジン１２０は、複数のＩＭノードに対する並行したサブ・クエリを使用して、クエリを処理する。並行したクエリの処理のさらなる詳細は、図３９、４０を参照して記載する。ブロック３５１４から、処理はブロック３５１６に続く。
【０１０６】
ブロック３５１６において、ＤＴＥＩＭエンジン１２０は、ユーザがクエリを行ったものであるとよい任意の「リクエスト」および「ｔｏ  ｄｏ」データと結合された「ノードを意識した」「アカウント」データをユーザに返して、複数のＩＭノードからの結合された情報をユーザに提示する。したがって、ユーザが「リクエスト」または「ｔｏ  ｄｏ」データを要求していなければ、ユーザは、複数のＩＭノードからの「アカウント」データを受信する。なお、ユーザが「リクエスト」もしくは「ｔｏ  ｄｏ」データまたはその両方を要求した場合、ユーザは、複数のＩＭノードからの、結合された「アカウント」データと、「リクエスト」もしくは「ｔｏ  ｄｏ」データまたはその両方とを受信する。ＤＴＥＩＭエンジン１２０は、既存のアイデンティティ管理情報を、このユーザが当該情報の提示以前にアクセスを許可されている複数のＩＭノードから取得し、結合した。
【０１０７】
図３９、４０は、特定の実施形態による、複数のＩＭノードに並行して情報に関するクエリを発行するようＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。図３９、４０は１つの図を表す。制御はブロック３６００にて始まり（図３９）、ＤＴＥＩＭエンジン１２０が、ユーザのフットプリントを使用して、クエリを行うＩＭノード・セットを構築し、クエリをサブ・クエリに分解し、サブ・クエリをＩＭノード・セットの各ＩＭノードに並行して発行する。特定の代わりの実施形態では、サブ・クエリは、各ＩＭノードに送信される完全なクエリであってもよい。
【０１０８】
具体的には、各ＩＭノード（例えば、ＩＭノード１、ＩＭノード２、．．．ＩＭノードＮ）に関して、ブロック３６２０〜３６２８（図４０）の処理が並行して実行される。ブロック３６２０において、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸ（Ｘは任意のＩＭノード、１、２、．．．Ｎ）がアクティブであるかどうかを判断する。そうであれば、処理はブロック３６２４に続き、そうでなければ、処理はブロック３６２２に続く。ブロック３６２２において、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸダウン結果を追加する。特定の実施形態では、ダウン結果は、「ＩＭノードはダウン／到達不可能」エラー・メッセージを示す。ブロック３６２２から、処理はブロック３６０８に続く（図３９）。
【０１０９】
ブロック３６２４では、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸの認証情報が、認証情報キャッシュにおいて入手可能かどうかを判断する。そうであれば、処理はブロック３６２８に続き、そうでなければ、処理はブロック３６２６に続く。ブロック３６２６において、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸ上の認証情報を認証し、認証情報を認証情報キャッシュに記憶する。ブロック３６２６から、処理はブロック３６２８に続く。
【０１１０】
ブロック３６２８において、ＤＴＥＩＭエンジン１２０は、サブ・クエリを非同期的にＩＭノードＸに発行する。ブロック３６２８から（図４０）、処理はブロック３６０８に続く（図３９）。
【０１１１】
ブロック３６０８において、ＤＴＥＩＭエンジン１２０は、ＩＭノードが応答するにつれて、サブ・クエリ結果を非同期的に結合する。ブロック３６１０において、ＤＴＥＩＭエンジン１２０は、結合された「ノードを意識した」結果セットを返す。
【０１１２】
図４１は、特定の実施形態による、ユーザ・リクエストの処理のためにＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック３７００にて始まり、ＤＴＥＩＭエンジン１２０が、ユーザからプロビジョニング・リクエストを受信する。プロビジョニング・リクエストは、情報を変更するリクエストである（例えば、アカウント追加／アカウント修正／パスワード変更／アカウント削除／アカウント一時停止／アカウント情報回復）。ブロック３７０２において、ＤＴＥＩＭエンジン１２０は、プロビジョニング・リクエスト・データを、「ノードを意識した」ＤＴＥＩＭリクエスト・データからＩＭノードｉｄ毎に分解する。特定の実施形態では、リクエスト・データが、リクエストのコンテキスト・データであり、ＤＴＥＩＭエンジン１２０が、ＩＭノード・アウェアネスを挿入する。
【０１１３】
ブロック３７０４において、ＤＴＥＩＭエンジン１２０は、ノードｉｄ毎のリクエスト・データをノード・マップにまとめる。ブロック３７０６において、ＤＴＥＩＭエンジンは、並行したサブ・リクエストを発行する。並行したリクエストの処理のさらなる詳細は、図４２、４３を参照して記載する。ブロック３７０８において、ＤＴＥＩＭエンジン１２０は、プロビジョニング・リクエスト・ステータス（例えば、完了、失敗など）をユーザに返す。
【０１１４】
図４２、４３は、特定の実施形態による、変更のリクエストを並行して発行するようＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。図４２、４３は１つの図を表す。制御は、ブロック３８００にて始まり、ＤＴＥＩＭエンジンが、リクエスト・ノード・マップを使用して、ターゲットとするＩＭノード・セットを構築し、プロビジョニング・リクエストをサブ・リクエストに分解し、サブ・リクエストをＩＭノード・セットの各ＩＭノードに発行する。特定の代わりの実施形態では、サブ・リクエストは、各ＩＭノードに送信される完全なプロビジョニング・リクエストであってもよい。
【０１１５】
具体的には、各ＩＭノード（例えば、ＩＭノード１、ＩＭノード２、．．．ＩＭノードＮ）に関して、ブロック３８２０〜３８２８（図４３）の処理は、並行して実行される。ブロック３８２０において、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸ（Ｘは任意のＩＭノード、１、２、．．．Ｎ）がアクティブであるかどうかを判断する。そうであれば、処理はブロック３８２４に続き、そうでなければ、処理はブロック３８２２に続く。ブロック３８２２において、ＤＴＥＩＭエンジン１２０は、サブ・リクエストをＩＭノードＸに遅延提出するために、キューに入れる。ブロック３８２２から、処理はブロック３８０８に続き（図４２）、サブ・リクエストの遅延ステータスを示す。
【０１１６】
ブロック３８２４では、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸの認証情報が、認証情報キャッシュにおいて入手可能かどうかを判断する。そうであれば、処理はブロック３８２８に続き、そうでなければ、処理はブロック３８２６に続く。ブロック３８２６において、ＤＴＥＩＭエンジン１２０は、ＩＭノードＸ上の認証情報を認証し、認証情報を認証情報キャッシュに記憶する。ブロック３８２６から、処理はブロック３８２８に続く。
【０１１７】
ブロック３８２８において、ＤＴＥＩＭエンジン１２０は、サブ・リクエストを非同期的にＩＭノードＸに提出する。ブロック３８２８から（図４３）、処理はブロック３８０８に続く（図４２）。
【０１１８】
ブロック３８０８において、ＤＴＥＩＭエンジン１２０は、ＩＭノードが応答するにつれて非同期的に、サブ・リクエスト・ステータスを結合して、プロビジョニング・リクエスト・ステータスを形成する。ブロック３８１０において、ＤＴＥＩＭエンジン１２０は、結合された「ノードを意識した」ステータスを返す。
【０１１９】
図４４は、特定の実施形態による、ＩＭノードに直接追加されたユーザ・アカウントに関してＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック３９００にて始まり、ＩＭノードＸが、個人Ｐに関して、新たなアカウントｕｓｅｒｉｄ  ＵをサービスＳ上に追加する。ブロック３９０２において、ＩＭノードＸ上のＤＴＥＩＭノーティファイア・モジュールは、オブジェクト・スタブを作成し、ノードｉｄを追加し、オブジェクト・スタブをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック３９０４において、ＤＴＥＩＭエンジン１２０は通知を受信する。ブロック３９０６において、ＤＴＥＩＭエンジン１２０は、個人Ｐに関して、ノードｉｄ  ＸおよびサービスＳを備えるオブジェクト・スタブＵをＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバに追加する。
【０１２０】
図４５は、特定の実施形態による、ＩＭノード上で直接行われたアカウント修正またはパスワード変更に関してＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック４０００にて始まり、ＩＭノードＸが、個人Ｐに関して、サービスＳ上のｕｓｅｒｉｄ  Ｕに関する既存のアカウントを修正するか、またはパスワードを変更する。ブロック４００２において、ＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバは既にアカウント・スタブを有するため、ＩＭノードＸ上のＤＴＥＩＭノーティファイア・モジュールは、通知をＤＴＥＩＭエンジン１２０に送信しない。すなわち、特定の実施形態では、ＤＴＥＩＭ  ＬＤＡＰディレクトリ・サーバは、アカウント・パスワードを記憶しない。ブロック４００４において、ＤＴＥＩＭエンジン１２０は、既存のアカウントの修正またはパスワードの変更に応答して、何の修正も加えない。
【０１２１】
図４６は、特定の実施形態による、ＩＭノード上のアカウント一時停止に関してＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック４１００にて始まり、ＩＭノードＸは、個人Ｐに関して、サービスＳ上のアカウントｕｓｅｒｉｄ  Ｕを一時停止する。ブロック４１０２において、ＩＭノードＸ上のＤＴＥＩＭノーティファイア・モジュールは、オブジェクト・スタブを一時停止するための修正パケットを作成し、ノードｉｄを追加し、修正パケットをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック４１０４において、ＤＴＥＩＭエンジン１２０は通知を受信する。ブロック４１０６において、ＤＴＥＩＭエンジン１２０は、オブジェクト・スタブＵを修正し、ステータスを一時停止中に変更する。
【０１２２】
図４７は、特定の実施形態による、ＩＭノード上のアカウント回復に関してＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック４２００にて始まり、ＩＭノードＸが、個人Ｐに関して、サービスＳ上のアカウントｕｓｅｒｉｄ  Ｕを回復する。ブロック４２０２において、ＩＭノードＸ上のＤＴＥＩＭノーティファイア・モジュールは、オブジェクト・スタブを回復するための修正パケットを作成し、ノードｉｄを追加し、修正パケットをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック４２０４において、ＤＴＥＩＭエンジン１２０は通知を受信する。ブロック４２０６において、ＤＴＥＩＭエンジン１２０は、オブジェクト・スタブＵを修正し、ステータスを回復済みに変更する。
【０１２３】
図４８は、特定の実施形態による、ＩＭノード上のアカウント削除に関してＤＴＥＩＭエンジン１２０によって実行される論理をフロー図で示す。制御は、ブロック４３００にて始まり、ＩＭノードＸが、個人Ｐに関して、サービスＳ上のアカウントｕｓｅｒｉｄ  Ｕを削除する。ブロック４３０２において、ＩＭノードＸ上のＤＴＥＩＭノーティファイア・モジュールは、オブジェクト・スタブを削除するための修正パケットを作成し、ノードｉｄを追加し、修正パケットをＤＴＥＩＭエンジン１２０にウェブ・サービスによって送信する。ブロック４３０４において、ＤＴＥＩＭエンジン１２０は通知を受信する。ブロック４３０６において、ＤＴＥＩＭエンジン１２０は、オブジェクト・スタブＵを削除済みとしてマークする。
【０１２４】
したがって、ＤＴＥＩＭアーキテクチャは、非常に大きなアイデンティティ管理実装に使用され得る。ＤＴＥＩＭアーキテクチャは、アイデンティティ管理を分散型のトポロジで展開することによって、アイデンティティ管理を徐々に拡張可能にする。ＤＴＥＩＭアーキテクチャは、ＩＭインフラストラクチャの時間差メンテナンスを可能にすることによって可用性を高め、パフォーマンスを改善し、ＩＭの異種バージョンをサポートし、アドミニストレーションを分散化する。分散化モデルは、管理可能性および作業負荷の分散を改善する。
【０１２５】
ＤＴＥＩＭアーキテクチャは、システム・アイデンティティを、分散型ＩＭノードを使用して追跡する。各ＩＭノードは、他のＩＭノードと協働して、拡張可能／分散型の様式でネットワーク・アーキテクチャに対する設定を行うことを可能にする。
【０１２６】
ＤＴＥＩＭアーキテクチャは、局所的なアドミニストレーションならびに集中したアイデンティティおよびアカウント運用を可能にする。ＤＴＥＩＭアーキテクチャは、集団（例えば、孤立したラボ）のサブセットにそれ１つのためのプロビジョニングを提供できる。
【０１２７】
ＤＴＥＩＭアーキテクチャを用いると、より多くのサービスが展開されるにつれてより多くのＩＭノードが追加されることもできる。個々のＩＭが、サービスおよび調整の、それ自体のサブセットを処理するため、パフォーマンス・ボトルネックが回避される。
【０１２８】
追加の実施形態の詳細
当業者であれば当然のことであるが、本発明の側面は、システム、方法またはコンピュータ・プログラム製品として具現化され得る。したがって、本発明の側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本願明細書においてすべて概して「回路」、「モジュール」もしくは「システム」と呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとってもよい。さらに、本発明の側面は、コンピュータ可読プログラム・コードが具現化された１つ以上のコンピュータ可読媒体（単数または複数）において具現化されたコンピュータ・プログラム製品の形態をとることもできる。
【０１２９】
１つ以上のコンピュータ可読媒体（単数または複数）の任意の組み合わせが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読ストレージ媒体とされ得る。コンピュータ可読ストレージ媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線、もしくは半導体システム、装置、もしくはデバイス、または前述のものの任意の適切な組み合わせとすることもできる。コンピュータ可読ストレージ媒体のより具体的な例（包括的でないリスト）には、１つ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）またはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、光学式ストレージ・デバイス、磁気ストレージ・デバイス、ソリッド・ステート・メモリ、磁気テープ、または前述のものの任意の適切な組み合わせが含まれるであろう。この文書の文脈では、コンピュータ可読ストレージ媒体は、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを含むこと、または記憶することができる任意の有形の媒体であればよい。
【０１３０】
コンピュータ可読信号媒体は、例えば、ベースバンドに、または搬送波の一部として、コンピュータ可読プログラム・コードが具現化された伝播データ信号を含み得る。そのような伝播信号は、電磁気、光学、またはその任意の適切な組み合わせを含むがこれらに限定はされない、様々な形態のいずれかをとってよい。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体でなく、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを伝達すること、伝播させること、または搬送することができる、任意のコンピュータ可読媒体としてよい。
【０１３１】
コンピュータ可読媒体上に具現化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、または前述のものの任意の適切な組み合わせを含むがこれらに限定はされない、任意の適切な媒体を使用して送られてもよい。
【０１３２】
本発明の側面の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋または同様のものなどのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続きプログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれていてよい。プログラム・コードは、スタンド・アロン・ソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されること、部分的にユーザのコンピュータ上で実行されること、または部分的にユーザのコンピュータ上で、かつ部分的にリモート・コンピュータ上で実行されること、または完全にリモート・コンピュータもしくはサーバ上で実行されることもできる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、もしくは広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を含む任意のタイプのネットワークを介してリモート・コンピュータがユーザのコンピュータに接続されてもよく、または、外部コンピュータに接続されてもよい（例えば、インターネット・サービス・プロバイダを使用しインターネットを介して）。
【０１３３】
本発明の実施形態の側面について、本発明の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して以下に記載する。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令により実装可能である。当該コンピュータ・プログラム命令が、マシーンを生じるよう、汎用コンピュータ、専用コンピュータ、またはその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサを用いて実行されて、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する手段を作り出すようにすることもできる。
【０１３４】
さらに、特定の形で機能するようコンピュータ、その他のプログラム可能データ処理装置、またはその他のデバイスに指示することができる当該コンピュータ・プログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する命令を含む製品を生じるようにすることもできる。
【０１３５】
さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラム可能データ処理装置、またはその他のデバイスにロードされて、コンピュータ、その他のプログラム可能装置、またはその他のデバイス上で一連の動作処理（例えば動作またはステップ）が実行されるようにしてコンピュータに実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。
【０１３６】
記載された動作を実装するコードはさらに、ハードウェア論理または回路（例えば集積回路チップ、プログラマブル・ゲート・アレイ（ＰＧＡ：Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）などにおいて実装され得る。ハードウェア論理は、動作を実行するようプロセッサに連結されてもよい。
【０１３７】
ＤＴＥＩＭエンジン１２０は、ハードウェア（例えば、ハードウェア論理もしくは回路）、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせとして実装されてよい。
【０１３８】
図４９は、特定の実施形態により使用され得るコンピュータ・アーキテクチャ４４００を示す。ＤＴＥＩＭサーバもしくはＩＭノードまたはその両方は、コンピュータ・アーキテクチャ４４００を実装してもよい。コンピュータ・アーキテクチャ４４００は、プログラム・コードの記憶もしくは実行またはその両方に適しており、システム・バス４４２０を介してメモリ要素４４０４に直接または間接的に連結された少なくとも１つのプロセッサ４４０２を含む。メモリ要素４４０４は、プログラム・コードを実際に実行する間に用いられるローカル・メモリ、大容量ストレージ、および、実行中にコードが大容量ストレージから読み出されなければならない回数を減らすために少なくとも一部のプログラム・コードの一時的なストレージとなるキャッシュ・メモリを含み得る。メモリ要素４４０４は、オペレーティング・システム４４０５および１つ以上のコンピュータ・プログラム４４０６を含む。
【０１３９】
入出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）デバイス４４１２、４４１４（限定はされないが、キーボード、ディスプレイ、ポインティング・デバイスなどを含む）は、直接、または介在するＩ／Ｏコントローラ４４１０を介して、システムに連結され得る。
【０１４０】
ネットワーク・アダプタ４４０８もシステムに連結されて、データ処理システムが、他のデータ処理システムまたはリモート・プリンタまたはストレージ・デバイスに、介在するプライベートまたはパブリック・ネットワークを介して連結された状態となることを可能にしてもよい。モデム、ケーブル・モデム、およびイーサネット・カードが、現在利用可能なタイプのネットワーク・アダプタ４４０８のごく一部である。
【０１４１】
コンピュータ・アーキテクチャ４４００は、ストレージ４４１６（例えば、磁気ディスク・ドライブ、光ディスク・ドライブ、テープ・ドライブなどの不揮発性ストレージ・エリア）に連結されてもよい。ストレージ４４１６は、内部ストレージ・デバイス、または接続されたストレージもしくはネットワーク・アクセス可能ストレージを含んでもよい。ストレージ４４１６内のコンピュータ・プログラム４４０６が、メモリ要素４４０４にロードされて、プロセッサ４４０２によって、当技術分野で既知の方法で実行されてもよい。
【０１４２】
コンピュータ・アーキテクチャ４４００は、示されているよりも少ないコンポーネントを含んでも、本願明細書に示されていない追加のコンポーネントを含んでも、または示されたコンポーネントおよび追加のコンポーネントの何らかの組み合わせを含んでもよい。コンピュータ・アーキテクチャ４４００は、メインフレーム、サーバ、パーソナル・コンピュータ、ワークステーション、ラップトップ、ハンドヘルド・コンピュータ、電話デバイス、ネットワーク・アプライアンス、仮想化デバイス、ストレージ・コントローラなど、当技術分野で既知の任意のコンピューティング・デバイスを含み得る。
【０１４３】
各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性および動作を示す。この関連で、フローチャートまたはブロック図内の各ブロックは、指定の論理機能（単数または複数）を実装する１つ以上の実行可能命令を含むモジュール、セグメント、またはコードの一部を表現することもできる。なお、さらに、いくつかの代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている２つのブロックが実際には事実上同時に実行されてもよく、または、各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェア・ベース・システム、または専用ハードウェアおよびコンピュータ命令の組み合わせにより実装することができる。
【０１４４】
本願明細書で使用される専門用語は、特定の実施形態を説明するためのものでしかなく、本発明の限定となることは目的としていない。本願明細書で使用される、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈によりそうでないことが明確に示されていない限り、複数形も含むものとする。さらに、当然のことながら、「含む」もしくは「含んでいる」またはその両方の用語は、本明細書で使用されるとき、記載された機能、完全体、ステップ、動作、構成要素、もしくはコンポーネント、またはそのいずれかの組み合わせの存在を指定するが、１つ以上の他の機能、完全体、ステップ、動作、構成要素、コンポーネント、もしくはそのグループ、またはそのいずれかの組み合わせの存在または追加を除外するものではない。
【０１４５】
以下の特許請求の範囲のミーンズまたはステップ・プラス・ファンクション構成要素すべての対応する構造、材料、動作、および等価物は、明確に請求されている他の請求される構成要素とともに機能を実行する任意の構造、材料、または動作を含むものとする。本発明の実施形態の記載は、例証および説明のために提示されたものであるが、包括的であることも、開示された形態の発明に限定されることも目的としていない。当業者には、本発明の範囲および意図から逸脱することのない、多数の変更および変形が明らかであろう。実施形態は、本発明の原理および実際の応用を最もよく説明して、当業者が、意図される特定の用途に適する様々な変更を用いた様々な実施形態に関して、本発明を理解できるように選ばれ、記載された。
【０１４６】
本発明の実施形態の前述の説明は、例証および説明のために提示された。包括的であること、または開示された厳密な形に実施形態を限定することを目的としたものではない。上記の教示を踏まえ、多数の変更および変形が可能である。実施形態の範囲は、この詳細な説明ではなく、本願明細書に添付されている特許請求の範囲によって定められるものとする。上記の明細事項、例、およびデータは、実施形態の構成の製造および使用の、全面的な説明を提供する。多数の実施形態が、本発明の意図および範囲から逸脱することなく構成され得るため、その実施形態は、以下に添付された特許請求の範囲または後に提出される任意の特許請求の範囲、およびその等価物に属する。
【符号の説明】
【０１４７】
１１０  ＤＴＥＩＭサーバ
１２０  ＤＴＥＩＭエンジン
１４０  ＤＴＥＩＭディレクトリ・サーバ
２００  ＤＴＥＩＭレイヤ
２１０  アイデンティティ・フィード
２３０ａ、２３０ｂ、２３０ｎ  ＤＴＥＩＭノーティファイア・モジュール
２５０  ＩＭレイヤ
２６０ａ、２６０ｂ、２６０ｎ  ＩＭノード
２６２ａ、２６２ｂ、２６２ｎ  ＩＭサーバ
２６４ａ、２６４ｂ、２６４ｎ  ＩＭディレクトリ・サーバ
２６６ａ、２６６ｂ、２６６ｎ  ＩＭデータベース
２６８ａ、２６８ｂ、２６８ｎ  ＩＭウェブ・サービス
２７０ａ、２７０ｂ、２７０ｎ  エンド・ポイント
２７２ｂ、２７２ｎ  ＩＭ−ＩＭアダプタ
【図１】
0005863432.tif 000002
【図２】
0005863432.tif 000003
【図３】
0005863432.tif 000004
【図４】
0005863432.tif 000005
【図５】
0005863432.tif 000006
【図６】
0005863432.tif 000007
【図７】
0005863432.tif 000008
【図８】
0005863432.tif 000009
【図９】
0005863432.tif 000010
【図１０】
0005863432.tif 000011
【図１１】
0005863432.tif 000012
【図１２】
0005863432.tif 000013
【図１３】
0005863432.tif 000014
【図１４】
0005863432.tif 000015
【図１５】
0005863432.tif 000016
【図１６】
0005863432.tif 000017
【図１７】
0005863432.tif 000018
【図１８】
0005863432.tif 000019
【図１９】
0005863432.tif 000020
【図２０】
0005863432.tif 000021
【図２１】
0005863432.tif 000022
【図２２】
0005863432.tif 000023
【図２３】
0005863432.tif 000024
【図２４】
0005863432.tif 000025
【図２５】
0005863432.tif 000026
【図２６】
0005863432.tif 000027
【図２７】
0005863432.tif 000028
【図２８】
0005863432.tif 000029
【図２９】
0005863432.tif 000030
【図３０】
0005863432.tif 000031
【図３１】
0005863432.tif 000032
【図３２】
0005863432.tif 000033
【図３３】
0005863432.tif 000034
【図３４】
0005863432.tif 000035
【図３５】
0005863432.tif 000036
【図３６】
0005863432.tif 000037
【図３７】
0005863432.tif 000038
【図３８】
0005863432.tif 000039
【図３９】
0005863432.tif 000040
【図４０】
0005863432.tif 000041
【図４１】
0005863432.tif 000042
【図４２】
0005863432.tif 000043
【図４３】
0005863432.tif 000044
【図４４】
0005863432.tif 000045
【図４５】
0005863432.tif 000046
【図４６】
0005863432.tif 000047
【図４７】
0005863432.tif 000048
【図４８】
0005863432.tif 000049
【図４９】
0005863432.tif 000050