JP5289104B2 - 認証先選定システム - Google Patents

Description

この発明は、ユーザが企業を跨ってＷｅｂ系業務システムを利用するシステムに関する。

従来のＷｅｂ系クライアント／サーバ型のシステムにおいて、複数の認証システム間のシングルサインオン（１度の認証情報の入力により複数システムが利用可能）については、認証先をあらかじめユーザが入力するものや、双方の認証システムにユーザ情報を保持する方式が一般的である。

例えば、特許文献１の「認証方法および装置、サービス提供方法および装置、情報入力装置」では、認証情報入力時に、ユーザＩＤ、パスワードに加え、認証サーバ情報を入力することで、アクセス先とは異なる認証サーバにて認証処理を可能とすることが記載されている。

現在、企業グループでは、グループ内企業の相乗効果やシステムの共通利用などが進んでいる。このとき、企業グループ共通のシステムを利用したり、各社相互にシステム利用したりすることになる。このようなときには、セキュリティ上、相互の企業における認証システムで本人認証することが一般的である。また、認証システムが認証やアクセス制御に使用する情報は、企業内の個人情報であり、他社に開示できないケースが多いのが一般的である。

特開２００５−１４９３４１号公報

従来技術では以下のような課題があった。従来の認証・認可サーバでは、複数企業のＷｅｂ系業務システムを利用する際にはそれぞれの認証システムにログインして業務を実施する。そのため、シングルサインオンが出来ないなど、ユーザ利便性を損ねる。また、それぞれの企業でユーザ登録をする必要があり、これは社員の個人情報を他社に提供し、二重管理することになるため、セキュリティレベルの低下となる。

この発明は、他企業のユーザ情報を保有せず、あらかじめ決めておいたユーザ情報の条件と認証先により、認証先を決定かつ転送することで認証処理を他企業に移管しつつ、認証結果を保持することでシングルサインオンを行う。

この発明の認証先選定システムは、
認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部を有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける認証先選定装置と、
前記システムを利用するクライアント端末装置と、
認証処理を実行する複数の前記認証装置と
を備え、
前記クライアント端末装置は、
前記認証先選定装置に前記利用リクエストを送信し、
前記認証先選定装置は、
前記利用リクエストを受信し、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより前記利用リクエストに対する認証処理を実行するべき前記認証装置を前記複数の認証装置のなかから選定し、選定された前記認証装置に前記利用リクエストに対する認証処理の実行を依頼し、
選定された前記認証装置は、
前記認証処理を実行して認証結果を前記認証先選定装置に送信し、
前記認証先選定装置は、
前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする。

この発明により、複数企業のＷｅｂ系業務システムを利用する際にも、シングルサインオンで各システムを利用することができる。また、各企業で他の企業の社員のユーザ登録をする必要がなくなり、社員の個人情報を他社に提供する必要がなくなる。

実施の形態１〜５の分散型認証連携システムの概要を説明する図。 実施の形態１における分散型認証連携システム１０のシステム構成図。 実施の形態１における認証処理を示すフローチャート。 実施の形態１における認可処理を示すフローチャート。 図３をシーケンス化した図。 図４をシーケンス化した図。 実施の形態２における分散型認証連携システム２０のシステム構成図。 実施の形態２における認証処理を示すフローチャート。 図８をシーケンス化した図。 実施の形態４における分散型認証連携システム４０のシステム構成図。 実施の形態４におけるクライアント端末がＷｅｂシステム１０００にリクエストを送信した場合の認証処理を示すフローチャート。 実施の形態４におけるクライアント端末がＷｅｂシステム２０００にリクエストを送信した場合の認証処理を示すフローチャート。 図１１をシーケンス化した図。 図１２で認証済みクッキーなしの場合をシーケンス化した図。 図１２で認証済みクッキー有りの場合をシーケンス化した図。 実施の形態５におけるログオフ処理を示すフローチャート。 図１６をシーケンス化した図。 実施の形態６における認証サーバ装置の外観を示す図。 実施の形態６における認証サーバ装置のハードウェア資源の一例を示す図。

実施の形態１．
図１〜図６を参照して実施の形態１を説明する。図１は、実施の形態１〜６で説明する分散型認証連携システムの概要を説明するための図である。図１は、認証サーバ１００〜３００がいずれも同一の認証方式選択テーブル（後述の条件テーブル）を保有している。図１では認証サーバ１００が、リクエストを受信した場合に認証を実行する認証装置を選定する認証先選定装置である。なお、図１は具体的には実施の形態２が該当する。

図１において、Ａ社データセンター及びＡ社拠点は、Ａ株式会社に属する。Ｂ社データセンター及びＢ社拠点は、Ｂ株式会社に属する。企業グループデータセンター（後述の共通センター）とは、Ａ株式会社及びＢ株式会社に属する社員の両社に利用が認められるバックエンドＷｅｂシステム１０００を持つ。また、各社のユーザ情報は、自社の認証リポジトリとして自社で管理される。ユーザ（Ａ会社の社員あるいはＢ会社の社員）は、認証成立を条件にＷｅｂシステム１０００〜３０００を使用することができる。図１の場合は、Ａ社の社員の認証はＡ社の認証サーバ２００が実施し、Ｂ社の社員の認証はＢ社の認証サーバ２００が実施するのであるが、そのため、自身の接続するＷｅｂシステムに対するリクエストを受けた認証サーバは、保有する認証方式選択テーブルを用いて、認証を実行するべき認証サーバを自身も含めて選定する。そして、選定された認証サーバが、リクエストに係るユーザの認証処理を実行する。

すなわち図１において、認証サーバ１００〜３００は、クライアント端末からのリクエストに対して、ユーザＩＤ（ＵＩＤ）、端末ＩＰアドレスなどの条件に応じて、認証方式選択テーブルを参照し、各社の認証サーバに割り振る。図１の場合、それぞれＷｅｂシステム１０００、２０００、３０００を利用したい場合、ユーザはクライアント端末から、Ｗｅｂシステム１０００、２０００、３０００へのリクエストを送信する。その場合、Ｗｅｂシステム１０００、２０００、３０００へのリクエストに対して、それぞれ、認証サーバ１００、２００、３００が認証方式選択テーブルを参照し、認証処理をするべき認証サーバを選定する。なお、Ａ社の社員Ａがクライアント端末ＡからＷｅｂシステム１０００〜３０００のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、Ａ社の認証サーバ２００である。同様に、Ｂ社の社員Ｂがクライアント端末ＢからＷｅｂシステム１０００〜３０００のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、Ｂ社の認証サーバ２００である。このように、他社あるいはセンターのＷｅｂシステムへのリクエストに対しても、社員の認証処理を自社の認証サーバが実施するので、他社に社員の個人情報を渡す必要がなくなり、同時にシングルサインオンも可能となる。

以下はユーザＩＤで認証サーバを割り振る場合の流れを示す。
（１）ユーザＡＡ０００００１は、Ｗｅｂシステム１０００を利用したい場合、Ａ社拠点のクライアント端末Ａにより、企業グループデータセンターの認証サーバ１００にアクセスする。
（２）クライアント端末Ａのログイン画面にて入力されて送信されたユーザＩＤを受信した認証サーバ１００は、認証方式選択テーブルを参照することにより、社員Ａの属するＡ社の認証サーバ２００に認証情報（ユーザＩＤ）を転送する。
（３）認証情報が転送されたＡ社の認証サーバ２００は、社員Ａの認証処理を実施する。
（４）認証が成功した場合には、認証サーバ２００から認証サーバ１００に通知され、認証成功の通知をうけた認証サーバ１００は、各認証サーバで有効と認められる認証済み情報をクライアント端末Ａに発行する。
（５）クライアント端末Ａは、認証済み情報を持っていれば、各認証サーバにアクセスした時に、認証ＯＫと判断され、各Ｗｅｂシステム１０００〜３０００に対してシングルサインオンでアクセス可能となる。
（６）以上のように認証方式選択テーブルを各認証サーバが保有することで、認証に必要な情報を各社で管理したとしても、シングルサインオンが可能となる。また、標準的な方式よりもサーバ間の通信を削減できるので、処理性能を上げるこができる。また、認証済み情報にユーザの属性情報を埋め込むことで、属性情報と、属性情報とアクセス権の対応が記載された後述のアクセス制御情報テーブルとから、各認証サーバでのアクセス制御も可能となる。

図２は、実施の形態１の分散型認証連携システム１０１を示す構成図である。分散型認証連携システム１０１では、共通センター、Ａ社センター、Ｂ社センターが存在する。共通センターは、第１認証サーバ１００を備えている。第１認証サーバ１００は、バックエンドＷｅｂシステム１０１０、バックエンドＷｅｂシステム１０２０に接続している。Ａ社センターは第２認証サーバ２００を備え、Ｂ社センターは第３認証サーバ３００を備えている。なお、以下では第１認証サーバ１００をセンタサーバ１００、第２認証サーバ２００をＡ社サーバ２００、第３認証サーバ３００をＢ社サーバ３００と呼ぶ。

センタサーバ１００は、バックエンドＷｅｂシステム１０１０、１０２０の認証処理を統合し、リバースプロキシ機能として働いている。

（センタサーバ１００の構成）
センタサーバ１００は、第１認証処理部１１０（判断部、認証装置選定部、認証処理依頼部、認証済み情報作成部）、条件テーブル格納部１１１（認証装置選定条件情報格納部）、第１認可処理部１２０（システム管理部）、アクセス制御情報リポジトリ１２１（アクセス制御情報格納部）、通信部１４０（リクエスト受信部）を備えている。

第１認可処理部１２０はバックエンドＷｅｂシステム１０１０，１０２０に接続している。条件テーブル格納部１１１は、条件テーブル（１１１−１）（認証装置選定条件情報）を格納している。アクセス制御情報リポジトリ１２１は、アクセス制御情報テーブル（１２１−１）を格納している。

（１）第１認可処理部１２０は、バックエンドＷｅｂシステム１０１０，１０２０とデータをやりとりする。
（２）通信部１４０は、クライアント端末から、バックエンドＷｅｂシステム１０１０，１０２０の利用を要求するリクエスト（利用リクエスト）を受信する。
（３）条件テーブル格納部１１１に格納される条件テーブル（１１１−１）は、認証処理を実行するべき認証装置の選定条件が定義されている。
（４）第１認証処理部１１０は、通信部１４０によって受信された利用リクエストに、認証済み情報（後述の認証済みクッキー）が含まれているかどうかを判断する。また、認証済み情報が利用リクエストに含まれていないと判断すると、クライアント端末にユーザＩＤ、パスワード等の認証処理に使用する認証情報の送信を要求し、クライアント端末から送信された認証情報と、条件テーブル（１１１−１）とから、リクエストに対する認証処理を実行するべき認証装置を選定する。そして、第１認証処理部１１０は、選定された前記認証装置に、リクエストに対する認証処理の実行を依頼し、選定された前記認証装置から認証結果を受信すると、認証結果が認証成立を示す場合には認証済み情報を作成し、その認証済み情報をクライアント端末に返信する。
（５）アクセス制御情報リポジトリ１２１に格納されたアクセス制御情報テーブル（１２１−１）には、バックエンドＷｅｂシステム１０１０，１０２０へのアクセス制限を示すアクセス権が定義されている。
（６）第１認可処理部１２０は、第１認証処理部１１０によって認証済み情報が利用リクエストに含まれていると判断されると、リクエストに基づいてアクセス制御情報テーブル（１２１−１）を検索することにより、クライアント端末のアクセス権を確認し、確認されたアクセス権の範囲でクライアント端末によるバックエンドＷｅｂシステム１０１０，１０２０へのアクセスを許可する。

（Ａ社サーバ２００、Ｂ社サーバ３００）
Ａ社サーバ２００は、ユーザ情報リポジトリ２１１、第２認証処理部２１０を備えている。Ｂ社サーバ３００は、ユーザ情報リポジトリ３１１、第３認証処理部３１０を備えている。Ａ社サーバ２００は、センタサーバ１００から認証処理の依頼と共にユーザの認証情報（例えばユーザＩＤ、パスワード）を受信すると、正規な認証情報が記載されたユーザ情報リポジトリ２１１のユーザ情報テーブル（２１１−１）を参照して、受信した認証情報が正規なものかどうかの認証処理を実行する。Ｂ社サーバ３００もＡ社サーバ２００と同様である。なお、図２のユーザ情報テーブル（２１１−１）、（３１１−１）には、パスワードの項目は示していないが、パスワードの項目も存在する。

次に動作について説明する。

図３は、実施の形態１において、Ａ社の社員Ａ（本システムのユーザ）が共通センターのセンタサーバ１００を利用して共通センターのバックエンドＷｅｂシステム１０１０にアクセスする際の認証処理時のフローチャートを示す。図２では、認証先選定装置となるのは、センタサーバ１００のみである。図４は、認証処理動作におけるセンタサーバ１００、Ａ社サーバ２００の認可処理時のフローチャートである。図５、図６はそれぞれ図３、図４をシーケンス化した図である。

ユーザＡ（ユーザＩＤ：ＡＡ０００００１）がクライアント端末ＡのＷｅｂブラウザを使用して、バックエンドＷｅｂシステム１０１０へのリクエスト（利用リクエスト）をセンタサーバ１００に送信する（Ｓ１）。センタサーバ１００の通信部１４０は、リクエストを受信する。第１認証処理部１１０が、リクエスト中の認証済み情報（後述の認証済クッキー）の有無により、認証済みかどうかをチェックする（Ｓ２）。認証前の場合、第１認証処理部１１０が通信部１４０を介してログイン画面を送信し、クライアント端末Ａはログイン画面を表示する（Ｓ３）。ユーザＡが、ログイン画面にてユーザＩＤ、パスワードを入力し、クライアント端末Ａが送信する（Ｓ４）。

（センタサーバ１００）
センタサーバ１００の通信部１４０がユーザＡの送信したユーザＩＤ、パスワードを受信し（Ｓ５）、第１認証処理部１１０がユーザＩＤを条件に条件テーブル（１１１−１）から認証先を検索し、決定する（Ｓ６）。ここでは、ユーザＡのユーザＩＤ、パスワードからＡ社サーバ２００が認証サーバとして第１認証処理部１１０により決定される。第１認証処理部１１０は、決定した認証先（Ａ社サーバ２００）に対して、ユーザＩＤ、パスワードを通信部１４０を介して転送する（Ｓ７）。

（Ａ社サーバ２００）
Ａ社サーバ２００はユーザＡのユーザＩＤとパスワードを受信する（Ｓ８）。そして、Ａ社サーバ２００は、ユーザ情報リポジトリ２１１内のユーザ情報テーブル（２１１−１）および受信したユーザＩＤ、パスワードを使用し、認証処理を実施する（Ｓ９）。認証結果を判断し（Ｓ１０）、成功したならば、Ａ社サーバ２００は、ユーザＡのユーザ属性とともに認証済結果を作成し、センタサーバ１００に送信する（Ｓ１１）。Ｓ１０の判断結果、認証失敗ならば、センタサーバ１００へ失敗結果を返し（Ｓ１４）、Ｓ３へ戻る。

（センタサーバ１００）
センタサーバ１００は成功の認証結果を受信すると、第１認証処理部１１０が認証済みクッキー（認証済み情報）を作成し（Ｓ１１−１）、クライアント端末Ａへ認証済みクッキーと共にバックエンドＷｅｂシステム１０１０に自動リダイレクトするページを送信する（Ｓ１２）。

（クライアント端末Ａ）
クライアント端末Ａは、認証済クッキーと共にバックエンドＷｅｂシステム１０１０への自動リクエストをセンタサーバ１００に送信する（Ｓ１３）。

（センタサーバ１００）
センタサーバ１００は、通信部１４０によりクライアント端末Ａからのリクエストを受信し（Ｓ１５）、第１認可処理部１２０により認可処理を実施する。以上で認証処理は完了（Ｓ１６）。

（認可処理）
Ｓ１６以降までの認証処理に続き、図４、図６を参照して、認証が完了したユーザＡが、センタサーバ１００経由で、バックエンドＷｅｂサーバ（バックエンドＷｅｂシステム１０１０）にアクセスするときの認可処理を説明する。認可処理は第１認可処理部１２０による処理である。

（センタサーバ１００）
センタサーバ１００の第１認可処理部１２０は、認証済クッキー内にあるユーザＡの属性情報（個人であるユーザＡを特定する情報ではないが、この情報に付随する付加的な情報）を元に、アクセス制御情報テーブル（１２１−１）を検索し（Ｓ１８）、ユーザＡのアクセス権があるかをチェックする（Ｓ１９）。アクセス権がなければ、第１認可処理部１２０はクライアント端末Ａにアクセスエラー画面を通信部１４０を介して送信し（Ｓ２０）、処理は終了（Ｓ２６）する。アクセス権があれば、第１認可処理部１２０はバックエンドＷｅｂシステム１０１０にリクエストを転送する（Ｓ２１）。その後、バックエンドＷｅｂシステム１０１０は、ユーザ情報によって適切な画面を生成し（Ｓ２２）、センタサーバ１００は、その画面をクライアント端末Ａに送信する（Ｓ２３、Ｓ２４）。クライアント端末Ａが送信された画面を表示して（Ｓ２５）、処理が終了する（Ｓ２６）。

以上のように、センタサーバ１００が条件テーブル（１１１−１）を備えることにより、ユーザからアクセスされるセンタサーバ１００がそのユーザのユーザ情報リポジトリを持たなくても認証処理を適切な認証サーバに転送する。これにより、適切な認証処理が可能となり、自社社員の個人情報を他企業に提供しなくても認証可能となり、個人情報に対するセキュリティを保持できる。

実施の形態２．
図７〜図９を参照して実施の形態２の分散型認証連携システム２０を説明する。実施の形態１ではセンタサーバ１００のみが条件テーブルを保有したが、実施の形態２はセンタサーバ１００の他、Ａ社サーバ２００及びＢサーバ３００も条件テーブルを保有する実施の形態である。すなわち、実施の形態２はセンタサーバ１００、Ａ社サーバ２００、Ｂ社サーバ３００いずれも認証先選定装置の場合の実施の形態である。

図７は、実施の形態２における分散型認証連携システム１１を示す構成図である。図２の分散型認証連携システム１０に対する差異のみを説明する。同じドメインであるセンタサーバ１００とＡ社サーバ２００、Ｂ社サーバ３００と複数あり、各認証サーバは、条件テーブル１１１（１１１−１）、条件テーブル２２２、条件テーブル３３３（３３３−１）を持つ。具体的には、実施の形態２では、センタサーバ１００は分散型認証連携システム１０と同じ構成である。分散型認証連携システム１１におけるＡ社サーバ２００は、分散型認証連携システム１０のセンタサーバ１００がユーザ情報リポジトリを備えた構成である。これは、センタサーバ１００は実際の認証処理は行わないがＡ社サーバ２００は認証処理を実行するからである。Ｂ社サーバ３００はＡ社サーバ２００と同じ構成である。もちろん、Ａ社サーバ２００のユーザ情報リポジトリ２１１はＡ社の社員の個人情報（認証処理に使用する情報）を格納しており、Ｂ社サーバ３００のユーザ情報リポジトリ３１１はＢ社の社員の個人情報を格納している。実施の形態２のＡ社サーバ２００は実施の形態１のセンタサーバ１００と同様の処理を実行するが、相違は、Ａ社サーバ２００は、自身でも認証処理を実行する場合がある点である。すなわちＡ社サーバ２００は、ユーザＡからのリクエストに対しては、条件テーブルを参照した結果、自信が認証処理を行うことになる。Ｂ社サーバ３００もＡ社サーバ２００と同様である。センタサーバ１００の場合はーザ情報リポジトリを持たない前提であるので、認証処理を実行することはない。

図８は、実施の形態２において、Ａ社のユーザＡがセンタサーバ１００経由でＡ社サーバ２００において認証された後、Ｂ社のバックエンドＷｅｂサーバ（バックエンドＷｅｂシステム３０１０）にＢ社サーバ３００経由でアクセスするときの認証処理時のフローチャートを示す。すなわち、ユーザＡは、まずＷｅｂシステム１０１０あるいはＷｅｂシステム１０２０を利用するためセンタサーバ１００にリクエストを送信して認証（Ａ社サーバ２００の実施）を受け、次にバックエンドＷｅｂシステム３０１０あるいはＷｅｂシステム３０２０の利用を希望してＢ社サーバ３００にリクエストを送信した場合である。

Ａ社のユーザＡがセンタサーバ１００経由でＡ社サーバ２００において認証されるときの処理は実施の形態１で述べたとおりである。

次に、図８を参照して、認証済ユーザＡ（Ａ社サーバ２００により認証済み）が、Ｂ社サーバ３００経由でバックエンドＷｅｂサーバ（バックエンドＷｅｂシステム３０１０）にアクセスするときの動作を示す。

（クライアント端末Ａ）
ユーザＡがクライアント端末ＡからリクエストをＢ社サーバ３００に送信する（Ｓ２９）。

（Ｂ社サーバ３００）
Ｂ社サーバ３００は通信部３４０でリクエスト（この例では認証済みクッキーを含む）を受信する（Ｓ３０）。Ｂ社サーバ３００の第３認証処理部３１０は、リクエストに認証済クッキーがあるかどうかをチェックする（Ｓ３１）。第３認証処理部３１０は、証済クッキーがなければ通常の認証処理を実施する（実施の形態１で述べたＳ３〜Ｓ１５）。第３認証処理部３１０は、証済クッキーがあれば、認証済クッキーからユーザＩＤ、セッションＩＤを抽出し（Ｓ３２）、ユーザＩＤ、セッションＩＤと条件テーブル３３３（３３３−１）とから認証先（認証先）を決定する（Ｓ３４）。この例ではＡ社サーバ２００が認証先として決定される。第３認証処理部３１０は、決定した認証先であるＡ社サーバ２００に認証済クッキー情報を通信部３４０から送信する（Ｓ３５）。

（Ａ社サーバ２００）
Ａ社サーバ２００は、通信部２４０で認証済クッキーを受信する（Ｓ３６）。第２認証処理部２１０は、認証済クッキーからユーザＩＤ、セッションＩＤを抽出し（Ｓ３２）、ユーザＡの情報をユーザ情報リポジトリ２１１から取得し（Ｓ３３）、Ｂ社サーバ３００へそのユーザ情報を通信部２４０から送信する（Ｓ３７）。

Ｂ社サーバ３００の通信部３４０がユーザＡの情報を受信すると、第３認可処理部３２０が認可処理を開始する。

以上のように、認証サーバが複数あり、第三者認証サーバにアクセスしてもシングルサインオンと他社ユーザ属性を使用した認可が可能である。

なお、図７では、センタサーバ１００がユーザ情報、条件テーブル、アクセス管理情報を保有するようにしたが、これらの情報は他の装置、あるいはシステムが保有するようにしても構わない。

実施の形態３．
次に実施の形態３を説明する。実施の形態２では、１度認証されれば、クライアント端末を止めない限り、「同じ認証済クッキー」で認証が成功してしまう。そこで、実施の形態３では、認証済クッキーに有効期限を設けることにより、認証後、一定時間経過後に再認証を必要とする実施の形態を示す。

実施の形態３を示す構成図は、実施の形態２の図７と同じであるが、認証成立の際に発行する認証済クッキーに有効期限を設定する。認証済クッキーを生成するのは、クライアント端末からリクエストを受けたサーバである。したがって、このリクエストを受けたサーバの認証処理部は、認証済クッキーを生成する際に認証済クッキーに有効期限を設定する。

実施の形態３における認証処理時のフローはほぼ実施の形態１あるいは２と同様であるが、サーバの認証処理部は、認証済みクッキーのチェックの際（Ｓ２，Ｓ３１等）に有効期限もチェックし、有効期限が来ていれば再認証の処理を実行することとなる。

以上のように、認証済クッキーに有効期限を設けることで、定期的に再認証させることができ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。

実施の形態４．
次に図１０〜図１６を参照して、実施の形態４の分散型認証連携システム４０を説明する。
図１０は、実施の形態４の分散型認証連携システム４０のシステム構成を示す。
図１１は、認証処理の過程を示すフローチャートである。図３等と同じ処理には同じステップ番号を付した。
図１２は、ユーザＡがＷｅｂシステム２０１０にアクセスする場合のフローチャートである。
図１３は、図１１をシーケンス化した図である。
図１４は、図１２で認証済みクッキーなしの場合をシーケンス化した図である。
図１５は、図１２で認証済みクッキー有りの場合をシーケンス化した図である。

以上の実施の形態３では、認証済みクッキーに有効期限を設定することで成りすましの可能性を減らすこととしたが、認証済クッキーを改ざんし、有効期限を長くすることで成りすましされてしまう可能性がある。そこで実施の形態４では、認証処理を現実に実行する認証サーバ（すなわち、Ａ社サーバ２００とＢ社サーバ３００）に認証済みクッキー管理テーブル（認証履歴情報）を備え、有効期限が一致しない場合には、認証済みクッキーを無効とする。

実施の形態４を示す構成図を図１０に示す。Ａ社サーバ２００は、認証クッキー管理テーブル２３０を備える。Ｂ社サーバ３００も備えるが図示はしていない。

実施の形態４における認証処理時のフローは、ユーザＡがＷｅｂシステム１０１０にリクエストを送信する場合であり、ほぼ実施の形態１と同様となる。

（Ａ社サーバ２００）
Ａ社サーバ２００の第２認証処理部２１０は、認証成功後、認証済みクッキー管理テーブル２３０に認証済み情報（認証履歴情報）としてユーザＩＤ、セッションＩＤ、有効期限を書き込む（Ｓ２７）。
第２認証処理部２１０は、ユーザＩＤ、セッションＩＤ、有効期限から生成した認証済通知をセンタサーバ１００に送信する（Ｓ２８）。

（センタサーバ１００）
以降の処理は実施の形態１と同様である。

次に図１４、図１５を参照して、認証済ユーザＡがＡ社サーバ２００経由でバックエンドＷｅｂシステム２０１０（バックエンドＷｅｂサーバ）にアクセスするときの動作を示す。

（クライアント端末Ａ）
ユーザＡがクライアント端末Ａから、Ａ社サーバ２００にリクエストを送信する（Ｓ２９）。

（Ａ社サーバ２００）
Ａ社サーバ２００はリクエストを受信する（Ｓ３０）。Ａ社サーバ２００の第２認証処理部２１０はリクエストに認証済みクッキーがあるかのチェックを行う（Ｓ３１）。第２認証処理部２１０は認証済みクッキーがなければ（図１４の場合）、通常の認証処理を実施する（Ｓ３〜Ｓ１５）。認証済みクッキーが有れば（図１５の場合）、第２認証処理部２１０は認証済みクッキーからユーザＩＤ、セッションＩＤ、有効期限を抽出し（Ｓ３２）、認証済みクッキー管理テーブル２３０に該当レコード（認証履歴情報）があるかをチェックする（Ｓ３３）。なければ通常の認証処理を実施し（Ｓ３〜Ｓ１５）、あれば認可処理へ進む。

以上のように、認証済情報の有効期限を管理することにより、認証済クッキーの改ざんを防ぎ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。

実施の形態５．
図１６、図１７を参照して実施の形態５を説明する。以上の実施の形態では、利用ユーザが明示的にログオフすることが出来ないため、利用後に不正アクセスされる可能性が残っている。そこで実施の形態５は、利用ユーザが明示的にログオフ要求し、認証済みクッキー管理テーブル２３０に記録されている認証済情報（ユーザＩＤ、セッションＩＤ、有効期限などを含む認証履歴情報）を削除する場合を示す。

実施の形態５を示す構成図は、実施の形態２と同じである。

図１６に実施の形態５におけるＡ社サーバ２００で認証処理されたユーザＡがセンタサーバ１００にログオフリクエストを送信した時のフローチャートを示す。図１７は、図１６をシーケンス化した図である。

（クライアント端末Ａ）
ユーザＡがクライアント端末ＡからＷｅｂブラウザを使用して、センタサーバ１００にログオフリクエスト（終了リクエスト）を送信する（Ｓ３８）。つまりクライアント端末Ａからセンタサーバ１００にリクエスト（利用リクエスト）を送信して認証成立した場合である。

（センタサーバ１００）
センタサーバ１００がログオフリクエストを受信する（Ｓ３９）。センタサーバ１００の第１認証処理部１１０は、認証済みクッキーの有無をチェックする（Ｓ３１）。なければ第１認証処理部１１０はクライアント端末Ａに認証済みクッキーがない旨の画面を送信する（Ｓ４４）。あれば、第１認証処理部１１０は、認証済みクッキーからユーザＩＤ、セッションＩＤを抽出する（Ｓ３２）。そして、第１認証処理部１１０は条件テーブル（１１１−１）を参照し、ユーザＩＤをもとに認証先を決定し（Ｓ３４）、認証済みクッキーとともにログオフリクエストを認証先であるＡ社サーバ２００に送信する（Ｓ４０）。

（Ａ社サーバ２００）
Ａ社サーバ２００の通信部２４０はログオフリクエスト付の認証済みクッキーを受信する（Ｓ４１）。第２認証処理部２１０は、認証済みクッキーからユーザＩＤ、セッションＩＤを抽出する（Ｓ３２）。第２認証処理部２１０は、抽出したユーザＩＤ、セッションＩＤの組み合わせが、認証済みクッキー管理テーブル２３０の認証履歴情報として存在するかをチェックする（Ｓ３３）。第２認証処理部２１０は、なければない旨をセンタサーバ１００に送信する（Ｓ４３）。センタサーバ１００は、クライアント端末Ａに認証済情報がない旨の画面を送信する（Ｓ４４）。認証済情報（認証履歴情報）があれば、第２認証処理部２１０は、認証済クッキー管理テーブル２３０の該当エントリ（該当する認証履歴情報）を削除し、ログオフが成功する（Ｓ４２）。Ａ社サーバ２００はログオフ成功をセンタサーバ１００に送信し（Ｓ４５）、センタサーバ１００は、クライアント端末Ａにログオフ成功画面を送信する（Ｓ４６）。

以上のように、利用ユーザの明示的なログオフが可能となり、成りすましなどの不正アクセスの可能性を低減することが可能である。

実施の形態６．
図１８、図１６を参照して実施の形態６を説明する。

実施の形態６は、認証サーバ（センタサーバ１００、Ａ社サーバ２００、Ｂ社サーバ３００）をコンピュータで実現する場合の具体的な形態を説明する。センタサーバ１００、Ａ社サーバ２００、Ｂ社サーバ３００は、センタサーバ１００がユーザ情報（ユーザ情報リポジトリ）を持たない以外は同様の構成であるので、センタサーバ１００を例に説明する。

図１８は、センタサーバ装置の外観の一例を示す図である。図１８において、センタサーバ１００は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、ＦＤＤ８１７（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・ Ｄｒｉｖｅ）、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｄｒｉｖｅ）、プリンタ装置８１９などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。

図１９は、コンピュータで実現されるセンタサーバ１００のハードウェア資源の一例を示す図である。図１９において、センタサーバ１００、プログラムを実行するＣＰＵ８１０（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８１２、表示装置８１３、キーボード８１４、マウス８１５、通信ボード８１６、ＦＤＤ８１７、ＣＤＤ８１８、プリンタ装置８１９、磁気ディスク装置８２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置８２０の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。

ＲＡＭ８１２は、揮発性メモリの一例である。ＲＯＭ８１１、ＦＤＤ８１７、ＣＤＤ８１８、磁気ディスク装置８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード８１６、キーボード８１４、ＦＤＤ８１７などは、入力部、入力装置の一例である。また、通信ボード８１６、表示装置８１３、プリンタ装置８１９などは、出力部、出力装置の一例である。

通信ボード８１６は、ネットワーク（ＬＡＮ等）に接続されている。通信ボード８１６は、ＬＡＮに限らず、インターネット、ＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。

磁気ディスク装置８２０には、オペレーティングシステム８２１（ＯＳ）、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１、ウィンドウシステム８２２により実行される。

上記プログラム群８２３には、以上の実施の形態の説明において「〜部」として説明した機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。

ファイル群８２４には、以上の実施の形態の説明において、「条件テーブル（１１１−１）」、「アクセス制御情報テーブル」、あるいはＡ社サーバ２００であれば、「ユーザ情報」、「認証済みクッキー管理情報」として説明したデータや、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明した情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

また、以上に述べた実施の形態の説明において、データや信号値は、ＲＡＭ８１２のメモリ、ＦＤＤ８１７のフレキシブルディスク、ＣＤＤ８１８のコンパクトディスク、磁気ディスク装置８２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス８２５や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、以上の実施の形態の説明において、「〜部」として説明したものは、「〜手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ＲＯＭ８１１に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以上に述べた「〜部」としてコンピュータを機能させるものである。あるいは、以上に述べた「〜部」の手順や方法をコンピュータに実行させるものである。

以上の実施の形態１〜５では、認証サーバ装置として、装置を説明したが、サーバ装置の動作を、コンピュータに実行させる認証先選定プログラム、あるいは認証先選定プログラムを記録したコンピュータ読み取り可能な記録媒体として把握することも可能である。さらに、認証サーバ装置の動作を認証サーバ装置が行う認証先選定方法として把握することも可能である。

１０，２０，４０ 分散型認証連携システム、１００ センタサーバ、１１０ 第１認証処理部、１１１ 条件テーブル格納部、１１１−１ 条件テーブル、１２０ 第１認可処理部、１２１ アクセス制御情報リポジトリ、１２１−１ アクセス制御情報テーブル、１４０ 通信部、２００ Ａ社サーバ、２１０ 第２認証処理部、２１１ ユーザ情報リポジトリ、２２０ 第２認可処理部、２２１ アクセス制御情報リポジトリ、２２１−１ アクセス制御情報テーブル、２２２ 条件テーブル格納部、２４０ 通信部、３００ Ｂ社サーバ、３１０ 第３認証処理部、３１１ ユーザ情報リポジトリ、３３３ 条件テーブル格納部、３２０ 第３認可処理部、３２１ アクセス制御情報リポジトリ、３４０ 通信部。

Claims (4)

1. 認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部と、認証処理に使用する個人情報を格納するユーザ情報リポジトリとを有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける複数の認証先選定装置と、
   前記システムを利用するクライアント端末装置と
   を備える認証先選定システムであって、
   前記認証装置選定条件情報は、
   前記複数の認証先選定装置が選定対象の前記認証装置として定義されており、
   前記クライアント端末装置は、
   複数の前記認証先選定装置のいずれかに前記利用リクエストを送信し、
   前記認証先選定装置は、
   前記利用リクエストを受信すると、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべきいずれかの前記認証先選定装置を前記複数の認証先選定装置のなかから選定し、選定された前記認証先選定装置に前記利用リクエストに対する認証処理の実行を依頼し、
   選定された前記認証先選定装置は、
   前記ユーザ情報リポジトリに格納された前記個人情報を用いて前記認証処理を実行し、前記認証処理の認証結果を前記認証処理の依頼元の前記認証先選定装置に送信し、
   前記認証処理の依頼元の前記認証先選定装置は、
   前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする認証先選定システム。
2. 前記複数の認証先選定装置の前記認証装置選定条件情報格納部が格納する認証装置選定条件情報は、
   前記選定条件として、ユーザＩＤと前記認証先選定装置との対応関係が定義され、
   前記利用リクエストを受信した認証先選定装置は、
   前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は、前記クライアント端末装置にユーザＩＤとパスワードとの送信を要求し、前記クライアント端末装置から前記ユーザＩＤと前記パスワードとを受信すると、受信した前記ユーザＩＤに対応する前記認証先選定装置を前記認証装置選定条件情報から選定し、選定された前記認証先選定装置に、受信した前記ユーザＩＤと前記パスワードとを送信し、
   選定された前記認証先選定装置は、
   前記ユーザＩＤと前記パスワードとを受信すると、受信した前記ユーザＩＤと前記パスワードと前記ユーザ情報リポジトリに格納された前記個人情報とを用いて前記認証処理を実行し、前記認証処理の認証結果を前記認証処理の依頼元の前記認証先選定装置に送信することを特徴とする請求項１記載の認証先選定システム。
3. 前記選定された認証先選定装置は、
   前記認証処理により認証成立と判断した場合には、前記認証処理の依頼元の前記認証先選定装置によって作成される前記認証済み情報の有効期限を含む認証履歴情報を作成し、記憶することを特徴とする請求項１または２のいずれかに記載の認証先選定システム。
4. 前記クライアント端末装置は、
   前記利用リクエストを送信した前記認証先選定装置に、前記システムの利用終了を要求する終了リクエストを送信し、
   前記認証先選定装置は、
   前記終了リクエストを受信すると、前記終了リクエストに基づき前記認証装置選定条件情報を検索することにより前記終了リクエストに対応する前記選定された認証先選定装置を特定し、特定された前記選定された認証先選定装置に前記終了リクエストを送信し、
   前記選定された認証先選定装置は、
   前記終了リクエストを受信すると、受信された前記終了リクエストに対応する前記認証履歴情報を破棄することを特徴とする請求項３記載の認証先選定システム。

Images