JP2007272689A - オンラインストレージ認証システム、オンラインストレージ認証方法、及びオンラインストレージ認証プログラム - Google Patents

Abstract

【課題】オンラインストレージサービスにおいて、アプリケーションサーバ側でクライアントを認証することができるとともに、異なるセキュリティポリシーのクライアントの要求に応じた認証方式を採用することができるようにすることを目的とする。
【解決手段】クライアント端末３０ＡからのリクエストにおけるＵＲＬの種類にもとづいて付加されたクライアント認証方式情報にもとづいて、Ｗｅｂアプリケーションサーバ５０Ａが、クライアントの認証方式を決定し、決定した認証方式に従ってクライアントの認証処理を実行する。
【選択図】図９

Description

本発明は、クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を行い、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容するオンラインストレージサーバを備えたオンラインストレージ認証システム、オンラインストレージ認証方法、及びオンラインストレージ認証処理を実行させるためのオンラインストレージ認証プログラムに関する。

従来から、通信ネットワークシステムにおいて、本人認証のための様々な認証方式が提案され実施されている。この認証方式としては、ＩＤ／パスワード方式が一般的であるが、そのセキュリティの脆弱さが指摘されている。このため、このＩＤ／パスワード方式に代わり、電子証明書による認証方式が利用されるようになってきている。

ウェブ（ＨＴＴＰ：Hypertext Transfer Protocol）上での電子証明書を用いた認証方式では、一般に、ＳＳＬ（Secure Socket Layer）を利用し、そのＳＳＬセッション上で交換されるＨＴＴＰフレームのヘッダにクライアント証明書の証明結果やその証明書情報を埋め込み、そのＨＴＴＰフレームのヘッダをアプリケーションサーバが利用するようにしている（特許文献１）。

このＳＳＬにおいて、クライアントの電子証明書を要求する場合は、どのクライアント証明書を利用するかという選択画面がブラウザ上に表示される。この電子証明書の格納場所として、ローカルコンピュータ上だけでなく、ＵＳＢトークンといった外部媒体が利用されている。

また、一般的なＷｅｂシステムにおいて、企業毎(以下、「コーポレート毎」と呼ぶ)に契約しサービスを受けることができるＡＳＰサービスも存在する。さらに、特許文献１や非特許文献１におけるＸｄｒｉｖｅ（登録商標）システムのようなウェブ技術を用いたオンラインストレージにおいては、ウェブシステムであっても、クライアントアプリケーションとして、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒのようなブラウザだけでなく、ブラウザのようなＧＵＩを持たずあたかもローカルディスクであるかのように振舞うアプリケーションを用いるものがある。このブラウザのようなＧＵＩをもたずあたかもローカルディスクであるかのように振舞うアプリケーションをここではＤＴＡ（デスクトップアプリケーション）と呼ぶ。ブラウザとは異なり、このＤＴＡはローカルキャッシュにオンラインストレージ上のデータ(ファイル)を持つ。

特表２００３−５１４２７９ "Ｘｄｒｉｖｅ"、［ｏｎｌｉｎｅ］、［平成１８年３月３０日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ:／／ｗｗｗ．ｘｄｒｉｖｅ．ｊｐ／＞

あるＷｅｂを用いたアプリケーションをＡＳＰ（アプリケーション・サービス・プロバイダ）が提供している場合において、そのＷｅｂアプリケーションを利用したい企業毎にセキュリティポリシーが異なる場合がある。例えば、企業ＡはＩＤ／パスワードのみ、企業Ｂは電子証明書のみ、企業ＣはＩＤ／パスワードかつ電子証明書による認証を求める場合がある。

電子証明書を用いてクライアント認証を行う場合にはクライアント端末側に電子証明書を選択する画面を出すが、電子証明書を用いたクライアント認証を行わない場合には電子証明書の選択画面を出すべきでない。ところが、電子証明書を用いたクライアント認証を行う場合と行わない場合との区別を行うことができないため、セキュリティポリシーが異なるユーザの要求を同一のアプリケーションサーバで制御することはできない。

本発明は、上述した問題を解消し、オンラインストレージサーバ側でコーポレート毎にクライアント認証方法を決定することを可能とし、その認証方法に応じた認証手段をクライアントアプリケーションに提供することができるとともに、コーポレートのユーザ毎に異なるセキュリティポリシーを持つ場合においても、クライアントの要求に応じた認証方式を採用することができるようにするオンラインストレージシステムを提供することを目的とする。

本発明のオンラインストレージ認証システムは、クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を行い、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容するオンラインストレージサーバを備えたオンラインストレージ認証システムであって、前記オンラインストレージサーバは、前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定手段と、該認証方式決定手段が決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理手段とを有することを特徴とする。

クライアント端末からのリクエストを受け付けて、オンラインストレージサーバに転送するリクエスト転送装置をさらに備え、該リクエスト転送装置は、前記クライアント端末からのリクエストが示すアクセス先情報に応じてクライアント認証方式を特定し、特定したクライアント認証方式を示すクライアント認証方式情報を前記リクエストに付加するクライアント認証方式情報付加手段と、該クライアント認証方式情報付加手段によりクライアント認証方式情報が付加されたリクエストを前記オンラインストレージサーバに転送するリクエスト転送手段とを有する構成とされていてもよい。

クライアント認証方式には、例えば、電子証明書による電子証明書認証方式と、ＩＤ／パスワードによるパスワード認証方式とを含む。

クライアント端末には、インターネットエクプローラのようなWebブラウザが搭載されてもよいし、ブラウザのようなＧＵＩを持たずあたかもローカルディスクのようにオンラインストレージを扱うことを可能にするアプリケーション(ＤＴＡ) が搭載されていてもよい。

リクエスト転送装置は、特定したクライアント認証方式に電子証明書認証方式が含まれていたときは、リクエストに添付されている電子証明書を用いた電子証明書認証処理を行う電子証明書認証処理手段を有し、クライアント認証方式情報付加手段は、前記電子証明書認証処理手段による電子証明書認証処理の処理結果を示す電子証明書認証結果をオンラインストレージサーバでのクライアント認証方式としてクライアント認証方式情報に含める構成とされていてもよい。

認証方式決定手段は、クライアント認証方式情報に電子証明書認証結果が含まれていた場合には、該電子証明書認証結果の確認によりクライアントを認証する認証方式を含むことに決定し、クライアント認証処理手段は、前記認証方式決定手段の決定に従って、前記電子証明書認証結果を確認し、その確認結果にもとづくクライアントの認証処理を実行する構成とされていてもよい。

また、本発明のオンラインストレージ認証方法は、クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を行い、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容するオンラインストレージ認証方法であって、前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定処理と、該認証方式決定処理にて決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理とを含むことを特徴とする。

さらに、本発明のオンラインストレージ認証プログラムは、クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を実行させ、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容させるオンラインストレージ認証プログラムであって、コンピュータに、前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定処理と、該認証方式決定処理にて決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理とを実行させるためのものである。

本発明によれば、オンラインストレージサーバ側でコーポレート毎にクライアント認証方法を決定することを可能とし、その認証方法に応じた認証手段をクライアントアプリケーションに提供することができるとともに、コーポレートのユーザ毎に異なるセキュリティポリシーを持つ場合においても、クライアントの要求に応じた認証方式を採用することができる

以下、本発明の実施の形態について図面を参照して説明する。
図１は、本発明の一実施の形態におけるユーザ認証システム１００の構成例を示すブロック図である。

図１に示すように、ユーザ認証システム１００は、管理端末１０と、ＣＡ局（認証局）サーバ２０と、コーポレート端末（ユーザ端末）３０Ａ〜３０Ｃと、ＳＳＬProxy+HTTPロードバランサ４０と、アプリケーションサーバ５０Ａ〜５０Ｃと、各アプリケーションサーバ５０Ａ〜５０Ｃに接続されたＤＢ５１とを含む。管理端末１０、ＣＡ局サーバ２０、コーポレート端末３０Ａ〜３０Ｃ、及びＳＳＬProxy+HTTPロードバランサ４０は、インターネットや専用回線などの通信ネットワーク６０に接続されている。また、アプリケーションサーバ５０Ａ〜５０Ｃは、ＳＳＬProxy+HTTPロードバランサ４０を介して通信ネットワーク６０に接続されている。

管理端末１０は、パーソナルコンピュータなどの情報処理装置であって、本システム１００を管理するシステム管理者に使用される端末装置である。

ＣＡ局サーバ２０は、例えばＷＷＷサーバやワークステーションサーバなどの情報処理装置によって構成され、認証局によって管理される。ＣＡ局サーバ２０は、電子証明書の発行や管理などを行う。

コーポレート端末３０Ａ〜３０Ｃは、それぞれ、パーソナルコンピュータなどの情報処理装置であって、アプリケーションサーバ５０Ａ〜５０Ｃによって提供されるサービスを受けるクライアント端末である。本例では、コーポレート端末３０Ａ〜３０Ｃは、企業単位で使用されるユーザ端末を想定している。

ＳＳＬProxy+HTTPロードバランサ４０は、コーポレート端末３０Ａ〜３０Ｃからのアプリケーション利用要求を一元的に管理し、その要求をアプリケーションサーバ５０Ａ〜５０Ｃに転送する負荷分散装置である。

アプリケーションサーバ５０Ａ〜５０Ｃは、例えばＷＷＷサーバなどの情報処理装置によって構成され、例えばコンテンツの提供などの本人認証を経た上で提供される各種のサービスを実行するための機能を備えている。

アプリケーションサーバ５０Ａ〜５０Ｃは、本例では、例えば「Ｘdrive」などのＷｅｂ技術を活用したオンラインストレージサービスを提供するためのＷｅｂアプリケーションサーバである。従って、アプリケーションサーバ５０Ａ〜５０Ｃは、正規のクライアントからのリクエストに応じて、自己が管理する図示しない記憶装置に各種のデータを保存する機能や、保存している各種のデータを提供する機能などを有する。

図２は、ＳＳＬProxy+HTTPロードバランサ４０の構成の例を示すブロック図である。図２には、アプリケーションサーバ５０Ａ〜５０Ｃなども示されている。図２に示すように、ＳＳＬProxy+HTTPロードバランサ４０は、ＳＳＬポリシー部４１と、ロードバランサ部４２とを含む。

本例では、ＵＲＬａ「ｈｔｔｐｓ：／／ｓｅｃｕｒｅ．ｘｄｒｉｖｅ．ｊｐ」を指定したアクセスと、ＵＲＬｂ「ｈｔｔｐｓ：／／ｘｄｒｉｖｅ．ｊｐ」を指定したアクセスと、ＵＲＬｃ「ｈｔｔｐ：／／ｘｄｒｉｖｅ．ｊｐ」を指定したアクセスとが受け付けられるものとする。なお、本例では、ＵＲＬａに対するアクセスは電子証明書による認証を必要とするアクセスであり、ＵＲＬｂ及びＵＲＬｃに対するアクセスは電子証明書による認証を必要としないアクセスであるものとする。

ＳＳＬProxy+HTTPロードバランサ４０は、コーポレート端末３０Ａ〜３０Ｃからのリクエストを受けると、リクエストにおいて指定されているＵＲＬの種類を判別し、ＨＴＴＰヘッダにＳＳＬポリシーを付加する（埋め込む）処理などを行う。

ＳＳＬProxy+HTTPロードバランサ４０は、コーポレート端末３０Ａ〜３０Ｃからのリクエストを受けると、リクエストにおいて指定されているＵＲＬの種類を判別し、判別結果に応じて電子証明書の指定・選択画面をコーポレート端末３０Ａ〜３０Ｃに提示する。具体的には、電子証明書による認証が必要であるＵＲＬａであったときは、電子証明書の指定・選択画面を提示し、コーポレート端末３０Ａ〜３０Ｃから電子証明書を取得する。なお、電子証明書による認証が必要でないＵＲＬｂ，ＵＲＬｃであったときは、電子証明書の指定・選択画面は提示しない。また、ＳＳＬProxy+HTTPロードバランサ４０は、取得した電子証明書による認証処理を実行する。さらに、ＳＳＬProxy+HTTPロードバランサ４０は、リクエストにおいて指定されているＵＲＬの種類の判別結果や、電子証明書の認証結果にもとづき、ＨＴＴＰヘッダにＳＳＬポリシーを付加する（埋め込む）処理などを行う。

具体的には、ＳＳＬProxy+HTTPロードバランサ４０は、指定されているＵＲＬがＵＲＬａであった場合には、ＳＳＬProxy部４１のＳＳＬ情報付加部４１ａにより、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）であることを示すプロトコル情報と、電子証明書による認証結果を示す証明書認証結果情報とを、ＳＳＬポリシーとしてリクエストにおけるＨＴＴＰヘッダに付加する。そして、ＳＳＬ情報付加部４１ａは、ＨＴＴＰヘッダを含むリクエストをロードバランサ部４２のバランサ４２ａに送信する。すると、バランサ４２ａは、ＨＴＴＰヘッダを含むリクエストをアプリケーションサーバ５０Ａ〜５０Ｃのいずれかに送信する。

また、ＳＳＬProxy+HTTPロードバランサ４０は、指定されているＵＲＬがＵＲＬｂであった場合には、ＳＳＬProxy部４１のＳＳＬ情報付加部４１ｂにより、ＨＴＴＰＳであることを示すプロトコル情報を、ＳＳＬポリシーとしてリクエストにおけるＨＴＴＰヘッダに付加する。そして、ＳＳＬ情報付加部４１ｂは、ＨＴＴＰヘッダを含むリクエストをロードバランサ部４２のバランサ４２ｂに送信する。すると、バランサ４２ｂは、ＨＴＴＰヘッダを含むリクエストをアプリケーションサーバ５０Ａ〜５０Ｃのいずれかに送信する。

さらに、ＳＳＬProxy+HTTPロードバランサ４０は、指定されているＵＲＬがＵＲＬｃであった場合には、ＳＳＬProxy部４１によるＨＴＴＰヘッダへの情報の追加を行うことなく、リクエストをロードバランサ部４２のバランサ４２ｂに送信する。すると、バランサ４２ｂは、ＳＳＬポリシーが付加されていないＨＴＴＰヘッダを含むリクエストをアプリケーションサーバ５０Ａ〜５０Ｃのいずれかに送信する。

図３（Ａ）は、コーポレート追加オプション管理テーブルを示す説明図である。図３（Ｂ）は、ユーザ管理テーブルを示す説明図である。コーポレート追加オプション管理テーブル及びユーザ管理テーブルは、管理端末１０によって設定され、ＤＢ５１に登録される。

コーポレート追加オプション管理テーブルには、図３（Ａ）に示すように、各コーポレートについて、それぞれ、コーポレートＩＤと、オプション名と、属性（ＰＫＩグループ情報）とが対応付けされて設定されている。

本例では、コーポレート端末３０Ｂを管理するコーポレートは、コーポレートＩＤが「コーポレートＢ」、オプション名が「ＰＫＩ」、属性が「Ｐ９９９９９９９９９」に設定されている。また、コーポレート端末３０Ｃを管理するコーポレートは、コーポレートＩＤが「コーポレートＣ」、オプション名が「ＰＫＩ＋ＩＤ／パスワード」、属性が「Ｐ１２３４５６７８９」に設定されている。さらに、コーポレート端末３０Ａを管理するコーポレートは、コーポレートＩＤが「コーポレートＡ」、オプション名が「その他オプション」、属性が「Ｎｕｌｌ」に設定されている。

なお、オプション名が「ＰＫＩ」であるとは、ＰＫＩ（Public Key Infrastructure）対応のドメイン（ｓｅｃｕｒｅ．ｘｄｒｉｖｅ．ｊｐ）のみアクセス可能であることを意味する。また、オプション名が「ＰＫＩ＋ＩＤ／パスワード」であるとは、ＰＫＩ対応のドメイン及びＩＤ／パスワード対応のドメイン（ｘｄｒｉｖｅ．ｊｐ）の両方にアクセス可能であることを意味する。さらに、オプション名が「その他オプション」であるとは、ＰＫＩ対応のドメイン以外のＩＤ／パスワード対応のドメイン（ｘｄｒｉｖｅ．ｊｐ）にアクセス可能性であることを意味する。

ユーザ管理テーブルには、図３（Ｂ）に示すように、各ユーザについて、それぞれ、ユーザＩＤと、コーポレートＩＤと、クライアント認証有無と、パスワード入力と、パスワード省略有無とが対応付けされて設定されている。

本例では、図３（Ａ）に示したように、コーポレートＢは電子証明書が必要で、図３（Ｂ）に示したように、コーポレートＢのユーザはパスワード必要／不必要を選択することができる。また、図３（Ａ）に示したように、コーポレートＣは電子証明書とＩＤ／パスワードのいずれかが必要で、図３（Ｂ）に示したように、コーポレートＣのユーザは電子証明書の利用の有無を選択することができる。なお、図３（Ｂ）には示されていないが、コーポレートＣのユーザはパスワード必要／不必要を選択することもできる。さらに、図３（Ａ）に示したように、コーポレートＡはＩＤ／パスワードが必要で、図３（Ｂ）に示したように、コーポレートＡのユーザは電子証明書の利用を選択することはできない。

例えば、あるユーザＸは、ユーザＩＤが「ユーザ１」、コーポレートＩＤが「コーポレートＢ」、クライアント認証有無が「利用する」、パスワード入力が「必要」、パスワード省略有無が「ＸＸＸＸＸＸＸ」に設定されている。従って、ユーザＸは、ユーザＩＤとして「ユーザ１」が付与されており、コーポレートＢに所属しており、電子証明書によるクライアント認証が必要であり、ＩＤ／パスワードによる認証が必要であり、パスワードの入力操作は不要であることになる。すなわち、コーポレートＢのユーザ１は電子証明書を用いて認証し、かつＩＤ／パスワードの認証も必要となる。

また、あるユーザＹは、ユーザＩＤが「ユーザ２」、コーポレートＩＤが「コーポレートＢ」、クライアント認証有無が「利用する」、パスワード入力が「不要」に設定されている。従って、ユーザＹは、ユーザＩＤとして「ユーザ２」が付与されており、コーポレートＢに所属しており、電子証明書によるクライアント認証が必要であり、ＩＤ／パスワードによる認証が不要であることになる。すなわち、コーポレートＢのユーザ２は、電子証明書の認証のみで、それが成功であればログイン画面に遷移することとなる。

図４は、クライアント認証とパスワード入力、及び利用ドメインの関係を示す説明図である。本例では、クライアント認証の有無、クライアント認証を利用しない場合の使用ドメイン、ＩＤ／パスワードによる認証の有無により、図４に示す６つの認証パターンＡ〜Ｆがある。

本例では、コーポレートＡは、認証パターンＣのみを利用可能であり、ＵＲＬｂを用いたドメイン（ｘｄｒｉｖｅ．ｊｐ）に対するアクセスが可能である。また、コーポレートＢは、認証パターンＡ，Ｄを利用可能であり、ＵＲＬａを用いたドメイン（ｓｅｃｕｒｅ．ｘｄｒｉｖｅ．ｊｐ）に対するアクセスが可能である。さらに、コーポレートＣは、認証パターンＡ，Ｂ，Ｃ，Ｄを利用可能であり、ＵＲＬｂを用いたドメイン（ｘｄｒｉｖｅ．ｊｐ）に対するアクセス及びＵＲＬｂを用いたドメイン（ｘｄｒｉｖｅ．ｊｐ）に対するアクセスが可能である。

次に、本例のユーザ認証システム１００の動作について説明する。
図５，図６は、本例のユーザ認証システム１００におけるアプリケーションサーバ５０Ａ〜５０Ｃが実行するログイン処理の例を示すフローチャートである。ここでは、ＳＬＬProxy+HTTPロードバランサ４０から転送されてきたリクエストを受信したことに応じて、アプリケーションサーバ５０Ａがログイン処理を実行する場合を例に説明する。

ログイン処理において、アプリケーションサーバ５０Ａは、先ず、受信したリクエストに含まれているＨＴＴＰヘッダに証明書認証結果情報が含まれているか否かを確認することで、アクセス対象のドメインがドメインＡ「ｘｄｒｉｖｅ．ｊｐ」であるかドメインＢ「ｓｅｃｕｒｅ．ｘｄｒｉｖｅ．ｊｐ」であるか確認する（ステップＳ１０１）。

ＨＴＴＰヘッダに証明書認証結果情報が含まれていなければ、アプリケーションサーバ５０Ａは、アクセス対象のドメインがドメインＡであると判定し、ＨＴＴＰヘッダのプロトコル情報を確認する（ステップＳ１０２）。ＨＴＴＰヘッダにプロトコル情報が含まれていなければ、アプリケーションサーバ５０Ａは、認証パターンＣの認証処理（ＩＤ／パスワードによる認証処理）を行うことに決定する（ステップＳ１０３）。一方、ＨＴＴＰヘッダにＳＳＬポリシーとしてＨＴＴＰＳであることを示すプロトコル情報が含まれていれば、アプリケーションサーバ５０Ａは、認証パターンＢの認証処理（ＩＤ／パスワードとＳＳＬ認証（電子証明書による認証を除く）による認証処理）を行うことに決定する（ステップＳ１０４）。

ＨＴＴＰヘッダにＳＳＬポリシーとして証明書認証結果情報が含まれていれば、アプリケーションサーバ５０Ａは、アクセス対象のドメインがドメインＢであると判定し、証明書認証結果情報が示すクライアント証明書の認証結果を確認する（ステップＳ１０５）。

認証結果がなければ、アプリケーションサーバ５０Ａは、認証パターンＢの認証処理を行うことに決定する（ステップＳ１０６）。認証結果が認証失敗であれば、アプリケーションサーバ５０Ａは、エラーページを送信する（ステップＳ１０７）。

認証結果が認証成功であれば、アプリケーションサーバ５０Ａは、既登録ユーザに関するユーザ情報を含むクライアント証明書情報（ユーザの属性を示すユーザ属性情報：図３（Ｂ）参照）をＤＢ５１から取得し（ステップＳ１０８）、ユーザの存在確認を行う（ステップＳ１０９）。ユーザが存在していないと判定したときは、アプリケーションサーバ５０Ａは、エラーページを送信する（ステップＳ１０７）。

ユーザが存在していると判定したときは、アプリケーションサーバ５０Ａは、ＤＢ５１から認証ポリシー（グループセキュリティポリシー：図３（Ａ）参照）を取得し（ステップＳ１１０）、取得した認証ポリシーに応じて、認証パターンＤの認証処理を行うことに決定（ステップＳ１１１）、認証パターンＡの認証処理を行うことに決定（ステップＳ１１２）、あるいは認証パターンＤに加えてバイオメトリクス認証による認証処理を行うことに決定する（ステップＳ１１３）。なお、グループセキュリティポリシーにおける属性（図３（Ａ）参照）により、バイオメトリクス認証による認証処理を行うか否かが判定される。

認証パターンＡ，Ｂ，Ｃのいずれかである場合には、アプリケーションサーバ５０Ａは、ＩＤ／パスワード入力画面を表示するための処理を行う（ステップＳ１１４）。そして、入力されたＩＤ／パスワードが正規のＩＤ／パスワードであると確認すると（ステップＳ１１５）、アプリケーションサーバ５０Ａは、ログイン後画面を表示するための処理を行う（ステップＳ１１６）。

認証パターンＤである場合には、アプリケーションサーバ５０Ａは、ログイン後画面を表示するための処理を行う（ステップＳ１１６）。

バイオメトリクス認証による認証処理を行う場合には、アプリケーションサーバ５０Ａは、バイオメトリクス認証画面を表示するための処理を行い（ステップＳ１１７）、入力あるいは指定されたバイオメトリクス認証情報が正規の情報であると確認すると（ステップＳ１１８）、ログイン後画面を表示するための処理を行う（ステップＳ１１６）

なお、上述した実施の形態では、ステップＳ１０５にて認証結果がなければ、アプリケーションサーバ５０Ａが、認証パターンＢの認証処理を行うことに決定する（ステップＳ１０６）ように構成していたが、図７，図８に示すように、ステップＳ１０５にて認証結果がなければ、認証パターンＣの認証処理を行うことに決定する（ステップＳ１０４）ようにしてもよい。

図９は、本例のユーザ認証システム１００における電子証明書認証と認証結果の確認処理の例を示すタイミングチャートである。ここでは、コーポレート端末３０Ｂは、先ず、ＳＳＬProxy+HTTPロードバランサ４０との間でＳＳＬセッションを構築したあと、ＨＴＴＰＳリクエストをＳＳＬProxy+HTTPロードバランサ４０に送付する（ステップＳ１）。

ＳＳＬProxy+HTTPロードバランサ４０は、ＨＴＴＰＳリクエストに含まれている電子証明書にもとづく認証結果（クライアント認証結果）と証明書情報とを含む証明書認証結果情報と、プロトコル情報とを、ＳＳＬポリシーとしてＨＴＴＰリクエストヘッダに追加し（ステップＳ２）、そのヘッダを含むＨＴＴＰリクエストを例えばＷｅｂアプリケーションサーバ５０Ａに送付する（ステップＳ３）。

ＨＴＴＰリクエストを受けると、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ＨＴＴＰリクエストヘッダに含まれている証明書情報に応じたユーザ情報を確認し（ステップＳ４）、ＤＢ５１からユーザ属性情報（図３（Ｂ）参照）を読み出す（ステップＳ５）。次いで、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ユーザ属性情報から対象ユーザが属するコーポレートについてのグループセキュリティポリシー（図３（Ａ）のテーブルに設定されているコーポレートのポリシー）を確認し（ステップＳ６）、ＤＢ５１からグループセキュリティポリシーを取得する（ステップＳ７）。

次に、Ｗｅｂアプリケーションサーバ５０Ａは、コーポレート及びユーザ認証ポリシーに応じたＷｅｂページを作成し（ステップＳ８）、ＳＳＬProxy+HTTPロードバランサ４０にＨＴＴＰレスポンスを送付する（ステップＳ９）。

そして、ＳＳＬProxy+HTTPロードバランサ４０は、コーポレート端末３０ＢにＨＴＴＰＳレスポンスを送付する（ステップＳ１０）。ＨＴＴＰＳレスポンスを受信すると、コーポレート端末３０Ｂは、自己が備える表示装置に、ＨＴＴＰＳレスポンスに含まれているＷｅｂページ（例えば、ログイン後の画面、エラー画面、バイオメトリクス情報入力画面など）を表示する。

以上に説明したように、クライアント端末からのリクエストが示すアクセス先情報（ＵＲＬ）にもとづいて付加されたクライアント認証方式情報（ＳＳＬポリシー）により、クライアントの認証方式を決定し、決定した認証方式に従ってクライアントの認証処理を実行する構成としたので、オンラインストレージサーバ側でクライアント毎に認証方法を決定することができ、その認証方法に応じた認証手段（ＨＴＴＰＳレスポンスに含まれているＷｅｂページ）をクライアントアプリケーションに提供することができる。また、クライアントのユーザ毎に異なるセキュリティポリシーを持つ場合においても、クライアントの要求に応じた認証方式を採用することができる。

また、上述した実施の形態では、電子証明書による認証が必要であることが特定可能なアクセス先情報（ＵＲＬａ）であったときにのみ、電子証明書の指定・選択画面をクライアント端末に提示する構成としたので、電子証明書による認証が必要でないクライアントに電子証明書の指定・選択画面が提示されてしまうことを防止することができ、セキュリティレベルを向上させることができる。

すなわち、電子証明書を用いたクライアント認証を行う場合と行わない場合との区別をアクセス先情報により行う構成としたので、電子証明書による認証が必要でないクライアントに電子証明書の指定・選択画面が提示されてしまうことを確実に防止することができ、セキュリティポリシーが異なるユーザの要求を同一のアプリケーションサーバで制御することができる。

なお、上述した実施の形態では、ＳＳＬProxy+HTTPロードバランサ４０を用いる構成としていたが、他の負荷分散装置を用いるようにしてもよい。この場合、例えば図１０に示すように、負荷分散装置としてＳＳＬロードバランサ４５を用いる構成とし、ＳＳＬロードバランサ４５に上述したＳＳＬProxy+HTTPロードバランサ４０が有する機能を持たせ、ＳＳＬProxy４１が有する機能をＷｅｂアプリケーションサーバ５０Ａ〜５０Ｃに持たせるようにすればよい。

この場合の処理フローを図１１に示す。図１１は、図１０に示すユーザ認証システムにおける電子証明書認証と認証結果の確認処理の例を示すタイミングチャートである。ここでは、コーポレート端末３０Ｂは、先ず、ＳＳＬロードバランサ４５によって決定されたＷｅｂアプリケーションサーバ５０Ａ〜５０Ｃのいずれかとの間でＳＳＬセッションを構築したあと、ＨＴＴＰＳリクエストをＳＳＬセッションを構築したＷｅｂアプリケーションサーバ（ここではＷｅｂアプリケーションサーバ５０Ａとする）に送付する（ステップＳ１）。

ＨＴＴＰリクエストを受けると、Ｗｅｂアプリケーションサーバ５０Ａは、ＨＴＴＰＳリクエストに含まれている電子証明書にもとづく認証結果（クライアント認証結果）と証明書情報とを含む証明書認証結果情報と、プロトコル情報とを、ＳＳＬポリシーとしてＨＴＴＰリクエストヘッダに追加する（ステップＳ２）。

次いで、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ＨＴＴＰリクエストヘッダに含まれている証明書情報に応じたユーザ情報を確認し（ステップＳ４）、ＤＢ５１からユーザ属性情報（図３（Ｂ）参照）を読み出す（ステップＳ５）。次いで、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ユーザ属性情報から対象ユーザが属するコーポレートについてのグループセキュリティポリシー（図３（Ａ）のテーブルに設定されているコーポレートのポリシー）を確認し（ステップＳ６）、ＤＢ５１からグループセキュリティポリシーを取得する（ステップＳ７）。

次に、Ｗｅｂアプリケーションサーバ５０Ａは、コーポレート及びユーザ認証ポリシーに応じたＷｅｂページを作成し（ステップＳ８）、コーポレート端末３０ＢにＨＴＴＰＳレスポンスを送付する（ステップＳ１０）。

また、上述した実施の形態では、ＳＳＬProxy+HTTPロードバランサ４０を用いる構成としていたが、例えば図１２に示すように、ＳＳＬProxy+HTTPロードバランサ４０に代えて、ＨＴＴＰロードバランサ４８と、ＶＰＮ終端装置４６と、ＶＰＮ認証情報管理サーバ４７とを設ける構成としてもよい。なお、図１３は、図１２の構成とした場合における処理タイミング図である。

図１３に示すように、コーポレート端末３０Ｂは、先ず、ＶＰＮ終端装置４６との間でリモートアクセスＶＰＮを構築する（ステップＳ２１）。リモートアクセスＶＰＮが構築されると、ＶＰＮ終端装置４６は、ユーザ名、割り当てたＩＰアドレス、及び認証方式をＶＰＮ認証情報管理サーバ４７に登録する（ステップＳ２２）。

次いで、コーポレート端末３０Ｂは、ＨＴＴＰロードバランサ４８によって選択されたＷｅｂアプリケーションサーバ５０Ａに対して、ＨＴＴＰリクエストを送付する（ステップＳ１）。

ＨＴＴＰリクエストを受けると、Ｗｅｂアプリケーションサーバ５０Ａは、ＶＰＮ認証情報管理サーバ４７にアクセスし、ＩＰアドレスからユーザ名を取得する（ステップＳ２３，Ｓ２４）。

次いで、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ＨＴＴＰリクエストヘッダに含まれている証明書情報に応じたユーザ情報を確認し（ステップＳ４）、ＤＢ５１からユーザ属性情報（図３（Ｂ）参照）を読み出す（ステップＳ５）。次いで、Ｗｅｂアプリケーションサーバ５０Ａは、ＤＢ５１にアクセスして、ユーザ属性情報から対象ユーザが属するコーポレートについてのグループセキュリティポリシー（図３（Ａ）のテーブルに設定されているコーポレートのポリシー）を確認し（ステップＳ６）、ＤＢ５１からグループセキュリティポリシーを取得する（ステップＳ７）。

次に、Ｗｅｂアプリケーションサーバ５０Ａは、グループセキュリティポリシーに応じたＷｅｂページを作成し（ステップＳ２５）、コーポレート端末３０ＢにＨＴＴＰレスポンスを送付する（ステップＳ９）。

また、上述した実施の形態においては特に言及していないが、本システム１００を構成する各部（例えばアプリケーションサーバ５０Ａ〜５０Ｃ、ＳＳＬProxy+HTTPロードバランサ４０等）は、本システム１００に搭載された制御プログラム（例えばクライアント認証プログラム）によって上述した各種の処理を実行している。

なお、上述した実施の形態では、コーポレート端末３０Ａ〜３０Ｃを管理する各コーポレートがクライアントであるものとして説明したが、クライアントの単位はコーポレートでなくてもよい。

本発明によれば、アプリケーションサーバ側でクライアントを認証し、異なるセキュリティポリシーのクライアントの要求に応じた認証方式を採用するのに有用である。

本発明の一実施の形態におけるユーザ認証システムの構成例を示すブロック図である。 ＳＳＬProxy+HTTPロードバランサの構成の例等を示すブロック図である。 図３（Ａ）は、コーポレート追加オプション管理テーブルを示す説明図である。図３（Ｂ）は、ユーザ管理テーブルを示す説明図である。 クライアント認証とパスワード入力、及び利用ドメインの関係を示す説明図である。 本発明の一実施の形態におけるユーザ認証システムにおけるアプリケーションサーバが実行するログイン処理の例を示すフローチャートである。 本発明の一実施の形態におけるユーザ認証システムにおけるアプリケーションサーバが実行するログイン処理の例を示すフローチャートである。 本発明の一実施の形態におけるユーザ認証システムにおけるアプリケーションサーバが実行するログイン処理の他の例を示すフローチャートである。 本発明の一実施の形態におけるユーザ認証システムにおけるアプリケーションサーバが実行するログイン処理の他の例を示すフローチャートである。 本例のユーザ認証システムにおける電子証明書認証と認証結果の確認処理の例を示すタイミングチャートである。 ユーザ認証システムの他の構成例を示すブロック図である。 他の例のユーザ認証システムにおける電子証明書認証と認証結果の確認処理の例を示すタイミングチャートである。 ユーザ認証システムのさらに他の構成例を示すブロック図である。 さらに他の例のユーザ認証システムにおける電子証明書認証と認証結果の確認処理の例を示すタイミングチャートである。

符号の説明

１０ 管理端末
２０ ＣＡ局サーバ
３０Ａ〜３０Ｃ コーポレート端末
４０ ＳＬＬProxy+HTTPロードバランサ
５０Ａ〜５０Ｃ Ｗｅｂアプリケーションサーバ
５１ ＤＢ
６０ 通信ネットワーク

Claims (10)

1. クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を行い、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容するオンラインストレージサーバを備えたオンラインストレージ認証システムであって、
   前記オンラインストレージサーバは、
   前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定手段と、
   該認証方式決定手段が決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理手段とを有する
   ことを特徴とするオンラインストレージ認証システム。
2. クライアント端末からのリクエストを受け付けて、オンラインストレージサーバに転送するリクエスト転送装置をさらに備え、
   該リクエスト転送装置は、
   前記クライアント端末からのリクエストが示すアクセス先情報に応じてクライアント認証方式を特定し、特定したクライアント認証方式を示すクライアント認証方式情報を前記リクエストに付加するクライアント認証方式情報付加手段と、
   該クライアント認証方式情報付加手段によりクライアント認証方式情報が付加されたリクエストを前記オンラインストレージサーバに転送するリクエスト転送手段とを有する
   請求項１記載のオンラインストレージ認証システム。
3. クライアント認証方式には、電子証明書による電子証明書認証方式と、ＩＤ／パスワードによるパスワード認証方式とを含む
   請求項２記載のオンラインストレージ認証システム。
4. リクエスト転送装置は、特定したクライアント認証方式に電子証明書認証方式が含まれていたときは、リクエストに添付されている電子証明書を用いた電子証明書認証処理を行う電子証明書認証処理手段を有し、
   クライアント認証方式情報付加手段は、前記電子証明書認証処理手段による電子証明書認証処理の処理結果を示す電子証明書認証結果をオンラインストレージサーバでのクライアント認証方式としてクライアント認証方式情報に含める
   請求項３記載のオンラインストレージ認証システム。
5. 認証方式決定手段は、クライアント認証方式情報に電子証明書認証結果が含まれていた場合には、該電子証明書認証結果の確認によりクライアントを認証する認証方式を含むことに決定し、
   クライアント認証処理手段は、前記認証方式決定手段の決定に従って、前記電子証明書認証結果を確認し、その確認結果にもとづくクライアントの認証処理を実行する
   請求項４記載のオンラインストレージ認証システム。
6. クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を行い、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容するオンラインストレージ認証方法であって、
   前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定処理と、
   該認証方式決定処理にて決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理とを含む
   ことを特徴とするオンラインストレージ認証方法。
7. クライアント端末からのリクエストが示すアクセス先情報に応じてクライアント認証方式を特定し、特定したクライアント認証方式を示すクライアント認証方式情報を前記リクエストに付加するクライアント認証方式情報付加処理と、
   該クライアント認証方式情報付加処理にてクライアント認証方式情報を付加したリクエストを転送するリクエスト転送処理とを含み、
   認証方式決定処理では、前記リクエスト転送処理にて転送したリクエストを前記クライアント端末からのリクエストとしてクライアントの認証方式を決定する
   請求項６記載のオンラインストレージ認証方法。
8. クライアント認証方式には、電子証明書による電子証明書認証方式と、ＩＤ／パスワードによるパスワード認証方式とを含む
   請求項７記載のオンラインストレージ認証方法。
9. クライアントによって管理されるクライアント端末からのリクエストにもとづいて前記クライアントの認証処理を実行させ、該認証処理により認証したことを条件に、通信ネットワークに接続された各種のデータを記憶する記憶装置へのアクセスを許容させるオンラインストレージ認証プログラムであって、
   コンピュータに、
   前記クライアント端末からのリクエストが示すアクセス先情報にもとづいて付加されたクライアント認証方式情報にもとづいて、前記クライアントの認証方式を決定する認証方式決定処理と、
   該認証方式決定処理にて決定した認証方式に従ってクライアントの認証処理を実行するクライアント認証処理とを
   実行させるためのオンラインストレージ認証プログラム。
10. コンピュータに、
    さらに、クライアント端末からのリクエストが示すアクセス先情報に応じてクライアント認証方式を特定し、特定したクライアント認証方式を示すクライアント認証方式情報を前記リクエストに付加するクライアント認証方式情報付加処理と、
    該クライアント認証方式情報付加処理にてクライアント認証方式情報を付加したリクエストを転送するリクエスト転送処理とを実行させ、
    認証方式決定処理では、前記リクエスト転送処理にて転送したリクエストを前記クライアント端末からのリクエストとしてクライアントの認証方式を決定させる
    ための請求項９記載のオンラインストレージ認証プログラム。

Images