JP4370258B2 - ユーザ・セッションを管理するための方法、データ処理システム、およびコンピュータ・プログラム（異機種連携環境における統合サインオフのための方法およびシステム） - Google Patents

Description

本発明は、改良されたデータ処理システムに関し、特に、マルチコンピュータ・データ転送のための方法および装置に関する。より詳細には、本発明は、ネットワーク・コンピュータ・システムを対象とする。

関連出願の相互参照
本出願は、本願譲受人による以下の出願に関連するものである。
出願日未定で、「Efficient browser-based identity management providing personalcontrol and anonymity」という発明の名称の米国特許出願（代理人整理番号ＣＨ９２００２０００６）
２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Proof-of-Possession Operations Associated withAuthentication Assertions in a Heterogeneous Federated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１０ＵＳ１）
２００２年ｘｘ月ｘｘ日に出願され、「Local Architecture for Federated Heterogeneous System」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１１ＵＳ１）
２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Attribute Exchange in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１２ＵＳ１）
２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Authentication in a Heterogeneous FederatedEnvironment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１３ＵＳ１）
２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Native Authentication Protocols in aHeterogeneous Federated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４８６ＵＳ１）

企業は一般に、インターネットを含む様々なネットワーク全体にわたってユーザ・フレンドリに保護リソースへのセキュア・アクセスを許可ユーザに提供することを所望する。セキュア認証メカニズムを提供することは保護リソースへの無許可アクセスのリスクを低減するが、同じ認証メカニズムが保護リソースとのユーザ対話にとってバリアになる場合もある。ユーザは一般に、これらのアプリケーションをサポートする特定の各システムを保護する認証バリアを度外視して、あるアプリケーションとの対話から他のアプリケーションにジャンプする能力を所望する。

ユーザはより洗練されているので、ユーザの負担が削減されるようにコンピュータ・システムがそのアクションを調整することを期待する。このようなタイプの期待は認証プロセスにも適用される。ユーザが何らかのコンピュータ・システムによって認証されると、その認証は、そのユーザにとってほとんど見えない様々なコンピュータ・アーキテクチャ境界を度外視して、そのユーザの作業セッション全体にわたってまたは少なくとも特定の期間の間、有効でなければならないと、ユーザが想定する可能性がある。企業は一般に、ユーザをなだめるためだけでなく、ユーザ効率が従業員の生産性に関連するか顧客満足度に関連するかにかかわらず、ユーザ効率を高めるためにも、その配置システムの動作特性においてこのような期待を達成しようとする。

より具体的には、共通ブラウザによりアクセス可能なＷｅｂベース・ユーザ・インターフェースを多くのアプリケーションが有する現行コンピューティング環境により、ユーザは、ユーザ・フレンドリ度がより高いことと、あるＷｅｂベース・アプリケーションから他のＷｅｂベース・アプリケーションへの移動に対するバリアが低いかまたは少ないことを期待する。これに関連して、ユーザは、特定の各ドメインを保護する認証バリアを度外視して、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションにジャンプする能力を期待するようになる。しかし、多くのシステムが使いやすいＷｅｂベース・インターフェースによりセキュア認証を提供する場合でも、ユーザは依然として、１組のドメインの全域でユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れざるを得ない可能性がある。所与の時間フレーム内にユーザを複数の認証プロセスにかけることは、ユーザの効率に著しく影響する可能性がある。

ユーザおよびコンピュータ・システム管理者の認証負担を低減するために、様々な技法が使用されてきた。これらの技法は、ユーザがサインオン操作を完了した後、すなわち、認証された後に、そのユーザはその後、他の認証操作を実行する必要がないという共通目的があるので、一般に「シングル・サインオン」（ＳＳＯ：single-sign-on）プロセスと記述される。このため、目標は、ユーザが特定のユーザ・セッション中に１つの認証プロセスのみ完了することを要求されるであろうということである。

このようなシングル・サインオン・ソリューションは、所与の企業内で実現したときは上首尾であった。しかし、より多くの企業がインターネットによって接続されたｅ−ｃｏｍｍｅｒｃｅマーケットプレイスまたはその他のコラボレーション努力に参加するにつれて、複数の認証プロセスまたはシステムによって提起されるバリアはますます一般的なものになっている。企業間の以前のシングル・サインオン・ソリューションは、参加企業間の事業協定が事前に確立されている同種環境に限られていた。これらの事業協定は、部分的に、信頼を確立し、企業間で情報を安全に転送する方法を制限し定義するために使用される。また、これらの事業協定は、ある企業から他の企業にユーザＩＤ（identity）を変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。

換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合は可能である。参加企業はこれらの以前のシングル・サインオン・ソリューションを使用することにより同種環境内で協働することができるが、複数の同種環境、たとえば、相互接続ｅ−ｃｏｍｍｅｒｃｅマーケットプレイスを相互接続する必要性または要望を考慮すると、これらの環境は限定的なものである。

加えて、ユーザがシステムに対して自分のＩＤを証明するために認証操作を完了するという要件は、システムを保護することの一部にすぎない。このプロセスの同様に重要な部分は、セキュア・セッションを終了するためにユーザがログオフ操作を完了するという要件であり、それにより、他のユーザが有効なセッションを流用するかまたは悪意をもって有効なセッションに干渉するのを防止する。
出願日未定（filed (TBD)）で、「Efficientbrowser-based identity management providing personal control and anonymity」という発明の名称の米国特許出願（代理人整理番号ＣＨ９２００２０００６） ２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Proof-of-Possession Operations Associated withAuthentication Assertions in a Heterogeneous Federated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１０ＵＳ１） ２００２年ｘｘ月ｘｘ日に出願され、「Local Architecture for Federated Heterogeneous System」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１１ＵＳ１） ２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Attribute Exchange in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１２ＵＳ１） ２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Authentication in a Heterogeneous FederatedEnvironment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４１３ＵＳ１） ２００２年ｘｘ月ｘｘ日に出願され、「Method and System for Native Authentication Protocols in aHeterogeneous Federated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４８６ＵＳ１） １９９３年９月発行のInternet Engineering Task Force (IETF) Request for Comments (RFC)1510に掲載されたＫｏｈｌ他による「TheKerberos Network Authentication Service (V5)」 ２００２年５月３１日発行のCommittee Specification 01に掲載された「Assertions and Protocol for the OASIS Security Assertion MarkupLanguage (SAML)」

したがって、参加企業間の所定の事業および技術変換協定がない場合に企業がユーザに対して同様のシングル・サインオンおよび同様のシングル・サインオフ（single-sign-off）経験を提供できる方法およびシステムを備えることは有利なことになるであろう。

連携（federated）ドメインが連携環境内で対話する方法、装置、システム、およびコンピュータ・プログラムが提示される。あるフェデレーション（federation）内のドメインは、他の連携ドメインのユーザに関する連携シングル・サインオン操作を開始することができる。あるドメイン内の窓口（point-of-contact）サーバは、そのドメインとフェデレーションとの間の信頼関係を管理するためにそのドメイン内のトラスト・プロキシ（trust proxy）を当てにする。トラスト・プロキシは、必要に応じて他の連携ドメインからのアサーションを解釈する。トラスト・プロキシは１つまたは複数のトラスト・ブローカ（trust broker）との信頼関係を有することができ、トラスト・プロキシはアサーションを解釈する際の支援のためにトラスト・ブローカを当てにすることができる。他の連携ドメインにおいてユーザのために連携シングル・サインオン操作を開始したドメインからログオフすることをそのユーザが要求すると、そのドメインは、それらの他の連携ドメインにおいてログオフ操作を要求することにより、統合ログオフ操作を開始し、これは、連携シングル・サインオン操作を開始したドメインに対してカスケード方式でログオフ操作を開始することもできる。また、あるドメインが特定の用途のためにログオフ・イベントに加入できる、パブリッシュ・サブスクライブ・モデル（publish-and-subscribe model）もサポートされる。

本発明に特有と思われる新規の特徴は特許請求の範囲に示されている。本発明そのもの、その他の目的、およびその利点は、添付図面に併せて読んだときに以下に示す詳細な説明を参照することにより最も良く理解されるであろう。

一般に、本発明を含むかまたは本発明に関する可能性のある装置は多様なデータ処理技術を含む。したがって、本発明をより詳細に説明する前に、背景として、分散データ処理システム内のハードウェアおよびソフトウェア・コンポーネントの典型的な編成について説明する。

次に添付図面を参照すると、図１は、そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを描写している。分散データ処理システム１００はネットワーク１０１を含み、そのネットワークは、分散データ処理システム１００内で一緒に接続された様々な装置およびコンピュータ間の通信リンクを提供するために使用できるメディアである。ネットワーク１０１は、ワイヤもしくは光ファイバ・ケーブルなどの永続接続または電話もしくはワイヤレス通信により行われる一時接続を含むことができる。描写した例では、サーバ１０２およびサーバ１０３は、ストレージ・ユニット１０４とともにネットワーク１０１に接続されている。加えて、クライアント１０５〜１０７もネットワーク１０１に接続されている。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ：personal digital assistant）などの多様なコンピューティング・デバイスによって表すことができる。分散データ処理システム１００は、図示されていない追加のサーバ、クライアント、ルータ、その他の装置、およびピアツーピア・アーキテクチャを含むことができる。

描写した例では、分散データ処理システム１００は、ＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル（Transport Control Protocol/Internet Protocol））、ＨＴＴＰ（ハイパーテキスト転送プロトコル（HyperText Transport Protocol））などの様々なプロトコルを使用して互いに通信するネットワークおよびゲートウェイの世界的な集合を表すネットワーク１０１とともにインターネットを含むことができる。当然のことながら、分散データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）、または広域ネットワーク（ＷＡＮ：wide area network）などのいくつかの異なるタイプのネットワークも含むことができる。たとえば、サーバ１０２はクライアント１０９およびネットワーク１１０を直接サポートし、そのネットワークはワイヤレス通信リンクを組み込んでいる。ネットワーク対応電話（network-enabled phone）１１１はワイヤレス・リンク１１２によりネットワーク１１０に接続し、ＰＤＡ１１３はワイヤレス・リンク１１４によりネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワーク（personal ad-hoc network）を作成するために、Ｂｌｕｅｔｏｏｔｈ（商標）ワイヤレス技術などの適切な技術を使用して、ワイヤレス・リンク１１５を越えて両者間でデータを直接転送することもできる。同様に、ＰＤＡ１１３は、ワイヤレス通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。

本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実現することができるであろう。図１は、本発明に関するアーキテクチャ制限としてのものではなく、異機種コンピューティング環境の一例としてのものである。

次に図２を参照すると、同図は、本発明を実現可能な、図１に示したものなどのデータ処理システムの典型的なコンピュータ・アーキテクチャを描写している。データ処理システム１２０は、内部システム・バス１２３に接続された１つまたは複数の中央演算処理装置（ＣＰＵ：central processing unit）１２２を含み、その内部システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）１２４、読取り専用メモリ１２６、および入出力アダプタ１２８を相互接続し、その入出力アダプタ１２８は、プリンタ１３０、ディスク・ユニット１３２、またはオーディオ出力システムなどの図示していないその他の装置などの様々な入出力装置をサポートする。また、システム・バス１２３は、通信リンク１３６へのアクセスを可能にする通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０とマウス１４２、またはタッチ・スクリーン、スタイラス、マイクロホンなどの図示していないその他の装置などの様々なユーザ装置を接続する。ディスプレイ・アダプタ１４４はシステム・バス１２３をディスプレイ装置１４６に接続する。

当業者であれば、図２のハードウェアはシステム実現例に応じて様々になる可能性があることが分かるであろう。たとえば、システムは、Ｉｎｔｅｌ（商標）のＰｅｎｔｉｕｍ（商標）ベースのプロセッサおよびデジタル・シグナル・プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性および不揮発性メモリとを有する可能性がある。図２に描写したハードウェアに加えてまたはその代わりに、その他の周辺装置を使用することもできる。描写した例は、本発明に関するアーキテクチャ制限を示すためのものではない。

様々なハードウェア・プラットフォームで実現できることに加えて、本発明は、様々なソフトウェア環境で実現することができる。各データ処理システム内のプログラム実行を制御するために、典型的なオペレーティング・システムを使用することができる。たとえば、ある装置はＵｎｉｘ（商標）オペレーティング・システムを実行することができ、他の装置は単純なＪａｖａ（商標）ランタイム環境を含む。代表的なコンピュータ・プラットフォームはブラウザを含むことができ、そのブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ：Extensible Markup Language）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：Hypertext Markup Language）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ：Handheld Device Markup Language）、ワイヤレス・マークアップ言語（ＷＭＬ：Wireless Markup Language）、および様々なその他のフォーマットおよびタイプのファイルなど、様々なフォーマットのハイパーテキスト・ドキュメントにアクセスするための周知のソフトウェア・アプリケーションである。また、図１に示した分散データ処理システムは、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されていることにも留意されたい。

次に図３を参照すると、データ・フロー・ダイアグラムは、クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示している。図示した通り、クライアント・ワークステーション１５０側のユーザは、クライアント・ワークステーション上で実行されるユーザのＷｅｂブラウザにより、コンピュータ・ネットワークを越えてサーバ１５１上の保護リソースにアクセスしようとする。保護リソースは、認証許可ユーザのみによってアクセス可能なユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）、またはより一般的には、ユニフォーム・リソース・アイデンティファイア（ＵＲＬ：Uniform Resource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示した通り、インターネット、イントラネット、またはその他のネットワークにすることができ、サーバは、Ｗｅｂアプリケーション・サーバ（ＷＡＳ：Web Application Server）、サーバ・アプリケーション、サーブレット・プロセスなどにすることができる。

プロセスは、ユーザが「ｉｂｍ．ｃｏｍ」というドメイン内のＷｅｂページなどの保護リソースを要求したときに開始される（ステップ１５２）。Ｗｅｂブラウザ（または関連アプリケーションもしくはアプレット）は、「ｉｂｍ．ｃｏｍ」というドメインをホストとして処理するＷｅｂサーバに送信されるＨＴＴＰ要求メッセージを生成する（ステップ１５３）。サーバは、それがクライアントに関するアクティブ・セッションを持っていないと判断し（ステップ１５４）、したがって、サーバは、何らかのタイプの認証質問（authentication challenge）をクライアントに送信することにより（ステップ１５５）、認証プロセスを実行するようユーザに要求する。認証質問は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）形式などの様々なフォーマットにすることができる。次にユーザは、ユーザＩＤおよび関連パスワードなどの要求された情報または必要な情報を提供する（ステップ１５６）か、またはクライアントは特定の情報を自動的に返す場合もある。

認証応答情報はサーバに送信され（ステップ１５７）、その時点でサーバは、たとえば、前にサブミットされた登録情報を検索し、提示された認証情報とユーザの保管情報とを突き合わせることにより、ユーザまたはクライアントを認証する（ステップ１５８）。認証が成功したと想定して、認証ユーザまたはクライアントに関するアクティブ・セッションが確立される。

次にサーバは、要求されたＷｅｂページを検索し、ＨＴＴＰ応答メッセージをクライアントに送信する（ステップ１５９）。その時点でユーザは、ハイパーテキスト・リンクをクリックすることによりブラウザ内で「ｉｂｍ．ｃｏｍ」内の他のページを要求することができ（ステップ１６０）、ブラウザは他のＨＴＴＰ要求をサーバに送信する（ステップ１６１）。その時点でサーバは、ユーザがアクティブ・セッションを持っていることを認識し（ステップ１６２）、サーバは他のＨＴＴＰ応答メッセージで要求されたＷｅｂページをクライアントに返送する（ステップ１６３）。図３は典型的な従来技術のプロセスを描写しているが、アクティブ・セッションを備えたユーザを識別するためにＣｏｏｋｉｅを使用することなど、他の代替セッション状態管理技法を描写することもでき、認証を証明するために使用されるのと同じＣｏｏｋｉｅを使用することを含む可能性もあることに留意されたい。

次に図４を参照すると、ネットワーク・ダイアグラムは、本発明を実現可能な典型的なＷｅｂベース環境を示している。この環境では、クライアント１７１側のブラウザ１７０のユーザは、ＤＮＳドメイン１７３内のＷｅｂアプリケーション・サーバ１７２上またはＤＮＳドメイン１７５内のＷｅｂアプリケーション・サーバ１７４上の保護リソースにアクセスすることを所望する。

図３に示したものと同様に、ユーザは多くのドメインのうちの１つで保護リソースを要求することができる。特定のドメインにおいて単一サーバのみを示す図３とは対照的に、図４の各ドメインは複数のサーバを有する。特に、各ドメインは関連認証サーバ１７６および１７７を有することができる。

この例では、クライアント１７１がドメイン１７３で保護リソースに関する要求を発行した後、Ｗｅｂアプリケーション・サーバ１７２は、それがクライアント１７１に関するアクティブ・セッションを持っていないと判断し、認証サーバ１７６がクライアント１７１との適切な認証操作を実行することを要求する。認証サーバ１７６は、認証操作の結果をＷｅｂアプリケーション・サーバ１７２に伝達する。ユーザ（またはユーザに代わってブラウザ１７０またはクライアント１７１）が正常に認証された場合、Ｗｅｂアプリケーション・サーバ１７２は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。概して、ユーザが認証サーバによって認証されると、Ｃｏｏｋｉｅを設定し、それをブラウザ内のＣｏｏｋｉｅキャッシュに保管することができる。図４は単に、特に認証操作を実行するために、あるドメインの処理リソースを複数サーバ間で共用できる方法の一例に過ぎない。

同様に、クライアント１７１がドメイン１７５で保護リソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証操作を実行し、その後、Ｗｅｂアプリケーション・サーバ１７４は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。

このため、図４は、クライアント１７１が異なるドメインにおける複数の並行セッションを持つことができるが、それらの並行セッションを確立するために複数の認証操作を完了する必要があることを示している。

次に図５を参照すると、ブロック図は、ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を描写している。もう一度、図３および図４を参照すると、ユーザは、図３に示した通り、被制御リソースにアクセスする前に認証操作を完了する必要がある可能性がある。図３に示していないが、ユーザを認証するために必要なユーザ情報を検索し使用するために、サーバ１５１上に認証マネージャを配置することができる。図４に示した通り、ユーザは異なるドメイン１７３および１７５内で複数の現行セッションを持っている可能性があり、それらは図４に示されていないが、各ドメインは、認証サーバの代わりにまたはそれに加えて認証マネージャを使用することができる。同様に、図５は１組のドメインも描写しており、そのそれぞれは何らかのタイプの認証マネージャをサポートする。図５は、各ドメインに関する認証操作を完了することをユーザに要求する複数のドメインにアクセスするときにユーザが経験する可能性のある障害のいくつかを示している。

ユーザ１９０はＩＳＰドメイン１９１で登録することができ、そのドメイン１９１は、ドメイン１９１に関するトランザクションを完了するためにユーザ１９０を認証する認証マネージャ１９２をサポートすることができる。ＩＳＰドメイン１９１は、インターネット接続サービス、Ｅメール・サービス、およびおそらくその他のｅ−ｃｏｍｍｅｒｃｅサービスを提供するインターネット・サービス・プロバイダ（ＩＳＰ：Internet Service Provider）にすることができる。代わって、ＩＳＰドメイン１９１は、ユーザ１９０によって頻繁にアクセスされるインターネット・ポータルにすることもできる。

同様に、ドメイン１９３、１９５、および１９７は、典型的なＷｅｂサービス・プロバイダを表している。行政ドメイン１９３は、様々な行政関連トランザクションを完了するためにユーザを認証する認証マネージャ１９４をサポートする。銀行用ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する認証マネージャ１９６をサポートする。ｅ−ｃｏｍｍｅｒｃｅドメイン１９７は、オンライン購入を完了するためにユーザを認証する認証マネージャ１９８をサポートする。

上記の通り、異なるドメインでリソースにアクセスすることにより、ユーザがインターネットまたはワールド・ワイド・ウェブ内のあるドメインから他のドメインに移動しようと試みる場合、ユーザは、複数のユーザ認証要求または要件にかけられる可能性があり、それは１組のドメインの全域でユーザの進行を著しく遅らせる可能性がある。例示的な環境として図５を使用すると、ユーザ１９０は、少なくとも１８歳であり、有効な運転免許証、有効なクレジット・カード、および米国銀行預金口座を有するユーザに制限されているオンライン・サービスをユーザが購入しようと試みているｅ−ｃｏｍｍｅｒｃｅドメイン１９７との複雑なオンライン・トランザクションに関係する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７を伴う可能性がある。

概して、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内のＩＤを維持していない可能性がある。この例では、ユーザ１９０は、そのユーザのＩＳＰに自分のＩＤを登録している可能性があるが、オンライン・トランザクションを完了するためには、ユーザは、ドメイン１９３、１９５、および１９７に対する認証も受ける必要がある可能性がある。それぞれのドメインがそのユーザに関するＩＤを維持していない場合、そのユーザのオンライン・トランザクションは失敗する可能性がある。ユーザが各ドメインによって認証される場合でも、そのユーザのトランザクションを完了するために異なるドメインがそれらの間で情報を転送できることは保証されていない。図５に示したユーザ１９０の場合、シングル・サインオンのために、ユーザ１９０が第１のＷｅｂサイト、たとえば、ＩＳＰ１９１に対する認証を受け、次にドメイン１９３、１９５、および１９７などの他のＷｅｂサービス・プロバイダに認証トークンを転送できるようにする従来技術の環境はまったく存在しない。

何らかの現行技術に関する前述の簡単な説明を考慮すると、残りの図面の説明は、本発明が機能しうる連携コンピュータ環境に関するものである。しかし、本発明をより詳細に論ずる前に、いくつかの用語について紹介する。

用語
「エンティティ」または「パーティ」という用語は一般に、ある組織、個人、またはシステムに代わって機能する組織、個人、または他のシステムを指す。「ドメイン」という用語はネットワーク環境内の追加の特性を意味するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は区別なく使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（ドメイン・ネーム・システム）ドメイン、またはより一般的に、外部エンティティにとって論理装置として現れる様々なデバイスおよびアプリケーションを含むデータ処理システムも指すことができる。

「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、またはその他の関連情報など、特定の操作に関係する情報の転送に適切なデータ・フォーマットを含むものと理解しなければならない。保護リソースは、それに関するアクセスが制御または制限されるリソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、またはその他の計算リソース、通信タイプのリソースなど）である。

トークンは、正常動作の直接的証拠を提供し、操作を実行するエンティティによって生成され、たとえば、認証トークンは正常認証操作後に生成される。Ｋｅｒｂｅｒｏｓトークンは、本発明で使用可能な認証トークンの一例である。Ｋｅｒｂｅｒｏｓに関する詳細は、１９９３年９月発行のInternet Engineering Task Force (IETF) Request for Comments (RFC)1510に掲載されたＫｏｈｌ他による「TheKerberos Network Authentication Service (V5)」で見つけることができる。

アサーションは、何らかのアクションの間接的証拠を提供する。アサーションは、ＩＤ、認証、属性、許可決定、その他の情報あるいは操作またはその両方の間接的証拠を提供することができる。認証アサーションは、認証サービスではないが、認証サービスを聴取したエンティティによる認証の間接的証拠を提供する。

セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ：Security Assertion Markup Language）アサーションは、本発明内で使用可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利グローバル・コンソーシアムであるＯｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって公布されたものである。ＳＡＭＬは、２００２年５月３１日発行のCommittee Specification 01に掲載された「Assertions and Protocol for the OASIS Security Assertion MarkupLanguage (SAML)」に記載されている。

セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）は、セキュリティ情報を交換するためのＸＭＬベースのフレームワークである。このセキュリティ情報はサブジェクトに関するアサーションの形で表され、サブジェクトは何らかのセキュリティ・ドメイン内のＩＤを有するエンティティ（人またはコンピュータのいずれか）である。サブジェクトの典型的な例は、特定のインターネットＤＮＳドメイン内の自分のＥメール・アドレスによって識別される人である。アサーションは、サブジェクトによって実行される認証行為、サブジェクトの属性、およびサブジェクトが特定のリソースにアクセスできるかどうかに関する許可決定に関する情報を搬送することができる。アサーションは、ＸＭＬ構成体として表され、ネストされた構造を有し、それにより、単一アサーションは認証、許可、および属性に関する数種類の内部ステートメントを含む可能性がある。認証ステートメントを含むアサーションは単に前に発生した認証の行為を記述するに過ぎないことに留意されたい。アサーションは、ＳＡＭＬ機関、すなわち、認証機関、属性機関、およびポリシー決定点（policy decision point）によって発行される。ＳＡＭＬは、それによりクライアントがＳＡＭＬ機関からアサーションを要求し、ＳＡＭＬ機関からの応答を取得できるプロトコルを定義する。このプロトコルは、ＸＭＬベースの要求および応答メッセージ・フォーマットからなり、多種多様な基礎となる通信およびトランスポート・プロトコルにバインドすることができ、現在、ＳＡＭＬはＨＴＴＰによるＳＯＡＰへのバインディングを定義する。ＳＡＭＬ機関は、その応答を作成する際に、外部ポリシー・ストアや、要求において入力として受信したアサーションなどの様々な情報ソースを使用することができる。したがって、クライアントは常にアサーションを消費するが、ＳＡＭＬ機関はアサーションの作成者と消費者のいずれにもなりうる。

ＳＡＭＬ規格では、アサーションは発行者によって作成された１つまたは複数のステートメントを提供する情報のパッケージであることを示している。ＳＡＭＬにより、発行者は、指定のサブジェクトが特定の時期に特定の手段によって認証されたという認証、指定のサブジェクトが指定のリソースにアクセスできるようにするための要求が認可または拒否されたという許可、および指定のサブジェクトが提供された属性に関連付けられる属性という３種類のアサーション・ステートメントを作成することができる。以下に詳述する通り、必要なときに、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することができる。

認証は、ユーザによってまたはユーザに代わって提供される１組の信用証明情報（credential）の妥当性を検査するプロセスである。認証は、ユーザが把握しているもの、ユーザが持っているもの、またはユーザが何者であるか、すなわち、ユーザに関する何らかの物理的特性を検証することによって実施される。ユーザが把握しているものとしては、ユーザのパスワードなど、または特定のユーザにのみ把握されているものを検証することにより、ユーザの暗号鍵などの共有秘密鍵（shared secret）を含むことができる。ユーザが
持っているものとしては、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特性としては、指紋または網膜マップなどのバイオメトリック入力を含むことができるであろう。

認証信用証明情報は、様々な認証プロトコルで使用される１組の質問／応答情報である。たとえば、ユーザ名とパスワードの組合せは、最も普通の形式の認証信用証明情報である。他の形式の認証信用証明情報としては、様々な形式の質問／応答情報、公開鍵インフラストラクチャ（ＰＫＩ：Public Key Infrastructure）証明書、スマートカード、バイオメトリクスなどを含むことができる。認証信用証明情報は認証アサーションとは差異化され、すなわち、認証信用証明情報は認証サーバまたはサービスとの認証プロトコル・シーケンスの一部としてユーザによって提示されるものであり、認証アサーションはユーザの認証信用証明情報の正常な提示および妥当性検査に関するステートメントであって、その後、必要なときにエンティティ間で転送されるものである。

従来技術のシングル・サインオン・ソリューションの区別
上記の通り、従来技術のシングル・サインオン・ソリューションは、参加企業間で事業協定が事前確立されている同種環境に制限されている。これらの事業協定は、信頼を確立し、企業間の安全な情報転送を定義する。また、これらの事業協定は、ある企業から他の企業にユーザＩＤを変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。

換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合は可能である。

本発明のフェデレーション・モデル
ワールド・ワイド・ウェブに関連して、ユーザは、特定の各ドメイン間の情報バリアを最小限に考慮して、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションにジャンプする能力を期待するようになる。ユーザは、単一トランザクションの場合に複数のドメインに対する認証を受けなければならないことによって引き起こされる欲求不満を望まない。換言すれば、ユーザは複数組織が相互運用することを期待するが、ユーザは一般に複数ドメインがユーザのプライバシを尊重することを希望する。加えて、ユーザは、私有情報を永続的に保管するドメインを制限する方を好む可能性がある。このようなユーザの期待は、多くの企業および組織が競合する認証技法を公布している、急速進化中の異機種環境に存在する。

従来技術のシステムとは対照的に、本発明は、特定の企業間の特定の事前確立された事業および技術協定がない場合に企業がユーザに対してシングル・サインオン経験を提供できるようにするためのフェデレーション・モデルを提供する。換言すれば、本発明は、連携異機種環境をサポートする。本発明の目的の一例として、もう一度、図５を参照すると、ユーザ１９０は、ドメイン１９１に対する認証を受け、トランザクションに関係する可能性のある各ダウンストリーム・ドメインに対し適切なアサーションをドメイン１９１から提供してもらうことができる。これらのダウンストリーム・ドメインは、ドメイン１９１と他のダウンストリーム・ドメインとの間に事前確立されたアサーション・フォーマットがまったくない場合でも、認証アサーションあるいはその他のタイプのアサーションまたはその両方を理解し信頼できることが必要である。アサーションを認識することに加えて、ダウンストリーム・ドメインは、事前確立されたＩＤマッピング関係がまったくない場合でも、アサーション内に含まれるＩＤを、特定のドメイン内のユーザ１９０を表すＩＤに変換できることが必要である。

本発明は、連携環境を対象とする。一般に、企業は、独自のユーザ・レジストリを有し、独自のユーザ・セットとの関係を維持する。各企業は概して、これらのユーザを認証する独自の手段を有する。しかし、本発明の連携方式により、複数の企業は、ある企業が企業フェデレーションに参加することによりその企業のユーザが１組の企業との関係を強化できるように、集合的に協働することができる。ユーザは、各企業との直接的関係を有する場合と同様に、連携した企業のうちのいずれかの企業側のリソースへのアクセスが許可される可能性がある。ユーザは、関心のある各事業に登録する必要はなく、自分自身を識別し認証することを絶えず要求されるわけではない。このため、この連携環境内では、認証方式により、情報技術において急速進化中の異機種環境内のシングル・サインオン経験が可能になる。

本発明では、フェデレーションは、シングル・サインオンの使いやすい経験をユーザに提供するために協働する、企業、組織、団体などの１組の別個のエンティティである。本発明では、連携環境は、２つの企業がユーザに関するどの情報をどのように転送するかを定義する直接的で事前確立された関係を有する必要がないという点で、典型的なシングル・サインオン環境とは異なる。連携環境内のエンティティは、ユーザを認証すること、他のエンティティによって提示される認証アサーション、たとえば、認証トークンを受諾すること、ならびに保証対象のユーザ（vouched-for user）のＩＤをローカル・エンティティ内で理解されるものに変換する何らかの形式の変換を提供することを扱うサービスを提供する。

フェデレーションは、サービス・プロバイダの管理負担を緩和する。サービス・プロバイダは、全体としてフェデレーションに関するその信頼関係を当てにすることができ、ユーザの認証ホーム・ドメインによって実施される認証を当てにすることができるので、ユーザ・パスワード情報などの認証情報を管理する必要がない。

また、本発明は、疎結合の認証サービス、ユーザ登録サービス、ユーザ・プロファイル管理サービス、あるいは許可サービスまたはこれらのサービスの組合せがセキュリティ・ドメインの全域でコラボレーションする基礎を確立する連携ＩＤ管理システムにも関係する。連携ＩＤ管理により、まったく異なる複数のセキュリティ・ドメインに常駐するサービスは、これらのまったく異なる複数ドメインにおいて基礎となるセキュリティ・メカニズムおよびオペレーティング・システム・プラットフォームに相違点が存在する可能性がある場合でも、安全に相互運用しコラボレーションすることができる。ユーザがフェデレーションへの参加を確立すると、シングル・サインオン経験が確立される。

ホーム・ドメイン、発行側パーティ（issuing party）、および依存側パーティ（relyingparty）
以下により詳細に説明する通り、本発明は、ユーザにとって重大な利点をもたらすものである。本発明により、ユーザは、以下でユーザのホーム・ドメインまたは認証ホーム・ドメインとも呼ばれる第１のエンティティで認証を受けることができる。この第１のエンティティは、第２のエンティティで使用するためにユーザに関する認証アサーションを発行する発行側パーティとして動作することができる。次にユーザは、第２のエンティティで明示的に再認証を受ける必要なしに、第１のエンティティによって発行された認証アサーションを提示することにより、依存側パーティと呼ばれる第２の別個のエンティティで保護リソースにアクセスすることができる。発行側パーティから依存側パーティに渡される情報はアサーションの形になっており、このアサーションは、種々のタイプの情報をステートメントの形で含むことができる。たとえば、あるアサーションは、あるユーザの認証済みＩＤに関するステートメントである場合もあれば、特定のユーザに関連するユーザ属性情報に関するステートメントである場合もある。

次に図６を参照すると、ブロック図は、第１の連携した企業に対してユーザによって開始され、それに応答して、連携環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関する連携環境の用語を描写している。図６は、所与の連携操作に関するフェデレーション内のエンティティの視点（perspective）に応じて用語が異なる可能性があることを示している。ユーザ２０２は、企業２０４の保護リソースに関する要求によりトランザクションを開始する。ユーザ２０２が企業２０４によってすでに認証されている場合、企業２０４は、この連携セッション用のユーザのホーム・ドメインになる。このトランザクションが企業２０６による何らかのタイプの操作を必要とし、企業２０４が企業２０６にアサーションを転送すると想定すると、企業２０４はその特定の操作に関する発行側ドメインになり、企業２０６はその操作に関する依存側ドメインになる。このトランザクションが他の操作を必要とし、企業２０６が企業２０８にアサーションを転送すると想定すると、企業２０６は要求された操作に関する発行側ドメインになり、企業２０８はその操作に関する依存側ドメインになる。

本発明の連携環境では、ユーザが認証を受けるドメインは、ユーザの（認証）ホーム・ドメインと呼ばれる。ホーム・ドメインは認証信用証明情報を維持する。ホーム・ドメインは、ユーザの雇用主、ユーザのＩＳＰ、またはその他の何らかのサービス・プロバイダである可能性がある。ユーザの認証信用証明情報を生成し妥当性検査する能力を有する企業が複数存在する可能性があるので、ユーザのホーム・ドメインとして動作できる企業が連携環境内に複数存在する可能性があることは起こり得ることである。

認証の視点によると、認証アサーションに関する発行側パーティは通常、ユーザの認証ホーム・ドメインである。ユーザのホーム・ドメインは、そのユーザに関する個人情報またはプロファイル情報を維持する場合もあれば、維持しない場合もある。このため、個人的に識別可能な情報、パーソナライゼーション情報、またはその他のユーザ属性を伴う属性の視点によると、属性アサーションに関する発行側パーティは、そのユーザの認証ホーム・ドメインである場合もあれば、そうではない場合もある。混乱を回避するため、属性ホーム・ドメインおよび認証ホーム・ドメインについて別々の用語を使用することができるが、以下の「ホーム・ドメイン」という用語は、認証ホーム・ドメインを指すものと解釈することができる。

しかし、所与の連携セッションの範囲内では、通常、ユーザのホーム・ドメインとして動作するドメインは１つだけである。ユーザがこのドメインに対して認証を受けると、そのフェデレーション内の他のすべてのドメインまたは企業は、そのセッションの期間中、依存側パーティとして扱われる。

既存の非連携アーキテクチャに及ぼす影響を最小限にしながら、既存のシステムに追加可能な連携インフラストラクチャを本発明が提供することを考慮すると、ユーザのホーム・ドメインにおける認証は、ホーム・ドメインも連携環境に参加可能であることによって変更されることはない。換言すれば、本発明により実現される連携環境にホーム・ドメインを統合できる場合でも、ユーザは、ユーザのホーム・ドメインで認証操作を実行しながら、同じエンドユーザ経験を持たなければならない。しかし、所与の企業のユーザのすべてが必ずしも連携環境に参加するわけではないことに留意されたい。

その上、ユーザ登録、たとえば、ユーザ・アカウントの確立は、ホーム・ドメインも連携環境に参加可能であることによって変更されることはない。ユーザは、連携環境とは無関係の登録プロセスによりドメインでアカウントを確立する。換言すれば、ホーム・ドメインにおけるユーザ・アカウントの確立は、フェデレーションの全域で有効なアカウント情報、たとえば、ＩＤ変換情報の確立を含まない。ユーザを認証できる単一連携ドメインが存在する場合、すなわち、ユーザが登録したフェデレーション内のドメインが１つだけである場合、このドメインは常にユーザのホーム・ドメインとして動作することになり、連携環境全体にわたってユーザの移動を指図することができる。

ユーザが１つの連携環境内で可能なホーム・ドメインを複数持っている場合、ユーザは２つ以上のエントリ・ポイントを介してそのフェデレーションに入ることができる。換言すれば、ユーザは複数のドメインでアカウントを持つことができ、これらのドメインは必ずしも他のドメインまたは他のドメインにおけるユーザのＩＤに関する情報を持っているわけではない。

ユーザが認証を受けるドメインはホーム・ドメインと呼ばれるが、発行側ドメインは、他のドメイン、すなわち、依存側ドメインによる使用のためにアサーションを発行するフェデレーション・エンティティである。発行側ドメインは、通常、ユーザのホーム・ドメインであるが、必ずそうであるわけではない。このため、通常、発行側パーティが、前述の通り、典型的な認証プロトコルによりすでにユーザを認証していることが実情になるであろう。しかし、発行側が前に依存側パーティとして動作しており、それにより、異なる発行側パーティからアサーションを受信したことは起こり得ることである。換言すれば、ユーザが開始したトランザクションは連携環境内の一連の企業によりカスケードすることができるので、受信側パーティは、その後、ダウンストリーム・トランザクションに関する発行側パーティとして動作することができる。一般に、ユーザに代わって認証アサーションを発行する能力を有するドメインは発行側ドメインとして動作することができる。

依存側ドメインは、発行側パーティからアサーションを受信するドメインである。依存側パーティは、ユーザに代わるサード・パーティ、すなわち、発行側ドメインによって発行されるアサーションを受諾し、信頼し、理解することができる。一般に、適切な認証機関を使用して認証アサーションを解釈することは依存側パーティの義務である。加えて、依存側パーティが特定のユーザを認証できる、すなわち、ユーザのホーム・ドメインとして動作できることは起こり得ることであるが、依存側パーティが従来の方法により特定のユーザを認証できない可能性があることも起こり得ることである。このため、依存側パーティは、ユーザによって提示される認証アサーションを当てにするドメインまたは企業であって、ユーザとの対話式セッションの一部としてユーザの認証信用証明情報の入力をユーザに促す代わりに、ユーザにシングル・サインオン経験を提供するドメインまたは企業である。

連携アーキテクチャ――レガシー・システム用の連携フロントエンド
次に図７を参照すると、ブロック図は、本発明の一実施形態により本発明の連携アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を描写している。連携環境は、ユーザに様々なサービスを提供する連携エンティティを含む。ユーザ２１２は、ブラウザ・アプリケーション２１６および他の様々なクライアント・アプリケーション２１８をサポートできるクライアント装置２１４と対話する。ユーザ２１２は、クライアント装置２１４、ブラウザ２１６、またはユーザとその他の装置およびサービスとのインターフェースとして動作する任意の他のソフトウェアとは別個のものである。場合によっては、以下の説明により、クライアント・アプリケーション内で明示的に動作するユーザと、ユーザに代わって動作するクライアント・アプリケーションとを区別することができる。しかし、一般に、リクエスタは、クライアントベースのアプリケーション、ブラウザ、ＳＯＡＰクライアントなど、ユーザに代わって動作するものと想定できる仲介者である。

ブラウザ・アプリケーション２１６は、ＨＴＴＰ通信コンポーネント２２０およびマークアップ言語（ＭＬ）インタープリタ２２２などの多くのモジュールを有する典型的なブラウザにすることができる。また、ブラウザ・アプリケーション２１６は、Ｗｅｂサービス・クライアント２２４あるいはダウンロード可能アプレットまたはその両方などのプラグインもサポートすることができ、そのアプレットは仮想計算機ランタイム環境を必要とする場合もあれば必要としない場合もある。Ｗｅｂサービス・クライアント２２４は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）を使用することができ、これは非集中分散環境における構造化および型付き情報の交換を定義するための軽量プロトコルである。ＳＯＡＰは、メッセージ内に何が含まれているかならびにそれをどのように処理するかを記述するためのフレームワークを定義するエンベロープと、アプリケーション定義のデータ型のインスタンスを表すための１組のエンコード・ルールと、リモート・プロシージャ・コールおよび応答を表すための規則という３つの部分からなるＸＭＬベースのプロトコルである。ユーザ２１２は、ブラウザ・アプリケーション２１６を使用してＷｅｂベース・サービスにアクセスすることができるが、ユーザ２１２は、クライアント装置２１４上の他のＷｅｂサービス・クライアントによりＷｅｂサービスにアクセスすることもできる。以下の図に示した本発明の例のいくつかは、連携環境内のエンティティ間で情報を交換するために、ユーザのブラウザによるＨＴＴＰリダイレクトを使用する。しかし、本発明は、様々な通信プロトコルにより実施することができ、ＨＴＴＰベースの通信に制限されるものではないことに留意されたい。たとえば、連携環境内のエンティティは、必要なときに直接通信することができ、ユーザのブラウザによりメッセージをリダイレクトする必要はない。

本発明は、連携環境に必要なコンポーネントを既存のシステムと統合できるように実現することができる。図７は、既存のシステムへのフロントエンドとしてこれらのコンポーネントを実現するための一実施形態を描写している。連携ドメインにある既存のコンポーネントは、図８に示したものと同様に認証サービス・ランタイム（ＡＳＲ：authentication service runtime）サーバ２３２を含む、レガシー・アプリケーションまたはバックエンド処理コンポーネント２３０と見なすことができる。ＡＳＲサーバ２３２は、そのドメインがアプリケーション・サーバ２３４へのアクセスを制御するときにユーザの認証を担当し、そのアプリケーション・サーバ２３４は保護リソースを生成するか、検索するか、またはその他の方法で処理するものと見なすことができる。このドメインは引き続きレガシー・ユーザ登録アプリケーション２３６を使用して、アプリケーション・サーバ２３４へのアクセスについてユーザを登録することができる。登録済みユーザを認証するために必要な情報は、レガシー・ユーザ・レジストリ２３８に保管される。

連携環境に加入後、そのドメインは、連携コンポーネントの介入なしに機能し続けることができる。換言すれば、そのドメインは、窓口サーバまたはこの窓口サーバ機能を実現するその他のコンポーネントを通過せずに、ユーザが特定のアプリケーション・サーバまたは他の保護リソースに直接アクセスし続けることができるように構成することができ、このようにシステムにアクセスするユーザは、典型的な認証フローおよび典型的なアクセスを経験することになるであろう。しかし、このようにする際に、レガシー・システムに直接アクセスするユーザは、そのドメインの窓口サーバに知られている連携セッションを確立できないであろう。

そのドメインのレガシー機能は、連携フロントエンド処理２４０の使用により連携環境に統合することができ、その連携フロントエンド処理２４０は窓口サーバ２４２とトラスト・プロキシ・サーバ２４４（またはより単純にトラスト・プロキシ２４４）とを含み、そのトラスト・プロキシ・サーバ２４４自体はセキュリティ・トークン・サービス（ＳＴＳ：Security Token Service）２４５を含み、これらのすべてについては図８に関し以下により詳細に説明する。フェデレーション構成アプリケーション２４６により、管理ユーザは、連携フロントエンド・コンポーネントが連携インターフェース・ユニット２４８によりレガシー・バックエンド・コンポーネントとのインターフェースを取れるようにその連携フロントエンド・コンポーネントを構成することができる。

所与の企業におけるレガシーまたは既存の認証サービスは、ユーザ名／パスワードまたはスマートカード・トークンベースの情報など、様々な周知の認証方法またはトークンを使用することができる。しかし、本発明では、窓口サーバの使用により、レガシー認証サービスの機能を連携環境で使用することができる。ユーザは、窓口サーバを通過せずにレガシー認証サーバに直接アクセスし続けることができるが、このようにシステムにアクセスするユーザは典型的な認証フローおよび典型的なアクセスを経験することになり、レガシー認証システムに直接アクセスするユーザは、本発明によりＩＤの証明として連携認証アサーションを生成できないであろう。連携フロントエンドの役割の１つは、窓口サーバで受信した連携認証トークンを、レガシー認証システムによって理解されるフォーマットに変換することである。このため、窓口サーバを介して連携環境にアクセスするユーザは必ずしも、レガシー認証サービスに対する再認証を受ける必要はなくなるであろう。好ましくは、ユーザは、ユーザが認証ダイアログに従事している場合と同様にそれが現れるように、窓口サーバとトラスト・プロキシとの組合せによって、レガシー認証サービスに対して認証されることになるであろう。

連携アーキテクチャ――窓口サーバ、トラスト・プロキシ、およびトラスト・ブローカ
次に図８を参照すると、ブロック図は、本発明の一実現例による連携アーキテクチャを描写している。連携環境は、ユーザに様々なサービスを提供する連携した企業または同様のエンティティを含む。ユーザは、クライアント装置上のアプリケーションにより、企業２５０などの様々なエンティティにあるリソースにアクセスしようと試みることができる。企業２５０の窓口（ＰＯＣ）サーバ２５２など、各連携した企業の窓口サーバは、そのユーザの連携環境へのエントリ・ポイントである。窓口サーバはフェデレーションの要件の多くを処理するので、窓口サーバは既存の非連携アーキテクチャ内の既存のコンポーネント、たとえば、レガシー・システムへの影響を最小限にする。窓口サーバは、セッション管理、プロトコル変換を可能にし、おそらく、認証アサーション変換を開始する。たとえば、窓口サーバは、ＨＴＴＰまたはＨＴＴＰＳメッセージをＳＯＡＰに変換することができ、またその逆も変換することができる。以下により詳細に説明するように、窓口サーバは、トラスト・プロキシを呼び出して認証アサーションを変換するために使用することもでき、たとえば、発行側パーティから受信したＳＡＭＬトークンは受信側パーティによって理解されるＫｅｒｂｅｒｏｓトークンに変換することができる。

企業２５０のトラスト・プロキシ（ＴＰ）２５４などのトラスト・プロキシまたはトラスト・プロキシ・サーバは、フェデレーション内の２つのエンティティ間の信頼関係を確立し維持する。トラスト・プロキシは一般に、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換（そのように構成されている場合、セキュリティ・トークン・サービスによる、セキュリティ・トークン・サービスについては以下に詳述する）を処理する能力を有する。

全体的に、窓口サーバとトラスト・プロキシの使用は、連携アーキテクチャの実現が既存の非連携システム・セットに及ぼす影響を最小限にする。このため、本発明の連携アーキテクチャは、そのエンティティが企業であるか、ドメインであるか、その他の論理エンティティまたは物理エンティティであるかにかかわらず、連携エンティティ当たり少なくとも１つの窓口サーバと少なくとも１つのトラスト・プロキシの実現を必要とする。しかし、本発明の連携アーキテクチャは必ずしも、既存の非連携システム・セットに対する変更を必要としない。好ましくは、所与の連携エンティティについて単一のトラスト・プロキシが存在するが、可用性のために複数のトラスト・プロキシが存在する可能性もあり、あるいは連携エンティティ内のより小さい様々なエンティティ、たとえば、企業内の個別の子会社のために、複数のトラスト・プロキシが存在する可能性もある。単一トラスト・プロキシは複数のフェデレーション内の信頼関係を管理することができるので、このシナリオは必ずしも複数のトラスト・プロキシを必要としないであろうが、所与のエンティティが２つ以上のフェデレーションに属すことができることは起こり得ることである。

トラスト・プロキシの役割の１つは、他のドメインあるいはそのドメイン内のトラスト・プロキシまたはその両方によって必要なトークン・タイプを決定することである。トラスト・プロキシは、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換を処理する能力を有する。また、トラスト・プロキシ２５４は、企業２５０に関して行われる任意のユーザＩＤ変換または属性変換も担当する。しかし、トラスト・プロキシは、以下に詳述する通り、支援のためにトラスト・ブローカを呼び出すことができる。ＩＤ変換は、発行側パーティに知られているユーザＩＤおよび属性を受信側パーティにとって意味のあるものにマッピングする必要がある場合がある。この変換は、発行側ドメインのトラスト・プロキシまたは受信側ドメインのトラスト・プロキシのいずれかによって呼び出すことができる。

トラスト・プロキシ２５４は、セキュリティ・トークン・サービス（ＳＴＳ）コンポーネント２５５として示される内部化コンポーネント（internalized component）を含むことができ、そのコンポーネントはトークン変換を可能にし、認証サービス・ランタイム（ＡＳＲ）２５６を呼び出してトークンを妥当性検査し生成することになる。セキュリティ・トークン・サービスは、トラスト・プロキシが必要とするトークン発行および妥当性検査サービスを提供する。したがって、セキュリティ・トークン・サービスは、既存の認証サービス・ランタイムへのインターフェースを含むか、またはそのサージス自体に認証サービス・ランタイムを組み込む。トラスト・プロキシ内に内部化されるのではなく、セキュリティ・トークン・サービス・コンポーネントは、たとえば、トラスト・プロキシによって呼び出されるスタンドアロン・コンポーネントとして実現することもでき、あるいは、たとえば、アプリケーション・サーバの一部として、トランザクション・サーバ内に内部化することもできる。

たとえば、ＳＴＳコンポーネントは、Ｋｅｒｂｅｒｏｓトークンを発行するための要求を受信することができる。そこからトークンが作成されるユーザの認証情報の一部として、要求は、ユーザ名とパスワードを含むバイナリ・トークンを含むことができる。ＳＴＳコンポーネントは、たとえば、ＬＤＡＰランタイム（典型的な認証）に照らし合わせてユーザ名およびパスワードを妥当性検査することになり、Ｋｅｒｂｅｒｏｓ ＫＤＣ（鍵配布センタ：Key Distribution Center）を呼び出して、このユーザに関するＫｅｒｂｅｒｏｓチケットを生成することになる。このトークンは、企業内で使用するためにトラスト・プロキシに返されるが、この使用は、フェデレーション内の他のドメインに転送するためにトークンを外部化することを含む可能性がある。

図４に関して説明したものと同様に、ユーザは、企業２５０および企業２６０の両方など、連携環境内の複数企業のリソースにアクセスすることを所望する可能性がある。企業２５０に関して上述したものと同様に、企業２６０は、窓口サーバ２６２と、トラスト・プロキシ２６４と、セキュリティ・トークン・サービス２６５と、認証サービス・ランタイム２６６とを有する。ユーザは各企業との個別のトランザクションを直接開始することができるが、ユーザは、連携環境全体にわたってカスケードする企業２５０とのトランザクションを開始することができる。ユーザがトランザクションを開始したときにユーザがその必要性を認識していなかった可能性がある場合でも、企業２５０は、特定のトランザクションを完了するために、企業２６０などの連携環境内の他の複数の企業とのコラボレーションを必要とする場合がある。企業２６０はダウンストリーム・ドメインとして関係することになり、本発明により、企業２５０は、ユーザのトランザクションを促進するために必要であれば、連携アサーションを企業２６０に提示することができる。

関連窓口サーバによって受信された認証トークンを解釈する方法あるいは所与のユーザＩＤおよび属性を変換する方法またはその両方をトラスト・プロキシが把握していないということが実情である場合もある。この場合、トラスト・プロキシは、トラスト・ブローカ２６８などのトラスト・ブローカ・コンポーネントで機能を呼び出すことを選択することができる。トラスト・ブローカは、個々のトラスト・プロキシとの関係を維持し、それにより、トラスト・プロキシ間の推移的な信頼関係を提供する。トラスト・ブローカを使用すると、企業２５０および２６０などの連携環境内の各エンティティは、連携環境内の各ドメインとの複数の個別信頼関係を確立するのではなく、トラスト・ブローカとの信頼関係を確立することができる。たとえば、企業２６０が企業２５０のユーザによって開始されたトランザクションについてダウンストリーム・ドメインとして関係することになったときに、企業２５０のトラスト・プロキシ２５４は、必要な場合にトラスト・ブローカ２６８で支援を呼び出すことにより、企業２６０のトラスト・プロキシ２６４がトラスト・プロキシ２５４からのアサーションを理解できることを確信することができる。図８は、単一トラスト・ブローカを備えた連携環境を描写しているが、連携環境は複数のトラスト・ブローカを有することができる。

図８は窓口サーバ２５２、トラスト・プロキシ２５４、セキュリティ・トークン・サービス・コンポーネント２５５、および認証サービス・ランタイム２５６を別個のエンティティとして描写しているが、これらのコンポーネントを個別のデバイスとして実現する必要はないことに留意されたい。たとえば、これらの個別のコンポーネントの機能を、単一物理装置上のアプリケーションとして実現するかまたは単一アプリケーションに結合することは可能である。加えて、図８は、１つの企業のための単一窓口サーバ、単一トラスト・プロキシ、および単一セキュリティ・トークン・サーバを描写しているが、代替構成は、各企業用の複数の窓口サーバ、複数のトラスト・プロキシ、および複数のセキュリティ・トークン・サーバを含むことができる。窓口サーバ、トラスト・プロキシ、セキュリティ・トークン・サービス、およびその他の連携エンティティは、ソフトウェア・アプリケーション、オブジェクト、モジュール、ソフトウェア・ライブラリなどの様々な形で実現することができる。

トラスト・プロキシ／ＳＴＳは、ユーザ名とパスワードの組合せおよびＫｅｒｂｅｒｏｓチケットなどの伝統的な信用証明情報を含む多種多様な認証信用証明情報ならびにサード・パーティによって生成される認証トークンを含む連携認証トークン・フォーマットを受諾し妥当性検査することができる。トラスト・プロキシ／ＳＴＳは、他の場所で認証の証明として認証トークンの受諾を可能にすることができる。認証トークンは、発行側パーティによって生成され、ユーザがその発行側パーティに対してすでに認証を受けていることを示すために使用される。発行側パーティは、ユーザの認証済みＩＤをアサートする手段として、認証トークンを生成する。

セキュリティ・トークン・サービスは、必要に応じて、認証サービス・ランタイムを呼び出す。認証サービス・ランタイムは、ユーザを認証できる認証サービスをサポートする。認証サービスは、認証応答を介して認証試行の成功または失敗の表示を提供する認証機関として動作する。トラスト・プロキシ／ＳＴＳは、認証サービス、たとえば、既存のレガシー・インフラストラクチャと対話する必要がないＷｅｂサービスの真新しいインストールが存在するというシナリオを内部化することができる。そうではない場合、ＳＴＳコンポーネントは、認証トークンの妥当性検査のために外部認証サービスを呼び出すことになる。たとえば、ＳＴＳコンポーネントは、ユーザ名／パスワードを含むバイナリ・トークンを「アンパック」し、次にＬＤＡＰサービスを使用してユーザ・レジストリにアクセスし、提示された信用証明情報の妥当性を検査することができるであろう。

アプリケーション・サーバなどの他のコンポーネントによって使用される場合、ＳＴＳコンポーネントは、レガシー認証システムへのシングル・サインオンに必要なトークンを生成するために使用することができる。このため、ＳＴＳコンポーネントは、内部目的のために、すなわち、１つの企業内で、ならびに外部目的のために、すなわち、１つのフェデレーション内の複数企業の全域で、トークン変換に使用することができる。内部目的の一例として、Ｗｅｂアプリケーション・サーバは、ＩＢＭ ＣＩＣＳ（顧客情報管理システム：Customer Information Control System）トランザクション・ゲートウェイを介してメインフレームとのインターフェースを取ることができ、ＣＩＣＳは、企業レベルのオンライン・トランザクション管理および接続性を主幹業務アプリケーションに提供するアプリケーション・サーバおよびコネクタのファミリである。Ｗｅｂアプリケーション・サーバは、Ｋｅｒｂｅｒｏｓチケット（Ｗｅｂアプリケーション・サーバによって内部で使用されるもの）を、ＣＩＣＳトランザクション・ゲートウェイが要求するＩＢＭ ＲＡＣＦ（商標）パスチケットに変換するために、ＳＴＳコンポーネントを呼び出すことができる。

図８に示したエンティティは、上記で紹介した用語、たとえば、「発行側パーティ」および「依存側パーティ」を使用して説明することができる。信頼関係を確立し維持することの一部として、発行側パーティのトラスト・プロキシは、依存側パーティのトラスト・プロキシによってどのトークン・タイプが要求／受諾されるかを決定することができる。したがって、トラスト・プロキシは、セキュリティ・トークン・サービスからトークン・サービスを呼び出すときに、この情報を使用する。発行側ドメインのトラスト・プロキシが依存側パーティに関する認証アサーションを生成することを要求された場合、そのトラスト・プロキシは、必要なトークン・タイプを決定し、セキュリティ・トークン・サービスから適切なトークンを要求する。

依存側ドメインのトラスト・プロキシが発行側パーティから認証アサーションを受信すると、そのトラスト・プロキシは、どのタイプのアサーションをそれが予想していたか、ならびに依存側ドメイン内の内部使用のためにどのタイプのアサーションを必要としているかを把握する。したがって、依存側ドメインのトラスト・プロキシは、受信した認証アサーション内のトークンに基づいて、セキュリティ・トークン・サービスが必要な内部使用トークンを生成することを要求する。

トラスト・プロキシとトラスト・ブローカはどちらも、発行側パーティから受信したアサーションを、依存側パーティによって理解されるフォーマットに変換する能力を有する。トラスト・ブローカは、それとの直接的信頼関係が存在するトラスト・プロキシのそれぞれに関するアサーション・フォーマット（複数も可）を解釈する能力を有し、それにより、トラスト・ブローカが発行側パーティと依存側パーティとの間のアサーション変換を行えるようにする。この変換は、その局所的トラスト・プロキシによりいずれかのパーティによって要求することができる。したがって、発行側パーティのトラスト・プロキシは、それが依存側パーティに送信される前にアサーションの変換を要求することができる。同様に、依存側パーティのトラスト・プロキシは、発行側パーティから受信されたアサーションの変換を要求することができる。

アサーション変換は、ユーザＩＤ変換、認証アサーション変換、属性アサーション変換、またはその他の形式のアサーション変換を含む。上記のポイントを繰り返すと、アサーション変換は、フェデレーション内の連携コンポーネント、すなわち、トラスト・プロキシとトラスト・ブローカによって処理される。トラスト・プロキシは、発行側ドメインまたは依存側ドメインのいずれかで、この変換をローカルで実行する場合もあれば、トラスト・ブローカから支援を呼び出す場合もある。

発行側パーティと依存側パーティがすでにトラスト・ブローカとの個別信頼関係を有すると想定すると、トラスト・ブローカは、必要であれば発行側パーティと依存側パーティとの間の新しい信頼関係を動的に作成する、すなわち、ブローカリングすることができる。トラスト・ブローカによって提供される初期信頼関係ブローカリング操作の後、発行側パーティと依存側パーティは、将来の変換要件のためにトラスト・ブローカを呼び出す必要がないように、その関係を直接維持することができる。認証トークンの変換は、発行側パーティのトラスト・プロキシ、依存側パーティのトラスト・プロキシ、およびトラスト・ブローカという考えられる３つの箇所で起こる可能性があることに留意されたい。好ましくは、発行側パーティのトラスト・プロキシは、依存側パーティに送信するためにトラスト・ブローカによって理解される認証アサーションを生成する。次に依存側パーティは、トラスト・ブローカからのこのトークンを依存側パーティによって認識可能なフォーマットに変換することを要求する。トークン変換は、認証アサーションの伝送前に、伝送後に、または伝送前と伝送後の両方で行うことができる。

連携アーキテクチャ内の信頼関係
本発明により実現される連携環境内には、企業トラスト・ドメインとフェデレーション・トラスト・ドメインという、管理しなければならない２つのタイプの「トラスト・ドメイン」が存在する。この２つのタイプのトラスト・ドメイン間の相違点は、部分的に、トラスト・ドメインとの信頼関係を支配する事業協定と、信頼を確立するために使用される技術とに基づいている。企業トラスト・ドメインは、その企業によって管理されるコンポーネントを含み、そのトラスト・ドメイン内のすべてのコンポーネントは互いに信頼する。一般に、たとえば、コンポーネント間で相互に認証されたＳＳＬセッションを要求することにより、配置された技術が１つの企業内で固有の信頼関係を作り出すので、１つの企業内で信頼を確立するために必要な事業協定はまったく存在しない。図７を参照すると、レガシー・アプリケーションおよびバックエンド処理システムは企業トラスト・ドメインを表すことができる。

フェデレーション・トラスト・ドメインは企業境界を越えるものであり、ある視点によると、フェデレーション・トラスト・ドメインは、別個の企業トラスト・ドメイン間の信頼関係を表すことができる。フェデレーション・トラスト・ドメインは、企業境界の全域でトラスト・プロキシにより確立される。連携信頼関係は、それによりトラスト・プロキシ間に初期信頼が確立される、ある種のブートストラッピング・プロセスを必要とする。このブートストラップ・プロセスの一部は、予想あるいは許可またはその両方のトークン・タイプとＩＤ変換を定義するルールならびに共有秘密鍵の確立を含むことができる。一般に、このブートストラッピング・プロセスは、ある企業のフェデレーションへの参加を支配する事業協定の確立と、この参加に関連する責任も含むので、このプロセスはアウト・オブ・バンドで実現される。

連携ビジネス・モデルには信頼を確立するためのメカニズムがいくつか存在する。フェデレーション・モデルでは、参加者間で転送されるアサーション（トークンおよび属性情報を含む）が有効であるという、あるレベルの保証を提供するために、ビジネス上の理由でフェデレーション参加者間の信頼の基本概念が必要である。信頼関係がまったくない場合、依存側ドメインは発行側ドメインから受信したアサーションに依存することができず、発行側パーティから受信した任意の情報を解釈する方法を決定するために依存側ドメインがそれを使用することができない。

たとえば、大企業は、数千のグローバル・カスタマ（global customer）をリンクしたいと希望する可能性があり、その企業は従来技術のソリューションを使用できるであろう。第１の例として、その企業は、相互信頼を確立するために商用証明局からのデジタル証明書を使用することをグローバル・カスタマに要求できるであろう。商用証明局は、その企業のサーバがそれぞれのグローバル・カスタマに位置するサーバを信頼できるようにする。第２の例として、その企業はＫｅｒｂｅｒｏｓを使用してサード・パーティの信頼を実現でき、その企業とそのグローバル・カスタマは共有秘密鍵ベースの信頼を実現するトラステッド・サード・パーティＫｅｒｂｅｒｏｓドメイン・サービスを実現できるであろう。第３の例として、その企業は、そのグローバル・カスタマのサーバによって相互に信頼される独自のセキュリティ・メッセージ・トークンにより専用方式を確立できるであろう。

その企業が少数のグローバル・カスタマとの信頼関係を管理する必要がある場合、上記の手法のいずれか１つが受入れ可能である可能性があるが、数百または数千の潜在的なフェデレーションのパートナが存在する場合には、これは管理不能になる可能性がある。たとえば、企業がより小規模なパートナに専用方式の実現を強制することは可能である場合もあるが、企業がより大規模なパートナに多くの要件を賦課できるようになることはありそうもないことである。

本発明では、企業は、トラスト・プロキシと、おそらくトラスト・ブローカにより確立され維持された信頼関係を使用することになる。本発明の連携アーキテクチャの利点の１つは、ある企業およびその潜在的なフェデレーションのパートナの現行インフラストラクチャ以上の追加要件を賦課しないことである。

しかし、本発明は、フェデレーションへの参加に必要な事業および責任協定を確立するために必要な予備作業から企業およびその潜在的なフェデレーションのパートナを救済するものではない。加えて、参加者は信頼関係の技術的ブートストラッピングを無視することができない。本発明はこのブートストラッピングを柔軟なものにすることができ、たとえば、第１のフェデレーションのパートナは特定の情報でＫｅｒｂｅｒｏｓチケットを発行することができ、第２のフェデレーションのパートナは特定の情報でＳＡＭＬ認証アサーションを発行することができる。

本発明では、２つのトラスト・プロキシ間で事前確立された関係に基づいて発行側パーティから受信されるトークンを妥当性検査し変換するセキュリティ・トークン・サービスを含むことができるフェデレーション・トラスト・プロキシにより信頼関係が管理される。連携企業が他の連携企業との信頼関係（およびトークン変換）を確立することが実現可能ではない状況では、トラスト・ブローカを呼び出すことができる。しかし、連携企業は依然として、トラスト・ブローカとの関係を確立しなければならない。

次に図９を参照すると、ブロック図は、本発明によりトラスト・プロキシとトラスト・ブローカとを使用する連携ドメイン間の例示的な１組の信頼関係を描写している。図８はトラスト・ブローカを紹介したが、図９は本発明の連携アーキテクチャ内の推移的な信頼関係の重要性を示している。

連携ドメイン２７１〜２７３はトラスト・プロキシ２７４〜２７６をそれぞれ組み込んでいる。トラスト・プロキシ２７４はトラスト・プロキシ２７５との直接的信頼関係２７７を有する。トラスト・ブローカ２８０はトラスト・プロキシ２７５との直接的信頼関係２７８を有し、トラスト・ブローカ２８０はトラスト・プロキシ２７９との直接的信頼関係２７９を有する。トラスト・ブローカ２８０は、フェデレーション参加者に代わって、他のフェデレーションのパートナとの推移的な信頼関係に基づいて信頼関係を確立するために使用される。推移的な信頼関係の原理により、トラスト・プロキシ２７５およびトラスト・プロキシ２７６はトラスト・ブローカ２８０を介して信頼関係２８１をブローカリングしてもらうことができる。トラスト・プロキシ２７５または２７６はいずれも、もう一方のアサーションを変換または妥当性検査する方法を把握している必要はなく、有効であり、信頼され、もう一方のトラスト・プロキシで理解されるものにアサーションを変換するために、トラスト・ブローカを呼び出すことができる。

連携した企業間の信頼関係に関する契約上の義務および責任を指定する事業協定は、ｅｂＸＭＬ（ＸＭＬを使用する電子ビジネス）規格の使用によりＸＭＬで表すことができる。たとえば、直接的信頼関係はｅｂＸＭＬドキュメントで表すことができ、直接的信頼関係を共用する各連携ドメインはｅｂＸＭＬドキュメントとして表された契約書のコピーを有することになるであろう。フェデレーション内の様々なエンティティに関する動作特性は、ｅｂＸＭＬ振り付け（choreography）内に指定し、ｅｂＸＭＬレジストリ内で公開することができ、たとえば、トラスト・プロキシまたはトラスト・ブローカを操作するために、特定のフェデレーションに参加することを希望する任意の企業は、そのフェデレーション内のすべてのトラスト・プロキシまたはトラスト・ブローカについてその特定のフェデレーションによって指定された公開要件に適合する必要があるであろう。セキュリティ・トークン・サービスは、他のドメインからのトークンを変換する方法に関する操作上の詳細について、これらのｅｂＸＭＬドキュメントを構文解析できるであろう。しかし、フェデレーション内の信頼関係が実現される方法に関する詳細を指定するために、本発明により他の規格およびメカニズムを使用できることに留意されたい。

連携アーキテクチャ内のアサーション処理
上記の通り、フェデレーション内のユーザの経験は、部分的に、複数ドメインの全域で転送される、ユーザに関するかまたはそのユーザのためのアサーションによって支配される。アサーションは、ユーザの認証状況に関する情報、属性情報、およびその他の情報を提供する。認証アサーションを使用すると、ユーザが、アクセスしたサイトごとに再認証を受ける必要性を除去することができる。連携環境内には、発行側パーティから依存側パーティへのアサーションを取得するために、プッシュ・モデル（push model）とプル・モデル（pullmodel）という２つのモデルが存在する。プッシュ・モデルでは、ユーザのアサーションはユーザの要求とともに発行側パーティに移動する。プル・モデルでは、ユーザの要求はいかなる情報もなしで依存側パーティで受信され、次に依存側パーティは発行側パーティから関連アサーションまたは必要なアサーションを要求する。

連携環境内でアサーションを使用するためのこれらのモデルを考慮して、次に本発明の説明では、本発明の連携環境内でアサーションを作成し使用するための１組のプロセスを記述する１組の図面を参照する。図１０は、連携環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写しており、図１１は、アサーションを「取り壊す」ため、すなわち、その情報を抽出し分析することにより、アサーションをその本質的情報まで削減するための依存側ドメインにおける汎用プロセスを描写している。図１２および図１３は、アサーションが発行側ドメイン内で生成され、次にユーザの要求とともに依存側ドメインに転送される、プッシュ・モデルの２つの変形を描写することにより、図１０に示した汎用プロセスに関するより詳細なプロセスを示している。図１４は、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。

次に図１０を参照すると、フローチャートは、連携環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写している。このプロセスは、発行側ドメインの窓口サーバがアサーションのためにトリガされたときに始まる（ステップ３０２）。窓口サーバは、依存側ドメインから所与のユーザ用の特定のアサーションに関する要求を受信する場合もあれば、アサーションを必要とする既知の依存側ドメインに対する発信要求をインターセプトする場合もあり、これらのシナリオについてはそれぞれ図１２および１３に関して以下により詳細に説明する。アサーションのためにトリガされたことに応答して、発行側ドメインの窓口サーバは発行側ドメインのトラスト・プロキシからアサーションを要求し（ステップ３０４）、発行側ドメインのトラスト・プロキシがアサーションを生成し（ステップ３０６）、発行側ドメインのトラスト・プロキシは、必要であれば、必要なアサーションを生成するためにトラスト・ブローカから支援を要求することができる。アサーションを生成した後、発行側ドメインのトラスト・プロキシは発行側ドメインの窓口サーバにアサーションを返し（ステップ３０８）、次に発行側ドメインの窓口サーバが適切な方法で、たとえば、発信ＨＴＴＰまたはＳＯＡＰメッセージにアサーションを挿入することにより、出力データストリームにアサーションを注入し（ステップ３１０）、それにより、プロセスを完了する。

図１０は、「ローカル・ウォレット」の使用なしに発行側ドメインでアサーションを作成するためのプロセスを描写している。しかし、本発明はローカル・ウォレット機能の組込みを可能にするものである。一般に、ローカル・ウォレットは、トランザクションを容易にするためにユーザ属性情報またはその他の情報に関するセキュア・データ・ストアとして動作可能なクライアント側のコードであり、このクライアント側のコードはアサーション転送のプッシュ・モデルあるいはプル・モデルまたはその両方に参加することもできる。ローカル・ウォレットが積極的にプロトコルに参加すると、それは、アサーションを生成し、それをプロトコル・フローに挿入するという点で窓口サーバ機能の機能サブセットを実現する。ローカル・ウォレットを使用することにより、ローカル・ウォレットが、窓口サーバとトラスト・プロキシとの間で行われるトラストベースの対話を実現できるわけではない。追加の信頼関係が必要な場合、窓口サーバを呼び出さなければならない。

次に図１１を参照すると、フローチャートは、アサーションを取り壊すための依存側ドメインにおける汎用プロセスを描写している。このプロセスは、依存側ドメインの窓口サーバが関連アサーションとともにメッセージを受信したときに始まり（ステップ３２２）、その後、依存側ドメインの窓口サーバはアサーションを抽出し、依存側ドメインのトラスト・プロキシにアサーションを転送する（ステップ３２４）。依存側ドメインのトラスト・プロキシは、発行側ドメインから受信したトークンを含む情報をアサーションから抽出し（ステップ３２６）、依存側ドメインのトラスト・プロキシは、セキュリティ・トークン・サービスを呼び出してこのトークンの妥当性を検査することになり、適切であれば、そのユーザに関してローカルで有効なトークンを返す（ステップ３２８）。

ステップ３２６の一部として、トラスト・プロキシは、アサーションのソース、すなわち、発行側パーティを決定することになる。トラスト・プロキシがこの発行側ドメインから受信したトラストアサーションを理解できる場合、トラスト・プロキシはステップ３２８を内部で実行することになる。トラスト・プロキシが発行側ドメインから受信したアサーションを理解／信頼できない場合、トラスト・プロキシはトラスト・ブローカからの支援を呼び出すことができる。アサーションの妥当性を検査できない場合、適切なエラー応答を生成することになるであろう。

アサーションの妥当性が検査されたと想定すると、依存側ドメインのトラスト・プロキシは、そのユーザについて必要なローカル情報を構築する（ステップ３３０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって必要とされる認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインの窓口サーバに返し（ステップ３３２）、その窓口サーバがそのユーザのためのローカル・セッションを構築する。

窓口サーバがそのユーザのためのセッションを構築した後、そのユーザは認証ユーザとして現れる。窓口サーバは、ログアウトまたはタイムアウト・イベントが開始されるまでユーザがそのドメインとの間で行っている任意のトランザクションをさらに支配するために、このセッション情報を使用することができる。窓口サーバがそのユーザに関する認証済みＩＤを有していることを考慮すると、窓口サーバは、この特定のユーザのＩＤとこの特定のユーザに関連する任意の許可ポリシーに基づいて、必要であれば、この要求に関する許可を入手することができる。次に窓口サーバは、要求されたバックエンド・アプリケーションまたはサービスに任意の関連情報とともにユーザの要求を転送し（ステップ３３４）、それにより、プロセスを完了する。

窓口サーバとトラスト・プロキシとの間で転送されるデータ項目およびそのデータ項目のフォーマットは様々になる可能性があることに留意されたい。メッセージからアサーションを抽出し、アサーションのみをトラスト・プロキシに転送するのではなく、窓口サーバは、メッセージ全体をトラスト・プロキシに転送することができる。たとえば、トラスト・プロキシにおける処理は、ＳＯＡＰメッセージ関するシグニチャ妥当性検査のようなステップを含むことができ、これはＳＯＡＰエンベロープ全体を必要とするであろう。

次に図１２を参照すると、フローチャートは、発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが発行側ドメイン内のＷｅｂページまたは同様のリソースから依存側ドメインへのリンクにアクセスしたときに始まり（ステップ３４２）、それにより、特定のアサーションを構築するために何らかの形のＣＧＩ（コモン・ゲートウェイ・インターフェース）タイプの処理を呼び出す。依存側ドメインによるアサーションの必要性を認識する発行側ドメインの能力は、本発明の連携インフラストラクチャが実現される既存のレガシー・システムとの緊密統合を示している。また、これは、発行側パーティが必要なアサーションを構築するためにトラスト・プロキシを呼び出す必要がないような、発行側パーティと依存側パーティとの緊密結合も示しており、この緊密結合は、適切に確立された信頼関係を有する特定のタイプの連携エンティティ間では適切なものである可能性がある。

発行側ドメインにおけるバックエンド処理は、必要なアサーションを構築するために呼び出され（ステップ３４４）、これは、ローカル・トラスト・プロキシにおける呼出し機能を含む可能性がある。次に、必要なアサーションを含む、依存側ドメインへのユーザの要求が構築され（ステップ３４６）、発行側ドメインはユーザの要求とともにアサーションを依存側ドメインに転送し（ステップ３４８）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションの妥当性を検査することになるであろう。

次に図１３を参照すると、フローチャートは、依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが依存側ドメインにおける保護リソースを要求したときに始まる（ステップ３５２）。窓口サーバは、たとえば、所定のユニフォーム・リソース・アイデンティファイア（ＵＲＩ）、特定のタイプのメッセージ、特定のタイプのメッセージ・コンテンツについて発信メッセージをフィルタリングすることによるか、またはその他の何らかの方法で、発信要求をインターセプトする（ステップ３５４）。次に発行側ドメインの窓口サーバは、発行側ドメインのトラスト・プロキシから適切なアサーションの生成を要求し（ステップ３５６）、そのトラスト・プロキシは必要であればトラスト・ブローカからの支援によりアサーションを生成する（ステップ３５８）。次に発行側ドメインは、生成したアサーションとともにユーザの要求を依存側パーティに転送し（ステップ３６０）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションを妥当性検査することになるであろう。

次に図１４を参照すると、フローチャートは、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。このプロセスは、依存側ドメインが保護リソースに関するユーザ要求を受信したときに始まる（ステップ３７２）。図１２または図１３に示した例とは対照的に、図１４に示した例は、ユーザに関する必要なアサーションがない場合に依存側ドメインで受信されるユーザの要求に関連する処理を記述している。この場合、発行側ドメインは、ユーザの要求に必要なアサーションを挿入するためにユーザの要求をインターセプトするかまたはその他の方法で処理する能力を持っていない。たとえば、ユーザは、発信要求が発行側ドメインの窓口サーバによってインターセプトされないように、ユニフォーム・リソース・ロケータ（ＵＲＬ）を入力したかまたはリソースへのブックマーク付き参照を使用した可能性がある。このため、依存側ドメインは発行側ドメインからアサーションを要求する。

次に依存側ドメインは、ユーザのホーム・ドメイン、すなわち、関連発行側ドメインを決定する（ステップ３７４）。ＨＴＴＰベースの実現例では、ユーザは、すでに依存側ドメインとの関係を事前設定しており、その結果、ユーザのクライアント装置で依存側ドメインによって永続Ｃｏｏｋｉｅが設定された可能性がある。この永続Ｃｏｏｋｉｅは、ユーザのホーム・ドメイン、すなわち、発行側ドメインのＩＤを含むことになるであろう。ユーザが何らかの方法でＷｅｂサービス・クライアントを操作するＳＯＡＰベースの実現例では、依存側ドメインにおけるＷｅｂサービスは、トークン要件を含む、ＷＳＤＬ（Ｗｅｂサービス記述言語：Web Services Description Language）によるサービス要件を公示したと考えられる。次にこれは、必要なトークン・タイプを提供するためにユーザのＷｅｂサービス・クライアント／ＳＯＡＰ実現例を必要とするであろう。この要件が達成されなかった場合、Ｗｅｂサービスは技術的にエラーを返すことになるであろう。場合によっては、これは、その要求を適切なトークンで繰り返すことができるように、認証情報を入力するようユーザのＷｅｂサービス・クライアントに促すことができるエラー・コードを返す可能性がある。

依存側ドメインの窓口サーバは、依存側ドメインのトラスト・プロキシによりアサーション要求を開始し（ステップ３７６）、それは発行側ドメインのトラスト・プロキシからユーザに関するアサーションを要求する（ステップ３７８）。この実施形態がＨＴＴＰベースの通信を使用している場合、依存側ドメインのトラスト・プロキシから発行側ドメインのトラスト・プロキシへのアサーション要求は、ユーザのブラウザ・アプリケーションによるリダイレクトを介して依存側ドメインの窓口サーバによって発行側ドメインの窓口サーバに伝送することができ、その窓口サーバはアサーション要求を発行側ドメインのトラスト・プロキシに転送する。

この実施形態がＳＯＡＰベースの実現例を使用している場合、依存側パーティは、ユーザのＷｅｂサービス・クライアントにエラー・コードを返すことができる。このエラー・コードにより、Ｗｅｂサービス・クライアントによって認証情報を入力するようユーザに促すことができる。次にＷｅｂサービス・クライアントは、要求されたトークンを生成することになるであろう。依存側ドメインのトラスト・プロキシがＵＤＤＩ（ユニバーサル記述、ディスカバリ、および統合：Universal Description, Discovery, and Integration）レジストリで公示され、ユーザのＷｅｂサービス・クライアントがトラスト・プロキシを見つけられるようにしている場合、ユーザのＷｅｂサービス・クライアントはトラスト・プロキシを直接呼び出すことができるであろう。一般に、このシナリオは内部ユーザについてのみ有効であり、その場合、トラスト・プロキシがインターネット上の公用ＵＤＤＩで公示されるかまたはフェデレーション外で一般にアクセス可能になることはありそうもないので、トラスト・プロキシは企業内の専用ＵＤＤＩで公示されている。

発行側ドメインのトラスト・プロキシは、アサーション要求が受信された方法をミラーリングする方法で、要求されたアサーションを生成し（ステップ３８０）、それを返す（ステップ３８２）。依存側ドメインのトラスト・プロキシが要求されたアサーションを受信した後（ステップ３８４）、依存側ドメインのトラスト・プロキシはアサーションから情報を抽出し（ステップ３８６）、アサーションを解釈するかあるいは妥当性検査するかまたはその両方を行い（ステップ３８８）、トラスト・プロキシはアサーションの変換のために必要であれば、トラスト・ブローカからの支援を呼び出すことができる。そのアサーションの妥当性を検査できない場合、適切なエラー応答が生成されることになるであろう。アサーションの妥当性が検査されると想定すると、依存側ドメインのトラスト・プロキシは、保護リソースに関するユーザの要求を達成しようと試みるバックエンド・サービスによる使用に必要な適切なフォーマットでローカル情報を構築する（ステップ３９０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって要求される認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインの窓口サーバに返し（ステップ３９２）、次にそれはユーザに関するローカル・セッションを構築し、関連情報とともにユーザの要求を要求されたバックエンド・アプリケーションまたはサービスに転送し（ステップ３９４）、それにより、プロセスを完了する。

連携アーキテクチャ内のシングル・サインオン
図６〜図９の説明は本発明による連携データ処理環境内のエンティティの動作特性に焦点を合わせているが、図１０〜図１４の説明はこれらのエンティティ間で行われるプロセスのいくつかに焦点を合わせている。これらの説明とは対照的に、ユーザにシングル・サインオン経験を提供しながら、ユーザに関するトランザクションを完了するという目標に焦点を合わせる本発明の説明のために、図１５を参照する。

換言すれば、以下の説明は、ユーザがユーザのセッション内でシングル・サインオン経験を持つことができる方法に関して本発明の概略視点に焦点を合わせているが、すでに前述したエンティティおよびプロセスについて論ずるものである。セッションは、初期ユーザ認証、すなわち、ログオンから（これを含む）ログアウトまでの１組のトランザクションとして定義することができる。セッション内のユーザのアクションは、部分的に、そのセッションに関してユーザに付与された権限によって支配されることになる。フェデレーション内のユーザは、そのセッション中にアクセスしたフェデレーションのパートナにかかわらず、ユーザが単一認証操作を完了し、そのセッションの期間の間、この認証操作で十分であるシングル・サインオン経験を持つことを期待する。

ユーザのセッション中に、ユーザは、多くの連携ドメインにアクセスして、そのドメインによって提供されるＷｅｂサービスを使用することができる。ドメインは、ＵＤＤＩおよびＷＳＤＬなどの標準規格を使用して、そのドメインが提供するサービスの記述を公開することができ、そのいずれも共通データ・フォーマットとしてＸＭＬを使用する。ユーザは、同じくこれらの標準規格に準拠するアプリケーションにより、使用可能なサービスおよびサービス・プロバイダを見つける。ＳＯＡＰは、ＸＭＬで表された要求および応答を伝達するためのパラダイムを提供する。連携環境内のエンティティは、とりわけ、これらの規格を使用することができる。

シングル・サインオン経験を容易にするために、連携環境をサポートするＷｅｂサービスは、ユーザの認証の証明を提供するためにサード・パーティによって生成された認証アサーションまたはセキュリティ・トークンの使用もサポートすることになる。このアサーションは、そのユーザ用のＩＤとともに、発行側パーティに対するユーザの認証の成功を示すある種の証拠を含むことになる。したがって、ユーザは、あるフェデレーションのパートナに対し、伝統的な認証信用証明情報、たとえば、ユーザ名およびパスワードを提示し、異なるフェデレーションのパートナに対し、認証／発行側パーティによって生成されたＳＡＭＬ認証アサーションを提供することができる。

Ｗｅｂサービス環境内の認証は、企業が許可クライアントにアクセスを制限できるように、Ｗｅｂサービス要求の請求されたＩＤを検証する行為である。Ｗｅｂサービスを要求するかまたは呼び出すユーザは、ほとんど常に認証され、したがって、本発明の連携環境内の認証の必要性はユーザ認証のためのＷｅｂサービスの現行要件とは少しも異ならないものである。また、連携環境により、Ｗｅｂサービスまたはその他のアプリケーションはＷｅｂサービスを要求することができ、これらのＷｅｂサービスも認証されることになるであろう。

連携セッションに参加していないユーザの認証は、本発明の連携アーキテクチャによる影響を受けない。たとえば、特定のドメインの非連携リソースにアクセスするためにＨＴＴＰ／Ｓによる用紙ベースの認証メカニズムで認証を受ける既存のユーザは、連携環境に関するそのドメインのサポートを導入することによって影響されない。認証は、部分的に、窓口サーバによって処理され、次にその窓口サーバが個別のトラスト・プロキシ・コンポーネントを呼び出すことができる。窓口サーバの使用は、既存のドメインのインフラストラクチャに対する影響を最小限にする。たとえば、窓口サーバは、そのドメインのバックエンドまたはレガシー・アプリケーションおよびシステムによって処理されるすべての非連携要求を通過するように構成することができる。

窓口サーバは、基本認証、用紙ベースの認証、またはその他の何らかの認証方法などのＨＴＴＰベースの認証方法を呼び出すことを選択することができる。また、窓口サーバは、ＳＡＭＬ認証アサーションなど、認証の証明としてユーザによって提示されたアサーションを認識することにより、連携トラスト・ドメインもサポートし、そのアサーションは企業トラスト・ドメイン間を越えている。窓口サーバはトラスト・プロキシを呼び出すことができ、次にそのトラスト・プロキシは認証信用証明情報／セキュリティ・トークンの妥当性検査のためにそのセキュリティ・トークン・サービスを呼び出すことができる。

Ｗｅｂサービスまたはその他のアプリケーションの認証は、ユーザの認証と同じプロセスを有する。Ｗｅｂサービスからの要求は、認証アサーションを含むセキュリティ・トークンを伝達し、このセキュリティ・トークンはユーザによって提示されるトークンと同じようにトラスト・プロキシ／セキュリティ・トークン・サービスによって妥当性検査されることになるであろう。ＷｅｂサービスはＵＤＤＩで公示された要求されたサービスによってどの認証アサーション／セキュリティ・トークンが要求されているかをすでに発見していると考えられるので、Ｗｅｂサービスからの要求は必ずそれとともにこのトークンを伝達しなければならない。

次に図１５を参照すると、ブロック図は、連携シングル・サインオン操作をサポートする連携環境を描写している。ユーザ４００は、クライアント装置およびブラウザなどの適切なクライアント・アプリケーションにより、企業／ドメイン４１０によって提供されるＷｅｂサービスにアクセスすることを所望し、その企業／ドメインは、連携環境内の連携ドメインとして動作するデータ処理システムをサポートする。ドメイン４１０は窓口サーバ４１２およびトラスト・プロキシ４１４をサポートし、同様に、ドメイン４２０は窓口サーバ４２２およびトラスト・プロキシ４２４をサポートし、ドメイン４３０は窓口サーバ４３２およびトラスト・プロキシ４３４をサポートする。トラスト・プロキシは、上述の通り、支援のためにトラスト・ブローカ４５０を当てにする。追加のドメインおよびトラスト・プロキシも連携環境に参加することができる。図１５は、ドメイン４１０とドメイン４２０との間の連携シングル・サインオン操作を記述しており、同様の操作はドメイン４１０とドメイン４３０との間でも行うことができる。

ユーザはドメイン４１０に関する認証操作を完了し、この認証操作は窓口サーバ４１２によって処理される。たとえば、アクセス制御またはパーソナライゼーションのために、認証済みＩＤを必要とする何らかのリソースへのアクセスをユーザが要求すると、認証操作がトリガされる。窓口サーバ４１２は、レガシー認証サービスを呼び出す場合もあれば、トラスト・プロキシ４１４を呼び出してユーザが提示した認証信用証明情報の妥当性を検査する場合もある。ドメイン４１０は、ユーザの連携セッションの期間中、ユーザのホーム・ドメインになる。

その後のある時点で、ユーザは、同じく連携ドメインをサポートする企業４２０などのフェデレーションパートナにおいてトランザクションを開始し、それにより、連携シングル・サインオン操作をトリガする。たとえば、ユーザがドメイン４２０で新しいトランザクションを開始する場合もあれば、ユーザの元のトランザクションが他のドメインにおける１つまたは複数の追加トランザクションにカスケードする場合もある。もう１つの例として、ユーザは、たとえば、ドメイン４１０内でホストとして処理されるＷｅｂページ上の特殊リンクを選択するか、またはドメイン４１０内でホストとして処理されるがドメイン４２０内でホストとして処理されるリソースを表示するポータル・ページを要求することにより、窓口サーバ４１２を介してドメイン４２０内のリソースへの連携シングル・サインオン操作を呼び出すこともできる。窓口サーバ４１２は、ドメイン４２０によって理解または信頼されるようにフォーマットされた、そのユーザ用のフェデレーションシングル・サインオン・トークンを生成するために、トラスト・プロキシ４１４に要求を送信する。トラスト・プロキシ４１４はこのトークンを窓口サーバ４１２に返し、その窓口サーバ４１２はこのトークンをドメイン内の窓口サーバ４２２に送信する。ドメイン４１０は、依存側パーティとして動作するドメイン４２０のユーザのための発行側パーティとして動作する。ユーザのトークンはユーザの要求とともにドメイン４２０に転送されると考えられ、このトークンはユーザのブラウザによるＨＴＴＰリダイレクトを使用して送信される場合もあれば、トラスト・プロキシ４１４によって供給されるトークンで識別されるユーザに代わって（ＨＴＴＰまたはＨＴＴＰによるＳＯＡＰにより）窓口サーバ４２２の要求を直接呼び出すことにより送信される場合もある。

窓口サーバ４２２は、フェデレーション・シングル・サインオン・トークンとともにその要求を受信し、トラスト・プロキシ４２４を呼び出す。トラスト・プロキシ４２４は、フェデレーションシングル・サインオン・トークンを受信し、そのトークンの妥当性を検査し、そのトークンが有効で信頼されているものと想定して、ユーザのためにローカルで有効なトークンを生成する。トラスト・プロキシ４２４はローカルで有効なトークンを窓口サーバ４２２に返し、その窓口サーバはドメイン４２０内でそのユーザに関するセッションを確立する。必要であれば、窓口サーバ４２２は、他の連携したパートナにおいて連携シングル・サインオンを開始することができる。

ドメイン４２０におけるトークンの妥当性検査は、おそらく、セキュリティ・トークン・サービスからの支援により、トラスト・プロキシ４２４によって処理される。ドメイン４１０によって提示されたトークンのタイプに応じて、セキュリティ・トークン・サービスは、ドメイン４２０のユーザ・レジストリにアクセスする必要がある場合もある。たとえば、ドメイン４２０は、ドメイン４２０のユーザ・レジストリに照らし合わせて妥当性検査すべき、ユーザの名前とパスワードを含むバイナリ・セキュリティ・トークンを提供することができる。このため、この例では、企業は単に、連携したパートナからのセキュリティ・トークンの妥当性を検査するだけである。ドメイン４１０と４２０との信頼関係は、ユーザに代わってドメイン４１０によって提示されたセキュリティ・トークンをドメイン４２０が理解し信頼できることを保証する。

連携シングル・サインオンは、ユーザに代わって依存側ドメインに提示されるセキュリティ・トークンの妥当性検査のみならず、セキュリティ・トークンに含まれる情報に基づいて依存側ドメインにおいてローカルで有効なユーザＩＤを決定することも必要とする。このような関係を確立するために必要な直接的信頼関係と事業協定の結果の１つとして、少なくとも１つのパーティ、発行側ドメインあるいは依存側ドメインのいずれか一方またはその両方は、発行側ドメインによって提供された情報を依存側ドメインで有効なＩＤに変換する方法を把握することになる。上記の簡単な例では、発行側ドメイン、すなわち、ドメイン４１０が依存側ドメイン、すなわち、ドメイン４２０にドメイン４２０で有効なユーザＩＤを提供できるものと想定されていた。そのシナリオでは、依存側ドメインは、ＩＤマッピング機能を呼び出す必要はなかった。ドメイン４２０におけるトラスト・プロキシ４２４は、このユーザの「保証人となる」、ユーザ用のセキュリティ・トークンを生成することになる。受諾されるトークンのタイプ、トークン上で必要なシグニチャ、およびその他の要件はいずれも、フェデレーションの事業協定の一部として事前確立される。ＩＤ変換を支配するルールおよびアルゴリズムも、フェデレーションの事業協定の一部として事前確立される。２つの参加者間の直接的信頼関係の場合、ＩＤ変換アルゴリズムは、その２つのパーティについて確立されていることになり、フェデレーション内の他のどのパーティにも関連しない可能性がある。

しかし、ドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングする方法を発行側ドメインが把握することが常に実情であるわけではない。場合によっては、このマッピングを実行する方法を把握しているのは依存側ドメインである可能性があり、さらに他の場合には、いずれのパーティもこの変換を実行する方法を把握しなくなり、その場合、サード・パーティのトラスト・ブローカを呼び出す必要がある可能性もある。換言すれば、ブローカリングされた信頼関係の場合、発行側ドメインと依存側ドメインは互いに直接的信頼関係を持っていない。しかし、それらのドメインは、トラスト・ブローカ４５０などのトラスト・ブローカとの直接的信頼関係を持つことになる。ＩＤマッピング・ルールおよびアルゴリズムは、この関係の一部として確立されたものになり、トラスト・ブローカはこの情報を使用して、ブローカリングされた信頼関係に必要なＩＤ変換を支援することになる。

ドメイン４２０は、窓口サーバ４２２においてドメイン４１０によって発行されたトークンを受信し、その窓口サーバはトラスト・プロキシ４２４を呼び出して、トークンの妥当性を検査し、ＩＤマッピングを実行する。この場合、トラスト・プロキシ４２４はドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングすることができないので、トラスト・プロキシ４２４はトラスト・ブローカ４５０を呼び出し、そのトラスト・ブローカがトークンの妥当性を検査し、ＩＤマッピングを実行する。そのユーザ用のローカルＩＤを入手した後、トラスト・プロキシ４２４は、おそらくそのセキュリティ・トークン・サービスにより、ドメイン４２０においてバックエンド・アプリケーションによって要求される任意のローカル・トークンを生成することができ、たとえば、窓口サーバからアプリケーション・サーバへのシングル・サインオンを容易にするためにＫｅｒｂｅｒｏｓトークンが要求される可能性がある。必要であれば、ローカルで有効なトークンを入手した後、窓口サーバはそのユーザ用のローカル・セッションを構築することができる。また、窓口サーバは、ユーザ要求の粗雑な許可を処理し、ドメイン４２０内の適切なアプリケーション・サーバに許可された要求を転送することになる。

連携アーキテクチャ内の統合ログオフ
上述の連携環境では、ユーザの認証情報は複数ドメインおよび異機種環境の全域で渡される。ユーザはホーム・ドメインを有し、これはユーザの認証信用証明情報の妥当性を検査するドメインである。次にこのホーム・ドメインは、依存側パーティによって異なるドメイン内で信頼し使用することができるユーザに関するアサーションを発行するために発行側パーティとして動作することができる。このアサーションは、発行側パーティから依存側パーティに転送されると、ユーザ介入なしに実行され、まったく異なる複数ドメインの全域でシングル・サインオン経験をユーザに提供する。

しかし、ユーザがシステムに対して自分のＩＤを証明するために認証操作、すなわち、ログオンまたはログイン操作を完了するという要件は、システムを保護することの一部にすぎない。このプロセスの同様に重要な部分は、セキュア・セッションを終了するためにユーザがログオフ操作、すなわち、サインオフまたはサインアウト操作を完了するという要件であり、それにより、他のユーザが有効なセッションを流用するかまたは悪意をもって有効なセッションに干渉するのを防止する。

ログオフ操作に関する困難な問題の１つは、ユーザがどこでログオフすることを決定するかを予測できないことである。換言すれば、ユーザは連携シングル・サインオン・セッション内の多くのドメインと対話することができ、ユーザがログオフすることを決定したときにユーザがどのドメインと対話しているかを予測することは不可能である。一例として、ユーザはユーザのホーム・ドメインからログオフすることを決定する可能性がある。しかし、ホーム・ドメインが他のドメインでシングル・サインオン操作を実行し、その後、それらの依存側ドメインの１つが発行側ドメインとして動作するように、ユーザがトランザクションを呼び出した場合、ユーザのホーム・ドメインはこれらのドメインを認識しなくなり、ユーザに代わってこれらのドメインでログオフ・アクションを呼び出すことができない。

本発明は、連携環境内の統合ログオフ操作に関する様々な手法を提示する。本発明は統合ログオフ操作に関する２通りの一般的な手法に従うものであり、一方はＨＴＴＰに基づき、もう一方はＳＯＡＰに基づくものである。ＨＴＴＰ手法は、ユーザのブラウザによるＨＴＴＰリダイレクトを使用する「フロントエンド」方式で、またはユーザのブラウザを呼び出さずに連携ドメイン内の窓口サーバにログオフ通知が直接送信される「バックチャネル」方式で実行することができる。

ＳＯＡＰ手法は、ユーザまたはユーザのＳＯＡＰクライアントを呼び出さずにフェデレーションのコンポーネント間で直接通信が行われる「バックチャネル」方式で実行される。また、ＳＯＡＰ手法はパブリッシュ・サブスクライブ・モデルを使用することもでき、これは、発生する可能性のあるログオフ・イベントに依存側ドメインが加入できるようにするものである。次にユーザのホーム・ドメインはユーザに関するログオフ・イベントを発行することになり、このイベントはこのようなログオフ・イベントに加入したすべてのドメインによって受信される。次に依存側ドメインは、そのログオフ・イベントが特定のユーザに関連するかどうかを決定することができ、関連する場合、依存側ドメインはユーザのログオフまたはセッション・パージ（session purge）を実施する。このログオフに関する「最適化」手法は、依存側ドメインがより細かい細分性のログオフ・イベント、すなわち、特定のユーザに固有のログオフ・イベントに加入できるようにすることであり、したがって、依存側ドメインはすべてのログオフ・イベントを聴取する必要はなく、その特定のユーザに関するログオフ・イベントのみ聴取する必要がある。統合ログオフ操作に関するいくつかの好ましい実施形態については、残りの図面に関連して以下に説明する。

次に図１６を参照すると、フローチャートは、ＨＴＴＰリダイレクトにより連携ドメイン間で統合ログオフ操作を実行するためのプロセスを描写している。図１６に示した統合ログオフ操作は、たとえば、Ｗｅｂページ上のログオフ・ボタンを選択することにより、ユーザがログオフ・プロセスを呼び出したときまたはユーザがログオフ・リソースにアクセスしたときに、ユーザのホーム・ドメインで始まり（ステップ５０２）、代わって、非アクティブ・タイムアウト（inactivity timeout）などの様々な理由からホーム・ドメインによってログオフ操作を開始することもできるであろう。

ホーム・ドメインは１組の他の連携ドメインのための発行側ドメインとして動作していた可能性があり、このため、ホーム・ドメインはこのプロセス内では発行側ドメインと呼ばれる場合もある。発行側ドメインは、それがユーザに関する連携シングル・サインオン操作中に認証アサーションを送信した依存側ドメインのリストを取得する（ステップ５０４）。発行側ドメインはリストから次の依存側ドメインを識別し（ステップ５０６）、発行側ドメインの窓口サーバは、識別された依存側ドメインのユーザに関するログオフ要求メッセージを生成する（発行側ドメインのトラスト・プロキシからの支援による）（ステップ５０８）。発行側ドメインの窓口サーバは、ユーザのブラウザ・アプリケーションによるＨＴＴＰリダイレクトを介して識別された依存側ドメインの窓口サーバにログオフ要求を送信する（ステップ５１０）。発行側ドメインの窓口サーバは、その後、ユーザのブラウザ・アプリケーションによるＨＴＴＰリダイレクトを介して識別された依存側ドメインの窓口サーバからログオフ状況メッセージを受信し、保管する（ステップ５１２）。

依存側ドメインのリスト内に他の依存側ドメインが存在するかどうかに関する決定が行われ（ステップ５１４）、存在する場合、プロセスはステップ５０６に分岐して戻り、他のログオフ要求を生成する。そうではない場合、発行側ドメインは発行側ドメインのユーザをログオフする（ステップ５１６）。次に発行側ドメインの窓口サーバは、ログオフ状況メッセージを構築し、それをユーザに送信し（ステップ５１８）、これでログオフ・プロセスを終了する。

上記の通り、ホーム・ドメインはある依存側ドメインのための発行側ドメインとして動作することができ、その依存側ドメイン自体は他のダウンストリーム・ドメインのための発行側ドメインとして動作することができる。このため、依存側ドメインがログオフ要求を取得すると、そのドメインは図１６に示したプロセスを実行することができる。その時点で依存側ドメインは、ステップ５０４〜５１６に関する発行側ドメインと見なすことができる。しかし、そのプロセスは上記とは異なる開始および終了を行うことになるであろう。そのログオフ・プロセスを開始するために、依存側ドメインは発行側ドメインからログオフ要求メッセージを受信する（ステップ５２０）。そのログオフ・プロセスを終了するために、依存側ドメインはログオフ応答メッセージを生成し、それがログオフ要求メッセージを受信した発行側ドメインにそのログオフ応答メッセージを返す（ステップ５２２）。

代替実施形態では、発行側ドメインの窓口サーバは、そのユーザに関するログオフ要求とともに依存側ドメインの窓口サーバにＨＴＴＰメッセージを直接送信することができる。これは、依存側ドメインの窓口サーバがこの要求を受信し、その要求に含まれるユーザＩＤを有効なユーザ・セッションにマッピングできることを必要とするが、ユーザが依存側ドメイン、たとえば、ログオフ要求に付随するＨＴＴＰ Ｃｏｏｋｉｅと対話するときにユーザのセッション情報はユーザ「とともに」移動するので、これは前のケースでは「透過的に」処理されている。ユーザのセッションを識別するために使用されるクライアント側のＣｏｏｋｉｅなど、クライアント側のセッション技法が使用されている場合、この代替シナリオはユーザを完全にログアウトしない。ユーザのセッションはサーバ側で終了されることになり、ユーザが次にサーバにアクセスしようと試みたときに（そのクライアント側のセッション・トークンが自動的に期限切れになっていないと想定する）、サーバはこのトークンを明示的に期限切れにする必要があるであろう。たとえば、サーバ側にマッチング・セッション（matching session）がまったくないクライアント側のセッションＣｏｏｋｉｅをサーバが受信すると、サーバはエラーで応答し、無効になるようにそのＣｏｏｋｉｅをリセットすることにもなるであろう。いずれの場合も、発行側ドメインの窓口サーバに返される状況メッセージはステップ５２２に関して記載したものと同じであり、ユーザに返される状況ページはステップ５１８に関して記載したものと同じである。

他の代替実施形態では、ログオフ要求操作はＨＴＴＰによるＳＯＡＰを使用する。このシナリオでは、発行側ドメインの窓口サーバから依存側ドメインの窓口サーバへの要求は、ＨＴＴＰによるＳＯＡＰを使用し、ユーザのブラウザによるリダイレクトを呼び出さない。しかし、発行側ドメインの窓口サーバから受信したログオフ要求およびセキュリティ・トークンを依存側ドメインの窓口サーバのユーザに関する適切なセッション情報と突き合わせるために、依存側ドメインの窓口サーバによって、より多くの処理が行われるものと考えられる。ログオフ状況メッセージおよび応答は図１６に記載したものと同様のものになるであろう。

次に図１７を参照すると、フローチャートは、ＳＯＡＰバックチャネル方法を使用して連携ドメイン間で統合ログオフ操作を実行するためのプロセスを描写している。図１７に示した統合ログオフ操作は、たとえば、Ｗｅｂページ上のログオフ・ボタンを選択することにより、ユーザがログオフ・プロセスを呼び出したときまたはユーザがログオフ・リソースにアクセスしたときに、ユーザのホーム・ドメインで始まり（ステップ６０２）、代わって、非アクティブ・タイムアウトなどの様々な理由からホーム・ドメインによってログオフ操作を開始することもできるであろう。ホーム・ドメインは１組の他の連携ドメインのための発行側ドメインとして動作していた可能性があり、このため、ホーム・ドメインはこのプロセス内では発行側ドメインと呼ばれる場合もある。

発行側ドメインの窓口サーバは、発行側ドメインのトラスト・プロキシにログオフ試行を通知する（ステップ６０４）。トラスト・プロキシは、それがユーザのセッション中にこの特定のユーザのために連携シングル・サインオン・トークンを構築したすべてのドメインの記録を維持している。発行側ドメインのトラスト・プロキシは、それがユーザに関する連携シングル・サインオン操作中に認証アサーションを送信した依存側ドメインのリストを取得する（ステップ６０６）。発行側ドメインのトラスト・プロキシはリストから次の依存側ドメインを識別し（ステップ６０８）、発行側ドメインのトラスト・プロキシ・サーバは、識別された依存側ドメインのユーザに関するログオフ要求メッセージを生成する（ステップ６１０）。次に発行側ドメインのトラスト・プロキシは、識別された依存側ドメインのトラスト・プロキシにログオフ要求を送信する（ステップ６１２）。発行側ドメインのトラスト・プロキシは、その後、識別された依存側ドメインのトラスト・プロキシからログオフ状況メッセージを受信し、保管する（ステップ６１４）。

依存側ドメインのリスト内に他の依存側ドメインが存在するかどうかに関する決定が行われ（ステップ６１６）、存在する場合、プロセスはステップ６０８に分岐して戻り、他のログオフ要求を生成する。そうではない場合、発行側ドメインのトラスト・プロキシは発行側ドメインのユーザをログオフする（ステップ６１８）。次に発行側ドメインのトラスト・プロキシは、ログオフ状況メッセージを構築し、それを窓口サーバを介してユーザに送信し（ステップ６２０）、これでログオフ・プロセスを終了する。ユーザ・セッション管理を実行するサーバに応じて、トラスト・プロキシは、ローカル・ユーザ・トークンを構築し、ユーザのセッションを終了するためにそのユーザ用の窓口サーバでログオフ・プロセスを開始する必要がある場合があることに留意されたい。

上記の通り、ホーム・ドメインはある依存側ドメインのための発行側ドメインとして動作することができ、その依存側ドメイン自体は他のダウンストリーム・ドメインのための発行側ドメインとして動作することができる。このため、依存側ドメインがログオフ要求を取得すると、そのドメインは図１７に示したプロセスを実行することができる。その時点で依存側ドメインは、ステップ６０４〜６１８に関する発行側ドメインと見なすことができる。しかし、そのプロセスは上記とは異なる開始および終了を行うことになるであろう。そのログオフ・プロセスを開始するために、依存側ドメインは発行側ドメインからログオフ要求メッセージを受信する（ステップ６２２）。そのログオフ・プロセスを終了するために、依存側ドメインはログオフ応答メッセージを生成し、それがログオフ要求メッセージを受信した発行側ドメインにそのログオフ応答メッセージを返す（ステップ６２４）。ログオフ状況メッセージおよび応答は図１７に記載したものと同様のものになるであろう。

また、ＳＯＡＰ手法はパブリッシュ・サブスクライブ・モデルを使用することもできる。本発明では、ログオフ・イベントが発生したことをそれに通知するために、ユーザが前にログオンしたすべてのサーバに対してログオフ・イベント・ハンドラが通信できるようにするために、パブリッシュ・サブスクライブ技術を使用する。上述の手法とは対照的に、パブリッシュ・サブスクライブ・モデルでは、ユーザがログオンしたすべてのシステムの記録またはこのようなすべてのシステムと通信するための方法を有する単一エンティティが存在する。

典型的なパブリッシュ・サブスクライブ環境では、パブリッシャ（publisher）とサブスクライバ（subscriber）との関係は一般に長期間のものであり、所与の「クラス」のすべてのイベント、たとえば、すべてのログオフ・イベントまたはすべてのログオン・イベントに適用される。本発明では、一時的でコンテキスト固有のサブスクライバ関係の概念について説明する。連携環境の動的性質のため、スケーラブル・トポロジ（scalable topology）は、一時的でコンテキスト固有のイベントと、長期間の関係の両方をサポートする。

本発明では、Ｗｅｂサービスは、すべてのログオン通知などの特定のタイプのイベントに加入することができ、その後、Ｗｅｂサービスは、任意のログオン・セッションが終了した時期を決定するために、すべてのログオフ・イベントに加入することが必要になるであろう。このため、ログオフ・イベントの特定のサブセットにのみ関心がある場合でも、Ｗｅｂサービスはすべてのログオフ・イベントに加入することになるが、どのログオン・イベントが興味の対象になるかを前もって予測することは不可能であるので、これは、Ｗｅｂサービスがすべてのログオン・イベントに加入しなければならない場合のログオン・イベントに匹敵するものである。

加えて、本発明では、Ｗｅｂサービスがコンテキスト固有のイベントに加入する能力を有するように、パブリッシュ・サブスクライブ・ルールを改良することができる。したがって、シナリオの一例では、サブジェクト・ユーザ（subject user）が認証されたことが特定のＷｅｂサービスに通知されることになるであろう。このログイン・イベントを反映するようにその状態を更新することをＷｅｂサービスが選択した場合、Ｗｅｂサービスは、ユーザがログオフしたかどうかを決定するためにログオフ・イベントへの加入に興味を持つことになるであろう。すべてのログオフ・イベントに加入するようＷｅｂサービスに強制するのではなく、本発明は、Ｗｅｂサービスがコンテキスト固有のイベントに加入できるようにするものであり、すなわち、すべてのログオフ・イベントの改良により、サブジェクト・ユーザがイベントをログオフできるようにするものである。この状況では、Ｗｅｂサービス、すなわち、依存側パーティと、発行側ドメインのトラスト・プロキシ、すなわち、パブリッシング・パーティ（publishing party）とのサブスクライバ関係は、一時的なものであり、すなわち、サブジェクト・ユーザの認証済みセッションの期間中のものである。

要約すると、発行側ドメインはパブリッシャとして動作し、依存側ドメインはサブスクライバとして動作し、これにより、依存側ドメインは、発行側ドメインで発生する可能性のあるログオフ・イベントに加入することができる。ユーザのホーム・ドメインはユーザに関するログオフ・イベントを発行することになり、このイベントはこのようなログオフ・イベントに加入したすべてのドメインによって受信されることになる。次に依存側ドメインは、そのログオフ・イベントが特定のユーザに関連するかどうかを決定することができ、関連する場合、依存側ドメインはユーザのログオフまたはセッション・パージを実施する。このログオフに関する最適化手法は、依存側ドメインがより細かい細分性のログオフ・イベント、すなわち、特定のユーザに固有のログオフ・イベントに加入できるようにすることであり、したがって、依存側ドメインはすべてのログオフ・イベントを聴取する必要はなく、その特定のユーザに関するログオフ・イベントのみ聴取する必要がある。

次に図１８〜１９を参照すると、１対のフローチャートは、パブリッシュ・サブスクライブ・モデルを使用するＳＯＡＰ手法により連携ドメイン間で統合ログオフ操作を実行するための１対のプロセスを描写している。図１８および図１９に示したプロセスでは、依存側ドメインのユーザに代わって連携シングル・サインオン操作がすでに完了しており、依存側ドメインがそのユーザに関するログオフ・イベントに加入していると想定する。たとえば、依存側ドメインの窓口サーバは、依存側ドメインにおける着信要求とともに、発行側ドメインの窓口サーバから認証アサーションを受信する。依存側ドメインで発生すると考えられる処理の一部として、依存側ドメインのトラスト・プロキシはそのユーザに関するログオフ・イベントに加入することになるであろう。図１１のステップ３３２を参照すると、依存側ドメインのトラスト・プロキシが発行側ドメインからのアサーションを妥当性検査した後、トラスト・プロキシは加入操作を開始することになるが、ログオフ・イベントに含まれていると考えられるＩＤは発行側ドメインによって発行されたＩＤであるので、トラスト・プロキシは、依存側ドメイン内でローカルで有効なＩＤではなく、発行側ドメインから受信したユーザＩＤを使用することになるであろう。

図１８に示したプロセスは発行側ドメインで行われ、図１９に示したプロセスは依存側ドメインで行われる。次に図１８を参照すると、プロセスは、ユーザのホーム・ドメインなどの発行側ドメインでユーザがログオフ・イベントを開始することから始まる（ステップ７０２）。発行側ドメインの窓口サーバは発行側ドメインのトラスト・プロキシに通知し（ステップ７０４）、そのトラスト・プロキシは、発行側ドメインにおけるユーザのセッション中にそのユーザのために発行されたすべてのトークンを決定する（ステップ７０６）。各発行済みトークンごとに、発行側ドメインのトラスト・プロキシは、発行済みトークンのそれぞれに関するログオフ通知とともにＳＯＡＰ発行メッセージを生成し（ステップ７０８）、プロセスは完了する。

次に図１９を参照すると、プロセスは、依存側ドメインのトラスト・プロキシがユーザに関するログオフ・メッセージを受信することから始まる（ステップ７１２）。依存側ドメインのトラスト・プロキシは、ログオフ・メッセージ内の受信トークンに基づいて、そのユーザに関する局所的セキュリティ・トークンを作成する（ステップ７１４）。次に依存側ドメインのトラスト・プロキシは、依存側ドメインの窓口サーバから、ユーザに代わってログオフ操作を開始し（ステップ７１６）、プロセスは完了する。代わって、依存側ドメインのトラスト・プロキシがセッション管理を実行する場合、依存側ドメインのトラスト・プロキシは、適切な方法でユーザのセッションを終了することにより、ログオフ操作を完了することになるであろう。

もう一度、図１５を参照すると、ユーザが統合ログオフ操作を実行する方法を説明するために連携環境の一例が使用されている。上記の図１５の記述は、ユーザ４００がドメイン４２０および４３０でセッションを確立するために連携シングル・サインオン操作を完了する方法を説明しており、その例では、ドメイン４１０はホーム・ドメインとして動作し、ドメイン４２０および４３０は依存側ドメインとして動作する。以下の例は図１５の記述の終了から継続し、換言すれば、以下の例では、ユーザが連携シングル・サインオン操作をすでに完了しており、統合ログオフ操作の完了に取りかかっているものと想定する。

このシナリオでは、ユーザのブラウザがＷｅｂサービス対応ではなく、すなわち、Ｗｅｂサービス・クライアントとして動作しないものと想定することができる。これは、ユーザがＨＴＴＰを使用してフェデレーションにアクセスすることを示している。フェデレーションのコンポーネントは、ＳＯＡＰまたはＨＴＴＰによるＳＯＡＰを使用して通信することができる。窓口サーバとトラスト・プロキシとの通信は内部のものにすることができ、すなわち、ＡＰＩを使用するかまたはＳＯＡＰによるものにすることができる。

以下のシナリオは、図１６に示したプロセスに従うものである。ユーザ４００はドメイン４１０からログアウトする。窓口サーバ４１２は、ユーザ４００に代わってそれが連携シングル・サインオン・トークンを送信したすべてのドメインのリストを維持する。ドメイン４１０でユーザのセッションを終了する前に、窓口サーバ４１２は、ドメイン４２０のユーザに関するログオフ要求を作成する。このように実行するために、窓口サーバ４１２は、ドメイン４２０で有効なユーザ４００に関するセキュリティ・トークンをトラスト・プロキシ４１４から要求する。窓口サーバ４１２は、４１４から受信したトークンを含み、ドメイン４２０でユーザ４００をログオフするための要求を構築し、このトークンは、ログアウト要求をユーザにマッピングするために使用することができる。このバインディングは窓口サーバ４２２とのユーザのセッションの一部にもなるので、これはＨＴＴＰシナリオではあまり重要ではないが、要求をユーザにバインドすることを可能にするので、これはＳＯＡＰシナリオではより重要なものである。

窓口サーバ４１２は、ユーザのブラウザを介してドメイン４２０内の窓口サーバ４２２にこの要求をリダイレクトする。窓口サーバ４２２は、要求を受信し、ドメイン４２０内のユーザに関するログオフを呼び出そうと試みる。その結果は、成功（ユーザが認証されており、この時点でログオフされ、すべてのセッション情報が削除される）または失敗（ユーザが有効なセッションを持っていなかった）またはエラー（ユーザがセッションを持っているが、おそらく、ログオフを完了できない）になる。窓口サーバ４２２は、ユーザのブラウザによるＨＴＴＰリダイレクトを介して窓口サーバ４１２に状況メッセージを返す。次に窓口サーバ４１２は、ドメイン４３０のユーザに関するログオフ要求を構築する。窓口サーバ４１２は、ユーザのブラウザを介してドメイン４３０内の窓口サーバ４３２にこの要求をリダイレクトする。窓口サーバ４３２は、要求を受信し、ドメイン４３０内のユーザに関するログオフを呼び出そうと試み、その結果は、成功、失敗、またはエラーになる。窓口サーバ４３２は、ユーザのブラウザによるＨＴＴＰリダイレクトを介して窓口サーバ４１２に状況メッセージを返す。

ユーザのホーム・ドメインにおける窓口サーバ４１２は、ユーザのブラウザに返されるログオフ状況メッセージを構築する。ドメイン４２０とドメイン４３０の両方が成功状況標識（successful status indicator）を返す場合、窓口サーバ４１２は、ドメイン４１０内のユーザに関するログオフを実行し、図２０に示したメッセージを返す。連携ドメインのうちの１つまたは複数が成功状況標識を返さない場合、一実施形態では、窓口サーバ４１２は、ドメイン４１０のユーザに関するログオフを実行しない。その代わりに、窓口サーバ４１２は、図２１に示したメッセージを返す。

次に図２０〜２１を参照すると、フェデレーション内の統合ログオフ操作からの状況メッセージを含むグラフィカル・ユーザ・インターフェース（ＧＵＩ：graphical user interface）ウィンドウが示されている。図２０を参照すると、ウィンドウ８００は、成功した統合ログオフ操作の結果を示している。この例では、成功した統合ログオフ操作に参加していたすべてのドメインの名前８０２が示されている。

図２１を参照すると、ウィンドウ８１０は、各連携ドメインに関する統合ログオフ操作の状況を示している。名前８１２は、ユーザが正常にログアウトされたドメインを示している。名前８１４は、ユーザがアクティブ・セッションを持っていなかったドメインを示しており、たとえば、ホーム・ドメインはあるドメインのユーザに関する連携シングル・サインオン操作を実行した可能性があるが、ユーザがその後、そのドメインから直接ログアウトしたかまたは非アクティブのためにログアウトされており、それにより、ホーム・ドメインを離れているが、ユーザが依然としてそのドメインでアクティブ・セッションを持っていると考えられるという間違った表示が行われる。名前８１６は、ログアウト操作中にエラーが発生したドメインを示している。

統合ログオフ操作の状況を検討した後、統合ログオフ操作の終了に関して何が行われるかをユーザが選択できるように、いくつかのオプションがユーザに提供される。この例では、ユーザは、ユーザがホーム・ドメインからログオフを続行したいことを示すオプション８１８を選択することができる。また、ユーザは、統合ログオフ操作中にエラーが発生したドメインに移行するためにオプション８２０を選択することもできる。

もう一度、図１５を参照すると、ユーザが図１７に示したプロセスにより統合ログオフ操作を実行する方法を説明するために連携環境の一例が使用されている。ユーザ４００は、窓口サーバ４１２に（または、トラスト・プロキシ４１４が、ユーザがユーザの状態情報を伝えるかまたは維持するコンポーネントである場合、そのトラスト・プロキシに直接）ログオフ要求を送信する。窓口サーバ４１２は、ログオフ要求を構築し、そのユーザに関するセキュリティ・トークンをトラスト・プロキシ４１４から要求し、そのトラスト・プロキシは、それがこのセッションでこのユーザに関する連携シングル・サインオン・トークンを構築したすべてのドメインに関するある種の記録を維持する。トラスト・プロキシ４１４は、これらのドメインのそれぞれでユーザに関するログオフ要求を構築し、ドメイン４２０内のトラスト・プロキシ４２４およびドメイン４３０内のトラスト・プロキシ４３４にこの要求を転送する。受信側のトラスト・プロキシ、たとえば、トラスト・プロキシ４２４は、ログオフ要求を受信し、ユーザ・トークンを検証し、ローカル・ユーザ・トークンを構築し、そのユーザに関する窓口サーバ４２２でログオフ要求を開始する（または、どのコンポーネントがセッション管理を実行するかに応じて、トラスト・プロキシ４２４でユーザのセッションを終了する）。

もう一度、図１５を参照すると、ユーザが図１８〜１９に示したプロセスにより統合ログオフ操作を実行する方法を説明するために連携環境の一例が使用されている。このシナリオでは、窓口サーバ４２２（またはトラスト・プロキシ４２４）がドメイン４１０からユーザ４００に関するログオン要求を受信すると、トラスト・プロキシ４２４は「ログオフ・イベントへの加入」／「ユーザ４００に関するログオフ・イベントへの加入」を開始する。ユーザがドメイン４１０でログオフ・イベントを開始すると、窓口サーバ４１２はトラスト・プロキシ４１４に送信するためのログオフ通知を構築し、そのトラスト・プロキシは、このセッション中にそのユーザに関してそれが発行したすべてのトークンを決定し、発行済みトークンのそれぞれに関するログオフ通知とともにＳＯＡＰ発行メッセージを構築する。

たとえば、連携シングル・サインオン操作中に窓口サーバ４２２で受信されたトークンは「トークンＡ」と呼ぶことができ、他の連携シングル・サインオン操作中に窓口サーバ４３２で受信されたトークンは「トークンＢ」と呼ぶことができる。トラスト・プロキシ４１４は、ログオフ・イベントおよび「トークンＡ」を有するＳＯＡＰ発行メッセージと、ログオフ・イベントおよび「トークンＢ」を有するＳＯＡＰ発行メッセージを構築する。トラスト・プロキシ４２４は、「トークンＡ」に関連するＳＯＡＰログオフ・メッセージに加入したことになり、したがって、第１のメッセージを受信する。トラスト・プロキシ４３４は、「トークンＢ」に関連するＳＯＡＰログオフ・メッセージに加入したことになり、したがって、第２のメッセージを受信する。

トラスト・プロキシ４２４がログオフ・メッセージを受信すると、それは、受信したトークンに基づいてそのユーザに関するローカル・セキュリティ・トークンを作成する。次にトラスト・プロキシ４２４は、ユーザに代わって窓口サーバ４２２からログオフを要求する（または、セッションがトラスト・プロキシで維持されている場合、そのユーザに関してローカルで維持されているセッションからログオフしようと試みる）。

上記で提供されている本発明の詳細な説明を考慮すると、本発明の利点は明らかであるはずである。従来技術のソリューションは、ドメイン・セキュリティ・サービスを階層として編成し、それにより、ドメインは堅い信頼関係と本質的に互換性のある技術を有する必要がある。その他の手法は、認証アサーションに均一フォーマットを賦課するかまたは認証アサーションの転送を可能にせず、ときには、それからローカル・アサーションが構築される認証済みＩＤを転送する。

本発明の利点の中で、トラスト・プロキシは、所与のドメイン内の既存のセキュリティ・サービスが、同じトラスト・ルートに加入するかまたは同じ信頼確立技術を使用する必要なしに、他のドメインとの信頼関係を確立できるようにするものである。このため、本発明の連携アーキテクチャは、エンティティの疎結合を提供する。ホーム・ドメインは認証を管理し、各ドメインはそれ自体の登録済みユーザのみの認証を管理する。各ドメインは、ユーザＩＤおよび属性に関する任意の他のドメインのステートメントを自由に受諾、拒否、または変更することができる。依存側ドメインは、ＩＤおよび属性に関する発行側ドメイン（最終的に、ホーム・ドメイン）のアサーションを当てにするが、各ドメインは任意の認証プロトコルを実現することができ、そのドメインがフェデレーションに参加するために前にサポートされていないプロトコルを実現するよう所与のドメイン内のアプリケーションを変更する必要はない。フェデレーションは特定のトラスト・モデルを必要とせず、１組のエンティティは、参加エンティティがすでに確立している可能性のあるトラスト・モデルに適合するフェデレーションを形成することができる。アサーション変換は、トラスト・プロキシあるいはトラスト・ブローカまたはその両方でのみ行われ、フェデレーションのアーキテクチャは、既存のレガシー・システムに対する最小限の影響で実現可能なフロントエンド・インフラストラクチャとして動作する。

フェデレーションにより、ユーザは、シングル・サインオン方式で所与のフェデレーション内の種々のサイトをシームレスにトラバースすることができる。フェデレーション参加者間で信頼関係が確立されているので、ある参加者はあるユーザを認証し、その後、そのユーザのための発行側パーティとして動作することができる。他のフェデレーションのパートナは依存側パーティになり、それにより、そのパートナは、ユーザの直接的関与なしに発行側パーティによってユーザに関して提供される情報を当てにする。ユーザがあるドメインからログオフすることを所望し、そのドメインがそのユーザのための発行側ドメインとして動作していた場合、そのユーザに関するアクティブ・連携シングル・サインオン・セッションを持っているすべてのドメインにログオフ操作が通知され、このようなすべてのドメインが依存側ドメイン内のユーザのセッションを終了できるように、発行側ドメインは任意の依存側ドメインで統合ログオフ操作を開始する。

完全に機能するデータ処理システムに関連して本発明を説明してきたが、当業者であれば、配布を実行するために実際に使用される特定のタイプの信号運搬メディアにかかわらず、本発明のプロセスがコンピュータ可読メディア内の命令の形および様々なその他の形で配布可能であることが分かることは、留意すべき重要なことである。コンピュータ可読メディアの例としては、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フレキシブル・ディスク、ハードディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどのメディア、ならびにデジタルおよびアナログ通信リンクなどの伝送タイプのメディアを含む。

１つの方法は一般に、所望の結果に至る首尾一貫したステップのシーケンスであると考えられている。これらのステップは、物理量の物理的操作を必要とする。必ずではないが、通常、これらの量は、保管、転送、結合、比較、およびその他の操作が可能な電気信号または磁気信号の形を取る。時には、主に一般的使用の理由で、これらの信号をビット、値、パラメータ、項目、エレメント、オブジェクト、記号、文字、項、数などと呼ぶと便利である。しかし、これらの用語および同様の用語はいずれも適切な物理量に関連付けられるものであり、単にこれらの量に適用された便利なラベルにすぎないことに留意されたい。

本発明の説明は、例示のために提示されたものであり、網羅的なものまたは開示された実施形態に限定されるものではない。当業者には、多くの変更および変形が明らかになるであろう。実施形態は、本発明の原理およびその実際的な適用例を説明し、他の企図された使用法に適している可能性がある様々な変更を含む様々な実施形態を実現するために他の当業者が本発明を理解できるようにするために選択されたものである。

そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを示す図である。 本発明を実現可能なデータ処理システム内で使用できる典型的なコンピュータ・アーキテクチャを示す図である。 クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示すデータ・フロー・ダイアグラムである。 本発明を実現可能な典型的なＷｅｂベース環境を示すネットワーク・ダイアグラムを示す図である。 ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を示すブロック図である。 第１の連携企業に対してユーザによって開始され、それに応答して、連携環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関する連携環境の用語を示すブロック図である。 本発明の一実施形態により本発明の連携アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を示すブロック図である。 本発明の一実現例による連携アーキテクチャを示すブロック図である。 本発明によりトラスト・プロキシとトラスト・ブローカとを使用する連携ドメイン間の例示的な１組の信頼関係を示すブロック図である。 連携環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを示すフローチャートである。 アサーションを取り壊すための依存側ドメインにおける汎用プロセスを示すフローチャートである。 発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。 依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。 要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを示すフローチャートである。 連携シングル・サインオン操作をサポートする連携環境を示すブロック図である。 ＨＴＴＰリダイレクトを介して連携ドメイン間で統合ログオフ操作を実行するためのプロセスを示すフローチャートである。 ＳＯＡＰバックチャネル方法を使用して連携ドメイン間で統合ログオフ操作を実行するためのプロセスを示すフローチャートである。 パブリッシュ・サブスクライブ・モデルを使用するＳＯＡＰ手法により連携ドメイン間で統合ログオフ操作を実行するためのプロセスを示すフローチャートである。 パブリッシュ・サブスクライブ・モデルを使用するＳＯＡＰ手法により連携ドメイン間で統合ログオフ操作を実行するためのプロセスを示すフローチャートである。 フェデレーション内の統合ログオフ操作からの状況メッセージを含むグラフィカル・ユーザ・インターフェース（ＧＵＩ）ウィンドウを描写する図である。 フェデレーション内の統合ログオフ操作からの状況メッセージを含むグラフィカル・ユーザ・インターフェース（ＧＵＩ）ウィンドウを描写する図である。

Claims (13)

1. 複数のドメインを含む分散データ処理システム内でユーザ・セッションを管理するための方法であって、
   第１のドメイン内のシステムが、当該システム上でユーザをログオフすることを決定したことに応答して、認証アサーションを発行することにより、前記第１のドメインが前記ユーザについてのログオン操作を開始したドメインのリストを入手するステップと、
   前記第１のドメイン内のシステムが、前記リスト内の各々のドメインにつき、前記ユーザについてのログオフ要求メッセージを生成するステップであって、ログオフ要求メッセージは前記ユーザについての認証アサーションを有する、ステップと、
   前記第１のドメイン内のシステムが、前記リスト内の各々のドメインにログオフ要求メッセージを送信するステップと、を有する方法。
2. 前記第１のドメイン内のシステムが、ログオフ操作を開始するために前記ユーザによって操作されるクライアントから要求を受信するステップと、
   前記第１のドメイン内のシステムが、前記ユーザからの前記要求に基づいて前記ユーザをログオフすることを決定するステップと、をさらに有する、請求項１に記載の方法。
3. 前記第１のドメイン内のシステムが、前記ユーザに関するログオフ操作を開始するために第２のドメイン内のシステムからログオフ要求メッセージを受信するステップと、
   前記第１のドメイン内のシステムが、前記第２のドメイン内のシステムからの前記要求に基づいて前記ユーザをログオフすることを決定するステップと、をさらに有する、請求項１に記載の方法。
4. ログオフ要求メッセージがＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）発行メッセージである、請求項３に記載の方法。
5. 前記第１のドメイン内のシステムがログオフ・イベントに加入している、請求項４に記載の方法。
6. 前記第１のドメイン内のシステムが、前記ユーザ向けのログオフ・イベントに加入している、請求項４に記載の方法。
7. ログオフ要求メッセージが、連携ドメイン内の窓口サーバによって生成される、請求項１に記載の方法。
8. ログオフ要求メッセージが、連携ドメイン内のトラスト・プロキシ・サーバによって生成される、請求項１に記載の方法。
9. 前記第１のドメイン内の窓口サーバがログオフ要求メッセージから認証アサーションを抽出するステップと、
   前記第１のドメイン内の窓口サーバが前記第１のドメイン内のトラスト・プロキシに、前記抽出した認証アサーションを転送するステップと、をさらに有する、請求項１に記載の方法。
10. 前記トラスト・プロキシが、前記抽出した認証アサーションの妥当性を検査したことに応答して、前記第１のドメイン内で有効なローカル・セキュリティ・トークンを前記窓口サーバに返すステップをさらに有する、請求項９に記載の方法。
11. 前記トラスト・プロキシが、前記抽出した認証アサーションの妥当性を検査することができないという決定に応答して、前記抽出した認証アサーションの妥当性を検査するようトラスト・ブローカに要求するステップをさらに有する、請求項１０に記載の方法。
12. 複数のドメインを含む分散データ処理システムにおいて、第１のドメインでユーザ・セッションを管理するためのデータ処理システムであって、
    第１のドメイン内のシステム上でユーザをログオフすることを決定したことに応答して、認証アサーションを発行することにより、前記第１のドメインが前記ユーザについてのログオン操作を開始したドメインのリストを入手するための手段と、
    前記第１のドメイン内のシステムで、前記リスト内の各々のドメインにつき、前記ユーザについてのログオフ要求メッセージを生成するための手段であって、ログオフ要求メッセージは前記ユーザについての認証アサーションを有する、手段と、
    前記リスト内の各々のドメインにログオフ要求メッセージを送信するための手段と、を有する、データ処理システム。
13. 複数のドメインを含む分散データ処理システムにおいて、第１のドメイン内のデータ処理システム内でユーザ・セッションを管理するためのコンピュータ可読メディア内のコンピュータ・プログラムであって、前記データ処理システムを、
    第１のドメイン内のシステム上でユーザをログオフすることを決定したことに応答して、認証アサーションを発行することにより、前記第１のドメインが前記ユーザについてのログオン操作を開始したドメインのリストを入手するための手段と、
    前記第１のドメイン内のシステムで、前記リスト内の各々のドメインにつき、前記ユーザについてのログオフ要求メッセージを生成するための手段であって、ログオフ要求メッセージは前記ユーザについての認証アサーションを有する、手段と、
    前記リスト内の各々のドメインにログオフ要求メッセージを送信するための手段、として機能させるためのコンピュータ・プログラム。

Images