JP2005011098A - Proxy authentication program, method, and device - Google Patents
Proxy authentication program, method, and device Download PDFInfo
- Publication number
- JP2005011098A JP2005011098A JP2003175139A JP2003175139A JP2005011098A JP 2005011098 A JP2005011098 A JP 2005011098A JP 2003175139 A JP2003175139 A JP 2003175139A JP 2003175139 A JP2003175139 A JP 2003175139A JP 2005011098 A JP2005011098 A JP 2005011098A
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- server
- proxy
- response
- 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.)
- Granted
Links
Images
Abstract
Description
【０００１】
【発明の属する技術分野】
本発明は他の装置への認証手続きを代理する代理認証プログラム、代理認証方法、および代理認証装置に関し、特に異なる認証方式による認証手続きを行う代理認証プログラム、代理認証方法、および代理認証装置に関する。
【０００２】
【従来の技術】
企業内のネットワークでは、ネットワーク内に複数のサーバ（あるいはサービスを提供するアプリケーションプログラム）が存在し、様々なサービスがネットワークを介して提供される。ただし、企業内のネットワークであっても、一部の機能に関しては使用可能なユーザが制限される。たとえば、社員の出退勤を管理するシステムに対しては、所定の役職以上のユーザ、あるいは人事部等の所定の部署のユーザに対してのみアクセスを許可する必要がある。以下、サービスを提供する機能（サーバアプリケーション）をサーバ機能と呼ぶこととする。
【０００３】
一般的には、サービスを利用可能なユーザを制限するため、サーバ機能毎にユーザ認証が行われる。ユーザ認証では、サーバ機能がユーザに対して、ユーザ名とパスワードとの入力を要求する。入力されたユーザ名とパスワードとの組が予めサーバ機能に登録されていれば、サーバ機能は、そのユーザに許可されている範囲の機能を提供する。このようなユーザ認証は、ネットワーク内にサーバ機能が多数存在する場合でも、原則的に個別に行われる。
【０００４】
ところで、最近の業務処理のシステム化に伴い、社内業務の多くが、その業務を支援するサーバ機能を利用して行われる。そのため、社員が業務を遂行する上で、様々なサーバ機能に対してユーザ認証を行う必要が生じる。この場合、個別のサーバ機能へのユーザ認証を行うには、各ユーザがユーザ名とパスワードとの組を個人で管理しなければならず、パスワード等の管理負担が大きい。また、一日に何度もユーザ認証手続きを行うのは、業務の作業効率低下に繋がる。
【０００５】
そこで、従来はシングルサインオンと呼ばれるシステムが利用されている。シングルサインオンでは、ユーザが一度認証を受けるだけで、そのユーザに対したアクセスを許可している機能をユーザ利用できる。
【０００６】
シングルサインオンを実現する技術の１つにＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を用いた技術がある。ＰＫＩは、電子署名と暗号技術を兼ね備え、安全な電子通信を確保する技術である。ＰＫＩシステムでは、ユーザ認証したユーザに対して電子証明書を発行する。そして、電子証明書を保持しているユーザは、その電子証明書に応じた各種サービスの提供を受けることができる。
【０００７】
また、シングルサインオンを実現する別の技術として、プロキシサーバで代理認証する方式がある。この技術では、各サーバ機能に対するユーザ認証のためのデータをプロキシサーバに保持する。そして、ユーザからサーバ機能へのアクセス要求が出されると、プロキシサーバが代理でサーバ機能との間でユーザ認証手続きを行う（たとえば、特許文献１参照）。
【０００８】
また、ユーザ端末からＷｅｂサーバへのプロキシサーバを介したアクセスで一度認証された場合、そのデータをプロキシサーバに記憶しておく。そして、同じユーザ端末による次回以降のログイン時には、プロキシサーバに記憶されたデータを使用する。この方式に寄れば、様々な形式のログインプロトコルに対応することができる（たとえば、特許文献２参照）。
【０００９】
【特許文献１】
特開平１０−１７７５５２号公報（第１図）
【特許文献２】
特開２００２−３２３４０号公報（第１図）
【００１０】
【発明が解決しようとする課題】
しかし、ＰＫＩを用いた技術の場合は、Ｗｅｂブラウザ、Ｗｅｂサーバともに電子証明書に対応した機構を必要とする上、電子証明書のためのインフラを必要とする。そのため、既存のシステムをそのまま流用するのは困難である。
【００１１】
すなわち、一般のプロキシサーバで代理認証する方式では固定的な認証プロトコルを用いるため、サーバ機能毎に認証方式が異なる場合には採用できない。しかも、現実のＷｅｂサーバの認証方式は開発者の自由であるため様々なものが存在する。一つの代理認証型のプロキシサーバがそれらに対し代理認証を行うのは困難であり、代理認証プロキシの有用性を減じさせている。
【００１２】
たとえば、特許文献１に記載された方式では、代理サーバで複数の認証情報を管理し、クライアントに代わってサーバに対して認証情報を送信するだけであり、サーバ毎に異なる手順の認証手続きを実行することができない。具体的には、認証情報を送信するだけで認証可能なサーバもあれば、サーバが提供するフォームデータ内の所定のパラメータとして設定した認証情報を送信することで認証可能なサーバもある。このように、単に認証情報を送信するだけでは、代理認証ができないサーバも多数存在する。
【００１３】
また、特許文献２に示された方式であればサーバ機能毎に異なる認証方式が採用されている場合にも適用可能である。しかし、特許文献２に示されたような認証時のデータを全て記録する方式では、多数のユーザが同じサーバを利用した場合は、認証用の通信データの保存域にほとんど同じだが少しだけ異なるデータを多数保持する必要が生じる。そのため、システムの資源（メインメモリやハードディスクデバイス等）の利用効率が悪くなる。これは、実際の認証用通信データで、ユーザ毎に異なる部分は僅かであり、データの多くは共通のヘッダやフッターによって占められるためである。
【００１４】
一般的に、必要なハードウェア資源の量が不明な場合、システムの安定運用のためには、余裕を持ったハードウェア環境を整えておく必要がある。そのため、システムの規模が肥大化し、システムの構築コストが増加していた。
【００１５】
本発明はこのような点に鑑みてなされたものであり、ハードウェア資源を効率よく利用して、異なる認証方式のサーバへの代理認証を行うことができる代理認証プログラム、代理認証方法、および代理認証装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような処理をコンピュータに実行させる代理認証プログラムが提供される。この代理認証プログラムは、他の装置への認証手続きを代理するためのものであり、コンピュータに対して以下の処理を実行させる。
【００１７】
コンピュータは、クライアント機能２ａ，２ｂ，２ｃ，・・・からの要求に応じて、ネットワークを介して接続されるサーバ機能３ａ，３ｂ，３ｃ，・・・に対してアクセスする（ステップＳ１）。コンピュータは、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、サーバ機能からの応答が複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する（ステップＳ２）。そして、ユーザ認証が必要な場合、コンピュータは、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きを行う（ステップＳ３）。
【００１８】
このような代理認証プログラムによれば、コンピュータにより、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証の未完了を示す応答が返されると、その応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。
【００１９】
また、上記課題を解決するために他の装置への認証手続きを代理するための代理認証方法において、クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバに対してアクセスし、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、ことを特徴とする代理認証方法が提供される。
【００２０】
このような代理認証方法によれば、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証の未完了を示す応答が返されると、その応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。
【００２１】
また、上記課題を解決するために、他の装置への認証手続きを代理する代理認証装置において、クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバに対してアクセスするアクセス手段と、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する認証要否判断手段と、ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、を有することを特徴とする代理認証装置が提供される。
【００２２】
このような代理認証装置によれば、アクセス手段により、クライアント機能からの要求に応じてサーバ機能へのアクセスが行われる。そして、サーバ機能から応答が返されると、認証要否判断手段により、ユーザ認証の要否を判断される。ユーザ認証が必要な場合、代理認証手段により、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きが行われる。
【００２３】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【００２４】
図１は、実施の形態に適用される発明の概念図である。代理認証装置１は、複数のクライアント機能２ａ，２ｂ，２ｃ，・・・と複数のサーバ機能３ａ，３ｂ，３ｃ，・・・との論理的な通信経路上に設けられている。ここで、論理的な通信経路とは、複数のクライアント機能２ａ，２ｂ，２ｃ，・・・のいずれかと複数のサーバ機能３ａ，３ｂ，３ｃ，・・・のいずれかとの間の通信（少なくとも代理認証を必要とする通信）が、必ず代理認証装置１を経由して行われることを意味する。
【００２５】
代理認証装置１は、クライアント機能２ａ，２ｂ，２ｃ，・・・がサーバ機能３ａ，３ｂ，３ｃ，・・・に対して実行すべきユーザ認証手続きを、クライアント機能２ａ，２ｂ，２ｃ，・・・の代理で実行することができる。なお、代理認証装置１には、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されている。また、各認証許否確認論理に対応付けて、認証手順が定義されている。認証手順は、認証手続きの際にクライアント機能２ａ，２ｂ，２ｃ，・・・側で実行すべき処理内容を、認証方式毎に定義したものである。
【００２６】
クライアント機能２ａ，２ｂ，２ｃ，・・・は、ユーザの操作入力に応答してサーバ機能３ａ，３ｂ，３ｃ，・・・に対して要求を送信する機能を有している。クライアント機能２ａ，２ｂ，２ｃ，・・・は、たとえば、それぞれが個別のクライアントコンピュータに実装されたクライアントアプリケーションである。
【００２７】
サーバ機能３ａ，３ｂ，３ｃ，・・・は、クライアント機能２ａ，２ｂ，２ｃ，・・・から送られた要求に応じた処理を行う。サーバ機能３ａ，３ｂ，３ｃ，・・・は、たとえば、プロキシサーバ等に実装されたサーバアプリケーションである。なお、サーバ機能３ａ，３ｂ，３ｃ，・・・はユーザ認証機能を有しており、ユーザ認証を完了したクライアント機能２ａ，２ｂ，２ｃ，・・・からの要求に対してのみ、処理機能を提供する。また、各サーバ機能３ａ，３ｂ，３ｃ，・・・は、それぞれ異なる認証方式を採用している。
【００２８】
ここで、クライアント機能２ａ，２ｂ，２ｃ，・・・からサーバ機能３ａ，３ｂ，３ｃ，・・・へアクセスする場合、代理認証装置１において、以下の処理が行われる。
【００２９】
代理認証装置１は、クライアント機能２ａ，２ｂ，２ｃ，・・・からの要求に応じて、ネットワークを介して接続されるサーバ機能３ａ，３ｂ，３ｃ，・・・に対してアクセスする（ステップＳ１）。アクセスされたサーバ機能は、ユーザ認証が必要であり、アクセス要求を出力したクライアント機能のユーザ認証が未完了の場合、ユーザ認証を要求する応答を代理認証装置１に返す。
【００３０】
代理認証装置１は、サーバ機能からの応答が複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する（ステップＳ２）。そして、ユーザ認証が必要と判断した場合、代理認証装置１は、応答が適合した認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバ機能との間でユーザ認証手続きを行う（ステップＳ３）。
【００３１】
このような代理認証装置１によれば、クライアント機能からの要求に応じてサーバ機能にアクセスしたとき、ユーザ認証の未完了を示す応答が返されると、その応答が適合する認証許否確認論理に対応する処理手順でサーバ機能との間で認証手続きが行われる。サーバ機能からの応答を解析してサーバ機能が採用する認証方式に応じた認証手順を判断し、その認証手順で代理認証を行うことで、認証手順等を格納しておくべき記憶容量が少なくてすむ。
【００３２】
たとえば、複数のクライアント機能２ａ，２ｂ，２ｃ，・・・が同一のサーバ機能３ａにアクセスする場合を考える。このとき、従来の技術（特許文献２参照）のように全ての認証データを記録し、そのデータから認証手続きを再現することで代理認証を行う場合、クライアント機能２ａ，２ｂ，２ｃ，・・・毎の認証手続きを保存しなければならない。本発明のように、サーバ機能３ａからの応答によって該当する認証手続きを決定し、その認証手続きで代理認証を行うようにすれば、サーバ機能３ａに対応付けて１つの認証手続きを保持しておけばよい。
【００３３】
しかも、サーバ機能からの応答によって必要な認証手続きを決定するため、各サーバ機能３ａ，３ｂ，３ｃ，・・・は、それぞれ異なる認証方式を採用していても、それぞれの認証方式に応じた認証手続きで代理認証を行うことができる。
【００３４】
なお、クライアント機能２ａ，２ｂ，２ｃ，・・・毎のユーザ認証情報（たとえば、ユーザ名とパスワード）を保持する必要はあるが、これらは短い文字列からなる情報である。そのため、ユーザ認証情報は、認証手続きの処理手順を全て記録する場合に比べて、少ない記憶容量で済む。
【００３５】
以下に、本実施の形態を具体的に説明する。以下の実施の形態は、プロキシサーバに代理認証装置の機能を実装し、Ｗｅｂサーバへの代理認証を行う場合の例である。
【００３６】
図２は、本実施の形態を提供するネットワークシステムの構成例を示す図である。図２に示すように、複数のクライアント１１，１２，１３，・・・、複数のサーバ３１，３２，３３，・・・およびプロキシサーバ１００でシステムが構成されている。
【００３７】
クライアント１１，１２，１３，・・・は、ユーザが使用するコンピュータである。クライアント１１，１２，１３，・・・とプロキシサーバ１００との間は、たとえば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続される。ユーザは、クライアント１１，１２，１３，・・・を用いて、プロキシサーバ１００に対してログイン（ベーシック（Ｂａｓｉｃ）認証ログイン）を行うことができる。本実施の形態では、各クライアント１１，１２，１３，・・・には、クライアント機能としてＷｅｂブラウザが実装されており、Ｗｅｂブラウザによってサーバ３１，３２，３３，・・・にアクセスするものとする。
【００３８】
サーバ３１，３２，３３，・・・は、クライアント１１，１２，１３，・・・からの要求に応じて所定のサービスを提供するサーバコンピュータである。サーバ３１，３２，３３，・・・とプロキシサーバ１００との間は、ＬＡＮ、高速専用回線、インターネット等で接続される。サーバ３１，３２，３３，・・・には、サーバ機能等が実装され、サーバ機能毎にユーザ認証機能を有している。本実施の形態では、各サーバ３１，３２，３３，・・・には、サーバ機能としてＷｅｂサーバが実装され、ＷｅｂサーバによってクライアントのＷｅｂブラウザに対するコンテンツの提供サービス等を行う。
【００３９】
プロキシサーバ１００は、クライアント１１，１２，１３，・・・の代理でサーバ３１，３２，３３，・・・にアクセスするコンピュータである。プロキシサーバ１００には、複数のログインアルゴリズム（ベーシック認証やフレーム認証）が定義されている。サーバ３１，３２，３３，・・・からユーザ認証が要求された場合、プロキシサーバ１００は要求されたユーザ認証用のログインアルゴリズムを識別し、該当するアルゴリズムでログイン手続きを行うことができる。たとえば、プロキシサーバ１００は、サーバ３１，３２，３３，・・・にアクセスする際、ユーザ認証を要求されると、クライアント１１，１２，１３，・・・に代わってユーザ認証手続きを行い、サーバ３１，３２，３３，・・・にログインする。
【００４０】
このようなシステムにより、ユーザはクライアント（たとえば、クライアント１１）を利用してサーバ３１，３２，３３，・・・にアクセスできる。そして、１つのＷｅｂサーバ（たとえば、サーバ３１）からユーザ認証が要求されると、プロキシサーバ１００からクライアント１１にユーザ認証が要求される。すると、ユーザがクライアント１１を操作し、プロキシサーバ１００に対してベーシック認証ログインを行う。
【００４１】
プロキシサーバ１００は、クライアント１１から送られるユーザ認証情報を、内部に保持するユーザ情報テーブルと照合することでベーシック認証ログインを認め、サーバ３１に対してログインする。その際、プロキシサーバ１００は、サーバ３１の認証方式に合ったアルゴリズムでログイン手続きを行う。
【００４２】
その後、クライアント１１から他のＷｅｂサーバ３２，３３，・・・へのアクセスの際にユーザ認証が要求されると、そのＷｅｂサーバの認証方式に合ったアルゴリズムで、プロキシサーバ１００がログイン手続きを行う。ログイン手続き完了後は、クライアント１１が要求するサービスがＷｅｂサーバにおいて提供され、結果がクライアント１１に渡される。
【００４３】
図３は、プロキシサーバのハードウェア構成例を示す図である。プロキシサーバ１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。
【００４４】
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
【００４５】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
【００４６】
通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータ（クライアント１１，１２，１３，・・・やサーバ３１，３２，３３，・・・）との間でデータの送受信を行う。
【００４７】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、プロキシサーバ１００のハードウェア構成を示したが、クライアント１１，１２，１３，・・・やサーバ３１，３２，３３，・・・も同様のハードウェア構成で実現することができる。
【００４８】
次に、プロキシサーバ１００の機能について具体的に説明する。なお、以下の説明では、クライアント１１からサーバ３１やサーバ３２に対してアクセスする場合を例に採る。
【００４９】
図４は、プロキシサーバの機能を示すブロック図である。なお、図４に示すように、プロキシサーバ１００には、クライアント１１に実装されたＷｅｂブラウザ１１ａとサーバ３１，３２に実装されたＷｅｂサーバ３１ａ，３２ａとの間で通信を行うことができる。
【００５０】
プロキシサーバ１００は、データベース１１０、セッション情報テーブル１２１、タイマ１２２、タイムアウト駆動部１２３、ブラウザ入力受付部１３１、プロキシサーバ認証部１３２、プロキシサーバ認証要求部１３３、通信状態保持部１３４、Ｗｅｂサーバ識別部１３５、Ｗｅｂサーバ要求生成部１３６、Ｗｅｂサーバ通信部１３７、レスポンス分析部１３８、認証処理判定部１３９、ログイン処理命令生成部１４０、コンテンツ変換部１４１、およびブラウザ応答生成部１４２を有している。
【００５１】
データベース１１０には、代理認証に必要なデータが格納されている。データベース１１０の内容は、ユーザ情報テーブル１１１とＷｅｂサーバ情報１１２とに分かれる。
【００５２】
ユーザ情報テーブル１１１は、クライアント１１，１２，１３，・・・を使用するユーザに関する情報が登録されたデータベースである。たとえば、ユーザ情報テーブル１１１には、各ユーザがプロキシサーバ１００にベーシックログインするためのユーザ認証情報や、ユーザがサーバ３１，３２，３３，・・・にログインするためのユーザ認証情報が、ユーザ毎に格納されている。本実施の形態では、ユーザ情報テーブル１１１の内容は、システムの管理者によって予め設定されるものとする。
【００５３】
Ｗｅｂサーバ情報１１２は、代理認証の対象とするＷｅｂサーバに関する情報である。Ｗｅｂサーバ情報１１２は、システムテーブル１１２ａとレスポンス分析・ログイン命令テーブル１１２ｂとに別れている。本実施の形態では、Ｗｅｂサーバ情報１１２の内容は、システムの管理者によって予め設定されるものとする。
【００５４】
システムテーブル１１２ａは、サーバ機能毎にＷｅｂサーバのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）や認証方式が管理されている。
レスポンス分析・ログイン命令テーブル１１２ｂには、Ｗｅｂサーバへのログインに必要な情報が格納されている。
【００５５】
セッション情報テーブル１２１には、クライアントとの間で確立したセッションに関する情報が登録されている。セッションに関する情報には、タイムアウト時刻も含まれる。セッション情報テーブル１２１の内容は、システムの運用中に動的に追加や削除される。
【００５６】
ここで、プロキシサーバ１００の他の要素を説明する前に、各情報のデータ構造例について詳細に説明する。
図５は、ユーザ情報テーブルのデータ構造例を示す図である。ユーザ情報テーブル１１１には、プロキシサーバ認証情報に対応付けて、システムＩＤ、ユーザ名およびパスワードの組がＷｅｂサーバ毎に設定されている。各欄の横方向に並べられた情報同士が互いに関連づけられて、各ユーザのユーザ情報を構成している。
【００５７】
プロキシサーバ認証情報の欄は、ユーザ名の欄とパスワードの欄とに分かれている。ユーザ名の欄には、ユーザ名が設定される。パスワードの欄には、ユーザ名に対応するパスワードが設定される。
【００５８】
システムＩＤの欄には、ユーザ認証対象となるＷｅｂサーバの識別情報が設定される。図５の例では、「Ｓｙｓ」に続くアルファベットがサーバ（ネットワーク上のノード）の識別子であり、アルファベットに続く数字がサーバ内のＷｅｂサーバの識別子である。従って、「ＳｙｓＡ０」と「ＳｙｓＡ１」とは、同じサーバ内の別々のＷｅｂサーバを示している。
【００５９】
ユーザ名の欄には、Ｗｅｂサーバに設定されているユーザ認証情報のユーザ名が設定される。パスワードの欄には、Ｗｅｂサーバに設定されているユーザ認証情報のパスワードが設定される。
【００６０】
図６は、システムテーブルのデータ構造例を示す図である。システムテーブル１１２ａには、システムＩＤ、仮想ＵＲＬ、実ＵＲＬ、および認証タイプの欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられて、各Ｗｅｂサーバに関する情報を構成している。
【００６１】
システムＩＤの欄には、Ｗｅｂサーバの識別情報が設定される。
仮想ＵＲＬの欄には、クライアントからＷｅｂサーバにアクセスするための仮想的なＵＲＬが設定される。Ｗｅｂブラウザからは、仮想ＵＲＬを指定したアクセス要求が出される。
【００６２】
実ＵＲＬの欄には、Ｗｅｂサーバの実際の所在を示すＵＲＬが設定される。なお、仮想ＵＲＬと実ＵＲＬとは同一の場合もある。
認証タイプの欄には、Ｗｅｂサーバにおけるユーザ認証方式の名称が設定される。図６の例では、認証タイプとして「フォーム」、「ベーシック」、「ｎｕｌｌ」が設定されている。
【００６３】
フォーム認証は、認証されていない要求をＷｅｂサーバ３１ａ側でＨＴＭＬフォームにリダイレクトするシステムである。クライアント（プロキシサーバ１００がＷｅｂブラウザ１１ａの代わりにクライアントとして機能する）には、認証用のフォームが渡される。そこで、フォームに対して認証情報を入力し、認証情報を含むフォームをＷｅｂサーバ３１ａに送信する。
【００６４】
ベーシック認証では、認証されていない要求を受け取ったＷｅｂサーバ３１ａから認証を要求する応答が返されると、クライアント（プロキシサーバ１００がＷｅｂブラウザ１１ａの代わりにクライアントとして機能する）に認証情報（ユーザ名とパスワード）入力用のダイアログが表示される。そのダイアログに対して認証情報を入力すると、その認証情報がＷｅｂサーバ３１ａに送信される。
【００６５】
ｎｕｌｌは、認証が不要であることを示している。
なお、仮想ＵＲＬは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のクッキー送信範囲の制限を回避し、外部（Ｗｅｂサーバ３１，３２，３３，・・・側）のネットワーク上のサーバに対し、内部（クライアント１１，１２，１３，・・・側）にあるサーバと同じようにシングルサインオンを提供するために利用される。すなわち、本実施の形態では、プロキシサーバ１００でのユーザ認証が完了しているか否かを示すセッション情報を、クライアントにおいてＨＴＴＰクッキーで管理している。このＨＴＴＰクッキーはその仕様上、ドメイン名が後方一致している場合に限り、異なるドメインに対して設定することができる。
【００６６】
たとえば、プロキシサーバ１００のドメイン名がａａａ．ｂｂｂ．ｃｏｍであり、ユーザがアクセスしたいサーバ機能のドメイン名がｄｄｄ．ｂｂｂ．ｃｏｍである場合は、ｂｂｂ．ｃｏｍの部分が同じ（後方一致）である。したがって、プロキシサーバ１００が仮想ＵＲＬを用いなくてもクッキー機構が機能する。しかし、対象となるＷｅｂサーバのドメイン名がｘｘｘ．ｚｚｚ．ｃｏｍだった場合には後方一致せず、プロキシサーバ１００がその通信を操作し、認証情報をクッキーに付加したとしても、ブラウザ側は仕様によりａａａ．ｂｂｂ．ｃｏｍプロキシサーバ１００のクッキーとは認められない。そのため、本実施の形態の認証ロジックが成立しない。
【００６７】
そこで本実施の形態では、ｘｘｘ．ｚｚｚ．ｃｏｍの仮想ＵＲＬをｘｘｘ．ｂｂｂ．ｃｏｍと設定する。ユーザはＷｅｂブラウザからＵＲＬとしてｘｘｘ．ｂｂｂ．ｃｏｍを指定して、プロキシサーバ１００経由でアクセスを行う。プロキシサーバ１００は内部で仮想ＵＲＬ変換を行い、実際の通信をｘｘｘ．ｚｚｚ．ｃｏｍに対して行う。プロキシサーバ１００はｘｘｘ．ｚｚｚ．ｃｏｍからの応答データとクッキーを組み合わせてユーザのＷｅｂブラウザに返送する。このときＷｅｂブラウザはＵＲＬがｘｘｘ．ｚｚｚ．ｃｏｍのＷｅｂサーバからではなく、ＵＲＬがｘｘｘ．ｂｂｂ．ｃｏｍのＷｅｂサーバからの通信と判断する。そのため、クッキーは無事受け入れられる。これにより、本発明の効果がインターネット全体に適用可能で、実用性が高まる。
【００６８】
図７は、レスポンス分析・ログイン命令テーブルのデータ構造例を示す図である。レスポンス分析・ログイン命令テーブル１１２ｂには、システムＩＤ、ログイン処理情報、および認証識別情報の欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられ、各Ｗｅｂサーバへのユーザ認証手続きに必要な情報を構成している。
【００６９】
システムＩＤの欄には、Ｗｅｂサーバの識別情報が設定される。
ログイン処理情報の欄には、Ｗｅｂサーバへのユーザ認証（ログイン）手続きに必要な情報が設定される。ログイン処理情報の欄には、認証ＵＲＬ、メソッド、フォーム名の欄が設けられている。
【００７０】
認証ＵＲＬの欄には、該当Ｗｅｂサーバへログインする際にアクセスすべきＵＲＬが設定される。
メソッドの欄には、ＨＴＴＰにおけるリクエストの種類（メソッド）が設定さえる。メソッドには、「ＧＥＴ」や「ＰＯＳＴ」がある。ＧＥＴは、Ｗｅｂサーバから情報を引き出すためのメソッドである。ＰＯＳＴは、Ｗｅｂサーバに対して情報を送信するためのメソッドである。
【００７１】
フォーム名の欄には、認証情報を設定すべきフォームの名称が設定される。フォーム名の欄には、ユーザ、パスワード、付加データの欄が設けられている。ユーザの欄には、ユーザ名を設定すべきフォームの名称が設定される。パスワードの欄には、パスワードを設定すべきフォームの名称が設定される。付加データの欄には、ユーザ認証に際して付加すべき情報を設定するためのフォームの名称が設定される。この付加データの欄には、１つのシステムＩＤに対応付けて１個あるいは複数（ｍ個：ｍは１以上の自然数）の情報を設定することができる。
【００７２】
認証識別情報の欄には、Ｗｅｂサーバからの応答が認証を要求しているか否かを識別するための情報が設定される。認証識別情報の欄には、レスポンスコード、認証ヘッダ、および識別内容データの欄が設けられている。
【００７３】
レスポンスコードの欄には、Ｗｅｂサーバからの応答の種別を示すコード（レスポンスコード）が設定される。識別ヘッダの欄には、認証の要求を示す応答のヘッダに含まれるべき情報が設定される。この識別ヘッダの欄には、１つのシステムＩＤに対応付けて１個あるいは複数（ｎ個：ｎは１以上の自然数）の情報を設定することができる。識別内容データの欄には、認証の要求を示す応答の内容に含まれるべき情報が設定される。
【００７４】
図８は、セッション情報テーブルのデータ構造例を示す図である。セッション情報テーブル１２１には、クライアントとの間で確立したセッションに関する情報が設定される。セッション情報テーブル１２１には、セッションＩＤ、ユーザ名、ログイン時刻、およびタイムアウト予告時刻の欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられ、セッション毎の情報を構成している。
【００７５】
セッションＩＤの欄には、確立されたセッションの識別情報が設定される。ユーザ名の欄には、セッションの確立を要求したユーザの識別情報が設定される。ログイン時刻の欄には、ユーザがプロキシサーバ１００に対してログイン（ユーザ認証が成功したこと）した時刻が設定される。タイムアウト予告時刻には、セッションを切断する時刻が設定される。
【００７６】
以上が、プロキシサーバ１００で管理される各データベースのデータ構造である。以下、図４の説明に戻り、プロキシサーバ１００の他の要素について説明する。
【００７７】
タイマ１２２は、時刻を計時する機能を有している。ＯＳは、タイマ１２２を用いて定期的にタイマーイベントを発生させ、そのタイマーイベントを契機にタイムアウト駆動部１２３が起動される。
【００７８】
タイムアウト駆動部１２３は、起動されるとセッション情報テーブル１２１を走査し、タイムアウト予定時刻を過ぎたセッション情報をセッション情報テーブル１２１から削除する。
【００７９】
ブラウザ入力受付部１３１は、Ｗｅｂブラウザ１１ａからの入力を受け付ける。ブラウザ入力受付部１３１は、受け付けた内容をプロキシサーバ認証部１３２、通信状態保持部１３４、およびＷｅｂサーバ識別部１３５に渡す。
【００８０】
プロキシサーバ認証部１３２は、Ｗｅｂブラウザ１１ａからの入力がプロキシサーバへの認証情報を含むか否かを確認する。入力内容に、既に認証済みを示すプロキシサーバセッションＩＤ情報が含まれていた場合は、プロキシサーバ認証部１３２は、セッション情報テーブル１２１を確認し、有効な接続か否かを確認する。有効な接続だった場合、プロキシサーバ認証部１３２は、タイムアウト時間を延長するために、”タイムアウト予定時刻”を更新することもできる。
【００８１】
また、入力情報にユーザ名とパスワード情報（ＡＵＴＨＯＲＩＺＥＤヘッダ内に含まれる）が含まれていた場合は、プロキシサーバ認証部１３２は、ユーザ情報テーブル１１１からプロキシサーバ認証用のユーザ名、パスワードと比較する。一致する場合は、プロキシサーバ認証部１３２は、セッション情報テーブル１２１にセッション情報を登録する。一致しない場合は、プロキシサーバ認証部１３２は、プロキシサーバ認証要求部１３３に対してプロキシサーバ認証を依頼する。
【００８２】
プロキシサーバ認証部１３２は、Ｗｅｂブラウザ１１ａからの入力内容にプロキシサーバへの認証情報（セッションＩＤ、ユーザ名、パスワード）を含まない場合は、何もしない（認証情報を含まないことは許可される）。
【００８３】
プロキシサーバ認証要求部１３３は、プロキシサーバ認証部１３２からの依頼に応じて、ＨＴＴＰのＵＮＡＵＴＨＯＲＩＺＥＤレスポンスを生成する。そして、プロキシサーバ認証要求部１３３は、生成したＵＮＡＵＴＨＯＲＩＺＥＤレスポンスをユーザのＷｅｂブラウザ１１ａに返す。ここで、ＵＮＡＵＴＨＯＲＩＺＥＤレスポンスとは、Ｗｅｂブラウザ１１ａに対して認証情報の送信を要求する通信パケットである。
【００８４】
通信状態保持部１３４は、後で使用するために、ブラウザから受けたＨＴＴＰ要求（ＭＥＴＨＯＤ，ＵＲＬ，ヘッダ、ＰＯＳＴデータ）を保存する。
Ｗｅｂサーバ識別部１３５は、Ｗｅｂブラウザからの入力内容がプロキシ通信要求の場合、そのプロキシ通信要求に基づいて通信先のＵＲＬを識別する。なお、Ｗｅｂブラウザ１１ａから指定されるＵＲＬは仮想ＵＲＬである。Ｗｅｂサーバ識別部１３５は、要求されたＵＲＬが含まれる情報をシステムテーブル１１２ａから検索する。検索時にはシステムテーブル１１２ａの仮想ＵＲＬの項目を対象にする。要求されたＵＲＬが仮想ＵＲＬに一致するか、あるいは仮想ＵＲＬの配下に含まれる場合、そのシステムエントリを用いる。Ｗｅｂサーバ識別部１３５は、要求されたＵＲＬを含む仮想ＵＲＬに対応する実ＵＲＬをＷｅｂサーバ要求生成部１３６に渡す。
【００８５】
以後の処理でプロキシサーバ１００から実際のＷｅｂサーバ３１ａ，３２ａへ通信がなされる場合は、仮想ＵＲＬが実ＵＲＬに変換される。なお、仮想ＵＲＬと実ＵＲＬは同じでもかまわない。
【００８６】
なお、仮想ＵＲＬ、実ＵＲＬともに物理的には同じ計算機であってもよい。本実施の形態では、サーバ機能がＵＲＬ毎に管理されるため、一つの計算機を複数のシステムとして扱うことが許される。
【００８７】
Ｗｅｂサーバ要求生成部１３６は、ＨＴＴＰ要求を生成する。その際、通信状態保持部１３４のデータを利用する。また、セッション情報テーブル１２１を確認し、プロキシサーバ１００で認証済みの場合は、プロキシサーバ１００のユーザ名等の認証情報を、ＨＴＴＰのクッキーとして、ＷｅｂサーバへのＨＴＴＰ要求に付加する。そして、Ｗｅｂサーバ要求生成部１３６は、クッキーが付加されたＨＴＴＰ要求をＷｅｂサーバ通信部１３７に渡す。
【００８８】
また、Ｗｅｂサーバ要求生成部１３６は、レスポンス分析部１３８による応答内容の分析の結果、Ｗｅｂサーバ３１ａ，３２ａに対するフォーム形式のログインが完了していたとき、応答内容を受け取る。すると、Ｗｅｂサーバ要求生成部１３６は、認証応答で得られたクッキー情報やセッション情報テーブル１２１から生成したプロキシサーバのユーザ名等の情報をＨＴＴＰクッキーに含める。そして、Ｗｅｂサーバ要求生成部１３６は、通信状態保持部１３４に保存されているユーザのＷｅｂブラウザからの要求を組み合わせ、Ｗｅｂサーバ通信部１３７からＷｅｂサーバ３１ａ，３２ａに送信する。
【００８９】
Ｗｅｂサーバ通信部１３７は、生成されたＨＴＴＰ要求をシステムテーブル１１２ａの実ＵＲＬから生成した通信先に送る。また、Ｗｅｂサーバ通信部１３７は、Ｗｅｂサーバからの通信応答をレスポンス分析部１３８に渡す。
【００９０】
レスポンス分析部１３８は、システムテーブル１１２ａの認証タイプを元に処理を切り替える。また、レスポンス分析部１３８は、認証タイプが「ｎｕｌｌ」の場合は、そのシステムにはアクセス制限は存在しないので、応答内容をコンテンツ変換部１４１に渡す。
【００９１】
レスポンス分析部１３８の認証の結果、ログイン処理が成功しており、かつシステムテーブル１１２ａの認証タイプがフォームだった場合、レスポンス分析部１３８は応答内容をＷｅｂサーバ要求生成部１３６に渡す。認証タイプがフォーム以外の場合、レスポンス分析部１３８はコンテンツ変換部１４１に応答内容を渡す。
【００９２】
さらに、レスポンス分析部１３８は、認証タイプが「ベーシック」の場合はサーバ応答のＨＴＴＰヘッダを調べ、ＵＮＡＵＴＨＯＲＩＺＥＤか否かを確認する。レスポンス分析部１３８は、ＵＮＡＵＴＨＯＲＩＺＥＤの場合は認証処理判定部１３９へ応答内容を渡す。それ以外の場合は、レスポンス分析部１３８はコンテンツ変換部１４１に応答内容を渡す。
【００９３】
認証タイプが「フォーム」の場合、レスポンス分析部１３８はレスポンス分析・ログイン命令テーブル１１２ｂを参照する。認証識別情報の項を用い、応答ヘッダ中のレスポンスコード、特定の識別ヘッダ、固有のコンテンツ識別内容データを比較する。これらが一致した場合は、レスポンス分析部１３８は該当するＷｅｂサーバから認証上の問題でアクセス拒否されたとみなし、認証処理判定部１３９に応答内容を渡す。それ以外は、レスポンス分析部１３８はコンテンツ変換部１４１に応答内容を渡す。
【００９４】
認証処理判定部１３９はセッション情報テーブル１２１を調べ、現在の通信要求者がプロキシサーバへの認証を経ているか確認する。セッション情報テーブル１２１に当該ユーザ名が存在しない場合はプロキシサーバ認証要求部１３３に処理を移す。存在する場合はログイン処理命令生成部１４０に移る。
【００９５】
ログイン処理命令生成部１４０は、システムテーブル１１２ａの現在のシステムＩＤ（要求されたＵＲＬに対応するシステムＩＤ）と一致するユーザ名（通信要求を出したユーザのユーザ名）／パスワードの組をユーザ情報テーブル１１１から得る。また、ログイン処理命令生成部１４０は、システムテーブル１１２ａを調べ、認証タイプによって処理を切り替える。
【００９６】
認証タイプが「ベーシック」だった場合、ログイン処理命令生成部１４０は、先にユーザ情報テーブル１１１から得た、特定のＷｅｂサーバ向けのユーザ名／パスワードをＨＴＴＰのベーシック認証に対応した送信用データを生成する。
【００９７】
認証タイプが”フォーム”だった場合、ログイン処理命令生成部１４０はレスポンス分析・ログイン命令テーブル１１２ｂのログイン処理情報の項の情報とユーザ情報テーブル１１１から得た、特定のＷｅｂサーバ向けのユーザ名／パスワードを組み合わせ、ＨＴＴＰのフォーム通信のデータを生成する。
【００９８】
ログイン処理命令生成部１４０は、ログイン処理用に生成した送信データをＷｅｂサーバ通信部１３７より該当するＵＲＬに送信する。Ｗｅｂサーバからの応答は上記と同様レスポンス分析部１３８で分析される。
【００９９】
コンテンツ変換部１４１は、応答内容をレスポンス分析部１３８から受け取ったとき、その応答がコンテンツ書き換えの条件を満たす場合、Ｗｅｂサーバ３１ａ，３２ａからの応答の内容（ＨＴＭＬ文書）を書き換える。書き換えの際には、現在の利用者の情報をセッション情報テーブル１２１とユーザ情報テーブル１１１を使って、ユーザ毎に異なるＨＴＭＬ変換を実施する。
【０１００】
ブラウザ応答生成部１４２は、コンテンツ変換部１４１より得たＷｅｂサーバからの応答に、セッション情報テーブル１２１から得た情報を元に生成したプロキシサーバ認証情報を含んだＨＴＴＰクッキーを組み合わせ、リモートＷｅｂブラウザに送信する。
【０１０１】
以上のような構成のシステムにおける処理をフローチャートを参照して説明する。
図９は、代理認証処理の手順を示す第１のフローチャートである。これは、Ｗｅｂブラウザ１１ａからＷｅｂサーバ３１ａにアクセスする場合の例である。以下、図９に示す処理をステップ番号に沿って説明する。
【０１０２】
［ステップＳ１１］Ｗｅｂブラウザ１１ａは、ユーザからの操作入力によるＷｅｂサーバ３１ａへのアクセス指示を受け付ける。たとえば、表示画面からＷｅｂサーバ３１ａのＵＲＬが関連付けられたアンカー表示の選択入力（マウスによるクリック等）を受け付ける。
【０１０３】
［ステップＳ１２］Ｗｅｂブラウザ１１ａは、プロキシサーバ１００に対して、Ｗｅｂサーバ３１ａへのアクセス要求（ブラウザ要求）を送信する。
［ステップＳ１３］プロキシサーバ１００では、ブラウザ入力受付部１３１がブラウザ要求を受信する。
【０１０４】
［ステップＳ１４］プロキシサーバ１００において、指定されたＵＲＬに基づき、アクセス対象のＷｅｂサーバ３１ａに対応した認証許否確認論理とログイン処理論理（認証手続き）とを取得する。認証許否確認論理は、システムテーブル１１２ａの認証タイプと、レスポンス分析・ログイン命令テーブル１１２ｂにおける認証識別情報とによって特定される。ログイン処理論理は、システムテーブル１１２ａの認証タイプと、レスポンス分析・ログイン命令テーブル１１２ｂのログイン処理情報とによって特定される。
【０１０５】
［ステップＳ１５］プロキシサーバ１００は、アクセス要求内のセッションを特定するクッキーの有無を確認する。そして、プロキシサーバ１００は、クッキーが有る場合、該当するセッションがセッション情報テーブル１２１に登録されているか否かを判断する。該当するセッションが有る場合、処理がステップＳ１６に進められる。該当するセッションが無い場合、処理がステップＳ１７に進められる。
【０１０６】
［ステップＳ１６］プロキシサーバ１００は、セッション情報テーブル１２１内の該当するセッションの情報からユーザ名を取得する。その後、処理がステップＳ３１（図１０参照）に進められる。
【０１０７】
［ステップＳ１７］プロキシサーバ１００は、受信したアクセス要求にＡｕｔｈｏｒｉｚｅｄヘッダが含まれるか否かを判断する。Ａｕｔｈｏｒｉｚｅｄヘッダは、Ｗｅｂブラウザ１１ａがユーザ認証情報を送信するために付加する情報である。Ｗｅｂブラウザ１１ａは、プロキシ認証レスポンスを受け取ったときに、プロキシサーバ１００へのユーザ認証情報（ユーザ名とパスワード）をＡｕｔｈｏｒｉｚｅｄヘッダに含めて、アクセス要求をプロキシサーバ１００に送信するように設計されている。Ａｕｔｈｏｒｉｚｅｄヘッダが含まれる場合には、処理がステップＳ１８に進められる。Ａｕｔｈｏｒｉｚｅｄヘッダが含まれない場合には、処理がステップＳ３１（図１０参照）に進められる。
【０１０８】
［ステップＳ１８］プロキシサーバ１００は、アクセス要求からＡｕｔｈｏｒｉｚｅｄヘッダからユーザ名／パスワード取得を取得する。
［ステップＳ１９］プロキシサーバ１００は、ユーザ情報テーブル１１１を参照し、ユーザ情報を取得する。具体的には、プロキシサーバ１００は、Ａｕｔｈｏｒｉｚｅｄヘッダに含まれていたユーザ名を、ユーザ情報テーブル１１１のプロキシサーバ認証情報のユーザ名の欄から検索する。そして、プロキシサーバ１００は、該当するユーザ名に対応付けられたパスワードを取得する。
【０１０９】
［ステップＳ２０］プロキシサーバ１００は、認証が成功したか否かを判断する。具体的には、プロキシサーバ１００は、Ａｕｔｈｏｒｉｚｅｄヘッダに含まれていたユーザ認証情報と一致するプロキシサーバ認証情報がユーザ情報テーブル１１１に登録されていれば、認証成功と判断する。該当するユーザ名がユーザ情報テーブル１１１に登録されていないか、該当するユーザ名のパスワードが異なっている場合には、認証失敗と判断する。認証が成功した場合、処理がステップＳ２２に進められる。認証失敗の場合、処理がステップＳ２１に進められる。
【０１１０】
［ステップＳ２１］認証に失敗した場合、プロキシサーバ１００は、プロキシ認証レスポンスを生成し、Ｗｅｂブラウザ１１ａに返信する。プロキシ認証レスポンスとは、プロキシサーバへのユーザ認証手続きを要求するパケットである。その後、処理が終了し、Ｗｅｂブラウザ１１ａからの要求を待つ。
【０１１１】
［ステップＳ２２］認証に成功した場合、プロキシサーバ１００は、セッションを生成する。生成したセッションには、ユニークなセッションＩＤが付与される。
【０１１２】
［ステップＳ２３］プロキシサーバ１００は、生成したセッションにユーザ情報を登録する。具体的には、プロキシサーバ１００は、生成したセッションに付与されたセッションＩＤに対し、ユーザ名、ログイン時刻、およびタイムアウト予定時刻を関連付けて、セッション情報テーブル１２１に登録する。ログイン時刻は、セッションの生成時刻である。タイムアウト予定時刻は、たとえば、セッション生成から所定の時間後の時刻を設定する。
【０１１３】
図１０は、代理認証処理の手順を示す第２のフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
［ステップＳ３１］プロキシサーバ１００は、ブラウザからのアクセス要求を受け取り、内部に保存する。
【０１１４】
［ステップＳ３２］プロキシサーバ１００は、Ｗｅｂサーバ３１ａのＵＲＬ（実ＵＲＬ）を取得し、Ｗｅｂサーバへのアクセス要求を生成する。生成されたアクセス要求は、プロキシサーバ１００によってＷｅｂサーバ３１ａに送信される。
【０１１５】
［ステップＳ３３］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答を受信する。
［ステップＳ３４］プロキシサーバ１００は、応答内容を解析し、Ｗｅｂサーバ３１ａによる処理結果を判定する。具体的には、プロキシサーバ１００は、システムテーブル１１２ａを参照し、Ｗｅｂサーバ３１ａの認証タイプを判断する。たとえば、プロキシサーバ１００は、認証タイプがベーシックであり、Ｗｅｂサーバ３１ａからの応答のＨＴＴＰヘッダがＵＮＡＵＴＨＯＲＩＺＥＤであれば、ベーシック認証の手続きが必要であると判断する。また、プロキシサーバ１００は、認証タイプがフォームの場合、レスポンス分析・ログイン命令テーブル１１２ｂを参照し、応答内容が該当するシステムＩＤに対応する認証識別情報に合致する場合には、フォーム認証の手続きが必要であるものと判断する。
【０１１６】
［ステップＳ３５］プロキシサーバ１００は、アクセスが許可されたか否かを判断する。すなわち、ベーシックやフォームの認証手続きを必要と判断するための条件のいずれにも該当しなければ、アクセスが許可されたものと判断される。アクセスが許可された場合、処理がステップＳ６１（図１２参照）に進められる。アクセスが許否された場合、処理がステップＳ４１（図１１参照）に進められる。
【０１１７】
図１１は、代理認証処理の手順を示す第３のフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］プロキシサーバ１００は、Ｗｅｂサーバ３１ａへのアクセスが拒否された場合、セッション情報テーブル１２１を参照し、Ｗｅｂブラウザ１１ａを介してアクセス要求を出したユーザのユーザ名に対応するセッションの有無を判断する。セッションがない場合、処理がステップＳ４２に進められる。セッションがある場合、処理がステップＳ４４に進められる。
【０１１８】
［ステップＳ４２］セッションがない場合、プロキシサーバ認証要求部１３３が、Ｗｅｂサーバ３１ａから受信したクッキーをＷｅｂブラウザ１１ａのプロキシ認証レスポンス（応答内容）に設定する。
【０１１９】
［ステップＳ４３］プロキシサーバ１００は、プロキシ認証レスポンスを生成し、Ｗｅｂブラウザ１１ａに返信する。その後、処理が終了する。
［ステップＳ４４］セッションがある場合、プロキシサーバ１００へのユーザ認証が完了しているため、プロキシサーバ１００は、セッション情報テーブル１２１からユーザ情報（ユーザ名等）を取得する。
【０１２０】
［ステップＳ４５］プロキシサーバ１００は、ユーザ情報テーブル１１１からＷｅｂサーバ３１ａにログインするためのユーザ認証情報を取得する。具体的には、プロキシサーバ１００は、ステップＳ４４で取得したユーザ名に対応付けて設定されているＷｅｂブラウザ３１ａ（システムＩＤで判別する）のユーザ名とパスワードとを取得する。
【０１２１】
［ステップＳ４６］プロキシサーバ１００は、ログインリクエストを生成する。
［ステップＳ４７］プロキシサーバ１００は、システムテーブル１１２ａを参照し、ベーシック認証か否かを判断する。ベーシック認証の場合、処理がステップＳ４８に進められる。ベーシック認証ではない場合、処理がステップＳ４９に進められる。
【０１２２】
［ステップＳ４８］プロキシサーバ１００は、保存してあるブラウザ要求を取り出し、ログインリクエストに組み合わせる。
［ステップＳ４９］プロキシサーバ１００は、Ｗｅｂサーバ３１ａへ要求（ログインリクエスト）を送信する。
【０１２３】
［ステップＳ５０］プロキシサーバ１００は、Ｗｅｂサーバ３１ａから応答された処理結果を受信する。
［ステップＳ５１］プロキシサーバ１００は、処理結果の内容を解析し、ログインに成功したか否かを判断する。ログインに成功した場合には、処理がステップＳ５４に進められる。ログインに失敗した場合には、処理がステップＳ５２に進められる。
【０１２４】
［ステップＳ５２］ログインに失敗した場合、プロキシサーバ１００は、エラーメッセージを生成する。
［ステップＳ５３］プロキシサーバ１００は、エラーメッセージを含む例外を発生させ、処理を終了する。
【０１２５】
［ステップＳ５４］プロキシサーバ１００は、成功したログイン処理がベーシック認証か否かを判断する。ベーシック認証の場合、処理がステップＳ３１（図１０参照）に進められる。ベーシック認証では無い場合、処理がステップＳ５５に進められる。
【０１２６】
［ステップＳ５５］プロキシサーバ１００は、通信状態保持部１３４から保存済のブラウザからの要求を取り出す。その後、処理がステップＳ３１（図１０参照）に進められる。
【０１２７】
次に、ステップＳ３５においてアクセスが許可されたと判断されたときの処理について説明する。
図１２は、代理認証処理の手順を示す第４のフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
【０１２８】
［ステップＳ６１］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答が書き換え対象か否かを、Ｗｅｂサーバ３１ａのＵＲＬから判断する。書き換え対象の場合、処理がステップＳ６２に進められる。書き換え対処ではない場合、処理がステップＳ６３に進められる。
【０１２９】
［ステップＳ６２］プロキシサーバ１００は、コンテンツの書き換えを行う。書き換え方法は、たとえば、ＵＲＬに対応付けて予め定義されている。
［ステップＳ６３］プロキシサーバ１００は、書き換えたコンテンツをブラウザレスポンスとして設定する。
【０１３０】
［ステップＳ６４］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからのレスポンスヘッダをブラウザレスポンスに設定する。
［ステップＳ６５］プロキシサーバ１００は、送信相手のＷｅｂブラウザに対応するセッションがあるか否かを判断する。セッションがあれば、処理がステップＳ６６に進められる。セッションがなければ、処理がステップＳ６７に進められる。
【０１３１】
［ステップＳ６６］プロキシサーバ１００は、プロキシのセッションＩＤを応答クッキーに埋め込む。
［ステップＳ６７］プロキシサーバ１００は、Ｗｅｂブラウザ１１ａに対して応答を送信する。
【０１３２】
［ステップＳ６８］Ｗｅｂブラウザ１１ａは、アクセスの結果を表示する。
以上のようにして、プロキシサーバ１００において代理認証が行われる。
次に、Ｗｅｂブラウザ１１ａによりプロキシサーバ１００にログインし、Ｗｅｂサーバ３１ａ等にアクセスする際の流れを具体的に説明する。以下の例では、Ｗｅｂサーバでベーシック認証を行う場合と、フォーム認証を行う場合とについて説明する。また、Ｗｅｂサーバ３１ａの名称を「ＷｅｂサーバＡ」、Ｗｅｂサーバ３２ａの名称を「ＷｅｂサーバＢ」とする。
【０１３３】
図１３は、Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第１のシーケンス図である。図１３は、プロキシサーバ１００にログインしていないＷｅｂブラウザ１１ａからの要求に対して、プロキシ認証レスポンスを返すまでの処理である。以下、図１３に示す処理をステップ番号に沿って説明する。
【０１３４】
［ステップＳ７１］Ｗｅｂブラウザ１１ａは、プロキシサーバ１００に対する最初の要求を送信する。この例では、ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
【０１３５】
［ステップＳ７２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。最初の要求では、Ａｕｔｈｏｒｉｚｅｄヘッダは含まれていない。Ａｕｔｈｏｒｉｚｅｄヘッダが無い場合、認証不要のリクエストであると仮定して処理が進められる。
【０１３６】
［ステップＳ７３］プロキシサーバ１００は、Ｗｅｂサーバ３１ａに要求を送信する。この例では、ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
［ステップＳ７４］Ｗｅｂサーバ３１ａは、プロキシサーバに対して応答「４０１（Ｕｎａｕｔｈｏｒｉｚｅｄ，ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ）」を返す。この例では、レスポンスコードが４０１の応答が返されている。この応答は、ベーシック認証が未完了であるためにアクセスを拒否したことを示している。
【０１３７】
［ステップＳ７５］プロキシサーバ１００は、レスポンスを解析する。
［ステップＳ７６］プロキシサーバ１００は、セッションの有無を確認する（ここで、プロキシサーバ１００とＷｅｂブラウザ１１ａとの間のセッションをＰＰＳセッションとする）。この段階では、Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインされていないため、セッションも存在していない。
【０１３８】
この例では、レスポンスコードが４０１であり（ログインを要求するレスポンス）、かつＰＰＳセッションが存在しない場合、プロキシサーバ１００へログイン処理が開始される。
【０１３９】
［ステップＳ７７］プロキシサーバ１００は、プロキシ認証レスポンス「Ｕｎａｕｔｈｏｒｉｚｅｄ，ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ」をＷｅｂブラウザ１１ａに送信する。
図１４は、Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第２のシーケンス図である。図１４は、Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインし、Ｗｅｂページを取得するまでの処理である。以下、図１４に示す処理をステップ番号に沿って説明する。
【０１４０】
［ステップＳ８１］Ｗｅｂブラウザ１１ａは、ユーザからのユーザ名とパスワードとの入力を受け付ける。
［ステップＳ８２］Ｗｅｂブラウザ１１ａは、Ａｕｔｈｏｒｉｚｅｄヘッダにユーザ認証情報を含めた要求「ＧＥＴ（ＵＲＬ＿Ｘ， Ａｕｔｈｏｒｉｚａｔｉｏｎ／ＰＰＳ）」を、プロキシサーバ１００に送信する。
【０１４１】
［ステップＳ８３］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダありと判断される。
［ステップＳ８４］プロキシサーバ１００は、セッション（ＰＰＳセッション）の有無を確認する。この時点では、セッションは存在しない。Ａｕｔｈｏｒｉｚｅｄヘッダがあってもセッションが存在しない場合、未認証であると判断される。
【０１４２】
なお、ステップＳ８３とステップＳ８４との処理は、順番が逆であってもよい。図９に示すフローチャートでは、セッションの確認（ステップＳ１５）の後、Ａｕｔｈｏｒｉｚｅｄヘッダを確認（ステップＳ１６）している。
【０１４３】
［ステップＳ８５］プロキシサーバ１００は、ユーザ名とパスワードとの組を照合（マッチング）する。照合が成功した場合、以下の処理が行われる。
［ステップＳ８６］プロキシサーバ１００は、セッションを生成する。
【０１４４】
［ステップＳ８７］プロキシサーバ１００は、Ｗｅｂサーバ３１ａ（ＳｕｂＳｙｓｔｅｍ）用のユーザ認証情報（認証キー）を取得する。
［ステップＳ８８］プロキシサーバ１００は、Ｗｅｂサーバ３１ａ用のＡｕｔｈｏｒｉｚｅｄヘッダを生成する。
【０１４５】
［ステップＳ８９］プロキシサーバ１００は、Ｗｅｂブラウザ１１ａから送られた要求からクッキー（ＰＰＳＣｏｏｋｉｅ）やプロキシサーバ１００へ認証するためのユーザ認証情報を取り除き、Ｗｅｂサーバ３１ａ用のユーザ認証情報を追加した要求「ＧＥＴ（ＵＲＬ＿Ｘ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／Ｓｕｂ）」を、Ｗｅｂサーバ３１ａに送信する。
【０１４６】
［ステップＳ９０］Ｗｅｂサーバ３１ａは、ユーザ認証情報に基づいてユーザ認証を行う。Ｗｅｂサーバ３１ａは、認証に成功すると、指定されたＷｅｂページ（ＵＲＬ＿Ｘのページ）をプロキシサーバ１００に送信する。なお、この送信のパケットのレスポンスコードは「２００」である。
【０１４７】
［ステップＳ９１］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。
［ステップＳ９２］プロキシサーバ１００は、Ｗｅｂサーバ３１ａから送られたＷｅｂページにプロキシサーバ１００用のクッキー（ＰＰＳＳＣｏｏｋｉｅ）を追加してＷｅｂブラウザ１１ａに送信する。このクッキーでは、プロキシサーバ１００のドメイン名と後方一致するＵＲＬへのアクセスの際に有効となるように設定されている。
【０１４８】
［ステップＳ９３］Ｗｅｂブラウザ１１ａは、受け取ったＷｅｂページを表示すると共に、プロキシサーバ１００から送られたクッキーを保存する。
以上のようにして、Ｗｅｂブラウザ１１ａを使用するユーザは、プロキシサーバ１００へログインするだけで、Ｗｅｂサーバ３１ａへのアクセスが可能となる。
【０１４９】
次に、引き続き同じＷｅｂサーバ３１ａにアクセスする際の処理手順を説明する。
図１５は、ベーシック認証を完了したＷｅｂサーバへのアクセス手順を示すシーケンス図である。以下、図１５に示す処理をステップ番号に沿って説明する。
【０１５０】
［ステップＳ１０１］Ｗｅｂブラウザ１１ａは、ユーザの操作入力に応答してＷｅｂページ（ＵＲＬ＿Ｙ）の取得要求「ＧＥＴ（ＵＲＬ＿Ｙ，ＰＰＳＣｏｏｋｉｅ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／ＰＰＳ）」をプロキシサーバ１００に送信する。この要求には、ステップＳ９２（図１４参照）で保存したクッキーやプロキシサーバ１００へログインするためのユーザ認証情報が含まれる。
【０１５１】
［ステップＳ１０２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダありと判断される。
［ステップＳ１０３］プロキシサーバ１００は、セッション（ＰＰＳセッション）の有無を確認する。この例ではすでにセッションが存在するため、認証済と判断され、以下の処理が行われる。
【０１５２】
［ステップＳ１０４］プロキシサーバ１００は、Ｗｅｂサーバ３１ａ（ＳｕｂＳｙｓｔｅｍ）用のユーザ認証情報（認証キー）を取得する。
［ステップＳ１０５］プロキシサーバ１００は、Ｗｅｂサーバ３１ａ用のＡｕｔｈｏｒｉｚｅｄヘッダを生成する。
【０１５３】
［ステップＳ１０６］プロキシサーバ１００は、Ｗｅｂブラウザ１１ａから送られた要求からクッキー（ＰＰＳＣｏｏｋｉｅ）やプロキシサーバ１００へ認証するためのユーザ認証情報を取り除き、Ｗｅｂサーバ３１ａ用のユーザ認証情報を追加した要求「ＧＥＴ（ＵＲＬ＿Ｙ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／ａ：Ｓｕｂ）」を生成する。そして、生成した要求をＷｅｂサーバ３１ａに送信する。
【０１５４】
［ステップＳ１０７］Ｗｅｂサーバ３１ａは、指定されたＷｅｂページ（ＵＲＬ＿Ｙのページ）をプロキシサーバ１００に送信する。
［ステップＳ１０８］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。アクセスが拒否されていないので、以下の処理に進める。
【０１５５】
［ステップＳ１０９］プロキシサーバ１００は、Ｗｅｂサーバ３１ａから送られたＷｅｂページにプロキシサーバ１００用のクッキー（ＰＰＳＳＣｏｏｋｉｅ）を追加してＷｅｂブラウザ１１ａに送信する。
【０１５６】
次に、プロキシサーバ１００へのログイン完了後に、新たなＷｅｂサーバにアクセスする場合の例を説明する
図１６は、ベーシック認証を必要とする新たなＷｅｂサーバへのアクセス手順を示すシーケンス図である。以下、図１６に示す処理をステップ番号に沿って説明する。
【０１５７】
［ステップＳ１１１］Ｗｅｂブラウザ１１ａは、ユーザの操作入力に応答してＷｅｂページ（ＵＲＬ＿ｘ）の取得要求「ＧＥＴ（ＵＲＬ＿ｘ，ＰＰＳＣｏｏｋｉｅ）」をプロキシサーバ１００に送信する。この要求には、ステップＳ９２（図１４参照）で保存したクッキーが含まれる。なお、以前と異なるＷｅｂサーバ３２ａへの要求なので、Ａｕｔｈｏｒｉｚｅｄヘッダは送られない。また、送信アドレスが仮想アドレスであるため、プロキシサーバ１００用のクッキーの適用範囲内であると判断され、そのクッキーが要求に含められている。
【０１５８】
［ステップＳ１１２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダなしと判断され、認証不要な要求と仮定して以降の処理が進められる。
【０１５９】
［ステップＳ１１３］プロキシサーバ１００は、Ｗｅｂサーバ３２ａに対して、要求を転送する。この要求では、プロキシサーバ１００用のクッキーは取り除かれている。
【０１６０】
［ステップＳ１１４］Ｗｅｂサーバ３２ａは、ユーザ認証を要求する応答をプロキシサーバ１００に返す。この応答のレスポンスコードは「４０１」である。
［ステップＳ１１５］プロキシサーバ１００は、応答を解析し、ユーザ認証が要求されていることを認識する。具体的には、レスポンスコードが「４０１」であることを検出し、ベーシック認証が要求されていることを認識する。
【０１６１】
［ステップＳ１１６］プロキシサーバ１００は、セッションの有無を確認する。この例では、既にセッションが存在するため、Ｗｅｂブラウザ１１ａへのユーザ認証用のダイアログ等の表示を行わず、以下のような自動認証処理を行う。
【０１６２】
［ステップＳ１１７］プロキシサーバ１００は、Ｗｅｂサーバ３２ａ用のユーザ認証情報を取得する。
［ステップＳ１１８］プロキシサーバ１００は、Ｗｅｂサーバ３２ａ用のＡｕｔｈｏｒｉｚｅｄヘッダを生成する。
【０１６３】
［ステップＳ１１９］プロキシサーバ１００は、Ｗｅｂブラウザ１１ａから送られた要求からクッキー（ＰＰＳＣｏｏｋｉｅ）やプロキシサーバ１００へ認証するためのユーザ認証情報を取り除き、Ｗｅｂサーバ３２ａ用のユーザ認証情報を追加した要求「ＧＥＴ（ＵＲＬ＿ｘ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／ｂ：ＳＵＢ）」を、Ｗｅｂサーバ３２ａに送信する。
【０１６４】
［ステップＳ１２０］Ｗｅｂサーバ３２ａは、ユーザ認証情報に基づいてユーザ認証を行う。Ｗｅｂサーバは、認証に成功すると、指定されたＷｅｂページ（ＵＲＬ＿ｘのページ）をプロキシサーバ１００に送信する。
【０１６５】
［ステップＳ１２１］プロキシサーバ１００は、Ｗｅｂサーバからの応答（レスポンス）を解析する。アクセスが拒否されていないので、以下の処理に進める。
【０１６６】
［ステップＳ１２２］プロキシサーバ１００は、Ｗｅｂサーバ３２ａから送られたＷｅｂページをＷｅｂブラウザ１１ａに送信する。
このように、既にプロキシサーバ１００にログインしていれば、新たなＷｅｂサーバ３２ａにアクセスする場合であってもユーザ認証情報の入力は不要となる。
【０１６７】
次に、フォーム認証を行う際の手順を説明する。
図１７は、Ｗｅｂサーバでフォーム認証を行う場合の処理手順を示す第１のシーケンス図である。図１７は、プロキシサーバ１００にログインしていないＷｅｂブラウザ１１ａからの要求に対して、プロキシ認証レスポンスを返すまでの処理である。以下、図１７に示す処理をステップ番号に沿って説明する。
【０１６８】
［ステップＳ１３１］Ｗｅｂブラウザ１１ａは、プロキシサーバ１００に対する最初の要求を送信する。この例では、ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
【０１６９】
［ステップＳ１３２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。最初の要求では、Ａｕｔｈｏｒｉｚｅｄヘッダは含まれていない。Ａｕｔｈｏｒｉｚｅｄヘッダが無い場合、認証不要のリクエストであると仮定して処理が進められる。
【０１７０】
［ステップＳ１３３］プロキシサーバ１００は、Ｗｅｂサーバ３１ａにする要求を送信する。この例では、ＧＥＴ要求「ＧＥＴ（ＵＲＬ＿Ｘ）」を送信している。
［ステップＳ１３４］Ｗｅｂサーバ３１ａは、プロキシサーバに対して応答を返す。この例では、要求拒否の応答（ＮＧレスポンス（ＳＳＳＣｏｏｋｉｅ））が返されている。要求拒否の応答には、クッキー（ＳＳＳＣｏｏｋｉｅ）が含まれる。この応答は、フォーム認証が未完了であるためにアクセスを拒否したことを示している。
【０１７１】
［ステップＳ１３５］プロキシサーバ１００は、レスポンスを解析する。
［ステップＳ１３６］プロキシサーバ１００は、セッションの有無を確認する（ここで、プロキシサーバ１００とＷｅｂブラウザ１１ａとの間のセッションをＰＰＳセッションとする）。この段階では、Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインされていないため、セッションも存在していない。
【０１７２】
この例では、要求拒否の応答が返され、かつＰＰＳセッションが存在しない場合、プロキシサーバ１００へログイン処理が開始される。
［ステップＳ１３７］プロキシサーバ１００は、プロキシ認証レスポンス「Ｕｎａｕｔｈｏｒｉｚｅｄ，ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ」をＷｅｂブラウザ１１ａに送信する。
【０１７３】
図１８は、Ｗｅｂサーバでフォーム認証を行う場合の処理手順を示す第２のシーケンス図である。図１８は、Ｗｅｂブラウザ１１ａからプロキシサーバ１００にログインし、Ｗｅｂページを取得するまでの処理である。以下、図１８に示す処理をステップ番号に沿って説明する。
【０１７４】
［ステップＳ１４１］Ｗｅｂブラウザ１１ａは、ユーザからのユーザ名とパスワードとの入力を受け付ける。
［ステップＳ１４２］Ｗｅｂブラウザ１１ａは、Ａｕｔｈｏｒｉｚｅｄヘッダにユーザ認証情報を含めた要求「ＧＥＴ（ＵＲＬ＿Ｘ， Ａｕｔｈｏｒｉｚａｔｉｏｎ／ＰＰＳ）」を、プロキシサーバ１００に送信する。
【０１７５】
［ステップＳ１４３］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダありと判断される。
［ステップＳ１４４］プロキシサーバ１００は、セッション（ＰＰＳセッション）の有無を確認する。この時点では、セッションは存在しない。Ａｕｔｈｏｒｉｚｅｄヘッダがあってもセッションが存在しない場合、未認証であると判断される。
【０１７６】
なお、ステップＳ１４３とステップＳ１４４との処理は、順番が逆であってもよい。図９に示すフローチャートでは、セッションの確認（ステップＳ１５）の後、Ａｕｔｈｏｒｉｚｅｄヘッダを確認（ステップＳ１６）している。
【０１７７】
［ステップＳ１４５］プロキシサーバ１００は、ユーザ名とパスワードとの組を照合（マッチング）する。照合が成功した場合、以下の処理が行われる。
［ステップＳ１４６］プロキシサーバ１００は、セッションを生成する。
【０１７８】
［ステップＳ１４７］プロキシサーバ１００は、Ｗｅｂサーバ３１ａ（ＳｕｂＳｙｓｔｅｍ）用のユーザ認証情報（認証キー）を取得する。
［ステップＳ１４８］プロキシサーバ１００は、Ｗｅｂサーバ３１ａに対してログイン要求「ＰＯＳＴ（ＵＲＬ＿Ｌｏｇｉｎ， Ｕｓｅｒ，Ｐａｓｓ， ＳＳＳＣｏｏｋｉｅ）」を送信する。このログイン要求には、ユーザ認証情報（Ｕｓｅｒ，Ｐａｓｓ）やクッキー（ＳＳＳＣｏｏｋｉｅ）が含まれる。
【０１７９】
［ステップＳ１４９］Ｗｅｂサーバ３１ａは、ユーザ認証情報に基づいてユーザ認証を行う。Ｗｅｂサーバ３１ａは、認証に成功すると、認証後に送信すべきものとして予め設定されているＷｅｂページをプロキシサーバ１００に送信する。なお、この送信のパケットのレスポンスコードは「２００」である。
【０１８０】
［ステップＳ１５０］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。これにより、Ｗｅｂサーバ３１ａに対するログインが成功したことが認識される。
【０１８１】
「ステップＳ１５１］プロキシサーバ１００は、最初にＷｅｂブラウザ１１ａから送られた要求にＷｅｂサーバ３１ａ用のクッキー（ＳＳＳＣｏｏｋｉｅ）を追加して新たな要求「ＧＥＴ（ＵＲＬ＿Ｘ， ＳＳＳＣｏｏｋｉｅ）」を生成し、Ｗｅｂサーバ３１ａに対して送信する。
【０１８２】
［ステップＳ１５２］Ｗｅｂサーバ３１ａは、クッキー（ＳＳＳＣｏｏｋｉｅ）により、既に認証しているユーザからのアクセスであると認識し、要求されたＷｅｂページをプロキシサーバ１００に送信する。
【０１８３】
［ステップＳ１５３］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。
［ステップＳ１５４］プロキシサーバ１００は、Ｗｅｂサーバ３１ａから送られたＷｅｂページにＷｅｂサーバ３１ａ用のクッキー（ＳＳＳＣｏｏｋｉｅ）とプロキシサーバ１００用のクッキー（ＰＰＳＳＣｏｏｋｉｅ）とを追加してＷｅｂブラウザ１１ａに送信する。プロキシサーバ１００用のクッキーでは、プロキシサーバ１００のドメイン名と後方一致するＵＲＬへのアクセスの際に有効となるように設定されている。
【０１８４】
［ステップＳ１５５］Ｗｅｂブラウザ１１ａは、受け取ったＷｅｂページを表示すると共に、プロキシサーバ１００から送られたクッキーを保存する。
以上のようにして、Ｗｅｂブラウザ１１ａを使用するユーザは、プロキシサーバ１００へログインするだけで、Ｗｅｂサーバ３１ａへのアクセスが可能となる。
【０１８５】
次に、引き続き同じＷｅｂサーバ３１ａにアクセスする際の処理手順を説明する。
図１９は、フォーム認証を完了したＷｅｂサーバへのアクセス手順を示すシーケンス図である。以下、図１９に示す処理をステップ番号に沿って説明する。
【０１８６】
［ステップＳ１６１］Ｗｅｂブラウザ１１ａは、ユーザの操作入力に応答してＷｅｂページ（ＵＲＬ＿Ｙ）の取得要求「ＧＥＴ（ＵＲＬ＿Ｙ，ＰＰＳＣｏｏｋｉｅ，Ａｕｔｈｏｒｉｚａｔｉｏｎ／ＰＰＳ）」をプロキシサーバ１００に送信する。この要求には、ステップＳ１５５（図１８参照）で保存したクッキーやプロキシサーバ１００へログインするためのユーザ認証情報が含まれる。
【０１８７】
［ステップＳ１６２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダありと判断される。
［ステップＳ１６３］プロキシサーバ１００は、セッション（ＰＰＳセッション）の有無を確認する。この例ではすでにセッションが存在するため、認証済と判断され、以下の処理が行われる。
【０１８８】
［ステップＳ１６４］プロキシサーバ１００は、Ｗｅｂブラウザ１１ａから送られた要求にＷｅｂサーバ３１ａ用のユーザ認証情報を追加した要求「ＧＥＴ（ＵＲＬ＿Ｙ，ＳＳＳＣｏｏｋｉｅ）」を生成し、Ｗｅｂサーバ３１ａに送信する。
【０１８９】
［ステップＳ１６５］Ｗｅｂサーバ３１ａは、指定されたＷｅｂページ（ＵＲＬ＿Ｙのページ）をプロキシサーバ１００に送信する。
［ステップＳ１６６］プロキシサーバ１００は、Ｗｅｂサーバ３１ａからの応答（レスポンス）を解析する。アクセスが拒否されていないので、以下の処理に進める。
【０１９０】
［ステップＳ１６７］プロキシサーバ１００は、Ｗｅｂサーバ３１ａから送られたＷｅｂページをＷｅｂブラウザ１１ａに送信する。
次に、プロキシサーバ１００へのログイン完了後に、新たなＷｅｂサーバにアクセスする場合の例を説明する。
【０１９１】
図２０は、フォーム認証を必要とする新たなＷｅｂサーバへのアクセス手順を示すシーケンス図である。以下、図２０に示す処理をステップ番号に沿って説明する。
【０１９２】
［ステップＳ１７１］Ｗｅｂブラウザ１１ａは、ユーザの操作入力に応答してＷｅｂページ（ＵＲＬ＿ｘ）の取得要求「ＧＥＴ（ＵＲＬ＿ｘ，ＰＰＳＳＣｏｏｋｉｅ）」をプロキシサーバ１００に送信する。この要求には、ステップＳ１５５（図１８参照）で保存したクッキーが含まれる。なお、以前と異なるＷｅｂサーバ３２ａへの要求なので、Ａｕｔｈｏｒｉｚｅｄヘッダは送られない。また、送信アドレスが仮想アドレスであるため、プロキシサーバ１００用のクッキーの適用範囲内であると判断され、そのクッキーが要求に含められている。
【０１９３】
［ステップＳ１７２］プロキシサーバ１００では、Ａｕｔｈｏｒｉｚａｔｉｏｎ（Ａｕｔｈｏｒｉｚｅｄヘッダ）の確認が行われる。このとき、Ａｕｔｈｏｒｉｚｅｄヘッダなしと判断され、認証不要な要求と仮定して以降の処理が進められる。
【０１９４】
［ステップＳ１７３］プロキシサーバ１００は、Ｗｅｂサーバ３２ａに対して、要求を転送する。この要求では、プロキシサーバ１００用のクッキーは取り除かれている。
【０１９５】
［ステップＳ１７４］Ｗｅｂサーバ３２ａは、ユーザ認証を要求する応答をプロキシサーバ１００に返す。この例では、要求拒否の応答（ＮＧレスポンス（ＳＳＳＣｏｏｋｉｅ））が返されている。要求拒否の応答には、クッキー（ＳＳＳＣｏｏｋｉｅ）が含まれる。この応答は、フォーム認証が未完了であるためにアクセスを拒否したことを示している。
【０１９６】
［ステップＳ１７５］プロキシサーバ１００は、応答を解析し、ユーザ認証が要求されていることを認識する。
［ステップＳ１７６］プロキシサーバ１００は、セッションの有無を確認する。この例では、既にセッションが存在するため、Ｗｅｂブラウザ１１ａへのユーザ認証用のダイアログ等の表示を行わず、以下のような自動認証処理を行う。
【０１９７】
［ステップＳ１７７］プロキシサーバ１００は、Ｗｅｂサーバ３２ａ（ＳｕｂＳｙｓｔｅｍ）用のユーザ認証情報（認証キー）を取得する。
［ステップＳ１７８］プロキシサーバ１００は、Ｗｅｂサーバ３２ａに対してログイン要求「ＰＯＳＴ（ＵＲＬ＿Ｌｏｇｉｎ，ＳＳＳＣｏｏｋｉｅ）」を送信する。このログイン要求には、クッキー（ＳＳＳＣｏｏｋｉｅ）が含まれる。
【０１９８】
［ステップＳ１７９］Ｗｅｂサーバ３２ａは、ユーザ認証情報に基づいてユーザ認証を行う。Ｗｅｂサーバ３２ａは、認証に成功すると、認証後に送信すべきものとして予め設定されているＷｅｂページをプロキシサーバ１００に送信する。なお、この送信のパケットのレスポンスコードは「２００」である。
【０１９９】
［ステップＳ１８０］プロキシサーバ１００は、Ｗｅｂサーバ３２ａからの応答（レスポンス）を解析する。これにより、Ｗｅｂサーバ３２ａに対するログインが成功したことが認識される。
【０２００】
［ステップＳ１８１］プロキシサーバ１００は、最初にＷｅｂブラウザ１１ａから送られた要求にＷｅｂサーバ３２ａ用のクッキー（ＳＳＳＣｏｏｋｉｅ）を追加して新たな要求「ＧＥＴ（ＵＲＬ＿ｘ，ＳＳＳＣｏｏｋｉｅ）」を生成し、Ｗｅｂサーバ３２ａに対して送信する。
【０２０１】
［ステップＳ１８２］Ｗｅｂサーバ３２ａは、クッキー（ＳＳＳＣｏｏｋｉｅ）により、既に認証しているユーザからのアクセスであると認識し、要求されたＷｅｂページをプロキシサーバ１００に送信する。
【０２０２】
［ステップＳ１８３］プロキシサーバ１００は、Ｗｅｂサーバ３２ａからの応答（レスポンス）を解析する。
［ステップＳ１８４］プロキシサーバ１００は、Ｗｅｂサーバ３２ａから送られたＷｅｂページにＷｅｂサーバ３２ａ用のクッキー（ＳＳＳＣｏｏｋｉｅ）を追加してＷｅｂブラウザ１１ａに送信する。
【０２０３】
［ステップＳ１８５］Ｗｅｂブラウザ１１ａは、受け取ったＷｅｂページを表示すると共に、プロキシサーバ１００から送られたクッキーを保存する。
以上のように、ベーシック認証、フォーム認証等の認証方式に合わせて、代理認証を行うことができる。しかも、認証手順は予め定義されており、各Ｗｅｂサーバに対するユーザ毎のユーザ認証情報を保持しておくだけでよい。
【０２０４】
なお、ベーシック認証の認証手順とフォーム認証の認証手順とは、上記の手順で表された相違点以外に、送信データの生成方法も異なる。そこで、以下に、ログイン処理命令生成部１４０による認証方式毎の送信データ生成方法について説明する。
【０２０５】
図２１は、ベーシック認証時の送信データ生成手順を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳ２０１］ログイン処理命令生成部１４０は、ユーザ名とパスワードとの文字列の間に‘：’をいれて、それぞれを連結する。
【０２０６】
［ステップＳ２０２］ログイン処理命令生成部１４０は、連結した文字列を所定のアルゴリズムでエンコードする。たとえば、Ｂａｓｅ６４と呼ばれるアルゴリズムでエンコードする。
【０２０７】
［ステップＳ２０３］ログイン処理命令生成部１４０は、エンコードされた認証文字列の前に“Ｂａｓｉｃ”という文字列を挿入する。
［ステップＳ２０４］ログイン処理命令生成部１４０は、生成した文字列をヘッダ名「ＡＵＴＨＯＲＩＺＡＴＩＯＮ」と連結し、認証ヘッダを生成する。
【０２０８】
［ステップＳ２０５］ログイン処理命令生成部１４０は、通信状態保持部１３４からＵＲＬ、ヘッダ、ボディ情報を引き出す。
［ステップＳ２０６］ログイン処理命令生成部１４０は、ヘッダ部に認証ヘッダを挿入する。
【０２０９】
［ステップＳ２０７］ログイン処理命令生成部１４０は、Ｗｅｂサーバにヘッダを送信する。
［ステップＳ２０８］ログイン処理命令生成部１４０は、Ｗｅｂサーバにボディ情報を送信する。
【０２１０】
図２２は、フォーム認証時の送信データ生成手順を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。
［ステップＳ２１１］ログイン処理命令生成部１４０は、ユーザフォーム名とユーザ名とをフォームデータ生成情報保持テーブル１４０ａに登録する。
【０２１１】
ここで、フォームデータ生成情報保持テーブル１４０ａは、ログイン処理命令生成部１４０が保持するデータテーブルであり、フォーム名（ユーザフォーム名やパスワードフォーム名）と登録情報（ユーザ名やパスワード文字列）との組を登録することができる。
【０２１２】
［ステップＳ２１２］ログイン処理命令生成部１４０は、パスワードフォーム名とパスワード文字列との組を、フォームデータ生成情報保持テーブル１４０ａに登録する。
【０２１３】
［ステップＳ２１３］ログイン処理命令生成部１４０は、ステップＳ２１１とステップＳ２１２とで登録した各々の文字列を、ＵＲＬエンコードルールに従って変換する。
【０２１４】
［ステップＳ２１４］ログイン処理命令生成部１４０は、変換した文字列の間に‘＆’を挿入して連結する。
［ステップＳ２１５］ログイン処理命令生成部１４０は、通信状態保持部１３４からクッキー情報を取得する。
【０２１５】
［ステップＳ２１６］ログイン処理命令生成部１４０は、Ｗｅｂサーバに“Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ”ヘッダを送信する。
［ステップＳ２１７］ログイン処理命令生成部１４０は、Ｗｅｂサーバにクッキーヘッダを送信する。
【０２１６】
［ステップＳ２１８］ログイン処理命令生成部１４０は、Ｗｅｂサーバに認証フォームデータを送信する。
以上説明したように、プロキシサーバ１００が代理認証を行うことで、ユーザは、Ｗｅｂサーバ毎にログイン手続きを行う必要が無くなり、利便性が向上する。
【０２１７】
なお、上記の例では、プロキシサーバが代理認証を行っているが、この機能をクライアントに実装することもできる。
図２３は、代理認証機能を実装したクライアントの概念図である。図２３に示すように、クライアント２００にはブラウザプログラム２１０とプロキシプログラム２２０とが実装される。ブラウザプログラム２１０は、Ｗｅｂブラウザとしてクライアント２００を機能させるためのプログラムである。また、プロキシプログラム２２０は、プロキシサーバ１００の機能をクライアント２００で実現するためのプログラムである。プロキシプログラム２２０は、ユーザ情報テーブル２２１を有している。ユーザ情報テーブル２２１、各サーバ３１，３２，３３に実装されたＷｅｂサーバにログインするためのユーザ認証情報（ユーザ名とパスワード）が登録されている。
【０２１８】
なお、プロキシプログラム２２０は、クライアント２００のユーザの代理認証を行えばよい。そのため、クライアント２００のＯＳへ正しくログインしたユーザに対しては、プロキシプログラム２２０においてユーザ認証を行わなくてもよい。
【０２１９】
以上説明したように、本発明の実施の形態によれば、複数の認証を要するＷｅｂシステムを利用する際に、ユーザがログインを行う数が１回ですむ。
しかも、従来のシングルサインオンシステムとは異なり、認証を要しないＷｅｂページを使用する場合には、ユーザのログイン操作は０回になる。すなわち、従来のシングルサインオン技術では、予め代理認証システムにログインすることが前提となり、かならず１回のユーザ認証処理が発生する。ところが、本実施の形態によれば、Ｗｅｂサーバでのユーザ認証の要否をプロキシサーバが判断し、ユーザ認証を要求しないＷｅｂサーバへのアクセスで有ればプロキシサーバへのログインを要求しない。その結果、ユーザの操作性が向上する。
【０２２０】
また、本実施の形態では、ＷｅｂサーバのＵＲＬ毎にユーザ認証情報を管理しているため、同一サーバコンピュータ内に複数のＷｅｂサーバが実装されていたときでも、Ｗｅｂサーバ毎の代理認証が可能である。
【０２２１】
また、従来の代理認証技術には、認証通信を完全に記録しそのまま再現するタイプのものがある。この技術では、冗長な記憶領域を必要とした。一方、本実施の形態の方式では認証用の通信データをプログラムの計算処理によって生成するため、ユーザが増加した場合も記憶容量の増加はごく僅かである。
【０２２２】
また、本実施の形態ではＷｅｂサーバ側でセッションのタイムアウト発生によりそのセッションが停止しても、次回の該当するＷｅｂサーバへのアクセスの際に自動的にログインされセッションが再度確立することができる。そのため、Ｗｅｂサーバでのセッションのタイムアウトをユーザが意識せずにすむ。
【０２２３】
また、従来のシングルサインオンでは、シングルサインオンを実現するためのサーバが必要であり個人での運用・利用は困難だった。本実施の形態では、プロキシサーバの機能を用意にクライアントに実装することができ（図２３参照）、クライアント上でのシングルサインオンが実現可能となる。
【０２２４】
なお、既存のＷｅｂブラウザにはユーザの入力したユーザ名やパスワードを記憶し、パスワード入力の手間を削減する機構が存在する。しかし、この機能は個々のブラウザ毎に異なり、複数のブラウザを利用するユーザはユーザ名やパスワードのデータを共用できない。図２３に示すような単一ユーザ形態であれば、複数のブラウザで統一されたシングルサインオンを実現できる。
【０２２５】
ところで、上記の例では、Ｗｅｂサーバにアクセスする場合の例を用いて説明しているが、ネットワーク経由のユーザ認証を要求する他のアプリケーションに対しても同様の処理で代理認証を行うことができる。
【０２２６】
また、上記の例では、Ｗｅｂサーバがベーシック認証またはフォーム認証を要求する場合の例を示したが、他の認証方式に適用することもできる。その場合、適用すべき認証方式の判別基準をレスポンス分析・ログイン命令テーブル１１２ｂに設定するとともに、該当する認証方式への認証手順を定義しておく。ログイン処理命令生成部１４０は、定義された手順で代理認証の処理を実行する。
【０２２７】
なお、上記のプロキシサーバ１００や代理認証装置１の処理機能は、サーバコンピュータに所定の代理認証プログラムを実行させることにより実現することができる。その場合、プロキシサーバ１００等が有すべき機能の処理内容を記述した代理認証プログラムが提供される。サーバコンピュータは、クライアントコンピュータからの要求に応答して、代理認証プログラムを実行する。これにより、上記処理機能がサーバコンピュータ上で実現され、処理結果がクライアントコンピュータに提供される。
【０２２８】
処理内容を記述した代理認証プログラムは、サーバコンピュータで読み取り可能な記録媒体に記録しておくことができる。サーバコンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｃ）などがある。
【０２２９】
代理認証プログラムを流通させる場合には、たとえば、その代理認証プログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。
代理認証プログラムを実行するサーバコンピュータは、たとえば、可搬型記録媒体に記録された代理認証プログラムを、自己の記憶装置に格納する。そして、サーバコンピュータは、自己の記憶装置から代理認証プログラムを読み取り、代理認証プログラムに従った処理を実行する。なお、サーバコンピュータは、可搬型記録媒体から直接代理認証プログラムを読み取り、その代理認証プログラムに従った処理を実行することもできる。
【０２３０】
（付記１） 他の装置への認証手続きを代理する代理認証プログラムにおいて、
コンピュータに、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
処理を実行させることを特徴とする代理認証プログラム。
【０２３１】
（付記２） 前記ユーザ認証手続きでは、予め前記クライアント機能に対応付けて格納されている前記サーバ機能へのユーザ認証情報を、前記クライアント機能からの前記要求に付加して前記サーバ機能へ送信することを特徴とする付記１記載の代理認証プログラム。
【０２３２】
（付記３） 前記クライアント機能からの前記要求を記憶し、前記サーバ機能との間の前記ユーザ認証手続き完了後、記憶しておいた前記要求を前記サーバ機能に送信することを特徴とする付記１記載の代理認証プログラム。
【０２３３】
（付記４） ユーザ認証が未完了であることを示す前記応答を受け取った際に、前記クライアント機能との間のセッションの確立の有無を確認し、
前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、
ユーザ認証が完了すると前記クライアント機能との間にセッションを確立し、前記サーバ機能との間の前記ユーザ認証手続きを行う、
ことを特徴とする付記１記載の代理認証プログラム。
【０２３４】
（付記５） 前記クライアント機能からアクセス可能な前記サーバ機能が複数有る場合、前記サーバ機能毎の認証許否確認論理が設定されていることを特徴とする付記１記載の代理認証プログラム。
【０２３５】
（付記６） 前記認証許否確認論理では、前記サーバ機能が実装されている装置の識別情報と前記装置内での前記サーバ機能の所在を示す情報との組み合わせにより前記サーバ機能が特定されていることを特徴とする付記１記載の代理認証プログラム。
【０２３６】
（付記７） 他の装置への認証手続きを代理するための代理認証方法において、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
ことを特徴とする代理認証方法。
【０２３７】
（付記８） 他の装置への認証手続きを代理する代理認証装置において、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスするアクセス手段と、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する認証要否判断手段と、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、
を有することを特徴とする代理認証装置。
【０２３８】
（付記９） 他の装置への認証手続きを代理する代理認証プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
処理を実行させることを特徴とする代理認証プログラムを記録したコンピュータ読み取り可能な記録媒体。
【０２３９】
【発明の効果】
以上説明したように本発明では、複数の認証許否確認論理を予め定義しておき、サーバ機能からの応答に応じた認証許否確認論理を判断し、その認証許否確認論理に対応付けられた認証手順でサーバ機能に対するユーザ認証手続きを行うようにした。このように認証許否確認論理に応じた認証手順に基づいてユーザ認証が行われるため、複数のクライアントの代理認証を行う場合であっても、クライアント毎の認証手順を記憶する必要が無い。その結果、少ないハードウェア資源の利用で代理認証機能が実現可能となる。
【図面の簡単な説明】
【図１】実施の形態に適用される発明の概念図である。
【図２】本実施の形態を提供するネットワークシステムの構成例を示す図である。
【図３】プロキシサーバのハードウェア構成例を示す図である。
【図４】プロキシサーバの機能を示すブロック図である。
【図５】ユーザ情報テーブルのデータ構造例を示す図である。
【図６】システムテーブルのデータ構造例を示す図である。
【図７】レスポンス分析・ログイン命令テーブルのデータ構造例を示す図である。
【図８】セッション情報テーブルのデータ構造例を示す図である。
【図９】代理認証処理の手順を示す第１のフローチャートである。
【図１０】代理認証処理の手順を示す第２のフローチャートである。
【図１１】代理認証処理の手順を示す第３のフローチャートである。
【図１２】代理認証処理の手順を示す第４のフローチャートである。
【図１３】Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第１のシーケンス図である。
【図１４】Ｗｅｂサーバでベーシック認証を行う場合の処理手順を示す第２のシーケンス図である。
【図１５】ベーシック認証を完了したＷｅｂサーバへのアクセス手順を示すシーケンス図である。
【図１６】ベーシック認証を必要とする新たなＷｅｂサーバへのアクセス手順を示すシーケンス図である。
【図１７】Ｗｅｂサーバでフォーム認証を行う場合の処理手順を示す第１のシーケンス図である。
【図１８】Ｗｅｂサーバでフォーム認証を行う場合の処理手順を示す第２のシーケンス図である。
【図１９】フォーム認証を完了したＷｅｂサーバへのアクセス手順を示すシーケンス図である。
【図２０】フォーム認証を必要とする新たなＷｅｂサーバへのアクセス手順を示すシーケンス図である。
【図２１】ベーシック認証時の送信データ生成手順を示すフローチャートである。
【図２２】フォーム認証時の送信データ生成手順を示すフローチャートである。
【図２３】代理認証機能を実装したクライアントの概念図である。
【符号の説明】
１ 代理認証装置
２ クライアント
３ サーバ
１１，１２，１３，・・・ クライアント
３１，３２，３３，・・・ サーバ
１００ プロキシサーバ
１１０ データベース
１１１ ユーザ情報テーブル
１１２ Ｗｅｂサーバ情報
１１２ａ システムテーブル
１１２ｂ レスポンス分析・ログイン命令テーブル
１２１ セッション情報テーブル
１２２ タイマ
１２３ タイムアウト駆動部
１３１ ブラウザ入力受付部
１３２ プロキシサーバ認証部
１３３ プロキシサーバ認証要求部
１３４ 通信状態保持部
１３５ Ｗｅｂサーバ識別部
１３６ Ｗｅｂサーバ要求生成部
１３７ Ｗｅｂサーバ通信部
１３８ レスポンス分析部
１３９ 認証処理判定部
１４０ ログイン処理命令生成部
１４１ コンテンツ変換部
１４２ ブラウザ応答生成部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a proxy authentication program, a proxy authentication method, and a proxy authentication device that proxy an authentication procedure to another device, and more particularly to a proxy authentication program, a proxy authentication method, and a proxy authentication device that perform an authentication procedure using different authentication methods.
[0002]
[Prior art]
In a corporate network, a plurality of servers (or application programs that provide services) exist in the network, and various services are provided via the network. However, even in a corporate network, the usable users are limited for some functions. For example, for a system for managing employee attendance, it is necessary to permit access only to users in a predetermined position or higher or users in a predetermined department such as the personnel department. Hereinafter, a function (server application) that provides a service is referred to as a server function.
[0003]
In general, user authentication is performed for each server function in order to limit users who can use the service. In user authentication, the server function requests the user to input a user name and a password. If the set of the input user name and password is registered in advance in the server function, the server function provides a function within a range permitted for the user. In principle, such user authentication is performed individually even when a large number of server functions exist in the network.
[0004]
By the way, with the recent systematization of business processing, most of the internal business is performed using a server function that supports the business. Therefore, it is necessary to perform user authentication for various server functions when an employee performs business. In this case, in order to perform user authentication to individual server functions, each user must individually manage a combination of a user name and a password, and the management burden of passwords and the like is large. In addition, performing user authentication procedures many times a day leads to a reduction in work efficiency.
[0005]
Therefore, a system called single sign-on has been used conventionally. In single sign-on, a user can use a function that allows access to the user only by once being authenticated.
[0006]
One of techniques for realizing single sign-on is a technique using PKI (Public Key Infrastructure). PKI is a technology that secures secure electronic communication by combining an electronic signature and encryption technology. In the PKI system, an electronic certificate is issued to a user who has been authenticated. A user who holds the electronic certificate can receive various services according to the electronic certificate.
[0007]
Another technique for realizing single sign-on is a proxy authentication method using a proxy server. In this technique, data for user authentication for each server function is held in a proxy server. When a request for access to the server function is issued from the user, the proxy server performs a user authentication procedure with the server function as a proxy (see, for example, Patent Document 1).
[0008]
In addition, when the user terminal is authenticated once by accessing the Web server through the proxy server, the data is stored in the proxy server. The data stored in the proxy server is used at the next and subsequent logins by the same user terminal. According to this method, various types of login protocols can be handled (see, for example, Patent Document 2).
[0009]
[Patent Document 1]
Japanese Patent Laid-Open No. 10-177552 (FIG. 1)
[Patent Document 2]
Japanese Patent Laid-Open No. 2002-32340 (FIG. 1)
[0010]
[Problems to be solved by the invention]
However, in the case of a technology using PKI, both a Web browser and a Web server require a mechanism corresponding to an electronic certificate, and an infrastructure for the electronic certificate is required. Therefore, it is difficult to divert the existing system as it is.
[0011]
In other words, since a general authentication method using a proxy server uses a fixed authentication protocol, it cannot be adopted when the authentication method differs for each server function. Moreover, there are various types of authentication methods for actual Web servers because the developer is free. It is difficult for a single proxy authentication type proxy server to perform proxy authentication on them, reducing the usefulness of the proxy authentication proxy.
[0012]
For example, in the method described in
[0013]
Moreover, if it is a system shown in
[0014]
Generally, when the amount of necessary hardware resources is unknown, it is necessary to prepare a hardware environment with a margin for stable operation of the system. As a result, the scale of the system has been enlarged, and the construction cost of the system has increased.
[0015]
The present invention has been made in view of these points, and a proxy authentication program, a proxy authentication method, and a proxy that can perform proxy authentication to a server of a different authentication method by efficiently using hardware resources. An object is to provide an authentication device.
[0016]
[Means for Solving the Problems]
In order to solve the above-described problems, the present invention provides a proxy authentication program that causes a computer to execute the process shown in FIG. This proxy authentication program is for proxying an authentication procedure to another device, and causes the computer to execute the following processing.
[0017]
In response to a request from the client functions 2a, 2b, 2c,..., The computer accesses the server functions 3a, 3b, 3c,... Connected via the network (step S1). In the computer, a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that the user authentication is incomplete is defined in advance, and the response from the server function matches one of the plurality of authentication permission / rejection confirmation logics. Whether or not user authentication is necessary is determined based on whether or not (step S2). If user authentication is required, the computer performs a user authentication procedure with the server function according to an authentication procedure defined in advance in association with the authentication permission / inhibition confirmation logic to which the response is matched (step S3).
[0018]
According to such a proxy authentication program, when a computer accesses a server function in response to a request from a client function, if a response indicating that user authentication is not completed is returned, an authentication permission / inhibition confirmation logic to which the response matches. An authentication procedure is performed with the server function in accordance with the processing procedure corresponding to.
[0019]
Further, in a proxy authentication method for proxying an authentication procedure to another device in order to solve the above problem, a user connected to a server connected via a network in response to a request from a client function, and a user A plurality of authentication permission / rejection confirmation logics for identifying a response indicating that the authentication is incomplete is defined in advance, and whether the response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Therefore, if user authentication is required, user authentication is performed with the server function according to a predefined authentication procedure in association with the authentication permission confirmation logic to which the response is adapted. A proxy authentication method characterized by performing a procedure is provided.
[0020]
According to such a proxy authentication method, when the server function is accessed in response to a request from the client function, if a response indicating that the user authentication is not completed is returned, the response corresponds to an authentication permission confirmation logic that matches. An authentication procedure is performed with the server function in the processing procedure.
[0021]
In addition, in order to solve the above-mentioned problem, an access unit for accessing a server connected via a network in response to a request from a client function in a proxy authentication device proxying an authentication procedure to another device , A plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and a response from the server function matches one of the plurality of authentication permission / rejection confirmation logics Authentication necessity judging means for judging whether or not user authentication is necessary, and, if user authentication is necessary, according to an authentication procedure defined in advance in association with the authentication permission confirmation logic to which the response is adapted, There is provided a proxy authentication device comprising proxy authentication means for performing a user authentication procedure with a server function.
[0022]
According to such a proxy authentication device, the access unit accesses the server function in response to a request from the client function. When a response is returned from the server function, the necessity of user authentication is determined by the authentication necessity determination means. When user authentication is required, the proxy authentication means performs a user authentication procedure with the server function in accordance with an authentication procedure defined in advance in association with the authentication permission / inhibition confirmation logic with which the response is matched.
[0023]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
First, the outline of the invention applied to the embodiment will be described, and then the specific contents of the embodiment will be described.
[0024]
FIG. 1 is a conceptual diagram of the invention applied to the embodiment. The
[0025]
The
[0026]
The client functions 2a, 2b, 2c,... Have a function of transmitting a request to the server functions 3a, 3b, 3c,. The client functions 2a, 2b, 2c,... Are, for example, client applications that are implemented in individual client computers.
[0027]
The server functions 3a, 3b, 3c,... Perform processing according to the request sent from the client functions 2a, 2b, 2c,. The server functions 3a, 3b, 3c,... Are server applications implemented in, for example, a proxy server. It should be noted that the server functions 3a, 3b, 3c,... Have a user authentication function, and a processing function is provided only for requests from the client functions 2a, 2b, 2c,. provide. Each
[0028]
Here, when accessing the server functions 3a, 3b, 3c,... From the client functions 2a, 2b, 2c,..., The
[0029]
The
[0030]
The
[0031]
According to such a
[0032]
For example, consider a case where a plurality of
[0033]
In addition, since each
[0034]
In addition, although it is necessary to hold | maintain the user authentication information (for example, user name and password) for every
[0035]
The present embodiment will be specifically described below. The following embodiment is an example when the proxy authentication device function is implemented in the proxy server and proxy authentication to the Web server is performed.
[0036]
FIG. 2 is a diagram illustrating a configuration example of a network system that provides the present embodiment. As shown in FIG. 2, a plurality of
[0037]
[0038]
The
[0039]
The
[0040]
With such a system, the user can access the
[0041]
The
[0042]
Thereafter, when user authentication is requested when the
[0043]
FIG. 3 is a diagram illustrating a hardware configuration example of the proxy server. The
[0044]
The
[0045]
A
[0046]
The
[0047]
With the hardware configuration as described above, the processing functions of the present embodiment can be realized. 3 shows the hardware configuration of the
[0048]
Next, the function of the
[0049]
FIG. 4 is a block diagram illustrating functions of the proxy server. As shown in FIG. 4, the
[0050]
The
[0051]
The
[0052]
The user information table 111 is a database in which information about users who use the
[0053]
The
[0054]
The system table 112a manages the URL (Uniform Resource Locator) and authentication method of the Web server for each server function.
The response analysis / login command table 112b stores information necessary for logging in to the Web server.
[0055]
In the session information table 121, information related to a session established with a client is registered. The information about the session includes a timeout time. The contents of the session information table 121 are dynamically added or deleted during system operation.
[0056]
Here, before describing other elements of the
FIG. 5 is a diagram illustrating an exemplary data structure of the user information table. In the user information table 111, a set of a system ID, a user name, and a password is set for each Web server in association with the proxy server authentication information. Information arranged in the horizontal direction of each column is associated with each other to constitute user information of each user.
[0057]
The proxy server authentication information field is divided into a user name field and a password field. A user name is set in the user name column. A password corresponding to the user name is set in the password field.
[0058]
In the column of system ID, identification information of a Web server that is a user authentication target is set. In the example of FIG. 5, the alphabet following “Sys” is the identifier of the server (node on the network), and the number following the alphabet is the identifier of the Web server in the server. Therefore, “SysA0” and “SysA1” indicate different Web servers in the same server.
[0059]
In the user name column, the user name of user authentication information set in the Web server is set. In the password column, a password for user authentication information set in the Web server is set.
[0060]
FIG. 6 is a diagram illustrating an exemplary data structure of the system table. The system table 112a has columns for system ID, virtual URL, real URL, and authentication type. The information arranged in the horizontal direction of each column is associated with each other to constitute information about each Web server.
[0061]
Identification information of the Web server is set in the system ID column.
In the virtual URL field, a virtual URL for accessing the Web server from the client is set. An access request designating a virtual URL is issued from the Web browser.
[0062]
In the real URL column, a URL indicating the actual location of the Web server is set. The virtual URL and the real URL may be the same.
The name of the user authentication method in the Web server is set in the authentication type column. In the example of FIG. 6, “form”, “basic”, and “null” are set as the authentication type.
[0063]
Form authentication is a system that redirects an unauthenticated request to an HTML form on the Web server 31a side. An authentication form is passed to the client (the
[0064]
In basic authentication, when a response requesting authentication is returned from the Web server 31a that has received an unauthenticated request, authentication information (user name and user name) is sent to the client (the
[0065]
null indicates that authentication is not required.
Note that the virtual URL avoids the limitation of the HTTP (HyperText Transfer Protocol) cookie transmission range, and the internal URL (
[0066]
For example, if the domain name of the
[0067]
Therefore, in the present embodiment, xxx. zzz. com virtual URL to xxx. bbb. com. The user can set xxx. bbb. com to access via the
[0068]
FIG. 7 is a diagram illustrating a data structure example of a response analysis / login command table. The response analysis / login command table 112b has columns for system ID, login processing information, and authentication identification information. Information arranged in the horizontal direction of each column is associated with each other, and constitutes information necessary for a user authentication procedure for each Web server.
[0069]
Identification information of the Web server is set in the system ID column.
Information necessary for a user authentication (login) procedure to the Web server is set in the login processing information column. The login process information column includes an authentication URL, a method, and a form name column.
[0070]
In the authentication URL field, a URL to be accessed when logging in to the corresponding Web server is set.
In the method column, the type of request (method) in HTTP is set. Methods include “GET” and “POST”. GET is a method for extracting information from a Web server. POST is a method for transmitting information to a Web server.
[0071]
In the form name column, the name of the form for which authentication information is to be set is set. In the column of form name, columns of user, password, and additional data are provided. The name of the form for which the user name is to be set is set in the user column. The name of the form for which the password is to be set is set in the password field. In the additional data column, the name of a form for setting information to be added at the time of user authentication is set. In this additional data column, one or a plurality of information (m: m is a natural number of 1 or more) can be set in association with one system ID.
[0072]
Information for identifying whether or not a response from the Web server requests authentication is set in the authentication identification information column. In the column of authentication identification information, columns of response code, authentication header, and identification content data are provided.
[0073]
In the response code column, a code (response code) indicating the type of response from the Web server is set. Information to be included in a response header indicating an authentication request is set in the identification header field. In this identification header field, one or a plurality (n: n is a natural number of 1 or more) of information can be set in association with one system ID. Information to be included in the response content indicating the authentication request is set in the identification content data column.
[0074]
FIG. 8 is a diagram illustrating an exemplary data structure of the session information table. In the session information table 121, information regarding a session established with the client is set. The session information table 121 includes columns for session ID, user name, login time, and timeout notice time. Information arranged in the horizontal direction in each column is associated with each other to constitute information for each session.
[0075]
In the session ID column, identification information of the established session is set. In the user name column, identification information of a user who has requested session establishment is set. In the login time column, a time when the user logs in to the proxy server 100 (user authentication has been successful) is set. The time for disconnecting the session is set as the timeout notice time.
[0076]
The above is the data structure of each database managed by the
[0077]
The
[0078]
When activated, the
[0079]
The browser
[0080]
The proxy
[0081]
When the input information includes the user name and password information (included in the AUTHORIZED header), the proxy
[0082]
The proxy
[0083]
In response to a request from the proxy
[0084]
The communication
When the input content from the Web browser is a proxy communication request, the Web
[0085]
When communication is performed from the
[0086]
Note that both the virtual URL and the real URL may be physically the same computer. In this embodiment, since the server function is managed for each URL, it is allowed to handle one computer as a plurality of systems.
[0087]
The web server
[0088]
The Web server
[0089]
The Web
[0090]
The
[0091]
As a result of the authentication by the
[0092]
Furthermore, when the authentication type is “basic”, the
[0093]
When the authentication type is “form”, the
[0094]
The authentication
[0095]
The login processing
[0096]
When the authentication type is “basic”, the login processing
[0097]
If the authentication type is “form”, the login processing
[0098]
The login process
[0099]
When the response content is received from the
[0100]
The browser
[0101]
Processing in the system configured as described above will be described with reference to a flowchart.
FIG. 9 is a first flowchart showing the procedure of proxy authentication processing. This is an example when accessing the Web server 31a from the
[0102]
[Step S11] The
[0103]
[Step S12] The
[Step S13] In the
[0104]
[Step S14] In the
[0105]
[Step S15] The
[0106]
[Step S16] The
[0107]
[Step S17] The
[0108]
[Step S18] The
[Step S19] The
[0109]
[Step S20] The
[0110]
[Step S21] When the authentication fails, the
[0111]
[Step S22] When the authentication is successful, the
[0112]
[Step S23] The
[0113]
FIG. 10 is a second flowchart showing the procedure of proxy authentication processing. In the following, the process illustrated in FIG. 10 will be described in order of step number.
[Step S31] The
[0114]
[Step S32] The
[0115]
[Step S33] The
[Step S34] The
[0116]
[Step S35] The
[0117]
FIG. 11 is a third flowchart showing the procedure of proxy authentication processing. In the following, the process illustrated in FIG. 11 will be described in order of step number.
[Step S41] When access to the Web server 31a is denied, the
[0118]
[Step S42] When there is no session, the proxy server
[0119]
[Step S43] The
[Step S44] If there is a session, the user authentication to the
[0120]
[Step S45] The
[0121]
[Step S46] The
[Step S47] The
[0122]
[Step S48] The
[Step S49] The
[0123]
[Step S50] The
[Step S51] The
[0124]
[Step S52] When login fails, the
[Step S53] The
[0125]
[Step S54] The
[0126]
[Step S55] The
[0127]
Next, processing when it is determined in step S35 that access is permitted will be described.
FIG. 12 is a fourth flowchart showing the procedure of proxy authentication processing. In the following, the process illustrated in FIG. 12 will be described in order of step number.
[0128]
[Step S61] The
[0129]
[Step S62] The
[Step S63] The
[0130]
[Step S64] The
[Step S65] The
[0131]
[Step S66] The
[Step S67] The
[0132]
[Step S68] The
As described above, proxy authentication is performed in the
Next, a flow when logging in to the
[0133]
FIG. 13 is a first sequence diagram illustrating a processing procedure when basic authentication is performed on a Web server. FIG. 13 shows processing until a proxy authentication response is returned in response to a request from the
[0134]
[Step S71] The
[0135]
[Step S72] The
[0136]
[Step S73] The
[Step S74] The Web server 31a returns a response “401 (Unauthorized, WWW-Authenticate)” to the proxy server. In this example, a response with a
[0137]
[Step S75] The
[Step S76] The
[0138]
In this example, when the response code is 401 (response requesting login) and there is no PPS session, login processing to the
[0139]
[Step S77] The
FIG. 14 is a second sequence diagram illustrating a processing procedure when basic authentication is performed on a Web server. FIG. 14 shows processing from logging in to the
[0140]
[Step S81] The
[Step S82] The
[0141]
[Step S83] The
[Step S84] The
[0142]
Note that the order of the processes in step S83 and step S84 may be reversed. In the flowchart shown in FIG. 9, after confirming the session (step S15), the Authorized header is confirmed (step S16).
[0143]
[Step S85] The
[Step S86] The
[0144]
[Step S87] The
[Step S88] The
[0145]
[Step S89] The
[0146]
[Step S90] The Web server 31a performs user authentication based on the user authentication information. If the authentication is successful, the Web server 31a transmits the specified Web page (URL_X page) to the
[0147]
[Step S91] The
[Step S92] The
[0148]
[Step S93] The
As described above, a user using the
[0149]
Next, a processing procedure when continuously accessing the same Web server 31a will be described.
FIG. 15 is a sequence diagram illustrating an access procedure to a Web server that has completed basic authentication. In the following, the process illustrated in FIG. 15 will be described in order of step number.
[0150]
[Step S101] The
[0151]
[Step S102] The
[Step S103] The
[0152]
[Step S104] The
[Step S105] The
[0153]
[Step S106] The
[0154]
[Step S107] The Web server 31a transmits the specified Web page (URL_Y page) to the
[Step S108] The
[0155]
[Step S109] The
[0156]
Next, an example of accessing a new Web server after completing login to the
FIG. 16 is a sequence diagram illustrating a procedure for accessing a new Web server that requires basic authentication. In the following, the process illustrated in FIG. 16 will be described in order of step number.
[0157]
[Step S111] The
[0158]
[Step S112] The
[0159]
[Step S113] The
[0160]
[Step S114] The
[Step S115] The
[0161]
[Step S116] The
[0162]
[Step S117] The
[Step S118] The
[0163]
[Step S119] The
[0164]
[Step S120] The
[0165]
[Step S121] The
[0166]
[Step S122] The
In this way, if the user has already logged in to the
[0167]
Next, a procedure for performing form authentication will be described.
FIG. 17 is a first sequence diagram illustrating a processing procedure when form authentication is performed on the Web server. FIG. 17 shows processing until a proxy authentication response is returned in response to a request from the
[0168]
[Step S131] The
[0169]
[Step S132] In the
[0170]
[Step S133] The
[Step S134] The Web server 31a returns a response to the proxy server. In this example, a request rejection response (NG response (SSSSCookie)) is returned. The request rejection response includes a cookie (SSSCookie). This response indicates that access is denied because the form authentication has not been completed.
[0171]
[Step S135] The
[Step S136] The
[0172]
In this example, when a request rejection response is returned and there is no PPS session, login processing to the
[Step S137] The
[0173]
FIG. 18 is a second sequence diagram illustrating a processing procedure when form authentication is performed on the Web server. FIG. 18 shows processing from logging in to the
[0174]
[Step S141] The
[Step S142] The
[0175]
[Step S143] The
[Step S144] The
[0176]
Note that the order of the processes of step S143 and step S144 may be reversed. In the flowchart shown in FIG. 9, after confirming the session (step S15), the Authorized header is confirmed (step S16).
[0177]
[Step S145] The
[Step S146] The
[0178]
[Step S147] The
[Step S148] The
[0179]
[Step S149] The Web server 31a performs user authentication based on the user authentication information. When the authentication is successful, the Web server 31a transmits a Web page that is set in advance to be transmitted after the authentication to the
[0180]
[Step S150] The
[0181]
[Step S151] The
[0182]
[Step S152] The Web server 31a recognizes that the access is from an already authenticated user using a cookie (SSSSCookie), and transmits the requested Web page to the
[0183]
[Step S153] The
[Step S154] The
[0184]
[Step S155] The
As described above, a user using the
[0185]
Next, a processing procedure when continuously accessing the same Web server 31a will be described.
FIG. 19 is a sequence diagram illustrating an access procedure to a Web server that has completed form authentication. In the following, the process illustrated in FIG. 19 will be described in order of step number.
[0186]
[Step S161] The
[0187]
[Step S162] In the
[Step S163] The
[0188]
[Step S164] The
[0189]
[Step S165] The Web server 31a transmits the specified Web page (URL_Y page) to the
[Step S166] The
[0190]
[Step S167] The
Next, an example in which a new Web server is accessed after login to the
[0191]
FIG. 20 is a sequence diagram showing an access procedure to a new Web server that requires form authentication. In the following, the process illustrated in FIG. 20 will be described in order of step number.
[0192]
[Step S <b> 171] The
[0193]
[Step S172] In the
[0194]
[Step S173] The
[0195]
[Step S174] The
[0196]
[Step S175] The
[Step S176] The
[0197]
[Step S177] The
[Step S178] The
[0198]
[Step S179] The
[0199]
[Step S180] The
[0200]
[Step S181] The
[0201]
[Step S182] The
[0202]
[Step S183] The
[Step S184] The
[0203]
[Step S185] The
As described above, proxy authentication can be performed in accordance with an authentication method such as basic authentication or form authentication. Moreover, the authentication procedure is defined in advance, and it is only necessary to hold user authentication information for each user for each Web server.
[0204]
The authentication procedure for basic authentication and the authentication procedure for form authentication are different from each other in the generation method of transmission data in addition to the differences expressed in the above procedure. Therefore, a transmission data generation method for each authentication method by the login processing
[0205]
FIG. 21 is a flowchart showing a transmission data generation procedure at the time of basic authentication. In the following, the process illustrated in FIG. 21 will be described in order of step number.
[Step S <b> 201] The login processing
[0206]
[Step S202] The login processing
[0207]
[Step S203] The login processing
[Step S204] The login processing
[0208]
[Step S205] The login processing
[Step S206] The login processing
[0209]
[Step S207] The login processing
[Step S208] The login processing
[0210]
FIG. 22 is a flowchart showing a transmission data generation procedure at the time of form authentication. In the following, the process illustrated in FIG. 22 will be described in order of step number.
[Step S211] The login processing
[0211]
Here, the form data generation information holding table 140a is a data table held by the login processing
[0212]
[Step S212] The login processing
[0213]
[Step S213] The login processing
[0214]
[Step S214] The login processing
[Step S <b> 215] The login processing
[0215]
[Step S216] The login processing
[Step S217] The login processing
[0216]
[Step S218] The login processing
As described above, when the
[0217]
In the above example, the proxy server performs proxy authentication, but this function can also be implemented in the client.
FIG. 23 is a conceptual diagram of a client that implements a proxy authentication function. As shown in FIG. 23, a
[0218]
The
[0219]
As described above, according to the embodiment of the present invention, when a Web system requiring a plurality of authentications is used, the user needs to log in only once.
Moreover, unlike a conventional single sign-on system, when a web page that does not require authentication is used, the user performs zero login operation. In other words, in the conventional single sign-on technology, it is assumed that the user has previously logged in to the proxy authentication system, and one user authentication process always occurs. However, according to this embodiment, the proxy server determines whether or not user authentication is required on the Web server, and does not request login to the proxy server if the access is to a Web server that does not require user authentication. As a result, user operability is improved.
[0220]
In this embodiment, since user authentication information is managed for each URL of the Web server, proxy authentication for each Web server is possible even when a plurality of Web servers are installed in the same server computer. is there.
[0221]
Further, the conventional proxy authentication technology includes a type in which authentication communication is completely recorded and reproduced as it is. This technique requires redundant storage areas. On the other hand, in the method of the present embodiment, authentication communication data is generated by calculation processing of a program. Therefore, even when the number of users increases, the increase in storage capacity is negligible.
[0222]
In this embodiment, even if the session is stopped due to the occurrence of a session timeout on the Web server side, the session can be automatically logged in when the corresponding Web server is accessed next time, and the session can be re-established. Therefore, the user does not need to be aware of session timeout on the Web server.
[0223]
In addition, with conventional single sign-on, a server for realizing single sign-on is necessary, and it is difficult to operate and use by individuals. In this embodiment, the proxy server function can be prepared in the client (see FIG. 23), and single sign-on on the client can be realized.
[0224]
An existing Web browser has a mechanism for storing the user name and password input by the user and reducing the trouble of inputting the password. However, this function is different for each browser, and users using multiple browsers cannot share user name and password data. If it is a single user form as shown in FIG. 23, the single sign-on unified by the some browser is realizable.
[0225]
By the way, in the above example, an example in the case of accessing a Web server has been described. However, proxy authentication can be performed for other applications that request user authentication via a network by the same process. .
[0226]
In the above example, an example in which the Web server requests basic authentication or form authentication is shown, but the present invention can also be applied to other authentication methods. In that case, the criteria for determining the authentication method to be applied are set in the response analysis / login command table 112b, and the authentication procedure for the corresponding authentication method is defined. The login processing
[0227]
Note that the processing functions of the
[0228]
The proxy authentication program describing the processing contents can be recorded on a recording medium readable by the server computer. Examples of the recording medium readable by the server computer include a magnetic recording device, an optical disk, a magneto-optical recording medium, and a semiconductor memory. Examples of the magnetic recording device include a hard disk device (HDD), a flexible disk (FD), and a magnetic tape. Examples of the optical disk include a DVD (Digital Versatile Disc), a DVD-RAM (Random Access Memory), a CD-ROM (Compact Disc Read Only Memory), and a CD-R (Recordable) / RW (ReWriteable). Magneto-optical recording media include MO (Magneto-Optical disc).
[0229]
When distributing the proxy authentication program, for example, portable recording media such as DVDs and CD-ROMs on which the proxy authentication program is recorded are sold.
For example, the server computer that executes the proxy authentication program stores the proxy authentication program recorded in the portable recording medium in its own storage device. Then, the server computer reads the proxy authentication program from its own storage device, and executes processing according to the proxy authentication program. The server computer can also read the proxy authentication program directly from the portable recording medium and execute processing according to the proxy authentication program.
[0230]
(Supplementary note 1) In the proxy authentication program that represents the authentication procedure for other devices,
On the computer,
In response to a request from the client function, access to the server function connected via the network,
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Whether or not user authentication is necessary,
When user authentication is required, a user authentication procedure is performed with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted.
A proxy authentication program characterized by causing processing to be executed.
[0231]
(Supplementary Note 2) In the user authentication procedure, user authentication information for the server function stored in advance in association with the client function is added to the request from the client function and transmitted to the server function. The proxy authentication program according to
[0232]
(Additional remark 3) The said request | requirement from the said client function is memorize | stored, and the said memorize | stored request | requirement is transmitted to the said server function after the said user authentication procedure between the said server functions is completed. The listed proxy authentication program.
[0233]
(Supplementary Note 4) Upon receiving the response indicating that user authentication is incomplete, confirm whether or not a session with the client function is established,
If the session is not established, request user authentication for the client function;
When user authentication is completed, a session is established with the client function, and the user authentication procedure with the server function is performed.
The proxy authentication program according to
[0234]
(Supplementary note 5) The proxy authentication program according to
[0235]
(Additional remark 6) In the said authentication permission confirmation logic, the said server function is specified by the combination of the identification information of the apparatus in which the said server function is mounted, and the information which shows the location of the said server function in the said apparatus The proxy authentication program according to
[0236]
(Supplementary note 7) In the proxy authentication method for proxying the authentication procedure to other devices,
In response to a request from the client function, access to the server function connected via the network,
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Whether or not user authentication is necessary,
When user authentication is required, a user authentication procedure is performed with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted.
A proxy authentication method characterized by that.
[0237]
(Supplementary note 8) In a proxy authentication device acting as a proxy for authentication to other devices,
An access means for accessing a server function connected via a network in response to a request from the client function;
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Authentication necessity judging means for judging whether or not user authentication is necessary depending on whether or not,
When user authentication is required, proxy authentication means for performing a user authentication procedure with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted;
A proxy authentication apparatus comprising:
[0238]
(Supplementary note 9) In a computer-readable recording medium in which a proxy authentication program for proxying an authentication procedure to another device is recorded,
In the computer,
In response to a request from the client function, access to the server function connected via the network,
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Whether or not user authentication is necessary,
When user authentication is required, a user authentication procedure is performed with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted.
A computer-readable recording medium having recorded thereon a proxy authentication program characterized in that processing is executed.
[0239]
【The invention's effect】
As described above, in the present invention, a plurality of authentication permission / rejection confirmation logics are defined in advance, an authentication permission / rejection confirmation logic is determined according to a response from the server function, and an authentication procedure associated with the authentication permission / rejection confirmation logic Added user authentication procedure for server function. As described above, since user authentication is performed based on an authentication procedure according to the authentication permission / inhibition confirmation logic, there is no need to store an authentication procedure for each client even when proxy authentication of a plurality of clients is performed. As a result, the proxy authentication function can be realized by using a small amount of hardware resources.
[Brief description of the drawings]
FIG. 1 is a conceptual diagram of an invention applied to an embodiment.
FIG. 2 is a diagram illustrating a configuration example of a network system that provides the exemplary embodiment;
FIG. 3 is a diagram illustrating a hardware configuration example of a proxy server.
FIG. 4 is a block diagram illustrating functions of a proxy server.
FIG. 5 is a diagram illustrating an example of a data structure of a user information table.
FIG. 6 is a diagram illustrating an exemplary data structure of a system table.
FIG. 7 is a diagram illustrating an example of a data structure of a response analysis / login command table.
FIG. 8 illustrates an exemplary data structure of a session information table.
FIG. 9 is a first flowchart showing a procedure of proxy authentication processing;
FIG. 10 is a second flowchart showing the procedure of proxy authentication processing;
FIG. 11 is a third flowchart showing the procedure of proxy authentication processing;
FIG. 12 is a fourth flowchart showing the procedure of proxy authentication processing;
FIG. 13 is a first sequence diagram illustrating a processing procedure when basic authentication is performed by a Web server.
FIG. 14 is a second sequence diagram illustrating a processing procedure when basic authentication is performed on a Web server.
FIG. 15 is a sequence diagram illustrating an access procedure to a Web server that has completed basic authentication.
FIG. 16 is a sequence diagram showing a procedure for accessing a new Web server that requires basic authentication.
FIG. 17 is a first sequence diagram illustrating a processing procedure when form authentication is performed on a Web server.
FIG. 18 is a second sequence diagram illustrating a processing procedure when form authentication is performed on a Web server.
FIG. 19 is a sequence diagram illustrating a procedure for accessing a Web server that has completed form authentication.
FIG. 20 is a sequence diagram showing a procedure for accessing a new Web server that requires form authentication.
FIG. 21 is a flowchart showing a transmission data generation procedure at the time of basic authentication.
FIG. 22 is a flowchart showing a transmission data generation procedure at the time of form authentication.
FIG. 23 is a conceptual diagram of a client that implements a proxy authentication function.
[Explanation of symbols]
1 Proxy authentication device
2 clients
3 servers
11, 12, 13, ... Client
31, 32, 33, ... Server
100 proxy server
110 database
111 User information table
112 Web server information
112a system table
112b Response analysis / login command table
121 Session information table
122 timer
123 Timeout drive unit
131 Browser input reception part
132 Proxy server authentication unit
133 Proxy server authentication request part
134 Communication state holding unit
135 Web server identification unit
136 Web server request generation unit
137 Web server communication unit
138 Response analysis unit
139 Authentication processing determination unit
140 Login processing command generator
141 Content converter
142 Browser response generator
Claims (5)
コンピュータに、
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
処理を実行させることを特徴とする代理認証プログラム。In the proxy authentication program that represents the authentication procedure for other devices,
On the computer,
In response to a request from the client function, access to the server function connected via the network,
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Whether or not user authentication is necessary,
When user authentication is required, a user authentication procedure is performed with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted.
A proxy authentication program characterized by causing processing to be executed.
前記セッションが未確立の場合、前記クライアント機能に対してユーザ認証を要求し、
ユーザ認証が完了すると前記クライアント機能との間にセッションを確立し、前記サーバ機能との間の前記ユーザ認証手続きを行う、
ことを特徴とする請求項１記載の代理認証プログラム。When receiving the response indicating that user authentication is incomplete, check whether a session with the client function is established,
If the session is not established, request user authentication for the client function;
When user authentication is completed, a session is established with the client function, and the user authentication procedure with the server function is performed.
The proxy authentication program according to claim 1.
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスし、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断し、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う、
ことを特徴とする代理認証方法。In the proxy authentication method for proxying the authentication procedure to other devices,
In response to a request from the client function, access to the server function connected via the network,
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Whether or not user authentication is necessary,
When user authentication is required, a user authentication procedure is performed with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted.
A proxy authentication method characterized by that.
クライアント機能からの要求に応じて、ネットワークを介して接続されるサーバ機能に対してアクセスするアクセス手段と、
ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されており、前記サーバ機能からの応答が前記複数の認証許否確認論理のいずれかに適合するか否かによりユーザ認証の要否を判断する認証要否判断手段と、
ユーザ認証が必要な場合、前記応答が適合した前記認証許否確認論理に対応付けて予め定義されている認証手順に従って、前記サーバ機能との間でユーザ認証手続きを行う代理認証手段と、
を有することを特徴とする代理認証装置。In a proxy authentication device that represents the authentication procedure for other devices,
An access means for accessing a server function connected via a network in response to a request from the client function;
Whether a plurality of authentication permission / rejection confirmation logics for identifying a response indicating that user authentication is incomplete is defined in advance, and whether a response from the server function matches any of the plurality of authentication permission / rejection confirmation logics Authentication necessity judging means for judging whether or not user authentication is necessary depending on whether or not,
When user authentication is required, proxy authentication means for performing a user authentication procedure with the server function according to an authentication procedure defined in advance in association with the authentication approval / disapproval confirmation logic to which the response is adapted;
A proxy authentication apparatus comprising:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003175139A JP4467256B2 (en) | 2003-06-19 | 2003-06-19 | Proxy authentication program, proxy authentication method, and proxy authentication device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003175139A JP4467256B2 (en) | 2003-06-19 | 2003-06-19 | Proxy authentication program, proxy authentication method, and proxy authentication device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005011098A true JP2005011098A (en) | 2005-01-13 |
| JP4467256B2 JP4467256B2 (en) | 2010-05-26 |
Family
ID=34098429
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003175139A Expired - Fee Related JP4467256B2 (en) | 2003-06-19 | 2003-06-19 | Proxy authentication program, proxy authentication method, and proxy authentication device |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4467256B2 (en) |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005063169A (en) * | 2003-08-13 | 2005-03-10 | Ricoh Co Ltd | Information processor, image processor, server device, method for session connection, session connection program, and recording medium |
| JP2006331044A (en) * | 2005-05-26 | 2006-12-07 | Hitachi Ltd | Single sign-on achievement method |
| JP2007049649A (en) * | 2005-08-12 | 2007-02-22 | Sharp Corp | Communication medium apparatus, data providing apparatus, and data providing system |
| JP2007058391A (en) * | 2005-08-23 | 2007-03-08 | Nippon Telegr & Teleph Corp <Ntt> | Authentication method for broadcast communication cooperation service, authentication cooperation device, its program and program recording medium |
| JP2009104353A (en) * | 2007-10-23 | 2009-05-14 | Nomura Securities Co Ltd | Gadget provision server and gadget provision program |
| JP2010092185A (en) * | 2008-10-06 | 2010-04-22 | Optim Corp | Network relay apparatus, user information management system and user information management method |
| JP2011133948A (en) * | 2009-12-22 | 2011-07-07 | Nec Access Technica Ltd | Router, web browser authentication method for the router, and web browser authentication program |
| JP2011522326A (en) * | 2008-05-27 | 2011-07-28 | マイクロソフト コーポレーション | Authentication for distributed secure content management systems |
| CN102164120A (en) * | 2010-02-18 | 2011-08-24 | 索尼公司 | Information processing apparatus, information processing method, and computer-readable recording medium |
| JP2011197874A (en) * | 2010-03-18 | 2011-10-06 | Fujitsu Ltd | Server apparatus and program |
| JP2011527468A (en) * | 2008-06-26 | 2011-10-27 | アリババ・グループ・ホールディング・リミテッド | Service integration platform system and method for internet service |
| JP2012501010A (en) * | 2008-06-26 | 2012-01-12 | アリババ・グループ・ホールディング・リミテッド | Method and service integration platform system for providing internet services |
| WO2012017561A1 (en) * | 2010-08-06 | 2012-02-09 | 富士通株式会社 | Mediation processing method, mediation device, and system |
| US8195808B2 (en) | 2007-11-12 | 2012-06-05 | International Business Machines Corporation | Session management technique |
| JP2012194722A (en) * | 2011-03-16 | 2012-10-11 | Fujitsu Ltd | System, authentication information management method and program |
| JP2013097744A (en) * | 2011-11-05 | 2013-05-20 | Kyocera Document Solutions Inc | Pseudo single sign-on device, image forming device using the same, and image forming system |
| JP2013114530A (en) * | 2011-11-30 | 2013-06-10 | Konica Minolta Business Technologies Inc | Network system, information processing device and control method thereof, and computer program |
| JP2014026348A (en) * | 2012-07-24 | 2014-02-06 | Nippon Telegr & Teleph Corp <Ntt> | Information distribution system, authentication cooperation method, device, and program therefor |
| JP2014127058A (en) * | 2012-12-27 | 2014-07-07 | Fujitsu Ltd | Relay device, relay method and program |
| US9294484B2 (en) | 2012-10-31 | 2016-03-22 | Ricoh Company, Ltd. | System, service providing device, and service providing method |
| JP2017084399A (en) * | 2016-12-28 | 2017-05-18 | 富士通株式会社 | Relay device, relay method, and program |
| JP2019040319A (en) * | 2017-08-23 | 2019-03-14 | コニカミノルタ株式会社 | Proxy authentication system, proxy authentication method, and program |
| CN113472796A (en) * | 2021-07-06 | 2021-10-01 | 山东电力工程咨询院有限公司 | Data center portal management method and system |
| CN115604041A (en) * | 2022-12-16 | 2023-01-13 | 深圳高灯计算机科技有限公司（Cn） | Security agent method, system, device, computer equipment and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002032216A (en) * | 2000-07-19 | 2002-01-31 | Fujitsu Ltd | Hosting device for application |
| JP2002202955A (en) * | 2000-10-31 | 2002-07-19 | Microsoft Corp | System and method for automatically formulating response to authentication request from secured server |
| JP2002334056A (en) * | 2001-05-08 | 2002-11-22 | Infocom Corp | System and method for executing log-in in behalf of user |
-
2003
- 2003-06-19 JP JP2003175139A patent/JP4467256B2/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002032216A (en) * | 2000-07-19 | 2002-01-31 | Fujitsu Ltd | Hosting device for application |
| JP2002202955A (en) * | 2000-10-31 | 2002-07-19 | Microsoft Corp | System and method for automatically formulating response to authentication request from secured server |
| JP2002334056A (en) * | 2001-05-08 | 2002-11-22 | Infocom Corp | System and method for executing log-in in behalf of user |
Cited By (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005063169A (en) * | 2003-08-13 | 2005-03-10 | Ricoh Co Ltd | Information processor, image processor, server device, method for session connection, session connection program, and recording medium |
| JP2006331044A (en) * | 2005-05-26 | 2006-12-07 | Hitachi Ltd | Single sign-on achievement method |
| JP4578352B2 (en) * | 2005-08-12 | 2010-11-10 | シャープ株式会社 | Communication mediating apparatus, data providing apparatus, and data providing system |
| JP2007049649A (en) * | 2005-08-12 | 2007-02-22 | Sharp Corp | Communication medium apparatus, data providing apparatus, and data providing system |
| JP2007058391A (en) * | 2005-08-23 | 2007-03-08 | Nippon Telegr & Teleph Corp <Ntt> | Authentication method for broadcast communication cooperation service, authentication cooperation device, its program and program recording medium |
| JP4589200B2 (en) * | 2005-08-23 | 2010-12-01 | 日本電信電話株式会社 | Authentication method, authentication cooperation device, program thereof, and program recording medium in broadcast communication cooperation service |
| JP2009104353A (en) * | 2007-10-23 | 2009-05-14 | Nomura Securities Co Ltd | Gadget provision server and gadget provision program |
| US9055054B2 (en) | 2007-11-12 | 2015-06-09 | International Business Machines Corporation | Session management technique |
| US10097532B2 (en) | 2007-11-12 | 2018-10-09 | International Business Machines Corporation | Session management technique |
| US8195808B2 (en) | 2007-11-12 | 2012-06-05 | International Business Machines Corporation | Session management technique |
| US8910255B2 (en) | 2008-05-27 | 2014-12-09 | Microsoft Corporation | Authentication for distributed secure content management system |
| JP2011522326A (en) * | 2008-05-27 | 2011-07-28 | マイクロソフト コーポレーション | Authentication for distributed secure content management systems |
| JP2014041652A (en) * | 2008-05-27 | 2014-03-06 | Microsoft Corp | Authentication for distributed secure content management system |
| JP2012501010A (en) * | 2008-06-26 | 2012-01-12 | アリババ・グループ・ホールディング・リミテッド | Method and service integration platform system for providing internet services |
| JP2011527468A (en) * | 2008-06-26 | 2011-10-27 | アリババ・グループ・ホールディング・リミテッド | Service integration platform system and method for internet service |
| US9027089B2 (en) | 2008-06-26 | 2015-05-05 | Alibaba Group Holding Limited | Method and system for providing internet services |
| JP2010092185A (en) * | 2008-10-06 | 2010-04-22 | Optim Corp | Network relay apparatus, user information management system and user information management method |
| JP2011133948A (en) * | 2009-12-22 | 2011-07-07 | Nec Access Technica Ltd | Router, web browser authentication method for the router, and web browser authentication program |
| JP2011171983A (en) * | 2010-02-18 | 2011-09-01 | Sony Corp | Apparatus and, processing information method, and computer-readable recording medium |
| CN102164120B (en) * | 2010-02-18 | 2017-04-26 | 索尼公司 | Information processing apparatus, information processing method, and computer-readable recording medium |
| CN102164120A (en) * | 2010-02-18 | 2011-08-24 | 索尼公司 | Information processing apparatus, information processing method, and computer-readable recording medium |
| US9065871B2 (en) | 2010-02-18 | 2015-06-23 | Sony Corporation | Information processing apparatus, information processing method, and computer-readable recording medium |
| US9641508B2 (en) | 2010-02-18 | 2017-05-02 | Sony Corporation | Information processing apparatus, information processing method, and computer-readable recording medium |
| JP2011197874A (en) * | 2010-03-18 | 2011-10-06 | Fujitsu Ltd | Server apparatus and program |
| JP5418681B2 (en) * | 2010-08-06 | 2014-02-19 | 富士通株式会社 | Mediation processing method, mediation apparatus and system |
| US8763151B2 (en) | 2010-08-06 | 2014-06-24 | Fujitsu Limited | Mediation processing method, mediation apparatus and system |
| WO2012017561A1 (en) * | 2010-08-06 | 2012-02-09 | 富士通株式会社 | Mediation processing method, mediation device, and system |
| US8732815B2 (en) | 2011-03-16 | 2014-05-20 | Fujitsu Limited | System, method of authenticating information management, and computer-readable medium storing program |
| JP2012194722A (en) * | 2011-03-16 | 2012-10-11 | Fujitsu Ltd | System, authentication information management method and program |
| JP2013097744A (en) * | 2011-11-05 | 2013-05-20 | Kyocera Document Solutions Inc | Pseudo single sign-on device, image forming device using the same, and image forming system |
| JP2013114530A (en) * | 2011-11-30 | 2013-06-10 | Konica Minolta Business Technologies Inc | Network system, information processing device and control method thereof, and computer program |
| JP2014026348A (en) * | 2012-07-24 | 2014-02-06 | Nippon Telegr & Teleph Corp <Ntt> | Information distribution system, authentication cooperation method, device, and program therefor |
| US9294484B2 (en) | 2012-10-31 | 2016-03-22 | Ricoh Company, Ltd. | System, service providing device, and service providing method |
| JP2014127058A (en) * | 2012-12-27 | 2014-07-07 | Fujitsu Ltd | Relay device, relay method and program |
| JP2017084399A (en) * | 2016-12-28 | 2017-05-18 | 富士通株式会社 | Relay device, relay method, and program |
| JP2019040319A (en) * | 2017-08-23 | 2019-03-14 | コニカミノルタ株式会社 | Proxy authentication system, proxy authentication method, and program |
| JP7025684B2 (en) | 2017-08-23 | 2022-02-25 | コニカミノルタ株式会社 | Proxy authentication system, proxy authentication method, program |
| CN113472796A (en) * | 2021-07-06 | 2021-10-01 | 山东电力工程咨询院有限公司 | Data center portal management method and system |
| CN113472796B (en) * | 2021-07-06 | 2023-05-30 | 山东电力工程咨询院有限公司 | Data center portal management method and system |
| CN115604041A (en) * | 2022-12-16 | 2023-01-13 | 深圳高灯计算机科技有限公司（Cn） | Security agent method, system, device, computer equipment and storage medium |
| CN115604041B (en) * | 2022-12-16 | 2023-05-09 | 深圳高灯计算机科技有限公司 | Security agent method, system, apparatus, computer device, and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4467256B2 (en) | 2010-05-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4467256B2 (en) | Proxy authentication program, proxy authentication method, and proxy authentication device | |
| JP4864289B2 (en) | Network user authentication system and method | |
| RU2447490C2 (en) | Protected processing of client system mandate for access to web-resources | |
| US9438633B1 (en) | System, method and computer program product for providing unified authentication services for online applications | |
| US8326981B2 (en) | Method and system for providing secure access to private networks | |
| US7043455B1 (en) | Method and apparatus for securing session information of users in a web application server environment | |
| US6510236B1 (en) | Authentication framework for managing authentication requests from multiple authentication devices | |
| EP1645971B1 (en) | Database access control method, database access controller, agent processing server, database access control program, and medium recording the program | |
| US7188181B1 (en) | Universal session sharing | |
| KR100800339B1 (en) | Method and system for user-determined authentication and single-sign-on in a federated environment | |
| US6374359B1 (en) | Dynamic use and validation of HTTP cookies for authentication | |
| CN100534092C (en) | Method and system for stepping up to certificate-based authentication without breaking an existing ssl session | |
| US20080040773A1 (en) | Policy isolation for network authentication and authorization | |
| US6934848B1 (en) | Technique for handling subsequent user identification and password requests within a certificate-based host session | |
| US7587491B2 (en) | Method and system for enroll-thru operations and reprioritization operations in a federated environment | |
| US20070156592A1 (en) | Secure authentication method and system | |
| WO2004036351A2 (en) | Cross-site timed out authentication management | |
| CN107872455A (en) | A kind of cross-domain single login system and its method | |
| US20030135734A1 (en) | Secure mutual authentication system | |
| JP2001186122A (en) | Authentication system and authentication method | |
| JP2002189646A (en) | Repeating installation | |
| JP2008015733A (en) | Log management computer | |
| WO2006114361A1 (en) | Method, system, and program product for connecting a client to a network | |
| KR20000059245A (en) | Biometrics Information Save System and Verification Method of Using the same | |
| CA2403383C (en) | System, method and computer program product for providing unified authentication services for online applications |
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 |