JP6121049B2 - プロキシを使用したリソースへの安全なアクセス - Google Patents

Description

本明細書に説明する本発明の各態様は大略的に、クライアントデバイスがプロキシデバイスを使用して安全にリソースにアクセスするためのアプローチを提供する方法およびデバイスに関するものである。

従来、公衆ネットワークに接続されているクライアントデバイスは、仮想プライベートネットワーク（ＶＰＮ）を使用してプライベートネットワークにつながっている。ＶＰＮにおいて、プロキシデバイスは、単純に透明なパイプとして機能し、クライアントデバイスとプライベートネットワークとの間に必要な接続を提供する。

従来のＶＰＮには様々な問題が存在する。第一に、クライアントデバイスはプライベートネットワークのリソースに直接アクセスできるため、クライアントデバイスに対して大きな信用が課される。第二に、クライアントデバイスはリソースおよび／またはプライベートネットワークの通信プロトコルのために構成されなければならない。第三に、プロキシデバイスはクライアントデバイスの活動（activity）を制御または監視できない。

以下に、本明細書に説明する様々な発明の態様の簡単な概要を提示する。本概要は広範な全体像ではなく重要なもしくは欠かせない要素を特定すること、または特許請求の範囲を正確に説明することを意図していない。以下の概要は、以下に記載するより詳細な説明の導入として、単にいくつかの概念を簡単な形で提示するにすぎない。

上述の先行技術の制約を克服し、本明細書の読解によって明らかになるであろう他の制約を克服するために、本明細書に説明する本発明の態様は、プロキシデバイスでクライアントデバイスからリソースに対する要求を受信するステップと、プロキシデバイスからリソース管理デバイスへ、リソースに対する要求を送信するステップとを含む方法を実行するように構成されたシステム、装置、および／またはコンピュータ可読媒体を指向する。

プロキシデバイスとリソース管理デバイスとの間に認証セッションを開始してもよい。プロキシデバイスはクライアントデバイスに対して署名提供の要求を生成してもよく、クライアントデバイスに対する署名提供の要求は（１）プロキシデバイスとリソース管理デバイスとの間で事前に交換した認証情報および（２）プロキシデバイスからリソース管理デバイスへ送信されるべき認証情報のうち少なくとも１つのデータ構造を識別するコンテキスト情報を含んでいてもよい。プロキシデバイスは、クライアントデバイスがコンテキスト情報を検証した場合などに、クライアントデバイスから署名を受信してもよい。署名はクライアントデバイスにおいてスマートカードから提供されてもよい。プロキシデバイスは署名をリソース管理デバイスへ送信してもよい。

いくつかの実施形態では、方法はさらに、認証セッション開始後に、プロキシデバイスにおいてクライアントデバイスからクライアントデバイスが利用できるセキュリティ証明書のリストを受信するステップを含んでいてもよい。認証セッションのためのセキュリティ証明書を選択してもよい。さらに、クライアントデバイスに対する署名提供の要求は選択されたセキュリティ証明書の識別を含んでいてもよい。

方法はさらに、リソース管理デバイスへの署名の送信後に、プロキシデバイスにおいて署名に対応するセッション鍵を受信するステップを含んでいてもよい。プロキシデバイスはセッション鍵を使用してリソース管理デバイスから要求されたリソースを取得してもよい。プロキシデバイスは要求されたリソースをクライアントデバイスへ送信してもよい。

いくつかの態様では、認証セッションはＳＳＬ認証を含んでもよく、データ構造を識別するコンテキスト情報は認証セッション中にプロキシデバイスとリソース管理デバイスとの間で事前に交換されたＳＳＬ認証メッセージを含んでいてもよい。他の態様では、認証セッションはケルベロス認証を含んでもよく、データ構造を識別するコンテキスト情報はケルベロスデータ構造を識別する情報を含んでいてもよい。たとえば、ケルベロスデータ構造は抽象構文記法１を含んでいてもよい。さらに／あるいは（additionally or alternatively）、データ構造を識別するコンテキスト情報は、ケルベロス認証のために使用されるケルベロス・ドメイン、クライアントデバイスと関連付けられたケルベロス主体名、認証セッションのために使用される鍵配信センターの識別子、要求されたチケットの有効期間、および認証セッション中に設定されたケルベロスフラグのうちの少なくとも１つを含んでいてもよい。

いくつかの実施形態では、コンテキスト情報は認証セッションと関連付けられたタイムスタンプを識別してもよい。さらに／あるいは、コンテキスト情報は認証セッションのプロトコルタイプを識別してもよい。

ある態様においては、プロキシデバイスは、プロセッサと、プロセッサによって実行されるとプロキシデバイスに上記の方法のステップを実行させるコンピュータ実行可能な命令を格納するメモリとを含む。

システム、装置および／またはコンピュータ可読媒体は、クライアントデバイスからプロキシデバイスへ、リソースに対する要求を送信するステップを含む方法を実行するように構成されていてもよい。クライアントデバイスは、プロキシデバイスから、クライアントデバイスに対する署名提供の要求を受信してもよい。クライアントデバイスに対する署名提供の要求は、（１）プロキシデバイスと要求されたリソースと関連付けられたリソース管理デバイスとの間で事前に交換された認証情報および（２）プロキシデバイスによってリソース管理デバイスへ送信されるべき認証情報のうちの少なくとも１つのデータ構造を識別するコンテキスト情報を含んでいてもよい。

クライアントデバイスはデータ構造を検証してもよく、データ構造の検証に応答してクライアントデバイスはプロキシデバイスへセキュリティ証明書に対応する署名を送信してもよい。セキュリティ証明書はクライアントデバイスに接続されたスマートカードに格納されてもよい。

方法はさらに、要求に応答して、クライアントデバイスからプロキシデバイスへ、クライアントデバイスが利用可能な１つ以上のセキュリティ証明書を含むリストを送信するステップを含んでいてもよい。受信されたクライアントデバイスに対する署名提供の要求は、１つ以上のセキュリティ証明書を含むリストから選択されたセキュリティ証明書の識別を含んでいてもよい。

以上および追加の態様は、以下のさらに詳細に述べる開示によって十分理解されるであろう。

本発明の１つ以上の実施形態に従って使用されるコンピュータシステムのアーキテクチャを示す図である。 リモートアクセスシステムのアーキテクチャを示す図である。 仮想（ハイパーバイザー）システムのアーキテクチャを示す図である。 クラウドベースのシステムのアーキテクチャを示す図である。 企業モビリティ管理システムを示す図である。 別の企業モビリティ管理システムを示す図である。 クライアント、プロキシ、リソースおよび／または認証サービスを有するシステムを示す図である。 クライアントおよびプロキシの詳細を示す図である。 認証のためおよび／またはプロキシを使用してリソースへの安全なアクセスを提供するための方法の各ステップを示すフローチャートである。 認証のためおよび／またはプロキシを使用してリソースへの安全なアクセスを提供するための別の方法の各ステップを示すフローチャートである。 認証のためおよび／またはプロキシを使用してリソースへの安全なアクセスを提供するためのさらに別の方法の各ステップを示すフローチャートである。

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

上述のとおり特定され、本明細書の一部をなし、例示により本明細書で説明する本発明の各態様を実施するための様々な実施形態を、添付の図面を参照しながら説明する。本明細書で説明する範囲を逸脱することなく、他の実施形態を利用し、構造および機能に変更を加えてもよいことは理解されるべきである。本発明の各態様は他の実施形態が可能であり、様々な異なる方法で実施または実行することが可能である。

以下詳細に説明する主題の概要紹介として、本明細書で説明する実施の形態は、モバイルコンピューティングデバイスの管理対象モバイルアプリケーションを使用して、企業コンピューティングシステムのリソースへのリモートアクセスを制御することを指向する。

アクセスマネージャは、企業リソースへのアクセスを要求するモバイルアプリケーションが正確に特定され、モバイルコンピューティングデバイスへのインストール後に改変されていないかどうかを判定する検証プロセスを行う。このように、アクセスマネージャは企業リソースへのアクセスを要求するモバイルアプリケーションが信頼でき、その企業リソースを保護するために使用されるセキュリティメカニズムを回避しようとしていないことを保証する。その結果、企業に関連する個人は、自分の私用モバイルデバイスで企業リソースを有利に利用できる。

本明細書で使用される表現および用語は、説明目的であり、制限と見なしてはならないことは理解されるべきである。むしろ、本明細書で使用される表現および用語には、そのもっとも広い解釈および意味が与えられるべきである。「含み」および「備え」ならびにその変形の使用は、これ以降で挙げられるアイテムおよびその等価物ならびに追加アイテムおよびその等価物を包含することが意図されている。「取り付けられている」、「接続されている」、「連結されている」、「位置付けられている」、「係合されている」および同様な用語の使用は、直接的および間接的の両方の取り付け、接続、連結、位置付けおよび係合を含むことが意図されている。

〈コンピューティングアーキテクチャ〉
コンピュータのソフトウェア、ハードウェアおよびネットワークは、特に、スタンドアロン、ネットワーク化、リモートアクセス（別称、リモートデスクトップ）、仮想化および／またはクラウドベースの環境を含め、多様な異なるシステム環境で利用される。

図１は、本明細書で説明する１つ以上の態様を、スタンドアロンおよび／またはネットワーク環境で実装するために使用される、システムアーキテクチャならびにデータ処理装置の一実施例を示す。

様々なネットワークノード１０３，１０５，１０７および１０９は、インターネットなどの広域ネットワーク（ＷＡＮ）１０１を介して相互接続されている。プライベートイントラネット、企業ネットワーク、ＬＡＮ、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイヤレスネットワーク、パーソナルネットワーク（ＰＡＮ）等を含む、他のネットワークもまた、または代わりに使用してもよい。ネットワーク１０１は例示目的であり、より少ないか、または追加のコンピュータネットワークと取り替えてもよい。ローカルエリアネットワーク（ＬＡＮ）はあらゆる周知のＬＡＮトポロジーのうちの１つ以上を有しており、イーサーネットなどの多様な異なるプロトコルのうちの１つ以上を使用する。デバイス１０３，１０５，１０７，１０９および他のデバイス（図示せず）は、撚り対線、同軸ケーブル、光ファイバ、電波または他の通信媒体を介してネットワークのうちの１つ以上に接続している。

本明細書で使用し、図面に図示する用語「ネットワーク」とは、遠隔記憶装置が１つ以上の通信パスを介して互いに連結されているシステムだけではなく、記憶容量を有する当該システムにそのときどきで連結してもよいスタンドアロンデバイスのことも含む。そのため、「ネットワーク」とは、「物理的ネットワーク」だけでなく、すべての物理的ネットワークに常駐する（単一のエンティティに帰属する）データから構成される「コンテンツネットワーク」をも含む。

コンポーネントは、データサーバ１０３、ウェブサーバ１０５およびクライアントコンピュータ１０７，１０９を含んでいる。データサーバ１０３は、本明細書で説明する１つ以上の態様を行うために、データベースおよび制御ソフトウェアの全体的なアクセス、制御および管理（administration）を提供する。

データサーバ１０３はウェブサーバ１０５に接続されていてもよく、それによりユーザは必要なデータとやりとりし、必要なデータを取得する。あるいは、データサーバ１０３はウェブサーバ自体として作動してもよく、インターネットに直接接続してもよい。データサーバ１０３は、直接もしくは間接的な接続を介して、または何らかの他のネットワークを介して、ネットワーク１０１（たとえば、インターネット）経由でウェブサーバ１０５に接続されていてもよい。

ユーザはリモートコンピュータ１０７，１０９を使用して、たとえばウェブサーバ１０５がホストする１つ以上の外部に露出するウェブサイトを介してデータサーバ１０３に接続するためのウェブブラウザを使用して、データサーバ１０３とやりとりする。クライアントコンピュータ１０７，１０９はデータサーバ１０３とともに使用されて、そこに格納されているデータにアクセスしてもよく、または他の目的で使用されてもよい。たとえばユーザは、クライアントデバイス１０７から、当該技術分野で周知のインターネットブラウザを使用して、またはコンピュータネットワーク（インターネットなど）上でウェブサーバ１０５および／またはデータサーバ１０３と通信するソフトウェア・アプリケーションを実行することにより、ウェブサーバ１０５にアクセスしてもよい。

サーバおよびアプリケーションは同じ物理マシン上に組み合わされて、個別の仮想アドレスもしくは論理アドレスを保持してもよく、または個別の物理マシンに常駐していてもよい。

図１は、使用され得るネットワークアーキテクチャのほんの一実施例を示しており、当業者は、使用される特定のネットワークアーキテクチャおよびデータ処理装置を変更してもよいこと、ならびに、本明細書で詳細に説明するように、それが提供する機能に対して二次的なものであることを認識するであろう。たとえば、ウェブサーバ１０５およびデータサーバ１０３が提供するサービスは単一のサーバに結合されてもよい。

各コンポーネント１０３，１０５，１０７，１０９は、あらゆるタイプの周知のコンピュータ、サーバまたはデータ処理装置であってもよい。たとえば、データサーバ１０３はレートサーバ１０３のオペレーション全体を制御するプロセッサ１１１を含んでいてもよい。データサーバ１０３は、ＲＡＭ１１３、ＲＯＭ１１５、ネットワークインターフェース１１７、入出力インターフェース１１９（たとえば、キーボード、マウス、ディスプレイ、プリンタ等）およびメモリ１２１をさらに含んでいてもよい。

Ｉ／Ｏ１１９は、データまたはファイルを読み込み、書き込み、表示し、および／または印刷する多様なインターフェースユニットおよびドライブを含んでいてもよい。メモリ１２１はデータ処理装置１０３、本明細書で説明する態様を行うようデータサーバ１０３に指図する制御ロジック１２５、ならびに本明細書で説明する態様と合わせて使用してもしなくてもよい二次的、サポートおよび／または他の機能を提供する他のアプリケーションソフトウェア１２７のオペレーション全体を制御するオペレーティングシステム・ソフトウェア１２３をさらに格納していてもよい。

制御ロジックは本明細書ではデータサーバソフトウェア１２５ともいう。データサーバソフトウェアの機能は、制御ロジックに符号化され、システムに入力を提供するユーザによって手動で作成されるルールに基づいて自動的に行われるオペレーションもしくは決定、および／またはユーザ入力（たとえば、問合わせ、データのアップデート等）に基づく自動処理の組合せをいう。

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

１つ以上の態様は、１つ以上のプログラムモジュールなど、１つ以上のコンピュータまたは本明細書で説明される他のデバイスによって実行されるコンピュータで使用可能な、もしくは読取可能なデータおよび／またはコンピュータ実行可能命令に具現されてもよい。

一般に、プログラムモジュールは、コンピュータまたは他のデバイス内のプロセッサによって実行されるとき、特定のタスクを行うかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含んでいる。モジュールは実行のために後でコンパイルされるソースコードプログラミング言語で書き込んでもよく、またはＨＴＭＬもしくはＸＭＬなどの（ただし、これだけに限定されない）スクリプト言語で書き込んでもよい。コンピュータ実行可能命令は、不揮発性記憶装置などのコンピュータ読取可能媒体に格納されていてもよい。ハードディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶装置、および／またはそのあらゆる組合せを含め、あらゆる適したコンピュータ読取可能記憶媒体を利用してもよい。さらに、本明細書で説明するデータまたはイベントを表す様々な伝送（非記憶）媒体は、金属ワイヤ、光ファイバ、ならびに／またはワイヤレス伝送媒体（たとえば、空気および／もしくは空間）など、信号伝達媒体を通して移動する電磁波の形で、送信元と宛先との間を転送してもよい。

本明細書で説明する様々な態様は、方法、データ処理システム、またはコンピュータプログラム製品として具現される。そのため、様々な機能は、集積回路、フィールドプログラマブル・ゲートアレイ（ＦＰＧＡ）等といった、ソフトウェア、ファームウェアおよび／またはハードウェアもしくはハードウェア等価物に全部または一部具現化されてもよい。本明細書で説明する１つ以上の態様をより効果的に実装するために特定のデータ構造を使用してもよく、当該データ構造は本明細書で説明されるコンピュータ実行可能命令およびコンピュータ使用可能データの範囲内に含まれる。

図２をさらに参照して、本明細書で説明する１つ以上の態様はリモートアクセス環境に実装されている。図２は、本明細書で説明する１つ以上の態様に従って使用されるコンピューティング環境２００の汎用コンピューティングデバイス２０１を含むシステムアーキテクチャを示す。

汎用コンピューティングデバイス２０１は、クライアントアクセスデバイスに仮想マシンを提供するように構成されている単一サーバまたはマルチサーバのデスクトップ仮想化システム（たとえば、リモートアクセスもしくはクラウドシステム）内のサーバ２０６ａとして使用されてもよい。汎用コンピューティングデバイス２０１は、ランダムアクセスメモリ（ＲＡＭ）２０５、読取専用メモリ（ＲＯＭ）２０７、入出力（Ｉ／Ｏ）モジュール２０９およびメモリ２１５を含め、サーバおよびその関連コンポーネントのオペレーション全体を制御するプロセッサ２０３を有していてもよい。

Ｉ／Ｏモジュール２０９は、汎用コンピューティングデバイス２０１のユーザが入力を提供するマウス、キーパッド、タッチスクリーン、スキャナ、光学リーダ、および／またはスタイラス（もしくは他の入力デバイス）を含んでいてもよく、また音声出力を提供するスピーカと、テキスト、オーディオビジュアルおよび／またはグラフィカル出力を提供するビデオディスプレイデバイスとのうちの１つ以上を含んでいてもよい。

ソフトウェアはメモリ２１５および／または他のストレージ内に格納され、本明細書で説明する様々な機能を実施するために汎用コンピューティングデバイス２０１を専用コンピューティングデバイスに構成する命令をプロセッサ２０３に与える。たとえば、メモリ２１５は、オペレーティングシステム２１７、アプリケーション・プログラム２１９および関連データベース２２１など、コンピューティングデバイス２０１が使用するソフトウェアを格納していてもよい。

コンピューティングデバイス２０１は、端末２４０（クライアントデバイスともいう）などの１つ以上のリモートコンピュータへの接続をサポートするネットワーク化環境で動作してもよい。端末２４０は、汎用コンピューティングデバイス１０３もしくは２０１に関して上述した要素の多くもしくはすべてを含むパーソナルコンピュータ、モバイルデバイス、ラップトップコンピュータ、タブレット、またはサーバであってもよい。

図２に図示するネットワーク接続はローカルエリアネットワーク（ＬＡＮ）２２５および広域ネットワーク（ＷＡＮ）２２９を含むが、他のネットワークを含んでいてもよい。ＬＡＮネットワーク化環境で使用される場合、コンピューティングデバイス２０１はネットワークインターフェースまたはアダプタ２２３経由でＬＡＮ２２５に接続してもよい。ＷＡＮネットワーク化環境で使用される場合、コンピューティングデバイス２０１は、コンピュータネットワーク２３０（たとえば、インターネット）など、ＷＡＮ２２９上で通信を確立するモデム２２７または他の広域ネットワークインターフェースを含んでいてもよい。

図示するネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段も使用してもよいことは認識されるであろう。コンピューティングデバイス２０１および／または端末２４０は、バッテリ、スピーカおよびアンテナ（図示せず）などの様々な他のコンポーネントを含めて、モバイル端末（たとえば、携帯電話、スマートフォン、ＰＤＡ、ノートブック等）であってもよい。

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

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

クライアントマシン２４０は、いくつかの実施形態では、単一クライアントマシン２４０またはクライアントマシンの単一グループ２４０と称されることがあり、サーバ２０６は単一サーバ２０６またはサーバの単一グループ２０６と称されることがある。一実施形態では、単一クライアントマシン２４０は２つ以上のサーバ２０６と通信し、別の実施形態では単一サーバ２０６は２つ以上のクライアントマシン２４０と通信する。さらに別の実施形態では、単一クライアントマシン２４０は単一サーバ２０６と通信する。

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

一実施形態では、クライアントマシン２４０は仮想マシンであってもよい。仮想マシンはあらゆる仮想マシンであってもよいが、いくつかの実施形態では、仮想マシンはタイプ１またはタイプ２のハイパーバイザ、たとえば、サイトリックス・システムズ、ＩＢＭ、ヴイエムウェアによって開発されるハイパーバイザ、またはあらゆる他のハイパーバイザによって管理されるあらゆる仮想マシンであってもよい。いくつかの態様において、仮想マシンはハイパーバイザによって管理してもよいが、いくつかの態様では、仮想マシンはサーバ２０６上で実行するハイパーバイザまたはクライアント２４０上で実行するハイパーバイザによって管理してもよい。

いくつかの実施形態は、サーバ２０６または遠隔設置された他のマシン上で遠隔実行するアプリケーションによって生成されるアプリケーション出力を表示するクライアントデバイス２４０を含む。これらの実施形態では、クライアントデバイス２４０は仮想マシンのクライアントエージェントプログラムまたはアプリケーションを実行して、アプリケーションウインドウ、ブラウザ、または他の出力ウインドウに出力を表示してもよい。

ある実施例では、アプリケーションはデスクトップであるが、他の実施例では、アプリケーションはデスクトップを生成または提示するアプリケーションである。デスクトップは、ローカルおよび／またはリモート・アプリケーションを統合することのできるオペレーティングシステムのインスタンスにユーザインターフェースを提供するグラフィカルシェルを含んでいてもよい。本明細書で使用するアプリケーションとは、オペレーティングシステム（および、任意で、デスクトップも）のインスタンスがロードされた後に実行するプログラムである。

サーバ２０６は、いくつかの実施形態では、クライアント上で実行するシンクライアントまたはリモートディスプレイ・アプリケーションにデータを送信するリモートプレゼンテーション・プロトコルまたは他のプロトコルを使用して、サーバ２０６上で実行するアプリケーションによって生成されるディスプレイ出力を提示する。シンクライアントまたはリモートディスプレイ・プロトコルは、次の非網羅的なプロトコルリストのうちのいずれか１つとすることができる。すなわち、フロリダ州フォート・ローダーデールのサイトリックス・システムズ・インクが開発したインディペンデント・コンピューティング・アーキテクチャ（ＩＣＡ）プロトコル、またはワシントン州レドモンドのマイクロソフト・コーポレーションが製造するリモートデスクトッププロトコル（ＲＤＰ）。

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

いくつかの実施形態では、サーバファームは、実質的に同じようなタイプのオペレーティングシステムのプラットフォーム（例、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、ｉＯＳ、ＡＮＤＲＯＩＤ（登録商標）、ＳＹＭＢＩＡＮ等）を実行するサーバ２０６を含んでいてもよい。他の実施形態では、サーバファーム２０６は、第１タイプのオペレーティングシステムのプラットフォームを実行する１つ以上のサーバからなる第１グループと、第２タイプのオペレーティングシステムのプラットフォームを実行する１つ以上のサーバからなる第２グループとを含んでいてもよい。

サーバ２０６は、必要なあらゆるタイプのサーバとして、たとえば、ファイルサーバ、アプリケーションサーバ、ウェブサーバ、プロキシサーバ、アプライアンス、ネットワーク・アプライアンス、ゲートウェイ、アプリケーション・ゲートウェイ、ゲートウェイサーバ、仮想化サーバ、デプロイメントサーバ、ＳＳＬ ＶＰＮサーバ、ファイヤウォール、ウェブサーバ、アプリケーションサーバ、またはマスターアプリケーションサーバ、アクティブディレクトリを実行するサーバ、またはファイヤウォール機能、アプリケーション機能、もしくは負荷分散機能を提供するアプリケーション高速化プログラムを実行するサーバとして構成されていてもよい。他のサーバのタイプも使用してもよい。

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

図２は、デスクトップ仮想化システムの高レベルアーキテクチャを示す。図示するように、デスクトップ仮想化システムは、１つ以上のクライアントアクセスデバイス２４０に仮想デスクトップおよび／または仮想アプリケーションを提供するように構成されている少なくとも１つの仮想化サーバ２０６を含め、単一サーバもしくはマルチサーバシステムまたはクラウドシステムであってもよい。

本明細書で使用されるデスクトップとは、１つ以上のアプリケーションをホストおよび／または実行してもよいグラフィカル環境またはスペースをいう。デスクトップは、ローカルおよび／またはリモート・アプリケーションを統合することのできるオペレーティングシステムのインスタンスにユーザインターフェースを提供するグラフィカルシェルを含んでいてもよい。アプリケーションは、オペレーティングシステムのインスタンス（および、任意でデスクトップも）をロードした後に実行するプログラムを含んでいてもよい。オペレーティングシステムのインスタンスは物理的（たとえば、１デバイスにつき１つのオペレーティングシステム）または仮想的（たとえば、単一デバイス上で稼動するＯＳの多くのインスタンス）であってもよい。各アプリケーションはローカルデバイス上で実行してもよく、または遠隔設置されたデバイス上で実行（たとえば、遠隔操作）してもよい。

図３をさらに参照すると、コンピュータデバイス３０１は、仮想化環境の仮想化サーバとして、たとえば、単一サーバ、マルチサーバ、またはクラウドコンピューティング環境として構成されていてもよい。

図３に図示する仮想化サーバ３０１は、図２に図示するサーバ２０６の１つ以上の実施形態もしくは他の周知のコンピューティングデバイスとしてデプロイ（deploy）することができ、および／またはそれにより実装することができる。

仮想化サーバ３０１に含まれるのが、１つ以上の物理的ディスク３０４、１つ以上の物理的デバイス３０６、１つ以上の物理的プロセッサ３０８および１つ以上の物理的メモリ３１６を含むことができるハードウェアレイヤである。いくつかの実施形態では、ファームウェア３１２を物理的メモリ３１６のメモリ素子内に格納することができ、物理的プロセッサ３０８のうちの１つ以上によって実行することができる。仮想化サーバ３０１はさらに物理的メモリ３１６のメモリ素子内に格納されて、物理的プロセッサ３０８のうちの１つ以上によって実行されてもよいオペレーティングシステム３１４をさらに含んでいてもよい。さらに、ハイパーバイザ３０２を物理的メモリ３１６のメモリ素子内に格納してもよく、物理的プロセッサ３０８のうちの１つ以上によって実行することができる。

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

仮想化サーバ３０１は、仮想化サーバ３０１と通信する１つ以上のハードウェアを備えるハードウェアレイヤ３１０を含んでいてもよい。いくつかの実施形態では、ハードウェアレイヤ３１０は、１つ以上の物理的ディスク３０４、１つ以上の物理的デバイス３０６、１つ以上の物理的プロセッサ３０８、および１つ以上のメモリ２１６を含むことができる。物理的コンポーネント３０４，３０６，３０８および３１６は、たとえば、上述したコンポーネントのいずれを含んでいてもよい。

物理的デバイス３０６は、たとえば、ネットワーク・インターフェース・カード、ビデオカード、キーボード、マウス、入力デバイス、モニタ、ディスプレイデバイス、スピーカ、光学ドライブ、記憶装置、ユニバーサルシリアルバス接続、プリンタ、スキャナ、ネットワーク素子（たとえば、ルータ、ファイヤウォール、ネットワークアドレス変換器、ロードバランサ、仮想プライベートネットワーク（ＶＰＮ）ゲートウェイ、ダイナミック・ホスト・コンフィギュレーション・プロトコル（ＤＨＣＰ）ルータ等）、または仮想化サーバ３０１に接続されているかもしくは仮想化サーバ３０１と通信するあらゆるデバイスを含んでいてもよい。ハードウェアレイヤ３１０の物理的メモリ３１６はあらゆるタイプのメモリを含んでいてもよい。物理的メモリ３１６はデータを格納してもよく、いくつかの実施形態では、１つ以上のプログラム、または実行可能命令のセットを格納してもよい。

図３は、仮想化サーバ３０１の物理的メモリ３１６内にファームウェア３１２が格納されている実施形態を示す。物理的メモリ３１６に格納されているプログラムまたは実行可能命令は、仮想化サーバ３０１の１つ以上のプロセッサ３０８によって実行することができる。

仮想化サーバ３０１はハイパーバイザ３０２も含んでいてもよい。いくつかの実施形態では、ハイパーバイザ３０２は仮想化サーバ３０１のプロセッサ３０８によって実行されて、あらゆる数の仮想マシン３３２を作成して管理するプログラムであってもよい。ハイパーバイザ３０２は仮想マシンモニタ、またはプラットフォーム仮想化ソフトウェアと称されることもある。いくつかの実施形態では、ハイパーバイザ３０２は実行可能命令と、コンピューティングマシン上で実行する仮想マシンを監視するハードウェアとのあらゆる組合せとすることができる。ハイパーバイザ３０２はタイプ２ハイパーバイザであってもよく、当該ハイパーバイザは仮想化サーバ３０１上で実行するオペレーティングシステム３１４内で実行する。それから、仮想マシンはハイパーバイザより上のレベルで実行する。

いくつかの実施形態では、タイプ２ハイパーバイザは、タイプ２ハイパーバイザがユーザのオペレーティングシステムとやりとりするように、ユーザのオペレーティングシステムのコンテキスト内で実行する。他の実施形態では、仮想化環境内の１つ以上の仮想化サーバ２０１は、代わりにタイプ１ハイパーバイザ（図示せず）を含んでいてもよい。タイプ１ハイパーバイザは、ハードウェアレイヤ３１０内のハードウェアおよびリソースに直接アクセスすることによって、仮想化サーバ３０１上で実行してもよい。すなわち、タイプ２ハイパーバイザ３０２は図示するようにホストオペレーティングシステム３１４経由でシステムのリソースにアクセスするのに対し、タイプ１ハイパーバイザはホストオペレーティングシステム３１４がなくてもすべてのシステムのリソースに直接アクセスしてもよい。タイプ１ハイパーバイザは仮想化サーバ３０１の１つ以上の物理的プロセッサ３０８上で直接実行してもよく、物理的メモリ３１６に格納されているプログラムデータを含んでいてもよい。

いくつかの実施形態では、ハイパーバイザ３０２はオペレーティングシステム３３０または仮想マシン３３２上で実行する制御プログラム３２０に、システムのリソースに直接アクセスできるオペレーティングシステム３３０または制御プログラム３２０をシミュレートするいずれの方法でも仮想リソースを提供することができる。

システムのリソースは、物理的デバイス３０６、物理的ディスク３０４、物理的プロセッサ３０８、物理的メモリ３１６および仮想化サーバ３０１のハードウェアレイヤ３１０に含まれているあらゆる他のコンポーネントを含むことができるが、これだけに限定されない。ハイパーバイザ３０２を使用して、仮想ハードウェアをエミュレートし、物理的ハードウェアを分割し、物理的ハードウェアを仮想化し、および／またはコンピューティング環境へのアクセスを提供する仮想マシンを実行してもよい。さらに他の実施形態では、ハイパーバイザ３０２は仮想化サーバ３０１上で実行する仮想マシン３３２のプロセッサのスケジューリングおよびメモリの分割を制御する。

ハイパーバイザ３０２はカリフォルニア州パロアルトのヴイエムウェア・インクが製造するもの、オープンソースのＸｅｎ．ｏｒｇコミュニティが開発を監督するオープンソース製品のＸＥＮハイパーバイザ、マイクロソフトが提供するＨｙｐｅｒＶ、ＶｉｒｔｕａｌＳｅｒｖｅｒまたは仮想ＰＣハイパーバイザ、または他のものを含んでいてもよい。いくつかの実施形態では、仮想化サーバ３０１は、その上でゲストオペレーティングシステムが実行してもよい仮想マシンプラットフォームを作成するハイパーバイザ３０２を実行する。これらの実施形態では、仮想化サーバ３０１はホストサーバと称されることがある。このような仮想化サーバの一例が、フロリダ州フォート・ローダーデールのサイトリックス・システムズ・インクが提供するＸＥＮ ＳＥＲＶＥＲである。

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

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

図３に図示するように、仮想化サーバ３０１は１つ以上の仮想マシン３３２をホストまたは実行してもよい。仮想マシン３３２は、プロセッサ３０８によって実行されるとき、仮想マシン３３２が物理的コンピューティングデバイスと同様にプログラムおよびプロセスを実行することができるように、物理的コンピュータの動作を模倣する実行可能命令のセットである。図３は仮想化サーバ３０１が３つの仮想マシン３３２をホストする実施形態を示しているが、他の実施形態では、仮想化サーバ３０１はあらゆる数の仮想マシン３３２をホストすることができる。

いくつかの実施形態では、ハイパーバイザ３０２は各仮想マシン３３２に、その仮想マシン３３２に利用できる物理的ハードウェア、メモリ、プロセッサおよび他のシステム・リソースの固有の仮想ビューを提供する。いくつかの実施形態では、固有の仮想ビューは、仮想マシンの許可、１つ以上の仮想マシン識別子へのポリシーエンジンの適用、仮想マシンにアクセスするユーザ、仮想マシン上で実行するアプリケーション、仮想マシンによってアクセスされるネットワーク、または他の所望の基準に基づくことができる。たとえば、ハイパーバイザ３０２は１つ以上のセキュリティ保護されていない仮想マシン３３２と、１つ以上のセキュリティ保護された仮想マシン３３２とを作成してもよい。セキュリティ保護されていない仮想マシン３３２には、セキュリティ保護された仮想マシン３３２がアクセスを許可されるリソース、ハードウェア、メモリ場所およびプログラムを禁止してもよい。他の実施形態では、ハイパーバイザ３０２は各仮想マシン３３２に、仮想マシン３３２に利用できる物理的ハードウェア、メモリ、プロセッサおよび他のシステム・リソースの実質的に同様な仮想ビューを提供してもよい。

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

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

図４をさらに参照すると、本明細書で説明するいくつかの態様は、クラウドベースの環境に実装される。図４はクラウドコンピューティング環境（またはクラウドシステム）４００の実施例を示す。図４から分かるように、クライアントコンピュータ４１１〜４１４はクラウド管理サーバ４１０と通信して、クラウドシステムのコンピューティングリソース（たとえば、ホストサーバ４０３、ストレージリソース４０４およびネットワークリソース４０５）にアクセスしてもよい。

管理サーバ４１０は１つ以上の物理的サーバ上に実装してもよい。管理サーバ４１０は、たとえば、特にフロリダ州フォート・ローダーデールのサイトリックス・システムズ・インクのＣＬＯＵＤＳＴＡＣＫ、またはＯＰＥＮＳＴＡＣＫを稼動してもよい。管理サーバ４１０は、たとえば、ホストコンピュータ４０３、データ記憶装置４０４およびネットワーキングデバイス４０５など、クラウド・ハードウェアおよびソフトウェア・リソースを含め、様々なコンピューティングリソースを管理してもよい。クラウド・ハードウェアおよびソフトウェア・リソースは非公開および／または公開コンポーネントを含んでいてもよい。たとえば、クラウドは１つ以上の特定のカスタマもしくはクライアントコンピュータ４１１〜４１４によって、および／またはプライベートネットワーク上で使用されるプライベートクラウドとして構成していてもよい。他の実施形態では、パブリッククラウドまたはハイブリッドパブリック−プライベートクラウドが、オープンまたはハイブリッドネットワーク上で他のカスタマによって使用されてもよい。

管理サーバ４１０は、クラウドオペレータおよびクラウドカスタマがクラウドシステムとやりとりしてもよいユーザインターフェースを提供するように構成されていてもよい。たとえば、管理サーバ４１０はユーザインターフェースにＡＰＩのセットおよび／または１つ以上のクラウドオペレータコンソール・アプリケーション（たとえば、ウェブベースのスタンドアロンアプリケーション）を提供して、クラウドオペレータがクラウドリソースを管理し、仮想化レイヤを構成し、カスタマアカウントを管理し、他のクラウド管理タスクを行うことができるようにしてもよい。

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

たとえば、一定のクライアント４１１〜４１４は、同じエンドユーザ、または同じ会社もしくは組織に属する異なるユーザの代わりに仮想マシンを作成する異なるクライアントコンピュータに関連付けられてもよい。他の実施例では、一定のクライアント４１１〜４１４は、異なる会社もしくは組織に属するユーザなどに関連付けられていなくてもよい。関連付けられていないクライアントに対して、いずれかのユーザの仮想マシンまたはストレージ上の情報を他のユーザから隠してもよい。

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

管理サーバ４１０はユーザの要求に応答してもよく、ゾーン４０１またはゾーン４０２のリソースを使用して仮想マシンが作成されたかどうかをユーザが知ることなく、仮想マシンを作成するためにリソースを割り当ててもよい。他の実施例では、クラウドシステムは、エンドユーザが特定のゾーンまたはゾーン内の特定のリソース４０３〜４０５に仮想マシン（または他のクラウドリソース）を割り当てるよう要求できるようにしてもよい。

この実施例では、各ゾーン４０１〜４０２は様々な物理的ハードウェアコンポーネント（またはコンピューティングリソース）４０３〜４０５の配列、たとえば、物理的ホスティングリソース（またはプロセッシングリソース）、物理的ネットワークリソース、物理的ストレージリソース、スイッチ、および、カスタマにクラウドコンピューティングサービスを提供するために使用してもよい追加のハードウェアリソースを含んでいてもよい。

クラウドゾーン４０１〜４０２の物理的ホスティングリソースは、上述した仮想化サーバ３０１など、仮想マシンのインスタンスを作成しホストするように構成されていてもよい１つ以上のコンピュータサーバ４０３を含んでいてもよい。クラウドゾーン４０１または４０２の物理的ネットワークリソースは、ファイヤウォール、ネットワークアドレス変換器、ロードバランサ、仮想プライベートネットワーク（ＶＰＮ）ゲートウェイ、ダイナミック・ホスト・コンフィギュレーション・プロトコル（ＤＨＣＰ）ルータ等といった、クラウドカスタマにネットワークサービスを提供するように構成されているハードウェアおよび／またはソフトウェアを備える１つ以上のネットワーク素子４０５（たとえば、ネットワークサービスプロバイダ）を含んでいてもよい。クラウドゾーン４０１〜４０２のストレージリソースは、ストレージディスク（たとえば、ソリッドステートドライブ（ＳＳＤ）、磁気ハードディスク等）および他の記憶装置を含んでいてもよい。

図４に図示するクラウドコンピューティング環境は、クラウドの物理的リソースを使用して仮想マシンを作成して管理し、カスタマに他のサービスを提供するように構成されている追加のハードウェアおよび／またはソフトウェア・リソースを備える仮想化レイヤ（たとえば、図１〜図３に図示するもの）も含んでいてもよい。

仮想化レイヤは、ネットワーク仮想化、ストレージ仮想化等を提供する他のコンポーネントとともに、上述の図３で説明したハイパーバイザを含んでいてもよい。仮想化レイヤは物理的リソースレイヤとは別のレイヤとしてもよく、または物理的リソースレイヤと同じハードウェアおよび／もしくはソフトウェア・リソースのいくつかもしくはすべてを共有していてもよい。たとえば、仮想化レイヤは物理的コンピューティングリソースを有する仮想化サーバ４０３のそれぞれにインストールされているハイパーバイザを含んでいてもよい。あるいは、たとえば、ＷＩＮＤＯＷＳ（登録商標） ＡＺＵＲＥ（ワシントン州レドモンドのマイクロソフト・コーポレーション）、ＡＭＡＺＯＮ ＥＣ２（ワシントン州シアトルのアマゾン・ドット・コム・インク）、ＩＢＭ ＢＬＵＥ ＣＬＯＵＤ（ニューヨーク州アーモンクのＩＢＭコーポレーション）、または他のものなど、周知のクラウドシステムを使用してもよい。

〈企業モビリティ管理アーキテクチャ〉
図５は、ＢＹＯＤ環境で使用するための企業モビリティ技術アーキテクチャ５００を示す。このアーキテクチャはモバイルデバイス５０２のユーザがモバイルデバイス５０２から企業リソースまたは個人リソースにアクセスすることと、モバイルデバイス５０２を個人利用に使用することと、の両方を可能にする。

ユーザは、当該企業リソース５０４または企業サービス５０８へのアクセスを、ユーザが購入したモバイルデバイス５０２を使用して行ってもよく、または企業がユーザに支給するモバイルデバイス５０２を使用して行ってもよい。ユーザはモバイルデバイス５０２をビジネス専用で利用しても、またはビジネスと個人兼用で利用してもよい。モバイルデバイスはｉＯＳオペレーティングシステム、およびアンドロイド・オペレーティングシステム等を稼動してもよい。企業はモバイルデバイス５０４を管理するポリシーを実装することを選んでもよい。

ポリシーは、ファイヤウォールまたはゲートウェイにより、モバイルデバイスを特定し、セキュリティ保護もしくはセキュリティ検証し、企業リソースへの選択的アクセスもしくは完全なアクセスをモバイルデバイスに提供できるように埋め込んでもよい。ポリシーはモバイルデバイス管理ポリシー、モバイルアプリケーション管理ポリシー、モバイルデータ管理ポリシー、またはモバイルデバイス、アプリケーションおよびデータ管理ポリシーのなんらかの組合せとしてもよい。モバイルデバイス管理ポリシーの適用により管理されるモバイルデバイス５０４は登録デバイスということがある。

モバイルデバイスのオペレーティングシステムは、管理対象パーティション５１０と非管理対象パーティション５１２とに分離されていてもよい。管理対象パーティション５１０は管理対象パーティション上で稼動しているアプリケーションおよび管理対象パーティションに格納されているデータをセキュリティ保護された状態にする（secure）ために、ポリシーをそれに適用させてもよい。管理対象パーティション上で稼動しているアプリケーションはセキュリティ保護されたアプリケーションであってもよい。セキュリティ保護されたアプリケーションは、電子メール・アプリケーション、ウェブブラウザ・アプリケーション、サービスとしてのソフトウェア（ＳａａＳ）アクセス・アプリケーション、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎアクセス・アプリケーション等であってもよい。セキュリティ保護されたアプリケーションは、セキュリティ保護されたネイティブアプリケーション５１４、セキュリティ保護されたアプリケーション・ランチャ５１８が実行するセキュリティ保護されたリモート・アプリケーション５２２、セキュリティ保護されたアプリケーション・ランチャ５１８が実行する仮想化アプリケーション５２６等であってもよい。

セキュリティ保護されたネイティブアプリケーション５１４はセキュリティ保護されたアプリケーション・ラッパー５２０によってラッピングしてもよい。セキュリティ保護されたアプリケーション・ラッパー５２０は、セキュリティ保護されたネイティブアプリケーションがデバイス上で実行されるときに、モバイルデバイス５０２上で実行される統合ポリシーを含んでいてもよい。セキュリティ保護されたアプリケーション・ラッパー５２０は、モバイルデバイス５０２上で稼動するセキュリティ保護されたネイティブアプリケーション５１４を、セキュリティ保護されたネイティブアプリケーション５１４の実行時に要求されるタスクを完了するようにセキュリティ保護されたネイティブアプリケーション５１４が要求してもよい企業でホストされるリソースに差し向けるメタデータを含んでいてもよい。セキュリティ保護されたアプリケーション・ランチャ５１８が実行するセキュリティ保護されたリモート・アプリケーション５２２は、セキュリティ保護されたアプリケーション・ランチャ・アプリケーション５１８内で実行してもよい。セキュリティ保護されたアプリケーション・ランチャ５１８が実行する仮想化アプリケーション５２６は、企業リソース５０４等で、モバイルデバイス５０２のリソースを利用してもよい。セキュリティ保護されたアプリケーション・ランチャ５１８が実行する仮想化アプリケーション５２６によってモバイルデバイス５０２で使用されるリソースは、ユーザ対話リソース、プロセッシングリソース等を含んでいてもよい。

ユーザ対話リソースは、キーボード入力、マウス入力、カメラ入力、触覚入力、オーディオ入力、ビジュアル入力、ジェスチャ入力等を収集して、伝送するために使用してもよい。プロセッシングリソースはユーザインターフェースを提示し、企業リソース５０４等から受信されるデータを処理するために使用してもよい。セキュリティ保護されたアプリケーション・ランチャ５１８が実行する仮想化アプリケーション５２６によって企業リソース５０４で使用されるリソースは、ユーザインターフェース生成リソース、プロセッシングリソース等を含んでいてもよい。ユーザインターフェース生成リソースは、ユーザインターフェースをアセンブルし、ユーザインターフェースを修正し、ユーザインターフェースをリフレッシュする等のために使用してもよい。

プロセッシングリソースは情報を作成し、情報を読み取り、情報を更新し、情報を削除する等のために使用してもよい。たとえば、仮想化アプリケーションはＧＵＩに関連するユーザの対話を記録し、それをサーバ・アプリケーションに伝えてもよく、当該サーバ・アプリケーションはユーザ対話データをサーバで動作するアプリケーションへの入力として使用する。

この構成では、企業は、アプリケーションに関連するデータ、ファイル等と同様に、サーバ側のアプリケーションを維持する選択をしてもよい。企業はモバイルデバイスへのデプロイメントのためにそれをセキュリティ保護された状態にすることにより本明細書の原理に従っていくつかのアプリケーションを「モバイル化」する選択をしてもよいが、この構成は一定のアプリケーションのためにも選択してもよい。たとえば、いくつかのアプリケーションはモバイルデバイスで使用するためにセキュリティ保護された状態にしてもよいが、他のものはモバイルデバイスへのデプロイメントの準備がされていないかまたはデプロイメントに適切ではない可能性があるので、企業は仮想化技術により準備されていないアプリケーションへのアクセスをモバイルユーザに提供する選択をしてもよい。

別の実施例として、企業は大量の複雑なデータセットを有する大きく複雑なアプリケーション（たとえば、資材所要量計画アプリケーション）を有することがあり、当該モバイルデバイスのアプリケーションをカスタマイズするのは非常に難しく、またはその他望ましくないので、企業は仮想化技術によりアプリケーションへのアクセスを提供する選択をしてもよい。さらに別の実施例として、企業は、セキュリティ保護化したモバイル環境であっても扱いに非常に注意を要すると企業に見なされて、企業が当該アプリケーションおよびデータへのモバイルアクセスを許可するために仮想化技術を選択してもよい高セキュリティ保護化データ（たとえば、人事データ、顧客データ、エンジニアリングデータ）を維持するアプリケーションを有していてもよい。

企業はサーバ側でより適切に動作すると見なされるアプリケーションへのアクセスを許可するために、仮想化アプリケーションとともに、モバイルデバイス上の完全にセキュリティ保護化しかつ完全に機能するアプリケーションを提供する選択をしてもよい。実施形態では、仮想化アプリケーションは、携帯電話のセキュリティ保護された記憶場所のうちの１つに、いくつかのデータ、ファイル等を格納してもよい。たとえば、企業は一定の情報を電話に格納させるが、他の情報を許可しない選択をしてもよい。

本明細書で説明するように、仮想化アプリケーションに関連して、モバイルデバイスは、ＧＵＩを提示し、さらにＧＵＩとのユーザの対話を記録するように設計されている仮想化アプリケーションを有していてもよい。アプリケーションは、アプリケーションとのユーザの対話として、サーバ側アプリケーションが使用するサーバ側とのユーザの対話を伝えてもよい。応答して、サーバ側のアプリケーションはモバイルデバイスに新たなＧＵＩを送り戻してもよい。たとえば、新たなＧＵＩは静的ページ、動的ページ、アニメーションまたは同様な他のものであってもよい。

管理対象パーティション上で稼働するアプリケーションは安定化されたアプリケーションであってもよい。安定化されたアプリケーションはデバイスマネージャ５２４によって管理されてもよい。デバイスマネージャ５２４は安定化されたアプリケーションを監視して、問題を検出して補修する技術が利用されない場合に安定化されていないアプリケーションをもたらすような問題検出および補修のための前記技術を利用してもよい。

セキュリティ保護されたアプリケーションは、モバイルデバイスの管理対象パーティション５１０のセキュリティ保護されたデータコンテナ５２８に格納されているデータにアクセスしてもよい。セキュリティ保護されたデータコンテナにセキュリティ保護化されているデータは、セキュリティ保護されたラッピングされたアプリケーション５１４、セキュリティ保護されたアプリケーション・ランチャ５１８が実行するアプリケーション、セキュリティ保護されたアプリケーション・ランチャ５１８が実行する仮想化アプリケーション５２６等によってアクセスしてもよい。

セキュリティ保護されたデータコンテナ５２８に格納されているデータはファイル、データベース等を含んでいてもよい。セキュリティ保護されたデータコンテナ５２８に格納されているデータはセキュリティ保護されたアプリケーション５３２の中で共有される特定のセキュリティ保護されたアプリケーション５３０等に制限されるデータを含んでいてもよい。セキュリティ保護されたアプリケーションに制限されるデータは、セキュリティ保護された一般データ５３４および高セキュリティ保護されたデータ５３８を含んでいてもよい。セキュリティ保護された一般データはＡＥＳ １２８ビット暗号化等の強力な暗号化方式を使用してもよいが、高セキュリティ保護されたデータ５３８はＡＥＳ ２５６ビット暗号化などの非常に強力な暗号化方式を使用してもよい。セキュリティ保護されたデータコンテナ５２８に格納されているデータは、デバイスマネージャ５２４からのコマンドを受信すると、デバイスから削除してもよい。

セキュリティ保護されたアプリケーションはデュアルモードオプション５４０を有していてもよい。デュアルモードオプション５４０は、非セキュリティ保護化モードで、セキュリティ保護されたアプリケーションを動作させるオプションをユーザに提示してもよい。非セキュリティ保護化モードでは、セキュリティ保護されたアプリケーションはモバイルデバイス５０２の非管理対象パーティション５１２の非セキュリティ保護化データコンテナ５４２に格納されているデータにアクセスしてもよい。非セキュリティ保護化データコンテナに格納されているデータは個人データ５４４であってもよい。非セキュリティ保護化データコンテナ５４２に格納されているデータは、モバイルデバイス５０２の非管理対象パーティション５１２上で稼動している非セキュリティ保護化アプリケーション５４８によってアクセスしてもよい。

非セキュリティ保護化データコンテナ５４２に格納されているデータは、セキュリティ保護されたデータコンテナ５２８に格納されているデータがモバイルデバイス５０２から削除されるとき、モバイルデバイス５０２上に残してもよい。企業は、ユーザが所有、ライセンスもしくは制御する個人データ、ファイルおよび／もしくはアプリケーション（個人データ）を残しながら、またはその他存続させながら、企業が所有、ライセンスまたは制御する選択されたもしくはすべてのデータ、ファイル、および／またはアプリケーション（企業データ）をモバイルデバイスから削除したいことがある。この動作を選択的消去と称すことがある。本明細書で説明する態様に従って分類される企業データおよび個人データを用いて、企業は選択的消去を行ってもよい。

モバイルデバイスは企業の企業リソース５０４および企業サービス５０８と、公衆インターネット５４８等とに接続してもよい。モバイルデバイスは仮想プライベートネットワーク接続を介して企業リソース５０４および企業サービス５０８に接続してもよい。仮想プライベートネットワーク接続は、モバイルデバイスの特定のアプリケーション５５０、特定のデバイス、特定のセキュリティ保護化エリア等５５２に特定的なものにしてもよい。たとえば、電話のセキュリティ保護化エリア内にラッピングされたアプリケーションのそれぞれは、ＶＰＮへのアクセスが、おそらくユーザまたはデバイスの属性情報と合わせて、アプリケーションに関連する属性に基づいて付与されるように、アプリケーション特定ＶＰＮ経由で企業リソースにアクセスしてもよい。

仮想プライベートネットワーク接続はＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅトラフィック、Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙトラフィック、ＨＴＴＰトラフィック、ＨＴＴＰＳトラフィック、アプリケーション管理トラフィック等を伝送してもよい。仮想プライベートネットワーク接続はシングルサインオン認証プロセス５５４をサポートし、これを有効にしてもよい。シングルサインオンプロセスは、ユーザが、後で認証サービス５５８によって検証される単一セットの認証資格情報を提供できるようにしてもよい。その後、認証サービス５５８は、各個々の企業リソース５０４に認証資格情報を提供するようユーザに要求しなくても、ユーザに複数の企業リソース５０４へのアクセス権を付与してもよい。

仮想プライベートネットワーク接続は、アクセス・ゲートウェイ５６０によって確立されて、管理してもよい。アクセス・ゲートウェイ５６０は企業リソース５０４のモバイルデバイス５０２への配信を管理し、高速化しおよび改善するパフォーマンス向上特徴を含んでいてもよい。アクセス・ゲートウェイはモバイルデバイス５０２から公衆インターネット５４８にトラフィックを経路切替えしてもよく、モバイルデバイス５０２が公衆インターネット５４８で稼動している公開利用できる非セキュリティ保護化アプリケーションにアクセスすることを可能にする。モバイルデバイスは転送ネットワーク５６２を介してアクセス・ゲートウェイに接続してもよい。

転送ネットワーク５６２はワイヤードネットワーク、ワイヤレスネットワーク、クラウドネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワーク、広域ネットワーク、パブリックネットワーク、プライベートネットワーク等でもよい。

企業リソース５０４は電子メールサーバ、ファイル共有サーバ、ＳａａＳアプリケーション、ウェブアプリケーションサーバ、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションサーバ等を含んでいてもよい。電子メールサーバはＥｘｃｈａｎｇｅサーバ、Ｌｏｔｕｓ Ｎｏｔｅｓサーバ等を含んでいてもよい。ファイル共有サーバはＳｈａｒｅＦｉｌｅサーバ等を含んでいてもよい。ＳａａＳアプリケーションはＳａｌｅｓｆｏｒｃｅ等を含んでいてもよい。Ｗｉｎｄｏｗｓ（登録商標）アプリケーションサーバはローカルなＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム上で稼動するように意図されたアプリケーションを提供するために構築されているあらゆるアプリケーションサーバ等を含んでいてもよい。

企業リソース５０４はプレミスベースのリソース、クラウドベースのリソース等であってもよい。企業リソース５０４はモバイルデバイス５０２から直接、またはアクセス・ゲートウェイ５６０経由でアクセスしてもよい。企業リソース５０４はモバイルデバイス５０２から転送ネットワーク５６２を介してアクセスしてもよい。転送ネットワーク５６２はワイヤードネットワーク、ワイヤレスネットワーク、クラウドネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワーク、広域ネットワーク、パブリックネットワーク、プライベートネットワーク等であってもよい。

企業サービス５０８は認証サービス５５８、脅威検出サービス５６４、デバイスマネージャサービス５２４、ファイル共有サービス５６８、ポリシーマネージャサービス５７０、ソーシャル統合サービス５７２、アプリケーションコントローラサービス５７４等を含んでいてもよい。

認証サービス５５８はユーザ認証サービス、デバイス認証サービス、アプリケーション認証サービス、データ認証サービス等を含んでいてもよい。認証サービス５５８は証明書を使用してもよい。証明書は企業リソース５０４等によりモバイルデバイス５０２に格納してもよい。モバイルデバイス５０２に格納されている証明書は、モバイルデバイスの暗号化された場所に格納してもよく、証明書は認証時点で使用する等のためにモバイルデバイス５０２に一時的に格納してもよい。脅威検出サービス５６４は侵入検出サービス、不正アクセス試行検出サービス等を含んでいてもよい。不正アクセス試行検出サービスはデバイス、アプリケーション、データ等への不正アクセスの試行を含んでいてもよい。

デバイス管理サービス５２４は構成サービス、プロビジョニングサービス、セキュリティサービス、サポートサービス、監視サービス、レポーティングサービスおよびデコミッショニングサービスを含んでいてもよい。ファイル共有サービス５６８はファイル管理サービス、ファイルストレージサービス、ファイルコラボレーションサービス等を含んでいてもよい。ポリシーマネージャサービス５７０はデバイスポリシーマネージャサービス、アプリケーションポリシーマネージャサービス、データポリシーマネージャサービス等を含んでいてもよい。

ソーシャル統合サービス５７２は連絡先統合サービス、コラボレーションサービス、Ｆａｃｅｂｏｏｋ、ＴｗｉｔｔｅｒおよびＬｉｎｋｅｄＩｎなどのソーシャル・ネットワークとの統合等を含んでいてもよい。アプリケーションコントローラサービス５７４は管理サービス、プロビジョニングサービス、デプロイメントサービス、割り当てサービス、失効サービス、ラッピングサービス等を含んでいてもよい。

企業モビリティ技術アーキテクチャ５００は、アプリケーションストア５７８を含んでいてもよい。アプリケーションストア５７８はラッピングされていないアプリケーション５８０、予めラッピングされたアプリケーション５８２等を含んでいてもよい。アプリケーションはアプリケーションコントローラ５７４からアプリケーションストア５７８に配置してもよい。アプリケーションストア５７８はモバイルデバイス５０２からアクセス・ゲートウェイ５６０、公衆インターネット５４８等経由でアクセスしてもよい。アプリケーションストアには直観的に理解でき、使いやすいユーザインターフェースを備えてもよい。アプリケーションストア５７８はソフトウェア開発キット５８４へのアクセス権を提供してもよい。

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

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

図６は、別の企業モビリティ管理システム６００である。図５を参照して上述したモビリティ管理システム５００の構成要素のうちのいくつかは、簡略化するために省略している。図６に図示するシステム６００のアーキテクチャは、図５を参照して上述したシステム５００のアーキテクチャと多くの点で類似しており、上述していない追加の特徴を含んでいる。

この場合、左側はクライアントエージェント６０４とともに登録モバイルデバイス６０２を表している。クライアントエージェント６０４は、遠隔またはモバイルデバイス上で稼働するエージェントを含んでいてもよい。クライアントエージェント６０４は、遠隔デバイスのためのクラウドリソースを含むゲートウェイサーバ６０６とやりとりしてもよい。ゲートウェイサーバ６０６は、右側に示すＥｘｃｈａｎｇｅ、Ｓｈａｒｅｐｏｉｎｔ、ＰＫＩリソース、ケルベロスリソース、証明書発行サービスなどの様々な企業リソース６０８およびサービス６０９にアクセスするために使用してもよい。具体的には図示していないが、モバイルデバイス６０２はアプリケーションの選択とダウンロードのために、企業アプリケーションストア（ＳｔｏｒｅＦｒｏｎｔ）とやりとりしてもよい。

クライアントエージェント６０４はＥｎｔｅｒｐｒｉｓｅデータセンターでホストされるＷｉｎｄｏｗｓ（登録商標）アプリ／デスクトップのＵＩ（ユーザインターフェース）媒介装置として機能し、ＥｎｔｅｒｐｒｉｓｅデータセンターはＨＤＸ／ＩＣＡ表示リモーティングプロトコルを使用してアクセスされる。クライアントエージェント６０４は、ネイティブｉＯＳまたはＡｎｄｒｏｉｄアプリケーションなどのモバイルデバイス６０２のネイティブアプリケーションのインストールおよび管理もサポートする。たとえば、上述の図面に図示する管理対象アプリケーション６１０（メール、ブラウザ、ラッピングされたアプリケーション）はすべてデバイス上でローカルに実行するネイティブアプリケーションである。

このアーキテクチャの、モバイル経験技術（ＭＤＸ）などの、クライアントエージェント６０４およびモバイルアプリケーション管理プロトコル（以下「ＭＡＭＰ」と略す）は、企業リソース／サービス６０８との接続性およびＳＳＯ（シングルサインオン）などのポリシーによる管理の機能および特徴を提供するように機能する。クライアントエージェント６０４は企業への、ゲートウェイサーバ６０６のコンポーネントなどに対する、一次ユーザ認証を扱う。クライアントエージェント６０４はゲートウェイサーバ６０６からポリシーを取得して、モバイルデバイス６０２上のＭＡＭＰ管理対象アプリケーション６１０の挙動を制御する。

ネイティブアプリケーション６１０とクライアントエージェント６０４とのセキュリティ保護されたＩＰＣリンク６１２は管理チャネルを表し、これによりクライアントエージェントは各アプリケーションを「ラッピング」するＭＡＭＰフレームワーク６１４によって強制されるポリシーを供給することができる。モバイルデバイス６０２上のＭＡＭＰ使用可能なアプリケーションは、直接的なリンクまたはラッピングプロセスによりＭＡＭＰを組み込んでもよい。したがって、ＭＡＭＰは、モバイルデバイス６０２上のアプリケーションを管理するために使用してもよい。

簡略化のために、本明細書においてＭＡＭＰはアプリケーションを管理するためのプロトコルを説明するために使用する。しかし、サーバから情報を受け取ることができ、かつモバイルデバイス６０２またはモバイルアプリケーションに対する診断を行うことができるあらゆるエージェントを含むエージェントを、モバイルデバイス６０２上のアプリケーションを管理できるモバイルデバイスに提供するいかなるプロトコルでも使用してよい。

ＩＰＣチャネル６１２により、クライアントエージェント６０４はまた、企業リソース６０８との接続性およびＳＳＯを有効にする資格情報および認証情報を供給することができる。最後に、ＩＰＣチャネル６１２により、ＭＡＭＰフレームワーク６１４は、オンラインおよびオフラインによる認証など、クライアントエージェント６０４が実装するユーザインターフェース機能を呼び出すことができる。

クライアントエージェント６０４とゲートウェイサーバ６０６との通信は、本質的に、各ネイティブ管理対象アプリケーション６１０をラッピングするＭＡＭＰフレームワーク６１４からの管理チャネルの拡張である。ＭＡＭＰフレームワーク６１４はクライアントエージェント６０４からのポリシー情報を要求し、これがさらにゲートウェイサーバ６０６からのポリシー情報を要求する。ＭＡＭＰフレームワーク６１４は認証を要求し、クライアントエージェント６０４はゲートウェイサーバ６０６のゲートウェイサービス部（ＮｅｔＳｃａｌｅｒ Ａｃｃｅｓｓ Ｇａｔｅｗａｙとしても知られる）にログインする。クライアントエージェント６０４はゲートウェイサーバ６０６上のサポートサービスも呼び出してもよく、それにより、以下詳細に説明するように、ローカルデータボルト６１６の暗号化鍵を導出するための入力成分を生成するか、または直接認証を可能にするクライアント証明書をＰＫＩ保護リソースに提供してもよい。

さらに詳しくは、ＭＡＭＰフレームワーク６１４は各管理対象アプリケーション６１０を「ラッピング」する。これは明確なビルドステップ、またはビルド後処理ステップを介して組み込んでもよい。ＭＡＭＰフレームワーク６１４は、セキュリティ保護ＩＰＣチャネルを初期化し、そのアプリケーションのポリシーを取得するために、アプリケーション６１０の最初の起動時にクライアントエージェント６０４と「ペア」にしてもよい。ＭＡＭＰフレームワーク６１４は、クライアントエージェントのログイン・ディペンデンシーおよび、ローカルＯＳサービスをどのように使用してよいか、またはローカルＯＳサービスがアプリケーション６１０とどのようにやりとりしてよいかを制限する閉じ込めポリシーのうちのいくつかなど、ローカルに適用するポリシーの関連部分を強制してもよい。

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

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

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

このアーキテクチャは、様々な他のセキュリティ特徴の組み込みをサポートする。たとえば、ある場合にはゲートウェイサーバ６０６（そのゲートウェイ・サービスを含む）はＡＤパスワードの妥当性検証をする必要がない。ある状況においてＡＤパスワードをあるユーザの認証因子として使用するかどうかは、企業の裁量に任せることができる。ユーザがオンラインまたはオフラインである（つまり、ネットワークに接続されている場合または接続されていない場合）、異なる認証方法を使用してもよい。

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

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

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

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

さらに、暗号化方法に１つ以上の初期化ベクトルを使用してもよい。初期化ベクトルは同じ暗号化データの複数のコピーに異なる暗号文出力を生じ、再生および暗号解読攻撃の両方を防止する。これは攻撃者がデータの暗号化に使用する特定の初期化ベクトルが不明な場合に盗んだ暗号鍵を用いた場合であっても、データの解読を防止する。また、認証後の解読を使用してもよく、ユーザがアプリケーション内で認証された後でしかアプリケーションデータは解読されない。別の特徴はメモリ内の扱いに注意を要するデータに関係してもよく、それが必要なときにのみ、メモリ（ディスクではない）に保管されてもよい。たとえば、ログイン資格情報はログイン後にメモリから消去されて、オブジェクティブＣインスタンス変数内の暗号化鍵および他のデータは、簡単に参照される可能性があるため格納されない。代わりに、これらのためにメモリを手動で割り当ててもよい。

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

ＭＡＭＰフレームワーク６１４からのデータ漏えいは、他の方法で防止してもよい。たとえば、アプリケーション６１０がバックグラウンドに入る場合、所定（構成可能な）期間後にメモリをクリアにしてもよい。バックグラウンドに移るとき、アプリケーションの最後に表示されたスクリーンのスナップショットを取得して、フォアグラウンドに出すプロセスを迅速化してもよい。スクリーンショットは機密データを含むことがあり、そのためクリアにされるべきである。

別のセキュリティ特徴は、１つ以上のアプリケーションにアクセスするためにＡＤ（アクティブディレクトリ）６２２のパスワードを使用せずに、ＯＴＰ（ワンタイムパスワード）６２０の使用に関係する。ある場合には、あるユーザは自身のＡＤパスワードを知らず（または知ることを許可されておらず）、そのためこれらユーザはＳｅｃｕｒＩＤなどのハードウェアＯＴＰシステムを使用するなど、ＯＴＰ６２０を使用して認証してもよい（ＯＴＰは、エントラストまたはジェムアルトなど、異なるベンダによっても提供されてよい）。ある場合には、ユーザがユーザＩＤで認証した後、ＯＴＰ６２０を用いてユーザにテキストが送信される。ある場合には、これはオンライン利用の場合のみ実施してもよく、プロンプトは単一フィールドである。

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

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

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

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

ｉＯＳのＭＡＭＰのクライアント証明書サポートは、各使用期間中、各管理対象アプリケーションのｉＯＳキーチェーンへのＰＫＣＳ １２ ＢＬＯＢ（バイナリ・ラージ・オブジェクト）のインポートに依拠してもよい。ＭＡＭＰのクライアント証明書サポートは、プライベートメモリ内キーストレージとともにＨＴＴＰＳ実装を使用してもよい。クライアント証明書はｉＯＳキーチェーンには絶対に存在することはなく、強力に保護されている「オンライン限定の」データ値を潜在的に除き、存続させない。

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

限定およびフル両方のケルベロス（kerberos）サポートを追加の特徴としてもよい。フルサポート特徴は、ＡＤパスワードまたは信頼できるクライアント証明書を使用したＡＤ６２２へのフルケルベロスログインを行い、ＨＴＴＰ Ｎｅｇｏｔｉａｔｅ認証チャレンジにレスポンスするためにケルベロスサービスチケットを取得する能力に関係する。限定サポート特徴はＡＧＥＥでの制約付き委任に関係し、当該ＡＧＥＥサポートはケルベロスプロトコル遷移の呼び出しをサポートするので、ＨＴＴＰ Ｎｅｇｏｔｉａｔｅ認証チャレンジにレスポンスしてケルベロスサービスチケット（制約付き委任を条件とする）を取得して使用することができる。このメカニズムはリバースウェブプロキシ（別名ＣＶＰＮ）モードで機能し、ｈｔｔｐ（ただし、ｈｔｔｐｓではない）接続はＶＰＮおよびマイクロＶＰＮモードでプロキシされる。

別の特徴はアプリケーション・コンテナのロックおよび消去に関係し、これはジェイルブレイクまたはルート化検出時には自動的に行われ、管理コンソールからプッシュされるコマンドとして発生し、たとえアプリケーション６１０が稼動していないときでも、遠隔消去機能を含んでいてもよい。

障害のある場合に、いくつかの異なる場所のうちの１つからユーザがサービスを受けられるＳｔｏｒｅＦｒｏｎｔおよびＡｐｐ Ｃｏｎｔｒｏｌｌｅｒのマルチサイト・アーキテクチャまたは構成をサポートしてもよい。

ある場合には、管理対象アプリケーション６１０には、ＡＰＩ（たとえば、ＯｐｅｎＳＳＬ）を介して証明書および秘密鍵にアクセスが許可されてもよい。企業の信頼できる管理対象アプリケーション６１０は、アプリケーションのクライアント証明書および秘密鍵を用いて、特定の公開鍵オペレーションを行うことが認められてもよい。アプリケーションがブラウザのように挙動し、証明書アクセスが要求されない場合、アプリケーションが「ｗｈｏ ａｍ Ｉ」証明書を読み取るとき、アプリケーションが証明書を使用してセキュリティ保護されたセッション・トークンを構築するとき、およびアプリケーションが重要なデータのデジタル署名のため（たとえば、トランザクションログ）または一時データ暗号化のために秘密鍵を使用するときなど、様々な使用のケースが識別され、それに応じて扱われてもよい。

〈プロキシを使用したリソースへの安全なアクセス〉
図７は、クライアントデバイス７０５、プロキシデバイス７１０、リソース７２０および／または認証サービス７１５を有するシステムを示す。図８は、クライアントデバイス７０５およびプロキシデバイス７１０の詳細図を示す。これらの構成要素は本明細書に説明する１つ以上の態様を実装してもよい。以下にさらなる実施例を用いてこれらの態様の簡単な説明を行う。

クライアントデバイス７０５はプロキシデバイス７１０を使用して１つ以上のリソース７２０および／または認証サービス７１５と通信してもよい。いくつかの態様では、クライアントデバイス７０５はリソース７２０および／または認証サービス７１５と直接通信するように構成されていない場合もある。たとえば、クライアントデバイス７０５およびリソース７２０は異なる認証および／または通信プロトコルを使用してもよい。プロキシデバイス７１０はこれらの異なるプロトコルの間で変換してもよい。さらに／あるいは、プロキシデバイス７１０は、以下の実施例で説明するように、さらなる利益を提供してもよい。

クライアントデバイス７０５はプロキシデバイス７１０に、ドキュメント、電子メール、サービス、ファイル等のリソース７２０に対する要求を送信してもよい。プロキシデバイス７１０はリソース７２０に要求を転送し、それに応答してプロキシデバイス７１０とリソース７２０との間の認証が開始されてもよい。

認証における１以上の時点で、リソース７２０はクライアント証明書等からの署名を要求してもよい。プロキシデバイス７１０はクライアント証明書への直接的なアクセスを有していない場合もあるので、プロキシデバイス７１０は、クライアントデバイス７０５がクライアント証明書へのアクセスを制御する場合などのように、クライアントデバイス７０５を認証プロセスに関連させてもよい。たとえば、プロキシデバイス７１０はクライアントデバイス７０５にクライアント証明書（またはそれに含まれる秘密鍵）を使用して認証メッセージに署名またはこれを解読するように、あるいは利用可能なセキュリティ証明書のリストまたは特定のセキュリティ証明書のユーザによる選択を返送するように要求してもよい。

プロキシデバイス７１０はクライアントデバイス７０５に、プロキシデバイス７１０とリソース／認証サーバとの間の認証セッションを識別するコンテキスト情報を提供してもよい。たとえば以下の実施例においてより詳細に説明するように、コンテキスト情報はプロキシデバイス７１０とリソース７２０との間および／またはプロキシデバイス７１０と認証サービス７１５との間で交換される（または交換されるべき）認証情報のデータ構造を識別してもよい。

クライアントデバイス７０５はコンテキスト情報を使用してプロキシデバイス７１０とリソース／認証サーバとの間の認証セッションを検証または別様に確認してもよい。コンテキスト情報が検証されると、クライアントデバイス７０５はプロキシデバイス７１０に要求された署名を提供し、プロキシデバイス７１０はリソース７２０および／または認証サービス７１５を用いた認証を完了してもよい。その後、プロキシデバイス７１０はクライアントデバイス７０５が要求するリソースを読み出して、それをクライアントデバイス７０５に提供してもよい。

クライアントデバイス７０５はエンドポイントデバイス、クライアントコンピュータ１０７または１０９、端末２４０、クライアントコンピュータ４１１〜４１４、モバイルデバイス５０２、モバイルデバイス６０２、またはその他のあらゆるデバイスを含んでいてもよい。たとえば、モバイルデバイスはスマートフォン、タブレット等を含んでよい。
１つ以上のアプリケーションがクライアントデバイス７０５上で稼働してもよい。アプリケーションは企業リソースなどの保護されたリソースへのアクセスを要求してもよく、そのアプリケーション（または他のアプリケーション）に含まれるモジュールがそれらの保護されたリソースへのアクセスを容易にしてもよい。

たとえば図８を参照すると、クライアントデバイス７０５上で稼働するアプリケーションはＭＡＭＰフレームワーク８０５にリソースに対する要求（たとえばＨＴＴＰ要求）を送信してもよく、それによりプロキシデバイス７１０との通信を容易にしてもよい。いくつかの態様では、ＭＡＭＰフレームワーク８０５はクライアントデバイス７０５上で特権的アプリケーションとして稼働してもよい。ＭＡＭＰフレームワーク８０５は、上述のように、ＭＡＭＰフレームワーク６１４によって提供される機能のすべてまたは一部を含んでよい。

クライアントデバイス７０５は、認証のために署名するのに用いてもよい１つ以上のクライアント証明書を格納する鍵ストア８１５へのアクセスを容易にするＰＫオペレーションＳＤＫモジュール８１０も備えていてよい。たとえば、クライアントデバイス７０５は、クライアントデバイス７０５のユーザを表すクライアント証明書へのアクセスまたはその所有を許可してもよい。いくつかの態様では、証明書は企業が発行する証明書であってもよい。証明書は暗号化モジュールを有する物理的スマートカードに結合されていてもよい。すなわち、暗号機密がスマートカードに制限されていてもよい。

ユーザはスマートカードに保護された証明書へのクライアントデバイス７０５のアクセスを許可してもよい。あるいは、証明書は、鍵を保護するためにハードウェアおよび／またはソフトウェアモジュールを使用して、仮想スマートカードに結合されていてもよい。クライアントデバイス７０５および／またはクライアントデバイス７０５の取り外し可能なハードウェアモジュールは、プロビジョニング・プロセスによって証明書および秘密鍵の格納を許可されてもよい。クライアント証明書の秘密鍵を含むオペレーションを許可するためにクライアントデバイス７０５を使用してＰＩＮコードを入力するようにユーザに要求してもよい。クライアントデバイス７０５から分離した他の外部デバイス（たとえば、他のスマートフォン）は証明書を制御してもよく、クライアントデバイス７０５は外部デバイスによって制御される証明書にアクセスするためにカスタムリーダ・インターフェースを利用してもよい。

いくつかの実施形態では、クライアント証明書および／または秘密鍵がクライアントデバイス７０５または物理的スマートカードに制限されている場合がある。したがって、クライアントデバイス７０５は鍵の制御を維持してもよい。鍵を使用した認証が要求される場合、クライアントデバイス７０５は認証プロセスに含まれることを必要としてもよい。これによりクライアントデバイス７０５は、証明書秘密鍵を用いて実行されるオペレーションがクライアントデバイス７０５が意図するものであることが保証される。

いくつかの組織は特定のオペレーションに対する否認防止を得るためにスマートカードを使用してもよく、これにより組織が発行する証明書のすべての使用に対する権限をユーザに要求してもよい。たとえば、ドキュメントの署名は明らかなユーザの権限を要求してもよいが、一定のシステムに対する認証は明らかなユーザの権限を要求しない場合もある。そのような保証を提供するのに適した機構は、アクセスされるリソース、含まれるプロキシデバイス、およびクライアントデバイス７０５の動作方法の特性によって決められてもよい。

プロキシデバイス７１０はサーバ（たとえば、サーバ２０１、２０６、３０１、４１０）、コンピューティングデバイス、アクセス・ゲートウェイ５６０、ゲートウェイサーバ６０６、または他のあらゆるデバイスのうちの１つ以上を含んでよい。プロキシデバイス７１０はクライアントデバイス７０５と企業リソースまたは他のネットワークとの間の通信を容易にしてもよい。たとえば、クライアントデバイス７０５のユーザは認証を要求する企業リソースへのアクセスを希望してもよく、プロキシデバイス７１０がアクセスを仲介してもよい。クライアントデバイス７０５は、たとえばクライアントデバイス７０５がリソースに直接アクセスできない場合、プロキシデバイス７１０を使用してリソースにアクセスしてもよい。たとえば、クライアントデバイス７０５は企業リソースが利用するプロトコル用に構成されていない場合がある。いくつかの態様では、企業リソースは認証のためにＰＫＩＮＩＴを用いたケルベロスを実装してもよいが、クライアントデバイス７０５はＰＫＩＮＩＴを用いたケルベロスを実装していない場合がある。同様に、企業リソースはクライアント証明書の認証を用いたＳＳＬを実装してもよいが、クライアントデバイス７０５はクライアント証明書の認証を用いたＳＳＬを実装していない場合がある。代わりに、クライアントデバイス７０５およびプロキシデバイス７１０は、標準コンポーネントを有し周知の認証フレームワークに適合するプロトコルを用いて通信してもよい。

プロキシデバイス７１０は第一のリソースへのプロトコル（たとえば、ケルベロスまたはＳＳＬ）と第二のクライアントデバイス７０５への異なるプロトコル（たとえば、ＨＴＴＰまたはＨＴＴＰＳ）との間の変換を行ってもよい。プロキシデバイス７１０を利用して、クライアントデバイスは企業リソースが使用する複雑なまたは異なるプロトコルを理解および操作する必要が無い場合がある。これらの実施例では、プロキシデバイス７１０はクライアントの役割を果たしてもよい。しかし、プロキシデバイス７１０はクライアント証明書の秘密鍵の制御を行わない場合がある。

プロキシデバイス７１０は、クライアントデバイス７０５がリソースへの直接的なアクセスを許可されていない場合、クライアントデバイス７０５のアクセス能力が限定されている場合、および／またはプロキシデバイス７１０が性能の改善または好ましいインターフェースの提供によってアクセスを向上している場合等の、他の状況におけるリソースへのアクセスを容易にするために使用されてもよい。

プロキシデバイス７１０はまた、セキュリティの増強を容易にしてもよい。たとえば、ケルベロスリソース認証はケルベロスＫＤＣ（たとえば、アクティブ・ディレクトリ・ドメイン・コントローラ）からのサービスチケットの取得を要求してもよい。しかし、ＫＤＣ自体は、いくつかのクライアントデバイスに直接的にアクセス可能にするべきではない扱いに注意を要する企業リソースを含んでいてもよい。これらの場合、ケルベロス認証は信頼できるプロキシデバイス７１０の使用を要求してもよい。

他の実施例として、プロキシデバイス７１０は企業のＤＭＺネットワークに配置された強固な通信ゲートウェイであってもよい。セキュリティをさらに向上させるために、プロキシデバイス７１０は、クライアントデバイス７０５と企業リソースとの間の端末相互間の通信の流れをプロキシデバイス７１０が存在しないかのように透明にするよりもむしろ、企業リソースにプロキシされている通信を検査できるようにしてもよい。すなわち、プロキシデバイス７１０はクライアントデバイス７０５がどのリソースを使用しているかおよびクライアントデバイス７０５が利用するプロトコルを認識していてもよい。

以下の実施例においてより詳細に述べるように、プロキシデバイス７１０はまた、クライアントデバイス７０５に、プロキシデバイス７１０と認証サービス７１５および／またはリソース７２０との間の認証セッションの１つ以上の態様を特定するコンテキスト情報を提供してもよい。クライアントデバイス７０５はこのコンテキスト情報を使用して、署名を要求するプロキシデバイス７１０によって提供されるデータに署名するべきか否かを判定してもよい。

図８を参照すると、プロキシデバイス７１０は、ハードウェアモジュールおよび／またはソフトウェアモジュールであってもよいパケットエンジン８２０を含んでいる。パケットエンジン８２０はクライアントデバイス７０５および／またはリソースとの通信を容易にしてもよい。プロキシデバイス７１０はセッションキャッシュ８２５も含んでよい。

以下の実施例においてより詳細に説明するように、セッションキャッシュ８２５は、プロキシデバイス７１０と１つ以上のリソースまたはリソースを格納するサーバとの間の通信を可能にするためのセッション鍵および／またはチケット（たとえば、ケルベロスセッション）を格納してもよい。プロキシデバイス７１０は、クライアントデバイス７０５から署名を取得する等、クライアントデバイス７０５を用いた認証を管理するように構成されたクライアント側の認証モジュール８３０を含んでいてもよい。ケルベロス認証のために、クライアント側の認証モジュール８３０は、ケルベロス認証プロトコル（たとえば、ＰＫＩＮＩＴプロトコル）のクライアント側の公開鍵形態を実装するＰＫＩＮＩＴモジュール（なおデーモンと称されてもよい）を含んでいてもよい。たとえば、これはケルベロスのオープンソースの実装から利用可能なｋｉｎｉｔコマンドラインプログラムである可能性がある。

プロキシデバイス７１０は、クライアント証明書秘密鍵にアクセスするための詳細を抽出するためにクライアント側の認証モジュール８３０が使用するライブラリモジュール８３５（たとえば、ＰＫオペレーション・プロキシＳＤＫ８３５）も含んでいてよい。

ケルベロスに対して、スマートカードに結合されたクライアント証明書にアクセスするためのＰＫＣＳ＃１１ ＡＰＩ仕様を実施するＰＫオペレーション・プロキシＳＤＫ８３５を使用してもよい。ＰＫオペレーション・プロキシＳＤＫ８３５はＰＫＣＳ＃１１の部分を実装し、関連する証明書オペレーションをクライアントデバイス７０５に対してリモート処理ができる形態にパッケージ化してもよい。ＰＫＣＳ＃１１ ＡＰＩを使用して、ＭＩＴ等の標準ケルベロス実装を含んでよいケルベロス実装は修正する必要が無い。これにより、製品にセキュリティフィックスが行われた場合などに、ケルベロス製品の維持が容易になる。

パケットエンジン８２０、セッションキャッシュ８２５、クライアント側の認証モジュール８３０、およびＰＫオペレーション・プロキシＳＤＫ８３５はハードウェアおよび／またはソフトウェアモジュールを含んでもよく、それらが実行してもよいオペレーションを以下の実施例においてより詳細に説明する。いくつかの態様では、プロキシデバイス７１０は１つ以上のプロセッサと、プロセッサが実行すると、プロキシデバイス７１０に、パケットエンジン８２０、セッションキャッシュ８２５、クライアント側の認証モジュール８３０、およびＰＫオペレーション・プロキシＳＤＫ８３５を提供させ、および／またはパケットエンジン８２０、セッションキャッシュ８２５、クライアント側の認証モジュール８３０、およびＰＫオペレーション・プロキシＳＤＫ８３５のオペレーションを実行させるコンピュータ実行可能命令を格納するメモリとを含んでよい。

クライアントデバイス７０５およびプロキシデバイス７１０は、ＨＴＴＰフレームワーク等の標準フレームワークを使用して通信してもよい。いくつかの態様においておよび以下の実施例で説明するように、クライアントデバイス７０５およびプロキシデバイス７１０は１つ以上の認証メッセージを交換してもよい。これらは、認証を要求するためのＨＴＴＰ４０１コード等のＨＴＴＰステータスコードおよび／またはチャレンジ・レスポンス方式のメッセージを交換してもよい。

いくつかの実施形態では、４０１の認証チャレンジを受信するクライアントデバイス７０５がクライアントの非公開証明書の安全な交換をサポートしていない場合、クライアントデバイス７０５は４０１のメッセージをクライアントデバイス７０５が理解しない認証チャレンジとして認識してもよい。クライアントデバイス７０５は、クライアントデバイス７０５がクライアントの非公開証明書の安全な交換をサポートしていないためオペレーションが完了できなかったというメッセージをユーザに表示する等、適切なエラー処理行動で対応してもよい。公開鍵オペレーションのリモート処理をサポートするためのＨＴＴＰレベルの符号化は比較的単純であってよい。パケットエンジン８２０およびＭＡＭＰフレームワーク８０５はＨＴＴＰレベルの符号化を処理してもよい。

通信は、参照によりその全文が本明細書に組み込まれるＲＦＣ４５５９に記載されているＨＴＴＰ Ｎｅｇｏｔｉａｔｅ認証計画と同様の構造であってもよい。Ｂａｓｅ６４の符号化されたブロブは、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅおよび／またはＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを使用してクライアントデバイスとプロキシデバイスとの間で前後に交換してもよい。ブロブは、それぞれのＰＫオペレーションＳＤＫ（８１０，８３５）によって各デバイスで生成および処理してもよい。

いくつかの実施形態では、ＨＴＴＰが認識するクライアントデバイス７０５とプロキシデバイス７１０との間の通信パス内のコンポーネントは認証プロセスと相互作用しない場合がある。たとえば、クライアントデバイス７０５とプロキシデバイス７１０との間のＨＴＴＰプロキシサーバは、プロキシデバイス７１０への接続は他のクライアントデバイスおよび／またはユーザからの要求の送信に再使用してはならないということを認識していてもよい。さらに、プロキシデバイス７１０から返送されたいかなるＨＴＴＰデータのキャッシングも、データが他のクライアントデバイスに送信されないように正確な範囲の制限を行わなければならない。

いくつかの態様では、クライアントデバイス７０５とプロキシデバイス７１０との間の認証は、ウェブ認証またはカスタム機構を用いたジェネリック・セキュリティ・サービス・アプリケーション・プログラム・インターフェース（ＧＳＳＡＰＩ）等の、標準の認証フレームワークを利用してもよい。オブジェクトはプロキシデバイス７１０からクライアントデバイス７０５へ送信されてもよい。クライアントデバイス７０５はオブジェクトを処理し、名前のチェックによる証明書パスの検証等の、標準の暗号化機構によってそれらの検証を行う。

クライアントデバイス７０５とプロキシデバイス７１０との間に専用通信チャネルを作成してもよい。たとえば、専用通信チャネルは証明書オペレーションの要求及び結果を中継するために使用してもよい。専用通信チャネルを利用して、クライアント７０５とプロキシデバイス７１０との間の標準ＳＳＬチャネルによって提供されるものを超えるさらなる暗号化保護を提供してもよい。これは、リモート処理される暗号化オペレーションの入出力の保護必要度を考慮すると、適切である場合がある。

いくつかの実施例では、クライアントデバイス７０５とプロキシデバイス７１０との間に、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換が発生する場合がある。この交換はクライアントデバイス７０５とプロキシデバイス７１０との間に相互認証を提供してもよい。いくつかの実施形態では、相互認証はクライアントデバイス７０５によるリソースへのアクセスの要求の前に既に確立されていてもよい。参照によりその全文が本明細書に組み込まれるＲＦＣ５９２９に説明されているように、チャネルの結合を使用して専用通信チャネルを外部ＳＳＬセッションに暗号でリンクしてもよい。

図８を簡潔に参照すると、ＰＫオペレーションのペイロード等の、データ用の専用通信チャネルの設定にクライアントデバイス７０５とパケットエンジン８２０との間の複数の交換を利用してもよい。これは、ＰＫオペレーションＳＤＫ８１０およびＰＫオペレーション・プロキシＳＤＫ８３５を除く全てに対して不透明であってよい。

専用通信チャネルを介してさらなる保護を提供する理由の一つは、実際問題として、ＳＳＬはプロキシデバイス７１０の前のオフロードデバイス等のネットワークのデバイスによって終了される場合があるということである。ＳＳＬ接続に含まれるＣＰＵの集中動作を加速するための専用のハードウェアの使用等により、ＳＳＬ接続処理に対するオフロードデバイスの最適化を行ってもよい。ハードウェアモジュールはまた、連邦情報処理規格（たとえば、ＦＩＰＳ−１４０）等の、商業的に重要な暗号化処理規格に適合するために認証されてもよい。

さらなる保護を提供する他の理由は、検査デバイスは通信を解読するためにＳＳＬ証明書鍵へのアクセスを付与される場合があるということである。検査デバイスは、信頼できるネットワーク領域の外部へ秘密情報を送信する試み、あるいは信頼できないまたは承認されていないサーバと通信する試みを検出すること等によって、セキュリティポリシーに従うためにネットワークトラフィックを監視するように設計されたセキュリティデバイスを含んでいてもよい。これらの検査デバイスのいくつかは、検査プロセスが暗号化通信チャネルの使用によって阻止されないように、ＳＳＬ接続のハンドシェイクの間、他のサーバに成り済ますように構成されていてもよい。

専用通信チャネルの使用によって、扱いに注意を要するデータのオフロードデバイスおよび／または検査デバイスへの不必要なおよび／または不適切な露出を阻止してもよい。したがって、クライアント証明書と同等のスマートカードの使用によって期待される否認防止特性を保護してもよい。たとえば、専用通信チャネルは署名されるデータに対する外部デバイスによる変更および／または解読されたデータの漏えいを阻止してもよい。

専用通信チャネルは複数の方法で実装してよい。たとえばおよび上述のように、標準ＨＴＴＰ認証プロトコル内で動作するカスタムＧＳＳＡＰＩ機構を利用してよい。この実施態様はいくつかの非排他的な利益を提供する。

第一に、プロキシデバイス７１０はクライアントデバイス７０５に、リソースに対する認証および／または認証サーバは要求されたリソースへのアクセスを完了するように要求されるということを標準的な方法（たとえば、ＨＴＴＰ）で示してもよい。第二に、クライアントデバイス７０５とプロキシデバイス７１０との間で、必要であれば複数回、任意のバイナリプロトコルを伝送させてもよい。第三に、この実施態様によりセキュリティ保護された通信機構を標準的な方法（たとえば、ＧＳＳＡＰＩレベルで）でデータの転送にネゴシエートおよび適用することができる。いくつかの実施態様では、標準ＨＴＴＰ認証プロトコル内で動作するカスタムＧＳＳＡＰＩ機構は、ＧＳＳＡＰＩのプラットフォーム実装をＭＩＣＲＯＳＯＦＴ ＮｅｇｏＥｘ機構等の追加されるカスタム機構で使用可能にすることができる。

図７を参照すると、１つ以上の認証サービス７１５（または認証サービス７１５を稼働させるサーバ）が存在してもよい。認証サービス７１５は、ケルベロスまたはＳＳＬを含む１つ以上のタイプの認証を実装してもよい。

本明細書で説明する態様は、クライアント証明書の秘密鍵オペレーションを含むあらゆる認証プロトコルに実装できる。たとえば、ケルベロスには、チケット付与チケットおよび／またはセッションチケットを含むチケットを発行するタスクを認証サーバに課してもよい。認証サーバは１つ以上のチャネルを介してプロキシデバイス７１０と通信してもよい。さらに、１つ以上のチャネルは、プロキシデバイス７１０と通信するためにクライアントデバイス７０５が使用する通信プロトコルとは異なる通信プロトコルを使用してもよい。いくつかの態様では、認証サービス７１５が、本明細書で説明する実施態様を実装しても、不変である場合がある。すなわち、認証サービス７１５は従来のインフラストラクチャ内に存在してもよい。認証サービス７１５は、たとえば、上述の認証サービス５５８を含んでいてもよい。

１つ以上のリソース７２０（またはリソース７２０を格納するサーバ）が存在してもよい。リソース７２０は、認証サーバがプロキシデバイス７１０と通信するために使用するような、１つ以上の同じまたは異なるプロトコルを使用してプロキシデバイス７１０と通信してもよい。いくつかの態様では、リソースは本明細書で説明する実施態様を実装しても、不変である場合がある。すなわち、リソースは従来のインフラストラクチャ内に存在してもよい。リソースについて限定しない実施例は、ファイルリソース、ウェブリソース、メールリソース、シェアポイントリソース等を含んでいてもよいが、これらには限定されない。これらのリソースは、構造クエリー言語（ＳＱＬ）データベース、リモート・プロシージャ・コール（ＲＰＣ）サーバ、分散型コンポーネント・オブジェクト・モジュール（ＤＣＯＭ）サーバ、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）ウェブサービス、表示状態転送（ＲＥＳＴ）ウェブサービス、および認証にＧＳＳＡＰＩまたは同様のセキュリティフレームワークを使用してよい他のプロプライエタリ・リソースを含んでいてもよい。

これらのリソースの１つ以上は、リソースと同じネットワーク上のまたは他の保護されたネットワーク内のコンピュータ等の内部デバイスが直接的にアクセスしてもよい。リソースは、上述の企業リソース５０４，５０８および／または６０８ならびに／もしくは企業サービス５０８および／または６０９を含んでいてもよい。さらに、リソースは図２に示すサーバ２０６等の１つ以上のサーバに格納されていてもよい。リソースは多層構成システムを通じてアクセスしてもよい。プロキシデバイス７１０は、次にバックエンドサーバと通信（および要求するユーザとして認証）してもよいフロントエンドサーバと通信してもよい。このタイプのシステムには制約のない権限を有するケルベロスを使用してもよく、プロキシデバイス７１０はフロントエンドサーバにユーザのために転送されたＴＧＴを供給してもよい。

図９Ａ〜図９Ｃは、認証および／またはプロキシを使用してリソースへの安全なアクセスを提供するための方法のステップのフローチャートである。

図９Ａ〜図９Ｃは、クライアントデバイス７０５、プロキシデバイス７１０、認証サービス７１５、および／またはリソース７２０のうちの１つによって実行される各ステップを示している。しかし、方法のステップは、クライアントデバイス７０５、プロキシデバイス７１０、認証サービス７１５、リソース７２０、および／またはそれらの組み合わせのうちのいずれかによって実行してよい。上述のように、リソース７２０および認証サービス７１５は同じサーバ（またはサーバ群）によって提供されてもよい。あるいは、リソース７２０および認証サービス７１５は異なるサーバ（またはサーバ群）によって提供されてもよい。簡潔にするために、方法のステップのうちのいくつかは、図９Ａ〜図９Ｃにおいて、単一のリソース／認証サービスエンティティ（たとえば、サーバまたはサーバ群）によって実行されるものとして示している。しかし、認証サービスは認証サーバ（または認証サーバ群）によって提供されてもよく、リソースは異なるサーバ（またはサーバ群）によって提供されてもよい。

ステップ９０２において、ユーザをクライアントデバイス７０５で認証する。たとえば、ユーザはクライアントデバイス７０５にログインするためにユーザ名および／またはパスワード等の視覚情報を提供してもよい。

ステップ９０４において、クライアントデバイス７０５はプロキシデバイス７１０を認証する。さらに／あるいは、ステップ９０６において、プロキシデバイス７１０はクライアントデバイス７０５を認証してもよい。すなわち、クライアントデバイス７０５およびプロキシデバイスは相互認証を実行してもよい。認証を実行するために、クライアントデバイス７０５はサーバ認証を有するＳＳＬを使用してプロキシデバイス７１０に接続してもよい。プロキシデバイス７１０はクライアントデバイス７０５および／またはクライアントデバイス７０５のユーザにプロキシデバイス７１０へのアクセスを承認する前にプロキシデバイス７１０に対する認証を行うように要求してもよい。

いくつかの態様では、クライアントデバイス７０５はこの認証に企業のクライアント証明書を使用してもよい。企業のクライアント証明書は、以下の実施例でより詳細に説明するように、ドキュメントおよび／または認証メッセージに署名するためにクライアントデバイス７０５が使用するのと同じ証明書であってもよい。あるいは、企業のクライアント証明書は異なる証明書を含んでいてもよい。たとえば、クライアントデバイス７０５はそれぞれ異なる目的に使用する複数の証明書を備えていてもよい。物理的なスマートカードを使用する場合は、複数の証明書がそのスマートカードまたは異なるスマートカードに格納されていてもよい。

同様に、クライアントデバイス７０５は、プロキシデバイス７１０が周知の信頼できるエンティティでありかつプロキシを介した委託された認証によってユーザが認証されるリソースの識別を要求してもよいということを確立するために、プロキシデバイス７１０の認証を要求してもよい。クライアントデバイス７０５はまた、たとえばＳＳＬハンドシェイクの一部としてデバイスが利用可能なクライアント証明書を使用して、あるいはたとえばＨＴＴＰ上でＳＳＬ接続内の個別のユーザ認証プロトコルを稼働して、プロキシデバイス７１０に対してクライアントデバイス７０５のユーザを認証してもよい。リソース７２０はまた、リソース７２０へのアクセスをリソース・アクセス・プロトコルの使用等によってプロキシデバイス７１０が仲介していることを知ることを希望してもよい。したがって、クライアントデバイス７０５／ユーザ、プロキシデバイス７１０、およびリソース７２０の３つのエンティティのすべてに対して相互認証または識別を実行してもよい。

３つのエンティティのうちの１つ以上の認証および／または識別の後、クライアントデバイス７０５は、プロキシデバイス７１０によるアクセスは可能であるがクライアント証明書に基づくユーザ認証を要求するウェブリソース、（たとえば、ネットワークファイルサーバからの）企業リソース、または他のリソース等の１つ以上のリソースに対する要求をプロキシデバイス７１０に送信してもよい。リソースに対する要求はＨＴＴＰ、ＨＴＴＰＳ、またはクライアントデバイスがサポートする他のアクセスプロトコルを介してクライアントデバイス７０５が送信してもよい。プロキシデバイス７１０はクライアントデバイス７０５が使用するアクセスプロトコル（たとえば、ＨＴＴＰまたはＨＴＴＰＳ）からリソースが使用するアクセスプロトコルへ変換またはブリッジしてもよい。変換後、プロキシデバイス７１０はステップ９１０においてリソースおよび／または認証サービスへの要求を転送するか、あるいは要求されたリソースへのアクセスを別様に試みてもよい。

ステップ９１２において、リソースはプロキシデバイス７１０からの認証を要求する。たとえば、リソースは実行する認証のタイプ（たとえば、ＳＳＬ、ケルベロス等のドメインベースの認証）を表示してもよい。認証のタイプに基づいて、リソースは認証チャレンジ（たとえば、ケルベロス認証に対する４０１ＮｅｇｏｔｉａｔｅメッセージまたはＳＳＬ認証に対するクライアント証明書チャレンジ）を送信してもよい。ケルベロス認証のために、ＰＫＩＮＩＴプロトコルを使用してもよく、プロキシデバイス７１０はケルベロスのレルム（たとえば、ＭＩＣＲＯＳＯＦＴアクティブ・ディレクトリ・ドメイン）へのクライアント認証によって識別されたユーザを認証するためにＰＫＩＮＩＴプロトコル内でクライアントの役割を果たしてもよい。リソースサーバは、ＨＴＴＰ４０１Ｎｅｇｏｔｉａｔｅ等のケルベロス認証チャレンジを生成してもよい。（たとえば、クライアント証明書を使用した）ＳＳＬ認証のために、プロキシデバイス７１０はリソースに対してプロキシデバイス７１０がユーザのクライアント証明書および／または鍵にアクセスしたことを示してもよい。

プロキシデバイス７１０は、ケルベロス認証においてと同様に、特定のドメインを用いる代わりにリソースを用いて直接的に認証を行うことを試みてもよい。さらに／あるいは、プロキシデバイス７１０は、要求されたリソースへのアクセスを試みる前に認証が要求されることを認識してもよい。何れの場合も、プロキシはリソースとの関連する認証プロトコルの対話を決定して開始してよい。これらの対話は、リソースに信頼されている認証サービスを稼働する認証サーバ等のさらなるエンティティを含んでいてもよい。

ステップ９１４において、プロキシデバイス７１０は、リソース（またはリソースを有するサーバ）との安全な通信セッションを開始するために使用できるセッション鍵が利用可能であるかどうかを判定する。セッション鍵は、リソースまたは認証サービスとの以前の認証セッションに基づいてプロキシデバイス７１０によって事前に取得されてプロキシデバイスで格納（たとえば、キャッシュ）されていてもよい。ケルベロス認証に対して、セッション鍵はチケット付与チケット（ＴＧＴ）またはその他の時間制限チケット等のケルベロスチケットで格納されてもよい。

図８を参照すると、ケルベロス認証のために、プロキシデバイス７１０のパケットエンジン８２０はそのケルベロス認証の応答ロジックを呼び出してもよく、これによりセッションキャッシュ８２５内にリソース（たとえば、ウェブリソース）のためのサービスチケットが既に存在するかどうかを確認する。いくつかの態様では、クライアント側の認証モジュール８３０は、この確認に応答して、クライアント証明書の認証が要求および／またはサポートされていることをプロキシデバイス７１０が認識している場合にＰＫＩＮＩＴを呼び出してもよい。ＳＳＬ認証のために、セッション鍵を使用してＳＳＬセッション等の事前のＳＳＬ接続を再開してもよい。セッション鍵（および／またはチケット）が利用可能であれば（ステップ９１４でＹＥＳ）、以下の実施例でさらに詳しく説明するように、プロキシデバイス７１０はセッション鍵（および／またはチケット）を使用してステップ９５４（要求されたリソースを取得する）に進んでもよい。

最初の認証のために、セッションキャッシュは空であってもよい（たとえば、有効なセッション鍵および／またはチケットを格納していない）（ステップ９１４でＮＯ）。したがって、プロキシデバイス７１０はリソースで認証を開始してもよい。

図８を参照すると、ケルベロス認証のために、パケットエンジン８２０はＴＧＴを取得するためにクライアント側の認証モジュールへ内部ＰＫＩＮＩＴコマンドを発行してもよい。認証のために、プロキシデバイス７１０は、それが、クライアントデバイス７０５によってアクセス可能なクライアント証明書に基づいて１つ以上のクライアント証明書および／または署名を必要としていると判定してもよい。これらの証明書および／または署名はプロキシデバイス７１０の直接的なアクセスが可能ではない場合がある。

図８を参照すると、クライアント側の認証モジュール８３０は、内部Ｐ１１証明書取得コマンド等のコマンドをＰＫオペレーション・プロキシＳＤＫ８３５へ送信して、クライアントデバイス７０５から証明書を取得してもよい。クライアント側の認証モジュール８３０は、ＰＫＩＮＩＴに適切なクライアント証明書を検索する方法として標準ＰＫＣＳ＃１１ライブラリ・インターフェース等の公開鍵暗号化基準（ＰＫＣＳ）をサポートする、ケルベロス・クライアントの実装を組み込んでもよい。ＰＫオペレーション・プロキシＳＤＫ８３５はＰＫＩＮＩＴ特性をサポートするためにＰＫＣＳ＃１１ ＡＰＩ機能の関連サブセットを実装してもよい。

ステップ９１６において、プロキシデバイス７１０はクライアントデバイス７０５に対して、クライアントデバイス７０５が利用可能なおよび／またはこれにアクセス可能な証明書のリストの要求を送信する。要求はＨＴＴＰヘッダに符号化されてもよい。たとえば、要求は、認証が要求されていることを示しかつ認証のためにクライアントデバイス７０５にチャレンジしているＨＴＴＰの４０１ステータスコードに符号化されてもよい。

図８を参照すると、プロキシＳＤＫ８３５は、クライアントデバイス７０５に送信された証明書要求（たとえば、ＰＫオペレーション要求）を取得しかつクライアントデバイス７０５がその要求に応答した場合に結果を受信するためにプロキシＳＤＫ８３５が使用してもよいパケットエンジン８２０へのカスタム・インターフェースを要求してもよい。証明書要求がリモート処理されることを必要とする場合は、プロキシＳＤＫ８３５は要求をバイナリ構造（必要に応じて暗号化／インテグリティ・ラッパを有する）に符号化して、パケットエンジン８２０に提示してもよい。パケットエンジン８２０はＨＴＴＰ４０１に、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎヘッダに符号化されたバイナリ構造を含む初期のＨＴＴＰ要求に応答してクライアントデバイス７０５へ送信されるカスタム認証チャレンジで応答させてもよい。

いくつかの態様では、プロキシデバイス７１０がクライアントデバイス７０５からの証明書のリストに対する要求に応答する応答を受信しない場合もある。特に、クライアントデバイス７０５が証明書要求に応答する（たとえば、ＰＫオペレーション）という保証はない。たとえば、クライアントデバイス７０５はクラッシュまたはその他により要求に応答できなくなる場合がある。さらに、クライアントデバイス７０５は（たとえば、鍵ストア８１５のロック解除のためにＰＩＮの入力をユーザに要求することによって）オペレーションに対するユーザの承諾を取得することを試みてもよいが、承諾を拒否される場合がある。

クライアントデバイス７０５がクライアント証明書のリストを返送しない状況に対処するために、プロキシデバイス７１０（プロキシＳＤＫ８３５コンポーネントなど）はタイムアウトを使用して最終的に証明書要求オペレーションを放棄してもよい。プロキシデバイス７１０はこれらの状況では適切なエラーコードを返送してもよい。ＰＫＩＮＩＴログオンの間、ＰＫＩＮＩＴログオンが成功、失敗または放棄されるか、もしくは時間切れになるまで、いくつかのＰＫオペレーションをデバイスに送信してもよい。

ステップ９１８において、クライアントデバイス７０５はプロキシデバイス７１０から証明書リストの要求を受信し、これに応答して、クライアントデバイス７０５が利用可能であるかまたは別様にアクセス可能な証明書を識別する。たとえば図８を参照すると、クライアントデバイス７０５のＭＡＭＰフレームワーク８０５は、プロキシデバイス７１０からのカスタム認証チャレンジを有するメッセージ（たとえば、ＨＴＴＰ４０１要求）を受信してもよい。これを証明書要求（たとえば、ＰＫオペレーション「認証」プロトコル）であると認識すると、ＭＡＭＰフレームワーク８０５は受信したヘッダフォーマットからメッセージを解読してメッセージのバイナリ構造をＰＫオペレーションＳＤＫ８１０へ転送する。ＰＫオペレーションＳＤＫ８１０は利用可能なクライアント証明書を認識していてもよい。

上述のように、クライアント証明書は物理的なスマートカード、仮想スマートカード等の形態であってよい。ＰＫオペレーションＳＤＫ８１０は要求を解読（あらゆる暗号化／インテグリティ・ラッパの処理を含む）し、それを適切な内部のハンドラに送信する。ハンドラは要求を処理し、利用可能な証明書のリストを生成する。証明書のリストは、たとえば、適切な鍵使用インジケータを有する証明書のみを含むように、要求されたオペレーションに対する関連性に従ってフィルタリングされてもよい。証明書のリストは残りの証明書が一つになるまでフィルタリングされてもよい。たとえば、オペレーションに使用するべき証明書を選別するために、クライアントデバイス７０５のユーザにＵＩを提示することによってリストをさらにフィルタリングしてもよい。リストはオペレーションの結果を示すバイナリ構造であってもよい。ＰＫオペレーションＳＤＫ８１０は、未だバイナリ構造であってもよい証明書のリストをＭＡＭＰフレームワーク８０５に返送してもよく、あるいはリストが生成できない場合はエラー状態を通知してもよい。

図９Ｂを参照すると、ステップ９２４において、クライアントデバイス７０５はプロキシデバイス７１０に利用可能な証明書のリストを含むメッセージを送信してよい。いくつかの態様では、メッセージはＨＴＴＰまたはＨＴＴＰＳメッセージとして送信されてもよい。たとえば、ＭＡＭＰフレームワーク８０５はプロキシデバイスからの元のＨＴＴＰ要求を再生してもよいが、利用可能な証明書のリストを含む要求に添付されているカスタムＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを使用してもよい。送信の前に、メッセージは暗号化／インテグリティ・ラッパにシールおよび／またはＨＴＴＰヘッダに適合するように符号化されてもよい。

ステップ９２６において、プロキシデバイス７１０はクライアントデバイス７０５からメッセージを受信する（および、必要であれば復号／解読してもよい）。図８を参照すると、パケットエンジン８２０は、クライアントデバイス７０５から受信したＨＴＴＰ要求がプロキシデバイス８１０によって送信された元の証明書要求の再送であることを認識してもよい。パケットエンジン８２０はＡｕｔｈｏｒｉｚａｔｉｏｎヘッダからのデータのバイナリ構造をクライアント側の認証モジュール８３０を介してプロキシＳＤＫ８３５に提示してもよい。プロキシＳＤＫ８３５はバイナリ構造（暗号化／インテグリティ・ラッパを含む）を解凍して、解凍したデータをクライアント側の認証モジュール８３０へ返送してもよい。

次に、プロキシデバイス７１０は、認証セッションに適した（すなわち、リソース／認証サーバでプロキシデバイス７１０を認証するための）証明書等の、リソース／認証サーバでプロキシデバイス７１０を認証するために使用する証明書を（証明書のリストから）選択してもよい。いくつかの実施形態では、ケルベロスおよびＳＳＬ規格によって、期待されるまたは要求される鍵使用を特定してもよい。たとえば、認証セッションがケルベロス認証を含む場合、プロキシデバイス７１０はケルベロスチケットを取得することを必要としてもよく、ケルベロスチケットの取得に適した証明書を選択することができる。ステップ９２４においてクライアントデバイス７０５が複数の証明書を返送した場合、プロキシデバイス７１０は、証明書のリストから選択するために入力することをユーザに求めてクライアントデバイスに選択要求を送信してもよい。

プロキシデバイス７１０およびリソースは認証セッションの間、メッセージの交換を続けてもよい。認証セッション中の１つ以上の時点で、プロキシデバイス７１０はクライアントデバイス７０５の、秘密鍵等の署名を用いた暗号化オペレーションの実行を要求されてもよい。秘密鍵はプロキシデバイス７１０が直接的に利用可能ではない場合がある。むしろ、秘密鍵はクライアントデバイス７０５の管理下に留まり、プロキシデバイス７１０が直接的に接触できない状態であってもよい。プロキシデバイス７１０は、署名（たとえば、秘密鍵）を取得するために専用の通信チャネルを介してクライアントデバイス７０５とやりとりしてもよい。

ステップ９２８において、プロキシデバイス７１０はクライアントデバイス７０５から選択された証明書に対応する署名に対する要求を生成する。プロキシデバイス７１０はまた、署名されるデータを生成してもよい。ケルベロス認証のために、このデータは選択された証明書を使用した認証サービス要求（ＡＳ＿ＲＥＱ）メッセージを含んでいてもよい。ＡＳ＿ＲＥＱメッセージは、クライアントデバイス７０５に送信される署名に対する要求に任意に添えられていてもよい。プロキシデバイス７１０は、クライアントデバイスが署名を提供する前に認証コンテキストの完全な詳細の確認を必要とする場合、クライアントデバイス７０５に未署名のＡＳ＿ＲＥＱメッセージを送信してもよい。プロキシデバイス７１０は、クライアントデバイスとプロキシデバイスとの間の通信プロトコルおよび／またはケルベロス認証の実装がクライアントデバイス７０５へのＡＳ＿ＲＥＱメッセージの送信をサポートしない場合、クライアントデバイス７０５にＡＳ＿ＲＥＱメッセージを送信しない場合がある。以下の実施例で説明するように、プロキシデバイス７１０は、クライアントデバイス７０５が署名すると、署名されたＡＳ＿ＲＥＱメッセージを認証サービス７１５および／またはリソース７２０に認証のために送信してもよい。

ステップ９３０において、プロキシデバイス７１０は署名の要求に含めるべき認証コンテキスト情報を決定する。いくつかの態様では、コンテキスト情報のサイズまたはフォーマットが限定されていない場合がある。たとえば、プロキシデバイス７１０はコンテキスト情報をバイナリ・ラージ・オブジェクト（ＢＬＯＢ）として送信してもよい。大略的に、コンテキスト情報はプロキシデバイス７１０とリソース／認証サーバとの間の認証セッションを識別する情報を含んでいてよい。以下の実施例でより詳細に説明するように、クライアントデバイス７０５はコンテキスト情報を使用してプロキシデバイス７１０とリソース／認証サーバとの間の認証セッションを検証または別様に確認してもよい。

ここで、コンテキスト情報の内容の実施例を提供する。コンテキスト情報はプロキシデバイス７１０とリソース／認証サーバとの間で事前に交換された認証情報のデータ構造を識別してもよい。たとえば、プロキシデバイス７１０およびリソースが既に認証メッセージを交換しておりかつ現時点が認証の途中である場合、コンテキスト情報は交換された認証メッセージの全てまたは一部を含んでいてよい。さらに／あるいは、コンテキスト情報は今後プロキシデバイス７１０によってリソース／認証サーバへ送信される認証情報のデータ構造を識別してもよい。たとえばケルベロス認証では、コンテキスト情報はプロキシデバイス７１０によってリソース／認証サーバへ送信されるＡＳ＿ＲＥＱメッセージの一部または全てを含んでいてもよい。

コンテキスト情報は認証セッションと関連付けられているタイムスタンプ情報を含んでいてもよい。タイムスタンプはプロキシデバイス７１０によって判定される現在の時間を識別してもよい。ケルベロス／ＰＫＩＮＩＴのために、認証サービス７１５および／またはリソース７２０は認証中のタイムスタンプの妥当性検証を行ってもよい。一般に、タイムスタンプは認証サービス７１５および／またはリソース７２０によって判定される現在の時間の合理的に厳格な許容差以内（たとえば、Ｘ秒以内）でなければならない。タイムスタンプは、認証サービス７１５および／またはリソース７２０でプロキシデバイス７１０を認証するために使用されるため、クライアントデバイス７０５による検証にも使用されてよい。

クライアントデバイス７０５とプロキシデバイス７１０はプロキシデバイス７１０と認証サービス７１５ほど時間的に密接に同期化されていない場合があるため、クライアントデバイス７０５はより大きな許容閾値（たとえば、Ｘ＋Ｙ秒）を使用してもよい。クライアントデバイス７０５は、認証セッションが最近（たとえば、直近の１分間、直近の１日の間等）行われたことを確認するためのタイムスタンプ情報を使用してもよい。

コンテキスト情報はプロキシデバイス７１０およびリソース／認証サーバによって使用される認証プロトコルのタイプを識別してもよい。たとえば、ケルベロス認証を使用する場合、コンテキスト情報は全体的にケルベロスを、またはケルベロスのＰＫＩＮＩＴ特性が使用されている場合はＰＫＩＮＩＴ／ケルベロスを識別してもよい。

一実施例として、「ＰＫＩＮＩＴに署名」を使用してもよい。コンテキスト情報はまた、署名または特定のプロキシデバイス７１０の実装を要求するアプリケーションも識別してもよい。たとえば、「ＮｅｔＳｃａｌｅｒでＰＫＩＮＩＴに署名」または「ＸｅｎＡｐｐでＰＫＩＮＩＴに署名」を使用することができる。ＳＳＬ認証を使用する場合、コンテキスト情報はＳＳＬを識別してもよい。一実施例として、「ＳＳＬ−クライアント−認証に署名」を使用してもよい。コンテキスト情報はまた、プロキシデバイス７１０がいずれのＳＳＬ認証オペレーションを実行しているのか（たとえば、オペレーション１、オペレーション２等）およびプロキシデバイス７１０がいずれのリソースで認証しているのかも識別してもよい。

コンテキスト情報はプロキシデバイス７１０がクライアントデバイス７０５によって提供される証明書のリストから選択した証明書を識別してもよい（たとえば、ステップ９２６）。選択された証明書を提供することにより、クライアントデバイス７０５はプロキシデバイス７１０およびリソースによって使用される認証プロトコルのタイプを把握できるようにしてもよい。

コンテキスト情報は、ケルベロスデータ構造またはＳＳＬデータ構造等の認証セッションのデータ構造を識別してもよい。たとえば、ケルベロス認証セッションは、プロキシデバイス７１０がコンテキスト情報を介して識別してもよい抽象構文記法１（ＡＳＮ．１）構造体を含んでいてもよい。特に、ＡＳ＿ＲＥＱの一部であってもよい、署名されるＡｕｔｈＰａｃｋはクライアントデバイス７０５が認識してもよいはっきり定義されたＡＳＮ．１構造を有していてもよい。ＳＳＬ認証のために、データ構造は証明書検証構造を含んでいてもよい。

コンテキスト情報はクライアントデバイス７０５が認証セッションを検証するために使用してもよい情報の特定の部分を含んでいてもよい。この情報の特定の部分はまた、認証セッションのデータ構造の識別に使用してもよい。たとえば、認証セッションがケルベロス認証を含む場合、コンテキスト情報はたとえば、ケルベロス認証と関連付けられたチェックサム、ケルベロス認証に使用されるケルベロス・ドメイン（たとえば、特定の認証サーバが処理するレルム）、クライアントデバイス７０５に関連付けられたケルベロスの主体名（たとえば、クライアントデバイス７０５に割り当てられたユーザネーム）、認証セッションに使用される鍵配信センター（ＫＤＣ）の識別子、要求されたチケット（たとえば、ＴＧＴチケットまたはセッションチケット）の有効期間、および認証セッション中に（たとえば、プロキシデバイス７１０とリソース／認証サーバとの間でそれまでに交換された認証メッセージに基づいて）設定されたケルベロスフラグを含んでいてもよい。

クライアントデバイス７０５が検証してもよいフラグの一実施例は「転送可能」フラグであり、これは結果として得られたチケットを他のデバイスへ転送してもよいことを示してもよい。上述のように、クライアントデバイス７０５によって署名されてリソース／認証サーバへ送信されるＡＳ＿ＲＥＱメッセージの一部または全体はクライアントデバイス７０５へ送信してもよい。

ＳＳＬ認証については、情報の特定の一部だけではクライアントデバイス７０５がプロキシデバイス７１０とリソース／認証サービスとの間のＳＳＬ認証セッションの内容を識別するのに十分ではない場合がある。たとえば、ＳＳＬ認証がプロキシデバイス７１０とリソースとの間を前後動したパケットの全シリーズのハッシュを生成するため、情報の特定の部分はクライアントデバイス７０５へのランダムデータに類似するであろう。

したがって、いくつかの実施形態において、ＳＳＬ認証のためのコンテキスト情報は、クライアントデバイス７０５からの署名を要求する前にプロキシデバイス７１０とリソースとの間の全体（またはほぼ全体）の認証の交信を含んでいてもよい。すなわち、ＳＳＬオペレーション（たとえば、ハンドシェイク・メッセージ）は全てクライアントデバイス７０５に提供されてもよい。プロキシデバイス７１０は実行されたＳＳＬオペレーションの累積ダイジェストを生成する。したがって、クライアントデバイス７０５は、クライアントデバイス７０５が検査を希望するハンドシェイクのあらゆる部分を検査してよく、これによりクライアントデバイス７０５はアクセスするリソースのアイデンティティの確認およびハンドシェイクが整形式であることの確認が可能になる。

いくつかの態様では、プロキシデバイス７１０は証明書オペレーションインターフェースを介してクライアントデバイス７０５にＳＳＬハンドシェイクプロセス全体を委託してもよい。ハンドシェイクが完了すると、クライアントデバイス７０５は、クライアントとプロキシとの間の専用通信チャネルのための鍵交換で保護されたマスターシークレットを供給してもよい。

ステップ９３２において、クライアントデバイス７０５はプロキシデバイス７１０から署名の要求を受信してそれに含まれるコンテキスト情報を抽出する。たとえば、クライアントデバイス７０５は要求メッセージを復号および／または解読してもよい。コンテキスト情報の例は上述した。

ステップ９３４において、クライアントデバイス７０５はコンテキスト情報の検証を試みる。クライアントデバイス７０５はコンテキスト情報を使用してプロキシデバイス７１０とリソース／認証サーバとの間の認証セッションが有効であることを確認してもよい。たとえば、クライアントデバイス７０５はコンテキスト情報を使用してプロキシデバイス７１０がリソース／認証サーバと通信していることおよびそれらの間で発生する通信のタイプを判定してもよい。

クライアントデバイス７０５は、たとえば、アクセスするリソースが意図するものである、要求された暗号化オペレーションが期待されたプロトコルの一部である、ならびに暗号化オペレーションの結果がプロキシデバイス７１０とリソースとの間の特定のプロトコルの対話の一部としてのみ有利に使用されるまたは使用することができるという、クライアントデバイス７０５を満足させるのに十分な、リソース認証プロトコルまたはプロキシの認証コンテキストの関連する部分（または全体）を認識するようにしてもよい。たとえば、クライアントデバイス７０５は、クライアントデバイス７０５が署名するように要求されたデータ（たとえば、ケルベロス認証のためのＡＳ＿ＲＥＱメッセージ）を検査して、そのデータ（または添付されたデータ）が期待された認証プロトコル（たとえば、ケルベロス、ＳＳＬ等）の構造体によって使用される周知の構造に確実に対応するようにしてもよい。データはまた、クライアントデバイス７０５が検証できる特定のデータ要素を潜在的に含んでいてもよい。あるいはまたはさらに、クライアントデバイス７０５はクライアントデバイス７０５が署名を提供する前に、データ内に認識可能および／または検証可能な期待される構造を検索するようにしてもよい。

コンテキスト情報が検証できない場合は（ステップ９３４においてＮＯ）、クライアントデバイス７０５はコンテキスト情報が検証できなかったことを示すメッセージを送信する。たとえば、クライアントデバイス７０５は要求された署名を含まない回答を送信してもよい。ケルベロス認証については、タイムスタンプがクライアントデバイス７０５によって設定された許容閾値外となる場合、検証は失敗の可能性がある。ＳＳＬおよびケルベロス認証のために、クライアントデバイス７０５は認証／リソースサーバの証明書に対して証明書チェーン検証を行ってもよいが、これは複数の理由のうちの何れかにより失敗する可能性がある。

ケルベロスに対する証明書チェーン検証は（ＡＳ＿ＲＥＱに対する回答であるＡＳ＿ＲＥＰに対応する）別のＰＫオペレーション・ステップを要求してもよい。ＳＳＬについては、プロキシデバイス７１０とリソースとの間のＳＳＬ認証メッセージの関連する部分がクライアントデバイス７０５に送信される場合は、チェーン検証が可能である。

いくつかの態様では、クライアントデバイス７０５がプロキシデバイス７１０によって既に提供されているコンテキスト情報を基に検証できない場合は、クライアントデバイス７０５はプロキシデバイス７１０からのさらなるコンテキスト情報を要求してもよい。

プロキシデバイス７１０がさらなるコンテキスト情報を提供することを決定した場合、プロキシデバイス７１０はステップ９３０へ戻り、クライアントデバイスに提供するためのさらなるコンテキスト情報を探し出す。さらなるコンテキスト情報は異なるタイプのコンテキスト情報であってもよい。たとえば、プロキシデバイス７１０が選択した証明書を識別する情報を事前に送っていた場合、プロキシデバイス７１０はプロキシデバイス７１０とリソース／認証サーバとの間で交換された認証メッセージ（たとえば、ケルベロス認証セッション中に設定されたケルベロスフラグまたはＳＳＬ認証セッション中に交換されたハンドシェイク・メッセージ）からの特定の情報を提供してもよい。署名のないメッセージを送信する代わりに、クライアントデバイス７０５はプロキシデバイスの署名要求に応答しない場合がある。

ステップ９３８において、プロキシデバイス７１０は署名が利用可能ではないことを示すメッセージを生成して、そのメッセージをリソース／認証サーバへ送信する。ステップ９７０において、リソース／認証サーバはプロキシが認証されていないと判定してもよく、それに対応して認証セッションを終了してもよい。すなわち、リソース／認証サーバはプロキシにセッション鍵（またはケルベロスの場合はチケット）を提供しない場合がある。

コンテキスト情報は検証されてもよい（ステップ９３４においてＹＥＳ）。ケルベロス認証については、たとえば受信したタイムスタンプがクライアントデバイスにおいて現在の時間の許容範囲内である場合および／または受信したＡｕｔｈＰａｃｋ内のチェックサムがクライアントデバイスによって計算されたチェックサムと一致する場合（ＡＳ＿ＲＥＱがコンテキスト情報として供給された場合）、検証は成功する可能性がある。

コンテキスト情報が検証された場合、ステップ９４２において、クライアントデバイス７０５は、プロキシデバイス７１０がステップ９２６において選択した証明書を使用して、プロキシデバイス７１０が提供したデータに署名する。たとえば、ケルベロス認証については、（たとえば、ステップ９３０において）プロキシデバイス７１０がクライアントデバイス７０５に未署名のＡＳ＿ＲＥＱメッセージを提供した場合、クライアントデバイス７０５はＡＳ＿ＲＥＱメッセージに署名してもよい。上述のように、未署名のＡＳ＿ＲＥＱメッセージの提供は任意である。あるいは、ケルベロスおよびＳＳＬ認証の両方については、プロキシデバイス７１０によって提供されたデータは、その上で署名が計算される一連のオクテット等の何らかのデータのチャンクを含んでいてもよい。

データに署名した後、ステップ９４４において、クライアントデバイス７０５は署名のあるメッセージおよび／または署名したデータをプロキシデバイス７１０に送信する。

ステップ９４６において、プロキシデバイス７１０はメッセージを受信して署名および／または署名したデータを抽出する。たとえば、以下にさらに詳細に説明するように、（他の一連のオクテットでもよい）署名はプロキシデバイスに返送され、リソースまたは認証サービスに送信されるのに適切な認証メッセージ内にプロキシデバイスによって挿入されてもよい。

図８を参照すると、パケットエンジン８２０はメッセージを受信してそのメッセージをプロキシＳＤＫ８３５へ転送してもよい。プロキシＳＤＫ８３５は署名をクライアント側の認証モジュール８３０に提供してもよい。

ステップ９４８において、プロキシデバイス７１０は署名を含む認証メッセージをリソース／認証サーバに送信する。認証メッセージは認証要求に応答して、ステップ９１２においてリソース／認証サーバが送信してもよい。概して、認証メッセージは、プロキシデバイス７１０がクライアントデバイス７０５によって要求されるリソースを取得するためのセッション鍵を取得するために使用してもよい。

たとえばケルベロス認証において、認証メッセージは、プロキシデバイス７１０がリソースとの安全な通信セッションのためのチケットを取得するために使用してもよいセッション鍵およびＴＧＴ等のチケットを取得するために使用するＡＳ＿ＲＥＱメッセージを含んでいてもよい。プロキシデバイス７１０がクライアントデバイス７０５から署名したＡＳ＿ＲＥＱメッセージを受信した場合、プロキシデバイス７１０はその署名されたＡＳ＿ＲＥＱメッセージをリソース／認証サーバに転送してもよい。プロキシデバイス７１０が署名を別に受信した場合は、プロキシデバイス７１０はＡＳ＿ＲＥＱメッセージを生成してそのＡＳ＿ＲＥＱメッセージに署名を添付してもよい。いくつかの態様では、ＡＳ＿ＲＥＱメッセージは、参照によりその全文が本明細書に組み込まれるＲＦＣ４５５６に記載されているように、ＰＡ−ＰＫ−ＡＳ−ＲＥＱフォーマットで符号化してもよい。

ステップ９５０において、リソース／認証サーバは認証メッセージを受信して、その認証メッセージが有効な署名を有するかどうかを判定する。署名が有効でない場合は、リソース／認証サーバは上述したステップ９７０（たとえば、プロキシデバイス７１０が認証されていないと判定するおよび／またはプロキシデバイス７１０との認証セッションを終了する）を実行してもよい。

ステップ９５２において、署名が有効であれば（ステップ９５０においてＹＥＳ）、リソース／認証サーバはセッション鍵を生成および／またはプロキシデバイス７１０に送信する。ケルベロス認証において、リソース／認証サーバはまた、ＴＧＴまたはサービスチケット等のチケットをプロキシデバイス７１０に送信してもよい。セッション鍵および／またはチケットは、プロキシデバイス７１０および／またはクライアントデバイス７０５が解読できる別の鍵を使用してカプセル化されてもよい。いくつかの態様では、メッセージはケルベロスＡＳ＿ＲＥＰメッセージとして送信されてもよい。

ステップ９５３において、プロキシデバイス７１０はセッション鍵および／またはチケットを受信して、そのセッション鍵および／またはチケットを格納（たとえば、キャッシュ）する。それらは後の使用のためにキャッシュされてもよい。たとえば、セッション鍵および／またはチケットは、後にクライアントデバイス７０５がさらなるリソースを要求する場合に使用してもよい。

図９Ａを参照すると、プロキシデバイス７１０はセッション鍵がステップ９１４においてプロキシデバイス７１０がクライアントデバイス７０５のためにリソースの取得を必要とする次回に利用可能であると判定してもよい。

図８を参照すると、ケルベロス認証については、クライアント側の認証モジュール８３０は、ＴＧＴおよび／またはサービスチケットとそれらの対応するセッション鍵を用いたユーザセッションのためにケルベロス・チケット・キャッシュを追加してもよい。

いくつかの実施形態では、プロキシデバイス７１０はリソース／認証サーバから受信したセッション鍵および／またはチケットを有するメッセージを解読するための鍵を備えていない場合がある。その代わりに、たとえば、クライアントデバイス７０５がプロキシデバイス７１０を完全に信頼していない場合は、クライアントデバイス７０５は鍵へのアクセスを制御してもよい。これらの実施形態では、プロキシデバイス７１０およびクライアントデバイス７０５は、セッション鍵および／またはチケットを含むカプセル化されたメッセージを解読するために（たとえば、さらなる証明書オペレーションにおいて）任意でさらなるメッセージのセットを交換してもよい。この交換は、ステップ９５３においてプロキシデバイス７１０がセッション鍵および／またはチケットを解読して格納する代わりに行われてもよい。

たとえばケルベロス認証において、参照によりその全文が本明細書に組み込まれるＲＦＣ４５５６のセクション３．２．３．１に記載されているように、ＰＫＩＮＩＴはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を使用してＴＧＴセッション鍵をラッピングするためのＡＳ回答鍵をネゴシエートしてもよい。あるいは、ＲＦＣ４５５６のセクション３．２．３．２に記載されているように、公開鍵暗号化がＫＤＣによって利用されて、証明書の公開ＲＳＡ鍵を用いてＫＤＣが生成するＡＳ回答鍵を暗号化してもよい。これによりプロキシデバイス７１０に、クライアントデバイス７０５に回答鍵を解読するように要求させてもよい。

これらの実施例では、クライアントデバイス７０５は、さらなるチケットを要求するためにＴＧＴのあらゆる使用を制御できるようにする（および希望すればそれらのサービスチケットの使用も制御できるようにする）ＴＧＴセッション鍵などのそれが保護する回答鍵および他の鍵を保持することを選択してもよい。したがって、ステップ９５３においてセッション鍵および／またはチケットを格納するプロキシデバイス７１０の代わりに、クライアントデバイス７０５がセッション鍵および／またはチケットを格納してもよい。これは、クライアントデバイス７０５がプロキシデバイス７１０をある程度信頼しているが完全には信頼していない場合に適切となる可能性がある。

ここで、公開鍵暗号化の使用についてより詳細に説明する。ＡＳ回答鍵を返送するためにＲＳＡ公開鍵暗号化が使用される場合、プロキシデバイス７１０は、ＫＲＢ−ＡＳ−ＲＥＰ回答メッセージのｅｎｃＫｅｙＰａｃｋフィールド等のリソースから受信したセッション鍵および／またはチケットを用いて回答メッセージのデータフィールド内のサブストラクチャのクライアントデバイス７０５からの証明書の秘密鍵の解読を要求してもよい。参照によりその全文が本明細書に組み込まれるＲＦＣ３８５２のセクション５．１に規定されているように、クライアントデバイス７０５による解読の結果得られたブロブ（blob）はＳｉｇｎｅｄＤａｔａ構造であってもよい。ＲＦＣ４５５６のセクション３．２．３．２に規定されているように、ＳｉｇｎｅｄＤａｔａ構造はｉｄ−ｐｋｉｎｉｔ−ｒｋｅｙＤａｔａのコンテントタイプおよびＲｅｐｌｙＫｅｙＰａｃｋ構造を含む内容フィールドを有していてもよい。ＳｉｇｎｅｄＤａｔａ上の署名フィールドは、クライアントデバイス７０５がＫＤＣの識別を確認するための証明書パスの検証を実行することを許可するＫＤＣの証明書を含んでいてもよい。したがって、ＲＳＡ公開鍵交換が使用される場合、クライアントデバイス７０５はプロキシデバイス７１０が認証しているＫＤＣの識別を完全に検証する能力を有していてもよい。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を使用する場合は、プロキシデバイス７１０はＫＤＣの証明書を参照してパスの確認を実行してもよい。プロキシデバイス７１０は鍵交換の完了にクライアントデバイス７０５を含むことを必要としなくてもよい。

あるいは、クライアントデバイス７０５はプロキシデバイス７１０に高い信頼を有し、セッション鍵および／またはチケットを含むメッセージの解読をプロキシデバイス７１０に許可してもよい。

これらの実施形態において、プロキシデバイスは、ステップ９５３に関して上述したように、メッセージを解読してセッション鍵および／またはチケットを格納してもよい。たとえば、プロキシデバイス７１０は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を制御して、（たとえば、ＴＧＴと関連付けられた）セッション鍵をさらなるクライアントデバイス７０５のサポート無しに復元することをプロキシデバイス７１０ができるようにしてもよい。この場合、プロキシデバイス７１０はＴＧＴの完全な制御を実行できるため、クライアントデバイス７０５による制限のない委託の許可をプロキシデバイス７１０に付与してもよい。

さらに／あるいは、プロキシデバイスはセッション鍵および／またはチケットを取得するためにＭｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ環境を利用してもよい。Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ環境において、プロキシデバイス７１０はドメインコントローラから（ＮＴＬＭクレデンシャル等の）ユーザのパスワードハッシュを受信することをプロキシデバイス７１０に許可するＰＫＩＮＩＴプロセスの拡張子をサポートしてもよい。これにより、プロキシデバイス７１０はケルベロス認証チャレンジと共にＮＴＬＭ認証チャレンジにも応答できるようになる。クライアントデバイスが（上述のように）ＴＧＴセッション鍵に対する制御を保持するためにＡＳ回答鍵を保持しない限り、プロキシデバイス７１０とクライアントデバイス７０５との間のさらなる対話はＮＴＬＭパスワードハッシュの復元には全く必要とされない。これはＴＧＴセッション鍵を伝達するために使用される同じＡＳ回答鍵でＮＴＬＭパスワードハッシュを暗号化してもよいためである。

ステップ９５４において、プロキシデバイス７１０はセッション鍵を使用して要求されたリソースを取得する。ステップ９５６において、サーバまたは他のデータベースはセッション鍵に基づいて要求されたリソースを提供する。ケルベロス認証については、リソース／認証サーバはステップ９５２においてＴＧＴおよび関連付けられたセッション鍵を提供していてもよい。この実施例では、プロキシデバイス７１０は、ＴＧＴを使用して要求されたリソースに対するさらなるケルベロスサービスチケットを取得することによってクライアントデバイス７０５のユーザに代わってインライン認証を実行してもよい。

図８を参照すると、クライアント側の認証モジュール８３０は、取得しているＰＫＩＮＩＴおよびケルベロスチケットがリソースに対するプロキシしたＨＴＴＰ要求の再試行を引き継いだ場合、パケットエンジン８２０に信号を送ってもよい。これは、セッション鍵／チケットキャッシュが追加された場合に実行してもよい。パケットエンジン８２０は、リソース取得のためにサービスチケットおよびセッション鍵から生成された適切なケルベロスバイナリ構造（ＡＰ＿ＲＥＱ）を含むＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを添付してもよい。上述のように、クライアントデバイス７０５はプロキシデバイス７１０を完全に信頼していない場合もある。

これらの実施例では、クライアントデバイス７０５はＴＧＴセッション鍵の所有を維持して、個々のリソースに対するサービスチケットを要求する際にクライアントデバイス７０５とやりとりするようにプロキシデバイス７１０に要求してもよい。このようにして、クライアントデバイス７０５はそれの代わりにプロキシデバイス７１０によってアクセスされたリソースの識別の可視性を確保することができる。

ステップ９５８において、プロキシデバイス７１０がリソースを取得すると、プロキシデバイス７１０はリソースをクライアントデバイス７０５に送信してもよい。ステップ９６０において、クライアントデバイス７０５は企業データまたはサービス等のデータまたはサービスにアクセスすること等によって要求されたリソースを受信してそれを希望通りに使用してもよい。上述のように、データまたはサービスはクライアントデバイス７０５上で保護するためにデータボルト６１６で暗号化してもよい。

いくつかの実施形態では、クライアントデバイス７０５は、（たとえば、プロキシデバイス７１０を介して）ＶＰＮトンネルまたはその他のタイプの通信チャネルを用いたＳｈａｒｅｐｏｉｎｔなどのリソース７２０と通信してもよい。（たとえば、図９Ａに示すステップ９１４において）リソース７２０からのリソース認証チャレンジを受信するプロキシデバイス７１０の代わりに、クライアントデバイス７０５はＶＰＮトンネルを介してチャレンジを受信してもよい。クライアントデバイス７０５は、プロキシデバイス７１０が認証を支援できるようにするためにプロキシデバイス７１０との第二の並列会話を確立（または事前に確立されたチャネルを介してプロキシデバイスと通信）してもよい。これは、クライアントデバイス７０５がケルベロス認証等の特定のタイプの認証を実行する機能を有していない場合があるため、有利である。

第二の並列会話の間、クライアントデバイス７０５はプロキシデバイス７１０へのリソース認証チャレンジを提示してもよい。プロキシデバイス７１０はその後、認証サービス７１５（たとえば、ケルベロス認証の場合はＫＤＣ）と通信して、リソースにアクセスするためにクライアントデバイス７０５に必要とされるセッション鍵（およびケルベロス認証の場合はケルベロスチケット）を取得してもよい。この点で、クライアントデバイス７０５、プロキシデバイス７１０、および認証サービス７１５の間で実行されるステップは、たとえば、図９Ａ〜図９Ｃを参照しながら上述した、ステップ９１４、ステップ９１６、ステップ９１８、ステップ９２４、ステップ９２６、ステップ９２８、ステップ９３０、ステップ９３２、ステップ９３４、ステップ９３６、ステップ９３８、ステップ９７０、ステップ９４２、ステップ９４４、ステップ９４６、ステップ９４８、ステップ９５０、ステップ９５２、および／または９５３のうちのいずれかを含んでいてもよい。

プロキシデバイス７１０が認証サービス７１５からセッション鍵および／またはチケットを受信した後、プロキシデバイス７１０はクライアントデバイスとプロキシデバイスとの間のセキュリティ保護された通信チャネルを介してクライアントデバイス７０５に鍵および／またはチケットを返信してもよい。クライアントデバイス７０５はここで、セッション鍵および／またはチケットを使用してリソース７２０から受信したリソース認証チャレンジに応答して要求されたリソースを取得してもよい。あるいは、プロキシデバイス７１０が鍵および／またはチケットをクライアントデバイス７０５に返送する代わりに、プロキシデバイス７１０はそれ自体が、リソース認証チャレンジへの応答を構成して、認証の応答をクライアントデバイス７０５に送信してもよい。クライアントデバイス７０５はこの応答をリソース７２０に転送して、要求されたリソースを取得してもよい。

図９Ａ〜図９Ｃに示すステップは、電子メールまたは他のドキュメントタイプ等のドキュメントへの署名および／または証明書秘密鍵によって保護されているデータの解読に適用されてもよい。ドキュメントへの署名の実施例では、プロキシデバイス７１０はクライアントデバイス７０５に署名するドキュメントを本明細書で説明するコンテキスト情報として提供してもよい。

図９Ａ〜図９Ｃに示すステップはまた、デスクトップおよび／またはアプリケーションの仮想化等の仮想化環境に適用してもよい。仮想化環境において、クライアントデバイス７０５は、図６に示すクライアントエージェント６０４または遠隔表示接続を確立するために使用される他の何らかのクライアントアプリケーション（たとえば、ＣＩＴＲＩＸ ＩＣＡ、ＣＩＴＲＩＸ ＲＤＰ等）等の仮想化アプリケーションを実行していてもよい。上述のように、クライアントデバイス７０５はこの状態でも、物理的または仮想のスマートカードに格納された鍵等のプライベート証明書を保護してもよい。

プロキシデバイス７１０は、図３に示す仮想化サーバ３０１等のアプリケーションまたはデスクトップ仮想化サーバを含むか、またはこれらの一部であってもよい。そのようなサーバはアプリケーションを実行してもよく、企業リソース等のリソースと通信してもよい。プロキシデバイス７１０とクライアントデバイス７０５との間の仮想化環境における通信は、ＣＩＴＲＩＸ ＩＣＡプロトコルまたはＣＩＴＲＩＸ ＲＤＰプロトコル等の、表示のリモート処理プロトコルを介して操作してもよい。リソースは、上述の企業リソース５０４、５０８、および／または６０８ならびに／もしくは企業サービス５０８および／または６０８を含んでいてもよい。

いくつかの実施形態では、図９Ａ〜図９Ｃに示すステップは仮想化環境に使用してもよい。あるいは、何らかの変更を加えてもよい。クライアントデバイス７０５とプロキシデバイス７１０との間のＨＴＴＰ通信は、ＣＩＴＲＩＸ ＩＣＡプロトコルまたはＣＩＴＲＩＸ ＲＤＰプロトコル等の、表示のリモート処理プロトコルを利用した通信に換えてもよい。ＰＫＯｐプロキシＳＤＫ８３５は第三者のアプリケーションを含んでいてもよい。したがって、上述のＰＫオペレーション・プロキシＳＤＫ８３５によって実行されるステップは第三者のプリケーションによって実行されてもよい。いくつかの態様では、プロキシデバイス７１０はこれらのステップを実行するために第三者のアプリケーションを呼び出してもよい。

ここで、仮想化の実施形態を説明する。仮想化サーバがＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）等のＯＳを起動する標準的ＯＳのケルベロスの実装を使用することができる。たとえば、ケルベロス・セキュリティ・サービス・プロバイダ（ケルベロスＳＳＰ）のＡｕｔｈｅｎｔｉｃａｔｉｏｎパッケージ（ＳＳＰ／ＡＰ）を使用してもよい。ケルベロスＳＳＰには（これらに限定されないが）、ＬｓａＣａｌｌＡｕｔｈｅｎｔｉｃａｔｉｏｎＰａｃｋａｇｅおよびＫＥＲＢ＿ＣＥＲＴＩＦＩＣＡＴＥ＿ＬＯＧＯＮを含む様々なプログラミング・インターフェースを利用できる。上述のＰＫＩＮＩＴケルベロス・ログオン・プロトコルを呼び出すために、顧客クレデンシャルプロバイダおよび顧客鍵格納プロバイダ（ＫＳＰ）と共に、クライアント証明書と同等のスマートカードを使用してもよい。ＫＳＰは、ＡｕｔｈＰａｃｋ構造のチェックサム等の秘密鍵で署名できるＰＫＩＮＩＴの特定のプロトコル要素に公開されてもよい。さらに、ケルベロスＳＳＰは、署名生成の最初のステップであるチェックサムの計算に使用されるＨａｓｈ ＡＰＩ等の暗号に関するオペレーションを呼び出すためにＯＳ ＡＰＩを使用してもよい。ケルベロスＳＳＰによって行われたＨａｓｈ ＡＰＩコールの傍受により、署名が計算されるプロトコル要素を知ることができる。Ｈａｓｈ ＡＰＩコールは、ケルベロスＳＳＰがＰＫＩＮＩＴを実行する信頼されたＬＳＡＳＳプロセスにロードされるカスタムＳＳＰを使用することによって傍受することができる。

上述のように、署名する構成要素はＲＦＣ４５５６のセクション３．２．１に記載されているＡｕｔｈＰａｃｋ構造を含んでいてもよい。さらに、プロトコル要素は、ＡＳＮ．１バイナリ符号化ルールに従う構造等の何らかの整形式の構造を有していてもよい。さらに、構造は、現在の時間を表すタイムスタンプを含み、クライアントデバイス自体の現在の時間の認識に対する基本的な妥当性確認を実施することをクライアントデバイス７０５に許可してもよい。

実際に起こり得る時間差異を許容するために、クライアントデバイス７０５は、たとえば認証サーバ（たとえば、ＫＤＣ）が許容するよりも広い時間差異の許容範囲を希望してもよい。たとえば、クライアントデバイス７０５は、ＫＤＣが許可する可能性のある５分間よりもむしろ、２４時間以内のそれ自体の時間的価値である時間的価値を受け入れてもよい。

いくつかの実施形態では、ＫＳＰは、最終的にＫＳＰを呼び出す証明書署名オペレーションを呼び出す前にケルベロスＳＳＰ内に準備されていてもよいＫＲＢ−ＲＥＱ−ＢＯＤＹバイナリ構造を確実に配置してもよい。ケルベロスＳＳＰへ戻るスタック等からこの構造が配置できる場合、その後ＡｕｔｈＰａｃｋの完全な検証が可能となってよい。あるいは、ケルベロスＳＳＰによって行われたＯＳ Ｈａｓｈ ＡＰＩコールの傍受により、ＡｕｔｈＰａｃｋ構造の準備の一部としてＫＲＢ−ＲＥＱ−ＢＯＤＹのチェックサムを計算するために、ＫＲＢ−ＲＥＱ−ＢＯＤＹ構造は直接的に可視であってもよい。その後、構造のコピーをプロキシデバイス７１０によってＰＫオペレーションの要求の一部としてクライアントデバイス７０５に送信することができる。同様に、ＡｕｔｈＰａｃｋ構造は署名構造体の一部としてＨａｓｈ ＡＰＩに対して可視であってもよい。

上述のように、クライアントデバイス７０５とプロキシデバイス７１０との間の専用通信チャネルはカスタムＧＳＳ−ＡＰＩ機構を含んでいてもよい。仮想化の実施形態では、専用通信チャネルは表示のリモート処理プロトコル内の仮想チャネルの内側にあってもよい。たとえば、ＳＳＰＩ仮想チャネルを使用してもよい。いくつかの態様では、ＳＳＰＩネゴシエーションが認証自体の完了に失敗した場合、表示のリモート処理プロトコルにサポートされている他の認証方法を代わりに使用することができる。

いくつかの実施形態では、本明細書で説明する態様をＣＩＴＲＩＸ ＸｅｎＡＰＰおよび／またはＸｅｎＤｅｓｋｔｏｐに適用してもよい。ＸｅｎＡＰＰおよびＸｅｎＤｅｓｋｔｏｐは、スマートカードリーダ・インターフェース（たとえば、ＰＣ／ＳＣ）をリモート処理するスマートカード仮想チャネルを使用してスマートカードのリモート処理をサポートしてもよい。本明細書で説明する態様は、Ｗｉｎｄｏｗｓ（登録商標）のログオンのためにＰＣ／ＳＣリモート処理を取り替えてもよい。セッションが確立されると、たとえばドキュメントに署名するためにスマートカードを使用するアプリケーションをサポートするためにスマートカードにアクセスしてもよい。これは、ＸＡ／ＸＤによって使用されるスマートカードＡＰＩフックを適切に構築して、それらをＷｉｎｄｏｗｓ（登録商標）のＬｏｇｏｎプロセス（たとえば、ｗｉｎｌｏｇｏｎ．ｅｘｅ、ｌｏｇｏｎｕｉ．ｅｘｅ等）に適用させないが、他のプロセスには通常適用させることによって達成してもよい。

クライアントデバイス７０５の観点から、リモート処理される証明書オペレーションはＰＫＩＮＩＴの特定の形態（たとえば、「ｓｉｇｎ−ｆｏｒ−ＰＫＩＮＩＴ−ｆｒｏｍ−ＸｅｎＡｐｐ」）に関連付けられていてもよく、ＰＫＩＮＩＴのために使用されるスマートカードのコンテキストは、必要であればアプリケーションがさらなるＰＩＮプロンプトをもたらすように終結時に即座に解放されてもよい。さらに／あるいは、スマートカードのコンテキストは、たとえば、プロキシデバイス７１０あるいは他のデバイスまたはサーバに対するクライアント証明書認証でＳＳＬを実行するためにクライアントデバイス７０５によって、ＰＫＩＮＩＴ要求の前に使用されていてもよい。このように、（このサービスを実行できる複数のデバイスから）リソースのアクセスオペレーションのために使用されるプロキシデバイス７１０を識別するブローカーサーバへのクライアントデバイス７０５による認証を可能にするためには単一のＰＩＮプロンプトで十分である。

選択されたプロキシデバイス７１０はその後、さらなるＰＩＮプロンプト無しに、かつクライアントデバイス７０５による明示的なＰＩＮキャッシングを要求することなく、ＰＫＩＮＩＴを実行してもよい。アプリケーションまたはデスクトップ仮想化サーバへのドメインログインの場合は、遠隔のスマートカードの認証の従来の方法に対して顕著なパフォーマンスの改善が達成される可能性がある。さらに、これは仮想のスマートカードに対して完全なリーダおよびスマートカードインターフェースの実装を必要とせずに達成することができる。

上述の態様には様々な変更が可能である。

各エンティティ（クライアントデバイス７０５、プロキシデバイス７１０、認証サービス７１５、および／またはリソース７２０）は、他のエンティティのアクティビティを認識するようにしてもよい。たとえば、各エンティティは１つ以上の他のエンティティに対する識別子を提供されてもよい。識別子は、図９Ａ〜図９Ｃに関して上述したメッセージ交換の何れかの間に提供されてもよい。たとえば、プロキシデバイス７１０はクライアントデバイス７０５を識別する情報を、プロキシデバイス７１０がリソース／認証サーバに送信した情報パケット内に注入してもよい。

プロキシデバイス７１０はまた、リソース／認証サーバを識別する情報を、プロキシデバイス７１０がクライアントデバイス７０５に送信した情報パケット内に注入してもよい。同様の方法で、クライアントデバイス７０５のタイプ（たとえば、ＰＣ、タブレット、スマートフォン等）を他のエンティティに提供してもよい。いくつかの態様では、参照によりその全文が本明細書に組み込まれるＲＦＣ６１１３に記載されているように、ケルベロスプロトコル・エクステンション（たとえば、ＭＳ−ＫＩＬＥ）を活用して、エンティティの活動を他のエンティティが利用可能にしてもよい。リソース７２０に識別情報を提供することによって、何者がデータにアクセスしているかおよび／または何者がデータへのアクセスを制限しているかもリソース７２０が判定できるようにしてもよい。

ケルベロスの場合、いくつかの実施態様（たとえば、Ｗｉｎｄｏｗｓ（登録商標）サーバ２０１２の実装）ではネットワークサービス認証中に２つの認証対象のアイデンティティを提供することが可能である。プロキシデバイス７１０は、Ｍｉｃｒｏｓｏｆｔケルベロスプロトコル・エクステンションのドキュメント［ＭＳ−ＫＩＬＥ］およびＲＦＣ６１１３に記載されているように、それ自体のケルベロスアイデンティティ（たとえば、ＴＧＴ）を使用してＴＧＳ交換を「防御」してもよい。この技術は、ＲＦＣ６１１３に記載されているようにＦＡＳＴと称される。

ユーザ／クライアントデバイス７０５およびプロキシデバイス７１０に対する複合アイデンティティを作成してもよい。Ｗｉｎｄｏｗｓ（登録商標）サーバ２０１２では、ＡＣＬがマシンのアイデンティティおよび他の要求を検査する機能を有する、Ｗｉｎｄｏｗｓ（登録商標） ＡＣＬフレームワークの上で稼働するリソースにこの複合アイデンティティを公開してもよい。Ｗｉｎｄｏｗｓ（登録商標）サーバ２０１２の実施態様を説明したが、当業者であれば、異なるオペレーティングシステムを使用したあらゆる他の実装を利用できることを認識するであろう。

プロキシデバイス７１０はクライアントデバイス７０５自体に関する情報の供給も行うために汎用型の要求機構を使用してもよく、この情報は（プロキシデバイス７１０に対するＳＳＬによるデバイス証明書認証等の他の手段から認識できる場合は）そのデバイスのアイデンティティまたは他の関連する特性、たとえば、認証中またはクライアントデバイス７０５からプロキシデバイス７１０へのリソースアクセスのプロセス中に学習できるデバイスのタイプ、ＯＳ、バージョン、またはセキュリティ姿勢等を反映する。

上述の態様の別の変更例は、クライアント証明書を使用するオペレーションをユーザに通知するユーザ・エクスペリエンスの調整を含んでいてもよい。プロキシデバイス７１０がクライアントデバイス７０５に提供する情報はユーザに対して表示されてもよい。別の実施例では、この表示はクライアントデバイス７０５がログオンプロセスの途中であることを示してもよいし、これはクライアント証明書も利用してよい。

ＰＩＮプロンプトも、クラス１リーダを使用してスマートカード等に対して表示してもよい。実行すべきオペレーションを忠実に表示するより詳細な表示をユーザに提供してもよい。たとえば、クライアント証明書を有するドキュメントへの署名については、ユーザのレビューのためにドキュメントを表示してもよい。実行すべき処理の適切な要約インジケータも表示してもよい。詳細な表示はクラス４等のスマートカードリーダのクラスの何れかに利用してもよい。いくつかの実施形態では、クライアントデバイス７０５はスマートカードリーダをシミュレート（または物理的なスマートカードとやりとりする場合はそのようなリーダーを使用してサポート）してもよい。

ユーザとの不必要なやりとり（interactions）を回避してもよい。たとえば、リモート処理される証明書オペレーションの範囲を適切に分類（たとえば、制限）してもよく、それにより同じグループ（たとえば、同じリソース認証プロトコルを使用するオペレーションのグループ）の一部である複数のオペレーションは、同じグループの一部であると認識されてもよく、論理グループを作成してもよい。

いくつかの態様では、１つの情報の表示またはプロンプトを同じグループ内でのオペレーションのためにユーザに表示してもよい。大略的には、この論理グループ分けは、従来の物理的なスマートカードの場合にスマートカードのコンテキストを取得および開放することに対応している。

構造的な特徴および／または方法論的な行為に特有の用語で主題を説明してきたが、添付の請求項で定義される主題は必ずしも上述した特有の特徴または行為に制限されるものではないことは理解されるべきである。むしろ、上述した特有の特徴および行為は以下の請求項の実施態様として説明されたものである。

関連出願の相互参照
本願は、２０１３年５月３日に出願された同じ発明の名称を有する米国特許出願第１３／８８６，８４５号の優先権を主張する。

Claims (20)

1. プロキシデバイスが、クライアントデバイスから、リソースに対する要求を受信し、
   前記プロキシデバイスからリソース管理デバイスへ、前記リソースに対する要求を送信し、
   前記プロキシデバイスと前記リソース管理デバイスとの間で認証セッションを開始し、
   前記プロキシデバイスによって前記クライアントデバイスに対する署名提供の要求を生成し、
   前記プロキシデバイスで前記クライアントデバイスから前記署名を受信し、
   前記プロキシデバイスから前記リソース管理デバイスへ前記署名を送信する、認証方法であって、
   前記クライアントデバイスに対する前記署名提供の要求は、（１）前記プロキシデバイスと前記リソース管理デバイスとの間で事前に交換された認証情報と、（２）前記プロキシデバイスによって前記リソース管理デバイスに送信されるべき認証情報とのうちの少なくとも１つのデータ構造を識別するコンテキスト情報を備える、方法。
2. 前記認証セッションの開始後、前記プロキシデバイスで前記クライアントデバイスから前記クライアントデバイスが利用可能なセキュリティ証明書のリストを受信することと、
   前記認証セッションのためのセキュリティ証明書を選択することと、
   をさらに含み、
   前記クライアントデバイスへの前記署名提供の要求は、前記選択されたセキュリティ証明書の識別を備えている、請求項１に記載の方法。
3. 前記署名を前記リソース管理デバイスに送信した後、前記プロキシデバイスで前記署名に対応するセッション鍵を受信することをさらに含む、請求項１に記載の方法。
4. 前記プロキシデバイスによって、前記リソース管理デバイスから前記要求されたリソースを取得するために前記セッション鍵を使用することをさらに含む、請求項３に記載の方法。
5. 前記プロキシデバイスから前記クライアントデバイスへ前記要求されたリソースを送信することをさらに含む、請求項４に記載の方法。
6. 前記認証セッションはＳＳＬ認証を備え、前記データ構造を識別する前記コンテキスト情報は前記認証セッション中に前記プロキシデバイスと前記リソース管理デバイスとの間で事前に交換されたＳＳＬ認証メッセージを備えている、請求項１に記載の方法。
7. 前記認証セッションはケルベロス認証を備え、前記データ構造を識別する前記コンテキスト情報はケルベロスデータ構造を識別する情報を備えている、請求項１に記載の方法。
8. 前記ケルベロスデータ構造は抽象構文記法１を備えている、請求項７に記載の方法。
9. 前記認証セッションはケルベロス認証を備え、前記データ構造を識別する前記コンテキスト情報は前記ケルベロス認証に使用するケルベロス・ドメイン、前記クライアントデバイスと関連付けられたケルベロス主体名、前記認証セッションに使用する鍵配信センターの識別子、要求されたチケットの有効期間、および前記認証セッション中に設定されたケルベロスフラグのうちの少なくとも１つを備えている、請求項１に記載の方法。
10. 前記コンテキスト情報は前記認証セッションに関連付けられたタイムスタンプを識別する、請求項１に記載の方法。
11. 前記コンテキスト情報は前記認証セッションのプロトコルタイプを識別する、請求項１に記載の方法。
12. 前記署名は前記クライアントデバイスでスマートカードから提供される、請求項１に記載の方法。
13. プロセッサと、コンピュータ実行可能な命令を格納するメモリとを備えるプロキシデバイスであって、
    前記命令が前記プロセッサによって実行されると、前記プロキシデバイスは、
    クライアントデバイスからリソースに対する要求を受信し、
    前記リソースに対する要求をリソース管理デバイスに送信し、
    前記プロキシデバイスと前記リソース管理デバイスとの間の認証セッションを開始し、
    （１）前記プロキシデバイスと前記リソース管理デバイスとの間で事前に交換された認証情報と（２）前記プロキシデバイスによって前記リソース管理デバイスに送信されるべき認証情報とのうちの少なくとも１つのデータ構造を識別するコンテキスト情報を含む、前記クライアントデバイスに対する署名提供の要求を生成し、
    前記クライアントデバイスから前記署名を受信し、
    前記リソース管理デバイスへ前記署名を送信する、プロキシデバイス。
14. 前記メモリは、前記プロセッサによって実行されると、前記署名を前記リソース管理デバイスに送信した後に、前記署名に対応するセッション鍵を前記プロキシデバイスに受信させる、コンピュータ実行可能な命令を格納している、請求項１３に記載のプロキシデバイス。
15. 前記メモリは、前記プロセッサによって実行されると、前記リソース管理デバイスから前記要求されたリソースを取得するために前記セッション鍵を前記プロキシデバイスに使用させる、コンピュータ実行可能な命令を格納している、請求項１４に記載のプロキシデバイス。
16. 前記認証セッションはＳＳＬ認証を含み、前記データ構造を識別する前記コンテキスト情報は前記認証セッション中に前記プロキシデバイスと前記リソース管理デバイスとの間で事前に交換されたＳＳＬ認証メッセージを含む、請求項１３に記載のプロキシデバイス。
17. 前記認証セッションはケルベロス認証を含み、前記データ構造を識別する前記コンテキスト情報はケルベロスデータ構造を識別する情報を含む、請求項１３に記載のプロキシデバイス。
18. 認証方法であって、
    クライアントデバイスからプロキシデバイスへ、リソースに対する要求を送信し、
    前記クライアントデバイスで前記プロキシデバイスから、（１）前記プロキシデバイスと前記要求されたリソースに関連付けられたリソース管理デバイスとの間で事前に交換された認証情報と（２）前記プロキシデバイスによって前記リソース管理デバイスに送信されるべき認証情報とのうちの少なくとも１つのデータ構造を識別するコンテキスト情報を備える、前記クライアントデバイスに対する署名提供の要求を受信し、
    前記クライアントデバイスによって、前記データ構造を検証し、
    前記データ構造の検証に応答して、前記クライアントデバイスから前記プロキシデバイスへ、セキュリティ証明書に対応する署名を送信する、方法。
19. 前記セキュリティ証明書は前記クライアントデバイスに接続されたスマートカードに格納される、請求項１８に記載の方法。
20. 要求に応答して、前記クライアントデバイスから前記プロキシデバイスへ、前記クライアントデバイスが利用可能な１つ以上のセキュリティ証明書を含むリストを送信することをさらに含み、
    前記クライアントデバイスに対する前記署名提供の前記受信された要求は前記１つ以上のセキュリティ証明書を含むリストから選択されたセキュリティ証明書の識別を備える、請求項１８に記載の方法。

Images