サーバベースのコンピュータシステムにおけるリモート認証のための方法および装置
サーバベースのコンピュータ環境におけるサーバに、ユーザをリモートに認証するための方法および装置である。クライアントコンピュータデバイスは、ユーザ証明を受信し、受信された証明に基づいて、ユーザ認証データを生成する。クライアントコンピュータデバイスは、サーバコンピュータデバイスに、生成されたユーザ認証データを送信する。サーバコンピュータデバイスは、送信されたユーザ認証データに応答して、ユーザを認証する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバベースのコンピュータシステムにおける分散されたアプリケーション処理を提供するため、特に、そのようなシステムにおける認証テクニックをリモートするための、方法および装置に関する。
【背景技術】
【０００２】
ネットワークされたリソースにリモートアクセスを提供するための技術は、様々なクライアント／サーバソフトウェアの組み合わせを含む。これらの技術の一つは、しばしば「シン（ｔｈｉｎ−ｃｌｉｅｎｔ）」または「サーバベースのコンピュータ」システムとして言及される。これらのシステムにおいて、アプリケーションプログラムは、一つ以上のクライアントコンピュータデバイスのために、サーバコンピュータデバイスによって実行される。アプリケーションへのクライアント入力およびアプリケーション出力は、クライアントコンピュータデバイスとサーバコンピュータデバイスとの間にて送信される。これらのシステムは、一般に、アプリケーションがサーバコンピュータデバイスによってユーザのために実行され得る前に、ユーザ自身を認証するためにクライアントコンピュータデバイスのユーザを要求する。
【０００３】
クライアントコンピュータデバイスは、ユーザがデバイスを使用する前に、ローカルにログオンすることを要求し得る。クライアントコンピュータデバイスにローカルにログオンすることは、通常ユーザ名およびパスワードを要求するが、多数のクライントオペレーティングシステムは、例えば、ユーザが、トークンベースのスキーム、スマートカード、または指紋のようなバイオメトリックを用いてログオンすることを要求するように、ログオンメカニズムが置き換えられることを許す。
【０００４】
クライアントコンピュータデバイスに認証するにも関わらず、ユーザは、しばしば、サーバコンピュータデバイスに認証する必要もある。しかしながら、上述されたような置換ログオンメカニズムが使用される場合、サーバコンピュータデバイスがしばしばユーザ名およびパスワードのみを許可するため、ユーザは、サーバコンピュータデバイスに認証できな得ない。ユーザが、バイオメトリックまたはスマートカードのようなテクニックを用いて認証した場合、ユーザは、サーバコンピュータデバイスに認証するために有用な有効ユーザ名−パスワード組み合わせを知り得ない。一部の技術は、ユーザ供給されたユーザ名−パスワード組み合わせのクライアントコンピュータデバイスによる傍受（ｉｎｔｅｒｃｅｐｔ）を許す。しかしながら、これらの技術は、標準の認証メカニズムが置き換えられた場合、作用しない。
【０００５】
したがって、シンクライアントシステムのユーザをリモートに認証する改良された方法が望まれる。
【発明の開示】
【課題を解決するための手段】
【０００６】
一局面において、本発明は、クライアントコンピュータデバイスのユーザをリモートに認証するために、Ｆｔ．Ｌａｕｄｅｒｄａｌｅ，Ｆｌｏｒｉｄａに在るＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．によって生産されるＩＣＡプロトコルまたはＲｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＲＤＰプロトコルのようなシンクライアントプロトコルと結合して、産業標準のＧｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を使用する。
【０００７】
他の局面においては、本発明は、ネットワークプロバイダにパススルー認証の代替方法を提供することによってセキュリティを強化する。クライアントコンピュータデバイスがサーバコンピュータデバイスにユーザ認証証明、例えば、パスワード、を送信する代わりに、認証仮想チャネルドライバは、シンクライアントプロトコル内にて仮想チャネルを通じて認証データを送信する。ユーザ認証データは、ユーザのアイデンティティを検証するために使用され得るが、ユーザの裏に隠された認証証明を明らかにはしない。送信されたユーザ認証データは、サーバコンピュータデバイスにユーザを認証するために使用される。クライアントは、したがって、ユーザ認証証明に一度もアクセスしない。管理者特権を要求し、認証証明をクライアントコンピュータデバイス上の任意のローカルな処理に利用可能にする、ネットワークプロバイダをインストールすることは要求されない。ユーザの認証証明は、どの形においても、ネットワークを通じて送信されない。リモート認証は、サーバコンピュータデバイスの裏に隠されたオペレーティングシステムによって実行される。
【０００８】
本発明の一局面においては、クライアントコンピュータデバイスは、ユーザ証明を受信し、受信された証明に基づいてユーザ認証データを生成する。クライアントコンピュータデバイスは、サーバコンピュータデバイスに、生成されたユーザ認証データを送信する。サーバコンピュータデバイスは、ユーザ認証データに応答してユーザを認証する。サーバは、受信されたユーザ認証データに基づいて、新しいユーザ認証データを生成する。サーバは、第２のサーバに、新しいユーザ認証データを送信する。第２のサーバは、受信されたユーザ認証データに応答して、ユーザを認証する。一実施形態において、ユーザは、第１のサーバと第２のサーバとの間の接続を通じて、利用可能なリソースにアクセスする。
【０００９】
他の局面においては、本発明は、ユーザのリモート認証に対して認証データを交換するために、ＩＣＡプロトコルまたはＲＤＰプロトコル内にて仮想チャネルを使用する。仮想チャネルは、データをエンドポイント間にて送信する目的のために、二つ以上のエンドポイント間における任意の論理的結合である。
【００１０】
他の局面においては、本発明は、認証のためにＧＳＳＡＰＩを使用する。したがって、本発明は、Ｋｅｒｂｅｒｏｓ認証方法のようなＧＳＳＡＰＩ実施によってサポートされる任意の認証方法を用いて作用し、ＧＳＳＡＰＩをサポートする任意のクライアントコンピュータプラットフォームまたはデバイスに使用され得る。
【００１１】
本発明の他の局面においては、ユーザ認証証明（例、パスワード）は、クライアントまたはサーバのどちらもによって、あからさまに傍受（ｉｎｔｅｒｃｅｐｔｅｄ）または扱われない。ユーザ認証証明は、クライアントコンピュータデバイスとサーバコンピュータデバイスとの間において送信されない。
【００１２】
本発明の他の局面においては、クライアントコンピュータデバイスは、サーバコンピュータデバイスを認証し、サーバコンピュータデバイスは、クライントコンピュータデバイスのユーザを認証する。
【００１３】
本発明の他の局面においては、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標)における委任（ｄｅｌｅｇａｔｉｏｎ）セキュリティポリシーが支持される。例えば、「アカウントは敏感であり、委任されるべきではない」を設定するユーザアカウントが可能になった場合、そのユーザは、他のサーバにログオンするために、このリモート認証テクニックを使用できない。
【発明を実施するための最良の形態】
【００１４】
本発明のこれらおよび他の局面は、本発明を限定するのではなく、示すことを意味する、下記の詳細な説明および添付の図面から明らかになるであろう。
【００１５】
本発明の例示的実施形態は、リモートユーザがコンテンツへのアクセスをリクエストする、分散されたネットワーク環境に適用可能である。本発明の特質を説明する前に、本発明の例示的実施形態が使用され得る一部のネットワーク環境を議論することが、役に立ち得る。
【００１６】
図１を参照すると、簡潔な概要において、本発明が使用され得るクライアントサーバシステムの一実施形態が示される。第１のコンピュータデバイス（クライントコンピュータデバイス）１００は、通信ネットワーク１８０を通じて、第２のコンピュータデバイス（サーバコンピュータデバイス）１４０と通信する。一部の実施形態において、第２のコンピュータデバイスは、クライアントデバイス１００でもある。クライントデバイス１００がサーバデバイス１４０と通信するネットワーク１８０のトポロジは、バス、スター、またはリングトポロジになり得る。ネットワーク１８０は、構内情報通信網（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、またはインターネットのような広域情報通信網（ＷＡＮ）になり得る。
【００１７】
クライアントおよびサーバデバイス１００，１４０は、標準電話線、ＬＡＮまたはＷＡＮリンク（例、Ｔ１，Ｔ３，５６ ｋｂ，Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、フレームリレー、ＡＴＭ）、および無線接続を含む様々な接続を介して、ネットワーク１８０に接続できる。接続は、様々な通信プロトコルを使用して確立され得る（例、ＴＣＰ／ＩＰ，ＩＰＸ，ＳＰＸ，ＮｅｔＢＩＯＳ，ＮｅｔＢＥＵＩ，ＳＭＢ，Ｅｔｈｅｒｎｅｔ（登録商標），ＡＲＣＮＥＴ，Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ），ＲＳ２３２，ＩＥＥＥ ８０２．１１，ＩＥＥＥ ８０２．１１ａ，ＩＥＥ ８０２．１１ｂ，ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）。他のクライアントデバイスおよびサーバデバイス（図示せず）は、ネットワーク１８０にも接続され得る。
【００１８】
クライアントデバイス１００は、一つ以上のサーバコンピュータデバイス１４０によって、そのデバイスのために実行されるアプリケーションから出力を受信および表示することが可能であり、本明細書中に開示されるプロトコルに従って動作することが可能な任意のデバイスになり得る。クライアントコンピュータデバイス１００は、パーソナルコンピュータ、ウィンドウズ（登録商標）ベースの端末、ネットワークコンピュータ、情報機器、Ｘデバイス、ワークステーション、ミニコンピュータ、携帯情報端末または携帯電話になり得る。
【００１９】
同様に、サーバコンピュータデバイス１４０は、実行するアプリケーションに対するクライアントコンピュータデバイス１００ユーザ入力から受信すること、クライアントコンピュータデバイス１００のためにアプリケーションプログラムを実行すること、および本明細書中に開示されるプロトコルを使用してクライアントコンピュータデバイスと相互作用することが可能である任意のコンピュータデバイスになり得る。サーバコンピュータデバイス１４０は、本明細書中にサーバファームとて言及される単一サーバシステムとして論理的に作用するサーバデバイスのグループとして供給され得る。一実施形態において、サーバコンピュータデバイス１４０は、複数の同時にアクティブなクライアント接続をサポートするマルチユーザサーバシステムである。
【００２０】
図２Ａおよび図２Ｂは、クライアントコンピュータデバイス１００およびサーバコンピュータデバイス１４０として有用な典型的なコンピュータ２００のブロック図を示す。図２Ａおよび図２Ｂに示されるように、各々のコンピュータ２００は、中央演算処理装置２０２およびメインメモリユニット２０４を含む。各々のコンピュータ２００は、一つ以上の入力／出力デバイス２３０ａ〜２３０ｂのような他の任意要素（一般に、参照番号２３０を使用して参照される）および中央演算処理装置２０２と通信するキャッシュメモリ２４０も含み得る。
【００２１】
中央演算処理装置２０２は、メインメモリユニット２０４からフェッチされる命令に応答およびそれを処理する任意の論理回路である。多数の実施形態において、中央演算処理装置は、その全てが、Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， Ｃａｌｉｆｏｒｎｉａに在るＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、８０８８，８０２８６，８０３８６，８０４８６，Ｐｅｎｔｉｕｍ（登録商標），Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ，Ｐｅｎｔｉｕｍ（登録商標） ＩＩ，Ｃｅｌｅｒｏｎ，またはＸｅｏｎプロセッサ；その全てがＳｃｈａｕｍｂｕｒｇ，Ｉｌｌｉｎｏｉｓに在るＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、６８０００，６８０１０，６８０２０，６８０３０，６８０４０，ＰｏｗｅｒＰＣ ６０１，ＰｏｗｅｒＰＣ６０４，ＰｏｗｅｒＰＣ６０４ｅ，ＭＰＣ６０３ｅ，ＭＰＣ６０３ｅｉ，ＭＰＣ６０３ｅｖ，ＭＰＣ６０３ｒ，ＭＰＣ６０３ｐ，ＭＰＣ７４０，ＭＰＣ７４５，ＭＰＣ７５０，ＭＰＣ７５５，ＭＰＣ７４００，ＭＰＣ７４１０，ＭＰＣ７４４１，ＭＰＣ７４４５，ＭＰＣ７４４７，ＭＰＣ７４５０，ＭＰＣ７４５１，ＭＰＣ７４５５，ＭＰＣ７４５７プロセッサ；Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａに在るＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、Ｃｒｕｓｏｅ ＴＭ５８００，Ｃｒｕｓｏｅ ＴＭ５６００，Ｃｒｕｓｏｅ ＴＭ５５００，Ｃｒｕｓｏｅ ＴＭ５４００，Ｅｆｆｉｃｅｏｎ ＴＭ８６００，Ｅｆｆｉｃｅｏｎ ＴＭ８３００，Ｅｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ；その全てがＷｈｉｔｅ Ｐｌａｉｎｓ，Ｎｅｗ Ｙｏｒｋに在るＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって生産される、ＲＳ／６０００プロセッサ，ＲＳ６４，ＲＳ ６４ ＩＩ，Ｐ２ＳＣ，ＰＯＷＥＲ３，ＲＳ６４ ＩＩＩ，ＰＯＷＥＲ３−ＩＩ，ＲＳ ６４ ＩＶ，ＰＯＷＥＲ４，ＰＯＷＥＲ４＋，ＰＯＷＥＲ５，またはＰＯＷＥＲ６プロセッサ；またはＳｕｎｎｙｖａｌｅ， Ｃａｌｉｆｏｒｎｉａに在るＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓによって生産される、ＡＭＤ Ｏｐｔｅｒｏｎ，ＡＭＤ Ａｔｈｌｏｎ ６４ＦＸ，ＡＭＤ Ａｔｈｌｏｎ，またはＡＭＤ Ｄｕｒｏｎプロセッサ、のようなマイクロプロセッサユニットによって提供される。
【００２２】
メインメモリユニット２０４は、データを格納することが可能であり、Ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ（ＳＲＡＭ），Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ），Ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ（ＤＲＡＭ），Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ），Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ（ＥＤＯ ＲＡＭ），Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ），Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ），同期（ｓｙｎｃｈｒｏｎｏｕｓ）ＤＲＡＭ（ＳＤＲＡＭ），ＪＥＤＥＣ ＳＲＡＭ，ＰＣ１００ ＳＤＲＡＭ，Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ），ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ），Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）またはＦｅｒｒｏｅｌｅｃｔｒｉｃ ＲＡＭ（ＦＲＡＭ）、のようなマイクロプロセッサ２０２によって直接アクセスされる任意のストレージ配置を許す、一つ以上のメモリチップになり得る。図２Ａに示される実施形態において、プロセッサ２０２は、システムバス２２０を介してメインメモリ２０４と通信する（より詳細に下記される）。図２Ｂは、プロセッサがメモリポートを介してメインメモリ２０４と直接通信する、コンピュータシステム２００の実施形態を示す。例えば、図２Ｂにおいては、メモリ２０４はＤＲＤＲＡＭになり得る。
【００２３】
図２Ａおよび図２Ｂは、メインプロセッサ２０２が時々「バックサイド」バスと言及される第２のバスを介して、キャッシュメモリ２４０と直接通信する実施形態を示す。他の実施形態において、メインプロセッサ２０２は、システムバス２２０を使用してキャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、一般に、メインメモリ２０４より早い応答時間を有し、一般に、ＳＲＡＭ，ＢＳＲＡＭ，ＥＤＲＡＭによって提供される。
【００２４】
図２Ａに示される実施形態において、プロセッサ２０２は、ローカルなシステムバス２２０を介して、様々なＩ／Ｏデバイス２３０と通信する。様々なバスは、中央演算処理装置２０２を、ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−ＥｘｐｒｅｓｓバスまたはＮｕＢｕｓを含むＩ／Ｏデバイス２３０に接続するために使用され得る。Ｉ／Ｏデバイスが映像ディスプレイである実施形態においては、プロセッサ２０２は、ディスプレイと通信するためにＡｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図２Ｂは、メインプロセッサ２０２がＨｙｐｅｒＴｒａｎｓｐｏｒｔ，Ｒａｐｉｄ Ｉ／Ｏ，またはＩｎｆｉｎｉＢａｎｄを介してＩ／Ｏデバイス２３０ｂと直接通信する、コンピュータシステム２００の実施形態を示す。図２Ｂは、ローカルなバスと直接通信がミックスされる実施形態も示す：プロセッサ２０２は、Ｉ／Ｏデバイス２３０ｂと直接通信する一方、ローカルな相互接続バスを使用してＩ／Ｏデバイス２３０ａと通信する。
【００２５】
Ｉ／Ｏデバイス２３０の広い多様性は、コンピュータシステム２００に存在し得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイクロホン、およびドローイングタブレットを含む。出力デバイスは、映像ディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および色素昇華型プリンタを含む。Ｉ／Ｏデバイスは、コンピュータシステム２００のためにハードディスクドライブのような大容量ストレージ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクのようなフロッピー（登録商標）ディスクを受け取るためのフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々な形式のテープドライブ、およびＬｏｓ Ａｌａｍｉｔｏｓ，Ｃａｌｉｆｏｒｎｉａに在るＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ，Ｉｎｃ．によって生産されるＵＳＢ Ｆｌａｓｈ ＤｒｉｖｅラインのデバイスのようなＵＳＢストレージデバイスも提供し得る。
【００２６】
更なる実施形態において、Ｉ／Ｏデバイス２３０は、システムバス２２０とＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐバス、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標)バス、ＡｐｐｌｅＴａｌｋバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、またはＳｅｒｉａｌ Ａｔｔａｃｈｅｄ小規模コンピュータシステムインターフェースバス、のような外部の通信バスとの間のブリッジになり得る。
【００２７】
図２Ａおよび図２Ｂに示される一種の一般的（ｇｅｎｅｒａｌ−ｐｕｒｐｏｓｅ）デスクトップコンピュータは、一般的に、タスクのスケジュリングおよびシステムリソースへのアクセスを制御するオペレーティングシステムの管理下において動作する。典型的なオペレーティングシステムは、Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．によって生産されるＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）；Ｃｕｐｅｒｔｉｎｏ，Ｃａｌｉｆｏｒｎｉａに在るＡｐｐｌｅ Ｃｏｍｐｕｔｅｒによって生産されるＭａｃＯＳ；Ａｒｍｏｎｋ，Ｎｅｗ Ｙｏｒｋに在るＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって生産されるＯＳ／２；Ｓａｌｔ Ｌａｋｅ Ｃｉｔｙ，Ｕｔａｈに在るＣａｌｄｅｒａ Ｃｏｒｐ．によって分配される他人同士で自由に利用可能なオペレーティングシステムであるＬｉｎｕｘを含む。
【００２８】
他の実施形態においては、クライントコンピュータデバイス１００は、デバイスと矛盾しない（ｃｏｎｓｉｓｔｅｎｔ）、異なるプロセッサ、オペレーティングシステム、および入力デバイスを有し得る。例えば、一実施形態において、クライアントコンピュータデバイス１００は、Ｐａｌｍ，Ｉｎｃ．によって生産されるＺｉｒｅ ７１携帯情報端末である。この実施形態においては、Ｚｉｒｅ ７１は、Ｄａｌｌａｓ，Ｔｅｘａｓに在るＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓによって生産されるＯＭＡＰ ３１０プロセッサを使用し、ＰａｌｍＯＳオペレーティングシステムの管理下において動作し、液晶ディスプレイスクリーン、スタイラス入力デバイス、および５ウェイ（ｆｉｖｅ−ｗａｙ）ナビゲータデバイスを含む。
【００２９】
図３Ａを参照すると、ブロック図が、本発明が実行され得るネットワーク４０の実施形態を示す。サーバ３０，３２，および３４は、同等のドメイン３８に属し得る。ネットワーク４０において、ドメインは、１つのセキュリティデータベースの管理下におけるアプリケーションサーバおよびクライアントノードのグループを含むサブグループである。ドメインは、一つ以上の「サーバファーム」を含み得る。（サーバファームは、集中型管理を提供するために、単一サーバシステムとして作用するように一緒にリンクされているサーバのグループである。）反対に、サーバファームは、一つ以上のドメインを含み得る。二つの異なるドメインのサーバが同等のサーバファームに属するためには、ドメイン間に信頼関係が存在する必要があり得る。信頼関係は、ユーザが１つだけのログオン認証を用いて各々のドメインに関連するリソースにアクセスすることを許す、異なるドメイン間における関係である。
【００３０】
一実施形態において、アプリケーションサーバ３６は、ドメイン３８とは異なるドメインにある。もう１つの実施形態においては、アプリケーションサーバ３６は、サーバ３０，３２，および３４と同等のドメインにある。どちらの実施形態に対しても、サーバ３６が他のサーバファームに属する一方、アプリケーションサーバ３０，３２，および３４は、１つのサーバファームに属し得、またはアプリケーションサーバ３０，３２，３４，および３６の全ては、同等のサーバファームに属し得る。新しいサーバがネットワーク４０に接続される場合、新しいサーバは、既存のサーバファームに加わるまたは新しいサーバファームを始めるのどちらかを行う。
【００３１】
クライアントノード１０，２０は、ドメインにあり得、またはどのドメインにも接続され得ない。一実施形態において、クライアントノード１０は、ドメイン３８にある。もう１つの実施形態においては、クライアントノード１０は、アプリケーションサーバ３０，３２，３４，または３６のどれも含まない他のドメインにある。もう１つの実施形態においては、クライアントノード１０は、どのドメインにもない。
【００３２】
一実施形態において、クライアントノード１０は、ドメイン３８にあり、クライアントノードのユーザは、クライアントノード１０にログオンするためにユーザ証明（ｃｒｅｄｅｎｔｉａｌ）を提供する。ユーザ証明は、一般的に、クライアントノードのユーザ名、ユーザのパスワード、およびユーザが認識されるドメイン名を含む。ユーザ証明は、スマートカード、時間ベーストークン、社会保障番号、ユーザパスワード、個人識別（ＰＩＮ）番号、シンメトリックキーまたは楕円曲線暗号に基づくデジタル証明書、ユーザのバイオメトリック特徴、またはクライアントノードのユーザの識別が、認証のために得られ得および提出され得る、任意の他の手段から得られ得る。
【００３３】
クライアントノード１０は、ユーザによって提供される証明からユーザ認証データを生成する。クライアントノード１０は、このユーザ認証データをサーバ３０に送信する。この実施形態において、クライアント証明は、ネットワークを通じて送信されず、結果として生じるユーザ認証データのみがクライアントノードによって送信される。
【００３４】
サーバ３０は、ユーザ認証データおよびアプリケーション関連情報から、サーバ３０を含むアプリケーションサーバファームによってホストされるどのアプリケーションプログラムが、クライアントノードのユーザによる使用のために利用可能なのかも決定できる。サーバ３０は、利用可能なアプリケーションプログラムを表す情報を、クライアントノード１０に送信する。この処理は、クライアントノードのユーザがアプリケーション接続をセットアップする必要性を除去する。更に、サーバファームの管理者は、様々なクライアントノードユーザ間でのアプリケーションへのアクセスを制御できる。
【００３５】
下記のホストされるアプリケーションプログラムのようなアプリケーションが他のサーバに存在し得るにも関わらず、サーバ３０によって実行されるユーザ認証は、クライアントノード１０に示される各々のホストされるアプリケーションプログラムの使用を認証するのに十分である。したがって、この実施形態において、クライアントノードがホストアプリケーションの１つにランチ（ｌａｕｎｃｈ）（すなわち、実行を開始する）した場合、ユーザによるユーザ証明の追加入力は、そのアプリケーションの使用を認証するために不必要になる。したがって、ユーザ証明の単一エントリは、利用可能なアプリケーションを決定し、クライアントユーザによる追加の、手動ログオン認証処理なしに、そのようなアプリケーションのランチを認証するために役立ち得る。
【００３６】
図３Ｂは、クライアントノード１０が利用可能なアプリケーションの実行を開始し、サーバがアプリケーションの結果をクライアントノード１０に示すことによる、他の例示的処理を示す。クライアントノード１０のユーザは、アプリケーション４１のランチをリクエストする（例えば、アプリケーションを表すクライアントノード１０に表示されるアイコンをクリックすることによって）。アプリケーションに対するリクエスト４２は、本実施例においてはサーバ３０である、第１のサーバノードに向けられる。アプリケーションが第１のサーバノード３０にある場合、第１のサーバノード３０は、アプリケーションを実行し得、結果をクライアントノード１０に戻し得る。代替的に、第１のサーバノード３０は、アプリケーション４１が、本実施例においてはサーバ３２である、他のサーバにおいて利用可能であることを、クライアントノード１０に示し得る（矢印４３）。クライアントノード１０およびサーバ３２は、クライアントノード１０がアプリケーション４１の実行をリクエストすることによって、接続（矢印４５と４６）を確立する。サーバ３２は、アプリケーション４１を実行し得、結果をクライアントノード１０に転送し得る（すなわち、グラフィカルユーザインターフェース）。
【００３７】
図３Ｃは、クライアントノード２０が、本実施例においてはワールドワイドウェブを介して、利用可能なアプリケーションの実行を開始することによる、他の例示的処理を示す。クライアントノード２０は、Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＭＩＣＲＯＳＯＦＴ ＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲのようなウェブブラウザアプリケーション８０を実行する。クライアントノード２０は、ウェブブラウザ８０を介して、サーバ３０によってダイナミックに生成されるＨＴＭＬページに対応するＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）アドレスにアクセスするためにリクエスト８２を送信する。一部の実施形態において、サーバ３０によってクライアントノード２０に戻される第１の応答８４は、クライアントノード２０を識別することを要求する認証リクエストである。
【００３８】
ユーザは、クライアントノード２０にユーザ証明を提供する。クライアントノード２０は、提供されるユーザ証明に基づいて、ユーザ認証データを生成する。認証リクエストは、クライアントノード２０が認証のために、サーバ３０にウェブブラウザ８０を介してユーザ認証データを送信することを許す。送信されたユーザ認証データは、サーバ３０によって検証される。
【００３９】
サーバ３０は、ユーザ認証データおよびアプリケーション関連情報から、アプリケーションサーバによってホストされるどのアプリケーションプログラムが、クライアントノード２０のユーザによって使用可能であるかも決定できる。サーバ３０は、利用可能なアプリケーションプログラムを表す情報を含むＨＴＭＬページを生成し、ウェブブラウザ８０を介してこれをクライアントノード２０に送信する。情報は、各々の利用可能なアプリケーションに対応する、個別のランチＵＲＬアドレスを含む。
【００４０】
本実施形態において、利用可能なアプリケーションは、ウェブブラウザ８０を介してクライアントノード２０に表示される。クライアントノードディスプレイは、利用可能なアプリケーションプログラムを表すグラフィックなアイコン５７を現すウィンドウ５８を有する。クライアントノード２０のユーザは、マウスを用いてアイコン５７をクリックすることによって、アプリケーションプログラムをランチできる。クライアントノード２０は、サーバ３０にあるアプリケーションランチサービスに対応するＵＲＬアドレスにアクセスするように、ウェブブラウザ８０を介して、リクエスト８６を送信する。サーバノード３０は、アプリケーションの実行をし、その結果をクライアントノード２０に転送するように、どのようにして接続が確立され得るかを示すランチ情報８８を、ウェブブラウザ８０を介して、クライアントノード２０に送信する。
【００４１】
図３Ｄは、クライアントノード１０、本実施例においてはサーバ３０である第１のサーバノード、とサーバ３２との間における通信の例示的処理を示す。クライアントノード１０は、サーバ３２とアクティブ接続７２を有する。クライアントノード１０およびサーバ３２は、第１のアプリケーションプログラムの実行に関する情報を交換するために、アクティブ接続７２を使用できる。受信されたユーザ証明から、クライアントノード１０によって生成されるユーザ認証データは、クライアントノードに格納される。ユーザ認証データのそのようなストレージは、キャッシュメモリにある。
【００４２】
本実施形態において、利用可能なアプリケーションは、クライアントノード１０に表示される。クライアントノードディスプレイは、第２のアプリケーションプログラムを表すグラフィックなアイコン５７を現すウィンドウ５８を有する。クライアントノード１０のユーザは、マウスを用いてアイコン５７をダブルクリックすることによって、第２のアプリケーションプログラムをランチできる。リクエストは、接続５９を介して、第１のサーバノード３０にパスする。第１のサーバノード３０は、求められているアプリケーションがサーバ３２において利用可能であることを、接続５９を介して、クライアントノード１０に示す。クライアントノード１０は、第２の接続７０を確立するために、サーバ３２に信号を送る。サーバ３２は、第２のアプリケーションプログラムへのアクセスを認証するために、クライアントノード１０からユーザ認証データをリクエストする。クライアントノード１０は、格納されているユーザ認証データに基づいて、ユーザ認証データを生成する。クライアントノード１０は、次いで、サーバ３２にユーザ認証データを送信する。成功（ｓｕｃｃｅｓｓｆｕｌ）認証において、クライアントノード１０およびサーバ３２は、第２の接続７０を確立し、第２のアプリケーションプログラムの実行に関する情報を交換する。したがって、クライアントノード１０およびサーバ３２は、複数の接続を通じて互いに通信する。
【００４３】
図４は、サーバコンピュータデバイス１４０に、クライアントノード１００のユーザをリモートに認証するためのシステムをより詳細に示す。図４に示されるように、クライアントコンピュータデバイス１００は、シンクライアントプログラム３２０と通信している認証モジュール３１０を含む。認証モジュール３１０は、クライアントコンピュータデバイス１００、サーバコンピュータデバイス１４０、またはその両方にユーザを認証する目的のために提供されるユーザ認証証明を受信する。受信される認証証明は、ユーザ名−パスワード組み合わせ、グラフィックなパスワードデータ、Ｍａｓｓａｃｈｕｓｅｔｔｓ，Ｂｅｄｆｏｒｄに在るＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．によって生産されるトークンのＳｅｃｕｒｌＤラインのような時間ベーストークンから引き出されるデータ、チャレンジ応答データ、スマートカードからの情報、および指紋、声紋または顔面特徴のようなバイオメトリック情報を含み得る。認証モジュール３１０は、クライアントコンピュータデバイス１００にユーザを認証するために、提供される認証証明を使用し得る。例えば、ＷＩＮＤＯＷＳ（登録商標）ベースの環境において、認証モジュール３１０は、ＭＳＧＩＮＡダイナミックにリンクされたライブラリによって提供され得る。他の実施形態においては、例えば、Ｕｎｉｘ（登録商標）ベースの環境において、認証モジュール３１０は、ｐａｍ＿ｋｒｂモジュールを使用して、Ｕｎｉｘ（登録商標） Ｐｌｕｇｇａｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒによって提供され得る。更なる他の実施形態においては、認証モジュール３１０は、Ｕｎｉｘ（登録商標） ｋｉｎｉｔコマンドプログラムによって提供され得る。
【００４４】
図４に示される実施形態において、クライアントコンピュータデバイスは、セキュリティサービス３１２も含む。他の実施形態において、認証モジュール３１０およびセキュリティサービス３１２は、同等のダイナミックにリンクされたライブラリとして提供される。セキュリティサービス３１２は、クライアントコンピュータデバイスへの認証およびリモートホストまたはネットワークサービスへの認証のようなセキュリティサービスを、認証モジュール３１０およびシンクライアントアプリケーション３２０を含む、クライアントコンピュータデバイスにあるモジュールおよびアプリケーションに提供する。例えば、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって特定されるＧＳＳＡＰＩまたはＲｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＳＳＰＩになり得るセキュリティサービス３１２は、クライアントコンピュータデバイスにあるモジュールまたはアプリケーションのリクエストにより、ユーザ認証証明の受信に応答してＫｅｒｂｅｒｏｓチケットを得り得、このチケットを、リモートホストまたはネットワークサービスへのユーザを認証するための追加のＫｅｒｂｅｒｏｓチケットを得るために使用する。セキュリティサービス３１２は、次いで、リモート認証のためにこれらのＫｅｒｂｅｒｏｓチケットを必要な場合使用し、ユーザ認証データを生成し得る。一実施形態において、セキュリティサービス３１２は、Ｋｅｒｂｅｒｏｓ環境におけるＫｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ ＣｅｎｔｅｒまたはＷｉｎｄｏｗｓ（登録商標）ベースの環境におけるＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙのような外部の認証サービスを使用して、ユーザ認証データを生成し得る。
【００４５】
セキュリティサービス３１２は、例えば、Ｋｅｒｂｅｒｏｓチケットおよび関連するＫｅｒｂｅｒｏｓ認証符号（ａｕｔｈｅｎｔｉｃａｔｏｒ）のような、生成されたユーサ認証データを、シンクライアントアプリケーション３２０に提供する。シンクライアントアプリケーション３２０は、ユーザのリモート認証のために、ユーザ認証データをサーバコンピュータデバイス１４０に送信する。したがって、サーバベースコンピューティングのための既存の単一サインオンメカニズムと違って、ユーザ提供される認証証明は、サーバコンピュータデバイス１４０にネットワーク１８０を通じて送信されない。セキュリティサービス３１２によって生成されるユーザ認証データは、クライアントコンピュータデバイス１００に認証するためにユーザによって使用される方法に依存しない。したがって、例えば、クライアントコンピュータデバイス１００に認証するために、ユーザがユーザ名−パスワード組み合わせまたはバイオメトリックを使用しようとなかろうと、クライアントコンピュータデバイス１００のユーザのためのＫｅｒｂｅｒｏｓチケットは得られる。
【００４６】
図４の示される実施形態において、シンクライアントアプリケーション３２０は、一つ以上の仮想チャネル３３５を有するシンクライアントプロトコルを介して、サーバコンピュータデバイス１４０と通信する。これらの実施形態において、シンクライアントアプリケーション３２０は、仮想チャネルドライバをロードし、それを、認証仮想チャネルにおいてメッセージを送信および受信するために使用する。一部の実施形態において、仮想チャネルドライバは、仮想チャネルを開口し、それを越えてデータを送信するための機能をさらす（ｅｘｐｏｓｅ）。
【００４７】
シンクライアントアプリケーション３２０は、シンクライアントプロトコル接続が確立された場合、認証仮想チャネルが利用可能であることを、サーバ側シンクライアントアプリケーション３５０に示し、サーバコンピュータデバイス１４０に仮想チャネル３３５のためのデータ構造をパスする。一実施形態において、認証仮想チャネルのための仮想チャネルデータ構造は、仮想チャネル情報およびクライアントコンピュータデバイス１００が、仮想チャネル３３５を通じてサーバコンピュータデバイス１４０から受け取りまたは送信できる、最も大きなデータパケットのサイズの表示を含む。データパケットサイズは、最大のシンクライアントサイズおよびクライアントコンピュータデバイス１００によって強制（ｉｍｐｏｓｅ）される任意の特定のメモリ制限によって抑制される。特定の一実施形態において、認証仮想チャネルのためのデータ構造は、以下のように定義される：
【００４８】
【数１】
サーバ側シンクライアントアプリケーション３５０は、仮想チャネルを開口し、チャネルにバインドリクエストメッセージを送信することによる、認証仮想チャネル３３５を使用して認証を実行する意図を、シンクライアントアプリケーション３２０に示す。仮想チャネルが一度開口されると、シンクライアントアプリケーション３２０にある仮想チャネルドライバは、一実施形態において、仮想チャネルからバインディングをリクエストするメッセージを読み取り、バインドリクエストに応答して仮想チャネルにメッセージを送信し、およびチャネルから「コミット」メッセージを読み取る。一実施形態において、バインディングをリクエストするメッセージは、サポートされているプロトコルバージョンを特定するデータを含む。他の実施形態において、プロトコルバージョンは、バインドリクエストおよびバインド応答メッセージを使用して、シンクライアントアプリケーション３２０とサーバ側シンクライアントアプリケーション３５０との間にてネゴシエートされ得る。
【００４９】
バインドリクエスト、バインド応答、およびバインドコミット初期化メッセージは、サーバ側シンクライアントアプリケーション３５０およびシンクライアントアプリケーション３２０が、サーバ側シンクライアントアプリケーション３５０によって開始される３方向のハンドシェイクを導く（ｃｏｎｄｕｃｔ）ことを許し、可能性（ｃａｐａｂｉｌｉｔｙ）をネゴシエートする。仮想チャネル可能性の現在のセットが、２方向ハンドシェイクのみを使用してネゴシエートされ得る場合、２方向ハンドシェイクは、サーバ側シンクライアントアプリケーション３５０によって開始され得るが、３方向ハンドシェイクは、新しい可能性または現在の可能性への将来的強化によって要求され得る、より多くの柔軟性を許すようにサポートされる。例えば、３方向ハンドシェイクにおいて、サーバ側シンクライアントアプリケーション３５０から可能性の「メニュー」を受信した後、シンクライアントアプリケーション３２０は、特定のプリファランスを示し得、またはその代わりに、特定の可能性に関連するオプションの全セットを認め、従って、サーバ側シンクライアントアプリケーション３５０が特定のオプションにおいて決定することを許す。シンクライアントアプリケーション３２０によって開始される２方向ハンドシェイクにおいて、シンクライアントアプリケーション３２０は、ホストによってサポートされ得ないため、特定のプレファレンスを示し得ない。
【００５０】
チャネルセットアップに続いて、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の両方の仮想チャネルドライバは、「ストップ」メッセージまたは「エラー」メッセージが受信されるまで、ループにおいて以下のことをする：仮想チャネルを介して、他の団体によって送信される任意の認証データを入力として提供し、セキュリティサービス３１２，３１２’から認証データを引き出す；引き出された認証データ（ある場合）を、データメッセージにおいて仮想チャネルに送信する。セキュリティサービス３１２，３１２’からのデータの引き出しが「ＳＴＯＰ」メッセージを返した場合、信号はストップし、認証仮想チャネルを閉じる。一部の実施形態において、仮想チャネルドライバは、「ＣＯＮＴＩＮＵＥ」信号においてそれ自体をリセットし得る。セキュリティサービス３１２，３１２’からのデータの引き出しが「続ける」メッセージを返した場合、続ける。セキュリティサービス３１２，３１２’からの認証データの引き出しが「ＥＲＲＯＲ」を返した場合、エラーが生じたことを信号で伝え、認証仮想チャネルを閉じる。
【００５１】
「ｓｔｏｐ」または「ｅｒｒｏｒ」の信号が送られない限りは、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の仮想チャネルドライバは、セキュリティサービス３１２，３１２’が送信されるデータバッファを生成することをストップするまで、データメッセージを自由に交換できる。一部の実施形態において、交換されるメッセージの数は、仮想チャネルドライバ、サーバ側シンクライアントアプリケーション３５０、または仮想チャネル３３５によって制限され得る。他の実施形態において、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の仮想チャネルドライバは、メッセージを連続的に交換し、すなわち、もう一方に送信される第１のメッセージへの返信なしに、二つのメッセージは、一つの方向に送信されない。どちらの実施形態においても、メッセージ交換は、メッセージがどちらかの方向に送信された後、ストップし得る。
【００５２】
一部の特定の実施形態において、データメッセージは、最初に、仮想チャネルＬｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｄｏｕｂｌｅ Ｗｏｒｄ（ＬＳＤＷ），Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｗｏｒｄ（ＬＳＷ），Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｙｔｅ（ＬＳＢ）を通じて送信される。他の特定の実施形態において、データメッセージは、バイト境界において並べられ（ａｌｉｇｎｅｄ）、メモリに完全に詰め込まれる（ｐａｃｋｅｄ）。これらの実施形態において、データフィールドは、仮想チャネルに書き込まれるまたは読み取られるように、メモリに並べられる。
【００５３】
認証仮想チャネルにおいて送信される一部のメッセージは、複数の仮想チャネルパケットに及ぶ（ｓｐａｎ）。これをサポートするために、あらゆるメッセージは、次に送信されるコマンドの長さを特定するメッセージに先行されるべきである。次のコマンドの長さを特定するために使用され得るメッセージの例は：
【００５４】
【数２】
である。
【００５５】
これらの実施形態の一部において、ＰＫＴ＿ＣＭＤＬＥＮは、どの種類のメッセージが続くかを示すためにコマンド番号も含む：
【００５６】
【数３】
Ｌｅｎｇｔｈ＝０を含むＰＫＴ＿ＣＭＤＬＥＮパケットは、データはもう続かないことを示す（すなわち、論理チャネル閉路）。
【００５７】
サーバ側シンクライアントアプリケーション３５０は、認証仮想チャネルを通じて受信する認証データを、そのセキュリティサービス３１２’にパスする。サーバ側セキュリティサービス３１２’がデータを検証できる場合、ユーザのためのログオンセッションを表すアクセストークンを生成し、ユーザが、認証証明を再提出せずにサーバコンピュータデバイス１４０に認証することを許す。アクセストークンは、他のものに加えて、ログオンセッションのためのｌｏｃａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（ＬＵＩＤ）を含むデータ対象物である。サーバ側セキュリティサービス３１２’がデータを検証できない場合、ユーザは、認証証明を再提出するのを促される。
【００５８】
一部の実施形態において、サーバ側セキュリティサービス３１２’がユーザを認証するまで、ユーザがサーバコンピュータデバイス１４０と通信し得る、唯一の仮想チャネルは、認証仮想チャネルである。これらの実施形態の一部において、認証後、新しい仮想チャネルは、通信のために開始される。他の実施形態においては、仮想チャネルは一つだけ存在し、ユーザが認証されるまで認証関連通信のためだけに使用され得、ユーザが認証された後、他の通信のために使用され得る。
【００５９】
サーバ側コンピュータデバイス１４０が、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムの管理下において動作する実施形態に対しては、サーバ側セキュリティサービス３１２’によって生成されるアクセストークンは、ネットワークログオン権利だけを有する模倣（ｉｍｐｅｒｓｏｎａｔｉｏｎ）トークンである。すなわち、生成されるアクセストークンは、ＷＩＮＤＯＷＳ（登録商標）サーバベースのコンピュータ環境において要求されるように、アプリケーションが対話式に走るように開始するために使用するのに適さない。アプリケーションが対話式に走ることを許すために、対話式ログオン権利を有するプライマリアクセストークンが必要である。一実施形態において、生成されるアクセストークンは、適切な権利を提供するために修正される。他の実施形態においては、新しいトークンが、ユーザのために生成される。
【００６０】
サーバ側コンピュータデバイス１４０がＵｎｉｘ（登録商標）ベースのオペレーティングシステムの管理下において動作する実施形態に対しては、サーバ側セキュリティサービス３１２’が、認証仮想チャネルを通じて、サーバ側シンクライアントアプリケーション３５０から受信する認証データを検証した場合、サーバ側シンクライアントアプリケーション３５０は、リソースへのユーザアクセスを認可する。これらの実施形態において、サーバ側セキュリティサービス３１２’は、アクセストークンを生成しない。
【００６１】
一部の実施形態において、サーバがユーザを認証した後、サーバは、ユーザに利用可能なリソースの列挙を示す。これらの実施形態において、サーバは、複数のサーバによってホストされ、クライアントコンピュータデバイスに利用可能な、リソースの表示を説明するページを生成し得る。サーバは、次いで、表示のためにクライアントコンピュータデバイスに生成されたページを送信し得、ホストされるリソースの１つをアクセスするためのリクエストを、クライアントコンピュータデバイスから受信し得る。
【００６２】
これらの実施形態の一部において、複数のサーバの１つによってホストされる利用可能なリソースの選択された一つは、次いで、クライアントコンピュータデバイスからユーザ認証データの更なる受信を要求せずに実行される。これらの実施形態の一部においては、サーバは、ユーザによる成功認証に応答して、サーバからユーザに利用可能なリソースをホストしている第２のサーバへの接続を開始する。これらの実施形態において、利用可能なリソースは、接続を通じて実行される。一部の実施形態においては、接続は仮想チャネルである。
【００６３】
他の実施形態においては、第１のサーバは、利用可能なリソースの選択された一つをホストしている。これらの実施形態の一部においては、サーバは、既存の接続を通じて、リソースをユーザに対して利用可能にする。これらの実施形態の他の部分においては、サーバは、新しい接続を通じて、リソースをユーザに対して利用可能にする。それらの実施形態の一部においては、新しい接続は仮想チャネルを含む。
【００６４】
本発明は、一つ以上の製造品にまたはその上に組み入れられた一つ以上のコンピュータ読取可能プログラムとして提供され得る。製造品は、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ ＲＯＭ、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープになり得る。一般に、コンピュータ読取可能プログラムは、任意のプログラミング言語において実施され得る。使用され得る言語の一部の例は、Ｃ、Ｃ＋＋、またはＪＡＶＡ（登録商標）を含む。ソフトウェアプログラムは、一つ以上の製造品にオブジェクトコードとして格納され得る。
【００６５】
発明が、特定の好ましい実施形態に関して示されおよび説明される一方、上記の特許請求の範囲によって定義されるような本発明の精神および範囲から逸脱することなく、形および詳細における様々な変更がその中にされ得ることが当業者によって理解されるであろう。
【図面の簡単な説明】
【００６６】
【図１】図１は、本発明の例示的実施形態を行うために適した環境のブロック図である。
【図２Ａ】図２Ａは、本発明との関係に有用なコンピュータの実施形態を示すブロック図である。
【図２Ｂ】図２Ｂは、本発明との関係に有用なコンピュータの実施形態を示すブロック図である。
【図３Ａ】図３Ａは、本発明が実行され得るネットワーク４０の実施形態を示すブロック図である。
【図３Ｂ】図３Ｂは、クライアントノードが利用可能なアプリケーションの実行を開始し、サーバがクライアントノードにアプリケーションの結果を示す、処理の実施形態を示すブロック図である。
【図３Ｃ】図３Ｃは、クライアントノードがワールドワイドウェブを介して、利用可能なアプリケーションの実行を開始する、処理の実施形態を示すブロック図である。
【図３Ｄ】図３Ｄは、クライントノードと２つのサーバノードとの間の通信に対する、処理の実施形態を示すブロック図である。
【図４】図４は、サーバコンピュータデバイスに、クライアントノードのユーザをリモートに認証するためのシステムの実施形態のブロック図である。
【技術分野】
【０００１】
本発明は、サーバベースのコンピュータシステムにおける分散されたアプリケーション処理を提供するため、特に、そのようなシステムにおける認証テクニックをリモートするための、方法および装置に関する。
【背景技術】
【０００２】
ネットワークされたリソースにリモートアクセスを提供するための技術は、様々なクライアント／サーバソフトウェアの組み合わせを含む。これらの技術の一つは、しばしば「シン（ｔｈｉｎ−ｃｌｉｅｎｔ）」または「サーバベースのコンピュータ」システムとして言及される。これらのシステムにおいて、アプリケーションプログラムは、一つ以上のクライアントコンピュータデバイスのために、サーバコンピュータデバイスによって実行される。アプリケーションへのクライアント入力およびアプリケーション出力は、クライアントコンピュータデバイスとサーバコンピュータデバイスとの間にて送信される。これらのシステムは、一般に、アプリケーションがサーバコンピュータデバイスによってユーザのために実行され得る前に、ユーザ自身を認証するためにクライアントコンピュータデバイスのユーザを要求する。
【０００３】
クライアントコンピュータデバイスは、ユーザがデバイスを使用する前に、ローカルにログオンすることを要求し得る。クライアントコンピュータデバイスにローカルにログオンすることは、通常ユーザ名およびパスワードを要求するが、多数のクライントオペレーティングシステムは、例えば、ユーザが、トークンベースのスキーム、スマートカード、または指紋のようなバイオメトリックを用いてログオンすることを要求するように、ログオンメカニズムが置き換えられることを許す。
【０００４】
クライアントコンピュータデバイスに認証するにも関わらず、ユーザは、しばしば、サーバコンピュータデバイスに認証する必要もある。しかしながら、上述されたような置換ログオンメカニズムが使用される場合、サーバコンピュータデバイスがしばしばユーザ名およびパスワードのみを許可するため、ユーザは、サーバコンピュータデバイスに認証できな得ない。ユーザが、バイオメトリックまたはスマートカードのようなテクニックを用いて認証した場合、ユーザは、サーバコンピュータデバイスに認証するために有用な有効ユーザ名−パスワード組み合わせを知り得ない。一部の技術は、ユーザ供給されたユーザ名−パスワード組み合わせのクライアントコンピュータデバイスによる傍受（ｉｎｔｅｒｃｅｐｔ）を許す。しかしながら、これらの技術は、標準の認証メカニズムが置き換えられた場合、作用しない。
【０００５】
したがって、シンクライアントシステムのユーザをリモートに認証する改良された方法が望まれる。
【発明の開示】
【課題を解決するための手段】
【０００６】
一局面において、本発明は、クライアントコンピュータデバイスのユーザをリモートに認証するために、Ｆｔ．Ｌａｕｄｅｒｄａｌｅ，Ｆｌｏｒｉｄａに在るＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．によって生産されるＩＣＡプロトコルまたはＲｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＲＤＰプロトコルのようなシンクライアントプロトコルと結合して、産業標準のＧｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を使用する。
【０００７】
他の局面においては、本発明は、ネットワークプロバイダにパススルー認証の代替方法を提供することによってセキュリティを強化する。クライアントコンピュータデバイスがサーバコンピュータデバイスにユーザ認証証明、例えば、パスワード、を送信する代わりに、認証仮想チャネルドライバは、シンクライアントプロトコル内にて仮想チャネルを通じて認証データを送信する。ユーザ認証データは、ユーザのアイデンティティを検証するために使用され得るが、ユーザの裏に隠された認証証明を明らかにはしない。送信されたユーザ認証データは、サーバコンピュータデバイスにユーザを認証するために使用される。クライアントは、したがって、ユーザ認証証明に一度もアクセスしない。管理者特権を要求し、認証証明をクライアントコンピュータデバイス上の任意のローカルな処理に利用可能にする、ネットワークプロバイダをインストールすることは要求されない。ユーザの認証証明は、どの形においても、ネットワークを通じて送信されない。リモート認証は、サーバコンピュータデバイスの裏に隠されたオペレーティングシステムによって実行される。
【０００８】
本発明の一局面においては、クライアントコンピュータデバイスは、ユーザ証明を受信し、受信された証明に基づいてユーザ認証データを生成する。クライアントコンピュータデバイスは、サーバコンピュータデバイスに、生成されたユーザ認証データを送信する。サーバコンピュータデバイスは、ユーザ認証データに応答してユーザを認証する。サーバは、受信されたユーザ認証データに基づいて、新しいユーザ認証データを生成する。サーバは、第２のサーバに、新しいユーザ認証データを送信する。第２のサーバは、受信されたユーザ認証データに応答して、ユーザを認証する。一実施形態において、ユーザは、第１のサーバと第２のサーバとの間の接続を通じて、利用可能なリソースにアクセスする。
【０００９】
他の局面においては、本発明は、ユーザのリモート認証に対して認証データを交換するために、ＩＣＡプロトコルまたはＲＤＰプロトコル内にて仮想チャネルを使用する。仮想チャネルは、データをエンドポイント間にて送信する目的のために、二つ以上のエンドポイント間における任意の論理的結合である。
【００１０】
他の局面においては、本発明は、認証のためにＧＳＳＡＰＩを使用する。したがって、本発明は、Ｋｅｒｂｅｒｏｓ認証方法のようなＧＳＳＡＰＩ実施によってサポートされる任意の認証方法を用いて作用し、ＧＳＳＡＰＩをサポートする任意のクライアントコンピュータプラットフォームまたはデバイスに使用され得る。
【００１１】
本発明の他の局面においては、ユーザ認証証明（例、パスワード）は、クライアントまたはサーバのどちらもによって、あからさまに傍受（ｉｎｔｅｒｃｅｐｔｅｄ）または扱われない。ユーザ認証証明は、クライアントコンピュータデバイスとサーバコンピュータデバイスとの間において送信されない。
【００１２】
本発明の他の局面においては、クライアントコンピュータデバイスは、サーバコンピュータデバイスを認証し、サーバコンピュータデバイスは、クライントコンピュータデバイスのユーザを認証する。
【００１３】
本発明の他の局面においては、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標)における委任（ｄｅｌｅｇａｔｉｏｎ）セキュリティポリシーが支持される。例えば、「アカウントは敏感であり、委任されるべきではない」を設定するユーザアカウントが可能になった場合、そのユーザは、他のサーバにログオンするために、このリモート認証テクニックを使用できない。
【発明を実施するための最良の形態】
【００１４】
本発明のこれらおよび他の局面は、本発明を限定するのではなく、示すことを意味する、下記の詳細な説明および添付の図面から明らかになるであろう。
【００１５】
本発明の例示的実施形態は、リモートユーザがコンテンツへのアクセスをリクエストする、分散されたネットワーク環境に適用可能である。本発明の特質を説明する前に、本発明の例示的実施形態が使用され得る一部のネットワーク環境を議論することが、役に立ち得る。
【００１６】
図１を参照すると、簡潔な概要において、本発明が使用され得るクライアントサーバシステムの一実施形態が示される。第１のコンピュータデバイス（クライントコンピュータデバイス）１００は、通信ネットワーク１８０を通じて、第２のコンピュータデバイス（サーバコンピュータデバイス）１４０と通信する。一部の実施形態において、第２のコンピュータデバイスは、クライアントデバイス１００でもある。クライントデバイス１００がサーバデバイス１４０と通信するネットワーク１８０のトポロジは、バス、スター、またはリングトポロジになり得る。ネットワーク１８０は、構内情報通信網（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、またはインターネットのような広域情報通信網（ＷＡＮ）になり得る。
【００１７】
クライアントおよびサーバデバイス１００，１４０は、標準電話線、ＬＡＮまたはＷＡＮリンク（例、Ｔ１，Ｔ３，５６ ｋｂ，Ｘ．２５）、ブロードバンド接続（ＩＳＤＮ、フレームリレー、ＡＴＭ）、および無線接続を含む様々な接続を介して、ネットワーク１８０に接続できる。接続は、様々な通信プロトコルを使用して確立され得る（例、ＴＣＰ／ＩＰ，ＩＰＸ，ＳＰＸ，ＮｅｔＢＩＯＳ，ＮｅｔＢＥＵＩ，ＳＭＢ，Ｅｔｈｅｒｎｅｔ（登録商標），ＡＲＣＮＥＴ，Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ），ＲＳ２３２，ＩＥＥＥ ８０２．１１，ＩＥＥＥ ８０２．１１ａ，ＩＥＥ ８０２．１１ｂ，ＩＥＥＥ ８０２．１１ｇおよび直接非同期接続）。他のクライアントデバイスおよびサーバデバイス（図示せず）は、ネットワーク１８０にも接続され得る。
【００１８】
クライアントデバイス１００は、一つ以上のサーバコンピュータデバイス１４０によって、そのデバイスのために実行されるアプリケーションから出力を受信および表示することが可能であり、本明細書中に開示されるプロトコルに従って動作することが可能な任意のデバイスになり得る。クライアントコンピュータデバイス１００は、パーソナルコンピュータ、ウィンドウズ（登録商標）ベースの端末、ネットワークコンピュータ、情報機器、Ｘデバイス、ワークステーション、ミニコンピュータ、携帯情報端末または携帯電話になり得る。
【００１９】
同様に、サーバコンピュータデバイス１４０は、実行するアプリケーションに対するクライアントコンピュータデバイス１００ユーザ入力から受信すること、クライアントコンピュータデバイス１００のためにアプリケーションプログラムを実行すること、および本明細書中に開示されるプロトコルを使用してクライアントコンピュータデバイスと相互作用することが可能である任意のコンピュータデバイスになり得る。サーバコンピュータデバイス１４０は、本明細書中にサーバファームとて言及される単一サーバシステムとして論理的に作用するサーバデバイスのグループとして供給され得る。一実施形態において、サーバコンピュータデバイス１４０は、複数の同時にアクティブなクライアント接続をサポートするマルチユーザサーバシステムである。
【００２０】
図２Ａおよび図２Ｂは、クライアントコンピュータデバイス１００およびサーバコンピュータデバイス１４０として有用な典型的なコンピュータ２００のブロック図を示す。図２Ａおよび図２Ｂに示されるように、各々のコンピュータ２００は、中央演算処理装置２０２およびメインメモリユニット２０４を含む。各々のコンピュータ２００は、一つ以上の入力／出力デバイス２３０ａ〜２３０ｂのような他の任意要素（一般に、参照番号２３０を使用して参照される）および中央演算処理装置２０２と通信するキャッシュメモリ２４０も含み得る。
【００２１】
中央演算処理装置２０２は、メインメモリユニット２０４からフェッチされる命令に応答およびそれを処理する任意の論理回路である。多数の実施形態において、中央演算処理装置は、その全てが、Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， Ｃａｌｉｆｏｒｎｉａに在るＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、８０８８，８０２８６，８０３８６，８０４８６，Ｐｅｎｔｉｕｍ（登録商標），Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ，Ｐｅｎｔｉｕｍ（登録商標） ＩＩ，Ｃｅｌｅｒｏｎ，またはＸｅｏｎプロセッサ；その全てがＳｃｈａｕｍｂｕｒｇ，Ｉｌｌｉｎｏｉｓに在るＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、６８０００，６８０１０，６８０２０，６８０３０，６８０４０，ＰｏｗｅｒＰＣ ６０１，ＰｏｗｅｒＰＣ６０４，ＰｏｗｅｒＰＣ６０４ｅ，ＭＰＣ６０３ｅ，ＭＰＣ６０３ｅｉ，ＭＰＣ６０３ｅｖ，ＭＰＣ６０３ｒ，ＭＰＣ６０３ｐ，ＭＰＣ７４０，ＭＰＣ７４５，ＭＰＣ７５０，ＭＰＣ７５５，ＭＰＣ７４００，ＭＰＣ７４１０，ＭＰＣ７４４１，ＭＰＣ７４４５，ＭＰＣ７４４７，ＭＰＣ７４５０，ＭＰＣ７４５１，ＭＰＣ７４５５，ＭＰＣ７４５７プロセッサ；Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａに在るＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎによって生産される、Ｃｒｕｓｏｅ ＴＭ５８００，Ｃｒｕｓｏｅ ＴＭ５６００，Ｃｒｕｓｏｅ ＴＭ５５００，Ｃｒｕｓｏｅ ＴＭ５４００，Ｅｆｆｉｃｅｏｎ ＴＭ８６００，Ｅｆｆｉｃｅｏｎ ＴＭ８３００，Ｅｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ；その全てがＷｈｉｔｅ Ｐｌａｉｎｓ，Ｎｅｗ Ｙｏｒｋに在るＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって生産される、ＲＳ／６０００プロセッサ，ＲＳ６４，ＲＳ ６４ ＩＩ，Ｐ２ＳＣ，ＰＯＷＥＲ３，ＲＳ６４ ＩＩＩ，ＰＯＷＥＲ３−ＩＩ，ＲＳ ６４ ＩＶ，ＰＯＷＥＲ４，ＰＯＷＥＲ４＋，ＰＯＷＥＲ５，またはＰＯＷＥＲ６プロセッサ；またはＳｕｎｎｙｖａｌｅ， Ｃａｌｉｆｏｒｎｉａに在るＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓによって生産される、ＡＭＤ Ｏｐｔｅｒｏｎ，ＡＭＤ Ａｔｈｌｏｎ ６４ＦＸ，ＡＭＤ Ａｔｈｌｏｎ，またはＡＭＤ Ｄｕｒｏｎプロセッサ、のようなマイクロプロセッサユニットによって提供される。
【００２２】
メインメモリユニット２０４は、データを格納することが可能であり、Ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ（ＳＲＡＭ），Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ），Ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ（ＤＲＡＭ），Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ），Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ（ＥＤＯ ＲＡＭ），Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ），Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ），同期（ｓｙｎｃｈｒｏｎｏｕｓ）ＤＲＡＭ（ＳＤＲＡＭ），ＪＥＤＥＣ ＳＲＡＭ，ＰＣ１００ ＳＤＲＡＭ，Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ），Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ），ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ），Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）またはＦｅｒｒｏｅｌｅｃｔｒｉｃ ＲＡＭ（ＦＲＡＭ）、のようなマイクロプロセッサ２０２によって直接アクセスされる任意のストレージ配置を許す、一つ以上のメモリチップになり得る。図２Ａに示される実施形態において、プロセッサ２０２は、システムバス２２０を介してメインメモリ２０４と通信する（より詳細に下記される）。図２Ｂは、プロセッサがメモリポートを介してメインメモリ２０４と直接通信する、コンピュータシステム２００の実施形態を示す。例えば、図２Ｂにおいては、メモリ２０４はＤＲＤＲＡＭになり得る。
【００２３】
図２Ａおよび図２Ｂは、メインプロセッサ２０２が時々「バックサイド」バスと言及される第２のバスを介して、キャッシュメモリ２４０と直接通信する実施形態を示す。他の実施形態において、メインプロセッサ２０２は、システムバス２２０を使用してキャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、一般に、メインメモリ２０４より早い応答時間を有し、一般に、ＳＲＡＭ，ＢＳＲＡＭ，ＥＤＲＡＭによって提供される。
【００２４】
図２Ａに示される実施形態において、プロセッサ２０２は、ローカルなシステムバス２２０を介して、様々なＩ／Ｏデバイス２３０と通信する。様々なバスは、中央演算処理装置２０２を、ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−ＥｘｐｒｅｓｓバスまたはＮｕＢｕｓを含むＩ／Ｏデバイス２３０に接続するために使用され得る。Ｉ／Ｏデバイスが映像ディスプレイである実施形態においては、プロセッサ２０２は、ディスプレイと通信するためにＡｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図２Ｂは、メインプロセッサ２０２がＨｙｐｅｒＴｒａｎｓｐｏｒｔ，Ｒａｐｉｄ Ｉ／Ｏ，またはＩｎｆｉｎｉＢａｎｄを介してＩ／Ｏデバイス２３０ｂと直接通信する、コンピュータシステム２００の実施形態を示す。図２Ｂは、ローカルなバスと直接通信がミックスされる実施形態も示す：プロセッサ２０２は、Ｉ／Ｏデバイス２３０ｂと直接通信する一方、ローカルな相互接続バスを使用してＩ／Ｏデバイス２３０ａと通信する。
【００２５】
Ｉ／Ｏデバイス２３０の広い多様性は、コンピュータシステム２００に存在し得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイクロホン、およびドローイングタブレットを含む。出力デバイスは、映像ディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および色素昇華型プリンタを含む。Ｉ／Ｏデバイスは、コンピュータシステム２００のためにハードディスクドライブのような大容量ストレージ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクのようなフロッピー（登録商標）ディスクを受け取るためのフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々な形式のテープドライブ、およびＬｏｓ Ａｌａｍｉｔｏｓ，Ｃａｌｉｆｏｒｎｉａに在るＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ，Ｉｎｃ．によって生産されるＵＳＢ Ｆｌａｓｈ ＤｒｉｖｅラインのデバイスのようなＵＳＢストレージデバイスも提供し得る。
【００２６】
更なる実施形態において、Ｉ／Ｏデバイス２３０は、システムバス２２０とＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐバス、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標)バス、ＡｐｐｌｅＴａｌｋバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、またはＳｅｒｉａｌ Ａｔｔａｃｈｅｄ小規模コンピュータシステムインターフェースバス、のような外部の通信バスとの間のブリッジになり得る。
【００２７】
図２Ａおよび図２Ｂに示される一種の一般的（ｇｅｎｅｒａｌ−ｐｕｒｐｏｓｅ）デスクトップコンピュータは、一般的に、タスクのスケジュリングおよびシステムリソースへのアクセスを制御するオペレーティングシステムの管理下において動作する。典型的なオペレーティングシステムは、Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．によって生産されるＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）；Ｃｕｐｅｒｔｉｎｏ，Ｃａｌｉｆｏｒｎｉａに在るＡｐｐｌｅ Ｃｏｍｐｕｔｅｒによって生産されるＭａｃＯＳ；Ａｒｍｏｎｋ，Ｎｅｗ Ｙｏｒｋに在るＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって生産されるＯＳ／２；Ｓａｌｔ Ｌａｋｅ Ｃｉｔｙ，Ｕｔａｈに在るＣａｌｄｅｒａ Ｃｏｒｐ．によって分配される他人同士で自由に利用可能なオペレーティングシステムであるＬｉｎｕｘを含む。
【００２８】
他の実施形態においては、クライントコンピュータデバイス１００は、デバイスと矛盾しない（ｃｏｎｓｉｓｔｅｎｔ）、異なるプロセッサ、オペレーティングシステム、および入力デバイスを有し得る。例えば、一実施形態において、クライアントコンピュータデバイス１００は、Ｐａｌｍ，Ｉｎｃ．によって生産されるＺｉｒｅ ７１携帯情報端末である。この実施形態においては、Ｚｉｒｅ ７１は、Ｄａｌｌａｓ，Ｔｅｘａｓに在るＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓによって生産されるＯＭＡＰ ３１０プロセッサを使用し、ＰａｌｍＯＳオペレーティングシステムの管理下において動作し、液晶ディスプレイスクリーン、スタイラス入力デバイス、および５ウェイ（ｆｉｖｅ−ｗａｙ）ナビゲータデバイスを含む。
【００２９】
図３Ａを参照すると、ブロック図が、本発明が実行され得るネットワーク４０の実施形態を示す。サーバ３０，３２，および３４は、同等のドメイン３８に属し得る。ネットワーク４０において、ドメインは、１つのセキュリティデータベースの管理下におけるアプリケーションサーバおよびクライアントノードのグループを含むサブグループである。ドメインは、一つ以上の「サーバファーム」を含み得る。（サーバファームは、集中型管理を提供するために、単一サーバシステムとして作用するように一緒にリンクされているサーバのグループである。）反対に、サーバファームは、一つ以上のドメインを含み得る。二つの異なるドメインのサーバが同等のサーバファームに属するためには、ドメイン間に信頼関係が存在する必要があり得る。信頼関係は、ユーザが１つだけのログオン認証を用いて各々のドメインに関連するリソースにアクセスすることを許す、異なるドメイン間における関係である。
【００３０】
一実施形態において、アプリケーションサーバ３６は、ドメイン３８とは異なるドメインにある。もう１つの実施形態においては、アプリケーションサーバ３６は、サーバ３０，３２，および３４と同等のドメインにある。どちらの実施形態に対しても、サーバ３６が他のサーバファームに属する一方、アプリケーションサーバ３０，３２，および３４は、１つのサーバファームに属し得、またはアプリケーションサーバ３０，３２，３４，および３６の全ては、同等のサーバファームに属し得る。新しいサーバがネットワーク４０に接続される場合、新しいサーバは、既存のサーバファームに加わるまたは新しいサーバファームを始めるのどちらかを行う。
【００３１】
クライアントノード１０，２０は、ドメインにあり得、またはどのドメインにも接続され得ない。一実施形態において、クライアントノード１０は、ドメイン３８にある。もう１つの実施形態においては、クライアントノード１０は、アプリケーションサーバ３０，３２，３４，または３６のどれも含まない他のドメインにある。もう１つの実施形態においては、クライアントノード１０は、どのドメインにもない。
【００３２】
一実施形態において、クライアントノード１０は、ドメイン３８にあり、クライアントノードのユーザは、クライアントノード１０にログオンするためにユーザ証明（ｃｒｅｄｅｎｔｉａｌ）を提供する。ユーザ証明は、一般的に、クライアントノードのユーザ名、ユーザのパスワード、およびユーザが認識されるドメイン名を含む。ユーザ証明は、スマートカード、時間ベーストークン、社会保障番号、ユーザパスワード、個人識別（ＰＩＮ）番号、シンメトリックキーまたは楕円曲線暗号に基づくデジタル証明書、ユーザのバイオメトリック特徴、またはクライアントノードのユーザの識別が、認証のために得られ得および提出され得る、任意の他の手段から得られ得る。
【００３３】
クライアントノード１０は、ユーザによって提供される証明からユーザ認証データを生成する。クライアントノード１０は、このユーザ認証データをサーバ３０に送信する。この実施形態において、クライアント証明は、ネットワークを通じて送信されず、結果として生じるユーザ認証データのみがクライアントノードによって送信される。
【００３４】
サーバ３０は、ユーザ認証データおよびアプリケーション関連情報から、サーバ３０を含むアプリケーションサーバファームによってホストされるどのアプリケーションプログラムが、クライアントノードのユーザによる使用のために利用可能なのかも決定できる。サーバ３０は、利用可能なアプリケーションプログラムを表す情報を、クライアントノード１０に送信する。この処理は、クライアントノードのユーザがアプリケーション接続をセットアップする必要性を除去する。更に、サーバファームの管理者は、様々なクライアントノードユーザ間でのアプリケーションへのアクセスを制御できる。
【００３５】
下記のホストされるアプリケーションプログラムのようなアプリケーションが他のサーバに存在し得るにも関わらず、サーバ３０によって実行されるユーザ認証は、クライアントノード１０に示される各々のホストされるアプリケーションプログラムの使用を認証するのに十分である。したがって、この実施形態において、クライアントノードがホストアプリケーションの１つにランチ（ｌａｕｎｃｈ）（すなわち、実行を開始する）した場合、ユーザによるユーザ証明の追加入力は、そのアプリケーションの使用を認証するために不必要になる。したがって、ユーザ証明の単一エントリは、利用可能なアプリケーションを決定し、クライアントユーザによる追加の、手動ログオン認証処理なしに、そのようなアプリケーションのランチを認証するために役立ち得る。
【００３６】
図３Ｂは、クライアントノード１０が利用可能なアプリケーションの実行を開始し、サーバがアプリケーションの結果をクライアントノード１０に示すことによる、他の例示的処理を示す。クライアントノード１０のユーザは、アプリケーション４１のランチをリクエストする（例えば、アプリケーションを表すクライアントノード１０に表示されるアイコンをクリックすることによって）。アプリケーションに対するリクエスト４２は、本実施例においてはサーバ３０である、第１のサーバノードに向けられる。アプリケーションが第１のサーバノード３０にある場合、第１のサーバノード３０は、アプリケーションを実行し得、結果をクライアントノード１０に戻し得る。代替的に、第１のサーバノード３０は、アプリケーション４１が、本実施例においてはサーバ３２である、他のサーバにおいて利用可能であることを、クライアントノード１０に示し得る（矢印４３）。クライアントノード１０およびサーバ３２は、クライアントノード１０がアプリケーション４１の実行をリクエストすることによって、接続（矢印４５と４６）を確立する。サーバ３２は、アプリケーション４１を実行し得、結果をクライアントノード１０に転送し得る（すなわち、グラフィカルユーザインターフェース）。
【００３７】
図３Ｃは、クライアントノード２０が、本実施例においてはワールドワイドウェブを介して、利用可能なアプリケーションの実行を開始することによる、他の例示的処理を示す。クライアントノード２０は、Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＭＩＣＲＯＳＯＦＴ ＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲのようなウェブブラウザアプリケーション８０を実行する。クライアントノード２０は、ウェブブラウザ８０を介して、サーバ３０によってダイナミックに生成されるＨＴＭＬページに対応するＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）アドレスにアクセスするためにリクエスト８２を送信する。一部の実施形態において、サーバ３０によってクライアントノード２０に戻される第１の応答８４は、クライアントノード２０を識別することを要求する認証リクエストである。
【００３８】
ユーザは、クライアントノード２０にユーザ証明を提供する。クライアントノード２０は、提供されるユーザ証明に基づいて、ユーザ認証データを生成する。認証リクエストは、クライアントノード２０が認証のために、サーバ３０にウェブブラウザ８０を介してユーザ認証データを送信することを許す。送信されたユーザ認証データは、サーバ３０によって検証される。
【００３９】
サーバ３０は、ユーザ認証データおよびアプリケーション関連情報から、アプリケーションサーバによってホストされるどのアプリケーションプログラムが、クライアントノード２０のユーザによって使用可能であるかも決定できる。サーバ３０は、利用可能なアプリケーションプログラムを表す情報を含むＨＴＭＬページを生成し、ウェブブラウザ８０を介してこれをクライアントノード２０に送信する。情報は、各々の利用可能なアプリケーションに対応する、個別のランチＵＲＬアドレスを含む。
【００４０】
本実施形態において、利用可能なアプリケーションは、ウェブブラウザ８０を介してクライアントノード２０に表示される。クライアントノードディスプレイは、利用可能なアプリケーションプログラムを表すグラフィックなアイコン５７を現すウィンドウ５８を有する。クライアントノード２０のユーザは、マウスを用いてアイコン５７をクリックすることによって、アプリケーションプログラムをランチできる。クライアントノード２０は、サーバ３０にあるアプリケーションランチサービスに対応するＵＲＬアドレスにアクセスするように、ウェブブラウザ８０を介して、リクエスト８６を送信する。サーバノード３０は、アプリケーションの実行をし、その結果をクライアントノード２０に転送するように、どのようにして接続が確立され得るかを示すランチ情報８８を、ウェブブラウザ８０を介して、クライアントノード２０に送信する。
【００４１】
図３Ｄは、クライアントノード１０、本実施例においてはサーバ３０である第１のサーバノード、とサーバ３２との間における通信の例示的処理を示す。クライアントノード１０は、サーバ３２とアクティブ接続７２を有する。クライアントノード１０およびサーバ３２は、第１のアプリケーションプログラムの実行に関する情報を交換するために、アクティブ接続７２を使用できる。受信されたユーザ証明から、クライアントノード１０によって生成されるユーザ認証データは、クライアントノードに格納される。ユーザ認証データのそのようなストレージは、キャッシュメモリにある。
【００４２】
本実施形態において、利用可能なアプリケーションは、クライアントノード１０に表示される。クライアントノードディスプレイは、第２のアプリケーションプログラムを表すグラフィックなアイコン５７を現すウィンドウ５８を有する。クライアントノード１０のユーザは、マウスを用いてアイコン５７をダブルクリックすることによって、第２のアプリケーションプログラムをランチできる。リクエストは、接続５９を介して、第１のサーバノード３０にパスする。第１のサーバノード３０は、求められているアプリケーションがサーバ３２において利用可能であることを、接続５９を介して、クライアントノード１０に示す。クライアントノード１０は、第２の接続７０を確立するために、サーバ３２に信号を送る。サーバ３２は、第２のアプリケーションプログラムへのアクセスを認証するために、クライアントノード１０からユーザ認証データをリクエストする。クライアントノード１０は、格納されているユーザ認証データに基づいて、ユーザ認証データを生成する。クライアントノード１０は、次いで、サーバ３２にユーザ認証データを送信する。成功（ｓｕｃｃｅｓｓｆｕｌ）認証において、クライアントノード１０およびサーバ３２は、第２の接続７０を確立し、第２のアプリケーションプログラムの実行に関する情報を交換する。したがって、クライアントノード１０およびサーバ３２は、複数の接続を通じて互いに通信する。
【００４３】
図４は、サーバコンピュータデバイス１４０に、クライアントノード１００のユーザをリモートに認証するためのシステムをより詳細に示す。図４に示されるように、クライアントコンピュータデバイス１００は、シンクライアントプログラム３２０と通信している認証モジュール３１０を含む。認証モジュール３１０は、クライアントコンピュータデバイス１００、サーバコンピュータデバイス１４０、またはその両方にユーザを認証する目的のために提供されるユーザ認証証明を受信する。受信される認証証明は、ユーザ名−パスワード組み合わせ、グラフィックなパスワードデータ、Ｍａｓｓａｃｈｕｓｅｔｔｓ，Ｂｅｄｆｏｒｄに在るＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．によって生産されるトークンのＳｅｃｕｒｌＤラインのような時間ベーストークンから引き出されるデータ、チャレンジ応答データ、スマートカードからの情報、および指紋、声紋または顔面特徴のようなバイオメトリック情報を含み得る。認証モジュール３１０は、クライアントコンピュータデバイス１００にユーザを認証するために、提供される認証証明を使用し得る。例えば、ＷＩＮＤＯＷＳ（登録商標）ベースの環境において、認証モジュール３１０は、ＭＳＧＩＮＡダイナミックにリンクされたライブラリによって提供され得る。他の実施形態においては、例えば、Ｕｎｉｘ（登録商標）ベースの環境において、認証モジュール３１０は、ｐａｍ＿ｋｒｂモジュールを使用して、Ｕｎｉｘ（登録商標） Ｐｌｕｇｇａｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒによって提供され得る。更なる他の実施形態においては、認証モジュール３１０は、Ｕｎｉｘ（登録商標） ｋｉｎｉｔコマンドプログラムによって提供され得る。
【００４４】
図４に示される実施形態において、クライアントコンピュータデバイスは、セキュリティサービス３１２も含む。他の実施形態において、認証モジュール３１０およびセキュリティサービス３１２は、同等のダイナミックにリンクされたライブラリとして提供される。セキュリティサービス３１２は、クライアントコンピュータデバイスへの認証およびリモートホストまたはネットワークサービスへの認証のようなセキュリティサービスを、認証モジュール３１０およびシンクライアントアプリケーション３２０を含む、クライアントコンピュータデバイスにあるモジュールおよびアプリケーションに提供する。例えば、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって特定されるＧＳＳＡＰＩまたはＲｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎに在るＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生産されるＳＳＰＩになり得るセキュリティサービス３１２は、クライアントコンピュータデバイスにあるモジュールまたはアプリケーションのリクエストにより、ユーザ認証証明の受信に応答してＫｅｒｂｅｒｏｓチケットを得り得、このチケットを、リモートホストまたはネットワークサービスへのユーザを認証するための追加のＫｅｒｂｅｒｏｓチケットを得るために使用する。セキュリティサービス３１２は、次いで、リモート認証のためにこれらのＫｅｒｂｅｒｏｓチケットを必要な場合使用し、ユーザ認証データを生成し得る。一実施形態において、セキュリティサービス３１２は、Ｋｅｒｂｅｒｏｓ環境におけるＫｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ ＣｅｎｔｅｒまたはＷｉｎｄｏｗｓ（登録商標）ベースの環境におけるＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙのような外部の認証サービスを使用して、ユーザ認証データを生成し得る。
【００４５】
セキュリティサービス３１２は、例えば、Ｋｅｒｂｅｒｏｓチケットおよび関連するＫｅｒｂｅｒｏｓ認証符号（ａｕｔｈｅｎｔｉｃａｔｏｒ）のような、生成されたユーサ認証データを、シンクライアントアプリケーション３２０に提供する。シンクライアントアプリケーション３２０は、ユーザのリモート認証のために、ユーザ認証データをサーバコンピュータデバイス１４０に送信する。したがって、サーバベースコンピューティングのための既存の単一サインオンメカニズムと違って、ユーザ提供される認証証明は、サーバコンピュータデバイス１４０にネットワーク１８０を通じて送信されない。セキュリティサービス３１２によって生成されるユーザ認証データは、クライアントコンピュータデバイス１００に認証するためにユーザによって使用される方法に依存しない。したがって、例えば、クライアントコンピュータデバイス１００に認証するために、ユーザがユーザ名−パスワード組み合わせまたはバイオメトリックを使用しようとなかろうと、クライアントコンピュータデバイス１００のユーザのためのＫｅｒｂｅｒｏｓチケットは得られる。
【００４６】
図４の示される実施形態において、シンクライアントアプリケーション３２０は、一つ以上の仮想チャネル３３５を有するシンクライアントプロトコルを介して、サーバコンピュータデバイス１４０と通信する。これらの実施形態において、シンクライアントアプリケーション３２０は、仮想チャネルドライバをロードし、それを、認証仮想チャネルにおいてメッセージを送信および受信するために使用する。一部の実施形態において、仮想チャネルドライバは、仮想チャネルを開口し、それを越えてデータを送信するための機能をさらす（ｅｘｐｏｓｅ）。
【００４７】
シンクライアントアプリケーション３２０は、シンクライアントプロトコル接続が確立された場合、認証仮想チャネルが利用可能であることを、サーバ側シンクライアントアプリケーション３５０に示し、サーバコンピュータデバイス１４０に仮想チャネル３３５のためのデータ構造をパスする。一実施形態において、認証仮想チャネルのための仮想チャネルデータ構造は、仮想チャネル情報およびクライアントコンピュータデバイス１００が、仮想チャネル３３５を通じてサーバコンピュータデバイス１４０から受け取りまたは送信できる、最も大きなデータパケットのサイズの表示を含む。データパケットサイズは、最大のシンクライアントサイズおよびクライアントコンピュータデバイス１００によって強制（ｉｍｐｏｓｅ）される任意の特定のメモリ制限によって抑制される。特定の一実施形態において、認証仮想チャネルのためのデータ構造は、以下のように定義される：
【００４８】
【数１】
サーバ側シンクライアントアプリケーション３５０は、仮想チャネルを開口し、チャネルにバインドリクエストメッセージを送信することによる、認証仮想チャネル３３５を使用して認証を実行する意図を、シンクライアントアプリケーション３２０に示す。仮想チャネルが一度開口されると、シンクライアントアプリケーション３２０にある仮想チャネルドライバは、一実施形態において、仮想チャネルからバインディングをリクエストするメッセージを読み取り、バインドリクエストに応答して仮想チャネルにメッセージを送信し、およびチャネルから「コミット」メッセージを読み取る。一実施形態において、バインディングをリクエストするメッセージは、サポートされているプロトコルバージョンを特定するデータを含む。他の実施形態において、プロトコルバージョンは、バインドリクエストおよびバインド応答メッセージを使用して、シンクライアントアプリケーション３２０とサーバ側シンクライアントアプリケーション３５０との間にてネゴシエートされ得る。
【００４９】
バインドリクエスト、バインド応答、およびバインドコミット初期化メッセージは、サーバ側シンクライアントアプリケーション３５０およびシンクライアントアプリケーション３２０が、サーバ側シンクライアントアプリケーション３５０によって開始される３方向のハンドシェイクを導く（ｃｏｎｄｕｃｔ）ことを許し、可能性（ｃａｐａｂｉｌｉｔｙ）をネゴシエートする。仮想チャネル可能性の現在のセットが、２方向ハンドシェイクのみを使用してネゴシエートされ得る場合、２方向ハンドシェイクは、サーバ側シンクライアントアプリケーション３５０によって開始され得るが、３方向ハンドシェイクは、新しい可能性または現在の可能性への将来的強化によって要求され得る、より多くの柔軟性を許すようにサポートされる。例えば、３方向ハンドシェイクにおいて、サーバ側シンクライアントアプリケーション３５０から可能性の「メニュー」を受信した後、シンクライアントアプリケーション３２０は、特定のプリファランスを示し得、またはその代わりに、特定の可能性に関連するオプションの全セットを認め、従って、サーバ側シンクライアントアプリケーション３５０が特定のオプションにおいて決定することを許す。シンクライアントアプリケーション３２０によって開始される２方向ハンドシェイクにおいて、シンクライアントアプリケーション３２０は、ホストによってサポートされ得ないため、特定のプレファレンスを示し得ない。
【００５０】
チャネルセットアップに続いて、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の両方の仮想チャネルドライバは、「ストップ」メッセージまたは「エラー」メッセージが受信されるまで、ループにおいて以下のことをする：仮想チャネルを介して、他の団体によって送信される任意の認証データを入力として提供し、セキュリティサービス３１２，３１２’から認証データを引き出す；引き出された認証データ（ある場合）を、データメッセージにおいて仮想チャネルに送信する。セキュリティサービス３１２，３１２’からのデータの引き出しが「ＳＴＯＰ」メッセージを返した場合、信号はストップし、認証仮想チャネルを閉じる。一部の実施形態において、仮想チャネルドライバは、「ＣＯＮＴＩＮＵＥ」信号においてそれ自体をリセットし得る。セキュリティサービス３１２，３１２’からのデータの引き出しが「続ける」メッセージを返した場合、続ける。セキュリティサービス３１２，３１２’からの認証データの引き出しが「ＥＲＲＯＲ」を返した場合、エラーが生じたことを信号で伝え、認証仮想チャネルを閉じる。
【００５１】
「ｓｔｏｐ」または「ｅｒｒｏｒ」の信号が送られない限りは、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の仮想チャネルドライバは、セキュリティサービス３１２，３１２’が送信されるデータバッファを生成することをストップするまで、データメッセージを自由に交換できる。一部の実施形態において、交換されるメッセージの数は、仮想チャネルドライバ、サーバ側シンクライアントアプリケーション３５０、または仮想チャネル３３５によって制限され得る。他の実施形態において、シンクライアントアプリケーション３２０およびサーバ側シンクライアントアプリケーション３５０の仮想チャネルドライバは、メッセージを連続的に交換し、すなわち、もう一方に送信される第１のメッセージへの返信なしに、二つのメッセージは、一つの方向に送信されない。どちらの実施形態においても、メッセージ交換は、メッセージがどちらかの方向に送信された後、ストップし得る。
【００５２】
一部の特定の実施形態において、データメッセージは、最初に、仮想チャネルＬｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｄｏｕｂｌｅ Ｗｏｒｄ（ＬＳＤＷ），Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｗｏｒｄ（ＬＳＷ），Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｙｔｅ（ＬＳＢ）を通じて送信される。他の特定の実施形態において、データメッセージは、バイト境界において並べられ（ａｌｉｇｎｅｄ）、メモリに完全に詰め込まれる（ｐａｃｋｅｄ）。これらの実施形態において、データフィールドは、仮想チャネルに書き込まれるまたは読み取られるように、メモリに並べられる。
【００５３】
認証仮想チャネルにおいて送信される一部のメッセージは、複数の仮想チャネルパケットに及ぶ（ｓｐａｎ）。これをサポートするために、あらゆるメッセージは、次に送信されるコマンドの長さを特定するメッセージに先行されるべきである。次のコマンドの長さを特定するために使用され得るメッセージの例は：
【００５４】
【数２】
である。
【００５５】
これらの実施形態の一部において、ＰＫＴ＿ＣＭＤＬＥＮは、どの種類のメッセージが続くかを示すためにコマンド番号も含む：
【００５６】
【数３】
Ｌｅｎｇｔｈ＝０を含むＰＫＴ＿ＣＭＤＬＥＮパケットは、データはもう続かないことを示す（すなわち、論理チャネル閉路）。
【００５７】
サーバ側シンクライアントアプリケーション３５０は、認証仮想チャネルを通じて受信する認証データを、そのセキュリティサービス３１２’にパスする。サーバ側セキュリティサービス３１２’がデータを検証できる場合、ユーザのためのログオンセッションを表すアクセストークンを生成し、ユーザが、認証証明を再提出せずにサーバコンピュータデバイス１４０に認証することを許す。アクセストークンは、他のものに加えて、ログオンセッションのためのｌｏｃａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（ＬＵＩＤ）を含むデータ対象物である。サーバ側セキュリティサービス３１２’がデータを検証できない場合、ユーザは、認証証明を再提出するのを促される。
【００５８】
一部の実施形態において、サーバ側セキュリティサービス３１２’がユーザを認証するまで、ユーザがサーバコンピュータデバイス１４０と通信し得る、唯一の仮想チャネルは、認証仮想チャネルである。これらの実施形態の一部において、認証後、新しい仮想チャネルは、通信のために開始される。他の実施形態においては、仮想チャネルは一つだけ存在し、ユーザが認証されるまで認証関連通信のためだけに使用され得、ユーザが認証された後、他の通信のために使用され得る。
【００５９】
サーバ側コンピュータデバイス１４０が、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムの管理下において動作する実施形態に対しては、サーバ側セキュリティサービス３１２’によって生成されるアクセストークンは、ネットワークログオン権利だけを有する模倣（ｉｍｐｅｒｓｏｎａｔｉｏｎ）トークンである。すなわち、生成されるアクセストークンは、ＷＩＮＤＯＷＳ（登録商標）サーバベースのコンピュータ環境において要求されるように、アプリケーションが対話式に走るように開始するために使用するのに適さない。アプリケーションが対話式に走ることを許すために、対話式ログオン権利を有するプライマリアクセストークンが必要である。一実施形態において、生成されるアクセストークンは、適切な権利を提供するために修正される。他の実施形態においては、新しいトークンが、ユーザのために生成される。
【００６０】
サーバ側コンピュータデバイス１４０がＵｎｉｘ（登録商標）ベースのオペレーティングシステムの管理下において動作する実施形態に対しては、サーバ側セキュリティサービス３１２’が、認証仮想チャネルを通じて、サーバ側シンクライアントアプリケーション３５０から受信する認証データを検証した場合、サーバ側シンクライアントアプリケーション３５０は、リソースへのユーザアクセスを認可する。これらの実施形態において、サーバ側セキュリティサービス３１２’は、アクセストークンを生成しない。
【００６１】
一部の実施形態において、サーバがユーザを認証した後、サーバは、ユーザに利用可能なリソースの列挙を示す。これらの実施形態において、サーバは、複数のサーバによってホストされ、クライアントコンピュータデバイスに利用可能な、リソースの表示を説明するページを生成し得る。サーバは、次いで、表示のためにクライアントコンピュータデバイスに生成されたページを送信し得、ホストされるリソースの１つをアクセスするためのリクエストを、クライアントコンピュータデバイスから受信し得る。
【００６２】
これらの実施形態の一部において、複数のサーバの１つによってホストされる利用可能なリソースの選択された一つは、次いで、クライアントコンピュータデバイスからユーザ認証データの更なる受信を要求せずに実行される。これらの実施形態の一部においては、サーバは、ユーザによる成功認証に応答して、サーバからユーザに利用可能なリソースをホストしている第２のサーバへの接続を開始する。これらの実施形態において、利用可能なリソースは、接続を通じて実行される。一部の実施形態においては、接続は仮想チャネルである。
【００６３】
他の実施形態においては、第１のサーバは、利用可能なリソースの選択された一つをホストしている。これらの実施形態の一部においては、サーバは、既存の接続を通じて、リソースをユーザに対して利用可能にする。これらの実施形態の他の部分においては、サーバは、新しい接続を通じて、リソースをユーザに対して利用可能にする。それらの実施形態の一部においては、新しい接続は仮想チャネルを含む。
【００６４】
本発明は、一つ以上の製造品にまたはその上に組み入れられた一つ以上のコンピュータ読取可能プログラムとして提供され得る。製造品は、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ ＲＯＭ、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープになり得る。一般に、コンピュータ読取可能プログラムは、任意のプログラミング言語において実施され得る。使用され得る言語の一部の例は、Ｃ、Ｃ＋＋、またはＪＡＶＡ（登録商標）を含む。ソフトウェアプログラムは、一つ以上の製造品にオブジェクトコードとして格納され得る。
【００６５】
発明が、特定の好ましい実施形態に関して示されおよび説明される一方、上記の特許請求の範囲によって定義されるような本発明の精神および範囲から逸脱することなく、形および詳細における様々な変更がその中にされ得ることが当業者によって理解されるであろう。
【図面の簡単な説明】
【００６６】
【図１】図１は、本発明の例示的実施形態を行うために適した環境のブロック図である。
【図２Ａ】図２Ａは、本発明との関係に有用なコンピュータの実施形態を示すブロック図である。
【図２Ｂ】図２Ｂは、本発明との関係に有用なコンピュータの実施形態を示すブロック図である。
【図３Ａ】図３Ａは、本発明が実行され得るネットワーク４０の実施形態を示すブロック図である。
【図３Ｂ】図３Ｂは、クライアントノードが利用可能なアプリケーションの実行を開始し、サーバがクライアントノードにアプリケーションの結果を示す、処理の実施形態を示すブロック図である。
【図３Ｃ】図３Ｃは、クライアントノードがワールドワイドウェブを介して、利用可能なアプリケーションの実行を開始する、処理の実施形態を示すブロック図である。
【図３Ｄ】図３Ｄは、クライントノードと２つのサーバノードとの間の通信に対する、処理の実施形態を示すブロック図である。
【図４】図４は、サーバコンピュータデバイスに、クライアントノードのユーザをリモートに認証するためのシステムの実施形態のブロック図である。
【特許請求の範囲】
【請求項１】
ユーザを、サーバベースのコンピュータ環境におけるサーバにリモートに認証するための方法であって、該方法は、
（ａ）クライアントコンピュータデバイスにおいて、ユーザ証明を受信するステップと、
（ｂ）該クライアントコンピュータデバイスにおいて、該受信された証明に基づいて、ユーザ認証データを生成するステップと、
（ｃ）サーバコンピュータデバイスに、該生成されたユーザ認証データを送信するステップと、
（ｄ）該サーバコンピュータデバイスにおいて、該送信されたユーザ認証データに応答して、該ユーザを認証するステップと
を包含する、方法。
【請求項２】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、バイオメトリックユーザ証明を受信することを包含する、請求項１に記載の方法。
【請求項３】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、時間ベースのパスコードを受信することを包含する、請求項１に記載の方法。
【請求項４】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、スマートカードからユーザ証明を受信することを包含する、請求項１に記載の方法。
【請求項５】
ステップ（ｂ）が、前記クライアントデバイスにおいて、前記受信されたユーザ証明を表す暗号化されたビットストリングを生成することを包含する、請求項１に記載の方法。
【請求項６】
ステップ（ｂ）が、前記受信された証明に基づいて、ユーザ認証データを、前記クライアントデバイスにあるセキュリティプロバイダサブシステムによって生成することを包含する、請求項１に記載の方法。
【請求項７】
前記ユーザ認証データが、外部の認証サービスを使用して生成される、請求項６に記載の方法。
【請求項８】
前記ユーザ認証データが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）によって生成される、請求項６に記載の方法。
【請求項９】
前記ユーザ認証データが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）によって生成される、請求項６に記載の方法。
【請求項１０】
ステップ（ｃ）が、サーバコンピュータデバイスに少なくとも１つの仮想チャネルメッセージを送信することを包含し、該少なくとも１つの仮想チャネルメッセージが、前記生成されたユーザ認証データの少なくとも一部を含む、請求項１に記載の方法。
【請求項１１】
ステップ（ｄ）が、
（ｄ−ａ）前記サーバコンピュータデバイスにおいて、前記送信されたユーザ認証データを受信することと、
（ｄ−ｂ）該受信されたユーザ認証データをローカルに実行するセキュリティサブシステムに提供することと、
（ｄ−ｃ）該ローカルに実行するセキュリティサブシステムによって、該ユーザ認証データに応答して、前記ユーザを認証することと
を包含する、請求項１に記載の方法。
【請求項１２】
（ｅ）複数のサーバによってホストされ、前記クライアントコンピュータデバイスに利用可能なリソースの表示を示すページを、前記サーバによって、生成するステップと、
（ｆ）表示のために該クライアントコンピュータデバイスに、該生成されたページを、該サーバによって、送信するステップと、
（ｇ）該ホストされるリソースの１つにアクセスするリクエストを、該クライアントコンピュータデバイスから受信するステップと、
（ｈ）該クライアントコンピュータデバイスからユーザ認証データの更なる受信を要求せずに、該複数のサーバの１つによってホストされる該利用可能なリソースの選択された一つを実行するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１３】
前記ユーザによる成功認証に応答して、前記クライアントコンピュータデバイスから該ユーザに利用可能なリソースをホストしているサーバへの接続を開始するステップをさらに包含する、請求項１に記載の方法。
【請求項１４】
前記接続が、仮想チャネルを含む、請求項１３に記載の方法。
【請求項１５】
（ａ）前記受信されたユーザ認証データに基づいて、第１のサーバによって、ユーザ認証データを生成するステップと、
（ｂ）第２のサーバに、該第１のサーバによって、該ユーザ認証データを送信するステップと、
（ｃ）該第２のサーバによって、該受信されたユーザ認証データに応答して、前記ユーザを認証するステップと、
（ｄ）該第２のサーバによって、該第１のサーバとの接続を維持するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１６】
前記第１のサーバと前記第２のサーバとの間の前記接続を通じて、前記ユーザが、該ユーザに利用可能なリソースにアクセスすることを許すステップをさらに包含する、請求項１５に記載の方法。
【請求項１７】
サーバベースのコンピュータ環境におけるサーバに、ユーザをリモートに認証するためのシステムであって、該システムは、
クライアント側認証モジュール、クライアント側セキュリティプロバイダサブシステム、およびクライアント側仮想チャネルドライバを含むクライアントコンピュータデバイスであって、該クライアント側認証モジュールは、ユーザ認証証明を受信し、該クライアント側セキュリティプロバイダサブシステムに該証明を送信し、該クライアント側セキュリティプロバイダサブシステムは、送信のために、該ユーザ認証証明に基づいて、ユーザ認証データを生成し、該クライアント側仮想チャネルドライバに該ユーザ認証データを送信する、クライアントコンピュータデバイスと、
サーバ側仮想チャネルドライバ、サーバ側セキュリティプロバイダサブシステム、およびサーバ側認証モジュールを含むサーバコンピュータデバイスであって、該サーバ側仮想チャネルドライバは、該送信されたユーザ認証データを受信し、該サーバ側認証モジュールに該受信された認証データを提供し、該サーバ側認証モジュールは、該サーバ側セキュリティプロバイダサブシステムに該ユーザ認証データを送信し、該セキュリティプロバイダサブシステムは、認証表示を用いて該ユーザ認証データに応答する、サーバコンピュータデバイスと
を備える、システム。
【請求項１８】
前記クライアントコンピュータデバイスが、パーソナルコンピュータを備える、請求項１７に記載のシステム。
【請求項１９】
前記クライアントコンピュータデバイスが、携帯情報端末を備える、請求項１７に記載のシステム。
【請求項２０】
前記クライアントコンピュータデバイスが、携帯電話を備える、請求項１７に記載のシステム。
【請求項２１】
前記クライアント側認証モジュールが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）グラフィカル識別および認証モジュールを備える、請求項１７に記載のシステム。
【請求項２２】
前記クライアント側認証モジュールが、ｐａｍ＿ｋｒｂモジュールを使用する、Ｕｎｉｘ（登録商標) Ｐｌｕｇｇａｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒを備える、請求項１７に記載のシステム。
【請求項２３】
前記クライアント側認証モジュールが、Ｕｎｉｘ（登録商標） ｋｉｎｉｔコマンドプログラムを備える、請求項１７に記載のシステム。
【請求項２４】
前記クライアント側セキュリティプロバイダサブシステムが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）を備える、請求項１７に記載のシステム。
【請求項２５】
前記クライアント側セキュリティプロバイダサブシステムが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を備える、請求項１７に記載のシステム。
【請求項２６】
前記クライアント側仮想チャネルドライバが、前記ユーザ認証データの少なくとも一部を含む、少なくとも１つの仮想チャネルメッセージを送信する、請求項１７に記載のシステム。
【請求項２７】
前記サーバ側認証モジュールが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）グラフィカル識別および認証モジュールを備える、請求項１７に記載のシステム。
【請求項２８】
前記サーバ側セキュリティプロバイダサブシステムが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）を備える、請求項１７に記載のシステム。
【請求項２９】
前記サーバ側セキュリティプロバイダサブシステムが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を備える、請求項１７のシステム。
【請求項３０】
前記サーバ側セキュリティプロバイダサブシステムが、前記ユーザ認証データに応答して、ログオンセッションおよび対応するアクセストークンを生成する、請求項１７に記載のシステム。
【請求項３１】
サーバベースのコンピュータ環境におけるサーバに、ユーザをリモートに認証するための、コンピュータ読取可能プログラム手段が組み入れられている製造品であって、該製造品は、
ユーザ証明を受信するためのコンピュータ読取可能プログラム手段と、
該受信された証明に基づいて、ユーザ認証データを生成するためのコンピュータ読取可能プログラム手段と、
該生成されたユーザ認証データをサーバコンピュータデバイスに送信するためのコンピュータ読取可能プログラム手段と、
該送信されたユーザ認証データに応答して、該ユーザを認証するためのコンピュータ読取可能プログラム手段と
を備える、製造品。
【請求項３２】
受信するための前記コンピュータ読取可能プログラム手段が、バイオメトリックユーザ証明を受信するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３３】
受信するための前記コンピュータ読取可能プログラム手段が、スマートカードからユーザ証明を受信するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３４】
生成するための前記コンピュータ読取可能プログラム手段が、前記受信されたユーザ証明を表す暗号化されたビットストリングを生成するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３５】
生成するための前記コンピュータ読取可能プログラム手段が、前記受信されたユーザ証明に基づいて、ユーザ認証データを生成するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３６】
送信するための前記コンピュータ読取可能プログラム手段が、サーバコンピュータデバイスに少なくとも１つの仮想チャネルメッセージを送信するためのコンピュータ読取可能プログラム手段を備え、該少なくとも１つの仮想チャネルメッセージが、前記生成されたユーザ認証データの少なくとも一部を含む、請求項３１に記載の製造品。
【請求項３７】
前記ユーザによる成功認証に応答して、前記クライアントコンピュータデバイスから該ユーザに利用可能なリソースをホストしているサーバへの接続を開始するためのコンピュータ読取可能プログラム手段をさらに備える、請求項３１に記載の製造品。
【請求項１】
ユーザを、サーバベースのコンピュータ環境におけるサーバにリモートに認証するための方法であって、該方法は、
（ａ）クライアントコンピュータデバイスにおいて、ユーザ証明を受信するステップと、
（ｂ）該クライアントコンピュータデバイスにおいて、該受信された証明に基づいて、ユーザ認証データを生成するステップと、
（ｃ）サーバコンピュータデバイスに、該生成されたユーザ認証データを送信するステップと、
（ｄ）該サーバコンピュータデバイスにおいて、該送信されたユーザ認証データに応答して、該ユーザを認証するステップと
を包含する、方法。
【請求項２】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、バイオメトリックユーザ証明を受信することを包含する、請求項１に記載の方法。
【請求項３】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、時間ベースのパスコードを受信することを包含する、請求項１に記載の方法。
【請求項４】
ステップ（ａ）が、クライアントコンピュータデバイスにおいて、スマートカードからユーザ証明を受信することを包含する、請求項１に記載の方法。
【請求項５】
ステップ（ｂ）が、前記クライアントデバイスにおいて、前記受信されたユーザ証明を表す暗号化されたビットストリングを生成することを包含する、請求項１に記載の方法。
【請求項６】
ステップ（ｂ）が、前記受信された証明に基づいて、ユーザ認証データを、前記クライアントデバイスにあるセキュリティプロバイダサブシステムによって生成することを包含する、請求項１に記載の方法。
【請求項７】
前記ユーザ認証データが、外部の認証サービスを使用して生成される、請求項６に記載の方法。
【請求項８】
前記ユーザ認証データが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）によって生成される、請求項６に記載の方法。
【請求項９】
前記ユーザ認証データが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）によって生成される、請求項６に記載の方法。
【請求項１０】
ステップ（ｃ）が、サーバコンピュータデバイスに少なくとも１つの仮想チャネルメッセージを送信することを包含し、該少なくとも１つの仮想チャネルメッセージが、前記生成されたユーザ認証データの少なくとも一部を含む、請求項１に記載の方法。
【請求項１１】
ステップ（ｄ）が、
（ｄ−ａ）前記サーバコンピュータデバイスにおいて、前記送信されたユーザ認証データを受信することと、
（ｄ−ｂ）該受信されたユーザ認証データをローカルに実行するセキュリティサブシステムに提供することと、
（ｄ−ｃ）該ローカルに実行するセキュリティサブシステムによって、該ユーザ認証データに応答して、前記ユーザを認証することと
を包含する、請求項１に記載の方法。
【請求項１２】
（ｅ）複数のサーバによってホストされ、前記クライアントコンピュータデバイスに利用可能なリソースの表示を示すページを、前記サーバによって、生成するステップと、
（ｆ）表示のために該クライアントコンピュータデバイスに、該生成されたページを、該サーバによって、送信するステップと、
（ｇ）該ホストされるリソースの１つにアクセスするリクエストを、該クライアントコンピュータデバイスから受信するステップと、
（ｈ）該クライアントコンピュータデバイスからユーザ認証データの更なる受信を要求せずに、該複数のサーバの１つによってホストされる該利用可能なリソースの選択された一つを実行するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１３】
前記ユーザによる成功認証に応答して、前記クライアントコンピュータデバイスから該ユーザに利用可能なリソースをホストしているサーバへの接続を開始するステップをさらに包含する、請求項１に記載の方法。
【請求項１４】
前記接続が、仮想チャネルを含む、請求項１３に記載の方法。
【請求項１５】
（ａ）前記受信されたユーザ認証データに基づいて、第１のサーバによって、ユーザ認証データを生成するステップと、
（ｂ）第２のサーバに、該第１のサーバによって、該ユーザ認証データを送信するステップと、
（ｃ）該第２のサーバによって、該受信されたユーザ認証データに応答して、前記ユーザを認証するステップと、
（ｄ）該第２のサーバによって、該第１のサーバとの接続を維持するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１６】
前記第１のサーバと前記第２のサーバとの間の前記接続を通じて、前記ユーザが、該ユーザに利用可能なリソースにアクセスすることを許すステップをさらに包含する、請求項１５に記載の方法。
【請求項１７】
サーバベースのコンピュータ環境におけるサーバに、ユーザをリモートに認証するためのシステムであって、該システムは、
クライアント側認証モジュール、クライアント側セキュリティプロバイダサブシステム、およびクライアント側仮想チャネルドライバを含むクライアントコンピュータデバイスであって、該クライアント側認証モジュールは、ユーザ認証証明を受信し、該クライアント側セキュリティプロバイダサブシステムに該証明を送信し、該クライアント側セキュリティプロバイダサブシステムは、送信のために、該ユーザ認証証明に基づいて、ユーザ認証データを生成し、該クライアント側仮想チャネルドライバに該ユーザ認証データを送信する、クライアントコンピュータデバイスと、
サーバ側仮想チャネルドライバ、サーバ側セキュリティプロバイダサブシステム、およびサーバ側認証モジュールを含むサーバコンピュータデバイスであって、該サーバ側仮想チャネルドライバは、該送信されたユーザ認証データを受信し、該サーバ側認証モジュールに該受信された認証データを提供し、該サーバ側認証モジュールは、該サーバ側セキュリティプロバイダサブシステムに該ユーザ認証データを送信し、該セキュリティプロバイダサブシステムは、認証表示を用いて該ユーザ認証データに応答する、サーバコンピュータデバイスと
を備える、システム。
【請求項１８】
前記クライアントコンピュータデバイスが、パーソナルコンピュータを備える、請求項１７に記載のシステム。
【請求項１９】
前記クライアントコンピュータデバイスが、携帯情報端末を備える、請求項１７に記載のシステム。
【請求項２０】
前記クライアントコンピュータデバイスが、携帯電話を備える、請求項１７に記載のシステム。
【請求項２１】
前記クライアント側認証モジュールが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）グラフィカル識別および認証モジュールを備える、請求項１７に記載のシステム。
【請求項２２】
前記クライアント側認証モジュールが、ｐａｍ＿ｋｒｂモジュールを使用する、Ｕｎｉｘ（登録商標) Ｐｌｕｇｇａｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒを備える、請求項１７に記載のシステム。
【請求項２３】
前記クライアント側認証モジュールが、Ｕｎｉｘ（登録商標） ｋｉｎｉｔコマンドプログラムを備える、請求項１７に記載のシステム。
【請求項２４】
前記クライアント側セキュリティプロバイダサブシステムが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）を備える、請求項１７に記載のシステム。
【請求項２５】
前記クライアント側セキュリティプロバイダサブシステムが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を備える、請求項１７に記載のシステム。
【請求項２６】
前記クライアント側仮想チャネルドライバが、前記ユーザ認証データの少なくとも一部を含む、少なくとも１つの仮想チャネルメッセージを送信する、請求項１７に記載のシステム。
【請求項２７】
前記サーバ側認証モジュールが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）グラフィカル識別および認証モジュールを備える、請求項１７に記載のシステム。
【請求項２８】
前記サーバ側セキュリティプロバイダサブシステムが、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｉｎｔｅｒｆａｃｅ（ＳＳＰＩ）を備える、請求項１７に記載のシステム。
【請求項２９】
前記サーバ側セキュリティプロバイダサブシステムが、Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＧＳＳＡＰＩ）を備える、請求項１７のシステム。
【請求項３０】
前記サーバ側セキュリティプロバイダサブシステムが、前記ユーザ認証データに応答して、ログオンセッションおよび対応するアクセストークンを生成する、請求項１７に記載のシステム。
【請求項３１】
サーバベースのコンピュータ環境におけるサーバに、ユーザをリモートに認証するための、コンピュータ読取可能プログラム手段が組み入れられている製造品であって、該製造品は、
ユーザ証明を受信するためのコンピュータ読取可能プログラム手段と、
該受信された証明に基づいて、ユーザ認証データを生成するためのコンピュータ読取可能プログラム手段と、
該生成されたユーザ認証データをサーバコンピュータデバイスに送信するためのコンピュータ読取可能プログラム手段と、
該送信されたユーザ認証データに応答して、該ユーザを認証するためのコンピュータ読取可能プログラム手段と
を備える、製造品。
【請求項３２】
受信するための前記コンピュータ読取可能プログラム手段が、バイオメトリックユーザ証明を受信するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３３】
受信するための前記コンピュータ読取可能プログラム手段が、スマートカードからユーザ証明を受信するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３４】
生成するための前記コンピュータ読取可能プログラム手段が、前記受信されたユーザ証明を表す暗号化されたビットストリングを生成するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３５】
生成するための前記コンピュータ読取可能プログラム手段が、前記受信されたユーザ証明に基づいて、ユーザ認証データを生成するためのコンピュータ読取可能プログラム手段を備える、請求項３１に記載の製造品。
【請求項３６】
送信するための前記コンピュータ読取可能プログラム手段が、サーバコンピュータデバイスに少なくとも１つの仮想チャネルメッセージを送信するためのコンピュータ読取可能プログラム手段を備え、該少なくとも１つの仮想チャネルメッセージが、前記生成されたユーザ認証データの少なくとも一部を含む、請求項３１に記載の製造品。
【請求項３７】
前記ユーザによる成功認証に応答して、前記クライアントコンピュータデバイスから該ユーザに利用可能なリソースをホストしているサーバへの接続を開始するためのコンピュータ読取可能プログラム手段をさらに備える、請求項３１に記載の製造品。
【図１】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図４】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図４】
【公表番号】特表２００７−５２０７８９（Ｐ２００７−５２０７８９Ａ）
【公表日】平成１９年７月２６日（２００７．７．２６）
【国際特許分類】
【出願番号】特願２００６−５４１５１０（Ｐ２００６−５４１５１０）
【出願日】平成１６年１１月２３日（２００４．１１．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０４１１８７
【国際公開番号】ＷＯ２００５／０５５０２６
【国際公開日】平成１７年６月１６日（２００５．６．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＲＡＭ
２．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
【公表日】平成１９年７月２６日（２００７．７．２６）
【国際特許分類】
【出願日】平成１６年１１月２３日（２００４．１１．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０４１１８７
【国際公開番号】ＷＯ２００５／０５５０２６
【国際公開日】平成１７年６月１６日（２００５．６．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＲＡＭ
２．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
[ Back to top ]