JP2005293161A - 認証システム、認証方法及びコンピュータプログラム - Google Patents

Abstract

【課題】 認証サーバが機能を停止した場合でも、アプリケーションサーバの認証機能を利用可能にする。
【解決手段】 アプリケーションサーバ１０２、１０４は、認証サーバ１０６が停止しているか否かを判断し、停止している場合には、クライアントコンピュータ１０１で入力されるユーザＩＤ及びパスワードの送信先をユーザ認証部２２２ａのＵＲＬとしたＨＴＭＬ１２００ａで記述されるログイン画面１２００ｂをクライアントコンピュータ１０１に送信する。その後、アプリケーションサーバ１０２、１０４は、前記送信したログイン画面１２００ｂを用いてクライアントコンピュータ１０１のユーザが入力したユーザＩＤ及びパスワードを受信すると、そのユーザＩＤ及びパスワードが、ユーザ情報データベース１０３、１０４に登録されているものと一致している場合に限り、クライントコンピュータ１０１のログインを許可する。
【選択図】 図１

Description

本発明は、認証システム、認証方法及びコンピュータプログラムに関し、特に、アプリケーションの利用者を、ネットワークを介して認証するために用いて好適なものである。

従来、利用者が、Ｗｅｂアプリケーションサーバにログインするときには、Ｗｅｂアプリケーションサーバは、あらかじめ利用者に対して発行したユーザＩＤ及びパスワードと、前記ログイン時に利用者端末から送信されたユーザＩＤ及びパスワードとが一致するかどうかを検証し、一致すれば利用者を認証し、そのログインを許可していた。

また、利用者が、複数のＷｅｂアプリケーションサーバを利用するときに、それらのうちの一つにログインが許可されることで他のＷｅｂアプリケーションサーバにも自動的にログインが許可されるＳＳＯ（シングルサインオン）と呼ばれる機能がある。

特許文献１に記載されているように、一般的に、前記ＳＳＯを実現するためには、ユーザＩＤ及びパスワードを集約的に管理し、一元的に利用者を認証する認証サーバが用いられている。特に、前記ＳＳＯに参加するアプリケーションサーバの各々が異なるインターネットドメインに属する場合、ユーザＩＤ及びパスワードなどの認証情報を共有するために認証サーバを利用することが必須となっていた。

特開平９−８１５１８号公報

ここで、上記したようなＳＳＯを実現した場合に、アプリケーションサーバが認証サーバを利用できなくなると、ユーザを認証することができないために、他のアプリケーションとの間で前記ＳＳＯを実現できないだけでなく、個々のアプリケーションサーバも利用できなくなるという問題があった。例えば、運用者が認証サーバの定期的なメンテナンスを行なう場合、認証サーバが故障した場合、認証サーバとアプリケーションサーバとの間での通信障害があった場合などに、アプリケーションサーバは認証サーバを利用できなくなり、個々のアプリケーションサーバも利用できなくなる。

本発明は、前述の問題点に鑑みてなされたものであり、アプリケーションサーバ間のＳＳＯを実現する環境下で認証サーバを利用できなくなった場合でも、ユーザから各アプリケーションサーバへのアクセスを可能にすることを目的とする。

本発明の認証システムは、クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを有し、前記複数のアプリケーションサーバは、前記認証サーバが稼動しているか否かを判断する判断手段と、前記判断手段により前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証手段とを有することを特徴とする。
また、本発明の他の特徴とするところは、クライアント端末と、アプリケーションサーバと、ユーザデータベースと、認証サーバとを有する認証システムであって、前記ユーザデータベースは、前記アプリケーションサーバと第１の通信手段を介して相互に接続され、前記クライアント端末を利用するユーザを認証するための認証情報を保持し、前記アプリケーションサーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第２の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記第１の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証手段と、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理手段とを有し、前記認証サーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求手段と、前記認証要求中継手段により認証要求がなされた後に、前記認証中継処理手段により送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証手段とを有することを特徴とする。

本発明の認証方法は、クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを用いて、前記クライアント端末を使用するユーザを認証する認証方法であって、前記複数のアプリケーションサーバは、前記認証サーバが稼動しているか否かを判断する判断ステップと、前記判断ステップにより前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証ステップとを行なうことを特徴とする。
また、本発明の他の特徴とするところは、アプリケーションサーバと、ユーザデータベースと、認証サーバとを用いて、クライアント端末を使用するユーザを認証する認証方法であって、前記アプリケーションサーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第１の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、第２の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証ステップと、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理ステップとを行い、前記認証サーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求ステップと、前記認証要求中継ステップにより認証要求がなされた後に、前記認証中継処理ステップにより送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証ステップとを行なうことを特徴とする。

本発明のコンピュータプログラムは、クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを用いて、前記クライアント端末を使用するユーザを認証することをコンピュータに実行させるためのコンピュータプログラムであって、前記複数のアプリケーションサーバが、前記認証サーバが稼動しているか否かを判断する判断ステップと、前記判断ステップにより前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証ステップとを行なうことをコンピュータに実行させる特徴とする。
また、本発明の他の特徴とするところは、アプリケーションサーバと、ユーザデータベースと、認証サーバとを用いて、クライアント端末を使用するユーザを認証することをコンピュータに実行させるためのコンピュータプログラムであって、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第１の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、第２の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証ステップと、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理ステップとを、前記アプリケーションサーバが行なうことをコンピュータに実行させるとともに、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求ステップと、前記認証要求中継ステップにより認証要求がなされた後に、前記認証中継処理ステップにより送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証ステップとを、前記認証サーバが行なうことをコンピュータに実行させることを特徴とする。

本発明によれば、クライアント端末を使用するユーザの複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバが稼動していない場合には、前記複数のアプリケーションサーバが、前記クライアント端末を使用するユーザを個別に認証するようにしたので、シングルサインオンを利用した認証システムにおいて、認証サーバが稼動できない場合にも、各アプリケーションサーバがクライアント端末を使用するユーザの認証を行なうことができる。これにより、アプリケーションサーバが認証サーバを利用できない場合でも、ユーザは、各アプリケーションサーバへアクセスすることが可能になる。

次に、図面を参照しながら、本発明の実施の形態について説明する。
図１は、本発明の実施形態を示し、インターネットを用いた認証システムの構成の一例を表した図である。
図１において、インターネット１０７には、インターネットサービスプロバイダー(Internet Service Provider；ＩＳＰ)などの接続手段を用いて世界的規模でコンピュータが相互に通信可能に接続される。各コンピュータは、TCP/IPなどの接続プロトコルで相互に通信することが可能である。このような構成のシステムにおいて、ＨＴＴＰ(Hypertext Transfer Protocol)を用いたＷＷＷ(World Wide Web)サービスは、多くの利用者に利用されている。

図２は、図１に示した本実施形態の認証システムの更に詳細な構成の一例を示す図である。なお、図２では、１台のＷｅｂアプリケーションサーバ１０２だけを示しているが、図１に示したＷｅｂアプリケーションサーバ１０４もＷｅｂアプリケーションサーバ１０２と同様の構成を有している。さらに、図２では、ユーザ情報データベース１０３だけを示しているが、図１に示したユーザ情報データベース１０５もユーザ情報データベース１０３と同様の構成を有している。

図２に示されるように、クライアントコンピュータ１０１には、ユーザエージェント２１１が導入されている。ユーザエージェント２１１としては、Netscape（登録商標）や、Mozilla（登録商標）など、一般的に入手可能なものを利用することができる。ユーザエージェント２１１は、利用者が利用を所望するＷｅｂアプリケーションサーバ１０２に、ＨＴＴＰを主としたプロトコルで接続される。この際、利用者を識別するために、あるいは利用者の接続の可否を判断するために認証と呼ばれる処理を行なう。

本実施形態では、ユーザエージェント２１１は、Ｗｅｂアプリケーションサーバ１０２、あるいは認証サーバ１０６のいずれかによって認証を受ける。図１に示すように、アプリケーションサーバ１０２は、第１のインターネットドメイン（serviceA.com）に属する。そして、認証サーバ１０６は、Ｗｅｂアプリケーションサーバ１０２、１０４が属する第１のインターネットドメインとは異なる第２のインターネットドメイン（authService.com）に属しているものとする。

Ｗｅｂアプリケーションサーバ１０２、１０４は、Ｗｅｂサーバ部２２１と、利用者の認証を行なう認証エージェント部２２２と、Ｗｅｂアプリケーション本体２２３とを備えて構成される。ユーザエージェント２１１から発せられたＨＴＴＰ要求は、Ｗｅｂサーバ部２２１によって受信される。そうすると、Ｗｅｂサーバ部２２１は、受信したＨＴＴＰ要求の内容を解析する。

このようにして、Ｗｅｂサーバ部２２１によって内容が解析されたＨＴＴＰ要求は、認証エージェント部２２２において行なわれる認証処理を経てはじめて、Ｗｅｂアプリケーション本体２２３に転送される。

認証エージェント部２２２は、ユーザ認証部２２２ａ及び認証中継処理部２２２ｂを備えて構成される。
ユーザ認証部２２２ａは、主に利用者が入力したユーザＩＤとパスワードとをユーザ情報データベース１０３、１０５に問い合わせることで利用者を認証する機能を持つ。

ここで、Ｗｅｂサーバ部２２１としては、Apache Software Foundationが提供するApache HTTPdなどを利用することができる。

一般的に、Ｗｅｂアプリケーションサーバ１０２、１０４には、利用者の情報を登録するために、アプリケーション毎に用意されたユーザ情報データベース１０３、１０５が接続される。本実施形態のユーザ情報データベース１０３、１０５は、市販あるいは無料で手に入れることができるリレーショナルデータベース管理サーバ上に配置される。また、ユーザ情報データベース１０３、１０５は、データベースベンダーの独自プロトコル、あるいはＪＤＢＣなど標準技術を用いた接続方式により、Ｗｅｂアプリケーションサーバ１０２、１０４に接続される。

ユーザ情報データベース１０３、１０５は、図９に示すように、ユーザＩＤや、パスワードをはじめとした、利用者に固有の情報を格納するユーザ情報テーブル９００として実現される。このユーザ情報データベース１０３、１０５は、リレーショナルデータベース管理サーバに対してＳＱＬ(Structured Query Language)などの問合せ言語で記述された問合せ文を発行することによって、所望のユーザＩＤを持つ利用者のユーザ情報を取得、変更、削除することができるように構成されている。

本実施形態の特徴の一つは、認証エージェント部２２２において、利用者の認証のために、二つのインターフェースを持つことである。先に説明したユーザエージェント２１１からの認証情報を受け取るユーザ認証部２２２ａはそのうちの一つである。他方のインターフェースは、認証中継処理部２２２ｂによって実現される。

認証中継処理部２２２ｂは、後述する認証サーバ１０６からの認証中継要求を受信し、同じ認証エージェント部２２２内のユーザ認証部２２２ａの提供する機能を用いて認証を行なう。本実施形態では、認証中継処理部２２２ｂは、一般の利用者からは利用されることなく、認証サーバ１０６からの要求のみを受け付ける。認証中継処理部２２２ｂと認証サーバ１０６との間の接続２８は、Ｗ３Ｃ(World Wide Web Consortium)が定めるＳＯＡＰ１．１(Simple Object Access Protocol Version1.1)によるＲＰＣ(Remote Produce Call)によって行なわれる。前記ＳＯＡＰ１．１の実装系としては、Apache Software Foundationが実装しているAxisなどを利用することができる。

一方、認証サーバ１０６は、Ｗｅｂサーバ部２５１、ユーザ認証部２５３、及び認証中継要求部２５２を備えて構成される。

ユーザエージェント２１１からの認証要求は、Ｗｅｂサーバ部２５１によって受信される。そして、Ｗｅｂサーバ部２５１は、受信した認証要求を解析してユーザ認証部２５３に転送する。
本実施形態における特徴の一つは、認証サーバ１０６がユーザ情報データベースを持たないことである。このため、認証サーバ１０６は、対象となるアプリケーションの認証エージェント部２２２に認証を依頼する。具体的に、本実施形態では、ユーザ認証部２５３は、利用者の認証を認証中継要求部２５２に依頼する。そうすると、認証中継要求部２５２は、前述したＳＯＡＰによるＲＰＣ２８により、認証エージェント部２２２内の認証中継処理部２２２ｂに認証要求を行なう。

本実施形態の目的の一つは、認証エージェント部２２２と認証サーバ１０６とに用意された合計２系統の認証経路を用いることにより、認証サーバ１０６を利用したＳＳＯを実現しつつも、アプリケーション単独の認証に自動的に切り替えることにより、アプリケーションの利用率を高めることにある。

ここで、図３のフローチャートを参照しながら、利用者が認証を得るまでの認証システムにおける処理の一例を説明する。
まず、クライアントコンピュータ１０１に配設されたマウスやキーボードなどを用いて利用者が所定の操作を行なうと、クライアントコンピュータ１０１にインストールされたユーザエージェント２１１は、Ｗｅｂアプリケーションサーバ１０２、１０４に接続要求（ＨＴＴＰ要求、リクエスト）を行なう（図３のステップＳ３０１）。

この接続要求は、主として、利用者がクライアントコンピュータ１００１のマウスやキーボードなどを操作して、ＵＲＬ(Uniform Resource Locator)をユーザエージェント２１１に対して入力することによって行なわれる。ユーザエージェント２１１から送信された接続要求は、アプリケーションサーバ１０２、１０４内にインストールされたＷｅｂサーバ部２２１によって受信され、認証エージェント部２２２内のユーザ認証部２２２ａに転送される。

ユーザ認証部２２２ａは、ユーザエージェント２１１に対して認証情報の入力を要求する必要があるか否かを判断する。この判断の結果、ユーザエージェント２１１に対して認証情報の要求が必要である場合、ユーザエージェント２１１に対して認証情報の入力を促す方法として、図１２（ａ）に示すようなＨＴＭＬ１２００ａによって記述された図１２（ｂ）に示すようなログイン画面１２００ｂに、利用者が、利用者登録時に予め決定したユーザＩＤとパスワードとを入力する方法を用いることが一般的である。本実施形態においても、この方法を採用する。

Ｗｅｂアプリケーションサーバ１０２、１０４は、ユーザエージェント２１１に対して、ＨＴＭＬ１２００ａで記述されたログイン画面１２００ｂを提示する。ユーザエージェント２１１は、Ｗｅｂアプリケーションサーバ１０２、１０４から受け取ったログイン画面１２００ｂを、クライアントコンピュータ１０１に配設されたモニタに表示し、利用者に入力を促す。利用者は、クライアントコンピュータ１０１に配設されたマウスやキーボードなどを用いて、自身が記憶しているユーザＩＤとパスワードとを入力した後、ログイン画面１２００ｂ上に表示されている転送ボタン１２１１を押すことで、Ｗｅｂアプリケーションサーバ１０２、１０４へのログインを試みる。

Ｗｅｂアプリケーションサーバ１０２、１０４は、ログイン画面１２００ｂに対して利用者が入力したユーザＩＤとパスワードとの組を、ユーザ情報データベース１０３、１０５内のユーザ情報テーブル９００（図９を参照）に格納されているユーザＩＤと、パスワードとの組と照合することで、利用者の認証を行なう。

ユーザ認証部２２２ａにおいて、ユーザエージェント２１１からの要求がログイン画面１２００ｂに割り当てられたＵＲＬに対する要求であれば、明示的なログイン要求（ログインページへのリクエスト）を意味するため、条件によらずログイン画面１２００ｂをクライアントコンピュータ１０１に表示させるための処理を行なう(図３のステップＳ３１１のＹＥＳ、ステップＳ３４１、Ｓ３０２)。

一方、ユーザエージェント２１１からの要求が明示的なログイン要求でない場合、認証エージェント部２２２内のユーザ認証部２２２ａは、利用者が既に認証済みであるか否かを判断する。すなわち、ユーザ認証部２２２ａは、クライアントコンピュータ１０１に配設されているモニタにログイン画面１２００ｂを表示させずに利用者にアプリケーションを利用させて良いか否かの判断を、すでに接続されたセッションが存在するか（有効なセッションＩＤを持つか）否かで判断する（図３のステップＳ３１２）。

本実施形態においては、有効なセッションの存在確認は、Cookieと呼ばれる技術を使用することで実現する。Cookieは、Ｗｅｂアプリケーションサーバ１０２、１０４と、ユーザエージェント２１１との間で、前回の接続状態を持続的に保持するための技術として広く用いられているものである。本実施形態では、セッションを識別する識別子（セッションＩＤ）をセッションCookieとして保持する。セッションCookieとして保持されるセッション識別子は、Ｗｅｂアプリケーションサーバ１０２、１０４とユーザエージェント２１１との間で確立されたセッションに対して１対１になるように、Ｗｅｂアプリケーションサーバ１０２、１０４で生成されるセッションオブジェクトを一意に識別できる識別子である。

セッションCookieは、ユーザエージェント２１１が起動してから初めてＷｅｂアプリケーションサーバ１０２、１０４に発行された要求の応答に内包される形で、ユーザエージェント２１１に送信される。一般に、Ｗｅｂアプリケーションサーバ１０２、１０４には、利用者が操作するためのログアウトボタンが設けられており、利用者がこのログアウトボタンを押すことで、セッションを終了することができる。そして、このセッションの終了に伴って、Ｗｅｂアプリケーションサーバ１００２、１００４におけるセッションオブジェクトも破棄される。

ユーザ認証部２２２ａは、ステップＳ３１２において、有効なセッション識別子（セッションＩＤ）を確認した場合、該当する要求は、既に認証済みの利用者からの要求と判断して認証エージェントの処理を終了し、アプリケーション本体２２３へ処理要求を転送する(ステップＳ３３１)。

一方、ユーザ認証部２２２ａは、ステップＳ３１２において、有効なセッション識別子を確認しなかった場合、認証サーバ１０６に対してユーザがログインしているか否かを判断する（リモート認証確認）。この判断の結果、すでに認証サーバ１０６に対するログインが成立していれば、Ｗｅｂアプリケーションサーバ１０２、１０４に対してもログインを認める。本実施形態では、認証サーバ１０６に対してログインが認められた利用者は、Ｗｅｂアプリケーションサーバ１０２、１０４に対するログインも認められることをもって、ＳＳＯ（シングルサインオン）を実現している。

前述したリモート認証確認を行なう段階では、以下のようにして処理を進める。本実施形態の特徴の一つは、この段階で、認証サーバ１０６の稼動確認を行なうことにある（図３のステップＳ３１３）。認証エージェント部２２２は、認証サーバ１０６への認証確認要求に先立ち、認証サーバ１０６に実装されている稼動確認ＡＰＩ(Application Programming Interface)を呼び出すことで、認証サーバ１０６の稼動状況を確認する。本実施形態では、稼動確認ＡＰＩは、ＳＯＡＰ１．１によるＲＰＣとして実装されており、稼動確認要求を受け取ると、データベースサーバや、ファイルサーバ等、認証サーバ１０６が稼動するに必要なシステム上の資源が利用可能であるか否かを確認する。稼動確認ＡＰＩは、この確認の結果、認証サーバ１０６として機能を提供することができると判断された場合には「真」、そうでない場合には「偽」を示す真偽値を表す返答を、Ｗｅｂアプリケーションサーバ１０２、１０４（認証エージェント部２２２）に対して行なう(図３のステップＳ３５１)。

稼動確認ＡＰＩを呼び出した認証エージェント部２２２は、受け取った返答に含まれる真偽値を解析する。この確認の結果、認証サーバ１０６が稼動していることを確認した場合には、認証エージェント部２２２は、リモート認証モードに入る(図３のステップＳ３２１)。一方、認証サーバ１０６を利用することができないことを確認した場合には、認証エージェント部２２２は、ローカル認証モードに入る(図３のステップＳ３１５)。

リモート認証モードに入った認証エージェント部２２２は、図３のステップＳ３２１より始まる処理に従って利用者の認証を行なう。

認証エージェント部２２２は、ユーザエージェント２１１が既に認証サーバ１０６で認証されているか否かを確認するための認証確認要求を発行する。この認証確認要求は、認証サーバ１０６上で稼動しているユーザ認証部２５３に対するリダイレクト要求を、ユーザエージェント２１１に発行することで実現される（ステップＳ３２３）。そして、ユーザ認証部２５３は、処理要求をユーザエージュント２１１から受け取ると、認証サーバ１０６とユーザエージェント２１１との間で既にセッションが確立しているか否かを判断する。

認証サーバ１０６におけるセッションの確認は、Ｗｅｂアプリケーションサーバ１０２、１０４内の認証エージェント部２２２におけるセッション確認と同じく、セッションCookieによって確認される。ただし、前述したように、本実施形態では、認証サーバ１０６は、Ｗｅｂアプリケーションサーバ１０２、１０４とは異なるインターネットドメインに属するサーバとして構成されているため、Ｗｅｂアプリケーションサーバ１０２、１０４に対するセッションとは本質的に異なるセッションとして認識される。

認証サーバ１０６とユーザエージェント２１１との間で既にセッションが確立している場合には（図３のステップＳ３５３でＹＥＳの場合には）、ユーザ認証部２５３は、認証サーバ１０６にログイン済みであると判断する(図３のステップＳ３５５)。一方、セッションが確立していることを確認することができない場合には（図３のステップＳ３５３でＮＯの場合には）、ユーザ認証部２５３は、認証サーバ１０６に対するログインが行なわれていない状況と判断し、後述するログイン処理に移る(図３のステップＳ３５４)。

認証サーバ１０６で有効なセッションが確立された場合、Ｗｅｂアプリケーションサーバ１０２、１０４に対してログイン済みのユーザ名を一意に通知することが必要である。このための技術として、標準化団体であるＯＡＳＩＳ(Organization for the Advancement of Structured Information Standards)が策定しているＳＡＭＬ(Security Assertion Markup Language)を採用することが望ましい。

このＳＡＭＬによれば、利用者の認証情報など、機密性の高い情報を安全にＷｅｂアプリケーションサーバ１０２、１０４に転送することができる。ＳＡＭＬの詳細に関しては、ＯＡＳＩＳが発行する標準仕様書Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1、及びBindings and Profiles for OASIS Security Assertion Markup Language (SAML) V1.1で詳細に述べられている。本実施形態では、ＳＡＭＬの仕様の中でもSAML Artifact/Browser Profile（ＳＡＭＬプロファイルと略称する）と呼ばれる、認証サーバ１０６が認証した利用者の認証情報をＷｅｂアプリケーションサーバ１０２、１０４に対して通知する技術を採用する。

ここで、図７を用いて、本実施形態の認証システムに適用される、リモート認証確認時における処理の一例を簡単に説明する。
まず、ユーザエージュエント（ＳＡＭＬプロファイル）２１１は、処理を要求するＷｅｂアプリケーション１０２の認証エージェント２２２のＵＲＬ（ＵＲＬ０２）に、処理の要求を行なう（通信Ｔ７０１）。この要求を受けた認証エージェント２２２は、リモート認証確認要求をユーザエージェント２１１に対して行なう（通信Ｔ７０２）。前述したように、このリモート認証確認要求は、認証サーバ１０６に対してユーザがログインしていることを確認する要求であり、具体的には、認証サーバ１０６のＵＲＬ（ＵＲＬ０１）へのリダイレクトによる接続要求である。
ユーザエージェント２１１は、このようなリモート認証確認要求に従って、認証サーバ１０６に対してリモート認証要求を行なう（通信Ｔ７０３）。このリモート認証要求を受けた認証サーバ１０６は、ユーザエージェント２１１の利用者の認証を行なう。

そして、認証サーバ１０６は、利用者の認証に成功すると、SAML SSO Assertion(以下、アサーションと略称する)と呼ばれるＸＭＬ(eXtensible Markup Language)で記述された認証情報を生成する。好適な例として、アサーションには、Ｗｅｂアプリケーションサーバ１０２、１０４での利用者のユーザＩＤが含まれる。

また、認証サーバ１０６は、アサーションを生成するのと同時に、アサーションと一対一に対応する短ストリングの識別子(SAML Artifact)をユーザエージェント２１１に発行する（通信Ｔ７０４）。発行された識別子（SAML Artifact）は、認証エージェント部２２２（ＵＲＬ０２）に対するリダイレクトによる接続要求に含まれ、このリダイレクトによる接続要求によって、Ｗｅｂアプリケーションサーバ１０２、１０４（本実施形態では認証エージェント部２２２）に通知される（通信Ｔ７０５）。

リダイレクトによる接続要求を受け取ったＷｅｂアプリケーションサーバ１０２、１０４は、そのリダイレクト接続要求に含まれている識別子（SAML Artifact）を取り出す。そして、ＳＡＭＬで定められるＳＯＡＰで実現されたプロトコルにより、アサーションを要求する（通信Ｔ７０６）。このとき、アサーションの要求は、受け取った識別子（SAML Artifact）を内包して発行される。
アサーションの要求を受け取った認証サーバ１０６は、アサーションの要求に含まれている識別子（SAML Artifact）と一意に対応するアサーションを検索する。この検索の結果、該当するアサーションが見つかった場合、認証サーバ１０６は、Ｗｅｂアプリケーションサーバ１０２、１０４に対して、先のアサーションの要求の返答として、見つかったアサーション（認証情報）をＷｅｂアプリケーションサーバ１０２、１０４に送信する（通信Ｔ７０７）。Ｗｅｂアプリケーションサーバ１０２、１０４は、送信されたアサーションを解析することによって、ユーザエージェント２１１を利用する利用者のＷｅｂアプリケーションサーバ１０２、１０４上でのユーザＩＤを知ることができる。そして、このユーザＩＤに基づいて、ユーザエージェント２１１からの処理要求に対する応答を行なう（通信Ｔ７０８）。

一方、稼動確認ＡＰＩにより、認証サーバ１０６が稼動していないことが確認された場合、認証エージェント部２２２は、ローカル認証モードに移る(図３のステップＳ３１５)。ローカル認証モードに移った認証エージェント部２２２は、ログイン処理に移る。

ローカル認証時におけるログイン認証処理は、図５に示すフローチャートに従って進行する。このログイン処理においては、ユーザエージェント２１１に対して、ログイン画面と呼ばれるユーザＩＤ及びパスワードの入力を行なうための画面を利用者に提供することが一般的である。本実施形態では、図１２（ａ）に示すように、<form>タグを内包するＨＴＭＬ１２００ａを利用する。ログイン画面１２００ｂは、図４に示すフローチャートに従って生成される。なお、図４に示すフローチャートは、認証エージュエント２２２によって実行される。

まず、認証モードがリモート認証モードであるかどうかを判断する（図４のステップＳ４０１）。本実施形態の特徴の一つは、認証サーバ１０６の停止時に、Ｗｅｂアプリケーションサーバ１０２、１０４内の認証エージェント部２２２が利用者を認証することにある。このため、認証モードが、リモート認証モードではなく、ローカル認証モードである場合には、<form>タグにおけるaction属性１２０１に、Ｗｅｂアプリケーションサーバ１０２、１０４上に実装されたユーザ認証部２２２ａのＵＲＬを埋め込んでＨＴＭＬ１２００ａを作成する(図４のステップＳ４０３〜Ｓ４０５)。

図３に説明を戻し、以上のようにしてＷｅｂアプリケーションサーバ１０２、１０４で生成されたＨＴＭＬ１２００ａは、ユーザエージュント部２１１に送信される（図３のステップＳ３４１、Ｓ３０２）。
ユーザエージェント部２１１は、Ｗｅｂアプリケーションサーバ１０２、１０４から受信したＨＴＭＬ１２００ａを解析し、ユーザエージェント２１１上にログイン画面１２００ｂを表示し、利用者に対してユーザＩＤとパスワードとの入力を促す（図３のステップＳ３０２）。

ユーザエージェント２１１の利用者は、Ｗｅｂアプリケーションサーバ１０２、１０４に登録されているユーザＩＤと、それに対応するパスワードとを、クライアントコンピュータ１０１に配設されているマウスやキーボードを用いて入力する。入力されたユーザＩＤ及びパスワードの確認処理、すなわちログイン認証は、ローカル認証モードであるか、リモート認証モードであるかにより処理が異なる。

本実施形態のローカル認証時におけるログイン認証処理は、図５に示すフローチャートに従って行なわれる。また、リモート認証時におけるログイン認証処理は、図６に示すフローチャートに従って行なわれる。

ローカル認証時においては、利用者によって入力されたユーザＩＤ及びパスワードは、ログイン画面１２００ｂ上に表示されている転送ボタン１２１１が利用者によって押されることにより、<form>タグのaction属性１２０１に記述されたＵＲＬに送信される（図５のステップＳ５０１）。図４のステップＳ４０３に示したように、ローカル認証モードでは、action属性１２０１に記述されているＵＲＬは、Ｗｅｂアプリケーションサーバ１０２、１０４内のユーザ認証部２２２ａのＵＲＬである。このため、ユーザＩＤ及びパスワードは、Ｗｅｂアプリケーションサーバ１０２、１０４に送信される。

ユーザＩＤ及びパスワードを受け取ったユーザ認証部２２２ａは、受け取ったユーザＩＤ及びパスワードが、ユーザ情報テーブル９００に登録されたユーザＩＤ及びパスワードに合致することを、Ｗｅｂアプリケーションサーバ１０２、１０４に接続されたユーザ情報データベース１０３、１０５から検索する(図５のステップＳ５０２)。ユーザＩＤとパスワードとが一致する登録ユーザが検索された場合には（図５のステップＳ５０３でＹＥＳの場合には）、ユーザ認証部２２２ａは、利用者によるログインが成功したものとみなし、ユーザエージェント２１１との間に確立したセッションを認証済み状態に設定して(ステップＳ５０５)、処理要求をＷｅｂアプリケーション本体２２３に転送する（ステップＳ５０６）。これにより、利用者が所望する処理が実行される。そして、ログイン成功時にクライアントコンピュータ１０１に表示される画面の情報がユーザエージェント２１１に送信される（ステップＳ５０７）。
一方、ユーザＩＤとパスワードとが一致する登録ユーザが検索されなかった場合には（図５のステップＳ５０３でＮＯの場合には）、ＨＴＭＬ１２００ａがログインページ生成処理により生成され、生成されたＨＴＭＬ１２００ａがユーザエージェント２１１に送信される（ステップＳ５０４、Ｓ５０７）。なお、図５のログインページ生成処理は、例えば、図４に示したフローチャートにより実現することができる。

次に、図６のフローチャートを参照しながら、リモート認証モード時におけるログイン認証処理について説明する。
リモート認証モードの場合（図４のステップＳ４０１でＹＥＳと判断された場合）、ログイン画面１２００ｂに埋め込まれる<form>タグのaction属性１２０１は、認証サーバ１０６上に実装されたユーザ認証部２５３のＵＲＬとなる（図４のステップＳ４０２）。また、ユーザエージェント２１１には表示されないHidden属性として、サービスを識別するための識別子(サービスＩＤ)１２０５がログイン画面１２００ｂに埋め込まれる。このサービスＩＤは、予め、認証サーバ１０６の管理者によって、認証サーバ１０６に接続されているＷｅｂアプリケーションサーバ１０２、１０４に対して一意に割り当てられた識別子である。本実施形態では、Ｗｅｂアプリケーションサーバに１０２、１０４組み込まれる認証エージェント部２２２は、サービスＩＤとして、該当するサービスＩＤをログイン画面１２００ｂに埋め込むようにしている。

本実施形態では、認証サーバ１０６は、図１０に示すサービス情報テーブル１０００を記述した構成情報記述ファイルを読み込むことにより、各サービスの認証中継部２２２ｂを表すＵＲＬを取得することができる。

利用者は、リモート認証モードにおいても、ローカル認証モードと同様に、認証エージュエント２２２で生成されたログイン画面１２００ｂにユーザＩＤ及びパスワードの入力を行なうことになる。ただし、ユーザＩＤ及びパスワードが送信されるサーバは、Ｗｅｂアプリケーションサーバ１０２ではなく、認証サーバ１０６となる。

そして、認証サーバ１０６内のユーザ認証部２５３は、Hidden属性として受け取ったサービス名１２０５から、ユーザ認証の依頼先を決定し、認証エージェント部２２２内の認証中継処理部２２２ｂに設けられた外部認証ＡＰＩに対して、受け取ったユーザＩＤ及びパスワードの認証を依頼する(図６のステップＳ６０２)。本実施形態では、外部認証ＡＰＩは、ＳＯＡＰにより実装される。認証サーバ１０６内のユーザ認証部２５３は、ユーザＩＤ及びパスワードを引数として、前記サービスＩＤで示されるＷｅｂアプリケーションサーバ１０２、１０４内の認証中継処理部２２２ｂに対して認証要求を送信する。

この認証要求を受け取った認証中継処理部２２２ｂは、ユーザＩＤ及びパスワードが、ユーザ情報テーブル９００に登録されているユーザＩＤ及びパスワードと合致するデータがあるか否かを、Ｗｅｂアプリケーションサーバ１０２、１０４に接続されたユーザ情報データベース１０３、１０５から検索する（図６のステップＳ６０３）。外部認証ＡＰＩの認証サーバ１０６への返り値は真偽値であり、ユーザＩＤ及びパスワードが一致する登録ユーザが検索された場合には、認証要求ＡＰＩの呼び出しに対する応答として「真」が、そうでない場合は「偽」が認証サーバ１０６へ返される（図６のステップＳ６０４）。

「偽」の返答を受け取った認証サーバ１０６は、ログイン要求を再度発行するために、ログイン処理に移る(図６のステップＳ６０５、Ｓ６０６)。一方、「真」の返答を受け取った認証サーバ１０６は、ユーザの認証が成功したと判断して、ユーザエージェント２１１との間にセッションを確立し(図６のステップＳ６０７)、アプリケーションサーバ１０２、１０４に対して認証されたユーザＩＤを通知するために、前述した認証確認要求段階と同様にＳＡＭＬプロファイル（SAML Artifact）とアサーション（Assertion）による手続きが実行される(図６のステップＳ６０８、６０９、)。その後、認証サーバ１０６は、ログイン成功時の表示画面をユーザエージュント２１１に送信する（図６のステップＳ６１０）。

なお、リモート認証モード時におけるログイン認証処理の概要は、図８に示すようになる。まず、認証エージェント部２２２は、ユーザエージェント２１１からの要求に従って、前述したようにしてログイン画面１２００ｂを生成して、ユーザエージェント２１１に送信する（通信Ｔ８０１）。ユーザエージェント２１１の利用者は、送信されたログイン画面１２００ｂにユーザＩＤとパスワードとを入力する。そうすると、ユーザエージェント２１１は、入力されたユーザＩＤとパスワードとを、ログイン画面１２００ｂを記述するＨＴＭＬ１２００ａに含まれているＵＲＬに従って、認証サーバ１０６に送信する（通信Ｔ８０２）。

前述したように本実施形態では、認証サーバ１０６は、ユーザ情報データベースを直接参照することができない。そこで、認証サーバ１０６は、アプリケーションサーバ１０２（認証エージェント２２２）に対して、ユーザＩＤとパスワードとの照合を要求する（通信Ｔ８０３）。認証エージェント２２２は、ユーザ情報データベース１０３を参照して、ユーザＩＤとパスワードとの照合を行い、その結果を認証サーバ１０６に送信する（通信Ｔ８０４）。こうして、認証サーバ１０６は、利用者の認証に成功すると、アサーションを生成するとともに、アサーションと一対一に対応する短ストリングの識別子(SAML Artifact)をユーザエージェント２１１に発行する（通信Ｔ８０５）。発行された識別子（SAML Artifact）は、認証エージェント部２２２に対するリダイレクトによる接続要求に含まれ、このリダイレクトによる接続要求によって、Ｗｅｂアプリケーションサーバ１０２に通知される（通信Ｔ８０６）。

リダイレクトによる接続要求を受け取ったＷｅｂアプリケーションサーバ１０２は、そのリダイレクト接続要求に含まれている識別子（SAML Artifact）を取り出し、ＳＡＭＬで定められるＳＯＡＰで実現されたプロトコルにより、アサーションを要求する（通信Ｔ８０７）。前述したように、アサーションの要求は、受け取った識別子（SAML Artifact）を内包して発行される。

アサーションの要求を受け取った認証サーバ１０６は、アサーションの要求に含まれている識別子（SAML Artifact）と一意に対応するアサーションを検索する。この検索の結果、該当するアサーションが見つかった場合、認証サーバ１０６は、Ｗｅｂアプリケーションサーバ１０２、１０４に対して、先のアサーションの要求の返答として、見つかったアサーション（認証情報）をＷｅｂアプリケーションサーバ１０２、１０４に送信する（通信Ｔ８０８）。Ｗｅｂアプリケーションサーバ１０２、１０４は、送信されたアサーションを解析することによって、ユーザエージェント２１１を利用する利用者のＷｅｂアプリケーションサーバ１０２、１０４上でのユーザＩＤを知ることができる。そして、このユーザＩＤに基づいて、ユーザエージェント２１１からの処理要求に対する応答を行なう（通信Ｔ８０９）。

以上のように、本実施形態では、Ｗｅｂアプリケーションサーバ１０２、１０４と、認証サーバ１０６との組み合わせにより、ローカル認証と、リモート認証との切り替えが自動的に行われることを特徴とした認証システムを提案したが、さらに、前述したＷｅｂアプリケーションサーバ１０２、１０４とは別のドメインに属する第二のアプリケーションサーバを導入した場合、この第二のアプリケーションサーバ上においても図３で示したフローチャートに従って利用者の認証を行なうことにより、ＳＳＯに対応した認証システムを実現することができる。

より具体的に説明すると、第一のＷｅｂアプリケーションサーバ１０２、１０４に対して、利用者の認証が完了している場合、認証サーバ１０６には、利用者のセッション情報が生成されており、それに対応するセッションCookieが利用者のユーザエージェント２１１に保存されている。この状態において、第一のＷｅｂアプリケーションサーバ１０２、１０４と異なるドメインに属する第二のＷｅｂアプリケーションサーバに利用者が接続要求を発した場合、図３のステップＳ３２３における認証確認要求（リダイレクト要求）において、ユーザエージェント２１１から認証サーバ１０６に対して、第一のＷｅｂアプリケーションサーバの認証時に生成したセッションCookieが事前に送信される。

すなわち、認証サーバ１０６は、セッションCookie及び対応するセッションオブジェクトを検証することにより、利用者が第一のＷｅｂプリケーションサーバ１０２、１０４にログイン中であることを確認することができる。

ここで、図３のステップＳ３５２において、認証サーバ１０６は、第二のＷｅｂアプリケーションサーバに対して、該当する利用者の第二のＷｅｂアプリケーションサーバに登録されたユーザＩＤを知らせることが必要になる。この問題を解決するための一例として、本実施形態では、認証サーバ１０６に、図１１に示すようなユーザＩＤマッピングテーブル１１００を事前に用意する。認証サーバ１０６は、該当するユーザエージェント２１１との間にセッションが確立した段階で、セッションオブジェクトに、利用者に対してあらかじめ一意に発行した識別子（以下、ＳＳＯ＿ＩＤと称する）を格納する。以後、認証サーバ１０６は、認証サーバ１０６とユーザエージェント２１１との間にセッションが確立されている間は、セッションオブジェクトに格納されているＳＳＯ＿ＩＤ、及び図１１に示すユーザＩＤマッピングテーブル１１００を参照することにより、そのＳＳＯ＿ＩＤを持つユーザの各サービス上でのユーザＩＤを取得し、図３のステップＳ３５２において、各ＷｅｂアプリケーションサーバへユーザＩＤを通知することが可能となる。

以上のように本実施形態では、アプリケーションサーバ１０２、１０４は、認証サーバ１０６が停止しているか否かを判断し、認証サーバ１０６が停止している場合には、クライアントコンピュータ１０１で入力されるユーザＩＤ及びパスワードの送信先をユーザ認証部２２２ａのＵＲＬとしたＨＴＭＬ１２００ａをログイン画面１２００ｂとともにクライアントコンピュータ１０１に送信する。その後、アプリケーションサーバ１０２、１０４は、前記送信したログイン画面１２００ｂを用いてクライアントコンピュータ１０１のユーザが入力したユーザＩＤ及びパスワードを、前記ＨＴＭＬ１２００ａの記述内容に従って受信し、受信したユーザＩＤ及びパスワードが、ユーザ情報データベース１０３、１０４に登録されているものと一致するか否かを判断し、一致している場合には、クライントコンピュータ１０１のログインを許可するようにした。これにより、認証サーバ１０６の稼動状況に基づいて、認証サーバ１０６を用いてシングルサインオンを利用した認証を行なうか、それともＷｅｂアプリケーションサーバ１０２、１０４で個別に認証を行なうかを切り替えるようにし、認証サーバ１０６が停止している場合でも、クライアントコンピュータ１０１のユーザを容易に認証することができる認証システムを構築することができる。このように、本実施形態の認証システムによれば、認証サーバ１０６の停止時にも、各Ｗｅｂアプリケーションサーバ１０２、１０４は独自に認証を継続することができるため、各サービスで定められたサービスレベルを維持することができ、認証サーバ１０６を安価に構築することができる。

（本発明の他の実施形態）
上述した実施形態の機能を実現するべく各種のデバイスを動作させるように、該各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、前記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って前記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。

また、この場合、前記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、例えば、かかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。

さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

本発明の実施形態を示し、インターネットを用いた認証システムの構成の一例を表した図である。 本発明の実施形態を示し、インターネットを用いた認証システムの構成の一例を表した図である。 本発明の実施形態を示し、利用者が認証を得るまでの認証システムにおける処理の一例を説明するフローチャートである。 本発明の実施形態を示し、ログイン画面を生成する際の処理の一例を説明するフローチャートである。 本発明の実施形態を示し、ローカル認証時におけるログイン認証処理の一例を説明するフローチャートである。 本発明の実施形態を示し、リモート認証時におけるログイン認証処理の一例を説明するフローチャートである。 本発明の実施形態を示し、リモート認証確認時における処理の一例を説明する図である。 本発明の実施形態を示し、リモート認証モード時におけるログイン認証処理の一例を説明する図である。 本発明の実施形態を示し、ユーザ情報テーブルの記録内容の一例を概念的に示す図である。 本発明の実施形態を示し、サービス情報テーブルの記録内容の一例を概念的に示す図である。 本発明の実施形態を示し、ユーザＩＤマッピングテーブルの記録内容の一例を示す図である。 本発明の実施形態を示し、ログイン画面の一例と、それを記述するＨＴＭＬの一例とを示す図である。

符号の説明

１０１ クライアントコンピュータ
１０２、１０４ Ｗｅｂアプリケーションサーバ
１０３、１０５ ユーザ情報データベース
１０６ 認証サーバ
１０７ インターネット
２１１ ユーザエージェント
２２２ 認証エージェント

Claims (18)

1. クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、
   前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを有し、
   前記複数のアプリケーションサーバは、前記認証サーバが稼動しているか否かを判断する判断手段と、
   前記判断手段により前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証手段とを有することを特徴とする認証システム。
2. クライアント端末と、アプリケーションサーバと、ユーザデータベースと、認証サーバとを有する認証システムであって、
   前記ユーザデータベースは、前記アプリケーションサーバと第１の通信手段を介して相互に接続され、前記クライアント端末を利用するユーザを認証するための認証情報を保持し、
   前記アプリケーションサーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第２の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記第１の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証手段と、
   前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理手段とを有し、
   前記認証サーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求手段と、
   前記認証要求中継手段により認証要求がなされた後に、前記認証中継処理手段により送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証手段とを有することを特徴とする認証システム。
3. 前記認証サーバは、前記第２の認証手段により認証された認証情報を記憶媒体に記憶する記憶手段と、
   前記記憶手段により記憶媒体に記憶された認証情報を前記アプリケーションサーバに通知する認証情報通知手段とを有することを特徴とする請求項２に記載の認証システム。
4. 前記アプリケーションサーバは、前記クライアント端末から前記認証要求を受け付けるのに先立ち、前記第１の認証手段による認証を実行するか、又は前記第２の認証手段による認証を実行するかの何れかを選択し、選択した認証手段を表す識別子をクライアント端末に通知する認証方法通知手段を有することを特徴とする請求項３に記載の認証システム。
5. 前記認証方法通知手段は、前記ユーザを表す識別子をそのユーザが入力することができるようにするためのログイン画面を、前記クライアント端末で表示することができるようにするための情報に、前記選択した認証手段を表す識別子を含めて前記クライアント端末に通知することを特徴とする請求項４に記載の認証システム。
6. 前記選択した認証手段を表す識別子は、前記クライアント端末が行なう認証要求の送付先を表すアドレスであることを特徴とする請求項４又は５に記載の認証システム。
7. 前記認証サーバは、自身の稼動状況を前記アプリケーションサーバに通知する稼動状況通知手段を有することを特徴とする請求項４〜６の何れか１項に記載の認証システム。
8. 前記認証方法通知手段は、前記稼動状況通知手段により前記認証サーバが稼動中であることが通知された場合には、前記第２の認証手段による認証を実行することを選択し、前記稼動状況通知手段により前記認証サーバが稼動中でないことが通知された場合には、前記第１の認証手段による認証を実行することを選択することを特徴とする請求項７に記載の認証システム。
9. クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、
   前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを用いて、前記クライアント端末を使用するユーザを認証する認証方法であって、
   前記複数のアプリケーションサーバは、前記認証サーバが稼動しているか否かを判断する判断ステップと、
   前記判断ステップにより前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証ステップとを行なうことを特徴とする認証方法。
10. アプリケーションサーバと、ユーザデータベースと、認証サーバとを用いて、クライアント端末を使用するユーザを認証する認証方法であって、
    前記アプリケーションサーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第１の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、第２の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証ステップと、
    前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理ステップとを行い、
    前記認証サーバは、前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求ステップと、
    前記認証要求中継ステップにより認証要求がなされた後に、前記認証中継処理ステップにより送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証ステップとを行なうことを特徴とする認証方法。
11. 前記認証サーバは、前記第２の認証ステップにより認証された認証情報を記憶媒体に記憶する記憶ステップと、
    前記記憶ステップにより記憶媒体に記憶された認証情報を前記アプリケーションサーバに通知する認証情報通知ステップとを行なうことを特徴とする請求項１０に記載の認証方法。
12. 前記アプリケーションサーバは、前記クライアント端末から前記認証要求を受け付けるのに先立ち、前記第１の認証ステップによる認証を実行するか、又は前記第２の認証ステップによる認証を実行するかの何れかを選択し、選択した認証方法を表す識別子をクライアント端末に通知する認証方法通知ステップを行なうことを特徴とする請求項１１に記載の認証方法。
13. 前記認証方法通知ステップは、前記ユーザを表す識別子をそのユーザが入力することができるようにするためのログイン画面を、前記クライアント端末で表示することができるようにするための情報に、前記選択した認証手段を表す識別子を含めて前記クライアント端末に通知することを特徴とする請求項１２に記載の認証方法。
14. 前記選択した認証方法を表す識別子は、前記クライアント端末が行なう認証要求の送付先を表すアドレスであることを特徴とする請求項１２又は１３に記載の認証方法。
15. 前記認証サーバは、自身の稼動状況を前記アプリケーションサーバに通知する稼動状況通知ステップを有することを特徴とする請求項１２〜１４の何れか１項に記載の認証方法。
16. 前記認証方法通知ステップは、前記稼動状況通知ステップにより前記認証サーバが稼動中であることが通知された場合には、前記第２の認証ステップによる認証を実行することを選択し、前記稼動状況通知ステップにより前記認証サーバが稼動中でないことが通知された場合には、前記第１の認証ステップによる認証を実行することを選択することを特徴とする請求項１５に記載の認証方法。
17. クライアント端末にアプリケーションを提供する複数のアプリケーションサーバと、
    前記クライアント端末を使用するユーザの前記複数のアプリケーションサーバに対する認証を一括して行なうようにするための認証サーバとを用いて、前記クライアント端末を使用するユーザを認証することをコンピュータに実行させるためのコンピュータプログラムであって、
    前記複数のアプリケーションサーバが、前記認証サーバが稼動しているか否かを判断する判断ステップと、
    前記判断ステップにより前記認証サーバが稼動していないと判断された場合には、前記クライアント端末を使用するユーザを個別に認証する認証ステップとを行なうことをコンピュータに実行させる特徴とするコンピュータプログラム。
18. アプリケーションサーバと、ユーザデータベースと、認証サーバとを用いて、クライアント端末を使用するユーザを認証することをコンピュータに実行させるためのコンピュータプログラムであって、
    前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第１の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、第２の通信手段を介して前記ユーザデータベースに問い合わせて、前記クライアント端末を利用するユーザを認証する第１の認証ステップと、
    前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第３の通信手段を介して前記認証サーバから受け付け、受け付けた認証要求に含まれる識別子に対応する認証情報を、前記認証サーバに送信する認証中継処理ステップとを、前記アプリケーションサーバが行なうことをコンピュータに実行させるとともに、
    前記クライアント端末を利用するユーザを表す識別子を含む認証要求を、第４の通信手段を介して前記クライアント端末から受け付け、受け付けた認証要求に基づいて、前記第３の通信手段を介して前記アプリケーションサーバに認証要求を行なう認証要求中継要求ステップと、
    前記認証要求中継ステップにより認証要求がなされた後に、前記認証中継処理ステップにより送信された認証情報を用いて、前記クライアント端末を利用するユーザを認証する第２の認証ステップとを、前記認証サーバが行なうことをコンピュータに実行させることを特徴とするコンピュータプログラム。

Images