JP2009223502A - 認証システム、認証方法、サーバ装置、認証装置、プログラム - Google Patents

Abstract

【課題】認証装置による認証をサーバ装置による認証に転用する認証技術において、サーバ装置が提供可能なソフトウェアリソースに応じて要求される認証方式に従って認証装置が認証を行う。
【解決手段】サーバ装置に、ソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すリソースクラスデータベースと、認証パターンとリソースクラスとの対応関係を表す認証パターンデータベースとが記憶され、認証装置に、認証パターンと認証方式との対応関係を表す認証方式データベースが記憶されている。サーバ装置ではソフトウェアリソースに対応するリソースクラスから認証パターンを特定し、認証装置ではサーバ装置で特定された認証パターンに対応する認証方式の組合せの中の認証方式で認証を行う。
【選択図】図７

Description

この発明は、多要素認証技術とシングルサインオン技術との組合せ技術に関する。

パスワード認証、生体情報を用いた認証、ＩＣカード認証、回線認証、その他さまざまな認証を組み合わせて認証強度を高めることを多要素認証と呼び、現在、徐々にインターネットバンキング等で利用されつつある。

一方、一度の認証で複数のコンピュータ（以下、サーバ装置という。）上のソフトウェアリソースの利用を可能にすることによって、ユーザが異なるサーバ装置上のソフトウェアリソースを利用する毎に認証を実施する必要をなくす機能をシングルサインオンと呼び、徐々にその実施が拡大しつつある（例えば非特許文献１参照）。

シングルサインオン技術として、ＯＡＳＩＳという団体が標準化を推進しているＳＡＭＬ ｖ２．０（非特許文献２参照）という方式が一般的になりつつあり、サーバ装置（サービスプロバイダー；ＳＰ）とユーザ装置（ユーザーエージェント；ＵＡ）とは別に認証装置（アイデンティティープロバイダー；ＩＤＰ）があり、認証を一括して実施する仕組みになっている。
エヌ・ティ・ティ・コミュニケーションズ株式会社、「マスターＩＤ」、[平成２０年３月５日検索]、インターネット〈ＵＲＬ：https://506506.ntt.com/masterid/〉 OASIS (Organization for the Advancement of Structured Information Standards), "Security Assertion Markup Language(SAML) v2.0"， [平成20年3月5日検索], インターネット <URL : http://www.oasis-open.org/specs/index.php#samlv2.0>

今後、認証に多要素認証技術およびシングルサインオン技術を利用するというニーズが高まると予想される。

認証装置と複数のサーバ装置との間でシングルサインオン認証を行う場合、各々のサーバ装置で採用される認証強度を確保する方針（ポリシー）が異なることが予想され、この際、認証装置がそれぞれのサーバ装置の要求する強度の認証に柔軟に対応する必要が生じるであろう。

一つのサーバ装置においてソフトウェアリソースの内容に応じて認証強度の異なる複数の認証が必要な例として、インターネットバンキングがある。単に口座の残高確認であればパスワードのみでいいが、振込み等の場合にはセキュリティを高めるために第２の認証を要求するといった仕組みが取り入れられている。

こうした複数の認証を必要とするサーバ装置同士がシングルサインオンで連携する場合として、高額の商品をネットショッピングで購入する場合が考えられる。高額取引である場合、複数の銀行口座から分割してネットショッピングサイトに入金することが考えられるが、各銀行サーバ装置にアクセスするたびに認証を実施しなければならなく、これを煩わしいとユーザが感じるであろう。このような状況に対して、各銀行サーバ装置がシングルサインオンで連携することが考えられるが、各銀行サーバ装置には銀行サーバ装置ごとのポリシーがあり、サービスに必要な認証方式の組み合わせが各銀行サーバ装置で一般的に異なることを考慮しなければならない。例えば取引額が５００万円として、Ａ銀行サーバ装置から３００万円、Ｂ銀行サーバ装置から１５０万円、Ｃ銀行サーバ装置から５０万円をネットショッピングサイトに入金する場合の例では、各銀行サーバ装置の振込金額等で定まる認証ポリシーに応じて、Ａ銀行サーバ装置ではパスワード認証、指紋認証、リスクベース認証を必要とし、Ｂ銀行サーバ装置では第１パスワード認証、第２パスワード認証、カード認証を必要とし、Ｃ銀行サーバ装置ではパスワード認証、カード認証を必要とするといったように、サービスに必要な認証方式の組み合わせが各銀行サーバ装置で異なる。

また、上述の銀行サーバ装置の場合と同様に、インターネットサービスプロバイダーは、サービスごとに認証のポリシーを持っており、このポリシーに基づいて各種認証の組み合わせを要求することが現実的であろう。

このような状況に鑑みて本発明は、認証装置による認証をサーバ装置による認証に転用する認証技術において、サーバ装置が提供可能なソフトウェアリソースに応じて要求される認証方式に従って認証装置が認証を行う技術を提供することを目的とする。

上記課題を解決するため、本発明では、サーバ装置の記憶部に、サーバ装置が提供可能なソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すリソースクラスデータベースと、認証パターンと少なくともリソースクラスとの対応関係を表す認証パターンデータベースとが記憶されており、認証装置の記憶部に、認証パターンと認証方式との対応関係を表す認証方式データベースが記憶されていることを、特徴の一つとする。サーバ装置のリソースクラス特定部は、リソースクラスデータベースを参照して、ソフトウェアリソースに対応するリソースクラスを特定する。そして、サーバ装置の認証パターン特定部が、認証パターンデータベースを参照して、特定されたリソースクラスに対応する認証パターンを特定する。この特定された認証パターンは、認証装置に送信される。認証装置の認証方式特定部は、認証装置の記憶部に記憶されている認証方式データベースを参照して、サーバ装置から受信した認証パターンに対応する認証方式の中から認証を行う認証方式を特定する。そして、認証装置の認証実行部が、特定された一つまたは複数の認証方式に従って認証を行う。この認証結果はサーバ装置に送信される。

つまり、サーバ装置では、ソフトウェアリソースに対応するリソースクラスから認証パターンを特定し、認証装置では、サーバ装置で特定された認証パターンに対応する認証方式の中から特定された認証方式で認証を行う。認証結果はサーバ装置に送信され、認証パターンに対応した認証結果としてサーバ装置に認識される。

本発明に拠れば、サーバ装置でソフトウェアリソースと認証パターンとの間に関連付けがなされており、認証装置で認証パターンと認証方式との間に関連付けがなされているから、サーバ装置で提供可能なソフトウェアリソースに応じて要求される認証方式に従って認証装置が認証を行うことができる。

図を参照しながら、本発明の実施形態について説明する。
本発明の実施形態である認証システム１は、相互に通信可能とされた、サーバ装置２００、認証装置３００から構成される（図１参照）。一つの認証装置３００に対して複数のサーバ装置２００が存在するのが通例の実施形態であり、この発明の理解を容易にする観点から、一つの認証装置３００に対して二つのサーバ装置２００、４００が存在する実施形態として説明する。

また、この実施形態では、各サーバ装置２００、４００の保有するソフトウェアリソースの提供に際して行われる認証として説明を行う観点から、リソース提供の相手方であってかつ認証装置３００が行う認証の対象であるユーザ装置１００が認証システム１に備わっている。

各サーバ装置２００、４００は中央処理装置、記憶装置、送受信装置などのハードウェアを備えたコンピュータで実現され、各サーバ装置２００、４００が発揮する機能構成部は所望の機能を発現するように記述されたプログラムを中央処理装置が解釈・実行することで実現される。ユーザ装置１００、認証装置３００についても同様である。

ユーザ装置１００は、各サーバ装置２００、４００のソフトウェアリソース（アプリケーションサービス、データ、その他種々のリソースを含む。）を指示する情報であるリソース指示情報を、サーバ装置２００あるいはサーバ装置４００に対して送信する送信部１０１と、認証装置３００との間で認証を行う認証処理部１０２とを備える（図１参照）。

サーバ装置２００は、記憶部２０９を備えており、この記憶部２０９に、後述するリソースクラスデータベース２０９ｂと認証パターンデータベース２０９ｃが記憶される。また、ユーザ装置１００からリソース指示情報を受信する受信部２０１と、リソースクラスデータベース２０９ｂを参照して、リソース指示情報で指示されたソフトウェアリソースに対応するリソースクラスを特定するリソースクラス特定部２０２と、認証パターンデータベース２０９ｃを参照して、リソースクラス特定部２０２によって特定されたリソースクラスに対応する認証パターンを特定する認証パターン特定部２０３と、認証パターン特定部２０３によって特定された認証パターンを認証装置３００に送信する送信部２０４を備える（図１参照）。

リソースクラスデータベース２０９ｂは、サーバ装置２００で提供可能なソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すデータベースである（図２参照）。図２に示すように、例えばソフトウェアリソース（１）〜（３）がリソースクラス１に分類されている。このため、リソース指示情報で指示されるソフトウェアリソースがソフトウェアリソース（３）である場合を例に採ると、このリソースクラスデータベース２０９ｂを参照することで、ソフトウェアリソース（３）に対応するリソースクラスをリソースクラス１と特定できる。

認証パターンデータベース２０９ｃは、リソースクラスとユーザ装置との組合せと、認証パターンとの対応を表すデータベースである（図３参照）。認証パターンは、認証装置３００で実施可能な認証方式のうち一つ以上を指定することに用いられる識別力のある名前（識別子）であり、リソースクラスとユーザ装置との組合せに応じて必要な種類が用意される（認証パターンは後述する認証方式データベース３０９ａに関連するので、そこでも説明を加える。）。図３に示す例では、認証パターンＡ〜Ｄが用意されている。図３に示す例では、認証パターンデータベース２０９ｃは、例えばユーザ装置αについて、リソースクラス１の場合に認証パターンＣ、リソースクラス２の場合に認証パターンＢ、リソースクラス３の場合に認証パターンＡを対応させている。このため、ユーザ装置αかつリソースクラス２である場合を例に採ると、この認証パターンデータベース２０９ｃを参照することで、ユーザ装置αとリソースクラス２との組合せに対応する認証パターンを認証パターンＢと特定できる。

同一のリソースクラスにつき、ユーザ装置ごとに認証パターンを定める理由は、様々なユーザの各状況を勘案すると、認証装置３００で実施可能な一つ以上の認証方式の中にユーザが実施できない認証方式が含まれる場合があり、このような場合に、同じセキュリティレベルが確保できる代替の認証方式があれば、その認証方式を利用できるようにするためである。

逆に全てのユーザ装置が指定された認証方式で認証を実施できるのであれば、認証パターンデータベース２０９ｃは、リソースクラスとユーザ装置との組合せと認証パターンとの対応を表すデータベースである必要はない。つまり、認証パターンと少なくともリソースクラスとの対応を表すデータベースであれば足りる。この場合、認証パターンデータベース２０９ｃは、ユーザ装置が何れかに関わりなく、リソースクラスごとに一つの認証パターンを定めたデータベースとなる。

サーバ装置２００について説明したことは、サーバ装置４００は固よりその他のサーバ装置についても当てはまる。

次に、認証装置３００は、記憶部３０９を備えており、この記憶部３０９に、認証方式データベース３０９ａが記憶される（図１参照）。

認証方式データベース３０９ａは、認証パターンと認証方式との対応関係を表すデータベースである（図４参照）。認証方式は認証装置３００が実施可能な認証方式であり、認証装置３００は複数の認証方式を実施可能であるとする。例えば図４に示す認証方式データベース３０９ａは、認証装置３００が認証方式ア〜クの８種類の認証方式を実施可能であることを意味する。認証方式の例としては、回線認証、機器認証、パスワード認証、カード認証などが挙げられる。この認証方式データベース３０９ａは、サーバ装置ごとに用意される。このため、図４に示す認証方式データベース３０９ａがサーバ装置２００に対応するものとすれば、認証パターンは、サーバ装置２００で用意されるその種類と同じだけ用意され、この例では認証パターンＡ〜Ｄの４種類の認証パターンが用意されることになる。

また、図４に示す認証方式データベース３０９ａでは、認証パターンに対応する認証方式ごとに、認証成功の要否と有効期間が指定されている。但し、実施不要の認証方式（図中では「×」で略記してある。）については、認証成功の要否と有効期間を指定する必要はない。ここで認証成功の要否は、各認証方式について、サーバ装置がユーザ装置に対してソフトウェアリソースの提供を行うために認証成功することが求められる必要性の程度を表す。認証成功の要否には、認証成功必要と認証成功任意の２種類が存在する（図中では「必要」「任意」で略記してある。）。認証成功必要は、それが指定された認証方式について、サーバ装置がユーザ装置に対してソフトウェアリソースの提供を行うために必ず認証成功することが求められることを表す。認証成功任意は、それが指定された認証方式について、サーバ装置がユーザ装置に対してソフトウェアリソースの提供を行うために必ずしも認証成功することが求められるものではないことを表す。認証成功任意の意義は、サーバ装置において、認証成功任意が指定された認証方式の認証結果次第でソフトウェアリソースの内容に係る付帯条件等を設定することに利用できることにあり、詳しくは後述する。図４に示す例では、例えば認証パターンＢについて、認証方式アを認証成功必要かつ１時間有効、認証方式イを認証成功任意かつ１時間有効、認証方式ウを認証成功任意かつ３０分有効、認証方式エを認証不要などとして定められている。

認証方式データベース３０９ａでは、この例に限らず、有効期間を定めなくてもよい。また、認証成功の要否を定めることも必須ではなく、認証方式ごとに認証実施／認証不実施の区別だけを定めてもよい。

なお、認証パターンごとに対応する認証方式の指定、認証成功の要否、有効期間は予めサーバ装置２００からの指示によって決定されているとする。

同様に、サーバ装置４００に対応する認証方式データベースの一例を、認証パターンＡ〜Ｃの３種類の認証パターンが用意された場合として、図５に示す。このように、認証方式データベースは、サーバ装置ごとに独立別個に定められる。

記憶部３０９には、各ユーザ装置について、各認証方式の前回の認証結果を対応させた認証結果データベース３０９ｂも記憶されている。例えば、図６に示すように、ユーザ装置ごとに、複数の認証方式に対する認証結果とその認証実施時刻が登録されている。図６に示す例では、例えばユーザ装置βについて、認証方式アで認証成功かつ９時１２分実施、認証方式イで未実施、認証方式ウで認証失敗かつ９時１１分実施、認証方式エで未実施などとして登録されている。

また、認証装置３００は、サーバ装置２００から認証パターンを受信する受信部３０１と、認証方式データベース３０９ａを参照して、受信した認証パターンに対応する認証方式の中から認証を行う認証方式を特定する認証方式特定部３０２と、認証方式特定部３０２によって特定された一つまたは複数の認証方式に従って、ユーザ装置１００との間で認証を行う認証実行部３０３と、認証実行部３０３による認証結果をサーバ装置２００に送信する送信部３０４とを備える（図１参照）。

次に、図７を参照して、認証システム１における処理の流れを叙述的に説明する。
まず、ユーザ装置１００の送信部１０１は、サーバ装置２００が提供可能なソフトウェアリソースを指示する情報であるリソース指示情報を、サーバ装置２００に対して送信する（ステップＳ１）。

サーバ装置２００の受信部２０１が、ユーザ装置１００からリソース指示情報を受信すると（ステップＳ２）、サーバ装置２００のリソースクラス特定部２０２が、記憶部２０９に記憶されたリソースクラスデータベース２０９ｂを参照して、リソース指示情報が指示するソフトウェアリソースに対応するリソースクラスを特定する（ステップＳ３）。

そして、サーバ装置２００の認証パターン特定部２０３が、記憶部２０９に記憶された認証パターンデータベース２０９ｃを参照して、ステップＳ３の処理において特定されたリソースクラスとユーザ装置との組合せに対応する認証パターンを特定する（ステップＳ４）。既述のとおり、ユーザ装置に依存しない場合には、リソースクラスに対応する認証パターンを特定すればよい。

サーバ装置２００の送信部２０４は、ステップＳ４の処理において特定された認証パターンを認証装置３００に送信する（ステップＳ５）。この処理では、認証装置３００で認証結果データベース３０９ｂの作成のためにユーザ装置を特定する情報も認証装置３００に送信する。この処理は、ＳＡＭＬ ｖ２．０を利用する場合、例えば、認証要求情報に併せて、認証パターンとユーザ装置特定情報を記述したAppendixを認証装置３００に送信する処理となる。

認証装置３００の受信部３０１が、サーバ装置２００から認証パターンとユーザ装置特定情報を受信すると（ステップＳ６）、認証装置３００の認証方式特定部３０２が、記憶部３０９に記憶されたサーバ装置２００に対応する認証方式データベース３０９ａを参照して、受信した認証パターンに対応する認証方式の中から認証を行う認証方式を特定する（ステップＳ７）。

図４に示す例で、この特定の手順を、認証パターンが認証パターンＢである場合で代表して説明する。サーバ装置２００に対応する認証方式データベース３０９ａ（図４参照）では、認証パターンＢについて、認証方式アが認証成功必要かつ１時間有効、認証方式イが認証成功任意かつ１時間有効、認証方式ウが認証成功任意かつ３０分有効、認証方式エが認証不要などとなっている。そこで、認証成功の要否の指定によらず、認証不要と指定された認証方式を除く認証方式を、認証を行う認証方式の候補とする。その例では、認証方式特定部３０２は、認証方式ア、イ、ウ、カ、キを認証を行う認証方式の候補として特定する。

認証方式特定部３０２は、認証装置３００の現在時刻管理部（図示しない。）が提供する現在時刻および記憶部３０９に記憶された認証結果データベース３０９ｂ（図６参照）を参照して、上記候補の認証方式のうち、前回の認証時刻から有効期間を徒過した認証方式、未実施の認証方式、前回の認証結果が認証失敗である認証方式を、認証を行う認証方式として特定する。

このことを、次のような状況設定を例にして説明する。
＜状況設定＞
前回の認証は、ユーザ装置βがサーバ装置４００の或るソフトウェアリソースの提供を受けようとしてサーバ装置４００の認証パターンＡに対応する認証方式に従い、ユーザ装置βと認証装置３００との間で認証が行われた。今回の認証は、ユーザ装置βがサーバ装置２００の或るソフトウェアリソースの提供を受けようとしてサーバ装置２００の認証パターンＢに対応する認証方式に従い、ユーザ装置βと認証装置３００との間で認証が行われようとしている。なお、サーバ装置４００に対応する前回の認証結果は図６に示す認証結果データベースのとおりであり、サーバ装置４００に対応する認証方式データベースは図５に示すとおりとする。

このとき、認証装置３００の認証方式特定部３０２は、例えば現在時刻が９時３０分である場合、候補である各認証方式ア、イ、ウ、カ、キについて、図６に示す認証結果データベース３０９ｂを参照して、
＜１＞認証方式アの認証結果は認証成功であり、前回認証時刻９時１２分から有効期間１時間を徒過していないので、認証方式アを認証を行う認証方式として採用しない、
＜２＞認証方式イは前回認証で何らかの理由で未実施であるから、認証方式イを認証を行う認証方式として採用する、
＜３＞認証方式ウは、前回認証時刻９時１１分から有効期間３０分を徒過していないが、前回の認証結果が認証失敗であるから、認証方式ウを認証を行う認証方式として採用する、
＜４＞認証方式カの認証結果は認証成功であり、前回認証時刻９時１４分から有効期間２時間を徒過していないので、認証方式カを認証を行う認証方式として採用しない、
＜５＞認証方式キは、前回の認証結果が認証成功であるが、前回認証時刻９時１１分から有効期間１０分を徒過しているため、認証方式キを認証を行う認証方式として採用する、として、認証を行う認証方式をイ、ウ、キに特定する。

このような認証方式特定処理であれば、前回認証に成功した認証方式であって認証結果の有効期間内であるものについて認証を実施する手間を省くことができる。反面、前回の認証時刻から有効期間を徒過した認証方式、未実施の認証方式、前回の認証結果が認証失敗である認証方式のうち少なくともいずれかを実施する認証方式に採用することで、ソフトウェアリソースの提供に際して要求される認証方式で認証成功する可能性をユーザ装置に失わせないように運用することができる。

勿論、認証実施の手間を厭わない場合には、前回の認証結果に関わらず、認証パターンで指示される認証方式による認証を実施すればよく、この場合は、認証方式データベース３０９ａ（図４参照）で決まる上記候補の認証方式を全て実施すればよい。

続いて、認証装置３００の認証実行部３０３は、ステップＳ７の処理において特定された一つまたは複数の認証方式に従って、ユーザ装置１００の認証処理部１０２との間で認証を行う（ステップＳ８）。各認証方式の認証結果は、認証装置の制御部（図示しない。）によって、ユーザ装置特定情報で特定されるユーザ装置（この例ではユーザ装置１００）に対応した認証結果として、認証結果データベース３０９ｂに保存される。

上記の認証が完了すると、認証装置３００の送信部３０４が、ステップＳ８の処理での認証結果をサーバ装置２００に送信する（ステップＳ９）。送信される認証結果には、認証成功の要否で認証成功必要と指定された各認証方式の認証結果の論理積が含まれる。つまり、例えば認証成功必要が指定された認証方式が、認証方式ア、キである場合、認証方式アの認証結果および認証方式キの認証結果が共に成功の場合のみ論理積は成功であり、それ以外の場合、論理積は失敗となる。また、送信される認証結果は、上記論理積とともに、各認証方式の認証結果（成功／失敗／未実施／エラー）を含むとしてもよい。この処理は、ＳＡＭＬ ｖ２．０を利用する場合、例えば、アサーション（Assertion）に上記論理積を記述し、アサーションの属性情報として各認証方式の認証結果（成功／失敗／未実施／エラー）を記述して、これをサーバ装置２００に送信する処理となる。

サーバ装置２００の受信部２０３が、認証装置３００から上記認証結果を受信すると（ステップＳ１０）、サーバ装置２００の制御部（図示しない。）は、ステップＳ４の処理で特定された認証パターンに対応する各認証方式の上記認証結果を基に、ユーザ装置１００に対して指示されたソフトウェアリソースの提供を実施するか否かの判断を行う（ステップＳ１１）。

受信した認証結果について、上記論理積が失敗を示す場合には、サーバ装置２００は、リソース指示情報で指示されたソフトウェアリソースの提供を行わない。上記論理積が成功を示す場合には、サーバ装置２００は、ユーザ装置１００に対してリソース指示情報で指示されたソフトウェアリソースの提供を行う。このとき、個々の認証方式の認証結果を受信している場合では、サーバ装置２００は、認証成功任意が指定された認証方式の認証結果次第で、提供するソフトウェアリソースの内容に係る付帯条件等を設定できる。

このことを例を挙げて説明する。例えば、銀行サーバ装置であるサーバ装置２００において、振込処理を行うソフトウェアリソース（８）の提供のための認証パターンが認証パターンＺに特定され、認証装置３００では、認証パターンＺに対応して実施する認証方式として、認証方式サ〜セが特定され、認証方式サ、シでは認証成功必要が指定され、認証方式ス、セでは認証成功任意が指定されているとする。このとき、認証成功必要が指定された認証方式サ、シで認証成功することで、サーバ装置２００がユーザ装置１００に対してソフトウェアリソース（８）の提供を行うことになる。

ところで、一般的な振込処理では、その振込金額に応じて認証強度が異なるのが通例である。例えばパスワード認証と第２パスワード認証にのみ成功した場合には、振込限度額が５０万円であり、さらにカード認証に成功した場合には、振込限度額が１００万円になるといった具合である。このように、一つのソフトウェアリソースでも、その内容に係る付帯条件等をサーバ装置側で適宜に設定できることが望ましい。また、ユーザ装置にとっても、仮に認証に失敗した場合に、その失敗をもって画一的にソフトウェアリソースの提供を受けることができなくなるよりも、認証成功の程度に応じてソフトウェアリソースの一部でも提供を受けられることが望ましい。

そこで、サーバ装置２００は、認証成功必要が指定された認証方式で認証成功することを前提条件として、認証成功任意が指定された認証方式での認証結果に応じてソフトウェアリソースの内容に係る付帯条件等の種類を予め設定しておく。この設定は一覧表として規定される。この一覧表がコンピュータで処理可能なデータ形式となっていることは言うまでもない。上述のソフトウェアリソースが振込処理の例でこの一覧表を図８に示す。図８の例では、認証方式ス、セの全てが認証成功以外（図中では空欄）であれば、振込限度額を５０万円であり、認証方式ス、セのいずれかが認証成功以外（図中では空欄）であれば、振込限度額を１００万円であり、認証方式ス、セの全てが認証成功であれば、振込限度額を２００万円としている。

ステップＳ１１の処理では上述の処理が行われ、この結果、具体的なソフトウェアリソースの提供がサーバ装置２００からユーザ装置１００に対して行われることになる。

以上の実施形態の他、本発明は上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

本発明の実施形態に係わる認証システム１の構成例を示す図。 サーバ装置２００で保有されるリソースクラスデータベース２０９ｂの構成例を示す図。 サーバ装置２００で保有される認証パターンデータベース２０９ｃの構成例を示す図。 認証装置３００で保有される認証方式データベース３０９ａ（サーバ装置２００に対応）の構成例を示す図。 認証装置３００で保有される認証方式データベース３０９ａ（サーバ装置４００に対応）の構成例を示す図。 認証装置３００で保有される認証結果データベース３０９ｂの構成例を示す図。 認証システム１における認証方法の処理フロー。 認証成功任意が指定された認証方式の認証結果に応じてソフトウェアリソースの内容に付随する条件等を示す一覧表の例。

符号の説明

１ 認証システム
１００ ユーザ装置
１０２ 認証処理部
２００ サーバ装置
２０２ リソースクラス特定部
２０３ 認証パターン特定部
３００ 認証装置
３０２ 認証方式特定部
３０３ 認証実行部
４００ サーバ装置

Claims (10)

1. サーバ装置と認証装置とを含み、認証装置による認証をサーバ装置による認証に転用する認証システムであって、
   上記サーバ装置は、
   上記サーバ装置が提供可能なソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すリソースクラスデータベースと、認証パターンと少なくとも上記リソースクラスとの対応関係を表す認証パターンデータベースとを記憶した記憶部と、
   上記リソースクラスデータベースを参照して、ソフトウェアリソースに対応するリソースクラスを特定するリソースクラス特定部と、
   上記認証パターンデータベースを参照して、上記リソースクラス特定部によって特定されたリソースクラスに対応する認証パターンを特定する認証パターン特定部と、
   上記認証パターン特定部によって特定された認証パターンを上記認証装置に送信する送信部とを備え、
   上記認証装置は、
   上記認証パターンと認証方式との対応関係を表す認証方式データベースを記憶した記憶部と、
   上記サーバ装置から上記認証パターンを受信する受信部と、
   上記認証方式データベースを参照して、受信した上記認証パターンに対応する認証方式の中から認証を行う認証方式を特定する認証方式特定部と、
   上記認証方式特定部によって特定された一つまたは複数の認証方式に従って認証を行う認証実行部と、
   上記認証実行部による認証結果を上記サーバ装置に送信する送信部とを備えた
   認証システム。
2. 上記認証方式データベースでは、上記認証パターンに対応する認証方式ごとに、認証成功の要否が指定されている
   ことを特徴とする請求項１に記載の認証システム。
3. 上記認証装置の上記送信部は、上記認証実行部が認証方式に従って行った認証の結果を上記サーバ装置に送信するものである
   ことを特徴とする請求項１または請求項２に記載の認証システム。
4. 上記認証方式データベースでは、上記認証パターンに対応する認証方式ごとに、認証結果の有効期間が指定されており、
   上記認証装置の上記認証方式特定部は、認証を行う認証方式に、前回の認証時刻から上記有効期間を徒過した認証方式、未実施の認証方式、前回の認証結果が認証失敗である認証方式の少なくともいずれかを含めるものである
   ことを特徴とする請求項１から請求項３のいずれかに記載の認証システム。
5. 複数のユーザ装置を含み、
   上記認証パターンデータベースは、上記認証パターンと、上記リソースクラスと上記ユーザ装置との組合せとの対応を表すものであり、
   上記認証パターン特定部は、上記認証パターンデータベースを参照して、上記リソースクラス特定部によって特定されたリソースクラスと上記認証の対象である上記ユーザ装置との組合せに対応する認証パターンを特定するものである
   ことを特徴とする請求項１から請求項４のいずれかに記載の認証システム。
6. サーバ装置と認証装置との間において、認証装置による認証をサーバ装置による認証に転用する認証方法であって、
   上記サーバ装置の記憶部には、上記サーバ装置が提供可能なソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すリソースクラスデータベースと、認証パターンと少なくとも上記リソースクラスとの対応関係を表す認証パターンデータベースとが記憶されており、
   上記認証装置の記憶部には、上記認証パターンと認証方式との対応関係を表す認証方式データベースが記憶されており、
   上記サーバ装置のリソースクラス特定部が、上記リソースクラスデータベースを参照して、ソフトウェアリソースに対応するリソースクラスを特定するリソースクラス特定ステップと、
   上記サーバ装置の認証パターン特定部が、上記認証パターンデータベースを参照して、上記リソースクラス特定ステップにおいて特定されたリソースクラスに対応する認証パターンを特定する認証パターン特定ステップと、
   上記サーバ装置の送信部が、上記認証パターン特定ステップにおいて特定された認証パターンを上記認証装置に送信する送信ステップと、
   上記認証装置の受信部が、上記サーバ装置から上記認証パターンを受信する受信ステップと、
   上記認証装置の認証方式特定部が、上記認証方式データベースを参照して、受信した上記認証パターンに対応する認証方式の中から認証を行う認証方式を特定する認証方式特定ステップと、
   上記認証装置の認証実行部が、上記認証方式特定ステップにおいて特定された一つまたは複数の認証方式に従って認証を行う認証ステップと、
   上記認証装置の送信部が、上記認証ステップでの認証結果を上記サーバ装置に送信する送信ステップとを有する
   認証方法。
7. 提供可能なソフトウェアリソースとソフトウェアリソースの分類を表すリソースクラスとの対応関係を表すリソースクラスデータベースと、認証パターンと少なくとも上記リソースクラスとの対応を表す認証パターンデータベースとを記憶した記憶部と、
   上記リソースクラスデータベースを参照して、ソフトウェアリソースに対応するリソースクラスを特定するリソースクラス特定部と、
   上記認証パターンデータベースを参照して、上記リソースクラス特定部によって特定されたリソースクラスに対応する認証パターンを特定する認証パターン特定部と、
   上記認証パターン特定部によって特定された認証パターンを外部に送信する送信部と
   を備えたサーバ装置。
8. 認証パターンと認証方式との対応関係を表す認証方式データベースを記憶した記憶部と、
   外部から認証パターンを受信する受信部と、
   上記認証方式データベースを参照して、受信した上記認証パターンに対応する認証方式の中から認証を行う認証方式を特定する認証方式特定部と、
   上記認証方式特定部によって特定された一つまたは複数の認証方式に従って認証を行う認証実行部と、
   上記認証実行部による認証結果を外部に送信する送信部と
   を備えた認証装置。
9. コンピュータを請求項７に記載のサーバ装置として機能させるためのプログラム。
10. コンピュータに請求項８に記載の認証装置として機能させるためのプログラム。

Images