実施形態1.
本発明による第1の実施形態のアクセス制御システムについて、図面を参照して説明する。図1は、本発明による第1の実施形態のアクセス制御システムの構成例を示すブロック図である。
図1に示すように、本発明による第1の実施形態のアクセス制御システムは、通信端末2とサーバ3とを含み、通信端末2にはアプリケーションサーバ1が接続される。なお、通信端末2は、サーバ3にも接続される。
アプリケーションサーバ1は、通信端末2に提供されるアプリケーションプログラムであるアプリケーション12が格納されたアプリケーション格納部11を含む。アプリケーション12は、通信端末2によってダウンロードされる。
通信端末2は、アプリケーション取得手段21と、アプリケーション格納部22と、アプリケーション認証手段23と、証明書格納部24と、認証情報格納部25と、リクエスト手段26と、アプリケーション実行手段27とを含む。
サーバ3は、リクエスト受付手段31と、リクエスト認証手段32と、証明書格納部33と、サービス格納部34と、アクセス制御手段35と、ポリシ格納部36とを含む。
次に、ブロック図およびフローチャートを参照して本実施形態のアクセス制御システムの動作について説明する。
アクセス制御システムの動作は、(1)通信端末2が実行するアプリケーション認証処理、(2)通信端末2からサーバ3へのリクエスト処理、(3)サーバ3が実行するリクエスト認証処理、の3つの動作に分けられる。以下、本実施形態におけるそれぞれの処理について説明する。
まず、(1)通信端末2が実行するアプリケーション認証処理について、図面を参照して説明する。図2は、アプリケーション認証処理を示すフローチャートである。通信端末2のアプリケーション取得手段21は、アプリケーションサーバ1からアプリケーション12をダウンロード(DL)する(ステップS21)。
アプリケーション12に証明書が付加されている場合(ステップS22のYes)、アプリケーション認証手段23は、証明書検証処理(認証処理)を行う(ステップS23)。なお、証明書(電子証明書)とは、例えば、CA等が電子的な方法で署名した電子データである。証明書には、例えば、証明書保持者名、証明書保持者の公開鍵、CAのID、およびCAによる電子署名などが含まれる。
証明書検証処理は、例えば、証明書格納部24に格納されている証明書と、アプリケーション12に付加されている証明書とが合致するか否かを判断する処理である。なお、他の方法によって証明書検証処理が行われてもよい。
アプリケーション認証手段23は、ステップS23における証明書検証処理で、証明書格納部24に格納されている証明書と、アプリケーション12に付加されている証明書とが合致すると判断した場合に(ステップS24のYes)、認証情報格納部25に検証結果として認証情報を格納する(ステップS25)。具体的には、アプリケーション認証手段23は、認証情報格納部25に、アプリケーション情報と認証情報とを対応付けて格納する。認証情報は、証明書格納部24に格納されている証明書とアプリケーション12に付加されている証明書とが合致すると判断された場合に、認証情報格納部25に検証結果として格納されるので、認証情報が認証情報格納部25に格納されているということは、当該認証情報に対応付けられているアプリケーション情報によって示されるアプリケーションが証明書検証処理(認証処理)で認証されたということである。
図3は、認証情報格納部25に対応付けられて格納されているアプリケーション情報と検証結果との例を示す説明図である。図3に示す例では、アプリケーション情報は、アプリケーション12の格納場所を示すURL(Uniform Resource Locator)である。また、図3に示す例では、認証情報は、アプリケーション12に付加されていた証明書のハッシュ値である。図3に示す例では、アプリケーション情報は「http://appserver1/app12」である。図3に示す例では、認証情報であるハッシュ値は「92q8sldkfjd038u」である。そして、図3には、アプリケーション12のアプリケーション情報であるアプリケーション12の格納場所を示すURLと、アプリケーション12に付加されていた証明書のハッシュ値とが対応付けられて認証情報格納部25に格納されていることが示されている。本例では、認証情報は、アプリケーション12に付加されていた証明書のハッシュ値である。
そして、アプリケーション取得手段21は、ステップS21の処理でアプリケーションサーバ1からダウンロードしたアプリケーション12をアプリケーション格納部22に格納する(ステップS26)。
次に、(2)通信端末2からサーバ3へのリクエスト処理について説明する。図4は、リクエスト処理を示すフローチャートである。上述したステップS21の処理で通信端末2がダウンロードしたアプリケーション12のプログラム制御にもとづいて、通信端末2がサーバ3にアクセスする場合(接続要求(アクセス要求)する場合)を例に説明する。アプリケーション実行手段27が、アプリケーション格納部22に格納されているアプリケーション12の実行中に、アプリケーション12のプログラム制御にもとづいてサーバ3にアクセス要求を行う指示(以下、単にアクセス要求という)をリクエスト手段26に出力する(ステップS41)。
リクエスト手段26は、アクセス要求を受け取ると、認証情報格納部25からアプリケーション12に対応する認証情報を取得する(ステップS42)。具体的には、認証情報の取得を試みる。図3に示す例では、認証情報格納部25に、アプリケーション12のURLに対応付けられた認証情報が格納されているので(ステップS43のYes)、アプリケーション12のID(具体的には、アプリケーション12の格納場所を示すURL)をキーとして認証情報である証明書のハッシュ値を得る。リクエスト手段26は、認証情報取得後、アクセス要求に認証情報を付加し(ステップS44)、サーバ3にリクエスト(アクセス要求情報)を送信する(ステップS45)。図5は、本実施形態のアクセス要求情報の例を示す説明図である。図5に示す例では、アクセス要求情報には、要求元のアプリケーションID(アプリケーション12のURL)、要求する内容(要求内容情報)、認証情報が含まれる。図5に示す例では、アクセス要求情報は、アプリケーション12がサーバ3にdata001の送信を要求する情報である。
次に、(3)サーバ3が実行するリクエスト認証処理について、図面を参照して説明する。図6は、リクエスト認証処理を示すフローチャートである。リクエスト受付手段31は、通信端末2からのアクセス要求(具体的には、アクセス要求情報)を受け(ステップS61)、リクエスト認証手段32にアクセス要求情報を渡し、検証を行う(ステップS62)。
リクエスト認証手段32は、アクセス要求情報から認証情報を取り出し、証明書格納部33に予め格納されている証明書と合致するか否かを確認する。本例では、図5に示すように、アクセス要求情報に認証情報として証明書のハッシュ値が含まれているので、リクエスト認証手段32は、証明書格納部33に予め格納されている証明書のハッシュ値を計算し、計算結果のハッシュ値と認証情報によって示されるハッシュ値とが合致するか否かを確認する。
ここでは、認証情報によって示されるハッシュ値が証明書格納部33に予め格納されている認証機関a(CA_1)によって発行された証明書のハッシュ値と合致したこととする。その後、アクセス制御手段35は、ポリシ格納部36に格納されているポリシを参照して、アクセス可否の判定を行う(ステップS63)。なお、ポリシ(ポリシ情報)とは、どの認証機関が発行した証明書を有するアプリケーションに、どのデータへのアクセスを許可するのかを示す情報である。ポリシ格納部36には、認証機関のID(例えば、CA_1やCA_2、CA_3)と、認証機関のIDごとにアクセスを許可するデータ(例えば、data001やdata002、data003、data004)とが格納されている。
図7は、ポリシ格納部36に格納されているポリシの例を示す説明図である。図7に示す例では、認証機関a(CA_1)が発行した証明書を有するアプリケーションに、data001,data002,data003へのアクセスを許可し、認証機関b(CA_2)が発行した証明書を有するアプリケーションに、data003,data004へのアクセスを許可し、認証機関c(CA_3)が発行した証明書を有するアプリケーションに、data002へのアクセスを許可するポリシがポリシ格納部36に格納されていることが示されている。
本例では、アクセス要求情報に含まれるハッシュ値は認証機関a(CA_1)が発行した証明書のハッシュ値と合致するので、アプリケーション12によるdata001へのアクセスは許可されることになる(ステップS64のYes)。アクセス許可になった場合(ステップS64のYes)、リクエスト受付手段31は、サービス格納部34からデータ(data001)を取り出し(ステップS65)、通信端末2にレスポンスを返す(ステップS66)。具体的には、取り出したデータ(data001)を通信端末2に送信する。
本実施形態では、通信端末2がアプリケーションの認証情報をサーバ3に送信するので、サーバ3がどのアプリケーション(具体的には、どの認証機関で認証されたアプリケーション)の動作にもとづく要求なのかを把握することができる。また、サーバ3が認証情報を検証するので、通信端末2が行った認証処理の正当性を確認している。さらに、サーバ3のポリシ格納部36に格納されているポリシでアクセス制御を行うことができる。すなわち、通信端末2のユーザによって証明書格納部24に証明書が追加され、その証明書によってアプリケーションが認証されたとしても、サーバ3のリクエスト認証処理およびポリシを用いたアクセス制御でアクセスを拒絶可能であるため、サーバ3が意図しないアクセスを行われることはない。つまり、サーバ3に所定の認証機関によって発行された証明書にもとづくポリシを設定して、アプリケーションごとのアクセス制御を行うことができる。
すなわち、本実施形態では、サーバがリクエスト元のコンテンツごとにアクセス制限を行うことができる。その理由は、通信端末がリクエストにコンテンツの認証情報を付加してサーバに送信するからである。また、サーバのポリシでアクセス制限を行うことができることである。その理由は、通信端末から送信される認証情報にもとづいて、サーバ側が、自身のポリシで再度認証するための仕組みを有しているからである。
実施形態2.
本発明の第2の実施形態のアクセス制御システムについて、図面を参照して説明する。図8は、本発明による第2の実施形態のアクセス制御システムの構成例を示すブロック図である。
図8に示すように、本発明の第2の実施形態のアクセス制御システムには、図1に示す第1の実施形態における通信端末2に、追加証明書格納部28と検証手段29とが追加されている。また、本発明の第2の実施形態のアクセス制御システムにおけるサーバ3は、リクエスト認証手段32と証明書格納部33とを含んでいない。追加証明書格納部28には、通信端末2のユーザによって追加された証明書が格納される。検証手段29は、証明書検証処理で、アプリケーション12に付加されている証明書に合致する証明書が証明書格納部24に格納されている証明書であるのか否かを検証する。
本実施形態のアクセス制御システムの動作について説明する。本実施形態では、図2に示す(1)通信端末2が実行するアプリケーション認証処理におけるステップS23の処理で、アプリケーション12に付加されている証明書が、証明書格納部24に格納されている証明書、または追加証明書格納部28に格納されている証明書に合致するか否かを判断する。その他の処理は図2に示す第1の実施形態の(1)通信端末2が実行するアプリケーション認証処理と同様なため、説明を省略する。
次に、本実施形態の(2)通信端末2からサーバ3へのリクエスト処理について説明する。図9は、本実施形態において図4に示す第1の実施形態の(2)通信端末2からサーバ3へのリクエスト処理に追加される処理を示すフローチャートである。
第1の実施形態では、図4に示すステップS42の処理で、リクエスト手段26が認証情報を取得していたが、本実施形態では、リクエスト手段26が認証情報を取得した後に、検証手段29が認証情報格納部25から認証情報を取得する(ステップS91)。
また、第1の実施形態では、図4に示すステップS43の処理で認証情報がある場合は、認証情報を付加する処理(ステップS44)が行われていた。しかし、第2の実施形態では、ステップS44の処理を行う前に、検証手段29が認証情報の検証を行う(ステップS91)。検証手段29は、認証情報が、(1)通信端末2が実行するアプリケーション認証処理におけるステップS23の処理で、証明書格納部24に格納されている証明書によって検証されたか否かを確認する。
具体的には、証明書格納部24に格納されている証明書のハッシュ値を計算し、図3に例示されているアプリケーション12に付加されていた証明書のハッシュ値と合致するか否かを確認する。検証手段29は、合致した場合には、証明書格納部24に格納されている証明書によって検証されたアプリケーションからの要求であると判断する。合致しない場合は、追加証明書格納部28に格納されている追加された証明書によって検証されたと判断する。
証明書格納部24に格納されている証明書によって検証されたことが判断された場合(S92のYes)、ステップS44の処理に移行する。第1の実施形態のステップS44の処理では、リクエスト手段26が、アクセス要求に認証情報としてハッシュ値を付加したが、第2の実施形態では、リクエスト手段26が、ステップS44の処理でアクセス要求に認証機関のIDを付加する。図10は、本実施形態のアクセス要求情報の例を示す説明図である。図10に示す本実施形態のアクセス要求情報には、要求元のアプリケーションID(アプリケーション12のURL)、要求する内容、認証機関のIDが含まれる。なお、リクエスト手段26は、証明書格納部24に格納されている証明書から認証機関のIDを取得する。
次に、本実施形態の(3)サーバ3が実行するリクエスト認証処理について説明する。第1の実施形態では、図6に示すステップS62でアクセス要求情報の検証処理を行っていたが、本実施形態では、ステップS61の処理後にステップS63の処理に移行し、ステップS62の処理は行われない。すなわち、図10に示すように、サーバ3には、通信端末2から送信される認証情報に認証機関のIDが含まれるので、ステップS61の処理後にはステップS63のアクセス可否判定に移行する。その後の処理は、第1の実施の形態と同様であるので、説明を省略する。
本実施の形態では、通信端末2において、もともとインストールされている(予め認証情報格納部25に格納されている)証明書と追加された(追加証明書格納部28に格納されている)証明書とが分けて管理されている。そして、アプリケーションの証明書のハッシュ値がもともとインストールされている証明書のハッシュ値と合致した場合には、認証機関のIDがサーバ3に送信されるように構成されている。このため、通信端末2がサーバ3にアクセスする際、サーバ3は、アクセス元のアプリケーションがもともとインストールされている証明書によって認証されているか否かを判断することができる。従って、第1の実施形態と異なり、サーバ3側でリクエスト認証処理を行う必要がない。よって、サーバ3の処理負担を軽減することができる。
なお、本実施形態は、第1の実施形態においてサーバ3側で管理している証明書(証明書格納部33に格納されている証明書)が通信端末2で管理している証明書(証明書格納部24に格納されている証明書)と同一であることが前提である。
以下に、本発明の他の実施形態について述べる。以上に述べた第1の実施形態では、図2に示すステップS25の処理で、認証情報格納部25に証明書のハッシュ値を格納した。このハッシュ値は、独自のハッシュ関数を用いて証明書からハッシュ値を計算してもよいし、証明書に格納されているフィンガープリントを使用してもよい。さらに、証明書に格納されている暗号化フィンガープリントを複合したものを使用してもよい。
さらに、第1の実施形態では、通信端末2からサーバ3に送信される認証情報は、証明書のハッシュ値としていたが、これに限らない。すなわち、証明書そのものを送信してもよい。
さらに、第1の実施形態では、図6に示すステップS62において、サーバ3のリクエスト認証手段32は、通信端末2からのリクエストがあったときに証明書格納部33に格納されている証明書のハッシュ値を計算していたがこれに限られない。すなわち、リクエスト認証手段32が、証明書格納部33に格納されている証明書のハッシュ値を予め計算しておき、リクエストがあった際は、比較だけ行うように構成されていてもよい。
さらに、第1の実施形態では、通信端末2からサーバ3へのリクエスト前に、リクエスト手段26が認証情報格納部25からリクエスト元のアプリケーションに対応した認証情報を取得していたがこれに限られない。すなわち、リクエスト手段26がリクエスト元のアプリケーションに対応した認証情報を取得できればよい。例えば、リクエスト元のアプリケーションに対応した証明書を取得するようなgetCertificate()関数などのAPI(Application Programming Interface)があり、これをリクエスト手段26が発行することで証明書を取得し、その証明書からハッシュ値を計算し、サーバ3に送信する、といった流れであってもよい。この方法によれば、通信端末2が行うアプリケーション認証処理時に認証結果を認証情報格納部25に格納する必要はない。
さらに、第1の実施形態および第2の実施形態では、サーバ3の証明書格納部33に格納されている証明書は更新されないことが前提であったが、これに限られない。また、更新された証明書を通信端末2に通知し、通信端末2において証明書格納部24に格納された証明書を更新する手段が設けられていてもよい。この場合、通信端末2に証明書更新手段を設け、サーバ3から通知、または通信端末2が定期的にポーリングし、証明書格納部24に格納されている証明書を更新する仕組みが設けられていてもよい。
さらに、第2の実施形態では、図8に示したように証明書格納部24と追加証明書格納部28とが分けられていたが、同じ格納部であってもよく、論理的に分かれていればよい。すなわち、通信端末2からサーバ3にリクエストを送信する前に、検証手段29によってもともとインストールされていた証明書によってアプリケーションが検証されているか否かがわかるように構成されていればよい。
さらに、第1の実施形態および第2の実施形態では、通信端末2がサーバ3にリクエストを送信する際、図5に例示したようにアプリケーションIDも送信していたが、これに限られない。すなわち、認証情報、つまり誰にお墨付きをもらったアプリケーションであるのかという認証機関の情報がアクセス要求情報に含まれていれば、アプリケーションIDは送信されなくてもよい。
さらに、第1の実施形態および第2の実施形態では、図6に示すステップS63のアクセス可否判定において、図7に例示したCAのIDとアクセス可能データとの対応付けテーブルが用いられていたが、対応付けの組み合わせはこれに限られない。すなわち、URLとアクセス可能データとの対応付けであってもよいし、CAのIDとURLとアクセス可能データとの組合せであってもよい。
次に、具体的な実施例を用いて本発明によるアクセス制御システムの動作を説明する。本実施例では、通信端末(通信端末2)が、搭載しているウェブブラウザの起動中にウェブサーバ(アプリケーションサーバ1)に格納されているウェブアプリケーションを実行し、サーバ(サーバ3)に格納されているデータにアクセスする場合を例に説明する。
まず、(1)通信端末2が行うアプリケーション認証処理について説明する。通信端末2のユーザは、ウェブブラウザを用いてウェブサーバ(アプリケーションサーバ1)にアクセスする(接続処理を行う)。ウェブサーバのURLが「https」で始まる場合には、SSL通信が行われることが示されており、ウェブサーバと通信端末2との間で証明書のやり取りが行われる。
具体的には、アプリケーション認証手段23が、例えば、ウェブサーバが信頼できる認証機関によってウェブアプリケーションが承認されているかを、アプリケーションサーバ1から送信された証明書と、証明書格納部24に格納されているルート証明書とを用いて確認する。本実施例では、アプリケーションサーバ1が信頼されていることを前提とし、認証情報格納部25にアプリケーションサーバ1のURLとルート証明書のハッシュ値とが対応付けられて格納されているとする。図11は、本実施例において、認証情報格納部25に格納されたウェブサーバのURLと証明書のハッシュ値とを示す説明図である。図11に示すように、本実施例では、認証情報格納部25には、ウェブサーバのURLである「https:appserver1.com」と、ルート証明書のハッシュ値である「3jlsdk0dl03j0817eub」とが格納されている。
ルート証明書を用いたウェブアプリケーションの確認後、ウェブサイトのHTML(HyperText Markup Language)ファイルを表示する。このHTMLファイルにウェブアプリケーションが組み込まれている場合、そのブラウザの起動中にウェブアプリケーションが実行される。具体的には、アプリケーション格納部22に格納されたウェブアプリケーションをアプリケーション実行手段27が実行する。
次に、(2)通信端末2からサーバ3へのリクエスト処理について説明する。ウェブアプリケーションは、サーバ3のAPIを発行する(具体的には、例えば、APIキーを発行する)ことで、サーバ3のサービス格納部34に格納されたデータのリクエストを行う。これは例えば、「call(http://appserver3.com?getData(“data001”))」などのAPIを発行することで、サーバ3に「data001」の送信を要求する。
ウェブアプリケーションが本APIを発行すると、リクエスト手段26はこれを検知する(具体的には、例えば、リクエスト手段26は、ウェブアプリケーションのプログラム制御にもとづいてアプリケーション実行手段27がAPIキーを発行したことを検知する)。そして、認証情報格納部25からリクエスト元のウェブアプリケーション(実際にはウェブアプリケーション配信元のサーバ。つまりアプリケーションサーバ1)に対応した認証情報を取り出す。リクエスト手段26は、この認証情報を付加して、サーバ3にリクエスト(具体的には、例えば、アクセス要求情報)を送信する。図12は、HTTPリクエストヘッダに認証情報を付加する例を示す説明図である。図12に示す例では、リクエスト元アプリケーションの情報として「referer」を設定し、認証情報として「x-cert-hash」を設定している。
次に、(3)サーバ3が実行するリクエスト認証処理について説明する。リクエスト受付手段31が通信端末2からのリクエストを受けた際(例えば、通信端末2が送信したアクセス要求情報を受信した際)、リクエスト認証手段32は、HTTPヘッダから認証情報を取得する。HTTPヘッダから認証情報を取得する方法には、例えば、「getHTTPHeader(“referer”)」などのAPIを呼び出し、リクエスト元のウェブアプリケーションの情報と認証情報とを取得する方法がある。リクエスト認証手段32は、取得した認証情報と証明書格納部33に格納されている証明書とが合致するか否か検証する。
図13は、各認証機関が発行したルート証明書のハッシュ値の例を示す説明図である。本実施例では、図13に示すように証明書のハッシュ値が予め計算されていることとし、各ハッシュ値が証明書の発行元のCAのIDと対応付けられていることとする。これによると、通信端末2が送信した認証情報によって示されるハッシュ値とCA_1のハッシュ値とが合致するため、リクエスト元のアプリケーション(を格納しているアプリケーションサーバ1)が確かにCA_1によって承認されていることがわかる。
ここで合致しない場合には、通信端末2は、リクエスト元のアプリケーション(アプリケーションサーバ1に格納されているアプリケーション)は信頼できるアプリケーションであると認識するが、サーバ3は(サーバ3のポリシでは)、それ(アプリケーションサーバ1に格納されているアプリケーション)は信頼できないアプリケーションである、と認識する。例えば、通信端末2において、ユーザによって追加された証明書(追加証明書)によってアプリケーションが認証されると、そのように(通信端末2が送信した認証情報によって示されるハッシュ値とCA_1のハッシュ値とが合致しない)なると考えられる。つまり、リクエスト(具体的には、例えば、アクセス要求情報)に追加証明書のハッシュ値が付与されて送信されると、サーバ側にはこの証明書は存在しない(例えば、サーバ3の証明書格納部33に格納されていない)ので、リクエスト認証の段階で、リクエストに付与されている証明書と自身が保持する証明書が合致しない、という結果になる。
認証処理を終えると、アクセス制御手段35は、CA_1(によって発行された証明書を有するアプリケーション)に対するポリシを確認する。これは、前述した図7に示したように、CA_1が発行した証明書を有するアプリケーションに、data001へのアクセスを許可するポリシがポリシ格納部36に格納されているため、アクセス権があると判断される。その後、リクエスト受付手段31は、サービス格納部34に格納されているdata001を取り出し、HTTPのレスポンスに追加し、通信端末2に返す(送信する)。
なお、本実施例は、ウェブアプリケーションを対象としていたが、これに限らない。例えば、JAVA(登録商標)アプリケーションなどにも適用できる。JAVAアプリケーションのダウンロード時にその実行環境であるJAVAVM(JAVA Virtual Machine)がアプリケーションの認証を行い、アプリケーションとアプリケーションに対応付けられた証明書を管理する。JAVAアプリケーションからサーバにデータの送信要求があった際は、JAVAVMがそれを検知し、リクエストに対応する証明書のハッシュ値を付加してサーバに送信することで実現できる。
本発明は、その他のアプリケーションにも適用できる。すなわち、機器固有のネイティブアプリケーションや、スクリプト言語で作成されたアプリケーションなどにも適用できる。また、アプリケーションに限らず、コンテンツにも適用できる。すなわち、HTMLファイルなどにも適用できる。HTMLファイルの場合は、自身のタグ(Aタグなど)でイメージファイルを読み込む際、他サイトにリンクが貼られている場合がある。その他サイトにおいて、どのHTMLファイルからアクセスされたのかを判断し、イメージファイルの提供に関するアクセス制御を行う、などに利用できる。
次に、本発明の概要について説明する。図14は、本発明の概要を示すブロック図である。図14に示すように、本発明によるアクセス制御システムは、サーバ(図1に示されたサーバ3に相当)100と通信端末(図1に示された通信端末2に相当)200とを備える。そして、通信端末200は、端末認証手段(図1に示されたアプリケーション認証手段23に相当)201、およびリクエスト手段(図1に示されたリクエスト手段26に相当)202を含む。また、サーバ100は、ポリシ情報格納手段(図1に示されたポリシ格納部36に相当)101、サーバ認証手段(図1に示されたリクエスト認証手段32に相当)102、アクセス制御手段(図1に示されたアクセス制御手段35に相当)103および処理実行手段(図1に示されたリクエスト受付手段34に相当)104を含む。
端末認証手段201は、コンテンツに付加されている電子証明書を用いて当該コンテンツの認証処理を行い、認証処理で認証したコンテンツと、認証処理で認証されたことを示し、電子証明書にもとづく情報であるコンテンツの認証情報とを対応付けて管理する。
リクエスト手段202は、コンテンツの実行動作に伴ってサーバ100にアクセスする場合に、当該コンテンツの認証情報と、サーバ100に要求する処理を示す要求内容情報とを含むリクエストをサーバ100に送信する。
ポリシ情報格納手段101は、通信端末200が送信したリクエストに含まれる認証情報および要求内容情報にもとづいて、リクエストに応じた処理を実行するか否かを示すポリシ情報を予め格納する。
サーバ認証手段102は、通信端末200が送信したリクエストに含まれる認証情報にもとづいてリクエストの認証を行う。
アクセス制御手段103は、サーバ認証手段102がリクエストを認証した場合に、ポリシ情報格納手段101に格納されているポリシ情報と、リクエストに含まれる認証情報および要求内容情報とにもとづいて、要求内容情報によって示される処理を実行するか否かを決定する。
処理実行手段104は、アクセス制御手段103が要求内容情報によって示される処理を実行すると決定した場合に、処理を実行する。
そのような構成により、通信端末200のリクエスト手段202がコンテンツの認証情報をサーバ100に送信するので、サーバ100がどのコンテンツ(具体的には、どの認証機関で認証されたコンテンツ)の動作にもとづく要求なのかを把握することができる。そして、サーバ100のアクセス制御手段103がポリシ情報格納手段101に格納されているポリシ情報にもとづいて当該要求に応じた処理を実行するか否かを決定するので、サーバ100のポリシ情報格納手段101に格納されているポリシ情報にもとづいてアクセス制御を行うことができる。よって、例えば、通信端末200のユーザによって証明書が追加され、その証明書によってコンテンツが認証されていたとしても、サーバ100のポリシ情報にもとづいてアクセスを拒絶可能であるため、サーバ100が意図しないアクセスを行われることはない。つまり、サーバ100に所定の認証機関によって発行された証明書にもとづくポリシを設定して、コンテンツごとにアクセス制御を行うことができる。
上記の各実施形態には、以下のようなアクセス制御システムも開示されている。
端末認証手段201が、コンテンツの電子証明書のハッシュ値、フィンガープリント、または電子証明書自体を当該コンテンツの認証情報として当該コンテンツに対応付けて管理するアクセス制御システム。
検証手段が、コンテンツの認証処理で用いられた電子証明書が予め記憶手段に記憶されている電子証明書に合致するか否かを検証するアクセス制御システム。そのような構成によれば、通信端末200がサーバ100にアクセスする際、サーバ100は、アクセス元のコンテンツがもともとインストールされている証明書によって認証されているか否かを判断することができる。よって、サーバ100側で認証処理を行う必要がなくなり、サーバ100の処理負担を軽減することができる。
端末認証手段によってコンテンツに対応付けて管理される当該コンテンツの認証情報には、コンテンツの電子証明書の発行元のIDが含まれているアクセス制御システム。コンテンツとしてアプリケーションプログラムを扱うアクセス制御システム。
通信端末200が検証手段(図8に示された検証手段29に相当)を含み、サーバ100がサーバ認証手段102を含まない構成が開示されている。
検証手段が、サーバ100にアクセスする場合に、当該コンテンツの認証処理で用いられた電子証明書が所定の電子証明書であるか否かを検証するように構成されている通信端末。
そのような構成によれば、前述した効果に加えて、通信端末200側で、コンテンツの認証処理で用いられた電子証明書が所定の電子証明書であるか否かを検証するので、サーバ100側で認証処理を行う必要がない。よって、サーバ100の処理負担を軽減することができる。
以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2009年11月9日に出願された日本特許出願2009-255908を基礎とする優先権を主張し、その開示の全てをここに取り込む。
産業上の利用の可能性
本発明を、PCや携帯電話機などの通信機器からウェブサービスを利用する際のアクセス制限に適用できる。