(57)【要約】      （修正有）【課題】互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報の入力により、認証が必要な複数のアプリケーションを利用可能とする。【解決手段】Ｗｅｂサーバ１０は、端末１３からの認証情報と記憶部の認証情報とを照合して認証を行い、該認証が成立した場合に、前記認証情報に含まれるユーザＩＤ、当該Ｗｅｂサーバ１０への第一のＵＲＬ、Ｗｅｂサーバ１１への第二のＵＲＬおよび前記記憶部の認証強度に関連する情報を含むメッセージを生成してネットワークに出力し、Ｗｅｂサーバ１１から認証が成功したことを示すメッセージであって、前記ユーザＩＤ、前記第一のＵＲＬ、前記第二のＵＲＬおよび認証強度に関連する情報を含むメッセージを受信すると、該ユーザＩＤが前記記憶部に記憶されている場合に前記受信した認証強度に関連する情報と前記記憶部の認証強度に関連する情報に基づいて認証を行う。【選択図】図１１
2010086435.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末とネットワークを介して接続されたコンピュータにおける情報処理方法であって、
前記何れかの端末からユーザ認証要求を前記ネットワークを介して受信し、
該認証要求に含まれるユーザ認証情報と記憶部に記憶されているユーザ認証情報とを照合してユーザ認証を行い、
該ユーザ認証が成功した場合に、前記コンピュータにて前記ユーザ認証が成功したことを示すメッセージであって、前記ユーザ認証情報に含まれるユーザ識別情報、前記コンピュータへのリンク情報、他のコンピュータへのリンク情報および前記記憶部に記憶されている認証強度に関連する情報を含むメッセージを生成し、
該メッセージを前記ネットワークに出力する
ことを特徴とする情報処理方法。
【請求項２】
他のコンピュータから、該他のコンピュータにてユーザ認証が成功したことを示すメッセージであって、前記ユーザ識別情報、前記コンピュータへのリンク情報、前記他のコンピュータへのリンク情報および認証強度に関連する情報を含むメッセージを前記ネットワークを介して受信し、
該受信したユーザ識別情報が前記記憶部に記憶されている場合に、前記受信した認証強度に関連する情報と前記記憶部に記憶されている前記認証強度に関連する情報に基づいてユーザ認証を行う
ことを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記認証強度に関連する情報は、前記ユーザ認証情報の運用ルールに関連する情報とユーザ属性情報の運用ルールに関連する情報の何れか一つ、または両方を含む
ことを特徴とする請求項２に記載の情報処理方法。
【請求項４】
前記コンピュータおよび前記他のコンピュータはＷｅｂサーバであり、前記ユーザ認証情報は、ユーザＩＤおよびパスワードである
ことを特徴とする請求項３に記載の情報処理方法。
【請求項５】
複数のＷｅｂサーバとネットワークを介して接続されたコンピュータにおける情報処理方法であって、
第一のＷｅｂサーバから、該第一のＷｅｂサーバにてユーザ認証が成功したことを示すメッセージであって、該第一のＷｅｂサーバがユーザを識別するための第一のユーザ識別情報、該第一Ｗｅｂサーバへの第一のリンク情報および第二のＷｅｂサーバへの第二のリンク情報を含むメッセージを前記ネットワークを介して受信し、
該第一のユーザ識別情報、第一のリンク情報および第二のリンク情報に基づいて、記憶部に記憶されている、前記Ｗｅｂサーバがユーザを識別するためのユーザ識別情報と、前記Ｗｅｂサーバへのリンク情報と、前記ユーザ識別情報および前記リンク情報の組み合わせに対して発行される情報で同一ユーザを識別するだめの情報と、の対応付け情報を検索して前記第二のＷｅｂサーバが前記ユーザを識別するための第二のユーザ識別情報を取得し、
前記メッセージに含まれる前記第一のユーザ識別情報を前記第二のユーザ識別情報に書き換え、
該メッセージを前記ネットワークを介して前記第二のＷｅｂサーバへ送信する
ことを特徴とする情報処理方法。
【請求項６】
複数のＷｅｂサーバとネットワークを介して接続されたコンピュータにおける情報処理方法であって、
第一のＷｅｂサーバから、該第一のＷｅｂサーバがユーザを識別するための第一のユーザ識別情報および前記第一のＷｅｂサーバへの第一のリンク情報の登録要求を前記ネットワークを介して受信し、
該受信情報に対して関連情報を発行し、該関連情報と前記受信情報とをそれぞれ対応付けて記憶部に格納し、
前記関連情報を前記ネットワークに出力し、
第二のＷｅｂサーバから、前記関連情報とともに、該第二のＷｅｂサーバが前記ユーザを識別するための第二のユーザ識別情報および前記第二のＷｅｂサーバへの第二のリンク情報の登録要求を前記ネットワークを介して受信し、
該受信した関連情報と前記記憶部に記憶されている関連情報とを照合し、
双方の関連情報が一致した場合に、前記受信した第二のユーザ識別情報および前記第二のリンク情報を前記関連情報に対応付けて前記記憶部に格納する
ことを特徴とする情報処理方法。
【請求項７】
複数の端末とネットワークを介して接続されたコンピュータであって、
ユーザ認証情報と認証強度に関連する情報を記憶する記憶部と、
前記何れかの端末からユーザ認証要求を前記ネットワークを介して受信すると、該認証要求に含まれるユーザ認証情報と前記記憶部に記憶されているユーザ認証情報とを照合してユーザ認証を行い、該ユーザ認証が成功した場合に、前記コンピュータにて前記ユーザ認証が成功したことを示すメッセージであって、前記ユーザ認証情報に含まれるユーザ識別情報、前記コンピュータへのリンク情報、他のコンピュータへのリンク情報および前記記憶部に記憶されている前記認証強度に関連する情報を含むメッセージを生成し、該メッセージを前記ネットワークに出力するように制御する制御部と、を有する
ことを特徴とするコンピュータ。
【請求項８】
前記制御部は、他のコンピュータから、該他のコンピュータにてユーザ認証が成功したことを示すメッセージであって、前記ユーザ識別情報、前記コンピュータへのリンク情報、前記他のコンピュータへのリンク情報および認証強度に関連する情報を含むメッセージを前記ネットワークを介して受信すると、該受信したユーザ識別情報が前記記憶部に記憶されている場合に、前記受信した認証強度に関連する情報と前記記憶部に記憶されている前記認証強度に関連する情報に基づいてユーザ認証を行う
ことを特徴とする請求項７に記載のコンピュータ。
【請求項９】
前記認証強度に関連する情報は、前記ユーザ認証情報の運用ルールに関連する情報とユーザ属性情報の運用ルールに関連する情報の何れか一つ、または両方を含む
ことを特徴とする請求項８に記載のコンピュータ。
【請求項１０】
前記コンピュータおよび前記他のコンピュータはＷｅｂサーバであり、前記ユーザ認証情報は、ユーザＩＤおよびパスワードである
ことを特徴とする請求項９に記載のコンピュータ。
【請求項１１】
複数のＷｅｂサーバとネットワークを介して接続されたコンピュータであって、
前記Ｗｅｂサーバがユーザを識別するためのユーザ識別情報と、前記Ｗｅｂサーバへのリンク情報と、前記ユーザ識別情報および前記リンク情報の組み合わせに対して発行される情報で同一ユーザを識別するだめの情報と、をそれぞれ対応付けて記憶する記憶部と、
第一のＷｅｂサーバから、該第一のＷｅｂサーバにてユーザ認証が成功したことを示すメッセージであって、該第一のＷｅｂサーバがユーザを識別するための第一のユーザ識別情報、該第一Ｗｅｂサーバへの第一のリンク情報および第二のＷｅｂサーバへの第二のリンク情報を含むメッセージを前記ネットワークを介して受信すると、該受信情報に基づいて前記記憶部に記憶されている情報を検索して前記第二のＷｅｂサーバが前記ユーザを識別するための第二のユーザ識別情報を取得し、前記メッセージに含まれる前記第一のユーザ識別情報を前記第二のユーザ識別情報に書き換え、該メッセージを前記ネットワークを介して前記第二のＷｅｂサーバへ送信するように制御部を有する
ことを特徴とするコンピュータ。
【請求項１２】
複数のＷｅｂサーバとネットワークを介して接続されたコンピュータであって、
第一のＷｅｂサーバから、該第一のＷｅｂサーバがユーザを識別するための第一のユーザ識別情報および前記第一のＷｅｂサーバへの第一のリンク情報の登録要求を前記ネットワークを介して受信すると、該受信情報に対して関連情報を発行し、該関連情報と前記受信情報とをそれぞれ対応付けて記憶部に格納するとともに前記関連情報を前記ネットワークに出力し、第二のＷｅｂサーバから、前記関連情報とともに、該第二のＷｅｂサーバが前記ユーザを識別するための第二のユーザ識別情報および前記第二のＷｅｂサーバへの第二のリンク情報の登録要求を前記ネットワークを介して受信すると、該受信した関連情報と前記記憶部に記憶されている関連情報とを照合し、双方の関連情報が一致した場合に、前記受信した第二のユーザ識別情報および前記第二のリンク情報を前記関連情報に対応付けて前記記憶部に格納する制御部を有する
ことを特徴とするコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一回の認証情報(ＩＤおよびパスワード等)の入力により、認証が必要な複数のアプリケーションを利用可能とする技術に関する。
【背景技術】
【０００２】
近年、様々な組織あるいは企業により様々なＷｅｂアプリケーションサービスがインターネット上で提供され、ユーザに広く利用されている。これらのＷｅｂアプリケーションの中には、ユーザ登録を行ったユーザに対して発行されたユーザＩＤとパスワードを用いてユーザを認証し、ユーザごとの便利なアプリケーションサービスを提供するものも多い。そのため、利用するＷｅｂアプリケーションの増加に伴い、ユーザの保持するユーザＩＤおよびパスワードも増加する。したがって、ユーザにとっては、複数のユーザＩＤおよびパスワードをＷｅｂアプリケーションごとに使い分けなければならず、煩雑なものとなっていた。この場合、一例として、次のような状況が起こる。あるユーザが、ブログやネットオークション、Ｗｅｂメール等のサービスを提供するポータルサイトサービスと、銀行のオンラインバンキングサービスと、証券会社のオンライントレードサービスと、居住自治体の電子申請サービスと、電力会社のオンライン電気使用開始・停止サービスとを利用していたとする。通常は、ポータルサイト、銀行、証券会社、自治体、電力会社の５つの組織が個別にユーザを管理するため、このユーザは５通りのユーザＩＤおよびパスワードを使い分ける必要があった。
【０００３】
ユーザＩＤおよびパスワードの使い分けが煩雑になることを避ける技術として一般にシングルサインオンと呼ばれる技術が知られている。シングルサインオンは、一回の認証情報(ＩＤおよびパスワード等)の入力により、認証が必要な複数のアプリケーションを利用可能とする技術である。例えば、あるＷｅｂサイトあるいは第三者安全保証機関(Ｔｈｉｒｄ-Ｐａｒｔｙ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ) (以下、認証サイトと称する)でユーザ認証を受ければ、続けて他のＷｅｂサイトにアクセスする際にはログイオン操作が不要となるユーザ認証技術が知られている(例えば、特許文献１、非特許文献１参照)。
【０００４】
【特許文献１】特開２００３−５８５０３号公報
【非特許文献１】Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｐｔｐｃｏｌｓ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ ＭａｒｋｕｐＬａｎｇｕａｇｅ（ＳＡＭＬ）Ｖ２．０、ＯＡＳＩＳ Ｓｔａｎｄａｒｄ、 １５ Ｍａｒｃｈ  ２００５、１１頁、Ｆｉｇ．４、[２００８年７月２２日検索]インターネット＜ＵＲＬ：http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記従来技術は、各Ｗｅｂサイトが認証サイトでの認証結果を受け入れることを前提としているため、各Ｗｅｂサイトと認証サイトとの間には信頼関係が成立している必要がある。したがって、上記従来技術は、このような信頼関係を容易に築くことが可能な一つの組織内に認証サイトを設け、組織内の各部門が有するＷｅｂサイトではこの認証サイトでの認証結果を利用するといった組織内認証基盤としての利用や、互いに提携関係にある企業同士での利用が現実的である。上述した５つの組織を例にとると、ポータルサイト内でブログやネットオークション、Ｗｅｂメールという一つの組織内での複数のシステムが認証サイトを共用するネットワークシステムの実現が可能である。
【０００６】
しかしながら、ポータルサイトと銀行と証券会社と自治体と電力会社といった互いに信頼関係や連携関係にない複数のシステムが認証サイトを共用するネットワークシステムを実現することは現実的には困難であった。しかし、上記従来技術には、この課題を解決する技術について記載されていない。
【０００７】
本発明の目的は、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報(ＩＤおよびパスワード等)の入力により、認証が必要な複数のアプリケーションを利用可能とする技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明を適用するネットワークシステムは、ネットワークに接続された、複数のＷｅｂサーバ、中継サーバおよび複数のユーザ端末から構成される。前記Ｗｅｂサーバは、前記何れかのユーザ端末からユーザ認証要求を前記ネットワークを介して受信すると、該認証要求に含まれるユーザ認証情報と記憶部に記憶されているユーザ認証情報とを照合して認証を行い、ユーザ認証が成立した場合に、当該Ｗｅｂサーバにてユーザ認証が成功したことを示すメッセージであって、前記ユーザ認証情報に含まれるユーザ識別情報、他のＷｅｂサーバへのリンク情報および前記記憶部に記憶されている認証強度に関連する情報を含むメッセージを生成し、該生成したメッセージを前記ネットワークに出力することを特徴とする。また、Ｗｅｂサーバは、前記他のＷｅｂサーバから、該他のＷｅｂサーバにてユーザ認証が成功したことを示すメッセージであって、前記ユーザ識別情報、前記Ｗｅｂサーバへのリンク情報、前記他のＷｅｂサーバへのリンク情報および認証強度に関連する情報を含むメッセージを前記ネットワークを介して受信すると、該受信したユーザ識別情報が前記記憶部に記憶されている場合に、前記受信した認証強度に関連する情報と前記記憶部に記憶されている前記認証強度に関連する情報に基づいてユーザ認証を行うことを特徴とする。
【０００９】
前記中継サーバは、第一のＷｅｂサーバから、該第一のＷｅｂサーバにてユーザ認証が成功したことを示すメッセージであって、該第一のＷｅｂサーバがユーザを識別するための第一のユーザ識別情報、該第一Ｗｅｂサーバへの第一のリンク情報、第二のＷｅｂサーバへの第二のリンク情報および認証強度に関する情報を含むメッセージを前記ネットワークを介して受信すると、該第一のユーザ識別情報、第一のリンク情報および第二のリンク情報に基づいて、前記中継サーバの記憶部に記憶されている、前記Ｗｅｂサーバがユーザを識別するためのユーザ識別情報と、前記Ｗｅｂサーバへのリンク情報と、前記ユーザ識別情報および前記リンク情報の組み合わせに対して発行される情報で同一ユーザを識別するだめの情報と、の対応付け情報を検索して前記第二のＷｅｂサーバが前記ユーザを識別するための第二のユーザ識別情報を取得し、前記メッセージに含まれる前記第一のユーザ識別情報を前記第二のユーザ識別情報に書き換え、該メッセージを前記ネットワークを介して前記第二のＷｅｂサーバへ送信することを特徴とする。
【発明の効果】
【００１０】
上記特徴を有する本発明によれば、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報(ＩＤおよびパスワード等)の入力により、認証が必要な複数のアプリケーションを利用可能とする技術を提供することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態について、図面を参照して詳細に説明する。
【００１２】
図１は、本発明を適用するネットワークシステム１の全体構成例を示す図である。ネットワークシステム１は、インターネット等のネットワーク１４に接続された、複数のＷｅｂサーバ１０、１１、中継サーバ１２、および複数のユーザ端末１３から構成されるシステムである。尚、複数のＷｅｂサーバは、図１に示すように二つを例にとり、それぞれＷｅｂサーバ１０、１１と区別して本実施形態を説明する。また、Ｗｅｂサーバ１０、１１は、スタティックなコンテンツを提供する狭義のＷｅｂサーバのみならず、動的にコンテンツやコンテンツの素材を生成するＡＰサーバと呼ばれるサーバや認証機能を有するリバースプロキシ等も含むものとする。
【００１３】
図２は、Ｗｅｂサーバ１０、１１のハードウェア構成例を示す図である。Ｗｅｂサーバ１０、１１は、ディスプレイ等の出力部１０１１、キーボードやマウス等の入力部１０２１、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の制御部１０３１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶部１０４１、およびネットワーク１４を介して他のコンピュータ（ユーザ端末１３、中継サーバ１２）と情報の送受信を行うＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）カード等のネットワークインタフェース部１０５１を具備する。
【００１４】
記憶部１０４１には、制御部１０３１が実行する各種プログラムおよびプログラム実行時に使用される各種データが格納されている。図２に示すように、各種プログラムは、ユーザ認証機能２０１、ユーザ認証情報変更機能２０２、ユーザ認証情報運用記録機能２０３、ユーザ属性情報更新機能２０４、ユーザ属性情報運用記録機能２０５、認証強度生成/算出機能２０６、認証済みメッセージ生成・通知機能２０７、認証済みユーザ再認証機能２０８およびＷｅｂアプリケーション２０９を含む。各種データは、ユーザ認証情報データベース２１０、ユーザ認証情報運用ポリシファイル２１１、ユーザ認証情報運用記録データベース２１２、ユーザ属性情報データベース２１３、ユーザ属性情報運用ポリシファイル２１４およびユーザ属性情報運用記録データベース２１５に記憶または記録または記載されている。
【００１５】
ユーザ認証機能２０１は、ユーザ端末１３からのユーザ認証情報（例えば、ユーザＩＤ、パスワード）とユーザ認証情報データベース２１０に記憶されているユーザ認証情報（例えば、ユーザＩＤ、パスワード）とを照合してユーザ認証を行う。ユーザ認証情報変更機能２０２は、ユーザ端末１３からのユーザ認証情報の変更要求を受けて、ユーザ認証情報データベース２１０に記憶されているユーザ認証情報を変更する。ユーザ認証情報運用記録機能２０３は、ユーザによりユーザ認証情報の変更操作が行われた場合に、その操作日時や操作内容をユーザＩＤと対応付けてユーザ認証情報運用記録データベース２１２に記録する。ユーザ属性情報更新機能２０４は、ユーザ端末１３からのユーザ属性情報の更新要求を受けて、ユーザ属性情報データベース２１３に記憶されているユーザ属性情報を更新する。ユーザ属性情報運用記録機能２０５は、ユーザによりユーザ属性情報の変更操作が行われた場合に、その操作日時、操作内容等をユーザＩＤと対応付けてユーザ属性情報運用記録データベース２１５に記録する。認証強度生成/算出機能２０６は、ユーザによりユーザ認証情報の変更操作が行われた場合に、ユーザ認証情報運用ポリシファイル２１１に記載されている操作ルール定義４０５に基づいて認証強度情報を生成または算出し、該当ユーザＩＤと対応付けてユーザ認証情報運用記録データベース２１２に記録する。また、認証強度生成/算出機能２０６は、ユーザによりユーザ属性情報の変更操作が行われた場合に、ユーザ属性情報運用ポリシファイル２１４に記載されている操作ルール定義７０９、７１０に基づいて認証強度情報を生成または算出し、該当ユーザＩＤと対応付けてユーザ属性情報運用記録データベース２１５に記録する。認証済みメッセージ生成・通知機能２０７は、ユーザ認証機能２０１によるユーザ認証の結果、認証成立した場合に、当該Ｗｅｂサーバにてユーザ認証が成功したことを示し、かつ上記認証強度情報等を含むメッセージ（認証済みメッセージと称する）を生成し、これをネットワーク１４を介して中継サーバ１２へ送信する。認証済みユーザ再認証機能２０８は、他のＷｅｂサーバにてユーザ認証が成功したユーザを、上記他のＷｅｂサーバからの認証済みメッセージに含まれる認証強度に関連する情報と当該Ｗｅｂサーバに記憶されている認証強度に関連する情報に基づいて再認証する。
【００１６】
図３は、ユーザ認証情報データベース２１０の構成例を示す図である。ユーザ認証情報データベース２１０には、ユーザＩＤ（ユーザ識別情報）３０１とパスワード（秘密情報）３０２とがそれぞれ対応付けられて記憶されている。
【００１７】
図４は、ユーザ認証情報運用ポリシファイル２１１の構成例を示す図である。ユーザ認証情報運用ポリシファイル２１１は、ユーザ認証情報定義部４０１とユーザ認証情報運用ルール部４０４から構成される。ユーザ認証情報定義部４０１は、ユーザＩＤ定義４０２とパスワード定義４０３からなり、最低文字数や文字の組み合わせ（アルファベットと数字を混ぜること）などデータ構造に関する制約事項が定義されている。ユーザ認証情報運用ルール部４０４には、操作ルール定義４０５が０個以上記載される。操作ルール定義４０５には、例えば、ユーザ認証情報定義部４０１で定義したどのデータを対象とした操作ルールか、どのような操作を対象としたルールか、最長頻度はどの程度か、最大何世代前までの再利用を禁止するかといった操作ルールが定義される。図４に示す例では、操作ルール定義４０５には、パスワード(ｐａｓｓｗｏｒｄ)の更新（ｕｐｄａｔｅ）について、６ヶ月以内に更新することおよび更新時の再利用は２世代までといった制約事項が定義されている。
【００１８】
図５は、ユーザ認証情報運用記録データベース２１２の構成例を示す図である。ユーザ認証情報運用記録データベース２１２には、ユーザ認証情報の変更操作を行ったユーザのユーザＩＤ３０１と操作日時５０１と操作内容５０２と認証強度５０３とがそれぞれ対応付けられて記録されている。認証強度５０３は、認証強度生成/算出機能２０６により、例えば、操作ルール定義４０５で定義されている操作ルールの遵守度（あるいは余裕率）から生成または算出される。図４に示す操作ルールでは、パスワードを６ヶ月以内に更新し、またその再利用は２世代前までと定義されており、例えば、どちらか一方でも条件を満たさない場合、あるいは過去に一度も双方の条件を満たさなかったことがある場合は認証強度Ｃが、５ヶ月以内に更新し３世代前まで再利用されていない場合は認証強度Ａが、そのどちらでもない場合は認証強度Ｂが、認証強度生成/算出機能２０６によりユーザ認証情報運用記録データベース２１２の認証強度５０３に記録される。
【００１９】
図６は、ユーザ属性情報データベース２１３の構成例を示す図である。ユーザ属性情報データベース２１３には、ユーザＩＤ３０１、ユーザの氏名６０１、住所６０２、性別６０３、生年月日６０４、口座番号６０５といったユーザの属性情報がそれぞれ対応付けて記憶されている。
【００２０】
図７は、ユーザ属性情報運用ポリシファイル２１４の構成例を示す図である。ユーザ属性情報運用ポリシファイル２１４は、ユーザ属性情報定義部７０１とユーザ属性情報運用ルール部７０２から構成される。ユーザ属性情報定義部７０１には、ユーザＩＤ定義７０３、氏名定義７０４、住所定義７０５、性別定義７０６、生年月日定義７０７、口座番号定義７０８等、ユーザ属性情報データベース２１３に記憶されている各情報について、最低文字数等のデータ構造に関する制約事項が定義されている。ユーザ属性情報運用ルール部７０２には、操作ルール定義が０個以上記載される。図７に示す例では、ユーザ属性情報運用ルール部７０２には、二つの操作ルール定義７０９、７１０が記載されている。操作ルール定義７０９には、氏名、住所、性別、生年月日および口座番号を新規作成する際、居住を確認可能な身分証によって確認されなければならない旨が記載されている。操作ルール定義７１０には、氏名、住所および性別を更新する際、書面または電話による確認が必要である旨が記載されている。
【００２１】
図８は、ユーザ属性情報運用記録データベース２１５の構成例を示す図である。ユーザ属性情報運用記録データベース２１５には、ユーザ属性情報の更新等の操作を行ったユーザのユーザＩＤ３０１と操作日時８０１と操作内容８０２と操作対象８０３と確認方法８０４と認証強度８０５とがそれぞれ対応付けられて記録されている。認証強度８０５は、認証強度生成/算出機能２０６により、操作ルール定義７０９、７１０で定義されている操作ルールの遵守度（あるいは余裕率）から生成または算出される。例えば、図７に示すユーザ属性情報運用ポリシファイル２１４に記載された操作ルール７１０では、書面または電話による確認が必要とされており、対面手続きでの書面による確認であれば認証強度Ａが、電話による確認であれば書面より強度の低い認証強度Ｂが、認証強度生成/算出機能２０６によりユーザ属性情報運用記録データベース２１５の認証強度８０５に記録される。なお、認証強度８０５に記録される情報は、ユーザ属性情報の操作に関する強度、すなわちユーザ属性情報の更新であれば更新後の情報の確からしさを示す情報であるので、実際に確認に使用した書類名（例えば「住民票の写し」「発行後１２０日経過の運転免許証」「クレジットカード会社Ｚ社の利用明細通知書」等）であっても良い。
【００２２】
図９は、中継サーバ１２のハードウェア構成例を示す図である。中継サーバ１２は、ディスプレイ等の出力部１０１２、キーボードやマウス等の入力部１０２２、ＣＰＵ等の制御部１０３２、ＲＡＭやＨＤＤ等の記憶部１０４２、およびネットワーク１４を介して他のコンピュータ（Ｗｅｂサーバ１０、１１）と情報の送受信を行うＬＡＮカード等のネットワークインタフェース部１０５２とを具備する。
【００２３】
記憶部１０４２には、制御部１０３２が実行する各種プログラムおよびプログラム実行時に使用される各種データが格納されている。図９に示すように、各種プログラムは、ユーザＩＤ解決機能９０１、認証済みメッセージ中継機能９０２を少なくとも含む。各種データは、同一ユーザ情報データベース９０３に記憶されている。
【００２４】
ユーザＩＤ解決機能９０１は、同一ユーザ情報データベース９０３を参照して、Ｗｅｂサーバ１０にて有効なユーザＩＤ（第一のユーザＩＤと称する）に対応するＷｅｂサーバ１１で有効なユーザＩＤ（第二のユーザＩＤと称する）を解決する。なお、Ｗｅｂサーバ１０またはＷｅｂサーバ１１で有効なユーザＩＤとは、それぞれがユーザを識別するためのユーザＩＤを示す。
【００２５】
図１５は、同一ユーザ情報データベース９０３の構成例を示す図である。図１５に示すように、同一ユーザ情報データベース９０３には、連携ユーザＩＤ１５０１とＷｅｂサーバ１０へのＵＲＬ（第一のＵＲＬと称する）１５０２とＷｅｂサーバ１１へのＵＲＬ（第二のＵＲＬと称する）１５０３とがそれぞれ対応付けられて記憶されている。連携ユーザＩＤ１５０１は、第一のユーザＩＤに対応する第二のユーザＩＤを解決するためのキーとなる情報であり、ＷｅｂサーバへのＵＲＬおよびこのＷｅｂサーバがユーザを識別するためのユーザＩＤの組み合わせに対して発行される。同一ユーザ情報データベース９０３において、連携ユーザＩＤが等しいレコード同士は、同一ユーザに関するレコードであることを示している。
【００２６】
図１０は、ユーザ端末１３のハードウェア構成例を示す図である。ユーザ端末１３は、ディスプレイ等の出力部１０１３、キーボードやマウス等の入力部１０２３、ＣＰＵ等の制御部１０３３、ＲＡＭやＨＤＤ等の記憶部１０４３、およびネットワーク１４を介して他のコンピュータ（Ｗｅｂサーバ１０、１１）と情報の送受信を行うＬＡＮカード等のネットワークインタフェース部１０５３を具備する。
【００２７】
記憶部１０４３には、制御部１０３３が実行する各種プログラムが格納されている。図１０に示すように、各種プログラムは、ユーザ認証情報取得・更新機能１００１、ユーザ属性情報取得・更新機能１００２、サービス要求・サービス中継要求送信機能１００３を含む。
【００２８】
図１１は、ネットワークシステム１全体の処理概要を示すシーケンス図である。なお、図１１に示す各処理は、各コンピュータが具備する制御部が記憶部に記憶されているプログラムに従って実行する。ここでは、説明を簡単にするために、単に制御部を実行主体として各処理を説明する。
【００２９】
先ず、ユーザ端末１３の制御部１０３３は、ユーザにより入力部１０２３を介して入力された認証情報を取得し、その認証情報を含む認証要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１１０１）。
【００３０】
Ｗｅｂサーバ１０の制御部１０３１は、受信した認証情報とユーザ認証情報データベース２１０に記憶されている認証情報とを照合してユーザ認証を行い（ステップ１１０２）、認証結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１１０３）。なお、ユーザ認証の結果、認証に失敗した場合は、ステップ１１０３以後の処理は行われない。
【００３１】
ステップ１１０３において、認証結果が認証成功を示す場合は、ユーザ端末１３の制御部１０３３は、サービス要求（Ｗｅｂアプリケーション利用要求）をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１１０４）。
【００３２】
Ｗｅｂサーバ１０の制御部１０３１は、上記サービス要求を受けて、該当Ｗｅｂアプリケーション２０９の実行結果を示すサービス画面をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１１０５）。このサービス画面は、ユーザ端末１３の出力部１０１３に出力される。サービス画面例を図１４に示す。図１４に示す例では、サービス画面には、Ｗｅｂサーバ１０が提供するオンラインバンキングの振込みサービス画面、および他のサイトへのＵＲＬを入力するためのテキストボックス１４０１入力画面がそれぞれ示されている。ここで、ユーザが、テキストボックス１４０１にＷｅｂサーバ１１への第ニのＵＲＬを入力し、入力部１０２３を用いて送信ボタン１４０２を押下する操作を行うと、新しいＷｅｂサービス画面が出力部１０１３に出力されるとともに、ユーザ端末１３の制御部１０３３は、第二のＵＲＬを含むサービス中継要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１１０６）。
【００３３】
Ｗｅｂサーバ１０の制御部１０３１は、Ｗｅｂサーバ１０においてユーザ認証が成功したことを示し、第一のユーザＩＤ、第一のＵＲＬ、第二のＵＲＬおよび認証強度に関連する情報を含む認証済みメッセージを生成し(ステップ１１０７)、これをネットワーク１４を介して中継サーバ１２へ送信する（ステップ１１０８）。
【００３４】
中継サーバ１２の制御部１０３２は、同一ユーザ情報データベース９０３を参照して、認証済みメッセージに含まれる第一のユーザＩＤに対応する第二のユーザＩＤを取得し（ステップ１１０９）、認証済みメッセージに含まれる第一のユーザＩＤを第二のユーザＩＤに書き換え、この認証済みメッセージをネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ１１１０）。
【００３５】
Ｗｅｂサーバ１１の制御部１０３１は、認証済みメッセージに含まれる第二のユーザＩＤからユーザを識別し、また、認証済みメッセージに含まれる認証強度に関連する情報とＷｅｂサーバ１１の記憶部１０４１に記憶されている認証強度に関連する情報に基づいてユーザの再認証を行い（ステップ１１１１）、その結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１１１２）。なお、再認証の結果、ユーザ認証に失敗した場合は、ステップ１１１２以後の処理は行われない。
【００３６】
ステップ１１１２において、再認証結果が認証成功を示す場合は、ユーザ端末１３の制御部１０３３は、Ｗｅｂサーバ１１へサービス要求をネットワーク１４を介して送信する（ステップ１１１３）。
【００３７】
Ｗｅｂサーバ１１の制御部１０３１は、上記サービス要求を受けて、該当Ｗｅｂアプリケーション２０９を実行し、その実行結果を示すサービス画面をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１１１４）。このサービス画面は、ユーザ端末１３の出力部１０１３に出力される。
【００３８】
図１２は、Ｗｅｂサーバ１０において、認証済みメッセージを生成し、これを中継サーバ１２に送信する（図１１−ステップ１１０７、１１０８）詳細処理を示すフローチャートである。先ず、Ｗｅｂサーバ１０の制御部１０３１は、ユーザ端末１３から送信されたサービス中継要求をネットワーク１４、ネットワークインタフェース部１０５１を介して受信する（ステップ１２０１）。次に、制御部１０３１は、受信したサービス中継要求から第一のユーザＩＤおよび第二のＵＲＬを抽出する（ステップ１２０２）。次に、制御部１０３１は、第一のユーザＩＤに基づいてユーザ認証情報運用記録データベース２１２を検索し、該当レコードからユーザ認証情報運用記録を取得する（ステップ１２０３）。次に、制御部１０３１は、第一のユーザＩＤに基づいてユーザ属性情報運用記録データベース２１５を検索し、該当レコードからユーザ属性情報運用記録を取得する（ステップ１２０４）。次に、制御部１０３１は、ステップ１２０２で抽出した第一のユーザＩＤおよび第二のＵＲＬと、予めプログラムに記述されたユーザ認証情報ポリシファイル２１１の格納先を示す情報（url）と、ステップ１２０３で取得したユーザ認証情報運用記録と、予めプログラムに記述されたユーザ属性情報運用ポリシファイル２１４の格納先を示す情報（url）と、ステップ１２０４で取得したユーザ属性情報運用記録を含む認証済みメッセージを生成し（ステップ１２０５）、これをネットワーク１４を介して中継サーバ１２へ送信する(ステップ１２０６)。なお、ステップ１２０２（図１２）において、サービス中継要求から第一のユーザＩＤを抽出しているが、その実現方法には、ＵＲＬにパラメータとして記載されている第一のユーザＩＤを抽出する方法、ＨＴＴＰヘッダに記載されている第一のユーザＩＤを抽出する方法、ＨＴＴＰボディにパラメータとして記載されている第一のユーザＩＤを抽出する方法、セッション管理のためのＣｏｏｋｉｅとユーザ認証情報データベース２１０を組み合わせてユーザＩＤを抽出する方法など、いくつかの実現方法がある。また、ステップ１２０５において、ユーザ認証情報運用ポリシファイルへのurlおよびユーザ属性情報運用ポリシファイルへのurlを認証済みメッセージに含めるようにしたが、各ファイルに記載されている情報実体を認証済みメッセージに含めるようにしても良い。
【００３９】
図１３は、Ｗｅｂサーバ１０にて生成される認証済みメッセージの構成例を示す図である。図１３に示すように、認証済みメッセージには、第一のユーザＩＤ１３０２、Ｆｒｏｍ要素で記載された第一のＵＲＬおよびＴｏ要素で記載された第二のＵＲＬ１３０３、ユーザ認証情報運用情報部１３０４、ユーザ属性情報運用情報部１３０５が記載される。ユーザ認証情報運用情報部１３０４には、ユーザ認証情報運用ポリシファイル２１１へのurl１３０６およびユーザ認証情報運用記録１３０７が記載される。ユーザ属性情報運用情報部１３０５には、ユーザ属性情報運用ポリシファイル２１４へのurl１３０８、ユーザ属性情報運用記録１３０９が記載される。
【００４０】
図１６は、中継サーバ１２において、第一のユーザＩＤに対応する第二のユーザＩＤを解決し、認証済みメッセージに含まれる第一のユーザＩＤを第二のユーザＩＤに書き換え、この認証済みメッセージをＷｅｂサーバ１１へ送信する（図１１−ステップ１１０９、１１１０）詳細処理を示すフローチャートである。ここでは、図１３および図１５に示す具体的なパラメータを用いながら図１６を説明する。先ず、中継サーバ１２の制御部１０３２は、Ｗｅｂサーバ１０から送信された認証済みメッセージをネットワーク１４、ネットワークインタフェース部１０５２を介して受信する（ステップ１６０１）。次に、制御部１０３２は、認証済みメッセージ（図１３）から第一のユーザＩＤ「１００００１」（１３０２）、第一のＵＲＬ「ｈｔｔｐｓ://ｗｗｗ.ｔｅｓｔ.ｃｏｍ/」および第二のＵＲＬ「ｈｔｔｐｓ://ｗｗｗ.ｅｘａｍｐｌｅ.ｃｏｍ/」（１３０３）を抽出する（ステップ１６０２）。次に、制御部１０３２は、第一のユーザＩＤ「１００００１」１３０２および第一のＵＲＬ「ｈｔｔｐｓ://ｗｗｗ.ｔｅｓｔ.ｃｏｍ/」１３０３に基づいて同一ユーザ情報データベース９０３（図１５）を検索し、該当レコード（１５０３）から連携ＩＤ「ＩＤＦ０００００１」１５０１を取得する（ステップ１６０３）。次に、制御部１０３２は、連携ＩＤ「ＩＤＦ０００００１」１５０１および第二のＵＲＬ「ｈｔｔｐｓ://ｗｗｗ.ｅｘａｍｐｌｅ.ｃｏｍ/」１３０３に基づいて同一ユーザ情報データベース９０３を検索し、該当レコード（１５０４）から第二のユーザＩＤ「２００００１」３０１を取得する（ステップ１６０４）。次に、制御部１０３２は、認証済みメッセージの第一のユーザＩＤ「１００００１」（１３０２）を第二のユーザＩＤ「２００００１」（３０１）に書き換え(ステップ１６０５)、この認証済みメッセージをネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ１６０６）。
【００４１】
図１７および図１８は、ネットワークシステム１において、中継サーバ１２が具備する同一ユーザ情報データベース９０３に、同一ユーザ情報を登録する処理を示すシーケンス図である。なお、以下の説明において、ＩＤ登録要求とは、ユーザＩＤおよびＷｅｂサーバへのＵＲＬの登録要求を示すものとする。先ず、図１７を参照して、第一のユーザＩＤおよび第一のＵＲＬを同一ユーザ情報データベース９０３に仮登録する処理を説明する。ユーザ端末１３の制御部１０３３は、認証要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１７０１）。
【００４２】
Ｗｅｂサーバ１０の制御部１０３１は、認証要求に含まれる認証情報とユーザ認証情報データベース２１０に記憶されている認証情報とを照合して認証処理を行い（ステップ１７０２）、その結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１７０３）。
【００４３】
ユーザ端末１３の制御部１０３３は、認証結果が認証成功を示す場合に、ＩＤ登録要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１７０４）。
【００４４】
Ｗｅｂサーバ１０の制御部１０３１は、第一のユーザＩＤおよび第一のＵＲＬ１７０を含むＩＤ登録要求をネットワーク１４を介して中継サーバ１２へ送信する（ステップ１７０５）。
【００４５】
中継サーバ１２の制御部１０３２は、受信した第一のユーザＩＤおよび第一のＵＲＬが同一ユーザ情報データベース９０３に登録されていない場合には、既に登録済みの連携ユーザＩＤと衝突しない新規の連携ユーザＩＤを発行し、これを第一のＵＲＬおよび第一のユーザＩＤと対応付けて同一ユーザ情報データベース９０３に仮登録する。なお、受信した第一のユーザＩＤおよび第一のＵＲＬが同一ユーザ情報データベース９０３に既に登録されている場合には、制御部１０３２は仮登録処理を行わない。次に、制御部１０３２は、仮登録した連携ユーザＩＤを含む情報（チケットと称する）１７１を生成し（ステップ１７０７）、これをネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ１７０８）。なお、チケット生成の際、連携ユーザＩＤを暗号化しても良い。ただし、暗号化方法は、受信側装置で復号化可能な方法でなければならない。
【００４６】
Ｗｅｂサーバ１０の制御部１０３１は、受信したチケット１７１をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１７０９）。ユーザ端末１３は、受信したチケット１７１をメモリ等に保持する（ステップ１７１０）。
【００４７】
次に、図１８を参照して、第ニのユーザＩＤおよび第ニのＵＲＬを同一ユーザ情報データベース９０３に登録する処理を説明する。先ず、ユーザ端末１３の制御部１０３３は、認証要求をネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ１８０１）。
【００４８】
Ｗｅｂサーバ１０の制御部１０３１は、認証要求に含まれる認証情報とユーザ認証情報データベース２１０に記憶されている認証情報とを照合して認証処理を行い（ステップ１８０２）、その結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１８０３）。
【００４９】
ユーザ端末１３の制御部１０３３は、認証結果が認証成功を示す場合に、保持していたチケット１７１とともにＩＤ登録要求をネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ１８０４）。
【００５０】
Ｗｅｂサーバ１１の制御部１０３１は、チケット１７１とともに、第ニのユーザＩＤおよび第ニのＵＲＬ１７２を含むＩＤ登録要求をネットワーク１４を介して中継サーバ１２へ送信する（ステップ１８０５）。
【００５１】
中継サーバ１２の制御部１０３２は、受信チケット１７１から連携ユーザＩＤを抽出し、この連携ユーザＩＤが同一ユーザ情報データベース９０３に登録されているか否かを判断する（ステップ１８０６）。判断の結果、連携ユーザＩＤが同一ユーザ情報データベース９０３に登録されていれば、制御部１０３２は、第二のＵＲＬおよび第二のユーザＩＤ１７２を連携ＩＤと対応付けて同一ユーザ情報データベース９０３に登録する（ステップ１８０７）。制御部１０３２は、ＩＤ登録処理を終えると、登録結果をネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ１８０８）。登録結果は、例えば、ユーザがアクセスする各ＷｅｂサーバのＵＲＬ、および各Ｗｅｂサーバでユーザを識別するためのユーザＩＤの登録が正常に完了した旨等を示す情報である。Ｗｅｂサーバ１１の制御部１０３１は、この登録結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１８０９）。
【００５２】
ユーザ端末１３の制御部１０３３は、この登録結果を受信すると、メモリ等に保持しておいたチケット１７１をメモリ等から削除する（ステップ１８１０）。
【００５３】
図１９は、Ｗｅｂサーバ１１において、Ｗｅｂサーバ１０で認証されたユーザを再認証し、その結果をユーザ端末１３へ送信する（図１１−ステップ１１１１、１１１２）詳細処理を示すフローチャートである。先ず、Ｗｅｂサーバ１１の制御部１０３１は、中継サーバ１２から送信された認証済みメッセージをネットワーク１４、ネットワークインタフェース部１０５１を介して受信する（ステップ１９０１）。次に、制御部１０３１は、認証済みメッセージから、第二のユーザＩＤ１３０２と、ユーザ認証情報運用ポリシファイルへのurl１３０６と、ユーザ認証情報運用記録１３０７と、ユーザ属性情報運用ポリシファイルへのurl１３０８と、ユーザ属性情報運用記録１３０９を抽出する（ステップ１９０２）。ここで、制御部１０３１は、url１３０６およびurl１３０７から、ユーザ認証情報運用ポリシファイル２１１およびユーザ属性情報運用ポリシファイル２１４をダウンロードし、これらファイルに記載されているユーザ認証情報運用ポリシおよびユーザ属性情報運用ポリシを取得する。なお、運用ポリシ情報は一度決めたら変更することは珍しいため、必ずしも毎回ダウンロードする必要はなく、Ｗｅｂサーバ１１においてキャッシュしておいても良い。次に、制御部１０３１は、ステップ１９０２で抽出した第二のユーザＩＤがユーザ認証情報データベース２１０に登録されているかどうかを確認する（ステップ１９０３）。確認の結果、第二のユーザＩＤがユーザ認証情報データベース２１０に登録されていない場合には、制御部１０３１は、認証失敗を示す情報をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１９０５）。一方、確認の結果、第二のユーザＩＤがユーザ認証情報データベース２１０に登録されている場合には、制御部１０３１は、ステップ１９０２で抽出した情報（ユーザ認証情報運用ポリシ、ユーザ認証情報運用記録１３０７、ユーザ属性情報運用ポリシ、ユーザ属性情報運用記録１３０９）と、Ｗｅｂサーバ１１の記憶部１０４１に記憶されている情報（ユーザ認証情報運用ポリシ、ユーザ認証情報運用記録、ユーザ属性情報運用ポリシ、ユーザ属性情報運用記録）に基づいて、ユーザの再認証を行い（ステップ１９０４）、再認証結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ１９０５）。すなわち、制御部１０３１は、Ｗｅｂサーバ１０で保持する認証強度に関連する情報とＷｅｂサーバ１１で保持する認証強度に関連する情報とを比較し、その比較結果に基づいて再認証成否を判断し、その結果をネットワーク１４を介してユーザ端末１３へ送信する。再認証成否は、（１）ユーザ認証情報運用ポリシの比較結果、（２）ユーザ認証情報運用記録の比較結果、（３）ユーザ属性情報運用ポリシの比較結果、（４）ユーザ属性情報運用記録の比較結果の何れか一つ、または（１）から（４）の任意の組合せにより判断する。例えば、Ｗｅｂサーバ１１の制御部１０３１は、Ｗｅｂサーバ１０で保持するユーザ認証情報運用ポリシとＷｅｂサーバ１１で保持するユーザ認証情報運用ポリシとを比較し、その結果、Ｗｅｂサーバ１１で保持するユーザ認証情報運用ポリシがＷｅｂサーバ１０で保持するユーザ認証情報運用ポリシより厳しい要件を課している場合には、再認証失敗と判断する。また、例えば、制御部１０３１は、パスワードの最低長（図４−４０３）の比較結果、パスワードの組み合わせ文字種別の数（４０３）の比較結果、パスワードの最長更新期間（４０５）の比較結果、パスワードの最低再利用世代数（４０５）の比較結果、ユーザ属性情報の項目数（図７−７０１）の比較結果、ユーザ属性情報の操作に関する確認条件（７０２）の比較結果の何れか一つ、またはこれらの任意の組み合わせに基づいて再認証成否を判断する。なお、ユーザ属性情報の操作に関する確認条件（７０２）を比較する場合、図７に示すような自然言語文での表現ではなく、レベルやランクとして表現できるＡ、Ｂ、Ｃなどのコードを用いたり、数値によりスコア化したりする必要がある。この場合、これらのコードやスコアの意味については、Ｗｅｂサーバ１０およびＷｅｂサーバ１１間で事前に同意されている必要がある。また、例えば、ユーザ認証情報運用記録データベース２１２に記憶されている認証強度５０３や、ユーザ属性情報運用記録データベース２１５に記憶されている認証強度８０５を用いて、Ｗｅｂサーバ１１の制御部１０３１がＷｅｂサーバ１０での認証結果を受け入れるための最低認証強度を設定しておくようにしても良い。これは、認証強度がＡ以上でなければ受け入れない、Ｂ以上でなければ受け入れないという再認証処理を行う方法であり、Ａ以上でなければ受け入れないという処理を行う場合、図１３に示す認証済みメッセージ例はユーザ属性情報運用記録（１３０９）に認証強度Ｂを含むため、Ｗｅｂサーバ１１の制御部１０３１は認証失敗を示す結果をユーザ端末１３にネットワーク１４を介して送信する。また、例えば、Ｗｅｂサーバ１１の制御部１０３１は、ユーザ認証情報運用ポリシファイル２１１に記載された操作ルール４０５(図４)からユーザ認証情報運用記録（図１３−１３０７）の遵守度（あるいは余裕率）を求め、所定の遵守度を満たしていない場合には認証失敗と判断する。なお、この場合、Ｗｅｂサーバ１０がユーザ認証情報運用記録データベース２１２に記憶されている認証強度５０３（図５）を計算する処理を、Ｗｅｂサーバ１１側で再計算し直すことに等しい。
【００５４】
以上、本発明の実施形態を説明した。本実施形態によれば、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報(ＩＤおよびパスワード等)の入力により、認証が必要な複数のアプリケーションを利用可能とする技術を提供することができる。また、本発明は、上記実施形態に限定されるものではなく、その趣旨の範囲内で数々の変形が可能である。以下に、他の実施形態について説明する。
(他の実施形態１)
図２０は、他実施形態によるネットワークシステム１全体における処理概要を示すシーケンス図である。なお、図２０に示す各処理は、各コンピュータが具備する制御部が記憶部に記憶されているプログラムに従って実行する。ここでは、説明を簡単にするために、単に制御部を実行主体として各処理を説明する。
【００５５】
先ず、ユーザ端末１３の制御部１０３３は、ユーザにより入力部１０２３を介して入力された認証情報を取得し、その認証情報を含む認証要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ２００１）。
【００５６】
Ｗｅｂサーバ１０の制御部１０３１は、受信した認証情報とユーザ認証情報データベース２１０に記憶されている認証情報とを照合してユーザ認証を行い（ステップ２００２）、認証結果をネットワーク１４を介してユーザ端末１３へ送信する（ステップ２００３）。なお、ユーザ認証の結果、認証に失敗した場合は、ステップ２００３以後の処理は行われない。
【００５７】
ステップ２００３において、認証結果が認証成功を示す場合は、ユーザ端末１３の制御部１０３３は、第二のＵＲＬを含むサービス要求をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ２００４）。
【００５８】
Ｗｅｂサーバ１０の制御部１０３１は、Ｗｅｂサーバ１０においてユーザ認証が成功したことを示し、第一のユーザＩＤ、第一のＵＲＬ、第二のＵＲＬおよび認証強度に関連する情報等を含む認証済みメッセージを生成し(ステップ２００５)、これをネットワーク１４を介して中継サーバ１２へ送信する（ステップ２００６）。
【００５９】
中継サーバ１２の制御部１０３２は、同一ユーザ情報データベース９０３を参照して、認証済みメッセージに含まれる第一のユーザＩＤに対応する第二のユーザＩＤを取得し（ステップ２００７）、認証済みメッセージに含まれる第一のユーザＩＤを第二のユーザＩＤに書き換え、この認証済みメッセージをネットワーク１４を介してＷｅｂサーバ１４へ送信する（ステップ２００８）。
【００６０】
Ｗｅｂサーバ１１の制御部１０３１は、認証済みメッセージに含まれる第二のユーザからユーザを識別し、また、認証済みメッセージに含まれる認証強度に関連する情報とＷｅｂサーバ１１の記憶部１０４１に記憶されている認証強度に関連する情報に基づいてユーザの再認証を行い（ステップ２００９）、その結果をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ２０１０）。なお、再認証の結果、ユーザ認証に失敗した場合は、ステップ２０１０以後の処理は行われない。
【００６１】
ステップ２０１０において、再認証結果が認証成功を示す場合は、Ｗｅｂサーバ１０の制御部１０３１は、サービス要求をネットワーク１４を介してＷｅｂサーバ１１へ送信する（ステップ２０１１）。
【００６２】
Ｗｅｂサーバ１１の制御部１０３１は、上記サービス要求を受けて、該当Ｗｅｂアプリケーション２０９を実行し、その実行結果を示すサービス画面およびコンテンツ１７３をネットワーク１４を介してＷｅｂサーバ１０へ送信する（ステップ２０１２）。
【００６３】
Ｗｅｂサーバ１０の制御部１０３１は、サービス画面にコンテンツを埋め込み、これをネットワーク１４を介してユーザ端末１３へ送信する（ステップ２０１３）。このサービス画面は、ユーザ端末１３の出力部１０１３に出力される。
(他の実施形態２)
Ｗｅｂサーバ１０、Ｗｅｂサーバ１１および中継サーバ１２は、それぞれサーバ機能を提供するものであるので、同一コンピュータに二つ乃至三つのサーバ機能を搭載する実施形態であっても良い。特に、昨今はＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）と呼ばれるソフトウェアデリバリ形態が普及しつつあり、ＳａａＳ形態では同一計算機上に複数サーバ機能が搭載される。同様に、サーバ仮想化機構を用いて、同一計算機上に複数サーバ機能をＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）ごと複数搭載する実施形態も、本発明の変形の範囲内である。
(他の実施形態３)
図１７および図１８に示すＩＤ登録方法を用いてユーザＩＤおよびＷｅｂサーバのＵＲＬを同一ユーザ情報データベース９０３に登録すると、同一ユーザに対して複数の連携ユーザＩＤが発行され同一ユーザ情報データベース９０３に登録される場合がある。例えば、図１７および図１８に示す処理手順に従って、第一のユーザＩＤ、第一のＵＲＬ、並びに第二のユーザＩＤ、第二のＵＲＬを同一ユーザ情報データベース９０３に登録した後、別の機会に、Ｗｅｂサーバ１０、１１以外の他のＷｅｂサーバで有効なユーザＩＤ、他のＷｅｂサーバへのＵＲＬを図１７に示す処理手順に従って同一ユーザ情報データベース９０３に仮登録し、次に図１８に示す処理手順に従ってＷｅｂサーバ１１で有効な第二のユーザＩＤ、第二のＵＲＬを同一ユーザ情報データベース９０３に登録すると、仮登録されるＵＲＬおよびユーザＩＤがそれぞれの登録機会で異なっているため、異なる連携ユーザＩＤが割り当てられる。これを防止する方法として、例えば、チケットを再利用する方法がある。具体的には、初回のユーザＩＤ仮登録時に、ユーザ端末１３で保持していたチケット１７１（図１７−ステップ１７１０）をメモリ等から削除（図１８−ステップ１８１０）せず、２回目以降のＩＤ仮登録時に、ユーザ端末１３の制御部１０３３は、チケット１７１ととともにＩＤ登録要求をネットワーク１４を介してＷｅｂサーバ１０へ送信し、Ｗｅｂサーバ１０の制御部１０３１は、チケット１７１とともにＩＤ登録要求（図１７−ステップ１７０５）をネットワーク１４を介して中継サーバ１２へ送信するようにする。しかし、この場合、再利用したチケットが他人に盗まれた場合、容易に成りすまし登録ができてしまう。そのため、チケットの厳重な管理を要求する、あるいはチケットに有効期限を設定し、成りすまし登録のリスクを軽減する等の配慮が必要となる。
【００６４】
他のＩＤ登録方法として、異なる連携ユーザＩＤで登録された同一ユーザのレコードがあった場合に、ＩＤ仮登録処理（図１７−ステップ１７０６）またはＩＤ登録処理（図１８−ステップ１８０７）で衝突が発生するレコードの連携ユーザＩＤを書き換える方法がある。このＩＤ登録方法方法を、図２１および図２２を用いて説明する。図２１および図２２は、次のような手順でＩＤ登録を行った際の同一ユーザ情報データベース９０３の登録状態を示す図である。なお、図２１に示すように、説明の便宜上、ユーザＩＤおよびＷｅｂサーバへのＵＲＬをＵＲＬ１、ＩＤ１など簡易化して用いる。図２１に示すネットワークシステムは、中継サーバ１２、５台のＷｅｂサーバ（２２０１、２２０２、２２０３、２２０４、２２０５）がネットワーク１４に接続されて構成されるシステムであり、２回のＩＤ登録が行われた結果が示されている。一回目のＩＤ登録はＷｅｂサーバ２２０１を第一のＷｅｂサーバ、Ｗｅｂサーバ２２０２を第二のＷｅｂサーバとして登録し、二回目のＩＤ登録はＷｅｂサーバ２２０３を第一のＷｅｂサーバ、Ｗｅｂサーバ２２０４を第二のＷｅｂサーバとして登録している。この場合、同一ユーザ情報データベース９０３に記憶されるデータ内容は、図２２に示す通りとなる。ここで、Ｗｅｂサーバ２２０５を第一のＷｅｂサーバとして登録し、Ｗｅｂサーバ２２０１〜２２０４の何れか一つをＷｅｂサーバ１１として登録するケースを考える。Ｗｅｂサーバ２２０５をＩＤ仮登録（図１７−ステップ１７０６）すると、ＵＲＬ１５０２が「ＵＲＬ５」であり、かつユーザＩＤ３０１が「ＩＤ５」であるレコードは存在しないため、新規に連携ユーザＩＤ１５０１が発行される。新規に発行された連携ユーザＩＤを仮に「ＩＤＦ５」とする。次に、例えば、第二のＷｅｂサーバとしてＷｅｂサーバ２２０１を登録しようとすると、ＩＤ登録（図１８−ステップ１８０７）の際に、ＵＲＬ１５０２が「ＵＲＬ１」であり、かつユーザＩＤ３０１が「ＩＤ１」であるレコードが1行目に見つかるため、「ＩＤＦ1」と「ＩＤＦ５」は同一の本人を表す連携ユーザＩＤであることがわかる。この場合、「ＩＤＦ５」を既に登録済みの「ＩＤＦ１」に書き換えることにより、連携ユーザＩＤが「ＩＤＦ1」であるレコードは３件になり、Ｗｅｂサーバ２２０１とＷｅｂサーバ２２０２とＷｅｂサーバ２２０５のＩＤ連携ができる。
【００６５】
また、Ｗｅｂサーバ２２０３を第一のＷｅｂサーバとして登録し、Ｗｅｂサーバ２２０５を第二のＷｅｂサーバとして登録するケースを考える。この場合、ＩＤ仮登録（図１７-ステップ１７０６）の際にＵＲＬ１５０２が「ＵＲＬ３」で、かつユーザＩＤ３０１が「ＩＤ３」であるレコードが見つかり、その連携ユーザＩＤが「ＩＤＦ３」のため、チケット１７１には連携ユーザＩＤとして「ＩＤＦ３」が書き込まれる。この場合、ＩＤ登録（図１８−ステップ１８０７）の際は「ＩＤＦ３」「ＵＲＬ５」「ＩＤ５」のペアが登録され、Ｗｅｂサーバ２２０３とＷｅｂサーバ２２０４とＷｅｂサーバ２２０５のＩＤ連携ができる。
【００６６】
さらに、Ｗｅｂサーバ２２０１を第一のＷｅｂサーバとして登録し、Ｗｅｂサーバ２２０３を第二のＷｅｂサーバとして登録するケースを考える。この場合、ＩＤ仮登録（図１７−ステップ１７０６）の際に連携ユーザＩＤが「ＩＤＦ１」であることが分かり、ＩＤ登録（図１８−ステップ１８０７）の際、連携ユーザＩＤ「ＩＤＦ３」と「ＩＤＦ１」が一致していることが分かる。そこで、「ＩＤＦ３」を「ＩＤＦ１」で書き換えると、Ｗｅｂサーバ２２０１とＷｅｂサーバ２２０２とＷｅｂサーバ２２０３とＷｅｂサーバ２２０４のＩＤ連携ができる。
【００６７】
このような登録処理を続けていくことで、いずれすべてのＷｅｂサーバ間でのＩＤ連携が完成する。
(他の実施形態４)
Ｗｅｂサーバ１０、１１以外の他のＷｅｂサーバで再認証を受ける場合にも、本発明を適用可能である。Ｗｅｂサーバ１０で通常の認証処理を受け、Ｗｅｂサーバ１１で再認証を受けた後、さらに他のＷｅｂサーバで再認証を受けるためにはＷｅｂサーバ１０から中継サーバ１２経由で他のＷｅｂサーバへ認証済みメッセージを送信する。ただし、Ｗｅｂサーバ１０での最後の操作からある程度時間がたった後に他のＷｅｂサーバで再認証を受けようとすると、Ｗｅｂサーバ１０ではタイムアウトが発生し認証結果が無効となっているケースもある。したがって、この場合は、Ｗｅｂサーバ１０で再度認証を受けた後に他のＷｅｂサーバで再認証を受けるか、Ｗｅｂサーバ１１で認証を受け他のＷｅｂサーバで再認証を受けるか、他のＷｅｂサーバで認証を受けるか、何れかの処理が必要となる。
(他の実施形態５)
上記実施形態では、ユーザ認証情報としてユーザＩＤとパスワードを例にとり説明したが、特に秘密情報についてはパスワード以外にワンタイムパスワードやＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）電子証明書等を使うことも可能である。どのような秘密情報を使うか、秘密情報をＩＣカード内に格納するのか等の運用条件は、ユーザ認証情報運用ポリシファイル２１１に記載される。
(他の実施形態６)
上記実施形態では、図１１において、Ｗｅｂサーバ１１での再認証結果（ステップ１１１２）が直接ユーザ端末１３にする場合を説明したが、中継サーバ１２あるいはＷｅｂサーバ１０を介してユーザ端末１３に送信するようにしても良い。
(他の実施形態７)
上記実施形態では、図１９において、第二のユーザＩＤの登録有無を確認し、登録有りの場合にユーザの再認証を行うようにしたが、ユーザの再認証を行い、再認証が成功した場合に、第二のユーザＩＤの登録有無を確認するようにしても良い。
(他の実施形態８)
上記実施形態では、認証済みメッセージ（図１３）のユーザＩＤ１３０２には、第一のユーザＩＤまたは第二のユーザＩＤの何れか一方を記載する場合を説明したが、第一のユーザＩＤと第二のユーザＩＤの双方とも記載しても良い。ただし、双方のユーザＩＤを記載することは、ユーザＩＤの開示範囲を不用意に広げることになり、ユーザＩＤそのものは秘密情報やプライバシ情報ではないとしてもセキュリティリスクの増大を招く恐れがあるため、通常はどちらか一方のみが記載され、中継サーバ１２において正しくＩＤ付け替えが行われる運用をする。同様に、ＷｅｂサーバのＵＲＬ１３０３は、第一のＵＲＬおよび第二のＵＲＬの双方を記載するのではなく、Ｗｅｂサーバ１０から中継サーバ１２へは第二のＵＲＬのみを、中継サーバ１２からＷｅｂサーバ１１へはＵＲＬを記載せずに認証済みメッセージを送ることも可能である。Ｗｅｂサーバや中継サーバがＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続する上で、接続元ホストのＩＰアドレスやＵＲＬは、自動取得・解決することが可能である。ただし、ＩＰアドレスとＵＲＬの対応関係は必ずしも一対一とは限らないため、第一のＵＲＬおよび第二のＵＲＬを記載した方が好ましい。
(他の実施形態９)
中継サーバ１２に同一ユーザ情報を登録する手順については、中継サーバ１２に対してもユーザ登録を行わせても良い。この場合、中継サーバ１２上でのユーザＩＤが連携ユーザＩＤと同じ効果を持ち、図１７および図１８で示したような、同一ユーザでありながら、同一ユーザ情報データベース９０３上は複数の連携ユーザＩＤを持つという問題は発生しない。また、チケットを発行する必要もない。
【図面の簡単な説明】
【００６８】
【図１】ユーザネットワークシステム１の全体構成例を示す図である。
【図２】Ｗｅｂサーバ１０、１１のハードウェア構成例を示す図である。
【図３】ユーザ認証情報データベース２１０の構成例を示す図である。
【図４】ユーザ認証情報運用ポリシファイル２１１の構成例を示す図である。
【図５】ユーザ認証情報運用記録データベース２１２の構成例を示す図である。
【図６】ユーザ属性情報データベース２１３の構成例を示す図である。
【図７】ユーザ属性情報運用ポリシファイル２１４の構成例を示す図である。
【図８】ユーザ属性情報運用記録データベース２１５の構成例を示す図である。
【図９】中継サーバ１２のハードウェア構成例を示す図である。
【図１０】ユーザ端末１３のハードウェア構成例を示す図である。
【図１１】ユーザネットワークシステム１全体の処理概要示すシーケンス図である。
【図１２】Ｗｅｂサーバ１０において、認証済みメッセージを生成し、これを中継サーバ１２に送信する（図１１−ステップ１１０７、１１０８）詳細処理を示すフローチャートである。
【図１３】認証済みメッセージの構成例を示す図である。
【図１４】ユーザサービス画面例を示す図である。
【図１５】同一ユーザ情報データベース９０３の構成例を示す図である。
【図１６】中継サーバ１２において、第一のユーザＩＤに対応する第二のユーザＩＤを解決し、認証済みメッセージに含まれる第一のユーザＩＤを第二のユーザＩＤに書き換え、この認証済みメッセージをＷｅｂサーバ１１へ送信する（図１１−ステップ１１０９、１１１０）詳細処理を示すフローチャートである。
【図１７】ネットワークシステム１において、中継サーバ１２が具備する同一ユーザ情報データベース９０３に、同一ユーザ情報を登録する処理を示すシーケンス図である。
【図１８】同じく、ネットワークシステム１において、中継サーバ１２が具備する同一ユーザ情報データベース９０３に、同一ユーザ情報を登録する処理を示すシーケンス図である。
【図１９】Ｗｅｂサーバ１１において、Ｗｅｂサーバ１０で認証されたユーザを再認証し、その結果をユーザ端末１３へ送信する（図１１−ステップ１１１１、１１１２）詳細処理を示すフローチャートである。
【図２０】他の実施形態によるネットワークシステム１全体における処理概要を示すシーケンス図である。
【図２１】同一ユーザ情報データベース９０３にユーザＩＤおよびＷｅｂサーバへのＵＲＬを登録する処理の他の実施形態を説明するための図である。
【図２２】同じく、同一ユーザ情報データベース９０３にユーザＩＤおよびＷｅｂサーバへのＵＲＬを登録する処理の他の実施形態を説明するための図である。
【符号の説明】
【００６９】
１０  Ｗｅｂサーバ
１１  Ｗｅｂサーバ
１２  中継サーバ
１３  ユーザ端末
１４  ネットワーク
【図１】
2010086435.tif 000003
【図２】
2010086435.tif 000004
【図３】
2010086435.tif 000005
【図４】
2010086435.tif 000006
【図５】
2010086435.tif 000007
【図６】
2010086435.tif 000008
【図７】
2010086435.tif 000009
【図８】
2010086435.tif 000010
【図９】
2010086435.tif 000011
【図１０】
2010086435.tif 000012
【図１１】
2010086435.tif 000013
【図１２】
2010086435.tif 000014
【図１３】
2010086435.tif 000015
【図１４】
2010086435.tif 000016
【図１５】
2010086435.tif 000017
【図１６】
2010086435.tif 000018
【図１７】
2010086435.tif 000019
【図１８】
2010086435.tif 000020
【図１９】
2010086435.tif 000021
【図２０】
2010086435.tif 000022
【図２１】
2010086435.tif 000023
【図２２】
2010086435.tif 000024