(57)【要約】【目的】利用者が複数のアプリケーションサーバのログイン認証を必要とする際に、シングルサインオンを実現した上で、当該利用者のログイン認証情報がネットワーク上に頻繁に流れないようにすることを目的とする。【構成】利用者が用いる利用者端末を識別するための識別情報を利用者端末が備え、認証サーバが、ログイン認証済みの利用者端末の識別情報を格納するサインオン管理テーブルを備え、利用者端末からアプリケーションサーバにログイン要求があった際に、サインオン管理テーブルに当該利用者端末の識別情報が含まれているか否かを判別し、当該識別情報が含まれている場合に、ログイン認証成功とし、含まれていない場合にログイン認証情報を利用者端末から取得する。【選択図】        図１
2005267529.tif 000002
【特許請求の範囲】
【請求項１】
ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末からログインを要求した際に、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を認証サーバが実施し、前記利用者端末から前記複数のアプリケーションサーバのいずれかへのログインが既に前記認証サーバによって許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証方法において、
前記利用者端末は、当該利用者端末を識別するための識別情報を記憶し、
前記利用者端末は、前記複数のアプリケーションサーバのいずれかに、ログインを要求する情報と前記識別情報とを送信し、
前記アプリケーションサーバは、利用者端末からログインを要求する情報と前記利用者端末の識別情報とを受信し、
前記アプリケーションサーバは、前記利用者端末の識別情報を前記認証サーバに送信し、
前記認証サーバは、前記アプリケーションサーバから、前記利用者端末の識別情報を受信し、
前記認証サーバは、前記複数のアプリケーションサーバのいずれかへのログインが許可された利用者端末の識別情報を記憶している記憶部に、前記受信した識別情報が記憶されているかどうかを判別し、
前記認証サーバは、前記識別情報が前記記憶部に記憶されている場合に、前記識別情報のみにてログインを許可する情報を、前記アプリケーションサーバに送信し、
前記アプリケーションサーバは、前記認証サーバからログインを許可する情報を受信した際に、前記利用者端末からのログインを許可することを特徴とするログイン認証方法。
【請求項２】
ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末からログインを要求した際に、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を認証サーバが実施し、前記利用者端末から前記複数のアプリケーションサーバのいずれかへのログインが既に前記認証サーバによって許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証システムにおいて、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続された前記利用者端末は、
前記利用者端末を識別するための識別情報を記憶する手段と、
前記複数のアプリケーションサーバのいずれかにログインを要求する情報と当該識別情報とを送信する手段とを有し、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続された認証サーバは、
予め、前記複数のアプリケーションサーバにログイン可能な利用者の認証情報を格納するアカウントデータベースと、
前記複数のアプリケーションサーバのいずれかへのログインを許可された利用者端末の識別情報を記憶するサインオン管理テーブルと、
前記アプリケーションサーバから、ログインを要求した利用者端末の識別情報を受信する手段と、
前記受信した識別情報が、前記サインオン管理テーブルに記憶されているかどうかを判別する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されている場合に、ログインを許可する情報を前記アプリケーションサーバに送信する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されていない場合に、前記識別情報を送信してきたアプリケーションサーバに、前記利用者端末を利用する利用者のログイン認証情報を要求する手段と、
前記識別情報を送信してきたアプリケーションサーバから前記ログイン認証情報を受信する手段と、
前記受信した前記ログイン認証情報を、前記アカウントデータベースに基づいて、正当なものかどうかを判別する手段と、
前記ログイン認証情報が正当なものであった場合に、前記利用者端末の識別情報を前記サインオン管理テーブルに記憶し、ログインを許可する情報を前記アプリケーションサーバに送信する手段とを有し、
前記アプリケーションサーバは、
利用者端末からログインを要求する情報と、前記利用者端末の識別情報とを受信する手段と、
前記利用者端末の識別情報を前記認証サーバに送信する手段と、
前記認証サーバから、前記利用者端末を利用する利用者のログイン認証情報を要求された場合に、前記利用者端末から、利用者のログイン認証情報を受信し、前記認証サーバに前記ログイン認証情報を送信する手段と、
前記認証サーバからログインを許可する情報を受信した際に、前記利用者端末からのログインを許可する手段と、
から構成されることを特徴とするログイン認証システム。
【請求項３】
ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末からログインを要求した際に、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を認証サーバが実施し、前記利用者端末から前記複数のアプリケーションサーバのいずれかへのログインが既に前記認証サーバによって許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証システムにおいて、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続され、前記複数のアプリケーションサーバにログインを許可する利用者の認証情報を予め格納するアカウントデータベースと、前記複数のアプリケーションサーバのいずれかとログイン認証を済ませた利用者端末の識別情報を記憶するサインオン管理テーブルとを備えた前記認証サーバを、
前記アプリケーションサーバから、ログインを要求した利用者端末の識別情報を受信する手段と、
前記受信した識別情報が、前記サインオン管理テーブルに記憶されているかどうかを判別する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されている場合に、ログインを許可する情報を前記アプリケーションサーバに送信する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されていない場合に、前記識別情報を送信してきたアプリケーションサーバに、前記利用者端末を利用する利用者のログイン認証情報を要求する手段と、
前記識別情報を送信してきたアプリケーションサーバから前記ログイン認証情報を受信する手段と、
前記受信した前記ログイン認証情報を、前記アカウントデータベースに基づいて、正当なものかどうかを判別する手段と、
前記ログイン認証情報が正当なものであった場合に、前記利用者端末の識別情報を前記サインオン管理テーブルに記憶し、ログインを許可する情報を前記アプリケーションサーバに送信する手段
として機能させることを特徴とする認証プログラム。
【請求項４】
ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末がログインを要求した際に、認証サーバが、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を実施し、前記利用者端末が、前記認証サーバによって、前記複数のアプリケーションサーバのいずれかへのログインが既に許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証システムにおいて、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続され、前記複数のアプリケーションサーバにログインを許可する利用者の認証情報を予め格納するアカウントデータベースと、前記複数のアプリケーションサーバのいずれかとログイン認証を済ませた利用者端末の識別情報を記憶するサインオン管理テーブルとを備えた前記認証サーバを、
前記アプリケーションサーバから、ログインを要求した利用者端末の識別情報を受信する手段と、
前記受信した識別情報が、前記サインオン管理テーブルに記憶されているかどうかを判別する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されている場合に、ログインを許可する情報を前記アプリケーションサーバに送信する手段と、
前記識別情報が前記サインオン管理テーブルに記憶されていない場合に、前記識別情報を送信してきたアプリケーションサーバに、前記利用者端末を利用する利用者のログイン認証情報を要求する手段と、
前記識別情報を送信してきたアプリケーションサーバから前記ログイン認証情報を受信する手段と、
前記受信した前記ログイン認証情報を、前記アカウントデータベースに基づいて、正当なものかどうかを判別する手段と、
前記ログイン認証情報が正当なものであった場合に、前記利用者端末の識別情報を前記サインオン管理テーブルに記憶し、ログインを許可する情報を前記アプリケーションサーバに送信する手段
として機能させる認証プログラムを記憶した記憶媒体。
【請求項５】
ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末がログインを要求した際に、認証サーバが、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を実施し、前記利用者端末が、前記認証サーバによって、前記複数のアプリケーションサーバのいずれかへのログインが既に許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証システムにおいて、
前記認証サーバとデータ通信可能に接続された前記アプリケーションサーバを、
利用者端末からログインを要求する情報と、前記利用者端末の識別情報とを受信する手段と、
前記利用者端末の識別情報を前記認証サーバに送信する手段と、
前記認証サーバから、前記利用者端末を利用する利用者のログイン認証情報を要求された場合に、前記利用者端末から、利用者のログイン認証情報を受信し、前記認証サーバに前記ログイン認証情報を送信する手段と、
前記認証サーバからログインを許可する情報を受信した際に、前記利用者端末からのログインを許可する手段
として機能させることを特徴とする通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある利用者が、ログイン認証を必要とする複数のアプリケーションサーバへのログイン認証をする際に、当該利用者が、一度、いずれかのアプリケーションサーバにログイン認証を済ませれば、他のアプリケーションサーバにアクセスする際に、ログイン認証に必要な認証情報を入力することを不要とするログイン認証に関するものである。
【背景技術】
【０００２】
インターネットの爆発的な普及により、各種のアプリケーションが場所や時間を気にせず気軽に利用できるようになっている。利用者が入力した個人情報のセキュリティを配慮しなければならないようなオンラインショッピングやオンライントレーディングなどのアプリケーションにおいては、利用者が当該アプリケーションを利用しようとした際に、当該利用者がアプリケーション利用者として正当な利用者かどうかを認証するログイン認証処理が用いられている。
【０００３】
また、このログイン認証処理においても、アプリケーションを提供するアプリケーションサーバごとにログイン認証処理が必要であるという煩わしさを解消するために、シングルサインオンという方式が用いられることが多くなってきている。
【０００４】
シングルサインオン方式とは、利用者がアプリケーションを提供しているサーバにアクセスした際に、最初の一度だけログイン認証を行い、正しい認証が行われた後は、同じ利用者が、他のアプリケーションへログインしようとした際に、ログイン認証に対する情報の入力を不要とする方式である。シングルサインオン方式としては一般的にエージェント型と呼ばれる方式と、リバースプロキシ型と呼ばれる方式の２種類が存在している。
【０００５】
図４で示されるようなエージェント型のシングルサインオン方式では、認証サーバ４２にインストールされた認証プログラム５０と通信を行う通信プログラム４７、４８、４９を、アプリケーションサーバ４４、４５、４６におのおのインストールしておき、認証サーバ４２は利用者がアプリケーションを利用できるかどうかを示すログイン認証情報をアカウントデータベース４３内に備え、アプリケーションサーバ４４、４５、４６のうちのいずれかひとつに利用者端末４１からのログイン要求が来た際に、通信プログラム４７、４８、４９のいずれかが認証サーバ４２の認証プログラム５０に、当該利用者の認証処理が既に済まされているかを問い合わせ、当該利用者の認証処理が事前に済んでいることがわかった場合は、利用者のログイン情報の入力を不要とした仕組みである。
【０００６】
また、図５で示されるようなリバースプロキシ型では、利用者が、あるアプリケーションサーバ５４、５５、５６を利用する際には、必ず認証サーバ５２を経由させる形態である。このようにアプリケーションを提供するアプリケーションサーバ５４、５５、５６にアクセスする際に、必ず認証サーバ５２を経由させることによって、認証サーバ５２内の認証プログラム５７が、当該利用者がログイン認証を過去に済ませているかどうかを判断でき、ログイン認証が既に済んでいる場合に、利用者端末５１からの再度のログイン情報入力を省くという仕組みである。
【０００７】
さらに、特許文献１には、上記のリバースプロキシ型を応用させた仕組みが明示されている。特許文献１に記載の仕組みは、利用者が、あるサーバＡでログイン認証を済ませた後に決済サーバであるサーバＢにログインする場合に、サーバＡ内にて、暗号化認証コードを生成し、その暗号化認証コードを、サーバＢをアクセスする際のＨＴＭＬ文あるいはＸＭＬ文に組み込むことで、利用者からの再度のログイン情報入力を省いたシングルサインオンを実現している。
【０００８】
さらに、特許文献２には、あるサーバＡに、他のサーバ（サーバＢ）がリンクされており、利用者がサーバＡにアクセスした際に、自動的に、サーバＡのリンクタグに記載された認証情報をリンク先のサーバ（サーバＢ）に渡し、認証情報を受信したサーバＢが、バックグラウンドにて、認証情報を記載したクッキーファイルを利用者端末に送信することが明示されている。これにより、利用者がサーバＢにアクセスしようとした際に、あらかじめ受信しているクッキーファイルを用いることで、ログイン情報の入力を省くことが可能となっている。
【特許文献１】特開２００３−７８５２１号公報
【特許文献２】特開２００３−５８５０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記のようなエージェント型、特許文献１を含めたリバースプロキシ型の形態では、アプリケーションを提供しているサーバすべてに対して、利用者端末がアクセスした際に、必ず、利用者のログイン識別子およびログインパスワードがネットワーク上を流れることになる。従来のシングルサインオンでは、通常、一回目のサーバアクセス後のログイン認証時に、利用者端末に入力された利用者ＩＤおよびパスワードがサーバに送信されるが、ログイン認証が許可された場合には、サーバから当該利用者端末に、バックグラウンドで利用者ＩＤおよびパスワードが返送され、その利用者端末から他のサーバにアクセスする際に、アクセス命令に利用者ＩＤおよびパスワードを付加して送信することで、利用者情報の入力を不要としている。このことにより、認証をおこなっていないサーバにアクセスするごとに、利用者端末から認証情報である利用者ＩＤおよびパスワードがネットワーク上に送信されることになっていた。
【００１０】
さらに、特許文献２では、ひとつめのサーバに対してアクセスし、ログイン認証が許可された場合には、他のサーバにアクセスすることがなくても、利用者の認証情報を利用者端末にクッキーファイルとして送信することになっていた。
【００１１】
ネットワーク上を認証情報が流れる回数が多ければ多いほど、認証情報を悪意のある人間に盗聴される危険性が増すことになる。本願は、このような問題を解決するために、考えられたログイン認証方式およびログイン認証システムである。
【課題を解決するための手段】
【００１２】
上記課題を解決するため本発明は、ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末がログインを要求した際に、認証サーバが、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を実施し、前記利用者端末が、前記認証サーバによって、前記複数のアプリケーションサーバのいずれかへのログインが既に許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証方法において、
前記利用者端末は、当該利用者端末を識別するための識別情報を記憶し、前記利用者端末は、前記複数のアプリケーションサーバのいずれかに、ログインを要求する情報と前記識別情報とを送信し、前記アプリケーションサーバは、利用者端末からログインを要求する情報と前記利用者端末の識別情報とを受信し、前記アプリケーションサーバは、前記利用者端末の識別情報を前記認証サーバに送信し、前記認証サーバは、前記アプリケーションサーバから、前記利用者端末の識別情報を受信し、前記認証サーバは、前記複数のアプリケーションサーバのいずれかへのログインが許可された利用者端末の識別情報を記憶している記憶部に、前記受信した識別情報が記憶されているかどうかを判別し、前記認証サーバは、前記識別情報が前記記憶部に記憶されている場合に、前記識別情報のみにてログインを許可する情報を、前記アプリケーションサーバに送信し、前記アプリケーションサーバは、前記認証サーバからログインを許可する情報を受信した際に、前記利用者端末からのログインを許可することを特徴とする。
【００１３】
さらに、本発明は、ログインが必要な複数のアプリケーションサーバのいずれかに対して、利用者端末がログインを要求した際に、認証サーバが、前記利用者端末がログインを要求した前記アプリケーションサーバにログインできるかどうかのログイン認証を実施し、前記利用者端末が、前記認証サーバによって、前記複数のアプリケーションサーバのいずれかへのログインが既に許可されている場合に、当該利用者端末からのログイン認証情報の取得を不要とするログイン認証システムにおいて、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続された前記利用者端末は、前記利用者端末を識別するための識別情報を記憶する手段と、前記複数のアプリケーションサーバのいずれかにログインを要求する情報と当該識別情報とを送信する手段とを有し、
前記複数のアプリケーションサーバのそれぞれとデータ通信可能に接続された認証サーバは、予め、前記複数のアプリケーションサーバにログイン可能な利用者の認証情報を格納するアカウントデータベースと、前記複数のアプリケーションサーバのいずれかへのログインを許可された利用者端末の識別情報を記憶するサインオン管理テーブルと、前記アプリケーションサーバから、ログインを要求した利用者端末の識別情報を受信する手段と、前記受信した識別情報が、前記サインオン管理テーブルに記憶されているかどうかを判別する手段と、前記識別情報が前記サインオン管理テーブルに記憶されている場合に、ログインを許可する情報を前記アプリケーションサーバに送信する手段と、前記識別情報が前記サインオン管理テーブルに記憶されていない場合に、前記識別情報を送信してきたアプリケーションサーバに、前記利用者端末を利用する利用者のログイン認証情報を要求する手段と、前記識別情報を送信してきたアプリケーションサーバから前記ログイン認証情報を受信する手段と、前記受信した前記ログイン認証情報を、前記アカウントデータベースに基づいて、正当なものかどうかを判別する手段と、前記ログイン認証情報が正当なものであった場合に、前記利用者端末の識別情報を前記サインオン管理テーブルに記憶し、ログインを許可する情報を前記アプリケーションサーバに送信する手段とを有し、
前記アプリケーションサーバは、利用者端末からログインを要求する情報と、前記利用者端末の識別情報とを受信する手段と、前記利用者端末の識別情報を前記認証サーバに送信する手段と、前記認証サーバから、前記利用者端末を利用する利用者のログイン認証情報を要求された場合に、前記利用者端末から、利用者のログイン認証情報を受信し、前記認証サーバに前記ログイン認証情報を送信する手段と、前記認証サーバからログインを許可する情報を受信した際に、前記利用者端末からのログインを許可する手段とから構成されることを特徴とする。
【発明の効果】
【００１４】
本願に記載された発明を用いることで、アプリケーションを提供している複数のアプリケーションサーバを、利用者が利用する場合に、利用者の認証情報であるログイン識別子およびログインパスワードは、一度しかネットワーク上を流れないようになる。これにより、認証情報が盗聴される可能性が極めて低くなり、安全性が向上するという効果がある。
【発明を実施するための最良の形態】
【００１５】
本発明を用いたログイン認証システムの形態を図１にて示す。利用者端末１１と、アプリケーションを提供する各アプリケーションサーバ１５、１６、１７とがデータ通信可能に接続され、また、アプリケーションサーバ１５、１６、１７のそれぞれは、データベースサーバ１２とデータ通信可能に接続されている形態となる。データベースサーバ１２は、アカウントデータベース１３と、サインオン管理テーブル１４とを備え、データベースサーバ１２内の認証プログラム２１が、アカウントデータベース１３と、アプリケーションサーバ１５、１６、１７のそれぞれが持つ通信プログラム１８、１９、２０とやりとりをして、アプリケーション利用者のログイン認証を行う。さらに、認証プログラム２１は、サインオン管理テーブル１４を用いて、シングルサインオンを実現する。
【００１６】
次に、データベースサーバ１２が備えるアカウントデータベース１３の一例を図２にて示す。アカウントデータベース１３には、アプリケーションサーバ１５、１６，１７が提供するアプリケーションの利用を許可された利用者の認証情報が登録されている。図２では、利用者のＩＤと、利用者のパスワードが対になって登録されている。この利用者のＩＤとパスワードは、暗号化されて登録されていても良い。アカウントデータベース１３に登録されている利用者は、アプリケーションサーバ１５、１６、１７が提供するアプリケーションを利用できるものとする。
【００１７】
このカウントデータベース１３は、図４で示されるようなエージェント型の認証サーバ４２が備えるアカウントデータベース４３、あるいは、図５で示されるようなリバースプロキシ型の認証サーバ５２が備えるアカウントデータベース５３と同様の役割を果たす。
【００１８】
次に、データベースサーバ１２が備えるサインオン管理テーブル１４の一例を図３に示す。サインオン管理テーブル１４には、アプリケーションサーバ１５、１６、１７にて提供されているアプリケーションを、ログイン認証した後に利用している利用者の情報が格納される。図３で示されるサインオン管理テーブル１４は、利用者端末１１のＩＰアドレスを値として持つＩＰアドレスフィールドと、利用者ＩＤを値として持つＩＤフィールドと、シングルサインオンの対象となる複数のアプリケーションサーバ名をフィールド名として持つフィールドにて構成される。図１と照合すると、図３のサーバＡがアプリケーションサーバ１５、サーバＢがアプリケーションサーバ１６、サーバＣがアプリケーションサーバ１７に対応する。
【００１９】
また、アプリケーションサーバ１５、１６、１７が提供するアプリケーションの利用を、利用者が中止した際や、タイムアウトされてアプリケーションの利用が終了した際に、当該利用者に対応する情報がサインオン管理テーブル１４から削除される。当該利用者がアプリケーションサーバ１５、１６、１７にアクセスされるたびに、当該利用者に対応する情報が追加されたり更新されたりする。
【００２０】
さらに、利用者がどのアプリケーションサーバにログイン済であるかもこのサインオン管理テーブル１４内に管理されている。例えば、図３で、ＩＤが” ＴＡＲＯ”である利用者は、現在、サーバＡおよびサーバＢにログイン済であることがわかる。
【００２１】
図１のアプリケーションサーバ１５、１６、１７のそれぞれにインストールされる通信プログラム１８、１９、２０は、図６に示すように、ログイン要求受付手段６１、ログインチェック手段６２、認証情報受信手段６３、認証情報送信手段６４、機器情報送信手段６５、アプリ実行手段６６、ログアウト処理手段６７から構成される。
【００２２】
ログイン要求受付手段６１は、利用者端末１１から、アプリケーションを提供するアプリケーションサーバへのログイン要求と、利用者端末１１の識別情報とを受け付ける働きを持つ。利用者端末１１から送信される要求の種類としては、各アプリケーションサーバ１５、１６、１７が提供していているアプリケーションの場所を示すＵＲＬであっても良い。アプリケーションを提供しているアプリケーションサーバ１５、１６、１７のいずれかにログインした後でアプリケーションが利用できるものとする。
【００２３】
ログインチェック手段６２は、ログイン要求を送信してきた利用者端末１１の識別情報が、データベースサーバ１２のサインオン管理テーブル１４に登録されているかどうかをデータベースサーバ１２に問い合わせる働きを持つ。利用者端末１１の識別情報とは、利用者端末１１に割り振られたＩＰアドレスや、利用者端末１１が最初にアプリケーションサーバにアクセスした際に生成されたセッションＩＤに相当する。
【００２４】
認証情報受信手段６３は、利用者端末１１に認証情報の入力を求める情報を送信するとともに、利用者端末１１に入力された認証情報を受信する働きを持つ。
【００２５】
認証情報送信手段６４は、認証情報受信手段６３で受信した認証情報を、データベースサーバ１２に送信し、アプリケーションサーバをアクセスする利用者として正当な認証情報であるかどうかの判定結果をデータベースサーバ１２から受信する働きを持つ。
【００２６】
機器情報送信手段６５は、利用者機器１１の識別情報を、データベースサーバ１２に送信する働きを持つ。
【００２７】
アプリ実行手段６６は、アプリケーションの実行を行う働きを持つ。具体的には、アプリケーションのメニュー情報を表す情報を利用者端末１１に送信し、利用者からのメニュー選択情報を受信してアプリケーションの実行を行うような仕組みであっても良い。なお、本実施例で言うところのアプリケーションとは、各種ゲーム、通信ソフトの実行をはじめ、音楽や映像などのコンテンツダウンロードやストリーミング受信をも含めたものとしている。
【００２８】
ログアウト処理手段６７は、利用者端末１１からのログアウト要求を受信し、ログアウト要求を発信した利用者端末１１のＩＰアドレスをデータベースサーバ１２に送信する働きを持つ。
【００２９】
次に、図７を用いて、アプリケーションを提供するアプリケーションサーバ内の通信プログラム１８、１９、２０の処理の流れを説明する。
【００３０】
図７のステップＳ７０１は、ログイン要求受付手段６１が、利用者端末１１からアプリケーションの利用要求とともに、利用者端末１１に依存する情報として、利用者端末１１のＩＰアドレスと、アプリケーションサーバにアクセスした際に生成されたセッションＩＤとを受信するステップである。
【００３１】
ステップＳ７０２は、ログインチェック手段６２が、ステップＳ７０１で受信した利用者端末１１のＩＰアドレスが、データベースサーバ１２のサインオン管理テーブル１４に含まれているかどうかを、データベースサーバ１２に問い合わせるステップである。
【００３２】
ステップＳ７０３は、ログインチェック手段６２が、ステップＳ７０２の問い合わせ結果により、利用者端末１１のＩＰアドレスが、データベースサーバ１２のサインオン管理テーブル１４に登録されていたかどうかを判定するステップである。利用者端末１１のＩＰアドレスが、データベースサーバ１２のサインオン管理テーブル１４に登録されていた場合はステップＳ７１２に処理が移り、登録されていない場合はステップＳ７０４に処理が移る。
【００３３】
ステップＳ７０４は、認証情報受信手段６３が、ログイン認証情報の入力を促す画面を表示させるためのデータを、利用者端末１１に送信するステップである。図８に、利用者端末１１にログイン認証情報の入力を促す画面が表示された一例を示す。
【００３４】
ステップＳ７０５は、認証情報受信手段６３が、利用者端末１１から利用者のログイン認証情報を受信するステップである。認証情報とは、例えば、利用者を識別するための利用者ＩＤと利用者のパスワードとなる。
【００３５】
ステップＳ７０６は、認証情報送信手段６４が、ステップＳ７０５で受信したログイン認証情報をデータベースサーバ１２に送信するステップである。
【００３６】
ステップＳ７０７は、認証情報送信手段６４が、データベースサーバ１２からログイン認証結果を受信するステップである。データベースサーバ１２内のログイン認証の処理は、後述する。
【００３７】
ステップＳ７０８は、認証情報送信手段６４がステップＳ７０７で受信した認証結果が成功か失敗かを判別するステップである。認証結果が成功である場合は、ステップＳ７０９に処理が移り、失敗である場合はステップＳ７１３に処理が移る。
【００３８】
ステップＳ７０９は、アプリ実行手段６６がアプリケーションを実行するステップである。
【００３９】
ステップＳ７１０は、アプリ実行手段６６が、利用者端末１１からアプリケーションを終了する信号を受信したかどうかを判定するステップである。アプリケーションを終了する信号を受信した場合は、ステップＳ７１１に処理が移り、受信していない場合はステップＳ７１０を繰り返す。
【００４０】
ステップＳ７１１は、アプリ実行手段６６がアプリケーションを終了するステップである。
【００４１】
ステップＳ７１２は、機器情報送信手段６５がデータベースサーバ１２に、ステップＳ７０１で受信した、アプリケーションサーバにアクセスした際に生成されたセッションＩＤを、データベースサーバ１２に送信するステップである。
【００４２】
ステップＳ７１３は、認証情報送信手段６４が、ログイン認証の失敗を表示させるための情報を、利用者端末１１に送信するステップである。
【００４３】
以上が、アプリケーションを提供するアプリケーションサーバ１５、１６、１７内にそれぞれインストールされた通信プログラム１８、１９、２０の処理の流れである。勿論、データベースサーバ１２とデータ通信可能に接続されているアプリケーションサーバは３つに限らない。また、通信プログラムはひとつのアプリケーションサーバにひとつインストールされていれば良い。
【００４４】
次に、図１のデータベースサーバ１２にインストールされた認証プログラム２１の構成を、図９を参照しながら説明する。データベースサーバ１２にインストールされる認証プログラム２１は、図９に示すように、機器情報チェック手段９１、認証情報取得手段９２、ログイン認証手段９３、機器情報登録手段９４、機器情報削除手段９５によって構成される。
【００４５】
機器情報チェック手段９１は、アプリケーションサーバ１５、１６、１７のいずれかから送信される利用者端末１１のＩＰアドレスが、サインオン管理テーブル１４に含まれているかどうかを判定する働きを持つ。
【００４６】
認証情報取得手段９２は、アプリケーションサーバ１５、１６、１７のいずれかが利用者端末１１から受信したログイン認証情報を取得する働きを持つ。
【００４７】
ログイン認証手段９３は、認証情報取得手段９２で取得した利用者のログイン認証情報と、アカウントデータベース１３に含まれる情報とに基づいて、利用者のログイン認証情報がアプリケーションを利用する正当な利用者を示すものであるかどうかを判断する働きを持つ。
【００４８】
機器情報登録手段９４は、アプリケーションサーバ１５、１６、１７のいずれかが利用者端末１１から取得した利用者端末１１のＩＰアドレスとセッションＩＤと利用者ＩＤを、サインオン管理テーブル１４に登録するステップである。なお、既にログイン認証が済まされている場合は、セッションＩＤのみがサインオン管理テーブル１４に追加される。
【００４９】
機器情報削除手段９５は、アプリケーションサーバ１５、１６、１７のいずれかから、ログアウト要求を示す情報と、ログアウト要求を送信した利用者端末１１のＩＰアドレスとを受信するステップである。
【００５０】
次に、認証プログラム２１におけるログイン認証の処理の流れを、図１０を参照しながら説明する。
【００５１】
図１０のステップＳ１００１は、認証プログラム２１の機器情報チェック手段９１が、利用者端末１１のＩＰアドレスをアプリケーションサーバ１５、１６、１７のいずれかから受信するステップである。
【００５２】
次のステップＳ１００２は、ステップＳ１００１で受信した利用者端末１１のＩＰアドレスが、サインオン管理テーブル１４に既に含まれているかどうかを、機器情報チェック手段９１がチェックするステップである。当該ＩＰアドレスがサインオン管理テーブル１４に含まれている場合は、ステップＳ１００７に処理が移り、含まれていない場合はステップＳ１００３に処理が移る。
【００５３】
例えば、現在のサインオン管理テーブル１４を図３とし、仮に、アプリケーションサーバ１５から、ＩＰアドレス”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”を機器情報チェック手段９１が受信したときに、図３が示すサインオン管理テーブル１４のＩＰアドレスフィールドの値として、このＩＰアドレス”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”を持つものがあるかどうかをステップＳ１００２にてチェックする。図３の場合は、ＩＰアドレスフィールドに”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”を持つものが存在することがわかるため、ステップＳ１００７に処理が移る。
【００５４】
なお、通常、ＩＰアドレスは数字列で表現されるが、本実施例ではすべてアルファベット列での表現としている。
【００５５】
ステップＳ１００３は、機器情報チェック手段９１が、ステップＳ１００１で受信したＩＰアドレスがサインオン管理テーブル１４に含まれていない旨の情報を、利用者端末１１のＩＰアドレスを送信してきたアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）に送信するステップである。
【００５６】
ステップＳ１００４は、認証情報取得手段９２が、利用者端末１１のＩＰアドレスを送信してきたアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）からログイン認証情報を受信するステップである。例えば、機器情報チェック手段９１にＩＰアドレスを送信してきたアプリケーションサーバがアプリケーションサーバ１５だとし、利用者端末１１のＩＰアドレスがサインオン管理テーブル１４に存在していた場合に、アプリケーションサーバ１５からログイン認証情報を受信する。
【００５７】
この場合の、ログイン認証情報は、アプリケーションサーバ１５にて提供されているアプリケーションを利用しようとした利用者の利用者ＩＤとパスワードであり、利用者端末１１からアプリケーションサーバ１１に送信されたものとなる。ログイン認証情報は暗号化されている場合も考えられており、暗号化されている場合は、本ステップにて複合しても良い。
【００５８】
次のステップＳ１００５は、ステップＳ１００４にて受信したログイン認証情報と、アカウントデータベース１３とを照合して、このログイン認証情報がアプリケーションを利用する（アプリケーションサーバにログインする）のに正当な利用者を示す情報であるかどうかを、ログイン認証手段９３が判断するステップである。
【００５９】
ログイン認証情報がアプリケーションを利用するに正当なものと認証された場合は、ステップＳ１００６に処理が移り、正当なものでないとされた場合は、ステップＳ１００９に処理が移る。
【００６０】
例えば、現在のアカウントデータベース１３が図２で示されるものであり、ステップＳ１００４で受信したログイン認証情報が、利用者ＩＤが”ＪＩＲＯＵ”で、パスワードが”ｌｏ０２ｎｈｇｈ”としたとき、このログイン認証情報は、アカウントデータベース１３に含まれるので、正当なログイン認証情報であるとされる。
【００６１】
ステップＳ１００６は、機器情報登録手段９４が、ステップＳ１００１で受信したＩＰアドレスと、ステップＳ１００４で受信した利用者ＩＤとセッションＩＤとを対応づけたレコードを、サインオン管理テーブル１４内に新しく追加するステップである。
【００６２】
例えば、現在のサインオン管理テーブル１４が図１１であったとし、図１１のサーバＡがアプリケーションサーバ１５、サーバＢがアプリケーションサーバ１６、サーバＣがアプリケーションサーバ１６に相当するとする。そこで、利用者ＩＤが”ＪＩＲＯＵ”で、その利用者の利用者端末１１のＩＰアドレスが”ＺＺＺ．ＺＺＺ．ＺＺＺ．ＺＺＺ”で、アプリケーションサーバ１５へのログイン認証が正しく終了した場合には、ステップＳ１００６にて、利用者ＩＤが”ＪＩＲＯＵ”である利用者に相当するレコードが新しく登録され、図１２に示されるサインオン管理テーブル１４に変更される。
【００６３】
ステップＳ１００７は、機器情報登録手段９４が、サインオン管理テーブル１４のステップＳ１００１で受信したＩＰアドレスと、当該ＩＰアドレスを送信してきたアプリケーションサーバとに対応するフィールドに、利用者端末１１が当該アプリケーションサーバにアクセスした際に生成されたセッションＩＤを登録するステップである。
【００６４】
例えば、現在のサインオン管理テーブル１４が図１３であったとし、図１３のサーバＡがアプリケーションサーバ１５、サーバＢがアプリケーションサーバ１６、サーバＣがアプリケーションサーバ１６に相当するとする。そこで、利用者ＩＤが”ＴＡＲＯＵ”で、その利用者の利用者端末１１のＩＰアドレスが”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”で、アプリケーションサーバ１７へのログイン認証が正しく終了した場合には、ステップＳ１００７にて、アプリケーションサーバ１７に相当するサーバＣフィールドの値としてセッションＩＤが登録され、図１４に示されるようなサインオン管理テーブル１４に変更される。
【００６５】
なお、ステップＳ１００７にてサインオン管理テーブル１４に登録するセッションＩＤは、ある利用者がどのアプリケーションサーバを現在、利用しているかを示す役割を果たすものであり、セッションＩＤに限らず、１と０で表されるフラグなどであっても良い。
【００６６】
ステップＳ１００８は、機器情報登録手段９４が、ログイン認証が成功した旨のデータを認証要求のあったアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）に送信するステップである。
【００６７】
ステップＳ１００９は、機器情報登録手段９４が、ログイン認証が失敗した旨のデータを認証要求のあったアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）に送信するステップである。
【００６８】
以上が本発明の認証プログラム２１のログイン認証の処理の流れである。なお、先に述べた実施例では、利用者端末１１のＩＰアドレスに対応させた情報をサインオン管理テーブル１４に登録し、ステップＳ１００２にて、ステップＳ１００１で受信したＩＰアドレスと同じＩＰアドレスがサインオン管理テーブル１４に登録されているかどうかを判別した。
【００６９】
他の方法として、利用者端末１１が最初にアプリケーションサーバにアクセスした際に生成されたセッションＩＤをサインオン認証用セッションＩＤとして、当該サインオン認証用セッションＩＤに対応づけて情報をサインオン管理テーブル１４に登録し、そのサインオン認証用セッションＩＤを利用者端末１１が記録し、データベースサーバ１２との通信時に当該サインオン認証用セッションＩＤを送信することでも実現可能である。この場合は、ステップＳ１００２にて、ステップＳ１００１で受信したサインオン認証用セッションＩＤと同じサインオン認証用セッションＩＤがサインオン管理テーブル１４に登録されているかどうかを判別することになる。また、他のステップにてＩＰアドレスを用いているところを、このサインオン認証用セッションＩＤにて代用することも実現可能である。この場合のサインオン管理テーブル１４の一例は、図１５に示されるようになる。
【００７０】
次に、アプリケーションサーバ１５、１６、１７のいずれかにログインしている利用者から、ログインしているアプリケーションサーバに対してログアウト要求が利用者端末１１から出された場合の処理の流れを図１６および図１７を参照しながら説明する。
【００７１】
図１６はアプリケーションサーバ１５、１６、１７のそれぞれにインストールされた通信プログラム１８、１９、２０のログアウト処理の流れを示したものであり、図１７は、データベースサーバ１２にインストールされた認証プログラム２１のログアウト処理の流れを示したものである。
【００７２】
図１６のステップＳ１６０１は、通信プログラム１８、１９、２０のログアウト処理手段６７が、利用者端末１１からログアウト要求と、利用者端末１１のＩＰアドレスを受信するステップである。
【００７３】
次のステップＳ１６０２は、ログアウト処理手段６７が、ステップＳ１６０１で受信したログアウト要求とＩＰアドレスとをデータベースサーバ１２に送信するステップである。
【００７４】
ステップＳ１６０３は、ログアウト処理手段６７が、データベースサーバ１２からログアウト処理結果を受信するステップである。
【００７５】
ステップＳ１６０４は、ログアウト処理手段６７が、ステップＳ１６０３で受信したログアウト処理結果を表示するための情報を利用者端末１１に送信するステップである。利用者端末１１には、この情報により、ログアウト処理が無事に終了したか、ログアウト処理が失敗したかが表示される。
【００７６】
図１７のステップＳ１７０１は、認証プログラム２１の機器情報削除手段９５が、アプリケーションサーバ１５、１６、１７にインストールされた通信プログラム１８、１９、２０のいずれかから、ログアウト要求と、ログアウト要求を出した利用者端末１１のＩＰアドレスとを受信するステップである。
【００７７】
次のステップＳ１７０２は、機器情報削除手段９５が、ステップＳ１７０１にて受信したＩＰアドレスがサインオン管理テーブル１４に含まれているかどうかを判別するステップである。もし、ＩＰアドレスがサインオン管理テーブル１４に含まれている場合は、ステップＳ１７０３に処理が移り、含まれていない場合はステップＳ１７０５に処理が移る。
【００７８】
ステップＳ１７０３は、機器情報削除手段９５が、サインオン管理テーブル１４からステップ１７０１で受信したＩＰアドレスに関する情報を削除するステップである。例えば、現在のサインオン管理テーブル１４が図１８であったとし、図１８のサーバＡがアプリケーションサーバ１５、サーバＢがアプリケーションサーバ１６、サーバＣがアプリケーションサーバ１６に相当するとする。そこで、利用者ＩＤが”ＴＡＲＯＵ”で、その利用者の利用者端末１１のＩＰアドレスが”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”とする利用者が、アプリケーションサーバ１７へログアウト要求を出した際に、ステップＳ１７０３にて、サインオン管理テーブル１４内のＩＰアドレスが”ＸＸ．ＸＸＸ．ＸＸ．ＸＸＸ”に対応づけられているすべてのデータが削除され、図１９に示されるサインオン管理テーブル１４に変更される。
【００７９】
ステップＳ１７０４は、機器情報削除手段９５が、ログアウト処理が終了した旨のデータを、ログアウト要求を送信してきたアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）に送信するステップである。
【００８０】
ステップＳ１７０５は、機器情報削除手段９５が、ログアウト処理が失敗した旨のデータを、ログアウト要求を送信してきたアプリケーションサーバ（アプリケーションサーバ１５、１６、１７のいずれか）に送信するステップである。以上がログアウト処理の流れである。
【００８１】
なお、利用者端末１１が最初にアプリケーションサーバにアクセスした際に生成されたセッションＩＤをサインオン認証用セッションＩＤとして、当該サインオン認証用セッションＩＤに対応づけて情報をサインオン管理テーブル１４に登録した場合は、認証プログラム２１および通信プログラム１８、１９、２０における各ステップのＩＰアドレスをサインオン認証用セッションＩＤに置き換えることで実現可能である。以上が本発明を用いたログイン認証システムの実施形態である。
【００８２】
また、図２０は、上記で示した認証プログラム２１を記憶した記憶媒体を利用する実施形態の一例である。データベースサーバ２０１が記憶媒体２０２に記憶された認証プログラム２１を読みこみ、認証プログラム２１を実行することも可能である。以上が本発明の実施例を示したものである。
【産業上の利用可能性】
【００８３】
本発明を用いることにより、ある利用者が、アプリケーションが提供される複数のアプリケーションサーバにログインする際において、最初のアプリケーションサーバのみにログイン認証を行い、他のアプリケーションサーバ利用時にはログイン認証情報の入力を不要とするシングルサインオンを実現するとともに、利用者のログイン認証情報を複数回、ネットワーク上に流さないことが実現できる。これにより、ネットワーク上に流れる認証情報を盗聴される危険性を少なくできる効果がある。
【図面の簡単な説明】
【００８４】
【図１】本発明の実施例における全体構成を示す図。
【図２】本発明の実施例におけるアカウントデータベースの一例を示す図。
【図３】本発明の実施例におけるサインオン管理テーブルの一例を示す図。
【図４】従来のエージェント型シングルサインの形態を示す図。
【図５】従来のリバースプロキシ型シングルサインオンの形態を示す図。
【図６】本発明の実施例における通信プログラムの構成を示す図。
【図７】本発明の実施例における通信プログラムのログイン認証処理の流れを示すフロー図。
【図８】本発明の実施例における利用者端末に表示されるログイン認証情報入力画面の一例を示す図。
【図９】本発明の実施例における認証プログラムの構成を示す図。
【図１０】本発明の実施例における認証プログラムのログイン認証処理の流れを示すフロー図。
【図１１】本発明の実施例におけるレコード追加前のサインオン管理テーブルの一例を示す図。
【図１２】本発明の実施例におけるレコード追加後のサインオン管理テーブルの一例を示す図。
【図１３】本発明の実施例におけるセッションＩＤ追加前のサインオン管理テーブルの一例を示す図。
【図１４】本発明の実施例におけるセッションＩＤ追加後のサインオン管理テーブルの一例を示す図。
【図１５】本発明の実施例におけるセッションＩＤに対応づけたサインオン管理テーブルの一例を示す図。
【図１６】本発明の実施例における通信プログラムのログアウト処理の流れを示すフロー図。
【図１７】本発明の実施例における認証プログラムのログアウト処理の流れを示すフロー図。
【図１８】本発明の実施例におけるログアウト前のサインオン管理テーブルの一例を示す図。
【図１９】本発明の実施例におけるログアウト前のサインオン管理テーブルの一例を示す図。
【図２０】本発明の実施例における、認証プログラムを記憶した記憶媒体をデータベースサーバにインストールする一例を示す図。
【符号の説明】
【００８５】
１１、４１、５１  利用者端末
１２、２０１  データベースサーバ
１３、４３、５３  アカウントデータベース
１４  サインオン管理テーブル
１５、１６、１７、４４、４５、４６、５４、５５、５６  アプリケーションサーバ
１８、１９、２０、４７、４８、４９  通信プログラム
２１、５０、５７  認証プログラム
４２、５２  認証サーバ
６１  ログイン要求受付手段
６２  ログインチェック手段
６３  認証情報受信手段
６４  認証情報送信手段
６５  機器情報送信手段
６６  アプリ実行手段
６７  ログアウト処理手段
９１  機器情報チェック手段
９２  認証情報取得手段
９３  ログイン認証手段
９４  機器情報登録手段
９５  機器情報削除手段
２０２  記憶媒体
【図１】
2005267529.tif 000003
【図２】
2005267529.tif 000004
【図３】
2005267529.tif 000005
【図４】
2005267529.tif 000006
【図５】
2005267529.tif 000007
【図６】
2005267529.tif 000008
【図７】
2005267529.tif 000009
【図８】
2005267529.tif 000010
【図９】
2005267529.tif 000011
【図１０】
2005267529.tif 000012
【図１１】
2005267529.tif 000013
【図１２】
2005267529.tif 000014
【図１３】
2005267529.tif 000015
【図１４】
2005267529.tif 000016
【図１５】
2005267529.tif 000017
【図１６】
2005267529.tif 000018
【図１７】
2005267529.tif 000019
【図１８】
2005267529.tif 000020
【図１９】
2005267529.tif 000021
【図２０】
2005267529.tif 000022