(57)【要約】【課題】ステートレスプロトコルを介してアクセスされるリソースの認証状態を維持する。【解決手段】提供側コンピュータシステムは、ステートレスプロトコルを介してリソースへのアクセス要求を受け取ることができる。アクセス制御アプリケーションは、管理規則を参照して、要求に関連付けられた妥当性検証情報を設定することができる。妥当性検証情報は、リソースに関連付けられたセッションの状態を示すことができる。要求が受け取られると、妥当性検証情報および認証情報を使用して、リソースへのアクセスを認可するべきか否かを判定することができる。リソースへのアクセスが認可または拒否されると、セッションの状態が変更されたことを示すように妥当性検証情報を更新することができる。【選択図】　　　　図２
2004005638.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにネットワーク接続可能であり、ステートレスプロトコルを介して要求を受け取ることができるコンピュータシステムにおいて、受け取られた要求は、前記コンピュータシステムに含まれるリソースへのアクセス要求であり、リソースへのアクセス要求に関連付けられた認証情報の妥当性を検証して、前記リソースの状態を判定する方法であって、
認証情報を必要とするリソースへのアクセス要求を受け取る特定の動作と、
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作と
を備えたことを特徴とする方法。
【請求項２】
認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
ステートレスプロトコルを介して、認証情報を必要とするリソースへのアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項３】
ステートレスプロトコルを介して、認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
認証情報を必要とするリソースへのＨＴＴＰアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項２に記載の方法。
【請求項４】
認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
ＷＷＷ−認証ヘッダを含む要求を受け取る特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項５】
認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
記憶場所から取り出された認証情報を含む要求を受け取る特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項６】
認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
ユーザに提示されるフォームに応答して手作業で入力された認証情報を含む要求を受け取る特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項７】
認証情報を必要とするリソースへのアクセス要求を受け取る前記特定の動作は、
アクセスするための認証情報を必要とするＷｅｂページへのアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項８】
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
後に前記認証情報とともに使用されるクッキーに含まれる妥当性検証情報を追加する特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項９】
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
後に前記認証情報とともに使用される状態テーブルに含まれる妥当性検証情報を追加する特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項１０】
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
後に前記認証情報とともに使用される前記リソースの前記妥当性検証状態を示す妥当性検証情報を追加する特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項１１】
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
高速ログアウトコマンドの実行によって設定され、後に前記認証情報とともに使用される妥当性検証情報を追加する特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項１２】
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
前記リソースへのアクセスが満了したことを示し、後に前記認証情報とともに使用される妥当性検証情報を追加する特定の動作を備えたことを特徴とする請求項１に記載の方法。
【請求項１３】
ネットワークにネットワーク接続可能であり、ステートレスプロトコルを介して要求を受け取ることができるコンピュータシステムにおいて、受け取られた要求は、リソースへのアクセス要求であり、リソースへのアクセス要求に含まれる認証情報の妥当性を検証して、リソースがアクセス可能な状態にあるか否かを判定する方法であって、前記要求は、ステートレスプロトコルを介して受け取られ、
前記リソースへの初期のアクセス要求を受け取る特定の動作と、
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照する特定の動作と、
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作と、
前記妥当性検証情報を認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作と
を備えたことを特徴とする方法。
【請求項１４】
前記リソースへの初期のアクセス要求を受け取る前記特定の動作は、
妥当性検証状態にあるリソースへのアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記リソースへの初期のアクセス要求を受け取る前記特定の動作は、
ブラウザによって記憶場所にキャッシュされた認証情報を含む要求を受け取る特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照する前記特定の動作は、
前記初期の要求を拒否して未許可メッセージを戻す特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項１７】
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照する前記特定の動作は、
妥当性検証状態を示す妥当性検証情報を設定するために管理規則を参照する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照する前記特定の動作は、
妥当性検証情報でクッキーを設定するために管理規則を参照する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照する前記特定の動作は、
妥当性検証情報で状態テーブルを設定するために管理規則を参照する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項２０】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
手作業で入力された認証情報を含む前記リソースへの第２のアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項２１】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
クッキーに含まれた妥当性検証情報に関連付けられた前記リソースへの第２のアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項２２】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
状態テーブルに含まれた妥当性検証情報に関連付けられた前記リソースへの第２のアクセス要求を受け取る特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項２３】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースが妥当性検証開始状態であることを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２４】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースが妥当性検証終了状態であることを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２５】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースが有効状態であることを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２６】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースがログイン状態であることを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２７】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースがログアウト状態であることを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２８】
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取る特定の動作は、
前記リソースへの第２のアクセス要求を受け取る特定の動作を備え、前記第２の要求は、前記リソースへのアクセスが満了したことを示す前記妥当性検証情報を含むことを特徴とする請求項１３に記載の方法。
【請求項２９】
前記妥当性検証情報を認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
認証情報とともにクッキーに含まれた妥当性検証情報を使用して、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項３０】
前記妥当性検証情報を認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
認証情報とともに状態テーブルに含まれた妥当性検証情報を使用して、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項３１】
前記妥当性検証情報を認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定する前記特定の動作は、
手作業で入力された認証情報とともに妥当性検証情報を使用して、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作を備えたことを特徴とする請求項１３に記載の方法。
【請求項３２】
前記リソースへのアクセス要求は、ステートレスプロトコルを介して受け取られることを特徴とする請求項１３に記載の方法。
【請求項３３】
前記リソースへのアクセス要求は、ＨＴＴＰを介して受け取られることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記リソースに関連付けられたセッションが、前記リソースへのアクセスを認可できる妥当性検証状態であることを示す妥当性検証情報に関連付けられた前記リソースへの第３のアクセス要求を受け取る特定の動作をさらに備えたことを特徴とする請求項１３に記載の方法。
【請求項３５】
ネットワークにネットワーク接続可能であり、ステートレスプロトコルを介して要求を受け取ることができるコンピュータシステムにおいて、受け取られた要求は、リソースへのアクセス要求であり、リソースへのアクセス要求に関連付けられ、ステートレスプロトコルを介して受け取られた認証情報の妥当性を検証して、リソースがアクセス可能な状態にあるか否かを判定する方法であって、
前記リソースへの初期のアクセス要求を受け取る特定の動作と、
後の前記リソースへのアクセス要求において前記リソースに妥当性検証情報を関連付け、前記リソースに関連付けられた前記認証情報が手作業で再入力されたことを示すステップと、
前記妥当性検証情報を前記認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定する特定の動作と
を備えたことを特徴とする方法。
【請求項３６】
ネットワークにネットワーク接続可能であり、ステートレスプロトコルを介して要求を受け取ることのできる提供側コンピュータシステムにおけるコンピュータプログラム製品であって、受け取られた要求は、前記提供側コンピュータシステムに含まれたリソースへのアクセス要求であり、前記コンピュータプログラム製品は、リソースへのアクセス要求で受け取られた認証情報の妥当性を検証して、前記リソースの前記状態を判定する方法を実施し、
前記コンピュータプログラム製品は、前記コンピュータシステムで実行されると前記コンピュータシステムに前記方法を実行させる、コンピュータ実行可能命令を収容している１または複数のコンピュータ読取り可能媒体を備え、前記方法は、
認証情報を必要とするリソースへのアクセス要求を受け取ることと、
後に前記認証情報とともに使用される妥当性検証情報を追加し、前記リソースへのアクセスを認可するべきか否かを判定することと
を含むことを特徴とするコンピュータプログラム製品。
【請求項３７】
前記１または複数のコンピュータ読取り可能媒体は、物理記憶媒体を含むことを特徴とする請求項３６に記載のコンピュータプログラム製品。
【請求項３８】
ネットワークにネットワーク接続可能であり、ステートレスプロトコルを介して要求を受け取ることのできるコンピュータシステムにおけるコンピュータプログラム製品であって、受け取られた要求は、リソースへのアクセス要求であり、前記コンピュータプログラム製品は、リソースへのアクセス要求に含まれた認証情報の妥当性を検証するための方法を実施し、前記要求は、ステートレスプロトコルを介して受け取られ、
前記コンピュータプログラム製品は、前記コンピュータシステムで実行されると前記コンピュータシステムに前記方法を実行させる、コンピュータ実行可能命令を収容している１または複数のコンピュータ読取り可能媒体を備え、前記方法は、
前記リソースへの初期のアクセス要求を受け取ることと、
前記リソースに関連付けられた妥当性検証情報を設定するために管理規則を参照することと、
前記妥当性検証情報を含む、前記リソースへの第２のアクセス要求を受け取ることと、
前記妥当性検証情報を認証情報とともに使用して、前記リソースへのアクセスを認可するべきか否かを判定することと
を含むことを特徴とするコンピュータプログラム製品。
【請求項３９】
前記１または複数のコンピュータ読取り可能媒体は、物理記憶媒体を含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
【請求項４０】
リソースへのアクセス要求に関連付けられた認証情報の妥当性を検査するためのネットワークシステムであって、
要求側コンピュータシステムが前記リソースへのアクセスを要求するときに、リソースへのアクセス要求に含まれた認証情報の妥当性検証に使用される妥当性検証情報を含む妥当性検証クッキーを転送するように構成された、ブラウザを含む要求側コンピュータシステムと、
前記要求側コンピュータシステムにネットワーク接続可能であり、前記リソースへのアクセス要求に関連付けられた認証の妥当性を検証するためのアプリケーションを含み、前記リソースに対してログイン状態およびログアウト状態を維持するように構成される提供側コンピュータシステムと
を備えたことを特徴とするネットワークシステム。
【請求項４１】
ネットワークにネットワーク接続可能であり、リソースへのアクセス要求を受け取ることのできるコンピュータシステムにおいて、リソースへのアクセスを認可するべきか否かを判定するための方法であって、
ステートレスプロトコルを介して、前記リソースへのアクセス要求を受け取る特定の動作と、
前記要求が前記リソースへのアクセスに適した認証情報に関連付けられているか否かを判定する特定の動作と、
状態情報が、セッションが前記リソースへのアクセスに適した状態にあることを示しているか否かを判定する特定の動作と、
前記認証情報および前記状態が前記リソースへのアクセスに適している場合には、前記リソースへのアクセスを認可する特定の動作と
を備えたことを特徴とする方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ステートレス（ｓｔａｔｅｌｅｓｓ）環境でアクセスされるリソースに対する認証状態の維持に関する。さらに詳細には、本発明は、ステートレスプロトコルを介して移送されるユーザ認証情報の妥当性を検証するための、システム、方法、およびコンピュータプログラム製品に関する。
【０００２】
【従来の技術】
ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）上のコンテンツは、典型的には、クライアント／サーバモデルでアクセスされる。クライアントコンピュータシステムの「Ｗｅｂブラウザ」は、サーバコンピュータシステムの「Ｗｅｂサーバ」が提供するコンテンツにアクセスするための要求を送信する。Ｗｅｂブラウザのユーザがコンテンツにアクセスする許可を与えられている場合、典型的には、Ｗｅｂサーバは、そのコンテンツをＷｅｂブラウザに提供する。
【０００３】
ＷｅｂブラウザおよびＷｅｂサーバには、コンテンツの要求、提供、および移送を行い、ＯＳＩ（Ｏｐｅｎ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルの様々な層で動作するソフトウェアモジュールが含まれる。ＯＳＩモデルは、様々な機能層でプロトコルを実施するために可能な１つのフレームワークを定義する。ＯＳＩモデルは、データ通信のためのオペレーションを、それぞれがデータ転送プロセスで一定のオペレーションを実行するように指定された７つの別個の「層」に分解する。実際に実装されてきた通信フレームワークは、このモデルとは多少異なるが、ＯＳＩモデルを参照すると、基本的なデータ通信を理解するのに役立つ。
【０００４】
典型的には、ＯＳＩモデルの上位層は、アプリケーションソフトウェアが実装され、ＯＳＩモデルの下位層は、オペレーティングシステムに委ねられる。最上位層はアプリケーション層であり、典型的には、アプリケーションおよびエンドユーザのプロセスをサポートする責任を担う。コンピュータシステムからデータが送られる場合、典型的には、データはアプリケーション層から発信され、下位層を通じて下に進み、物理ネットワークに入る。同様に、コンピュータシステムでデータが受信される場合、データは物理ネットワークから入り、下位層を通じて上に進み、アプリケーション層に転送される。
【０００５】
Ｗｅｂ環境では、コンテンツおよびコンテンツ要求は、しばしばＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）を使用して移送される。ＨＴＴＰは、ＯＳＩモデルのアプリケーション層と他の下位層との間で、Ｗｅｂ環境でのコンテンツの転送を容易にするように動作する。コンテンツへのアクセス要求は、典型的には、Ｗｅｂブラウザにおいてユーザから発信される。次にこの要求は、ＨＴＴＰに変換され、ＯＳＩモデルの下位層を通じて渡され、ブラウザのクライアントコンピュータシステムからネットワークを介して送信される。要求は、Ｗｅｂサーバを含むサーバコンピュータシステムで受信され、ＯＳＩモデルの下位層を通じて渡され、その後ＨＴＴＰに変換される。ＨＴＴＰに変換された後、Ｗｅｂサーバは、この要求を処理して、Ｗｅｂブラウザのユーザが要求されたコンテンツへのアクセスを許可されているかどうかを判定することができる。ユーザが要求されたコンテンツへのアクセスを許可されている場合、Ｗｅｂサーバは、要求が移送されたときと同じ方法で、ＨＴＴＰを介してＷｅｂブラウザにコンテンツを戻すことになる。
【０００６】
ＨＴＴＰは、ステートレスプロトコルである。言い換えれば、ＨＴＴＰを介した通信（例えばＷｅｂページ要求）は、どんな以前の通信（例えば他の以前のＷｅｂページ要求）の知識もなしに実行される。従って、ＨＴＴＰ認証は、ユーザが「ログイン」または「ログアウト」する「セッション」の概念をサポートしていない。ＨＴＴＰを介して移送されるコンテンツにアクセスするための要求（以下「ＨＴＴＰ要求」と呼ぶ）は、それぞれ適切なＨＴＴＰ認証情報を含んでいなければならない。
【０００７】
ＨＴＴＰプロトコルは、この認証情報の規定を設け、ＷＷＷ−許可ヘッダと呼ばれる特別のヘッダを介して、各ＨＴＴＰ要求とともに供給される。この許可ヘッダは、「ＷＷＷ−Ａｕｔｈｏｒｉｚａｔｉｏｎ：［Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｔｙｐｅ］［Ｃｒｅｄｅｎｔｉａｌｓ］」の形式をとる。ブラウザがこれら信用状を取得して伝送する方法は、次のとおりである。最初に、ユーザが認証を必要とするＷｅｂサイトへのアクセスを試みると、Ｗｅｂサーバは、要求されたコンテンツの提供を拒否し、ブラウザに対してＨＴＴＰ　Ｅｒｒｏｒ　ｍｅｓｓａｇｅ　Ｎｏ．４０１　−　Ｕｎａｕｔｈｏｒｉｚｅｄを戻すことになるが、この応答には、「ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ：［ｒｅａｌｍ］［Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｅｔｈｏｄｓ　ｓｕｐｐｏｒｔｅｄ］［Ｏｐｔｉｏｎａｌ　ｉｎｆｏｒｍａｔｉｏｎ］」のテキストを備えたヘッダ行が含まれる。
【０００８】
ブラウザがこのメッセージを受け取ると、ユーザ名およびパスワードを要求するダイアログボックスがポップアップ表示される。ユーザが正しいパスワードを入力すると、ブラウザは、元のＨＴＴＰ要求をサーバに再送するが、ヘッダラベルの引数としての信用状を含むＨＴＴＰ「ＷＷＷ−許可」ヘッダを追加する。Ｗｅｂサーバが、含まれた信用状を受け入れて有効なコンテンツを戻すと、ブラウザは、これら信用状をキャッシュして、同じＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）または同じコンテンツに関連付けられた派生する関連のＵＲＬへ、新しい要求とともにこれらを再送する。
【０００９】
ユーザの信用状をブラウザメモリに格納することは、少なくとも１つの潜在的なセキュリティリスクを提示することになる。Ｗｅｂブラウザは、信用状を集めて、通常はブラウザプログラムが（ブラウザプログラムを終了するか、あるいはコンピュータ（クライアントデバイス）をリブートまたはターンオフすることによって）中止されるまで、無期限にこれらをキャッシュメモリに格納する。従って、保護されたコンテンツにアクセスしたユーザの信用状は、ユーザがもはやブラウザを使用しなくなった後にも、ブラウザのキャッシュメモリ内に格納されている可能性がある。
【００１０】
これは、公衆コンピュータを備えた場所では、特に問題となる可能性がある。特権が与えられたユーザは、公衆コンピュータまたはクライアントデバイス（例えば公衆キオスク）に格納されたブラウザを介して、保護されたコンテンツ（アクセスのために信用状が必要なコンテンツ）にアクセスすることができる。保護されたコンテンツにアクセスした結果として、特権が与えられたユーザの信用状は、ブラウザメモリにキャッシュされる。その後、特権が与えられたユーザが公衆コンピュータを離れた場合、特権が与えられていないユーザがやってきて、ブラウザの戻るボタンまたは履歴機能を使用すると、保護されたコンテンツにアクセスすることができる。特権が与えられたユーザが以前に訪れたＵＲＬに特権が与えられていないユーザが訪れると、ブラウザがキャッシュされた信用状を再送することになるので、特権が与えられていないユーザは、保護されたコンテンツにアクセスできてしまう。
【００１１】
同様のリスクが、Ｗｅｂブラウザを備えた、例えば移動電話または個人用携帯型情報端末などのポータブルデバイスにも当てはまる。例えば、特権が与えられていないユーザは、現在アクティブなＷｅｂブラウザを含む移動デバイスを見つける（すなわちポータブルデバイスがターンオンされる）可能性がある。特権が与えられていないユーザは、ポータブルデバイスの所有者のキャッシュされた信用状をＷｅｂブラウザに再送させるＵＲＬを訪れることによって、ポータブルデバイス上の保護されたコンテンツにアクセスすることができる。
【００１２】
Ｗｅｂブラウザを含むほとんどの公衆コンピュータおよびポータブルデバイスにおいて、Ｗｅｂブラウザキャッシュからユーザが信用状を除去する簡単な方法がない。たとえ（デバイスの電源をオフにするか、またはブラウザを終了するなどによって）メモリから信用状を除去することが可能であっても、ユーザは、Ｗｅｂブラウザの使用を完了するときに、自分の信用状を除去するのを忘れる可能性がある。従って、ユーザが自分の信用状の除去を忘れたときの影響を軽減するために、ある程度のレベルのセキュリティを提供する必要がある。
【００１３】
信用状を使用する最も安全な方法は、コンテンツにアクセスするための各ＨＴＴＰ要求に関する認証情報を手作業で再入力するように、ブラウザがユーザに要求することである。ただしＷｅｂサイトとの典型的な対話は、何十、何百というＨＴＴＰ要求からなる可能性がある。従って、各ＨＴＴＰ要求について信用状を再入力することになれば、コンテンツにアクセスするために必要な時間が大幅に増加し、ユーザをいらだたせる可能性がある。
【００１４】
ＨＴＴＰ認証情報をブラウザに格納したままにしておく危険性により、コンテンツプロバイダモジュールの中には、独自のアプリケーション層におけるログイン状態を実施する。例えば、Ｗｅｂサーバが、ＨＴＴＰ認証を使用してＷｅｂページにアクセス制御できるようにするのに対して、Ｗｅｂページは、アプリケーション層認証を使用して自身にクセス制御することができる。これは、ユーザが、ＨＴＴＰ認証情報の代わりにコンテンツプロバイダ認証情報を手作業で入力する「フォームベース（ｆｏｒｍｓ−ｂａｓｅｄ）」のログインを導入するコンテンツプロバイダモジュールによって行われる場合が多い。ユーザがログインに成功すると、Ｗｅｂサーバではなくコンテンツプロバイダモジュールが、Ｗｅｂブラウザにログインクッキーを送信する。新しい要求が受け取られるたびに、コンテンツプロバイダモジュールは、このログインクッキーをチェックする。コンテンツプロバイダモジュールがログインクッキーを感知すると、コンテンツプロバイダモジュールは、Ｗｅｂブラウザのユーザがログインしたことを認識する。
【００１５】
コンテンツプロバイダモジュールは、独自のアプリケーション層におけるログアウト状態も実施することができる。ユーザがログアウトリンクをクリックするのに応答して、コンテンツプロバイダモジュールは、ログインクッキーをＷｅｂブラウザから設定解除（ｕｎｓｅｔ）または削除する。コンテンツプロバイダは、ログインクッキーをログアウトクッキーに置き換えることもできる。次の要求がコンテンツプロバイダモジュールに入ってくると、コンテンツプロバイダモジュールは、ユーザがログアウトしたことを感知し、Ｗｅｂブラウザにコンテンツを提供するのを拒否する。新しいユーザがアクセス権を得るための唯一の方法は、フォームベースのログインを手作業で完了させることである。
【００１６】
従って、キャッシュされたＨＴＴＰ認証情報の問題を解決するための従来の方法は、ＨＴＴＰ認証をまったく使用しないが、アプリケーションフォームを使用したアプリケーションベースの認証セッション管理を導入して、認証情報についてのプロンプトをユーザに出し、この情報を「クッキー」に格納する。クッキーとは、Ｗｅｂブラウザのユーザに関連付けられたユーザ名およびパスワードなどの、Ｗｅｂブラウザに関する情報を含む小さなテキストファイルである。最初に、ブラウザがアプリケーションにコンテンツを要求すると、アプリケーションは、ユーザの名前およびパスワードを要求するフォームをユーザに送信する。次に、アプリケーションはユーザを認証し、この認証が成功すると、アプリケーションは、通常はその１つのセッションの間有効である妥当性が検証された（タイムスタンプを押された）「ａｄｍｉｓｓｉｏｎ　ｔｉｃｋｅｔ」とともにクッキーを符号化する。クッキーは、要求されたコンテンツに関連付けられ、Ｗｅｂサーバは、Ｗｅｂブラウザにクッキーを返信し、ここでクッキーが格納される。要求されたコンテンツにアクセスするための後続の要求で、クッキーに含まれる認証情報（すなわち「ａｄｍｉｓｓｉｏｎ　ｔｉｃｋｅｔ」）は、自動的にＷｅｂサーバに伝送される。従って、ユーザが同じコンテンツに頻繁にアクセスする場合、ユーザは、同じコンテンツにアクセスするたびに認証情報を手作業で再入力する必要がない。
【００１７】
【発明が解決しようとする課題】
アプリケーションレベルのセッション管理により、コンテンツへのアクセスはより安全なものとなる一方で、ログインおよびログアウトクッキーを使用することにより、こうしたスキームを使用することはコンテンツプロバイダモジュールにとって面倒な作業でもある。コンテンツプロバイダモジュールは、特別なアクセスクッキーの管理を含む、別の認証基盤を管理する必要がある。これは少なくとも２つの理由で問題である。Ｗｅｂサーバまたはプロキシサーバは、典型的には、ＨＴＴＰレベルでコンテンツへのアクセスを制御し、コンテンツプロバイダモジュールをコンテンツの管理および送達に集中させる。コンテンツプロバイダモジュールのリソースをセッション管理に費やすことで、コンテンツを提供するためのリソースの量が減少する。さらにＨＴＴＰ認証は、様々なオペレーティングシステムにうまく統合される。ただし、コンテンツプロバイダモジュールによって管理されるなど、別の認証基盤は、様々なオペレーティングシステムとの互換性のあるオペレーションのためにかなりのコーディング修正が必要になる場合がある。
【００１８】
一部のコンテンツプロバイダモジュールは、アプリケーション層のセッション管理に頼ることなく、ＨＴＴＰ認証情報をクッキーに格納したままにしておく危険性を解消する方法を見出した。１つのメカニズムでは、ユーザがログアウト動作を行うと終了信号がＷｅｂブラウザに戻され、これによってＷｅｂブラウザに、クッキーに格納される可能性のあるすべてのキャッシュ済みユーザＩＤおよびパスワードを捨てさせる。他のメカニズムでは、クライアントコンピュータシステム上でスクリプトを実行させる。このスクリプトは、専用のＷｅｂブラウザのアプリケーションプログラムインタフェース（ＡＰＩ）を使用して、クッキーに格納されているようなキャッシュされた信用状を消去するものである。ただし、これらのメカニズムは、Ｗｅｂブラウザに依存しており、Ｗｅｂブラウザは、これらのメカニズムとの互換性を確実にするための修正を必要とする可能性がある。さらに、これらのメカニズムは、決して終了することがないかまたは専用のＡＰＩを含まないＷｅｂブラウザを含む、デバイスのニーズに対処するものではない。例えば、Ｗｅｂブラウザベースの多くのセル電話は、決して終了することがなく、スクリプトを実行する機能も含んでいない。
【００１９】
ステートレスプロトコルを介してアクセスされるリソースの認証状態を維持するためのシステム、方法、およびコンピュータプログラム製品が要求され、このシステム、方法、およびコンピュータプログラム製品は、ステートレスプロトコルに含まれる認証メカニズムを使用する。
【００２０】
【課題を解決するための手段】
ＨＴＴＰなどのステートレスプロトコルを使用してアクセスされるリソースの認証状態を維持するための方法、システム、およびコンピュータプログラム製品について説明する。認証状態は、ステートレスＨＴＴＰプロトコル固有の認証メカニズムを補う、妥当性検証情報の新しい使用方法を介して維持される。本発明にかかる認証状態の維持は、別の認証基盤または専用のブラウザの修正を必要としない。
【００２１】
認証を必要とするリソースにアクセスするための要求が受け取られる。これは、Ｗｅｂブラウザからの要求を受け取るＷｅｂサーバを含むことができる。要求は、ネットワーク（例えばインターネット）に含まれるコンテンツ（例えばＷｅｂページ）に対するものであってよい。こうした要求は、ＨＴＴＰ、ＷＴＰ（Ｗｉｒｅｌｅｓｓ　Ｔｒａｎｓｆｅｒ　ｐｒｏｔｏｃｏｌ）、ＷＡＰ（Ｗｉｒｅｌｅｓｓ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ）、およびＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）を含む、任意のステートレスプロトコルを介して移送することができる。認証情報は、要求に関連付けられたヘッダ（例えば、ＨＴＴＰの場合は「ＷＷＷ−認証」ヘッダ）に含めることができる。
【００２２】
妥当性検証情報が要求に追加され、続いて認証情報とともに使用され、リソースへのアクセスを認可するべきか否かを判定する。妥当性検証情報はクッキーに格納され、Ｗｅｂブラウザが要求を送信するときに認証情報とともに伝送することができる。あるいは、リソースに関連付けられた妥当性検証情報に、クッキー識別子を介して索引付けし、状態テーブルに格納することもできる。後者の代替方法では、リソースへのアクセス要求が送信または受信されるときに、リソースに関連付けられた妥当性検証情報を、状態テーブルから取り出すことができる。
【００２３】
場合によっては、認証情報を必要とするリソースへのアクセス要求は、Ｗｅｂブラウザのユーザがブラウザを使用して以前にアクセスしたことのないリソースへのアクセス要求である可能性がある。このリソースへの最初のアクセス要求は、現在デフォルトで「ログアウト」状態にあるセッションに関連付けられる。
【００２４】
ログアウト状態にあるリソースへの最初のアクセス要求を受け取ると、リソースホストは、管理規則を参照して、認証を成功させるためにはどの妥当性検証情報を要求に関連付ける必要があるかを判定することができる。状況によっては（例えば、同じＷｅｂブラウザの以前のユーザが、リソースをログアウトしたとき、または現在のユーザのタイムスタンプを押されたクッキーが、タイムアウトしたとき）、管理規則は、セッションをログアウト状態に戻すように指示することができる。ログアウト状態に設定するための妥当性検証モジュールのメカニズムは、クッキー全体を除去するか、または「妥当性検証開始」クッキーを設定する。妥当性検証開始クッキーは、Ｗｅｂサーバに戻って受け取られると認証プロセスを開始（または再開）させることになる情報を含むクッキーである。妥当性検証モジュールは、あるフォームをユーザに送信して、ユーザの信用状を要求する。ユーザがフォームに記入し、妥当性検証モジュールがこれらの信用状の認証を試みる。認証プロセスが成功すると、妥当性検証モジュールは、「ログイン」の妥当性検証クッキーを設定することによって「ログイン」状態を設定する。
【００２５】
Ｗｅｂサーバ妥当性検証モジュールは、妥当性検証クッキーが満了したタイムスタンプを押されたクッキーを含む場合には、ユーザがログアウト状態に入ったと決定することができる。上述したように、妥当性検証モジュールは、クッキーを除去するか、またはクッキーを「妥当性検証開始」に設定して、ユーザを認証フォームにリダイレクト（ｒｅｄｉｒｅｃｔ）しなければならない。
【００２６】
リソースへのアクセス要求が、適切な妥当性検証情報を含まない場合（例えば、要求が、妥当性検証開始クッキーからの妥当性検証情報を含まない場合）、要求は拒否されることがある。要求の拒否は、たとえ要求に含まれるＨＴＴＰ認証情報が正しく、そうでなければリソースへのアクセスが認可される場合であっても発生することがある。
【００２７】
リソースへのアクセス要求が拒否されると、妥当性検証モジュールから要求側コンピュータシステムに、要求が拒否されたことまたはユーザが未許可であることを示す未許可メッセージを送信することができる。妥当性検証モジュールは、ユーザが自分の認証情報を再入力できるフォームを送信することもできる。こうしたフォームは、妥当性検証モジュール（ＨＴＴＰではない）の制御下にあってよく、これによって、以前にキャッシュされた信用状が要求側コンピュータシステムから妥当性検証モジュールに送信されるどんな機会も本来的に排除される。この拒否メッセージを送信し、有効な再認証信用状をユーザから受信した後に、妥当性検証モジュールは、クッキー内にあるかまたはクッキーに関連付けられたセッション妥当性検証情報を更新することができる。いくつかの実施形態では、妥当性検証モジュールは、フォームに入力された信用状とＨＴＴＰ要求のＷＷＷ−許可ヘッダに含まれた信用状とを比較することができる。これにより、妥当性検証モジュールが認証データベースに問い合わせる必要性を取り除くことができる。
【００２８】
更新された妥当性検証情報は、現在の妥当性検証クッキーを置き換えるために要求側コンピュータシステムに送信される、更新された妥当性検証クッキーであってよい。例えば、妥当性検証開始クッキーを「妥当性検証終了」クッキーに置き換えることができる。妥当性検証終了クッキーには、Ｗｅｂサーバに戻って受け取られると、セッションがログイン状態であると認識することになる情報が含まれる。あるいは妥当性検証情報は、妥当性検証状態テーブルを更新することによって更新可能である。再認証信用状が無効であることがわかった場合、更新された妥当性検証情報は、第１の要求が拒否されたときに未許可メッセージが要求側コンピュータシステムに戻されたことを示す情報を含むことができる。
【００２９】
リソースに関する後続の要求が実行される場合、妥当性検証情報は、ＨＴＴＰ認証情報とともに再度使用され、リソースへのアクセスを認可するべきか否かが判定される。リソースへのアクセス要求が適切な妥当性検証情報に関連付けられ、適切な認証情報を含むものであれば、リソースへのアクセスが認可される。
【００３０】
更新可能な妥当性検証情報を使用することによって、ステートレスプロトコル固有の認証メカニズムを引き続き使用しながら、セッション状態を維持することができる。妥当性検証情報は、Ｗｅｂブラウザのユーザが認証情報を手作業で再入力したこと、および／またはブラウザによってキャッシュされた認証情報がアクティブに再入力されたことを示すために使用される。これにより、認証情報を必要とするリソースにアクセスする場合のセキュリティレベルが向上し、ブラウザによってキャッシュされたユーザ信用状であっても短期間であれば使用可能であり、引き続き使用するためには再検証が必要であることを保証するのに役立つ。さらに、アプリケーションの開発者は、認証プロセスの管理に費やすリソースを少なくすることができる。
【００３１】
次に、本発明の他の特徴および利点について以下で説明するが、その一部はこの説明から明らかになるか、または本発明を実施することによって知ることができよう。本発明の特徴および利点は、特許請求の範囲で具体的に指摘した機器および組合せによって、実現および取得することができる。本発明のこれらおよび他の特徴は、以下の説明および特許請求の範囲からより完全に明らかになるか、または本発明を以下で説明するように実施することによって知ることができよう。
【００３２】
本発明の上述および他の利点および特徴が取得可能な方法について説明するために、上記で簡単に述べた本発明について、添付の図面に示した特有の実施形態を参照しながらより具体的に説明する。これらの図面が本発明の典型的な実施形態のみを示すものであり、その範囲を限定するものとはみなされないことを理解した上で、添付の図面を使用しながら、追加の特性および詳細について記述および説明する。
【００３３】
【発明の実施の形態】
本発明は、ステートレスプロトコルを介してアクセスされるリソースの認証状態を維持するためのシステム、方法、およびコンピュータプログラム製品に及ぶ。リソースへのアクセスを認可するべきか否かを判定する際に、ステートレスプロトコルを介して移送された認証情報を補足するために妥当性検証情報が使用される。要求に関連付けられた妥当性検証情報または認証情報のいずれかがリソースへのアクセスに適切でない場合、リソースへのアクセスは拒否される。ただし、要求に関連付けられた妥当性検証情報または認証情報がどちらもリソースへのアクセスに適切である場合、リソースへのアクセスを認可することができる。
【００３４】
オペレーションでは、補足クッキーまたは状態テーブルに含まれる妥当性検証情報を使用して、要求側コンピュータシステムのブラウザに関して提供側コンピュータシステムのリソースの状態を決定することができる。妥当性検証情報が、リソースがブラウザに関して「ログアウト」状態のセッションに関連付けられていることを示す場合には、ブラウザのユーザは、リソースへのアクセスを拒否される可能性がある。リソースへのアクセスを拒否されると、提供側コンピュータシステム（例えばＷｅｂサーバ）は、ユーザに認証情報を手作業で再入力するように指示するフォームを提供することができる。その後ブラウザが同じリソースへのアクセス要求を行う場合、妥当性検証情報は、認証情報が手作業で再入力されたことを提供側コンピュータシステムに示すことができる。
【００３５】
本発明の実施形態は、以下でより詳細に述べる、様々なコンピュータハードウェア構成要素を含む汎用または特定用途向けのコンピュータシステムを備えることができる。本発明の範囲内の実施形態は、コンピュータ実行可能命令またはデータ構造を収容または格納しておくための、コンピュータ読取り可能媒体も含む。こうしたコンピュータ読取り可能媒体は、汎用または特定用途向けのコンピュータシステムによってアクセス可能などんな使用可能媒体であってもよい。例を挙げると、こうしたコンピュータ読取り可能媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ−ＲＯＭ、あるいは他の光ディスク記憶デバイス、磁気ディスク記憶デバイス、または他の磁気記憶デバイス、あるいは所望のプログラムコード手段をコンピュータ実行可能命令またはデータ構造の形で収容または格納するために使用可能であり、汎用または特定用途向けのコンピュータシステムによってアクセス可能な、任意の他の媒体などの、物理記憶媒体を含むことができる。
【００３６】
情報がネットワークまたは他の通信接続（ハードワイヤード、ワイヤレス、あるいはハードワイヤードまたはワイヤレスの組合せのいずれか）を介してコンピュータシステムに転送または提供される場合、接続は、厳密にコンピュータ読取り可能媒体として考えられる。従って、こうしたどんな接続も厳密にコンピュータ読取り可能媒体と呼ばれる。上記の組合せもコンピュータ読取り可能媒体の範囲に含まれるとするべきである。コンピュータ実行可能命令は、例えば汎用コンピュータシステムまたは特定用途向けコンピュータシステムに一定の機能または機能グループを実行させる、命令およびデータを含む。
【００３７】
本記述および特許請求の範囲では、「コンピュータシステム」は、電子データに関するオペレーションを実行するために協働する１または複数のソフトウェアモジュール、１または複数のハードウェアモジュール、あるいはそれらの組合せとして定義される。例えば、コンピュータシステムの定義には、パーソナルコンピュータのハードウェア構成要素、ならびにパーソナルコンピュータのオペレーティングシステムなどのソフトウェアモジュールが含まれる。モジュールの物理的レイアウトは重要でない。コンピュータシステムは、コンピュータネットワークを介して結合された１または複数のコンピュータを含むことができる。同様に、コンピュータシステムは、（メモリおよびプロセッサなどの）内部モジュールが電子データに関するオペレーションを実行するために協働する、（移動電話または個人用携帯型情報端末「ＰＤＡ」などの）単一の物理デバイスを含むことができる。
【００３８】
当業者であれば、本発明が、プロセッサ制御型キオスク、パーソナルコンピュータ、ラップトップコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な大衆向け電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、移動電話、ＰＤＡ、ポケットベルなどを含む、多くの種類のコンピュータシステム構成を備えたネットワークコンピューティング環境で実施可能であることを理解されよう。本発明は、通信ネットワークを介して（ハードワイヤードリンク、ワイヤレスリンク、あるいはハードワイヤードリンクまたはワイヤレスリンクの組合せのいずれかによって）リンクされた、ローカルおよびリモートのコンピュータシステムの双方がタスクを実行する、分散型コンピューティング環境でも実施可能である。分散型コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのどちらのメモリ記憶デバイスにも配置することができる。
【００３９】
図１および以下の考察は、本発明が実施可能な好適なコンピューティング環境について、簡単で一般的な説明を提供することを意図するものである。必須ではないが、本発明は、コンピュータシステムによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明される。一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。コンピュータ実行可能命令、関連付けられたデータ構造、およびプログラムモジュールは、本明細書で開示される方法のステップを実行するためのプログラムコード手段の例を表すものである。こうした実行可能命令または関連付けられたデータ構造の特定のシーケンスは、こうしたステップで説明される機能を実施するための対応する動作の例を表すものである。
【００４０】
図１を参照すると、本発明の原理に好適なオペレーティング環境には、電話デバイス１００の形の汎用コンピュータシステムが含まれる。電話デバイス１００には、ユーザインタフェース１０１が含まれ、ユーザが入力ユーザインタフェース１０３を介して情報を入力し、出力ユーザインタフェース１０２を介して提示された情報を見ることができる。例えば、出力ユーザインタフェース１０２は、オーディオ情報をユーザに提示するためのスピーカ１０４、ならびにビジュアル情報をユーザに提示するためのディスプレイ１０５を含む。電話デバイス１００がワイヤレス機能を有する場合、電話デバイス１００はアンテナ１０９も備えることができる。
【００４１】
入力ユーザインタフェース１０３は、オーディオ情報を電子形式に変換するためのマイクロフォン１０６も含むことができる。さらに、入力ユーザインタフェース１０３は、ユーザが情報を入力する際に使用する１２のボタンによって表されるダイヤリングコントロール（ｄｉａｌｉｎｇ　ｃｏｎｔｒｏｌ）１０７も含む。入力ユーザインタフェース１０３は、ディスプレイ１０５上にリストされた様々なエントリおよびオプションを介して、ユーザがナビゲーションするのを支援するナビゲーションコントロールボタン１０８も含む。
【００４２】
ユーザインタフェース１０１は移動電話の外観を有するが、ユーザインタフェース１０１の見えない機能により、複雑かつフレキシブルな汎用処理機能を実行することができる。例えば電話デバイス１００は、相互に接続され、バス１１０を介してユーザインタフェース１０１と接続された、プロセッサ１１１およびメモリ１１２も含む。メモリ１１２は、一般に多種多彩な揮発性および／または不揮発性メモリを表し、以前に論じたメモリのタイプを含むことができる。ただし、電話デバイス１００で使用されている特定タイプのメモリは、本発明にとって重要ではない。電話デバイス１００は、他の汎用コンピュータシステムに関連付けられたものと同様の物理記憶媒体（図示せず）も含むことができる。
【００４３】
１または複数のプログラムモジュールを含むプログラムコード手段を、メモリ１１２または上述のような他の記憶デバイスに格納することができる。１または複数のプログラムモジュールは、オペレーティングシステム１１３、１または複数のアプリケーションプログラム１１４、他のプログラムモジュール１１５、およびプログラムデータ１１６を含むことができる。
【００４４】
図１は、本発明に好適なオペレーティング環境を表すものであるが、本発明の原理は、必要であれば好適な修正を行い、本発明の原理を実施することのできるいかなるシステムでも使用可能である。図１に示された環境は例示的なものであって、本発明の原理が実施可能な多種多様な環境のほんの一部を表したに過ぎない。
【００４５】
本説明および特許請求の範囲では、「提供側コンピュータシステム」は、リソースへのアクセス要求を受け取ることが可能であり、リソースへのアクセスが認可された場合には、要求側コンピュータシステムにリソースを提供することが可能な、コンピュータシステムとして定義される。提供側コンピュータシステムの一例は、Ｗｅｂブラウザにコンテンツを提供できるＷｅｂサーバを含むコンピュータシステムである。
【００４６】
本説明および特許請求の範囲では、「要求側コンピュータシステム」は、提供側コンピュータシステムにリソースへのアクセス要求を送信することが可能であり、アクセスされたリソースをユーザに提示することが可能な、コンピュータシステムとして定義される。要求側コンピュータシステムの一例は、Ｗｅｂサーバに要求を送信できるＷｅｂブラウザを含むコンピュータシステムである。
【００４７】
コンピュータシステムは、提供側および要求側どちらのコンピュータシステムであってもよいことを理解されたい。すなわち、コンピュータシステムは要求を受け取り、一部のリソースへのアクセスが認可されるべきであるか否かを判定することが可能であり、要求を送信して要求されたリソースをユーザに提示することも可能である。
【００４８】
本説明および特許請求の範囲では、「認証情報」は、プロトコル（例えばＨＴＴＰ）のアクセス制御メカニズムに固有の情報として定義される。認証情報には、リソースへのアクセスが認可されるべきであるか否かを判定するためにプロトコルが使用する、ユーザ識別子およびパスワードが含まれることが多い。例えば、認証情報は、プロトコルヘッダに含め、コンピュータシステム間で移送することが可能である。
【００４９】
本説明および特許請求の範囲では、「妥当性検証状態」は、リソースに対するセッションの状態として定義される。妥当性検証状態は、「ログイン」状態、「ログアウト」状態、「有効」状態、「妥当性検証開始」状態、「妥当性検証終了」状態、またはセッションとリソースとの関係を指定する任意の他の状態とすることができる。妥当性検証状態は、セッションがリソースにアクセスできるか否かを決定することができる。
【００５０】
本説明および特許請求の範囲では、「妥当性検証情報」は、プロトコルを使用してリソースへのアクセスを制御する際に使用される認証情報以外の任意の情報として定義される。妥当性検証情報は、セッションをリソースに対する特定の妥当性検証状態であると認識させる情報を含むことができる。例えば、妥当性検証情報を、、セッションがリソースに対するログアウト状態であると妥当性検証モジュールに認識させる、セッションに関連付けることができる。
【００５１】
本説明および特許請求の範囲では、「論理通信パス」は、コンピュータシステムまたはモジュールなどの２つのエンティティ間での電子データの移送を可能にすることができる、任意の通信パスとして定義される。２つのエンティティ間の通信パスの実際の物理的表示は重要でなく、経時的に変更可能である。論理通信パスは、システムバス、ローカルエリアネットワーク、ワイドエリアネットワーク、インターネット、それらの組合せの一部、または電子データの移送を容易にすることのできる任意の他のパスの一部を含むことができる。論理通信パスは、ハードワイヤードリンク、ワイヤレスリンク、またはハードワイヤードリンクおよびワイヤレスリンクの組合せを含むことができる。論理通信パスは、本発明の原理を実施する構成要素にアクセスできるようにデータの一部を条件付けるかまたはフォーマット化する、ソフトウェアまたはハードウェアモジュールを含むこともできる。こうした構成要素は、例えばプロキシ、ルータ、ファイアウォール、またはゲートウェイを含むことができる。論理通信パスは、ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）の一部を含むこともできる。
【００５２】
本説明および特許請求の範囲では、「ステートレスプロトコル」は、以前に転送されたデータの知識なしにデータを転送する任意のプロトコルとして定義される。すなわち、ステートレスプロトコルを使用する各トランザクションは、独立したトランザクションとしてみなされ、以前のトランザクションのコンテキストまたはメモリを必要としない。例えば、ＨＴＴＰを介して現在のリソースへのアクセス要求を受け取るＷＷＷサーバは、リソースへのアクセスを認可するべきか否かを決定する際に、以前のどんな要求からの情報も必要としない。ＨＴＴＰ、ＷＴＰ、ＷＡＰおよびＳＩＰは、ステートレスプロトコルの例の一部である。
【００５３】
本発明によれば、ブラウザ、アクセス制御アプリケーション、妥当性検証モジュール、およびリソース、ならびにクッキーおよび状態テーブルを含む関連付けられたプログラムデータを格納し、電話デバイス１００に関連付けられた任意のコンピュータ読取り可能媒体からアクセスすることができる。例えば、こうしたモジュールの一部および関連付けられたプログラムデータの一部を、メモリ１１２に格納するために、オペレーティングシステム１１３、アプリケーションプログラム１１４、プログラムモジュール１１５、および／またはプログラムデータ１１６に含めることができる。こうしたモジュールおよび関連付けられたプログラムデータの一部は、上述の任意の物理記憶媒体に格納することもできる。こうしたモジュールの実行は、上述のように分散環境で行うことができる。
【００５４】
図２は、ステートレスプロトコルを介してアクセスされるリソースの状態の維持を容易にするために使用可能な、機能構成要素の一部を示す図である。図２には、要求側コンピュータシステム２１０および提供側コンピュータシステム２３０が示されている。図２に示されたそれぞれのコンピュータシステムは、上述した同様の構成要素を含む汎用コンピュータシステムであってよい。図２に含まれるコンピュータシステムは、複雑かつフレキシブルな汎用処理機能を提供することができる。
【００５５】
ブラウザ２１２およびクッキー２１３は、記憶装置２１１に格納することができる。格納装置２１１は、メモリ１１２と同様であるか、または任意の他のタイプの物理記憶媒体であってよい。ブラウザ２１２は、提供側コンピュータシステムに含まれるリソースへのアクセス要求を容易にする、１または複数のモジュールを含むことができる。ブラウザ２１２は、例えばＨＴＴＰなどのステートレスプロトコルを介して、提供側コンピュータシステム２３０などの提供側コンピュータシステムに含まれるリソースにアクセスするための要求を送信することができる。
【００５６】
ブラウザ２１２は、提供側コンピュータシステム２３０または他の提供側コンピュータシステムのリソースへのアクセスを要求する際に、クッキー２１３に含まれる情報を使用することができる。ブラウザ２１２は、要求側コンピュータシステム２１０のユーザへのアクセスされたリソースの提示を容易にすることもできる。これには、ディスプレイ１０５と同様のディスプレイでの視覚的方法、またはスピーカ１０４と同様のスピーカでの音響方法により、アクセスされたリソースを出力することを含むことができる。
【００５７】
アクセス制御アプリケーション２３１およびリソース２３２を、提供側コンピュータシステム２３０に含めることができる。提供側コンピュータシステム２３０は、要求側コンピュータシステム２１０などの要求側コンピュータシステムから、ステートレスプロトコルを介して要求を受け取ることができる。アクセス制御アプリケーション２３１は、こうした要求に関連付けられた認証情報および妥当性検証情報を使用して、リソースへのアクセスを認可するべきか否かを判定することができる。提供側コンピュータシステム２３０がＨＴＴＰを介して（例えば要求側コンピュータシステム２１０からの）要求を受け取ると、アクセス制御アプリケーション２３１は、リソース２３２へのアクセスを認可するべきか否かを判定する際に、妥当性検証情報とともに要求に含まれるＨＴＴＰ認証情報を使用することができる。
【００５８】
図２には、ネットワーク２２０も含まれる。ネットワーク２２０は、ローカルエリアネットワーク、ワイドエリアネットワーク、インターネット、それらの組合せの一部、または電子データの移送を容易にすることができる任意の他のネットワークの一部を含むことができる。ネットワーク２２０は、ハードワイヤードリンク、ワイヤレスリンク、またはハードワイヤードリンクとワイヤレスリンクの組合せを含むことができる。ネットワーク２２０は、本発明の原理を実施する構成要素にアクセス可能にするようにデータの一部を条件付けるかまたはフォーマット化する、ソフトウェアまたはハードウェアモジュールを含むこともできる。こうした構成要素は、例えばプロキシ、ルータ、ファイアウォール、またはゲートウェイを含むことができる。ネットワーク２２０は、ＶＰＮの一部を含むこともできる。図２に示されるように、要求側コンピュータシステム２１０は、論理通信リンク２４０を介してネットワーク２２０と通信し、提供側コンピュータシステム２３０は、論理通信リンク２５０を介してネットワーク２２０と通信する。
【００５９】
図３は、高速ログアウトコマンドの実行を容易にすることができるいくつかの機能構成要素を示す図である。こうしたコマンドは、リソースに関連付けられたセッションをブラウザに対して「ログアウト」状態に移行させるために使用することができる。図３の矢印１で示されるように、ブラウザ３１２は、ログアウトモジュール３３２を実行させることができる。これにより、ブラウザ３１２上のセッションを、リソース３３３に対して「ログアウト」させることができる。セッションは、ブラウザ３１２のユーザがログアウトモジュール３３２を実行させるＵＲＩを選択すると、ログアウトすることができる。例えば、提供側コンピュータシステム３３０がＷｅｂサーバを含む場合には、Ｗｅｂサーバは、選択されるとログアウトモジュール３３２を実行させるＵＲＩを含むことができる。ログアウトモジュール３３２は、アクセス制御アプリケーション３３１がリソース３３３に関連付けられたタイムスタンプを押されたクッキーまたは使用量スタンプを押されたクッキーが満了したことを感知すると、実行されるようにすることもできる。提供側コンピュータシステム３３０は、要求側コンピュータシステム３１０からの要求で、タイムスタンプを押されたクッキーまたは使用量スタンプを押されたクッキーからの情報を受け取ることができる。
【００６０】
図４は、ログアウトクッキーの設定を容易にすることができるいくつかの機能構成要素を示す図である。図４の矢印２で示されるように、アクセス制御アプリケーション３３１がログアウトクッキー３１４を設定する。ログアウトクッキー３１４は、リソース３３３がブラウザセッションに対してログアウト状態であることを示す、例えば妥当性検証情報などのリソース３３３の状態に関連付けられた妥当性検証情報を含むことができる。妥当性検証情報は、リソースの状態を判定するためにアクセス制御アプリケーションが処理することのできる任意の情報を含むことができる。例えば、ログアウトクッキー３１４に含まれる妥当性検証情報は、リソース３３３の状態を判定するためにアクセス制御アプリケーション３３１が処理することができる。こうした妥当性検証情報は、リソース３３３に関連付けられたセッションがブラウザ３１２に対してログアウトされていることを示すことができる。いくつかの実施形態では、「妥当性検証開始」情報を使用して、リソースに関連付けられたセッションがログアウト状態であることを示すことができる。
【００６１】
ログアウトモジュール３３２がブラウザ３１２からの要求に応答して実行される場合には、ログアウトクッキーを、ブラウザ３１２にアクセス可能な場所に格納することができる。例えば図４に示されるように、ログアウトクッキー３１４はクッキー３１３に含まれ、ブラウザ３１２およびクッキー３１３はどちらも記憶装置３１１に格納される。
【００６２】
アクセス制御アプリケーションに含まれるモジュールは、妥当性検証情報を設定する際に、リソースに関連付けられた管理規則を参照することができる。例えば、ログアウトモジュール３３２は、ログアウトクッキー３１４内の妥当性検証情報を設定する際に、リソース３３３に関連付けられた管理規則を参照することができる。管理規則は、ハードコード化されるか、またはユーザインタフェースを介してユーザが構成することができる。例えば、提供側コンピュータシステム３３０が様々なネットワーク環境で動作する場合、ユーザは、１または複数の管理規則を構成して、様々なネットワーク環境の各々に対して様々な妥当性検証情報を指定することができる。ログアウトモジュール３３２を実行するとき、１または複数の管理規則を参照して、指定された妥当性検証情報をログアウトクッキー３１４に含めることができる。
【００６３】
妥当性検証情報は、特定の文字セットで符号化された電子テキストの形をとることができる。電子テキストの符号化には、各文字に固有の数値を割り当てることが含まれる。コンピュータシステムが特定の文字に関連付けられた数値を解釈すれば、関連付けられた文字でオペレーションを実行していることがわかる。例えば、文字「ａ」は１６進数値６１で表すことができる。コンピュータシステムが文字オペレーションを実行中であり、１６進数値６１を受け取ると、コンピュータシステムは文字「ａ」でオペレーションを実行していることがわかる。
【００６４】
電子テキストは、数値をテキスト文字表現に対応させる仮想上の任意の技法を使用して符号化することができる。ただし、符号化技法の中にはより一般的なものもある。ＡＳＣＩＩ（Ａｍｅｒｉｃａｎ　Ｓｔａｎｄａｒｄ　Ｃｏｄｅ　ｆｏｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｘｃｈａｎｇｅ）文字セットは、各文字に０から１２７の間の数を割り当てた、英文字を表すためのコードである。ＩＳＯ　Ｌａｔｉｎ　１文字セットは、各文字に０から２５５の間の数を割り当てた、ＡＳＣＩＩ文字セットのスーパーセットである。割当てに使用できる数を増やせば、文字セットのユーザが使用できる様々な文字の数も増える。これにより文字セットに特殊記号を含めることが可能になり、１つの文字セットが様々な言語間で使用できるようになる。
【００６５】
ＡＮＳＩ文字セットは、米国規格協会（Ａｍｅｒｉｃａｎ　Ｎａｔｉｏｎａｌ　Ｓｔａｎｄａｒｄｓ　Ｉｎｓｔｉｔｕｔｅ）が採用する特殊文字と関連コードの集まりである。ＡＮＳＩ文字セットには、多くの異なる言語、特殊句読点、およびビジネス記号に関する文字が含まれる。
【００６６】
日本語の文字を符号化するのに使用されるいくつかの文字セットがある。これらの文字セットの多くは日本工業規格（Ｊａｐａｎｅｓｅ　Ｉｎｄｕｓｔｒｉａｌ　Ｓｔａｎｄａｒｄｓ）に基づくものであり、例えばＪＩＳ　Ｘ　０２０８−１９９０などのように「ＪＩＳ」で始まるコードによって識別される。
【００６７】
ユニコードは、６５，０００を超える固有文字を割り当てることができる、文字を表すための規格である。ユニコードは、現在様々な符号化技法を使用することができるプログラムとプラットフォームとの間の相互運用性を促進するために開発された。同じ数が異なる文字を表す可能性があるか、または異なる数が同じ文字を表す可能性のある、様々な符号化技法を使用する場合はリスクがある。ユニコードは６５，０００を超える固有文字を表すことができるため、ギリシャ、中国、および日本を含むほとんどの言語のすべての文字を、１つの文字セットに含めることができる。
【００６８】
転送符号化とは、特定モードの伝送に関する文字セットの数値を表すための方式である。文字セットは、例えば１６ビット値のような第１の大きいフォーマットに格納されるが、例えば８ビットの第２の小さなフォーマットのデータストリームで伝送される、数値を含むことができる。従って、文字セットの数値を再フォーマット化、または「転送用に符号化」することにより、第２の小さなフォーマットに適合するようにしなければならない。例えば、１６ビットのユニコード値は、ＷＷＷに関連付けられた７ビットまたは８ビットのデータストリーム内に配置する前に、転送用に符号化する必要が生じる可能性がある。
【００６９】
転送のための文字セットの符号化は、多種多様の技法を使用して実行することができる。転送符号化技法の中には、例えばＩＳＯ−２０２２−ＪＰ（ＪＩＳ）符号化、ＥＵＣ−ＪＰ符号化、およびＳｈｉｆｔ−ＪＩＳ符号化などの、日本語の文字を転送用に符号化する際に専用に使用されるものがある。日本語文字セットおよび対応する転送符号化方式を使用することにより、日本語の文字をネットワーク化されたコンピュータシステムの間、例えばＷＷＷ上の提供側コンピュータシステムと要求側コンピュータシステムの間などで転送することができる。
【００７０】
本説明および特許請求の範囲では、電子テキストおよび電子テキストの転送を参照することができる。上述のテキスト符号化技法および転送符号化技法は単なる例示であることを理解されたい。本発明は、これらの記載されたテキスト符号化技法または記載された転送符号化技法に限定されるものではない。当業者が本説明を再検討した後には、上述のものに加えて、様々なテキスト符号化技法および転送符号化技法を使用して、本発明の原理を実施できることが明らかになろう。
【００７１】
いくつかの実施形態では、妥当性検証情報は、単一文字の電子テキストを含むことができる。例えば、単一文字の電子テキストをログアウトクッキー３１４に含めることができる。単一文字のテキストをアクセス制御アプリケーション３３１が処理することで、リソース３３３に関連付けられたセッションがブラウザ３１２に対してログアウト状態にあると判定することができる。他の実施形態では、妥当性検証情報は、複数文字のテキストを含むことができる。妥当性検証情報を使用して、リソースに関連付けられたセッションをログアウト状態またはログイン状態に移行させることができる。ただし、妥当性検証情報全体が拡張可能であるので、妥当性検証情報に含めることのできる文字の数および配置構成は、仮想上無制限であり、リソースの状態は、必ずしもログインおよびログアウト状態に限定されるものではない。
【００７２】
図５は、リソースへのアクセス要求を容易にすることができるいくつかの機能構成要素を示す図である。図５の矢印１によって示されるように、ブラウザ４１２は、リソース４３３へのアクセスを要求する。ブラウザ４１２によるこうした要求は、認証ヘッダ、例えば「ＷＷＷ−認証」ヘッダの送信を含むことができる。アクセス制御アプリケーション４３１は、認証ヘッダに含まれる認証情報を処理して、認証情報がリソース４３３へのアクセスに適切であるか否かを判定することができる。アクセス制御アプリケーション４３１は、妥当性検証情報を処理して、ブラウザ４１２に対してリソース４３３へのアクセスを要求するセッションの状態を判定することもできる。
【００７３】
図６は、タイムスタンプを押されたクッキーの設定を容易にすることができるいくつかの機能構成要素を示す図である。図６の矢印２に示されるように、アクセス制御アプリケーション４３１は、タイムスタンプを押されたクッキー４１４を設定する。タイムスタンプを押されたクッキー４１４は、リソース４３３に関連付けられたセッションの状態を示す妥当性検証情報を含むことができる。タイムスタンプモジュールは、リソースへのアクセス要求（例えばＨＴＴＰ要求）が認可（または拒否）されると、タイムスタンプを押されたクッキーを設定することができる。例えば、タイムスタンプモジュール４３２は、アクセス制御アプリケーション４３１がリソース４３３へのアクセスを認可すると、タイムスタンプを押されたクッキー４１４を設定することができる。
【００７４】
ブラウザ４１２からの要求に応答してタイムスタンプモジュール４３２が実行されると、タイムスタンプを押されたクッキーをブラウザ４１２にアクセス可能な場所に格納することができる。例えば、図６に示されるように、タイムスタンプクッキー４１４は、クッキー４１３に含まれ、ブラウザ４１２およびクッキー４１３は、どちらも記憶装置４１１に格納される。
【００７５】
タイムスタンプモジュール４３２は、タイムスタンプクッキー４１４の妥当性検証情報を設定するときに、リソース４３３に関連付けられた管理規則を参照することができる。こうした管理規則は、リソース４３３に関連付けられたセッションが、ブラウザ４１２に対してログイン状態にある時間を指定することができる。管理規則は、１または複数の時間パラメータを妥当性検証情報に含めることができる。テキスト「Ｔ＝＜ｔｉｍｅ　ｖａｌｕｅ＞」を妥当性検証情報に含めることができる。こうした妥当性検証情報では、「Ｔ」はリソースのログイン状態が満了するべき時間を表すパラメータであってよく、「＜ｔｉｍｅ　ｖａｌｕｅ＞」は、そのパラメータの値である。
【００７６】
時間パラメータは、提供側コンピュータシステムのシステム時間に従って設定することができる。例えば、提供側コンピュータシステム４３０のシステム時間が、２００１年１１月１日９時００分００秒であり、２時間の満了時間が要求されると、妥当性検証情報「Ｔ＝１１：００：００　１１／１／２００１」をタイムスタンプクッキー４１４に含めることができる。あるいは、ログイン時間と満了時間を妥当性検証情報に含めることができる。例えば、妥当性検証情報「ｌｏｇｉｎ　Ｔ＝９：００：００　１１／１／２００１　ｅｘｐｉｒｅ　Ｔ＝１１：００：００　１１／１／２００１」をタイムスタンプクッキー４１４に含めることができる。こうした妥当性検証情報では、テキスト「ｌｏｇｉｎ」は、その後のＴパラメータが、リソースがログイン状態に配置された時間であることを示し、テキスト「ｅｘｐｉｒｅ」は、その後のＴパラメータが、ログイン状態が満了するべき時間であることを示すことができる。時間パラメータは、時、分、または秒などの時間の増分であってよい。例えば、妥当性検証情報「Ｔ＝２」をタイムスタンプクッキー４１４に含めることができる。こうした妥当性検証情報では、テキスト「Ｔ＝２」は、リソースのログイン状態がログイン状態を開始した時間から２時間で満了するべきであることを示すことができる。増分時間パラメータは、絶対時間パラメータと組み合わせることができる。例えば、妥当性検証情報「ｌｏｇｉｎ　Ｔ＝９：００：００　１１／１／２００１　ｅｘｐｉｒｅ　Ｔ＝２」をタイムスタンプクッキー４１４に含めることができる。こうした妥当性検証情報では、テキスト「ｅｘｐｉｒｅ　Ｔ＝２」は、ログイン状態が２００１年１１月１日９時００分００秒の２時間後に満了するべきであることを示すことができる。
【００７７】
いくつかの実施形態では、アクセス制御アプリケーションに含まれた使用量スタンプモジュールは、使用量スタンプを押されたクッキーの妥当性検証情報を設定するときに、リソースに関連付けられた管理規則を参照することができる。こうした管理規則は、ログイン状態が満了するまでにブラウザがリソースにアクセスできる回数を指定することができる。例えば、アクセス制御アプリケーション４３１に含まれる使用量スタンプモジュール（図示せず）は、ログイン状態が満了するまでにブラウザ４１２がリソース４３３にアクセスできる回数を指定する、管理規則を参照することができる。管理規則は、１または複数の使用量パラメータを妥当性検証情報に含めることができる。例えば、テキスト「Ｎ＝＜ｎｕｍｂｅｒ＞」を妥当性検証情報に含めることができる。こうした妥当性検証情報では、「Ｎ」は、リソースのログイン状態が満了する前にリソースにアクセスできる回数を表すパラメータであってよく、「＜ｎｕｍｂｅｒ＞」は、そのパラメータの値である。
【００７８】
上述のパラメータは、英語の文字を使用して図示されているが、タイムスタンプまたは使用量スタンプを押されたクッキーのパラメータには、例えば日本語などの他の言語の文字を含めることもできる。
【００７９】
パラメータの組合せを妥当性検証情報に含めることもできる。例えば妥当性検証情報は、リソースへのアクセスが３０分後に、またはリソースへのアクセスが５回になった後に、満了するものであることを示すことができる。
【００８０】
これらは、妥当性検証情報に含めることのできるパラメータの一例に過ぎないことを理解されたい。当業者が本説明を再検討した後には、リソースの状態を判定する際の一助として、様々なパラメータを妥当性検証情報に含められることが明らかとなろう。
【００８１】
図７は、リソースへのアクセスを認可するべきか否かを判定する際に妥当性検証情報を使用できる、いくつかの機能構成要素の一例を示す図である。図１２は、リソースへのアクセスを認可するべきか否かを判定する際に妥当性検証情報を使用するための方法の一例を示す流れ図である。図１２の方法について、図７に含まれる機能構成要素を参照しながら論じる。
【００８２】
図１２の方法は、認証情報を必要とするリソースへのアクセス要求の受取で開始される（動作８０１）。図７の矢印１で示されるように、これはブラウザ５１２から要求を受け取るアクセス制御アプリケーション５３１を含むことができる。ブラウザ５１２からのリソース５３３へのアクセス要求は、妥当性検証クッキー５１４に格納される情報を自動的に含むことができる。情報の要求は、キャッシュされた認証情報５１５にブラウザ５１２によってキャッシュされた認証情報を含むこともできる。従って、ブラウザ５１２は、リソース５３３へのアクセスを要求すると、認証情報は自動的にこの要求に含まれる。場合によっては、認証が事前にキャッシュされていないことがある。これらの場合には、手作業で入力した認証情報を要求に含めることができる。
【００８３】
妥当性検証情報を追加し、認証情報とともに後に使用して、リソースへのアクセスを認可するべきか否かを判定することができる（動作８０２）。図１４は、認証情報と妥当性検証情報との関係を示す図の一例である。図１４に示されるように、要求が適切な認証情報を含み、ログイン状態を示す妥当性検証情報に関連付けられているとき、リソースへのアクセスを認可することができる。図１４によれば、アクセス制御アプリケーション５３１は、受け取った認証情報を処理し、認証情報がリソース５３３へのアクセスに適したものであるか否かを判定することができる。同様に、妥当性検証モジュール５３２は、妥当性検証情報を処理し、受け取った認証情報がログイン状態を示すかどうかを判定することができる。従って、認証情報がリソース５３３へのアクセスに適しており、妥当性検証情報がリソース５３３に関連付けられたセッションがログイン状態にあることを示す場合には、リソース５３３へのアクセスを認可することができる。
【００８４】
妥当性検証情報は、リソースに関連付けられたクッキーに含めることによって、リソースへのアクセス要求に関連付けることができる。図７には、ブラウザ５１２に対するリソース５３３の状態を示す妥当性検証情報を含むことができる、妥当性検証クッキー５１４が示されている。すなわち、こうした妥当性検証情報は、リソース５３３に関連付けられたセッションが、ブラウザ５１２に対してログイン状態にあるかログアウト状態にあるかを示すことができる。
【００８５】
いくつかの実施形態では、リソースに関連付けられた妥当性検証情報を、クッキー識別子を介して索引付けされた状態テーブルに含めることができる。リソースへのアクセス要求が受け取られると、状態テーブルは、リソースの状態を示す妥当性検証情報を提供することができる。例えば、アクセス制御アプリケーション５３１がリソース５３３へのアクセス要求を受け取ると、妥当性検証モジュール５３２は、状態テーブルの索引付けされたエントリを参照して、リソース５３３に関連付けられたセッションがログイン状態にあるかログアウト状態にあるかを判定することができる。
【００８６】
図１３は、認証情報が手作業で入力される機会を増やす方法で妥当性検証情報を使用するための方法の一例を示す流れ図である。図８、９および１０は、認証情報を手作業で再入力する機会を増やすのを容易にすることができる、いくつかの機能構成要素を示す図である。図１３の方法について、図８、９および１０に含まれる機能構成要素を参照しながら論じる。
【００８７】
図１３の方法は、リソースへの第１のアクセス要求を受け取ることで開始される（９０１）。図８の矢印１で示されるように、これはブラウザ６１２から要求を受け取るアクセス制御アプリケーション６３１を含むことができる。こうした要求は、認証情報（例えば、ブラウザ６１２によって事前にメモリにキャッシュされた認証情報）ならびに妥当性検証開始クッキー６１４からの妥当性検証情報を含むことができる。アクセス制御アプリケーションは、認証情報を処理して、認証情報が適切かどうかを判定することができる。同様に、妥当性検証モジュール６３２は、妥当性検証開始クッキー６１４からの妥当性検証情報を処理して、リソース６３３の状態を判定することができる。いくつかの実施形態では、妥当性検証モジュール６３２は、状態テーブルからのリソース６３３に関連付けられたセッションに関する妥当性検証情報にアクセスすることができる。
【００８８】
図１３の方法は、後続のリソースへのアクセス要求において、妥当性検証情報をリソースに関連付けるためのステップを含むことができる（ステップ９０５）。これは、リソース６３３に関連付けられたセッションがログイン状態にないことを判定する、妥当性検証モジュール６３２を含むことができる。いくつかの実施形態では、妥当性検証開始クッキー６１４が、リソース６３３に関連付けられたセッションがログアウト状態であることを示す妥当性検証情報を含む、ログアウトクッキーであってよい。ログアウト状態を示す妥当性検証情報が妥当性検証モジュール６３２で受け取られると、妥当性検証モジュール６３２は、アクセス制御アプリケーション６３２に要求を拒否させることができる。
【００８９】
いくつかの実施形態では、妥当性検証モジュール６３２は、リソース６３３に関連付けられたセッションがログアウト状態にあることを示す状態テーブルからの妥当性検証情報にアクセスすることができる。
【００９０】
同様にいくつかの実施形態では、妥当性検証開始クッキー６１４は、タイプスタンプを押されたクッキー４１４と同様のタイプスタンプを押されたクッキー、または使用量スタンプを押されたクッキーであってよい。従って、妥当性検証開始クッキー６１４は、セッションのリソース６３３へのアクセスが満了したことを示す妥当性検証情報を含むことができる。妥当性検証モジュール６３２がタイムスタンプを押されたかまたは使用量スタンプを押されたクッキーから情報を受け取ると、妥当性検証モジュール６３２は、リソースへのアクセスが満了したか否かを判定するための比較を行うことができる。これは、妥当性検証情報に含まれるパラメータと、妥当性検証情報に含まれる他のパラメータまたは提供側コンピュータシステムのパラメータとの比較を含むことができる。例えば、妥当性検証モジュール６３２は、妥当性検証情報「ｌｏｇｉｎ　Ｔ＝９：００：００　１１／１／２００１　ｅｘｐｉｒｅ　Ｔ＝２」に含まれる時間パラメータに関する比較を実行して、２００１年１１月１日９時００分００秒の２時間後であるか否かを判定することができる。パラメータの比較は、使用量パラメータの比較を含むこともできる。例えば、妥当性検証モジュール６３２は、妥当性検証情報「Ｎ＝３」に含まれる使用量パラメータに関する比較を実行して、リソースがすでに３回アクセスされているかどうかを判定することができる。セッションのリソースへのアクセスが、時間または使用量により満了すると、妥当性検証モジュール６３２は、セッションをあたかもログアウト状態にあるかのようにみなすことができる。
【００９１】
いくつかの実施形態では、妥当性検証モジュール６３２は、状態テーブルからアクセスされた時間および使用量パラメータを比較することができる。
【００９２】
これらは、リソースの状態を判定する際に実行することができる比較の種類の例に過ぎないことを理解されたい。当業者が本説明を再検討した後には、リソースの状態を判定する際に様々な比較が実行可能であることを理解されよう。
【００９３】
図９をより詳細に参照すると、妥当性検証モジュール６３２が、リソース６３３に関連付けられたセッションがブラウザ６１２に対してログアウト状態にあると判定した場合には、妥当性検証モジュール６３２は、１または複数の処理機能を実行させることができる。妥当性検証モジュール６３２は、ブラウザ６１２のリソース６３３へのアクセス要求を拒否させることができる。図９の矢印２で示されるように、妥当性検証モジュール６３２は、未許可応答をブラウザ６１２に送信させることもできる。ＨＴＴＰを使用してメッセージ送信が実行される場合、これは「４０１　Ｕｎａｕｔｈｏｒｉｚｅｄ」応答を含むことができる。
【００９４】
さらに図９の矢印２で示されるように、妥当性検証モジュール６３２は、クッキー６１３で妥当性検証終了クッキー６１５を設定することもできる。これは、リソースに関連付けられた妥当性検証情報を設定するための管理規則の参照に対応する動作として、ステップ９０５に含めることができる（動作９０２）。すなわち、妥当性検証モジュール６３２は、妥当性検証終了クッキー６１５で妥当性検証情報を設定する場合に、管理規則を参照することができる。管理規則は、ブラウザ６１２が未許可メッセージを返されたことを示す、妥当性検証情報を指定することができる。妥当性検証終了クッキー６１５に含まれる妥当性検証情報は、１文字または複数文字の電子テキストであってよい。妥当性検証情報全体が拡張可能であるため、妥当性検証終了クッキー６１５に含めることのできる文字の数および配置構成は、仮想上無制限である。
【００９５】
ステップ９０５は、妥当性検証情報を含むリソースへの第２のアクセス要求を受け取るという動作を含むこともできる（動作９０３）。これは、妥当性検証終了クッキー６１５に含まれる妥当性検証情報の受取も含むことができる。図１０の矢印３に示されるように、ブラウザ６１２は、手作業で再入力された認証情報を使用して、リソース６３３へのアクセスを要求することができる。妥当性検証終了クッキー６１５に含まれる妥当性検証情報は、要求が手作業で再入力された認証情報を含むことを示すことができる。
【００９６】
リソースへのアクセス要求が拒否されると、要求が拒否されたかユーザが未許可であることを示す未許可メッセージを、妥当性検証モジュールから要求側コンピュータシステムへ送信することができる。妥当性検証モジュールは、ユーザが自分の認証情報を再入力できるフォームを送信することもできる。こうしたフォームは、妥当性検証モジュール（例えば、妥当性検証モジュール６３２）の制御下であってよい。この拒否メッセージを送信し、再入力された認証情報をユーザから受け取った後、妥当性検証モジュールは、クッキー内にあるかまたはクッキーに関連付けられたセッション妥当性検証情報を更新することができる。いくつかの実施形態では、妥当性検証モジュールは、フォームに入力された信用状と、ＨＴＴＰ要求のＷＷＷ−許可ヘッダに含まれる信用状とを比較することができる。これにより、妥当性検証モジュールが認証データベースにコンタクトする必要が軽減できる。
【００９７】
妥当性検証情報を認証情報とともに使用して、リソースへのアクセスを認可するべきか否かを判定することができる（動作９０４）。これは、認証情報を処理するアクセス制御アプリケーション６３１と、妥当性検証情報を処理する妥当性検証モジュール６３２とを含むことができる。図１４によれば、アクセス制御アプリケーション６３１は、受け取った認証情報を処理して、認証情報がリソース６３３へのアクセスに適しているかどうかを判定することができる。同様に妥当性検証モジュール６３２は、妥当性検証情報を処理して、受け取った認証情報がログイン状態にあるセッションに関連付けられているかどうかを判定することができる。従って、認証情報がリソース６３３へのアクセスに適しており、妥当性検証情報がリソース６３３に関連付けられたセッションがログイン状態にあることを示す場合、リソース６３３へのアクセスを認可することができる。
【００９８】
リソースに関連付けられたセッションの状態を妥当性検証開始状態から妥当性検証終了状態に変えることは、セッションの状態を表すための妥当性検証情報の使用例に過ぎないことを理解されたい。当業者が本説明を再検討した後には、セッションの様々な状態を表す際に妥当性検証情報が使用できることが明らかになろう。図１１には、例えばＨＴＴＰなどのステートレスプロトコルを介してアクセスされたリソースに関連付けられたセッションに対して維持することができる状態を含む、状態テーブルの一例が示されている。
【００９９】
図１１は、「入口状態」、「妥当性検証モジュール動作」、および「出口状態」の３つの列を示す。入口状態は、リソースへのアクセス要求が受け取られる前のセッションの状態を表す。例えば、リソースに関連付けられたセッションがログインされると、リソースは有効状態であるとみなすことができる。妥当性検証モジュール動作は、妥当性検証情報を含む受け取られた要求に関して実行される処理オペレーションを表す。例えば、妥当性検証モジュールは、ログアウト開始クッキーからの妥当性検証情報を処理して、リソースに関連付けられたセッションがログアウト状態であることを判定することができる。出口状態は、妥当性検証モジュールが処理オペレーションを実行した後のセッションの状態を表す。例えば、妥当性検証モジュールは、満了したクッキーを処理し、セッションをログイン状態からログアウト状態に移行させることができる。
【０１００】
図１１に示されるように、リソースの状態にはＮＯＮＥ、ＶＡＬＩＤ、ＶＡＬＩＤＡＴＩＯＮ　ＢＥＧＩＮおよびＶＡＬＩＤＡＴＩＯＮ　ＥＮＤが含まれる。ＮＯＮＥ状態は、ブラウザがこれまでにリソースへのアクセスを１回も要求したことがなく、従って要求が妥当性検証情報に関連付けられていない場合に発生する。妥当性検証モジュールは、妥当性検証モジュールの構成に応じて、ＮＯＮＥ状態をログイン状態またはログアウト状態とみなすことができる。どんな妥当性検証情報にも関連付けられていない要求を受け取ると、これに応答して、妥当性検証モジュールは、セッションに対してなんらかの妥当性検証情報を設定するために管理規則を参照することができる。これには、クッキーまたは状態テーブル内で妥当性検証情報を設定することを含めることができる。妥当性検証モジュールは、ＶＡＬＩＤ状態をログイン状態とみなすことができる。妥当性検証モジュールは、ＶＡＬＩＤ状態にあるリソースへのアクセス要求を認めることができる。
【０１０１】
妥当性検証モジュールが、高速ログアウトコマンドを含む要求を受け取るか、またはリソースへのアクセスが満了したことを示す妥当性検証情報を検出すると、妥当性検証モジュールは、ＶＡＬＩＤＡＴＩＯＮ　ＢＥＧＩＮ状態を示す妥当性検証情報を設定することができる。妥当性検証モジュールは、ＶＡＬＩＤＡＴＩＯＮ　ＢＥＧＩＮ状態を、リソースに関連付けられたセッションがログアウト状態にあり、および／または認証情報が再入力される状態とみなすことができる。妥当性検証モジュールがブラウザに未許可メッセージを戻した後の要求において、認証情報が受け取られると、妥当性検証モジュールは、ＶＡＬＩＤＡＴＩＯＮ　ＥＮＤ状態を示す妥当性検証情報を設定することができる。妥当性検証モジュールは、ＶＡＬＩＤＡＴＩＯＮ　ＥＮＤ状態をログイン状態とみなすことができる。
【０１０２】
妥当性検証情報を使用することにより、ステートレスプロトコルを介したリソースへのアクセスに関連付けられたセッションに対して認証状態を維持することができる。状態は、ステートレスプロトコルに固有の技法を使用して維持することができる。その結果、別のアプリケーションレベルの認証基盤、および専用のブラウザの修正は不要である。これにより、状態を維持する機能を実行するモジュールを作成するために必要なプログラミングリソースは減少し、既存のオペレーティングシステムに適合する機会が増加する。
【０１０３】
本発明は、その精神または本来の特徴を逸脱することなく、他の特有の形式で実施することができる。記載された実施形態は、すべての点で例示的なものに過ぎず、限定的なものではない。従って本発明の範囲は、上述の内容ではなく特許請求の範囲によって示されるものである。特許請求の範囲の均等物の意図および範囲内にあるすべての変更は、その範囲内に包含されるものとする。
【図面の簡単な説明】
【図１】本発明に好適なオペレーティング環境を提供する電話デバイスの一例を示す図である。
【図２】ステートレスプロトコルを介してアクセスされるリソースの認証状態を容易に維持できるいくつかの機能構成要素の一例を示す図である。
【図３】高速ログアウト機能の実施を容易にするいくつかの機能構成要素の一例を示す図である。
【図４】ログアウトクッキーの設定を容易にするいくつかの機能構成要素の一例を示す図である。
【図５】リソースへのアクセス要求を容易にするいくつかの機能構成要素の一例を示す図である。
【図６】タイムスタンプを押されたクッキーの設定を容易にするいくつかの機能構成要素の一例を示す図である。
【図７】リソースへのアクセスを認可するべきか否かを判定する際に妥当性検証情報を使用することができる、いくつかの機能構成要素の一例を示す図である。
【図８】妥当性検証開始クッキーを使用したリソースへのアクセス要求を容易にするいくつかの機能構成要素の一例を示す図である。
【図９】未許可の応答を戻すことおよび妥当性検証終了クッキーの設定を容易にするいくつかの機能構成要素の一例を示す図である。
【図１０】手作業で入力した認証情報を使用したリソースへのアクセス要求を容易にするいくつかの機能構成要素の一例を示す図である。
【図１１】ステートレスプロトコルを介してアクセスしたリソースに対して維持可能な状態を含む状態テーブルの一例を示す図である。
【図１２】リソースへのアクセスを認可するべきか否かを判定する際に妥当性検証情報を使用するための方法の一例を示す流れ図である。
【図１３】認証情報が手作業で入力される機会を増やす方法で妥当性検証情報を使用するための方法の一例を示す流れ図である。
【図１４】認証情報と妥当性検証情報との関係を示す図の一例である。
【符号の説明】
２１０　要求側コンピュータシステム
２１１　記憶装置
２１２　ブラウザ
２１３　クッキー
２２０　ネットワーク
２３０　提供側コンピュータシステム
２３１　アクセス制御アプリケーション
２３２　リソース
２４０，２５０　論理通信リンク
【図１】
2004005638.tif 000003
【図２】
2004005638.tif 000004
【図３】
2004005638.tif 000005
【図４】
2004005638.tif 000006
【図５】
2004005638.tif 000007
【図６】
2004005638.tif 000008
【図７】
2004005638.tif 000009
【図８】
2004005638.tif 000010
【図９】
2004005638.tif 000011
【図１０】
2004005638.tif 000012
【図１１】
2004005638.tif 000013
【図１２】
2004005638.tif 000014
【図１３】
2004005638.tif 000015
【図１４】
2004005638.tif 000016