JPH0721127A - 認証確認システム - Google Patents

Abstract

(57)【要約】 【構成】 （Ｓ１０３）作成した認証要求データ１０１
に基づいて、認証要求データ検討処理を行う。（Ｓ１０
４）認証要求データ検討処理の結果が、ｆａｌｓｅな
ら、アプリケーションに認証が拒否されたことを通知す
る。（Ｓ１０５）結果が、ｔｒｕｅなら、認証サーバあ
るいは他の認証クライアントからの返事を待つ。（Ｓ１
０６）他の認証クライアントから認証の拒否を通知され
た場合、アプリケーションに拒否を伝える。（Ｓ１０
７）認証サーバからの認証データを受けて、文書の更新
処理を進める。 【効果】 様々に変化する流動的なグループ構成を単位
とした柔軟な認証機能を実現することにより、参加メン
バが動的に変化するような協調作業における認証をサポ
ートできる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、固有の権利を持った複
数のユーザによって利用される計算機環境において、そ
れらのユーザの種々のデータおよび操作の正当性を保証
して管理する認証確認システムに関する。

【０００２】更に詳述すれば、本発明は、特に複数人が
データベースシステムなどを介して協調作業を行う際に
好適な認証確認システムに関する。

【０００３】

【従来の技術】現在、データあるいは操作の正当性をシ
ステム側で保証するための認証メカニズムが検討されて
いる。

【０００４】従来、認証を行うためには、オペレーティ
ングシステムあるいは特定の認証サーバが個々のユーザ
情報を管理し、それらのユーザの独立な確認要求に答え
るという方法をとっていた。

【０００５】たとえば、あるオペレーティングシステム
では、オペレーティングシステム自身が管理しているユ
ーザ管理情報（典型的には、“／ｅｔｃ／ｐａｓｓｗ
ｄ”ファイルの情報）に基づいて、「各ユーザのファイ
ルへのアクセス要求」などの認証を行なっていた。

【０００６】具体的には、あるユーザがあるファイルを
読み出そうとする場合、あるオペレーティングシステム
では、そのファイルの読み書き許可属性（パーミッショ
ン）および所有者属性（オーナー）と、そのユーザの属
性とを比較し、読み出しを許しているかを検討する。そ
して、この検討を全ての読み出し操作時に行うことによ
って、操作およびファイルの正当性を保証している。

【０００７】

【発明が解決しようとする課題】しかしながら、上記従
来例では、複数のユーザが協調して作業を行う環境で必
要となる、次のような機能をサポートすることが難しい
という問題があった。

【０００８】（１）様々に変化する流動的なグループ構
成を単位とした柔軟な認証機能 （２）複数ユーザの連名要求についての認証機能 例えば、あるオペレーティングシステムで用意している
認証機能では、あるグループに属する個々のユーザ単独
のファイル・アクセス要求については、その要求を拒否
するが、ユーザ・グループの連名のファイル・アクセス
要求については、それを許可する機能が実現されていな
い。

【０００９】よって本発明の目的は上述の点に鑑み、協
調作業を行うアプリケーションにおいて必要となるグル
ープを単位とした認証機構を実現することにある。

【００１０】具体的には、協調作業中、単独のユーザで
認証を求めても拒否されるが、協調作業を行っている複
数のユーザが協力して（連名で）認証を求める場合に
は、承認されることを許す認証確認システムを提供する
ことにある。

【００１１】

【課題を解決するための手段】かかる目的を達成するた
めに、本発明は複数のユーザによる協調作業を扱い、該
協調作業を実行する際に認証を必要とするシステムにお
いて、システムの実行にかかわる複数のユーザを管理
し、認証要求を受け付ける認証確認手段と、システムの
実行にかかわる複数のユーザが協調して前記認証確認手
段に認証を求める協調手段と、協調作業を行っている他
のユーザに知らせることなく、各ユーザが署名をするた
めの可逆性のない暗号化を行う暗号化手段とを有し、前
記協調手段を介して情報を共有する複数のユーザが前記
暗号化手段により暗号化した署名を前記認証確認手段に
より認証するものである。

【００１２】

【作用】本発明の上記構成によれば、協調手段を用いて
情報を共有する複数のユーザが暗号化手段により暗号化
した署名を認証確認手段により認証することにより、グ
ループ認証をサポートすることができるようになる。

【００１３】このように、単独のユーザで認証を求めて
も拒否されるが、予め設定された複数のユーザが協調し
て認証を求める場合には認められる認証確認システムを
構成することにより、例えば、特に安全性を重視する貸
し金庫のような種類の情報システムに適用した場合、極
めて有用である。

【００１４】ここで認証とは、ある演算またはデータが
正当な手続・方式でなされたことをシステム側で保証す
ることをいう。

【００１５】

【実施例】以下、図面を参照して本発明の実施例を詳細
に説明する。

【００１６】実施例１ 本実施例では、複数のユーザの協調による校正作業中
に、文書データの更新のために認証を求めるためのシス
テムについて説明する。

【００１７】本実施例では、認証を求めるクライアント
間で通信を行う事により、複数ユーザの協調作業に必要
となる認証手段を提供している。

【００１８】すなわち、単独ユーザの要求では拒否され
てしまう認証要求であっても、校正作業に携わっている
複数のユーザの連名の要求によって認証可能とする「グ
ループ認証」の実現方法として、複数の認証クライアン
ト間の通信を用いているものである。

【００１９】ここで、認証クライアントとは、複数ユー
ザによる連名の署名を実現するための機能であり、ユー
ザごとに設定されるものとする。

【００２０】次に、本実施例の処理の流れについて説明
する。本実施例での処理は、協調作業による文書データ
の校正作業中、アプリケーションからの認証要求を受け
取った認証クライアントが、その認証に必要な協調作業
中のユーザの署名を回収し、最終的に、これらのユーザ
が協調して認証サーバに認証要求を出す処理である。

【００２１】図１は、本実施例における複数のユーザの
協調による認証要求処理のフローチャートである。

【００２２】（ａ）まず、協調による認証要求処理につ
いて説明する。

【００２３】図１に示したステップＳ１０１〜Ｓ１０７
の内容は、以下の通りである。

【００２４】（Ｓ１０１）あるユーザｋｕｒｏが文書デ
ータの校正中に、更新のための認証を要求する。

【００２５】（Ｓ１０２）認証クライアントは、アプリ
ケーションの実行中、認証が要求された時点で、認証要
求データ作成処理により認証要求データを作成する。例
えば、図６の認証要求データ１０１の通りである。

【００２６】（Ｓ１０３）作成した認証要求データ１０
１に基づいて、認証要求データ検討処理を行う。

【００２７】（Ｓ１０４）認証要求データ検討処理の結
果が、ｆａｌｓｅなら、アプリケーションに認証が拒否
されたことを通知する。

【００２８】（Ｓ１０５）結果が、ｔｒｕｅなら、認証
サーバあるいは他の認証クライアントからの返事を待
つ。

【００２９】（Ｓ１０６）他の認証クライアントから認
証の拒否を通知された場合、アプリケーションに拒否を
伝える。

【００３０】（Ｓ１０７）認証サーバからの認証データ
を受けて、文書の更新処理を進める。例えば、図６の認
証データ１１０の通りである。この例では、認証要求デ
ータに、有効期限と暗号化された認証サーバの署名が加
えられている。

【００３１】以上で、協調による認証要求処理の説明を
終了する。

【００３２】（ｂ）次に、図２を参照して認証要求デー
タ作成処理について説明する。

【００３３】ここでは、図６の認証要求データ１０１を
用いて、認証要求データの作成処理を説明する。図２に
示したステップＳ２０１〜Ｓ２０６の内容は、以下の通
りである。

【００３４】（Ｓ２０１）Ｓｕｂｊｅｃｔフィールド
に、要求する認証の対象を設定する。ここでは、ホスト
「ｈｏｓｔ＃４」上の文書識別子「ｄｏｃｕｍｅｎｔ＃
２８」で示される文書データを更新のためにアクセスす
る操作に対して認証を要求している。

【００３５】（Ｓ２０２）Ｒｅｑｕｅｓｔｅｒフィール
ドには、認証に必要な連名者の認証クライアント識別子
が並べられる。ここでは、ｋｕｒｏ，ｋａｔｏ，ｓａｔ
ｏの３つである。

【００３６】（Ｓ２０３）Ｉｓｓｕｅｄ−ｂｙフィール
ドには、この認証要求を発行した認証クライアント識別
子を設定する。認証処理が途中で失敗した場合には、そ
れに通知する。

【００３７】（Ｓ２０４）Ｒｅｐｌｙ−ｔｏフィールド
には、得られた認証を利用するアプリケーションの認証
クライアント識別子を設定する。認証処理が成功した場
合には、それに通知する。

【００３８】（Ｓ２０５）Ｗａｉｔｉｎｇフィールドに
は、得られた認証を利用するアプリケーションの識別子
とそのアプリケーションの認証窓口を示す。ここでは、
「ａｐｐｌｉｃａｔｉｏｎ＃３」というアプリケーショ
ンが、窓口「ｐｏｒｔ＃５４３０６」で待っていること
を示す。

【００３９】（Ｓ２０６）Ｄａｔｅフィールドには、こ
の認証要求データが作成された日付を示す。

【００４０】なお、ここでは説明のためテキスト表現を
使っているが、実際の認証要求データでは、何らかのコ
ード化がされていても良い。

【００４１】また、図６の認証要求データ１０１に示し
たデータの項目は説明を容易にするためのものであり、
必ずしも必要ではない。

【００４２】以上で、認証要求データ作成処理の説明を
終了する。

【００４３】（ｃ）次に、図３を参照して認証要求デー
タ検討処理について説明する。図３に示したステップＳ
３０１〜Ｓ３０８の内容は、以下の通りである。

【００４４】（Ｓ３０１）認証要求データを受け取る。

【００４５】（Ｓ３０２）認証要求データに含まれる要
求内容，要求日時，連名者などから、その要求の妥当性
を検討する。

【００４６】このためには、たとえば、各認証クライア
ントが独自の認可データベースを保持している。

【００４７】（Ｓ３０３）もし、要求が妥当でないなら
ば、ｆａｌｓｅを返す。

【００４８】（Ｓ３０４）もし、要求が妥当でないなら
ば、自分の署名を暗号化したものをＲｅｑｕｅｓｔｅｒ
フィールドの自分の識別子（例えば、ｓａｔｏ）のあと
に加える（ここでは、説明のため、カギ括弧の中に記入
してある。） （Ｓ３０５）Ｒｅｑｕｅｓｔｅｒフィールドを調べる。

【００４９】（Ｓ３０６）もし、全ての連名者の署名が
終わっているなら、認証を得るためにこの認証要求デー
タを認証サーバに送る。例えば、図６の認証要求データ
１０３の通りである。

【００５０】（Ｓ３０７）反対に、まだ未署名者が残っ
ているならば、その認証クライアントにこの認証要求デ
ータを転送する。例えば、図６の認証要求データ１０２
の通りである。

【００５１】（Ｓ３０８）ｔｒｕｅを返す。

【００５２】なお、ここでは、他の認証クライアントか
らの要求に対して、要求を受けたユーザのデータベース
を検索する事で説明したが、そのユーザに対して会話的
に承認を求める事も可能である。

【００５３】図６の認証要求データ１０２あるいは１０
３では、説明のため、暗号化した署名として長さ１３の
文字列を示したが、これは、適切な桁数の数、あるい
は、別のデータ構造であっても良い。

【００５４】また、暗号化した署名を加える時、その暗
号化のために、認証要求データの一部あるいは全てを対
象とし、これによって署名したユーザの認証の他に、メ
ッセージに改ざんが加えられていない事を保証させる事
も容易に実施可能である。

【００５５】以上で、認証要求データ検討処理の説明を
終了する。

【００５６】（ｄ）次に、図４を参照して転送された認
証要求データの処理について説明する。図４に示したス
テップＳ４０１〜Ｓ４０４の内容は、以下の通りであ
る。

【００５７】（Ｓ４０１）他の認証クライアントから、
認証要求データを受け取る。

【００５８】（Ｓ４０２）受けとった認証要求データに
基づいて、認証要求データ検討処理を行う。

【００５９】（Ｓ４０３）検討結果がｆａｌｓｅなら、
要求を拒否し、要求の発信元に認証を拒否したことを伝
える。

【００６０】（Ｓ４０４）検討結果がｔｒｕｅなら、こ
の処理を終える。

【００６１】以上で、転送された認証要求データの処理
の説明を終了する。

【００６２】図８は、本実施例における複数のユーザの
協調による認証の処理の概要図である。

【００６３】なお本実施例では、認証クライアントが、
認証サーバに確認要求する例について説明したが、ユー
ザと直接通信する認証クライアントと中央の認証サーバ
とが、同レベルのサーバであっても良い。つまり、複数
の認証サーバが通信しあって、１つの認証機能を実現し
ている分散認証環境であっても良い。

【００６４】逆に、中央の認証サーバが階層化されてい
て、必要に応じて別の認証サーバへ確認要求を転送する
ことにより、最終的な認証を行なっても良い。

【００６５】なお、別のサーバに認証要求を転送する場
合に、中継サーバの履歴情報を付加して、この履歴情報
を認証要求データ検討処理において利用することも可能
である。

【００６６】また、本実施例では、アプリケーションの
認証を受け持つ認証クライアントが存在する説明をした
が、認証クライアントの認証要求の処理は、ライブラリ
化されアプリケーションの中に組み込まれていても良
い。

【００６７】また、認証クライアントがアプリケーショ
ン単位に存在する説明をしたが、認証クライアントの設
定は、アプリケーション単位であっても、ユーザ単位で
も、または、プロジェクト単位であっても良い。

【００６８】さらに、本実施例では３名が協調作業を行
う例について述べたが、２名以下でも、４名以上であっ
ても良い。

【００６９】以上をもって、本実施例の処理の流れにつ
いての説明を終了する。

【００７０】図９は、本発明における実施例１を実現す
るためのシステム構成図である。本図において、１１お
よび１２は、それぞれのサイトにおいて、本実施例の処
理を行うためのＣＰＵ、２１および２２は、それぞれの
サイトにおいて、ＣＰＵ，通信装置および記憶装置を結
合する計算機バス、３１および３２は、それぞれのサイ
トにおいて、ネットワークを介して、情報を交換するた
めの通信装置、４１および４２は、それぞれのサイトに
おいて、各種プログラムやデータを実行あるいは利用す
るための記憶装置、５０は、サイトＡに置かれた認証サ
ーバ、５１および５２は、それぞれのサイトにおいて、
アプリケーションの要求を受け取り、認証サーバあるい
は他の認証クライアントと協調して認証処理を行う認証
クライアント、６１および６２は、それぞれのサイトに
おいて、本実施例の文書校正処理を行う文書校正アプリ
ケーション、７は以上のように構成されたサイト間を結
ぶネットワーク（たとえば、イーサネットあるいはＦＤ
ＤＩ）である。

【００７１】なお、ここでは説明を簡単にするために、
各種プログラムやデータを同一の記憶装置に配置してい
るが、それぞれ別の記憶装置を使ってもよい。また、二
時記憶装置に保持しておき、必要に応じて主記憶装置に
配置し直しても良い。

【００７２】また、この説明図は、認証サーバがサイト
Ａに配置されているが、認証サーバは、サイトＢにあっ
ても、ネットワークにつながった他のサイトにあっても
良い。

【００７３】実施例２ 以下に詳述する第２の実施例では、第１の実施例と同じ
く、複数ユーザが協調して認証を要求する例について述
べるが、認証クライアントの一つに、特定のユーザとし
て『公証人』が含まれる点で異っている。

【００７４】本実施例では、この『公証人』を利用した
公文書データの登録処理について説明する。

【００７５】本実施例の処理の流れについて説明する。

【００７６】本処理は、文書を公文書として登録するた
めに、特別のユーザ『公証人』をパートナーとした協調
作業を行う。協調作業における認証要求は、第１の実施
例と同様に説明できる。

【００７７】本実施例の場合の認証要求データは、図７
の認証要求データ２０１および２０２のようになる。ま
た、認証データは、図７の認証データ２１０のようにな
る。

【００７８】第１の実施例の認証要求データ検討処理に
おいて、協調作業する他のユーザの認証クライアント
は、独自の認可データベースを確認し、単純に署名して
いた。しかし、『公証人』の認証クライアントの場合
は、図５に示すような以下のような操作を行う。

【００７９】（ｅ）図５を参照して、『公証人』の認証
クライアントにおける認証要求データ検討処理について
説明する。図５に示したステップＳ５０１〜Ｓ５０９の
内容は、以下の通りである。

【００８０】（Ｓ５０１）認証要求データを受け取る。

【００８１】（Ｓ５０２）要求内容に示された文書識別
子（以下、５０１という）を調べ、認証要求の発信元か
らその文書を受け取ることを『公証人』に要求する。

【００８２】（Ｓ５０３）『公証人』は、受け取った文
書を自分の署名として暗号化する。それを暗号５０２と
する。

【００８３】（Ｓ５０４）上記文書識別子５０１と暗号
５０２のペアを、『公証人』のデータベースに加える。

【００８４】（Ｓ５０５）暗号５０２を『公証人』の認
証クライアントの暗号化された署名として、認証要求デ
ータのＲｅｑｕｅｓｔｅｒフィールドの自分の識別子
（ここでは、＊ｎｏｔａｒｙ＊）のあとに加える。

【００８５】本実施例では、暗号５０２は、「ｈＳｒＫ
ｍ７ＢｅｔＮＷｌｏ」と示される。

【００８６】（Ｓ５０６）Ｒｅｑｕｅｓｔｅｒフィール
ドを調べる。

【００８７】（Ｓ５０７）もし、全ての連名者の署名が
終わっているなら、認証を得るためにこの認証要求デー
タを認証サーバに送る。

【００８８】（Ｓ５０８）反対に、まだ未署名者が残っ
ているならば、その認証クライアントにこの認証要求デ
ータを転送する。

【００８９】（Ｓ５０９）ｔｒｕｅを返す。

【００９０】これによって、『公証人』は、審議の対象
となった文書に、上記Ｓ５０３で用いた暗号化処理と同
一の暗号化処理を適用し、登録しておいた暗号５０２と
の比較を行うことによって、文書全体の正当性を検証す
ることが可能になる。

【００９１】ここでは、異なった文書を暗号化した結
果、偶然同一の暗号が得られる確率が極めて小さいとい
う特徴を利用して、文書の改ざんの有無を調べる例につ
いて説明したが、『公証人』が、文書全体をデータベー
スに蓄えることで、改ざんの有無を調べられるようにす
ることも、可能である。

【００９２】以上で、『公証人』の認証クライアントに
おける認証要求データ検討処理の説明を終了する。

【００９３】なお本実施例においては、文書データを公
文書として登録する例について説明したが、公文書を更
新する場合にも同様に説明できる。この場合、更新以前
の文書と更新後の文書とを比較して、文書の差分が大き
過ぎる場合には、『公証人』が連名を拒否するような機
能を追加することも容易に可能である。

【００９４】以上をもって、本実施例の処理の流れにつ
いての説明を終了する。

【００９５】

【発明の効果】以上説明したとおり本発明によれば、複
数のユーザによる協調作業などを扱い、その実行に認証
が必要となるシステムにおいて、情報を共有する複数の
ユーザが協調して認証確認を要求することにより、以下
のような効果が得られる。

【００９６】（１）様々に変化する流動的なグループ構
成を単位とした柔軟な認証機能を実現することにより、
参加メンバが動的に変化するような協調作業における認
証をサポートできる。

【００９７】（２）複数ユーザの連名要求についての認
証機能を実現することにより、従来不可能だった複数人
による認証要求が可能になる。

【００９８】（３）しかも、協調するユーザの中に『公
証人』や『貸し金庫管理人』のような特別のユーザを組
み込むことにより、特別な認証機能の付加が容易にな
る。

【図面の簡単な説明】

【図１】本発明における実施例１を説明するためのフロ
ーチャートである。

【図２】実施例１の認証要求データ作成処理を説明する
ためのフローチャートである。

【図３】実施例１の認証要求データ検討処理を説明する
ためのフローチャートである。

【図４】実施例１の転送された認証要求データの処理を
説明するためのフローチャートである。

【図５】実施例２の『公証人』の認証クライアントにお
ける認証要求データ検討処理を説明するためのフローチ
ャートである。

【図６】実施例１で取り扱う認証要求データおよび認証
データを説明するための図である。

【図７】実施例２で取り扱う認証要求データおよび認証
データを説明するための図である。

【図８】本発明におけるグループ認証を説明するための
概要図である。

【図９】実施例１におけるシステム構成図である。

【符号の説明】

Ｓ１０２ 認証要求データの作成処理 Ｓ１０３ 認証要求データの検討処理

Claims (7)

【特許請求の範囲】
1. 【請求項１】 複数のユーザによる協調作業を扱い、該
   協調作業を実行する際に認証を必要とするシステムにお
   いて、 システムの実行にかかわる複数のユーザを管理し、認証
   要求を受け付ける認証確認手段と、 システムの実行にかかわる複数のユーザが協調して前記
   認証確認手段に認証を求める協調手段と、 協調作業を行っている他のユーザに知らせることなく、
   各ユーザが署名をするための可逆性のない暗号化を行う
   暗号化手段とを有し、 前記協調手段を介して情報を共有する複数のユーザが前
   記暗号化手段により暗号化した署名を前記認証確認手段
   により認証することを特徴とする認証確認システム。
2. 【請求項２】 請求項１において、前記認証確認手段
   は、ユーザの情報を保持したデータベースを利用し、そ
   のデータベースに問い合わせることにより認証を実現す
   ることを特徴とする認証確認システム。
3. 【請求項３】 請求項１において、前記認証確認手段
   は、オペレーティングシステムに備わっているユーザ管
   理機能を利用することを特徴とする認証確認システム。
4. 【請求項４】 請求項１において、前記認証確認手段
   は、分散環境に対応した、通信し合う複数の認証サーバ
   から構成されることを特徴とする認証確認システム。
5. 【請求項５】 請求項１において、前記協調手段は、各
   ユーザあるいは各アプリケーションに対応する複数の認
   証サーバを利用し、それらの認証サーバ間で通信しあう
   ことにより、協調作業を実現することを特徴とする認証
   確認システム。
6. 【請求項６】 請求項１において、前記協調手段は、ユ
   ーザ間でプロトコルを定め、直接通信することにより、
   協調作業を実現することを特徴とする認証確認システ
   ム。
7. 【請求項７】 請求項１において、前記協調手段は、認
   証サーバとの通信インターフェースを備えた認証クライ
   アントを用意し、該認証クライアントにより各ユーザあ
   るいは各アプリケーションの協調作業を助けることを特
   徴とする認証確認システム。