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

Abstract

【課題】 本来シングルサインオンの環境を実現する認証サーバが機能しなくなった場合でも、複数のアプリケーションサーバ間でのシングルサインオンの環境を維持することができる認証システム及び認証方法を提供する。
【解決手段】 認証エージェント２２２は、複数のアプリケーションサーバにおいて共通で利用可能な主認証サーバ１０６を複数の認証サーバの中より選択する。認証エージェント２２２は、主認証サーバ１０６にユーザＩＤを含む認証情報の発行を依頼する。主認証サーバ１０６は、上記依頼に応じて利用者の要求するサービスに応じたユーザＩＤを含む認証情報を認証エージェント２２２へ発行する。認証エージェント２２２は、依頼に応じて認証サーバ１０６が発行したユーザＩＤを含む認証情報を基に、ユーザ情報データベースＡ・１０３を参照することで、ユーザＩＤで特定される利用者の認証を行う。
【選択図】 図２

Description

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

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

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

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

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

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

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

この発明は、上述した課題を解決すべくなされたもので、本発明による認証システムにおいては、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、複数のアプリケーションサーバに対して利用者端末を利用する利用者の認証情報を管理する複数の認証サーバとを備える認証システムであって、複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースと、サービスを利用する利用者を特定する複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、第１の利用者識別子及びサービスを特定するサービス識別子を格納する識別子データベースとを具備し、アプリケーションサーバは、複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを複数の認証サーバの中より選択する選択手段と、ネットワークを介して利用者端末からサービスの要求を受信する受信手段と、受信手段がサービスの要求を受信した場合に、選択手段で選択した認証サーバに第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼手段と、認証情報依頼手段の依頼に応じて認証サーバが発行した第１の利用者識別子を含む認証情報を得た場合に、認証情報に含まれる第１の利用者識別子を基に、利用者情報データベースを参照することで、第１の利用者識別子で特定される利用者の認証を行う認証手段と、認証手段により認証された利用者の利用者端末に要求に応じたサービスを提供するサービス提供手段とを具備し、認証サーバは、アプリケーションサーバから第１の利用者識別子を含む認証情報の発行の依頼を受信する受信手段と、受信手段が受信した依頼に応じて、識別子データベースを参照して、利用者の要求するサービスに応じた第１の利用者識別子を含む認証情報をアプリケーションサーバへ発行する発行手段とを具備することを特徴とする。

また、本発明による認証方法においては、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、複数のアプリケーションサーバに対して利用者端末を利用する利用者の認証情報を管理する複数の認証サーバと、複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースとを備える認証システムを利用した認証方法であって、複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを複数の認証サーバの中より選択する選択ステップと、ネットワークを介して利用者端末からサービスの要求を受信する受信ステップと、受信ステップでサービスの要求を受信した場合に、選択ステップで選択した認証サーバに第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼ステップと、認証情報依頼ステップの依頼に応じて認証サーバが発行した第１の利用者識別子を含む認証情報を得た場合に、認証情報に含まれる第１の利用者識別子を基に、利用者情報データベースを参照することで、第１の利用者識別子で特定される利用者の認証を行う認証ステップと、認証ステップで認証された利用者の利用者端末に要求に応じたサービスを提供するサービス提供ステップとをアプリケーションサーバにより行い、アプリケーションサーバから第１の利用者識別子を含む認証情報の発行の依頼を受信する受信ステップと、受信ステップで受信した依頼に応じて、サービスを利用する利用者を特定する複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、第１の利用者識別子及びサービスを特定するサービス識別子を格納する識別子データベースを参照して、利用者の要求するサービスに応じた第１の利用者識別子を含む認証情報をアプリケーションサーバへ発行する発行ステップとを認証サーバにより行うことを特徴とする。

また、本発明によるプログラムは、ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、複数のアプリケーションサーバに対して利用者端末を利用する利用者の認証情報を管理する複数の認証サーバと、複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースとを備える認証システム用のプログラムであって、複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを複数の認証サーバの中より選択する選択ステップと、ネットワークを介して利用者端末からサービスの要求を受信する第１の受信ステップと、第１の受信ステップでサービスの要求を受信した場合に、選択ステップで選択した認証サーバに第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼ステップと、認証情報依頼ステップの依頼に応じて認証サーバが発行した第１の利用者識別子を含む認証情報を得た場合に、認証情報に含まれる第１の利用者識別子を基に、利用者情報データベースを参照することで、第１の利用者識別子で特定される利用者の認証を行う認証ステップと、認証ステップで認証された利用者の利用者端末に要求に応じたサービスを提供するサービス提供ステップとアプリケーションサーバから第１の利用者識別子を含む認証情報の発行の依頼を受信する第２の受信ステップと、第２の受信ステップで受信した依頼に応じて、サービスを利用する利用者を特定する複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、第１の利用者識別子及びサービスを特定するサービス識別子を格納する識別子データベースを参照して、利用者の要求するサービスに応じた第１の利用者識別子を含む認証情報をアプリケーションサーバへ発行する発行ステップとをコンピュータに実行させるためのプログラムである。

本発明による認証システム及び認証方法は、複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを複数の認証サーバの中より選択することができるので、本来シングルサインオンの環境を実現する認証サーバが機能しなくなった場合でも、複数のアプリケーションサーバ間でのシングルサインオンの環境を維持することができる。

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

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

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

ここで、主認証サーバ１０６及び認証サーバ１０７は、Ｗｅｂアプリケーションサーバ１０２、１０４が提供するアプリケーションサービスを利用する利用者の認証処理を行う。すなわち、ネットワーク１００を介して接続されたＷｅｂアプリケーションサーバ１０２、１０４と、主認証サーバ１０６及び認証サーバ１０７により本実施形態における認証システムが構築されている。

また、主認証サーバ１０６には、ユーザ識別子データベースＡ・１０８が接続され、認証サーバ１０７には、ユーザ識別子データベースＢ・１０９が接続されている。このユーザ識別子データベースＡ・１０８、ユーザ識別子データベースＢ・１０９には、本実施形態の認証システムによって管理される複数アプリケーションサーバ（アプリケーションサーバ１０２、１０４など）を利用するユーザを一意に識別するための識別子を共有するためのデータベースである。

また、アプリケーションサーバ１０２、１０４には、各々ユーザ情報データベースＡ・１０３、ユーザ情報データベースＢ・１０５が接続されている。ユーザ情報データベースＡ・１０３及びユーザ情報データベースＢ・１０５は、利用者に固有のユーザＩＤと、ユーザＩＤに関連付けられたパスワードなどの情報を格納する。尚、本実施形態において主認証サーバ１０６と認証サーバ１０７とは同じようにＳＳＯ機能を実現することができ、複数の認証エージェントによって後述の方法によって選ばれた任意の一台の認証サーバを主認証サーバとする。

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

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

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

ユーザ認証部２２２ａは、主に利用者が入力したユーザＩＤとパスワードをユーザ情報データベースＡ・１０３にＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）などの問い合わせ言語で問い合わせを行うことでユーザ認証する機能を有する。認証中継処理部２２２ｂは、主認証サーバ１０６からの認証中継要求を受信し、同じ認証エージェント部２２２内のユーザ認証部２２２ａの提供する機能を用いて認証を行う。

尚、本実施形態の認証中継処理部２２２ｂは、クライアントコンピュータ１０１からは利用されることなく、主認証サーバ１０６からの要求のみを受け付ける。また、認証中継処理部２２２ｂと後述する主認証サーバ１０６の認証中継要求部２５２の通信を示す矢印２０３は、例えば、例えばＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）が定めるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）１．１によるＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）に応じた通信を行う。

主認証サーバ１０６は、Ｗｅｂサーバ部２５１、認証中継要求部２５２、ユーザ認証部２５３、ユーザ識別子情報管理部２５４から構成される。ユーザエージェント２１１からの認証要求は、Ｗｅｂサーバ部２５１によって、受信、解析されユーザ認証部２５３に転送される。主認証サーバ１０６は、認証対象となるアプリケーションサーバ１０２の認証エージェント２２２に認証を依頼する。具体的には、ユーザ認証部２５３が、ユーザの認証を、認証中継要求部２５２に依頼し、さらに認証中継要求部２５２が、矢印２０３に示す通信により認証エージェント２２２内の認証中継処理部２２２ｂに認証要求を行う。ここで、矢印２０３に示す通信は、上述したように、Ｗ３Ｃが定めるＳＯＡＰ１．１によるＲＰＣに応じた通信を行う。

また、ユーザ識別子情報管理部２５４は、ユーザ識別子データベースＡ・１０８に格納されるユーザ識別子に関する情報を管理する。また、主認証サーバ１０６のユーザ識別子情報管理部２５４及び認証サーバ１０７のユーザ識別子情報管理部２６４は、各々ユーザ識別子データベースＡ・１０８とユーザ識別子データベースＢ・１０９が接続されている。また、主認証サーバ１０６のユーザ識別子情報管理部２５４と認証サーバ１０７のユーザ識別子情報管理部２６４とは、通信路２０６により接続されている。この通信路２０６における通信プロトコルとして、上述したＳＯＡＰ１．１によるＲＰＣで実装されている。

以上の構成により、主認証サーバ１０６中のユーザ識別子データベースＡ・１０８内のユーザ識別情報に変更が生じた際は、主認証サーバ１０６のユーザ識別子情報管理部２５４が通信路２０６を介した通信によるＲＰＣを用いて認証サーバ１０７のユーザ識別子情報管理部２６４へ変更情報を通知する。これにより、通知を受けた該ユーザ識別子情報管理部２６４は、ユーザ識別子データベースＢ・１０９の情報更新処理を行う。以上の処理により、ユーザ識別子データベースＡ・１０８とユーザ識別子データベースＢ・１０９内のユーザ識別子情報は同一に保たれる。尚、本実施形態においては、各認証サーバにユーザ識別子データベースが接続されている構成であったが、これに限定されるものではなく、ユーザ識別子情報の共有のために主認証サーバ１０６および認証サーバ１０７の双方に一つのユーザ識別子データベースを接続する構成であってもよい。

認証サーバ１０７は、主認証サーバ１０６と同様の機能を持つが、主認証サーバ１０６の機能停止が認証エージェント２２２で確認されない限り認証サーバ１０７が認証要求を受けることは無い。

尚、主認証サーバ１０６と認証サーバ１０７は同じ機能を有し、図１に示すように本実施形態の認証システムにおける認証サーバは複数台あるが、図２においては、便宜上一台の認証サーバ１０７を示している。同様に、アプリケーションサーバ１０２は複数台の図１に示したアプリケーションサーバ１０２、１０４のうち、任意の一台としてアプリケーションサーバ１０２を示している。

次に、ユーザ識別子データベースＡ・１０８の構成例について説明する。図１０は、ユーザ識別子データベースＡ・１０８内のデータ構成例を示す図である。図１０において、ユーザ識別子データベースＡ・１０８は、ユーザを一意に識別するための識別子であるＳＳＯＩＤ（第２の利用者識別子）（１００１）と各サービス内でのユーザを表す識別子であるユーザＩＤ（第１の利用者識別子）（１００２）と各サービスを表す識別子であるサービスＩＤ（サービス識別子）（１００３）から構成されている。尚、サービスＩＤ（１００３）において、「サービスＡ」とは、図１に示したＷｅｂアプリケーションサーバ１０２が提供するアプリケーションサービスＡを示し、「サービスＢ」とは、Ｗｅｂアプリケーションサーバ１０４が提供するアプリケーションサービスＢを示す。

図１０に示すように、サービスＩＤ（１００３）＝「サービスＡ」のユーザＩＤ（１００２）＝「ｉｃｈｉｒｏ」と、サービスＩＤ（１００３）＝「サービスＢ」のユーザＩＤ（１００２）＝「ｙ−ｉｃｈｉｒｏ」とが、同一ユーザを表す識別子である場合に、同一ＳＳＯＩＤ（１００１）＝「ｓｓｏｉｄ０１」が与えられている。これにより、主認証サーバ１０６及び認証サーバ１０７において、ＳＳＯＩＤ（１００１）を管理することで、例えばＷｅｂアプリケーションサーバ１０２を利用する利用者を一意に識別することができる。尚、ユーザ識別子データベースＢ・１０９の構成も、図１０に示したユーザ識別子データベースＡ・１０８の構成例と同様である。

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

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

以上に示した機能構成により、本実施形態における認証システムは、主認証サーバ１０６を利用したシングルサインオンを実現し、更に複数の認証サーバ１０７を用いることにより、主認証サーバ１０６が機能停止した時も別の認証サーバ１０７がその機能を引き継ぐことにより、シングルサインオン機能を継続して、利用者に提供することができる。

尚、本実施形態においては、認証サーバ１０６の機能と、Ｗｅｂアプリケーションサーバ１０２の機能は別々の機能として構成されているが、これに限定されるものではなく、例えば、認証サーバ１０６の機能と認証エージェント２２２の機能を、同一のＷｅｂアプリケーションサーバ上に実装していても良い。

次に、図１及び図２に示した複数の認証サーバ（主認証サーバ１０６や認証サーバ１０７など）を利用したシングルサインオンを提供する認証システムにおける利用者の認証処理の流れについて説明する。
図３は、図１及び図２に示した認証システムにおける利用者の認証処理の流れを示すフロー図である。

図３に示すように、まず利用者は、クライアントコンピュータ１０１にインストールされたユーザエージェント２１１を用いてアプリケーションサーバ１０２に接続要求を発する（ステップ３０１）。ここで、クライアントコンピュータ１０１が発する接続要求は主としてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をユーザエージェント２１１の提供するＧＵＩの所定入力欄に対して入力することによって行われる。ユーザエージェント２１１よって発信された接続要求は、アプリケーションサーバ１０２内にインストールされたＷｅｂサーバ部２２１によって受信され、認証エージェント２２２内のユーザ認証部２２２ａに転送される。

ユーザ認証処理部２２２ａでは、まずユーザエージェント２１１に対して認証情報の入力を要求する必要があるか否かを判断する（ステップ３１１）。ユーザエージェント２１１に対して認証情報の要求が必要であると判断した場合には、ユーザ認証処理部２２２ａは、ステップ３４１に進み、ユーザエージェント２１１に対して利用者に認証情報の入力を促すための情報を生成して送信する。具体的には、ユーザ認証処理部２２２ａは、図４に示すようなログインページ（ＨＴＭＬによって記述されている）４０１を表示するための画面情報を生成して、ユーザエージェント２１１に生成した画面情報を返信する。これにより、ステップ３０１において、ユーザエージェント２１１は、画面情報を受信して、図４に示すようなログインページ４０１を表示する。これにより、クライアントコンピュータ１０１の利用者に認証情報（ユーザＩＤとパスワード）の入力を促すことができる。ここで、利用者は、予め利用者登録時に決定されたユーザＩＤとパスワードを入力する。

以上に説明したように、ユーザ認証部２２２ａは、ユーザエージェント２１１からの要求がログインページ４０１への要求であると判断した場合（ステップ３１１のＹＥＳ）には、明示的なログイン要求を意味するため、条件によらずログインページ４０１を表示するための情報を生成する。

また、明示的なログイン要求でない場合（ステップ３１１のＮＯ）、ユーザ認証部２２２ａは、利用者が既に認証済みであるか否かの判断、即ち、ログインページ４０１を利用した認証処理をせずにアプリケーションを利用させて良いか否かの判断を、既にクライアントコンピュータ１０１と接続されたセッションが存在するか否かで判断する（ステップ３１２）。

具体的には、ユーザ認証部２２２ａは、有効なセッションの存在確認処理を、例えばＣｏｏｋｉｅ（クッキー）と呼ばれる情報ファイルを利用することで実現する。Ｃｏｏｋｉｅは、アプリケーションサーバ１０２とユーザエージェント２１１間で、前回の接続状態を持続的に保持するための技術として広く用いられている情報ファイルである。本実施形態の認証システムでは、セッションを識別する識別子をセッションＣｏｏｋｉｅとして保持する。セッションＣｏｏｋｉｅとして保持される識別子は、アプリケーションサーバ１０２とユーザエージェント２１１間に確立したセッションに対して１対１に、アプリケーションサーバ１０２上に生成されるセッションオブジェクトを一意に識別できる識別子である。セッションＣｏｏｋｉｅは、ユーザエージェント２１１が起動してから初めてアプリケーションサーバ１０２に発行された要求の応答に内包される形で、ユーザエージェント２１１に送信される。一般にアプリケーションサーバ１０２には利用者の操作するクライアントコンピュータ１０１のユーザエージェント２１１が表示する画面に対してログアウトボタンを設けており、利用者がそのログアウトボタンをマウスなどの操作により押下ことで、セッションを終了することができる。セッションが終了すると、アプリケーションサーバ１０２上のセッションオブジェクトも破棄される。

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

また、ステップ３１２において有効なセッション識別子（セッションＩＤ）が確認されない場合には、ユーザ認証部２２２ａは、認証サーバ１０６に対してユーザがログインしているか否かの判断を要求する処理（認証確認を要求する処理）を行い。すでに主認証サーバ１０６に対してログインが成立していれば、Ｗｅｂアプリケーションサーバ１０２、１０４に対してもログインを認めることでシングルサインオンを実現する。

以下に、シングルサインオンを実現する処理の詳細を説明する。主認証サーバ１０６における認証確認（以下、リモート認証とする）は、以下の処理フローで進む。
まず、認証エージェント２２２は、ステップ３１３において、主認証サーバ１０６への認証確認要求に先立ち、主認証サーバ１０６に実装される、稼動確認ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出すことで主認証サーバ１０６の稼動状況を確認する。

本実施形態における稼動確認ＡＰＩは、ＳＯＡＰ１．１によるＲＰＣとして実装されており、稼動確認要求を受け取ると、データベースサーバやファイルサーバ等、主認証サーバ１０６が稼動するに必要なシステム上の資源が利用可能であるか否かを確認する。確認の結果、主任賞サーバ１０６が、認証サーバとして機能を提供できると判断された場合には真、そうでない場合には偽を表す真偽値を含む返答を認証エージェント２２２へ返す（ステップ３５１）。

稼動確認ＡＰＩを呼び出した認証エージェント２２２は、受け取った返答に含まれる真偽値を解析し、主認証サーバ１０６の稼動が確認された場合（ステップ３１４のＹＥＳ）には、リモート認証モードに移行する（ステップ３２１）。また、主認証サーバ１０６が移動してないことが確認された場合（ステップ３１４のＮＯ）は、図６に示される主認証サーバ切替え処理に移行する。

ここで、主認証サーバの切替え処理について説明する。図６は、主認証サーバの切替え処理を示すフロー図である。図６に示すように、主認証サーバ１０６の機能停止を検知した認証エージェント２２２は、保持する認証サーバの優先順位を示す情報（プロパティファイル）に従い、次の認証サーバ１０７を選択し、稼動確認ＡＰＩによる稼動確認を行う（ステップ６０１、６０２）。認証サーバ１０７は、上述したステップ３５１と同様の処理を行い稼動中であるか否かの真偽を表す真偽値を、稼動確認ＡＰＩを呼び出した認証エージェント２２２へ返信する（ステップ６０３）。

稼動確認ＡＰＩを呼び出した認証エージェント２２２は、受け取った返答に含まれる真偽値を解析し、認証サーバ１０７の稼動が確認された場合（ステップ６０４のＹＥＳ）には、リモート認証モードに移行する（ステップ６０５）。また、認証サーバ１０７が移動してないことが確認された場合（ステップ６０４のＮＯ）は、順次認証サーバを切替えて稼動確認を行うステップ６０１、６０２の処理を再度行う。すなわち、認証エージェント２２２は、稼動確認が取れた時点で、認証モードをリモート認証モードに切替え（ステップ６０５）、自身の保持する主認証サーバを示す情報（プロパティファイル）を更新する（ステップ６０６）。尚、以下の説明では、認証サーバ１０７が主認証サーバとして更新されたとする。また、認証エージェント２２２は、新たな主認証サーバである認証サーバ１０７（以下、主認証サーバ１０７とする）に認証確認要求（認証確認ＵＲＬへのＨＴＴＰリダイレクト）と主認証サーバ変更通知送信依頼を行う（ステップ６０７）。

本実施形態では主認証サーバを示す情報と認証サーバの優先順を示す情報はＩＰアドレスまたはホスト名という形式でプロパティファイルに記述される。図７は、プロパティファイルの具体例を示す図である。図７に示すように、プロパティファイル７０１中、主認証サーバは「ＡｕｔｈＳｅｒｖｅｒ」として記述される。また、認証サーバの優先順位は「ＡｕｔｈＳｅｒｖｅｒ＋番号（優先順位を示す番号）」という形で記述される。これにより、認証エージェント２２２は、稼動確認が取れるまで、プロパティファイル７０１を参照して「ＡｕｔｈＳｅｒｖｅｒ１、２、３、…」の順に認証サーバの稼動確認を行っていく。

認証確認要求と変更通知依頼を受けた新たな主認証サーバ１０７は、認証システム中の全ての認証エージェントに主認証サーバ切替え通知を送信する（ステップ６０８、６０９）。これにより、通知を受け取った認証エージェントは各々が保持するプロパティファイルを更新することで主認証サーバの切替えを行い、書き換え完了通知を主認証サーバ１０７に対して行う（ステップＳ６１０、６１１）。これにより、変更完了通知を受信した新たな主認証サーバ１０７は、ログインページの生成処理に認証確認要求を転送する（ステップ６１２）。これにより、ステップ６１３において、認証エージェント２２２は、ログインページ４０１をクライアントコンピュータ１０１に表示するための情報を生成して、ユーザエージェント２１１へ送信する。次に、ステップ６１４において、ユーザエージェント２１１は、認証エージェント２２２からログインページ４０１をクライアントコンピュータ１０１に表示するための情報を受信する。

以上に示した、主認証サーバの切替えフロー中に行われるサーバ間の全ての通知（通信経路２０１〜２０５における通信）は、例えばＳＯＡＰ１．１によるＰＲＣを利用する。
なお、本実施形態における認証システムの運用開始時は、複数の認証サーバの中から任意の一台を主認証サーバ１０６として選び、図７に示すようにプロパティファイル７０１に記述する。

ここで、図３におけるステップ３２１の処理の続きの説明に戻る。
ステップ３２１の次には、ステップ３２２において、認証エージェント２２２は、ユーザエージェント２１１からの接続要求にＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ） Ａｒｔｉｆａｃｔが含まれるか否かを判断する。このＳＡＭＬ Ａｒｔｉｆａｃｔについての説明及びステップ３２２のＹＥＳの場合における処理（ステップ３５２、３３２、３３３）の説明は詳細を後述する。

また、ＳＡＭＬ Ａｒｔｉｆａｃｔが含まれないと判断した場合（ステップ３２２のＮＯ）には、認証エージェント２２２は、ユーザエージェント２１１が既に認証エージェント２２２で認証されているか否かを確認する認証確認要求を主認証サーバ１０６へ送信するための情報をユーザエージェント２１１へ送信する（ステップ３２３）。具体的には、認証エージェント２２２は、認証確認要求として、認証サーバ１０６上で稼動しているユーザ認証部２５３に対するリダイレクト（ＨＴＴＰリダイレクト）要求をユーザエージェント２１１に送信することで主認証サーバ１０６を利用した認証確認を実現する。尚、上述したステップ３２３の処理や後述するステップ３５４、３５５の処理において、図３には示していないが、認証エージェント２２２と主認証サーバ１０６の間の通信には、ユーザエージェント２１１が介在しており、その詳細の説明については図８を用いて後述する。

次に、ユーザ認証部２５３は、処理要求を受け取ると、主認証サーバ１０６とユーザエージェント２１１の間で既にセッションが確立しているか否かを判断する。主認証サーバ１０６におけるセッションの確認は、Ｗｅｂアプリケーションサーバ１０２上の認証エージェント２２２におけるセッション確認と同じく、セッションＣｏｏｋｉｅによって確認されるが、本実施形態では、主認証サーバ１０６は、Ｗｅｂアプリケーションサーバ１０２とは異なるインターネットドメインに属するサーバとして構成されているため、Ｗｅｂアプリケーションサーバ１０２に対するセッションとは本質的に異なるセッションとして認識される。そのためセッションが確立している場合（ステップ３５３のＹＥＳ）は、すでに主認証サーバ１０６にユーザがログイン済み（＝セッションＩＤが有効）であると判断され、ユーザ認証部２５３は、認証エージェント２２２へＳＡＭＬ Ａｒｔｉｆａｃｔを送信する（ステップ３５５）。

これにより、ステップ３１７において認証エージェント２２２は、ＳＡＭＬ Ａｒｔｉｆａｃｔに対応する認証情報を認証サーバ１０６に要求して認証情報を確認後に、Ｗｅｂアプリケーション部２２３へ処理要求を転送する。

また、セッションの確立が確認できない場合（ステップ３５３のＮＯ）には、主認証サーバ１０６に対するユーザのログインが行われていない判断し、ユーザ認証部２５３は、認証エージェント２２２にログイン処理に移行するよう要求する（ステップ３５４）。これにより、認証エージェント２２２は、ステップ３４１においてログインページ４０１の生成処理を行う。

ここで、認証エージェント２２２によるログインページ４０１の生成処理について具体例を示して説明する。認証エージェント２２２がログイン処理に入ると、ログイン画面生成処理によってログインページ４０１に埋め込まれる＜ｆｏｒｍ＞タグのａｃｔｉｏｎ属性は、主認証サーバ１０６上に実装されたユーザ認証部２５３のＵＲＬとなる。同時にＨｉｄｄｅｎ属性として、サービスを識別するための識別子（図１０のサービスＩＤ）が埋め込まれる。サービスＩＤは予め主認証サーバ１０６及び認証サーバ１０７の管理者によって、主認証サーバ１０６および認証サーバ１０７に接続されているアプリケーションサーバ１０２、１０４に対して一意に割り当てられた識別子である。本実施形態では、アプリケーションサーバ１０２に組み込まれる認証エージェント２２２は、サービスＩＤとして、処理要求該当するサービスＩＤをログインページ４０１に埋め込むように構成されている。

次に、ＳＡＭＬ Ａｒｔｉｆａｃｔについての説明及びステップ３２２のＹＥＳの場合における処理の説明を行う。
主認証サーバ１０６上で有効なセッションが確立された場合、Ｗｅｂアプリケーションサーバ１０２に対してログイン済みのユーザ名を一意に通知することが必要である。本実施形態においては、このための技術として、標準化団体であるＯＡＳＩＳ（Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ）が策定しているＳＡＭＬを採用する。ＳＡＭＬによれば、利用者の認証情報など、機密性の高い情報を安全に主認証サーバ１０６からＷｅｂアプリケーションサーバ１０２に転送することができる。ＳＡＭＬの詳細に関しては本実施形態では詳細に述べないが、ＯＡＳＩＳが発行する標準仕様書Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＳＡＭＬ） Ｖ１．１、およびＢｉｎｄｉｎｇｓ ａｎｄ Ｐｒｏｆｉｌｅｓ ｆｏｒ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＳＡＭＬ） Ｖ１．１で詳細に述べられている。

本実施形態では、ＳＡＭＬの仕様の中でもＳＡＭＬ Ａｒｔｉｆａｃｔ／Ｂｒｏｗｓｅｒ Ｐｒｏｆｉｌｅと呼ばれる、主認証サーバ１０６が認証した利用者の認証情報をＷｅｂアプリケーションサーバ１０２に対して通知する技術を利用する。

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

図８に示すように、まず、ユーザエージェント２１１は、ＵＲＬ０２への処理要求をアプリケーションサーバ１０２へ送信する（ステップ１）。これにより、認証エージェント２２２は、図３に示した処理ステップ３１１〜３１４、３２１、３２２、３２３の処理により、リモート認証確認要求をＵＲＬ０１へのリダイレクトとしてユーザエージェント２１１へ送信する（ステップ２）。次に、ユーザエージェント２１１は、ＵＲＬ０１に応じて認証サーバ１０６へリモート認証要求を送信する（ステップ３）。尚、図８のステップ２、３の処理が、図３のステップ３２３の処理に対応する。

また、主認証サーバ１０６はＡｓｓｅｒｔｉｏｎ（認証情報）を生成するのと同時に、Ａｓｓｅｒｔｉｏｎと一対一に対応する短ストリングの識別子（ＳＡＭＬ Ａｒｔｉｆａｃｔ）を発行する。上述したリモート認証要求を受信した主認証サーバ１０６は、ＳＡＭＬ Ａｒｔｉｆａｃｔを含むＵＲＬ０２へのリダイレクトを認証要求応答としてユーザエージェント２１１に送信する（ステップ４）。これにより、ユーザエージェント２１１は、ＵＲＬ０２に応じたアプリケーションサーバ１０２（本実施形態では認証エージェント２２２）へアクセスする（ステップ５）。この時、認証サーバ１０６にて発行されたＳＡＭＬ Ａｒｔｉｆａｃｔは、アプリケーションサーバ１０２（本実施形態では認証エージェント２２２）にリダイレクトによって通知される。尚、図８のステップ４、５の処理が、図３のステップ３５５の処理に対応する。

リダイレクトによる接続要求を受け取ったＷｅｂアプリケーションサーバ１０２は接続要求に含まれているＳＡＭＬ Ａｒｔｉｆａｃｔを取り出し、ＳＡＭＬで定められるＳＯＡＰ上に実現されたプロトコルにより、認証サーバ１０６にＡｓｓｅｒｔｉｏｎ（認証情報）を要求する（ステップ６）。このとき、Ａｓｓｅｒｔｉｏｎ要求は、受け取ったＳＡＭＬ Ａｒｔｉｆａｃｔを内包して発行される。Ａｓｓｅｒｔｉｏｎ要求を受け取った主認証サーバ１０６は、Ａｓｓｅｒｔｉｏｎ要求に含まれるＳＡＭＬ Ａｒｔｉｆａｃｔと一意に対応するＡｓｓｅｒｔｉｏｎを検索する。この検索処理により該当するＡｓｓｅｒｔｉｏｎが見つかった場合、主認証サーバ１０６は、アプリケーションサーバ１０２に対して、先のＡｓｓｅｒｔｉｏｎ要求の返答として、見つかったＡｓｓｅｒｔｉｏｎを送信する（ステップ７）。

尚、ステップ７の処理において、主認証サーバ１０６は、Ａｓｓｅｒｔｉｏｎに含めるユーザＩＤを、利用者から処理要求のあったサービスのサービスＩＤを基に、ユーザ識別子データベースＡ・１０８を参照して定める。また、図８のステップ６、７の処理が、図３のステップ３２２のＹＥＳの場合の処理、ステップ３５２の処理及びステップ３１７の処理の一部に対応する。

以上により、アプリケーションサーバ１０２は、Ａｓｓｅｒｔｉｏｎ（認証情報）を解析することによって、ユーザエージェント２１１を利用する利用者のアプリケーションサーバ１０２上でのユーザＩＤを知ることができる。そして、認証エージェント２２２は、ユーザＩＤを利用して認証処理を行い、認証できたならＷｅｂアプリケーション部２２３へ処理要求を転送する。Ｗｅｂアプリケーション部２２３は、Ｗｅｂサーバ部２２１を介してＵＲＬ０２への処理要求に対する応答（例えば、アプリケーションサービスＡ）をユーザエージェント２１１へ送信する（ステップ８）。以上に示したように、ＳＡＭＬを利用した認証処理により、機密性を維持した状態で、サーバ間における認証情報の送受信を行うことができる。

次に、図３に示したステップ３０２以降のリモート認証モードにおけるログイン処理の詳細について説明する。
図９は、図３に示したステップ３０２以降のリモート認証モードにおけるログイン処理の詳細を示す図である。図９に示すように、利用者は、ログインページ４０１に対してユーザＩＤおよびパスワードの入力を行う（ステップ９０１）。これにより、ユーザエージェント２１１が、ユーザＩＤとパスワードを送信する先は、アプリケーションサーバ１０２ではなく主認証サーバ１０６となる。これは、上述したように、ログインページ４０１の生成時に埋め込まれるＵＲＬが主任賞サーバ１０６上のユーザ認証部２５３を示すＵＲＬであるからである。

主認証サーバ１０６上のユーザ認証部２５３は、Ｈｉｄｄｅｎ属性として受け取ったサービス名（サービスＩＤ）から、ユーザ認証の依頼先（アプリケーションサーバ）を決定し、認証エージェント２２２上に設けられた外部認証ＡＰＩに対して受け取ったユーザＩＤとパスワードの認証を依頼する（ステップ９０２）。本実施形態では、外部ユーザ認証ＡＰＩは、前述したＳＡＭＬによるユーザ認証確認フロー（図８）と同じく、ＳＯＡＰにより実装する。主認証サーバ１０６のユーザ認証部２５３は、ユーザＩＤとパスワードを引数に、サービスＩＤ上のＳＯＡＰインターフェースに対して認証要求を送信する。認証要求を受け取った認証エージェント２２２は、ユーザＩＤとパスワードが合致するデータがあるか否かを、アプリケーションサーバ１０２に接続されたユーザ情報データベースＡ・１０３から検索して、検索結果を返り値として認証要求ＡＰＩへ渡す（ステップ９０３、９０４）。

次に、認証要求ＡＰＩの返り値は真偽値であり、ユーザＩＤとパスワードが一致する登録ユーザが検索された場合は、認証要求ＡＰＩの呼出しに対する応答として真が、そうでない場合は偽が返される。偽の返答を受け取った場合（ステップ９０５のＮＯ）には、認証サーバ１０６は、再度ログイン要求を発行するために、ログイン処理に移る（ステップ９０６）。これにより、ステップ９０７において、ユーザエージェント２１１は、ログインページを受信する。

また、真の返答を受け取った場合（ステップ９０５のＹＥＳ）には、認証サーバ１０６は、ユーザの認証が成功したと判断し、ユーザエージェント２１１との間にセッション（ユーザ確認情報）を確立する（ステップ９０８）。次に、認証サーバ１０６は、アプリケーションサーバ１０２に対して認証されたユーザＩＤを通知するために、前述した認証確認要求段階と同様のＳＡＭＬ ＡｒｔｉｆａｃｔとＡｓｓｅｒｔｉｏｎによる手続きを実行する（ステップ９０９）。これにより、ステップ９１０において、ユーザエージェント２１１は、ログイン成功の旨を示すページを受信する。

以上、アプリケーションサーバ１０２、１０４と主認証サーバ１０６及び認証サーバ１０７の組合せにより、主認証サーバ１０６でのリモート認証を行う方法を示したが、これに限定されるものではない。例えば、アプリケーションサーバ１０２、１０４とは別のドメインに属する第二のアプリケーションサーバを導入した場合、第二のアプリケーションサーバ上においてもリモート認証を行うことにより、主認証サーバ１０６のセッションＣｏｏｋｉｅが二つのアプリケーションサーバ間で共有される。主認証サーバ１０６に接続されたユーザ識別子データベースＡ・１０８中のユーザ識別子（図１０のＳＳＯＩＤ（１００１））によって各アプリケーションサーバを利用する利用者を一意に識別できることにより、複数アプリケーションサーバ間でのシングルサインオンが実現できる。認証サーバ１０６における認証機能は各アプリケーションサーバ上に実装できることから、例えば、全てのアプリケーションサーバに上記認証機能を実装することで、全てのアプリケーションサーバが機能停止しない限りシングルサインオン機能が停止しない認証システムを実現することができる。

また、上述した実施形態におけるクライアントコンピュータ１０１、アプリケーションサーバ１０２、１０４、主認証サーバ１０６及び認証サーバ１０７は、ＣＰＵ及びメモリを備えるハードウェア構成である。そして、例えばアプリケーションサーバ１０２の認証エージェント２２２の機能や、主認証サーバ１０６の認証機能を実現する為のプログラムをメモリから読み出してＣＰＵが実行することによりその機能を実現させるものである。

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

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

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

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

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

本発明の一実施形態であるアプリケーションサーバを含む認証システムの構成を模式的に示す図である。 図１に示した認証システムの機能構成を示す図である。 図１及び図２に示した認証システムにおける利用者の認証処理の流れを示すフロー図である。 本実施形態におけるクライアントコンピュータ１０１に表示されるログインページ例を示す図である。 ユーザ情報データベースＡ・１０３の構成例を示す図である。 主認証サーバの切替え処理を示すフロー図である。 プロパティファイルの具体例を示す図である。 本実施形態の認証システムにおいてＳＡＭＬを利用した認証処理例を示す図である。 図３に示したステップ３０２以降のリモート認証モードにおけるログイン処理の詳細を示す図である。 ユーザ識別子データベースＡ・１０８内のデータ構成例を示す図である。

符号の説明

１００ インターネット
１０１ クライアントコンピュータ
１０２、１０４ アプリケーションサーバ
１０３ ユーザ情報データベースＡ
１０５ ユーザ情報データベースＢ
１０６ 主認証サーバ（認証サーバ）
１０７ 認証サーバ
１０８ ユーザ識別子データベースＡ
１０９ ユーザ識別子データベースＢ
２１１ ユーザスエージェント
２２１ Ｗｅｂサーバ部
２２２ 認証エージェント
２２２ａ ユーザ認証部
２２２ｂ 認証中継処理部
２２３ Ｗｅｂアプリケーション部
２５１、２６１ Ｗｅｂサーバ部
２５２、２６２ 認証中継要求部
２５３、２６３ ユーザ認証部
２５４、２６４ ユーザ識別子情報管理部

Claims (9)

1. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記複数のアプリケーションサーバに対して前記利用者端末を利用する利用者の認証情報を管理する複数の認証サーバとを備える認証システムであって、
   前記複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、前記サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースと、
   前記サービスを利用する利用者を特定する前記複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、前記第１の利用者識別子及び前記サービスを特定するサービス識別子を格納する識別子データベースと
   を具備し、
   前記アプリケーションサーバは、
   前記複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを前記複数の認証サーバの中より選択する選択手段と、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信手段と、
   前記受信手段がサービスの要求を受信した場合に、前記選択手段で選択した認証サーバに前記第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼手段と、
   前記認証情報依頼手段の依頼に応じて前記認証サーバが発行した前記第１の利用者識別子を含む認証情報を得た場合に、前記認証情報に含まれる前記第１の利用者識別子を基に、前記利用者情報データベースを参照することで、前記第１の利用者識別子で特定される利用者の認証を行う認証手段と、
   前記認証手段により認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供手段と
   を具備し、
   前記認証サーバは、
   前記アプリケーションサーバから前記第１の利用者識別子を含む認証情報の発行の依頼を受信する受信手段と、
   前記受信手段が受信した前記依頼に応じて、前記識別子データベースを参照して、利用者の要求するサービスに応じた前記第１の利用者識別子を含む認証情報を前記アプリケーションサーバへ発行する発行手段と
   を具備することを特徴とする認証システム。
2. 前記アプリケーションサーバは、
   前記選択手段で選択した前記複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを主認証サーバとする場合に、前記主認証サーバが稼動しているか否かを確認する確認手段を更に具備すること
   を特徴とする請求項１に記載の認証システム。
3. 前記認証サーバは、
   前記アプリケーションサーバの前記確認手段から稼動しているか否かの確認要求を受信する受信手段と、
   前記受信手段が受信した確認要求に応じて稼動しているか否かを示す情報を返信する稼動情報通知手段と
   を更に具備することを特徴とする請求項２に記載の認証システム。
4. 前記アプリケーションサーバは、前記選択手段が選択した前記主認証サーバに対して、選択された旨を通知する通知手段を更に具備し、
   前記認証サーバは、前記通知手段からの通知に応じて、他のアプリケーションサーバに対して認証処理の依頼先を自身に変更するよう通知する変更通知手段を具備すること
   を特徴とする請求項３に記載の認証システム。
5. 前記アプリケーションサーバは、
   前記複数の認証サーバの優先順位を定める情報を保持する保持手段を更に具備し、
   前記選択手段は、前記保持手段より前記優先順位の情報を参照して、前記複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを前記優先順位に応じて選択することを特徴とする請求項１〜４のいずれか１項に記載の認証システム。
6. 前記アプリケーションサーバは、前記認証サーバの前記受信手段及び前記発行手段と同等の機能を更に具備することを特徴とする請求項１〜５のいずれか１項に記載の認証システム。
7. 前記複数の認証サーバ毎に前記識別子データベースを設け、
   前記認証サーバは、前記識別子データベースに格納する情報を管理する管理手段を更に具備し、
   前記主認証サーバの管理手段において前記主認証サーバの識別子データベースを更新した場合には、前記主認証サーバの管理手段は、他の認証サーバの管理手段に対して、他の認証サーバの識別子データベースを同様に更新するよう指示することを特徴とする請求項２〜６のいずれか１項に記載の認証システム。
8. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記複数のアプリケーションサーバに対して前記利用者端末を利用する利用者の認証情報を管理する複数の認証サーバと、前記複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、前記サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースとを備える認証システムを利用した認証方法であって、
   前記複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを前記複数の認証サーバの中より選択する選択ステップと、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する受信ステップと、
   前記受信ステップでサービスの要求を受信した場合に、前記選択ステップで選択した認証サーバに前記第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼ステップと、
   前記認証情報依頼ステップの依頼に応じて前記認証サーバが発行した前記第１の利用者識別子を含む認証情報を得た場合に、前記認証情報に含まれる前記第１の利用者識別子を基に、前記利用者情報データベースを参照することで、前記第１の利用者識別子で特定される利用者の認証を行う認証ステップと、
   前記認証ステップで認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップと
   を前記アプリケーションサーバにより行い、
   前記アプリケーションサーバから前記第１の利用者識別子を含む認証情報の発行の依頼を受信する受信ステップと、
   前記受信ステップで受信した前記依頼に応じて、前記サービスを利用する利用者を特定する前記複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、前記第１の利用者識別子及び前記サービスを特定するサービス識別子を格納する識別子データベースを参照して、利用者の要求するサービスに応じた前記第１の利用者識別子を含む認証情報を前記アプリケーションサーバへ発行する発行ステップと
   を前記認証サーバにより行うこと
   を特徴とする認証方法。
9. ネットワークを介して利用者端末へ種々のサービスを提供する複数のアプリケーションサーバと、前記複数のアプリケーションサーバに対して前記利用者端末を利用する利用者の認証情報を管理する複数の認証サーバと、前記複数のアプリケーションサーバに対応して設けられ、各アプリケーションサーバが提供するサービスを利用する利用者の認証に必要な認証情報を、前記サービスを利用可能な利用者を特定する第１の利用者識別子に関連付けて格納する複数の利用者情報データベースとを備える認証システム用のプログラムであって、
   前記複数のアプリケーションサーバにおいて共通で利用可能な認証サーバを前記複数の認証サーバの中より選択する選択ステップと、
   前記ネットワークを介して前記利用者端末からサービスの要求を受信する第１の受信ステップと、
   前記第１の受信ステップでサービスの要求を受信した場合に、前記選択ステップで選択した認証サーバに前記第１の利用者識別子を含む認証情報の発行を依頼する認証情報依頼ステップと、
   前記認証情報依頼ステップの依頼に応じて前記認証サーバが発行した前記第１の利用者識別子を含む認証情報を得た場合に、前記認証情報に含まれる前記第１の利用者識別子を基に、前記利用者情報データベースを参照することで、前記第１の利用者識別子で特定される利用者の認証を行う認証ステップと、
   前記認証ステップで認証された利用者の利用者端末に前記要求に応じたサービスを提供するサービス提供ステップと
   前記アプリケーションサーバから前記第１の利用者識別子を含む認証情報の発行の依頼を受信する第２の受信ステップと、
   前記第２の受信ステップで受信した前記依頼に応じて、前記サービスを利用する利用者を特定する前記複数のアプリケーションサーバに共通の識別子である第２の利用者識別子に関連付けて、前記第１の利用者識別子及び前記サービスを特定するサービス識別子を格納する識別子データベースを参照して、利用者の要求するサービスに応じた前記第１の利用者識別子を含む認証情報を前記アプリケーションサーバへ発行する発行ステップと
   をコンピュータに実行させるためのプログラム。

Images