JP4305146B2

JP4305146B2 - 通信制御装置、アプリケーションサーバ、およびプログラム

Info

Publication number: JP4305146B2
Application number: JP2003396541A
Authority: JP
Inventors: 陽一廣瀬
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2003-11-27
Filing date: 2003-11-27
Publication date: 2009-07-29
Anticipated expiration: 2023-11-27
Also published as: JP2005157822A

Description

本発明は、通信制御装置、特に、認証を受けたクライアント端末に対して、所定のサービスを提供するために、クライアント端末からのアクセスを制御する通信制御装置に関する。

従来、認証サーバのユーザ認証を受けたクライアント端末に対してのみ、ＨＴＴＰ通信により、各種サービスを提供するＷｅｂサーバが知られている。このようなＷｅｂサーバを含むネットワークシステムでは、クライアント端末からＷｅｂサーバに対してアクセスがあった場合、Ｗｅｂサーバは、まず、そのクライアント端末を操作するユーザがすでに認証サーバの認証を受けているか否かを判定する。判定の結果、未認証ユーザの場合は、クライアント端末に対して、認証サーバの認証を受けるように指示を出す。そして、クライアント端末から、認証サーバによるユーザ認証を受けた旨の通知を受けるのを待って、Ｗｅｂサーバは、そのクライアント端末との間にセッションを確立させ、そのクライアント端末に対して、各種サービスを提供する。

このようなＨＴＴＰ通信を利用して、Ｗｅｂサーバが、ユーザ認証を行ったクライアント端末に対して、各種サービスを提供するシステムとして、例えば、特開２００３−２９６２７７号公報（以下、特許文献１）に開示された技術がある。

この特許文献１では、ＨＴＴＰ通信として、ＨＴＴＰのＧＥＴメソッドやＰＯＳＴメソッドを利用して通信を行い、ＨＴＴＰの機能の一つであるリダイレクトを使用して、ユーザ認証を行っている。

ここで、ＧＥＴメソッドとは、サーバ等へアクセスする場合に使用するメソッドであり、ＨＴＴＰメッセージ形式の一つである。具体的には、ＧＥＴメソッドを構成するヘッダ領域に記述されるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｅｒ）に直接送信先へ送りたいデータを記述する形式のことをいう。例えば、ヘッダ領域に記述されるＵＲＬが、「http://test.fujixerox.co.jp/login?user=fuji&passwd=xerox」という記述の場合、「？」より前の記述が、データ送信先となるサーバ等のアクセス先（アドレス）を示し、「？」より後の記述が、送信先のサーバ等へ送信すべきデータを示す。つまり、ＧＥＴメソッドを使用する場合、ヘッダ領域に記述されたデータのみ送信すれば、所望のデータを送信先のサーバ等へ送信することができる。しかし、ＧＥＴメソッドのＵＲＬに書き込むことが可能なデータ量には、制限があり、大量のデータを送信する場合などには適さない。一方、ＰＯＳＴメソッドも、サーバ等へアクセスする場合に使用するメソッドの一つであり、ＨＴＴＰメッセージ形式の一つである。しかし、ヘッダ領域とは別に定義されたボディ領域に、送信先のサーバ等へ送信すべきデータを記述する点で、ＧＥＴメソッドとは異なる。ＰＯＳＴメソッドを利用する場合、ヘッダ領域のデータのほかに、ＨＴＴＰ通信において、ボディ領域のデータも送信先のサーバ等に送信する必要がある。ＰＯＳＴメソッドは、送信するデータ量が多かったり、メッセージにファイルを添付して送信する場合や、直接ＵＲＬに書き込んで送信することで、サーバ上にデータをログとして残したくない場合などに使用されることが多い。また、リダイレクトとは、アクセスしてきた端末等に対して、別の接続先へアクセスするように指示を出すことをいう。

このようなＧＥＴメソッド等を利用して、特許文献１では、次のように、ユーザ認証を行っている。

まず、ＷＷＷブラウザは、ＧＥＴメソッドを用いて、例えば、「ＧＥＴｕｒｌ１ＨＴＴＰ／１．Ｘ」といった要求メッセージを、ＷＷＷアプリケーションに送信する。ここで、「ｕｒｌ１」は、ＷＷＷアプリケーションのＵＲＬを示す。ＷＷＷアプリケーションは、ＷＷＷブラウザからのアクセスを受けると、ＳＳＯサーバ（認証サーバ）の認証を受けたユーザからのアクセスか否かを判断する。そして、まだ認証が済んでいないユーザからのアクセスであった場合、ＷＷＷアプリケーションは、ＳＳＯサーバによるユーザ認証を受けるように、ＳＳＯサーバへのリダイレクトをＷＷＷブラウザに対して指示する。

そして、ＷＷＷアプリケーションからのリダイレクトを受信したＷＷＷブラウザは、その要求に従い、指定されたＵＲＬを有するＳＳＯサーバに対して、アクセスし、ユーザ認証要求を行う。ＳＳＯサーバは、ユーザ認証が成功すると、ＷＷＷアプリケーションにアクセスするように、ＷＷＷアプリケーションへのリダイレクトをＷＷＷブラウザに対して指示する。リダイレクト指示を受けたＷＷＷブラウザは、再度ＷＷＷアプリケーションにアクセスすることで、セッションが保持され、所望のサービスの提供を受ける。

このように、ＨＴＴＰのリダイレクトを利用して、ユーザ認証を行う場合、クライアント端末（ＷＷＷブラウザ）は、ＷＷＷアプリケーションに直接アクセスすれば、その後、リダイレクトの機能により、自動的に認証サーバにアクセスし、認証成功後は、さらにリダイレクトすることで、クライアント端末は、ＷＷＷアプリケーションとの間にセッションを確立できるため、クライアント端末は、認証サーバのＵＲＬを直接知らなくても、サービスの提供を受けることができる。

特開２００３−２９６２７７号公報

上述したような認証サーバの認証成功により保持された、クライアント端末とＷＷＷアプリケーションとのセッションは、永続的に確立しておくと、ＷＷＷアプリケーションの処理を行うサーバのメモリ空間を圧迫したり、セキュリティ上の問題があるため、クライアント端末からのレスポンスが一定の期間なかった場合、強制的にセッションを切断するようにシステムも構成するのが一般的である。しかしながら、このように構成されたシステムにおいて、リダイレクトの機能を利用すると、リダイレクトのＲＦＣの規定上、次のような課題が生じる。

すなわち、リダイレクトは、ＲＦＣ２６１６の規定されているとおり、ＧＥＴメソッドのみ使用可能であり、リダイレクトを受け取った受信側は、リダイレクトに示されたＵＲＬに対して、ＧＥＴメソッドを用いてアクセスを行う。ＰＯＳＴメソッドを使用して、アクセスした場合でも、ＲＦＣの規定上、リダイレクトは、ＧＥＴメソッドによりアクセスが行われる。すると、ＧＥＴメソッドには、上述のようにボディ領域について定義されていないため、ＰＯＳＴメソッドに対してリダイレクトが行われた場合、ＰＯＳＴメソッドのボディ領域に含まれるデータは、リダイレクトによって、失われてしまうこととなる。

したがって、従来において、クライアント端末とＷＷＷアプリケーションとの間にセッションが確立されてから一定期間経過後に、クライアント端末が、ＷＷＷアプリケーションに処理させたデータを作成して、ＰＯＳＴメソッドを用いて、そのデータをボディ領域に書き込み、ＷＷＷアプリケーションにアクセスしたとしても、すでにセッションが切断され、上述したような認証に伴うリダイレクトが行われると、クライアント端末から送信されたＰＯＳＴメソッドのボディ領域に書き込まれたデータは失われてしまう。よって、クライアント端末は、先ほど作成したデータを、ＷＷＷアプリケーションに提供し処理してもらうためには、ユーザ認証が行われ、セッションが再確立された後に、同じデータを再度作成し、ＰＯＳＴメソッドにて再送する必要がある。

上記では、ＨＴＴＰ通信において、リダイレクトを用いた認証を行った後にアプリケーションを提供するシステムにおいて、タイムアウト等が原因で、一度確立されたセッションが切断してしまい、再認証が行われたことにより、ＰＯＳＴメソッドのボディ領域に書き込まれたデータが失われてしまうことを例として挙げた。しかし、このようなデータの喪失は、認証後に、タイムアウト等が原因で、一度確立されたセッションが切断してしまい、再度認証が行われるシステムでは、同様に起こる可能性がある。

本発明は、上記課題を鑑みてなされたものであり、認証を伴うアプリケーションを利用するシステムにおいて、アプリケーションの利便性の向上を図ることを目的とする。

本発明に係る通信制御装置は、利用者によりクライアント端末から送信された、指定したサービス処理装置が処理する処理対象データと、指定したサービス処理装置を特定するサービス識別子とを含む情報データを受信する受信手段と、前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証装置の認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持する保持手段と、前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該クライアント端末に対して、前記認証装置への認証要求を指示する認証要求指示手段と、クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたサービス識別子に基づき特定したサービス処理装置に提供する提供手段と、を備える。

本発明によれば、未認証のクライアント端末が送信した情報データであった場合でも、その情報データに含まれる処理対象データを、保持手段に保持しておき、そのクライアント端末からの認証済み報告通知を受けるのを待って、提供手段が、保持手段に保持した処理対象データを、そのサービス対象データに関連づけられたクライアント端末から送信されたデータとして、そのサービス対象データに関連づけられたサービス識別子に基づき特定したサービス処理装置に提供することができる。これにより、例えば、クライアント端末は、情報データを送信した際に、未認証であった場合でも、認証を受けた後、改めて同一の情報データを送信する手間が省け、利便性の向上を図ることができる。

本発明に係る通信制御装置は、利用者によりクライアント端末から送信された、指定したアプリケーション処理装置が処理する処理対象データがボディ領域に書き込まれ、かつ指定したアプリケーション処理装置のアドレスがヘッダ領域に書き込まれたＰＯＳＴメソッドを受信する受信手段と、前記受信手段により受信されたＰＯＳＴメソッドを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末と当該ＰＯＳＴメソッドのヘッダ領域に書き込まれたアプリケーション処理装置のアドレスとに関連づけて、当該ＰＯＳＴメソッドのボディ領域に書き込まれた処理対象データを保持する保持手段と、前記受信手段により受信されたＰＯＳＴメソッドを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末に対して、前記認証サーバへの認証要求を指示するリダイレクトを行うリダイレクト手段と、クライアント端末から前記リダイレクト手段が行ったリダイレクトに対する認証が済んだことを示すＧＥＴメソッドによる通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたアドレスに基づき特定したアプリケーション処理装置に提供する提供手段と、を備える。

本発明によれば、アプリケーション処理装置が処理する処理対象データがボディ領域に書き込まれたＰＯＳＴメソッドを送信したクライアント端末が、所定の認証サーバの認証を受けていなかった場合に、認証要求のためのリダイレクトがなされたとしても、保持手段が、ＰＯＳＴメソッドのボディ領域に書き込まれた処理対象データを一時保持し、提供手段が、クライアント端末からＧＥＴメソッドによる認証済み報告通知を受けるのを待って、その処理対象データをアプリケーション処理装置に提供する。よって、例えば、処理対象データがボディ領域に書き込まれたＰＯＳＴメソッドを送信したクライアント端末が、所定の認証サーバの認証を受けていなかった場合に、認証要求のためのリダイレクトがなされたとしても、その処理対象データは、破棄されることなく、アプリケーション処理装置に提供されるため、クライアント端末は、同じ処理対象データがボディ領域に書き込まれたＰＯＳＴメソッドを再度送信する手間が省け、利便性の向上につながる。
本発明に係るアプリケーションサーバは、クライアント端末からのアクセスを制御する通信制御手段と、アクセスしてきたクライアント端末によって指定されたアプリケーションサービスのサービス処理を実行するサービス処理手段と、を備えるアプリケーションサーバにおいて、前記通信制御手段は、利用者によりクライアント端末から送信された、前記サービス処理手段がサービス処理を実行する処理対象データと、指定されたアプリケーションサービスを特定するサービス識別子とを含む情報データを受信する受信手段と、前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持する保持手段と、前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該情報データを送信したクライアント端末に対して、前記認証サーバへの認証要求を指示する認証要求指示手段と、クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該処理対象データに関連づけられたサービス識別子に基づき特定したアプリケーションサービスのサービス処理を実行させるために、当該処理対象データに関連づけられたクライアント端末から送信されたデータとして、前記サービス処理手段に提供する提供手段と、を備える。
本発明に係るプログラムは、利用者によりクライアント端末から送信された、指定したサービス処理装置が処理する処理対象データと、指定したサービス処理装置を特定するサービス識別子とを含む情報データを受信する受信手段、前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証装置の認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持部に保持させる保持手段、前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該情報データを送信したクライアント端末に対して、前記認証装置への認証要求を指示する認証要求指示手段、クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持部が保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたサービス識別子に基づき特定したサービス処理装置に提供する提供手段、としてコンピュータを機能させる。

本発明の実施の形態（以下、実施形態とする）について、以下、図面を用いて説明する。図１は、本実施形態におけるシステム構成を示す図である。図１において、ＷＷＷブラウザ１０、ＷＷＷアプリケーション２０、認証サーバ３０は、ネットワーク４０を介して相互にＨＴＴＰなどのプロトコルを使用して通信を行う。本実施形態では、ＷＷＷブラウザ、ＷＷＷアプリケーション、認証サーバは、それぞれ１つのみシステム上に存在するが、もちろん、多くのＷＷＷブラウザ、ＷＷＷアプリケーション、認証サーバを含むシステムでもよい。

ＷＷＷブラウザ１０は、クライアント端末（図示せず）上で動作するソフトウェアであり、ネットワーク４０を介して、ＨＴＴＰ通信により様々なサービスや情報の提供を受ける。クライアント端末は、例えば、デスクトップコンピュータ、ラップトップコンピュータ、ＰＤＡ、携帯電話など、ネットワークに接続可能な端末であって、ＷＷＷブラウザが動作する環境を提供可能な端末であれば何でもよい。

ＷＷＷアプリケーション２０は、ＷＷＷブラウザ１０に対して各種のサービスを提供する。また、ＷＷＷアプリケーション２０は、コンピュータなどのネットワーク装置（サーバ）上でＷＷＷブラウザ１０にサービスを提供するソフトウェアである。また、ＷＷＷアプリケーション２０は、ユーザ認証が行われたユーザにのみサービスを提供する。

認証サーバ３０は、ＷＷＷブラウザ１０からのアクセスに対して、ユーザ認証を行うとともに、ＷＷＷアプリケーション２０からの要求に応じてユーザ認証結果を返す。

ここで、さらに、ＷＷＷアプリケーション２０と認証サーバ３０について説明する。

ＷＷＷアプリケーション２０は、通信制御部２１と処理部２２とを含み構成されている。通信制御部２１は、ネットワーク４０を介して、ＷＷＷブラウザ１０からのアクセスを受け付けて、対応する処理を行う。例えば、未認証のＷＷＷブラウザ１０からのアクセスを受け付けた際には、ＷＷＷブラウザ１０を利用しているユーザが認証済みであるか否かを判断する。そして、判断の結果、未認証であれば、認証の判断等に使用するリクエストＩＤを発行するとともに、ＷＷＷブラウザ１０に対して、認証サーバ３０へのリダイレクトを行う。これにより、ＷＷＷブラウザ１０に対して、認証サーバ３０による認証を受けさせる。また、認証済みのＷＷＷブラウザ１０からのアクセスであった場合には、先に発行したリクエストＩＤを受け取って、処理部２２にサービスを行わせる。また、通信制御部２１は、リダイレクトによりＷＷＷブラウザ１０から、認証済み報告通知を受けると、ＷＷＷブラウザ１０との間のセッションを一定期間保持する。ただし、そのセッションは、一定期間経過後は、切断し、その後再度そのユーザからアクセスがあった場合は、再度ＷＷＷブラウザ１０に対して、認証サーバ３０へのリダイレクトを行う。

さらに、本実施形態における通信制御部２１は、アクセスしてきたＷＷＷブラウザ１０が未認証であって、それがＰＯＳＴメソッドを用いたアクセスであった場合、リダイレクトに伴うＧＥＴメソッドを用いた認証済み報告の通知を受けるまでの間、そのＰＯＳＴメソッドのボディ領域に書き込まれたデータを一時保持することを特徴としている。そして、通信制御部２１は、ＷＷＷブラウザ１０からのＧＥＴメソッドを用いた認証済み報告を受けた後に、そのＧＥＴメソッドを、先ほど一時保持したデータがボディ領域に書き込まれたＰＯＳＴメソッドとなるようにエミュレートして、処理部２２へ渡す。これにより、ＰＯＳＴメソッドを用いてアクセスしてきたＷＷＷブラウザ１０が、未認証ユーザからのアクセスであった場合にも、ＰＯＳＴメソッドのボディ領域に書き込まれたデータは破棄されることなく、処理部２２に提供される。

これにより、例えば、ＷＷＷブラウザ上に表示された各入力フォームに、ユーザが必要に応じて、データを入力して、ＷＷＷアプリケーションの管理するデータベースに登録するようなシステムでは、次のような効果がある。すなわち、ＷＷＷブラウザ１０が、ユーザ認証を受けた後に、ＷＷＷアプリケーション２０から、図２に示すようなブラウザ表示画面を受け取り、ユーザが、クライアント端末に備えられたキーボードなどを使用して、各入力フォームに必要事項を入力する。ここで、入力フォームに入力されるデータとしては、テキストデータであったり、文書作成ツールなどの他のソフトウェアで作成した文書データや画像データ等の添付ファイルデータなどである。そして、データを入力した後、ＷＷＷブラウザ１０が、その入力データのデータ形式変換を行い、その入力内容をボディ領域に書き込んでＰＯＳＴメソッドにより、ＷＷＷアプリケーション２０へアクセスを試みる。その際に、例えば、ユーザが入力フォームに内容を入力する時間が多くかかったことなどが原因で、入力途中に、ユーザ認証によって確立されたＷＷＷブラウザ１０とＷＷＷアプリケーション２０との間のセッションがタイムアウトして、切断されてしまうことがある。その場合、ＷＷＷアプリケーション２０は、リダイレクトにより、改めてＷＷＷブラウザ１０に対して認証を受けさせる。しかし、上述したように、リダイレクトは、ＲＦＣの規定上、ＧＥＴメソッドを用いて行われるため、従来のＷＷＷアプリケーションでは、先ほど、ＷＷＷブラウザ１０より受け取ったＰＯＳＴメソッドのボディ領域に書き込まれたデータを破棄せざるを得なかった。一方、本実施形態におけるＷＷＷアプリケーション２０は、通信制御部２１において、ＰＯＳＴメソッドのボディ領域に書き込まれたデータを一時保持しておき、認証の確認を行ったのちに、そのデータを処理部２２に提供することができるため、認証が終了したのち、ユーザは改めて、各入力フォームに同じ内容を入力する必要がなく、ＷＷＷアプリケーションの利便性の向上を果たすことができる。

認証サーバ３０は、認証部３１と、個人情報管理データベース３２とを含み構成されている。認証部３１は、ＷＷＷブラウザ１０からのアクセスに応じて認証処理を行うと伴に、ＷＷＷアプリケーション２０からの問い合わせに応じて認証結果の返送などを行う。また、ＷＷＷブラウザ１０からのアクセスを受けたとき、ＷＷＷブラウザ１０のユーザが未認証である場合には、ＷＷＷブラウザ１０に対して、図３に示すような認証フォームを送信してユーザによるユーザＩＤやパスワードなどの入力情報を受け取る。そして、その入力情報に基づいて、個人情報管理データベース３２への問い合わせを行って、ユーザの認証を行う。認証済のユーザによるＷＷＷブラウザ１０からのアクセスに対しては、ＷＷＷブラウザに対して認証フォームを送信することはせずに、認証処理は行わない。

なお、この例では個人情報管理データベース３２を認証サーバ３０内に設けられるように図示しているが、これに限らず、認証サーバ３０とは別のサーバにより構成することも可能である。また、それぞれの構成要素は実際の装置構成と一致しない場合もある。例えば、複数のＷＷＷアプリケーションを一台のコンピュータに実装してもよいし、一台のコンピュータにおいて、ＷＷＷアプリケーションと認証サーバとを実現しても構わない。また、例えば、ＷＷＷアプリケーション２０の通信制御部２１と処理部２２とを、別々の装置として構成しても構わない。

続いて、本実施形態において、未認証のＷＷＷブラウザ１０が、ＷＷＷアプリケーション２０にアクセスしてきた場合の、ユーザ認証フローについて、図４に示すシーケンス図を元に説明する。

ＷＷＷブラウザ１０を利用しているユーザは、ＷＷＷアプリケーション２０を利用する場合には、ＷＷＷアプリケーション２０のＵＲＬ（ｕｒｌ１）を入力し、アクセスを指示する。するとＷＷＷブラウザ１０は、ＷＷＷアプリケーション２０へのアクセスを行う（Ｓ１０１）。このときのＨＴＴＰの要求メッセージでは“ＧＥＴ”メソッドを用い、例えば“ＧＥＴｕｒｌ１ＨＴＴＰ／１．ｘ”といった要求メッセージをＷＷＷアプリケーション２０へ送る。

ＷＷＷアプリケーション２０の通信制御部２１は、ＷＷＷブラウザ１０からのアクセスを受けると、ＷＷＷブラウザ１０との間にセッションが存在するか否か、すなわち認証済みか否かを判断する（Ｓ１０２）。セッションの有無は、ＷＷＷアプリケーション２０内に保持しているセッションオブジェクトとして登録されているか否かを判断するなど、任意の方法によって行えばよい。ここではそれまでにＷＷＷブラウザ１０との間にセッションが存在しない。そこで、セッションを確立するために、まず新たに、そのＷＷＷブラウザとＷＷＷアプリケーションとを関連づけた固有の識別子であるリクエストＩＤを一時的に発行して、セッションオブジェクトとして登録しておく（Ｓ１０３）。

ＷＷＷアプリケーション２０の通信制御部２１は、ＷＷＷブラウザ１０とのセッションが存在していなかったので、ＷＷＷブラウザ１０に対して認証サーバ３０による認証を行うように促すために、認証サーバ３０へのリダイレクトをＷＷＷブラウザ１０に対して指示する（Ｓ１０４）。具体的には、認証サーバ３０のＵＲＬをｓｓｏとするとき、応答時のコード“３０２”を用い、応答メッセージとして例えば“ＨＴＴＰ／１．ｘ３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙＬｏｃａｔｉｏｎ：ｓｓｏ＋ｉｄ”などとして、リダイレクトによりアクセスするように応答すればよい。なお、“ｓｓｏ＋ｉｄ”は、認証サーバ３０のＵＲＬ“ｓｓｏ”に、ＷＷＷアプリケーション２０が一時的に発行したリクエストＩＤを付加したものである。さらに、ＷＷＷアプリケーション２０のＵＲＬも付加しておくとよい。また、応答時にＷＷＷアプリケーション２０用の仮のクッキー（ｃｏｏｋｉｅ）をＷＷＷブラウザ１０に送っておいてもよい。

ＷＷＷブラウザ１０は、上述のようなＷＷＷアプリケーション２０からの応答メッセージを受けると、自動的に認証サーバ３０に対して、認証要求をするためにアクセスを行う（Ｓ１０５）。このようなリダイレクトを利用することによって、ユーザは認証サーバ３０のＵＲＬ等を知らなくても、利用したいＷＷＷアプリケーションにアクセスすれば、初回は認証サーバ３０へ自動的にアクセスされるので、利便性を向上させることができる。

また、自動的に行われるＷＷＷブラウザ１０から認証サーバ３０へのアクセス時の要求メッセージは、具体的には“ＧＥＴ”メソッドを用い、アドレス部分はＳ１０４で渡された“Ｌｏｃａｔｉｏｎ：”以降の部分、すなわち“ｓｓｏ＋ｉｄ”である。例えば“ＧＥＴｓｓｏ＋ｉｄＨＴＴＰ／１．ｘ”といった要求メッセージがＷＷＷブラウザ１０から認証サーバ３０へ渡される。なお、アドレス部分にＷＷＷアプリケーション２０のＵＲＬが含まれる場合もある。

認証サーバ３０では、ＷＷＷブラウザ１０からのアクセスを受けた場合、この時点ではいままでにＷＷＷブラウザ１０とのセッションはなく、認証を行っていない。従って、認証サーバの認証部３１が、新規にセッションを生成し、内部にセッションオブジェクトとして登録しておく。このとき、アドレス部分で渡された、通信制御部２１で生成したリクエストＩＤを用いることができる。また、アドレス部分にＷＷＷアプリケーション２０のＵＲＬが含まれる場合、そのＵＲＬも保持しておく。

新たにＷＷＷブラウザ１０からアクセスされた場合、認証部３１は、認証を行うための認証フォームをＷＷＷブラウザ１０へ送る（Ｓ１０６）。具体的には応答コード“２００”を用い、例えば応答ヘッダ“ＨＴＴＰ／１．ｘ２００ＯＫ”と、認証フォームのデータを応答メッセージとしてＷＷＷブラウザ１０に送信すればよい。このとき、認証サーバ３０用の仮のクッキーを送信しておいてもよい。

ユーザが、認証フォームに表示された欄にユーザＩＤ及びパスワードを入力したのち、そのユーザが入力したユーザＩＤ及びパスワードがＷＷＷブラウザ１０から認証サーバ３０へ送られる（Ｓ１０７）。

ＷＷＷブラウザ１０から認証サーバ３０へユーザＩＤ及びパスワードを送信する場合の具体的な要求メッセージは、“ＰＯＳＴ”メソッドを用い、例えばリクエストラインとして“ＰＯＳＴｓｓｏＨＴＴＰ／１．ｘ”、ボディ領域にユーザが入力したユーザＩＤ及びパスワードを含めればよい。

認証部３１は、ＷＷＷブラウザ１０からユーザＩＤおよびパスワードを受け取ると、個人情報管理データベース３２への問い合わせを行い、ユーザの認証を行う（Ｓ１０８）。ユーザＩＤとパスワードが正しくなければ、認証できなかった旨をＷＷＷブラウザ１０に通知し、再入力を受けるかあるいは処理を終了する。

受け取ったユーザＩＤとパスワードが正しければ、ＷＷＷブラウザ１０のユーザを正規のユーザとして認証する。このとき、認証サーバ３０へのログインが行われ、認証済である状態がユーザのユーザＩＤとともにセッションオブジェクトとして登録される。

認証サーバ３０の認証部３１での認証が行われたら、認証部３１はＷＷＷブラウザ１０に対してＷＷＷアプリケーション２０へのリダイレクトをするように、応答メッセージを返す（Ｓ１０９）。具体的には、応答コード“３０２”を使用し、例えば“ＨＴＴＰ／１．ｘ３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙＬｏｃａｔｉｏｎ：ｕｒｌ１”とし、ＷＷＷアプリケーション２０のＵＲＬ（“ｕｒｌ１”）を指定したリダイレクトをＷＷＷブラウザ１０に指示すればよい。

認証サーバ３０からのリダイレクトを受けたＷＷＷブラウザ１０は、ＧＥＴメソッドを用いて、認証サーバ３０によるユーザ認証が済んだことを通知するために、ＷＷＷアプリケーション２０にアクセスする（Ｓ１１０）。ＷＷＷブラウザ１０からのアクセスを受けたＷＷＷアプリケーション２０の通信制御部２１は、認証サーバ３０に対して、先ほど発行したリクエストＩＤをキーとして、認証されたユーザ名を要求し（Ｓ１１１）、その要求に応じて、認証サーバ３０の認証部３１は、認証されたユーザ名をＷＷＷアプリケーション２０に送信する（Ｓ１１２）。要求したユーザ名を受信した通信制御部２１は、ユーザ認証が適正に行われたユーザからのアクセスであると判断して、ＷＷＷブラウザ１０からの受信したデータを処理部２２へ渡し、ＷＷＷブラウザ１０からの要求に応じたサービスを提供する（Ｓ１１３）。例えば、処理部２２は、通信制御部２１を介して、図２に示す表示画面フォームをＷＷＷブラウザ１０に送信する。

このように、ユーザ認証を受けたユーザに対してのみ、サービスを提供するＷＷＷアプリケーションにおいて、リダイレクトを用いて、自動的にＷＷＷブラウザに対して、認証要求を行わせることで、ＷＷＷブラウザは、直接認証サーバのＵＲＬ等を知ることなしに、ユーザ認証を受けて、サービスの提供を受けることができる。

しかしながら、認証を受けた後、図２に示すような表示画面フォームが提供されたＷＷＷブラウザ１０において、ユーザが各入力フォームに必要事項の入力を行っている間に、一定時間が経過してしまうことなどが原因で、ユーザ認証に伴い確立されたセッションが切断されてしまうことがある。すると、ＷＷＷブラウザ１０が、ユーザによるデータ入力が完了した時点で、その入力データをデータベースに登録する処理をＷＷＷアプリケーション２０に行ってもらうために、その入力データを、ボディ領域に書き込んで、ＰＯＳＴメソッドを用いて、ＷＷＷアプリケーション２０にアクセスしたとしても、セッションが切断されているために、再度、リダイレクトにより認証が行われる。しかし、リダイレクトは、ＧＥＴメソッドでのみ行われるため、ＰＯＳＴメソッドのボディ領域に書き込まれたデータは、破棄されてしまう。

そこで、本実施形態では、ユーザ認証が済んだものの、一定期間が経過してしまったことなどが原因により、セッションが切断された時点で、ＷＷＷブラウザ１０が、ＰＯＳＴメソッドを用いて、ＷＷＷアプリケーション２０にアクセスしてきた場合に、図５に示すようなシーケンスを実行することで、そのＰＯＳＴメソッドのボディ領域に書き込まれたデータが破棄されてしまうことを防いでいる。

すなわち、図５において、ユーザによるデータ入力が済んだのち、ＷＷＷブラウザ１０は、ＰＯＳＴメソッドを用いて、そのボディ領域に入力されたデータを書き込んで、ＷＷＷアプリケーション２０にアクセスする（Ｓ２０１）。ＷＷＷアプリケーション２０の通信制御部２１は、そのアクセスを受けて、そのＷＷＷブラウザ１０がユーザ認証を受けているか否かを判断する（Ｓ２０２）。ここでは、タイムアウト等のために一度ユーザ認証が成功し、確立されていたセッションが切断されてしまった場合を想定しているため、通信制御部２１は、そのＷＷＷブラウザ１０について、未認証と判断する。そこで、新たにユーザ認証を行うために、改めて、一時的なリクエストＩＤを発行して（Ｓ２０３）、セッションオブジェクトとして登録しておく。さらに、本実施形態の特徴として、通信制御部２１は、そのＷＷＷブラウザとＷＷＷアプリケーションとを関連づけた固有の識別子であるリクエストＩＤに関連づけて、ＷＷＷブラウザから受け取ったＰＯＳＴメソッドのボディ領域に書き込まれたデータを、通信制御部２１が保有するＲＡＭ等の記憶部（図示せず）に一時保持する（Ｓ２０４）。

続いて、通信制御部２１は、ＷＷＷブラウザ１０に対して認証サーバ３０による認証を行うように促すために、認証サーバ３０へのリダイレクトをＷＷＷブラウザ１０に対して指示する（Ｓ２０５）。この指示は、リダイレクトのため、上述したように、ＲＦＣの規定により、ＧＥＴメソッドにより行われる。したがって、従来であれば、ＷＷＷブラウザ１０からのＰＯＳＴメソッドのボディ領域に書き込まれたデータは、ＷＷＷアプリケーションによるリダイレクトにより破棄されてしまう。しかし、本実施形態によれば、Ｓ２０５において、ＰＯＳＴメソッドのボディ領域に書き込まれたデータは、リクエストＩＤと関連づけられて一時保持されるため、破棄されずに済む。

そして、ＷＷＷアプリケーション２０からのリダイレクトを受けたＷＷＷブラウザ１０は、認証サーバ３０との間で、図４に示すシーケースのＳ１０５〜Ｓ１０９と同様の処理をＳ２０６〜Ｓ２１０において、実行する。さらに、認証サーバ３０による認証に成功すると、認証サーバ３０の認証部３１からのリダイレクトにより、ＷＷＷブラウザ１０は、ＷＷＷアプリケーション２０に、認証サーバ３０による認証が済んだことを通知するために、ＧＥＴメソッドを用いてアクセスする（Ｓ２１１）。ＷＷＷブラウザ１０からのアクセスを受けて、ＷＷＷアプリケーション２０の通信制御部２１は、図４に示すシーケースのＳ１１１〜Ｓ１１２と同様の処理をＳ２１２〜Ｓ２１３において、実行することで、正式にユーザ認証が済んだことを認証サーバ３０に対して確認する。

認証サーバ３０への認証確認の後、本実施形態において、特徴的な処理として、通信制御部２１は、リクエストＩＤと関連づけられ、一時保持しているデータが存在するか否かを判断する（Ｓ２１４）。ここでは、先ほど一時保持したデータが存在するため、ＷＷＷアプリケーション２０は、その一時保持したデータを復元し、ＰＯＳＴメソッド後のｒｅｑｕｅｓｔオブジェクトをエミュレートするようなラッパーを作成し、処理部２２へ渡す（Ｓ２１５）。処理部２２は、通信制御部２１によって一時保持したデータを復元し、エミュレートされたＰＯＳＴメソッドを用いて処理を行うため、Ｓ２０１において、ＰＯＳＴメソッドを用いてアクセスした際の、そのＰＯＳＴメソッドのボディ領域に書き込まれたデータは破棄されることなく、処理部２２において処理されて、その処理結果が、通信制御部２１を介してＷＷＷブラウザ１０に提供される（Ｓ２１６）。

よって、たとえ、図２に示すような表示画面フォームが提供されたＷＷＷブラウザ１０において、ユーザが各入力フォームに必要事項の入力を行っている間に、一定時間が経過してしまうことなどが原因で、ユーザ認証に伴い確立されたセッションが切断されてしまい、改めて、リダイレクトにより認証が行われたとしても、通信制御部２１が、そのリダイレクトの前にＰＯＳＴメソッドを用いてアクセスされた際のデータを復元し、処理部２２に提供するため、ユーザは、認証後に再度同じデータを、入力する手間を省くことができ、ＷＷＷアプリケーションの利便性の向上につながる。

なお、本実施形態において、説明したユーザ認証方法は、一例に過ぎず、リダイレクトを用いた認証を行うＷＷＷアプリケーションを含むシステムであれば、どのような認証方法でもよい。また、本実施形態では、ユーザ認証の際に用いるリクエストＩＤを、ＰＯＳＴメソッドのボディ領域に書き込まれたデータを一時保持する際に、併用している。しかし、リクエストＩＤとは別に、固有のＩＤを発行して、そのＩＤに基づいて、データの保持及び復元を行っても構わない。

また、本実施形態では、ＨＴＴＰ通信において、リダイレクトを用いた認証を行った後にアプリケーションを提供するシステムにおいて、タイムアウト等が原因で、一度確立されたセッションが切断してしまい、再認証が行われたことにより、ＰＯＳＴメソッドのボディ領域に書き込まれたデータが失われてしまうことを例として挙げた。しかし、ＨＴＴＰ通信でのＰＯＳＴメソッドを利用したシステムでなくとも、認証後に、タイムアウト等が原因で、一度確立されたセッションが切断してしまい、再度認証が行われるシステムであれば、同様に、認証前に受信したいデータを一時保持しておき、認証確認後に、その認証前のデータを復元することで、実現可能である。

さらに、本実施形態では、ＷＷＷブラウザ１０とＷＷＷアプリケーション２０との間に確立された１つのセッションに対して、１つのＰＯＳＴメソッドのボディ領域に書き込まれたデータを関連づけて一時保持するのではなく、ＷＷＷブラウザ１０とＷＷＷアプリケーション２０とに関連づけて発行されるリクエストＩＤに関連づけて、ＰＯＳＴメソッドのボディ領域に書き込まれたデータを一時保持する。よって、確立された１つのセッションに対して、ＰＯＳＴメソッドのボディ領域に書き込まれたデータを、複数保持することができる。

加えて、１つのセッションに、ＰＯＳＴメソッドのボディ領域に書き込まれたデータを、複数保持することができるため、図２に示すような、フレームで複数の入力フォームに分割された画面において、複数のＰＯＳＴメソッドにより複数のデータが入力された場合でも、データの競合をすることなく、個々のフレームに入力されたデータを適切に管理し、復元することが可能である。

また、本実施形態は、ＷＷＷアプリケーション２０の通信制御部２１で行う処理内容に改良を加えるだけで、実現可能なため、処理部２２での処理内容や、ＷＷＷブラウザ１０での処理内容は、従来と同一でよい。したがって、本実施形態を実現するために、ＷＷＷアプリケーションのシステム変更を大幅に行ったり、ＷＷＷブラウザの仕様を変更する必要がなく、容易に現状のシステムに導入することが可能である。

本実施形態におけるシステム構成図である。本実施形態のＷＷＷアプリケーションがＷＷＷブラウザに提供する表示画面の一例を示す図である。本実施形態の認証サーバが、ユーザ認証を行なうためにＷＷＷブラウザに提供する認証フォームの一例である。本実施形態におけるユーザ認証のシーケンスを示す図である。本実施形態において、ＰＯＳＴメソッドを送信したＷＷＷブラウザが認証を受けていなかった場合のシーケンスを示す図である。

符号の説明

１０ＷＷＷブラウザ、２０ＷＷＷアプリケーション、２１通信制御部、２２処理部、３０認証サーバ、３１認証部、３２個人情報管理データベース、４０ネットワーク。

Claims

利用者によりクライアント端末から送信された、指定したサービス処理装置が処理する処理対象データと、指定したサービス処理装置を特定するサービス識別子とを含む情報データを受信する受信手段と、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証装置の認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持する保持手段と、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該クライアント端末に対して、前記認証装置への認証要求を指示する認証要求指示手段と、
クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたサービス識別子に基づき特定したサービス処理装置に提供する提供手段と、
を備える通信制御装置。
利用者によりクライアント端末から送信された、指定したアプリケーション処理装置が処理する処理対象データがボディ領域に書き込まれ、かつ指定したアプリケーション処理装置のアドレスがヘッダ領域に書き込まれたＰＯＳＴメソッドを受信する受信手段と、
前記受信手段により受信されたＰＯＳＴメソッドを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末と当該ＰＯＳＴメソッドのヘッダ領域に書き込まれたアプリケーション処理装置のアドレスとに関連づけて、当該ＰＯＳＴメソッドのボディ領域に書き込まれた処理対象データを保持する保持手段と、
前記受信手段により受信されたＰＯＳＴメソッドを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末に対して、前記認証サーバへの認証要求を指示するリダイレクトを行うリダイレクト手段と、
クライアント端末から前記リダイレクト手段が行ったリダイレクトに対する認証が済んだことを示すＧＥＴメソッドによる通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたアドレスに基づき特定したアプリケーション処理装置に提供する提供手段と、
を備える通信制御装置。
クライアント端末からのアクセスを制御する通信制御手段と、アクセスしてきたクライアント端末によって指定されたアプリケーションサービスのサービス処理を実行するサービス処理手段と、を備えるアプリケーションサーバにおいて、
前記通信制御手段は、
利用者によりクライアント端末から送信された、前記サービス処理手段がサービス処理を実行する処理対象データと、指定されたアプリケーションサービスを特定するサービス識別子とを含む情報データを受信する受信手段と、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証サーバの認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持する保持手段と、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該情報データを送信したクライアント端末に対して、前記認証サーバへの認証要求を指示する認証要求指示手段と、
クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持手段に保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該処理対象データに関連づけられたサービス識別子に基づき特定したアプリケーションサービスのサービス処理を実行させるために、当該処理対象データに関連づけられたクライアント端末から送信されたデータとして、前記サービス処理手段に提供する提供手段と、
を備えるアプリケーションサーバ。
利用者によりクライアント端末から送信された、指定したサービス処理装置が処理する処理対象データと、指定したサービス処理装置を特定するサービス識別子とを含む情報データを受信する受信手段、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が所定の認証装置の認証を受けていない場合、当該クライアント端末と当該情報データに含まれるサービス識別子とに関連づけて、当該情報データに含まれる処理対象データを保持部に保持させる保持手段、
前記受信手段により受信された情報データを送信したクライアント端末の利用者が前記認証装置の認証を受けていない場合、当該情報データを送信したクライアント端末に対して、前記認証装置への認証要求を指示する認証要求指示手段、
クライアント端末から前記認証要求の指示に対する認証が済んだことを示す通知を受けるのを待って、前記保持部が保持した処理対象データのうち、当該クライアント端末に関連づけられた処理対象データを、当該クライアント端末から送信されたデータとして、当該処理対象データに関連づけられたサービス識別子に基づき特定したサービス処理装置に提供する提供手段、
としてコンピュータを機能させるためのプログラム。