JP2012528411A

JP2012528411A - 非ｈｔｔｐ通信プロトコルを用いてウエブアプリケーションの状態非依存型安全性管理を提供するシステム及び方法

Info

Publication number: JP2012528411A
Application number: JP2012513318A
Authority: JP
Inventors: ジョンアールファロウズ; フランクサリム
Original assignee: カージングコーポレーション
Priority date: 2009-05-28
Filing date: 2010-05-28
Publication date: 2012-11-12
Also published as: WO2010138883A1; US20100306547A1; CN102884517A; AU2010253949A1; US8527774B2; EP2435925A1

Abstract

ゲートウェイサーバーが、クライアント及びリモートサーバーシステムと相互に動作して、分散化されたウエブアプリケーションのための状態非依存型管理を提供する。クライアントアプリケーションに対応するローカル記憶部内に安全なトークンが存在していない場合には、ウエブブラウザクライアントのユーザへ向けられた認証チャレンジを実行することによって、クライアントシステム上のウエブクライアントアプリケーションが、リモートウエブサービスへ向けられたウエブソケット接続を開始する。認証チャレンジは、ユーザ信用証明を取得し、ユーザ信用証明を安全なトークン用のゲートウェイサーバーと交換する。次いで、この安全なトークンはプロトコル専用接続メッセージの形でゲートウェイサーバーへ送信される。ゲートウェイサーバーは、接続メッセージの受信に応答して、この接続メッセージを検査することにより、リモートウエブサービスへ向けられたウエブソケット接続を開始して、安全なトークンを回復し、この安全なトークンを評価して、ユーザ信用証明を取得し、このユーザ信用証明を安全なトークンに挿入し、上記接続メッセージをリモートウエブサービスへ送信する。
【選択図】図４

Description

〔関連出願との相互参照〕
本出願は、２００９年５月２８日出願の米国仮出願第６１／１８１，９２４号の利益を主張するものである。

本発明は一般に、非ＨＴＴＰプロトコルを用いて通信を行うウエブアプリケーションクライアントとサーバーとの間で安全性の保証された接続を確立することに関し、特に、非ＨＴＴＰ通信プロトコルを用いるリモートサーバーベースのウエブサービスと接続するウエブブラウザベースのウエブアプリケーションクライアントに対してサポートを行う、ゲートウェイサーバー介在安全性認証及び信用証明管理システムに関する。

ウエブベース技術の現在進行中の開発の実質的な態様は、分散化され、ネットワーク化されたアプリケーションに対するサポートを増加させることに向けられている。この努力が、ウエブブラウザベースのクライアントアプリケーションと、このウエブブラウザベースのクライアントアプリケーションに対して遠隔地に配置されているサーバーシステム上で提供されるウエブサービスとの間で双方向データ送信を行うための、接続用のベースとして、ＷｅｂＳｏｃｋｅｔｓ（ウエブソケット）の開発をもたらした。

分散化されたネットワークアプリケーションは、通常、対応するサービスアプリケーションを実行するサーバーシステムとの永続的な双方向接続を通じて理想的に通信を行う専用アプリケーションを、クライアントが実行するようになった、クライアントサーバーモデルを用いるものとして構成される。接続の初期化中に認証のための信用証明がクライアントから供給される。この認証は、クライアントアプリケーションが、接続を解除するか又は他の方法で遮断するまで持続する。接続が作動可能な状態にある間は、クライアントとサーバーは、提供するサービス及び交換されるデータの性質にとって最も適切なプロトコルを用いて通信を行う。

しかし、従来のウエブブラウザクライアントは、ページ及びＨＴＴＰプロトコル向けのものである。設計上、従来のウエブブラウザは、クライアントが１つのページから別のページへ移行するときは常に、既存のローカル状態を破棄する。何らかの関連を有する認証データを含む接続が、文書又はページ向けのローカル状態として保持される。したがって、ページ移行の自然の結果として、現行の接続が終了することになる。従来のウエブブラウザのクライアントにより、非ページ状態データをクッキーとして記憶することもできる。これらのクッキーは、サーバーシステムにより割り当てられ、これらのクッキーを操作して、サーバー定義セッションの持続のために必要となる認証済み接続の自律的復元を可能にする情報を記憶することが可能である。このようにしてセッションクッキーにアクセスし、操作することは、従来のウエブブラウザクライアントによって本来的にサポートされているＨＴＴＰプロトコルの使用に、事実上限定される。ウエブソケットのプロトコルは、ウエブソケット接続が確立される最初の接続段階中に通常のＨＴＴＰクッキーの送信を可能にするものではあるが、ウエブソケットの接続上でホストされるさらに高レベルのプロトコルは、これらのクッキーにアクセスしたり、該クッキーを使用したりすることはできない。

したがって、ウエブブラウザクライアントの通常の動作上の性質に適応する状態を安全確実な形で機能的に維持しながら、ウエブブラウザクライアントとサーバーアプリケーションの間でウエブソケット接続及び他の非ＨＴＴＰプロトコル接続を利用できるようにするシステム及び方法に対する必要性が存在する。

従って、本発明の一般的目的は、ウエブブラウザクライアントが、ウエブソケット接続及びその他の非ＨＴＴＰプロトコル接続に関係する状態情報を安全確実に確立し、管理することを可能にするシステム及び方法を提供することである。

本発明においては、上記目的は、クライアントシステム及びリモートサーバーシステムと相互に動作して、分散化されたウエブアプリケーションに対する状態非依存型安全性管理を行うゲートウェイサーバーを提供することによって達成される。クライアントシステム上のウエブクライアントアプリケーションは、該クライアントアプリケーションに対応するローカル記憶個所内に安全管理されたトークンが存在しないウエブブラウザクライアントのユーザに向けて、認証問合せを行って、安全管理されたトークンを取得し、次いで、ゲートウエイサーバーとの間でユーザ信用証明を交換する。次いで、この安全管理されたトークンは、プロトコル専用接続メッセージの中に含めてゲートウェイサーバーへ送信される。該ゲートウェイサーバーは、この接続メッセージの受信に応答して、該接続メッセージを検査することにより、リモートウエブサービスに向けられたウエブソケット接続を開始して、安全管理されたトークンを回復し、この安全管理されたトークンを評価して、ユーザ信用証明を取得し、このユーザ信用証明を安全管理されたトークンに導入し、該接続メッセージをリモートウエブサービスへ送信する。

本発明の利点は、種々のプロトコルを用いて、特に、ウエブソケットの接続上でホストされる非ＨＴＴＰプロトコルを含む意味での種々のプロトコルを用いて、リモートウエブサービスとの認証済みの接続を維持するために、ユーザ信用証明の管理及び利用を効率的に行うことが可能になるという点である。

本発明の別の利点は、多くのエラー及び失敗のシナリオの下で管理が困難になる状態依存性のユーザ情報が、本発明と関連して利用されるゲートウェイサーバーにとって負担にならないという点である。クライアントシステムとゲートウェイシステムとの間での連携関係を通じての状態依存性の情報の管理は、有効かつ安全であり、ゲートウェイサーバーにおけるメモリ及びＣＰＵの必要性を減らし、そのため、性能及び規模特性を高めることになる。さらに、ゲートウェイサーバーとの連携関係によって、種々の標準認証システムに対する単一のインタフェースとして、クライアントシステムがゲートウェイサーバーを利用できるようになり、これによってクライアントシステムの管理が単純化される。

本発明の更なる利点は、クライアントシステムが、ウエブブラウザベースのクライアントアプリケーションを実行すると共に、通常のウエブブラウザの安全管理モデル内の状態情報を保持するという点である。クライアントシステム上での状態情報の格納を、格段に安全管理されたものとする一方で、ゲートウェイサーバーと連携する認証関係が、本質的な認証情報を、通常のクライアントシステムに記憶されるとき及び通常のウエブブラウザの安全管理モデル内に記憶されるときでさえも、安全確実な状態のままとすることを保証する。ゲートウェイサーバーとの間で連携したこの認証関係を実現するのに必要な通信は、最低限のものとなる。認証状態を確立する基礎として使用される安全認証証明は、ウエブブラウザの再開及びセッションの終了にかかわらず存続できるように、ローカルにかつ永続的に記憶される。

本発明のさらに別の利点は、ゲートウェイサーバーと連携する認証関係がウエブソケットプロトコルレベルで有効に確立され、固有のドメイン制約を伴うことなく認証接続の確立が可能になるという点である。認証がウエブクライアントアプリケーションのサイトに関係して制約を受ける一方で、ゲートウェイサーバーのドメイン及び接続されたウエブサービスのドメインに関係するいかなる制約も、ゲートウェイサーバーが実行するサービスアクセス制御により決定されることになる。このサービスアクセス制御は、管理された形で構成される。

本発明の好ましい実施形態のための好ましい動作環境を概略的に示す図である。分散化されたクライアント／サーバーウエブアプリケーションの実行時における本発明の好ましい実施形態を実現するのに適した好ましいクライアント／サーバーシステムを示すブロック図である。本発明の好ましい実施形態に従って、分散されたクライアント／サーバーウエブアプリケーションと連携してクライアント側アプリケーションを実行するために構成されたウエブブラウザクライアントを示す詳細なブロック図を提示する。本発明の好ましい実施形態において実装された状態におけるゲートウェイサーバーの好ましい実装構成を示すブロック図を提示する。本発明の好ましい実施形態によるウエブサービスネットワーク接続を確立する際のウエブブラウザクライアントアプリケーションの初期化及び実行を示すシーケンス図である。本発明の好ましい実施形態によるウエブサービスネットワーク接続を確立する際のウエブブラウザクライアントアプリケーションの初期化及び実行をさらに詳述するシーケンス図である。本発明の好ましい実施形態で使用するための認証トークンを作成する好ましい処理を示すフローチャートである。

本発明は、ウエブブラウザクライアントと遠隔ウエブサービスとの間でリアルタイムにデータを交換しながら、安全な通信チャネルを効率的に認証し、このチャネルを維持するための、分散化されたウエブアプリケーションに対するサポートを提供するものである。本発明の好ましい実施形態は、中間安全管理マネジャとしてゲートウェイサーバーを利用する。また、このゲートウェイサーバーは、好適には、本願の譲受人に譲受されている２０１０年４月３０日出願の、同時継続中の出願「ウエブソケット通信の分散化されたエミュレーションを通じてウエブアプリケーションのサポートを提供するエンタープライズクライアントサーバーシステム及び方法」に記載されている機能も実装することが望ましい。上記出願は、引用により本願に組み込まれる。要約すると、この組み込まれた出願に記載のゲートウェイサーバーは、リモートサーバーシステムによりホストされる、ウエブブラウザベースのクライアントアプリケーションとデータサービスとの間において、ソケット指向の双方向リアルタイム通信を可能にするものである。本発明についての以下の詳細な説明において、１又はそれ以上の図に描かれている同様の部分を示すために同じ参照番号を用いるものとする。

分散化されたウエブアプリケーションの実行を表す本発明１０の好ましい動作環境が、図１に全体的に示されている。従来のクライアントシステム１２、１４は、公衆インターネット、民間イントラネット、その他の通信ネットワーク１６を介して１又はそれ以上のリモートサーバーシステム１８、２０、２２へのアクセスを動作的に行うウエブブラウザベースのクライアントアプリケーションを実行して、双方向でのリアルタイム情報の要求及び受信を行う。典型的な事例では、クライアントシステム１２により実行され、ウエブブラウザクライアントを通じて行われる情報要求は、最初は一次サーバーすなわちソースサーバー１８へ向けられ、次いで、必要に応じて、他の二次サーバー２０、２２との間で、リアルタイムの双方向情報送信接続が確立される。例えば、ソースサーバー１８からウエブページを要求してもよく、このソースサーバー１８は、配信ページを示すユーザインタフェース表示内の適正な指定ウインドウエリア内において、ニュースソースサーバー２０から得られるリアルタイムのニュース記事と、株情報サーバー２２から得られる株価情報とを提示する。本発明の実施及び利用を通じて、クライアントアプリケーションの実行時にウエブブラウザクライアントのコンテキスト内において生じ得るページ移行の間、上記のような情報送信接続を効果的に継続することが可能となる。すなわち、ＨＴＴＰ接続の基礎をなす切断の結果として、能動的ウエブソケット接続が突然終了するが、本発明は、ウエブブラウザクライアントのエンドユーザに対する明らかな中断を伴うことなく、接続の選択的復元を可能にするのに十分なウエブソケット接続レベルで、接続情報の保持及び管理を提供する。

本発明によれば、ウエブブラウザクライアントアプリケーションとリモートウエブサービス間で最終的に確立されるウエブソケット接続の管理に参加するためのゲートウェイサービスが提供される。図２に示されているように、本発明のこの好ましいシステムアーキテクチャ３０は、クライアントコンピュータシステム３２が双方向のウエブソケット接続３４、３６を介してゲートウェイサーバー３８と通信することを可能にする。別個の双方向のウエブソケット接続部４０、４２及び４４、４６が、それぞれをホストしているウエブサービスにアクセスするのに適切なように、ゲートウェイサーバー３８をリモートサーバー４８、５０に接続する。ゲートウェイサーバー３８は、複数のクライアントシステム３２が複数のリモートウエブサービスにアクセスするのを同時にサポートすることができ、リモートサーバー４８、５０の各々は、複数のウエブサービスを提供することができる。代替的な実施形態では、ゲートウェイサーバー３８は、クライアントシステム３２にアクセス可能なウエブサービスを、ローカルに実現することも可能である。ゲートウェイサーバーは、ＬＤＡＰ、Ｋｅｒｂｅｒｏｓ、Ｊａｖａ（登録商標）認証及び認可サービス（ＪＡＡＳ）、或いは、別の標準に基づく信用証明サービスを実行して、直接的に又は外部認証サーバー５２のサポートを得るか、のいずれかにより、認証サービスを実行することが好ましい。

ゲートウェイサーバー３８は、ウエブソケット接続を管理する際に、システム３２のために多数の機能を実行する。これらの機能には、認証トークンの鍵リングをウエブブラウザクライアントアプリケーションと協調して管理することと、ゲートウェイサーバー３８を通される選択プロトコル専用データパケットに対して安全性強化プロキシ処理を行うことと、単一のプロトコル及び１又はそれ以上のリモートサービスにより提供される複数の選択的サービスに適用可能な複数のプロトコルのためのクライアントユーザ認証サービスを行うこととが含まれる。これらの機能を実現するに際して、ゲートウェイサーバー３８は、ゲートウェイサーバー３８内を通過するプロトコルデータパケットの選択的変更に対して責任を負う。これらの好ましい実施形態において、ゲートウェイサーバー３８は、リモートサーバー４８、５０へ送信されるプロトコルデータパケット内に安全性証明を選択的に挿入するように動作する。選択的に返信されるプロトコルデータパケット内に安全性証明トークンが挿入される。現在のところ好ましい実施形態において実現されているように、クライアントシステム３２により記憶されている信用証明トークンは、改竄及び悪用に対して安全性を確保するのに効果的なものとなる。安全性証明がゲートウェイサーバー３８上に存在しているのに対して、これらの信用証明は単に一時的に存在しているにすぎず、そのため、改竄及び悪用に対して同様に安全確実なものとなる。クライアントシステム３２及びゲートウェイサーバー３８は、一緒になって相互に動作し、クライアント３２とリモートサーバーシステム４８、５０との間でのリアルタイム通信における安全確実なユーザ特定と認証を効率的にサポートするものとなる。

さらに詳細なシステムについての実施形態６０が図３に示されている。この好ましい実施形態では、エンドユーザの行為に応答して、ウエブブラウザクライアントアプリケーション６２がクライアントシステム３２上で実行される。典型的には、エンドユーザの入力に基づいて、ウエブクライアントアプリケーション６４を含むウエブページがリモートアプリケーションソースサーバー６６からロードされる。本発明の好ましい実施形態では、ウエブクライアントアプリケーション６４は、ウエブソケットライブラリ６８をロードすることを含むか、あるいは、このロードに対して責任を負う。前述の組み込まれた同時継続中の出願にさらに詳述されているように、ウエブソケットライブラリ６８は、ｐｒｅＨＴＭＬ５対応ウエブブラウザクライアントアプリケーション６２用としてエミュレートされたウエブソケットサービスを提供し、必要に応じて、ｐｒｅＨＴＭＬ５に対応すると共に、ＨＴＭＬ５に完全に対応するウエブブラウザクライアント６２の双方のためのプロトコル専用クライアントライブラリも同様に提供する。

ウエブソケットクライアントライブラリ６８のいずれかの特定の配信に含まれている特定セットのクライアントプロトコルライブラリは、典型的には、ウエブクライアントアプリケーション６４の開発者による設計時の選択、あるいは、ウエブクライアントアプリケーション６４の開発者のために行われる設計時の選択に依存する。ウエブクライアントアプリケーション６４が採用される場合には、該ウエブクライアントアプリケーション６４は、ウエブブラウザクライアント６２のインスタンスによりロードを行うために、ウエブソケットライブラリ６８の特定の事例を指定することが好ましい。ウエブクライアントアプリケーション６４を実行する際に、ウエブソケットライブラリ６８を利用して、ゲートウェイサーバー３８用のウエブソケット接続が確立される。例えば遠隔サーバー４８上でホストされているもののような、遠隔的にホストされているリモートサービス７０に対して、ウエブクライアントアプリケーション６４対応する接続が行われる。

鍵リングライブラリが、ウエブソケットライブラリ６８内に含まれるか、或いは、ウエブソケットライブラリ６８と組み合わされて交互に検索されることが好ましい。該鍵リングライブラリは、ウエブクライアントアプリケーション６４により利用され、ローカルストア７２の１又はそれ以上の事例が確立される。この鍵リングライブラリは、ローカルストア７２事例内において鍵リングのデータ構造を確立するための、及び、鍵リングのデータ構造にアクセスするための、鍵を発見し、鍵を追加し、鍵リングのデータ構造から鍵を除去することを含む機能を提供することによって、ウエブクライアントアプリケーション６４をさらにサポートする。ウエブソケットライブラリ６８が、ＨＴＴＰ５対応ウエブブラウザクライアントアプリケーション６２の固有のウエブソケット能力を用いるものであるか、或いは、プレＨＴＴＰ５対応ウエブブラウザクライアントアプリケーション６２用としてエミュレートされたウエブソケット能力を提供するものであるかどうかに関わらず、上記鍵リングライブラリは、ウエブソケットライブラリ６８と組み合わされてウエブクライアントアプリケーション６４により利用され、安全確実な鍵管理機能を提供することが好ましい。

本発明の好ましい実施形態では、チャットセッションをサポートしたり、リアルタイムのデータフィードを表示したりする特定用途のために、ウエブクライアントアプリケーション６４が設計され、開発される。ウエブクライアントアプリケーション６４の意図された用途に個々に適合するように、個々のウエブクライアントアプリケーション６４は、通信プロトコルの種類を示す識別子、鍵リングデータ構造名、ゲートウェイサーバー識別子、及びリモートウエブサービス識別子によって最初にコード化される。本発明の現在のところ好ましい実施形態では、ゲートウェイ識別子とリモートウエブサービス識別子とは、ＵＲＬ及びポート値として一体にコード化される。この情報は、ウエブクライアントアプリケーション６４が、特定されたウエブサービスに達するのに適合したゲートウェイサーバー３８へ送信を行うための適切で安全なトークンの選択を行うのに十分な情報である。本発明の別の実施形態では、負荷バランスのような目的のために、ゲートウェイサーバー３８によってウエブサービス識別子をさらに分析して、同等のウエブサービス７０を提供する複数のウエブサーバーの中からリモートサーバー４８及びウエブサービス７０を選択できるようにしてもよい。

図４を参照すると、ゲートウェイサーバー３８の実装のための好ましい構成８０が示されている。これらの好ましい実施形態では、クライアントシステム３２とリモートサーバー４８、５０との間でネットワーク接続をサポートするように構成された従来のウエブサーバーシステム上に、ゲートウェイサーバー３８が実装される。機能的には、クライアントネットワークインタフェース８２が、ウエブブラウザクライアントアプリケーション６４を用いてネットワーク接続８４をサポートする。サーバーネットワークインタフェース８６が、リモートサーバー４８、５０及び認証サーバー５２を用いてネットワーク接続をサポートする。同じ又は別の物理的ネットワークインタフェースコントローラを用いて、クライアント及びサーバーのネットワークインタフェース８２、８６を実装してもよい。

認証制御プロセッサ９０及び関連するパケットプロセッサ９２、９４、９６、９８は、ゲートウェイサーバー３８により実行されるアプリケーションサーバー内でホストされたイベント駆動モジュールとして実現されることが好ましい。この好ましい実施形態の実現にあたって、ＡｐａｃｈｅＭｉｎａネットワークアプリケーションのフレームワークが用いられる。クライアントの認可及びプロトコルデータパケットの処理動作を管理する際に、認証制御プロセッサ９０が中央制御装置として機能するようにすることが好ましい。クライアントパケット検査プロセッサ９２は、管理対象プロトコルに関連する着信データパケットを監視し、次いで、検査済みデータパケットと関連するプロトコルの状態及び接続状態を、認証制御プロセッサ９０へ選択的に報告する。プロトコルにより定義されたデータパケット構造に適合した信用証明を含むようにするために、信用証明挿入プロセッサ９４は選択したデータパケットの挿入又は書き換えに対して責任を負う。ゲートウェイサーバー３８へローカルに記憶された管理上確立されたサービスアクセス制御構成の評価に好適には基づいて、挿入された信用証明が認証制御プロセッサ９０により提供されることが望ましい。トークンストアサービスアクセス制御構成を示す例が表１に提示されている。

表１サービスアクセス制御構成（トークン）


<session>

<authentication-scheme>Basic</authentication-scheme>


<realm-name>stompRealm</realm-name>
</session>


<security>
<realm>
<name>stompRealm</name>

<login-module>
<type>ldap</type>
<success>required</success>
<options>
<userProvider>
ldap://ldap-svr/ou=people,dc=example,dc=com
</userProvider>
<userFilter>
(&(uid={USERNAME})(objectClass=inetOrgPerson))
</userFilter>
<authzIdentity>{EMPLOYEENUMBER}</authzIdentity>
</options>
</login-module>
</realm>
</security>


<service>
<accept>https://localhost:9000/keyring</accept>
<type>keyring</type>
<auth-constraint>
<require-role>AUTHORIZED</require-role>
</auth-constraint>
</service>


<service>

<accept>wss://example.com:9000/stomp</accept>
<connect>tcp://stompserver.com:61613</connect>
<type>stomp.proxy</type>

セッションストアサービスアクセス制御構成を示す例が表２に提示されている。

表２サービスアクセス制御構成（セッション）


<session>

<service-domain>.example.com</service-domain>


<authentication-scheme>Basic</authentication-scheme>


<realm-name>stompRealm</realm-name>



<encryption-key-alias>session</encryption-key-alias>

<inactivity-timeout>1800</inactivity-timeout>
</session>


<security>
<realm>
<name>stompRealm</name>

<login-module>
<type>ldap</type>
<success>required</success>
<options>
<userProvider>
ldap://ldap-svr/ou=people,dc=example,dc=com
</userProvider>
<userFilter>
(&(uid={USERNAME})(objectClass=inetOrgPerson))
</userFilter>
<authzIdentity>{EMPLOYEENUMBER}</authzIdentity>
</options>
</login-module>
</realm>
</security>


<service>
<accept>https://www.example.com/session</accept>
<type>session</type>

<auth-constraint>
<require-role>AUTHENTICATED</require-role>
</auth-constraint>
</service>


<service>

<accept>wss://example.com:9000/stomp</accept>
<connect>tcp://stompserver.com:61613</connect>
<type>stomp.proxy</type>
</service>

必要に応じて、認証制御プロセッサ９０は、クライアントシステム３２のユーザへログインチャレンジを提示するようにウエブクライアントアプリケーション６４に命令して、クライアント信用証明を取得すると共に、認証サーバー５２と相互に動作して、返信されたクライアント信用証明を有効化し、対応するサービス関連信用証明並びに暗号化証明書を取得する。管理対象プロトコルパケットの書き変えは、リアルタイムで行われることが好ましい。書き換えられたプロトコルパケットは、ネットワーク内の認証制御プロセッサ９０が決定した位置にあるリモートサーバー４８、５０へ、ネットワークインタフェース８６を通じて送信される。

サーバーパケット検査プロセッサ９６は、管理対象プロトコルに関連する着信データパケットを同様に監視し、次いで、検査済みデータパケットと関連するプロトコルの状態及び接続状態を認証制御プロセッサ９０へ選択的に報告する。プロトコルにより定義されたデータパケット構造に適合し安全なトークンを含むように、トークン挿入プロセッサ９８は選択したデータパケットの挿入又は書き換えに対して責任を負う。挿入されたトークンは、認証制御プロセッサ９０より提供される。基本設定上は、この挿入済みの安全なトークンは、パケット検査プロセッサ９２に取り込まれたトランザクション対応の、同一で安全なトークンである。トークン挿入プロセッサ９８による挿入に先立って、安全管理されたトークン内に埋め込まれたタイムスタンプ値が、認証制御プロセッサ９０の動作により追加又は更新されるようにすることが好ましい。書き換えられたプロトコルパケットは、クライアントネットワークインタフェース８２を介して、対応するクライアントシステム３２へ送信される。

本発明の好ましい実施形態の好ましい処理フロー１１０が、図５に全体的に示されている。ウエブクライアントアプリケーション１１６の実行を直接的又は間接的に要求する１１４ことによって、クライアントシステム３２のエンドユーザは、一般に、ウエブブラウザクライアント１１２を使用する処理１１０を開始する。一般に実行されているように、エンドユーザは、ウエブクライアントアプリケーション１１６に対する参照を含むウエブページのロードを命令する。ウエブブラウザクライアント１１２がこの参照を評価することにより、ウエブクライアントアプリケーション１１６のロード及び実行が結果としてもたらされる。ウエブクライアントアプリケーション１１６の最初の実行の暗黙の結果として、或いは、ウエブブラウザクライアント１１２によりエンドユーザに提示されるグラフィカルユーザインタフェース要素の起動に対する明白な応答として、ログイン要求１１４イベントが行われる。

トークンを記憶する第１の実施形態では、最初のログイン要求１１４がクライアントアプリケーション１１６へ向けられる。ウエブブラウザクライアント１１２を介して認証チャレンジ１１８を提示することによってクライアントアプリケーション１１６はエンドユーザに応答する。認証チャレンジ１１８は、ユーザ識別子とパスワードのタプルとして一般に表される対応するユーザ認証信用証明の入力を要求するログインダイアログとして実現されることが好ましい。これらの信用証明は、エンドユーザにより提供され１２０、次いで、ウエブクライアントアプリケーション１１６へ渡される１２２。ゲートウェイサーバー３８により実行されるとき、安全で、好適にはＨＴＴＰであるによる接続１２４が、ゲートウェイアプリケーションサーバー１２６との間で確立されて、認証用のユーザ信用証明が提示される。この接続１２４は、認証制御プロセッサ９０によって有効に受信され、処理される。この信用証明認証要求メッセージには、ユーザ信用証明が、好適な形態では、認証要求を受けるユーザ役割の特定が含まれることが好ましい。このユーザ役割は、認可の対象となるアクセスの範囲及び性質についての、クライアントアクセス制御の分類付けを定義するものであることが好ましく、典型的には、ウエブクライアントアプリケーション１１６のコード化に際して提供される役割識別子として表される。

セッションを記憶する第２の実施形態では、ログイン要求１１４’がゲートウェイアプリケーション１２６へ向けられる。応答は、ゲートウェイアプリケーション１２６との安全な、好適にはＨＴＴＰである接続１２２’を通じて行われるユーザ認証信用証明の収集及び返信を行うためのログインダイアログ１２０を提示する従来のＨＴＴＰ認証チャレンジ１１８’である。

最初のユーザ信用証明を受信したとき、認証制御プロセッサ９０は、特定されたユーザ役割に関する既知のユーザ識別子及びパスワードのタプルとしての有効性の評価１２８をユーザ信用証明に対して行う。外部のＬＤＡＰサーバー５２又は同等のサーバーと協議することも可能である。次いで、結果メッセージがウエブブラウザクライアント１１２及びウエブクライアントアプリケーション１１６へ有効に返信される１３０、１３０’。認証が失敗した場合には、認証チャレンジ１１８、１１８’が反復される。

トークンを記憶する実施形態において認証が成功すると、ゲートウェイアプリケーション１２６は、ユーザ信用証明を含む安全なトークンをさらに生成し１２８、次いで、記憶１３２するために、この安全なトークンをクライアントアプリケーション１１６へ返信する１３０。トークンを記憶する本発明の好ましい実施形態では、秘密鍵がゲートウェイサーバーアプリケーション１２６により安全確実に保持されている通常の秘密鍵暗号化アルゴリズムを用いて、ユーザ信用証明を暗号化することにより、安全なトークンが生成される。

セッションを記憶する実施形態において認証が成功すると、ユーザ信用証明を含む安全なセッションクッキーも又、生成される１２８。安全なトークンは、信用証明を直接含むのではなく、安全なセッションクッキーに対する参照が含む形で、前述したものと同様に生成される１２８。安全なトークンはクライアントアプリケーション１１６により記憶される１３２が、この安全なセッションクッキーは、ウエブブラウザクライアント１１２へ返信１３０され、該ウエブブラウザクライアント１１２の、ローカル記憶部７２とは通常は区別される通常のローカルなクッキー記憶部に記憶される。

クライアントアプリケーション１１６は、該クライアントアプリケーション１１６に関連付けられたローカルな記憶部に、受信された安全なトークンを記憶する１３２。本発明によれば、安全なトークンの記憶を行う鍵リングデータ構造を含むローカルな記憶部７２の場所が、ウエブクライアントアプリケーション１１６により割り当てられる。ローカルな記憶部７２の場所は、ウエブブラウザクライアント１１２に固有に備えられているか、或いは、ウエブソケットライブラリ６８の実行によるエミュレーションを通じてもたらされるＨＴＭＬ５対応アプリケーションプログラミングインタフェース（ＡＰＩ）を用いる鍵リングライブラリを通じて、割り当てられ、管理されることが好ましい。これらのＡＰＩによって、セッション又はローカルデータのいずれかと見なされるストリングデータの記憶が可能となる。或いは、鍵リングライブラリにより、利用可能な別の技術を使用して、ローカル記憶部７２の場所を実装するようにしてもよい。アドビフラッシュ又はグーグルギアーズ、インターネットエクスプローラにおける「ｕｓｅｒＤａｔａ」の性質、或いは別のウエブブラウザにおけるローカルデータベースＡＰＩ、といったウエブブラウザプラグインを使用してもよい。特に、ローカル記憶部７２の場所へのアクセスは、必ずしも安全が保障されたものではない。ローカル記憶部７２の場所へのアクセスは、一般に、ローカル記憶部７２のこの場所の作成に対して責任を負うクライアントアプリケーション１１６の発信元の範囲のみに制約される。同じ発信元からサービスを受ける別のウエブクライアントアプリケーションが、対応するローカル記憶部７２のこの場所にあるコンテンツにアクセスし、このコンテンツを読み出すことがあり得る。

セッション範囲は、ウエブブラウザクライアント１１２における事象、特に、ウエブブラウザウインドウに表される事象の実行ライフスパンに対応し、さらに、ウエブクライアントアプリケーション１１６のロードに対して責任を負うウエブページドキュメントの発信元サイトに対応する。ウエブブラウザウインドウは、ページ変更が行われたとき、及び、ウエブブラウザクライアントが遮断されたときに終了する。ウエブブラウザの遮断は、一般に、ウエブブラウザクライアント１１２のユーザが指示した実行終了の結果として行われる。ローカル記憶部７２の場所内に割り当てられたセッションの記憶は、対応するウエブブラウザウインドウの終了時にクリアされる。

ローカルな記憶部は、同様に、ウエブクライアントアプリケーション１１６のロードに対して責任を負うウエブページドキュメントの発信元サイトに限定されるが、その他の点では、変わりはない。したがって、ローカルな範囲は不変であり、記憶されたデータを、ウエブブラウザクライアント１１２の複数の実行ライフスパンにわたって使用することが可能となる。ウエブクライアントアプリケーション１１６により明白に消去されるまで、或いは、ローカルな記憶部がウエブブラウザクライアント１１２の機能としてクリアされるまで、鍵値はローカルな記憶部内に保持される。

安全なトークンが記憶される１３２と、次に、接続メッセージ又は同等のメッセージが、クライアントアプリケーション１１６により、リモートサーバー４４上で実行される所望のウエブサービス７０に、ゲートウェイアプリケーション１２６を介して送信１３４される。例としてシンプルテキスト指向メッセージプロトコル（ＳＴＯＭＰ）について考えると、ログイン要求１１４は、クライアントアプリケーション１１６のローカルな実行を介して行われる、ウエブソケットライブラリ６８に含まれているＳＴＯＭＰプロトコル専用のクライアントライブラリによりサポートされたＳＴＯＭＰ対話の開始を求めるユーザ要求を表すものとなる。ＳＴＯＭＰプロトコル専用クライアントライブラリは、ウエブクライアントアプリケーション１１６が、ゲートウェイアプリケーション１２６を介して、適切にフォーマットされたＳＴＯＭＰメッセージを、遠隔ＳＴＯＭＰウエブサービス７０と交換することを可能にする。本発明に適合させることができる他の非ＨＴＴＰプロトコルとしては、拡張可能メッセージング及びプレゼンスプロトコル（ＸＭＰＰ）、インターネット中継チャット（ＩＲＣ）、ＡＯＬインスタントメッセージング（ＡＩＭ）、及びスカイプチャットのようなチャットプロトコルや、アドバンストメッセージキュープロトコル（ＡＭＱＰ）、シンプルテキスト向けメッセージングプロトコル（ＳＴＯＭＰ）、及びＴｉｂｃｏＲｅｎｄｅｚｖｏｕｓのようなメッセージングプロトコル、オープンゲームプロトコル（ＯＧＰ）及びバーチャルネットワークコンピューティング（ＶＮＣ）のようなゲーミング用及びメディア用プロトコルが挙げられるが、これらに限定されるものではない。

本発明の好ましい実施形態においては、安全なトークンがゲートウェイアプリケーション１２６に送信されるように、接続メッセージ１３４が修正される。この接続メッセージは、典型的にはプロトコル専用データパケットとして実現され、本来的にはクリアテキスト内にユーザ信用証明を記憶するものとされている、定義済みユーザ名フィールドとパスワードフィールドとを含む。接続メッセージは、ユーザ信用証明の代わりに、トークンマーカー及び安全なトークンを記憶するように、修正することが好ましい。ＳＴＯＭＰ接続メッセージの場合には、このトークンマーカー及び安全なトークンは、接続データパケットのパスワードフィールド内に記憶される。トークンマーカーは、認証制御プロセッサ９０に知られており、修正されたプロトコルパケットの特定に用いられる「マジックナンバー」であることが好ましい。トークンの記憶とセッションの記憶のための安全なトークンの種類を区別するためには、異なるトークンマーカーが利用される。

セッションを記憶する実施形態では、接続１３４は、ＨＴＴＰ接続として開始され、これによって、適用可能なセッションクッキーの、ゲートウェイサーバー３８への自動転送がもたらされる。次いで、ＨＴＴＰ接続は、ウエブソケット接続へグレードアップされる。接続メッセージは、ウエブソケット接続が確立されたときに転送される。従って、トークンを記憶する実施形態の場合には、安全なトークン内に埋め込まれ、次いで暗号化されることになるユーザ信用証明が、接続メッセージに直接含まれることになる。セッションを記憶する実施形態では、接続メッセージ内に埋め込まれた安全なトークンは、認証制御プロセッサ９０が、ＨＴＴＰプロトコルから配信されたセッションクッキーをウエブソケット接続メッセージに一意に関連付けることを可能にする、セッションクッキーへの安全な参照を含む。

ゲートウェイサーバーアプリケーション１２６による受信があったとき、データパケットが、パケット検査プロセッサ９２による検査のためのプロトコルに基づいてフィルタされる。管理された状態で確立されたネットワークパケットフィルタ構成により定義された管理対象プロトコルに対して、接続データパケットを特定するための検査が行われ、トークンマーカーが発見された場合には、安全なトークンをさらに探索して抽出し、パケットプロトコルの識別子と安全なトークンのコピーとを認証制御プロセッサ９０に提供する。安全なトークンの有効性は、この安全なトークンを復号することと、回復されたユーザ信用証明を認証することによってチェックされる。

この安全なトークンから直接的又は間接的に回復されたユーザ信用証明は、信用証明挿入プロセッサ９４に提供される。接続データパケットが、ユーザ信用証明により書き換えられて１３６、プロトコルに準拠する、修正された接続メッセージが生成される。ＳＴＯＭＰ接続メッセージの場合には、ユーザ信用証明は、ユーザ名フィールド及びパスワードフィールドに書き込まれる。次いで、この修正された接続メッセージは、リモートウエブサービス７０へ送信される１３８。安全なトークンのコピーが、クライアントアプリケーション１１６に返信された接続確認応答メッセージ１４０内に挿入される。さらなるトランザクションメッセージと、ＳＴＯＭＰプロトコルの場合の対話の伝達とが送受信される１４２。

好ましいことであるが、安全なトークンが、ローカル記憶部７２のうちの局所的な範囲内に記憶される場合には、認証チャレンジ１１８の反復なしに、後続するログイン要求１４４を終了させることができる。ログイン要求１４４は、接続の意図的終了又はクライアントアプリケーション１１６の意図的終了の後に行われるようにしてもよい。ログイン要求１４４は又、双方向送信トランザクションメッセージ１４２のために使用されるウエブソケット接続に基づくＨＴＴＰセッションの解除に起因して暗黙のうちに行われてもよい。ＨＴＴＰセッションの解除は、ユーザが命令したページ変更のような、ウエブブラウザクライアントにより実行される明白な行為の結果として生じる場合もあるし、クライアントアプリケーション１１６の進行中の実行の結果として間接的に生じる場合もある。いずれの場合にも、ＨＴＴＰセッションの解除事象がクライアントアプリケーション１１６により認識され、クライアントアプリケーション１１６のプログラムされた実行に依存して、ウエブソケット接続を自動的に再確立するためにログイン要求１１４が行われるようにしてもよい。

ログイン要求１４４が受信されたとき、ウエブクライアントアプリケーション１１６は、対応する安全なトークンの有無について、ローカル記憶部７２のチェックを行う１４６。このトークンの検査は、ログイン要求１４４により必然的に参照される同じサイトに対応するローカル記憶部７２の場所において実行される。トークンの検査は、さらに、ウエブクライアントアプリケーション１１６により提供される鍵リング識別子に対して実行される。有効な安全トークンが発見されなかった場合には、ウエブクライアントアプリケーション１１６は、認証チャレンジ１１８、１１８’の実行に進む。安全トークンが発見され、有効なものであれば、特に期限切れ或いは無効とマークされていなければ、この安全トークンは、接続メッセージ１４８の一部として提供される。前述したように、ゲートウェイサーバーアプリケーション１２６によって安全なトークンが特定され、遠隔ウエブサービス７０への送信１５２が行われる前に、プロトコル適合信用証明が接続データパケット内に挿入される１５０。返信接続確認応答メッセージが、好適には、トランザクション対応の安全トークンを挿入された形で、クライアントアプリケーション１１６に返される１５４。ウエブサービス接続が確立されていることを条件として、トランザクションメッセージの送受信１５６が行われる。

本発明の好ましい実施形態では、安全なトークンは、改竄及び悪用に曝されるのを減少させるため、タイムスタンプ及びシーリングの双方を行う。シールされたタイムスタンプ付きトークンの使用及び管理について説明する処理フロー１７０が、図６に示されている。上記のように、最初のログイン要求１７２に応答して、認証チャレンジ１７４が、ユーザ信用証明をウエブクライアントアプリケーション１１６に提供する。鍵リングが現在のユーザ及びドキュメントのサイトに対応する現在の安全なトークンを含んでいない場合には、認証チャレンジ１７４は適切なものとされる。ユーザ信用証明及びユーザ役割をユーザに関連付けられたものとして提示するために、トークン要求１７６が、クライアントアプリケーション１１６によってゲートウェイサーバーアプリケーション１２６に送出される。認証が成功すると、認証制御プロセッサ９０によりセキュアトークンが生成され１７８、このトークンが返信される１８０。前述したように、クライアントアプリケーション１１６は、クライアントアプリケーション１１６に関連付けられたローカルな記憶部内に、受信した安全なトークンを記憶する。

図７を参照すると、タイムスタンプを含む安全なトークンを生成する好ましい処理２４０が示されている。トークンを記憶する実施形態においては、ユーザ信用証明により提供されるユーザ名２４２とパスワード２４４が、データオブジェクト内に一緒に記憶され、暗号化され２４６、シールされた安全な信用証明トークン２４８が生成される。使用される暗号化方式は、秘密鍵がゲートウェイサーバーアプリケーション１２６により安全確実に保持されている、秘密鍵対称暗号化であることが好ましい。クライアントの安全性に対する侵害が、クライアントの記憶するシールされたトークン２４８の安全性についての妥協を強いるものとなることを防止するために、この秘密鍵は、クライアントシステム３２に記憶したり、該クライアントシステム３２からアクセスできる状態にすることはない。基本的には、現在時刻に関連する生成済みのタイムスタンプのデータ値２５０が、その後信用証明トークン２４８に添付され、暗号化されて２５２、タイムスタンプ付きのトークン２５４が生成される。秘密鍵がゲートウェイサーバーアプリケーション１２６により再度安全に保持されている場合には、別の秘密鍵の評価した対称暗号化が、タイムスタンプの暗号化２５２のために使用されるようにすることが好ましい。

次いで、マーカー２５６を好ましくは先頭に追加して２５８、安全なトークン２６０を最終的に作成し、マーカー２５６をクライアントアプリケーション１１６に返信し１８０、ローカル記憶部７２内に存在する対応する鍵リング記憶部２６２に記憶する。マーカー２５６がユーザ名又はパスワードの一部として現れることがありそうにない文字列その他の値であれば、マーカー２５６の構成は重要ではない。マーカー２５６の値はパケット検査プロセッサ９２により保持され、通常のユーザ信用証明と認可トークンとの区別が可能となる。最初に生成された１７８安全なトークンと、後で更新された該安全なトークンのコピーとを区別するために、マーカー２５６の値が用いられる。認証チャレンジと関連して生成された１７８最初の安全なトークンが、空のタイムスタンプ２５０フィールドを用いて生成されることが好ましい。

セッションを記憶する実施形態については、安全なトークンの生成は実質的に同様である。こ場合の生成は、秘密鍵で暗号化されたユーザ信用証明データオブジェクトを含むセッションクッキー２６４が暗号化２４６により生成される、という点で異なる。関連付けられた従来のクッキーストア２６６に記憶するために、セッションクッキー２６４は、ＨＴＴＰヘッダの形でウエブブラウザクライアント１１２へ返信される。暗号化２４６によって、信用証明トークン２４８として使用されるセッションクッキー参照が、さらに生成される。このクッキー参照は、最近受信され、かつ、バッファされたＨＴＴＰヘッダの検査にあたって、対応するセッションクッキー２６４の一意の特定及び回復を可能にするのに十分に一意の数値化された識別子である。このセッションクッキーの参照は、タイムスタンプ２５０を用いて暗号化される２５２と共に、その後、安全なトークン２６０の作成のために用いられる。

次いで、プロトコル専用接続要求メッセージが、ゲートウェイサーバーアプリケーション１２６へ送信される１８２。接続メッセージを作成する際に、安全なトークンがクライアントアプリケーション１１６により選択され、接続メッセージ内に埋め込まれる。マーカー２５６の値に基づいて、選択に対する優先順位が、他の点では同等である最初の安全なトークン２６０に優先してタイムスタンプ済みのセキュアトークン２６０に与えられる。サービスアクセス制御の評価に基づいて、クライアントアプリケーション１１６による接続要求が、認証制御プロセッサ９０によって条件付きで受け付けられる。安全なトークンの二重復号化を介して接続メッセージからタイムスタンプ値及びユーザ信用証明が回復され、トークンを記憶する形態の場合には直接的に、セッションを記憶する形態の場合には間接的に、ユーザ信用証明が獲得される。次いで、これらのユーザ信用証明は、接続要求に特定された役割のために認証サーバー５２に対して認証される。

また、接続認証は、安全なトークン２６０内に埋め込まれたタイムスタンプ値により定義された時間内に、パケット検査プロセッサ９２が接続要求を受信することを必要とするものであることが好ましい。生成されたタイムスタンプデータ値２５０は、典型的には、３０秒〜３０分のオーダーの持続時間（time-to-live）値を表すものであることが好ましい。一般に、この持続時間値は、エンドユーザとウエブサービスとの間の或る程度の最小相互作用期間をカバーするように経験的に選択される。マーカー２５６値が安全なトークン２６０を初期の安全なトークン２６０として特定した場合には、接続要求は適時のものであると推定される。そうでない場合には、タイムスタンプ値は、パケット検査プロセッサ９２による接続メッセージの受信時刻に応じて直接的又は間接的に有効と見なされる。

次いで、回復したユーザ信用証明は、リモートウエブサービス７０への移行１８４に先立って、プロトコル専用接続データパケット内に挿入される。リモートウエブサービスから接続確認応答メッセージが受信されたとき、安全なトークンの更新済みコピーが接続確認応答メッセージに挿入され、クライアントアプリケーション１１６に返信されるようにすることが好ましい。安全なトークンは、該安全なトークン内に埋め込まれたタイムスタンプ値を更新し、又は追加することによって更新される。安全なトークンの挿入は、クライアントアプリケーション１１６への送信に先立って、トークン挿入プロセッサ９８により実行される。更新済みの安全なトークンは、受信されると、ローカル記憶部７２内に存在している対応する鍵リング記憶部２６２内に記憶される。その後、トランザクションメッセージが送信され、受信される１８６ことになる。

その後の当然に予定されているか、明白なログイン要求１９０に応答して、クライアントアプリケーション１１６は、ローカルな鍵リング記憶部２６２にアクセスし、対応する安全なトークンを検索する２６０。初期の安全なトークンとタイムスタンプ済みの安全なトークンとの双方が存在している場合には、タイムスタンプの期間が期限切れでない限り、タイムスタンプ済みの安全なトークンの方が選択される。タイムスタンプの満了期間は、管理された状態で確立されていることが望ましいが、そうでない場合には、タイムスタンプは定まった時間値であってもよい。その場合には、タイムスタンプ済みの安全なトークンが鍵リング記憶部２６２に最後に追加されるか、又は更新が行われた時刻に基づいて、タイムスタンプ済み安全なトークンの有効性を決定することができる。タイムスタンプ済みの安全なトークン２６０が存在していないか、有効でなければ、最初の安全なトークン２６０が選択される。接続メッセージ１９２が、選択された安全なトークン２６０と共にゲートウェイサーバーアプリケーション１２６へ送出される。

パケット検査プロセッサ９２及び認証制御プロセッサ９０の動作によって、更新された１９４タイムスタンプ値を含む安全なトークン２６０のコピーが作成される。挿入済みユーザ信用証明を含むゲートウェイアプリケーション１２６によって、変更済み接続メッセージ１９６が送出される。更新された認証トークン２６０は、次いで接続確認応答メッセージの形でクライアントアプリケーション１１６に返信され１９６、次いで、ローカルな鍵リング記憶部２６２において記憶される。接続が確立されていることを条件として、トランザクションメッセージの交換２００が行われるようにしてもよい。

好適には、タイムスタンプ済みの安全なトークン２６０がクライアントアプリケーション１１６により定期的に更新されながら、クライアントアプリケーション１１６が実行を継続するようにする。ローカルな鍵リング記憶部２６２に記憶された認証トークン２６０の満了期間を継続して監視するために、期間満了タイマーが稼働する２２０。個々の認証トークン２６０がローカルな鍵リング記憶部２６２に最後に追加され、又は更新された時刻に基づいて、期間満了タイマー２２０が満了期間を監視することが望ましい。タイムスタンプされた安全なトークン２６０が満了期限に近づいている場合には、期間満了タイマー２２０は、ゲートウェイサーバーアプリケーション１２６への、対応するトークン更新メッセージ２２２の送出を開始する。このトークン更新メッセージ２２２は、タイムスタンプされた安全なトークン２６０を埋め込んだものである。認証トークン２６０が抽出され、更新され２２４、トークン更新応答メッセージ内に挿入され、返信される２２６。トークン更新応答メッセージが受信されると、更新済みの安全なトークン２６０がローカルな鍵リング記憶部２６２に記憶される。

別の実施形態では、認証制御プロセッサ９０は、クロスドメインの単一のサインオン認証システムをサポートするように動作するものとしてもよい。認証トークン２６０の管理及び使用がウエブソケットプロトコルサポートレベルで機能的に生じるので、ネイティブなウエブブラウザクライアントアプリケーション６２により強制される、ＨＴＴＰベースの接続の或る種のドメイン制限による制約は回避される。ゲートウェイサーバー３８とウエブサービス７０とは、互いに異なるドメイン内に存在するようにしてもよく、特にソースサーバー６６のドメインとは異なるドメイン内に存在するようにしてもよい。

単一のサインオンをサポートするために、複数のウエブクライアントアプリケーション１１６がコード化されて、安全なトークンが同じ名称の鍵リング内に記憶される。参照される同じ発信元の範囲内でウエブクライアントアプリケーション１１６が実行されることを条件として、同じ名称の鍵リングは同じローカル記憶部７２内の場所で共有されることになる。複数のウエブクライアントアプリケーション１１６のうちのいずれか１つのアプリケーションのために最初に作成された安全なトークンは、同様の目的をもった他のログイン要求１１４、１１４’によっても自動的に使用されることになる。単一のサインオンユーザ信用証明が個々のプロトコル専用ウエブサービスに対して有効であれば、複数のウエブサービスへのアクセスを可能にするために単一の認可チャレンジが必要とされるだけである。セッションを記憶する実施形態の場合には、セッションクッキーの宣言された範囲内のいずれの参加ゲートウェイサーバー３８に対しても、単一のサインオンが暗黙のうちにサポートされる。セッションクッキーは、クッキーの定義された範囲の通信時に送信されるＨＴＴＰヘッダの一部として自動的に送信される。

別の実施形態では、認証制御プロセッサ９０の指示の下で挿入されたユーザ信用証明は、ウエブクライアントアプリケーション１１６により提供される認証トークン２６０内に含まれているユーザ信用証明である必要はない。むしろ、提供されるユーザ信用証明及び役割の特定に基づいて、認証制御プロセッサ９０は、接続メッセージ内へ挿入するための異なるセットのユーザ信用証明を選択してもよい。管理された状態で行われるクライアントアクセス制御の一部として、１又はそれ以上の、代替的なユーザ信用証明が、ゲートウェイサーバー３８に直接的あるいは間接的に記憶されたり、アクセスされたりして、認証制御プロセッサ９０により評価され、使用されるようにしてもよい。特に、ゲートウェイサーバー３８は、ケルベロス（Kerberos）認証システム５２と相互に動作して、ユーザ信用証明がウエブサービス７０に提示される度に、単一使用チケットベースのサービス要求が与えられるようにするために、使用される回数を生成するようにしてもよい。

以上、状態関連情報の管理を通じてウエブクライアントとウエブサービスとの間でのリアルタイムのデータ交換を可能にするシステム及び方法について説明した。本発明の好ましい実施形態についての上述の説明に照らして、上記開示された実施形態の多くの変更及び変形は当業者により容易に理解されるものである。したがって、添付の請求項の範囲内において、特に、上記に記載した以外の違った形で本発明の実施が可能であることが理解されるべきである。

８２ネットワークインタフェース
８６ネットワークインタフェース
９０認証制御プロセッサ
９２パケット検査プロセッサ
９４信用証明挿入プロセッサ
９６パケット検査プロセッサ
９８トークン挿入プロセッサ

Claims

非ＨＴＴＰ通信プロトコルを用いるウエブアプリケーションのために状態に依存しない安全性管理を提供するコンピュータで実行される方法であって、
ａ）クライアントシステム上でウエブブラウザクライアント内において実行されるクライアントアプリケーションから、通信プロトコル識別子により特定され、リモートウエブサービスへ向けられるウエブソケット接続を開始する第１の開始ステップを含み、前記第１の開始ステップは、
i)前記通信プロトコル識別子に対応する安全なトークンが前記クライアントアプリケーションに対応するローカル記憶部内に存在していない場合、前記ウエブブラウザクライアントのユーザへ向けて認証チャレンジを実行するステップであって、第１のユーザ信用証明を取得し、前記第１のユーザ信用証明をゲートウェイサーバーへ送信し、前記安全なトークンを前記ゲートウェイサーバーから受信し、前記安全なトークンを前記ローカルストアインスタンス内に記憶する前記認証チャレンジを実行するステップと、
ii)前記安全なトークンを前記ローカル記憶部から取得するステップと、
iii)前記通信プロトコルの識別子専用プロトコルであり、且つ、前記安全なトークンを含む第１の接続メッセージを前記ゲートウェイサーバーへ送信する送信ステップと、を含み、
ｂ）前記第１の接続メッセージの受信に応答して、前記リモートウエブサービスへ向けられるウエブソケット接続を前記ゲートウェイサーバーから開始する第２の開始ステップをさらに含み、前記第２の開始ステップは、
i)前記安全なトークンを特定するために前記第１の接続メッセージを検査するステップと、
ii)第２のユーザ信用証明を取得するために前記安全なトークンを評価するステップと、
iii)前記安全なトークンを置き換える時に、前記第１の接続メッセージに対応する第２の接続メッセージ内へ前記第２のユーザ信用証明を挿入するステップと、
iv)前記第２の接続メッセージを前記リモートウエブサービスへ送信するステップと、
を含むことを特徴とするコンピュータで実行される方法。
前記通信プロトコル識別子は、前記ウエブソケット接続上でホストされる非ＨＴＴＰプロトコルに対応する、請求項１に記載のコンピュータ実行方法。
前記安全なトークンは、前記第１のユーザ信用証明の暗号化されたコピーを含む、請求項２に記載のコンピュータ実行方法。
前記第２のユーザ信用証明は、前記第１のユーザ信用証明において前記安全なトークンを復号化により取得されるものである、請求項３に記載のコンピュータ実行方法。
前記安全なトークンはタイムスタンプを含み、前記タイムスタンプは前記安全なトークンが無効であるかどうか判断できるものであり、前記安全なトークンが無効である場合には、ローカル記憶部内に前記安全なトークンが存在していないと決定する、請求項２に記載のコンピュータ実行方法。
前記決定するステップは、i)前記ローカル記憶部内に記憶されている前記安全なトークンを前記タイムスタンプの期限の間、監視するステップと、ii)前記タイムスタンプの更新のために前記安全なトークンを前記ゲートウェイサーバーへ送信するステップと、iii)前記ゲートウェイサーバーによって更新された前記安全なトークンを前記ローカル記憶部内に記憶するステップとを含む、請求項５に記載のコンピュータ実行方法。
シールされたオブジェクトを生成するための、前記第１のユーザ信用証明の秘密鍵の暗号化と、前記シールされたオブジェクト及び前記タイムスタンプから成る公開鍵の暗号化とによって、前記安全なトークンを前記ゲートウェイサーバーにより生成するステップをさらに含む、請求項６に記載のコンピュータ実行方法。
前記第２のユーザ信用証明は、前記第１のユーザ信用証明において前記安全なトークンを復号化することにより取得されるものである、請求項７に記載のコンピュータ実行方法。
前記安全なトークンは複数の通信プロトコル識別子に対応する、請求項８に記載のコンピュータ実行方法。
クライアントシステム及びリモートサーバーシステムにより連携して実行される分散化されたウエブアプリケーションに対して状態に依存せずに安全性についての認可を提供するゲートウェイサーバーであって、
前記ゲートウェイサーバーは、
ａ）通信ネットワークを介して、クライアントシステム上のウエブブラウザクライアントにおいてクライアントアプリケーションを実行するように構成されたクライアントシステムと、ウエブサービスを実行するように構成されたリモートサーバーに結合可能なコンピュータサーバーシステムと、
ｂ）認証制御プロセッサ、パケット検査プロセッサ、及び、信用証明挿入プロセッサを含み、前記コンピュータサーバーシステムによって実行されるウエブサーバーと、
を備え、
前記認証制御プロセッサは、前記クライアントアプリケーションにより提供される第１のユーザ信用証明を受信し、該第１のユーザ信用証明を有効化したとき、安全なトークンを生成するように動作し、
前記認証制御プロセッサは、前記クライアントアプリケーションに関連付けられた範囲内にある前記クライアントシステム上のローカル記憶部内に前記安全なトークンを記憶するように前記クライアントアプリケーションと相互に動作し、
前記パケット検査プロセッサは、前記クライアントアプリケーションにより提供され前記安全なトークンを埋め込んだ接続メッセージに応答して、前記接続メッセージを検出すると共に、前記安全なトークンを前記認証制御プロセッサへ提供するように動作し、
前記認証制御プロセッサは前記安全なトークンに対応する第２のユーザ信用証明を回復するように動作し、
前記信用証明挿入プロセッサは、前記認証制御プロセッサに応答して、前記第２のユーザ信用証明を前記接続メッセージ内へ挿入するように動作し、
前記ウエブサーバーは前記接続メッセージを前記リモートサーバーへ送信するように動作することを特徴とするゲートウェイサーバー。
前記認証制御プロセッサは、前記安全なトークンを生成する際に前記第１のユーザ信用証明を暗号化し、前記第２のユーザ信用証明は前記第１のユーザ信用証明である、請求項１０に記載のゲートウェイサーバー。
前記認証制御プロセッサは、前記安全なトークンを生成する際に前記第１のユーザ信用証明を暗号化し、前記第２のユーザ信用証明は、前記第１のユーザ信用証明との所定の対応関係に基づいて回復される、請求項１０に記載のゲートウェイサーバー。
前記認証制御プロセッサは、前記第１のユーザ信用証明を暗号化して、前記安全なトークンの生成と連携してセッションクッキーを提供し、さらに、前記認証制御プロセッサは、前記クライアントシステム上の前記ウエブブラウザクライアントを介して前記セッションクッキーを記憶し、
前記安全なトークンは、前記セッションクッキーと前記安全なトークンとの間の所定の対応関係を確立するセッションクッキー識別子を含み、
前記第２のユーザ信用証明は、前記所定の対応関係に基づいて前記認証制御プロセッサにより回復される、請求項１０に記載のゲートウェイサーバー。
前記ウエブサーバーは、前記ウエブサービスから提供される接続確認応答メッセージを前記クライアントアプリケーションへ返信し、さらに前記ウエブサーバーは前記認証制御プロセッサに応答するトークン挿入プロセッサをさらに備え、
前記認証制御プロセッサは前記クライアントアプリケーションへ戻る前に、前記安全なトークンのコピーを前記接続確認応答メッセージ内へ挿入し、
前記クライアントアプリケーションは、前記クライアントアプリケーションに関連付けられた前記範囲内にある前記クライアントシステム上の前記ローカル記憶部内の前記安全なトークンの前記コピーの記憶を行う、請求項１０に記載のゲートウェイサーバー。
前記認証制御プロセッサは、限定された有効期間を表すタイムスタンプを前記安全なトークンのコピーの中に含ませ、さらに、前記認証制御プロセッサは、前記タイムスタンプに基づいて前記接続メッセージを条件付きで受け付ける、請求項１４に記載のゲートウェイサーバー。
前記認証制御プロセッサは、前記安全なトークン内の第１のマーカー値と、前記安全なトークンのコピー内の第２のマーカー値とを提供し、
前記第１及び第２のマーカー値は、前記安全なトークンが前記タイムスタンプを含むかどうかを特定し、
前記安全なトークンのコピーは、前記接続メッセージ内の前記安全なトークンに対する優先順位で前記クライアントアプリケーションにより提供される、請求項１５に記載のゲートウェイサーバー。