JP5942503B2 - サービス要求装置、サービス要求方法およびサービス要求プログラム - Google Patents

Description

本発明は、サービス要求装置、サービス要求方法およびサービス要求プログラムに関する。

従来、複数のサービスを連携させて新たなサービスを提供するマッシュアップなどと呼ばれるＷｅｂサービスが知られている。例えば、サービス連携の一形態としては、提供元が異なる複数のサービスを連携させる印刷サービスなどが挙げられる。具体的には、ユーザは、Ｂ社が提供する文書管理サービスにデータを保管する。Ａ社は、Ｂ社に預けられたユーザのデータを取得して、自社が提供する印刷サービスを利用してＣ社の印刷機に印刷する。

このようなサービス連携には、ＯＡｕｔｈ２．０を用いた認証方法が利用される。ＯＡｕｔｈ２．０を用いた認証方法では、事前認証フェーズと確認フェーズとが実行される。例えば、事前認証フェーズでは、ユーザは、Ｗｅｂブラウザ等を用いてＡ社にアクセスしてユーザ認証を実行し、認証結果がＯＫの場合に、Ａ社に印刷サービスを要求する。Ａ社は、印刷サービスの要求を受信すると、ユーザ端末を経由したリダイレクトで、データの提供をＢ社に依頼する。

確認フェーズでは、ユーザは、Ｗｅｂブラウザ等を用いてＢ社との間で認証を実施する。そして、Ｂ社は、ユーザ端末を介して、ユーザによる認証結果をＡ社に送信する。その後、Ａ社は、印刷サービスを実行するＡＰＩ（Application Program Interface）を用いて、アクセストークンの要求をＢ社に送信する。Ｂ社は、ユーザデータを取得するＡＰＩを示すアクセストークンを応答する。そして、Ａ社は、Ｂ社から受信したアクセストークンをＢ社に送信し、ユーザデータの取得を要求する。こうして、Ｂ社は、Ａ社に対してユーザデータを提供する。

このように、確認フェーズにおいて、Ａ社とＢ社との間で、ユーザに許可された許可証であるアクセストークンをやり取りすることで、アクセス権の権限委譲を実行し、セキュアなサービス連携を実現している。また、ＯＡｕｔｈ２．０では、サービスにログイン中であれば、アクセストークンの有効期間内では確認フェーズを省略して、サービス連携を実行させる。

OAuth2.0 IETF draft-ietf-oauth-v2-22 "http://tools.ietf.org/html/draft-ietf-oauth-v2-22"

しかしながら、従来技術では、大量のサービス要求が発生すると、ＯＡｕｔｈ処理の確認フェーズが大量に実行される場合があり、ＯＡｕｔｈ処理がボトルネックとなって処理性能が劣化するという問題がある。

例えば、ＯＡｕｔｈ２．０では、新規のユーザやログアウト後に再度ログインしたユーザに対しては、事前認証フェーズと確認フェーズの両方を実行する。このため、これらに該当する大量のユーザが上記Ａ社にサービス要求を送信した場合、Ａ社では、大量のＯＡｕｔｈ処理を実行することになり、処理負荷が高くなる。この場合、Ａ社では、ＯＡｕｔｈ処理そのものの遅延やＢ社へのデータ送信などの他の処理の遅延が発生するので、サービス全体として性能が劣化する。

１つの側面では、処理性能の劣化を抑制できるサービス要求装置、サービス要求方法およびサービス要求プログラムを提供することを目的とする。

第１の案では、サービス要求装置は、記憶部と判定部と要求部とを有する。記憶部は、ユーザ識別子と連携元セッション情報と連携先セッション情報とを記憶する。ユーザ識別子は、ユーザを識別する。連携元セッション情報は、前記ユーザがサービスの提供を要求するサービス連携元が使用するセッションの情報を示す。連携先セッション情報は、前記サービス連携元と連携して前記ユーザにサービスを提供するサービス連携先が使用するセッションの情報を示す。判定部は、前記サービス連携元に対してサービスの提供を要求するユーザのユーザ識別子が、前記記憶部に記憶されているか否かを判定する。要求部は、前記判定部によって前記ユーザ識別子が記憶されていると判定された場合に、前記ユーザ識別子に対応付けられて前記記憶部に記憶される前記連携元セッション情報を用いて接続されるサービス連携元に、前記連携元セッション情報に対応付けられた前記連携先セッション情報を用いて接続されるサービス連携先と連携したサービスの提供を要求する。

処理性能の劣化を抑制できる。

図１は、実施例１に係るサービス提供システムの全体構成例を示す図である。 図２は、実施例２に係るサービス提供システムの全体構成例を示す図である。 図３は、ネットワーク事業者が有する各装置の構成を示す機能ブロック図である。 図４は、管理サーバのクラウド対応テーブルに記憶される情報の例を示す図である。 図５は、管理サーバの認証情報テーブルに記憶される情報の例を示す図である。 図６は、ＧＷ装置の連携サービステーブルに記憶される情報の例を示す図である。 図７は、ＧＷ装置のアカウント管理テーブルに記憶される情報の例を示す図である。 図８は、ＧＷ装置のセッション管理テーブルに記憶される情報の例を示す図である。 図９は、ＧＷ装置のセッション維持テーブルに記憶される情報の例を示す図である。 図１０は、実施例２に係るＧＷ装置が実行する処理の流れを示すフローチャートである。 図１１は、実施例２に係るＧＷ装置が実行するサービスリクエスト処理の流れを示すフローチャートである。 図１２は、実施例２に係るＧＷ装置が実行するログアウト処理の流れを示すフローチャートである。 図１３は、実施例２に係るＧＷ装置が実行する認証要求処理の流れを示すフローチャートである。 図１４は、実施例２に係るＧＷ装置が実行する認証情報応答処理の流れを示すフローチャートである。 図１５は、実施例２に係るＧＷ装置が実行する連携サービス登録処理の流れを示すフローチャートである。 図１６は、実施例２に係るサービス提供システムにおける初回ログイン時の処理シーケンス図である。 図１７は、実施例２に係るサービス提供システムにおける初回ログイン時の処理シーケンス図である。 図１８は、実施例２に係るサービス提供システムにおけるログイン中からログアウトまでの処理シーケンス図である。 図１９は、実施例２に係るサービス提供システムにおける再ログイン時の処理シーケンス図である。 図２０は、セッション情報の判定基準例を示す図である。 図２１は、１アカウントで１ユーザが利用できる場合の例を示す図である。 図２２は、１アカウントで複数ユーザが利用できる場合の例を示す図である。 図２３は、ハードウェア構成例を示す図である。

以下に、本願の開示するサービス要求装置、サービス要求方法およびサービス要求プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るサービス提供システムの全体構成例を示す図である。図１に示すように、サービス提供システムは、ユーザ端末１とサービス要求装置２とサービス連携元装置３とサービス連携先装置４とを有する。各装置は、ネットワークを介して接続される。ネットワークには、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、ＶＰＮ（Virtual Private Network）など様々なネットワークを採用できる。

このサービス提供システムは、ＯＡｕｔｈ２．０に準拠したシステムであり、サービス連携元装置３がサービス連携先装置４と連携して、ユーザ端末１にサービスを提供するシステムである。例えば、サービス提供システムには印刷サービスなどを適用できる。一例を挙げると、サービス連携元装置３が、写真などのデータを保持し、サービス連携先装置４が、ユーザの承認を得た後にサービス連携元装置３からデータを受信して所定のプリンタに印刷するサービスなどに適用できる。なお、ここで例示したサービスはあくまで例示であり、これに限定されるものではなく、様々なサービスに適用することができる。

ユーザ端末１は、ユーザが利用するコンピュータ装置であり、例えば、パーソナルコンピュータ、携帯電話、スマートフォンなどの端末である。サービス要求装置２は、記憶部２ａと判定部２ｂと要求部２ｃとを有し、ユーザ端末１がサービスを受ける際のセッション情報を管理するサーバ装置である。サービス連携先装置４は、例えばユーザ端末１のユーザデータを保持するサーバ装置であり、ユーザ端末１からサービス要求を受信し、サービス連携元装置３と連携してサービスを提供する。サービス連携元装置３は、例えばユーザデータをプリンタに印刷するサーバ装置であり、サービス連携先装置４と連携してユーザにサービスを提供する。

まず、ユーザ端末１がサービスを使用する場合について説明する。ユーザ端末１は、サービス要求装置２を介して、サービス連携元装置３にＷｅｂアクセスを行い、サービス連携元装置３にサービスを要求する。このとき、サービス連携元装置３は、ユーザ端末１が正当なユーザであるか否かを認証し、正当なユーザであると認証すると、サービスへのログインを許可する。

続いて、サービス連携元装置３は、ＯＡｕｔｈにしたがって、サービス連携先装置４に対して認証要求を送信する。サービス連携先装置４は、ユーザ端末１等から認証情報を受け付けてユーザ認証を実行し、ユーザ端末１を正当なユーザであると認証する。このようにして、サービス提供システムでは、サービスを提供するためのセッションが確立される。図１の場合、サービス要求装置２とサービス連携元装置３とがセッションを確立し、サービス要求装置２とサービス連携先装置４とがセッションを確立する。

そして、サービス連携先装置４とサービス連携元装置３とが、連携してユーザ端末１にサービスを提供する。例えば、サービス連携先装置４が、サービス連携元装置３からユーザデータを受信して、所定のプリンタに印刷する。その後、ユーザ端末１は、ユーザの指示操作によってサービスからログアウトを実行する。

このとき、サービス要求装置２は、ユーザを識別するユーザ識別子に対応付けて、連携元セッション情報と連携先セッション情報とを記憶部２ａに記憶する。すなわち、サービス要求装置２は、ユーザ端末１にサービスを提供するためのセッションを切断せずに維持する。なお、連携元セッション情報は、ユーザがサービスの提供を依頼するサービス連携元装置３が使用するセッションの情報である。連携先セッション情報は、サービス連携元装置３と連携してユーザにサービスを提供するサービス連携先装置４が使用するセッションの情報である。

その後、１度ログアウトを実行したユーザ端末１が、サービス要求装置２を介して、サービス連携元装置３にＷｅｂアクセスを行い、サービス連携元装置３にサービスを再度要求する。すなわち、ユーザ端末１が再度サービスにログインしたとする。

この場合、サービス要求装置２の判定部２ｂは、サービス連携元に対してサービスの提供を要求するユーザ端末１のユーザ識別子が、記憶部２ａに記憶されているか否かを判定する。そして、サービス要求装置２の要求部２ｃは、判定部２ｂによってユーザ識別子が記憶されていると判定された場合に、維持するセッションを用いたサービスの提供をサービス連携元装置３に要求する。具体的には、要求部２ｃは、ユーザ識別子に対応付けて記憶される連携元セッション情報で接続されるサービス連携元装置３に、連携元セッション情報に対応付けられた連携先セッション情報で接続されるサービス連携先装置４と連携したサービスの提供を要求する。

このように、実施例１に係るサービス提供システムは、ユーザ端末１に対するサービス提供に使用されたセッション情報を、ユーザ端末１がログアウト後も維持しておく。そして、実施例１に係るサービス提供システムは、同じユーザ端末１から再度ログインしてサービスを要求された場合には、維持したセッションを使用してサービスを提供する。したがって、２度目のログイン時には、ＯＡｕｔｈ処理における確認フェーズを省略することができる。この結果、ＯＡｕｔｈ処理がボトルネックとなることを防止でき、処理性能の劣化を抑制できる。

実施例１では、ユーザ端末がサービス連携元装置とサービス連携先装置の各々に認証を実行するシステム形態を例にして説明したが、これに限定されるものではない。例えば、ユーザ端末に代って代理認証するシステム形態にも開示するサービス要求装置を適用することができる。そこで、実施例２では、代理認証を用いたシステム形態を例にして説明する。

［全体構成］
図２は、実施例２に係るサービス提供システムの全体構成例を示す図である。図２に示すように、このサービス提供システムは、テナントＸ１０と、テナントＹ１１と、ネットワーク事業者２０と、サービス事業者（Ａ社）６０と、サービス事業者（Ｂ社）７０とを有する。各装置間は、実施例１と同様、ネットワークを介して接続される。なお、各テナントと各事業者とは特段の関係性はなく、別々の事業者であってもよい。

テナントＹ１０は、テナントＩＤとして「tenantY」が割当てられた企業などの組織であり、ここでは、ユーザ端末１０ａがテナントＹ１０に属している。テナントＺ１１は、テナントＩＤとして「tenantZ」が割当てられた企業などの組織であり、ここでは、ユーザ端末１１ａがテナントＺ１１に属している。

ネットワーク事業者２０は、ＩＤＰ（Identity Provider）サーバ３０と管理サーバ４０とＧＷ装置５０とを有し、これらによって、ユーザ端末に代理認証およびセッション管理を実行する。なお、各装置の構成等については後述する。

サービス事業者（Ａ社）６０は、ＩＤＰサーバ６０ａとＡＰサーバ６０ｂとがルータなどを介して接続され、これらによって、サービス事業者（Ｂ社）７０と連携してユーザにサービスを提供する。ＩＤＰサーバ６０ａは、ＡＰサーバ６０ｂで提供するサービスを利用するユーザの認証を実行する。ＡＰサーバ６０ｂは、ＩＤＰサーバ６０ａで認証を受けたユーザに対してサービスを提供する。例えば、ＡＰサーバ６０ｂは、ＩＤＰサーバ６０ａで認証を受けたユーザが使用するユーザ端末１０ａからの要求に応じて、要求された処理を実行する。

サービス事業者（Ｂ社）７０は、ＩＤＰサーバ７０ａとＡＰサーバ７０ｂとがルータなどを介して接続され、これらによって、サービス事業者（Ａ社）６０と連携してユーザにサービスを提供する。ＩＤＰサーバ７０ａは、ＡＰサーバ７０ｂで提供するサービスを利用するユーザの認証を実行する。ＡＰサーバ７０ｂは、ＩＤＰサーバ７０ａで認証を受けたユーザに対してサービスを提供する。例えば、ＡＰサーバ７０ｂは、ＩＤＰサーバ７０ａで認証を受けたユーザが使用するユーザ端末１０ａからの要求に応じて、要求された処理を実行する。

そして、サービス事業者（Ａ社）６０のＩＤＰサーバ６０ａと、サービス事業者（Ｂ社）７０のＩＤＰサーバ７０ａとは、アクセス権の委譲処理を行うことができる。例えば、ＩＤＰサーバ７０ａは、ユーザ端末１０ａを使用するユーザのＡＰサーバ７０ｂへのアクセス権を、ＡＰサーバ６０ｂに委譲することができる。これにより、ＡＰサーバ６０ｂは、ＡＰサーバ７０ｂにアクセスして、ＡＰサーバ７０ｂによって提供されるサービスを利用することができる。このようなアクセス権の委譲を行うことができるプロトコルとしては、例えばＯＡｕｔｈがある。

アクセス権の委譲により実行できるサービスの一例を説明する。例えば、ユーザ端末１０ａのユーザは、サービス事業者（Ｂ社）７０のＡＰサーバ７０ｂに自己のドキュメントデータを保管しているものとする。また、サービス事業者（Ａ社）６０のＡＰサーバ６０ｂでは、ユーザ端末１０ａのユーザのドキュメントデータを印刷データに変換するサービスを行うことができる。

具体的には、ユーザは、ＡＰサーバ７０ｂに保管しておいた自己のドキュメントデータの内容を印刷する場合、例えばプリンタ機能を有するユーザ端末１０ａの操作パネルを用いてドキュメントデータの印刷を指示する入力を行う。ユーザ端末１０ａは、入力に応じて、ＡＰサーバ６０ｂに対してドキュメントデータのネットプリント要求を送信する。ネットプリント要求は、ＡＰサーバ６０ｂに対して送られる。ＡＰサーバ６０ｂは、ユーザに与えられたアクセス権を用いてＡＰサーバ７０ｂにアクセスし、ドキュメントデータを取得する。そして、ＡＰサーバ６０ｂは、ドキュメントデータを印刷データに変換して、ユーザ端末１０ａに送信する。ユーザ端末１０ａは、受信した印刷データに基づいて印刷を実行し、ドキュメントデータの内容が印刷された紙書類を排出する。

このようなサービスを利用するには、ＡＰサーバ６０ｂに対して、ＡＰサーバ７０ｂへのアクセス権の委譲が行われる。その場合、ユーザの代理認証を実行するネットワーク事業者２０のＧＷ（Gateway）装置５０は、ＡＰサーバ６０ｂのサービスを利用するための代理認証を受けるとともに、ＡＰサーバ７０ｂのサービスを利用するための代理認証を受けることとなる。そのために、ＧＷ装置５０は、ＡＰサーバ６０ｂとＡＰサーバ７０ｂとのそれぞれのサービスを利用するための複数の認証情報を取得する。

［ネットワーク事業者の構成］
次に、図２に示したネットワーク事業者が有する各装置の構成について説明する。図３は、ネットワーク事業者が有する各装置の構成を示す機能ブロック図である。図３に示すように、ネットワーク事業者は、ＩＤＰサーバ３０と管理サーバ４０とＧＷ装置５０とを有する。ここでは、各装置の構成を説明する。

（ＩＤＰサーバの構成）
図３に示すように、ＩＤＰサーバ３０は、送受信部３１とログイン情報テーブル３２と認証部３３とを有する。送受信部３１は、他の装置の通信を制御する処理部であり、例えばネットワークインタフェースカードなどである。例えば、送受信部３１は、ログイン要求を受け付けたユーザ端末１０ａからユーザ名とパスワードとを受け付ける。また、送受信部３１は、認証結果をユーザ端末１０ａに送信する。

ログイン情報テーブル３２は、ユーザを認証する認証情報を記憶する。ログイン情報テーブル３２は、例えばメモリやハードディスク等の記憶装置に設けられる。例えば、このログイン情報テーブル３２は、ユーザを識別する「ユーザＩＤ」と当該ユーザを特定する「パスワード」とを対応付けた認証情報を記憶する。ログイン情報テーブル３２は、ユーザ等によってパスワードやユーザＩＤが変更されるたびに、管理者等によって更新される。

認証部３３は、ユーザ認証を実行する処理部である。この認証部３３は、例えばＣＰＵ（Central Processing Unit）などの電子回路でもよく、ＣＰＵが実行する処理部であってもよい。例えば、認証部３３は、ユーザ端末１０ａからログイン要求を受け付けると、ログイン画面をユーザ端末１０ａに表示させる。そして、認証部３３は、ログイン画面上で「ユーザＩＤ」と「パスワード」とを受け付ける。その後、認証部３３は、受け付けた「ユーザＩＤ」と「パスワード」とが対応付けられてログイン情報テーブル３２に記憶されているか否かを判定する。そして、認証部３３は、記憶されている場合に認証を許可することを示す認証結果をユーザ端末１０ａに応答し、記憶されていない場合に認証を拒否することを示す認証結果をユーザ端末１０ａに応答する。このように、認証部３３は、サービス提供システムを利用するユーザに対して、事前認証を実行する。

（管理サーバの構成）
図３に示すように、管理サーバ４０は、送受信部４１とクラウド対応テーブル４２と認証情報テーブル４３と認証情報提供部４４とを有する。

送受信部４１は、他の装置の通信を制御する処理部であり、例えばネットワークインタフェースカードなどである。例えば、送受信部４１は、ＧＷ装置５０から認証情報の取得要求を受信し、該当する認証情報を応答する。

クラウド対応テーブル４２は、各サービス事業者のＩＤＰサーバの情報を記憶する。クラウド対応テーブル４２は、例えばメモリやハードディスク等の記憶装置に設けられる。図４は、管理サーバのクラウド対応テーブルに記憶される情報の例を示す図である。図４に示すように、クラウド対応テーブル４２は、「ＩＤＰ＿ＵＲＬ、サービス事業者」を対応付けて記憶する。

ここで記憶される「ＩＤＰ＿ＵＲＬ」には、サービス事業者が有するＩＤＰサーバのＵＲＬ（Uniform Resource Locator）が設定される。また、「サービス事業者」には、サービス事業者の事業者名や識別子が設定される。図４の例では、「Ａ社」のＩＤＰ＿ＵＲＬが「https://IDP1.com」であることを示す。

認証情報テーブル４３は、サービス事業者ごとに設けられたテーブルであり、テナント内のユーザの認証情報を記憶する。認証情報テーブル４３は、例えばメモリやハードディスク等の記憶装置に設けられる。図５は、管理サーバの認証情報テーブルに記憶される情報の例を示す図である。図５に示すように、認証情報テーブル４３は、サービス事業者ごとに「テナントＩＤ、ユーザＩＤ、各社ＩＤ、各社パスワード」を対応付けた認証情報テーブル群を記憶する。認証情報テーブル４３は、ユーザ等によってパスワードやユーザＩＤが変更されるたびに、管理者等によって更新される。

ここでＡ社を例にして、認証情報テーブル４３に記憶される情報を説明する。「テナントＩＤ」には、サービス事業者のサービス提供を受けるテナントの識別情報が設定される。「ユーザＩＤ」には、テナントＩＤで示されるテナントに属するユーザの識別情報が設定される。「Ａ社ＩＤ」には、サービス事業者ＡのＩＤＰサーバに登録された、テナントのユーザＩＤが設定される。「Ａ社パスワード」には、サービス事業者ＡのＩＤＰサーバにおける認証用のパスワードが設定される。図５の例では、「tenantY」の属する「user001」は、「a＿ID」かつ「a＿PW」でサービス事業者ＡのＩＤＰサーバに認証許可されることを示す。

認証情報提供部４４は、認証情報の問い合わせに対して応答する処理部である。認証情報提供部４４は、例えばＣＰＵなどの電子回路でもよく、ＣＰＵが実行する処理部であってもよい。具体的には、認証情報提供部４４は、ＧＷ装置５０から認証情報の問い合わせを受信し、クラウド対応テーブル４２や認証情報提供部４４から該当する情報を取得して、ＧＷ装置５０に応答する。例えば、認証情報提供部４４は、テナント名、ユーザＩＤ、および少なくとも１つのＩＤＰサーバのＵＲＬの組を含む問い合わせを受信する。そして、認証情報提供部４４は、受信した問い合わせに含まれる情報の組み合わせに対応する情報をクラウド対応テーブル４２や認証情報提供部４４から取得して、ＧＷ装置５０に応答する。

（ＧＷ装置の構成）
図３に示すように、ＧＷ装置５０は、送受信部５１と記憶部５２と制御部５３とを有する。記憶部５２は、メモリやハードディスクなどの記憶装置である。制御部５３は、ＣＰＵなどの電子回路や集積回路である。

送受信部５１は、他の装置の通信を制御する処理部であり、例えばネットワークインタフェースカードなどである。この送受信部５１は、外部の装置からメッセージ、パケット、データを受信して受付部５４に出力する。また、送受信部５１は、受付部５４から出力されたメッセージ、パケット、データを宛先の外部装置に送信する。

記憶部５２は、制御部５３が実行するプログラムやデータを記憶する記憶装置であり、連携サービステーブル５２ａとアカウント管理テーブル５２ｂとセッション管理テーブル５２ｃとセッション維持テーブル５２ｄとを有する。

連携サービステーブル５２ａは、サービスごとに、認証を受ける対象先のＩＤＰサーバのＵＲＬを記憶する。この連携サービステーブル５２ａは、制御部５３や管理者等によって更新される。図６は、ＧＷ装置の連携サービステーブルに記憶される情報の例を示す図である。図６に示すように、連携サービステーブル５２ａは、「テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」を対応付けて記憶する。

ここで記憶される「テナントＩＤ」には、サービス要求メッセージを送信したユーザ端末を使用しているユーザが属するテナントのＩＤが設定される。「サービスＵＲＬ」には、サービス要求メッセージの宛先であるＡＰサーバのＵＲＬが設定される。「ＩＤＰ＿ＵＲＬ」には、サービス要求メッセージの宛先であるＡＰサーバからサービスの提供を受けるユーザに対して、ユーザ認証を実行するＩＤＰサーバのＵＲＬが設定される。「連携先ＩＤＰ＿ＵＲＬ」には、サービス要求メッセージの宛先であるＡＰサーバと連携した処理を実行する他のＡＰサーバから、サービスの提供を受けるユーザに対して、ユーザ認証を実行するＩＤＰサーバのＵＲＬが設定される。

図６の１例では、「tenantY」に属するユーザから「https://service1.com」に対するサービス要求メッセージについては、連携元として「https://IDP1.com」が認証処理を実行し、連携先として「https://IDP2.com」が認証処理を実行することを示す。

図３に戻り、アカウント管理テーブル５２ｂは、ユーザごとに、各サービスのＩＤＰサーバで認証を受けるための認証情報を記憶する。このアカウント管理テーブル５２ｂは、制御部５３によって更新される。図７は、ＧＷ装置のアカウント管理テーブルに記憶される情報の例を示す図である。図７に示すように、アカウント管理テーブル５２ｂは、「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ、ＩＤ、ＰＷ」を対応付けて記憶する。

ここで記憶される「テナントＩＤ」には、サービス要求メッセージを送信したユーザ端末を使用しているユーザが属するテナントのテナントＩＤが設定される。「ユーザＩＤ」には、サービス要求メッセージを送信したユーザ端末を使用しているユーザのユーザＩＤが設定される。「サービスＵＲＬ」は、サービスを提供するＡＰサーバのＵＲＬが設定される。「ＩＤＰ＿ＵＲＬ」は、認証を行ったＩＤＰのＵＲＬが設定される。「ＩＤ」は、認証に使用されたユーザＩＤが設定される。「ＰＷ」には、認証に使用されたパスワードが設定される。

図７の１例では、「tenantY」に属する「user001」が「https://IDP1.com」において「a＿ID、a＿PW」で認証が許可されて、「https://service1.com」からサービスを提供されることを示す。同様に、「tenantY」に属する「user001」が「https://IDP2.com」において「b＿ID、b＿PW」で認証が許可されて、「https://service2.com」からサービスを提供されることを示す。

図３に戻り、セッション管理テーブル５２ｃは、提供されているサービスのセッション情報を記憶する。このセッション管理テーブル５２ｃは、は、サービスが提供されているセッションを管理するものであり、サービスが終了すると該当するサービスのセッション情報が削除される。図８は、ＧＷ装置のセッション管理テーブルに記憶される情報の例を示す図である。図８に示すように、セッション管理テーブル５２ｃは、「ユーザセッションＩＤ、テナントＩＤ、ユーザＩＤ、サービスＵＲＬ（連携元）、連携元セッションＩＤ、サービスＵＲＬ（連携先）、連携先セッションＩＤ」を対応付けて記憶する。

ここで記憶される「ユーザセッションＩＤ」は、セッション管理テーブル５２ｃのエントリすなわちセッション情報を識別する識別子が設定される。「テナントＩＤ」は、サービスを受けているユーザが属するテナントのテナントＩＤが設定される。「ユーザＩＤ」は、サービスを受けているユーザのユーザＩＤが設定される。「サービスＵＲＬ（連携元）」は、ユーザからサービス要求を受信してユーザにサービスを提供しているＡＰサーバのＵＲＬが設定される。「連携元セッションＩＤ」は、サービスＵＲＬ（連携元）に設定されるＡＰサーバがサービスの提供に使用するセッションを識別するセッション識別子が設定される。「サービスＵＲＬ（連携先）」は、ユーザからサービス要求を受信したＡＰサーバと連携してユーザにサービスを提供しているＡＰサーバのＵＲＬが設定される。「連携先セッションＩＤ」は、サービスＵＲＬ（連携先）に設定されるＡＰサーバがサービスの提供に使用するセッションを識別するセッション識別子が設定される。なお、各セッションは、各ＡＰサーバとＧＷ装置５０との間で確立されるセッションである。

図８の一例では、「tenantY」に属する「user001」は、「https://service1.com」が「yyyyy」で識別されるセッションを用いるとともに、「https://service2.com」が「zzzzz」で識別されるセッションを用いる状態で、サービスを受けていることを示す。

セッション維持テーブル５２ｄは、ユーザがログアウトした際に、ユーザがサービスの提供を受けていたセッションに関する情報を記憶する。このセッション維持テーブル５２ｄは、制御部５３によって更新される。図９は、ＧＷ装置のセッション維持テーブルに記憶される情報の例を示す図である。図９に示すように、セッション維持テーブル５２ｄは、「サービスＵＲＬ、ＩＤ、セッションＩＤ、状態、連携先」を対応付けて記憶する。

ここで記憶される「サービスＵＲＬ」は、ユーザにサービスを提供したＡＰサーバのＵＲＬが設定される。「ＩＤ」は、サービスの提供を受けたユーザのユーザＩＤが設定される。「セッションＩＤ」は、サービスの提供に使用されたセッションのセッションＩＤが設定される。「状態」は、ログイン状態であるかログアウト状態であるかが設定される。「連携先」は、ユーザへのサービスを他のＡＰサーバと連携して提供した場合に、当該他のＡＰサーバのＵＲＬが設定される。

図９の一例では、「https://service1.com」が、「https://service2.com」と連携したサービスを、「yyyyy」で識別されるセッションを用いて「a＿ID」のユーザに提供し、現在も「a＿ID」がログイン中であることを示す。同様に、「https://service2.com」が、「https://service1.com」と連携したサービスを、「zzzzz」で識別されるセッションを用いて「b＿ID」のユーザに提供し、現在も「b＿ID」がログイン中であることを示す。ここで、図８と図９とを比較してもわかるように、セッション維持テーブル５２ｄには、ユーザからサービスを要求されたサービス連携元の情報と、サービス連携元から連携したサービスを要求されたサービス連携先の情報とがそれぞれ格納される。

図３に戻り、制御部５３は、ＧＷ装置５０全体の処理を司る処理部であり、受付部５４と事前認証部５５と問い合わせ部５６と代理認証部５７とセッション管理部５８とを有する。

受付部５４は、送受信部５１によって受け付けられたメッセージの種別を判定し、該当する処理部に出力する処理部である。また、受付部５４は、他の処理部が出力されたメッセージを、送受信部５１を介して宛先に送信する処理部である。

例えば、受付部５４は、受信されたメッセージのヘッダ等を参照し、当該メッセージがサービスを要求するリクエスト要求である場合には、当該メッセージを事前認証部５５に出力する。また、受付部５４は、受信されたメッセージがログアウト要求である場合には、当該メッセージをセッション管理部５８に出力する。また、受付部５４は、受信されたメッセージが認証要求によるリダイレクト要求、認証情報要求、アクセス許可要求である場合には、当該メッセージを代理認証部５７に出力する。

事前認証部５５は、ユーザに対して事前認証を実行する処理部である。具体的には、事前認証部５５は、アクセスしてきたユーザ端末がログイン状態であるか否かを判定し、ログイン状態でない場合に、ログイン処理に移行させる。例えば、事前認証部５５は、受付部５４から入力されたサービス要求メッセージが認証済みであるか否かを判定する。そして、事前認証部５５は、サービス要求メッセージが認証済みでない場合、すなわち、ログイン中でないユーザである場合、ＩＤＰサーバ３０による認証処理に移行させるメッセージを、要求元のユーザ端末に送信する。

なお、事前認証部５５は、ユーザがＩＤＰサーバ３０において正しく認証された場合に、そのユーザが正しく認証されたことを示す情報をＩＤＰサーバ３０から取得する。ユーザが正しく認証されたことを示す情報とは、認証が許可されたユーザＩＤやパスワードなどである。なお、この情報は、例えばサービスを要求するユーザ端末からの再度のサービス要求メッセージに含まれる。このとき、暗号化をしていてもよい。また、ＩＤＰサーバ３０は、ＯｐｅｎＩＤなどの認証システムを利用することもできる。

問い合わせ部５６は、アカウント管理テーブル５２ｂを生成するために用いる認証情報を管理サーバ４０に問い合わせる処理部である。例えば、問い合わせ部５６は、事前認証部５５から未認証のサービス要求メッセージが入力されると、管理サーバ４０に認証情報を問い合わせて、その応答結果からアカウント管理テーブル５２ｂのエントリを生成する。

一例を挙げると、問い合わせ部５６は、「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ」を含んだサービス要求メッセージを受信する。すると、問い合わせ部５６は、連携サービステーブル５２ａから、受信した「テナントＩＤ、サービスＵＲＬ」に対応する「ＩＤＰ＿ＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」を特定する。そして、問い合わせ部５６は、受信した「テナントＩＤ、ユーザＩＤ」とともに、特定した「ＩＤＰ＿ＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」とを含んだ認証情報の問い合わせ要求を管理サーバ４０に送信する。

そして、管理サーバ４０の認証情報提供部４４では、受信した「ＩＤＰ＿ＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」に対応する認証情報テーブルを認証情報テーブル４３から特定する。続いて、認証情報提供部４４は、各認証情報テーブル４３から、受信した「テナントＩＤ、サービスＵＲＬ」に対応する「ＩＤ、パスワード」を特定して、ＧＷ装置５０に応答する。

その後、問い合わせ部５６は、「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ、ＩＤ、パスワード（ＰＷ）」を対応付けたエントリを生成して、アカウント管理テーブル５２ｂに格納する。このとき、問い合わせ部５６は、ユーザから受信したサービス要求メッセージに含まれるサービスＵＲＬに対応する連携先ＩＤＰ＿ＵＲＬが存在する場合、サービス連携元とサービス連携先のそれぞれについてエントリを生成する。なお、問い合わせ部５６は、サービス連携先のＵＲＬについては、管理サーバ４０から受信した連携先ＩＤＰ＿ＵＲＬをキーにして、連携サービステーブル５２ａから特定することができる。

図３に戻り、代理認証部５７は、各サービス事業者が実行するユーザ認証を、ユーザ端末に代わって対応する処理部である。すなわち、代理認証部５７は、ユーザ端末の代理認証を実行する処理部である。具体的には、代理認証部５７は、サービス事業者のＩＤＰサーバから送信された認証情報の問い合わせに対して、該当するＩＤとＰＷとを応答する。

例えば、代理認証部５７は、サービス事業者（Ａ社）６０のＩＤＰサーバ６０ａから認証情報を要求された場合、当該要求からＩＤＰサーバ６０ａのＩＤＰ＿ＵＲＬ「https://IDP1.com」を特定する。そして、代理認証部５７は、特定したＩＤＰ＿ＵＲＬ「https://IDP1.com」をキーにしてアカウント管理テーブル５２ｂを検索し、ＩＤ「a＿ID」とＰＷ「a＿PW」を抽出する。その後、代理認証部５７は、サービス事業者（Ａ社）６０のＩＤＰサーバ６０ａに対して、認証情報としてＩＤ「a＿ID」とＰＷ「a＿PW」とを応答する。

セッション管理部５８は、ログイン時のセッション情報を管理し、ログアウト後の所定時間セッションを維持する処理部である。具体的には、セッション管理部５８は、ユーザがログインしてサービスを提供されている間、当該サービスに関する各種情報を収集してエントリを生成して、セッション管理テーブル５２ｃに格納する。そして、セッション管理部５８は、ユーザがログアウトを実行する場合に、当該ユーザにサービスを提供しているサービス連携元とサービス連携先各々のセッション情報を、セッション管理テーブル５２ｃとアカウント管理テーブル５２ｂから取得してセッション維持テーブル５２ｄに格納する。その後、セッション管理部５８は、セッション維持テーブル５２ｄで管理されるユーザが再度ログインした場合には、維持するセッションによるサービス提供を各サービス事業者のＡＰサーバに依頼する。

つまり、セッション管理部５８は、セッション維持テーブル５２ｄで管理されるユーザが再度ログインした場合に、代理認証部５７による代理認証を省略して、当該ユーザにサービスを提供させる。

ここで、セッション管理部５８が、ログイン中のユーザがサービスの提供を受けている際に、セッション管理テーブル５２ｃのエントリを生成する処理を説明する。例えば、セッション管理部５８は、「テナントＩＤ」と「ユーザＩＤ」と「サービスＵＲＬ（連携元）」とを、アカウント管理テーブル５２ｂから取得する。また、セッション管理部５８は、「連携元セッションＩＤ」について、サービスＵＲＬ（連携元）に該当するＡＰサーバからユーザ端末へ送信されたパケットや、当該ＡＰサーバとＧＷ装置５０との間に確立されたセッションから取得する。

また、セッション管理部５８は、「サービスＵＲＬ（連携先）」については、「サービスＵＲＬ（連携元）」をキーにして連携サービステーブル５２ａを検索することで取得できる。また、セッション管理部５８は、「連携先セッションＩＤ」については、サービスＵＲＬ（連携先）に該当するＡＰサーバからユーザ端末へ送信されたパケットや、当該ＡＰサーバとＧＷ装置５０との間に確立されたセッションから取得する。

そして、セッション管理部５８は、上記情報を対応付けたエントリをセッション管理テーブル５２ｃに格納する。なお、セッション管理部５８は、当該エントリを識別する情報として、当該エントリに任意の「ユーザセッションＩＤ」を割当てる。

次に、セッション管理部５８が、ログアウトを要求したユーザに対して、セッション維持テーブル５２ｄのエントリを生成する処理を説明する。セッション管理部５８は、連携元と連携先との両方について、セッション維持テーブル５２ｄのエントリを生成する。つまり、連携元と連携先との関係は、一方からみた場合の関係であり、双方からみた場合には両方が連携元にも連携先にもなる。具体的には、ユーザ端末がサービス事業者（Ａ社）にサービス要求を送信し、Ａ社のＡＰサーバがＢ社のＡＰサーバと連携してサービスを提供したとする。この場合、Ａ社から見れば、自社のＡＰサーバが連携元で、Ｂ社のＡＰサーバが連携先となる。一方、この場合であっても、Ｂ社から見れば、自社のＡＰサーバが連携元で、Ａ社のＡＰサーバが連携先となる。このため、セッション管理部５８は、連携元と連携先との両方について、エントリを生成する。この結果、ＧＷ装置５０は、サービス間連携で利用された各セッションを維持することができる。

サービス提供元ついて一例を説明する。セッション管理部５８は、ログアウトを要求したユーザ端末１０ａを使用するユーザのユーザＩＤに対応するエントリを、セッション管理テーブル５２ｃから特定する。続いて、セッション管理部５８は、特定したエントリの「サービスＵＲＬ（連携元）」、「連携元セッションＩＤ」、「サービスＵＲＬ（連携先）」を、「サービスＵＲＬ」、「セッションＩＤ」、「連携先」のそれぞれに格納する。また、セッション管理部５８は、「ＩＤ」ついては、「サービスＵＲＬ」に対応付けてアカウント管理テーブル５２ｂに記憶される「ユーザＩＤ」を格納する。なお、この「ＩＤ」は、「サービスＵＲＬ（連携元）」に対応付けてアカウント管理テーブル５２ｂに記憶される「ユーザＩＤ」、つまりログアウトを要求した「ユーザＩＤ」でもよい。そして、セッション管理部５８は、取得した上記情報とログイン状態とを対応付けたエントリをセッション維持テーブル５２ｄに格納する。

次に、サービス提供先ついて一例を説明する。セッション管理部５８は、ログアウトを要求したユーザ端末１０ａを使用するユーザのユーザＩＤに対応するエントリを、セッション管理テーブル５２ｃから特定する。続いて、セッション管理部５８は、特定したエントリの「サービスＵＲＬ（連携先）」、「連携先セッションＩＤ」、「サービスＵＲＬ（連携元）」を、「サービスＵＲＬ」、「セッションＩＤ」、「連携先」のそれぞれに格納する。また、セッション管理部５８は、「ＩＤ」ついては、「サービスＵＲＬ」に対応付けてアカウント管理テーブル５２ｂに記憶される「ユーザＩＤ」を格納する。なお、この「ＩＤ」は、「サービスＵＲＬ（連携先）」に対応付けてアカウント管理テーブル５２ｂに記憶される「ユーザＩＤ」、つまりログアウトを要求した「ユーザＩＤ」でもよい。そして、セッション管理部５８は、取得した上記情報とログイン状態とを対応付けたエントリをセッション維持テーブル５２ｄに格納する。

［処理の流れ］
次に、実施例２に係るＧＷ装置５０が実行する処理の流れを説明する。ここでは、全体的な流れ、メッセージによって実行される各処理の流れを説明する。

（全体的な流れ）
図１０は、実施例２に係るＧＷ装置が実行する処理の流れを示すフローチャートである。図１０に示すように、ＧＷ装置５０の送受信部５１がサービス要求メッセージを受信すると（Ｓ１０１）、受付部５４は、受信されたサービス要求メッセージの種別を判定する（Ｓ１０２）。

受付部５４がサービス要求メッセージをリクエスト要求と判定した場合、事前認証部５５等は、サービスリクエスト処理を実行する（Ｓ１０３）。また、受付部５４がサービス要求メッセージをログアウト要求と判定した場合、セッション管理部５８は、ログアウト処理を実行する（Ｓ１０４）。

また、受付部５４がサービス要求メッセージを認証要求によるリダイレクト要求と判定した場合、代理認証部５７等は、認証要求処理を実行する（Ｓ１０５）。また、受付部５４がサービス要求メッセージを認証情報要求と判定した場合、代理認証部５７等は、認証情報応答処理を実行する（Ｓ１０６）。

また、受付部５４がサービス要求メッセージをアクセス許可判断要求と判定した場合、代理認証部５７等は、アクセス判定結果を要求元に送出する（Ｓ１０７）。すなわち、代理認証部５７等は、キャッシュしておいたOAuth codeを含むアクセス許可要求メッセージを生成し、受付部５４と送受信部５１とを介して要求元に送信する。

また、受付部５４がサービス要求メッセージを認証またはアクセス許可終了時のリダイレクト要求と判定した場合、受付部５４等は、リダイレクトを送出する（Ｓ１０８）。すなわち、受付部５４等は、受信したメッセージのリダイレクト指示にしたがって、リダイレクトでメッセージを送信する。例えば、受付部５４等は、メッセージが認証成功を示す認証結果メッセージであれば、リダイレクト指示にしたがって、認証済みのサービス要求メッセージとして認証結果をリダイレクト先に送信する。また、受付部５４等は、メッセージが認証成功の認証結果メッセージであれば、リダイレクト指示にしたがって、許可完了通知メッセージとして認証結果をリダイレクト先に送信する。

また、受付部５４がサービス要求メッセージをサービス応答と判定した場合、制御部５３は、連携サービス登録処理を実行する（Ｓ１０９）。

（サービスリクエスト処理）
図１１は、実施例２に係るＧＷ装置が実行するサービスリクエスト処理の流れを示すフローチャートである。図１１に示すように、事前認証部５５は、受信されたリクエスト要求が認証済みであるか否かを判定する（Ｓ２０１）。例えば、事前認証部５５は、リクエスト要求に認証済みであることを示す識別子等が含まれている場合に、認証済みであると判定する。なお、この識別子は、認証処理を実行したＩＤＰサーバによって付加される。

続いて、リクエスト要求が認証済みであると判定された場合（Ｓ２０１Ｙｅｓ）、セッション管理部５８は、当該リクエスト要求を送信したユーザのユーザ識別子がセッション管理テーブル５２ｃに記憶されているか否かを判定する（Ｓ２０２）。つまり、セッション管理部５８は、リクエスト要求元のユーザがログイン中であるか否かを判定する。例えば、セッション管理部５８は、リクエスト要求に含まれるユーザＩＤが、セッション管理テーブル５２ｃに存在する場合に、ユーザがログイン中であると判定する。

そして、リクエスト要求を送信したユーザのユーザ識別子がセッション管理テーブル５２ｃに記憶されていないと判定された場合（Ｓ２０２Ｎｏ）、代理認証部５７は、Ｓ２０３を実行する。つまり、代理認証部５７は、セッションが確立されていないと判定した場合、Ｓ２０３を実行する。具体的には、代理認証部５７は、受信されたメッセージに含まれる「テナントＩＤ、サービスＵＲＬ」の組に対応するエントリが、連携サービステーブル５２ａに記憶されているか否かを判定する。そして、代理認証部５７は、該当するエントリが存在する場合には、当該エントリから「ＩＤＰ＿ＵＲＬ」と「連携先ＩＤＰ＿ＵＲＬ」を抽出する。その後、代理認証部５７は、「テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ」と「テナントＩＤ、サービスＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」とを認証情報候補として生成し、認証情報が存在すると判定する。

続いて、代理認証部５７は、認証情報が存在すると判定した場合（Ｓ２０３Ｙｅｓ）、アカウント管理テーブル５２ｂに当該認証情報が登録されているか否かを判定する（Ｓ２０４）。すなわち、代理認証部５７は、Ｓ２０３で生成した「テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ」と「テナントＩＤ、サービスＵＲＬ、連携先ＩＤＰ＿ＵＲＬ」の各々に対応するエントリがアカウント管理テーブル５２ｂに存在するか否かを判定する。なお、認証情報が存在しないと判定された場合（Ｓ２０３Ｎｏ）、ＧＷ装置５０は、Ｓ２０４を実行することなく、Ｓ２０５を実行する。

そして、代理認証部５７は、両方の組に対応するエントリが存在すると判定した場合（Ｓ２０４Ｙｅｓ）、「テナントＩＤ、ユーザＩＤ」および「サービスＵＲＬ」をキャッシュデータとして保持する（Ｓ２０５）。具体的には、代理認証部５７は、受信されたメッセージから「テナントＩＤ、ユーザＩＤ」を取得する。さらに、代理認証部５７は、取得した「テナントＩＤ、ユーザＩＤ」に対応する「サービスＵＲＬ」をアカウント管理テーブル５２ｂ等から取得する。そして、代理認証部５７は、「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ」をキャッシュデータとして保持する。

一方、代理認証部５７が両方の組に対応するエントリまたはいずれかの組に対応するエントリが存在しないと判定した場合（Ｓ２０４Ｎｏ）、問い合わせ部５６は、Ｓ２０６を実行する。具体的には、問い合わせ部５６は、対応するエントリが存在しないと判定された上記組を含む問い合わせメッセージを管理サーバ４０に送信し、その応答としてＩＤとパスワードとを含む認証情報を受信する。例えば、問い合わせ部５６は、「テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ」を管理サーバ４０に送信する。管理サーバ４０では、受信した組に対応付けられた「ＩＤ、パスワード」を、認証情報テーブル４３から取得してＧＷ装置５０に応答する。そして、問い合わせ部５６は、送信した「テナントＩＤ、サービスＵＲＬ、ＩＤＰ＿ＵＲＬ」に、受信した「ＩＤ、パスワード」を対応付けて、アカウント管理テーブル５２ｂに格納する。その後、Ｓ２０５が実行される。

その後、セッション管理部５８は、メッセージを送信したユーザのユーザＩＤがセッション維持テーブル５２ｄに記憶されているか否かを判定する（Ｓ２０７）。例えば、セッション管理部５８は、Ｓ２０３で生成された「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ」またはＳ２０２で抽出された「テナントＩＤ、サービスＵＲＬ」に対応する「ＩＤ」をアカウント管理テーブル５２ｂから特定する。そして、セッション管理部５８は、特定した「ＩＤ」がセッション維持テーブル５２ｄに記憶されているか否かを判定する。このとき、セッション管理部５８は、「サービスＵＲＬ」の一致をさらに判定してもよい。

そして、セッション管理部５８によって、ユーザＩＤがセッション維持テーブル５２ｄに記憶されていないと判定した場合（Ｓ２０７Ｎｏ）、代理認証部５７は、サービス要求を送出する（Ｓ２０８）。例えば、代理認証部５７は、Ｓ２０５でキャッシュした「サービスＵＲＬ」すなわちサービス要求メッセージに含まれる「サービスＵＲＬ」に対して、サービス要求を送信する。

一方、セッション管理部５８は、ユーザＩＤがセッション維持テーブル５２ｄに記憶されていると判定した場合（Ｓ２０７Ｙｅｓ）、セッション情報を付加してサービス要求を送出する（Ｓ２０９）。例えば、セッション管理部５８は、ユーザＩＤに対応付けられる「セッションＩＤ」を用いて接続されるサービス連携元のＡＰサーバにサービスを要求する。このとき、セッション管理部５８は、当該「セッションＩＤ」に対応する「連携先」をセッション維持テーブル５２ｄから特定し、さらに、当該「連携先」に対応する「セッションＩＤ」を特定する。そして、セッション管理部５８は、特定した「セッションＩＤ」すなわち「連携先のセッションＩＤ」、を用いて接続されるサービス連携先と連携したサービスの提供を要求する。

また、Ｓ２０２において、代理認証部５７によって、リクエスト要求を送信したユーザのユーザ識別子がセッション管理テーブル５２ｃに記憶されていると判定された場合（Ｓ２０２Ｙｅｓ）、セッション管理部５８は、Ｓ２０９を実行する。つまり、セッション管理部５８は、セッションが確立されていると判定した場合、Ｓ２０９を実行する。

また、Ｓ２０１において、リクエスト要求が認証済みでないと判定された場合（Ｓ２０１Ｎｏ）、事前認証部５５は、Ｓ２１０を実行する。具体的には、事前認証部５５は、サービス要求メッセージの要求元のユーザ端末に、認証要求メッセージを応答する。例えば、事前認証部５５は、認証要求メッセージを生成し、受付部５４に出力する。受付部５４は、入力された認証要求メッセージを、送受信部５１を介して宛先のユーザ端末に送信する。なお、Ｓ２０８、Ｓ２０９、Ｓ２１０が実行されると、ＧＷ装置５０は、サービスリクエスト処理を終了する。

（ログアウト処理）
図１２は、実施例２に係るＧＷ装置が実行するログアウト処理の流れを示すフローチャートである。図１２に示すように、セッション管理部５８は、ログアウト要求が受信された場合に、ログアウトを依頼したユーザが使用しているセッションを維持するか否かを判定する（Ｓ３０１）。

例えば、セッション管理部５８は、ログアウト要求からユーザＩＤを抽出し、当該ユーザＩＤに対応するサービスＵＲＬをセッション管理テーブル５２ｃから特定する。そして、セッション管理部５８は、特定したサービスＵＲＬによって提供されるサービスの種別によってセッションを維持するか否かを判定する。一例を挙げると、セッション管理部５８は、サービス種別がダウンロードサービスである場合には、維持すると判定して、サービス種別がデータ格納サービスである場合には、破棄するなどと判定する。

そして、セッション管理部５８は、セッションを維持すると判定した場合（Ｓ３０１Ｙｅｓ）、セッション維持テーブル５２ｄにセッション情報を登録する（Ｓ３０２）。

例えば、セッション管理部５８は、ログアウト要求から抽出したユーザＩＤに対応するエントリをセッション管理テーブル５２ｃから特定する。そして、セッション管理部５８は、特定したエントリの情報等を用いて、セッション維持テーブル５２ｄにエントリを格納する。

その後、セッション管理部５８は、ログアウト要求から抽出したユーザＩＤに対応するエントリをセッション管理テーブル５２ｃから削除する（Ｓ３０３）。また、Ｓ３０１において、セッション管理部５８は、ログアウトを依頼したユーザが使用しているセッションを維持しないと判定した場合（Ｓ３０１Ｎｏ）、Ｓ３０３を実行する。なお、Ｓ３０３が実行されると、ＧＷ装置５０は、ログアウト処理を終了する。

（認証要求処理）
図１３は、実施例２に係るＧＷ装置が実行する認証要求処理の流れを示すフローチャートである。

図１３に示すように、代理認証部５７は、リダイレクトを伴う認証要求メッセージが受信された場合、当該メッセージにOAuth codeが含まれているか否かを判定する（Ｓ４０１）。例えば、代理認証部５７は、認証要求メッセージにOAuth codeが含まれているか否かを判定し、OAuth codeを含む認証要求メッセージは、ＯＡｕｔｈにおける許可要求メッセージに該当する。

そして、代理認証部５７は、認証要求メッセージにOAuth codeが含まれていると判定した場合（Ｓ４０１Ｙｅｓ）、サービス間連携と判断し、OAuth codeとリダイレクト先とを保持する（Ｓ４０２）。例えば、代理認証部５７は、OAuth codeとリダイレクト先のＵＲＬである連携先ＩＤＰサーバのＵＲＬとを保持する。

一方、代理認証部５７は、認証要求メッセージにOAuth codeが含まれていないと判定した場合（Ｓ４０１Ｎｏ）、リダイレクト先のＵＲＬである連携元ＩＤＰサーバのＵＲＬを、当該メッセージから取得して保持する（Ｓ４０３）。

Ｓ４０２とＳ４０４を実行した後、代理認証部５７は、サービスを利用するための認証処理が未認証であることから、当該メッセージを指示されたリダイレクトで、該当するＩＤＰサーバに送信する（Ｓ４０４）。なお、Ｓ４０４が実行されると、ＧＷ装置５０は、認証要求処理を終了する。

（認証情報応答処理）
図１４は、実施例２に係るＧＷ装置が実行する認証情報応答処理の流れを示すフローチャートである。

図１４に示すように、ＧＷ装置５０の代理認証部５７は、認証情報要求を示すサービス要求メッセージが受信された場合、要求された認証情報を保持するか否かを判定する（Ｓ５０１）。例えば、代理認証部５７は、要求された「テナントＩＤ、ユーザＩＤ、ＩＤＰのＵＲＬ」の組がアカウント管理テーブル５２ｂに記憶されているか否かを判定する。

そして、代理認証部５７が認証情報を保持していないと判定した場合（Ｓ５０１Ｎｏ）、問い合わせ部５６が、要求された認証情報を管理サーバ４０に問い合わせ、代理認証部５７が、問い合わせて得られた認証情報を保持させる（Ｓ５０２）。例えば、問い合わせ部５６は、要求された「テナントＩＤ、ユーザＩＤ、ＩＤＰのＵＲＬ」を管理サーバ４０に問い合わせて、「テナントＩＤ、ユーザＩＤ、ＩＤＰのＵＲＬ」とともに、この情報に対応する「ＩＤ、パスワード」を管理サーバ４０から取得する。なお、ここでの「ＩＤ、パスワード」は、認証情報テーブル４３上では、各社のＩＤと各社のパスワードに該当する。そして、代理認証部５７は、取得された「テナントＩＤ、ユーザＩＤ、ＩＤＰのＵＲＬ」と「ＩＤ、パスワード」とを対応付けて、アカウント管理テーブル５２ｂに格納する。

その後、代理認証部５７は、認証情報要求元に認証情報を送出する（Ｓ５０３）。例えば、代理認証部５７は、要求された「テナントＩＤ、ユーザＩＤ、ＩＤＰのＵＲＬ」に対応するエントリをアカウント管理テーブル５２ｂから特定する。そして、代理認証部５７は、受付部５４と送受信部５１とを介して、特定したエントリ内の「ＩＤ、ＰＷ」を要求元に送出する。

（連携サービス登録処理）
図１５は、実施例２に係るＧＷ装置が実行する連携サービス登録処理の流れを示すフローチャートである。

図１５に示すように、ＧＷ装置５０の制御部５３は、サービス応答を示すサービス要求メッセージが受信された場合、受信したサービス応答を送信元に送信する（Ｓ６０１）。例えば、制御部５３の受付部５４は、送受信部５１を介して、受信されたサービス要求メッセージに対する応答として、サービス応答を送信元に送信する。

続いて、制御部５３は、連携サービステーブル５２ａへの格納対象となるエントリを作成する（Ｓ６０２）。例えば、制御部５３は、代理認証部５７が保持しているキャッシュデータから、「テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、連携先ＩＤＰのＵＲＬ」を取得し、この組を１つのエントリ候補とする。

そして、制御部５３は、エントリ候補と同一のエントリが連携サービステーブル５２ａ内に存在するか否かを判定する（Ｓ６０３）。例えば、制御部５３は、Ｓ６０２で生成した「テナントＩＤ、サービスＵＲＬ、連携元ＩＤＰのＵＲＬ、連携先ＩＤＰのＵＲＬ」の組が連携サービステーブル５２ａに記憶されているか否かを判定する。

その後、制御部５３は、エントリ候補と同一のエントリが連携サービステーブル５２ａ内に存在すると判定した場合（Ｓ６０３Ｙｅｓ）、代理認証部５７が保持していたキャッシュを削除する（Ｓ６０４）。

一方、制御部５３は、エントリ候補と同一のエントリが連携サービステーブル５２ａ内に存在しないと判定した場合（Ｓ６０３Ｎｏ）、Ｓ６０２で生成したエントリ候補を新たなエントリとして連携サービステーブル５２ａに登録する（Ｓ６０５）。

［シーケンス］
次に、実施例２に係るサービス提供システム全体の処理シーケンスを説明する。ここでは、ユーザが初めてログインした場合のシーケンス、ログイン中からログアウトまでのシーケンス、ログアウト後に再ログインした場合のシーケンスについて説明する。

（初回ログイン）
図１６と図１７は、実施例２に係るサービス提供システムにおける初回ログイン時の処理シーケンス図である。図１６に示すように、ユーザ端末１０ａは、ユーザの指示操作によって、事前認証が未認証の状態でＡＰサーバ７０ｂ「https://service1.com」にサービス要求メッセージを送信する（Ｓ７０１）。ただし、このメッセージはＧＷ装置５０に受信される。

そして、ＧＷ装置５０の事前認証部５５は、受信されたサービス要求メッセージを未認証と判定する（Ｓ７０２）。例えば、事前認証部５５は、事前認証が終了していることを示す識別子等がサービス要求メッセージに含まれていないことから、未認証と判定する。

続いて、ＧＷ装置５０の事前認証部５５は、ユーザ端末１０ａを介するリダイレクト指示を含めた認証要求をＩＤＰサーバ３０に送信する（Ｓ７０３）。ＩＤＰサーバ３０は、認証要求をリダイレクトさせたユーザ端末１０ａに、認証画面を応答する（Ｓ７０４）。

ユーザ端末１０ａは、ＩＤＰサーバ３０から受信した認証画面に対してユーザが入力したＩＤとパスワードとを認証情報として、ＩＤＰサーバ３０に応答する（Ｓ７０５）。ＩＤＰサーバ３０の認証部３３は、ユーザ端末１０ａから受信した認証情報がログイン情報テーブル３２に記憶されているか否かを判定するユーザ認証処理を実行する（Ｓ７０６）。なお、ここでは、認証情報がログイン情報テーブル３２に記憶されているものとする。

そして、ＩＤＰサーバ３０の認証部３３は、認証を許可したことを示す認証結果をユーザ端末１０ａに送信する（Ｓ７０７）。この認証結果を受信したユーザ端末１０ａは、ＡＰサーバ６０ｂ「https://service1.com」にサービス要求メッセージを送信する（Ｓ７０８）。このとき、ユーザ端末１０ａは、事前認証済みであることを示す識別子を付与して送信する。ただし、ここで送信されたメッセージは、ＧＷ装置５０に受信される。

このメッセージを受信したＧＷ装置５０の事前認証部５５が認証済みと判定し、問い合わせ部５６が、認証情報を管理サーバ４０に問い合わせて、該当する認証情報を取得する（Ｓ７０９）。

例えば、代理認証部５７は、サービス要求メッセージから「サービスＵＲＬ（https://service1.com）、ユーザＩＤ（user001）、テナントＩＤ（tenantY）」を取得する。そして、代理認証部５７は、取得した「サービスＵＲＬ（https://service1.com）、テナントＩＤ（tenantY）」に対応する「ＩＤＰ＿ＵＲＬ（https://IDP1.com）」と「連携先ＩＤＰ＿ＵＲＬ（https://IDP2.com）」とを連携サービステーブル５２ａから取得する。ここで、代理認証部５７は、これまでに取得した「https://service1.com、user001、tenantY、https://IDP1.com」のエントリと「https://service1.com、user001、tenantY、https://IDP2.com」のエントリとをアカウント管理テーブル５２ｂに生成する。そして、問い合わせ部５６は、取得された「https://service1.com、user001、tenantY、https://IDP1.com」の認証情報および「https://service1.com、user001、tenantY、https://IDP2.com」の認証情報を管理サーバ４０に問い合わせる。

管理サーバ４０の認証情報提供部４４は、受信した「https://IDP1.com」と「https://IDP2.com」各々に対応する各サービス事業者をクラウド対応テーブル４２から検索する。そして、認証情報提供部４４は、検索したサービス事業者（Ａ社）の認証情報テーブルを用いて、ＧＷ装置５０から受信した「user001、tenantY」に対応する「Ａ社ＩＤ（a＿ID）、Ａ社パスワード（a＿PW）」を特定する。同様に、認証情報提供部４４は、検索したサービス事業者（Ｂ社）の認証情報テーブルを用いて、ＧＷ装置５０から受信した「user001、tenantY」に対応する「Ｂ社ＩＤ（b＿ID）、Ｂ社パスワード（b＿PW）」を特定する。その後、認証情報提供部４４は、特定した「Ａ社ＩＤ（a＿ID）、Ａ社パスワード（a＿PW）」と「Ｂ社ＩＤ（b＿ID）、Ｂ社パスワード（b＿PW）」とを、ＧＷ装置５０に応答する。

そして、ＧＷ装置５０の問い合わせ部５６は、管理サーバ４０から「Ａ社ＩＤ（a＿ID）、Ａ社パスワード（a＿PW）」と「Ｂ社ＩＤ（b＿ID）、Ｂ社パスワード（b＿PW）」とを取得する。すると、代理認証部５７は、アカウント管理テーブル５２ｂに先ほど生成したサービス提供元「https://service1.com」のエントリに、「Ａ社ＩＤ（a＿ID）、Ａ社パスワード（a＿PW）」を格納する。同様に、代理認証部５７は、アカウント管理テーブル５２ｂに先ほど生成したサービス提供先「https://service2.com」のエントリに、「Ｂ社ＩＤ（b＿ID）、Ｂ社パスワード（b＿PW）」を格納する。

図１６に戻り、ＧＷ装置５０の代理認証部５７は、ユーザ端末１０ａから受信したサービス提供メッセージの宛先であるＡＰサーバ６０ｂに、当該メッセージを転送する（Ｓ７１０）。

このメッセージを受信したＡＰサーバ６０ｂは、サービス要求メッセージを未認証と判定し、送信元のＧＷ装置５０を介するリダイレクト指示を含めた認証要求をＩＤＰサーバ６０ａに送信する（Ｓ７１１）。ＩＤＰサーバ６０ａは、認証要求をリダイレクトさせたＧＷ装置５０に、認証画面を応答する（Ｓ７１２）。

ＧＷ装置５０は、受信した認証画面に対して応答として、該当する認証情報をＩＤＰサーバ６０ａに応答する（Ｓ７１３）。例えば、代理認証部５７は、「テナントＩＤ（tenantY）、ユーザＩＤ（user001）」を含むサービス要求メッセージの応答として認証画面を受信することから、認証対象となっている「テナントＩＤ（tenantY）、ユーザＩＤ（user001）」を特定できる。また、代理認証部５７は、認証画面のＵＲＬ等から認証を要求するサーバのＵＲＬ、すなわちサービスＵＲＬ「https://service1.com」を特定する。そして、代理認証部５７は、「テナントＩＤ（tenantY）、ユーザＩＤ（user001）、サービスＵＲＬ「https://service1.com」に対応する「a＿ID、a＿PW」をアカウント管理テーブル５２ｂから特定し、ＩＤＰサーバ６０ａに応答する。

ＩＤＰサーバ６０ａは、ＧＷ装置５０から受信した認証情報を記憶しているか否かによって、正当なユーザであるか否かを判定するユーザ認証処理を実行する（Ｓ７１４）。なお、ここでは、ＩＤＰサーバ６０ａは、正当なユーザであると判定したとする。

そして、ＩＤＰサーバ６０ａは、認証を許可したことを示す認証結果をＧＷ装置５０に送信する（Ｓ７１５）。この認証結果を受信したＧＷ装置５０は、ＡＰサーバ６０ｂ「https://service1.com」にサービス要求メッセージを送信する（Ｓ７１６）。

その後、ＡＰサーバ６０ｂは、サービス要求メッセージの内容を解析し、ＡＰサーバ７０ｂとの連携処理であることを認識する。

すると、ＡＰサーバ６０ｂは、ＧＷ装置５０を介するリダイレクト指示を含めるとともに、受信したOAuth codeを含む許可要求メッセージを、ネットワーク事業者Ｂ社のＩＤＰサーバ７０ａに送信する（Ｓ７１７）。この際、OAuth codeは、ＨＴＴＰ（HyperText Transfer Protocol）形式の応答メッセージに含めることができる。なお、ＧＷ装置５０は、許可要求メッセージに応じてＩＤＰサーバ７０ａの代理認証を実施するので、ここでは、許可要求メッセージは認証要求メッセージの一種である。

そして、ＩＤＰサーバ７０ａは、OAuth codeを含む許可要求メッセージを受信し、その応答として認証画面を、リダイレクト元のＧＷ装置５０に応答する（Ｓ７１８）。

続いて、図１７に示すように、ＧＷ装置５０は、受信した認証画面に対して応答として、該当する認証情報をＩＤＰサーバ７０ａに応答する（Ｓ８０１）。例えば、代理認証部５７は、「テナントＩＤ（tenantY）、ユーザＩＤ（user001）」を含むサービス要求メッセージの応答として認証画面を受信することから、認証対象となっている「テナントＩＤ（tenantY）、ユーザＩＤ（user001）」を特定できる。また、代理認証部５７は、認証画面のＵＲＬ等から認証を要求するサーバのＵＲＬ、すなわちサービスＵＲＬ「https://service2.com」を特定する。そして、代理認証部５７は、テナントＩＤ（tenantY）、ユーザＩＤ（user001）、サービスＵＲＬ「https://service2.com」に対応する「b＿ID、b＿PW」をアカウント管理テーブル５２ｂから特定し、ＩＤＰサーバ７０ａに応答する。

ＩＤＰサーバ７０ａは、ＧＷ装置５０から受信した認証情報を記憶しているか否かによって、正当なユーザであるか否かを判定するユーザ認証処理を実行する（Ｓ８０２）。なお、ここでは、ＩＤＰサーバ７０ａは、正当なユーザであると判定したとする。そして、ＩＤＰサーバ７０ａは、アクセス許可画面データをＧＷ装置５０に送信する（Ｓ８０３）。アクセス許可画面データは、例えばＡＰサーバ６０ｂがアクセスするドキュメントデータの内容と条件を示し、アクセス許可してよいか否かの判断を促す画面のデータである。なお、この画面データがアクセス許可判断要求となる。

この画面を受信したＧＷ装置５０の代理認証部５７は、OAuth codeを含むアクセス許可要求メッセージをＩＤＰサーバ７０ａに送信する（Ｓ８０４）。なお、アクセス許可要求メッセージは、アクセス許可画面データに示される内容を許可してよいかどうかを問い合わせるメッセージである。

その後、ＩＤＰサーバ７０ａは、認証処理を実行する（Ｓ８０５）。そして、ＩＤＰサーバ７０ａは、ＧＷ装置５０を介したリダイレクト指示を含んだ、認証を許可したことを示す認証結果メッセージをＡＰサーバ６０ｂに応答する（Ｓ８０６）。例えば、ＩＤＰサーバ７０ａは、ＧＷ装置５０によってアクセスが許可された場合に、アクセス許可を示すOAuth codeを含む認証結果メッセージをＡＰサーバ６０ｂに送信する。

認証結果メッセージを受信したＧＷ装置５０の代理認証部５７は、アクセス許可を示すOAuth codeを含む許可完了通知を、リダイレクト先のＡＰサーバ６０ｂに送信する（Ｓ８０７）。

許可完了通知を受信したＡＰサーバ６０ｂは、ＩＤＰサーバ７０ａに対してアクセストークン要求を送信する（Ｓ８０８）。なお、アクセストークン要求には、アクセス許可を示すOAuth codeが含まれる。

そして、ＩＤＰサーバ７０ａは、アクセストークン要求を受信すると、アクセス許可を示すOAuth codeが含まれていることを確認後、アクセストークン応答をＡＰサーバ６０ｂに応答する（Ｓ８０９）。なお、アクセストークン応答には、データ取得のＡＰＩを示すアクセストークン（A＿token）が含まれる。

ＡＰサーバ６０ｂは、アクセストークン応答を受信すると、アクセストークンに含まれるデータ取得のＡＰＩを用いたデータ要求を、ＡＰサーバ７０ｂに送信する（Ｓ８１０）。ＡＰサーバ７０ｂは、受信したデータ要求にしたがって、該当するデータをＡＰサーバ６０ｂに応答する（Ｓ８１１）。

ＡＰサーバ６０ｂは、ＡＰサーバ７０ｂから受信したデータに対して、所定の処理を実行して得られたデータを、ＧＷ装置５０に送信する（Ｓ８１２）。ＧＷ装置５０は、ＡＰサーバ６０ｂから受信したデータをユーザ端末１０ａに応答する（Ｓ８１３）。例えば、ＡＰサーバ６０ｂは、ＡＰサーバ７０ｂから受信したドキュメントデータを印刷データに変換し、ＧＷ装置５０を介して、印刷データをユーザ端末１０ａに応答する。

また、ＧＷ装置５０のセッション管理部５８は、ユーザ端末１０ａにサービスを提供しているセッションの情報を収集して、セッション管理テーブル５２ｃに格納する（Ｓ５１４）。具体的には、セッション管理部５８は、ＧＷ装置５０とＡＰサーバ６０ｂとの間のセッション情報と、ＧＷ装置５０とＡＰサーバ７０ｂとの間のセッション情報と、これらのセッション情報の関係性とを収集する。

例えば、セッション管理部５８は、アカウント管理テーブル５２ｂを参照することで、どのテナントのどのユーザが、どのサービスＵＲＬにアクセスしているかを特定できる。また、セッション管理部５８は、連携サービステーブル５２ａを参照することで、特定したサービスＵＲＬがいずれのＵＲＬと連携しているかを特定することができる。また、セッション管理部５８は、現在確立されているセッションやＧＷ装置５０と他サーバとの間で送受信されたＷｅｂ画面におけるCookieから、セッションを識別するセッションＩＤを特定できる。そして、セッション管理部５８は、上記特定した各情報を関連付けたエントリを生成して、セッション管理テーブル５２ｃに格納する。

このようにして、ＧＷ装置５０は、連携サービスを行う複数のＡＰサーバの機能を使用するための代理認証の手続きを実施することができる。しかも、ＧＷ装置５０は、代理認証に用いられる複数の認証情報を、管理サーバ４０から一括して取得することができる。

（ログイン中からログアウトまで）
図１８は、実施例２に係るサービス提供システムにおけるログイン中からログアウトまでの処理シーケンス図である。

ログイン中のユーザ端末１０ａは、ログイン中のセッションを示すセッションＩＤ＝xxxxxを含めたサービス要求をＡＰサーバ７０ｂ「https://service1.com」に送信する（Ｓ９０１）。ただし、このメッセージはＧＷ装置５０に受信される。

そして、ＧＷ装置５０の事前認証部５５は、受信されたサービス要求メッセージを認証済みと判定する（Ｓ９０２）。例えば、事前認証部５５は、サービス要求メッセージを受信したＷｅｂページを利用する場合のCookieに含まれる「xxxxx」がログイン中のセッションであることから、事前認証済みと判定する。また、事前認証部５５は、サービス要求メッセージに含まれる「テナントＩＤ、ユーザＩＤ」がセッション管理テーブル５２ｃに登録されていることから、事前認証済みと判定することもできる。

そして、ＧＷ装置５０の代理認証部５７は、Ｓ７１６と同様、ＡＰサーバ６０ｂ「https://service1.com」にサービス要求メッセージを送信する（Ｓ９０３）。例えば、代理認証部５７は、サービス要求メッセージに含まれる「テナントＩＤ、ユーザＩＤ」に対応する「サービスＵＲＬ（連携元）」と「連携元セッションＩＤ」とを、セッション管理テーブル５２ｃから特定する。そして、代理認証部５７は、特定した「連携元セッションＩＤ」で識別されるセッションを用いて、「サービスＵＲＬ（連携元）＝ https://service1.com」に、サービス要求メッセージを送信する。

その後のＳ９０４からＳ９０７までの処理は、図１７で説明したＳ８１０からＳ８１３までと同様の処理なので、詳細な説明は省略する。

サービスを利用したユーザ端末１０ａは、ユーザの指示操作によって、ログアウト要求をＡＰサーバ７０ｂ「https://service1.com」に送信する（Ｓ９０８）。ただし、このメッセージはＧＷ装置５０に受信される。また、このログアウト要求のcookieには、セッションＩＤ＝yyyyyが含まれる。

ログアウト要求を受信したＧＷ装置５０のセッション管理部５８は、ユーザ端末１０ａがサービスの提供を受けているセッション情報をセッション維持テーブル５２ｄに登録した後（Ｓ９０９）、ログアウトを実行する（Ｓ９１０）。例えば、セッション管理部５８は、ユーザ端末１０ａの「テナントＩＤ、ユーザＩＤ」に対応付けられる「サービスＵＲＬ（連携元）、連携元セッションＩＤ、サービスＵＲＬ（連携先）、連携先セッションＩＤ」をセッション維持テーブル５２ｄに登録する。

（再ログイン時）
図１９は、実施例２に係るサービス提供システムにおける再ログイン時の処理シーケンス図である。図１９に示すように、Ｓ１００１からＳ１００８までの処理は、図１６のＳ７０１からＳ７０８までの処理と同様であるので、詳細な説明は省略する。

認証済みのサービス要求メッセージを受信したＧＷ装置５０の事前認証部５５が認証済みと判定し、セッション管理部５８は、セッション維持テーブル５２ｄからセッション情報を検出する（Ｓ１００９）。

例えば、セッション管理部５８は、サービス要求メッセージに含まれる「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ」を抽出する。続いて、セッション管理部５８は、抽出した「テナントＩＤ、ユーザＩＤ、サービスＵＲＬ」に対応するエントリをアカウント管理テーブル５２ｂから検索し、「ＩＤ、ＰＷ」を特定する。そして、セッション管理部５８は、抽出した「テナントＩＤ、サービスＵＲＬ」および特定した「ＩＤ」の組に対応するエントリをセッション維持テーブル５２ｄから検索し、「セッションＩＤ、連携先」を特定する。その後、セッション管理部５８は、セッションＩＤで識別されるセッションを用いて、抽出した「サービスＵＲＬ」に対して「連携先」と連携したサービスを要求する（Ｓ１０１０）。

その後のＳ１０１１からＳ１０１４の処理は、図１７のＳ８１０からＳ８１３までの処理と同様であるので、詳細な説明は省略する。

このように、実施例２に係るサービス提供システムでは、ＧＷ装置５０がユーザ端末に代わって、各ＡＰサーバへの認証を代理で実行することができる。また、ＧＷ装置５０が認証情報を管理サーバ４０から一括で取得することができるので、代理認証の処理が効率化する。また、ＧＷ装置５０は、ユーザがログアウトした後を、ログイン時に利用していたセッションを維持することができる。このため、サービスを利用したユーザが一度ログアウトした後に再度ログインしてサービスを利用する場合に、ＯＡｕｔｈ処理の確認フェーズを省略することができる。したがって、ＯＡｕｔｈ処理がボトルネックとなることを防止でき、処理性能の劣化を抑制できる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（セッション維持判定）
例えば、ＧＷ装置５０は、セッション情報を維持するか否かの判定基準をサービスごとに設けることができる。図２０は、セッション情報の判定基準例を示す図である。図２０に示すように、ＧＷ装置５０は、「サービスＵＲＬ（連携元）、サービスＵＲＬ（連携先）、セッション動作、タイムアウト」を対応付けて記憶する。ここで記憶される「セッション動作」は、セッションを維持するか削除するかを示す情報が設定される。また、「タイムアウト」は、削除するタイミングが設定される。

図２０を例にすると、ＧＷ装置５０は、サービス連携元が「https://service1.com」で、かつ、サービス連携先が「https://service2.com」であるサービスのセッション情報を、２４時間維持し、２４時間経過後に削除する。つまり、ＧＷ装置５０は、上記条件に該当するセッション情報をセッション維持テーブル５２ｄで２４時間保持し、２４時間経過後に、該当エントリをセッション維持テーブル５２ｄから削除する。なお、図２０に記憶される情報は、管理者等によって更新される。

このようにサービスごとに、維持するか削除するか等を柔軟に設定できるので、セキュリティを高く保つことができる。例えば、代金支払いサイトなど、セッションを維持し続けるにはリスクの高いサービスの場合には、維持することなく削除することができる。

（グループ管理）
実施例２では、ユーザ各々が、各ＡＰサーバに認証するためのＩＤとＰＷとを有する例を説明したが、これに限定されるものではなく、複数のユーザが、各ＡＰサーバに認証するためにＩＤとＰＷとを共有することができる。つまり、１つのグループアカウントを複数のユーザで共有することができる。

図２１は、１アカウントで１ユーザが利用できる場合の例を示す図である。図２１の構成は、実施例１や実施例２と同様なので、省略する。図２１に示すように、ＧＷ装置５０は、アカウント管理テーブル５２ｂに、「テナントＩＤ＝tenantY、ユーザＩＤ＝User001、サービスＵＲＬ＝https://service1.com、ＩＤ＝group1001、ＰＷ＝G＿PW」を記憶する。また、ＧＷ装置５０は、セッション維持テーブル５２ｄに、「連携元＝https://service1.com、ＩＤ＝group1001、セッションＩＤ＝yyyyy、状態＝login、連携先＝https://service2.com」を記憶する。つまり、ＩＤ＝group001に属するユーザＩＤ＝User001が、セッションＩＤ＝yyyyyで接続される「https://service1.com」が提供するサービスを利用中である状態である。

このような状態で、ＩＤ＝group001に属するユーザＩＤ＝User002がログインして、サービス要求メッセージを送信したとする。この場合、ＧＷ装置５０は、１アカウントで１ユーザが使用できる条件にしたがって、「ユーザＩＤ＝User002」のサービス要求メッセージを拒否する。このようにすることで、ＩＤを共有する場合であっても、１ユーザ１アカウントと同様のセキュリティレベルを維持できる。

図２２は、１アカウントで複数ユーザが利用できる場合の例を示す図である。図２２の構成は、実施例１や実施例２と同様なので、省略する。また、図２２におけるアカウント管理テーブル５２ｂおよびセッション維持テーブル５２ｄの状態は、図２１と同様なので説明を省略する。図２１と異なる点は、ＧＷ装置５０が、サービスＵＲＬに対応付けてセッション利用可能数を記憶する点である。

このような状態で、ＩＤ＝group001に属するユーザＩＤ＝User002がログインして、サービス要求メッセージを送信したとする。この場合、ＧＷ装置５０は、１アカウントで１０ユーザが使用できる条件にしたがって、「ユーザＩＤ＝User002」のサービス要求メッセージを許可する。このとき、ＧＷ装置５０は、ユーザ数が上限値を超える場合には、「ユーザＩＤ＝User002」のサービス要求メッセージを拒否する。このようにすることで、ＡＰサーバごと、または、サービスごとにセッションを接続できる数を定義できるので、サービスに適したセキュリティで、柔軟なサービスを提供することができる。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（ハードウェア構成）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。

図２３は、ハードウェア構成例を示す図である。図２３に示すように、ＧＷ装置１００は、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、媒体読取装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８を有する。また、図２３に示した各部は、バス１０１で相互に接続される。

入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０７は、図３等に示した機能を実行するプログラムとともに、実施例１や実施例２で説明した各テーブル等を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータが読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記録媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのＧＷ装置自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０２は、図３に示した各処理部と同様の処理を実行するプログラムを読み出してＲＡＭ１０８に展開することで、図３等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、受付部５４、事前認証部５５、問い合わせ部５６、代理認証部５７、セッション管理部５８を実行する。このようにＧＷ装置１００は、プログラムを読み出して実行することでセッション管理方法を実行する情報処理装置として動作する。

また、ＧＷ装置１００は、媒体読取装置１０６によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、ＧＷ装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。なお、図１や図２に示した他の装置も、図２３と同様のハードウェア構成を用いることができる。

３０ ＩＤＰサーバ
３１ 送受信部
３２ ログイン情報テーブル
３３ 認証部
４０ 管理サーバ
４１ 送受信部
４２ クラウド対応テーブル
４３ 認証情報テーブル
４４ 認証情報提供部
５０ ＧＷ装置
５１ 送受信部
５２ 記憶部
５２ａ 連携サービステーブル
５２ｂ アカウント管理テーブル
５２ｃ セッション管理テーブル
５２ｄ セッション維持テーブル
５３ 制御部
５４ 受付部
５５ 事前認証部
５６ 問い合わせ部
５７ 代理認証部
５８ セッション管理部

Claims (7)

1. ユーザ端末を認証した認証情報を用いてユーザ認証を代行するサービス要求装置において、
   ユーザを識別するユーザ識別子に対応付けて、前記ユーザがサービスの提供を要求するサービス連携元が使用するセッションの情報を示す連携元セッション情報と、前記サービス連携元と連携して前記ユーザにサービスを提供するサービス連携先が使用するセッションの情報を示す連携先セッション情報とを記憶する記憶部と、
   前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行する前記サービス連携元に対してサービスの提供を要求するユーザのユーザ識別子が、前記記憶部に記憶されているか否かを判定する判定部と、
   前記判定部によって前記ユーザ識別子が記憶されていると判定された場合に、前記ユーザ識別子に対応付けられて前記記憶部に記憶される前記連携元セッション情報を用いて接続されるサービス連携元に、前記連携元セッション情報に対応付けられた前記連携先セッション情報を用いて接続される、前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行する前記サービス連携先と連携したサービスの提供を要求する要求部と
   を有することを特徴とするサービス要求装置。
2. 前記サービス連携元に対してサービスの提供を要求するユーザが正当なユーザであるか否かを認証する認証部をさらに有し、
   前記判定部は、前記認証部によって正当なユーザであると認証されたユーザに対して、当該ユーザのユーザ識別子が、前記記憶部に記憶されているか否かを判定することを特徴とする請求項１に記載のサービス要求装置。
3. 前記ユーザが前記サービス連携元と前記サービス連携先とが連携して提供するサービスを終了する際に、前記サービスの提供を受けている前記ユーザの識別子と、前記サービス連携元の前記連携元セッション情報と、前記サービス連携先の前記連携先セッション情報とを取得し、取得した情報を対応付けて前記記憶部に格納する格納制御部をさらに有することを特徴とする請求項１に記載のサービス要求装置。
4. 前記ユーザに提供されるサービスごとに決められた有効期限にしたがって、前記記憶部に記憶されるエントリのうち、前記有効期限を超過したサービスのセッション情報に該当する前記連携元セッション情報または前記連携先セッション情報を含むエントリを、前記記憶部から削除する削除制御部をさらに有することを特徴とする請求項１に記載のサービス要求装置。
5. 前記記憶部に記憶される前記ユーザ識別子は、複数のユーザが属するグループを識別する識別子であって、
   前記判定部は、さらに、前記サービス連携元に対してサービスの提供を要求するユーザによって、当該ユーザのユーザ識別子が属するグループが、利用可能なセッション数を越えるか否かを判定することを特徴とする請求項１に記載のサービス要求装置。
6. ユーザ端末を認証した認証情報を用いてユーザ認証を代行するサービス要求装置が、
   前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行するサービス連携元に対してサービスの提供を要求するユーザのユーザ識別子が、前記ユーザ識別子と、前記ユーザがサービスの提供を要求するサービス連携元が使用するセッションの情報を示す連携元セッション情報と、前記サービス連携元と連携して前記ユーザにサービスを提供するサービス連携先が使用するセッションの情報を示す連携先セッション情報とを対応付けて記憶する記憶部に、記憶されているか否かを判定し、
   前記ユーザ識別子が記憶されていると判定した場合に、前記ユーザ識別子に対応付けられて前記記憶部に記憶される前記連携元セッション情報を用いて接続されるサービス連携元に、前記連携元セッション情報に対応付けられた前記連携先セッション情報を用いて接続される、前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行する前記サービス連携先と連携したサービスの提供を要求する
   処理を実行することを特徴とするサービス要求方法。
7. ユーザ端末を認証した認証情報を用いてユーザ認証を代行するサービス要求装置に、
   前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行するサービス連携元に対してサービスの提供を要求するユーザのユーザ識別子が、前記ユーザ識別子と、前記ユーザがサービスの提供を要求するサービス連携元が使用するセッションの情報を示す連携元セッション情報と、前記サービス連携元と連携して前記ユーザにサービスを提供するサービス連携先が使用するセッションの情報を示す連携先セッション情報とを対応付けて記憶する記憶部に、記憶されているか否かを判定し、
   前記ユーザ識別子が記憶されていると判定した場合に、前記ユーザ識別子に対応付けられて前記記憶部に記憶される前記連携元セッション情報を用いて接続されるサービス連携元に、前記連携元セッション情報に対応付けられた前記連携先セッション情報を用いて接続される、前記ユーザ端末に代わって前記サービス要求装置から前記認証情報を取得してユーザ認証を実行する前記サービス連携先と連携したサービスの提供を要求する
   処理を実行させることを特徴とするサービス要求プログラム。

Images