JP2017122957A - 情報処理装置及び情報処理プログラム - Google Patents

Abstract

【課題】クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることを可能にした情報処理装置を提供する。【解決手段】情報処理装置の記憶制御手段は、クライアントから受け付けた要求に付与された第１の情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行い、送信手段は、前記第２の情報を削除した応答を前記クライアントに送信する。【選択図】図１

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、持続的に同一の宛先へのＨＴＴＰ接続を導く目的で、ＨＴＴＰ接続のデータストリーム内のクッキー（Ｃｏｏｋｉｅ）を挿入し、検査するための方法及びシステムとして、要求されたリソースにアクセスするために同じサーバ（宛先）に同じクライアントからの後続のＨＴＴＰ接続を指示することが開示されている。つまり、同一クライアントからのリクエストをロードバランサの背後にある複数のアプリケーションサーバのうち、毎回同じサーバに転送するように、アプリケーションサーバを識別するための情報をクッキーに記載する方法が提案されている。

米国特許第６４７３８０２号明細書

ＲＥＳＴ ＡＰＩでは、論理的にはサーバ側は状態を持たないことが前提となっており、状態管理を目的としたクッキー（Ｃｏｏｋｉｅ）をクライアント側が使用することがない。
一方、論理的にはサーバ側に状態を持たない場合でも、同じクライアントからのリクエストを同じサーバ（実サーバ）に到達させることにより、キャッシュの有効利用等の面で性能上有利になることが多い。
しかし、特許文献１に記載の技術では、ＲＥＳＴ ＡＰＩに対応することができない。つまり、特許文献１に記載の技術では、クッキーをクライアント側が使用することとなるので、ＲＥＳＴ ＡＰＩに準じていないことになる。
本発明は、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることを可能にした情報処理装置及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、クライアントから受け付けた要求に付与された第１の情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、前記第２の情報を削除した応答を前記クライアントに送信する送信手段を有する情報処理装置である。

請求項２の発明は、クライアントから受け付けた要求に付与された第１の情報を前記記憶装置から検索して、該第１の情報に対応する第２の情報を該要求に付与し、該第２の情報が付与された要求をロードバランサ手段に送信する第２の送信手段をさらに有する請求項１に記載の情報処理装置である。

請求項３の発明は、認可サーバから第１の情報を受け付ける受付手段と、ロードバランサ手段に要求を送信する送信手段と、前記ロードバランサ手段から前記要求に対する応答に付与された第２の情報を受け付ける第２の受付手段と、前記第２の情報を前記認可サーバに送信する第２の送信手段を有する情報処理装置である。

請求項４の発明は、クライアントから受け付けた要求に付与された第１の情報から前記第２の情報を抽出し、該要求に付与する付与手段と、前記要求と前記第１の情報と前記第２の情報をロードバランサ手段に送信する第３の送信手段をさらに有する請求項３に記載の情報処理装置である。

請求項５の発明は、認可サーバからユーザーに関する情報を受け付ける受付手段と、要求を行ったユーザーに関する情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、前記受付手段によって受け付けられたユーザーに関する情報に類似するユーザーに関する情報を前記記憶装置から検索し、該検索されたユーザーに関する情報に対応する第２の情報を前記認可サーバに送信する送信手段を有する情報処理装置である。

請求項６の発明は、前記ユーザーに関する情報として、該ユーザーを識別するための識別情報、該ユーザーが属しているグループを識別するための識別情報、該ユーザーの役割を示す情報、該ユーザーがアクセス可能なリソースを示す情報のいずれか１つ、又はこれらの組み合わせを利用する、請求項５に記載の情報処理装置である。

請求項７の発明は、前記第１の情報として、クライアントが認可サーバから取得するアクセストークンを利用し、前記第２の情報として、前記ロードバランサ手段が発行したクッキーを利用する、請求項１から４のいずれか一項に記載の情報処理装置である。

請求項８の発明は、コンピュータを、クライアントから受け付けた要求に付与された第１の情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、前記第２の情報を削除した応答を前記クライアントに送信する送信手段として機能させるための情報処理プログラムである。

請求項９の発明は、コンピュータを、認可サーバから受け付けた第１の情報を受け付ける受付手段と、ロードバランサ手段に要求を送信する送信手段と、前記ロードバランサ手段から前記要求に対する応答に付与された第２の情報を受け付ける第２の受付手段と、前記第２の情報を前記認可サーバに送信する第２の送信手段として機能させるための情報処理プログラムである。

請求項１０の発明は、コンピュータを、認可サーバから受け付けたユーザーに関する情報を受け付ける受付手段と、要求を行ったユーザーに関する情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、前記受付手段によって受け付けられたユーザーに関する情報に類似するユーザーに関する情報を前記記憶装置から検索し、該検索されたユーザーに関する情報に対応する第２の情報を前記認可サーバに送信する送信手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

請求項２の情報処理装置によれば、クライアントから受け付けた要求に付与された第１の情報を記憶装置から検索して、その第１の情報に対応する第２の情報をその要求に付与し、その第２の情報が付与された要求をロードバランサ手段に送信することができる。

請求項３の情報処理装置によれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

請求項４の情報処理装置によれば、クライアントから受け付けた要求に付与された第１の情報から第２の情報を抽出し、要求と第１の情報と第２の情報をロードバランサ手段に送信することができる。

請求項５の情報処理装置によれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

請求項６の情報処理装置によれば、ユーザーに関する情報として、ユーザーを識別するための識別情報、そのユーザーが属しているグループを識別するための識別情報、そのユーザーの役割を示す情報、そのユーザーがアクセス可能なリソースを示す情報のいずれか１つ、又はこれらの組み合わせを利用することができる。

請求項７の情報処理装置によれば、第１の情報として、クライアントが取得したアクセストークンを利用し、第２の情報として、ロードバランサ手段が発行したクッキーを利用することができる。

請求項８の情報処理プログラムによれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

請求項９の情報処理プログラムによれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

請求項１０の情報処理プログラムによれば、クライアントにクッキーを使用させることなく、同じクライアントからの要求を同じサーバに処理させることができる。

第１の実施の形態の構成例についての概念的なモジュール構成図である。 第１の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を利用したシステム構成例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 第１の実施の形態による処理例を示すフローチャートである。 クッキーデータのデータ構造例を示す説明図である。 関連テーブルのデータ構造例を示す説明図である。 関連テーブルのデータ構造例を示す説明図である。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 第２の実施の形態による処理例を示すフローチャートである。 第２の実施の形態による処理例を示すフローチャートである。 アクセストークンデータのデータ構造例を示す説明図である。 第３の実施の形態の構成例についての概念的なモジュール構成図である。 第３の実施の形態の構成例についての概念的なモジュール構成図である。 第３の実施の形態による処理例を示すフローチャートである。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
＜第１の実施の形態＞
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態にしたがって、又はそれまでの状況・状態にしたがって定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

第１の実施の形態である情報処理システムは、クライアント１１０からの要求（リクエスト）に応じて、アプリケーションサーバ１４５が処理を行うものであって、図１の例に示すように、クライアント１１０、認可サーバ１２０、中継装置１３０、ロードバランサ１４０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃを有している。なお、図１では、３つのアプリケーションサーバ１４５を例示しているが、複数のアプリケーションサーバ１４５を使用すればよい。クライアント１１０と認可サーバ１２０、クライアント１１０と中継装置１３０、中継装置１３０とロードバランサ１４０、ロードバランサ１４０と各アプリケーションサーバ１４５は、通信回線を介して接続されている。
なお、請求項に記載の「第１の情報」として、例えば、アクセストークン又はこのアクセストークンと同等の機能（ここでは、同じクライアントであることを保証できる機能）を有する情報であればよい。以下、アクセストークンを例示して説明する。また、「第２の情報」として、例えば、クッキー又はこのクッキーと同等の機能（ここでは、アプリケーションサーバを指定できる機能）を有する情報であればよい。以下、クッキーを例示して説明する。「ロードバランサ手段」として、例えば、図１、９、１４に示すロードバランサ１４０、図２に示すロードバランス処理モジュール２３５、図１０に示すロードバランス処理モジュール１０３５、図１５に示すロードバランス処理モジュール１５３２が該当する。

クライアント１１０とロードバランサ１４０の間に中継装置１３０を置き、その中継装置１３０内でアクセストークンからロードバランサ１４０が解釈するクッキーを生成し、中継装置１３０からロードバランサ１４０への要求を転送する際に付与する。これによって、ＲＥＳＴ ＡＰＩにしたがって（つまり、クライアント１１０はクッキーを利用することなく、アプリケーションサーバ１４５もクッキーを利用することなく）、クライアント１１０からの複数回の要求を同じアプリケーションサーバ１４５に処理させることができるようになる。なお、同じアプリケーションサーバ１４５に処理させるのは、例えば、そのユーザーにとって、毎回異なるアプリケーションサーバ１４５が処理を行うよりも効率的な処理を実施することができ、また、ユーザーに関する処理である場合、前回のそのユーザーに関する処理結果を用いることができることがあるからである。

クライアント１１０は、認可サーバ１２０、中継装置１３０と接続されている。クライアント１１０は、通信機能を有しており、ユーザーが用いる情報処理装置である。例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ、ノートＰＣ等であってもよい）、携帯端末（スマートフォンを含む携帯電話等）、ウェアラブル端末（リストバンド型（腕輪型）、腕時計型、頭に装着するメガネ型）等が該当する。クライアント１１０は、認可サーバ１２０からアクセストークンを取得し、そのアクセストークンを付与した要求を中継装置１３０に送信する。
具体的には、クライアント１１０は、アプリケーションサーバ１４５を利用するクライアントであって、中継装置１３０及びロードバランサ１４０を経由してＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）呼び出しを実行する。なお、ＡＰＩ呼び出しに先立ち、認可サーバ１２０からアクセストークンを取得する。

認可サーバ１２０は、クライアント１１０と接続されている。認可サーバ１２０は、通信機能を有しており、クライアント１１０からの要求にしたがってアクセストークンを生成し、クライアント１１０に送信する。ここでアクセストークンとは、クライアント１１０（又はクライアント１１０を利用するユーザー）が、アプリケーションサーバ１４５を利用することができることを証明する情報である。例えば、認証済みユーザーを識別するための文字列等が該当する。アクセストークンを生成するために、クライアント１１０から、ユーザーによってログイン操作（ユーザー名とパスワード（指紋認証等の生体認証を含めてもよい）の受付）が行われる。なお、一般的に、アクセストークンには有効期限が設定されている。
具体的には、認可サーバ１２０は、ＡＰＩ呼び出しの権限を表すアクセストークンを生成する。第１の実施の形態では、認可の仕組みには依存しないが、例としてはＯＡｕｔｈ２（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９）を用いてもよい。なお、認可サーバ１２０が発行するアクセストークンはクライアント１１０から透過的な（意味を持たない）ものなので任意の文字列が使われるが、一般にはＪＷＴ（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７５１９）が用いられる。

中継装置１３０は、記録装置１３５を有しており、クライアント１１０、ロードバランサ１４０と接続されている。中継装置１３０は、通信機能を有しており、クライアント１１０とロードバランサ１４０の間に存在し、クライアント１１０からロードバランサ１４０又はロードバランサ１４０からクライアント１１０にアクセスするためには、中継装置１３０を経由することになる。
中継装置１３０は、クライアント１１０から受け付けた要求に付与されたアクセストークン（第１の情報の一形態）と、その要求に対してロードバランサ１４０（ロードバランサ手段の一形態）から受け付けた応答に付与されたクッキー（第２の情報の一形態）を対応付けて記録装置１３５に記憶させる制御を行う。ここで前述したように、第１の情報として、クライアント１１０が認可サーバ１２０から取得したアクセストークンを利用し、第２の情報として、ロードバランサ１４０が発行したクッキーを利用する。
そして、中継装置１３０は、ロードバランサ１４０から受け取った応答から、クッキーを削除し、そのクッキーを削除した後の応答をクライアント１１０に送信する。
また、中継装置１３０は、クライアント１１０から受け付けた要求に付与されたアクセストークンを記録装置１３５から検索して、そのアクセストークンに対応するクッキーを、その要求に付与し、そのクッキーが付与された要求をロードバランサ１４０に送信するようにしてもよい。
具体的には、中継装置１３０は、クライアント１１０からアプリケーションサーバ１４５へのＡＰＩ呼び出し（アクセストークンを含む要求）を中継する。中継する際に、アクセストークンからロードバランサ１４０が使用するクッキーを付与する。第１の実施の形態では、最初に、ロードバランサ１４０が生成したクッキーをアクセストークンと紐づけて記録装置１３５に記憶させ、次回同じアクセストークンでリクエストが来た場合にそのクッキーを付与してロードバランサ１４０（最終的にはアプリケーションサーバ１４５）に要求を転送する。

記録装置１３５は、アクセストークンとクッキーを対応付けて（アクセストークンとクッキーのペアを）記憶する。例えば、関連テーブル７００を記憶する。図７は、関連テーブル７００のデータ構造例を示す説明図である。関連テーブル７００は、アクセストークン欄７１０、サーバＩＤ欄７２０、ユーザーＩＤ欄７３０、グループＩＤ欄７４０、ロール欄７５０、最終アクセス時刻欄７６０、アクセストークン有効期限欄７７０を有している。アクセストークン欄７１０は、アクセストークンを記憶している。サーバＩＤ欄７２０は、本実施の形態において、アプリケーションサーバ１４５を一意に識別するための情報（サーバＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）を記憶している。ユーザーＩＤ欄７３０は、本実施の形態において、ユーザーを一意に識別するための情報（ユーザーＩＤ）を記憶している。グループＩＤ欄７４０は、本実施の形態において、グループを一意に識別するための情報（グループＩＤ）を記憶している。ロール欄７５０は、そのユーザー又はグループが有しているロール（「ユーザーの役割を示す情報」の一形態であって、役割、役柄、任務、クラス等を含む）を記憶している。最終アクセス時刻欄７６０は、そのユーザーによって行われたアプリケーションサーバ１４５への最終アクセス時刻（最新アクセス時刻）を記憶している。アクセストークン有効期限欄７７０は、そのアクセストークンの有効期限を記憶している。
なお、サーバＩＤ欄７２０内の情報は、ロードバランサ１４０から得た応答に付与されたクッキーから抽出した情報である。したがって、アクセストークンとクッキーが対応付けられている。最終アクセス時刻欄７６０又はアクセストークン有効期限欄７７０内の情報は、関連テーブル７００内のその行にある関連付けデータの削除を判断するために用いる。例えば、現在の時刻が、最終アクセス時刻欄７６０内の時刻から予め定められた期間が過ぎている場合は、その行の関連付けデータを削除してもよい。また、現在の時刻が、アクセストークン有効期限欄７７０内の有効期限を過ぎている場合は、その行の関連付けデータを削除してもよい。
また、記録装置１３５は、関連テーブル８００を記憶していてもよい。図８は、関連テーブル８００のデータ構造例を示す説明図である。関連テーブル８００は、アクセストークン欄８１０、Ｃｏｏｋｉｅ欄８２０を有している。アクセストークン欄８１０は、アクセストークンを記憶している。Ｃｏｏｋｉｅ欄８２０は、そのアクセストークンに対応するクッキーを記憶している。

ロードバランサ１４０は、中継装置１３０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。ロードバランサ１４０は、通信機能を有しており、負荷分散装置であり、クライアント１１０から送信された要求を、２台以上のアプリケーションサーバ１４５に振り分けて処理（分散処理）をさせるものである。要求の割り当て方は既存の方法を用いればよい。例えば、各アプリケーションサーバ１４５に順番に均等に割り当てるラウンドロビン方式等を採用してもよい。ここでのロードバランサ１４０は、既存のロードバランサを採用してもよい。例えば、特許文献１に記載の技術を用いてもよい。具体的には、同じクライアント１１０（又はユーザー）からの要求は、同じアプリケーションサーバ１４５に処理させるために、アプリケーションサーバ１４５からの処理結果を受け取った場合に、その処理結果にクッキーを付与して、中継装置１３０を介してクライアント１１０に送信する。
具体的には、ロードバランサ１４０は、クライアント１１０からの要求を後段のアプリケーションサーバ１４５に分散して転送する。同一クライアント１１０からの要求を同じアプリケーションサーバ１４５に転送するために、クッキーに転送先を決定するための情報を埋め込む。例えば、クッキー内に図６に示すクッキーデータ６００を埋め込む。クッキーデータ６００は、ロードバランサ１４０が設定するクッキー情報の例を示しており、具体的には、処理させるアプリケーションサーバ１４５として、「Ｓ１」を指定していることを意味している。

各アプリケーションサーバ１４５は、ロードバランサ１４０と接続されている。アプリケーションサーバ１４５は、通信機能を有しており、ロードバランサ１４０からの要求にしたがって処理を行い、その処理結果をロードバランサ１４０に返信する。

図２は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。図１の例に示した第１の実施の形態とは、異なるモジュール構成にしたものである。図２の例に示したロードバランサ２３０は、図１の例に示した中継装置１３０とロードバランサ１４０を組み合わせたものであり、両者の機能を有している。そして、ロードバランサ１４０の機能をロードバランス処理モジュール２３５が有している。
クライアント１１０は、認可サーバ１２０、ロードバランサ２３０と接続されている。
認可サーバ１２０は、クライアント１１０と接続されている。
ロードバランサ２３０は、ロードバランス処理モジュール２３５、記録装置１３５を有しており、クライアント１１０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。
各アプリケーションサーバ１４５は、ロードバランサ２３０と接続されている。

図３は、本実施の形態を利用したシステム構成例を示す説明図である。
クライアント１１０Ａ、クライアント１１０Ｂ、クライアント１１０Ｃ、認可サーバ１２０、中継装置１３０、ロードバランサ２３０は、通信回線３９０を介してそれぞれ接続されている。通信回線３９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、中継装置１３０（ロードバランサ１４０、アプリケーションサーバ１：１４５Ａ等を含めてもよい）、ロードバランサ２３０（アプリケーションサーバ４：１４５Ｄ等を含めてもよい）による機能は、クラウドサービスとして実現してもよい。もちろんのことながら、クライアント１１０、認可サーバ１２０、中継装置１３０、ロードバランサ２３０等の設置は、図３の例に示した個数以外の個数であってもよい。
各クライアント１１０のブラウザ等が用いられて、各ホームページからサービス（アプリケーションサーバ１：１４５Ａ等又はアプリケーションサーバ４：１４５Ｄ等が提供するサービス）が提供される。ユーザーの操作にしたがって、アプリケーションサーバ１４５に対して要求が送信され、アプリケーションサーバ１４５等によるサービス（要求に対する処理）が提供される。その場合に、アプリケーションサーバ１４５、クライアント１１０間では、ＲＥＳＴ ＡＰＩにしたがってクッキーの利用はされないが、中継装置１３０とロードバランサ１４０（又はロードバランサ２３０）によって、同じクライアント１１０からの要求は、同じアプリケーションサーバ１４５に処理させることができるようになる。

図４は、第１の実施の形態による処理例を示すフローチャートである。クライアント１１０から初回の要求があった場合の処理例を示すものである。
ステップＳ４０２では、クライアント１１０が認可サーバ１２０にアクセストークンを要求する。
ステップＳ４０４では、認可サーバ１２０がアクセストークンをクライアント１１０に返す。
ステップＳ４０６では、クライアント１１０が中継装置１３０にアクセストークン付きでＡＰＩ要求を発行する。
ステップＳ４０８では、ロードバランサ１４０がアプリケーションサーバ１４５の１つを決定し、要求を転送する。

ステップＳ４１０では、アプリケーションサーバ１４５が要求に対し応答を返す。
ステップＳ４１２では、ロードバランサ１４０が転送先アプリケーションサーバ１４５を固定するクッキーを応答に付与する。
ステップＳ４１４では、中継装置１３０がアクセストークンとクッキーの情報を紐づけて記録し、クッキー情報を応答から削除する。なお、このときにユーザーＩＤも合わせて記録してもよい。
ステップＳ４１６では、クライアント１１０が応答を受け取る。ここでの応答は、クッキーが付与されていないデータ（ステップＳ４１０での応答と同等）である。

図５は、第１の実施の形態による処理例を示すフローチャートである。クライアント１１０から２回目以降の要求があった場合の処理例を示すものである。つまり、図４の例に示すフローチャートの処理が実行された後に、クライアント１１０が発行した要求に対する処理である。
ステップＳ５０２では、クライアント１１０が中継装置１３０にアクセストークン付きでＡＰＩ要求を発行する。なお、ここでのアクセストークンは、図４の例に示すフローチャートの処理によって取得したアクセストークンである。
ステップＳ５０４では、中継装置１３０がアクセストークンに関連付けられたクッキーを要求に付与する。また、アクセストークンに関連付けられたクッキーがない場合は、ユーザーＩＤ／グループＩＤ／ロールＩＤで検索して、類似性の高いユーザーの使用したクッキーを使用してもよい。
ステップＳ５０６では、ロードバランサ１４０がクッキーに基づきアプリケーションサーバ１４５を決定し、要求を転送する。

ステップＳ５０８では、アプリケーションサーバ１４５が要求に対し応答を返す。
ステップＳ５１０では、ロードバランサ１４０が応答をそのまま転送する。
ステップＳ５１２では、中継装置１３０が応答をそのまま転送する。
ステップＳ５１４では、クライアント１１０が応答を受け取る。
なお、図５の例に示すフローチャートの処理は、記録装置１３５内にアクセストークンとクッキーのペアが記憶されているので、ステップＳ５１０、ステップＳ５１２では、応答をそのまま転送している。ただし、図４の例に示すフローチャート、図５の例に示すフローチャートで、ロードバランサ１４０が同じ処理を行わせるため（つまり、図４の例に示すフローチャートの処理、図５の例に示すフローチャートの処理であることを区別させる必要をなくすため）、クッキーを付与してもよい。その場合、ステップＳ５１２で、中継装置１３０が、そのクッキーを削除すればよい。

＜第２の実施の形態＞
図９は、第２の実施の形態の構成例についての概念的なモジュール構成図である。なお、前述の実施の形態と同種の部位には同一符号を付し重複した説明を省略する（以下、同様）。第２の実施の形態は、第１の実施の形態のようにクッキーとアクセストークンのペアを記録する必要がなくなり、必要メモリ量が削減できる。
クライアント１１０は、認可サーバ９２０、中継装置９３０と接続されている。
認可サーバ９２０は、クライアント１１０、中継装置９３０と接続されている。認可サーバ９２０は、第１の実施の形態の認可サーバ１２０と同等のアクセストークンの生成処理を行うが、生成したアクセストークンに付与するクッキーを中継装置９３０に要求する。そして、中継装置９３０からクッキーを受け取り、アクセストークンにクッキーを埋め込んで、そのアクセストークン（クッキーが付与されたアクセストークン）をクライアント１１０に渡す。
又は、認可サーバ９２０は、アクセストークンの生成処理を行い、生成したアクセストークンを中継装置９３０に渡す。中継装置９３０が、アクセストークンにクッキーを付与する。そして、中継装置９３０が、そのアクセストークン（クッキーが付与されたアクセストークン）をクライアント１１０に渡すようにしてもよい。若しくは、中継装置９３０が、そのアクセストークン（クッキーが付与されたアクセストークン）を認可サーバ９２０に渡し、認可サーバ９２０がそのアクセストークンをクライアント１１０に渡すようにしてもよい。

中継装置９３０は、クライアント１１０、認可サーバ９２０、ロードバランサ１４０と接続されている。中継装置９３０は、認可サーバ９２０からアクセストークンを受け付ける。ロードバランサ１４０に、任意の要求を送信する。ここでの要求は、クッキーを生成させるためだけの要求であり、アプリケーションサーバ１４５に実際の処理を行わせるものでなくてもよい。もちろんのことながら、実際の処理を行わせる要求であってもよい。そして、ロードバランサ１４０から要求に対する応答に付与されたクッキーを受け付ける。次に、そのクッキーを認可サーバ９２０に送信する。
また、中継装置９３０は、クライアント１１０から受け付けた要求に付与されたアクセストークンからクッキーを抽出し、その要求に付与するようにしてもよい。なお、この中継装置９３０における「付与する」処理は、アクセストークンから抽出したクッキー情報を、本来のクッキーとして機能するように要求に付与する処理である。
そして、要求とアクセストークンとクッキー（アクセストークンとクッキーが付与された要求）をロードバランサ１４０に送信するようにしてもよい。
具体的には、中継装置９３０は、クライアント１１０からアプリケーションサーバ１４５へのＡＰＩ呼び出し（アクセストークンを含む要求）を中継する。中継する際に、アクセストークンからロードバランサ１４０が使用するクッキーを付与する。第２の実施の形態では、認可サーバ９２０と連携し、認可サーバ９２０が発行するアクセストークンに、ロードバランサ１４０が生成したクッキー情報を埋め込んでクライアント１１０にアクセストークンを提供する。なお、クッキー情報を埋め込む処理自体、クライアント１１０にアクセストークンを送信する処理自体は、中継装置９３０が行ってもよいし、認可サーバ９２０が行ってもよい。

ロードバランサ１４０は、中継装置９３０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。
アプリケーションサーバ１４５は、ロードバランサ１４０と接続されている。

図１０は、第２の実施の形態の構成例についての概念的なモジュール構成図である。図９の例に示した第２の実施の形態とは、異なるモジュール構成にしたものである。図１０の例に示したロードバランサ１０３０は、図９の例に示した中継装置９３０とロードバランサ１４０を組み合わせたものであり、両者の機能を有している。そして、ロードバランサ１４０の機能をロードバランス処理モジュール１０３５が有している。
クライアント１１０は、認可サーバ９２０、ロードバランサ１０３０と接続されている。
認可サーバ９２０は、クライアント１１０、ロードバランサ１０３０と接続されている。
ロードバランサ１０３０は、クライアント１１０、認可サーバ９２０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。
各アプリケーションサーバ１４５は、ロードバランサ１０３０と接続されている。

図１１は、第２の実施の形態による処理例を示すフローチャートである。主に、アクセストークンの発行処理例を示すものである。
ステップＳ１１０２では、クライアント１１０が認可サーバ９２０にアクセストークンを要求する。
ステップＳ１１０４では、認可サーバ９２０は中継装置９３０にアクセストークンに埋め込む追加情報（クッキー情報）を要求する。
ステップＳ１１０６では、中継装置９３０はロードバランサ１４０に適当な要求を発行する。ここでの要求は、前述したように、クッキーを生成させるためだけの要求であり、アプリケーションサーバ１４５に実際の処理を行わせるものでなくてもよい（例えば、単に、返信を行わせるだけの処理等）。もちろんのことながら、実際の処理を行わせる要求であってもよい。
ステップＳ１１０８では、ロードバランサ１４０がアプリケーションサーバ１４５の１つを決定し、要求を転送する。

ステップＳ１１１０では、アプリケーションサーバ１４５が要求に対し応答を返す。
ステップＳ１１１２では、ロードバランサ１４０が転送先アプリケーションサーバ１４５を固定するクッキーを応答に付与する。
ステップＳ１１１４では、中継装置９３０がロードバランサ１４０が生成したクッキーからアクセストークンに埋め込む情報を生成し、認可サーバ９２０に返す。
ステップＳ１１１６では、認可サーバ９２０がクライアント１１０にアクセストークンを返す。認可サーバ９２０は、例えば、アクセストークンデータ１３００を生成する。図１３は、アクセストークンデータ１３００のデータ構造例を示す説明図である。アクセストークンデータ１３００の末尾（図１３の例では、「．」の右側）にロードバランサ１４０（ロードバランス処理モジュール１０３５）が設定したクッキーに含まれるサーバＩＤ（アプリケーションサーバ１４５の識別情報、図１３の例では「Ｓ１」）を付与したものである。
ステップＳ１１１８では、クライアント１１０がアクセストークン（クッキーが埋め込まれたアクセストークン）を受け取る。

図１２は、第２の実施の形態による処理例を示すフローチャートである。主に、ＡＰＩアクセス処理例を示すものである。このＡＰＩアクセス処理が行われるためには、アクセストークンの生成処理（図１１の例に示すフローチャートの処理）が行われている必要がある。
ステップＳ１２０２では、クライアント１１０が中継装置９３０にアクセストークン付きでＡＰＩ要求を発行する。ここでのアクセストークンには、図１１の例に示すフローチャートの処理が行われたものであり、クッキー情報が埋め込まれている。
ステップＳ１２０４では、中継装置９３０がアクセストークンに埋め込まれた情報からクッキーを復元し、そのクッキーを要求に付与する。
ステップＳ１２０６では、ロードバランサ１４０がクッキーに基づきアプリケーションサーバ１４５を決定し、要求を転送する。

ステップＳ１２０８では、アプリケーションサーバ１４５が要求に対し応答を返す。
ステップＳ１２１０では、ロードバランサ１４０が応答をそのまま転送する。
ステップＳ１２１２では、中継装置９３０が応答をそのまま転送する。
ステップＳ１２１４では、クライアント１１０が応答を受け取る。

＜第３の実施の形態＞
図１４は、第３の実施の形態の構成例についての概念的なモジュール構成図である。第１の実施の形態（記録モード）と第２の実施の形態（埋め込みモード）とを組み合わせたものである。
第１の実施の形態では、第２の実施の形態による任意の要求を行う等のような余分の処理が少ないが、アクセストークンとクッキーの関連付けを保持するため、メモリ容量を必要とする。
第２の実施の形態では、アクセストークンへの情報の埋め込みに先立ち、どのアプリケーションサーバ１４５にリクエストを送るかを決定するために、いったん中継装置９３０からロードバランサ１４０へのなんらかのＨＴＴＰリクエストを送る必要がある。しかし、アクセストークンとクッキーの関連付けを保持する必要がないため、メモリ容量は不要である。
第３の実施の形態では、第１の実施の形態における記録装置１３５を利用して、クッキー情報をアクセストークンに埋め込む処理を行っている。

クライアント１１０は、認可サーバ１４２０、中継装置１４３０と接続されている。
認可サーバ１４２０は、クライアント１１０、中継装置１４３０と接続されている。認可サーバ１４２０は、認可サーバ９２０と同等の処理を行う。

中継装置１４３０は、記録装置１３５を有しており、クライアント１１０、認可サーバ１４２０、ロードバランサ１４０と接続されている。中継装置１４３０は、認可サーバ１４２０からユーザーに関する情報を受け付ける。
そして、要求を行ったユーザーに関する情報と、その要求に対してロードバランサ１４０から受け付けた応答に付与されたクッキーを対応付けて記録装置１３５に記憶させる制御を行う。例えば、記録装置１３５は、関連テーブル７００を記憶する。
受け付けたユーザーに関する情報に類似するユーザーに関する情報を記録装置１３５から検索し、その検索されたユーザーに関する情報に対応するクッキーを認可サーバ１４２０に送信する。
ここでユーザーに関する情報として、そのユーザーを識別するための識別情報、そのユーザーが属しているグループを識別するための識別情報、そのユーザーの役割を示す情報、そのユーザーがアクセス可能なリソースを示す情報のいずれか１つ、又はこれらの組み合わせを利用するようにしてもよい。

例えば、第３の実施の形態の中継装置１４３０では、アクセストークンに含まれるユーザーＩＤを利用して、同じユーザーのクッキーを再利用する。前回と同じユーザーからの要求を同じアプリケーションサーバ１４５に割り振ることにより、そのユーザーの権限、属性、アクセスするリソース等が、そのアプリケーションサーバ１４５上でキャッシュ済みである可能性が高まり、性能を向上させることができる。
また、第３の実施の形態の中継装置１４３０は、アクセストークンに含まれるユーザーＩＤ情報から、そのユーザーが属するグループ又はそのユーザーに割り当てられているロール（役割、一般ユーザー、管理者等）を決定し、類似（同じ場合を含む）するグループ又はロールのユーザーが使用したアプリケーションサーバ１４５に要求を転送するようにクッキーを再利用するようにしてもよい。一般に、ユーザーの権限を確認するためには、そのユーザーの属するグループの保有している権限や、そのユーザーに割り当てられている権限を調べる必要がある。同じグループ又はロールからのアクセスを同じアプリケーションサーバ１４５に転送することにより、アプリケーションサーバ１４５上でグループ又はロールの権限、属性、アクセスするリソース等を、すでにそのアプリケーションサーバ１４５のメモリ上にロード済みである可能性が高まり、性能を向上させることができる。
また、第３の実施の形態の中継装置１４３０は、アクセストークンに含まれるスコープ情報から、類似するスコープ情報を有するユーザーが使用したアプリケーションサーバ１４５に要求を転送するようにクッキーを再利用するようにしてもよい。なお、スコープとはアクセス可能なリソースを宣言する識別子である。アクセスするリソースが、キャッシュ済みである可能性が高まり、性能を向上させることができる。

ロードバランサ１４０は、中継装置１４３０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。
各アプリケーションサーバ１４５は、ロードバランサ１４０と接続されている。

図１５は、第３の実施の形態の構成例についての概念的なモジュール構成図である。図１４の例に示した第３の実施の形態とは、異なるモジュール構成にしたものである。図１５の例に示したロードバランサ１５３０は、図１４の例に示した中継装置１４３０とロードバランサ１４０を組み合わせたものであり、両者の機能を有している。そして、ロードバランサ１４０の機能をロードバランス処理モジュール１５３２が有している。
クライアント１１０は、認可サーバ１４２０、ロードバランサ１５３０と接続されている。
認可サーバ１４２０は、クライアント１１０、ロードバランサ１５３０と接続されている。
ロードバランサ１５３０は、ロードバランス処理モジュール１５３２、記録装置１３５を有しており、クライアント１１０、認可サーバ１４２０、アプリケーションサーバ１：１４５Ａ、アプリケーションサーバ２：１４５Ｂ、アプリケーションサーバ３：１４５Ｃと接続されている。
各アプリケーションサーバ１４５は、ロードバランサ１５３０と接続されている。

図１６は、第３の実施の形態による処理例を示すフローチャートである。記録装置１３５内の類似するユーザーのクッキーを利用する処理例を示すものである。
ステップＳ１６０２では、クライアント１１０が認可サーバ１４２０にアクセストークンを要求する。
ステップＳ１６０４では、認可サーバ１４２０は中継装置１４３０にユーザーＩＤを渡し、アクセストークンに埋め込む追加情報を要求する。
ステップＳ１６０６では、中継装置１４３０はユーザーＩＤ、グループＩＤ、ロールＩＤで検索して類似性の高いユーザーに関連付けられたクッキーを記録装置１３５から検索し、あれば認可サーバ１４２０に返す。

ステップＳ１６０８では、ロードバランサ１４０がアプリケーションサーバ１４５の１つを決定し、要求を転送する。なお、ステップＳ１６０８の処理は、ステップＳ１６０６で類似性の高いユーザーに関連付けられたクッキーが記録装置１３５にはない場合に行うようにしてもよい。そして、図１１の例に示したフローチャート内のステップＳ１１０６の処理を行った後、ステップＳ１６０８の処理を行い、ステップＳ１１１０からステップＳ１１１４までの処理を行うようにしてもよい。
ステップＳ１６１０では、認可サーバ１４２０がクライアント１１０にアクセストークンを返す。
ステップＳ１６１２では、クライアント１１０がアクセストークンを受け取る。
この後、図１２の例に示すフローチャートにしたがった処理を行う。

図１７を参照して、本実施の形態の情報処理装置（クライアント１１０、認可サーバ１２０、中継装置１３０、ロードバランサ１４０、アプリケーションサーバ１４５）のハードウェア構成例について説明する。図１７に示す構成は、例えばパーソナルコンピュータ（ＰＣ）等によって構成されるものであり、スキャナ等のデータ読み取り部１７１７と、プリンタ等のデータ出力部１７１８を備えたハードウェア構成例を示している。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１７０１は、前述の実施の形態において説明した各種のモジュール、すなわち、クライアント１１０、認可サーバ１２０、中継装置１３０、ロードバランサ１４０、アプリケーションサーバ１４５、ロードバランサ２３０、ロードバランス処理モジュール２３５、認可サーバ９２０、中継装置９３０、ロードバランサ１０３０、ロードバランス処理モジュール１０３５、認可サーバ１４２０、中継装置１４３０、ロードバランサ１５３０、ロードバランス処理モジュール１５３２等の各装置又はモジュールの実行シーケンスを記述したコンピュータ・プログラムにしたがった処理を実行する制御部である。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１７０２は、ＣＰＵ１７０１が使用するプログラムや演算パラメータ等を格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１７０３は、ＣＰＵ１７０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を格納する。これらはＣＰＵバス等から構成されるホストバス１７０４により相互に接続されている。

ホストバス１７０４は、ブリッジ１７０５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス１７０６に接続されている。

キーボード１７０８、マウス等のポインティングデバイス１７０９は、操作者により操作されるデバイスである。ディスプレイ１７１０は、液晶表示装置又はＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）等があり、各種情報をテキストやイメージ情報として表示する。また、ポインティングデバイス１７０９とディスプレイ１７１０の両方の機能を備えているタッチスクリーン等であってもよい。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１７１１は、ハードディスク（フラッシュメモリ等であってもよい）を内蔵し、ハードディスクを駆動し、ＣＰＵ１７０１によって実行するプログラムや情報を記録又は再生させる。ハードディスクには、ハードディスクは、記録装置１３５等としての機能を実現させる。さらに、その他の各種データ、各種コンピュータ・プログラム等が格納される。

ドライブ１７１２は、装着されている磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体１７１３に記録されているデータ又はプログラムを読み出して、そのデータ又はプログラムを、インタフェース１７０７、外部バス１７０６、ブリッジ１７０５、及びホストバス１７０４を介して接続されているＲＡＭ１７０３に供給する。なお、リムーバブル記録媒体１７１３も、データ記録領域として利用可能である。

接続ポート１７１４は、外部接続機器１７１５を接続するポートであり、ＵＳＢ、ＩＥＥＥ１３９４等の接続部を持つ。接続ポート１７１４は、インタフェース１７０７、及び外部バス１７０６、ブリッジ１７０５、ホストバス１７０４等を介してＣＰＵ１７０１等に接続されている。通信部１７１６は、通信回線に接続され、外部とのデータ通信処理を実行する。データ読み取り部１７１７は、例えばスキャナであり、ドキュメントの読み取り処理を実行する。データ出力部１７１８は、例えばプリンタであり、ドキュメントデータの出力処理を実行する。

なお、図１７に示す情報処理装置のハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１７に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続している形態でもよく、さらに図１７に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。

前述の実施の形態においては、中継装置１３０とロードバランサ１４０を組み合わせる例を示したが、中継装置１３０と認可サーバ１２０を組み合わせてもよいし、さらに、中継装置１３０と認可サーバ１２０とロードバランサ１４０を組み合わせてもよい。
また、第１の実施の形態と第２の実施の形態の組み合わせ例として、予め定められた条件を満たすまで第１の実施の形態による処理を行い、予め定められた条件を満たした後は、第２の実施の形態による処理を行うようにしてもよい。ここで、予め定められた条件として、例えば、記録装置１３５が使用できるメモリ容量が予め定められたメモリ容量（例えば、記録装置１３５に使用できる最大のメモリ容量）に達すること、第１の実施の形態による処理期間が予め定められた期間に達すること等としてもよい。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラムの全体又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分又は全部であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。

１１０…クライアント
１２０…認可サーバ
１３０…中継装置
１３５…記録装置
１４０…ロードバランサ
１４５…アプリケーションサーバ
２３０…ロードバランサ
２３５…ロードバランス処理モジュール
３９０…通信回線
９２０…認可サーバ
９３０…中継装置
１０３０…ロードバランサ
１０３５…ロードバランス処理モジュール
１４２０…認可サーバ
１４３０…中継装置
１５３０…ロードバランサ
１５３２…ロードバランス処理モジュール

Claims (10)

1. クライアントから受け付けた要求に付与された第１の情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、
   前記第２の情報を削除した応答を前記クライアントに送信する送信手段
   を有する情報処理装置。
2. クライアントから受け付けた要求に付与された第１の情報を前記記憶装置から検索して、該第１の情報に対応する第２の情報を該要求に付与し、該第２の情報が付与された要求をロードバランサ手段に送信する第２の送信手段
   をさらに有する請求項１に記載の情報処理装置。
3. 認可サーバから第１の情報を受け付ける受付手段と、
   ロードバランサ手段に要求を送信する送信手段と、
   前記ロードバランサ手段から前記要求に対する応答に付与された第２の情報を受け付ける第２の受付手段と、
   前記第２の情報を前記認可サーバに送信する第２の送信手段
   を有する情報処理装置。
4. クライアントから受け付けた要求に付与された第１の情報から前記第２の情報を抽出し、該要求に付与する付与手段と、
   前記要求と前記第１の情報と前記第２の情報をロードバランサ手段に送信する第３の送信手段
   をさらに有する請求項３に記載の情報処理装置。
5. 認可サーバからユーザーに関する情報を受け付ける受付手段と、
   要求を行ったユーザーに関する情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、
   前記受付手段によって受け付けられたユーザーに関する情報に類似するユーザーに関する情報を前記記憶装置から検索し、該検索されたユーザーに関する情報に対応する第２の情報を前記認可サーバに送信する送信手段
   を有する情報処理装置。
6. 前記ユーザーに関する情報として、該ユーザーを識別するための識別情報、該ユーザーが属しているグループを識別するための識別情報、該ユーザーの役割を示す情報、該ユーザーがアクセス可能なリソースを示す情報のいずれか１つ、又はこれらの組み合わせを利用する、
   請求項５に記載の情報処理装置。
7. 前記第１の情報として、クライアントが認可サーバから取得するアクセストークンを利用し、
   前記第２の情報として、前記ロードバランサ手段が発行したクッキーを利用する、
   請求項１から４のいずれか一項に記載の情報処理装置。
8. コンピュータを、
   クライアントから受け付けた要求に付与された第１の情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、
   前記第２の情報を削除した応答を前記クライアントに送信する送信手段
   として機能させるための情報処理プログラム。
9. コンピュータを、
   認可サーバから受け付けた第１の情報を受け付ける受付手段と、
   ロードバランサ手段に要求を送信する送信手段と、
   前記ロードバランサ手段から前記要求に対する応答に付与された第２の情報を受け付ける第２の受付手段と、
   前記第２の情報を前記認可サーバに送信する第２の送信手段
   として機能させるための情報処理プログラム。
10. コンピュータを、
    認可サーバから受け付けたユーザーに関する情報を受け付ける受付手段と、
    要求を行ったユーザーに関する情報と、該要求に対してロードバランサ手段から受け付けた応答に付与された第２の情報を対応付けて記憶装置に記憶させる制御を行う記憶制御手段と、
    前記受付手段によって受け付けられたユーザーに関する情報に類似するユーザーに関する情報を前記記憶装置から検索し、該検索されたユーザーに関する情報に対応する第２の情報を前記認可サーバに送信する送信手段
    として機能させるための情報処理プログラム。

Images