JP2005251171A - 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体 - Google Patents

Abstract

【課題】 各種のアプリケーションに共通的な情報と特定のアプリケーションに依存した情報とを統合的に提供することのできる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体の提供を目的とする。
【解決手段】 ユーザに係る情報を提供する情報提供手段を併合する併合手段を有する情報提供装置であって、前記併合手段は、複数のアプリケーションのうちの所定のアプリケーションからの要求に応じ、前記複数のアプリケーションより共通に利用され得る、ユーザに係る情報を第一の情報提供手段から取得し、該ユーザに係る情報と同一ユーザに係る、前記所定のアプリケーションに依存する情報を第二の情報提供手段から取得する情報取得手段と、前記第一及び第二の情報提供手段より取得された情報を統合する情報統合手段とを有し、前記情報統合手段により統合された情報を前記アプリケーションに提供することにより上記課題を解決する。
【選択図】 図３

Description

本発明は、情報提供装置、情報提供方法、情報提供プログラム及び記録媒体に関し、特にユーザに係る情報を提供する情報提供装置、情報提供方法、情報提供プログラム及び記録媒体に関する。

複数のコンピュータによって構成される情報システムにおいて、当該システムのユーザに関する各種情報（以下、「ユーザ属性情報」という。）を一元管理すると共に、当該ユーザの認証等を行うサーバ（以下、「ユーザ管理サーバ」という。）が設置されるのが一般である。例えばWindows（登録商標）環境におけるドメインコントローラが代表的な例である。

かかる情報システムにおける各種アプリケーションは、当該アプリケーションのユーザの認証や、当該ユーザのユーザ属性情報の入手等をユーザ管理サーバにアクセスすることで効率的に行うことができる。但し、ユーザ管理サーバに管理されているユーザ属性情報は、各種アプリケーションが共通的に利用する、いわば汎用的な情報であるため、各アプリケーションに依存したアプリケーション固有のユーザ属性情報は、アプリケーションごとに管理する必要があった。

しかしながら、アプリケーション固有のユーザ属性情報をユーザ管理システムと別個に管理すると、アプリケーションは、ユーザ属性情報の管理場所が複数に分散されていることを意識しなければならず、アプリケーションの実装が煩雑になるという問題があった。

そこで、アプリケーション固有の情報をユーザ管理システムの未使用領域に割り当てたり、ユーザ管理システムのデータベーススキーマを拡張し、その拡張領域にアプリケーション固有の情報を割り当てるということが考えられる。しかし、前者の場合は、ユーザ管理システムの拡張性が失われ、後者の場合は、ユーザ管理システムの管理工数の増大化をもたらすことが予想される。そもそも、各種アプリケーションより共通的に利用されるユーザ管理システムに、アプリケーション固有の情報を実装することは、ユーザ管理システムの汎用性を失わせてしまうという問題もある。

したがって、既存のユーザ管理システムに対する変更を要することなく、ユーザ管理システムにおけるユーザ属性情報とアプリケーション固有のユーザ属性情報とをアプリケーションに対して統合的に提供できる手段の存在が望まれる。

また、ユーザ管理システムに管理されているグループとは異なる観点から分類した概念によってアプリケーションに対するユーザの権限を規定したい場合がある。すなわち、ユーザ管理システムに管理されているグループとは異なる観点から分類された概念によって所定のアプリケーションに対するユーザの権限を規定することにより、ユーザ管理システム上においては、一般ユーザとして扱われるユーザを、所定のアプリケーションを利用する際に限って、管理者ユーザとして扱ったりすることが可能となる。かかる場合に、ユーザ管理システムにおけるユーザ権限情報と、アプリケーション固有のユーザ権限情報とを統合的に提供することができれば、当該情報の提供を受けたアプリケーションにとって便宜である。

本発明は、上記の点に鑑みてなされたものであって、各種のアプリケーションに共通的な情報と特定のアプリケーションに依存した情報とを統合的に提供することのできる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、ユーザに係る情報を提供する情報提供手段を併合する併合手段を有する情報提供装置であって、前記併合手段は、複数のアプリケーションのうちの所定のアプリケーションからの要求に応じ、前記複数のアプリケーションより共通に利用され得る、ユーザに係る情報を第一の情報提供手段から取得し、該ユーザに係る情報と同一ユーザに係る、前記所定のアプリケーションに依存する情報を第二の情報提供手段から取得する情報取得手段と、前記第一及び第二の情報提供手段より取得された情報を統合する情報統合手段とを有し、前記情報統合手段により統合された情報を前記アプリケーションに提供することを特徴とする。

このような情報提供装置では、一の情報提供手段より取得される複数のアプリケーションに共通の情報と、他の情報提供手段より取得される所定のアプリケーションに依存した情報とをマージして提供することができる。

また、上記課題を解決するため、本発明は、上記情報提供装置における情報提供方法、前記情報提供方法を前記情報提供装置に実行させるための情報提供プログラム、又は前記情報提供プログラムを記録した記録媒体としてもよい。

本発明によれば、各種のアプリケーションに共通的な情報と特定のアプリケーションに依存した情報とを統合的に提供することのできる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるユーザ管理システムの構成例を示す図である。図１に示されるように、本実施の形態におけるユーザ管理システム１は、ユーザ管理サーバ１０と、端末２０ａ、２０ｂ及び２０ｃ等の複数の端末（以下、総称する場合「端末２０」という。）と、ドメインコントローラ３０とがＬＡＮ（Local Area Network）等のネットワーク５０を介して接続されることによって構成されている。

ユーザ管理サーバ１０は、ユーザの認証を行い、そのユーザに関する各種情報（以下、「ユーザ属性情報」という。）を端末２０に対して提供するためのＷｅｂサービスであるユーザ管理サービス１００が実装されているコンピュータである。ユーザ管理サービス１００は、ドメインコントローラ３０において管理されているユーザ属性情報や、ユーザ管理サービス１００において管理されているユーザ属性情報を端末２０に提供する。

端末２０は、ユーザが直接利用するＰＣ等のコンピュータであり、アプリケーション２１が実装されている。アプリケーション２１は、ユーザ管理サーバ１０より提供されたユーザ属性情報に基づいて、ユーザに対して提供可能な機能を判断する、例えば、文書管理アプリケーション等のようなアプリケーションである。

ドメインコントローラ３０は、周知なように、Ｗｉｎｄｏｗｓ（登録商標）のネットワーク環境においてドメインに関する情報を一括管理するサーバである。本実施の形態において、ドメインコントローラ３０は、端末２０のユーザの認証を行うためのサーバとして、また、Ｗｉｎｄｏｗｓ（登録商標）システムにおけるユーザ属性情報を提供するためのサーバとして機能する。

次に、ユーザ管理サーバ１０の詳細について説明する。図２は、本発明の実施の形態におけるユーザ管理サーバのハードウェア構成例を示す図である。ユーザ管理サーバ１０は、ＣＰＵ１０１１、ＲＯＭ１０１２、ＲＡＭ１０１３、補助記憶装置１０１４、ネットワークインタフェース（Ｉ／Ｆ）１０１５、ドライブ装置１０１６等から構成されている。

ＣＰＵ１０１１は、ユーザ管理サーバ１０全体を制御する制御部であり、ＲＯＭ１０１２や補助記憶装置１０１４に格納された各種制御プログラムやアプリケーションプログラムを実行して装置の制御、通信の制御、データの取得及び編集等の動作を行う。ＲＯＭ１０１２は、主に装置の制御プログラムを記憶する記憶手段であり、ＲＡＭ１０１３はＣＰＵ１０１１のワークメモリや一時的なデータの記憶に用いる記憶手段である。補助記憶装置１０１４は、各種アプリケーションプログラムやデータを記憶する記憶手段である。ネットワークＩ／Ｆ１０１５は、ユーザ管理サーバ１０をネットワーク５０に接続するためのインタフェースである。ドライブ装置１０１６は、本発明の機能を実行するプログラムが記録されたＣＤ−ＲＯＭ等の記録媒体１０１７を読み取るための装置である。

なお、図２には操作部や表示部を示していないが、キーボードやマウス等による操作部や、液晶やブラウン管（ＣＲＴ）による表示部を設け、ユーザからの入力の受け付けや動作結果の表示を行うことができるようにしてもよい。

図３は、本発明の実施の形態におけるユーザ管理サービスの機能構成例を示す図である。図３に示されるように、ユーザ管理サービス１００は、ディスパッチャ１１、チケット管理テーブル１１１、ユニオンマージプロバイダ１２、Ｗプロバイダ１３、ロールプロバイダ１４、Ｎプロバイダ１５、リモートプロバイダ１６、及びロールＤＢ（Ｄａｔａ Ｂａｓｅ）１４１等より構成されている。

ユニオンマージプロバイダ１２、Ｗプロバイダ１３、ロールプロバイダ１４、Ｎプロバイダ１５、及びリモートプロバイダ１６は、「認証プロバイダ」と呼ばれるモジュールである。認証プロバイダとは、基本的にそれぞれが対応する認証エンジンの独自のプロトコルを吸収し、統一されたインタフェースによって、各認証エンジンの認証機能を提供するためのモジュールである。認証プロバイダが統一されたインタフェースを提供することにより、認証プロバイダの呼び出し側である上位モジュール（ディスパッチャ１１）は、認証エンジンごとに異なるプロトコルを意識する必要がない。したがって、上位モジュールの実装に影響を与えることなく新たな認証プロバイダを追加することができる。

例えば、各認証プロバイダに共通に実装されているインタフェース（メソッド）として、認証メソッド（authenticateByPassword）がある。認証メソッドは、ユーザ名、パスワード及びドメイン名等を入力引数とし、当該ユーザが認証された場合は、当該ユーザが認証された旨を証明するデータ（以下、「チケット」という。）を生成し、返却するものである。なお、チケットには、対応している認証エンジンにおける管理体系において、当該ユーザが属しているグループに関する情報等が記録されている。

具体的には、Ｗプロバイダ１３は、Ｗｉｎｄｏｗｓ（登録商標）のドメインコントローラ３０におけるパスワード認証に対応した認証プロバイダである。したがって、Ｗプロバイダ１３は、認証メソッドが呼び出されると、ドメインコントローラ３０に当該ユーザの認証を要求すると共に、当該ユーザについてのグループ情報等をドメインコントローラ３０より取得し、そのグループ情報等が記録されたチケットを返却する。

同様に、Ｎプロバイダ１５は、Ｎｏｔｅｓ（登録商標）サーバ（図中、「Ｎサーバ４０」として表示）におけるパスワード認証に対応した認証プロバイダである。

リモートプロバイダ１６は、直接的に認証エンジンに対応している認証プロバイダではなく、他のコンピュータにおけるユーザ管理サービス１００と同様のサービス（図中には、「他のユーザ管理サービス」と表示）に対応している認証プロバイダである。すなわち、リモートプロバイダ１６は、認証メソッドが呼び出されると、当該他のユーザ管理サービスの認証メソッドを呼び出し、その応答として返信されるチケットをそのまま返却する。

ロールプロバイダ１４は、認証を目的とした認証プロバイダではなく、ロールＤＢ１４１に管理されている、アプリケーション２１に依存した固有のユーザ属性情報の提供を主目的とした認証プロバイダである。ここで、アプリケーション２１に固有のユーザ属性情報とは、アプリケーション２１において独自に定義されている情報をいい、アプリケーション２１は、当該ユーザ属性情報を、各ユーザの権限を識別するための情報として用いる。したがって、ロールプロバイダ１４は、認証メソッドが呼び出されると、認証の対象となっているユーザに関するアプリケーション２１に固有のユーザ属性情報をロールＤＢ１４１より検索し、検索された情報をチケットに格納して返却する。

図４は、ロールプロバイダの機能構成例を説明するための図である。図４に示されるように、ロールプロバイダ１４は、ロールＤＢ検索部１４２及び擬似チケット生成部１４３等より構成される。ロールＤＢ検索部１４２は、アプリケーション２１に固有のユーザ属性情報をロールＤＢ１４１より検索する機能である。擬似チケット生成部１４３は、ロールＤＢ検索部１４２によって検索された情報に基づいて、擬似的なチケット（擬似チケット）を生成する機能である。ここで、「擬似的な」と表現するのは、チケットは、本来はユーザが認証された場合にその旨を証明するために発行されるものであるところ、ロールプロバイダ１４においては、ユーザの認証は行われないからである。すなわち、ロールプロバイダ１４より返却されたチケットは、ユーザが認証された旨を示すものではなく、当該ユーザ関する、アプリケーション２１に固有のユーザ属性情報が記録された媒体として機能するものだからである。

図３に戻る。ユニオンマージプロバイダ１２は、認証プロバイダの一つであるが、認証エンジンに対する直接の仲介役として機能するものではなく、二つ以上の認証プロバイダを統合的に（いかにも一つの認証プロバイダとして）上位モジュールに見せるための認証プロバイダである。本実施の形態におけるユニオンマージプロバイダ１２は、Ｗプロバイダ１３とロールプロバイダ１４とを併合する。したがって、ユニオンマージプロバイダ１２は、認証メソッドが呼び出されると、Ｗプロバイダ１３及びロールプロバイダ１４の認証メソッドを呼び出し、それぞれより返却されたチケットをマージしたもの（以下、「マージチケット」という。）を返却する。

図５は、ユニオンマージプロバイダの機能構成例を説明するための図である。図５に示されるように、ユニオンマージプロバイダ１２は、プロバイダ振分け部１２１、チケットマージ処理部１２２及びマージ構成情報１２３等より構成される。プロバイダ振分け部１２１は、ユニオンマージプロバイダ１２に併合されている各認証プロバイダを呼び出すことにより、各認証プロバイダよりチケットを取得するための機能である。チケットマージ処理部１２２は、プロバイダ振分け部１２１によって取得されたチケットを一つのマージチケットにマージするための機能である。マージ構成情報１２３は、ユニオンマージプロバイダ１２に併合されている認証プロバイダを識別するためと共に、プロバイダ振分け部１２１が各認証プロバイダを呼び出すにあたり、どのような順番でそれぞれを呼び出すのかを判断するための情報である。

図３に戻る。ディスパッチャ１１は、アプリケーション２１からのユーザの認証要求に応じ、上述した各認証プロバイダを呼び分けるためのモジュールである。ディスパッチャ１１は、また、呼び出した認証プロバイダより返却されたチケットをアプリケーション２１からの提供要求に対する応答として返信する。チケット管理テーブル１１１は、認証プロバイダより返却されたチケットを保持しておくためのテーブルである。

以下、図３のユーザ管理サーバ１０の処理手順について説明する。図６は、ユーザの認証要求に対するユーザ管理サーバにおける処理を説明するためのシーケンス図である。

ステップＳ１０１において、ユーザよりユーザ名、パスワード及びドメイン名等の入力を受けたアプリケーション２１は、ユーザ管理サービス１００の認証メソッド（authenticateByPassword）をＳＯＡＰ（Simple Object Access Protocol）のＲＰＣ（Remote Procedure Call）によって呼び出すことにより、端末２０のユーザについての認証の要求（ＳＯＡＰリクエスト）をユーザ管理サービス１００に対して送信する。認証メソッドの引数には、ユーザによって入力されたユーザ名、パスワード及びドメイン名と、認証の要求先とする認証プロバイダのプロバイダ名が指定される。本実施の形態において、アプリケーション２１は、ユニオンマージプロバイダ１２を認証の要求先として実装されているものとする。したがって、プロバイダ名を指定する引数には、ユニオンマージプロバイダ１２のプロバイダ名である「ユニオンマージプロバイダ」が指定される。

なお、本実施の形態についてはＳＯＡＰを用いた例を説明するが、ＲＰＣのプロトコル又はアーキテクチャについては、必ずしもＳＯＡＰに限られない。ＤＣＥ（Data Communications Exchange）ＲＰＣでもよいし、ＣＯＲＢＡ（Common Object Request Broker Architecture）やＤＣＯＭ（Distributed COM）等、システム環境に合わせて適切なものを選択すればよい。

ステップＳ１０１に続いてステップＳ１０２に進み、ＳＯＡＰリクエストを受信したディスパッチャ１１は、認証メソッドの引数に指定されているプロバイダ名（ユニオンマージプロバイダ）に基づいて、ユニオンマージプロバイダ１２の認証メソッドを呼び出す。なお、ユーザ名、パスワード及びドメイン名は、ユニオンマージプロバイダ１の認証メソッドの引数に引き継がれる。ステップＳ１０２に続いてステップＳ１０３に進み、ユニオンマージプロバイダ１２は、マージ構成情報１２３を参照することにより、併合される各認証プロバイダ、及びそれらを呼び出す順番を判断する。

図７は、マージ構成情報の構成例を示す図である。図７のマージ構成情報１２３には、ユニオンマージプロバイダ１２によって併合されるＷプロバイダ１３及びロールプロバイダ１４のそれぞれについて、そのプロバイダ名及び種別（「Ｐｒｉｍａｒｙ」又は「Ａｄｄｉｔｉｏｎａｌ」）が示されている。したがって、ユニオンマージプロバイダ１２は、マージ構成情報１２３に含まれているプロバイダ名によって、自らに併合される認証プロバイダを特定することができると共に、種別によって、併合される各認証プロバイダを呼び出す順番を判断することができる。すなわち、種別には「Ｐｒｉｍａｒｙ」と「Ａｄｄｉｔｉｏｎａｌ」とがあるが、「Ｐｒｉｍａｒｙ」は、最初に呼び出されるべき認証プロバイダであることを示す。このように、併合される認証プロバイダをユニオンマージプロバイダ１２のソースコードにハードコーディングするのではなく、外部情報（マージ構成情報１２３）として管理することにより、ユニオンマージプロバイダ１２によって併合される認証プロバイダを変更する際等に、ユニオンマージプロバイダ１２のソースコードの修正、コンパイル及びリンク等を行う必要はない。

マージ構成情報１２３に基づいて、ユニオンマージプロバイダ１２のプロバイダ振分け部１２１は、まず、Ｗプロバイダ１３の認証メソッド（authenticateByPassword）を、ユーザ名、パスワード及びドメイン名を引数に指定して呼び出す（Ｓ１０４）。ステップＳ１０４に続いて、Ｗプロバイダ１３は、ユーザ名、パスワード及びドメイン名に基づく認証をドメインコントローラ３０に要求すると共に、認証されたユーザのユーザ属性情報をドメインコントローラ３０より取得する（Ｓ１０５、Ｓ１０６）。ステップＳ１０６に続いてステップＳ１０７に進み、Ｗプロバイダ１３は、ドメインコントローラ３０より取得した情報に基づいてチケットを生成する。

図８は、Ｗプロバイダによって生成されたチケットの例を示す図である。図８に示されるチケット５１０は、認証されたユーザについてのユーザ情報５１１と、当該ユーザが属しているグループに関する情報であるグループ情報５１２及び５１３とから構成されている。ユーザ情報及び各グループ情報は、当該情報を取得した認証プロバイダのプロバイダ名、当該ユーザ又はグループが属しているドメイン、当該ユーザ又はグループの名前、及び当該ユーザ又はグループを一意に識別するためのユニークＩＤ等を識別するための情報により構成されている。したがって、チケット５１０によって、当該ユーザは、ＳＳＣドメインにおいて定義されているユーザ「Ｔａｒｏ」であること、及びユーザ「Ｔａｒｏ」は、ＳＳＣドメインにおいて定義されている「Ｇｒｏｕｐ１」及び「Ｇｒｏｕｐ２」の二つのグループに属していること等が識別され得る。なお、ユニークＩＤは、複数の認証プロバイダ間においてユーザを一意に特定することができるものである。すなわち、各認証プロバイダは、同一のユニークＩＤによって同一ユーザを識別する。

ステップＳ１０７に続いてステップＳ１０８に進み、Ｗプロバイダ１３は、生成したチケット５１０をユニオンマージプロバイダ１２に対して出力する。

ステップＳ１０８に続いてステップＳ１０９に進み、ユニオンマージプロバイダ１２のプロバイダ振分け部１２１は、ロールプロバイダ１４の認証メソッド（authenticateByPassword）を、ユーザ名、パスワード及びドメイン名を引数に指定して呼び出す。ステップＳ１０９に続いてステップＳ１１０に進み、ロールプロバイダ１４のロールＤＢ検索部１４２は、ユーザ名に基づいて当該ユーザのユーザ属性情報をロールＤＢ１４１より検索する。

図９は、ロールＤＢを構成するユーザ・ロール対応テーブルの構成例を示す図である。図９に示されるように、ユーザ・ロール対応テーブル１４１ａは、ユーザとロールとの対応づけが管理されているテーブルであり、対応づけごとにユーザを特定する情報として、ユニークＩＤ及びユーザ名が、ロールを特定する情報としてロールのユニークＩＤ（ロールＩＤ）が登録されている。ここで、ロールとは、アプリケーション２１の機能に対するユーザの権限（利用の可否）を識別するための概念である。すなわち、アプリケーション２１において、ユーザが利用可能な機能は、当該ユーザがどのロールに属しているかによって判断される。ユーザとロールは多対多の関係にあり、あるユーザは複数のロールに属することができ、また一つのロールには複数のユーザが属し得る。

図１０は、ロールＤＢを構成するロール管理テーブルの構成例を示す図である。図１０に示されるように、ロール管理テーブル１４１ｂは、ロールＩＤごとに、当該ロールのロール名が管理されているテーブルである。

したがって、ロールＤＢ検索部１４２は、ユーザ・ロール対応テーブル１４１ａ及びロール管理テーブル１４１ｂより、ユーザ「Ｔａｒｏ」が属するロールは、「ＲＳＡｄｍｉｎ」及び「ＣＳＡｄｍｉｎ」であることを特定する。

ステップＳ１１０に続いてステップＳ１１１に進み、ロールプロバイダ１４の擬似チケット生成部１４３は、ロールＤＢ検索部１４２より検索された情報に基づいて擬似チケットを生成する。

図１１は、ロールプロバイダによって生成された擬似チケットの例を示す図である。図１１に示されるように、擬似チケット５２０は、Ｗプロバイダ１３によって生成されるチケット５１０と同様の構造をしている。すなわち、ロールＤＢ１４における「ロール」という概念は、「グループ」という概念に近似するものであるため、ロールに関する情報をグループ情報としてあてはめることで、両チケットの構造を共通的なものとしているのである。擬似チケット５２０によって、ユーザ「Ｔａｒｏ」は、ロール「ＲＳＡｄｍｉｎ」及びロール「ＣＳＡｄｍｉｎ」に属していることが識別され得る。

ステップＳ１１１に続いてステップＳ１１２に進み、ロールプロバイダ１４は、生成した擬似チケット５２０をユニオンマージプロバイダ１２に対して出力する。なお、ここでユニオンマージプロバイダ１２に対して出力された擬似チケットは、Ｗプロバイダ１３より取得されたチケットに対応したユーザと同一ユーザ（Ｔａｒｏ）に対するものである。

ステップＳ１１２に続いてステップＳ１１３に進み、ユニオンマージプロバイダ１２のチケットマージ処理部１２２は、Ｗプロバイダ１３より取得したチケット５１０と、ロールプロバイダ１４より取得した擬似チケット５２０とをマージして、一つのマージチケットを生成する。

図１２は、マージチケットの例を示す図である。図１２に示されるように、マージチケット５３０は、チケット５１０におけるユーザ情報及びグループ情報と、擬似チケット５２０におけるグループ情報とをマージしたものである。マージチケット５３０によって、ユーザ「Ｔａｒｏ」は、「Ｇｒｏｕｐ１」、「Ｇｒｏｕｐ２」、「ＲＳＡｄｍｉｎ」及び「ＣＳＡｄｍｉｎ」の４つのグループに属していることが識別され得る。但し、前者二つのグループと後者二つのグループとは、本質的に異なるものであることに注意を要する。すなわち、前者二つのグループは、ドメインコントローラ３０おいて定義されているＷｉｎｄｏｗｓ（登録商標）システム（すなわち、アプリケーション２１の動作環境）において定義されているグループであるのに対し、後者二つのグループは、アプリケーション２１の世界において定義された、ユーザの権限を識別するためのロールである。

ステップＳ１１３に続いてステップＳ１１４に進み、ユニオンマージプロバイダ１２が、生成したマージチケット５３０をディスパッチャ１１に対して出力すると、ディスパッチャ１１は、マージチケットをチケット管理テーブル１１１に登録する（Ｓ１１５）。

図１３は、チケット管理テーブルの構成例を示す図である。図１３に示されるように、チケット管理テーブル１１１は、発行されたチケットごとに、チケット、発行プロバイダ名、及びチケット詳細情報等を管理するものである。チケットは、チケットの実体である。発行プロバイダ名は、当該チケットを発行した認証プロバイダのプロバイダ名である。チケット詳細情報は、当該チケットに係るユーザに関する各種情報である。

なお、チケット管理テーブル１１１に登録された情報は、アプリケーション２１よりマージチケットの提示を受けた各種サービスから、当該マージチケットの正当性の確認等を要求された場合の照会情報等として用いられる。

ステップＳ１１５に続いてステップＳ１１６に進み、ディスパッチャ１１は、マージチケット５３０を含むＳＯＡＰメッセージをＳＯＡＰレスポンスとしてアプリケーション２１に対して送信する。以降、マージチケット５３０を受信したアプリケーション２１は、マージチケット５３０にグループ情報３及び４として記録されている、ロール情報に基づいてユーザの権限を識別することにより、ユーザに提供可能な機能を判断することができる。

上述したように、本実施の形態におけるユーザ管理サーバ１０におけるユニオンマージプロバイダ１２によれば、ドメインコントローラ３０によって管理されている情報と、ユーザにロールＤＢ１４１において管理されている、アプリケーション２１に依存したロール情報とをマージして提供することができる。したがって、ドメインコントローラ３０に影響を与えることなく、アプリケーション２１に対してそれぞれの情報を一元的に提供することができる。

なお、本実施の形態においては、ロールに関する情報をアプリケーションに依存した情報の例として説明したが、本発明は、様々な情報に対して同様に適用可能である。また、本実施の形態において、Ｗプロバイダ１３やロールプロバイダ１４等がユニオンマージプロバイダ１２と同一のコンピュータ（ユーザ管理サーバ１０）に実装されている例について説明したが、Ｗプロバイダ１３及びロールプロバイダ１４をユニオンマージプロバイダ１２と別のコンピュータに実装してもよい。この場合、ユニオンマージプロバイダ１２とＷプロバイダ１３及びロールプロバイダ１４との間をＳＯＡＰ等のＲＰＣが実現可能なプロトコルによって接続すれば、全てが同一のコンピュータにある場合とほぼ同様の実装によって各認証プロバイダを実現することができる。

ところで、上記においては、ユニオンマージプロバイダ１２が、ユーザの認証処理の際において各認証プロバイダによる処理、あるいは各認証プロバイダによって生成されるチケットをマージする例について説明したが、ユニオンマージプロバイダ１２による認証プロバイダの併合は、認証処理の場合だけに限られない。以下、アプリケーション２１より、任意のユーザのユーザ属性情報の検索が要求された場合の例について説明する。

図１４は、ユーザ属性情報の検索処理を説明するためのシーケンス図である。ここで、図１４における処理は、図６における処理とは本質的に異なることに注意を要する。すなわち、図１４における処理は、当該ユーザ自身に関する情報をチケットとして提供するのではなく、当該ユーザとは別の他のユーザのユーザ属性情報を検索し、当該ユーザに提供するための処理である。

ステップＳ２０１において、アプリケーション２１は、ユーザ管理サービス１００の検索メソッド（searchEntry）をＳＯＡＰのＲＰＣによって呼び出すことにより、任意のユーザに関するユーザ属性情報の検索要求（ＳＯＡＰリクエスト）をユーザ管理サービス１００に対して送信する。検索メソッドに引数には、検索対象とするユーザのユーザ名及びドメイン名と、検索対象とする属性（ここでは、「メールアドレス」とする。）を識別する情報（以下、「検索属性名」という。）と、検索の要求先とする認証プロバイダのプロバイダ名（ここでは、「ユニオンマージプロバイダ」）が指定される。

ステップＳ２０１に続いてステップＳ２０２に進み、ＳＯＡＰリクエストを受信したディスパッチャ１１は、検索メソッドの引数に指定されているプロバイダ名（ユニオンマージプロバイダ）に基づいて、ユニオンマージプロバイダ１２の検索メソッドを呼び出す。なお、ユーザ名、ドメイン名及び検索属性名は、ユニオンマージプロバイダ１２の検索メソッドの引数に引き継がれる。ステップＳ２０２に続いてステップＳ２０３に進み、ユニオンマージプロバイダ１２は、マージ構成情報１２３を参照することにより、併合される各認証プロバイダはＷプロバイダ１３及びロールプロバイダ１４である旨、並びにＷプロバイダ１３を最初に呼び出す旨を判断する。

ステップＳ２０３に続いてステップＳ２０４に進み、ユニオンマージプロバイダ１２のプロバイダ振分け部１２１は、Ｗプロバイダ１３の検索メソッド（searchEntry）を、ユーザ名、ドメイン名及び検索属性名を引数に指定して呼び出す。ステップＳ２０４に続いてステップＳ２０５に進み、Ｗプロバイダ１３が、ドメインコントロール３０に対して、引数に指定されたユーザ名及びドメイン名によって特定されるユーザについて、検索属性名によって特定される属性（メールアドレス）の検索を要求すると、ドメインコントローラ３０より検索結果が返信される（Ｓ２０６）。

ステップＳ２０６に続いてステップＳ２０７に進み、Ｗプロバイダ１３は、ドメインコントローラ３０より受信した検索結果をユニオンマージプロバイダ１２に対して出力する。ここで、検索属性名によって特定される属性がドメインコントロール３０によって管理されていない情報である場合等、ドメインコントロール３０からの検索結果がエラーであった場合には、Ｗプロバイダ１３は、空値を出力するようにしてもよい。

ステップＳ２０７に続いてステップＳ２０８に進み、ユニオンマージプロバイダ１２のプロバイダ振分け部１２１は、ロールプロバイダ１４の検索メソッド（searchEntry）を、ユーザ名、ドメイン名及び検索属性名を引数に指定して呼び出す。ステップＳ２０８に続いてステップＳ２０９に進み、ロールプロバイダ１４のロールＤＢ検索部１４２は、引数に指定されたユーザ名及びドメイン名によって特定されるユーザについて、検索属性名によって特定される属性（メールアドレス）をロールＤＢ１４１より検索すると、その検索結果をユニオンマージプロバイダ１２に対して出力する（Ｓ２１０）。

ステップＳ２１０に続いてステップＳ２１１に進み、ユニオンマージプロバイダ１２は、Ｗプロバイダ１３より取得した検索結果とロールプロバイダ１４より取得した検索結果とをマージする。ここで、検索結果がメールアドレスである場合は、双方より取得したメールアドレスを一覧形式にマージしてもよいが、マージの仕方（いずれを優先させるか等）を予め規定しておき、その規定に基づいていずれ一方のみを採用してもよい。マージの仕方については、マージ構成情報１２３に登録するようにしてもよい。

図１５は、マージの仕方をマージ構成情報に含めた例を示す図である。図１５に示されるマージ構成情報１２３ａにおいて、符号１２４によって示される列が、マージの仕方を規定した情報である。当該規定においては、属性ごとに各認証プロバイダより取得された情報の採否が○×によって示されている。例えば、マージ構成情報１２３ａより、グループ情報については、Ｗプロバイダ１３及びロールプロバイダ１４の双方より取得された情報を採用すること（すなわち、双方より取得された情報をマージすること）が分かり、メールアドレスについては、ロールプロバイダ１４より取得された情報のみを採用することが分かる。

なお、図６の処理において、ユニオンマージプロバイダ１２がチケットをマージする際（Ｓ１１３）においても、図１５に示されるようなマージ構成情報１２３ａに基づいてどの認証プロバイダから取得されたチケットを採用するかを判断するようにしてもよい。

本実施の形態においては、ユニオンマージプロバイダ１２は、マージ構成情報１２３ａに基づいて、ロールプロバイダ１４より取得されたメールアドレスのみを採用し、当該メールアドレスを検索結果としてディスパッチャ１１に対して出力する（Ｓ２１２）。ステップＳ２１２に続いてステップＳ２１３に進み、ディスパッチャ１１は、検索結果を含むＳＯＡＰメッセージをＳＯＡＰレスポンスとしてアプリケーション２１に対して送信する。

このように、認証プロバイダの併合という仕組みは、ユーザに認証処理に関してだけでなく、種々の情報の提供に関する処理において有効に適用することが可能である。

なお、本実施の形態においては、複数のアプリケーションから共通に利用される情報と、所定のアプリケーション固有の情報とをマージチケットとして提供する例について説明したが、例えば、複数の機器から要求に利用される情報と、特定の機器固有の情報とを併合して提供する場合においても、本発明の思想を用いることができる。

ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＣＰＵが搭載され、コンピュータと同様にソフトウェアによって機能を実現するものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複数のアプリケーションを有する画像形成装置もかかる機器に該当する。

したがって、このような機器に対して、本発明を適用してもよい。図１６は、本実施の形態におけるユーザ管理サービスを実装した機器の構成例を示す図である。図１６中、図３と同一部分には同一符号を付し、その説明は省略する。

図１６において、機器４００は、ユーザ管理サービス１００と、アプリケーション４０１ａ、アプリケーション４０１ｂ、アプリケーション４０１ｃ及びアプリケーション４０１ｄ（以下、総称する場合「アプリケーション４０１」という。）とを有している。

アプリケーション４０１は、ユーザ管理サービス１００より提供されたユーザ属性情報に基づいて、ユーザに対して提供可能な機能を判断するアプリケーションである。例えば、複合機であれば、、文書管理機能を提供する文書管理アプリケーションや、印刷機能を提供する印刷アプリケーション、文書配信機能を提供する配信アプリケーション等が相当する。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態におけるユーザ管理システムの構成例を示す図である。 本発明の実施の形態におけるユーザ管理サーバのハードウェア構成例を示す図である。 本発明の実施の形態におけるユーザ管理サービスの機能構成例を示す図である。 ロールプロバイダの機能構成例を説明するための図である。 ユニオンマージプロバイダの機能構成例を説明するための図である。 ユーザの認証要求に対するユーザ管理サーバにおける処理を説明するためのシーケンス図である。 マージ構成情報の構成例を示す図である。 Ｗプロバイダによって生成されたチケットの例を示す図である。 ロールＤＢを構成するユーザ・ロール対応テーブルの構成例を示す図である。 ロールＤＢを構成するロール管理テーブルの構成例を示す図である。 ロールプロバイダによって生成された擬似チケットの例を示す図である。 マージチケットの例を示す図である。 チケット管理テーブルの構成例を示す図である。 ユーザ属性情報の検索処理を説明するためのシーケンス図である。 マージの仕方をマージ構成情報に含めた例を示す図である。 本実施の形態におけるユーザ管理サービスを実装した機器の構成例を示す図である。

符号の説明

１ ユーザ管理システム
１０ ユーザ管理サーバ
１１ ディスパッチャ
１２ ユニオンマージプロバイダ
１３ Ｗプロバイダ
１４ ロールプロバイダ
１５ Ｎプロバイダ
１６ リモートプロバイダ
２０、２０ａ、２０ｂ、２０ｃ 端末
３０ ドメインコントローラ
４０ Ｎサーバ
１００ ユーザ管理サービス
１１１ チケット管理テーブル
１４１ ロールＤＢ
１４２ ロールＤＢ検索部
１４３ 擬似チケット生成部
１２１ プロバイダ振分け部
１２２ チケットマージ処理部
１２３ マージ構成情報
４００ 機器
４０１、４０１ａ、４０１ｂ、４０１ｃ、４０１ｄ アプリケーション
１０１１ ＣＰＵ
１０１２ ＲＯＭ
１０１３ ＲＡＭ
１０１４ 補助記憶装置
１０１５ ネットワークＩ／Ｆ
１０１６ ドライブ装置
１０１７ 記録媒体

Claims (17)

1. ユーザに係る情報を提供する情報提供手段を併合する併合手段を有する情報提供装置であって、
   前記併合手段は、複数のアプリケーションのうちの所定のアプリケーションからの要求に応じ、
   前記複数のアプリケーションより共通に利用され得る、ユーザに係る情報を第一の情報提供手段から取得し、該ユーザに係る情報と同一ユーザに係る、前記所定のアプリケーションに依存する情報を第二の情報提供手段から取得する情報取得手段と、
   前記第一及び第二の情報提供手段より取得された情報を統合する情報統合手段とを有し、
   前記情報統合手段により統合された情報を前記アプリケーションに提供することを特徴とする情報提供装置。
2. 前記第一及び第二の情報提供手段を有することを特徴とする請求項１記載の情報提供装置。
3. 前記所定のアプリケーションに依存する情報は、該情報に係るユーザについて前記所定のアプリケーションの機能に対する権限を示す情報を含むことを特徴とする請求項１又は２記載の情報提供装置。
4. 前記第一の情報提供手段より取得される前記ユーザに係る情報は、所定のシステムにおいて該ユーザが属するグループに関する情報を含むことを特徴とする請求項１乃至３いずれか一項記載の情報提供装置。
5. 複数の前記情報提供手段の中から前記第一及び第二の情報提供手段を識別する情報を含む情報提供手段識別情報を有し、
   前記情報取得手段は、前記情報提供手段識別情報に基づいて前記第一及び第二の情報提供手段を特定することを特徴とする請求項１乃至４いずれか一項記載の情報提供装置。
6. 前記ユーザに係る情報を構成する属性ごとに、前記第一及び第二の情報提供手段のそれぞれより取得された情報の採否を示す採否判別情報を有し、
   前記情報統合手段は、前記採否判別情報に基づいて前記第一及び第二の情報提供手段より取得された情報を統合することを特徴とする請求項１乃至５いずれか一項記載の情報提供装置。
7. 前記所定のアプリケーションからの要求は、ユーザについての認証要求であって、
   前記情報取得手段は、前記第一の情報提供手段に前記ユーザの認証を要求することにより、前記第一の情報提供手段から前記ユーザに係る情報を取得することを特徴とする請求項１乃至６いずれか一項記載の情報提供装置。
8. 前記情報取得手段は、前記第一の情報提供手段に前記ユーザの認証を要求することにより、前記ユーザに係る情報を含むと共に前記ユーザが認証された旨を証明する証明情報を取得し、
   前記情報統合手段は、前記第一の情報提供手段より取得された前記証明情報と、前記第二の情報提供手段より取得されたユーザに係る情報とを前記証明情報として統合することを特徴とする請求項７記載の情報提供装置。
9. ユーザに係る情報を提供する情報提供手段を統合する情報提供装置における情報提供方法であって、
   複数のアプリケーションのうちの所定のアプリケーションからの要求に応じ、前記複数のアプリケーションより共通に利用され得る、ユーザに係る情報を第一の情報提供手段から取得する第一の情報取得手順と、
   前記第一の情報取得手順において情報が取得されたユーザと同一ユーザに係る、前記所定のアプリケーションに依存する情報を第二の情報提供手段から取得する第二の情報取得手順と、
   前記第一及び第二の情報提供手段より取得された情報を統合する情報統合手順とを有し、
   前記情報統合手順において統合された情報を前記アプリケーションに提供することを特徴とする情報提供方法。
10. 前記所定のアプリケーションに依存する情報は、該情報に係るユーザについて前記所定のアプリケーションの機能に対する権限を示す情報を含むことを特徴とする請求項９記載の情報提供方法。
11. 前記第一の情報取得手順において取得される前記ユーザに係る情報は、所定のシステムにおいて該ユーザが属するグループに関する情報を含むことを特徴とする請求項９又は１０記載の情報提供方法。
12. 前記第一及び第二の情報取得手順は、複数の前記情報提供手段の中から前記第一及び第二の情報提供手段を識別する情報を含む情報提供手段識別情報に基づいて前記第一又は第二の情報提供手段を特定することを特徴とする請求項９乃至１１いずれか一項記載の情報提供方法。
13. 前記情報統合手順は、前記ユーザに係る情報を構成する属性ごとに、前記第一及び第二の情報提供手段のそれぞれより取得された情報の採否を示す採否判別情報に基づいて前記第一及び第二の情報提供手段より取得された情報を統合することを特徴とする請求項９乃至１２いずれか一項記載の情報提供方法。
14. 前記所定のアプリケーションからの要求は、ユーザについての認証要求であって、
    前記第一の情報取得手順は、前記第一の情報提供手段に前記ユーザの認証を要求することにより、前記第一の情報提供手段から前記ユーザに係る情報を取得することを特徴とする請求項９乃至１３いずれか一項記載の情報提供方法。
15. 前記第一の情報取得手順は、前記第一の情報提供手段に前記ユーザの認証を要求することにより、前記ユーザに係る情報を含むと共に前記ユーザが認証された旨を証明する証明情報を取得し、
    前記情報統合手順は、前記第一の情報提供手段より取得された前記証明情報と、前記第二の情報提供手段より取得されたユーザに係る情報とを前記証明情報として統合することを特徴とする請求項１４記載の情報提供方法。
16. コンピュータを、ユーザに係る情報を提供する情報提供手段を統合する情報提供装置として機能させる情報提供プログラムであって、
    複数のアプリケーションのうちの所定のアプリケーションからの要求に応じ、前記複数のアプリケーションより共通に利用され得るユーザに係る情報を第一の情報提供手段から取得する第一の情報取得手順と、
    前記第一の情報取得手順において情報が取得されたユーザと同一ユーザに係る、前記所定のアプリケーションに依存する情報を第二の情報提供手段から取得する第二の情報取得手順と、
    前記第一及び第二の情報提供手段より取得された情報を統合する情報統合手順と、
    前記情報統合手順において統合された情報を前記アプリケーションに提供する情報提供手順とを実行させるための情報提供プログラム。
17. 請求項１６記載の情報提供プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images