フェデレーテッド・リソースにアクセスするためのトークンの提供
【課題】エクストラネットおよびフェデレーテッド・アクセスを可能にし、Ｗｉｎｄｏｗｓ（登録商標）トークンをＤＭＺ内で動作するアプリケーションに供給することを可能にすること。
【解決手段】フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、およびインターネット接続を介してウェブ・サーバに結合された、ウェブ・サーバにサイン・オンすることができる、フェデレーテッド・パートナーに配置されたクライアントを含む、コンピュータ・ユーザを認証するシステム。
【解決手段】フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、およびインターネット接続を介してウェブ・サーバに結合された、ウェブ・サーバにサイン・オンすることができる、フェデレーテッド・パートナーに配置されたクライアントを含む、コンピュータ・ユーザを認証するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、その内容が参照によって本明細書に組み込まれている、２００４年１２月７日出願の米国特許仮出願第６０／６３４３５６号の利益を主張するものである。
【０００２】
本発明は、全般的には通信ネットワークに関し、より詳細には、ウェブ・アプリケーションのパッシブ・クライアント・シングル・サイン・オンに関する。
【背景技術】
【０００３】
近年、インターネットは、組織が互いに通信し、相互作用するための最も重要なツールの１つになってきた。インターネットを介するユーザによる、または関連するネットワーク内もしくはフェデレーテッド（federated）ネットワーク内のユーザによる、ネットワーク・リソースへのアクセスが、増加しつつある。通常のネットワークの外部に広がったユーザ・グループに対処するためのユーザ・ディレクトリの提供は、経時的に、これらのディレクトリを維持する努力と共に増加する傾向がある。セキュリティの理由から、特定の組織内のユーザは、しばしば、別の組織のリソースへのアクセスを許可される前に、認証される必要がある。ユーザ認証（authentication）を容易にするための別の機構が開発されてきた。そのような機構の１つが、Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＷＳ）−Ｆｅｄｅｒａｔｉｏｎである。ＷＳ−Ｆｅｄｅｒａｔｉｏｎは、拡張マークアップ言語（ＸＭＬ）セキュリティ・トークンを使用することによって、企業間の境界を横切ってアイデンティティの共有を可能にする。これらのＸＭＬトークンは、ＳＡＭＬ（Security Assertion Markup Language）またはＸｒＭＬ（Extensible Rights Markup Language）などのフォーマットを使用する。
【０００４】
通常、セキュリティ・トークン内のクレイム（claim：申告）は、一対の企業間を流れる。しかし、セキュリティの理由から、ウェブ・クライアントまたはネットワーク・パートナーがアクセスするリソースが、セキュリティ境界の外側に配置される場合がある。セキュリティ境界の確立は、セキュリティを保つために、シャドウ・ディレクトリと、トークン転送機構を要求する場合がある。この配置は、ユーザによるマルチプル・サイン・オンを要求する。通常のトークン交換では、トークンのオリジネータを、アイデンティティ・プロバイダと呼ぶ。アイデンティティ・プロバイダは、ユーザのアイデンティティおよび認証を所有する。トークンの消費者を、リソース・プロバイダと呼ぶ。リソース・プロバイダは、任意の個数のウェブ・サービスまたは他のアプリケーションを提供することができる。暗号による信頼を、２つの当事者間で確立することができ、その結果、リソース・プロバイダが、セキュリティ・トークンのオーソリティとしてアイデンティティ・プロバイダを認証することができる。
【０００５】
【特許文献１】米国特許出願第０９／８８６１４６号
【特許文献２】米国特許出願第１０／０２９４２６号
【特許文献３】米国特許出願第１０／４３６８８０号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
エクストラネットおよびフェデレーテッド・アクセスを可能にし、Ｗｉｎｄｏｗｓ（登録商標）トークンをＤＭＺ内で動作するアプリケーションに供給することを可能にすることが必要とされている。
【課題を解決するための手段】
【０００７】
本発明は、コンピュータ・ユーザを認証するシステムに関する。このシステムは、フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、およびインターネット接続を介してウェブ・サーバに結合された、ウェブ・サーバにサイン・オンすることができる、フェデレーテッド・パートナーに配置されたクライアントを備える。
【発明を実施するための最良の形態】
【０００８】
この説明は、添付図面に鑑みて次の説明を読むことからよりよく理解される。添付図面で、同一の符号が、同一の部分を指定するのに使用されている。
【０００９】
添付図面に関して下で示す詳細な説明は、この例の説明として意図されたものであり、この例が構成したりまたは使用したりすることのできる唯一の形態を表すことを意図してはいない。この説明は、この例の機能と、この例を構成し、および動作させるためのステップのシーケンスとについて記述している。しかし、同一のまたは同等の機能およびシーケンスを、異なる例によって達成することもできる。
【００１０】
この例を、本明細書でインターネット・システムに実装されるものとして説明し、図示するが、説明されるシステムは、制限ではなく例として提供される。当業者が諒解するように、この例は、さまざまな異なるタイプのネットワーク・システムでの応用に適する。
【００１１】
作成され、企業ネットワーク（corporate networks）で現在使用されている多数の既存ウェブ・アプリケーションがある。これらのアプリケーションの多くは、アプリケーションへのアクセスを制限するのに伝統的なＷｉｎｄｏｗｓ（登録商標）許可制御機構（authorization mechanisms）を使用する。アプリケーションでは、これは、Ｗｉｎｄｏｗｓ（登録商標）ＳＩＤ（Security Identifier）（ユーザＳＩＤおよびグループＳＩＤ）を使用するＷｉｎｄｏｗｓ（登録商標）ベースのアクセス制御リスト（「ＡＣＬ」）に対するアクセス検査をＷｉｎｄｏｗｓ（登録商標）トークンを用いて行えるようにするためにＳＩＤを含むＷｉｎｄｏｗｓ（登録商標）トークンを受け取ることを意味している。企業イントラネットからアクセスするだけでなく、インターネットから、およびパートナーの企業のネットワークからアクセス可能になるように、アプリケーションを移動させる傾向が増大している。これらのアプリケーションを移動させる負担を最小にするために、Ｗｉｎｄｏｗｓ（登録商標）許可制御（authorization ）を使用し続けることを可能にする最小限の変更（modification）が行われる。これを達成する第１ステップは、通常、アプリケーションを、関連するネットワークをアクセスから隔離するＤＭＺに移動することを要求する。ＤＭＺに課せられる通常のセキュリティ制約のゆえに、余分のシャドウ・アカウント（extra shadow accounts）を利用しない限り、現在のＷｉｎｄｏｗｓ（登録商標）認証機構を使用して、ＤＭＺ内のアプリケーションでＷｉｎｄｏｗｓ（登録商標）トークンを作成することは、通常は不可能である。
【００１２】
シャドウ・アカウントとは、実際の企業ユーザまたはパートナー・アカウントをシャドウイングするアカウントであり、たとえば、企業従業員は、企業ネットワーク内にアカウントを有し、ＤＭＺ内に追加のシャドウ・アカウントを必要とする。シャドウ・アカウントは、通常、Ｗｉｎｄｏｗｓ（登録商標）許可制御を可能にするために提供される。通常、シャドウ・アカウントは、これを更新したり、維持したりするのに管理者にかなりの労力を要求する。
【００１３】
トークンは、通常、ユーザを認証するのに使用される。ＡＤＦＳ（Active Directory Federation Service）（登録商標）は、データを交換するためのＤＭＺ内のアプリケーションに対する認証および許可制御のためにＡＤＦＳトークンを供給する認証システムの例である。ＡＤＦＳは、Ｗｉｎｄｏｗｓ（登録商標）トークンと異なるトークンを供給する。許可制御を提供するＷｉｎｄｏｗｓ（登録商標）トークンを、通常、ＮＴトークンと称する。提供される例は、エクストラネットおよびフェデレーテッド・アクセスを可能にすることができ、Ｗｉｎｄｏｗｓ（登録商標）トークンをＤＭＺ内で動作するアプリケーションに供給することを可能にすることができる。全体的な効果は、通常のセキュリティ手段または通常使用される制約と干渉しないこととすることができる。セキュリティ・トークンを転送する方法は、その内容が参照によって本明細書に組み込まれている２００４年１１月１９日に出願された米国特許出願第１０／９９３７４５号および２００５年５月１３日に出願された米国特許出願第ＴＢＤ号（弁理士整理番号３１２１５９．０１）に記載されている。
【００１４】
シングル・サイン・オン（「ＳＳＯ」）の第１の例は、コンピュータ・ユーザに、そのユーザが複数のアプリケーションにアクセスするときであっても、単一のアイデンティティを用いて、およびセッション当たり単一のログインによって、さまざまなリソースにアクセスする能力を与えることができる。第１の例は、追加の許可制御データを備えたＡＤＦＳトークンを供給することができ、その結果、Ｗｉｎｄｏｗｓ（登録商標）認証を実行できるようにするＷｉｎｄｏｗｓ（登録商標）ＮＴトークンを構成できるようになる。シングル・サイン・オンは、ユーザのアクティブ・ディレクトリ・アカウントがない状態でのウェブ・エージェントでのＮＴトークンの作成を可能にすることができる。したがって、第１の例では、認証データがトークンで供給されるので、シャドウ・アカウントを除去することができる。ウェブ・シングル・サイン・オン（「ＷｅｂＳＳＯ」）は、ブラウズ可能ウェブ・サイトだけに適用できる、ＳＳＯのサブセットである。ブラウズ可能ウェブ・サイトは、インターネットの人気に起因して、現在、ＳＳＯの支配的な形とみなされているのも当然である。
【００１５】
ＷｅｂＳＳＯ設計は、インターネット上のウェブ・サービスが使用するプロトコルおよびトークン・フォーマットを提供するように構成することができる。この方法の全般的な説明は、企業アカウントについて、企業アカウント・フォーレストからのＳＩＤが、企業ネットワーク内のＦＳ（Federation Server）によってＡＤＦＳトークン内に入れられるということである。次に、このＳＩＤが、ＤＭＺ内のＦＳによってフィルタリングされ、その後、ウェブ・サーバ（ＷＳ）のＡＤＦＳウェブ・サーバ・エージェントによって拡張される。次に、ＡＤＦＳウェブ・サーバ・エージェントが、これらのＳＩＤからトークンを作る。ＡＤＦＳトークンが、この過程の各ステップで認証されることに留意されたい。
【００１６】
フェデレーテッド・パートナー・アクセスまたはフェデレーテッド・リソース・サイン・オンの第２の例について、フェデレーテッド・パートナーは、ＤＭＺ内のアプリケーションにアクセスするために、Ｗｉｎｄｏｗｓ（登録商標）トークンも必要とする場合がある。従来のフェデレーテッド・パートナーには、シャドウ・アカウントが、通常、必要である、というのは、フェデレーテッド・パートナーのＷｉｎｄｏｗｓ（登録商標）（商標）フォーレストからのＳＩＤが、リソースＤＭＺでは役に立たないからである。通常、あるネットワークのＳＩＤは、別のネットワークにとって無意味である。この第２の例は、ウェブ・サーバが、アクティブ・ディレクトリ３０５からアカウント情報を転送するトークンを構成することによって、シャドウ・アカウントなしのフェデレーテッド・ユーザに対して従来のＷｉｎｄｏｗｓ（登録商標）ベース認証を使用することを可能にすることができる。フェデレーテッド・パートナーに対するＷｉｎｄｏｗｓ（登録商標）トークンを作るのに使用される処理を、下でさらに説明する。
【００１７】
さらに、ウェブＳＳＯは、コンピュータ・オペレーティング・システムのアイデンティティおよびアクセス管理機能を容易にする傾向がある。たとえば、本明細書で提示するシングル・サイン・オンの例は、シャドウ・アカウントを除去することによって、シャドウ・アカウントに関連するオーバーヘッドを減らす傾向がある。
【００１８】
図１に、コンピュータ・オペレーティング・システム１０４の一部として、シングル・サイン・オン１０７およびフェデレーテッド・リソース・サインオン１０８を示す。コンピュータオペレーティングシステム１０４に、通常、そのオペレーティング・システムのうちでネットワーキングを容易にすることができる部分１０５が含まれる。使用可能なネットワーキング機能１０５のうちで、シングル・サイン・オン（「ＳＳＯ」）１０６機能を、下で説明する例で、提供することができる。具体的に言うと、シャドウ・アカウントの除去を可能にするシングル・サイン・オン（「ウェブＳＳＯ」）１０７、およびシャドウ・アカウントの除去を可能にするフェデレーテッド・リソースへのアクセスを可能にするサイン・オン１０８を説明する。ウェブＳＳＯ １０７の第１の例は、フェデレーテッド・リソース・サイン・オン１０８の第２の例と独立に動作することができる。
【００１９】
エクストラネット・リソースにアクセスするためのトークン
ウェブ・シングル・サイン・オンは、通常、孤立して動作するコンピュータには存在しない。ウェブＳＳＯは、１つまたは複数のネットワークを形成するように連携して動作する複数のプロセッサ・ベース・デバイス上に、またはコンピューティング・デバイス１０１、１０２、１０３上に提供することができる。ネットワークを構成するコンピューティング・デバイスに、通常、サーバ１０３、ＰＣ １０２、ラップトップ・コンピュータ１０１、および類似物が含まれる。任意の台数のこれらのコンピューティング・デバイスに、ウェブＳＳＯ機能を与えることができ、その結果、これらが、ネットワークの機能のセキュリティおよび滑らかな動作を維持しながら、ＳＳＯ機能を提供するネットワークへのアクセスを試みる１つまたは複数のクライアント・コンピュータと共に動作できるようになる。フェデレーテッド・リソースへのアクセスを可能にする方法を、オペレーティング・システム１０４内に置くこともできる。フェデレーション・アクセス方法は、必ずしも、ＳＳＯ機能と同一位置にある必要はなく、互いに独立に存在することができる。
【００２０】
図２に、ウェブＳＳＯを実装するさまざまなネットワークの例を示す。ウェブＳＳＯを実施する際に、通常は、ＳＳＯ実施形態に特に重要になる可能性がある３つのネットワーク・コンポーネント（またはプレイヤ）がある。さまざまな構成でこれらのコンポーネントを展開する（利用可能に準備する）ことによって、さまざまなウェブＳＳＯ構成を可能にすることができる。
【００２１】
まず、ウェブ・サイトにアクセスするためにユーザが実行するプログラムとすることのできるウェブ・クライアント（ユーザ）２０８〜２１１が存在する可能性がある。この例に、インターネットにアクセスできる、普通のアプリケーションまたはブラウザが含まれる。
【００２２】
第２のコンポーネントは、通常は、ユーザがアクセスするリソースを含むサービスである、ウェブ・サイト（リソース所有者）２１２である。この例には、ユーザがアクセスすることができるさまざまなアプリケーション、ウェブページ、またはウェブ・サイトを含めることができる。ＳＳＯ状況では、企業などの組織が、インターネット上のクライアント２１０がアプリケーションにアクセスできるように、ＤＭＺ内にウェブ・サイト２１２を展開する（利用可能に準備得する）ことを望む可能性がある。この例では、企業が、許可制御を変更するためにアプリケーションをリワークすることなく、アプリケーションをイントラネット２０３からＤＭＺ ２０２に移動できる場合がある。しかし、ＤＭＺへのアプリケーションの移動は、過去において、従来の許可制御標準規格またはアクセス制御リストを介して信頼を確立するためにシャドウ・アカウントを設けることを必要とした。
【００２３】
最後に、通常は、ウェブ・サイト・リソースへのユーザ・アクセスを制御するためのアイデンティティおよび属性を定義するサービスであるアカウント・ストア（アカウント・アドミニストレータ）２０４〜２０７コンポーネントがある。この例に、ＬＤＡＰベース・ディレクトリ、ＳＱＬベース・データベース、および類似物を含めることができる。リソースは、イントラネット２０１、ＤＭＺ ２０２、またはインターネット２１８に常駐することができる。
【００２４】
ウェブＳＳＯを実装するシステムは、異なるＷｅｂＳＳＯシナリオを可能にするために３つの前に述べたコンポーネントを展開する（利用可能に準備する）ときに、柔軟性を提供する。この３つのコンポーネントのさまざまな構成は、Ｂ２Ｅ ２１７構成、フェデレーテッドＢ２Ｂ ２１４構成、フェデレーテッドＢ２Ｃ ２１５構成、およびエクストラネット２１６構成を可能にする。エクストラネット・リソースへのアクセスにトークンを使用することの第１の例を、エクストラネット構成２１６に示す。フェデレーテッド・リソースへのアクセスにトークンを使用することの第２の例を、フェデレーテッドＢ２Ｃ ２１５構成およびフェデレーテッドＢ２Ｂ ２１４構成に示す。第１および第２の例を、下でさらに説明する。
【００２５】
Ｂ２Ｅ（Business to Enterprise）２１７は、通常、サイト自体の会社の従業員２１１が、その企業のアカウント・ストア２０７からの従業員アイデンティティを使用して、ウェブ・サイト２１２にアクセスすることを可能にする。従業員は、イントラネットからまたはｖｐｎを必要とせずにそのウェブの外部から、このサイトにアクセスすることができる。フェデレーテッドＢ２Ｂ（Federated business to business）２１４は、通常、パートナー企業の従業員２０８が、彼らの（パートナー企業の）アカウント・ストア２０４からのアイデンティティを使用してウェブ・サイト２１２にアクセスすることを可能にする。フェデレーテッドＢ２Ｃ（Federated business to consumer）２１５は、通常、インターネット上の消費者２０９が、外部消費者アカウント・ストア（Ｐａｓｓｐｏｒｔなど）２０５からのアイデンティティを使用してウェブ・サイト２１２にアクセスすることを可能にする。Ｂ２Ｂは、通常、ある種の提携協定（partnering arrangement）を有する異なる企業の間のｅ−ｃｏｍｍｅｒｃｅを指し、個人または企業が別の企業の製品またはサービスを購入するＢ２Ｃまたはｂｕｓｉｎｅｓｓ−ｔｏ−ｃｏｎｓｕｍｅｒ関係と対照的である。エクストラネット２１６は、通常、消費者またはアドホックなパートナー２１０が、ウェブ・サイトの企業自体によって彼らに発行されたアカントで、そのサイトにローカルなエクストラネット・アカウント・ストア２０６で管理されるアカウントを使用して、ウェブ・サイト２１２にアクセスすることを可能にする。
【００２６】
このシナリオ２１４〜２１７のそれぞれで、ウェブ・サイト２１２は、異なるアカウント・ストア２０４〜２０７を効果的に信頼する。ウェブ・サイト２１２は、ローカル・アカウント・ストア２０６および２０７を直接に信頼し、パートナーまたは消費者のアカウント・ストア２０４および２０５を間接的に、フェデレーションを介して信頼する。フェデレーテッド信頼は、通常は、２つのアカウント・ストア所有者の間のビジネス・レベル契約を必要とする。したがって、１つのウェブ・サイトが、図示のように構成を混合して、調和させることができる。
【００２７】
セキュリティは、ウェブＳＳＯ構成で維持される。ＷｅｂＳＳＯは、通常は、安全な方法で各構成によって提示される異なる信頼シナリオを実装するためにアカウント・ストアおよびウェブ・サイトによって使用される認証（authentication）と許可制御（authorization）のインフラストラクチャを提供する。Ｂ２Ｅの例２１７では、従業員２１１が、内部サイトおよびＤＭＺ企業ウェブ・サイトならびにアウトソーシングされたベネフィッツ・サイト（benefits site）に、その従業員の企業アクティブ・ディレクトリ・アンデンティティ２０７を使用するシングル・サイン・オンを用いてアクセスすることができる。Ｂ２Ｂの例２１４では、ＷｅｂＳＳＯは、第１の組織が、第２の組織によってそれ自体のアクティブ・ディレクトリ２０４内で定義されて維持されるアイデンティティを使用して、ＤＭＺ ２０２内のＳｈａｒｅＰｏｉｎｔサイト２０６を第２の組織の従業員２０８とフェデレーテッド（連携）させることを可能にすることができる。
【００２８】
上で使用された用語の定義を、提供される例をユーザが理解するのを助けるために、次の段落でも提供される。しかし、これらの定義は、これらの例の実践を開示される構造に制限することを意図されたものではない。提供される例が、さまざまなネットワーク構成に適用できるものであり、１製造業者の設計、標準規格、または特定の実施形態に制限されないことを理解されたい。
【００２９】
フェデレーションは、通常、ユーザ・アイデンティティおよび権利付与（entitlements）を組織の間で可搬にするのに使用される契約、標準規格、および／または協力テクノロジを有する異なる組織（たとえば、異なる自律的アイデンティティ・ドメインまたは領域）の連携（association）を指す。この形では、ある領域のユーザは、複数のログオン・イベントなしで、異なる領域のウェブ・アプリケーションにアクセスすることができる。
【００３０】
フォーレスト（forest）は、より密接に関係する組織をリンクするのに使用することができる。ドメインは、しばしば、組織とそのメンバを表すのに使用される。ツリーは、通常は、ドメインまたは子ドメインのコレクションである。１つの企業内など、密接に関係するビジネス・エンティティを管理するために、各めいめいのツリー（tree）を、ドメイン・フォーレスト（forest）内で相互接続することができる。フォーレスト内のツリーは、通常、両方向の信頼関係によって接続される。ツリーが、一緒にグループ化され、フォーレスト内で１つのネットワーク・システムとして実装されると、フォーレスト境界が、信頼（たとえば、セキュリティ）境界になり、ドメイン・グループに対する管理上の分離の単位になる。
【００３１】
非武装地帯（「ＤＭＺ」）は、通常はローカル・エリア・ネットワーク（「ＬＡＮ」）とインターネットの間の境界で確立される周辺（perimeter）セキュリティ・ネットワークを指す場合がある。そのようなＤＭＺは、ＬＡＮ上のサーバをインターネット上の悪意のあるユーザから保護する役目を果たす。通常、ファイヤウォールが、ＬＡＮとＤＭＺの間にある。ＤＭＺに、プロキシ・サーバ、ウェブ・サーバ、および仮想プライベート・ネットワーク（「ＶＰＮ」）サーバが含まれる場合がある。プロキシ・サーバは、通常、ＬＡＮ上の情報にアクセスする外部ユーザにセキュア・アクセスを提供し、通常は、クライアント・コンピュータにトランスペアレントに見える。プロキシ・サーバは、特定のリソースへのアクセスを許さないようにプログラムすることができる。ウェブ・サーバは、通常、インターネット上の誰もがアクセス可能である。ＶＰＮサーバは、通常、インターネットを介するＬＡＮへのセキュア・アクセスを可能にするリモート・アクセス認証サーバ（remote access and authentication servers）である。ネットワークへのセキュア・アクセスは、従来のＫｅｒｂｅｒｏｓシステムなどのさまざまなセキュリティ・プロトコルによって提供することができる。セキュリティ・プロトコルとは、ネットワークおよびシステムが、これらのネットワークおよびシステムのリソースにアクセスするユーザ、コンピュータ、およびアプリケーションを認証できるようにするプロトコルである。セキュリティ・プロトコルは、さまざまな形の暗号化を使用して、ユーザの信任証（credentials）およびネットワーク通信の、プライバシ、信憑性（authenticity）、および保全性（integrity）を保証する。
【００３２】
図３は、エクストラネット・リソースへのアクセスにトークンを使用し、シャドウ・ディレクトリが除外されることを可能にする、ウェブＳＳＯ中のセキュリティを維持するのに通常使用されるシステム・コンポーネントを示すブロック図である。ウェブＳＳＯは、次のコンポーネントを提供することによってセキュリティを維持することができる。
【００３３】
第１に、アクティブ・ディレクトリのセキュリティ・トークン・サービス・プロキシ３０１を提供する。これらのサービスは、アクティブ・ディレクトリ３０５に含まれるアイデンティティおよび属性に関する、ウェブに対して適切なセキュリティ・トークン（web-appropriate security tokens）を作る。アクティブ・ディレクトリ３０５は、イントラネット３１３内にあり、ＤＭＺ ３１４内のプロキシ化されたサービス３０９によって保護されている。ウェブ・サーバ（「ＷＳ」）３２０は、アプリケーションをクライアントまたはウェブ・クライアント３１１から使用可能にするために、ＤＭＺ内に展開（使用可能に準備）される。ＤＭＺ内にＷＳを展開（使用可能に準備）することは、通常、ＤＭＺイントラネット境界をまたぐことによるセキュリティ問題を引き起こさずにＷＳとＦＳＲとの間で信頼が確立されるようにするために、ＤＭＺ内にＦＳＲ ３０９を展開（使用可能に準備）することを要求する。ＦＳＰ−Ａ ３２１は、ＦＳ Ａ ３０８のプロキシ・サーバである。
【００３４】
第２に、ウェブ・サイト信頼を管理するフェデレーション・サービス３０２が、さまざまなアカウント・ストア所有者との信頼を定義し、制御する機構をリソース所有者に与える。フェデレーション・サービスは、参照によってその内容を本明細書に組み込まれている２００１年６月２０に出願された特許文献１および２００１年１２月２１に出願された特許文献２に記載されている。
【００３５】
第３は、ウェブ・アプリケーションのＳＳＯエージェント・プロセス・セキュリティ・トークン３０３である。これらのエージェント（ＩＳＡＰＩエクステンションおよびトークン／クレイム・ライブラリ）は、セキュリティ・トークンを、アクセス制御のためにＩＩＳアプリケーションによって使用される、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社の商標）Ｉｍｐｅｒｓｏｎａｔｉｏｎコンテクスト・ロールまたはＡＳＰ．Ｎｅｔロールに変換することができる。代替実施形態では、セキュリティ・トークンを処理する同等のエージェントに置換することができる。セキュリティ・クレイムは、参照によってその内容を本明細書に組み込まれている２００５年４月２９日に出願された米国特許出願第１１／１１９２３６号にさらに詳細に記載されている。
【００３６】
第４に、インターオペラブル・ウェブ・サービス・プロトコルまたはパッシブ・クライアント・プロトコル３０４を提供する。アカウント・ストアおよびウェブ・サイトは、通常、直接には通信せず、セキュリティ・トークンが、これらの間で、ウェブ・サービス・フェデレーション・パッシブ・クライアント・プロトコルなどのプロトコルを使用して、クライアントによって、それらの間に伝えられる。このタイプのプロトコルは、ＳＡＭＬトークンおよびＸｒＭＬトークンを含むウェブ・サービス−セキュリティＸＭＬセキュリティ・トークンを交換する。代替案では、他の同等のプロトコルおよびトークン交換を使用することができる。例示的なインターオペラブル・ウェブ・サービス・プロトコルが、参照によってその内容を本明細書に組み込まれている２００３年５月１２に出願された特許文献３にさらに詳細に記載されている。
【００３７】
第５に、複数のアプリケーションを含むウェブ・サーバを提供する。このウェブ・サーバは、通常、サーバＦＳＲ ３０９を信頼する。
【００３８】
ウェブ・シングル・サイン・オン（「ＳＳＯ」）は、複数のアプリケーションにアクセスするときであっても、ユーザに、単一のアイデンティティ、およびセッションごとに単一のログオン、を用いてコンピュータ・リソースにアクセスする能力を与えることができる。ウェブ・シングル・サイン・オン（「ＷｅｂＳＳＯ」）は、通常、ブラウズ可能ウェブ・サイトだけに適用される、シングル・サイン・オンのサブセットとみなされる。しかし、インターネットの人気に起因して、ウェブ・シングル・サイン・オンが、ＳＳＯより普及する傾向がある。
【００３９】
ネットワークは、そのファイヤウォールの外側にＤＭＺゾーンを設けることができる。リソースは、このＤＭＺゾーン内に展開（利用可能に準備）されることになる。例示的実施形態によれば、企業ユーザは、シャドウ・アカウントなしでシングル・サイン・オンを使用する伝統的なＷｉｎｄｏｗｓ（登録商標）認証および許可を使用することによって、ＤＭＺリソースにアクセスする。このシナリオでは、企業は、ＤＭＺゾーンを有し、そこに、その企業が、企業ユーザがアクセス可能なリソース（たとえば、ＳｈａｒｅＰｏｉｎｔサーバ）を展開（利用可能に準備）する。
【００４０】
図４は、エクストラネット・アクセスに関する全体的な処理フローを示すブロック図である。エクストラネットＤＭＺアクティブ・ディレクトリ（「ＡＤ」）４０６は、コープネット（corpnet）アクティブ・ディレクトリ４０４への１方向Ｗｉｎｄｏｗｓ（登録商標）信頼（trust）を有する。ログオン・サーバ／フェデレーテッド・サーバ（「ＬＳ−Ｒ／ＦＳ−Ｒ」）４０９が、エクストラネット・リソース領域に展開（利用可能に準備）され、ログオン・サーバ／フェデレーテッド・サーバ（「ＬＳ−Ａ／ＦＳ−Ａ」）４０７が、コープネット・アカウント領域またはイントラネット４０１に展開（利用可能に準備）される。エクストラネット・リソース領域とコープネット・アカウント領域の間のフェデレーション信頼は、両側で「Ｗｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ」信頼としてフラグを立てられ、これは、エクストラネット領域が、コープネット領域ＡＤストアからのユーザに伝統的なＷｉｎｄｏｗｓ（登録商標）認証および許可制御を使用するアプリケーションを有することを意味する。ウェブ・サーバ（「ＷＳ」）で動作する信頼するアプリケーションは、フェデレーション・サーバ（「ＦＳ−Ｒ」）で「Ｗｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ」としてフラグを立てられ、これは、そのアプリケーションが、ローカルＮＴアクセス・トークンを作るためにユーザＳＩＤを受け入れることを意味する。
【００４１】
クライアントは、ＤＭＺに展開（利用可能に準備）されたウェブ・サーバＷＳで動作する伝統的なウェブ・アプリケーションにアクセスする。クライアントは、インターネットまたはイントラネットに位置することができる。最終目標は、ＷＳでＮＴアクセス・トークンを作り、その結果、通常のＮＴ許可制御を、アクセスされるリソースのアクセス制御リスト（「ＡＣＬ」）に対して使用できるようにすることである。これは、ユーザ許可制御属性（ＳＩＤ）がある形でＷＳに配布されることを意味する。
【００４２】
図５および図６は、インターネット上のクライアントがエクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。Ｗｉｎｄｏｗｓ（登録商標）信頼を確立するためのトークン交換のフローは、Ｗｉｎｄｏｗｓ（登録商標）ネットワークまたはその同等物に典型的な形で維持される。しかし、トークンの構成および内容（content）は、シャドウ・アカウント内ではなくトークン内にセキュリティ識別子（「ＳＩＤ」）を設けることによって変更されている。認証について、ＳＩＤは、既に存在し、アプリケーションが、アプリケーションのドメイン内のシャドウ・アカウントからＳＩＤを取り出す必要はない。
【００４３】
第１に、インターネット上のクライアントが、（ＨＴＴＰ ＧＥＴを介して）ＤＭＺ内に位置する所望のアプリケーションを有するウェブ・クライアントからのリソースＵＲＬにアクセスする（ブロック５０１）。このクライアントは認証クッキーを有しないので、このクライアントはＬＳ−Ｒ／ＦＳ−Ｒにリダイレクトされる。第２に、ＬＳ−Ｒは、クライアント・ホーム領域を決定し、クライアントをＬＳ−Ａ−ＥＸＴにリダイレクトする（ブロック５０２）。
【００４４】
クライアントが、コープネットに位置する場合に、クライアントは、ＬＳ−Ａ−ＥＸＴではなくＬＳ−Ａにその要求を送信する。この実施形態には、少数のオプションがある。たとえば、特殊なＤＮＳ構成をコープネットＤＮＳサーバで使用し、その結果、ＬＳ−Ａ−ＥＸＴ名がＬＳ−ＡのＩＰアドレスに解決されるようにすることができる。代替実施形態で実行されるもう１つの可能性は、ＬＳ−Ａ−ＥＸＴに２つのＮＩＣ（一方のＮＩＣはコープネットに面し、他方はインターネットに面する）を有し、どちらのＮＩＣがＬＳ−Ａ−ＥＸＴへの接続に使用されているかに基づいてクライアントのローカリティを決定することである。この場合に、ＬＳ−Ａは、ＦＳ−ＡにすべてのユーザＳＩＤを与える統合認証を使用する。
【００４５】
あるいは、クライアントがインターネットに位置する場合に、ＬＳ−Ａ−ＥＸＴが、ユーザ信任証（ユーザ名およびパスワードまたはクライアント証明書）を収集し、これらを信任証検証または検査のためにＦＳ−Ａに送信する（ブロック５０３）。ＦＳ−Ａは、ユーザ信任証を検証する。信任証が検証された後に、ＦＳ−Ａは、ローカルＮＴアクセス・トークンからのユーザＳＩＤのコレクションを有する（ブロック５０４）。
【００４６】
前のステップでユーザＳＩＤを入手したので、ＦＳ−Ａは、そのＳＩＤをグループ・クレイムに変換し、ユーザＡＤアカウントからのＬＤＡＰ属性を使用してカスタム・クレイムを入手する（ブロック５０５）。次に、リソース領域がＷｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔであるならば、ＦＳ−Ａは、ユーザのアカウント・グループＳＩＤを入手する（ブロック５０６）。次に、ＦＳ−Ａは、Ａｄｖｉｃｅ要素内の属性およびアカウント・グループＳＩＤとして変換されたＷｅｂＳＳＯクレイムを運ぶＳＡＭＬトークンを発行する（ブロック５０７）。さらなる詳細については、Ａｄｖｉｃｅ要素のフォーマットに関するセクション「ＳＩＤパッキング」を参照されたい。ＦＳ−Ａは、このＳＡＭＬトークンをインプロセスでＬＳ−Ａに渡すか（事例３ａ）、このトークンをＬＳ−Ａ−ＥＸＴに送り返す（事例３ｂ）（ブロック５０８）。ＬＳ−Ａ／ＬＳ−Ａ−ＥＸＴは、このＳＡＭＬトークンをクッキーとしてクライアントに書き込み、そのクライアントをＬＳ−Ｒ／ＦＳ−Ｒにリダイレクトする（ブロック５０９）。
【００４７】
ＦＳ−Ｒは、ＳＡＭＬトークンを受信し、検証する（ブロック５１０）。トークンの検証に成功すると、ＦＳ−Ｒは、トークンから入手したクレイムに関する普通のクレイム変換を実行する。次に、アカウント領域がＷｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ領域であるならば、ＦＳ−Ｒは、ＳＡＭＬ Ａｄｖｉｃｅ要素からのユーザＳＩＤを処理する（ブロック５１１）。具体的に言うと、ＦＳ−Ｒは、受信したＳＩＤをフィルタリングする（下のセクション「ＳＩＤフィルタリング」で説明するように）。ＦＳ−Ｒは、Ａｄｖｉｃｅ要素内に属性およびフィルタリングされたアカウント・グループＳＩＤとしてＷＳに適切に変換されたクレイムを運ぶＳＡＭＬトークンを、ＷＳに発行する（ブロック５１２）。図６の流れ図に継続して、ＦＳ−Ｒは、制御をＬＳ−Ｒに返し、このＬＳ−Ｒは、生成されたＳＡＭＬトークンをクッキーとしてクライアントに書き込み、このクライアントをＷＳにリダイレクトする（ブロック６１３）。
【００４８】
ＷＳのＷｅｂＳＳＯ ＩＳＡＰＩエクステンションが、トークンを受信し、クライアントがアクセスを試みていたオリジナルＵＲＬにリダイレクトする（６１４）。このリダイレクトでは、ＩＳＡＰＩエクステンションが、ＷｅｂＳＳＯトークンをクッキーとして書き込む。
【００４９】
ＷＳのＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、クッキーとしてトークンを受信し、検証のためにＷｅｂＳＳＯサービスに渡す（ブロック６１５）。このサービスは、トークンを検証し、ＳＩＤを入手し、このＳＩＤをＷｅｂＳＳＯ認証パッケージに渡す（ブロック６１６）。このパッケージは、ＳＩＤを拡張して、ＷＳが参加しているドメインにリソース・グループＳＩＤを追加する（ブロック６１７）（下のセクション「グループ拡張」を参照されたい）。ＳＩＤの結果のコレクションを使用して、ＮＴアクセス・トークンを作る（ブロック６１８）。ブロック６１５〜６１８は、セキュリティの理由から、ＮＴサービスおよびＬＳＡ認証パッケージが、ＷｅｂＳＳＯトークンの検証に使用され、その後、そのトークンからのＳＩＤをＮＴアクセス・トークンに変えることを示している（ブロック６１９）。ＳＩＤコレクションは、将来の使用のために、認証パッケージ内でキャッシングされ、入ってくるアカウントＳＩＤのハッシュによってキーイングされる（ブロック６２０）。ＮＴアクセス・トークン・ハンドルは、将来の使用のために、ＷｅｂＳＳＯ ＩＳＡＰＩエクステンション内でキャッシングされ、ＳＡＭＬトークンのハッシュによってキーイングされる（６２１）。
【００５０】
クライアントに書き込まれたクッキーは、シングル・サイン・オン体験を達成すること、および繰り返される動作で、通常では手間のかかる動作を防ぐこと、に使用される。ブロック５０８（図５の）で書き込まれるクッキーは、クライアントがリソース領域からアカウント領域にリダイレクトされるときに使用され、その結果、ユーザ信任証検査およびクレイム／ＳＩＤ抽出を避けることができる。ブロック５１０（図５の）で書き込まれるクッキーは、クライアントがリソース・アプリケーション・サーバによってリソース領域ＦＳ−Ｒにリダイレクトされるときに使用され、その結果、クレイム変換およびＳＩＤフィルタリングを避けることができる。ブロック６１４で書き込まれるクッキーは、クライアントがＷＳと通信するときに次のように使用される。
【００５１】
ＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、（クッキーで送信されたＳＡＭＬトークンをハッシュ化し、そのハッシュに対応するキャッシュ・エントリを見つけることによって）そのキャッシュ内でキャッシングされたＮＴトークンを検索することになり、したがって、ユーザは、即座に成りすますことができる。キャッシングされたＮＴトークンが見つからない場合には、ＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、クッキーからのＳＩＤをＷｅｂＳＳＯ認証パッケージに渡し、このＷｅｂＳＳＯ認証パッケージは、そのキャッシュを検索して、入ってくるＳＩＤのハッシュと等しいキーを有するエントリを見つけ、その結果、リソース・グループＳＩＤ拡張を避けることができるようになる。ＷｅｂＳＳＯ認証パッケージは、そのキャッシュ内でＳＩＤを見つけない場合に、上のブロック６１５〜６２１で指定されたようにＮＴアクセス・トークンを作ることになる。
【００５２】
リソース・グループ拡張プロセスの代替の例は、ＷＳではなくＦＳ−Ｒでグループを拡張することである。この方法では、ＦＳ−Ｒは、すべてのＳＩＤを使用してクライアントにクッキーを書き込み、他のリソースがＷＳと同一のドメインに参加しているならば、そのクライアントが次に他のリソースにアクセスするときにそのＳＩＤを使用する。しかし、これは、すべての展開されたアプリケーショ・ンサーバに関するドメインのＦＳ−Ｒに関する知識を要求する。これを達成する方法の１つは、アプリケーションで準備され、ＦＳ−Ｒに送信される、ｗｃｔｘパラメータの一部としてドメイン名を含めることである。このパラメータは、認証されず、したがって、ＷＳは、そのＷＳが参加しているもの以外のドメイン名を置くことができる。
【００５３】
もう１つの代替の例が、信頼するアプリケーションが追加されるときに信頼ポリシでＷＳのドメインを構成することであるが、この手法は、通常、より多くの管理を要求する。
【００５４】
信任証検査（Credentials Verification）
次の説明は、上でステップ５０３（図５の）で説明した信任証検査プロセスを詳説するものである。このプロセスでは、ＦＳ−Ａが、２タイプのユーザ信任証、すなわち、ユーザ名およびパスワードと、クライアント証明書を検証する。ユーザ名およびパスワードは、公表されたＬｏｇｏｎＵｓｅｒ ＡＰＩを介して検証される。その結果は、通常はすべてのユーザＳＩＤ（ＦＳ−Ａが参加しているドメインのアカウントＳＩＤおよびリソースＳＩＤ）を含むＮＴアクセス・トークンである。ユーザ名は、ＵＰＮフォーマット（ｕｓｅｒ＠ｓｏｍｅｗｈｅｒｅ．ｃｏｍ）またはＳＡＭアカウント名フォーマット（ｓｏｍｅｗｈｅｒｅ＼ｕｓｅｒ）とすることができる。クライアント証明書は、通常、次のデータ構造体の証明書を収容するプロトコル・サブミット・バッファを備えるＬｓａＣａｌｌＡｕｔｈｅｎｔｉｃａｔｉｏｎＰａｃｋａｇｅ呼び出しを介してＷｅｂＳＳＯ認証パッケージにクライアント証明書を渡すことによって検証される。
【００５５】
【表１】
【００５６】
この呼び出しは、通常、信頼されない呼び出し元から許可されるので、ＦＳ−Ａは、ＴＣＢ特権を保持する必要がない。しかし、パッケージは、ユーザ・セキュリティ属性を返すので、パッケージは、呼び出し元がＦＳである場合に限ってこの呼び出しを許可することができる。この目的のために、ＦＳセットアップは、通常、ローカル・マシン・グループＡＤＦＳＧｒｏｕｐを作成し、ＦＳアカウントをこのグループに入れる。認証パッケージは、呼び出し元がそのＮＴアクセス・トークン内にＡＤＦＳＧｒｏｕｐ ＳＩＤを有することを検査する。
【００５７】
ＷｅｂＳＳＯパッケージは、内部ＬｓａｌＣａｌｌＰａｃｋａｇｅ呼び出しを介して、検査のために、証明書をＷｉｎｄｏｗｓ（登録商標） ＴＬＳ／ＳＳＬ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（登録商標）に、渡す。検査に成功すると、ＷｅｂＳＳＯパッケージは、ユーザＵＰＮ、ユーザ・アカウント・ドメイン名、およびユーザトークン・グループ（ＳＩＤ）を次のデータ構造体で返す。
【００５８】
【表２】
【００５９】
グループ拡張
次の説明は、上でステップ６１７で説明した信任証検査プロセスを詳説するものである。ＦＳ−Ａは、アカウントおよびリソース・グループ拡張を、そのために実装された新しいＡｕｔｈＺ（「AuthZ」は、AuthenticationとAuthorizationとを表す略語）機能性であるＡｕｔｈｚｉＷｅｂＳｓｏＧｅｔＧｒｏｕｐｓＢｙＳｉｄを使用することによって、実行する。ＡｕｔｈＺは、現在、グループ拡張を行うが、その拡張は選択的でない、すなわち、アカウントとリソース・グループの両方が、必ず拡張される。ＡｕｔｈＺは、拡張が分離され、その結果、アカウント側（ＦＳ−Ａ）がアカウント・グループを拡張でき、リソース側（ＷＳ）が、そのめいめいのドメイン内のリソース・グループを拡張できるように変更されている。さらに、ＡｕｔｈＺによって使用されるＬＤＡＰハンドルおよびＳＡＭハンドルをキャッシングするように、性能最適化が実施されている。
【００６０】
ＳＩＤパッキング
ＳＡＭＬトークンのサイズを減らすために、ＳＩＤは、次のようにＳＡＭＬ Ａｄｖｉｃｅ要素にパックされている。Ａｄｖｉｃｅ要素は次の通りである。
【００６１】
【表３】
【００６２】
（「ｈｔｔｐ：／／ｆａｂｒｉｋａｍ．ｃｏｍ／ｆｅｄｅｒａｔｉｏｎ／ｖ１／Ｗｉｎｄｏｗｓ（登録商標）Ｉｄｅｎｔｉｆｉｅｒｓ」は、テンポラリ名前空間であることに留意されたい）。Ｗｉｎｄｏｗｓ（登録商標）Ｉｄｅｎｔｉｆｉｅｒｓ要素には、次のフォーマットでユーザＳＩＤを収容するｂａｓｅ６４エンコーデッド・ストリングを収容する。
【００６３】
Ｆｌａｇｓ｜ＤｏｍａｉｎＳｉｄＣｏｕｎｔ｜ＡｃｃｏｕｎｔＤｏｍａｉｎＳｉｄ｜ＲｉｄＣｏｕｎｔ｜Ｒｉｄ＿１｜…｜Ｒｉｄ＿Ｎ｜ＤｏｍａｉｎＳｉｄ｜ＲｉｄＣｏｕｎｔ｜Ｒｉｄ＿１｜…｜Ｒｉｄ＿Ｍ｜…
ここで、縦セパレータ｜は、ＤＷＯＲＤ境界を示す。最初のＤＷＯＲＤは、Ｆｌａｇｓパラメータである。ＷＳが受信したＦｌａｇｓパラメータのビット１がセットされている場合に、これは、ＷＳが、リソース・グループを追加するためにグループを拡張する必要があることを示す。第２のＤＷＯＲＤは、このバッファに何個のドメインＳＩＤが存在するかを示すパラメータである。次のＤＷＯＲＤは、アカウント・ドメインＳＩＤである最初のドメインＳＩＤである。次のＤＷＯＲＤは、アカウント・ドメインＳＩＤのＲＩＤの個数である。アカウントＳＩＤおよびグループＳＩＤが、ドメインＳＩＤを対応するＲＩＤと組み合わせることによって構成されることに留意されたい。次のＤＷＯＲＤは、ユーザアカウントのＲＩＤである。これに、グループＲＩＤ（ＲｉｄＣｏｕｎｔで定義された個数より１つ少ない）が続く。次に、次ドメインＳＩＤがあり、そのドメインのＲＩＤカウントが続き、ＲＩＤが続く。このパターン自体は、ＲＩＤを有するすべてのドメインＳＩＤが列挙されるまで繰り返される。
【００６４】
ＳＩＤフィルタリング
ＷｅｂＳＳＯは、ＦＳ−Ｒに対するＳＩＤフィルタリングを実行し、このフィルタリングは、通常リソース・ドメイン・コントローラに対して実行されるネイティブＳＩＤフィルタリングと同一のルールに従う。フィルタリングは、通常のＷｉｎｄｏｗｓ（登録商標）実装形態を使用すること、内部ＤＣ固有Ｗｉｎｄｏｗｓ（登録商標） Ｌｏｃａｌ Ｓｅｃｕｒｉｔｙ Ａｕｔｈｏｒｉｔｙ（「ＬＳＡ」）（ＬＳ−Ａと混同してはならない）ルーチンを実装すること、によって達成される。このルーチンは、ドメインおよびフォーレストの信頼トポロジを計算し、ランタイムにＳＩＤ検索を実行する。これらを実装するために、ルート・ドメインＤＣからのドメイン信頼およびフォーレスト信頼が、ＤｓＥｎｕｍｅｒａｔｅＤｏｍａｉｎＴｒｕｓｔｓ ＡＰＩおよびＤｓＧｅｔＦｏｒｅｓｔＴｒｕｓｔＩｎｆｏｒｍａｔｉｏｎＷ ＡＰＩを使用することによって入手される。これらのＡＰＩは、信頼境界を決定し、エクストラネット信頼の信頼タイプおよび信頼属性を識別するのに必要な情報を返す。その情報を得ると、任意の所与のＳＩＤを、ローカル・フォーレストならびに（クロス・フォーレスト信頼に関して直接にまたは他動的に信頼される）信頼されるドメインのドメインＳＩＤと突き合わせることができる。その情報は、ドメイン信頼変化を考慮に入れるために周期的に更新される。これによって、使用される内部ＬＳＡ ＡＰＩの実装が可能になり、その結果、同一のコア・コード・ベースを使用できるようになる。この文書の最後のセクションで、これらのリソースへのフェデレーテッド・パートナー・アクセスを扱う。
【００６５】
フェデレーテッド・リソースにアクセスするためのトークン
図７は、エクストラネット・リソースに対するフェデレーテッド・パートナーに関する全体的な処理フローを示す流れ図である。エクストラネットＤＭＺアクティブ・ディレクトリに、ウェブＳＳＯトークンをマッピングできるアクティブ・ディレクトリ内のシャドウ・アカウントが含まれ、その結果、ＮＴアクセス・トークンを生成することができるようになる。ウェブＳＳＯトークンを得るプロトコルは、上で説明したプロトコルおよびＷＳ−フェデレーション・プロトコルに類似する。ＦＳ−Ｒが、アカウントＦＳによって発行された、クライアントのウェブＳＳＯトークンを得たならば、ＦＳ−Ｒは、そのトークンのクレイムをマッピングすることができる。
【００６６】
図８は、ＮＴアクセス・トークンの生成を可能にするためにクレイムをマッピングする３つの異なる形を示す流れ図である。
【００６７】
第１に、ユーザ・プリンシパル名（「ＵＰＮ」）クレイムに、ＦＳ−Ａ内でトークンを発行し（８０１）、このクレイムを、ＦＳ−Ｒによって無変更でＷＳに渡す（８０２）。この場合に、フェデレーテッド・クライアントのＵＰＮクレイムに一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。
【００６８】
第２に、電子メール・クレイムにＦＳ−Ａ内でトークンを発行し（８０３）、クレイムをＵＰＮクレイムに変更する（８０４）。このクレイムを、ＦＳ−ＲによってＷＳに渡す（８０５）。この場合に、フェデレーテッド・クライアントの電子メール・アドレスと一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。
【００６９】
第３に、グループ・クレイムにＦＳ−Ａでトークンを発行し（８０６）、このグループ・クレイムをＵＰＮクレイムにマッピングする（８０７）。この場合に、マッピングするＵＰＮに一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。この場合に、複数のクライアントが１つのシャドウ・アカウントにマッピングされることに留意されたい。
【００７０】
現在、シャドウ・アカウントが必要である唯一の場所は、伝統的な（ＮＴアクセス・トークン・ベースの）アプリケーションを展開する（利用可能に準備する）、フェデレーテッド・リレーションシップのリソース側である。シャドウ・アカウントは、通常、ＡＤＦＳウェブ・エージェントが、ＮＴアクセス・トークンを作るために、シャドウ・アカウントを偽装できる（成りすますことができる）ようにするために必要である。シャドウ・アカウントは、通常、アカウントを展開（利用可能に準備）し、維持する必要があるので、顧客の主要な関心事である。多くの場合に、シャドウ・アカウントは、ＤＭＺでのＡＤＦＳの展開する場合に、展開ブロッカを構成する。
【００７１】
この第２の例では、非ＤＭＺアカウント領域から受信したインバウンド・グループ・クレイムをローカル・リソースＡＤグループに変換することによってシャドウ・アカウントを除去し、ＡＤグループＳＩＤを使用してＮＴトークンを作ることができる。リソースは、ローカルＡＤグループＳＩＤを用いてＡＣＬを与えられ、したがって、結果のＮＴトークンは、リソース・アプリケーションによって実行されるアクセス検査に対して適切なものになる。
【００７２】
シャドウ・ディレクトリを除去することができる、この第２の例を実装するために、新しい企業グループ・クレイム・タイプであるＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍを使用する。クレイムは、通常、オーソリティが、名前、アイデンティティ、キー、グループ、特権、機能、および類似物など、のプリンシパルに関して作ることができるステートメントである。クレイムは、セキュリティ・トークンによってアサートすることができる。
【００７３】
このクレイム・タイプは、対応するＡＤグループのＳＩＤであるＳＩＤプロパティを追加することによって、ＧｒｏｕｐＣｌａｉｍを拡張する。ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍは、ＧｒｏｕｐＣｌａｉｍであり、したがって、通常、クレイム変換などの企業グループ・クレイムを現在操作するすべての場所でそのようなものとして扱われる。
【００７４】
ランタイムに、リソースＦＳ−Ｒが非ＤＭＺ領域からインバウンド・トークンを得、インバウンド・グループ・クレイムを、アプリケーションに発行されたアウト・バウンド企業グループ・クレイム（ＡＤグループを含めることができる）に変換した後に、ＦＳ−Ｒは、通常、アウトバウンド・コレクションで見つかったＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍごとにＡＤグループＳＩＤを追加する。
【００７５】
グループＳＩＤのほかに、ＦＳは、通常、信頼される領域ＵＲＩから導出されたユーザＳＩＤおよびインバウンド・トークン内のアイデンティティ・クレイムの値を生成する（ユーザＳＩＤ生成アルゴリズムの詳細については以下を参照されたい）。
【００７６】
結果のユーザＳＩＤおよびグループＳＩＤは、発行される新しいトークンのＡｄｖｉｃｅ要素の形でウェブ・サーバ・エージェントに渡され、これは、通常、ＤＭＺリソースＦＳ−Ｒによって普通に行われるのと同一の形である。
【００７７】
ウェブ・サーバ（ＷＳ）は、ＳＩＤを得、これを拡張してリソース・ドメイン・ローカル・グループＳＩＤを追加し、このＳＩＤを有するトークンを、普通の認証パッケージを介して作る。ＮＴトークンを作るために、ＳＩＤのほかに、認証パッケージは、それぞれ、起点アカウント・オーソリティおよび結果のログオン・セッションのユーザ名としてセットされるＡｕｔｈｅｎｔｉｃａｔｉｎｇＡｕｔｈｏｒｉｔｙプロパティおよびＡｃｃｏｕｎｔＮａｍｅプロパティを有する必要がある場合がある。アカウント領域ＵＲＩおよびアイデンティティ・クレイム値を、それぞれ、この目的に使用することができる。
【００７８】
結果として、アカウント領域ＵＲＩおよびユーザ・アイデンティティが、許可制御パッケージによって実行されるログオンの成功に基づいて、ＬＳＡによって生成されるセキュリティ監査イベントでログインされる。これは、シャドウ・アカウントではなく実際のユーザアカウントに関する監査能力を提供するので、有用な機能である場合がある。
【００７９】
そのような監査の例を、下に示す。この監査は、上で説明したように変更された認証パッケージによるユーザｕｓｅｒ＠ａｄａｔｕｍ．ｃｏｍのログオンが成功したときに生成されたものである。
【００８０】
【表４】
【００８１】
さらなる代替の例では、顧客が、一部のユーザについてシャドウ・アカウントを配置し、他のユーザについてＳＡＭＬグループ−ＡＤグループ変換（ＳＧ２ＡＤＧ）を使用することができる。原理的に、ＵＰＮ／電子メールおよびＳＩＤの所与の組について、まず、シャドウ・アカウント・ログオンを実行すること試み、シャドウ・アカウント・ログオンが、ユーザが存在しないことを示すエラーで失敗する場合に、ＳＩＤを用いるログオンを行うことができる。しかし、これを行うことは、通常、シャドウ・アカウントが多数のユーザについて利用可能に準備されていない場合に、性能（perf）に大きく影響する。
【００８２】
シャドウ・アカウントまたはＳＩＤのどちらを使用するかを決定するために、信頼される領域の新しい信頼ポリシＯＭ列挙タイプ、ＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅが追加されている。この列挙は、通常、４つの値すなわち、Ｕｎｓｐｅｃｉｆｉｅｄ、ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔ、ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓ、およびＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓを有する。Ｕｎｓｐｅｃｉｆｉｅｄは、シャドウ・アカウント存在が、この領域からのユーザについて指定されていないことを意味する。これは、デフォルト値である。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔは、この信頼される領域から来るユーザについてシャドウ・アカウントが展開（利用可能に準備）されていないことを意味する。この場合に、ＳＧ２ＡＤＧ変換から生じるＳＩＤが、ＮＴトークンの作成に使用される。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓは、通常、シャドウ・アカウントが、この信頼される領域からのユーザの一部について展開（利用可能に準備）されていることを意味する。この場合に、シャドウ・アカウントＵＰＮ／電子メールを用いるログオンが、まず試みられ、その後、ＳＩＤを用いるログオンが、この信頼される領域からのユーザについて次に試みられる。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓは、通常、シャドウ・アカウントが、この信頼される領域からのすべてのユーザについて展開（利用可能に準備）されていることを意味する。この場合には、シャドウ・アカウントＵＰＮ／電子メールを用いるログオンだけが試みられる。
【００８３】
ランタイムに、ＦＳ−Ｒが伝統的なアプリケーションにＳＡＭＬトークンを発行するときに、ＦＳ−Ｒは、発行されるＳＡＭＬトークンで、そのアプリケーションが実行しなければならないログオンのタイプを示す。ＦＳ−Ｒは、次のように、ＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅの値に基づいてログオンのタイプを決定する。
【００８４】
Ｕｎｓｐｅｃｉｆｉｅｄ：結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンだけを試みなければならないことを示す。そうではなく、ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、シャドウ・アカウント・ログオンだけを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に失敗する。
【００８５】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔ：結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に
失敗する。
【００８６】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓ：ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、シャドウ・アカウント・ログオンだけを試みなければならず、アプリケーションに発行されたＳＡＭＬトークンにＳＩＤが存在するならば、次にＳＩＤログオンを試みなければならないことを示す。そうではなく、結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に失敗する。
【００８７】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓ：ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、そのユーザについてシャドウ・アカウント・ログオンだけを試みなければならないことを示し、ＳＡＭＬトークンにＳＩＤを含めない。そうでない場合に、ＦＳ−Ｒは、結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合であっても、ユーザ要求に失敗する。実際に、ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムは、普通のＧｒｏｕｐＣｌａｉｍの意味でコレクションに現れる場合があり、これらをＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓの値に従ってＡＤグループとして扱うことは、管理者の意図ではない。
【００８８】
ＷＳに発行されたＳＡＭＬトークン内のパックされたＳＩＤ構造体の存在は、ＷＳがＳＩＤログオンを試みなければならないことを示す。この構造体は、ＳＩＤログオンの前にシャドウ・アカウント・ログオンを試みなければならないかどうかも示す。具体的に言うと、この構造体のＦｌａｇｓパラメータのビット２がセットされている場合に、ＷＳは、まず、ＳＡＭＬトークンからのＵＰＮ／電子メール・アイデンティティ・クレイムを使用してシャドウ・アカウント・ログオンを試みる。そうでない場合には、ＷＳはＳＩＤログオンだけを試みる。ＳＩＤ構造体が存在しない場合には、ＷＳは、シャドウ・アカウント・ログオンだけを行う。
【００８９】
ＵＩは、通常、信頼される非ＤＭＺ領域のＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅ列挙タイプの値をセットすることをサポートする。ＵＩは、組織クレイム内の新しいＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍのクレイム・タイプもサポートする。新しいクレイム・タイプと既存のグループ・クレイム・タイプの間の唯一の相違は、Ｓｉｄ属性の追加であり、このＳｉｄ属性は、ＡＤストアによるグループ・クレイムの取り込み時に、ＵＩ内に既に実装されているものと同一のＯｂｊｅｃｔ Ｐｉｃｋｅｒコードを介して取り込まれる。
【００９０】
ユーザＳＩＤ生成
ＦＳは、次のようにユーザＳＩＤを生成する。ＳＩＤは、所与の信頼される領域からの所与のユーザについて一意である。ＳＩＤは、通常、２８バイトの長さ（普通のＡＤ ＳＩＤのサイズである）である。ＳＩＤのＳＩＤ＿ＩＤＥＮＴＩＦＩＥＲ＿ＡＵＴＨＯＲＩＴＹには、通常は、他の既存ＳＩＤからそのＳＩＤを区別するために、新しいＡＤＦＳオーソリティがセットされる。ＳＩＤサブオーソリティに割り当てられた２０バイトは、文字列「＜ｔｒｕｓｔｅｄ ｒｅａｌｍ ＵＲＩ＞＼＜ｉｄｅｎｔｉｔｙ ｃｌａｉｍ ｖａｌｕｅ＞」のハッシュが書き込まれ、ここで、＜ｔｒｕｓｔｅｄ ｒｅａｌｍ ＵＲＩ＞は、ＳＡＭＬトークンを発行したアカウント領域のＵＲＩであり、＜ｉｄｅｎｔｉｔｙ ｃｌａｉｍ ｖａｌｕｅ＞は、ＳＡＭＬトークからのアイデンティティ・クレイム（ＵＰＮ、電子メール、またはＣｏｍｍｏｎＮａｍｅ）の値である。２０バイトのハッシュは、通常、所与の領域からの所与のユーザに一意のＳＩＤを生成するのに十分に長い。したがって、要約すると、生成されるＳＩＤは、通常、「Ｓ−１−＜ＡＤＦＳオーソリティ＞−＜２０バイトハッシュを書き込まれる５ＤＷＯＲＤサブオーソリティ＞」のように見える。
【００９１】
フェデレーテッド・クライアントに発行されるＷｅｂＳＳＯトークンが、Ａｄｖｉｃｅ要素内にＳＩＤを有しないことに留意されたい。ＷＳは、ＦＳ−Ｒによって発行されたＷｅｂＳＳＯトークンを、クッキーとして、ＵＰＮクレイムと共に受信する。ＷｅｂＳＳＯトークンは、ＮＴサービスによって検証され、ＵＰＮが、ＬＳＡ認証パッケージに渡される。ＷＳが、Ｗｉｎｄｏｗｓ（登録商標）２００３（Ｍｉｃｒｏｓｏｆｔ社の商標）ドメイン内にあり、Ｋｅｒｂｅｒｏｓ Ｓ４Ｕがサポートされる場合に、サービスは、ＬｓａＬｏｇｏｎＵｓｅｒを用いてＫｅｒｂｅｒｏｓ認証パッケージを呼び出し、ＮＴトークンが返される。ＷＳが、Ｗｉｎｄｏｗｓ（登録商標） ２０００ドメイン内にある場合に、ＷｅｂＳＳＯ認証パッケージが、ＬｓａＬｏｇｏｎＵｓｅｒを使用して呼び出され、ＵＰＮが、このパッケージに渡され、トークンが返される。ＷｅｂＳＳＯ認証パッケージは、ＡｕｔｈＺ ＡＰＩを使用して、ＵＰＮで渡されたＳＩＤを得、次に、これらのＳＩＤに基づいてトークンを作る。
【００９２】
ＬｓａＬｏｇｏｎＵｓｅｒを呼び出すときに使用される構造体は、次の通りである。
【００９３】
【表５】
【００９４】
この場合にはサービスであるクライアント・アプリケーションは、パッケージ名（「ＷｅｂＳｓｏＡｐ」）を用いてＬｓａＬｏｏｋｕｐＡｕｔｈｅｎｔｉｃａｔｉｏｎＰａｃｋａｇｅを呼び出し、次に、ＬｓａＬｏｇｏｎＵｓｅｒを呼び出し、ＡｕｔｈＩｎｆｏＢｕｆｆｅｒパラメータで書き込まれた＿ＷＥＢＳＳＯ＿ＬＯＧＯＮ構造体を供給する。
【００９５】
認証パッケージは、ＡｚＭａｎから取り出した、クライアントＵＰＮに対するインデックスであるトークン情報のＡＶＬツリー・ベース・キャッシュを維持する。
【００９６】
コンピューティング環境
図９に、本明細書に記載のウェブＳＳＯを実装できる例示的なコンピューティング環境９００を示す。例示的なコンピューティング環境９００は、コンピューティング・システムの１例にすぎず、本明細書に記載の例をこの特定のコンピューティング環境に制限することは意図されていない。
【００９７】
たとえば、コンピューティング環境９００は、多数の他の汎用または特殊目的のコンピューティング・システム構成を用いて実施することができる。周知のコンピューティング・システムの例に、パーソナル・コンピュータ、ハンドヘルド・デバイスまたはラップトップ・デバイス、マイクロ・プロセッサ・ベースのシステム、マルチ・プロセッサ・システム、セットトップボックス、ゲーム機、コンシューマ・エレクトロニクス、セル電話機、ＰＤＡ、および類似物を含めることができるが、これらに制限はされない。
【００９８】
コンピュータ９００に、コンピューティング・デバイス９０１の形の汎用コンピューティング・システムが含まれる。コンピューティング・デバイス９０１のコンポーネントに、１つまたは複数のプロセッサ（ＣＰＵ、ＧＰＵ、マイクロ・プロセッサ、および類似物を含む）９０７、システム・メモリ９０９、およびさまざまなシステム・コンポーネントを結合するシステム・バス９０８が含まれる。プロセッサ９０７は、コンピューティング・デバイス９０１の動作を制御するものおよび他の電子デバイスおよびコンピューティング・デバイス（図示せず）と通信するものなど、さまざまなコンピュータ実行可能命令を処理する。システム・バス９０８は、メモリ・バスまたはメモリ・コントローラ、周辺バス、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ、およびさまざまなバス・アーキテクチャのいずれかを使用するプロセッサ・バスまたはローカル・バスを含む、任意の個数の複数のタイプのバス構造を表す。
【００９９】
システム・メモリ９０９に、ランダム・アクセス・メモリ（ＲＡＭ）などの揮発性メモリおよび／または読取専用メモリ（ＲＯＭ）などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。基本入出力システム（ＢＩＯＳ）が、ＲＯＭに格納されている。ＲＡＭには、通常、１つまたは複数のプロセッサ９０７がダイレクトにアクセス可能および／またはこれによって現在操作されているデータおよび／またはプログラム・モジュールが含まれる。
【０１００】
マス・ストレージ・デバイス９０４を、コンピューティング・デバイス９０１に結合するか、バスに結合することによってコンピューティング・デバイスに組み込むことができる。そのようなマス・ストレージ・デバイス９０４に、リムーバブル不揮発性磁気ディスク（たとえば、「フロッピー（登録商標）・ディスク」）９０５から読み取り、これに書き込む磁気ディスク・ドライブ、またはＣＤ ＲＯＭもしくは類似物などのリムーバブル不揮発性光ディスク９０６から読み取り、かつ／またはこれに書き込む光ディスク・ドライブを含めることができる。コンピュータ可読媒体９０５および９０６は、通常、フロッピー（登録商標）・ディスク、ＣＤ、ポータブル・メモリ・スティック、および類似物で供給されるコンピュータ可読命令、データ構造、プログラム・モジュール、および類似物を、示す。
【０１０１】
たとえば、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データを含む、任意の個数のプログラム・モジュールを、ハードディスク９１０、マス・ストレージ・デバイス９０４、ＲＯＭおよび／またはＲＡＭ９０９に格納することができる。そのようなオペレーティング・システム、アプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データのそれぞれ（またはこれらのある組合せ）に、本明細書に記載のシステムおよび方法の実施形態を含めることができる。
【０１０２】
ディスプレイ・デバイス９０２を、ビデオ・アダプタ９１１などのインターフェースを介してシステム・バス９０８に接続することができる。ユーザは、キーボード、ポインティング・デバイス、ジョイスティック、ゲームパッド、シリアル・ポート、および／または類似物などの任意の個数の異なる入力デバイス９０３を介してコンピューティング・デバイス９０１とインターフェースすることができる。上記および他の入力デバイスは、システム・バス９０８に結合された入出力インターフェース９１２を介してプロセッサ９０７に接続されるが、パラレル・ポート、ゲーム・ポート、および／またはＵＳＢ（universal serial bus）などの他のインターフェースおよびバス構造によって接続することができる。
【０１０３】
コンピューティング・デバイス９００は、１つまたは複数のローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、および類似物を介する１つまたは複数のリモート・コンピュータへの接続を使用してネットワーク化された環境で動作することができる。コンピューティング・デバイス９０１は、ネットワーク・アダプタ９１３を介して、あるいはその代わりにモデム、ＤＳＬ、ＩＳＤＮインターフェース、または類似物によって、ネットワーク９１４に接続される。
【０１０４】
当業者は、プログラム命令の格納に使用されるストレージ・デバイスを、ネットワーク上で分散できることを諒解するであろう。たとえば、リモート・コンピュータに、ソフトウェアとして、説明された処理の例を格納することができる。ローカル・コンピュータまたは端末コンピュータは、リモート・コンピュータにアクセスし、ソフトウェアの一部またはすべてをダウンロードして、プログラムを実行することができる。その代わりに、ローカル・コンピュータが、必要に応じてソフトウェアの一部をダウンロードするか、ローカル端末でソフトウェア命令の一部を、リモート・コンピュータ（またはコンピュータ・ネットワーク）でソフトウェア命令の一部を実行することによって分散式に処理することができる。当業者は、当業者に既知の従来の技法を使用することによって、ソフトウェア命令のすべてまたは一部を、ＤＳＰ、プログラマブル・ロジック・アレイ、または類似物などの専用回路によって実行できることも理解するであろう。
【図面の簡単な説明】
【０１０５】
【図１】コンピュータ・オペレーティング・システムの一部としてのウェブ・シングル・サイン・オンを示す図である。
【図２】ウェブＳＳＯを実施するさまざまなネットワークの例を示す図である。
【図３】ウェブＳＳＯ中にセキュリティを維持するのに使用されるシステム・コンポーネントを示すブロック図である。
【図４】エクストラネット・アクセスに関する全体的な処理フローを示すブロック図である。
【図５】エクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。
【図６】エクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。
【図７】エクストラネット・リソースに対するフェデレーテッド・パートナーに関する全体的な処理フローを示す流れ図である。
【図８】フェデレーション・パートナーによるアクセスを可能にするＮＴアクセス・トークンの生成を可能にするためにクレイムをマッピングする３つの異なる形を示す流れ図である。
【図９】本明細書に記載のウェブＳＳＯおよびフェデレーテッド・パートナーによるネットワーク・アクセスを実装できる例示的なコンピューティング環境を示す図である。
【符号の説明】
【０１０６】
１０１ ラップトップ
１０２ ＰＣ
１０３ ウェブ・サーバ
１０４ オペレーティング・システム
１０５ オペレーティング・システムのネットワーキング部分
１０６ シングル・サイン・オン（ＳＳＯ）
１０７ ウェブ・シングル・サイン・オン（ウェブＳＳＯ）
１０８ フェデレーテッド・リソース・サイン・オン
２０１ イントラネット
２０２ ＤＭＺ
２０３ イントラネット
２０４ パートナアー・カウント・ストア
２０５ 消費者アカウント・ストア
２０６ ウェブ・サイト・エクストラネット・アカウント・ストア
２０７ ウェブ・サイト従業員アカウント・ストア
２０８ ＳＳＯを用いるパートナー・ウェブ・クライアント
２０９ ＳＳＯを用いる消費者ウェブ・クライアント
２１０ ＳＳＯを用いる消費者またはパートナーのウェブ・クライアント
２１１ ＳＳＯを用いる従業員ウェブ・クライアント
２１２ ウェブ・サイト
２１３ ファイヤウォール
２１４ フェデレーテッドＢ２Ｂ
２１５ フェデレーテッドＢ２Ｃ
２１６ エクストラネット
２１７ Ｂ２Ｅ
２１８ インターネット
３０１ アクティブ・ディレクトリのセキュリティ・トークン・サービス・プロキシ
３０２ ウェブ・サイト信頼を管理するフェデレーション・サービス
３０３ ウェブ・アプリケーションのＳＳＯエージェント・プロセス・セキュリティ・ト
３０４ パッシブ・クライアント・プロトコル
３０５ アクティブ・ディレクトリ
３０６ アカウント・ストア
３０８ ＦＳＡ
３０９ ＦＳＲ
３１０ ＦＳＲ’
３１１ ウェブＳＳＯを用いるウェブ・クライアント
３１２ ウェブ・サイト・アプリケーション
３１３ イントラネット
３１４ ＤＭＺ
３１５ インターネット
３１６ イントラネット
３２０ ＷＳ
３２１ ＦＳＰ−Ａ
４０１ イントラネット
４０２ ＤＭＺ
４０３ インターネット
４０４ コープネットＡＤ
４０５ Ｗｉｎｄｏｗｓ（登録商標）信頼
４０６ エクストラネットＡＤ
４０７ コープネット・リソース領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ａ／ＦＳ−Ａ
４０８ フェデレーション信頼
４０９ エクストラネット・アカウント領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ｒ／ＦＳ−Ｒ
４１０ コープネット上のクライアント
４１１ インターネット上のクライアント
４１２ ＬＳ−Ａ−ＥＸＴ
４１３ ＷＳ
７０１ リソースＤＭＺ
７０２ インターネット
７０３ アカウント・コープネット
７０４ リソースＦＳ
７０５ Ｗｉｎｄｏｗｓ（登録商標）信頼
７０６ アカウントＦＳ
７０７ コープネット・アカウント領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ｒ／ＦＳ−Ｒ
７０８ フェデレーション信頼
７０９ エクストラネット・リソース領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ａ／ＦＳ−Ａ
７１０ ＷＳ
７１１ インターネット上のクライアント
７１２ コープネット上のクライアント
９００ コンピュータ環境
９０１ コンピューティング・デバイス
９０２ ディスプレイ
９０３ 入出力デバイス
９０４ 周辺ドライブ
９０５ フロッピー（登録商標）・ディスク
９０６ 光ディスク
９０７ 処理ユニット
９０８ システム・バス
９０９ システム・メモリ
９１０ ハードディスク
９１１ ビデオ・アダプタ
９１２ 入出力インターフェース
９１３ ネットワーク・アダプタ
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、その内容が参照によって本明細書に組み込まれている、２００４年１２月７日出願の米国特許仮出願第６０／６３４３５６号の利益を主張するものである。
【０００２】
本発明は、全般的には通信ネットワークに関し、より詳細には、ウェブ・アプリケーションのパッシブ・クライアント・シングル・サイン・オンに関する。
【背景技術】
【０００３】
近年、インターネットは、組織が互いに通信し、相互作用するための最も重要なツールの１つになってきた。インターネットを介するユーザによる、または関連するネットワーク内もしくはフェデレーテッド（federated）ネットワーク内のユーザによる、ネットワーク・リソースへのアクセスが、増加しつつある。通常のネットワークの外部に広がったユーザ・グループに対処するためのユーザ・ディレクトリの提供は、経時的に、これらのディレクトリを維持する努力と共に増加する傾向がある。セキュリティの理由から、特定の組織内のユーザは、しばしば、別の組織のリソースへのアクセスを許可される前に、認証される必要がある。ユーザ認証（authentication）を容易にするための別の機構が開発されてきた。そのような機構の１つが、Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＷＳ）−Ｆｅｄｅｒａｔｉｏｎである。ＷＳ−Ｆｅｄｅｒａｔｉｏｎは、拡張マークアップ言語（ＸＭＬ）セキュリティ・トークンを使用することによって、企業間の境界を横切ってアイデンティティの共有を可能にする。これらのＸＭＬトークンは、ＳＡＭＬ（Security Assertion Markup Language）またはＸｒＭＬ（Extensible Rights Markup Language）などのフォーマットを使用する。
【０００４】
通常、セキュリティ・トークン内のクレイム（claim：申告）は、一対の企業間を流れる。しかし、セキュリティの理由から、ウェブ・クライアントまたはネットワーク・パートナーがアクセスするリソースが、セキュリティ境界の外側に配置される場合がある。セキュリティ境界の確立は、セキュリティを保つために、シャドウ・ディレクトリと、トークン転送機構を要求する場合がある。この配置は、ユーザによるマルチプル・サイン・オンを要求する。通常のトークン交換では、トークンのオリジネータを、アイデンティティ・プロバイダと呼ぶ。アイデンティティ・プロバイダは、ユーザのアイデンティティおよび認証を所有する。トークンの消費者を、リソース・プロバイダと呼ぶ。リソース・プロバイダは、任意の個数のウェブ・サービスまたは他のアプリケーションを提供することができる。暗号による信頼を、２つの当事者間で確立することができ、その結果、リソース・プロバイダが、セキュリティ・トークンのオーソリティとしてアイデンティティ・プロバイダを認証することができる。
【０００５】
【特許文献１】米国特許出願第０９／８８６１４６号
【特許文献２】米国特許出願第１０／０２９４２６号
【特許文献３】米国特許出願第１０／４３６８８０号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
エクストラネットおよびフェデレーテッド・アクセスを可能にし、Ｗｉｎｄｏｗｓ（登録商標）トークンをＤＭＺ内で動作するアプリケーションに供給することを可能にすることが必要とされている。
【課題を解決するための手段】
【０００７】
本発明は、コンピュータ・ユーザを認証するシステムに関する。このシステムは、フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、およびインターネット接続を介してウェブ・サーバに結合された、ウェブ・サーバにサイン・オンすることができる、フェデレーテッド・パートナーに配置されたクライアントを備える。
【発明を実施するための最良の形態】
【０００８】
この説明は、添付図面に鑑みて次の説明を読むことからよりよく理解される。添付図面で、同一の符号が、同一の部分を指定するのに使用されている。
【０００９】
添付図面に関して下で示す詳細な説明は、この例の説明として意図されたものであり、この例が構成したりまたは使用したりすることのできる唯一の形態を表すことを意図してはいない。この説明は、この例の機能と、この例を構成し、および動作させるためのステップのシーケンスとについて記述している。しかし、同一のまたは同等の機能およびシーケンスを、異なる例によって達成することもできる。
【００１０】
この例を、本明細書でインターネット・システムに実装されるものとして説明し、図示するが、説明されるシステムは、制限ではなく例として提供される。当業者が諒解するように、この例は、さまざまな異なるタイプのネットワーク・システムでの応用に適する。
【００１１】
作成され、企業ネットワーク（corporate networks）で現在使用されている多数の既存ウェブ・アプリケーションがある。これらのアプリケーションの多くは、アプリケーションへのアクセスを制限するのに伝統的なＷｉｎｄｏｗｓ（登録商標）許可制御機構（authorization mechanisms）を使用する。アプリケーションでは、これは、Ｗｉｎｄｏｗｓ（登録商標）ＳＩＤ（Security Identifier）（ユーザＳＩＤおよびグループＳＩＤ）を使用するＷｉｎｄｏｗｓ（登録商標）ベースのアクセス制御リスト（「ＡＣＬ」）に対するアクセス検査をＷｉｎｄｏｗｓ（登録商標）トークンを用いて行えるようにするためにＳＩＤを含むＷｉｎｄｏｗｓ（登録商標）トークンを受け取ることを意味している。企業イントラネットからアクセスするだけでなく、インターネットから、およびパートナーの企業のネットワークからアクセス可能になるように、アプリケーションを移動させる傾向が増大している。これらのアプリケーションを移動させる負担を最小にするために、Ｗｉｎｄｏｗｓ（登録商標）許可制御（authorization ）を使用し続けることを可能にする最小限の変更（modification）が行われる。これを達成する第１ステップは、通常、アプリケーションを、関連するネットワークをアクセスから隔離するＤＭＺに移動することを要求する。ＤＭＺに課せられる通常のセキュリティ制約のゆえに、余分のシャドウ・アカウント（extra shadow accounts）を利用しない限り、現在のＷｉｎｄｏｗｓ（登録商標）認証機構を使用して、ＤＭＺ内のアプリケーションでＷｉｎｄｏｗｓ（登録商標）トークンを作成することは、通常は不可能である。
【００１２】
シャドウ・アカウントとは、実際の企業ユーザまたはパートナー・アカウントをシャドウイングするアカウントであり、たとえば、企業従業員は、企業ネットワーク内にアカウントを有し、ＤＭＺ内に追加のシャドウ・アカウントを必要とする。シャドウ・アカウントは、通常、Ｗｉｎｄｏｗｓ（登録商標）許可制御を可能にするために提供される。通常、シャドウ・アカウントは、これを更新したり、維持したりするのに管理者にかなりの労力を要求する。
【００１３】
トークンは、通常、ユーザを認証するのに使用される。ＡＤＦＳ（Active Directory Federation Service）（登録商標）は、データを交換するためのＤＭＺ内のアプリケーションに対する認証および許可制御のためにＡＤＦＳトークンを供給する認証システムの例である。ＡＤＦＳは、Ｗｉｎｄｏｗｓ（登録商標）トークンと異なるトークンを供給する。許可制御を提供するＷｉｎｄｏｗｓ（登録商標）トークンを、通常、ＮＴトークンと称する。提供される例は、エクストラネットおよびフェデレーテッド・アクセスを可能にすることができ、Ｗｉｎｄｏｗｓ（登録商標）トークンをＤＭＺ内で動作するアプリケーションに供給することを可能にすることができる。全体的な効果は、通常のセキュリティ手段または通常使用される制約と干渉しないこととすることができる。セキュリティ・トークンを転送する方法は、その内容が参照によって本明細書に組み込まれている２００４年１１月１９日に出願された米国特許出願第１０／９９３７４５号および２００５年５月１３日に出願された米国特許出願第ＴＢＤ号（弁理士整理番号３１２１５９．０１）に記載されている。
【００１４】
シングル・サイン・オン（「ＳＳＯ」）の第１の例は、コンピュータ・ユーザに、そのユーザが複数のアプリケーションにアクセスするときであっても、単一のアイデンティティを用いて、およびセッション当たり単一のログインによって、さまざまなリソースにアクセスする能力を与えることができる。第１の例は、追加の許可制御データを備えたＡＤＦＳトークンを供給することができ、その結果、Ｗｉｎｄｏｗｓ（登録商標）認証を実行できるようにするＷｉｎｄｏｗｓ（登録商標）ＮＴトークンを構成できるようになる。シングル・サイン・オンは、ユーザのアクティブ・ディレクトリ・アカウントがない状態でのウェブ・エージェントでのＮＴトークンの作成を可能にすることができる。したがって、第１の例では、認証データがトークンで供給されるので、シャドウ・アカウントを除去することができる。ウェブ・シングル・サイン・オン（「ＷｅｂＳＳＯ」）は、ブラウズ可能ウェブ・サイトだけに適用できる、ＳＳＯのサブセットである。ブラウズ可能ウェブ・サイトは、インターネットの人気に起因して、現在、ＳＳＯの支配的な形とみなされているのも当然である。
【００１５】
ＷｅｂＳＳＯ設計は、インターネット上のウェブ・サービスが使用するプロトコルおよびトークン・フォーマットを提供するように構成することができる。この方法の全般的な説明は、企業アカウントについて、企業アカウント・フォーレストからのＳＩＤが、企業ネットワーク内のＦＳ（Federation Server）によってＡＤＦＳトークン内に入れられるということである。次に、このＳＩＤが、ＤＭＺ内のＦＳによってフィルタリングされ、その後、ウェブ・サーバ（ＷＳ）のＡＤＦＳウェブ・サーバ・エージェントによって拡張される。次に、ＡＤＦＳウェブ・サーバ・エージェントが、これらのＳＩＤからトークンを作る。ＡＤＦＳトークンが、この過程の各ステップで認証されることに留意されたい。
【００１６】
フェデレーテッド・パートナー・アクセスまたはフェデレーテッド・リソース・サイン・オンの第２の例について、フェデレーテッド・パートナーは、ＤＭＺ内のアプリケーションにアクセスするために、Ｗｉｎｄｏｗｓ（登録商標）トークンも必要とする場合がある。従来のフェデレーテッド・パートナーには、シャドウ・アカウントが、通常、必要である、というのは、フェデレーテッド・パートナーのＷｉｎｄｏｗｓ（登録商標）（商標）フォーレストからのＳＩＤが、リソースＤＭＺでは役に立たないからである。通常、あるネットワークのＳＩＤは、別のネットワークにとって無意味である。この第２の例は、ウェブ・サーバが、アクティブ・ディレクトリ３０５からアカウント情報を転送するトークンを構成することによって、シャドウ・アカウントなしのフェデレーテッド・ユーザに対して従来のＷｉｎｄｏｗｓ（登録商標）ベース認証を使用することを可能にすることができる。フェデレーテッド・パートナーに対するＷｉｎｄｏｗｓ（登録商標）トークンを作るのに使用される処理を、下でさらに説明する。
【００１７】
さらに、ウェブＳＳＯは、コンピュータ・オペレーティング・システムのアイデンティティおよびアクセス管理機能を容易にする傾向がある。たとえば、本明細書で提示するシングル・サイン・オンの例は、シャドウ・アカウントを除去することによって、シャドウ・アカウントに関連するオーバーヘッドを減らす傾向がある。
【００１８】
図１に、コンピュータ・オペレーティング・システム１０４の一部として、シングル・サイン・オン１０７およびフェデレーテッド・リソース・サインオン１０８を示す。コンピュータオペレーティングシステム１０４に、通常、そのオペレーティング・システムのうちでネットワーキングを容易にすることができる部分１０５が含まれる。使用可能なネットワーキング機能１０５のうちで、シングル・サイン・オン（「ＳＳＯ」）１０６機能を、下で説明する例で、提供することができる。具体的に言うと、シャドウ・アカウントの除去を可能にするシングル・サイン・オン（「ウェブＳＳＯ」）１０７、およびシャドウ・アカウントの除去を可能にするフェデレーテッド・リソースへのアクセスを可能にするサイン・オン１０８を説明する。ウェブＳＳＯ １０７の第１の例は、フェデレーテッド・リソース・サイン・オン１０８の第２の例と独立に動作することができる。
【００１９】
エクストラネット・リソースにアクセスするためのトークン
ウェブ・シングル・サイン・オンは、通常、孤立して動作するコンピュータには存在しない。ウェブＳＳＯは、１つまたは複数のネットワークを形成するように連携して動作する複数のプロセッサ・ベース・デバイス上に、またはコンピューティング・デバイス１０１、１０２、１０３上に提供することができる。ネットワークを構成するコンピューティング・デバイスに、通常、サーバ１０３、ＰＣ １０２、ラップトップ・コンピュータ１０１、および類似物が含まれる。任意の台数のこれらのコンピューティング・デバイスに、ウェブＳＳＯ機能を与えることができ、その結果、これらが、ネットワークの機能のセキュリティおよび滑らかな動作を維持しながら、ＳＳＯ機能を提供するネットワークへのアクセスを試みる１つまたは複数のクライアント・コンピュータと共に動作できるようになる。フェデレーテッド・リソースへのアクセスを可能にする方法を、オペレーティング・システム１０４内に置くこともできる。フェデレーション・アクセス方法は、必ずしも、ＳＳＯ機能と同一位置にある必要はなく、互いに独立に存在することができる。
【００２０】
図２に、ウェブＳＳＯを実装するさまざまなネットワークの例を示す。ウェブＳＳＯを実施する際に、通常は、ＳＳＯ実施形態に特に重要になる可能性がある３つのネットワーク・コンポーネント（またはプレイヤ）がある。さまざまな構成でこれらのコンポーネントを展開する（利用可能に準備する）ことによって、さまざまなウェブＳＳＯ構成を可能にすることができる。
【００２１】
まず、ウェブ・サイトにアクセスするためにユーザが実行するプログラムとすることのできるウェブ・クライアント（ユーザ）２０８〜２１１が存在する可能性がある。この例に、インターネットにアクセスできる、普通のアプリケーションまたはブラウザが含まれる。
【００２２】
第２のコンポーネントは、通常は、ユーザがアクセスするリソースを含むサービスである、ウェブ・サイト（リソース所有者）２１２である。この例には、ユーザがアクセスすることができるさまざまなアプリケーション、ウェブページ、またはウェブ・サイトを含めることができる。ＳＳＯ状況では、企業などの組織が、インターネット上のクライアント２１０がアプリケーションにアクセスできるように、ＤＭＺ内にウェブ・サイト２１２を展開する（利用可能に準備得する）ことを望む可能性がある。この例では、企業が、許可制御を変更するためにアプリケーションをリワークすることなく、アプリケーションをイントラネット２０３からＤＭＺ ２０２に移動できる場合がある。しかし、ＤＭＺへのアプリケーションの移動は、過去において、従来の許可制御標準規格またはアクセス制御リストを介して信頼を確立するためにシャドウ・アカウントを設けることを必要とした。
【００２３】
最後に、通常は、ウェブ・サイト・リソースへのユーザ・アクセスを制御するためのアイデンティティおよび属性を定義するサービスであるアカウント・ストア（アカウント・アドミニストレータ）２０４〜２０７コンポーネントがある。この例に、ＬＤＡＰベース・ディレクトリ、ＳＱＬベース・データベース、および類似物を含めることができる。リソースは、イントラネット２０１、ＤＭＺ ２０２、またはインターネット２１８に常駐することができる。
【００２４】
ウェブＳＳＯを実装するシステムは、異なるＷｅｂＳＳＯシナリオを可能にするために３つの前に述べたコンポーネントを展開する（利用可能に準備する）ときに、柔軟性を提供する。この３つのコンポーネントのさまざまな構成は、Ｂ２Ｅ ２１７構成、フェデレーテッドＢ２Ｂ ２１４構成、フェデレーテッドＢ２Ｃ ２１５構成、およびエクストラネット２１６構成を可能にする。エクストラネット・リソースへのアクセスにトークンを使用することの第１の例を、エクストラネット構成２１６に示す。フェデレーテッド・リソースへのアクセスにトークンを使用することの第２の例を、フェデレーテッドＢ２Ｃ ２１５構成およびフェデレーテッドＢ２Ｂ ２１４構成に示す。第１および第２の例を、下でさらに説明する。
【００２５】
Ｂ２Ｅ（Business to Enterprise）２１７は、通常、サイト自体の会社の従業員２１１が、その企業のアカウント・ストア２０７からの従業員アイデンティティを使用して、ウェブ・サイト２１２にアクセスすることを可能にする。従業員は、イントラネットからまたはｖｐｎを必要とせずにそのウェブの外部から、このサイトにアクセスすることができる。フェデレーテッドＢ２Ｂ（Federated business to business）２１４は、通常、パートナー企業の従業員２０８が、彼らの（パートナー企業の）アカウント・ストア２０４からのアイデンティティを使用してウェブ・サイト２１２にアクセスすることを可能にする。フェデレーテッドＢ２Ｃ（Federated business to consumer）２１５は、通常、インターネット上の消費者２０９が、外部消費者アカウント・ストア（Ｐａｓｓｐｏｒｔなど）２０５からのアイデンティティを使用してウェブ・サイト２１２にアクセスすることを可能にする。Ｂ２Ｂは、通常、ある種の提携協定（partnering arrangement）を有する異なる企業の間のｅ−ｃｏｍｍｅｒｃｅを指し、個人または企業が別の企業の製品またはサービスを購入するＢ２Ｃまたはｂｕｓｉｎｅｓｓ−ｔｏ−ｃｏｎｓｕｍｅｒ関係と対照的である。エクストラネット２１６は、通常、消費者またはアドホックなパートナー２１０が、ウェブ・サイトの企業自体によって彼らに発行されたアカントで、そのサイトにローカルなエクストラネット・アカウント・ストア２０６で管理されるアカウントを使用して、ウェブ・サイト２１２にアクセスすることを可能にする。
【００２６】
このシナリオ２１４〜２１７のそれぞれで、ウェブ・サイト２１２は、異なるアカウント・ストア２０４〜２０７を効果的に信頼する。ウェブ・サイト２１２は、ローカル・アカウント・ストア２０６および２０７を直接に信頼し、パートナーまたは消費者のアカウント・ストア２０４および２０５を間接的に、フェデレーションを介して信頼する。フェデレーテッド信頼は、通常は、２つのアカウント・ストア所有者の間のビジネス・レベル契約を必要とする。したがって、１つのウェブ・サイトが、図示のように構成を混合して、調和させることができる。
【００２７】
セキュリティは、ウェブＳＳＯ構成で維持される。ＷｅｂＳＳＯは、通常は、安全な方法で各構成によって提示される異なる信頼シナリオを実装するためにアカウント・ストアおよびウェブ・サイトによって使用される認証（authentication）と許可制御（authorization）のインフラストラクチャを提供する。Ｂ２Ｅの例２１７では、従業員２１１が、内部サイトおよびＤＭＺ企業ウェブ・サイトならびにアウトソーシングされたベネフィッツ・サイト（benefits site）に、その従業員の企業アクティブ・ディレクトリ・アンデンティティ２０７を使用するシングル・サイン・オンを用いてアクセスすることができる。Ｂ２Ｂの例２１４では、ＷｅｂＳＳＯは、第１の組織が、第２の組織によってそれ自体のアクティブ・ディレクトリ２０４内で定義されて維持されるアイデンティティを使用して、ＤＭＺ ２０２内のＳｈａｒｅＰｏｉｎｔサイト２０６を第２の組織の従業員２０８とフェデレーテッド（連携）させることを可能にすることができる。
【００２８】
上で使用された用語の定義を、提供される例をユーザが理解するのを助けるために、次の段落でも提供される。しかし、これらの定義は、これらの例の実践を開示される構造に制限することを意図されたものではない。提供される例が、さまざまなネットワーク構成に適用できるものであり、１製造業者の設計、標準規格、または特定の実施形態に制限されないことを理解されたい。
【００２９】
フェデレーションは、通常、ユーザ・アイデンティティおよび権利付与（entitlements）を組織の間で可搬にするのに使用される契約、標準規格、および／または協力テクノロジを有する異なる組織（たとえば、異なる自律的アイデンティティ・ドメインまたは領域）の連携（association）を指す。この形では、ある領域のユーザは、複数のログオン・イベントなしで、異なる領域のウェブ・アプリケーションにアクセスすることができる。
【００３０】
フォーレスト（forest）は、より密接に関係する組織をリンクするのに使用することができる。ドメインは、しばしば、組織とそのメンバを表すのに使用される。ツリーは、通常は、ドメインまたは子ドメインのコレクションである。１つの企業内など、密接に関係するビジネス・エンティティを管理するために、各めいめいのツリー（tree）を、ドメイン・フォーレスト（forest）内で相互接続することができる。フォーレスト内のツリーは、通常、両方向の信頼関係によって接続される。ツリーが、一緒にグループ化され、フォーレスト内で１つのネットワーク・システムとして実装されると、フォーレスト境界が、信頼（たとえば、セキュリティ）境界になり、ドメイン・グループに対する管理上の分離の単位になる。
【００３１】
非武装地帯（「ＤＭＺ」）は、通常はローカル・エリア・ネットワーク（「ＬＡＮ」）とインターネットの間の境界で確立される周辺（perimeter）セキュリティ・ネットワークを指す場合がある。そのようなＤＭＺは、ＬＡＮ上のサーバをインターネット上の悪意のあるユーザから保護する役目を果たす。通常、ファイヤウォールが、ＬＡＮとＤＭＺの間にある。ＤＭＺに、プロキシ・サーバ、ウェブ・サーバ、および仮想プライベート・ネットワーク（「ＶＰＮ」）サーバが含まれる場合がある。プロキシ・サーバは、通常、ＬＡＮ上の情報にアクセスする外部ユーザにセキュア・アクセスを提供し、通常は、クライアント・コンピュータにトランスペアレントに見える。プロキシ・サーバは、特定のリソースへのアクセスを許さないようにプログラムすることができる。ウェブ・サーバは、通常、インターネット上の誰もがアクセス可能である。ＶＰＮサーバは、通常、インターネットを介するＬＡＮへのセキュア・アクセスを可能にするリモート・アクセス認証サーバ（remote access and authentication servers）である。ネットワークへのセキュア・アクセスは、従来のＫｅｒｂｅｒｏｓシステムなどのさまざまなセキュリティ・プロトコルによって提供することができる。セキュリティ・プロトコルとは、ネットワークおよびシステムが、これらのネットワークおよびシステムのリソースにアクセスするユーザ、コンピュータ、およびアプリケーションを認証できるようにするプロトコルである。セキュリティ・プロトコルは、さまざまな形の暗号化を使用して、ユーザの信任証（credentials）およびネットワーク通信の、プライバシ、信憑性（authenticity）、および保全性（integrity）を保証する。
【００３２】
図３は、エクストラネット・リソースへのアクセスにトークンを使用し、シャドウ・ディレクトリが除外されることを可能にする、ウェブＳＳＯ中のセキュリティを維持するのに通常使用されるシステム・コンポーネントを示すブロック図である。ウェブＳＳＯは、次のコンポーネントを提供することによってセキュリティを維持することができる。
【００３３】
第１に、アクティブ・ディレクトリのセキュリティ・トークン・サービス・プロキシ３０１を提供する。これらのサービスは、アクティブ・ディレクトリ３０５に含まれるアイデンティティおよび属性に関する、ウェブに対して適切なセキュリティ・トークン（web-appropriate security tokens）を作る。アクティブ・ディレクトリ３０５は、イントラネット３１３内にあり、ＤＭＺ ３１４内のプロキシ化されたサービス３０９によって保護されている。ウェブ・サーバ（「ＷＳ」）３２０は、アプリケーションをクライアントまたはウェブ・クライアント３１１から使用可能にするために、ＤＭＺ内に展開（使用可能に準備）される。ＤＭＺ内にＷＳを展開（使用可能に準備）することは、通常、ＤＭＺイントラネット境界をまたぐことによるセキュリティ問題を引き起こさずにＷＳとＦＳＲとの間で信頼が確立されるようにするために、ＤＭＺ内にＦＳＲ ３０９を展開（使用可能に準備）することを要求する。ＦＳＰ−Ａ ３２１は、ＦＳ Ａ ３０８のプロキシ・サーバである。
【００３４】
第２に、ウェブ・サイト信頼を管理するフェデレーション・サービス３０２が、さまざまなアカウント・ストア所有者との信頼を定義し、制御する機構をリソース所有者に与える。フェデレーション・サービスは、参照によってその内容を本明細書に組み込まれている２００１年６月２０に出願された特許文献１および２００１年１２月２１に出願された特許文献２に記載されている。
【００３５】
第３は、ウェブ・アプリケーションのＳＳＯエージェント・プロセス・セキュリティ・トークン３０３である。これらのエージェント（ＩＳＡＰＩエクステンションおよびトークン／クレイム・ライブラリ）は、セキュリティ・トークンを、アクセス制御のためにＩＩＳアプリケーションによって使用される、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社の商標）Ｉｍｐｅｒｓｏｎａｔｉｏｎコンテクスト・ロールまたはＡＳＰ．Ｎｅｔロールに変換することができる。代替実施形態では、セキュリティ・トークンを処理する同等のエージェントに置換することができる。セキュリティ・クレイムは、参照によってその内容を本明細書に組み込まれている２００５年４月２９日に出願された米国特許出願第１１／１１９２３６号にさらに詳細に記載されている。
【００３６】
第４に、インターオペラブル・ウェブ・サービス・プロトコルまたはパッシブ・クライアント・プロトコル３０４を提供する。アカウント・ストアおよびウェブ・サイトは、通常、直接には通信せず、セキュリティ・トークンが、これらの間で、ウェブ・サービス・フェデレーション・パッシブ・クライアント・プロトコルなどのプロトコルを使用して、クライアントによって、それらの間に伝えられる。このタイプのプロトコルは、ＳＡＭＬトークンおよびＸｒＭＬトークンを含むウェブ・サービス−セキュリティＸＭＬセキュリティ・トークンを交換する。代替案では、他の同等のプロトコルおよびトークン交換を使用することができる。例示的なインターオペラブル・ウェブ・サービス・プロトコルが、参照によってその内容を本明細書に組み込まれている２００３年５月１２に出願された特許文献３にさらに詳細に記載されている。
【００３７】
第５に、複数のアプリケーションを含むウェブ・サーバを提供する。このウェブ・サーバは、通常、サーバＦＳＲ ３０９を信頼する。
【００３８】
ウェブ・シングル・サイン・オン（「ＳＳＯ」）は、複数のアプリケーションにアクセスするときであっても、ユーザに、単一のアイデンティティ、およびセッションごとに単一のログオン、を用いてコンピュータ・リソースにアクセスする能力を与えることができる。ウェブ・シングル・サイン・オン（「ＷｅｂＳＳＯ」）は、通常、ブラウズ可能ウェブ・サイトだけに適用される、シングル・サイン・オンのサブセットとみなされる。しかし、インターネットの人気に起因して、ウェブ・シングル・サイン・オンが、ＳＳＯより普及する傾向がある。
【００３９】
ネットワークは、そのファイヤウォールの外側にＤＭＺゾーンを設けることができる。リソースは、このＤＭＺゾーン内に展開（利用可能に準備）されることになる。例示的実施形態によれば、企業ユーザは、シャドウ・アカウントなしでシングル・サイン・オンを使用する伝統的なＷｉｎｄｏｗｓ（登録商標）認証および許可を使用することによって、ＤＭＺリソースにアクセスする。このシナリオでは、企業は、ＤＭＺゾーンを有し、そこに、その企業が、企業ユーザがアクセス可能なリソース（たとえば、ＳｈａｒｅＰｏｉｎｔサーバ）を展開（利用可能に準備）する。
【００４０】
図４は、エクストラネット・アクセスに関する全体的な処理フローを示すブロック図である。エクストラネットＤＭＺアクティブ・ディレクトリ（「ＡＤ」）４０６は、コープネット（corpnet）アクティブ・ディレクトリ４０４への１方向Ｗｉｎｄｏｗｓ（登録商標）信頼（trust）を有する。ログオン・サーバ／フェデレーテッド・サーバ（「ＬＳ−Ｒ／ＦＳ−Ｒ」）４０９が、エクストラネット・リソース領域に展開（利用可能に準備）され、ログオン・サーバ／フェデレーテッド・サーバ（「ＬＳ−Ａ／ＦＳ−Ａ」）４０７が、コープネット・アカウント領域またはイントラネット４０１に展開（利用可能に準備）される。エクストラネット・リソース領域とコープネット・アカウント領域の間のフェデレーション信頼は、両側で「Ｗｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ」信頼としてフラグを立てられ、これは、エクストラネット領域が、コープネット領域ＡＤストアからのユーザに伝統的なＷｉｎｄｏｗｓ（登録商標）認証および許可制御を使用するアプリケーションを有することを意味する。ウェブ・サーバ（「ＷＳ」）で動作する信頼するアプリケーションは、フェデレーション・サーバ（「ＦＳ−Ｒ」）で「Ｗｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ」としてフラグを立てられ、これは、そのアプリケーションが、ローカルＮＴアクセス・トークンを作るためにユーザＳＩＤを受け入れることを意味する。
【００４１】
クライアントは、ＤＭＺに展開（利用可能に準備）されたウェブ・サーバＷＳで動作する伝統的なウェブ・アプリケーションにアクセスする。クライアントは、インターネットまたはイントラネットに位置することができる。最終目標は、ＷＳでＮＴアクセス・トークンを作り、その結果、通常のＮＴ許可制御を、アクセスされるリソースのアクセス制御リスト（「ＡＣＬ」）に対して使用できるようにすることである。これは、ユーザ許可制御属性（ＳＩＤ）がある形でＷＳに配布されることを意味する。
【００４２】
図５および図６は、インターネット上のクライアントがエクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。Ｗｉｎｄｏｗｓ（登録商標）信頼を確立するためのトークン交換のフローは、Ｗｉｎｄｏｗｓ（登録商標）ネットワークまたはその同等物に典型的な形で維持される。しかし、トークンの構成および内容（content）は、シャドウ・アカウント内ではなくトークン内にセキュリティ識別子（「ＳＩＤ」）を設けることによって変更されている。認証について、ＳＩＤは、既に存在し、アプリケーションが、アプリケーションのドメイン内のシャドウ・アカウントからＳＩＤを取り出す必要はない。
【００４３】
第１に、インターネット上のクライアントが、（ＨＴＴＰ ＧＥＴを介して）ＤＭＺ内に位置する所望のアプリケーションを有するウェブ・クライアントからのリソースＵＲＬにアクセスする（ブロック５０１）。このクライアントは認証クッキーを有しないので、このクライアントはＬＳ−Ｒ／ＦＳ−Ｒにリダイレクトされる。第２に、ＬＳ−Ｒは、クライアント・ホーム領域を決定し、クライアントをＬＳ−Ａ−ＥＸＴにリダイレクトする（ブロック５０２）。
【００４４】
クライアントが、コープネットに位置する場合に、クライアントは、ＬＳ−Ａ−ＥＸＴではなくＬＳ−Ａにその要求を送信する。この実施形態には、少数のオプションがある。たとえば、特殊なＤＮＳ構成をコープネットＤＮＳサーバで使用し、その結果、ＬＳ−Ａ−ＥＸＴ名がＬＳ−ＡのＩＰアドレスに解決されるようにすることができる。代替実施形態で実行されるもう１つの可能性は、ＬＳ−Ａ−ＥＸＴに２つのＮＩＣ（一方のＮＩＣはコープネットに面し、他方はインターネットに面する）を有し、どちらのＮＩＣがＬＳ−Ａ−ＥＸＴへの接続に使用されているかに基づいてクライアントのローカリティを決定することである。この場合に、ＬＳ−Ａは、ＦＳ−ＡにすべてのユーザＳＩＤを与える統合認証を使用する。
【００４５】
あるいは、クライアントがインターネットに位置する場合に、ＬＳ−Ａ−ＥＸＴが、ユーザ信任証（ユーザ名およびパスワードまたはクライアント証明書）を収集し、これらを信任証検証または検査のためにＦＳ−Ａに送信する（ブロック５０３）。ＦＳ−Ａは、ユーザ信任証を検証する。信任証が検証された後に、ＦＳ−Ａは、ローカルＮＴアクセス・トークンからのユーザＳＩＤのコレクションを有する（ブロック５０４）。
【００４６】
前のステップでユーザＳＩＤを入手したので、ＦＳ−Ａは、そのＳＩＤをグループ・クレイムに変換し、ユーザＡＤアカウントからのＬＤＡＰ属性を使用してカスタム・クレイムを入手する（ブロック５０５）。次に、リソース領域がＷｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔであるならば、ＦＳ−Ａは、ユーザのアカウント・グループＳＩＤを入手する（ブロック５０６）。次に、ＦＳ−Ａは、Ａｄｖｉｃｅ要素内の属性およびアカウント・グループＳＩＤとして変換されたＷｅｂＳＳＯクレイムを運ぶＳＡＭＬトークンを発行する（ブロック５０７）。さらなる詳細については、Ａｄｖｉｃｅ要素のフォーマットに関するセクション「ＳＩＤパッキング」を参照されたい。ＦＳ−Ａは、このＳＡＭＬトークンをインプロセスでＬＳ−Ａに渡すか（事例３ａ）、このトークンをＬＳ−Ａ−ＥＸＴに送り返す（事例３ｂ）（ブロック５０８）。ＬＳ−Ａ／ＬＳ−Ａ−ＥＸＴは、このＳＡＭＬトークンをクッキーとしてクライアントに書き込み、そのクライアントをＬＳ−Ｒ／ＦＳ−Ｒにリダイレクトする（ブロック５０９）。
【００４７】
ＦＳ−Ｒは、ＳＡＭＬトークンを受信し、検証する（ブロック５１０）。トークンの検証に成功すると、ＦＳ−Ｒは、トークンから入手したクレイムに関する普通のクレイム変換を実行する。次に、アカウント領域がＷｉｎｄｏｗｓ（登録商標）ＲｅａｌｍＴｒｕｓｔ領域であるならば、ＦＳ−Ｒは、ＳＡＭＬ Ａｄｖｉｃｅ要素からのユーザＳＩＤを処理する（ブロック５１１）。具体的に言うと、ＦＳ−Ｒは、受信したＳＩＤをフィルタリングする（下のセクション「ＳＩＤフィルタリング」で説明するように）。ＦＳ−Ｒは、Ａｄｖｉｃｅ要素内に属性およびフィルタリングされたアカウント・グループＳＩＤとしてＷＳに適切に変換されたクレイムを運ぶＳＡＭＬトークンを、ＷＳに発行する（ブロック５１２）。図６の流れ図に継続して、ＦＳ−Ｒは、制御をＬＳ−Ｒに返し、このＬＳ−Ｒは、生成されたＳＡＭＬトークンをクッキーとしてクライアントに書き込み、このクライアントをＷＳにリダイレクトする（ブロック６１３）。
【００４８】
ＷＳのＷｅｂＳＳＯ ＩＳＡＰＩエクステンションが、トークンを受信し、クライアントがアクセスを試みていたオリジナルＵＲＬにリダイレクトする（６１４）。このリダイレクトでは、ＩＳＡＰＩエクステンションが、ＷｅｂＳＳＯトークンをクッキーとして書き込む。
【００４９】
ＷＳのＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、クッキーとしてトークンを受信し、検証のためにＷｅｂＳＳＯサービスに渡す（ブロック６１５）。このサービスは、トークンを検証し、ＳＩＤを入手し、このＳＩＤをＷｅｂＳＳＯ認証パッケージに渡す（ブロック６１６）。このパッケージは、ＳＩＤを拡張して、ＷＳが参加しているドメインにリソース・グループＳＩＤを追加する（ブロック６１７）（下のセクション「グループ拡張」を参照されたい）。ＳＩＤの結果のコレクションを使用して、ＮＴアクセス・トークンを作る（ブロック６１８）。ブロック６１５〜６１８は、セキュリティの理由から、ＮＴサービスおよびＬＳＡ認証パッケージが、ＷｅｂＳＳＯトークンの検証に使用され、その後、そのトークンからのＳＩＤをＮＴアクセス・トークンに変えることを示している（ブロック６１９）。ＳＩＤコレクションは、将来の使用のために、認証パッケージ内でキャッシングされ、入ってくるアカウントＳＩＤのハッシュによってキーイングされる（ブロック６２０）。ＮＴアクセス・トークン・ハンドルは、将来の使用のために、ＷｅｂＳＳＯ ＩＳＡＰＩエクステンション内でキャッシングされ、ＳＡＭＬトークンのハッシュによってキーイングされる（６２１）。
【００５０】
クライアントに書き込まれたクッキーは、シングル・サイン・オン体験を達成すること、および繰り返される動作で、通常では手間のかかる動作を防ぐこと、に使用される。ブロック５０８（図５の）で書き込まれるクッキーは、クライアントがリソース領域からアカウント領域にリダイレクトされるときに使用され、その結果、ユーザ信任証検査およびクレイム／ＳＩＤ抽出を避けることができる。ブロック５１０（図５の）で書き込まれるクッキーは、クライアントがリソース・アプリケーション・サーバによってリソース領域ＦＳ−Ｒにリダイレクトされるときに使用され、その結果、クレイム変換およびＳＩＤフィルタリングを避けることができる。ブロック６１４で書き込まれるクッキーは、クライアントがＷＳと通信するときに次のように使用される。
【００５１】
ＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、（クッキーで送信されたＳＡＭＬトークンをハッシュ化し、そのハッシュに対応するキャッシュ・エントリを見つけることによって）そのキャッシュ内でキャッシングされたＮＴトークンを検索することになり、したがって、ユーザは、即座に成りすますことができる。キャッシングされたＮＴトークンが見つからない場合には、ＷｅｂＳＳＯ ＩＳＡＰＩエクステンションは、クッキーからのＳＩＤをＷｅｂＳＳＯ認証パッケージに渡し、このＷｅｂＳＳＯ認証パッケージは、そのキャッシュを検索して、入ってくるＳＩＤのハッシュと等しいキーを有するエントリを見つけ、その結果、リソース・グループＳＩＤ拡張を避けることができるようになる。ＷｅｂＳＳＯ認証パッケージは、そのキャッシュ内でＳＩＤを見つけない場合に、上のブロック６１５〜６２１で指定されたようにＮＴアクセス・トークンを作ることになる。
【００５２】
リソース・グループ拡張プロセスの代替の例は、ＷＳではなくＦＳ−Ｒでグループを拡張することである。この方法では、ＦＳ−Ｒは、すべてのＳＩＤを使用してクライアントにクッキーを書き込み、他のリソースがＷＳと同一のドメインに参加しているならば、そのクライアントが次に他のリソースにアクセスするときにそのＳＩＤを使用する。しかし、これは、すべての展開されたアプリケーショ・ンサーバに関するドメインのＦＳ−Ｒに関する知識を要求する。これを達成する方法の１つは、アプリケーションで準備され、ＦＳ−Ｒに送信される、ｗｃｔｘパラメータの一部としてドメイン名を含めることである。このパラメータは、認証されず、したがって、ＷＳは、そのＷＳが参加しているもの以外のドメイン名を置くことができる。
【００５３】
もう１つの代替の例が、信頼するアプリケーションが追加されるときに信頼ポリシでＷＳのドメインを構成することであるが、この手法は、通常、より多くの管理を要求する。
【００５４】
信任証検査（Credentials Verification）
次の説明は、上でステップ５０３（図５の）で説明した信任証検査プロセスを詳説するものである。このプロセスでは、ＦＳ−Ａが、２タイプのユーザ信任証、すなわち、ユーザ名およびパスワードと、クライアント証明書を検証する。ユーザ名およびパスワードは、公表されたＬｏｇｏｎＵｓｅｒ ＡＰＩを介して検証される。その結果は、通常はすべてのユーザＳＩＤ（ＦＳ−Ａが参加しているドメインのアカウントＳＩＤおよびリソースＳＩＤ）を含むＮＴアクセス・トークンである。ユーザ名は、ＵＰＮフォーマット（ｕｓｅｒ＠ｓｏｍｅｗｈｅｒｅ．ｃｏｍ）またはＳＡＭアカウント名フォーマット（ｓｏｍｅｗｈｅｒｅ＼ｕｓｅｒ）とすることができる。クライアント証明書は、通常、次のデータ構造体の証明書を収容するプロトコル・サブミット・バッファを備えるＬｓａＣａｌｌＡｕｔｈｅｎｔｉｃａｔｉｏｎＰａｃｋａｇｅ呼び出しを介してＷｅｂＳＳＯ認証パッケージにクライアント証明書を渡すことによって検証される。
【００５５】
【表１】
【００５６】
この呼び出しは、通常、信頼されない呼び出し元から許可されるので、ＦＳ−Ａは、ＴＣＢ特権を保持する必要がない。しかし、パッケージは、ユーザ・セキュリティ属性を返すので、パッケージは、呼び出し元がＦＳである場合に限ってこの呼び出しを許可することができる。この目的のために、ＦＳセットアップは、通常、ローカル・マシン・グループＡＤＦＳＧｒｏｕｐを作成し、ＦＳアカウントをこのグループに入れる。認証パッケージは、呼び出し元がそのＮＴアクセス・トークン内にＡＤＦＳＧｒｏｕｐ ＳＩＤを有することを検査する。
【００５７】
ＷｅｂＳＳＯパッケージは、内部ＬｓａｌＣａｌｌＰａｃｋａｇｅ呼び出しを介して、検査のために、証明書をＷｉｎｄｏｗｓ（登録商標） ＴＬＳ／ＳＳＬ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（登録商標）に、渡す。検査に成功すると、ＷｅｂＳＳＯパッケージは、ユーザＵＰＮ、ユーザ・アカウント・ドメイン名、およびユーザトークン・グループ（ＳＩＤ）を次のデータ構造体で返す。
【００５８】
【表２】
【００５９】
グループ拡張
次の説明は、上でステップ６１７で説明した信任証検査プロセスを詳説するものである。ＦＳ−Ａは、アカウントおよびリソース・グループ拡張を、そのために実装された新しいＡｕｔｈＺ（「AuthZ」は、AuthenticationとAuthorizationとを表す略語）機能性であるＡｕｔｈｚｉＷｅｂＳｓｏＧｅｔＧｒｏｕｐｓＢｙＳｉｄを使用することによって、実行する。ＡｕｔｈＺは、現在、グループ拡張を行うが、その拡張は選択的でない、すなわち、アカウントとリソース・グループの両方が、必ず拡張される。ＡｕｔｈＺは、拡張が分離され、その結果、アカウント側（ＦＳ−Ａ）がアカウント・グループを拡張でき、リソース側（ＷＳ）が、そのめいめいのドメイン内のリソース・グループを拡張できるように変更されている。さらに、ＡｕｔｈＺによって使用されるＬＤＡＰハンドルおよびＳＡＭハンドルをキャッシングするように、性能最適化が実施されている。
【００６０】
ＳＩＤパッキング
ＳＡＭＬトークンのサイズを減らすために、ＳＩＤは、次のようにＳＡＭＬ Ａｄｖｉｃｅ要素にパックされている。Ａｄｖｉｃｅ要素は次の通りである。
【００６１】
【表３】
【００６２】
（「ｈｔｔｐ：／／ｆａｂｒｉｋａｍ．ｃｏｍ／ｆｅｄｅｒａｔｉｏｎ／ｖ１／Ｗｉｎｄｏｗｓ（登録商標）Ｉｄｅｎｔｉｆｉｅｒｓ」は、テンポラリ名前空間であることに留意されたい）。Ｗｉｎｄｏｗｓ（登録商標）Ｉｄｅｎｔｉｆｉｅｒｓ要素には、次のフォーマットでユーザＳＩＤを収容するｂａｓｅ６４エンコーデッド・ストリングを収容する。
【００６３】
Ｆｌａｇｓ｜ＤｏｍａｉｎＳｉｄＣｏｕｎｔ｜ＡｃｃｏｕｎｔＤｏｍａｉｎＳｉｄ｜ＲｉｄＣｏｕｎｔ｜Ｒｉｄ＿１｜…｜Ｒｉｄ＿Ｎ｜ＤｏｍａｉｎＳｉｄ｜ＲｉｄＣｏｕｎｔ｜Ｒｉｄ＿１｜…｜Ｒｉｄ＿Ｍ｜…
ここで、縦セパレータ｜は、ＤＷＯＲＤ境界を示す。最初のＤＷＯＲＤは、Ｆｌａｇｓパラメータである。ＷＳが受信したＦｌａｇｓパラメータのビット１がセットされている場合に、これは、ＷＳが、リソース・グループを追加するためにグループを拡張する必要があることを示す。第２のＤＷＯＲＤは、このバッファに何個のドメインＳＩＤが存在するかを示すパラメータである。次のＤＷＯＲＤは、アカウント・ドメインＳＩＤである最初のドメインＳＩＤである。次のＤＷＯＲＤは、アカウント・ドメインＳＩＤのＲＩＤの個数である。アカウントＳＩＤおよびグループＳＩＤが、ドメインＳＩＤを対応するＲＩＤと組み合わせることによって構成されることに留意されたい。次のＤＷＯＲＤは、ユーザアカウントのＲＩＤである。これに、グループＲＩＤ（ＲｉｄＣｏｕｎｔで定義された個数より１つ少ない）が続く。次に、次ドメインＳＩＤがあり、そのドメインのＲＩＤカウントが続き、ＲＩＤが続く。このパターン自体は、ＲＩＤを有するすべてのドメインＳＩＤが列挙されるまで繰り返される。
【００６４】
ＳＩＤフィルタリング
ＷｅｂＳＳＯは、ＦＳ−Ｒに対するＳＩＤフィルタリングを実行し、このフィルタリングは、通常リソース・ドメイン・コントローラに対して実行されるネイティブＳＩＤフィルタリングと同一のルールに従う。フィルタリングは、通常のＷｉｎｄｏｗｓ（登録商標）実装形態を使用すること、内部ＤＣ固有Ｗｉｎｄｏｗｓ（登録商標） Ｌｏｃａｌ Ｓｅｃｕｒｉｔｙ Ａｕｔｈｏｒｉｔｙ（「ＬＳＡ」）（ＬＳ−Ａと混同してはならない）ルーチンを実装すること、によって達成される。このルーチンは、ドメインおよびフォーレストの信頼トポロジを計算し、ランタイムにＳＩＤ検索を実行する。これらを実装するために、ルート・ドメインＤＣからのドメイン信頼およびフォーレスト信頼が、ＤｓＥｎｕｍｅｒａｔｅＤｏｍａｉｎＴｒｕｓｔｓ ＡＰＩおよびＤｓＧｅｔＦｏｒｅｓｔＴｒｕｓｔＩｎｆｏｒｍａｔｉｏｎＷ ＡＰＩを使用することによって入手される。これらのＡＰＩは、信頼境界を決定し、エクストラネット信頼の信頼タイプおよび信頼属性を識別するのに必要な情報を返す。その情報を得ると、任意の所与のＳＩＤを、ローカル・フォーレストならびに（クロス・フォーレスト信頼に関して直接にまたは他動的に信頼される）信頼されるドメインのドメインＳＩＤと突き合わせることができる。その情報は、ドメイン信頼変化を考慮に入れるために周期的に更新される。これによって、使用される内部ＬＳＡ ＡＰＩの実装が可能になり、その結果、同一のコア・コード・ベースを使用できるようになる。この文書の最後のセクションで、これらのリソースへのフェデレーテッド・パートナー・アクセスを扱う。
【００６５】
フェデレーテッド・リソースにアクセスするためのトークン
図７は、エクストラネット・リソースに対するフェデレーテッド・パートナーに関する全体的な処理フローを示す流れ図である。エクストラネットＤＭＺアクティブ・ディレクトリに、ウェブＳＳＯトークンをマッピングできるアクティブ・ディレクトリ内のシャドウ・アカウントが含まれ、その結果、ＮＴアクセス・トークンを生成することができるようになる。ウェブＳＳＯトークンを得るプロトコルは、上で説明したプロトコルおよびＷＳ−フェデレーション・プロトコルに類似する。ＦＳ−Ｒが、アカウントＦＳによって発行された、クライアントのウェブＳＳＯトークンを得たならば、ＦＳ−Ｒは、そのトークンのクレイムをマッピングすることができる。
【００６６】
図８は、ＮＴアクセス・トークンの生成を可能にするためにクレイムをマッピングする３つの異なる形を示す流れ図である。
【００６７】
第１に、ユーザ・プリンシパル名（「ＵＰＮ」）クレイムに、ＦＳ−Ａ内でトークンを発行し（８０１）、このクレイムを、ＦＳ−Ｒによって無変更でＷＳに渡す（８０２）。この場合に、フェデレーテッド・クライアントのＵＰＮクレイムに一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。
【００６８】
第２に、電子メール・クレイムにＦＳ−Ａ内でトークンを発行し（８０３）、クレイムをＵＰＮクレイムに変更する（８０４）。このクレイムを、ＦＳ−ＲによってＷＳに渡す（８０５）。この場合に、フェデレーテッド・クライアントの電子メール・アドレスと一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。
【００６９】
第３に、グループ・クレイムにＦＳ−Ａでトークンを発行し（８０６）、このグループ・クレイムをＵＰＮクレイムにマッピングする（８０７）。この場合に、マッピングするＵＰＮに一致するＵＰＮを有するＤＭＺ ＡＤにシャドウ・アカウントがあると仮定する。この場合に、複数のクライアントが１つのシャドウ・アカウントにマッピングされることに留意されたい。
【００７０】
現在、シャドウ・アカウントが必要である唯一の場所は、伝統的な（ＮＴアクセス・トークン・ベースの）アプリケーションを展開する（利用可能に準備する）、フェデレーテッド・リレーションシップのリソース側である。シャドウ・アカウントは、通常、ＡＤＦＳウェブ・エージェントが、ＮＴアクセス・トークンを作るために、シャドウ・アカウントを偽装できる（成りすますことができる）ようにするために必要である。シャドウ・アカウントは、通常、アカウントを展開（利用可能に準備）し、維持する必要があるので、顧客の主要な関心事である。多くの場合に、シャドウ・アカウントは、ＤＭＺでのＡＤＦＳの展開する場合に、展開ブロッカを構成する。
【００７１】
この第２の例では、非ＤＭＺアカウント領域から受信したインバウンド・グループ・クレイムをローカル・リソースＡＤグループに変換することによってシャドウ・アカウントを除去し、ＡＤグループＳＩＤを使用してＮＴトークンを作ることができる。リソースは、ローカルＡＤグループＳＩＤを用いてＡＣＬを与えられ、したがって、結果のＮＴトークンは、リソース・アプリケーションによって実行されるアクセス検査に対して適切なものになる。
【００７２】
シャドウ・ディレクトリを除去することができる、この第２の例を実装するために、新しい企業グループ・クレイム・タイプであるＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍを使用する。クレイムは、通常、オーソリティが、名前、アイデンティティ、キー、グループ、特権、機能、および類似物など、のプリンシパルに関して作ることができるステートメントである。クレイムは、セキュリティ・トークンによってアサートすることができる。
【００７３】
このクレイム・タイプは、対応するＡＤグループのＳＩＤであるＳＩＤプロパティを追加することによって、ＧｒｏｕｐＣｌａｉｍを拡張する。ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍは、ＧｒｏｕｐＣｌａｉｍであり、したがって、通常、クレイム変換などの企業グループ・クレイムを現在操作するすべての場所でそのようなものとして扱われる。
【００７４】
ランタイムに、リソースＦＳ−Ｒが非ＤＭＺ領域からインバウンド・トークンを得、インバウンド・グループ・クレイムを、アプリケーションに発行されたアウト・バウンド企業グループ・クレイム（ＡＤグループを含めることができる）に変換した後に、ＦＳ−Ｒは、通常、アウトバウンド・コレクションで見つかったＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍごとにＡＤグループＳＩＤを追加する。
【００７５】
グループＳＩＤのほかに、ＦＳは、通常、信頼される領域ＵＲＩから導出されたユーザＳＩＤおよびインバウンド・トークン内のアイデンティティ・クレイムの値を生成する（ユーザＳＩＤ生成アルゴリズムの詳細については以下を参照されたい）。
【００７６】
結果のユーザＳＩＤおよびグループＳＩＤは、発行される新しいトークンのＡｄｖｉｃｅ要素の形でウェブ・サーバ・エージェントに渡され、これは、通常、ＤＭＺリソースＦＳ−Ｒによって普通に行われるのと同一の形である。
【００７７】
ウェブ・サーバ（ＷＳ）は、ＳＩＤを得、これを拡張してリソース・ドメイン・ローカル・グループＳＩＤを追加し、このＳＩＤを有するトークンを、普通の認証パッケージを介して作る。ＮＴトークンを作るために、ＳＩＤのほかに、認証パッケージは、それぞれ、起点アカウント・オーソリティおよび結果のログオン・セッションのユーザ名としてセットされるＡｕｔｈｅｎｔｉｃａｔｉｎｇＡｕｔｈｏｒｉｔｙプロパティおよびＡｃｃｏｕｎｔＮａｍｅプロパティを有する必要がある場合がある。アカウント領域ＵＲＩおよびアイデンティティ・クレイム値を、それぞれ、この目的に使用することができる。
【００７８】
結果として、アカウント領域ＵＲＩおよびユーザ・アイデンティティが、許可制御パッケージによって実行されるログオンの成功に基づいて、ＬＳＡによって生成されるセキュリティ監査イベントでログインされる。これは、シャドウ・アカウントではなく実際のユーザアカウントに関する監査能力を提供するので、有用な機能である場合がある。
【００７９】
そのような監査の例を、下に示す。この監査は、上で説明したように変更された認証パッケージによるユーザｕｓｅｒ＠ａｄａｔｕｍ．ｃｏｍのログオンが成功したときに生成されたものである。
【００８０】
【表４】
【００８１】
さらなる代替の例では、顧客が、一部のユーザについてシャドウ・アカウントを配置し、他のユーザについてＳＡＭＬグループ−ＡＤグループ変換（ＳＧ２ＡＤＧ）を使用することができる。原理的に、ＵＰＮ／電子メールおよびＳＩＤの所与の組について、まず、シャドウ・アカウント・ログオンを実行すること試み、シャドウ・アカウント・ログオンが、ユーザが存在しないことを示すエラーで失敗する場合に、ＳＩＤを用いるログオンを行うことができる。しかし、これを行うことは、通常、シャドウ・アカウントが多数のユーザについて利用可能に準備されていない場合に、性能（perf）に大きく影響する。
【００８２】
シャドウ・アカウントまたはＳＩＤのどちらを使用するかを決定するために、信頼される領域の新しい信頼ポリシＯＭ列挙タイプ、ＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅが追加されている。この列挙は、通常、４つの値すなわち、Ｕｎｓｐｅｃｉｆｉｅｄ、ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔ、ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓ、およびＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓを有する。Ｕｎｓｐｅｃｉｆｉｅｄは、シャドウ・アカウント存在が、この領域からのユーザについて指定されていないことを意味する。これは、デフォルト値である。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔは、この信頼される領域から来るユーザについてシャドウ・アカウントが展開（利用可能に準備）されていないことを意味する。この場合に、ＳＧ２ＡＤＧ変換から生じるＳＩＤが、ＮＴトークンの作成に使用される。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓは、通常、シャドウ・アカウントが、この信頼される領域からのユーザの一部について展開（利用可能に準備）されていることを意味する。この場合に、シャドウ・アカウントＵＰＮ／電子メールを用いるログオンが、まず試みられ、その後、ＳＩＤを用いるログオンが、この信頼される領域からのユーザについて次に試みられる。ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓは、通常、シャドウ・アカウントが、この信頼される領域からのすべてのユーザについて展開（利用可能に準備）されていることを意味する。この場合には、シャドウ・アカウントＵＰＮ／電子メールを用いるログオンだけが試みられる。
【００８３】
ランタイムに、ＦＳ−Ｒが伝統的なアプリケーションにＳＡＭＬトークンを発行するときに、ＦＳ−Ｒは、発行されるＳＡＭＬトークンで、そのアプリケーションが実行しなければならないログオンのタイプを示す。ＦＳ−Ｒは、次のように、ＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅの値に基づいてログオンのタイプを決定する。
【００８４】
Ｕｎｓｐｅｃｉｆｉｅｄ：結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンだけを試みなければならないことを示す。そうではなく、ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、シャドウ・アカウント・ログオンだけを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に失敗する。
【００８５】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＡｂｓｅｎｔ：結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に
失敗する。
【００８６】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＳｏｍｅＵｓｅｒｓ：ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、シャドウ・アカウント・ログオンだけを試みなければならず、アプリケーションに発行されたＳＡＭＬトークンにＳＩＤが存在するならば、次にＳＩＤログオンを試みなければならないことを示す。そうではなく、結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合に、ＦＳ−Ｒは、ＳＩＤを用いるログオンを試みなければならないことを示す。そうでない場合に、ＦＳ−Ｒは、伝統的なＷＳがＮＴトークンを作ることができないので、ユーザ要求に失敗する。
【００８７】
ＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓ：ユーザ・アイデンティティがＵＰＮ／電子メールである場合に、ＦＳ−Ｒは、そのユーザについてシャドウ・アカウント・ログオンだけを試みなければならないことを示し、ＳＡＭＬトークンにＳＩＤを含めない。そうでない場合に、ＦＳ−Ｒは、結果のクレイム・コレクションにＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムが含まれる場合であっても、ユーザ要求に失敗する。実際に、ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍクレイムは、普通のＧｒｏｕｐＣｌａｉｍの意味でコレクションに現れる場合があり、これらをＳｈａｄｏｗＡｃｃｏｕｎｔｓＦｏｒＡＩＩＵｓｅｒｓの値に従ってＡＤグループとして扱うことは、管理者の意図ではない。
【００８８】
ＷＳに発行されたＳＡＭＬトークン内のパックされたＳＩＤ構造体の存在は、ＷＳがＳＩＤログオンを試みなければならないことを示す。この構造体は、ＳＩＤログオンの前にシャドウ・アカウント・ログオンを試みなければならないかどうかも示す。具体的に言うと、この構造体のＦｌａｇｓパラメータのビット２がセットされている場合に、ＷＳは、まず、ＳＡＭＬトークンからのＵＰＮ／電子メール・アイデンティティ・クレイムを使用してシャドウ・アカウント・ログオンを試みる。そうでない場合には、ＷＳはＳＩＤログオンだけを試みる。ＳＩＤ構造体が存在しない場合には、ＷＳは、シャドウ・アカウント・ログオンだけを行う。
【００８９】
ＵＩは、通常、信頼される非ＤＭＺ領域のＳｈａｄｏｗＡｃｃｏｕｎｔＥｘｉｓｔｅｎｃｅ列挙タイプの値をセットすることをサポートする。ＵＩは、組織クレイム内の新しいＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙＧｒｏｕｐＣｌａｉｍのクレイム・タイプもサポートする。新しいクレイム・タイプと既存のグループ・クレイム・タイプの間の唯一の相違は、Ｓｉｄ属性の追加であり、このＳｉｄ属性は、ＡＤストアによるグループ・クレイムの取り込み時に、ＵＩ内に既に実装されているものと同一のＯｂｊｅｃｔ Ｐｉｃｋｅｒコードを介して取り込まれる。
【００９０】
ユーザＳＩＤ生成
ＦＳは、次のようにユーザＳＩＤを生成する。ＳＩＤは、所与の信頼される領域からの所与のユーザについて一意である。ＳＩＤは、通常、２８バイトの長さ（普通のＡＤ ＳＩＤのサイズである）である。ＳＩＤのＳＩＤ＿ＩＤＥＮＴＩＦＩＥＲ＿ＡＵＴＨＯＲＩＴＹには、通常は、他の既存ＳＩＤからそのＳＩＤを区別するために、新しいＡＤＦＳオーソリティがセットされる。ＳＩＤサブオーソリティに割り当てられた２０バイトは、文字列「＜ｔｒｕｓｔｅｄ ｒｅａｌｍ ＵＲＩ＞＼＜ｉｄｅｎｔｉｔｙ ｃｌａｉｍ ｖａｌｕｅ＞」のハッシュが書き込まれ、ここで、＜ｔｒｕｓｔｅｄ ｒｅａｌｍ ＵＲＩ＞は、ＳＡＭＬトークンを発行したアカウント領域のＵＲＩであり、＜ｉｄｅｎｔｉｔｙ ｃｌａｉｍ ｖａｌｕｅ＞は、ＳＡＭＬトークからのアイデンティティ・クレイム（ＵＰＮ、電子メール、またはＣｏｍｍｏｎＮａｍｅ）の値である。２０バイトのハッシュは、通常、所与の領域からの所与のユーザに一意のＳＩＤを生成するのに十分に長い。したがって、要約すると、生成されるＳＩＤは、通常、「Ｓ−１−＜ＡＤＦＳオーソリティ＞−＜２０バイトハッシュを書き込まれる５ＤＷＯＲＤサブオーソリティ＞」のように見える。
【００９１】
フェデレーテッド・クライアントに発行されるＷｅｂＳＳＯトークンが、Ａｄｖｉｃｅ要素内にＳＩＤを有しないことに留意されたい。ＷＳは、ＦＳ−Ｒによって発行されたＷｅｂＳＳＯトークンを、クッキーとして、ＵＰＮクレイムと共に受信する。ＷｅｂＳＳＯトークンは、ＮＴサービスによって検証され、ＵＰＮが、ＬＳＡ認証パッケージに渡される。ＷＳが、Ｗｉｎｄｏｗｓ（登録商標）２００３（Ｍｉｃｒｏｓｏｆｔ社の商標）ドメイン内にあり、Ｋｅｒｂｅｒｏｓ Ｓ４Ｕがサポートされる場合に、サービスは、ＬｓａＬｏｇｏｎＵｓｅｒを用いてＫｅｒｂｅｒｏｓ認証パッケージを呼び出し、ＮＴトークンが返される。ＷＳが、Ｗｉｎｄｏｗｓ（登録商標） ２０００ドメイン内にある場合に、ＷｅｂＳＳＯ認証パッケージが、ＬｓａＬｏｇｏｎＵｓｅｒを使用して呼び出され、ＵＰＮが、このパッケージに渡され、トークンが返される。ＷｅｂＳＳＯ認証パッケージは、ＡｕｔｈＺ ＡＰＩを使用して、ＵＰＮで渡されたＳＩＤを得、次に、これらのＳＩＤに基づいてトークンを作る。
【００９２】
ＬｓａＬｏｇｏｎＵｓｅｒを呼び出すときに使用される構造体は、次の通りである。
【００９３】
【表５】
【００９４】
この場合にはサービスであるクライアント・アプリケーションは、パッケージ名（「ＷｅｂＳｓｏＡｐ」）を用いてＬｓａＬｏｏｋｕｐＡｕｔｈｅｎｔｉｃａｔｉｏｎＰａｃｋａｇｅを呼び出し、次に、ＬｓａＬｏｇｏｎＵｓｅｒを呼び出し、ＡｕｔｈＩｎｆｏＢｕｆｆｅｒパラメータで書き込まれた＿ＷＥＢＳＳＯ＿ＬＯＧＯＮ構造体を供給する。
【００９５】
認証パッケージは、ＡｚＭａｎから取り出した、クライアントＵＰＮに対するインデックスであるトークン情報のＡＶＬツリー・ベース・キャッシュを維持する。
【００９６】
コンピューティング環境
図９に、本明細書に記載のウェブＳＳＯを実装できる例示的なコンピューティング環境９００を示す。例示的なコンピューティング環境９００は、コンピューティング・システムの１例にすぎず、本明細書に記載の例をこの特定のコンピューティング環境に制限することは意図されていない。
【００９７】
たとえば、コンピューティング環境９００は、多数の他の汎用または特殊目的のコンピューティング・システム構成を用いて実施することができる。周知のコンピューティング・システムの例に、パーソナル・コンピュータ、ハンドヘルド・デバイスまたはラップトップ・デバイス、マイクロ・プロセッサ・ベースのシステム、マルチ・プロセッサ・システム、セットトップボックス、ゲーム機、コンシューマ・エレクトロニクス、セル電話機、ＰＤＡ、および類似物を含めることができるが、これらに制限はされない。
【００９８】
コンピュータ９００に、コンピューティング・デバイス９０１の形の汎用コンピューティング・システムが含まれる。コンピューティング・デバイス９０１のコンポーネントに、１つまたは複数のプロセッサ（ＣＰＵ、ＧＰＵ、マイクロ・プロセッサ、および類似物を含む）９０７、システム・メモリ９０９、およびさまざまなシステム・コンポーネントを結合するシステム・バス９０８が含まれる。プロセッサ９０７は、コンピューティング・デバイス９０１の動作を制御するものおよび他の電子デバイスおよびコンピューティング・デバイス（図示せず）と通信するものなど、さまざまなコンピュータ実行可能命令を処理する。システム・バス９０８は、メモリ・バスまたはメモリ・コントローラ、周辺バス、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ、およびさまざまなバス・アーキテクチャのいずれかを使用するプロセッサ・バスまたはローカル・バスを含む、任意の個数の複数のタイプのバス構造を表す。
【００９９】
システム・メモリ９０９に、ランダム・アクセス・メモリ（ＲＡＭ）などの揮発性メモリおよび／または読取専用メモリ（ＲＯＭ）などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。基本入出力システム（ＢＩＯＳ）が、ＲＯＭに格納されている。ＲＡＭには、通常、１つまたは複数のプロセッサ９０７がダイレクトにアクセス可能および／またはこれによって現在操作されているデータおよび／またはプログラム・モジュールが含まれる。
【０１００】
マス・ストレージ・デバイス９０４を、コンピューティング・デバイス９０１に結合するか、バスに結合することによってコンピューティング・デバイスに組み込むことができる。そのようなマス・ストレージ・デバイス９０４に、リムーバブル不揮発性磁気ディスク（たとえば、「フロッピー（登録商標）・ディスク」）９０５から読み取り、これに書き込む磁気ディスク・ドライブ、またはＣＤ ＲＯＭもしくは類似物などのリムーバブル不揮発性光ディスク９０６から読み取り、かつ／またはこれに書き込む光ディスク・ドライブを含めることができる。コンピュータ可読媒体９０５および９０６は、通常、フロッピー（登録商標）・ディスク、ＣＤ、ポータブル・メモリ・スティック、および類似物で供給されるコンピュータ可読命令、データ構造、プログラム・モジュール、および類似物を、示す。
【０１０１】
たとえば、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データを含む、任意の個数のプログラム・モジュールを、ハードディスク９１０、マス・ストレージ・デバイス９０４、ＲＯＭおよび／またはＲＡＭ９０９に格納することができる。そのようなオペレーティング・システム、アプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データのそれぞれ（またはこれらのある組合せ）に、本明細書に記載のシステムおよび方法の実施形態を含めることができる。
【０１０２】
ディスプレイ・デバイス９０２を、ビデオ・アダプタ９１１などのインターフェースを介してシステム・バス９０８に接続することができる。ユーザは、キーボード、ポインティング・デバイス、ジョイスティック、ゲームパッド、シリアル・ポート、および／または類似物などの任意の個数の異なる入力デバイス９０３を介してコンピューティング・デバイス９０１とインターフェースすることができる。上記および他の入力デバイスは、システム・バス９０８に結合された入出力インターフェース９１２を介してプロセッサ９０７に接続されるが、パラレル・ポート、ゲーム・ポート、および／またはＵＳＢ（universal serial bus）などの他のインターフェースおよびバス構造によって接続することができる。
【０１０３】
コンピューティング・デバイス９００は、１つまたは複数のローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、および類似物を介する１つまたは複数のリモート・コンピュータへの接続を使用してネットワーク化された環境で動作することができる。コンピューティング・デバイス９０１は、ネットワーク・アダプタ９１３を介して、あるいはその代わりにモデム、ＤＳＬ、ＩＳＤＮインターフェース、または類似物によって、ネットワーク９１４に接続される。
【０１０４】
当業者は、プログラム命令の格納に使用されるストレージ・デバイスを、ネットワーク上で分散できることを諒解するであろう。たとえば、リモート・コンピュータに、ソフトウェアとして、説明された処理の例を格納することができる。ローカル・コンピュータまたは端末コンピュータは、リモート・コンピュータにアクセスし、ソフトウェアの一部またはすべてをダウンロードして、プログラムを実行することができる。その代わりに、ローカル・コンピュータが、必要に応じてソフトウェアの一部をダウンロードするか、ローカル端末でソフトウェア命令の一部を、リモート・コンピュータ（またはコンピュータ・ネットワーク）でソフトウェア命令の一部を実行することによって分散式に処理することができる。当業者は、当業者に既知の従来の技法を使用することによって、ソフトウェア命令のすべてまたは一部を、ＤＳＰ、プログラマブル・ロジック・アレイ、または類似物などの専用回路によって実行できることも理解するであろう。
【図面の簡単な説明】
【０１０５】
【図１】コンピュータ・オペレーティング・システムの一部としてのウェブ・シングル・サイン・オンを示す図である。
【図２】ウェブＳＳＯを実施するさまざまなネットワークの例を示す図である。
【図３】ウェブＳＳＯ中にセキュリティを維持するのに使用されるシステム・コンポーネントを示すブロック図である。
【図４】エクストラネット・アクセスに関する全体的な処理フローを示すブロック図である。
【図５】エクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。
【図６】エクストラネット・リソースにアクセスするのにトークンを使用する方法を示す流れ図である。
【図７】エクストラネット・リソースに対するフェデレーテッド・パートナーに関する全体的な処理フローを示す流れ図である。
【図８】フェデレーション・パートナーによるアクセスを可能にするＮＴアクセス・トークンの生成を可能にするためにクレイムをマッピングする３つの異なる形を示す流れ図である。
【図９】本明細書に記載のウェブＳＳＯおよびフェデレーテッド・パートナーによるネットワーク・アクセスを実装できる例示的なコンピューティング環境を示す図である。
【符号の説明】
【０１０６】
１０１ ラップトップ
１０２ ＰＣ
１０３ ウェブ・サーバ
１０４ オペレーティング・システム
１０５ オペレーティング・システムのネットワーキング部分
１０６ シングル・サイン・オン（ＳＳＯ）
１０７ ウェブ・シングル・サイン・オン（ウェブＳＳＯ）
１０８ フェデレーテッド・リソース・サイン・オン
２０１ イントラネット
２０２ ＤＭＺ
２０３ イントラネット
２０４ パートナアー・カウント・ストア
２０５ 消費者アカウント・ストア
２０６ ウェブ・サイト・エクストラネット・アカウント・ストア
２０７ ウェブ・サイト従業員アカウント・ストア
２０８ ＳＳＯを用いるパートナー・ウェブ・クライアント
２０９ ＳＳＯを用いる消費者ウェブ・クライアント
２１０ ＳＳＯを用いる消費者またはパートナーのウェブ・クライアント
２１１ ＳＳＯを用いる従業員ウェブ・クライアント
２１２ ウェブ・サイト
２１３ ファイヤウォール
２１４ フェデレーテッドＢ２Ｂ
２１５ フェデレーテッドＢ２Ｃ
２１６ エクストラネット
２１７ Ｂ２Ｅ
２１８ インターネット
３０１ アクティブ・ディレクトリのセキュリティ・トークン・サービス・プロキシ
３０２ ウェブ・サイト信頼を管理するフェデレーション・サービス
３０３ ウェブ・アプリケーションのＳＳＯエージェント・プロセス・セキュリティ・ト
３０４ パッシブ・クライアント・プロトコル
３０５ アクティブ・ディレクトリ
３０６ アカウント・ストア
３０８ ＦＳＡ
３０９ ＦＳＲ
３１０ ＦＳＲ’
３１１ ウェブＳＳＯを用いるウェブ・クライアント
３１２ ウェブ・サイト・アプリケーション
３１３ イントラネット
３１４ ＤＭＺ
３１５ インターネット
３１６ イントラネット
３２０ ＷＳ
３２１ ＦＳＰ−Ａ
４０１ イントラネット
４０２ ＤＭＺ
４０３ インターネット
４０４ コープネットＡＤ
４０５ Ｗｉｎｄｏｗｓ（登録商標）信頼
４０６ エクストラネットＡＤ
４０７ コープネット・リソース領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ａ／ＦＳ−Ａ
４０８ フェデレーション信頼
４０９ エクストラネット・アカウント領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ｒ／ＦＳ−Ｒ
４１０ コープネット上のクライアント
４１１ インターネット上のクライアント
４１２ ＬＳ−Ａ−ＥＸＴ
４１３ ＷＳ
７０１ リソースＤＭＺ
７０２ インターネット
７０３ アカウント・コープネット
７０４ リソースＦＳ
７０５ Ｗｉｎｄｏｗｓ（登録商標）信頼
７０６ アカウントＦＳ
７０７ コープネット・アカウント領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ｒ／ＦＳ−Ｒ
７０８ フェデレーション信頼
７０９ エクストラネット・リソース領域内のログイン・サーバ／フェデレーション・サーバ ＬＳ−Ａ／ＦＳ−Ａ
７１０ ＷＳ
７１１ インターネット上のクライアント
７１２ コープネット上のクライアント
９００ コンピュータ環境
９０１ コンピューティング・デバイス
９０２ ディスプレイ
９０３ 入出力デバイス
９０４ 周辺ドライブ
９０５ フロッピー（登録商標）・ディスク
９０６ 光ディスク
９０７ 処理ユニット
９０８ システム・バス
９０９ システム・メモリ
９１０ ハードディスク
９１１ ビデオ・アダプタ
９１２ 入出力インターフェース
９１３ ネットワーク・アダプタ
【特許請求の範囲】
【請求項１】
フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、
イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、および
インターネット接続を介して前記ウェブ・サーバに結合された、前記ウェブ・サーバにサイン・オンすることができる、前記フェデレーテッド・パートナーに配置されたクライアント
を備えることを特徴とするコンピュータ・ユーザを認証するシステム。
【請求項１】
フェデレーテッド・パートナーに配置された単一のアクティブ・ディレクトリ、
イントラネットに関連付けられたＤＭＺに配置されたウェブ・サーバ、および
インターネット接続を介して前記ウェブ・サーバに結合された、前記ウェブ・サーバにサイン・オンすることができる、前記フェデレーテッド・パートナーに配置されたクライアント
を備えることを特徴とするコンピュータ・ユーザを認証するシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００６−１６４２４７（Ｐ２００６−１６４２４７Ａ）
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願番号】特願２００５−３１９５９６（Ｐ２００５−３１９５９６）
【出願日】平成１７年１１月２日（２００５．１１．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年６月２２日（２００６．６．２２）
【国際特許分類】
【出願日】平成１７年１１月２日（２００５．１１．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]