情報提供装置、情報提供ポータルシステム、情報提供方法、情報提供プログラム
【課題】本発明は、利用者によるデータの改竄を防ぎ、利用者装置及び情報提供装置に対する処理上の負荷を軽減する情報提供装置、情報提供方法及び情報提供プログラムを提供することを目的とする。
【解決手段】本発明の情報提供装置は、各サービスモジュールのポリシー情報として記憶し、利用者装置と情報提供装置間において接続を確立する際に、主セッションＩＤ、及び、サービスセッションＩＤを生成し、利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証し、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行する。
【解決手段】本発明の情報提供装置は、各サービスモジュールのポリシー情報として記憶し、利用者装置と情報提供装置間において接続を確立する際に、主セッションＩＤ、及び、サービスセッションＩＤを生成し、利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証し、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者のリクエストに対して、返答する情報提供装置、情報提供ポータルシステム、情報提供方法及び情報提供プログラムに関する。
【背景技術】
【０００２】
利用者装置のリクエストに対して、返答する情報提供装置としては例えばｗｅｂサーバ等が、利用者装置としては例えばｗｅｂブラウザ等が、提供される情報としてはｗｅｂページ等がある。
【０００３】
ｗｅｂサーバは、ＨＴＭＬ文書や画像などの情報を蓄積しておき、ｗｅｂブラウザのリクエストに応じて、インターネットなどのネットワークを通じて、これらの情報を送信する。これは、以下のような手順により行われる。
【０００４】
利用者がｗｅｂブラウザ上でＵＲＬ（Uniform Resource Locator）を指定する。なお、ＵＲＬとは、インターネット上に存在する情報資源(文書や画像など)の場所を指し示す記述方式であり、情報の種類やサーバ名、ポート番号、フォルダ名、ファイル名などで構成される（例えば、「www.test01.example02.com/sample03/index.html」等）。ｗｅｂブラウザは、ＵＲＬからドメインを抽出する。なお、ドメインとは、インターネット上に存在するコンピュータやネットワークにおける共通して管理される領域を意味し、その識別子をドメイン名（例えば、「www.test01.example02.com」等）という。ｗｅｂブラウザは、抽出したドメインにリクエスト情報を送信する。なお、リクエスト情報とは、メソッド、ＵＲＬ、要求するデータ等を含んだ情報である。
【０００５】
ｗｅｂサーバは、動的にｗｅｂページを生成し、レスポンス情報をｗｅｂブラウザに送信する。なお、レスポンス情報とは、ステータス・コードやレスポンス・フレーズ、応答するデータ等を含む情報である。なお、ｗｅｂページは、表示を担当するＨＴＭＬの部分と、実行可能なJava（登録商標）script等のｗｅｂブラウザ上で稼動するスクリプトの部分から構成されてもよい。なお、スクリプトは、他のｗｅｂページの情報にアクセスできる。但し、アクセスできる範囲は、同じドメインから配信されたｗｅｂページに限定される。この限定は、Same Origin Policyと呼ばれる。つまり、ドメイン「www.test01.example02.com」のｗｅｂページは、同一ドメイン内のｗｅｂページにはアクセスできるが、異なるドメイン「www.test02.example02.com」内のｗｅｂページにアクセスすることはできない。
【０００６】
利用者のｗｅｂページ間の挙動を追跡し、ｗｅｂページが異なるドメイン間でもアクセスすることを可能にする方法として、セッションＩＤを利用する方法がある。なお、セッションとは、一連の通信のことを意味し、例えば、接続を確立してから切断するまでが一つのセッションとすることもできる。セッションＩＤとは、このセッションを一意に特定する識別子のことを意味する。また、セッションＩＤは、利用者とサービス提供者以外の第三者が推測できない情報を利用する。セッションＩＤの発行手順は以下の通りである。ｗｅｂサーバがリクエスト情報を送信した利用者の正当性を検証する。正当性が認められれば（認証）、ｗｅｂサーバは、利用者に対してセッションＩＤを生成し、割り当てる。さらに、ｗｅｂサーバは、利用者とセッションＩＤを記憶部に記憶する。ｗｅｂサーバは、ｗｅｂブラウザに対して、「ドメイン・ＵＲＬのパス・プロトコルが指定と一致するページを有効期限内に訪れる際には、必ずこのセッションＩＤをリクエスト情報に含めよ」という指示をレスポンス情報に含める。以降、ｗｅｂサーバは、リクエスト情報に含まれるセッションＩＤを用いて一連の通信を識別することができる。
【０００７】
ここで、主モジュールと複数のサービスモジュールから構成され、情報を提供するポータルについて考える。なお、サービスモジュールは、ｗｅｂサーバが提供する情報の少なくとも一部を提供する。ポータルは、サービスモジュールを追加、削除することで機能を容易に変更することができる。例えば、利用者の要望に応じてサービスモジュールを追加することなどが考えられる。このような場合には、複数のサービスモジュールは、一つのセッションＩＤを共有する。この場合には、Same Origin Policyにかかわらず、ｗｅｂページは異なるドメインに存在する他のｗｅｂページにもアクセスが可能となる。
【０００８】
しかし、一般的に、開発費の大小や開発者の技術レベルの差異によりサービスモジュールは主モジュールに比べて、セキュリティホールが存在する可能性が高い。一つのセッションＩＤを共有する場合には、複数のサービスモジュールの内の一つのサービスモジュールに欠陥があれば、攻撃者にセッションＩＤを盗難され、利用者になりすまされ、ポータル全体に被害が及ぶ可能性がある。
【０００９】
非特許文献１記載の技術は、１ドメインに１サービスモジュールが対応するという構成である。なお、以下、サービスモジュールが対応する個別のドメインのことをサービスドメインという。セッションＩＤは、サービスモジュール毎に個別のＩＤを利用する。このような構成とすることで、上記、ポータル全体に被害が及ばないようにしている。各サービスモジュールは、Same Origin Policyにより、ドメインが異なる他のサービスモジュールにアクセスできない。なお、Same Origin Policyを用いず、セッションＩＤが異なっても、他のドメインに対しアクセスできる構成とすることは、従来技術同様、ポータル全体に被害が及ぶ可能性がある。そこで非特許文献１記載の技術では、サービスモジュール間のデータの通信は利用者のｗｅｂブラウザ上で実行されるスクリプトを利用し、利用者装置を経由して行う。
【非特許文献１】Collin Jackson, Helen J. Wang," Subspace: Secure Cross-Domain Communication for Web Mashups", [on line], May 8-12 2007, the International World Wide Web Conference Committee (IW3C2), Banff, Alberta, Canada,［平成２００８年１２月９日検索］, インターネット< http://www2007.org/papers/paper801.pdf >
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、非特許文献１記載の技術では、データが利用者の利用者装置（例えば、「ｗｅｂブラウザ」等）を経由するため、利用者によるデータの改竄の可能性があるという問題がある。また、各サービスモジュールは、他のサービスモジュールからデータを取得したい場合には、他のサービスモジュールを起動し、スクリプトによって情報を共有しなければならないため、ｗｅｂサーバ及びｗｅｂブラウザに対する処理上の負荷が増大するという問題がある。また、通信量が増大するという問題がある。
【００１１】
本発明は、セキュリティを高めたまま、スクリプトを利用せずにサービスモジュール間のデータ通信を行い、利用者によるデータの改竄を防ぎ、利用者装置及び情報提供装置に対する処理上の負荷を軽減する情報提供装置、情報提供方法及び情報提供プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の情報提供技術は、サービスモジュールに対する利用者装置のリクエストに返答し、情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、サービスモジュール名とサービスモジュールの識別情報を記憶し、各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶し、利用者装置と情報提供装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成し、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶し、利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証し、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する。
【発明の効果】
【００１３】
本発明の情報提供装置及び情報提供方法によれば、スクリプトを利用せずにサービスモジュール間のデータ通信を行うことができるため、利用者による改竄を防止できる。また、利用者装置及び情報提供装置の処理上の負荷を軽減できる。また、通信量を軽減することができる。
【発明を実施するための最良の形態】
【００１４】
ここで、本発明の実施例について説明する。
【実施例１】
【００１５】
［情報提供ポータルシステム１０］
図１は、利用者装置３と情報提供ポータルシステム１０の関係を示す。図２は、情報提供ポータルシステム１０の構成例を示す。情報提供ポータルシステム１０は、主モジュール１００と、一つ以上のサービスモジュール２００ｎ（１≦ｎ≦Ｎ）から構成され、利用者装置３（例えば、ｗｅｂブラウザ等）の求めに応じて、ネットワーク５（例えば、ＬＡＮやインターネット等）を介して、情報を提供するシステムである。なお、利用者装置３は、ｗｅｂブラウザ等を意味してもよいし、それを実装するコンピュータ等を意味してもよい。主モジュール１００は、情報提供ポータルシステムが情報を提供するために必要となるモジュールである。詳細は後述する。
【００１６】
＜サービスモジュール２００ｎ＞
サービスモジュール２００ｎは、情報提供装置１が提供する情報の少なくとも一部を提供する。例えば、主モジュール１００の実行部１６０に呼び出され、実行部１６０において実行され、情報提供装置の提供するｗｅｂページの一部を作成する。
【００１７】
主モジュール１００は、情報提供ポータルシステム１０を構成する情報提供装置１上に実装される。なお、主モジュールが実装される情報提供装置１００も、情報提供ポータルシステム１０の一部を構成する。サービスモジュール２００ｎは、主モジュール１００と同じドメイン上に実装されてもよいし（例えば、サービスモジュール２００１及び２００２）、主モジュール１００と異なるドメイン上に実装されてもよい（例えば、サービスモジュール２００５）。なお、全てのサービスモジュールが、主モジュールと異なるドメインに実装されてもよい。以下、主モジュールが実装されるドメインを「主ドメイン」、サービスモジュールが実装されるドメインを「サービスドメイン」という。よって、主ドメインと各サービスドメインは同一ドメインの場合もあれば、異なるドメインの場合もある。但し、主ドメインとサービスドメインの少なくとも一部は異なる。このとき、Same Origin Policyにより、異なるドメイン内のモジュールは、スクリプトを利用して、互いにアクセスすることはできない。例えば、各サービスモジュール２００ｎは図示しない記憶部２０８ｎ等を有してもよく、利用者の個人情報等を各記憶部２０８ｎに記憶してもよい。異なるドメイン内のモジュールは、スクリプトを利用して、他の記憶部にアクセスすることはできないため、個人情報等を安全に管理することができる。サービスドメインを管理するＤＮＳ（Domain Name System）サーバには、サービスドメインに対応するＩＰアドレスとして情報提供装置１のＩＰアドレスが登録されている。このような構成とすることで、サービスドメインにアクセスしようとした利用者装置３は、情報提供装置１にアクセスする。
【００１８】
［情報提供装置１］
図３は、情報提供装置１の処理フロー例を示す。情報提供装置１は、通信部７、記憶部８、制御部９、主モジュール１００及びサービスモジュール２００ｎを有する。主モジュール１００は、識別情報記憶部１０５、認証部１１０、ポリシー記憶部１２０、生成部１３０、セッション情報記憶部１４０、検証部１５０、実行部１６０を備える。
なお、本実施例は発明の内容を限定するものではない。例えば、サービスモジュール２００ｎを設けなくともよく、外部のサービスモジュールのみを用いてもよい。
【００１９】
＜通信部７、記憶部８及び制御部９＞
情報提供装置１は、利用者装置３からリクエスト情報が送信されるのを待つ（ｓ１）。利用者装置３からリクエスト情報が送信されると、情報提供装置１は、ネットワーク５及び通信部７を介して、利用者装置３からのリクエスト情報を受信する（ｓ７）。以下、特に記述しなくとも、情報提供装置１及び利用者装置３と通信する際には、通信部７を介して行われるものとする。通信部７は、例えば、ＬＡＮアダプタ等により構成され、ＬＡＮやインターネット等からなるネットワーク５と接続される。
【００２０】
記憶部８は、受信したリクエスト情報を一時的に記憶してもよい。以下、特に示さない限り、入出力される各データや演算過程の各データは、逐一、記憶部８に格納・読み出され、各演算処理が進められる。但し、必ずしも記憶部８に記憶しなければならないわけではなく、各部間で直接データを受け渡してもよい。なお、後述するポリシー記憶部１２０及びセッション情報記憶部１４０は、記憶部９の一部として設けてもよいし、別に設けてもよい。
【００２１】
制御部９は、情報提供装置１において、各処理を制御、実行する。例えば、通信部７を介して、リクエスト情報を受信した際に、制御部９は、主モジュール１００を起動させてもよい。
【００２２】
検証部１５０は、利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する。初めてのアクセスの際には、サービスセッションＩＤはリクエスト情報に含まれないため、情報を提供する前に処理を認証部１１０に移す。サービスセッションＩＤがリクエスト情報に含まれる場合の処理については、後述する。
【００２３】
＜識別情報記憶部１０５＞
識別情報記憶部１０５は、予め各サービスモジュールの識別子（例えば、各サービスモジュールのＵＲＬ等。以下、「サービスモジュール名」という）とサービスモジュールの識別情報を記憶しておく。図４は、識別情報記憶部１０５に記憶されるデータ例を示す。例えば、識別情報としては、ＩＰアドレス等が考えられる。他にＭＡＣアドレス等、サービスモジュールが実装される機器（サーバ等）を識別できる情報であればよい。例えば、図４の２行目、３行目のドメインは「module2.portal.com」であり、同一である。このように一つのサービスドメインに複数のサービスモジュールや識別情報が対応してもよい。また、３行目、４行目の識別情報は、「192.168.200.△△△」であり、同一である。このように一つ識別情報に複数のサービスドメインやサービスモジュールが対応してもよい。
【００２４】
＜認証部１１０＞
図５は、認証部１１０の処理フロー例を示す。認証部１１０は、利用者を認証する（ｓ１１０）。例えば、リクエスト情報を送信した利用者装置３に対し、認証情報を要求する（ｓ１１２）。認証情報としては、例えば、利用者ＩＤとパスワード、指紋情報等の生体認証に用いる認証情報が考えられる。利用者装置３は、認証情報を情報提供装置１へ送信する。認証部１１０は、認証情報を受信し（ｓ１１４）、図示していない認証情報データベース等を参照し、利用者装置３の正当性を確認する（ｓ１１６）。正当性が確認できない場合には、エラーを出力する（ｓ１１７）。また、利用者装置３の要求を拒否してもよいし、再度認証情報を要求してもよい。正当性が確認できる場合には、生成部１３０に処理を移す（ｓ１１８）。
【００２５】
なお、非特許文献１記載の技術を用いて、利用者を認証する場合には、各サービスモジュールに利用者装置がアクセスする際に、各サービスモジュールにより認証を行う必要があり、処理量及び通信量が増大する。また、前述の通り、サービスモジュールは主モジュールに比べて、セキュリティホールが存在する可能性が高く、攻撃者に狙われやすい。主モジュールに認証部１１０を有することによって、集中管理することによりセキュリティを高めることができる。また、認証を一括することにより処理量及び通信量を軽減することができる。
【００２６】
なお、本実施例は発明の内容を限定するものではない。必ずしも認証部１１０は、認証情報を要求せずともよい。例えば、リクエスト情報を受信した際に得られる送信元ＩＰアドレス等によって認証してもよい。この場合、上記「利用者」とは、必ずしも「利用者自身」を意味せずともよく、例えば、「利用者装置」を意味してもよい。また、例えば、利用者装置の正当性を確認する必要がない場合には、認証部１１０を設けなくともよい。
【００２７】
＜ポリシー記憶部１２０＞
ポリシー記憶部１２０は、サービスモジュール名とそのサービスモジュールの権限をポリシー情報として予め記憶しておく。図６は、ポリシー記憶部１２０に記憶されるデータ例を示す。権限としては、アクセスできる範囲や処理内容等がある。例えば、図６に沿って説明すると、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをする権限を有していることを意味する。また、例えば、アクセスできる範囲には、サービスモジュールだけではなく、サービスモジュールの有するデータ項目まで、範囲を限定することも可能である。例えば、主モジュールは、あるサービスモジュール２００ｎからデータ項目「年齢」だけを「読込み」をすることができるといった構成とすることも可能である。
【００２８】
＜生成部１３０＞
図７は、生成部１３０の処理フロー例を示す。生成部１３０は、利用者装置３と情報提供装置１間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置３と各サービスモジュール２００ｎとの接続を一意に識別するサービスセッションＩＤを生成する（ｓ１３０）。例えば、生成部１３０は、リクエスト情報から用いるサービスモジュール名を特定し（ｓ１３１）、対応する主セッションＩＤ及びサービスセッションＩＤを生成し（ｓ１３３）、さらに、ポリシー記憶部１２０を参照し、特定したサービスモジュール名に対応するポリシー情報を取得し（ｓ１３５）、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及びポリシー情報をセッション情報記憶部１４０に出力する（ｓ１３７）。なお、以下、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及びこれに対応するポリシー情報を併せてセッション情報という。なお、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値とは、主セッションＩＤ、サービスセッションＩＤ自体であってもよいし、そこから得ることができる値であってもよい。例えば、主セッションＩＤ、サービスセッションＩＤから得ることができるハッシュ値や暗号処理した値等が考えられる。サービスセッションＩＤは、サービスモジュール間で、共有させないため、非特許文献同様、ポータル全体に被害が及ぶことはない。
【００２９】
情報提供装置１は、サービスセッションＩＤとともに、「ドメイン・ＵＲＬのパス・プロトコルが指定と一致するページを有効期限内に訪れる際には、必ずこのサービスセッションＩＤをリクエスト情報に含めよ」という指示をレスポンス情報に加える。
例えば、クッキー（Cookie）等を用いて、以降のリクエスト情報にはサービスセッションＩＤを付加する。なお、主セッションＩＤもリクエスト情報に含めるよう指示してもよい。
【００３０】
＜セッション情報記憶部１４０＞
セッション情報記憶部１４０は、セッション情報を記憶する（ｓ１４０）。図８は、セッション情報記憶部１４０に記憶されるデータ例を示す。例えば、主セッションＩＤが「osdkmasgaso」であり、かつ、サービスセッションＩＤが「agq3qvw4tq24」である接続は、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをすることができる。主セッションＩＤは、主モジュール（または、情報提供装置１）と利用者装置３とのセッションを管理し、サービスセッションＩＤは、サービスモジュール２００ｎと利用者装置３とのセッションを管理する。よって、複数のサービスモジュール２００ｎを呼び出す場合には、一つの主セッションＩＤに複数のサービスセッションＩＤが対応することとなる。また、情報提供装置１は、リクエスト情報にサービスセッションＩＤのみ含まれる場合であっても、セッション情報記憶部１４０のデータから、主セッションＩＤを特定することができる。なお、ポリシー情報として主セッションＩＤ、サービスセッションＩＤから得ることができるハッシュ値や暗号処理した値等を用いた場合には、セッション情報記憶部１４０が覗き見られた場合であっても、攻撃者は主セッションＩＤ、サービスセッションＩＤが分からない。よって、攻撃者が利用者になりすますことを防止できる。また、ハッシュ値等を用いて記憶する情報量を軽減してもよい。
【００３１】
＜検証部１５０＞
図９は、検証部１５０の処理フロー例を示す。検証部１５０は、利用者装置３からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する（ｓ１５０）。例えば、検証部１５０は、利用者装置３からのリクエスト情報に含まれるサービスセッションＩＤがセッション情報記憶部に存在するか否か確認することにより有効性を検証する。検証部１５０は、リクエスト情報を入力され、前述の通り利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する（ｓ１５１）。前述の通り含まれない場合には、処理を認証部１１０に移す（ｓ１５３）。サービスセッションＩＤがリクエスト情報に含まれる場合には、セッション情報記憶部１４０を参照し、このサービスセッションＩＤが存在するか否か確認し（ｓ１５５）、存在する場合には処理を実行部１６０に移し（ｓ１５７）、存在しない場合には処理を認証部に移す（ｓ１５３）。なお、認証部に処理を移す前に、「セッションの有効期限が切れた」旨のメッセージを利用者装置３に送信してもよい。なお、セッション情報記憶部１４０にサービスセッションＩＤのハッシュ値等が記憶されている場合には、同じハッシュ関数等を用いて、リクエスト情報に含まれるサービスセッションＩＤからハッシュ値を求め、同様に有効性を検証する。
【００３２】
＜実行部１６０＞
図１０は、実行部１６０の処理フロー例を示す。実行部１６０は、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部１０５を参照して対応するサービスモジュールの識別情報を取得する。また、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行する。ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する（ｓ１６０）。例えば、実行部１６０は、リクエスト情報が入力され、リクエスト情報に含まれるＵＲＬからサービスモジュール名を抽出し、識別情報記憶部１０５を参照し、サービスモジュールの識別情報を取得する（ｓ１６１）。さらに、リクエスト情報に含まれるサービスセッションＩＤから、セッション情報記憶部１４０を参照し、ポリシー情報を取得する（ｓ１６２）。但し、セッション情報記憶部１４０を参照せずに、生成部１３０から直接セッション情報を受け取る構成としてもよい。リクエスト情報がポリシー情報に従っているか確認し（ｓ１６３）、リクエスト情報がポリシー情報に従っている場合には、サービスモジュールを呼び出し、実行する（ｓ１６５）。処理結果をレスポンス情報の少なくとも一部として出力する（ｓ１６６）。従っていない場合には、エラーを出力する（ｓ１６７）。
【００３３】
情報提供装置１は、レスポンス情報を利用者装置３に送信し、情報を提供する。なお、一つのセッションの間に、複数のサービスモジュールにアクセスしてもよい。その際は、生成部１３０において、対応する複数のサービスセッションＩＤを生成する。
【００３４】
このような構成とすることで、各サービスモジュールに対し、サービスセッションＩＤを設け、非特許文献１記載の従来技術と同等のセキュリティを有することができる。さらに、スクリプトを利用せずにサービスモジュール間のデータ通信を行うことができるため、利用者による改竄を防止できる。また、利用者装置及び情報提供装置の処理上の負荷を軽減できる。また、通信量を軽減することができる。
【００３５】
＜ハードウェア構成＞
図１１は、本実施例における情報提供装置１のハードウェア構成を例示したブロック図である。
図１１に例示するように、この例の情報提供装置１は、ＣＰＵ（Central Processing Unit）１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ（Read Only Memory）１５、ＲＡＭ（Random Access Memory）１６及びバス１７を有している。
【００３６】
この例のＣＰＵ１１は、制御部１１ａ、演算部１１ｂ及びレジスタ１１ｃを有し、レジスタ１１ｃに読み込まれた各種プログラムに従って様々な演算処理を実行する。また、入力部１２は、データが入力される入力インターフェース、キーボード、マウス等であり、出力部１３は、データが出力される出力インターフェース等である。補助記憶装置１４は、例えば、ハードディスク、ＭＯ（Magneto-Optical disc）、半導体メモリ等であり、情報提供装置１としてコンピュータを機能させるためのプログラムが格納されるプログラム領域１４ａ及び各種データが格納されるデータ領域１４ｂを有している。また、ＲＡＭ１６は、ＳＲＡＭ (Static Random Access Memory)、ＤＲＡＭ (Dynamic Random Access Memory)等であり、上記のプログラムが格納されるプログラム領域１６ａ及び各種データが格納されるデータ領域１６ｂを有している。また、バス１７は、ＣＰＵ１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ１５及びＲＡＭ１６を通信可能に接続する。
【００３７】
なお、このようなハードウェアの具体例としては、例えば、パーソナルコンピュータの他、サーバ装置やワークステーション等を例示できる。
【００３８】
＜プログラム構成＞
上述のように、プログラム領域１４ａ，１６ａには、本実施例の情報提供装置１の各処理を実行するための各プログラムが格納される。情報提供名プログラムを構成する各プログラムは、単一のプログラム列として記載されていてもよく、また、少なくとも一部のプログラムが別個のモジュールとしてライブラリに格納されていてもよい。また、各プログラムが単体でそれぞれの機能を実現してもよいし、各プログラムがさらに他のライブラリを読み出して各機能を実現するものでもよい。
【００３９】
＜ハードウェアとプログラムとの協働＞
ＣＰＵ１１（図１１）は、読み込まれたＯＳ（Operating System）プログラムに従い、補助記憶装置１４のプログラム領域１４ａに格納されている上述のプログラムをＲＡＭ１６のプログラム領域１６ａに書き込む。同様にＣＰＵ１１は、補助記憶装置１４のデータ領域１４ｂに格納されている各種データを、ＲＡＭ１６のデータ領域１６ｂに書き込む。そして、このプログラムやデータが書き込まれたＲＡＭ１６上のアドレスがＣＰＵ１１のレジスタ１１ｃに格納される。ＣＰＵ１１の制御部１１ａは、レジスタ１１ｃに格納されたこれらのアドレスを順次読み出し、読み出したアドレスが示すＲＡＭ１６上の領域からプログラムやデータを読み出し、そのプログラムが示す演算を演算部１１ｂに順次実行させ、その演算結果をレジスタ１１ｃに格納していく。
【００４０】
図１は、このようにＣＰＵ１１に上述のプログラムが読み込まれて実行されることにより構成される情報提供装置１の機能構成を例示したブロック図である。
【００４１】
ここで、記憶部８、ポリシー記憶部１２０及びセッション情報記憶部１４０は、補助記憶装置１４、ＲＡＭ１６、レジスタ１１ｃ、その他のバッファメモリやキャッシュメモリ等の何れか、あるいはこれらを併用した記憶領域に相当する。また、通信部７と、記憶部８と、制御部９と、認証部１１０と、生成部１３０と、検証部１５０と、実行部１６０は、ＣＰＵ１１に情報提供プログラムを実行させることにより構成されるものである。
また、本形態の情報提供装置１は、各制御部９の制御のもと各処理を実行する。
【００４２】
［変形例１］認証用サービスモジュール
実施例１と異なる部分についてのみ説明する。変形例１の情報提供装置１は、認証部１１０を有さない。情報提供ポータルシステム１０は、認証用サービスモジュール２００３を有する。さらに、認証処理を分散するために認証用サービスモジュール２００４等を有してもよい。
【００４３】
認証用サービスモジュール２００３等は、利用者を認証する。例えば、このような構成とした場合、検証部１５０は、リクエスト情報を入力され、利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する。含まれない場合、または、含まれるが、セッション情報記憶部１４０に存在しない場合には、認証用サービスモジュール２００３を呼び出す。認証用サービスモジュールの呼び出し方法は、実施例１と同様であってもよいし、他の方法であってもよい。他の方法としては、認証用サービスモジュールの識別情報は、別途記憶部８に記憶しておき、識別情報記憶部１０５を参照せずに、呼び出してもよい。次に、実行部１６０において、認証用サービスモジュールを実行する。認証処理は、認証部１３０と同様である。
【００４４】
このような構成とすることで複数の認証処理を行うことが可能となり、処理を分散することができる。また、モジュール毎に認証の強度を容易に変更することができる。例えば、一つの認証用サービスモジュールでは、利用者ＩＤ、パスワードのみで認証可能だが、他の認証用サービスモジュールでは、利用者ＩＤ、パスワードに加え、バイオメトリクス認証情報等を必要としてもよい。なお、認証用サービスモジュールは、主ドメイン内であっても、主ドメイン外であってもよい。
【００４５】
［変形例２］ユーザＩＤによるアクセス制限
実施例１と異なる部分についてのみ説明する。変形例２の情報提供装置１は、ポリシー記憶部１２０に記憶されるデータが実施例１とは異なる。図１２は、変形例２のポリシー情報記憶部１２０に記憶されるデータ例を示す。ポリシー記憶部１２０は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する。図１２を用いて説明する。例えば、図１２に沿って説明すると、利用者「user_A」の場合には、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、読込みをする権限は有さず、書込みをする権限を有している。一方、利用者「user_B」の場合には、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをする権限は有さず、読込みをする権限を有していることを意味する。
【００４６】
例えば、生成部１３０は、主セッションＩＤ及びサービスセッションＩＤを生成する際に、リクエスト情報から用いるサービスモジュール名と利用者を特定し、対応する主セッションＩＤ及びサービスセッションＩＤを生成する。さらに、ポリシー記憶部１２０を参照し、特定したサービスモジュール名と利用者の組合せに対応するポリシー情報を取得し、主セッションＩＤ及びサービスセッションＩＤ、及びポリシー情報をセッション情報記憶部１４０に出力する。
【００４７】
このような構成とすることで利用者毎に柔軟にポリシーを設定することができる。ポリシー情報の設定変更は、利用者側が行ってもよいし、情報提供装置の管理者が行ってもよい。利用者が行う構成とする場合には、例えば、保護者が未成年者の有害なサイトへのアクセスを制限することができる。また、管理者側が行う構成とする場合には、特定のサービスに申し込みをしている利用者のみに、そのサービスを受けることができるように設定することができる。また、サービスモジュール毎にポリシーを設定することで、ポータルが提供できるサービスの組合せのバリエーションを多数用意することができる。用意したサービスの組合せを選択する構成としてもよい。
【図面の簡単な説明】
【００４８】
【図１】利用者装置３と情報提供ポータルシステム１０の関係を示す図。
【図２】情報提供ポータルシステム１０の構成例を示す図。
【図３】情報提供装置１の処理フロー例を示す図。
【図４】識別情報記憶部１０５に記憶されるデータ例を示す図。
【図５】認証部１１０の処理フロー例を示す図。
【図６】ポリシー記憶部１２０に記憶されるデータ例を示す図。
【図７】生成部１３０の処理フロー例を示す図。
【図８】セッション情報記憶部１４０に記憶されるデータ例を示す図。
【図９】検証部１５０の処理フロー例を示す図。
【図１０】実行部１６０の処理フロー例を示す図。
【図１１】本実施例における情報提供装置１のハードウェア構成を例示したブロック図。
【図１２】変形例２のポリシー情報記憶部１２０に記憶されるデータ例を示す図。
【符号の説明】
【００４９】
１ 情報提供装置 １０ 情報提供ポータルシステム
７ 通信部 ８ 記憶部
９ 制御部 １０５ 識別情報記憶部
１１０ 認証部 １２０ ポリシー記憶部
１３０ 生成部 １４０ セッション情報記憶部
１５０ 検証部 １６０ 実行部
【技術分野】
【０００１】
本発明は、利用者のリクエストに対して、返答する情報提供装置、情報提供ポータルシステム、情報提供方法及び情報提供プログラムに関する。
【背景技術】
【０００２】
利用者装置のリクエストに対して、返答する情報提供装置としては例えばｗｅｂサーバ等が、利用者装置としては例えばｗｅｂブラウザ等が、提供される情報としてはｗｅｂページ等がある。
【０００３】
ｗｅｂサーバは、ＨＴＭＬ文書や画像などの情報を蓄積しておき、ｗｅｂブラウザのリクエストに応じて、インターネットなどのネットワークを通じて、これらの情報を送信する。これは、以下のような手順により行われる。
【０００４】
利用者がｗｅｂブラウザ上でＵＲＬ（Uniform Resource Locator）を指定する。なお、ＵＲＬとは、インターネット上に存在する情報資源(文書や画像など)の場所を指し示す記述方式であり、情報の種類やサーバ名、ポート番号、フォルダ名、ファイル名などで構成される（例えば、「www.test01.example02.com/sample03/index.html」等）。ｗｅｂブラウザは、ＵＲＬからドメインを抽出する。なお、ドメインとは、インターネット上に存在するコンピュータやネットワークにおける共通して管理される領域を意味し、その識別子をドメイン名（例えば、「www.test01.example02.com」等）という。ｗｅｂブラウザは、抽出したドメインにリクエスト情報を送信する。なお、リクエスト情報とは、メソッド、ＵＲＬ、要求するデータ等を含んだ情報である。
【０００５】
ｗｅｂサーバは、動的にｗｅｂページを生成し、レスポンス情報をｗｅｂブラウザに送信する。なお、レスポンス情報とは、ステータス・コードやレスポンス・フレーズ、応答するデータ等を含む情報である。なお、ｗｅｂページは、表示を担当するＨＴＭＬの部分と、実行可能なJava（登録商標）script等のｗｅｂブラウザ上で稼動するスクリプトの部分から構成されてもよい。なお、スクリプトは、他のｗｅｂページの情報にアクセスできる。但し、アクセスできる範囲は、同じドメインから配信されたｗｅｂページに限定される。この限定は、Same Origin Policyと呼ばれる。つまり、ドメイン「www.test01.example02.com」のｗｅｂページは、同一ドメイン内のｗｅｂページにはアクセスできるが、異なるドメイン「www.test02.example02.com」内のｗｅｂページにアクセスすることはできない。
【０００６】
利用者のｗｅｂページ間の挙動を追跡し、ｗｅｂページが異なるドメイン間でもアクセスすることを可能にする方法として、セッションＩＤを利用する方法がある。なお、セッションとは、一連の通信のことを意味し、例えば、接続を確立してから切断するまでが一つのセッションとすることもできる。セッションＩＤとは、このセッションを一意に特定する識別子のことを意味する。また、セッションＩＤは、利用者とサービス提供者以外の第三者が推測できない情報を利用する。セッションＩＤの発行手順は以下の通りである。ｗｅｂサーバがリクエスト情報を送信した利用者の正当性を検証する。正当性が認められれば（認証）、ｗｅｂサーバは、利用者に対してセッションＩＤを生成し、割り当てる。さらに、ｗｅｂサーバは、利用者とセッションＩＤを記憶部に記憶する。ｗｅｂサーバは、ｗｅｂブラウザに対して、「ドメイン・ＵＲＬのパス・プロトコルが指定と一致するページを有効期限内に訪れる際には、必ずこのセッションＩＤをリクエスト情報に含めよ」という指示をレスポンス情報に含める。以降、ｗｅｂサーバは、リクエスト情報に含まれるセッションＩＤを用いて一連の通信を識別することができる。
【０００７】
ここで、主モジュールと複数のサービスモジュールから構成され、情報を提供するポータルについて考える。なお、サービスモジュールは、ｗｅｂサーバが提供する情報の少なくとも一部を提供する。ポータルは、サービスモジュールを追加、削除することで機能を容易に変更することができる。例えば、利用者の要望に応じてサービスモジュールを追加することなどが考えられる。このような場合には、複数のサービスモジュールは、一つのセッションＩＤを共有する。この場合には、Same Origin Policyにかかわらず、ｗｅｂページは異なるドメインに存在する他のｗｅｂページにもアクセスが可能となる。
【０００８】
しかし、一般的に、開発費の大小や開発者の技術レベルの差異によりサービスモジュールは主モジュールに比べて、セキュリティホールが存在する可能性が高い。一つのセッションＩＤを共有する場合には、複数のサービスモジュールの内の一つのサービスモジュールに欠陥があれば、攻撃者にセッションＩＤを盗難され、利用者になりすまされ、ポータル全体に被害が及ぶ可能性がある。
【０００９】
非特許文献１記載の技術は、１ドメインに１サービスモジュールが対応するという構成である。なお、以下、サービスモジュールが対応する個別のドメインのことをサービスドメインという。セッションＩＤは、サービスモジュール毎に個別のＩＤを利用する。このような構成とすることで、上記、ポータル全体に被害が及ばないようにしている。各サービスモジュールは、Same Origin Policyにより、ドメインが異なる他のサービスモジュールにアクセスできない。なお、Same Origin Policyを用いず、セッションＩＤが異なっても、他のドメインに対しアクセスできる構成とすることは、従来技術同様、ポータル全体に被害が及ぶ可能性がある。そこで非特許文献１記載の技術では、サービスモジュール間のデータの通信は利用者のｗｅｂブラウザ上で実行されるスクリプトを利用し、利用者装置を経由して行う。
【非特許文献１】Collin Jackson, Helen J. Wang," Subspace: Secure Cross-Domain Communication for Web Mashups", [on line], May 8-12 2007, the International World Wide Web Conference Committee (IW3C2), Banff, Alberta, Canada,［平成２００８年１２月９日検索］, インターネット< http://www2007.org/papers/paper801.pdf >
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、非特許文献１記載の技術では、データが利用者の利用者装置（例えば、「ｗｅｂブラウザ」等）を経由するため、利用者によるデータの改竄の可能性があるという問題がある。また、各サービスモジュールは、他のサービスモジュールからデータを取得したい場合には、他のサービスモジュールを起動し、スクリプトによって情報を共有しなければならないため、ｗｅｂサーバ及びｗｅｂブラウザに対する処理上の負荷が増大するという問題がある。また、通信量が増大するという問題がある。
【００１１】
本発明は、セキュリティを高めたまま、スクリプトを利用せずにサービスモジュール間のデータ通信を行い、利用者によるデータの改竄を防ぎ、利用者装置及び情報提供装置に対する処理上の負荷を軽減する情報提供装置、情報提供方法及び情報提供プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の情報提供技術は、サービスモジュールに対する利用者装置のリクエストに返答し、情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、サービスモジュール名とサービスモジュールの識別情報を記憶し、各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶し、利用者装置と情報提供装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成し、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶し、利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証し、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する。
【発明の効果】
【００１３】
本発明の情報提供装置及び情報提供方法によれば、スクリプトを利用せずにサービスモジュール間のデータ通信を行うことができるため、利用者による改竄を防止できる。また、利用者装置及び情報提供装置の処理上の負荷を軽減できる。また、通信量を軽減することができる。
【発明を実施するための最良の形態】
【００１４】
ここで、本発明の実施例について説明する。
【実施例１】
【００１５】
［情報提供ポータルシステム１０］
図１は、利用者装置３と情報提供ポータルシステム１０の関係を示す。図２は、情報提供ポータルシステム１０の構成例を示す。情報提供ポータルシステム１０は、主モジュール１００と、一つ以上のサービスモジュール２００ｎ（１≦ｎ≦Ｎ）から構成され、利用者装置３（例えば、ｗｅｂブラウザ等）の求めに応じて、ネットワーク５（例えば、ＬＡＮやインターネット等）を介して、情報を提供するシステムである。なお、利用者装置３は、ｗｅｂブラウザ等を意味してもよいし、それを実装するコンピュータ等を意味してもよい。主モジュール１００は、情報提供ポータルシステムが情報を提供するために必要となるモジュールである。詳細は後述する。
【００１６】
＜サービスモジュール２００ｎ＞
サービスモジュール２００ｎは、情報提供装置１が提供する情報の少なくとも一部を提供する。例えば、主モジュール１００の実行部１６０に呼び出され、実行部１６０において実行され、情報提供装置の提供するｗｅｂページの一部を作成する。
【００１７】
主モジュール１００は、情報提供ポータルシステム１０を構成する情報提供装置１上に実装される。なお、主モジュールが実装される情報提供装置１００も、情報提供ポータルシステム１０の一部を構成する。サービスモジュール２００ｎは、主モジュール１００と同じドメイン上に実装されてもよいし（例えば、サービスモジュール２００１及び２００２）、主モジュール１００と異なるドメイン上に実装されてもよい（例えば、サービスモジュール２００５）。なお、全てのサービスモジュールが、主モジュールと異なるドメインに実装されてもよい。以下、主モジュールが実装されるドメインを「主ドメイン」、サービスモジュールが実装されるドメインを「サービスドメイン」という。よって、主ドメインと各サービスドメインは同一ドメインの場合もあれば、異なるドメインの場合もある。但し、主ドメインとサービスドメインの少なくとも一部は異なる。このとき、Same Origin Policyにより、異なるドメイン内のモジュールは、スクリプトを利用して、互いにアクセスすることはできない。例えば、各サービスモジュール２００ｎは図示しない記憶部２０８ｎ等を有してもよく、利用者の個人情報等を各記憶部２０８ｎに記憶してもよい。異なるドメイン内のモジュールは、スクリプトを利用して、他の記憶部にアクセスすることはできないため、個人情報等を安全に管理することができる。サービスドメインを管理するＤＮＳ（Domain Name System）サーバには、サービスドメインに対応するＩＰアドレスとして情報提供装置１のＩＰアドレスが登録されている。このような構成とすることで、サービスドメインにアクセスしようとした利用者装置３は、情報提供装置１にアクセスする。
【００１８】
［情報提供装置１］
図３は、情報提供装置１の処理フロー例を示す。情報提供装置１は、通信部７、記憶部８、制御部９、主モジュール１００及びサービスモジュール２００ｎを有する。主モジュール１００は、識別情報記憶部１０５、認証部１１０、ポリシー記憶部１２０、生成部１３０、セッション情報記憶部１４０、検証部１５０、実行部１６０を備える。
なお、本実施例は発明の内容を限定するものではない。例えば、サービスモジュール２００ｎを設けなくともよく、外部のサービスモジュールのみを用いてもよい。
【００１９】
＜通信部７、記憶部８及び制御部９＞
情報提供装置１は、利用者装置３からリクエスト情報が送信されるのを待つ（ｓ１）。利用者装置３からリクエスト情報が送信されると、情報提供装置１は、ネットワーク５及び通信部７を介して、利用者装置３からのリクエスト情報を受信する（ｓ７）。以下、特に記述しなくとも、情報提供装置１及び利用者装置３と通信する際には、通信部７を介して行われるものとする。通信部７は、例えば、ＬＡＮアダプタ等により構成され、ＬＡＮやインターネット等からなるネットワーク５と接続される。
【００２０】
記憶部８は、受信したリクエスト情報を一時的に記憶してもよい。以下、特に示さない限り、入出力される各データや演算過程の各データは、逐一、記憶部８に格納・読み出され、各演算処理が進められる。但し、必ずしも記憶部８に記憶しなければならないわけではなく、各部間で直接データを受け渡してもよい。なお、後述するポリシー記憶部１２０及びセッション情報記憶部１４０は、記憶部９の一部として設けてもよいし、別に設けてもよい。
【００２１】
制御部９は、情報提供装置１において、各処理を制御、実行する。例えば、通信部７を介して、リクエスト情報を受信した際に、制御部９は、主モジュール１００を起動させてもよい。
【００２２】
検証部１５０は、利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する。初めてのアクセスの際には、サービスセッションＩＤはリクエスト情報に含まれないため、情報を提供する前に処理を認証部１１０に移す。サービスセッションＩＤがリクエスト情報に含まれる場合の処理については、後述する。
【００２３】
＜識別情報記憶部１０５＞
識別情報記憶部１０５は、予め各サービスモジュールの識別子（例えば、各サービスモジュールのＵＲＬ等。以下、「サービスモジュール名」という）とサービスモジュールの識別情報を記憶しておく。図４は、識別情報記憶部１０５に記憶されるデータ例を示す。例えば、識別情報としては、ＩＰアドレス等が考えられる。他にＭＡＣアドレス等、サービスモジュールが実装される機器（サーバ等）を識別できる情報であればよい。例えば、図４の２行目、３行目のドメインは「module2.portal.com」であり、同一である。このように一つのサービスドメインに複数のサービスモジュールや識別情報が対応してもよい。また、３行目、４行目の識別情報は、「192.168.200.△△△」であり、同一である。このように一つ識別情報に複数のサービスドメインやサービスモジュールが対応してもよい。
【００２４】
＜認証部１１０＞
図５は、認証部１１０の処理フロー例を示す。認証部１１０は、利用者を認証する（ｓ１１０）。例えば、リクエスト情報を送信した利用者装置３に対し、認証情報を要求する（ｓ１１２）。認証情報としては、例えば、利用者ＩＤとパスワード、指紋情報等の生体認証に用いる認証情報が考えられる。利用者装置３は、認証情報を情報提供装置１へ送信する。認証部１１０は、認証情報を受信し（ｓ１１４）、図示していない認証情報データベース等を参照し、利用者装置３の正当性を確認する（ｓ１１６）。正当性が確認できない場合には、エラーを出力する（ｓ１１７）。また、利用者装置３の要求を拒否してもよいし、再度認証情報を要求してもよい。正当性が確認できる場合には、生成部１３０に処理を移す（ｓ１１８）。
【００２５】
なお、非特許文献１記載の技術を用いて、利用者を認証する場合には、各サービスモジュールに利用者装置がアクセスする際に、各サービスモジュールにより認証を行う必要があり、処理量及び通信量が増大する。また、前述の通り、サービスモジュールは主モジュールに比べて、セキュリティホールが存在する可能性が高く、攻撃者に狙われやすい。主モジュールに認証部１１０を有することによって、集中管理することによりセキュリティを高めることができる。また、認証を一括することにより処理量及び通信量を軽減することができる。
【００２６】
なお、本実施例は発明の内容を限定するものではない。必ずしも認証部１１０は、認証情報を要求せずともよい。例えば、リクエスト情報を受信した際に得られる送信元ＩＰアドレス等によって認証してもよい。この場合、上記「利用者」とは、必ずしも「利用者自身」を意味せずともよく、例えば、「利用者装置」を意味してもよい。また、例えば、利用者装置の正当性を確認する必要がない場合には、認証部１１０を設けなくともよい。
【００２７】
＜ポリシー記憶部１２０＞
ポリシー記憶部１２０は、サービスモジュール名とそのサービスモジュールの権限をポリシー情報として予め記憶しておく。図６は、ポリシー記憶部１２０に記憶されるデータ例を示す。権限としては、アクセスできる範囲や処理内容等がある。例えば、図６に沿って説明すると、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをする権限を有していることを意味する。また、例えば、アクセスできる範囲には、サービスモジュールだけではなく、サービスモジュールの有するデータ項目まで、範囲を限定することも可能である。例えば、主モジュールは、あるサービスモジュール２００ｎからデータ項目「年齢」だけを「読込み」をすることができるといった構成とすることも可能である。
【００２８】
＜生成部１３０＞
図７は、生成部１３０の処理フロー例を示す。生成部１３０は、利用者装置３と情報提供装置１間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置３と各サービスモジュール２００ｎとの接続を一意に識別するサービスセッションＩＤを生成する（ｓ１３０）。例えば、生成部１３０は、リクエスト情報から用いるサービスモジュール名を特定し（ｓ１３１）、対応する主セッションＩＤ及びサービスセッションＩＤを生成し（ｓ１３３）、さらに、ポリシー記憶部１２０を参照し、特定したサービスモジュール名に対応するポリシー情報を取得し（ｓ１３５）、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及びポリシー情報をセッション情報記憶部１４０に出力する（ｓ１３７）。なお、以下、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値及びこれに対応するポリシー情報を併せてセッション情報という。なお、主セッションＩＤから得ることができる値、サービスセッションＩＤから得ることができる値とは、主セッションＩＤ、サービスセッションＩＤ自体であってもよいし、そこから得ることができる値であってもよい。例えば、主セッションＩＤ、サービスセッションＩＤから得ることができるハッシュ値や暗号処理した値等が考えられる。サービスセッションＩＤは、サービスモジュール間で、共有させないため、非特許文献同様、ポータル全体に被害が及ぶことはない。
【００２９】
情報提供装置１は、サービスセッションＩＤとともに、「ドメイン・ＵＲＬのパス・プロトコルが指定と一致するページを有効期限内に訪れる際には、必ずこのサービスセッションＩＤをリクエスト情報に含めよ」という指示をレスポンス情報に加える。
例えば、クッキー（Cookie）等を用いて、以降のリクエスト情報にはサービスセッションＩＤを付加する。なお、主セッションＩＤもリクエスト情報に含めるよう指示してもよい。
【００３０】
＜セッション情報記憶部１４０＞
セッション情報記憶部１４０は、セッション情報を記憶する（ｓ１４０）。図８は、セッション情報記憶部１４０に記憶されるデータ例を示す。例えば、主セッションＩＤが「osdkmasgaso」であり、かつ、サービスセッションＩＤが「agq3qvw4tq24」である接続は、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをすることができる。主セッションＩＤは、主モジュール（または、情報提供装置１）と利用者装置３とのセッションを管理し、サービスセッションＩＤは、サービスモジュール２００ｎと利用者装置３とのセッションを管理する。よって、複数のサービスモジュール２００ｎを呼び出す場合には、一つの主セッションＩＤに複数のサービスセッションＩＤが対応することとなる。また、情報提供装置１は、リクエスト情報にサービスセッションＩＤのみ含まれる場合であっても、セッション情報記憶部１４０のデータから、主セッションＩＤを特定することができる。なお、ポリシー情報として主セッションＩＤ、サービスセッションＩＤから得ることができるハッシュ値や暗号処理した値等を用いた場合には、セッション情報記憶部１４０が覗き見られた場合であっても、攻撃者は主セッションＩＤ、サービスセッションＩＤが分からない。よって、攻撃者が利用者になりすますことを防止できる。また、ハッシュ値等を用いて記憶する情報量を軽減してもよい。
【００３１】
＜検証部１５０＞
図９は、検証部１５０の処理フロー例を示す。検証部１５０は、利用者装置３からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する（ｓ１５０）。例えば、検証部１５０は、利用者装置３からのリクエスト情報に含まれるサービスセッションＩＤがセッション情報記憶部に存在するか否か確認することにより有効性を検証する。検証部１５０は、リクエスト情報を入力され、前述の通り利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する（ｓ１５１）。前述の通り含まれない場合には、処理を認証部１１０に移す（ｓ１５３）。サービスセッションＩＤがリクエスト情報に含まれる場合には、セッション情報記憶部１４０を参照し、このサービスセッションＩＤが存在するか否か確認し（ｓ１５５）、存在する場合には処理を実行部１６０に移し（ｓ１５７）、存在しない場合には処理を認証部に移す（ｓ１５３）。なお、認証部に処理を移す前に、「セッションの有効期限が切れた」旨のメッセージを利用者装置３に送信してもよい。なお、セッション情報記憶部１４０にサービスセッションＩＤのハッシュ値等が記憶されている場合には、同じハッシュ関数等を用いて、リクエスト情報に含まれるサービスセッションＩＤからハッシュ値を求め、同様に有効性を検証する。
【００３２】
＜実行部１６０＞
図１０は、実行部１６０の処理フロー例を示す。実行部１６０は、リクエスト情報に含まれるサービスモジュール名を用いて、識別情報記憶部１０５を参照して対応するサービスモジュールの識別情報を取得する。また、サービスセッションＩＤに対応付けられるセッション情報と識別情報を用いて、サービスモジュールを呼び出し、実行する。ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する（ｓ１６０）。例えば、実行部１６０は、リクエスト情報が入力され、リクエスト情報に含まれるＵＲＬからサービスモジュール名を抽出し、識別情報記憶部１０５を参照し、サービスモジュールの識別情報を取得する（ｓ１６１）。さらに、リクエスト情報に含まれるサービスセッションＩＤから、セッション情報記憶部１４０を参照し、ポリシー情報を取得する（ｓ１６２）。但し、セッション情報記憶部１４０を参照せずに、生成部１３０から直接セッション情報を受け取る構成としてもよい。リクエスト情報がポリシー情報に従っているか確認し（ｓ１６３）、リクエスト情報がポリシー情報に従っている場合には、サービスモジュールを呼び出し、実行する（ｓ１６５）。処理結果をレスポンス情報の少なくとも一部として出力する（ｓ１６６）。従っていない場合には、エラーを出力する（ｓ１６７）。
【００３３】
情報提供装置１は、レスポンス情報を利用者装置３に送信し、情報を提供する。なお、一つのセッションの間に、複数のサービスモジュールにアクセスしてもよい。その際は、生成部１３０において、対応する複数のサービスセッションＩＤを生成する。
【００３４】
このような構成とすることで、各サービスモジュールに対し、サービスセッションＩＤを設け、非特許文献１記載の従来技術と同等のセキュリティを有することができる。さらに、スクリプトを利用せずにサービスモジュール間のデータ通信を行うことができるため、利用者による改竄を防止できる。また、利用者装置及び情報提供装置の処理上の負荷を軽減できる。また、通信量を軽減することができる。
【００３５】
＜ハードウェア構成＞
図１１は、本実施例における情報提供装置１のハードウェア構成を例示したブロック図である。
図１１に例示するように、この例の情報提供装置１は、ＣＰＵ（Central Processing Unit）１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ（Read Only Memory）１５、ＲＡＭ（Random Access Memory）１６及びバス１７を有している。
【００３６】
この例のＣＰＵ１１は、制御部１１ａ、演算部１１ｂ及びレジスタ１１ｃを有し、レジスタ１１ｃに読み込まれた各種プログラムに従って様々な演算処理を実行する。また、入力部１２は、データが入力される入力インターフェース、キーボード、マウス等であり、出力部１３は、データが出力される出力インターフェース等である。補助記憶装置１４は、例えば、ハードディスク、ＭＯ（Magneto-Optical disc）、半導体メモリ等であり、情報提供装置１としてコンピュータを機能させるためのプログラムが格納されるプログラム領域１４ａ及び各種データが格納されるデータ領域１４ｂを有している。また、ＲＡＭ１６は、ＳＲＡＭ (Static Random Access Memory)、ＤＲＡＭ (Dynamic Random Access Memory)等であり、上記のプログラムが格納されるプログラム領域１６ａ及び各種データが格納されるデータ領域１６ｂを有している。また、バス１７は、ＣＰＵ１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ１５及びＲＡＭ１６を通信可能に接続する。
【００３７】
なお、このようなハードウェアの具体例としては、例えば、パーソナルコンピュータの他、サーバ装置やワークステーション等を例示できる。
【００３８】
＜プログラム構成＞
上述のように、プログラム領域１４ａ，１６ａには、本実施例の情報提供装置１の各処理を実行するための各プログラムが格納される。情報提供名プログラムを構成する各プログラムは、単一のプログラム列として記載されていてもよく、また、少なくとも一部のプログラムが別個のモジュールとしてライブラリに格納されていてもよい。また、各プログラムが単体でそれぞれの機能を実現してもよいし、各プログラムがさらに他のライブラリを読み出して各機能を実現するものでもよい。
【００３９】
＜ハードウェアとプログラムとの協働＞
ＣＰＵ１１（図１１）は、読み込まれたＯＳ（Operating System）プログラムに従い、補助記憶装置１４のプログラム領域１４ａに格納されている上述のプログラムをＲＡＭ１６のプログラム領域１６ａに書き込む。同様にＣＰＵ１１は、補助記憶装置１４のデータ領域１４ｂに格納されている各種データを、ＲＡＭ１６のデータ領域１６ｂに書き込む。そして、このプログラムやデータが書き込まれたＲＡＭ１６上のアドレスがＣＰＵ１１のレジスタ１１ｃに格納される。ＣＰＵ１１の制御部１１ａは、レジスタ１１ｃに格納されたこれらのアドレスを順次読み出し、読み出したアドレスが示すＲＡＭ１６上の領域からプログラムやデータを読み出し、そのプログラムが示す演算を演算部１１ｂに順次実行させ、その演算結果をレジスタ１１ｃに格納していく。
【００４０】
図１は、このようにＣＰＵ１１に上述のプログラムが読み込まれて実行されることにより構成される情報提供装置１の機能構成を例示したブロック図である。
【００４１】
ここで、記憶部８、ポリシー記憶部１２０及びセッション情報記憶部１４０は、補助記憶装置１４、ＲＡＭ１６、レジスタ１１ｃ、その他のバッファメモリやキャッシュメモリ等の何れか、あるいはこれらを併用した記憶領域に相当する。また、通信部７と、記憶部８と、制御部９と、認証部１１０と、生成部１３０と、検証部１５０と、実行部１６０は、ＣＰＵ１１に情報提供プログラムを実行させることにより構成されるものである。
また、本形態の情報提供装置１は、各制御部９の制御のもと各処理を実行する。
【００４２】
［変形例１］認証用サービスモジュール
実施例１と異なる部分についてのみ説明する。変形例１の情報提供装置１は、認証部１１０を有さない。情報提供ポータルシステム１０は、認証用サービスモジュール２００３を有する。さらに、認証処理を分散するために認証用サービスモジュール２００４等を有してもよい。
【００４３】
認証用サービスモジュール２００３等は、利用者を認証する。例えば、このような構成とした場合、検証部１５０は、リクエスト情報を入力され、利用者装置３からのリクエスト情報にサービスセッションＩＤが含まれるか否か検証する。含まれない場合、または、含まれるが、セッション情報記憶部１４０に存在しない場合には、認証用サービスモジュール２００３を呼び出す。認証用サービスモジュールの呼び出し方法は、実施例１と同様であってもよいし、他の方法であってもよい。他の方法としては、認証用サービスモジュールの識別情報は、別途記憶部８に記憶しておき、識別情報記憶部１０５を参照せずに、呼び出してもよい。次に、実行部１６０において、認証用サービスモジュールを実行する。認証処理は、認証部１３０と同様である。
【００４４】
このような構成とすることで複数の認証処理を行うことが可能となり、処理を分散することができる。また、モジュール毎に認証の強度を容易に変更することができる。例えば、一つの認証用サービスモジュールでは、利用者ＩＤ、パスワードのみで認証可能だが、他の認証用サービスモジュールでは、利用者ＩＤ、パスワードに加え、バイオメトリクス認証情報等を必要としてもよい。なお、認証用サービスモジュールは、主ドメイン内であっても、主ドメイン外であってもよい。
【００４５】
［変形例２］ユーザＩＤによるアクセス制限
実施例１と異なる部分についてのみ説明する。変形例２の情報提供装置１は、ポリシー記憶部１２０に記憶されるデータが実施例１とは異なる。図１２は、変形例２のポリシー情報記憶部１２０に記憶されるデータ例を示す。ポリシー記憶部１２０は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する。図１２を用いて説明する。例えば、図１２に沿って説明すると、利用者「user_A」の場合には、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、読込みをする権限は有さず、書込みをする権限を有している。一方、利用者「user_B」の場合には、サービスモジュール「module1.portal.com」は、サービスモジュール「module2.portal.com」に対して、書込みをする権限は有さず、読込みをする権限を有していることを意味する。
【００４６】
例えば、生成部１３０は、主セッションＩＤ及びサービスセッションＩＤを生成する際に、リクエスト情報から用いるサービスモジュール名と利用者を特定し、対応する主セッションＩＤ及びサービスセッションＩＤを生成する。さらに、ポリシー記憶部１２０を参照し、特定したサービスモジュール名と利用者の組合せに対応するポリシー情報を取得し、主セッションＩＤ及びサービスセッションＩＤ、及びポリシー情報をセッション情報記憶部１４０に出力する。
【００４７】
このような構成とすることで利用者毎に柔軟にポリシーを設定することができる。ポリシー情報の設定変更は、利用者側が行ってもよいし、情報提供装置の管理者が行ってもよい。利用者が行う構成とする場合には、例えば、保護者が未成年者の有害なサイトへのアクセスを制限することができる。また、管理者側が行う構成とする場合には、特定のサービスに申し込みをしている利用者のみに、そのサービスを受けることができるように設定することができる。また、サービスモジュール毎にポリシーを設定することで、ポータルが提供できるサービスの組合せのバリエーションを多数用意することができる。用意したサービスの組合せを選択する構成としてもよい。
【図面の簡単な説明】
【００４８】
【図１】利用者装置３と情報提供ポータルシステム１０の関係を示す図。
【図２】情報提供ポータルシステム１０の構成例を示す図。
【図３】情報提供装置１の処理フロー例を示す図。
【図４】識別情報記憶部１０５に記憶されるデータ例を示す図。
【図５】認証部１１０の処理フロー例を示す図。
【図６】ポリシー記憶部１２０に記憶されるデータ例を示す図。
【図７】生成部１３０の処理フロー例を示す図。
【図８】セッション情報記憶部１４０に記憶されるデータ例を示す図。
【図９】検証部１５０の処理フロー例を示す図。
【図１０】実行部１６０の処理フロー例を示す図。
【図１１】本実施例における情報提供装置１のハードウェア構成を例示したブロック図。
【図１２】変形例２のポリシー情報記憶部１２０に記憶されるデータ例を示す図。
【符号の説明】
【００４９】
１ 情報提供装置 １０ 情報提供ポータルシステム
７ 通信部 ８ 記憶部
９ 制御部 １０５ 識別情報記憶部
１１０ 認証部 １２０ ポリシー記憶部
１３０ 生成部 １４０ セッション情報記憶部
１５０ 検証部 １６０ 実行部
【特許請求の範囲】
【請求項１】
サービスモジュールに対する利用者装置のリクエストに返答する情報提供装置であって、
当該情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
各サービスモジュール名とサービスモジュールの識別情報を記憶する識別情報記憶部と、
各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶するポリシー記憶部と、
利用者装置と情報提供装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成部と、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶部と、
前記利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証部と、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する実行部と、を有する
ことを特徴とする情報提供装置。
【請求項２】
請求項１記載の情報提供装置であって、
利用者認証用サービスモジュールを有し、
前記実行部は、前記リクエスト情報にサービスセッションＩＤが含まれないか、または、サービスセッションＩＤが含まれるが有効ではない場合には、予め定められた識別情報から利用者認証用サービスモジュールを呼び出し、実行し、利用者を認証する
ことを特徴とする情報提供装置。
【請求項３】
請求項１または２記載の情報提供装置であって、
前記ポリシー記憶部は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する、
ことを特徴とする情報提供装置。
【請求項４】
サービスモジュールに対する利用者装置のリクエストに返答する情報提供ポータルシステムであって、
情報提供ポータルシステムが提供する情報の少なくとも一部を提供する１以上のサービスモジュールと、情報提供装置を有し、当該情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
前記情報提供装置は、
サービスモジュール名とサービスモジュールの識別情報を記憶する識別情報記憶部と、
各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶するポリシー記憶部と、
利用者装置と情報提供ポータルシステム間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成部と、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶部と、
前記利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証部と、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供ポータルシステムが提供する情報の少なくとも一部を提供する実行部を備える、
ことを特徴とする情報提供ポータルシステム。
【請求項５】
サービスモジュールに対する利用者方法のリクエストに返答する情報提供方法であって、
当該情報提供方法を実現する情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
識別情報記憶部はサービスモジュール名とサービスモジュールの識別情報を記憶し、
ポリシー記憶部は各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶し、
利用者方法と情報提供方法を実現する装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者方法と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成ステップと、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶ステップと、
前記利用者方法からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証ステップと、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供方法が提供する情報の少なくとも一部を提供する実行ステップと、を有する
ことを特徴とする情報提供方法。
【請求項６】
請求項５記載の情報提供方法であって、
当該情報提供方法を実現する情報提供ポータルシステムは利用者認証用サービスモジュールを有し、
前記リクエスト情報にサービスセッションＩＤが含まれないか、または、サービスセッションＩＤが含まれるが有効ではない場合には、予め定められた識別情報を用いて利用者認証用サービスモジュールを呼び出し、実行し、利用者を認証する認証ステップを有する
ことを特徴とする情報提供方法。
【請求項７】
請求項５または６記載の情報提供方法であって、
前記ポリシー記憶部は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する、
ことを特徴とする情報提供方法。
【請求項８】
請求項１から３記載の何れかの情報提供装置としてコンピュータを機能させるための情報提供プログラム。
【請求項１】
サービスモジュールに対する利用者装置のリクエストに返答する情報提供装置であって、
当該情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
各サービスモジュール名とサービスモジュールの識別情報を記憶する識別情報記憶部と、
各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶するポリシー記憶部と、
利用者装置と情報提供装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成部と、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶部と、
前記利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証部と、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供装置が提供する情報の少なくとも一部を提供する実行部と、を有する
ことを特徴とする情報提供装置。
【請求項２】
請求項１記載の情報提供装置であって、
利用者認証用サービスモジュールを有し、
前記実行部は、前記リクエスト情報にサービスセッションＩＤが含まれないか、または、サービスセッションＩＤが含まれるが有効ではない場合には、予め定められた識別情報から利用者認証用サービスモジュールを呼び出し、実行し、利用者を認証する
ことを特徴とする情報提供装置。
【請求項３】
請求項１または２記載の情報提供装置であって、
前記ポリシー記憶部は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する、
ことを特徴とする情報提供装置。
【請求項４】
サービスモジュールに対する利用者装置のリクエストに返答する情報提供ポータルシステムであって、
情報提供ポータルシステムが提供する情報の少なくとも一部を提供する１以上のサービスモジュールと、情報提供装置を有し、当該情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
前記情報提供装置は、
サービスモジュール名とサービスモジュールの識別情報を記憶する識別情報記憶部と、
各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶するポリシー記憶部と、
利用者装置と情報提供ポータルシステム間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者装置と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成部と、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶部と、
前記利用者装置からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証部と、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供ポータルシステムが提供する情報の少なくとも一部を提供する実行部を備える、
ことを特徴とする情報提供ポータルシステム。
【請求項５】
サービスモジュールに対する利用者方法のリクエストに返答する情報提供方法であって、
当該情報提供方法を実現する情報提供装置のドメインとサービスモジュールの少なくとも一部のドメインとが異なり、
識別情報記憶部はサービスモジュール名とサービスモジュールの識別情報を記憶し、
ポリシー記憶部は各サービスモジュール名とそのサービスモジュールの権限をポリシー情報として記憶し、
利用者方法と情報提供方法を実現する装置間において接続を確立する際に、その接続を一意に識別する主セッションＩＤ、及び、利用者方法と各サービスモジュールとの接続を一意に識別するサービスセッションＩＤを生成する生成ステップと、
前記主セッションＩＤから得ることができる値、前記サービスセッションＩＤから得ることができる値及び対応するポリシー情報をセッション情報として記憶するセッション情報記憶ステップと、
前記利用者方法からのリクエスト情報に含まれるサービスセッションＩＤの有効性をセッション情報記憶部の情報を用いて検証する検証ステップと、
前記リクエスト情報に含まれるサービスモジュール名を用いて、前記識別情報記憶部を参照して対応するサービスモジュールの識別情報を取得し、前記サービスセッションＩＤに対応付けられるセッション情報と前記識別情報を用いて、サービスモジュールを呼び出し、実行し、ポリシーに従って情報提供方法が提供する情報の少なくとも一部を提供する実行ステップと、を有する
ことを特徴とする情報提供方法。
【請求項６】
請求項５記載の情報提供方法であって、
当該情報提供方法を実現する情報提供ポータルシステムは利用者認証用サービスモジュールを有し、
前記リクエスト情報にサービスセッションＩＤが含まれないか、または、サービスセッションＩＤが含まれるが有効ではない場合には、予め定められた識別情報を用いて利用者認証用サービスモジュールを呼び出し、実行し、利用者を認証する認証ステップを有する
ことを特徴とする情報提供方法。
【請求項７】
請求項５または６記載の情報提供方法であって、
前記ポリシー記憶部は、利用者名とサービスモジュール名の組合せとその組合せに対する権限を表すポリシー情報を記憶する、
ことを特徴とする情報提供方法。
【請求項８】
請求項１から３記載の何れかの情報提供装置としてコンピュータを機能させるための情報提供プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−１５２６９０（Ｐ２０１０−１５２６９０Ａ）
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願番号】特願２００８−３３０７４２（Ｐ２００８−３３０７４２）
【出願日】平成２０年１２月２５日（２００８．１２．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願日】平成２０年１２月２５日（２００８．１２．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]