(57)【特許請求の範囲】
【請求項１】
カスタマイズされたセキュリティを提供するように構成されたサーブレットエンジンを含むコンピュータシステムであって、
前記サーブレットエンジンは、
選択された認証プロトコルおよび許可プロトコルを含むカスタマイズされたセキュリティプロトコルに従ってリクエストの検査を行うように構成されたセキュリティモジュールであって、前記認証プロトコルは、前記サーブレットエンジンによって受信されたリクエストが検証済みの発信源を有していることを確認するものであり、前記許可プロトコルは、前記検証済みの発信源が適切な許可を有していることを確認するものであり、前記サーブレットエンジンによって受信されたリクエストが前記カスタマイズされたセキュリティプロトコルのいずれかの検査で失敗したときに、前記セキュリティモジュールが、失敗したセキュリティプロトコル検査に対応するカスタマイズされたエラーコードを生成する、カスタマイズされたセキュリティモジュールと、
前記カスタマイズされたセキュリティモジュールに接続されたロギングモジュールであって、前記検証済みの発信源から発生していないか、または、適切な許可を有していない前記受信されたリクエストを記録するとともに、前記カスタマイズされたエラーコードを記録し、記録される前記カスタマイズされたエラーコードの種類によって前記失敗したセキュリティプロトコル検査の種類を決定できるように構成されたロギングモジュールと、
前記カスタマイズされたセキュリティモジュールと前記ロギングモジュールとに接続され、前記カスタマイズされたセキュリティモジュールにより認証および許可されて前記ロギングモジュールによって登録された前記受信されたリクエストのみを処理するように構成されたサーブレットと、
を含むサーブレットコンテナを備えた、コンピュータシステム。
【請求項２】
請求項１記載のコンピュータシステムであって、
前記サーブレットエンジンはサーバ内に含まれている、コンピュータシステム。
【請求項３】
請求項２記載のコンピュータシステムであって、
前記サーバは、前記サーブレットエンジンによって受信された前記リクエストを生成することができるクライアントアプリケーションに接続されている、コンピュータシステム。
【請求項４】
請求項３記載のコンピュータシステムであって、
前記クライアントアプリケーションはウェブブラウザであり、前記サーバはウェブサーバであり、前記リクエストは、リクエストされたドキュメントが格納されているデータベースを有したホストコンピュータを特定するｈｔｔｐリクエストである、コンピュータシステム。
【請求項５】
請求項４記載のコンピュータシステムであって、
前記データベースは前記サーブレットエンジンに接続されており、前記リクエストは、前記データベースに格納された情報を獲得するために前記データベースにアクセスするのに必要とされるデータベースアクセスリクエストである、コンピュータシステム。
【請求項６】
請求項４又は５に記載のコンピュータシステムであって、
前記サーブレットは、前記ウェブブラウザにｈｔｔｐレスポンスを提供することにより前記ｈｔｔｐリクエストに応える、コンピュータシステム。
【請求項７】
請求項４ないし６のいずれかに記載のコンピュータシステムであって、
前記ウェブブラウザは、ユーザが供給した入力に応えて前記ｈｔｔｐリクエストを生成するように構成されたアプレットを含む、コンピュータシステム。
【請求項８】
請求項４ないし７のいずれかに記載のコンピュータシステムであって、
前記ウェブブラウザによりセッションが開始されるときに、前記カスタマイズされたセキュリティモジュールにより前記ウェブブラウザにクッキーが提供され、前記クッキーは、前記セッション中に引き続いてなされるｈｔｔｐリクエストが、前記サーブレットにより直接処理されるために前記カスタマイズされたセキュリティモジュールを迂回するのに使用される、コンピュータシステム。
【請求項９】
請求項８記載のコンピュータシステムであって、
前記カスタマイズされたセキュリティモジュールは、前記クッキーが有効なクッキーであるかを周期的に決定する、コンピュータシステム。
【請求項１０】
請求項９記載のコンピュータシステムであって、
前記有効なクッキーは期限切れでないクッキーである、コンピュータシステム。
【請求項１１】
請求項４ないし１０のいずれかに記載のコンピュータシステムであって、
前記ウェブサーバは前記ホストコンピュータ内に存在しており、前記ホストコンピュータはコンピュータのインターネットネットワークの一部である、コンピュータシステム。
【請求項１２】
サーブレットエンジンに接続された保護リソースにアクセスする方法であって、
選択された認証プロトコルおよび許可プロトコルを含むカスタマイズされたセキュリティプロトコルに従ってリクエストの検査を行うように構成されたセキュリティモジュールであって、前記認証プロトコルは、前記サーブレットエンジンによって受信されたリクエストが検証済みの発信源を有していることを確認するものであり、前記許可プロトコルは、前記検証済みの発信源が適切な許可を有していることを確認するものであり、前記サーブレットエンジンによって受信されたリクエストが前記カスタマイズされたセキュリティプロトコルのいずれかの検査で失敗したときに、前記セキュリティモジュールが、失敗したセキュリティプロトコル検査に対応するカスタマイズされたエラーコードを生成する、カスタマイズされたセキュリティモジュールを提供し、
前記カスタマイズされたセキュリティモジュールに接続されたロギングモジュールであって、前記検証済みの発信源から発生していないか、または、適切な許可を有していない前記受信されたリクエストを記録するとともに、前記カスタマイズされたエラーコードを記録し、記録される前記カスタマイズされたエラーコードの種類によって前記失敗したセキュリティプロトコル検査の種類を決定できるように構成されたロギングモジュールを提供し、
受信したアクセスリクエストが検証済み発信源から発生しているかを前記認証プロトコルに基づいて、また、前記受信したアクセスリクエストが適切な許可を有しているかを前記許可プロトコルに基づいて、前記カスタマイズされたセキュリティモジュールにより決定し、
前記検証済み発信源から発生していないか、または、適切な許可を有していない前記アクセスリクエストに対応するカスタマイズされたエラーコードを、前記ロギングモジュールにより記録し、
前記セキュリティモジュールにより認証および許可された前記受信されたアクセスリクエストを、サーブレットにより処理し、
前記セキュリティモジュールにより認証および許可されて前記サーブレットにより処理されたアクセスリクエストを、前記サーブレットにより第１のタイプのフラグを用いて前記ロギングモジュールに通知し、
前記第１のタイプのフラグで識別された前記アクセスリクエストのために、前記保護リソースへのアクセスを前記サーブレットにより提供すること、
を備えた方法。
【請求項１３】
請求項１２記載の方法であって、
前記保護リソースはデータベースである、方法。
【請求項１４】
請求項１３記載の方法であって、
前記アクセスリクエストはデータベースアクセスリクエストである、方法。
【請求項１５】
請求項１４記載の方法であって、
前記サーブレットエンジンは、前記保護データベースに接続されたホストコンピュータ内に存在する、方法。
【請求項１６】
請求項１５記載の方法であって、
前記ホストコンピュータはクライアントアプリケーションに接続されており、前記クライアントアプリケーションはｈｔｔｐリクエストの形で前記データベースアクセスリクエストを生成する、方法。
【請求項１７】
請求項１６記載の方法であって、
前記クライアントアプリケーションは、ユーザが供給した入力に前記ｈｔｔｐリクエストを生成することにより応えるアプレットを有する、方法。
【請求項１８】
保護されたリソースへのアクセスを提供するための装置であって、
選択された認証プロトコルおよび許可プロトコルを含むカスタマイズされたセキュリティプロトコルに従ってリクエストの検査を行うように構成されたセキュリティモジュールであって、前記認証プロトコルは、サーブレットエンジンによって受信されたリクエストが検証済みの発信源を有していることを確認するものであり、前記許可プロトコルは、前記検証済みの発信源が適切な許可を有していることを確認するものであり、前記サーブレットエンジンによって受信されたリクエストが前記カスタマイズされたセキュリティプロトコルのいずれかの検査で失敗したときに、前記セキュリティモジュールが、失敗したセキュリティプロトコル検査に対応するカスタマイズされたエラーコードを生成する、カスタマイズされたセキュリティモジュールを提供するセキュリティプロトコル提供手段と、
保護リソースアクセスリクエストの発信源が検証済みかを、前記選択された認証プロトコルに基づいて決定することにより認証を行うための認証手段と、
前記保護アクセスリクエストの発信源が適切な保護リソースアクセス許可を有するかを、前記選択された許可プロトコルに基づいて決定することにより許可を行うための許可手段と、
前記許可手段に接続され、前記認証手段によって認証されるとともに前記許可手段によって許可された前記保護リソースアクセスリクエストにサービスするためのリクエストハンドル手段と、
前記認証手段および前記許可手段に接続され、サービスされた保護リソースアクセスリクエストのみでなく、認証に失敗した保護リソースアクセスリクエストと、許可に失敗した保護リソースアクセスリクエストと、カスタマイズされたエラーコードとを記録するためのロギング手段と、
を備えた装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般にコンピュータシステムに関する。より詳しくは、サーバ環境内において、カスタマイズ可能なセキュリティおよびロギングモジュールを提供するための方法および装置に関する。
【０００２】
【従来の技術】
インターネットビジネス（ｅ−コマースとも言う）が爆発的な成長を遂げるにつれて、安全なトランザクションを効率的に記録する能力を提供すると共に、インターネット上においてこれら多数のトランザクションを処理する能力を向上させることが、重要な課題となっている。
【０００３】
現在のウェブブラウザは、そのほとんどが、図１に示されるように非常に単純なネットワークへのアプローチを採っている。ウェブブラウザ１００と、ホスト名およびホスト上のドキュメント（ｈｔｔｐリクエストとも呼ばれる）を含んだＵＲＬ（universal resource locator）とが与えられると、ブラウザ１０２はＵＲＬを、指名されたホスト部分１０４とリクエストされたドキュメント１０６とに分割（解析）する。本発明の一実施形態では、リクエストされたドキュメント１０６は、当業者に周知のＨＴＭＬ（Hyper Text Markup Language）文の形を採る。リクエストされたドキュメントがローカルなキャッシュメモリに格納されていない場合は、ブラウザ１０２は、サーバ１０８を含んだ指名ホスト１０４にＴＣＰ（伝送制御プロトコル）接続する。このウェブでは、ウェブサーバは、リクエストされたＨＴＭＬページやファイルを提供するコンピュータプログラム（通常はホストコンピュータ１０４内に存在する）であり、ウェブクライアントは、ユーザに関連したリクエストプログラム（ブラウザ１００等）である。
【０００４】
リクエストされたドキュメント１０６は、ホストコンピュータ１０４に格納されたスタティックウェブページ１１０の形を採る場合がある。しかしながら、リクエストされたドキュメント１０６は、いわゆるダイナミックウェブページ１１２である場合もある。ダイナミックウェブページ１１２は、一般に、例えばサーバ１０８がコモンゲートウェイインターフェース（ＣＧＩ：common gateway interface）アプリケーションによりアクセスする外部データベース１１６等のデータベースに格納されている。
【０００５】
コモンゲートウェイインターフェース（ＣＧＩ）は、ウェブサーバが、ウェブユーザのリクエストをアプリケーションプログラムに引き渡したり、ユーザへ転送するためのデータを受信したりするための標準的なな方法である。ユーザがウェブページをリクエストすると（例えば、強調文字をクリックしたり、またはウェブサイトのアドレスを入力したりすることにより）、サーバ１０８は、リクエストされたページをｈｔｔｐレスポンスの形で返信する。しかしながら、ユーザがウェブページ上で記入したフォームを送信する場合は、アプリケーションプログラムで処理する必要があるのが通常である。ウェブサーバ１０８は一般に、このフォーム情報を、データを処理し、提供された情報に基づいてレスポンスを返信する小アプリケーションプログラムに引き渡す。
【０００６】
あいにくコモンゲートウェイインターフェースは、非効率的でリソース集約的である。例えば、現在のウェブアプリケーションのほとんどが、何らかのデータベースアクセスを必要とする。ＣＧＩアプリケーションを使用するということは、ＣＧＩが走るたびに、新しいデータベース接続が形成されて数秒の時間を要することを意味する。このためＣＧＩは、インターネットを経済的に使用するのに必要とされる多数のトランザクション（「ヒット」と呼ばれ、数千、数十万、ときにはそれ以上の数になる）を処理するのには適さない。ＣＧＩの壁を越える解決策の１つに、サーブレットまたはＪａｖａサーブレット（Ｊａｖａベースのウェブサーバに組み込まれている場合）と呼ばれるものがある。
【０００７】
Ｊａｖａサーブレットは、ウェブブラウザからのリクエスト（すなわちｈｔｔｐリクエスト）に応えてウェブまたはＨＴＴＰサーバ上で実行されるＪａｖａプログラムである。ウェブサーバソフトウェアは、サーブレットを走らせてＨＴＭＬページを生成するために、Ｊａｖａ仮想マシンを使用する。サーブレットは、ＨＴＭＬ入力タグを含んだＨＴＭＬページ（ｈｔｔｐリクエスト）からの入力を取り入れ、処理して、それに応えるＨＴＭＬページ（ｈｔｔｐレスポンス）を結果と共に返す。Ｊａｖａサーブレットは、シングルブラウザ専用であるため、従来のＣＧＩアプリケーションよりも多くのトラフィックを（ｈｔｔｐリクエストおよび関連のｈｔｔｐレスポンスの形で）処理することができる。
【０００８】
こういった利点を有するものの、Ｊａｖａサーブレットは、カスタマイズされたセキュリティおよびロギングプロトコルを提供することができない。現在のところ、セキュリティおよびロギングプロトコルはウェブサーバのみによって提供されており、これは、それをサポートする全てのウェブアプリケーションに対して同じである。この方法では、あるウェブサーバに接続された全てのアプリケーション（またはＨＴＴＰサーバ）が、アプリケーションごとに特有なニーズがあるにも関わらず、そのウェブサーバに与えられたセキュリティおよびロギングプロトコルのみを使用することしかできない。このような非柔軟性は、ｅ−コマースウェブサイトの遂行に実質的なコストの増加をもたらす。これは、ユーザ／開発者が、予想される（望ましい）数のトランザクション（ヒット）を処理することができるうえに特殊なセキュリティおよびロギング要求を満たすような望ましいウェブサーバを探さすか、またはアプリケーションの一部としてセキュリティおよびロギングコードを開発するかしなければならないためである。
【０００９】
【発明が解決しようとする課題】
以上からわかるように、サーブレット環境において、カスタマイズされたセキュリティおよびロギングプロトコルを提供するための、方法および装置が望まれている。
【００１０】
【課題を解決するための手段およびその作用・効果】
本発明の一実施形態では、選択されたセキュリティおよびロギングプロトコルを提供するように構成されたサーブレットエンジンが開示されている。サーブレットエンジンは、セキュリティモジュールと、ロギングモジュールと、サーブレットと、を有したサーブレットコンテナを含む。一実施形態におけるセキュリティモジュールは、認証プロトコル（オーセンティフィケーションプロトコル）および許可プロトコル（オーソライゼイションプロトコル）を含む選択されたセキュリティプロトコルを提供する。認証プロトコルは、サーブレットエンジンにより受信されたリクエストが検証済みの発信源を有することを確認し、許可プロトコルは、検証済みの発信源が適切な許可を有していることを確認する。ロギングモジュールは、検証済みの発信源から発生したのではないか、または、適切な認可を有していない受信リクエストがロギングモジュールによって記録されるように、選択されたロギングプロトコルを提供する。
【００１１】
好ましい一実施形態において、サーブレットは、セキュリティモジュールにより認証および許可されたこれらリクエストを取り扱い、サーブレットによりうまく取り扱われたこれらリクエストを、第１のタイプのフラグでロギングモジュールに通知する。サーブレットはまた、サーブレットによりうまくハンドルされなかったこれらリクエストを、第２のタイプのフラグでロギングモジュールに通知する。
【００１２】
本発明の別の形態においては、プログラマによって選択されたセキュリティおよびロギングプロトコルを利用するサーブレットエンジンに接続されている保護されたリソースにアクセスするための方法が説明されている。一実施形態において、サーブレットエンジン内に含まれるサーブレットで処理されるのは、全てのセキュリティプロトコルをパスしたリクエストのみである。好ましい一実施形態において、セキュリティプロトコルは、プログラマによって定義された認証プロトコルおよび許可プロトコルを含む。この方法では、データベース等の保護されたリソースにアクセスできるのは、適切なセキュリティへの認証を有するリクエスト者のみである。
【００１３】
本発明のさらに別の形態では、保護されたリソースへのアクセスを提供するための装置が開示されている。保護リソースアクセスリクエストの発信源が検証済みかを第１に決定するための認証手段は、保護リソースアクセスリクエストの発信源が適切な保護リソースアクセス許可を有するかを第２に決定するための許可手段に接続されている。許可手段に接続されているリクエスト処理手段は、認証手段および許可手段を共にパスしたリクエストにサービスし、認証手段および許可手段に接続されたロギング手段は、サービスされたトランザクションだけでなく、失敗した認証トランザクションや失敗した許可トランザクションも記録する。
【００１４】
【発明の実施の形態】
以下の説明では、例えばブラウザ／サーバ環境等のウェブサーバ内に、カスタマイズされたセキュリティおよびロギングプロトコルを提供するための構成および方法を説明する。以下では、本発明を先ずマルチスレッドオブジェクト指向のコンピューティングシステムに属するサーバアプリケーションの視点から説明するが、本発明が、ｈｔｔｐリクエストおよびレスポンスを処理することのできる他の任意のシステム内で使用できる点に注意が必要である。
【００１５】
一般に、ウェブサーバに接続されて、ＨＴＴＰページとも呼ばれるブラウザがｈｔｔリクエストを生成すると、プログラマ／開発者によって提供されてウェブサーバに含まれるセキュリティモジュールは、ｈｔｔｐリクエストを提供するブラウザの認証を行う（すなわち、一実施形態ではＩＤを確認する）。認証が成功する、すなわちブラウザの識別が適切に行われると、セキュリティモジュールは、そのブラウザが、リクエストされたデータベースにアクセスするのに適切な許可を有しているかを決定する。ブラウザが適切に識別され且つ適切な許可を有している場合は、関連のサーブレットが呼び出され、必要であればセキュアデータベース等の保護されたリソースにアクセスすることにより、その検証済みのｈｔｔｐリクエストにサービスする。
【００１６】
関連のサーブレットがｈｔｔｐリクエストを処理すると、関連のロギングモジュールがｈｔｔｐリクエストの処理状態を記録する。ある実施形態では、エラーフラグと関連していない（すなわち処理が「成功した」）ｈｔｔｐリクエストのみが、成功したものとして記録される。別の実施形態では、失敗した許可および／または認証も全て同様に、ロギングモジュールにより記録される。この方法では、ハッキングを試みる者や、さもなくばセキュアデータベースまたはウェブサーバに割り込もうとする者を追跡したり、周知のＩＤや追跡技術を使用して犯罪者を識別したりすることができる。
【００１７】
一実施形態において、いわゆるセッション中における許可は、あらかじめセキュリティモジュールから提供されたクッキー（ブラウザ内に存在する）に部分的にもとづくものである。当業者には明らかなように、セッションとは、同一ユーザ（すなわち同一ブラウザ）からの一連のリクエストに関する状態を一定期間に渡って維持するために、サーブレットが使用するメカニズムである。クッキーとは、ユーザに関連付けられた少量の状態情報をクライアントに保持させるために、サーブレットが使用するメカニズムである。サーブレットは、クッキー内の情報を、ユーザがサイトに入る際に（例えば低セキュリティユーザのサインオンとして）使用するか、ユーザがサイトをナビゲートする際に（例えばユーザプレファレンスの保管場所として）使用するか、またはその両方の際に使用することができる。
【００１８】
ほとんどのウェブサーバは、図２に示されるようにネットワークへの非常に単純なアプローチを採っている。ブラウザ２００（クライアントアプリケーションまたはクライアントプログラムとも呼ばれる）は、ローカルコンピュータ２０２上に存在するプログラムであり、指名されたホストコンピュータ２０４と、このホストコンピュータ２０４に接続され外部データベース２０６に格納されているのが一般的なドキュメントと、を含むｈｔｔｐリクエストと呼ばれるものを生成するプログラムである。ホストコンピュータ２０４は、ローカルエリアネットワーク（ＬＡＮ）もしくは広域データ通信ネットワーク（ＷＡＮ）等のネットワーク内コンピュータの集まりに接続されているのが一般的であり、または、コンピュータのインターネットネットワークの一部となっているのがさらに一般的である。上述した実施形態では、ホストコンピュータ２０４はウェブサーバアプリケーションプログラム（サーバ）２０８を含む。
【００１９】
上述した実施形態において、サーバ２０８は、ロギングモジュール２１４に接続されたセキュリティモジュール２１２を含むサーブレットコンテナ２１０を含み、ロギングモジュール２１４はサーブレット２１６に接続される。ある実装例では、サーブレットコンテナ２１０はサーブレットエンジンとも呼ばれ、サーバ２０８とサーブレット２１６との間のインターフェースを提供する。セキュリティモジュール２１２がアクティブになる（すなわち開発者／プログラマセキュリティプロトコルを提供する）と、サーブレット２１６は、セキュリティモジュール２１２によって認証および許可されたｈｔｔｐリクエストのみをサービスする（すなわち、処理する）。セキュリティモジュール２１２がアクティブでない場合、または、あるセキュリティプロトコルがサーバプログラマによって必要ないと決定された場合は、本発明の一実装例では、ウェブサーバ２０４によってすでに提供されているセキュリティプロトコルがデフォルトモードで使用される。
【００２０】
ｈｔｔｐリクエストが認証または許可に失敗した場合は、ロギングモジュール２１４にエラーフラグが供給される。このようなエラーフラグは、認証が失敗したことを示すいわゆる「４０１」エラーコード等のエラーコードを含むことができる。別の故障モードでは、あるオブジェクトが見つからなかったことを示す「４０４」エラーコードが生成される。本発明の利点の１つは、サーブレットエンジン開発者／プログラマに、ロギングモジュール２１４が記録するエラーコードの種類と数の両方をカスタマイズする能力が提供されることである。この方法により、サーブレットプログラマ／開発者は、例えば、一定期間内に多数回アクセスに失敗したブラウザを記録してハッカを追跡したり、あるブラウザのユーザによって公表された種々のセキュリティ故障の頻度および種類を決定したりする能力を、提供することができる。
【００２１】
これに対して、ｈｔｔｐリクエストがセキュリティモジュール２１２により有効とされた場合は、その有効とされたｈｔｔｐリクエストがサーブレット２１６に転送される。上述した実施形態において、サーブレット２１６は、例えば、有効なｈｔｔｐリクエストに関連付けられたデータベース２０６に格納されているリクエストされたドキュメントに対応するドキュメントオブジェクトモジュール（ＤＯＭ）を生成することにより、ｈｔｔｐリクエストを処理する。リクエストされたドキュメントは、データベース２０６から引き出されてサーブレット２１６に転送される。するとサーブレット２１６は、引き出されたドキュメントをｈｔｔｐレスポンスの形でブラウザ２００に引き渡すとほぼ同時にロギングモジュール２１４への通知を行う。
【００２２】
一実施形態において、ロギングモジュールは一般に、成功したヒット数対セキュリティモジュール２１２によって報告された許可および／または認証されなかったリクエスト数に関連した情報のみでなく、ブラウザ２００の仮想場所を示すＩＰ（インターネットプロトコル）アドレス情報に関連した情報の追跡も行う。この情報によって開発者は、サーブレットが処理するｈｔｔｐリクエストの数および種類を追跡することができる。この方法では、ウェブサイトの所有者が、あるサイトに入ろうと試みたユーザ数、ならびに問題のサイトに入るのに失敗および／または成功したユーザ数を決定できるだけでなく、ウェブサイトの利用状況をより正確に追跡することもできる。
【００２３】
一実施形態において、ユーザがセッションの開始を決定した場合は、そのセッションの開始時に、セキュリティモジュール２１２がセッション期間中アクティブであるブラウザ２００にクッキー２１８を提供する。このようなセッションの一例として、セキュアウェブサイトまたはデータベース２０６にアクセスするために、ユーザが例えばブラウザ２００内でアプレット２２０をインスタンス化する場合が挙げられる。ユーザは、データバンク２０６内に格納された機密情報にアクセスすることにより、例えば、銀行のオンラインバンキングウェブサイトを使用したり最新の紳士服をオーダーしたりするために、安全なビジネスの実行を希望することができる。クッキー２１８は、セッション用に定義された期間中に必要とされる許可および認証を、ブラウザ２００に提供する。この期間中は、クッキー２１８が有効である限り、そのセキュアウェブサイトのためにアプレット２２０により生成された全てのｈｔｔｐリクエストが、セキュリティモジュール２１２を効率的に迂回して、サーブレット２１６により処理される。しかしながら、クッキー２１８が例えば期限切れまたは特定セッションの終了により無効になった場合は、セキュリティモジュール２１２はどんな時であれ、適切なセキュリティプロトコルに基づき新しいクッキーを再送出しなくてはならない。
【００２４】
図３は、本発明の一実施形態に従ってサーブレットのライフサイクル３００を詳述したフローチャートである。ここで、サーブレットのライフサイクル３００が、オブジェクト指向コンピューティングシステムのＪａｖａ仮想マシン内で実行されるように設計された、Ｊａｖａサーブレットの視点から説明されている点に注意が必要である。本発明の一実施形態において、サーブレットのライフサイクル３００は、ステップ３０２においてサーブレットをインスタンス化することにより開始し、続くステップ３０４ではサーバによってサーブレットが初期化される。サーバは、サーブレットを初期化するために、サーブレットをロードしてその「init method」を走らせる。ここで、サーブレットの初期化が、クライアントのリクエストが処理される前であって、かつ、サーブレットが破壊される前に完了する点に注意が必要である。ほとんどのサーブレットはマルチスレッド化されたサーバ内で走るが、サーブレットの初期化中に同時発生の問題が生じることはない。サーバは、サーブレットをロードする時にinit methodを一回呼び出すが、サーブレットを再ロードしない限りは再び呼び出すことはない。サーバは、破壊メソッドを呼び出してサーブレットを破壊するまでサーブレットを再ロードすることはできない。サーブレットは、サーバによって初期化された後、ステップ３０６においてｈｔｔｐリクエストを待つ。ｈｔｔｐリクエストが受信され、その一部がクライアントセッションである場合は、ステップ３０８において、クライアントセッションが認証されたか否かを決定する。この認証は、一般に、セッションに対応するクッキーが期限切れでないか、および／または、適切なサインオンを有しているかを決定することにより実施される。セッションを認証しないと決定した場合は、セキュリティモジュールはステップ３１０において、例えばクッキーを検査してセッションを認証することによりセキュリティを処理する。受信されたｈｔｔｐリクエストがあるセッションの初期のｈｔｔｐリクエストであった場合は、セキュリティモジュールによりそのｈｔｔｐリクエストの有効性を検査した（すなわち認証および許可の両方を行った）後、クライアントブラウザに新しいクッキーが送出される。
【００２５】
これに対して、ステップ３０８においてセッションが認証された場合は、ステップ３１２においてｈｔｔｐリクエストがサーブレットによりサービスされた後、ステップ３１４においてｈｔｔｐレスポンスがロギングモジュールにより記録される。ここで、ｈｔｔｐリクエストが何らかの理由で失敗したことをセキュリティモジュールが決定した場合は、いつ何時であろうと、適切なエラーフラグがロギングモジュールに供給される点に注意が必要である。
【００２６】
再びステップ３０６に戻って、受信されたｈｔｔｐリクエストがセッションの一部ではない場合は、ステップ３１０においてセキュリティモジュールがセキュリティを処理するとともに、ステップ３１４における記録に備えて故障であることがロギングモジュールに報告され、ステップ３１２において、有効とされたｈｔｔｐリクエストがサーブレットによりサービスされる。
【００２７】
ここで、ステップ３０６において、事前選択された期間中に追加のｈｔｔｐリクエストが来なかった場合は、ステップ３１６において、サーブレットを破壊するか否かに関する決定がなされる。サーブレットを破壊しないと決定された場合は、ｈｔｔｐリクエストが受信される時までステップ３０６に制御が戻る。これに対して、サーブレットを破壊すると決定された場合は、サーバはステップ３１８において、サーブレットの破壊メソッドを走らせることによりサーブレットを破壊する。上述した実施形態において、破壊メソッドが走るのは一度のみであり、そのサーブレットは、サーバにより再ロード・再初期化されるまで再び走ることはない。破壊メソッドが一度走った後は、破壊されたサーブレットがステップ３２０においてガーベッジコレクションされる。ここで、マルチスレッド化されたシステムの場合は、サービスリクエストをまだ走らせている長期継続のスレッドが存在する可能性があるため、クリーンなシャットダウンを提供しなくてはならない点に注意が必要である。
【００２８】
図４は、図３のセキュリティ処理操作３１０を実現するプロセス４００を詳述したフローチャートである。ここで、プロセス４００が本発明に従ってセキュリティを処理する方法の１つに過ぎず、本発明の範囲を限定するものとは解釈されない点に注意が必要である。プロセス４００は、ステップ４０２において、セキュリティモジュールがアクティブに設定されているかを決定することにより開始する。セキュリティモジュールがアクティブに設定されていないと決定された場合は、ステップ４０４において、サーブレットがサーバのデフォルトセキュリティモードを利用する。これに対して、セキュリティモジュールがアクティブに設定されている場合には、受信されたｈｔｔｐリクエストを認証するために、ステップ４０６において、関連するセキュリティモジュールにより認証リクエストとしての認証メソッドが呼び出される。そしてステップ４０８において、認証が成功したか否かに関する決定がなされる。認証が成功しなかった場合は、ステップ３１４（ロギング）に制御が引き渡され、それ以外の場合は、ステップ４１０においてセキュリティモジュールがｈｔｔｐリクエスト上に許可メソッドを呼び出す。許可が成功しなかった場合は、ステップ３１４（ロギング）に制御が引き渡され、それ以外の場合は、ステップ３１２においてｈｔｔｐリクエストがサーブレットによりサービスされる。
【００２９】
図５は、図３のロギング処理操作３１４を実現するプロセス５００を詳述したフローチャートである。ここで、プロセス５００が本発明に従ってロギングを処理する方法の１つに過ぎず、本発明の範囲を限定するものとは解釈されない点に注意が必要である。プロセス５００は、ステップ５０２において、ｈｔｔｐレスポンスオブジェクトに故障コードが設定されているかを決定することにより開始する。故障コードが設定されていないと決定された場合は、ｈｔｔｐリクエストは、ロギングモジュール上にログメソッドを呼び出すことにより記録される。これに対して、故障コードが設定されている場合は、ｈｔｔｐリクエストは、ステップ５０４においてロギングモジュール上にログエラーメソッドを呼び出すことにより記録される。いずれの場合も、ロギングメソッドが完了してからステップ３０６において次のｈｔｔｐリクエストが受信されるまでの間、サーブレットは待ち状態に置かれる。
【００３０】
図６は、本発明を実現するのに利用することができるコンピュータシステム６００を描いた図である。コンピュータシステム６００は、より厳密に言えば複数のＣＰＵ６０２は、当業者には明らかなように、仮想マシンをサポートするように構成することができる。当業者に周知のように、ＲＯＭが、データおよび命令をＣＰＵ６０２に一方向的に伝送するよう作動する一方で、ＲＡＭは、データおよび命令を双方向的に伝送するように使用されるのが典型的である。ＣＰＵ６０２は、一般に任意数のプロセッサを含んで良い。主記憶装置６０４，６０６は、ともに任意の適切なコンピュータ読み取り可能媒体を含んで良い。二次記憶媒体６０８は、大容量のメモリデバイスであるのが典型的であり、ＣＰＵ６０２に双方向的に接続されて追加のデータ格納容量を提供する。大容量メモリデバイス６０８は、コンピュータコードやデータ等を含むプログラムを格納するのに使用され得るコンピュータ読み取り可能媒体である。典型的な大容量メモリデバイス６０８は、一般の主記憶装置６０４，６０６よりも低速な、ハードディスクやテープ等の記憶媒体である。大容量メモリデバイス６０８は、磁気もしくは紙テープ読取り装置、またはその他の周知な装置の形を採っても良い。大容量メモリデバイス６０８内に保持される情報は、適切な場合には、ＲＡＭ６０６内に、その一部を占める仮想メモリとしてスタンダードな方式で組み込まれていても良い。ＣＤ−ＲＯＭ等の特定の主記憶装置６０４は、ＣＰＵ６０２に一方向的にデータを引き渡しても良い。
【００３１】
また、ＣＰＵ６０２は１つまたはそれ以上の入出力デバイス６１０に接続されていて良い。入出力デバイスは、ビデオモニタ、トラックボール、マウス、キーボード、マイクロフォン、タッチディスプレイ、トランスデューサカードリーダ、磁気もしくは紙テープリーダ、タブレット、スタイラス、音声もしくは筆跡認識装置、または他のコンピュータ等のその他の周知な入力デバイスを含み、これらの限定されない。ＣＰＵ６０２は、最終的にコンピュータに接続されるか、または、例えばインターネットやイントラネット等の通信網に、６１２として一般に示されるようなネットワーク接続を使用して選択的に接続されても良い。このようなネットワーク接続により、ＣＰＵ６０２は、上述した方法の工程の最中に、ネットワークから情報を受信したりネットワークに情報を出力したりできると考えられる。これらの情報は、ＣＰＵ６０２で実行される命令のシーケンスとして表現されることが多く、例えば搬送波に組み込まれたコンピュータデータ信号の形で、ネットワークから受信されたりネットワークに出力されても良い。上述した装置および材料は、コンピュータのハードウェアおよびソフトウェア技術の当業者にとって周知のものである。
【００３２】
以上では、本発明の実施形態を数種のみ取り上げたが、本発明が、本発明の精神または範囲を逸脱することなく他の多くの特殊な形で実施できる点に注意が必要である。
【００３３】
本発明にもとづいた、カスタムセキュリティおよびロギングプロトコルをサーブレットエンジンに提供するための方法は、Ｊａｖａ（商標）ベースの環境で実現するのに特に適しているが、この方法は、一般に、任意の適切なオブジェクトベースの環境に適用することが可能である。この方法は特に、プラットフォーム独立のオブジェクトベース環境で使用するのに適している。ここで、この方法を、分散オブジェクト指向システムで実現することも可能である点に注意が必要である。
【００３４】
以上では、本発明を、関連のウェブブラウザおよびウェブサーバを有するコンピュータシステムに使用した場合を説明したが、本発明が一般に、任意の適切なオブジェクト指向コンピュータシステム上で実現できる点に注意が必要である。
したがって、本発明は例示的なものであり限定的ではないと考えられ、ここで示した詳細に限定されることはない。よって本発明は、最大限の範囲で同等物が可能であるのに加え、添付した特許請求の範囲の範囲内で各種の変更を加えることが可能である。
【図面の簡単な説明】
【図１】従来のブラウザ／サーバ構成を示した図である。
【図２】Ｊａｖａベースのサーバと、それに関連し、ユーザによる設定が可能なセキュリティおよびロギングプロトコルを提供するサーブレットコンテナとを本発明の一実施形態に従って示した図である。
【図３】本発明の一実施形態に従って、サーブレットのライフサイクルを詳細に示したフローチャートである。
【図４】図３のセキュリティ処理操作を実現するプロセスを詳細に示したフローチャートである。
【図５】図３のロギング処理操作を実現するプロセスを詳細に示したフローチャートである。
【図６】本発明を実現するのに利用することができるコンピュータシステムを描いた図である。
【符号の説明】
１００…ウェブブラウザ
１０２…ブラウザ
１０４…指名されたホスト
１０６…リクエストされたドキュメント
１０８…サーバ
１１０…スタティックウェブページ
１１２…ダイナミックウェブページ
１１４…外部データベース
２００…ブラウザ
２０２…ローカルコンピュータ
２０４…ホストコンピュータ
２０６…外部データベース
２０８…ウェブサーバアプリケーションプログラム
２１０…サーブレットコンテナ
２１２…セキュリティモジュール
２１４…ロギングモジュール
２１６…サーブレット
６００…コンピュータシステム
６０２…ＣＰＵｓ
６０４，６０６…主記憶装置
６０８…二次記憶媒体
６１０…入出力デバイス
６１２…ネットワーク接続
【図１】
0004615096.tif 000002
【図２】
0004615096.tif 000003
【図３】
0004615096.tif 000004
【図４】
0004615096.tif 000005
【図５】
0004615096.tif 000006
【図６】
0004615096.tif 000007