JP2005346571A - 認証システム及び認証方法 - Google Patents

Abstract

【課題】 シングルサインオンの環境を実現する認証サーバが機能しなくなった場合でも、各アプリケーションサーバにおいて利用者の認証処理を可能とする認証システム及び認証方法を提供する。
【解決手段】 認証エージェント２２２は、認証サーバシステム１０６に利用者の認証を行うための認証情報を発行するよう依頼し、依頼に応じて認証サーバシステム１０６から認証情報を得た場合に、その認証情報を基に利用者の認証を行う。Ｗｅｂアプリケーション部２２３は、記認エージェント２２２により認証された利用者のクライアントコンピュータ１０１に要求に応じたサービスを提供する。認証サーバシステム１０６は、認証サーバが停止している場合には、停止情報をアプリケーションサーバ１０２へ通知する。これにより、アプリケーションサーバ１０２はクライアントコンピュータ１０１へ認証に必要な情報を要求する。
【選択図】 図２

Description

本発明は、ネットワークを介してＷｅｂアプリケーションを利用する利用者の認証を行う認証システム及び認証方法に関するものである。

従来、利用者が利用者端末よりネットワークを介してアプリケーションサーバにログインする時には、アプリケーションサーバは、あらかじめ利用者に対して発行したユーザＩＤとパスワードを参照して、ログイン時に利用者端末から受信したユーザＩＤ及びパスワードが参照したものと一致するか否かを検証し、一致すれば利用者を認証し、そのログインを許可していた。

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

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

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

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

本発明は、上述した事情を考慮してなされたもので、シングルサインオンの環境を実現する認証サーバが機能しなくなった場合でも、各アプリケーションサーバにおいて利用者の認証処理を可能とすることができる認証システム及び認証方法を提供することを目的とする。

この発明は、上述した課題を解決すべくなされたもので、本発明による認証システムにおいては、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システムであって、前記アプリケーションサーバは、前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信手段と、前記受信手段がサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼手段と、前記認証情報依頼手段の依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う認証手段と、前記認証手段により認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供手段とを具備し、前記認証サーバシステムは、前記認証情報に関する処理を行う認証サーバと、前記アプリケーションサーバの前記認証情報依頼手段からの前記依頼を前記利用者端末経由で受信する受信手段と、前記受信手段の前記依頼の受信に応じて前記認証サーバが停止しているか否かを判断する停止判断手段と、前記停止判断手段において前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知手段と、前記停止判断手段が停止していないと判断した場合には、前記受信手段が受信した前記依頼を前記認証サーバへ伝達する伝達手段とを具備し、前記認証サーバは、前記伝達手段により伝達された前記依頼に応じて前記認証情報を発行する認証情報発行手段と、前記認証情報発行手段が発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信手段とを具備し、前記アプリケーションサーバの前記認証情報依頼手段は、前記停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求し、前記認証手段は、前記情報の要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行うことを特徴とする。

また、本発明による認証方法においては、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システムを利用した認証方法であって、前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信ステップと、前記受信ステップでサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼ステップと、前記認証情報依頼ステップの依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う第１の認証ステップと、前記認証サーバシステムから認証サーバの停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求する要求ステップと、前記要求ステップの要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行う第２の認証ステップと、前記第１の認証ステップまたは前記第２の認証ステップにより認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップとを前記アプリケーションサーバにより行い、前記アプリケーションサーバの前記認証情報依頼ステップによる前記依頼を前記利用者端末経由で受信する受信ステップと、前記受信ステップでの前記依頼の受信に応じて認証サーバが停止しているか否かを判断する停止判断ステップと、前記停止判断ステップにおいて前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知ステップと、前記停止判断ステップで停止していないと判断した場合には、前記受信ステップで受信した前記依頼を前記認証サーバへ伝達する伝達ステップと、前記伝達ステップにより伝達された前記依頼に応じて前記認証情報を発行する認証情報発行ステップと、前記認証情報発行ステップで発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信ステップとを前記認証サーバシステムにより行うことを特徴とする。

また、本発明によるプログラムは、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システム用のプログラムであって、前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信ステップと、前記受信ステップでサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼ステップと、前記認証情報依頼ステップの依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う第１の認証ステップと、前記認証サーバシステムから認証サーバの停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求する要求ステップと、前記要求ステップの要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行う第２の認証ステップと、前記第１の認証ステップまたは前記第２の認証ステップにより認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップとを前記アプリケーションサーバにより行い、前記アプリケーションサーバの前記認証情報依頼ステップによる前記依頼を前記利用者端末経由で受信する受信ステップと、前記受信ステップでの前記依頼の受信に応じて認証サーバが停止しているか否かを判断する停止判断ステップと、前記停止判断ステップにおいて前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知ステップと、前記停止判断ステップで停止していないと判断した場合には、前記受信ステップで受信した前記依頼を前記認証サーバへ伝達する伝達ステップと、前記伝達ステップにより伝達された前記依頼に応じて前記認証情報を発行する認証情報発行ステップと、前記認証情報発行ステップで発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信ステップとを前記認証サーバシステムにより行うことをコンピュータに実行させるためのプログラムである。

本発明による認証システム及び認証方法は、シングルサインオンの環境を実現する認証サーバが機能しなくなった場合でも、各アプリケーションサーバにおいて利用者の認証処理を可能とすることができる。

以下添付図面を参照して本発明の好適な実施形態について詳細に説明する。
まず、本発明の一実施形態である認証サーバシステムを含む認証システムの概略構成について説明する。本実施形態における認証システムは、認証サーバシステム自体に各アプリケーションに応じたユーザ情報を持たず、認証サーバシステムが各アプリケーションサーバにユーザ情報を問い合わせることで認証を行なうという分散系の認証システムである。ここで、アプリケーションサーバは、ネットワークを介して利用者端末（クライアントコンピュータ）にアプリケーションサービスを提供するサーバである。図１は、本発明の一実施形態である認証サーバシステムを含む認証システムの構成を模式的に示す図である。

図１において、１００は、インターネットであり、種々のサービスが提供されている通信ネットワークである。インターネット１００上では、インターネットサービスプロバイダ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ， ＩＳＰ）などの接続手段を用いて世界規模でコンピュータが接続される。各コンピュータはＴＣＰ／ＩＰなどの接続プロトコルで通信可能であり、特にＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いたＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスも利用可能である。

図１は、インターネット１００上に接続されたクライアントコンピュータ１０１と、利用者がクライアントコンピュータ１０１を用いて利用できる複数のアプリケーションサーバ１０２、１０４が接続されている。また、認証システムの必要構成要素として、認証サーバシステム１０６がインターネット１００に接続されている。

ここで、認証サーバシステム１０６は、アプリケーションサーバ１０２、１０４が提供するアプリケーションサービスを利用する利用者の認証処理を行う。すなわち、ネットワーク１００を介して接続されたアプリケーションサーバ１０２、１０４と、認証サーバシステム１０６により本実施形態における認証システムが構築されている。また、アプリケーションサーバ１０２、１０４には、各々ユーザ情報データベースＡ・１０３、ユーザ情報データベースＢ・１０５が接続されている。ユーザ情報データベースＡ・１０３及びユーザ情報データベースＢ・１０５は、利用者に固有のユーザＩＤと、ユーザＩＤに関連付けられたパスワードなどの情報を格納する。

また、利用者がアプリケーションサービスを利用するには、クライアントコンピュータ１０１よりブラウザにて「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｉｃｅＡ．ｃｏｍ／」のＵＲＬを指定することでアプリケーションサーバ１０２にアクセスしてアプリケーションサービスＡを利用することができる。同様に、クライアントコンピュータ１０１よりブラウザにて「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｉｃｅＢ．ｃｏｍ／」のＵＲＬを指定することでアプリケーションサーバ１０４にアクセスしてアプリケーションサービスＢを利用することができる。但し、利用者が上述したアプリケーションサービスＡ、Ｂを利用するには、認証システムにより認証される必要がある。

次に、図１に示した認証システムにおける機能構成について説明する。
図２は、図１に示した認証システムの機能構成を示す図である。クライアントコンピュータ１０１は、ユーザエージェント２１１を備える。ユーザエージェント２１１としてはＮｅｔｓｃａｐｅ（登録商標）、Ｍｏｚｉｌｌａ（登録商標）など一般的に入手可能なブラウザを利用することができる。ユーザエージェント２１１は、利用者が利用を所望するアプリケーションサーバ１０２にＨＴＴＰを主としたプロトコルで接続を行う。この際、利用者を識別するために、あるいは利用者の接続の可否を判断するために認証と呼ばれる処理を行う。矢印２６、２７に示すように、ユーザエージェント２１１は、アプリケーションサーバ１０２、あるいは認証サーバシステム１０６と通信を行い、アプリケーションサーバ１０２、あるいは認証サーバシステム１０６のいずれかによって認証を受ける。

尚、本実施形態におけるアプリケーションサーバ１０２は、インターネットドメイン「ｓｅｒｖｉｃｅＡ．ｃｏｍ」に属し、認証サーバシステム１０６はアプリケーションサーバ１０２とは異なるインターネットドメイン「ａｕｔｈＳｅｒｖｉｃｅ．ｃｏｍ」に属しているものとする。

アプリケーションサーバ１０２は、Ｗｅｂサーバ部２２１、利用者の認証を行う認証エージェント２２２、Ｗｅｂアプリケーション部２２３から構成される。ユーザエージェント２１１から発せられたＨＴＴＰ要求は、Ｗｅｂサーバ部２２１によって受信、解析され、認証エージェント２２２における認証処理を通過できた場合（認証された場合）、Ｗｅｂアプリケーション部２２３に転送される。さらに認証エージェント部２２２はユーザ認証部２２２ａおよび認証中継処理部２２２ｂによって構成される。

ユーザ認証部２２２ａは、主に利用者が入力したユーザＩＤとパスワードをユーザ情報データベースＡ・１０３に問い合わせを行うことでユーザ認証する機能を有する。認証中継処理部２２２ｂは、認証サーバシステム１０６からの認証中継要求を受信し、同じ認証エージェント部２２２内のユーザ認証部２２２ａの提供する機能を用いて認証を行う。

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

図９は、ユーザ情報データベースＡ・１０３の構成例を示す図である。図９に示すように、ユーザ情報データベースＡ・１０３は、アプリケーションサービスＡを利用する利用者のユーザＩＤ（９０１）及び、そのユーザＩＤの認証に必要なパスワード（９０２）をはじめとした、利用者に固有の情報を格納する。具体的には、ユーザ情報データベースＡ・１０３は、例えばリレーショナルデータベース管理サーバによる管理の基で実現され、アプリケーションサーバ１０２からリレーショナルデータベース管理サーバに対してＳＱＬなどの問い合わせ言語を発行することによって、所望のユーザＩＤを持つ利用者のユーザ情報を取得・変更・削除することができる。

また本実施形態の特徴の一つは、認証エージェント２２２において、認証のために二つのインターフェースを持つことである。先に説明した、ユーザエージェント２１１からの認証情報を受け取るユーザ認証部２２２ａはそのうちの一つである。他方のインターフェースは、認証中継処理部２２２ｂによって実現される。認証中継処理部２２２ｂは、後述する認証サーバシステム１０６からの認証中継要求を受信し、同じ認証エージェント２２２内のユーザ認証部２２２ａの提供する機能を用いて認証を行なう。本実施形態では、認証中継処理部２２２ｂは、一般の利用者からは利用されることなく、認証サーバシステム１０６からの要求のみを受け付ける。また、認証中継処理部２２２ｂと認証サーバシステム１０６間の通信（矢印２８）は、例えば、例えばＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）が定めるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）１．１によるＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）に応じた通信を行う。

また、本実施形態の認証エージェント２２２は、後述する認証サーバシステム１０６内の認証サーバ３１０の稼動状態によって認証モードを、ユーザ認証部２２２ａを用いて自分自身で認証を行うローカル認証モードまたは、認証サーバ３１０と認証中継処理部２２２ｂを用いて認証を行うリモート認証モードのいずれかに設定し、その設定モードに関する情報を、認証モード記憶部２２２ｃに記憶する。

次に、図１、２に示した認証サーバシステム１０６の内部構成について説明する。図３は、図１、２に示した認証サーバシステム１０６の内部構成例を示す図である。図３に示すように認証サーバシステム１０６は、仮想ＩＰ提供装置３０１、認証サーバ３１０、代替サーバ（通知サーバ）３２０から構成される。

仮想ＩＰ提供装置３０１は、認証サーバ３１０および代替サーバ３２０の前段に位置し、ユーザエージェント２１１および認証エージェント２２２から送信された認証サーバシステム１０６に対する処理要求は全て仮想ＩＰ提供装置３０１によって受信される。すなわち、図３には示していないが仮想ＩＰ提供装置３０１は、インターネット１００に接続されている。仮想ＩＰ提供装置３０１は、認証サーバ３１０の稼動状態を監視しており、認証サーバ３１０が稼動状態にある場合は、受け取った要求を認証サーバ３１０へ転送し、認証サーバ３１０が停止状態にある場合は受け取った要求を代替サーバ３２０へ転送する機能を持つ。

認証サーバ３１０は、Ｗｅｂサーバ部３１１、ユーザ認証部３１３、認証中継要求部３１２から構成される。ユーザエージェント２１１からの認証要求は、Ｗｅｂサーバ部３１１によって、受信、解析されユーザ認証部３１３に転送される。本実施形態の特徴の一つは、認証サーバ３１０にユーザ情報のデータベースを持たないことであるため、認証サーバ３１０は、対象アプリケーションの認証エージェント（例えばアプリケーションサーバ１０２の認証エージェント２２２）に認証を依頼する。また、本実施形態の認証サーバ３１０において、ユーザ認証部３１３は、ユーザの認証を、認証中継要求部３１２に依頼し、さらに認証中継要求部３１２は、前述したＳＯＡＰによるＲＰＣに応じた通信（図２の矢印２８）により、認証エージェント２２２内の認証中継処理部２２２ｂに認証要求を行なう。

代替サーバ３２０は、Ｗｅｂサーバ部３２１および認証サーバ停止通知部３２２から構成される。ユーザエージェント２１１および認証エージェント２２２からの処理要求は、Ｗｅｂサーバ部３２１によって受信、解析され認証サーバ停止通知部３２２へ転送される。認証サーバ停止通知部３２２は、要求が認証エージェント２２２からのものであった場合は認証サーバ３１０が停止している旨を通知し、要求がユーザエージェント２１１からのものであった場合は認証サーバ３１０が停止している旨を表す識別子を付加し、アプリケーションサーバ１０２へ処理要求をリダイレクト（ＨＴＴＰリダイレクト）する機能を持つ。この認証サーバ３１０が停止している旨を表す識別子は、例えばＵＲＬのパラメータとして付与される。また、認証サーバ３１０が停止している旨を表す識別子は、ＨＴＴＰのエラーコードであってもよい。

このように、認証サーバ３１０が停止時にのみ要求を受け付け、認証サーバ３１０が停止している旨をアプリケーションサーバ１０２に通知する代替サーバ３２０を認証サーバシステム１０６内に有することで、認証サーバ３１０を利用したシングルサインオンを利用しながら、認証サーバ３１０が稼動できない場合には、アプリケーション１０２に認証処理を依頼する認証システムを構築することができる。また、上述したように認証エージェント２２２と認証サーバ３１０に用意された計２系統の認証経路を用意することにより、認証サーバ３１０を利用したＳＳＯを実現しつつも、アプリケーションサーバ１０２単独の認証に自動的に切り替えることが可能となり、アプリケーションサーバ１０２が提供するアプリケーションの利用率を高めることができる。尚、代替サーバ３２０は、予め登録された複数のアプリケーションサーバに対して認証サーバ３１０が停止している旨を通知する機能を更に備えてもよい。また、認証サーバ３１０は、停止した状態から稼動状態へ移行した際に、稼動状態であることを通知する稼動情報を、予め登録した複数のアプリケーションサーバへ通知する機能を備えてもよい。

尚、図２に示すアプリケーションサーバ１０２は、図１に示した複数台のアプリケーションサーバ１０２、１０４のうち、任意の一台を便宜上示している。また、認証システムに含まれるアプリケーションサーバは、図１では２台であったが、これに限定されるものではなく、認証システムが任意の数のアプリケーションサーバを含む構成であってもよい。

次に、本実施形態における認証システムにおける利用者の認証処理について図４〜図７及び図１０を用いて説明する。
まず、本実施形態の認証システムにおけるログインページを表示するか否かを判断する処理について説明する。図１０は、本実施形態におけるログインページを表示するか否かを判断する処理を示す図である。まず、ステップ１００１において、利用者が例えばブラウザを操作することにより、クライアントコンピュータ１０１上にインストールされたユーザエージェント２１１が、アプリケーションサーバ１０２に接続要求を送信する。この利用者によるブラウザの操作とは、例えばアプリケーションサーバ１０２がサービスを提供するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をブラウザ（ユーザエージェント２１１）に対して入力する操作である。ユーザエージェント２１１よって発信された接続要求は、アプリケーションサーバ１０２内にインストールされたＷｅｂサーバ２１１によって受信され、認証エージェント２２２内のユーザ認証部２２２ａに転送される。

ユーザ認証処理部２２２ａでは、まずユーザエージェント２１１に対して認証情報の入力を要求する必要があるか否かを判断する。ユーザエージェント２１１に対して認証情報の要求が必要である場合、認証エージェント２２２は、例えば図１２−１のようなＨＴＭＬ記述データ１２００を送信することでクライアントコンピュータ１０１の画面に図１２−２に示すログインページ（ログインページ）１２１０を表示し、利用者に予め利用者登録時に決定したユーザＩＤとパスワードを入力するよう促す。すなわち、アプリケーションサーバ１０２は、必要に応じてユーザエージェント２１１に対してログインページ１２１０を提示するＨＴＭＬ記述データ１２００を送信する。

ユーザエージェント２１１は、受け取ったＨＴＭＬ記述データ１２００を基にログインページ１２１０を表示し、利用者に入力を促す。利用者は、記憶しているユーザＩＤとパスワードを入力し、ログインページ１２１０上に表示されている転送ボタン（図１２−２の「Ｓｕｂｍｉｔ」ボタン）を押すことで、アプリケーションサーバ１０２へのログインを試みる。アプリケーションサーバ１０２は、ログインページ１２１０に対して利用者が入力したユーザＩＤとパスワードの組を、図９に示したユーザ情報データベースＡ・１０３に格納されているユーザＩＤ（９０１）、パスワード（９０２）の組と照合することで、認証を行なう。

次に、ステップ１００２において、ユーザエージェント２１１からの要求がログインページへの要求である場合は、認証エージェント２２２は、明示的なログイン要求を意味するため、条件によらずログインページを生成する（ステップ１００３）。具体的には、認証エージェント２２２は、図１２−１に示したようなＨＴＭＬ記述データ１２００を生成する。

また、ステップ１００２において、明示的なログイン要求でない場合、認証エージェント２２２のユーザ認証部２２２ａは、利用者が既に認証済みであるか否かの判断、即ち、ログインページ１２１０を表示せずにアプリケーションを利用させて良いか否かの判断を、有効なセッションが存在するか否かで判断する（ステップ１００４）。本実施形態においては、ユーザ認証部２２２ａは、有効なセッションの存在確認処理としてＣｏｏｋｉｅ（クッキー）と呼ばれる情報を利用することで実現する。

Ｃｏｏｋｉｅは、Ｗｅｂサーバ２２１とユーザエージェント２１１の間で、前回の接続状態を持続的に保持するための情報として広く用いられているものである。本実施形態では、セッションを識別する識別子をセッションＣｏｏｋｉｅとして保持する。セッションＣｏｏｋｉｅとして保持される識別子は、アプリケーションサーバ１０２とユーザエージェント２１１間に確立したセッションに対して一対一に生成されるセッションオブジェクトを一意に識別できる識別子であり、利用者が認証された際にセッションオブジェクトに認証済みであるという情報を付加することによって、それ以降の処理要求の際に有効なセッションの確認により認証済みであるか否かも確認することができる。セッションＣｏｏｋｉｅはユーザエージェント２１１が起動して初めてアプリケーションサーバ１０２にアクセスした応答に対して発行される。一般にＷｅｂアプリケーションでは利用者に対してログアウトボタンを設けており、利用者がこのログアウトボタンを押すことで、セッションを終了することができ、アプリケーションサーバ１０２上のセッションオブジェクトも破棄される。

次に、ステップ１００４において有効なセッション識別子が確認された場合、すでに認証済みの利用者として判断することで認証エージェント２２２の処理を終了し、Ｗｅｂアプリケーション部２２３へ処理要求を転送する（ステップ１００５）。

また、ステップ１００４において有効なセッション識別子が確認されない場合、認証エージェント２２２は、現在の認証モードがローカル認証モードであるか、リモート認証モードであるかを確認する（ステップ１００６）。認証モードは前述の通り、認証サーバ３１０の稼動状態によって変化し、認証エージェント２２２の認証モード記憶部２２２ｃによって記憶されている。このステップ１００６において認証モードがローカル認証モードであると確認された場合は、認証エージェント２２２はログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００を生成してユーザエージェント２１１に対して送信する（ステップ１００３）。

一方、ステップ１００６において認証モードがリモート認証モードであると確認された場合は、認証エージェント２２２は認証サーバ３１０に対してユーザがログインしているか否かを判断するためにリモート認証確認処理に移る（ステップ１００７）。すでに認証サーバ３１０に対してログインが成立していれば、アプリケーションサーバ１０２に対してもログインを認めることでＳＳＯを実現することができる。

次に、図１０のステップ１００７におけるリモート認証確認処理について図４を用いて説明する。図４は、図１０のステップ１００７におけるリモート認証確認処理の詳細を示す図である。

まず、認証エージェント２２２はユーザエージェント２１１から受け取った要求に認証サーバ３１０の停止を表す識別子が含まれるか否かを確認する（ステップ４０１）。この識別子は、前述の代替サーバ３２０によって処理要求に付加されるものであり、認証サーバ３１０の稼動中はこの識別子が処理要求に含まれることはないため、処理要求に認証サーバ３１０の停止を表す識別子が含まれる場合は、認証モード記憶部２２２ｃの認証モードをローカル認証モードに変更し（ステップ４０２）、ログインページ生成処理に進む（ステップ４２０）。

一方、ステップ４０１において受け取った要求に認証サーバ３１０の停止を表す識別子が含まれない場合は、認証エージェント２２２は、受け取った要求に後述するＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ） Ａｒｔｉｆａｃｔが含まれているか否かを確認し（ステップ４０３）、要求にＳＡＭＬ Ａｒｔｉｆａｃｔも含まれていない場合は、ユーザエージェント２１１が既に認証サーバ３１０で認証されているか否かを確認する認証確認要求を発行する（ステップ４０５）。この認証確認要求は、認証サーバシステム１０６に対するリダイレクト要求をユーザエージェント２１１に発行することで実現される。

ステップ４０５の処理による認証サーバシステム１０６に対する処理要求は、前述の通り、仮想ＩＰ提供装置３０１によって受信される。処理要求を受信した仮想ＩＰ提供装置３０１は、認証サーバ３１０が稼動中であるか否かを確認し（ステップ４０９）、認証サーバ３１０が稼動中であった場合は処理要求を認証サーバ３１０へ転送することでステップ４１１へ移行し、認証サーバ３１０が停止中であると確認された場合は処理要求を代替サーバ３２０へ転送することでステップ４１７へ移行する。

ステップ４０９において認証確認要求が代替サーバ３２０へ転送された場合は、要求はＷｅｂサーバ部３２１で受信、解析され、認証サーバ停止通知部３２２に転送される。これにより認証サーバ停止通知部３２２は、認証サーバ３１０の停止を表す識別子を処理要求に付加してユーザエージェント２１１をアプリケーションサーバ１０２へリダイレクトして処理を終了する（ステップ４１７）。ここで付加された識別子は前述の通り、ステップ４０１において認証エージェント２２２によって確認される。

ステップ４０９において認証確認要求が認証サーバ３１０へ転送された場合は、要求はＷｅｂサーバ部３１１によって受信、解析され、ユーザ認証処理部３１３へ転送される。これによりユーザ認証処理部３１３は、処理要求を受け取ると、認証サーバ３１０とユーザエージェント２１１の間で既に有効なセッションが確立しているか否かを判断する（ステップ４１１）。

セッションの確認は、アプリケーションサーバ１０２とユーザエージェント２１１間でのセッションと同じくセッションＣｏｏｋｉｅによって確認されるが、本実施形態では、認証サーバ３１０は、アプリケーションサーバ１０２とは異なるインターネットドメインに属するサーバとして構成されているため、アプリケーションサーバ１０２に対するセッションとは本質的に異なるセッションとして認識される。有効なセッションが確立している場合は、すでに認証サーバ３１０にログイン済みであると判断される。セッションの確立が確認できない場合は、認証サーバ３１０に対するログインが行なわれていない状況と判断し、後述するログイン処理に移る（ステップ４１３）。

認証サーバ３１０上で有効なセッションが確立された場合、アプリケーションサーバ１０２に対してログイン済みのユーザ名を一意に通知することが必要である。このための技術としては、標準化団体であるＯＡＳＩＳ（Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ）が策定しているＳＡＭＬを採用することが望ましい。ＯＡＳＩＳが発行する標準仕様書Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＳＡＭＬ） Ｖ１．１、およびＢｉｎｄｉｎｇｓ ａｎｄ Ｐｒｏｆｉｌｅｓ ｆｏｒ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＳＡＭＬ） Ｖ１．１で詳細に述べられているので本実施形態では詳細に述べないが、認証サーバ３１０が認証した利用者の認証情報をアプリケーションサーバ１０２に対して通知する技術として利用することができる（ＳＡＭＬ Ａｒｔｉｆａｃｔ／Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅ）。

以下、本実施形態に適用される、ＳＡＭＬ Ａｒｔｉｆａｃｔ／Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅについて図８を用いて簡単に説明する。図８は、本実施形態の認証システムにおいてＳＡＭＬを利用した認証処理例を示す図である。ＳＡＭＬ Ａｒｔｉｆａｃｔ／Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅでは、認証サーバ３１０は、利用者の認証に成功すると、ＳＡＭＬ ＳＳＯ Ａｓｓｅｒｔｉｏｎ（以下、Ａｓｓｅｒｔｉｏｎとする）と呼ばれるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述された認証情報を生成する。好適な例としてはＳＡＭＬ ＳＳＯ Ａｓｓｅｒｔｉｏｎは、アプリケーションサーバ１０２上での利用者のユーザＩＤを含む。

また、認証サーバ３１０はＡｓｓｅｒｔｉｏｎ（認証情報）を生成するのと同時に、ＳＡＭＬ Ａｒｔｉｆａｃｔと呼ばれるＡｓｓｅｒｔｉｏｎと一対一に対応する短ストリングの識別子を発行する。発行されたＳＡＭＬ Ａｒｔｉｆａｃｔは、アプリケーションサーバ１０２の認証エージェント２２２にリダイレクトによって通知される（ステップ５、６）。リダイレクトによる接続要求を受け取ったアプリケーションサーバ１０２は接続要求に含まれているＳＡＭＬ Ａｒｔｉｆａｃｔを取り出し、ＳＡＭＬで定められるＳＯＡＰ上に実現されたプロトコルにより、Ａｓｓｅｒｔｉｏｎを要求する（ステップ７）。このとき、Ａｓｓｅｒｔｉｏｎ要求は、受け取ったＳＡＭＬ Ａｒｔｉｆａｃｔを引数として発行される。ＳＯＡＰエンジンを介してＡｓｓｅｒｔｉｏｎ要求を受け取った認証サーバ３１０は、Ａｓｓｅｒｔｉｏｎ要求に含まれるＳＡＭＬ Ａｒｔｉｆａｃｔと一意に対応するＡｓｓｅｒｔｉｏｎを検索する。該当するＡｓｓｅｒｔｉｏｎが見つかった場合、認証サーバ３１０は、アプリケーションサーバ１０２に対して、先のＡｓｓｅｒｔｉｏｎ要求の返答として、見つかったＡｓｓｅｒｔｉｏｎ（認証情報）を送信する（ステップ８）。アプリケーションサーバ１０２は、Ａｓｓｅｒｔｉｏｎを解析することによって、ユーザエージェント２１１を利用する利用者のアプリケーションサーバ１０２上でのユーザＩＤを知ることができる。

ここで、図４の処理の説明に戻り、ステップ４１１において、有効なセッションＩＤが確認された場合は、ユーザ認証部３１３はＳＡＭＬ Ａｒｔｉｆａｃｔを付加してユーザエージェント２１１をアプリケーションサーバ１０２へリダイレクトする（ステップ４１２）。ここで付加されたＳＡＭＬ Ａｒｔｉｆａｃｔは、ステップ４０３において確認される。尚、このステップ４１２の処理は、図８のステップ５、６の処理に対応する。

ステップ４０３において処理要求にＳＡＭＬ Ａｒｔｉｆａｃｔが含まれていた場合、認証エージェント２２２は認証サーバシステム１０６に対してＡｓｓｅｒｔｉｏｎ（認証情報）を要求する（ステップ４０４）。尚、このステップ４０４の処理は、図８のステップ７の処理に対応する。

Ａｓｓｅｒｔｉｏｎ要求は認証確認要求と同様に、仮想ＩＰ提供装置３０１によって受信され、認証サーバ３１０が稼動中の場合は認証サーバ３１０へ、認証サーバ３１０が停止中の場合は代替サーバ３２０へ転送される（ステップ４１０）。ここで、Ａｓｓｅｒｔｉｏｎ要求が代替サーバ３２０へ転送された場合、ステップ４１８へ移行し、代替サーバ３２０は認証サーバ３１０の停止を認証エージェント２２２に対して通知する。これにより、ステップ４１９において、認証サーバ３１０が停止している旨の通知を受け取った認証エージェント２２２は、認証モード記憶部２２２ｃに記憶されている認証モードをローカル認証モードに変更する。次に、認証エージェント２２２は、ステップ４２０に進み、ログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００を生成し、ユーザエージェント２１１に対して送信する。

一方、ステップ４１０で認証サーバ３１０が稼動中と判断され、Ａｓｓｅｒｔｉｏｎ要求が認証サーバ３１０へ転送された場合は、認証サーバ３１０は、前述のＳＡＭＬ Ａｒｔｉｆａｃｔ／Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅの通り、ユーザ認証部３１３において受け取ったＳＡＭＬ Ａｒｔｉｆａｃｔに対応するＡｓｓｅｒｔｉｏｎを検索する（ステップ４１４）。ここで、対応するＡｓｓｅｒｔｉｏｎが存在した場合は、ステップ４１５に進み、認証サーバ３１０は、Ａｓｓｅｒｔｉｏｎを認証エージェント２２２に返信する。尚、このステップ４１５の処理は、図８のステップ８の処理に対応する。

また、ステップ４１４で対応するＡｓｓｅｒｔｉｏｎが存在しない場合は、ステップ４１６に進み、認証サーバ３１０は、ユーザエージェント２１１が認証サーバ３１０でも未認証な状態である旨を認証エージェント２２２へ通知する。これにより、ステップ４２０において、認証エージェント２２２は、ユーザエージェント２１１に対してログインページ１２１０を送信する。

ステップ４１５の処理によりＡｓｓｅｒｔｉｏｎを受け取った認証エージェント２２２は、Ａｓｓｅｒｔｉｏｎを解析し（ステップ４０７）、ユーザＩＤを取得する。認証エージェント２２２は取得したユーザＩＤを持つ利用者としてユーザエージェント２１１を認証し、Ｗｅｂアプリケーション部２２３へ処理要求を転送する（ステップ４０８）。尚、アプリケーションサーバ１０２とユーザエージェント２１１の間のセッションは、この段階から有効なものとして識別される。図４のフローで示されるリモート認証確認処理でユーザエージェント２１１が認証されなかった場合、認証エージェント２２２はログイン処理に移る。

ログイン処理においては、ユーザエージェント２１１に対して、ログインページ１２１０のように、ユーザＩＤおよびパスワードの入力を行うための画面を提供する。本実施形態では図１２−１の符号１２０１に示したように＜ＦＯＲＭ＞タグを内包するＨＴＭＬ記述データ１２００を利用する。ログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００は図７のフローに従って生成される。図７は、ログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００を生成する処理を示す図である。

図７に示すように、まず、ステップ７０１において、認証エージェント２２２は、ログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００を生成する処理（以下、単に「ログインページ１２１０を生成する処理」とする）を開始する。次に、ステップ７０２において、認証エージェント２２２は、認証モードがリモート認証モードであるか否かを判断する。

本実施形態においては、認証サーバ３１０の稼動状態によって変化する認証モードによって、認証サーバ３１０を用いたリモート認証および認証エージェント２２２を用いたローカル認証を使い分ける。このため、ステップ７０２において、リモート認証と判断した場合には、認証エージェント２２２は、ＨＴＭＬ記述データ１２００に示すように＜ＦＯＲＭ＞タグにおけるＡＣＴＩＯＮ属性に、認証サーバ３１０上に実装されたユーザ認証部３１３のＵＲＬを埋め込む（ステップ７０３）。また、ローカル認証と判断した場合には、認証エージェント２２２は、ＨＴＭＬ記述データの＜ＦＯＲＭ＞タグにおけるＡＣＴＩＯＮ属性に、アプリケーションサーバ１０２上に実装された認証処理ＵＲＬ（ユーザ認証部２２２ａのＵＲＬ）を埋め込む（ステップ７０４）。ステップ７０３または７０４の次に、ステップ７０５において、認証エージェント２２２は、リモート認証またはローカル認証に応じた認証情報の送付先を指定したＨＴＭＬ記述データ１２００が生成し、ユーザエージェント２１１へ送信する。

ユーザエージェント２１１は、アプリケーションサーバ１０２から受信したＨＴＭＬ記述データを解析し、ユーザエージェント２１１上にログインページを表示し、利用者に対してユーザＩＤとパスワードの入力を促す。ユーザエージェント２１１の利用者は、予めアプリケーションサーバ１０２に登録されているユーザＩＤとそれに対応するパスワードを入力する。入力されたユーザＩＤおよびパスワードの確認処理、すなわちログイン認証は、ローカル認証モードであるか、リモート認証モードであるかにより処理が異なる。本実施形態におけるリモート認証時のログイン認証フローを図５に示し、ローカル認証時のログイン認証フローを図６に示す。

尚、リモートログイン処理時に用いられるログインページ１２１０には、ユーザエージェント２１１には表示されないＨＩＤＤＥＮ属性として、図１２−１の符号１２０２に示すようにサービスを識別するための識別子（ＳｅｒｖｉｃｅＩＤ）が埋め込まれる。ＳｅｒｖｉｃｅＩＤは予め認証サーバシステム１０６の管理者によって、認証サーバシステム１０６に接続されるアプリケーションサーバ１０２に対して一意に割り当てられた識別子である。本実施形態では、アプリケーションサーバ１０２に組み込まれる認証エージェント２２２はサービスを識別するための識別子として、該当するＳｅｒｖｉｃｅＩＤをログインページに埋め込むように構成されている。

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

ここで、認証モードがリモート認証時のログイン認証処理について説明する。図５は、認証モードがリモート認証時のログイン認証フローを示す図である。図５に示すように、利用者によって入力されたユーザＩＤおよびパスワードは、画面上の送信ボタンを押下することにより、＜ＦＯＲＭ＞タグのＡＣＴＩＯＮ属性に記述されたＵＲＬへ送信される（ステップ５０１）。ステップ７０３で示したように、リモート認証モードでは、ＡＣＴＩＯＮ属性に記述されているＵＲＬは認証サーバ３１０上のユーザ認証処理部３１３であるため、ユーザＩＤおよびパスワードは、認証サーバシステム１０６へ送信される。

前述の通り、認証サーバシステム１０６に対する処理要求は仮想ＩＰ提供装置３０１が受信し、認証サーバ３１０が稼動中である場合は認証サーバ３１０へ処理要求を転送し、認証サーバ３１０が停止中である場合は代替サーバ３２０へ処理要求を転送する（ステップ５０２）。ここで、要求が代替サーバ３２０へ転送された場合、代替サーバ３２０は、認証サーバ停止通知部３２２において認証サーバ３１０の停止を表す識別子を付加し、ユーザエージェント２１１をアプリケーションサーバ１０２へリダイレクトする（ステップ５０７）。

また、ステップ５０２において要求が認証サーバ３１０へ転送された場合は、認証サーバ３１０上のユーザ認証処理部３１３は、ＨＩＤＤＥＮ属性として受け取ったサービス名から、ユーザ認証の依頼先を決定し、認証要求中継部３１２を用いて、認証エージェント２２２上に外部ユーザ認証ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として設けられた認証中継処理部２２２ｂに対して受け取ったユーザＩＤおよびパスワードの認証を依頼する（ステップ５０３）。尚、本実施形態においては、外部ユーザ認証ＡＰＩは、前述したＳＡＭＬによるユーザ認証処理例図８と同じく、ＳＯＡＰにより実装する。これにより、認証サーバ３１０の認証中継要求部３１２は、ユーザＩＤとパスワードを引数に、前記ＳｅｒｖｉｃｅＩＤを持つアプリケーションサーバ上の認証中継処理部２２２ｂに対して認証要求を送信する。

認証要求を受け取った認証エージェント２２２は、ユーザＩＤとパスワードが合致するデータがあるか否かを、アプリケーションサーバ１０２に接続されたユーザ情報データベースＡ・１０３から検索する（ステップ５０８）。外部ユーザ認証ＡＰＩの返り値は真偽値であり、ユーザＩＤとパスワードが一致する登録ユーザが検索された場合は、外部ユーザ認証ＡＰＩの呼び出しに対する応答として真が、そうでない場合は偽が返される。

ステップ５０９において、偽の返答を受け取った認証サーバ３１０は、再度ログイン要求を発行するために、ログイン処理に移る（ステップ５０６）。また、ステップ５０９において真の返答を受け取った認証サーバ３１０は、ユーザの認証が成功したと判断し、認証情報をあらわすＡｓｓｅｒｔｉｏｎを生成する（ステップ５０４）と同時に、ユーザエージェント２１１との間に有効なセッションを確立し、アプリケーションサーバ１０２に対して認証されたユーザＩＤを通知するために、前述した認証確認要求段階と同様のＳＡＭＬ ＡｒｔｉｆａｃｔとＡｓｓｅｒｔｉｏｎによる手続きが実行される（ステップ５０５）。

次に、認証モードがローカル認証時のログイン認証処理について説明する。図６は、認証モードがローカル認証時のログイン認証フローを示す図である。図６に示すように、ローカル認証の場合、ステップ７０４に示したように、ログインページ生成処理によってログインページに埋め込まれる＜ＦＯＲＭ＞タグのＡＣＴＩＯＮ属性は、アプリケーションサーバ１０２上に実装されたユーザ認証部２２２ａのＵＲＬとなる。利用者はローカル認証においてもリモート認証と同様に、ログインページにユーザＩＤおよびパスワードの入力を行う（ステップ６０１）が、ユーザＩＤおよびパスワードの送信先は、認証サーバシステム１０６ではなくアプリケーションサーバ１０２となる。

ユーザＩＤとパスワードを受信したユーザ認証部２２２ａは、ユーザＩＤとパスワードが合致することを、アプリケーションサーバ１０２に接続されたユーザ情報データベースＡ・１０３から検索する（ステップ６０２）。ユーザＩＤおよびパスワードが一致する登録ユーザが検索された場合は、利用者によるログインが成功したものとみなされ、ユーザエージェント２１１との間に確立したセッションを認証済み状態に設定し、Ｗｅｂアプリケーション部２２３に処理要求が転送される（ステップ６０５）。これにより、転送された処理要求は図１０のステップ１００４において有効なセッションとして識別されるため、ステップ１００５に移行して利用者が所望した処理が実行される。

以上に示したように、本実施形態では、アプリケーションサーバ１０２と認証サーバシステム１０６の組み合わせにより、ローカル認証、リモート認証の切り替えが自動的に行われるが、さらに前記のアプリケーションサーバ１０２とは別のドメインに属する第二のアプリケーションサーバを導入した認証システムであっても、第二のアプリケーションサーバ上において図４〜図７及び図１０に示した認証処理を行なうことによりＳＳＯに対応した認証システムを実現することができる。より具体的には、第一のアプリケーションサーバ（アプリケーションサーバ１０２）に対して、利用者の認証が完了している場合、認証サーバ３１０上には、利用者のセッション情報が生成されており、それに対応するセッションＣｏｏｋｉｅが利用者のユーザエージェント２１１に保存されている。この状態において、利用者が第二のアプリケーションサーバに接続要求を発した場合、図４のステップ４０５における認証確認要求において、ユーザエージェントから認証サーバ３１０に対して、事前に第一のアプリケーションサーバの認証時に生成したセッションＣｏｏｋｉｅが送信される。認証サーバ３１０は、セッションＣｏｏｋｉｅおよび対応するセッションオブジェクトを検証することにより、利用者が第一のアプリケーションサーバにログイン中であることを確認することができる。

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

以上に示したように、本実施形態の認証システムにおいては、認証サーバシステム１０６により、認証サーバ３１０の稼動確認および認証サーバ３１０が稼動停止した際の認証方法の切り替えを実現している。これにより、認証サーバ３１０を利用したシングルサインオンを利用しながら、認証サーバ３１０が稼動できない場合には各アプリケーションサーバに認証処理させる認証システムを構築することができる。また、本認証システムによれば、認証サーバ３１０の停止時にも、各アプリケーションサーバは独自に認証を継続することができるため、各サービスで定めたサービスレベルを維持することができる。更には、認証サーバ３１０の稼動停止を回避するためコストを削減できるので、認証サーバ３１０の構築を安価に行なうことができる。

尚、上述した実施形態において、
また、上述した実施形態におけるクライアントコンピュータ１０１、アプリケーションサーバ１０２、１０４、認証サーバシステム１０６内の仮想ＩＰ提供装置３０１、認証サーバ３１０及び代替サーバ３２０は、ＣＰＵ（中央演算装置）及びメモリを備えるハードウェア構成である。そして、例えばアプリケーションサーバ１０２の認証エージェント２２２の機能や、認証サーバ３１０の認証機能を実現する為のプログラムをメモリから読み出してＣＰＵが実行することによりその機能を実現させるものである。

尚、上述したプログラム処理により機能を実現する構成に限定さるものではなく、各処理の全部または一部の機能を専用のハードウェアにより実現してもよい。また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記録媒体、ＲＡＭ以外の揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。

また、アプリケーションサーバ１０２の認証エージェント２２２における各種処理を行う機能や、認証サーバシステム１０６の認証機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各処理を行っても良い。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。具体的には、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含む。

また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体およびプログラムプロダクトは、本発明の範疇に含まれる。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明の一実施形態である認証サーバシステムを含む認証システムの構成を模式的に示す図である。 図１に示した認証システムの機能構成を示す図である。 図１、２に示した認証サーバシステム１０６の内部構成例を示す図である。 図１０のステップ１００７におけるリモート認証確認処理の詳細を示す図である。 認証モードがリモート認証時のログイン認証フローを示す図である。 認証モードがローカル認証時のログイン認証フローを示す図である。 ログインページ１２１０を表示するためのＨＴＭＬ記述データ１２００を生成する処理を示す図である。 本実施形態の認証システムにおいてＳＡＭＬを利用した認証処理例を示す図である。 ユーザ情報データベースＡ・１０３の構成例を示す図である。 本実施形態におけるログインページを表示するか否かを判断する処理を示す図である。 本実施形態におけるサービス情報テーブル例を示す図である。 本実施形態におけるＨＴＭＬ記述データ例を示す図である。 本実施形態におけるログインページ例を示す図である。 本実施形態におけるユーザＩＤマッピングテーブル例を示す図である。

符号の説明

１００ インターネット
１０１ クライアントコンピュータ
１０２、１０４ アプリケーションサーバ
１０３ ユーザ情報データベースＡ
１０５ ユーザ情報データベースＢ
１０６ 認証サーバシステム
２１１ ユーザエージェント
２２１ Ｗｅｂサーバ部
２２２ 認証エージェント
２２２ａ ユーザ認証部
２２２ｂ 認証中継処理部
２２２ｃ 認証モード記憶部
２２３ Ｗｅｂアプリケーション部
３０１ 仮想ＩＰ提供装置
３１０ 認証サーバ
３１１ Ｗｅｂサーバ
３１２ 認証中継要求部
３１３ ユーザ認証処理部
３２０ 代替サーバ
３２１ Ｗｅｂサーバ
３２２ 認証サーバ停止通知部

Claims (9)

1. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システムであって、
   前記アプリケーションサーバは、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信手段と、
   前記受信手段がサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼手段と、
   前記認証情報依頼手段の依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う認証手段と、
   前記認証手段により認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供手段と
   を具備し、
   前記認証サーバシステムは、
   前記認証情報に関する処理を行う認証サーバと、
   前記アプリケーションサーバの前記認証情報依頼手段からの前記依頼を前記利用者端末経由で受信する受信手段と、
   前記受信手段の前記依頼の受信に応じて前記認証サーバが停止しているか否かを判断する停止判断手段と、
   前記停止判断手段において前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知手段と、
   前記停止判断手段が停止していないと判断した場合には、前記受信手段が受信した前記依頼を前記認証サーバへ伝達する伝達手段と
   を具備し、
   前記認証サーバは、
   前記伝達手段により伝達された前記依頼に応じて前記認証情報を発行する認証情報発行手段と、
   前記認証情報発行手段が発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信手段と
   を具備し、
   前記アプリケーションサーバの前記認証情報依頼手段は、前記停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求し、前記認証手段は、前記情報の要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行うこと
   を特徴とする認証システム。
2. 前記アプリケーションサーバは、前記認証サーバから受信した前記停止情報を保持する保持手段を更に具備し、
   前記アプリケーションサーバの前記認証情報依頼手段は、前記保持手段が前記停止情報を保持している場合には前記利用者端末へ認証に必要な情報を要求し、前記保持手段が前記停止情報を保持していない場合には前記利用者端末経由で前記認証サーバシステムに前記認証情報を発行するよう依頼すること
   を特徴とする請求項１に記載の認証システム。
3. 前記認証サーバシステムは、
   前記認証サーバシステムの前記受信手段、前記停止判断手段及び前記伝達手段を含む構成である停止判断装置と、
   前記認証サーバシステムの前記通知手段を含む構成である通知サーバとから構成され、
   前記停止判断装置は、前記停止判断手段において前記認証サーバが停止していると判断した場合には、前記受信手段が受信した前記依頼を前記通知サーバへ伝達し、
   前記通知サーバの通知手段は、伝達された前記依頼に前記停止情報を付与した情報を前記依頼の元となるアプリケーションサーバへ返信すること
   を特徴とする請求項１または２に記載の認証システム。
4. 前記通知手段が前記依頼に付与する前記停止情報は、返信先となるアプリケーションサーバを指定するＵＲＬのパラメータとして付与されることを特徴とする請求項３に記載の認証システム。
5. 前記通知手段が通知する前記停止情報は、自身が利用している通信プロトコルのエラーコードであることを特徴とする請求項１に記載の認証システム。
6. 前記通知手段は、予め登録された複数のアプリケーションサーバに対して前記停止情報を通知することを特徴とする請求項１または５に記載の認証システム。
7. 前記認証サーバは、停止した状態から稼動状態へ移行した際に、稼動状態であることを通知する稼動情報を予め登録した複数のアプリケーションサーバへ通知する稼動情報通知手段を更に具備することを特徴とする請求項１〜６のいずれか１項に記載の認証システム。
8. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システムを利用した認証方法であって、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信ステップと、
   前記受信ステップでサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼ステップと、
   前記認証情報依頼ステップの依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う第１の認証ステップと、
   前記認証サーバシステムから認証サーバの停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求する要求ステップと、
   前記要求ステップの要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行う第２の認証ステップと、
   前記第１の認証ステップまたは前記第２の認証ステップにより認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップと
   を前記アプリケーションサーバにより行い、
   前記アプリケーションサーバの前記認証情報依頼ステップによる前記依頼を前記利用者端末経由で受信する受信ステップと、
   前記受信ステップでの前記依頼の受信に応じて認証サーバが停止しているか否かを判断する停止判断ステップと、
   前記停止判断ステップにおいて前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知ステップと、
   前記停止判断ステップで停止していないと判断した場合には、前記受信ステップで受信した前記依頼を前記認証サーバへ伝達する伝達ステップと、
   前記伝達ステップにより伝達された前記依頼に応じて前記認証情報を発行する認証情報発行ステップと、
   前記認証情報発行ステップで発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信ステップと
   を前記認証サーバシステムにより行うこと
   を特徴とする認証方法。
9. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記サービスの利用を要求する前記利用者端末の利用者の認証を行う認証サーバシステムとを備える認証システム用のプログラムであって、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信ステップと、
   前記受信ステップでサービスの要求を受信した場合に、前記利用者端末経由で前記認証サーバシステムに利用者の認証を行うための認証情報を発行するよう依頼する認証情報依頼ステップと、
   前記認証情報依頼ステップの依頼に応じて前記認証サーバシステムから前記利用者端末経由で認証情報を得た場合に、前記認証情報を基に利用者の認証を行う第１の認証ステップと、
   前記認証サーバシステムから認証サーバの停止情報を受信した場合には前記利用者端末へ認証に必要な情報を要求する要求ステップと、
   前記要求ステップの要求に応じて前記利用者端末から得た前記認証に必要な情報を基に利用者の認証を行う第２の認証ステップと、
   前記第１の認証ステップまたは前記第２の認証ステップにより認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップと
   を前記アプリケーションサーバにより行い、
   前記アプリケーションサーバの前記認証情報依頼ステップによる前記依頼を前記利用者端末経由で受信する受信ステップと、
   前記受信ステップでの前記依頼の受信に応じて認証サーバが停止しているか否かを判断する停止判断ステップと、
   前記停止判断ステップにおいて前記認証サーバが停止していると判断した場合には、停止情報を前記依頼の元となるアプリケーションサーバへ通知する通知ステップと、
   前記停止判断ステップで停止していないと判断した場合には、前記受信ステップで受信した前記依頼を前記認証サーバへ伝達する伝達ステップと、
   前記伝達ステップにより伝達された前記依頼に応じて前記認証情報を発行する認証情報発行ステップと、
   前記認証情報発行ステップで発行した前記認証情報を前記依頼の元となる前記アプリケーションサーバへ前記利用者端末経由で送信する送信ステップと
   を前記認証サーバシステムにより行うこと
   をコンピュータに実行させるためのプログラム。

Images