JP2009532748A - 分散型ディレクトリ中でのグループ・メンバーシップを伴うアクセス許可のための方法およびシステム - Google Patents

Abstract

【課題】 分散型ディレクトリ環境において、所与のユーザについてのグループ・メンバーシップを評価する技術を提供する。
【解決手段】 分散型ディレクトリ環境内においてディレクトリ動作を実行するためのシステムを提供する。この環境は、分散型ディレクトリ・サーバ、および、クライアントと分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含む。プロキシ・サーバは、各ディレクトリ・サーバがサポートする分散型ディレクトリの各部分内のグループ項目に関してユーザについてのグループ・メンバーシップに関する情報を収集するために、ディレクトリ・サーバに要求を送信する。プロキシ・サーバは、ユーザのために要求するいずれかのディレクトリ動作と共に、ユーザについてのコンパイルしたグループ・メンバーシップ情報を送信する。ディレクトリ・サーバは、要求されたディレクトリ動作と共にコンパイルしたグループ・メンバーシップ情報を受信し、次いで、分散型ディレクトリ情報ツリーのローカルにストアした部分に関して、および、ユーザについてのグループ・メンバーシップの受信した情報に関して、要求されたディレクトリ動作を実行する。
【選択図】 図５

Description

本発明は、改良型のデータ処理システムに関し、具体的には、データベース・アクセスのための方法および装置に関する。更に具体的には、本発明は、分散型ディレクトリからの情報を考慮して認証動作を行うための方法および装置を対象とする。

ディレクトリは、人間、組織、データ処理システム、およびその他の情報ソースに関する情報を管理するための、特別なタイプのデータベースである。ディレクトリ内の情報は、階層型のネームスペース内に組織化されている。各項目は名前付きオブジェクトであり、１組の属性から成る。各属性は、規定された属性型および１つ以上の値を有する。各項目は、一義的な識別名（ＤＮ：distinguished name）によって識別される。識別名は、項目から選択された属性の連結である。ディレクトリ・サービスは、ディレクトリを検索し、ディレクトリから情報を取得するための機構を提供する。ディレクトリおよびディレクトリ・サービスを規定するための様々な規格が広まっている。例えば、Ｘ．５００仕様はディレクトリ規格を規定する。更に詳しい情報は、Weider等による、InternetEngineering Task Force（ＩＥＴＦ）ＲＦＣ１３０９（１９９２年４月）の「Technical Overview of Directory Services Using the X.500 Protocol」において見ることができる。別の例として、Lightweight DirectoryAccess Protocol（ＬＤＡＰ）仕様は、Ｘ．５００ディレクトリ・モデルをサポートするディレクトリにアクセスするためのプロトコルを規定する。更に詳しい情報は、Wahl等のＩＥＴＦ ＲＦＣ２２５１（１９９７年１２月）の「Lightweight Directory Access Protocol (v3)」において見ることができる。

ディレクトリの論理表現は、必ずしもそのディレクトリの物理的記憶装置の構成を反映するわけではない。メモリ・システムの多くのタイプと同様に、ディレクトリは、論理的には全体としてまとめてサポートされるが、物理的には分散型でサポートされる場合がある。例えば、単一のディレクトリを多くのサーバ間にまたがってストアし、各サーバがそのディレクトリのサブツリーをサポートすることができる。

ディレクトリの使用例として、例えば企業の社員のような個人に関する情報をストアするディレクトリが挙げられる。この場合、各個人は、分散型データ処理システムの多くのユーザの一人である。ディレクトリにおける項目によって個人に関する属性をストアすることができ、ディレクトリ内における特定のユーザの項目はそのユーザの識別名によって識別される。更に、ユーザの集合を示すというようにグループを規定することができ、ディレクトリにおける項目はグループ・メンバーシップに関する情報を含むことができる。ディレクトリにおける項目によってグループに関する属性をストアすることができ、ディレクトリ内における特定のグループの項目はそのグループの識別名によって識別される。「ユーザ項目」という言葉は、特定ユーザの属性のストレージを表すディレクトリにおける項目を示し、「グループ項目」という言葉は、特定グループの属性のストレージを表すディレクトリ内の項目を示すことができる。
Weider等による、InternetEngineering Task Force（ＩＥＴＦ）ＲＦＣ１３０９（１９９２年４月）、「Technical Overview of Directory Services Using the X.500 Protocol」 Wahl等による、ＩＥＴＦ ＲＦＣ２２５１（１９９７年１２月）、「Lightweight Directory Access Protocol(v3)」

ユーザ項目およびグループ項目を含むディレクトリについて分散型ストレージ機構を採用する場合、様々な情報処理の問題が生じる場合がある。例えば、指定されたターゲット・オブジェクトに関して指定されたユーザのために実行されている特定のタイプの動作には、この特定のタイプの動作をうまく完了させるための要件として、指定されたユーザについて特定グループ内でのメンバーシップを有するという肯定的な判定を必要とする場合がある。指定されたユーザがその特定グループに属する、すなわち、指定されたユーザが必要なグループ・メンバーシップを有する可能性はあるが、分散型ディレクトリを採用している場合、その判定を行うことは問題となり得る。場合によっては、指定されたユーザについてのユーザ項目は、その指定されたユーザが属するグループについてのグループ項目を含む分散型ディレクトリの部分とは異なるサーバによってサポートされている分散型ディレクトリの部分内にあるかもしれない。したがって、サーバが指定されたユーザのための動作を実行しようとする場合、分散型ディレクトリのローカルにストアされローカルにサポートされた部分からユーザ項目を検索することは、おそらく大したことではないだろう。しかしながら、必要なグループ項目の検索は困難である場合がある。なぜなら、サーバは、分散型ディレクトリ内の他のどこかにストアされたグループ項目の位置の特定あるいは検索またはその両方を行うための情報も機構も容易に利用可能でない場合があるからである。換言すると、あるサーバ上に、指定されたユーザについてのユーザ項目があり、そのユーザをメンバとして有するグループについてのグループ項目が異なるサーバ上にある場合、指定されたユーザがそのグループに属することを判定するためには、分散型ストレージの障害を克服しなければならない。

もっと具体的かつ難しい問題は、分散型ディレクトリ中のアクセス制御のために必要なグループ・メンバーシップを判定する行為である。例えば、あるディレクトリに関して、ユーザは１つ以上のグループのメンバである可能性があるが、そのディレクトリ内の項目に対するアクセスを判定するためにグループ・メンバーシップが用いられる。換言すると、あるグループのメンバだけが、ユーザおよびユーザ・グループが規定されているディレクトリのある部分に対するアクセスを与えられなければならない。現在のディレクトリ・サーバの実施においては、ユーザおよびユーザ・グループが同一のディレクトリ・サーバ上にあると想定されているので、アクセスを制限することは難しくない。しかしながら、典型的な分散型データ処理環境において、多数のディレクトリ・サーバ間で分割されサポートされている単一のディレクトリ情報ツリー（ＤＩＴ）を１つの分散型ディレクトリ・システムが提供する分散型ディレクトリ・システムをサポートする必要がある。クライアントは、分散型ディレクトリ・サーバにトランスペアレントにアクセスすることができなければならず、これによってディレクトリ情報ツリーから自動的かつシームレスに情報を検索するが、サポートしているサーバ間でどのようにデータが分割されているかについて詳細を知る必要はない。このため、現在のシステムの中には、プロキシ・サーバを採用して、多数のサーバでサポートされているディレクトリ情報ツリーに対するアクセスを支援するものがある。

しかしながら、グループ・メンバーシップを評価して分散型ディレクトリ環境におけるアクセスを判定する場合、２つの大きな問題がある。第１に、グループ・メンバーシップの評価は難しい。なぜなら、ユーザ項目、グループ項目、およびターゲット・オブジェクト項目は、分散型ディレクトリをサポートしているいかなるサーバ上にも存在し得るからである。第２に、所与のユーザについて特定のサーバによってグループ・メンバーシップを判定した後、その特定のサーバから、分散型ディレクトリをサポートしている他のサーバに、そのグループ・メンバーシップに関する情報を伝達して、分散型ディレクトリ内の情報にアクセスすることに関する所与のユーザのための動作をサポートする必要があり、これは、それらの他のサーバのいずれにおいてもサポートされストアすることができる。

ユーザ項目、グループ項目、およびターゲット・オブジェクト項目が、異なるシステム上でサポートされる分散型ディレクトリの異なる部分にあるという問題を回避するための１つの解決策は、以下の通りである。通常、ディレクトリの一部に対するアクセスを特定のユーザおよびグループに制限するために、アクセス制御リスト（ＡＣＬ：access control list）が用いられる。アクセス制御リストは、これらの特定のユーザおよびグループを示す。従って、アクセス制御リストの処理は、ディレクトリからユーザ項目およびグループ項目を検索することを必要とする。従って、現在のある解決策では、ＡＬＣが示す全てのユーザおよびグループに関する情報が、ＡＣＬを評価するサーバによってサポートされるディレクトリの部分内にローカルに存在することを、コンピューティング環境によって保証しなければならない。これは、全てのユーザ項目および全てのグループ項目を、分散型ディレクトリをサポートしている全てのサーバに複製することによって、実行可能である。しかしながら、このタスクは厄介である。なぜなら、多くの場合、ターゲット・オブジェクトについての項目は、ユーザ項目およびグループ項目と同じサブツリーにあるからである。また、全てのユーザ項目およびグループ項目を複製するには、ユーザ項目またはグループ項目の各サブツリーにおいて項目の全てを複製する必要があり、これによって分散型ディレクトリの効果がなくなってしまう。

別の解決策は、各分散型ディレクトリ・サーバごとに１組のユーザおよびグループを規定することである。しかしながら、この解決策は不充分であり、柔軟でない。ユーザおよびグループは、データとは異なるサブツリーにおいて規定しなければならない。また、ユーザは、１つのサーバのデータにアクセスを有するだけである。従って、この解決策は、分散型ディレクトリ環境が、エンド・ユーザにシームレスに見える方法で分割データをサポートしなければならないという要件に反している。

更に別の解決策は、管理者が所与のユーザについてのグループ・メンバーシップを手作業で判定すること、またはアプリケーションがそれ自身のアルゴリズムを用いて所与のユーザについてのグループ・メンバーシップを個別に判定することである。しかしながら、グループ・メンバーシップの判定後、この情報をディレクトリ・サーバと通信する方法はない。更に、グループ・メンバーシップの判定には間違いが起こりやすく、二度手間となるだろう。ディレクトリ・サーバは、グループ・メンバーシップを決定するためのアルゴリズムをすでに有する。

従って、分散型ディレクトリ環境におけるアクセスを決定するために、更にデータ複製を行う必要なく、また、分散型ディレクトリの部分のストレージ位置を更に制限する必要なく、分散型ディレクトリをサポートするように、所与のユーザについてのグループ・メンバーシップを評価する方法を提供することができれば有利であろう。

分散型ディレクトリ環境内においてディレクトリ動作を実行するための方法、システム、装置、またはコンピュータ・プログラム製品を提供する。この環境は、１つ以上の分散型ディレクトリ・サーバ、および、クライアントと分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含む。プロキシ・サーバは、各ディレクトリ・サーバがサポートする分散型ディレクトリの各部分内のグループ項目に関してユーザについてのグループ・メンバーシップに関する情報を収集またはコンパイルするために、ディレクトリ・サーバに要求を送信する。次いで、プロキシ・サーバは、ユーザのためにディレクトリ・サーバに送信するいずれかのディレクトリ動作と共に、ユーザについてのコンパイルしたグループ・メンバーシップ情報を送信する。ディレクトリ・サーバは、要求されたディレクトリ動作と共にコンパイルしたグループ・メンバーシップ情報を受信し受け入れ、次いで、分散型ディレクトリ情報ツリーのローカルにストアした部分に関して、および、ユーザについてのグループ・メンバーシップの受信した情報に関して、要求されたディレクトリ動作を実行する。

本発明の新規な特色と考えられる特徴は、特許請求の範囲において述べる。本発明自体、その目的および利点は、以下の詳細な説明を、添付図面と組み合わせて読んで参照することによって、最も良く理解されよう。

一般的に、本発明を含むかまたは本発明に関連することができるデバイスは、多種多様なデータ処理技術を含む。従って、背景として、本発明を更に詳細に説明する前に、分散型データ処理システム内のハードウェア・コンポーネントおよびソフトウェア・コンポーネントの典型的な構成について説明する。

ここで図面を参照すると、図１は典型的なデータ処理システムのネットワークを示し、その各々が本発明の一部を実施することができる。分散型データ処理システム１００はネットワーク１０１を含み、これは、分散型データ処理システム１００内で接続された様々なデバイスおよびコンピュータ間に通信リンクを提供するために使用可能な媒体である。ネットワーク１０１は、ワイヤもしくは光ファイバ・ケーブル等の永続的な接続、または電話もしくは無線通信によって行われる一時的な通信を含むことができる。図示した例では、サーバ１０２およびサーバ１０３が、ストレージ・ユニット１０４と共にネットワーク１０１に接続されている。更に、クライアント１０５〜１０７もネットワーク１０１に接続されている。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、パーソナル・デジタル・アシスタント（ＰＤＡ）等の様々なコンピューティング・デバイスによって代表することができる。分散型データ処理システム１００は、図示しない追加のサーバ、クライアント、ルータ、他のデバイス、およびピア・ツー・ピア・アーキテクチャを含むことも可能である。

図示した例では、分散型データ処理システム１００はインターネットを含み、ネットワーク１０１が、Lightweight Directory Access Protocol（ＬＤＡＰ）、Transport Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）、File Transfer Protocol（ＦＴＰ）、Hypertext Transport Protocol（ＨＴＴＰ）、Wireless Application Protocol（ＷＡＰ）等の様々なプロトコルを用いて相互に通信を行うネットワークおよびゲートウェイの世界的な集合を表すことができる。むろん、分散型データ処理システム１００は、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）等の多数の異なるタイプのネットワークを含むことも可能である。例えば、サーバ１０２は、クライアント１０９および無線通信リンクを組み込んだネットワーク１１０を直接サポートする。ネットワーク対応電話１１１は無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ１１３は無線リンク１１４を介してネットワーク１１０に接続する。また、電話１１１およびＰＤＡ１１３は、Bluetooth（商標）無線技術等の適切な技術を用いて、無線リンク１１５を介して相互に直接データを転送して、いわゆるパーソナル・エリア・ネットワーク（ＰＡＮ）またはパーソナル・アドホック・ネットワークを生成することができる。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。

本発明は、様々なハードウェア・プラットフォーム上で実施することができる。図１は、異種コンピューティング環境の一例として意図したものであり、本発明についてのアーキテクチャ上の限定ではない。

ここで図２を参照すると、この図は、本発明を実施可能な、図１に示したもののようなデータ処理システムの典型的なコンピュータ・アーキテクチャを示す。データ処理システム１２０は、内部システム・バス１２３に接続された１つ以上の中央演算処理装置（ＣＰＵ）１２２含む。システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ）１２４、リード・オンリ・メモリ（１２６）、および入／出力アダプタ１２８を相互接続する。入／出力アダプタ１２８は、プリンタ１３０、ディスク・ユニット１３２、またはオーディオ出力システム等の図示しない他のデバイス等の様々なＩ／Ｏデバイスをサポートする。また、システム・バス１２３は、通信リンク１３６に対するアクセスを提供する通信アダプタ１３４に接続する。ユーザ・インタフェース・アダプタ１４８は、キーボード１４０およびマウス１４２等の様々なユーザ・デバイス、またはタッチ・スクリーン、ペン、マイクロフォン等の図示しない他のデバイスを接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３をディスプレイ・デバイス１４６に接続する。

図２のハードウェアがシステムの実施に応じて変化し得ることは、当業者には認められよう。例えば、このシステムは、Intel（Ｒ）Ｐｅｎｔｉｕｍ（登録商標）（Ｒ）ベースのプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）等の１つ以上のプロセッサ、ならびに、揮発性および不揮発性メモリの１つ以上のタイプを有する場合がある。図２に示したハードウェアに加えて、またはその代わりに、他の周辺デバイスも用いることができる。図示した例は、本発明に関してアーキテクチャ上の限定を加えることを意図していない。

様々なハードウェア・プラットフォーム上で実施可能であることに加えて、本発明は、様々なソフトウェア環境において実施することができる。典型的なオペレーティング・システムを用いて、各データ処理システム内でプログラム実行を制御することができる。例えば、１つのデバイスでＵｎｉｘ（登録商標）（Ｒ）オペレーティング・システムが動作し、別のデバイスがシンプル Ｊａｖａ（登録商標）（Ｒ）実行時環境を含むことができる。代表的なコンピュータ・プラットフォームはブラウザを含む場合がある。これは、グラフィック・ファイル、ワード・プロセッシング・ファイル、Extensible Markup Language（ＸＭＬ）、Hypertext Markup Language（ＨＴＭＬ）、Handheld Device Markup Language（ＨＤＭＬ）、Wireless Markup Language（ＷＭＬ）等の様々なフォーマットのハイパーテキスト文書、および他の様々なフォーマットおよび形式のファイルにアクセスするための周知のソフトウェア・アプリケーションである。

本発明は、図１および図２に関して上述したように、様々なハードウェアおよびソフトウェア・プラットフォーム上で実施可能である。更に具体的には、本発明は、改良型の分散型データ処理環境を対象とする。本発明について更に詳しく説明する前に、典型的な分散型データ処理環境のいくつかの側面について説明する。

本明細書における図の説明は、クライアント・デバイスまたはクライアント・デバイスのユーザのいずれかによる何らかの動作を含む場合がある。クライアントへのおよびクライアントからの応答あるいは要求またはそれら双方は、時にはユーザによって開始され、またある時には、多くの場合はクライアントのユーザの代わりに自動的にクライアントによって開始されることは、当業者には理解されよう。従って、図面の説明においてクライアントまたはクライアントのユーザについて言及する場合、「クライアント」および「ユーザ」という言葉は、説明されているプロセスの意味に大きく影響することなく交換可能に用いることができることは理解されよう。

以下に、機能ユニットによって実行されるものとして、いくつかの計算タスクを記載する場合がある。１つの機能ユニットは、ルーチン、サブルーチン、プロセス、サブプロセス、手順、機能、方法、オブジェクト指向のオブジェクト、ソフトウェア・モジュール、アプレット、プラグイン、ActiveX（商標）制御、スクリプト、または、計算タスクを実行するための他の何らかのファームウェアまたはソフトウェアのコンポーネントによって表すことができる。

本明細書における図の説明は、様々なコンポーネント間での情報交換を含む場合がある。情報交換は、例えば要求メッセージ後の応答メッセージのようなメッセージの交換によって実施されるものとして記載することができる。計算コンポーネント間の情報交換は、同期または非同期の要求／応答交換を含む場合があり、メッセージ、メソッド呼び出し、リモート・プロシージャ・コール、イベント信号、または他の機構等、様々なデータ交換機構によって同等に実施することができることに留意すべきである。

以下で、本発明について、Ｘ．５００ディレクトリおよびLightweight Directory Access Protocol（ＬＤＡＰ）の動作に関連した用語および機能について説明するが、本発明は様々なディレクトリ実装スキームおよびプロトコルを用いて実施可能であることに留意すべきである。

ここで図３を参照すると、このブロック図は、企業ドメインのための典型的な分散型データ処理システムを示す。典型的な企業コンピューティング環境またはインターネット・ベースのコンピューティング環境においてと同様に、企業ドメイン１５０は、例えばネットワーク１５４を介してクライアント・デバイス１５３上でブラウザ・アプリケーション１５２を用いることによってユーザ１５１がアクセスすることができる制御されたリソースをホストする。

企業ドメイン１５０は、複数のサーバをサポートする。アプリケーション・サーバ１６５は、ウェブ・ベースのアプリケーションまたはレガシー・アプリケーションを含む他のタイプのアプリケーションによって、アクセス可能リソースをサポートする。認証サーバ１５６は、ユーザ名／パスワード、Ｘ．５０９証明書、セキュアなトークン、またはＳＳＬセッション等の様々な認証機構をサポートする。

プロキシ・サーバ１５７は、企業ドメイン１５０のための多種多様な機能を実行する。プロキシ・サーバ１５７は、コンフィギュレーション・ファイルおよび企業ポリシ・データベース１５８によって管理上構成されて、プロキシ・サーバ１５７の機能を制御することができる。例えば、アプリケーション・サーバからの内容をミラーリングするためにウェブ・ページをキャッシュしたり、入力データストリーム・フィルタ・ユニット１５９および出力データストリーム・フィルタ・ユニット１６０によって着信および発信データストリームをフィルタリングしたりする。入力データストリーム・フィルタ・ユニット１５９は着信要求に対する複数のチェックを実行し、出力データストリーム・フィルタ・ユニット１６０は発信応答に対する複数のチェックを実行することができる。各チェックは、様々な企業ポリシ内で規定された目標および条件に従って実行することができる。

企業ドメイン１５０は権利付与サーバ１６１を含む。これは、ユーザ・レジストリ・データベース１６２、アクセス制御リスト（ＡＣＬ）データベース１６３、および他のドメインからの第三者データストリーム１６４内の情報を受け入れる。権利付与サーバ１６１は、ドメイン１５０内でアプリケーション・サーバ１６５によって提供されるあるサービスに対するユーザのアクセスが許可されているか否かを判定するため、それらのサービスへのユーザ要求について、ポリシあるいはアクセス制御リストまたはそれら両方をチェックする。プロキシ・サーバ１５７、権利付与サーバ１６１、またはプロキシ・サーバ１５７と権利付与サーバ１６１との組み合わせたまたは連係した動作によって、１組のユーザ固有の権利を用いて、ユーザ要求に応答してアプリケーション・サーバ１６５および他の制御リソースに対するアクセスを決定または制御する。

企業ドメイン１５０内の上述のエンティティは、多くのコンピューティング環境内の典型的なエンティティを表す。ウェブ・ベースのアプリケーションは、様々な手段を用いて、多くの場合はＨＴＭＬ形式のユーザ名／パスワードの組み合わせとして認証情報を入力するようユーザに促すことができる。図３に示す例では、おそらくクライアント１５３がリソースにアクセスする前にユーザ１５１を認証する必要があり、その後クライアント１５３についてセッションを確立する。図３において、クライアント１５３から着信要求を受信した後、入力データストリーム・フィルタ・ユニット１５９は、クライアント１５３がすでにセッションを確立しているか否かを判定することができる。まだセッションが確立していない場合、ユーザ１５１を認証するために、認証サーバ１５６上の認証サービスを呼び出すことができる。クライアント１５３がすでにセッションを確立している場合は、制御リソースに対するアクセスを与える前に、着信要求に対して追加のチェックを実行する場合がある。追加のチェックは、企業認証ポリシにおいて規定することができる。

ここで図４を参照すると、ブロック図は、典型的な分散型ディレクトリ環境を示す。ユーザ２０２は、クライアント・アプリケーション２０４を動作させる。これは、図３に示すようなクライアント１５３等のクライアント・デバイス上で実行することができる。クライアント・アプリケーション２０４は、プロキシ化ディレクトリ・サーバによってディレクトリ・サーバとインタラクトする。このサーバは、ディレクトリ・プロキシ・サーバまたはプロキシ・ディレクトリ・サーバとしても知られ、プロキシ・サーバ２０６として示す。プロキシ・サーバ２０６は、ユーザのクライアント・デバイス上、または、図１に示すもの等の接続されたデバイスのネットワーク内のどこか他の場所で実行することができる。プロキシ・サーバ２０６は、コンフィギュレーション・ファイル２０８に関連付けることができる。このファイル２０８が含む情報は、管理ユーザ・アプリケーションによって管理されて、これによってプロキシ・サーバ２０６の機能を制御する。

プロキシ・サーバ２０６は、分散型ディレクトリ環境に対する中間エージェントとして機能する。プロキシ・サーバ２０６は、ＬＤＡＰ仕様を含む様々なディレクトリ・スキームおよびプロトコルに従って動作を実行することができる。プロキシ・サーバ２０６はプロキシ許可制御機能ユニット２１０を含み、これは、プロキシ化許可制御とも呼ばれるプロキシ許可制御を発生させる。これらの制御がプロキシ・サーバ２０６によって用いられて、クライアント・アプリケーション２０４のために、または同様にユーザ２０２のために、分散型ディレクトリに関する動作を実行する。Wahl等の「LightweightDirectory Access Protocol（v3）」、ＩＥＴＦ ＲＦＣ２２５１（１９９７年１２月）において記載されているように、制御は、ＬＤＡＰ動作と共に用いるための拡張情報を規定する方法である。制御は、ＬＤＡＰ要求の一部として送信され、それに伴う要求のみに適用することができる。サーバが制御タイプを認識し、それが動作に適切である場合、要求された動作を実行する際にサーバは制御を利用する。様々な任意のパラメータを用いて、制御が認識されないかまたは不適切である場合にそれを無視するか否かを、サーバに知らせることができる。また、制御は、割り当てられたオブジェクト識別子を含む。

従って、プロキシ許可制御機能ユニット２１０は、入力パラメータとしてプロキシ識別名（ＤＮ）を受け入れるアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供することができる。この入力パラメータは、クライアント・アプリケーション２０４またはユーザ２０２のために動作を実行する際にプロキシ・サーバ２０６が想定するアイデンティティの項目のＤＮを特定する。提供されたＡＰＩを呼び出し側が用いて、プロキシ許可アイデンティティを含むＬＤＡＰ制御を生成することができる。次いで、生成されたプロキシ許可制御をＬＤＡＰ動作に含ませて、ディレクトリ・サーバから動作を要求する。このプロキシ許可制御機構を用いて、クライアント、またはこの場合にはプロキシ・サーバ２０６は、それ自身のアイデンティティを用いてディレクトリ・エンジンにバインドすることができるが、別のユーザすなわちユーザ２０２またはクライアント・アプリケーション２０４のプロキシ許可権を与えられてターゲット・ディレクトリにアクセスする。ＬＤＡＰサーバがプロキシ許可制御を有する動作要求を受信すると、バインドＤＮが管理グループあるいは既定のプロキシ認証グループに対して有効になって、バインドＤＮにプロキシ許可権を与えるか否かが判定される。換言すると、この例ではプロキシ・サーバ２０６であるバインドされたアプリケーション・クライアントは、プロキシ許可動作を要求するために、管理グループまたはプロキシ許可グループのメンバでなければならない。プロキシ許可制御を用いることに関する更に詳しい情報は、Weltmanの「LDAP ProxiedAuthorization Control」、ＩＥＴＦ Internet-Draft、draft-weltman-ldapv3-proxy-l2.txt（２００３年４月）において見ることができる。また、ＬＤＡＰプロトコルは、拡張機構をサポートして、ＬＤＡＰ仕様内で規定されないサービスについて追加動作を規定することができる。拡張動作によって、クライアントは、特定の実施に限定されている場合がある既定のシンタクスおよびセマンティクスを用いて要求を行い応答を受信することができる。

分散型ディレクトリ環境は、複数のディレクトリ・サーバ２１２〜２１６を含み、これらは、例えば図１および図３に示した分散型データ処理環境と同様に、プロキシ・サーバ２０６およびクライアント・アプリケーション２０４と同じ分散型データ処理環境内で相互協調する。ディレクトリ・サーバ２１２〜２１６は、分散型ディレクトリの一部、すなわち、分散型ディレクトリ・データストア２１８〜２２２として示すディレクトリ情報ツリーの一部を含むデータストアにアクセスするための機能をサポートする。また、ディレクトリ・サーバ２１２〜２１６は、例えばプロキシ・サーバ２０６または他のディレクトリ・クライアントによって送信することができるプロキシ化許可制御の受信および処理をサポートするという、図４には図示しない機能も含む。

先に記載した状況と同様の方法で、特定のディレクトリ動作に関して対象となるユーザ項目、グループ項目、およびターゲット・オブジェクト項目は、異なるシステム上でサポートされる分散型ディレクトリの異なる部分に存在する場合がある。図４に示す例では、ターゲット・オブジェクト項目２２４は分散型ディレクトリ・データストア２１８内にあり、ユーザ項目２２６は分散型ディレクトリ・データストア２２０内にあり、グループ項目２２８は分散型ディレクトリ・データストア２２２内にある。

ここで図５を参照すると、このブロック図は、本発明の一実施形態に従った、グループ・メンバーシップを考慮してディレクトリ・アクセス許可をサポートするための機能を含むように拡張した分散型ディレクトリ環境を示す。図５は図４と同様であり、同様の参照番号は同様の要素を示す。しかしながら、図４とは異なり、図５は本発明の実施形態をサポートするための追加の機能も示す。

図５は、本発明に従って分散型ディレクトリ環境を拡張させる２つの機構を含む例示的な実施形態を示す。第１の機構は、ユーザの識別名および１組の属性が与えられた場合に、グループ・メンバーシップを評価するために、分散型ディレクトリ環境内でディレクトリ・サーバに対する要求をサポートする機能から成る。この機構によって、同一サーバ上のユーザ項目なしで、グループ・メンバーシップの評価が可能となる。例えば、アプリケーションがユーザのための動作を実行している場合、この機構を用いて、ユーザが属する分散型ディレクトリ内のグループを決定することができる。

第２の機構は、ディレクトリ動作を実行するためにディレクトリ・サーバに対する要求をサポートする機能から成り、その一方で、ディレクトリ動作に対する要求と共に提供されたユーザ・グループ・メンバーシップに関する情報内で示されるように１組のグループに特定のユーザが属することの表明を受け入れる。例えば、いったんユーザが１組のグループに属すると判定されると、それ以降、グループ識別名およびグループ属性等のこれらのグループに関する情報を、ユーザのためのディレクトリ動作に対する全ての要求において送信することができ、これによって、許可アクセスを決定するための必要な情報が全てローカルにあるかのように、ユーザに同じ有効な許可アクセスを与える。換言すると、ユーザはそれ以降、必要なグループ項目が全て同一のディレクトリ・サーバ上にストアされている場合に有するのと同じアクセスを有する。

図５は、これらの２つの機構がプロキシ・ディレクトリ・サーバ内および１つ以上のディレクトリ・サーバ内の機能ユニットによって表される例示的な実施形態を示す。第１の機構は、ディレクトリ・サーバ上の対応するコンポーネントと共にプロキシ・サーバ２０６上のマルチサーバ・グループ・メンバーシップ・コンパイル機能ユニット２５０、ディレクトリ・サーバ２１２上のグループ・メンバーシップ評価機能ユニット（ＧＭＥＦＵ）２５２、ディレクトリ・サーバ２１４上のＧＭＥＦＵ２５４、およびディレクトリ・サーバ２１６上のＧＭＥＦＵ２５６によってサポートされる。第１の機構は、新規の拡張ディレクトリ動作を用い、これはプロキシ・サーバによって用いられて、所与のユーザについてグループ・メンバーシップを決定および評価することができる。ディレクトリ・サーバがプロキシ・サーバから拡張動作要求を受信すると、ディレクトリ・サーバはそのバックエンド・データストアにアクセスして、グループ・メンバーシップを決定する。この機構についての詳細は、残りの図面を参照して以下で説明する。

第２の機構は、ディレクトリ・サーバ上の対応するコンポーネントと共にプロキシ・サーバ２０６上のグループ表明制御発生機能ユニット２６０、ディレクトリ・サーバ２１２上のグループ表明制御処理機能ユニット（ＧＡＣＰＦＵ）２６２、ディレクトリ・サーバ２１４上のＧＡＣＰＦＵ２６４、ディレクトリ・サーバ２１６上のＧＡＣＰＦＵ２６６によってサポートされる。第２の機構は、本発明ではグループ表明制御と呼ぶ新規の制御を用い、これは、プロキシ・サーバによっていずれかのディレクトリ動作と関連付けて用いることができる。好適な実施形態において、グループ表明制御は、ＬＤＡＰ制御に従ってフォーマット化して処理することができる。ディレクトリ・サーバがディレクトリ動作要求と共にプロキシ・サーバからグループ表明制御を受信すると、ディレクトリ・サーバは、識別されたユーザ、すなわちディレクトリ動作を実行しているアイデンティティが、１組の識別されたグループ、すなわちグループ表明制御内で指定された１組のグループに属すると想定する。ディレクトリ・サーバが、分散型ディレクトリ環境内でのディレクトリ・サーバとプロキシ・サーバとの間の暗示的または明示的な信頼関係に基づいてグループ表明制御を受け入れると想定することができる。グループ表明制御を受信した後、ディレクトリ・サーバは、表明されたグループ組に基づいて分散型ディレクトリにアクセスするための全ての許可判定を実行する。グループ表明制御をプロキシ認証制御と共に用いて、グループ表明制御およびプロキシ許可制御を同一のディレクトリ動作に関連付けて用いるようにすることができる。同一のディレクトリ動作に関して２つの制御が用いられた場合、ディレクトリ・サーバは、識別されたユーザの１組のグループ・メンバーシップを考慮して、与えられたユーザ・アイデンティティのために要求されたディレクトリ動作を実行する。この機構についてのこれ以上の詳細は、残りの図面を参照して以下で説明する。

ここで図６を参照すると、このブロック図は、クライアントまたはクライアント・アプリケーションとディレクトリ・プロキシ・サーバとの間の典型的なデータフローを示す。クライアント３０２は、プロキシ・サーバ３０６に、ディレクトリ動作についての要求を表す要求メッセージ３０４を送信する。要求されたディレクトリ動作を実行した後、プロキシ・サーバ３０６は、クライアント３０２に、要求されたディレクトリ動作についての応答を表す応答メッセージ３０８を戻す。次いで、クライアント３０２は、受信した情報について何らかの追加の計算タスクを実行する。このように、クライアントとディレクトリ・プロキシ・サーバとの間のディレクトリ動作に関する要求および応答の交換は、典型的な分散型ディレクトリ環境内で行われるデータフローと類似している。プロキシ・サーバ３０６は、ディレクトリ動作が実行されているユーザまたはクライアントについての認証動作（図示せず）を実行するためのユーザ・アイデンティティおよびいずれかの必要な認証証明書を取得しているかまたは以前にキャッシュしていると想定することができる。

ここで図７を参照すると、このブロック図は、本発明の一実施形態に従って所与のユーザのグループ・メンバーシップに関する情報を取得するための、ディレクトリ・プロキシ・サーバとディレクトリ・サーバとの間のデータフローを示す。プロキシ・サーバ３１２は、要求メッセージ３１６をディレクトリ・サーバ３１４に送信する。要求メッセージ３１６は、ディレクトリ・サーバ３１４がサポートするディレクトリ情報ツリーの一部にストアされた情報に関して、識別されたユーザが属するグループを判定するためのディレクトリ・サーバ３１４に対する要求を表す。要求メッセージ３１６は、特定のユーザを識別するためのユーザＤＮ３１８を含み、また、ディレクトリ・サーバ３１４がサポートするデータストアにローカルに存在するグループ項目を考慮してグループ・メンバーシップ判定を実行するための、特定のユーザについてのユーザ属性３２０も含む。ディレクトリ・サーバ３１４が、識別されたユーザについて適切な１組のグループ・メンバーシップを判定した後、ディレクトリ・サーバ３１４は、プロキシ・サーバ３１２に、以前に指定したユーザのグループ評価判定についての応答を表す応答メッセージ３２２を戻す。応答メッセージ３２２は、１組のグループＤＮ３２４を含み、更に、好ましくは、付随するグループＤＮについての１組の対応するグループ属性３２６を含む。また、応答メッセージ３２２は、ユーザＤＮ３１８よびユーザ属性３２０を返すことができる。分散型ディレクトリ環境内のメッセージは、必要に応じて、暗号によって保護すると想定することができる。

このように、プロキシ・サーバおよびディレクトリ・サーバが要求および応答を交換することで、プロキシ・サーバは、ディレクトリ・サーバ３１４等の特定のディレクトリ・サーバに既知の１組のグループ・メンバーシップをユーザのために取得することができる。しかしながら、分散型ディレクトリ環境では、ディレクトリ・サーバ３１４は、例えば複数のディレクトリ・サーバを示す図５に示すように、多くのデータストア間で物理的に分割されたディレクトリ情報ツリーをサポートする複数のディレクトリ・サーバの１つである。従って、以下で更に詳細に記載するように、プロキシ・サーバは、所与のユーザのグループ・メンバーシップを全て判定するために、分散型ディレクトリ環境内の各ディレクトリ・サーバにグループ・メンバーシップ評価要求を送信し、これは、分散型ディレクトリを含むデータストア全体に広がるグループ項目に反映させることができる。

ここで図８を参照すると、このブロック図は、本発明の一実施形態に従って、識別したユーザまたはクライアントおよびその関連グループ・メンバーシップに関して、ディレクトリ動作を実行するための、ディレクトリ・プロキシ・サーバとディレクトリ・サーバとの間のデータフローを示す。図７および図８における同様の参照番号は同様の要素を示す。プロキシ・サーバ３１２は、要求メッセージ３３２をディレクトリ・サーバ３１４に送信する。要求メッセージ３３２は、識別したユーザについて与えられた情報に関してディレクトリ動作を実行するためのディレクトリ・サーバ３１４に対する要求を表す。

図８に示すようなディレクトリ動作を要求するために用いられる要求メッセージ３３２は、図６に示すようなディレクトリ動作を要求するために用いられる要求メッセージ３０４と同一ではないことに留意すべきである。要求メッセージ３０４は、要求メッセージ３０４からコピーした情報を含むように、変更、コピーおよび変更、または発生されている。従って、要求メッセージ３３２は、最初に要求されたディレクトリ動作を実行するための要求メッセージ３０４からのあらゆる必要な情報を含む。更に、要求メッセージ３３２はプロキシ許可制御３３４を含み、これは、特定のユーザを識別するためのユーザＤＮ３１８を含み、更に、この特定のユーザのためのユーザ属性３２０も含む。ディレクトリ・サーバ３１４がプロキシ許可制御３３４を受け入れることによって、プロキシ・サーバ３１２は、例えば図６のクライアント３０２のようなクライアントのためのプロキシ・エンージェントとして機能することができる。換言すると、プロキシ許可制御３３４は、例えばディレクトリ・サーバ３１４のような受信側ディレクトリ・サーバに対して、ディレクトリ・サーバ３１４がクライアント３０２から直接要求メッセージ３３２を受信したかのように、要求メッセージ３３２によって表されるディレクトリ動作をプロキシ・サーバ３１２が要求する許可を受けていることを知らせる。

本発明の新規の機能に従って、要求メッセージ３３２は、グループ表明制御３３６も含む。上述のように、プロキシ・サーバ３１２は、例えば図７に関して上述したような要求／応答交換を用いることによって、識別したユーザのグループ・メンバーシップに関する情報をあらかじめ収集している。ここで、プロキシ・サーバ３１２は、ディレクトリ動作の要求と共にグループ表明制御３３６を送信することによって、ディレクトリ動作の間にこの蓄積したグループ・メンバーシップ情報を表明する。グループ表明制御３３６は、１組のグループＤＮ３３８を含み、好ましくは、付随するグループＤＮのための１組の対応するグループ属性３４０も含む。グループ表明制御は、オブジェクトＩＤ（ＯＩＤ）等のいずれかの他の適切な情報も含むことができる。場合によっては、要求メッセージ３３２における１組のグループＤＮおよびグループ属性は、図７の応答メッセージ３２２の１組のグループＤＮおよびグループ属性と同一である場合がある。しかしながら、それらは同一でない可能性が高い。なぜなら、グループ表明制御３３６におけるグループ・メンバーシップ情報は、ディレクトリ・サーバ３１４を含む１つ以上のディレクトリ・サーバから検索したゼロ以上のグループＤＮを含むからである。

要求されたディレクトリ動作を実行した後、ディレクトリ・サーバ３１４は、応答メッセージ３４２をプロキシ・サーバ３１２に送信する。応答メッセージ３４２はディレクトリ動作の結果を含み、これは失敗情報を含む場合がある。プロキシ・サーバ３１２は、応答メッセージ３４２を処理し、例えば図６に示すように要求側クライアントに応答メッセージを戻す。

ここで図９を参照すると、このフローチャートは、本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについてのディレクトリ動作中にこの所与のユーザに関する１組のグループ・メンバーシップを後に用いるためにコンパイルするプロキシ・サーバにおけるプロセスを示す。このプロセスは、ディレクトリ・プロキシ・サーバが所与のユーザに関して認証動作を実行することを決定すると開始する（ステップ４０２）。この決定は、図９には図示しない以前のイベントによってトリガされ、このプロセスは、図９には図示しない追加のステップによって終了することができる。例えば、プロキシ・サーバは、クライアント・アプリケーションから、分散型ディレクトリ環境にログインする要求を受信する場合がある。別の例では、プロキシ・サーバは最初のディレクトリ動作についての要求を受信するが、プロキシ・サーバが要求側ユーザのための認証証明書を有しないと判定された後、プロキシ・サーバはユーザに関して認証動作を実行することを決定する。図９の認証動作は、ユーザ名−パスワード検証プロセスを示すが、例えばデジタル証明書に基づいた認証動作のような別のタイプの認証動作も実行可能である。

プロキシ・サーバは、例えばクライアント・アプリケーションとのインタラクションによって、ユーザのためのユーザ名およびパスワードの組み合わせを取得する（ステップ４０４）。プロキシ・サーバは、分散型ディレクトリを検索して、適切なユーザ項目を見つけて取り出し（ステップ４０６）、以前に取得したユーザ・パスワードを、ユーザ項目内にストアしたユーザ・パスワードに対して照合する（ステップ４０８）。パスワードが確認されない場合、何らかのタイプのエラーを報告し、プロセスを終了する。その他の場合、パスワードが確認されたと仮定すると、プロキシ・サーバは以降の使用のためにユーザ項目をキャッシュする（ステップ４１０）。

ステップ４０２〜４１０に示す認証関連手順は、一般的に、多くのディレクトリ環境内で実行される。しかしながら、図９は、本発明の一実施形態に従って実行される新規のステップも示す。

プロキシ・サーバは、その分散型ディレクトリ環境内の分散型ディレクトリ・サーバのリストを検索する（ステップ４１２）。このリストは、プロキシ・サーバのためのコンフィギュレーション・ファイルを含むいずれかの適切な位置から検索することができる。次いで、プロキシ・サーバは、ディレクトリ・サーバのリストを進んでいき、リスト内の各ディレクトリ・サーバに関して一連のステップを実行する。

プロキシ・サーバは、リスト内の次のディレクトリ・サーバに関する情報を検索する（ステップ４１４）。このディレクトリ・サーバは、プロキシ・サーバの現在のアクションに関して現在のディレクトリ・サーバと見なされる。現在のディレクトリ・サーバに関する検索された情報は様々な情報を含み得る。すなわち、ディレクトリ・サーバの識別子、ディレクトリ・サーバに接触するために用いられるプロトコル、ディレクトリ・サーバに接触するために用いられるアドレス、および、プロキシ・サーバに様々な動作をどのように実行するかを通知するために特定の分散型ディレクトリ環境内で使用可能ないずれかの他の情報である。次いで、プロキシ・サーバは、ユーザのグループ・メンバーシップを取得するために、現在のディレクトリ・サーバに拡張動作要求を送信する（ステップ４１６）。拡張動作要求は、ユーザのためのユーザＤＮおよびユーザ属性を含む。ある時点で、プロキシ・サーバは、現在のディレクトリ・サーバからいずれかのグループ・メンバーシップ情報を受信する（ステップ４１８）。グループ情報は、１組のグループＤＮおよび１組のグループ属性と共に、他のいずれかの適切な情報を含む。

次いで、プロキシ・サーバは、ディレクトリ・サーバのリストに他のディレクトリ・サーバがあるか否かを調べる（ステップ４２０）。ある場合、プロセスはステップ４１４に戻り、異なるディレクトリ・サーバに関するグループ・メンバーシップ情報の検索を行う。それ以上ディレクトリ・サーバが存在しない場合、プロキシ・サーバはユーザのグループ・メンバーシップ・リストをコンパイルする（ステップ４２２）。グループ・メンバーシップに関する情報は、以降のディレクトリ動作のために、ユーザについてのユーザＤＮに関連付けてキャッシュされ（ステップ４２４）、プロセスは終了する。

ここで図１０を参照すると、このフローチャートは、本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについて１組のグループ・メンバーシップを用いながら要求されたディレクトリ動作を実行するためのプロキシ・サーバにおけるプロセスを示す。このプロセスは、ディレクトリ・プロキシ・サーバがクライアント・アプリケーションからディレクトリ動作についての要求を受信すると開始する（ステップ５０２）。分散型ディレクトリ動作がセキュアな動作をサポートまたは要求する場合、プロキシ・サーバは要求側クライアントまたはそのユーザをすでに認証していると想定することができる。そうでない場合、例えば図９に示すように、ステップ５０２の後に認証動作を実行することができる。次いで、プロキシ・サーバは、ディレクトリ動作が要求されているユーザのユーザＤＮおよびユーザ属性を検索し（ステップ５０４）、プロキシ・サーバは、後にディレクトリ・サーバに送信するディレクトリ要求内に含ませるプロキシ許可制御を発生する（ステップ５０６）。

ステップ５０２〜５０６に示すプロキシ関連手順は、一般的に、多くのディレクトリ環境内で実行される。しかしながら、図１０は、本発明の一実施形態に従って実行される新規のステップも示す。

プロキシ・サーバは、ユーザのためのグループ・メンバーシップ情報を以前にキャッシュしており（ステップ５０８）、次いで、ユーザのグループ・メンバーシップ情報を含むグループ表明制御を発生する（ステップ５１０）。プロキシ・サーバは、発生したプロキシ認証制御および発生したグループ表明制御を含むディレクトリ要求を生成する（ステップ５１２）。プロキシ・サーバは、そのディレクトリ要求を必要に応じて１つ以上のディレクトリ・サーバに送信する（ステップ５１４）。ある時点で、プロキシ・サーバは、例えばステップ５１４に関した動作に対して適宜、１つ以上のディレクトリ・サーバからディレクトリ応答を受信する（ステップ５１６）。次いで、プロキシ・サーバは、ディレクトリ応答を発生して要求側クライアント・アプリケーションに送信し（ステップ５１８）、プロセスは終了する。

ここで図１１を参照すると、このフローチャートは、本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについてディレクトリ・プロキシ・サーバによって提供された１組のグループ・メンバーシップを用いながら要求されたディレクトリ動作を実行するためのディレクトリ・サーバにおけるプロセスを示す。このプロセスは、ディレクトリ・サーバがディレクトリ・プロキシ・サーバからディレクトリ動作についての要求を受信すると開始する（ステップ６０２）。ディレクトリ・サーバは、受信したディレクトリ動作要求から、プロキシ許可制御およびグループ表明制御を認識して取得する（ステップ６０４）。次いで、ディレクトリ・サーバは、何らかの方法でプロキシ許可制御を検証する（ステップ６０６）。検証が失敗すると、何らかのタイプのエラーが報告されるか、あるいは戻される、またはその両方が実行される。プロキシ許可制御が確認されると、ディレクトリ・サーバは、プロキシ許可制御内で識別されたユーザに関して以降の動作を実行する。

次いで、ディレクトリ・サーバは、グループ表明制御からグループ・メンバーシップ情報を取得する（ステップ６０８）。ディレクトリ・サーバは、識別されたユーザのために、グループ・メンバーシップ情報に関して要求されたディレクトリ動作を実行する（ステップ６１０）。ディレクトリ動作の結果についての情報は、発生したディレクトリ応答内にストアされる（ステップ６１２）。ディレクトリ応答を要求側のプロキシ・サーバに送信し（ステップ６１４）、これによってプロセスを終了する。

本発明の利点は、上述の詳細な説明を考慮すれば明らかであろう。ディレクトリ・サーバがディレクトリ動作についての要求内でグループ表明制御を受信した場合、グループ表明制御は以前に評価された所与のユーザのグループ・メンバーシップに関する情報を含む。次いで、ディレクトリ・サーバは、ディレクトリ情報ツリーのその部分内にストアされた情報を用い、例えば１組のグループＤＮおよび関連するグループ属性のような受信したグループ・メンバーシップ情報を用いて、要求されたディレクトリ動作を実行することができる。

要求されたディレクトリ動作が、特定グループのユーザのみにアクセスが限定されているディレクトリ情報ツリーの部分に対するアクセスを必要とする場合、ディレクトリ・サーバは、ユーザがその特定のグループに属するか否かを判定する機能を有する。従って、本発明は、分散型ディレクトリ環境におけるアクセスを決定するために、更にデータ複製を行う必要なく、また、分散型ディレクトリの部分のストレージ位置を更に制限する必要なく、分散型ディレクトリをサポートするように、所与のユーザについてのグループ・メンバーシップの評価をサポートする機構を提供する。

本発明は、充分に機能するデータ処理システムの状況において説明したが、本発明に関連するプロセスの一部は、コンピュータ読み取り可能媒体において命令の形態で、および様々な他の形態で分散させることができ、その分散を行うために実際に用いる信号記録媒体の特定のタイプには無関係であることは、当業者には認められよう。コンピュータ読み取り可能媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭ等の媒体、デジタルおよびアナログ通信リンク等の伝送型の媒体が含まれる。

本発明の記載は、例示の目的で与えるものであり、網羅的であったり開示する実施形態を限定したりすることは意図していない。当業者には、多くの変更および変形が明らかであろう。実施形態は、本発明の原理およびその実際の応用を説明するため、ならびに、当業者が本発明を理解して、他の考えられる使用に適切であるような様々な変更と共に様々な実施形態を実施することができるように選んだものである。

本発明を実施可能な典型的な分散型データ処理システムを示す。 本発明を実施可能なデータ処理システム内で用いることができる典型的なコンピュータ・アーキテクチャを示す。 企業領域の典型的な分散型データ処理システムを示すブロック図である。 典型的な分散型ディレクトリ環境を示すブロック図である。 本発明に従って、グループ・メンバーシップを考慮してディレクトリ・アクセス許可をサポートするための機能を含むように拡張した分散型ディレクトリ環境を示すブロック図である。 クライアントまたはクライアント・アプリケーションとディレクトリ・プロキシ・サーバとの間の典型的なデータフローを示すブロック図である。 本発明の一実施形態に従って所与のユーザのグループ・メンバーシップに関する情報を取得するための、ディレクトリ・プロキシ・サーバとディレクトリ・サーバとの間のデータフローを示すブロック図である。 本発明の一実施形態に従って、識別したユーザまたはクライアントおよびその関連グループ・メンバーシップに関して、ディレクトリ動作を実行するための、ディレクトリ・プロキシ・サーバとディレクトリ・サーバとの間のデータフローを示すブロック図である。 本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについてのディレクトリ動作中にこの所与のユーザに関する１組のグループ・メンバーシップを後に用いるためにコンパイルするプロキシ・サーバにおけるプロセスを示すフローチャートである。 本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについて１組のグループ・メンバーシップを用いながら要求されたディレクトリ動作を実行するためのプロキシ・サーバにおけるプロセスを示すフローチャートである。 本発明の一実施形態に従った、分散型ディレクトリ環境内で所与のユーザについてディレクトリ・プロキシ・サーバによって提供された１組のグループ・メンバーシップを用いながら要求されたディレクトリ動作を実行するためのディレクトリ・サーバにおけるプロセスを示すフローチャートである。

Claims (27)

1. 分散型ディレクトリ環境内でディレクトリ動作を実行するための方法であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記方法が、
   前記ディレクトリ・サーバがサポートする分散型ディレクトリの一部内のグループ項目に関するグループ・メンバーシップを前記ディレクトリ・サーバが判定するユーザを指示する第１の要求をプロキシ・サーバからディレクトリ・サーバに送信するステップと、
   前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバにおいて受信するステップと、
   前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記１組の識別名および属性を前記プロキシ・サーバにおいてストアするステップと、
   を含む、方法。
2. ディレクトリ・アクセス・プロトコル内で拡張動作を用いてディレクトリ・サーバから情報を要求し受信することによって、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するステップを更に含む、請求項１に記載の方法。
3. 前記分散型ディレクトリ環境内の各ディレクトリ・サーバから、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するステップを更に含む、請求項１または２に記載の方法。
4. 前記分散型ディレクトリ環境内の複数のディレクトリ・サーバからの応答に基づいて、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についてのコンパイルした１組の識別名および属性を発生させるステップを更に含む、請求項１、２、または３に記載の方法。
5. 前記プロキシ・サーバからディレクトリ・サーバに第２の要求を送信するステップを更に含み、前記第２の要求が前記ユーザのために実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含む、請求項４に記載の方法。
6. 前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含み、ディレクトリ・アクセス・プロトコルに従ってフォーマット化されている制御を発生させるステップと、
   発生させた制御を前記第２の要求に配置するステップと、
   を更に含む、請求項５に記載の方法。
7. 分散型ディレクトリ環境内でディレクトリ動作を実行するための方法であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記方法が、
   ユーザについての識別名および属性を含む第１の要求をプロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて受信するステップと、
   前記ユーザについての前記識別名および属性に関して、および、前記ディレクトリ・サーバがサポートするディレクトリ情報ツリーにおけるグループ項目に関して、前記ユーザについてのグループ・メンバーシップを評価するステップと、
   前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第１の組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバに送信するステップと、
   を含む、方法。
8. プロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて第２の要求を受信するステップを更に含み、前記第２の要求が前記ディレクトリ・サーバによって実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第２の組の識別名および属性を含み、前記第２の要求が前記ユーザについての識別名および属性を含む、請求項７に記載の方法。
9. 前記ディレクトリ・サーバがサポートする前記ディレクトリ情報ツリー、前記ユーザについての前記識別名および属性、ならびに、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記第２の組の識別名および属性に関して、前記ディレクトリ動作を実行するステップと、
   前記ディレクトリ動作を実行した後、前記ディレクトリ・サーバから前記プロキシ・サーバに第２の応答を送信するステップと、
   を更に含む、請求項８に記載の方法。
10. 分散型ディレクトリ環境内でディレクトリ動作を実行するためのコンピュータ読み取り可能媒体上のコンピュータ・プログラム製品であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記コンピュータ・プログラム製品が、
    前記ディレクトリ・サーバがサポートする分散型ディレクトリの一部内のグループ項目に関するグループ・メンバーシップを前記ディレクトリ・サーバが判定するユーザを指示する第１の要求をプロキシ・サーバからディレクトリ・サーバに送信するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバにおいて受信するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記１組の識別名および属性を前記プロキシ・サーバにおいてストアするための手段と、
    を含む、コンピュータ・プログラム製品。
11. ディレクトリ・アクセス・プロトコル内で拡張動作を用いてディレクトリ・サーバから情報を要求し受信することによって、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するための手段を更に含む、請求項１０に記載のコンピュータ・プログラム製品。
12. 前記分散型ディレクトリ環境内の各ディレクトリ・サーバから、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するための手段を更に含む、請求項１０または１１に記載のコンピュータ・プログラム製品。
13. 前記分散型ディレクトリ環境内の多数のディレクトリ・サーバからの応答に基づいて、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についてのコンパイルした１組の識別名および属性を発生させるための手段を更に含む、請求項１０、１１、または１２に記載のコンピュータ・プログラム製品。
14. 前記プロキシ・サーバからディレクトリ・サーバに第２の要求を送信するための手段を更に含み、前記第２の要求が前記ユーザのために実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含む、請求項１３に記載のコンピュータ・プログラム製品。
15. 前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含み、ディレクトリ・アクセス・プロトコルに従ってフォーマット化されている制御を発生させるための手段と、
    発生させた制御を前記第２の要求に配置するための手段と、
    を更に含む、請求項１４に記載のコンピュータ・プログラム製品。
16. 分散型ディレクトリ環境内でディレクトリ動作を実行するためのコンピュータ読み取り可能媒体上のコンピュータ・プログラム製品であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記コンピュータ・プログラム製品が、
    ユーザについての識別名および属性を含む第１の要求をプロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて受信するための手段と、
    前記ユーザについての前記識別名および属性に関して、および、前記ディレクトリ・サーバがサポートするディレクトリ情報ツリーにおけるグループ項目に関して、前記ユーザについてのグループ・メンバーシップを評価するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第１の組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバに送信するための手段と、
    を含む、コンピュータ・プログラム製品。
17. プロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて第２の要求を受信するための手段を更に含み、前記第２の要求が前記ディレクトリ・サーバによって実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第２の組の識別名および属性を含み、前記第２の要求が前記ユーザについての識別名および属性を含む、請求項１６に記載のコンピュータ・プログラム製品。
18. 前記ディレクトリ・サーバがサポートする前記ディレクトリ情報ツリー、前記ユーザについての前記識別名および属性、ならびに、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記第２の組の識別名および属性に関して、前記ディレクトリ動作を実行するための手段と、
    前記ディレクトリ動作を実行した後、前記ディレクトリ・サーバから前記プロキシ・サーバに第２の応答を送信するための手段と、
    を更に含む、請求項１７に記載のコンピュータ・プログラム製品。
19. 分散型ディレクトリ環境内でディレクトリ動作を実行するための装置であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記装置が、
    前記ディレクトリ・サーバがサポートする分散型ディレクトリの一部内のグループ項目に関するグループ・メンバーシップを前記ディレクトリ・サーバが判定するユーザを指示する第１の要求をプロキシ・サーバからディレクトリ・サーバに送信するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバにおいて受信するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記１組の識別名および属性を前記プロキシ・サーバにおいてストアするための手段と、
    を含む、装置。
20. ディレクトリ・アクセス・プロトコル内で拡張動作を用いてディレクトリ・サーバから情報を要求し受信することによって、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するための手段を更に含む、請求項１９に記載の装置。
21. 前記分散型ディレクトリ環境内の各ディレクトリ・サーバから、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての１組の識別名および属性を前記プロキシ・サーバにおいて取得するための手段を更に含む、請求項１９に記載の装置。
22. 前記分散型ディレクトリ環境内の多数のディレクトリ・サーバからの応答に基づいて、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についてのコンパイルした１組の識別名および属性を発生させるための手段を更に含む、請求項１９に記載の装置。
23. 前記プロキシ・サーバからディレクトリ・サーバに第２の要求を送信するための手段を更に含み、前記第２の要求が前記ユーザのために実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含む、請求項２２に記載の装置。
24. 前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記コンパイルした１組の識別名および属性を含み、ディレクトリ・アクセス・プロトコルに従ってフォーマット化されている制御を発生させるための手段と、
    発生させた制御を前記第２の要求に配置するための手段と、
    を更に含む、請求項２３に記載の装置。
25. 分散型ディレクトリ環境内でディレクトリ動作を実行するための装置であって、前記分散型ディレクトリ環境が、１つ以上の分散型ディレクトリ・サーバおよび、クライアントと前記分散型ディレクトリ環境との間の中間エージェントとして機能するプロキシ・サーバを含み、前記装置が、
    ユーザについての識別名および属性を含む第１の要求をプロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて受信するための手段と、
    前記ユーザについての前記識別名および属性に関して、および、前記ディレクトリ・サーバがサポートするディレクトリ情報ツリーにおけるグループ項目に関して、前記ユーザについてのグループ・メンバーシップを評価するための手段と、
    前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第１の組の識別名および属性を含む第１の応答を前記ディレクトリ・サーバから前記プロキシ・サーバに送信するための手段と、
    を含む、装置。
26. プロキシ・サーバから前記分散型ディレクトリ環境内のディレクトリ・サーバにおいて第２の要求を受信するための手段を更に含み、前記第２の要求が前記ディレクトリ・サーバによって実行されるディレクトリ動作を指示し、前記第２の要求が、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての第２の組の識別名および属性を含み、前記第２の要求が前記ユーザについての識別名および属性を含む、請求項２５に記載の装置。
27. 前記ディレクトリ・サーバがサポートする前記ディレクトリ情報ツリー、前記ユーザについての前記識別名および属性、ならびに、前記ユーザがグループ・メンバーシップを有するグループを表すグループ項目についての前記第２の組の識別名および属性に関して、前記ディレクトリ動作を実行するための手段と、
    前記ディレクトリ動作を実行した後、前記ディレクトリ・サーバから前記プロキシ・サーバに第２の応答を送信するための手段と、
    を更に含む、請求項２６に記載の装置。

Images