JP4467256B2 - 代理認証プログラム、代理認証方法、および代理認証装置 - Google Patents

代理認証プログラム、代理認証方法、および代理認証装置 Download PDF

Info

Publication number
JP4467256B2
JP4467256B2 JP2003175139A JP2003175139A JP4467256B2 JP 4467256 B2 JP4467256 B2 JP 4467256B2 JP 2003175139 A JP2003175139 A JP 2003175139A JP 2003175139 A JP2003175139 A JP 2003175139A JP 4467256 B2 JP4467256 B2 JP 4467256B2
Authority
JP
Japan
Prior art keywords
authentication
server
response
proxy
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2003175139A
Other languages
English (en)
Other versions
JP2005011098A (ja
Inventor
秀成 三輪
克幸 松永
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2003175139A priority Critical patent/JP4467256B2/ja
Publication of JP2005011098A publication Critical patent/JP2005011098A/ja
Application granted granted Critical
Publication of JP4467256B2 publication Critical patent/JP4467256B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Description

【0001】
【発明の属する技術分野】
本発明は他の装置への認証手続きを代理する代理認証プログラム、代理認証方法、および代理認証装置に関し、特に異なる認証方式による認証手続きを行う代理認証プログラム、代理認証方法、および代理認証装置に関する。
【0002】
【従来の技術】
企業内のネットワークでは、ネットワーク内に複数のサーバ(あるいはサービスを提供するアプリケーションプログラム)が存在し、様々なサービスがネットワークを介して提供される。ただし、企業内のネットワークであっても、一部の機能に関しては使用可能なユーザが制限される。たとえば、社員の出退勤を管理するシステムに対しては、所定の役職以上のユーザ、あるいは人事部等の所定の部署のユーザに対してのみアクセスを許可する必要がある。以下、サービスを提供する機能(サーバアプリケーション)をサーバ機能と呼ぶこととする。
【0003】
一般的には、サービスを利用可能なユーザを制限するため、サーバ機能毎にユーザ認証が行われる。ユーザ認証では、サーバ機能がユーザに対して、ユーザ名とパスワードとの入力を要求する。入力されたユーザ名とパスワードとの組が予めサーバ機能に登録されていれば、サーバ機能は、そのユーザに許可されている範囲の機能を提供する。このようなユーザ認証は、ネットワーク内にサーバ機能が多数存在する場合でも、原則的に個別に行われる。
【0004】
ところで、最近の業務処理のシステム化に伴い、社内業務の多くが、その業務を支援するサーバ機能を利用して行われる。そのため、社員が業務を遂行する上で、様々なサーバ機能に対してユーザ認証を行う必要が生じる。この場合、個別のサーバ機能へのユーザ認証を行うには、各ユーザがユーザ名とパスワードとの組を個人で管理しなければならず、パスワード等の管理負担が大きい。また、一日に何度もユーザ認証手続きを行うのは、業務の作業効率低下に繋がる。
【0005】
そこで、従来はシングルサインオンと呼ばれるシステムが利用されている。シングルサインオンでは、ユーザが一度認証を受けるだけで、そのユーザに対したアクセスを許可している機能をユーザ利用できる。
【0006】
シングルサインオンを実現する技術の1つにPKI(Public Key Infrastructure)を用いた技術がある。PKIは、電子署名と暗号技術を兼ね備え、安全な電子通信を確保する技術である。PKIシステムでは、ユーザ認証したユーザに対して電子証明書を発行する。そして、電子証明書を保持しているユーザは、その電子証明書に応じた各種サービスの提供を受けることができる。
【0007】
また、シングルサインオンを実現する別の技術として、プロキシサーバで代理認証する方式がある。この技術では、各サーバ機能に対するユーザ認証のためのデータをプロキシサーバに保持する。そして、ユーザからサーバ機能へのアクセス要求が出されると、プロキシサーバが代理でサーバ機能との間でユーザ認証手続きを行う(たとえば、特許文献1参照)。
【0008】
また、ユーザ端末からWebサーバへのプロキシサーバを介したアクセスで一度認証された場合、そのデータをプロキシサーバに記憶しておく。そして、同じユーザ端末による次回以降のログイン時には、プロキシサーバに記憶されたデータを使用する。この方式に寄れば、様々な形式のログインプロトコルに対応することができる(たとえば、特許文献2参照)。
【0009】
【特許文献1】
特開平10−177552号公報(第1図)
【特許文献2】
特開2002−32340号公報(第1図)
【0010】
【発明が解決しようとする課題】
しかし、PKIを用いた技術の場合は、Webブラウザ、Webサーバともに電子証明書に対応した機構を必要とする上、電子証明書のためのインフラを必要とする。そのため、既存のシステムをそのまま流用するのは困難である。
【0011】
すなわち、一般のプロキシサーバで代理認証する方式では固定的な認証プロトコルを用いるため、サーバ機能毎に認証方式が異なる場合には採用できない。しかも、現実のWebサーバの認証方式は開発者の自由であるため様々なものが存在する。一つの代理認証型のプロキシサーバがそれらに対し代理認証を行うのは困難であり、代理認証プロキシの有用性を減じさせている。
【0012】
たとえば、特許文献1に記載された方式では、代理サーバで複数の認証情報を管理し、クライアントに代わってサーバに対して認証情報を送信するだけであり、サーバ毎に異なる手順の認証手続きを実行することができない。具体的には、認証情報を送信するだけで認証可能なサーバもあれば、サーバが提供するフォームデータ内の所定のパラメータとして設定した認証情報を送信することで認証可能なサーバもある。このように、単に認証情報を送信するだけでは、代理認証ができないサーバも多数存在する。
【0013】
また、特許文献2に示された方式であればサーバ機能毎に異なる認証方式が採用されている場合にも適用可能である。しかし、特許文献2に示されたような認証時のデータを全て記録する方式では、多数のユーザが同じサーバを利用した場合は、認証用の通信データの保存域にほとんど同じだが少しだけ異なるデータを多数保持する必要が生じる。そのため、システムの資源(メインメモリやハードディスクデバイス等)の利用効率が悪くなる。これは、実際の認証用通信データで、ユーザ毎に異なる部分は僅かであり、データの多くは共通のヘッダやフッターによって占められるためである。
【0014】
一般的に、必要なハードウェア資源の量が不明な場合、システムの安定運用のためには、余裕を持ったハードウェア環境を整えておく必要がある。そのため、システムの規模が肥大化し、システムの構築コストが増加していた。
【0015】
本発明はこのような点に鑑みてなされたものであり、ハードウェア資源を効率よく利用して、異なる認証方式のサーバへの代理認証を行うことができる代理認証プログラム、代理認証方法、および代理認証装置を提供することを目的とする。
【0016】
【課題を解決するための手段】
本発明では上記課題を解決するために、図1に示すような処理をコンピュータに実行させる代理認証プログラムが提供される。この代理認証プログラムは、他の装置への認証手続きを代理するためのものであり、コンピュータに対して以下の処理を実行させる。
【0017】
コンピュータは、クライアント機能2a,2b,2c,・・・からの要求に応じて、ネットワークを介して接続されるサーバ機能3a,3b,3c,・・・に対してアクセスする(ステップS1)。コンピュータは、サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、サーバ機能からの応答が複数の認証許否確認論理のいずれかに適合するか否かにより、サーバ機能との間のユーザ認証の要否を判断する(ステップS2)。サーバ機能との間のユーザ認証が必要と判断した場合、クライアント機能との間のセッションの確立の有無を判断し、セッションが未確立の場合、クライアント機能に対してユーザ認証を要求し、クライアント機能との間のユーザ認証が完了するとクライアント機能との間にセッションを確立する。そして、サーバ機能との間のユーザ認証が必要と判断した場合であって、クライアント機能との間でセッションが確立済みになると、コンピュータは、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きを行う(ステップS3)。
【0018】
このような代理認証プログラムによれば、コンピュータにより、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証を要求する応答が返されると、クライアント機能との間のセッションの確立の有無が確認される。セッションが未確立の場合、クライアント機能との間のセッションが確立される。そして、サーバ機能からの応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。
【0019】
また、上記課題を解決するために他の装置への認証手続きを代理するコンピュータの代理認証方法において、前記コンピュータが、クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバに対してアクセスし、前記サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、前記コンピュータが、記応答が前記複数の認証許否確認論理のいずれかに適合するか否かにより、前記サーバ機能との間のユーザ認証の要否を判断し、前記コンピュータが、前記サーバ機能との間のユーザ認証が必要と判断した場合、前記クライアント機能との間のセッションの確立の有無を確認し、前記コンピュータが、前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、前記クライアント機能との間のユーザ認証が完了すると前記クライアント機能との間に前記セッションを確立し、前記コンピュータが、前記サーバ機能との間のユーザ認証が必要と判断した場合であって、前記クライアント機能との間で前記セッションが確立済みになると、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、ことを特徴とする代理認証方法が提供される。
【0020】
このような代理認証方法によれば、コンピュータにより、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証を要求する応答が返されると、クライアント機能との間のセッションの確立の有無が確認される。セッションが未確立の場合、クライアント機能との間のセッションが確立される。そして、サーバ機能からの応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。
【0021】
また、上記課題を解決するために、他の装置への認証手続きを代理する代理認証装置において、クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスするアクセス手段と、前記サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、前記応答が前記複数の認証許否確認論理のいずれかに適合するか否かにより、前記サーバ機能との間のユーザ認証の要否を判断する認証要否判断手段と、前記サーバ機能との間のユーザ認証が必要と判断された場合、前記クライアント機能との間のセッションの確立の有無を確認し、前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、前記クライアント機能との間のユーザ認証が完了すると前記クライアント機能との間に前記セッションを確立する手段と、前記サーバ機能との間のユーザ認証が必要と判断された場合であって、前記クライアント機能との間で前記セッションが確立済みになると、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、を有することを特徴とする代理認証装置が提供される。
【0022】
このような代理認証装置によれば、アクセス手段により、クライアント機能からの要求に応じてサーバ機能へのアクセスが行われる。そして、サーバ機能から応答が返されると、認証要否判断手段により、ユーザ認証の要否を判断される。ユーザ認証が必要な場合、クライアント機能との間のセッションの確立の有無が確認され、未確立の場合は、クライアント機能との間にセッションが確立される。ユーザ認証が必要な場合であってセッションが確立済みになると、代理認証手段により、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きが行われる。
【0023】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【0024】
図1は、実施の形態に適用される発明の概念図である。代理認証装置1は、複数のクライアント機能2a,2b,2c,・・・と複数のサーバ機能3a,3b,3c,・・・との論理的な通信経路上に設けられている。ここで、論理的な通信経路とは、複数のクライアント機能2a,2b,2c,・・・のいずれかと複数のサーバ機能3a,3b,3c,・・・のいずれかとの間の通信(少なくとも代理認証を必要とする通信)が、必ず代理認証装置1を経由して行われることを意味する。
【0025】
代理認証装置1は、クライアント機能2a,2b,2c,・・・がサーバ機能3a,3b,3c,・・・に対して実行すべきユーザ認証手続きを、クライアント機能2a,2b,2c,・・・の代理で実行することができる。なお、代理認証装置1には、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されている。また、各認証許否確認論理に対応付けて、認証手順が定義されている。認証手順は、認証手続きの際にクライアント機能2a,2b,2c,・・・側で実行すべき処理内容を、認証方式毎に定義したものである。
【0026】
クライアント機能2a,2b,2c,・・・は、ユーザの操作入力に応答してサーバ機能3a,3b,3c,・・・に対して要求を送信する機能を有している。クライアント機能2a,2b,2c,・・・は、たとえば、それぞれが個別のクライアントコンピュータに実装されたクライアントアプリケーションである。
【0027】
サーバ機能3a,3b,3c,・・・は、クライアント機能2a,2b,2c,・・・から送られた要求に応じた処理を行う。サーバ機能3a,3b,3c,・・・は、たとえば、プロキシサーバ等に実装されたサーバアプリケーションである。なお、サーバ機能3a,3b,3c,・・・はユーザ認証機能を有しており、ユーザ認証を完了したクライアント機能2a,2b,2c,・・・からの要求に対してのみ、処理機能を提供する。また、各サーバ機能3a,3b,3c,・・・は、それぞれ異なる認証方式を採用している。
【0028】
ここで、クライアント機能2a,2b,2c,・・・からサーバ機能3a,3b,3c,・・・へアクセスする場合、代理認証装置1において、以下の処理が行われる。
【0029】
代理認証装置1は、クライアント機能2a,2b,2c,・・・からの要求に応じて、ネットワークを介して接続されるサーバ機能3a,3b,3c,・・・に対してアクセスする(ステップS1)。アクセスされたサーバ機能は、ユーザ認証が必要であり、アクセス要求を出力したクライアント機能のユーザ認証が未完了の場合、ユーザ認証を要求する応答を代理認証装置1に返す。
【0030】
代理認証装置1は、サーバ機能からの応答が複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する(ステップS2)。そして、ユーザ認証が必要と判断した場合、代理認証装置1は、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きを行う(ステップS3)。
【0031】
このような代理認証装置1によれば、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証の未完了を示す応答が返されると、その応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。サーバ機能からの応答を解析してサーバ機能が採用する認証方式に応じた認証手順を判断し、その認証手順で代理認証を行うことで、認証手順等を格納しておくべき記憶容量が少なくてすむ。
【0032】
たとえば、複数のクライアント機能2a,2b,2c,・・・が同一のサーバ機能3aにアクセスする場合を考える。このとき、従来の技術(特許文献2参照)のように全ての認証データを記録し、そのデータから認証手続きを再現することで代理認証を行う場合、クライアント機能2a,2b,2c,・・・毎の認証手続きを保存しなければならない。本発明のように、サーバ機能3aからの応答によって該当する認証手続きを決定し、その認証手続きで代理認証を行うようにすれば、サーバ機能3aに対応付けて1つの認証手続きを保持しておけばよい。
【0033】
しかも、サーバ機能からの応答によって必要な認証手続きを決定するため、各サーバ機能3a,3b,3c,・・・は、それぞれ異なる認証方式を採用していても、それぞれの認証方式に応じた認証手続きで代理認証を行うことができる。
【0034】
なお、クライアント機能2a,2b,2c,・・・毎のユーザ認証情報(たとえば、ユーザ名とパスワード)を保持する必要はあるが、これらは短い文字列からなる情報である。そのため、ユーザ認証情報は、認証手続きの処理手順を全て記録する場合に比べて、少ない記憶容量で済む。
【0035】
以下に、本実施の形態を具体的に説明する。以下の実施の形態は、プロキシサーバに代理認証装置の機能を実装し、Webサーバへの代理認証を行う場合の例である。
【0036】
図2は、本実施の形態を提供するネットワークシステムの構成例を示す図である。図2に示すように、複数のクライアント11,12,13,・・・、複数のサーバ31,32,33,・・・およびプロキシサーバ100でシステムが構成されている。
【0037】
クライアント11,12,13,・・・は、ユーザが使用するコンピュータである。クライアント11,12,13,・・・とプロキシサーバ100との間は、たとえば、LAN(Local Area Network)で接続される。ユーザは、クライアント11,12,13,・・・を用いて、プロキシサーバ100に対してログイン(ベーシック(Basic)認証ログイン)を行うことができる。本実施の形態では、各クライアント11,12,13,・・・には、クライアント機能としてWebブラウザが実装されており、Webブラウザによってサーバ31,32,33,・・・にアクセスするものとする。
【0038】
サーバ31,32,33,・・・は、クライアント11,12,13,・・・からの要求に応じて所定のサービスを提供するサーバコンピュータである。サーバ31,32,33,・・・とプロキシサーバ100との間は、LAN、高速専用回線、インターネット等で接続される。サーバ31,32,33,・・・には、サーバ機能等が実装され、サーバ機能毎にユーザ認証機能を有している。本実施の形態では、各サーバ31,32,33,・・・には、サーバ機能としてWebサーバが実装され、WebサーバによってクライアントのWebブラウザに対するコンテンツの提供サービス等を行う。
【0039】
プロキシサーバ100は、クライアント11,12,13,・・・の代理でサーバ31,32,33,・・・にアクセスするコンピュータである。プロキシサーバ100には、複数のログインアルゴリズム(ベーシック認証やフレーム認証)が定義されている。サーバ31,32,33,・・・からユーザ認証が要求された場合、プロキシサーバ100は要求されたユーザ認証用のログインアルゴリズムを識別し、該当するアルゴリズムでログイン手続きを行うことができる。たとえば、プロキシサーバ100は、サーバ31,32,33,・・・にアクセスする際、ユーザ認証を要求されると、クライアント11,12,13,・・・に代わってユーザ認証手続きを行い、サーバ31,32,33,・・・にログインする。
【0040】
このようなシステムにより、ユーザはクライアント(たとえば、クライアント11)を利用してサーバ31,32,33,・・・にアクセスできる。そして、1つのWebサーバ(たとえば、サーバ31)からユーザ認証が要求されると、プロキシサーバ100からクライアント11にユーザ認証が要求される。すると、ユーザがクライアント11を操作し、プロキシサーバ100に対してベーシック認証ログインを行う。
【0041】
プロキシサーバ100は、クライアント11から送られるユーザ認証情報を、内部に保持するユーザ情報テーブルと照合することでベーシック認証ログインを認め、サーバ31に対してログインする。その際、プロキシサーバ100は、サーバ31の認証方式に合ったアルゴリズムでログイン手続きを行う。
【0042】
その後、クライアント11から他のWebサーバ32,33,・・・へのアクセスの際にユーザ認証が要求されると、そのWebサーバの認証方式に合ったアルゴリズムで、プロキシサーバ100がログイン手続きを行う。ログイン手続き完了後は、クライアント11が要求するサービスがWebサーバにおいて提供され、結果がクライアント11に渡される。
【0043】
図3は、プロキシサーバのハードウェア構成例を示す図である。プロキシサーバ100は、CPU(Central Processing Unit)101によって装置全体が制御されている。CPU101には、バス107を介してRAM(Random Access Memory)102、ハードディスクドライブ(HDD:Hard Disk Drive)103、グラフィック処理装置104、入力インタフェース105、および通信インタフェース106が接続されている。
【0044】
RAM102には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM102には、CPU101による処理に必要な各種データが格納される。HDD103には、OSやアプリケーションプログラムが格納される。
【0045】
グラフィック処理装置104には、モニタ11が接続されている。グラフィック処理装置104は、CPU101からの命令に従って、画像をモニタ11の画面に表示させる。入力インタフェース105には、キーボード12とマウス13とが接続されている。入力インタフェース105は、キーボード12やマウス13から送られてくる信号を、バス107を介してCPU101に送信する。
【0046】
通信インタフェース106は、ネットワーク10に接続されている。通信インタフェース106は、ネットワーク10を介して、他のコンピュータ(クライアント11,12,13,・・・やサーバ31,32,33,・・・)との間でデータの送受信を行う。
【0047】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図3には、プロキシサーバ100のハードウェア構成を示したが、クライアント11,12,13,・・・やサーバ31,32,33,・・・も同様のハードウェア構成で実現することができる。
【0048】
次に、プロキシサーバ100の機能について具体的に説明する。なお、以下の説明では、クライアント11からサーバ31やサーバ32に対してアクセスする場合を例に採る。
【0049】
図4は、プロキシサーバの機能を示すブロック図である。なお、図4に示すように、プロキシサーバ100には、クライアント11に実装されたWebブラウザ11aとサーバ31,32に実装されたWebサーバ31a,32aとの間で通信を行うことができる。
【0050】
プロキシサーバ100は、データベース110、セッション情報テーブル121、タイマ122、タイムアウト駆動部123、ブラウザ入力受付部131、プロキシサーバ認証部132、プロキシサーバ認証要求部133、通信状態保持部134、Webサーバ識別部135、Webサーバ要求生成部136、Webサーバ通信部137、レスポンス分析部138、認証処理判定部139、ログイン処理命令生成部140、コンテンツ変換部141、およびブラウザ応答生成部142を有している。
【0051】
データベース110には、代理認証に必要なデータが格納されている。データベース110の内容は、ユーザ情報テーブル111とWebサーバ情報112とに分かれる。
【0052】
ユーザ情報テーブル111は、クライアント11,12,13,・・・を使用するユーザに関する情報が登録されたデータベースである。たとえば、ユーザ情報テーブル111には、各ユーザがプロキシサーバ100にベーシックログインするためのユーザ認証情報や、ユーザがサーバ31,32,33,・・・にログインするためのユーザ認証情報が、ユーザ毎に格納されている。本実施の形態では、ユーザ情報テーブル111の内容は、システムの管理者によって予め設定されるものとする。
【0053】
Webサーバ情報112は、代理認証の対象とするWebサーバに関する情報である。Webサーバ情報112は、システムテーブル112aとレスポンス分析・ログイン命令テーブル112bとに別れている。本実施の形態では、Webサーバ情報112の内容は、システムの管理者によって予め設定されるものとする。
【0054】
システムテーブル112aは、サーバ機能毎にWebサーバのURL(Uniform Resource Locator)や認証方式が管理されている。
レスポンス分析・ログイン命令テーブル112bには、Webサーバへのログインに必要な情報が格納されている。
【0055】
セッション情報テーブル121には、クライアントとの間で確立したセッションに関する情報が登録されている。セッションに関する情報には、タイムアウト時刻も含まれる。セッション情報テーブル121の内容は、システムの運用中に動的に追加や削除される。
【0056】
ここで、プロキシサーバ100の他の要素を説明する前に、各情報のデータ構造例について詳細に説明する。
図5は、ユーザ情報テーブルのデータ構造例を示す図である。ユーザ情報テーブル111には、プロキシサーバ認証情報に対応付けて、システムID、ユーザ名およびパスワードの組がWebサーバ毎に設定されている。各欄の横方向に並べられた情報同士が互いに関連づけられて、各ユーザのユーザ情報を構成している。
【0057】
プロキシサーバ認証情報の欄は、ユーザ名の欄とパスワードの欄とに分かれている。ユーザ名の欄には、ユーザ名が設定される。パスワードの欄には、ユーザ名に対応するパスワードが設定される。
【0058】
システムIDの欄には、ユーザ認証対象となるWebサーバの識別情報が設定される。図5の例では、「Sys」に続くアルファベットがサーバ(ネットワーク上のノード)の識別子であり、アルファベットに続く数字がサーバ内のWebサーバの識別子である。従って、「SysA0」と「SysA1」とは、同じサーバ内の別々のWebサーバを示している。
【0059】
ユーザ名の欄には、Webサーバに設定されているユーザ認証情報のユーザ名が設定される。パスワードの欄には、Webサーバに設定されているユーザ認証情報のパスワードが設定される。
【0060】
図6は、システムテーブルのデータ構造例を示す図である。システムテーブル112aには、システムID、仮想URL、実URL、および認証タイプの欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられて、各Webサーバに関する情報を構成している。
【0061】
システムIDの欄には、Webサーバの識別情報が設定される。
仮想URLの欄には、クライアントからWebサーバにアクセスするための仮想的なURLが設定される。Webブラウザからは、仮想URLを指定したアクセス要求が出される。
【0062】
実URLの欄には、Webサーバの実際の所在を示すURLが設定される。なお、仮想URLと実URLとは同一の場合もある。
認証タイプの欄には、Webサーバにおけるユーザ認証方式の名称が設定される。図6の例では、認証タイプとして「フォーム」、「ベーシック」、「null」が設定されている。
【0063】
フォーム認証は、認証されていない要求をWebサーバ31a側でHTMLフォームにリダイレクトするシステムである。クライアント(プロキシサーバ100がWebブラウザ11aの代わりにクライアントとして機能する)には、認証用のフォームが渡される。そこで、フォームに対して認証情報を入力し、認証情報を含むフォームをWebサーバ31aに送信する。
【0064】
ベーシック認証では、認証されていない要求を受け取ったWebサーバ31aから認証を要求する応答が返されると、クライアント(プロキシサーバ100がWebブラウザ11aの代わりにクライアントとして機能する)に認証情報(ユーザ名とパスワード)入力用のダイアログが表示される。そのダイアログに対して認証情報を入力すると、その認証情報がWebサーバ31aに送信される。
【0065】
nullは、認証が不要であることを示している。
なお、仮想URLは、HTTP(HyperText Transfer Protocol)のクッキー送信範囲の制限を回避し、外部(Webサーバ31,32,33,・・・側)のネットワーク上のサーバに対し、内部(クライアント11,12,13,・・・側)にあるサーバと同じようにシングルサインオンを提供するために利用される。すなわち、本実施の形態では、プロキシサーバ100でのユーザ認証が完了しているか否かを示すセッション情報を、クライアントにおいてHTTPクッキーで管理している。このHTTPクッキーはその仕様上、ドメイン名が後方一致している場合に限り、異なるドメインに対して設定することができる。
【0066】
たとえば、プロキシサーバ100のドメイン名がaaa.bbb.comであり、ユーザがアクセスしたいサーバ機能のドメイン名がddd.bbb.comである場合は、bbb.comの部分が同じ(後方一致)である。したがって、プロキシサーバ100が仮想URLを用いなくてもクッキー機構が機能する。しかし、対象となるWebサーバのドメイン名がxxx.zzz.comだった場合には後方一致せず、プロキシサーバ100がその通信を操作し、認証情報をクッキーに付加したとしても、ブラウザ側は仕様によりaaa.bbb.comプロキシサーバ100のクッキーとは認められない。そのため、本実施の形態の認証ロジックが成立しない。
【0067】
そこで本実施の形態では、xxx.zzz.comの仮想URLをxxx.bbb.comと設定する。ユーザはWebブラウザからURLとしてxxx.bbb.comを指定して、プロキシサーバ100経由でアクセスを行う。プロキシサーバ100は内部で仮想URL変換を行い、実際の通信をxxx.zzz.comに対して行う。プロキシサーバ100はxxx.zzz.comからの応答データとクッキーを組み合わせてユーザのWebブラウザに返送する。このときWebブラウザはURLがxxx.zzz.comのWebサーバからではなく、URLがxxx.bbb.comのWebサーバからの通信と判断する。そのため、クッキーは無事受け入れられる。これにより、本発明の効果がインターネット全体に適用可能で、実用性が高まる。
【0068】
図7は、レスポンス分析・ログイン命令テーブルのデータ構造例を示す図である。レスポンス分析・ログイン命令テーブル112bには、システムID、ログイン処理情報、および認証識別情報の欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられ、各Webサーバへのユーザ認証手続きに必要な情報を構成している。
【0069】
システムIDの欄には、Webサーバの識別情報が設定される。
ログイン処理情報の欄には、Webサーバへのユーザ認証(ログイン)手続きに必要な情報が設定される。ログイン処理情報の欄には、認証URL、メソッド、フォーム名の欄が設けられている。
【0070】
認証URLの欄には、該当Webサーバへログインする際にアクセスすべきURLが設定される。
メソッドの欄には、HTTPにおけるリクエストの種類(メソッド)が設定さえる。メソッドには、「GET」や「POST」がある。GETは、Webサーバから情報を引き出すためのメソッドである。POSTは、Webサーバに対して情報を送信するためのメソッドである。
【0071】
フォーム名の欄には、認証情報を設定すべきフォームの名称が設定される。フォーム名の欄には、ユーザ、パスワード、付加データの欄が設けられている。ユーザの欄には、ユーザ名を設定すべきフォームの名称が設定される。パスワードの欄には、パスワードを設定すべきフォームの名称が設定される。付加データの欄には、ユーザ認証に際して付加すべき情報を設定するためのフォームの名称が設定される。この付加データの欄には、1つのシステムIDに対応付けて1個あるいは複数(m個:mは1以上の自然数)の情報を設定することができる。
【0072】
認証識別情報の欄には、Webサーバからの応答が認証を要求しているか否かを識別するための情報が設定される。認証識別情報の欄には、レスポンスコード、認証ヘッダ、および識別内容データの欄が設けられている。
【0073】
レスポンスコードの欄には、Webサーバからの応答の種別を示すコード(レスポンスコード)が設定される。識別ヘッダの欄には、認証の要求を示す応答のヘッダに含まれるべき情報が設定される。この識別ヘッダの欄には、1つのシステムIDに対応付けて1個あるいは複数(n個:nは1以上の自然数)の情報を設定することができる。識別内容データの欄には、認証の要求を示す応答の内容に含まれるべき情報が設定される。
【0074】
図8は、セッション情報テーブルのデータ構造例を示す図である。セッション情報テーブル121には、クライアントとの間で確立したセッションに関する情報が設定される。セッション情報テーブル121には、セッションID、ユーザ名、ログイン時刻、およびタイムアウト予告時刻の欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられ、セッション毎の情報を構成している。
【0075】
セッションIDの欄には、確立されたセッションの識別情報が設定される。ユーザ名の欄には、セッションの確立を要求したユーザの識別情報が設定される。ログイン時刻の欄には、ユーザがプロキシサーバ100に対してログイン(ユーザ認証が成功したこと)した時刻が設定される。タイムアウト予告時刻には、セッションを切断する時刻が設定される。
【0076】
以上が、プロキシサーバ100で管理される各データベースのデータ構造である。以下、図4の説明に戻り、プロキシサーバ100の他の要素について説明する。
【0077】
タイマ122は、時刻を計時する機能を有している。OSは、タイマ122を用いて定期的にタイマーイベントを発生させ、そのタイマーイベントを契機にタイムアウト駆動部123が起動される。
【0078】
タイムアウト駆動部123は、起動されるとセッション情報テーブル121を走査し、タイムアウト予定時刻を過ぎたセッション情報をセッション情報テーブル121から削除する。
【0079】
ブラウザ入力受付部131は、Webブラウザ11aからの入力を受け付ける。ブラウザ入力受付部131は、受け付けた内容をプロキシサーバ認証部132、通信状態保持部134、およびWebサーバ識別部135に渡す。
【0080】
プロキシサーバ認証部132は、Webブラウザ11aからの入力がプロキシサーバへの認証情報を含むか否かを確認する。入力内容に、既に認証済みを示すプロキシサーバセッションID情報が含まれていた場合は、プロキシサーバ認証部132は、セッション情報テーブル121を確認し、有効な接続か否かを確認する。有効な接続だった場合、プロキシサーバ認証部132は、タイムアウト時間を延長するために、"タイムアウト予定時刻"を更新することもできる。
【0081】
また、入力情報にユーザ名とパスワード情報(AUTHORIZEDヘッダ内に含まれる)が含まれていた場合は、プロキシサーバ認証部132は、ユーザ情報テーブル111からプロキシサーバ認証用のユーザ名、パスワードと比較する。一致する場合は、プロキシサーバ認証部132は、セッション情報テーブル121にセッション情報を登録する。一致しない場合は、プロキシサーバ認証部132は、プロキシサーバ認証要求部133に対してプロキシサーバ認証を依頼する。
【0082】
プロキシサーバ認証部132は、Webブラウザ11aからの入力内容にプロキシサーバへの認証情報(セッションID、ユーザ名、パスワード)を含まない場合は、何もしない(認証情報を含まないことは許可される)。
【0083】
プロキシサーバ認証要求部133は、プロキシサーバ認証部132からの依頼に応じて、HTTPのUNAUTHORIZEDレスポンスを生成する。そして、プロキシサーバ認証要求部133は、生成したUNAUTHORIZEDレスポンスをユーザのWebブラウザ11aに返す。ここで、UNAUTHORIZEDレスポンスとは、Webブラウザ11aに対して認証情報の送信を要求する通信パケットである。
【0084】
通信状態保持部134は、後で使用するために、ブラウザから受けたHTTP要求(METHOD,URL,ヘッダ、POSTデータ)を保存する。
Webサーバ識別部135は、Webブラウザからの入力内容がプロキシ通信要求の場合、そのプロキシ通信要求に基づいて通信先のURLを識別する。なお、Webブラウザ11aから指定されるURLは仮想URLである。Webサーバ識別部135は、要求されたURLが含まれる情報をシステムテーブル112aから検索する。検索時にはシステムテーブル112aの仮想URLの項目を対象にする。要求されたURLが仮想URLに一致するか、あるいは仮想URLの配下に含まれる場合、そのシステムエントリを用いる。Webサーバ識別部135は、要求されたURLを含む仮想URLに対応する実URLをWebサーバ要求生成部136に渡す。
【0085】
以後の処理でプロキシサーバ100から実際のWebサーバ31a,32aへ通信がなされる場合は、仮想URLが実URLに変換される。なお、仮想URLと実URLは同じでもかまわない。
【0086】
なお、仮想URL、実URLともに物理的には同じ計算機であってもよい。本実施の形態では、サーバ機能がURL毎に管理されるため、一つの計算機を複数のシステムとして扱うことが許される。
【0087】
Webサーバ要求生成部136は、HTTP要求を生成する。その際、通信状態保持部134のデータを利用する。また、セッション情報テーブル121を確認し、プロキシサーバ100で認証済みの場合は、プロキシサーバ100のユーザ名等の認証情報を、HTTPのクッキーとして、WebサーバへのHTTP要求に付加する。そして、Webサーバ要求生成部136は、クッキーが付加されたHTTP要求をWebサーバ通信部137に渡す。
【0088】
また、Webサーバ要求生成部136は、レスポンス分析部138による応答内容の分析の結果、Webサーバ31a,32aに対するフォーム形式のログインが完了していたとき、応答内容を受け取る。すると、Webサーバ要求生成部136は、認証応答で得られたクッキー情報やセッション情報テーブル121から生成したプロキシサーバのユーザ名等の情報をHTTPクッキーに含める。そして、Webサーバ要求生成部136は、通信状態保持部134に保存されているユーザのWebブラウザからの要求を組み合わせ、Webサーバ通信部137からWebサーバ31a,32aに送信する。
【0089】
Webサーバ通信部137は、生成されたHTTP要求をシステムテーブル112aの実URLから生成した通信先に送る。また、Webサーバ通信部137は、Webサーバからの通信応答をレスポンス分析部138に渡す。
【0090】
レスポンス分析部138は、システムテーブル112aの認証タイプを元に処理を切り替える。また、レスポンス分析部138は、認証タイプが「null」の場合は、そのシステムにはアクセス制限は存在しないので、応答内容をコンテンツ変換部141に渡す。
【0091】
レスポンス分析部138の認証の結果、ログイン処理が成功しており、かつシステムテーブル112aの認証タイプがフォームだった場合、レスポンス分析部138は応答内容をWebサーバ要求生成部136に渡す。認証タイプがフォーム以外の場合、レスポンス分析部138はコンテンツ変換部141に応答内容を渡す。
【0092】
さらに、レスポンス分析部138は、認証タイプが「ベーシック」の場合はサーバ応答のHTTPヘッダを調べ、UNAUTHORIZEDか否かを確認する。レスポンス分析部138は、UNAUTHORIZEDの場合は認証処理判定部139へ応答内容を渡す。それ以外の場合は、レスポンス分析部138はコンテンツ変換部141に応答内容を渡す。
【0093】
認証タイプが「フォーム」の場合、レスポンス分析部138はレスポンス分析・ログイン命令テーブル112bを参照する。認証識別情報の項を用い、応答ヘッダ中のレスポンスコード、特定の識別ヘッダ、固有のコンテンツ識別内容データを比較する。これらが一致した場合は、レスポンス分析部138は該当するWebサーバから認証上の問題でアクセス拒否されたとみなし、認証処理判定部139に応答内容を渡す。それ以外は、レスポンス分析部138はコンテンツ変換部141に応答内容を渡す。
【0094】
認証処理判定部139はセッション情報テーブル121を調べ、現在の通信要求者がプロキシサーバへの認証を経ているか確認する。セッション情報テーブル121に当該ユーザ名が存在しない場合はプロキシサーバ認証要求部133に処理を移す。存在する場合はログイン処理命令生成部140に移る。
【0095】
ログイン処理命令生成部140は、システムテーブル112aの現在のシステムID(要求されたURLに対応するシステムID)と一致するユーザ名(通信要求を出したユーザのユーザ名)/パスワードの組をユーザ情報テーブル111から得る。また、ログイン処理命令生成部140は、システムテーブル112aを調べ、認証タイプによって処理を切り替える。
【0096】
認証タイプが「ベーシック」だった場合、ログイン処理命令生成部140は、先にユーザ情報テーブル111から得た、特定のWebサーバ向けのユーザ名/パスワードをHTTPのベーシック認証に対応した送信用データを生成する。
【0097】
認証タイプが"フォーム"だった場合、ログイン処理命令生成部140はレスポンス分析・ログイン命令テーブル112bのログイン処理情報の項の情報とユーザ情報テーブル111から得た、特定のWebサーバ向けのユーザ名/パスワードを組み合わせ、HTTPのフォーム通信のデータを生成する。
【0098】
ログイン処理命令生成部140は、ログイン処理用に生成した送信データをWebサーバ通信部137より該当するURLに送信する。Webサーバからの応答は上記と同様レスポンス分析部138で分析される。
【0099】
コンテンツ変換部141は、応答内容をレスポンス分析部138から受け取ったとき、その応答がコンテンツ書き換えの条件を満たす場合、Webサーバ31a,32aからの応答の内容(HTML文書)を書き換える。書き換えの際には、現在の利用者の情報をセッション情報テーブル121とユーザ情報テーブル111を使って、ユーザ毎に異なるHTML変換を実施する。
【0100】
ブラウザ応答生成部142は、コンテンツ変換部141より得たWebサーバからの応答に、セッション情報テーブル121から得た情報を元に生成したプロキシサーバ認証情報を含んだHTTPクッキーを組み合わせ、リモートWebブラウザに送信する。
【0101】
以上のような構成のシステムにおける処理をフローチャートを参照して説明する。
図9は、代理認証処理の手順を示す第1のフローチャートである。これは、Webブラウザ11aからWebサーバ31aにアクセスする場合の例である。以下、図9に示す処理をステップ番号に沿って説明する。
【0102】
[ステップS11]Webブラウザ11aは、ユーザからの操作入力によるWebサーバ31aへのアクセス指示を受け付ける。たとえば、表示画面からWebサーバ31aのURLが関連付けられたアンカー表示の選択入力(マウスによるクリック等)を受け付ける。
【0103】
[ステップS12]Webブラウザ11aは、プロキシサーバ100に対して、Webサーバ31aへのアクセス要求(ブラウザ要求)を送信する。
[ステップS13]プロキシサーバ100では、ブラウザ入力受付部131がブラウザ要求を受信する。
【0104】
[ステップS14]プロキシサーバ100において、指定されたURLに基づき、アクセス対象のWebサーバ31aに対応した認証許否確認論理とログイン処理論理(認証手続き)とを取得する。認証許否確認論理は、システムテーブル112aの認証タイプと、レスポンス分析・ログイン命令テーブル112bにおける認証識別情報とによって特定される。ログイン処理論理は、システムテーブル112aの認証タイプと、レスポンス分析・ログイン命令テーブル112bのログイン処理情報とによって特定される。
【0105】
[ステップS15]プロキシサーバ100は、アクセス要求内のセッションを特定するクッキーの有無を確認する。そして、プロキシサーバ100は、クッキーが有る場合、該当するセッションがセッション情報テーブル121に登録されているか否かを判断する。該当するセッションが有る場合、処理がステップS16に進められる。該当するセッションが無い場合、処理がステップS17に進められる。
【0106】
[ステップS16]プロキシサーバ100は、セッション情報テーブル121内の該当するセッションの情報からユーザ名を取得する。その後、処理がステップS31(図10参照)に進められる。
【0107】
[ステップS17]プロキシサーバ100は、受信したアクセス要求にAuthorizedヘッダが含まれるか否かを判断する。Authorizedヘッダは、Webブラウザ11aがユーザ認証情報を送信するために付加する情報である。Webブラウザ11aは、プロキシ認証レスポンスを受け取ったときに、プロキシサーバ100へのユーザ認証情報(ユーザ名とパスワード)をAuthorizedヘッダに含めて、アクセス要求をプロキシサーバ100に送信するように設計されている。Authorizedヘッダが含まれる場合には、処理がステップS18に進められる。Authorizedヘッダが含まれない場合には、処理がステップS31(図10参照)に進められる。
【0108】
[ステップS18]プロキシサーバ100は、アクセス要求からAuthorizedヘッダからユーザ名/パスワード取得を取得する。
[ステップS19]プロキシサーバ100は、ユーザ情報テーブル111を参照し、ユーザ情報を取得する。具体的には、プロキシサーバ100は、Authorizedヘッダに含まれていたユーザ名を、ユーザ情報テーブル111のプロキシサーバ認証情報のユーザ名の欄から検索する。そして、プロキシサーバ100は、該当するユーザ名に対応付けられたパスワードを取得する。
【0109】
[ステップS20]プロキシサーバ100は、認証が成功したか否かを判断する。具体的には、プロキシサーバ100は、Authorizedヘッダに含まれていたユーザ認証情報と一致するプロキシサーバ認証情報がユーザ情報テーブル111に登録されていれば、認証成功と判断する。該当するユーザ名がユーザ情報テーブル111に登録されていないか、該当するユーザ名のパスワードが異なっている場合には、認証失敗と判断する。認証が成功した場合、処理がステップS22に進められる。認証失敗の場合、処理がステップS21に進められる。
【0110】
[ステップS21]認証に失敗した場合、プロキシサーバ100は、プロキシ認証レスポンスを生成し、Webブラウザ11aに返信する。プロキシ認証レスポンスとは、プロキシサーバへのユーザ認証手続きを要求するパケットである。その後、処理が終了し、Webブラウザ11aからの要求を待つ。
【0111】
[ステップS22]認証に成功した場合、プロキシサーバ100は、セッションを生成する。生成したセッションには、ユニークなセッションIDが付与される。
【0112】
[ステップS23]プロキシサーバ100は、生成したセッションにユーザ情報を登録する。具体的には、プロキシサーバ100は、生成したセッションに付与されたセッションIDに対し、ユーザ名、ログイン時刻、およびタイムアウト予定時刻を関連付けて、セッション情報テーブル121に登録する。ログイン時刻は、セッションの生成時刻である。タイムアウト予定時刻は、たとえば、セッション生成から所定の時間後の時刻を設定する。
【0113】
図10は、代理認証処理の手順を示す第2のフローチャートである。以下、図10に示す処理をステップ番号に沿って説明する。
[ステップS31]プロキシサーバ100は、ブラウザからのアクセス要求を受け取り、内部に保存する。
【0114】
[ステップS32]プロキシサーバ100は、Webサーバ31aのURL(実URL)を取得し、Webサーバへのアクセス要求を生成する。生成されたアクセス要求は、プロキシサーバ100によってWebサーバ31aに送信される。
【0115】
[ステップS33]プロキシサーバ100は、Webサーバ31aからの応答を受信する。
[ステップS34]プロキシサーバ100は、応答内容を解析し、Webサーバ31aによる処理結果を判定する。具体的には、プロキシサーバ100は、システムテーブル112aを参照し、Webサーバ31aの認証タイプを判断する。たとえば、プロキシサーバ100は、認証タイプがベーシックであり、Webサーバ31aからの応答のHTTPヘッダがUNAUTHORIZEDであれば、ベーシック認証の手続きが必要であると判断する。また、プロキシサーバ100は、認証タイプがフォームの場合、レスポンス分析・ログイン命令テーブル112bを参照し、応答内容が該当するシステムIDに対応する認証識別情報に合致する場合には、フォーム認証の手続きが必要であるものと判断する。
【0116】
[ステップS35]プロキシサーバ100は、アクセスが許可されたか否かを判断する。すなわち、ベーシックやフォームの認証手続きを必要と判断するための条件のいずれにも該当しなければ、アクセスが許可されたものと判断される。アクセスが許可された場合、処理がステップS61(図12参照)に進められる。アクセスが許否された場合、処理がステップS41(図11参照)に進められる。
【0117】
図11は、代理認証処理の手順を示す第3のフローチャートである。以下、図11に示す処理をステップ番号に沿って説明する。
[ステップS41]プロキシサーバ100は、Webサーバ31aへのアクセスが拒否された場合、セッション情報テーブル121を参照し、Webブラウザ11aを介してアクセス要求を出したユーザのユーザ名に対応するセッションの有無を判断する。セッションがない場合、処理がステップS42に進められる。セッションがある場合、処理がステップS44に進められる。
【0118】
[ステップS42]セッションがない場合、プロキシサーバ認証要求部133が、Webサーバ31aから受信したクッキーをWebブラウザ11aのプロキシ認証レスポンス(応答内容)に設定する。
【0119】
[ステップS43]プロキシサーバ100は、プロキシ認証レスポンスを生成し、Webブラウザ11aに返信する。その後、処理が終了する。
[ステップS44]セッションがある場合、プロキシサーバ100へのユーザ認証が完了しているため、プロキシサーバ100は、セッション情報テーブル121からユーザ情報(ユーザ名等)を取得する。
【0120】
[ステップS45]プロキシサーバ100は、ユーザ情報テーブル111からWebサーバ31aにログインするためのユーザ認証情報を取得する。具体的には、プロキシサーバ100は、ステップS44で取得したユーザ名に対応付けて設定されているWebブラウザ31a(システムIDで判別する)のユーザ名とパスワードとを取得する。
【0121】
[ステップS46]プロキシサーバ100は、ログインリクエストを生成する。
[ステップS47]プロキシサーバ100は、システムテーブル112aを参照し、ベーシック認証か否かを判断する。ベーシック認証の場合、処理がステップS48に進められる。ベーシック認証ではない場合、処理がステップS49に進められる。
【0122】
[ステップS48]プロキシサーバ100は、保存してあるブラウザ要求を取り出し、ログインリクエストに組み合わせる。
[ステップS49]プロキシサーバ100は、Webサーバ31aへ要求(ログインリクエスト)を送信する。
【0123】
[ステップS50]プロキシサーバ100は、Webサーバ31aから応答された処理結果を受信する。
[ステップS51]プロキシサーバ100は、処理結果の内容を解析し、ログインに成功したか否かを判断する。ログインに成功した場合には、処理がステップS54に進められる。ログインに失敗した場合には、処理がステップS52に進められる。
【0124】
[ステップS52]ログインに失敗した場合、プロキシサーバ100は、エラーメッセージを生成する。
[ステップS53]プロキシサーバ100は、エラーメッセージを含む例外を発生させ、処理を終了する。
【0125】
[ステップS54]プロキシサーバ100は、成功したログイン処理がベーシック認証か否かを判断する。ベーシック認証の場合、処理がステップS31(図10参照)に進められる。ベーシック認証では無い場合、処理がステップS55に進められる。
【0126】
[ステップS55]プロキシサーバ100は、通信状態保持部134から保存済のブラウザからの要求を取り出す。その後、処理がステップS31(図10参照)に進められる。
【0127】
次に、ステップS35においてアクセスが許可されたと判断されたときの処理について説明する。
図12は、代理認証処理の手順を示す第4のフローチャートである。以下、図12に示す処理をステップ番号に沿って説明する。
【0128】
[ステップS61]プロキシサーバ100は、Webサーバ31aからの応答が書き換え対象か否かを、Webサーバ31aのURLから判断する。書き換え対象の場合、処理がステップS62に進められる。書き換え対処ではない場合、処理がステップS63に進められる。
【0129】
[ステップS62]プロキシサーバ100は、コンテンツの書き換えを行う。書き換え方法は、たとえば、URLに対応付けて予め定義されている。
[ステップS63]プロキシサーバ100は、書き換えたコンテンツをブラウザレスポンスとして設定する。
【0130】
[ステップS64]プロキシサーバ100は、Webサーバ31aからのレスポンスヘッダをブラウザレスポンスに設定する。
[ステップS65]プロキシサーバ100は、送信相手のWebブラウザに対応するセッションがあるか否かを判断する。セッションがあれば、処理がステップS66に進められる。セッションがなければ、処理がステップS67に進められる。
【0131】
[ステップS66]プロキシサーバ100は、プロキシのセッションIDを応答クッキーに埋め込む。
[ステップS67]プロキシサーバ100は、Webブラウザ11aに対して応答を送信する。
【0132】
[ステップS68]Webブラウザ11aは、アクセスの結果を表示する。
以上のようにして、プロキシサーバ100において代理認証が行われる。
次に、Webブラウザ11aによりプロキシサーバ100にログインし、Webサーバ31a等にアクセスする際の流れを具体的に説明する。以下の例では、Webサーバでベーシック認証を行う場合と、フォーム認証を行う場合とについて説明する。また、Webサーバ31aの名称を「WebサーバA」、Webサーバ32aの名称を「WebサーバB」とする。
【0133】
図13は、Webサーバでベーシック認証を行う場合の処理手順を示す第1のシーケンス図である。図13は、プロキシサーバ100にログインしていないWebブラウザ11aからの要求に対して、プロキシ認証レスポンスを返すまでの処理である。以下、図13に示す処理をステップ番号に沿って説明する。
【0134】
[ステップS71]Webブラウザ11aは、プロキシサーバ100に対する最初の要求を送信する。この例では、GET要求「GET(URL_X)」を送信している。
【0135】
[ステップS72]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。最初の要求では、Authorizedヘッダは含まれていない。Authorizedヘッダが無い場合、認証不要のリクエストであると仮定して処理が進められる。
【0136】
[ステップS73]プロキシサーバ100は、Webサーバ31aに要求を送信する。この例では、GET要求「GET(URL_X)」を送信している。
[ステップS74]Webサーバ31aは、プロキシサーバに対して応答「401(Unauthorized,WWW-Authenticate)」を返す。この例では、レスポンスコードが401の応答が返されている。この応答は、ベーシック認証が未完了であるためにアクセスを拒否したことを示している。
【0137】
[ステップS75]プロキシサーバ100は、レスポンスを解析する。
[ステップS76]プロキシサーバ100は、セッションの有無を確認する(ここで、プロキシサーバ100とWebブラウザ11aとの間のセッションをPPSセッションとする)。この段階では、Webブラウザ11aからプロキシサーバ100にログインされていないため、セッションも存在していない。
【0138】
この例では、レスポンスコードが401であり(ログインを要求するレスポンス)、かつPPSセッションが存在しない場合、プロキシサーバ100へログイン処理が開始される。
【0139】
[ステップS77]プロキシサーバ100は、プロキシ認証レスポンス「Unauthorized,WWW-Authenticate」をWebブラウザ11aに送信する。
図14は、Webサーバでベーシック認証を行う場合の処理手順を示す第2のシーケンス図である。図14は、Webブラウザ11aからプロキシサーバ100にログインし、Webページを取得するまでの処理である。以下、図14に示す処理をステップ番号に沿って説明する。
【0140】
[ステップS81]Webブラウザ11aは、ユーザからのユーザ名とパスワードとの入力を受け付ける。
[ステップS82]Webブラウザ11aは、Authorizedヘッダにユーザ認証情報を含めた要求「GET(URL_X, Authorization/PPS)」を、プロキシサーバ100に送信する。
【0141】
[ステップS83]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダありと判断される。
[ステップS84]プロキシサーバ100は、セッション(PPSセッション)の有無を確認する。この時点では、セッションは存在しない。Authorizedヘッダがあってもセッションが存在しない場合、未認証であると判断される。
【0142】
なお、ステップS83とステップS84との処理は、順番が逆であってもよい。図9に示すフローチャートでは、セッションの確認(ステップS15)の後、Authorizedヘッダを確認(ステップS16)している。
【0143】
[ステップS85]プロキシサーバ100は、ユーザ名とパスワードとの組を照合(マッチング)する。照合が成功した場合、以下の処理が行われる。
[ステップS86]プロキシサーバ100は、セッションを生成する。
【0144】
[ステップS87]プロキシサーバ100は、Webサーバ31a(SubSystem)用のユーザ認証情報(認証キー)を取得する。
[ステップS88]プロキシサーバ100は、Webサーバ31a用のAuthorizedヘッダを生成する。
【0145】
[ステップS89]プロキシサーバ100は、Webブラウザ11aから送られた要求からクッキー(PPSCookie)やプロキシサーバ100へ認証するためのユーザ認証情報を取り除き、Webサーバ31a用のユーザ認証情報を追加した要求「GET(URL_X,Authorization/Sub)」を、Webサーバ31aに送信する。
【0146】
[ステップS90]Webサーバ31aは、ユーザ認証情報に基づいてユーザ認証を行う。Webサーバ31aは、認証に成功すると、指定されたWebページ(URL_Xのページ)をプロキシサーバ100に送信する。なお、この送信のパケットのレスポンスコードは「200」である。
【0147】
[ステップS91]プロキシサーバ100は、Webサーバ31aからの応答(レスポンス)を解析する。
[ステップS92]プロキシサーバ100は、Webサーバ31aから送られたWebページにプロキシサーバ100用のクッキー(PPSSCookie)を追加してWebブラウザ11aに送信する。このクッキーでは、プロキシサーバ100のドメイン名と後方一致するURLへのアクセスの際に有効となるように設定されている。
【0148】
[ステップS93]Webブラウザ11aは、受け取ったWebページを表示すると共に、プロキシサーバ100から送られたクッキーを保存する。
以上のようにして、Webブラウザ11aを使用するユーザは、プロキシサーバ100へログインするだけで、Webサーバ31aへのアクセスが可能となる。
【0149】
次に、引き続き同じWebサーバ31aにアクセスする際の処理手順を説明する。
図15は、ベーシック認証を完了したWebサーバへのアクセス手順を示すシーケンス図である。以下、図15に示す処理をステップ番号に沿って説明する。
【0150】
[ステップS101]Webブラウザ11aは、ユーザの操作入力に応答してWebページ(URL_Y)の取得要求「GET(URL_Y,PPSCookie,Authorization/PPS)」をプロキシサーバ100に送信する。この要求には、ステップS92(図14参照)で保存したクッキーやプロキシサーバ100へログインするためのユーザ認証情報が含まれる。
【0151】
[ステップS102]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダありと判断される。
[ステップS103]プロキシサーバ100は、セッション(PPSセッション)の有無を確認する。この例ではすでにセッションが存在するため、認証済と判断され、以下の処理が行われる。
【0152】
[ステップS104]プロキシサーバ100は、Webサーバ31a(SubSystem)用のユーザ認証情報(認証キー)を取得する。
[ステップS105]プロキシサーバ100は、Webサーバ31a用のAuthorizedヘッダを生成する。
【0153】
[ステップS106]プロキシサーバ100は、Webブラウザ11aから送られた要求からクッキー(PPSCookie)やプロキシサーバ100へ認証するためのユーザ認証情報を取り除き、Webサーバ31a用のユーザ認証情報を追加した要求「GET(URL_Y,Authorization/a:Sub)」を生成する。そして、生成した要求をWebサーバ31aに送信する。
【0154】
[ステップS107]Webサーバ31aは、指定されたWebページ(URL_Yのページ)をプロキシサーバ100に送信する。
[ステップS108]プロキシサーバ100は、Webサーバ31aからの応答(レスポンス)を解析する。アクセスが拒否されていないので、以下の処理に進める。
【0155】
[ステップS109]プロキシサーバ100は、Webサーバ31aから送られたWebページにプロキシサーバ100用のクッキー(PPSSCookie)を追加してWebブラウザ11aに送信する。
【0156】
次に、プロキシサーバ100へのログイン完了後に、新たなWebサーバにアクセスする場合の例を説明する
図16は、ベーシック認証を必要とする新たなWebサーバへのアクセス手順を示すシーケンス図である。以下、図16に示す処理をステップ番号に沿って説明する。
【0157】
[ステップS111]Webブラウザ11aは、ユーザの操作入力に応答してWebページ(URL_x)の取得要求「GET(URL_x,PPSCookie)」をプロキシサーバ100に送信する。この要求には、ステップS92(図14参照)で保存したクッキーが含まれる。なお、以前と異なるWebサーバ32aへの要求なので、Authorizedヘッダは送られない。また、送信アドレスが仮想アドレスであるため、プロキシサーバ100用のクッキーの適用範囲内であると判断され、そのクッキーが要求に含められている。
【0158】
[ステップS112]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダなしと判断され、認証不要な要求と仮定して以降の処理が進められる。
【0159】
[ステップS113]プロキシサーバ100は、Webサーバ32aに対して、要求を転送する。この要求では、プロキシサーバ100用のクッキーは取り除かれている。
【0160】
[ステップS114]Webサーバ32aは、ユーザ認証を要求する応答をプロキシサーバ100に返す。この応答のレスポンスコードは「401」である。
[ステップS115]プロキシサーバ100は、応答を解析し、ユーザ認証が要求されていることを認識する。具体的には、レスポンスコードが「401」であることを検出し、ベーシック認証が要求されていることを認識する。
【0161】
[ステップS116]プロキシサーバ100は、セッションの有無を確認する。この例では、既にセッションが存在するため、Webブラウザ11aへのユーザ認証用のダイアログ等の表示を行わず、以下のような自動認証処理を行う。
【0162】
[ステップS117]プロキシサーバ100は、Webサーバ32a用のユーザ認証情報を取得する。
[ステップS118]プロキシサーバ100は、Webサーバ32a用のAuthorizedヘッダを生成する。
【0163】
[ステップS119]プロキシサーバ100は、Webブラウザ11aから送られた要求からクッキー(PPSCookie)やプロキシサーバ100へ認証するためのユーザ認証情報を取り除き、Webサーバ32a用のユーザ認証情報を追加した要求「GET(URL_x,Authorization/b:SUB)」を、Webサーバ32aに送信する。
【0164】
[ステップS120]Webサーバ32aは、ユーザ認証情報に基づいてユーザ認証を行う。Webサーバは、認証に成功すると、指定されたWebページ(URL_xのページ)をプロキシサーバ100に送信する。
【0165】
[ステップS121]プロキシサーバ100は、Webサーバからの応答(レスポンス)を解析する。アクセスが拒否されていないので、以下の処理に進める。
【0166】
[ステップS122]プロキシサーバ100は、Webサーバ32aから送られたWebページをWebブラウザ11aに送信する。
このように、既にプロキシサーバ100にログインしていれば、新たなWebサーバ32aにアクセスする場合であってもユーザ認証情報の入力は不要となる。
【0167】
次に、フォーム認証を行う際の手順を説明する。
図17は、Webサーバでフォーム認証を行う場合の処理手順を示す第1のシーケンス図である。図17は、プロキシサーバ100にログインしていないWebブラウザ11aからの要求に対して、プロキシ認証レスポンスを返すまでの処理である。以下、図17に示す処理をステップ番号に沿って説明する。
【0168】
[ステップS131]Webブラウザ11aは、プロキシサーバ100に対する最初の要求を送信する。この例では、GET要求「GET(URL_X)」を送信している。
【0169】
[ステップS132]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。最初の要求では、Authorizedヘッダは含まれていない。Authorizedヘッダが無い場合、認証不要のリクエストであると仮定して処理が進められる。
【0170】
[ステップS133]プロキシサーバ100は、Webサーバ31aにする要求を送信する。この例では、GET要求「GET(URL_X)」を送信している。
[ステップS134]Webサーバ31aは、プロキシサーバに対して応答を返す。この例では、要求拒否の応答(NGレスポンス(SSSCookie))が返されている。要求拒否の応答には、クッキー(SSSCookie)が含まれる。この応答は、フォーム認証が未完了であるためにアクセスを拒否したことを示している。
【0171】
[ステップS135]プロキシサーバ100は、レスポンスを解析する。
[ステップS136]プロキシサーバ100は、セッションの有無を確認する(ここで、プロキシサーバ100とWebブラウザ11aとの間のセッションをPPSセッションとする)。この段階では、Webブラウザ11aからプロキシサーバ100にログインされていないため、セッションも存在していない。
【0172】
この例では、要求拒否の応答が返され、かつPPSセッションが存在しない場合、プロキシサーバ100へログイン処理が開始される。
[ステップS137]プロキシサーバ100は、プロキシ認証レスポンス「Unauthorized,WWW-Authenticate」をWebブラウザ11aに送信する。
【0173】
図18は、Webサーバでフォーム認証を行う場合の処理手順を示す第2のシーケンス図である。図18は、Webブラウザ11aからプロキシサーバ100にログインし、Webページを取得するまでの処理である。以下、図18に示す処理をステップ番号に沿って説明する。
【0174】
[ステップS141]Webブラウザ11aは、ユーザからのユーザ名とパスワードとの入力を受け付ける。
[ステップS142]Webブラウザ11aは、Authorizedヘッダにユーザ認証情報を含めた要求「GET(URL_X, Authorization/PPS)」を、プロキシサーバ100に送信する。
【0175】
[ステップS143]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダありと判断される。
[ステップS144]プロキシサーバ100は、セッション(PPSセッション)の有無を確認する。この時点では、セッションは存在しない。Authorizedヘッダがあってもセッションが存在しない場合、未認証であると判断される。
【0176】
なお、ステップS143とステップS144との処理は、順番が逆であってもよい。図9に示すフローチャートでは、セッションの確認(ステップS15)の後、Authorizedヘッダを確認(ステップS16)している。
【0177】
[ステップS145]プロキシサーバ100は、ユーザ名とパスワードとの組を照合(マッチング)する。照合が成功した場合、以下の処理が行われる。
[ステップS146]プロキシサーバ100は、セッションを生成する。
【0178】
[ステップS147]プロキシサーバ100は、Webサーバ31a(SubSystem)用のユーザ認証情報(認証キー)を取得する。
[ステップS148]プロキシサーバ100は、Webサーバ31aに対してログイン要求「POST(URL_Login, User,Pass, SSSCookie)」を送信する。このログイン要求には、ユーザ認証情報(User,Pass)やクッキー(SSSCookie)が含まれる。
【0179】
[ステップS149]Webサーバ31aは、ユーザ認証情報に基づいてユーザ認証を行う。Webサーバ31aは、認証に成功すると、認証後に送信すべきものとして予め設定されているWebページをプロキシサーバ100に送信する。なお、この送信のパケットのレスポンスコードは「200」である。
【0180】
[ステップS150]プロキシサーバ100は、Webサーバ31aからの応答(レスポンス)を解析する。これにより、Webサーバ31aに対するログインが成功したことが認識される。
【0181】
「ステップS151]プロキシサーバ100は、最初にWebブラウザ11aから送られた要求にWebサーバ31a用のクッキー(SSSCookie)を追加して新たな要求「GET(URL_X, SSSCookie)」を生成し、Webサーバ31aに対して送信する。
【0182】
[ステップS152]Webサーバ31aは、クッキー(SSSCookie)により、既に認証しているユーザからのアクセスであると認識し、要求されたWebページをプロキシサーバ100に送信する。
【0183】
[ステップS153]プロキシサーバ100は、Webサーバ31aからの応答(レスポンス)を解析する。
[ステップS154]プロキシサーバ100は、Webサーバ31aから送られたWebページにWebサーバ31a用のクッキー(SSSCookie)とプロキシサーバ100用のクッキー(PPSSCookie)とを追加してWebブラウザ11aに送信する。プロキシサーバ100用のクッキーでは、プロキシサーバ100のドメイン名と後方一致するURLへのアクセスの際に有効となるように設定されている。
【0184】
[ステップS155]Webブラウザ11aは、受け取ったWebページを表示すると共に、プロキシサーバ100から送られたクッキーを保存する。
以上のようにして、Webブラウザ11aを使用するユーザは、プロキシサーバ100へログインするだけで、Webサーバ31aへのアクセスが可能となる。
【0185】
次に、引き続き同じWebサーバ31aにアクセスする際の処理手順を説明する。
図19は、フォーム認証を完了したWebサーバへのアクセス手順を示すシーケンス図である。以下、図19に示す処理をステップ番号に沿って説明する。
【0186】
[ステップS161]Webブラウザ11aは、ユーザの操作入力に応答してWebページ(URL_Y)の取得要求「GET(URL_Y,PPSCookie,Authorization/PPS)」をプロキシサーバ100に送信する。この要求には、ステップS155(図18参照)で保存したクッキーやプロキシサーバ100へログインするためのユーザ認証情報が含まれる。
【0187】
[ステップS162]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダありと判断される。
[ステップS163]プロキシサーバ100は、セッション(PPSセッション)の有無を確認する。この例ではすでにセッションが存在するため、認証済と判断され、以下の処理が行われる。
【0188】
[ステップS164]プロキシサーバ100は、Webブラウザ11aから送られた要求にWebサーバ31a用のユーザ認証情報を追加した要求「GET(URL_Y,SSSCookie)」を生成し、Webサーバ31aに送信する。
【0189】
[ステップS165]Webサーバ31aは、指定されたWebページ(URL_Yのページ)をプロキシサーバ100に送信する。
[ステップS166]プロキシサーバ100は、Webサーバ31aからの応答(レスポンス)を解析する。アクセスが拒否されていないので、以下の処理に進める。
【0190】
[ステップS167]プロキシサーバ100は、Webサーバ31aから送られたWebページをWebブラウザ11aに送信する。
次に、プロキシサーバ100へのログイン完了後に、新たなWebサーバにアクセスする場合の例を説明する。
【0191】
図20は、フォーム認証を必要とする新たなWebサーバへのアクセス手順を示すシーケンス図である。以下、図20に示す処理をステップ番号に沿って説明する。
【0192】
[ステップS171]Webブラウザ11aは、ユーザの操作入力に応答してWebページ(URL_x)の取得要求「GET(URL_x,PPSSCookie)」をプロキシサーバ100に送信する。この要求には、ステップS155(図18参照)で保存したクッキーが含まれる。なお、以前と異なるWebサーバ32aへの要求なので、Authorizedヘッダは送られない。また、送信アドレスが仮想アドレスであるため、プロキシサーバ100用のクッキーの適用範囲内であると判断され、そのクッキーが要求に含められている。
【0193】
[ステップS172]プロキシサーバ100では、Authorization(Authorizedヘッダ)の確認が行われる。このとき、Authorizedヘッダなしと判断され、認証不要な要求と仮定して以降の処理が進められる。
【0194】
[ステップS173]プロキシサーバ100は、Webサーバ32aに対して、要求を転送する。この要求では、プロキシサーバ100用のクッキーは取り除かれている。
【0195】
[ステップS174]Webサーバ32aは、ユーザ認証を要求する応答をプロキシサーバ100に返す。この例では、要求拒否の応答(NGレスポンス(SSSCookie))が返されている。要求拒否の応答には、クッキー(SSSCookie)が含まれる。この応答は、フォーム認証が未完了であるためにアクセスを拒否したことを示している。
【0196】
[ステップS175]プロキシサーバ100は、応答を解析し、ユーザ認証が要求されていることを認識する。
[ステップS176]プロキシサーバ100は、セッションの有無を確認する。この例では、既にセッションが存在するため、Webブラウザ11aへのユーザ認証用のダイアログ等の表示を行わず、以下のような自動認証処理を行う。
【0197】
[ステップS177]プロキシサーバ100は、Webサーバ32a(SubSystem)用のユーザ認証情報(認証キー)を取得する。
[ステップS178]プロキシサーバ100は、Webサーバ32aに対してログイン要求「POST(URL_Login,SSSCookie)」を送信する。このログイン要求には、クッキー(SSSCookie)が含まれる。
【0198】
[ステップS179]Webサーバ32aは、ユーザ認証情報に基づいてユーザ認証を行う。Webサーバ32aは、認証に成功すると、認証後に送信すべきものとして予め設定されているWebページをプロキシサーバ100に送信する。なお、この送信のパケットのレスポンスコードは「200」である。
【0199】
[ステップS180]プロキシサーバ100は、Webサーバ32aからの応答(レスポンス)を解析する。これにより、Webサーバ32aに対するログインが成功したことが認識される。
【0200】
[ステップS181]プロキシサーバ100は、最初にWebブラウザ11aから送られた要求にWebサーバ32a用のクッキー(SSSCookie)を追加して新たな要求「GET(URL_x,SSSCookie)」を生成し、Webサーバ32aに対して送信する。
【0201】
[ステップS182]Webサーバ32aは、クッキー(SSSCookie)により、既に認証しているユーザからのアクセスであると認識し、要求されたWebページをプロキシサーバ100に送信する。
【0202】
[ステップS183]プロキシサーバ100は、Webサーバ32aからの応答(レスポンス)を解析する。
[ステップS184]プロキシサーバ100は、Webサーバ32aから送られたWebページにWebサーバ32a用のクッキー(SSSCookie)を追加してWebブラウザ11aに送信する。
【0203】
[ステップS185]Webブラウザ11aは、受け取ったWebページを表示すると共に、プロキシサーバ100から送られたクッキーを保存する。
以上のように、ベーシック認証、フォーム認証等の認証方式に合わせて、代理認証を行うことができる。しかも、認証手順は予め定義されており、各Webサーバに対するユーザ毎のユーザ認証情報を保持しておくだけでよい。
【0204】
なお、ベーシック認証の認証手順とフォーム認証の認証手順とは、上記の手順で表された相違点以外に、送信データの生成方法も異なる。そこで、以下に、ログイン処理命令生成部140による認証方式毎の送信データ生成方法について説明する。
【0205】
図21は、ベーシック認証時の送信データ生成手順を示すフローチャートである。以下、図21に示す処理をステップ番号に沿って説明する。
[ステップS201]ログイン処理命令生成部140は、ユーザ名とパスワードとの文字列の間に‘:’をいれて、それぞれを連結する。
【0206】
[ステップS202]ログイン処理命令生成部140は、連結した文字列を所定のアルゴリズムでエンコードする。たとえば、Base64と呼ばれるアルゴリズムでエンコードする。
【0207】
[ステップS203]ログイン処理命令生成部140は、エンコードされた認証文字列の前に“Basic”という文字列を挿入する。
[ステップS204]ログイン処理命令生成部140は、生成した文字列をヘッダ名「AUTHORIZATION」と連結し、認証ヘッダを生成する。
【0208】
[ステップS205]ログイン処理命令生成部140は、通信状態保持部134からURL、ヘッダ、ボディ情報を引き出す。
[ステップS206]ログイン処理命令生成部140は、ヘッダ部に認証ヘッダを挿入する。
【0209】
[ステップS207]ログイン処理命令生成部140は、Webサーバにヘッダを送信する。
[ステップS208]ログイン処理命令生成部140は、Webサーバにボディ情報を送信する。
【0210】
図22は、フォーム認証時の送信データ生成手順を示すフローチャートである。以下、図22に示す処理をステップ番号に沿って説明する。
[ステップS211]ログイン処理命令生成部140は、ユーザフォーム名とユーザ名とをフォームデータ生成情報保持テーブル140aに登録する。
【0211】
ここで、フォームデータ生成情報保持テーブル140aは、ログイン処理命令生成部140が保持するデータテーブルであり、フォーム名(ユーザフォーム名やパスワードフォーム名)と登録情報(ユーザ名やパスワード文字列)との組を登録することができる。
【0212】
[ステップS212]ログイン処理命令生成部140は、パスワードフォーム名とパスワード文字列との組を、フォームデータ生成情報保持テーブル140aに登録する。
【0213】
[ステップS213]ログイン処理命令生成部140は、ステップS211とステップS212とで登録した各々の文字列を、URLエンコードルールに従って変換する。
【0214】
[ステップS214]ログイン処理命令生成部140は、変換した文字列の間に‘&’を挿入して連結する。
[ステップS215]ログイン処理命令生成部140は、通信状態保持部134からクッキー情報を取得する。
【0215】
[ステップS216]ログイン処理命令生成部140は、Webサーバに“Content-Type:application/x-www-form-urlencoded”ヘッダを送信する。
[ステップS217]ログイン処理命令生成部140は、Webサーバにクッキーヘッダを送信する。
【0216】
[ステップS218]ログイン処理命令生成部140は、Webサーバに認証フォームデータを送信する。
以上説明したように、プロキシサーバ100が代理認証を行うことで、ユーザは、Webサーバ毎にログイン手続きを行う必要が無くなり、利便性が向上する。
【0217】
なお、上記の例では、プロキシサーバが代理認証を行っているが、この機能をクライアントに実装することもできる。
図23は、代理認証機能を実装したクライアントの概念図である。図23に示すように、クライアント200にはブラウザプログラム210とプロキシプログラム220とが実装される。ブラウザプログラム210は、Webブラウザとしてクライアント200を機能させるためのプログラムである。また、プロキシプログラム220は、プロキシサーバ100の機能をクライアント200で実現するためのプログラムである。プロキシプログラム220は、ユーザ情報テーブル221を有している。ユーザ情報テーブル221、各サーバ31,32,33に実装されたWebサーバにログインするためのユーザ認証情報(ユーザ名とパスワード)が登録されている。
【0218】
なお、プロキシプログラム220は、クライアント200のユーザの代理認証を行えばよい。そのため、クライアント200のOSへ正しくログインしたユーザに対しては、プロキシプログラム220においてユーザ認証を行わなくてもよい。
【0219】
以上説明したように、本発明の実施の形態によれば、複数の認証を要するWebシステムを利用する際に、ユーザがログインを行う数が1回ですむ。
しかも、従来のシングルサインオンシステムとは異なり、認証を要しないWebページを使用する場合には、ユーザのログイン操作は0回になる。すなわち、従来のシングルサインオン技術では、予め代理認証システムにログインすることが前提となり、かならず1回のユーザ認証処理が発生する。ところが、本実施の形態によれば、Webサーバでのユーザ認証の要否をプロキシサーバが判断し、ユーザ認証を要求しないWebサーバへのアクセスで有ればプロキシサーバへのログインを要求しない。その結果、ユーザの操作性が向上する。
【0220】
また、本実施の形態では、WebサーバのURL毎にユーザ認証情報を管理しているため、同一サーバコンピュータ内に複数のWebサーバが実装されていたときでも、Webサーバ毎の代理認証が可能である。
【0221】
また、従来の代理認証技術には、認証通信を完全に記録しそのまま再現するタイプのものがある。この技術では、冗長な記憶領域を必要とした。一方、本実施の形態の方式では認証用の通信データをプログラムの計算処理によって生成するため、ユーザが増加した場合も記憶容量の増加はごく僅かである。
【0222】
また、本実施の形態ではWebサーバ側でセッションのタイムアウト発生によりそのセッションが停止しても、次回の該当するWebサーバへのアクセスの際に自動的にログインされセッションが再度確立することができる。そのため、Webサーバでのセッションのタイムアウトをユーザが意識せずにすむ。
【0223】
また、従来のシングルサインオンでは、シングルサインオンを実現するためのサーバが必要であり個人での運用・利用は困難だった。本実施の形態では、プロキシサーバの機能を用意にクライアントに実装することができ(図23参照)、クライアント上でのシングルサインオンが実現可能となる。
【0224】
なお、既存のWebブラウザにはユーザの入力したユーザ名やパスワードを記憶し、パスワード入力の手間を削減する機構が存在する。しかし、この機能は個々のブラウザ毎に異なり、複数のブラウザを利用するユーザはユーザ名やパスワードのデータを共用できない。図23に示すような単一ユーザ形態であれば、複数のブラウザで統一されたシングルサインオンを実現できる。
【0225】
ところで、上記の例では、Webサーバにアクセスする場合の例を用いて説明しているが、ネットワーク経由のユーザ認証を要求する他のアプリケーションに対しても同様の処理で代理認証を行うことができる。
【0226】
また、上記の例では、Webサーバがベーシック認証またはフォーム認証を要求する場合の例を示したが、他の認証方式に適用することもできる。その場合、適用すべき認証方式の判別基準をレスポンス分析・ログイン命令テーブル112bに設定するとともに、該当する認証方式への認証手順を定義しておく。ログイン処理命令生成部140は、定義された手順で代理認証の処理を実行する。
【0227】
なお、上記のプロキシサーバ100や代理認証装置1の処理機能は、サーバコンピュータに所定の代理認証プログラムを実行させることにより実現することができる。その場合、プロキシサーバ100等が有すべき機能の処理内容を記述した代理認証プログラムが提供される。サーバコンピュータは、クライアントコンピュータからの要求に応答して、代理認証プログラムを実行する。これにより、上記処理機能がサーバコンピュータ上で実現され、処理結果がクライアントコンピュータに提供される。
【0228】
処理内容を記述した代理認証プログラムは、サーバコンピュータで読み取り可能な記録媒体に記録しておくことができる。サーバコンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープなどがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM(Random Access Memory)、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録媒体には、MO(Magneto-Optical disc)などがある。
【0229】
代理認証プログラムを流通させる場合には、たとえば、その代理認証プログラムが記録されたDVD、CD−ROMなどの可搬型記録媒体が販売される。
代理認証プログラムを実行するサーバコンピュータは、たとえば、可搬型記録媒体に記録された代理認証プログラムを、自己の記憶装置に格納する。そして、サーバコンピュータは、自己の記憶装置から代理認証プログラムを読み取り、代理認証プログラムに従った処理を実行する。なお、サーバコンピュータは、可搬型記録媒体から直接代理認証プログラムを読み取り、その代理認証プログラムに従った処理を実行することもできる。
【0230】
(付記1) 他の装置への認証手続きを代理する代理認証プログラムにおいて、
コンピュータに、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
処理を実行させることを特徴とする代理認証プログラム。
【0231】
(付記2) 前記ユーザ認証手続きでは、予め前記クライアント機能に対応付けて格納されている前記サーバ機能へのユーザ認証情報を、前記クライアント機能からの前記要求に付加して前記サーバ機能へ送信することを特徴とする付記1記載の代理認証プログラム。
【0232】
(付記3) 前記クライアント機能からの前記要求を記憶し、前記サーバ機能との間の前記ユーザ認証手続き完了後、記憶しておいた前記要求を前記サーバ機能に送信することを特徴とする付記1記載の代理認証プログラム。
【0233】
(付記4) ユーザ認証が未完了であることを示す前記応答を受け取った際に、前記クライアント機能との間のセッションの確立の有無を確認し、
前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、
ユーザ認証が完了すると前記クライアント機能との間にセッションを確立し、前記サーバ機能との間の前記ユーザ認証手続きを行う、
ことを特徴とする付記1記載の代理認証プログラム。
【0234】
(付記5) 前記クライアント機能からアクセス可能な前記サーバ機能が複数有る場合、前記サーバ機能毎の認証許否確認論理が設定されていることを特徴とする付記1記載の代理認証プログラム。
【0235】
(付記6) 前記認証許否確認論理では、前記サーバ機能が実装されている装置の識別情報と前記装置内での前記サーバ機能の所在を示す情報との組み合わせにより前記サーバ機能が特定されていることを特徴とする付記1記載の代理認証プログラム。
【0236】
(付記7) 他の装置への認証手続きを代理するための代理認証方法において、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
ことを特徴とする代理認証方法。
【0237】
(付記8) 他の装置への認証手続きを代理する代理認証装置において、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスするアクセス手段と、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する認証要否判断手段と、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、
を有することを特徴とする代理認証装置。
【0238】
(付記9) 他の装置への認証手続きを代理する代理認証プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
処理を実行させることを特徴とする代理認証プログラムを記録したコンピュータ読み取り可能な記録媒体。
【0239】
【発明の効果】
以上説明したように本発明では、複数の認証許否確認論理を予め定義しておき、サーバ機能からの応答に応じた認証許否確認論理を判断し、その認証許否確認論理に対応付けられた認証手順でサーバ機能に対するユーザ認証手続きを行うようにした。このように認証許否確認論理に応じた認証手順に基づいてユーザ認証が行われるため、複数のクライアントの代理認証を行う場合であっても、クライアント毎の認証手順を記憶する必要が無い。その結果、少ないハードウェア資源の利用で代理認証機能が実現可能となる。
【図面の簡単な説明】
【図1】実施の形態に適用される発明の概念図である。
【図2】本実施の形態を提供するネットワークシステムの構成例を示す図である。
【図3】プロキシサーバのハードウェア構成例を示す図である。
【図4】プロキシサーバの機能を示すブロック図である。
【図5】ユーザ情報テーブルのデータ構造例を示す図である。
【図6】システムテーブルのデータ構造例を示す図である。
【図7】レスポンス分析・ログイン命令テーブルのデータ構造例を示す図である。
【図8】セッション情報テーブルのデータ構造例を示す図である。
【図9】代理認証処理の手順を示す第1のフローチャートである。
【図10】代理認証処理の手順を示す第2のフローチャートである。
【図11】代理認証処理の手順を示す第3のフローチャートである。
【図12】代理認証処理の手順を示す第4のフローチャートである。
【図13】Webサーバでベーシック認証を行う場合の処理手順を示す第1のシーケンス図である。
【図14】Webサーバでベーシック認証を行う場合の処理手順を示す第2のシーケンス図である。
【図15】ベーシック認証を完了したWebサーバへのアクセス手順を示すシーケンス図である。
【図16】ベーシック認証を必要とする新たなWebサーバへのアクセス手順を示すシーケンス図である。
【図17】Webサーバでフォーム認証を行う場合の処理手順を示す第1のシーケンス図である。
【図18】Webサーバでフォーム認証を行う場合の処理手順を示す第2のシーケンス図である。
【図19】フォーム認証を完了したWebサーバへのアクセス手順を示すシーケンス図である。
【図20】フォーム認証を必要とする新たなWebサーバへのアクセス手順を示すシーケンス図である。
【図21】ベーシック認証時の送信データ生成手順を示すフローチャートである。
【図22】フォーム認証時の送信データ生成手順を示すフローチャートである。
【図23】代理認証機能を実装したクライアントの概念図である。
【符号の説明】
1 代理認証装置
2 クライアント
3 サーバ
11,12,13,・・・ クライアント
31,32,33,・・・ サーバ
100 プロキシサーバ
110 データベース
111 ユーザ情報テーブル
112 Webサーバ情報
112a システムテーブル
112b レスポンス分析・ログイン命令テーブル
121 セッション情報テーブル
122 タイマ
123 タイムアウト駆動部
131 ブラウザ入力受付部
132 プロキシサーバ認証部
133 プロキシサーバ認証要求部
134 通信状態保持部
135 Webサーバ識別部
136 Webサーバ要求生成部
137 Webサーバ通信部
138 レスポンス分析部
139 認証処理判定部
140 ログイン処理命令生成部
141 コンテンツ変換部
142 ブラウザ応答生成部

Claims (4)

  1. 他の装置への認証手続きを代理する代理認証プログラムにおいて、
    コンピュータに、
    クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
    前記サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、前記応答が前記複数の認証許否確認論理のいずれかに適合するか否かにより、前記サーバ機能との間のユーザ認証の要否を判断し、
    前記サーバ機能との間のユーザ認証が必要と判断した場合、前記クライアント機能との間のセッションの確立の有無を確認し、
    前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、前記クライアント機能との間のユーザ認証が完了すると前記クライアント機能との間に前記セッションを確立し、
    前記サーバ機能との間のユーザ認証が必要と判断した場合であって、前記クライアント機能との間で前記セッションが確立済みになると、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
    処理を実行させることを特徴とする代理認証プログラム。
  2. 前記クライアント機能からの前記要求を記憶し、前記サーバ機能との間の前記ユーザ認証手続き完了後、記憶しておいた前記要求を前記サーバ機能に送信することを特徴とする請求項1記載の代理認証プログラム。
  3. 他の装置への認証手続きを代理するコンピュータの代理認証方法において、
    前記コンピュータが、クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
    前記サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、前記コンピュータが、前記応答が前記複数の認証許否確認論理のいずれかに適合するか否かにより、前記サーバ機能との間のユーザ認証の要否を判断し、
    前記コンピュータが、前記サーバ機能との間のユーザ認証が必要と判断した場合、前記クライアント機能との間のセッションの確立の有無を確認し、
    前記コンピュータが、前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、前記クライアント機能との間のユーザ認証が完了すると前記クライアント機能との間に前記セッションを確立し、
    前記コンピュータが、前記サーバ機能との間のユーザ認証が必要と判断した場合であって、前記クライアント機能との間で前記セッションが確立済みになると、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
    ことを特徴とする代理認証方法。
  4. 他の装置への認証手続きを代理する代理認証装置において、
    クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスするアクセス手段と、
    前記サーバ機能からの応答がユーザ認証を要求する応答であるか否かを当該応答の内容から判断する方法を示した情報である複数の認証許否確認論理が予め定義されており、前記応答が前記複数の認証許否確認論理のいずれかに適合するか否かにより、前記サーバ機能との間のユーザ認証の要否を判断する認証要否判断手段と、
    前記サーバ機能との間のユーザ認証が必要と判断された場合、前記クライアント機能との間のセッションの確立の有無を確認し、前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、前記クライアント機能との間のユーザ認証が完了すると前記クライアント機能との間に前記セッションを確立する手段と、
    前記サーバ機能との間のユーザ認証が必要と判断された場合であって、前記クライアント機能との間で前記セッションが確立済みになると、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、
    を有することを特徴とする代理認証装置。
JP2003175139A 2003-06-19 2003-06-19 代理認証プログラム、代理認証方法、および代理認証装置 Expired - Fee Related JP4467256B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003175139A JP4467256B2 (ja) 2003-06-19 2003-06-19 代理認証プログラム、代理認証方法、および代理認証装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003175139A JP4467256B2 (ja) 2003-06-19 2003-06-19 代理認証プログラム、代理認証方法、および代理認証装置

Publications (2)

Publication Number Publication Date
JP2005011098A JP2005011098A (ja) 2005-01-13
JP4467256B2 true JP4467256B2 (ja) 2010-05-26

Family

ID=34098429

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003175139A Expired - Fee Related JP4467256B2 (ja) 2003-06-19 2003-06-19 代理認証プログラム、代理認証方法、および代理認証装置

Country Status (1)

Country Link
JP (1) JP4467256B2 (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005063169A (ja) * 2003-08-13 2005-03-10 Ricoh Co Ltd 情報処理装置、画像処理装置、サーバ装置、セッション接続方法、セッション接続プログラム及び記録媒体
JP4779444B2 (ja) * 2005-05-26 2011-09-28 株式会社日立製作所 シングルサインオン実現方法
JP4578352B2 (ja) * 2005-08-12 2010-11-10 シャープ株式会社 通信媒介装置、データ提供装置およびデータ提供システム
JP4589200B2 (ja) * 2005-08-23 2010-12-01 日本電信電話株式会社 放送通信連携サービスにおける認証方法,認証連携装置,そのプログラムおよびそのプログラム記録媒体
JP5305280B2 (ja) * 2007-10-23 2013-10-02 野村證券株式会社 ガジェット提供サーバ
JP5159261B2 (ja) 2007-11-12 2013-03-06 インターナショナル・ビジネス・マシーンズ・コーポレーション セッションを管理する技術
US8910255B2 (en) 2008-05-27 2014-12-09 Microsoft Corporation Authentication for distributed secure content management system
CN101296243B (zh) * 2008-06-26 2013-02-20 阿里巴巴集团控股有限公司 一种服务集成平台系统及提供互联网服务的方法
CN101616136B (zh) 2008-06-26 2013-05-01 阿里巴巴集团控股有限公司 一种提供互联网服务的方法及服务集成平台系统
JP4815481B2 (ja) * 2008-10-06 2011-11-16 株式会社オプティム ネットワーク中継機器、ユーザ情報管理システム、およびユーザ情報管理方法
JP5175830B2 (ja) * 2009-12-22 2013-04-03 Necアクセステクニカ株式会社 ルータ、ルータのウェブブラウザ認証方法およびウェブブラウザ認証プログラム
JP2011171983A (ja) * 2010-02-18 2011-09-01 Sony Corp 情報処理装置、情報処理方法およびコンピュータ読み取り可能な記録媒体
JP5732732B2 (ja) * 2010-03-18 2015-06-10 富士通株式会社 認証サーバ装置、プログラム、および方法
JP5418681B2 (ja) * 2010-08-06 2014-02-19 富士通株式会社 仲介処理方法、仲介装置及びシステム
JP5614340B2 (ja) 2011-03-16 2014-10-29 富士通株式会社 システム、認証情報管理方法、およびプログラム
JP5485246B2 (ja) * 2011-11-05 2014-05-07 京セラドキュメントソリューションズ株式会社 画像形成装置
JP5510434B2 (ja) * 2011-11-30 2014-06-04 コニカミノルタ株式会社 ネットワークシステム、情報処理装置およびその制御方法、ならびにコンピュータープログラム
JP5589034B2 (ja) * 2012-07-24 2014-09-10 日本電信電話株式会社 情報流通システム、認証連携方法、装置及びそのプログラム
JP6255858B2 (ja) 2012-10-31 2018-01-10 株式会社リコー システム及びサービス提供装置
JP2014127058A (ja) * 2012-12-27 2014-07-07 Fujitsu Ltd 中継装置、中継方法及びプログラム
JP2017084399A (ja) * 2016-12-28 2017-05-18 富士通株式会社 中継装置、中継方法及びプログラム
JP7025684B2 (ja) * 2017-08-23 2022-02-25 コニカミノルタ株式会社 代理認証システム、代理認証方法、プログラム
JP7502955B2 (ja) 2020-09-29 2024-06-19 株式会社日本総合研究所 仮想ブラウザサーバ及びプログラム、
CN113472796B (zh) * 2021-07-06 2023-05-30 山东电力工程咨询院有限公司 一种数据中心门户管理方法及系统
CN115604041B (zh) * 2022-12-16 2023-05-09 深圳高灯计算机科技有限公司 安全代理方法、系统、装置、计算机设备和存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002032216A (ja) * 2000-07-19 2002-01-31 Fujitsu Ltd アプリケーションのホスティング装置
EP1223721A3 (en) * 2000-10-31 2004-07-14 Microsoft Corporation Systems and methods for automatically formulating response to authentication requests from secured servers
JP2002334056A (ja) * 2001-05-08 2002-11-22 Infocom Corp ログイン代行システム及びログイン代行方法

Also Published As

Publication number Publication date
JP2005011098A (ja) 2005-01-13

Similar Documents

Publication Publication Date Title
JP4467256B2 (ja) 代理認証プログラム、代理認証方法、および代理認証装置
US9438633B1 (en) System, method and computer program product for providing unified authentication services for online applications
JP4864289B2 (ja) ネットワークユーザ認証システムおよび方法
RU2447490C2 (ru) Защищенная обработка мандата клиентской системы для доступа к ресурсам на основе web
US8326981B2 (en) Method and system for providing secure access to private networks
US6510236B1 (en) Authentication framework for managing authentication requests from multiple authentication devices
KR100856674B1 (ko) 클라이언트 서버 환경에서 클라이언트를 인증하는 시스템및 방법
KR100800339B1 (ko) 제휴 환경에서 사용자에 의해 결정된 인증 및 단일 사인온을 위한 방법 및 시스템
US20080040773A1 (en) Policy isolation for network authentication and authorization
JP4886508B2 (ja) 既存のsslセッションを中断することなく証明書ベースの認証にステップアップするための方法及びシステム
US7587491B2 (en) Method and system for enroll-thru operations and reprioritization operations in a federated environment
US7188181B1 (en) Universal session sharing
US6976164B1 (en) Technique for handling subsequent user identification and password requests with identity change within a certificate-based host session
US7043455B1 (en) Method and apparatus for securing session information of users in a web application server environment
US7356833B2 (en) Systems and methods for authenticating a user to a web server
EP1645971B1 (en) Database access control method, database access controller, agent processing server, database access control program, and medium recording the program
US20070156592A1 (en) Secure authentication method and system
US20010000045A1 (en) Web-based, biometric authentication system and method
WO1998057247A1 (en) Web-based, biometric authentication system and method
CN107872455A (zh) 一种跨域单点登录系统及其方法
CA2381108A1 (en) Secure mutual authentication system
JP2001186122A (ja) 認証システム及び認証方法
US12107956B2 (en) Information processing device, information processing method, and non-transitory computer readable storage medium
JP2002189646A (ja) 中継装置
JP2008015733A (ja) ログ管理計算機

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060525

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090513

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090519

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090717

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100223

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100223

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130305

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140305

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees