説明

中継装置、異なる端末装置間のサービス継続方法、及び中継プログラム

【課題】サービスを提供するサーバの負荷の増大を抑えると共に、メッセージの自動振分に対応できる、異なる端末装置間でサービスの継続利用を可能とするための技術を提供する。
【解決手段】GW装置20は、動画配信サーバ60が提供するサービスを利用している端末装置10のユーザに係わる属性情報を、その動画配信サーバ60が生成した状態(セッション)62の識別子63と対応付けて保存する。端末装置10から識別子63が付加されていないメッセージを受信すると、その端末装置10のユーザの属性情報をSAML認証サーバ30から取得し、取得した属性情報と一致する属性情報が保存されているか否か確認する。その確認により、一致する属性情報が存在していることが判明すると、その属性情報に対応付けた識別子を受信したメッセージに挿入してSLB50に送信する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信ネットワークを介してサーバが端末装置のユーザにサービスを提供するための技術に関する。
【背景技術】
【0002】
現在、インターネットに代表される通信ネットワークは広く社会に普及している。それにより、サーバを用いて、通信ネットワークと接続されたクライアントである端末装置のユーザを対象にした様々なサービスが提供されるようになっている。
【0003】
サービスを提供するサーバは、端末装置から受信したメッセージによりセッションを生成し、その端末装置のユーザを対象にしたサービスを提供する。このセッションは、サーバが1端末装置にサービスを提供するうえでの単位に相当する。このセッションを生成したサーバは、端末装置へのレスポンスとするメッセージに、生成したセッションを識別するための識別子を挿入して送信する。識別子が挿入されたメッセージを受信した端末装置は以降、その識別子を挿入したメッセージをサーバ宛てに送信する。それによりサーバは、端末装置から受信したメッセージ中の識別子により、サービスの提供を継続させることができる。
【0004】
通信ネットワークを介して提供するサービスは通常、多くの人の利用を想定する。利用する人が多くなるほど、サーバの負荷は増大する。このことから、サービスを提供する側は、複数のサーバを用意し、端末装置のユーザにサービスを提供させるサーバをそのうちの一つに振り分ける負荷分散を行うシステム構成を採用するのが普通である。この負荷分散は通常、SLB(Server Load Balancer:負荷分散装置)を用いて行われる。
【0005】
SLBは、識別子とその識別子が割り当てられたセッションを保持するサーバとの関係を保存する。それによりSLBは、識別子が挿入されたメッセージを端末装置から受信した場合、その識別子を有する関係を保存しているか否か確認し、その確認結果に応じて、メッセージの振分先を決定する。決定される振分先は、識別子を有する関係が保存されていれば、その関係から特定されるサーバであり、識別子を有する関係が保存されていなければ、ラウンドロビン方式等の自律振分アルゴリズムにより選択したサーバである。そのように振分先を決定することによりSLBは、同じ端末装置から送信される関連するメッセージは同じサーバに振り分ける一意性保証を実現する。この一意性保証を実現する機能は一意性保証機能(或いはセッション維持機能)と呼ばれる。この一意性保証の実現に用いる関係は以降「一意性保証情報」と呼ぶことにする。自律振分アルゴリズムにより振り分けるメッセージ、つまりサーバがセッションを生成する契機となるメッセージは以降「初期メッセージ」と呼ぶこととする。
【0006】
近年、携帯電話機は多機能化し、大部分の携帯電話機は端末装置として使用できるようになっている。パーソナル・コンピュータ(PC)は安価になり、複数台のPCを所有する人は多い。このようなこともあり、ユーザの多くは、複数の端末装置を使用することができる。
【0007】
ユーザが端末装置を変えてサービスを利用する場合、各端末装置から最初に送信させるメッセージは、何れも初期メッセージとしてサーバに処理される。そのように初期メッセージとして処理した場合、或る端末装置により利用していたサービスは他の端末装置では継続利用することはできない。しかし、ユーザは、異なる端末装置(複数の端末装置)の間でサービスを継続して利用することを望む場合がある。例えば映像の配信サービスでは、ユーザは、端末装置を変えても、視聴中の映像は視聴していない箇所から視聴を継続したいと望むことが多い。このようなことから現在では、異なる端末装置の間でサービスを継続して利用できるようにする技術が創案されている。この技術は以降「サービス継続技術」と呼ぶことにする。
【0008】
従来のサービス継続技術としては、例えば特許文献1及び2に記載されたものがある。特許文献1に記載の従来のサービス継続技術では、サービスの継続を可能とさせるための専用のデバイスを用意して、その専用デバイスにセッショに係わる情報(セッション情報)を記録する。この記録したセッション情報を用いることにより、別の端末装置でサービスの継続を可能とさせる。そのようにして専用デバイスは、異なる端末装置間でのセッション情報の共有化に用いる。専用デバイスは、端末装置との通信により、セッション情報の取得、更新、或いは提供を行う。
【0009】
特許文献2に記載の従来のサービス継続技術では、サービスを提供するサーバは、端末装置にユーザが入力した識別情報(ユーザID)を受信して、関係がある既存のセッションが存在するか否か判定する。その判定結果に応じてサーバは、新たなセッションの生成、及び既存のセッションへの再関連の何れかを行う。そのセッションへの再関連により、ユーザは別の端末装置を用いてサービスの継続した利用を行うことができる。
【0010】
専用デバイスを用意する場合、サービスを提供するうえでのコストの上昇、或いはユーザの経済的負担を増大させる。また、端末装置(に実行させるプログラム)は、専用デバイスに対応させる必要がある。その対応のために、端末装置のユーザは煩わしい操作等を行わなければならない。このようなことから、特許文献1に記載の従来のサービス継続技術は、望ましいものではない。
【0011】
特許文献2に記載の従来のサービス継続技術では、コストの上昇やユーザの経済的負担の増大は共に抑えることができる。しかし、サーバは、識別情報の受信により、既存のセッションのなかから関連するセッションを抽出しなければならない。このため、サーバの負荷は増大する。この負荷の増大は、サービスの質の低下、或いは必要とするサーバの台数の増加、等の不具合を生じさせる。負荷の増大は、多くの人が利用するほど深刻化する。通信ネットワークを介したサービスは、多くの人が利用するのを想定している。このようなことから、サーバにおける負荷の増大は抑えるのが望ましい。
【0012】
上記の通り、多くの人の利用を想定する場合、サービスを提供する側は、複数のサーバを用意し、SLBによりメッセージを自動振分するシステム構成を採用するのが普通である。特許文献2に記載の従来のサービス継続技術は、そのようなシステム構成には対応できない。なぜなら、メッセージを自動振分するSLBは、ユーザが入力した識別情報(ユーザID)からメッセージを送信すべきサーバを特定できないからである。このようなことから、異なる端末装置間のサービスの継続利用では、サーバの負荷の増大を抑える他に、SLBを用いたシステム構成、つまりメッセージの自動振分にも対応できるようにすることも重要である。
【先行技術文献】
【特許文献】
【0013】
【特許文献1】特開2006−191617号公報
【特許文献2】特開2008−102940号公報
【発明の概要】
【発明が解決しようとする課題】
【0014】
本発明は、サービスを提供するサーバの負荷の増大を抑えると共に、メッセージの自動振分に対応できる、異なる端末装置間でサービスの継続利用を可能とするための技術を提供することを目的とする。
【課題を解決するための手段】
【0015】
開示のシステムでは、端末装置と、その端末装置のユーザに通信ネットワークを介してサービスを提供するサーバとの間に、端末装置からサーバに送信されるメッセージを中継する中継装置を配置する。その中継装置は、メッセージを端末装置から受信した場合に、その端末装置のユーザに係わる属性情報を取得し、端末装置からのメッセージによりセッションを生成したサーバがその端末装置へのメッセージ中に挿入する、そのセッションを識別するための識別子を取得し、取得した識別子を、その識別子を挿入したメッセージを送信する端末装置のユーザに係わる属性情報と対応付けて保存し、メッセージを端末装置から受信した場合に、そのメッセージの受信により取得する属性情報と一致する属性情報が保存されているか否か判定し、一致する属性情報が保存されていると判定した場合に、その端末装置から受信したメッセージ中に一致する属性情報に対応付けられた識別子を挿入して送信する中継を行う。
【発明の効果】
【0016】
開示のシステムでは、実際にサービスを提供するサーバの負荷の増大を抑えつつ、メッセージの自動振分が行われるシステム構成であっても、異なる端末装置間でユーザはサービスを継続利用することができる。
【図面の簡単な説明】
【0017】
【図1】本実施形態による中継装置を用いて構築されたサービス提供システムの構成を示す図である。
【図2】本実施形態による中継装置であるGW装置20の機能構成図である。
【図3】端末装置10を代えて動画配信サービスを利用する例のタイミングチャートである。
【図4】携帯端末装置11、PC12、各SLB50、SAML認証サーバ30、及び動画配信サーバ60の動作例を示すシーケンス図である。
【図5】携帯端末装置11、PC12、各SLB50、SAML認証サーバ30、動画配信サーバ60、及び一意性保証情報設定管理装置70の動作例を示すシーケンス図である。
【図6】属性種別情報テーブル25のデータ構成を説明する図である。
【図7】属性/識別子情報テーブル26のデータ構成、及びエントリへのデータの格納手順を説明する図である。
【図8】サービス名抽出テーブル27のデータ構成を説明する図である。
【図9】セッション位置抽出テーブル28のデータ構成を説明する図である。
【図10】認証問い合わせ要求と認証アサーションの構文例を説明する図である。
【図11】属性問い合わせ要求と属性アサーションの構文例を説明する図である。
【図12】SIPメッセージ例を説明する図である。
【図13】HTTPメッセージ例を説明する図である。
【図14】メッセージ中継処理のフローチャートである。
【図15】本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0018】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図1は、本実施形態による中継装置を用いて構築されたサービス提供システムの構成を示す図である。このサービス提供システムは、不図示の通信ネットワークを介して接続されるクライアントである端末装置10のユーザを対象にサービスを提供するために構築されている。図1には端末装置10として、携帯電話機、PDA、或いはノート型のPC等の携帯が容易な携帯端末装置11、及びデスクトップ型、或いはノート型の通常は携帯しないPC12を示している。端末装置10は、それらに限定されるものではなく、通信ネットワークを介した通信が可能なテレビジョン、及びカーナビゲーション装置等も端末装置10として使用するのが可能である。ここでは便宜的に、端末装置10としては携帯端末装置11、及びPC12のみを想定することとする。携帯端末装置11、及びPC12の表記は、端末装置10を区別する場合にのみ用いる。区別する必要がない場合は端末装置10と表記する。
【0019】
サービス提供システムは、GW(GateWay)装置20、SAML(Security Assertion Markup Language)認証サーバ30、及びサービス処理システム40を備えている。本実施形態による中継装置は、GW装置20として実現されている。
【0020】
SAMLは、周知のように、ID/パスワードなどの認証情報を安全に交換するための仕様である。SAML認証サーバ30は、端末装置10から送信される認証情報を用いて認証を行い、その認証によって端末装置10のユーザがアカウントの登録者であることを確認した場合に、認証済みであることを示すアーティファクト(認証情報)を発行する。
【0021】
アーティファクトは、他のサイトへのアクセスを可能にするGSSO(Global Single Sign On)を実現させる。SAML認証サーバ30は、アーティファクトにより、そのアーティファクトから特定されるアサーションを発行する。GSSOは、このアサーションを他のサイトが信用し、認証済みと見なすことで実現される。SAML仕様では、アサーションとして、認証済みのユーザについての情報を伝えるメッセージである認証アサーション、そのユーザの属性情報を伝える属性アサーション、ユーザ(サブジェクト)が特定のリソースへのアクセスが許可されているか否かを示す認可決定アサーションの3種類が存在する。
【0022】
このように、SAML認証サーバ30はGSSOを実現させるために用意される。複数のサイトで認証結果を利用できることから、サービス提供システムにとって必須の構成要素ではない。SAML認証サーバ30は、他のサイトに用意されたものであっても良く、複数のサイトにそれぞれ用意されていても良い。ここでは便宜的に、SAML認証サーバ30は1台のみとする。
【0023】
SAML認証サーバ30は、認証のためにリポジトリ31を備えている。このリポジトリ31は、具体的には例えば補助記憶装置、或いは接続されたストレージ装置である。リポジトリ31には、認証情報データベース(DB)35、認証アサーション情報テーブル36、及び属性情報DB37が格納されている。
【0024】
認証情報DB35には、アカウントの登録者毎にその認証情報が格納されている。図1中に表記の「id01/pas1」は、認証情報として格納されたID/パスワードを表している。ここでは、認証情報としてID/パスワードを想定する。
【0025】
認証済みか否かの確認は、アーティファクトによるSAML認証サーバ30のアサーションの発行の有無から行われる。認証アサーション情報テーブル36は、発行したアーティファクトとそのアーティファクトが割り当てられたアサーションの対応関係を管理するためのテーブルである。図1中の1エントリ(レコード)に表記の「AAA」「携帯端末ユーザA」は、携帯端末装置11を使用するユーザAの認証によって「AAA」のアーティファクトが発行されたことを表している。実際には、1エントリに、アーティファクトと、例えばそのアーティファクトが割り当てられた認証アサーション、属性アサーションの各保存場所を示す保存場所情報とが格納される。SAML認証サーバ30は、認証を行う度に、認証アサーション情報テーブル36にエントリ(レコード)を追加する。
【0026】
属性情報DB37は、アカウントの登録者毎に、その登録者に係わる属性情報を格納したテーブルである。図1中の1エントリに表記の「CN=Taro Suzuki,TEID=id01,UID=id03」は、氏名(CN)はTaro Suzuki、携帯端末装置12でのID(端末ID)はid01、PC12でのIDはid03、であることを表している。属性情報としては他に、誕生日(DB)、都市名(L)、都道府県名(ST)、国名(C)、等が存在する。組織に属する人では、属性情報に、グループ名(OG)、組織名(OU)、職種(O)が含まれる。認証アサーション、及び属性アサーションは、この属性情報DB37から抽出される属性情報を用いて生成される。
【0027】
GW装置20は、端末装置10と不図示の通信ネットワークを介して接続され、端末装置10から送信されたメッセージを中継する。サービスの提供に係わるメッセージは、サービス処理システム40に転送する。それにより、サービス処理システム40にメッセージを処理させ、端末装置10のユーザが望むサービスの提供を実現させる。
【0028】
サービス処理システム40は、例えば通信プロトコル毎に用意されたSLB50、動画配信サービス等の複数のサービスを提供する複数の動画配信サーバ60、及びSLB50への一意性保証情報の設定を管理する一意性保証情報設定管理装置70を備えている。
【0029】
図1では、SLB50として、50a及び50bの符号を付した2台を示している。動画配信サーバ60も、60a及び60bを付した2台を示している。50a、50b、60a及び60bの各符号も端末装置10と同様に、区別する必要がある場合のみ用いることとする。
【0030】
各動画配信サーバ60は、アプリケーション・プログラム(以降「アプリケーション」と略記)61を実行することにより、端末装置10のユーザを対象にしたサービスを提供する。サービスを提供していないユーザが使用する端末装置10から送信されたメッセージ(初期メッセージ)を受信すると、状態62を生成し、その状態62を一意に識別できる識別子63を割り当てる。図1中に表記の「α1」は識別子63を表している。
【0031】
上記サービスとは、動画の配信に係わるものである。サービスの種類は特に限定するものではないが、ここでは便宜的に、映画やドラマ等の動画配信サービス、テレビジョン会議用に動画と音声を配信するTV会議サービスを想定する。サービスの提供は、状況に応じた処理をアプリケーション61が実行することにより実現される。状態62は、状況に応じた処理を実行するために生成する。このことから、状態62はセッションを維持している間のみ存在する、セッションの存在の他に、状況を示す情報である。
【0032】
アプリケーション61は、状態(セッション)62を生成すると、そのセッションに係わるデータ(セッションデータ)を保存する。そのセッションデータは、識別子63、及びセッションに付随するデータを含むものである。アプリケーション61には、セッション情報監視・通知部61aが搭載されている。この通知部61aは、アプリケーション61によるセッションの生成を監視し、生成されたセッションに係わる情報(セッション情報)を一意性保証情報設定管理装置(以降「設定管理装置」と略記)70に通知する。このセッション情報は少なくとも識別子63を含んでいる情報である。
【0033】
SLB50は、通信プロトコル毎に用意されている。初期メッセージは1台のSLB50によって1台の動画配信サーバ60に転送され、その動画配信サーバ60は、識別子63を挿入したメッセージをレスポンスとしてそのSLB50に送信する。このため、同じ端末装置10から送信される関連するメッセージを同じ動画配信サーバ60に転送するための一意性保証情報は、初期メッセージを転送したSLB50にのみ設定されるのが普通である。しかし、このように一意性保証情報を設定した場合、端末装置10から通信プロトコルを変えて送信されるメッセージは、転送すべき動画配信サーバ60に転送できるとは限らない。本実施形態では、そのような通信プロトコルの変更は、設定管理装置70により対応できるようにしている。
【0034】
設定管理装置70は、動画配信サーバ60からセッション情報を取得すると、そのセッション情報を用いて、初期メッセージを転送していないSLB50に設定すべき一意性保証情報を生成し、そのSLB50に送信する。そのようにして、初期メッセージを転送していないSLB50にも一意性保証情報を登録させることにより、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる。本実施形態では、初期メッセージを転送したSLB50への一意性保証情報の登録も併せて行わせている。
【0035】
一意性保証情報は、状態(セッション)62に割り当てられた識別子63と、その状態62を生成した動画配信サーバ60との関係を示す情報である。動画配信サーバ60を示す情報とは、例えばアドレス、各動画配信サーバ60に割り当てられた固有の識別子、である。
【0036】
動画配信サーバ60からのメッセージは、SLB50を介してGW装置20に送信される。しかし、そのメッセージは、SLB50等を中継することなく端末装置10に送信しても良い。そのようにメッセージを送信する場合には、設定管理装置70に各SLB50への一意性保証情報の登録を行わせれば良い。一意性保証情報の登録は、セッションを生成した動画配信サーバ60に行わせても良い。一意性保証情報の設定用に設定管理装置70を用意しているのは、各動画配信サーバ60の負荷をより抑えるためである。
【0037】
携帯端末装置11及びPC12を使用できるユーザでは、外出中は携帯端末装置11によりサービスを利用し、外出から戻ったらPC12によりサービスを利用するケースが考えられる。その逆のケースも考えられる。動画配信サービスでは、それら何れのケースでも、ユーザは端末装置10を代えた後、動画を最初から視聴しようと望む可能性は低いと思われる。これは、動画を視聴していたユーザは、その続きが気になって、視聴していた時点以降の動画を直ちに視聴したいと望む場合が多いと考えられるからである。このことから本実施形態では、異なる端末装置10間でサービスを継続して利用できるようにしている。
【0038】
図3は、端末装置10を代えて動画配信サービスを利用する例のタイミングチャートである。この図3に示す例は、最初に携帯端末装置11を用いて動画配信サービスを利用した後、PC12を用いて動画配信サービスを継続して利用した場合である。通信プロトコルは、携帯端末装置11ではSIP(Session Initiation Protocol)、PC12ではHTTP(HyperText Transfer Protocol)が用いられている。以降は便宜的に、携帯端末装置11及びPC12それぞれに用いられる通信プロトコルはSIP及びHTTPのみと想定する。SLB50aはSIP専用、SLB50bはHTTP専用と想定する。
【0039】
端末装置10からのメッセージの振分は、そのメッセージの通信プロトコルに対応するSLB50が行う。その振分は、メッセージから状態62の識別子63を抽出できた場合、登録されている一意性保証情報を参照して行われる。本実施形態では、このことに着目し、異なる端末装置10間でのサービスの継続利用は、端末装置10から送信されるメッセージのなかで識別子63を挿入すべきメッセージを抽出し、抽出したメッセージに識別子63を挿入することで実現させる。そのメッセージの抽出、及び抽出したメッセージへの識別子63の挿入は、GW装置20により実現させている。
【0040】
上記のようにメッセージに識別子63を挿入する場合、SLB50は識別子63から転送すべき動画配信サーバ60を特定することができる。動画配信サーバ60は、GW装置20によって識別子63が挿入されたメッセージを、それまで受信していたメッセージと同様に処理することができる。このようなことから、基本的にサービス処理システム40側の変更を行うことなく、異なる端末装置10間でのサービスの継続利用を可能にすることができる。動画配信サーバ60の負荷の増大は回避できるか、或いは抑えることができる。これらも、GW装置20によりサービスの継続利用を可能とさせた理由である。
【0041】
図2は、本実施形態による中継装置であるGW装置20の機能構成図である。このGW装置20は、図2に示すように、メッセージ受信/送信部21、メッセージ間関係付けテーブル作成部22、識別子抽出/挿入部23、及び格納部24を備えている。格納部24には、属性種別情報テーブル25、属性/識別子情報テーブル26、サービス名抽出テーブル27、及びセッション位置抽出テーブル28が格納されている。
【0042】
GW装置20は、SLB50を介して動画配信サーバ60が端末装置10宛てに送信したメッセージを受信し、そのメッセージ中の識別子63を抽出して保存する。その識別子63には、端末装置10のユーザに係わる属性情報を対応付ける。属性情報は、使用する端末装置10が異なっても、ユーザが同じであれば変化しない。このことから属性情報は、端末装置10から送信されたメッセージのなかで識別子63を挿入すべきメッセージ、及びメッセージに挿入すべき識別子63の特定の両方に用いている。
【0043】
動画配信サーバ60が提供するサービスの利用は、SAML認証サーバ30による認証を前提としている。このため、端末装置10のユーザに係わる属性情報は、SAML認証サーバ30から取得できる。これは、端末装置10側に、属性情報等のユーザを識別するための情報を送信する機能を新たに搭載させることなく、必要な属性情報を得られることを意味する。識別子63に属性情報を対応付けるのは、端末装置10側に新たな機能を追加する必要性を回避できることも理由の一つである。属性情報の取得方法は、認証結果を利用して取得する以外の方法であっても良い。
【0044】
格納部24に格納されたテーブル25〜28は、上記のようにしてメッセージに識別子63を挿入するために用いられる。各部21〜23の説明の前に、これらのテーブル25〜28について、図6〜図9を参照して具体的に説明する。
【0045】
図6は、属性種別情報テーブル25のデータ構成を説明する図である。この属性種別情報テーブル25は、動画配信サーバ60が提供可能なサービス(ここでは動画配信サービス、及びTV会議サービス)毎に、ユーザの特定に用いる属性の種別をまとめたものである。属性種別情報は、属性の種別をまとめたもの、つまり属性の組み合わせに相当する。図6において、「movie」は動画配信サービス、「TVconference」はTV会議サービスをそれぞれ表している。上記したように、「CN」「DB」「L」「OG」「OU」「O」及び「C」はそれぞれ、氏名、誕生日、都市名、グループ名、組織名、職種、及び国名を表している。
【0046】
図6に示すように、属性種別情報、つまりユーザを特定するための属性の組み合わせは、サービスによって異なっている。これは、サービスによって対象とする人が異なるからである。動画配信サービスは、個人を対象にするのに対し、TV会議サービスは、複数の人を対象にするからである。このことから、動画配信サービスでは、ユーザ自身に係わる属性情報、TV会議サービスでは、ユーザが属する組織に係わる属性情報をそれぞれユーザの識別に用いている。
【0047】
図8は、サービス名抽出テーブル27のデータ構成を説明する図である。このサービス名抽出テーブル27は、端末装置10が送信したメッセージから、そのメッセージの通信プロトコル、及び要求されたサービスを特定するためのテーブルである。図8では、以下のようにして、通信プロトコルとサービスを特定することを示している。図8中の「HTTP/movie」「HTTP/TVconference」及び「SIP/movie」はそれぞれ、HTTPにより提供される動画配信サービス、HTTPにより提供されるTV会議サービス、SIPにより提供される動画配信サービスを表している。
【0048】
メッセージは、IPヘッダ、通信プロトコルに応じたヘッダ、及び通信プロトコルに応じたボディを備えた構成である。図8中の「IPヘッダ値」及び「メッセージヘッダ値」はそれぞれ、IPヘッダ及び通信プロトコルに応じたヘッダから抽出する対象となるフィールド値を示す項目である。それにより、これらの項目名は「ヘッダ値」項目の下位に位置している。通信プロトコルに応じたヘッダ、及びボディについては、例えば「SIPヘッダ」「HTTPヘッダ」のように、通信プロトコル名を付した表記を用いる。
【0049】
「IPヘッダ値」項目は、通信プロトコルの特定に用いられる。「IPヘッダ」項目中の「受信ポート」項目の欄に表記した「80」「5060」は、動画配信サーバ60がメッセージの受信に用いるポート番号を表している。つまり、動画配信サーバ60は、HTTP、SIPの各メッセージの受信にそれぞれ番号が「80」「5060」のポートを用いることを表している。このことから本実施形態では、IPヘッダ中のポート番号から、メッセージの通信プロトコルを特定している。「Protocol ID」項目の値として表記の「tcp」「udp」はそれぞれ、HTTP、SIPに割り当てられた識別子63を表している。ポート番号は、IPアドレスの下に割り当てられたサブアドレスである。
【0050】
図12及び図13に示すように、通信プロトコルに応じたヘッダ、及びボディの各構成は通信プロトコルによって異なる。「メッセージヘッダ値」項目は、通信プロトコルに応じたヘッダからサービスを特定するのに用いられる。具体的には「メッセージヘッダ値」項目中の「Request−URI」項目の欄に表記の「/movie」及び「/conference」はそれぞれ、動画配信サービス及びTV会議サービスと特定される文字列を表している。それらの文字列は、例えば図13に示すように、HTTPヘッダのGETメソッドとして記述される文字列である。このことから「Request−URI」項目は、HTTPメッセージが要求するサービスの特定に用いられる。
【0051】
「Route」項目は、SIPメッセージが要求するサービスの特定に用いられる。その項目の欄に表記の「SIP:192.168.0.100:5060」は、動画配信サービスと特定される文字列を表している。この文字列は、図12(a)に示すように、SIPヘッダのRouteヘッダにフィールド値として記述される。
【0052】
図9は、セッション位置抽出テーブル28のデータ構成を説明する図である。このセッション位置抽出テーブル28は、サービス毎に、状態(セッション)62の識別子63がメッセージ内に挿入された位置(セッション位置)を特定するためのテーブルである。そのセッション位置は、通信プロトコル毎に定義されている。セッション位置は、通信プロトコルが同じであればサービスの種類によって変化しない。HTTPメッセージでは、図13に示すように、HTTPヘッダのCookieフィールドである。SIPメッセージでは、図12(b)に示すように、SIPヘッダのContactフィールドである。識別子63は、「session=」の後に記述される。このことからセッション位置抽出テーブル28は、動画配信サーバ60が送信したメッセージ(応答メッセージ)から識別子63を抽出する他に、端末装置10が送信したメッセージへの識別子63の挿入にも用いられる。
【0053】
図7は、属性/識別子情報テーブル26のデータ構成、及びエントリへのデータの格納手順を説明する図である。このテーブル26は、端末装置10から送信されたメッセージのなかで識別子63を挿入すべきメッセージに識別子63を挿入するために用いられる。
【0054】
エントリ(レコード)は、端末装置10のユーザが要求したサービス毎に登録される。1エントリ(レコード)には、サービス名、属性情報、及び識別子情報が格納される。サービス名は、端末装置10のユーザが要求したサービスの種類を表し、識別子情報は、そのサービスの要求によって生成された状態(セッション)62の識別子63を表している。属性情報としては、そのサービスの種類に応じた属性情報の組み合わせが格納される。
【0055】
動画配信サーバ60が提供するサービスの利用には、SAML認証サーバ30による認証が必要である。これは、動画配信サーバ60が状態62を生成する初期メッセージは認証後に端末装置10から送信されることを意味する。このため、図7(a)のエントリ生成前の状態(ここではエントリが存在しない初期状態)で生成されるエントリには、図7(b)に示すように、サービス名と属性情報が格納される。その後、初期メッセージへの応答メッセージにより、図7(c)に示すように、その応答メッセージに挿入された識別子63が識別子情報として格納される。生成されたエントリは、予め定めた条件が満たされた場合に消去される。その条件とは、状態62が維持される期間に応じて定義されたものか、或いは状態62を消去した旨の通知の受信である。
【0056】
格納部24に格納されたテーブル25〜28において、テーブル25、27及び28は予め固定的に用意される。しかし、属性/識別子情報テーブル26は、上記のように、GW装置20が随時、更新する。その更新により、テーブル26には、端末装置10が送信したメッセージのなかから識別子63を挿入すべきメッセージを抽出し、抽出したメッセージに識別子63を挿入するための情報(以降「識別子挿入情報」と呼ぶ)が必要なだけ格納(登録)される。このため、GW装置20は、テーブル26を参照することにより、識別子63を挿入すべきメッセージに挿入すべき識別子63を挿入することができる。
【0057】
テーブル26の1エントリに格納される識別子挿入情報は、サービス名、属性情報、及び識別子情報を備えた構成である。サービス名を格納するのは、動画配信サーバ60は複数のサービスを提供できるからである。動画配信サーバ60が提供するサービスが1種類のみの場合には、サービス名は格納しなくとも良い。このことから識別子挿入情報は、少なくとも、識別子情報、及び属性情報を含む情報であれば良い。
【0058】
次に、図2に示す各部21〜23の動作について具体的に説明する。
メッセージ受信/送信部21は、端末装置10とSLB50との間で送受信されるメッセージを中継する。認証済みのユーザが使用する端末装置10は、その認証によって得られたアーティファクトを挿入したメッセージを送信する。メッセージ受信/送信部21は、アーティファクトが挿入されたメッセージを受信した場合、そのアーティファクトを用いて生成したメッセージである認証問い合わせ要求をSAML認証サーバ30に送信することにより、認証アサーションを取得する。その認証アサーションは受信したメッセージと共に識別子抽出/挿入部23に渡す。
【0059】
図10は、認証問い合わせ要求と認証アサーションの構文例を説明する図である。図10(a)は認証問い合わせ要求、図10(b)は認証アサーションをそれぞれ示している。図10(a)において、アーティファクトは「BBB」に相当する。メッセージ受信/送信部21は、図10(a)のような認証問い合わせ要求を生成してSAML認証サーバ30に送信することにより、図10(b)に示すような認証アサーションを取得する。その認証アサーションには、図4に示すように、認証に用いた認証手段、有効期間の他に、氏名(CN)、端末ID(TEID)、誕生日(DB)、都市名(L)、都道府県名(ST)、国名(C)、等の属性情報が記述されている。
【0060】
識別子抽出/挿入部23は、図8のサービス名抽出テーブル27を参照して、渡されたメッセージの通信プロトコル、及びそのメッセージが要求するサービス(サービス名)を特定する。その特定結果を用いて、図9のセッション位置抽出テーブル28を参照し、渡されたメッセージに識別子63(図12(b)或いは図13)が挿入されているか否か判定する。識別子63が挿入されていると判定した場合、その旨をメッセージ受信/送信部21に通知する。識別子63が挿入されていないと判定した場合、例えば渡されたメッセージが要求するサービスの属性種別情報を図6の属性種別情報テーブル25から抽出し、渡された認証アサーション80に必要な属性情報(属性値)が全て存在するか否か判定する。必要な属性情報が全て存在すると判定した場合、特定したサービス名、及び必要とする属性情報が格納されたエントリを図7の属性/識別子情報テーブル26から抽出する。足りない属性情報が存在すると判定した場合、その旨をメッセージ受信/送信部21に通知する。
【0061】
識別子抽出/挿入部23は、対応するエントリを抽出できた場合、図9のセッション位置抽出テーブル28を参照して、そのエントリに格納された識別子63を渡されたメッセージに挿入し、その挿入後のメッセージをメッセージ受信/送信部21に渡す。エントリを抽出できたことは、ユーザが端末装置10を代えて、利用中のサービスを継続利用しようとしていることを意味する。対応するエントリを抽出できなかった場合、識別子63を挿入できない旨をメッセージ受信/送信部21に通知する。
【0062】
メッセージ受信/送信部21は、識別子63が挿入されている旨の通知を受け取った場合、メッセージを対応するSLB50に送信する。メッセージが渡された場合も同様に、そのメッセージを対応するSLB50に送信する。そのようにして送信されたメッセージは何れも、挿入された識別子63により、SLB50によって転送すべき動画配信サーバ60に転送される。一方、識別子63を挿入できない旨の通知を受け取った場合は、端末装置10から受信したメッセージは初期メッセージと見なし、そのまま対応するSLB50に送信する。それにより、メッセージの転送先とする動画配信サーバ60をSLB50の自動振分機能により選択させる。
【0063】
足りない属性情報が存在する旨の通知を受け取ったメッセージ受信/送信部21は、アーティファクトを用いて生成したメッセージである属性問い合わせ要求をSAML認証サーバ30に送信することにより、属性アサーションを取得する。図11(a)は属性問い合わせ要求、図11(b)は属性アサーションの構文例をそれぞれ示している。この属性アサーションには、図4に示すような認証アサーション80には存在しない属性情報が記述されている。メッセージ受信/送信部21は、取得した属性アサーションを識別子抽出/挿入部23に渡す。
【0064】
このようにして本実施形態では、最初に認証アサーション80を取得し、属性アサーションは必要に応じて取得するようにしている。それにより、SAML認証サーバ30との間のメッセージ交換を行う頻度を抑えている。属性種別情報テーブル25におけるサービス毎の属性種別情報(属性の組み合わせ)の定義は、認証アサーション80及び属性アサーションにそれぞれ記述された属性を考慮して行っている。このことから、属性種別情報が組み合わせを示す属性の値は、認証アサーション80及び属性アサーションのうちの少なくとも一方に記述されている。
【0065】
図6に示すように、必要とする属性の組み合わせはサービス毎に定義している。このことから、各アサーションに値が記述される属性の組み合わせをサービスに応じて決定しても良い。つまり例えば動画配信サービスでは認証アサーション80のみ、TV会議サービスでは属性アサーションのみを取得するといったように、サービスに応じて取得すべきアサーションを選択するようにしても良い。
【0066】
属性アサーションが渡された識別子抽出/挿入部23は、特定したサービス名、及び必要とする属性情報が格納されたエントリを図7の属性/識別子情報テーブル26から抽出する。そのエントリを抽出できた場合、図9のセッション位置抽出テーブル28を参照して、そのエントリに格納された識別子63を渡されたメッセージに挿入し(図12(b)或いは図13)、その挿入後のメッセージをメッセージ受信/送信部21に渡す。そのエントリを抽出できなかった場合、識別子63を挿入できない旨をメッセージ受信/送信部21に通知する。
【0067】
メッセージ受信/送信部21は、識別子抽出/挿入部23からメッセージが渡された場合、そのメッセージを対応するSLB50に送信する。それによりSLB50は、挿入した識別子63から特定される動画配信サーバ60をメッセージの転送先として選択する。識別子63を挿入できない旨の通知を受け取った場合は、上記のように、端末装置10から受信したメッセージは初期メッセージと見なし、対応するSLB50に送信する。そのメッセージは、取得済みのアサーションと共にメッセージ間関係付けテーブル生成部22に渡される。
【0068】
メッセージ間関係付けテーブル生成部22は、属性/識別子情報テーブル26に1エントリを生成(追加)し、図6、図8及び図9にそれぞれ示すテーブル25、27及び28を参照して、渡されたメッセージ、及びアサーションからそれぞれ抽出した情報を格納する。それにより生成したエントリには、図7(b)に示すように、サービス名、及び属性値の組み合わせである属性情報が格納される。このようなことから、テーブル26へのエントリの追加は、初期メッセージの受信時に行われる。
【0069】
動画配信サーバ60からの応答メッセージは、SLB50を介してGW装置20に送信される。メッセージ受信/送信部21は、受信した応答メッセージを端末装置10に送信すると共に、メッセージ間関係付けテーブル生成部22に渡す。
【0070】
メッセージ間関係付けテーブル生成部22は、渡された応答メッセージから、図7の属性/識別子情報テーブル26中の対応するエントリを特定し、特定したエントリに、その応答メッセージから図9のセッション位置抽出テーブル28を参照して抽出した識別子63を識別子情報として格納する。対応するエントリの特定は、例えばそのエントリの生成時に、その契機となったメッセージが要求するサービス、及びそのメッセージの送信元アドレスを保存することにより行うことができる。
【0071】
このようにしてGW装置20は、初期メッセージと見なさないメッセージを端末装置10から受信した場合、そのメッセージのアーティファクトにより取得されるアサーションの属性値から挿入すべき識別子63を特定し挿入する。このため、識別子63を挿入したメッセージは、SLB50の一意性保証機能により、転送すべき動画配信サーバ60に転送されることになる。メッセージが転送された動画配信サーバ60は、挿入された識別子63により、既に存在する状態(セッション)62として処理される。このため、端末装置10を代えても、ユーザはそれまで利用していたサービスを継続して利用できることとなる。この結果、例えば図3に示すような時系列でサービスを継続利用することができるようになる。これは、SLB50によりメッセージの転送先を振り分けないシステム構成であっても同じである。
【0072】
アーティファクトを用いて属性情報を取得する場合、GW装置20は必要なデータのみを保存する形となる。他のサービスを利用していない人のデータを扱う必要性は回避され、GW装置20の負荷は抑えられる。このことから本実施形態では、アーティファクトを用いて必要な属性情報を取得している。
【0073】
上記メッセージ受信/送信部21、メッセージ間関係付けテーブル作成部22、及び識別子抽出/挿入部23は、GW装置20がメッセージの中継のためのプログラム(中継プログラム)を実行することで実現される。ここで図15を参照して、本発明を適用可能なコンピュータ、つまりこの中継プログラムを実行することでGW装置20として使用可能なコンピュータについて具体的に説明する。
【0074】
図15に示すコンピュータは、CPU91、メモリ92、入力装置93、出力装置94、外部記憶装置95、媒体駆動装置96、及びネットワーク接続装置97を有し、これらがバス98によって互いに接続された構成となっている。図15に示す構成は一例であり、これに限定されるものではない。例えばサービス処理システム40との接続、及び端末装置10との接続がそれぞれ異なる通信ネットワークを介して実現される場合、ネットワーク接続装置97は複数、備えた構成となる。
【0075】
CPU91は、当該コンピュータ全体の制御を行う。
メモリ92は、プログラムの実行、データ更新等の際に、外部記憶装置95(あるいは可搬型の記録媒体99)に記憶されているプログラムあるいはデータを一時的に格納するRAM等の半導体メモリである。CPU91は、プログラムをメモリ92に読み出して実行することにより、全体の制御を行う。
【0076】
入力装置93は、例えば、キーボード、マウス等の操作装置と接続可能なインターフェースである。接続された操作装置に対するユーザの操作を検出し、その検出結果をCPU91に通知する。
【0077】
出力装置94は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置97は、例えばサービス処理システム40及び端末装置10と通信ネットワークを介して通信を行うためのものである。外部記憶装置95は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【0078】
媒体駆動装置96は、光ディスクや光磁気ディスク等の可搬型の記録媒体99にアクセスするものである。
上記中継プログラムは、外部記憶装置95、若しくは記録媒体99に記録されているか、或いは通信ネットワークを介してネットワーク接続97により取得される。その中継プログラムをメモリ92に読み出してCPU91が実行することにより、GW装置20は実現される。中継プログラムが外部記憶装置95に格納されていると想定する場合、メッセージ受信/送信部21は、例えばCPU91、メモリ92、外部記憶装置95、ネットワーク接続装置97、及びバス98によって実現される。更に、格納部24が外部記憶装置95であると想定した場合には、メッセージ間関係付けテーブル生成部22は、例えばCPU91、メモリ92、外部記憶装置95、及びバス98によって実現される。これは、識別子抽出/挿入部23も同様である。
【0079】
図4は、携帯端末装置11、PC12、各SLB50、SAML認証サーバ30、及び動画配信サーバ60の動作例を示すシーケンス図である。このシーケンス図は、ユーザが端末装置10を携帯端末装置11からPC12に代えて同じサービスを利用するケースを例にとったものである。次に図4を参照して、このケースにおけるそれらの装置の動作について具体的に説明する。
【0080】
図4では、属性/識別子情報テーブルは「TBL−2」と表記している。これは、図5及び図14でも同様である。また、SIP専用のSLB50aは「SLB−A」、HTTP専用のSLB50bは「SLB−B」とそれぞれ表記している。
【0081】
携帯端末装置11によるサービスの利用では、特には図示していないが、ユーザはSAML認証サーバ30にアクセスして認証を行う。その認証は、チャレンジ・レスポンス方式を採用している場合、例えば以下のようにして行われる。
【0082】
先ず、携帯端末装置11は、ID/パスワードを付加していないREGISTERメッセージをSAML認証サーバ30に送信する。SAML認証サーバ30は、そのメッセージの受信により、認証情報を要求するエラーメッセージ(401 Unauthorized)を携帯端末装置11に送信する。そのエラーメッセージを受信した携帯端末装置30は、認証(Authorization)ヘッダに認証情報を格納したメッセージを再度SAML認証サーバ30に送信する。SAML認証サーバ30は、そのメッセージ中の認証情報が表すID/パスワードの組み合わせが認証情報DB35に登録されているか否か確認することにより認証を行う。その認証の結果、ID/パスワードの登録が確認できた場合、アーティファクトを発行し、携帯端末装置11にメッセージにより通知する。また、認証アサーション情報テーブル36に1エントリを生成(追加)し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。ID/パスワードの登録が確認できなかった場合には、再度、上記エラーメッセージを携帯端末装置11に送信する。
【0083】
上記のようにして認証が済んだ後、携帯端末装置11によるサービスの提供の要求が可能となる、その要求は、アーティファクトが挿入されたメッセージ(初期メッセージ)を送信することで行われる(シーケンスS1−3)。そのメッセージはGW装置20によって受信され、GW装置20は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してSAML認証サーバ30に送信することにより、アーティファクト検証を行う(シーケンスS1−4)。その認証問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された認証アサーション80をGW装置20に送信する(シーケンスS1−5)。
【0084】
認証アサーション80を受信したGW装置20は、そのアサーション80に記述された属性情報(属性値)を抽出し、属性/識別子情報テーブル26を参照することにより、受信したメッセージ中に挿入すべき識別子63が存在するか否か確認する。ここでは、受信したメッセージは初期メッセージに相当する。このため、GW装置20は受信したメッセージに識別子63を挿入することなく、SIP専用のSLB50aに送信する。それによりSLB50aは、自動振分機能により選択した動画配信サーバ60にメッセージを転送する(以上、シーケンスS1−6)。GW装置20は、属性/識別子情報テーブル26に1エントリを生成し、サービス名、及び属性情報を格納することも併せて行う。
【0085】
初期メッセージを受信した動画配信サーバ60は、状態62を生成し、識別子63を割り当て、その識別子63を挿入した応答メッセージをSLB50aに送信する。SLB50aは、その応答メッセージを受信し、GW装置20に送信する(シーケンスS1−7)。GW装置20は、受信した応答メッセージを携帯端末装置11に送信すると共に、その応答メッセージから識別子63を抽出し、属性/識別子情報テーブル26の対応するエントリに格納する(シーケンスS1−8)。
【0086】
ユーザが携帯端末装置11に代えてPC12を使用し、同一のサービスを利用する場合、PC12はサービスの提供を要求するメッセージを送信する(シーケンスS2−3)。そのメッセージにはアーティファクトは挿入されていない。このことからGW装置20は、そのメッセージを受信すると、SAML認証サーバ30による認証を行わせる。その認証は、例えばリダイレクトによりPC12をSAML認証サーバ30にアクセスさせることで行う(シーケンスS2−4)。
【0087】
GW装置20は、リダイレクトにより、PC12に転送先を通知する。その通知により、PC12は転送先であるSAML認証サーバ30にアクセスし、SAML認証サーバ30は認証情報を要求する。その要求により、PC12は認証情報をSAML認証サーバ30に送信する。それによりSAML認証サーバ30は、SIPの場合と同様に、受信した認証情報が表すID/パスワードの組み合わせが認証情報DB35に登録されているか否か確認することにより認証を行う。その認証の結果、ID/パスワードの登録が確認できた場合、アーティファクトを発行し、PC12にメッセージにより通知する。このアーティファクトの発行により、認証アサーション情報テーブル36には、図1に示すように、同じユーザ(ユーザA)を対象にするアーティファクトが端末装置10毎に格納されることとなる。
【0088】
上記のようにして認証が済んだ後、PC12はサービスの提供を要求する、アーティファクトが挿入されたメッセージを送信する。そのメッセージを受信したGW装置20は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してSAML認証サーバ30に送信することにより、アーティファクト検証を行う(シーケンスS1−4)。その認証問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された認証アサーション80をGW装置20に送信する(シーケンスS1−5)。
【0089】
認証アサーション80を受信したGW装置20は、そのアサーション80に記述された属性情報を抽出し、属性/識別子情報テーブル26を参照することにより、受信したメッセージ中に挿入すべき識別子63が存在するか否か確認する。ここでは、受信したメッセージは、端末装置10は異なっても、同一のユーザが使用するPC12から送信されたものである。そのユーザに対応するエントリは属性/識別子情報テーブル26に存在する。このため、GW装置20は受信したメッセージに挿入すべき識別子63(図4の「α1」)を例えば図13に示すように挿入し、HTTP専用のSLB50bに送信する。SLB50bには、一意性保証情報設定管理装置70により、対応する一意性保証情報が登録されている。このためSLB50bは、一意性保証情報に従って選択した動画配信サーバ60にメッセージを転送する(以上、シーケンスS2−6)。
【0090】
このようにして、同一のサービスを利用する場合、ユーザが使用する端末装置10を代えても、最初に使用した端末装置10のメッセージが転送された動画配信サーバ60に、それ以降に使用される端末装置10のメッセージは同じ識別子63が挿入されて転送される。このためユーザは、端末装置10を代えてもサービスを継続して利用することができる。
【0091】
図5は、携帯端末装置11、PC12、各SLB50、SAML認証サーバ30、動画配信サーバ60、及び一意性保証情報設定管理装置70の動作例を示すシーケンス図である。このシーケンス図は、図4と同じく、ユーザが端末装置10を携帯端末装置11からPC12に代えて同じサービスを利用するケースを例にとったものである。次に図5を参照して、一意性保証情報設定管理装置70を含む各装置の動作についてより具体的に説明する。
【0092】
先ず、携帯端末装置11は、ID/パスワードを付加していないREGISTERメッセージをSAML認証サーバ30に送信する(シーケンスS101)。SAML認証サーバ30は、そのメッセージの受信により、認証情報を要求するエラーメッセージ(401 Unauthorized)を携帯端末装置11に送信する(シーケンスS102)。
【0093】
そのエラーメッセージを受信した携帯端末装置30は、ユーザの操作に従い、認証ヘッダに認証情報を格納したメッセージを再度SAML認証サーバ30に送信する。SAML認証サーバ30は、そのメッセージ中の認証情報が表すID/パスワードの組み合わせが認証情報DB35に登録されているか否か確認することにより認証を行う。その認証の結果、ID/パスワードの登録が確認できた場合、アーティファクトを発行し、携帯端末装置11にメッセージにより通知する。ID/パスワードの登録が確認できなかった場合には、再度、上記エラーメッセージを携帯端末装置11に送信する。シーケンスS103では、このような認証のためのメッセージの送受信が行われる。ID/パスワードの登録が確認できた場合、SAML認証サーバ30は、認証アサーション情報テーブル36に1エントリを生成(追加)し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。
【0094】
上記のようにして認証が済んだ後、携帯端末装置11はサービスの提供を要求する、アーティファクトが挿入されたメッセージ(初期メッセージ)を送信する(シーケンスS104)。そのメッセージを受信したGW装置20は、そのメッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してSAML認証サーバ30に送信する(シーケンスS105)。その認証問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された認証アサーション80をGW装置20に送信する(シーケンスS106)。
【0095】
認証アサーション80を受信したGW装置20は、そのアサーション80に記述された属性情報を抽出し、受信したメッセージから特定したサービス名を用いて図6の属性種別情報テーブル25を参照することにより、必要な属性情報が全て存在しているか否か判定する。その判定により、足りない属性情報が存在することが判明した場合、属性問い合わせ要求を生成して再度、SAML認証サーバ30に送信する(シーケンスS107)。その属性問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された属性アサーションをGW装置20に送信する(シーケンスS108)。
【0096】
GW装置20は、受信した属性アサーションから足りない属性情報を抽出し、受信したメッセージから特定したサービス名、及び抽出した全ての属性情報を用いて図7の属性/識別子情報テーブル26を参照することにより、対応するエントリの特定を行う。ここでは、携帯端末装置11から受信したメッセージは初期メッセージに相当するため、エントリは特定できない。この結果、受信したメッセージに識別子63を挿入することなく、対応するSLB50aに送信する(シーケンスS109)。GW装置20は、属性/識別子情報テーブル27に1エントリを生成し、サービス名、及び属性情報(指定された各属性の値)を格納することも併せて行う。SLB50aは、受信したメッセージを自動振分機能により選択した動画配信サーバ60に転送する(シーケンスS110)。
【0097】
初期メッセージを受信した動画配信サーバ60は、状態(セッション)62を生成し、識別子63を割り当て、生成した状態(セッション)62に係わるセッション情報を一意性保証情報設定管理装置70に通知する(シーケンスS111)。その通知は、動画配信サーバ60が実行するアプリケーション61に搭載されたセッション情報監視・通知部61aの制御で行われる。一意性保証情報設定管理装置70は、例えば通知されたセッション情報中の識別子63、及びそのセッション情報を通知した動画配信サーバ60を示す情報の組み合わせである一意性保証情報を生成し、各SLB50に送信する(シーケンスS112)。各SLB50は、受信した一意性保証情報を登録し、その旨を返信する(シーケンスS113)。一意性保証情報設定管理装置70は、その返信を受信すると、一意性保証情報の設定が完了した旨を動画配信サーバ60に通知する(シーケンスS114)。動画配信サーバ60は、その通知を受信するのを待って、応答メッセージを対応するSLB50aに送信する(シーケンスS115)。
【0098】
SLB50aは、受信した応答メッセージをGW装置20に送信する(シーケンスS116)。GW装置20は、受信した応答メッセージを携帯端末装置11に送信する(シーケンスS117)。また、その応答メッセージから識別子63を抽出し、属性/識別子情報テーブル26の対応するエントリに格納する。以降、携帯端末装置11から送信されるメッセージは、GW装置20によって識別子63が挿入されることなく、対応するSLB50aに転送され、そのSLB50aによって同じ動画配信サーバ60に転送される。
【0099】
ユーザが携帯端末装置11に代えてPC12を使用し、同一のサービスを利用する場合、PC12はサービスの提供を要求するメッセージを送信する(シーケンスS118)。そのメッセージにはアーティファクトは挿入されていない。このことからGW装置20は、そのメッセージを受信すると、SAML認証サーバ30にアクセスさせるリダイレクト用の応答メッセージをPC12に送信する(シーケンスS118)。それによりPC12は、受信した応答メッセージで指定されるSAML認証サーバ30にメッセージを送信する(シーケンスS120)。
【0100】
メッセージを受信したSAML認証サーバ30は、PC12に認証情報を要求し、その要求によりPC12は、認証情報をSAML認証サーバ30に送信する。それにより、SAML認証サーバ30は、携帯端末装置11(SIP)の場合と同様に、受信した認証情報が表すID/パスワードの組み合わせが認証情報DB35に登録されているか否か確認することにより認証を行う。シーケンスS121では、このような認証のためのメッセージの送受信が行われる。その認証の結果、ID/パスワードの登録が確認できた場合、SAML認証サーバ30は、アーティファクトを挿入したメッセージをPC12に送信する(シーケンスS122)。認証アサーション情報テーブル36には1エントリを生成(追加)し、そのエントリに、発行したアーティファクト、及び生成した各アサーションの保存場所情報を格納する。
【0101】
このようにしてアーティファクトを取得したPC12は、そのアーティファクトを挿入したメッセージを送信する(シーケンスS123)。そのメッセージを受信したGW装置20は、メッセージ中のアーティファクトを挿入した認証問い合わせ要求を生成してSAML認証サーバ30に送信する(シーケンスS124)。その認証問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された認証アサーション80をGW装置20に送信する(シーケンスS125)。
【0102】
認証アサーション80を受信したGW装置20は、そのアサーション80に記述された属性情報を抽出し、受信したメッセージから特定したサービス名を用いて図6の属性種別情報テーブル25を参照することにより、必要な属性情報(属性値)が全て存在しているか否か判定する。その判定により、足りない属性情報が存在することが判明した場合、属性問い合わせ要求を生成して再度、SAML認証サーバ30に送信する(シーケンスS126)。その属性問い合わせ要求を受信したSAML認証サーバ30は、認証アサーション情報テーブル36を参照して、要求された属性アサーションをGW装置20に送信する(シーケンスS127)。
【0103】
GW装置20は、受信した属性アサーションから足りない属性情報を抽出し、受信したメッセージから特定したサービス名、及び抽出した全ての属性情報を用いて図7の属性/識別子情報テーブル26を参照することにより、対応するエントリの特定を行う。この状況では、ユーザはPC12を使用する前に、携帯端末装置11を使用して同じサービスを利用している。このため、エントリは特定できる。この結果、特定したエントリに格納されている識別子63を受信したメッセージに挿入し、対応するSLB50に送信する(シーケンスS128)。SLB50は、一意性保証情報に従って、受信したメッセージを転送すべき動画配信サーバ60に転送する(シーケンスS129)。動画配信サーバ60は、受信したメッセージの応答メッセージを対応するSLB50に送信する(シーケンスS130)。SLB50は、動画配信サーバ60から受信した応答メッセージをGW装置20に転送し(シーケンスS131)、GW装置20は、転送された応答メッセージをPC12に送信する(シーケンスS132)。
【0104】
応答メッセージを受信したPC12は、その後に送信する、関連するメッセージには識別子63を挿入する。このため、GW装置20は以降、PC12から受信したメッセージは識別子63を挿入することなく中継することとなる。
【0105】
図14は、メッセージ中継処理のフローチャートである。このフローチャートは、理解を容易とするために、端末装置10から送信された1メッセージ(要求メッセージ)に対応するために実行される処理を抜粋し、その流れを示したものである。次に図14を参照して、GW装置20の動作について詳細に説明する。図14にフローチャートを示すメッセージ中継処理は、GW装置20に搭載されたCPUが上記中継プログラムを実行することで実現される。
【0106】
先ず、ステップS201では、端末装置10から送信されたメッセージ(要求メッセージ)を受信する。次のステップS202では、図8のサービス名抽出テーブル27を参照して、受信したメッセージの通信プロトコル及び要求するサービスを特定すると共に、図9のセッション位置抽出テーブル29を参照して、識別子63の有無を確認する。特には図示していなが、識別子63を確認できた場合、受信したメッセージを対応するSLB50に送信し、ここでメッセージ中継処理を終了する。それによりステップS203には、識別子63を確認できなかった場合に移行する。
【0107】
ステップS203では、受信したメッセージからアーティファクトの抽出を行うことにより、このメッセージを送信させたユーザが認証を行ったか否か判定する。ユーザが認証を行った後に端末装置10から送信されるメッセージにはアーティファクトが挿入されている。このため、受信したメッセージからアーティファクトを抽出できた場合、判定はYESとなってステップS208に移行する。そのアーティファクトを抽出できなかった場合には、判定はNOとなってステップS207に移行し、SAML認証サーバ30にアクセスさせるリダイレクト用のメッセージを端末装置10に送信した後、このメッセージ中継処理を終了する。
【0108】
ステップS208では、抽出したアーティファクトを用いて認証問い合わせ要求(図10(a))を生成してSAML認証サーバ30に送信する。認証問い合わせ要求を送信した後はステップS209に移行して、SAML認証サーバ30から認証アサーション80(図4及び図10(b))を受信するのを待つ。その認証アサーション80を受信した後に、ステップS210に移行する。
【0109】
ステップS210では、ステップS202で抽出したサービス名を用いて図6の属性種別情報テーブル(図14中「TBL−1」と表記)25を参照し、認証アサーション80から必要な属性値を取得する。属性種別情報テーブル25には、サービス毎に、必要とする属性情報(属性値)の組み合わせ(図14中「属性グループ」と表記)を示す属性種別情報が定義されている。続くステップS211では、該当する属性種別情報が示す属性値を全て取得できたか否か判定する。足りない属性値が存在した場合、判定はNOとなってステップS212に移行し、属性問い合わせ要求(図11(a))を生成してSAML認証サーバ30に送信し、属性アサーション(図11(b)を受信するのを待って、ステップS213に移行する。必要な属性値を全て取得できた場合には、判定はYESとなってステップS213に移行する。
【0110】
ステップS213では、特定したサービス名、及び取得した属性値を用いて図7の属性/識別子情報テーブル26を参照することにより、そのサービス名、及び取得した属性値を格納したエントリが存在するか否か判定する。そのようなエントリが存在した場合、判定はYESとなってステップS214に移行し、そのエントリの識別子63を受信したメッセージ(図14中「MSG」と表記)に付加して対応するSLB50に送信した後、このメッセージ中継処理を終了する。識別子63の付加は、メッセージの通信プロトコルに応じて、図12(b)或いは図13に示すように行う。そのようなエントリが存在しない場合には、判定はNOとなってステップS215に移行する。
【0111】
ステップS215への移行は、受信したメッセージが初期メッセージであることを意味している。このことからステップS215以降では、初期メッセージに対応するための処理が実行される。
【0112】
ステップS215では、属性/識別子情報テーブル26に新規にエントリを登録し、特定したサービス名、及び取得した全ての属性値をそのエントリに格納する。次のステップS216では、受信したメッセージ(初期メッセージ)を対応するSLB50、つまり特定した通信プロトコルのSLB50に送信する。その後はステップS217に移行して、メッセージの送信により返信される応答メッセージを受信するのを待つ。それによりステップS218には応答メッセージ(MSG)の受信後に移行する。
【0113】
ステップS218では、図9のセッション位置抽出テーブル28を参照して、応答メッセージから識別子63を抽出し、抽出した識別子63をステップS215で新規に登録したエントリに格納する。続くステップS219では、応答メッセージを端末装置10に送信する。その送信を行った後、メッセージ中継処理を終了する。
【0114】
なお、本実施形態では、端末装置10からのメッセージに必要に応じて識別子を挿入する中継装置はGW装置20として実現させているが、本実施形態を適用可能な装置はGW装置20に限定されるものではない。端末装置10とサービスを提供するサーバの間に位置している装置であれば、幅広く本実施形態を適用することができる。このことから、SLB50に本実施形態による中継装置を搭載させることも可能である。
【符号の説明】
【0115】
10 端末装置(クライアント)
11 携帯端末装置
12 PC
20 GW(ゲートウェイ)装置
21 メッセージ受信/送信部
22 メッセージ間関係付けテーブル生成部
23 識別子抽出/挿入部
24 格納部
25 属性種別情報テーブル
26 属性/識別子情報テーブル
27 サービス名抽出テーブル
28 セッション位置抽出テーブル
30 SAML認証サーバ
31 リポジトリ
40 サービス処理システム
50、50a、50b SLB
60、60a、60b 動画配信サーバ
61 アプリケーション・プログラム
62 状態(セッション)
63 識別子
70 一意性保証情報設定管理装置

【特許請求の範囲】
【請求項1】
通信ネットワークを介して端末装置からサーバに送信されるメッセージを中継する中継装置であって、
前記メッセージを受信した前記端末装置のユーザに係わる属性情報を取得する属性情報取得手段と、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得する識別子取得手段と、
前記識別子取得手段が取得した識別子を、前記属性情報取得手段が取得した属性情報と対応付けて保存する情報保存手段と、
前記属性情報取得手段が属性情報を取得した場合に、該取得した属性情報と一致する属性情報を前記情報保存手段が保存しているか否か判定する判定手段と、
前記属性情報取得手段が取得した属性情報に一致する属性情報を前記情報保存手段が保存していると前記判定手段が判定した場合に、該属性情報取得手段が属性情報を取得する契機となったメッセージ中に該属性情報に対応付けられた識別子を挿入する識別子挿入手段と、
前記識別子挿入手段が識別子を挿入したメッセージを送信する中継手段と、
を具備することを特徴とする中継装置。
【請求項2】
前記情報保存手段は、前記識別子、及び前記属性情報を、前記識別子が挿入されたメッセージにより前記サーバに要求されるサービスと対応付けて保存する、
ことを特徴とする請求項1記載の中継装置。
【請求項3】
前記属性情報取得手段は、前記端末装置のユーザが認証済みであることを示す認証情報を用いて、該ユーザに係わる属性情報を取得する、
ことを特徴とする請求項1、または2記載の中継装置。
【請求項4】
前記識別子挿入手段は、前記端末装置から受信したメッセージの通信プロトコルを判別し、該判別結果に応じて、該メッセージ中に前記識別子を挿入する位置を決定する、
ことを特徴とする請求項1記載の中継装置。
【請求項5】
端末装置のユーザに通信ネットワークを介してサーバが提供するサービスを該ユーザが使用する異なる端末装置の間で継続して利用可能とする方法において、
前記通信ネットワークを介して前記端末装置から前記サーバに送信されるメッセージを中継する中継装置に、
前記メッセージを前記端末装置から受信した場合に、該端末装置のユーザに係わる属性情報を取得させ、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得させ、
該識別子を、該識別子を挿入したメッセージを送信する端末装置のユーザに係わる属性情報と対応付けて保存させ、
前記メッセージを前記端末装置から受信した場合に、前記メッセージの受信により取得する属性情報と一致する属性情報が保存されているか否か判定させ、
前記一致する属性情報が保存されていると判定した場合に、前記端末装置から受信したメッセージ中に該一致する属性情報に対応付けられた識別子を挿入して送信する中継を行わせる、
ことを特徴とする異なる端末装置間のサービス継続方法。
【請求項6】
前記属性情報を取得する契機となったメッセージにより前記サーバに要求されるサービスを特定し、該特定したサービスは該属性情報と対応付けて保存する、
ことを特徴とする請求項5記載の異なる端末装置間のサービス継続方法。
【請求項7】
前記属性情報は、前記端末装置のユーザが認証済みであることを示す認証情報を用いて取得する、
ことを特徴とする請求項5、または6記載の異なる端末装置間のサービス継続方法。
【請求項8】
通信ネットワークを介して端末装置からサーバに送信されるメッセージを中継する中継装置として用いられるコンピュータに、
前記メッセージを受信した前記端末装置のユーザに係わる属性情報を取得する属性情報取得機能と、
前記端末装置からのメッセージによりセッションを生成したサーバが該端末装置へのメッセージ中に挿入する、該セッションを識別するための識別子を取得する識別子取得機能と、
前記識別子取得機能により取得した識別子を、前記属性情報取得機能により取得した属性情報と対応付けて保存する情報保存機能と、
前記属性情報取得機能により属性情報を取得した場合に、該取得した属性情報と一致する属性情報を前記情報保存機能により保存しているか否か判定する判定機能と、
前記属性情報取得機能により取得した属性情報に一致する属性情報を前記情報保存機能により保存していると前記判定機能により判定した場合に、該属性情報取得機能による属性情報を取得する契機となったメッセージ中に該属性情報に対応付けられた識別子を挿入する識別子挿入機能と、
前記識別子挿入機能により識別子を挿入したメッセージを送信する中継機能と、
を実現させるための中継プログラム。

【図2】
image rotate

【図3】
image rotate

【図1】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate


【公開番号】特開2011−76425(P2011−76425A)
【公開日】平成23年4月14日(2011.4.14)
【国際特許分類】
【出願番号】特願2009−227924(P2009−227924)
【出願日】平成21年9月30日(2009.9.30)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】