JP5991817B2 - ネットワークシステム - Google Patents

Description

本発明は、プログラム、ネットワークシステムに関する。

従来から、ユーザＩＤとパスワードとに基づき、ユーザを認証する認証サーバが存在する。また、近年は、クラウドコンピューティングと呼ばれるシステムによって、インターネットを介してユーザが何処からでもアクセスできるようになり、ユーザの利便性を図れるようになってきている。

また、従来技術として、端末がサーバから回線識別情報を取得し、回線識別情報が端末側で予め記憶されている場合に決済処理を行うものが存在する（特許文献１の図１、０００９段落参照）。

特開２００６−２６１９９１号公報

従来では、端末がユーザＩＤとパスワードとをイントラネットを介して認証サーバに送信することが多く、閉域化されたネットワーク上ではセキュリティ面で安全が確保される状況下にあった。

一方、クラウドコンピューティングでは、広域化されたネットワークであるので、端末から入力されたユーザＩＤとパスワードとがインターネットを介して認証サーバに送信することになり、イントラネットでの認証システムに比べて、盗聴やなりすまし等のセキュリティ上の問題が生じる可能性が高い。

本発明は、上述した課題に鑑みたものであり、クラウドコンピューティングにおけるユーザの利便性を高め、セキュリティを高めた認証を行うことが可能なプログラム、ネットワークシステムを提供することにある。

（１）本発明は、端末とインターネットを介して接続された認証サーバのためのプログラムであって、前記端末から受信したユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する第１の判断部と、前記端末の送信元のアドレス情報が、予め前記認証データベースに登録されているアドレス情報と一致することを第２の条件とする当該第２の条件を満たすか否かを判断する第２の判断部と、前記端末から受信した証明情報が、予め前記認証データベースに登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する第３の判断部と、前記ユーザＩＤのグループを判定するグループ判定部と、前記ユーザＩＤの認証の許可又は不許可を判定する認証判定部として、コンピュータを機能させ、前記認証判定部が、前記第１の条件及び前記第２の条件を満たす場合に、第１のグループに属するユーザＩＤの認証を許可し、前記第１の条件及び前記第２の条件を満たす場合、又は、前記第１の条件及び前記第３の条件を満たす場合に、第２のグループに属するユーザＩＤの認証を許可するプログラムに関する。

また、本発明は、コンピュータにより読み取り可能であって、上記プログラムを記憶した情報記憶媒体に関する。また、本発明は、上記各部を含む認証サーバに関する。また、「アドレス情報」とは、例えば、組織のネットワークのゲートウェイのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｃｏｌ）アドレスである。

本発明によれば、第１のグループに属するユーザＩＤと、第２のグループに属するユーザＩＤで異なった方法・フローで認証の許可を判定するので、利便性とセキュリティを高めつつ、グループに応じた適切な認証を行うことができる。

例えば、本発明によれば、第１のグループに属するユーザＩＤ（例えば、開発部のグループのユーザＩＤ）については、ユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致する場合、及び、端末の送信元のアドレス情報が、予め認証データベースに登録されているアドレス情報（例えば、会社のネットワークのゲートウェイのＩＰアドレス）と一致する場合に認証を許可する。また、第２のグループに属するユーザＩＤ（例えば、営業部のグループのユーザＩＤ）については、（Ａ）ユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致する場合、及び、端末の送信元のアドレス情報が、予め認証データベースに登録されているアドレス情報と一致する場合、又は、（Ｂ）ユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致する場合、及び、端末から受信した証明情報が、予め認証データベースに登録されている証明情報と一致する場合に認証を許可する。

つまり、本発明によれば、予め認証データベースに会社のネットワークのゲートウェイのＩＰアドレスを登録した場合には、第１のグループに属するユーザＩＤ（例えば、開発部のグループのユーザＩＤ）については、社内のネットワークからのアクセスに制限し、社外のネットワークからのアクセスを禁止することができる。また、第２のグループに属するユーザＩＤ（例えば、営業部のグループのユーザＩＤ）については、社外のネットワークからのアクセスであったとしても、端末から受信した証明情報が予め認証データベースに登録されている証明情報と一致する場合に、認証が許可されることになる。このように、本発明によれば、第１のグループに属する端末ついては、端末の送信元を例えば会社のネットワークのゲートウェイのＩＰアドレスに制限する（社内のネットワークからのアクセスに制限する）ことによって、セキュリティを高めることができる。また、第２のグループに属する端末については、端末の送信元が例えば会社のネットワークのゲートウェイのＩＰアドレスでない場合（例えば、社外のネットワークからのアクセスであった場合）であっても、証明情報の一致を条件に認証が許可される。このように、本発明によれば、セキュリティを高めるとともに、利便性を高めた認証システムを提供することができる。

（２）また、本発明のプログラムは、前記端末が第２のグループに属するユーザＩＤの端末である場合には、前記第１の条件及び前記第２の条件を満たす場合に、当該第２のグループに属するユーザＩＤの端末に、前記証明情報を送信する処理を行う通信制御部として、コンピュータを更に機能させるようにしてもよい。

本発明によれば、第２のグループに属するユーザＩＤ（例えば、営業部のグループのユーザＩＤ）の端末に対して、ユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致する場合、及び、端末の送信元のアドレス情報が、予め認証データベースに登録されているアドレス情報（例えば、会社のネットワークのゲートウェイのＩＰアドレス）と一致する場合に、証明情報を送信する処理を行う。

つまり、本発明によれば、予め認証データベースに会社のネットワークのゲートウェイのＩＰアドレスを登録した場合に、第２のグループに属するユーザＩＤの端末の送信元が会社のネットワークのゲートウェイのＩＰアドレス（社内のネットワークからのアクセス）である場合に、認証サーバは証明情報を送信する。したがって、本発明によれば、証明情報の付与を、例えば社内からの端末に制限することによってセキュリティを高めることができる。

（３）本発明は、端末と認証サーバとがインターネットを介して接続されたネットワークシステムであって、前記端末から受信したユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する第１の判断部と、前記端末の送信元のアドレス情報が、予め前記認証データベースに登録されているアドレス情報と一致することを第２の条件とする当該第２の条件を満たすか否かを判断する第２の判断部と、前記端末から受信した証明情報が、予め前記認証データベースに登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する第３の判断部と、前記ユーザＩＤのグループを判定するグループ判定部と、前記ユーザＩＤの認証の許可又は不許可を判定する認証判定部と、を含み、前記認証判定部が、前記第１の条件及び前記第２の条件を満たす場合に、第１のグループに属するユーザＩＤの認証を許可し、前記第１の条件及び前記第２の条件を満たす場合、又は、前記第１の条件及び前記第３の条件を満たす場合に、第２のグループに属するユーザＩＤの認証を許可し、前記端末が、ファイルのダウンロードが禁止されているＷｅｂブラウザと、入力部から入力されたユーザＩＤとパスワードとを、前記認証サーバに送信する処理を行う通信制御部と、を含み、前記通信制御部が、前記Ｗｅｂブラウザに予め前記証明情報が設定されている場合に、前記証明情報を前記認証サーバに送信するネットワークシステムに関する。

本発明によれば、第１のグループに属するユーザＩＤと、第２のグループに属するユーザＩＤで異なった方法・フローで認証の許可を判定するので、利便性とセキュリティを高めつつ、グループに応じた適切な認証を行うことができる。

また、本発明の端末は、ファイルのダウンロードが禁止されている特別なＷｅｂブラウザに予め証明情報が設定されている場合に、証明情報を認証サーバに送信する。したがって、本発明によれば、認証が許可されるようにするために、ファイルのダウンロードが禁止されている特別なＷｅｂブラウザを使用するように促すことができる。また、ファイルのダウンロードが禁止されている特別なＷｅｂブラウザの利用促進を図ることによって、ファイルのダウンロードを防止することができ、更にセキュリティを高めることができる。

本実施形態のネットワーク図の一例。 本実施形態の機能ブロック図の一例。 図３（Ａ）（Ｂ）（Ｃ）は、データベースに格納されるデータの説明図。 図４（Ａ）（Ｂ）は、アクセス成功・失敗フローのフローチャート図。 図５は、ＯＴＰ確認フロー、証明情報確認フローのフローチャート図。 図６（Ａ）（Ｂ）は、証明情報付与フローのフローチャート図。 本実施形態の処理の流れを示すフローチャート図。 本実施形態の処理の流れを示すフローチャート図。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．ネットワーク
図１は、本実施形態のネットワーク図の一例である。本実施形態の認証サーバ１０（ＩＤプロバイダ）は、ユーザの端末２０から送信される情報（データ）に基づいて、ユーザの認証を行う。

認証サーバ１０は、ネットワークを介して、複数の端末２０と接続される。例えば、本実施形態の認証サーバ１０は、インターネットを介して、会社や学校などの小規模ネットワーク３０を構成する各端末２０−Ａ〜２０−Ｅと接続されている。また、認証サーバ１０は、インターネットを介して、ｕｓｅｒＡの自宅４１の端末２０−Ｆ、ｕｓｅｒＢが会社から持ち帰った端末２０−Ｂ、ｕｓｅｒＣの自宅４３の端末２０−Ｇ、ｕｓｅｒＤの携帯用の端末２０−Ｈ（例えば、スマートフォン）と接続可能である。なお、本実施形態の端末２０は有線又は無線によって認証サーバ１０と接続される。

また、認証サーバ１０は、ユーザＩＤ、パスワード等の情報が格納された認証データベース１１とネットワーク（イントラネット又はインターネット）を介して接続されている。認証サーバ１０は、認証データベース１１に登録されているデータを参照する処理を行う。また、認証サーバ１０は、認証データベース１１に対して新たなデータの登録や、データの削除、データの変更の命令を行うことができる。

また、認証サーバ１０は、ネットワークを介してメールサーバ３１、ファイルサーバ３２、ショッピングサーバ３３、写真サーバ３４などの種々のサーバ（サービス提供サーバ）と接続されている。例えば、メールサーバ３１は、認証サーバ１０が認証を許可したユーザＩＤに関するメールサービスの提供を行う。また、ファイルサーバ３２は、認証サーバ１０が認証を許可したユーザＩＤに関するファイルサービスの提供を行う。また、ショッピングサーバ３３は、認証サーバ１０が認証を許可したユーザＩＤに関するショッピングサービスの提供を行う。また、写真サーバ３４は、認証サーバ１０が認証を許可したユーザＩＤに関する写真サービスの提供を行う。つまり、ユーザは、１つのユーザＩＤとパスワード等を覚えるだけで、認証サーバ１０への認証が許可されると種々のサーバ３１〜３４からサービスの提供を受けることができるシングルサインオンが可能となる。なお、認証サーバ１０と各種サーバ３１〜３４と認証の許可又は不許可等のデータを送信する場合には、電子署名などを用いてデータの暗号化を行うようにしてもよい。

２．構成
図２は、本実施形態のネットワークシステムの機能ブロック図の一例である。なお、本実施形態のネットワークシステムは、図２の各部を全て含む必要はなく、その一部を省略した構成としてもよい。

まず、認証サーバ１０の機能について説明する。記憶部１７０は、処理部１００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。

また、情報記憶媒体１８０は、コンピュータにより読み取り可能であり、この情報記憶媒体１８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部１００は、この情報記憶媒体１８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。

例えば、情報記録媒体１８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。

処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部１００が、情報記憶媒体１８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部１７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。

処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、通信制御部１１１、判断部１１２、グループ判定部１１３、認証判定部１１４を含む。

通信制御部１１１は、ネットワーク（イントラネット又はインターネット）を介して端末２０とデータを送受信する処理を行う。

例えば、通信制御部１１１は、端末２０によって送信されるユーザＩＤ、パスワードを受信する処理を行う。また、通信制御部１１１は、認証の許可又は不許可を端末２０に送信するようにしてもよい。

また、通信制御部１１１は、認証データベース１１や、メールサーバ３１、ファイルサーバ３２、ショッピングサーバ３３、写真サーバ３４の各種サーバとネットワーク（イントラネット又はインターネット）を介してデータを送受信する処理を行う。例えば、通信制御部１１１は、認証の許可又は不許可を各種サーバ３１〜３４に送信するようにしてもよい。

特に、本実施形態の通信制御部１１１は、端末２０が第２のグループに属するユーザＩＤの端末２０である場合には、第１の判断部１１２Ａの第１の条件及び第２の判断部１１２Ｂの第２の条件を満たす場合に、第２のグループに属するユーザＩＤの端末２０に、証明情報を送信する処理を行う。

判断部１１２は、認証のための判断を行う。特に、本実施形態の判断部１１２は、第１の判断部１１２Ａ、第２の判断部１１２Ｂ、第３の判断部１１２Ｃを含む。

第１の判断部１１２Ａは、端末２０から受信したユーザＩＤとパスワードとが、予め認証データベース１１に登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する。

第２の判断部１１２Ｂは、端末２０の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報と一致することを第２の条件とする当該第２の条件を満たすか否かを判断する。

第３の判断部１１２Ｃは、端末２０から受信した証明情報が、予め認証データベース１１に登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する。

グループ判定部１１３は、ユーザＩＤのグループを判定する。本実施形態では、２以上の複数のグループ（例えば、第１、第２のグループ）のうち、ユーザＩＤがいずれのグループに属するかを、認証データベース１１に登録されているユーザ情報を参照して判定する。

認証判定部１１４は、ユーザＩＤの認証の許可又は不許可を判定する。そして、認証判定部１１４は、第１の判断部１１２Ａの第１の条件及び第２の判断部１１２Ｂの第２の条件を満たす場合に、第１のグループに属するユーザＩＤの認証を許可し、第１の判断部１１２Ａの第１の条件及び第２の判断部１１２Ｂの第２の条件を満たす場合、又は、第１の判断部１１２Ａの第１の条件及び第３の判断部１１２Ｃの第３の条件を満たす場合に、第２のグループに属するユーザＩＤの認証を許可する。

認証サーバ１０は、認証データベース１１を含む。認証データベース１１には、ユーザＩＤ、パスワード、アドレス情報、証明情報などの情報が登録（格納、記憶）される。本実施形態では、管理者からの入力情報に基づいて、予め情報を認証データベース１１に登録してもよい。また、管理者からの入力情報に基づいて、情報の更新処理、情報の削除処理を行うようにしてもよい。また、本実施形態では、認証サーバ１０が、登録処理を行ってもよい。例えば、認証サーバ１０は、端末２０からの登録要求に基づいてユーザＩＤ、パスワード等を登録してもよい。また、本実施形態では、認証サーバ１０が、更新処理を行ってもよい。例えば、認証サーバ１０は、端末２０からの更新要求に基づいてユーザＩＤ、パスワード等を更新してもよい。また、本実施形態では、認証サーバ１０が削除処理を行ってもよい。例えば、認証サーバ１０は、端末２０からの削除要求に基づいてユーザＩＤ、パスワード等を削除してもよい。なお、本実施形態では認証データベース１１の記憶部（記憶領域）が認証サーバ１０の記憶部１７０（記憶領域）から物理的に分離されているが、認証サーバ１０の記憶部１７０に、認証データベース１１のデータを記憶させるようにしてもよい。

また、本実施形態の処理部１００は、Ｗｅｂサーバとして機能するＷｅｂ処理部を含んでいてもよい。例えば、Ｗｅｂ処理部は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じて、端末２０にインストールされているＷｅｂブラウザ２１０の要求に応じてデータを送信する処理、端末２０のＷｅｂブラウザ２１０によって送信されるデータを受信する処理を行う。特に、本実施形態では、Ｗｅｂ処理部が、ユーザ認証を行うためのログイン画面を提供し、端末２０のＷｅｂブラウザ２１０によって送信されたユーザＩＤ、パスワード等のユーザ情報を受信する処理を行うようにしてもよい。

端末２０は、コンピュータ、スマートフォン、タブレット型コンピュータ、携帯電話、ゲーム機などである。

記憶部２７０は、処理部２００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。

また、情報記憶媒体２８０は、コンピュータにより読み取り可能であり、この情報記憶媒体２８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体２８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部２００は、この情報記憶媒体２８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。

例えば、情報記録媒体２８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。

処理部２００は、記憶部２７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部２００が、情報記憶媒体２８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部２７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。

処理部２００（プロセッサ）は、記憶部２７０内の主記憶部をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部２００は、Ｗｅｂブラウザ２１０、通信制御部２１１を含む。端末２０は、Ｗｅｂブラウザ２１０によって、インターネットを介してＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）によって指定されたＷｅｂサーバからの情報を表示させることができる。例えば、端末２０は、認証サーバ１０において認証が許可されると、Ｗｅｂサーバ機能を備えたメールサーバ３１からの端末２０のユーザＩＤのメール情報（ユーザの受信メール、送信されたメール等）を表示させることができる。また、本実施形態のＷｅｂブラウザ２１０は、ファイルのダウンロードが禁止されているＷｅｂブラウザであってもよい。

通信制御部２１１は、ネットワークを介して認証サーバ１０、各種サーバ３１〜３４等とデータを送受信する処理を行う。例えば、通信制御部２１１は、入力部２２０から入力されたユーザＩＤとパスワードとを、認証サーバ１０に送信する処理を行う。また、通信制御部２１１は、Ｗｅｂブラウザ２１０に予め証明情報が設定されている場合に、証明情報を認証サーバ１０に送信するようにしてもよい。また、通信制御部２１１は、認証判定の結果（許可又は不許可）を認証サーバ１０から受信するようにしてもよい。また、通信制御部２１１は、認証サーバ１０によって認証が許可された場合に、メールサーバ３１から当該端末２０のユーザＩＤに関するメール情報を受信するようにしてもよい。

入力部２２０は、ユーザ（操作者）からの入力情報を入力するための入力機器（コントローラ）であり、ユーザの入力情報を処理部２００に出力する。本実施形態の入力部２２０は、ユーザの入力情報（入力信号）を検出する検出部を備えていてもよい。例えば、入力部２２０は、キーボードの入力情報を検出し、タッチパネル型ディスプレイの接触位置（タッチ位置）を検出する。

また、入力部２２０は、３軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。また入力部２２０は、入力機器と一体化されている端末２０（スマートフォン、携帯電話、携帯端末、携帯型ゲーム装置）なども含まれる。

表示部２９０は、Ｗｅｂブラウザの情報、画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネル型ディスプレイ、あるいはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。

３．本実施形態の処理の手法
３．１ 概要
本実施形態の認証サーバ１０は、組織内の複数のユーザについてグループ分けを行い、各グループに応じた認証を行う手法を採用する。つまり、認証サーバ１０は、端末のユーザＩＤのグループを判定し、ユーザＩＤの属するグループに基づいてユーザＩＤの認証の許可又は不許可を判定する手法を採用する。

例えば、認証サーバ１０は、（１）端末から受信したユーザＩＤとパスワードとが、予め認証データベース１１に登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する第１の判断と、（２）端末の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報（例えば、会社のネットワークのゲートウェイのＩＰアドレス）と一致することを第２の条件とする当該第２の条件を満たすか否かを判断する第２の判断と、（３）端末から受信した証明情報が、予め認証データベース１１に登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する第３の判断を行う。そして、認証サーバ１０は、第１の条件及び第２の条件を満たす場合に、第１のグループに属するユーザＩＤ（例えば、開発部のグループのユーザＩＤ）の認証を許可し、第１の条件及び第２の条件を満たす場合、又は、第１の条件及び第３の条件を満たす場合に、第２のグループに属するユーザＩＤ（例えば、営業部のグループのユーザＩＤ）の認証を許可する。

このようにすれば、第１のグループに属するユーザＩＤと、第２のグループに属するユーザＩＤで異なった方法・フローで認証を判定するので、利便性とセキュリティを高めつつ、グループに応じた適切な認証を行うことができる。つまり、会社のネットワークのゲートウェイのＩＰアドレスが認証データベース１１に予め登録されている場合には、第１のグループ（例えば開発グループ）に属するユーザＩＤについては、社内のネットワークからのアクセスに制限することによって、セキュリティを高めることができる。また、第２のグループ（例えば営業グループ）に属するユーザＩＤについては、社内のネットワークからのアクセスも可能であるし、社外のネットワークからのアクセスであった場合であっても、証明情報の一致を条件に認証を許可する。このように、本実施形態では、第２のグループのユーザに対して、セキュリティを高めつつ社外のネットワークからでもアクセス可能なように利便性を高めるようにしている。

３．２ 認証データベース
３．２．１ ユーザ情報
図３（Ａ）は、認証データベース１１に登録されているユーザ情報の一例である。ユーザ情報は、ユーザＩＤ（ユーザ識別情報、ユーザ名）、パスワード、ユーザが属するグループＩＤ（グループ識別情報）を含む。また、ユーザ情報には、ＯＴＰ（ＯＴＰはワンタイムパスワードの略）のｓｅｅｄ番号（種番号）、証明情報を含んでいてもよい。ＯＴＰのｓｅｅｄ番号、証明情報が登録されていない場合には、ＮＵＬＬが設定される。また、パスワード、グループＩＤ、ＯＴＰのｓｅｅｄ番号、証明情報は、ユーザＩＤに対応付けられて登録される。なお、本実施形態の証明情報は、１ユーザあたり１つの識別された情報（アルファベットや数字からなる文字列）とし、ユーザ毎に異なる証明情報が付与される。なお、図３（Ａ）は、組織ＩＤが１の○○会社のユーザ情報である。本実施形態では、組織毎にユーザ情報を管理する。

３．２．２ 組織情報
図３（Ｂ）は、認証データベース１１に登録されている組織情報の一例である。例えば、組織情報は、組織ＩＤ（組織識別情報）、組織名、その組織のネットワークのＩＰアドレス（ネットワークのゲートウェイのＩＰアドレス）を含む。つまり、組織ＩＤに対応づけて、組織名、組織のネットワークのＩＰアドレスが登録される。

３．２．３ フローパターン（処理パターン）
図３（Ｃ）は、認証データベース１１に登録されている各種フローパターン（処理パターン、処理類型）の一例である。例えば、図３（Ｃ）に示すように、グループＩＤに対応づけて、アクセス成功・失敗フロー、ＯＴＰ確認フロー（ワンタイムパスワード確認フロー）、証明情報確認フロー、証明情報付与フローそれぞれのパターン（類型）が登録される。

３．２．３．１ アクセス成功・失敗フロー
まず、アクセス成功・失敗フローについて説明する。アクセス成功・失敗フローとは、ユーザの端末２０から認証サーバ１０へのアクセスの成功又は失敗を判定するための処理の流れである。

図４（Ａ）は、アクセス成功・失敗フローのＡパターンである。Ａパターンについて説明すると、まず、組織のネットワークからのアクセスか否かを判断する（ステップＳ１）。つまり、認証サーバ１０は、端末２０の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報と一致するか否か（第２の判断部１１２Ｂの第２の条件を満たすか否か）を判断する。例えば、認証サーバ１０は、端末２０から受信したパケット情報から、端末２０の送信元（アクセス元）のＩＰアドレスを検出し、端末の送信元のＩＰアドレスが、認証データベースに登録されているＩＰアドレスと一致するか否かを判断する。例えば、端末２０−Ａの送信元のＩＰアドレスが「１２２．２００．２４３．２４０」の場合には、図３（Ｂ）に示すように、端末２０−Ａの送信元のＩＰアドレスが認証データベース１１に登録されているので、「○○会社」のネットワークからのアクセスであると判定できる。つまり、組織（○○会社）のネットワークからのアクセスであると判定される。

そして、組織のネットワークからのアクセスである場合（ステップＳ１のＹ）、成功と判定し（ステップＳ２）、一方、組織のネットワークからのアクセスでない場合（ステップＳ１のＮ）、つまり、組織外（例えば、「○○会社」の社外）のネットワークからのアクセスである場合は、失敗と判定する（ステップＳ３）。図３（Ｃ）の例によれば、開発部、営業部、管理部のグループはパターンＡのフローでアクセス成功・失敗を判定する。

図４（Ｂ）は、アクセス成功・失敗フローのＢパターンの条件式である。Ｂパターンについて説明すると、まず、組織のネットワークからのアクセスか否かを判断する（ステップＳ５）。そして、組織のネットワークからのアクセスである場合（ステップＳ５のＹ）、現在時刻が所定時間帯（例えば、午前９時から午後６時まで）であるか否かを判断する（ステップＳ６）。現在時刻が所定時間帯である場合には（ステップＳ６のＹ）、成功と判定する（ステップＳ７）。一方、組織のネットワークからのアクセスでない場合（ステップＳ５のＮ）、或いは、現在時刻が所定時間帯でない場合には（ステップＳ６のＮ）、失敗と判定する（ステップＳ８）。図３（Ｃ）の例によれば、アルバイトのグループはパターンＢのフローでアクセス成功・失敗を判定する。なお、本実施形態では、アクセス成功・失敗フローの他のパターンを用意しておいてもよい。例えば、端末の送信元のＩＰアドレスのドメイン名が特定の文字列（例えば、「ｊｐ」）を含む場合には、成功と判定し、端末の送信元のＩＰアドレスのドメイン名が特定の文字列を含まない場合には、失敗と判定するフローをＣパターンとして用意しておいてもよい。

３．２．３．２ ＯＴＰ確認フロー
次に、ＯＴＰ確認フロー（ワンタイムパスワード確認フロー）について説明する。ＯＴＰ確認フローとは、ユーザの端末に対して、ＯＴＰの確認を必要とするか否かを判定するための処理の流れである。

図５は、ＡパターンのＯＴＰ確認フローである。例えば、組織のネットワークからのアクセスか否かを判断する（ステップＳ１０）。つまり、上述したように、認証サーバ１０は、端末２０の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報と一致するか否か（第２の判断部１１２Ｂの第２の条件を満たすか否か）を判断する。そして、組織のネットワークからのアクセスである場合（ステップＳ１０のＹ）、不要と判定し（ステップＳ１１）、組織のネットワークからのアクセスでない場合（ステップＳ１０のＮ）、つまり、組織外（例えば、「○○会社」の社外）のネットワークからのアクセスである場合は、必要と判定する（ステップＳ１２）。図３（Ｃ）の例によれば、開発部、管理部、営業部、アルバイトはパターンＡのフローでＯＴＰの確認の要・不要を判定する。なお、本実施形態では、ＯＴＰ確認フローの他のパターンを用意しておいてもよい。

３．２．３．３ 証明情報確認フロー
次に、証明情報確認フローについて説明する。証明情報確認フローとは、ユーザの端末に対して、証明情報の確認を必要とするか否かを判定するための処理の流れである。

本実施形態では、Ａパターンの証明情報確認フローは、ＯＴＰ確認フローのＡパターンと同様のフローを採用している。また、図３（Ｃ）の例によれば、開発部、管理部、営業部、アルバイトはパターンＡのフローで証明情報の確認の要・不要を判定する。なお、本実施形態では、独自の証明情報確認フローを設定してもよいし、複数種類の証明情報確認フローを設定しておいてもよい。

３．２．３．４ 証明情報付与フロー
次に、証明情報付与フローについて説明する。証明情報付与フローとは、ユーザの端末に対して、証明情報を付与するか否かを判定するための処理の流れである。

図６（Ａ）は、Ａパターンの証明情報付与フローである。例えば、組織のネットワークからのアクセスか否かを判断する（ステップＳ２０）。つまり、上述したように、認証サーバ１０は、端末２０の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報と一致するか否か（第２の判断部１１２Ｂの第２の条件を満たすか否か）を判断する。そして、組織のネットワークからのアクセスである場合（ステップＳ２０のＹ）付与すると判定し（ステップＳ２１）、組織のネットワークからのアクセスでない場合（ステップＳ２０のＮ）、つまり、組織外（例えば、「○○会社」の社外）のネットワークからのアクセスである場合は、付与しないと判定する（ステップＳ２２）。図３（Ｃ）の例によれば、営業部はパターンＡの証明情報付与フローで証明情報を付与するか否かを判定する。

図６（Ｂ）は、Ｂパターンの証明情報付与フローである。Ｂパターンは、常に付与しないと判定する（ステップＳ２３）。つまり、組織（例えば、○○会社）内外のネットワークを問わず常に証明情報を付与しないと判定する。図３（Ｃ）の例によれば、開発部、管理部、アルバイトは、パターンＢのフローで証明情報を付与しないと判定される。このように、社外のネットワークからのアクセスを禁止したいグループに対しては証明情報を付与しないようにすることで、セキュリティを更に向上させることができる。

３．２．４ ワンタイムパスワードの説明
本実施形態では、社外のネットワークからのアクセスは、詐欺、盗難などのセキュリティ上の問題があるので、社外のネットワークからアクセスする可能性のある特定のグループに属するユーザ（例えば、営業部のユーザ）の端末２０に、認証サーバ１０とアルゴリズムが同じＯＴＰ（ワンタイムパスワード）を生成するＯＴＰ生成プログラムをインストールし、ワンタイムパスワードを用いた認証を行っている。

例えば、端末２０にインストールされたＯＴＰ生成プログラム（或いはＯＴＰ生成装置の生成プログラム）と、認証サーバ１０にインストールされたＯＴＰ生成プログラムとにおいて、アルゴリズム及びｓｅｅｄ番号（種番号）は一致しており、その結果、端末側（ユーザに付与したＯＴＰ生成装置側）で生成されたＯＴＰと、認証サーバで生成されたＯＴＰが一致していることになる。例えば、ワンタイムパスワード生成プログラムでは、所定周期（３０秒毎）に、時刻とｓｅｅｄ番号（種番号）とに基づいてワンタイムパスワードを生成する処理を行う。なお、本実施形態では、営業部などの特定のグループについて、ワンタイムパスワードの照合処理を含めて認証を行っているが、ワンタイムパスワードの照合処理を行わないように制御してもよい。

３．２．５ 証明情報の説明
また、本実施形態では、営業部などの特定のグループに属するユーザの端末２０に対して証明情報を付与するようにしている。例えば、認証サーバ１０は、端末２０が第２のグループ（例えば、営業部のグループ）に属するユーザＩＤの端末２０である場合には、端末２０から受信したユーザＩＤとパスワードとが、予め認証データベース１１に登録されているユーザＩＤとパスワードと一致する場合（第１の判断部１１２Ａの第１の条件を満たす場合）及び端末２０の送信元のアドレス情報が、予め認証データベース１１に登録されているアドレス情報と一致する場合（第２の判断部１１２Ｂの第２の条件を満たす場合）に、当該第２のグループに属するユーザＩＤの端末に、証明情報を送信する処理を行う。また、端末２０は、Ｗｅｂブラウザを用いて、端末２０と認証サーバ１０との通信を行い、例えば、端末２０は、認証サーバ１０から証明情報を受信した場合には、当該証明情報をＷｅｂブラウザのクッキーとして記憶する処理を行う。「クッキー」とは、ＨＴＴＰ ｃｏｏｋｉｅであり、Ｗｅｂブラウザに記憶される情報のことを示す。

例えば、図１を用いて説明すると、認証データベース１１に、「○○会社」のネットワーク３０のゲートウェイのＩＰアドレス（１２２．２００．２４３．２４０）が登録されているとする。そして、図１に示すように、例えば、営業部のユーザＢが社内にいる際に、社内のネットワークに接続された端末２０−Ｂから認証サーバ１０にアクセスし、認証許可されると認証サーバ１０から証明情報を受信する。つまり、端末２０−ＢのＷｅｂブラウザに、クッキーとして証明情報が記憶される。そして、営業部のユーザＢが端末２０−Ｂを持ち帰り、例えば、自宅のネットワークに端末２０−Ｂを接続し、端末２０−ＢがＷｅｂブラウザを用いてインターネットを介して認証サーバ１０にアクセスすると、入力されたユーザＩＤ、パスワード、及び、Ｗｅｂブラウザのクッキーとして設定された証明情報を認証サーバ１０に送信する。そして、認証サーバ１０は、端末２０−Ｂから受信したユーザＩＤ、パスワード、証明情報を認証データベース１１に登録されているユーザＩＤ、パスワード、証明情報と一致している場合に、認証を許可する。

このように、本実施形態では、営業部のユーザＢが使用する端末２０−Ｂが認証サーバ１０に認証許可されることを契機として端末２０−Ｂが証明情報を取得できる仕組みを提供している。つまり、本実施形態によれば、社内のネットワークから営業グループのユーザＩＤとしてＷｅｂブラウザを用いて認証サーバ１０を正常にログインするだけで証明情報を取得できるので利便性を高めることができる。また、認証サーバ１０では社内のネットワークからのアクセスに対して証明情報を付与することによってセキュリティを強固なものにすることができる。なお、認証サーバ１０は、ユーザの端末に付与する証明情報に有効期限（例えば、証明情報を付与した日から７日間有効とする有効期限）を設定していてもよく、有効期限が切れた証明情報を受信した場合には、当該証明情報を無効として処理してもよい。このようにすれば、更にセキュリティを高めることができる。

３．２．６ その他
本実施形態では、認証サーバ１０が認証データベース１１に登録されているユーザ情報、組織情報、各種フロー等を参照する。また、認証サーバ１０は、端末２０からの要求に応じて、ユーザ情報、組織情報、各種フローの登録処理、更新処理、削除処理を行うようにしてもよい。また、本実施形態では、管理者が認証データベースを管理可能であり、管理者からの入力情報に基づいて、ユーザ情報、組織情報、各種フローの参照、登録、変更、削除等を行うことができる。また、管理者からの入力情報に基づいて、フローの変更、追加、削除等も行うことができる。

３．３ 処理の流れ
図７（Ａ）（Ｂ）は、本実施形態の認証サーバ１０の処理の流れを示すフローチャートである。まず、認証サーバ１０は、端末２０からユーザＩＤとパスワードを受信する（ステップＳ１００）。

次に、受信した端末２０の送信元のＩＰアドレスを確認する（ステップＳ１０１）。例えば、認証サーバ１０は、端末２０から受信したパケット情報から、送信元のＩＰアドレスを検出する。例えば、端末２０−Ａの送信元のＩＰアドレスが「１２２．２００．２４３．２４０」の場合には、図３（Ｂ）に示すように、組織ＩＤ＝１である「○○会社」のネットワークからのアクセスであると判定できる。一方、端末２０−Ａの送信元のＩＰアドレスが認証データベースに登録されていない場合には、会社外（組織外）のネットワークからのアクセス（インターネット上の不特定な端末、不特定なネットワークからのアクセス）であると判定できる。

そして、端末２０から受信したユーザＩＤとパスワードとが正しいか否かを判断する（ステップＳ１０２）。つまり、端末２０から受信したユーザＩＤとパスワードとが、認証データベース１１に登録されているユーザＩＤと（当該ユーザＩＤに対応する）パスワードと一致するか否かを判断する。

端末２０から受信したユーザＩＤとパスワードとが正しい場合、つまり、端末２０から受信したユーザＩＤとパスワードとが、認証データベース１１に登録されているユーザＩＤと（当該ユーザＩＤに対応する）パスワードと一致する場合には（ステップＳ１０２のＹ）、ステップＳ１０３に進む。一方、端末２０から受信したユーザＩＤとパスワードとが正しくない場合、つまり、端末２０から受信したユーザＩＤとパスワードとが、認証データベース１１に登録されているユーザＩＤと（当該ユーザＩＤに対応する）パスワードと一致しない場合には（ステップＳ１０２のＮ）、認証を不許可と判定する（ステップＳ１１３）。

次に、受信したユーザＩＤのグループＩＤを判定する（ステップＳ１０３）。つまり、図３（Ａ）に示すように、認証データベース１１に登録されたユーザＩＤに対応するグループＩＤを参照してグループＩＤを判定する。例えば、受信したユーザＩＤが「ｕｓｅｒＡ」である場合は、「ｕｓｅｒＡ」のグループＩＤは「１」となる。

次に、グループＩＤに基づいてアクセスが成功か否かを判断する（ステップＳ１０４）。図３（Ｃ）に示すように、グループＩＤ毎に、アクセス成功・失敗フローのパターンが設定されているので、グループＩＤに対応するパターンに基づいてアクセス成功又は失敗を判断する。

例えば、図３（Ａ）に示すように「ｕｓｅｒＡ」はグループＩＤが「１」でアクセス成功・失敗フローがＡパターンである。したがって、図４（Ａ）に示すように「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワークからのアクセスである場合には、アクセス成功と判定される（ステップＳ２、ステップＳ１０４のＹ）。一方、「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワーク以外からのアクセスである場合には、アクセス失敗と判定される（ステップＳ３、ステップＳ１０４のＮ）。

また、例えば、図３（Ａ）に示すように「ｕｓｅｒＦ」はグループＩＤが「４」でアクセス成功・失敗フローがＢパターンである。したがって、図４（Ｂ）に示すように、「ｕｓｅｒＦ」が組織（例えば○○会社）のネットワークからのアクセスした場合であって、現在時刻が所定の時間帯内（例えば、午後２時）である場合には、アクセス成功と判定される（ステップＳ７、ステップＳ１０４のＹ）。一方、「ｕｓｅｒＦ」が組織（例えば○○会社）のネットワーク以外からのアクセスである場合や、「ｕｓｅｒＦ」が組織（例えば○○会社）のネットワークからアクセスした場合であっても、現在時刻が所定の時間帯以外の時刻（例えば、午後１１時）である場合には、アクセス失敗と判定される（ステップＳ８、ステップＳ１０４のＮ）。

そして、アクセス成功と判定された場合には（ステップＳ１０４のＹ）、ステップＳ１０５に進む。一方、アクセス失敗と判定された場合（ステップＳ１０４のＮ）は、グループＩＤ＝２か否かを判断する（ステップＳ１１４）。つまり、グループが特定のグループ（例えば、第２のグループ）であるか否かを判断する。そして、グループＩＤ＝２である場合には（ステップＳ１１４のＹ）、ステップＳ１０５に進み、グループＩＤ＝２でない場合には（ステップＳ１１４のＮ）、認証を不許可と判定する（ステップＳ１１３）。

次に、ワンタイムパスワード（ＯＴＰ）を確認するか否かを判断する（ステップＳ１０５）。図３（Ｃ）に示すように、グループＩＤ毎に、ＯＴＰ確認フローのパターンが設定されているので、グループＩＤに対応するフローのパターンに基づいてＯＴＰを確認するか否かを判断する。

例えば、図３（Ａ）に示すように「ｕｓｅｒＡ」はグループＩＤが「１」でＯＴＰ確認フローがＡパターンである。したがって、図５に示すように、「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワークからのアクセスである場合にはＯＴＰの確認が不要と判断され（ステップＳ１１）、ワンタイムパスワードを確認しない（ステップＳ１０５のＮ）。一方、「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワーク以外からのアクセスである場合には、ＯＴＰの確認が必要と判断され（ステップＳ１２）、ワンタイムパスワードを確認する（ステップＳ１０５のＹ）。

そして、ワンタイムパスワードを確認する場合には（ステップＳ１０５のＹ）、ワンタイムパスワードを端末に要求し（ステップＳ１０６）、端末から受信したワンタイムパスワードが正しいか否かを判断する（ステップＳ１０７）。つまり、認証サーバ１０で生成されたワンタイムパスワードと端末２０から受信したワンタイムパスワードが一致するか否かを判断する。ワンタイムパスワードが正しい場合、つまり、認証サーバ１０で生成されたワンタイムパスワードと端末２０から受信したワンタイムパスワードが一致する場合、（ステップＳ１０７のＹ）は、ステップＳ１０８に進む。一方、ワンタイムパスワードが正しくない場合、つまり、認証サーバ１０で生成されたワンタイムパスワードと端末２０から受信したワンタイムパスワードが一致しない場合（ステップＳ１０７のＮ）、認証を不許可と判定する（ステップＳ１１３）。

次に、証明情報を確認するか否かを判断する（ステップＳ１０８）。図３（Ｃ）に示すように、グループＩＤ毎に、証明情報確認フローのパターンが設定されているので、グループＩＤに対応するフローのパターンに基づいて証明情報を確認するか否かを判断する。

例えば、図３（Ａ）に示すように「ｕｓｅｒＡ」はグループＩＤが「１」で証明情報確認フローがＡパターンである。したがって、図５に示すように、「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワークからのアクセスである場合には証明情報の確認が不要と判断され（ステップＳ１１）、証明情報を確認しない（ステップＳ１０８のＮ）。一方、「ｕｓｅｒＡ」が組織（例えば○○会社）のネットワーク以外からのアクセスである場合には、証明情報の確認が必要と判断され（ステップＳ１２）、証明情報を確認する（ステップＳ１０８のＹ）。

そして、証明情報を確認する場合には（ステップＳ１０８のＹ）、端末から受信した証明情報が正しいか否かを判断する（ステップＳ１０９）。つまり、端末２０から受信した証明情報が、予め認証データベース１１に登録されている当該ユーザＩＤに対応する証明情報と一致するか否かを判断する。例えば、ユーザＩＤが「ｕｓｅｒＢ」である端末２０−Ｂから送信された証明情報が「ｒｇ２ｂ９ｉ４ｇ７ｐｘ」である場合には、認証データベース１１に登録されているユーザＩＤ「ｕｓｅｒＢ」に対応する証明情報「ｒｇ２ｂ９ｉ４ｇ７ｐｘ」と一致するので証明情報が正しいと判断される。そして、証明情報が正しい場合（ステップＳ１０９のＹ）は、ステップＳ１１０に進む。一方、証明情報が正しくない場合（ステップＳ１０９のＮ）、認証を不許可と判定する（ステップＳ１１３）。

次に、証明情報を付与するか否かを判断する（ステップＳ１１０）。図３（Ｃ）に示すように、グループＩＤ毎に、証明情報付与フローのパターンが設定されているので、グループＩＤに対応するフローのパターンに基づいて証明情報を付与するか否かを判断する。

例えば、図３（Ａ）に示すように「ｕｓｅｒＢ」はグループＩＤが「２」で証明情報付与フローがＡパターンである。したがって、図６（Ａ）に示すように、「ｕｓｅｒＢ」が組織（例えば○○会社）のネットワークからのアクセスである場合には証明情報を付与すると判定する（ステップＳ２１、ステップＳ１１０のＹ）。一方、「ｕｓｅｒＢ」が組織（例えば○○会社）のネットワーク以外からのアクセスである場合には、証明情報を付与しないと判定する（ステップＳ２２、ステップＳ１１０のＮ）。

また、例えば、図３（Ａ）に示すように「ｕｓｅｒＡ」はグループＩＤが「１」で証明情報付与フローがＢパターンである。したがって、図６（Ｂ）に示すように、「ｕｓｅｒＡ」が○○会社の社内のネットワークからのアクセスか否かにかかわらず、証明情報を付与しないと判定する（ステップＳ２３、ステップＳ１１０のＮ）。

そして、証明情報を付与する場合には（ステップＳ１１０のＹ）、端末２０に証明情報を送信する（ステップＳ１１１）。そして、ステップＳ１１１、又は、ステップＳ１１０のＮの後、認証を許可と判定する（ステップＳ１１２）。以上で処理が終了する。

３．４ ＳＳＬクライアント証明書を利用する例
本実施形態の認証サーバ１０は、証明情報を要求する端末に対して、証明情報の照合に追加して（又は証明情報の照合の替わりに）、端末から送信されるＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）クライアント証明書を用いた認証を行うようにしてもよい。かかる認証を行う場合には、端末２０のＷｅｂブラウザに予めＳＳＬクライアント証明書が設定される。

例えば、端末２０は認証サーバ１０にＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）接続を行い、認証サーバ１０は端末２０にＳＳＬクライアント証明書を要求する。そして、端末２０は、ＳＳＬクライアント証明書を認証サーバ１０に送信する。そして、認証サーバ１０は、署名されたＳＳＬクライアント証明書を解読しクライアント（端末２０）の公開鍵を取得する。端末２０は、送付メッセージにダイジェストを付加し、端末２０の持つ秘密鍵で暗号化する。そして、認証サーバ１０は、端末２０の公開鍵を使ってメッセージを解読し、解読したメッセージからメッセージ・ダイジェストを作成し、端末２０が付加したメッセージ・ダイジェストと比較する。一致が確認された場合には、信頼できる端末２０から改ざんされていないメッセージを受信することになり、認証許可と判定する。

３．５ 特別なＷｅｂブラウザを利用する例
本実施形態では、端末２０にファイルのダウンロードが禁止されているＷｅｂブラウザ５０を設定し、Ｗｅｂブラウザ５０に予め証明情報がクッキーとして設定されている場合に、証明情報を認証サーバ１０に送信するようにしてもよい。このようにすれば、ファイルのダウンロードが禁止されている特別なＷｅｂブラウザ５０を使用するように促すことができる。また、ファイルのダウンロードが禁止されている特別なＷｅｂブラウザ５０の利用促進を図ることによって、ファイルのダウンロードを防止することができ、更にセキュリティを高めることができる。

例えば、図１に示すように、ｕｓｅｒＤの私物の端末２０−Ｈ（例えば、スマートフォンやパーソナルコンピュータ）に、ファイルのダウンロードが禁止された特別なＷｅｂブラウザ５０がインストールされているとする。そして、Ｗｅｂブラウザ５０に予め証明情報を設定する（Ｗｅｂブラウザのクッキーとして証明情報を設定する）。なお、管理者からの入力に基づき、端末２０−ＨのＷｅｂブラウザに証明情報を設定するようにしてもよい。

すると、ｕｓｅｒＤは、社外のネットワークであっても私物の端末２０−Ｈから、認証サーバ１０への認証が許可され、メールサーバ３１等のサービス提供サーバへのログインが可能となり、より利便性の高いネットワークシステムを実現できる。また、証明情報は、通常のＷｅｂブラウザに設定できずに特殊なＷｅｂブラウザ５０にのみ設定できるようにすることで、私物の端末２０−Ｈに対してもセキュリティの管理を行うことができる。

３．６ その他
本実施形態では、ユーザＩＤ・パスワード以外の多要素認証の例として、証明情報、ＯＴＰの照合、ＳＳＬクライアント証明書等を用いた認証を説明したが、他の多要素認証を行うようにしてもよい。

また、本実施形態では、ユーザＩＤ・パスワード判定処理の例として、認証サーバが、予め認証データベースに格納されているパスワードを用いて判定する処理を説明したが、認証データベースにパスワードを格納しないで、他のシステムにユーザＩＤ・パスワード判定処理を委任するようにしてもよい。

１０ 認証サーバ、１１ 認証データベース、１００ 処理部、１１１ 通信制御部、
１１２ 判断部、１１２Ａ 第１の判断部、１１２Ｂ 第２の判断部、
１１２Ｃ 第３の判断部、１１３ グループ判定部、１１４ 認証判定部、
１７０ 記憶部、１８０ 情報記憶媒体、
２０ 端末、２００ 処理部、２１０ Ｗｅｂブラウザ、２１１ 通信制御部、
２２０ 入力部、２７０ 記憶部、２８０ 情報記憶媒体、２９０ 表示部、
５０ ダウンロードが禁止されたＷｅｂブラウザ

Claims (2)

1. 端末と認証サーバとがインターネットを介して接続されたネットワークシステムであって、
   前記認証サーバが、
   前記端末から受信したユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する第１の判断部と、
   予め前記認証データベースに登録されているＩＰアドレスに基づき、前記端末が組織内のネットワークからのアクセスであると判定されることを、第２の条件とする当該第２の条件を満たすか否かを判断する第２の判断部と、
   前記端末から受信した証明情報が、予め前記認証データベースに登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する第３の判断部と、
   前記ユーザＩＤのグループを判定するグループ判定部と、
   第１のグループに属するユーザＩＤに対して、前記第１の条件及び前記第２の条件を満たす場合に認証を許可する認証判定部と、を含み、
   前記認証判定部が、
   第２のグループに属するユーザＩＤに対して、前記第１の条件及び前記第２の条件を満たす場合、又は、前記第１の条件及び前記第３の条件を満たす場合に認証を許可し、
   前記端末が、
   ファイルのダウンロードが禁止されている特別なＷｅｂブラウザと、
   入力部から入力されたユーザＩＤとパスワードとを、前記認証サーバに送信する処理を行う通信制御部と、
   前記特別なＷｅｂブラウザにのみ前記証明情報を設定可能とする証明情報設定部と、を含み、
   前記通信制御部が、
   前記特別なＷｅｂブラウザに予め前記証明情報が設定されている場合に、前記証明情報を前記認証サーバに送信することを特徴とするネットワークシステム。
2. 端末と認証サーバとがインターネットを介して接続されたネットワークシステムであって、
   前記認証サーバが、
   前記端末から受信したユーザＩＤとパスワードとが、予め認証データベースに登録されているユーザＩＤとパスワードと一致することを第１の条件とする当該第１の条件を満たすか否かを判断する第１の判断部と、
   予め前記認証データベースに登録されているＩＰアドレスに基づき、前記端末が組織内のネットワークからのアクセスであると判定されることを、第２の条件とする当該第２の条件を満たすか否かを判断する第２の判断部と、
   前記端末から受信した証明情報が、予め前記認証データベースに登録されている証明情報と一致することを第３の条件とする当該第３の条件を満たすか否かを判断する第３の判断部と、
   前記ユーザＩＤのグループを判定するグループ判定部と、
   第１のグループに属するユーザＩＤに対して、前記第１の条件及び前記第２の条件を満たす場合に認証を許可する認証判定部と、
   第２のグループに属するユーザＩＤに対して、前記第１の条件及び前記第２の条件を満たす場合に、当該第２のグループに属するユーザＩＤの端末に、前記証明情報を送信する処理を行う通信制御部と、を含み、
   前記認証判定部が、
   第２のグループに属するユーザＩＤに対して、前記第１の条件及び前記第２の条件を満たす場合、又は、前記第１の条件及び前記第３の条件を満たす場合に認証を許可し、
   前記端末が、
   入力部から入力されたユーザＩＤとパスワードとを、前記認証サーバに送信する処理を行う通信制御部と、を含み、
   前記通信制御部が、
   前記端末に予め前記証明情報が設定されている場合に、前記証明情報を前記認証サーバに送信することを特徴とするネットワークシステム。

Images