JP2008287524A - 認証方法、認証装置及びプログラム - Google Patents

Abstract

【課題】サーバ上の情報やプログラムに対するアクセスを制御することができる。
【解決手段】クライアント端末の固有のＩＤと、その利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定手段を有する認証装置であって、前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とする。
【選択図】図２

Description

本発明はアクセス制御をより確実に行うことができる認証装置等に関する。

汎用のクライアントプログラムであるＷＷＷクライアントを用いた情報提供サービスや、情報システムは、企業内のシステムや、インターネットを用いた一般市場に対するサービス等、広くあらゆる企業、産業分野で利用されている。また、一方で、このようなシステムや、サービスには、部分的に、より強固なセキュリティを要求される場合が多い。従来のアプリケーションプログラムやハードウェア等を特定しない汎用認証システムにおいて、最も一般的なものは、利用者のＩＤとパスワード等を用いて、利用者を特定するものである。さらに、通信の暗号化や、指紋などの身体認証、を用いるものも多数存在し、実用に供されている。

一方、クライアント端末を特定する認証方式としては、クライアント端末に専用のプログラムや、専用のハードウェアを用いる方式が一般的である。また、上述した方式以外で、クライアント端末を特定する方式としては、専用のネットワークを構築したり、又はネットワークを必要な範囲のみ論理的或いは物理的に分離したりして、その範囲からしかアクセスできないようにする方式もある。

また、サーバへのアクセスのときに、動的に取得されるクライアント端末固有の情報と、利用者の情報と、を判断材料として認証を行う技術が知られている（例えば、特許文献１参照）。
さらには、クライアント端末固有のＩＤと、利用者の情報と、をサーバで管理して認証の判断材料とする技術が知られている（例えば、特許文献２参照）。

特開２００２−４１３４７号公報 特開２００１−６７３１９号公報

しかしながら、ＩＤ等により利用者を特定する認証システムは、利用者自身を特定することは可能であるが、利用者と同時に、利用者が利用しようとしているクライアント端末を特定することはできない。
また、専用プログラムや端末を用いる方式では、一般に利用されている通常のコンピュータからサービスを利用する場合に、専用のハードウェアを導入しなければならない。従って、コストや専用のプログラムを配布／管理するコストがかかるため、汎用認証方式としては、改善する余地がある。
また、専用のネットワークを形成する場合には、当該ネットワークを経由するあらゆるアクセスをネットワーク通信のレベルで無差別に制限することになり、同等のセキュリティが不要な情報提供サービスや、情報システムを利用することもできなくなってしまう。

サーバへのアクセスのときに、動的に取得されるクライアント端末固有の情報と、利用者情報と、を利用する場合は、一旦サーバへのアクセスを始めた後に、アクセス中のクライアント端末の以外からのアクセスを拒絶することは可能となる。しかし、この方式ではサーバ側にアクセス可能なクライアント端末と利用者の情報を持っていないため、予め、特定のクライアント端末からのアクセスを制御することはできない。

また、クライアント端末側で端末固有情報を含む暗号鍵を生成してサーバに送付する方法による場合、クライアント端末側に特殊なプログラムを必要とする点で、汎用認証システムとしては改善する余地がある。

クライアント端末固有のＩＤと、利用者の情報と、をサーバで管理して、これを認証の判断材料とする場合は、単独の検索システムの利便性とセキュリティ上の堅牢性を両立させることが可能である。しかし、「クライアント固有のＩＤと利用者の情報の組み合わせ」と、アクセス可能な情報と、の対応を管理する必要があり、また、利用者が利用可能なクライアント端末を登録する必要があるため、汎用の認証システムとしては改善する余地がある。

本発明は、クライアント端末の固有のＩＤと、その利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定ステップを有する認証方法であって、前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とする。

本発明によれば、複数のクライアント端末がアクセス可能なサーバを有し、クライアント端末と、利用者の双方を特定した上で、サーバ上の情報やプログラムに対するアクセスを制御することができる。

このようなアクセス制御は、例えば、企業内の情報システム、あるいは、広くインターネット上でサービスを提供する情報システムにおいて、特に、セキュリティ上、アクセスするクライアント端末を特定する必要がある場合に有効である。

例えば、企業内において、特定の機密情報に対してのみ、同一の利用者であっても、強固な物理セキュリティ対策を施した端末室に設置したクライアント端末からしかアクセスできないようにすることができる。また、例えば、一般市場に対するサービスにおいても、同一の利用者であっても、利用者の自宅に設置したクライアント端末のみからアクセス可能にし、紛失や、他者によるなりすましの危険が大きい携帯端末からはアクセス不可能にすることができる。

以下、図面を参照して本実施形態について説明する。
ここでは、企業内で典型的に利用されている汎用認証システムを一例として取りあげて、本発明がどのように適用されるかを説明する。本発明は、必ずしも企業内の認証システムに利用範囲を限るものではなく、同様の管理を要求されるインターネット上のオープンなサービスやシステムにも十分に適用可能なものである。例えば、インターネット上のオープンなサービスやシステムへ適用する際の実施方法についても本発明の認証方式は適用可能である。

（全体構成）
図１は、本実施形態に係るシステムの構成を示す図である。
図１において、認証サーバ１と、クライアント端末６と、アプリケーションサーバ８と、ＷＷＷサーバ１０とは、それぞれコンピュータである。これらは、キーボード、マウス等の入力装置（不図示）と、ディスプレイ等の表示装置（不図示）と、を必要に応じて備えている。

個人情報データベース３と、認証情報データベース４と、アプリケーションデータベース９と、ＷＷＷリソースデータ１１とは、各々データの保存域である。これらについて、さまざまなデータベース管理プログラムを、別のコンピュータ上で動作させる場合もあれば、認証サーバ１、クライアント端末６、アプリケーションサーバ８又はＷＷＷサーバ１０上で、動作させる場合もある。さらに、認証サーバ１、アプリケーションサーバ８及びＷＷＷサーバ１０は、すべて物理的にひとつのコンピュータで実現することが可能であるし、同種の役割を担う多数のコンピュータで実現することも可能である。こうしたシステム構成の問題は、もっぱら個々の実現形態において、性能その他の要件によって設計されるべきものであり、本発明の効果とは無関係である。

図１は、以上のような要件を含みながら、本実施形態の説明に適した構成を示したものである。図１において、１は、認証サーバである。以後の説明において、本発明の認証システム２がプログラムとして動作する。認証サーバ１は、利用者と、クライアント端末固有のＩＤと、の組み合わせで、認証を行い、その他のアプリケーションに認証情報を提供する役割を担う。６は、クライアント端末であり、ＷＷＷブラウザ７が動作する。利用者は、クライアント端末６を用い、クライアント端末６上で動作するプログラムであるＷＷＷブラウザ７を操作して、各種のアプリケーションサービスや、情報提供サービスを受ける。図１では、便宜上、クライアント端末６は、１つのみで構成されているが、実際には、多数のクライアント端末６が存在するものとして以下の説明を行う。

５は、ネットワークであり、ＬＡＮ、ＷＡＮ等の形態を問わず、インターネットプロトコルに代表される標準的なプロトコルを用いたものである。
３は、個人情報データベースである。個人情報データベース３は、企業内のシステムであれば、人事情報データベース、一般に公開されたシステムであれば顧客情報データベース等、システムの利用者の属性情報を保存しているデータベースである。個人情報データベース３は、本発明の利用例を示すためのものであり、個人情報データベース３が、存在しなくてもよい。

４は、認証情報データベースである。認証情報データベース４は、利用者の認証情報、すなわち、利用者ＩＤ、パスワード、クライアント端末固有のＩＤ及び利用可能なアプリケーションの組み合わせを管理する。認証情報データベース４の内容については、本発明の中心をなすものであり、後に詳細に説明する。

８は、アプリケーションサーバである。アプリケーションサーバ８は、認証サーバ１によって付与された認証情報に従って、利用者及びクライアント端末を特定した上で、利用者に情報を提供するアプリケーションプログラムが動作する。

９は、上記アプリケーションプログラムが利用するアプリケーションデータベースである。アプリケーションプログラムの種類によっては、アプリケーションデータベース９が、不要な場合がある。また、１つのアプリケーションプログラムに対して複数のアプリケーションデータベース９が存在してもよい。

また、図１では、アプリケーションサーバ８及びアプリケーションデータベース９を１つのみとして説明しているが、これは、説明の便宜のためであって、実際には、アプリケーションサーバ８、アプリケーションデータベース９は多数に存在してもかまわない。本発明においては、原理的には、アプリケーションサーバ８、アプリケーションデータベース９の数に制限はない。

１０は、ＷＷＷサーバである。１１は、ＷＷＷリソースデータである。ＷＷＷサーバ１０は、ＷＷＷブラウザ７からの要求に応じて、ＷＷＷリソースデータ１１から指定のデータを呼び出し、ＷＷＷブラウザ７に送信する役割を行う。具体的には、認証サーバ１によって付与された認証情報に従って、ＷＷＷリソースデータ１１のうち、アクセス可能なもののみをＷＷＷブラウザ７に送信する。また、ＷＷＷサーバ１０及びＷＷＷリソースデータ１１は、同一のコンピュータで実現可能であり、かつ、複数存在してもかまわないことは、アプリケーションサーバ８及びアプリケーションデータベース９と同様である。

（第１の実施形態）
上述した全体構成をもとに、本発明がどのように実現されるかを詳細に説明する。
図２は、第１の実施形態に係る処理を示すフローチャートである。図２のフローチャートは、大きく３段階に分かれている。
１段階目のステップＳ−Ａ（Ｓ１、Ｓ２、Ｓ３）は、本認証システムに利用者情報と、クライアント端末固有のＩＤとを登録するステップである。このステップＳ−Ａでは、新たな利用者やクライアント端末を登録する必要が発生するたびに実施するものである。

２段階目のステップＳ４は、本認証システムを用いて認証制御を行うアプリケーションや、情報を登録する処理であり、新たに本認証システムを利用するアプリケーションや、ＷＷＷサーバが発生するたびに実施するものである。
以上、１段階目であるステップＳ−Ａ及び２段階目であるステップＳ３は、認証に必要な情報を登録する事前準備のステップである。

３段階目のステップＳ−Ｂ（Ｓ５、Ｓ６、Ｓ７、Ｓ８）は、ステップＳ−Ａ及びステップＳ３で、登録した情報をもとに、実際に認証を行うステップである。このステップＳ−Ｂでは、本認証システムを用いるアプリケーションやＷＷＷサーバへ、利用者がアクセスする際に、実行するものである。

以下、ステップＳ１から順次説明を行う。
まず、ステップＳ１は、利用者を認証するステップである。利用者を認証する方式としては、ユーザＩＤとパスワードを利用者に入力させ、これをチェックする方式が一般的であり、すでに多くのシステムで実現されている。また、ＩＣカード等の物理的な鍵を利用する方法や、生体認証を利用する方式、各種の暗号化と組み合わせる等、さまざまな方式も実現されている。本発明は、利用者とクライアント端末の組み合わせで認証を行う方式である。従って、利用者の認証方式が、どのようなものであろうと、結果としてＷＷＷブラウザ７を経由して、認証システム２にアクセスする利用者が、認証情報データベース４に予め登録されている利用者と同一であることが確認できればよい。本実施形態では、ユーザＩＤとパスワードを用いて利用者を認証するものとして、説明する。

ステップＳ１では、認証情報データベース４に、図３のようなデータが格納されているものとして説明する。図３で示される、ユーザＩＤとパスワードは必須であり、その他の属性情報は、認証システムの用途によって任意に構築することができる。また、パスワードは、通常暗号化を施してデータベースに登録し、読み出し時に復号することが通常であるが、この機構については、本発明では特に言及しない。

なお、一般に企業等では、利用者情報は、人事情報システムにあらかじめ登録されていることが多い。また、一般の顧客を利用者とするシステムでは、顧客情報がデータベース化されている場合がある。個人情報データベース３は、このような利用者に対する各種の属性情報を管理するデータベースである。

ステップＳ１で利用者を認証する前に、利用を許可された利用者情報を予め、認証情報データベース４に登録しておく必要がある。この際には、個人情報データベース３より、利用者情報を抽出することで、図３における「その他の属性情報」について登録作業の効率を上げることができる。しかしながら、このような効率化は、すでに常識的に実施されているため、本発明では特に言及しない。

ステップＳ１では、利用者がクライアント端末６で、ＷＷＷブラウザ７を通じてユーザＩＤとパスワードとを入力し、これをネットワーク５を介して、認証サーバ１に送信する。認証システム２は、認証サーバ１に送信された、ユーザＩＤとパスワードとを検出し、認証情報データベース４に登録されている図３に例示したデータから、一致するユーザＩＤ及びパスワードがあるかどうかを検索する。認証情報データベース４に、一致するユーザＩＤ及びパスワードが存在すれば、利用者の認証は成功し、次のステップに進む。認証情報データベース４に、一致するユーザＩＤ及びパスワードが存在しない場合は、その旨を示すメッセージを、ネットワーク５を介してクライアント端末６へ送信して処理を中断する。

ステップＳ２では、アクセスしているクライアント端末６の、クライアント端末固有のＩＤを取得する。クライアント端末固有のＩＤとは、一般的には、ＩＰアドレスと呼ばれるネットワーク内で固有のアドレス、又はＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ａｄｄｒｅｓｓ）と呼ばれるハードウェア固有アドレスを用いる場合がある。これらはいずれも、現状では、ネットワーク制御上において必須の汎用ＩＤであり、これらのアドレスを持っていない汎用ネットワークアクセスは存在しない。

本発明では、このような汎用ＩＤ（汎用ネットワークアドレス）を用いることを特徴とするものである。これにより、クライアント端末６に特殊なソフトウェアやハードウェアを搭載したり、ネットワークを物理的に分離したりする等の対策が不要となり、汎用認証システムとしてより有効に利用可能となる。また、このような条件を満たし、かつ、認証サーバ１から取得可能なクライアント端末固有ＩＤとしては、現状では、ＩＰアドレス、ＭＡＣアドレスが存在し、将来これら以外のクライアント端末固有のＩＤが一般化した場合は、そのＩＤを利用するようにしてもよい。以下、ＩＰアドレス又はＭＡＣアドレスをクライアント端末固有のＩＤとして利用するものとして説明をする。

ＩＰアドレスは、通常、一般的なＷＷＷサーバの機能によって取得することが可能である。ただし、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を利用している場合等には、クライアント端末６に動的にＩＰアドレスが割り当てられるため、ＩＰアドレスはクライアント端末固有のＩＤとしては利用できない。この場合には、ＭＡＣアドレスをクライアント端末固有のＩＤとして利用することができる。

ＭＡＣアドレスを取得する方法としては、一般に、ＤＨＣＰサーバと呼ばれるネットワーク機器によって提供されているＩＰアドレスからＭＡＣアドレスを検索する機能を用いることができる。また、インターネット環境のように、多数の通信業者のサーバ等が介在してクライアント端末のＭＡＣアドレスをネットワーク経由で取得できない場合がある。この場合には、Ｊａｖａ(登録商標)Ａｐｐｌｅｔに代表されるＷＷＷブラウザ上で動作するプログラムを一時的にダウンロードしてＭＡＣアドレスを所得することも可能である。以上のような方法により、認証システム２が、クライアント端末６のＭＡＣアドレスを取得することも実現が可能である。

以上のような条件により、認証システムを利用する範囲や、ネットワーク環境に応じて、クライアント端末固有のＩＤとして、ＩＰアドレスを選択するかＭＡＣアドレスを選択するかを決めればよい。ステップＳ２では、以上、説明したような方式により、クライアント端末固有のＩＤを取得する。

次に、ステップＳ３において、ステップＳ１で認証した利用者情報と、ステップＳ２で取得したクライアント端末固有のＩＤと、を対応付けて組み合わせ、認証情報データベース４に登録する。このとき、認証情報データベース４での登録情報は、図４のようになっている。図４は、ステップＳ２で認証したユーザＩＤと、クライアント端末固有のＩＤと、この組み合わせでアクセス可能な情報のアドレスと、を表形式で保存する形式となっている。なお、この時点では、アクセス可能情報は空欄となっている。このアクセス可能情報は、次の、ステップＳ４で登録する。なお、本実施形態では、認証情報データベース４において、ステップＳ１にて利用する情報（図３）と、ステップＳ２にて利用する情報（図４）とは、データベースの構成上、別のテーブルとして管理することを想定して説明する。

なお、これらのテーブルは、図５のようにひとつのテーブルとして管理することも可能である。このような情報の管理方法は、利用者に対して、クライアント端末固有のＩＤが概ね１つしかない場合に有効である。

また、図６のように、図４に示した情報を２つのテーブルに分けて管理することも可能である。図６に示されるアクセスランクとは、アクセス可能な情報を分類し、個々の分類ごとに付与したランクである。このような情報の管理方法は、利用者とクライアント端末固有のＩＤの組み合わせに対して、多数のアクセス可能情報が存在する場合に有効である。

図４、図５及び図６に示すような情報の管理方法は、一般にデータベースの正規化と呼ばれるデータベースを設計する上で一般的な手法であって、データの量や条件、要求される性能などによって使い分けられる。どのようなテーブル構成をとったとしても、結果として、利用者と、クライアント端末固有のＩＤと、アクセス可能情報と、組み合わせが管理できればよい。少なくとも利用者情報（ユーザＩＤ）とクライアント端末固有のＩＤの組み合わせが同一のテーブルで管理され、利用者情報（ユーザＩＤ）とクライアント端末固有ＩＤとの組み合わせ及びアクセス可能情報の対応がとられていればよい。

以上のようにして、第１段目のステップＳ−Ａ（ステップＳ１、Ｓ２、Ｓ３）の処理が終了する。この時点で、利用者情報と、クライアント端末固有のＩＤと、の組み合わせがあらかじめ登録されていることになる。なお、ステップＳ−Ａでは、一般に実用に供されている利用者の認証手段を用いて、クライアント端末固有のＩＤを登録する事例を示している。これは、「利用者を認証する認証手段と、前記認証手段を用いて、前記利用者が利用可能なクライアント端末の固有のＩＤを登録する登録手段」を例示したものである。

しかしながら、これらの情報は、あらかじめ別の手段にて登録しておくこともできる。また、ここまでのステップＳ−Ａの説明では、クライアント端末固有ＩＤを、利用者の認証時に自動的に登録する例を示しているが、しかるべき管理者の承認を経て登録する機能等、実際の利用形態によってはさまざまな機能を付加することも可能である。

次に、ステップＳ４に進み、ステップＳ−Ａで登録した、図４のようなユーザＩＤと、クライアント端末固有のＩＤと、の組み合わせに対して、利用可能な情報を登録する。ステップＳ４では、利用者ではなく、アプリケーションや情報の管理者が、別の機能を用いて登録することを想定している。データベースパッケージに通常付属しているデータ管理機能を用いることもできるし、専用の機能を構築することもできるが、これらの機能については、特に本発明では言及しない。

図７は、アクセス可能情報を登録した場合の概念図である。
本実施形態では、アクセス可能情報の登録形式としては、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と呼ばれるネットワーク上でユニークな文字列を用いている。一般にＵＲＬは、ＷＷＷサーバと、ＷＷＷクライアント端末と、からなる情報システムにおいては、アプリケーションプログラムの起動や、ＷＷＷサーバ上にある特定のファイルを取得するための指示子としても機能する。そのため、認証システム２は、その管理下にあるあらゆるアプリケーションプログラムや、特定の情報に対して、利用者と、クライアント端末固有のＩＤと、の組み合わせにより、アクセスを許可したり拒否したりすることができる。

なお、本発明を用いれば、さらに、アプリケーションプログラムの内部で制御しているデータベース上の特定のデータについて、アクセスを許可したり拒否したりすることも可能であるが、これについては、第２の実施形態で説明する。以上のようにして、第２段目のステップＳ４の処理が終了する。

次に、図２のステップＳ−Ｂ（ステップＳ５、Ｓ６、Ｓ７、Ｓ８）において、実際に利用者からのアクセスがあった際に、どのようにこれを判定し、アクセス可否の制御をするかについて説明する。
ステップＳ５において、利用者の認証を行う。この時点で、利用者が認証情報データベース４に登録されていない場合には、その旨のメッセージを、ＷＷＷブラウザ７に表示し、利用者からの要求を拒絶する。その詳細は、ステップＳ１と同様であるため、説明を省略する。

次に、ステップＳ６において、クライアント端末固有のＩＤを取得する。その詳細は、ステップＳ２と同様であるため説明を省略する。
ステップＳ７では、利用者が要求している情報が、当該利用者が、当該クライアント端末からのアクセスを許可されている情報かどうかを判定する。この時点では、図７に示したような、ユーザＩＤと、クライアント端末固有のＩＤと、アクセス可能情報と、の組み合わせが、認証情報データベース４に登録されている。

ステップＳ５で認証したユーザＩＤ及びステップＳ６で取得した端末固有のＩＤの組み合わせで、認証情報データベース４に登録されている、図７に例示したテーブルを検索し、一致するものがあるかどうかを調べる。一致している情報があれば、当該利用者は、当該クライアント端末からのアクセスを許可された情報にアクセスしようとしていると判断し、次に進む。一致している情報がない場合には、当該利用者は、当該クライアント端末からのアクセスを許可されていない情報にアクセスしようとしていると判断し、その旨を、ＷＷＷブラウザ７に表示し、処理を中断する。

ステップＳ８では、ステップＳ７で、アクセスを許可した情報を、ＷＷＷブラウザ７に送信する。これは、当該利用者が、当該クライアント端末から、再び、同じ情報にアクセスしようとした際、ステップＳ５、Ｓ６、Ｓ７で示した認証処理を、再度実施することを避け、効率を保つためである。この処理は、通常、通信規約であるＨＴＴＰプロトコル（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に定められたＣｏｏｋｉｅと呼ばれる領域に、認証システム２が、認証結果を書き込むことによって実現できる。

ＷＷＷブラウザ７は、認証結果が書き込まれたＣｏｏｋｉｅの領域をそのまま、目的とするアプリケーションサーバ８や、ＷＷＷサーバ１０に送信する。アプリケーションサーバ８上で動作するアプリケーションは、これを読み取って、認証されたアクセスであることを知ることができる。しかし、特定のアプリケーションに一回のみアクセスする場合等は、必ずしも、認証結果を、ＷＷＷブラウザ７に送信する必要はなく、指定されたアプリケーションと、認証システム２の間で直接通信をしてよい。

第１の実施形態によれば、利用者と当該利用者が利用中のクライアント端末の組み合わせで、ＵＲＬで指示されるアプリケーションプログラムや、ＷＷＷサーバ上の特定のファイルへのアクセスが制御可能となる。こうしたアクセス制御は、企業内の情報システム、あるいは、広くインターネット上でサービスを提供する情報システムにおいて、特に、セキュリティ上、アクセスするクライアント端末を特定する必要がある場合に有効である。

第１の実施形態では、ＵＲＬで指示されるアプリケーションプログラムや、ＷＷＷサーバ上の特定のファイルへのアクセスを制御可能とする場合について説明した。しかし、アプリケーションプログラムによっては、アプリケーションが管理するデータベースの特定のデータや、アプリケーション内部の特定の機能について利用者と当該利用者が利用中のクライアント端末の組み合わせでアクセス制御を行う場合も想定される。従って、このような必要性を、どのように本発明を利用してどのように実現するかを、第１の実施形態と異なる部分を中心に説明する。

（第２の実施形態）
図８は、第２の実施形態に係る、図１のアプリケーションサーバ８と、アプリケーションデータベース９の内部を論理的に分割した概念図である。アプリケーションプログラム８１は、アプリケーションサーバ８上で動作するアプリケーションプログラムであり、この機能の中で本実施形態で示すアクセス制御を行う。また、アプリケーションデータベース９１は、アプリケーションが提供する情報そのものを格納したデータベースである。アクセス制御データベース９２は、特に、本実施形態でアクセス制御を行うためのデータベースである。

以下、第２の実施形態について、図２のフローチャートを参照しながら、第１の実施形態との違いを中心に説明する。ステップＳ−Ａ（Ｓ１、Ｓ２、Ｓ３）については、第１の実施形態と同様である。
次に、ステップＳ４において、第１の実施形態では、認証情報データベース４に、図７に示すように、ユーザＩＤと、クライアント端末固有のＩＤと、アクセス可能な情報と、を登録している。この際、アクセス可能情報の登録形式は、アプリケーションの起動が可能な識別子であるＵＲＬであった。
第２の実施形態では、これに加えて、起動されたアプリケーションの中で、より詳細な機能やデータの範囲を管理する必要がある。そこで、各アプリケーションプログラム８１に対応するアクセス制御データベース９２に、その情報を登録しておく。

図９は、この時点でのアクセス制御データを例示した概念図である。図９に示すアクセス可能機能とは、アプリケーションプログラム８１内部の詳細な機能を指す識別子であり、プログラム名、機能名、メニュー名等を指している。アプリケーションプログラム８１が、識別可能であれば、アプリケーション内部にのみ通用するＩＤでも構わない。

また、図９に示すアクセス可能データ範囲とは、アプリケーションデータベース９１に格納されているデータの特定のキー項目の範囲を示している。例えば、データの機密度に応じて割り振られたＩＤなどの範囲を登録する。これも、アプリケーションプログラム８１が、識別可能であれば、アプリケーション内部にのみ通用するＩＤでも構わない。次に、ステップＳ５、Ｓ６、Ｓ７は、認証システムの動作であり、第１の実施形態と同様である。

次に、ステップＳ８において第１の実施形態では、認証システム２は、ＷＷＷブラウザ７に認証結果情報を送信している。第２の実施形態では、これに加え、少なくとも、ユーザＩＤ及びクライアント端末固有のＩＤも送信する。
次に、図２に示した一連の認証処理を終わり、アプリケーションサーバ８に、ＷＷＷブラウザ７がアクセスした後について説明する。ＷＷＷブラウザ７は、図２のステップＳ８で送信されたユーザＩＤと、クライアント端末固有のＩＤとを、アプリケーションサーバ８に送信する。アプリケーションプログラム８１は、この情報をキーとして、ステップＳ４で登録済みのアクセス制御データベース９２を読み取り、当該利用者と当該クライアント端末からアクセス可能な機能やデータの範囲を読み取る。そして、読み取ったアクセス可能な機能やデータの範囲を基に動作し、必要に応じてアクセス可能な機能やデータ範囲を制限する。

例えば、ある利用者とクライアント端末との組み合わせでアクセス可能な機能として“Ａ”という機能のみが登録されていた場合には、表示メニュー上、“Ａ”のみを表示する。また、ある利用者とクライアント端末との組み合わせでアクセス可能なデータ範囲として、アプリケーションデータベースの特定テーブルのキー情報が、１以上３０以下の範囲に設定されている場合、検索結果から上記の範囲のみを表示する等である。

第２の実施形態によれば、アプリケーションごとの詳細なアクセス制御にも適用可能であることがわかる。なお、第２の実施形態では、アクセス制御データベース９２に、図９のように、ユーザＩＤとクライアント端末固有ＩＤとを持ち、これをキーとして、アクセス可能な機能や、データ範囲を検索するようにしている。また、アプリケーションプログラム８１は、認証システム２から、ＷＷＷブラウザ７を通じて、ユーザＩＤとクライアント端末固有のＩＤとを受け取るようにしている。

しかしながら、このようなアプリケーションプログラム８１と、認証システム２の機能分担は、他に様々な機能分担もしてもよい。例えば、図６に示したようなアクセスランクを、アプリケーション共通に定義しておき、アプリケーションプログラム８１は、認証システム２から、ＷＷＷブラウザ７を通じて、アクセスランクを受け取るようにしても構わない。

上述した本発明の実施形態における認証装置を構成する各手段、並びに認証法の各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

本実施形態に係るシステム全体の構成を示す図である。 本実施形態に係る処理の流れを示すフローチャートである。 利用者認証情報管理テーブルの一例を示す図である。 利用者とクライアント端末とを組み合わせた管理テーブルを示す図である。 利用者認証情報管理テーブルの一例を示す図である。 利用者認証情報管理テーブルの一例を示す図である。 利用者とクライアント端末とアクセス可能情報の組み合わせを登録した一例を示す図である。 第２の実施形態に係るシステムの一部詳細を示した図である。 第２の実施形態に係る利用者とクライアント端末とを組み合わせたアクセス制御データを示す図である。

符号の説明

１ 認証サーバ
２ 認証システム
３ 個人情報データベース
４ 認証情報データベース
５ ネットワーク
６ クライアント端末
７ ＷＷＷブラウザ
８ アプリケーションサーバ
９ アプリケーションデータベース
１０ ＷＷＷサーバ
１１ ＷＷＷリソースデータ
８１ アプリケーションプログラム
９１ アプリケーションデータベース
９２ アプリケーションが利用する認証データベース

Claims (5)

1. クライアント端末の固有のＩＤと、その利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定ステップを有する認証方法であって、
   前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とする認証方法。
2. 利用者を認証する認証手段と、前記認証手段を用いて、前記利用者が利用可能なクライアント端末の固有のＩＤを登録する登録手段と、を有する認証装置の認証方法であって、
   前記クライアント端末の固有のＩＤと、前記利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定ステップを有し、
   前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とする認証方法。
3. 前記クライアント端末の固有のＩＤは、ＩＰアドレス又はＭＡＣアドレスであることを特徴とする請求項１又は２に記載の認証方法。
4. クライアント端末の固有のＩＤと、その利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定手段を有する認証装置であって、
   前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とする認証装置。
5. クライアント端末の固有のＩＤと、その利用者の認証情報と、を対応付けて管理された情報及び前記クライアント端末と、前記利用者と、の組み合わせに対するアクセス可能なリソースを管理する情報に基づいて、サーバ上のリソースへのアクセス可否の判定を行う判定ステップをコンピュータに実行させるためのプログラムであって、
   前記クライアント端末の固有のＩＤが、ネットワーク制御上の汎用ＩＤであることを特徴とするプログラム。

Images