説明

業務処理装置、認証システム、同システムにおける認証方法、およびプログラム

【課題】認証情報のやり取りを最小限に抑えることで不正アクセスによる認証情報の漏洩、及びなりすましを防ぎ、ユーザ負荷、および認証サーバの処理負荷と通信負荷を軽減する。
【解決手段】ユーザ端末14と、認証サーバ10と、業務サーバA(12)と、業務サーバB(13)と業務サーバA(12)と業務サーバB(13)が共通して使用するサービスを実行する決裁サーバ11と、がネットワーク15経由で接続される。決裁サーバ11は、ユーザ端末14からのログイン要求を受けた場合、業務サーバA(12)もしくは業務サーバB(13)から送信される認証要求を受信し、認証サーバ10から受信した認証キーをユーザ端末14に送信する際、認証キーを、ユーザに固有で更新性のある情報により暗号化して認証情報として送信する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、あるシステムでログイン認証を済ませたユーザが他のシステムを認証の手続きなしに利用可能な仕組みを持つSSO(Single Sign On)認証システムに関する。
【背景技術】
【0002】
近年用いられるようになったSSOの具体的な利用イメージは以下のようになる。すなわち、ユーザが社内ポータルサイト等にアクセスし、ユーザID(IDentification)とパスワードを入力して認証を済ませると、その認証情報は、グループウエア等、他の社内システムに転送される。このため、ユーザは再度ログインを求められることがなくなり、システム毎に認証を要求される煩雑さが無くなり、システム管理者側にとっても運用の手間が減るといった利点がある。
【0003】
前記したSSOを実現するために、従来、プロキシ型と呼ばれる方式と、エージェント型と呼ばれる方式の2つの方式が存在する。
プロキシ型は、1つのサーバをユーザからのアクセスを全て受け付ける認証サーバとして利用し、そのサーバは認証後にプロキシサーバとして動作する。つまり、ユーザが各システムへの接続要求を認証サーバに送信すると、認証サーバがその代理として各システムに接続し、認証やデータ取得等の作業を代行する。
【0004】
一方、エージェント型は、SSOが利用可能なシステムのそれぞれにエージェントと呼ばれるプログラムを組み込むことで、認証情報をシステム間で自動的にやりとりすることができ、再度認証の必要をなくしたものである。
前記したプロキシ型とエージェント型のそれぞれに一長一短があり、プロキシ型は既存システムの変更点が少なく導入しやすい反面、プロキシサーバとして動作する認証サーバの負荷が大きい。また、エージェント型は、特定のシステムに負荷が集中することはないが、SSOで利用するシステム全てにエージェントを実装する必要がある。
【0005】
前記したエージェント型を採用してSSOを実現するシステム(例えば、非特許文献1参照)の動作シーケンスを図21に示す。
ここでは、ユーザ端末と、認証サーバと、業務サーバAと、業務サーバBとからなるSSO認証システムを例示して、その信号処理の流れについて簡単に説明する。
【0006】
まず、ユーザ端末は業務サーバAに対してログイン要求を送信する(ステップS21)。これを受けた業務サーバAは、認証情報がないため、認証サーバに対して認証要求を行う(ステップS22)。認証サーバは、ユーザ端末に認証情報生成のために必要なユーザIDとパスワード入力を促し(ステップS23)、これを受けたユーザ端末は、ユーザIDとパスワードを入力して送信する(ステップS24)。これを受けた認証サーバは、認証情報を生成してユーザ端末に送信し(ステップS25)、また、業務サーバAに認証手続きが終了したことを通知する(ステップS26)。
【0007】
認証が成功すると、業務サーバAは、ログイン要求のあったユーザ端末に対してサービス画面を送信し(ステップS27)、これを受信したユーザ端末は、先に受信した認証情報に基づき業務サーバBにログイン要求を行う(ステップS28)。
業務サーバBは、認証サーバに、受信したログイン要求に基づく認証要求を送信するが(ステップS29)、既に認証手続きは終了しているため、ユーザ端末にログインを許可し(ステップS30)、ユーザ端末は、ユーザID、パスワード入力による認証手続きをスキップして認証サーバを経由して業務サーバBに認証情報を送信する(ステップS31、S32)。これを受けた業務サーバはログイン要求のあったユーザ端末に対してサービス画面を送信して要求に応じたサービスを実行する(ステップS33)。
【先行技術文献】
【非特許文献】
【0008】
【非特許文献1】”Oasis Security Services Use Cases And Requirements(第11頁、図4)”、[online]、[2009年3月16日検索]、インターネット<URL:http://www.oasis-opeNorg/committees/security/docs/draft-sstc-saml-reqs-01.pdf2001/3>
【発明の概要】
【発明が解決しようとする課題】
【0009】
図21に示すように、従来、業務サーバA(B)は、ユーザからのログインを契機に認証サーバへ認証を要求し、認証サーバは、要求を受けた時点でのユーザ情報(ユーザID、パスワード、生体情報等)をもとに認証情報を生成してユーザに返す。そして、他の業務サーバB(A)へのログインの際は、認証サーバとユーザ端末との間でこの認証情報を利用することでユーザ情報の入力をスキップさせ、SSOを実現している。
【0010】
ところで、ステップS30で認証サーバからユーザ端末へ送信される認証情報は、ステップS25でユーザ端末が受信した認証情報と同じものであり、ユーザ端末と認証サーバ間の通信経路で同じ情報が複数回送信される。認証サーバと業務サーバ間は、比較的セキュリティ性の高いイントラネット等により接続されるが、ユーザ端末と認証サーバ間は、通常、インターネット等のオープン環境で接続される。このため、ユーザ端末と認証サーバ間で、第三者に前記した認証情報を不正に取得された場合、なりすましが容易である。
【0011】
この対策として、従来、例えば、認証情報に有効期間を設ける、あるいは、ワンタイムパスワードの仕組みを用いる方法がある。しかしながら、これらの場合、認証サーバにアクセスが集中するため、認証サーバの処理負荷が大きく、また、ワンタイムパスワードを導入してSSOを実現する場合は、パスワードをユーザに再入力させることができないため、トークン(専用の小型装置)の利用等が必要になり、ユーザの負担も大きくなる。
また、認証サーバは、業務サーバA、Bのアクセス毎にユーザ端末との間でやりとりが発生するため、認証サーバの処理負荷が大きく、また、通信負荷も大きくなる。
【0012】
本発明は、前記した課題を解決するためになされたものであり、認証システムにおいて、同じ認証情報のやり取りを最小限に抑えることで不正アクセスによる認証情報の漏洩及びなりすましを防ぎ、ユーザ負荷、および認証サーバの処理負荷と通信負荷を軽減することを目的とする。
【課題を解決するための手段】
【0013】
前記した課題を解決するために、本発明は、ユーザ端末および認証装置とネットワークを介して接続され、第1の処理部と、第2の処理部と、第1の処理部および第2の処理部が共通して使用するサービスを実行する第3の処理部と、を有する業務処理装置である。
第3の処理部は、ユーザ端末から送信されるログイン要求を受けた場合、第1の処理部もしくは第2の処理部から送信される認証要求を受信し、認証装置から取得した認証情報を加工してユーザ端末に送信する認証情報送受信手段を備える。
その他の手段については後記する。
【発明の効果】
【0014】
本発明によれば、認証システムにおいて、同じ認証情報のやり取りを最小限に抑えることで不正アクセスによる認証情報の漏洩及びなりすましを防ぎ、ユーザ負荷、および認証サーバの処理負荷と通信負荷を軽減することことができる。
【図面の簡単な説明】
【0015】
【図1】本発明の実施形態に係るSSO認証システムのシステム構成を示す図である。
【図2】本発明の実施形態に係るSSO認証システムの認証サーバの構成を示すブロック図である。
【図3】本発明の実施形態に係るSSO認証システムの決裁サーバの構成を示すブロック図である。
【図4】本発明の実施形態に係るSSO認証システムの業務サーバAの構成を示すブロック図である。
【図5】本発明の実施形態に係るSSO認証システムの業務サーバBの構成を示すブロック図である。
【図6】本発明の実施形態に係るSSO認証システムの認証装置が管理するユーザ情報DBのデータ構造の一例を示す図である。
【図7】本発明の実施形態に係るSSO認証システムの認証装置が管理する認証情報DBのデータ構造の一例を示す図である。
【図8】本発明の実施形態に係るSSO認証システムの決裁サーバが管理する決裁情報DBのデータ構造の一例を示す図である。
【図9】本発明の実施形態に係るSSO認証システムの決裁サーバが管理する決裁履歴DBのデータ構造の一例を示す図である。
【図10】本発明の実施形態に係るSSO認証システムの業務サーバAが管理する業務処理情報DBのデータ構造の一例を示す図である。
【図11】本発明の実施形態に係るSSO認証システムの業務サーバBが管理する業務処理情報DBのデータ構造の一例を示す図である。
【図12】本発明の実施形態に係るSSO認証システムによるユーザ端末の初回アクセス時の動作を示すシーケンス図である。
【図13】本発明の実施形態に係るSSO認証システムによるユーザ端末の2回目以降のアクセス時の動作を示すシーケンス図である。
【図14】本発明の実施形態に係るSSO認証システムの認証サーバの動作を示すフローチャートである。
【図15】本発明の実施形態に係るSSO認証システムの決裁サーバによる親エージェントの処理動作を示すフローチャートである。
【図16】本発明の実施形態に係るSSO認証システムの決裁サーバによる親エージェントの処理動作を示すフローチャートである。
【図17】本発明の実施形態に係るSSO認証システムの決裁サーバによる親エージェントの処理動作を示すフローチャートである。
【図18】本発明の実施形態に係るSSO認証システムの決裁サーバによる決裁処理動作を示すフローチャートである。
【図19】本発明の実施形態に係るSSO認証システムの業務サーバA(B)による子エージェントの処理動作を示すフローチャートである。
【図20】本発明の実施形態に係るSSO認証システムの決裁サーバによる業務処理動作を示すフローチャートである。
【図21】従来例におけるSSO認証システムの動作を示すシーケンス図である。
【発明を実施するための形態】
【0016】
以下、本発明を実施するための形態(以下、実施形態という。)について、図面を参照して詳細に説明する。なお、本実施形態において、「認証情報(図12のステップS111における「A×L1」に相当)」に対して、その認証情報の元となる情報を「認証キー(図12のステップS108における「A」に相当)」と称する。また、前記した「A×L1」以外に認証に関係する情報(後記する履歴情報など)も、「認証情報」と称する。
【0017】
(SSO認証システム1の構成)
図1に示すように、本発明の実施形態に係るSSO認証システム1において、SSO認証装置としての認証サーバ10と、業務処理装置の第3の処理部としての決裁サーバ11と、業務処理装置の第1の処理部としての業務サーバA(12)と、業務処理装置の第2の処理部としての業務サーバB(13)と、ユーザ端末14とが、ネットワーク15を介して接続され、構成される。
【0018】
本実施形態では、業務サーバA(12)は財務会計、業務サーバB(13)は文書管理を行うものとし、決裁サーバ11は、財務会計と文書管理に共通処理である決裁を行うものとする。決裁サーバ11は、業務サーバA(12)、業務サーバB(13)に対し、共通的なサービスを提供し、各業務サーバから起票される案件のワークフローを一元的に管理するもので、親エージェントが実装される。また、業務サーバA(12)と、業務サーバB(13)には子エージェントが実装される。この親エージェントと子エージェントについての詳細は後記する。
【0019】
認証サーバ10は、決裁サーバ11、業務サーバA(12)、業務サーバB(13)に関して、ユーザ情報、権限情報の管理、および認証処理を一元的に担い、ユーザ端末14に対してSSOを提供する。
また、ユーザ端末14は、ネットワーク15としてのインターネット、もしくはイントラネット内で他のユーザ端末からもアクセスできるネットワーク環境下に配置される。一方、認証サーバ10、決裁サーバ11、業務サーバA(12)、業務サーバB(13)は、イントラネット内でアクセスが制限されたネットワーク環境下に配置されるものとする。ここでは、ユーザ端末14と各サーバ10、11、12、13との通信は、比較的オープンで第三者から監視されやすいネッワーク経由で行われ、各サーバ10、11、12、13間の通信は、比較的クローズで第三者から監視されにくいネットワーク経由で行われるものとする。
【0020】
本発明の実施形態に係るSSO認証システム1は、認証サーバ10の認証キーを、後記するように、業務サーバA、Bの共通処理履歴等、ユーザに固有で更新性のある情報を利用して加工することにより、認証サーバ10の処理負荷を軽減し、ネットワーク15上に同じ認証キーや認証情報を何度も伝播させないようにしてセキュリティ強化を図るものである。
【0021】
なお、図1に示すシステム形態によれば、決裁サーバ11と、業務サーバA(12)と、業務サーバB(13)とは、独立した筐体に実装される業務処理装置として例示されているが、例えば、それらは1個の業務処理装置内にあって、それぞれの機能を有するソフトウエアとして実装されていてもよい。
【0022】
ここでは、決裁サーバ11は、「ユーザ端末14から送信されるログイン要求に基づき、業務サーバA(12)もしくは業務サーバB(13)から送信される認証要求を受信し、認証サーバ10から取得した認証キーをユーザ端末14に送信する際に、認証キーを加工して認証情報として送信する業務処理装置」として機能する(詳細は後記)。
【0023】
(認証サーバ10の構成)
図2に示すように、認証サーバ10は、制御部200と、記憶部201と、入力部202と、表示部203と、ネットワークインタフェース部204とが、アドレス、データ、コントロールのためのラインが複数本実装される内部バス205に共通接続され、構成される。
【0024】
制御部200は、記憶部201に記憶されるプログラム210を逐次読み出し実行することにより、ユーザ情報や権限情報を管理し、また、認証処理を一元的に行うものである。
制御部200は、プログラム210を実行することにより、認証要求を受信した場合、認証情報の有無を判定する。認証情報がある場合に、認証情報に基づく認証処理を行い、認証が成功した場合、認証要求があった業務サーバA(12)もしくは業務サーバB(13)に認証結果を送信する。認証情報がない場合、もしくは認証が不成功の場合、ユーザ端末14にログイン入力画面情報を送信してユーザ情報の入力を促し、入力されたユーザ情報に基づき認証処理を実行し、認証が成功した場合、認証キーを生成して決裁サーバ11に送信する。
【0025】
このため、図2では、制御部200が実行するプログラムの機能を示すように、プログラム210として、ユーザ認証部211と、認証キー生成部212とを示している。
ユーザ認証部211は、認証情報DB222に格納される認証情報に基づき前記した認証処理を実行する機能を有し、認証キー生成部212は、ユーザ情報DB221に登録されたユーザ情報に基づき、例えば、“XYZ001XXXX”(図7)等の認証キーを生成する機能を有する。
【0026】
ユーザ情報DB221は、図6にそのデータ構造の一例を示すように、ユーザID(D10)と、パスワードD11と、A利用フラグD12と、B利用フラグD13の各データ項目からなる。ここで、利用フラグD12、D13は、業務サーバA(12)、B(13)毎に設けられ、ユーザが利用可能か否かを示す情報である。
【0027】
認証情報DB222は、図7にそのデータ構造の一例を示すように、ユーザID(D20)と、認証キーD21と、有効期間D22と、認可システムD23の各データ項目からなる。ここで、認可システムD23には、ユーザ情報DB221の利用フラグD12、D13が「利用する」となっている業務サーバA(12)(B(13))が設定される。
【0028】
なお、図2に示す入力部202と表示部203は、例えば、キーボードディスプレイからなるマンマシン装置である。また、ネットワークインタフェース部204は、ネットワーク15経由で接続される、決裁サーバ11、業務サーバA(12)、業務サーバB(13)、ユーザ端末14との通信インタフェースの機能を司り、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)による通信を行う。
【0029】
(決裁サーバ11の構成)
図3に示すように、決裁サーバ11は、制御部300と、記憶部301と、入力部302と、表示部303と、ネットワークインタフェース部304とが、アドレス、データ、コントロールのためのラインが複数本実装される内部バス305に共通接続され、構成される。
【0030】
制御部300は、記憶部301に記憶される、親エージェント320(親エージェントプログラム)を逐次読み出し実行することにより、ユーザ端末14から送信されるログイン要求に基づき、業務サーバA(12)、もしくは業務サーバB(13)から送信される認証要求を受信し、認証サーバ10から受信した認証キーをユーザ端末14に送信する際に、認証キーを、ユーザに固有で更新性のある情報で暗号化して認証情報として送信する。
このため、制御部300が実行する親エージェントの機能を示すように、親エージェント320として、認証情報送信部321と、認証情報受信部322と、認証要求部323とを示している。
【0031】
このうち、認証情報送信部321と、認証情報受信部322とは、「ユーザ端末14から送信されるログイン要求に基づき、業務サーバA(12)、業務サーバB(13)から送信される認証要求を受信し、認証サーバ10から受信した認証キーをユーザ端末14に送信する際に、認証情報を、ユーザに固有で更新性のある情報で暗号化して送信する認証情報送受信手段」として機能する。
認証要求部323は、認証要求を受信したときに、認証キーがあるか否かを判定し、認証キーがないと判定された場合、認証サーバ10に対し認証要求を送信する機能を有する。
【0032】
また、制御部300は、業務プログラム310を逐次読み出し実行することにより、決裁サーバ11が本来持つ決裁処理機能を実現する。このため、制御部300が実行する業務プログラムの機能を示すように、業務プログラム310として、決裁処理部311と、履歴情報管理部312とを示している。
【0033】
決裁処理部311は、ユーザ端末14からのログインに基づいて業務サーバA(12)、B(13)で処理される決裁要求に基づき、決裁情報DB331に格納された情報を参照しながら決裁処理を行う。また、履歴情報管理部312は、決裁履歴DB332に格納されたユーザに固有の更新性を有する情報を認証情報の一部として管理する。
【0034】
決裁情報DB331は、そのデータ構造の一例を図8に示すように、ユニークな案件ID(D31)と、業務システムD32と、ステータスD33と、案件保持者ID(D34)とをデータ項目として有する。ここでは、案件ID“1000”は、業務サーバA(12)で承認待ちになっており、案件保持者IDはユーザID“001”のユーザであるとしている。
【0035】
また、決裁履歴DB332は、そのデータ構造の一例を図9に示すように、案件ID(D40)と、操作履歴D41と、操作時刻D42と、操作者ID(D43)とをデータ項目として有する。ここでは、案件ID“1000”の1行目は、認証情報の一部として使用される文字列の操作履歴が「起案」であって、この操作時刻が、1/26の15:15:00、そのときの操作者IDが、ユーザID“003”を有するユーザであるとしている。
【0036】
なお、図3に示す入力部302と表示部303は、例えば、キーボードディスプレイからなるマンマシン装置である。また、ネットワークインタフェース部304は、ネットワーク15経由で接続される、認証サーバ10、業務サーバA(12)、業務サーバB(13)、ユーザ端末14との通信インタフェースの機能を司り、例えば、TCP/IPによる通信を行う。
【0037】
(業務サーバAの構成)
図4に示すように、業務サーバA(12)は、制御部400と、記憶部401と、入力部402と、表示部403と、ネットワークインタフェース部404とが、アドレス、データ、コントロールのためのラインが複数本実装される内部バス405に共通接続され、構成される。
【0038】
制御部400は、記憶部401に記憶される、子エージェント420(子エージェントプログラム)を逐次読み出し実行する。具体的に、子エージェント420は、ユーザ端末14からのログイン要求に対し認証情報の有無を判定し、認証情報がある場合、決裁サーバ11から受信した操作履歴等、ユーザに固有で更新性のある情報により認証情報が復号可能か否かを判定する。そして、復号可能である場合に復号処理を行い、復号した認証キーに基づき認証サーバ10に認証要求を送信し、復号ができない場合、決裁サーバ11へ認証キーがない状態で認証要求を送信する。なお、認証情報がない場合もは決裁サーバ11へ認証キーがない状態で認証要求を送信する。
このため、制御部400が実行する子エージェントの機能を示するように、子エージェント420として、認証要求部421と、認証情報復号化部422とを示している。
【0039】
認証要求部421は、認証情報復号化部422で復号した認証キーに基づき認証サーバ10に認証要求を送信し、復号ができない場合、決裁サーバ11へ認証キーがない状態で認証要求を送信する機能を有する。また、認証要求部421は、認証情報がない場合も、決裁サーバ11へ認証キーがない状態で認証要求を送信する機能を有する。
認証情報復号化部422は、ユーザ端末14からのログイン要求に対し認証情報の有無を判定し、認証情報がある場合、決裁サーバ11から受信した操作履歴等、ユーザに固有で更新性のある情報により認証情報が復号可能か否かを判定し、復号可能である場合に復号処理を行う機能を有する。
【0040】
また、制御部400は、業務プログラム410を逐次読み出し実行することにより、業務サーバ12が本来持つ財務処理機能を実現する。
このため、制御部400が実行する業務プログラム410の機能を示すように、業務プログラム410として、業務処理部411と、履歴情報受信部412とを示している。
【0041】
業務処理部411は、ユーザ端末14からの要求に基づき業務処理情報DB431のデータを参照しながら財務処理を行い、結果をユーザ端末14に返す。また、処理結果に基づき業務処理情報DB431の内容を更新する。
図10に示すように、業務処理情報DB431は、伝票ID(D50)と、伝票種別D51と、金額D52と、決裁用案件ID(D53)と、をデータ項目として有する。例えば、伝票ID“A001”は、支払伝票であって、金額が“1000円”、その決裁用案件IDは、“1000”である。
【0042】
なお、履歴情報受信部412は、決裁サーバ11から認証情報の一部として送信される履歴情報を受信して子エージェント420の認証情報復号化部422に引き渡す機能を有する。
【0043】
なお、図4に示す入力部402と表示部403は、例えば、キーボードディスプレイからなるマンマシン装置である。また、ネットワークインタフェース部404は、ネットワーク15経由で接続される、認証サーバ10、決裁サーバ11、業務サーバB(13)、ユーザ端末14との通信インタフェースの機能を司り、例えば、TCP/IPによる通信を行う。
【0044】
(業務サーバBの構成)
図5は、業務サーバB(13)の構成を示すブロック図であるが、図4に示す業務サーバA(12)が財務会計処理を行うのに対し、業務サーバB(13)が文書管理を行うこと以外、ハードウエア、ソフトウエア共に構成や機能が同じであるため、重複説明を適宜省略する。
【0045】
図11に示すように、業務処理情報DB531は、文書ID(D60)と、文書名D61と、添付文書D62と、決裁用案件ID(D63)とをデータ項目として有する。
例えば、文書ID“B001”は、文書名が「議会開催通知」であり、添付ファイルが“Tuuchi.doc”であり、決裁用案件IDが“2000”である。この決裁用案件ID(D63)により、決裁サーバ11が有する決裁情報DB331の案件ID(D31)、あるいは決裁履歴DB332の案件ID(D40)と関連付けられている。
【0046】
(SSO認証システム1の動作)
次に、本発明の実施形態に係るSSO認証システム1の動作について詳細に説明する。なお、図12、図13は、全体フローであって、代表的な動作パターンについて処理内容を示している。また、図14〜図20は、個別の装置の動作フローを示しているので、図12、図13よりも詳細な処理内容を示している。
【0047】
まず、図12のシーケンス図を参照しながら本発明の実施形態に係るSSO認証システム1のユーザ端末14の初回アクセス時の動作について詳細に説明する。
【0048】
まず、ユーザ端末14は、業務サーバA(12)に対して認証情報なしのログイン要求を送信する(ステップS101)。これを受けた業務サーバA(12)は、決裁サーバ11に対し、認証情報なしの認証要求を返し(ステップS102)、決裁サーバ11は、決裁履歴DB332を参照して履歴判定を行う(ステップS103)。
決裁サーバ11は、続いて認証サーバ10に認証情報なしの認証要求を送信し(ステップS104)、これを受けた認証サーバ10は、ユーザ端末14に、ユーザIDとパスワード入力を促すユーザ情報入力画面情報を送信する(ステップS105)。
【0049】
ユーザ端末14には表示画面上にユーザ情報入力画面が表示され、ユーザが、ユーザ端末14を操作することにより、ユーザID、パスワード(Pass)を入力し(ステップS106)、その情報が認証サーバ10に送信される。認証サーバ10は、その情報を受信し、ユーザ情報DB221を参照して認証判定を行う(ステップS107)。ここで、認証が成功すると、認証サーバ10は、決裁サーバ11に対し、認証キー「A」を送信する(ステップS108)。
【0050】
認証キー「A」を受信した決裁サーバ11は、親エージェント320が起動し、認証キー「A」を、先の履歴判定により取得した履歴情報である文字列「L1」で加工し、暗号化して得られる認証情報「A×L1」をユーザ端末14に送信する(ステップS109)。あわせて、決裁サーバ11は、業務サーバA(12)に対して履歴情報「L1」を送信する(ステップS110)。なお、ここで、「A×L」は、「A」、「L」のいずれかで、他方を復元できる特性を持つものとする。
【0051】
続いて、認証情報「A×L1」を受信したユーザ端末14は、業務サーバA(12)に対し、この認証情報に基づくログイン要求を行う(ステップS111)。
これを受けた業務サーバA(12)は、復号処理を行って認証キー「A」を抽出し(ステップS112)、この認証キー「A」に基づき認証サーバ10に認証要求を送信する(ステップS113)。これを受けた認証サーバ10は、既に認証済みであるため、認証結果を示す画面情報を返し(ステップS114)、業務サーバA(12)はこれを受けてユーザ端末14に画面応答(画面レスポンス)を行う(ステップS115)。これによりユーザ端末14は、業務サーバA(12)へのアクセス(操作)が可能になる(ステップS116)。
【0052】
以下、図13のシーケンス図を参照しながら本発明の実施形態に係るSSO認証システム1のユーザ端末14の2回目以降のアクセス時の動作について詳細に説明する。
【0053】
まず、ユーザ端末14は、先に業務サーバA(12)にログインしたときに取得した認証情報「A×L1」に基づき、業務サーバB(13)にログインする(ステップS201)。これを受けた業務サーバB(13)は、決裁サーバ11に対し、認証情報「A×L1」による認証要求を送信する(ステップS202)。
【0054】
決裁サーバ11は、認証要求を受信すると、決裁履歴DB332を参照して履歴判定を行い(ステップS203)、復号化(復号処理)を行う(ステップS204)。続いて、決裁サーバ11は、認証キー「A」を、先の履歴判定により取得した履歴情報「L2」で加工し、暗号化して得られる認証情報「A×L2」をユーザ端末14に送信する(ステップS205)。あわせて、決裁サーバ11は、業務サーバB(13)に対して履歴情報「L2」を送信する(ステップS206)。
【0055】
続いて、認証情報「A×L2」を受信したユーザ端末14は、業務サーバB(13)に対し、この認証情報に基づくログイン要求を行う(ステップS207)。
これを受けた業務サーバB(13)は、復号処理を行って認証キー「A」を抽出し(ステップS208)、この認証キー「A」に基づき認証サーバ10に認証要求を送信する(ステップS209)。これを受けた認証サーバ10は、既に認証済みであるため、認証結果を示す画面情報を返し(ステップS210)、業務サーバB(13)はこれを受けてユーザ端末14に画面応答(画面レスポンス)を行う(ステップS211)。これによりユーザ端末14は、ユーザ情報の入力なしに業務サーバB(13)へのアクセス(操作)が可能になる(ステップS212)。
【0056】
(認証サーバ10の動作)
次に、図14のフローチャートを参照しながら、図2に示す認証サーバ10の処理動作について詳細に説明する。
【0057】
まず、認証サーバ10は、認証要求を受信すると(ステップS301)、ユーザ認証部211が、認証キーの有無(あるか否か)を判定し(ステップS302)、認証キーがある場合に(ステップS302“Yes”)、認証情報DB222を参照して認証キーに基づき認証処理を実施する(ステップS303)。ここで、認証が成功した場合(ステップS305“Yes”)、ユーザ認証部211は、認証要求があった子エージェントを有する業務サーバA(12)、B(13)に認証成功を応答する(ステップS309)。
【0058】
一方、ステップS302で認証キーがないと判定された場合(ステップS302“No”)、もしくは、認証が不成功の場合(ステップS305“No”)、ユーザ認証部211は、ユーザ端末14にログイン入力画面情報を送信してユーザIDとバスワード入力を促し(ステップS304)、入力されたユーザIDとパスワードに基づきユーザ情報DB221と照合して認証処理を実施する(ステップS306)。
【0059】
ここで、認証が成功した場合(ステップS308“Yes”)、認証キー生成部212を起動し、認証キー生成部212は、認証キーの発行処理を行って認証情報DB222に登録し(ステップS310)、あわせて親エージェントを有する決裁サーバ11に送信する(ステップS311)。また、認証が不成功の場合(ステップS308“No”)、ユーザ認証部211は、エラー画面情報を生成して終了する。
【0060】
次に、図15〜図17のフローチャートを参照しながら、図3に示す決裁サーバ11の処理動作について詳細に説明する。
【0061】
図15において、認証情報受信部322は、認証要求を受信し(ステップS401)、認証情報があるか否かを判定する(ステップS402)。
ここで、認証情報がないと判定された場合(ステップS402“No”)、認証要求部323により認証サーバ10に対して認証要求を送信して終了する(ステップS404)。
【0062】
一方、認証情報があると判定された場合(ステップS402“Yes”)、認証情報送信部321は、認証要求があった業務サーバA(12)もしくは業務サーバB(13)が有する業務処理情報DB431、531からユーザに固有で更新性のある最新の情報を検索し認証情報が履歴情報により復号が可能か否かを判定する(ステップS403)。
ここで、復号が可能であると判定された場合(ステップS405“Yes”)、決裁履歴DB332を検索し、検索した最新の情報に基づき、一度復号化した認証キーを再暗号化する(ステップS406)。復号ができないと判定された場合は(ステップS405“No”)、ステップS404の処理へ移行し、認証要求部323により認証サーバ10に対して認証要求を送信して終了する。
【0063】
認証情報送信部321は、前記した再暗号化処理(ステップS406)の後、認証要求のあった業務サーバA(12)もしくは業務サーバB(13)へ最新の情報を送信し(ステップS407)、また、ユーザ端末14へ再暗号化した認証情報を送信する(ステップS408)。なお、前記した認証キーの暗号化および再暗号化は、ランダムハッシュによる方法が考えられる。
【0064】
次に、図16において、認証情報受信部322は、認証サーバ10から認証キーを受信し(ステップS501)、決裁履歴DB332を検索して認証要求のあった業務サーバA(12)もしくは業務サーバB(13)のユーザに固有で更新性のある最新の情報を取得し、受信した認証キーを暗号化する(ステップS502)。
そして、認証情報送信部321は、認証要求のあった業務サーバA(12)もしくは業務サーバB(13)へその最新の履歴を送信し(ステップS503)、また、ユーザ端末14へ、暗号化した認証情報を送信する(ステップS504)。
【0065】
次に、図17において、認証情報受信部322は、ユーザ端末14のログイン要求に基づく認証要求を受信して(ステップS601)、認証情報の有無(あるか否か)を判定する(ステップS602)。ここで、認証情報がないと判定された場合(ステップS602“No”)、認証情報送信部321は、認証サーバ10へ認証情報がない状態で認証要求を送信する(ステップS604)。
一方、認証情報があると判定された場合(ステップS602“Yes”)、決裁履歴DB332を検索して、ユーザに固有で更新の必要がある情報により認証情報が復号可能か否かを判定する(ステップS603)。ここで、復号可能であると判定された場合(ステップS605“Yes”)、復号処理を行い、復号した認証キーに基づいて認証サーバ10に認証要求を送信し(ステップS606)、復号できないと判定された場合(ステップS605“No”)、認証サーバ10へ認証情報(認証キー)がない状態で認証要求を送信する(ステップS604)。
【0066】
以下、図18のフローチャートを参照しながら、図3に示す決裁サーバ11の動作(本来の決裁処理動作)について詳細に説明する。
【0067】
決裁サーバ11は、決裁処理部311が、ユーザ端末14から操作入力があるとこれを受信し(ステップS701)、認証済みか否かを判定する(ステップS702)。
ここで、認証済みであると判定されると(ステップS702“Yes”)、操作入力のあったユーザ端末14に画面応答(画面レスポンス)を返し(ステップS703)、操作内容に応じて決裁情報DB331を更新する(ステップS705)。また、操作内容に応じて決裁履歴DB332も更新する(ステップS706)。なお、認証が未済の場合は(ステップS702“No”)、親エージェント320の認証要求部323に制御が移り、認証要求部323で認証要求処理が行われる(ステップS704)。
【0068】
以下、図19のフローチャートを参照しながら、図4に示す業務サーバA(12)の子エージェント420の動作について詳細に説明する。
【0069】
図19において、子エージェント420は、まず、ユーザ端末14からのログイン要求を受信したときに、認証情報の有無(あるか否か)を判定する(ステップS801)。
ここで、認証情報があると判定された場合(ステップS802“Yes”)、認証情報復号化部422は、決裁サーバ11から受信したユーザに固有で更新性のある情報により認証情報が復号可能か否かを判定する(ステップS803)。復号可能である場合(ステップS805“Yes”)、認証情報復号化部422は復号処理を行い、認証要求部421は、復号した認証キーに基づき認証サーバ10に認証要求を送信する(ステップS807)。
【0070】
復号ができない場合(ステップS805“No”)、認証要求部421は、決裁サーバ11(親エージェント)へ認証情報がある状態で認証要求を送信する(ステップS806)。また、ステップS802で認証情報がないと判定された場合(ステップS802“No”)、認証要求部421は、決裁サーバ11へ認証情報がない状態で認証要求を送信する(ステップS804)。
【0071】
なお、業務サーバB(13)の子エージェント520の動作についても同様であるので、説明を省略する。
【0072】
次に、図20のフローチャートを参照しながら図3に示す決裁サーバ11の業務処理動作について詳細に説明する。
【0073】
図20において、決裁サーバ11は、決裁処理部311が、ユーザ端末14から操作入力があるとこれを受信し(ステップS901)、認証済みか否かを判定する(ステップS902)。
ここで、認証済みであると判定されると(ステップS902“Yes”)、操作入力のあったユーザ端末14に画面応答(画面レスポンス)を返し(ステップS903)、操作内容に応じて決裁情報DB331を更新する(ステップS905)。なお、認証が未済の場合は(ステップS902“No”)、親エージェント320の認証要求部323に制御が移り、認証要求部323で認証要求処理が行われる(ステップS904)。
【0074】
以上説明のように本発明の実施形態に係るSSO認証システム1によれば、決裁サーバ11が、ユーザ端末14から送信されるログイン要求に基づき、業務サーバA(12)、B(13)から送信される認証要求を受信し、認証サーバ10から取得した認証キーをユーザ端末14に送信する際に、認証キーを加工して認証情報として送信することにより、認証サーバ10とユーザ端末14間での認証情報のやり取りを最小限に抑えてセキュリティ性を高め、かつ、認証サーバ10の負荷を軽減することができる。
また、認証キーを加工するにあたり、認証サーバ10から取得した認証キーをユーザに固有で更新性のある任意の情報で暗号化することでワンタイム特性を持たせ、このことにより、不正アクセスによる認証情報の漏洩、およびなりすましを抑制することができる。
【0075】
また、業務サーバA(12)、B(13)のアクセス毎に、認証サーバ10とユーザ端末14との間のやり取りが不要になるため、認証サーバ10の処理負荷、ならびに通信負荷が減少する。
更に、本発明の実施形態に係る業務処理装置によれば、以下に列挙する効果が得られる。
(1)認証キーを加工するにあたり、処理履歴等、従来やり取りしている情報を活用するため、従来のSSO認証システムとシステム全体としてのネットワークトランザクションの変更はない。
(2)決裁サーバ11、業務サーバA(12)、B(13)等、業務処理装置のエージェントの機能追加で実現が可能であり、認証サーバ10を含めシステム構成の変更が不要である。
(3)頻繁に更新される履歴情報を使用して認証キーを暗号化することで、ユーザ端末14と各サーバ10、11、12、13間を同じ認証情報が伝播しないため、ワンタイム要件が満たされ、セキュリティが強化される。
(4)認証サーバ10は、要求に基づき認証キー「A」を発行するだけで済み、認証サーバ10が暗号化する場合に比較して、処理量が少なくて済む。
【0076】
なお、本発明の実施形態に係るSSO認証システム1では、ユーザに固有で更新性のある任意の情報として、処理履歴を用いたが、他に、最終アクセス時刻等、ユーザに関連し、業務サーバA(12)、B(13)とやり取りして更新される情報であれば代替が可能である。
【符号の説明】
【0077】
1…SSO認証システム、10…認証サーバ(認証装置)、11…決裁サーバ、12…業務サーバA、13…業務サーバB、14…ユーザ端末、15…ネットワーク


【特許請求の範囲】
【請求項1】
ネットワークを介してユーザ端末および認証装置と接続され、第1の処理部と、第2の処理部と、前記第1の処理部および前記第2の処理部が共通して使用するサービスを実行する第3の処理部と、を有する業務処理装置であって、
前記第3の処理部は、
前記ユーザ端末から送信されるログイン要求を受けた場合、前記第1の処理部もしくは前記第2の処理部から送信される認証要求を受信し、前記認証装置から取得した認証キーを加工した認証情報を前記ユーザ端末に送信する認証情報送受信手段を備える
ことを特徴とする業務処理装置。
【請求項2】
前記認証情報送受信手段は、
前記認証要求を受信して認証情報があるか否かを判定し、
前記認証情報がないと判定した場合、前記認証装置に対して認証要求を送信し、
前記認証情報があると判定した場合、前記認証要求があった前記第1の処理部もしくは前記第2の処理部が過去に生成したユーザに固有で更新性のある最新の情報を検索し、前記検索した最新の情報に基づき、前記認証情報から抽出した認証キーを暗号化して認証情報として前記ユーザ端末へ送信するとともに、前記認証要求のあった前記第1の処理部もしくは前記第2の処理部へ前記最新の情報を送信する
ことを特徴とする請求項1に記載の業務処理装置。
【請求項3】
前記認証情報送受信手段は、
前記認証装置から認証キーを受信し、
自身のデータベースを検索して前記認証要求のあった前記第1の処理部もしくは前記第2の処理部へ、ユーザに固有で更新性のある最新の情報を送信し、前記ユーザ端末へ、前記認証キーを暗号化した認証情報を送信する
ことを特徴とする請求項1または請求項2に記載の業務処理装置。
【請求項4】
前記認証情報送受信手段は、
前記ユーザ端末のログイン要求に基づく認証要求を受信して認証情報の有無を判定し、
前記認証情報がないと判定した場合、
前記認証装置へ認証キーがない状態で認証要求を送信し、
認証情報があると判定した場合、
自身のデータベースを検索して前記ユーザに固有で更新の必要がある情報により前記認証情報が復号可能か否かを判定し、復号可能であると判定した場合に復号を行い、前記復号した認証キーに基づいて前記認証装置に認証要求を送信し、復号できないと判定した場合、前記認証装置へ認証キーがない状態で認証要求を送信する
ことを特徴とする請求項1から請求項3のいずれか1項に記載の業務処理装置。
【請求項5】
前記第1の処理部もしくは前記第2の処理部は、
前記ユーザ端末からのログイン要求に対し認証情報の有無を判定し、
前記認証情報がある場合、
前記第3の処理部から受信したユーザに固有で更新性のある情報により前記認証情報が復号可能か否かを判定し、復号可能である場合、復号処理を行い、復号した認証キーに基づいて前記認証装置に認証要求を送信し、復号可能でない場合、前記第3の処理部へ認証キーがない状態で認証要求を送信し、
前記認証情報がない場合、
前記第3の処理部へ認証情報がない状態で認証要求を送信することを特徴とする請求項1から請求項4のいずれか1項に記載の業務処理装置。
【請求項6】
ユーザ端末と、
認証装置と、
第1の処理部と、第2の処理部と、前記第1の処理部および前記第2の処理部が共通して使用するサービスを実行する第3の処理部と、を有する業務処理装置と、がネットワークを介して接続され、
前記第3の処理部は、
前記ユーザ端末からのログイン要求を受けた場合、前記第1の処理部もしくは前記第2の処理部から送信される認証要求を受信し、前記認証装置から取得した認証キーを加工した認証情報を前記ユーザ端末に送信する
ことを特徴とする認証システム。
【請求項7】
前記第1の処理部および前記第2の処理部に、前記認証情報を前記認証装置もしくは前記第3の処理部に送信して認証要求を行う子エージェントが実装され、
前記第3の処理部に、前記ユーザ端末からのログイン要求を受けた場合、前記第1の処理部もしくは前記第2の処理部から送信される認証要求を受信し、前記認証装置から取得した認証キーを前記ユーザ端末に送信する際に、前記認証キーを加工した認証情報を送信する親エージェントが実装される
ことを特徴とする請求項6に記載の認証システム。
【請求項8】
前記認証装置は、
前記認証要求を受信すると認証キーの有無を判定し、
前記認証キーがある場合に前記認証キーに基づく認証処理を行い、認証が成功した場合、前記認証要求があった前記第1の処理部もしくは前記第2の処理部に認証結果を応答し、
前記認証キーがない場合、もしくは前記認証が不成功の場合、前記ユーザ端末にログイン入力画面情報を送信してユーザIDとバスワード入力を促し、入力されたユーザIDとパスワードに基づき認証処理を実行し、認証が成功した場合、認証キーを生成して前記第3の処理部に送信する、
ことを特徴とする請求項7に記載の認証システム。
【請求項9】
ユーザ端末と、
認証装置と、
第1の処理部と、第2の処理部と、前記第1の処理部および前記第2の処理部が共通して使用するサービスを実行する第3の処理部と、を有する業務処理装置と、がネットワークを介して接続される認証システムにおける認証方法であって、
前記第3の処理部は、
前記ユーザ端末からのログイン要求を受けた場合、前記第1の処理部もしくは前記第2の処理部から送信される認証要求を受信し、前記認証装置から取得した認証キーを加工した認証情報を前記ユーザ端末に送信する
ことを特徴とする認証方法。
【請求項10】
請求項9に記載の認証方法をコンピュータに実行させるためのプログラム。


【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate


【公開番号】特開2010−225108(P2010−225108A)
【公開日】平成22年10月7日(2010.10.7)
【国際特許分類】
【出願番号】特願2009−74584(P2009−74584)
【出願日】平成21年3月25日(2009.3.25)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】