(57)【特許請求の範囲】
【請求項１】
サービスを提供する複数のサービス提供端末と、前記サービス提供端末が提供するサービスを利用するクライアント端末とにそれぞれ接続されるアクセス制御付ディレクトリ機能装置であって、
前記サービス提供端末で提供されるサービスを利用可能な利用者についての許可利用者情報と、そのサービス提供端末がサービスを提供する際に利用するサービスを記録した依存サービス情報とを含むアクセス制御リストをそれぞれ前記複数のサービス提供端末から受信する受信手段と、
前記受信手段により受信したサービス提供端末のアクセス制御リストに含まれる許可利用者情報と、そのアクセス制御リストに含まれる依存サービス情報に記録されているサービスを提供する他のサービス提供端末についての許可利用者情報とに基づいて、利用者がサービスを利用可能であるか否かについての統合アクセス制御リストを作成する統合アクセス制御リスト作成手段と、
を有することを特徴とするアクセス制御付ディレクトリ機能装置。
【請求項２】
前記クライアント端末を使用する利用者に対して、前記サービス提供端末が提供するサービスを提供するか否かについて、前記統合アクセス制御リスト作成手段が作成した統合アクセス制御リストを参照することにより、当該利用者がサービスを利用可能か否かについて決定するアクセス制御手段を更に有することを特徴とする請求項１記載のアクセス制御付ディレクトリ機能装置。
【請求項３】
前記アクセス制御手段により利用者がサービスを利用可能であると決定した場合には、当該サービスの利用許可証を発行するとともに、当該サービスの依存サービス情報に記録されているサービスの利用許可証を発行するサービス利用許可証発行手段を更に有することを特徴とする請求項２記載のアクセス制御付ディレクトリ機能装置。
【請求項４】
コンピュータをアクセス制御付ディレクトリ機能装置として動作させるためのプログラムであって、
コンピュータに、
サービス提供端末で提供されるサービスを利用可能な利用者についての許可利用者情報と、そのサービス提供端末がサービスを提供する際に利用するサービスを記録した依存サービス情報とを含むアクセス制御リストをそれぞれ複数のサービス提供端末から受信させる第１のステップと、
前記第１のステップで受信したサービス提供端末のアクセス制御リストに含まれる許可利用者情報と、そのアクセス制御リストに含まれる依存サービス情報に記録されているサービスを提供する他のサービス提供端末についての許可利用者情報とに基づいて、利用者がサービスを利用可能であるか否かについての統合アクセス制御リストを作成させる第２のステップと、
を実行させるプログラム。
【請求項５】
コンピュータに、
クライアント端末を使用する利用者に対して、前記サービス提供端末が提供するサービスを提供するか否かについて、前記第２のステップで作成した統合アクセス制御リストを参照することにより、当該利用者がサービスを利用可能か否かについて決定する第３のステップを更に実行させる請求項４記載のプログラム。
【請求項６】
コンピュータに、
前記第３のステップで利用者がサービスを利用可能であると決定された場合には、当該サービスの利用許可証を発行するとともに、当該サービスの依存サービス情報に記録されているサービスの利用許可証を発行する第４のステップを更に実行させる請求項５記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアント端末にネットワーク上の各種サービスを提供するアクセス制御付ディレクトリ機能装置及びプログラムに関する。
【０００２】
【従来の技術】
従来より、サービスに対するアクセス制御リスト（ＡＣＬ：Access Control List）をディレクトリ機能に持たせて一元管理し、ディレクトリ機能がアクセス制御を実施することが行なわれていた。これは、アクセス制御付ディレクトリ機能と呼ばれている。
【０００３】
【発明が解決しようとする課題】
しかしながら、従来技術によるアクセス制御付ディレクトリ機能では、以下のような問題がある。
【０００４】
例えば、図６（ａ）に示すような場合には、
【０００５】
１）サービス利用者は、サービスＡの利用が許可されているので、サービスＡを利用できる。
【０００６】
２）サービスＡは、サービスＢを利用しているサービスであるので、サービスＡは、サービスを提供するためにサービスＢを利用する。サービス利用者がサービスＡを利用しているということは、サービスＢも利用できていることになる。
【０００７】
３）サービス利用者は、サービスＢの利用が許可されていないはずである。それにもかかわらず、サービスＡを利用することによって、サービスＢも利用できてしまう。
【０００８】
例えば、図６（ａ）において、サービスＡがプリンタ、サービスＢが景観カメラであったとき、サービス利用者が、サービスＡに「景観をプリントして欲しい」と依頼すると、本来利用者が見ることができないはずの景観を、プリンタを通して見ることができてしまうことになる。
【０００９】
また、図６（ｂ）に示すような場合には、
【００１０】
１）サービス利用者は、サービスＡの利用が許可されているので、サービスＡを利用できる。
【００１１】
２）サービス利用者は、サービスＡにサービスＢを使うサービスを依頼する。サービスＡは、サービスＢを利用できないサービスであるので、サービスＡは、サービス利用者の依頼サービスを提供できない。
３）サービスの依頼元であるサービス利用者は、サービスＢを利用できるはずである。それにもかかわらず、サービスＡを通すと、サービスＢを利用できない。
【００１２】
例えば、図６（ｂ）において、サービスＡがプリンタ、サービスＢが景観カメラであったとき、サービス利用者が、サービスＡに「景観をプリントして欲しい」と依頼すると、本来利用者が見ることができるはずの景観が、プリンタを通すと見ることができない。
【００１３】
また、図７に示すような場合には、
【００１４】
１）サービス利用者は、サービスＡの利用権があるかどうかディレクトリ機能に尋ねる（アクセス制御依頼）。
【００１５】
２）サービスＡの利用権があれば、サービス利用許可証を発行する。
【００１６】
３）サービスＡは、サービス利用者がサービスＢの利用権があるかどうかディレクトリ機能に尋ねる。
【００１７】
４）サービス利用者にサービスＢの利用権があれば、サービス利用許可証を発行する。
【００１８】
このように、アクセス元（アクセス主体、サービス利用者）が移り変わる度に、ディレクトリ機能にアクセス制御依頼を行なう。委任機能を持っている場合であっても、再帰的サービス利用時は図示のようになる。なお、委任機能とは、サービス利用権限をサービス利用先へ次々と委任する機能である。また、再帰的サービス利用とは、１つのサービス結果を得るために、そのサービスが他の複数のサービスを利用する必要がある場合をいう。
【００１９】
このように、従来技術によるアクセス制御付ディレクトリ機能では、以下のような問題がある。
【００２０】
１）管理者が全てのサービス提供許可管理を行なうと、管理者の負担が大きくなる。
【００２１】
２）再帰的サービス利用が発生したとき、サービス提供が許可されているにも関わらず、サービスが提供されなかったり、逆にサービス提供が許可されていないにも関わらず、サービスが提供されてしまうことがある。
【００２２】
３）再帰的サービス利用が発生する度に、ディレクトリ機能でアクセス制御する必要がある。本来、１回のアクセス制御で利用できるはずのサービスに、再帰的にサービス利用が発生すると、何度でもアクセス制御処理を行なわなければならないことになる。
【００２３】
この発明は上述した事情に鑑みてなされたもので、各種サービスに対するアクセス制御付ディレクトリ機能における、管理者負担を軽減することができ、また、サービス提供の矛盾をなくすことができ、また、再帰的サービスの利用のアクセス制御を簡便化することができるアクセス制御付ディレクトリ機能装置及びプログラムを提供することを目的とする。
【００２４】
【課題を解決するための手段】
本発明は、上述した課題を解決するためになされたものであり、請求項１に記載の発明は、サービスを提供する複数のサービス提供端末と、前記サービス提供端末が提供するサービスを利用するクライアント端末とにそれぞれ接続されるアクセス制御付ディレクトリ機能装置であって、前記サービス提供端末で提供されるサービスを利用可能な利用者についての許可利用者情報と、そのサービス提供端末がサービスを提供する際に利用するサービスを記録した依存サービス情報とを含むアクセス制御リストをそれぞれ前記複数のサービス提供端末から受信する受信手段と、前記受信手段により受信したサービス提供端末のアクセス制御リストに含まれる許可利用者情報と、そのアクセス制御リストに含まれる依存サービス情報に記録されているサービスを提供する他のサービス提供端末についての許可利用者情報とに基づいて、利用者がサービスを利用可能であるか否かについての統合アクセス制御リストを作成する統合アクセス制御リスト作成手段とを有することを特徴とするアクセス制御付ディレクトリ機能装置である。
【００２５】
また、請求項２に記載の発明は、前記クライアント端末を使用する利用者に対して、前記サービス提供端末が提供するサービスを提供するか否かについて、前記統合アクセス制御リスト作成手段が作成した統合アクセス制御リストを参照することにより、当該利用者がサービスを利用可能か否かについて決定するアクセス制御手段を更に有することを特徴とする請求項１記載のアクセス制御付ディレクトリ機能装置である。
また、請求項３に記載の発明は、前記アクセス制御手段により利用者がサービスを利用可能であると決定した場合には、当該サービスの利用許可証を発行するとともに、当該サービスの依存サービス情報に記録されているサービスの利用許可証を発行するサービス利用許可証発行手段を更に有することを特徴とする請求項２記載のアクセス制御付ディレクトリ機能装置である。
【００２６】
また、請求項４に記載の発明は、コンピュータをアクセス制御付ディレクトリ機能装置として動作させるためのプログラムであって、コンピュータに、サービス提供端末で提供されるサービスを利用可能な利用者についての許可利用者情報と、そのサービス提供端末がサービスを提供する際に利用するサービスを記録した依存サービス情報とを含むアクセス制御リストをそれぞれ複数のサービス提供端末から受信させる第１のステップと、前記第１のステップで受信したサービス提供端末のアクセス制御リストに含まれる許可利用者情報と、そのアクセス制御リストに含まれる依存サービス情報に記録されているサービスを提供する他のサービス提供端末についての許可利用者情報とに基づいて、利用者がサービスを利用可能であるか否かについての統合アクセス制御リストを作成させる第２のステップとを実行させるプログラムである。
【００２７】
また、請求項５に記載の発明は、コンピュータに、クライアント端末を使用する利用者に対して、前記サービス提供端末が提供するサービスを提供するか否かについて、前記第２のステップで作成した統合アクセス制御リストを参照することにより、当該利用者がサービスを利用可能か否かについて決定する第３のステップを更に実行させる請求項４記載のプログラムである。
また、請求項６に記載の発明は、コンピュータに、前記第３のステップで利用者がサービスを利用可能であると決定された場合には、当該サービスの利用許可証を発行するとともに、当該サービスの依存サービス情報に記録されているサービスの利用許可証を発行する第４のステップを更に実行させる請求項５記載のプログラムである。
【００２８】
この発明では、複数のサービス提供端末がクライアント端末に対してサービスを利用可能にするときに、受信手段により、前記複数のサービス提供端末から送信されてくる、各サービスに対する複数のアクセス制御リストを受信し、統合アクセス制御リスト作成手段により、前記複数のアクセス制御リストに基づいて、各サービスの依存関係が整合するように、前記複数のアクセス制御リストを統合し、統合アクセス制御リストを作成する。したがって、各種サービスに対するアクセス制御付ディレクトリ機能における、管理者負担を軽減することが可能となり、また、サービス提供の矛盾をなくすことが可能となり、また、再帰的サービスの利用のアクセス制御を簡便化することが可能となる。
【００２９】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
Ａ．実施形態の構成
【００３０】
図１は、本発明の実施形態によるネットワークシステムの構成を示すブロック図である。図１において、クライアント端末１は、サービス利用者（ユーザ）に用いられ、利用者ＩＤ（Ｍｒ．Ａなど）によって、サービスあるいはリソースの利用を依頼する。例えば、「プリンタで景観を印刷してほしい」と依頼する。このとき、パスワードなどの認証情報を送ることも含まれる。
【００３１】
サービス／リソース端末２−１〜２−ｎは、プリンタや、カメラなどからなり、プラグ＆プレイによりネットワーク４に接続／非接続される。サービスやリソース端末２−１〜２−ｎのサービス／リソースは、ディレクトリサーバ３にそのサービス内容を登録する際、サービスやリソースで規定するアクセス制御情報（ＡＣＬ）を送信する。サービスのＡＣＬは、ディレクトリ機能に送信され、統合ＡＣＬに自動的に追加登録される。
【００３２】
ディレクトリサーバ３は、サービスやリソースのリストを管理する（ディレクトリ機能）。リストには、サービスやリソースの、内容や所在などの情報の他に、アクセス制御情報（ＡＣＬ）が含まれる。
【００３３】
また、ディレクトリサーバ３は、ディレクトリ機能により、クライアント端末１からのサービス利用依頼を受けて、以下の手順に従ってアクセス制御を実行する。
【００３４】
▲１▼統合ＡＣＬを参照し、サービス名とアクションが依頼者に実行許可されているか、検索する。
▲２▼検索中、依存サービスが存在すれば、再帰的にその依存サービスのアクセス制御を行なう。
【００３５】
また、ディレクトリサーバ３は、ディレクトリ機能により、以下の手順に従ってサービス／リソース端末２−１〜２−ｎのサービス／リソースから送信されてくるＡＣＬを統合ＡＣＬに追加登録する。
【００３６】
▲１▼サービスから送信されてくるＡＣＬに依存サービスがあれば、再帰的に依存サービス先の許可ユーザもチェックし、サービスから送信されてくるＡＣＬのとおりに本当に許可してもよいサービスであるか確認する。
▲２▼依存サービスの許可ユーザに矛盾があれば、その矛盾を解消してからサービスを登録する。
【００３７】
Ｂ．実施形態の動作
【００３８】
次に、本実施形態の動作について詳細に説明する。
【００３９】
Ｂ−１．全体の略動作
【００４０】
まず、統合ＡＣＬを作成する際の略動作について説明する。ここで、図２は、本実施形態の全体の略動作について説明するためのデータフロー図である。サービスＡおよびサービスＢが持つＡＣＬは、各サービスがプラグ＆プレイされたとき、以下の例のような手順で、ディレクトリサーバ３のディレクトリ機能のアクセス制御情報（統合ＡＣＬ）に自動的に反映される（以下の手順は、上記サービスＡのＡＣＬ、サービスＢのＡＣＬ、統合ＡＣＬを例に説明する）。
【００４１】
Ｓａ１）サービスＡは、プラグ＆プレイされると、ディレクトリサーバ３のディレクトリ機能にサービスＡのＡＣＬを送信する。
【００４２】
Ｓａ２）同様に、サービスＢは、プラグ＆プレイされると、ディレクトリサーバ３のディレクトリ機能にサービスＢのＡＣＬを送信する。
【００４３】
Ｓａ３）ディレクトリサーバ３のディレクトリ機能では、ＡＣＬ受信部３０により、上記各サービスＡ，ＢからのＡＣＬを受信し、ＡＣＬ解析部３１に供給する。
【００４４】
Ｓａ４）ディレクトリ機能では、ＡＣＬ解析部３１により、サービスＡのＡＣＬ、サービスＢのＡＣＬを解析し、矛盾が生じないように、所定のマージ方法を選択して統合ＡＣＬを作成（あるいは更新）する。なお、統合ＡＣＬの作成の詳細については後述する。
【００４５】
次に、サービスの利用は以下の順に行なわれる。
【００４６】
Ｓｂ１）Ａ氏（サービス利用者）は、サービス利用権要求部１０に対してサービスＡのアクションａ１の利用を要求する。
【００４７】
Ｓｂ２）Ａ氏の要求は、ディレクトリサーバ３のディレクトリ機能へ送信され、
【００４８】
Ｓｂ３）ディレクトリサーバ３のディレクトリ機能は、サービス要求受付部３３によりＡ氏の要求を受信し、アクセス制御部（ＡＣＬ解析部）３４により統合ＡＣＬを参照してＡ（ａ１）はＡ氏が利用可能かを判断し、
【００４９】
Ｓｂ４）利用可能であれば、サービス利用許可証発行部３５により、Ａ（ａ１）の利用許可証を発行する。同時に再帰的サービス利用先のＢ（ｂ１）の利用許可証も発行する。
【００５０】
Ｓｂ５）Ａ氏は、サービスＡのアクションａ１（以後、Ａ（ａ１）と記述する）を利用するとき、サービス利用依頼部１１に対して、受け取った２つの利用許可証を提示する。
【００５１】
Ｓｂ６）Ａ（ａ１）は、依頼サービス解析部２１により解析された後、サービス利用依頼部２２により、Ｂ（ｂ１）の利用許可証をもってＢ（ｂ１）の利用を要求する。
【００５２】
Ｓｂ７）Ｂ（ｂ１）では、依頼サービス解析部２１により解析された後、サービスが提供される。
【００５３】
Ｓｂ８）Ａ（ａ１）は、Ｂ（ｂ１）のサービスを得られたので、Ａ氏にＡ（ａ１）のサービスを提供する。
【００５４】
Ｂ−２．統合ＡＣＬの作成動作
【００５５】
次に、上述したサービスの利用に先立って行なわれる、あるいは新たにサービスがプラグ＆プレイされたときに行なわれる、統合ＡＣＬの作成動作について説明する。ここで、図３は、上記サービスＡおよびサービスＢ、各々のアクセス制御情報（ＡＣＬ）を示す概念図である。
【００５６】
Ｓｃ１）サービスＡとサービスＢは、起動すると、プラグ＆プレイにより、自らのＡＣＬを自動的にディレクトリサーバ３のディレクトリ機能に送信する。
【００５７】
Ｓｃ２）ディレクトリサーバ３のディレクトリ機能は、受信したサービスＡとサービスＢのそれぞれのＡＣＬをマージする。そして、マージ結果をディレクトリ機能が持つ統合ＡＣＬとする。このとき、単純に、サービスＡのＡＣＬとサービスＢのＡＣＬを足し合わせようとすると、矛盾が見つかるので、マージ方法は、以下に説明する方式（マージパターンＭＰ１〜ＭＰ３）のどれかを選択することになる。選択は、ディレクトリ機能の管理者が行なうことができる。
【００５８】
Ｓｃ３）マージパターンＭＰ１：
【００５９】
図３（ａ）に示すサービスＡのＡＣＬによると、サービスＡのアクションａ２（以後、Ａ（ａ２）と記述する）は、Ａ氏に利用許可されている。Ａ（ａ２）は、Ｂ（ｂ２）とＢ（ｂ３）とを必要としている。そこで、図３（ｂ）に示すサービスＢのＡＣＬを調べると、Ｂ（ｂ２）は、Ａ氏に利用許可されているが、Ｂ（ｂ３）は、Ａ氏に利用許可されていない。したがって、最終的に、Ａ（ａ２）は、Ａ氏による利用ができないので、Ａ（ａ２）の許可利用者から、Ａ氏を削除したものが結果として統合ＡＣＬになる（→本実施形態による図４の統合ＡＣＬ例では、このやり方が採用されている）。他に、Ａ（ａ２）の許可利用者にＡ氏を残し、Ｂ（ｂ３）の許可利用者にＡ氏を追加する統合ＡＣＬも考えられる。いずれの統合ＡＣＬになるかは、ディレクトリ管理者のポリシーで決定できる。なお、ポリシーの詳細については後述する。
【００６０】
Ｓｃ４）マージパターンＭＰ２：
【００６１】
図３（ａ）に示すように、Ａ（ａ２）は、Ｂ（ｂ２）とＢ（ｂ３）とを必要としており、Ｂ（ｂ２）とＢ（ｂ３）は、図３（ｂ）に示すように、Ｂ氏に利用許可されている。Ｂ（ｂ２）とＢ（ｂ３）の利用ができるＢ氏は、Ａ（ａ２）の利用もできると考えられるが、サービスＡのＡＣＬにはその記述がない。最終的なマージＡＣＬでは、サービスＡの許可利用者にＢ氏を加えることもできる（→本実施形態による統合ＡＣＬ例では、このやり方が採用されている）し、Ｂ氏を加えないこともできる。いずれの統合ＡＣＬになるかは、ディレクトリ管理者のポリシーで決定できる。
【００６２】
Ｓｃ５）マージパターンＭＰ３：
【００６３】
図３（ａ）に示すように、Ａ（ａ３）は、Ｂ（ｂ４）を必要としており、Ｂ（ｂ４）は、図３（ｂ）に示すように、Ａ（ａ３）を必要としている。ループした依存関係があるが、許可利用者がそれぞれのサービスで異なる。このようにループしているサービスの依存関係があり、許可利用者が異なる場合、
【００６４】
ａ．矛盾した誤りのＡＣＬなのか？
【００６５】
ｂ．互いに依存しているなら、１つのサービスとしてまとめてしまった方がよいか？まとめる場合、許可利用者に誰を入れるか（利用者の追加や削除）？
【００６６】
ｃ．依存のループが発生した場合、ループしたところで依存関係のチェックは終了させるか？（→本実施形態による統合ＡＣＬ例では、このやり方が採用されている）
【００６７】
といった判断を行なって最終的な統合ＡＣＬを作成する。
【００６８】
ここで、図４は、上記サービスＡおよびサービスＢを統合した統合ＡＣＬを示す概念図である。図において、「依存サービス」には、予めデータ（依存関係）が登録されている。もしくは、「Ｃサービス」等の新たなサービスを登録したときに、そのサービスの一般的なアクションであれば、自動的に登録される。例えば、サービスが「プリンタ」で、アクションが「テキストのプリントアウト」と「スキャナのデータのプリントアウト」である場合、自動的に登録される。つまり、サービス「プリンタ」が統合ＡＣＬに追加されると、その一般的アクション「テキストのプリントアウト」や「スキャナのデータのプリントアウト」などは自動的に追加されるということである。さらに一般的に述べると、サービスオブジェクトが追加されれば、そのスーパーセットが持つ機能（サービスオブジェクトが継承しているスーパークラスが持つ機能）も追加されるということである。また、自動追加されるアクションの「許可利用者」は、初期段階においては、すなわち統合前には、空欄となっており、例えば、上記マージパターンＭＰ２の実行後、ディレクトリ機能管理者のポリシーによりＢ氏に許可を与えた場合に「Ｂ氏」が許可利用者として登録されるものである。
【００６９】
Ｂ−３．本方式のメリット
【００７０】
Ａ）上述したように、ディレクトリ機能へのＡＣＬの反映方法は、人（ディレクトリ機能管理者）による選択作業が含まれる場合もある。最終的なＡＣＬを完成する前の重要な判断ポイントは、人による選択と確認とができる。
【００７１】
Ｂ）また、上述したマージパターンＭＰ１やＭＰ２のように、サービス個別のＡＣＬでは分からなかった新しいアクセス制御パターンまたはアクセス制御パターンの矛盾を発見することができる。
【００７２】
Ｃ）さらに、上述したマージパターンＭＰ３のように、ループしたアクセスパターンを自動的に発見し、修正したり解釈を加えたりすることができる。
【００７３】
ここで、上述した実施形態において、統合ＡＣＬを作成する場合のポリシーについて説明する。図５は、統合ＡＣＬを作成する場合のポリシーについて説明するための概念図である。コンピュータ内部が、各サービスのＡＣＬをマージして統合ＡＣＬを作成する場合、図５に示すポリシーのテーブルを参照して作成する。例えば、部長グループのマージングポリシーで「転属する」が除かれているので、部長グループに所属する人（アクセス主体）が、「転属」するというアクションを持った人を獲得しても、「転属」させるアクションだけ取らせることができない、というアクセス制御リストができる。
【００７４】
上述した実施形態によれば、最初にディレクトリ機能にサービス利用許可証の発行を依頼した時点で、ディレクトリ機能は、依頼されたサービスを利用するために必要な他のサービスは何があるか分かる。そのため、最初のディレクトリ機能へのアクセス制御依頼のみで再帰的サービス利用が可能か判明する（そもそも統合ＡＣＬが再帰的サービス利用を考慮したＡＣＬになっている）。これにより、再帰的サービスへの利用権を含めたサービス利用許可証をディレクトリ機能が発行できる。関係するサービス全ての許可証を１回で発行できることになる。
【００７５】
また、ディレクトリサービスに、動的にサービスが登録されるとき（プラグ＆プレイ）、ＡＣＬも動的に登録される。いままで人手で登録していた作業が省力化できる。
【００７６】
また、サービスから送信されてきたＡＣＬには、再帰的サービス利用のために依存関係が記されているので、ディレクトリ機能は、その依存関係を探索しながら統合ＡＣＬを作成すればよい。統合ＡＣＬによって、サービス間で依存関係のある複雑なアクセス制御の矛盾や曖昧な部分（依存がループしているなど）を発見することが容易になる。
【００７７】
また、ディレクトリ機能は、１度のアクセス制御のみで再帰的サービス利用を含めたアクセス制御が可能であるため、サービス利用者は、再帰的サービス利用が発生する度にアクセス制御を、ディレクトリ機能に依頼しなくてもよくなる。再帰的なサービス利用があっても、ディレクトリ機能は、再帰的サービス利用先が見渡せるので、要求サービスが最終的に利用できるかどうかが１度で判断できる。
【００７８】
【発明の効果】
以上説明したように、本発明によれば、複数のサービス提供端末がクライアント端末に対してサービスを利用可能にするときに、受信手段により、前記複数のサービス提供端末から送信されてくる、各サービスに対する複数のアクセス制御リストを受信し、統合アクセス制御リスト作成手段により、前記複数のアクセス制御リストに基づいて、各サービスの依存関係が整合するように、前記複数のアクセス制御リストを統合し、統合アクセス制御リストを作成するようにしたので、管理者負担を軽減することができ、また、再帰的サービスへの利用権を含めたサービス提供の矛盾をなくすことができ、また、再帰的サービスの利用のアクセス制御を簡便化することができるという利点が得られる。
【図面の簡単な説明】
【図１】  本発明の実施形態によるネットワークシステムの構成を示すブロック図である。
【図２】  本実施形態の全体の略動作について説明するためのデータフロー図である。
【図３】  上記サービスＡおよびサービスＢ、各々のアクセス制御情報（ＡＣＬ）を示す概念図である。
【図４】  上記サービスＡおよびサービスＢを統合した統合ＡＣＬを示す概念図である。
【図５】  統合ＡＣＬを作成する場合のポリシーについて説明するための概念図である。
【図６】  従来技術によるディレクトリ機能による動作を説明するための概念図である。
【図７】  従来技術によるディレクトリ機能による動作を説明するための概念図である。
【符号の説明】
１  クライアント端末
２−１〜２−ｎ  サービス／リソース端末
３  ディレクトリサーバ
４  ネットワーク
１０  サービス利用権要求部
１１  サービス利用依頼部
２１  依頼サービス解析部
２２  サービス利用依頼部
３０  ＡＣＬ受信部（受信手段）
３１  ＡＣＬ解析部（統合アクセス制御リスト作成手段）
３２  統合ＡＣＬ（統合アクセス制御リスト）
３３  サービス要求受付部
３４  アクセス制御部（アクセス制御手段）
３５  サービス利用許可証発行部
【図１】
0003756457.tif 000002
【図２】
0003756457.tif 000003
【図３】
0003756457.tif 000004
【図４】
0003756457.tif 000005
【図５】
0003756457.tif 000006
【図６】
0003756457.tif 000007
【図７】
0003756457.tif 000008