(57)【特許請求の範囲】
【請求項１】
クライアント・アプリケーション（１０１）と、サーバ・アプリケーション（１０２）と、リソース・ロケーション（１０３）と、前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の認証済み１次通信チャネル（１０４）と、前記サーバ・アプリケーション（１０２）と前記リソース・ロケーション（１０３）との間の認証済み１次通信チャネル（１０５）とを有するシステム（１００）における認証のための方法であって、
前記クライアント・アプリケーション（１０１）が前記サーバ・アプリケーション（１０２）との２次通信チャネル（１０６）を作成するステップ（１２１、１２２）と、
前記クライアント・アプリケーション（１０１）が、前記２次通信チャネル（１０６）によりアクセスを許可するための要求（１２３）を前記サーバ・アプリケーション（１０２）に対してサブミットするステップと、
前記サーバ・アプリケーション（１０２）が、前記リソース・ロケーション（１０３）に保管すべき認証トークン（１４３）の生成を開始するステップであって、前記認証トークン（１４３）が前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記認証済み１次通信チャネル（１０４）により前記クライアント・アプリケーションにとってアクセス可能であるステップと、
前記クライアント・アプリケーション（１０１）が、前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記認証済み１次通信チャネル（１０４）により前記リソース・ロケーションから前記認証トークン（１４３）のコピー（１４５）を取り出すステップ（１２７、１２８）と、
前記クライアント・アプリケーション（１０１）が、前記２次通信チャネル（１０６）により前記サーバ・アプリケーション（１０２）に前記認証トークンのコピー（１４５）を返すステップ（１２９）と、
前記クライアント・アプリケーション（１０１）によって返された前記認証トークンのコピー（１４５）が前記リソース・ロケーション（１０３）に保管された前記生成された認証トークン（１４３）と一致することをチェックすることにより、前記サーバ・アプリケーション（１０２）が前記クライアント・アプリケーション（１０１）を認証するステップと、
前記認証が成功したときに、前記サーバ・アプリケーション（１０２）が前記２次通信チャネル（１０６）により前記クライアント・アプリケーション（１０１）に対してアクセスを許可するステップと、
を含む、方法。
【請求項２】
前記認証トークン（１４３）が、前記サーバ・アプリケーション（１０２）へのアクセスを要求した前記クライアント・アプリケーション（１０１）を含む特権ユーザのみにとってアクセス可能である、請求項１記載の方法。
【請求項３】
前記リソース・ロケーション（１０３）に保管された前記認証トークン（１４３）が、前記クライアント・アプリケーション（１０１）と前記サーバ・アプリケーション（１０２）との間の前記２次通信チャネル（１０６）の単一確立のために生成されている、請求項１記載の方法。
【請求項４】
前記生成された認証トークン（１４３）が統計的にランダムなビット・パターンである、請求項１記載の方法。
【請求項５】
前記リソース・ロケーション（１０３）がファイル・システムである、請求項１記載の方法。
【請求項６】
前記ファイル・システムが前記サーバ・アプリケーション（１０２）および前記クライアント・アプリケーション（１０１）のうちの少なくとも一方のローカル・ファイル・システムであり、前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０４）および前記サーバ・アプリケーション（１０２）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０５）のうちの少なくとも一方が、前記ファイル・システムのオペレーティング・システムのサービスによって提供された認証メカニズムを使用する、請求項５記載の方法。
【請求項７】
前記ファイル・システムが前記クライアント・アプリケーション（１０１）および前記サーバ・アプリケーション（１０２）のうちの少なくとも一方のためのリモート・ファイル・システムであり、前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０４）および前記サーバ・アプリケーション（１０２）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０５）のうちの少なくとも一方が、それぞれ、前記クライアント・アプリケーション（１０１）および前記サーバ・アプリケーション（１０２）のうちの少なくとも一方の接続および認証のために前記リモート・ファイル・システムの装着を使用する、請求項５記載の方法。
【請求項８】
前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０４）および前記サーバ・アプリケーション（１０２）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０５）のうちの少なくとも一方が認証済みネットワーク通信プロトコルを使用し、前記ネットワーク通信プロトコルがセキュア・ソケット・レイヤ（ＳＳＬ）であり、前記リソース・ロケーション（１０３）に保管された前記認証トークン（１４３）がユニフォーム・リソース・ロケータ（ＵＲＬ）によって識別される、請求項１記載の方法。
【請求項９】
前記生成された認証トークン（１４３）が前記リソース・ロケーション（１０３）に保管される前に、前記２次通信チャネル（１０６）が確立されている（１２１、１２２）、請求項１記載の方法。
【請求項１０】
前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０４）および前記サーバ・アプリケーション（１０２）と前記リソース・ロケーション（１０３）との間の前記１次通信チャネル（１０５）が暗号化され、前記クライアント・アプリケーション（１０１）が前記サーバ・アプリケーション（１０２）との前記２次通信チャネル（１０６）を作成する（１２１、１２２）前に、前記生成された認証トークン（１４３）が前記リソース・ロケーション（１０３）に保管される、請求項１記載の方法。
【請求項１１】
前記クライアント・アプリケーション（１０１）がデータベース・ドライバのクライアント・コンポーネントであり、前記サーバ・アプリケーション（１０２）が前記データベース・ドライバのサーバ・コンポーネントである、請求項１記載の方法。
【請求項１２】
クライアント・アプリケーション（１０１）を実行しているクライアント・デバイスと、サーバ・アプリケーション（１０２）を実行しているサーバ・デバイスと、リソース・ロケーション（１０３）と、前記クライアント・デバイスと前記リソース・ロケーションとの間の認証済み１次通信チャネル（１０４）と、前記サーバ・デバイスと前記リソース・ロケーション（１０３）との間の認証済み１次通信チャネル（１０５）とを有する認証のためのシステム（１００）であって、
前記クライアント・アプリケーション（１０１）が前記サーバ・アプリケーション（１０２）との２次通信チャネル（１０６）を作成する手段（１２１、１２２）と、
前記クライアント・アプリケーション（１０１）が、前記２次通信チャネル（１０６）によりアクセスを許可するための要求（１２３）を前記サーバ・アプリケーション（１０２）に対してサブミットする手段と、
前記サーバ・アプリケーション（１０２）が、前記リソース・ロケーション（１０３）に保管すべき認証トークン（１４３）の生成を開始する手段であって、前記認証トークン（１４３）が前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記認証済み１次通信チャネル（１０４）により前記クライアント・アプリケーションにとってアクセス可能である手段と、
前記クライアント・アプリケーション（１０１）が、前記クライアント・アプリケーション（１０１）と前記リソース・ロケーション（１０３）との間の前記認証済み１次通信チャネル（１０４）により前記リソース・ロケーションから前記認証トークン（１４３）のコピー（１４５）を取り出す手段（１２７、１２８）と、
前記クライアント・アプリケーション（１０１）が、前記２次通信チャネル（１０６）により前記サーバ・アプリケーション（１０２）に前記認証トークン（１４５）を返す手段（１２９）と、
前記クライアント・アプリケーション（１０１）によって返された前記認証トークンのコピー（１４５）が前記リソース・ロケーション（１０３）に保管された前記生成された認証トークン（１４３）と一致することをチェックすることにより、前記サーバ・アプリケーション（１０２）が前記クライアント・アプリケーション（１０１）を認証する手段と、
前記認証が成功したときに、前記サーバ・アプリケーション（１０２）が前記２次通信チャネル（１０６）により前記クライアント・アプリケーション（１０１）に対してアクセスを許可する手段と、
を含む、システム。
【請求項１３】
前記クライアント・アプリケーション（１０１）と前記サーバ・アプリケーション（１０２）が同じデバイスで実行されている、請求項１２記載のシステム。
【請求項１４】
前記サーバ・デバイスおよび前記クライアント・デバイスのうちの少なくとも一方が前記リソース・ロケーション（１０３）をさらに含む、請求項１２または１３記載のシステム。
【請求項１５】
データ処理システムで認証を行うためのコンピュータ・プログラムであって、前記データ処理システムに、請求項１ないし１１のいずれか１項に記載の方法の各ステップを実行させる、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・システムにおける認証の方法、この方法を実行するためのコンピュータ・システム、およびこの方法を実行するためのプログラム・コード部分を含むコンピュータ・プログラム（computer program product）に関する。
【背景技術】
【０００２】
クライアント・アプリケーションはサーバ・アプリケーションのリソースにアクセスする必要がある。クライアント・アプリケーションは、サーバ・アプリケーションとの通信チャネルをオープンする。通信チャネルは、通常、認証されておらず、これは、どのクライアント・アプリケーションでも接続を確立できることを意味する。クライアント・アプリケーションがサーバ・アプリケーションのリソースにアクセスする前に、クライアント・アプリケーションは、クライアント・アプリケーション・ユーザの名前を識別することにより、サーバ・アプリケーションから認証を要求する。クライアント・アプリケーション・ユーザを認証するために、サーバ・アプリケーションは、実際のクライアント・アプリケーション・ユーザによってのみ解答できるパズル（puzzle）である確認のための呼び掛け（challenge）をクライアント・アプリケーションに送信する。クライアント・アプリケーションはそのパズルに対する解答を返送する。サーバ・アプリケーションはその解答を検証し、その結果、クライアント・アプリケーションを認証し、クライアント・アプリケーションに対してサーバ・アプリケーションのリソースへのアクセスを許可する。
【０００３】
従来技術の実装例では、確認のための呼びかけは、サーバ・アプリケーションからのメッセージであって、クライアント・アプリケーションがクライアント・アプリケーション・ユーザの鍵で暗号化するメッセージにすることができるであろう。このメッセージは、セキュリティ・エンジニアリングでは「１回使用の数」として知られ、１回の通信セッションについてのみ生成されたｎｏｎｃｅにすることができるであろう。ｎｏｎｃｅは任意のランダム・データまたはタイムスタンプにすることができる。クライアント・アプリケーション・ユーザの鍵は、クライアント・アプリケーションとサーバ・アプリケーションの両方がコピーを有する対称鍵である。あるいは、その鍵は、クライアント・アプリケーションが秘密鍵を有し、サーバ・アプリケーションが対応する公開鍵を有する、非対称鍵である。クライアントは、暗号化されたメッセージをサーバ・アプリケーションに返送する。サーバ・アプリケーションは、それぞれクライアント・アプリケーション・ユーザの対称鍵または公開鍵でそのメッセージを暗号化解除し、この暗号化解除されたメッセージがサーバ・アプリケーションからクライアント・アプリケーションに送信されたメッセージと一致することを検証する。検証が成功すると、サーバ・アプリケーションは、そのメッセージがそれぞれクライアント・アプリケーション・ユーザの対称鍵または秘密鍵の所有者によって暗号化されたものと推論し、暗号化されたメッセージの送信側を認証する。
【０００４】
従来技術では、代替認証方法は、非対称鍵によるパスワードの暗号化および暗号化解除に基づくものである。クライアント・アプリケーションは、暗号化された通信チャネルによりサーバ・アプリケーションにパスワードを送信する。通信チャネルはサーバ・アプリケーション・ユーザの公開鍵で暗号化することができ、その公開鍵は、暗号化して通信チャネルによりサーバ・アプリケーションにパスワードを送信する前に、公然と使用可能であるかまたはクライアント・アプリケーションに渡されている。サーバ・アプリケーションは、サーバ・アプリケーション・ユーザの秘密鍵により、パスワードを含む受信メッセージを暗号化解除できる唯一のものである。サーバ・アプリケーションがサーバ・アプリケーション・ホスト上で実行されている場合、サーバ・アプリケーションは、クライアント・アプリケーションから入手したパスワードを使用して、サーバ・アプリケーション・ホストの基礎となるオペレーティング・システムから認証を要求することができる。
【０００５】
従来技術では、Ｋｅｒｂｅｒｏｓアルゴリズムは、中央認証サーバを介してサーバ・アプリケーションによるクライアント・アプリケーションの認証を使用する。詳細は、たとえば、２００２年プレンティスホール社発行のＣ．Ｋａｕｆｍａｎ他による「Ｎｅｔｗｏｒｋ  Ｓｅｃｕｒｉｔｙ」に記載されている。Ｋｅｒｂｅｒｏｓアルゴリズムは本質的に以下のように機能する。すなわち、クライアント・アプリケーションは、サーバ・アプリケーションによる認証のためのチケットを返すよう、中央認証サーバに要求を送信する。認証サーバは、セッション鍵を創作し、サーバ・アプリケーション・ユーザの公開鍵または対称鍵でセッション鍵およびクライアント・アプリケーション・ユーザの名前を暗号化することによりサーバ・アプリケーションのためのチケットを作成する。創作されたセッション鍵、サーバ・アプリケーションのための生成されたチケット、およびサーバ・アプリケーション・ユーザの名前はいずれも、クライアント・アプリケーション・ユーザの公開鍵または対称鍵で暗号化される。中央認証サーバは、暗号化されたメッセージをクライアント・アプリケーションに送信する。クライアント・アプリケーション・ユーザは、クライアント・アプリケーション・ユーザの秘密鍵または対称鍵により、受信メッセージを暗号化解除できる唯一のものである。クライアント・アプリケーション・ユーザのみがそのメッセージを暗号化解除でき、そのメッセージがサーバ・アプリケーション・ユーザの名前を含むので、クライアント・アプリケーション・ユーザは、中央認証サーバから受信したメッセージを使用してサーバ・アプリケーションによりクライアント・アプリケーションを認証できることを検証する。クライアント・アプリケーションは、サーバ・アプリケーションのためのチケットと、セッション鍵で暗号化されたタイムスタンプをサーバ・アプリケーションに送信する。サーバ・アプリケーション・ユーザは、サーバ・アプリケーション・ユーザの秘密鍵または対称鍵により、チケットを暗号化解除し、セッション鍵およびクライアント・アプリケーション・ユーザの名前を取り出せる唯一のものである。サーバ・アプリケーションは、中央認証サーバがチケット内に挿入したクライアント・アプリケーション・ユーザの名前を認識し、したがって、サーバ・アプリケーションにより送信側のクライアント・アプリケーションを認証するためにそのチケットが使用される。サーバ・アプリケーションは、暗号化解除されたチケットからのセッション鍵を使用して、暗号化されたタイムスタンプを暗号化解除し、それを妥当性検査する。チケットおよびタイムスタンプを基礎として、サーバ・アプリケーションは、サーバ・アプリケーションへのアクセスを要求したクライアント・アプリケーションに対してアクセスを許可する。
【０００６】
中央認証サーバの暗号化は、中央認証サーバからのメッセージをクライアント・アプリケーション・ユーザのみが暗号化解除でき、中央認証サーバが作成し、クライアント・アプリケーションがサーバ・アプリケーションに送信したチケットをサーバ・アプリケーション・ユーザのみが暗号化解除できることを保証する。
【０００７】
Ｋｅｒｂｅｒｏｓアルゴリズムでは、クライアント・アプリケーション・ユーザは、サーバ・アプリケーション・ユーザのパスワードまたは鍵を把握せずに、サーバ・アプリケーションによりそれ自体を認証する。反対に、サーバ・アプリケーションは、クライアント・アプリケーション・ユーザの鍵またはパスワードを保管する必要はない。しかし、中央認証サーバは、クライアント・アプリケーション・ユーザとサーバ・アプリケーション・ユーザ両方の公開鍵または対称鍵を保管しなければならない。
【０００８】
サーバ・アプリケーションが基礎となるオペレーティング・システムの認証メカニズムにアクセスできない場合、従来技術には不利点となる。この場合、サーバ・アプリケーションは、クライアント・アプリケーションから受信したパスワードを使用して、クライアント・アプリケーション・ユーザを認証することができない。
【０００９】
従来技術の第２の不利点は、パスワードを送信するときに通信チャネルを暗号化しなければならないことである。クライアント・アプリケーションおよびサーバ・アプリケーションのうちの少なくとも一方は、通信チャネルによる安全なデータ交換のために必要なパスワードまたはｎｏｎｃｅの暗号化および暗号化解除を実装しなければならない。暗号化および暗号化解除プログラム・コードの実装は複雑である。
【００１０】
Ｋｅｒｂｅｒｏｓアルゴリズムは、チケット生成メカニズムを備えた中央認証サーバと、
クライアント・アプリケーション・ユーザおよびサーバ・アプリケーション・ユーザの対称鍵または非対称鍵を使用するメッセージの暗号化および暗号化解除に基づくものである。認証サーバならびにクライアント・アプリケーション側およびサーバ・アプリケーション側の暗号化および暗号化解除のためのプログラム・コードのセットアップおよび実装も複雑である。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】２００２年プレンティスホール社発行のＣ．Ｋａｕｆｍａｎ他による「Ｎｅｔｗｏｒｋ  Ｓｅｃｕｒｉｔｙ」
【発明の概要】
【発明が解決しようとする課題】
【００１２】
したがって、本発明の一目的は、クライアント・アプリケーションとサーバ・アプリケーションとの間に認証されておらず暗号化されていない２次通信チャネルを確立した後、サーバ・アプリケーションによりクライアント・アプリケーションを認証するための簡易化した方法およびシステムを提供することである。
【課題を解決するための手段】
【００１３】
本発明のこの目的は、クライアント・アプリケーションと、サーバ・アプリケーションと、リソース・ロケーションと、クライアント・アプリケーションとリソース・ロケーションとの間の認証済み１次通信チャネルと、サーバ・アプリケーションとリソース・ロケーションとの間の認証済み１次通信チャネルとを有するシステムにおける認証のための方法によって達成される。認証済み通信チャネルとは、クライアント・アプリケーションとリソース・ロケーションとの間の通信チャネルを確立するクライアント・アプリケーション・ユーザがリソース・ロケーションによって認証されることを意味する。サーバ・アプリケーションとリソース・ロケーションとの間の認証済み通信チャネルにも同じことが適用され、リソース・ロケーションがサーバ・アプリケーション・ユーザを認証する。リソース・ロケーションのみが、１組の特権ユーザのための通信チャネルの確立を可能にし、リソース・ロケーションとの通信チャネルを作成したユーザのＩＤを把握する。１次通信チャネルは必ず暗号化する必要はなく、これは、侵入アプリケーション（intruding application）が通信チャネル上で盗聴し、送信メッセージを読むことができることを意味する。
【００１４】
クライアント・アプリケーションとサーバ・アプリケーションとの間に２次的な直接通信チャネル接続を確立するために、クライアント・アプリケーションはサーバ・アプリケーションとの２次通信チャネルを作成し、この通信チャネルは通常、認証されず、暗号化されない。どのクライアント・アプリケーションでも、サーバ・アプリケーションとの通信チャネルを作成することができる。サーバ・アプリケーションは、通信チャネル接続を確立したクライアント・アプリケーション・ユーザのＩＤを把握していない。クライアント・アプリケーションは、２次通信チャネルによりアクセスを許可するための要求をサーバ・アプリケーションに対してサブミットし、クライアント・アプリケーション・ユーザのＩＤをサーバ・アプリケーションに伝える。サーバ・アプリケーションは以下の方法でクライアント・アプリケーション・ユーザを認証する。すなわち、サーバ・アプリケーションは認証トークンの生成を開始する。サーバ・アプリケーションは、認証トークンそのものを作成するかまたは認証トークンを生成するようリモート・サーバに要求することができる。認証トークンは、１回使用の数またはワードであるｎｏｎｃｅ、たとえば、統計的にランダムなビット・パターンまたは暗号化されたタイムスタンプにすることができる。サーバ・アプリケーションは、リソース・ロケーションに認証トークンを保管し、クライアント・アプリケーション・ユーザが認証トークンにアクセスする権利を有するようにアクセス許可を設定することを開始する。サーバ・アプリケーションがリソース・ロケーションに生成された認証トークンを保管するときに、サーバ・アプリケーション・ユーザは、リソース・ロケーションにアクセスし、リソース・ロケーションに認証トークンを保管し、クライアント・アプリケーション・ユーザを含む特権ユーザのみがクライアント・アプリケーションとリソース・ロケーションとの間の認証済み１次通信チャネルにより認証トークンにアクセスできるようにアクセス許可を設定するための書き込みおよび作成許可を有する。クライアント・アプリケーションは少なくとも認証トークンを読み取るための許可を得ていなければならない。サーバ・アプリケーションへのアクセスを要求する非特権ユーザは、認証トークンにアクセスし、それにより、認証トークンを読み取るかまたは変更する権利を持っていてはいけない。サーバ・アプリケーション・ユーザおよびおそらくシステム管理者は、通常、特権ユーザであり、認証トークンにアクセスするための許可を得ている。クライアント・アプリケーションは、クライアント・アプリケーションとリソース・ロケーションとの間の認証済み１次通信チャネルにより認証トークンのコピーを取り出す。クライアント・アプリケーションは、２次通信チャネルによりサーバ・アプリケーションに認証トークンのコピーを返す。サーバ・アプリケーションは、サーバ・アプリケーションの開始時に、クライアント・アプリケーションによって返された認証トークンのコピーがリソース・ロケーションに保管された生成された認証トークンと一致することをチェックする。認証トークンの受信したコピーと保管されている認証トークンが同一であることをサーバ・アプリケーションが証明すると、サーバ・アプリケーションはクライアント・アプリケーションを認証し、２次通信チャネルによりクライアント・アプリケーションに成功メッセージを返し、クライアント・アプリケーションに対してアクセスを許可する。認証トークンの受信したコピーが保管されている認証トークンとは異なる場合、サーバ・アプリケーションは、２次通信チャネルによりエラー・メッセージを返し、クライアント・アプリケーションに対してアクセスを拒否する。
【００１５】
本発明の好ましい一実施形態では、クライアント・アプリケーションは、生成された認証トークンがリソース・ロケーションに保管される前に、サーバ・アプリケーションとの２次通信チャネルを確立している。２次通信チャネルは、それによりサーバ・アプリケーションがクライアント・アプリケーションから認証トークンを受信することを予期する唯一の通信チャネルである。これは、１次通信チャネルを必ず暗号化する必要がないことを意味する。侵入クライアント・アプリケーションが１次認証済み通信チャネルのいずれかで盗聴し、認証トークンを読み取り、サーバ・アプリケーションとの他の２次通信チャネルを確立した場合、要求側クライアント・アプリケーションとの２次通信チャネルがすでに作成されているので、サーバ・アプリケーションは、侵入クライアント・アプリケーションに対してアクセスを拒否することになるであろう。
【００１６】
クライアント・アプリケーションはクライアント・デバイスで実行され、サーバ・アプリケーションはサーバ・デバイスで実行されている。リソース・ロケーションは、クライアント・デバイス、サーバ・デバイス、および第３のデバイスのうちの１つにある。
【００１７】
本発明の好ましい実施形態では、クライアント・デバイスおよびサーバ・デバイスは、それぞれ個別のファイル・システムを備えた個別のホスト・システムであり、リソース・ロケーションはサーバ・アプリケーション・ホストのローカル・ファイル・システムである。クライアント・アプリケーション・ホストは、リモート・ファイル・システムとしてサーバ・アプリケーション・ホストのファイル・システムを装着し、オペレーティング・システム・サービスによって提供されたリモート・ファイル・システムの装着の認証メカニズムを使用して、リモート・ファイル・システムのファイルにアクセスする。サーバ・アプリケーションは、サーバ・アプリケーション・ユーザを本質的に認証するローカル・ファイル・システムのオペレーティング・システム・サービスを使用して、ローカル・ファイル・システムのファイルへのアクセスを許可する。
【００１８】
本発明の好ましい実施形態では、クライアント・アプリケーションはデータベース・ドライバのクライアント・コンポーネントであり、サーバ・アプリケーションはデータベース・ドライバのサーバ・コンポーネントである。
【００１９】
本発明の代替一実施形態では、クライアント・アプリケーションとサーバ・アプリケーションは同じデバイスで実行されている。これは、それらが１つのローカル・ファイル・システムを備えた同じホスト・システムで実行できることを意味する。クライアント・アプリケーションは、アクセスを許可するための要求をサーバ・アプリケーションに送信する。この要求は、クライアント・アプリケーション・ユーザの名前を含むが、パスワードを含まない。サーバ・アプリケーションは基礎となるオペレーティング・システムの認証メカニズムにアクセスできないので、サーバ・アプリケーションはクライアント・アプリケーション・ユーザのパスワードを使用することができない。サーバ・アプリケーションは共通ファイル・システムのロケーションに生成された認証トークンを保管し、そこでクライアント・アプリケーションは認証トークンを容易に読み取ることができる。クライアント・アプリケーションは認証トークンのコピーをサーバ・アプリケーションに送信する。サーバ・アプリケーションは、認証トークンを検証し、クライアント・アプリケーションに対してアクセスを許可する。
【００２０】
本発明の第２の代替実施形態では、リソース・ロケーションはファイル・サーバ・ホストのファイル・システムであり、このホストはクライアント・アプリケーション・ホストおよびサーバ・アプリケーション・ホストのいずれとも別個のものである。クライアント・アプリケーション・ホストおよびサーバ・アプリケーション・ホストは、それぞれリモート・ファイル・システムとしてファイル・サーバ・ホストのファイル・システムを装着し、オペレーティング・システム・サービスによって提供された認証メカニズムを使用して、リモート・ファイル・システムのファイルにアクセスする。
【００２１】
本発明の第３の代替実施形態では、リソース・ロケーションは認証サーバまたはデータベース・サーバにすることができる。
【００２２】
本発明の第４の代替実施形態では、クライアント・アプリケーションとリソース・ロケーションとの間の１次通信チャネルおよびサーバ・アプリケーションとリソース・ロケーションとの間の１次通信チャネルのうちの少なくとも一方は、認証済みネットワーク通信プロトコルを使用する。ネットワーク通信プロトコルはセキュア・ソケット・レイヤ（ＳＳＬ：secure socket layer）にすることができ、リソース・ロケーションに保管された認証トークンはユニフォーム・リソース・ロケータ（ＵＲＬ：uniform resource locator）によって識別することができる。
【００２３】
本発明の第５の代替実施形態では、サーバ・アプリケーションは、クライアント・アプリケーションがサーバ・アプリケーションとの２次通信チャネルを作成してしまう前に、生成された認証トークンをリソース・ロケーションに保管することを開始する。クライアント・アプリケーション・ユーザは、認証トークンにアクセスしてそれを読み取り、サーバ・アプリケーションとの２次通信チャネルを作成し、認証トークンのコピーをサーバ・アプリケーションに送信することができ、サーバ・アプリケーションは最終的にクライアント・アプリケーションを認証する。しかし、この場合、１次通信チャネルを暗号化しなければならない。１次通信チャネルが暗号化されていない場合、侵入クライアント・アプリケーションは１次通信チャネルのいずれかで盗聴し、サーバ・アプリケーションとの２次通信チャネルを作成し、そのために認証トークンが生成されたクライアント・アプリケーション・ユーザになりすまし、盗んだ認証トークンのコピーを誤用してサーバ・アプリケーションに送信し、サーバ・アプリケーションに対して許可されたアクセス権を得ることができるであろう。
【００２４】
本発明の第６の代替実施形態では、クライアント・アプリケーションがサーバ・アプリケーションで置き換えられ、逆もまた同じである。クライアント・アプリケーションとリソース・ロケーションとの間の１次通信チャネルはサーバ・アプリケーションとリソース・ロケーションとの間の１次通信チャネルで置き換えられ、逆もまた同じである。クライアント・アプリケーションとサーバ・アプリケーションとの間でこのように役割を交換した後、対応するやり方で上記の認証方法を適用することができる。
【００２５】
本発明の第７の代替実施形態では、クライアント・アプリケーションおよびサーバ・アプリケーションのうちの少なくとも一方は、スマート・カード・デバイスで実行されている。
【００２６】
本発明の方法は、コンピュータ・システムで実行することができ、この方法の諸ステップを実行するためのコンピュータ・プログラム・コード部分を含み、データ処理システムで実行するためのコンピュータ・プログラムに実装することがでる。
【００２７】
本発明は、例として示されており、図面内の各図の形状によって限定されない。
【図面の簡単な説明】
【００２８】
【図１】本発明によるトークンベースの認証システムの概略ブロック図表現である。
【図２】本発明による認証トークンベースの認証方法の流れ図およびプロセス図表現である。
【図３】本発明による認証トークンベースの認証方法の流れ図およびプロセス図表現である。
【図４】本発明による認証トークンベースの認証方法の流れ図およびプロセス図表現である。
【発明を実施するための形態】
【００２９】
図面および明細書には、本発明の好ましい一実施形態が規定されており、特定の用語が使用されているが、このように示されている記述では、限定のためではなく、一般的かつ説明的意味でのみ専門用語を使用している。しかし、特許請求の範囲に規定されている本発明のより広い精神および範囲を逸脱せずにそれに対して様々な修正および変更を行うことができることは明白になるであろう。
【００３０】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせで実現することができる。任意の種類のコンピュータ・システム、あるいは本明細書に記載された方法を実行するために適合されたその他の装置が適している。ハードウェアとソフトウェアの典型的な組み合わせは、ロードされ実行されたときに、それが本明細書に記載された方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを備えた汎用コンピュータ・システムにすることができるであろう。また、本発明は、本明細書に記載された方法の実装を可能にするすべての特徴を含み、コンピュータ・システムにロードされたときにこれらの方法を実行することができる、コンピュータ・プログラムに組み込むこともできる。
【００３１】
コンピュータ・プログラム手段またはコンピュータ・プログラムは、これに関連して、直接もしくはａ）他の言語、コード、または表記への変換、またはｂ）異なる物質的形式による複製のいずれか一方あるいは両方の後、情報処理機能を有するシステムに特定の機能を実行させるための１組の命令を任意の言語、コード、または表記で表した任意の表現を意味する。
【００３２】
図１は、クライアント・アプリケーション（１０１）と、サーバ・アプリケーション（１０２）と、リソース・ロケーション（１０３）とを含む、認証のためのシステム（１００）を示している。クライアント・アプリケーション（１０１）およびサーバ・アプリケーション（１０２）はそれぞれ、認証済み１次通信チャネル（１０４）および（１０５）によりリソース・ロケーション（１０３）にアクセスする。
【００３３】
１次通信チャネル（１０４）および（１０５）は必ず暗号化されるわけではなく、すなわち、第三者がチャネル（１０４）および（１０５）により送信されたデータを読み取ることができるであろう。通信チャネル（１０４）は、クライアント・アプリケーションがリソース・ロケーション（１０３）のアクセス制御されたリソース、たとえば、リモート・ファイル・システム内の被制御アクセス権を有するファイルにアクセスするための経路を提供する。
【００３４】
クライアント・アプリケーション（１０１）は、ユーザ名およびパスワードを入力することによりクライアント・アプリケーションにログオン（１１１）したクライアント・アプリケーション・ユーザのために認証済みログオン・セッションで実行される。
【００３５】
サーバ・アプリケーション（１０２）は、オペレーティング・システム・サービスによって確立されたサーバ・アプリケーション・ユーザのために認証済みログオン・セッションで実行される。
【００３６】
クライアント・アプリケーション（１０１）は、サーバ・アプリケーション（１０２）との２次通信チャネル（１０６）を確立する予定である。２次通信チャネル（１０６）は、クライアント・アプリケーションをデータベース・サーバに接続するデータベース・ドライバのクライアント・コンポーネントとサーバ・コンポーネントとの間の通信ソケットにすることができる。データベース・ドライバのサーバ・コンポーネントは、データベース・サーバの基礎となるオペレーティング・システムの認証メカニズムにアクセスして、クライアント・アプリケーション・ユーザの受信パスワードを認証に使用することができない可能性がある。したがって、クライアント・アプリケーション（１０１）は、サーバ・アプリケーション（１０２）との２次的な非認証２次通信チャネル（１０６）を作成し（１２１、１２２）、これは、その通信チャネルがユーザ資格情報を必要とせずに、どのクライアント・アプリケーションでも接続を確立できることを意味する。通信チャネル（１０６）は必ず暗号化されるわけではない。
【００３７】
クライアント・アプリケーション（１０１）は、確立された非認証２次通信チャネル（１０６）によりクライアント・アプリケーション・ユーザのために実行されているクライアント・アプリケーションを認証するよう、サーバ・アプリケーション（１０２）に要求（１２３）を送信する。この要求は、クライアント・アプリケーション・ユーザの名前を含む。
【００３８】
サーバ・アプリケーション（１０２）は認証トークン（１４１）を生成し、これは統計的にランダムなビット・パターンまたは暗号化されたタイムスタンプにすることができる。ＩＤ妥当性検査の信頼性は、認証トークン（１４１）のランダム生成器の品質によって決まる。サーバ・アプリケーションは、特定の名前およびロケーションとともにリソース・ロケーション（１０３）に認証トークン（１４３）を「ドロップオフする」、すなわち、保管する（１２４、１２５）。サーバ・アプリケーションは、クライアント・アプリケーション・ユーザを含む特権ユーザのグループのみがその認証トークンの読み取りを許可されるように、認証トークン（１４３）のファイル・アクセス許可を設定する。クライアント・アプリケーション・ユーザの名前は、サーバ・アプリケーションとの２次通信チャネルの認証に関する要求（１２３）に含まれている。しかし、非特権ユーザは、認証トークンへのアクセスを許可されてはならない。サーバ・アプリケーション・ユーザと、通常、システム管理者は、認証トークン（１４３）にアクセスする権利を有する特権ユーザのグループに属している。
【００３９】
サーバ・アプリケーション（１０２）は、２次通信チャネル（１０６）によりクライアント・アプリケーション（１０１）に応答を返し（１２６）、その応答はリソース・ロケーション（１０３）に保管された認証トークン（１４３）の名前およびロケーションを含むことができる。
【００４０】
クライアント・アプリケーション（１０１）は、認証済み１次通信チャネル（１０４）によりリソース・ロケーション（１０３）から認証トークンを「回復する」、すなわち、読み取る（１２７、１２８）。サーバ・アプリケーション（１０２）との２次通信チャネル（１０６）を要求したクライアント・アプリケーション・ユーザまたはクライアント・アプリケーション・ユーザの資格情報を有する任意のアプリケーション・ユーザは、認証トークン（１４３）にアクセスし、それを読み取ることが許可されている特権ユーザのうちの１人である。クライアント・アプリケーション（１０１）は、２次通信チャネル（１０６）により認証トークン（１４３）のコピー（１４５）をサーバ・アプリケーション（１０２）に返す（１２９）。
【００４１】
サーバ・アプリケーション（１０２）は、予期された２次通信チャネル（１０６）により認証トークン（１４３）のコピー（１４６）を受信する。これは、それによりサーバ・アプリケーション（１０２）がクライアント・アプリケーション・ユーザを認証するための要求（１２３）に応答して認証トークン（１４３）のコピー（１４６）を受信することを予期する、唯一の通信チャネルである。
【００４２】
サーバ・アプリケーション（１０２）は、認証トークン（１４３）の受信した（「回復した」）コピー（１４６）が、サーバ・アプリケーションがリソース・ロケーション（１０３）に保管（「ドロップオフ」）し、クライアント・アプリケーション・ユーザのみがアクセス可能な認証トークン（１４３）と一致することを検証する。保管されている認証トークン（１４３）は生成された認証トークン（１４１）と同一である。
【００４３】
検証が成功した場合、サーバ・アプリケーション（１０２）との非認証２次通信チャネル（１０６）を確立したユーザは、本人の主張通りのユーザである。サーバ・アプリケーション（１０２）は、クライアント・アプリケーションとの２次通信チャネル（１０６）を認証し、クライアント・アプリケーション（１０１）に対してアクセスを許可する。サーバ・アプリケーションは、クライアント・アプリケーション・ユーザが認証されたという確認メッセージを２次通信チャネル（１０６）によりクライアント・アプリケーションに返す（１３０）ことができる。
【００４４】
検証が失敗した場合、すなわち、認証トークンのコピー（１４６）が保管されている認証トークン（１４３）または生成された認証トークン（１４１）とは異なる場合、サーバ・アプリケーションは、アクセスを拒否し、２次通信チャネル（１０６）によりクライアント・アプリケーションにアプリケーション・エラーを返す（１３０）。
【００４５】
クライアント・アプリケーション（１０１）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０４）およびサーバ・アプリケーション（１０２）とリソース・ロケーション（１０３）との間の１次通信チャネルのうちの少なくとも一方が暗号化されない場合、サーバ・アプリケーションがリソース・ロケーション（１０３）に認証トークンを保管する前にサーバ・アプリケーション（１０２）との非認証２次通信チャネル（１０６）が確立されることが重要である。サーバ・アプリケーション（１０２）は、確立された２次通信チャネル（１０６）のみにより認証トークンを予期する。
【００４６】
図２は、本発明の認証方法の流れ図およびプロセス図を含んでいる。２次通信チャネル（１０６）を確立するための要求（２１１）に応答して、クライアント・アプリケーション（２０１）はサーバ・アプリケーション（２０２）との非認証２次通信チャネル（１０６）を作成する（２１２、２３１、２３２）。クライアント・アプリケーション（２０１）はこの通信チャネル（１０６）を使用して、サーバ・アプリケーション（２０２）に対して要求（２１３、２３３）をサブミットする。サーバ・アプリケーション・ユーザおよびおそらくシステム管理者に加えてクライアント・アプリケーション・ユーザがそれを読み取ることができる唯一のものになるように、サーバ・アプリケーション（２０２）は認証トークンを生成し（２１４）、それをリソース・ロケーション（２０３）に保管する（２１５、２３４、２３５）。サーバ・アプリケーション（２０２）は、クライアント・アプリケーション（２０１）に応答を返す（２１６、２３６）。次に、クライアント・アプリケーション（２０１）は、クライアント・アプリケーション（２０１）とリソース・ロケーション（２０３）との間の１次通信チャネル（１０４）により認証トークンのコピーを取り出し（２１７、２３７、２３８）、２次通信チャネル（１０６）を使用してそれをサーバ・アプリケーション（２０２）に返す（２１８、２３９）。サーバ・アプリケーション（２０２）は、認証トークンの受信したコピーが、リソース・ロケーション（２０３）に保管されており、クライアント・アプリケーション・ユーザのみが読み取りアクセス可能な、生成された認証トークンと一致することを検証する。検証が成功した場合、サーバ・アプリケーションは、２次通信チャネル（１０６）により成功メッセージを返し（２２０、２４０）、クライアント・アプリケーション（２０１）に対してアクセスを許可する（２２２）。検証が失敗した場合、サーバ・アプリケーション（２０２）は、２次通信チャネル（１０６）によりクライアント・アプリケーション（２０１）にエラー・メッセージを返送し（２２１、２４０）、クライアント・アプリケーション（２０１）に対してアクセスを拒否する（２２３）。
【００４７】
図３は、クライアント・アプリケーション（３０１）とサーバ・アプリケーション（３０２）との間に２次通信チャネル（１０６）が確立される前に、サーバ・アプリケーション（３０２）が初期設定（３１１）時に認証トークンを生成し（３１２）、それをリソース・ロケーション（３０３）に保管する（３１３、３２１、３２２）、代替実施形態を示している。この代替実施形態では、生成された認証トークンと、サーバ・アプリケーションとの２次通信チャネル（１０６）を作成し、認証トークンのコピーをサーバ・アプリケーションに送信することが予期されているクライアント・アプリケーション・ユーザとの間に１対１の関係がある。
【００４８】
図４は、２次通信チャネルが確立される前に生成された認証トークンがリソース・ロケーション（４０３）に保管された場合の代替実施形態の方法ステップを示している。２次通信チャネル（１０６）によりクライアント・アプリケーション・ユーザのために実行されているクライアント・アプリケーションを認証するための要求（４１１）に応答して、クライアント・アプリケーションは、リソース・ロケーション（４０３）から認証トークンのコピーを取り出す（４１２、４２１、４２２）。クライアント・アプリケーション・ユーザは、サーバ・アプリケーション・ユーザおよびおそらくシステム管理ユーザに加えて、認証トークンにアクセスするための唯一の特権ユーザである。
【００４９】
クライアント・アプリケーションは、サーバ・アプリケーションとの非認証２次通信チャネル（１０６）を作成し（４１３、４２３、４２４）、２次通信チャネル（１０６）によりサーバ・アプリケーションに認証トークンのコピーを返す（４１４、４２５）。サーバ・アプリケーションは、認証トークンの受信したコピーが、特定のクライアント・アプリケーション・ユーザについてサーバ・アプリケーションが保管している認証トークンと一致することを検証する（４１５）。検証の結果に応じて、サーバ・アプリケーションは、成功メッセージ（４１６）またはエラー・メッセージ（４１７）を送信し（４２６）、クライアント・アプリケーションに対してそれぞれアクセスを許可する（４１８）かまたは拒否する（４１９）。
【００５０】
クライアント・アプリケーション（１０１）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０４）およびサーバ・アプリケーション（１０２）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０５）のうちの少なくとも一方が暗号化されていない場合、第三者がその通信チャネルから認証トークンのコピーを読み取り、サーバ・アプリケーションとの非認証２次通信チャネルを確立し、それのために認証トークンが作成されたクライアント・アプリケーション・ユーザであると主張することができるであろう。２次通信チャネル（１０６）が確立される前に認証トークンがリソース・ロケーションに保管された場合に認証トークンの誤用を回避するために、クライアント・アプリケーション（１０１）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０４）およびサーバ・アプリケーション（１０２）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０５）を暗号化しなければならない。
【００５１】
クライアント・アプリケーション（１０１）とサーバ・アプリケーション（１０２）との間の２次通信チャネル（１０６）により初めて認証トークンを送信する場合、侵入クライアント・アプリケーションが２次通信チャネル（１０６）で盗聴し、認証トークンのコピーを読み取れる前に、サーバ・アプリケーションは通常、認証トークンのコピーを受信することになる。この場合、２次通信チャネルを必ず暗号化する必要はない。少なくとも１つの通信チャネルにより、少なくとも複数回、認証トークンの任意のコピーを送信する場合、複数のチャネルを順々に使用する場合でも、対応する通信チャネルを暗号化することが必須である。
【００５２】
クライアント・アプリケーション（１０１）の役割をサーバ・アプリケーション（１０２）とスワップし、クライアント・アプリケーション（１０１）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０４）の役割をサーバ・アプリケーション（１０２）とリソース・ロケーション（１０３）との間の１次通信チャネル（１０５）とスワップするだけで、クライアント・アプリケーション（１０１）は、クライアント・アプリケーション・ユーザがサーバ・アプリケーションにより認証するのとまったく同じやり方で、サーバ・アプリケーション・ユーザのＩＤを検証することができる。この逆方向の認証の場合には、サーバ・アプリケーションがクライアント・アプリケーションとの非認証２次通信チャネル（１０６）を確立し、アクセスを許可するための要求をクライアント・アプリケーションに対してサブミットする。クライアント・アプリケーションは、認証トークンを生成し、それをリソース・ロケーションに保管することを開始し、読み取られる認証トークンは、アクセスの許可を要求したサーバ・アプリケーションのユーザにとってアクセス可能なものである。サーバ・アプリケーションは、認証済み１次通信チャネル（１０５）によりリソース・ロケーションから認証トークンのコピーを取り出し、２次通信チャネル（１０６）によりクライアント・アプリケーションに認証トークンのコピーを返す。クライアント・アプリケーションは、サーバ・アプリケーションによって返された認証トークンのコピーが、クライアント・アプリケーションによってリソース・ロケーション（１０３）に保管された認証トークンと一致することを検証する。
【図１】
0005619019.tif 000002
【図２】
0005619019.tif 000003
【図３】
0005619019.tif 000004
【図４】
0005619019.tif 000005