JP4867486B2

JP4867486B2 - 制御プログラムおよび通信システム

Info

Publication number: JP4867486B2
Application number: JP2006162261A
Authority: JP
Inventors: 恒中津山
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2006-06-12
Filing date: 2006-06-12
Publication date: 2012-02-01
Anticipated expiration: 2026-06-12
Also published as: CN101090319A; CN101090319B; JP2007334411A; US20070288634A1

Description

本発明は、制御プログラムおよび通信システムに関する。

ユーザが最初に一度認証を受けると、その認証で許可された全ての機能を利用できるようにするＳＳＯ（Single Sign-On）システムが提案されている。このシステムは、例えば、特許文献１に記載された構成で実現でき、あるサーバへの接続に際し認証、別のサーバへの接続に際し認証…といった認証操作を複数回繰り返す煩わしさを解消させることができる。

学校、企業等において、ネットワークシステムを運用する場合には、セキュリティを強化するために、内部ネットワークと外部ネットワーク（例えば、インターネット）との境に、内部ネットワークのコンピュータの代理として外部ネットワークへ接続を行うプロキシサーバが設けられる。このプロキシサーバは、外部ネットワーク上のサーバを、内部ネットワークから利用することを目的とし、特に、フォワードプロキシと呼ばれることもある。

これに対しリバースプロキシは、フォワードプロキシが内部ネットワークから外部ネットワークへの接続を中継するのとは逆に、外部ネットワークから内部ネットワークへの接続を中継する。なお、リバースプロキシの用途は、外部ネットワークから内部ネットワークへの接続に限らず、同一のネットワーク内で用いられることも少なくない。
特開２００５−２６７５２９号

ＳＳＯシステムの１つに、リバースプロキシを配し、外部ネットワーク側からの接続を集中的に管理ならびに監査するリバースプロキシ型のＳＳＯシステムがある。このタイプのシステムでは、ＷｅｂブラウザからＷｅｂサーバに対する全てのリクエストを一旦、このリバースプロキシが受け取り、Ｗｅｂサーバに転送することによって動作することになる。そのため、全てのリクエストがこのリバースプロキシを通過することになるので、リバースプロキシがボトルネックとなり、処理速度や可用性が低下してしまう恐れがある。

リバースプロキシ型のＳＳＯシステムの場合、ブラウザ側からは、コンテンツがすべてリバースプロキシに存在するように見える。このため、リバースプロキシでは、コンテンツ（例えば、ＨＴＭＬ（HyperText Markup Language）、スタイルシート（ＣＳＳ）、クライアントサイドスクリプト言語（Java（登録商標）Script、VBScript）等で構成される）内にリンクなどが設定してある場合、このリンク先のＵＲＬに変更が生じるため、これに伴ってコンテンツを書き換える必要がでてくる。これらのコンテンツはユーザが手作業で作成、あるいは、サーバ側へのアクセス時にプログラムが動的に生成したものであるため、構文上正しい保証がなく、往々にして誤りが含まれている。

構文が間違っていれば、書き換えが上手くいかないので、事前に構文チェックをしておく等の、サーバ側での対応が必要になってくるケースがある。このため、任意のサービスをＳＳＯシステムに参加させることが難しい場合が多かった。

また、上述したリバースプロキシ型のＳＳＯシステムの他、Ｗｅｂサーバに認証モジュールを組み込みＷｅｂアプリケーション等に至る前に、認証を済ませるエージェント型のＳＳＯシステムも提案されているが、この場合、Ｗｅｂサーバに組み込むことになるため、プラットフォームや種類に依存してしまう。場合によっては、Ｗｅｂサーバ側で大掛かりな対応が必要になってくる。

また、エージェント型のリバースプロキシと呼ばれるタイプのＳＳＯシステムでは一般に、Ｗｅｂサーバ毎に仮想サーバが必要になってくるため、ＩＰ（Internet Protocol）アドレスを余計に消費してしまうことになる。

そこで、本発明は上記問題点に鑑みてなされたものであり、プラットフォームへの依存や、コンテンツの書き換えを無くすとともに、パフォーマンスを向上させるようにした制御プログラムおよび通信システムを提供することを目的とする。

上記目的を達成するため、請求項１の制御プログラムの発明は、リソース端末がリソースを記憶し、該リソースにアクセスする際に行う認証処理を該リソース端末とは別の端末に配設されたコンピュータに実行させる制御プログラムであって、該コンピュータは、前記リソース端末の名前を該コンピュータに解決するネームサーバと接続され、ブラウザからの前記リソースに対するリクエストに該リクエストを送信したユーザの認証済みを示す情報が提示されているか否かを判断する判断ステップと、前記判断ステップによる判断の結果、認証済みを示す情報が提示されていない場合に、認証済みであるか否かを確認する確認ステップと、前記確認ステップにより認証済みであることが確認された場合、認証済みを示す情報を前記ブラウザに発行する発行ステップと、前記認証済みを示す情報が提示された場合は、前記ブラウザと前記リソース間のデータ通信を前記ネームサーバを介して中継する中継ステップとを含む。

また、請求項２の発明は、請求項１の発明において、前記確認ステップは、前記コンピュータと接続される特定の端末への問い合わせに基づき認証済みであるか否かの確認を行う。

また、請求項３の発明は、請求項２の発明において、認証済みであることが確認できない場合、該ブラウザからのリクエストを前記特定の端末へリダイレクトすることにより認証を行わせるリダイレクト手段を更に含む。

また、請求項４の発明は、請求項１の発明において、前記データ通信に際して、リソースに対するアクセスの認可を行う認可ステップを更に含む。

また、請求項５の発明は、請求項４の発明において、前記認可ステップは、前記特定の端末への問い合わせに基づき前記認可を行う。

また、請求項６の発明は、請求項１の発明において、別端末へログを出力するログ出力ステップを更に含む。

また、請求項７の通信システムの発明は、第１の端末と、第２の端末と、リソース端末と、ネームサーバとが通信手段を介して接続される通信システムであって、前記リソース端末は、リソースを記憶し、前記ネームサーバは、前記リソース端末の名前を前記第２の端末に解決し、前記第１の端末は、認証情報に基づき認証を行う認証手段と、認可情報に基づきリソースに対するアクセスの認可を行う第１の認可手段とを具備し、前記第２の端末は、ブラウザからの前記リソースに対するリクエストに認証済みを示す情報が提示されているか否かを判断する判断手段と、前記判断手段による判断の結果、認証済みを示す情報が提示されていない場合に、前記認証手段への問合せに基づき認証済みであるか否かを確認する確認手段と、前記確認手段により認証済みであることが確認された場合、認証済みを示す情報を前記ブラウザに発行する発行手段と、前記認証済みを示す情報が提示された場合は、前記第１の認可手段への問い合わせに基づき該リソースに対するアクセスの認可を行う認可手段と、前記認証済みを示す情報が提示された場合は、前記ブラウザと前記リソース間のデータ通信を前記ネームサーバを介して中継する中継手段とを具備するように構成される。

また、請求項８の発明は、請求項７の発明において、前記リソース端末が複数存在し、前記複数のリソース端末に応じて前記第２の端末を一つ以上備えるように構成される。

本発明によれば、リバースプロキシ型のように隘路ができないので、パフォーマンスが向上する。

また、本発明によれば、プラットフォームへの依存や、コンテンツの書き換えがなく、ＳＳＯに参加するサーバ端末側での対応が不要であるため、任意のサービスをＳＳＯに参加させることができる。

また、本発明によれば、コンテンツを書き換える必要がないので、性能の劣化を招かない。

以下、この発明に係わる制御プログラムおよび通信システムの実施形態について添付図面を参照して詳細に説明する。

図１は、本発明に係わる通信システムの全体構成の一例を示す図である。

この通信システムは、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等で構成されたネットワーク５０を介して１または複数台のクライアント端末１０と、１または複数台のサービス提供サーバ２０と、ＳＳＯ情報サーバ３０と、ログサーバ４０とが接続されている。この通信システムでは、ＳＳＯ情報サーバ３０の認証部３３と、サービス提供サーバ２０内のＳＳＯモジュール２１の制御によりＳＳＯが実現される。すなわち、この認証部３３において、１度認証が有効に行われると、Ｗｅｂブラウザ１１、ＳＳＯモジュール２１、認証部３３が協調動作することで、以後、どのサービス提供サーバ２０にアクセスしたとしても、ユーザが認証を要求されることはない。なお、この通信システムにおけるネットワーク構成は、あくまで一例であり、ネットワーク５０上にはこの他、各種ネットワーク端末が接続されていても良い。

ここで、クライアント端末１０には、ＨＴＭＬコンテンツ等を閲覧するためのアプリケーションとしてＷｅｂブラウザ１１が備わっており、このＷｅｂブラウザ１１を用いることでサービス提供サーバ２０等とのデータ通信が実現されることになる。

ＳＳＯ情報サーバ３０は、認証情報管理部３１において認証情報３１ａを、認可情報管理部３２において認可情報３２ａを記憶管理するとともに、この認証情報３１ａに基づき認証を行う認証部３３と、この認可情報３２ａに基づき認可を行う認可部３４とを具備して構成される。

サービス提供サーバ２０は、ＨＴＭＬコンテンツ、画像などの各種情報や、Ｗｅｂアプリケーションなどのリソースを保持するＷｅｂサーバ２２を具備して構成されており、クライアント端末１０からのＷｅｂブラウザ１１を介したｈｔｔｐ（HyperText Transfer Protocol）リクエスト（以下、単にリクエストと略す場合もある）に応じてこれら情報等を提供する。

ここで、Ｗｅｂサーバ２２では、Ｗｅｂブラウザ１１からのリクエストを直接受信することはせず、必ず、ＳＳＯモジュール２１を介して受信する。また、このリクエストに対するＷｅｂサーバ２２からの応答もこのＳＳＯモジュール２１を介してＷｅｂブラウザ１１へ返送することになる。すなわち、クライアント端末１０とＷｅｂサーバ２２間のデータ通信は、必ずＳＳＯモジュール２１を中継して行われることになり、このＳＳＯモジュール２１とＷｅｂサーバとが同一サーバ内に配置されているため、コンテンツの書き換えを行う必要がなくなる。

また、ＳＳＯモジュール２１では、ＳＳＯ情報サーバ３０と連携し、認証、認可を行うことになるが、このときの処理内容を示すログをログサーバ４０へ出力する。このログサーバ４０へ出力されたログは、ログサーバ４０のログ管理部４１において、記憶管理されることになる。

このログサーバ４０においては、各サービス提供サーバ２０から送られてくるログ４１ａを一元して管理するため、保守、保全の面でも使い勝手が良いといえる。また、ＳＳＯモジュール２１から切り離してログが管理されることになるため、万一ＳＳＯモジュール２１が配置されたサーバが不正アクセスされたとしても、侵入者がログを削除あるいは改竄して形跡を隠す脅威を軽減することができる。なお、このログサーバ４０に改竄検知機能を組み込んでもよい。また、ログサーバ４０は、１台でなく複数台配してもよく、その場合、可用性の向上や改竄防止を見込める。

次に、図２を用いて、この図１に示すサービス提供サーバ２０の機能的な構成の一部について説明する。

サービス提供サーバ２０は、その機能構成として大きく、ＳＳＯモジュール２１と、Ｗｅｂサーバ２２とに分けられ、ここで、ＳＳＯモジュール２１内部には、各種処理機能部として、ネットワーク通信部６１と、制御部６２と、認証部６３と、認可部６４と、ログ出力部６５と、Ｗｅｂサーバ通信部６６とが備えられる。

ネットワーク通信部６１は、ネットワーク５０上の各端末からの通信を司る機能を果たす。すなわち、Ｗｅｂサーバ２２に対するネットワーク５０からのリクエストを、このネットワーク通信部６１において受け付け、これをＷｅｂサーバ２２へ中継することになる。

制御部６２は、ＳＳＯモジュール２１の動作を統括制御する。すなわち、このＳＳＯモジュール２１を構成する各種処理機能は、この制御部６２からの指示に従って動作する。また、制御部６２は、各処理機能部間で発生するデータの入出力を制御する。

認証部６３は、ＳＳＯ情報サーバ３０の認証部３３と連携することで、認証処理を実行する機能を果たす。この認証部６３における認証処理の詳細については、後述する図４および図５を用いて説明することとする。

認可部６４は、認証後、ユーザから指定されたリソースへのアクセスを許可するか否かの認可を行う機能を果たす。この認可は、ＳＳＯ情報サーバ３０への問い合わせに基づき行われる。なお、この認可は従来からの一般的な方法で実現でき、例えば、リソースの特定には、リクエストが指し示すホスト、パス、拡張子などを参照することで行える。ＳＳＯ情報サーバ３０との通信がボトルネックにならないように認可結果をキャッシュするようにしてもよい。この認可部６４における認可処理の詳細については、後述する図６を用いて説明することとする。

ログ出力部６５は、ＳＳＯモジュール２１においてなされた処理、特に、認証や、認可に関する処理内容を示すログを作成し、それを出力する機能を果たす。なお、Ｗｅｂサーバ２２間とのデータ通信等に関するログなども作成ならびに出力するようにしてもよく、認証、認可に関するログだけに限られず、幅広くログを採るようにしてもよい。

Ｗｅｂサーバ通信部６６は、Ｗｅｂサーバ２２との通信を司る機能を果たす。すなわち、Ｗｅｂサーバ通信部６６では、Ｗｅｂブラウザ１１からのリクエスト等を、Ｗｅｂサーバ２２へ転送することになる。このとき、Ｗｅｂサーバ２２側へは、Ｃｏｏｋｉｅを含むｈｔｔｐリクエストヘッダでユーザの識別情報等を渡すことになる。ここで、このｈｔｔｐリクエストヘッダが偽装されていないことを保証するために、このヘッダにメッセージ認証子やデジタル署名を付与するように構成してもよい。なお、Ｗｅｂサーバ２２側で、ローカルからのリクエストだけを受け付けるように設定しておき、このＷｅｂサーバ通信部６６以外からのデータ通信を受け付けないようにすることで、ＳＳＯモジュール２１をバイパスしてＷｅｂサーバ２２に直接アクセスしたり、ＩＰアドレス偽装攻撃（IP Spoofing）等によって、ＳＳＯモジュール２１以外からアクセスされる危険を回避することができる。

ここで、図３を用いて、この図１および図２に示す通信システムの動作について説明する。なお、ここでは、サービス提供サーバ２０において、Ｗｅｂブラウザ１１からのｈｔｔｐリクエストを受け付けた場合の動作について説明する。

ＳＳＯモジュール２１のネットワーク通信部６１で、Ｗｅｂブラウザ１１からのｈｔｔｐリクエストを受け付けると、この処理は開始される（ステップＳ１０１でＹＥＳ）。この処理が開始されると、まず、認証部６３において、このリクエスト送信元のユーザに対する認証が済んでいるか否かを判断する。なお、認証済みであるか否かの判断は、ＳＳＯ情報サーバ３０への問い合わせや、Ｃｏｏｋｉｅを参照することで行うことができる。

ここで、未認証であると判断された場合（ステップＳ１０２でＮＯ）、認証処理が行われることになるが（ステップＳ１０３）、既に認証済みであると判断された場合には（ステップＳ１０２でＹＥＳ）、次に、認可部６４において、リソースに対するアクセスを許可するか否かを判断する認可処理が行われる（ステップＳ１０４）。なお、このステップＳ１０３における認証処理、ステップＳ１０４における認可処理の詳細については後述する。

この認可処理の結果、当該リソースに対するアクセス権がないと判断された場合には（ステップＳ１０５でＮＯ）、アクセス権が無い旨をユーザに伝えるなどしてこの処理を終了することになるが、アクセス権があると判断された場合には（ステップＳ１０５でＹＥＳ）、ＳＳＯモジュール２１のＷｅｂサーバ通信部６６では、Ｗｅｂブラウザ１１からのリクエストを、Ｗｅｂサーバ２２へ転送する（ステップＳ１０６）。

このリクエストの転送を受けたＷｅｂサーバ２２では、当該リクエストに応じてＷｅｂアプリケーション等を実行するとともに、その結果をＷｅｂサーバ通信部６６へと返す（ステップＳ１０７）。これを受けたＷｅｂサーバ通信部６６では、この応答をネットワーク通信部６１に伝え、そこからさらにＷｅｂブラウザ１１へと転送し（ステップＳ１０８）、この処理は終了することになる。

次に、図４を用いて、図３のステップＳ１０３における認証処理の流れについて説明する。図４には、図１および図２に示す通信システムにおける認証処理の流れの一例を示すシーケンス図が示されており、ここでは、ユーザ認証前の処理の流れについて説明する。

Ｗｅｂブラウザ１１からのｈｔｔｐリクエストが送られてくると（ステップＳ２０１）、ＳＳＯモジュール２１では、まず、認証部６３において、リクエスト送信元のＷｅｂブラウザ１１との間にセッションが存在するか否かを判断する。ここでは、初回のアクセスであるため、セッションは存在しない（ステップＳ２０２）。そのため、認証部６３は、ＳＳＯ情報サーバ３０へのリダイレクトをＷｅｂブラウザ１１に指示する（ステップＳ２０３）。このとき、Ｗｅｂブラウザ１１へは、リダイレクト先であるＳＳＯ情報サーバ３０のＵＲＬとともに、戻り先であるサービス提供サーバ２０のＵＲＬを含む情報が送られる。

Ｗｅｂブラウザ１１は、リダイレクトに従って自動的に、ＳＳＯ情報サーバ３０へアクセスする（ステップＳ２０４）。このＳＳＯ情報サーバ３０へのアクセスは、リダイレクトによって行われるため、ユーザが特段の操作を行う必要はない。

ＳＳＯ情報サーバ３０では、Ｗｅｂブラウザ１１からのリクエストを受けると、この時点では、Ｗｅｂブラウザ１１との間にセッションがないため（ステップＳ２０５）、新規にセッションを生成するとともに、Ｗｅｂブラウザ１１へ認証画面を送信する（ステップＳ２０６）。この認証画面の送信は、認証部３３により行われ、認証画面には、アカウントやパスワード等の認証情報を入力するための入力項目が設けられる。

Ｗｅｂブラウザ１１上に認証画面が表示され、それに伴ってユーザが認証情報を入力すると（ステップＳ２０７）、入力された認証情報がＷｅｂブラウザ１１からＳＳＯ情報サーバ３０へと送られる（ステップＳ２０８）。すると、ＳＳＯ情報サーバ３０の認証部３３において、ユーザ認証が行われる（ステップＳ２０９）。この認証は、送られてきた認証情報と、認証情報管理部３１で管理された認証情報３１ａとに基づき行われる。

この認証の結果、認証情報に誤りがあれば、Ｗｅｂブラウザ１１には認証失敗が応答され、これを受けたユーザは再度認証を行うか、あるいは処理を終了することになるが、認証が正常に行われると、Ｗｅｂブラウザ１１に対してＳＳＯ情報サーバ３０への第１の認証チケット（Ｃｏｏｋｉｅ）が発行される（ステップＳ２１０）。なお、この第１の認証チケットは、ＳＳＯ情報サーバ３０に対してのみ提示されるため、この第１の認証チケットでは、ＳＳＯモジュール２１を利用することはできない。

また、この応答では、サービス提供サーバ２０のＵＲＬが指定され、サービス提供サーバ２０へのリダイレクトが指示される（ステップＳ２１１）。これは、ユーザのもともとのアクセス先がサービス提供サーバ２０であったためである。

このリダイレクトによって、Ｗｅｂブラウザ１１は自動的に、サービス提供サーバ２０へアクセスする（ステップＳ２１２）。ＳＳＯモジュール２１では、認証部６３において、リクエスト送信元のＷｅｂブラウザ１１との間にセッションが存在するか否かを判断する。ここでは、上述したステップＳ２０１におけるアクセスによりセッションが存在しているため、セッションありとなる（ステップＳ２１３）。

セッションが存在すると、認証部６３は、ＳＳＯ情報サーバ３０の認証部３３に対し、ユーザの認証状況を問い合わせる（ステップＳ２１４）。この問い合わせの結果、認証済みが返送されると（ステップＳ２１５）、この通知を受けた認証部６３は、ＳＳＯモジュール２１のみに有効な第２の認証チケットをＷｅｂブラウザ１１に対して発行する（ステップＳ２１６）。これにより、ＳＳＯモジュール２１に対する認証が済むことになり、２度目以降のアクセスに際しては、Ｗｅｂブラウザ１１が、この第２の認証チケットを提示することで、再度認証が要求されることはない。

認証処理が済むと、ＳＳＯモジュール２１のログ出力部６５では、この上述したＳＳＯモジュール２１での認証処理の処理内容を示すログを、ログサーバ４０へと送信する（ステップＳ２１７）。なお、この図４においては、認証処理が終了した段階でログサーバ４０へログを送信することになるが、この認証処理の過程で随時、ログを送信するようにしてもよい。

次に、図５を用いて、図３のステップＳ１０３における認証処理の流れについて説明する。図５には、図１および図２に示す通信システムにおける認証処理の流れの一例を示すシーケンス図が示される。この図５に示すシーケンスと、上記図４で説明したシーケンスは、Ｗｅｂブラウザ１１とＳＳＯ情報サーバ３０との間でセッションが存在するか否かと言う点において異なる（図４のステップＳ２０５と図５のステップＳ３０５）。すなわち、この図５には、ユーザ認証が済んでいる状態で（あるサービス提供サーバ２０を利用したため）、別のセッションのないサービス提供サーバ２０へアクセスした場合の処理の流れが示される。

Ｗｅｂブラウザ１１からのｈｔｔｐリクエストが送られてくると（ステップＳ３０１）、ＳＳＯモジュール２１では、まず、認証部６３において、リクエスト送信元のＷｅｂブラウザ１１との間にセッションが存在するか否かを判断する。ここでは、当該ＳＳＯモジュール２１へのアクセスは初めてであるため、セッションは存在しない（ステップＳ３０２）。そのため、認証部６３は、ＳＳＯ情報サーバ３０へのリダイレクトをＷｅｂブラウザ１１に指示する（ステップＳ３０３）。このとき、Ｗｅｂブラウザ１１へは、リダイレクト先であるＳＳＯ情報サーバ３０のＵＲＬとともに、戻り先であるサービス提供サーバ２０のＵＲＬを含む情報が送られる。

Ｗｅｂブラウザ１１は、リダイレクトに従って自動的に、ＳＳＯ情報サーバ３０へアクセスする（ステップＳ３０４）。このＳＳＯ情報サーバ３０へのアクセスは、リダイレクトによって行われるため、ユーザが特段の操作を行う必要はない。

Ｗｅｂブラウザ１１とＳＳＯ情報サーバ３０との間にはセッションが存在し（ステップＳ３０５）、また、認証済みであるため、Ｗｅｂブラウザ１１からＳＳＯ情報サーバ３０に対して第１の認証チケットが提示される。ＳＳＯ情報サーバ３０は、Ｗｅｂブラウザ１１から第１の認証チケットが提示されたことによって、認証済であることが分かり、改めてユーザの認証を行うことはない。ＳＳＯ情報サーバ３０は、サービス提供サーバ２０へのリダイレクトをＷｅｂブラウザ１１に対して指示する（ステップＳ３０６）。

このリダイレクトによって、Ｗｅｂブラウザ１１は自動的に、サービス提供サーバ２０へアクセスする（ステップＳ３０７）。ＳＳＯモジュール２１では、認証部６３において、リクエスト送信元のＷｅｂブラウザ１１との間にセッションが存在するか否かを判断する。ここでは、上述したステップＳ３０１におけるアクセスによりセッションが存在しているため、セッションありとなる（ステップＳ３０８）。

セッションが存在すると、認証部６３は、ＳＳＯ情報サーバ３０の認証部３３に対し、ユーザの認証状況を問い合わせる（ステップＳ３０９）。この問い合わせの結果、認証済みが返送されると（ステップＳ３１０）、この通知を受けた認証部６３は、ＳＳＯモジュール２１のみに有効な第２の認証チケットをＷｅｂブラウザ１１に対して発行する（ステップＳ３１１）。これにより、当該ＳＳＯモジュール２１に対する認証が済むことになり、２度目以降のアクセスに際しては、Ｗｅｂブラウザ１１が、この第２の認証チケットを提示することで、再度認証が要求されることはない。

認証処理が済むと、ＳＳＯモジュール２１のログ出力部６５では、この上述したＳＳＯモジュール２１での認証処理の処理内容を示すログを、ログサーバ４０へと送信する（ステップＳ３１２）。なお、この図５においては、認証処理が終了した段階でログサーバ４０へログを送信することになるが、この認証処理の過程で随時、ログを送信するようにしてもよい。

次に、図６を用いて、図３のステップＳ１０４における認可処理の流れについて説明する。図６には、図１および図２に示す通信システムにおける認可処理の流れの一例を示すシーケンス図が示される。

Ｗｅｂブラウザ１１からのリソースを指定したｈｔｔｐリクエストが送られてくると（ステップＳ４０１）、ＳＳＯモジュール２１の認可部６４では、当該ユーザによる当該リソースに対するアクセスを許可するか否かの判断を行う。そのため、認可部６４においては、まず、ＳＳＯ情報サーバ３０の認可部３４に対し、アクセス権を問い合わせることになる（ステップＳ４０２）。このとき、ＳＳＯ情報サーバ３０へは当該ユーザのユーザ識別情報とリソース指定情報とを含む情報が送られる。

ＳＳＯ情報サーバ３０の認可部３４においては、これら送られてきた情報に基づいて認可処理を行う（ステップＳ４０３）。すなわち、送られてきたユーザ識別情報およびリソース指定情報と、認可情報管理部３２で管理された認可情報３２ａとに基づき当該ユーザによる当該リソースに対するアクセスを許可するか否かの判断を行う。

この認可の結果、アクセス権がないならばＦＡＬＳＥが、アクセス権があるならばＴＲＵＥが、ＳＳＯ情報サーバ３０からＳＳＯモジュール２１へと返され（ステップＳ４０４）、これを受けた認可部６４では、この結果に基づきリソースに対するアクセスの認可を行う（ステップＳ４０５）。

認可処理が済むと、ＳＳＯモジュール２１のログ出力部６５では、この上述したＳＳＯモジュール２１での認可処理の処理内容を示すログを、ログサーバ４０へと送信する（ステップＳ４０６）。なお、この図６においては、認可処理が終了した段階でログサーバ４０へログを送信することになるが、この認可処理の過程で随時、ログを送信するようにしてもよい。

以上が本発明の代表的な実施形態の一例であるが、本発明は、上記および図面に示す実施例に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。

例えば、フォーム認証の場合、ＳＳＯ情報サーバ３０の認証部３３を用いず、フォーム認証のページにＳＳＯモジュール２１がアカウントとパスワードとを埋める。このとき、ＳＳＯモジュール２１とＷｅｂサーバ２２間は、ローカル通信であるため、パスワード等のデータが平文で通信されてもセキュリティの心配はない。

また、ＳＳＬ（Secure Socket Layer）非対応のＷｅｂアプリケーションがある場合、Ｗｅｂアプリケーションとのデータ通信はｈｔｔｐのままにしておき、クライアント端末１０とＳＳＯモジュール２１間のデータ通信をｈｔｔｐｓ（Hypertext Transfer Protocol Security）にするとＳＳＬ化にも対応できる。但し、ＵＲＬのスキーム（コロン「：」の前の部分）の書き換えが伴わないよう、このＷｅｂサーバ自身の配下にあるコンテンツのパスが相対で書かれていることを前提とする。

また、ＳＳＯモジュール２１とＷｅｂサーバ２２とを別々のマシンへ配置しても良い。これは、ＤＮＳ（Domain Name System）の設定と組み合わせることで実現できる。例えば、図７に示すように、ＤＮＳサーバ７０を配し、アクセス先のＷｅｂサーバ２２の名前が、ＳＳＯモジュール２１を配置したマシン（管理サーバ８０）に解決されるようにすることで、コンテンツの書き換えを回避できる。また、ＤＮＳの設定次第では、ＳＳＯモジュール２１を複数配置することもでき（例えば、サブネットごとにＳＳＯモジュール２１を配置する）、この場合、性能上のボトルネックを避けることができる。

また、認証機能を持たないｈｔｔｐ以外のプロトコルであっても、トランスポート層にＳＳＬを用いて相互認証することで対応することができる。

また、この通信システムに、ＩＤＳ（侵入検知システム）やＩＰＳ（侵入防止システム）を組み合わせてセキュリティの強化を図るようにしてもよい。

また、ＳＳＯモジュール２１の認証部６３において、ユーザ認証を行うようにしてもよい。すなわち、これは、上述したＳＳＯ情報サーバ３０の認証部３３の機能を、ＳＳＯモジュール２１の認証部６３に持たせると言うことである。この場合、認証情報３１ａは、上述した実施例と同様に、ＳＳＯ情報サーバ３０側で記憶管理し、ＳＳＯ情報サーバ３０への問い合わせに基づき認証を行うよう構成することが望ましいが、もちろん、認証情報３１ａをＳＳＯモジュール２１と同一端末上に配するようにしてもよい。なお、認可部６４についても、この認証部６３と同様の構成で実現してもよい。

また、上記実施例においては、ＳＳＯモジュール２１に認証部６３と認可部６４とを設け、認証と認可の両方を行う場合を例に挙げて説明したが、認可は必ずしも行う必要はなく、認可は行わないようにしてもよい。なお、認可を行う場合、コンテンツ単位ではなく、Ｗｅｂアプリケーション全体で設定してもよい。

また、上記実施例においては、ＳＳＯモジュール２１にログ出力部６５を設け、処理内容を示すログを出力する場合を例に挙げて説明したが、このログの出力は必ずしも行う必要はなく、ログの出力を行わないようにしてもよい。

また、上記実施例においては、本発明に係わる通信システムにより処理を実施する場合を説明したが、この処理をコンピュータにインストールされた制御プログラムにより実施するように構成してもよい。なお、この制御プログラムは、ネットワーク等の通信手段により提供することはもちろん、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することも可能である。

本発明の制御プログラムおよび通信システムは、リソースに対する認証処理をコンピュータに実行させる制御プログラムおよび通信システム全般に適用可能である。

本発明に係わる通信システムの全体構成の一例を示す図である。図１に示すサービス提供サーバ２０の機能的な構成の一部について説明する。図１および図２に示す通信システムの動作の一例を示すフローチャートである。図３のステップＳ１０３における認証処理の第１の動作を示すシーケンス図である。図３のステップＳ１０３における認証処理の第２の動作を示すシーケンス図である。図３のステップＳ１０４における認可処理の動作を示すシーケンス図である。本発明に係わる通信システムの変形例の一例を示す図である。

符号の説明

１０クライアント端末
１１Ｗｅｂブラウザ
２０サービス提供サーバ
２１ＳＳＯモジュール
２２Ｗｅｂサーバ
３０ＳＳＯ情報サーバ
３１認証情報管理部
３１ａ認証情報
３２認可情報管理部
３２ａ認可情報
３３認証部
３４認可部
４０ログサーバ
４１ログ管理部
４１ａログ
５０ネットワーク
６１ネットワーク通信部
６２制御部
６３認証部
６４認可部
６５ログ出力部
６６Ｗｅｂサーバ通信部
７０ＤＮＳサーバ
８０管理サーバ

Claims

リソース端末がリソースを記憶し、該リソースにアクセスする際に行う認証処理を該リソース端末とは別の端末に配設されたコンピュータに実行させる制御プログラムであって、
該コンピュータは、前記リソース端末の名前を該コンピュータに解決するネームサーバと接続され、
ブラウザからの前記リソースに対するリクエストに該リクエストを送信したユーザの認証済みを示す情報が提示されているか否かを判断する判断ステップと、
前記判断ステップによる判断の結果、認証済みを示す情報が提示されていない場合に、認証済みであるか否かを確認する確認ステップと、
前記確認ステップにより認証済みであることが確認された場合、認証済みを示す情報を前記ブラウザに発行する発行ステップと、
前記認証済みを示す情報が提示された場合は、前記ブラウザと前記リソース間のデータ通信を前記ネームサーバを介して中継する中継ステップと
を含む制御プログラム。
前記確認ステップは、
前記コンピュータと接続される特定の端末への問い合わせに基づき認証済みであるか否かの確認を行う
請求項１記載の制御プログラム。
認証済みであることが確認できない場合、前記ブラウザからのリクエストを前記特定の端末へリダイレクトすることにより認証を行わせるリダイレクトステップ
を更に含む請求項２記載の制御プログラム。
前記データ通信に際して、リソースに対するアクセスの認可を行う認可ステップ
を更に含む請求項１記載の制御プログラム。
前記認可ステップは、
前記特定の端末への問い合わせに基づき前記認可を行う
請求項４記載の制御プログラム。
別端末へログを出力するログ出力ステップ
を更に含む請求項１記載の制御プログラム。
第１の端末と、第２の端末と、リソース端末と、ネームサーバとが通信手段を介して接続される通信システムであって、
前記リソース端末は、
リソースを記憶し、
前記ネームサーバは、
前記リソース端末の名前を前記第２の端末に解決し、
前記第１の端末は、
認証情報に基づき認証を行う認証手段と、
認可情報に基づきリソースに対するアクセスの認可を行う第１の認可手段と
を具備し、
前記第２の端末は、
ブラウザからの前記リソースに対するリクエストに認証済みを示す情報が提示されているか否かを判断する判断手段と、
前記判断手段による判断の結果、認証済みを示す情報が提示されていない場合に、前記認証手段への問合せに基づき認証済みであるか否かを確認する確認手段と、
前記確認手段により認証済みであることが確認された場合、認証済みを示す情報を前記ブラウザに発行する発行手段と、
前記認証済みを示す情報が提示された場合は、前記第１の認可手段への問い合わせに基づき該リソースに対するアクセスの認可を行う認可手段と、
前記認証済みを示す情報が提示された場合は、前記ブラウザと前記リソース間のデータ通信を前記ネームサーバを介して中継する中継手段と
を具備する通信システム。
前記リソース端末が複数存在し、
前記複数のリソース端末に応じて前記第２の端末を一つ以上備える
請求項７記載の通信システム。