(57)【要約】      （修正有）【課題】繰り返しアクセスするＷＥＢシステム間での認証工程の処理効率を向上できる認証システムを提供する。【解決手段】第１のサーバＡに対して、利用者端末１０１から業務システムＡの利用要求があると、認証手段１０４は認証ＤＢ１０３を利用して利用要求を認証し、引き続き業務システムＡから連携して利用される可能性のあるサーバＢの認証手段１０７に対しても認証を要求する。認証手段１０７は、認証ＤＢ１０６を利用して認証の可否を問い合わせ、ＯＫと判断されると、サーバＢ内にＨＴＴＰセッション１０８を生成して認証を得られた利用者情報と認証済みフラグ１０８１とを記載する。業務システムＡから業務システムＢのソフトウェア資産１０５に対して利用要求が発生すると、認証チェック手段１０９はＨＴＴＰセッション１０８を参照して既に認証が得られている利用者からの要求であるか否かを判断する。【選択図】図１
2012164167.tif 000002
【特許請求の範囲】
【請求項１】
利用者端末と、
前記利用者端末から使用する第１の業務システム、前記利用者端末から前記第１の業務システムの使用要求を受けて利用者情報の認証処理をする第１の認証手段、及び前記第１の認証手段が前記利用者情報を識別するために使用する前記第１の業務システム用の第１の認証データ管理部とを備える第１のサーバと、
前記第１の業務システムから呼び出される第２の業務システム、前記第１の認証手段から予め前記利用者情報の認証要求を受けて認証処理をする第２の認証手段、及び前記第２の認証手段が前記利用者情報を識別するために使用する前記第２の業務システム用の第２の認証データ管理部とを備える１台以上の第２のサーバとを有する認証システムであって、
前記第２の認証手段は、前記第１の認証手段から前記利用者情報の認証要求を最初に受けた時に、前記第２の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、前記第２のサーバに備える認証フラグ管理部に前記利用者情報と認証済フラグの少なくとも一方を記入し、
前記第２の業務システムが、前記第１の業務システムから呼び出される時は、
前記認証フラグ管理部の前記利用者情報又は前記認証済フラグの少なくとも一方の有無をチェックする、前記第２のサーバに備えた認証チェック手段が、前記第２の業務システムの利用の可否を判定することを特徴とする認証システム。
【請求項２】
前記認証フラグ管理部は、前記第２の認証手段が生成するＨＴＴＰセッション又はデータベースであることを特徴とする請求項１に記載の認証システム。
【請求項３】
前記第１の認証データ管理部及び前記第２の認証データ管理部はデータベース又は一覧テーブルであることを特徴とする請求項１又は請求項２に記載の認証システム。
【請求項４】
前記第１のサーバは、前記認証チェック手段が前記認証要求を否と判定した場合に当該判定を受けて、その後の処理を制御する認証エラー制御手段と、
前記認証エラー制御手段が前記処理内容を決定するために用いる認証エラー制御設定ファイルを有することを特徴とする請求項１乃至請求項３のいずれか１項に記載の認証システム。
【請求項５】
前記利用者情報は、利用者端末情報、ユーザ情報、第１のサーバ情報の少なくとも１つを含むことを特徴とする請求項１乃至請求項４のいずれか１項に記載の認証システム。
【請求項６】
前記認証エラー制御設定ファイルは、前記第２の業務システムの一部又は全部の利用権限を有する、利用者端末情報、ユーザ情報、第２のサーバ情報の少なくとも１つを含むことを特徴とする請求項５に記載の認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のＷＥＢシステムがもつソフトウェア資産を連携して新規のＷＥＢシステムを構築する場合に、各ＷＥＢシステムのソフトウェア資産へのアクセスの認証（許可）を行う認証システムに関するものである。
【背景技術】
【０００２】
複数のＷＥＢシステムにおいて、あるＷＥＢシステムから他のＷＥＢシステムのソフトウェア資産をＳＯＡ（Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ−Ａｒｃｈｉｔｅｃｔｕｒｅ）技術によって利用することが可能である。
この場合、不正ユーザからの利用でないかをチェックして認証する技術が必要である。  従来の認証システムにおけるソフトウェア資産の利用については、アクセスの都度、共通鍵や公開鍵を使った認証を行う方式等が利用されている。（例えば、特許文献１）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２１７６２６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の認証システムでは、ＷＥＢシステム上のソフトウェア資産の利用において、複雑な認証鍵や公開鍵といった認証技術の利用が必要であったり、他のサーバへアクセスする都度認証を行う必要があるという問題点があり、多数のＷＥＢシステムを連携する場合に、時間がかかる、煩わしい等の問題があった。
【０００５】
この発明は、上記のような課題を解決するためになされたものであり、認証鍵や公開鍵といった認証技術の利用を必須とせず、繰り返しアクセスするＷＥＢシステム間の認証工程の処理効率の向上を目的とする。
【課題を解決するための手段】
【０００６】
この発明に係る認証システムは、
利用者端末と、
利用者端末から使用する第１の業務システム、利用者端末から第１の業務システムの使用要求を受けて利用者情報の認証処理をする第１の認証手段、及び第１の認証手段が利用者情報を識別するために使用する第１の業務システム用の第１の認証データ管理部とを備える第１のサーバと、
第１の業務システムから呼び出される第２の業務システム、
第１の認証手段から予め利用者情報の認証要求を受けて認証処理をする第２の認証手段、及び第２の認証手段が利用者情報を識別するために使用する第２の業務システム用の第２の認証データ管理部とを備える１台以上の第２のサーバとを有する認証システムであって、
第２の認証手段は、第１の認証手段から利用者情報の認証要求を最初に受けた時に、第２の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第２のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第２の業務システムが、第１の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第２のサーバに備えた認証チェック手段が、第２の業務システムの利用の可否を判定することを特徴とするものである。
【発明の効果】
【０００７】
この発明に係る認証システムは、
第２の認証手段は、第１の認証手段から利用者情報の認証要求を最初に受けた時に、第２の認証データ管理部に当該認証要求の可否を問い合わせ、
認証を可とする場合は、第２のサーバに備える認証フラグ管理部に利用者情報と認証済フラグの少なくとも一方を記入し、
第２の業務システムが、第１の業務システムから呼び出される時は、
認証フラグ管理部の利用者情報又は認証済フラグの少なくとも一方の有無をチェックする、第２のサーバに備えた認証チェック手段が、第２の業務システムの利用の可否を判定することを特徴とするものなので、
ログイン時に認証が通れば、後の業務処理の実行時には認証データベースを使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。
【図面の簡単な説明】
【０００８】
【図１】この発明の実施の形態１に係る認証システムの機能構成（ログイン時）を示す図である。
【図２】この発明の実施の形態１に係る認証システムの動作のフローチャート（ログイン時）を示す図である。
【図３】この発明の実施の形態１に係る認証システムの機能構成（ソフトウェア資産アクセス時）を示図である。
【図４】この発明の実施の形態１に係る認証システムの動作のフローチャート（ソフトウェア資産アクセス時）を示す図である。
【図５】この発明の実施の形態２に係る認証システムの機能構成（ログイン時）を示す図である。
【図６】この発明の実施の形態２に係る認証システムの動作のフローチャート（ログイン時）を示す図である。
【図７】この発明の実施の形態３に係る認証システムの機能構成（ログイン時）を示す図である。
【図８】この発明の実施の形態３に係る認証システムの動作のフローチャート（ログイン時）を示す図である。
【図９】この発明の実施の形態３に係る認証システムの機能構成（ソフトウェア資産アクセス時）を示す図である。
【図１０】この発明の実施の形態３に係る認証システムの動作のフローチャート（ソフトウェア資産アクセス時）を示す図である。
【図１１】この発明の実施の形態４の機能構成（ソフトウェア資産アクセス時）を示す図である。
【図１２】この発明の実施の形態４の動作のフローチャート（ソフトウェア資産アクセス時）を示す図である。
【発明を実施するための形態】
【０００９】
実施の形態１．
以下、この発明の実施の形態１を図１乃至図４に基づいて説明する。
図１は、この発明の実施の形態１に係る認証システム１００の機能構成（ログイン時）と各構成要素間の相互関係を示す図である。
ログイン画面等、利用者側の操作画面をＧＵＩ環境を利用して表示する利用者端末１０１と、利用者が直接使う業務システムＡ（特許請求の範囲では第１の業務システムに相当）が搭載されたサーバＡ（特許請求の範囲では第１のサーバに相当）、業務システムＡから利用されている業務システムＢ（特許請求の範囲では第２の業務システムに相当）のソフトウェア資産１０５が搭載されたサーバＢ（特許請求の範囲では第２のサーバに相当）、及び同様に業務システムＣ（特許請求の範囲では第２の業務システムに相当）のソフトウェア資産１１０が搭載されたサーバＣ（特許請求の範囲では第２のサーバに相当）で構成される。サーバ数は、説明の都合上２台にしているだけであり、同様の構成であれば何台でも接続できる。
【００１０】
図２は、利用者が利用者端末１０１からサーバＡの業務システムＡにログインする時のフローを示す図であり、以下、図１の網掛け部分を主に説明する。（他の図においても同じ）
利用者端末１０１上に表示されるログイン画面にて、ユーザ情報（ユーザＩＤ、パスワード等）を入力し、業務システムＡにログイン（Ｓ２０１）する。
認証手段１０４（特許請求の範囲では第１の認証手段に相当）は、業務システムＡ用の認証データベースである認証ＤＢ１０３（特許請求の範囲では第１の認証データ管理部に相当）を用いてユーザ情報の認証処理を行い（Ｓ２０２）、認証結果（Ｓ２０３）がＯＫであれば、業務システムＢ用の認証手段１０７（特許請求の範囲では第２の認証手段に相当）を呼び出す。この時、サーバＢにはＨＴＴＰセッション１０８（特許請求の範囲では認証フラグ管理部に相当）が生成され、その後、認証手段１０７は、業務システムＢ用の認証データベースである認証ＤＢ１０６（特許請求の範囲では第２の認証データ管理部に相当）を用いてユーザ情報の認証処理を行い（Ｓ２０４）、認証結果（Ｓ２０５）がＯＫであれば、ＨＴＴＰセッション１０８に認証済フラグ１０８１をセット（Ｓ２０６）する。業務システムＣ（特許請求の範囲では第２の業務システムに相当）についても同様の処理（Ｓ２０７〜Ｓ２０９）を行う。各認証処理にて、認証結果がＮＧとなった場合は、エラー画面を利用者端末１０１に表示（Ｓ２１０）する。
【００１１】
次に、図３、図４に基づいて、利用者が業務システムＡを利用し、更にシステムＡから業務システムＢのソフトウェア資産、業務システムＣのソフトウェア資産を使用する場合の動作を説明する。
図３は、認証システム１００において業務システムＡが他のサーバのソフトウェア資産にアクセスする時の機能構成を示す図である。また、図４はソフトウェア資産連携のフローを示す図である。
【００１２】
利用者端末１０１上に表示された業務システムＡの業務画面から利用者が業務システムＡに属する業務処理ａの使用を依頼すると、業務処理ａが実行（Ｓ４０１）される。業務処理ａは、業務システムＢに属する業務処理ｂを担当するソフトウェア資産１０５を使用するために業務処理ｂを呼び出す（Ｓ４０２）のであるが、その時に認証チェック手段１０９が実行（Ｓ４０３）される。認証チェック手段はＨＴＴＰセッション１０８内に認証済フラグ１０８１が存在するか否かをチェックし、チェック結果（Ｓ４０４）がＯＫであれば、業務システムＢのソフトウェア資産１０５を実行（Ｓ４０５）する。業務システムＣのソフトウェア資産の使用についても同様の処理（Ｓ４０６〜４０９）を行う。各認証チェック処理にて、チェック結果がＮＧとなった場合は、エラー画面を表示（Ｓ４１０）する。
【００１３】
この実施の形態１では、ログイン時に認証が通れば、後の業務処理の実行時には認証ＤＢ１０６を使用した認証処理が不要となり、認証が済んでいるか否かのチェックという簡易な仕組みで業務システム間の連携を実現できる。また、認証処理は、各業務システムで個別の方法で行うことができるのでフレキシブルなシステム構成を実現できる。
【００１４】
実施の形態２．
以下、この発明の実施の形態２を図５、図６に基づいて、実施の形態１と異なる部分を説明する。
図５は、認証システム２００の機能構成（ログイン時）を示す図である。
実施の形態１では、業務システムＢ、業務システムＣにて各々認証ＤＢ１０６，１１１を用いた認証処理を実施していたが、実施の形態２では独自の認証ＤＢを不要とした認証手段２０７、２１２を用いる構成となっている。
【００１５】
次に、利用者がログインする時の動作を実施の形態１と異なる部分を説明する。
図６は、実施の形態２に係る認証システム２００の動作のフローチャート（ログイン時）を示す図である。
実施の形態１と異なるところは、認証処理のためのデータベースをシステム毎に実装する必要が無く、認証処理実行（Ｓ６０１、Ｓ６０２）はデータベースの代わりに設けた信頼済みサーバ一覧情報２０６、２１１を利用するところである。
認証手段２０７、２１２は、自身の機能の呼び元のサーバ情報（ここではサーバＡ）をリクエスト情報から取得し、予め信頼できるサーバとして登録されている信頼済みサーバ一覧情報２０６、２１１と比較して、合致した場合に認証結果（Ｓ２０５、Ｓ２０８）をＯＫとする。
ソフトウェア資産アクセス時のその他の動作は、実施の形態１で図４を用いて説明したものと同じである。
【００１６】
この実施の形態２では、各業務システムで個別のデータベースを用いた認証処理までは不要の場合に、簡易に認証処理を実現できる。
【００１７】
実施の形態３．
以下、この発明の実施の形態３を図７乃至図１０に基づいて実施の形態１と異なる部分を説明する。
図７は、実施の形態３に係る認証システム３００の機能構成（ログイン時）を示す図である。
実施の形態１では、認証済みフラグの保持用としてＨＴＴＰセッション１０８を利用していたが、この実施の形態３では、認証手段用ＤＢ３０８を利用する。
【００１８】
次に、図７、図８を用いて、利用者がログインする時の動作を説明する。
図８は、認証システム３００の動作のフローチャート（ログイン時）を示す図である。
実施の形態１と異なるところは、認証処理（Ｂ用、Ｃ用）の実行の後で、認証手段用ＤＢ３０８の認証済情報管理テーブル３１８にユーザＩＤを登録（８０１、８０２）し、これを認証済フラグとして利用する点である。
【００１９】
次に、図９、図１０を用いて、利用者が業務システムＡを利用し、更にシステムＡから業務システムＢのソフトウェア資産、業務システムＣのソフトウェア資産を使用する場合の動作を説明する。
図９は、認証システム３００の機能構成（ソフトウェア資産アクセス時）を示す図である。
また、図１０は、認証システム３００の動作のフローチャート（ソフトウェア資産アクセス時）を示す図である。
【００２０】
実施の形態１と異なるところは、認証チェック（Ｂ）（Ｓ１００１）において、認証チェック手段３０９が、認証手段用ＤＢ３０８に備える認証済情報管理テーブル３１８中に該当のユーザＩＤが存在するか否かの検索を行い、存在する場合にチェック結果をＯＫとする点である。認証チェック（Ｃ）（Ｓ１００２）についても同様である。
【００２１】
この実施の形態３では、認証済情報を識別するためのデータであるユーザＩＤをデータベースに保持するため、実施の形態１で発生するＨＴＴＰセッション１０８のタイムアウトによる認証済フラグ１０８１の消滅という不都合を回避できる。
【００２２】
実施の形態４．
以下、この発明の実施の形態４を図１１に基づいて、実施の形態１と異なる部分を説明する。
図１１は、認証システム４００の機能構成（ソフトウェア資産アクセス時）を示す図である。
実施の形態１では、サーバＢ、Ｃでの認証チェック手段１０９，１１４による認証チェックでエラーが発生した時には、エラー画面を表示していた。
この実施の形態４では、サーバＢ、Ｃ上の認証チェック手段４０９，４１４による認証チェックでエラーが発生した場合でもエラー画面の表示は行わず、サーバＡ上の認証エラー制御手段４１５にその後の判断を委ねる。
【００２３】
次に、図１２を用いて、利用者が業務システムＡを利用し、更にシステムＡから業務システムＢのソフトウェア資産、業務システムＣのソフトウェア資産を使用する場合の動作を説明する。
図１２は、実施の形態４に係る認証システム４００の動作のフローチャート（ソフトウェア資産アクセス時）を示す図である。
【００２４】
実施の形態１と異なるところは、認証チェック（Ｂ，Ｃ）の各ステップ（Ｓ１２０１、Ｓ１２０２）において、認証エラーが発生した場合でもエラー画面の表示を行わず、認証エラー制御（Ｓ１２０３，Ｓ１２０５）を実行する点である。認証エラー制御手段４１５は、認証エラー制御設定ファイル４１６を読み込み、各サーバで認証エラーが発生した場合の後続処理（継続／中止）を判断する。継続と判断した場合は、エラー画面表示は行わず次の処理を実行する。
【００２５】
本実施の形態４におけるログイン時の動作は、実施の形態１、図２で説明したものと同じである。
【００２６】
実施の形態４では、他の業務システムのソフトウェア資産の特性に合わせ、認証エラー時の動作を認証エラー制御設定ファイルに容易に定義できる。
例えば、特定のサーバについてはエラーが発生してもフルアクセスを許可したり、業務システムＢ，Ｃ中の一部の業務処理についてのみ、エラー時でも利用を許可しても良い。
また、利用者情報毎にエラー時の動作を定義しても良い。
認証エラー制御設定ファイルを利用することにより、一時的に認証対象を一括変更できるという利点もある。
なお、この実施の形態４で示した認証エラー制御手段４１５は、先述の実施の形態２、３とも組み合わせて運用可能であり、組み合わされた各実施の形態が持つ効果を合わせて得ることができる。
各実施の形態によって、利用者情報としては利用者端末情報、ユーザ情報（ＩＤ、パスワード）、第１のサーバ情報の少なくとも１つを含むこととなる。
【符号の説明】
【００２７】
１００，２００,３００，４００  認証システム、１０１  利用者端末、
１０３，１０６，１１１  認証ＤＢ、
１０４，１０７，２０７，１１２，２１２  認証手段、
１０５，１１０  ソフトウェア資産、１０８  ＨＴＴＰセッション、
１０８１  認証済フラグ、
１０９，３０９，４０９，１１４，４１４  認証チェック手段、
２０６，２１１  信頼済みサーバ一覧情報、
３０８  認証手段用ＤＢ、３１８  認証済情報管理テーブル、
４１５  認証エラー制御手段、４１６  認証エラー制御設定ファイル。
【図１】
2012164167.tif 000003
【図２】
2012164167.tif 000004
【図３】
2012164167.tif 000005
【図４】
2012164167.tif 000006
【図５】
2012164167.tif 000007
【図６】
2012164167.tif 000008
【図７】
2012164167.tif 000009
【図８】
2012164167.tif 000010
【図９】
2012164167.tif 000011
【図１０】
2012164167.tif 000012
【図１１】
2012164167.tif 000013
【図１２】
2012164167.tif 000014