JP5644565B2 - 認証システム及び認証方法 - Google Patents

Description

本発明は、ユーザが企業をまたがってＷｅｂ系アプリケーションを利用できる認証システムに関するものである。

複数の企業間で用いられるＷｅｂ系クライアント／サーバ型のシステムにおいて、自社の社員の個人情報を他社に提供すること無く、複数の認証システム間でシングルサインオン（１度の認証情報の入力により複数システムが利用可能とする方法）を行う認証システムとして、従来、クライアント端末と認証処理を行う複数の認証サーバとクライアント端末からの要求に基づいて適切な認証サーバを選択するセンタサーバとを備え、センタサーバにより選択された認証サーバから認証されたユーザは、選択された認証サーバおよび他の認証サーバへのアクセスが可能となる認証システムがある（例えば、特許文献１参照）。

特開２０１０−２０５１６６号公報

特許文献１に記載の認証システムにおいては、選択された認証サーバ以外の認証サーバはクライアント端末からのアクセスに対してユーザ認証を行わないため、不正アクセスがなされた場合であってもユーザを特定できないという問題があった。

本発明はこのような問題を解決するためになされたもので、複数の認証サーバ間で個人情報を開示すること無くシングルサインオンができ、かつ、不正アクセスがなされた場合に不正アクセスしたユーザの特定が可能な認証システムを得ることを目的とする。

本発明に係わる認証システムは、ユーザ識別子を有するユーザにより使用されるクライアント端末装置、ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第１の記憶部、クライアント端末装置からのアクセスを認証する第１の認証装置、 第１の認証装置により認証されたクライアント端末装置からのアクセスを認証する第２の認証装置、クライアント端末装置から第２の認証装置を介してアクセスされるアプリケーション部、を備えた認証システムであって、 第１の認証装置は、クライアント端末装置からユーザ識別子を受信する受信部、受信部により受信されたユーザ識別子を用いて第１の変換ＩＤを生成する第１のＩＤ変換部、およびクライアント端末装置からアプリケーション部へのアクセスが要求された場合にユーザ情報テーブルからユーザ識別子に対応する属性情報を取得し、属性情報及び第１のＩＤ変換部により生成された第１の変換ＩＤを含む認証連携用トークンを第２の認証装置に送信する送信部、を有し、第２の認証装置は、第１の認証装置から受信した認証連携用トークンが自装置内に登録されている認証連携用トークンと一致するか否かの確認を行うことによりクライアント端末装置からのアクセスを認証する認証部と、第１の認証装置から受信した認証連携用トークンが登録されている認証連携用トークンと一致している場合に当該認証連携用トークンから取得される属性情報を用いて第２の認証装置にアクセスするための第２の変換ＩＤを生成する第２のＩＤ変換部と、認証部により認証されたクライアント端末装置のアプリケーション部へのアクセス情報を第１の変換ＩＤと共に第１のアクセスログテーブルに記録する第１の記録部と、を有することを特徴とするものである。

本発明によれば、認証システムは上記構成を備え、第１の認証装置がユーザ識別子から生成した変換ＩＤとユーザの属性情報を第２の認証装置に送信し、第２の認証装置は受信した属性情報を用いてユーザの認証を行い、このユーザによるアプリケーション部へのアクセス情報を第１の認証装置から受信した変換ＩＤと共にアクセスログテーブルに記録することにより、第１の認証装置と第２の認証装置間で個人情報であるユーザ識別子を開示すること無くシングルサインオンでき、かつ、不正アクセスがなされた場合には第２の認証装置において変換ＩＤにより不正アクセスしたユーザを特定できる。

実施の形態１に係る認証システムの構成を示す図である。 実施の形態１におけるクライアント端末及び認証サーバ間の認証シーケンスを示す図である。 実施の形態１における複数企業間の認証シーケンスを示す図である。 実施の形態１における認証処理を示すフローチャートである。 図４の認証連携受入処理Ｘを示すフローチャートである。 図４の認証連携受入処理Ｙを示すフローチャートである。 実施の形態１におけるアクセス監査処理を示すフローチャートである。 実施の形態２に係る認証システムの構成を示す図である。 実施の形態２における認証連携受入処理Ｘを示すフローチャートである。 実施の形態２における認証連携受入処理Ｙを示すフローチャートである。 実施の形態２における複数企業間の認証シーケンスを示す図である。 実施の形態２におけるアクセス監査処理を示すフローチャートである。

実施の形態１．
本発明を実施するための実施の形態１に係る認証システムを図１ないし図７を用いて説明する。図１において、認証システム１００は企業Ａのイントラネット１０ａ、企業Ｂのイントラネット１０ｂ、２つのイントラネット１０ａ、１０ｂを接続するネットワーク１１を備え、企業Ａのイントラネット１０ａにはユーザにより利用されるクライアント端末装置１ａ〜１ｃ、クライアント端末装置からのアクセスを認証する認証サーバ２ａすなわち第１の認証装置、ユーザ情報テーブル３１ａやＩＤ変換ログテーブル３２を記録したリポジトリ３ａすなわち第１の記憶部及び第２の記憶部、認証サーバ２ａにより認証されたユーザによる利用が可能な業務アプリケーション部４ａ、４ｂ（以降、業務アプリ４ａ、４ｂと称する）、ユーザＩＤを検索するＩＤ検索サーバ７すなわち検索装置、管理用の管理者端末５ａすなわち管理用装置が設けられている。

また、企業Ｂのイントラネット１０ｂにはクライアント端末装置１ｄ〜１ｆ、クライアント端末装置からのアクセスを認証する認証サーバ２ｂすなわち第２の認証装置、ユーザ情報テーブル３１ｂやアクセス監査ログテーブル３３すなわち第１のアクセスログテーブルを記録したリポジトリ３ｂ、認証サーバ２ｂにより認証されたユーザの利用が可能な業務アプリケーション４ｃ、４ｄすなわちアプリケーション部、定期的にアクセス監査を行う管理用サーバ６すなわち監視装置、管理用サーバ６へアクセスするための管理者端末５ｂが設けられている。

なお、ここではＷｅｂアプリケーションの一例として業務アプリを用いているが、業務用以外のＷｅｂアプリケーションであっても良い。また、ここではユーザ情報テーブル３１ａとＩＤ変換ログテーブル３２を同じリポジトリ３ａに記録しているが、それぞれ異なるリポジトリに記憶させても良い。

企業Ａの認証サーバ２ａは、クライアント端末装置１ａ〜１ｆからユーザを識別するユーザＩＤすなわちユーザ識別子やパスワードを受信する受信部（図示しない）、クライアント端末装置１ａ〜１ｆからのアクセスの正当性を確認する認証部２１ａ、認証されたユーザの自社の業務アプリ４ａ、４ｂへのアクセスを自装置内のアクセスポリシーに基づいて認可する認可部２２ａ、ユーザＩＤ及びアクセス日時の情報からハッシュ関数などを用いて変換ＩＤすなわち第１の変換ＩＤを生成するＩＤ変換部２３ａすなわち第１のＩＤ変換部、変換ＩＤをリポジトリ３ａに記録する変換ＩＤ記録部２４、リポジトリ３ａに記憶されたユーザ情報テーブル２ａからユーザＩＤに対応するユーザの役職情報すなわち属性情報を取得し変換ＩＤと共に認証連携用トークン（後述）に含めて認証サーバ２ｂに送信する送信部（図示しない）を備えている。認証部２１ａはリバースプロキシ機能を有し、クライアント端末装置１ａ〜１ｆから業務アプリ４ａ、４ｂへのアクセスが要求される場合には必ず経由される。
なお、変換ＩＤはユーザＩＤから一意に決まるものであって、変換ＩＤからユーザＩＤを推測したり逆変換してユーザＩＤを生成したりすることはできない。

リポジトリ３ａに保存されたユーザ情報テーブル３１ａには、ユーザＩＤ、ユーザ名、ユーザの属性情報である部、課、役職、パスワードなどがそれぞれユーザＩＤごとに対応付けて記録されている。例えば図１の例では、ユーザＩＤが「User-A1」、「User-A2」、「User-A3」の３名分のユーザ情報が記録されている。一方、ＩＤ変換ログテーブル３２には、ＩＤ変換部２３ａにより変換された変換ＩＤ、変換前のユーザＩＤ、変換日時の情報がそれぞれ対応付けて記録されている。

ＩＤ検索サーバ７は企業Ｂの管理用サーバ６又は管理者端末５ｂから不正アクセスと判断された変換ＩＤを受取り登録する検索ＩＤ登録部７１、検索ＩＤ登録部７１に登録された変換ＩＤを検索キーとしてＩＤ変換ログテーブル３２からユーザＩＤを検索するＩＤ検索部７２、検索の結果取得されたユーザＩＤを管理者端末５ａに通知する通知部７３を備えている。

企業Ｂの認証サーバ２ｂも、企業Ａの認証サーバ２ａと同様にクライアント端末装置からのユーザのアクセスを認証する認証部２１ｂ、認証されたユーザの自社の業務アプリ４ｃ、４ｄへのアクセスを認可する認可部２２ｂを備えている。また、認証サーバ２ｂは自社のユーザのユーザＩＤから変換ＩＤ（企業Ａにアクセスする際に使用する）を生成すると共に企業Ａのユーザからアクセスされた場合に認証連携用トークン（後述）に含まれる役職情報から役職ＩＤすなわち第２の変換ＩＤを生成するＩＤ変換部２３ｂすなわち第２のＩＤ変換部と、自社の業務アプリ４ｃ、４ｄにアクセスしたユーザのユーザ情報をユーザ情報テーブル３１ｂに登録されたユーザＩＤごとに記録する特定ＩＤ監査記録部２５すなわち第１の記録部を備えている。
なお、ここではＩＤ変換部２３ｂは企業Ａから企業Ｂへのアクセスは役職に応じて行うものとして認証連携用トークン（後述）に含まれる役職情報から役職ＩＤを生成しているが、ユーザの他の属性情報に応じてアクセスする場合はアクセスに使用するユーザの属性情報から属性ＩＤを生成する。

リポジトリ３ｂはユーザ情報テーブル３１ｂとアクセス監査ログテーブル３３を有し、ユーザ情報テーブル３１ｂには、ユーザＩＤ、ユーザ名、ユーザの属性である部、課、役職、パスワードがそれぞれ対応付けて記録されている。例えば図１の例では、企業ＢのユーザのユーザＩＤ「User-B1」、「User-B2」、「User-B3」のほかに企業Ａの役職ごとに設けられたユーザＩＤ「User-Bucho」、「User-Kacho」、「User-Ippan」の６名分のユーザ情報が記録されている。

アクセス監査ログテーブル３３には、特定ＩＤ監査記録部２５により記録されたクライアント端末装置１ａ〜１ｆからのアクセス日時、アクセスに使用されたユーザＩＤ、アクセスされた業務アプリのＵＲＬ、認証連携用トークン（後述）に含まれる変換ＩＤの情報が対応付けて記録されている。なお、変換ＩＤの情報が記録されるのは、企業Ａからのアクセスの場合のみであって、企業Ｂのユーザが自社の業務アプリにアクセスする場合は変換ＩＤを生成せずユーザＩＤを用いるため、変換ＩＤの欄は空欄となる。

ここでは企業Ａ、企業Ｂのクライアント端末をそれぞれ３台、業務アプリをそれぞれ２台設けているが、数はこれに限るものではなく、これより多くても少なくても良い。また、図１は企業Ａのクライアント端末装置１ａ〜１ｃから企業Ｂの業務アプリ４ｃ、４ｄにアクセスするために必要な構成を示したものであり、企業Ａに特定ＩＤ監査記録部２５、アクセス監査ログテーブル３３、及び管理用テーブルを設け、企業Ｂに変換ＩＤ記録部２４、ＩＤ検索サーバ７を設けても良い。このような構成とすることで、企業Ｂのクライアント端末１ｄ〜１ｆから企業Ａの業務アプリ４ａ、４ｂへのアクセスが可能となる。

ここで、認証システム１００の動作について説明する。
（企業Ａ内部における認証処理）
図２は、クライアント端末装置１ａが自社の認証サーバＡに初めてアクセスする場合のシーケンスを示している。企業ＡのユーザであるユーザＡ１（ユーザＩＤ：User-A1）が自社の認証サーバ２ａにアクセスすると（Ｓ１）、認証部２１ａが認証サーバ２ａ内のユーザＩＤ「User-A1」に対する認証済みクッキーの有無をチェックする（Ｓ２）。

ユーザＡ１の認証サーバ２ａへの認証がまだの場合、認証サーバ２ａはクライアント端末装置１ａに認証サーバ２ａへログインするためのログイン画面を返す（Ｓ３）。クライアント端末装置１ａはログイン画面を受取ると自装置の表示画面（図示しない）にログイン画面を表示する（Ｓ４）。ログイン画面を見たユーザＡ１によりクライアント端末装置１ａにユーザＡ１のユーザＩＤ「User-A1」とパスワードが入力されると、クライアント端末装置１ａはこのユーザＩＤ「User-A1」とパスワードを認証情報として認証サーバ２ａに送信する（Ｓ５）。認証サーバ２ａはユーザＩＤ「User-A1」とパスワードを受信すると、ユーザ情報テーブル３１ａに記録されているユーザＩＤ「User-A1」及びパスワードと比較して認証処理を行う（Ｓ６）。

受信したユーザＩＤ「User-A1」とパスワードが記録されたユーザＩＤ「User-A1」とパスワードにそれぞれ一致すると認証サーバ２ａは認証に成功したと判断し（Ｓ６）、ユーザＩＤを埋め込んだ認証済みクッキーを発行してクライアント端末装置１ａに返信する（Ｓ７）。ここで、認証済みクッキーとは、クッキー（Ｗｅｂサーバがサイトを訪問したユーザが使用するクライアント端末装置に保存させるテキスト形式の情報）の一種であって、認証サーバにより認証されたことを示すものである。

認証サーバからクライアント端末装置にクライアント端末装置１ａが認証済みクッキーを受信して認証が完了すると、クライアント端末装置１ａは表示画面に自社の業務アプリ４ａ、４ｂ及び連携している企業Ｂの業務アプリ４ｃ、４ｄを選択するためのメニュー画面を表示する（Ｓ８）。これ以後、ユーザＡ１はクライアント端末装置１ａに表示されたメニュー画面から業務アプリ４ａ〜４ｄの選択が可能となる。

（企業Ａから企業Ｂの業務アプリに始めてアクセスする場合）
図３は、自社の認証サーバ２ａに認証されたクライアント端末装置１ａが、他社である企業Ｂの業務アプリ４ｃにアクセスする場合のシーケンスを示している。
ユーザＡ１が、クライアント端末装置１ａから企業Ｂの業務アプリ４ｃのＵＲＬ（Uniform Resource Locator）へアクセスするために、認証サーバ２ｂにこのＵＲＬ情報を含むＨＴＴＰリクエストを送信する（Ｓ９）。認証サーバ２ｂはＨＴＴＰリクエストを受付け（Ｓ１０）、認証部２１ｂがこの企業Ａからのアクセスに対する認証済みクッキーの有無をチェックする（Ｓ１１）。

企業Ｂの認証サーバ２ｂ内に認証済みクッキーが無く、認証部２１ｂが企業Ａからのアクセスは未認証であると判断した場合、認証サーバ２ｂはクライアント端末装置１ａに、企業Ａの認証サーバＡに認証連携用トークンを要求するリダイレクトページを返信する（Ｓ１２）。ここで、認証連携用トークンとは、複数のＷｅｂサイトをシングルサインオンで利用するために認証サーバ２ａ、２ｂ間で用いられる、ＳＡＭＬ（Security Assertion Markup Language）プロトコルで規定された認証情報であって、クッキーの更新と同様に、複数の認証サーバをまたがった一連のアクセス毎に更新されるものである。

リダイレクトページを受信したクライアント端末装置１ａは、企業Ａの認証サーバ２ａに企業Ｂの認証サーバ２ｂに対する認証連携用トークンの発行を要求する（Ｓ１３）。認証連携用トークンを要求された認証サーバ２ａはこれを受付け（Ｓ１４）、ＩＤ変換部２３ａにて変換ＩＤ「ＷＸＹＺ」を生成し、ＩＤ変換ログテーブル３２に記録する（Ｓ１５）。その後、認証サーバ２ａはユーザＡ１の属性情報のひとつであるユーザＡ１の役職情報「部長」と変換ＩＤ「ＷＸＹＺ」を含む認証連携用トークンを発行し（Ｓ１６）、クライアント端末装置１ａに認証連携用トークンを含むリダイレクトページを返信する（Ｓ１７）。クライアント端末装置１ａに返信されたリダイレクトページは、企業Ｂの認証サーバ２ｂへ認証連携用トークンを送信するためのページである。なお、Ｓ１６にて発行された認証連携用トークンには、セキュリティ向上のために認証の有効期限情報やユーザの役職に対応する署名等の情報を含んでも良い。

クライアント端末装置１ａはリダイレクトページを受信すると、企業Ｂの認証サーバ２ｂに認証連携用トークンを送信し（Ｓ１８）、認証部２１ｂが認証連携用トークンのチェックすなわち自装置内に登録されている認証連携用トークンと比較して一致するか否かの確認を行い（Ｓ１９）、正常（受信した認証連携用トークンと認証サーバ２ｂに登録されている認証連携用トークンとが一致する）と判断した場合には認証連携用トークンに含まれるユーザＡ１の役職「部長」と変換ＩＤ「ＷＸＹＺ」の情報を取得する（Ｓ２０）。

ＩＤ変換部２３ｂは取得した役職「部長」の情報から変換役職ＩＤ「User-Bucho」を生成し、この変換役職ＩＤ「User-Bucho」をユーザＩＤとして認証サーバ２ｂにログインする（Ｓ２１）。その後、認証サーバ２ｂはユーザＩＤ（変換役職ＩＤ）「User-Bucho」と変換ＩＤ（企業Ａの認証サーバ２ａから受信した変換ＩＤ）「ＷＸＹＺ」を認証済みクッキーに記録し（Ｓ２２）、クライアント端末装置１ａから受信したＨＴＴＰリクエストを業務アプリ４ｃへ転送する（Ｓ２３）。業務アプリ４ｃはリクエスト結果としてＨＴＭＬページを認証サーバ２ｂに返信する（Ｓ２４）。

ＨＴＭＬページを受信した認証サーバ２ｂの特定ＩＤ監査記録部２５は、アクセス監査ログテーブル３３にアクセス日時「201009270900」、アクセスに使用されたユーザＩＤ（変換役職ＩＤ）「User-Bucho」、アクセスした業務アプリのＵＲＬ（業務アプリB-1のURL）、ユーザＩＤに対応する変換ＩＤの情報（企業Ａからのアクセスの場合のみ）「ＷＸＹＺ」を記録してログの更新を行い（Ｓ２５）、クライアント端末装置１ａに受信したＨＴＭＬページを転送する（Ｓ２６）。クライアント端末装置１ａは自身の表示画面に受信したＨＴＭＬページを表示する（Ｓ２７）。

（企業Ａから企業Ｂの業務アプリへ２回目以降のアクセスをする場合）
図４は、図２、図３のシーケンスをフローチャートで示したものであり、同一番号を付したステップの動作は共通する。
Ｓ２において、クライアント端末装置１ａが自社の認証サーバ２ａにより認証済みである場合はＳ８にスキップする。

Ｓ６において、自社の認証サーバ２ａによる認証処理に失敗、すなわちクライアント端末装置１ａから受信したユーザＩＤとパスワードの少なくとも一方がユーザ情報テーブル３１ａに登録されているものと一致しない場合、認証サーバ２ａは失敗回数をカウントし（Ｓ３０）、カウントした失敗回数が予め定めた所定回数以上であるか否かを判断する（Ｓ３１）。失敗回数が所定回数以上であると判断すると、クライアント端末装置１ａに認証エラー画面を返信し（Ｓ３２）、クライアント端末装置１ａは表示画面に認証エラー画面を表示する（Ｓ３３）。失敗回数が所定回数未満であれば、再度Ｓ３に戻り、クライアント端末装置１ａにログイン画面を返信し、フローを終了する（Ｓ３４）。

ここで、認証連携受入処理Ｘ（Ｓ１８〜Ｓ２９）について図５を用いて補足説明する。
Ｓ１９において、認証サーバ２ｂが受信した認証連携用トークンが自装置内に登録されている認証連携用トークンと一致しないと判断した場合、認証サーバ２ｂはクライアント端末装置１ａに認証エラー画面を返信し（Ｓ２８）、クライアント端末装置１ａは受信した認証エラー画面を表示画面に表示する（Ｓ２９）。クライアント端末装置１ａがリクエストされたＨＴＭＬページを表示（Ｓ２７）、あるいは認証エラー画面を表示すると（Ｓ２９）、認証連携受入処理Ｘを終了し全体フローも終了する（Ｓ３４）。

図４のＳ１１において、他社の認証サーバ２ｂにすでに認証されている場合は認証連携受入処理Ｙを行う。図６に示すように、認証連携受入処理Ｙは上述のＳ２３からＳ２７までの処理を順次行うものであり、Ｓ２７が完了すると認証連携処理Ｂを終了し、全体フローを終了する（Ｓ３４）。

（企業Ｂにおける不正アクセス監査）
図７は不正アクセス監査処理のフローチャートである。
アクセス監査処理が始まると（Ｓ４０）、企業Ｂの管理用サーバ６は、例えば自装置内に設けた監査用タイマ（図示しない）により監査時間の経過を計測する（Ｓ４１）。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ６はアクセス監査ログテーブル３３をチェックする（Ｓ４２）。
ここで、アクセス監査ログテーブル３３のチェックとは、具体的には、予め定めた有効期限内のアクセスであるか否か、管理用サーバ６に登録されている署名を有するものか等、一般的な認証と同様の確認処理のことを示している。

管理用サーバ６がアクセス監査ログテーブル３３のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ６に未登録の署名を含む場合（Ｓ４３）、不正アクセスと判断したユーザのアクセス日時及びユーザＩＤの情報を検索キーとしてアクセス監査ログテーブル３３から不正アクセスに使用された変換ＩＤを取得する（Ｓ４４）。

管理用サーバ６は取得した変換ＩＤを企業ＡのＩＤ検索サーバ７に通知し（Ｓ４５）、ＩＤ検索サーバ７内の検索ＩＤ登録部７１が変換ＩＤを検索ＩＤとして自装置内に登録する（Ｓ４６）。ＩＤ検索部７２は登録された検索ＩＤをキーとしてＩＤ変換ログテーブル３２を検索し（Ｓ４７）、検索ＩＤに対応するユーザＩＤを取得する（Ｓ４８）。その後、ＩＤ検索部７２は取得したユーザＩＤを検索キーとしてユーザ情報テーブル３１ａから対応するユーザ情報を取得し（Ｓ４９）、通知部７３が管理者端末５ａに通知する（Ｓ５０）。管理者端末５ａは通知された検索結果を画面に表示し（Ｓ５１）、アクセス監査処理を終了する（Ｓ５２）。

このように、企業ＡのユーザＡ１が企業ＢのＷｅｂ系アプリケーションにアクセスする場合、企業Ａの認証サーバ２ａと企業Ｂの認証サーバ２ｂ間でユーザＡ１のユーザＩＤから生成した変換ＩＤ及び属性情報を含む認証連携用トークンを用いて認証を行うため、企業ＡはユーザＡ１を特定するユーザＩＤを企業Ｂに開示せずともシングルサインオンにて企業ＢのＷｅｂ系アプリケーションにアクセスすることができる。

また、企業Ｂの管理用サーバ６が定期的あるいは不定期にアクセス監査用ログテーブルの内容を確認して不正アクセスであるか否かを判断し、不正アクセスであると判断した場合は不正アクセスに使用された変換ＩＤを不正アクセスＩＤとして検出することができる。
また、検出した不正アクセスＩＤを企業Ａに通知し、企業ＡではＩＤ検索サーバ７が通知された不正アクセスＩＤ（変換ＩＤ）に基づいてユーザＩＤを検索し不正アクセスしたユーザを特定することにより、企業Ａ内で不正アクセスを行うユーザの管理が容易になる。
また、企業Ａでは企業ＢのＷｅｂ系アプリケーションに不正アクセスしたユーザの情報を管理者端末５ａの画面に表示するため、企業Ａの管理者は画面を見ることで不正アクセスした自社のユーザ情報を容易に確認できる。

Ｓ４１にて監査用タイマが満了していない場合、あるいはＳ４３にて管理用サーバ６が不正アクセスでは無いと判断した場合はＳ４１に戻る。
また、監査用タイマの満了時だけでなく、管理者端末５ｂから管理用サーバ６へ任意のタイミングで監査指示を出せるようにし、監査指示があった場合に管理用サーバ６がＳ４２の処理をするようにしても良い。

ここまで、クライアント端末装置１ａから業務アプリ４ｃにアクセスする場合について説明したが、クライアント端末装置１ａは企業Ａの他のクライアント端末装置１ｂ、１ｃであっても良いし、業務アプリ４ｃは企業Ｂの他の業務アプリ４ｄであっても良いことは言うまでもない。

本実施の形態によれば、認証システム１００はユーザの属性情報を用いて企業Ａ、Ｂ間での認証を行うことにより、企業Ａの社員個人情報であるユーザＩＤを他社である企業Ｂに提供すること無く企業Ａから企業Ｂのイントラネット１０ｂへのシングルサインオンが可能となり、安全性を高く保つことができる。また、認証システム１００は企業Ａ、Ｂ間でやりとりする認証連携用トークンにユーザの属性情報及びユーザＩＤから生成した変換ＩＤを含めることにより、企業Ａから企業Ｂの業務アプリ４ｃ、４ｄへのアクセスを変換ＩＤごとに管理することが可能となり、企業Ｂにおいて企業Ａのユーザ個人情報を知らずとも不正アクセスしたユーザを特定できる。
また、企業Ｂは不正アクセスに使用された変換ＩＤを不正アクセスＩＤとして検出することにより機械的にユーザを特定できる。
また、不正アクセスに使用された変換ＩＤを企業Ｂから企業Ａに通知することにより、企業Ａにおいて不正アクセスしたユーザを特定することができ、不正アクセスを行うユーザの管理が容易になる。

また、企業Ａから企業Ｂの業務アプリ４ｃに不正アクセスしたユーザＡ１の情報を管理者端末５ａの画面に表示することにより、企業Ａの管理者は不正アクセスした自社のユーザ情報を容易に確認できる。
また、企業Ｂの管理用サーバ６は監査用タイマが満了するとアクセス監査ログテーブルを確認することにより、定期的にアクセス監査を実行できる。
また、企業Ｂの管理者端末５ｂから任意のタイミングで監査指示を出せるようにしたため、企業Ｂでの要求に応じたアクセス監査を実施することもできる。

実施の形態２．
本発明を実施するための実施の形態２に係る認証システムを図８ないし図１２を用いて説明する。図８に示す認証システム１００ａは、実施の形態１に係るイントラネット１０ｂに、業務アプリ４ｃ、４ｄに対する共通コンポーネントであるサービス９ａ〜９ｃすなわち共通コンポーネント部、サービス９ａ〜９ｃのインターフェースを業務アプリ４ｃ、４ｄに提供するためのＥＳＢ（Enterprise service bus）８すなわち中継装置、及びサービス９ａ〜９ｃへのアクセスを登録するアクセス監査ログテーブル３３ａすなわち第２のアクセスログテーブルを有し監査ログデータベースとして機能するリポジトリ３ｃを設けた、イントラネット１０ｃを備えたものである。
このようにＥＳＢ８を設けることにより、システムがＳＯＡ（Service Oriented Architecture）化され、共通コンポーネントの再利用が可能となる。

ＥＳＢ８内には、アクセス監査ログテーブル３３ａに各サービス９ａ〜９ｃへアクセスしたユーザ情報等を記録するサービス用ＩＤ監査記録機能部８１すなわち第２の記録部が備えられている。また、管理用サーバ６ａはリポジトリ３ｂ及びリポジトリ３ｃのアクセス監査ログテーブル３３、３３ａへのアクセスを定期的に監査できるように設けられたものである。

アクセス監査ログテーブル３３ａには、サービス用ＩＤ監査記録機能部８１により記録されたクライアント端末装置１ａ〜１ｆからのアクセス日時、アクセスに使用されたユーザＩＤ、アクセス元の業務アプリのＵＲＬ、アクセス先のサービス種別、認証連携用トークンに含まれる変換ＩＤの情報（企業Ａからのアクセスの場合のみ）が対応付けて記録されている。なお、企業Ｂのユーザが自社の業務アプリにアクセスする場合は変換ＩＤを生成せずにユーザＩＤを用いるため、変換ＩＤの欄は空欄となる。
その他の構成は実施の形態１と同じであるため、説明を省略する。

ここで、認証システム１００ａの動作について説明する。
企業Ａ内部における認証処理、及び企業Ａから企業Ｂの業務アプリに始めてアクセスする場合の大まかな処理の流れは実施の形態１と同じであり、認証連携受入処理の一部が異なる。図９に実施の形態２における認証連携受入処理Ｘのフローチャートを、図１０に実施の形態２における認証連携受入処理Ｙのフローチャートを示す。認証システム１００ａでは、図５のＳ２４の代わりにＳ２４１〜Ｓ２４６の処理を行う。Ｓ２３〜Ｓ２４６の各ステップの処理について、図１１のシーケンス図を用いて順に説明する。

認証サーバ２ｂはクライアント端末装置１ａから受信したＨＴＴＰリクエストを業務アプリ４ｃに転送すると（Ｓ２３）、業務アプリ４ｃはこのＨＴＴＰリクエストに対応するＨＴＭＬページを作成するために必要なサービスを得るため、ＥＳＢ８にサービス９ａをリクエストする（Ｓ２４０）。ＥＳＢ８は受信したリクエストをサービス９ａに転送し（Ｓ２４１）、サービス９ａはＥＳＢ８にリクエストの結果をＳＯＡＰというプロトコルを用いて返信する（Ｓ２４２）。

リクエスト結果を受信したＥＳＢ８のサービス用ＩＤ監査記録部８１は、アクセス監査ログテーブル３３ａにアクセス日時「201009270900」、アクセスに使用されたユーザＩＤ「User-Bucho」、アクセス元の業務アプリのＵＲＬ（業務アプリB-1のＵＲＬ）、アクセス先のサービス種別「サービスB-a」、ユーザＩＤ「User-Bucho」に対応する変換ＩＤ（企業Ａからのアクセスの場合のみ）「ＷＸＹＺ」を記録してログの更新を行い（Ｓ２４３）、リクエスト結果を業務アプリ４ｃに返信する（Ｓ２４４）。業務アプリ４ｃは受信したリクエスト結果を用いてＨＴＭＬページを生成し（Ｓ２４５）、認証サーバ２ｂに返信する（Ｓ２４６）。その後の動作は実施の形態１と同様である。

なお、ここでは業務アプリ４ｃがサービス９ａを使用する場合について説明したが、他のサービス９ｂ、９ｃを用いる場合や複数のサービス９ａ〜９ｃを併用する場合であっても同様に処理される。

（企業Ｂにおける不正アクセス監査）
実施の形態２における不正アクセス監査処理について、図１２のフローチャートを用いて説明する。
アクセス監査処理が始まると（Ｓ６０）、企業Ｂの管理用サーバ６ａは、例えば自装置内に設けた監査用タイマ（図示しない）により監査時間の経過を計測する（Ｓ６１）。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ６ａはアクセス監査ログテーブル３３、３３ａをチェックする（Ｓ６２）。
なお、ここではアクセス監査ログテーブル３３、３３ａの監査時間が同じである場合について説明するが、複数の監査用タイマを設けて監査時間を個別に計測できるようにしても良い。

管理用サーバ６ａがアクセス監査ログテーブル３３のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ６ａに未登録の署名を含む場合（Ｓ６４）、不正アクセスと判断したユーザのアクセス日時及びユーザＩＤの情報を検索キーとしてアクセス監査ログテーブル３３から不正アクセスに使用された変換ＩＤを取得する（Ｓ６５）。

管理用サーバ６ａがアクセス監査ログテーブル３３ａのチェックで不正アクセスと判断した場合も同様に（Ｓ６４）、不正アクセスと判断したユーザのアクセス日時及びユーザＩＤの情報を検索キーとしてアクセス監査ログテーブル３３ａから不正アクセスに使用された変換ＩＤを取得する（Ｓ６６）。

管理用サーバ６ａは取得した変換ＩＤを企業ＡのＩＤ検索サーバ７に通知し（Ｓ６７）、ＩＤ検索サーバ７内の検索ＩＤ登録部７１が変換ＩＤを検索ＩＤとして自装置内に登録する（Ｓ６８）。ＩＤ検索部７２は登録された検索ＩＤをキーとしてＩＤ変換ログテーブル３２を検索し（Ｓ６９）、検索ＩＤに対応するユーザＩＤを取得する（Ｓ７０）。その後、ＩＤ検索部７２は取得したユーザＩＤを検索キーとしてユーザ情報テーブル３１ａから対応するユーザ情報を取得し（Ｓ７１）、通知部７３が管理者端末５ａに通知する（Ｓ７２）。管理者端末５ａは通知された検索結果を画面に表示し（Ｓ７３）、アクセス監査処理を終了する（Ｓ７４）。

本実施の形態によれば、ＥＳＢ８にサービス用ＩＤ監査記録部８１を設けて共通コンポーネントであるサービス９ａ〜９ｃへのアクセスをアクセス監査ログテーブル３３ａに記録し、管理用サーバ６ａから不正アクセス監査処理ができるようにしたため、実施の形態１の効果に加えて、共通コンポーネント単位の不正アクセス監査も可能となる。このような形態では、サービスへの不正アクセスが検出された場合であっても、業務アプリへの不正アクセスが検出されない場合には、不正アクセスが検出されたサービスへのアクセス権限のみを制限するといったアクセスポイントに応じた柔軟な設定が可能となる。

上記実施の形態１、２の説明において「〜部」と説明したものは、「〜手段」、「〜回路」、「〜機器」であっても良い。すなわち、ソフトウェア、ファームウェア、素子・デバイス・基板・配線などのハードウェア、あるいはこれらの組合せによって実施するものであっても良い。ソフトウェアやファームウェアの場合、プログラムとしてＲＯＭやＤＶＤ等の記録媒体に記録され、認証サーバ２ａ、２ｂ内あるいはＩＤ検索サーバ７内のＣＰＵ（図示しない）がこれらのプログラムを読み出し実行することで、「〜部」として機能するものである。

１ａ〜１ｆ クライアント端末装置
２ａ、２ｂ 認証サーバ
２１ａ、２１ｂ 認証部
２２ａ、２２ｂ 認可部
２３ａ、２３ｂ ＩＤ変換部
２４ 変換ＩＤ記録部
２５ 特定ＩＤ監査記録部
３ａ〜３ｃ リポジトリ
３１ａ、３１ｂ ユーザ情報テーブル
３２ ＩＤ変換ログテーブル
３３、３３ａ アクセス監査ログテーブル
４ａ〜４ｄ 業務アプリ
５ａ、５ｂ 管理者端末
６、６ａ 管理用サーバ
７ ＩＤ検索サーバ
７１ 検索ＩＤ登録部
７２ ＩＤ検索部
７３ 通知部
８ ＥＳＢ（Enterprise service bus）
８１ サービス用ＩＤ監査記録部
９ａ〜９ｃ サービス
１０ａ〜１０ｃ イントラネット
１１ ネットワーク

Claims (7)

1. ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
   前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第１の記憶部、
   前記クライアント端末装置からのアクセスを認証する第１の認証装置、
   前記第１の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第２の認証装置、および
   前記クライアント端末装置から前記第２の認証装置を介してアクセスされるアプリケーション部、
   を備えた認証システムにおいて、
   前記第１の認証装置は、
   前記クライアント端末装置から前記ユーザ識別子を受信する受信部、
   前記受信部により受信された前記ユーザ識別子を用いて第１の変換ＩＤを生成する第１のＩＤ変換部、および
   前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得し、該属性情報及び前記第１のＩＤ変換部により生成された前記第１の変換ＩＤを含む認証連携用トークンを前記第２の認証装置に送信する送信部、を有し、
   前記第２の認証装置は、
   前記第１の認証装置から受信した認証連携用トークンが自装置内に登録されている認証連携用トークンと一致するか否かの確認を行うことにより前記クライアント端末装置からのアクセスを認証する認証部と、
   前記第１の認証装置から受信した認証連携用トークンが前記登録されている認証連携用トークンと一致している場合に当該認証連携用トークンから取得される前記属性情報を用いて前記第２の認証装置にアクセスするための第２の変換ＩＤを生成する第２のＩＤ変換部と、
   前記認証部により認証された前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第１の変換ＩＤと共に第１のアクセスログテーブルに記録する第１の記録部と、を有することを特徴とする認証システム。
2. 前記アプリケーション部を複数有する場合に該複数のアプリケーション部に使用される共通コンポーネント部と、
   前記アプリケーション部と前記共通コンポーネント部との間に設けられ、前記アプリケーション部から前記共通コンポーネント部への要求、及び前記共通コンポーネント部から前記アプリケーション部への前記要求に対する結果を中継する中継装置と、
   前記アプリケーション部から前記共通コンポーネント部へのアクセス情報を前記第１の変換ＩＤと共に第２のアクセスログテーブルに記録する第２の記録部と、を備えたことを特徴とする請求項１に記載の認証システム。
3. 前記第１のアクセスログテーブルに所定のアクセス情報以外の情報が記録された場合に不正アクセスと判断し、該不正アクセスに使用された前記第１の変換ＩＤを不正アクセスＩＤとして検出する監視装置を備えたことを特徴とする請求項１又は請求項２に記載の認証システム。
4. 前記ユーザ情報テーブルは前記ユーザ識別子に対応するユーザ名を保持し、
   前記認証システムは、
   前記ユーザ識別子及び前記第１の変換ＩＤを記録したＩＤ変換ログテーブルを有する第２の記憶部と、
   前記監視装置により不正アクセスＩＤとして検出された前記第１の変換ＩＤに対応するユーザ識別子を前記ＩＤ変換ログテーブルから検索し、前記検索の結果得られたユーザ識別子に対応する前記ユーザ名を前記ユーザ情報テーブルから取得する検索装置と、
   を備えたことを特徴とする請求項３に記載の認証システム。
5. 前記第１の認証装置は、前記属性情報と前記第１の変換ＩＤと認証の有効期限情報とを有する認証連携用トークンを前記第２の認証装置に送信し、
   前記第２の認証装置は、前記第１のアクセスログテーブルにアクセス情報として前記有効期限情報を記録し、
   前記監視装置は、前記第１のアクセスログテーブルに記録された前記有効期限情報が所定の有効期限を超過している場合に不正アクセスと判断することを特徴とする請求項３に記載の認証システム。
6. 前記第１の認証装置は、前記属性情報と前記第１の変換ＩＤと前記属性情報に対応する署名とを有する認証連携用トークンを前記第２の認証装置に送信し、
   前記第２の認証装置は、前記第１のアクセスログテーブルにアクセス情報として前記署名を記録し、
   前記監視装置は、前記第１のアクセスログテーブルに記録された前記署名が自装置内に登録されていない場合に不正アクセスと判断することを特徴とする請求項３に記載の認証システム。
7. ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
   前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第１の記憶部、
   前記クライアント端末装置からのアクセスを認証する第１の認証装置、
   前記第１の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第２の認証装置、および
   前記クライアント端末装置から前記第２の認証装置を介してアクセスされるアプリケーション部、
   を有する認証システムで実行される認証方法において、
   前記第１の認証装置が前記クライアント端末装置から前記ユーザ識別子を受信する第１ステップ、
   前記第１の認証装置が前記第１ステップにより受信した前記ユーザ識別子を用いて第１の変換ＩＤを生成する第２ステップ、
   前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記第１の認証装置が、前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得し、該属性情報及び前記第１の変換ＩＤを含む認証連携用トークンを前記第２の認証装置に送信する第３ステップ、
   前記第１の認証装置が、前記第３ステップにより取得した前記属性情報及び前記第２ステップにより生成した前記第１の変換ＩＤを前記第２の認証装置に送信する第４ステップ、
   前記第２の認証装置が、前記第１の認証装置から前記属性情報及び前記認証連携用トークンを受信する第５ステップ、
   前記第２の認証装置が、前記第５ステップにより受信した前記認証連携用トークンが自装置内に登録されている認証連携用トークンと一致するか否かの確認を行うことにより前記クライアント端末装置からのアクセスを認証する第６ステップ、
   前記認証連携用トークンが前記登録されている認証連携用トークンと一致している場合に、前記第２の認証装置が、当該認証連携用トークンから取得される前記属性情報を用いて前記第２の認証装置にアクセスするための第２の変換ＩＤを生成する第７ステップ、および
   前記第２の認証装置が、前記第６ステップにより認証した前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第１の変換ＩＤと共に第１のアクセスログテーブルに記録する第８ステップ、を備えたことを特徴とする認証方法。

Images