認証システム及び認証方法
【課題】複数の認証サーバ間で個人情報を開示すること無くシングルサインオンができ、かつ、不正アクセスがなされた場合に不正アクセスしたユーザの特定が可能な認証システムを得る。
【解決手段】認証システム100は、ユーザがクライアント端末装置1aから業務アプリ4cへのアクセスを要求すると、認証サーバ2aはユーザIDから生成した変換IDとユーザの役職情報を認証サーバ2bに送信し、認証サーバ2bは役職情報に基いてユーザ認証を行った後このユーザの業務アプリ4cへのアクセス情報を変換IDと共にアクセス監査ログテーブル33に記録する。
【解決手段】認証システム100は、ユーザがクライアント端末装置1aから業務アプリ4cへのアクセスを要求すると、認証サーバ2aはユーザIDから生成した変換IDとユーザの役職情報を認証サーバ2bに送信し、認証サーバ2bは役職情報に基いてユーザ認証を行った後このユーザの業務アプリ4cへのアクセス情報を変換IDと共にアクセス監査ログテーブル33に記録する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザが企業をまたがってWeb系アプリケーションを利用できる認証システムに関するものである。
【背景技術】
【0002】
複数の企業間で用いられるWeb系クライアント/サーバ型のシステムにおいて、自社の社員の個人情報を他社に提供すること無く、複数の認証システム間でシングルサインオン(1度の認証情報の入力により複数システムが利用可能とする方法)を行う認証システムとして、従来、クライアント端末と認証処理を行う複数の認証サーバとクライアント端末からの要求に基づいて適切な認証サーバを選択するセンタサーバとを備え、センタサーバにより選択された認証サーバから認証されたユーザは、選択された認証サーバおよび他の認証サーバへのアクセスが可能となる認証システムがある(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2010−205166号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載の認証システムにおいては、選択された認証サーバ以外の認証サーバはクライアント端末からのアクセスに対してユーザ認証を行わないため、不正アクセスがなされた場合であってもユーザを特定できないという問題があった。
【0005】
本発明はこのような問題を解決するためになされたもので、複数の認証サーバ間で個人情報を開示すること無くシングルサインオンができ、かつ、不正アクセスがなされた場合に不正アクセスしたユーザの特定が可能な認証システムを得ることを目的とする。
【課題を解決するための手段】
【0006】
本発明に係る認証システムは、ユーザ識別子を有するユーザにより使用されるクライアント端末装置、ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、クライアント端末装置からのアクセスを認証する第1の認証装置、第1の認証装置により認証されたクライアント端末装置からのアクセスを認証する第2の認証装置、クライアント端末装置から第2の認証装置を介してアクセスされるアプリケーション部、を備えた認証システムであって、第1の認証装置は、クライアント端末装置からユーザ識別子を受信する受信部、受信部により受信されたユーザ識別子を用いて第1の変換IDを生成する第1のID変換部、クライアント端末装置からアプリケーション部へのアクセスが要求された場合にユーザ情報テーブルからユーザ識別子に対応する属性情報を取得し、属性情報及び第1のID変換部により生成された第1の変換IDを第2の認証装置に送信する送信部、を有し、第2の認証装置は、第1の認証装置から受信した属性情報を用いて第2の変換IDを生成する第2のID変換部、第2のID変換部により生成された第2の変換IDを用いてクライアント端末装置からのアクセスを認証する認証部、認証部により認証されたクライアント端末装置のアプリケーション部へのアクセス情報を第1の変換IDと共に第1のアクセスログテーブルに記録する第1の記録部と、を有することを特徴とするものである。
【発明の効果】
【0007】
本発明によれば、認証システムは上記構成を備え、第1の認証装置がユーザ識別子から生成した変換IDとユーザの属性情報を第2の認証装置に送信し、第2の認証装置は受信した属性情報を用いてユーザの認証を行い、このユーザによるアプリケーション部へのアクセス情報を第1の認証装置から受信した変換IDと共にアクセスログテーブルに記録することにより、第1の認証装置と第2の認証装置間で個人情報であるユーザ識別子を開示すること無くシングルサインオンでき、かつ、不正アクセスがなされた場合には第2の認証装置において変換IDにより不正アクセスしたユーザを特定できる。
【図面の簡単な説明】
【0008】
【図1】実施の形態1に係る認証システムの構成を示す図である。
【図2】実施の形態1におけるクライアント端末及び認証サーバ間の認証シーケンスを示す図である。
【図3】実施の形態1における複数企業間の認証シーケンスを示す図である。
【図4】実施の形態1における認証処理を示すフローチャートである。
【図5】図4の認証連携受入処理Xを示すフローチャートである。
【図6】図4の認証連携受入処理Yを示すフローチャートである。
【図7】実施の形態1におけるアクセス監査処理を示すフローチャートである。
【図8】実施の形態2に係る認証システムの構成を示す図である。
【図9】実施の形態2における認証連携受入処理Xを示すフローチャートである。
【図10】実施の形態2における認証連携受入処理Yを示すフローチャートである。
【図11】実施の形態2における複数企業間の認証シーケンスを示す図である。
【図12】実施の形態2におけるアクセス監査処理を示すフローチャートである。
【発明を実施するための形態】
【0009】
実施の形態1.
本発明を実施するための実施の形態1に係る認証システムを図1ないし図7を用いて説明する。図1において、認証システム100は企業Aのイントラネット10a、企業Bのイントラネット10b、2つのイントラネット10a、10bを接続するネットワーク11を備え、企業Aのイントラネット10aにはユーザにより利用されるクライアント端末装置1a〜1c、クライアント端末装置からのアクセスを認証する認証サーバ2aすなわち第1の認証装置、ユーザ情報テーブル31aやID変換ログテーブル32を記録したリポジトリ3aすなわち第1の記憶部及び第2の記憶部、認証サーバ2aにより認証されたユーザによる利用が可能な業務アプリケーション部4a、4b(以降、業務アプリ4a、4bと称する)、ユーザIDを検索するID検索サーバ7すなわち検索装置、管理用の管理者端末5aすなわち管理用装置が設けられている。
【0010】
また、企業Bのイントラネット10bにはクライアント端末装置1d〜1f、クライアント端末装置からのアクセスを認証する認証サーバ2bすなわち第2の認証装置、ユーザ情報テーブル31bやアクセス監査ログテーブル33すなわち第1のアクセスログテーブルを記録したリポジトリ3b、認証サーバ2bにより認証されたユーザの利用が可能な業務アプリケーション4c、4dすなわちアプリケーション部、定期的にアクセス監査を行う管理用サーバ6すなわち監視装置、管理用サーバ6へアクセスするための管理者端末5bが設けられている。
【0011】
なお、ここではWebアプリケーションの一例として業務アプリを用いているが、業務用以外のWebアプリケーションであっても良い。また、ここではユーザ情報テーブル31aとID変換ログテーブル32を同じリポジトリ3aに記録しているが、それぞれ異なるリポジトリに記憶させても良い。
【0012】
企業Aの認証サーバ2aは、クライアント端末装置1a〜1fからユーザを識別するユーザIDすなわちユーザ識別子やパスワードを受信する受信部(図示しない)、クライアント端末装置1a〜1fからのアクセスの正当性を確認する認証部21a、認証されたユーザの自社の業務アプリ4a、4bへのアクセスを自装置内のアクセスポリシーに基づいて認可する認可部22a、ユーザID及びアクセス日時の情報からハッシュ関数などを用いて変換IDすなわち第1の変換IDを生成するID変換部23aすなわち第1のID変換部、変換IDをリポジトリ3aに記録する変換ID記録部24、リポジトリ3aに記憶されたユーザ情報テーブル2aからユーザIDに対応するユーザの役職情報すなわち属性情報を取得し変換IDと共に認証連携用トークン(後述)に含めて認証サーバ2bに送信する送信部(図示しない)を備えている。認証部21aはリバースプロキシ機能を有し、クライアント端末装置1a〜1fから業務アプリ4a、4bへのアクセスが要求される場合には必ず経由される。
なお、変換IDはユーザIDから一意に決まるものであって、変換IDからユーザIDを推測したり逆変換してユーザIDを生成したりすることはできない。
【0013】
リポジトリ3aに保存されたユーザ情報テーブル31aには、ユーザID、ユーザ名、ユーザの属性情報である部、課、役職、パスワードなどがそれぞれユーザIDごとに対応付けて記録されている。例えば図1の例では、ユーザIDが「User-A1」、「User-A2」、「User-A3」の3名分のユーザ情報が記録されている。一方、ID変換ログテーブル32には、ID変換部23aにより変換された変換ID、変換前のユーザID、変換日時の情報がそれぞれ対応付けて記録されている。
【0014】
ID検索サーバ7は企業Bの管理用サーバ6又は管理者端末5bから不正アクセスと判断された変換IDを受取り登録する検索ID登録部71、検索ID登録部71に登録された変換IDを検索キーとしてID変換ログテーブル32からユーザIDを検索するID検索部72、検索の結果取得されたユーザIDを管理者端末5aに通知する通知部73を備えている。
【0015】
企業Bの認証サーバ2bも、企業Aの認証サーバ2aと同様にクライアント端末装置からのユーザのアクセスを認証する認証部21b、認証されたユーザの自社の業務アプリ4c、4dへのアクセスを認可する認可部22bを備えている。また、認証サーバ2bは自社のユーザのユーザIDから変換ID(企業Aにアクセスする際に使用する)を生成すると共に企業Aのユーザからアクセスされた場合に認証連携用トークン(後述)に含まれる役職情報から役職IDすなわち第2の変換IDを生成するID変換部23bすなわち第2のID変換部と、自社の業務アプリ4c、4dにアクセスしたユーザのユーザ情報をユーザ情報テーブル31bに登録されたユーザIDごとに記録する特定ID監査記録部25すなわち第1の記録部を備えている。
なお、ここではID変換部23bは企業Aから企業Bへのアクセスは役職に応じて行うものとして認証連携用トークン(後述)に含まれる役職情報から役職IDを生成しているが、ユーザの他の属性情報に応じてアクセスする場合はアクセスに使用するユーザの属性情報から属性IDを生成する。
【0016】
リポジトリ3bはユーザ情報テーブル31bとアクセス監査ログテーブル33を有し、ユーザ情報テーブル31bには、ユーザID、ユーザ名、ユーザの属性である部、課、役職、パスワードがそれぞれ対応付けて記録されている。例えば図1の例では、企業BのユーザのユーザID「User-B1」、「User-B2」、「User-B3」のほかに企業Aの役職ごとに設けられたユーザID「User-Bucho」、「User-Kacho」、「User-Ippan」の6名分のユーザ情報が記録されている。
【0017】
アクセス監査ログテーブル33には、特定ID監査記録部25により記録されたクライアント端末装置1a〜1fからのアクセス日時、アクセスに使用されたユーザID、アクセスされた業務アプリのURL、認証連携用トークン(後述)に含まれる変換IDの情報が対応付けて記録されている。なお、変換IDの情報が記録されるのは、企業Aからのアクセスの場合のみであって、企業Bのユーザが自社の業務アプリにアクセスする場合は変換IDを生成せずユーザIDを用いるため、変換IDの欄は空欄となる。
【0018】
ここでは企業A、企業Bのクライアント端末をそれぞれ3台、業務アプリをそれぞれ2台設けているが、数はこれに限るものではなく、これより多くても少なくても良い。また、図1は企業Aのクライアント端末装置1a〜1cから企業Bの業務アプリ4c、4dにアクセスするために必要な構成を示したものであり、企業Aに特定ID監査記録部25、アクセス監査ログテーブル33、及び管理用テーブルを設け、企業Bに変換ID記録部24、ID検索サーバ7を設けても良い。このような構成とすることで、企業Bのクライアント端末1d〜1fから企業Aの業務アプリ4a、4bへのアクセスが可能となる。
【0019】
ここで、認証システム100の動作について説明する。
(企業A内部における認証処理)
図2は、クライアント端末装置1aが自社の認証サーバAに初めてアクセスする場合のシーケンスを示している。企業AのユーザであるユーザA1(ユーザID:User-A1)が自社の認証サーバ2aにアクセスすると(S1)、認証部21aが認証サーバ2a内のユーザID「User-A1」に対する認証済みクッキーの有無をチェックする(S2)。
【0020】
ユーザA1の認証サーバ2aへの認証がまだの場合、認証サーバ2aはクライアント端末装置1aに認証サーバ2aへログインするためのログイン画面を返す(S3)。クライアント端末装置1aはログイン画面を受取ると自装置の表示画面(図示しない)にログイン画面を表示する(S4)。ログイン画面を見たユーザA1によりクライアント端末装置1aにユーザA1のユーザID「User-A1」とパスワードが入力されると、クライアント端末装置1aはこのユーザID「User-A1」とパスワードを認証情報として認証サーバ2aに送信する(S5)。認証サーバ2aはユーザID「User-A1」とパスワードを受信すると、ユーザ情報テーブル31aに記録されているユーザID「User-A1」及びパスワードと比較して認証処理を行う(S6)。
【0021】
受信したユーザID「User-A1」とパスワードが記録されたユーザID「User-A1」とパスワードにそれぞれ一致すると認証サーバ2aは認証に成功したと判断し(S6)、ユーザIDを埋め込んだ認証済みクッキーを発行してクライアント端末装置1aに返信する(S7)。ここで、認証済みクッキーとは、クッキー(Webサーバがサイトを訪問したユーザが使用するクライアント端末装置に保存させるテキスト形式の情報)の一種であって、認証サーバにより認証されたことを示すものである。
【0022】
認証サーバからクライアント端末装置にクライアント端末装置1aが認証済みクッキーを受信して認証が完了すると、クライアント端末装置1aは表示画面に自社の業務アプリ4a、4b及び連携している企業Bの業務アプリ4c、4dを選択するためのメニュー画面を表示する(S8)。これ以後、ユーザA1はクライアント端末装置1aに表示されたメニュー画面から業務アプリ4a〜4dの選択が可能となる。
【0023】
(企業Aから企業Bの業務アプリに始めてアクセスする場合)
図3は、自社の認証サーバ2aに認証されたクライアント端末装置1aが、他社である企業Bの業務アプリ4cにアクセスする場合のシーケンスを示している。
ユーザA1が、クライアント端末装置1aから企業Bの業務アプリ4cのURL(Uniform Resource Locator)へアクセスするために、認証サーバ2bにこのURL情報を含むHTTPリクエストを送信する(S9)。認証サーバ2bはHTTPリクエストを受付け(S10)、認証部21bがこの企業Aからのアクセスに対する認証済みクッキーの有無をチェックする(S11)。
【0024】
企業Bの認証サーバ2b内に認証済みクッキーが無く、認証部21bが企業Aからのアクセスは未認証であると判断した場合、認証サーバ2bはクライアント端末装置1aに、企業Aの認証サーバAに認証連携用トークンを要求するリダイレクトページを返信する(S12)。ここで、認証連携用トークンとは、複数のWebサイトをシングルサインオンで利用するために認証サーバ2a、2b間で用いられる、SAML(Security Assertion Markup Language)プロトコルで規定された認証情報であって、クッキーの更新と同様に、複数の認証サーバをまたがった一連のアクセス毎に更新されるものである。
【0025】
リダイレクトページを受信したクライアント端末装置1aは、企業Aの認証サーバ2aに企業Bの認証サーバ2bに対する認証連携用トークンの発行を要求する(S13)。認証連携用トークンを要求された認証サーバ2aはこれを受付け(S14)、ID変換部23aにて変換ID「WXYZ」を生成し、ID変換ログテーブル32に記録する(S15)。その後、認証サーバ2aはユーザA1の属性情報のひとつであるユーザA1の役職情報「部長」と変換ID「WXYZ」を含む認証連携用トークンを発行し(S16)、クライアント端末装置1aに認証連携用トークンを含むリダイレクトページを返信する(S17)。クライアント端末装置1aに返信されたリダイレクトページは、企業Bの認証サーバ2bへ認証連携用トークンを送信するためのページである。なお、S16にて発行された認証連携用トークンには、セキュリティ向上のために認証の有効期限情報やユーザの役職に対応する署名等の情報を含んでも良い。
【0026】
クライアント端末装置1aはリダイレクトページを受信すると、企業Bの認証サーバ2bに認証連携用トークンを送信し(S18)、認証部21bが認証連携用トークンのチェックすなわち自装置内に登録されている認証連携用トークンと比較して一致するか否かの確認を行い(S19)、正常(受信した認証連携用トークンと認証サーバ2bに登録されている認証連携用トークンとが一致する)と判断した場合には認証連携用トークンに含まれるユーザA1の役職「部長」と変換ID「WXYZ」の情報を取得する(S20)。
【0027】
ID変換部23bは取得した役職「部長」の情報から変換役職ID「User-Bucho」を生成し、この変換役職ID「User-Bucho」をユーザIDとして認証サーバ2bにログインする(S21)。その後、認証サーバ2bはユーザID(変換役職ID)「User-Bucho」と変換ID(企業Aの認証サーバ2aから受信した変換ID)「WXYZ」を認証済みクッキーに記録し(S22)、クライアント端末装置1aから受信したHTTPリクエストを業務アプリ4cへ転送する(S23)。業務アプリ4cはリクエスト結果としてHTMLページを認証サーバ2bに返信する(S24)。
【0028】
HTMLページを受信した認証サーバ2bの特定ID監査記録部25は、アクセス監査ログテーブル33にアクセス日時「201009270900」、アクセスに使用されたユーザID(変換役職ID)「User-Bucho」、アクセスした業務アプリのURL(業務アプリB-1のURL)、ユーザIDに対応する変換IDの情報(企業Aからのアクセスの場合のみ)「WXYZ」を記録してログの更新を行い(S25)、クライアント端末装置1aに受信したHTMLページを転送する(S26)。クライアント端末装置1aは自身の表示画面に受信したHTMLページを表示する(S27)。
【0029】
(企業Aから企業Bの業務アプリへ2回目以降のアクセスをする場合)
図4は、図2、図3のシーケンスをフローチャートで示したものであり、同一番号を付したステップの動作は共通する。
S2において、クライアント端末装置1aが自社の認証サーバ2aにより認証済みである場合はS8にスキップする。
【0030】
S6において、自社の認証サーバ2aによる認証処理に失敗、すなわちクライアント端末装置1aから受信したユーザIDとパスワードの少なくとも一方がユーザ情報テーブル31aに登録されているものと一致しない場合、認証サーバ2aは失敗回数をカウントし(S30)、カウントした失敗回数が予め定めた所定回数以上であるか否かを判断する(S31)。失敗回数が所定回数以上であると判断すると、クライアント端末装置1aに認証エラー画面を返信し(S32)、クライアント端末装置1aは表示画面に認証エラー画面を表示する(S33)。失敗回数が所定回数未満であれば、再度S3に戻り、クライアント端末装置1aにログイン画面を返信し、フローを終了する(S34)。
【0031】
ここで、認証連携受入処理X(S18〜S29)について図5を用いて補足説明する。
S19において、認証サーバ2bが受信した認証連携用トークンが自装置内に登録されている認証連携用トークンと一致しないと判断した場合、認証サーバ2bはクライアント端末装置1aに認証エラー画面を返信し(S28)、クライアント端末装置1aは受信した認証エラー画面を表示画面に表示する(S29)。クライアント端末装置1aがリクエストされたHTMLページを表示(S27)、あるいは認証エラー画面を表示すると(S29)、認証連携受入処理Xを終了し全体フローも終了する(S34)。
【0032】
図4のS11において、他社の認証サーバ2bにすでに認証されている場合は認証連携受入処理Yを行う。図6に示すように、認証連携受入処理Yは上述のS23からS27までの処理を順次行うものであり、S27が完了すると認証連携処理Bを終了し、全体フローを終了する(S34)。
【0033】
(企業Bにおける不正アクセス監査)
図7は不正アクセス監査処理のフローチャートである。
アクセス監査処理が始まると(S40)、企業Bの管理用サーバ6は、例えば自装置内に設けた監査用タイマ(図示しない)により監査時間の経過を計測する(S41)。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ6はアクセス監査ログテーブル33をチェックする(S42)。
ここで、アクセス監査ログテーブル33のチェックとは、具体的には、予め定めた有効期限内のアクセスであるか否か、管理用サーバ6に登録されている署名を有するものか等、一般的な認証と同様の確認処理のことを示している。
【0034】
管理用サーバ6がアクセス監査ログテーブル33のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ6に未登録の署名を含む場合(S43)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33から不正アクセスに使用された変換IDを取得する(S44)。
【0035】
管理用サーバ6は取得した変換IDを企業AのID検索サーバ7に通知し(S45)、ID検索サーバ7内の検索ID登録部71が変換IDを検索IDとして自装置内に登録する(S46)。ID検索部72は登録された検索IDをキーとしてID変換ログテーブル32を検索し(S47)、検索IDに対応するユーザIDを取得する(S48)。その後、ID検索部72は取得したユーザIDを検索キーとしてユーザ情報テーブル31aから対応するユーザ情報を取得し(S49)、通知部73が管理者端末5aに通知する(S50)。管理者端末5aは通知された検索結果を画面に表示し(S51)、アクセス監査処理を終了する(S52)。
【0036】
このように、企業AのユーザA1が企業BのWeb系アプリケーションにアクセスする場合、企業Aの認証サーバ2aと企業Bの認証サーバ2b間でユーザA1のユーザIDから生成した変換ID及び属性情報を含む認証連携用トークンを用いて認証を行うため、企業AはユーザA1を特定するユーザIDを企業Bに開示せずともシングルサインオンにて企業BのWeb系アプリケーションにアクセスすることができる。
【0037】
また、企業Bの管理用サーバ6が定期的あるいは不定期にアクセス監査用ログテーブルの内容を確認して不正アクセスであるか否かを判断し、不正アクセスであると判断した場合は不正アクセスに使用された変換IDを不正アクセスIDとして検出することができる。
また、検出した不正アクセスIDを企業Aに通知し、企業AではID検索サーバ7が通知された不正アクセスID(変換ID)に基づいてユーザIDを検索し不正アクセスしたユーザを特定することにより、企業A内で不正アクセスを行うユーザの管理が容易になる。
また、企業Aでは企業BのWeb系アプリケーションに不正アクセスしたユーザの情報を管理者端末5aの画面に表示するため、企業Aの管理者は画面を見ることで不正アクセスした自社のユーザ情報を容易に確認できる。
【0038】
S41にて監査用タイマが満了していない場合、あるいはS43にて管理用サーバ6が不正アクセスでは無いと判断した場合はS41に戻る。
また、監査用タイマの満了時だけでなく、管理者端末5bから管理用サーバ6へ任意のタイミングで監査指示を出せるようにし、監査指示があった場合に管理用サーバ6がS42の処理をするようにしても良い。
【0039】
ここまで、クライアント端末装置1aから業務アプリ4cにアクセスする場合について説明したが、クライアント端末装置1aは企業Aの他のクライアント端末装置1b、1cであっても良いし、業務アプリ4cは企業Bの他の業務アプリ4dであっても良いことは言うまでもない。
【0040】
本実施の形態によれば、認証システム100はユーザの属性情報を用いて企業A、B間での認証を行うことにより、企業Aの社員個人情報であるユーザIDを他社である企業Bに提供すること無く企業Aから企業Bのイントラネット10bへのシングルサインオンが可能となり、安全性を高く保つことができる。また、認証システム100は企業A、B間でやりとりする認証連携用トークンにユーザの属性情報及びユーザIDから生成した変換IDを含めることにより、企業Aから企業Bの業務アプリ4c、4dへのアクセスを変換IDごとに管理することが可能となり、企業Bにおいて企業Aのユーザ個人情報を知らずとも不正アクセスしたユーザを特定できる。
また、企業Bは不正アクセスに使用された変換IDを不正アクセスIDとして検出することにより機械的にユーザを特定できる。
また、不正アクセスに使用された変換IDを企業Bから企業Aに通知することにより、企業Aにおいて不正アクセスしたユーザを特定することができ、不正アクセスを行うユーザの管理が容易になる。
【0041】
また、企業Aから企業Bの業務アプリ4cに不正アクセスしたユーザA1の情報を管理者端末5aの画面に表示することにより、企業Aの管理者は不正アクセスした自社のユーザ情報を容易に確認できる。
また、企業Bの管理用サーバ6は監査用タイマが満了するとアクセス監査ログテーブルを確認することにより、定期的にアクセス監査を実行できる。
また、企業Bの管理者端末5bから任意のタイミングで監査指示を出せるようにしたため、企業Bでの要求に応じたアクセス監査を実施することもできる。
【0042】
実施の形態2.
本発明を実施するための実施の形態2に係る認証システムを図8ないし図12を用いて説明する。図8に示す認証システム100aは、実施の形態1に係るイントラネット10bに、業務アプリ4c、4dに対する共通コンポーネントであるサービス9a〜9cすなわち共通コンポーネント部、サービス9a〜9cのインターフェースを業務アプリ4c、4dに提供するためのESB(Enterprise service bus)8すなわち中継装置、及びサービス9a〜9cへのアクセスを登録するアクセス監査ログテーブル33aすなわち第2のアクセスログテーブルを有し監査ログデータベースとして機能するリポジトリ3cを設けた、イントラネット10cを備えたものである。
このようにESB8を設けることにより、システムがSOA(Service Oriented Architecture)化され、共通コンポーネントの再利用が可能となる。
【0043】
ESB8内には、アクセス監査ログテーブル33aに各サービス9a〜9cへアクセスしたユーザ情報等を記録するサービス用ID監査記録機能部81すなわち第2の記録部が備えられている。また、管理用サーバ6aはリポジトリ3b及びリポジトリ3cのアクセス監査ログテーブル33、33aへのアクセスを定期的に監査できるように設けられたものである。
【0044】
アクセス監査ログテーブル33aには、サービス用ID監査記録機能部81により記録されたクライアント端末装置1a〜1fからのアクセス日時、アクセスに使用されたユーザID、アクセス元の業務アプリのURL、アクセス先のサービス種別、認証連携用トークンに含まれる変換IDの情報(企業Aからのアクセスの場合のみ)が対応付けて記録されている。なお、企業Bのユーザが自社の業務アプリにアクセスする場合は変換IDを生成せずにユーザIDを用いるため、変換IDの欄は空欄となる。
その他の構成は実施の形態1と同じであるため、説明を省略する。
【0045】
ここで、認証システム100aの動作について説明する。
企業A内部における認証処理、及び企業Aから企業Bの業務アプリに始めてアクセスする場合の大まかな処理の流れは実施の形態1と同じであり、認証連携受入処理の一部が異なる。図9に実施の形態2における認証連携受入処理Xのフローチャートを、図10に実施の形態2における認証連携受入処理Yのフローチャートを示す。認証システム100aでは、図5のS24の代わりにS241〜S246の処理を行う。S23〜S246の各ステップの処理について、図11のシーケンス図を用いて順に説明する。
【0046】
認証サーバ2bはクライアント端末装置1aから受信したHTTPリクエストを業務アプリ4cに転送すると(S23)、業務アプリ4cはこのHTTPリクエストに対応するHTMLページを作成するために必要なサービスを得るため、ESB8にサービス9aをリクエストする(S240)。ESB8は受信したリクエストをサービス9aに転送し(S241)、サービス9aはESB8にリクエストの結果をSOAPというプロトコルを用いて返信する(S242)。
【0047】
リクエスト結果を受信したESB8のサービス用ID監査記録部81は、アクセス監査ログテーブル33aにアクセス日時「201009270900」、アクセスに使用されたユーザID「User-Bucho」、アクセス元の業務アプリのURL(業務アプリB-1のURL)、アクセス先のサービス種別「サービスB-a」、ユーザID「User-Bucho」に対応する変換ID(企業Aからのアクセスの場合のみ)「WXYZ」を記録してログの更新を行い(S243)、リクエスト結果を業務アプリ4cに返信する(S244)。業務アプリ4cは受信したリクエスト結果を用いてHTMLページを生成し(S245)、認証サーバ2bに返信する(S246)。その後の動作は実施の形態1と同様である。
【0048】
なお、ここでは業務アプリ4cがサービス9aを使用する場合について説明したが、他のサービス9b、9cを用いる場合や複数のサービス9a〜9cを併用する場合であっても同様に処理される。
【0049】
(企業Bにおける不正アクセス監査)
実施の形態2における不正アクセス監査処理について、図12のフローチャートを用いて説明する。
アクセス監査処理が始まると(S60)、企業Bの管理用サーバ6aは、例えば自装置内に設けた監査用タイマ(図示しない)により監査時間の経過を計測する(S61)。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ6aはアクセス監査ログテーブル33、33aをチェックする(S62)。
なお、ここではアクセス監査ログテーブル33、33aの監査時間が同じである場合について説明するが、複数の監査用タイマを設けて監査時間を個別に計測できるようにしても良い。
【0050】
管理用サーバ6aがアクセス監査ログテーブル33のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ6aに未登録の署名を含む場合(S64)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33から不正アクセスに使用された変換IDを取得する(S65)。
【0051】
管理用サーバ6aがアクセス監査ログテーブル33aのチェックで不正アクセスと判断した場合も同様に(S64)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33aから不正アクセスに使用された変換IDを取得する(S66)。
【0052】
管理用サーバ6aは取得した変換IDを企業AのID検索サーバ7に通知し(S67)、ID検索サーバ7内の検索ID登録部71が変換IDを検索IDとして自装置内に登録する(S68)。ID検索部72は登録された検索IDをキーとしてID変換ログテーブル32を検索し(S69)、検索IDに対応するユーザIDを取得する(S70)。その後、ID検索部72は取得したユーザIDを検索キーとしてユーザ情報テーブル31aから対応するユーザ情報を取得し(S71)、通知部73が管理者端末5aに通知する(S72)。管理者端末5aは通知された検索結果を画面に表示し(S73)、アクセス監査処理を終了する(S74)。
【0053】
本実施の形態によれば、ESB8にサービス用ID監査記録部81を設けて共通コンポーネントであるサービス9a〜9cへのアクセスをアクセス監査ログテーブル33aに記録し、管理用サーバ6aから不正アクセス監査処理ができるようにしたため、実施の形態1の効果に加えて、共通コンポーネント単位の不正アクセス監査も可能となる。このような形態では、サービスへの不正アクセスが検出された場合であっても、業務アプリへの不正アクセスが検出されない場合には、不正アクセスが検出されたサービスへのアクセス権限のみを制限するといったアクセスポイントに応じた柔軟な設定が可能となる。
【0054】
上記実施の形態1、2の説明において「〜部」と説明したものは、「〜手段」、「〜回路」、「〜機器」であっても良い。すなわち、ソフトウェア、ファームウェア、素子・デバイス・基板・配線などのハードウェア、あるいはこれらの組合せによって実施するものであっても良い。ソフトウェアやファームウェアの場合、プログラムとしてROMやDVD等の記録媒体に記録され、認証サーバ2a、2b内あるいはID検索サーバ7内のCPU(図示しない)がこれらのプログラムを読み出し実行することで、「〜部」として機能するものである。
【符号の説明】
【0055】
1a〜1f クライアント端末装置
2a、2b 認証サーバ
21a、21b 認証部
22a、22b 認可部
23a、23b ID変換部
24 変換ID記録部
25 特定ID監査記録部
3a〜3c リポジトリ
31a、31b ユーザ情報テーブル
32 ID変換ログテーブル
33、33a アクセス監査ログテーブル
4a〜4d 業務アプリ
5a、5b 管理者端末
6、6a 管理用サーバ
7 ID検索サーバ
71 検索ID登録部
72 ID検索部
73 通知部
8 ESB(Enterprise service bus)
81 サービス用ID監査記録部
9a〜9c サービス
10a〜10c イントラネット
11 ネットワーク
【技術分野】
【0001】
本発明は、ユーザが企業をまたがってWeb系アプリケーションを利用できる認証システムに関するものである。
【背景技術】
【0002】
複数の企業間で用いられるWeb系クライアント/サーバ型のシステムにおいて、自社の社員の個人情報を他社に提供すること無く、複数の認証システム間でシングルサインオン(1度の認証情報の入力により複数システムが利用可能とする方法)を行う認証システムとして、従来、クライアント端末と認証処理を行う複数の認証サーバとクライアント端末からの要求に基づいて適切な認証サーバを選択するセンタサーバとを備え、センタサーバにより選択された認証サーバから認証されたユーザは、選択された認証サーバおよび他の認証サーバへのアクセスが可能となる認証システムがある(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2010−205166号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載の認証システムにおいては、選択された認証サーバ以外の認証サーバはクライアント端末からのアクセスに対してユーザ認証を行わないため、不正アクセスがなされた場合であってもユーザを特定できないという問題があった。
【0005】
本発明はこのような問題を解決するためになされたもので、複数の認証サーバ間で個人情報を開示すること無くシングルサインオンができ、かつ、不正アクセスがなされた場合に不正アクセスしたユーザの特定が可能な認証システムを得ることを目的とする。
【課題を解決するための手段】
【0006】
本発明に係る認証システムは、ユーザ識別子を有するユーザにより使用されるクライアント端末装置、ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、クライアント端末装置からのアクセスを認証する第1の認証装置、第1の認証装置により認証されたクライアント端末装置からのアクセスを認証する第2の認証装置、クライアント端末装置から第2の認証装置を介してアクセスされるアプリケーション部、を備えた認証システムであって、第1の認証装置は、クライアント端末装置からユーザ識別子を受信する受信部、受信部により受信されたユーザ識別子を用いて第1の変換IDを生成する第1のID変換部、クライアント端末装置からアプリケーション部へのアクセスが要求された場合にユーザ情報テーブルからユーザ識別子に対応する属性情報を取得し、属性情報及び第1のID変換部により生成された第1の変換IDを第2の認証装置に送信する送信部、を有し、第2の認証装置は、第1の認証装置から受信した属性情報を用いて第2の変換IDを生成する第2のID変換部、第2のID変換部により生成された第2の変換IDを用いてクライアント端末装置からのアクセスを認証する認証部、認証部により認証されたクライアント端末装置のアプリケーション部へのアクセス情報を第1の変換IDと共に第1のアクセスログテーブルに記録する第1の記録部と、を有することを特徴とするものである。
【発明の効果】
【0007】
本発明によれば、認証システムは上記構成を備え、第1の認証装置がユーザ識別子から生成した変換IDとユーザの属性情報を第2の認証装置に送信し、第2の認証装置は受信した属性情報を用いてユーザの認証を行い、このユーザによるアプリケーション部へのアクセス情報を第1の認証装置から受信した変換IDと共にアクセスログテーブルに記録することにより、第1の認証装置と第2の認証装置間で個人情報であるユーザ識別子を開示すること無くシングルサインオンでき、かつ、不正アクセスがなされた場合には第2の認証装置において変換IDにより不正アクセスしたユーザを特定できる。
【図面の簡単な説明】
【0008】
【図1】実施の形態1に係る認証システムの構成を示す図である。
【図2】実施の形態1におけるクライアント端末及び認証サーバ間の認証シーケンスを示す図である。
【図3】実施の形態1における複数企業間の認証シーケンスを示す図である。
【図4】実施の形態1における認証処理を示すフローチャートである。
【図5】図4の認証連携受入処理Xを示すフローチャートである。
【図6】図4の認証連携受入処理Yを示すフローチャートである。
【図7】実施の形態1におけるアクセス監査処理を示すフローチャートである。
【図8】実施の形態2に係る認証システムの構成を示す図である。
【図9】実施の形態2における認証連携受入処理Xを示すフローチャートである。
【図10】実施の形態2における認証連携受入処理Yを示すフローチャートである。
【図11】実施の形態2における複数企業間の認証シーケンスを示す図である。
【図12】実施の形態2におけるアクセス監査処理を示すフローチャートである。
【発明を実施するための形態】
【0009】
実施の形態1.
本発明を実施するための実施の形態1に係る認証システムを図1ないし図7を用いて説明する。図1において、認証システム100は企業Aのイントラネット10a、企業Bのイントラネット10b、2つのイントラネット10a、10bを接続するネットワーク11を備え、企業Aのイントラネット10aにはユーザにより利用されるクライアント端末装置1a〜1c、クライアント端末装置からのアクセスを認証する認証サーバ2aすなわち第1の認証装置、ユーザ情報テーブル31aやID変換ログテーブル32を記録したリポジトリ3aすなわち第1の記憶部及び第2の記憶部、認証サーバ2aにより認証されたユーザによる利用が可能な業務アプリケーション部4a、4b(以降、業務アプリ4a、4bと称する)、ユーザIDを検索するID検索サーバ7すなわち検索装置、管理用の管理者端末5aすなわち管理用装置が設けられている。
【0010】
また、企業Bのイントラネット10bにはクライアント端末装置1d〜1f、クライアント端末装置からのアクセスを認証する認証サーバ2bすなわち第2の認証装置、ユーザ情報テーブル31bやアクセス監査ログテーブル33すなわち第1のアクセスログテーブルを記録したリポジトリ3b、認証サーバ2bにより認証されたユーザの利用が可能な業務アプリケーション4c、4dすなわちアプリケーション部、定期的にアクセス監査を行う管理用サーバ6すなわち監視装置、管理用サーバ6へアクセスするための管理者端末5bが設けられている。
【0011】
なお、ここではWebアプリケーションの一例として業務アプリを用いているが、業務用以外のWebアプリケーションであっても良い。また、ここではユーザ情報テーブル31aとID変換ログテーブル32を同じリポジトリ3aに記録しているが、それぞれ異なるリポジトリに記憶させても良い。
【0012】
企業Aの認証サーバ2aは、クライアント端末装置1a〜1fからユーザを識別するユーザIDすなわちユーザ識別子やパスワードを受信する受信部(図示しない)、クライアント端末装置1a〜1fからのアクセスの正当性を確認する認証部21a、認証されたユーザの自社の業務アプリ4a、4bへのアクセスを自装置内のアクセスポリシーに基づいて認可する認可部22a、ユーザID及びアクセス日時の情報からハッシュ関数などを用いて変換IDすなわち第1の変換IDを生成するID変換部23aすなわち第1のID変換部、変換IDをリポジトリ3aに記録する変換ID記録部24、リポジトリ3aに記憶されたユーザ情報テーブル2aからユーザIDに対応するユーザの役職情報すなわち属性情報を取得し変換IDと共に認証連携用トークン(後述)に含めて認証サーバ2bに送信する送信部(図示しない)を備えている。認証部21aはリバースプロキシ機能を有し、クライアント端末装置1a〜1fから業務アプリ4a、4bへのアクセスが要求される場合には必ず経由される。
なお、変換IDはユーザIDから一意に決まるものであって、変換IDからユーザIDを推測したり逆変換してユーザIDを生成したりすることはできない。
【0013】
リポジトリ3aに保存されたユーザ情報テーブル31aには、ユーザID、ユーザ名、ユーザの属性情報である部、課、役職、パスワードなどがそれぞれユーザIDごとに対応付けて記録されている。例えば図1の例では、ユーザIDが「User-A1」、「User-A2」、「User-A3」の3名分のユーザ情報が記録されている。一方、ID変換ログテーブル32には、ID変換部23aにより変換された変換ID、変換前のユーザID、変換日時の情報がそれぞれ対応付けて記録されている。
【0014】
ID検索サーバ7は企業Bの管理用サーバ6又は管理者端末5bから不正アクセスと判断された変換IDを受取り登録する検索ID登録部71、検索ID登録部71に登録された変換IDを検索キーとしてID変換ログテーブル32からユーザIDを検索するID検索部72、検索の結果取得されたユーザIDを管理者端末5aに通知する通知部73を備えている。
【0015】
企業Bの認証サーバ2bも、企業Aの認証サーバ2aと同様にクライアント端末装置からのユーザのアクセスを認証する認証部21b、認証されたユーザの自社の業務アプリ4c、4dへのアクセスを認可する認可部22bを備えている。また、認証サーバ2bは自社のユーザのユーザIDから変換ID(企業Aにアクセスする際に使用する)を生成すると共に企業Aのユーザからアクセスされた場合に認証連携用トークン(後述)に含まれる役職情報から役職IDすなわち第2の変換IDを生成するID変換部23bすなわち第2のID変換部と、自社の業務アプリ4c、4dにアクセスしたユーザのユーザ情報をユーザ情報テーブル31bに登録されたユーザIDごとに記録する特定ID監査記録部25すなわち第1の記録部を備えている。
なお、ここではID変換部23bは企業Aから企業Bへのアクセスは役職に応じて行うものとして認証連携用トークン(後述)に含まれる役職情報から役職IDを生成しているが、ユーザの他の属性情報に応じてアクセスする場合はアクセスに使用するユーザの属性情報から属性IDを生成する。
【0016】
リポジトリ3bはユーザ情報テーブル31bとアクセス監査ログテーブル33を有し、ユーザ情報テーブル31bには、ユーザID、ユーザ名、ユーザの属性である部、課、役職、パスワードがそれぞれ対応付けて記録されている。例えば図1の例では、企業BのユーザのユーザID「User-B1」、「User-B2」、「User-B3」のほかに企業Aの役職ごとに設けられたユーザID「User-Bucho」、「User-Kacho」、「User-Ippan」の6名分のユーザ情報が記録されている。
【0017】
アクセス監査ログテーブル33には、特定ID監査記録部25により記録されたクライアント端末装置1a〜1fからのアクセス日時、アクセスに使用されたユーザID、アクセスされた業務アプリのURL、認証連携用トークン(後述)に含まれる変換IDの情報が対応付けて記録されている。なお、変換IDの情報が記録されるのは、企業Aからのアクセスの場合のみであって、企業Bのユーザが自社の業務アプリにアクセスする場合は変換IDを生成せずユーザIDを用いるため、変換IDの欄は空欄となる。
【0018】
ここでは企業A、企業Bのクライアント端末をそれぞれ3台、業務アプリをそれぞれ2台設けているが、数はこれに限るものではなく、これより多くても少なくても良い。また、図1は企業Aのクライアント端末装置1a〜1cから企業Bの業務アプリ4c、4dにアクセスするために必要な構成を示したものであり、企業Aに特定ID監査記録部25、アクセス監査ログテーブル33、及び管理用テーブルを設け、企業Bに変換ID記録部24、ID検索サーバ7を設けても良い。このような構成とすることで、企業Bのクライアント端末1d〜1fから企業Aの業務アプリ4a、4bへのアクセスが可能となる。
【0019】
ここで、認証システム100の動作について説明する。
(企業A内部における認証処理)
図2は、クライアント端末装置1aが自社の認証サーバAに初めてアクセスする場合のシーケンスを示している。企業AのユーザであるユーザA1(ユーザID:User-A1)が自社の認証サーバ2aにアクセスすると(S1)、認証部21aが認証サーバ2a内のユーザID「User-A1」に対する認証済みクッキーの有無をチェックする(S2)。
【0020】
ユーザA1の認証サーバ2aへの認証がまだの場合、認証サーバ2aはクライアント端末装置1aに認証サーバ2aへログインするためのログイン画面を返す(S3)。クライアント端末装置1aはログイン画面を受取ると自装置の表示画面(図示しない)にログイン画面を表示する(S4)。ログイン画面を見たユーザA1によりクライアント端末装置1aにユーザA1のユーザID「User-A1」とパスワードが入力されると、クライアント端末装置1aはこのユーザID「User-A1」とパスワードを認証情報として認証サーバ2aに送信する(S5)。認証サーバ2aはユーザID「User-A1」とパスワードを受信すると、ユーザ情報テーブル31aに記録されているユーザID「User-A1」及びパスワードと比較して認証処理を行う(S6)。
【0021】
受信したユーザID「User-A1」とパスワードが記録されたユーザID「User-A1」とパスワードにそれぞれ一致すると認証サーバ2aは認証に成功したと判断し(S6)、ユーザIDを埋め込んだ認証済みクッキーを発行してクライアント端末装置1aに返信する(S7)。ここで、認証済みクッキーとは、クッキー(Webサーバがサイトを訪問したユーザが使用するクライアント端末装置に保存させるテキスト形式の情報)の一種であって、認証サーバにより認証されたことを示すものである。
【0022】
認証サーバからクライアント端末装置にクライアント端末装置1aが認証済みクッキーを受信して認証が完了すると、クライアント端末装置1aは表示画面に自社の業務アプリ4a、4b及び連携している企業Bの業務アプリ4c、4dを選択するためのメニュー画面を表示する(S8)。これ以後、ユーザA1はクライアント端末装置1aに表示されたメニュー画面から業務アプリ4a〜4dの選択が可能となる。
【0023】
(企業Aから企業Bの業務アプリに始めてアクセスする場合)
図3は、自社の認証サーバ2aに認証されたクライアント端末装置1aが、他社である企業Bの業務アプリ4cにアクセスする場合のシーケンスを示している。
ユーザA1が、クライアント端末装置1aから企業Bの業務アプリ4cのURL(Uniform Resource Locator)へアクセスするために、認証サーバ2bにこのURL情報を含むHTTPリクエストを送信する(S9)。認証サーバ2bはHTTPリクエストを受付け(S10)、認証部21bがこの企業Aからのアクセスに対する認証済みクッキーの有無をチェックする(S11)。
【0024】
企業Bの認証サーバ2b内に認証済みクッキーが無く、認証部21bが企業Aからのアクセスは未認証であると判断した場合、認証サーバ2bはクライアント端末装置1aに、企業Aの認証サーバAに認証連携用トークンを要求するリダイレクトページを返信する(S12)。ここで、認証連携用トークンとは、複数のWebサイトをシングルサインオンで利用するために認証サーバ2a、2b間で用いられる、SAML(Security Assertion Markup Language)プロトコルで規定された認証情報であって、クッキーの更新と同様に、複数の認証サーバをまたがった一連のアクセス毎に更新されるものである。
【0025】
リダイレクトページを受信したクライアント端末装置1aは、企業Aの認証サーバ2aに企業Bの認証サーバ2bに対する認証連携用トークンの発行を要求する(S13)。認証連携用トークンを要求された認証サーバ2aはこれを受付け(S14)、ID変換部23aにて変換ID「WXYZ」を生成し、ID変換ログテーブル32に記録する(S15)。その後、認証サーバ2aはユーザA1の属性情報のひとつであるユーザA1の役職情報「部長」と変換ID「WXYZ」を含む認証連携用トークンを発行し(S16)、クライアント端末装置1aに認証連携用トークンを含むリダイレクトページを返信する(S17)。クライアント端末装置1aに返信されたリダイレクトページは、企業Bの認証サーバ2bへ認証連携用トークンを送信するためのページである。なお、S16にて発行された認証連携用トークンには、セキュリティ向上のために認証の有効期限情報やユーザの役職に対応する署名等の情報を含んでも良い。
【0026】
クライアント端末装置1aはリダイレクトページを受信すると、企業Bの認証サーバ2bに認証連携用トークンを送信し(S18)、認証部21bが認証連携用トークンのチェックすなわち自装置内に登録されている認証連携用トークンと比較して一致するか否かの確認を行い(S19)、正常(受信した認証連携用トークンと認証サーバ2bに登録されている認証連携用トークンとが一致する)と判断した場合には認証連携用トークンに含まれるユーザA1の役職「部長」と変換ID「WXYZ」の情報を取得する(S20)。
【0027】
ID変換部23bは取得した役職「部長」の情報から変換役職ID「User-Bucho」を生成し、この変換役職ID「User-Bucho」をユーザIDとして認証サーバ2bにログインする(S21)。その後、認証サーバ2bはユーザID(変換役職ID)「User-Bucho」と変換ID(企業Aの認証サーバ2aから受信した変換ID)「WXYZ」を認証済みクッキーに記録し(S22)、クライアント端末装置1aから受信したHTTPリクエストを業務アプリ4cへ転送する(S23)。業務アプリ4cはリクエスト結果としてHTMLページを認証サーバ2bに返信する(S24)。
【0028】
HTMLページを受信した認証サーバ2bの特定ID監査記録部25は、アクセス監査ログテーブル33にアクセス日時「201009270900」、アクセスに使用されたユーザID(変換役職ID)「User-Bucho」、アクセスした業務アプリのURL(業務アプリB-1のURL)、ユーザIDに対応する変換IDの情報(企業Aからのアクセスの場合のみ)「WXYZ」を記録してログの更新を行い(S25)、クライアント端末装置1aに受信したHTMLページを転送する(S26)。クライアント端末装置1aは自身の表示画面に受信したHTMLページを表示する(S27)。
【0029】
(企業Aから企業Bの業務アプリへ2回目以降のアクセスをする場合)
図4は、図2、図3のシーケンスをフローチャートで示したものであり、同一番号を付したステップの動作は共通する。
S2において、クライアント端末装置1aが自社の認証サーバ2aにより認証済みである場合はS8にスキップする。
【0030】
S6において、自社の認証サーバ2aによる認証処理に失敗、すなわちクライアント端末装置1aから受信したユーザIDとパスワードの少なくとも一方がユーザ情報テーブル31aに登録されているものと一致しない場合、認証サーバ2aは失敗回数をカウントし(S30)、カウントした失敗回数が予め定めた所定回数以上であるか否かを判断する(S31)。失敗回数が所定回数以上であると判断すると、クライアント端末装置1aに認証エラー画面を返信し(S32)、クライアント端末装置1aは表示画面に認証エラー画面を表示する(S33)。失敗回数が所定回数未満であれば、再度S3に戻り、クライアント端末装置1aにログイン画面を返信し、フローを終了する(S34)。
【0031】
ここで、認証連携受入処理X(S18〜S29)について図5を用いて補足説明する。
S19において、認証サーバ2bが受信した認証連携用トークンが自装置内に登録されている認証連携用トークンと一致しないと判断した場合、認証サーバ2bはクライアント端末装置1aに認証エラー画面を返信し(S28)、クライアント端末装置1aは受信した認証エラー画面を表示画面に表示する(S29)。クライアント端末装置1aがリクエストされたHTMLページを表示(S27)、あるいは認証エラー画面を表示すると(S29)、認証連携受入処理Xを終了し全体フローも終了する(S34)。
【0032】
図4のS11において、他社の認証サーバ2bにすでに認証されている場合は認証連携受入処理Yを行う。図6に示すように、認証連携受入処理Yは上述のS23からS27までの処理を順次行うものであり、S27が完了すると認証連携処理Bを終了し、全体フローを終了する(S34)。
【0033】
(企業Bにおける不正アクセス監査)
図7は不正アクセス監査処理のフローチャートである。
アクセス監査処理が始まると(S40)、企業Bの管理用サーバ6は、例えば自装置内に設けた監査用タイマ(図示しない)により監査時間の経過を計測する(S41)。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ6はアクセス監査ログテーブル33をチェックする(S42)。
ここで、アクセス監査ログテーブル33のチェックとは、具体的には、予め定めた有効期限内のアクセスであるか否か、管理用サーバ6に登録されている署名を有するものか等、一般的な認証と同様の確認処理のことを示している。
【0034】
管理用サーバ6がアクセス監査ログテーブル33のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ6に未登録の署名を含む場合(S43)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33から不正アクセスに使用された変換IDを取得する(S44)。
【0035】
管理用サーバ6は取得した変換IDを企業AのID検索サーバ7に通知し(S45)、ID検索サーバ7内の検索ID登録部71が変換IDを検索IDとして自装置内に登録する(S46)。ID検索部72は登録された検索IDをキーとしてID変換ログテーブル32を検索し(S47)、検索IDに対応するユーザIDを取得する(S48)。その後、ID検索部72は取得したユーザIDを検索キーとしてユーザ情報テーブル31aから対応するユーザ情報を取得し(S49)、通知部73が管理者端末5aに通知する(S50)。管理者端末5aは通知された検索結果を画面に表示し(S51)、アクセス監査処理を終了する(S52)。
【0036】
このように、企業AのユーザA1が企業BのWeb系アプリケーションにアクセスする場合、企業Aの認証サーバ2aと企業Bの認証サーバ2b間でユーザA1のユーザIDから生成した変換ID及び属性情報を含む認証連携用トークンを用いて認証を行うため、企業AはユーザA1を特定するユーザIDを企業Bに開示せずともシングルサインオンにて企業BのWeb系アプリケーションにアクセスすることができる。
【0037】
また、企業Bの管理用サーバ6が定期的あるいは不定期にアクセス監査用ログテーブルの内容を確認して不正アクセスであるか否かを判断し、不正アクセスであると判断した場合は不正アクセスに使用された変換IDを不正アクセスIDとして検出することができる。
また、検出した不正アクセスIDを企業Aに通知し、企業AではID検索サーバ7が通知された不正アクセスID(変換ID)に基づいてユーザIDを検索し不正アクセスしたユーザを特定することにより、企業A内で不正アクセスを行うユーザの管理が容易になる。
また、企業Aでは企業BのWeb系アプリケーションに不正アクセスしたユーザの情報を管理者端末5aの画面に表示するため、企業Aの管理者は画面を見ることで不正アクセスした自社のユーザ情報を容易に確認できる。
【0038】
S41にて監査用タイマが満了していない場合、あるいはS43にて管理用サーバ6が不正アクセスでは無いと判断した場合はS41に戻る。
また、監査用タイマの満了時だけでなく、管理者端末5bから管理用サーバ6へ任意のタイミングで監査指示を出せるようにし、監査指示があった場合に管理用サーバ6がS42の処理をするようにしても良い。
【0039】
ここまで、クライアント端末装置1aから業務アプリ4cにアクセスする場合について説明したが、クライアント端末装置1aは企業Aの他のクライアント端末装置1b、1cであっても良いし、業務アプリ4cは企業Bの他の業務アプリ4dであっても良いことは言うまでもない。
【0040】
本実施の形態によれば、認証システム100はユーザの属性情報を用いて企業A、B間での認証を行うことにより、企業Aの社員個人情報であるユーザIDを他社である企業Bに提供すること無く企業Aから企業Bのイントラネット10bへのシングルサインオンが可能となり、安全性を高く保つことができる。また、認証システム100は企業A、B間でやりとりする認証連携用トークンにユーザの属性情報及びユーザIDから生成した変換IDを含めることにより、企業Aから企業Bの業務アプリ4c、4dへのアクセスを変換IDごとに管理することが可能となり、企業Bにおいて企業Aのユーザ個人情報を知らずとも不正アクセスしたユーザを特定できる。
また、企業Bは不正アクセスに使用された変換IDを不正アクセスIDとして検出することにより機械的にユーザを特定できる。
また、不正アクセスに使用された変換IDを企業Bから企業Aに通知することにより、企業Aにおいて不正アクセスしたユーザを特定することができ、不正アクセスを行うユーザの管理が容易になる。
【0041】
また、企業Aから企業Bの業務アプリ4cに不正アクセスしたユーザA1の情報を管理者端末5aの画面に表示することにより、企業Aの管理者は不正アクセスした自社のユーザ情報を容易に確認できる。
また、企業Bの管理用サーバ6は監査用タイマが満了するとアクセス監査ログテーブルを確認することにより、定期的にアクセス監査を実行できる。
また、企業Bの管理者端末5bから任意のタイミングで監査指示を出せるようにしたため、企業Bでの要求に応じたアクセス監査を実施することもできる。
【0042】
実施の形態2.
本発明を実施するための実施の形態2に係る認証システムを図8ないし図12を用いて説明する。図8に示す認証システム100aは、実施の形態1に係るイントラネット10bに、業務アプリ4c、4dに対する共通コンポーネントであるサービス9a〜9cすなわち共通コンポーネント部、サービス9a〜9cのインターフェースを業務アプリ4c、4dに提供するためのESB(Enterprise service bus)8すなわち中継装置、及びサービス9a〜9cへのアクセスを登録するアクセス監査ログテーブル33aすなわち第2のアクセスログテーブルを有し監査ログデータベースとして機能するリポジトリ3cを設けた、イントラネット10cを備えたものである。
このようにESB8を設けることにより、システムがSOA(Service Oriented Architecture)化され、共通コンポーネントの再利用が可能となる。
【0043】
ESB8内には、アクセス監査ログテーブル33aに各サービス9a〜9cへアクセスしたユーザ情報等を記録するサービス用ID監査記録機能部81すなわち第2の記録部が備えられている。また、管理用サーバ6aはリポジトリ3b及びリポジトリ3cのアクセス監査ログテーブル33、33aへのアクセスを定期的に監査できるように設けられたものである。
【0044】
アクセス監査ログテーブル33aには、サービス用ID監査記録機能部81により記録されたクライアント端末装置1a〜1fからのアクセス日時、アクセスに使用されたユーザID、アクセス元の業務アプリのURL、アクセス先のサービス種別、認証連携用トークンに含まれる変換IDの情報(企業Aからのアクセスの場合のみ)が対応付けて記録されている。なお、企業Bのユーザが自社の業務アプリにアクセスする場合は変換IDを生成せずにユーザIDを用いるため、変換IDの欄は空欄となる。
その他の構成は実施の形態1と同じであるため、説明を省略する。
【0045】
ここで、認証システム100aの動作について説明する。
企業A内部における認証処理、及び企業Aから企業Bの業務アプリに始めてアクセスする場合の大まかな処理の流れは実施の形態1と同じであり、認証連携受入処理の一部が異なる。図9に実施の形態2における認証連携受入処理Xのフローチャートを、図10に実施の形態2における認証連携受入処理Yのフローチャートを示す。認証システム100aでは、図5のS24の代わりにS241〜S246の処理を行う。S23〜S246の各ステップの処理について、図11のシーケンス図を用いて順に説明する。
【0046】
認証サーバ2bはクライアント端末装置1aから受信したHTTPリクエストを業務アプリ4cに転送すると(S23)、業務アプリ4cはこのHTTPリクエストに対応するHTMLページを作成するために必要なサービスを得るため、ESB8にサービス9aをリクエストする(S240)。ESB8は受信したリクエストをサービス9aに転送し(S241)、サービス9aはESB8にリクエストの結果をSOAPというプロトコルを用いて返信する(S242)。
【0047】
リクエスト結果を受信したESB8のサービス用ID監査記録部81は、アクセス監査ログテーブル33aにアクセス日時「201009270900」、アクセスに使用されたユーザID「User-Bucho」、アクセス元の業務アプリのURL(業務アプリB-1のURL)、アクセス先のサービス種別「サービスB-a」、ユーザID「User-Bucho」に対応する変換ID(企業Aからのアクセスの場合のみ)「WXYZ」を記録してログの更新を行い(S243)、リクエスト結果を業務アプリ4cに返信する(S244)。業務アプリ4cは受信したリクエスト結果を用いてHTMLページを生成し(S245)、認証サーバ2bに返信する(S246)。その後の動作は実施の形態1と同様である。
【0048】
なお、ここでは業務アプリ4cがサービス9aを使用する場合について説明したが、他のサービス9b、9cを用いる場合や複数のサービス9a〜9cを併用する場合であっても同様に処理される。
【0049】
(企業Bにおける不正アクセス監査)
実施の形態2における不正アクセス監査処理について、図12のフローチャートを用いて説明する。
アクセス監査処理が始まると(S60)、企業Bの管理用サーバ6aは、例えば自装置内に設けた監査用タイマ(図示しない)により監査時間の経過を計測する(S61)。監査用タイマが満了して監査時間が経過したと判断すると、監査用サーバ6aはアクセス監査ログテーブル33、33aをチェックする(S62)。
なお、ここではアクセス監査ログテーブル33、33aの監査時間が同じである場合について説明するが、複数の監査用タイマを設けて監査時間を個別に計測できるようにしても良い。
【0050】
管理用サーバ6aがアクセス監査ログテーブル33のチェックで不正アクセスと判断した場合、すなわち認証連携用トークンに含まれる有効期限情報が所定の有効期限を超過している場合や管理用サーバ6aに未登録の署名を含む場合(S64)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33から不正アクセスに使用された変換IDを取得する(S65)。
【0051】
管理用サーバ6aがアクセス監査ログテーブル33aのチェックで不正アクセスと判断した場合も同様に(S64)、不正アクセスと判断したユーザのアクセス日時及びユーザIDの情報を検索キーとしてアクセス監査ログテーブル33aから不正アクセスに使用された変換IDを取得する(S66)。
【0052】
管理用サーバ6aは取得した変換IDを企業AのID検索サーバ7に通知し(S67)、ID検索サーバ7内の検索ID登録部71が変換IDを検索IDとして自装置内に登録する(S68)。ID検索部72は登録された検索IDをキーとしてID変換ログテーブル32を検索し(S69)、検索IDに対応するユーザIDを取得する(S70)。その後、ID検索部72は取得したユーザIDを検索キーとしてユーザ情報テーブル31aから対応するユーザ情報を取得し(S71)、通知部73が管理者端末5aに通知する(S72)。管理者端末5aは通知された検索結果を画面に表示し(S73)、アクセス監査処理を終了する(S74)。
【0053】
本実施の形態によれば、ESB8にサービス用ID監査記録部81を設けて共通コンポーネントであるサービス9a〜9cへのアクセスをアクセス監査ログテーブル33aに記録し、管理用サーバ6aから不正アクセス監査処理ができるようにしたため、実施の形態1の効果に加えて、共通コンポーネント単位の不正アクセス監査も可能となる。このような形態では、サービスへの不正アクセスが検出された場合であっても、業務アプリへの不正アクセスが検出されない場合には、不正アクセスが検出されたサービスへのアクセス権限のみを制限するといったアクセスポイントに応じた柔軟な設定が可能となる。
【0054】
上記実施の形態1、2の説明において「〜部」と説明したものは、「〜手段」、「〜回路」、「〜機器」であっても良い。すなわち、ソフトウェア、ファームウェア、素子・デバイス・基板・配線などのハードウェア、あるいはこれらの組合せによって実施するものであっても良い。ソフトウェアやファームウェアの場合、プログラムとしてROMやDVD等の記録媒体に記録され、認証サーバ2a、2b内あるいはID検索サーバ7内のCPU(図示しない)がこれらのプログラムを読み出し実行することで、「〜部」として機能するものである。
【符号の説明】
【0055】
1a〜1f クライアント端末装置
2a、2b 認証サーバ
21a、21b 認証部
22a、22b 認可部
23a、23b ID変換部
24 変換ID記録部
25 特定ID監査記録部
3a〜3c リポジトリ
31a、31b ユーザ情報テーブル
32 ID変換ログテーブル
33、33a アクセス監査ログテーブル
4a〜4d 業務アプリ
5a、5b 管理者端末
6、6a 管理用サーバ
7 ID検索サーバ
71 検索ID登録部
72 ID検索部
73 通知部
8 ESB(Enterprise service bus)
81 サービス用ID監査記録部
9a〜9c サービス
10a〜10c イントラネット
11 ネットワーク
【特許請求の範囲】
【請求項1】
ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、
前記クライアント端末装置からのアクセスを認証する第1の認証装置、
前記第1の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第2の認証装置、
前記クライアント端末装置から前記第2の認証装置を介してアクセスされるアプリケーション部、
を備えた認証システムにおいて、
前記第1の認証装置は、
前記クライアント端末装置から前記ユーザ識別子を受信する受信部、
前記受信部により受信された前記ユーザ識別子を用いて第1の変換IDを生成する第1のID変換部、
前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得し、該属性情報及び前記第1のID変換部により生成された前記第1の変換IDを前記第2の認証装置に送信する送信部、を有し、
前記第2の認証装置は、
前記第1の認証装置から受信した前記属性情報を用いて第2の変換IDを生成する第2のID変換部、
前記第2のID変換部により生成された前記第2の変換IDを用いて前記クライアント端末装置からのアクセスを認証する認証部、
前記認証部により認証された前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第1の変換IDと共に第1のアクセスログテーブルに記録する第1の記録部と、を有することを特徴とする認証システム。
【請求項2】
前記アプリケーション部を複数有する場合に該複数のアプリケーション部に使用される共通コンポーネント部と、
前記アプリケーション部と前記共通コンポーネント部との間に設けられ、前記アプリケーション部から前記共通コンポーネント部への要求、及び前記共通コンポーネント部から前記アプリケーション部への前記要求に対する結果を中継する中継装置と、
前記アプリケーション部から前記共通コンポーネント部へのアクセス情報を前記第1の変換IDと共に第2のアクセスログテーブルに記録する第2の記録部と、を備えたことを特徴とする請求項1に記載の認証システム。
【請求項3】
前記第1のアクセスログテーブルに所定のアクセス情報以外の情報が記録された場合に不正アクセスと判断し、該不正アクセスに使用された前記第1の変換IDを不正アクセスIDとして検出する監視装置を備えたことを特徴とする請求項1又は請求項2に記載の認証システム。
【請求項4】
前記ユーザ情報テーブルは前記ユーザ識別子に対応するユーザ名を保持し、
前記認証システムは、
前記ユーザ識別子及び前記第1の変換IDを記録したID変換ログテーブルを有する第2の記憶部と、
前記監視装置により不正アクセスIDとして検出された前記第1の変換IDに対応するユーザ識別子を前記ID変換ログテーブルから検索し、前記検索の結果得られたユーザ識別子に対応する前記ユーザ名を前記ユーザ情報テーブルから取得する検索装置と、
を備えたことを特徴とする請求項3に記載の認証システム。
【請求項5】
前記第1の認証装置は、前記属性情報と前記第1の変換IDと認証の有効期限情報とを有する認証連携用トークンを前記第2の認証装置に送信し、
前記第2の認証装置は、前記第1のアクセスログテーブルにアクセス情報として前記有効期限情報を記録し、
前記監視装置は、前記第1のアクセスログテーブルに記録された前記有効期限情報が所定の有効期限を超過している場合に不正アクセスと判断することを特徴とする請求項3に記載の認証システム。
【請求項6】
前記第1の認証装置は、前記属性情報と前記第1の変換IDと前記属性情報に対応する署名とを有する認証連携用トークンを前記第2の認証装置に送信し、
前記第2の認証装置は、前記第1のアクセスログテーブルにアクセス情報として前記署名を記録し、
前記監視装置は、前記第1のアクセスログテーブルに記録された前記署名が自装置内に登録されていない場合に不正アクセスと判断することを特徴とする請求項3に記載の認証システム。
【請求項7】
ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、
前記クライアント端末装置からのアクセスを認証する第1の認証装置、
前記第1の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第2の認証装置、
前記クライアント端末装置から前記第2の認証装置を介してアクセスされるアプリケーション部、
を有する認証システムで実行される認証方法において、
前記第1の認証装置が前記クライアント端末装置から前記ユーザ識別子を受信する第1ステップ、
前記第1の認証装置が前記第1ステップにより受信した前記ユーザ識別子を用いて第1の変換IDを生成する第2ステップ、
前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記第1の認証装置が前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得する第3ステップ、
前記第1の認証装置が前記第3ステップにより取得した前記属性情報及び前記第2ステップにより生成した前記第1の変換IDを前記第2の認証装置に送信する第4ステップ、
前記第2の認証装置が前記第1の認証装置から前記属性情報及び前記第1の変換IDを受信する第5ステップ、
前記第2の認証装置が前記第5ステップにより受信した前記属性情報を用いて第2の変換IDを生成する第6ステップ、
前記第2の認証装置が前記第6ステップにより生成した前記第2の変換IDを用いて前記クライアント端末装置からのアクセスを認証する第7ステップ、
前記第2の認証装置が前記第7ステップにより認証した前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第1の変換IDと共に第1のアクセスログテーブルに記録する第8ステップ、を備えたことを特徴とする認証方法。
【請求項1】
ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、
前記クライアント端末装置からのアクセスを認証する第1の認証装置、
前記第1の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第2の認証装置、
前記クライアント端末装置から前記第2の認証装置を介してアクセスされるアプリケーション部、
を備えた認証システムにおいて、
前記第1の認証装置は、
前記クライアント端末装置から前記ユーザ識別子を受信する受信部、
前記受信部により受信された前記ユーザ識別子を用いて第1の変換IDを生成する第1のID変換部、
前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得し、該属性情報及び前記第1のID変換部により生成された前記第1の変換IDを前記第2の認証装置に送信する送信部、を有し、
前記第2の認証装置は、
前記第1の認証装置から受信した前記属性情報を用いて第2の変換IDを生成する第2のID変換部、
前記第2のID変換部により生成された前記第2の変換IDを用いて前記クライアント端末装置からのアクセスを認証する認証部、
前記認証部により認証された前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第1の変換IDと共に第1のアクセスログテーブルに記録する第1の記録部と、を有することを特徴とする認証システム。
【請求項2】
前記アプリケーション部を複数有する場合に該複数のアプリケーション部に使用される共通コンポーネント部と、
前記アプリケーション部と前記共通コンポーネント部との間に設けられ、前記アプリケーション部から前記共通コンポーネント部への要求、及び前記共通コンポーネント部から前記アプリケーション部への前記要求に対する結果を中継する中継装置と、
前記アプリケーション部から前記共通コンポーネント部へのアクセス情報を前記第1の変換IDと共に第2のアクセスログテーブルに記録する第2の記録部と、を備えたことを特徴とする請求項1に記載の認証システム。
【請求項3】
前記第1のアクセスログテーブルに所定のアクセス情報以外の情報が記録された場合に不正アクセスと判断し、該不正アクセスに使用された前記第1の変換IDを不正アクセスIDとして検出する監視装置を備えたことを特徴とする請求項1又は請求項2に記載の認証システム。
【請求項4】
前記ユーザ情報テーブルは前記ユーザ識別子に対応するユーザ名を保持し、
前記認証システムは、
前記ユーザ識別子及び前記第1の変換IDを記録したID変換ログテーブルを有する第2の記憶部と、
前記監視装置により不正アクセスIDとして検出された前記第1の変換IDに対応するユーザ識別子を前記ID変換ログテーブルから検索し、前記検索の結果得られたユーザ識別子に対応する前記ユーザ名を前記ユーザ情報テーブルから取得する検索装置と、
を備えたことを特徴とする請求項3に記載の認証システム。
【請求項5】
前記第1の認証装置は、前記属性情報と前記第1の変換IDと認証の有効期限情報とを有する認証連携用トークンを前記第2の認証装置に送信し、
前記第2の認証装置は、前記第1のアクセスログテーブルにアクセス情報として前記有効期限情報を記録し、
前記監視装置は、前記第1のアクセスログテーブルに記録された前記有効期限情報が所定の有効期限を超過している場合に不正アクセスと判断することを特徴とする請求項3に記載の認証システム。
【請求項6】
前記第1の認証装置は、前記属性情報と前記第1の変換IDと前記属性情報に対応する署名とを有する認証連携用トークンを前記第2の認証装置に送信し、
前記第2の認証装置は、前記第1のアクセスログテーブルにアクセス情報として前記署名を記録し、
前記監視装置は、前記第1のアクセスログテーブルに記録された前記署名が自装置内に登録されていない場合に不正アクセスと判断することを特徴とする請求項3に記載の認証システム。
【請求項7】
ユーザ識別子を有するユーザにより使用されるクライアント端末装置、
前記ユーザのユーザ識別子及び属性情報を有するユーザ情報テーブルを記憶した第1の記憶部、
前記クライアント端末装置からのアクセスを認証する第1の認証装置、
前記第1の認証装置により認証された前記クライアント端末装置からのアクセスを認証する第2の認証装置、
前記クライアント端末装置から前記第2の認証装置を介してアクセスされるアプリケーション部、
を有する認証システムで実行される認証方法において、
前記第1の認証装置が前記クライアント端末装置から前記ユーザ識別子を受信する第1ステップ、
前記第1の認証装置が前記第1ステップにより受信した前記ユーザ識別子を用いて第1の変換IDを生成する第2ステップ、
前記クライアント端末装置から前記アプリケーション部へのアクセスが要求された場合に前記第1の認証装置が前記ユーザ情報テーブルから前記ユーザ識別子に対応する前記属性情報を取得する第3ステップ、
前記第1の認証装置が前記第3ステップにより取得した前記属性情報及び前記第2ステップにより生成した前記第1の変換IDを前記第2の認証装置に送信する第4ステップ、
前記第2の認証装置が前記第1の認証装置から前記属性情報及び前記第1の変換IDを受信する第5ステップ、
前記第2の認証装置が前記第5ステップにより受信した前記属性情報を用いて第2の変換IDを生成する第6ステップ、
前記第2の認証装置が前記第6ステップにより生成した前記第2の変換IDを用いて前記クライアント端末装置からのアクセスを認証する第7ステップ、
前記第2の認証装置が前記第7ステップにより認証した前記クライアント端末装置の前記アプリケーション部へのアクセス情報を前記第1の変換IDと共に第1のアクセスログテーブルに記録する第8ステップ、を備えたことを特徴とする認証方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2012−164191(P2012−164191A)
【公開日】平成24年8月30日(2012.8.30)
【国際特許分類】
【出願番号】特願2011−24884(P2011−24884)
【出願日】平成23年2月8日(2011.2.8)
【出願人】(000006013)三菱電機株式会社 (33,312)
【Fターム(参考)】
【公開日】平成24年8月30日(2012.8.30)
【国際特許分類】
【出願日】平成23年2月8日(2011.2.8)
【出願人】(000006013)三菱電機株式会社 (33,312)
【Fターム(参考)】
[ Back to top ]