JP2011128731A - 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム - Google Patents
認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム Download PDFInfo
- Publication number
- JP2011128731A JP2011128731A JP2009284532A JP2009284532A JP2011128731A JP 2011128731 A JP2011128731 A JP 2011128731A JP 2009284532 A JP2009284532 A JP 2009284532A JP 2009284532 A JP2009284532 A JP 2009284532A JP 2011128731 A JP2011128731 A JP 2011128731A
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- information
- service
- load distribution
- load
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】異なるドメインに設置されたSP間で負荷分散を行い、かつ、利便性を高めるために認証をSP間で連携する必要があるが、従来技術では対応することができないという課題がある。
【解決手段】上記課題を解決するために本発明に係る認証連携負荷分散技術は、予め記憶している利用者の認証情報を用いて利用者の認証処理を行い、利用者の認証結果が許可だった場合に、信頼ドメイン情報とサービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定する。
【選択図】図3
【解決手段】上記課題を解決するために本発明に係る認証連携負荷分散技術は、予め記憶している利用者の認証情報を用いて利用者の認証処理を行い、利用者の認証結果が許可だった場合に、信頼ドメイン情報とサービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定する。
【選択図】図3
Description
本発明は、複数のサービス提供装置において、認証結果を連携すると同時に、サービス提供装置間の負荷分散を行う認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラムに関する。
従来の認証連携技術は、利用者の認証を行い、認証結果や認可情報(以下「認証結果等」という)を管理者や利用者が指定したサービス提供装置(以下「SP」(Service Provider)という)へ提供するシングルサインオン機能を有している。シングルサインオンの仕組みを規定する代表的な技術仕様として、非特許文献1記載のSAML2.0や非特許文献2記載のOpenID等がある。この認証連携技術においては、複数のサービス間で認証情報をやりとりする。
また、非特許文献3が従来の負荷分散技術として知られている。負荷分散技術とは、サーバへのアクセス集中によるレスポンスの低下を防ぎ、動的に複数サーバへ配信する処理を行う技術である。なお、サーバとはネットワークを介して他の端末からの要求に答えることができる端末であり、端末とはアプリケーションを実行する装置であり、端末毎に端末が有する機能が異なる。また、アプリケーションとは、任意の利用者の要求に答えるソフトウェアである。負荷分散システムを用いることで、サーバの拡張性の向上や、DoS攻撃などへの耐性を高めることができる。なお、負荷分散システムとは、外部ネットワークからの要求を一元的に管理し、同等の機能を持つ複数のサーバに要求を転送する装置である。
また、認証セッションを継承し負荷分散を行う従来技術として、特許文献1も検討されている。
"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 >
しかしながら、特許文献1記載の従来技術は異なるドメインに存在するSP間で、負荷分散を行うことができないという問題がある。なお、ドメインとはインターネット上に存在するコンピュータやネットワークの識別された領域、または領域を識別する名称である。
Ajax(Asynchronous Java(登録商標)Script + XML)やマッシュアップといったWeb2.0技術は、Webにおける基盤技術として、コンシューマー向けサービスや企業内で用いるビジネスアプリケーションなどでの利用が進んでいる。このようなWeb2.0技術によってソフトウェアをサービスとして提供するSaaS(Software as a Service)も浸透してきている。なお、SaaSとは、ソフトウェア機能を利用者が所有することなく、ネットワークを介してサービスとして利用できるようにしたソフトウェアの提供形態である。また、SaaSで提供されるアプリケーションを利用する際には、利用者の認証が行われるが、これらのアプリケーションを組合せて利用するマッシュアップにおいては、相互運用性や信頼性を高めるために、認証を連携させる必要がある。さらに、SaaSの普及によってアプリケーションが大規模化すると、拡張性や可用性、保守性確保の観点から複数のインフラ上で提供されることも想定される。今後、インタークラウド等の普及に伴い(参考文献1参照)、異なる運用事業者によって運営される異なるドメインに設置されたSP間で負荷分散を行い、かつ、利便性を高めるために認証をSP間で連携する必要があるが、従来技術では対応することができない。
参考文献1:[online]、2009、グローバルクラウド基盤連携技術フォーラム、[平成21年12月2日検索]、インターネット<URL: http://www.gictf.jp/activities.html>
参考文献1:[online]、2009、グローバルクラウド基盤連携技術フォーラム、[平成21年12月2日検索]、インターネット<URL: http://www.gictf.jp/activities.html>
上記の課題を解決するために、本発明に係る認証連携負荷分散システムは、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置とからなる。SPは、利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)に、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認し、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、認証連携負荷分散装置にサービス要求情報を転送する認証許可確認部と、認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備える。認証連携負荷分散装置は、利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)と信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)を記憶する記憶部と、信頼ドメイン内に存在するSPの負荷情報を収集する負荷情報収集部と、認証情報を用いて利用者の認証処理を行う認証部と、利用者の認証結果が許可だった場合に、SPが当該認証連携負荷分散装置にサービス要求情報を転送する際にそのサービス要求情報に付加される転送元ドメインと記憶部が記憶する信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、そのSPが信頼ドメイン内に存在する場合に、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定するSP決定部と、を備え、SP決定部は、認証許可情報を生成し、決定されたSPと利用者端末に認証許可情報を送信する。
上記の課題を解決するために、本発明に係る認証連携負荷分散装置は、利用者の認証処理を行い、かつ、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)の中から利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる。利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)と信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)を記憶する記憶部と、信頼ドメイン内に存在するSPの負荷情報を収集する負荷情報収集部と、認証情報を用いて利用者の認証処理を行う認証部と、利用者の認証結果が許可だった場合に、利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)をSPが当該認証連携負荷分散装置に転送する際にそのサービス要求情報に付加される転送元ドメインと記憶部が記憶する信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、そのSPが信頼ドメイン内に存在する場合に、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷を示す値が所定値よりも低いSPを利用者端末の要求に応答するSPとして決定するSP決定部と、を備え、SP決定部は、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、決定されたSPと利用者端末に認証許可情報を送信する。
上記の課題を解決するために、本発明に係るサービス提供装置は、認証連携負荷分散装置によって、利用者に対しサービスを提供するSPとして決定され、利用者端末にアクセスされる。利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)に、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認し、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、認証連携負荷分散装置にサービス要求情報を転送する認証許可確認部と、認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備える。異なるドメインに存在する他のサービス提供装置からサービス要求情報を転送された場合、認証許可情報を認証連携負荷分散装置に送信し、認証連携負荷分散装置が、サービスを要求する利用者に関する情報(以下、「サービス状態」という)の転送を許可することを示す情報(サービス情報転送許可情報)を認証連携負荷分散装置から受け取り、サービス状態を有するサービス提供装置に対し、サービス情報転送許可情報を付加してサービス状態の転送を要求し、異なるドメインに存在する他のサービス提供装置へサービス要求情報を転送する場合、サービス情報転送許可情報を用いて、サービス状態の転送要求が正当であることを確認し、要求されたサービス状態を転送する。
上記の課題を解決するために、本発明に係るサービス提供装置は、認証連携負荷分散装置によって、利用者に対しサービスを提供するSPとして決定され、利用者端末にアクセスされる。利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)に、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認し、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、認証連携負荷分散装置にサービス要求情報を転送する認証許可確認部と、認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備える。異なるドメインに存在する他のサービス提供装置からサービス要求情報を転送された場合、認証許可情報を認証連携負荷分散装置に送信し、認証連携負荷分散装置が、サービスを要求する利用者に関する情報(以下、「サービス状態」という)の転送を許可することを示す情報(サービス情報転送許可情報)を認証連携負荷分散装置から受け取り、サービス状態を有するサービス提供装置に対し、サービス情報転送許可情報を付加してサービス状態の転送を要求し、異なるドメインに存在する他のサービス提供装置へサービス要求情報を転送する場合、サービス情報転送許可情報を用いて、サービス状態の転送要求が正当であることを確認し、要求されたサービス状態を転送する。
上記の課題を解決するために、請求項6に係る認証連携負荷分散方法は、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置を用いる。認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、SPが、利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取るステップと、SPが、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認する認証許可確認ステップと、サービス要求情報に、認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、SPが認証連携負荷分散装置にサービス要求情報を転送するステップと、認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、利用者の認証結果が許可だった場合に、認証連携負荷分散装置が、SPが当該認証連携負荷分散装置にサービス要求情報を転送する際に、そのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、そのSPが信頼ドメイン内に存在する場合に、認証連携負荷分散装置が、信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)とサービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定するSP決定ステップと、認証連携負荷分散装置が、認証許可情報を生成し、決定されたSPと利用者端末に認証許可情報を送信するステップと、サービス要求情報に、認証許可情報が付加されている場合に、SPが利用者端末に対し、サービスを提供するサービス提供ステップと、を備える。
上記の課題を解決するために、請求項7に係る認証連携負荷分散方法は、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置を用いる。認証連携負荷分散装置が、当該認証連携負荷分散装置とにあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、認証連携負荷分散装置が、利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取るステップと、認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、認証連携負荷分散装置が、利用者の認証結果が許可だった場合に、信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)とサービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定するSP決定ステップと、認証連携負荷分散装置が、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、決定されたSPと利用者端末に認証許可情報を送信するステップと、SPが、サービス要求情報に、認証許可情報が付加されているか否か確認する認証許可確認ステップと、サービス要求情報に、認証許可情報が付加されている場合に、SPが利用者端末に対し、サービスを提供するサービス提供ステップと、を備える。
上記の課題を解決するために、請求項9に係る認証連携負荷分散方法は、利用者の認証処理を行い、かつ、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)の中から利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる。この方法を実施する装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、利用者の認証結果が許可だった場合に、利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)をSPが転送する際にそのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、そのSPが信頼ドメイン内に存在する場合に、信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)とサービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定するSP決定ステップと、認証連携負荷分散装置が、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、決定されたSPと利用者端末に認証許可情報を送信するステップを備える。
本発明は、認証の結果と負荷分散を連動させることによって、異なる運用事業者によって運営される異なるドメインに設置されたSP間で負荷分散を行い、かつ、利便性を高めるために認証をSP間で連携することができるという効果を奏する。
[従来技術の組合せ]
従来の認証装置(以下「IDP」(Identity Provider)という)と負荷分散装置(以下「LB」(Load Balancer)という)を用いて、認証及び負荷分散をする方法について図1を用いて説明する。図1の(A)は負荷分散前の従来技術を、(B)は負荷分散処理後の従来技術を示す。IDPとLBがそれぞれ別々に運用されている場合、異なるドメイン間で他のドメインの情報を保持していないため、それぞれのドメイン上のSPでログイン処理が必要になる。
従来の認証装置(以下「IDP」(Identity Provider)という)と負荷分散装置(以下「LB」(Load Balancer)という)を用いて、認証及び負荷分散をする方法について図1を用いて説明する。図1の(A)は負荷分散前の従来技術を、(B)は負荷分散処理後の従来技術を示す。IDPとLBがそれぞれ別々に運用されている場合、異なるドメイン間で他のドメインの情報を保持していないため、それぞれのドメイン上のSPでログイン処理が必要になる。
利用者の操る利用者端末10のブラウザは、ドメインA内のLB140Aに対してサービスを要求する(1)。LB140Aは、まずIDP130との間で利用者の認証処理を行う(2)。認証の結果、許可されれば、LB140Aは、要求されたサービスを提供するSP200Aに対する負荷情報を取得する(3)。
LB140Aは、負荷情報に基づき、SP200Aに処理を行わせるべきか判断し、高負荷であると判断した場合には、他のサービス提供装置200Bに負荷を分散するため、LB140Bへサービス要求を転送する(4)。LB140Bは、LB140Aと同様に、IDP130との間で利用者の認証処理を行い(5)、認証の結果、許可されれば、SP200Bに対する負荷情報を取得する(6)。LB140Bは、負荷情報に基づき、SP200Bに処理を行わせるべきか判断し、低負荷であると判断した場合には、SP200Bがサービスを提供するように指示し、SP200Bはサービスを提供する(7)。
なお、LB140AとIDP130の間で認証処理を行っているが、ドメインが異なるため、この認証結果をLB140Bに引き継ぐことはできない。例えば、異なる複数の運用事業者によって運営される異なるドメインに設置されたSP間で認証システムを連携させるためには、SPは認証システムから得た認証結果等を明示的にやりとりする仕組みをサービスに実装する必要がある。しかし、異なる運用事業者間でこのような仕組みを共有することは負担が大きいと考えられる。また、異なる運用事業者間で認証結果等を伝達する場合には、余分な負荷(データ量)が大きくなる。
また、負荷分散システムは負荷の分散に特化しているため、認証結果等を含めて、異なるドメインに転送するためには、SPの正当性や利用者の正当性の両方を確認する必要があり、アクセスポリシを管理する点においても障壁が高い。さらに、各LBは、配置されたドメイン内のSPの負荷情報しか取得できないため、転送に際して、SP200Bの負荷状態を知ることはできない。そのため、利用者端末10のサービス要求はLB140Bで転送された後も、サービスを受けることができない事態も生じうる。
以下、本発明の実施の形態について、詳細に説明する。
本発明は、認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)が異なる複数のSP間において、利用者の認証を行うプロセスと同時に認認証連携負荷分散装置が複数のSP間の負荷を監視し、負荷の低いSPへ利用者を転送する。なお、例えば、信頼ドメインとは、認証連携負荷分散装置の運用者と高い信頼関係にある運用者が運営するドメイン等である。
本発明の一実施形態として、あるサービスを運用する際に、クラウドコンピューティング(以下、クラウド)と呼ばれるサービス基盤上で運用する形態がある。クラウドとは、インフラリソースやアプリケーションなどのコンピュータ資源・機能を、ネットワークを介して利用する形態であり、ネットワーク上に存在するサーバが提供するサービスを、それらのサーバ群を意識することなく利用できるコンピューティング形態を表す。ネットワークを図示するのに雲状の絵を使うことが多いことに由来している。雲の中にはハードウェアやソフトウェアの実体があるが、その中身を意識することなく利用できる。このようなクラウドは多くのクラウド提供業者によって提供されており、サービスの冗長性確保や可用性維持のために複数のクラウド提供事業者を利用するケースが想定できる。一つのサービスが複数のクラウド提供事業者によって提供される場合、複数のドメインを信頼ドメインとして認証連携負荷分散装置が管理し、利用者のサービス要求によって遷移先のSPを決定する。
[認証連携負荷分散システム1000]
図2は認証連携負荷分散システム1000の構成例を示す。図2を用いて実施例1に係る認証連携負荷分散システム1000を説明する。認証連携負荷分散システム1000は、異なるドメインに存在する2以上のSP(例えば、200A、200B)と、利用者の認証処理を行い、かつ、利用者端末10から要求されるサービスを提供するSPを決定し、利用者端末10を、決定したSPにアクセスさせる認証連携負荷分散装置100とからなる。
[認証連携負荷分散システム1000]
図2は認証連携負荷分散システム1000の構成例を示す。図2を用いて実施例1に係る認証連携負荷分散システム1000を説明する。認証連携負荷分散システム1000は、異なるドメインに存在する2以上のSP(例えば、200A、200B)と、利用者の認証処理を行い、かつ、利用者端末10から要求されるサービスを提供するSPを決定し、利用者端末10を、決定したSPにアクセスさせる認証連携負荷分散装置100とからなる。
まず認証連携負荷分散システム1000の概要を説明する。利用者は利用者端末10を操作して、ドメインA上で運用されているあるSP200Aに対してサービスを要求する(1)。SP200Aは、認証処理及び負荷分散処理を行うために、認証連携負荷分散装置100へ利用者端末10を転送する(2)。認証連携負荷分散装置100は、利用者の認証処理を行う(3)。また、認証連携負荷分散装置100は信頼ドメインA、B上のSP200A、200Bの負荷状況を監視する(4)。認証連携負荷分散装置100は、認証許可情報を負荷が低いSP(例えばSP200B)に送信する(5)。その後、利用者端末10は、負荷の低いSPに転送される(6)。負荷の低いSPは、利用者端末10にサービスを提供する(7)。このとき、ドメインAとドメインBはそれぞれ異なる信頼ドメインであり、異なる運用事業者間でサービスが提供されていてもよい。
図3は認証連携負荷分散装置100の構成例を、図4はSP200(200A及び200B)の構成例を、図5は認証連携負荷分散システム1000のシーケンス図を、図6は図5の処理の続きを、図7は認証連携負荷分散装置100の処理フロー例を示す。なお、認証連携負荷分散装置100、SP200は図示しない通信部を有し、これを介して、他の装置と通信する構成であってもよい。通信部は、例えば、LANアダプタ等により構成され、LANやインターネット等からなる通信回線と接続される。
(1)サービス要求
利用者端末10(例えば、パーソナルコンピュータ等)は、利用者によって操作され、当該利用者端末10上にインストールされるWebブラウザ等を介して、ドメインA上のSP200Aに対し、サービスを要求する(s11)。
(2)利用者転送
SP200は、利用者端末10が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取る。認証許可確認部211は、サービス要求情報に認証許可情報が付加されているか否かを確認し、認証連携負荷分散装置100によって生成された認証許可情報が付加されていない場合には、利用者端末10に対し、認証連携負荷分散装置100のURL、転送元ドメイン、認証処理要求メッセージ、転送要求を送信する。その際、利用者端末に対し、サービス要求情報に転送元ドメイン(例えば、この場合「ドメインA」)と認証処理要求メッセージを付加して、認証連携負荷分散装置100にアクセスするように指示する(s214)。なお、認証許可情報とは、例えば、後述するトークンやセッションID2等である。
(1)サービス要求
利用者端末10(例えば、パーソナルコンピュータ等)は、利用者によって操作され、当該利用者端末10上にインストールされるWebブラウザ等を介して、ドメインA上のSP200Aに対し、サービスを要求する(s11)。
(2)利用者転送
SP200は、利用者端末10が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取る。認証許可確認部211は、サービス要求情報に認証許可情報が付加されているか否かを確認し、認証連携負荷分散装置100によって生成された認証許可情報が付加されていない場合には、利用者端末10に対し、認証連携負荷分散装置100のURL、転送元ドメイン、認証処理要求メッセージ、転送要求を送信する。その際、利用者端末に対し、サービス要求情報に転送元ドメイン(例えば、この場合「ドメインA」)と認証処理要求メッセージを付加して、認証連携負荷分散装置100にアクセスするように指示する(s214)。なお、認証許可情報とは、例えば、後述するトークンやセッションID2等である。
利用者端末10は、指示に従い、サービス要求情報に認証処理要求メッセージと転送元ドメインを付加して認証連携負荷分散装置100にアクセスする(s13)。なお、サービス要求情報、認証処理要求メッセージ、転送元ドメインに対する改竄を検知するための情報として改竄検知情報(例えば、電子署名等)を付加する構成としてもよい。
(3)認証処理
認証連携付加分散装置100は、サービス要求情報を受け取り(s101a)、認証部113において、認証情報を用いて利用者の認証処理を行う。
(3)認証処理
認証連携付加分散装置100は、サービス要求情報を受け取り(s101a)、認証部113において、認証情報を用いて利用者の認証処理を行う。
なお、認証連携負荷分散装置100は、転送元ドメイン等に改竄検知情報が付加されている場合には、改竄検知情報に基づき転送元ドメイン等に改竄等がなされていないか確認する。改竄が検知された場合には、エラー処理を行う。例えば、利用者端末10に対し、転送元ドメイン等と改竄検知情報を再送するように指示する。
図10(A)は記憶部103が記憶する認証情報(ユーザID、ユーザPW)の、(B)は認可情報(利用可能なサービスやドメイン)の、(C)は属性情報(利用者権限、優先順位、住所)のデータ例を示す。認証情報や認可情報、属性情報等は、利用者登録等により作成され、利用に先立ち予め記憶部103に記憶しておく。例えば、認証連携負荷分散装置100は利用者端末10にユーザID及びユーザパスワードの入力を要求する(s112)。
利用者は、利用者端末10を操作し、ユーザID及びユーザパスワードを入力し、認証連携負荷分散装置100へ送信する(s15)。認証部113は、ユーザIDとユーザパスワードを受け取り(s101b)、受け取ったユーザIDとユーザパスワードと図10(A)の認証情報を照合して利用者の認証処理を行う(s113a)。
さらに、図10(B)の認可情報と利用者の要求するサービス内容や転送元ドメインを照合して利用者がそのサービスを受ける権限を有しているか否か判断する(以下「認可処理」という)構成としてもよい(s113b)。例えば、図10(B)の場合、ユーザID「jiroh」は、要求するサービスが(2)である場合やドメインBが転送元ドメインである場合には、サービスを受ける権限を有しているが、要求するサービスが(1)である場合やドメインAが転送元ドメインである場合には、サービスを受ける権限を有していない。ユーザIDが判明した時点で、認可情報と紐付けて認可処理を行うことができる。
認証処理が完了すると、セッションID生成部114は、この認証情報と関連づけられたセッションID1を生成する(s114)。そして、サービス要求情報とセッションID1と転送元ドメインの組合せを使用情報として記憶部103に記憶する(s103b)。図8は、使用情報のデータ例である。このとき、2行目の例のようにセッションID1と転送元ドメインとサービス内容とユーザIDのみが記憶される。但し、セッションID1を用いず、利用者端末10と認証連携負荷分散装置100のアクセスを特定する必要がない場合には、使用情報を記憶部103に記憶しなくてもよい。また、上記認証処理は発明の内容を限定するものではなく、他の従来技術を用いて認証処理を行ってもよい。また、認証連携負荷分散システム1000が1種類のサービスのみ提供するSP群からなる場合には、使用情報やセッションIDを用いなくてもよい。
利用者の認証結果(及び認可結果)が許可だった場合に、認証連携負荷分散装置100の信頼ドメイン確認部111は、転送元ドメインと記憶部103が記憶する信頼ドメインから、SP200Aが信頼ドメイン内に存在するか否かを確認する(s111a)。図9は記憶部103が記憶する信頼ドメイン情報のデータ例を示す。信頼ドメイン情報は、信頼ドメインと信頼ドメイン内に存在するSPの組合せであり、さらに、信頼ドメインの信頼情報や所在地等を含んでもよく、利用に先立ち予め記憶部103に記憶される。但し、信頼ドメイン内に存在するSPが2以上のサービスを提供する場合には、サービス毎にそのサービスを提供するSPの情報を記憶してもよい。なお、信頼情報とは、認証連携負荷分散装置100と各SP200A、200B、…の間で秘密に管理される情報であり、各SPは、信頼情報が付加された情報を受信した場合に、その情報の発信源が認証連携負荷分散装置100であることを確認することができる。
信頼ドメイン確認部111は、SP200Aが信頼ドメイン内に存在する場合には、サービス要求情報と信頼ドメイン情報を用いて、利用者端末10が要求するサービスを転送元のSPが提供するか否かを確認する構成としてもよい(s111b)。このような構成は、認証連携負荷分散システム1000が2種類以上のサービスを提供するSP群からなり、SP毎に提供できるサービスが異なる場合に有用である。
認証結果または認可結果が不許可だった場合や、SPが信頼ドメイン内に存在せず、または、要求するサービスを転送元のSPが提供していない場合には、エラー処理を行う(s190)。例えば、利用者端末10に対し、再度ユーザIDやユーザパスワードの入力を求めてもよいし、利用者登録画面のリンクを表示してもよい。また、転送元SPに対し、エラーが生じた旨の通知を行ってもよい。
例えば、図9の場合、転送元ドメインがドメインA、ドメインB、ドメインD、…等であれば、SP200Aは信頼ドメイン内に存在するが、転送元ドメインがドメインC等の場合には、SP200Aは信頼ドメイン外に存在するものとして、エラー処理を行う(s190)。また、転送元のSPが200Aであり、利用者端末10がサービス(2)を要求する場合、転送元のSPはサービス(2)を提供していないため、エラー処理を行う(s190)。
(4)負荷情報取得
SPが信頼ドメイン内に存在し、要求するサービスを転送元のSPが提供している場合に、SP決定部115は、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを1つ以上選択する(s115)。
(4)負荷情報取得
SPが信頼ドメイン内に存在し、要求するサービスを転送元のSPが提供している場合に、SP決定部115は、サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを1つ以上選択する(s115)。
なお、サービス要求情報と信頼ドメイン情報に加え、転送関係情報を用いている構成としてもよい。図11は転送関係情報のデータ例を示す。転送関係情報は利用に先立ち、予め記憶部103に記憶しておく。転送関係情報は利用者端末10のサービス要求を取得したドメインが他のドメインに転送できるか否かを表し、例えば、ドメインBからドメインAへ利用者端末10を転送することはできないが、ドメインBからドメインDに転送することはできる。転送できない場合には、転送先のドメイン内のSPはサービスを提供できないものとみなされる。また、転送関係情報はドメイン間ではなく、SP間の転送関係を示してもよい。本実施例では、サービス要求情報と信頼ドメイン情報を用いる場合について説明する。
サービスを提供できるSPが1つの場合、つまり転送元のSPのみの場合には、そのSPを利用者端末の要求に応答するSPとして決定する。SPが2つ以上の場合には、最適なSPを選択する。最適なSPを選択する方法の例としては、負荷情報を用いて、選択したSPの中から負荷の低いSPを利用者端末の要求に応答するSPとして決定する方法がある(s118)。なお、負荷の低いSPとは、例えば、選択されたSPの中で最も負荷を示す値が低いSPや、負荷を示す値が所定値よりも低いSP、また負荷を示す値が所定値よりも低いSPが2以上ある場合には、その中からランダムに選択されるSP等である。なお、所定値とは認証連携負荷分散装置100の記憶部103の中に予め記憶されているものである。SP選択の方法は他にも、利用者装置のネットワークに近いSPに転送するなどの方法がある。図12は負荷情報のデータ例を示す。SPの負荷情報とは、例えば、実行待ちの状態にあるプロセスの単位時間辺りの平均数やメモリ使用量、プロセッサ使用率、ディスクアクセス頻度等である。またドメインの負荷情報(例えば、ネットワークトラフィック)を間接的にそのドメイン内のSPの負荷情報として用い、負荷の少ないドメインを選択し、そのドメイン内のSPの負荷が少ないものとみなし、選択する構成としてもよい。
負荷情報収集部117は、所定のタイミングで、信頼ドメイン内に存在するSPの負荷情報を要求し、収集する(s117A、s117B)。所定のタイミングとは、例えば、SP決定部115から指示を受けたタイミングや、利用者端末10からサービス要求情報を受け取ったタイミングや、所定時間が経過したタイミング(例えば5分毎)等である。
図10(C)は利用者の属性情報のデータ例を示す。信頼ドメイン情報として信頼ドメインの所在地を記憶している場合であって、利用者の属性情報として利用者の住所を記憶している場合や使用情報として送信元(利用者端末10)の(図示していない)IPアドレス等を記憶している場合には、負荷情報収集部117は、記憶部103からこれらの情報を収集し、その信頼ドメインと、利用者の住所または利用者端末10との距離を負荷情報として求める構成としてもよい。アクセス後に信頼ドメインと利用者の住所または利用者端末10との距離が変わらない場合には、所定のタイミングは、最初のアクセス時や認証処理後としてもよい。
各SPは、負荷情報要求を受け取ると、負荷情報生成部215で負荷情報を生成し、認証連携負荷分散装置100へ送信する(s215A、s215B)。但し、ドメインの負荷情報(例えば、ネットワークトラフィック)を間接的にそのドメイン内のSPの負荷情報として用いる場合には、負荷情報生成部215をSP内に設けずに、ドメイン内のネットワーク上に設けてもよい。
レスポンスタイム(認証部113がユーザID及びユーザパスワードを受け取ってから、SP決定部115が負荷情報を受け取るまでの時間)を短くしたい場合には、SP決定部115から指示を受けたタイミングや、利用者端末10からサービス要求情報を受け取ったタイミングとは無関係に所定時間毎に、負荷情報収集部117が管理する全てのSPの負荷情報を収集し、記憶部103に記憶しておき、認証処理後にSP決定部115が、記憶部103から負荷情報を取り出す構成としたほうがよい。
サービス要求が少ない場合には、効率的に負荷情報を収集するために、SP決定部115から指示を受けたタイミングや、利用者端末10からサービス要求情報を受け取ったタイミングで、負荷情報収集部117が要求されるサービスを提供できるSPのみの負荷情報を収集する構成としてもよい。
また、例えば、負荷情報を収集できなかったSPは、装置の故障または高負荷の状態であるとみなして、サービス提供できない状態にあると判断し、負荷情報を収集できたSPのみを、SPの選択対象としてもよい。
但し、上記負荷分散方法は発明の内容を限定するものではなく、他の従来技術を用いて負荷分散を行ってもよい。このような構成とすることによって、認証情報や認可情報、属性情報等と負荷情報及び信頼ドメイン情報を結びつけてSPを決定することができる。
(5)認証許可情報等送信
SPを決定後、SP決定部115は、認証許可情報としてトークンを作成し、トークンを決定したSP(例えば、SP200B)に送信する(s119B)。トークンは認証結果が許可を表す場合のみ作成されるため、これを受け取った場合には、認証結果が許可であることが明らかである。
(5)認証許可情報等送信
SPを決定後、SP決定部115は、認証許可情報としてトークンを作成し、トークンを決定したSP(例えば、SP200B)に送信する(s119B)。トークンは認証結果が許可を表す場合のみ作成されるため、これを受け取った場合には、認証結果が許可であることが明らかである。
但し、記憶部103が信頼情報を記憶している場合には、SP決定部115は、トークンに信頼情報を付加する構成としてもよい。また、図10(B)の認可情報や、(C)の属性情報等を付加する構成としてもよい。さらに、ユーザIDや信頼ドメイン情報等を付加する構成としてもよい。さらに、トークンと信頼情報等に対する改竄を検知するための情報として改竄検知情報(例えば、電子署名等)を付加する構成としてもよい。
なお、本実施例では、転送元SPと転送先SPが異なっているが、同一の場合であっても同様の処理を行えばよい。
(6)利用者転送
一方、SP決定部115は、利用者端末に対し、トークンに決定したSPのURLを付加して送信する(s120)。その際、利用者端末10に対し、サービス要求情報に、トークンを付加して決定したSPにアクセスするように指示する。なお、記憶部103は、各SPのURLを信頼ドメイン情報として記憶してもよいし、別途SP情報として記憶してもよい。
(6)利用者転送
一方、SP決定部115は、利用者端末に対し、トークンに決定したSPのURLを付加して送信する(s120)。その際、利用者端末10に対し、サービス要求情報に、トークンを付加して決定したSPにアクセスするように指示する。なお、記憶部103は、各SPのURLを信頼ドメイン情報として記憶してもよいし、別途SP情報として記憶してもよい。
利用者端末10は、この指示に従い、サービス要求情報にトークンを付加して決定したSPにアクセスする(s17)。
(7)サービス提供
決定したSP(例えば、SP200B)は、認証連携負荷分散装置100からトークンを受け取り記憶部203に記憶する。さらに、決定したSPは、利用者端末10からサービス要求情報を受け取る。認証許可確認部211は、サービス要求情報にトークンが付加されているか否かを確認する(s211)。つまり、記憶部103が記憶している認証連携負荷分散装置100から受け取ったトークンとサービス要求情報に付加されているトークンが同一か否か判定し、同一の場合には、サービス要求情報に付加されたトークンが認証許可情報であると判断する。異なる場合には、エラー処理を行う。例えば、利用者端末に対し、サービス要求情報の再送を要求する。
(7)サービス提供
決定したSP(例えば、SP200B)は、認証連携負荷分散装置100からトークンを受け取り記憶部203に記憶する。さらに、決定したSPは、利用者端末10からサービス要求情報を受け取る。認証許可確認部211は、サービス要求情報にトークンが付加されているか否かを確認する(s211)。つまり、記憶部103が記憶している認証連携負荷分散装置100から受け取ったトークンとサービス要求情報に付加されているトークンが同一か否か判定し、同一の場合には、サービス要求情報に付加されたトークンが認証許可情報であると判断する。異なる場合には、エラー処理を行う。例えば、利用者端末に対し、サービス要求情報の再送を要求する。
サービス提供部219は、サービス要求情報に対し認証連携負荷分散装置100が生成した認証許可情報(例えば、トークン)が付加されている場合には、利用者端末に対し、サービスを提供する(s217)。
認証連携負荷分散装置100からのトークンに改竄検知情報が付加されている場合には、改竄検知部217が、トークン等に改竄等がなされていないか確認する構成としてもよい。改竄が検知された場合には、エラー処理を行う。例えば、認証連携負荷分散装置100に対し、トークン等の再送を要求する。
認証連携負荷分散装置100からのトークンに信頼情報が付加されている場合には、転送元検証部218が、予め記憶部203に記憶しておいた信頼情報と、トークンに付加されている信頼情報が同一か否か検証する構成としてもよい。同一の場合には、そのトークンの発信源が認証連携負荷分散装置100であるものとして処理を行う。異なる場合には、転送元が認証連携負荷分散装置100ではないと判断し、エラー処理を行う。例えば、認証連携負荷分散装置100に対し、トークン等の再送を要求する。このような構成により、認証連携負荷分散装置100のなりすまし等を防止することができる。
認証連携負荷分散装置100からのトークンに属性情報の優先順位が付加されている場合には、その優先順位に従って、サービスを提供する構成としてもよい。決定されたSPの記憶部203はトークンと優先順位を紐付けて記憶する。さらに、決定されたSPは、利用者端末10からトークン付のサービス要求情報を受け取り、認証許可確認部211でトークンを照合し、同一の場合には、トークンに紐付けられた優先順位を取得する。例えば、複数の利用者端末10からのサービス要求情報を受信し、サービス提供部219において、サービス待ち状態が発生している場合であっても、先に待ち状態となっていた低い優先順位に対応するトークンを付加されたサービス要求情報よりも、高い優先順位に対応するトークンを付加されたサービス要求情報に対し、早くサービスを提供する。
認証連携負荷分散装置100からのトークンに認可情報や属性情報の利用者権限が付加されている場合には、最初のサービス要求情報で要求していたサービス内容と異なるサービス内容であっても、その認可情報や利用者権限に従って、サービスを提供する構成としてもよい。
認証許可確認部211は、サービス要求情報にトークンが付加されていると判断した場合に、セッションID生成部213にセッションID2を生成するように指示し、サービス提供部219にサービスを提供するように指示する構成としてもよい。セッションID生成部213は、指示に従って、セッションID2を生成し(s213B)、トークンとセッションID2を紐付けて記憶部203に記憶する。サービス提供部219は、サービス情報にセッションID2を付加して利用者端末10に送信する(s217)。その際に、利用者端末10に対し、以後サービス要求情報にセッションID2を付加するように指示する。
利用者端末10は、指示に従って、サービス要求情報にセッションID2を付加して決定したSPにアクセスする(s17−2)。決定したSPでは認証許可確認部211は、サービス要求情報に付加されたセッションID2と、記憶部203が記憶するトークンと紐付けられたセッションID2が同一であるか否かを確認し、同一の場合には、サービス要求情報に付加されたセッションID2が認証許可情報であると判断し、サービス提供部219に対し、サービスを提供するように指示する。サービス提供部219は、サービス情報にセッションID2を付加して利用者端末10に送信する(s217−2)。以後、同様にセッションID2を用いて、サービスの要求と提供が行われる。
<効果>
このような構成とすることによって、大規模システム向けの過負荷制御技術と、セキュリティ分野の認証技術という異なる技術分野を組合せることでき、認証ステップと負荷分散のステップを同時に実施することにより、複数の信頼ドメインにまたがる負荷分散を安全に実施し、高可用性を同時に確保することができる。また、SPは認証結果や認可情報を明示的にやりとりする仕組みをサービスに実装せずに、認証連携負荷分散装置100の指示に従って、サービスを提供することができ、システム全体の信頼性を向上させ、システム実装における負担を軽減することができる。さらに、利用者は異なるドメインに転送される際にも再ログインをせずにサービスを受けることができる。
<ハードウェア構成>
図13は、本実施例における認証連携負荷分散装置100のハードウェア構成を例示したブロック図である。図13に例示するように、この例の認証連携負荷分散装置100は、それぞれCPU(Central Processing Unit)11、入力部12、出力部13、補助記憶装置14、ROM(Read Only Memory)15、RAM(Random Access Memory)16及びバス17を有している。
<効果>
このような構成とすることによって、大規模システム向けの過負荷制御技術と、セキュリティ分野の認証技術という異なる技術分野を組合せることでき、認証ステップと負荷分散のステップを同時に実施することにより、複数の信頼ドメインにまたがる負荷分散を安全に実施し、高可用性を同時に確保することができる。また、SPは認証結果や認可情報を明示的にやりとりする仕組みをサービスに実装せずに、認証連携負荷分散装置100の指示に従って、サービスを提供することができ、システム全体の信頼性を向上させ、システム実装における負担を軽減することができる。さらに、利用者は異なるドメインに転送される際にも再ログインをせずにサービスを受けることができる。
<ハードウェア構成>
図13は、本実施例における認証連携負荷分散装置100のハードウェア構成を例示したブロック図である。図13に例示するように、この例の認証連携負荷分散装置100は、それぞれCPU(Central Processing Unit)11、入力部12、出力部13、補助記憶装置14、ROM(Read Only Memory)15、RAM(Random Access Memory)16及びバス17を有している。
この例のCPU11は、制御部11a、演算部11b及びレジスタ11cを有し、レジスタ11cに読み込まれた各種プログラムに従って様々な演算処理を実行する。また、入力部12は、データが入力される入力インターフェース、キーボード、マウス等であり、出力部13は、データが出力される出力インターフェース等である。補助記憶装置14は、例えば、ハードディスク、半導体メモリ等であり、認証連携負荷分散装置100としてコンピュータを機能させるためのプログラムや各種データが格納される。また、RAM16には、上記のプログラムや各種データが展開され、CPU11等から利用される。また、バス17は、CPU11、入力部12、出力部13、補助記憶装置14、ROM15及びRAM16を通信可能に接続する。なお、このようなハードウェアの具体例としては、例えば、パーソナルコンピュータの他、サーバ装置やワークステーション等を例示できる。
<プログラム構成>
上述のように、補助記憶装置14には、本実施例の認証連携負荷分散装置100の各処理を実行するための各プログラムが格納される。認証連携負荷分散プログラムを構成する各プログラムは、単一のプログラム列として記載されていてもよく、また、少なくとも一部のプログラムが別個のモジュールとしてライブラリに格納されていてもよい。
<ハードウェアとプログラムとの協働>
CPU11は、読み込まれたOSプログラムに従い、補助記憶装置14に格納されている上述のプログラムや各種データをRAM16に展開する。そして、このプログラムやデータが書き込まれたRAM16上のアドレスがCPU11のレジスタ11cに格納される。CPU11の制御部11aは、レジスタ11cに格納されたこれらのアドレスを順次読み出し、読み出したアドレスが示すRAM16上の領域からプログラムやデータを読み出し、そのプログラムが示す演算を演算部11bに順次実行させ、その演算結果をレジスタ11cに格納していく。
<プログラム構成>
上述のように、補助記憶装置14には、本実施例の認証連携負荷分散装置100の各処理を実行するための各プログラムが格納される。認証連携負荷分散プログラムを構成する各プログラムは、単一のプログラム列として記載されていてもよく、また、少なくとも一部のプログラムが別個のモジュールとしてライブラリに格納されていてもよい。
<ハードウェアとプログラムとの協働>
CPU11は、読み込まれたOSプログラムに従い、補助記憶装置14に格納されている上述のプログラムや各種データをRAM16に展開する。そして、このプログラムやデータが書き込まれたRAM16上のアドレスがCPU11のレジスタ11cに格納される。CPU11の制御部11aは、レジスタ11cに格納されたこれらのアドレスを順次読み出し、読み出したアドレスが示すRAM16上の領域からプログラムやデータを読み出し、そのプログラムが示す演算を演算部11bに順次実行させ、その演算結果をレジスタ11cに格納していく。
図3は、このようにCPU11に上述のプログラムが読み込まれて実行されることにより構成される認証連携負荷分散装置100の機能構成を例示したブロック図である。
ここで、記憶部103は、補助記憶装置14、RAM16、レジスタ11c、その他のバッファメモリやキャッシュメモリ等の何れか、あるいはこれらを併用した記憶領域に相当する。また、信頼ドメイン確認部111、認証部113、SP決定部115及び負荷情報収集部117は、CPU11に認証連携負荷分散プログラムを実行させることにより構成されるものである。
<変形例1>
実施例1と異なる部分について説明する。図14はSAMLを用いて認証済みの利用者端末10を負荷情報に基づいて負荷が高いSPから負荷が低いSPへ転送する際のシーケンス図、図15はOpenIDを用いて、認証済みの利用者端末10を負荷情報に基づいて負荷が高いSPから負荷が低いSPへ転送する際のシーケンス図である。なお、利用者が利用中のデータの転送を伴わない場合の例を示す。
<変形例1>
実施例1と異なる部分について説明する。図14はSAMLを用いて認証済みの利用者端末10を負荷情報に基づいて負荷が高いSPから負荷が低いSPへ転送する際のシーケンス図、図15はOpenIDを用いて、認証済みの利用者端末10を負荷情報に基づいて負荷が高いSPから負荷が低いSPへ転送する際のシーケンス図である。なお、利用者が利用中のデータの転送を伴わない場合の例を示す。
変形例1の認証連携負荷分散装置100は、負荷情報を用いて、あるSP(例えばSP200B)でサービス利用中の利用者を、他のSP(例えばSP200A)に転送することができる。
認証連携負荷分散装置100の負荷情報収集部117は、認証済み、言い換えると、サービス提供中(図6のs17、s217)であっても、負荷情報収集部117は、所定のタイミングで、信頼ドメイン内に存在するSPの負荷情報を要求し、収集する(s117A、s117B)。各SPは、負荷情報要求を受け取ると、負荷情報生成部215で負荷情報を生成し、認証連携負荷分散装置100へ送信する(s215A、s215B)。
SP決定部115は、負荷情報と信頼ドメイン情報に基づき、負荷の高いSPと同様のサービスを提供しているSPを選択する(s115’)。
例えば、図12のような負荷情報に基づき、負荷の高いSPを抽出する。例えば、閾値以上の負荷値であるSPを高負荷SPとして抽出する。さらに、信頼ドメイン情報を用いて、負荷の高いSPが提供しているサービスと同様のサービスを提供しているSPを選択する。さらに、転送関係情報を用いて、負荷の高いSPの存在するドメインから、そのSPと同様のサービスを提供しているSPの存在するドメインへ利用者端末10を転送できるか否かを判定する構成としてもよい。転送できない場合には、転送先のドメイン内のSPはサービスを提供できないものとみなされる。
サービスを提供できるSPが他にない場合、つまり負荷の高いSPのみの場合には、転送処理は行わない。負荷の高いSP以外にサービスを提供できるSPが存在する場合には、負荷情報を用いて、選択したSPの中から負荷の低いSPに、負荷が高いSPを利用中の認証済みの利用者を転送するか否か決定する(s118’)。例えば、抽出した負荷の高いSPの負荷を示す値から選択した負荷の低いSPの負荷を示す値を引いて、差を求め、この差が所定値以上の場合に転送する構成としてもよい。利用者を転送することで、転送先の負荷が高くなりすぎないか、また、転送処理によって生じるメリット(負荷を分散することができる等)とデメリット(転送処理自体が負荷となる等)を検討して転送するか否か決定する。
転送処理を行う場合には、SP決定部115は、転送元となる負荷が高いSPに対し、認証済みの利用者を決定したSPに転送するように要求する(s131)。
転送元SP(例えばSP200B)は、サービスを提供している利用者の一部に対して、認証連携負荷分散装置100のURLを送信し、実施例1の認証連携負荷分散装置100から受信したトークン(図6のs120)を認証連携負荷分散装置100へ送信し、アクセスするように指示する(s231)。
利用者端末10は、指示に従って、トークンを認証連携負荷分散装置100へ送信する(s21)。
認証連携負荷分散装置100の認証部113は、利用者端末10が送信してきたトークンと同一のトークンが図8の使用情報に存在するか否かを確認し、つまり、受け取ったトークンが、自身の有するSP決定部で生成したものか確認し、生成したものである場合には、認証処理が許可であると判断する(s113’)。存在しない場合には利用者端末にログイン画面を表示する等のエラー処理を行う。なお、トークンに代えてセッションID1を用いてもよい。セッションID1を用いた場合には、利用者端末10が送信してきたセッションID1と同一のセッションID1が図8の使用情報に存在し、かつ、そのセッションID1に紐付けられるトークンが存在するか否かを確認し、何れも存在する場合には、認証処理が許可であると判断する。なお、この場合、セッションID1が認証許可情報となる。
利用者が既にログイン済みの場合は利用者に認証を要求せずにシングルサインオンでサービス状態の継承ができる(図2の(6−2)参照)。シングルサインオンの形式として、SAMLを用いた場合と、OpenIDを用いた場合について説明する。他の形式でシングルサインオンを行ってもよい。なお、通常のシングルサインオンは、利用者端末10からのアクセス要求に対し、SPが変わるときにログインの手間を省略するために行われるが、本発明では、利用者端末10のからのアクセス要求により行われるわけではなく、自動的に認証連携負荷分散装置100の指示に従って、シングルサインオンを行っている。
(SAMLを用いる場合)
認証連携負荷分散装置100は、認証処理が許可である場合には、利用者端末10が送信してきたトークンと同一のトークンを負荷の低い転送先SP(例えばSP200A)に送信する(s119A’)。このトークンに信頼情報や改竄検知情報を付加した場合の転送先SPの処理は実施例1と同様である。また、図6のs119Aのように、トークン、認可情報等を、すでに転送先SPに送っている場合には、転送先SPにおいて、トークンを照合することで、トークンに対応する認可情報や属性情報を取得することができる。
(SAMLを用いる場合)
認証連携負荷分散装置100は、認証処理が許可である場合には、利用者端末10が送信してきたトークンと同一のトークンを負荷の低い転送先SP(例えばSP200A)に送信する(s119A’)。このトークンに信頼情報や改竄検知情報を付加した場合の転送先SPの処理は実施例1と同様である。また、図6のs119Aのように、トークン、認可情報等を、すでに転送先SPに送っている場合には、転送先SPにおいて、トークンを照合することで、トークンに対応する認可情報や属性情報を取得することができる。
認証連携負荷分散装置100が、図8の使用情報を用いて、トークンからユーザIDを特定し、図10(B)、(C)の認可情報、属性情報を用いてユーザIDに対応する認可情報や属性情報を取得し、これらの情報を転送先SPに送信する構成であってもよい。
認証連携負荷分散装置100は、転送先SPのURLを利用者端末10に送信する(s120’)。その際、利用者端末10に対し、サービス要求情報にトークンを付加して、転送先SPにアクセスするように指示する。
利用者端末10は、この指示に従い、サービス要求情報にトークンを付加して転送先SPにアクセスする(s23)。
転送先SP(例えば、SP200A)は、認証連携負荷分散装置100からトークンを受け取り記憶部203に記憶する。さらに、転送先SPは、利用者端末10からサービス要求情報を受け取る。認証許可確認部211は、サービス要求情報にトークンが付加されているか否かを確認する(s211A)。つまり、記憶部103が記憶している認証連携負荷分散装置100から受け取ったトークンとサービス要求情報に付加されているトークンが同一か否か判定し、同一の場合には、サービス要求情報に付加されたトークンが認証許可情報であると判断する。異なる場合には、エラー処理を行う。
(OpenIDを用いる場合)
OpenIDを用いる場合、認証連携負荷分散装置100と各SPは、暗号化及び復号
のための共通鍵を有する。
(OpenIDを用いる場合)
OpenIDを用いる場合、認証連携負荷分散装置100と各SPは、暗号化及び復号
のための共通鍵を有する。
認証連携負荷分散装置100は、認証処理が許可である場合には、共通鍵を用いてトークンを暗号化し、暗号化されたトークンと転送先SPのURLを利用者端末10に送信する(s120”)。その際、利用者端末10に対し、サービス要求情報に暗号化されたトークンを付加して、転送先SPにアクセスするように指示する。なお、暗号化されたトークンに信頼情報や改竄検知情報を付加した場合、利用者端末10は、付加された情報を転送先SPに転送する。付加された情報を受信した転送先SPの処理は実施例1と同様である。
利用者端末10は、この指示に従い、サービス要求情報に暗号化されたトークンを付加して転送先SPにアクセスする(s23”)。
転送先SP(例えば、SP200A)は、利用者端末10からサービス要求情報を受け取る。認証許可確認部211は、共通鍵を用いてサービス要求情報に付加されているトークンを復号し、トークンが改竄されていないか確認し認証許可情報か否かを確認する。
サービス提供部219は、認証許可情報(例えば、トークン)が付加されている場合には、利用者端末に対し、サービスを提供する(s217A)。なお、セッションID生成部213でセッションID3を生成し(s213A)、これをサービス情報に付加して、利用者端末に送信する構成としてもよい。
従来技術では、認証装置は、要求のあったSPに対して、認証結果等を返していたため、信頼ドメイン間で認証情報を動的に伝搬させるのが困難であったが、上記構成により、動的に認証情報を連携することができる。また、従来技術では利用者の転送とサービス状態の引き継ぎを行う場合、LB同士が信頼ドメインであることの確認が必要であったが、信頼ドメイン情報を用いれば、認証連携負荷分散装置100で容易に管理することができる。
<変形例2>
実施例1及び変形例1と異なる部分について説明する。図16は、あるドメイン内のSPが有する、サービスを要求する利用者に関する情報(以下「サービス状態」という)を、他のドメインに転送する場合のシーケンス図である。例えば、図6、図14及び15のサービスの提供(s217、s217A)の前にサービス状態の転送が行われる。
<変形例2>
実施例1及び変形例1と異なる部分について説明する。図16は、あるドメイン内のSPが有する、サービスを要求する利用者に関する情報(以下「サービス状態」という)を、他のドメインに転送する場合のシーケンス図である。例えば、図6、図14及び15のサービスの提供(s217、s217A)の前にサービス状態の転送が行われる。
SP決定部115において決定されたSP(以下「転送先SP」という、例えばSP200A)は、OAuth(参考文献2参照)等を用いて署名付キー要求情報に認証許可情報(例えば、トークン)を付加して認証連携負荷分散装置100に送信する(s241)。
参考文献2:" OAuth "、[online]、 [平成21年12月2日検索]、インターネット<URL: http://oauth.net/>
認証連携負荷分散装置100は、受け取った認証許可情報が図8の使用情報に存在するか否かを確認し(s141)、つまり、受け取った認証許可情報が、自身の有するSP決定部で生成したものか確認し、生成したものである場合には、既に認証されているので、サービス状態の転送を許可することを示す情報を転送先SPに送信する(s143)。この転送を許可することを示す情報は、例えば、署名付キー等であり、本変形例では、署名付キーを用いて説明する。
参考文献2:" OAuth "、[online]、 [平成21年12月2日検索]、インターネット<URL: http://oauth.net/>
認証連携負荷分散装置100は、受け取った認証許可情報が図8の使用情報に存在するか否かを確認し(s141)、つまり、受け取った認証許可情報が、自身の有するSP決定部で生成したものか確認し、生成したものである場合には、既に認証されているので、サービス状態の転送を許可することを示す情報を転送先SPに送信する(s143)。この転送を許可することを示す情報は、例えば、署名付キー等であり、本変形例では、署名付キーを用いて説明する。
転送先SPは、書名付キーを認証連携負荷分散装置から受け取り、サービス状態を有するSP(以下、「転送元SP」という、例えばSP200B)に対し、サービス状態の転送を要求する(s254A)。その際、署名付キーを付加する。転送元SPは、署名付キーにより転送要求の正当性を確認し、要求されたサービス状態を転送する(s247B)。転送先SPは、転送元サービス提供装置から、要求したサービス状態を受け取る。
例えば、Webメールサービスを提供しているサービス提供者がドメインの異なる運営事業者上で運営している場合、利用者端末がWebメールSPにアクセスしようとしたときに、最初はドメインA上のWebメールSP200Aにアクセスしようとするが、ドメインAが高負荷だった場合、認証連携負荷分散装置100は負荷情報及び信頼ドメイン情報を基に、負荷の低いドメインB上のWebメールSP200Bに利用者を転送する。このとき、ドメインA上のSP200AからドメインB上のSP200Bへは認可情報に基づいて利用者のメールデータなどのサービス状態を転送する。
なお、この場合、サービス状態とは、ドメインAの利用者のメールデータ等(送受信メールやアドレス帳やフォルダ情報や、メールに付したタグやラベル情報など)であり、このサービス状態全てを転送する構成としてもよいし、データ量が大きい場合には、サービスを提供するために必要なサービス状態のみを部分的に転送する構成としてもよい。例えば、送受信メールの内、直近の50通分ずつのみを転送することなどが考えられる。また、サービス状態は別のドメインで記憶しておき、ドメイン間の転送を省略する構成も考えられる(参考文献3、4)。
参考文献3:" Amazon Relational Database Service (Amazon RDS)"、[online]、2009、 Amazon Web Services LLC or its affiliates、 [平成21年12月2日検索]、インターネット<URL: http://aws.amazon.com/rds/>
参考文献4:" Amazon SimpleDB "、[online]、2009、Amazon Web Services LLC or its affiliates、 [平成21年12月2日検索]、インターネット<URL: http://aws.amazon.com/simpledb/>
なお、認証連携負荷分散装置100は、提供する毎に継承するサービス状態を規定する情報を予め記憶部103に記憶しておいてもよい。そのような構成とすることで、認証連携負荷分散装置100が、サービス状態を管理し、SP側で特別な処理を行わなくてもサービスを提供することが可能となる。
参考文献3:" Amazon Relational Database Service (Amazon RDS)"、[online]、2009、 Amazon Web Services LLC or its affiliates、 [平成21年12月2日検索]、インターネット<URL: http://aws.amazon.com/rds/>
参考文献4:" Amazon SimpleDB "、[online]、2009、Amazon Web Services LLC or its affiliates、 [平成21年12月2日検索]、インターネット<URL: http://aws.amazon.com/simpledb/>
なお、認証連携負荷分散装置100は、提供する毎に継承するサービス状態を規定する情報を予め記憶部103に記憶しておいてもよい。そのような構成とすることで、認証連携負荷分散装置100が、サービス状態を管理し、SP側で特別な処理を行わなくてもサービスを提供することが可能となる。
図17は信頼関係情報のデータ例を示す。信頼ドメイン間で安全にサービス状態を転送できるか否かを表す信頼関係情報を記憶部103に記憶しておいてもよい。
図18は拡張した使用情報のデータ例である。使用情報として、サービスを提供しているドメイン及びSP、サービスを継承可能なドメイン及びSPを記憶してもよい。このような構成とすることで、データを紐付けて収集する処理を省くことができる。
なお、ユーザの固有の情報を管理しているSP(またはドメイン)をメインSP(またはメインドメイン)として管理する構成としてもよい。利用者は原則としてメインSPにアクセスし、メインSPが高負荷となっている場合に、一時的に、他のSP(以下「サブSP」という)に転送される構成としてもよい。認証連携負荷分散装置100は、データの転送処理が行われると、図19のようにデータ格納情報を作成し、サービスの提供が終わると、サブSPから更新されたデータをメインSPへ送信する構成としてもよい。このような構成とすることによって、メインSPで利用者を管理することが可能となる。
上述のWebメールサービス等は、大量のメールデータ等を管理するため、メインSPを設ける構成や、データは別のドメインで記憶する構成が望ましい。
これらのデータ転送は、ログイン時だけではなく、サービス提供中にデータを転送する場合にも同様に行うことができる。
信頼ドメインA、B間で認可情報によるサービス状態を引き継ぎ、サービスを提供する。本発明では、認証連携負荷分散装置における認証・認可プロセスの途中に、負荷分散システムにおける負荷分散のプロセスを組み込むことで、サービスの信頼性確保を考慮に入れた認証連携が想定できる。
実施例1と異なる部分について説明する。図2を用いて実施例2に係る認証連携負荷分散システム2000を説明する。認証連携負荷分散システム2000は、異なるドメインに存在する2以上のSP(例えば、200A、200B)と、利用者の認証処理を行い、かつ、利用者端末10から要求されるサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置300とからなる。
まず認証連携負荷分散システム2000の概要を説明する。利用者は利用者端末10を操作して、認証連携負荷分散装置300にアクセスし、認証連携負荷分散装置300は、利用者の認証処理を行う(3)。実施例1との違いは、(1)サービス要求、(2)利用者転送処理がなく、利用者端末10が、まず認証連携負荷分散装置300にアクセスする点である。他の処理((4)負荷情報取得、(5)認証許可情報等送信、(6)利用者転送、(7)サービス提供等)は実施例1と同様である。
図20は認証連携負荷分散装置300の構成例を、図21は認証連携負荷分散システム2000のシーケンス図を示す。
なお、各SPは、SP200は、最初に、利用者端末10からサービス要求情報を受け取らないため、認証許可確認部211は、サービス要求情報に認証許可情報が付加されているか否かを確認し、認証許可情報が付加されていない場合に、利用者端末10に対し、認証連携負荷分散装置100のURL等を送信する構成でなくてもよい。
(3)認証処理
利用者端末10(例えば、パーソナルコンピュータ等)は、利用者によって操作され、当該利用者端末10上にインストールされるWebブラウザ等を介して、認証連携負荷分散装置300にアクセスする(s51)。その際、サービス要求情報や認証処理要求メッセージを送信する構成としてもよい。本実施例では、認証処理要求メッセージを送信するものとする。
(3)認証処理
利用者端末10(例えば、パーソナルコンピュータ等)は、利用者によって操作され、当該利用者端末10上にインストールされるWebブラウザ等を介して、認証連携負荷分散装置300にアクセスする(s51)。その際、サービス要求情報や認証処理要求メッセージを送信する構成としてもよい。本実施例では、認証処理要求メッセージを送信するものとする。
認証連携付加分散装置100は、認証部113において、認証情報を用いて利用者の認証処理を行う。
例えば、認証連携負荷分散装置100は利用者端末10にユーザID及びユーザパスワードの入力を要求する(s312)。サービス要求情報を受け取っていない場合には、これも要求する。例えば、パスワード入力画面とともにサービス選択画面を表示してもよい。
利用者は、利用者端末10を操作し、ユーザID及びユーザパスワード、サービス要求情報を入力し、認証連携負荷分散装置100へ送信する(s55)。認証部113は、ユーザIDとユーザパスワード、サービス要求情報を受け取り、受け取ったユーザIDとユーザパスワードと図10(A)の認証情報を照合して利用者の認証処理を行う。
さらに、図10(B)の認可情報と利用者の要求するサービス内容を照合して利用者がそのサービスを受ける権限を有しているか否か判断する(以下「認可処理」という)構成としてもよい。ユーザIDが判明した時点で、認可情報と紐付けて認可処理を行うことができる。
但し、上記認証処理は発明の内容を限定するものではなく、他の従来技術を用いて認証処理を行ってもよい。
認証処理が完了すると、セッションID生成部114は、この認証情報と関連づけられたセッションID1を生成する(s114)。そして、サービス要求情報とセッションID1の組合せを使用情報として記憶部103に記憶する(s103b)。但し、セッションID1を用いず、利用者端末10と認証連携負荷分散装置100のアクセスを特定する必要がない場合には、使用情報を記憶部103に記憶しなくてもよい。また、認証連携負荷分散システム1000が1種類のサービスのみを提供するSP群からなる場合には、使用情報やセッションID1を用いなくてもよい。
実施例2では、使用情報として転送元ドメインを用いなくてもよく、転送元ドメインが信頼ドメインか否かの確認、及び、転送元のSPが要求されているサービスを提供しているか否かの確認を行わなくてもよく、信頼ドメイン確認部111を設けなくてもよい。
このような構成とすることで、実施例1と同様の効果を得ることができ、さらに、SPと認証連携負荷分散装置100間で行われる転送処理を省略することができる。また、認証連携負荷分散装置300、SP200を実施例1の変形例1及び2と同様の構成としてもよい。
10 利用者端末
100、300 認証連携負荷分散装置
200、200A、200B SP
1000、2000 認証連携負荷分散システム
111 信頼ドメイン確認部
113 認証部
115 SP決定部
117 負荷情報収集部
103、203 記憶部
211 認証許可確認部
217 サービス提供部
100、300 認証連携負荷分散装置
200、200A、200B SP
1000、2000 認証連携負荷分散システム
111 信頼ドメイン確認部
113 認証部
115 SP決定部
117 負荷情報収集部
103、203 記憶部
211 認証許可確認部
217 サービス提供部
Claims (10)
- 異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置とからなる認証連携負荷分散システムであって、
前記SPは、
前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)に、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認し、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記認証連携負荷分散装置に前記サービス要求情報を転送する認証許可確認部と、
前記認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備え、
前記認証連携負荷分散装置は、
利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)と信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)を記憶する記憶部と、
信頼ドメイン内に存在するSPの負荷情報を収集する負荷情報収集部と、
前記認証情報を用いて利用者の認証処理を行う認証部と、
利用者の認証結果が許可だった場合に、前記SPが当該認証連携負荷分散装置に前記サービス要求情報を転送する際にそのサービス要求情報に付加される転送元ドメインと前記記憶部が記憶する信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、
そのSPが信頼ドメイン内に存在する場合に、前記サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には前記負荷情報を用いて、選択したSPの中から負荷の低いSPを前記利用者端末の要求に応答するSPとして決定するSP決定部と、を備え、
前記SP決定部は、認証許可情報を生成し、前記決定されたSPと利用者端末に認証許可情報を送信すること、
を特徴とする認証連携負荷分散システム。 - 請求項1記載の認証連携負荷分散システムであって、
前記SP決定部において決定されたSP(以下「転送先SP」という)は、認証許可情報を認証連携負荷分散装置に送信し、
前記認証連携負荷分散装置は、受け取った前記認証許可情報が、自身の有する前記SP決定部で生成したものか否かを確認し、生成したものである場合には、サービスを要求する利用者に関する情報(以下「サービス状態」という)の転送を許可することを示す情報(以下「サービス状態転送許可情報」という)を転送先SPに送信し、
転送先SPは、前記サービス状態を有するSP(以下「転送元SP」という)に対し、前記サービス状態転送許可情報を付加してサービス状態の転送を要求し、
転送元SPは、前記サービス状態転送許可情報を用いて、転送要求の正当性を確認し、要求されたサービス状態を転送先SPに転送すること、
を特徴とする認証連携負荷分散システム。 - 利用者の認証処理を行い、かつ、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)の中から利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置であって、
利用者の認証情報と、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)と信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)を記憶する記憶部と、
信頼ドメイン内に存在するSPの負荷情報を収集する負荷情報収集部と、
前記認証情報を用いて利用者の認証処理を行う認証部と、
利用者の認証結果が許可だった場合に、前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を前記SPが当該認証連携負荷分散装置に転送する際にそのサービス要求情報に付加される転送元ドメインと前記記憶部が記憶する信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認部と、
そのSPが信頼ドメイン内に存在する場合に、前記サービス要求情報と信頼ドメイン情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には前記負荷情報を用いて、選択したSPの中から負荷の低いSPを前記利用者端末の要求に応答するSPとして決定するSP決定部と、を備え、
前記SP決定部は、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、前記決定されたSPと利用者端末に認証許可情報を送信すること、
を特徴とする認証連携負荷分散装置。 - 請求項3記載の認証連携負荷分散装置であって、
前記SP決定部は、前記負荷情報を用いて負荷の高いSPを抽出し、前記信頼ドメイン情報を用いて抽出したSPと同様のサービスを提供するSPを選択し、負荷の高いSP以外にサービスを提供できるSPが存在する場合には、選択したSPの中から負荷の低いSPに、負荷が高いSPを利用中の認証済みの利用者を転送するかを否か決定し、転送する場合には、転送元となる負荷の高いSPに対し、認証済みの利用者を決定したSPに転送するように要求すること、
を特徴とする認証連携負荷分散装置。 - 認証連携負荷分散装置によって、利用者に対しサービスを提供するSPとして決定され、利用者端末にアクセスされるサービス提供装置であって、
前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)に、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認し、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記認証連携負荷分散装置に前記サービス要求情報を転送する認証許可確認部と、
前記認証許可情報が付加されている場合には、利用者端末に対し、サービスを提供するサービス提供部と、を備え、
異なるドメインに存在する他のサービス提供装置からサービス要求情報を転送された場合、
認証許可情報を前記認証連携負荷分散装置に送信し、
前記認証連携負荷分散装置が、サービスを要求する利用者に関する情報(以下、「サービス状態」という)の転送を許可することを示す情報(サービス情報転送許可情報)を前記認証連携負荷分散装置から受け取り、前記サービス状態を有するサービス提供装置に対し、前記サービス情報転送許可情報を付加してサービス状態の転送を要求し、
異なるドメインに存在する他のサービス提供装置へサービス要求情報を転送する場合、
前記サービス情報転送許可情報を用いて、サービス状態の転送要求が正当であることを確認し、要求されたサービス状態を転送すること、
を特徴とするサービス提供装置。 - 異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置を用いる認証連携負荷分散方法であって、
前記認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、
前記SPが、前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取るステップと、
前記SPが、認証結果が許可であることを表す情報(以下「認証許可情報」という)が付加されているか否かを確認する認証許可確認ステップと、
サービス要求情報に、前記認証連携負荷分散装置によって生成された認証許可情報が付加されていない場合に、前記SPが前記認証連携負荷分散装置に前記サービス要求情報を転送するステップと、
前記認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
利用者の認証結果が許可だった場合に、前記認証連携負荷分散装置が、前記SPが当該認証連携負荷分散装置に前記サービス要求情報を転送する際に、そのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、
そのSPが信頼ドメイン内に存在する場合に、前記認証連携負荷分散装置が、前記信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)と前記サービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には前記負荷情報を用いて、選択したSPの中から負荷の低いSPを前記利用者端末の要求に応答するSPとして決定するSP決定ステップと、
前記認証連携負荷分散装置が、認証許可情報を生成し、前記決定されたSPと利用者端末に認証許可情報を送信するステップと、
サービス要求情報に、認証許可情報が付加されている場合に、前記SPが利用者端末に対し、サービスを提供するサービス提供ステップと、を備えること、
を特徴とする認証連携負荷分散方法。 - 異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)と、利用者の認証処理を行い、かつ、利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散装置を用いる認証連携負荷分散方法であって、
前記認証連携負荷分散装置が、当該認証連携負荷分散装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、
前記認証連携負荷分散装置が、前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を受け取るステップと、
前記認証連携負荷分散装置が、予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
前記認証連携負荷分散装置が、利用者の認証結果が許可だった場合に、前記信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)と前記サービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には前記負荷情報を用いて、選択したSPの中から負荷の低いSPを前記利用者端末の要求に応答するSPとして決定するSP決定ステップと、
前記認証連携負荷分散装置が、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、前記決定されたSPと利用者端末に認証許可情報を送信するステップと、
前記SPが、サービス要求情報に、認証許可情報が付加されているか否かを確認する認証許可確認ステップと、
サービス要求情報に、認証許可情報が付加されている場合に、前記SPが利用者端末に対し、サービスを提供するサービス提供ステップと、を備えること、
を特徴とする認証連携負荷分散方法。 - 請求項6または7記載の認証連携負荷分散方法であって、
前記SP決定ステップにおいて決定されたSP(以下「転送先SP」という)が、認証許可情報を認証連携負荷分散装置に送信するステップと、
前記認証連携負荷分散装置が、受け取った前記認証許可情報が、自身の有する前記SP決定ステップで生成したものか否かを確認し、生成したものである場合には、サービスを要求する利用者に関する情報(以下「サービス状態」という)の転送を許可することを示す情報(以下「サービス状態転送許可情報」という)を転送先SPに送信するステップと、
転送先SPが、前記サービス状態を有するSP(以下「転送元SP」という)に対し、前記サービス状態転送許可情報を付加してサービス状態の転送を要求するステップと、
転送元SPが、前記サービス状態転送許可情報を用いて、転送要求の正当性を確認し、要求されたサービス状態を転送先SPに転送するステップを有すること、
を特徴とする認証連携負荷分散方法。 - 利用者の認証処理を行い、かつ、異なるドメインに存在する2以上のサービス提供装置(以下「SP」という)の中から利用者端末が要求するサービスを提供するSPを決定し、利用者端末を、決定したSPにアクセスさせる認証連携負荷分散方法であって、
当該方法を実施する装置と信頼関係にあるドメイン(以下「信頼ドメイン」という)内に存在するSPの負荷情報を収集する負荷情報収集ステップと、
予め記憶している利用者の認証情報を用いて利用者の認証処理を行う認証ステップと、
利用者の認証結果が許可だった場合に、前記利用者端末が要求するサービスに関する情報(以下「サービス要求情報」という)を前記SPが転送する際にそのサービス要求情報に付加される転送元ドメインと予め記憶している信頼ドメインから、そのSPが信頼ドメイン内に存在するか否かを確認する信頼ドメイン確認ステップと、
そのSPが信頼ドメイン内に存在する場合に、信頼ドメインと信頼ドメイン内に存在するSPの組合せ(以下「信頼ドメイン情報」という)と前記サービス要求情報を用いて、サービスを提供できるSPを選択し、SPを2つ以上選択した場合には前記負荷情報を用いて、選択したSPの中から負荷の低いSPを前記利用者端末の要求に応答するSPとして決定するSP決定ステップと、
前記認証連携負荷分散装置が、認証結果が許可であることを表す情報(以下「認証許可情報」という)を生成し、前記決定されたSPと利用者端末に認証許可情報を送信するステップを備えること、
を特徴とする認証連携負荷分散方法。 - 請求項3から5の何れかに記載の装置としてコンピュータを機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009284532A JP2011128731A (ja) | 2009-12-15 | 2009-12-15 | 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009284532A JP2011128731A (ja) | 2009-12-15 | 2009-12-15 | 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011128731A true JP2011128731A (ja) | 2011-06-30 |
Family
ID=44291293
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009284532A Pending JP2011128731A (ja) | 2009-12-15 | 2009-12-15 | 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011128731A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022135828A (ja) * | 2021-03-04 | 2022-09-15 | 株式会社ストラテジット | SaaS連携アプリケーションのマーケットプレイス |
CN115617279A (zh) * | 2022-12-13 | 2023-01-17 | 北京中电德瑞电子科技有限公司 | 分布式云数据的处理方法、装置及存储介质 |
-
2009
- 2009-12-15 JP JP2009284532A patent/JP2011128731A/ja active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022135828A (ja) * | 2021-03-04 | 2022-09-15 | 株式会社ストラテジット | SaaS連携アプリケーションのマーケットプレイス |
CN115617279A (zh) * | 2022-12-13 | 2023-01-17 | 北京中电德瑞电子科技有限公司 | 分布式云数据的处理方法、装置及存储介质 |
CN115617279B (zh) * | 2022-12-13 | 2023-03-31 | 北京中电德瑞电子科技有限公司 | 分布式云数据的处理方法、装置及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109417557B (zh) | 认证访问托管应用的客户端的方法、***和计算机可读介质 | |
US9455960B2 (en) | Secure application delivery system with dynamic stitching of network connections in the cloud | |
JP5614340B2 (ja) | システム、認証情報管理方法、およびプログラム | |
Singhal et al. | Guide to secure web services | |
JP5567011B2 (ja) | インターネットサービスを提供するための方法およびサービス統合プラットフォームシステム | |
KR101621128B1 (ko) | 보안 관점의 분산 시스템 간의 데이터 전송 제어 | |
US8549112B2 (en) | Computer-readable medium storing access control program, access control method, and access control device | |
JP4301482B2 (ja) | サーバ、情報処理装置及びそのアクセス制御システム並びにその方法 | |
CN101331731B (zh) | 由身份提供商对联盟内的客户进行定制认证的方法、装置和程序产品 | |
JP5375976B2 (ja) | 認証方法、認証システムおよび認証プログラム | |
US8832857B2 (en) | Unsecured asset detection via correlated authentication anomalies | |
US8769128B2 (en) | Method for extranet security | |
WO2005069823A2 (en) | Centralized transactional security audit for enterprise systems | |
US11531777B2 (en) | Methods and systems for restricting data access based on properties of at least one of a process and a machine executing the process | |
JP2008015733A (ja) | ログ管理計算機 | |
JP4573559B2 (ja) | 分散認証システム、負荷分散装置及び認証サーバ、並びに負荷分散プログラム及び認証プログラム | |
US9225713B2 (en) | System, control method, and storage medium | |
JP2011128731A (ja) | 認証連携負荷分散システム、認証連携負荷分散装置、サービス提供装置、認証連携負荷分散方法及びそのプログラム | |
Hanaoui et al. | Security requirements and model for mobile agent authentication | |
Chandersekaran et al. | Information sharing and federation | |
JP2014026348A (ja) | 情報流通システム、認証連携方法、装置及びそのプログラム | |
JP6128958B2 (ja) | 情報処理サーバーシステム、制御方法、およびプログラム | |
Nobayashi et al. | Development of single sign-on system with hardware token and key management server | |
JP2010152690A (ja) | 情報提供装置、情報提供ポータルシステム、情報提供方法、情報提供プログラム | |
Singhal et al. | SP 800-95. Guide to Secure Web Services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20110722 |