認証先選定システム及び認証先選定装置及び認証先選定プログラム及び記録媒体
【課題】複数企業のWeb系業務システムでは各認証システムにログインするためシングルサインオンができない、また各企業でユーザ登録する必要があり、自社の社員の個人情報を他社に提供する必要がある。
【解決手段】センタサーバ100は認証装置を選定する条件テーブルを有し、バックエンドWebシステム1010等を管理し、このシステム利用を要求するリクエストを受信する。クライアント端末Aがリクエストを送信すると、センタサーバ100はリクエストを受信し、リクエストに認証済みクッキー情報があるかを判断し、ない場合はリクエストに基づき条件テーブルを検索して認証処理を実行する認証装置を選定し、選定した認証装置に認証処理を依頼する。選定された認証装置は認証処理を行い認証結果をセンタサーバ100に返す。センタサーバ100は認証結果を受信し、認証成立の場合には認証済みクッキーを作成してクライアント端末Aに送信する。
【解決手段】センタサーバ100は認証装置を選定する条件テーブルを有し、バックエンドWebシステム1010等を管理し、このシステム利用を要求するリクエストを受信する。クライアント端末Aがリクエストを送信すると、センタサーバ100はリクエストを受信し、リクエストに認証済みクッキー情報があるかを判断し、ない場合はリクエストに基づき条件テーブルを検索して認証処理を実行する認証装置を選定し、選定した認証装置に認証処理を依頼する。選定された認証装置は認証処理を行い認証結果をセンタサーバ100に返す。センタサーバ100は認証結果を受信し、認証成立の場合には認証済みクッキーを作成してクライアント端末Aに送信する。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、ユーザが企業を跨ってWeb系業務システムを利用するシステムに関する。
【背景技術】
【0002】
従来のWeb系クライアント/サーバ型のシステムにおいて、複数の認証システム間のシングルサインオン(1度の認証情報の入力により複数システムが利用可能)については、認証先をあらかじめユーザが入力するものや、双方の認証システムにユーザ情報を保持する方式が一般的である。
【0003】
例えば、特許文献1の「認証方法および装置、サービス提供方法および装置、情報入力装置」では、認証情報入力時に、ユーザID、パスワードに加え、認証サーバ情報を入力することで、アクセス先とは異なる認証サーバにて認証処理を可能とすることが記載されている。
【0004】
現在、企業グループでは、グループ内企業の相乗効果やシステムの共通利用などが進んでいる。このとき、企業グループ共通のシステムを利用したり、各社相互にシステム利用したりすることになる。このようなときには、セキュリティ上、相互の企業における認証システムで本人認証することが一般的である。また、認証システムが認証やアクセス制御に使用する情報は、企業内の個人情報であり、他社に開示できないケースが多いのが一般的である。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2005−149341号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
従来技術では以下のような課題があった。従来の認証・認可サーバでは、複数企業のWeb系業務システムを利用する際にはそれぞれの認証システムにログインして業務を実施する。そのため、シングルサインオンが出来ないなど、ユーザ利便性を損ねる。また、それぞれの企業でユーザ登録をする必要があり、これは社員の個人情報を他社に提供し、二重管理することになるため、セキュリティレベルの低下となる。
【0007】
この発明は、他企業のユーザ情報を保有せず、あらかじめ決めておいたユーザ情報の条件と認証先により、認証先を決定かつ転送することで認証処理を他企業に移管しつつ、認証結果を保持することでシングルサインオンを行う。
【課題を解決するための手段】
【0008】
この発明の認証先選定システムは、
認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部を有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける認証先選定装置と、
前記システムを利用するクライアント端末装置と、
認証処理を実行する複数の前記認証装置と
を備え、
前記クライアント端末装置は、
前記認証先選定装置に前記利用リクエストを送信し、
前記認証先選定装置は、
前記利用リクエストを受信し、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより前記利用リクエストに対する認証処理を実行するべき前記認証装置を前記複数の認証装置のなかから選定し、選定された前記認証装置に前記利用リクエストに対する認証処理の実行を依頼し、
選定された前記認証装置は、
前記認証処理を実行して認証結果を前記認証先選定装置に送信し、
前記認証先選定装置は、
前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする。
【発明の効果】
【0009】
この発明により、複数企業のWeb系業務システムを利用する際にも、シングルサインオンで各システムを利用することができる。また、各企業で他の企業の社員のユーザ登録をする必要がなくなり、社員の個人情報を他社に提供する必要がなくなる。
【図面の簡単な説明】
【0010】
【図1】実施の形態1〜5の分散型認証連携システムの概要を説明する図。
【図2】実施の形態1における分散型認証連携システム10のシステム構成図。
【図3】実施の形態1における認証処理を示すフローチャート。
【図4】実施の形態1における認可処理を示すフローチャート。
【図5】図3をシーケンス化した図。
【図6】図4をシーケンス化した図。
【図7】実施の形態2における分散型認証連携システム20のシステム構成図。
【図8】実施の形態2における認証処理を示すフローチャート。
【図9】図8をシーケンス化した図。
【図10】実施の形態4における分散型認証連携システム40のシステム構成図。
【図11】実施の形態4におけるクライアント端末がWebシステム1000にリクエストを送信した場合の認証処理を示すフローチャート。
【図12】実施の形態4におけるクライアント端末がWebシステム2000にリクエストを送信した場合の認証処理を示すフローチャート。
【図13】図11をシーケンス化した図。
【図14】図12で認証済みクッキーなしの場合をシーケンス化した図。
【図15】図12で認証済みクッキー有りの場合をシーケンス化した図。
【図16】実施の形態5におけるログオフ処理を示すフローチャート。
【図17】図16をシーケンス化した図。
【図18】実施の形態6における認証サーバ装置の外観を示す図。
【図19】実施の形態6における認証サーバ装置のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【0011】
実施の形態1.
図1〜図6を参照して実施の形態1を説明する。図1は、実施の形態1〜6で説明する分散型認証連携システムの概要を説明するための図である。図1は、認証サーバ100〜300がいずれも同一の認証方式選択テーブル(後述の条件テーブル)を保有している。図1では認証サーバ100が、リクエストを受信した場合に認証を実行する認証装置を選定する認証先選定装置である。なお、図1は具体的には実施の形態2が該当する。
【0012】
図1において、A社データセンター及びA社拠点は、A株式会社に属する。B社データセンター及びB社拠点は、B株式会社に属する。企業グループデータセンター(後述の共通センター)とは、A株式会社及びB株式会社に属する社員の両社に利用が認められるバックエンドWebシステム1000を持つ。また、各社のユーザ情報は、自社の認証リポジトリとして自社で管理される。ユーザ(A会社の社員あるいはB会社の社員)は、認証成立を条件にWebシステム1000〜3000を使用することができる。図1の場合は、A社の社員の認証はA社の認証サーバ200が実施し、B社の社員の認証はB社の認証サーバ200が実施するのであるが、そのため、自身の接続するWebシステムに対するリクエストを受けた認証サーバは、保有する認証方式選択テーブルを用いて、認証を実行するべき認証サーバを自身も含めて選定する。そして、選定された認証サーバが、リクエストに係るユーザの認証処理を実行する。
【0013】
すなわち図1において、認証サーバ100〜300は、クライアント端末からのリクエストに対して、ユーザID(UID)、端末IPアドレスなどの条件に応じて、認証方式選択テーブルを参照し、各社の認証サーバに割り振る。図1の場合、それぞれWebシステム1000、2000、3000を利用したい場合、ユーザはクライアント端末から、Webシステム1000、2000、3000へのリクエストを送信する。その場合、Webシステム1000、2000、3000へのリクエストに対して、それぞれ、認証サーバ100、200、300が認証方式選択テーブルを参照し、認証処理をするべき認証サーバを選定する。なお、A社の社員Aがクライアント端末AからWebシステム1000〜3000のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、A社の認証サーバ200である。同様に、B社の社員Bがクライアント端末BからWebシステム1000〜3000のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、B社の認証サーバ200である。このように、他社あるいはセンターのWebシステムへのリクエストに対しても、社員の認証処理を自社の認証サーバが実施するので、他社に社員の個人情報を渡す必要がなくなり、同時にシングルサインオンも可能となる。
【0014】
以下はユーザIDで認証サーバを割り振る場合の流れを示す。
(1)ユーザAA000001は、Webシステム1000を利用したい場合、A社拠点のクライアント端末Aにより、企業グループデータセンターの認証サーバ100にアクセスする。
(2)クライアント端末Aのログイン画面にて入力されて送信されたユーザIDを受信した認証サーバ100は、認証方式選択テーブルを参照することにより、社員Aの属するA社の認証サーバ200に認証情報(ユーザID)を転送する。
(3)認証情報が転送されたA社の認証サーバ200は、社員Aの認証処理を実施する。
(4)認証が成功した場合には、認証サーバ200から認証サーバ100に通知され、認証成功の通知をうけた認証サーバ100は、各認証サーバで有効と認められる認証済み情報をクライアント端末Aに発行する。
(5)クライアント端末Aは、認証済み情報を持っていれば、各認証サーバにアクセスした時に、認証OKと判断され、各Webシステム1000〜3000に対してシングルサインオンでアクセス可能となる。
(6)以上のように認証方式選択テーブルを各認証サーバが保有することで、認証に必要な情報を各社で管理したとしても、シングルサインオンが可能となる。また、標準的な方式よりもサーバ間の通信を削減できるので、処理性能を上げるこができる。また、認証済み情報にユーザの属性情報を埋め込むことで、属性情報と、属性情報とアクセス権の対応が記載された後述のアクセス制御情報テーブルとから、各認証サーバでのアクセス制御も可能となる。
【0015】
図2は、実施の形態1の分散型認証連携システム101を示す構成図である。分散型認証連携システム101では、共通センター、A社センター、B社センターが存在する。共通センターは、第1認証サーバ100を備えている。第1認証サーバ100は、バックエンドWebシステム1010、バックエンドWebシステム1020に接続している。A社センターは第2認証サーバ200を備え、B社センターは第3認証サーバ300を備えている。なお、以下では第1認証サーバ100をセンタサーバ100、第2認証サーバ200をA社サーバ200、第3認証サーバ300をB社サーバ300と呼ぶ。
【0016】
センタサーバ100は、バックエンドWebシステム1010、1020の認証処理を統合し、リバースプロキシ機能として働いている。
【0017】
(センタサーバ100の構成)
センタサーバ100は、第1認証処理部110(判断部、認証装置選定部、認証処理依頼部、認証済み情報作成部)、条件テーブル格納部111(認証装置選定条件情報格納部)、第1認可処理部120(システム管理部)、アクセス制御情報リポジトリ121(アクセス制御情報格納部)、通信部140(リクエスト受信部)を備えている。
【0018】
第1認可処理部120はバックエンドWebシステム1010,1020に接続している。条件テーブル格納部111は、条件テーブル(111−1)(認証装置選定条件情報)を格納している。アクセス制御情報リポジトリ121は、アクセス制御情報テーブル(121−1)を格納している。
【0019】
(1)第1認可処理部120は、バックエンドWebシステム1010,1020とデータをやりとりする。
(2)通信部140は、クライアント端末から、バックエンドWebシステム1010,1020の利用を要求するリクエスト(利用リクエスト)を受信する。
(3)条件テーブル格納部111に格納される条件テーブル(111−1)は、認証処理を実行するべき認証装置の選定条件が定義されている。
(4)第1認証処理部110は、通信部140によって受信された利用リクエストに、認証済み情報(後述の認証済みクッキー)が含まれているかどうかを判断する。また、認証済み情報が利用リクエストに含まれていないと判断すると、クライアント端末にユーザID、パスワード等の認証処理に使用する認証情報の送信を要求し、クライアント端末から送信された認証情報と、条件テーブル(111−1)とから、リクエストに対する認証処理を実行するべき認証装置を選定する。そして、第1認証処理部110は、選定された前記認証装置に、リクエストに対する認証処理の実行を依頼し、選定された前記認証装置から認証結果を受信すると、認証結果が認証成立を示す場合には認証済み情報を作成し、その認証済み情報をクライアント端末に返信する。
(5)アクセス制御情報リポジトリ121に格納されたアクセス制御情報テーブル(121−1)には、バックエンドWebシステム1010,1020へのアクセス制限を示すアクセス権が定義されている。
(6)第1認可処理部120は、第1認証処理部110によって認証済み情報が利用リクエストに含まれていると判断されると、リクエストに基づいてアクセス制御情報テーブル(121−1)を検索することにより、クライアント端末のアクセス権を確認し、確認されたアクセス権の範囲でクライアント端末によるバックエンドWebシステム1010,1020へのアクセスを許可する。
【0020】
(A社サーバ200、B社サーバ300)
A社サーバ200は、ユーザ情報リポジトリ211、第2認証処理部210を備えている。B社サーバ300は、ユーザ情報リポジトリ311、第3認証処理部310を備えている。A社サーバ200は、センタサーバ100から認証処理の依頼と共にユーザの認証情報(例えばユーザID、パスワード)を受信すると、正規な認証情報が記載されたユーザ情報リポジトリ211のユーザ情報テーブル(211−1)を参照して、受信した認証情報が正規なものかどうかの認証処理を実行する。B社サーバ300もA社サーバ200と同様である。なお、図2のユーザ情報テーブル(211−1)、(311−1)には、パスワードの項目は示していないが、パスワードの項目も存在する。
【0021】
次に動作について説明する。
【0022】
図3は、実施の形態1において、A社の社員A(本システムのユーザ)が共通センターのセンタサーバ100を利用して共通センターのバックエンドWebシステム1010にアクセスする際の認証処理時のフローチャートを示す。図2では、認証先選定装置となるのは、センタサーバ100のみである。図4は、認証処理動作におけるセンタサーバ100、A社サーバ200の認可処理時のフローチャートである。図5、図6はそれぞれ図3、図4をシーケンス化した図である。
【0023】
ユーザA(ユーザID:AA000001)がクライアント端末AのWebブラウザを使用して、バックエンドWebシステム1010へのリクエスト(利用リクエスト)をセンタサーバ100に送信する(S1)。センタサーバ100の通信部140は、リクエストを受信する。第1認証処理部110が、リクエスト中の認証済み情報(後述の認証済クッキー)の有無により、認証済みかどうかをチェックする(S2)。認証前の場合、第1認証処理部110が通信部140を介してログイン画面を送信し、クライアント端末Aはログイン画面を表示する(S3)。ユーザAが、ログイン画面にてユーザID、パスワードを入力し、クライアント端末Aが送信する(S4)。
【0024】
(センタサーバ100)
センタサーバ100の通信部140がユーザAの送信したユーザID、パスワードを受信し(S5)、第1認証処理部110がユーザIDを条件に条件テーブル(111−1)から認証先を検索し、決定する(S6)。ここでは、ユーザAのユーザID、パスワードからA社サーバ200が認証サーバとして第1認証処理部110により決定される。第1認証処理部110は、決定した認証先(A社サーバ200)に対して、ユーザID、パスワードを通信部140を介して転送する(S7)。
【0025】
(A社サーバ200)
A社サーバ200はユーザAのユーザIDとパスワードを受信する(S8)。そして、A社サーバ200は、ユーザ情報リポジトリ211内のユーザ情報テーブル(211−1)および受信したユーザID、パスワードを使用し、認証処理を実施する(S9)。認証結果を判断し(S10)、成功したならば、A社サーバ200は、ユーザAのユーザ属性とともに認証済結果を作成し、センタサーバ100に送信する(S11)。S10の判断結果、認証失敗ならば、センタサーバ100へ失敗結果を返し(S14)、S3へ戻る。
【0026】
(センタサーバ100)
センタサーバ100は成功の認証結果を受信すると、第1認証処理部110が認証済みクッキー(認証済み情報)を作成し(S11−1)、クライアント端末Aへ認証済みクッキーと共にバックエンドWebシステム1010に自動リダイレクトするページを送信する(S12)。
【0027】
(クライアント端末A)
クライアント端末Aは、認証済クッキーと共にバックエンドWebシステム1010への自動リクエストをセンタサーバ100に送信する(S13)。
【0028】
(センタサーバ100)
センタサーバ100は、通信部140によりクライアント端末Aからのリクエストを受信し(S15)、第1認可処理部120により認可処理を実施する。以上で認証処理は完了(S16)。
【0029】
(認可処理)
S16以降までの認証処理に続き、図4、図6を参照して、認証が完了したユーザAが、センタサーバ100経由で、バックエンドWebサーバ(バックエンドWebシステム1010)にアクセスするときの認可処理を説明する。認可処理は第1認可処理部120による処理である。
【0030】
(センタサーバ100)
センタサーバ100の第1認可処理部120は、認証済クッキー内にあるユーザAの属性情報(個人であるユーザAを特定する情報ではないが、この情報に付随する付加的な情報)を元に、アクセス制御情報テーブル(121−1)を検索し(S18)、ユーザAのアクセス権があるかをチェックする(S19)。アクセス権がなければ、第1認可処理部120はクライアント端末Aにアクセスエラー画面を通信部140を介して送信し(S20)、処理は終了(S26)する。アクセス権があれば、第1認可処理部120はバックエンドWebシステム1010にリクエストを転送する(S21)。その後、バックエンドWebシステム1010は、ユーザ情報によって適切な画面を生成し(S22)、センタサーバ100は、その画面をクライアント端末Aに送信する(S23、S24)。クライアント端末Aが送信された画面を表示して(S25)、処理が終了する(S26)。
【0031】
以上のように、センタサーバ100が条件テーブル(111−1)を備えることにより、ユーザからアクセスされるセンタサーバ100がそのユーザのユーザ情報リポジトリを持たなくても認証処理を適切な認証サーバに転送する。これにより、適切な認証処理が可能となり、自社社員の個人情報を他企業に提供しなくても認証可能となり、個人情報に対するセキュリティを保持できる。
【0032】
実施の形態2.
図7〜図9を参照して実施の形態2の分散型認証連携システム20を説明する。実施の形態1ではセンタサーバ100のみが条件テーブルを保有したが、実施の形態2はセンタサーバ100の他、A社サーバ200及びBサーバ300も条件テーブルを保有する実施の形態である。すなわち、実施の形態2はセンタサーバ100、A社サーバ200、B社サーバ300いずれも認証先選定装置の場合の実施の形態である。
【0033】
図7は、実施の形態2における分散型認証連携システム11を示す構成図である。図2の分散型認証連携システム10に対する差異のみを説明する。同じドメインであるセンタサーバ100とA社サーバ200、B社サーバ300と複数あり、各認証サーバは、条件テーブル111(111−1)、条件テーブル222、条件テーブル333(333−1)を持つ。具体的には、実施の形態2では、センタサーバ100は分散型認証連携システム10と同じ構成である。分散型認証連携システム11におけるA社サーバ200は、分散型認証連携システム10のセンタサーバ100がユーザ情報リポジトリを備えた構成である。これは、センタサーバ100は実際の認証処理は行わないがA社サーバ200は認証処理を実行するからである。B社サーバ300はA社サーバ200と同じ構成である。もちろん、A社サーバ200のユーザ情報リポジトリ211はA社の社員の個人情報(認証処理に使用する情報)を格納しており、B社サーバ300のユーザ情報リポジトリ311はB社の社員の個人情報を格納している。実施の形態2のA社サーバ200は実施の形態1のセンタサーバ100と同様の処理を実行するが、相違は、A社サーバ200は、自身でも認証処理を実行する場合がある点である。すなわちA社サーバ200は、ユーザAからのリクエストに対しては、条件テーブルを参照した結果、自信が認証処理を行うことになる。B社サーバ300もA社サーバ200と同様である。センタサーバ100の場合はーザ情報リポジトリを持たない前提であるので、認証処理を実行することはない。
【0034】
図8は、実施の形態2において、A社のユーザAがセンタサーバ100経由でA社サーバ200において認証された後、B社のバックエンドWebサーバ(バックエンドWebシステム3010)にB社サーバ300経由でアクセスするときの認証処理時のフローチャートを示す。すなわち、ユーザAは、まずWebシステム1010あるいはWebシステム1020を利用するためセンタサーバ100にリクエストを送信して認証(A社サーバ200の実施)を受け、次にバックエンドWebシステム3010あるいはWebシステム3020の利用を希望してB社サーバ300にリクエストを送信した場合である。
【0035】
A社のユーザAがセンタサーバ100経由でA社サーバ200において認証されるときの処理は実施の形態1で述べたとおりである。
【0036】
次に、図8を参照して、認証済ユーザA(A社サーバ200により認証済み)が、B社サーバ300経由でバックエンドWebサーバ(バックエンドWebシステム3010)にアクセスするときの動作を示す。
【0037】
(クライアント端末A)
ユーザAがクライアント端末AからリクエストをB社サーバ300に送信する(S29)。
【0038】
(B社サーバ300)
B社サーバ300は通信部340でリクエスト(この例では認証済みクッキーを含む)を受信する(S30)。B社サーバ300の第3認証処理部310は、リクエストに認証済クッキーがあるかどうかをチェックする(S31)。第3認証処理部310は、証済クッキーがなければ通常の認証処理を実施する(実施の形態1で述べたS3〜S15)。第3認証処理部310は、証済クッキーがあれば、認証済クッキーからユーザID、セッションIDを抽出し(S32)、ユーザID、セッションIDと条件テーブル333(333−1)とから認証先(認証先)を決定する(S34)。この例ではA社サーバ200が認証先として決定される。第3認証処理部310は、決定した認証先であるA社サーバ200に認証済クッキー情報を通信部340から送信する(S35)。
【0039】
(A社サーバ200)
A社サーバ200は、通信部240で認証済クッキーを受信する(S36)。第2認証処理部210は、認証済クッキーからユーザID、セッションIDを抽出し(S32)、ユーザAの情報をユーザ情報リポジトリ211から取得し(S33)、B社サーバ300へそのユーザ情報を通信部240から送信する(S37)。
【0040】
B社サーバ300の通信部340がユーザAの情報を受信すると、第3認可処理部320が認可処理を開始する。
【0041】
以上のように、認証サーバが複数あり、第三者認証サーバにアクセスしてもシングルサインオンと他社ユーザ属性を使用した認可が可能である。
【0042】
なお、図7では、センタサーバ100がユーザ情報、条件テーブル、アクセス管理情報を保有するようにしたが、これらの情報は他の装置、あるいはシステムが保有するようにしても構わない。
【0043】
実施の形態3.
次に実施の形態3を説明する。実施の形態2では、1度認証されれば、クライアント端末を止めない限り、「同じ認証済クッキー」で認証が成功してしまう。そこで、実施の形態3では、認証済クッキーに有効期限を設けることにより、認証後、一定時間経過後に再認証を必要とする実施の形態を示す。
【0044】
実施の形態3を示す構成図は、実施の形態2の図7と同じであるが、認証成立の際に発行する認証済クッキーに有効期限を設定する。認証済クッキーを生成するのは、クライアント端末からリクエストを受けたサーバである。したがって、このリクエストを受けたサーバの認証処理部は、認証済クッキーを生成する際に認証済クッキーに有効期限を設定する。
【0045】
実施の形態3における認証処理時のフローはほぼ実施の形態1あるいは2と同様であるが、サーバの認証処理部は、認証済みクッキーのチェックの際(S2,S31等)に有効期限もチェックし、有効期限が来ていれば再認証の処理を実行することとなる。
【0046】
以上のように、認証済クッキーに有効期限を設けることで、定期的に再認証させることができ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。
【0047】
実施の形態4.
次に図10〜図16を参照して、実施の形態4の分散型認証連携システム40を説明する。
図10は、実施の形態4の分散型認証連携システム40のシステム構成を示す。
図11は、認証処理の過程を示すフローチャートである。図3等と同じ処理には同じステップ番号を付した。
図12は、ユーザAがWebシステム2010にアクセスする場合のフローチャートである。
図13は、図11をシーケンス化した図である。
図14は、図12で認証済みクッキーなしの場合をシーケンス化した図である。
図15は、図12で認証済みクッキー有りの場合をシーケンス化した図である。
【0048】
以上の実施の形態3では、認証済みクッキーに有効期限を設定することで成りすましの可能性を減らすこととしたが、認証済クッキーを改ざんし、有効期限を長くすることで成りすましされてしまう可能性がある。そこで実施の形態4では、認証処理を現実に実行する認証サーバ(すなわち、A社サーバ200とB社サーバ300)に認証済みクッキー管理テーブル(認証履歴情報)を備え、有効期限が一致しない場合には、認証済みクッキーを無効とする。
【0049】
実施の形態4を示す構成図を図10に示す。A社サーバ200は、認証クッキー管理テーブル230を備える。B社サーバ300も備えるが図示はしていない。
【0050】
実施の形態4における認証処理時のフローは、ユーザAがWebシステム1010にリクエストを送信する場合であり、ほぼ実施の形態1と同様となる。
【0051】
(A社サーバ200)
A社サーバ200の第2認証処理部210は、認証成功後、認証済みクッキー管理テーブル230に認証済み情報(認証履歴情報)としてユーザID、セッションID、有効期限を書き込む(S27)。
第2認証処理部210は、ユーザID、セッションID、有効期限から生成した認証済通知をセンタサーバ100に送信する(S28)。
【0052】
(センタサーバ100)
以降の処理は実施の形態1と同様である。
【0053】
次に図14、図15を参照して、認証済ユーザAがA社サーバ200経由でバックエンドWebシステム2010(バックエンドWebサーバ)にアクセスするときの動作を示す。
【0054】
(クライアント端末A)
ユーザAがクライアント端末Aから、A社サーバ200にリクエストを送信する(S29)。
【0055】
(A社サーバ200)
A社サーバ200はリクエストを受信する(S30)。A社サーバ200の第2認証処理部210はリクエストに認証済みクッキーがあるかのチェックを行う(S31)。第2認証処理部210は認証済みクッキーがなければ(図14の場合)、通常の認証処理を実施する(S3〜S15)。認証済みクッキーが有れば(図15の場合)、第2認証処理部210は認証済みクッキーからユーザID、セッションID、有効期限を抽出し(S32)、認証済みクッキー管理テーブル230に該当レコード(認証履歴情報)があるかをチェックする(S33)。なければ通常の認証処理を実施し(S3〜S15)、あれば認可処理へ進む。
【0056】
以上のように、認証済情報の有効期限を管理することにより、認証済クッキーの改ざんを防ぎ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。
【0057】
実施の形態5.
図16、図17を参照して実施の形態5を説明する。以上の実施の形態では、利用ユーザが明示的にログオフすることが出来ないため、利用後に不正アクセスされる可能性が残っている。そこで実施の形態5は、利用ユーザが明示的にログオフ要求し、認証済みクッキー管理テーブル230に記録されている認証済情報(ユーザID、セッションID、有効期限などを含む認証履歴情報)を削除する場合を示す。
【0058】
実施の形態5を示す構成図は、実施の形態2と同じである。
【0059】
図16に実施の形態5におけるA社サーバ200で認証処理されたユーザAがセンタサーバ100にログオフリクエストを送信した時のフローチャートを示す。図17は、図16をシーケンス化した図である。
【0060】
(クライアント端末A)
ユーザAがクライアント端末AからWebブラウザを使用して、センタサーバ100にログオフリクエスト(終了リクエスト)を送信する(S38)。つまりクライアント端末Aからセンタサーバ100にリクエスト(利用リクエスト)を送信して認証成立した場合である。
【0061】
(センタサーバ100)
センタサーバ100がログオフリクエストを受信する(S39)。センタサーバ100の第1認証処理部110は、認証済みクッキーの有無をチェックする(S31)。なければ第1認証処理部110はクライアント端末Aに認証済みクッキーがない旨の画面を送信する(S44)。あれば、第1認証処理部110は、認証済みクッキーからユーザID、セッションIDを抽出する(S32)。そして、第1認証処理部110は条件テーブル(111−1)を参照し、ユーザIDをもとに認証先を決定し(S34)、認証済みクッキーとともにログオフリクエストを認証先であるA社サーバ200に送信する(S40)。
【0062】
(A社サーバ200)
A社サーバ200の通信部240はログオフリクエスト付の認証済みクッキーを受信する(S41)。第2認証処理部210は、認証済みクッキーからユーザID、セッションIDを抽出する(S32)。第2認証処理部210は、抽出したユーザID、セッションIDの組み合わせが、認証済みクッキー管理テーブル230の認証履歴情報として存在するかをチェックする(S33)。第2認証処理部210は、なければない旨をセンタサーバ100に送信する(S43)。センタサーバ100は、クライアント端末Aに認証済情報がない旨の画面を送信する(S44)。認証済情報(認証履歴情報)があれば、第2認証処理部210は、認証済クッキー管理テーブル230の該当エントリ(該当する認証履歴情報)を削除し、ログオフが成功する(S42)。A社サーバ200はログオフ成功をセンタサーバ100に送信し(S45)、センタサーバ100は、クライアント端末Aにログオフ成功画面を送信する(S46)。
【0063】
以上のように、利用ユーザの明示的なログオフが可能となり、成りすましなどの不正アクセスの可能性を低減することが可能である。
【0064】
実施の形態6.
図18、図16を参照して実施の形態6を説明する。
【0065】
実施の形態6は、認証サーバ(センタサーバ100、A社サーバ200、B社サーバ300)をコンピュータで実現する場合の具体的な形態を説明する。センタサーバ100、A社サーバ200、B社サーバ300は、センタサーバ100がユーザ情報(ユーザ情報リポジトリ)を持たない以外は同様の構成であるので、センタサーバ100を例に説明する。
【0066】
図18は、センタサーバ装置の外観の一例を示す図である。図18において、センタサーバ100は、システムユニット830、CRT(Cathode・Ray・Tube)やLCD(液晶)の表示画面を有する表示装置813、キーボード814(Key・Board:K/B)、マウス815、FDD817(Flexible・Disk・ Drive)、コンパクトディスク装置818(CDD:Compact Disk Drive)、プリンタ装置819などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
【0067】
図19は、コンピュータで実現されるセンタサーバ100のハードウェア資源の一例を示す図である。図19において、センタサーバ100、プログラムを実行するCPU810(Central Processing Unit)を備えている。CPU810は、バス825を介してROM(Read Only Memory)811、RAM(Random Access Memory)812、表示装置813、キーボード814、マウス815、通信ボード816、FDD817、CDD818、プリンタ装置819、磁気ディスク装置820と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置820の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
【0068】
RAM812は、揮発性メモリの一例である。ROM811、FDD817、CDD818、磁気ディスク装置820等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード816、キーボード814、FDD817などは、入力部、入力装置の一例である。また、通信ボード816、表示装置813、プリンタ装置819などは、出力部、出力装置の一例である。
【0069】
通信ボード816は、ネットワーク(LAN等)に接続されている。通信ボード816は、LANに限らず、インターネット、ISDN等のWAN(ワイドエリアネットワーク)などに接続されていても構わない。
【0070】
磁気ディスク装置820には、オペレーティングシステム821(OS)、ウィンドウシステム822、プログラム群823、ファイル群824が記憶されている。プログラム群823のプログラムは、CPU810、オペレーティングシステム821、ウィンドウシステム822により実行される。
【0071】
上記プログラム群823には、以上の実施の形態の説明において「〜部」として説明した機能を実行するプログラムが記憶されている。プログラムは、CPU810により読み出され実行される。
【0072】
ファイル群824には、以上の実施の形態の説明において、「条件テーブル(111−1)」、「アクセス制御情報テーブル」、あるいはA社サーバ200であれば、「ユーザ情報」、「認証済みクッキー管理情報」として説明したデータや、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明した情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU810によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのCPUの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【0073】
また、以上に述べた実施の形態の説明において、データや信号値は、RAM812のメモリ、FDD817のフレキシブルディスク、CDD818のコンパクトディスク、磁気ディスク装置820の磁気ディスク、その他光ディスク、ミニディスク、DVD(Digital・Versatile・Disk)等の記録媒体に記録される。また、データや信号は、バス825や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【0074】
また、以上の実施の形態の説明において、「〜部」として説明したものは、「〜手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ROM811に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU810により読み出され、CPU810により実行される。すなわち、プログラムは、以上に述べた「〜部」としてコンピュータを機能させるものである。あるいは、以上に述べた「〜部」の手順や方法をコンピュータに実行させるものである。
【0075】
以上の実施の形態1〜5では、認証サーバ装置として、装置を説明したが、サーバ装置の動作を、コンピュータに実行させる認証先選定プログラム、あるいは認証先選定プログラムを記録したコンピュータ読み取り可能な記録媒体として把握することも可能である。さらに、認証サーバ装置の動作を認証サーバ装置が行う認証先選定方法として把握することも可能である。
【符号の説明】
【0076】
10,20,40 分散型認証連携システム、100 センタサーバ、110 第1認証処理部、111 条件テーブル格納部、111−1 条件テーブル、120 第1認可処理部、121 アクセス制御情報リポジトリ、121−1 アクセス制御情報テーブル、140 通信部、200 A社サーバ、210 第2認証処理部、211 ユーザ情報リポジトリ、220 第2認可処理部、221 アクセス制御情報リポジトリ、221−1 アクセス制御情報テーブル、222 条件テーブル格納部、240 通信部、300 B社サーバ、310 第3認証処理部、311 ユーザ情報リポジトリ、333 条件テーブル格納部、320 第3認可処理部、321 アクセス制御情報リポジトリ、340 通信部。
【技術分野】
【0001】
この発明は、ユーザが企業を跨ってWeb系業務システムを利用するシステムに関する。
【背景技術】
【0002】
従来のWeb系クライアント/サーバ型のシステムにおいて、複数の認証システム間のシングルサインオン(1度の認証情報の入力により複数システムが利用可能)については、認証先をあらかじめユーザが入力するものや、双方の認証システムにユーザ情報を保持する方式が一般的である。
【0003】
例えば、特許文献1の「認証方法および装置、サービス提供方法および装置、情報入力装置」では、認証情報入力時に、ユーザID、パスワードに加え、認証サーバ情報を入力することで、アクセス先とは異なる認証サーバにて認証処理を可能とすることが記載されている。
【0004】
現在、企業グループでは、グループ内企業の相乗効果やシステムの共通利用などが進んでいる。このとき、企業グループ共通のシステムを利用したり、各社相互にシステム利用したりすることになる。このようなときには、セキュリティ上、相互の企業における認証システムで本人認証することが一般的である。また、認証システムが認証やアクセス制御に使用する情報は、企業内の個人情報であり、他社に開示できないケースが多いのが一般的である。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2005−149341号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
従来技術では以下のような課題があった。従来の認証・認可サーバでは、複数企業のWeb系業務システムを利用する際にはそれぞれの認証システムにログインして業務を実施する。そのため、シングルサインオンが出来ないなど、ユーザ利便性を損ねる。また、それぞれの企業でユーザ登録をする必要があり、これは社員の個人情報を他社に提供し、二重管理することになるため、セキュリティレベルの低下となる。
【0007】
この発明は、他企業のユーザ情報を保有せず、あらかじめ決めておいたユーザ情報の条件と認証先により、認証先を決定かつ転送することで認証処理を他企業に移管しつつ、認証結果を保持することでシングルサインオンを行う。
【課題を解決するための手段】
【0008】
この発明の認証先選定システムは、
認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部を有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける認証先選定装置と、
前記システムを利用するクライアント端末装置と、
認証処理を実行する複数の前記認証装置と
を備え、
前記クライアント端末装置は、
前記認証先選定装置に前記利用リクエストを送信し、
前記認証先選定装置は、
前記利用リクエストを受信し、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより前記利用リクエストに対する認証処理を実行するべき前記認証装置を前記複数の認証装置のなかから選定し、選定された前記認証装置に前記利用リクエストに対する認証処理の実行を依頼し、
選定された前記認証装置は、
前記認証処理を実行して認証結果を前記認証先選定装置に送信し、
前記認証先選定装置は、
前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする。
【発明の効果】
【0009】
この発明により、複数企業のWeb系業務システムを利用する際にも、シングルサインオンで各システムを利用することができる。また、各企業で他の企業の社員のユーザ登録をする必要がなくなり、社員の個人情報を他社に提供する必要がなくなる。
【図面の簡単な説明】
【0010】
【図1】実施の形態1〜5の分散型認証連携システムの概要を説明する図。
【図2】実施の形態1における分散型認証連携システム10のシステム構成図。
【図3】実施の形態1における認証処理を示すフローチャート。
【図4】実施の形態1における認可処理を示すフローチャート。
【図5】図3をシーケンス化した図。
【図6】図4をシーケンス化した図。
【図7】実施の形態2における分散型認証連携システム20のシステム構成図。
【図8】実施の形態2における認証処理を示すフローチャート。
【図9】図8をシーケンス化した図。
【図10】実施の形態4における分散型認証連携システム40のシステム構成図。
【図11】実施の形態4におけるクライアント端末がWebシステム1000にリクエストを送信した場合の認証処理を示すフローチャート。
【図12】実施の形態4におけるクライアント端末がWebシステム2000にリクエストを送信した場合の認証処理を示すフローチャート。
【図13】図11をシーケンス化した図。
【図14】図12で認証済みクッキーなしの場合をシーケンス化した図。
【図15】図12で認証済みクッキー有りの場合をシーケンス化した図。
【図16】実施の形態5におけるログオフ処理を示すフローチャート。
【図17】図16をシーケンス化した図。
【図18】実施の形態6における認証サーバ装置の外観を示す図。
【図19】実施の形態6における認証サーバ装置のハードウェア資源の一例を示す図。
【発明を実施するための形態】
【0011】
実施の形態1.
図1〜図6を参照して実施の形態1を説明する。図1は、実施の形態1〜6で説明する分散型認証連携システムの概要を説明するための図である。図1は、認証サーバ100〜300がいずれも同一の認証方式選択テーブル(後述の条件テーブル)を保有している。図1では認証サーバ100が、リクエストを受信した場合に認証を実行する認証装置を選定する認証先選定装置である。なお、図1は具体的には実施の形態2が該当する。
【0012】
図1において、A社データセンター及びA社拠点は、A株式会社に属する。B社データセンター及びB社拠点は、B株式会社に属する。企業グループデータセンター(後述の共通センター)とは、A株式会社及びB株式会社に属する社員の両社に利用が認められるバックエンドWebシステム1000を持つ。また、各社のユーザ情報は、自社の認証リポジトリとして自社で管理される。ユーザ(A会社の社員あるいはB会社の社員)は、認証成立を条件にWebシステム1000〜3000を使用することができる。図1の場合は、A社の社員の認証はA社の認証サーバ200が実施し、B社の社員の認証はB社の認証サーバ200が実施するのであるが、そのため、自身の接続するWebシステムに対するリクエストを受けた認証サーバは、保有する認証方式選択テーブルを用いて、認証を実行するべき認証サーバを自身も含めて選定する。そして、選定された認証サーバが、リクエストに係るユーザの認証処理を実行する。
【0013】
すなわち図1において、認証サーバ100〜300は、クライアント端末からのリクエストに対して、ユーザID(UID)、端末IPアドレスなどの条件に応じて、認証方式選択テーブルを参照し、各社の認証サーバに割り振る。図1の場合、それぞれWebシステム1000、2000、3000を利用したい場合、ユーザはクライアント端末から、Webシステム1000、2000、3000へのリクエストを送信する。その場合、Webシステム1000、2000、3000へのリクエストに対して、それぞれ、認証サーバ100、200、300が認証方式選択テーブルを参照し、認証処理をするべき認証サーバを選定する。なお、A社の社員Aがクライアント端末AからWebシステム1000〜3000のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、A社の認証サーバ200である。同様に、B社の社員Bがクライアント端末BからWebシステム1000〜3000のいずれかにリクエストを送信した場合、認証処理を実行するのは、常に、B社の認証サーバ200である。このように、他社あるいはセンターのWebシステムへのリクエストに対しても、社員の認証処理を自社の認証サーバが実施するので、他社に社員の個人情報を渡す必要がなくなり、同時にシングルサインオンも可能となる。
【0014】
以下はユーザIDで認証サーバを割り振る場合の流れを示す。
(1)ユーザAA000001は、Webシステム1000を利用したい場合、A社拠点のクライアント端末Aにより、企業グループデータセンターの認証サーバ100にアクセスする。
(2)クライアント端末Aのログイン画面にて入力されて送信されたユーザIDを受信した認証サーバ100は、認証方式選択テーブルを参照することにより、社員Aの属するA社の認証サーバ200に認証情報(ユーザID)を転送する。
(3)認証情報が転送されたA社の認証サーバ200は、社員Aの認証処理を実施する。
(4)認証が成功した場合には、認証サーバ200から認証サーバ100に通知され、認証成功の通知をうけた認証サーバ100は、各認証サーバで有効と認められる認証済み情報をクライアント端末Aに発行する。
(5)クライアント端末Aは、認証済み情報を持っていれば、各認証サーバにアクセスした時に、認証OKと判断され、各Webシステム1000〜3000に対してシングルサインオンでアクセス可能となる。
(6)以上のように認証方式選択テーブルを各認証サーバが保有することで、認証に必要な情報を各社で管理したとしても、シングルサインオンが可能となる。また、標準的な方式よりもサーバ間の通信を削減できるので、処理性能を上げるこができる。また、認証済み情報にユーザの属性情報を埋め込むことで、属性情報と、属性情報とアクセス権の対応が記載された後述のアクセス制御情報テーブルとから、各認証サーバでのアクセス制御も可能となる。
【0015】
図2は、実施の形態1の分散型認証連携システム101を示す構成図である。分散型認証連携システム101では、共通センター、A社センター、B社センターが存在する。共通センターは、第1認証サーバ100を備えている。第1認証サーバ100は、バックエンドWebシステム1010、バックエンドWebシステム1020に接続している。A社センターは第2認証サーバ200を備え、B社センターは第3認証サーバ300を備えている。なお、以下では第1認証サーバ100をセンタサーバ100、第2認証サーバ200をA社サーバ200、第3認証サーバ300をB社サーバ300と呼ぶ。
【0016】
センタサーバ100は、バックエンドWebシステム1010、1020の認証処理を統合し、リバースプロキシ機能として働いている。
【0017】
(センタサーバ100の構成)
センタサーバ100は、第1認証処理部110(判断部、認証装置選定部、認証処理依頼部、認証済み情報作成部)、条件テーブル格納部111(認証装置選定条件情報格納部)、第1認可処理部120(システム管理部)、アクセス制御情報リポジトリ121(アクセス制御情報格納部)、通信部140(リクエスト受信部)を備えている。
【0018】
第1認可処理部120はバックエンドWebシステム1010,1020に接続している。条件テーブル格納部111は、条件テーブル(111−1)(認証装置選定条件情報)を格納している。アクセス制御情報リポジトリ121は、アクセス制御情報テーブル(121−1)を格納している。
【0019】
(1)第1認可処理部120は、バックエンドWebシステム1010,1020とデータをやりとりする。
(2)通信部140は、クライアント端末から、バックエンドWebシステム1010,1020の利用を要求するリクエスト(利用リクエスト)を受信する。
(3)条件テーブル格納部111に格納される条件テーブル(111−1)は、認証処理を実行するべき認証装置の選定条件が定義されている。
(4)第1認証処理部110は、通信部140によって受信された利用リクエストに、認証済み情報(後述の認証済みクッキー)が含まれているかどうかを判断する。また、認証済み情報が利用リクエストに含まれていないと判断すると、クライアント端末にユーザID、パスワード等の認証処理に使用する認証情報の送信を要求し、クライアント端末から送信された認証情報と、条件テーブル(111−1)とから、リクエストに対する認証処理を実行するべき認証装置を選定する。そして、第1認証処理部110は、選定された前記認証装置に、リクエストに対する認証処理の実行を依頼し、選定された前記認証装置から認証結果を受信すると、認証結果が認証成立を示す場合には認証済み情報を作成し、その認証済み情報をクライアント端末に返信する。
(5)アクセス制御情報リポジトリ121に格納されたアクセス制御情報テーブル(121−1)には、バックエンドWebシステム1010,1020へのアクセス制限を示すアクセス権が定義されている。
(6)第1認可処理部120は、第1認証処理部110によって認証済み情報が利用リクエストに含まれていると判断されると、リクエストに基づいてアクセス制御情報テーブル(121−1)を検索することにより、クライアント端末のアクセス権を確認し、確認されたアクセス権の範囲でクライアント端末によるバックエンドWebシステム1010,1020へのアクセスを許可する。
【0020】
(A社サーバ200、B社サーバ300)
A社サーバ200は、ユーザ情報リポジトリ211、第2認証処理部210を備えている。B社サーバ300は、ユーザ情報リポジトリ311、第3認証処理部310を備えている。A社サーバ200は、センタサーバ100から認証処理の依頼と共にユーザの認証情報(例えばユーザID、パスワード)を受信すると、正規な認証情報が記載されたユーザ情報リポジトリ211のユーザ情報テーブル(211−1)を参照して、受信した認証情報が正規なものかどうかの認証処理を実行する。B社サーバ300もA社サーバ200と同様である。なお、図2のユーザ情報テーブル(211−1)、(311−1)には、パスワードの項目は示していないが、パスワードの項目も存在する。
【0021】
次に動作について説明する。
【0022】
図3は、実施の形態1において、A社の社員A(本システムのユーザ)が共通センターのセンタサーバ100を利用して共通センターのバックエンドWebシステム1010にアクセスする際の認証処理時のフローチャートを示す。図2では、認証先選定装置となるのは、センタサーバ100のみである。図4は、認証処理動作におけるセンタサーバ100、A社サーバ200の認可処理時のフローチャートである。図5、図6はそれぞれ図3、図4をシーケンス化した図である。
【0023】
ユーザA(ユーザID:AA000001)がクライアント端末AのWebブラウザを使用して、バックエンドWebシステム1010へのリクエスト(利用リクエスト)をセンタサーバ100に送信する(S1)。センタサーバ100の通信部140は、リクエストを受信する。第1認証処理部110が、リクエスト中の認証済み情報(後述の認証済クッキー)の有無により、認証済みかどうかをチェックする(S2)。認証前の場合、第1認証処理部110が通信部140を介してログイン画面を送信し、クライアント端末Aはログイン画面を表示する(S3)。ユーザAが、ログイン画面にてユーザID、パスワードを入力し、クライアント端末Aが送信する(S4)。
【0024】
(センタサーバ100)
センタサーバ100の通信部140がユーザAの送信したユーザID、パスワードを受信し(S5)、第1認証処理部110がユーザIDを条件に条件テーブル(111−1)から認証先を検索し、決定する(S6)。ここでは、ユーザAのユーザID、パスワードからA社サーバ200が認証サーバとして第1認証処理部110により決定される。第1認証処理部110は、決定した認証先(A社サーバ200)に対して、ユーザID、パスワードを通信部140を介して転送する(S7)。
【0025】
(A社サーバ200)
A社サーバ200はユーザAのユーザIDとパスワードを受信する(S8)。そして、A社サーバ200は、ユーザ情報リポジトリ211内のユーザ情報テーブル(211−1)および受信したユーザID、パスワードを使用し、認証処理を実施する(S9)。認証結果を判断し(S10)、成功したならば、A社サーバ200は、ユーザAのユーザ属性とともに認証済結果を作成し、センタサーバ100に送信する(S11)。S10の判断結果、認証失敗ならば、センタサーバ100へ失敗結果を返し(S14)、S3へ戻る。
【0026】
(センタサーバ100)
センタサーバ100は成功の認証結果を受信すると、第1認証処理部110が認証済みクッキー(認証済み情報)を作成し(S11−1)、クライアント端末Aへ認証済みクッキーと共にバックエンドWebシステム1010に自動リダイレクトするページを送信する(S12)。
【0027】
(クライアント端末A)
クライアント端末Aは、認証済クッキーと共にバックエンドWebシステム1010への自動リクエストをセンタサーバ100に送信する(S13)。
【0028】
(センタサーバ100)
センタサーバ100は、通信部140によりクライアント端末Aからのリクエストを受信し(S15)、第1認可処理部120により認可処理を実施する。以上で認証処理は完了(S16)。
【0029】
(認可処理)
S16以降までの認証処理に続き、図4、図6を参照して、認証が完了したユーザAが、センタサーバ100経由で、バックエンドWebサーバ(バックエンドWebシステム1010)にアクセスするときの認可処理を説明する。認可処理は第1認可処理部120による処理である。
【0030】
(センタサーバ100)
センタサーバ100の第1認可処理部120は、認証済クッキー内にあるユーザAの属性情報(個人であるユーザAを特定する情報ではないが、この情報に付随する付加的な情報)を元に、アクセス制御情報テーブル(121−1)を検索し(S18)、ユーザAのアクセス権があるかをチェックする(S19)。アクセス権がなければ、第1認可処理部120はクライアント端末Aにアクセスエラー画面を通信部140を介して送信し(S20)、処理は終了(S26)する。アクセス権があれば、第1認可処理部120はバックエンドWebシステム1010にリクエストを転送する(S21)。その後、バックエンドWebシステム1010は、ユーザ情報によって適切な画面を生成し(S22)、センタサーバ100は、その画面をクライアント端末Aに送信する(S23、S24)。クライアント端末Aが送信された画面を表示して(S25)、処理が終了する(S26)。
【0031】
以上のように、センタサーバ100が条件テーブル(111−1)を備えることにより、ユーザからアクセスされるセンタサーバ100がそのユーザのユーザ情報リポジトリを持たなくても認証処理を適切な認証サーバに転送する。これにより、適切な認証処理が可能となり、自社社員の個人情報を他企業に提供しなくても認証可能となり、個人情報に対するセキュリティを保持できる。
【0032】
実施の形態2.
図7〜図9を参照して実施の形態2の分散型認証連携システム20を説明する。実施の形態1ではセンタサーバ100のみが条件テーブルを保有したが、実施の形態2はセンタサーバ100の他、A社サーバ200及びBサーバ300も条件テーブルを保有する実施の形態である。すなわち、実施の形態2はセンタサーバ100、A社サーバ200、B社サーバ300いずれも認証先選定装置の場合の実施の形態である。
【0033】
図7は、実施の形態2における分散型認証連携システム11を示す構成図である。図2の分散型認証連携システム10に対する差異のみを説明する。同じドメインであるセンタサーバ100とA社サーバ200、B社サーバ300と複数あり、各認証サーバは、条件テーブル111(111−1)、条件テーブル222、条件テーブル333(333−1)を持つ。具体的には、実施の形態2では、センタサーバ100は分散型認証連携システム10と同じ構成である。分散型認証連携システム11におけるA社サーバ200は、分散型認証連携システム10のセンタサーバ100がユーザ情報リポジトリを備えた構成である。これは、センタサーバ100は実際の認証処理は行わないがA社サーバ200は認証処理を実行するからである。B社サーバ300はA社サーバ200と同じ構成である。もちろん、A社サーバ200のユーザ情報リポジトリ211はA社の社員の個人情報(認証処理に使用する情報)を格納しており、B社サーバ300のユーザ情報リポジトリ311はB社の社員の個人情報を格納している。実施の形態2のA社サーバ200は実施の形態1のセンタサーバ100と同様の処理を実行するが、相違は、A社サーバ200は、自身でも認証処理を実行する場合がある点である。すなわちA社サーバ200は、ユーザAからのリクエストに対しては、条件テーブルを参照した結果、自信が認証処理を行うことになる。B社サーバ300もA社サーバ200と同様である。センタサーバ100の場合はーザ情報リポジトリを持たない前提であるので、認証処理を実行することはない。
【0034】
図8は、実施の形態2において、A社のユーザAがセンタサーバ100経由でA社サーバ200において認証された後、B社のバックエンドWebサーバ(バックエンドWebシステム3010)にB社サーバ300経由でアクセスするときの認証処理時のフローチャートを示す。すなわち、ユーザAは、まずWebシステム1010あるいはWebシステム1020を利用するためセンタサーバ100にリクエストを送信して認証(A社サーバ200の実施)を受け、次にバックエンドWebシステム3010あるいはWebシステム3020の利用を希望してB社サーバ300にリクエストを送信した場合である。
【0035】
A社のユーザAがセンタサーバ100経由でA社サーバ200において認証されるときの処理は実施の形態1で述べたとおりである。
【0036】
次に、図8を参照して、認証済ユーザA(A社サーバ200により認証済み)が、B社サーバ300経由でバックエンドWebサーバ(バックエンドWebシステム3010)にアクセスするときの動作を示す。
【0037】
(クライアント端末A)
ユーザAがクライアント端末AからリクエストをB社サーバ300に送信する(S29)。
【0038】
(B社サーバ300)
B社サーバ300は通信部340でリクエスト(この例では認証済みクッキーを含む)を受信する(S30)。B社サーバ300の第3認証処理部310は、リクエストに認証済クッキーがあるかどうかをチェックする(S31)。第3認証処理部310は、証済クッキーがなければ通常の認証処理を実施する(実施の形態1で述べたS3〜S15)。第3認証処理部310は、証済クッキーがあれば、認証済クッキーからユーザID、セッションIDを抽出し(S32)、ユーザID、セッションIDと条件テーブル333(333−1)とから認証先(認証先)を決定する(S34)。この例ではA社サーバ200が認証先として決定される。第3認証処理部310は、決定した認証先であるA社サーバ200に認証済クッキー情報を通信部340から送信する(S35)。
【0039】
(A社サーバ200)
A社サーバ200は、通信部240で認証済クッキーを受信する(S36)。第2認証処理部210は、認証済クッキーからユーザID、セッションIDを抽出し(S32)、ユーザAの情報をユーザ情報リポジトリ211から取得し(S33)、B社サーバ300へそのユーザ情報を通信部240から送信する(S37)。
【0040】
B社サーバ300の通信部340がユーザAの情報を受信すると、第3認可処理部320が認可処理を開始する。
【0041】
以上のように、認証サーバが複数あり、第三者認証サーバにアクセスしてもシングルサインオンと他社ユーザ属性を使用した認可が可能である。
【0042】
なお、図7では、センタサーバ100がユーザ情報、条件テーブル、アクセス管理情報を保有するようにしたが、これらの情報は他の装置、あるいはシステムが保有するようにしても構わない。
【0043】
実施の形態3.
次に実施の形態3を説明する。実施の形態2では、1度認証されれば、クライアント端末を止めない限り、「同じ認証済クッキー」で認証が成功してしまう。そこで、実施の形態3では、認証済クッキーに有効期限を設けることにより、認証後、一定時間経過後に再認証を必要とする実施の形態を示す。
【0044】
実施の形態3を示す構成図は、実施の形態2の図7と同じであるが、認証成立の際に発行する認証済クッキーに有効期限を設定する。認証済クッキーを生成するのは、クライアント端末からリクエストを受けたサーバである。したがって、このリクエストを受けたサーバの認証処理部は、認証済クッキーを生成する際に認証済クッキーに有効期限を設定する。
【0045】
実施の形態3における認証処理時のフローはほぼ実施の形態1あるいは2と同様であるが、サーバの認証処理部は、認証済みクッキーのチェックの際(S2,S31等)に有効期限もチェックし、有効期限が来ていれば再認証の処理を実行することとなる。
【0046】
以上のように、認証済クッキーに有効期限を設けることで、定期的に再認証させることができ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。
【0047】
実施の形態4.
次に図10〜図16を参照して、実施の形態4の分散型認証連携システム40を説明する。
図10は、実施の形態4の分散型認証連携システム40のシステム構成を示す。
図11は、認証処理の過程を示すフローチャートである。図3等と同じ処理には同じステップ番号を付した。
図12は、ユーザAがWebシステム2010にアクセスする場合のフローチャートである。
図13は、図11をシーケンス化した図である。
図14は、図12で認証済みクッキーなしの場合をシーケンス化した図である。
図15は、図12で認証済みクッキー有りの場合をシーケンス化した図である。
【0048】
以上の実施の形態3では、認証済みクッキーに有効期限を設定することで成りすましの可能性を減らすこととしたが、認証済クッキーを改ざんし、有効期限を長くすることで成りすましされてしまう可能性がある。そこで実施の形態4では、認証処理を現実に実行する認証サーバ(すなわち、A社サーバ200とB社サーバ300)に認証済みクッキー管理テーブル(認証履歴情報)を備え、有効期限が一致しない場合には、認証済みクッキーを無効とする。
【0049】
実施の形態4を示す構成図を図10に示す。A社サーバ200は、認証クッキー管理テーブル230を備える。B社サーバ300も備えるが図示はしていない。
【0050】
実施の形態4における認証処理時のフローは、ユーザAがWebシステム1010にリクエストを送信する場合であり、ほぼ実施の形態1と同様となる。
【0051】
(A社サーバ200)
A社サーバ200の第2認証処理部210は、認証成功後、認証済みクッキー管理テーブル230に認証済み情報(認証履歴情報)としてユーザID、セッションID、有効期限を書き込む(S27)。
第2認証処理部210は、ユーザID、セッションID、有効期限から生成した認証済通知をセンタサーバ100に送信する(S28)。
【0052】
(センタサーバ100)
以降の処理は実施の形態1と同様である。
【0053】
次に図14、図15を参照して、認証済ユーザAがA社サーバ200経由でバックエンドWebシステム2010(バックエンドWebサーバ)にアクセスするときの動作を示す。
【0054】
(クライアント端末A)
ユーザAがクライアント端末Aから、A社サーバ200にリクエストを送信する(S29)。
【0055】
(A社サーバ200)
A社サーバ200はリクエストを受信する(S30)。A社サーバ200の第2認証処理部210はリクエストに認証済みクッキーがあるかのチェックを行う(S31)。第2認証処理部210は認証済みクッキーがなければ(図14の場合)、通常の認証処理を実施する(S3〜S15)。認証済みクッキーが有れば(図15の場合)、第2認証処理部210は認証済みクッキーからユーザID、セッションID、有効期限を抽出し(S32)、認証済みクッキー管理テーブル230に該当レコード(認証履歴情報)があるかをチェックする(S33)。なければ通常の認証処理を実施し(S3〜S15)、あれば認可処理へ進む。
【0056】
以上のように、認証済情報の有効期限を管理することにより、認証済クッキーの改ざんを防ぎ、これにより成りすましなどの不正アクセスの可能性を減らすことが可能である。
【0057】
実施の形態5.
図16、図17を参照して実施の形態5を説明する。以上の実施の形態では、利用ユーザが明示的にログオフすることが出来ないため、利用後に不正アクセスされる可能性が残っている。そこで実施の形態5は、利用ユーザが明示的にログオフ要求し、認証済みクッキー管理テーブル230に記録されている認証済情報(ユーザID、セッションID、有効期限などを含む認証履歴情報)を削除する場合を示す。
【0058】
実施の形態5を示す構成図は、実施の形態2と同じである。
【0059】
図16に実施の形態5におけるA社サーバ200で認証処理されたユーザAがセンタサーバ100にログオフリクエストを送信した時のフローチャートを示す。図17は、図16をシーケンス化した図である。
【0060】
(クライアント端末A)
ユーザAがクライアント端末AからWebブラウザを使用して、センタサーバ100にログオフリクエスト(終了リクエスト)を送信する(S38)。つまりクライアント端末Aからセンタサーバ100にリクエスト(利用リクエスト)を送信して認証成立した場合である。
【0061】
(センタサーバ100)
センタサーバ100がログオフリクエストを受信する(S39)。センタサーバ100の第1認証処理部110は、認証済みクッキーの有無をチェックする(S31)。なければ第1認証処理部110はクライアント端末Aに認証済みクッキーがない旨の画面を送信する(S44)。あれば、第1認証処理部110は、認証済みクッキーからユーザID、セッションIDを抽出する(S32)。そして、第1認証処理部110は条件テーブル(111−1)を参照し、ユーザIDをもとに認証先を決定し(S34)、認証済みクッキーとともにログオフリクエストを認証先であるA社サーバ200に送信する(S40)。
【0062】
(A社サーバ200)
A社サーバ200の通信部240はログオフリクエスト付の認証済みクッキーを受信する(S41)。第2認証処理部210は、認証済みクッキーからユーザID、セッションIDを抽出する(S32)。第2認証処理部210は、抽出したユーザID、セッションIDの組み合わせが、認証済みクッキー管理テーブル230の認証履歴情報として存在するかをチェックする(S33)。第2認証処理部210は、なければない旨をセンタサーバ100に送信する(S43)。センタサーバ100は、クライアント端末Aに認証済情報がない旨の画面を送信する(S44)。認証済情報(認証履歴情報)があれば、第2認証処理部210は、認証済クッキー管理テーブル230の該当エントリ(該当する認証履歴情報)を削除し、ログオフが成功する(S42)。A社サーバ200はログオフ成功をセンタサーバ100に送信し(S45)、センタサーバ100は、クライアント端末Aにログオフ成功画面を送信する(S46)。
【0063】
以上のように、利用ユーザの明示的なログオフが可能となり、成りすましなどの不正アクセスの可能性を低減することが可能である。
【0064】
実施の形態6.
図18、図16を参照して実施の形態6を説明する。
【0065】
実施の形態6は、認証サーバ(センタサーバ100、A社サーバ200、B社サーバ300)をコンピュータで実現する場合の具体的な形態を説明する。センタサーバ100、A社サーバ200、B社サーバ300は、センタサーバ100がユーザ情報(ユーザ情報リポジトリ)を持たない以外は同様の構成であるので、センタサーバ100を例に説明する。
【0066】
図18は、センタサーバ装置の外観の一例を示す図である。図18において、センタサーバ100は、システムユニット830、CRT(Cathode・Ray・Tube)やLCD(液晶)の表示画面を有する表示装置813、キーボード814(Key・Board:K/B)、マウス815、FDD817(Flexible・Disk・ Drive)、コンパクトディスク装置818(CDD:Compact Disk Drive)、プリンタ装置819などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。
【0067】
図19は、コンピュータで実現されるセンタサーバ100のハードウェア資源の一例を示す図である。図19において、センタサーバ100、プログラムを実行するCPU810(Central Processing Unit)を備えている。CPU810は、バス825を介してROM(Read Only Memory)811、RAM(Random Access Memory)812、表示装置813、キーボード814、マウス815、通信ボード816、FDD817、CDD818、プリンタ装置819、磁気ディスク装置820と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置820の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
【0068】
RAM812は、揮発性メモリの一例である。ROM811、FDD817、CDD818、磁気ディスク装置820等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部、バッファの一例である。通信ボード816、キーボード814、FDD817などは、入力部、入力装置の一例である。また、通信ボード816、表示装置813、プリンタ装置819などは、出力部、出力装置の一例である。
【0069】
通信ボード816は、ネットワーク(LAN等)に接続されている。通信ボード816は、LANに限らず、インターネット、ISDN等のWAN(ワイドエリアネットワーク)などに接続されていても構わない。
【0070】
磁気ディスク装置820には、オペレーティングシステム821(OS)、ウィンドウシステム822、プログラム群823、ファイル群824が記憶されている。プログラム群823のプログラムは、CPU810、オペレーティングシステム821、ウィンドウシステム822により実行される。
【0071】
上記プログラム群823には、以上の実施の形態の説明において「〜部」として説明した機能を実行するプログラムが記憶されている。プログラムは、CPU810により読み出され実行される。
【0072】
ファイル群824には、以上の実施の形態の説明において、「条件テーブル(111−1)」、「アクセス制御情報テーブル」、あるいはA社サーバ200であれば、「ユーザ情報」、「認証済みクッキー管理情報」として説明したデータや、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明した情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU810によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのCPUの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【0073】
また、以上に述べた実施の形態の説明において、データや信号値は、RAM812のメモリ、FDD817のフレキシブルディスク、CDD818のコンパクトディスク、磁気ディスク装置820の磁気ディスク、その他光ディスク、ミニディスク、DVD(Digital・Versatile・Disk)等の記録媒体に記録される。また、データや信号は、バス825や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【0074】
また、以上の実施の形態の説明において、「〜部」として説明したものは、「〜手段」、「〜回路」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ROM811に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU810により読み出され、CPU810により実行される。すなわち、プログラムは、以上に述べた「〜部」としてコンピュータを機能させるものである。あるいは、以上に述べた「〜部」の手順や方法をコンピュータに実行させるものである。
【0075】
以上の実施の形態1〜5では、認証サーバ装置として、装置を説明したが、サーバ装置の動作を、コンピュータに実行させる認証先選定プログラム、あるいは認証先選定プログラムを記録したコンピュータ読み取り可能な記録媒体として把握することも可能である。さらに、認証サーバ装置の動作を認証サーバ装置が行う認証先選定方法として把握することも可能である。
【符号の説明】
【0076】
10,20,40 分散型認証連携システム、100 センタサーバ、110 第1認証処理部、111 条件テーブル格納部、111−1 条件テーブル、120 第1認可処理部、121 アクセス制御情報リポジトリ、121−1 アクセス制御情報テーブル、140 通信部、200 A社サーバ、210 第2認証処理部、211 ユーザ情報リポジトリ、220 第2認可処理部、221 アクセス制御情報リポジトリ、221−1 アクセス制御情報テーブル、222 条件テーブル格納部、240 通信部、300 B社サーバ、310 第3認証処理部、311 ユーザ情報リポジトリ、333 条件テーブル格納部、320 第3認可処理部、321 アクセス制御情報リポジトリ、340 通信部。
【特許請求の範囲】
【請求項1】
認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部を有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける認証先選定装置と、
前記システムを利用するクライアント端末装置と、
認証処理を実行する複数の前記認証装置と
を備え、
前記クライアント端末装置は、
前記認証先選定装置に前記利用リクエストを送信し、
前記認証先選定装置は、
前記利用リクエストを受信し、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより前記利用リクエストに対する認証処理を実行するべき前記認証装置を前記複数の認証装置のなかから選定し、選定された前記認証装置に前記利用リクエストに対する認証処理の実行を依頼し、
選定された前記認証装置は、
前記認証処理を実行して認証結果を前記認証先選定装置に送信し、
前記認証先選定装置は、
前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする認証先選定システム。
【請求項2】
前記選定された認証装置は、
前記認証処理により認証成立と判断した場合には、前記認証先選定装置によって作成される前記認証済み情報の有効期限を含む認証履歴情報を作成し、記憶することを特徴とする請求項1記載の認証先選定システム。
【請求項3】
前記クライアント端末装置は、
前記認証先選定装置に前記システムの利用終了を要求する終了リクエストを送信し、
前記認証先選定装置は、
前記終了リクエストを受信すると、前記終了リクエストに基づき前記認証装置選定条件情報を検索することにより前記終了リクエストに対応する前記選定された認証装置を特定し、特定された前記選定された認証装置に前記終了リクエストを送信し、
前記選定された認証装置は、
前記終了リクエストを受信すると、受信された前記終了リクエストに対応する前記認証履歴情報を破棄することを特徴とする請求項2記載の認証先選定システム。
【請求項4】
所定のシステムとデータをやりとりするシステム管理部と、
クライアント端末装置から、前記システムの利用を要求する利用リクエストを受信するリクエスト受信部と、
認証処理を実行する認証装置の選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部と、
前記リクエスト受信部によって受信された前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断する判断部と、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定する認証装置選定部と、
前記認証装置選定部によって選定された前記認証装置に、前記利用リクエストに対する認証処理の実行を依頼する認証処理依頼部と、
選定された前記認証装置から認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信する認証済み情報作成部と
を備えたことを特徴とする認証先選定装置。
【請求項5】
前記認証先選定装置は、さらに、
前記システムへのアクセス制限を示すアクセス権が定義されたアクセス制御情報を格納するアクセス制御情報格納部を備え、
前記システム管理部は、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていると判断されると、前記利用リクエストに基づいて前記アクセス制御情報を検索することにより、前記利用リクエストの送信元である前記クライアント端末装置のアクセス権を確認し、確認された前記アクセス権の範囲で前記クライアント端末装置による前記システムへのアクセスを許可することを特徴とする請求項4記載の認証先選定装置。
【請求項6】
前記認証済み情報作成部は、
前記認証済み情報を作成するときに、前記認証済み情報に有効期限を示す有効期限情報を付加し、
前記判断部は、
前記利用リクエストに前記認証済み情報が含まれていると判断した場合には、さらに、前記有効期限情報の示す有効期限が期限内かどうかを判断し、
前記認証装置選定部は、
前記判断部によって前記有効期限情報の示す有効期限が期限内ではないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定することを特徴とする請求項4または5のいずれかに記載の認証先選定装置。
【請求項7】
コンピュータを、
所定のシステムとデータをやりとりするシステム管理部、
クライアント端末装置から、前記システムの利用を要求する利用リクエストを受信するリクエスト受信部、
認証処理を実行する認証装置の選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部、
前記リクエスト受信部によって受信された前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断する判断部、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定する認証装置選定部、
前記認証装置選定部によって選定された前記認証装置に、前記利用リクエストに対する認証処理の実行を依頼する認証処理依頼部、
選定された前記認証装置から認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信する認証済み情報作成部、
として機能させるための認証先選定プログラム。
【請求項8】
請求項7記載の認証先選定プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項1】
認証処理を実行する認証装置を選定する選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部を有し、所定のシステムを管理すると共に前記システムの利用を要求する利用リクエストを受け付ける認証先選定装置と、
前記システムを利用するクライアント端末装置と、
認証処理を実行する複数の前記認証装置と
を備え、
前記クライアント端末装置は、
前記認証先選定装置に前記利用リクエストを送信し、
前記認証先選定装置は、
前記利用リクエストを受信し、前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断し、前記認証済み情報が前記利用リクエストに含まれていないと判断した場合は前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより前記利用リクエストに対する認証処理を実行するべき前記認証装置を前記複数の認証装置のなかから選定し、選定された前記認証装置に前記利用リクエストに対する認証処理の実行を依頼し、
選定された前記認証装置は、
前記認証処理を実行して認証結果を前記認証先選定装置に送信し、
前記認証先選定装置は、
前記認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信することを特徴とする認証先選定システム。
【請求項2】
前記選定された認証装置は、
前記認証処理により認証成立と判断した場合には、前記認証先選定装置によって作成される前記認証済み情報の有効期限を含む認証履歴情報を作成し、記憶することを特徴とする請求項1記載の認証先選定システム。
【請求項3】
前記クライアント端末装置は、
前記認証先選定装置に前記システムの利用終了を要求する終了リクエストを送信し、
前記認証先選定装置は、
前記終了リクエストを受信すると、前記終了リクエストに基づき前記認証装置選定条件情報を検索することにより前記終了リクエストに対応する前記選定された認証装置を特定し、特定された前記選定された認証装置に前記終了リクエストを送信し、
前記選定された認証装置は、
前記終了リクエストを受信すると、受信された前記終了リクエストに対応する前記認証履歴情報を破棄することを特徴とする請求項2記載の認証先選定システム。
【請求項4】
所定のシステムとデータをやりとりするシステム管理部と、
クライアント端末装置から、前記システムの利用を要求する利用リクエストを受信するリクエスト受信部と、
認証処理を実行する認証装置の選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部と、
前記リクエスト受信部によって受信された前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断する判断部と、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定する認証装置選定部と、
前記認証装置選定部によって選定された前記認証装置に、前記利用リクエストに対する認証処理の実行を依頼する認証処理依頼部と、
選定された前記認証装置から認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信する認証済み情報作成部と
を備えたことを特徴とする認証先選定装置。
【請求項5】
前記認証先選定装置は、さらに、
前記システムへのアクセス制限を示すアクセス権が定義されたアクセス制御情報を格納するアクセス制御情報格納部を備え、
前記システム管理部は、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていると判断されると、前記利用リクエストに基づいて前記アクセス制御情報を検索することにより、前記利用リクエストの送信元である前記クライアント端末装置のアクセス権を確認し、確認された前記アクセス権の範囲で前記クライアント端末装置による前記システムへのアクセスを許可することを特徴とする請求項4記載の認証先選定装置。
【請求項6】
前記認証済み情報作成部は、
前記認証済み情報を作成するときに、前記認証済み情報に有効期限を示す有効期限情報を付加し、
前記判断部は、
前記利用リクエストに前記認証済み情報が含まれていると判断した場合には、さらに、前記有効期限情報の示す有効期限が期限内かどうかを判断し、
前記認証装置選定部は、
前記判断部によって前記有効期限情報の示す有効期限が期限内ではないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定することを特徴とする請求項4または5のいずれかに記載の認証先選定装置。
【請求項7】
コンピュータを、
所定のシステムとデータをやりとりするシステム管理部、
クライアント端末装置から、前記システムの利用を要求する利用リクエストを受信するリクエスト受信部、
認証処理を実行する認証装置の選定条件が定義された認証装置選定条件情報を格納する認証装置選定条件情報格納部、
前記リクエスト受信部によって受信された前記利用リクエストに、すでに認証されていることを示す認証済み情報が含まれているかどうかを判断する判断部、
前記判断部によって前記認証済み情報が前記利用リクエストに含まれていないと判断されると、前記利用リクエストに基づき前記認証装置選定条件情報を検索することにより、前記利用リクエストに対する認証処理を実行するべき前記認証装置を選定する認証装置選定部、
前記認証装置選定部によって選定された前記認証装置に、前記利用リクエストに対する認証処理の実行を依頼する認証処理依頼部、
選定された前記認証装置から認証結果を受信し、前記認証結果が認証成立を示す場合には前記認証済み情報を作成し、作成された前記認証済み情報を前記クライアント端末装置に送信する認証済み情報作成部、
として機能させるための認証先選定プログラム。
【請求項8】
請求項7記載の認証先選定プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【公開番号】特開2010−205166(P2010−205166A)
【公開日】平成22年9月16日(2010.9.16)
【国際特許分類】
【出願番号】特願2009−52511(P2009−52511)
【出願日】平成21年3月5日(2009.3.5)
【出願人】(000006013)三菱電機株式会社 (33,312)
【Fターム(参考)】
【公開日】平成22年9月16日(2010.9.16)
【国際特許分類】
【出願日】平成21年3月5日(2009.3.5)
【出願人】(000006013)三菱電機株式会社 (33,312)
【Fターム(参考)】
[ Back to top ]