JP2020067967A - 情報処理システム、情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

【課題】シングルサインオン連携を用いた情報処理システムにおいて、サービスプロバイダ側の変更によって、応答を受信するためのアドレス情報が変わった場合であっても、シングルサインオンを継続する。【解決手段】シングルサインオン連携を行うための情報処理システムであって、サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信手段と、前記サービスプロバイダの変更後のアドレスを特定する特定手段と、前記認証応答の送信元に、前記特定手段にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト手段とを有する。【選択図】 図６

Description

本発明は、情報処理システム、情報処理装置、情報処理方法、およびプログラムに関する。

近年、インターネット上に展開されるアプリケーションサービスは、サーバーやネットワーク機器をデータセンターと呼ばれる施設に集約して設置、運用するクラウド上のサーバーで動作している。アプリケーションサービスの増加に伴い、ユーザーは複数のアプリケーションサービスを利用するようになってきている。複数のアプリケーションサービスを利用する際に、ユーザーが一回の認証操作で複数のアプリケーションサービスにログインすることができるシングルサインオン機能がある。例えば、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は、異なる管理ドメインのアプリケーションサービス間でのシングルサインオンを行う標準規格の一つである。ＳＡＭＬを利用したシングルサインオンの一例として特許文献１がある。

ＳＡＭＬを利用したシングルサインオンでは、認証情報を利用するＳＰ（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と認証情報を提供するＩｄＰ（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ）があり、ＳＰとＩｄＰで予め信頼関係を結んでおく必要がある。具体的には、ＳＰの情報をＩｄＰに登録したり、ＩｄＰがＳＰ向けに鍵ペアを作成して公開鍵をＳＰに渡したりする。ＩｄＰに登録するＳＰの情報として、ＳＰがＩｄＰから認証応答を受信するためのエンドポイントであるＡＣＳ（Ａｓｓｅｒｔｉｏｎ Ｃｏｎｓｕｍｅｒ Ｓｅｒｖｉｃｅ） ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）がある。このような認証応答を受け付けるためのアドレス情報など、ＳＰとＩｄＰ間の信頼関係に関する設定は、利用ユーザーなど、ＳＰやＩｄＰの提供者とは別のユーザーが行うことが多い。

特開２０１２−１６８７９５号公報

例えば、ＳＰのＵＲＬが変更されると、認証応答であるＳＡＭＬレスポンスを受信するためのＡＣＳ ＵＲＬも変わる。しかし、ＡＣＳ ＵＲＬはＩｄＰ側に登録されているため、通常、ＳＰの提供者は変更することができない。ＩｄＰ側に登録されているＡＣＳ ＵＲＬが変更されないとＳＡＭＬレスポンスが受信できず、シングルサインオンができなくなってしまう。

そこで、本発明は、シングルサインオン連携を用いた情報処理システムにおいて、サービスプロバイダ側の変更によって、応答を受信するためのアドレス情報が変わった場合であっても、シングルサインオンを継続することを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、シングルサインオン連携を行うための情報処理システムであって、サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信手段と、前記サービスプロバイダの変更後のアドレスを特定する特定手段と、前記認証応答の送信元に、前記特定手段にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト手段とを有する。

本発明により、シングルサインオン連携を用いた情報処理システムにおいて、サービスプロバイダ側の変更によって、応答を受信するアドレス情報が変わった場合であっても、シングルサインオンの継続が可能となる。

本発明の一実施形態におけるコンピュータの構成例を示す図。 本発明の一実施形態としてのネットワーク構成の例を図。 従来例におけるＳＡＭＬシングルサインオンのシーケンス図。 テナントがＳＰを移動した場合の課題を説明するための図。 本実施形態に係る認証・認可サーバー（ＳＰ）の機能構成の例を示す図。 第１の実施形態に係るＳＡＭＬシングルサインオンのシーケンス図。 本実施形態に係るテナントの存在チェック処理のフローチャート。 第１の実施形態に係るＡＣＳ ＵＲＬ更新を含むＳＡＭＬシングルサインオンのシーケンス図。 本実施形態に係るＡＣＳ ＵＲＬ更新対象者チェック処理のフローチャート。 本実施形態に係るＡＣＳ ＵＲＬ更新の確認ダイアログの例を示す図。 第２の実施形態に係る統合エントランスサーバーを用いたＳＡＭＬシングルサインオンのシーケンス図。 第２の実施形態に係るＡＣＳ ＵＲＬに統合エントランスを指定した場合のシーケンス図。

以下、本発明を実施するための一実施形態について図面を用いて説明する。なお、以下に示す構成等は一例であり、これらに限定することを意図するものではない。

＜第１の実施形態＞
［装置構成］
図１は、本発明を実施するための一実施形態に係る情報処理装置の構成例を示す図である。図１において、情報処理装置１００は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、および通信インタフェース１０７を備える。また、情報処理装置１００内の各構成要素はシステムバス１０１を介して互いに通信可能に接続されている。

ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする。メモリ１０３は、データやプログラムを記憶する装置であり、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３がある。図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなどが使用されてもよい。

本実施形態に係るプログラムは、記憶装置１０４から読み出され、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、メモリ１０３から読み出したり、通信インタフェース１０７を介して外部から読み出したりする構成であってもよい。

ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置１００に対する動作指令等を行う。ポインティングデバイス１１６は、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。

通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。

［ネットワーク構成］
図２は、本実施形態に係る情報処理システムにおけるネットワーク構成の例を示す図である。図２に示されるクライアントおよびサーバーは、図１で示した情報処理装置１００の構成を備えているものとする。ただし、図１の構成に限定するものではなく、他の機能を備えている場合や、単体のコンピュータに限らないラックマウント型のシステムであっても構わない。また、後述の全ての説明において、特に断りのない限りサーバーやクライアントの実行の主体は各装置におけるＣＰＵ１０２であり、ソフトウェア上の主体は記憶装置１０４に保管されたアプリケーションプログラムである。

Ｗｅｂクライアント２０１、データセンター２１０、２２０、統合エントランスサーバー２３０、および認証サーバー２４０が、インターネット２００に接続されている。Ｗｅｂクライアント２０１は、Ｗｅｂブラウザの機能を搭載したクライアントである。データセンター２１０、２２０はそれぞれ異なるデータセンターを示している。データセンター２１０内のコンピュータネットワーク２１１には、リバースプロキシサーバー２１２、認証・認可サーバー２１３、リソースサーバー２１４が接続されている。また、データセンター２２０内のコンピュータネットワーク２２１には、リバースプロキシサーバー２２２、認証・認可サーバー２２３、リソースサーバー２２４が接続されている。各データセンター内のサーバーは、コンピュータネットワークを介してインターネット２００に接続されている。

データセンター２１０とデータセンター２２０には同様のサーバー構成が構築されている。リバースプロキシサーバー２１２および２２２はそれぞれ、外部からのリクエストをコンピュータネットワーク内部のサーバーに振り分ける役割を持つ。例えば、リバースプロキシサーバーは、アクセスを受け付けたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）にて示されるパス名に基づき、認証・認可サーバーもしくはリソースサーバーへの振り分けを判断する。なお、認証・認可サーバーとリソースサーバーの振り分けが不要な場合等、リバースプロキシサーバーが存在しない構成であっても構わない。リバースプロキシサーバー２１２、２２２はそれぞれ、リージョン固有の異なるサブドメインが割り当てられ、ＵＲＬのサブドメインも異なる。従って、アクセスはリージョン毎に分離されることになる。ここでのリージョンとは、物理的に離れた位置を示す。

Ｗｅｂクライアント２０１からリバースプロキシサーバー２１２へのアクセスは認証・認可サーバー２１３およびリソースサーバー２１４に振り分けられる。一方、リバースプロキシサーバー２２２へのアクセスは認証・認可サーバー２２３およびリソースサーバー２２４に振り分けられる。また、認証・認可サーバー２１３とリソースサーバー２１４のサブドメインは同じになる。同様に、認証・認可サーバー２２３とリソースサーバー２２４のサブドメインも同じになる。認証・認可サーバー２１３、２２３はそれぞれ、Ｗｅｂクライアント２０１からのリクエストに対して認証、および処理の認可を行う。リソースサーバー２１４、２２４はそれぞれ、認証・認可サーバー２１３、２２３に認可された範囲でＷｅｂアプリケーションサービスを提供する。

統合エントランスサーバー２３０は、ワールドワイドで共通のＵＲＬを受け付けるために用意されたサーバーである。統合エントランスサーバー２３０は、データセンター２１０やデータセンター２２０とは別のデータセンターに配備されてもよいし、データセンター２１０あるいはデータセンター２２０に配備されてもよい。またさらに、統合エントランスサーバー２３０を複数のデータセンターに配備し、ＧｅｏＤＮＳ（非図示）を用いて共通のＵＲＬを付与するようにしてもよい。ＧｅｏＤＮＳとはリクエストを要求しているクライアントからネットワーク的に（もしくは、物理的に）近いサーバーへ要求を転送する仕組みである。例えば、Ｗｅｂクライアント２０１が統合エントランスサーバーの共通ＵＲＬへアクセスを要求したとする。このとき、Ｗｅｂクライアント２０１の配置位置がネットワーク上におけるデータセンター２１０に近い場合はデータセンター２１０に配備された統合エントランスサーバーに要求が転送される。

認証サーバー２４０は、データセンター２１０やデータセンター２２０とは異なるドメインのクラウドサービス上に存在する。本実施形態におけるＳＡＭＬシングルサインオンの機能において、認証サーバー２４０はＩｄＰ（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ：アイデンティティプロバイダ）の役割を担う。また、認証・認可サーバー２１３および２２３はＳＰ（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ：サービスプロバイダ）の役割を担う。なお、本実施形態では、シングルサインオン連携を行うための認証としてＳＡＭＬを用いた例を示すが、これに限定するものではない。

［処理シーケンス］
図３を用いて、一般的なＳＡＭＬシングルサインオンのシーケンスについて説明を行う。なお、図３以降のシーケンス図において、図２で示したリバースプロキシサーバー２１２あるいは２２２の動作は省略して説明する。Ｗｅｂクライアント２０１から認証・認可サーバー２１３あるいは２２３に直接アクセスしているように記載するが、実際には各リバースプロキシサーバーを経由してアクセスされる。

図３（Ａ）は、ＳＰ側のサイトを起点としたＳＡＭＬシングルサインオンのシーケンス図である。

Ｓ３０１にて、Ｗｅｂクライアント２０１は、ＳＰの役割を担う認証・認可サーバー２１３に対してＩｄＰ認証でのログイン要求を行う。この際に、Ｗｅｂクライアント２０１は、ＳＰ内のターゲットリソースを指定する。ターゲットリソースは認証を受け付けるＳＰ内の対象を示し、例えば、テナントのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）等がある。

Ｓ３０２にて、ＳＰ２１３は、Ｗｅｂクライアント２０１からのログイン要求に起因して、Ｗｅｂクライアント２０１に対して認証要求であるＳＡＭＬリクエストを送信する。このときＳＡＭＬリクエストには、クエリパラメータとして、ＲｅｌａｙＳｔａｔｅが指定される。ＲｅｌａｙＳｔａｔｅの値は、Ｓ３０１で受信したログイン要求にて指定されるターゲットリソースである。

Ｓ３０３にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０へＳＡＭＬリクエストを送信する。ここでも、ＳＡＭＬリクエストには、クエリパラメータとして、Ｓ３０２にて指定されたＲｅｌａｙＳｔａｔｅが指定される。

Ｓ３０４にて、ＩｄＰ２４０は、ＳＡＭＬリクエストを受信すると、Ｗｅｂクライアント２０１にログインページを返す。

Ｓ３０５にて、Ｗｅｂクライアント２０１は、ログインページを介してユーザーによりクレデンシャル情報が入力されると、このクレデンシャル情報をＩｄＰ２４０へ送信する。クレデンシャル情報の例としては、ユーザーＩＤとパスワードの対などが挙げられる。

Ｓ３０６にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１からクレデンシャル情報を受け付けると、これを用いて認証およびログイン処理を実行する。ＩｄＰ２４０側では、クレデンシャル情報に対応付けてユーザーの管理が行われており、管理している情報と、Ｗｅｂクライアント２０１から受信した情報とに基づいて認証処理が行われる。

Ｓ３０７にて、ＩｄＰ２４０は、認証およびログイン処理の結果に基づき、認証応答であるＳＡＭＬレスポンスを作成し、Ｗｅｂクライアント２０１にＳＡＭＬレスポンスを送信する。ここでのＳＡＭＬレスポンスには、クエリパラメータとして、Ｓ３０３にてＳＡＭＬリクエストにて指定されたＲｅｌａｙＳｔａｔｅが指定される。

Ｓ３０８にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０から受信したＳＡＭＬレスポンスをＳＰ２１３へ送信する。ここでのＳＡＭＬレスポンスには、クエリパラメータとして、Ｓ３０７にてＳＡＭＬレスポンスにて指定されたＲｅｌａｙＳｔａｔｅが指定される。

Ｓ３０９にて、ＳＰ２１３は、ＳＡＭＬレスポンスを受信すると、ＳＡＭＬレスポンスにて示されるＩｄＰ側のユーザーＩＤと、ＳＰ側のユーザーＩＤとを用いてログイン処理を行う。ＩｄＰ側のユーザーＩＤとＳＰ側のユーザーＩＤのマッピングは信頼関係構築後に事前に実施されている。つまり、ＳＰ２１３は、信頼関係が構築されているＩｄＰ２４０側で正常に認証が行われていた場合には、この結果を信用し、認証対象（ここでは、Ｗｅｂクライアント２０１）からの要求を許可する。

Ｓ３１０にて、ＳＰ２１３は、ログイン処理の結果に基づき、ログイン応答をＷｅｂクライアント２０１へ返す。そして、本シーケンスを終了する。

図３（Ｂ）は、ＩｄＰ側のサイトを起点としたＳＡＭＬシングルサインオンのシーケンス図である。

Ｓ３２１にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０にログインページを要求する。

Ｓ３２２にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１からの要求に応じてログインページを返す。

Ｓ３２３にて、Ｗｅｂクライアント２０１は、ログインページを介してユーザーによりクレデンシャル情報が入力されると、このクレデンシャル情報をＩｄＰ２４０へ送信する。

Ｓ３２４にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１からクレデンシャル情報を受け付けると、これを用いて認証およびログイン処理を実行する。ＩｄＰ２４０側では、クレデンシャル情報に対応付けてユーザーの管理が行われており、管理している情報と、Ｗｅｂクライアント２０１から受信した情報とに基づいて認証処理が行われる。

Ｓ３２５にて、ＩｄＰ２４０は、認証およびログイン処理の結果に基づき、ログイン応答をＷｅｂクライアント２０１に返す。

Ｓ３２６にて、Ｗｅｂクライアント２０１は、ＳＰを選択する。例えば、Ｓ３２５で受信したログイン応答にて示されるＷｅｂページ上にＳＰサイト側の機能を選択するリンクやボタンが配置されており、それをユーザーがクリックすることにより選択が行われる。リンクやボタンにはＳＰ側のターゲットリソース情報も含まれる。

Ｓ３２７にて、ＩｄＰ２４０は、Ｓ３２６で受信した情報を元にＳＡＭＬリクエストを作成して自身のエンドポイントに対するリダイレクトを行わせるためのリダイレクト応答を返す。

Ｓ３２８にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０からのリダイレクト応答に基づき、ＩｄＰ２４０のエンドポイントへリダイレクトする。ここで、ＩｄＰ２４０は既にログインしているユーザーからの要求であることを判別して、ＳＡＭＬレスポンスを作成する。ユーザーのログイン状態の判別には、例えばｃｏｏｋｉｅを利用する方法等があるがこれに限定するものではない。

Ｓ３２９にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１にＳＡＭＬレスポンスを送信する。ここでのＳＡＭＬレスポンスには、Ｓ３２６にて指定されたターゲットリソース情報がＲｅｌａｙＳｔａｔｅの値として指定される。

Ｓ３３０にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０からＳＡＭＬレスポンスを受信したことに応じて、ＳＡＭＬレスポンスをＳＰ２１３へ送信する。ここでのＳＡＭＬレスポンスには、Ｓ３２９にて指定されたターゲットリソース情報がＲｅｌａｙＳｔａｔｅの値として指定される。

Ｓ３３１にて、ＳＰ２１３は、ＳＡＭＬレスポンスを受信すると、ＳＡＭＬレスポンスにて示されるＩｄＰ側のユーザーＩＤと、ＳＰ側のユーザーＩＤとを用いてログイン処理を行う。

Ｓ３３２にて、ＳＰ２１３は、ログイン処理の結果に基づき、ログイン応答をＷｅｂクライアント２０１へ返す。そして、本シーケンスを終了する。なお、図３（Ａ）、図３（Ｂ）で示したどちらのケースも、ＩｄＰ２４０がＳＡＭＬレスポンスを送信した後の流れは同様となる。

［本実施形態に係る課題の詳細］
図４は、本実施形態に係るテナントがＳＰを移動した場合を説明するための図である。例えば、ある利用ユーザーに近い場所に新しくデータセンターが開設されたような場合、ユーザーのネットワーク上の利便性を考慮してテナントごとデータセンターを移動する場合がある。テナントの移動では、ユーザー情報を含めテナントに関係する情報がコピーされる。ＳＡＭＬのシングルサインオンで利用されるＩｄＰの情報もコピーされる。図４において、ＳｒｃＳＰは移動元のＳＰを示し、ＤｅｓｔＳＰは移動先のＳＰを示している。図２に対応付けて説明すると、ＳｒｃＳＰが認証・認可サーバー２１３で、ＤｅｓｔＳＰが認証・認可サーバー２２３のような構成となる。また、ＩｄＰも図２に対応付けて説明すると認証サーバー２４０、ユーザー４０１はＷｅｂクライアント２０１を操作するユーザーとなる。

ここで、図３（Ａ）で示したシングルサインオンを、移動先のＤｅｓｔＳＰ２２３で実行する場合について説明する。ユーザー４０１は、ＩｄＰ認証でのログイン要求をＤｅｓｔＳＰ２２３に対して行う（Ｓ４１１）。ＤｅｓｔＳＰ２２３は、ユーザー４０１からのログイン要求に起因して、ＩｄＰ２４０に向けてＳＡＭＬリクエストを送信する（Ｓ４１２）。ＩｄＰ２４０は、ユーザー４０１に対してクレデンシャル情報を要求し、入力されたクレデンシャル情報を用いて認証を行ってログイン処理を実行する（Ｓ４１３）。更に、ＩｄＰ２４０は、ログイン処理の結果に基づきＳＡＭＬレスポンスを作成する。ここで、ＩｄＰ２４０は、予め設定されたＳｒｃＳＰ２１３のＡＣＳ（Ａｓｓｅｒｔｉｏｎ Ｃｏｎｓｕｍｅｒ Ｓｅｒｖｉｃｅ） ＵＲＬに向けてＳＡＭＬレスポンスを送付することになる（Ｓ４１４）。つまり、通信応答（ＳＡＭＬレスポンス）の通信先が変更前のアドレスとなり、正しい送信先でない状態となる。ＩｄＰへのＡＣＳ ＵＲＬの設定は、通常、利用ユーザーが行う。従って、ＳＰを提供する事業者等はＳＰ内のテナント情報は移動できるが、ＩｄＰの情報を変更することはできない。そのため、テナント情報を移動させただけでは、ＳＡＭＬリクエストの送信元であるＤｅｓｔＳＰ（変更後のアドレスのサービスプロバイダ）にはＳＡＭＬレスポンスが返らないこととなる。結果として、移動元のＳｒｃＳＰ２１３でテナントが存在しないためにエラーとなってしまう。

なお、図４ではデータセンターを移動する例を示したが、テナントの移動を伴わずにアドレス情報（例えば、ＵＲＬ）が変更されるようなケースでも同様の問題が発生する。

［シングルサインオン］
次に、本実施形態に係るシングルサインオンの機能について説明する。

図５は、本実施形態に係るＳＰの役割を担う認証・認可サーバー２１３および２２３の機能ブロックの構成例を示す図である。ユーザー管理部５０１は、認証・認可サーバーで認証・認可されるユーザーの情報を管理する。認証部５０２は、ユーザー管理部５０１で管理される情報に基づいて、ユーザーの認証を行う。テナント管理部５０３は、テナントの管理を行う。テナントは、主にクラウドサービスでリソースを共有する単位、境界として定義されるものであり、例えば利用する企業単位に作成される。なお、ここでの単位は、契約に基づいて設定され、１の企業が複数のテナントを用いてもよい。グローバルテナントロケーション管理部５０４は、例えば、図２で示したような複数のデータセンターを横断して、テナントがどのデータセンターに存在しているかを管理している。グローバルテナントロケーション管理部５０４は、データセンター間や統合エントランスサーバー２３０と同期して各種情報が管理されている。したがって、グローバルテナントロケーション管理部５０４は、外部装置と連携して、外部に位置するテナントに関する情報を適時更新、管理する。

ＳＡＭＬ ＩｄＰ情報管理部５０５は、ＩｄＰと信頼関係を構築するための情報を管理する。ここではＩｄＰのエンドポイントを含むメタデータやＩｄＰが発行した公開鍵が管理されており、これらはＳＡＭＬリクエストの作成やＳＡＭＬレスポンスの検証で利用される。ＳＡＭＬリクエスト作成部５０６は、ＩｄＰへ送信するＳＡＭＬリクエストを作成する。ＳＡＭＬレスポンス検証部５０７は、ＩｄＰから受信したＳＡＭＬレスポンスを検証する。ユーザーマッピング管理部５０８は、自サーバー（ＳＰ）内で管理されているユーザーと、ＩｄＰで管理されているユーザーのマッピング情報を管理する。マッピング情報は、ユーザーの対応関係を示す情報である。

図６は、本発明の一実施形態としてのＳＡＭＬシングルサインオンのシーケンス図である。本シーケンスは、図３（Ａ）にて示したＳＰに起因するシーケンスに対応する。図４で示したように移動元のＳｒｃＳＰを認証・認可サーバー２１３、移動先のＤｅｓｔＳＰを認証・認可サーバー２２３として説明する。

Ｓ６０１にて、Ｗｅｂクライアント２０１は、ＤｅｓｔＳＰ２２３に対してＩｄＰ認証でのログイン要求を行う。このとき、ＳＰ内のターゲットリソースとしてテナントＩＤが指定される。テナントＩＤは、属するテナントを一意に示すための識別情報（ＩＤ）である。

Ｓ６０２にて、ＤｅｓｔＳＰ２２３は、Ｗｅｂクライアント２０１からのログイン要求に対応して、Ｗｅｂクライアント２０１にＳＡＭＬリクエストを送信するためのＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ページを返す。より具体的には、ＤｅｓｔＳＰ２２３は、ＩｄＰの役割を担う認証サーバー２４０のＩｄＰエンドポイントに対してｆｏｒｍを使ってＰＯＳＴリクエストを送信するＨＴＭＬページをＷｅｂクライアント２０１に返す。ｆｏｒｍのパラメータには、ＳＡＭＬリクエストを示すＳＡＭＬＲｅｑｕｅｓｔ、およびＲｅｌａｙＳｔａｔｅが設定される。ＲｅｌａｙＳｔａｔｅの値は、Ｓ６０１で受信したログイン要求にて指定されるターゲットリソース（ここでは、テナントＩＤ）である。

Ｓ６０３にて、Ｗｅｂクライアント２０１は、ＤｅｓｔＳＰ２２３から受信したＨＴＭＬページをロードすることにより、ｆｏｒｍによるＰＯＳＴリクエストの送信がＩｄＰ２４０に対して実行される。ここでのＳＡＭＬリクエストには、Ｓ６０２にて指定されたターゲットリソース情報がＲｅｌａｙＳｔａｔｅの値として指定される。

Ｓ６０４にて、ＩｄＰ２４０は、ＳＡＭＬリクエストを受信すると、これに応答してＷｅｂクライアント２０１にログインページを返す。

Ｓ６０５にて、Ｗｅｂクライアント２０１は、ログインページを介してユーザーによりクレデンシャル情報が入力されると、このクレデンシャル情報をＩｄＰ２４０へ送信する。クレデンシャル情報の例としては、ユーザーＩＤとパスワードなどが挙げられる。

Ｓ６０６にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１からクレデンシャル情報を受け付けると、これを用いて認証およびログイン処理を実行する。ＩｄＰ２４０側では、クレデンシャル情報に対応付けてユーザーの管理が行われており、管理している情報と、Ｗｅｂクライアント２０１から受信した情報とに基づいて認証処理が行われる。

Ｓ６０７にて、ＩｄＰ２４０は、認証およびログイン処理の結果に基づきＳＡＭＬレスポンスを作成し、Ｗｅｂクライアント２０１にＳＡＭＬレスポンスを送信するためのＨＴＭＬページを返す。より具体的には、ＩｄＰ２４０は、ＡＣＳ ＵＲＬに対してｆｏｒｍを使ってＰＯＳＴリクエストを送信するＨＴＭＬページを返す。ｆｏｒｍのパラメータには、ＳＡＭＬレスポンスを示すＳＡＭＬＲｅｓｐｏｎｓｅおよびＲｅｌａｙＳｔａｔｅが設定される。ＲｅｌａｙＳｔａｔｅは、Ｓ６０３で受信した値がそのまま設定される。

Ｓ６０８にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０から受信したＨＴＭＬページをロードすることにより、ｆｏｒｍによるＰＯＳＴリクエストの送信がＳｒｃＳＰ２１３に対して実行される。ＡＣＳ ＵＲＬは移動元ＳＰのＵＲＬが設定されているため、送信先はＳｒｃＳＰ２１３となる。ここでのＳＡＭＬレスポンスには、Ｓ６０７にて受信したＲｅｌａｙＳｔａｔｅの値がそのまま設定される。

Ｓ６０９にて、ＳｒｃＳＰ２１３は、ＳＡＭＬレスポンスを受信したことに応じて、テナントの存在チェックを行う。Ｓ６０９の詳細は図７を用いて後述するが、ここではデータセンター内にテナントが存在するか否かを確認し、存在しない場合は他のデータセンター内に存在するか否かを確認する。つまり、ＳＡＭＬレスポンスに対応するテナントの位置を特定する。

ＤｅｓｔＳＰ２２３にテナントが存在する場合、Ｓ６１０にて、ＳｒｃＳＰ２１３は、ＤｅｓｔＳＰ２２３のＡＣＳ ＵＲＬを取得し、Ｗｅｂクライアント２０１に転送するように指定して返す。このときのＨＴＴＰステータスは“３０８”あるいは“３０７”を用いる。ＨＴＴＰステータスコード”３０７”は、一時的リダイレクトを示し、この場合、ヘッダに移動先のＵＲＬが示される。また、ＨＴＴＰステータスコード”３０８”は恒久的リダイレクトを示す。

Ｓ６１１にて、Ｗｅｂクライアント２０１は、ＳｒｃＳＰ２１３から受信したＳＡＭＬレスポンスをＤｅｓｔＳＰ２２３へリダイレクトする。ここでのＳＡＭＬレスポンスには、Ｓ６０７にて受信したＲｅｌａｙＳｔａｔｅの値がそのまま設定される。

Ｓ６１２にて、ＤｅｓｔＳＰ２２３は、Ｗｅｂクライアント２０１から受信したＳＡＭＬレスポンスにて示されるＩｄＰ側のユーザーＩＤと、ＳＰ側のユーザーＩＤとを用いてログイン処理を行う。

Ｓ６１３にてＤｅｓｔＳＰ２２３は、ログイン処理の結果に基づき、ログイン応答をＷｅｂクライアント２０１へ返す。そして、本シーケンスを終了する。

（テナントの存在チェック処理）
図７は、図６のＳ６０９で示したテナントの存在チェックのフローチャートである。本処理フローは、例えば、ＳｒｃＳＰ２１３が備えるＣＰＵ１０２が記憶装置１０４に保持されたプログラムを読み出して実行することにより実現される。

Ｓ７０１にて、ＳｒｃＳＰ２１３は、Ｗｅｂクライアント２０１から受信したＳＡＭＬレスポンスにて示されるＲｅｌａｙＳｔａｔｅに設定されたテナントＩＤを取得する。なお、テナントＩＤは全データセンターで一意に識別できるようになっている。

Ｓ７０２にて、ＳｒｃＳＰ２１３は、自データセンター内に、ＲｅｌａｙＳｔａｔｅに設定されたテナントＩＤに対応するテナントが存在するか否かの確認を行う。ここでの確認は、ユーザー管理部５０１やテナント管理部５０３等にて管理している情報に基づいて行われる。自データセンターにテナントが存在した場合は（Ｓ７０２にてＹＥＳ）Ｓ７０３へ進み、存在しない場合は（Ｓ７０２にてＮＯ）Ｓ７０４へ進む。

Ｓ７０３にて、ＳｒｃＳＰ２１３は、自データセンター内のテナントに対し、マッピングされたユーザーでログイン処理を行う。そして、本処理フローを終了し、図６のＳ６１０の処理へ進む。

Ｓ７０４にて、ＳｒｃＳＰ２１３は、他のデータセンターに、ＲｅｌａｙＳｔａｔｅに設定されたテナントが存在するか否かを確認する。この確認処理はグローバルテナントロケーション管理部５０４で実施される。他データセンターにテナントが存在する場合は（Ｓ７０４にてＹＥＳ）Ｓ７０５へ進み、存在しない場合は（Ｓ７０４にてＮＯ）Ｓ７０６へ進む。

Ｓ７０５にて、ＳｒｃＳＰ２１３は、テナントが存在するデータセンターへリダイレクトするように処理を行う。ここでの処理の結果、図６のＳ６１０の処理において、リダイレクト先がレスポンスとして返される。そして、本処理フローを終了する。

Ｓ７０６にて、ＳｒｃＳＰ２１３は、ＲｅｌａｙＳｔａｔｅに設定されたテナントが他データセンターにも存在しないものとして、エラー処理を行う。ここでの処理の結果、図６のＳ６１０の処理において、エラーがレスポンスとして返される。そして、本処理フローを終了する。

以上、本実施形態により、ＳＰ側の変更が行われ、認証応答を受信するエンドポイントのＵＲＬが変わった場合であっても、シングルサインオンができるようになる。

［ＡＣＳ ＵＲＬの更新を含むシングルサインオン］
次に、本実施形態に係るＡＣＳ ＵＲＬ更新を含むシングルサインオンの機能について説明する。図６を用いて述べた方法により、移動元サイトから移動先サイトへ転送することでシングルサインオンができる。一方、移動元のサイトあるいはＵＲＬが今後も稼動し続けるとは限らない。また、移動後もシングルサインオンができるようになったことで、利用者がＡＣＳ ＵＲＬ変更の必要性を認識しづらくなることも考えられる。従って、できるだけ速やかにＡＣＳ ＵＲＬを変更する必要がある。そこで、本実施形態では以下のシーケンスを用いる。

図８は、本実施形態に係るＡＣＳ ＵＲＬ更新を含むシングルサインオンのシーケンス図である。Ｓ６０１からＳ６０９までの流れは図６と同じであるため説明を省略する。

Ｓ６０９にてＤｅｓｔＳＰ２２３にテナントが存在すると判定された場合、Ｓ８１０にて、ＳｒｃＳＰ２１３は、ＤｅｓｔＳＰ２２３のＡＣＳ ＵＲＬを取得し、Ｗｅｂクライアント２０１に対して、そのＡＣＳ ＵＲＬへ転送するように指定して返す。このとき、転送するＡＣＳ ＵＲＬにクエリパラメータが設定される。例えば、本例のように転送元がＳｒｃＳＰ２１３の場合、ｆｒｏｍ＝ｓｒｃｓｐのように転送元のデータセンターがわかるような情報が設定される。

Ｓ８１１にて、Ｗｅｂクライアント２０１は、ＳｒｃＳＰ２１３から受信したＡＣＳ ＵＲＬに基づいて、ＳＡＭＬレスポンスをＤｅｓｔＳＰ２２３へリダイレクトする。ここでのＳＡＭＬレスポンスには、Ｓ６０７にて受信したＲｅｌａｙＳｔａｔｅの値がそのまま設定される。

Ｓ８１２にて、ＤｅｓｔＳＰ２２３は、受信したＳＡＭＬレスポンスにて示されるＩｄＰ側のユーザーＩＤと、ＳＰ側のユーザーＩＤとを用いてログイン処理を行う。

Ｓ８１３にて、ＤｅｓｔＳＰ２２３は、Ｓ８１１で受信したクエリパラメータをチェックし、他のデータセンターから転送されたか否かを判別する。転送されている場合は、更に、ＤｅｓｔＳＰ２２３は、ＳＡＭＬレスポンスを送信したＷｅｂクライアント２０１がＩｄＰ側のＡＣＳ ＵＲＬを変更できるユーザーか否かのチェックを行う。チェック処理の詳細は図９を用いて後述する。ＳＡＭＬレスポンスを送信したＷｅｂクライアント２０１がＡＣＳ ＵＲＬを変更できるユーザーである場合は、Ｓ８１４〜Ｓ８２３の処理にてＯＡｕｔｈによるユーザーからの権限委譲を受けてユーザーの代わりにＡＣＳ ＵＲＬの変更を行う。

Ｓ８１４にて、ＤｅｓｔＳＰ２２３は、ＩｄＰに対する認可リクエストをＷｅｂクライアント２０１へ送信する。

Ｓ８１５にて、Ｗｅｂクライアント２０１は、ＤｅｓｔＳＰ２２３から認可リクエストを受け付けたことに応じて、認可リクエストをＩｄＰ２４０へ送信する。

Ｓ８１６にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１から認可リクエストを受け付けたことに応じて、ＡＣＳ ＵＲＬ変更のための認可確認ページをＷｅｂクライアント２０１へ送信する。

Ｓ８１７にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０から受信した認可確認ページを表示し、これを介してユーザーから認可の指示（承諾）を受け付けたことに応じて、認可結果をＩｄＰ２４０へ送信する。

Ｓ８１８にて、ＩｄＰ２４０は、Ｗｅｂクライアント２０１から受け付けた認可結果に基づいて認可コードを発行し、ＤｅｓｔＳＰ２２３のエンドポイントに対して認可コードを送信するためのページをＷｅｂクライアント２０１へ送信する。

Ｓ８１９にて、Ｗｅｂクライアント２０１は、ＩｄＰ２４０から受け付けたページに基づき、認可コードをＤｅｓｔＳＰ２２３へ送信する。なお、認可コードを受信するＤｅｓｔＳＰ２２３のエンドポイントは、ＡＣＳ ＵＲＬと同様にＩｄＰ２４０に予め登録されている。

Ｓ８２０にて、ＤｅｓｔＳＰ２２３は、Ｗｅｂクライアント２０１から受信した認可コードを使って、直接ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ：不図示）によりＩｄＰ２４０に認可トークンの取得を要求する。ここでの要求方法は、公知の方法を用いるものとし、ここでの詳細な説明は省略する。

Ｓ８２１にて、ＩｄＰ２４０は、ＤｅｓｔＳＰ２２３からの要求に応じて認可トークンを発行し、ＤｅｓｔＳＰ２２３へ返す。

Ｓ８２２にて、ＤｅｓｔＳＰ２２３は、ＩｄＰ２４０から受信した認可トークンを使って、ＡＰＩでＩｄＰ２４０にＡＣＳ ＵＲＬの変更を要求する。

Ｓ８２３にて、ＩｄＰ２４０は、認可トークンに基づくＤｅｓｔＳＰ２２３からのＡＣＳ ＵＲＬの変更の要求に基づき、ＡＣＳ ＵＲＬの変更を行う。更に、ＩｄＰ２４０は、変更処理の結果をＤｅｓｔＳＰ２２３へ返す。

Ｓ８２４にて、ＤｅｓｔＳＰ２２３は、変更処理の結果をＩｄＰ２４０から受信すると、本処理シーケンスのＳ６０１にて行われたログイン要求に対するログイン応答をＷｅｂクライアント２０１へ返す。そして、本処理シーケンスを終了する。

（ＡＣＳ ＵＲＬ更新対象者チェック処理）
図９は、図８のＳ８１３で示したＡＣＳ ＵＲＬ更新対象者チェックフローチャートである。本処理フローは、例えば、ＤｅｓｔＳＰ２２３が備えるＣＰＵ１０２が記憶装置１０４に保持されたプログラムを読み出して実行することにより実現される。

Ｓ９０１にて、ＤｅｓｔＳＰ２２３は、図８のＳ８１１で受信したＳＡＭＬレスポンスにて示されるクエリパラメータを取得する。

Ｓ９０２にて、ＤｅｓｔＳＰ２２３は、ＳＡＭＬレスポンスが他のデータセンターからリダイレクトされたものか否かを判定する。ここでは、ＳＡＭＬレスポンスにクエリパラメータが設定されていれば、他のデータセンターからリダイレクトされたものとして判定し、設定されていなければリダイレクトされずにＩｄＰ２４０からＳＡＭＬレスポンスを受信したと判定する。リダイレクトされたと判定した場合は（Ｓ９０２にてＹＥＳ）Ｓ９０３へ進み、そうでないと判定した場合は（Ｓ９０２にてＮＯ）本処理フローを終了する。

Ｓ９０３にて、ＤｅｓｔＳＰ２２３は、ログインユーザーが管理者権限を有するユーザーか否かを判定する。ＳＰ側で管理しているユーザーには、管理者と一般者の区別が設けられており、ＳＰのユーザー管理部５０１ではユーザーごとにその属性を保管している。ＳＰ側でＩｄＰに関する設定をできるのは管理者だけであり、管理者権限のあるユーザーか否かを判定することでＡＣＳ ＵＲＬを変更できるユーザーの絞込みを行う。ただし、これは、ＳＡＭＬの信頼関係構築の設定はＩｄＰ側もＳＰ側も同ユーザーが実施するという推測の元に行われるものであり、ＳＰ側のユーザーとして管理者であるからといって、ＩｄＰ側のＡＣＳ ＵＲＬを変更できるとは限らない。従って、Ｓ９０３の処理を行わない実装であってもよい。管理者権限を有するユーザーであると判定された場合は（Ｓ９０３にてＹＥＳ）Ｓ９０４へ進み、そうでないと判定された場合は（９０３にてＮＯ）本処理フローを終了する。

Ｓ９０４にて、ＤｅｓｔＳＰ２２３は、ＡＣＳ ＵＲＬを更新するか否かの確認ダイアログを操作者に対して表示する。確認ダイアログの詳細は図１０を用いて後述する。ここでの操作者とは、例えば、Ｗｅｂクライアント２０１のユーザーが該当する。

Ｓ９０５にて、ＤｅｓｔＳＰ２２３は、確認ダイアログを介して操作者がＡＣＳ ＵＲＬの更新を承諾したか否かを判定する。承諾された場合は（Ｓ９０５にてＹＥＳ）Ｓ９０６へ進み、承諾されなかった場合は（Ｓ９０５にてＮＯ）本処理フローを終了する。

Ｓ９０６にて、ＤｅｓｔＳＰ２２３は、Ｗｅｂクライアント２０１を介してＩｄＰ２４０へ認可リクエストを送信させる（図８のＳ８１４〜Ｓ８１５）。そして、本処理フローを終了する。

（確認ダイアログ）
図１０は、図９のＳ９０４で表示される、ＡＣＳ ＵＲＬ更新の確認ダイアログの構成例を示す図である。確認ダイアログ１０００において、ＡＣＳ ＵＲＬを変更する必要があることと、更新を行うかどうかを操作者に確認している。なお、図１０に示すメッセージは一例であり、これに限定するものではない。はいボタン１００１が押下されると、ＡＣＳ ＵＲＬの変更を了承する指示を行う。いいえボタン１００２が押下されると、ＡＣＳ ＵＲＬの変更を却下（承諾しない）する指示を行う。

以上、本実施形態により、ＳＰ側の変更が行われ、認証応答を受信するエンドポイントのＵＲＬが変わった場合であっても、シングルサインオンができるようになり、ＡＣＳ ＵＲＬの更新も促進されるようになる。

＜第２の実施形態＞
第１の実施形態では、図２に示す統合エントランスサーバー２３０を利用しない例を述べたが、統合エントランスサーバー２３０を利用した実施形態について説明する。統合エントランスサーバー２３０はワールドワイドで共通のＵＲＬを受け付けるために用意されたサーバーである。

［処理シーケンス］
図１１は、統合エントランスを利用する場合のシングルサインオンのシーケンス図である。ここでは、第１の実施形態にて述べた図３（Ａ）の処理フローに、統合エントランスサーバー２３０が加わっている。

Ｓ１１０１にて、Ｗｅｂクライアント２０１は、統合エントランスサーバー２３０に対してＩｄＰ認証でのログイン要求を行う。ここで指定されるＵＲＬは、データセンターに依存しない（つまり、データセンターの位置に依存しない）ワールドワイドで共通のＵＲＬとなる。

Ｓ１１０２にて、統合エントランスサーバー２３０は、Ｗｅｂクライアント２０１からのログイン要求にてターゲットリソースとして指定されたテナントＩＤに基づいて、テナントの存在チェックを行う。ここでのテナント存在のチェック方法は、第１の実施形態にて図７のＳ７０４等で説明した内容と同じである。

Ｓ１１０３にて、統合エントランスサーバー２３０は、テナントが存在するデータセンターへリダイレクトするように、Ｗｅｂクライアント２０１に対して応答する。この後のシーケンスに関しては、第１の実施形態にて図３（Ａ）で示した通りとなる。

図１２は、ＡＣＳ ＵＲＬに統合エントランスを指定した場合のシーケンス図である。図６および図１１で説明した内容との差異のみを説明し、同じ処理については同じ参照番号を付している。ここでは、ＩｄＰ２４０に予め設定されたＡＣＳ ＵＲＬが統合エントランスサーバー２３０のＵＲＬとなっている。そのため、Ｓ６０７でＩｄＰ２４０にて指定されるエンドポイントが統合エントランスサーバー２３０となり、Ｓ６０８でＷｅｂクライアント２０１から統合エントランスサーバー２３０にＳＡＭＬレスポンスが送信される。

Ｓ１２０１にて、統合エントランスサーバー２３０は、Ｓ１１０２と同じように、Ｓ６０８で受信したＲｅｌａｙＳｔａｔｅの値（テナントＩＤ）からテナントが存在するデータセンターを判定する。そして、Ｓ６１０にて、統合エントランスサーバー２３０は、データセンターのエンドポイントを取得し、Ｗｅｂクライアント２０１に転送するように指定して返す。

以上、本実施形態では、予め統合エントランスサーバーのＵＲＬを使うことで、テナントが移動した場合でもＡＣＳ ＵＲＬが変更されないため、継続してシングルサインオンができるようになる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

２００…インターネット、２０１…Ｗｅｂクライアント、２１０、２２０…データセンター、２３０…統合エントランスサーバー、２４０…認証サーバー（ＩｄＰ）、２１２、２２２…リバースプロキシサーバー、２１３、２２３…認証・認可サーバー（ＳＰ）、２１４、２２４…リソースサーバー

Claims (12)

1. シングルサインオン連携を行うための情報処理システムであって、
   サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信手段と、
   前記サービスプロバイダの変更後のアドレスを特定する特定手段と、
   前記認証応答の送信元に、前記特定手段にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト手段と
   を有することを特徴とする情報処理システム。
2. 前記認証応答は、アドレスが変更された後のサービスプロバイダから発行された認証要求に対応する認証応答であり、
   前記認証応答は、アイデンティティプロバイダに設定されている前記サービスプロバイダの変更前のアドレスに基づいて送信されていることを特徴とする請求項１に記載の情報処理システム。
3. 前記認証応答を受信した際に、当該認証応答が前記リダイレクトにより行われたものか否かを判定する判定手段と、
   前記判定手段にて前記認証応答が前記リダイレクトにより行われたものであると判定された場合、前記アイデンティティプロバイダに設定されている前記サービスプロバイダのアドレスの変更の要求を行う要求手段と
   を更に有することを特徴とする請求項２に記載の情報処理システム。
4. 前記判定手段にて前記認証応答が前記リダイレクトにより行われたものであると判定された場合、前記アイデンティティプロバイダに設定されている前記サービスプロバイダのアドレスの変更を行うか否かの指示を受け付ける受け付け手段を更に有し、
   前記要求手段は、前記受け付け手段にて前記アイデンティティプロバイダに設定されているアドレスの変更を行うとの指示を受け付けた場合、前記アイデンティティプロバイダに設定されているアドレスの変更の要求を行う要求手段と
   を更に有することを特徴とする請求項３に記載の情報処理システム。
5. 前記リダイレクト手段は、前記リダイレクトの指示を行う際に、前記リダイレクトが行われる認証応答に前記リダイレクトが行われたことを示す情報を含ませ、
   前記判定手段は、前記情報に基づいて、前記認証応答がリダイレクトにより行われたものか否かを判定することを特徴とする請求項３または４に記載の情報処理システム。
6. 前記受信手段、前記特定手段、および、前記リダイレクト手段は、前記変更前のアドレスに対応するサービスプロバイダとして機能する情報処理装置が有し、
   前記判定手段、および、前記要求手段は、前記変更後のアドレスに対応するサービスプロバイダとして機能する情報処理装置が有する
   ことを特徴とする請求項３乃至５のいずれか一項に記載の情報処理システム。
7. 前記アイデンティティプロバイダに設定されるサービスプロバイダのアドレスは、当該サービスプロバイダが前記アイデンティティプロバイダから応答を受け付けるＡＣＳ（Ａｓｓｅｒｔｉｏｎ Ｃｏｎｓｕｍｅｒ Ｓｅｒｖｉｃｅ） ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であることを特徴とする請求項３乃至６のいずれか一項に記載の情報処理システム。
8. クライアントからサービスプロバイダに対する要求を受け付ける手段と、
   前記クライアントの位置に応じて、前記クライアントに、複数のサービスプロバイダのうちのいずれかへ前記要求のリダイレクトを指示する手段と
   を更に有することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理システム。
9. 前記シングルサインオン連携は、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いることを特徴とする請求項１乃至８のいずれか一項に記載の情報処理システム。
10. シングルサインオン連携を行うための情報処理システムに含まれる情報処理装置であって、
    サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信手段と、
    前記サービスプロバイダの変更後のアドレスを特定する特定手段と、
    前記認証応答の送信元に、前記特定手段にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト手段と
    を有することを特徴とする情報処理装置。
11. シングルサインオン連携を行うための情報処理方法であって、
    サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信工程と、
    前記サービスプロバイダの変更後のアドレスを特定する特定工程と、
    前記認証応答の送信元に、前記特定工程にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト工程と
    を有することを特徴とする情報処理方法。
12. シングルサインオン連携を行うための情報処理システムに含まれるコンピュータを、
    サービスプロバイダのアドレスが変更になった後に、前記サービスプロバイダの変更前のアドレスに対して送信された認証応答を受信する受信手段、
    前記サービスプロバイダの変更後のアドレスを特定する特定手段、
    前記認証応答の送信元に、前記特定手段にて特定された変更後のアドレスに対する前記認証応答のリダイレクトを指示するリダイレクト手段
    として機能させるためのプログラム。

Images