認証システム
【課題】繰り返しアクセスするWEBシステム間での認証工程の処理効率を向上できる認証システムを提供する。
【解決手段】第1のサーバAに対して、利用者端末101から業務システムAの利用要求があると、認証手段104は認証DB103を利用して利用要求を認証し、引き続き業務システムAから連携して利用される可能性のあるサーバBの認証手段107に対しても認証を要求する。認証手段107は、認証DB106を利用して認証の可否を問い合わせ、OKと判断されると、サーバB内にHTTPセッション108を生成して認証を得られた利用者情報と認証済みフラグ1081とを記載する。業務システムAから業務システムBのソフトウェア資産105に対して利用要求が発生すると、認証チェック手段109はHTTPセッション108を参照して既に認証が得られている利用者からの要求であるか否かを判断する。
【解決手段】第1のサーバAに対して、利用者端末101から業務システムAの利用要求があると、認証手段104は認証DB103を利用して利用要求を認証し、引き続き業務システムAから連携して利用される可能性のあるサーバBの認証手段107に対しても認証を要求する。認証手段107は、認証DB106を利用して認証の可否を問い合わせ、OKと判断されると、サーバB内にHTTPセッション108を生成して認証を得られた利用者情報と認証済みフラグ1081とを記載する。業務システムAから業務システムBのソフトウェア資産105に対して利用要求が発生すると、認証チェック手段109はHTTPセッション108を参照して既に認証が得られている利用者からの要求であるか否かを判断する。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、複数のWEBシステムがもつソフトウェア資産を連携して新規のWEBシステムを構築する場合に、各WEBシステムのソフトウェア資産へのアクセスの認証(許可)を行う認証システムに関するものである。
【背景技術】
【0002】
複数のWEBシステムにおいて、あるWEBシステムから他のWEBシステムのソフトウェア資産をSOA(Service−Oriented−Architecture)技術によって利用することが可能である。
この場合、不正ユーザからの利用でないかをチェックして認証する技術が必要である。 従来の認証システムにおけるソフトウェア資産の利用については、アクセスの都度、共通鍵や公開鍵を使った認証を行う方式等が利用されている。(例えば、特許文献1)
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2008−217626号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
従来の認証システムでは、WEBシステム上のソフトウェア資産の利用において、複雑な認証鍵や公開鍵といった認証技術の利用が必要であったり、他のサーバへアクセスする都度認証を行う必要があるという問題点があり、多数のWEBシステムを連携する場合に、時間がかかる、煩わしい等の問題があった。
【0005】
この発明は、上記のような課題を解決するためになされたものであり、認証鍵や公開鍵といった認証技術の利用を必須とせず、繰り返しアクセスするWEBシステム間の認証工程の処理効率の向上を目的とする。
【課題を解決するための手段】
【0006】
この発明に係る認証システムは、
利用者端末と、
利用者端末から使用する第1の業務システム、利用者端末から第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び第1の認証手段が利用者情報を識別するために使用する第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、
第1の業務システムから呼び出される第2の業務システム、
第1の認証手段から予め利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び第2の認証手段が利用者情報を識別するために使用する第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、
第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第2の業務システムが、第1の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものである。
【発明の効果】
【0007】
この発明に係る認証システムは、
第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第2の業務システムが、第1の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものなので、
ログイン時に認証が通れば、後の業務処理の実行時には認証データベースを使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。
【図面の簡単な説明】
【0008】
【図1】この発明の実施の形態1に係る認証システムの機能構成(ログイン時)を示す図である。
【図2】この発明の実施の形態1に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図3】この発明の実施の形態1に係る認証システムの機能構成(ソフトウェア資産アクセス時)を示図である。
【図4】この発明の実施の形態1に係る認証システムの動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【図5】この発明の実施の形態2に係る認証システムの機能構成(ログイン時)を示す図である。
【図6】この発明の実施の形態2に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図7】この発明の実施の形態3に係る認証システムの機能構成(ログイン時)を示す図である。
【図8】この発明の実施の形態3に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図9】この発明の実施の形態3に係る認証システムの機能構成(ソフトウェア資産アクセス時)を示す図である。
【図10】この発明の実施の形態3に係る認証システムの動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【図11】この発明の実施の形態4の機能構成(ソフトウェア資産アクセス時)を示す図である。
【図12】この発明の実施の形態4の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【発明を実施するための形態】
【0009】
実施の形態1.
以下、この発明の実施の形態1を図1乃至図4に基づいて説明する。
図1は、この発明の実施の形態1に係る認証システム100の機能構成(ログイン時)と各構成要素間の相互関係を示す図である。
ログイン画面等、利用者側の操作画面をGUI環境を利用して表示する利用者端末101と、利用者が直接使う業務システムA(特許請求の範囲では第1の業務システムに相当)が搭載されたサーバA(特許請求の範囲では第1のサーバに相当)、業務システムAから利用されている業務システムB(特許請求の範囲では第2の業務システムに相当)のソフトウェア資産105が搭載されたサーバB(特許請求の範囲では第2のサーバに相当)、及び同様に業務システムC(特許請求の範囲では第2の業務システムに相当)のソフトウェア資産110が搭載されたサーバC(特許請求の範囲では第2のサーバに相当)で構成される。サーバ数は、説明の都合上2台にしているだけであり、同様の構成であれば何台でも接続できる。
【0010】
図2は、利用者が利用者端末101からサーバAの業務システムAにログインする時のフローを示す図であり、以下、図1の網掛け部分を主に説明する。(他の図においても同じ)
利用者端末101上に表示されるログイン画面にて、ユーザ情報(ユーザID、パスワード等)を入力し、業務システムAにログイン(S201)する。
認証手段104(特許請求の範囲では第1の認証手段に相当)は、業務システムA用の認証データベースである認証DB103(特許請求の範囲では第1の認証データ管理部に相当)を用いてユーザ情報の認証処理を行い(S202)、認証結果(S203)がOKであれば、業務システムB用の認証手段107(特許請求の範囲では第2の認証手段に相当)を呼び出す。この時、サーバBにはHTTPセッション108(特許請求の範囲では認証フラグ管理部に相当)が生成され、その後、認証手段107は、業務システムB用の認証データベースである認証DB106(特許請求の範囲では第2の認証データ管理部に相当)を用いてユーザ情報の認証処理を行い(S204)、認証結果(S205)がOKであれば、HTTPセッション108に認証済フラグ1081をセット(S206)する。業務システムC(特許請求の範囲では第2の業務システムに相当)についても同様の処理(S207〜S209)を行う。各認証処理にて、認証結果がNGとなった場合は、エラー画面を利用者端末101に表示(S210)する。
【0011】
次に、図3、図4に基づいて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図3は、認証システム100において業務システムAが他のサーバのソフトウェア資産にアクセスする時の機能構成を示す図である。また、図4はソフトウェア資産連携のフローを示す図である。
【0012】
利用者端末101上に表示された業務システムAの業務画面から利用者が業務システムAに属する業務処理aの使用を依頼すると、業務処理aが実行(S401)される。業務処理aは、業務システムBに属する業務処理bを担当するソフトウェア資産105を使用するために業務処理bを呼び出す(S402)のであるが、その時に認証チェック手段109が実行(S403)される。認証チェック手段はHTTPセッション108内に認証済フラグ1081が存在するか否かをチェックし、チェック結果(S404)がOKであれば、業務システムBのソフトウェア資産105を実行(S405)する。業務システムCのソフトウェア資産の使用についても同様の処理(S406〜409)を行う。各認証チェック処理にて、チェック結果がNGとなった場合は、エラー画面を表示(S410)する。
【0013】
この実施の形態1では、ログイン時に認証が通れば、後の業務処理の実行時には認証DB106を使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。また、認証処理は、各業務システムで個別の方法で行うことができるのでフレキシブルなシステム構成を実現できる。
【0014】
実施の形態2.
以下、この発明の実施の形態2を図5、図6に基づいて、実施の形態1と異なる部分を説明する。
図5は、認証システム200の機能構成(ログイン時)を示す図である。
実施の形態1では、業務システムB、業務システムCにて各々認証DB106,111を用いた認証処理を実施していたが、実施の形態2では独自の認証DBを不要とした認証手段207、212を用いる構成となっている。
【0015】
次に、利用者がログインする時の動作を実施の形態1と異なる部分を説明する。
図6は、実施の形態2に係る認証システム200の動作のフローチャート(ログイン時)を示す図である。
実施の形態1と異なるところは、認証処理のためのデータベースをシステム毎に実装する必要が無く、認証処理実行(S601、S602)はデータベースの代わりに設けた信頼済みサーバ一覧情報206、211を利用するところである。
認証手段207、212は、自身の機能の呼び元のサーバ情報(ここではサーバA)をリクエスト情報から取得し、予め信頼できるサーバとして登録されている信頼済みサーバ一覧情報206、211と比較して、合致した場合に認証結果(S205、S208)をOKとする。
ソフトウェア資産アクセス時のその他の動作は、実施の形態1で図4を用いて説明したものと同じである。
【0016】
この実施の形態2では、各業務システムで個別のデータベースを用いた認証処理までは不要の場合に、簡易に認証処理を実現できる。
【0017】
実施の形態3.
以下、この発明の実施の形態3を図7乃至図10に基づいて実施の形態1と異なる部分を説明する。
図7は、実施の形態3に係る認証システム300の機能構成(ログイン時)を示す図である。
実施の形態1では、認証済みフラグの保持用としてHTTPセッション108を利用していたが、この実施の形態3では、認証手段用DB308を利用する。
【0018】
次に、図7、図8を用いて、利用者がログインする時の動作を説明する。
図8は、認証システム300の動作のフローチャート(ログイン時)を示す図である。
実施の形態1と異なるところは、認証処理(B用、C用)の実行の後で、認証手段用DB308の認証済情報管理テーブル318にユーザIDを登録(801、802)し、これを認証済フラグとして利用する点である。
【0019】
次に、図9、図10を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図9は、認証システム300の機能構成(ソフトウェア資産アクセス時)を示す図である。
また、図10は、認証システム300の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【0020】
実施の形態1と異なるところは、認証チェック(B)(S1001)において、認証チェック手段309が、認証手段用DB308に備える認証済情報管理テーブル318中に該当のユーザIDが存在するか否かの検索を行い、存在する場合にチェック結果をOKとする点である。認証チェック(C)(S1002)についても同様である。
【0021】
この実施の形態3では、認証済情報を識別するためのデータであるユーザIDをデータベースに保持するため、実施の形態1で発生するHTTPセッション108のタイムアウトによる認証済フラグ1081の消滅という不都合を回避できる。
【0022】
実施の形態4.
以下、この発明の実施の形態4を図11に基づいて、実施の形態1と異なる部分を説明する。
図11は、認証システム400の機能構成(ソフトウェア資産アクセス時)を示す図である。
実施の形態1では、サーバB、Cでの認証チェック手段109,114による認証チェックでエラーが発生した時には、エラー画面を表示していた。
この実施の形態4では、サーバB、C上の認証チェック手段409,414による認証チェックでエラーが発生した場合でもエラー画面の表示は行わず、サーバA上の認証エラー制御手段415にその後の判断を委ねる。
【0023】
次に、図12を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図12は、実施の形態4に係る認証システム400の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【0024】
実施の形態1と異なるところは、認証チェック(B,C)の各ステップ(S1201、S1202)において、認証エラーが発生した場合でもエラー画面の表示を行わず、認証エラー制御(S1203,S1205)を実行する点である。認証エラー制御手段415は、認証エラー制御設定ファイル416を読み込み、各サーバで認証エラーが発生した場合の後続処理(継続/中止)を判断する。継続と判断した場合は、エラー画面表示は行わず次の処理を実行する。
【0025】
本実施の形態4におけるログイン時の動作は、実施の形態1、図2で説明したものと同じである。
【0026】
実施の形態4では、他の業務システムのソフトウェア資産の特性に合わせ、認証エラー時の動作を認証エラー制御設定ファイルに容易に定義できる。
例えば、特定のサーバについてはエラーが発生してもフルアクセスを許可したり、業務システムB,C中の一部の業務処理についてのみ、エラー時でも利用を許可しても良い。
また、利用者情報毎にエラー時の動作を定義しても良い。
認証エラー制御設定ファイルを利用することにより、一時的に認証対象を一括変更できるという利点もある。
なお、この実施の形態4で示した認証エラー制御手段415は、先述の実施の形態2、3とも組み合わせて運用可能であり、組み合わされた各実施の形態が持つ効果を合わせて得ることができる。
各実施の形態によって、利用者情報としては利用者端末情報、ユーザ情報(ID、パスワード)、第1のサーバ情報の少なくとも1つを含むこととなる。
【符号の説明】
【0027】
100,200,300,400 認証システム、101 利用者端末、
103,106,111 認証DB、
104,107,207,112,212 認証手段、
105,110 ソフトウェア資産、108 HTTPセッション、
1081 認証済フラグ、
109,309,409,114,414 認証チェック手段、
206,211 信頼済みサーバ一覧情報、
308 認証手段用DB、318 認証済情報管理テーブル、
415 認証エラー制御手段、416 認証エラー制御設定ファイル。
【技術分野】
【0001】
この発明は、複数のWEBシステムがもつソフトウェア資産を連携して新規のWEBシステムを構築する場合に、各WEBシステムのソフトウェア資産へのアクセスの認証(許可)を行う認証システムに関するものである。
【背景技術】
【0002】
複数のWEBシステムにおいて、あるWEBシステムから他のWEBシステムのソフトウェア資産をSOA(Service−Oriented−Architecture)技術によって利用することが可能である。
この場合、不正ユーザからの利用でないかをチェックして認証する技術が必要である。 従来の認証システムにおけるソフトウェア資産の利用については、アクセスの都度、共通鍵や公開鍵を使った認証を行う方式等が利用されている。(例えば、特許文献1)
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2008−217626号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
従来の認証システムでは、WEBシステム上のソフトウェア資産の利用において、複雑な認証鍵や公開鍵といった認証技術の利用が必要であったり、他のサーバへアクセスする都度認証を行う必要があるという問題点があり、多数のWEBシステムを連携する場合に、時間がかかる、煩わしい等の問題があった。
【0005】
この発明は、上記のような課題を解決するためになされたものであり、認証鍵や公開鍵といった認証技術の利用を必須とせず、繰り返しアクセスするWEBシステム間の認証工程の処理効率の向上を目的とする。
【課題を解決するための手段】
【0006】
この発明に係る認証システムは、
利用者端末と、
利用者端末から使用する第1の業務システム、利用者端末から第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び第1の認証手段が利用者情報を識別するために使用する第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、
第1の業務システムから呼び出される第2の業務システム、
第1の認証手段から予め利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び第2の認証手段が利用者情報を識別するために使用する第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、
第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第2の業務システムが、第1の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものである。
【発明の効果】
【0007】
この発明に係る認証システムは、
第2の認証手段は、第1の認証手段から利用者情報の認証要求を最初に受けた時に、第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第2のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第2の業務システムが、第1の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第2のサーバに備えた認証チェック手段が、第2の業務システムの利用の可否を判定することを特徴とするものなので、
ログイン時に認証が通れば、後の業務処理の実行時には認証データベースを使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。
【図面の簡単な説明】
【0008】
【図1】この発明の実施の形態1に係る認証システムの機能構成(ログイン時)を示す図である。
【図2】この発明の実施の形態1に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図3】この発明の実施の形態1に係る認証システムの機能構成(ソフトウェア資産アクセス時)を示図である。
【図4】この発明の実施の形態1に係る認証システムの動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【図5】この発明の実施の形態2に係る認証システムの機能構成(ログイン時)を示す図である。
【図6】この発明の実施の形態2に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図7】この発明の実施の形態3に係る認証システムの機能構成(ログイン時)を示す図である。
【図8】この発明の実施の形態3に係る認証システムの動作のフローチャート(ログイン時)を示す図である。
【図9】この発明の実施の形態3に係る認証システムの機能構成(ソフトウェア資産アクセス時)を示す図である。
【図10】この発明の実施の形態3に係る認証システムの動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【図11】この発明の実施の形態4の機能構成(ソフトウェア資産アクセス時)を示す図である。
【図12】この発明の実施の形態4の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【発明を実施するための形態】
【0009】
実施の形態1.
以下、この発明の実施の形態1を図1乃至図4に基づいて説明する。
図1は、この発明の実施の形態1に係る認証システム100の機能構成(ログイン時)と各構成要素間の相互関係を示す図である。
ログイン画面等、利用者側の操作画面をGUI環境を利用して表示する利用者端末101と、利用者が直接使う業務システムA(特許請求の範囲では第1の業務システムに相当)が搭載されたサーバA(特許請求の範囲では第1のサーバに相当)、業務システムAから利用されている業務システムB(特許請求の範囲では第2の業務システムに相当)のソフトウェア資産105が搭載されたサーバB(特許請求の範囲では第2のサーバに相当)、及び同様に業務システムC(特許請求の範囲では第2の業務システムに相当)のソフトウェア資産110が搭載されたサーバC(特許請求の範囲では第2のサーバに相当)で構成される。サーバ数は、説明の都合上2台にしているだけであり、同様の構成であれば何台でも接続できる。
【0010】
図2は、利用者が利用者端末101からサーバAの業務システムAにログインする時のフローを示す図であり、以下、図1の網掛け部分を主に説明する。(他の図においても同じ)
利用者端末101上に表示されるログイン画面にて、ユーザ情報(ユーザID、パスワード等)を入力し、業務システムAにログイン(S201)する。
認証手段104(特許請求の範囲では第1の認証手段に相当)は、業務システムA用の認証データベースである認証DB103(特許請求の範囲では第1の認証データ管理部に相当)を用いてユーザ情報の認証処理を行い(S202)、認証結果(S203)がOKであれば、業務システムB用の認証手段107(特許請求の範囲では第2の認証手段に相当)を呼び出す。この時、サーバBにはHTTPセッション108(特許請求の範囲では認証フラグ管理部に相当)が生成され、その後、認証手段107は、業務システムB用の認証データベースである認証DB106(特許請求の範囲では第2の認証データ管理部に相当)を用いてユーザ情報の認証処理を行い(S204)、認証結果(S205)がOKであれば、HTTPセッション108に認証済フラグ1081をセット(S206)する。業務システムC(特許請求の範囲では第2の業務システムに相当)についても同様の処理(S207〜S209)を行う。各認証処理にて、認証結果がNGとなった場合は、エラー画面を利用者端末101に表示(S210)する。
【0011】
次に、図3、図4に基づいて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図3は、認証システム100において業務システムAが他のサーバのソフトウェア資産にアクセスする時の機能構成を示す図である。また、図4はソフトウェア資産連携のフローを示す図である。
【0012】
利用者端末101上に表示された業務システムAの業務画面から利用者が業務システムAに属する業務処理aの使用を依頼すると、業務処理aが実行(S401)される。業務処理aは、業務システムBに属する業務処理bを担当するソフトウェア資産105を使用するために業務処理bを呼び出す(S402)のであるが、その時に認証チェック手段109が実行(S403)される。認証チェック手段はHTTPセッション108内に認証済フラグ1081が存在するか否かをチェックし、チェック結果(S404)がOKであれば、業務システムBのソフトウェア資産105を実行(S405)する。業務システムCのソフトウェア資産の使用についても同様の処理(S406〜409)を行う。各認証チェック処理にて、チェック結果がNGとなった場合は、エラー画面を表示(S410)する。
【0013】
この実施の形態1では、ログイン時に認証が通れば、後の業務処理の実行時には認証DB106を使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。また、認証処理は、各業務システムで個別の方法で行うことができるのでフレキシブルなシステム構成を実現できる。
【0014】
実施の形態2.
以下、この発明の実施の形態2を図5、図6に基づいて、実施の形態1と異なる部分を説明する。
図5は、認証システム200の機能構成(ログイン時)を示す図である。
実施の形態1では、業務システムB、業務システムCにて各々認証DB106,111を用いた認証処理を実施していたが、実施の形態2では独自の認証DBを不要とした認証手段207、212を用いる構成となっている。
【0015】
次に、利用者がログインする時の動作を実施の形態1と異なる部分を説明する。
図6は、実施の形態2に係る認証システム200の動作のフローチャート(ログイン時)を示す図である。
実施の形態1と異なるところは、認証処理のためのデータベースをシステム毎に実装する必要が無く、認証処理実行(S601、S602)はデータベースの代わりに設けた信頼済みサーバ一覧情報206、211を利用するところである。
認証手段207、212は、自身の機能の呼び元のサーバ情報(ここではサーバA)をリクエスト情報から取得し、予め信頼できるサーバとして登録されている信頼済みサーバ一覧情報206、211と比較して、合致した場合に認証結果(S205、S208)をOKとする。
ソフトウェア資産アクセス時のその他の動作は、実施の形態1で図4を用いて説明したものと同じである。
【0016】
この実施の形態2では、各業務システムで個別のデータベースを用いた認証処理までは不要の場合に、簡易に認証処理を実現できる。
【0017】
実施の形態3.
以下、この発明の実施の形態3を図7乃至図10に基づいて実施の形態1と異なる部分を説明する。
図7は、実施の形態3に係る認証システム300の機能構成(ログイン時)を示す図である。
実施の形態1では、認証済みフラグの保持用としてHTTPセッション108を利用していたが、この実施の形態3では、認証手段用DB308を利用する。
【0018】
次に、図7、図8を用いて、利用者がログインする時の動作を説明する。
図8は、認証システム300の動作のフローチャート(ログイン時)を示す図である。
実施の形態1と異なるところは、認証処理(B用、C用)の実行の後で、認証手段用DB308の認証済情報管理テーブル318にユーザIDを登録(801、802)し、これを認証済フラグとして利用する点である。
【0019】
次に、図9、図10を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図9は、認証システム300の機能構成(ソフトウェア資産アクセス時)を示す図である。
また、図10は、認証システム300の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【0020】
実施の形態1と異なるところは、認証チェック(B)(S1001)において、認証チェック手段309が、認証手段用DB308に備える認証済情報管理テーブル318中に該当のユーザIDが存在するか否かの検索を行い、存在する場合にチェック結果をOKとする点である。認証チェック(C)(S1002)についても同様である。
【0021】
この実施の形態3では、認証済情報を識別するためのデータであるユーザIDをデータベースに保持するため、実施の形態1で発生するHTTPセッション108のタイムアウトによる認証済フラグ1081の消滅という不都合を回避できる。
【0022】
実施の形態4.
以下、この発明の実施の形態4を図11に基づいて、実施の形態1と異なる部分を説明する。
図11は、認証システム400の機能構成(ソフトウェア資産アクセス時)を示す図である。
実施の形態1では、サーバB、Cでの認証チェック手段109,114による認証チェックでエラーが発生した時には、エラー画面を表示していた。
この実施の形態4では、サーバB、C上の認証チェック手段409,414による認証チェックでエラーが発生した場合でもエラー画面の表示は行わず、サーバA上の認証エラー制御手段415にその後の判断を委ねる。
【0023】
次に、図12を用いて、利用者が業務システムAを利用し、更にシステムAから業務システムBのソフトウェア資産、業務システムCのソフトウェア資産を使用する場合の動作を説明する。
図12は、実施の形態4に係る認証システム400の動作のフローチャート(ソフトウェア資産アクセス時)を示す図である。
【0024】
実施の形態1と異なるところは、認証チェック(B,C)の各ステップ(S1201、S1202)において、認証エラーが発生した場合でもエラー画面の表示を行わず、認証エラー制御(S1203,S1205)を実行する点である。認証エラー制御手段415は、認証エラー制御設定ファイル416を読み込み、各サーバで認証エラーが発生した場合の後続処理(継続/中止)を判断する。継続と判断した場合は、エラー画面表示は行わず次の処理を実行する。
【0025】
本実施の形態4におけるログイン時の動作は、実施の形態1、図2で説明したものと同じである。
【0026】
実施の形態4では、他の業務システムのソフトウェア資産の特性に合わせ、認証エラー時の動作を認証エラー制御設定ファイルに容易に定義できる。
例えば、特定のサーバについてはエラーが発生してもフルアクセスを許可したり、業務システムB,C中の一部の業務処理についてのみ、エラー時でも利用を許可しても良い。
また、利用者情報毎にエラー時の動作を定義しても良い。
認証エラー制御設定ファイルを利用することにより、一時的に認証対象を一括変更できるという利点もある。
なお、この実施の形態4で示した認証エラー制御手段415は、先述の実施の形態2、3とも組み合わせて運用可能であり、組み合わされた各実施の形態が持つ効果を合わせて得ることができる。
各実施の形態によって、利用者情報としては利用者端末情報、ユーザ情報(ID、パスワード)、第1のサーバ情報の少なくとも1つを含むこととなる。
【符号の説明】
【0027】
100,200,300,400 認証システム、101 利用者端末、
103,106,111 認証DB、
104,107,207,112,212 認証手段、
105,110 ソフトウェア資産、108 HTTPセッション、
1081 認証済フラグ、
109,309,409,114,414 認証チェック手段、
206,211 信頼済みサーバ一覧情報、
308 認証手段用DB、318 認証済情報管理テーブル、
415 認証エラー制御手段、416 認証エラー制御設定ファイル。
【特許請求の範囲】
【請求項1】
利用者端末と、
前記利用者端末から使用する第1の業務システム、前記利用者端末から前記第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び前記第1の認証手段が前記利用者情報を識別するために使用する前記第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、
前記第1の業務システムから呼び出される第2の業務システム、前記第1の認証手段から予め前記利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び前記第2の認証手段が前記利用者情報を識別するために使用する前記第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、
前記第2の認証手段は、前記第1の認証手段から前記利用者情報の認証要求を最初に受けた時に、前記第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、前記第2のサーバに備える認証フラグ管理部に前記利用者情報と認証済フラグの少なくとも一方を記入し、
前記第2の業務システムが、前記第1の業務システムから呼び出される時は、
前記認証フラグ管理部の前記利用者情報又は前記認証済フラグの少なくとも一方の有無をチェックする、前記第2のサーバに備えた認証チェック手段が、前記第2の業務システムの利用の可否を判定することを特徴とする認証システム。
【請求項2】
前記認証フラグ管理部は、前記第2の認証手段が生成するHTTPセッション又はデータベースであることを特徴とする請求項1に記載の認証システム。
【請求項3】
前記第1の認証データ管理部及び前記第2の認証データ管理部はデータベース又は一覧テーブルであることを特徴とする請求項1又は請求項2に記載の認証システム。
【請求項4】
前記第1のサーバは、前記認証チェック手段が前記認証要求を否と判定した場合に当該判定を受けて、その後の処理を制御する認証エラー制御手段と、
前記認証エラー制御手段が前記処理内容を決定するために用いる認証エラー制御設定ファイルを有することを特徴とする請求項1乃至請求項3のいずれか1項に記載の認証システム。
【請求項5】
前記利用者情報は、利用者端末情報、ユーザ情報、第1のサーバ情報の少なくとも1つを含むことを特徴とする請求項1乃至請求項4のいずれか1項に記載の認証システム。
【請求項6】
前記認証エラー制御設定ファイルは、前記第2の業務システムの一部又は全部の利用権限を有する、利用者端末情報、ユーザ情報、第2のサーバ情報の少なくとも1つを含むことを特徴とする請求項5に記載の認証システム。
【請求項1】
利用者端末と、
前記利用者端末から使用する第1の業務システム、前記利用者端末から前記第1の業務システムの使用要求を受けて利用者情報の認証処理をする第1の認証手段、及び前記第1の認証手段が前記利用者情報を識別するために使用する前記第1の業務システム用の第1の認証データ管理部とを備える第1のサーバと、
前記第1の業務システムから呼び出される第2の業務システム、前記第1の認証手段から予め前記利用者情報の認証要求を受けて認証処理をする第2の認証手段、及び前記第2の認証手段が前記利用者情報を識別するために使用する前記第2の業務システム用の第2の認証データ管理部とを備える1台以上の第2のサーバとを有する認証システムであって、
前記第2の認証手段は、前記第1の認証手段から前記利用者情報の認証要求を最初に受けた時に、前記第2の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、前記第2のサーバに備える認証フラグ管理部に前記利用者情報と認証済フラグの少なくとも一方を記入し、
前記第2の業務システムが、前記第1の業務システムから呼び出される時は、
前記認証フラグ管理部の前記利用者情報又は前記認証済フラグの少なくとも一方の有無をチェックする、前記第2のサーバに備えた認証チェック手段が、前記第2の業務システムの利用の可否を判定することを特徴とする認証システム。
【請求項2】
前記認証フラグ管理部は、前記第2の認証手段が生成するHTTPセッション又はデータベースであることを特徴とする請求項1に記載の認証システム。
【請求項3】
前記第1の認証データ管理部及び前記第2の認証データ管理部はデータベース又は一覧テーブルであることを特徴とする請求項1又は請求項2に記載の認証システム。
【請求項4】
前記第1のサーバは、前記認証チェック手段が前記認証要求を否と判定した場合に当該判定を受けて、その後の処理を制御する認証エラー制御手段と、
前記認証エラー制御手段が前記処理内容を決定するために用いる認証エラー制御設定ファイルを有することを特徴とする請求項1乃至請求項3のいずれか1項に記載の認証システム。
【請求項5】
前記利用者情報は、利用者端末情報、ユーザ情報、第1のサーバ情報の少なくとも1つを含むことを特徴とする請求項1乃至請求項4のいずれか1項に記載の認証システム。
【請求項6】
前記認証エラー制御設定ファイルは、前記第2の業務システムの一部又は全部の利用権限を有する、利用者端末情報、ユーザ情報、第2のサーバ情報の少なくとも1つを含むことを特徴とする請求項5に記載の認証システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2012−164167(P2012−164167A)
【公開日】平成24年8月30日(2012.8.30)
【国際特許分類】
【出願番号】特願2011−24498(P2011−24498)
【出願日】平成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 ]