ユーザ認証システム、方法、プログラムおよび装置
【課題】多様なデータアクセスを提供することができる。
【解決手段】本実施形態に係るユーザ認証システムは、データを提供するシステムの種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する。ユーザ認証システムは、第１ユーザから第１データの要求があった場合、ユーザ情報と第１ユーザの第１アクセス権限とを参照して、第１ユーザが第１データにアクセス可能であるかどうかを判定する。ユーザ認証システムは、第１データの第１認証方式に応じた、第１ユーザの認証に必要な第１認証情報を端末から受信する。ユーザ認証システムは、第１認証方式および第１認証情報に基づいて、第１ユーザを認証する。ユーザ認証システムは、第１ユーザが第１データにアクセス可能であると判定され、かつ認証が成功した場合に、第１データが提供可能であることを示す結果情報を通知する。
【解決手段】本実施形態に係るユーザ認証システムは、データを提供するシステムの種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する。ユーザ認証システムは、第１ユーザから第１データの要求があった場合、ユーザ情報と第１ユーザの第１アクセス権限とを参照して、第１ユーザが第１データにアクセス可能であるかどうかを判定する。ユーザ認証システムは、第１データの第１認証方式に応じた、第１ユーザの認証に必要な第１認証情報を端末から受信する。ユーザ認証システムは、第１認証方式および第１認証情報に基づいて、第１ユーザを認証する。ユーザ認証システムは、第１ユーザが第１データにアクセス可能であると判定され、かつ認証が成功した場合に、第１データが提供可能であることを示す結果情報を通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザの用途に応じて、サービスを利用できるかどうかを判定するユーザ認証システム、方法、プログラムおよび装置に関する。
【背景技術】
【０００２】
一般的に、ユーザがあるサービスを利用する際にはユーザ認証を行なう。例えば、ユーザがＷｅｂサービスを利用する際には、ユーザ識別番号（ＩＤ）とパスワードによる認証が行われる。近年は、シングルサインオン（ＳＳＯ）機能やセキュリティを強化した二要素認証が実行される。二要素認証は、例えば、ＳＳＯ機能を利用している状態で、さらに高いセキュリティが必要な場合に、ワンタイムパスワードを利用するといった、２つの手法を用いる認証方法である。他の例としては、銀行の口座からＡＴＭを利用して現金を引き出す場合に、自分のＩＣカードとパスワードとの組み合わせによる二要素認証でサービス利用可能かどうかを判定している。さらに、その他の認証方式としては、多段認証、同時認証、外部認証などが存在する（例えば、特許文献１および特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９２１９３号公報
【特許文献２】特開２００９−０７１４３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、一般的に、１つのサービスの中では様々な認証を使用することを想定していない。例えばＳＳＯ機能のＷｅｂサービスを使用している状態で、他の認証を必要とする場合は予め作り込んでおく必要があるので、他の認証を動的に追加することができない。
さらに、複数のサービスが共存する場合は、提供する情報によりセキュリティのレベルが異なるので、様々な認証方式を用いてサービスを提供する必要があるが、現状では、サービスごとに認証方式を変えるといったきめ細かな対応ができない。
【０００５】
この発明は上記事情に着目してなされたもので、その目的とするところは、多様なデータアクセスを提供することができるユーザ認証システム、方法、プログラムおよび装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためにこの発明の一つの観点は、ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、前記要求装置は、前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出する抽出手段を具備し、前記連携装置は、ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、前記要求装置は、前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信する第１送受信手段をさらに具備し、前記提供装置は、前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信する第２送受信手段を具備することを特徴とする。
【発明の効果】
【０００７】
すなわちこの発明によれば、多様なデータアクセスを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態に係るトラストサークルシステムの一例を示す概念図。
【図２】本実施形態に係るクライアント端末、要求側システム、提供側システムを示すブロック図。
【図３】本実施形態に係る連携システムを示すブロック図。
【図４】ＳＳＯ認証の一例を示すフローチャート。
【図５】ＳＳＯ認証後のデータ取得の一例を示すフローチャート。
【図６】ＳＳＯ認証済みで、かつ多段認証に必要な場合のデータ取得の一例を示すフローチャート。
【図７】ＳＳＯ認証済みで、かつ同時認証が必要な場合のデータ取得の一例を示すフローチャート。
【図８】外部認証後のデータ取得の一例を示すフローチャート。
【図９】複数認証時のデータ取得の一例を示すフローチャート。
【発明を実施するための形態】
【０００９】
ここで、上述した認証方式について説明する。
多段認証は、アクセスしてきたユーザの認証方法が原因でアクセス拒否判定となった場合、提供側システムから送信された「アクセス許可になるために必要となる認証方法」に基づき、要求側システムが連携システムに対して追加の認証要求を実行することを可能とする認証方式である。具体的には、薬の服用歴などはＳＳＯ認証だけで閲覧できるが、病院が提供する閲覧用診療カルテといった、他人に知られると自分の身に被害が及ぶ可能性のあるデータを閲覧するときは、より強力な認証方法を使う仕組みである。
同時認証は、第１ユーザＸがＳＳＯしているときに、別の第２ユーザＹの認証を実行することで、第２ユーザＹのアクセス制御を書き換え、第１ユーザＸが第２ユーザＹのデータにアクセスできるようにする認証方式である。具体的には、第１ユーザＸが医師で、第２ユーザＹが患者である場合、医師が患者を診察しているときに、別の病院にかかっていたときの患者の電子カルテを参照できるようにする方式である。
【００１０】
外部認証は、各サービス用に用意された認証である独自の認証の結果を、ＳＳＯ内部の認証方式の一方式として取り込み、ＳＳＯ認証を受けたユーザと同じようにＳＡＭＬのＡｓｓｅｒｔｉｏｎ（ＩｄＰ（Identity Provider）が発行し、ＳＰにおけるユーザ情報を示す認証トークンのＸＭＬスキーマを規定）を発行すること、および提供側システムで独自認証方式を許可していることにより、ＳＳＯすることなしにサービスを利用できる方式である。
【００１１】
複数認証とは、複数の要素を用いた認証を同一シーケンス内で連続して実行することにより、ユーザ認証を行う方式である。具体的には、インターネットバンキングサービスを提供する銀行では、顧客識別番号、端末情報、第１暗証番号、第２暗証番号、金融債取引用暗証番号、ログインパスワードおよび合言葉といった要素を用いてユーザ認証を行う。他銀行でも複数の要素を組み合わせてサービスを提供している。
【００１２】
以下、図面を参照しながら本発明の実施形態に係るユーザ認証システム、方法、プログラムおよび装置について詳細に説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
本実施形態に係るユーザ連携システムの一例となるトラストサークルシステムについて図１を参照して説明する。
トラストサークルシステム１００は、クライアント端末１０１、要求側システム１０２、提供側システム１０３、連携システム１０４を含む。また、クライアント端末１０１、要求側システム１０２−１および１０２−２、提供側システム１０３−１および１０３−２、および連携システム１０４は、ネットワーク１０５を介して相互接続される。トラストサークルは、ＳＡＭＬ（Security Assertion Markup Language）を介して形成され、ＳＳＯやＳＬＯ（シングルログアウト）もトラストサークルに参加するシステム間で行われる。
クライアント端末１０１は、ユーザインターフェース（ＵＩ）を含み、ユーザからの入力を受け付け、またはユーザに対して情報を表示する。ユーザに対する情報の表示は、例えば、Ｗｅｂブラウザが提供するユーザインタフェースを使って実現すればよい。
【００１３】
要求側システム１０２は、クライアント端末１０１からの要求を受信する。要求側システム１０２自身でデータを提供できる場合は、要求側システム１０２自身でクライアント端末１０１にデータを提供することでサービスを提供する。要求側システム１０２自身でデータを提供できない場合は提供側システム１０３にデータを要求する。
提供側システム１０３は、要求側システム１０２にデータを提供する。なお、提供側システム１０３は、状況によって要求側システム１０２と同じ動作をおこなう。
連携システム１０４は、要求側システム１０２と提供側システム１０３とのシステム間の連携をおこなう。また、連携システム１０４は、認証サーバとしての役割を持ち、システムを利用するユーザのアクセス制御を管理する。
本実施形態では、ユーザがクライアント端末１０１を用いて要求側システム１０２−１のサービスＳＡにアクセスし、サービスＳＡが提供側システム１０３−１および１０３−２に格納されるデータＤ１およびＤ２のそれぞれを用いてユーザに情報を提供する場合を想定する。
【００１４】
次に、クライアント端末１０１、要求側システム１０２および提供側システム１０３について図２のブロック図を参照して説明する。
クライアント端末１０１は、Ｗｅｂブラウザ２０１を含む。クライアント端末１０１は、ユーザがクライアント端末１０１のＷｅｂブラウザに入力した情報を要求側システム１０２に送り、要求側システム１０２から受け取った情報をＷｅｂブラウザに表示する。これにより、ユーザはサービスに関する情報を閲覧することができる。
【００１５】
要求側システム１０２は、Ｗｅｂアクセス抽出部２１０、データアクセス部２１１、ユーザ情報格納部２１２、アプリケーションデータ格納部２１３、アクセス制御判定部２１４、送受信部２１５を含む。また、Ｗｅｂアクセス抽出部２１０およびアクセス制御判定部２１４をアクセス制御部２１６とも呼ぶ。
Ｗｅｂアクセス抽出部２１０は、クライアント端末１０１のＷｅｂブラウザ２０１から要求されたＨＴＴＰリクエストを受信し、ＨＴＴＰリクエストを解析する。この解析処理により、ユーザが要求するデータと、ユーザ情報と、データの表示許可のために指定されている認証方式とを抽出する。
データアクセス部２１１は、Ｗｅｂアクセス抽出部２１０からユーザ情報格納部２１２とアプリケーションデータ格納部２１３とにアクセスする。
ユーザ情報格納部２１２は、ユーザに関する情報、例えば、ユーザ名（ユーザＩＤ）、組織、内部組織、資格といった属性をそれぞれ対応付けて格納する。組織および内部組織は、ユーザの所属を示し、アクセス権限の一要素となる。例えば組織「病院」、内部組織「外科」が挙げられる。資格は、ユーザが所有する資格であり、アクセス権限の一要素となる。例えば、資格「医師」が挙げられる。
【００１６】
アプリケーションデータ格納部２１３は、アプリケーションで使用するデータ、またはユーザが格納したデータを格納する。アプリケーションで使用するデータは、具体的には、起動のために必要となる設定ファイル、レスポンスデータである。レスポンスデータは、例えばＨＴＭＬ（Hypertext Markup Language）に代表されるようなマークアップ言語で構成されるＨＴＴＰレスポンスであり、Ｗｅｂブラウザにデータを表示させるためのデータである。なお、Ｗｅｂブラウザに限らずユーザがデータを認識しやすい表示形式であれば何でもよい。ユーザが格納したデータは、具体的には、ユーザに提供するデータである。なお、要求側システム１０２は、アプリケーションデータ格納部２１３を有さなくてもよい。
アクセス制御判定部２１４は、ユーザ情報格納部２１２に格納されるユーザ情報およびアプリケーションデータ格納部２１３が存在する場合はアプリケーションデータ格納部２１３に格納されるデータを参照して、ユーザがアクセス可能であるかどうかを判定する。
なお、要求側システム１０２自身でユーザがアクセス可能であるかどうかを判定できない場合、またはユーザにデータを提供できない場合は、提供側システム１０３に判定およびデータ提供を依頼する。
送受信部２１５は、信号を送受信する。具体的に本実施形態では、データまたはデータを要求する要求信号を送受信する。
【００１７】
提供側システム１０３は、Ｗｅｂアクセス抽出部２１０、データアクセス部２１１、ユーザ情報格納部２１２、アプリケーションデータ格納部２１３、アクセス制御判定部２１４および送受信部２１５を含む。また、Ｗｅｂアクセス抽出部２１０およびアクセス制御判定部２１４をアクセス制御部２１６とも呼ぶ。提供側システム１０３の各ブロックは、要求側システム１０２とほぼ同様であり、同様の動作を行うので異なる部分のみ説明する。アプリケーションデータ格納部２１３は、データとデータの認証方式とを対応付けて格納する。なお、提供側システム１０３に格納されるデータは全て同じ認証方式としてもよい。
【００１８】
また、提供側システム１０３は、要求側システム１０２の要求に応じて、認証が成功している場合に、アプリケーションデータ格納部２１３からデータを抽出して要求側システム１０２にデータを送る。なお、アプリケーションデータ格納部２１３に格納されるデータは、データの重要度に応じて認証方式がそれぞれ定められていてもよい。例えば、データの重要度が高いほど、認証の数を増やしてもよい。具体的には、重要度が高いデータに関して、ＩＤ／パスワード認証のほか、端末情報、暗証番号、生体認証などといった多要素の認証を行えばよい。また、データの重要度に応じてセキュリティ強度を変更した認証を行ってもよい。例えば、データの重要度が低いものに関しては、ＩＤ／パスワード認証のみとし、データの重要度が高いほど、生体認証などセキュリティ強度が高い認証を用いる。なお、データの重要度に応じて、認証の数とセキュリティ強度の高い認証との両方を用いて認証方式を定めてもよい。
データの認証方式を変更する場合は、クライアント端末１０１から送られるＨＴＴＰリクエストに埋め込まれる認証方式を変更し、各システムにおいて変更した認証方式に対応するアプリケーションを組み込めばよい。
【００１９】
次に、連携システム１０４について図３のブロック図を参照して説明する。
連携システム１０４は、Ｗｅｂアクセス受信部３０１、ユーザ情報格納部３０２、システム情報格納部３０３、マスタ情報格納部３０４、認証データ格納部３０５、認証画面生成部３０６、認証処理部３０７、アクセス権限管理部３０８、アクセス制御判定部３０９、および通知部３１０を含む。
【００２０】
Ｗｅｂアクセス受信部３０１は、要求側システム１０２または提供側システム１０３から、データを要求するユーザのユーザ情報と、データにアクセスするための認証方式の種類とを受信する。また、クライアント端末１０１から、ユーザにより入力される認証処理に必要な認証情報を受信する。
ユーザ情報格納部３０２は、連携システムにおけるユーザＩＤとユーザのそれぞれの属性とを対応付けて格納する。具体的には、要求側システム１０２および提供側システム１０３におけるユーザ情報格納部２１２と同様の情報を格納するが、ユーザＩＤおよび氏名ではなく、連携システム１０４における仮ＩＤを用いる点が異なる。なお、仮ＩＤはＳＡＭＬで用いられる一般的なものであるため、具体的な説明は省略する。
システム情報格納部３０３は、要求側システム１０２および提供側システム１０３が有するシステムに関する情報（例えば、システムの種別）とシステムで使用する認証方式とを格納する。
【００２１】
マスタ情報格納部３０４は、属性のＩＤと属性名称とをそれぞれ対応付けて格納する。具体的には、例えば、組織データであれば、「組織ＩＤ：１００１、組織属性名称：Ａ病院」、資格データであれば、「資格ＩＤ：ｑ００１、資格属性名称：医師」となる。また、新しく資格を追加したい場合は、新規に資格ＩＤと資格属性名称とを登録すればよい。
認証データ格納部３０５は、認証を実行するために必要な認証方式のデータを格納する。例えば、ＩＤ／パスワード認証や生体認証に関するデータを格納する。
認証画面生成部３０６は、Ｗｅｂアクセス受信部３０１からデータの認証方式を受け取り、受け取った認証方式の認証処理で必要となるユーザの認証情報を取得するための、入力画面データを生成する。また、認証が失敗した場合のエラー画面を表示するためのレスポンスデータも生成する。
【００２２】
認証処理部３０７は、Ｗｅｂアクセス受信部３０１からデータの認証方式の種類と認証に必要なユーザの認証情報とを、認証データ格納部３０５から認証データをそれぞれ受け取り、認証処理を実行し、認証結果を出力する。具体的には、例えばＩＤ／パスワード認証であれば、認証情報としてユーザＩＤとユーザが入力したパスワードとを受け取り、認証データと一致するかどうかを判定し、認証結果として出力する。なお、システム全体で認証方式が統一されている場合は、認証処理部３０７は、システム情報格納部３０３からシステムにおける認証方式を受け取り、認証方式を実行すればよい。
アクセス権限管理部３０８は、ユーザ、組織などの属性、およびシステムに関連するデータへのアクセス権限を管理する。アクセス権限管理部３０８に格納されるデータは、例えば以下のように記述される。
１）資格Ｃを有するユーザは、提供側システム１０３が有する、組織Ｓが保有する全てのユーザデータを検索することができるが、更新できない。
２）資格Ｄを有するユーザは、提供側システム１０３が有する、組織Ｓが保有する全てのユーザデータを更新することができる。
なお、ユーザが有する資格に応じて、組織Ｓが保有するユーザデータの扱いを変更してもよい。
【００２３】
アクセス制御判定部３０９は、Ｗｅｂアクセス受信部３０１からデータ要求したユーザのユーザ情報を、アクセス権限管理部３０８からデータ要求したユーザのアクセス権限をそれぞれ受け取り、データ要求したユーザがアクセス権限を有するかどうかを判定する。
通知部３１０は、認証画面生成部３０６から入力画面データを受け取り、ユーザに認証情報を入力させるため外部へ入力画面データを送信する。また、通知部３１０は、認証処理部３０７から認証結果を、アクセス制御判定部３０９から判定結果をそれぞれ受け取り、要求に応じて要求側システム１０２または提供側システム１０３に出力する。
【００２４】
ここで、トラストサークルシステムにおける認証処理の流れについて説明する。
はじめにユーザがクライアント端末１０１のＷｅｂブラウザから要求側システム１０２にアクセスすると、クライアント端末１０１にユーザが利用できるサービスの一覧が表示される。ユーザは、その中から自分が利用したいサービスへのアクセスを要求する。このとき、リンク先のデータにどの認証方式を用いるのかが記述されている。
【００２５】
要求側システム１０２では、Ｗｅｂアクセス抽出部２１０がクライアント端末１０１から送られてきたリクエストを解析して、どの認証方式を用いるかを抽出する。アクセスを要求したユーザと認証方式とに応じて、要求側システム１０２は連携システム１０４にアクセス権限の可否と認証処理とを要求する。必要な場合は、提供側システム１０３にアクセス権限の可否を要求する。
【００２６】
連携システム１０４は、アクセスの可否の判定と認証処理とを実行し、判定結果と認証結果とを結果情報として要求側システム１０２に送る。
クライアント端末１０１は、ユーザがアクセス可能でありかつ認証成功の場合、提供側システム１０３から要求側システム１０２を介して、所望のデータを受信することができる。一方、ユーザがアクセス不可であるかまたは認証失敗の場合は、クライアント端末１０１は、エラー画面をユーザに表示する。
【００２７】
以下、具体的な認証方式におけるクライアント端末１０１、要求側システム１０２、提供側システム１０３および連携システム１０４の動作シーケンスについて、図４から図９までを参照して説明する。
ＳＳＯ認証について図４のフローチャートを参照して説明する。
ステップＳ４０１では、クライアント端末１０１がアクセスを要求側システム１０２に要求する。
【００２８】
ステップＳ４０２では、要求側システム１０２が、認証を要求するためのメッセージを連携システム１０４に送る。
ステップＳ４０３では、連携システム１０４が、必要に応じてユーザ認証を行う。
ステップＳ４０４では、連携システム１０４が、認証結果をクライアント端末１０１を介して要求側システム１０２に送る。認証成功の場合は、ステップＳ４０５およびステップＳ４０６に進み、認証失敗の場合は、ステップＳ４０７およびステップＳ４０８に進む。
【００２９】
ステップＳ４０５では、要求側システム１０２が、アクセス許可を示す画面を表示させるためのレスポンスデータをクライアント端末１０１に送り、ステップＳ４０６では、クライアント端末１０１が、認証が成功しアクセス可能であることを示す画面をＷｅｂブラウザなどに表示する。
【００３０】
ステップＳ４０７では、要求側システム１０２が、エラー画面を表示させるためのデータをクライアント端末１０１に送り、ステップＳ４０８では、クライアント端末１０１が、認証が失敗したことを示す画面をＷｅｂブラウザなどに表示する。
次に、ＳＳＯ認証済みの状態でのデータ取得処理について図５のフローチャートを参照して説明する。
ステップＳ５０１では、クライアント端末１０１が、データＤ１を要求側システム１０２に要求する。なお、データＤ１は、ここでは提供側システム１０３−１に格納されるデータとする。
ステップＳ５０２では、要求側システム１０２が、要求側システム１０２自身はデータＤ１を有していないため、データＤ１を提供側システム１０３−１に要求する。
ステップＳ５０３では、提供側システム１０３−１が、ユーザがデータＤ１にアクセス可能であるかどうかの情報を得るための確認指示として、例えばユーザ情報を連携システム１０４に送る。
【００３１】
ステップＳ５０４では、連携システム１０４が、ユーザがデータＤ１にアクセス可能であるかどうかを判定し、ここでは、ユーザがデータＤ１にアクセス可能であることを示す結果情報を提供側システム１０３−１に送る。
ステップＳ５０５では、提供側システム１０３−１が、データＤ１を要求側システム１０２に送る。
ステップＳ５０６では、要求側システム１０２が、データＤ１を表示させるためのレスポンスデータを送る。
ステップＳ５０７では、クライアント端末１０１が、要求側システム１０２から送られたデータのフォーマットに従ってデータＤ１の取得画面を表示する。以上で、ＳＳＯ認証済みの状態でのデータ取得の処理を終了する。
【００３２】
次に、ＳＳＯ認証済みの状態で、かつ多段認証が必要となる場合のデータ取得処理について図６のフローチャートを参照して説明する。なお、図６の例では、多段認証の一方式として、生体認証を例に説明するが、生体認証に限らずどのような認証でもよい。
ステップＳ６０１では、クライアント端末１０１が、データＤ２を要求側システム１０２に要求する。なお、データＤ２は、提供側システム１０３−２に格納されるデータとする。
ステップＳ６０２では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ６０３では、提供側システム１０３−２が、ユーザの属性やデータ種別などから、生体認証が必要であると判定する。その後提供側システム１０３−２は、生体認証が必要であることの通知を要求側システム１０２に送る。
【００３３】
ステップＳ６０４では、要求側システム１０２が、生体認証を実行するための入力画面データを、クライアント端末１０１を介して連携システム１０４に要求する。
ステップＳ６０５では、連携システム１０４が、入力画面データをクライアント端末１０１に送る。
ステップＳ６０６では、クライアント端末１０１が、生体認証のための入力画面を表示する。その後ユーザが必要な生体認証に関する認証情報を入力する。
ステップＳ６０７では、クライアント端末１０１が、入力された生体認証に関する認証情報を連携システム１０４に送る。
ステップＳ６０８では、連携システム１０４が、生体認証処理を実行する。
【００３４】
ステップＳ６０９では、連携システム１０４が、生体認証処理の結果、すなわち認証成功か認証失敗かに関する認証結果の通知を、クライアント端末１０１を介して要求側システム１０２に送る。
ステップＳ６１０では、要求側システム１０２が認証結果を提供側システム１０３−２に通知する。以下、認証成功の場合は、ステップＳ６１１からステップＳ６１４までの処理を行い、認証失敗の場合は、ステップＳ６１５およびステップＳ６１６の処理を行う。
【００３５】
認証成功の場合、ステップＳ６１１では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ６１２では、提供側システム１０３−２が、データＤ２を要求側システム１０２に送る。
ステップＳ６１３では、要求側システム１０２が、データＤ２を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ６１４では、クライアント端末１０１が、データＤ２の取得画面を表示する。
【００３６】
認証失敗の場合、ステップＳ６１５では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ６１６では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、多段認証が必要となる場合のデータ取得処理を終了する。
【００３７】
次に、ＳＳＯ認証済みの状態で、かつ同時認証が必要となる場合のデータ取得処理について図７のフローチャートを参照して説明する。なお、図７の例では、同時認証の一方式として、ユーザＩＤおよびパスワード認証を例に説明するが、ユーザＩＤおよびパスワード認証に限らずどのような認証でもよい。
なお、図７の例では、クライアント端末１０１では、ユーザＸで認証済みの状態であり、ユーザＸが初めてユーザＹのデータを取得する場合を想定する。
【００３８】
ステップＳ７０１では、クライアント端末１０１が、ユーザＹのデータを要求側システム１０２に要求する。
ステップＳ７０２では、要求側システム１０２が、ユーザＹのデータを提供側システム１０３に要求する。
ステップＳ７０３では、提供側システム１０３が、ユーザＸはユーザＹのデータに対してアクセス権限を有するかどうかの確認指示を、連携システム１０４に送る。
ステップＳ７０４では、連携システム１０４が、ユーザＸのアクセス権限を判定する。ここでは、ユーザＸの認証では、ユーザＹのデータにアクセスできないので、ユーザＸはアクセス不可であることの通知を提供側システム１０３に送る。
ステップＳ７０５では、提供側システム１０３が、ユーザＸがユーザＹのデータにアクセス不可であることの通知を要求側システム１０２に送る。
【００３９】
ステップＳ７０６では、要求側システム１０２が、ユーザＹのアクセス制御を書き換えてユーザＸがアクセスできるようにするため、アクセス権限の書き換え通知をクライアント端末１０１を介して連携システム１０４に送る。
ステップＳ７０７では、連携システム１０４が、ユーザＹの認証情報を入力するための入力画面データを生成して、クライアント端末１０１に送る。
ステップＳ７０８では、クライアント端末１０１が、ユーザが入力した情報（ユーザＩＤおよびパスワード）を連携システム１０４に送る。
ステップＳ７０９では、連携システム１０４が、パスワード認証処理を実行する。
ステップＳ７１０では、連携システム１０４が、認証結果をクライアント端末１０１を介して要求側システム１０２に送る。ここではパスワード認証が成功した場合を想定する。
ステップＳ７１１では、要求側システム１０２が、ユーザＹのデータに関するアクセス権限の書き換え指示を連携システム１０４に送る。
ステップＳ７１２では、連携システム１０４が、アクセス権限管理部３０８に格納されるアクセス権限の書き換えを実行する。
ステップＳ７１３では、連携システム１０４が、アクセス権限の書き換え結果をクライアント端末１０１を介して要求側システム１０２に送る。以下、アクセス権限の書き換えが許可された場合は、ステップＳ７１４からステップＳ７１９までの処理を行い、アクセス権限の書き換えが不可である場合は、ステップＳ７２０およびステップＳ７２１の処理を行う。
【００４０】
アクセス権限の書き換えが許可された場合、ステップＳ７１４では、要求側システム１０２が、再びユーザＹのデータを提供側システム１０３に要求する。
ステップＳ７１５では、提供側システム１０３が、ユーザＸがユーザＹのデータにアクセスできるかどうかを連携システム１０４に問い合わせる。
ステップＳ７１６では、連携システム１０４が、ユーザＸがユーザＹのデータにアクセスできるかどうかを判定し、ユーザＸがユーザＹのデータに対してアクセス権限があることを提供側システム１０３に通知する。
ステップＳ７１７では、提供側システム１０３が、要求側システム１０２にユーザＹのデータを送る。
ステップＳ７１８では、要求側システム１０２が、ユーザＹのデータを表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ７１９では、クライアント端末１０１がユーザＹのデータ取得の画面を表示する。
【００４１】
パスワード認証が失敗した場合またはアクセス権限の書き換え不可である場合、ステップＳ７２０では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ７２１では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、同時認証が必要な場合のデータ取得処理を終了する。
【００４２】
次に、外部認証を用いる場合のデータ取得処理について図８のフローチャートを参照して説明する。なお、提供側システム１０３−１における独自の認証（以下、独自認証という）が完了しており、かつ提供側システム１０３−２では提供側システム１０３−１の独自認証を経たアクセスを許可している場合を想定する。
ステップＳ８０１では、クライアント端末１０１が、データＤ２を要求側システム１０２に要求する。
ステップＳ８０２では、要求側システム１０２が、提供側システム１０３−１の独自認証の取り込みの要求をクライアント端末１０１を介して連携システム１０４に送る。
ステップＳ８０３では、連携システム１０４が、提供側システム１０３−１の独自認証を取り込む。
ステップＳ８０４では、連携システム１０４が、独自認証の取り込みが完了したことを示すアサーション（例えば、ＳＡＭＬのＡｓｓｅｒｔｉｏｎ）を、クライアント端末１０１を介して要求側システム１０２に発行する。
【００４３】
ステップＳ８０５では、要求側システム１０２が、提供側システム１０３−２での認証の要求を連携システム１０４に送る。
ステップＳ８０６では、連携システム１０４が、認証処理を実行する。ここでは、提供側システム１０３−２が提供側システム１０３−１の認証を取り込んでいるので、提供側システム１０３−１の認証は成功となるが、提供側システム１０３−２の認証処理を実施することになる。
ステップＳ８０７では、連携システム１０４が、認証結果を要求側システム１０２に送る。以下、認証成功の場合は、ステップＳ８０８からステップＳ８１１までの処理を行い、認証失敗の場合は、ステップＳ８１２およびステップＳ８１３の処理を行う。
【００４４】
認証成功の場合、ステップＳ８０８では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ８０９では、提供側システム１０３−２が、データＤ２を要求側システム１０２に送る。
ステップＳ８１０では、要求側システム１０２が、データＤ２を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ８１１では、クライアント端末１０１が、データＤ２の取得画面を表示する。
【００４５】
認証失敗の場合、ステップＳ８１２では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ８１３では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、外部認証を取り込む場合のデータ取得処理を終了する。
【００４６】
次に、複数認証時のデータ取得処理について図９のフローチャートを参照して説明する。
図９の例では、連携システム１０４が複数認証を実行する場合に用いる認証方式の順序を示すリストを格納し、リストを参照して順次認証を実行する。
ステップＳ９０１では、クライアント端末１０１が、データＤ１を要求側システム１０２に要求する。
ステップＳ９０２では、要求側システム１０２が、ユーザＩＤおよびパスワード認証によりデータＤ１を提供側システム１０３−１に要求する。
ステップＳ９０３では、提供側システム１０３−１が、ＳＳＯ認証を実行する指示を、クライアント端末１０１を介して連携システム１０４に送る。
ステップＳ９０４では、連携システム１０４が、ＳＳＯ認証を実行するための入力画面データをクライアント端末１０１に送る。
【００４７】
ステップＳ９０５では、クライアント端末１０１がＳＳＯ認証画面を表示する。
ステップＳ９０６では、クライアント端末１０１が、入力されたデータを連携システム１０４に送る。
ステップＳ９０７では、連携システム１０４が認証処理を実行する。
【００４８】
ステップＳ９０８では、連携システム１０４がＳＳＯ認証結果をクライアント端末１０１を介してユーザに提示し、連携システム１０４自身に返す。以下、認証成功の場合は、ステップＳ９０９からステップＳ９１８までの処理を行い、認証失敗の場合は、ステップＳ９１９およびステップＳ９２０の処理を行う。
【００４９】
認証成功の場合、ステップＳ９０９では、連携システム１０４が、α認証（αは任意の認証方式を示す）を実行するための入力画面データをクライアント端末１０１に送る。
ステップＳ９１０では、クライアント端末１０１がα認証の認証画面を表示する。
【００５０】
ステップＳ９１１では、クライアント端末１０１が、ユーザから入力された認証情報を連携システム１０４に送る。
ステップＳ９１２では、連携システム１０４が、α認証処理を実行する。
ステップＳ９１３では、連携システム１０４が、α認証結果をクライアント端末１０１を介してユーザに提示し、連携システム１０４自身に返す。α認証が成功した場合、リストを参照して次の認証処理、例えばβ認証、γ認証（β、γは任意の認証方式を示す）について処理を実行するため、ステップＳ９０９からステップＳ９１３までと同様の処理を繰り返す。
【００５１】
ステップＳ９１４では、最後の認証結果が成功した場合、連携システム１０４が、認証成功の通知をクライアント端末１０１を介して要求側システム１０２に送る。
ステップＳ９１５では、要求側システム１０２が、提供側システム１０３−１に対し、認証結果を通知し、さらにデータＤ１を要求する。
【００５２】
ステップＳ９１６では、提供側システム１０３−１が、データＤ１を要求側システム１０２に送る。
ステップＳ９１７では、要求側システム１０２が、データＤ１を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ９１８では、クライアント端末１０１が、データＤ１の取得画面を表示する。
【００５３】
１つでも認証が失敗した場合、ステップＳ９１９において、連携システム１０４が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ９２０では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で複数認証時のデータ取得処理を終了する。
【００５４】
以上に示した本実施形態によれば、連携システムが格納するユーザのアクセス権限や、ユーザに提供するデータに関する認証方式などを参照し、ユーザのデータに関するアクセスの可否を判定することで、情報要求に対して柔軟に認証方式を決定できる。また、データの重要性に応じて様々な認証方式を組み合わせることができるので、重要なデータには認証の要素数を増やしてセキュリティ強度を高めるといった多様なサービスを提供することができる。
【００５５】
また本実施形態によれば、以下に示す場合にも柔軟にアクセス制御を行うことができる。
例えば、救急医療時において患者の身元は確定しているが、患者に意識がなく、既往歴やアレルギー情報が入手できない場合を想定する。もしこの患者が搬送された病院以外の、他の病院の診察券を持っていたとしても、通常であれば、医師は他の病院の診療カルテを見ることはできない。確認をとっている間にも患者を救う可能性は低くなっていく。しかし、緊急時サービスとして、「ある特別な認証方式を使って認証された医師は、他の病院が保有する患者の診療カルテを閲覧することができる」というサービスを提供することができれば、患者に対してより適切な治療ができ、結果として生命を救える可能性が高くなる。
【００５６】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００５７】
１００・・・トラストサークルシステム、１０１・・・クライアント端末、１０２・・・要求側システム、１０３・・・提供側システム、１０４・・・連携システム、１０５・・・ネットワーク、２０１・・・Ｗｅｂブラウザ、２１０・・・Ｗｅｂアクセス抽出部、２１１・・・データアクセス部、２１２，３０２・・・ユーザ情報格納部、２１３・・・アプリケーションデータ格納部、２１４・・・アクセス制御判定部、２１５・・・送受信部、２１６・・・アクセス制御部、３０１・・・Ｗｅｂアクセス受信部、３０３・・・システム情報格納部、３０４・・・マスタ情報格納部、３０５・・・認証データ格納部、３０６・・・認証画面生成部、３０７・・・認証処理部、３０８・・・アクセス権限管理部、３０９・・・アクセス制御判定部、３１０・・・通知部。
【技術分野】
【０００１】
この発明は、ユーザの用途に応じて、サービスを利用できるかどうかを判定するユーザ認証システム、方法、プログラムおよび装置に関する。
【背景技術】
【０００２】
一般的に、ユーザがあるサービスを利用する際にはユーザ認証を行なう。例えば、ユーザがＷｅｂサービスを利用する際には、ユーザ識別番号（ＩＤ）とパスワードによる認証が行われる。近年は、シングルサインオン（ＳＳＯ）機能やセキュリティを強化した二要素認証が実行される。二要素認証は、例えば、ＳＳＯ機能を利用している状態で、さらに高いセキュリティが必要な場合に、ワンタイムパスワードを利用するといった、２つの手法を用いる認証方法である。他の例としては、銀行の口座からＡＴＭを利用して現金を引き出す場合に、自分のＩＣカードとパスワードとの組み合わせによる二要素認証でサービス利用可能かどうかを判定している。さらに、その他の認証方式としては、多段認証、同時認証、外部認証などが存在する（例えば、特許文献１および特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９２１９３号公報
【特許文献２】特開２００９−０７１４３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、一般的に、１つのサービスの中では様々な認証を使用することを想定していない。例えばＳＳＯ機能のＷｅｂサービスを使用している状態で、他の認証を必要とする場合は予め作り込んでおく必要があるので、他の認証を動的に追加することができない。
さらに、複数のサービスが共存する場合は、提供する情報によりセキュリティのレベルが異なるので、様々な認証方式を用いてサービスを提供する必要があるが、現状では、サービスごとに認証方式を変えるといったきめ細かな対応ができない。
【０００５】
この発明は上記事情に着目してなされたもので、その目的とするところは、多様なデータアクセスを提供することができるユーザ認証システム、方法、プログラムおよび装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためにこの発明の一つの観点は、ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、前記要求装置は、前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出する抽出手段を具備し、前記連携装置は、ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、前記要求装置は、前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信する第１送受信手段をさらに具備し、前記提供装置は、前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信する第２送受信手段を具備することを特徴とする。
【発明の効果】
【０００７】
すなわちこの発明によれば、多様なデータアクセスを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態に係るトラストサークルシステムの一例を示す概念図。
【図２】本実施形態に係るクライアント端末、要求側システム、提供側システムを示すブロック図。
【図３】本実施形態に係る連携システムを示すブロック図。
【図４】ＳＳＯ認証の一例を示すフローチャート。
【図５】ＳＳＯ認証後のデータ取得の一例を示すフローチャート。
【図６】ＳＳＯ認証済みで、かつ多段認証に必要な場合のデータ取得の一例を示すフローチャート。
【図７】ＳＳＯ認証済みで、かつ同時認証が必要な場合のデータ取得の一例を示すフローチャート。
【図８】外部認証後のデータ取得の一例を示すフローチャート。
【図９】複数認証時のデータ取得の一例を示すフローチャート。
【発明を実施するための形態】
【０００９】
ここで、上述した認証方式について説明する。
多段認証は、アクセスしてきたユーザの認証方法が原因でアクセス拒否判定となった場合、提供側システムから送信された「アクセス許可になるために必要となる認証方法」に基づき、要求側システムが連携システムに対して追加の認証要求を実行することを可能とする認証方式である。具体的には、薬の服用歴などはＳＳＯ認証だけで閲覧できるが、病院が提供する閲覧用診療カルテといった、他人に知られると自分の身に被害が及ぶ可能性のあるデータを閲覧するときは、より強力な認証方法を使う仕組みである。
同時認証は、第１ユーザＸがＳＳＯしているときに、別の第２ユーザＹの認証を実行することで、第２ユーザＹのアクセス制御を書き換え、第１ユーザＸが第２ユーザＹのデータにアクセスできるようにする認証方式である。具体的には、第１ユーザＸが医師で、第２ユーザＹが患者である場合、医師が患者を診察しているときに、別の病院にかかっていたときの患者の電子カルテを参照できるようにする方式である。
【００１０】
外部認証は、各サービス用に用意された認証である独自の認証の結果を、ＳＳＯ内部の認証方式の一方式として取り込み、ＳＳＯ認証を受けたユーザと同じようにＳＡＭＬのＡｓｓｅｒｔｉｏｎ（ＩｄＰ（Identity Provider）が発行し、ＳＰにおけるユーザ情報を示す認証トークンのＸＭＬスキーマを規定）を発行すること、および提供側システムで独自認証方式を許可していることにより、ＳＳＯすることなしにサービスを利用できる方式である。
【００１１】
複数認証とは、複数の要素を用いた認証を同一シーケンス内で連続して実行することにより、ユーザ認証を行う方式である。具体的には、インターネットバンキングサービスを提供する銀行では、顧客識別番号、端末情報、第１暗証番号、第２暗証番号、金融債取引用暗証番号、ログインパスワードおよび合言葉といった要素を用いてユーザ認証を行う。他銀行でも複数の要素を組み合わせてサービスを提供している。
【００１２】
以下、図面を参照しながら本発明の実施形態に係るユーザ認証システム、方法、プログラムおよび装置について詳細に説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
本実施形態に係るユーザ連携システムの一例となるトラストサークルシステムについて図１を参照して説明する。
トラストサークルシステム１００は、クライアント端末１０１、要求側システム１０２、提供側システム１０３、連携システム１０４を含む。また、クライアント端末１０１、要求側システム１０２−１および１０２−２、提供側システム１０３−１および１０３−２、および連携システム１０４は、ネットワーク１０５を介して相互接続される。トラストサークルは、ＳＡＭＬ（Security Assertion Markup Language）を介して形成され、ＳＳＯやＳＬＯ（シングルログアウト）もトラストサークルに参加するシステム間で行われる。
クライアント端末１０１は、ユーザインターフェース（ＵＩ）を含み、ユーザからの入力を受け付け、またはユーザに対して情報を表示する。ユーザに対する情報の表示は、例えば、Ｗｅｂブラウザが提供するユーザインタフェースを使って実現すればよい。
【００１３】
要求側システム１０２は、クライアント端末１０１からの要求を受信する。要求側システム１０２自身でデータを提供できる場合は、要求側システム１０２自身でクライアント端末１０１にデータを提供することでサービスを提供する。要求側システム１０２自身でデータを提供できない場合は提供側システム１０３にデータを要求する。
提供側システム１０３は、要求側システム１０２にデータを提供する。なお、提供側システム１０３は、状況によって要求側システム１０２と同じ動作をおこなう。
連携システム１０４は、要求側システム１０２と提供側システム１０３とのシステム間の連携をおこなう。また、連携システム１０４は、認証サーバとしての役割を持ち、システムを利用するユーザのアクセス制御を管理する。
本実施形態では、ユーザがクライアント端末１０１を用いて要求側システム１０２−１のサービスＳＡにアクセスし、サービスＳＡが提供側システム１０３−１および１０３−２に格納されるデータＤ１およびＤ２のそれぞれを用いてユーザに情報を提供する場合を想定する。
【００１４】
次に、クライアント端末１０１、要求側システム１０２および提供側システム１０３について図２のブロック図を参照して説明する。
クライアント端末１０１は、Ｗｅｂブラウザ２０１を含む。クライアント端末１０１は、ユーザがクライアント端末１０１のＷｅｂブラウザに入力した情報を要求側システム１０２に送り、要求側システム１０２から受け取った情報をＷｅｂブラウザに表示する。これにより、ユーザはサービスに関する情報を閲覧することができる。
【００１５】
要求側システム１０２は、Ｗｅｂアクセス抽出部２１０、データアクセス部２１１、ユーザ情報格納部２１２、アプリケーションデータ格納部２１３、アクセス制御判定部２１４、送受信部２１５を含む。また、Ｗｅｂアクセス抽出部２１０およびアクセス制御判定部２１４をアクセス制御部２１６とも呼ぶ。
Ｗｅｂアクセス抽出部２１０は、クライアント端末１０１のＷｅｂブラウザ２０１から要求されたＨＴＴＰリクエストを受信し、ＨＴＴＰリクエストを解析する。この解析処理により、ユーザが要求するデータと、ユーザ情報と、データの表示許可のために指定されている認証方式とを抽出する。
データアクセス部２１１は、Ｗｅｂアクセス抽出部２１０からユーザ情報格納部２１２とアプリケーションデータ格納部２１３とにアクセスする。
ユーザ情報格納部２１２は、ユーザに関する情報、例えば、ユーザ名（ユーザＩＤ）、組織、内部組織、資格といった属性をそれぞれ対応付けて格納する。組織および内部組織は、ユーザの所属を示し、アクセス権限の一要素となる。例えば組織「病院」、内部組織「外科」が挙げられる。資格は、ユーザが所有する資格であり、アクセス権限の一要素となる。例えば、資格「医師」が挙げられる。
【００１６】
アプリケーションデータ格納部２１３は、アプリケーションで使用するデータ、またはユーザが格納したデータを格納する。アプリケーションで使用するデータは、具体的には、起動のために必要となる設定ファイル、レスポンスデータである。レスポンスデータは、例えばＨＴＭＬ（Hypertext Markup Language）に代表されるようなマークアップ言語で構成されるＨＴＴＰレスポンスであり、Ｗｅｂブラウザにデータを表示させるためのデータである。なお、Ｗｅｂブラウザに限らずユーザがデータを認識しやすい表示形式であれば何でもよい。ユーザが格納したデータは、具体的には、ユーザに提供するデータである。なお、要求側システム１０２は、アプリケーションデータ格納部２１３を有さなくてもよい。
アクセス制御判定部２１４は、ユーザ情報格納部２１２に格納されるユーザ情報およびアプリケーションデータ格納部２１３が存在する場合はアプリケーションデータ格納部２１３に格納されるデータを参照して、ユーザがアクセス可能であるかどうかを判定する。
なお、要求側システム１０２自身でユーザがアクセス可能であるかどうかを判定できない場合、またはユーザにデータを提供できない場合は、提供側システム１０３に判定およびデータ提供を依頼する。
送受信部２１５は、信号を送受信する。具体的に本実施形態では、データまたはデータを要求する要求信号を送受信する。
【００１７】
提供側システム１０３は、Ｗｅｂアクセス抽出部２１０、データアクセス部２１１、ユーザ情報格納部２１２、アプリケーションデータ格納部２１３、アクセス制御判定部２１４および送受信部２１５を含む。また、Ｗｅｂアクセス抽出部２１０およびアクセス制御判定部２１４をアクセス制御部２１６とも呼ぶ。提供側システム１０３の各ブロックは、要求側システム１０２とほぼ同様であり、同様の動作を行うので異なる部分のみ説明する。アプリケーションデータ格納部２１３は、データとデータの認証方式とを対応付けて格納する。なお、提供側システム１０３に格納されるデータは全て同じ認証方式としてもよい。
【００１８】
また、提供側システム１０３は、要求側システム１０２の要求に応じて、認証が成功している場合に、アプリケーションデータ格納部２１３からデータを抽出して要求側システム１０２にデータを送る。なお、アプリケーションデータ格納部２１３に格納されるデータは、データの重要度に応じて認証方式がそれぞれ定められていてもよい。例えば、データの重要度が高いほど、認証の数を増やしてもよい。具体的には、重要度が高いデータに関して、ＩＤ／パスワード認証のほか、端末情報、暗証番号、生体認証などといった多要素の認証を行えばよい。また、データの重要度に応じてセキュリティ強度を変更した認証を行ってもよい。例えば、データの重要度が低いものに関しては、ＩＤ／パスワード認証のみとし、データの重要度が高いほど、生体認証などセキュリティ強度が高い認証を用いる。なお、データの重要度に応じて、認証の数とセキュリティ強度の高い認証との両方を用いて認証方式を定めてもよい。
データの認証方式を変更する場合は、クライアント端末１０１から送られるＨＴＴＰリクエストに埋め込まれる認証方式を変更し、各システムにおいて変更した認証方式に対応するアプリケーションを組み込めばよい。
【００１９】
次に、連携システム１０４について図３のブロック図を参照して説明する。
連携システム１０４は、Ｗｅｂアクセス受信部３０１、ユーザ情報格納部３０２、システム情報格納部３０３、マスタ情報格納部３０４、認証データ格納部３０５、認証画面生成部３０６、認証処理部３０７、アクセス権限管理部３０８、アクセス制御判定部３０９、および通知部３１０を含む。
【００２０】
Ｗｅｂアクセス受信部３０１は、要求側システム１０２または提供側システム１０３から、データを要求するユーザのユーザ情報と、データにアクセスするための認証方式の種類とを受信する。また、クライアント端末１０１から、ユーザにより入力される認証処理に必要な認証情報を受信する。
ユーザ情報格納部３０２は、連携システムにおけるユーザＩＤとユーザのそれぞれの属性とを対応付けて格納する。具体的には、要求側システム１０２および提供側システム１０３におけるユーザ情報格納部２１２と同様の情報を格納するが、ユーザＩＤおよび氏名ではなく、連携システム１０４における仮ＩＤを用いる点が異なる。なお、仮ＩＤはＳＡＭＬで用いられる一般的なものであるため、具体的な説明は省略する。
システム情報格納部３０３は、要求側システム１０２および提供側システム１０３が有するシステムに関する情報（例えば、システムの種別）とシステムで使用する認証方式とを格納する。
【００２１】
マスタ情報格納部３０４は、属性のＩＤと属性名称とをそれぞれ対応付けて格納する。具体的には、例えば、組織データであれば、「組織ＩＤ：１００１、組織属性名称：Ａ病院」、資格データであれば、「資格ＩＤ：ｑ００１、資格属性名称：医師」となる。また、新しく資格を追加したい場合は、新規に資格ＩＤと資格属性名称とを登録すればよい。
認証データ格納部３０５は、認証を実行するために必要な認証方式のデータを格納する。例えば、ＩＤ／パスワード認証や生体認証に関するデータを格納する。
認証画面生成部３０６は、Ｗｅｂアクセス受信部３０１からデータの認証方式を受け取り、受け取った認証方式の認証処理で必要となるユーザの認証情報を取得するための、入力画面データを生成する。また、認証が失敗した場合のエラー画面を表示するためのレスポンスデータも生成する。
【００２２】
認証処理部３０７は、Ｗｅｂアクセス受信部３０１からデータの認証方式の種類と認証に必要なユーザの認証情報とを、認証データ格納部３０５から認証データをそれぞれ受け取り、認証処理を実行し、認証結果を出力する。具体的には、例えばＩＤ／パスワード認証であれば、認証情報としてユーザＩＤとユーザが入力したパスワードとを受け取り、認証データと一致するかどうかを判定し、認証結果として出力する。なお、システム全体で認証方式が統一されている場合は、認証処理部３０７は、システム情報格納部３０３からシステムにおける認証方式を受け取り、認証方式を実行すればよい。
アクセス権限管理部３０８は、ユーザ、組織などの属性、およびシステムに関連するデータへのアクセス権限を管理する。アクセス権限管理部３０８に格納されるデータは、例えば以下のように記述される。
１）資格Ｃを有するユーザは、提供側システム１０３が有する、組織Ｓが保有する全てのユーザデータを検索することができるが、更新できない。
２）資格Ｄを有するユーザは、提供側システム１０３が有する、組織Ｓが保有する全てのユーザデータを更新することができる。
なお、ユーザが有する資格に応じて、組織Ｓが保有するユーザデータの扱いを変更してもよい。
【００２３】
アクセス制御判定部３０９は、Ｗｅｂアクセス受信部３０１からデータ要求したユーザのユーザ情報を、アクセス権限管理部３０８からデータ要求したユーザのアクセス権限をそれぞれ受け取り、データ要求したユーザがアクセス権限を有するかどうかを判定する。
通知部３１０は、認証画面生成部３０６から入力画面データを受け取り、ユーザに認証情報を入力させるため外部へ入力画面データを送信する。また、通知部３１０は、認証処理部３０７から認証結果を、アクセス制御判定部３０９から判定結果をそれぞれ受け取り、要求に応じて要求側システム１０２または提供側システム１０３に出力する。
【００２４】
ここで、トラストサークルシステムにおける認証処理の流れについて説明する。
はじめにユーザがクライアント端末１０１のＷｅｂブラウザから要求側システム１０２にアクセスすると、クライアント端末１０１にユーザが利用できるサービスの一覧が表示される。ユーザは、その中から自分が利用したいサービスへのアクセスを要求する。このとき、リンク先のデータにどの認証方式を用いるのかが記述されている。
【００２５】
要求側システム１０２では、Ｗｅｂアクセス抽出部２１０がクライアント端末１０１から送られてきたリクエストを解析して、どの認証方式を用いるかを抽出する。アクセスを要求したユーザと認証方式とに応じて、要求側システム１０２は連携システム１０４にアクセス権限の可否と認証処理とを要求する。必要な場合は、提供側システム１０３にアクセス権限の可否を要求する。
【００２６】
連携システム１０４は、アクセスの可否の判定と認証処理とを実行し、判定結果と認証結果とを結果情報として要求側システム１０２に送る。
クライアント端末１０１は、ユーザがアクセス可能でありかつ認証成功の場合、提供側システム１０３から要求側システム１０２を介して、所望のデータを受信することができる。一方、ユーザがアクセス不可であるかまたは認証失敗の場合は、クライアント端末１０１は、エラー画面をユーザに表示する。
【００２７】
以下、具体的な認証方式におけるクライアント端末１０１、要求側システム１０２、提供側システム１０３および連携システム１０４の動作シーケンスについて、図４から図９までを参照して説明する。
ＳＳＯ認証について図４のフローチャートを参照して説明する。
ステップＳ４０１では、クライアント端末１０１がアクセスを要求側システム１０２に要求する。
【００２８】
ステップＳ４０２では、要求側システム１０２が、認証を要求するためのメッセージを連携システム１０４に送る。
ステップＳ４０３では、連携システム１０４が、必要に応じてユーザ認証を行う。
ステップＳ４０４では、連携システム１０４が、認証結果をクライアント端末１０１を介して要求側システム１０２に送る。認証成功の場合は、ステップＳ４０５およびステップＳ４０６に進み、認証失敗の場合は、ステップＳ４０７およびステップＳ４０８に進む。
【００２９】
ステップＳ４０５では、要求側システム１０２が、アクセス許可を示す画面を表示させるためのレスポンスデータをクライアント端末１０１に送り、ステップＳ４０６では、クライアント端末１０１が、認証が成功しアクセス可能であることを示す画面をＷｅｂブラウザなどに表示する。
【００３０】
ステップＳ４０７では、要求側システム１０２が、エラー画面を表示させるためのデータをクライアント端末１０１に送り、ステップＳ４０８では、クライアント端末１０１が、認証が失敗したことを示す画面をＷｅｂブラウザなどに表示する。
次に、ＳＳＯ認証済みの状態でのデータ取得処理について図５のフローチャートを参照して説明する。
ステップＳ５０１では、クライアント端末１０１が、データＤ１を要求側システム１０２に要求する。なお、データＤ１は、ここでは提供側システム１０３−１に格納されるデータとする。
ステップＳ５０２では、要求側システム１０２が、要求側システム１０２自身はデータＤ１を有していないため、データＤ１を提供側システム１０３−１に要求する。
ステップＳ５０３では、提供側システム１０３−１が、ユーザがデータＤ１にアクセス可能であるかどうかの情報を得るための確認指示として、例えばユーザ情報を連携システム１０４に送る。
【００３１】
ステップＳ５０４では、連携システム１０４が、ユーザがデータＤ１にアクセス可能であるかどうかを判定し、ここでは、ユーザがデータＤ１にアクセス可能であることを示す結果情報を提供側システム１０３−１に送る。
ステップＳ５０５では、提供側システム１０３−１が、データＤ１を要求側システム１０２に送る。
ステップＳ５０６では、要求側システム１０２が、データＤ１を表示させるためのレスポンスデータを送る。
ステップＳ５０７では、クライアント端末１０１が、要求側システム１０２から送られたデータのフォーマットに従ってデータＤ１の取得画面を表示する。以上で、ＳＳＯ認証済みの状態でのデータ取得の処理を終了する。
【００３２】
次に、ＳＳＯ認証済みの状態で、かつ多段認証が必要となる場合のデータ取得処理について図６のフローチャートを参照して説明する。なお、図６の例では、多段認証の一方式として、生体認証を例に説明するが、生体認証に限らずどのような認証でもよい。
ステップＳ６０１では、クライアント端末１０１が、データＤ２を要求側システム１０２に要求する。なお、データＤ２は、提供側システム１０３−２に格納されるデータとする。
ステップＳ６０２では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ６０３では、提供側システム１０３−２が、ユーザの属性やデータ種別などから、生体認証が必要であると判定する。その後提供側システム１０３−２は、生体認証が必要であることの通知を要求側システム１０２に送る。
【００３３】
ステップＳ６０４では、要求側システム１０２が、生体認証を実行するための入力画面データを、クライアント端末１０１を介して連携システム１０４に要求する。
ステップＳ６０５では、連携システム１０４が、入力画面データをクライアント端末１０１に送る。
ステップＳ６０６では、クライアント端末１０１が、生体認証のための入力画面を表示する。その後ユーザが必要な生体認証に関する認証情報を入力する。
ステップＳ６０７では、クライアント端末１０１が、入力された生体認証に関する認証情報を連携システム１０４に送る。
ステップＳ６０８では、連携システム１０４が、生体認証処理を実行する。
【００３４】
ステップＳ６０９では、連携システム１０４が、生体認証処理の結果、すなわち認証成功か認証失敗かに関する認証結果の通知を、クライアント端末１０１を介して要求側システム１０２に送る。
ステップＳ６１０では、要求側システム１０２が認証結果を提供側システム１０３−２に通知する。以下、認証成功の場合は、ステップＳ６１１からステップＳ６１４までの処理を行い、認証失敗の場合は、ステップＳ６１５およびステップＳ６１６の処理を行う。
【００３５】
認証成功の場合、ステップＳ６１１では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ６１２では、提供側システム１０３−２が、データＤ２を要求側システム１０２に送る。
ステップＳ６１３では、要求側システム１０２が、データＤ２を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ６１４では、クライアント端末１０１が、データＤ２の取得画面を表示する。
【００３６】
認証失敗の場合、ステップＳ６１５では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ６１６では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、多段認証が必要となる場合のデータ取得処理を終了する。
【００３７】
次に、ＳＳＯ認証済みの状態で、かつ同時認証が必要となる場合のデータ取得処理について図７のフローチャートを参照して説明する。なお、図７の例では、同時認証の一方式として、ユーザＩＤおよびパスワード認証を例に説明するが、ユーザＩＤおよびパスワード認証に限らずどのような認証でもよい。
なお、図７の例では、クライアント端末１０１では、ユーザＸで認証済みの状態であり、ユーザＸが初めてユーザＹのデータを取得する場合を想定する。
【００３８】
ステップＳ７０１では、クライアント端末１０１が、ユーザＹのデータを要求側システム１０２に要求する。
ステップＳ７０２では、要求側システム１０２が、ユーザＹのデータを提供側システム１０３に要求する。
ステップＳ７０３では、提供側システム１０３が、ユーザＸはユーザＹのデータに対してアクセス権限を有するかどうかの確認指示を、連携システム１０４に送る。
ステップＳ７０４では、連携システム１０４が、ユーザＸのアクセス権限を判定する。ここでは、ユーザＸの認証では、ユーザＹのデータにアクセスできないので、ユーザＸはアクセス不可であることの通知を提供側システム１０３に送る。
ステップＳ７０５では、提供側システム１０３が、ユーザＸがユーザＹのデータにアクセス不可であることの通知を要求側システム１０２に送る。
【００３９】
ステップＳ７０６では、要求側システム１０２が、ユーザＹのアクセス制御を書き換えてユーザＸがアクセスできるようにするため、アクセス権限の書き換え通知をクライアント端末１０１を介して連携システム１０４に送る。
ステップＳ７０７では、連携システム１０４が、ユーザＹの認証情報を入力するための入力画面データを生成して、クライアント端末１０１に送る。
ステップＳ７０８では、クライアント端末１０１が、ユーザが入力した情報（ユーザＩＤおよびパスワード）を連携システム１０４に送る。
ステップＳ７０９では、連携システム１０４が、パスワード認証処理を実行する。
ステップＳ７１０では、連携システム１０４が、認証結果をクライアント端末１０１を介して要求側システム１０２に送る。ここではパスワード認証が成功した場合を想定する。
ステップＳ７１１では、要求側システム１０２が、ユーザＹのデータに関するアクセス権限の書き換え指示を連携システム１０４に送る。
ステップＳ７１２では、連携システム１０４が、アクセス権限管理部３０８に格納されるアクセス権限の書き換えを実行する。
ステップＳ７１３では、連携システム１０４が、アクセス権限の書き換え結果をクライアント端末１０１を介して要求側システム１０２に送る。以下、アクセス権限の書き換えが許可された場合は、ステップＳ７１４からステップＳ７１９までの処理を行い、アクセス権限の書き換えが不可である場合は、ステップＳ７２０およびステップＳ７２１の処理を行う。
【００４０】
アクセス権限の書き換えが許可された場合、ステップＳ７１４では、要求側システム１０２が、再びユーザＹのデータを提供側システム１０３に要求する。
ステップＳ７１５では、提供側システム１０３が、ユーザＸがユーザＹのデータにアクセスできるかどうかを連携システム１０４に問い合わせる。
ステップＳ７１６では、連携システム１０４が、ユーザＸがユーザＹのデータにアクセスできるかどうかを判定し、ユーザＸがユーザＹのデータに対してアクセス権限があることを提供側システム１０３に通知する。
ステップＳ７１７では、提供側システム１０３が、要求側システム１０２にユーザＹのデータを送る。
ステップＳ７１８では、要求側システム１０２が、ユーザＹのデータを表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ７１９では、クライアント端末１０１がユーザＹのデータ取得の画面を表示する。
【００４１】
パスワード認証が失敗した場合またはアクセス権限の書き換え不可である場合、ステップＳ７２０では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ７２１では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、同時認証が必要な場合のデータ取得処理を終了する。
【００４２】
次に、外部認証を用いる場合のデータ取得処理について図８のフローチャートを参照して説明する。なお、提供側システム１０３−１における独自の認証（以下、独自認証という）が完了しており、かつ提供側システム１０３−２では提供側システム１０３−１の独自認証を経たアクセスを許可している場合を想定する。
ステップＳ８０１では、クライアント端末１０１が、データＤ２を要求側システム１０２に要求する。
ステップＳ８０２では、要求側システム１０２が、提供側システム１０３−１の独自認証の取り込みの要求をクライアント端末１０１を介して連携システム１０４に送る。
ステップＳ８０３では、連携システム１０４が、提供側システム１０３−１の独自認証を取り込む。
ステップＳ８０４では、連携システム１０４が、独自認証の取り込みが完了したことを示すアサーション（例えば、ＳＡＭＬのＡｓｓｅｒｔｉｏｎ）を、クライアント端末１０１を介して要求側システム１０２に発行する。
【００４３】
ステップＳ８０５では、要求側システム１０２が、提供側システム１０３−２での認証の要求を連携システム１０４に送る。
ステップＳ８０６では、連携システム１０４が、認証処理を実行する。ここでは、提供側システム１０３−２が提供側システム１０３−１の認証を取り込んでいるので、提供側システム１０３−１の認証は成功となるが、提供側システム１０３−２の認証処理を実施することになる。
ステップＳ８０７では、連携システム１０４が、認証結果を要求側システム１０２に送る。以下、認証成功の場合は、ステップＳ８０８からステップＳ８１１までの処理を行い、認証失敗の場合は、ステップＳ８１２およびステップＳ８１３の処理を行う。
【００４４】
認証成功の場合、ステップＳ８０８では、要求側システム１０２が、データＤ２を提供側システム１０３−２に要求する。
ステップＳ８０９では、提供側システム１０３−２が、データＤ２を要求側システム１０２に送る。
ステップＳ８１０では、要求側システム１０２が、データＤ２を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ８１１では、クライアント端末１０１が、データＤ２の取得画面を表示する。
【００４５】
認証失敗の場合、ステップＳ８１２では、要求側システム１０２が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ８１３では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で、外部認証を取り込む場合のデータ取得処理を終了する。
【００４６】
次に、複数認証時のデータ取得処理について図９のフローチャートを参照して説明する。
図９の例では、連携システム１０４が複数認証を実行する場合に用いる認証方式の順序を示すリストを格納し、リストを参照して順次認証を実行する。
ステップＳ９０１では、クライアント端末１０１が、データＤ１を要求側システム１０２に要求する。
ステップＳ９０２では、要求側システム１０２が、ユーザＩＤおよびパスワード認証によりデータＤ１を提供側システム１０３−１に要求する。
ステップＳ９０３では、提供側システム１０３−１が、ＳＳＯ認証を実行する指示を、クライアント端末１０１を介して連携システム１０４に送る。
ステップＳ９０４では、連携システム１０４が、ＳＳＯ認証を実行するための入力画面データをクライアント端末１０１に送る。
【００４７】
ステップＳ９０５では、クライアント端末１０１がＳＳＯ認証画面を表示する。
ステップＳ９０６では、クライアント端末１０１が、入力されたデータを連携システム１０４に送る。
ステップＳ９０７では、連携システム１０４が認証処理を実行する。
【００４８】
ステップＳ９０８では、連携システム１０４がＳＳＯ認証結果をクライアント端末１０１を介してユーザに提示し、連携システム１０４自身に返す。以下、認証成功の場合は、ステップＳ９０９からステップＳ９１８までの処理を行い、認証失敗の場合は、ステップＳ９１９およびステップＳ９２０の処理を行う。
【００４９】
認証成功の場合、ステップＳ９０９では、連携システム１０４が、α認証（αは任意の認証方式を示す）を実行するための入力画面データをクライアント端末１０１に送る。
ステップＳ９１０では、クライアント端末１０１がα認証の認証画面を表示する。
【００５０】
ステップＳ９１１では、クライアント端末１０１が、ユーザから入力された認証情報を連携システム１０４に送る。
ステップＳ９１２では、連携システム１０４が、α認証処理を実行する。
ステップＳ９１３では、連携システム１０４が、α認証結果をクライアント端末１０１を介してユーザに提示し、連携システム１０４自身に返す。α認証が成功した場合、リストを参照して次の認証処理、例えばβ認証、γ認証（β、γは任意の認証方式を示す）について処理を実行するため、ステップＳ９０９からステップＳ９１３までと同様の処理を繰り返す。
【００５１】
ステップＳ９１４では、最後の認証結果が成功した場合、連携システム１０４が、認証成功の通知をクライアント端末１０１を介して要求側システム１０２に送る。
ステップＳ９１５では、要求側システム１０２が、提供側システム１０３−１に対し、認証結果を通知し、さらにデータＤ１を要求する。
【００５２】
ステップＳ９１６では、提供側システム１０３−１が、データＤ１を要求側システム１０２に送る。
ステップＳ９１７では、要求側システム１０２が、データＤ１を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ９１８では、クライアント端末１０１が、データＤ１の取得画面を表示する。
【００５３】
１つでも認証が失敗した場合、ステップＳ９１９において、連携システム１０４が、エラー画面を表示するためのレスポンスデータをクライアント端末１０１に送る。
ステップＳ９２０では、クライアント端末１０１が、認証失敗を示す画面を表示する。以上で複数認証時のデータ取得処理を終了する。
【００５４】
以上に示した本実施形態によれば、連携システムが格納するユーザのアクセス権限や、ユーザに提供するデータに関する認証方式などを参照し、ユーザのデータに関するアクセスの可否を判定することで、情報要求に対して柔軟に認証方式を決定できる。また、データの重要性に応じて様々な認証方式を組み合わせることができるので、重要なデータには認証の要素数を増やしてセキュリティ強度を高めるといった多様なサービスを提供することができる。
【００５５】
また本実施形態によれば、以下に示す場合にも柔軟にアクセス制御を行うことができる。
例えば、救急医療時において患者の身元は確定しているが、患者に意識がなく、既往歴やアレルギー情報が入手できない場合を想定する。もしこの患者が搬送された病院以外の、他の病院の診察券を持っていたとしても、通常であれば、医師は他の病院の診療カルテを見ることはできない。確認をとっている間にも患者を救う可能性は低くなっていく。しかし、緊急時サービスとして、「ある特別な認証方式を使って認証された医師は、他の病院が保有する患者の診療カルテを閲覧することができる」というサービスを提供することができれば、患者に対してより適切な治療ができ、結果として生命を救える可能性が高くなる。
【００５６】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００５７】
１００・・・トラストサークルシステム、１０１・・・クライアント端末、１０２・・・要求側システム、１０３・・・提供側システム、１０４・・・連携システム、１０５・・・ネットワーク、２０１・・・Ｗｅｂブラウザ、２１０・・・Ｗｅｂアクセス抽出部、２１１・・・データアクセス部、２１２，３０２・・・ユーザ情報格納部、２１３・・・アプリケーションデータ格納部、２１４・・・アクセス制御判定部、２１５・・・送受信部、２１６・・・アクセス制御部、３０１・・・Ｗｅｂアクセス受信部、３０３・・・システム情報格納部、３０４・・・マスタ情報格納部、３０５・・・認証データ格納部、３０６・・・認証画面生成部、３０７・・・認証処理部、３０８・・・アクセス権限管理部、３０９・・・アクセス制御判定部、３１０・・・通知部。
【特許請求の範囲】
【請求項１】
ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、
前記要求装置は、
前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出する抽出手段を具備し、
前記連携装置は、
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、
前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、
前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、
前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、
前記要求装置は、
前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信する第１送受信手段をさらに具備し、
前記提供装置は、
前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信する第２送受信手段を具備することを特徴とするユーザ認証システム。
【請求項２】
前記管理手段は、認証が成功した場合に前記ユーザがデータにアクセス可能となるように該ユーザのアクセス権限を書き換えることを特徴とする請求項１に記載のユーザ認証システム。
【請求項３】
前記連携装置は、第１提供装置におけるデータの第１認証方式を第２提供装置におけるデータの第２認証方式として採用し、前記要求装置が該第２提供装置からデータを受信する場合に、前記第１認証方式を用いて認証処理を行うことを特徴とする請求項１に記載のユーザ認証システム。
【請求項４】
前記提供装置は、前記第１データと該第１データの第３認証方式とを対応付けて格納するデータ格納手段をさらに具備し、
前記連携装置は、前記第１認証方式と前記第３認証方式とが異なる場合、該第３認証方式に応じた前記第１ユーザの認証に必要な第３認証情報を前記端末から受信し、前記第３認証方式および該第３認証情報に基づいて、前記第１ユーザを認証することを特徴とする請求項１に記載のユーザ認証システム。
【請求項５】
データの重要度が高いほど、認証の数が多いか該認証のセキュリティ強度が高いかの少なくともどちらか一方であることを特徴とする請求項１に記載のユーザ認証システム。
【請求項６】
ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムで用いられるユーザ認証方法であって、
前記要求装置は、
前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出し、
前記連携装置は、
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理し、
前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納し、
前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定し、
前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信し、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証し、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知し、
前記要求装置は、
前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信し、
前記提供装置は、
前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信することを具備することを特徴とするユーザ認証方法。
【請求項７】
コンピュータを、請求項１に記載のユーザ認証システムの各手段として実行させるためのプログラム。
【請求項８】
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、
データを提供するシステムの種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、
第１ユーザから前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、
該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、該第１データが提供可能であることを示す結果情報を通知する通知手段と、を具備することを特徴とするユーザ認証装置。
【請求項１】
ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムであって、
前記要求装置は、
前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出する抽出手段を具備し、
前記連携装置は、
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、
前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、
前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、
前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知する通知手段と、を具備し、
前記要求装置は、
前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信する第１送受信手段をさらに具備し、
前記提供装置は、
前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信する第２送受信手段を具備することを特徴とするユーザ認証システム。
【請求項２】
前記管理手段は、認証が成功した場合に前記ユーザがデータにアクセス可能となるように該ユーザのアクセス権限を書き換えることを特徴とする請求項１に記載のユーザ認証システム。
【請求項３】
前記連携装置は、第１提供装置におけるデータの第１認証方式を第２提供装置におけるデータの第２認証方式として採用し、前記要求装置が該第２提供装置からデータを受信する場合に、前記第１認証方式を用いて認証処理を行うことを特徴とする請求項１に記載のユーザ認証システム。
【請求項４】
前記提供装置は、前記第１データと該第１データの第３認証方式とを対応付けて格納するデータ格納手段をさらに具備し、
前記連携装置は、前記第１認証方式と前記第３認証方式とが異なる場合、該第３認証方式に応じた前記第１ユーザの認証に必要な第３認証情報を前記端末から受信し、前記第３認証方式および該第３認証情報に基づいて、前記第１ユーザを認証することを特徴とする請求項１に記載のユーザ認証システム。
【請求項５】
データの重要度が高いほど、認証の数が多いか該認証のセキュリティ強度が高いかの少なくともどちらか一方であることを特徴とする請求項１に記載のユーザ認証システム。
【請求項６】
ユーザからの入力を受け付ける端末と、データを提供する提供装置と、前記端末からの要求によりデータを前記提供装置に要求する要求装置と、認証を行う連携装置とを具備するユーザ認証システムで用いられるユーザ認証方法であって、
前記要求装置は、
前記端末から要求される第１データに関して、第１データを要求する第１ユーザのユーザ情報と該第１データの第１認証方式とを抽出し、
前記連携装置は、
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理し、
前記提供装置の種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納し、
前記要求装置から前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定し、
前記要求装置から前記第１データの要求があった場合、該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信し、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証し、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、前記第１データが提供可能であることを示す結果情報を前記要求装置および前記提供装置の少なくともどちらか一方に通知し、
前記要求装置は、
前記結果情報を受け取った場合、前記提供装置に前記第１データを要求する要求信号を送信し、
前記提供装置は、
前記結果情報を受け取った場合、前記要求信号に応じて前記第１データを該要求装置に送信することを具備することを特徴とするユーザ認証方法。
【請求項７】
コンピュータを、請求項１に記載のユーザ認証システムの各手段として実行させるためのプログラム。
【請求項８】
ユーザと該ユーザの属性との少なくともどちらか一方に応じた、データへのアクセス権限を管理するアクセス権限管理手段と、
データを提供するシステムの種別、前記属性、およびデータの少なくとも１つに基づく、データにアクセスするための認証方式を格納する認証データ格納手段と、
第１ユーザから前記第１データの要求があった場合、前記ユーザ情報と前記第１ユーザの第１アクセス権限とを参照して、該第１ユーザが前記第１データにアクセス可能であるかどうかを判定する判定手段と、
該第１データの前記第１認証方式に応じた、前記第１ユーザの認証に必要な第１認証情報を前記端末から受信する受信手段と、
前記第１認証方式および前記第１認証情報に基づいて、前記第１ユーザを認証する認証手段と、
前記第１ユーザが前記第１データにアクセス可能であると判定され、かつ認証が成功した場合に、該第１データが提供可能であることを示す結果情報を通知する通知手段と、を具備することを特徴とするユーザ認証装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−３０１２４（Ｐ２０１３−３０１２４Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１１−１６７４８１（Ｐ２０１１−１６７４８１）
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]