JP2011128731A - 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム - Google Patents

Abstract

【課題】異なるドメインに設置されたＳＰ間で負荷分散を行い、かつ、利便性を高めるために認証をＳＰ間で連携する必要があるが、従来技術では対応することができないという課題がある。
【解決手段】上記課題を解決するために本発明に係る認証連携負荷分散技術は、予め記憶している利用者の認証情報を用いて利用者の認証処理を行い、利用者の認証結果が許可だった場合に、信頼ドメイン情報とサービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定する。
【選択図】図３

Description

本発明は、複数のサービス提供装置において、認証結果を連携すると同時に、サービス提供装置間の負荷分散を行う認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラムに関する。

従来の認証連携技術は、利用者の認証を行い、認証結果や認可情報（以下「認証結果等」という）を管理者や利用者が指定したサービス提供装置（以下「ＳＰ」（Service Provider）という）へ提供するシングルサインオン機能を有している。シングルサインオンの仕組みを規定する代表的な技術仕様として、非特許文献１記載のＳＡＭＬ２．０や非特許文献２記載のＯｐｅｎＩＤ等がある。この認証連携技術においては、複数のサービス間で認証情報をやりとりする。

また、非特許文献３が従来の負荷分散技術として知られている。負荷分散技術とは、サーバへのアクセス集中によるレスポンスの低下を防ぎ、動的に複数サーバへ配信する処理を行う技術である。なお、サーバとはネットワークを介して他の端末からの要求に答えることができる端末であり、端末とはアプリケーションを実行する装置であり、端末毎に端末が有する機能が異なる。また、アプリケーションとは、任意の利用者の要求に答えるソフトウェアである。負荷分散システムを用いることで、サーバの拡張性の向上や、ＤｏＳ攻撃などへの耐性を高めることができる。なお、負荷分散システムとは、外部ネットワークからの要求を一元的に管理し、同等の機能を持つ複数のサーバに要求を転送する装置である。

また、認証セッションを継承し負荷分散を行う従来技術として、特許文献１も検討されている。

特開２００９−２２３６７４号公報

"Online community for the Security Assertion Markup Language （SAML） OASIS Standard", [online], OASIS , [平成21年11月30日検索],インターネット<URL: http://saml.xml.org/> "OpenID",[online], 2006年, OpenID Foundation,[平成21年12月3日検索],インターネット<URL: http://openid.net/ > "負荷分散入門",第2回 負荷分散装置の基本機能,[online], 2004年8月3日, 富士通株式会社,[平成21年11月30日検索],インターネット<URL: http://fenics.fujitsu.com/products/ipcom/catalog/data/1/2.html >

しかしながら、特許文献１記載の従来技術は異なるドメインに存在するＳＰ間で、負荷分散を行うことができないという問題がある。なお、ドメインとはインターネット上に存在するコンピュータやネットワークの識別された領域、または領域を識別する名称である。

Ａｊａｘ（Asynchronous Java（登録商標）Script + XML）やマッシュアップといったＷｅｂ２．０技術は、Ｗｅｂにおける基盤技術として、コンシューマー向けサービスや企業内で用いるビジネスアプリケーションなどでの利用が進んでいる。このようなＷｅｂ２．０技術によってソフトウェアをサービスとして提供するＳａａＳ（Software as a Service）も浸透してきている。なお、ＳａａＳとは、ソフトウェア機能を利用者が所有することなく、ネットワークを介してサービスとして利用できるようにしたソフトウェアの提供形態である。また、ＳａａＳで提供されるアプリケーションを利用する際には、利用者の認証が行われるが、これらのアプリケーションを組合せて利用するマッシュアップにおいては、相互運用性や信頼性を高めるために、認証を連携させる必要がある。さらに、ＳａａＳの普及によってアプリケーションが大規模化すると、拡張性や可用性、保守性確保の観点から複数のインフラ上で提供されることも想定される。今後、インタークラウド等の普及に伴い（参考文献１参照）、異なる運用事業者によって運営される異なるドメインに設置されたＳＰ間で負荷分散を行い、かつ、利便性を高めるために認証をＳＰ間で連携する必要があるが、従来技術では対応することができない。
参考文献１：[online]、2009、グローバルクラウド基盤連携技術フォーラム、[平成２１年１２月２日検索]、インターネット＜URL: http://www.gictf.jp/activities.html＞

上記の課題を解決するために、本発明に係る認証連携負荷分散システムは、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置とからなる。ＳＰは、利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）に、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認し、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、認証連携負荷分散装置にサービス要求情報を転送する認証許可確認部と、認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備える。認証連携負荷分散装置は、利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）と信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）を記憶する記憶部と、信頼ドメイン内に存在するＳＰの負荷情報を収集する負荷情報収集部と、認証情報を用いて利用者の認証処理を行う認証部と、利用者の認証結果が許可だった場合に、ＳＰが当該認証連携負荷分散装置にサービス要求情報を転送する際にそのサービス要求情報に付加される転送元ドメインと記憶部が記憶する信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、そのＳＰが信頼ドメイン内に存在する場合に、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定するＳＰ決定部と、を備え、ＳＰ決定部は、認証許可情報を生成し、決定されたＳＰと利用者端末に認証許可情報を送信する。

上記の課題を解決するために、本発明に係る認証連携負荷分散装置は、利用者の認証処理を行い、かつ、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）の中から利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる。利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）と信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）を記憶する記憶部と、信頼ドメイン内に存在するＳＰの負荷情報を収集する負荷情報収集部と、認証情報を用いて利用者の認証処理を行う認証部と、利用者の認証結果が許可だった場合に、利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）をＳＰが当該認証連携負荷分散装置に転送する際にそのサービス要求情報に付加される転送元ドメインと記憶部が記憶する信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、そのＳＰが信頼ドメイン内に存在する場合に、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷を示す値が所定値よりも低いＳＰを利用者端末の要求に応答するＳＰとして決定するＳＰ決定部と、を備え、ＳＰ決定部は、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、決定されたＳＰと利用者端末に認証許可情報を送信する。
上記の課題を解決するために、本発明に係るサービス提供装置は、認証連携負荷分散装置によって、利用者に対しサービスを提供するＳＰとして決定され、利用者端末にアクセスされる。利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）に、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認し、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、認証連携負荷分散装置にサービス要求情報を転送する認証許可確認部と、認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備える。異なるドメインに存在する他のサービス提供装置からサービス要求情報を転送された場合、認証許可情報を認証連携負荷分散装置に送信し、認証連携負荷分散装置が、サービスを要求する利用者に関する情報（以下、「サービス状態」という）の転送を許可することを示す情報（サービス情報転送許可情報）を認証連携負荷分散装置から受け取り、サービス状態を有するサービス提供装置に対し、サービス情報転送許可情報を付加してサービス状態の転送を要求し、異なるドメインに存在する他のサービス提供装置へサービス要求情報を転送する場合、サービス情報転送許可情報を用いて、サービス状態の転送要求が正当であることを確認し、要求されたサービス状態を転送する。

上記の課題を解決するために、請求項６に係る認証連携負荷分散方法は、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置を用いる。認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、ＳＰが、利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を受け取るステップと、ＳＰが、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認する認証許可確認ステップと、サービス要求情報に、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、ＳＰが認証連携負荷分散装置にサービス要求情報を転送するステップと、認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、利用者の認証結果が許可だった場合に、認証連携負荷分散装置が、ＳＰが当該認証連携負荷分散装置にサービス要求情報を転送する際に、そのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、そのＳＰが信頼ドメイン内に存在する場合に、認証連携負荷分散装置が、信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）とサービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、認証連携負荷分散装置が、認証許可情報を生成し、決定されたＳＰと利用者端末に認証許可情報を送信するステップと、サービス要求情報に、認証許可情報が付加されている場合に、ＳＰが利用者端末に対し、サービスを提供するサービス提供ステップと、を備える。

上記の課題を解決するために、請求項７に係る認証連携負荷分散方法は、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置を用いる。認証連携負荷分散装置が、当該認証連携負荷分散装置とにあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、認証連携負荷分散装置が、利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を受け取るステップと、認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、認証連携負荷分散装置が、利用者の認証結果が許可だった場合に、信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）とサービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、認証連携負荷分散装置が、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、決定されたＳＰと利用者端末に認証許可情報を送信するステップと、ＳＰが、サービス要求情報に、認証許可情報が付加されているか否か確認する認証許可確認ステップと、サービス要求情報に、認証許可情報が付加されている場合に、ＳＰが利用者端末に対し、サービスを提供するサービス提供ステップと、を備える。

上記の課題を解決するために、請求項９に係る認証連携負荷分散方法は、利用者の認証処理を行い、かつ、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）の中から利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる。この方法を実施する装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、利用者の認証結果が許可だった場合に、利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）をＳＰが転送する際にそのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、そのＳＰが信頼ドメイン内に存在する場合に、信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）とサービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、認証連携負荷分散装置が、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、決定されたＳＰと利用者端末に認証許可情報を送信するステップを備える。

本発明は、認証の結果と負荷分散を連動させることによって、異なる運用事業者によって運営される異なるドメインに設置されたＳＰ間で負荷分散を行い、かつ、利便性を高めるために認証をＳＰ間で連携することができるという効果を奏する。

（Ａ）は負荷分散前の従来技術を、（Ｂ）は負荷分散処理後の従来技術を示す図。 認証連携負荷分散システム１０００の構成例を示す図。 認証連携負荷分散装置１００の構成例を示す図。 ＳＰ２００（２００Ａ及び２００Ｂ）の構成例を示す図。 認証連携負荷分散システム１０００のシーケンス図。 図５の処理の続きを示す図。 認証連携負荷分散装置１００の処理フロー例を示す図。 使用情報のデータ例を示す図。 信頼ドメイン情報のデータ例を示す図。 （Ａ）は記憶部１０３が記憶する認証情報（ユーザＩＤ、ユーザＰＷ）の、（Ｂ）は認可情報（利用可能なサービスやドメイン）の、（Ｃ）は属性情報（利用者権限、優先順位、住所）のデータ例を示す図。 転送関係情報のデータ例を示す図。 負荷情報のデータ例を示す図。 本実施例における認証連携負荷分散装置１００のハードウェア構成を例示したブロック図。 ＳＡＭＬを用いて認証済みの利用者端末１０を負荷情報に基づいて負荷が高いＳＰから負荷が低いＳＰへ転送する際のシーケンス図。 ＯｐｅｎＩＤを用いて、認証済みの利用者端末１０を負荷情報に基づいて負荷が高いＳＰから負荷が低いＳＰへ転送する際のシーケンス図。 あるドメイン内のＳＰが有するサービス状態を他のドメインのＳＰに転送する場合のシーケンス図。 信頼関係情報のデータ例を示す図。 拡張した使用情報のデータ例を示す図。 データ格納情報のデータ例を示す図。 認証連携負荷分散装置３００の構成例を示す図。 認証連携負荷分散システム２０００のシーケンス図。

［従来技術の組合せ］
従来の認証装置（以下「ＩＤＰ」（Identity Provider）という）と負荷分散装置（以下「ＬＢ」（Load Balancer）という）を用いて、認証及び負荷分散をする方法について図１を用いて説明する。図１の（Ａ）は負荷分散前の従来技術を、（Ｂ）は負荷分散処理後の従来技術を示す。ＩＤＰとＬＢがそれぞれ別々に運用されている場合、異なるドメイン間で他のドメインの情報を保持していないため、それぞれのドメイン上のＳＰでログイン処理が必要になる。

利用者の操る利用者端末１０のブラウザは、ドメインＡ内のＬＢ１４０Ａに対してサービスを要求する（１）。ＬＢ１４０Ａは、まずＩＤＰ１３０との間で利用者の認証処理を行う（２）。認証の結果、許可されれば、ＬＢ１４０Ａは、要求されたサービスを提供するＳＰ２００Ａに対する負荷情報を取得する（３）。

ＬＢ１４０Ａは、負荷情報に基づき、ＳＰ２００Ａに処理を行わせるべきか判断し、高負荷であると判断した場合には、他のサービス提供装置２００Ｂに負荷を分散するため、ＬＢ１４０Ｂへサービス要求を転送する（４）。ＬＢ１４０Ｂは、ＬＢ１４０Ａと同様に、ＩＤＰ１３０との間で利用者の認証処理を行い（５）、認証の結果、許可されれば、ＳＰ２００Ｂに対する負荷情報を取得する（６）。ＬＢ１４０Ｂは、負荷情報に基づき、ＳＰ２００Ｂに処理を行わせるべきか判断し、低負荷であると判断した場合には、ＳＰ２００Ｂがサービスを提供するように指示し、ＳＰ２００Ｂはサービスを提供する（７）。

なお、ＬＢ１４０ＡとＩＤＰ１３０の間で認証処理を行っているが、ドメインが異なるため、この認証結果をＬＢ１４０Ｂに引き継ぐことはできない。例えば、異なる複数の運用事業者によって運営される異なるドメインに設置されたＳＰ間で認証システムを連携させるためには、ＳＰは認証システムから得た認証結果等を明示的にやりとりする仕組みをサービスに実装する必要がある。しかし、異なる運用事業者間でこのような仕組みを共有することは負担が大きいと考えられる。また、異なる運用事業者間で認証結果等を伝達する場合には、余分な負荷（データ量）が大きくなる。

また、負荷分散システムは負荷の分散に特化しているため、認証結果等を含めて、異なるドメインに転送するためには、ＳＰの正当性や利用者の正当性の両方を確認する必要があり、アクセスポリシを管理する点においても障壁が高い。さらに、各ＬＢは、配置されたドメイン内のＳＰの負荷情報しか取得できないため、転送に際して、ＳＰ２００Ｂの負荷状態を知ることはできない。そのため、利用者端末１０のサービス要求はＬＢ１４０Ｂで転送された後も、サービスを受けることができない事態も生じうる。

以下、本発明の実施の形態について、詳細に説明する。

本発明は、認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）が異なる複数のＳＰ間において、利用者の認証を行うプロセスと同時に認認証連携負荷分散装置が複数のＳＰ間の負荷を監視し、負荷の低いＳＰへ利用者を転送する。なお、例えば、信頼ドメインとは、認証連携負荷分散装置の運用者と高い信頼関係にある運用者が運営するドメイン等である。

本発明の一実施形態として、あるサービスを運用する際に、クラウドコンピューティング(以下、クラウド)と呼ばれるサービス基盤上で運用する形態がある。クラウドとは、インフラリソースやアプリケーションなどのコンピュータ資源・機能を、ネットワークを介して利用する形態であり、ネットワーク上に存在するサーバが提供するサービスを、それらのサーバ群を意識することなく利用できるコンピューティング形態を表す。ネットワークを図示するのに雲状の絵を使うことが多いことに由来している。雲の中にはハードウェアやソフトウェアの実体があるが、その中身を意識することなく利用できる。このようなクラウドは多くのクラウド提供業者によって提供されており、サービスの冗長性確保や可用性維持のために複数のクラウド提供事業者を利用するケースが想定できる。一つのサービスが複数のクラウド提供事業者によって提供される場合、複数のドメインを信頼ドメインとして認証連携負荷分散装置が管理し、利用者のサービス要求によって遷移先のＳＰを決定する。
［認証連携負荷分散システム１０００］
図２は認証連携負荷分散システム１０００の構成例を示す。図２を用いて実施例１に係る認証連携負荷分散システム１０００を説明する。認証連携負荷分散システム１０００は、異なるドメインに存在する２以上のＳＰ（例えば、２００Ａ、２００Ｂ）と、利用者の認証処理を行い、かつ、利用者端末１０から要求されるサービスを提供するＳＰを決定し、利用者端末１０を、決定したＳＰにアクセスさせる認証連携負荷分散装置１００とからなる。

まず認証連携負荷分散システム１０００の概要を説明する。利用者は利用者端末１０を操作して、ドメインＡ上で運用されているあるＳＰ２００Ａに対してサービスを要求する（１）。ＳＰ２００Ａは、認証処理及び負荷分散処理を行うために、認証連携負荷分散装置１００へ利用者端末１０を転送する（２）。認証連携負荷分散装置１００は、利用者の認証処理を行う（３）。また、認証連携負荷分散装置１００は信頼ドメインＡ、Ｂ上のＳＰ２００Ａ、２００Ｂの負荷状況を監視する（４）。認証連携負荷分散装置１００は、認証許可情報を負荷が低いＳＰ（例えばＳＰ２００Ｂ）に送信する（５）。その後、利用者端末１０は、負荷の低いＳＰに転送される（６）。負荷の低いＳＰは、利用者端末１０にサービスを提供する（７）。このとき、ドメインＡとドメインＢはそれぞれ異なる信頼ドメインであり、異なる運用事業者間でサービスが提供されていてもよい。

図３は認証連携負荷分散装置１００の構成例を、図４はＳＰ２００（２００Ａ及び２００Ｂ）の構成例を、図５は認証連携負荷分散システム１０００のシーケンス図を、図６は図５の処理の続きを、図７は認証連携負荷分散装置１００の処理フロー例を示す。なお、認証連携負荷分散装置１００、ＳＰ２００は図示しない通信部を有し、これを介して、他の装置と通信する構成であってもよい。通信部は、例えば、ＬＡＮアダプタ等により構成され、ＬＡＮやインターネット等からなる通信回線と接続される。
（１）サービス要求
利用者端末１０（例えば、パーソナルコンピュータ等）は、利用者によって操作され、当該利用者端末１０上にインストールされるＷｅｂブラウザ等を介して、ドメインＡ上のＳＰ２００Ａに対し、サービスを要求する（ｓ１１）。
（２）利用者転送
ＳＰ２００は、利用者端末１０が要求するサービスに関する情報（以下「サービス要求情報」という）を受け取る。認証許可確認部２１１は、サービス要求情報に認証許可情報が付加されているか否かを確認し、認証連携負荷分散装置１００によって生成された認証許可情報が付加されていない場合には、利用者端末１０に対し、認証連携負荷分散装置１００のＵＲＬ、転送元ドメイン、認証処理要求メッセージ、転送要求を送信する。その際、利用者端末に対し、サービス要求情報に転送元ドメイン（例えば、この場合「ドメインＡ」）と認証処理要求メッセージを付加して、認証連携負荷分散装置１００にアクセスするように指示する（ｓ２１４）。なお、認証許可情報とは、例えば、後述するトークンやセッションＩＤ２等である。

利用者端末１０は、指示に従い、サービス要求情報に認証処理要求メッセージと転送元ドメインを付加して認証連携負荷分散装置１００にアクセスする（ｓ１３）。なお、サービス要求情報、認証処理要求メッセージ、転送元ドメインに対する改竄を検知するための情報として改竄検知情報（例えば、電子署名等）を付加する構成としてもよい。
（３）認証処理
認証連携付加分散装置１００は、サービス要求情報を受け取り（ｓ１０１ａ）、認証部１１３において、認証情報を用いて利用者の認証処理を行う。

なお、認証連携負荷分散装置１００は、転送元ドメイン等に改竄検知情報が付加されている場合には、改竄検知情報に基づき転送元ドメイン等に改竄等がなされていないか確認する。改竄が検知された場合には、エラー処理を行う。例えば、利用者端末１０に対し、転送元ドメイン等と改竄検知情報を再送するように指示する。

図１０（Ａ）は記憶部１０３が記憶する認証情報（ユーザＩＤ、ユーザＰＷ）の、（Ｂ）は認可情報（利用可能なサービスやドメイン）の、（Ｃ）は属性情報（利用者権限、優先順位、住所）のデータ例を示す。認証情報や認可情報、属性情報等は、利用者登録等により作成され、利用に先立ち予め記憶部１０３に記憶しておく。例えば、認証連携負荷分散装置１００は利用者端末１０にユーザＩＤ及びユーザパスワードの入力を要求する（ｓ１１２）。

利用者は、利用者端末１０を操作し、ユーザＩＤ及びユーザパスワードを入力し、認証連携負荷分散装置１００へ送信する（ｓ１５）。認証部１１３は、ユーザＩＤとユーザパスワードを受け取り（ｓ１０１ｂ）、受け取ったユーザＩＤとユーザパスワードと図１０（Ａ）の認証情報を照合して利用者の認証処理を行う（ｓ１１３ａ）。

さらに、図１０（Ｂ）の認可情報と利用者の要求するサービス内容や転送元ドメインを照合して利用者がそのサービスを受ける権限を有しているか否か判断する（以下「認可処理」という）構成としてもよい（ｓ１１３ｂ）。例えば、図１０（Ｂ）の場合、ユーザＩＤ「ｊｉｒｏｈ」は、要求するサービスが（２）である場合やドメインＢが転送元ドメインである場合には、サービスを受ける権限を有しているが、要求するサービスが（１）である場合やドメインＡが転送元ドメインである場合には、サービスを受ける権限を有していない。ユーザＩＤが判明した時点で、認可情報と紐付けて認可処理を行うことができる。

認証処理が完了すると、セッションＩＤ生成部１１４は、この認証情報と関連づけられたセッションＩＤ１を生成する（ｓ１１４）。そして、サービス要求情報とセッションＩＤ１と転送元ドメインの組合せを使用情報として記憶部１０３に記憶する（ｓ１０３ｂ）。図８は、使用情報のデータ例である。このとき、２行目の例のようにセッションＩＤ１と転送元ドメインとサービス内容とユーザＩＤのみが記憶される。但し、セッションＩＤ１を用いず、利用者端末１０と認証連携負荷分散装置１００のアクセスを特定する必要がない場合には、使用情報を記憶部１０３に記憶しなくてもよい。また、上記認証処理は発明の内容を限定するものではなく、他の従来技術を用いて認証処理を行ってもよい。また、認証連携負荷分散システム１０００が１種類のサービスのみ提供するＳＰ群からなる場合には、使用情報やセッションＩＤを用いなくてもよい。

利用者の認証結果（及び認可結果）が許可だった場合に、認証連携負荷分散装置１００の信頼ドメイン確認部１１１は、転送元ドメインと記憶部１０３が記憶する信頼ドメインから、ＳＰ２００Ａが信頼ドメイン内に存在するか否かを確認する（ｓ１１１ａ）。図９は記憶部１０３が記憶する信頼ドメイン情報のデータ例を示す。信頼ドメイン情報は、信頼ドメインと信頼ドメイン内に存在するＳＰの組合せであり、さらに、信頼ドメインの信頼情報や所在地等を含んでもよく、利用に先立ち予め記憶部１０３に記憶される。但し、信頼ドメイン内に存在するＳＰが２以上のサービスを提供する場合には、サービス毎にそのサービスを提供するＳＰの情報を記憶してもよい。なお、信頼情報とは、認証連携負荷分散装置１００と各ＳＰ２００Ａ、２００Ｂ、…の間で秘密に管理される情報であり、各ＳＰは、信頼情報が付加された情報を受信した場合に、その情報の発信源が認証連携負荷分散装置１００であることを確認することができる。

信頼ドメイン確認部１１１は、ＳＰ２００Ａが信頼ドメイン内に存在する場合には、サービス要求情報と信頼ドメイン情報を用いて、利用者端末１０が要求するサービスを転送元のＳＰが提供するか否かを確認する構成としてもよい（ｓ１１１ｂ）。このような構成は、認証連携負荷分散システム１０００が２種類以上のサービスを提供するＳＰ群からなり、ＳＰ毎に提供できるサービスが異なる場合に有用である。

認証結果または認可結果が不許可だった場合や、ＳＰが信頼ドメイン内に存在せず、または、要求するサービスを転送元のＳＰが提供していない場合には、エラー処理を行う（ｓ１９０）。例えば、利用者端末１０に対し、再度ユーザＩＤやユーザパスワードの入力を求めてもよいし、利用者登録画面のリンクを表示してもよい。また、転送元ＳＰに対し、エラーが生じた旨の通知を行ってもよい。

例えば、図９の場合、転送元ドメインがドメインＡ、ドメインＢ、ドメインＤ、…等であれば、ＳＰ２００Ａは信頼ドメイン内に存在するが、転送元ドメインがドメインＣ等の場合には、ＳＰ２００Ａは信頼ドメイン外に存在するものとして、エラー処理を行う（ｓ１９０）。また、転送元のＳＰが２００Ａであり、利用者端末１０がサービス（２）を要求する場合、転送元のＳＰはサービス（２）を提供していないため、エラー処理を行う（ｓ１９０）。
（４）負荷情報取得
ＳＰが信頼ドメイン内に存在し、要求するサービスを転送元のＳＰが提供している場合に、ＳＰ決定部１１５は、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるＳＰを１つ以上選択する（ｓ１１５）。

なお、サービス要求情報と信頼ドメイン情報に加え、転送関係情報を用いている構成としてもよい。図１１は転送関係情報のデータ例を示す。転送関係情報は利用に先立ち、予め記憶部１０３に記憶しておく。転送関係情報は利用者端末１０のサービス要求を取得したドメインが他のドメインに転送できるか否かを表し、例えば、ドメインＢからドメインＡへ利用者端末１０を転送することはできないが、ドメインＢからドメインＤに転送することはできる。転送できない場合には、転送先のドメイン内のＳＰはサービスを提供できないものとみなされる。また、転送関係情報はドメイン間ではなく、ＳＰ間の転送関係を示してもよい。本実施例では、サービス要求情報と信頼ドメイン情報を用いる場合について説明する。

サービスを提供できるＳＰが１つの場合、つまり転送元のＳＰのみの場合には、そのＳＰを利用者端末の要求に応答するＳＰとして決定する。ＳＰが２つ以上の場合には、最適なＳＰを選択する。最適なＳＰを選択する方法の例としては、負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを利用者端末の要求に応答するＳＰとして決定する方法がある（ｓ１１８）。なお、負荷の低いＳＰとは、例えば、選択されたＳＰの中で最も負荷を示す値が低いＳＰや、負荷を示す値が所定値よりも低いＳＰ、また負荷を示す値が所定値よりも低いＳＰが２以上ある場合には、その中からランダムに選択されるＳＰ等である。なお、所定値とは認証連携負荷分散装置１００の記憶部１０３の中に予め記憶されているものである。ＳＰ選択の方法は他にも、利用者装置のネットワークに近いＳＰに転送するなどの方法がある。図１２は負荷情報のデータ例を示す。ＳＰの負荷情報とは、例えば、実行待ちの状態にあるプロセスの単位時間辺りの平均数やメモリ使用量、プロセッサ使用率、ディスクアクセス頻度等である。またドメインの負荷情報（例えば、ネットワークトラフィック）を間接的にそのドメイン内のＳＰの負荷情報として用い、負荷の少ないドメインを選択し、そのドメイン内のＳＰの負荷が少ないものとみなし、選択する構成としてもよい。

負荷情報収集部１１７は、所定のタイミングで、信頼ドメイン内に存在するＳＰの負荷情報を要求し、収集する（ｓ１１７Ａ、ｓ１１７Ｂ）。所定のタイミングとは、例えば、ＳＰ決定部１１５から指示を受けたタイミングや、利用者端末１０からサービス要求情報を受け取ったタイミングや、所定時間が経過したタイミング（例えば５分毎）等である。

図１０（Ｃ）は利用者の属性情報のデータ例を示す。信頼ドメイン情報として信頼ドメインの所在地を記憶している場合であって、利用者の属性情報として利用者の住所を記憶している場合や使用情報として送信元（利用者端末１０）の（図示していない）ＩＰアドレス等を記憶している場合には、負荷情報収集部１１７は、記憶部１０３からこれらの情報を収集し、その信頼ドメインと、利用者の住所または利用者端末１０との距離を負荷情報として求める構成としてもよい。アクセス後に信頼ドメインと利用者の住所または利用者端末１０との距離が変わらない場合には、所定のタイミングは、最初のアクセス時や認証処理後としてもよい。

各ＳＰは、負荷情報要求を受け取ると、負荷情報生成部２１５で負荷情報を生成し、認証連携負荷分散装置１００へ送信する（ｓ２１５Ａ、ｓ２１５Ｂ）。但し、ドメインの負荷情報（例えば、ネットワークトラフィック）を間接的にそのドメイン内のＳＰの負荷情報として用いる場合には、負荷情報生成部２１５をＳＰ内に設けずに、ドメイン内のネットワーク上に設けてもよい。

レスポンスタイム（認証部１１３がユーザＩＤ及びユーザパスワードを受け取ってから、ＳＰ決定部１１５が負荷情報を受け取るまでの時間）を短くしたい場合には、ＳＰ決定部１１５から指示を受けたタイミングや、利用者端末１０からサービス要求情報を受け取ったタイミングとは無関係に所定時間毎に、負荷情報収集部１１７が管理する全てのＳＰの負荷情報を収集し、記憶部１０３に記憶しておき、認証処理後にＳＰ決定部１１５が、記憶部１０３から負荷情報を取り出す構成としたほうがよい。

サービス要求が少ない場合には、効率的に負荷情報を収集するために、ＳＰ決定部１１５から指示を受けたタイミングや、利用者端末１０からサービス要求情報を受け取ったタイミングで、負荷情報収集部１１７が要求されるサービスを提供できるＳＰのみの負荷情報を収集する構成としてもよい。

また、例えば、負荷情報を収集できなかったＳＰは、装置の故障または高負荷の状態であるとみなして、サービス提供できない状態にあると判断し、負荷情報を収集できたＳＰのみを、ＳＰの選択対象としてもよい。

但し、上記負荷分散方法は発明の内容を限定するものではなく、他の従来技術を用いて負荷分散を行ってもよい。このような構成とすることによって、認証情報や認可情報、属性情報等と負荷情報及び信頼ドメイン情報を結びつけてＳＰを決定することができる。
（５）認証許可情報等送信
ＳＰを決定後、ＳＰ決定部１１５は、認証許可情報としてトークンを作成し、トークンを決定したＳＰ（例えば、ＳＰ２００Ｂ）に送信する（ｓ１１９Ｂ）。トークンは認証結果が許可を表す場合のみ作成されるため、これを受け取った場合には、認証結果が許可であることが明らかである。

但し、記憶部１０３が信頼情報を記憶している場合には、ＳＰ決定部１１５は、トークンに信頼情報を付加する構成としてもよい。また、図１０（Ｂ）の認可情報や、（Ｃ）の属性情報等を付加する構成としてもよい。さらに、ユーザＩＤや信頼ドメイン情報等を付加する構成としてもよい。さらに、トークンと信頼情報等に対する改竄を検知するための情報として改竄検知情報（例えば、電子署名等）を付加する構成としてもよい。

なお、本実施例では、転送元ＳＰと転送先ＳＰが異なっているが、同一の場合であっても同様の処理を行えばよい。
（６）利用者転送
一方、ＳＰ決定部１１５は、利用者端末に対し、トークンに決定したＳＰのＵＲＬを付加して送信する（ｓ１２０）。その際、利用者端末１０に対し、サービス要求情報に、トークンを付加して決定したＳＰにアクセスするように指示する。なお、記憶部１０３は、各ＳＰのＵＲＬを信頼ドメイン情報として記憶してもよいし、別途ＳＰ情報として記憶してもよい。

利用者端末１０は、この指示に従い、サービス要求情報にトークンを付加して決定したＳＰにアクセスする（ｓ１７）。
（７）サービス提供
決定したＳＰ（例えば、ＳＰ２００Ｂ）は、認証連携負荷分散装置１００からトークンを受け取り記憶部２０３に記憶する。さらに、決定したＳＰは、利用者端末１０からサービス要求情報を受け取る。認証許可確認部２１１は、サービス要求情報にトークンが付加されているか否かを確認する（ｓ２１１）。つまり、記憶部１０３が記憶している認証連携負荷分散装置１００から受け取ったトークンとサービス要求情報に付加されているトークンが同一か否か判定し、同一の場合には、サービス要求情報に付加されたトークンが認証許可情報であると判断する。異なる場合には、エラー処理を行う。例えば、利用者端末に対し、サービス要求情報の再送を要求する。

サービス提供部２１９は、サービス要求情報に対し認証連携負荷分散装置１００が生成した認証許可情報（例えば、トークン）が付加されている場合には、利用者端末に対し、サービスを提供する（ｓ２１７）。

認証連携負荷分散装置１００からのトークンに改竄検知情報が付加されている場合には、改竄検知部２１７が、トークン等に改竄等がなされていないか確認する構成としてもよい。改竄が検知された場合には、エラー処理を行う。例えば、認証連携負荷分散装置１００に対し、トークン等の再送を要求する。

認証連携負荷分散装置１００からのトークンに信頼情報が付加されている場合には、転送元検証部２１８が、予め記憶部２０３に記憶しておいた信頼情報と、トークンに付加されている信頼情報が同一か否か検証する構成としてもよい。同一の場合には、そのトークンの発信源が認証連携負荷分散装置１００であるものとして処理を行う。異なる場合には、転送元が認証連携負荷分散装置１００ではないと判断し、エラー処理を行う。例えば、認証連携負荷分散装置１００に対し、トークン等の再送を要求する。このような構成により、認証連携負荷分散装置１００のなりすまし等を防止することができる。

認証連携負荷分散装置１００からのトークンに属性情報の優先順位が付加されている場合には、その優先順位に従って、サービスを提供する構成としてもよい。決定されたＳＰの記憶部２０３はトークンと優先順位を紐付けて記憶する。さらに、決定されたＳＰは、利用者端末１０からトークン付のサービス要求情報を受け取り、認証許可確認部２１１でトークンを照合し、同一の場合には、トークンに紐付けられた優先順位を取得する。例えば、複数の利用者端末１０からのサービス要求情報を受信し、サービス提供部２１９において、サービス待ち状態が発生している場合であっても、先に待ち状態となっていた低い優先順位に対応するトークンを付加されたサービス要求情報よりも、高い優先順位に対応するトークンを付加されたサービス要求情報に対し、早くサービスを提供する。

認証連携負荷分散装置１００からのトークンに認可情報や属性情報の利用者権限が付加されている場合には、最初のサービス要求情報で要求していたサービス内容と異なるサービス内容であっても、その認可情報や利用者権限に従って、サービスを提供する構成としてもよい。

認証許可確認部２１１は、サービス要求情報にトークンが付加されていると判断した場合に、セッションＩＤ生成部２１３にセッションＩＤ２を生成するように指示し、サービス提供部２１９にサービスを提供するように指示する構成としてもよい。セッションＩＤ生成部２１３は、指示に従って、セッションＩＤ２を生成し（ｓ２１３Ｂ）、トークンとセッションＩＤ２を紐付けて記憶部２０３に記憶する。サービス提供部２１９は、サービス情報にセッションＩＤ２を付加して利用者端末１０に送信する（ｓ２１７）。その際に、利用者端末１０に対し、以後サービス要求情報にセッションＩＤ２を付加するように指示する。

利用者端末１０は、指示に従って、サービス要求情報にセッションＩＤ２を付加して決定したＳＰにアクセスする（ｓ１７−２）。決定したＳＰでは認証許可確認部２１１は、サービス要求情報に付加されたセッションＩＤ２と、記憶部２０３が記憶するトークンと紐付けられたセッションＩＤ２が同一であるか否かを確認し、同一の場合には、サービス要求情報に付加されたセッションＩＤ２が認証許可情報であると判断し、サービス提供部２１９に対し、サービスを提供するように指示する。サービス提供部２１９は、サービス情報にセッションＩＤ２を付加して利用者端末１０に送信する（ｓ２１７−２）。以後、同様にセッションＩＤ２を用いて、サービスの要求と提供が行われる。
＜効果＞
このような構成とすることによって、大規模システム向けの過負荷制御技術と、セキュリティ分野の認証技術という異なる技術分野を組合せることでき、認証ステップと負荷分散のステップを同時に実施することにより、複数の信頼ドメインにまたがる負荷分散を安全に実施し、高可用性を同時に確保することができる。また、ＳＰは認証結果や認可情報を明示的にやりとりする仕組みをサービスに実装せずに、認証連携負荷分散装置１００の指示に従って、サービスを提供することができ、システム全体の信頼性を向上させ、システム実装における負担を軽減することができる。さらに、利用者は異なるドメインに転送される際にも再ログインをせずにサービスを受けることができる。
＜ハードウェア構成＞
図１３は、本実施例における認証連携負荷分散装置１００のハードウェア構成を例示したブロック図である。図１３に例示するように、この例の認証連携負荷分散装置１００は、それぞれＣＰＵ（Central Processing Unit）１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ（Read Only Memory）１５、ＲＡＭ（Random Access Memory）１６及びバス１７を有している。

この例のＣＰＵ１１は、制御部１１ａ、演算部１１ｂ及びレジスタ１１ｃを有し、レジスタ１１ｃに読み込まれた各種プログラムに従って様々な演算処理を実行する。また、入力部１２は、データが入力される入力インターフェース、キーボード、マウス等であり、出力部１３は、データが出力される出力インターフェース等である。補助記憶装置１４は、例えば、ハードディスク、半導体メモリ等であり、認証連携負荷分散装置１００としてコンピュータを機能させるためのプログラムや各種データが格納される。また、ＲＡＭ１６には、上記のプログラムや各種データが展開され、ＣＰＵ１１等から利用される。また、バス１７は、ＣＰＵ１１、入力部１２、出力部１３、補助記憶装置１４、ＲＯＭ１５及びＲＡＭ１６を通信可能に接続する。なお、このようなハードウェアの具体例としては、例えば、パーソナルコンピュータの他、サーバ装置やワークステーション等を例示できる。
＜プログラム構成＞
上述のように、補助記憶装置１４には、本実施例の認証連携負荷分散装置１００の各処理を実行するための各プログラムが格納される。認証連携負荷分散プログラムを構成する各プログラムは、単一のプログラム列として記載されていてもよく、また、少なくとも一部のプログラムが別個のモジュールとしてライブラリに格納されていてもよい。
＜ハードウェアとプログラムとの協働＞
ＣＰＵ１１は、読み込まれたＯＳプログラムに従い、補助記憶装置１４に格納されている上述のプログラムや各種データをＲＡＭ１６に展開する。そして、このプログラムやデータが書き込まれたＲＡＭ１６上のアドレスがＣＰＵ１１のレジスタ１１ｃに格納される。ＣＰＵ１１の制御部１１ａは、レジスタ１１ｃに格納されたこれらのアドレスを順次読み出し、読み出したアドレスが示すＲＡＭ１６上の領域からプログラムやデータを読み出し、そのプログラムが示す演算を演算部１１ｂに順次実行させ、その演算結果をレジスタ１１ｃに格納していく。

図３は、このようにＣＰＵ１１に上述のプログラムが読み込まれて実行されることにより構成される認証連携負荷分散装置１００の機能構成を例示したブロック図である。

ここで、記憶部１０３は、補助記憶装置１４、ＲＡＭ１６、レジスタ１１ｃ、その他のバッファメモリやキャッシュメモリ等の何れか、あるいはこれらを併用した記憶領域に相当する。また、信頼ドメイン確認部１１１、認証部１１３、ＳＰ決定部１１５及び負荷情報収集部１１７は、ＣＰＵ１１に認証連携負荷分散プログラムを実行させることにより構成されるものである。
＜変形例１＞
実施例１と異なる部分について説明する。図１４はＳＡＭＬを用いて認証済みの利用者端末１０を負荷情報に基づいて負荷が高いＳＰから負荷が低いＳＰへ転送する際のシーケンス図、図１５はＯｐｅｎＩＤを用いて、認証済みの利用者端末１０を負荷情報に基づいて負荷が高いＳＰから負荷が低いＳＰへ転送する際のシーケンス図である。なお、利用者が利用中のデータの転送を伴わない場合の例を示す。

変形例１の認証連携負荷分散装置１００は、負荷情報を用いて、あるＳＰ（例えばＳＰ２００Ｂ）でサービス利用中の利用者を、他のＳＰ（例えばＳＰ２００Ａ）に転送することができる。

認証連携負荷分散装置１００の負荷情報収集部１１７は、認証済み、言い換えると、サービス提供中（図６のｓ１７、ｓ２１７）であっても、負荷情報収集部１１７は、所定のタイミングで、信頼ドメイン内に存在するＳＰの負荷情報を要求し、収集する（ｓ１１７Ａ、ｓ１１７Ｂ）。各ＳＰは、負荷情報要求を受け取ると、負荷情報生成部２１５で負荷情報を生成し、認証連携負荷分散装置１００へ送信する（ｓ２１５Ａ、ｓ２１５Ｂ）。

ＳＰ決定部１１５は、負荷情報と信頼ドメイン情報に基づき、負荷の高いＳＰと同様のサービスを提供しているＳＰを選択する（ｓ１１５’）。

例えば、図１２のような負荷情報に基づき、負荷の高いＳＰを抽出する。例えば、閾値以上の負荷値であるＳＰを高負荷ＳＰとして抽出する。さらに、信頼ドメイン情報を用いて、負荷の高いＳＰが提供しているサービスと同様のサービスを提供しているＳＰを選択する。さらに、転送関係情報を用いて、負荷の高いＳＰの存在するドメインから、そのＳＰと同様のサービスを提供しているＳＰの存在するドメインへ利用者端末１０を転送できるか否かを判定する構成としてもよい。転送できない場合には、転送先のドメイン内のＳＰはサービスを提供できないものとみなされる。

サービスを提供できるＳＰが他にない場合、つまり負荷の高いＳＰのみの場合には、転送処理は行わない。負荷の高いＳＰ以外にサービスを提供できるＳＰが存在する場合には、負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰに、負荷が高いＳＰを利用中の認証済みの利用者を転送するか否か決定する（ｓ１１８’）。例えば、抽出した負荷の高いＳＰの負荷を示す値から選択した負荷の低いＳＰの負荷を示す値を引いて、差を求め、この差が所定値以上の場合に転送する構成としてもよい。利用者を転送することで、転送先の負荷が高くなりすぎないか、また、転送処理によって生じるメリット（負荷を分散することができる等）とデメリット（転送処理自体が負荷となる等）を検討して転送するか否か決定する。

転送処理を行う場合には、ＳＰ決定部１１５は、転送元となる負荷が高いＳＰに対し、認証済みの利用者を決定したＳＰに転送するように要求する（ｓ１３１）。

転送元ＳＰ（例えばＳＰ２００Ｂ）は、サービスを提供している利用者の一部に対して、認証連携負荷分散装置１００のＵＲＬを送信し、実施例１の認証連携負荷分散装置１００から受信したトークン（図６のｓ１２０）を認証連携負荷分散装置１００へ送信し、アクセスするように指示する（ｓ２３１）。

利用者端末１０は、指示に従って、トークンを認証連携負荷分散装置１００へ送信する（ｓ２１）。

認証連携負荷分散装置１００の認証部１１３は、利用者端末１０が送信してきたトークンと同一のトークンが図８の使用情報に存在するか否かを確認し、つまり、受け取ったトークンが、自身の有するＳＰ決定部で生成したものか確認し、生成したものである場合には、認証処理が許可であると判断する（ｓ１１３’）。存在しない場合には利用者端末にログイン画面を表示する等のエラー処理を行う。なお、トークンに代えてセッションＩＤ１を用いてもよい。セッションＩＤ１を用いた場合には、利用者端末１０が送信してきたセッションＩＤ１と同一のセッションＩＤ１が図８の使用情報に存在し、かつ、そのセッションＩＤ１に紐付けられるトークンが存在するか否かを確認し、何れも存在する場合には、認証処理が許可であると判断する。なお、この場合、セッションＩＤ１が認証許可情報となる。

利用者が既にログイン済みの場合は利用者に認証を要求せずにシングルサインオンでサービス状態の継承ができる（図２の（６−２）参照）。シングルサインオンの形式として、ＳＡＭＬを用いた場合と、ＯｐｅｎＩＤを用いた場合について説明する。他の形式でシングルサインオンを行ってもよい。なお、通常のシングルサインオンは、利用者端末１０からのアクセス要求に対し、ＳＰが変わるときにログインの手間を省略するために行われるが、本発明では、利用者端末１０のからのアクセス要求により行われるわけではなく、自動的に認証連携負荷分散装置１００の指示に従って、シングルサインオンを行っている。
（ＳＡＭＬを用いる場合）
認証連携負荷分散装置１００は、認証処理が許可である場合には、利用者端末１０が送信してきたトークンと同一のトークンを負荷の低い転送先ＳＰ（例えばＳＰ２００Ａ）に送信する（ｓ１１９Ａ’）。このトークンに信頼情報や改竄検知情報を付加した場合の転送先ＳＰの処理は実施例１と同様である。また、図６のｓ１１９Ａのように、トークン、認可情報等を、すでに転送先ＳＰに送っている場合には、転送先ＳＰにおいて、トークンを照合することで、トークンに対応する認可情報や属性情報を取得することができる。

認証連携負荷分散装置１００が、図８の使用情報を用いて、トークンからユーザＩＤを特定し、図１０（Ｂ）、（Ｃ）の認可情報、属性情報を用いてユーザＩＤに対応する認可情報や属性情報を取得し、これらの情報を転送先ＳＰに送信する構成であってもよい。

認証連携負荷分散装置１００は、転送先ＳＰのＵＲＬを利用者端末１０に送信する（ｓ１２０’）。その際、利用者端末１０に対し、サービス要求情報にトークンを付加して、転送先ＳＰにアクセスするように指示する。

利用者端末１０は、この指示に従い、サービス要求情報にトークンを付加して転送先ＳＰにアクセスする（ｓ２３）。

転送先ＳＰ（例えば、ＳＰ２００Ａ）は、認証連携負荷分散装置１００からトークンを受け取り記憶部２０３に記憶する。さらに、転送先ＳＰは、利用者端末１０からサービス要求情報を受け取る。認証許可確認部２１１は、サービス要求情報にトークンが付加されているか否かを確認する（ｓ２１１Ａ）。つまり、記憶部１０３が記憶している認証連携負荷分散装置１００から受け取ったトークンとサービス要求情報に付加されているトークンが同一か否か判定し、同一の場合には、サービス要求情報に付加されたトークンが認証許可情報であると判断する。異なる場合には、エラー処理を行う。
（ＯｐｅｎＩＤを用いる場合）
ＯｐｅｎＩＤを用いる場合、認証連携負荷分散装置１００と各ＳＰは、暗号化及び復号
のための共通鍵を有する。

認証連携負荷分散装置１００は、認証処理が許可である場合には、共通鍵を用いてトークンを暗号化し、暗号化されたトークンと転送先ＳＰのＵＲＬを利用者端末１０に送信する（ｓ１２０”）。その際、利用者端末１０に対し、サービス要求情報に暗号化されたトークンを付加して、転送先ＳＰにアクセスするように指示する。なお、暗号化されたトークンに信頼情報や改竄検知情報を付加した場合、利用者端末１０は、付加された情報を転送先ＳＰに転送する。付加された情報を受信した転送先ＳＰの処理は実施例１と同様である。

利用者端末１０は、この指示に従い、サービス要求情報に暗号化されたトークンを付加して転送先ＳＰにアクセスする（ｓ２３”）。

転送先ＳＰ（例えば、ＳＰ２００Ａ）は、利用者端末１０からサービス要求情報を受け取る。認証許可確認部２１１は、共通鍵を用いてサービス要求情報に付加されているトークンを復号し、トークンが改竄されていないか確認し認証許可情報か否かを確認する。

サービス提供部２１９は、認証許可情報（例えば、トークン）が付加されている場合には、利用者端末に対し、サービスを提供する（ｓ２１７Ａ）。なお、セッションＩＤ生成部２１３でセッションＩＤ３を生成し（ｓ２１３Ａ）、これをサービス情報に付加して、利用者端末に送信する構成としてもよい。

従来技術では、認証装置は、要求のあったＳＰに対して、認証結果等を返していたため、信頼ドメイン間で認証情報を動的に伝搬させるのが困難であったが、上記構成により、動的に認証情報を連携することができる。また、従来技術では利用者の転送とサービス状態の引き継ぎを行う場合、ＬＢ同士が信頼ドメインであることの確認が必要であったが、信頼ドメイン情報を用いれば、認証連携負荷分散装置１００で容易に管理することができる。
＜変形例２＞
実施例１及び変形例１と異なる部分について説明する。図１６は、あるドメイン内のＳＰが有する、サービスを要求する利用者に関する情報（以下「サービス状態」という）を、他のドメインに転送する場合のシーケンス図である。例えば、図６、図１４及び１５のサービスの提供（ｓ２１７、ｓ２１７Ａ）の前にサービス状態の転送が行われる。

ＳＰ決定部１１５において決定されたＳＰ（以下「転送先ＳＰ」という、例えばＳＰ２００Ａ）は、ＯＡｕｔｈ（参考文献２参照）等を用いて署名付キー要求情報に認証許可情報（例えば、トークン）を付加して認証連携負荷分散装置１００に送信する（ｓ２４１）。
参考文献２：" OAuth "、[online]、 [平成２１年１２月２日検索]、インターネット＜URL: http://oauth.net/＞
認証連携負荷分散装置１００は、受け取った認証許可情報が図８の使用情報に存在するか否かを確認し（ｓ１４１）、つまり、受け取った認証許可情報が、自身の有するＳＰ決定部で生成したものか確認し、生成したものである場合には、既に認証されているので、サービス状態の転送を許可することを示す情報を転送先ＳＰに送信する（ｓ１４３）。この転送を許可することを示す情報は、例えば、署名付キー等であり、本変形例では、署名付キーを用いて説明する。

転送先ＳＰは、書名付キーを認証連携負荷分散装置から受け取り、サービス状態を有するＳＰ（以下、「転送元ＳＰ」という、例えばＳＰ２００Ｂ）に対し、サービス状態の転送を要求する（ｓ２５４Ａ）。その際、署名付キーを付加する。転送元ＳＰは、署名付キーにより転送要求の正当性を確認し、要求されたサービス状態を転送する（ｓ２４７Ｂ）。転送先ＳＰは、転送元サービス提供装置から、要求したサービス状態を受け取る。

例えば、Ｗｅｂメールサービスを提供しているサービス提供者がドメインの異なる運営事業者上で運営している場合、利用者端末がＷｅｂメールＳＰにアクセスしようとしたときに、最初はドメインＡ上のＷｅｂメールＳＰ２００Ａにアクセスしようとするが、ドメインＡが高負荷だった場合、認証連携負荷分散装置１００は負荷情報及び信頼ドメイン情報を基に、負荷の低いドメインＢ上のＷｅｂメールＳＰ２００Ｂに利用者を転送する。このとき、ドメインＡ上のＳＰ２００ＡからドメインＢ上のＳＰ２００Ｂへは認可情報に基づいて利用者のメールデータなどのサービス状態を転送する。

なお、この場合、サービス状態とは、ドメインＡの利用者のメールデータ等（送受信メールやアドレス帳やフォルダ情報や、メールに付したタグやラベル情報など）であり、このサービス状態全てを転送する構成としてもよいし、データ量が大きい場合には、サービスを提供するために必要なサービス状態のみを部分的に転送する構成としてもよい。例えば、送受信メールの内、直近の５０通分ずつのみを転送することなどが考えられる。また、サービス状態は別のドメインで記憶しておき、ドメイン間の転送を省略する構成も考えられる（参考文献３、４）。
参考文献３：" Amazon Relational Database Service (Amazon RDS)"、[online]、2009、 Amazon Web Services LLC or its affiliates、 [平成２１年１２月２日検索]、インターネット＜URL: http://aws.amazon.com/rds/＞
参考文献４：" Amazon SimpleDB "、[online]、2009、Amazon Web Services LLC or its affiliates、 [平成２１年１２月２日検索]、インターネット＜URL: http://aws.amazon.com/simpledb/＞
なお、認証連携負荷分散装置１００は、提供する毎に継承するサービス状態を規定する情報を予め記憶部１０３に記憶しておいてもよい。そのような構成とすることで、認証連携負荷分散装置１００が、サービス状態を管理し、ＳＰ側で特別な処理を行わなくてもサービスを提供することが可能となる。

図１７は信頼関係情報のデータ例を示す。信頼ドメイン間で安全にサービス状態を転送できるか否かを表す信頼関係情報を記憶部１０３に記憶しておいてもよい。

図１８は拡張した使用情報のデータ例である。使用情報として、サービスを提供しているドメイン及びＳＰ、サービスを継承可能なドメイン及びＳＰを記憶してもよい。このような構成とすることで、データを紐付けて収集する処理を省くことができる。

なお、ユーザの固有の情報を管理しているＳＰ（またはドメイン）をメインＳＰ（またはメインドメイン）として管理する構成としてもよい。利用者は原則としてメインＳＰにアクセスし、メインＳＰが高負荷となっている場合に、一時的に、他のＳＰ（以下「サブＳＰ」という）に転送される構成としてもよい。認証連携負荷分散装置１００は、データの転送処理が行われると、図１９のようにデータ格納情報を作成し、サービスの提供が終わると、サブＳＰから更新されたデータをメインＳＰへ送信する構成としてもよい。このような構成とすることによって、メインＳＰで利用者を管理することが可能となる。

上述のＷｅｂメールサービス等は、大量のメールデータ等を管理するため、メインＳＰを設ける構成や、データは別のドメインで記憶する構成が望ましい。

これらのデータ転送は、ログイン時だけではなく、サービス提供中にデータを転送する場合にも同様に行うことができる。

信頼ドメインＡ、Ｂ間で認可情報によるサービス状態を引き継ぎ、サービスを提供する。本発明では、認証連携負荷分散装置における認証・認可プロセスの途中に、負荷分散システムにおける負荷分散のプロセスを組み込むことで、サービスの信頼性確保を考慮に入れた認証連携が想定できる。

実施例１と異なる部分について説明する。図２を用いて実施例２に係る認証連携負荷分散システム２０００を説明する。認証連携負荷分散システム２０００は、異なるドメインに存在する２以上のＳＰ（例えば、２００Ａ、２００Ｂ）と、利用者の認証処理を行い、かつ、利用者端末１０から要求されるサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置３００とからなる。

まず認証連携負荷分散システム２０００の概要を説明する。利用者は利用者端末１０を操作して、認証連携負荷分散装置３００にアクセスし、認証連携負荷分散装置３００は、利用者の認証処理を行う（３）。実施例１との違いは、（１）サービス要求、（２）利用者転送処理がなく、利用者端末１０が、まず認証連携負荷分散装置３００にアクセスする点である。他の処理（（４）負荷情報取得、（５）認証許可情報等送信、（６）利用者転送、（７）サービス提供等）は実施例１と同様である。

図２０は認証連携負荷分散装置３００の構成例を、図２１は認証連携負荷分散システム２０００のシーケンス図を示す。

なお、各ＳＰは、ＳＰ２００は、最初に、利用者端末１０からサービス要求情報を受け取らないため、認証許可確認部２１１は、サービス要求情報に認証許可情報が付加されているか否かを確認し、認証許可情報が付加されていない場合に、利用者端末１０に対し、認証連携負荷分散装置１００のＵＲＬ等を送信する構成でなくてもよい。
（３）認証処理
利用者端末１０（例えば、パーソナルコンピュータ等）は、利用者によって操作され、当該利用者端末１０上にインストールされるＷｅｂブラウザ等を介して、認証連携負荷分散装置３００にアクセスする（ｓ５１）。その際、サービス要求情報や認証処理要求メッセージを送信する構成としてもよい。本実施例では、認証処理要求メッセージを送信するものとする。

認証連携付加分散装置１００は、認証部１１３において、認証情報を用いて利用者の認証処理を行う。

例えば、認証連携負荷分散装置１００は利用者端末１０にユーザＩＤ及びユーザパスワードの入力を要求する（ｓ３１２）。サービス要求情報を受け取っていない場合には、これも要求する。例えば、パスワード入力画面とともにサービス選択画面を表示してもよい。

利用者は、利用者端末１０を操作し、ユーザＩＤ及びユーザパスワード、サービス要求情報を入力し、認証連携負荷分散装置１００へ送信する（ｓ５５）。認証部１１３は、ユーザＩＤとユーザパスワード、サービス要求情報を受け取り、受け取ったユーザＩＤとユーザパスワードと図１０（Ａ）の認証情報を照合して利用者の認証処理を行う。

さらに、図１０（Ｂ）の認可情報と利用者の要求するサービス内容を照合して利用者がそのサービスを受ける権限を有しているか否か判断する（以下「認可処理」という）構成としてもよい。ユーザＩＤが判明した時点で、認可情報と紐付けて認可処理を行うことができる。

但し、上記認証処理は発明の内容を限定するものではなく、他の従来技術を用いて認証処理を行ってもよい。

認証処理が完了すると、セッションＩＤ生成部１１４は、この認証情報と関連づけられたセッションＩＤ１を生成する（ｓ１１４）。そして、サービス要求情報とセッションＩＤ１の組合せを使用情報として記憶部１０３に記憶する（ｓ１０３ｂ）。但し、セッションＩＤ１を用いず、利用者端末１０と認証連携負荷分散装置１００のアクセスを特定する必要がない場合には、使用情報を記憶部１０３に記憶しなくてもよい。また、認証連携負荷分散システム１０００が１種類のサービスのみを提供するＳＰ群からなる場合には、使用情報やセッションＩＤ１を用いなくてもよい。

実施例２では、使用情報として転送元ドメインを用いなくてもよく、転送元ドメインが信頼ドメインか否かの確認、及び、転送元のＳＰが要求されているサービスを提供しているか否かの確認を行わなくてもよく、信頼ドメイン確認部１１１を設けなくてもよい。

このような構成とすることで、実施例１と同様の効果を得ることができ、さらに、ＳＰと認証連携負荷分散装置１００間で行われる転送処理を省略することができる。また、認証連携負荷分散装置３００、ＳＰ２００を実施例１の変形例１及び２と同様の構成としてもよい。

１０ 利用者端末
１００、３００ 認証連携負荷分散装置
２００、２００Ａ、２００Ｂ ＳＰ
１０００、２０００ 認証連携負荷分散システム
１１１ 信頼ドメイン確認部
１１３ 認証部
１１５ ＳＰ決定部
１１７ 負荷情報収集部
１０３、２０３ 記憶部
２１１ 認証許可確認部
２１７ サービス提供部

Claims (10)

1. 異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置とからなる認証連携負荷分散システムであって、
   前記ＳＰは、
   前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）に、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認し、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記認証連携負荷分散装置に前記サービス要求情報を転送する認証許可確認部と、
   前記認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備え、
   前記認証連携負荷分散装置は、
   利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）と信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）を記憶する記憶部と、
   信頼ドメイン内に存在するＳＰの負荷情報を収集する負荷情報収集部と、
   前記認証情報を用いて利用者の認証処理を行う認証部と、
   利用者の認証結果が許可だった場合に、前記ＳＰが当該認証連携負荷分散装置に前記サービス要求情報を転送する際にそのサービス要求情報に付加される転送元ドメインと前記記憶部が記憶する信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、
   そのＳＰが信頼ドメイン内に存在する場合に、前記サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には前記負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを前記利用者端末の要求に応答するＳＰとして決定するＳＰ決定部と、を備え、
   前記ＳＰ決定部は、認証許可情報を生成し、前記決定されたＳＰと利用者端末に認証許可情報を送信すること、
   を特徴とする認証連携負荷分散システム。
2. 請求項１記載の認証連携負荷分散システムであって、
   前記ＳＰ決定部において決定されたＳＰ（以下「転送先ＳＰ」という）は、認証許可情報を認証連携負荷分散装置に送信し、
   前記認証連携負荷分散装置は、受け取った前記認証許可情報が、自身の有する前記ＳＰ決定部で生成したものか否かを確認し、生成したものである場合には、サービスを要求する利用者に関する情報（以下「サービス状態」という）の転送を許可することを示す情報（以下「サービス状態転送許可情報」という）を転送先ＳＰに送信し、
   転送先ＳＰは、前記サービス状態を有するＳＰ（以下「転送元ＳＰ」という）に対し、前記サービス状態転送許可情報を付加してサービス状態の転送を要求し、
   転送元ＳＰは、前記サービス状態転送許可情報を用いて、転送要求の正当性を確認し、要求されたサービス状態を転送先ＳＰに転送すること、
   を特徴とする認証連携負荷分散システム。
3. 利用者の認証処理を行い、かつ、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）の中から利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置であって、
   利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）と信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）を記憶する記憶部と、
   信頼ドメイン内に存在するＳＰの負荷情報を収集する負荷情報収集部と、
   前記認証情報を用いて利用者の認証処理を行う認証部と、
   利用者の認証結果が許可だった場合に、前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を前記ＳＰが当該認証連携負荷分散装置に転送する際にそのサービス要求情報に付加される転送元ドメインと前記記憶部が記憶する信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、
   そのＳＰが信頼ドメイン内に存在する場合に、前記サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には前記負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを前記利用者端末の要求に応答するＳＰとして決定するＳＰ決定部と、を備え、
   前記ＳＰ決定部は、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、前記決定されたＳＰと利用者端末に認証許可情報を送信すること、
   を特徴とする認証連携負荷分散装置。
4. 請求項３記載の認証連携負荷分散装置であって、
   前記ＳＰ決定部は、前記負荷情報を用いて負荷の高いＳＰを抽出し、前記信頼ドメイン情報を用いて抽出したＳＰと同様のサービスを提供するＳＰを選択し、負荷の高いＳＰ以外にサービスを提供できるＳＰが存在する場合には、選択したＳＰの中から負荷の低いＳＰに、負荷が高いＳＰを利用中の認証済みの利用者を転送するかを否か決定し、転送する場合には、転送元となる負荷の高いＳＰに対し、認証済みの利用者を決定したＳＰに転送するように要求すること、
   を特徴とする認証連携負荷分散装置。
5. 認証連携負荷分散装置によって、利用者に対しサービスを提供するＳＰとして決定され、利用者端末にアクセスされるサービス提供装置であって、
   前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）に、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認し、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記認証連携負荷分散装置に前記サービス要求情報を転送する認証許可確認部と、
   前記認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備え、
   異なるドメインに存在する他のサービス提供装置からサービス要求情報を転送された場合、
   認証許可情報を前記認証連携負荷分散装置に送信し、
   前記認証連携負荷分散装置が、サービスを要求する利用者に関する情報（以下、「サービス状態」という）の転送を許可することを示す情報（サービス情報転送許可情報）を前記認証連携負荷分散装置から受け取り、前記サービス状態を有するサービス提供装置に対し、前記サービス情報転送許可情報を付加してサービス状態の転送を要求し、
   異なるドメインに存在する他のサービス提供装置へサービス要求情報を転送する場合、
   前記サービス情報転送許可情報を用いて、サービス状態の転送要求が正当であることを確認し、要求されたサービス状態を転送すること、
   を特徴とするサービス提供装置。
6. 異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置を用いる認証連携負荷分散方法であって、
   前記認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、
   前記ＳＰが、前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を受け取るステップと、
   前記ＳＰが、認証結果が許可であることを表す情報（以下「認証許可情報」という）が付加されているか否かを確認する認証許可確認ステップと、
   サービス要求情報に、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記ＳＰが前記認証連携負荷分散装置に前記サービス要求情報を転送するステップと、
   前記認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
   利用者の認証結果が許可だった場合に、前記認証連携負荷分散装置が、前記ＳＰが当該認証連携負荷分散装置に前記サービス要求情報を転送する際に、そのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、
   そのＳＰが信頼ドメイン内に存在する場合に、前記認証連携負荷分散装置が、前記信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）と前記サービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には前記負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを前記利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、
   前記認証連携負荷分散装置が、認証許可情報を生成し、前記決定されたＳＰと利用者端末に認証許可情報を送信するステップと、
   サービス要求情報に、認証許可情報が付加されている場合に、前記ＳＰが利用者端末に対し、サービスを提供するサービス提供ステップと、を備えること、
   を特徴とする認証連携負荷分散方法。
7. 異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散装置を用いる認証連携負荷分散方法であって、
   前記認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、
   前記認証連携負荷分散装置が、前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を受け取るステップと、
   前記認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
   前記認証連携負荷分散装置が、利用者の認証結果が許可だった場合に、前記信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）と前記サービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には前記負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを前記利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、
   前記認証連携負荷分散装置が、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、前記決定されたＳＰと利用者端末に認証許可情報を送信するステップと、
   前記ＳＰが、サービス要求情報に、認証許可情報が付加されているか否かを確認する認証許可確認ステップと、
   サービス要求情報に、認証許可情報が付加されている場合に、前記ＳＰが利用者端末に対し、サービスを提供するサービス提供ステップと、を備えること、
   を特徴とする認証連携負荷分散方法。
8. 請求項６または７記載の認証連携負荷分散方法であって、
   前記ＳＰ決定ステップにおいて決定されたＳＰ（以下「転送先ＳＰ」という）が、認証許可情報を認証連携負荷分散装置に送信するステップと、
   前記認証連携負荷分散装置が、受け取った前記認証許可情報が、自身の有する前記ＳＰ決定ステップで生成したものか否かを確認し、生成したものである場合には、サービスを要求する利用者に関する情報（以下「サービス状態」という）の転送を許可することを示す情報（以下「サービス状態転送許可情報」という）を転送先ＳＰに送信するステップと、
   転送先ＳＰが、前記サービス状態を有するＳＰ（以下「転送元ＳＰ」という）に対し、前記サービス状態転送許可情報を付加してサービス状態の転送を要求するステップと、
   転送元ＳＰが、前記サービス状態転送許可情報を用いて、転送要求の正当性を確認し、要求されたサービス状態を転送先ＳＰに転送するステップを有すること、
   を特徴とする認証連携負荷分散方法。
9. 利用者の認証処理を行い、かつ、異なるドメインに存在する２以上のサービス提供装置（以下「ＳＰ」という）の中から利用者端末が要求するサービスを提供するＳＰを決定し、利用者端末を、決定したＳＰにアクセスさせる認証連携負荷分散方法であって、
   当該方法を実施する装置と信頼関係にあるドメイン（以下「信頼ドメイン」という）内に存在するＳＰの負荷情報を収集する負荷情報収集ステップと、
   予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
   利用者の認証結果が許可だった場合に、前記利用者端末が要求するサービスに関する情報（以下「サービス要求情報」という）を前記ＳＰが転送する際にそのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのＳＰが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、
   そのＳＰが信頼ドメイン内に存在する場合に、信頼ドメインと信頼ドメイン内に存在するＳＰの組合せ（以下「信頼ドメイン情報」という）と前記サービス要求情報を用いて、サービスを提供できるＳＰを選択し、ＳＰを２つ以上選択した場合には前記負荷情報を用いて、選択したＳＰの中から負荷の低いＳＰを前記利用者端末の要求に応答するＳＰとして決定するＳＰ決定ステップと、
   前記認証連携負荷分散装置が、認証結果が許可であることを表す情報（以下「認証許可情報」という）を生成し、前記決定されたＳＰと利用者端末に認証許可情報を送信するステップを備えること、
   を特徴とする認証連携負荷分散方法。
10. 請求項３から５の何れかに記載の装置としてコンピュータを機能させるためのプログラム。

Images