JP6957764B2 - 高速スマートカードログオン - Google Patents

Description

本発明は概して、スマートカードを使用してリモートコンピューティング環境にクライアントをログオンさせることに関する。

従来、スマートカード認証は、サーバ（認証）デバイスとクライアントデバイスとの間の多数のインタラクションを必要とする。リモートコンピューティング環境では、その多数のインタラクションは、サーバとクライアントとの間の接続におけるレイテンシの増加によって、大幅に遅くなる。

以下に、本明細書に記載の様々な態様の簡略化した概要を提示する。本概要は広範な概観ではなく、主要なもしくは重要な要素を特定することも、特許請求の範囲を線引きすることも意図していない。以下の概要は、以下に提供するより詳細な説明への導入的な前置きとして、一部の概念を簡略化した形で提示するものにすぎない。

上述した従来技術の限界を克服し、本明細書を読解すると明らかになる他の限界を克服するために、本明細書に記載の態様は、たとえばスマートカードを用いた、より高速かつより効率的なログオンのための方法及びシステムを対象とする。

高速スマートカードログオンを使用して、レイテンシを短縮し、セキュリティを向上させ得る。たとえば、システムは、認証に使用されるサーバデバイスとクライアントデバイスとの間の動作（たとえば、インタラクション）の回数を削減し得る。これらの動作は、スマートカードからユーザ証明書をフェッチすること、またはデータに署名することを含んでもよい。高速スマートカードログオンはまた、任意選択でネットワークを介したＰＩＮ（または他の資格情報）の伝送を回避し、ＰＩＮキャッシングに頼ることのない、実際のリモートコンピューティング環境へのログオンにスマートカードを使用した、認証イベント（たとえば、セキュアソケットレイヤ（ＳＳＬ）またはトランスポートレイヤセキュリティ（ＴＬＳ）認証）からのシングルサインオンを可能にすることにより、セキュリティを向上させ得る。

高速スマートカードログオンを実装するために使用されるコンポーネントはまた、フェデレーテッドフルドメインログオンを実装するために使用されてもよい。外部認証イベントの受諾に基づいて、仮想スマートカード資格情報が発行されてもよく、これは一時的なものでもよい。例示的な外部認証イベントには、セキュリティアサーションマークアップ言語（ＳＡＭＬ）アイデンティティプロバイダにおけるログオンと、ＴＬＳまたはＳＳＬを介したスマートカード認証と、ＡＤパスワードを使用しないバイオメトリクスまたはワンタイムパスワード（ＯＴＰ）などの代替的な認証資格情報と、が含まれる。また、高速スマートカードログオンからの証明書動作インターセプトコンポーネントを使用して、ＰＣ／ＳＣのＡＰＩレベルでスマートカードを完全にエミュレートすることなく、仮想スマートカードとのインタラクションを可能にし得る。仮想スマートカードは、リモートコンピューティング環境上でローカルに、または高度に保護され得る別のサーバ上で作成されてもよい。

本明細書に記載の態様は、より高速なスマートカードログオンのためのシステム、装置、コンピュータ可読媒体、メモリ、及び方法を対象とする。方法は、サーバとクライアントデバイスとの間にリモーティングチャネルを確立することを含んでもよい。サーバは、クライアントデバイスから、及び／またはパーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）プロトコルを介して、クライアントデバイスに関連付けられたスマートカードの識別子を含むメッセージを受信してもよい。サーバは、識別子をスマートカードの代替識別子に置き換えてもよい。代替識別子に基づいて、サーバは、スマートカードに関連する１つまたは複数の暗号動作に使用する暗号サービスプロバイダを決定してもよい。この方法は、決定された暗号サービスプロバイダを介して、リモーティングチャネルを介して、及び／またはクライアントデバイスに、スマートカードを必要とする暗号動作の１つまたは複数の要求を送信することを含んでもよい。

一部の例では、識別子はリセット応答（ＡＴＲ）データを含んでもよく、代替識別子は代替ＡＴＲデータを含んでもよい。追加的または代替的には、スマートカードの識別子は、スマートカードのスマートカードタイプを識別してもよい。

一部の例では、暗号サービスプロバイダを決定することは、代替識別子と、スマートカードを用いた１つまたは複数の暗号動作に使用する暗号サービスプロバイダとの間の関連付けについてデータベースに照会することを含んでもよい。一部のシナリオでは、データベースはレジストリを含んでもよい。この方法は、代替識別子を生成すること、及び／または、スマートカードを用いた１つまたは複数の暗号動作に使用する暗号サービスプロバイダに関連付けて代替識別子をデータベースに記憶すること、を含んでもよい。一部の例では、スマートカードを用いた１つまたは複数の暗号動作に使用する暗号サービスプロバイダに関連付けて代替識別子を記憶することは、スマートカードを用いた１つまたは複数の暗号動作に使用する暗号サービスプロバイダを識別する情報と同じファイルに代替識別子を記憶することを含んでもよい。

これら及び追加の態様は、以下でさらに詳細に説明する本開示の恩恵を受けて理解されよう。

添付図面を考慮して以下の説明を参照することによって、本明細書に記載の態様及びそれらの利点のより完全な理解が得られ、添付図面では、同様の参照番号は同様の特徴を示す。

本明細書に記載の１つまたは複数の態様に従って使用され得る例示的なコンピュータシステムのアーキテクチャを示す図である。 本明細書に記載の１つまたは複数の態様に従って使用され得る例示的なリモートアクセスシステムのアーキテクチャを示す図である。 本明細書に記載の１つまたは複数の態様に従って使用され得る例示的な仮想化（ハイパーバイザ）システムのアーキテクチャを示す図である。 本明細書に記載の１つまたは複数の態様に従って使用され得る例示的なクラウドベースのシステムのアーキテクチャを示す図である。 例示的な企業モビリティ管理システムを示す図である。 他の例示的な企業モビリティ管理システムを示す図である。 本明細書に記載の１つまたは複数の態様によるスマートカードログオンのための例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様による高速スマートカードログオンのための例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様による高速スマートカードログオンのための他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様による高速スマートカードログオンのためのさらに他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様によるフェデレーテッドログオンのための例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様によるフェデレーテッドログオンのための他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様によるフェデレーテッドログオンのためのさらに他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様によるフェデレーテッドログオンのための他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様によるアプリケーションストア、資格情報マッパー、及び仮想化エージェントの間の例示的なインタラクションを示す図である。 本明細書に記載の１つまたは複数の態様によるフェデレーテッドログオンのためのさらに他の例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様による資格情報マッピングサービスを提供するための例示的なシステムを示す図である。 本明細書に記載の１つまたは複数の態様による例示的なスマートカードのデータベースを示す図である。 本明細書に記載の１つまたは複数の態様による例示的なスマートカードのデータベースを示す図である。 本明細書に記載の１つまたは複数の態様による例示的なユーザインターフェースを示す図である。

様々な実施形態の以下の説明では、上記で明らかにした、本明細書の一部を形成する添付図面を参照し、添付図面では、本明細書に記載の態様が実施され得る様々な実施形態を例として示している。本明細書に記載の範囲から逸脱することなく、他の実施形態が利用されてもよく、構造的及び機能的な変更が加えられてもよいことは理解されたい。様々な態様は他の実施形態が可能であり、様々な異なる方法で実施または実行することが可能である。

以下でより詳細に説明する主題の概略的な紹介として、本明細書に記載の態様は、より高速なスマートカードログオンのためのシステム、装置、コンピュータ可読媒体、メモリ、及び方法を対象とする。サーバとクライアントデバイスとの間にリモーティングチャネルが確立されてもよい。サーバは、クライアントデバイスから、及び／またはパーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）プロトコルを介して、クライアントデバイスに関連付けられたスマートカードの識別子を含むメッセージを受信してもよい。サーバは、スマートカードの識別子を代替識別子に置き換えてもよい。代替識別子に基づいて、サーバは、スマートカードに関連する１つまたは複数の暗号動作に使用する暗号サービスプロバイダを決定してもよい。一部の態様では、たとえば、決定された暗号サービスプロバイダを介して、及び／またはリモーティングチャネルを介して、クライアントデバイスに、スマートカードを必要とする暗号動作の１つまたは複数の要求が送信されてもよい。

本明細書で使用する表現及び用語は、説明を目的としたものであり、限定するものと見なされるべきでないことは理解されたい。むしろ、本明細書で使用する表現及び用語には、それらの最も広い解釈及び意味が与えられるべきである。「含む（ｉｎｃｌｕｄｉｎｇ）」及び「備える（ｃｏｍｐｒｉｓｉｎｇ）」ならびにそれらの変形の使用は、それらの後に列挙した項目及びそれらの均等物、ならびに追加の項目及びそれらの均等物を包含するものとする。「取り付けられた」、「接続された」、「結合される」、「位置付けられた」、「係合された」という用語及び同様の用語の使用は、直接及び間接両方の取り付け、接続、結合、位置付け、及び係合を含むものとする。

コンピューティングアーキテクチャ
コンピュータソフトウェア、ハードウェア及びネットワークは、とりわけ、スタンドアロン環境、ネットワーク化環境、リモートアクセス（リモートデスクトップとしても知られている）環境、仮想化環境、及び／またはクラウドベースの環境を含む、多様な異なるシステム環境で利用され得る。図１に、スタンドアロン環境及び／またはネットワーク化環境において本明細書に記載の１つまたは複数の例示的な態様を実装するために使用され得るシステムアーキテクチャ及びデータ処理デバイスの一例を示す。様々なネットワークノード１０３、１０５、１０７、及び１０９が、インターネットなどのワイドエリアネットワーク（ＷＡＮ）１０１を介して相互接続されてもよい。プライベートイントラネット、企業ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、無線ネットワーク、パーソナルネットワーク（ＰＡＮ）などを含む他のネットワークが追加的にまたは代替的に使用されてもよい。ネットワーク１０１は例示を目的としたものであり、より少数のまたは追加のコンピュータネットワークに置き換えられてもよい。ローカルエリアネットワーク１３３はあらゆる知られているＬＡＮトポロジのうちの１つまたは複数を有してもよく、Ｅｔｈｅｒｎｅｔなどの多様な異なるプロトコルのうちの１つまたは複数を使用してもよい。デバイス１０３、１０５、１０７、及び１０９ならびに他のデバイス（図示せず）は、ツイストペア線、同軸ケーブル、光ファイバ、電波、または他の通信媒体を介してネットワークのうちの１つまたは複数に接続されてもよい。

本明細書で使用し、図面に示す「ネットワーク」という用語は、リモートストレージデバイスが１つまたは複数の通信経路を介して相互に結合されるシステムを指すだけでなく、記憶機能を有するそのようなシステムに、その時々に結合され得るスタンドアロンデバイスも指す。結果的に、「ネットワーク」という用語は、「物理ネットワーク」だけでなく、全ての物理ネットワークにわたって存在する、単一のエンティティに帰属する、データから構成される「コンテンツネットワーク」も含む。

コンポーネントは、データサーバ１０３、ウェブサーバ１０５、及びクライアントコンピュータ１０７、１０９を含んでもよい。データサーバ１０３は、本明細書に記載の１つまたは複数の例示的な態様を実施するためのデータベース及び制御ソフトウェアの全体的なアクセス、制御、及び管理を提供する。データサーバ１０３はウェブサーバ１０５に接続されてもよく、それを介してユーザはインタラクトし、要求通りにデータを取得する。代替的には、データサーバ１０３は、ウェブサーバ自体として機能し、インターネットに直接接続されてもよい。データサーバ１０３は、ローカルエリアネットワーク１３３、ワイドエリアネットワーク１０１（たとえば、インターネット）経由で、直接もしくは間接的な接続を介して、または他の何らかのネットワークを介して、ウェブサーバ１０５に接続されてもよい。ユーザはリモートコンピュータ１０７、１０９を使用して、たとえばウェブブラウザを使用して、ウェブサーバ１０５によってホストされる１つまたは複数の外部に公開されたウェブサイトを介してデータサーバ１０３に接続することによって、データサーバ１０３とインタラクトしてもよい。クライアントコンピュータ１０７、１０９をデータサーバ１０３と協働させて使用して、そこに記憶されたデータにアクセスしてもよく、または他の目的で使用してもよい。たとえば、クライアントデバイス１０７から、ユーザは当技術分野で知られているようにインターネットブラウザを使用して、またはコンピュータネットワーク（インターネットなど）を介してウェブサーバ１０５及び／またはデータサーバ１０３と通信するソフトウェアアプリケーションを実行することにより、ウェブサーバ１０５にアクセスしてもよい。

サーバ及びアプリケーションは、同じ物理マシン上で組み合わせられ、別々の仮想アドレスもしくは論理アドレスを保持してもよく、または別々の物理マシンに存在してもよい。図１は、使用され得るネットワークアーキテクチャのほんの一例を示しており、当業者は、使用される特定のネットワークアーキテクチャ及びデータ処理デバイスが変更されてもよく、本明細書でさらに説明するように、それらが提供する機能に対して二次的なものであることを理解するであろう。たとえば、ウェブサーバ１０５及びデータサーバ１０３によって提供されるサービスは単一のサーバ上で組み合わせられてもよい。

各コンポーネント１０３、１０５、１０７、１０９は、任意のタイプの知られているコンピュータ、サーバ、またはデータ処理デバイスであってもよい。データサーバ１０３は、たとえば、データサーバ１０３の動作全体を制御するプロセッサ１１１を含んでもよい。データサーバ１０３は、ランダムアクセスメモリ（ＲＡＭ）１１３、読み取り専用メモリ（ＲＯＭ）１１５、ネットワークインターフェース１１７、入力／出力インターフェース１１９（たとえば、キーボード、マウス、ディスプレイ、プリンタなど）、及びメモリ１２１をさらに含んでもよい。入力／出力（Ｉ／Ｏ）１１９は、データまたはファイルの読み込み、書き込み、表示、及び／または印刷のための多様なインターフェースユニット及びドライブを含んでもよい。メモリ１２１は、データ処理デバイス１０３の動作全体を制御するためのオペレーティングシステムソフトウェア１２３と、本明細書に記載の態様を実施するようにデータサーバ１０３に指示するための制御ロジック１２５と、本明細書に記載の態様と共に使用してもよく、使用しない場合もある二次的な機能、サポート機能、及び／または他の機能を提供する他のアプリケーションソフトウェア１２７と、をさらに記憶してもよい。制御ロジック１２５は、本明細書ではデータサーバソフトウェア１２５と呼ぶこともある。データサーバソフトウェア１２５の機能は、制御ロジック１２５内にコード化されたルールに基づいて自動的に行われる動作もしくは判定、ユーザがシステムに入力を提供することによって手動で行われる動作もしくは判定、及び／またはユーザ入力に基づく自動処理（たとえば、クエリ、データ更新など）の組み合わせを指す場合がある。

メモリ１２１は、第１のデータベース１２９及び第２のデータベース１３１を含む、本明細書に記載の１つまたは複数の態様を実施する際に使用されるデータも記憶してもよい。一部の実施形態では、第１のデータベース１２９は、第２のデータベース１３１を（たとえば、別個のテーブル、レポートなどとして）含んでもよい。すなわち、情報は、システム設計に応じて、単一のデータベースに記憶するか、または異なる論理データベース、仮想データベース、もしくは物理データベースに分けることができる。デバイス１０５、１０７、及び１０９は、デバイス１０３に関して説明したのと同様のまたは異なるアーキテクチャを有してもよい。本明細書に記載のデータ処理デバイス１０３（またはデバイス１０５、１０７、もしくは１０９）の機能を複数のデータ処理デバイスに拡散させて、たとえば、複数のコンピュータに処理負荷を分散させて、地理的な場所、ユーザアクセスレベル、サービス品質（ＱｏＳ）などに基づいてトランザクションを分別してもよいことを当業者は理解するであろう。

１つまたは複数の態様は、本明細書に記載の１つまたは複数のコンピュータまたは他のデバイスによって実行される１つまたは複数のプログラムモジュールなどの中の、コンピュータ使用可能もしくは読取可能データ及び／またはコンピュータ実行可能命令で具現化されてもよい。一般に、プログラムモジュールは、コンピュータまたは他のデバイス内のプロセッサによって実行された場合に、特定のタスクを実施するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。モジュールは、実行のために後でコンパイルされるソースコードプログラミング言語で記述されてもよく、またはハイパーテキストマークアップ言語（ＨＴＭＬ）もしくは拡張可能マークアップ言語（ＸＭＬ）などの（ただし、これらに限定されない）スクリプト言語で記述されてもよい。コンピュータ実行可能命令は、不揮発性ストレージデバイスなどのコンピュータ可読媒体に記憶されてもよい。ハードディスク、ＣＤ−ＲＯＭ、光学ストレージデバイス、磁気ストレージデバイス、及び／またはそれらの任意の組み合わせを含む、任意の適切なコンピュータ可読記憶媒体が利用されてもよい。加えて、本明細書に記載のデータまたはイベントを表す様々な伝送（非記憶）媒体は、金属線、光ファイバ、及び／または無線伝送媒体（たとえば、空気及び／または空間）などの信号伝導媒体の中を進む電磁波の形で、ソースと宛先との間で転送されてもよい。本明細書に記載の様々な態様は、方法、データ処理システム、またはコンピュータプログラム製品として具現化されてもよい。そのため、様々な機能は、ソフトウェア、ファームウェア、及び／またはハードウェアもしくはハードウェア均等物、たとえば、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などで、全体的にまたは部分的に具現化されてもよい。本明細書に記載の１つまたは複数の態様をより効果的に実装するために特定のデータ構造が使用されてもよく、そのようなデータ構造は、本明細書に記載のコンピュータ実行可能命令及びコンピュータ使用可能データの範囲内で企図される。

図２をさらに参照すると、本明細書に記載の１つまたは複数の態様はリモートアクセス環境に実装されてもよい。図２に、本明細書に記載の１つまたは複数の例示的な態様に従って使用され得る例示的なコンピューティング環境２００におけるコンピューティングデバイス２０１を含む例示的なシステムアーキテクチャを示す。コンピューティングデバイス２０１は、単一サーバまたはマルチサーバのデスクトップ仮想化システム（たとえば、リモートアクセスまたはクラウドシステム）内のサーバ２０６ａとして使用されてもよく、クライアントアクセスデバイスに仮想マシンを提供するように構成することができる。コンピューティングデバイス２０１は、デバイス２０１の動作全体を制御するプロセッサ２０３と、それに関連するコンポーネント、たとえば、ＲＡＭ２０５、ＲＯＭ２０７、入力／出力（Ｉ／Ｏ）モジュール２０９、及びメモリ２１５と、を有してもよい。

Ｉ／Ｏモジュール２０９は、コンピューティングデバイス２０１のユーザがそれを介して入力を提供し得るマウス、キーパッド、タッチスクリーン、スキャナ、光学リーダ、及び／またはスタイラス（もしくは他の入力デバイス（複数可））を含んでもよく、また、音声出力を提供するためのスピーカーのうちの１つまたは複数と、テキスト、オーディオビジュアル、及び／またはグラフィカル出力を提供するためのビデオディスプレイデバイスのうちの１つまたは複数と、を含んでもよい。ソフトウェアは、本明細書に記載の様々な機能を実施するために、コンピューティングデバイス２０１を専用コンピューティングデバイスに構成するための命令をプロセッサ２０３に提供するように、メモリ２１５及び／または他のストレージ内に記憶されてもよい。たとえば、メモリ２１５は、コンピューティングデバイス２０１によって使用されるソフトウェア、たとえば、オペレーティングシステム２１７、アプリケーションプログラム２１９、及び関連するデータベース２２１を記憶してもよい。

コンピューティングデバイス２０１は、端末２４０（クライアントデバイスとも呼ばれる）などの１つまたは複数のリモートコンピュータへの接続をサポートするネットワーク化環境で動作してもよい。端末２４０は、コンピューティングデバイス１０３または２０１に関して上述した要素の多くまたは全てを含むパーソナルコンピュータ、モバイルデバイス、ラップトップコンピュータ、タブレット、またはサーバであってもよい。図２に示すネットワーク接続は、ローカルエリアネットワーク（ＬＡＮ）２２５及びワイドエリアネットワーク（ＷＡＮ）２２９を含むが、他のネットワークをさらに含んでもよい。ＬＡＮネットワーキング環境で使用される場合、コンピューティングデバイス２０１は、ネットワークインターフェースまたはアダプタ２２３を介してＬＡＮ２２５に接続されてもよい。ＷＡＮネットワーキング環境で使用される場合、コンピューティングデバイス２０１は、コンピュータネットワーク２３０（たとえば、インターネット）などのＷＡＮ２２９を介して通信を確立するためのモデムまたは他のワイドエリアネットワークインターフェース２２７を含んでもよい。図示したネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段が使用されてもよいことは理解されよう。コンピューティングデバイス２０１及び／または端末２４０はまた、バッテリ、スピーカー、及びアンテナ（図示せず）などの他の様々なコンポーネントを含むモバイル端末（たとえば、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ノートブックなど）であってもよい。

本明細書に記載の態様は、他の多くの汎用または専用コンピューティングシステム環境または構成でも動作可能であってもよい。本明細書に記載の態様での使用に適し得る他のコンピューティングシステム、環境、及び／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークパーソナルコンピュータ（ＰＣ）、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、これらに限定されない。

図２に示すように、１つまたは複数のクライアントデバイス２４０は、１つまたは複数のサーバ２０６ａ〜２０６ｎ（本明細書では総称して「サーバ（複数可）２０６」と呼ぶ）と通信可能であってもよい。一実施形態では、コンピューティング環境２００は、サーバ（複数可）２０６とクライアントマシン（複数可）２４０との間に設置されるネットワークアプライアンスを含んでもよい。ネットワークアプライアンスはクライアント／サーバ接続を管理してもよく、一部のケースでは、複数のバックエンドサーバ２０６間でクライアント接続の負荷分散を行うことができる。

クライアントマシン（複数可）２４０は、一部の実施形態では、単一クライアントマシン２４０または単一グループのクライアントマシン２４０と呼ぶ場合があり、サーバ（複数可）２０６は、単一サーバ２０６または単一グループのサーバ２０６と呼ぶ場合がある。一実施形態では、単一クライアントマシン２４０は２つ以上のサーバ２０６と通信し、他の実施形態では、単一サーバ２０６は２つ以上のクライアントマシン２４０と通信する。さらに他の実施形態では、単一クライアントマシン２４０は単一サーバ２０６と通信する。

クライアントマシン２４０は、一部の実施形態では、次の非網羅的な用語、すなわち、クライアントマシン（複数可）、クライアント（複数可）、クライアントコンピュータ（複数可）、クライアントデバイス（複数可）、クライアントコンピューティングデバイス（複数可）、ローカルマシン、リモートマシン、クライアントノード（複数可）、エンドポイント（複数可）、またはエンドポイントノード（複数可）、のうちのいずれか１つによって言及する場合がある。サーバ２０６は、一部の実施形態では、次の非網羅的な用語、すなわち、サーバ（複数可）、ローカルマシン、リモートマシン、サーバファーム（複数可）、またはホストコンピューティングデバイス（複数可）、のうちのいずれか１つによって言及する場合がある。

一実施形態では、クライアントマシン２４０は仮想マシンであってもよい。仮想マシンは任意の仮想マシンであってもよく、一部の実施形態では、仮想マシンは、タイプ１またはタイプ２ハイパーバイザ、たとえば、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ、ＩＢＭ、ＶＭｗａｒｅによって開発されたハイパーバイザ、または他の任意のハイパーバイザによって管理される任意の仮想マシンであってもよい。一部の態様では、仮想マシンはハイパーバイザによって管理されてもよく、他の態様では、仮想マシンは、サーバ２０６上で実行されるハイパーバイザ、またはクライアント２４０上で実行されるハイパーバイザによって管理されてもよい。

一部の実施形態は、サーバ２０６またはリモート配置された他のマシン上で、リモートで実行されるアプリケーションによって生成されるアプリケーション出力を表示するクライアントデバイス２４０を含む。これらの実施形態では、クライアントデバイス２４０は、仮想マシンのレシーバプログラムまたはアプリケーションを実行して、アプリケーションウインドウ、ブラウザ、または他の出力ウインドウに出力を表示してもよい。一例では、そのアプリケーションはデスクトップであり、他の例では、そのアプリケーションは、デスクトップを生成または提示するアプリケーションである。デスクトップは、ローカル及び／またはリモートアプリケーションを統合することができるオペレーティングシステムのインスタンスに対するユーザインターフェースを提供するグラフィカルシェルを含んでもよい。アプリケーションとは、本明細書で使用する場合、オペレーティングシステムのインスタンスが（及び任意選択でデスクトップも）ロードされた後に実行されるプログラムである。

サーバ２０６は、一部の実施形態では、リモートプレゼンテーションプロトコルまたは他のプロトコルを使用して、シンクライアントまたはクライアント上で実行されるリモートディスプレイアプリケーションにデータを送信し、サーバ２０６上で実行されるアプリケーションによって生成されたディスプレイ出力を提示する。シンクライアントまたはリモートディスプレイプロトコルは、次の非網羅的なプロトコルのリスト、すなわち、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，Ｆｔ．Ｌａｕｄｅｒｄａｌｅ，Ｆｌｏｒｉｄａによって開発されたインディペンデントコンピューティングアーキテクチャ（ＩＣＡ）プロトコル、またはＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ，Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎによって作られたリモートデスクトッププロトコル（ＲＤＰ）、のうちのいずれか１つとすることができる。

リモートコンピューティング環境は、２つ以上のサーバ２０６ａ〜２０６ｎを含むことによって、サーバ２０６ａ〜２０６ｎが、たとえばクラウドコンピューティング環境におけるサーバファーム２０６に論理的にグループ化されるようにしてもよい。サーバファーム２０６は、論理的にグループ化されつつも地理的に分散しているサーバ２０６、または論理的にグループ化されつつも互いに近接して配置されたサーバ２０６を含んでもよい。サーバファーム２０６内の地理的に分散したサーバ２０６ａ〜２０６ｎは、一部の実施形態では、ＷＡＮ（ワイド）、ＭＡＮ（メトロポリタン）、またはＬＡＮ（ローカル）を使用して通信することができ、異なる地理的地域は、異なる大陸、ある大陸の異なる地域、異なる国、異なる州、異なる都市、異なるキャンパス、異なる部屋、または前述の地理的な場所の任意の組み合わせとみなすことができる。一部の実施形態では、サーバファーム２０６は単一のエンティティとして管理されてもよく、他の実施形態では、サーバファーム２０６は複数のサーバファームを含むことができる。

一部の実施形態では、サーバファームは、実質的に同様のタイプのオペレーティングシステムプラットフォーム（たとえば、ＷＩＮＤＯＷＳ(登録商標)、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ、ｉＯＳ、ＡＮＤＲＯＩＤ（登録商標）、ＳＹＭＢＩＡＮなど）を実行するサーバ２０６を含んでもよい。他の実施形態では、サーバファーム２０６は、第１のタイプのオペレーティングシステムプラットフォームを実行する第１のグループの１つまたは複数のサーバと、第２のタイプのオペレーティングシステムプラットフォームを実行する第２のグループの１つまたは複数のサーバとを含んでもよい。

サーバ２０６は、必要に応じて、任意のタイプのサーバとして、たとえば、ファイルサーバ、アプリケーションサーバ、ウェブサーバ、プロキシサーバ、アプライアンス、ネットワークアプライアンス、ゲートウェイ、アプリケーションゲートウェイ、ゲートウェイサーバ、仮想化サーバ、デプロイメントサーバ、セキュアソケットレイヤ（ＳＳＬ）ＶＰＮサーバ、ファイアウォール、ウェブサーバ、アプリケーションサーバ、もしくはマスターアプリケーションサーバ、アクティブディレクトリ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ）を実行するサーバ、またはファイアウォール機能、アプリケーション機能、もしくは負荷分散機能を提供するアプリケーションアクセラレーションプログラムを実行するサーバとして構成されてもよい。他のサーバタイプも使用されてもよい。

一部の実施形態は、第１のサーバ２０６ａを含み、第１のサーバ２０６ａは、クライアントマシン２４０から要求を受信し、要求を第２のサーバ２０６ｂ（図示せず）に転送し、第２のサーバ２０６ｂ（図示せず）からの応答を用いて、クライアントマシン２４０により生成された要求に応答する。第１のサーバ２０６ａはクライアントマシン２４０が利用可能なアプリケーションの一覧表に加え、アプリケーションの一覧表内で識別されるアプリケーションをホストするアプリケーションサーバ２０６に関連するアドレス情報を取得してもよい。第１のサーバ２０６ａは次いで、ウェブインターフェースを使用してクライアントの要求に対する応答を提示し、クライアント２４０と直接通信して、識別されたアプリケーションへのアクセスをクライアント２４０に提供することができる。１つまたは複数のクライアント２４０及び／または１つまたは複数のサーバ２０６は、ネットワーク２３０、たとえばネットワーク１０１上でデータを伝送してもよい。

図３に、例示的なデスクトップ仮想化システムの高レベルアーキテクチャを示す。図示のように、デスクトップ仮想化システムは、１つまたは複数のクライアントアクセスデバイス２４０に仮想デスクトップ及び／または仮想アプリケーションを提供するように構成される少なくとも１つの仮想化サーバ３０１を含む、単一サーバもしくはマルチサーバシステム、またはクラウドシステムであってもよい。本明細書で使用する場合、デスクトップとは、１つまたは複数のアプリケーションがホスト及び／または実行されてもよいグラフィカル環境または空間を指す。デスクトップは、ローカル及び／またはリモートアプリケーションを統合することができるオペレーティングシステムのインスタンスに対するユーザインターフェースを提供するグラフィカルシェルを含んでもよい。アプリケーションは、オペレーティングシステムのインスタンス（及び任意選択でデスクトップも）がロードされた後に実行されるプログラムを含んでもよい。オペレーティングシステムの各インスタンスは、物理的なもの（たとえば、１デバイスにつき１つのオペレーティングシステム）であってもよく、仮想的なもの（たとえば、単一デバイス上で稼動するＯＳの多数のインスタンス）であってもよい。各アプリケーションはローカルデバイス上で実行されてもよく、リモート配置されたデバイス上で実行（たとえば、リモーティング）されてもよい。

コンピュータデバイス３０１は、仮想化環境における仮想化サーバとして、たとえば、単一サーバ、マルチサーバ、またはクラウドコンピューティング環境として構成されてもよい。図３に示す仮想化サーバ３０１は、図２に示すサーバ２０６の１つまたは複数の実施形態、あるいは他の知られているコンピューティングデバイスとしてデプロイすることができ、及び／またはそれらによって実装することができる。１つまたは複数の物理ディスク３０４、１つまたは複数の物理デバイス３０６、１つまたは複数の物理プロセッサ３０８、及び１つまたは複数の物理メモリ３１６を含むことができるハードウェアレイヤが、仮想化サーバ３０１に含まれる。一部の実施形態では、ファームウェア３１２を物理メモリ３１６のメモリ素子内に記憶することができ、物理プロセッサ３０８のうちの１つまたは複数によって実行することができる。仮想化サーバ３０１は物理メモリ３１６のメモリ素子内に記憶され、物理プロセッサ３０８のうちの１つまたは複数によって実行され得るオペレーティングシステム３１４をさらに含んでもよい。またさらに、ハイパーバイザ３０２を物理メモリ３１６のメモリ素子内に記憶してもよく、物理プロセッサ３０８のうちの１つまたは複数によって実行することができる。

物理プロセッサ３０８のうちの１つまたは複数で実行されるのは、１つまたは複数の仮想マシン３３２Ａ〜Ｃ（総称して３３２）であってもよい。各仮想マシン３３２は仮想ディスク３２６Ａ〜Ｃ及び仮想プロセッサ３２８Ａ〜Ｃを有してもよい。一部の実施形態では、第１の仮想マシン３３２Ａは、仮想プロセッサ３２８Ａを使用して、ツールスタック３２４を含む制御プログラム３２０を実行してもよい。制御プログラム３２０は、制御仮想マシン、Ｄｏｍ０、ドメイン０、またはシステム管理及び／または制御に使用される他の仮想マシンと呼ばれる場合がある。一部の実施形態では、１つまたは複数の仮想マシン３３２Ｂ〜Ｃは、仮想プロセッサ３２８Ｂ〜Ｃを使用して、ゲストオペレーティングシステム３３０Ａ〜Ｂを実行することができる。

仮想化サーバ３０１は、仮想化サーバ３０１と通信する１つまたは複数のハードウェアを有するハードウェアレイヤ３１０を含んでもよい。一部の実施形態では、ハードウェアレイヤ３１０は、１つまたは複数の物理ディスク３０４、１つまたは複数の物理デバイス３０６、１つまたは複数の物理プロセッサ３０８、及び１つまたは複数の物理メモリ３１６を含むことができる。物理コンポーネント３０４、３０６、３０８、及び３１６は、たとえば、上述したコンポーネントのいずれを含んでもよい。物理デバイス３０６は、たとえば、ネットワークインターフェースカード、ビデオカード、キーボード、マウス、入力デバイス、モニタ、ディスプレイデバイス、スピーカー、光学ドライブ、ストレージデバイス、ユニバーサルシリアルバス接続、プリンタ、スキャナ、ネットワーク要素（たとえば、ルータ、ファイアウォール、ネットワークアドレス変換器、ロードバランサ、仮想プライベートネットワーク（ＶＰＮ）ゲートウェイ、動的ホスト構成プロトコル（ＤＨＣＰ）ルータなど）、または仮想化サーバ３０１に接続されるかもしくはこれと通信する任意のデバイスを含んでもよい。ハードウェアレイヤ３１０内の物理メモリ３１６は、任意のタイプのメモリを含んでもよい。物理メモリ３１６はデータを記憶してもよく、一部の実施形態では、１つまたは複数のプログラム、あるいは実行可能命令のセットを記憶してもよい。図３に、仮想化サーバ３０１の物理メモリ３１６内にファームウェア３１２が記憶される一実施形態を示す。物理メモリ３１６に記憶されたプログラムまたは実行可能命令は、仮想化サーバ３０１の１つまたは複数のプロセッサ３０８によって実行することができる。

仮想化サーバ３０１はまた、ハイパーバイザ３０２を含んでもよい。一部の実施形態では、ハイパーバイザ３０２は、仮想化サーバ３０１上でプロセッサ３０８によって実行されて、任意の数の仮想マシン３３２を作成して管理するプログラムであってもよい。ハイパーバイザ３０２は、仮想マシンモニタ、またはプラットフォーム仮想化ソフトウェアと呼ばれる場合がある。一部の実施形態では、ハイパーバイザ３０２は、実行可能命令と、コンピューティングマシン上で実行される仮想マシンを監視するハードウェアとの任意の組み合わせとすることができる。ハイパーバイザ３０２はタイプ２ハイパーバイザであってもよく、そのハイパーバイザは、仮想化サーバ３０１上で実行されるオペレーティングシステム３１４内で実行される。仮想マシンは次いで、ハイパーバイザ３０２より上のレベルで実行されてもよい。一部の実施形態では、タイプ２ハイパーバイザをユーザのオペレーティングシステムのコンテキスト内で実行させて、タイプ２ハイパーバイザがユーザのオペレーティングシステムとインタラクトするようにしてもよい。他の実施形態では、仮想化環境における１つまたは複数の仮想化サーバ３０１は、代わりにタイプ１ハイパーバイザ（図示せず）を含んでもよい。タイプ１ハイパーバイザは、ハードウェアレイヤ３１０内のハードウェア及びリソースに直接アクセスすることによって、仮想化サーバ３０１上で実行され得る。すなわち、タイプ２ハイパーバイザ３０２は、図示のようにホストオペレーティングシステム３１４経由でシステムリソースにアクセスするのに対し、タイプ１ハイパーバイザは、ホストオペレーティングシステム３１４なしで全てのシステムリソースに直接アクセスし得る。タイプ１ハイパーバイザは仮想化サーバ３０１の１つまたは複数の物理プロセッサ３０８上で直接実行され得、物理メモリ３１６に記憶されたプログラムデータを含み得る。

ハイパーバイザ３０２は、一部の実施形態では、システムリソースに直接アクセスできるオペレーティングシステム３３０または制御プログラム３２０をシミュレートする任意の方法で、仮想マシン３３２上で実行されるオペレーティングシステム３３０または制御プログラム３２０に仮想リソースを提供することができる。システムリソースは、物理デバイス３０６、物理ディスク３０４、物理プロセッサ３０８、物理メモリ３１６、及び仮想化サーバ３０１のハードウェアレイヤ３１０に含まれる他の任意のコンポーネントを含むことができるが、これらに限定されない。ハイパーバイザ３０２は、仮想ハードウェアのエミュレート、物理ハードウェアの分割、物理ハードウェアの仮想化、及び／またはコンピューティング環境へのアクセスを提供する仮想マシンの実行を行うために使用されてもよい。さらに他の実施形態では、ハイパーバイザ３０２は、仮想化サーバ３０１上で実行される仮想マシン３３２に対してプロセッサのスケジューリング及びメモリの分割を制御してもよい。ハイパーバイザ３０２は、ＶＭＷａｒｅ，Ｉｎｃ．，Ｐａｌｏ Ａｌｔｏ，Ｃａｌｉｆｏｒｎｉａによって製造されたもの、オープンソースのＸｅｎＰｒｏｊｅｃｔ．ｏｒｇコミュニティによって開発が監督されるオープンソース製品であるＸＥＮＰＲＯＪＥＣＴハイパーバイザ、Ｍｉｃｒｏｓｏｆｔによって提供されるＨｙｐｅｒＶ、ＶｉｒｔｕａｌＳｅｒｖｅｒ、もしくはｖｉｒｔｕａｌ ＰＣハイパーバイザ、またはその他を含んでもよい。一部の実施形態では、仮想化サーバ３０１は、ゲストオペレーティングシステムがその上で実行され得る仮想マシンプラットフォームを作成するハイパーバイザ３０２を実行してもよい。これらの実施形態では、仮想化サーバ３０１はホストサーバと呼ぶ場合がある。そのような仮想化サーバの一例は、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，Ｆｏｒｔ Ｌａｕｄｅｒｄａｌｅ，ＦＬによって提供されるＸＥＮＳＥＲＶＥＲである。

ハイパーバイザ３０２は、ゲストオペレーティングシステム３３０がその中で実行される１つまたは複数の仮想マシン３３２Ｂ〜Ｃ（総称して３３２）を作成してもよい。一部の実施形態では、ハイパーバイザ３０２は仮想マシンイメージをロードして仮想マシン３３２を作成してもよい。他の実施形態では、ハイパーバイザ３０２は仮想マシン３３２内でゲストオペレーティングシステム３３０を実行してもよい。さらに他の実施形態では、仮想マシン３３２はゲストオペレーティングシステム３３０を実行してもよい。

仮想マシン３３２を作成することに加えて、ハイパーバイザ３０２は少なくとも１つの仮想マシン３３２の実行を制御してもよい。他の実施形態では、ハイパーバイザ３０２は、仮想化サーバ３０１によって提供される少なくとも１つのハードウェアリソース（たとえば、ハードウェアレイヤ３１０内で利用可能な任意のハードウェアリソース）の抽象化を、少なくとも１つの仮想マシン３３２に与えてもよい。他の実施形態では、ハイパーバイザ３０２は、仮想マシン３３２が仮想化サーバ３０１内で利用可能な物理プロセッサ３０８にアクセスする方法を制御してもよい。物理プロセッサ３０８へのアクセスを制御することは、仮想マシン３３２がプロセッサ３０８にアクセスすべきか否かを判定し、物理プロセッサの能力がどのように仮想マシン３３２に与えられるかを決定することを含んでもよい。

図３に示すように、仮想化サーバ３０１は１つまたは複数の仮想マシン３３２をホストまたは実行してもよい。仮想マシン３３２は、プロセッサ３０８によって実行された場合に、仮想マシン３３２が物理コンピューティングデバイスによく似たようにプログラム及びプロセスを実行することができるよう、物理コンピュータの動作を模倣し得る実行可能命令のセットである。図３には仮想化サーバ３０１が３つの仮想マシン３３２をホストする一実施形態を示しているが、他の実施形態では、仮想化サーバ３０１は任意の数の仮想マシン３３２をホストすることができる。ハイパーバイザ３０２は、一部の実施形態では、各仮想マシン３３２に、その仮想マシン３３２が利用可能な物理ハードウェア、メモリ、プロセッサ、及び他のシステムリソースの固有の仮想ビューを提供してもよい。一部の実施形態では、固有の仮想ビューは、仮想マシンのパーミッション、１つまたは複数の仮想マシン識別子へのポリシーエンジンの適用、仮想マシンにアクセスするユーザ、仮想マシン上で実行されるアプリケーション、仮想マシンによってアクセスされるネットワーク、または他の任意の所望の基準に基づくことができる。たとえば、ハイパーバイザ３０２は１つまたは複数の非セキュア仮想マシン３３２と、１つまたは複数のセキュア仮想マシン３３２とを作成してもよい。非セキュア仮想マシン３３２は、セキュア仮想マシン３３２にはアクセスが許可され得るリソース、ハードウェア、メモリ位置、及びプログラムへのアクセスが禁止され得る。他の実施形態では、ハイパーバイザ３０２は各仮想マシン３３２に、その仮想マシン３３２が利用可能な物理ハードウェア、メモリ、プロセッサ、及び他のシステムリソースの実質的に同様の仮想ビューを提供してもよい。

各仮想マシン３３２は仮想ディスク３２６Ａ〜Ｃ（総称して３２６）と、仮想プロセッサ３２８Ａ〜Ｃ（総称して３２８）とを含んでもよい。仮想ディスク３２６は、一部の実施形態では、仮想化サーバ３０１の１つまたは複数の物理ディスク３０４、あるいは仮想化サーバ３０１の１つまたは複数の物理ディスク３０４の一部の仮想化ビューである。物理ディスク３０４の仮想化ビューは、ハイパーバイザ３０２によって生成、提供、及び管理することができる。一部の実施形態では、ハイパーバイザ３０２は各仮想マシン３３２に物理ディスク３０４の固有のビューを提供する。このように、これらの実施形態では、各仮想マシン３３２に含まれる特定の仮想ディスク３２６は、他の仮想ディスク３２６と比較した場合に、固有であり得る。

仮想プロセッサ３２８は、仮想化サーバ３０１の１つまたは複数の物理プロセッサ３０８の仮想化ビューとすることができる。一部の実施形態では、物理プロセッサ３０８の仮想化ビューは、ハイパーバイザ３０２によって生成、提供及び管理することができる。一部の実施形態では、仮想プロセッサ３２８は、少なくとも１つの物理プロセッサ３０８と同じ特徴の実質的に全てを有する。他の実施形態では、仮想プロセッサ３０８は、仮想プロセッサ３２８の特徴の少なくとも一部が、対応する物理プロセッサ３０８の特徴と異なるような、物理プロセッサ３０８の修正ビューを提供する。

図４をさらに参照すると、本明細書に記載の一部の態様は、クラウドベースの環境に実装されてもよい。図４に、クラウドコンピューティング環境（またはクラウドシステム）４００の一例を示す。図４に見られるように、クライアントコンピュータ４１１〜４１４はクラウド管理サーバ４１０と通信して、クラウドシステムのコンピューティングリソース（たとえば、ホストサーバ４０３ａ〜４０３ｂ（本明細書では総称して「ホストサーバ４０３」と呼ぶ）、ストレージリソース４０４ａ〜４０４ｂ（本明細書では総称して「ストレージリソース４０４」と呼ぶ）、及びネットワークリソース４０５ａ〜４０５ｂ（本明細書では総称して「ネットワークリソース４０５」と呼ぶ））にアクセスしてもよい。

管理サーバ４１０は１つまたは複数の物理サーバ上に実装されてもよい。管理サーバ４１０は、たとえば、とりわけ、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，Ｆｔ．Ｌａｕｄｅｒｄａｌｅ，ＦＬのＣＬＯＵＤＰＬＡＴＦＯＲＭ、またはＯＰＥＮＳＴＡＣＫを稼動させてもよい。管理サーバ４１０は、たとえば、ホストコンピュータ４０３、データストレージデバイス４０４、及びネットワーキングデバイス４０５などのクラウドハードウェア及びソフトウェアリソースを含む様々なコンピューティングリソースを管理してもよい。クラウドハードウェア及びソフトウェアリソースは、プライベート及び／またはパブリックコンポーネントを含んでもよい。たとえば、クラウドは１つまたは複数の特定の顧客もしくはクライアントコンピュータ４１１〜４１４によって、及び／またはプライベートネットワークを介して使用されるプライベートクラウドとして構成されてもよい。他の実施形態では、パブリッククラウドまたはハイブリッドのパブリック−プライベートクラウドが、他の顧客によって、オープンネットワークまたはハイブリッドネットワークを介して使用されてもよい。

管理サーバ４１０は、クラウドオペレータ及びクラウド顧客がクラウドシステム４００とインタラクトし得るユーザインターフェースを提供するように構成されてもよい。たとえば、管理サーバ４１０は、クラウドオペレータがクラウドリソースを管理し、仮想化レイヤを構成し、顧客アカウントを管理し、他のクラウド管理タスクを行うことを可能にするユーザインターフェースを有する、アプリケーションプログラミングインタフェース（ＡＰＩ）のセット、及び／または１つまたは複数のクラウドオペレータコンソールアプリケーション（たとえば、ウェブベースもしくはスタンドアロンのアプリケーション）を提供してもよい。管理サーバ４１０はまた、クライアントコンピュータ４１１〜４１４を介したエンドユーザからのクラウドコンピューティング要求、たとえば、クラウド内で仮想マシンを作成、修正、または破棄する要求を受信するように構成されるユーザインターフェースを有する、ＡＰＩのセット及び／または１つまたは複数の顧客コンソールアプリケーションを含んでもよい。クライアントコンピュータ４１１〜４１４はインターネットまたは他の何らかの通信ネットワークを介して管理サーバ４１０に接続してもよく、管理サーバ４１０によって管理されるコンピューティングリソースのうちの１つまたは複数へのアクセスを要求してもよい。クライアントの要求に応答して、管理サーバ４１０は、クライアント要求に基づいて、クラウドシステムのハードウェアレイヤ内の物理リソースを選択してプロビジョニングするように構成されるリソースマネージャを含んでもよい。たとえば、管理サーバ４１０及びクラウドシステムの追加のコンポーネントは、クライアントコンピュータ４１１〜４１４の顧客に対して、ネットワーク（たとえば、インターネット）を介して、仮想マシン及びそれらの動作環境（たとえば、ハイパーバイザ、ストレージリソース、ネットワーク要素によって提供されるサービスなど）をプロビジョニングし、作成し、管理し、顧客に計算リソース、データストレージサービス、ネットワーキング能力、ならびにコンピュータプラットフォーム及びアプリケーションサポートを提供するように構成されてもよい。クラウドシステムはまた、セキュリティシステム、開発環境、ユーザインターフェースなどを含む様々な特定のサービスを提供するように構成されてもよい。

特定のクライアント４１１〜４１４は、同じエンドユーザ、または同じ会社もしくは組織に属する異なるユーザのために、仮想マシンを作成する異なるクライアントコンピュータなどに関連付けられてもよい。他の例では、特定のクライアント４１１〜４１４は、異なる会社または組織に属するユーザなど、無関係であってもよい。無関係のクライアントの場合、任意の１人のユーザの仮想マシンまたはストレージに関する情報は、他のユーザから隠されてもよい。

ここでクラウドコンピューティング環境の物理ハードウェアレイヤを参照すると、可用性ゾーン４０１〜４０２（またはゾーン）は、一緒に配置された物理コンピューティングリソースのセットを指す場合がある。コンピューティングリソースのクラウド全体において、ゾーンは他のゾーンとは地理的に離れ得る。たとえば、ゾーン４０１はカリフォルニア州にある第１のクラウドデータセンターであってもよく、ゾーン４０２はフロリダ州にある第２のクラウドデータセンターであってもよい。管理サーバ４１０は可用性ゾーンのうちの１つ、または別の場所に配置されてもよい。各ゾーンは、管理サーバ４１０などのゾーン外のデバイスとゲートウェイ経由でインターフェースする内部ネットワークを含んでもよい。クラウドのエンドユーザ（たとえば、クライアント４１１〜４１４）は、ゾーン間の区別を認識してもよく、しなくてもよい。たとえば、エンドユーザは、指定量のメモリ、処理能力、及びネットワーク能力を有する仮想マシンの作成を要求してもよい。管理サーバ４１０はユーザの要求に応答してもよく、ゾーン４０１またはゾーン４０２のいずれのリソースを使用して仮想マシンが作成されたかどうかをユーザが知ることなく、仮想マシンを作成するためのリソースを割り当ててもよい。他の例では、クラウドシステムは、特定のゾーン内で、またはあるゾーン内の特定のリソース４０３〜４０５上で仮想マシン（または他のクラウドリソース）が割り当てられるように、エンドユーザが要求することを可能にし得る。

この例では、各ゾーン４０１〜４０２は様々な物理ハードウェアコンポーネント（またはコンピューティングリソース）４０３〜４０５、たとえば、物理ホスティングリソース（またはプロセッシングリソース）、物理ネットワークリソース、物理ストレージリソース、スイッチ、及びクラウドコンピューティングサービスを顧客に提供するために使用され得る追加のハードウェアリソースの配置を含んでもよい。クラウドゾーン４０１〜４０２内の物理ホスティングリソースは、上述した仮想化サーバ３０１など、仮想マシンのインスタンスを作成してホストするように構成され得る１つまたは複数のコンピュータサーバ４０３を含んでもよい。クラウドゾーン４０１または４０２内の物理ネットワークリソースは、ファイアウォール、ネットワークアドレス変換器、ロードバランサ、仮想プライベートネットワーク（ＶＰＮ）ゲートウェイ、動的ホスト構成プロトコル（ＤＨＣＰ）ルータなど、クラウド顧客にネットワークサービスを提供するように構成されるハードウェア及び／またはソフトウェアを含む１つまたは複数のネットワーク要素４０５（たとえば、ネットワークサービスプロバイダ）を含んでもよい。クラウドゾーン４０１〜４０２内のストレージリソースは、ストレージディスク（たとえば、ソリッドステートドライブ（ＳＳＤ）、磁気ハードディスクなど）、及び他のストレージデバイスを含んでもよい。

図４に示す例示的なクラウドコンピューティング環境はまた、クラウドの物理リソースを使用して仮想マシンを作成して管理し、他のサービスを顧客に提供するように構成される追加のハードウェア及び／またはソフトウェアリソースを有する仮想化レイヤ（たとえば、図１〜図３に図示）を含んでもよい。仮想化レイヤは、図３で上述したハイパーバイザを、ネットワーク仮想化、ストレージ仮想化などを提供する他のコンポーネントと共に含んでもよい。仮想化レイヤは、物理リソースレイヤとは別のレイヤとしてもよく、または物理リソースレイヤと同じハードウェア及び／またはソフトウェアリソースの一部または全部を共有してもよい。たとえば、仮想化レイヤは、仮想化サーバ４０３のそれぞれにインストールされたハイパーバイザを、物理コンピューティングリソースと共に含んでもよい。あるいは、たとえば、ＷＩＮＤＯＷＳ（登録商標） ＡＺＵＲＥ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ，Ｒｅｄｍｏｎｄ Ｗａｓｈｉｎｇｔｏｎ）、ＡＭＡＺＯＮ ＥＣ２（Ａｍａｚｏｎ．ｃｏｍ Ｉｎｃ．，Ｓｅａｔｔｌｅ，Ｗａｓｈｉｎｇｔｏｎ）、ＩＢＭ ＢＬＵＥ ＣＬＯＵＤ（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ，Ａｒｍｏｎｋ，Ｎｅｗ Ｙｏｒｋ）、またはその他など、知られているクラウドシステムが使用されてもよい。

企業モビリティ管理アーキテクチャ
図５に、「Ｂｒｉｎｇ Ｙｏｕｒ Ｏｗｎ Ｄｅｖｉｃｅ」（ＢＹＯＤ）環境で使用するための企業モビリティ技術アーキテクチャ５００を示す。このアーキテクチャは、モバイルデバイス５０２のユーザがモバイルデバイス５０２から企業リソースまたは個人リソースにアクセスすることと、モバイルデバイス５０２を個人用途に使用することと、の両方を可能にする。ユーザは、ユーザが購入したモバイルデバイス５０２、または企業がユーザに支給したモバイルデバイス５０２を使用して、そのような企業リソース５０４または企業サービス５０８にアクセスしてもよい。ユーザはモバイルデバイス５０２を仕事専用にしてもよく、仕事及び個人兼用にしてもよい。モバイルデバイス５０２は、ｉＯＳオペレーティングシステム、Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステムなどを稼動させてもよい。企業はモバイルデバイス５０２を管理するためのポリシーを実装することを選んでもよい。ポリシーは、モバイルデバイス５０２が識別、セキュア化、もしくはセキュリティ検証がなされ、企業リソース（たとえば、５０４及び５０８）への選択的アクセスもしくはフルアクセスが提供され得るように、ファイアウォールまたはゲートウェイ経由で実装されてもよい。ポリシーは、モバイルデバイス管理ポリシー、モバイルアプリケーション管理ポリシー、モバイルデータ管理ポリシー、またはモバイルデバイス、アプリケーション、及びデータ管理ポリシーのなんらかの組み合わせであってもよい。モバイルデバイス管理ポリシーの適用を通じて管理されるモバイルデバイス５０２を、登録済みデバイスと呼ぶ場合がある。

一部の実施形態では、モバイルデバイス５０２のオペレーティングシステムは、管理対象パーティション５１０と非管理対象パーティション５１２とに分離されてもよい。管理対象パーティション５１０は、管理対象パーティション５１０上で稼動するアプリケーション及びそこに記憶されたデータをセキュア化するためのポリシーが適用されてもよい。管理対象パーティション５１０上で稼動するアプリケーションは、セキュアアプリケーションであってもよい。他の実施形態では、全てのアプリケーションは、アプリケーションとは別に受信する１つまたは複数のポリシーファイルのセットに従って実行されてもよく、これらは、１つまたは複数のセキュリティパラメータ、機能、リソース制約、及び／または、そのアプリケーションがモバイルデバイス５０２上で実行されている場合にモバイルデバイス管理システムによって施行される他のアクセス制御を定義する。それぞれのポリシーファイル（複数可）に従って動作することにより、各アプリケーションは、１つまたは複数の他のアプリケーション及び／またはリソースとの通信が許可または制限されてもよく、それによって仮想パーティションが作成される。このように、本明細書で使用する場合、パーティションとは、メモリの物理的に分割された部分（物理パーティション）、メモリの論理的に分割された部分（論理パーティション）、及び／または、本明細書に記載のように複数のアプリケーションにわたって１つまたは複数のポリシー及び／またはポリシーファイルを施行した結果として作成される仮想的なパーティション（仮想パーティション）を指す場合がある。別の言い方をすれば、管理対象アプリケーションにポリシーを施行することにより、それらのアプリケーションを、他の管理対象アプリケーション及び信頼済みの企業リソースとしか通信できないように制限することによって、非管理対象アプリケーション及びデバイスにはアクセスできない仮想パーティションを作成してもよい。

セキュアアプリケーションは、電子メールアプリケーション、ウェブブラウジングアプリケーション、ソフトウェアアズアサービス（ＳａａＳ）アクセスアプリケーション、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎアクセスアプリケーションなどであってもよい。セキュアアプリケーションは、セキュアネイティブアプリケーション５１４、セキュアアプリケーションランチャ５１８によって実行されるセキュアリモートアプリケーション５２２、セキュアアプリケーションランチャ５１８によって実行される仮想化アプリケーション５２６などであってもよい。セキュアネイティブアプリケーション５１４は、セキュアアプリケーションラッパー５２０によってラッピングされてもよい。セキュアアプリケーションラッパー５２０は、セキュアネイティブアプリケーション５１４がモバイルデバイス５０２上で実行される場合に、モバイルデバイス５０２上で実行される統合されたポリシーを含んでもよい。セキュアアプリケーションラッパー５２０は、モバイルデバイス５０２上で稼動するセキュアネイティブアプリケーション５１４を、セキュアネイティブアプリケーション５１４の実行時に要求されるタスクを完了するためにセキュアネイティブアプリケーション５１４が必要とし得る、企業でホストされるリソース（たとえば、５０４及び５０８）に差し向けるメタデータを含んでもよい。セキュアアプリケーションランチャ５１８によって実行されるセキュアリモートアプリケーション５２２は、セキュアアプリケーションランチャ５１８内で実行されてもよい。セキュアアプリケーションランチャ５１８によって実行される仮想化アプリケーション５２６は、モバイルデバイス５０２上のリソース、企業リソース５０４におけるリソースなどを利用してもよい。セキュアアプリケーションランチャ５１８によって実行される仮想化アプリケーション５２６によってモバイルデバイス５０２上で使用されるリソースは、ユーザインタラクションリソース、プロセッシングリソースなどを含んでもよい。ユーザインタラクションリソースは、キーボード入力、マウス入力、カメラ入力、触覚入力、オーディオ入力、ビジュアル入力、ジェスチャ入力などを収集して伝送するために使用されてもよい。プロセッシングリソースは、ユーザインターフェースを提示し、企業リソース５０４から受信したデータを処理するなどのために使用されてもよい。セキュアアプリケーションランチャ５１８によって実行される仮想化アプリケーション５２６によって企業リソース５０４において使用されるリソースは、ユーザインターフェース生成リソース、プロセッシングリソースなどを含んでもよい。ユーザインターフェース生成リソースは、ユーザインターフェースをアセンブルし、ユーザインターフェースを修正し、ユーザインターフェースをリフレッシュするなどのために使用されてもよい。プロセッシングリソースは、情報を作成し、情報を読み込み、情報を更新し、情報を削除するなどのために使用されてもよい。たとえば、仮想化アプリケーション５２６は、グラフィカルユーザインターフェース（ＧＵＩ）に関連するユーザインタラクションを記録し、それらをサーバアプリケーションに伝達してもよく、サーバアプリケーションは、ユーザインタラクションデータをサーバ上で動作するアプリケーションへの入力として使用することになる。そのような構成では、企業は、アプリケーションに関連するデータ、ファイルなどと同様に、アプリケーションをサーバ側で維持することを選択してもよい。企業は、一部のアプリケーションをセキュア化してモバイルデバイス５０２にデプロイすることにより、それらを本明細書の原理に従って「モバイル化」することを選択してもよいが、この構成は特定のアプリケーションのためにも選択されてもよい。たとえば、一部のアプリケーションはモバイルデバイス５０２で使用するためにセキュア化されてもよいが、その他は、モバイルデバイス５０２にデプロイする準備ができていないかまたはそれに適さない場合があるので、企業は仮想化技術を通じて、準備ができていないアプリケーションへのアクセスをモバイルユーザに提供することを選択してもよい。他の例として、企業は、大規模かつ複雑なデータセットを有する大規模かつ複雑なアプリケーション（たとえば、材料資源計画アプリケーション）を有する場合があり、モバイルデバイス５０２用にアプリケーションをカスタマイズするのは非常に難しく、あるいは望ましくないと思われるので、企業は仮想化技術を通じてアプリケーションへのアクセスを提供することを選択してもよい。さらに他の例として、企業は、セキュア化されたモバイル環境にとっても機密性が高すぎると企業に見なされ得る高セキュア化データ（たとえば、人事データ、顧客データ、技術データ）を維持するアプリケーションを有する場合があり、そのため企業は、そのようなアプリケーション及びデータへのモバイルアクセスを許可するために仮想化技術を使用することを選択してもよい。企業は、完全にセキュア化されかつ完全に機能するアプリケーションをモバイルデバイス５０２上に提供すると共に、仮想化アプリケーション５２６が、サーバ側でより適切に動作すると見なされるアプリケーションへのアクセスを許可することを選択してもよい。一実施形態では、仮想化アプリケーション５２６は、モバイルデバイス５０２の一部のデータ、ファイルなどをセキュアな記憶場所のうちの１つに記憶してもよい。企業は、たとえば、特定の情報をモバイルデバイス５０２に記憶することを許可するが、他の情報は許可しないことを選択してもよい。

本明細書に記載の仮想化アプリケーション５２６に関連して、モバイルデバイス５０２は、ＧＵＩを提示してＧＵＩとのユーザインタラクションを記録するように設計された仮想化アプリケーション５２６を有してもよい。仮想化アプリケーション５２６は、ユーザインタラクションをサーバ側に伝達し、これはサーバ側アプリケーションによって、アプリケーションとのユーザインタラクションとして使用されてもよい。それに応答して、サーバ側のアプリケーションは、モバイルデバイス５０２に新たなＧＵＩを返してもよい。たとえば、新たなＧＵＩは、静的なページ、動的なページ、アニメーションなどであってもよく、それによってリモート配置されたリソースへのアクセスを提供する。

セキュアアプリケーション５１４は、モバイルデバイス５０２の管理対象パーティション５１０内のセキュアデータコンテナ５２８に記憶されたデータにアクセスしてもよい。セキュアデータコンテナ内でセキュア化されたデータは、セキュアネイティブアプリケーション５１４、セキュアアプリケーションランチャ５１８によって実行されるセキュアリモートアプリケーション５２２、セキュアアプリケーションランチャ５１８によって実行される仮想化アプリケーション５２６などによってアクセスされてもよい。セキュアデータコンテナ５２８に記憶されたデータは、ファイル、データベースなどを含んでもよい。セキュアデータコンテナ５２８に記憶されたデータは、特定のセキュアアプリケーション５３０に制限されるデータ、セキュアアプリケーション５３２の間で共有されるデータなどを含んでもよい。あるセキュアアプリケーションに制限されるデータは、セキュア一般データ５３４と、高セキュアデータ５３８とを含んでもよい。セキュア一般データは、高度暗号化標準（ＡＥＳ）１２８ビット暗号化などの強力な暗号化形式を使用してもよく、高セキュアデータ５３８は、ＡＥＳ２５６ビット暗号化などの非常に強力な暗号化形式を使用してもよい。セキュアデータコンテナ５２８に記憶されたデータは、デバイスマネージャ５２４からのコマンドを受信すると、モバイルデバイス５０２から削除されてもよい。セキュアアプリケーション（たとえば、５１４、５２２、及び５２６）は、デュアルモードオプション５４０を有してもよい。デュアルモードオプション５４０は、セキュア化アプリケーションを非セキュア化または非管理モードで動作させるオプションをユーザに提示し得る。非セキュア化または非管理モードでは、セキュアアプリケーションは、モバイルデバイス５０２の非管理対象パーティション５１２の非セキュア化データコンテナ５４２に記憶されたデータにアクセスし得る。非セキュア化データコンテナに記憶されたデータは、個人データ５４４であってもよい。非セキュア化データコンテナ５４２に記憶されたデータはまた、モバイルデバイス５０２の非管理対象パーティション５１２で稼動する非セキュア化アプリケーション５４６によってアクセスされてもよい。セキュアデータコンテナ５２８に記憶されたデータがモバイルデバイス５０２から削除される場合に、非セキュア化データコンテナ５４２に記憶されたデータはモバイルデバイス５０２上に残してもよい。企業は、企業によって所有、ライセンス、または管理される選択されたもしくは全てのデータ、ファイル、及び／またはアプリケーション（企業データ）をモバイルデバイス５０２から削除しつつ、ユーザによって所有、ライセンス、または管理される個人データ、ファイル、及び／またはアプリケーション（個人データ）を残すかまたは別の方法で保存したい場合がある。この動作は選択的ワイプと呼ばれる場合がある。本明細書に記載の態様に従って配置される企業データ及び個人データを用いて、企業は選択的ワイプを行ってもよい。

モバイルデバイス５０２は企業の企業リソース５０４及び企業サービス５０８、公衆インターネット５４８などに接続してもよい。モバイルデバイス５０２は仮想プライベートネットワーク接続を介して企業リソース５０４及び企業サービス５０８に接続してもよい。仮想プライベートネットワーク接続は、マイクロＶＰＮまたはアプリケーション別ＶＰＮとも呼ばれるが、特定のアプリケーション（マイクロＶＰＮ５５０として示す）、特定のデバイス、モバイルデバイス上の特定のセキュア化エリア（Ｏ／Ｓ ＶＰＮ５５２として示す）などに専用のものであってもよい。たとえば、モバイルデバイス５０２のセキュア化エリア内のラッピングされたアプリケーションのそれぞれは、ＶＰＮへのアクセスが、場合によりユーザまたはデバイスの属性情報と共に、アプリケーションに関連する属性に基づいて付与されるように、アプリケーション別ＶＰＮ経由で企業リソースにアクセスしてもよい。仮想プライベートネットワーク接続はＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅトラフィック、Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙトラフィック、ハイパーテキスト転送プロトコル（ＨＴＴＰ）トラフィック、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）トラフィック、アプリケーション管理トラフィックなどを搬送してもよい。仮想プライベートネットワーク接続は、シングルサインオン認証プロセス５５４をサポートし、有効化してもよい。シングルサインオンプロセスは、ユーザが単一セットの認証資格情報を提供できるようにしてもよく、これは後で認証サービス５５８によって検証される。認証サービス５５８は次いで、各個々の企業リソース５０４に認証資格情報を提供するようユーザに求めることなく、複数の企業リソース５０４へのアクセスをユーザに付与し得る。

仮想プライベートネットワーク接続は、アクセスゲートウェイ５６０によって確立され、管理されてもよい。アクセスゲートウェイ５６０は、モバイルデバイス５０２への企業リソース５０４の配信を管理し、高速化し、改善するパフォーマンス向上機能を含んでもよい。アクセスゲートウェイ５６０はまた、モバイルデバイス５０２からのトラフィックを公衆インターネット５４８に経路切替して、モバイルデバイス５０２が公衆インターネット５４８上で稼動する公的に利用可能な非セキュア化アプリケーションにアクセスすることを可能にし得る。モバイルデバイス５０２は、転送ネットワーク５６２を介してアクセスゲートウェイに接続してもよい。転送ネットワーク５６２は１つまたは複数の転送プロトコルを使用してもよく、有線ネットワーク、無線ネットワーク、クラウドネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワーク、ワイドエリアネットワーク、パブリックネットワーク、プライベートネットワークなどであってもよい。

企業リソース５０４は、電子メールサーバ、ファイル共有サーバ、ＳａａＳアプリケーション、ウェブアプリケーションサーバ、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションサーバなどを含んでもよい。電子メールサーバは、Ｅｘｃｈａｎｇｅサーバ、Ｌｏｔｕｓ Ｎｏｔｅｓサーバなどを含んでもよい。ファイル共有サーバは、ＳｈａｒｅＦｉｌｅサーバなどを含んでもよい。ＳａａＳアプリケーションは、Ｓａｌｅｓｆｏｒｃｅなどを含んでもよい。Ｗｉｎｄｏｗｓ（登録商標）アプリケーションサーバは、ローカルなＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムで稼動するように意図されたアプリケーションなどを提供するように構築される任意のアプリケーションサーバを含んでもよい。企業リソース５０４はプレミスベースのリソース、クラウドベースのリソースなどであってもよい。企業リソース５０４はモバイルデバイス５０２によって直接、またはアクセスゲートウェイ５６０経由でアクセスされてもよい。企業リソース５０４はモバイルデバイス５０２によって転送ネットワーク５６２を介してアクセスされてもよい。

企業サービス５０８は、認証サービス５５８、脅威検出サービス５６４、デバイスマネージャサービス５２４、ファイル共有サービス５６８、ポリシーマネージャサービス５７０、ソーシャル統合サービス５７２、アプリケーションコントローラサービス５７４などを含んでもよい。認証サービス５５８は、ユーザ認証サービス、デバイス認証サービス、アプリケーション認証サービス、データ認証サービスなどを含んでもよい。認証サービス５５８は証明書を使用してもよい。証明書は、企業リソース５０４などによって、モバイルデバイス５０２上に記憶してもよい。モバイルデバイス５０２上に記憶された証明書は、モバイルデバイス５０２上の暗号化された場所に記憶されてもよく、証明書は認証時に使用するなどのためにモバイルデバイス５０２に一時的に記憶されてもよい。脅威検出サービス５６４は、侵入検出サービス、不正アクセス試行検出サービスなどを含んでもよい。不正アクセス試行検出サービスは、デバイス、アプリケーション、データなどへの不正なアクセスの試行を含んでもよい。デバイス管理サービス５２４は、構成サービス、プロビジョニングサービス、セキュリティサービス、サポートサービス、監視サービス、報告サービス、及び廃止サービスを含んでもよい。ファイル共有サービス５６８は、ファイル管理サービス、ファイルストレージサービス、ファイルコラボレーションサービスなどを含んでもよい。ポリシーマネージャサービス５７０は、デバイスポリシーマネージャサービス、アプリケーションポリシーマネージャサービス、データポリシーマネージャサービスなどを含んでもよい。ソーシャル統合サービス５７２は、連絡先統合サービス、コラボレーションサービス、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、及びＬｉｎｋｅｄＩｎなどのソーシャルネットワークとの統合などを含んでもよい。アプリケーションコントローラサービス５７４は、管理サービス、プロビジョニングサービス、デプロイメントサービス、割り当てサービス、失効サービス、ラッピングサービスなどを含んでもよい。

企業モビリティ技術アーキテクチャ５００は、アプリケーションストア５７８を含んでもよい。アプリケーションストア５７８は、ラッピングされていないアプリケーション５８０、事前にラッピングされたアプリケーション５８２などを含んでもよい。アプリケーションは、アプリケーションコントローラ５７４からアプリケーションストア５７８に配置されてもよい。アプリケーションストア５７８は、モバイルデバイス５０２によって、アクセスゲートウェイ５６０、公衆インターネット５４８などを経由してアクセスされてもよい。アプリケーションストア５７８には、直観的かつ使いやすいユーザインターフェースが設けられてもよい。

ソフトウェア開発キット５８４は、本明細書で前述したようにアプリケーションをラッピングすることにより、ユーザにより選択されたアプリケーションをセキュア化する機能をユーザに提供してもよい。ソフトウェア開発キット５８４を使用してラッピングされたアプリケーションは次いで、アプリケーションコントローラ５７４を使用してアプリケーションストア５７８内に配置することにより、モバイルデバイス５０２に利用可能にされてもよい。

企業モビリティ技術アーキテクチャ５００は、管理・解析機能５８８を含んでもよい。管理・解析機能５８８は、リソースの使用方法、リソースの使用頻度などに関連する情報を提供してもよい。リソースは、デバイス、アプリケーション、データなどを含んでもよい。リソースの使用方法は、どのデバイスがどのアプリケーションをダウンロードするか、どのアプリケーションがどのデータにアクセスするか、などを含んでもよい。リソースの使用頻度は、アプリケーションがダウンロードされた頻度、特定のデータセットがアプリケーションによってアクセスされた回数などを含んでもよい。

図６は、他の例示的な企業モビリティ管理システム６００である。図５を参照して上述したモビリティ管理システム５００のコンポーネントのうちの一部は、簡単にするために省略している。図６に示すシステム６００のアーキテクチャは、図５を参照して上述したシステム５００のアーキテクチャと多くの点で類似しており、上述していない追加機能を含み得る。

この場合、左手側は、クライアントエージェント６０４を有する登録済みモバイルデバイス６０２を表しており、クライアントエージェント６０４は、ゲートウェイサーバ６０６（これはアクセスゲートウェイ及びアプリケーションコントローラ機能を含む）とインタラクトして、右手側上方に示す様々な企業リソース６０８及びサービス６０９、たとえば、Ｅｘｃｈａｎｇｅ、Ｓｈａｒｅｐｏｉｎｔ、公開鍵基盤（ＰＫＩ）リソース、ケルベロス（Ｋｅｒｂｅｒｏｓ）リソース、証明書発行サービスにアクセスする。具体的には示していないが、モバイルデバイス６０２はまた、アプリケーションの選択及びダウンロードのために企業アプリケーションストア（ＳｔｏｒｅＦｒｏｎｔ）とインタラクトしてもよい。

クライアントエージェント６０４は、高品位ユーザエクスペリエンス（ＨＤＸ）／ＩＣＡディスプレイリモーティングプロトコルを使用してアクセスされる、企業データセンターでホストされるＷｉｎｄｏｗｓ（登録商標）アプリ／デスクトップへの媒介となるＵＩ（ユーザインターフェース）として機能する。クライアントエージェント６０４は、ネイティブｉＯＳまたはＡｎｄｒｏｉｄ（登録商標）アプリケーションなど、モバイルデバイス６０２へのネイティブアプリケーションのインストール及び管理もサポートする。たとえば、上記の図に示す管理対象アプリケーション６１０（メール、ブラウザ、ラッピングされたアプリケーション）は全て、モバイルデバイス６０２上でローカルに実行されるネイティブアプリケーションである。クライアントエージェント６０４及びこのアーキテクチャのアプリケーション管理フレームワークは、企業リソース／サービス６０８との接続性及びＳＳＯ（シングルサインオン）などのポリシー主導の管理機能及び機能を提供するように機能する。クライアントエージェント６０４は、企業への、通常はアクセスゲートウェイ（ＡＧ）６０６への一次ユーザ認証を、他のゲートウェイサーバコンポーネントへのＳＳＯと共に担当する。クライアントエージェント６０４はゲートウェイサーバ６０６からポリシーを取得して、モバイルデバイス６０２上の管理対象アプリケーション６１０の挙動を制御する。

ネイティブアプリケーション６１０とクライアントエージェント６０４との間のセキュアプロセス間通信（ＩＰＣ）リンク６１２は管理チャネルを表し、これによりクライアントエージェントは、ポリシーを供給することが可能になり得、ポリシーは、アプリケーション管理フレームワーク６１４が各アプリケーションを「ラッピング」することによって施行される。ＩＰＣチャネル６１２はまた、クライアントエージェント６０４が、企業リソース６０８との接続性及びＳＳＯを可能にする資格情報及び認証情報を供給することを可能にし得る。最後に、ＩＰＣチャネル６１２は、アプリケーション管理フレームワーク６１４が、クライアントエージェント６０４によって実装されるユーザインターフェース機能、たとえばオンライン及びオフライン認証を呼び出すことを可能にし得る。

クライアントエージェント６０４とゲートウェイサーバ６０６との間の通信は、基本的には、各ネイティブ管理対象アプリケーション６１０をラッピングするアプリケーション管理フレームワーク６１４から管理チャネルを拡張したものである。アプリケーション管理フレームワーク６１４はクライアントエージェント６０４にポリシー情報を要求してもよく、今度はクライアントエージェント６０４がゲートウェイサーバ６０６にポリシー情報を要求してもよい。アプリケーション管理フレームワーク６１４は認証を要求してもよく、クライアントエージェント６０４は、（ＮＥＴＳＣＡＬＥＲ ＡＣＣＥＳＳ ＧＡＴＥＷＡＹとしても知られている）ゲートウェイサーバ６０６のゲートウェイサービス部分にログインしてもよい。クライアントエージェント６０４はまた、ゲートウェイサーバ６０６上のサポートサービスを呼び出してもよく、これは、以下で十分に説明するように、ローカルデータボルト６１６用の暗号化鍵を導出するための入力素材を生成してもよく、またはＰＫＩ保護リソースへの直接認証を可能にし得るクライアント証明書を提供してもよい。

より詳細には、アプリケーション管理フレームワーク６１４は各管理対象アプリケーション６１０を「ラッピング」する。これは明確な構築ステップ、または構築後の処理ステップによって組み込まれてもよい。アプリケーション管理フレームワーク６１４は、アプリケーション６１０の初回起動時にクライアントエージェント６０４と「ペア」を組んで、セキュアＩＰＣチャネル６１２を初期化し、そのアプリケーションのポリシーを取得してもよい。アプリケーション管理フレームワーク６１４は、ローカルに適用されるポリシーの関連部分、たとえば、クライアントエージェントのログイン依存関係、及びローカルＯＳサービスが使用され得る方法、またはそれらが管理対象アプリケーション６１０とインタラクトし得る方法を制限する閉じ込め（ｃｏｎｔａｉｎｍｅｎｔ）ポリシーの一部を施行してもよい。

アプリケーション管理フレームワーク６１４は、セキュアＩＰＣチャネル６１２を介してクライアントエージェント６０４によって提供されるサービスを使用して、認証及び内部ネットワークアクセスを容易にしてもよい。プライベート及び共有データボルト６１６（コンテナ）の鍵管理もまた、管理対象アプリケーション６１０とクライアントエージェント６０４との間の適切なインタラクションによって管理されてもよい。ボルト６１６はオンライン認証後にのみ利用可能になってもよく、またはポリシーによって許可される場合にはオフライン認証後に利用可能になされてもよい。ボルト６１６の最初の使用はオンライン認証を求めてもよく、オフラインアクセスは、最大でも、オンライン認証が再び求められる前のポリシーリフレッシュ期間に制限されてもよい。

内部リソースへのネットワークアクセスは、個々の管理対象アプリケーション６１０からアクセスゲートウェイ６０６を介して直接行われてもよい。アプリケーション管理フレームワーク６１４は、各管理対象アプリケーション６１０の代わりにネットワークアクセスの指揮を担ってもよい。クライアントエージェント６０４は、オンライン認証後に取得される適切な時間制限付きの二次資格情報を提供することにより、これらのネットワーク接続を容易にしてもよい。リバースウェブプロキシ接続及びエンドツーエンドＶＰＮ型トンネル６１８など、複数のネットワーク接続のモードが使用されてもよい。

メール及びブラウザ管理対象アプリケーション６１０は特別なステータスを有し、任意のラッピングされたアプリケーションには一般に利用可能でない場合がある設備を利用してもよい。たとえば、メールアプリケーション６１０は、フルＡＧログオンを必要とせずに長時間にわたってＥｘｃｈａｎｇｅサーバ６０８にアクセスすることを許可する特別なバックグラウンドネットワークアクセスメカニズムを使用してもよい。ブラウザアプリケーション６１０は複数のプライベートデータボルト６１６を使用して、異なる種類のデータを分別してもよい。

このアーキテクチャは、他の様々なセキュリティ機能の組み込みをサポートしてもよい。たとえば、ゲートウェイサーバ６０６（そのゲートウェイサービスを含む）は、一部のケースでは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）パスワードの有効性検証をする必要がなくてもよい。ＡＤパスワードが一部の状況において一部のユーザ用の認証要素として使用されてもよいか否かは、企業の裁量に任せることができる。ユーザがオンラインの場合とオフラインの場合とで（すなわち、ネットワークに接続されている場合と接続されていない場合とで）、異なる認証方法が使用されてもよい。

ステップアップ認証とは、ゲートウェイサーバ６０６が、強力な認証を必要とする極秘データへのアクセスが許可される管理対象ネイティブアプリケーション６１０を識別し、以前の弱いレベルのログイン後にユーザによる再認証が必要になることになっても、これらのアプリケーションへのアクセスが適切な認証を行った後にのみ許可されるようにし得る機能である。

このソリューションの他のセキュリティ機能は、モバイルデバイス６０２上でのデータボルト６１６（コンテナ）の暗号化である。ボルト６１６は、ファイル、データベース、及び構成を含むデバイス上の全データが保護されるように暗号化されてもよい。オンラインボルトの場合、鍵はサーバ（ゲートウェイサーバ６０６）上に記憶されてもよく、オフラインボルトの場合、鍵のローカルコピーがユーザパスワードまたはバイオメトリック認証によって保護されてもよい。データがローカルにモバイルデバイス６０２のセキュアコンテナ６１６に記憶される場合または時に、最低でもＡＥＳ２５６暗号化アルゴリズムが利用されるのが好ましい場合がある。

他のセキュアコンテナ機能も実装されてもよい。たとえば、管理対象アプリケーション６１０内で起こるセキュリティイベントがログ記録されてバックエンドに報告され得るロギング機能が含まれてもよい。データワイプがサポートされてもよく、管理対象アプリケーション６１０が改ざんを検出した場合または時などに、関連する暗号化鍵をランダムデータで上書きして、ユーザデータが破棄されたことの手がかりをファイルシステムに残さないようにしてもよい。スクリーンショットの保護が他の機能であってもよく、アプリケーションはいかなるデータもスクリーンショットに記憶されないようにしてもよい。たとえば、鍵ウインドウの隠しプロパティがＹＥＳに設定されてもよい。これにより、現在スクリーンに表示されているあらゆるコンテンツが隠され得るので、通常は任意のコンテンツが存在するはずのスクリーンショットがブランクになる。

たとえば、データを外部のアプリケーションにコピーするかまたは送るなど、データがアプリケーションコンテナ外にローカルに転送されることを防止することによって、ローカルなデータ転送が防止されてもよい。キーボードキャッシュ機能は、機密性が高いテキストフィールドのオートコレクト機能を無効化するように動作してもよい。ＳＳＬ証明書の有効性検証は、アプリケーションがサーバＳＳＬ証明書を特別に有効性検証し、キーチェーンには記憶しないように動作可能であってもよい。モバイルデバイス６０２上でデータを暗号化するために使用される鍵が、（オフラインアクセスが必要な場合に）ユーザによって供給されるパスフレーズまたはバイオメトリックデータを使用して生成されるような、暗号化鍵生成機能が使用されてもよい。オフラインアクセスが必要でない場合、サーバ側でランダムに生成されて記憶される他の鍵とのＸＯＲがとられてもよい。鍵導出関数は、ユーザパスワードから生成される鍵が、その暗号学的ハッシュを作成するのではなく、ＫＤＦ（鍵導出関数、特にパスワードベースの鍵導出関数２（ＰＢＫＤＦ２））を使用するように動作してもよい。後者では、鍵が総当たり攻撃または辞書攻撃を受けやすくなる。

さらに、暗号化方法において１つまたは複数の初期化ベクトルが使用されてもよい。初期化ベクトルにより、同じ暗号化データの複数のコピーは異なる暗号文出力を生成することになり、リプレイアタック及び暗号解読攻撃の両方が防止される。これにより攻撃者は、盗んだ暗号鍵を用いても、いかなるデータも復号できなくなる。さらに、ユーザがアプリケーション内で認証した後でのみ、アプリケーションデータが復号される、認証後復号が使用されてもよい。他の機能はメモリ内の機密性が高いデータに関するものでもよく、それは必要な場合にのみ、メモリに（ディスクにではなく）保管されてもよい。たとえば、ログイン資格情報はログイン後にメモリからワイプされてもよく、オブジェクティブＣインスタンス変数内の暗号化鍵及び他のデータは、簡単に参照され得るので記憶されない。その代わりに、これらにメモリが手動で割り当てられてもよい。

ポリシーで定義された無活動期間の後に、ユーザセッションが終了される無活動タイムアウトが実装されてもよい。

アプリケーション管理フレームワーク６１４からのデータ漏洩は、他の方法で防止されてもよい。たとえば、管理対象アプリケーション６１０がバックグラウンドになった場合または時に、所定の（設定可能な）期間の後にメモリがクリアされてもよい。バックグラウンド化される場合、アプリケーションの最後に表示された画面のスナップショットをとって、フォアグラウンドのプロセスを固定してもよい。スクリーンショットは機密データを含む場合があるので、クリアされるべきである。

他のセキュリティ機能は、１つまたは複数のアプリケーションにアクセスするために、ＡＤ（Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ）６２２のパスワードを使用せずに、ＯＴＰ（ワンタイムパスワード）６２０を使用することに関するものでもよい。一部のケースでは、一部のユーザは自身のＡＤパスワードを知らず（または知ることを許可されておらず）、そのためこれらユーザはＯＴＰ６２０を使用して、たとえばＳｅｃｕｒＩＤのようなハードウェアＯＴＰシステムを使用して、認証してもよい（ＯＴＰは、ＥｎｔｒｕｓｔやＧｅｍａｌｔｏなど、異なるベンダによって提供されてもよい）。一部のケースでは、ユーザがユーザＩＤで認証した後、ＯＴＰ６２０を有するテキストがユーザに送られてもよい。一部のケースでは、これは、プロンプトが単一フィールドである、オンライン利用の場合にのみ実施されてもよい。

企業ポリシーによってオフライン使用が許可される管理対象アプリケーション６１０については、オフライン認証のためにオフラインパスワードが実装されてもよい。たとえば、企業は、ＳｔｏｒｅＦｒｏｎｔがこの方法でアクセスされることを望む場合がある。この場合、クライアントエージェント６０４は、ユーザにカスタムオフラインパスワードを設定するように求めてもよく、ＡＤパスワードは使用されない。ゲートウェイサーバ６０６は、パスワードの最小長、文字種の組み合わせ、及び有効期限に関するパスワード標準を管理及び施行するポリシーを提供してもよく、たとえば、標準的なＷｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒのパスワードの複雑さの要件によって記述されるものなどであるが、これらの要件は修正されてもよい。

他の機能は、特定のアプリケーション６１０用のクライアント側証明書を二次資格情報として有効化すること（アプリケーション管理フレームワークのマイクロＶＰＮ機能を介してＰＫＩ保護ウェブリソースにアクセスするため）に関するものでもよい。たとえば、管理対象アプリケーション６１０はそのような証明書を利用し得る。この場合、ＡｃｔｉｖｅＳｙｎｃプロトコルを使用した証明書に基づく認証がサポートされてもよく、クライアントエージェント６０４からの証明書はゲートウェイサーバ６０６によって取得され、キーチェーンで使用されてもよい。各管理対象アプリケーション６１０は、ゲートウェイサーバ６０６で定義されるラベルによって識別される１つの関連付けられたクライアント証明書を有してもよい。

ゲートウェイサーバ６０６は、企業専用ウェブサービスとインタラクトして、クライアント証明書の発行をサポートし、関連する管理対象アプリケーションが内部ＰＫＩ保護リソースへ認証することを可能にし得る。

クライアントエージェント６０４及びアプリケーション管理フレームワーク６１４は、内部ＰＫＩ保護ネットワークリソースへの認証のためのクライアント証明書の取得及び使用をサポートするように増強されてもよい。様々なレベルのセキュリティ及び／または分離要件に応じるなどのために、２つ以上の証明書がサポートされてもよい。証明書は、メール及びブラウザ管理対象アプリケーション６１０によって、及び究極的には任意のラッピングされたアプリケーション６１０によって使用されてもよい（ただし、アプリケーション管理フレームワークがＨＴＴＰＳ要求を仲介するのが合理的な、ウェブサービス型の通信パターンをこれらのアプリケーションが使用する場合である）。

ｉＯＳでのアプリケーション管理クライアント証明書サポートは、公開鍵暗号標準（ＰＫＣＳ）１２ＢＬＯＢ（バイナリラージオブジェクト）を各管理対象アプリケーション６１０のｉＯＳキーチェーンに、各使用期間中にインポートすることに依存してもよい。アプリケーション管理フレームワークのクライアント証明書サポートは、プライベートのメモリ内キーストレージを用いたＨＴＴＰＳ実装を使用してもよい。クライアント証明書はｉＯＳキーチェーンに存在しなくてもよく、強力に保護された「オンライン限定の」データ値に存在する場合を除いて、存続させなくてもよい。

相互ＳＳＬまたはＴＬＳも実装して、モバイルデバイス６０２が企業へ認証すること及びその逆を必要とすることにより、追加のセキュリティを提供してもよい。ゲートウェイサーバ６０６への認証用の仮想スマートカードも実装されてもよい。

限定及びフル両方のＫｅｒｂｅｒｏｓサポートが追加機能であってもよい。フルサポート機能は、ＡＤパスワードまたは信頼済みクライアント証明書を使用して、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）６２２へのフルＫｅｒｂｅｒｏｓログインを行い、ＨＴＴＰネゴシエート認証チャレンジに応答するためにＫｅｒｂｅｒｏｓサービスチケットを取得できることに関するものである。限定サポート機能は、Ｃｉｔｒｉｘアクセスゲートウェイエンタープライズエディション（ＡＧＥＥ）での制約付き委任に関するものであり、ＡＧＥＥはＫｅｒｂｅｒｏｓプロトコル移行の呼び出しをサポートするので、ＨＴＴＰネゴシエート認証チャレンジに応答してＫｅｒｂｅｒｏｓサービスチケット（制約付き委任を条件とする）を取得して使用することができる。このメカニズムは、リバースウェブプロキシ（別名、企業仮想プライベートネットワーク（ＣＶＰＮ））モードで、ＨＴＴＰ（ただし、ＨＴＴＰＳではない）接続がＶＰＮ及びマイクロＶＰＮモードでプロキシされる場合に、機能する。

他の機能はアプリケーションコンテナのロック及びワイプに関するものでもよく、これはジェイルブレイクまたはルート化の検出時に自動的に行われ、管理コンソールからプッシュされるコマンドとして行われてもよく、管理対象アプリケーション６１０が稼動していない場合でも、リモートワイプ機能を含んでもよい。

障害時にいくつかの異なる場所のうちの１つからユーザがサービスを受けられるようになる企業アプリケーションストア及びアプリケーションコントローラのマルチサイトアーキテクチャまたは構成がサポートされてもよい。

一部のケースでは、管理対象アプリケーション６１０は、ＡＰＩ（たとえば、ＯｐｅｎＳＳＬ）を介した証明書及び秘密鍵へのアクセスが許可されてもよい。企業の信頼済み管理対象アプリケーション６１０は、アプリケーションのクライアント証明書及び秘密鍵を用いて特定の公開鍵動作を行うことが許可されてもよい。たとえば、アプリケーションがブラウザのように挙動し、証明書アクセスが必要ない場合または時、アプリケーションが「ｗｈｏ ａｍ Ｉ」に関する証明書を読み込んだ場合または時、アプリケーションが証明書を使用してセキュアセッショントークンを構築する場合または時、及びアプリケーションが重要なデータ（たとえば、トランザクションログ）のデジタル署名のため、または一時的なデータ暗号化のために秘密鍵を使用する場合または時など、様々なユースケースが特定され、適宜対処され得る。

スマートカードログインの例示的な実施形態
高速スマートカードログオンは、レイテンシを短縮し、セキュリティを向上させながら、スマートカードを使用してインタラクティブサーバ（たとえば、ＭＩＣＲＯＳＯＦＴ仮想デスクトップインフラストラクチャ（ＶＤＩ）／リモートデスクトップサービス（ＲＤＳ）サーバ）などのサーバに対してユーザまたはクライアントデバイスを認証を行うために使用されてもよい。たとえば、システムは、認証に使用されるサーバデバイスとクライアントデバイスとの間の動作（たとえば、インタラクション）の回数を削減し得る。これらの動作は、スマートカードからユーザ証明書をフェッチすること、またはデータに署名することを含んでもよい。その結果、ＰＣ／ＳＣログオンを遅くするスマートカードネットワークチャター（ｃｈａｔｔｅｒ）が低減され得る。高速スマートカードログオンはまた、任意選択でネットワークを介したＰＩＮ（または他の資格情報）の伝送を回避し、スマートカードを使用した認証イベント（たとえば、セキュアソケットレイヤ（ＳＳＬ）またはトランスポートレイヤセキュリティ（ＴＬＳ）認証）から、ＰＩＮキャッシングに頼ることなく、実際のインタラクティブサーバへのログオンへのシングルサインオンを可能にすることにより、セキュリティを向上させ得る。

図７に、本明細書に記載の１つまたは複数の例示的な態様によるスマートカードログオンのための例示的なシステムを示す。前述のように、図７に示すクライアントデバイス７０１は、同じく図７に示すサーバ７２１とインタラクトして、認証を行い、サーバ７２１がリモートアプリケーションサービスを提供するようにしてもよい。たとえば、クライアントデバイス７０１は、サーバ７２１または他のサーバ上で、リモートで実行されるアプリケーションによって生成されるアプリケーション出力を表示するために使用される仮想マシンプログラムまたはアプリケーションなどのクライアントエージェント７０３を含んでもよい。

クライアントデバイス７０１は、アプリケーションがデータを暗号化するかまたはこれに署名するのを可能にする暗号アプリケーションプログラミングインターフェース７０９（ＣＡＰＩ）と、暗号サービスプロバイダ７１１（ＣＳＰ）と、ミニドライバ７１３と、を含んでもよい。一部の実施形態では、ＣＡＰＩ７０９、ＣＳＰ７１１、及びミニドライバ７１３は、スマートカードログオン中にクライアントデバイス７０１によって使用されなくてもよい。

サーバ７２１は、仮想化エージェント（または仮想エージェント）７２３を含んでもよい。サーバ７２１はまた、資格情報プロバイダ７２５、Ｋｅｒｂｅｒｏｓモジュール７２７、ＣＡＰＩ７２９、ＣＳＰ７３１、及びミニドライバ７３７を含んでもよい。サーバ７２１はこれらのコンポーネントを使用して、クライアントデバイス７０１を認証してもよく、及び／またはクライアントデバイス７０１がデータに署名するようにしてもよい。クライアントデバイス７０１及びサーバ７２１のそれぞれはまた、スマートカードの統合に使用される低レベルのパーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）レイヤ７１５または７３９を含んでもよい。スマートカード７１７は、図７に示すように、クライアントデバイス７０１に物理的に接続されてもよい。クライアントデバイス７０１は、追加的または代替的に、以下にさらに詳細に説明するように、仮想スマートカードを使用してもよい。

一部の態様では、ユーザは、認証のために個人識別番号（ＰＩＮ）または他の資格情報の入力を促されてもよい。クライアントエージェント７０３は、ＰＩＮをキャプチャし、任意選択でＰＩＮを記憶し、サーバ７２１の仮想エージェント７２３にネットワーク接続を介してＰＩＮを送ってもよい。サーバ７２１のＣＡＰＩ７２９は、サードパーティＡＰＩまたはパブリックＡＰＩを含んでもよい。また、スマートカード認証用のドライバはサーバ側にあってもよく、これによりオペレーティングシステム間の互換性を可能にし得る。サーバ側の暗号サービスプロバイダ７３１は、クライアントデバイス７０１から受信したＰＩＮを記憶（たとえば、キャッシュ）してもよい。認証プロセス中に、サーバ７２１は、ＰＣ／ＳＣレイヤ７３９を介してクライアントデバイス７０１にＰＩＮを送り返して、クライアントデバイス７０１のスマートカード７１７から１つまたは複数の証明書などの資格情報を取得するようにしてもよい。ＰＣ／ＳＣレイヤ７１５及び７３９でのスマートカードインタラクションの間に、クライアントデバイス７０１及びサーバ７２１は、数百回、たとえば、約５００回の往復の要求でインタラクトし得る。高速スマートカードログインのための第２の方法は、以下に説明するように、たとえば、１回、２回、または３回のインタラクションなど、スマートカード認証中にクライアントデバイス７０１及びサーバ７２１がインタラクトする回数を低減し得る。

図８に、本明細書に記載の１つまたは複数の例示的な態様による高速スマートカードログオンのための例示的なシステムを示す。高速スマートカードログオンは、ＰＣ／ＳＣレベル８１５及び８３９ではなく、より高い通信レベルでのクライアントデバイス８０１及びサーバ８２１間のインタラクション（たとえば、クライアント証明書によるドメインログオン）を含んでもよい。これにより、クライアントデバイス８０１及びサーバ８２１間のインタラクションの回数、及び／またはクライアントデバイス８０１及びサーバ８２１間で交換されるデータの量（たとえば、ボリューム）が減少し得る。

図７に関して前述したように、クライアントデバイスは、クライアントエージェント８０３、ＣＡＰＩ８０９、ＣＳＰ８１１（たとえば、図８に示すＣＳＰ２）、ミニドライバ８１３、及びＰＣ／ＳＣ８１５を含んでもよい。しかしながら、クライアントデバイスは、サーバのＣＡＰＩ８２９、ＣＳＰ８３１、及びミニドライバ８３７に頼るのではなく、自身のＣＡＰＩ８０９、ＣＳＰ２ ８１１、及びミニドライバ８１３をスマートカード認証に使用してもよい。スマートカード８１７もまた、これはバイオメトリックスマートカード（または他の任意のスマートカード）であってもよいが、クライアントデバイス８０１に物理的に接続されてもよい。スマートカード８１７は、証明書などの資格情報を記憶してもよい。

クライアントエージェント８０３は、仮想エージェント８２３へのディスプレイリモーティング接続を介して、サーバ８２１の仮想エージェント８２３とのネゴシエーションセッションを確立する。ネゴシエーションセッション中に、サーバ８２１（たとえば、サーバ８２１の仮想エージェント８２３）は、従来のスマートカードログオンまたは高速スマートカードログオンのいずれを実行するかを決定してもよい。上記のように、高速スマートカードログオンは、サーバ８２１とクライアントデバイス８０１との間のより少数のインタラクションを必要とし得る。クライアントデバイス８０１及びサーバ８２１は、ネゴシエーションセッション中に互いに自身の機能を知らせてもよい。

仮想エージェント８２３はまた、クライアントエージェント８０３が仮想エージェント８２３に自動ログオン資格情報を提供したか否かを判定してもよい。ブローカリングステップ中に、クライアントデバイス８０１は、他の（たとえば、認証）サーバと認証している場合があり、ユーザはパスワード、ＰＩＮ、バイオメトリクス、または他の資格情報を提供している場合がある。スマートカード８１７は、ブローカリングステップ中に使用されている場合があり、最初のサーバとの認証が成功した場合、スマートカード８１７がロック解除されている場合がある。ブローカリングステップ及びスマートカードロック解除ステップは、クライアントエージェント８０３と仮想エージェント８２３との間のネゴシエーションセッションの前に行われてもよく、またはクライアントエージェント８０３と仮想エージェント８２３との間のネゴシエーションセッション中に行われてもよい。したがって、仮想エージェント８２３は、自動ログオン資格情報がクライアントエージェント８０３によって提供されたと、ネゴシエーションセッション中に判定し得る。一部の態様では、自動ログオン資格情報が提供された場合など、クライアントにおける将来のＰＩＮ（または他の資格情報）プロンプトが有益にブロックされ得る場合、仮想エージェント８２３は、高速スマートカードログオンを使用することを決定してもよい。それ以外の場合、仮想エージェント８２３は、従来のスマートカードログオン（たとえば、ＰＣ／ＳＣレイヤを介したスマートカード認証）を使用することを決定してもよい。

サーバ８２１は、どのログオン方式を使用するかを決定するために１つまたは複数の他の要因を考慮してもよい。たとえば、サーバ８２１は、クライアントデバイス８０１が高速スマートカードログオン（たとえば、スマートカード認証）を使用することを好むことを（たとえば、ネゴシエーションセッション中に）クライアントデバイス８０１が指示している場合、高速スマートカードログオンを使用することを決定してもよい。サーバ８２１はまた、それが高速スマートカードログオンを行うことが可能であるか否かを判定してもよい。一部の態様では、サーバ８２１は、ＰＩＮのユーザプロンプトの回数に基づいて、高速スマートカードログオンを実行するか否かを決定してもよい。たとえば、サーバ８２１は、１回またはより少ない回数のユーザＰＩＮプロンプトが発生する場合（たとえば、ブローカリングステップ中に１回、またはブローカリングステップ及びネゴシエーションステップ中に１回）、高速スマートカードログオンを使用することを決定してもよい。ＰＩＮプロンプトの他の任意の閾値回数が使用されてもよい。それ以外の場合、サーバ８２１は、高速スマートカードログオン方式を使用しないことを決定してもよい。

ユーザがＰＩＮまたは他の資格情報（たとえば、バイオメトリック）を提供した後、クライアントデバイス８０１のＣＳＰ８１１は、ＰＩＮ、バイオメトリック、または他の資格情報を記憶（たとえば、キャッシュ）するか、または別の方法でスマートカードをロック解除されたままにして、クライアントデバイス８０１がさらに使用できるようにしてもよい。ＣＳＰ２ ８１１にＰＩＮまたはバイオメトリックを記憶することにより、図７に示すように、サーバ８２１のＣＳＰ８３１がスマートカード８１７と通信して証明書を取得するのではなく、クライアントデバイス８０１がスマートカード８１７と直接通信して、セキュリティ証明書を取得し得る。したがって、ＰＩＮまたはバイオメトリックは、セキュア化されているかまたはされていない場合があるネットワークを介してクライアントデバイス８０１とサーバ８２１との間で（時には複数回）伝送されるのではなく、クライアントデバイス８０１上に残り得る。代替的な実施形態では、クライアントエージェント８０３は、ＰＩＮまたはバイオメトリックをサーバ８２１に送ってもよい。サーバ８２１は、以下にさらに詳細に説明するように、ＣＳＰ８３３などにＰＩＮまたはバイオメトリックを記憶してもよい。バイオメトリクス（たとえば、指紋）の例では、指紋または他のバイオメトリクスに使用されるデータが多いので、スマートカード認証は（他のスマートカード認証方式と比べて）大幅に高速化され得る。

クライアントデバイス８０１はまた、スマートカード８１７を用いるなどして証明書動作を処理するように構成される秘密鍵動作（ＰＫ動作）ＳＤＫモジュール８０７を含んでもよい。ＰＫ動作ＳＤＫ８０７の機能は、同時係属中の米国非仮特許出願第１３／８８６，８４５号に記載されており、その全体が引用により本明細書に組み込まれている。具体的には、クライアントデバイス８０１のＰＫ動作ＳＤＫモジュール８０７は、鍵ストアへのアクセスを容易にし得て、この鍵ストアは、認証用の署名に使用され得る対応する秘密鍵と共に、１つまたは複数のクライアント証明書を記憶する。たとえば、クライアントデバイス８０１は、クライアントデバイス８０１のユーザを表すクライアント証明書へのアクセスを許可してもよく、またはそれを所持してもよい。一部の態様では、証明書は、企業が発行した証明書であってもよい。証明書は、暗号モジュールを有する物理スマートカードにバインドされてもよい。換言すれば、暗号秘密は、スマートカードにとどめられてもよい。ユーザはクライアントデバイス８０１がスマートカードで保護された証明書にアクセスすることを許可してもよい。

代替的には、証明書は派生資格情報（たとえば、仮想スマートカード）にバインドされてもよく、これはハードウェア及び／またはソフトウェアモジュールを使用して鍵を保護してもよい。派生資格情報内の証明書は、クライアントデバイス８０１に記憶されてもよく、物理スマートカード８１７上の証明書と同様にアクセスされてもよい。派生資格情報からの証明書は、クライアントデバイス８０１における信頼済みの環境に記憶されてもよい。

クライアントデバイス８０１及び／またはクライアントデバイスの取り外し可能なハードウェアモジュールは、証明書及び秘密鍵を記憶することを、プロビジョニングプロセスによって許可されてもよい。クライアント証明書の秘密鍵を必要とする動作を許可するために、ユーザは、クライアントデバイス８０１を使用してＰＩＮまたは他の資格情報（たとえば、バイオメトリック）を入力するように要求され得る。クライアントデバイス８０１（たとえば、スマートフォン）とは別の他の外部デバイスが証明書を管理してもよく、クライアントデバイス８０１は、カスタムリーダインターフェースを利用して、外部デバイスによって管理される証明書にアクセスしてもよい。

ここでサーバ８２１に着目すると、サーバ８２１は、図７に関して上記に前述したように、仮想エージェント８２３及びＣＡＰＩ８２９を含んでもよい。サーバ８２１はＣＳＰ８３１を含んでもよいが、ＣＳＰ８３１をスマートカード認証に利用しなくてもよい。むしろ、クライアント側ＣＳＰ８１１が代わりに利用されてもよい。サーバ８２１はまた、スマートカードログオンを開始するように構成される資格情報プロバイダ８２５（または資格情報プロバイダフィルタ）を含む１つまたは複数の資格情報プロバイダを含んでもよい。仮想エージェント８２３は、高速スマートカードログオンに使用する資格情報プロバイダ、たとえば、資格情報プロバイダ８２５を選択してもよい。Ｋｅｒｂｅｒｏｓ認証が利用される場合、資格情報プロバイダ８２５は、以下の例でさらに詳細に説明するように、信頼済みのサードパーティデバイス８２７（たとえば、Ｋｅｒｂｅｒｏｓモジュール）と通信してもよい。

サーバ８２１は、暗号サービスプロバイダＣＳＰ８３１、及び／または（任意選択で）図示していないキーストレージプロバイダ（ＫＳＰ）を含んでもよい。換言すれば、ＣＳＰ８３１は、ＫＳＰに置き換えられてもよい。ＫＳＰは、ＣＳＰ８３１によってサポートされていない場合がある代替的なスマートカードのアルゴリズムをサポートするために使用されてもよい。同様に、クライアントデバイス８０１のＣＳＰ８１１は、ＫＳＰに置き換えられてもよい。ＣＳＰ（及び／またはＫＳＰ）は、証明書動作をインターセプトするように構成されてもよい。資格情報プロバイダ８２５は、高速スマートカードログオンに使用するＣＳＰ、たとえばＣＳＰ８３１を選択してもよい。サーバ８２１のＣＳＰ８３１（及び／またはＫＳＰ）は、リモーティングチャネル８３６を介してクライアントデバイス８０１のＰＫ動作ＳＤＫ８０７と通信してもよい。たとえば、クライアントデバイス８０１とサーバ８２１との間の仮想チャネル８３６は、クライアントデバイス８０１の仮想チャネルドライバ８０５と、サーバ８２１の仮想チャネルドライバ８３５とによって確立されてもよい。

クライアントデバイス８０１を使用する動作、たとえば、スマートカード８１７からの証明書の要求、またはデータ署名の要求などは、サーバ８２１のＣＳＰ８３１（及び／またはＫＳＰ）からクライアントデバイス８０１のＰＫ動作ＳＤＫ８０７に（たとえば、仮想チャネル８３６を介して）送られてもよい。より高いレベルで（たとえば、ＰＣ／ＳＣトンネル８３８ではなく仮想チャネル８３６を介して）通信することにより、図８に示すサーバ及びクライアントデバイスのペアは、図７に示すサーバ及びクライアントデバイスのペアよりも少ない回数で、及び／または少ない情報を相互に通信し、それによって潜在的なレイテンシが短縮され得る。

サーバ８２１はまた、クライアントデバイス８０１（またはスマートカード８１７）との通信を必要としないサーバ側の認証動作のための、サードパーティＣＳＰなどのＣＳＰ８３３を含んでもよい。前述のように、サーバ８２１はまた、ミニドライバ８３７及びＰＣ／ＳＣフック８３９を含んでもよい。一部の態様では、ミニドライバ８３７及びＰＣ／ＳＣ８３９は、クライアントデバイスの認証に使用されなくてもよい。他の態様では、ＰＣ／ＳＣ８３９は、他の仮想チャネル８３８を介してクライアントデバイス８０１のＰＣ／ＳＣ８１５と通信してもよい。

ここで、Ｋｅｒｂｅｒｏｓによるスマートカード８１７を使用した認証のための一般的な動作についてさらに詳細に説明する。サーバの資格情報プロバイダ８２５は、ＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体を使用して、スマートカードクラスユーザ証明書を用いたＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙログオンなどのログオンをトリガしてもよい。サーバの資格情報プロバイダ８２５はＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体を使用してもよい。ＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体は、次のように構成されてもよい。

さらに、ＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体に記述されているように、「ＣｓｐＤａｔａ」は、ＫＥＲＢ＿ＳＭＡＲＴＣＡＲＤ＿ＣＳＰ＿ＩＮＦＯ構造体へのポインタをコンプロマイズし得る。ＫＥＲＢ＿ＳＭＡＲＴＣＡＲＤ＿ＣＳＰ＿ＩＮＦＯ構造体は、次のように構成されてもよい。

この構造体は、サーバの資格情報プロバイダ８２５によって生成されてもよい。特に、この構造体は、ＣＳＰ８３１及び／またはＫＳＰの名前などを識別してもよい。

引用により本明細書に組み込まれている米国特許出願第１３／８８６，８４５号にさらに詳細に説明されているように、Ｋｅｒｂｅｒｏｓリソース認証は、ＫｅｒｂｅｒｏｓのＫＤＣ（たとえば、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙドメインコントローラ）からサービスチケットを取得することを必要としてもよい。たとえば、サーバ８２１におけるＫｅｒｂｅｒｏｓ認証パッケージは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙログオンを実行するために、コメント要求（ＲＦＣ）４５５６に記載されたようなＫｅｒｂｅｒｏｓにおける初期認証用公開鍵暗号（ＰＫＩＮＩＴ）プロトコルを使用してもよい。

サーバの資格情報プロバイダ８２５、Ｋｅｒｂｅｒｏｓモジュール８２７、またはスマートカードを使用する他のアプリケーションによる情報の処理中に、サーバ８２１側のＣＳＰ８３１及び／またはＫＳＰは、資格情報プロバイダ８２５及びＫｅｒｂｅｒｏｓモジュール８２７によって行われる関連する証明書動作をインターセプトし、それらの動作をクライアントデバイス８０１（たとえば、クライアントデバイス８０１のＰＫ動作ＳＤＫ８０７）にリモーティングしてもよい。たとえば、ＣＳＰ８３１及び／またはＫＳＰが証明書要求またはデータ署名動作を検出した場合、ＣＳＰ８３１及び／またはＫＳＰは、認証データをパッケージ化し、証明書及び／または署名の要求をクライアントデバイス８０１に送ってもよい。それ以外の場合、クライアント情報を使用しない動作は一般に、クライアントデバイス８０１に関与せずに、（たとえば、サードパーティＣＳＰ８３３を介して）サーバ８２１で行われてもよく、それによって、クライアントデバイス８０１及びサーバ８２１の間で交換されるデータの量と、クライアントデバイス８０１及びサーバ８２１がインタラクトする回数とを減少し得る。クライアントデバイス８０１にリモーティングされる例示的な動作には、スマートカード８１７上の証明書をリスト化（たとえば、列挙）する要求、証明書の要求、スマートカード８１７の秘密鍵を使用した署名動作、及びスマートカード８１７の秘密鍵を使用した復号動作が含まれるが、これらに限定されない。クライアントデバイス８０１に送られなくてもよい（たとえば、リモーティングされなくてもよい）例示的な動作（たとえば、サードパーティＣＳＰ８３３によって、あるいはサーバ８２１で行われてもよい）には、コンテキスト及びハンドル管理、パラメータ収集及びハンドリング、乱数生成、対称鍵生成及び導出、バルク暗号化及び復号、メッセージダイジェストを生成するためのデータのハッシング、セッション鍵のラッピング、署名検証、及び他の特定の動作が含まれるが、これらに限定されない。

ＣＳＰ８３１及び／またはＫＳＰはまた、クライアント８０１がデータに署名するかもしくはこれを復号するために、またはクライアント８０１に関与する他の任意の動作のために、証明書の要求と共にクライアントデバイス８０１にＰＫＩＮＩＴコンテキスト情報などのコンテキスト情報を供給してもよい。コンテキスト情報の供給については、米国特許出願第１３／８８６，８４５号にさらに詳細に説明されており、その全体が引用により本明細書に組み込まれている。コンテキスト情報を供給することにより、（仮想チャネルドライバ８０５及び８３５を介して確立された）サーバ８２１とクライアントデバイス８０１との間のリモーティングチャネル８３６の誤用から保護され得る。

ここで、例示的な署名動作について説明する。Ｋｅｒｂｅｒｏｓモジュール８２７は、ログオン中にＣＳＰ８３１の呼び出しを行って、たとえば、クライアントデバイスの署名が望まれていることを示してもよい。たとえば、米国特許出願第１３／８８６，８４５号にさらに詳細に説明されているように、Ｋｅｒｂｅｒｏｓモジュール８２７は、ＰＫＩＮＩＴ中に署名すべきＡｕｔｈＰａｃｋに署名する呼び出しを行ってもよい。

スマートカード８１７の秘密鍵は、クライアントデバイス８０１によってＡｕｔｈＰａｃｋ構造に署名するために使用されてもよい。署名は、ＲＦＣ５６５２に記載されている暗号メッセージ構文（ＣＭＳ）を使用して行われてもよい。特に、ＲＦＣ５６５２に記載されているように、ＡｕｔｈＰａｃｋはＳｉｇｎｅｄＤａｔａエンベロープ内に配置されてもよい。したがって、署名動作はＣＳＰレベルで認識可能であり得、その理由は、ハッシュ関数呼び出しに渡される生データが、整形された（ｗｅｌｌ−ｆｏｒｍｅｄ）ＡＳＮ．１構造を有し得るためであり、これはＲＦＣ４５５６及び５６５２で定義されており、また、米国特許出願第１３／８８６，８４５号でさらに詳細に議論されており、その議論は引用により本明細書に組み込まれている。一部の態様では、クライアントデバイス８０１にリモーティングされる動作（たとえば、署名及び復号）は、プロトコルコンテキスト（たとえば、ＡＳＮ．１または他の認識可能な構造）を示さなくてもよい。したがって、これらの動作は、これらの動作を生じさせるプロトコルコンテキストの証明を提供することなく、提供され得る。

上記で説明したように、クライアントデバイス８０１は、認証プロセス中にサーバ８２１から１つまたは複数の要求を受信してもよい。クライアントデバイス８０１上のプロセスは、１つまたは複数のプロセス間通信（ＩＰＣ）メカニズムを介して通信してもよい。また、各プロセスは他のどのプロセスが最初のプロセスを呼び出しているかを特定してもよく、これを使用して、認証中の余分なＰＩＮプロンプト（または他の資格情報プロンプト）を防ぐか否かを決定してもよい。あるプロセスが既にスマートカード８１７をロック解除している場合、１つまたは複数のその後のＰＩＮプロンプトをブロックして、ユーザが再度ＰＩＮを提供する必要がないようにしてもよい。しかしながら、どのプロセスもスマートカード８１７を使用していない場合、ユーザはＰＩＮの入力を促されてもよい。クライアントエージェント８０３は、論理的には（ユーザの観点から）１つのアプリケーションで構成されていても良いが、複数のプロセスで構成されてもよい。それらのプロセスの１つは、ブローカリング中の以前の認証のために、スマートカードの使用を許可される場合があり（また、その他は許可されない場合があり）、そのため、クライアントデバイス８０１は、これらの追加のスマートカード動作を、クライアントエージェントのログオンステップから最初のプロセスに戻るように経路指定して、これ以上のＰＩＮプロンプトを回避してもよい。

一方、さらなるＰＩＮプロンプトが一部の状況で発生する場合がある。クライアントデバイス８０１が再びユーザにユーザのＰＩＮ（または他の資格情報）の入力を促すか否かは、どのプロセスがスマートカードのＰＩＮを呼び出しているかに依存してもよい。一部の態様では、ユーザが、スマートカードを使用したい各アプリケーションを許可してもよい。これは、ロック解除されたスマートカードが、ＰＩＮプロンプトを発生させてユーザ許可を取得した最初のプロセスとは目的が異なり得る他のプロセスには必ずしも使用可能ではなくなるように、オペレーティングシステム及びＣＳＰによって実装されてもよい。一部のケースでは、スマートカード自体が、ＰＩＮプロンプトを強制する内部ポリシーを有してもよい。

一部の態様では、前述の認証方法は、ＣＳＰ（たとえば、ＣＳＰ８３１）及び／またはＫＳＰ上で実装されてもよい。ＣＳＰまたはＫＳＰが使用される場合、ハッシュ関数が使用されなくてもよい。一般に、ＣＳＰ関数の多くは、ＣｐＳｉｇｎＨａｓｈ及びＣｐＤｅｃｒｙｐｔなどのクライアントデバイス８０１を使用する動作以外は、標準的なＣＳＰ（たとえば、サードパーティＣＳＰ８３３）に委任され得る。一部の実施形態では、Ｋｅｒｂｅｒｏｓモジュール８２７がユーザ証明書もフェッチしてＡＳ−ＲＥＱパケットに入れる場合、Ｋｅｒｂｅｒｏｓモジュール８２７は、ＣｒｙｐｔＧｅｔＫｅｙＰａｒａｍを呼び出してユーザ証明書を読み込んでもよい。それに応じて、ＣｒｙｐｔＧｅｔＫｅｙＰａｒａｍは、クライアントデバイス８０１にユーザ証明書を要求するようにＣＳＰ８３１をトリガしてもよい。

クライアントデバイス８０１にリモーティングされる動作（たとえば、１つ、２つ、３つ、または４つの動作）を行った後、Ｋｅｒｂｅｒｏｓシステム８２７は、ドメインコントローラへのその認証を完了させて、基本的なオペレーティングシステムのログオンを完了してもよい。

サーバ８２１は、スマートカードの取り外しポリシーをサポートしてもよい。一部の態様では、クライアント側のＰＣ／ＳＣ８１５とサーバ側のＰＣ／ＳＣ８３９との間に他の仮想チャネル８３８が存在してもよい。サーバ８２１は、この仮想チャネル８３８を使用してスマートカードレイヤを見ることができるので、スマートカード８１７が取り外されたときを特定することができる。この例では、資格情報プロバイダ８２５は、正しいスマートカードリーダ名がＫＥＲＢ＿ＳＭＡＲＴＣＡＲＤ＿ＣＳＰ＿ＩＮＦＯなどのデータフィールドにリストされていることを確認して、それがＰＣ／ＳＣ仮想チャネル８３８によって公開されている情報と一致するようにしてもよい。他の態様では、ＰＣ／ＳＣ仮想チャネル８３８は、使用されなくてもよい。その代わりに、サーバ８２１が、サーバ側のＣＳＰ８３１とクライアント側のＰＫ動作８０７との間の仮想チャネル８３６を使用して、スマートカード８１７のステータスを特定してもよい。たとえば、クライアントデバイス８０１がスマートカード８１７のステータスを特定してもよく、ステータスはＰＫ動作８０７によって仮想チャネル８３６を介してＣＳＰ８３１に送られてもよい。サーバ８２１は、スマートカード８１７のステータスをエミュレートする仮想スマートカードリーダ（図示せず）を生成して記憶してもよい。サーバ８２１は、サーバ８２１における仮想スマートカードリーダのステータスを特定することによって、スマートカード８１７のステータスを特定してもよい。サーバ８２１は、スマートカードが取り外されたと判定した後に、様々なアクションを実行してもよい。たとえば、サーバ８２１は、ユーザが自身のアクセス端末から離れた場合に、セッションをロックして、それをセキュアなままにしてもよい。これにより、ユーザは自身のカードを携行する以外に何もする必要がなくなり得る。

図９に、本明細書に記載の１つまたは複数の例示的な態様による高速スマートカードログオンのための他の例示的なシステムを示す。図９に示すシステムは、図８に示すシステムの拡張を含み、補助的なサードパーティ（たとえば、ベンダー）ＣＳＰ関数をサポートしてもよい。図８に示すコンポーネントに加えて、図９の例におけるサーバ８２１は、サードパーティＣＳＰであるＣＳＰ９３２を含んでもよい。一部の態様では、ＣＳＰ９３２は図７に示すＣＳＰ７３１であってもよい。両方のＣＳＰはユーザのＰＩＮまたはバイオメトリックを記憶してもよい。この例では、クライアントデバイス８０１は、ＰＩＮ（または他の資格情報）をサーバ８２１に送ってもよい。ＰＩＮ（または他の資格情報）は、たとえば、Ｄｉｆｆｉｅ−Ｈｅｌｍａｎなどの、クライアントデバイス８０１とサーバ８２１との間の鍵ネゴシエーションにより、伝送中に保護されてもよい。鍵ネゴシエーションは、ＴＬＳなどの任意の下位レベルの転送セキュリティメカニズムに加えて、ＰＫ動作の仮想チャネル内で行われてもよい。ＰＩＮ（または他の資格情報）を受信すると、ＣＳＰ９３２はＰＩＮを記憶（たとえば、キャッシュ）してもよい。ＰＩＮを記憶することにより、ＣＳＰ９３２は、ログオン後のアプリケーション使用（たとえば、インタラクティブサーバセッションで稼動中のアプリケーション及び／または他の同様の機能のためのもの）のために、スマートカード８１７をロック解除してもよい。仮想セッション内の例示的なアプリケーションには、ウェブブラウザ、生産性ソフトウェア、電子メールクライアントなどが含まれてもよい。また、ＣＳＰ９３２はログオン中に直接使用されていない場合があるので、ＣＳＰ９３２へのＰＩＮの記憶は、ログオンパフォーマンス（たとえば、速度、レイテンシ、セキュリティなど）にほとんどまたは全く影響を与えない場合がある。ＣＳＰ９３２へのＰＩＮの記憶は、インタラクティブサーバセッションで稼動するアプリケーションへのシングルサインオンに使用されてもよい。たとえば、アプリケーションは、ＣＳＰ９３２からＰＩＮに直接アクセスして、ユーザをサインオンさせてもよい。

一部の実施形態では、インタラクティブサーバセッションで稼動するアプリケーション、たとえば、ウェブブラウザ、文書への署名を利用するアプリケーション、または他のアプリケーションは、ログオンのためにスマートカード資格情報にアクセスしてもよい。本明細書に記載の動作は、スマートカード資格情報にアクセスするアプリケーションのために使用されてもよい。これらの例では、サーバ側のＫｅｒｂｅｒｏｓコンポーネント８２７は、スマートカードへのアクセスを要求するアプリケーションに置き換えられてもよく、スマートカード資格情報にアクセスするための動作は上記のように行われてもよい。また、仮想チャネル８３６を使用して得られたユーザ証明書は、ユーザセッション用の証明書ストア、たとえば、ＷＩＮＤＯＷＳ（登録商標）または他のＯＳの証明書ストアに伝達されてもよい。ＯＳはこの動作を通常のスマートカードログオンのために、ＰＣ／ＳＣのＡＰＩを使用するバックグラウンドプロセスとして実行してもよい。それに応じて、証明書は、カード用の通常のＣＳＰ（たとえば、図９に示すＣＳＰ９３２）ではなく、ＣＳＰ８３１にリンクされてもよい。

サーバ側のＫｅｒｂｅｒｏｓコンポーネント８２７が、スマートカードへのアクセスを要求するアプリケーションに置き換えられる場合、ＣＳＰ８３１（及びＰＫ動作ＳＤＫ、ならびに他のコンポーネント）は、アプリケーションごとのユーザ許可が所望されるならば、サーバ側の異なるアプリケーション間を区別し得る。異なるサーバ側アプリケーションがカードの使用を試みる場合があるので、ＰＩＮプロンプトが自動的に行われない場合があり、秘密鍵動作は、既に許可されているクライアント側のプロセスに戻り得る。そのため、ＣＳＰ８３１は、サーバ８２１によって使用されるＰＩＮプロンプトポリシーを示してもよく、それにより秘密鍵動作はクライアント８０１によって実行され得る。一部のケースでは、これは、サーバ側のＣＡＰＩ８２９によりサポートされるスマートカード動作の概念を公開して、クライアント８０１上のＣＡＰＩ８０９に動作をミラーリングできるようにすることによって行われ得る。

一部の実施形態では、スマートカードはまだロック解除されていない場合があり、インタラクティブなＰＩＮプロンプトが使用されてもよい。これらの実施形態では、ＰＩＮプロンプトは、クライアント８０１ではなく、サーバ８２１によって処理されてもよい。サーバ８２１上でのＰＩＮの収集は、クライアント８０１上でのＰＩＮの収集よりも安全でない場合がある。しかしながら、この場合にはサーバでの実装がより容易であり得、その理由は、コアセキュリティシステム（たとえば、ＷＩＮＤＯＷＳ（登録商標）上のＬＳＡ）が、ユーザの入力を待つ際に、本来ブロックされ得るときに、ブロックされない場合があるためである。上述のような（ＰＣ／ＳＣではなく）ＰＫ動作のリモーティングの速度上の利益は、これらの実施形態において存在し得る。簡単な例として、このモードは、スマートカードの取り外しによってロックがかかったが、セッションは切断されなかった場合に、リモートセッションをロック解除するために使用されてもよい。ユーザがスマートカードを再挿入した場合、スマートカードの挿入が（たとえば、ＰＣ／ＳＣまたはＰＫ動作の仮想チャネルを介して）信号伝達されてもよく、ユーザはＰＩＮを入力してカードをロック解除するように促されてもよい。

図１０に、本明細書に記載の１つまたは複数の例示的な態様による高速スマートカードログオンのためのさらに他の例示的なシステムを示す。クライアントデバイス１００１は、前述のように、クライアントエージェント１００３を含んでもよい。クライアントデバイス１００１は、１つまたは複数の仮想チャネル１００５を介してサーバ１０２１と通信してもよい。クライアントデバイス１００１はまた、認証マネージャ１００８を含んでもよく、これは、図８を参照して前述したクライアントデバイスのＣＡＰＩ、ＣＳＰ２、及び／またはミニドライバモジュールのうちの１つまたは複数を含んでもよい。認証マネージャ１００８は、図７及び図８に示す（そして前述した）ＰＫ動作ＳＤＫを実装するクライアントエージェント１００３内のモジュールであってもよい。クライアントデバイスのオペレーティングシステムに応じて、認証マネージャ１００８は、オペレーティングシステム提供のＣＡＰＩを使用してもよく、独自のＣＡＰＩを含んでもよい。認証マネージャ１００８は、スマートカード１０１７及び／またはシングルサインオンデバイス１０１９、たとえば、セキュアなＰＩＮキャッシングサービス及び／またはデバイスと通信してもよい。認証マネージャ１００８は、認証中にユーザによって提供されたＰＩＮまたは他の資格情報を記憶してもよい。高速スマートカードログオンは、クライアントデバイス１００１が認証マネージャと通信して新たな認証向けのスマートカード証明書サービスにアクセスするための新たなＩＰＣチャネルに依存してもよい。

サーバ１０２１はブローカーエージェントサービス１０３５を含んでもよく、これはクライアントデバイス１００１とサーバ１０２１との間の仮想チャネル１００５とインターフェースしてもよい。たとえば、ブローカーエージェントサービス１０３５は、図８に示す仮想チャネルドライバ８３５を含んでもよい。ブローカーエージェントサービス１０３５は、認証を容易にし得る。サーバ１０２１は、図８を参照して前述したように、暗号サービスプロバイダＣＳＰ１０３１及び資格情報プロバイダ１０２５（たとえば、証明書資格情報プロバイダ）を含んでもよい。サーバ１０２１はまた、資格情報プロバイダマネージャ１０２４を含んでもよく、これは前述の仮想エージェント８２３を含んでもよい。資格情報プロバイダマネージャ１０２４は、認証のためにスマートカードログイン（たとえば、図７に示す実施形態）または高速スマートカードログイン（たとえば、図８に示す実施形態）のいずれを使用するかを決定するために使用されてもよい。

ここで、図１０に示すコンポーネントによって実施され得る認証ステップについて説明する。まず、クライアントデバイス１００１とサーバ１０２１との間の仮想チャネル１００５が確立されてもよい。クライアントデバイス１００１は、たとえばクライアントエージェント１００３を介して、サーバ１０２１と、たとえば資格情報プロバイダマネージャ１０２４を介してネゴシエートして、使用する資格情報プロバイダ１０２５を決定してもよい。一部の例では、サーバ１０２１は、複数の資格情報プロバイダ１０２５を有してもよく、及び／または、そうでなければ、複数の資格情報プロバイダとインタラクトしてもよい。また、クライアントエージェント１００３は、資格情報プロバイダマネージャ１０２４とネゴシエートして、スマートカードログインまたは高速スマートカードログインのいずれを使用するかを決定してもよい。クライアントエージェント１００３は、クライアントデバイス１００１がスマートカードまたは他の資格情報を使用した認証を希望していることをサーバ１０２１に通知してもよい。

高速スマートカードログオンを使用（たとえば、有効化）すべきことをサーバ１０２１の資格情報プロバイダマネージャ１０２４が検出した場合、資格情報プロバイダ１０２５がトリガされてもよい。換言すれば、資格情報プロバイダマネージャ１０２４は、特定の資格情報プロバイダ１０２５にスマートカードログイン手順を実行するように通知してもよい。このトリガは、ＣＳＰ１０３１で見つかった証明書を使用して認証するようにドメインログオンプロセス（たとえば、ＷｉｎＬｏｇｏｎ．ｅｘｅ）に通知してもよい。ＣＳＰ１０３１は、証明書の取得及び署名動作などのクライアントデバイス１００１に関与する動作をクライアント１００１に指示しつつ、サーバ１０２１上でローカルに他の暗号関数を実行してもよい。図８を参照して前述したように、資格情報プロバイダ１０２５は、認証のためにＫｅｒｂｅｒｏｓモジュールと通信してもよい。資格情報プロバイダ１０２５とＫｅｒｂｅｒｏｓモジュールとの間での動作中に、ＣＳＰ１０３１は、証明書動作及び／または署名動作（またはクライアントデバイス１００１に記憶された情報を使用する他の動作）を実行するために呼び出されてもよい。ＣＳＰ１０３１は、所望のクライアントまたはユーザ情報を取得するために、サーバ側のブローカーエージェントサービス１０３５及びクライアント側の仮想チャネル１００５を介して、クライアントデバイス１００１の認証マネージャ１００８と通信してもよい。

クライアントデバイス１００１が情報の要求を受信した後、証明書の選択及びＰＩＮの要求を含むユーザインターフェースのインタラクションは、クライアントデバイス１００１上の認証マネージャサービス１００８によって処理されてもよい。スマートカードログオンが有効化されている場合、既存のスマートカードの仮想チャネル（たとえば、ＰＣ／ＳＣ）ではなく、（前述のような）仮想チャネルが使用されてもよい。一部の態様では、クライアントデバイス１００１は、サーバ１０２１によって要求された動作を実行するために、（たとえば、証明書の選択、ＰＩＮまたはバイオメトリックの入力などのために）インタラクティブにユーザに入力を促してもよい。たとえば、ユーザインタラクションステップは、資格情報プロバイダがトリガされる前に、クライアントエージェント接続中の初期に行われてもよい。

以下の動作またはコマンドは、スマートカードログインまたは高速スマートカードログインの間で選択するために使用されてもよい。

ログオンシーケンスにおけるステップは、クライアントデバイス１００１上の認証マネージャサービス１００８によって制御されてもよく、これは、グラフィカルユーザインターフェース（ＧＵＩ）を介して情報を入力するようにユーザに促すか否かを決定してもよい。起動時に、クライアントエージェント１００３は仮想チャネルをロードしてもよく、これは高速スマートカード仮想チャネルを有効化するか否かの決定に進み得る。ＰＯＬＩＣＹ＿ＶＩＲＴＵＡＬ＿ＣＨＡＮＮＥＬ＿ＤＩＳＡＢＬＥＤが偽であり、ＩＣＡＦＩＬＥ＿ＤＩＳＡＢＬＥ＿ＣＴＲＬ＿ＡＬＴ＿ＤＥＬが真であり、認証マネージャサービスのＩｓＣｅｒｔｉｆｉＣＡｔｅＬｏｇｏｎＥｎａｂｌｅｄ（）が真である場合に、高速スマートカード仮想チャネルが有効化されてもよい。ＰＯＬＩＣＹ＿ＶＩＲＴＵＡＬ＿ＣＨＡＮＮＥＬ＿ＤＩＳＡＢＬＥＤが偽であり、スマートカードデバイスが検出された場合に、ＩｓＣｅｒｔｉｆｉＣＡｔｅＬｏｇｏｎＥｎａｂｌｅｄ（）は真になり得る。

サーバ１０２１の資格情報プロバイダマネージャ１０２４はまた、アクティブ化ステップを実行してもよい。たとえば、ＩＣＡＦＩＬＥ＿ＤＩＳＡＢＬＥ＿ＣＴＲＬ＿ＡＬＴ＿ＤＥＬが真である場合、資格情報プロバイダマネージャ１０２４は、スマートカードログオンを試みてもよい。この時点で、資格情報プロバイダマネージャ１０２４は、ＰＯＬＩＣＹ＿ＶＩＲＴＵＡＬ＿ＣＨＡＮＮＥＬ＿ＤＩＳＡＢＬＥＤが偽であり、仮想チャネルがクライアントデバイス１００１によって有効化されており、資格情報プロバイダマネージャ１０２４が仮想チャネルのＧｅｔＣｅｒｔｉｆｉＣＡｔｅ（）の呼び出しを介して（たとえば、クライアントデバイス１００１が証明書を取得するため）ログオン証明書を取得することができる場合に、高速スマートカード認証仮想チャネルの使用を試みてもよい。それ以外の場合、（高速スマートカードログオンではなく、スマートカードログオンを有効化するために）既存のスマートカード仮想チャネルがアクティブ化されてもよい。

クライアントデバイスコンポーネントは、ＧｅｔＣｅｒｔｉｆｉＣＡｔｅ（）の呼び出しに応答してもよい。仮想チャネルが有効化されていたと仮定すると、ＧｅｔＣｅｒｔｉｆｉＣＡｔｅ（）要求は、サーバ１０２１からクライアントデバイスの認証マネージャサービス１００８に直接渡されてもよい。認証マネージャサービス１００８は、ＰＯＬＩＣＹ＿ＶＩＲＴＵＡＬ＿ＣＨＡＮＮＥＬ＿ＤＩＳＡＢＬＥＤが偽であり、スマートカードデバイスが存在し、証明書が適切なフォーマットを有する（たとえば、証明書のタイプについてのポリシーを満たす）ことを検証した後、サーバ１０２１に証明書を返してもよい。必要であれば、スマートカードが検出されなかった場合、及び／または適切なフォーマットの複数の利用可能な証明書が存在する場合、認証マネージャサービス１００８は、ユーザにスマートカード１０１７を挿入するか、または証明書を選択するように促してもよい。

サーバ１０２１の資格情報プロバイダ１０２５及びＣＳＰ１０３１は、様々なステップを実行してもよい。資格情報プロバイダマネージャ１０２４は、証明書を受信した場合、資格情報プロバイダ１０２５を起動し、暗号学的にランダムなＣＳＰアクセスチケットを資格情報プロバイダ１０２５に送ってもよい。ＣＳＰ１０３１は、ブローカーエージェントサービス１０３５のローカル認証サービスによって提供される証明書機能を使用してインタラクティブログオンを行ってもよい。たとえば、ローカル認証サービス１０３５は、ＳｉｇｎＨａｓｈ（）または他の動作を実行するために仮想チャネルを使用する前に、ＣＳＰの呼び出し元がアクセスチケットを知っていたことを検証してもよい。

クライアントデバイスコンポーネントは、ＳｉｇｎＨａｓｈ（）動作に応答してもよい。仮想チャネルが有効化されていたと仮定すると、ＳｉｇｎＨａｓｈ（）要求が、クライアントデバイス１００１の認証マネージャサービス１００８に直接渡されてもよい。ＰＯＬＩＣＹ＿ＶＩＲＴＵＡＬ＿ＣＨＡＮＮＥＬ＿ＤＩＳＡＢＬＥＤが偽であり、証明書がユーザによって選択されたものであり、ＰＩＮがシングルサインオンサービスから入手可能であるか、もしくは（たとえば、ユーザが他のサービスに認証したときの以前のステップからの）以前のスマートカードセッションが存在する場合、またはスマートカード１０１７のロック解除に使用される正しいＰＩＮまたは他の資格情報、たとえば、指紋や他のバイオメトリックなどをユーザが供給した場合、認証マネージャサービス１００８は、ハッシュに署名してもよい。

高速スマートカードは、１つまたは複数のオペレーティングシステムと統合（たとえば、完全に統合）されてもよく、期待されるエンドユーザエクスペリエンスを提供し得る。高速スマートカードログオンをオペレーティングシステムと統合することにより、スマートカードがローカルに（たとえば、リモートセッションプロトコルなしで）使用されたシナリオと同じまたは同様のエンドユーザエクスペリエンスがもたらされ得る。たとえば、１つまたは複数のリソースにアクセスするために、クライアントデバイス上の実行可能プログラムまたは他のプログラム（たとえば、ＷＩＮＤＯＷＳ（登録商標）のＬｏｇｏｎＵＩ）を使用して、スマートカードＰＩＮまたは他のスマートカード資格情報を入力するようにユーザに促してもよい。本明細書に記載の態様は、ユーザが、たとえばログオンユーザインターフェースプログラム（ＬｏｇｏｎＵＩなど）を介して、スマートカードＰＩＮまたは他の資格情報をオペレーティングシステムに提供することにより、インタラクティブにリモートセッションにログオンすることを可能にし得る。本明細書に記載の態様は、ユーザが、たとえばログオンユーザインターフェースプログラムを介して、ユーザのスマートカード資格情報をオペレーティングシステムに提供することにより、リモートセッションをロック解除することを可能にし得る。したがって、ユーザは、リモートセッションをロック時に切断し、次いでシングルサインオンを使用して再接続する必要がなくなり得る。本明細書に記載の態様は、様々なＰＣ／ＳＣ関数、たとえば、ＰＣ／ＳＣのＳＣＡｒｄＬｉｓｔＣＡｒｄｓ関数、ＰＣ／ＳＣのＳＣＡｒｄＧｅｔＣＡｒｄＴｙｐｅＰｒｏｖｉｄｅｒＮａｍｅ関数、または他の関数の呼び出しなどを介して、スマートカードに関連付けられたＣＳＰを発見するためにリソースマネージャへの標準クエリを使用し得るセッション内アプリケーションを使用することを可能にし得る。

一部の態様では、１つ（または複数）の代用スマートカードを使用して、高速スマートカードを１つまたは複数のオペレーティングシステム、たとえば、ＷＩＮＤＯＷＳ（登録商標）、ＬＩＮＵＸなどと統合してもよい。代用スマートカードは現実のスマートカード（たとえば、現実の物理スマートカード）でなくてもよい。その代わりに、代用スマートカードは、サーバの１つまたは複数のサーバ側コンポーネント、たとえば、図８及び図９に示すサーバ８２１、図１０に示すサーバ１０２１、または本明細書に記載の他の任意のサーバの１つまたは複数のコンポーネントなどによって生成されてもよく、及び／またはそれらに知られていてもよい。前述のように、クライアントデバイス８０１は、リモートセッションプロトコルを介してサーバ８２１に接続されてもよい。

１つまたは複数の代用スマートカードは、代用スマートカードタイプ識別子によって識別されてもよい。代用スマートカードタイプ識別子は、たとえば、代用スマートカードのスマートカードタイプを示してもよい。代用スマートカードの代用スマートカードタイプ識別子は、たとえば、リセット応答（ＡＴＲ）メッセージまたはファイルに含まれてもよい。代用スマートカードのＡＴＲは、現実のスマートカードと同様に、スマートカードのタイプを一意に識別するデータのシーケンス（たとえば、バイトのシーケンス）を含んでもよく、これはＩＳＯ７８１６仕様に従って定義されてもよい。サーバは、ＩＳＯ７８１６フォーマットに従って１つ（または複数）の代用スマートカードＡＴＲを作成してもよい。一部の態様では、サーバは、仮想マシンのインストールなどのインストール時に、代用スマートカードと、それに関連付けられる代用スマートカード識別子とを作成する。

生成された代用スマートカード識別子（たとえば、ＡＴＲ）は、ＣＳＰ（たとえば、高速スマートカードＣＳＰ）に関連付けられてもよく、ＣＳＰは一部のシナリオでは暗号動作に使用されてもよい。代用スマートカード識別子とＣＳＰとの間の関連付けは、サーバ側コンピュータ（たとえば、サーバ８２１）に記憶されてもよい。たとえば、サーバはデータベースを含んでもよく、識別子（たとえば、ＡＴＲ）とＣＳＰとの間の関連付けは、サーバのデータベースに追加されてもよい。ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムの場合、代用スマートカード識別子と、対応するＣＳＰ（たとえば、高速スマートカードＣＳＰ）との間の関連付けは、ＰＣ／ＳＣリソースマネージャデータベースに追加されてもよい。たとえば、関連付けはＷＩＮＤＯＷＳ（登録商標）レジストリに追加されてもよい。

図１６Ａに、本明細書に記載の１つまたは複数の例示的な態様による例示的なスマートカードのデータベースを示す。データベース（たとえば、スマートカードリソースマネージャデータベース）は、レジストリであってもよく、複数のスマートカード１６０５に関する情報を含んでもよい。たとえば、スマートカードの１つは、リモートスマートカード１６１０を含んでもよく、これはサーバ側で生成及び記憶される代用スマートカードであってもよい。リモートスマートカード１６１０の対応するファイル１６１２は、リモートスマートカード１６１０に関する情報、たとえば、スマートカード識別子１６１５（たとえば、ＡＴＲ）、及びＣＳＰ１６２０を識別する情報を含んでもよい。スマートカード識別子１６１５及びＣＳＰ１６２０を識別する情報は、同じファイル（たとえば、リモートスマートカードファイル）に記憶されてもよい。図示のように、リモートスマートカード１６１０は、１６進値（たとえば、３ｂ １ｆ ｄ９ ４３ ６９ ７４ ７２ ６９ ７８ ５３ ６ｄ ６１ ７２ ７４ ４３ ６１ ７２ ６４ ９６）を持つＡＴＲを有してもよい。２進値またはＡＳＣＩＩ値などの他のタイプの値を使用して、ＡＴＲを表現してもよい。ＣＳＰ１６２０を識別する情報は、ＣＩＴＲＩＸスマートカード暗号プロバイダなどのＣＳＰの名前（またはＣＳＰへの他のポインタ）を含んでもよい。この名前は、ＣＳＰ（たとえば、ダイナミックリンクライブラリ（ＤＬＬ）データ）のパスを示す、データベース内の場所を指してもよい。

図１６Ｂに、本明細書に記載の１つまたは複数の例示的な態様による例示的なスマートカードのデータベースを示す。前述のように、ＣＳＰ１６２０を識別する情報は、ＣＩＴＲＩＸスマートカード暗号プロバイダなどのＣＳＰの名前を含んでもよい。ＣＳＰの名前は、データベース内の場所１６２５を指してもよい。場所１６２５は、ＣＳＰの場所を指すデータ１６３０などのデータを含んでもよい。たとえば、ＣＳＰファイル（たとえば、ＤＬＬ）をロードする（たとえば、動的にロードする）ためのパスは、Ｃ：￥Ｐｒｏｇｒａｍ Ｆｉｌｅｓ￥Ｃｉｔｒｉｘ￥Ｓｙｓｔｅｍ３２￥ＣｔｘＳｍａｒｔＣＡｒｄＣＳＰ６４．ｄｌｌであってもよい。これらの例では、データベースは、スマートカード識別子（たとえば、ＡＴＲ）を適切なＣＳＰに関連付けてもよい。

図１６Ａを参照すると、他のスマートカード１６０５または他のタイプのスマートカードは、スマートカード１６１０と同じまたは類似の情報を含んでもよい。たとえば、異なるタイプのスマートカードはそれぞれ、異なるスマートカード識別子を有してもよい。同じタイプのスマートカードは、同じスマートカード識別子（たとえば、ＡＴＲ）を使用してもよい。結果的に、同じタイプのスマートカードは同じＣＳＰを使用してもよい。たとえば、同じタイプの一部のスマートカードは、同じ識別子（たとえば、ＡＴＲ）と、同じＣＳＰ識別子（たとえば、ＣＳＰ名またはＣＳＰの他のポインタ）とを記憶する対応するファイルを有してもよい。

一部の態様では、複数の代用ＡＴＲまたは他の識別子が使用されてもよい。たとえば、クライアントデバイスが複数のスマートカードを同時に（または異なる時間に）使用してもよく、それらのスマートカードは異なるタイプのスマートカードを含んでもよい。異なるタイプのスマートカードが、単一の代替ＡＴＲ（または他の識別子）に関連付けられてもよく、したがって、同じＣＳＰ（たとえば、図８に示すＣＳＰ８３１）を使用してもよい。しかしながら、クライアント側で異なるＣＳＰが使用されてもよい。たとえば、クライアントデバイス８０１は、あるタイプのスマートカードに対処するためのＣＳＰ８１１と、他のタイプのスマートカードに対処するための他のＣＳＰ（図８には図示せず）とを含んでもよい。クライアントデバイス８０１は、どのＣＳＰを使用するかを知っていてもよい。サーバ８２１からクライアントデバイス８０１への暗号動作要求があるたびに、要求内のフィールドは、クライアント側で使用するＣＳＰ（たとえば、ＣＳＰ８１１または他のＣＳＰ）の名前を含んでもよい。

追加的または代替的には、異なるタイプのスマートカードはそれぞれ、異なる代替ＡＴＲ（または他の識別子）に関連付けられてもよく、したがって、サーバ側で異なるＣＳＰを使用してもよい。たとえば、図８に示すＣＳＰ８３１は、あるタイプのスマートカードに使用されてもよく、サーバ側の他のＣＳＰ（図８には図示せず）は、他のタイプのスマートカードに使用されてもよい。異なるタイプのスマートカード用の異なるＣＳＰは、ダブルアップシナリオで、たとえば、関与するクライアント８０１からサーバ８２１へ、そしてサーバ８２１から他のサーバ（図８には図示せず）への認証などで使用されてもよい。他のサーバは、高速スマートカード機能を使用しない場合があり、ＡＴＲを現実のスマートカード８１７に代替し戻すために、現実のスマートカード８１７のスマートカードタイプを知る必要がある場合がある。

本明細書に記載の１つまたは複数の例は、暗号動作の高速スマートカードリダイレクトと、一部の（たとえば、初期）ＰＣ／ＳＣ関数のＰＣ／ＳＣリダイレクトとを使用する。図８を参照すると、サーバ８２１は、ログオンユーザインターフェースアプリケーションを含んでもよい。たとえば、そのアプリケーションはＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムのＬｏｇｏｎＵＩであってもよい。サーバ８２１は、そのアプリケーションを介して、クライアントデバイス８０１が１つまたは複数のスマートカードリーダを含むかあるいはそれに接続されているか否かを判定してもよい。そのアプリケーションは、ＰＣ／ＳＣ要求を介して、たとえば、サーバ８２１のＰＣ／ＳＣフック８３９を介して、スマートカードリーダ（複数可）を発見してもよい。発見要求は、サーバ８２１の暗号ＡＰＩ８２９をバイパスしてもよい。ＰＣ／ＳＣフック８３９は仮想チャネルドライバ８３５及び／または仮想チャネルドライバ８０５を介してクライアント８０１のＰＣ／ＳＣ８１５に要求を伝達してもよく、要求はＰＣ／ＳＣレベルで送られてもよい。クライアント側のＰＣ／ＳＣ８１５は、ＰＣ／ＳＣレイヤを介して、クライアントデバイス８０１が１つまたは複数のスマートカードリーダを有することの指示を返してもよい。

サーバ８２１は、ＷＩＮＤＯＷＳ（登録商標）のＬｏｇｏｎＵＩなどのアプリケーションを介して、たとえば、スマートカードが存在するか否か（たとえば、カードが挿入されているか否か）を確認するために、リーダ（複数可）のステータスの要求をスマートカードリーダ（複数可）に送ってもよい。ステータス要求は、ＰＣ／ＳＣフック８３９の直接呼び出しなど、ＰＣ／ＳＣレベルで送信されてもよい。ステータス要求は暗号ＡＰＩ８２９をバイパスしてもよい。ＰＣ／ＳＣフック８３９は、仮想チャネルドライバ８３５及び／または仮想チャネルドライバ８０５を介してＰＣ／ＳＣ８１５に要求を伝達してもよく、要求はＰＣ／ＳＣレベルで送られてもよい。クライアント側のＰＣ／ＳＣ８１５は、ＰＣ／ＳＣレイヤを介して、スマートカードがリーダに挿入されているか否かの指示を返してもよい。

スマートカード（たとえば、スマートカード８１７）が識別された場合、クライアントデバイス８０１は、ＰＣ／ＳＣ８１５を介して、スマートカード８１７に関連する情報、たとえば、スマートカード８１７の一意の識別子、またはスマートカードのタイプを（たとえば、ＡＴＲファイルとして）取得してもよい。スマートカードのＡＴＲ（または他の識別子）は、たとえば、ＳＣＡｒｄＧｅｔＳｔａｔｕｓＣｈａｎｇｅのＰＣ／ＳＣ関数によってスマートカード８１７から取得されてもよい。クライアントデバイス８０１は、仮想チャネルドライバ８０５及び／または仮想チャネルドライバ８３５を介してサーバ８２１に応答を送信してもよい。応答はＰＣ／ＳＣレベルで送信されてもよい。応答は、スマートカードのＡＴＲ（または他の識別子）を含んでもよい。

サーバ８２１は、仮想チャネルドライバ８３５を介して、スマートカードの一意の識別子（たとえば、ＡＴＲ）を含む応答を受信してもよい。前述のように、サーバ８２１は、たとえばプロトコルネゴシエーションを介して、高速スマートカードリダイレクトが有効化されているか否かを知ってもよい。高速スマートカードが有効化されている場合、サーバ８２１のＰＣ／ＳＣリダイレクトレイヤ（たとえば、スマートカードサービス）は、スマートカード８１７のＡＴＲを代用スマートカードのＡＴＲに代替してもよい。現実のスマートカードのＡＴＲの代用スマートカードのＡＴＲへの代替は、ＰＣ／ＳＣリダイレクトレイヤによって、クライアントからサーバへの方向、及び／またはサーバからクライアントへの方向に、オンザフライで実行されてもよい。代替されたＡＴＲを含むスマートカード８１７に関連する情報は、ＰＣ／ＳＣフック８３９に送られてもよい。サーバ８２１のログオンユーザインターフェースは、ＰＣ／ＳＣフック８３９を介して代替されたＡＴＲを含む情報を取得してもよい。

代替されたＡＴＲに基づいて、サーバ８２１のログオンユーザインターフェースは、暗号動作に使用するＣＳＰを決定してもよい。たとえば、ログオンユーザインターフェースは、リソースデータベースに照会して、データベース内の任意のエントリがＡＴＲまたはその一部を含むか否か、及び／または任意のエントリがＡＴＲを特定のＣＳＰに関連付けているか否かを判定してもよい。例示的なデータベースを図１６Ａ及び図１６Ｂに示す。

図１６Ａを参照して、たとえば、代替されたＡＴＲが３ｂ １ｆ ｄ９ ４３ ６９ ７４ ７２ ６９ ７８ ５３ ６ｄ ６１ ７２ ７４ ４３ ６１ ７２ ６４ ９６の１６進数値を含むと仮定する。サーバ８２１は、ログオンユーザインターフェースを介して、対応する（たとえば、一致する）ＡＴＲ（たとえば、３ｂ １ｆ ｄ９ ４３ ６９ ７４ ７２ ６９ ７８ ５３ ６ｄ ６１ ７２ ７４ ４３ ６１ ７２ ６４ ９６の１６進数値を有するもの）をデータベースで検索してもよい。サーバ８２１はＡＴＲ１６１５を見つけ、それが代替されたＡＴＲに対応すると判定してもよい。

サーバ８２１がＡＴＲ１６１５を識別した後、サーバ８２１はそのＡＴＲに対応するスマートカードの名前を取得することを試みてもよい。たとえば、スマートカード名を取得するためにＳＣＡｒｄＬｉｓｔＣＡｒｄｓのＰＣ／ＳＣ関数が呼び出されてもよい。この例では、取得されるスマートカード名は、リモートスマートカード１６１０であってもよい。

サーバ８２１がスマートカード名（たとえば、リモートスマートカード１６１０）を取得した後、サーバ８２１は、データベース（たとえば、レジストリ）に照会するなどして、スマートカードに関連付けられたＣＳＰを特定してもよい。たとえば、ＳＣＡｒｄＧｅｔＣＡｒｄＴｙｐｅＰｒｏｖｉｄｅｒＮａｍｅのＰＣ／ＳＣ関数を呼び出して、ＣＳＰを特定してもよい。この例では、取得されるＣＳＰ名は、スマートカード暗号プロバイダ１６２０であってもよく、スマートカード暗号プロバイダ１６２０は、たとえば、図８及び図９に示すＣＳＰ８３１を識別してもよい。それに応じて、サーバ８２１は、ログオンユーザインターフェースアプリケーションを介して、ＣＳＰ１６２０とＡＴＲ１６１５との間の関連付けを発見してもよい。サーバ８２１はＣＳＰをロードし、クライアントにおけるスマートカード（たとえば、スマートカード８１７）を必要とする暗号動作にＣＳＰを使用してもよい。ＣＳＰ８３１などの高速スマートカードＣＳＰを使用する様々な例は、前述している。また、暗号ＡＰＩ８２９を使用して、ＣＳＰ８３１にアクセスしてもよい。ＣＳＰ名を指定するＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔ関数を使用して、高速スマートカードメカニズムと連携する暗号動作を実行してもよい。

前述のように、スマートカード８１７を必要とする１つまたは複数の動作は、ＰＣ／ＳＣレイヤよりも上位のレイヤで仮想チャネル８３６を介してクライアントデバイス８０１にリダイレクトされてもよい。一部の態様では、システムは、ＰＣ／ＳＣレイヤではなく、より上位のレイヤにできるだけ多くの動作をリダイレクトすることを試みてもよい。前述のように、（たとえば、リモートセッションプロトコルを介して）クライアントデバイス８０１にリモーティングされ得る例示的な暗号動作には、スマートカード８１７上の証明書をリスト化する要求、証明書の要求、スマートカード８１７の秘密鍵を使用した署名動作、及びスマートカード８１７の秘密鍵を使用した復号動作が含まれるが、これらに限定されない。高速スマートカードログオンを使用することにより、たとえば長いレイテンシが存在する場合に、より高速なパフォーマンスが提供され得る。

ＣＳＰ８３１は、高速スマートカードログオン暗号動作に使用されてもよく、ＣＳＰ８３１は、仮想チャネルドライバ８３５（及び／またはクライアントデバイス８０１の対応する仮想チャネルドライバ８０５）を介してクライアントデバイス８０１と通信してもよい。クライアントデバイスの暗号ＡＰＩ８０９は、ＣＳＰ８１１と通信して、スマートカード８１７を使用した暗号動作を完了してもよい。

ＰＣ／ＳＣレイヤよりも上位のレイヤで通信することにより、いくつかの技術的な利益がもたらされ得る。たとえば、ＰＣ／ＳＣはチャッティ（ｃｈａｔｔｙ）なプロトコルであり得、スマートカードから証明書（複数可）を取得すると、（たとえば、ＳＣＡｒｄＴｒａｎｓｍｉｔのＰＣ／ＳＣ関数を介して）何百もの同期ＰＣ／ＳＣ要求／応答に変換され得る。ネットワークのレイテンシが長い（たとえば、１５０ミリ秒以上である）場合、リモートスマートカードの使用は、エンドユーザにとって遅すぎて、パフォーマンスが低下し得る。たとえば、場合によっては１回の動作で何百もの要求／応答のレイテンシが合計されるので、暗号動作は実行に長い時間がかかり得る。スマートカードの動作をより上位のレイヤにリダイレクトすることにより、スマートカードを使用した認証または他の動作の速度が向上し得る。

暗号動作中に、資格情報を受信するためのユーザインターフェースが、クライアントデバイス８０１に関連付けられたディスプレイに表示されてもよい。図１７に、本明細書に記載の１つまたは複数の例示的な態様による例示的なユーザインターフェース１７００を示す。ユーザインターフェース１７００は、たとえば、ユーザ名及び／またはサインインオプション、たとえば、パスワードを使用するか、スマートカードを使用するかなどを表示してもよい。ユーザは、スマートカードを使用して認証するオプション１７１０を選択してもよく、ＰＩＮなどのスマートカードに関連付けられた資格情報を入力してもよい。ユーザがＰＩＮまたは他の資格情報を提供すると、資格情報は暗号化され、ユーザの認証に使用され得る。前述のように、ＰＩＮ（または他の資格情報）は記憶されてもよく、記憶されたＰＩＮ（または他の資格情報）を使用して、ログオン後にアプリケーションで使用するためにスマートカード８１７をロック解除してもよい。クライアントデバイス８０１は、スマートカード８１７を使用してドメインコントローラへ認証されてもよい。

図８を参照すると、（たとえば、ＬｏｇｏｎＵＩアプリケーションを介して）ＰＩＮ（または他の資格情報）がＵＩから取得され、サーバ側のＣＳＰ（たとえば、図８に示すＣＳＰ８３１及び／またはＣＳＰ８３３）に提供されてもよい。前述のように、ＰＩＮはクライアント側のエージェントに送られてもよく、ＰＩＮは仮想チャネル８３６を介して搬送されてもよい。公開／秘密鍵ペアまたは他の任意の非対称暗号を使用して、ＰＩＮを保護してもよい。クライアントエージェント８０３は、たとえば起動時に、公開／秘密鍵ペアをオンザフライで生成してもよい。鍵ペアはメモリに記憶されてもよく、高速スマートカードが有効化されている場合に実行されてもよい。スマートカード仮想チャネルがネゴシエーションを終えた後（たとえば、高速スマートカードが有効化されている場合）、生成された公開鍵はサーバ側に送られてもよい。ＣＳＰ８３１は次いで、受信した公開鍵を取得してもよい。スマートカードのＰＩＮ（または他の資格情報）をクライアント側に送る場合、ＣＳＰ８３１はＰＩＮを公開鍵で暗号化してもよい。ＰＩＮは、暗号化された状態で仮想チャネル８３６を介して、及び／または仮想チャネルドライバ８０５に送り返されてもよい。仮想チャネルドライバ８０５及び／またはクライアントエージェント８０３は、メモリに記憶された秘密鍵でＰＩＮを復号してもよい。仮想チャネルドライバ８０５及び／またはクライアントエージェント８０３は次いで、ＣＳＰ８１１を介して、ＰＩＮを使用する１つまたは複数の暗号動作を実行してもよい。これにより、ＣＳＰ８３１から仮想チャネルドライバ８０５及び／またはクライアントエージェント８０３までのＰＩＮの保護が可能になり得、これは、ＰＩＮ（または他のスマートカード資格情報）を使用するＣＳＰ８１１を用いて１つまたは複数の暗号動作を実行してもよい。

フェデレーテッドログオンの例示的な実施形態
前述の高速スマートカードログオンを実装するために使用されるコンポーネントはまた、フェデレーテッドフルドメイン（たとえば、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ））ログオンを実装するために使用されてもよい。フルドメインログオン後、セッションはフルネットワーク資格情報（たとえば、Ｋｅｒｂｅｒｏｓチケット付与チケット（ＴＧＴ）及びチャレンジ／応答パスワードハッシュ（たとえば、ＮＴＬＭパスワードハッシュ））を有し得る。たとえば、ユーザは、ＳＡＭＬ許可トークンを提供することにより、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙユーザアカウントとして、仮想デスクトップセッション、物理ＰＣ、またはリモートデスクトップサーバセッションへ認証してもよい。以下の例でさらに詳細に説明するように、ユーザは、適切な任意のタイプの資格情報及び／または認証プロトコルを使用して、外部コンポーネント／サービス／デバイス、たとえば、アイデンティティプロバイダ（ＩｄＰ）へ認証してもよい。この認証は、外部認証イベントと呼ばれる場合がある。例示的な外部認証イベントには、セキュリティアサーションマークアップ言語（ＳＡＭＬ）アイデンティティプロバイダにおけるログオン、ＴＬＳまたはＳＳＬを介したスマートカード認証、及びＡＤパスワードを使用しないバイオメトリクスまたはワンタイムパスワード（ＯＴＰ）などの代替的な認証資格情報が含まれる。

ＩｄＰとの認証後、ＩｄＰは確認トークン（たとえば、ＳＡＭＬトークン）を指名されたリライングパーティ（ＲＰ）またはサービスプロバイダに発行してもよく、これを使用してユーザからのサービスアクセス要求を処理し得る。ＲＰは、認証の詳細全てを知ることも、資格情報と直接インタラクトすることも必要とせずに、ＩｄＰからのフレッシュなＳＡＭＬトークンを使用して、要求元ユーザのアイデンティティを信用し得る。ＩｄＰがユーザのアイデンティティを確認したことが（後述の）資格情報マッピングサービスに保証され得る限り、ＳＡＭＬトークンの代わりに、他のトークンフォーマットまたはアイデンティティ確認メカニズムが使用されてもよい。外部認証イベント（たとえば、ＩｄＰによる認証）の受諾に基づいて、仮想スマートカードの資格情報（短期間ログオン証明書とも呼ばれる）が発行されてもよい。

上記の高速スマートカードログオンからの証明書動作インターセプトコンポーネントを使用して、ＰＣ／ＳＣのＡＰＩレベルでスマートカードを完全にエミュレートすることなく、仮想スマートカードとのインタラクションを可能にし得る。仮想スマートカードは、ＩｄＰにおいて、リモートコンピューティング環境（たとえば、認証サーバ）においてローカルに、及び／または高度に保護され得る別個のサーバ、たとえば、資格情報マッピングサービスをホストするサーバなどにおいて、作成されてもよい。

様々なフェデレーションシナリオが存在する。たとえば、外部ユーザの従来のフェデレーションは、ビジネスツービジネス（たとえば、サプライチェーン、共同開発などのパートナー）であり得る。コンシューマツービジネスは、たとえば、市民、退職者、退役軍人などを含み得る。クラウドサービスは、企業リソースにアクセスするためにクラウドデスクトップが使用されるソフトウェアアズアサービス（ＳａａＳ）製品及び／またはデータアズアサービス（ＤａａＳ）にアクセスするための企業管理型のユーザ認証を含み得る。次世代の企業セキュリティモデルは、アイデンティティプロバイダ（ＩｄＰ）を、デバイスからのＳａａＳ及びオンプレムリソース用のユーザ認証のための中心点として含んでもよい。ＩｄＰ自体が、アイデンティティアズアサービス（ＩＤａａＳ）などの、オンプレムまたはクラウドサービスであってもよい。

図１１に、本明細書に記載の１つまたは複数の例示的な態様によるフェデレーテッドログオンのための例示的なシステムを示す。図１１に示すシステムは、図１２Ａ〜図１２Ｃに示す例示的なシステムで使用されるように、資格情報マッパーを使用しなくてもよい。

図１２Ａに、本明細書に記載の１つまたは複数の例示的な態様によるフェデレーテッドログオンのための他の例示的なシステムを示す。一部の態様では、スマートカードは、このフェデレーテッドログオンの場合に使用されなくてもよい。その代わりに、証明書が認証に使用されてもよく、リソースシステム１２２１（たとえば、顧客の構内）は、証明書がスマートカード証明書であると考えてもよい。システム１２２１はセットアップフェーズを開始してもよい。アプリケーションストア１２２５は、信頼済みのデバイスを含んでもよく、ユーザのドメイン（たとえば、ＡＤまたはディレクトリサービス１２４１）ログオン資格情報を資格情報マッパー１２２９に要求するために使用されてもよい。資格情報は、短い有効期間のスマートカードクラス証明書（たとえば、仮想スマートカード証明書）を含んでもよい。資格情報マッパー１２２９は、ＡＤユーザ用の短い有効期間のスマートカードクラス証明書を要求するために、サードパーティ証明書サービス（たとえば、ＭＩＣＲＯＳＯＦＴ証明書サービス）などの、証明書サービス１２３１によって信頼されてもよい。資格情報マッパー１２２９は、ユーザ用の仮想スマートカードを作成するために使用されてもよい。資格情報マッパー１２２９は、証明書サービス１２３１に証明書を要求してもよく、証明書サービス１２３１は、ユーザ用のスマートカードクラス証明書を資格情報マッパー１２２９に返してもよい。仮想スマートカードは、資格情報マッパー１２２９に記憶（たとえば、キャッシュ）されてもよい。

カスタムテンプレートが、制御を提供するために使用されてもよい。発行インフラストラクチャへの制御を提供する（たとえば、スマートカードクラス証明書を要求するのに信頼されるサーバを制限または識別する）だけでなく、カスタムテンプレートはまた、特別なマーカーを発行される証明書に含ませることができ、これにより特別なグループメンバーシップがログオントークン及びＫｅｒｂｅｒｏｓチケットに挿入されることになる。一部の態様では、複数のマーカーが証明書内に配置されてもよく、各マーカーが各自のグループメンバーシップを選択する。これにより、認証及びサービスプロバイダアクセス要求の完全な状況を構成する異なる属性を個別のグループにマッピングするための柔軟性が提供され得、所望のリソースアクセス制御ポリシーを表現し易くなる。これらのマーカーによって、たとえば、ＷＩＮＤＯＷＳ（登録商標）ベースのインフラストラクチャ及びサービスは、現実のスマートカードまたはパスワードを使用するのではなく、この特定のメカニズムによってユーザがＡＤへ認証したことを認識することが可能になり得る。

異なるテンプレートが、資格情報マッピングサービス１２２９によって、ＳＡＭＬトークンの属性、または真の認証保証レベルの他の指示に基づいて使用されてもよい。追加または代替の認証状況が、認証保証レベル以外の関心対象であってもよい。たとえば、ユーザの地理的位置、またはサービスプロバイダにアクセスするために使用される接続経路（たとえば、境界線の内か外か）が、関心対象であってもよい。証明書テンプレートは、これらの利用可能な属性及び状況指標の一部または全部からのマッピングに基づいて選択されてもよい。追加的または代替的には、資格情報マッピングサービス１２２９によって、たとえば、資格情報マッパーサービス１２２９により認証局に送られる証明書署名要求を介して、カスタムステートメントまたは属性が証明書に追加されてもよい。これらはセキュリティグループにマッピングされなくてもよく、クライアント証明書認証を直接使用するウェブアプリケーションなどのアプリケーションによって検査することができる。

ディレクトリサービス１２４１は、ユーザログオン用のスマートカードクラス証明書を発行する証明書サービス１２３１を信頼してもよい。この信頼ステップは、仮想スマートカード証明書をＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙログオンなどに使用することを可能にし得る。信頼ファブリックが、サービスツーサービスのアイデンティティ及びセキュアな通信を確立する適所にあってもよい。任意選択で、資格情報マッパー１２２９は、アイデンティティプロバイダ（ＩｄＰ）１２１３によって発行されたＳＡＭＬトークンをクロスチェックしてもよい。

システムは実行フェーズを開始してもよい。クライアントエージェント１２０１内のウェブビュー１２０３は、ＩｄＰログオンに対処するために使用されてもよい。クライアントエージェント１２０１は、ログオンのために資格情報をＩｄＰ１２１３に送ってもよい。ウェブビュー１２０３はまた、ゲートウェイサーバ１２２３またはアプリケーションストア１２２５へのＳＡＭＬログオンのための標準的なセキュリティアサーションマークアップ言語（ＳＡＭＬ）プロトコルをサポートしてもよい。ゲートウェイサーバ１２２３は、企業リソース及び／またはクラウドリソースへのアクセスを提供するサーバまたは他のリソースであってもよい。ログオンプロセス中に、ＩｄＰ１２１３は、アイデンティティ確認トークン（たとえば、ＳＡＭＬトークン）をクライアントエージェント１２０１に返してもよい。ＳＡＭＬトークンはクライアントエージェント１２０１によって、アイデンティティシステム１２１１と認証したことの証明として使用されてもよく、これはリソースシステム１２２１の外部パートナーを含んでもよい。

ウェブフォームを含むＨＴＭＬページを含み得るログオンページ１２１５を使用して、ユーザから、または場合によってはブラウザもしくはクライアントエージェント自体から認証資格情報を収集してもよい。これらの資格情報は、ユーザ名及びパスワードフォームから、高度なリスクベースの認証システムにまで及ぶことができる。ＩｄＰ１２１３はこれらのログオンページ１２１５を使用して、１つまたは複数の任意の適切な認証方法で正規ユーザを認証してもよい。

ディレクトリ１２１７は、アイデンティティストアもしくはアカウントデータベース、またはＩｄＰ１２１５をサポートする他のディレクトリを含んでもよい。たとえば、ディレクトリ１２１７は、他の会社のネットワーク内のＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙのインスタンスであってもよく、または他のベンダーのＬＤＡＰディレクトリ製品を使用してもよい。

ＤｉｒＳｙｎｃ１２１９は、（仮想化サーバ１２３７を介して公開され得る）リソースシステム１２２１でホストされるアプリケーション及びデスクトップへのアクセスを許可されるべきであるディレクトリ１２１７内の正当で許可されたユーザごとにディレクトリサービス１２４１においてシャドウアカウントが存在するようにするメカニズムまたはメカニズムのセットを含んでもよい。ＤｉｒＳｙｎｃ１２１９メカニズムの例には、許可されたユーザ名及び他の関連するアイデンティティまたは許可情報のリストを有するスプレッドシートを電子メール送信またはアップロードするなどの手動手順が含まれる。他の例には、（場合によってはディレクトリの区別された部分における）一部または全部のアカウントについてディレクトリ１２１７を照会してディレクトリサーバ１２４１に送信する、定期的にスケジュールされたまたは恒久的に繰り返すバッチジョブが含まれる。他の例には、ディレクトリ１２１７の変更を監視し、それらの変更を発生時に、またはスケジュールに従って送信することが含まれる。他のメカニズムは暗黙的なものであり、すなわち、ディレクトリ１２１７における新たな許可ユーザの存在が、そのユーザアイデンティティを引用するフェデレーショントークンがリソースシステム１２２１に提示された場合に、暗示され得る。

一部の態様では、証明鍵バインディングが使用されてもよい。ＳＡＭＬトークン証明鍵は、フルドメインログオンを許可するために作成される仮想スマートカードにリンクされてもよい。この証明鍵（または関連する証明鍵）は次いで、リモートコンピューティング環境によって、仮想スマートカードを実際に使用するために使用されてもよい。クライアントエージェント１２０１は、ＩｄＰ１２１３により発行されたＳＡＭＬトークンにバインドされる証明鍵をネゴシエートしてもよい。

一部の態様では、ＳＡＭＬトークンまたは他の信頼済みのログオン資格情報が、対応するＡＤユーザパスワードにマッピングされてもよく、これはそのパスワードが、（以下でさらに詳細に説明する）ゲートウェイサーバ１２２３またはアプリケーションストア１２２５のログオンプロセス中に直接利用できない場合でも行われ得る。たとえば、パスワードは、ＩｄＰ１２１３によってそのログオン中にキャプチャされ、信頼済みのバックチャネルを介してゲートウェイサーバ１２２３またはアプリケーションストア１２２５に中継されてもよい。他の態様では、パスワードボルトまたはパスワード管理サービスが、パスワードをゲートウェイサーバ１２２３またはアプリケーションストア１２２５に返してもよい。他の例では、資格情報マッパー１２２９は、それ自体が特定のユーザアカウントのパスワードを管理してもよい。これらのパスワードは、ユーザが選択したパスワードでなくてもよく、したがって、マスター鍵からユーザごとのソルトを使用して導出することができる。この例では、データベースまたはパスワードボルトは使用されなくてもよい。

フルドメインログオンが要求される場合、クライアントエージェント１２０１は、ゲートウェイサーバ１２２３及び／またはアプリケーションストア１２２５にＳＡＭＬトークンを送ってもよい。ゲートウェイサーバ１２２３及び／またはアプリケーションストア１２２５は、（たとえば、バックチャネルを介して）ＳＡＭＬトークンを送るなどしてＩｄＰ１２１３と通信することにより、クライアント１２０１がアイデンティティシステム１２１１と認証されたことを検証してもよい。ＳＡＭＬトークンが有効期間などの時間を含む場合、ＩｄＰ１２１３は現在時刻が有効期間内であることを検証してもよい。追加的または代替的には、リライングパーティ（コンポーネント）は、ＩｄＰの署名証明書のローカルに記憶された（たとえば、信頼済みの）コピーを使用して、ＳＡＭＬトークンが含むデジタル署名をチェックすることにより、ＳＡＭＬトークンをローカルに有効性検証してもよい。

アプリケーションストア１２２５、デリバリーコントローラ１２３５、及び／または仮想化デバイス１２３７は、アプリケーションストア１２２５によって提供されたカスタムログオンデータを、仮想化デバイス１２３７上でのログオンプロセスを駆動するために使用され得る資格情報プラグイン１２３９にセキュアに搬送してもよい。アプリケーションストアは、ログオンデータプロバイダなどの認証拡張１２２７を含んでもよく、これは本明細書に記載のように、仮想スマートカード参照と、仮想化デバイス１２３７が仮想スマートカードにアクセスするための一致する資格情報プラグインと、仮想スマートカードを実装するためのサポート用サービスインフラストラクチャ（たとえば、資格情報マッパー１２２９）と、を取得するために使用されてもよい。

クライアント１２０１が認証されたことが検証されると、ゲートウェイ１２２３、アプリケーションストア１２２５、及び／またはデリバリーコントローラ１２３５（たとえば、デスクトップデリバリーコントローラ）は、資格情報マッパー１２２９が、指定された仮想化マシン上でのＡＤログオン用の時間制限付きの（たとえば、一時的な）スマートカードクラス証明書を取得することを許可してもよい。換言すれば、一時的な証明書は、スマートカード（たとえば、スマートカード内の１つまたは複数の証明書）をエミュレートするために作成されてもよい。時間制限付き証明書は、数分、数時間、数日、またはさらに短いもしくはさらに長い期間の間に有効であってもよい。許可ステップをサポートするために、ストア１２２５／コントローラ１２３５は、ＩｄＰ１２１３からのオリジナルのＳＡＭＬトークンを提示して、その有効性が資格情報マッピングサービス１２２９によって再び検証されるようにしてもよい。たとえば、資格情報マッパー１２２９は、ＩｄＰ１２１３と通信してＳＡＭＬトークンを検証してもよい。このステップはまた、ＳＡＭＬトークンから仮想スマートカードへバインドする証明鍵の転送、または新たな証明鍵のネゴシエーションを容易にすることができる。

ログオンチケットが発行され、リモートディスプレイプロトコル（たとえば、クライアントエージェント）ファイルに入ってもよい。ログオンチケットの手法では、クライアントエージェント１２０１に送られたログオンチケットはまた、資格情報マッピングサービス１２２９によって保持される仮想スマートカードの秘密鍵を最初に暗号化するために使用されてもよい。追加的または代替的には、クライアントエージェント１２０１によって保持される証明鍵が、短い有効期間の証明書にリンク（たとえば、バインド）されてもよい。任意選択で、資格情報マッパー１２２９に、クライアント１２０１による有効なログオンの証拠として、オリジナルのＩｄＰ認証トークンが提示されてもよい。ログオンチケットは、追加的または代替的には、資格情報マッパー１２２９によって提供される仮想スマートカードへのセキュアな参照を暗号化するために使用されてもよい。この例では、仮想スマートカードは、デリバリーコントローラ１２３５によって仮想スマートカードを使用することが許可された仮想化エージェント１２３７のみによって復元されてもよい。暗号化された仮想スマートカード参照は、アプリケーションストア１２２５からデリバリーコントローラ１２３５へ、そして仮想化エージェント１２３７へ送られてもよく、一方、ログオンチケットはクライアントエージェント１２０１に送られる。これにより、仮想化エージェント１２３７が知られる前に仮想スマートカードが作成されること、または複数の仮想化エージェントに別々にログオンするために使用されることが可能になり得る。

仮想化エージェント１２３７は、ログオンチケット（またはログオンチケットを使用して復号されるセキュアな仮想スマートカード参照）を資格情報マッピングサービス１２２９に提示し、スマートカードクラス証明書を使用して、クライアントデバイス１２０１をＭＩＣＲＯＳＯＦＴ ＡＤなどのディレクトリサービス１２４１にログオンさせてもよい。資格情報プラグイン１２３９（たとえば、ログオンフック）は、前述の高速スマートカードログオンの手法に非常に類似しているかまたは同一であってもよい。資格情報プラグイン１２３９は、図８を参照して説明したサーバ側の仮想エージェント８２３、資格情報プロバイダ８２５、及び／またはＣＳＰ８３１を含んでもよい。

資格情報マッパー１２２９は証明書サービス１２３１とインタラクトしてもよく、これは、スマートカードクラスユーザ認証証明書を対応する秘密鍵と共に取得するための認証局、たとえば、ＷＩＮＤＯＷＳ（登録商標）証明書サービスを含んでもよい。すなわち、資格情報マッパー１２２９は、ユーザ用の登録局（たとえば、ＭＩＣＲＯＳＯＦＴ登録エージェント）として使用されてもよい。資格情報マッパー１２２９は、証明書サービス１２３１に要求を送るときに認証証明書として使用する登録局証明書を有してもよい。資格情報を初めて取得するためのブートストラッププロセスが存在してもよく、その後、手動ステップを最小限にするために必要に応じて更新が自動的に行われてもよい。

スマートカードクラス証明書は、ディレクトリサービス１２４１（たとえば、ＡＤドメイン）によって、関連するユーザアカウント用のインタラクティブログオン資格情報として信頼されてもよい。換言すれば、証明書は仮想スマートカードとして、たとえば、スマートカードクラスユーザ証明書として扱われてもよい。証明書は、資格情報マッパーサーバ１２２９上の鍵ストアに保持された対応する秘密鍵を用いた、Ｋｅｒｂｅｒｏｓなどを介したＡＤログオンのための適切な鍵使用が可能であってもよい。ハードウェアベースの鍵の保護が、たとえば、信頼済みプラットフォーム（たとえば、ＷＩＮＤＯＷＳ（登録商標）トラステッドプラットフォームモジュール（ＴＰＭ））及び／またはハードウェアセキュリティモジュール（ＨＳＭ）を介して、秘密鍵に対して使用されてもよい。ハードウェアベースの鍵の保護はまた、ログオンレイテンシを有益に短縮するために使用されてもよい。

アプリケーションストア１２２５の認証拡張１２２７は、アプリケーションストア１２２５の起動シーケンス中に（及び任意選択でアプリケーションストア１２２５のログオンシーケンス中に）資格情報マッパー１２２９とインタラクトして、ユーザ用の仮想スマートカードを準備するようにしてもよい。ユーザ用の仮想スマートカードはオンデマンドで、たとえば、起動もしくは再接続イベントのたびに作成されてもよく、または様々なセキュリティポリシー及びパフォーマンスニーズに応じて一定の期間の間、再使用されてもよい。仮想スマートカードは、事前に作成されてもよく、特に上述のように秘密鍵へのハードウェア保護が存在する場合には、物理スマートカードに使用されるものに近い有効期間を有してもよい。

仮想化サーバ１２３７の資格情報プラグイン１２３９は、ログオン中に仮想スマートカードを使用する関連するオペレーティングシステムコールをインターセプトして、資格情報マッパーサーバ１２２９に特定の動作をリダイレクトしてもよく、そこでそれらが暗号ＡＰＩ及びプロバイダを使用して実行されることになる。

図１２Ｂに、本明細書に記載の１つまたは複数の例示的な態様によるフェデレーテッドログオンのためのさらに他の例示的なシステムを示す。図１２Ｂに示す認証システムは、図１２Ａを参照して説明した認証システムと類似し得る。しかしながら、アイデンティティ確認（たとえば、ＳＡＭＬトークン）を使用する代わりに、クライアントエージェント１２０１は、ワンタイムパスワード（ＯＴＰ）または実際のスマートカード資格情報を、リソースシステム１２２１内のコンポーネントのうちの１つまたは複数、たとえばゲートウェイサーバ１２２３に送ってもよい。ゲートウェイサーバ１２２３は、以下でさらに詳細に説明するように、ベンダー認証サービス１２５１を用いてクライアントまたはユーザを認証してもよい。また、ゲートウェイサーバ１２２３は、同じく以下で説明するように、ＲＡＤＩＵＳまたはＲＥＳＴプロトコルを使用して認証サービス１２５１と通信してもよい。

図１２Ｃに、本明細書に記載の１つまたは複数の例示的な態様によるフェデレーテッドログインのための他の例示的なシステムを示す。図１２Ｃに関して説明するコンポーネントを使用して、仮想スマートカードを作成して使用することによって、ユーザセッション（たとえば、仮想デスクトップセッション）を開始してもよい。ユーザアカウントを保持するＡＤドメインは、証明書サービス１２３１などの認証局（ＣＡ）によって発行されたスマートカードクラスユーザ証明書をフルＡＤドメインログオンに使用することを可能にするために、正しいフォームの事前に築かれた信頼を有してもよい。最初に、いくつかのデプロイメントステップが実行されてもよい（図示せず）。たとえば、システムは、資格情報マッパー１２２９をデプロイし、図１２Ｃに示すコンポーネント間に信頼を築くためのステップ（これは手動ステップでもよい）を実行してもよい。

資格情報マッパー１２２９は、ＣＡへの登録局（たとえば、登録エージェント）を含んでもよい。資格情報マッパー１２２９は、組織のＣＡ管理者（たとえば、セキュリティ責任者）による手動承認を使用し得るブートストラップ証明書テンプレートを使用してＣＡによって発行されたクライアント証明書などの自身の資格情報を要求してもよい。最初の証明書が発行されると、第２の証明書テンプレートは、ＲＡ証明書のロールオーバが自動的に処理されることを可能にし得る。ロールオーバは、現在の証明書の有効期限が近づくと、新たな証明書を発行することを含んでもよい。

また、第２の証明書テンプレートによって、資格情報マッパー１２２９の１つのインスタンスは、他のサーバがグループに参加し、資格情報マッパー１２２９の他のインスタンスをホストすることを許可することが可能になり得る。これは、セットアップ及び継続的な保守の運用負担を最小限に抑えながら、スケールアウト及び冗長性のために使用されてもよい。これは、この機能のユーザが、高可用性を維持しながら、そのような証明書ベースのデプロイメントを運用及び保守する専門家ではない場合に有益であり得る。

ここで、図１２Ｃを参照して例示的な流れを説明する。クライアントエージェント１２０１（またはブラウザ）は、ゲートウェイサーバ１２２３にログオンしてもよい。一部の態様では、ワンタイムパスワード（ＯＴＰ）がＡＤパスワードの代わりに使用されてもよい。ユーザにＯＴＰが発行されてもよい。代替的には、他の認証資格情報、たとえば、ＳＡＭＬトークン、スマートカード資格情報、チャレンジ／応答資格情報、Ｋｅｒｂｅｒｏｓ資格情報、バイオメトリクス、ＰＩＮなどが、ＯＴＰの代わりに使用されてもよい。ステップ１２７０において、クライアントエージェント１２０１（またはクライアントデバイス上のブラウザ）は、ゲートウェイサーバ１２２３にＯＴＰを送ってもよい。ＡＤパスワードが使用されないので、ゲートウェイサーバ１２２３は、アプリケーションストア１２２５に（たとえば、シングルサインオンで）サインオンするためにパスワードを使用できない場合がある。その代わりに、ステップ１２７２において、ゲートウェイサーバ１２２３は、ベンダー認証サービス１２５１を介してユーザを認証してもよい。たとえば、ゲートウェイサーバ１２２３は、リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）ネットワークプロトコル、軽量ディレクトリアクセスプロトコル（ＬＤＡＰ）、表現可能状態転送（ＲＥＳＴ）ネットワークプロトコル、またはＯＴＰに基づいてユーザを認証するための他の任意のタイプのネットワークプロトコルを使用してもよい。ゲートウェイサーバ１２２３は、たとえば、平文のユーザ資格情報が、ＲＡＤＩＵＳ、ＬＤＡＰ、またはＲＥＳＴなどの転送プロトコルの一部として暗号化されたものを送ってもよい。認証サービス１２５１は、平文の資格情報を復元し、それらを有効性検証してもよい。認証サービス１２５１は、資格情報が有効であるか否かを折り返し報告し、場合によっては追加のアイデンティティ情報、たとえば、正規のユーザ名及びグループＩＤを供給してもよい。

ステップ１２７４において、ゲートウェイサーバ１２２３は、シングルサインオンプロトコルを介して、ユーザのアイデンティティ（たとえば、ＡＤアイデンティティ）をアプリケーションストア１２２５に送ってもよい。ゲートウェイサーバ１２２３はまた、セキュリティコンテキスト情報をアプリケーションストア１２２５に送ってもよい。ステップ１２７４で送られる例示的な情報には、認証方法、クライアントデバイス上で実行されたスキャンを識別する情報、及び／またはクライアントデバイスの位置が含まれる。ゲートウェイサーバ１２２３によって開始されるＳＳＯセッション中に、いくつかのステップが行われてもよい。

ステップ１２７６において、アプリケーションストア１２２５は、資格情報マッパー１２２９（たとえば、ユーザ資格情報サービス）に連絡して、Ｗｉｎｄｏｗｓ（登録商標）のＡＤログオンを有効化するために、一致するユーザ証明書及び秘密鍵が利用可能であることを確認してもよい。ゲートウェイサーバ１２２３によってアプリケーションストア１２２５に渡されたセキュリティコンテキスト情報の一部または全部が、ユーザ証明書に組み込むために資格情報マッパー１２２９に送られてもよい。コンテキスト情報は、要約、補足、またはマッピングされた形で送られてもよい。アプリケーションストア１２２５は、どのようなセキュリティコンテキスト情報が資格情報マッパー１２２９に渡されるかを制御してもよい。渡され得る他の情報は、セキュリティグループ（たとえば、ＷＩＮＤＯＷＳ（登録商標）セキュリティグループ）に関連付けられた役割ラベルを含んでもよい。役割ラベルは、生のセキュリティコンテキスト情報に基づいて選択されてもよく、顧客のセキュリティポリシーの決定事項であってもよい。ユーザがセキュリティグループに追加されてもよい。

アプリケーションストア１２２５はまた、Ｋｅｒｂｅｒｏｓまたはデバイス証明書を使用するなどして、資格情報マッパー１２２９へ認証してもよい。マシンレベル認証を使用する場合、資格情報マッパー１２２９は、資格情報ハンドルを要求するのに信頼済みのマシンのホワイトリストを実装してもよく、これは後で（たとえば、異なる信頼済みマシンのセットにより）ログオンのために使用することができる（たとえば、ユーザの偽装）。代替的には、アプリケーションストア１２２５は、Ｋｅｒｂｅｒｏｓ制約付き委任（ＫＣＤ）及びプロトコル遷移を使用して、直ちにユーザに偽装し、資格情報マッパー１２２９へのＫｅｒｂｅｒｏｓユーザ認証を実行してもよい。これにより、標準的なＡＤ制御をＫＣＤに使用してホワイトリストを管理することが可能になり得る。これはまた、ユーザの偽装から除外することができる、管理者などの特定の機密性が高いユーザアカウントをブラックリストに載せるメカニズムを提供し得る。

ステップ１２７８において、資格情報マッパー１２２９は、資格情報マッパー１２２９が特定のユーザ用の証明書を要求することを可能にする事前に確立された許可に基づいて、証明書サービス１２３１（ＣＡ）への登録局（たとえば、登録エージェント）として機能してもよい。アプリケーションストア１２２５によって提供された役割ラベルを使用して、資格情報マッパー１２２９は、特定のセッション用の証明書を取得するために使用するＣＡと証明書テンプレートとの組み合わせを決定してもよい。顧客は、ＡＤの認証メカニズム保証機能及びエンタープライズ証明書サービス（たとえば、ＷＩＮＤＯＷＳ（登録商標） ＳＥＲＶＥＲ２００８）を使用して、これらの証明書に基づくユーザセッションをＷＩＮＤＯＷＳ（登録商標）セキュリティグループなどの特定のセキュリティグループに所属させることができる。これにより、標準的なＷＩＮＤＯＷＳ（登録商標）アクセス制御リスト（ＡＣＬ）を使用して、仮想化セッション１２３７に、ネットワークリソースへのアクセスを許可または拒否することが可能になり得る。ＡＣＬは、被信頼者（ｔｒｕｓｔｅｅ）を識別し、被信頼者に対するアクセス権を指定するために使用されるアクセス制御エントリ（ＡＣＥ）をリスト化してもよい。

資格情報マッパー１２２９は、デプロイメント中にプロビジョニングされたそのＲＡ証明書を使用して、そのサービスアイデンティティを証明書サービス１２３１に対して証明してもよい。これは、証明書サービス１２１３によって、要求された証明書テンプレートへのアクセスを許可または拒否し、ひいては証明書発行要求１２７８を許可または拒否するために使用されてもよい。ＷＩＮＤＯＷＳ（登録商標）エンタープライズ証明書サービスは、どのエンティティが証明書を発行することができるか、また、どの対象に対してかについて制限することを可能にする証明書テンプレート及び登録エージェントのＡＣＬを許可してもよい。

ステップ１２８０において、資格情報マッパー１２２９がセッションに適切なユーザ証明書を作成または配置すると、資格情報マッパー１２２９は、アプリケーションストア１２２５にセキュアなハンドルを返してもよく、これは仮想化マシンが後で証明書資格情報にアクセスするために使用することができる。返されたハンドルは、ＯＡｕｔｈトークンと類似していてもよい。たとえば、ハンドルは、サーバのアイデンティティタグなどの他の情報と組み合わせられたセキュアな乱数を含んでもよく、これは後で他のマシンからのネットワークアクセスを可能にする。ハンドルは、純粋にベアラ所持トークンとして使用可能でなくてもよい。むしろ、トークンは、（たとえば、Ｋｅｒｂｅｒｏｓまたはマシン証明書を使用して）自身のアイデンティティを独立して証明することができ、許可済みマシンのホワイトリスト上にあるマシンによって提示された場合に、使用されてもよい。

ステップ１２８２において、アプリケーションストア１２２５がユーザのパスワードをキャッシュし得る方法と同様に、アプリケーションストア１２２５は資格情報ハンドルをキャッシュしてもよい。そのサイズ及び他の考慮事項に応じて、ハンドルは、アプリケーションストア１２２５の認証サービスにより発行されたＳＡＭＬ認証トークン内にそのままの形で配置されて、クライアントエージェント１２０１または他のコンポーネントによってキャッシュされてもよい。代替的には、ハンドルは、アプリケーションストアサーバ１２２５上に維持される資格情報ホルダまたはボルト内に配置して、処理が後でハンドルを要求した場合にアクセスできるようにしてもよい。アプリケーションストア１２２５のログオンプロセスは、この段階で完了してもよい。

ステップ１２８４において、ゲートウェイサーバ１２２３及び／またはアプリケーションストア１２２５によるログオンの後に、リソース起動要求が行われてもよい。資格情報ハンドルが、アプリケーションストア１２２５のＳＡＭＬ認証トークンから直接的または間接的に復元されてもよい。起動処理の一部として、後に行われ得るディスプレイリモーティング接続に備えて、ユーザのセッション（たとえば、ＷＩＮＤＯＷＳ（登録商標）セッションなどの仮想化セッション１２３７）をホストするマシンに、デスクトップコントローラコンポーネント１２６１を介して、ハンドルが転送されてもよい。たとえば、ハンドルは、リモートアプリケーションまたはデスクトップコントローラ１２６１を使用して、仮想化セッション１２３７に渡されてもよい。セッションは仮想デスクトップまたは仮想アプリケーションセッションを含んでもよく、ホスト１２３７は一度に１つのユーザセッション専用であってもよく、または（たとえば、リモートデスクトップサービスを使用して）複数の独立したユーザセッションを可能にし得る。ユーザセッションは、これが再接続イベントである場合には既に存在し得、またはこれが初回の起動イベントである場合には、まもなく作成され得る。セッションホスト１２３９は、ハンドルを受信してもよく、ディスプレイリモーティング接続を待つ間、一時的にハンドルをキャッシュしてもよい。ハンドルはまた、ハンドルを開示するリスクを最小化するために、送信及びキャッシングステップの前に暗号化されてもよい。ハンドルを復号するための鍵は、通常のクライアントエージェント起動ファイルの一部として、ログオンチケットの形でクライアントエージェント１２０１に送られてもよい。

ステップ１２８６において、クライアントエージェントのエンジンは、アプリケーションストア１２２５から受信したクライアントエージェント起動ファイルを使用して始動されてもよい。クライアントエージェント１２０１は、クライアントエージェントセッションネゴシエーションの一部として、セッションホスト１２３７にログオンチケットを提示してもよい。図示していないが、クライアントエージェントの接続は、別の許可チケットを必要とするゲートウェイサーバ１２２３を介してプロキシされてもよい。

ステップ１２８８において、ログオンチケットを使用して復号鍵を導出することによって、資格情報ハンドルを復元し、これを使用して、資格情報動作が資格情報マッパー１２２９によって実行されることを要求してもよい。要求された動作は、ユーザ証明書自体を取得する動作など、スマートカードログオンをリモートで実行するため、１つまたは複数の署名動作を実行するため、及び／または１つまたは複数の復号動作を実行してＫｅｒｂｅｒｏｓセッション鍵をラッピング解除するために使用されてもよい。代替の形態のインタラクションは、仮想化エージェント１２３７上で直接（たとえば、ジャストインタイムで）一時的な仮想スマートカードを作成することであってもよい。この例では、ＣＳＰは、鍵のペアを作成し、次いで、通常の証明書取得要求の代わりに、公開鍵の証明書署名要求を資格情報マッパー１２２９に送ってもよい。この要求は、証明書ハンドルを使用し、マシン認証を使用して行われてもよい。

資格情報マッパー１２２９は、前述のように、役割及び他のセキュリティコンテキスト情報に基づいてユーザ用の証明書を要求する。証明書は仮想化エージェント１２３７に返されてもよいが、鍵がローカルに存在するときに、残りの仮想スマートカード動作がローカルで実行されてもよい。

資格情報マッパー１２２９は、鍵のペアを作成しないように修正されてもよい。その代わりに、資格情報マッパー１２２９は、ユーザ証明書（たとえば、ユーザアイデンティティ、役割、または他のセキュリティコンテキスト情報）を取得するための関連情報を覚えてもよい。資格情報ハンドルは、その情報を使用して既に準備された仮想スマートカードではなく、この情報への参照であってもよい。

高速スマートカードログインの場合と同様に、ＣＳＰは多くまたはほとんどの動作を仮想化エージェント１２３７上の他のＣＳＰ（たとえば、標準ＣＳＰ）に委任してもよい。フルフェデレーテッドログオンの場合、標準ＣＳＰは、ＴＰＭまたは他のＨＳＭを活用して強力な鍵の保護または高速化機能を提供することができるＣＳＰで構成されてもよい。鍵は、セッション中の使用できるように維持されてもよい。鍵はまた、ログオンに使用するのに十分に長くメモリに保持され、その後破棄されてもよい。前述の例では、暗号動作を仮想化エージェント１２３７にわたって分散させて、資格情報マッパー１２２９への負荷を軽減してもよい。

セッションホストマシン（たとえば、仮想化セッション１２３７）は、たとえばＫｅｒｂｅｒｏｓまたはデバイス証明書を使用して、資格情報マッパー１２２９へ認証してもよい。資格情報マッパー１２２９は、ユーザログオン（たとえば、ユーザの偽装）を実現するためにこのように資格情報ハンドルを使用するのに信頼済みのマシンのホワイトリストを実装してもよい。

図１３に、本明細書に記載の１つまたは複数の例示的な態様によるアプリケーションストア１２２５、資格情報マッパー１２２９、及び仮想化エージェント１２３７の間の例示的なインタラクションを示す。この例では、前述の高速スマートカードログオン用のコンポーネントが、フェデレーテッドフルドメインログオンを実装するために再使用され得る。たとえば、資格情報マッパー１２２９は、ネットワーク仮想スマートカードのように機能してもよいが、前述のように、スマートカード１２９０が一時的なものであって、ＳＡＭＬトークンまたは他の信頼済みアイデンティティ確認に基づいて発行されてもよいことを除く。また、ワンショットログオンチケット（または前述の証明鍵）が、ブローカーまたは資格情報マッパー１２２９によって、リモートセッション起動要求をリモートディスプレイプロトコル接続にリンクさせるために生成されてもよい。

証明鍵が使用され得る複数の方法が存在し、そのいくつかは上述している。他の方法は、クライアントエージェントが、ＩｄＰへの認証中にＳＡＭＬ認証トークンにリンクされる証明鍵を有してもよいというものである。この証明鍵はまた、仮想スマートカード証明書にリンクされてもよく、この証明鍵を必要とするクライアントエージェントと仮想化エージェントとの間のインタラクションは、仮想スマートカードが使用可能になる前に行われてもよい。仮想化エージェントは、クライアントエージェントが（たとえば、仮想スマートカードを使用するための前提条件として）証明鍵を所持しているか否かを確かめてもよい。代替的には、仮想化エージェントは、クライアントエージェントと資格情報マッパーとの間の間接的なインタラクションを仲介してもよい。仲介を使用して、仮想スマートカード動作を許可する前に証明鍵の所持を証明してもよく、または場合によっては、仲介を使用して、仮想スマートカードの秘密鍵を復号することができる。

アプリケーションストア１２２５は、認証サービス１２２７（たとえば、ログオンデータプロバイダ拡張）を呼び出して、１つまたは複数の起動要求についてのカスタムログオンデータを取得してもよい。ステップ１３０５において、認証サービス１２２７は、資格情報マッパー１２２９からログオンデータを取得してもよい。資格情報マッパー１２２９との最初のインタラクションはまた、起動中の遅延の最小化を支援するためにアプリケーションストア１２２５のログオン中に行われてもよい。資格情報マッパー１２２９からのログオンデータは、資格情報マッパー１２２９によって管理される仮想スマートカード１２９０への参照を含んでもよい。アプリケーションストア１２２５は、資格情報マッパー１２２９からログオンデータを受信してもよい。

ステップ１３１０において、アプリケーションストア１２２５は、ログオンデータを暗号化し、暗号化したデータをデリバリーコントローラ１２３５に送ってもよい。ステップ１３１０は、たとえば、クライアントのログオンステップ中に実行されてもよい。一部の態様では、デリバリーコントローラ１２３５に送られる暗号化されたログオンデータは、無署名であってもよい。ステップ１３１５において、デリバリーコントローラ１２３５は、暗号化されたログオンデータを仮想化エージェント１２３７に送ってもよい。ステップ１３１５は、暗号化されたユーザ名及びパスワードが標準的な起動要求中に渡されるのによく似たように、セッション準備中などに実行されてもよい。アプリケーションストア１２２５は、暗号化鍵またはそれを導出できるランダム値をクライアントエージェントファイル内にログオンチケットとして入れてもよい。

仮想化エージェント１２３７は、資格情報プラグイン１２３９（図１２Ａ〜図１２Ｃなどに図示）を含んでもよく、資格情報プラグイン１２３９は、仮想化エージェント１２３７に事前に登録されてもよい。資格情報プラグイン１２３９は、特定の資格情報タイプに関連付けられてもよく、その資格情報タイプは、アプリケーションストア１２２５によって、仮想化エージェント１２３７に送られたログオンデータを用いて宣言されてもよい。

前述のように、ＫＣＤがログオンに使用されてもよい。ＫＣＤの実装では、アプリケーションストア１２２５からのカスタムログオンデータは、アプリケーションストア１２２５が発行したトークンまたはチケットを提示してアプリケーションストア１２２５に（または資格情報マッパー１２２９に）認証されたコンタクトを返すように、異なる仮想化エージェント１２３７の資格情報プラグインに指示してもよい。アプリケーションストア１２２５は次いでＫＣＤを使用して、ユーザアイデンティティを仮想化エージェント１２３７にジャストインタイムで委任してもよい。この実装は、デリバリーコントローラ１２３５に対するＸＭＬインターフェースと、仮想化エージェント１２３７に対するブローカリングプロトコルインターフェースとを介して、フルＫｅｒｂｅｒｏｓ委任チェーンを構築することを回避してもよい。仮想化エージェントの資格情報プラグインは次いで認証パッケージを呼び出して、ＫＣＤからのネットワークログオントークンをフルインタラクティブログオントークンに変換してもよい。

クライアントとの接続が行われ、ログオンチケットが提示された場合、仮想化エージェント１２３７は自動ログオン処理を実行してもよい。たとえば、仮想化エージェント１２３７は、資格情報プロバイダ１２９２に信号を送ってもよく、これはワークステーションセッションなどのために登録されてもよい。資格情報プロバイダの代わりに、資格情報プロバイダフィルタが、リモートデスクトップセッションの場合などに、使用されてもよい。ステップ１３１５で受信した暗号化ログオンデータを復号し、検査して、資格情報タイプを特定してもよい。資格情報タイプはカスタム資格情報タイプであってもよいので、復号されたデータが、登録された資格情報プラグインに渡されてもよい。資格情報プラグインは、ＷＩＮＤＯＷＳ（登録商標）のログオンシステム（または他の任意のＯＳのログオンシステム）によって使用される、適切なシリアル化された資格情報構造を生成してもよい。シリアル化された資格情報は、処理のために資格情報プロバイダ１２９２（またはフィルタ）から返されてもよい。

資格情報プラグイン１２３９は、前述のように、ＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体を生成してもよい。ＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮ構造体は、スマートカードドメインログオンが実行されることをオペレーティングシステムに示してもよい。前述のように、データ構造は、スマートカードとのインタラクションに使用されるドライバ（たとえば、ＣＳＰ１２９４などのＣＳＰまたはＫＳＰ）への参照を含んでもよい。ステップ１３２０において、ＣＳＰ１２９４は次いで、仮想スマートカードが存在する資格情報マッパー１２２９に関連する動作をリダイレクトしてもよい。

仮想化エージェント１２３７が特定の仮想スマートカードを使用するための許可は、二重にされてもよい。第１に、仮想化エージェント１２３７が、資格情報マッパー１２２９によって信頼済みのホストのホワイトリストにあることが確認されてもよい。第２に、仮想化エージェント１２３７がセッションの準備中にデリバリーコントローラ１２３５から参照を受信したことが確認されてもよい。アプリケーションストア１２２５とデリバリーコントローラ１２３５との間のリソース起動インタラクションの性質のため、アプリケーションストア１２２５（ひいては資格情報マッパー１２２９）は、仮想スマートカード参照を取得する際にデリバリーコントローラ１２３５によって選択される仮想化ホスト１２３７のアイデンティティを知らない場合がある。したがって、仮想スマートカード参照は、任意の信頼済みの仮想化ホストによって使用可能になるように選択され得る。任意の信頼済みの仮想化エージェントホストは、資格情報参照を使用して、仮想スマートカードをローカルに作成することができる。

図１４に、本明細書に記載の１つまたは複数の例示的な態様によるフェデレーテッドログオンのためのさらに他の例示的なシステムを示す。仮想化デプロイメントの観点から、図１４（ならびに前述の図１２Ａ〜図１２Ｃ）に示したコンポーネントによって実行されるステップは、ＳＡＭＬを介した参照チケットなどの従来のチケットログオンモデルに類似したモデルであってもよい。

前述のように、クライアントデバイス１４０１は、アイデンティティプロバイダからＳＡＭＬ認証トークンを受信してもよい。フルドメインアクセスを有するために、クライアントデバイス１４０１は、認証のためにアプリケーションストア１４１１にＳＡＭＬトークンを送ってもよい。アプリケーションストア１４１１は、ブローカーエージェントサービス１４２３及び／またはサーバ１４２１のデリバリーコントローラにＳＡＭＬトークン（たとえば、ユーザの平文のパスワードではない）を送ってもよく、これを使用して参照チケットを要求してもよい。ＳＡＭＬトークンは、クライアント１４０１によって送られたＳＡＭＬトークンと同じであってもよく、またはサードパーティＩｄＰによって修正されてもよい。（たとえば、デリバリーコントローラが資格情報マッピングサービス１４２５を用いてＳＡＭＬトークンを検証することによって）ＳＡＭＬトークンが受諾可能であるとサーバ１４２１が判定した場合、サーバ１４２１は、ユーザのチケット（これは一時的なものでもよい）を作成し、また、作成したチケットを参照または識別する参照チケットを返してもよい。たとえば、資格情報マッピングサービス１４２５は、ＰＫＣＳ１０要求を生成して認証局（ＣＡ）１４３１に送り、この段階でＣＡ１４３１から証明書を取得してもよい。チケットはサーバ１４２１に、たとえば資格情報マッピングサービス１４２５に記憶されてもよい。サーバ１４２１はアプリケーションストア１４１１に参照チケットを送ってもよく、アプリケーションストア１４１１は、セルフサービスプラグイン１４０３を介してクライアント１４０１に参照チケットを送ってもよい。一方、ＳＡＭＬアサーションが資格情報マッピングサービス１４２５によって却下された場合に、「アクセス拒否」エラーコードが代わりにアプリケーションストア１４１１に返されてもよい。

クライアントデバイス１４０１は、参照チケットをフルドメインログオンと引き換えてもよい。たとえば、クライアントエージェント１４０５は、セルフサービスプラグインから参照チケットを受信し、任意選択で参照チケットを記憶し、転送（たとえば、リモーティング）プロトコルを使用して参照チケットを仮想化マシン１４４１に送ってもよい。仮想化マシン１４４１は、参照チケットをサーバ１４２１に、たとえば、サーバ１４２１のデリバリーコントローラ（たとえば、ＤＤＣ）（図示せず）に送ってもよい。チケットはＣＩＴＲＩＸ接続ブローカリングプロトコル（ＣＢＰ）などのブローカープロトコルによって送られてもよい。仮想化マシン１４４１は、参照チケットがＳＡＭＬアサーションログインを表すか否かを、ブローカーに送るまで知らない場合がある。ブローカーからの応答は、平文パスワード、または公開鍵ＰＫＣＳ７認証証明書チェーンを含む新たな応答構造のいずれかであってもよい。

参照チケットを受信した後、デリバリーコントローラは、（参照チケットに含まれる情報に基づいて）チケットが平文パスワード認証プロセスではなく資格情報マッピングサービス１４２５の認証プロセスに使用されたと判定してもよい。したがって、仮想化マシン１４４１に平文のパスワードを返すのではなく、デリバリーコントローラは、資格情報マッピングサービス１４２５によって以前に生成及び／または記憶されたログオン証明書を返してもよい。

図１２Ａ〜図１２Ｃを参照して前述したように、サーバ１４２１のコンポーネントは、参照チケットが正しくかつタイムリーである（たとえば、特定の期間内に引き換えられる）ことを検証してもよい。ブローカーは、ＳＡＭＬアサーションを表す有効な参照チケットを受信した場合、仮想化マシン１４４１と資格情報マッピングサービス１４２５との間のプロキシとして機能してもよい。

証明書が提供されると、クライアント１４０１には、ブローカープロトコルを介した秘密鍵署名動作へのアクセスが与えられてもよい。仮想化マシン１４４１は、ＡＤスマートカード認証を使用して、ユーザをログインさせてもよい。最初の通信パケットは、公開ＰＫＣＳ７証明書チェーンの要求であってもよい。仮想化マシンからの後続の要求は、秘密鍵署名動作に関するものであってもよい。

様々なセキュリティポリシーが使用され得る。資格情報マッピングサービス１４２５には、認証局１４３１（たとえば、ＭＩＣＲＯＳＯＦＴ認証局）への特権的アクセスが付与されてもよい。認証局１４３１はユーザ用の証明書を発行してもよい。認証局１４３１によって資格情報マッピングサービス１４２５に課せられるあらゆる制限に加えて、セキュリティポリシーのクラスが、資格情報マッピングサービスの管理者によって構成されてもよい。第１に、どのユーザがログインできるかが制御されてもよい。アクセス制御リスト（ＡＣＬ）は、資格情報マッピングサービス１４２５を使用して、誰の認証を許可できるか及びできないかを指定してもよい。たとえば、ドメイン管理者グループのどのメンバーもこのようにアクセスすることを許可されないことが決定されてもよい。第２に、どの仮想化マシンがチケットを引き換えてよいかが制限されてもよい。ブローカーの要求時に、チケットは、指名された仮想化マシン（たとえば、Ｋｅｒｂｅｒｏｓドメインアカウントまたは信頼エリアＲＩＤ）によって引き換え可能であってもよい。資格情報マッピングサービス１４２５は、仮想化マシンのリストを制限することが可能であってもよい。たとえば、１つの仮想化マシンカタログが、本明細書に記載のメカニズムを使用して認証を許可されるべきであると決定されてもよい。

第３に、証明書の有効期間が使用されてもよい。証明書は、数分などの短い期間に使用可能であってもよい。これは認証局１４３１を介して制御可能であってもよい。より長い有効期間の証明書が望ましい場合、失効システムが、たとえばユーザのログオフによってトリガまたは実行されてもよい。代替的には、より長い有効期間のネットワーク仮想スマートカードが利用されてもよい。ネットワーク仮想スマートカードは、たとえば、ハードウェアセキュリティモジュールまたはトラステッドプラットフォームモジュール（ＴＰＭ）を使用して仮想スマートカード秘密鍵を暗号化することによって、より高いセキュリティレベルまで保護されてもよい。代替的には、各秘密鍵が、特定のクライアントエージェントによって保持される永続的な証明鍵にリンクされてもよい。仮想スマートカードは、ログオフ時に失効されなくてもよく、資格情報マッピングサービス１４２５によって永続的に記憶することができる。したがって、資格情報マッピングサービス１４２５に記憶された仮想スマートカードは、長期間にわたって（たとえば、セッションの期間中に、ドメインログオンのためだけではなく）再使用されてもよく、その理由は、（特定の仮想化ホストではなく）仮想スマートカードのより強力な保護及び他のパフォーマンス上の利益を提供し得る資格情報マッピングサービス１４２５に記憶されているためである。

第４に、証明書のキャッシング及び有効性の再検証が制御されてもよい。証明書は、最初の認証と、その後のデスクトップのロック解除動作との両方に使用されてもよい。デフォルトでは、証明書はある期間だけキャッシュされてもよいが、新たなＳＡＭＬトークンを提出することによって新たな証明書が生成されるポリシーを構成することを管理者は望む場合がある。第５に、ＳＡＭＬアサーションの検証が実装されてもよい。ＳＡＭＬトークンの検証に対する標準的な制御が提供されてもよい。Ｗｉｎｄｏｗｓ（登録商標）のＵＰＮを主張するＳＡＭＬトークンが最初に許可されてもよく、これにはサードパーティＩｄＰの特別な構成が必要な場合がある。

他の様々なセキュリティ制御が、本明細書に記載のコンポーネントのために構成されてもよい。たとえば、ディレクトリサービス（たとえば、ＡＤ）の管理者などの管理者が、ユーザドメインごとに、関連するＣＡの信頼を手動で構成してもよい。たとえば、管理者は、ルートまたは下位ルート証明書などの証明書を保護されたデータストアに、たとえば、ＡＤ内のＭＩＣＲＯＳＯＦＴのＮＴＡｕｔｈ証明書ストアにインポートしてもよい。これらの証明書をインポートすることにより、関連するＣＡがスマートカードまたはドメインコントローラのタイプの証明書を発行するのに信頼されていることが示され得る。ＷＩＮＤＯＷＳ（登録商標）証明書サービスが企業ＣＡとしてデプロイされている場合、証明書のインポートは自動的に実行されてもよい。

ＣＡ管理者はまた、たとえば、３つの証明書テンプレートをインポートまたは作成してもよい。第１のテンプレートは、データセンターサーバ内の初期信頼をブートストラップするために使用されてもよく、これにより仮想化コンポーネント及びサービスが提供され得る。第２のテンプレートは、データセンターサーバの資格情報の自動化された証明書の更新と、クラスタに参加する新たなデータセンターサーバの資格情報の発行と、を可能にするために使用されてもよい。第３のテンプレートは、ユーザ用のスマートカードログオン証明書を発行するために使用されてもよい。ＣＡは、どのデータセンターサーバがテンプレートを使用できるかを決定するアクセス制御を有してもよい。

他のセキュリティ制御は、データセンターサーバからの証明書要求への信頼をブートストラップするための、ＣＡ管理者による手動の承認を含んでもよい。さらに他のセキュリティ制御は、データセンターサーバ自体が、セキュリティ制御のセットを実装して、仮想スマートカードの作成を要求することが許可されたアプリケーションストアサーバと、ログオンに仮想スマートカードを使用することが許可された仮想化マシンと、を識別することを含んでもよい。それはまた、このように偽装することができるユーザのセットを識別または制限するための制御を有してもよい。

資格情報マッピングサービスの例示的な実施形態
前述の資格情報マッピングサービスの実施形態は、様々な方法で実装されてもよい。１つの目標は、ユーザが証明書を使用してＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙユーザアカウントに簡単かつ迅速にログオンできるシステムである。

一態様では、本明細書に記載のリモートサービスは、クライアントデバイス上のクライアントエージェントに配置されてもよい。これらの態様では、クライアントエージェントはユーザのスマートカードを直接使用して、認証ステップを実行してもよい。これは、前述のように、新たな仮想チャネルを使用してもよい。

他の態様では、リモートサービスは、前述のように、資格情報マッピングサービスを含んでもよい。このサービスは、企業向けＭＩＣＲＯＳＯＦＴ認証局などの認証局を使用して、オンザフライでスマートカード証明書を発行及び記憶するために使用されてもよい。代替的には、証明書は事前に作成されてもよい。認証局と組み合わせた資格情報マッピングサービスを使用して、認証ポリシーの様々な態様を施行してもよい。

図１５に、本明細書に記載の１つまたは複数の例示的な態様による資格情報マッピングサービスを提供するための例示的なシステムを示す。サードパーティＩｄＰ１５５１は、アイデンティティ確認トークン（たとえば、ＳＡＭＬトークン）をフェデレーションサーバ１５５３に送ってもよい。フェデレーションサーバ１５５３はトークンをアプリケーションストア１５１１に送ってもよく、アプリケーションストア１５１１はトークンをデリバリーコントローラ１５１３に転送してもよい。資格情報マッピングサービス１５２５は、保護された接続を介して特別に登録されたデリバリーコントローラ１５１３からのＳＡＭＬトークンを受諾してもよい。構成されたポリシーによって認証が許可された場合、それは１回限りのセキュアなランダムチケットを返してもよく、これはクライアントエージェント１５０５に渡されてもよい。クライアントエージェント１５０５は、仮想化マシン１５４１にチケットを提示してもよく、仮想化マシンがチケットに遭遇した場合、（たとえば、信頼済みの接続を介して）資格情報マッピングサービス１５２５に提示してもよい。これにより、資格情報マッピングサービス１５２５で稼動するリモート暗号動作プロトコルサーバへのログオンシステムのアクセスが可能になり得る。資格情報マッピングサービス１５２５は、秘密鍵を生成し、ＳＡＭＬトークンで識別されたユーザ用の一時的なスマートカード証明書を登録して、認証の暗号学的態様を実行してもよい。一部の態様では、生成された秘密鍵は、セキュアなランダムチケットから導出されたかまたはそれに関連付けられた鍵を使用して、ラッピングされてもよい。

Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙアカウントへの明示的な認証が望まれる場合、別個の高特権サービスがインストールされてもよい。このサービスはドメイン管理者によって構成されてもよい。ドメイン管理者（または同等者）の資格情報を使用して、資格情報マッピングサービス１５２５によって使用されるドメインの認証局１５３１を構成してもよい。これは１回実行されてもよく、管理者のコンソールから自動的に行われてもよい。

資格情報マッピングサービス１５２５を構成する場合、認証局１５３１はドメインで利用可能な全てのＣＡのリストから選択されてもよい。ドメイン管理者（または同等者）の資格情報を使用して、資格情報マッピングサービス１５２５が選択されたＣＡ１５３１にアクセスすることを許可してもよい。ドメイン管理者（または同等者）は、選択されたＣＡの管理コンソールを使用して資格情報マッピングサービス１５２５の許可を認めてもよい。セキュリティ上の理由から、本明細書に記載の動作は、資格情報マッピングサービスごとに行われてもよい。

資格情報マッピングサービス１５２５は、実行時構成用の３つの基本的なリスト、すなわち、資格情報がマッピングされることを要求することが可能なマシンのリスト、マッピングすることができるユーザアカウントのリスト（たとえば、グループ）、及びマッピングされた資格情報に基づいてＡＤログオンを実行することが可能なマシンのリスト、を有してもよい。したがって、セキュリティの決定事項は、次の形態、すなわち、アプリケーションストアＡがＳＡＭＬアサーションＢをＡｃｔｉｖｅ ＤｉｒｅｃｔｏｒｙアカウントＣにマッピングしてもよい、という形態を有してもよい。ログオンは次いで仮想化サーバＤ上で行われてもよい。

本明細書に開示された概念に基づいて様々な利益が利用可能になる。まず、「スマートカードからの証明書の取得」及び「秘密鍵の実行」の動作などの少数の動作は、サーバと（たとえば、クライアントデバイス上の）スマートカードとの間の往復の通信を利用してもよい。その結果、ログオンプロセスが著しく速くなり得る。さらに、互換性のあるスマートカードドライバがサーバにインストールされていない場合でも、スマートカードログオンが成功し得る。

他の利益は、ワンタイムパスワードにより現実のＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙアカウントへのアクセスが提供され得ることである。また、匿名ログオンが一時的にフルＡＤアカウントにマッピングされてもよい。サードパーティ認証ソリューションを、簡単に仮想化マシンにマッピングすることができる。

高速スマートカードログオン機能について、ＷＩＮＤＯＷＳ（登録商標）のＰＫＩＮＩＴログオンシステムとの統合があってもよい。資格情報プロバイダパッケージが、この認証システムと相互運用することになるサーバマシンにインストールされてもよい。これは、一部のシステムに既に含まれる資格情報プロバイダの拡張を含んでもよい。このパッケージの新機能は、ＣＳＰを使用してＰＫＩＮＩＴを用いてログインするようにＷＩＮＤＯＷＳ（登録商標）に指示することであってもよい。ＣＳＰは究極的には、実際のログオン証明書を提供し、関連する秘密鍵動作を行うリモートプロセスと通信してもよい。仮想チャネルは、ＣＳＰと、クライアント上で稼動する既存の認証マネージャプログラムとの間のコンジットとして機能してもよい。３つのトランザクション（または動作）は、「スマートカードユーザ証明書の取得」、「秘密鍵署名の実行」、及び「秘密鍵による復号」を含む。認証マネージャは、ローカルスマートカードを直接使用してＰＫ動作要求を満たしてもよく、これによりユーザを仮想化マシンにログインさせてもよい。認証マネージャは、スマートカードを既にロック解除して、アプリケーションストアにログインし得るので、これはＳＳＯ機能も提供し得る。

一部の追加の態様では、仮想チャネルを介してクライアントにＰＫ動作要求を渡すのではなく、要求が資格情報マッピングサービス（ＣＭＳ）に向けられてもよい。ＣＭＳサーバはログオンを許可し、ＰＫ動作を実行してもよい。別個のサーバにインストールされた信頼済みのサービスが、ＣＳＰからのＰＫ動作要求にサービスして、許可チェックを実行した後に適切なユーザをログインさせてもよい。デリバリーコントローラとの別個のセキュアな通信経路を有するので、ＣＭＳは期待しているログオン要求を許可してもよい。ＣＳＰによって提示される「シングルユースチケット」は、これを実現するための１つのメカニズムであってもよい。ＣＭＳはスマートカード証明書を自動的に登録してもよい。ユーザログオンを実行するために、ＣＭＳは内部で自動的にスマートカード証明書要求を生成し、それらをＭＩＣＲＯＳＯＦＴ認証局またはサードパーティＣＡによって発行させてもよい。ＣＳＰからのＰＫ動作要求は、これらの証明書に基づいてサービスされてもよい。ＣＭＳは追加的に、シングルユースチケットから得られる鍵ラッピング鍵による暗号化を使用して、あるいはハードウェアセキュリティモジュールもしくはトラステッドプラットフォームモジュールまたは他の同様の手段を使用して、証明書用の秘密鍵を保護してもよい。

一般的なセキュリティ要件が存在してもよい。秘密鍵は保護され、ＰＫＩＮＩＴ要求への署名に使用されてもよい。ＰＫ動作の秘密鍵署名要求にサービスするたびに、サーバは、署名するデータが適切なＫｅｒｂｅｒｏｓプロトコルデータに対応するＡＳＮ−１構造であることを検査することにより、Ｋｅｒｂｅｒｏｓログオンを実際に実行していることを確認してもよい。他のデータ構造に秘密鍵動作を実行しようとする試みは、却下されてもよい。復号動作について、復号されたデータは、サーバに返す前に検査して、Ｋｅｒｂｅｒｏｓプロトコル動作に対応する期待されるＡＳＮ−１構造を有することを確認してもよい。秘密鍵は仮想化マシン上で生成または記憶されなくてもよい。ＰＫ動作プロトコルは、ユーザがログインしているマシン上に秘密鍵が存在しなくてもよいようにしてもよい。秘密鍵は、クライアントマシン上のスマートカード内、または分離し得るＣＭＳサーバ内に存在してもよい。

一部の実施形態では、ユーザはリモートセッション（たとえば、リモートアプリケーションまたはデスクトップセッション）に再接続してもよい。再接続は、異なる認証方法及び／または異なるセキュリティコンテキストを最初の起動として使用してもよい。再接続時には、クレームを、新たな認証方法、保証レベル、及び／または他のセキュリティコンテキスト情報、たとえば、位置及びデバイスなどを反映するように更新することができる。この更新は、（セキュリティグループのメンバーシップが追跡される場合は）Ｋｅｒｂｅｒｏｓチケットに、また、セッション証明書自体に情報を反映することに加えて行われてもよく、これを上述のようにＴＬＳクライアント認証に使用し、次いで他のサーバによって検査することができる。一部の態様では、証明書の事前作成を使用したり、上述のモデルをキャッシュしたりするのではなく、起動または再接続のたびに新たな証明書が生成されてもよい。

起動と同様に、通常の（たとえば、ＷＩＮＤＯＷＳ（登録商標）または他のＯＳの）認証プロセスが、前述のように再接続のために行われてもよい。ＯＳレベルで、この認証（たとえば、現在のログオン中のセッションユーザの再認証）を使用して、正しいユーザが存在しているためにセッションがロック解除され得ることを確認してもよい。ユーザが正しいユーザであることを確認した後、既存のセッションをアクセス可能にして、ユーザがユーザのアプリケーションを見て使用できるようにしてもよい。しかしながら、（再接続動作中にこの活動を指揮し得る）仮想化エージェントは、（セッションを起動するための最初の認証に基づく）セッション用のＫｅｒｂｅｒｏｓチケット情報が廃棄され、再認証中に得られた新たなＫｅｒｂｅｒｏｓチケットに置き換えられるように構成してもよい。ＯＳ内の既存のＡＰＩを使用して、このようにＫｅｒｂｅｒｏｓチケットを破棄して置き換えてもよい。たとえば、ＷＩＮＤＯＷＳ（登録商標）コマンドｋｌｉｓｔ．ｅｘｅが使用されてもよい。更新された情報はまた、特別な方法で動作するＯＳの特定の部分、たとえば、ファイル共有アクセスを管理するサービスなどに伝播されてもよい。

代替的には、最初のセッション証明書が新たな証明書に置き換えられてもよい。セッション証明書は、前述のログオン証明書であるが、セッション中に使用するのに十分に長い有効期間を有するものを含み、ＯＳの証明書ストアに伝播して、アプリケーションにアクセスできるようにしてもよい。以前の証明書に基づくあらゆるアプリケーションレベルＴＬＳ接続状態をクリーンアップするために、ブラウザを再起動などして、新たな証明書を正しくピックアップするようにしてもよい。代替的には、属性権限モデルが使用されてもよい。たとえば、セッション証明書は、実際のセキュリティコンテキスト情報を含まなくてもよく、むしろその情報を知っているサービス、たとえば、前述の資格情報マッパーサービスなどへのポインタ（たとえば、適切なセッション参照を有するもの）を含んでもよい。ＴＬＳクライアント認証を使用するウェブサイトは、真の情報を知るために、この属性サービスを照会してもよい。

関連出願の相互参照
本出願は、２０１８年８月２４日に出願され、「ＦＡＳＴ ＳＭＡＲＴ ＣＡＲＤ ＬＯＧＯＮ」と題された米国非仮特許出願第１６／１１１，３２８号の優先権を主張する。本出願はまた、２０１８年２月８日に出願され、「ＦＡＳＴ ＳＭＡＲＴ ＣＡＲＤ ＬＯＧＯＮ」と題された米国仮特許出願第６２／６２７，７９０号の優先権を主張する。本出願は、２０１５年９月３０日に出願され、「ＦＡＳＴ ＳＭＡＲＴ ＣＡＲＤ ＬＯＧＯＮ」と題された米国特許出願第１４／８７０，４３５号と、２０１４年９月３０日に出願され、「ＦＡＳＴ ＳＭＡＲＴ ＣＡＲＤ ＬＯＧＯＮ ＡＮＤ ＦＥＤＥＲＡＴＥＤ ＦＵＬＬ ＤＯＭＡＩＮ ＬＯＧＯＮ」と題された米国仮特許出願第６２／０５７，３４４号とに関連する。各先行出願は、その全体が引用により本明細書に組み込まれる。

本主題は構造的特徴及び／または方法論的行為に特有の文言で説明してきたが、添付の特許請求の範囲で定義する本主題が必ずしも上述の特定の特徴または行為に限定されないことを理解されたい。むしろ、上述の特定の特徴及び行為は、添付の特許請求の範囲の例示的な実施態様として説明している。

Claims (20)

1. サーバとクライアントデバイスとの間にリモーティングチャネルを確立することと、
   前記サーバによって、前記クライアントデバイスから、パーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）プロトコルを介して、前記クライアントデバイスに関連付けられたスマートカードの識別子を含むメッセージを受信することと、
   前記サーバによって、前記識別子を前記スマートカードの代替識別子に置き換えることと、
   前記代替識別子に基づいて、前記サーバによって、前記スマートカードに関連する１つまたは複数の暗号動作に使用する暗号サービスプロバイダを決定することと、
   前記決定された暗号サービスプロバイダを介して、前記リモーティングチャネルを介して、前記クライアントデバイスに、前記スマートカードを必要とする暗号動作の１つまたは複数の要求を送信することと、
   を含む、方法。
2. 前記識別子はリセット応答（ＡＴＲ）データを含み、前記代替識別子は代替ＡＴＲデータを含む、請求項１に記載の方法。
3. 前記暗号サービスプロバイダを決定することは、前記代替識別子と、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダとの間の関連付けについてデータベースに照会することを含む、請求項１に記載の方法。
4. 前記データベースはレジストリを含む、請求項３に記載の方法。
5. 前記代替識別子を生成することと、
   前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を前記データベースに記憶することと、
   をさらに含む、請求項３に記載の方法。
6. 前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を記憶することは、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダを識別する情報と同じファイルに前記代替識別子を記憶することを含む、請求項５に記載の方法。
7. 前記スマートカードの前記識別子は、前記スマートカードのスマートカードタイプを識別する、請求項１に記載の方法。
8. プロセッサと、
   コンピュータ実行可能命令を記憶するメモリと、
   を備える装置であって、前記コンピュータ実行可能命令は、前記プロセッサによって実行された場合に、前記装置に、
   前記装置とクライアントデバイスとの間にリモーティングチャネルを確立することと、
   前記クライアントデバイスから、パーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）プロトコルを介して、前記クライアントデバイスに関連付けられたスマートカードの識別子を含むメッセージを受信することと、
   前記識別子を前記スマートカードの代替識別子に置き換えることと、
   前記代替識別子に基づいて、前記スマートカードに関連する１つまたは複数の暗号動作に使用する暗号サービスプロバイダを決定することと、
   前記決定された暗号サービスプロバイダを介して、前記リモーティングチャネルを介して、前記クライアントデバイスに、前記スマートカードを必要とする暗号動作の１つまたは複数の要求を送信することと、
   を行わせる、前記装置。
9. 前記識別子はリセット応答（ＡＴＲ）データを含み、前記代替識別子は代替ＡＴＲデータを含む、請求項８に記載の装置。
10. 前記暗号サービスプロバイダを決定することは、前記代替識別子と、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダとの間の関連付けについてデータベースに照会することを含む、請求項８に記載の装置。
11. 前記データベースはレジストリを含む、請求項１０に記載の装置。
12. 前記メモリは、コンピュータ実行可能命令を記憶し、前記コンピュータ実行可能命令は、前記プロセッサによって実行された場合に、前記装置に、
    前記代替識別子を生成することと、
    前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を前記データベースに記憶することと、
    を行わせる、請求項１０に記載の装置。
13. 前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を記憶することは、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダを識別する情報と同じファイルに前記代替識別子を記憶することを含む、請求項１２に記載の装置。
14. 前記スマートカードの前記識別子は、前記スマートカードのスマートカードタイプを識別する、請求項８に記載の装置。
15. コンピュータ可読命令を記憶する１つまたは複数の非一時的コンピュータ可読媒体であって、前記コンピュータ可読命令は、コンピューティングデバイスによって読み取られた場合に、前記コンピューティングデバイスに、
    前記コンピューティングデバイスとクライアントデバイスとの間にリモーティングチャネルを確立することと、
    前記クライアントデバイスから、パーソナルコンピュータ／スマートカード（ＰＣ／ＳＣ）プロトコルを介して、前記クライアントデバイスに関連付けられたスマートカードの識別子を含むメッセージを受信することと、
    前記識別子を前記スマートカードの代替識別子に置き換えることと、
    前記代替識別子に基づいて、前記スマートカードに関連する１つまたは複数の暗号動作に使用する暗号サービスプロバイダを決定することと、
    前記決定された暗号サービスプロバイダを介して、前記リモーティングチャネルを介して、前記クライアントデバイスに、前記スマートカードを必要とする暗号動作の１つまたは複数の要求を送信することと、
    を行わせる、前記１つまたは複数の非一時的コンピュータ可読媒体。
16. 前記識別子はリセット応答（ＡＴＲ）データを含み、前記代替識別子は代替ＡＴＲデータを含む、請求項１５に記載の１つまたは複数の非一時的コンピュータ可読媒体。
17. 前記暗号サービスプロバイダを決定することは、前記代替識別子と、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダとの間の関連付けについてデータベースに照会することを含む、請求項１５に記載の１つまたは複数の非一時的コンピュータ可読媒体。
18. 前記データベースはレジストリを含む、請求項１７に記載の１つまたは複数の非一時的コンピュータ可読媒体。
19. コンピュータ可読命令を記憶し、前記コンピュータ可読命令は、前記コンピューティングデバイスによって読み取られた場合に、前記コンピューティングデバイスに、
    前記代替識別子を生成することと、
    前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を前記データベースに記憶することと、
    を行わせる、請求項１７に記載の１つまたは複数の非一時的コンピュータ可読媒体。
20. 前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダに関連付けて前記代替識別子を記憶することは、前記スマートカードを用いた１つまたは複数の暗号動作に使用する前記暗号サービスプロバイダを識別する情報と同じファイルに前記代替識別子を記憶することを含む、請求項１９に記載の１つまたは複数の非一時的コンピュータ可読媒体。

Images