(57)【要約】【課題】  クライアントセッションフェイルオーバーを提供する。【解決手段】本発明の一実施形態では、クライアントセッションフェイルオーバーを提供する方法であって、セキュリティアサーション（security assertion：セキュリティ表明）を使用し、それによりクライアントとのセッションを再確立し、クライアントがフェイルオーバーサーバにフェイルオーバーできるようにすることを含む。この方法は、セキュリティアサーションを発行する第１のサーバとフェイルオーバーサーバの間に信頼関係を確立することも含む。【選択図】図２
2004206695.tif 000002
【特許請求の範囲】
【請求項１】
クライアントセッションフェイルオーバーを提供する方法であって、
セキュリティアサーションを使用することであって、それによりクライアントとのセッションを再確立し、前記クライアントがフェイルオーバーサーバにフェイルオーバーすることができる、該セキュリティアサーションを使用すること
を含むクライアントセッションフェイルオーバーを提供する方法。
【請求項２】
前記セキュリティアサーションを発行する第１のサーバと前記フェイルオーバーサーバの間に信頼関係を確立すること
をさらに含む請求項１記載のクライアントセッションフェイルオーバーを提供する方法。
【請求項３】
前記クライアントは、前記セキュリティアサーションを発行する第１のサーバに障害が発生したことに応答して、前記フェイルオーバーサーバへのフェイルオーバーを行う
請求項１記載のクライアントセッションフェイルオーバーを提供する方法。
【請求項４】
前記クライアントとのセッションを再確立して、前記クライアントによるファイルオーバーサーバへのフェイルオーバーを許可する前に、前記セキュリティアサーションを検証すること
をさらに含む請求項１記載のクライアントセッションフェイルオーバーを提供する方法。
【請求項５】
クライアントセッションフェイルオーバーを提供する装置であって、
クライアントと、
セキュリティアサーションを前記クライアントに提供するように構成された第１のサーバと、
前記セキュリティアサーションに基づいて、前記クライアントとのセッションを再確立するように構成されたフェイルオーバーサーバと
を備えたクライアントセッションフェイルオーバーを提供する装置。
【請求項６】
前記第１のサーバおよび前記ファイルオーバーサーバは信頼関係を有する
請求項５記載のクライアントセッションフェイルオーバーを提供する装置。
【請求項７】
前記クライアントは、前記セキュリティアサーションを発行する前記第１のサーバに障害が発生したことに応答して、前記フェイルオーバーサーバへのファイルオーバーを行う
請求項５記載のクライアントセッションフェイルオーバーを提供する装置。
【請求項８】
前記フェイルオーバーサーバは、前記クライアントとのセッションを再確立して、前記クライアントによるフェイルオーバーサーバへのフェイルオーバーを許可する前に、前記セキュリティアサーションを検証する
請求項５記載のクライアントセッションフェイルオーバーを提供する装置。
【請求項９】
フェイルオーバーサーバがクライアントセッションを再確立できるようにする方法であって、
第１のサーバにより、セキュリティアサーションをクライアントに発行することであって、それによりクライアントとのセッションを確立する、該セキュリティアサーションをクライアントに発行すること、
前記セキュリティアサーションを検証することであって、それによって前記クライアントとのセッションを再確立し、前記クライアントによるファイルオーバーを許可する、該セキュリティアサーションを検証すること
とを含むフェイルオーバーサーバがクライアントセッションを確立できるようにする方法。
【請求項１０】
クライアントが別のサーバにフェイルオーバーできるようにする方法であって、
セキュリティアサーションを受け取り、サーバとのセッションを確立すること、
前記サーバに障害が発生したことに応答して、前記セキュリティアサーションを含む要求を第２のサーバに送ることであって、それによって前記第２のサーバとのセッションを再確立する、該要求を第２のサーバに送ることと
を含むクライアントが別のサーバにフェイルオーバーできるようにする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、包括的に、クライアントサーバコンピューティング技術に関する。
本発明の実施形態は、特に、クライアントセッションフェイルオーバーを提供する方法および構造に関する。
【背景技術】
【０００２】
環境では、サーバに障害が発生した場合に、認証済みのクライアントセッション状態を失わずにいることが重要な務めである。
これは特に、クライアントが人間ユーザへのインタフェースとして動作しているアプリケーションの場合について言える。
ユーザのアクティブセッション中にサーバに障害が発生すると、そのセッションは失われ、これによりユーザが待機サーバまたはプロセッサファーム内の別のサーバに対して再度認証する必要がある。
これはユーザの心証を悪くし、さらに悪いことには、ユーザセッションデータが失われる可能性もある。
【０００３】
クライアントセッションフェイルオーバーは実施が複雑であり、往々にして、この耐故障性の振る舞いを提供することを目的とする解決策は、非耐故障性の機構に頼っているため、それ自体障害の対象である。
さらに、セッションを保存する解決策はさらなるネットワーク通信、処理、および格納が必要であるため、クライアント、サーバ、または両方の装置に過度な負担をかけ得る。
【０００４】
通常、採用される現行の手法は、サーバがセッション管理を担う専用プロセスを有するというものである。
このセッションマネージャプロセスは冗長化され、ネットワーク全体に分散される。
各ユーザのコンテキスト状態がセッションマネージャ内で存続し、次に、リアルタイムあるいは間隔を置いてその他のセッションマネージャに複製される。
特定のセッションマネージャサーバに障害が発生した場合は、その他のサーバがユーザのセッション状態を所有することになる。
この現行の解決策に伴う問題は、各ユーザのセッションをすべての冗長セッションマネージャに複製するために多大な量のネットワークコールが求められることであり、限られた帯域の消費につながることである。
さらに、この種の解決策は、ネットワーキングノードにわたって水平にも、また地理にわたって垂直にも拡張性があまりない。
【０００５】
この問題に採用されることが多い別の現行の解決策は、クラスタリングの使用である。
クラスタリングは、すべて同じオペレーティングシステム、関係データベース、およびアプリケーションを有するいくつかのサーバのグループ化に関わる。
このサーバのグループは論理的に１つとみなされる。
クラスタを管理するソフトウェアは、クライアント要求の分配およびシステムの同期を保つ責任を負う。
サーバに障害が発生した場合、クラスタ中のその他のサーバがクライアント状態情報、アプリケーションおよび関連データベースを有しており、障害が発生していないかのように処理を続けることができる。
この種の解決策は、その意図する目的に適しているが、複製ハードウェアおよびソフトウェア資源が必要とされるため、実施が高価である。
【０００６】
セッションを保持する他の現行の解決策は、クライアントにセッション情報を格納し、通常のクライアント／サーバ通信中にこの情報をサーバアプリケーションに伝えることに依拠している。
このシナリオでは、サーバがステートレスであるため、セッション情報の損失につながるサーバフェイルオーバーは問題ではない。
しかし、この手法ではクライアントがセッション情報を管理するロジックを保有しなければならないため、この手法には欠点がある。
セッション状態がクライアントに格納される場合、セッション状態を要求毎にサーバに伝送しなければならない。
多くの場合、サーバ応答は、変更されたにせよそうでないにせよ、セッション状態のさらに別のコピーを含む。
これは、通信オーバヘッドを大幅に増大させる。
さらに、すべてのセッション情報をクライアントに格納する場合は、セッション情報の機密性および保全性に対処してセキュアなシステムを確保するために、クライアント側でより複雑な処理が求められる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、現行の手法および／または技術は特定の機能に制限され、かつ／または様々な制約を受ける。
【課題を解決するための手段】
【０００８】
これより、各種実施形態の少なくともいくつかについて述べる。
本発明の一実施形態では、クライアントセッションフェイルオーバーを提供する方法であって、セキュリティアサーション（security assertion：セキュリティ表明）を使用し、それによりクライアントとのセッションを再確立し、クライアントがフェイルオーバーサーバにフェイルオーバーできるようにすることを含む。
この方法は、セキュリティアサーションを発行する第１のサーバとフェイルオーバーサーバの間に信頼関係を確立することも含む。
【０００９】
本発明の別の実施形態では、クライアントセッションフェイルオーバーを提供する装置は、クライアントと、セキュリティアサーションをクライアントに提供するように構成された第１のサーバと、セキュリティアサーションに基づいてクライアントとのセッションを再確立するように構成されたフェイルオーバーサーバと、を備える。
【００１０】
本発明の他の実施形態は以下に述べる各種実施形態を含むが、これらに限定されない。
【００１１】
本発明の実施形態のこれらおよび他の特徴は、添付の図面および特許請求の範囲を含む本開示全体を読むことにより、当業者には容易に明らかであろう。
【発明を実施するための最良の形態】
【００１２】
本明細書における説明では、本発明の実施形態の完全な理解を提供するために、コンポーネントおよび／または方法の例等、多くの特定の詳細が提供される。
しかしながら、当業者は、特定の詳細の１つまたは複数を使用せずに、または他の装置、システム、方法、コンポーネント、材料、パーツ、および／またはこれらと同様のものを用いて、本発明の実施形態を実施可能なことを認めよう。
場合によっては、本発明の実施形態の態様を曖昧にしないように、周知の構造、材料、または動作については詳細に図示または説明しない。
【００１３】
図１は、サーバフェイルオーバーの前後に行われる対話、ならびにサーバフェイルオーバーの前後でクライアントセッションがどのように保持されるかを示すブロック図である。
一実施形態では、フェイルオーバー時に、システム１０が、クライアント１５に格納される高信頼性セキュリティアサーションを使用して、サーバ（１つまたは複数）とのセッションを再確立する。
たとえば、クライアント１５がサーバ２０とのセッションを確立し、そしてサーバ２０に障害が発生した場合は、クライアントが、サーバ２０との信頼関係を有する別のサーバ（たとえば、サーバ２５）とのセッションを再確立することができる。
【００１４】
クライアント１５ならびにサーバ２０および２５は、クライアントがサーバ２０および２５と通信し、認証および要求／応答動作を実行できるようにするとともに、サーバ２０および２５が信頼関係３０を確立できるようにする既知のコンポーネント（たとえば、プロセッサおよびソフトウェア）を含む。
【００１５】
本発明の一実施形態では、クライアントセッションフェイルオーバーを提供する方法は以下のステップを含む。
ステップ１００は、サーバアプリケーション（またはサーバ）２０に対するクライアント１５の認証を含む。
認証は、最初にセッションを確立するに先立って要求される。
当業者には既知のように、認証とは、個人（クライアント１５を使用している）を識別するプロセスのことである。
通常、認証はユーザ名およびパスワードに基づいており、その個人が主張している本人であることを単に保証するだけであり、その個人のアクセス権については何等言及しない。
また、当業者には既知のように、セッションとは、１つの接続期間中に発生する２つの通信エンドポイント間の一連の対話のことである。
通常、一方のエンドポイントが指定された別のエンドポイントとの接続を要求する。
そのエンドポイントが接続に同意する応答を返す場合、これらエンドポイントが交代でコマンドおよびデータを交換する（「互いに会話する」）。
セッションは、接続の両端で確立されたときに始まり、接続が終了したときに終わる。
【００１６】
認証の成功を受けて、サーバアプリケーション２０は、ステップ２００に示すように、ローカルセッショントークンおよびセキュリティアサーションの両方を返す。
ローカルセッションは通常、一意性を確保することができる無作為に生成された数のＭＤ５ハッシュである。
そして、サーバ２０は、後続してクライアントから呼び出しがあったときに、このトークンをセッションマネージャへのインデックスとして使用する。
【００１７】
通常、セキュリティアサーションは、ＸＭＬベースのスキーマ定義およびセキュリティ情報を伝送するためのプロトコルであるセキュリティアサーションマークアップ言語（ＳＡＭＬ）に基づく。
ＳＡＭＬは、認証、許可、および属性情報を交換する機構を定義し、シングルサインオン機能をウェブアプリケーションおよびサービスに与える。
【００１８】
ステップ３００および４００は、クライアント／サーバアプリケーションの通常の標準的な要求／応答モデルを示す。
ローカルセッショントークンは、クライアント１５による各要求においてサーバ２０に通信される（ステップ３００）。
ローカルセッショントークンは、クライアント１５のセッション識別子として機能し、クライアントとサーバの間でセッションを維持するために使用される。
一例として、ウェブブラウザ環境では、トークンは通常クッキーである。
サーバ２０は、クライアント１５が行った要求に応答する（ステップ４００）。
【００１９】
サーバ２０に障害が発生した後、クライアント要求はタイムアウトするか、あるいは失敗し（ステップ５００）、この時点で、クライアント１５は次に、ステップ２００において取得したセキュリティアサーションを提示することによって別のサーバとのセッションを確立しようと試みる。
クライアント１５はフェイルオーバーサーバに要求を行い、セキュリティアサーションがその要求に含められる（ステップ６００）（通常、クライアント１５には要求６００の送り先であるフェイルオーバーサーバ２５の場所が予め構成されている。さらに、２つ以上のフェイルオーバーサーバがあり得る）。
フェイルオーバー状況が存在する場合、クライアント１５はセッショントークンをフェイルオーバーサーバに送らない。
代わりに、クライアント１５は要求に含めたセキュリティアサーションをフェイルオーバーサーバに送る。
セキュリティアサーションにより、フェイルオーバーサーバ２５は、フェイルオーバー状況が存在し、フェイルオーバーサーバ２５が特定のクライアント１５と新しいローカルセッションを確立しようと試みるべきであることを検出することができる。
【００２０】
フェイルオーバーサーバ２５はセキュリティアサーションを検証し、セキュリティアサーションの内容に基づいて新しいローカルセッションコンテキストを確立する（ステップ７００）。
フェイルオーバーサーバ２５は、通常、セキュリティアサーションの内容を見ることによってセキュリティアサーションを検証する。
セキュリティアサーションは、最低でも、氏名識別子、認証方法、有効期間、およびユーザの署名等のパラメータを含めることによってユーザの認証された身元を検証する。
氏名識別子はクライアント１５の特定のユーザを識別し、ユーザ署名はクライアント１５のユーザのデジタル署名である。
認証方法は、認証がどのように行われたか（たとえば、ユーザ名およびパスワードの使用によるなど）を示す。
有効期間は、セキュリティアサーションが有効な期間を示す。
サーバによって作成されるセキュリティアサーションは、所与の時間期間（たとえば、２時間、１日、または１週間）後に期限切れになることが一般的である。
【００２１】
さらに、セキュリティアサーションは、直列化オブジェクトまたは二進コード化の形のセッションコンテキスト情報（たとえば、ショッピングカートアイテム）を含み得る。
セキュリティアサーションは、セッションが確立されてからクライアント１５によって得られ、そして、時間ベースの間隔で、またはセッション情報が変更されたときに、プッシュあるいはプル機構を使用して更新される。
【００２２】
ステップ８００において、サーバ２５は、このサーバ２５との今後の通信に使用するための新しいローカルセッショントークンを含む応答をクライアント１５に送る。
さらに、ステップ８００において、サーバ２５は、クライアント１５への応答に、今後フェイルオーバー状況が発生した場合にクライアント１５が使用する新しいセキュリティアサーション４０を含める。
【００２３】
図１中、クライアント１５はサーバ２５にフェイルオーバーして示されているが、サーバ２０と信頼関係３０を有する他のいずれのサーバにもフェイルすることができる。
【００２４】
上に述べたように、本発明の一実施形態は、フェイルオーバー環境においてサーバ間に信頼関係３０を予め確立することに依拠する。
一例では、これは、アサーションをデジタル的に署名するキーイング情報を共有することに相当する。
信頼関係３０は、フェイルオーバーサーバが、信頼関係３０にあるサーバによって前に作成されたセキュリティアサーションを消費することを可能にする。
【００２５】
既知の様々な方法を使用して信頼関係３０を作ることができる。
たとえば、図２は、帯域外通信（すなわち、クライアント１５からの要求）の使用によりサーバ２０と２５の間に信頼関係３０を確立する方法を示す。
フェイルオーバーサーバ２５は、サーバ２０に障害が発生した後、クライアント１５からクライアント要求９００を受け取る（図１のステップ６００も参照のこと）。
クライアント要求９００はセキュリティアサーション９０５を含み、セキュリティアサーション９０５はサーバ２０のインターネットプロトコル（ＩＰ）アドレス９１０を含む。
サーバ２５は、サーバ２０のＩＰアドレス９１０が、サーバ２０と２５の間の書面契約書に基づいて承認可能なものである場合に承認することができる。
書面契約書は通常、サーバ２０および２５が別個の組織によってホストされ所有される場合に使用される。
書面契約書は、共有されるセキュリティアサーションを、そのセキュリティアサーションが特定の同意がなされた情報（たとえば、発信サーバのＩＰアドレス、または共有される秘密鍵）を含む場合に信用するという、２つ以上のエンティティ間の取引契約に相当する。
【００２６】
図３は、ＰＫＩ（公開鍵インフラストラクチャ）の使用によりサーバ２０と２５の間に信頼関係３０を確立する別の方法を示す。
当業者には既知のように、ＰＫＩは、インターネット等の基本的に非セキュアな公衆ネットワークのユーザが、信頼のおける機関を通して取得し共有される公開および秘密の暗号鍵対を使用することによってデータおよび金銭をセキュアかつ個人的に交換できるようにする。
公開鍵インフラストラクチャは、個人または組織を識別することができるデジタル証明書、ならびに証明書を格納し、必要であれば取り消すことができるディレクトリサービスを提供する。
【００２７】
サーバ２０は、デジタル署名９５５を使用することによりセキュリティアサーション９５０に署名することができる。
フェイルオーバーサーバ２５は、サーバ２０に障害が発生した後、クライアント１５からクライアント要求９６０を受け取る（図１のステップ６００も参照のこと）。
クライアント要求９６０はセキュリティアサーション９５０およびデジタル署名９５５を含み、フェイルオーバーサーバ２５はセキュリティアサーション９５０およびデジタル署名９５５を検証する（９６５）ことができる。
【００２８】
サーバ間に信頼関係３０を確立する他の適した方法も使用することができる。
【００２９】
通信オーバヘッドの増大を回避するため、本発明の一実施形態は、通常の実行時動作中に従来のサーバベースのセッション管理技法（たとえば、ＨｔｔｐＳｅｓｓｉｏｎ）を使用し、そして、フェイルオーバー時に新しい（フェイルオーバー）サーバと通信する場合に、クライアントに格納されているセキュリティアサーションを使用することによってセッションを行う混成手法を採用する。
フェイルオーバーサーバ（たとえば、サーバ２５）は、セキュリティアサーションからの前のセッション情報を確認し、そのクライアントに新しいサーバベースのセッションを作成することができる。
【００３０】
本発明の実施形態は様々な利点を実現する。
第１に、本発明の実施形態では、サーバ側でのデータベースの同期またはハードウェアのクラスタ化技法が必要とされない。
第２に、本発明の実施形態の混成手法により、通信チャネル（１つまたは複数）に、クライアント要求またはサーバ応答毎のセッションコンテキスト情報による過負荷がかからない。
第３に、本発明の実施形態では、セキュリティがフェイルオーバーサーバ間に確立される信頼関係に基づいているため、クライアントはセッション情報の複雑な署名または暗号化処理に対処する必要がない。
第４に、本発明の実施形態は、垂直および水平の両方において拡張性が高い。
クライアントは、セキュリティアサーションを発行したサーバと事前に信頼関係を予め確立している任意のサーバにフェイルオーバーすることができる。
【００３１】
本明細書に述べる各種エンジンまたはモジュールは、たとえば、ソフトウェア、コマンド、データファイル、プログラム、コード、モジュール、命令等であることができ、適した機構を含むこともできる。
【００３２】
本明細書全体を通しての「一実施形態」、「実施形態」、または「特定の実施形態」への言及は、実施形態と併せて述べられた特定の機構、構造、または特徴が、本発明の少なくとも１つの実施形態に含まれることを意味する。
したがって、本明細書全体を通して様々な箇所にある「一実施形態では」、「実施形態では」または「特定の実施形態では」という語句がすべて、必ずしも同じ実施形態を指しているとは限らない。
さらに、特定の機構、構造、または特徴は、１つまたは複数の実施形態に任意の適した様式で組み合わせることができる。
【００３３】
上記開示に照らして、上に述べた実施形態および方法の他の変形および変更が可能である。
さらに、本発明の一実施形態のコンポーネントの少なくともいくつかは、プログラムされた汎用デジタルコンピュータを使用することにより、特定用途向け集積回路、プログラマブルロジックデバイス、またはフィールドプログラマブルゲートアレイを使用することにより、またはコンポーネントおよび回路が相互に接続されたネットワークを使用することにより実施し得る。
接続は、ワイヤ、ワイヤレス、モデムによるもの等であることができる。
【００３４】
また、図面／図に示される要素の１つまたは複数もまた、特定の応用に従って有用なように、さらに分離させて、またはさらに統合させて実施することもでき、あるいは、さらに特定の場合に取り外して、または動作不能とすることもできることが理解されよう。
【００３５】
また、機械可読媒体に格納して、コンピュータに上に述べた方法のいずれかを実行させることができるプログラムまたはコードを実装することも本発明の実施形態の範囲内である。
【００３６】
加えて、図面／図中の信号矢印は、特記されない限り例示的なものとみなされ、限定するものではない。
さらに、本開示に使用される「または（あるいは）」という語は概して、特記されない限り、「および／または」を意味するものと意図される。
用語により、分離可能なこと、または組み合わせ可能なことがはっきりしないものと予見される場合、コンポーネントまたはステップの組み合わせも言及されているものとみなされる。
【００３７】
本明細書における説明および添付の特許請求の範囲全体を通して使用される「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈により明らかに異なって記述している場合を除き、複数の参照を含む。
また、本明細書における説明および添付の特許請求の範囲全体を通して使用される「ｉｎ」の意味には、文脈により明らかに異なって記述している場合を除き、「ｉｎ」および「ｏｎ」を含む。
【００３８】
また、図面に示され、本文に述べた各種機能、変数、または他のパラメータには、識別を目的として特定の名称が与えられていることに留意する。
しかし、機能名、変数名、または他のパラメータ名は、その機能、変数、または他のパラメータを識別するいくつかの考えられる例として提供されているにすぎない。
他の機能名、変数名、またはパラメータ名も、図面に示され、本文に述べた機能、変数、またはパラメータの識別に使用することができる。
【００３９】
本発明について本発明の特定の実施形態を参照して本明細書に説明したが、許容範囲の変更、各種変形、および置換は上記開示内にあるものと意図され、場合によっては、記載される本発明の範囲および精神から逸脱することなく、本発明のいくつかの機構を、対応する他の機構を使用することなく採用されることが認められよう。
したがって、本発明の本質的な範囲および精神に多くの変更を行って特定の状況または材料に適応させることができる。
本発明は、本発明を実行するに最良の形態とみなされる、開示された特定の実施形態に限定されず、添付の特許請求の範囲内にあるすべての実施形態および同等物を包含するものと意図される。
【産業上の利用可能性】
【００４０】
本発明は、クライアントサーバコンピューティングに利用されうる。
【図面の簡単な説明】
【００４１】
【図１】サーバフェイルオーバーの前後に行われる対話、ならびにサーバフェイルオーバーの前後でクライアントセッションがどのように保持されるかを示すブロック図である。
【図２】サーバ間に信頼関係を確立する方法を示すブロック図である。
【図３】サーバ間に信頼関係を確立する別の方法を示すブロック図である。
【符号の説明】
【００４２】
１５・・・クライアント、
２０，２５・・・サーバ、
３０・・・信頼関係、
４０・・・新しいセキュリティアサーション、
【図１】
2004206695.tif 000003
【図２】
2004206695.tif 000004
【図３】
2004206695.tif 000005