JP6949688B2 - システムおよびその制御方法 - Google Patents

Description

本発明は、クラウド認証サービスを有するシステムおよびその制御方法に関する。

近年、インターネット上に展開されたクラウドサービスの利用が拡大している。クラウドサービスでは、サーバーやネットワーク機器などのＩＴ機器をデータセンターと呼ばれる施設に集約して設置、運用し、利用者にＷｅｂアプリケーションサービスを提供している。データセンターは国や地域ごとに設置されており、ワールドワイドにサービスを提供する企業は必要に応じて複数のデータセンターに同種のサービスを配備している。利用者がアクセスするデータセンターは、利用者の物理的な地域や法制度あるいは業務内容に応じて決められる。

一方、配備されるＷｅｂアプリケーションに目を向けると、ＷｅｂアプリケーションはＨＴＴＰプロトコルを使ってＷｅｂサーバーとＷｅｂクライアントが通信しているが、ＨＴＴＰプロトコルは一回の通信で処理が完結する、いわゆるステートレスなプロトコルである。よって、複数の通信によって成り立つ業務フローで必要な利用者の状態を保持できない。そこで、状態を保持する技術として、ＨＴＴＰ ｃｏｏｋｉｅ（以下、ｃｏｏｋｉｅと称する）が使われるようになった。ｃｏｏｋｉｅは、ＷｅｂサーバーとＷｅｂブラウザ間で状態を管理するための通信プロトコルで、Ｗｅｂブラウザがクライアントに保存するＷｅｂサーバーとの通信に関する情報のことを指す。ｃｏｏｋｉｅはＷｅｂサーバーの構成や、クライアント側の利用方法に応じて適切に管理する必要がある。クライアント側におけるｃｏｏｋｉｅ管理の方法として特許文献１がある。

前述のように、ワールドワイドにサービスを提供する場合には、利用者の物理的な地域や法制度に応じて利用者がアクセスするデータセンターを決定する。だが、データセンターが異なるということはデータセンターに配備されたサービスサイトにアクセスするためのＵＲＬが異なることでもある。そこで、利用者が共通のＵＲＬでサービスにアクセスするための統合エントランスサイトを設けることがある。

この統合エントランスサイトでは、利用者からの要求に応じて利用者が利用しているデータセンター上のサービスへ転送する役目を果たす。また、統合エントランスサイトと各データセンターに配備されたエントランスサイトは個々に存在しており、どちらのエントランスサイトからアクセスするのかはユーザーの利用方法によって使い分けることになる。例えば、Ｗｅｂブラウザにアクセスするページのブックマークを設定したような場合には、各データセンターのサイトに依存したＵＲＬがブックマークとして設定されることがある。ブックマークを選択すると各データセンターのエントランスサイトに遷移し、アクセスすることになる。

特開２０１５−５１３４号公報

統合エントランスサイトと各データセンターのエントランスサイトが共存することになるため、認証に関する処理フローの中で、どちらに遷移するべきなのかを状況に応じて適宜判断する必要性が生じることになる。本願発明の目的は、ＷｅｂブラウザのＣｏｏｋｉｅ情報を基に、システムにおけるＷｅｂブラウザの遷移を制御することで、課題を解決することを目的とする。

課題を解決するための本願発明の一実施例に係るシステムは、各リージョンに配備された複数の認証サーバーと、ログインページを提供する統合エントランスサーバーと、Ｗｅｂブラウザを有するクライアントとを含むシステムであって、前記統合エントランスサーバーは、前記Ｗｅｂブラウザから前記ログインページを介してユーザーにより入力されたユーザー情報を受信したことに応じて、前記ユーザー情報を基に前記ユーザーが所属するリージョンを特定する特定手段と、前記特定手段により特定されたリージョンに関する情報を前記Ｗｅｂブラウザへ送信する送信手段と、を有し、前記クライアントは、前記送信手段により送信された情報を基に、各リージョンに配備された複数の認証サーバーの内、１つの認証サーバーへアクセスするアクセス手段を有し、前記アクセス手段によるアクセスを受けた前記認証サーバーは、前記アクセス手段によるアクセスに伴い受信した前記ユーザー情報を基に、前記ユーザーの認証を行う認証手段と、前記認証手段により前記ユーザーが認証されたことに応じて、前記ＷｅｂブラウザのＣｏｏｋｉｅ情報に対してログインされたことを示す認証トークンおよび前記統合エントランスサーバーを経由してログインされたことを示す識別情報を設定する設定手段と、を有し、前記ＷｅｂブラウザのＣｏｏｋｉｅ情報を基に、前記システムにおける前記Ｗｅｂブラウザの遷移を制御することを特徴とする。

統合エントランスサイトと各データセンターのエントランスサイトが共存する場合でも、認証に関する処理フローの中で、適切な遷移が可能となる。

本発明の一実施形態におけるコンピュータの構成内容を示す図 本発明の一実施形態としてのネットワーク構成図 認証・認可サーバーの機能ブロック図 ログインシーケンス図 ログイン状態下でのサーバーへのアクセスシーケンス図 統合エントランスサーバーの機能ブロック図 本発明の一実施形態としての統合ログインシーケンス図 ログイン処理時のｃｏｏｋｉｅ設定フローチャート 統合ログイン状態下で統合エントランスにアクセスした場合のシーケンス図 ログイン判定ｃｏｏｋｉｅチェックのフローチャート 統合ログイン状態下で認証エラーとなった場合のシーケンス図 遷移先チェックのフローチャート 認証エラーの際に詳細エラーを表示する場合のシーケンス図 ＪＷＴを用いた統合ログインシーケンス図 ＪＷＴを用いた統合ログインで発行されるＪＷＴの例 ログイン処理切り替えのフローチャート 認証エラーの表示画面

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

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

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

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

また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。

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

２００はインターネットを表しており、Ｗｅｂクライアント２０１はインターネットに接続されている。Ｗｅｂクライアント２０１はＷｅｂブラウザの機能を搭載したクライアントであり、ｃｏｏｋｉｅ等のＷｅｂ技術を利用することができる。２１０はデータセンターを示しており、２２０は２１０と別のデータセンターを示している。ここで便宜上、データセンターが設置されている地域を元にした識別名でデータセンターを区別することとし、２１０のデータセンターをＵＳリージョン、２２０のデータセンターをＥＵリージョンと呼称する。ＵＳリージョン２１０内のコンピュータネットワーク２１１には、リバースプロキシサーバー２１２、認証・認可サーバー２１３、リソースサーバー２１４が接続されている。また、ＥＵリージョン２２０内のコンピュータネットワーク２２１には、リバースプロキシサーバー２２２、認証・認可サーバー２２３、リソースサーバー２２４が接続されている。なお、リージョンとは国、地域と言ったある一定の範囲を指す用語であり、リージョンの範囲に限定はない。

ＵＳリージョン２１０とＥＵリージョン２２０には同様のサーバー構成が構築されている。リバースプロキシサーバー２１２および２２２は外部からのリクエストをネットワーク内部のサーバーに振り分ける役割を持つ。例えば、ＵＲＬのパス名から認証・認可サーバーへ振り分けるのか、リソースサーバーに振り分けるのかを判断する。リバースプロキシサーバー２１２と２２２はそれぞれリージョン固有の異なるドメイン名が割り当てられ、ＵＲＬのドメイン名も異なる。従って、アクセスはリージョン毎に分離されることになる。Ｗｅｂクライアント２０１からリバースプロキシサーバー２１２へのアクセスは認証・認可サーバー２１３およびリソースサーバー２１４に振り分けられる。

一方、リバースプロキシサーバー２２２へのアクセスは認証・認可サーバー２２３およびリソースサーバー２２４に振り分けられる。また、リバースプロキシサーバー２１２および２２２がリクエストを受信するため、認証・認可サーバー２１３とリソースサーバー２１４のドメイン名およびドメインは同じになる。同様に認証・認可サーバー２２３とリソースサーバー２２４のドメイン名およびドメインも同じになる。認証・認可サーバー２１３および２２３はＷｅｂクライアント２０１からのリクエストに対して認証、および処理の認可を行う。なお、認証処理のみ行う認証・認可サーバーであってもよいため、便宜上、認証・認可サーバーを単に認証サーバーと呼ぶ場合もある。リソースサーバー２１４および２２４は、認証・認可サーバー２１３および２２３に認可された範囲でＷｅｂアプリケーションサービスを提供する。

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

図３は認証・認可サーバー２１３および２２３の機能ブロック図である。リクエスト受信部３０１はクライアントあるいはサーバーからのリクエストを受信する。レスポンス送信部３０２はリクエスト受信部３０１で受信した内容に応じてクライアントあるいはサーバーへ応答を返す。ｃｏｏｋｉｅ管理部３０３はリクエスト受信部３０１やレスポンス送信部３０２で送受信されるｃｏｏｋｉｅ情報の設定や取得を行う。ユーザー情報管理部３０４は登録されたユーザー情報を保管、管理する。認証トークン発行部３０５は認証トークンの発行を行う。認証トークンはユーザー情報管理部３０４に保管されたユーザー情報に紐付けて発行される。認証トークン管理部３０６は認証トークン発行部３０５が発行した認証トークンを保管、管理する。また、不要となった認証トークンの削除も認証トークン管理部３０６で行われる。認証トークン検証部３０７は渡された認証トークンを認証トークン管理部３０６に保管されている認証トークンと照合し、認証トークンが正規に発行されたものであるか、すなわちユーザーが認証済みであるかを検証する。

図４および図５で、統合エントランスサーバーが存在しない場合のシーケンスについて説明を行う。なお、図４以降のシーケンス図において、図２で示したリバースプロキシサーバー２１２を省略して記載する。Ｗｅｂクライアント２０１から認証・認可サーバー２１３やリソースサーバー２１４に直接アクセスしているように記載するが、実際にはリバースプロキシサーバー２１２を経由してアクセスされる。

図４（Ａ）は、従来のログインシーケンスを示した図である。Ｗｅｂクライアント２０１はＵＳリージョン２１０にある認証・認可サーバー２１３に対してログインページを要求し（Ｓ４０１）、認証・認可サーバー２１３はＷｅｂクライアント２０１にログインページを返す（Ｓ４０２）。ログインページを受信したＷｅｂクライアント２０１はログインページをディスプレイ装置１１４に表示し、Ｗｅｂクライアント２０１を利用するユーザーはキーボード１１５やポインティングデバイス１１６等の入力装置を使ってログインページ上にユーザーＩＤとパスワードを入力し、ログイン指示を出す（Ｓ４０３）。

Ｗｅｂクライアント２０１は認証・認可サーバー２１３にログイン要求を送信する（Ｓ４０４）。この際、利用ユーザーから受信したユーザーＩＤとパスワードも送信する。Ｓ４０４でログイン要求時に指定するＵＲＬは、ＵＳリージョン２１０固有のドメイン名を持ったＵＲＬとなる。要求を受信した認証・認可サーバー２１３はログイン処理を行う（Ｓ４０５）。ログイン処理の詳細は図８の中で後述する。そして、認証・認可サーバー２１３はログイン完了時の移動先であるメニューページのＵＲＬへリダイレクトする指示と、ｃｏｏｋｉｅ情報に認証トークンを設定する指示を応答として返す（Ｓ４０６）。

Ｗｅｂクライアント２０１のＷｅｂブラウザは、Ｓ４０６で受信したｃｏｏｋｉｅをローカルに保管する。Ｓ４０６で認証・認可サーバー２１３が設定するｃｏｏｋｉｅ情報の例を示したのが図４（Ｂ）である。Ｃｏｏｋｉｅ情報の設定はＨＴＴＰヘッダのＳｅｔ−Ｃｏｏｋｉｅフィールドで指定される。図４（Ｂ）の「ａｕｔｈ」属性に設定される値が認証トークンで、認証トークンは認証・認可サーバー２１３内でユニークなＩＤである。また「ｅｘｐｉｒｅｒｓ」属性に設定される値はｃｏｏｋｉｅの有効期限で、有効期限を過ぎたｃｏｏｋｉｅはＷｅｂブラウザからサーバーに送信されない仕様となっている。また、図４（Ｂ）では「ｄｏｍａｉｎ」属性を指定していないが、「ｄｏｍａｉｎ」属性を指定しない場合は、ｃｏｏｋｉｅ情報の設定を行ったサーバーのドメイン、図例の場合ｗｗｗ−ｕｓ．ｘｙｚ．ｃｏｍのみに送信される仕様となっている。

図４（Ａ）に戻り、Ｗｅｂクライアント２０１はＳ４０６で受信したリダイレクト先ＵＲＬへリダイレクトすると共に、保管したｃｏｏｋｉｅ情報を送信する（Ｓ４０７）。認証・認可サーバー２１３とリソースサーバー２１４は同じリバースプロキシサーバー２１２を経由するため、Ｗｅｂクライアント２０１は認証・認可サーバー２１３とリソースサーバー２１４を同じリバースプロキシサーバー２１２のドメインと判定しｃｏｏｋｉｅ情報を送信する。リソースサーバー２１４は受信した認証トークンの検証を認証・認可サーバー２１３に依頼し、認証・認可サーバー２１３が認証トークンの検証を行う（Ｓ４０８）。ユーザーが認証済みであることが検証されたら、リソースサーバー２１４はＷｅｂクライアント２０１から要求されたメニューページを返す（Ｓ４０９）。

図５はユーザーがログインした状態、すなわち、Ｗｅｂクライアント２０１に認証トークンがｃｏｏｋｉｅとして保管されている状態において認証・認可サーバー２１３やリソースサーバー２１４へアクセスしたときのシーケンス図を示している。

図５（Ａ）は、メニューページにアクセスした場合のシーケンス図で、図４（Ａ）のＳ４０７からの処理と同じになる。図４（Ａ）では、Ｓ４０６でリダイレクトされてメニューページにアクセスしたが、図５（Ａ）ではＷｅｂクライアント２０１から直接メニューページへのアクセスを指定している。

Ｗｅｂクライアント２０１がメニューページへのアクセスを要求すると共に、Ｓ４０６で受信して保管した、認証トークンが設定されたｃｏｏｋｉｅ情報をリソースサーバー２１４に送信する（Ｓ５０１）。リソースサーバー２１４は受信した認証トークンの検証を認証・認可サーバー２１３に依頼し、認証・認可サーバー２１３が認証トークンの検証を行う（Ｓ４０８）。ユーザーが認証済みであることが検証されたら、リソースサーバー２１４はＷｅｂクライアント２０１から要求されたメニューページを返す（Ｓ４０９）。

図５（Ｂ）は、ログアウト時のシーケンス図を示している。Ｗｅｂクライアント２０１はログアウト要求を送信する（Ｓ５１１）。受信した認証・認可サーバー２１３は認証トークン管理部３０６に保管した認証トークンを削除する（Ｓ５１２）。そして、認証トークンが設定されたｃｏｏｋｉｅの有効期限を現在日時より過去にして設定し直すと共に、デフォルトページであるログインページを返す（Ｓ５１３）。認証トークンが設定されたｃｏｏｋｉｅは有効期限が切れるため無効化される。

図５（Ｃ）は、メニューページにアクセスして認証エラーになった場合のシーケンス図を示している。認証エラーになるケースとしては、認証トークンが設定されたｃｏｏｋｉｅの有効期限が切れた場合や認証トークン管理部３０６で管理されていない認証トークンを送信した場合等がある。なお、既にログアウトした場合も有効期限切れの場合と同様である。Ｗｅｂクライアント２０１はメニューページへのアクセスを要求するが、Ｓ４０６で受信した認証トークンは有効期限が切れているため送信されない、もしくは、認証トークン管理部３０６で管理されていない認証トークンが送信される（Ｓ５２１）。

リソースサーバー２１４は認証トークンの検証を認証・認可サーバー２１３に依頼するが、認証・認可サーバー２１３は認証トークンの値が無い、あるいは認証トークンが認証トークン管理部３０６に存在しないため、検証エラーとなる（Ｓ５２２）。なお、認証トークンが渡されなかった場合、認証トークンの検証を認証・認可サーバー２１３に依頼せずにリソースサーバーが認証エラーと判断する実装であってもよい。リソースサーバー２１４はリダイレクト先に認証エラー発生時のエンドポイントのＵＲＬを指定して応答を返す（Ｓ５２３）。Ｗｅｂクライアント２０１はＳ５２３で指定されたエンドポイントへリダイレクトし（Ｓ５２４）、認証・認可サーバー２１３はエラー情報を含んだログインページを返す（Ｓ５２５）。

図４および図５で示したように、ｃｏｏｋｉｅに認証トークンを保管することで、ステートレスなＨＴＴＰプロトコルであっても、その都度ログイン処理を行うことなくリソースサーバーにアクセスできる。また、ログアウト時や認証エラーが発生した場合もエラーページやログインページに戻ることができる。なお、図４および図５では図２で示したＵＳリージョン２１０でのフローを示したが、ＥＵリージョン２２０でも同様のシーケンスとなる。

次に図６から図１２で統合エントランスサーバー２３０を経由したクラウド認証サービスについて説明する。図６は統合エントランスサーバー２３０の機能ブロック図である。リクエスト受信部６０１はクライアントあるいはサーバーからのリクエストを受信する。レスポンス送信部６０２はリクエスト受信部６０１で受信した内容に応じてクライアントあるいはサーバーへ応答を返す。ｃｏｏｋｉｅ管理部６０３はリクエスト受信部６０１やレスポンス送信部６０２で送受信されるｃｏｏｋｉｅ情報の設定や取得を行う。ユーザーリージョンマッピング情報管理部６０４は各リージョンに所属するユーザーＩＤのハッシュ値とそのユーザーが登録されているリージョンのマッピング情報を管理する。ユーザーＩＤのハッシュ値を保管するのは、ユーザーＩＤが個人情報にあたり、個人情報を保護するためである。ユーザーＩＤはワールドワイドでユニークな値となっている。また、統合エントランスサーバー２３０は各リージョンの認証・認可サーバーのユーザー情報管理部３０４と同期してマッピング情報を管理する。

図２の例では、ＵＳリージョン２１０にある認証・認可サーバー２１３のユーザー情報管理部３０４に保管されているユーザーＩＤリストの各ハッシュ値とＵＳリージョンであることのマッピング情報を保管している。また、ＥＵリージョン２２０にある認証・認可サーバー２２３のユーザー情報管理部３０４に保管されているユーザーＩＤも同様にユーザーＩＤリストの各ハッシュ値とＥＵリージョンであることのマッピング情報を保管している。その結果、ユーザーリージョンマッピング情報管理部６０４の情報によって、統合エントランスサーバー２３０はユーザーＩＤがどのリージョンに所属しているのかが判定可能となる。リージョン情報管理部６０５はクラウド認証サービスに内にあるリージョン情報や各リージョンに配備されたサーバーのドメイン名等の情報を管理する。表１はユーザーＩＤとリージョンのマッピングテーブルの例である。

表１のｕｓｅｒ＿ｉｄ＿ｈａｓｈ列はユーザーＩＤのハッシュ値である。前述のようにユーザーＩＤは個人情報に該当する場合があるため、ユーザーが特定されないようにハッシュ値にして保管している。統合エントランスサーバー２３０がユーザーＩＤを照合する際は、マッピングテーブルに保管されたハッシュ値と同様の方法で受信したユーザーＩＤをハッシュ値に変換し、照合を行う。ｒｅｇｉｏｎ列はユーザーが所属するリージョンを示している。

図７（Ａ）は本発明の一実施形態としてのログインシーケンス図である。Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してログインページを要求し（Ｓ７０１）、統合エントランスサーバー２３０はＷｅｂクライアント２０１にログインページを返す（Ｓ７０２）。Ｓ７０１で統合エントランスサーバー２３０に要求する際のＵＲＬはワールドワイドで共通のＵＲＬとなり、クライアントがどのリージョンにあってもＵＲＬの変化を意識することなく利用できるＵＲＬである。ここで、ログインページを受信したＷｅｂクライアント２０１ではログインページのＨＴＭＬに記述されたスクリプトが動作し、統合エントランスサーバー２３０に対してログイン判定ｃｏｏｋｉｅのチェックを行うＡＰＩを実行する（Ｓ９０３）。受信した統合エントランスサーバー２３０は、ログイン判定ｃｏｏｋｉｅのチェックを行う（Ｓ９０４）。詳細は後述の図９で説明するが、Ｓ９０３およびＳ９０４の処理は既にログイン済みかどうかを判定するための処理であり、図７においては未だログイン処理は行われていないため、Ｓ９０５では戻り値が返されない。

ログイン済みでないことを確認すると、Ｗｅｂクライアント２０１はログインページをディスプレイ装置１１４に表示する。Ｗｅｂクライアント２０１を利用するユーザーはキーボード１１５やポインティングデバイス１１６等の入力装置を使ってログインページ上にユーザーＩＤとパスワードを入力し、ログイン指示を出す（Ｓ７０３）。すると、ログインページのＨＴＭＬに記載されたスクリプトがクライアント上で動作し、Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してユーザーＩＤの所属リージョンを取得するＡＰＩを実行する（Ｓ７０４）。

このとき利用ユーザーから受信したユーザーＩＤも統合エントランスサーバー２３０へ送信される。なお、ＡＰＩ実行スクリプトの記述例には「ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｏｐｅｎ（‘ＰＯＳＴ’， ‘／ｒｅｇｉｏｎ’， ｆａｌｓｅ）；」などがある。統合エントランスサーバー２３０は受信したユーザーＩＤのハッシュ値を算出し、ユーザーリージョンマッピング情報管理部６０４で照合して所属するリージョンを特定する（Ｓ７０５）。そして、統合エントランスサーバー２３０はＳ７０５で特定されたリージョンをＷｅｂクライアント２０１へ返す（Ｓ７０６）。Ｗｅｂクライアント２０１は受信したリージョンによって特定されるＵＲＬのログインＡＰＩにログイン要求を行う（Ｓ７０７）。図７（Ａ）の例ではＵＳリージョンにユーザーが所属しているため、ＵＳリージョン２１０にある認証・認可サーバー２１３のログインＡＰＩにログイン要求を送信する。

Ｓ７０７でログイン要求時に指定するＵＲＬは、ＵＳリージョン２１０固有のドメイン名を持ったＵＲＬとなる。ＵＲＬはログインページのＨＴＭＬに記載されたスクリプトがＳ７０６で受信したリージョンと組み合わせて作成する。なお、統合エントランスサーバー２３０がＳ７０５で特定したリージョンに基づいて、リージョン情報管理部６０５から認証・認可サーバー２１３のログインＡＰＩのＵＲＬを取得し、Ｓ７０６でＵＲＬを送信するという実装であってもよい。またこの際、Ｓ７０３で利用ユーザーから受信したユーザーＩＤとパスワードも送信する。

認証・認可サーバー２１３はログイン処理を行う（Ｓ７０８）。ログイン処理の詳細は図８の中で後述する。認証・認可サーバー２１３はログイン完了時の移動先であるメニューページのＵＲＬへリダイレクトする指示を応答として返す（Ｓ７０９）。このとき、後述するログイン処理の結果、ｃｏｏｋｉｅ情報に認証トークンおよび統合エントランスからログインされた識別情報を設定する。Ｗｅｂクライアント２０１はＳ７０９で受信した２種類のｃｏｏｋｉｅをローカルに保管する。

Ｓ７０９で設定するｃｏｏｋｉｅ情報の例を示したのが図７（Ｂ）である。図７（Ｂ）において、７２１は認証トークンを設定するｃｏｏｋｉｅで、図４（Ｂ）と同じものである。７２２は統合エントランスからログインされた識別情報を設定するｃｏｏｋｉｅである。「ｌｏｇｉｎ」はログイン状態であることを示すキー名で、その値「ｗｗ＿ｕｓ」は統合エントランスを経由してＵＳリージョンでログインしたことを示している。図４のケースのようにリージョン内からログインした場合には、値「ｕｓ」が設定される。「ｄｏｍａｉｎ」属性に設定される値はｃｏｏｋｉｅの送信範囲を示している。ログイン判定ｃｏｏｋｉｅ７２２では、「ｄｏｍａｉｎ」属性に「ｘｙｚ．ｃｏｍ」が指定されているが、これはメインドメインであるｘｙｚ．ｃｏｍとそのサブドメイン全てのサーバーに送信されることを示す。すなわち、Ｃｏｏｋｉｅ情報は図２のＵＳリージョン２１０とＥＵリージョン２２０内にあるサーバー全てに送信される。

なお、認証トークンｃｏｏｋｉｅ７２１のように「ｄｏｍａｉｎ」属性を指定しない場合は、ｃｏｏｋｉｅの設定を行ったサーバーのドメイン、図例の場合ｗｗｗ−ｕｓ．ｘｙｚ．ｃｏｍのみに送信される仕様となっている。すなわち、統合エントランスサーバー２３０にはログイン状態であることを判定するためのログイン判定ｃｏｏｋｉｅ７２２のみが送信される。一方、リバースプロキシサーバー２１２を経由する認証・認可サーバー２１３とリソースサーバー２１４には認証トークンｃｏｏｋｉｅ７２１およびログイン判定ｃｏｏｋｉｅ７２２の両方が送信されることになる。認証トークンの送信範囲は図４のフローと変わらないため、セキュリティが弱まることはない。

図７（Ａ）に戻り、Ｗｅｂクライアント２０１はＳ７０９で受信したリダイレクト先ＵＲＬへリダイレクトすると共に、Ｓ７０９で受信して保管したｃｏｏｋｉｅ情報を送信する（Ｓ７１０）。リソースサーバー２１４は受信した認証トークンの検証を認証・認可サーバー２１３に依頼し、認証・認可サーバー２１３が認証トークンの検証を行う（Ｓ７１１）。ユーザーが認証済みであることが検証されたら、リソースサーバー２１４はＷｅｂクライアント２０１から要求されたメニューページを返す（Ｓ７１２）。なお、図４のシーケンスと図７のシーケンスは共存しており、Ｗｅｂクライアント２０１はリージョン内からログインする他、統合エントランスからログインすることも可能である。

図８は図７（Ａ）のＳ７０７で行われるログイン処理のフローチャートである。本フローチャートに係るプログラムは、認証・認可サーバー２１３の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。まず、認証・認可サーバー２１３はログイン処理を行う（Ｓ８０１）。具体的には、リクエスト受信部３０１でユーザーＩＤおよびパスワードを受信し、ユーザーＩＤおよびパスワードが合致するユーザー情報をユーザー情報管理部３０４が照合する。合致するユーザー情報が存在した場合はユーザーが認証されたと判断してログインを許可する。そしてログインが許可されたかどうかを判定し（Ｓ８０２）、許可された場合は認証トークン発行部３０５が認証トークンを発行（Ｓ８０３）、認証トークン管理部３０６が発行した認証トークンを保管する（Ｓ８０４）。

またｃｏｏｋｉｅ管理部３０３がレスポンスＨＴＴＰヘッダのＳｅｔ−Ｃｏｏｋｉｅフィールドとして発行された認証トークンを設定する（Ｓ８０５）。具体的には図７の７２１で示した通りである。そして、リクエスト受信部３０１が、図４で示したリージョン内からのログイン要求なのか、図７で示した統合エントランスからのログインなのかを判定する（Ｓ８０６）。判定方法としては図４と図７のようにリクエストを受信するＵＲＬが異なることで判別する方法や、ＵＲＬが同じ場合には判別するための属性値を設ける方法などがある。例えば、判別するための属性値としてＨＴＴＰヘッダのＯｒｉｇｉｎフィールドを使う方法がある。ＯｒｉｇｉｎフィールドはＣｒｏｓｓ−Ｏｒｉｇｉｎ Ｒｅｓｏｕｒｃｅ Ｓｈａｒｉｎｇの仕様で、異なるドメインへのアクセスを行う際に設定されるフィールドである。統合エントランスサーバー２３０のログインページから異なるドメインである認証・認可サーバー２１３へアクセスするため、Ｏｒｉｇｉｎフィールドに統合エントランスサーバー２３０のドメイン名「ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／」が設定される。一方、認証・認可サーバー２１３のログインページから同認証・認可サーバー２１３へアクセスする場合はＯｒｉｇｉｎフィールドが設定されないため、統合エントランスからのログインなのか判定が可能である。

Ｓ８０６で統合エントランスからのログインであると判定された場合は、ｃｏｏｋｉｅ管理部３０３がＨＴＴＰヘッダのＳｅｔ−Ｃｏｏｋｉｅフィールドとして統合エントランスからログインされたこととサーバーが所属するリージョン情報を持ったｃｏｏｋｉｅを設定する（Ｓ８０７）。具体的には図７の７２２で示した通りである。Ｓ８０２でログインが許可されなかった場合は認証エラーの応答を返す（Ｓ８０８）。

図９はユーザーが統合エントランスからログインした状態、すなわち、Ｗｅｂクライアント２０１に認証トークンｃｏｏｋｉｅ７２１とログイン判定ｃｏｏｋｉｅ７２２が保管されている状態において、統合エントランスに対してログイン要求を行った場合のシーケンス図である。Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してログインページを要求し（Ｓ９０１）、統合エントランスサーバー２３０はＷｅｂクライアント２０１にログインページを返す（Ｓ９０２）。ログインページを受信したＷｅｂクライアント２０１ではログインページに記述されたスクリプトが動作し、Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してログイン判定ｃｏｏｋｉｅのチェックを行うＡＰＩを実行する（Ｓ９０３）。また、併せてＷｅｂクライアント２０１は図７のＳ７０９で受信したログイン判定ｃｏｏｋｉｅ７２２を送信する。

ここで、認証トークンｃｏｏｋｉｅ７２１は送信範囲がリバースプロキシサーバー２１２を経由するサーバーに限られるため、統合エントランスサーバー２３０には送信されない。統合エントランスサーバー２３０は、ログイン判定ｃｏｏｋｉｅチェックを行い（Ｓ９０４）、リージョン情報をＷｅｂクライアント２０１へ返す（Ｓ９０５）。ログイン判定ｃｏｏｋｉｅチェックの内容は後述する。なお、リージョン情報が取得できなかった場合は、図７で説明したようにログインページが表示され、図７のＳ７０３にあるユーザーの入力を待つ状態となる。

続いてＷｅｂクライアント２０１はＳ９０５で受信したリージョンの認証・認可サーバーに対して、認証トークンが発行されているか、すなわちユーザーがログイン状態にあるかどうかを確認するＡＰＩを実行する（Ｓ９０６）。このＡＰＩは、ログインチェックを行う専用ＡＰＩであってもよいし、図に示したようにログイン状態であればユーザー情報が取得されるユーザー情報取得ＡＰＩを実行することで代用してもよい。また併せて、Ｗｅｂクライアント２０１は認証トークンｃｏｏｋｉｅ７２１およびログイン判定ｃｏｏｋｉｅ７２２を送信する。

認証・認可サーバー２１３は認証トークンを検証してログイン済みであることを確認すると（Ｓ９０７）、成功応答を返す（Ｓ９０８）。Ｗｅｂクライアント２０１はログイン状態にあることの応答を受信すると、Ｓ９０５で受信したリージョンに対して、メニューページへのアクセスを要求する（Ｓ９０９）。また併せて、Ｗｅｂクライアント２０１は認証トークンｃｏｏｋｉｅ７２１およびログイン判定ｃｏｏｋｉｅ７２２を送信する。リソースサーバー２１４は受信した認証トークンの検証を認証・認可サーバー２１３に依頼し、認証・認可サーバー２１３が認証トークンの検証を行う（Ｓ９１０）。ユーザーが認証済みであることが検証されたら、リソースサーバー２１４はＷｅｂクライアント２０１から要求されたメニューページを返す（Ｓ９１１）。

図１０は図９のＳ９０４において、統合エントランスサーバー２３０で行われるログイン判定ｃｏｏｋｉｅチェックのフローチャートである。本フローチャートに係るプログラムは、統合エントランスサーバー２３０の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。統合エントランスサーバー２３０において、ｃｏｏｋｉｅ管理部６０３がログイン判定ｃｏｏｋｉｅ７２２を取得し（Ｓ１００１）、ログイン判定ｃｏｏｋｉｅ７２２が存在するかどうかを判定する（Ｓ１００２）。ログイン判定ｃｏｏｋｉｅ７２２が存在する場合はｃｏｏｋｉｅ管理部６０３がｃｏｏｋｉｅの値に設定されていたリージョン情報を取得する（Ｓ１００３）。例えばリージョン内からログインした場合はログイン判定ｃｏｏｋｉｅ７２２の値である「ｕｓ」を取得し、統合エントランスサーバー２３０経由でログインした場合は値「ｗｗ＿ｕｓ」からリージョンを示す部分「ｕｓ」を切り出して取得する。そして、リージョン情報管理部６０５がリージョン情報のチェックを行った上で、レスポンス送信部６０２がリージョン情報を応答する（Ｓ１００４）。Ｓ１００２でログイン判定ｃｏｏｋｉｅ７２２が取得できなかった場合はログイン状態ではないため、認証エラーを応答する（Ｓ１００５）。

図１１はユーザーが統合エントランスからログインした状態、すなわち、Ｗｅｂクライアント２０１に認証トークンｃｏｏｋｉｅ７２１とログイン判定ｃｏｏｋｉｅ７２２が保管されている状態において、メニューページにアクセスしたが認証エラーになった場合のシーケンス図を示している。認証エラーになるケースとしては、図５（Ｃ）と同様に、認証トークンが設定されたｃｏｏｋｉｅの有効期限が切れた場合や認証トークン管理部３０６で管理されていない認証トークンを送信した場合等がある。既にログアウトした状態の場合も有効期限切れの場合と同様である。

Ｗｅｂクライアント２０１はリソースサーバー２１４にメニューページへのアクセスを要求するが、Ｓ７０９で受信した認証トークンは有効期限が切れているため送信されない、もしくは、認証トークン管理部３０６で管理されていない認証トークンが送信される（Ｓ１１０１）。リソースサーバー２１４は認証トークンの検証を認証・認可サーバー２１３に依頼するが、認証・認可サーバー２１３は認証トークンの値が無い、あるいは認証トークンが認証トークン管理部３０６に存在しないため、検証エラーとなる（Ｓ１１０２）。なお、認証トークンが渡されなかった場合、認証トークンの検証を認証・認可サーバー２１３に依頼せずにリソースサーバーが認証エラーと判断する実装であってもよい。

リソースサーバー２１４はリダイレクト先に認証エラー時のエンドポイントのＵＲＬを指定して応答を返し（Ｓ１１０３）、Ｗｅｂクライアント２０１は認証エラー時のエンドポイントへリダイレクトする（Ｓ１１０４）。併せて、ログイン判定ｃｏｏｋｉｅ７２２が送信されるが、認証トークンは有効期限が切れているため送信されない、もしくは、認証トークン管理部３０６で管理されていない認証トークンを送信する。認証・認可サーバー２１３は統合エントランス経由でログインしたのかリージョン内からログインしたのか確認（以降、遷移先チェックと呼称）を行う（Ｓ１１０５）。遷移先チェックの詳細は後述するが、図１１においては、Ｗｅｂクライアント２０１は統合エントランス経由でログインした前提で説明を続ける。認証・認可サーバー２１３は統合エントランスのログインページにエラー情報のクエリパラメータを付けてリダイレクトすると共に、ログイン判定ｃｏｏｋｉｅ７２２を無効化する（Ｓ１１０６）。Ｗｅｂクライアント２０１は統合エントランスサーバー２３０へリダイレクトし（Ｓ１１０７）、統合エントランスサーバー２３０はクエリパラメータを元にエラー情報を付けたログインページを応答する（Ｓ１１０８）。

図１２は図１１のＳ１１０５で行われる遷移先チェックのフローチャートである。本フローチャートに係るプログラムは、認証・認可サーバー２１３の記憶装置１０４に記憶されており、メモリ１０３に読み出されＣＰＵ１０２によって実行される。認証・認可サーバー２１３において、ｃｏｏｋｉｅ管理部３０３がログイン判定ｃｏｏｋｉｅ７２２を取得し（Ｓ２１０１）、統合エントランス経由でログインされたのかリージョン内からログインされたのかを判定する（Ｓ２１０２）。例えば、ログイン判定ｃｏｏｋｉｅ７２２の値に「ｗｗ」が付いていれば統合エントランス経由でログインされたと判定し、リージョン部分のみであればリージョン内からログインされたと判定する。統合エントランス経由でログインされた場合は、ｃｏｏｋｉｅ管理部３０３がログイン判定ｃｏｏｋｉｅ７２２の有効期限を現在日時より過去にして設定し直す（Ｓ２１０３）。そして、レスポンス送信部３０２が統合エントランスのログインページにエラー情報のクエリパラメータを付けてリダイレクト応答を返す（Ｓ１２０４）。Ｓ２１０２でリージョン内からログインされた場合は、Ｓ２１０３と同様にログイン判定ｃｏｏｋｉｅ７２２を無効化し（Ｓ１２０５）、レスポンス送信部３０２がリージョン内のログインページにエラー情報を追加して応答する（Ｓ１２０６）。

以上、図６から図１２で説明したように、統合エントランスからログインした場合とリージョン内からログインした場合の遷移を適切に制御することが可能となる。また、認証トークンと統合ログイン経由時の識別情報をｃｏｏｋｉｅのドメイン属性を使い分けて設定することで、セキュリティの低下を防ぐことにもなる。なお、図６から図１２ではＵＳリージョン２１０へ遷移するフローを示したが、ＥＵリージョン２２０へ遷移する場合も同様のシーケンスとなる。

次に図１３で、図１１のシーケンスにおけるＳ１１０８において、詳細なエラー表示を行うケースについて説明する。エラー表示にはユーザーＩＤなどの個人情報を表示するケースがある。しかし、エラーページの作成はリダイレクト先の統合エントランスサーバー２３０が行うため、図４および図５で示した従来のケースのように、認証・認可サーバー２１３のｓｅｓｓｉｏｎに情報を保持することができない。また、ｃｏｏｋｉｅに関しても送信範囲が広がって国を越えるケースもあるため、個人情報保護の観点から保管すべきではない。そこで、個人情報は予めＷｅｂ Ｓｔｏｒａｇｅに保管しておき、エラー発生時にＷｅｂクライアント２０１がスクリプトで表示するエラー情報を整形して出力する例について説明する。

図１３は図７で示した統合エントランスサーバー２３０からログインを行い、図１１で示した認証エラーが発生するケースを示している。図１３において、Ｓ７０１からＳ７０３までの処理は図７と同様である。次にＳ７０３で利用ユーザーが入力を行った際に、ユーザーＩＤをＷｅｂ Ｓｔｏｒａｇｅに保管する（Ｓ１３０１）。保管する処理はＳ７０２で返されるログインページのＨＴＭＬに記述されたスクリプトがページに入力されたユーザーＩＤを取得し、Ｗｅｂ Ｓｔｏｒａｇｅ に保管するメソッドを使って保管する。保管メソッドの例としては「ｓｅｓｓｉｏｎＳｔｏｒａｇｅ．ｓｅｔＩｔｅｍ（‘ｕｓｅｒＩｄ’， ｕｓｅｒＩｄ）；」などがある。第一引数の「‘ｕｓｅｒＩｄ’」はＷｅｂ Ｓｔｏｒａｇｅに保管するときのキー名で、第二引数の「ｕｓｅｒＩｄ」はログインページに入力されたユーザーＩＤが格納されている変数を示している。

Ｓ７０４以降のログイン処理は図７と同様のため省略する。その後、図１１と同様にＳ１１０１からＳ１１０８でメニューページを要求し認証エラーが発生、統合エントランスサーバー２３０にリダイレクトしてエラー表示を含むログインページか返される。Ｓ１１０８で返されるログインページのＨＴＭＬに記述されたスクリプトがＷｅｂクライアント２０１で実行され、表示するエラー情報にＳ１３０１でＷｅｂ Ｓｔｏｒａｇｅに保管したユーザーＩＤを取得して表示を行う（Ｓ１３０２）。Ｗｅｂ Ｓｔｏｒａｇｅから取得するメソッドの例としては「ｓｅｓｓｉｏｎＳｔｏｒａｇｅ．ｇｅｔＩｔｅｍ（‘ｕｓｅｒＩｄ’）；」などがある。第一引数の「‘ｕｓｅｒＩｄ’」はＷｅｂ Ｓｔｏｒａｇｅから取得する情報のキー名を示している。

図１７は図１３のＳ１３０２で説明したエラー表示の例を示している。１７０１はエラーメッセージである。エラーメッセージは図１３において認証・認可サーバー２１３がＳ１１０６で送信したエラー情報を、Ｓ１１０７を通して統合エントランスサーバー２３０が受信し、Ｓ１１０８でメッセージとしてログインページのＨＴＭＬに埋め込んだものである。また、エラーメッセージは候補を複数ＨＴＭＬに埋め込んでおき、Ｗｅｂ Ｓｔｏｒａｇｅから取得した情報を元にログインページのＨＴＭＬに記述したスクリプトで選択しても構わない。例えば、図１７の例では、認証・認可サーバー２１３はＳ１１０６でログイン状態ではない旨のエラー情報を返す。Ｓ１３０２ではＷｅｂクライアント２０１はＷｅｂ ＳｔｏｒａｇｅにユーザーＩＤが保管されていたことによって直前にログインしていたと判定できるため、再ログインを促すメッセージを表示している。１７０２は直前にログインしていたときのユーザーＩＤで、図１３のＳ１３０２でＷｅｂ Ｓｔｏｒａｇｅから取得した値である。このように、保管する情報に応じて保管する場所を選択し組み合わせて利用することで、セキュリティの低下を防止しつつ、エラーを表示することができる。

［実施例２］
実施例１では、図７で説明した統合エントランスサーバー２３０からのログイン処理において、Ｓ７０４やＳ７０７でＡＰＩを使った実装を行っているが、古いＷｅｂブラウザではスクリプトを使ったＡＰＩ呼び出しが実行できないものもある。そのような古いＷｅｂブラウザを使ったケースにおいても、統合エントランスサーバー２３０からのログイン処理するための実施形態について説明する。

図１４において、Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してログインページを要求し（Ｓ１４０１）、統合エントランスサーバー２３０はＷｅｂクライアント２０１にログインページを返す（Ｓ１４０２）。Ｓ１４０１でログインページを要求する際のＵＲＬはワールドワイドで共通のＵＲＬとなる。また、Ｓ１４０２で返されるログインページのＨＴＭＬは実施例１の図７におけるＳ７０２の内容とは異なっており、図７のＳ９０３、Ｓ７０４、Ｓ７０７のようにＡＰＩが実行されるスクリプトは記述されていない。

ログインページを受信したＷｅｂクライアント２０１はログインページをディスプレイ装置１１４に表示する。Ｗｅｂクライアント２０１を利用するユーザーはキーボード１１５やポインティングデバイス１１６等の入力装置を使ってログインページ上にユーザーＩＤとパスワードを入力し、ログイン指示を出す（Ｓ１４０３）。Ｗｅｂクライアント２０１は統合エントランスサーバー２３０に対してログイン要求を送信する（Ｓ１４０４）。この際、Ｓ７０３で利用ユーザーから受信したユーザーＩＤとパスワードも送信する。

統合エントランスサーバー２３０は受信したユーザーＩＤのハッシュ値を算出し、ユーザーリージョンマッピング情報管理部６０４が所属するリージョンを特定する（Ｓ１４０５）。そして、統合エントランスサーバー２３０は、認証・認可サーバー２１３にログイン要求を行うために、ＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）フォーマットのリクエスト情報を作成する（Ｓ１４０６）。ＪＷＴにはＷｅｂクライアント２０１から受信したユーザーＩＤとパスワードが含まれる。ＪＷＴの内容の詳細は後述する。また、ＪＷＴにはデジタル署名が付けられ、ＪＷＴのヘッダ部とペイロード部は暗号化される。デジタル署名には統合エントランスサーバー２３０の秘密鍵、暗号化には共通鍵が用いられる。統合エントランスサーバー２３０では予め公開鍵と秘密鍵の鍵ペアが作成されており、公開鍵が認証・認可サーバー２１３に配布されている。また、共通鍵が統合エントランスサーバー２３０や認証・認可サーバー２１３等、本システム内のサーバーに配布されている。

統合エントランスサーバー２３０はＷｅｂクライアント２０１に遷移先のＵＲＬ、暗号化されたＪＷＴを返し、ＪＷＴのデジタル署名をｃｏｏｋｉｅに設定する（Ｓ１４０７）。遷移先ＵＲＬのドメイン名はＳ１４０５で解決したリージョンのドメイン名である。ＪＷＴのデジタル署名を設定したｃｏｏｋｉｅのドメイン属性はログイン判定ｃｏｏｋｉｅ７２２と同じ「ｘｙｚ．ｃｏｍ」であり、認証・認可サーバー２１３も参照可能にしている。なお、ＪＷＴを暗号化するのは統合エントランスサーバー２３０から認証・認可サーバー２１３へＪＷＴを受け渡す際に盗聴を防止するためある。また、ＪＷＴをレスポンスで返してＪＷＴのデジタル署名をｃｏｏｋｉｅに保存するのは、ＪＷＴとＪＷＴのデジタル署名がセットで置換されてしまうことを防止するためである。

Ｗｅｂクライアント２０１は受信した遷移先のＵＲＬ、すなわち認証・認可サーバー２１３に対してログイン要求を行う。この際、Ｓ１４０７で受信したＪＷＴとＪＷＴのデジタル署名が設定されたｃｏｏｋｉｅを送信する（Ｓ１４０８）。なお、Ｓ１４０８のログイン要求は、実施例１の図７におけるＳ７０７とは異なるＵＲＬであり、認証・認可サーバー２１３で実行される処理も異なる。

認証・認可サーバー２１３は受信したＪＷＴを共通鍵で復号し（Ｓ１４０９）、統合エントランスサーバー２３０の公開鍵を使って受信したデジタル署名でＪＷＴの内容を署名検証する（Ｓ１４１０）。ＪＷＴの内容が署名検証されたら、ＪＷＴから取り出したユーザーＩＤとパスワードを使ってログイン処理を実施する（Ｓ１４１１）。なお、ログイン処理の詳細は前述の通りである。そして、認証・認可サーバー２１３は図７のＳ７０９と同様に、ログイン完了時に移動するメニューページのＵＲＬへリダイレクトする指示と、ｃｏｏｋｉｅ情報として認証トークンおよび統合エントランスからログインされた識別情報を設定する指示を応答として返す（Ｓ１４１２）。その後の処理は実施例１で説明した図７のＳ７１０からＳ７１２と同様である。

図１５はＳ１４０６で作成されるＪＷＴの例である。ＪＷＴはヘッダ部、ペイロード部、デジタル署名部からなっており、それぞれをＢａｓｅ６４エンコードした文字列を「．」連結した構成になっている。ここで利用するＪＷＴのペイロードには、ｉｓｓ（発行者を示す）およびｓｕｂ（主体を示す）に発行した統合エントランスサーバー２３０のドメイン名「ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／」が設定される。次にａｕｄ（利用者を示す）に認証・認可サーバー２１３のドメイン名「ｈｔｔｐｓ：／／ｗｗｗ−ｕｓ．ｘｙｚ．ｃｏｍ／」を設定し、ｅｘｐ（有効期限）、ｉａｔ（発行日時）をそれぞれ設定する。そして本実施の形態の特徴として、ペイロードのｕｓｅｒＩｄにユーザーＩＤの値、ｐａｓｓｗｏｒｄにパスワードの値が設定されている。なお、図１５の例ではログインコンテキストをＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式のテキストデータで示しているが、その形式に限定されない。最後にヘッダおよびペイロードをＢａｓｅ６４エンコードし、その文字列に対して統合エントランスサーバー２３０の秘密鍵を使ってデジタル署名を付与する。

認証・認可サーバー２１３は統合エントランスサーバー２３０の公開鍵を使ってこのデジタル署名値を検証する事によって、ＪＷＴの情報が改竄されていない事を検証する事ができる。また、図１４で説明したように、Ｓ１４０６ではヘッダ部とペイロード部、デジタル署名部は分離され、ヘッダ部とペイロード部は共通鍵を使って暗号化された上でＷｅｂクライアント２０１に渡される。

以上のように、スクリプトを使ったＡＰＩ呼び出しが実行できない古いＷｅｂブラウザであっても、統合エントランスサーバー２３０からのログイン処理を実行することができる。なお、実施例１と実施例２は共存した実装とすることもできる。実施例１の図７におけるＳ７０１と実施例２の図１４におけるＳ１４０１は共に同じＵＲＬを指定し、それぞれＳ７０２もしくはＳ１４０２のログインページを返しているが、ログインページを共通化する。そして、クライアント側でログインページのＨＴＭＬに記載されたスクリプトによって実施例１もしくは実施例２のどちらの処理を実行するかを判定することで共存が可能となる。

図１６はログイン処理切り替えのフローチャートである。本フローチャートに係るプログラムは、ログインページのＨＴＭＬに記載されたスクリプトとして受信し、Ｗｅｂクライアント２０１のメモリ１０３に読み出されＣＰＵ１０２によって実行される。まず、Ｗｅｂクライアント２０１は環境情報を取得する（Ｓ１６０１）。環境情報の取得は、例えばｊａｖａｓｃｒｉｐｔでｗｉｎｄｏｗ．ｎａｖｉｇａｔｏｒオブジェクトを取得する。ｗｉｎｄｏｗ．ｎａｖｉｇａｔｏｒオブジェクトにはＷｅｂブラウザの情報やオペレーションシステムの情報等が含まれている。Ｗｅｂクライアント２０１は環境情報を確認し、クライアント側でＡＰＩ呼び出しが可能かどうかを判断する（Ｓ１６０２）。ＡＰＩ呼び出しが可能かどうかの判定も予めスクリプトに判定処理が記載されており、Ｗｅｂクライアント２０１はスクリプトの判定処理に従って判断を行う。そして、ＡＰＩ呼び出しが可能であれば、実施例１の図７で示したＡＰＩを使ったログイン処理を実施し（Ｓ１６０３）、ＡＰＩ呼び出しが不可であれば、実施例２の図１４で示したＳ１４０２のログイン処理を実施する（Ｓ１６０４）。

［その他の実施例］
実施例１および実施例２は認証・認可サーバー２１３が認証トークンを発行し、リソースサーバー２１４は認証トークンの検証を認証・認可サーバー２１３に依頼していたが、デジタル署名付きの情報として渡す実装であってもよい。例えば、認証・認可サーバー２１３は、認証トークンをＪＷＴフォーマットで発行し、自身の秘密鍵を使ってデジタル署名を付与して渡す。リソースサーバー２１４は認証・認可サーバー２１３の公開鍵を使って署名検証を行い、ＪＷＴペイロード部をチェックすることで認証トークンの検証を行う。

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２０１ Ｗｅｂクライアント
２１２ リバースプロキシサーバー
２１３ 認証・認可サーバー
２１４ リソースサーバー
２３０ 統合エントランスサーバー

Claims (10)

1. 各リージョンに配備された複数の認証サーバーと、ログインページを提供する統合エントランスサーバーと、Ｗｅｂブラウザを有するクライアントとを含むシステムであって、
   前記統合エントランスサーバーは、
   前記Ｗｅｂブラウザから前記ログインページを介してユーザーにより入力されたユーザー情報を受信したことに応じて、前記ユーザー情報を基に前記ユーザーが所属するリージョンを特定する特定手段と、
   前記特定手段により特定されたリージョンに関する情報を前記Ｗｅｂブラウザへ送信する送信手段と、を有し、
   前記クライアントは、
   前記送信手段により送信された情報を基に、各リージョンに配備された複数の認証サーバーの内、１つの認証サーバーへアクセスするアクセス手段を有し、
   前記アクセス手段によるアクセスを受けた前記認証サーバーは、
   前記アクセス手段によるアクセスに伴い受信した前記ユーザー情報を基に、前記ユーザーの認証を行う認証手段と、
   前記認証手段により前記ユーザーが認証されたことに応じて、前記ＷｅｂブラウザのＣｏｏｋｉｅ情報に対してログインされたことを示す認証トークンおよび前記統合エントランスサーバーを経由してログインされたことを示す識別情報を設定する設定手段と、を有し、
   前記ＷｅｂブラウザのＣｏｏｋｉｅ情報を基に、前記システムにおける前記Ｗｅｂブラウザの遷移を制御することを特徴とするシステム。
2. 前記Ｗｅｂブラウザの遷移の制御とは、前記統合エントランスサーバーへのアクセス、および各リージョンに配備されたリソースサーバーへのアクセスの何れか１つのアクセスが行われたことによる前記Ｗｅｂブラウザの遷移の制御であることを特徴とする請求項１に記載のシステム。
3. 前記アクセス手段によるアクセスは、前記Ｗｅｂブラウザにより行われることを特徴とする請求項１または２に記載のシステム。
4. 前記認証サーバーは、
   各リージョンに配備された複数のリソースサーバーの内、前記クライアントによるアクセスを受けたリソースサーバーから前記クライアントの前記ＷｅｂブラウザのＣｏｏｋｉｅ情報に設定された認証トークンを受信し、受信された認証トークンの検証を行う検証手段を有する請求項１に記載のシステム。
5. 前記認証サーバーは、
   前記検証手段による検証がエラーであったことにより前記リソースサーバーからの指示で前記クライアントがアクセスしてきたことに応じて、前記Ｃｏｏｋｉｅ情報に設定された前記識別情報を基に、前記統合エントランスサーバーを経由してログインしたか否かを確認する確認手段と、
   前記確認手段により前記統合エントランスサーバーを経由してログインしたと確認されたことに応じて、前記クライアントに前記統合エントランスサーバーへアクセスするよう指示する指示手段と、を有し、
   前記統合エントランスサーバーは、前記指示手段による指示に従いアクセスしてきた前記クライアントの前記Ｗｅｂブラウザに対して前記ログインページを提供することを特徴とする請求項４に記載のシステム。
6. 前記指示手段は、クライアントに前記統合エントランスサーバーへアクセスするよう指示するとともに、前記Ｗｅｂブラウザの前記Ｃｏｏｋｉｅ情報に設定された前記識別情報を無効化することを特徴とする請求項５に記載のシステム。
7. 前記認証サーバーは、前記確認手段により前記統合エントランスサーバーを経由してログインしていないと確認されたことに応じて、前記クライアントの前記Ｗｅｂブラウザに対して前記認証サーバーのログインページを提供することを特徴とする請求項５または６に記載のシステム。
8. 前記Ｗｅｂブラウザは、
   前記統合エントランスサーバーが提供する前記ログインページに入力された前記ユーザー情報を保存する保存手段を有し、
   前記指示手段による指示に従い前記統合エントランスサーバーにアクセスしたことに応じて提供される前記ログインページに前記保存手段により保存された前記ユーザー情報が入力された状態で、当該ログインページを表示することを特徴とする請求項５乃至７の何れか１項に記載のシステム。
9. 前記送信手段は、前記クライアントの環境情報を基に前記Ｗｅｂブラウザが認証に関するＡＰＩを呼び出せないことが確認された場合、暗号化したユーザー情報、デジタル署名、およびアクセスすべき認証サーバーのＵＲＬを送信し、
   前記アクセス手段は、前記ＵＲＬが示す前記認証サーバーへアクセスするとともに前記ユーザー情報、および前記デジタル署名を送信し、
   前記認証手段は、前記デジタル署名の検証が成功したことに応じて、前記暗号化された前記ユーザー情報を基に前記ユーザーの認証を行うことを特徴とする請求項１乃至８の何れか１項に記載のシステム。
10. 各リージョンに配備された複数の認証サーバーと、ログインページを提供する統合エントランスサーバーと、Ｗｅｂブラウザを有するクライアントとを含むシステムの制御方法であって、
    前記統合エントランスサーバーにおいて、
    前記Ｗｅｂブラウザから前記ログインページを介してユーザーにより入力されたユーザー情報を受信したことに応じて、前記ユーザー情報を基に前記ユーザーが所属するリージョンを特定する特定ステップと、
    前記特定ステップにより特定されたリージョンに関する情報を前記Ｗｅｂブラウザへ送信する送信ステップと、を実行し、
    前記クライアントにおいて、
    前記送信ステップにおいて送信された情報を基に、各リージョンに配備された複数の認証サーバーの内、１つの認証サーバーへアクセスするアクセスステップを実行し、
    前記アクセスステップによるアクセスを受けた前記認証サーバーにおいて、
    前記アクセスステップによるアクセスに伴い受信した前記ユーザー情報を基に、前記ユーザーの認証を行う認証ステップと、
    前記認証ステップにおいて前記ユーザーが認証されたことに応じて、前記ＷｅｂブラウザのＣｏｏｋｉｅ情報に対してログインされたことを示す認証トークンおよび前記統合エントランスサーバーを経由してログインされたことを示す識別情報を設定する設定ステップと、を実行し、
    前記ＷｅｂブラウザのＣｏｏｋｉｅ情報を基に、前記システムにおける前記Ｗｅｂブラウザの遷移を制御することを特徴とする制御方法。

Images