異機種フェデレーテッド環境におけるネイティブ認証プロトコルのための方法およびシステム
【課題】 フェデレーテッド・ドメインがフェデレーテッド環境内で対話する方法を提供することにある。
【解決手段】 あるフェデレーション内のドメインは、他のフェデレーテッド・ドメインのユーザに関するフェデレーテッド・シングル・サイン操作を開始することができる。あるドメイン内のポイントオブコンタクト・サーバは、そのドメインとフェデレーションとの間の信頼関係を管理するためにそのドメイン内のトラスト・プロキシを当てにする。トラスト・プロキシは、必要に応じて他のフェデレーテッド・ドメインからのアサーションを解釈する。トラスト・プロキシは１つまたは複数のトラスト・ブローカとの信頼関係を有することができ、トラスト・プロキシはアサーションを解釈する際の支援のためにトラスト・ブローカを当てにすることができる。
【解決手段】 あるフェデレーション内のドメインは、他のフェデレーテッド・ドメインのユーザに関するフェデレーテッド・シングル・サイン操作を開始することができる。あるドメイン内のポイントオブコンタクト・サーバは、そのドメインとフェデレーションとの間の信頼関係を管理するためにそのドメイン内のトラスト・プロキシを当てにする。トラスト・プロキシは、必要に応じて他のフェデレーテッド・ドメインからのアサーションを解釈する。トラスト・プロキシは１つまたは複数のトラスト・ブローカとの信頼関係を有することができ、トラスト・プロキシはアサーションを解釈する際の支援のためにトラスト・ブローカを当てにすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、特に、マルチコンピュータ・データ転送のための方法および装置に関する。より詳細には、本発明は、ネットワーク・コンピュータ・システムを対象とする。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、本出願人による以下の出願に関連するものである。
出願日未定（filed (TBD)）で、「Efficient browser-based identity management providingpersonal 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 Consolidated Sign-off in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４６１ＵＳ１）
【０００３】
企業は一般に、インターネットを含む様々なネットワーク全体にわたって保護リソースへのセキュア・アクセスを許可ユーザにフレンドリに提供することを望んでいる。セキュア認証メカニズムを提供することは保護リソースへの無許可アクセスのリスクを低減するが、反面、同じ認証メカニズムが保護リソースとのユーザ対話にとって障害になる場合もある。ユーザは一般に、これらのアプリケーションをサポートする特定の各システムを保護する認証の障害を意識せずに、あるアプリケーションとの対話から他のアプリケーションに移行できることを望む。
【０００４】
ユーザがより洗練されるのにつけ、ユーザの負担が削減されるようにコンピュータ・システムがその動作を調整することをユーザは期待する。このようなタイプの期待は認証プロセスにも適用される。ユーザが何らかのコンピュータ・システムによって認証されると、その認証は、そのユーザにとってほとんど見えない様々なコンピュータ・アーキテクチャ境界を意識せずに、そのユーザの作業セッション全体にわたってまたは少なくとも特定の期間の間、有効でなければならないと、ユーザが期待し得る。企業は一般に、ユーザをなだめるためだけでなく、ユーザ効率（ユーザ効率が従業員の生産性に関連するか顧客満足度に関連するかにかかわらず）を高めるためにも、その配置システムの動作特性においてこのような期待に応えようとする。
【０００５】
より具体的には、共通ブラウザによりアクセス可能なＷｅｂベース・ユーザ・インターフェースを多くのアプリケーションが有する現行コンピューティング環境により、ユーザは、より使いやすいこと、あるＷｅｂベース・アプリケーションから他のＷｅｂベース・アプリケーションへの移行に対する障害が低いかまたは少ないことを期待する。これに関連して、ユーザは、特定の各ドメインを保護する認証の障害を意識せずに、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションに移行できることを期待するようになる。しかし、多くのシステムが使いやすいＷｅｂベース・インターフェースによりセキュア認証を提供する場合でも、ユーザは依然として、１組のドメインの全域でユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れざるを得ない可能性がある。所与の時間フレーム内にユーザを複数の認証プロセスにかけることは、ユーザの効率に著しく影響する可能性がある。
【０００６】
ユーザおよびコンピュータ・システム管理者の認証負担を低減するために、様々な技法が使用されてきた。これらの技法は、ユーザがサインオン操作を完了した後、すなわち、認証された後に、そのユーザはその後、他の認証操作を実行する必要がないという共通目的があるので、一般に「シングル・サインオン」（ＳＳＯ：single-sign-on）プロセスと記述される。このため、目標は、ユーザが特定のユーザ・セッション中に１つの認証プロセスのみ完了することを要求されるであろうということである。
【０００７】
このようなシングル・サインオン・ソリューションは、所与の企業内で実現したときは上首尾であった。しかし、より多くの企業がインターネットによって接続されたｅ−ｃｏｍｍｅｒｃｅマーケットプレイスまたはその他のコラボレーション努力に参加するにつれて、複数の認証プロセスまたはシステムによって提起される障害はますます一般的なものになっている。企業間の以前のシングル・サインオン・ソリューションは、参加企業間の事業協定が事前に確立されている同種環境に限られていた。これらの事業協定は、部分的に、信頼を確立し、企業間で情報を安全に転送する方法を制限し定義するために使用される。また、これらの事業協定は、ある企業から他の企業にユーザＩＤ（identity）を変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。
【０００８】
換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合が可能である。
【０００９】
参加企業はこれらの以前のシングル・サインオン・ソリューションを使用することにより同種環境内で協働することができるが、複数の同種環境、たとえば、相互接続ｅ−ｃｏｍｍｅｒｃｅマーケットプレイスを相互接続する必要性または要望を考慮すると、これらの環境は限定的なものである。
【特許文献１】出願日未定（filed (TBD)）で、「Efficient browser-based identity management providingpersonal 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 Consolidated Sign-off in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４６１ＵＳ１）
【非特許文献１】１９９３年９月発行のInternetEngineering Task Force (IETF) Request for Comments (RFC) 1510に掲載されたＫｏｈｌ他による「TheKerberos Network Authentication Service (V5)」
【非特許文献２】２００２年５月３１日発行のCommitteeSpecification 01に掲載された「Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML)」
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、参加企業間の所定の事業および技術変換協定がない場合に企業がユーザに対して同様のシングル・サインオン経験を提供できる方法およびシステムを備えることは有利なことになるであろう。
【課題を解決するための手段】
【００１１】
フェデレーテッド（federated）ドメインがフェデレーテッド環境内で対話する方法、装置、システム、およびコンピュータ・プログラムが提示される。あるフェデレーション（federation）内のドメインは、他のフェデレーテッド・ドメインのユーザに関するフェデレーテッド・シングル・サイン操作を開始することができる。あるドメイン内のポイントオブコンタクト（point-of-contact）サーバは、そのドメインとフェデレーションとの間の信頼関係を管理するためにそのドメイン内のトラスト・プロキシ（trustproxy）を当てにする。トラスト・プロキシは、必要に応じて他のフェデレーテッド・ドメインからのアサーションを解釈する。トラスト・プロキシは１つまたは複数のトラスト・ブローカ（trustbroker）との信頼関係を有することができ、トラスト・プロキシはアサーションを解釈する際の支援のためにトラスト・ブローカを当てにすることができる。
【００１２】
本発明に特有と思われる新規の特徴は特許請求の範囲に示されている。本発明そのもの、その他の目的、およびその利点は、添付図面に併せて読んだときに以下に示す詳細な説明を参照することにより最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１３】
一般に、本発明を含むかまたは本発明に関する可能性のある装置は多様なデータ処理技術を含む。したがって、本発明をより詳細に説明する前に、背景として、分散データ処理システム内のハードウェアおよびソフトウェア・コンポーネントの典型的な編成について説明する。
【００１４】
次に添付図面を参照すると、図１は、そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを描写している。分散データ処理システム１００はネットワーク１０１を含み、そのネットワークは、分散データ処理システム１００内で一緒に接続された様々な装置およびコンピュータ間の通信リンクを提供するために使用できるメディアである。ネットワーク１０１は、ワイヤもしくは光ファイバ・ケーブルなどの永続接続または電話もしくはワイヤレス通信により行われる一時接続を含むことができる。描写した例では、サーバ１０２およびサーバ１０３は、ストレージ・ユニット１０４とともにネットワーク１０１に接続されている。加えて、クライアント１０５〜１０７もネットワーク１０１に接続されている。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ：personal digital assistant）などの多様なコンピューティング・デバイスによって表すことができる。分散データ処理システム１００は、図示されていない追加のサーバ、クライアント、ルータ、その他の装置、およびピアツーピア・アーキテクチャを含むことができる。
【００１５】
描写した例では、分散データ処理システム１００は、ＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル（TransportControl Protocol/Internet Protocol））、ＨＴＴＰ（ハイパーテキスト転送プロトコル（HyperText TransportProtocol））などの様々なプロトコルを使用して互いに通信するネットワークおよびゲートウェイの世界的な集合を表すネットワーク１０１とともにインターネットを含むことができる。当然のことながら、分散データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：localarea network）、または広域ネットワーク（ＷＡＮ：wide area network）などのいくつかの異なるタイプのネットワークも含むことができる。たとえば、サーバ１０２はクライアント１０９およびネットワーク１１０を直接サポートし、そのネットワークはワイヤレス通信リンクを組み込んでいる。ネットワーク対応電話（network-enabledphone）１１１はワイヤレス・リンク１１２によりネットワーク１１０に接続し、ＰＤＡ１１３はワイヤレス・リンク１１４によりネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワーク（personalad-hoc network）を作成するために、Ｂｌｕｅｔｏｏｔｈ（商標）ワイヤレス技術などの適切な技術を使用して、ワイヤレス・リンク１１５を越えて両者間でデータを直接転送することもできる。同様に、ＰＤＡ１１３は、ワイヤレス通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。
【００１６】
本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実現することができるであろう。図１は、本発明に関するアーキテクチャ制限としてのものではなく、異機種コンピューティング環境の一例としてのものである。
【００１７】
次に図２を参照すると、同図は、本発明を実現可能な、図１に示したものなどのデータ処理システムの典型的なコンピュータ・アーキテクチャを描写している。データ処理システム１２０は、内部システム・バス１２３に接続された１つまたは複数の中央演算処理装置（ＣＰＵ：central processing unit）１２２を含み、その内部システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ：randomaccess memory）１２４、読取り専用メモリ１２６、および入出力アダプタ１２８を相互接続し、その入出力アダプタ１２８は、プリンタ１３０、ディスク・ユニット１３２、またはオーディオ出力システムなどの図示していないその他の装置などの様々な入出力装置をサポートする。また、システム・バス１２３は、通信リンク１３６へのアクセスを可能にする通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０とマウス１４２、またはタッチ・スクリーン、スタイラス、マイクロホンなどの図示していないその他の装置などの様々なユーザ装置を接続する。ディスプレイ・アダプタ１４４はシステム・バス１２３をディスプレイ装置１４６に接続する。
【００１８】
当業者であれば、図２のハードウェアはシステム実現例に応じて様々になる可能性があることが分かるであろう。たとえば、システムは、Ｉｎｔｅｌ（商標）のＰｅｎｔｉｕｍ（商標）ベースのプロセッサおよびデジタル・シグナル・プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性および不揮発性メモリとを有する可能性がある。図２に描写したハードウェアに加えてまたはその代わりに、その他の周辺装置を使用することもできる。描写した例は、本発明に関するアーキテクチャ制限を示すためのものではない。
【００１９】
様々なハードウェア・プラットフォームで実現できることに加えて、本発明は、様々なソフトウェア環境で実現することができる。各データ処理システム内のプログラム実行を制御するために、典型的なオペレーティング・システムを使用することができる。たとえば、ある装置はＵｎｉｘ（商標）オペレーティング・システムを実行することができ、他の装置は単純なＪａｖａ（商標）ランタイム環境を含む。代表的なコンピュータ・プラットフォームはブラウザを含むことができ、そのブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ：Extensible Markup Language）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：Hypertext MarkupLanguage）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ：Handheld Device Markup Language）、ワイヤレス・マークアップ言語（ＷＭＬ：WirelessMarkup Language）、および様々なその他のフォーマットおよびタイプのファイルなど、様々なフォーマットのハイパーテキスト・ドキュメントにアクセスするための周知のソフトウェア・アプリケーションである。また、図１に示した分散データ処理システムは、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されていることにも留意されたい。
【００２０】
次に図３を参照すると、データ・フロー・ダイアグラムは、クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示している。図示した通り、クライアント・ワークステーション１５０側のユーザは、クライアント・ワークステーション上で実行されるユーザのＷｅｂブラウザにより、コンピュータ・ネットワークを越えてサーバ１５１上の保護リソースにアクセスしようとする。保護リソースは、認証許可ユーザのみによってアクセス可能なユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）、またはより一般的には、ユニフォーム・リソース・アイデンティファイア（ＵＲＬ：UniformResource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示した通り、インターネット、イントラネット、またはその他のネットワークにすることができ、サーバは、Ｗｅｂアプリケーション・サーバ（ＷＡＳ：WebApplication Server）、サーバ・アプリケーション、サーブレット・プロセスなどにすることができる。
【００２１】
プロセスは、ユーザが「ｉｂｍ．ｃｏｍ」というドメイン内のＷｅｂページなどの保護リソースを要求したときに開始される（ステップ１５２）。Ｗｅｂブラウザ（または関連アプリケーションもしくはアプレット）は、「ｉｂｍ．ｃｏｍ」というドメインをホストとして処理するＷｅｂサーバに送信されるＨＴＴＰ要求メッセージを生成する（ステップ１５３）。サーバは、それがクライアントに関するアクティブ・セッションを持っていないと判断し（ステップ１５４）、したがって、サーバは、何らかのタイプの認証質問（authentication challenge）をクライアントに送信することにより（ステップ１５５）、認証プロセスを実行するようユーザに要求する。認証質問は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）形式などの様々なフォーマットにすることができる。次にユーザは、ユーザＩＤおよび関連パスワードなどの要求された情報または必要な情報を提供する（ステップ１５６）か、またはクライアントは特定の情報を自動的に返す場合もある。
【００２２】
認証応答情報はサーバに送信され（ステップ１５７）、その時点でサーバは、たとえば、前にサブミットされた登録情報を検索し、提示された認証情報とユーザの保管情報とを突き合わせることにより、ユーザまたはクライアントを認証する（ステップ１５８）。認証が成功したと想定して、認証ユーザまたはクライアントに関するアクティブ・セッションが確立される。
【００２３】
次にサーバは、要求されたＷｅｂページを検索し、ＨＴＴＰ応答メッセージをクライアントに送信する（ステップ１５９）。その時点でユーザは、ハイパーテキスト・リンクをクリックすることによりブラウザ内で「ｉｂｍ．ｃｏｍ」内の他のページを要求することができ（ステップ１６０）、ブラウザは他のＨＴＴＰ要求をサーバに送信する（ステップ１６１）。その時点でサーバは、ユーザがアクティブ・セッションを持っていることを認識し（ステップ１６２）、サーバは他のＨＴＴＰ応答メッセージで要求されたＷｅｂページをクライアントに返送する（ステップ１６３）。図３は典型的な従来技術のプロセスを描写しているが、アクティブ・セッションを備えたユーザを識別するためにＣｏｏｋｉｅを使用することなど、他の代替セッション状態管理技法を描写することもでき、認証を証明するために使用されるのと同じＣｏｏｋｉｅを使用することを含む可能性もあることに留意されたい。
【００２４】
次に図４を参照すると、ネットワーク・ダイアグラムは、本発明を実現可能な典型的なＷｅｂベース環境を示している。この環境では、クライアント１７１側のブラウザ１７０のユーザは、ＤＮＳドメイン１７３内のＷｅｂアプリケーション・サーバ１７２上またはＤＮＳドメイン１７５内のＷｅｂアプリケーション・サーバ１７４上の保護リソースにアクセスすることを所望する。
【００２５】
図３に示したものと同様に、ユーザは多くのドメインのうちの１つで保護リソースを要求することができる。特定のドメインにおいて単一サーバのみを示す図３とは対照的に、図４の各ドメインは複数のサーバを有する。特に、各ドメインは関連認証サーバ１７６および１７７を有することができる。
【００２６】
この例では、クライアント１７１がドメイン１７３で保護リソースに関する要求を発行した後、Ｗｅｂアプリケーション・サーバ１７２は、それがクライアント１７１に関するアクティブ・セッションを持っていないと判断し、認証サーバ１７６がクライアント１７１との適切な認証操作を実行することを要求する。認証サーバ１７６は、認証操作の結果をＷｅｂアプリケーション・サーバ１７２に伝達する。ユーザ（またはユーザに代わってブラウザ１７０またはクライアント１７１）が正常に認証された場合、Ｗｅｂアプリケーション・サーバ１７２は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。概して、ユーザが認証サーバによって認証されると、Ｃｏｏｋｉｅを設定し、それをブラウザ内のＣｏｏｋｉｅキャッシュに保管することができる。図４は単に、特に認証操作を実行するために、あるドメインの処理リソースを複数サーバ間で共用できる方法の一例に過ぎない。
【００２７】
同様に、クライアント１７１がドメイン１７５で保護リソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証操作を実行し、その後、Ｗｅｂアプリケーション・サーバ１７４は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。
【００２８】
このため、図４は、クライアント１７１が異なるドメインにおける複数の並行セッションを持つことができるが、それらの並行セッションを確立するために複数の認証操作を完了する必要があることを示している。
【００２９】
次に図５を参照すると、ブロック図は、ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を描写している。もう一度、図３および図４を参照すると、ユーザは、図３に示した通り、被制御リソースにアクセスする前に認証操作を完了する必要がある可能性がある。図３に示していないが、ユーザを認証するために必要なユーザ情報を検索し使用するために、サーバ１５１上に認証マネージャを配置することができる。図４に示した通り、ユーザは異なるドメイン１７３および１７５内で複数の現行セッションを持っている可能性があり、それらは図４に示されていないが、各ドメインは、認証サーバの代わりにまたはそれに加えて認証マネージャを使用することができる。同様に、図５は１組のドメインも描写しており、そのそれぞれは何らかのタイプの認証マネージャをサポートする。図５は、各ドメインに関する認証操作を完了することをユーザに要求する複数のドメインにアクセスするときにユーザが経験する可能性のある障害のいくつかを示している。
【００３０】
ユーザ１９０はＩＳＰドメイン１９１で登録することができ、そのドメイン１９１は、ドメイン１９１に関するトランザクションを完了するためにユーザ１９０を認証する認証マネージャ１９２をサポートすることができる。ＩＳＰドメイン１９１は、インターネット接続サービス、Ｅメール・サービス、およびおそらくその他のｅ−ｃｏｍｍｅｒｃｅサービスを提供するインターネット・サービス・プロバイダ（ＩＳＰ：Internet Service Provider）にすることができる。代わって、ＩＳＰドメイン１９１は、ユーザ１９０によって頻繁にアクセスされるインターネット・ポータルにすることもできる。
【００３１】
同様に、ドメイン１９３、１９５、および１９７は、典型的なＷｅｂサービス・プロバイダを表している。行政ドメイン１９３は、様々な行政関連トランザクションを完了するためにユーザを認証する認証マネージャ１９４をサポートする。銀行用ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する認証マネージャ１９６をサポートする。ｅ−ｃｏｍｍｅｒｃｅドメイン１９７は、オンライン購入を完了するためにユーザを認証する認証マネージャ１９８をサポートする。
【００３２】
上記の通り、異なるドメインでリソースにアクセスすることにより、ユーザがインターネットまたはワールド・ワイド・ウェブ内のあるドメインから他のドメインに移動しようと試みる場合、ユーザは、複数のユーザ認証要求または要件にかけられる可能性があり、それは１組のドメインの全域でユーザの進行を著しく遅らせる可能性がある。例示的な環境として図５を使用すると、ユーザ１９０は、少なくとも１８歳であり、有効な運転免許証、有効なクレジット・カード、および米国銀行預金口座を有するユーザに制限されているオンライン・サービスをユーザが購入しようと試みているｅ−ｃｏｍｍｅｒｃｅドメイン１９７との複雑なオンライン・トランザクションに関係する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７を伴う可能性がある。
【００３３】
概して、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内のＩＤを維持していない可能性がある。この例では、ユーザ１９０は、そのユーザのＩＳＰに自分のＩＤを登録している可能性があるが、オンライン・トランザクションを完了するためには、ユーザは、ドメイン１９３、１９５、および１９７に対する認証も受ける必要がある可能性がある。それぞれのドメインがそのユーザに関するＩＤを維持していない場合、そのユーザのオンライン・トランザクションは失敗する可能性がある。ユーザが各ドメインによって認証される場合でも、そのユーザのトランザクションを完了するために異なるドメインがそれらの間で情報を転送できることは保証されていない。図５に示したユーザ１９０の場合、シングル・サインオンのために、ユーザ１９０が第１のＷｅｂサイト、たとえば、ＩＳＰ１９１に対する認証を受け、次にドメイン１９３、１９５、および１９７などの他のＷｅｂサービス・プロバイダに認証トークンを転送できるようにする従来技術の環境はまったく存在しない。
【００３４】
何らかの現行技術に関する前述の簡単な説明を考慮すると、残りの図面の説明は、本発明が機能しうるフェデレーテッド・コンピュータ環境に関するものである。しかし、本発明をより詳細に論ずる前に、いくつかの用語について紹介する。
【００３５】
用語
「エンティティ」または「パーティ」という用語は一般に、ある組織、個人、またはシステムに代わって機能する組織、個人、または他のシステムを指す。「ドメイン」という用語はネットワーク環境内の追加の特性を意味するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は区別なく使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（ドメイン・ネーム・システム）ドメイン、またはより一般的に、外部エンティティにとって論理装置として現れる様々なデバイスおよびアプリケーションを含むデータ処理システムも指すことができる。
【００３６】
「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、またはその他の関連情報など、特定の操作に関係する情報の転送に適切なデータ・フォーマットを含むものと理解しなければならない。保護リソースは、それに関するアクセスが制御または制限されるリソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、またはその他の計算リソース、通信タイプのリソースなど）である。
【００３７】
トークンは、正常動作の直接的証拠を提供し、操作を実行するエンティティによって生成され、たとえば、認証トークンは正常認証操作後に生成される。Ｋｅｒｂｅｒｏｓトークンは、本発明で使用可能な認証トークンの一例である。Ｋｅｒｂｅｒｏｓに関する詳細は、１９９３年９月発行のInternet Engineering Task Force (IETF) Request for Comments (RFC)1510に掲載されたＫｏｈｌ他による「The Kerberos Network Authentication Service (V5)」で見つけることができる。
【００３８】
アサーション(assertion)は、何らかのアクションの間接的証拠を提供する。アサーションは、ＩＤ、認証、属性、許可決定、その他の情報あるいは操作またはその両方の間接的証拠を提供することができる。認証アサーションは、認証サービスではないが、認証サービスを聴取したエンティティによる認証の間接的証拠を提供する。
【００３９】
セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ：Security Assertion Markup Language）アサーションは、本発明内で使用可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利グローバル・コンソーシアムであるＯｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって公布されたものである。ＳＡＭＬは、２００２年５月３１日発行のCommitteeSpecification 01に掲載された「Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML)」に記載されている。
【００４０】
セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）は、セキュリティ情報を交換するためのＸＭＬベースのフレームワークである。このセキュリティ情報はサブジェクトに関するアサーションの形で表され、サブジェクトは何らかのセキュリティ・ドメイン内のＩＤを有するエンティティ（人またはコンピュータのいずれか）である。サブジェクトの典型的な例は、特定のインターネットＤＮＳドメイン内の自分のＥメール・アドレスによって識別される人である。アサーションは、サブジェクトによって実行される認証行為、サブジェクトの属性、およびサブジェクトが特定のリソースにアクセスできるかどうかに関する許可決定に関する情報を搬送することができる。アサーションは、ＸＭＬ構成体として表され、ネストされた構造を有し、それにより、単一アサーションは認証、許可、および属性に関する数種類の内部ステートメントを含む可能性がある。認証ステートメントを含むアサーションは単に前に発生した認証の行為を記述するに過ぎないことに留意されたい。アサーションは、ＳＡＭＬ機関、すなわち、認証機関、属性機関、およびポリシー決定点（policy decision point）によって発行される。ＳＡＭＬは、それによりクライアントがＳＡＭＬ機関からアサーションを要求し、ＳＡＭＬ機関からの応答を取得できるプロトコルを定義する。このプロトコルは、ＸＭＬベースの要求および応答メッセージ・フォーマットからなり、多種多様な基礎となる通信およびトランスポート・プロトコルにバインドすることができ、現在、ＳＡＭＬはＨＴＴＰによるＳＯＡＰへのバインディングを定義する。ＳＡＭＬ機関は、その応答を作成する際に、外部ポリシー・ストアや、要求において入力として受信したアサーションなどの様々な情報ソースを使用することができる。したがって、クライアントは常にアサーションを消費するが、ＳＡＭＬ機関はアサーションの作成者と消費者のいずれにもなりうる。
【００４１】
ＳＡＭＬ規格では、アサーションは発行者によって作成された１つまたは複数のステートメントを提供する情報のパッケージであることを示している。ＳＡＭＬにより、発行者は、指定のサブジェクトが特定の時期に特定の手段によって認証されたという認証、指定のサブジェクトが指定のリソースにアクセスできるようにするための要求が認可または拒否されたという許可、および指定のサブジェクトが提供された属性に関連付けられる属性という３種類のアサーション・ステートメントを作成することができる。以下に詳述する通り、必要なときに、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することができる。
【００４２】
認証は、ユーザによってまたはユーザに代わって提供される１組の信用証明情報（credential）を妥当性検査するプロセスである。認証は、ユーザが把握しているもの、ユーザが持っているもの、またはユーザが何者であるか、すなわち、ユーザに関する何らかの物理的特性を検証することによって実施される。ユーザが把握しているものとしては、ユーザのパスワードなど、または特定のユーザにのみ把握されているものを検証することにより、ユーザの暗号鍵などの共有秘密鍵（sharedsecret）を含むことができる。ユーザが持っているものとしては、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特性としては、指紋または網膜マップなどのバイオメトリック入力を含むことができるであろう。
【００４３】
認証信用証明情報は、様々な認証プロトコルで使用される１組の質問／応答情報である。たとえば、ユーザ名とパスワードの組合せは、最も普通の形式の認証信用証明情報である。他の形式の認証信用証明情報としては、様々な形式の質問／応答情報、公開鍵インフラストラクチャ（ＰＫＩ：Public Key Infrastructure）証明書、スマートカード、バイオメトリクスなどを含むことができる。認証信用証明情報は認証アサーションとは差異化され、すなわち、認証信用証明情報は認証サーバまたはサービスとの認証プロトコル・シーケンスの一部としてユーザによって提示されるものであり、認証アサーションはユーザの認証信用証明情報の正常な提示および妥当性検査に関するステートメントであって、その後、必要なときにエンティティ間で転送されるものである。
【００４４】
従来技術のシングル・サインオン・ソリューションの区別
上記の通り、従来技術のシングル・サインオン・ソリューションは、参加企業間で事業協定が事前確立されている同種環境に制限されている。これらの事業協定は、信頼を確立し、企業間の安全な情報転送を定義する。また、これらの事業協定は、ある企業から他の企業にユーザＩＤを変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。
【００４５】
換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合は可能である。
【００４６】
本発明のフェデレーション・モデル
ワールド・ワイド・ウェブに関連して、ユーザは、特定の各ドメイン間の情報バリアを最小限に考慮して、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションにジャンプする能力を期待するようになる。ユーザは、単一トランザクションの場合に複数のドメインに対する認証を受けなければならないことによって引き起こされる欲求不満を望まない。換言すれば、ユーザは複数組織が相互運用することを期待するが、ユーザは一般に複数ドメインがユーザのプライバシを尊重することを希望する。加えて、ユーザは、私有情報を永続的に保管するドメインを制限する方を好む可能性がある。このようなユーザの期待は、多くの企業および組織が競合する認証技法を公布している、急速進化中の異機種環境に存在する。
【００４７】
従来技術のシステムとは対照的に、本発明は、特定の企業間の特定の事前確立された事業および技術協定がない場合に企業がユーザに対してシングル・サインオン経験を提供できるようにするためのフェデレーション・モデルを提供する。換言すれば、本発明は、フェデレーテッド異機種環境をサポートする。本発明の目的の一例として、もう一度、図５を参照すると、ユーザ１９０は、ドメイン１９１に対する認証を受け、トランザクションに関係する可能性のある各ダウンストリーム・ドメインに対し適切なアサーションをドメイン１９１から提供してもらうことができる。これらのダウンストリーム・ドメインは、ドメイン１９１と他のダウンストリーム・ドメインとの間に事前確立されたアサーション・フォーマットがまったくない場合でも、認証アサーションあるいはその他のタイプのアサーションまたはその両方を理解し信頼できることが必要である。アサーションを認識することに加えて、ダウンストリーム・ドメインは、事前確立されたＩＤマッピング関係がまったくない場合でも、アサーション内に含まれるＩＤを、特定のドメイン内のユーザ１９０を表すＩＤに変換できることが必要である。
【００４８】
本発明は、フェデレーテッド環境を対象とする。一般に、企業は、独自のユーザ・レジストリを有し、独自のユーザ・セットとの関係を維持する。各企業は概して、これらのユーザを認証する独自の手段を有する。しかし、本発明のフェデレーテッド方式により、複数の企業は、ある企業が企業フェデレーションに参加することによりその企業のユーザが１組の企業との関係を強化できるように、集合的に協働することができる。ユーザは、各企業との直接的関係を有する場合と同様に、フェデレーテッド企業のうちのいずれかの企業側のリソースへのアクセスが許可される可能性がある。ユーザは、関心のある各事業に登録する必要はなく、自分自身を識別し認証することを絶えず要求されるわけではない。このため、このフェデレーテッド環境内では、認証方式により、情報技術において急速進化中の異機種環境内のシングル・サインオン経験が可能になる。
【００４９】
本発明では、フェデレーションは、シングル・サインオンの使いやすい経験をユーザに提供するために協働する、企業、組織、団体などの１組の別個のエンティティである。本発明では、フェデレーテッド環境は、２つの企業がユーザに関するどの情報をどのように転送するかを定義する直接的で事前確立された関係を有する必要がないという点で、典型的なシングル・サインオン環境とは異なる。フェデレーテッド環境内のエンティティは、ユーザを認証すること、他のエンティティによって提示される認証アサーション、たとえば、認証トークンを受諾すること、ならびに保証対象のユーザ（vouched-for user）のＩＤをローカル・エンティティ内で理解されるものに変換する何らかの形式の変換を提供することを扱うサービスを提供する。
【００５０】
フェデレーションは、サービス・プロバイダの管理負担を緩和する。サービス・プロバイダは、全体としてフェデレーションに関するその信頼関係を当てにすることができ、ユーザの認証ホーム・ドメインによって実施される認証を当てにすることができるので、ユーザ・パスワード情報などの認証情報を管理する必要がない。
【００５１】
また、本発明は、疎結合の認証サービス、ユーザ登録サービス、ユーザ・プロファイル管理サービス、あるいは許可サービスまたはこれらのサービスの組合せがセキュリティ・ドメインの全域でコラボレーションする基礎を確立するフェデレーテッドＩＤ管理システムにも関係する。フェデレーテッドＩＤ管理により、まったく異なる複数のセキュリティ・ドメインに常駐するサービスは、これらのまったく異なる複数ドメインにおいて基礎となるセキュリティ・メカニズムおよびオペレーティング・システム・プラットフォームに相違点が存在する可能性がある場合でも、安全に相互運用しコラボレーションすることができる。ユーザがフェデレーションへの参加を確立すると、シングル・サインオン経験が確立される。
【００５２】
ホーム・ドメイン、発行側パーティ（issuingparty）、および依存側パーティ（relying party）
以下により詳細に説明する通り、本発明は、ユーザにとって重大な利点をもたらすものである。本発明により、ユーザは、以下でユーザのホーム・ドメインまたは認証ホーム・ドメインとも呼ばれる第１のエンティティで認証を受けることができる。この第１のエンティティは、第２のエンティティで使用するためにユーザに関する認証アサーションを発行する発行側パーティとして動作することができる。次にユーザは、第２のエンティティで明示的に再認証を受ける必要なしに、第１のエンティティによって発行された認証アサーションを提示することにより、依存側パーティと呼ばれる第２の別個のエンティティで保護リソースにアクセスすることができる。発行側パーティから依存側パーティに渡される情報はアサーションの形になっており、このアサーションは、種々のタイプの情報をステートメントの形で含むことができる。たとえば、あるアサーションは、あるユーザの認証済みＩＤに関するステートメントである場合もあれば、特定のユーザに関連するユーザ属性情報に関するステートメントである場合もある。
【００５３】
次に図６を参照すると、ブロック図は、第１のフェデレーテッド企業に対してユーザによって開始され、それに応答して、フェデレーテッド環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関するフェデレーテッド環境の用語を描写している。図６は、所与のフェデレーテッド操作に関するフェデレーション内のエンティティの視点（perspective）に応じて用語が異なる可能性があることを示している。ユーザ２０２は、企業２０４の保護リソースに関する要求によりトランザクションを開始する。ユーザ２０２が企業２０４によってすでに認証されている場合、企業２０４は、このフェデレーテッド・セッション用のユーザのホーム・ドメインになる。このトランザクションが企業２０６による何らかのタイプの操作を必要とし、企業２０４が企業２０６にアサーションを転送すると想定すると、企業２０４はその特定の操作に関する発行側ドメインになり、企業２０６はその操作に関する依存側ドメインになる。このトランザクションが他の操作を必要とし、企業２０６が企業２０８にアサーションを転送すると想定すると、企業２０６は要求された操作に関する発行側ドメインになり、企業２０８はその操作に関する依存側ドメインになる。
【００５４】
本発明のフェデレーテッド環境では、ユーザが認証を受けるドメインは、ユーザの（認証）ホーム・ドメインと呼ばれる。ホーム・ドメインは認証信用証明情報を維持する。ホーム・ドメインは、ユーザの雇用主、ユーザのＩＳＰ、またはその他の何らかのサービス・プロバイダである可能性がある。ユーザの認証信用証明情報を生成し妥当性検査する能力を有する企業が複数存在する可能性があるので、ユーザのホーム・ドメインとして動作できる企業がフェデレーテッド環境内に複数存在する可能性があることは起こり得ることである。
【００５５】
認証の視点によると、認証アサーションに関する発行側パーティは通常、ユーザの認証ホーム・ドメインである。ユーザのホーム・ドメインは、そのユーザに関する個人情報またはプロファイル情報を維持する場合もあれば、維持しない場合もある。このため、個人的に識別可能な情報、パーソナライゼーション情報、またはその他のユーザ属性を伴う属性の視点によると、属性アサーションに関する発行側パーティは、そのユーザの認証ホーム・ドメインである場合もあれば、そうではない場合もある。混乱を回避するため、属性ホーム・ドメインおよび認証ホーム・ドメインについて別々の用語を使用することができるが、以下の「ホーム・ドメイン」という用語は、認証ホーム・ドメインを指すものと解釈することができる。
【００５６】
しかし、所与のフェデレーテッド・セッションの範囲内では、通常、ユーザのホーム・ドメインとして動作するドメインは１つだけである。ユーザがこのドメインに対して認証を受けると、そのフェデレーション内の他のすべてのドメインまたは企業は、そのセッションの期間中、依存側パーティとして扱われる。
【００５７】
既存の非フェデレーテッド・アーキテクチャに及ぼす影響を最小限にしながら、既存のシステムに追加可能なフェデレーテッド・インフラストラクチャを本発明が提供することを考慮すると、ユーザのホーム・ドメインにおける認証は、ホーム・ドメインもフェデレーテッド環境に参加可能であることによって変更されることはない。換言すれば、本発明により実現されるフェデレーテッド環境にホーム・ドメインを統合できる場合でも、ユーザは、ユーザのホーム・ドメインで認証操作を実行しながら、同じエンドユーザ経験を持たなければならない。しかし、所与の企業のユーザのすべてが必ずしもフェデレーテッド環境に参加するわけではないことに留意されたい。
【００５８】
その上、ユーザ登録、たとえば、ユーザ・アカウントの確立は、ホーム・ドメインもフェデレーテッド環境に参加可能であることによって変更されることはない。ユーザは、フェデレーテッド環境とは無関係の登録プロセスによりドメインでアカウントを確立する。換言すれば、ホーム・ドメインにおけるユーザ・アカウントの確立は、フェデレーションの全域で有効なアカウント情報、たとえば、ＩＤ変換情報の確立を含まない。ユーザを認証できる単一フェデレーテッド・ドメインが存在する場合、すなわち、ユーザが登録したフェデレーション内のドメインが１つだけである場合、このドメインは常にユーザのホーム・ドメインとして動作することになり、フェデレーテッド環境全体にわたってユーザの移動を指図することができる。
【００５９】
ユーザが１つのフェデレーテッド環境内で可能なホーム・ドメインを複数持っている場合、ユーザは２つ以上のエントリ・ポイントを介してそのフェデレーションに入ることができる。換言すれば、ユーザは複数のドメインでアカウントを持つことができ、これらのドメインは必ずしも他のドメインまたは他のドメインにおけるユーザのＩＤに関する情報を持っているわけではない。
【００６０】
ユーザが認証を受けるドメインはホーム・ドメインと呼ばれるが、発行側ドメインは、他のドメイン、すなわち、依存側ドメインによる使用のためにアサーションを発行するフェデレーション・エンティティである。発行側ドメインは、通常、ユーザのホーム・ドメインであるが、必ずそうであるわけではない。このため、通常、発行側パーティが、前述の通り、典型的な認証プロトコルによりすでにユーザを認証していることが実情になるであろう。しかし、発行側が前に依存側パーティとして動作しており、それにより、異なる発行側パーティからアサーションを受信したことは起こり得ることである。換言すれば、ユーザが開始したトランザクションはフェデレーテッド環境内の一連の企業によりカスケードすることができるので、受信側パーティは、その後、ダウンストリーム・トランザクションに関する発行側パーティとして動作することができる。一般に、ユーザに代わって認証アサーションを発行する能力を有するドメインは発行側ドメインとして動作することができる。
【００６１】
依存側ドメインは、発行側パーティからアサーションを受信するドメインである。依存側パーティは、ユーザに代わるサード・パーティ、すなわち、発行側ドメインによって発行されるアサーションを受諾し、信頼し、理解することができる。一般に、適切な認証機関を使用して認証アサーションを解釈することは依存側パーティの義務である。加えて、依存側パーティが特定のユーザを認証できる、すなわち、ユーザのホーム・ドメインとして動作できることは起こり得ることであるが、依存側パーティが従来の方法により特定のユーザを認証できない可能性があることも起こり得ることである。このため、依存側パーティは、ユーザによって提示される認証アサーションを当てにするドメインまたは企業であって、ユーザとの対話式セッションの一部としてユーザの認証信用証明情報の入力をユーザに促す代わりに、ユーザにシングル・サインオン経験を提供するドメインまたは企業である。
【００６２】
フェデレーテッド・アーキテクチャ――レガシー・システム用のフェデレーテッド・フロントエンド
次に図７を参照すると、ブロック図は、本発明の一実施形態により本発明のフェデレーテッド・アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を描写している。フェデレーテッド環境は、ユーザに様々なサービスを提供するフェデレーテッド・エンティティを含む。ユーザ２１２は、ブラウザ・アプリケーション２１６および他の様々なクライアント・アプリケーション２１８をサポートできるクライアント装置２１４と対話する。ユーザ２１２は、クライアント装置２１４、ブラウザ２１６、またはユーザとその他の装置およびサービスとのインターフェースとして動作する任意の他のソフトウェアとは別個のものである。場合によっては、以下の説明により、クライアント・アプリケーション内で明示的に動作するユーザと、ユーザに代わって動作するクライアント・アプリケーションとを区別することができる。しかし、一般に、リクエスタは、クライアントベースのアプリケーション、ブラウザ、ＳＯＡＰクライアントなど、ユーザに代わって動作するものと想定できる仲介者である。
【００６３】
ブラウザ・アプリケーション２１６は、ＨＴＴＰ通信コンポーネント２２０およびマークアップ言語（ＭＬ）インタープリタ２２２などの多くのモジュールを有する典型的なブラウザにすることができる。また、ブラウザ・アプリケーション２１６は、Ｗｅｂサービス・クライアント２２４あるいはダウンロード可能アプレットまたはその両方などのプラグインもサポートすることができ、そのアプレットは仮想計算機ランタイム環境を必要とする場合もあれば必要としない場合もある。Ｗｅｂサービス・クライアント２２４は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）を使用することができ、これは非集中分散環境における構造化および型付き情報の交換を定義するための軽量プロトコルである。ＳＯＡＰは、メッセージ内に何が含まれているかならびにそれをどのように処理するかを記述するためのフレームワークを定義するエンベロープと、アプリケーション定義のデータ型のインスタンスを表すための１組のエンコード・ルールと、リモート・プロシージャ・コールおよび応答を表すための規則という３つの部分からなるＸＭＬベースのプロトコルである。ユーザ２１２は、ブラウザ・アプリケーション２１６を使用してＷｅｂベース・サービスにアクセスすることができるが、ユーザ２１２は、クライアント装置２１４上の他のＷｅｂサービス・クライアントによりＷｅｂサービスにアクセスすることもできる。以下の図に示した本発明の例のいくつかは、フェデレーテッド環境内のエンティティ間で情報を交換するために、ユーザのブラウザによるＨＴＴＰリダイレクトを使用する。しかし、本発明は、様々な通信プロトコルにより実施することができ、ＨＴＴＰベースの通信に制限されるものではないことに留意されたい。たとえば、フェデレーテッド環境内のエンティティは、必要なときに直接通信することができ、ユーザのブラウザによりメッセージをリダイレクトする必要はない。
【００６４】
本発明は、フェデレーテッド環境に必要なコンポーネントを既存のシステムと統合できるように実現することができる。図７は、既存のシステムへのフロントエンドとしてこれらのコンポーネントを実現するための一実施形態を描写している。フェデレーテッド・ドメインにある既存のコンポーネントは、図８に示したものと同様に認証サービス・ランタイム（ＡＳＲ：authentication service runtime）サーバ２３２を含む、レガシー・アプリケーションまたはバックエンド処理コンポーネント２３０と見なすことができる。ＡＳＲサーバ２３２は、そのドメインがアプリケーション・サーバ２３４へのアクセスを制御するときにユーザの認証を担当し、そのアプリケーション・サーバ２３４は保護リソースを生成するか、検索するか、またはその他の方法で処理するものと見なすことができる。このドメインは引き続きレガシー・ユーザ登録アプリケーション２３６を使用して、アプリケーション・サーバ２３４へのアクセスについてユーザを登録することができる。登録済みユーザを認証するために必要な情報は、レガシー・ユーザ・レジストリ２３８に保管される。
【００６５】
フェデレーテッド環境に加入後、そのドメインは、フェデレーテッド・コンポーネントの介入なしに機能し続けることができる。換言すれば、そのドメインは、ポイントオブコンタクト・サーバまたはこのポイントオブコンタクト・サーバ機能を実現するその他のコンポーネントを通過せずに、ユーザが特定のアプリケーション・サーバまたは他の保護リソースに直接アクセスし続けることができるように構成することができ、このようにシステムにアクセスするユーザは、典型的な認証フローおよび典型的なアクセスを経験することになるであろう。しかし、このようにする際に、レガシー・システムに直接アクセスするユーザは、そのドメインのポイントオブコンタクト・サーバに知られているフェデレーテッド・セッションを確立できないであろう。
【００６６】
そのドメインのレガシー機能は、フェデレーテッド・フロントエンド処理２４０の使用によりフェデレーテッド環境に統合することができ、そのフェデレーテッド・フロントエンド処理２４０はポイントオブコンタクト・サーバ２４２とトラスト・プロキシ・サーバ２４４（またはより単純にトラスト・プロキシ２４４）とを含み、そのトラスト・プロキシ・サーバ２４４自体はセキュリティ・トークン・サービス（ＳＴＳ：Security Token Service）２４５を含み、これらのすべてについては図８に関し以下により詳細に説明する。フェデレーション構成アプリケーション２４６により、管理ユーザは、フェデレーテッド・フロントエンド・コンポーネントがフェデレーテッド・インターフェース・ユニット２４８によりレガシー・バックエンド・コンポーネントとのインターフェースを取れるようにそのフェデレーテッド・フロントエンド・コンポーネントを構成することができる。
【００６７】
所与の企業におけるレガシーまたは既存の認証サービスは、ユーザ名／パスワードまたはスマートカード・トークンベースの情報など、様々な周知の認証方法またはトークンを使用することができる。しかし、本発明では、ポイントオブコンタクト・サーバの使用により、レガシー認証サービスの機能をフェデレーテッド環境で使用することができる。ユーザは、ポイントオブコンタクト・サーバを通過せずにレガシー認証サーバに直接アクセスし続けることができるが、このようにシステムにアクセスするユーザは典型的な認証フローおよび典型的なアクセスを経験することになり、レガシー認証システムに直接アクセスするユーザは、本発明によりＩＤの証明としてフェデレーテッド認証アサーションを生成できないであろう。フェデレーテッド・フロントエンドの役割の１つは、ポイントオブコンタクト・サーバで受信したフェデレーテッド認証トークンを、レガシー認証システムによって理解されるフォーマットに変換することである。このため、ポイントオブコンタクト・サーバを介してフェデレーテッド環境にアクセスするユーザは必ずしも、レガシー認証サービスに対する再認証を受ける必要はなくなるであろう。好ましくは、ユーザは、ユーザが認証ダイアログに従事している場合と同様にそれが現れるように、ポイントオブコンタクト・サーバとトラスト・プロキシとの組合せによって、レガシー認証サービスに対して認証されることになるであろう。
【００６８】
フェデレーテッド・アーキテクチャ――ポイントオブコンタクト・サーバ、トラスト・プロキシ、およびトラスト・ブローカ
次に図８を参照すると、ブロック図は、本発明の一実現例によるフェデレーテッド・アーキテクチャを描写している。フェデレーテッド環境は、ユーザに様々なサービスを提供するフェデレーテッド企業または同様のエンティティを含む。ユーザは、クライアント装置上のアプリケーションにより、企業２５０などの様々なエンティティにあるリソースにアクセスしようと試みることができる。企業２５０のポイントオブコンタクト（ＰＯＣ）サーバ２５２など、各フェデレーテッド企業のポイントオブコンタクト・サーバは、そのユーザのフェデレーテッド環境へのエントリ・ポイントである。ポイントオブコンタクト・サーバはフェデレーション要件の多くを処理するので、ポイントオブコンタクト・サーバは既存の非フェデレーテッド・アーキテクチャ内の既存のコンポーネント、たとえば、レガシー・システムへの影響を最小限にする。ポイントオブコンタクト・サーバは、セッション管理、プロトコル変換を可能にし、おそらく、認証アサーション変換を開始する。たとえば、ポイントオブコンタクト・サーバは、ＨＴＴＰまたはＨＴＴＰＳメッセージをＳＯＡＰに変換することができ、またその逆も変換することができる。以下により詳細に説明するように、ポイントオブコンタクト・サーバは、トラスト・プロキシを呼び出して認証アサーションを変換するために使用することもでき、たとえば、発行側パーティから受信したＳＡＭＬトークンは受信側パーティによって理解されるＫｅｒｂｅｒｏｓトークンに変換することができる。
【００６９】
企業２５０のトラスト・プロキシ（ＴＰ）２５４などのトラスト・プロキシまたはトラスト・プロキシ・サーバは、フェデレーション内の２つのエンティティ間の信頼関係を確立し維持する。トラスト・プロキシは一般に、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換（以下に詳述するセキュリティ・トークン・サービスによる）を処理する能力を有する。
【００７０】
全体的に、ポイントオブコンタクト・サーバとトラスト・プロキシの使用は、フェデレーテッド・アーキテクチャの実現が既存の非フェデレーテッド・システム・セットに及ぼす影響を最小限にする。このため、本発明のフェデレーテッド・アーキテクチャは、そのエンティティが企業であるか、ドメインであるか、その他の論理エンティティまたは物理エンティティであるかにかかわらず、フェデレーテッド・エンティティ当たり少なくとも１つのポイントオブコンタクト・サーバと少なくとも１つのトラスト・プロキシの実現を必要とする。しかし、本発明のフェデレーテッド・アーキテクチャは必ずしも、既存の非フェデレーテッド・システム・セットに対する変更を必要としない。好ましくは、所与のフェデレーテッド・エンティティについて単一のトラスト・プロキシが存在するが、可用性のために複数のトラスト・プロキシが存在する可能性もあり、あるいはフェデレーテッド・エンティティ内のより小さい様々なエンティティ、たとえば、企業内の個別の子会社のために、複数のトラスト・プロキシが存在する可能性もある。単一トラスト・プロキシは複数のフェデレーション内の信頼関係を管理することができるので、このシナリオは必ずしも複数のトラスト・プロキシを必要としないであろうが、所与のエンティティが２つ以上のフェデレーションに属すことができることは起こり得ることである。
【００７１】
トラスト・プロキシの役割の１つは、他のドメインあるいはそのドメイン内のトラスト・プロキシまたはその両方によって必要なトークン・タイプを決定することである。トラスト・プロキシは、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換を処理する能力を有する。また、トラスト・プロキシ２５４は、企業２５０に関して行われる任意のユーザＩＤ変換または属性変換も担当する。しかし、トラスト・プロキシは、以下に詳述する通り、支援のためにトラスト・ブローカを呼び出すことができる。ＩＤ変換は、発行側パーティに知られているユーザＩＤおよび属性を受信側パーティにとって意味のあるものにマッピングする必要がある場合がある。この変換は、発行側ドメインのトラスト・プロキシまたは受信側ドメインのトラスト・プロキシのいずれかによって呼び出すことができる。
【００７２】
トラスト・プロキシ２５４は、セキュリティ・トークン・サービス（ＳＴＳ）コンポーネント２５５として示される内部化コンポーネント（internalized component）を含むことができ、そのコンポーネントはトークン変換を可能にし、認証サービス・ランタイム（ＡＳＲ）２５６を呼び出してトークンを妥当性検査し生成することになる。セキュリティ・トークン・サービスは、トラスト・プロキシが必要とするトークン発行および妥当性検査サービスを提供する。したがって、セキュリティ・トークン・サービスは、既存の認証サービス・ランタイムへのインターフェースを含むか、またはそのサージス自体に認証サービス・ランタイムを組み込む。トラスト・プロキシ内に内部化されるのではなく、セキュリティ・トークン・サービス・コンポーネントは、たとえば、トラスト・プロキシによって呼び出されるスタンドアロン・コンポーネントとして実現することもでき、あるいは、たとえば、アプリケーション・サーバの一部として、トランザクション・サーバ内に内部化することもできる。
【００７３】
たとえば、ＳＴＳコンポーネントは、Ｋｅｒｂｅｒｏｓトークンを発行するための要求を受信することができる。そこからトークンが作成されるユーザの認証情報の一部として、要求は、ユーザ名とパスワードを含むバイナリ・トークンを含むことができる。ＳＴＳコンポーネントは、たとえば、ＬＤＡＰランタイム（典型的な認証）に照らし合わせてユーザ名およびパスワードを妥当性検査することになり、Ｋｅｒｂｅｒｏｓ ＫＤＣ（鍵配布センタ：Key Distribution Center）を呼び出して、このユーザに関するＫｅｒｂｅｒｏｓチケットを生成することになる。このトークンは、企業内で使用するためにトラスト・プロキシに返されるが、この使用は、フェデレーション内の他のドメインに転送するためにトークンを外部化することを含む可能性がある。
【００７４】
図４に関して説明したものと同様に、ユーザは、企業２５０および企業２６０の両方など、フェデレーテッド環境内の複数企業のリソースにアクセスすることを所望する可能性がある。企業２５０に関して上述したものと同様に、企業２６０は、ポイントオブコンタクト・サーバ２６２と、トラスト・プロキシ２６４と、セキュリティ・トークン・サービス２６５と、認証サービス・ランタイム２６６とを有する。ユーザは各企業との個別のトランザクションを直接開始することができるが、ユーザは、フェデレーテッド環境全体にわたってカスケードする企業２５０とのトランザクションを開始することができる。ユーザがトランザクションを開始したときにユーザがその必要性を認識していなかった可能性がある場合でも、企業２５０は、特定のトランザクションを完了するために、企業２６０などのフェデレーテッド環境内の他の複数の企業とのコラボレーションを必要とする場合がある。企業２６０はダウンストリーム・ドメインとして関係することになり、本発明により、企業２５０は、ユーザのトランザクションを促進するために必要であれば、フェデレーテッド・アサーションを企業２６０に提示することができる。
【００７５】
関連ポイントオブコンタクト・サーバによって受信された認証トークンを解釈する方法あるいは所与のユーザＩＤおよび属性を変換する方法またはその両方をトラスト・プロキシが把握していないということが実情である場合もある。この場合、トラスト・プロキシは、トラスト・ブローカ２６８などのトラスト・ブローカ・コンポーネントで機能を呼び出すことを選択することができる。トラスト・ブローカは、個々のトラスト・プロキシとの関係を維持し、それにより、トラスト・プロキシ間の推移的な信頼関係を提供する。トラスト・ブローカを使用すると、企業２５０および２６０などのフェデレーテッド環境内の各エンティティは、フェデレーテッド環境内の各ドメインとの複数の個別信頼関係を確立するのではなく、トラスト・ブローカとの信頼関係を確立することができる。たとえば、企業２６０が企業２５０のユーザによって開始されたトランザクションについてダウンストリーム・ドメインとして関係することになったときに、企業２５０のトラスト・プロキシ２５４は、必要な場合にトラスト・ブローカ２６８で支援を呼び出すことにより、企業２６０のトラスト・プロキシ２６４がトラスト・プロキシ２５４からのアサーションを理解できることを確信することができる。図８は、単一トラスト・ブローカを備えたフェデレーテッド環境を描写しているが、フェデレーテッド環境は複数のトラスト・ブローカを有することができる。
【００７６】
図８はポイントオブコンタクト・サーバ２５２、トラスト・プロキシ２５４、セキュリティ・トークン・サービス・コンポーネント２５５、および認証サービス・ランタイム２５６を別個のエンティティとして描写しているが、これらのコンポーネントを個別のデバイスとして実現する必要はないことに留意されたい。たとえば、これらの個別のコンポーネントの機能を、単一物理装置上のアプリケーションとして実現するかまたは単一アプリケーションに結合することは可能である。加えて、図８は、１つの企業のための単一ポイントオブコンタクト・サーバ、単一トラスト・プロキシ、および単一セキュリティ・トークン・サーバを描写しているが、代替構成は、各企業用の複数のポイントオブコンタクト・サーバ、複数のトラスト・プロキシ、および複数のセキュリティ・トークン・サーバを含むことができる。ポイントオブコンタクト・サーバ、トラスト・プロキシ、セキュリティ・トークン・サービス、およびその他のフェデレーテッド・エンティティは、ソフトウェア・アプリケーション、オブジェクト、モジュール、ソフトウェア・ライブラリなどの様々な形で実現することができる。
【００７７】
トラスト・プロキシ／ＳＴＳは、ユーザ名とパスワードの組合せおよびＫｅｒｂｅｒｏｓチケットなどの伝統的な信用証明情報を含む多種多様な認証信用証明情報ならびにサード・パーティによって生成される認証トークンを含むフェデレーテッド認証トークン・フォーマットを受諾し妥当性検査することができる。トラスト・プロキシ／ＳＴＳは、他の場所で認証の証明として認証トークンの受諾を可能にすることができる。認証トークンは、発行側パーティによって生成され、ユーザがその発行側パーティに対してすでに認証を受けていることを示すために使用される。発行側パーティは、ユーザの認証済みＩＤをアサートする手段として、認証トークンを生成する。
【００７８】
セキュリティ・トークン・サービスは、必要に応じて、認証サービス・ランタイムを呼び出す。認証サービス・ランタイムは、ユーザを認証できる認証サービスをサポートする。認証サービスは、認証応答を介して認証試行の成功または失敗の表示を提供する認証機関として動作する。トラスト・プロキシ／ＳＴＳは、認証サービス、たとえば、既存のレガシー・インフラストラクチャと対話する必要がないＷｅｂサービスの真新しいインストールが存在するというシナリオを内部化することができる。そうではない場合、ＳＴＳコンポーネントは、認証トークンの妥当性検査のために外部認証サービスを呼び出すことになる。たとえば、ＳＴＳコンポーネントは、ユーザ名／パスワードを含むバイナリ・トークンを「アンパック」し、次にＬＤＡＰサービスを使用してユーザ・レジストリにアクセスし、提示された信用証明情報を妥当性検査することができるであろう。
【００７９】
アプリケーション・サーバなどの他のコンポーネントによって使用される場合、ＳＴＳコンポーネントは、レガシー認証システムへのシングル・サインオンに必要なトークンを生成するために使用することができる。このため、ＳＴＳコンポーネントは、内部目的のために、すなわち、１つの企業内で、ならびに外部目的のために、すなわち、１つのフェデレーション内の複数企業の全域で、トークン変換に使用することができる。内部目的の一例として、Ｗｅｂアプリケーション・サーバは、ＩＢＭ ＣＩＣＳ（顧客情報管理システム：Customer Information Control System）トランザクション・ゲートウェイを介してメインフレームとのインターフェースを取ることができ、ＣＩＣＳは、企業レベルのオンライン・トランザクション管理および接続性を主幹業務アプリケーションに提供するアプリケーション・サーバおよびコネクタのファミリである。Ｗｅｂアプリケーション・サーバは、Ｋｅｒｂｅｒｏｓチケット（Ｗｅｂアプリケーション・サーバによって内部で使用されるもの）を、ＣＩＣＳトランザクション・ゲートウェイが要求するＩＢＭ ＲＡＣＦ（商標）パスチケットに変換するために、ＳＴＳコンポーネントを呼び出すことができる。
【００８０】
図８に示したエンティティは、上記で紹介した用語、たとえば、「発行側パーティ」および「依存側パーティ」を使用して説明することができる。信頼関係を確立し維持することの一部として、発行側パーティのトラスト・プロキシは、依存側パーティのトラスト・プロキシによってどのトークン・タイプが要求／受諾されるかを決定することができる。したがって、トラスト・プロキシは、セキュリティ・トークン・サービスからトークン・サービスを呼び出すときに、この情報を使用する。発行側ドメインのトラスト・プロキシが依存側パーティに関する認証アサーションを生成することを要求された場合、そのトラスト・プロキシは、必要なトークン・タイプを決定し、セキュリティ・トークン・サービスから適切なトークンを要求する。
【００８１】
依存側ドメインのトラスト・プロキシが発行側パーティから認証アサーションを受信すると、そのトラスト・プロキシは、どのタイプのアサーションをそれが予想していたか、ならびに依存側ドメイン内の内部使用のためにどのタイプのアサーションを必要としているかを把握する。したがって、依存側ドメインのトラスト・プロキシは、受信した認証アサーション内のトークンに基づいて、セキュリティ・トークン・サービスが必要な内部使用トークンを生成することを要求する。
【００８２】
トラスト・プロキシとトラスト・ブローカはどちらも、発行側パーティから受信したアサーションを、依存側パーティによって理解されるフォーマットに変換する能力を有する。トラスト・ブローカは、それとの直接的信頼関係が存在するトラスト・プロキシのそれぞれに関するアサーション・フォーマット（複数も可）を解釈する能力を有し、それにより、トラスト・ブローカが発行側パーティと依存側パーティとの間のアサーション変換を行えるようにする。この変換は、そのローカル・トラスト・プロキシによりいずれかのパーティによって要求することができる。したがって、発行側パーティのトラスト・プロキシは、それが依存側パーティに送信される前にアサーションの変換を要求することができる。同様に、依存側パーティのトラスト・プロキシは、発行側パーティから受信されたアサーションの変換を要求することができる。
【００８３】
アサーション変換は、ユーザＩＤ変換、認証アサーション変換、属性アサーション変換、またはその他の形式のアサーション変換を含む。上記のポイントを繰り返すと、アサーション変換は、フェデレーション内のトラスト・コンポーネント、すなわち、トラスト・プロキシとトラスト・ブローカによって処理される。トラスト・プロキシは、発行側ドメインまたは依存側ドメインのいずれかで、この変換をローカルで実行する場合もあれば、トラスト・ブローカから支援を呼び出す場合もある。
【００８４】
発行側パーティと依存側パーティがすでにトラスト・ブローカとの個別信頼関係を有すると想定すると、トラスト・ブローカは、必要であれば発行側パーティと依存側パーティとの間の新しい信頼関係を動的に作成する、すなわち、ブローカリングすることができる。トラスト・ブローカによって提供される初期信頼関係ブローカリング操作の後、発行側パーティと依存側パーティは、将来の変換要件のためにトラスト・ブローカを呼び出す必要がないように、その関係を直接維持することができる。認証トークンの変換は、発行側パーティのトラスト・プロキシ、依存側パーティのトラスト・プロキシ、およびトラスト・ブローカという考えられる３つの箇所で起こる可能性があることに留意されたい。好ましくは、発行側パーティのトラスト・プロキシは、依存側パーティに送信するためにトラスト・ブローカによって理解される認証アサーションを生成する。次に依存側パーティは、トラスト・ブローカからのこのトークンを依存側パーティによって認識可能なフォーマットに変換することを要求する。トークン変換は、認証アサーションの伝送前に、伝送後に、または伝送前と伝送後の両方で行うことができる。
【００８５】
フェデレーテッド・アーキテクチャ内の信頼関係
本発明により実現されるフェデレーテッド環境内には、企業トラスト・ドメインとフェデレーション・トラスト・ドメインという、管理しなければならない２つのタイプの「トラスト・ドメイン」が存在する。この２つのタイプのトラスト・ドメイン間の相違点は、部分的に、トラスト・ドメインとの信頼関係を支配する事業協定と、信頼を確立するために使用される技術とに基づいている。企業トラスト・ドメインは、その企業によって管理されるコンポーネントを含み、そのトラスト・ドメイン内のすべてのコンポーネントは互いに信頼する。一般に、たとえば、コンポーネント間で相互に認証されたＳＳＬセッションを要求することにより、配置された技術が１つの企業内で固有の信頼関係を作り出すので、１つの企業内で信頼を確立するために必要な事業協定はまったく存在しない。図７を参照すると、レガシー・アプリケーションおよびバックエンド処理システムは企業トラスト・ドメインを表すことができる。
【００８６】
フェデレーション・トラスト・ドメインは企業境界を越えるものであり、ある視点によると、フェデレーション・トラスト・ドメインは、別個の企業トラスト・ドメイン間の信頼関係を表すことができる。フェデレーション・トラスト・ドメインは、企業境界の全域でトラスト・プロキシにより確立される。フェデレーテッド信頼関係は、それによりトラスト・プロキシ間に初期信頼が確立される、ある種のブートストラッピング・プロセスを必要とする。このブートストラップ・プロセスの一部は、予想あるいは許可またはその両方のトークン・タイプとＩＤ変換を定義するルールならびに共有秘密鍵の確立を含むことができる。一般に、このブートストラッピング・プロセスは、ある企業のフェデレーションへの参加を支配する事業協定の確立と、この参加に関連する責任も含むので、このプロセスはアウト・オブ・バンドで実現される。
【００８７】
フェデレーテッド・ビジネス・モデルには信頼を確立するためのメカニズムがいくつか存在する。フェデレーション・モデルでは、参加者間で転送されるアサーション（トークンおよび属性情報を含む）が有効であるという、あるレベルの保証を提供するために、ビジネス上の理由でフェデレーション参加者間の信頼の基本概念が必要である。信頼関係がまったくない場合、依存側ドメインは発行側ドメインから受信したアサーションに依存することができず、発行側パーティから受信した任意の情報を解釈する方法を決定するために依存側ドメインがそれを使用することができない。
【００８８】
たとえば、大企業は、数千のグローバル・カスタマ（globalcustomer）をリンクしたいと希望する可能性があり、その企業は従来技術のソリューションを使用できるであろう。第１の例として、その企業は、相互信頼を確立するために商用証明局からのデジタル証明書を使用することをグローバル・カスタマに要求できるであろう。商用証明局は、その企業のサーバがそれぞれのグローバル・カスタマに位置するサーバを信頼できるようにする。第２の例として、その企業はＫｅｒｂｅｒｏｓを使用してサード・パーティの信頼を実現でき、その企業とそのグローバル・カスタマは共有秘密鍵ベースの信頼を実現するトラステッド・サード・パーティＫｅｒｂｅｒｏｓドメイン・サービスを実現できるであろう。第３の例として、その企業は、そのグローバル・カスタマのサーバによって相互に信頼される独自のセキュリティ・メッセージ・トークンにより専用方式を確立できるであろう。
【００８９】
その企業が少数のグローバル・カスタマとの信頼関係を管理する必要がある場合、上記の手法のいずれか１つが受入れ可能である可能性があるが、数百または数千の潜在的なフェデレーション・パートナが存在する場合には、これは管理不能になる可能性がある。たとえば、企業がより小規模なパートナに専用方式の実現を強制することは可能である場合もあるが、企業がより大規模なパートナに多くの要件を賦課できるようになることはありそうもないことである。
【００９０】
本発明では、企業は、トラスト・プロキシと、おそらくトラスト・ブローカにより確立され維持された信頼関係を使用することになる。本発明のフェデレーテッド・アーキテクチャの利点の１つは、ある企業およびその潜在的なフェデレーション・パートナの現行インフラストラクチャ以上の追加要件を賦課しないことである。
【００９１】
しかし、本発明は、フェデレーションへの参加に必要な事業および責任協定を確立するために必要な予備作業から企業およびその潜在的なフェデレーション・パートナを救済するものではない。加えて、参加者は信頼関係の技術的ブートストラッピングを無視することができない。本発明はこのブートストラッピングを柔軟なものにすることができ、たとえば、第１のフェデレーション・パートナは特定の情報でＫｅｒｂｅｒｏｓチケットを発行することができ、第２のフェデレーション・パートナは特定の情報でＳＡＭＬ認証アサーションを発行することができる。
【００９２】
本発明では、２つのトラスト・プロキシ間で事前確立された関係に基づいて発行側パーティから受信されるトークンを妥当性検査し変換するセキュリティ・トークン・サービスを含むことができるフェデレーション・トラスト・プロキシにより信頼関係が管理される。フェデレーテッド企業が他のフェデレーテッド企業との信頼関係（およびトークン変換）を確立することが実現可能ではない状況では、トラスト・ブローカを呼び出すことができる。しかし、フェデレーテッド企業は依然として、トラスト・ブローカとの関係を確立しなければならない。
【００９３】
次に図９を参照すると、ブロック図は、本発明によりトラスト・プロキシとトラスト・ブローカとを使用するフェデレーテッド・ドメイン間の例示的な１組の信頼関係を描写している。図８はトラスト・ブローカを紹介したが、図９は本発明のフェデレーテッド・アーキテクチャ内の推移的な信頼関係の重要性を示している。
【００９４】
フェデレーテッド・ドメイン２７１〜２７３はトラスト・プロキシ２７４〜２７６をそれぞれ組み込んでいる。トラスト・プロキシ２７４はトラスト・プロキシ２７５との直接的信頼関係２７７を有する。トラスト・ブローカ２８０はトラスト・プロキシ２７５との直接的信頼関係２７８を有し、トラスト・ブローカ２８０はトラスト・プロキシ２７９との直接的信頼関係２７９を有する。トラスト・ブローカ２８０は、フェデレーション参加者に代わって、他のフェデレーション・パートナとの推移的な信頼関係に基づいて信頼関係を確立するために使用される。推移的な信頼関係の原理により、トラスト・プロキシ２７５およびトラスト・プロキシ２７６はトラスト・ブローカ２８０を介して信頼関係２８１をブローカリングしてもらうことができる。トラスト・プロキシ２７５または２７６はいずれも、もう一方のアサーションを変換または妥当性検査する方法を把握している必要はなく、有効であり、信頼され、もう一方のトラスト・プロキシで理解されるものにアサーションを変換するために、トラスト・ブローカを呼び出すことができる。
【００９５】
フェデレーテッド企業間の信頼関係に関する契約上の義務および責任を指定する事業協定は、ｅｂＸＭＬ（ＸＭＬを使用する電子ビジネス）規格の使用によりＸＭＬで表すことができる。たとえば、直接的信頼関係はｅｂＸＭＬドキュメントで表すことができ、直接的信頼関係を共用する各フェデレーテッド・ドメインはｅｂＸＭＬドキュメントとして表された契約書のコピーを有することになるであろう。フェデレーション内の様々なエンティティに関する動作特性は、ｅｂＸＭＬ振り付け（choreography）内に指定し、ｅｂＸＭＬレジストリ内で公開することができ、たとえば、トラスト・プロキシまたはトラスト・ブローカを操作するために、特定のフェデレーションに参加することを希望する任意の企業は、そのフェデレーション内のすべてのトラスト・プロキシまたはトラスト・ブローカについてその特定のフェデレーションによって指定された公開要件に適合する必要があるであろう。セキュリティ・トークン・サービスは、他のドメインからのトークンを変換する方法に関する操作上の詳細について、これらのｅｂＸＭＬドキュメントを構文解析できるであろう。しかし、フェデレーション内の信頼関係が実現される方法に関する詳細を指定するために、本発明により他の規格およびメカニズムを使用できることに留意されたい。
【００９６】
フェデレーテッド・アーキテクチャ内のアサーション処理
上記の通り、フェデレーション内のユーザの経験は、部分的に、複数ドメインの全域で転送される、ユーザに関するかまたはそのユーザのためのアサーションによって支配される。アサーションは、ユーザの認証状況に関する情報、属性情報、およびその他の情報を提供する。認証アサーションを使用すると、ユーザが、アクセスしたサイトごとに再認証を受ける必要性を除去することができる。フェデレーテッド環境内には、発行側パーティから依存側パーティへのアサーションを取得するために、プッシュ・モデル（push model）とプル・モデル（pull model）という２つのモデルが存在する。プッシュ・モデルでは、ユーザのアサーションはユーザの要求とともに発行側パーティに移動する。プル・モデルでは、ユーザの要求はいかなる情報もなしで依存側パーティで受信され、次に依存側パーティは発行側パーティから関連アサーションまたは必要なアサーションを要求する。
【００９７】
フェデレーテッド環境内でアサーションを使用するためのこれらのモデルを考慮して、次に本発明の説明では、本発明のフェデレーテッド環境内でアサーションを作成し使用するための１組のプロセスを記述する１組の図面を参照する。図１０は、フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写しており、図１１は、アサーションを「取り壊す」ため、すなわち、その情報を抽出し分析することにより、アサーションをその本質的情報まで削減するための依存側ドメインにおける汎用プロセスを描写している。図１２および図１３は、アサーションが発行側ドメイン内で生成され、次にユーザの要求とともに依存側ドメインに転送される、プッシュ・モデルの２つの変形を描写することにより、図１０に示した汎用プロセスに関するより詳細なプロセスを示している。図１４は、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。
【００９８】
次に図１０を参照すると、フローチャートは、フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写している。このプロセスは、発行側ドメインのポイントオブコンタクト・サーバがアサーションのためにトリガされたときに始まる（ステップ３０２）。ポイントオブコンタクト・サーバは、依存側ドメインから所与のユーザ用の特定のアサーションに関する要求を受信する場合もあれば、アサーションを必要とする既知の依存側ドメインに対する発信要求をインターセプトする場合もあり、これらのシナリオについてはそれぞれ図１２および１３に関して以下により詳細に説明する。アサーションのためにトリガされたことに応答して、発行側ドメインのポイントオブコンタクト・サーバは発行側ドメインのトラスト・プロキシからアサーションを要求し（ステップ３０４）、発行側ドメインのトラスト・プロキシがアサーションを生成し（ステップ３０６）、発行側ドメインのトラスト・プロキシは、必要であれば、必要なアサーションを生成するためにトラスト・ブローカから支援を要求することができる。アサーションを生成した後、発行側ドメインのトラスト・プロキシは発行側ドメインのポイントオブコンタクト・サーバにアサーションを返し（ステップ３０８）、次に発行側ドメインのポイントオブコンタクト・サーバが適切な方法で、たとえば、発信ＨＴＴＰまたはＳＯＡＰメッセージにアサーションを挿入することにより、出力データストリームにアサーションを注入し（ステップ３１０）、それにより、プロセスを完了する。
【００９９】
図１０は、「ローカル・ウォレット」の使用なしに発行側ドメインでアサーションを作成するためのプロセスを描写している。しかし、本発明はローカル・ウォレット機能の組込みを可能にするものである。一般に、ローカル・ウォレットは、トランザクションを容易にするためにユーザ属性情報またはその他の情報に関するセキュア・データ・ストアとして動作可能なクライアント側のコードであり、このクライアント側のコードはアサーション転送のプッシュ・モデルあるいはプル・モデルまたはその両方に参加することもできる。ローカル・ウォレットが積極的にプロトコルに参加すると、それは、アサーションを生成し、それをプロトコル・フローに挿入するという点でポイントオブコンタクト・サーバ機能の機能サブセットを実現する。ローカル・ウォレットを使用することにより、ローカル・ウォレットが、ポイントオブコンタクト・サーバとトラスト・プロキシとの間で行われるトラストベースの対話を実現できるわけではない。追加の信頼関係が必要な場合、ポイントオブコンタクト・サーバを呼び出さなければならない。
【０１００】
次に図１１を参照すると、フローチャートは、アサーションを取り壊すための依存側ドメインにおける汎用プロセスを描写している。このプロセスは、依存側ドメインのポイントオブコンタクト・サーバが関連アサーションとともにメッセージを受信したときに始まり（ステップ３２２）、その後、依存側ドメインのポイントオブコンタクト・サーバはアサーションを抽出し、依存側ドメインのトラスト・プロキシにアサーションを転送する（ステップ３２４）。依存側ドメインのトラスト・プロキシは、発行側ドメインから受信したトークンを含む情報をアサーションから抽出し（ステップ３２６）、依存側ドメインのトラスト・プロキシは、セキュリティ・トークン・サービスを呼び出してこのトークンを妥当性検査することになり、適切であれば、そのユーザに関してローカルで有効なトークンを返す（ステップ３２８）。
【０１０１】
ステップ３２６の一部として、トラスト・プロキシは、アサーションのソース、すなわち、発行側パーティを決定することになる。トラスト・プロキシがこの発行側ドメインから受信したトラスト・アサーションを理解できる場合、トラスト・プロキシはステップ３２８を内部で実行することになる。トラスト・プロキシが発行側ドメインから受信したアサーションを理解／信頼できない場合、トラスト・プロキシはトラスト・ブローカからの支援を呼び出すことができる。アサーションを妥当性検査できない場合、適切なエラー応答を生成することになるであろう。
【０１０２】
アサーションが妥当性検査されたと想定すると、依存側ドメインのトラスト・プロキシは、そのユーザについて必要なローカル情報を構築する（ステップ３３０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって必要とされる認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインのポイントオブコンタクト・サーバに返し（ステップ３３２）、そのポイントオブコンタクト・サーバがそのユーザのためのローカル・セッションを構築する。
【０１０３】
ポイントオブコンタクト・サーバがそのユーザのためのセッションを構築した後、そのユーザは認証ユーザとして現れる。ポイントオブコンタクト・サーバは、ログアウトまたはタイムアウト・イベントが開始されるまでユーザがそのドメインとの間で行っている任意のトランザクションをさらに支配するために、このセッション情報を使用することができる。ポイントオブコンタクト・サーバがそのユーザに関する認証済みＩＤを有していることを考慮すると、ポイントオブコンタクト・サーバは、この特定のユーザのＩＤとこの特定のユーザに関連する任意の許可ポリシーに基づいて、必要であれば、この要求に関する許可を入手することができる。次にポイントオブコンタクト・サーバは、要求されたバックエンド・アプリケーションまたはサービスに任意の関連情報とともにユーザの要求を転送し（ステップ３３４）、それにより、プロセスを完了する。
【０１０４】
ポイントオブコンタクト・サーバとトラスト・プロキシとの間で転送されるデータ項目およびそのデータ項目のフォーマットは様々になる可能性があることに留意されたい。メッセージからアサーションを抽出し、アサーションのみをトラスト・プロキシに転送するのではなく、ポイントオブコンタクト・サーバは、メッセージ全体をトラスト・プロキシに転送することができる。たとえば、トラスト・プロキシにおける処理は、ＳＯＡＰメッセージ関するシグニチャ妥当性検査のようなステップを含むことができ、これはＳＯＡＰエンベロープ全体を必要とするであろう。
【０１０５】
次に図１２を参照すると、フローチャートは、発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが発行側ドメイン内のＷｅｂページまたは同様のリソースから依存側ドメインへのリンクにアクセスしたときに始まり（ステップ３４２）、それにより、特定のアサーションを構築するために何らかの形のＣＧＩ（コモン・ゲートウェイ・インターフェース）タイプの処理を呼び出す。依存側ドメインによるアサーションの必要性を認識する発行側ドメインの能力は、本発明のフェデレーテッド・インフラストラクチャが実現される既存のレガシー・システムとの緊密統合を示している。また、これは、発行側パーティが必要なアサーションを構築するためにトラスト・プロキシを呼び出す必要がないような、発行側パーティと依存側パーティとの緊密結合も示しており、この緊密結合は、適切に確立された信頼関係を有する特定のタイプのフェデレーテッド・エンティティ間では適切なものである可能性がある。
【０１０６】
発行側ドメインにおけるバックエンド処理は、必要なアサーションを構築するために呼び出され（ステップ３４４）、これは、ローカル・トラスト・プロキシにおける呼出し機能を含む可能性がある。次に、必要なアサーションを含む、依存側ドメインへのユーザの要求が構築され（ステップ３４６）、発行側ドメインはユーザの要求とともにアサーションを依存側ドメインに転送し（ステップ３４８）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションを妥当性検査することになるであろう。
【０１０７】
次に図１３を参照すると、フローチャートは、依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが依存側ドメインにおける保護リソースを要求したときに始まる（ステップ３５２）。ポイントオブコンタクト・サーバは、たとえば、所定のユニフォーム・リソース・アイデンティファイア（ＵＲＩ）、特定のタイプのメッセージ、特定のタイプのメッセージ・コンテンツについて発信メッセージをフィルタリングすることによるか、またはその他の何らかの方法で、発信要求をインターセプトする（ステップ３５４）。次に発行側ドメインのポイントオブコンタクト・サーバは、発行側ドメインのトラスト・プロキシから適切なアサーションの生成を要求し（ステップ３５６）、そのトラスト・プロキシは必要であればトラスト・ブローカからの支援によりアサーションを生成する（ステップ３５８）。次に発行側ドメインは、生成したアサーションとともにユーザの要求を依存側パーティに転送し（ステップ３６０）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションを妥当性検査することになるであろう。
【０１０８】
次に図１４を参照すると、フローチャートは、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。このプロセスは、依存側ドメインが保護リソースに関するユーザ要求を受信したときに始まる（ステップ３７２）。図１２または図１３に示した例とは対照的に、図１４に示した例は、ユーザに関する必要なアサーションがない場合に依存側ドメインで受信されるユーザの要求に関連する処理を記述している。この場合、発行側ドメインは、ユーザの要求に必要なアサーションを挿入するためにユーザの要求をインターセプトするかまたはその他の方法で処理する能力を持っていない。たとえば、ユーザは、発信要求が発行側ドメインのポイントオブコンタクト・サーバによってインターセプトされないように、ユニフォーム・リソース・ロケータ（ＵＲＬ）を入力したかまたはリソースへのブックマーク付き参照を使用した可能性がある。このため、依存側ドメインは発行側ドメインからアサーションを要求する。
【０１０９】
次に依存側ドメインは、ユーザのホーム・ドメイン、すなわち、関連発行側ドメインを決定する（ステップ３７４）。ＨＴＴＰベースの実現例では、ユーザは、すでに依存側ドメインとの関係を事前設定しており、その結果、ユーザのクライアント装置で依存側ドメインによって永続Ｃｏｏｋｉｅが設定された可能性がある。この永続Ｃｏｏｋｉｅは、ユーザのホーム・ドメイン、すなわち、発行側ドメインのＩＤを含むことになるであろう。ユーザが何らかの方法でＷｅｂサービス・クライアントを操作するＳＯＡＰベースの実現例では、依存側ドメインにおけるＷｅｂサービスは、トークン要件を含む、ＷＳＤＬ（Ｗｅｂサービス記述言語：Web Services Description Language）によるサービス要件を公示したと考えられる。次にこれは、必要なトークン・タイプを提供するためにユーザのＷｅｂサービス・クライアント／ＳＯＡＰ実現例を必要とするであろう。この要件が達成されなかった場合、Ｗｅｂサービスは技術的にエラーを返すことになるであろう。場合によっては、これは、その要求を適切なトークンで繰り返すことができるように、認証情報を入力するようユーザのＷｅｂサービス・クライアントに促すことができるエラー・コードを返す可能性がある。
【０１１０】
依存側ドメインのポイントオブコンタクト・サーバは、依存側ドメインのトラスト・プロキシによりアサーション要求を開始し（ステップ３７６）、それは発行側ドメインのトラスト・プロキシからユーザに関するアサーションを要求する（ステップ３７８）。この実施形態がＨＴＴＰベースの通信を使用している場合、依存側ドメインのトラスト・プロキシから発行側ドメインのトラスト・プロキシへのアサーション要求は、ユーザのブラウザ・アプリケーションによるリダイレクトを介して依存側ドメインのポイントオブコンタクト・サーバによって発行側ドメインのポイントオブコンタクト・サーバに伝送することができ、そのポイントオブコンタクト・サーバはアサーション要求を発行側ドメインのトラスト・プロキシに転送する。
【０１１１】
この実施形態がＳＯＡＰベースの実現例を使用している場合、依存側パーティは、ユーザのＷｅｂサービス・クライアントにエラー・コードを返すことができる。このエラー・コードにより、Ｗｅｂサービス・クライアントによって認証情報を入力するようユーザに促すことができる。次にＷｅｂサービス・クライアントは、要求されたトークンを生成することになるであろう。依存側ドメインのトラスト・プロキシがＵＤＤＩ（ユニバーサル記述、ディスカバリ、および統合：Universal Description, Discovery, and Integration）レジストリで公示され、ユーザのＷｅｂサービス・クライアントがトラスト・プロキシを見つけられるようにしている場合、ユーザのＷｅｂサービス・クライアントはトラスト・プロキシを直接呼び出すことができるであろう。一般に、このシナリオは内部ユーザについてのみ有効であり、その場合、トラスト・プロキシがインターネット上の公用ＵＤＤＩで公示されるかまたはフェデレーション外で一般にアクセス可能になることはありそうもないので、トラスト・プロキシは企業内の専用ＵＤＤＩで公示されている。
【０１１２】
発行側ドメインのトラスト・プロキシは、アサーション要求が受信された方法をミラーリングする方法で、要求されたアサーションを生成し（ステップ３８０）、それを返す（ステップ３８２）。依存側ドメインのトラスト・プロキシが要求されたアサーションを受信した後（ステップ３８４）、依存側ドメインのトラスト・プロキシはアサーションから情報を抽出し（ステップ３８６）、アサーションを解釈するかあるいは妥当性検査するかまたはその両方を行い（ステップ３８８）、トラスト・プロキシはアサーションの変換のために必要であれば、トラスト・ブローカからの支援を呼び出すことができる。そのアサーションを妥当性検査できない場合、適切なエラー応答が生成されることになるであろう。アサーションが妥当性検査されると想定すると、依存側ドメインのトラスト・プロキシは、保護リソースに関するユーザの要求を達成しようと試みるバックエンド・サービスによる使用に必要な適切なフォーマットでローカル情報を構築する（ステップ３９０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって要求される認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインのポイントオブコンタクト・サーバに返し（ステップ３９２）、次にそれはユーザに関するローカル・セッションを構築し、関連情報とともにユーザの要求を要求されたバックエンド・アプリケーションまたはサービスに転送し（ステップ３９４）、それにより、プロセスを完了する。
【０１１３】
フェデレーテッド・アーキテクチャ内のシングル・サインオン
図６〜図９の説明は本発明によるフェデレーテッド・データ処理環境内のエンティティの動作特性に焦点を合わせているが、図１０〜図１４の説明はこれらのエンティティ間で行われるプロセスのいくつかに焦点を合わせている。これらの説明とは対照的に、ユーザにシングル・サインオン経験を提供しながら、ユーザに関するトランザクションを完了するという目標に焦点を合わせる本発明の説明のために、図１５を参照する。
【０１１４】
換言すれば、以下の説明は、ユーザがユーザのセッション内でシングル・サインオン経験を持つことができる方法に関して本発明の概略視点に焦点を合わせているが、すでに前述したエンティティおよびプロセスについて論ずるものである。セッションは、初期ユーザ認証、すなわち、ログオンから（これを含む）ログアウトまでの１組のトランザクションとして定義することができる。セッション内のユーザのアクションは、部分的に、そのセッションに関してユーザに付与された権限によって支配されることになる。フェデレーション内のユーザは、そのセッション中にアクセスしたフェデレーション・パートナにかかわらず、ユーザが単一認証操作を完了し、そのセッションの期間の間、この認証操作で十分であるシングル・サインオン経験を持つことを期待する。
【０１１５】
ユーザのセッション中に、ユーザは、多くのフェデレーテッド・ドメインにアクセスして、そのドメインによって提供されるＷｅｂサービスを使用することができる。ドメインは、ＵＤＤＩおよびＷＳＤＬなどの標準規格を使用して、そのドメインが提供するサービスの記述を公開することができ、そのいずれも共通データ・フォーマットとしてＸＭＬを使用する。ユーザは、同じくこれらの標準規格に準拠するアプリケーションにより、使用可能なサービスおよびサービス・プロバイダを見つける。ＳＯＡＰは、ＸＭＬで表された要求および応答を伝達するためのパラダイムを提供する。フェデレーテッド環境内のエンティティは、とりわけ、これらの規格を使用することができる。
【０１１６】
シングル・サインオン経験を容易にするために、フェデレーテッド環境をサポートするＷｅｂサービスは、ユーザの認証の証明を提供するためにサード・パーティによって生成された認証アサーションまたはセキュリティ・トークンの使用もサポートすることになる。このアサーションは、そのユーザ用のＩＤとともに、発行側パーティに対するユーザの認証の成功を示すある種の証拠を含むことになる。したがって、ユーザは、あるフェデレーション・パートナに対し、伝統的な認証信用証明情報、たとえば、ユーザ名およびパスワードを提示し、異なるフェデレーション・パートナに対し、認証／発行側パーティによって生成されたＳＡＭＬ認証アサーションを提供することができる。
【０１１７】
Ｗｅｂサービス環境内の認証は、企業が許可クライアントにアクセスを制限できるように、Ｗｅｂサービス要求の請求されたＩＤを検証する行為である。Ｗｅｂサービスを要求するかまたは呼び出すユーザは、ほとんど常に認証され、したがって、本発明のフェデレーテッド環境内の認証の必要性はユーザ認証のためのＷｅｂサービスの現行要件とは少しも異ならないものである。また、フェデレーテッド環境により、Ｗｅｂサービスまたはその他のアプリケーションはＷｅｂサービスを要求することができ、これらのＷｅｂサービスも認証されることになるであろう。
【０１１８】
フェデレーテッド・セッションに参加していないユーザの認証は、本発明のフェデレーテッド・アーキテクチャによる影響を受けない。たとえば、特定のドメインの非フェデレーテッド・リソースにアクセスするためにＨＴＴＰ／Ｓによる用紙ベースの認証メカニズムで認証を受ける既存のユーザは、フェデレーテッド環境に関するそのドメインのサポートを導入することによって影響されない。認証は、部分的に、ポイントオブコンタクト・サーバによって処理され、次にそのポイントオブコンタクト・サーバが個別のトラスト・プロキシ・コンポーネントを呼び出すことができる。ポイントオブコンタクト・サーバの使用は、既存のドメインのインフラストラクチャに対する影響を最小限にする。たとえば、ポイントオブコンタクト・サーバは、そのドメインのバックエンドまたはレガシー・アプリケーションおよびシステムによって処理されるすべての非フェデレーテッド要求を通過するように構成することができる。
【０１１９】
ポイントオブコンタクト・サーバは、基本認証、用紙ベースの認証、またはその他の何らかの認証方法などのＨＴＴＰベースの認証方法を呼び出すことを選択することができる。また、ポイントオブコンタクト・サーバは、ＳＡＭＬ認証アサーションなど、認証の証明としてユーザによって提示されたアサーションを認識することにより、フェデレーテッド・トラスト・ドメインもサポートし、そのアサーションは企業トラスト・ドメイン間を越えている。ポイントオブコンタクト・サーバはトラスト・プロキシを呼び出すことができ、次にそのトラスト・プロキシは認証信用証明情報／セキュリティ・トークンの妥当性検査のためにそのセキュリティ・トークン・サービスを呼び出すことができる。
【０１２０】
Ｗｅｂサービスまたはその他のアプリケーションの認証は、ユーザの認証と同じプロセスを有する。Ｗｅｂサービスからの要求は、認証アサーションを含むセキュリティ・トークンを伝達し、このセキュリティ・トークンはユーザによって提示されるトークンと同じようにトラスト・プロキシ／セキュリティ・トークン・サービスによって妥当性検査されることになるであろう。ＷｅｂサービスはＵＤＤＩで公示された要求されたサービスによってどの認証アサーション／セキュリティ・トークンが要求されているかをすでに発見していると考えられるので、Ｗｅｂサービスからの要求は必ずそれとともにこのトークンを伝達しなければならない。
【０１２１】
次に図１５を参照すると、ブロック図は、フェデレーテッド・シングル・サインオン操作をサポートするフェデレーテッド環境を描写している。ユーザ４００は、クライアント装置およびブラウザなどの適切なクライアント・アプリケーションにより、企業／ドメイン４１０によって提供されるＷｅｂサービスにアクセスすることを所望し、その企業／ドメインは、フェデレーテッド環境内のフェデレーテッド・ドメインとして動作するデータ処理システムをサポートする。ドメイン４１０はポイントオブコンタクト・サーバ４１２およびトラスト・プロキシ４１４をサポートし、同様に、ドメイン４２０はポイントオブコンタクト・サーバ４２２およびトラスト・プロキシ４２４をサポートし、ドメイン４３０はポイントオブコンタクト・サーバ４３２およびトラスト・プロキシ４３４をサポートする。トラスト・プロキシは、上述の通り、支援のためにトラスト・ブローカ４５０を当てにする。追加のドメインおよびトラスト・プロキシもフェデレーテッド環境に参加することができる。図１５は、ドメイン４１０とドメイン４２０との間のフェデレーテッド・シングル・サインオン操作を記述しており、同様の操作はドメイン４１０とドメイン４３０との間でも行うことができる。
【０１２２】
ユーザはドメイン４１０に関する認証操作を完了し、この認証操作はポイントオブコンタクト・サーバ４１２によって処理される。たとえば、アクセス制御またはパーソナライゼーションのために、認証済みＩＤを必要とする何らかのリソースへのアクセスをユーザが要求すると、認証操作がトリガされる。ポイントオブコンタクト・サーバ４１２は、レガシー認証サービスを呼び出す場合もあれば、トラスト・プロキシ４１４を呼び出してユーザが提示した認証信用証明情報を妥当性検査する場合もある。ドメイン４１０は、ユーザのフェデレーテッド・セッションの期間中、ユーザのホーム・ドメインになる。
【０１２３】
その後のある時点で、ユーザは、同じくフェデレーテッド・ドメインをサポートする企業４２０などのフェデレーション・パートナにおいてトランザクションを開始し、それにより、フェデレーテッド・シングル・サインオン操作をトリガする。たとえば、ユーザがドメイン４２０で新しいトランザクションを開始する場合もあれば、ユーザの元のトランザクションが他のドメインにおける１つまたは複数の追加トランザクションにカスケードする場合もある。もう１つの例として、ユーザは、たとえば、ドメイン４１０内でホストとして処理されるＷｅｂページ上の特殊リンクを選択するか、またはドメイン４１０内でホストとして処理されるがドメイン４２０内でホストとして処理されるリソースを表示するポータル・ページを要求することにより、ポイントオブコンタクト・サーバ４１２を介してドメイン４２０内のリソースへのフェデレーテッド・シングル・サインオン操作を呼び出すこともできる。ポイントオブコンタクト・サーバ４１２は、ドメイン４２０によって理解または信頼されるようにフォーマットされた、そのユーザ用のフェデレーション・シングル・サインオン・トークンを生成するために、トラスト・プロキシ４１４に要求を送信する。トラスト・プロキシ４１４はこのトークンをポイントオブコンタクト・サーバ４１２に返し、そのポイントオブコンタクト・サーバ４１２はこのトークンをドメイン内のポイントオブコンタクト・サーバ４２２に送信する。ドメイン４１０は、依存側パーティとして動作するドメイン４２０のユーザのための発行側パーティとして動作する。ユーザのトークンはユーザの要求とともにドメイン４２０に転送されると考えられ、このトークンはユーザのブラウザによるＨＴＴＰリダイレクトを使用して送信される場合もあれば、トラスト・プロキシ４１４によって供給されるトークンで識別されるユーザに代わって（ＨＴＴＰまたはＨＴＴＰによるＳＯＡＰにより）ポイントオブコンタクト・サーバ４２２の要求を直接呼び出すことにより送信される場合もある。
【０１２４】
ポイントオブコンタクト・サーバ４２２は、フェデレーション・シングル・サインオン・トークンとともにその要求を受信し、トラスト・プロキシ４２４を呼び出す。トラスト・プロキシ４２４は、フェデレーション・シングル・サインオン・トークンを受信し、そのトークンを妥当性検査し、そのトークンが有効で信頼されているものと想定して、ユーザのためにローカルで有効なトークンを生成する。トラスト・プロキシ４２４はローカルで有効なトークンをポイントオブコンタクト・サーバ４２２に返し、そのポイントオブコンタクト・サーバはドメイン４２０内でそのユーザに関するセッションを確立する。必要であれば、ポイントオブコンタクト・サーバ４２２は、他のフェデレーテッド・パートナにおいてフェデレーテッド・シングル・サインオンを開始することができる。
【０１２５】
ドメイン４２０におけるトークンの妥当性検査は、おそらく、セキュリティ・トークン・サービスからの支援により、トラスト・プロキシ４２４によって処理される。ドメイン４１０によって提示されたトークンのタイプに応じて、セキュリティ・トークン・サービスは、ドメイン４２０のユーザ・レジストリにアクセスする必要がある場合もある。たとえば、ドメイン４２０は、ドメイン４２０のユーザ・レジストリに照らし合わせて妥当性検査すべき、ユーザの名前とパスワードを含むバイナリ・セキュリティ・トークンを提供することができる。このため、この例では、企業は単に、フェデレーテッド・パートナからのセキュリティ・トークンを妥当性検査するだけである。ドメイン４１０と４２０との信頼関係は、ユーザに代わってドメイン４１０によって提示されたセキュリティ・トークンをドメイン４２０が理解し信頼できることを保証する。
【０１２６】
フェデレーテッド・シングル・サインオンは、ユーザに代わって依存側ドメインに提示されるセキュリティ・トークンの妥当性検査のみならず、セキュリティ・トークンに含まれる情報に基づいて依存側ドメインにおいてローカルで有効なユーザＩＤを決定することも必要とする。このような関係を確立するために必要な直接的信頼関係と事業協定の結果の１つとして、少なくとも１つのパーティ、発行側ドメインあるいは依存側ドメインのいずれか一方またはその両方は、発行側ドメインによって提供された情報を依存側ドメインで有効なＩＤに変換する方法を把握することになる。上記の簡単な例では、発行側ドメイン、すなわち、ドメイン４１０が依存側ドメイン、すなわち、ドメイン４２０にドメイン４２０で有効なユーザＩＤを提供できるものと想定されていた。そのシナリオでは、依存側ドメインは、ＩＤマッピング機能を呼び出す必要はなかった。ドメイン４２０におけるトラスト・プロキシ４２４は、このユーザの「保証人となる」、ユーザ用のセキュリティ・トークンを生成することになる。受諾されるトークンのタイプ、トークン上で必要なシグニチャ、およびその他の要件はいずれも、フェデレーションの事業協定の一部として事前確立される。ＩＤ変換を支配するルールおよびアルゴリズムも、フェデレーションの事業協定の一部として事前確立される。２つの参加者間の直接的信頼関係の場合、ＩＤ変換アルゴリズムは、その２つのパーティについて確立されていることになり、フェデレーション内の他のどのパーティにも関連しない可能性がある。
【０１２７】
しかし、ドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングする方法を発行側ドメインが把握することが常に実情であるわけではない。場合によっては、このマッピングを実行する方法を把握しているのは依存側ドメインである可能性があり、さらに他の場合には、いずれのパーティもこの変換を実行する方法を把握しなくなり、その場合、サード・パーティのトラスト・ブローカを呼び出す必要がある可能性もある。換言すれば、ブローカリングされた信頼関係の場合、発行側ドメインと依存側ドメインは互いに直接的信頼関係を持っていない。しかし、それらのドメインは、トラスト・ブローカ４５０などのトラスト・ブローカとの直接的信頼関係を持つことになる。ＩＤマッピング・ルールおよびアルゴリズムは、この関係の一部として確立されたものになり、トラスト・ブローカはこの情報を使用して、ブローカリングされた信頼関係に必要なＩＤ変換を支援することになる。
【０１２８】
ドメイン４２０は、ポイントオブコンタクト・サーバ４２２においてドメイン４１０によって発行されたトークンを受信し、そのポイントオブコンタクト・サーバはトラスト・プロキシ４２４を呼び出して、トークンを妥当性検査し、ＩＤマッピングを実行する。この場合、トラスト・プロキシ４２４はドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングすることができないので、トラスト・プロキシ４２４はトラスト・ブローカ４５０を呼び出し、そのトラスト・ブローカがトークンを妥当性検査し、ＩＤマッピングを実行する。そのユーザ用のローカルＩＤを入手した後、トラスト・プロキシ４２４は、おそらくそのセキュリティ・トークン・サービスにより、ドメイン４２０においてバックエンド・アプリケーションによって要求される任意のローカル・トークンを生成することができ、たとえば、ポイントオブコンタクト・サーバからアプリケーション・サーバへのシングル・サインオンを容易にするためにＫｅｒｂｅｒｏｓトークンが要求される可能性がある。必要であれば、ローカルで有効なトークンを入手した後、ポイントオブコンタクト・サーバはそのユーザ用のローカル・セッションを構築することができる。また、ポイントオブコンタクト・サーバは、ユーザ要求の粗雑な許可を処理し、ドメイン４２０内の適切なアプリケーション・サーバに許可された要求を転送することになる。
【０１２９】
ユーザのセッションは、ユーザがログアウトまたはサインオフしたときに終了する。ユーザがそのホーム・ドメインとのセッションからログアウトすると、ホーム・ドメインはすべての依存側ドメイン、すなわち、それがセキュリティ・トークンを発行したドメインに通知し、これらのドメインにおいてユーザ・ログアウトを呼び出すことになるであろう。次にこれらの依存側ドメインのいずれかが同じユーザのための発行側ドメインとして動作した場合、そのドメインは、カスケード式にユーザ・ログアウト要求についてその依存側ドメインのすべてに通知することになるであろう。各ドメインのトラスト・プロキシは、ユーザのログアウト要求をすべての依存側ドメインに通知することを担当することになり、トラスト・プロキシはこのプロセスの一部としてトラスト・ブローカを呼び出すことができる。
【０１３０】
上記で提供されている本発明の詳細な説明を考慮すると、本発明の利点は明らかであるはずである。従来技術のソリューションは、ドメイン・セキュリティ・サービスを階層として編成し、それにより、ドメインは堅い信頼関係と本質的に互換性のある技術を有する必要がある。その他の手法は、認証アサーションに均一フォーマットを賦課するかまたは認証アサーションの転送を可能にせず、ときには、それからローカル・アサーションが構築される認証済みＩＤを転送する。
【０１３１】
本発明の利点の中で、トラスト・プロキシは、所与のドメイン内の既存のセキュリティ・サービスが、同じトラスト・ルートに加入するかまたは同じ信頼確立技術を使用する必要なしに、他のドメインとの信頼関係を確立できるようにするものである。このため、本発明のフェデレーテッド・アーキテクチャは、エンティティの疎結合を提供する。ホーム・ドメインは認証を管理し、各ドメインはそれ自体の登録済みユーザのみの認証を管理する。各ドメインは、ユーザＩＤおよび属性に関する任意の他のドメインのステートメントを自由に受諾、拒否、または変更することができる。依存側ドメインは、ＩＤおよび属性に関する発行側ドメイン（最終的に、ホーム・ドメイン）のアサーションを当てにするが、各ドメインは任意の認証プロトコルを実現することができ、そのドメインがフェデレーションに参加するために前にサポートされていないプロトコルを実現するよう所与のドメイン内のアプリケーションを変更する必要はない。フェデレーションは特定のトラスト・モデルを必要とせず、１組のエンティティは、参加エンティティがすでに確立している可能性のあるトラスト・モデルに適合するフェデレーションを形成することができる。アサーション変換は、トラスト・プロキシあるいはトラスト・ブローカまたはその両方でのみ行われ、フェデレーション・アーキテクチャは、既存のレガシー・システムに対する最小限の影響で実現可能なフロントエンド・インフラストラクチャとして動作する。
【０１３２】
フェデレーションにより、ユーザは、シングル・サインオン方式で所与のフェデレーション内の種々のサイトをシームレスにトラバースすることができる。フェデレーション参加者間で信頼関係が確立されているので、ある参加者はあるユーザを認証し、その後、そのユーザのための発行側パーティとして動作することができる。他のフェデレーション・パートナは依存側パーティになり、それにより、そのパートナは、ユーザの直接的関与なしに発行側パーティによってユーザに関して提供される情報を当てにする。
【０１３３】
完全に機能するデータ処理システムに関連して本発明を説明してきたが、当業者であれば、配布を実行するために実際に使用される特定のタイプの信号運搬メディアにかかわらず、本発明のプロセスがコンピュータ可読メディア内の命令の形および様々なその他の形で配布可能であることが分かることは、留意すべき重要なことである。コンピュータ可読メディアの例としては、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フレキシブル・ディスク、ハードディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどのメディア、ならびにデジタルおよびアナログ通信リンクなどの伝送タイプのメディアを含む。
【０１３４】
１つの方法は一般に、所望の結果に至る首尾一貫したステップのシーケンスであると考えられている。これらのステップは、物理量の物理的操作を必要とする。必ずではないが、通常、これらの量は、保管、転送、結合、比較、およびその他の操作が可能な電気信号または磁気信号の形を取る。時には、主に一般的使用の理由で、これらの信号をビット、値、パラメータ、項目、エレメント、オブジェクト、記号、文字、項、数などと呼ぶと便利である。しかし、これらの用語および同様の用語はいずれも適切な物理量に関連付けられるものであり、単にこれらの量に適用された便利なラベルにすぎないことに留意されたい。
【０１３５】
本発明の説明は、例示のために提示されたものであり、網羅的なものまたは開示された実施形態に限定されるものではない。当業者には、多くの変更および変形が明らかになるであろう。実施形態は、本発明の原理およびその実際的な適用例を説明し、他の企図された使用法に適している可能性がある様々な変更を含む様々な実施形態を実現するために他の当業者が本発明を理解できるようにするために選択されたものである。
【図面の簡単な説明】
【０１３６】
【図１】そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを示す図である。
【図２】本発明を実現可能なデータ処理システム内で使用できる典型的なコンピュータ・アーキテクチャを示す図である。
【図３】クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示すデータ・フロー・ダイアグラムである。
【図４】本発明を実現可能な典型的なＷｅｂベース環境を示すネットワーク・ダイアグラムを示す図である。
【図５】ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を示すブロック図である。
【図６】第１のフェデレーテッド企業に対してユーザによって開始され、それに応答して、フェデレーテッド環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関するフェデレーテッド環境の用語を示すブロック図である。
【図７】本発明の一実施形態により本発明のフェデレーテッド・アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を示すブロック図である。
【図８】本発明の一実現例によるフェデレーテッド・アーキテクチャを示すブロック図である。
【図９】本発明によりトラスト・プロキシとトラスト・ブローカとを使用するフェデレーテッド・ドメイン間の例示的な１組の信頼関係を示すブロック図である。
【図１０】フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを示すフローチャートである。
【図１１】アサーションを取り壊すための依存側ドメインにおける汎用プロセスを示すフローチャートである。
【図１２】発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。
【図１３】依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。
【図１４】要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを示すフローチャートである。
【図１５】フェデレーテッド・シングル・サインオン操作をサポートするフェデレーテッド環境を示すブロック図である。
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、特に、マルチコンピュータ・データ転送のための方法および装置に関する。より詳細には、本発明は、ネットワーク・コンピュータ・システムを対象とする。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、本出願人による以下の出願に関連するものである。
出願日未定（filed (TBD)）で、「Efficient browser-based identity management providingpersonal 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 Consolidated Sign-off in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４６１ＵＳ１）
【０００３】
企業は一般に、インターネットを含む様々なネットワーク全体にわたって保護リソースへのセキュア・アクセスを許可ユーザにフレンドリに提供することを望んでいる。セキュア認証メカニズムを提供することは保護リソースへの無許可アクセスのリスクを低減するが、反面、同じ認証メカニズムが保護リソースとのユーザ対話にとって障害になる場合もある。ユーザは一般に、これらのアプリケーションをサポートする特定の各システムを保護する認証の障害を意識せずに、あるアプリケーションとの対話から他のアプリケーションに移行できることを望む。
【０００４】
ユーザがより洗練されるのにつけ、ユーザの負担が削減されるようにコンピュータ・システムがその動作を調整することをユーザは期待する。このようなタイプの期待は認証プロセスにも適用される。ユーザが何らかのコンピュータ・システムによって認証されると、その認証は、そのユーザにとってほとんど見えない様々なコンピュータ・アーキテクチャ境界を意識せずに、そのユーザの作業セッション全体にわたってまたは少なくとも特定の期間の間、有効でなければならないと、ユーザが期待し得る。企業は一般に、ユーザをなだめるためだけでなく、ユーザ効率（ユーザ効率が従業員の生産性に関連するか顧客満足度に関連するかにかかわらず）を高めるためにも、その配置システムの動作特性においてこのような期待に応えようとする。
【０００５】
より具体的には、共通ブラウザによりアクセス可能なＷｅｂベース・ユーザ・インターフェースを多くのアプリケーションが有する現行コンピューティング環境により、ユーザは、より使いやすいこと、あるＷｅｂベース・アプリケーションから他のＷｅｂベース・アプリケーションへの移行に対する障害が低いかまたは少ないことを期待する。これに関連して、ユーザは、特定の各ドメインを保護する認証の障害を意識せずに、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションに移行できることを期待するようになる。しかし、多くのシステムが使いやすいＷｅｂベース・インターフェースによりセキュア認証を提供する場合でも、ユーザは依然として、１組のドメインの全域でユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れざるを得ない可能性がある。所与の時間フレーム内にユーザを複数の認証プロセスにかけることは、ユーザの効率に著しく影響する可能性がある。
【０００６】
ユーザおよびコンピュータ・システム管理者の認証負担を低減するために、様々な技法が使用されてきた。これらの技法は、ユーザがサインオン操作を完了した後、すなわち、認証された後に、そのユーザはその後、他の認証操作を実行する必要がないという共通目的があるので、一般に「シングル・サインオン」（ＳＳＯ：single-sign-on）プロセスと記述される。このため、目標は、ユーザが特定のユーザ・セッション中に１つの認証プロセスのみ完了することを要求されるであろうということである。
【０００７】
このようなシングル・サインオン・ソリューションは、所与の企業内で実現したときは上首尾であった。しかし、より多くの企業がインターネットによって接続されたｅ−ｃｏｍｍｅｒｃｅマーケットプレイスまたはその他のコラボレーション努力に参加するにつれて、複数の認証プロセスまたはシステムによって提起される障害はますます一般的なものになっている。企業間の以前のシングル・サインオン・ソリューションは、参加企業間の事業協定が事前に確立されている同種環境に限られていた。これらの事業協定は、部分的に、信頼を確立し、企業間で情報を安全に転送する方法を制限し定義するために使用される。また、これらの事業協定は、ある企業から他の企業にユーザＩＤ（identity）を変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。
【０００８】
換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合が可能である。
【０００９】
参加企業はこれらの以前のシングル・サインオン・ソリューションを使用することにより同種環境内で協働することができるが、複数の同種環境、たとえば、相互接続ｅ−ｃｏｍｍｅｒｃｅマーケットプレイスを相互接続する必要性または要望を考慮すると、これらの環境は限定的なものである。
【特許文献１】出願日未定（filed (TBD)）で、「Efficient browser-based identity management providingpersonal 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 Consolidated Sign-off in a HeterogeneousFederated Environment」という発明の名称の米国特許出願（代理人整理番号ＡＵＳ９２００２０４６１ＵＳ１）
【非特許文献１】１９９３年９月発行のInternetEngineering Task Force (IETF) Request for Comments (RFC) 1510に掲載されたＫｏｈｌ他による「TheKerberos Network Authentication Service (V5)」
【非特許文献２】２００２年５月３１日発行のCommitteeSpecification 01に掲載された「Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML)」
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、参加企業間の所定の事業および技術変換協定がない場合に企業がユーザに対して同様のシングル・サインオン経験を提供できる方法およびシステムを備えることは有利なことになるであろう。
【課題を解決するための手段】
【００１１】
フェデレーテッド（federated）ドメインがフェデレーテッド環境内で対話する方法、装置、システム、およびコンピュータ・プログラムが提示される。あるフェデレーション（federation）内のドメインは、他のフェデレーテッド・ドメインのユーザに関するフェデレーテッド・シングル・サイン操作を開始することができる。あるドメイン内のポイントオブコンタクト（point-of-contact）サーバは、そのドメインとフェデレーションとの間の信頼関係を管理するためにそのドメイン内のトラスト・プロキシ（trustproxy）を当てにする。トラスト・プロキシは、必要に応じて他のフェデレーテッド・ドメインからのアサーションを解釈する。トラスト・プロキシは１つまたは複数のトラスト・ブローカ（trustbroker）との信頼関係を有することができ、トラスト・プロキシはアサーションを解釈する際の支援のためにトラスト・ブローカを当てにすることができる。
【００１２】
本発明に特有と思われる新規の特徴は特許請求の範囲に示されている。本発明そのもの、その他の目的、およびその利点は、添付図面に併せて読んだときに以下に示す詳細な説明を参照することにより最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１３】
一般に、本発明を含むかまたは本発明に関する可能性のある装置は多様なデータ処理技術を含む。したがって、本発明をより詳細に説明する前に、背景として、分散データ処理システム内のハードウェアおよびソフトウェア・コンポーネントの典型的な編成について説明する。
【００１４】
次に添付図面を参照すると、図１は、そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを描写している。分散データ処理システム１００はネットワーク１０１を含み、そのネットワークは、分散データ処理システム１００内で一緒に接続された様々な装置およびコンピュータ間の通信リンクを提供するために使用できるメディアである。ネットワーク１０１は、ワイヤもしくは光ファイバ・ケーブルなどの永続接続または電話もしくはワイヤレス通信により行われる一時接続を含むことができる。描写した例では、サーバ１０２およびサーバ１０３は、ストレージ・ユニット１０４とともにネットワーク１０１に接続されている。加えて、クライアント１０５〜１０７もネットワーク１０１に接続されている。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ：personal digital assistant）などの多様なコンピューティング・デバイスによって表すことができる。分散データ処理システム１００は、図示されていない追加のサーバ、クライアント、ルータ、その他の装置、およびピアツーピア・アーキテクチャを含むことができる。
【００１５】
描写した例では、分散データ処理システム１００は、ＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル（TransportControl Protocol/Internet Protocol））、ＨＴＴＰ（ハイパーテキスト転送プロトコル（HyperText TransportProtocol））などの様々なプロトコルを使用して互いに通信するネットワークおよびゲートウェイの世界的な集合を表すネットワーク１０１とともにインターネットを含むことができる。当然のことながら、分散データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：localarea network）、または広域ネットワーク（ＷＡＮ：wide area network）などのいくつかの異なるタイプのネットワークも含むことができる。たとえば、サーバ１０２はクライアント１０９およびネットワーク１１０を直接サポートし、そのネットワークはワイヤレス通信リンクを組み込んでいる。ネットワーク対応電話（network-enabledphone）１１１はワイヤレス・リンク１１２によりネットワーク１１０に接続し、ＰＤＡ１１３はワイヤレス・リンク１１４によりネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワーク（personalad-hoc network）を作成するために、Ｂｌｕｅｔｏｏｔｈ（商標）ワイヤレス技術などの適切な技術を使用して、ワイヤレス・リンク１１５を越えて両者間でデータを直接転送することもできる。同様に、ＰＤＡ１１３は、ワイヤレス通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。
【００１６】
本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実現することができるであろう。図１は、本発明に関するアーキテクチャ制限としてのものではなく、異機種コンピューティング環境の一例としてのものである。
【００１７】
次に図２を参照すると、同図は、本発明を実現可能な、図１に示したものなどのデータ処理システムの典型的なコンピュータ・アーキテクチャを描写している。データ処理システム１２０は、内部システム・バス１２３に接続された１つまたは複数の中央演算処理装置（ＣＰＵ：central processing unit）１２２を含み、その内部システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ：randomaccess memory）１２４、読取り専用メモリ１２６、および入出力アダプタ１２８を相互接続し、その入出力アダプタ１２８は、プリンタ１３０、ディスク・ユニット１３２、またはオーディオ出力システムなどの図示していないその他の装置などの様々な入出力装置をサポートする。また、システム・バス１２３は、通信リンク１３６へのアクセスを可能にする通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０とマウス１４２、またはタッチ・スクリーン、スタイラス、マイクロホンなどの図示していないその他の装置などの様々なユーザ装置を接続する。ディスプレイ・アダプタ１４４はシステム・バス１２３をディスプレイ装置１４６に接続する。
【００１８】
当業者であれば、図２のハードウェアはシステム実現例に応じて様々になる可能性があることが分かるであろう。たとえば、システムは、Ｉｎｔｅｌ（商標）のＰｅｎｔｉｕｍ（商標）ベースのプロセッサおよびデジタル・シグナル・プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性および不揮発性メモリとを有する可能性がある。図２に描写したハードウェアに加えてまたはその代わりに、その他の周辺装置を使用することもできる。描写した例は、本発明に関するアーキテクチャ制限を示すためのものではない。
【００１９】
様々なハードウェア・プラットフォームで実現できることに加えて、本発明は、様々なソフトウェア環境で実現することができる。各データ処理システム内のプログラム実行を制御するために、典型的なオペレーティング・システムを使用することができる。たとえば、ある装置はＵｎｉｘ（商標）オペレーティング・システムを実行することができ、他の装置は単純なＪａｖａ（商標）ランタイム環境を含む。代表的なコンピュータ・プラットフォームはブラウザを含むことができ、そのブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ：Extensible Markup Language）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：Hypertext MarkupLanguage）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ：Handheld Device Markup Language）、ワイヤレス・マークアップ言語（ＷＭＬ：WirelessMarkup Language）、および様々なその他のフォーマットおよびタイプのファイルなど、様々なフォーマットのハイパーテキスト・ドキュメントにアクセスするための周知のソフトウェア・アプリケーションである。また、図１に示した分散データ処理システムは、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されていることにも留意されたい。
【００２０】
次に図３を参照すると、データ・フロー・ダイアグラムは、クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示している。図示した通り、クライアント・ワークステーション１５０側のユーザは、クライアント・ワークステーション上で実行されるユーザのＷｅｂブラウザにより、コンピュータ・ネットワークを越えてサーバ１５１上の保護リソースにアクセスしようとする。保護リソースは、認証許可ユーザのみによってアクセス可能なユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）、またはより一般的には、ユニフォーム・リソース・アイデンティファイア（ＵＲＬ：UniformResource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示した通り、インターネット、イントラネット、またはその他のネットワークにすることができ、サーバは、Ｗｅｂアプリケーション・サーバ（ＷＡＳ：WebApplication Server）、サーバ・アプリケーション、サーブレット・プロセスなどにすることができる。
【００２１】
プロセスは、ユーザが「ｉｂｍ．ｃｏｍ」というドメイン内のＷｅｂページなどの保護リソースを要求したときに開始される（ステップ１５２）。Ｗｅｂブラウザ（または関連アプリケーションもしくはアプレット）は、「ｉｂｍ．ｃｏｍ」というドメインをホストとして処理するＷｅｂサーバに送信されるＨＴＴＰ要求メッセージを生成する（ステップ１５３）。サーバは、それがクライアントに関するアクティブ・セッションを持っていないと判断し（ステップ１５４）、したがって、サーバは、何らかのタイプの認証質問（authentication challenge）をクライアントに送信することにより（ステップ１５５）、認証プロセスを実行するようユーザに要求する。認証質問は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）形式などの様々なフォーマットにすることができる。次にユーザは、ユーザＩＤおよび関連パスワードなどの要求された情報または必要な情報を提供する（ステップ１５６）か、またはクライアントは特定の情報を自動的に返す場合もある。
【００２２】
認証応答情報はサーバに送信され（ステップ１５７）、その時点でサーバは、たとえば、前にサブミットされた登録情報を検索し、提示された認証情報とユーザの保管情報とを突き合わせることにより、ユーザまたはクライアントを認証する（ステップ１５８）。認証が成功したと想定して、認証ユーザまたはクライアントに関するアクティブ・セッションが確立される。
【００２３】
次にサーバは、要求されたＷｅｂページを検索し、ＨＴＴＰ応答メッセージをクライアントに送信する（ステップ１５９）。その時点でユーザは、ハイパーテキスト・リンクをクリックすることによりブラウザ内で「ｉｂｍ．ｃｏｍ」内の他のページを要求することができ（ステップ１６０）、ブラウザは他のＨＴＴＰ要求をサーバに送信する（ステップ１６１）。その時点でサーバは、ユーザがアクティブ・セッションを持っていることを認識し（ステップ１６２）、サーバは他のＨＴＴＰ応答メッセージで要求されたＷｅｂページをクライアントに返送する（ステップ１６３）。図３は典型的な従来技術のプロセスを描写しているが、アクティブ・セッションを備えたユーザを識別するためにＣｏｏｋｉｅを使用することなど、他の代替セッション状態管理技法を描写することもでき、認証を証明するために使用されるのと同じＣｏｏｋｉｅを使用することを含む可能性もあることに留意されたい。
【００２４】
次に図４を参照すると、ネットワーク・ダイアグラムは、本発明を実現可能な典型的なＷｅｂベース環境を示している。この環境では、クライアント１７１側のブラウザ１７０のユーザは、ＤＮＳドメイン１７３内のＷｅｂアプリケーション・サーバ１７２上またはＤＮＳドメイン１７５内のＷｅｂアプリケーション・サーバ１７４上の保護リソースにアクセスすることを所望する。
【００２５】
図３に示したものと同様に、ユーザは多くのドメインのうちの１つで保護リソースを要求することができる。特定のドメインにおいて単一サーバのみを示す図３とは対照的に、図４の各ドメインは複数のサーバを有する。特に、各ドメインは関連認証サーバ１７６および１７７を有することができる。
【００２６】
この例では、クライアント１７１がドメイン１７３で保護リソースに関する要求を発行した後、Ｗｅｂアプリケーション・サーバ１７２は、それがクライアント１７１に関するアクティブ・セッションを持っていないと判断し、認証サーバ１７６がクライアント１７１との適切な認証操作を実行することを要求する。認証サーバ１７６は、認証操作の結果をＷｅｂアプリケーション・サーバ１７２に伝達する。ユーザ（またはユーザに代わってブラウザ１７０またはクライアント１７１）が正常に認証された場合、Ｗｅｂアプリケーション・サーバ１７２は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。概して、ユーザが認証サーバによって認証されると、Ｃｏｏｋｉｅを設定し、それをブラウザ内のＣｏｏｋｉｅキャッシュに保管することができる。図４は単に、特に認証操作を実行するために、あるドメインの処理リソースを複数サーバ間で共用できる方法の一例に過ぎない。
【００２７】
同様に、クライアント１７１がドメイン１７５で保護リソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証操作を実行し、その後、Ｗｅｂアプリケーション・サーバ１７４は、クライアント１７１に関するセッションを確立し、要求された保護リソースを返す。
【００２８】
このため、図４は、クライアント１７１が異なるドメインにおける複数の並行セッションを持つことができるが、それらの並行セッションを確立するために複数の認証操作を完了する必要があることを示している。
【００２９】
次に図５を参照すると、ブロック図は、ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を描写している。もう一度、図３および図４を参照すると、ユーザは、図３に示した通り、被制御リソースにアクセスする前に認証操作を完了する必要がある可能性がある。図３に示していないが、ユーザを認証するために必要なユーザ情報を検索し使用するために、サーバ１５１上に認証マネージャを配置することができる。図４に示した通り、ユーザは異なるドメイン１７３および１７５内で複数の現行セッションを持っている可能性があり、それらは図４に示されていないが、各ドメインは、認証サーバの代わりにまたはそれに加えて認証マネージャを使用することができる。同様に、図５は１組のドメインも描写しており、そのそれぞれは何らかのタイプの認証マネージャをサポートする。図５は、各ドメインに関する認証操作を完了することをユーザに要求する複数のドメインにアクセスするときにユーザが経験する可能性のある障害のいくつかを示している。
【００３０】
ユーザ１９０はＩＳＰドメイン１９１で登録することができ、そのドメイン１９１は、ドメイン１９１に関するトランザクションを完了するためにユーザ１９０を認証する認証マネージャ１９２をサポートすることができる。ＩＳＰドメイン１９１は、インターネット接続サービス、Ｅメール・サービス、およびおそらくその他のｅ−ｃｏｍｍｅｒｃｅサービスを提供するインターネット・サービス・プロバイダ（ＩＳＰ：Internet Service Provider）にすることができる。代わって、ＩＳＰドメイン１９１は、ユーザ１９０によって頻繁にアクセスされるインターネット・ポータルにすることもできる。
【００３１】
同様に、ドメイン１９３、１９５、および１９７は、典型的なＷｅｂサービス・プロバイダを表している。行政ドメイン１９３は、様々な行政関連トランザクションを完了するためにユーザを認証する認証マネージャ１９４をサポートする。銀行用ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する認証マネージャ１９６をサポートする。ｅ−ｃｏｍｍｅｒｃｅドメイン１９７は、オンライン購入を完了するためにユーザを認証する認証マネージャ１９８をサポートする。
【００３２】
上記の通り、異なるドメインでリソースにアクセスすることにより、ユーザがインターネットまたはワールド・ワイド・ウェブ内のあるドメインから他のドメインに移動しようと試みる場合、ユーザは、複数のユーザ認証要求または要件にかけられる可能性があり、それは１組のドメインの全域でユーザの進行を著しく遅らせる可能性がある。例示的な環境として図５を使用すると、ユーザ１９０は、少なくとも１８歳であり、有効な運転免許証、有効なクレジット・カード、および米国銀行預金口座を有するユーザに制限されているオンライン・サービスをユーザが購入しようと試みているｅ−ｃｏｍｍｅｒｃｅドメイン１９７との複雑なオンライン・トランザクションに関係する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７を伴う可能性がある。
【００３３】
概して、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内のＩＤを維持していない可能性がある。この例では、ユーザ１９０は、そのユーザのＩＳＰに自分のＩＤを登録している可能性があるが、オンライン・トランザクションを完了するためには、ユーザは、ドメイン１９３、１９５、および１９７に対する認証も受ける必要がある可能性がある。それぞれのドメインがそのユーザに関するＩＤを維持していない場合、そのユーザのオンライン・トランザクションは失敗する可能性がある。ユーザが各ドメインによって認証される場合でも、そのユーザのトランザクションを完了するために異なるドメインがそれらの間で情報を転送できることは保証されていない。図５に示したユーザ１９０の場合、シングル・サインオンのために、ユーザ１９０が第１のＷｅｂサイト、たとえば、ＩＳＰ１９１に対する認証を受け、次にドメイン１９３、１９５、および１９７などの他のＷｅｂサービス・プロバイダに認証トークンを転送できるようにする従来技術の環境はまったく存在しない。
【００３４】
何らかの現行技術に関する前述の簡単な説明を考慮すると、残りの図面の説明は、本発明が機能しうるフェデレーテッド・コンピュータ環境に関するものである。しかし、本発明をより詳細に論ずる前に、いくつかの用語について紹介する。
【００３５】
用語
「エンティティ」または「パーティ」という用語は一般に、ある組織、個人、またはシステムに代わって機能する組織、個人、または他のシステムを指す。「ドメイン」という用語はネットワーク環境内の追加の特性を意味するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は区別なく使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（ドメイン・ネーム・システム）ドメイン、またはより一般的に、外部エンティティにとって論理装置として現れる様々なデバイスおよびアプリケーションを含むデータ処理システムも指すことができる。
【００３６】
「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、またはその他の関連情報など、特定の操作に関係する情報の転送に適切なデータ・フォーマットを含むものと理解しなければならない。保護リソースは、それに関するアクセスが制御または制限されるリソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、またはその他の計算リソース、通信タイプのリソースなど）である。
【００３７】
トークンは、正常動作の直接的証拠を提供し、操作を実行するエンティティによって生成され、たとえば、認証トークンは正常認証操作後に生成される。Ｋｅｒｂｅｒｏｓトークンは、本発明で使用可能な認証トークンの一例である。Ｋｅｒｂｅｒｏｓに関する詳細は、１９９３年９月発行のInternet Engineering Task Force (IETF) Request for Comments (RFC)1510に掲載されたＫｏｈｌ他による「The Kerberos Network Authentication Service (V5)」で見つけることができる。
【００３８】
アサーション(assertion)は、何らかのアクションの間接的証拠を提供する。アサーションは、ＩＤ、認証、属性、許可決定、その他の情報あるいは操作またはその両方の間接的証拠を提供することができる。認証アサーションは、認証サービスではないが、認証サービスを聴取したエンティティによる認証の間接的証拠を提供する。
【００３９】
セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ：Security Assertion Markup Language）アサーションは、本発明内で使用可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利グローバル・コンソーシアムであるＯｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって公布されたものである。ＳＡＭＬは、２００２年５月３１日発行のCommitteeSpecification 01に掲載された「Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML)」に記載されている。
【００４０】
セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）は、セキュリティ情報を交換するためのＸＭＬベースのフレームワークである。このセキュリティ情報はサブジェクトに関するアサーションの形で表され、サブジェクトは何らかのセキュリティ・ドメイン内のＩＤを有するエンティティ（人またはコンピュータのいずれか）である。サブジェクトの典型的な例は、特定のインターネットＤＮＳドメイン内の自分のＥメール・アドレスによって識別される人である。アサーションは、サブジェクトによって実行される認証行為、サブジェクトの属性、およびサブジェクトが特定のリソースにアクセスできるかどうかに関する許可決定に関する情報を搬送することができる。アサーションは、ＸＭＬ構成体として表され、ネストされた構造を有し、それにより、単一アサーションは認証、許可、および属性に関する数種類の内部ステートメントを含む可能性がある。認証ステートメントを含むアサーションは単に前に発生した認証の行為を記述するに過ぎないことに留意されたい。アサーションは、ＳＡＭＬ機関、すなわち、認証機関、属性機関、およびポリシー決定点（policy decision point）によって発行される。ＳＡＭＬは、それによりクライアントがＳＡＭＬ機関からアサーションを要求し、ＳＡＭＬ機関からの応答を取得できるプロトコルを定義する。このプロトコルは、ＸＭＬベースの要求および応答メッセージ・フォーマットからなり、多種多様な基礎となる通信およびトランスポート・プロトコルにバインドすることができ、現在、ＳＡＭＬはＨＴＴＰによるＳＯＡＰへのバインディングを定義する。ＳＡＭＬ機関は、その応答を作成する際に、外部ポリシー・ストアや、要求において入力として受信したアサーションなどの様々な情報ソースを使用することができる。したがって、クライアントは常にアサーションを消費するが、ＳＡＭＬ機関はアサーションの作成者と消費者のいずれにもなりうる。
【００４１】
ＳＡＭＬ規格では、アサーションは発行者によって作成された１つまたは複数のステートメントを提供する情報のパッケージであることを示している。ＳＡＭＬにより、発行者は、指定のサブジェクトが特定の時期に特定の手段によって認証されたという認証、指定のサブジェクトが指定のリソースにアクセスできるようにするための要求が認可または拒否されたという許可、および指定のサブジェクトが提供された属性に関連付けられる属性という３種類のアサーション・ステートメントを作成することができる。以下に詳述する通り、必要なときに、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することができる。
【００４２】
認証は、ユーザによってまたはユーザに代わって提供される１組の信用証明情報（credential）を妥当性検査するプロセスである。認証は、ユーザが把握しているもの、ユーザが持っているもの、またはユーザが何者であるか、すなわち、ユーザに関する何らかの物理的特性を検証することによって実施される。ユーザが把握しているものとしては、ユーザのパスワードなど、または特定のユーザにのみ把握されているものを検証することにより、ユーザの暗号鍵などの共有秘密鍵（sharedsecret）を含むことができる。ユーザが持っているものとしては、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特性としては、指紋または網膜マップなどのバイオメトリック入力を含むことができるであろう。
【００４３】
認証信用証明情報は、様々な認証プロトコルで使用される１組の質問／応答情報である。たとえば、ユーザ名とパスワードの組合せは、最も普通の形式の認証信用証明情報である。他の形式の認証信用証明情報としては、様々な形式の質問／応答情報、公開鍵インフラストラクチャ（ＰＫＩ：Public Key Infrastructure）証明書、スマートカード、バイオメトリクスなどを含むことができる。認証信用証明情報は認証アサーションとは差異化され、すなわち、認証信用証明情報は認証サーバまたはサービスとの認証プロトコル・シーケンスの一部としてユーザによって提示されるものであり、認証アサーションはユーザの認証信用証明情報の正常な提示および妥当性検査に関するステートメントであって、その後、必要なときにエンティティ間で転送されるものである。
【００４４】
従来技術のシングル・サインオン・ソリューションの区別
上記の通り、従来技術のシングル・サインオン・ソリューションは、参加企業間で事業協定が事前確立されている同種環境に制限されている。これらの事業協定は、信頼を確立し、企業間の安全な情報転送を定義する。また、これらの事業協定は、ある企業から他の企業にユーザＩＤを変換またはマッピングする方法ならびに参加企業間でユーザの保証人となるために使用される情報を転送する方法に関するルールに関する技術協定も含む。
【００４５】
換言すれば、以前のシングル・サインオン・ソリューションは、ある企業が事前交渉または事前構成された協定に基づいて異なる企業によって生成された認証アサーション（そのアサーションで提供されるユーザＩＤとともに）を信頼できるようにするものである。それぞれの別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、同様の協定を取り交わした他の企業によって理解されうる認証アサーションを作成し解釈する方法を把握している。これらのシステム間にはユーザＩＤをマッピングするために企業が把握している決定的関係が存在するので、これらの同種環境は緊密に結合される。シングル・サインオン環境を確立するために事業協定が使用されるので、この緊密結合は可能である。
【００４６】
本発明のフェデレーション・モデル
ワールド・ワイド・ウェブに関連して、ユーザは、特定の各ドメイン間の情報バリアを最小限に考慮して、あるインターネット・ドメイン上のアプリケーションとの対話から他のドメイン上の他のアプリケーションにジャンプする能力を期待するようになる。ユーザは、単一トランザクションの場合に複数のドメインに対する認証を受けなければならないことによって引き起こされる欲求不満を望まない。換言すれば、ユーザは複数組織が相互運用することを期待するが、ユーザは一般に複数ドメインがユーザのプライバシを尊重することを希望する。加えて、ユーザは、私有情報を永続的に保管するドメインを制限する方を好む可能性がある。このようなユーザの期待は、多くの企業および組織が競合する認証技法を公布している、急速進化中の異機種環境に存在する。
【００４７】
従来技術のシステムとは対照的に、本発明は、特定の企業間の特定の事前確立された事業および技術協定がない場合に企業がユーザに対してシングル・サインオン経験を提供できるようにするためのフェデレーション・モデルを提供する。換言すれば、本発明は、フェデレーテッド異機種環境をサポートする。本発明の目的の一例として、もう一度、図５を参照すると、ユーザ１９０は、ドメイン１９１に対する認証を受け、トランザクションに関係する可能性のある各ダウンストリーム・ドメインに対し適切なアサーションをドメイン１９１から提供してもらうことができる。これらのダウンストリーム・ドメインは、ドメイン１９１と他のダウンストリーム・ドメインとの間に事前確立されたアサーション・フォーマットがまったくない場合でも、認証アサーションあるいはその他のタイプのアサーションまたはその両方を理解し信頼できることが必要である。アサーションを認識することに加えて、ダウンストリーム・ドメインは、事前確立されたＩＤマッピング関係がまったくない場合でも、アサーション内に含まれるＩＤを、特定のドメイン内のユーザ１９０を表すＩＤに変換できることが必要である。
【００４８】
本発明は、フェデレーテッド環境を対象とする。一般に、企業は、独自のユーザ・レジストリを有し、独自のユーザ・セットとの関係を維持する。各企業は概して、これらのユーザを認証する独自の手段を有する。しかし、本発明のフェデレーテッド方式により、複数の企業は、ある企業が企業フェデレーションに参加することによりその企業のユーザが１組の企業との関係を強化できるように、集合的に協働することができる。ユーザは、各企業との直接的関係を有する場合と同様に、フェデレーテッド企業のうちのいずれかの企業側のリソースへのアクセスが許可される可能性がある。ユーザは、関心のある各事業に登録する必要はなく、自分自身を識別し認証することを絶えず要求されるわけではない。このため、このフェデレーテッド環境内では、認証方式により、情報技術において急速進化中の異機種環境内のシングル・サインオン経験が可能になる。
【００４９】
本発明では、フェデレーションは、シングル・サインオンの使いやすい経験をユーザに提供するために協働する、企業、組織、団体などの１組の別個のエンティティである。本発明では、フェデレーテッド環境は、２つの企業がユーザに関するどの情報をどのように転送するかを定義する直接的で事前確立された関係を有する必要がないという点で、典型的なシングル・サインオン環境とは異なる。フェデレーテッド環境内のエンティティは、ユーザを認証すること、他のエンティティによって提示される認証アサーション、たとえば、認証トークンを受諾すること、ならびに保証対象のユーザ（vouched-for user）のＩＤをローカル・エンティティ内で理解されるものに変換する何らかの形式の変換を提供することを扱うサービスを提供する。
【００５０】
フェデレーションは、サービス・プロバイダの管理負担を緩和する。サービス・プロバイダは、全体としてフェデレーションに関するその信頼関係を当てにすることができ、ユーザの認証ホーム・ドメインによって実施される認証を当てにすることができるので、ユーザ・パスワード情報などの認証情報を管理する必要がない。
【００５１】
また、本発明は、疎結合の認証サービス、ユーザ登録サービス、ユーザ・プロファイル管理サービス、あるいは許可サービスまたはこれらのサービスの組合せがセキュリティ・ドメインの全域でコラボレーションする基礎を確立するフェデレーテッドＩＤ管理システムにも関係する。フェデレーテッドＩＤ管理により、まったく異なる複数のセキュリティ・ドメインに常駐するサービスは、これらのまったく異なる複数ドメインにおいて基礎となるセキュリティ・メカニズムおよびオペレーティング・システム・プラットフォームに相違点が存在する可能性がある場合でも、安全に相互運用しコラボレーションすることができる。ユーザがフェデレーションへの参加を確立すると、シングル・サインオン経験が確立される。
【００５２】
ホーム・ドメイン、発行側パーティ（issuingparty）、および依存側パーティ（relying party）
以下により詳細に説明する通り、本発明は、ユーザにとって重大な利点をもたらすものである。本発明により、ユーザは、以下でユーザのホーム・ドメインまたは認証ホーム・ドメインとも呼ばれる第１のエンティティで認証を受けることができる。この第１のエンティティは、第２のエンティティで使用するためにユーザに関する認証アサーションを発行する発行側パーティとして動作することができる。次にユーザは、第２のエンティティで明示的に再認証を受ける必要なしに、第１のエンティティによって発行された認証アサーションを提示することにより、依存側パーティと呼ばれる第２の別個のエンティティで保護リソースにアクセスすることができる。発行側パーティから依存側パーティに渡される情報はアサーションの形になっており、このアサーションは、種々のタイプの情報をステートメントの形で含むことができる。たとえば、あるアサーションは、あるユーザの認証済みＩＤに関するステートメントである場合もあれば、特定のユーザに関連するユーザ属性情報に関するステートメントである場合もある。
【００５３】
次に図６を参照すると、ブロック図は、第１のフェデレーテッド企業に対してユーザによって開始され、それに応答して、フェデレーテッド環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関するフェデレーテッド環境の用語を描写している。図６は、所与のフェデレーテッド操作に関するフェデレーション内のエンティティの視点（perspective）に応じて用語が異なる可能性があることを示している。ユーザ２０２は、企業２０４の保護リソースに関する要求によりトランザクションを開始する。ユーザ２０２が企業２０４によってすでに認証されている場合、企業２０４は、このフェデレーテッド・セッション用のユーザのホーム・ドメインになる。このトランザクションが企業２０６による何らかのタイプの操作を必要とし、企業２０４が企業２０６にアサーションを転送すると想定すると、企業２０４はその特定の操作に関する発行側ドメインになり、企業２０６はその操作に関する依存側ドメインになる。このトランザクションが他の操作を必要とし、企業２０６が企業２０８にアサーションを転送すると想定すると、企業２０６は要求された操作に関する発行側ドメインになり、企業２０８はその操作に関する依存側ドメインになる。
【００５４】
本発明のフェデレーテッド環境では、ユーザが認証を受けるドメインは、ユーザの（認証）ホーム・ドメインと呼ばれる。ホーム・ドメインは認証信用証明情報を維持する。ホーム・ドメインは、ユーザの雇用主、ユーザのＩＳＰ、またはその他の何らかのサービス・プロバイダである可能性がある。ユーザの認証信用証明情報を生成し妥当性検査する能力を有する企業が複数存在する可能性があるので、ユーザのホーム・ドメインとして動作できる企業がフェデレーテッド環境内に複数存在する可能性があることは起こり得ることである。
【００５５】
認証の視点によると、認証アサーションに関する発行側パーティは通常、ユーザの認証ホーム・ドメインである。ユーザのホーム・ドメインは、そのユーザに関する個人情報またはプロファイル情報を維持する場合もあれば、維持しない場合もある。このため、個人的に識別可能な情報、パーソナライゼーション情報、またはその他のユーザ属性を伴う属性の視点によると、属性アサーションに関する発行側パーティは、そのユーザの認証ホーム・ドメインである場合もあれば、そうではない場合もある。混乱を回避するため、属性ホーム・ドメインおよび認証ホーム・ドメインについて別々の用語を使用することができるが、以下の「ホーム・ドメイン」という用語は、認証ホーム・ドメインを指すものと解釈することができる。
【００５６】
しかし、所与のフェデレーテッド・セッションの範囲内では、通常、ユーザのホーム・ドメインとして動作するドメインは１つだけである。ユーザがこのドメインに対して認証を受けると、そのフェデレーション内の他のすべてのドメインまたは企業は、そのセッションの期間中、依存側パーティとして扱われる。
【００５７】
既存の非フェデレーテッド・アーキテクチャに及ぼす影響を最小限にしながら、既存のシステムに追加可能なフェデレーテッド・インフラストラクチャを本発明が提供することを考慮すると、ユーザのホーム・ドメインにおける認証は、ホーム・ドメインもフェデレーテッド環境に参加可能であることによって変更されることはない。換言すれば、本発明により実現されるフェデレーテッド環境にホーム・ドメインを統合できる場合でも、ユーザは、ユーザのホーム・ドメインで認証操作を実行しながら、同じエンドユーザ経験を持たなければならない。しかし、所与の企業のユーザのすべてが必ずしもフェデレーテッド環境に参加するわけではないことに留意されたい。
【００５８】
その上、ユーザ登録、たとえば、ユーザ・アカウントの確立は、ホーム・ドメインもフェデレーテッド環境に参加可能であることによって変更されることはない。ユーザは、フェデレーテッド環境とは無関係の登録プロセスによりドメインでアカウントを確立する。換言すれば、ホーム・ドメインにおけるユーザ・アカウントの確立は、フェデレーションの全域で有効なアカウント情報、たとえば、ＩＤ変換情報の確立を含まない。ユーザを認証できる単一フェデレーテッド・ドメインが存在する場合、すなわち、ユーザが登録したフェデレーション内のドメインが１つだけである場合、このドメインは常にユーザのホーム・ドメインとして動作することになり、フェデレーテッド環境全体にわたってユーザの移動を指図することができる。
【００５９】
ユーザが１つのフェデレーテッド環境内で可能なホーム・ドメインを複数持っている場合、ユーザは２つ以上のエントリ・ポイントを介してそのフェデレーションに入ることができる。換言すれば、ユーザは複数のドメインでアカウントを持つことができ、これらのドメインは必ずしも他のドメインまたは他のドメインにおけるユーザのＩＤに関する情報を持っているわけではない。
【００６０】
ユーザが認証を受けるドメインはホーム・ドメインと呼ばれるが、発行側ドメインは、他のドメイン、すなわち、依存側ドメインによる使用のためにアサーションを発行するフェデレーション・エンティティである。発行側ドメインは、通常、ユーザのホーム・ドメインであるが、必ずそうであるわけではない。このため、通常、発行側パーティが、前述の通り、典型的な認証プロトコルによりすでにユーザを認証していることが実情になるであろう。しかし、発行側が前に依存側パーティとして動作しており、それにより、異なる発行側パーティからアサーションを受信したことは起こり得ることである。換言すれば、ユーザが開始したトランザクションはフェデレーテッド環境内の一連の企業によりカスケードすることができるので、受信側パーティは、その後、ダウンストリーム・トランザクションに関する発行側パーティとして動作することができる。一般に、ユーザに代わって認証アサーションを発行する能力を有するドメインは発行側ドメインとして動作することができる。
【００６１】
依存側ドメインは、発行側パーティからアサーションを受信するドメインである。依存側パーティは、ユーザに代わるサード・パーティ、すなわち、発行側ドメインによって発行されるアサーションを受諾し、信頼し、理解することができる。一般に、適切な認証機関を使用して認証アサーションを解釈することは依存側パーティの義務である。加えて、依存側パーティが特定のユーザを認証できる、すなわち、ユーザのホーム・ドメインとして動作できることは起こり得ることであるが、依存側パーティが従来の方法により特定のユーザを認証できない可能性があることも起こり得ることである。このため、依存側パーティは、ユーザによって提示される認証アサーションを当てにするドメインまたは企業であって、ユーザとの対話式セッションの一部としてユーザの認証信用証明情報の入力をユーザに促す代わりに、ユーザにシングル・サインオン経験を提供するドメインまたは企業である。
【００６２】
フェデレーテッド・アーキテクチャ――レガシー・システム用のフェデレーテッド・フロントエンド
次に図７を参照すると、ブロック図は、本発明の一実施形態により本発明のフェデレーテッド・アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を描写している。フェデレーテッド環境は、ユーザに様々なサービスを提供するフェデレーテッド・エンティティを含む。ユーザ２１２は、ブラウザ・アプリケーション２１６および他の様々なクライアント・アプリケーション２１８をサポートできるクライアント装置２１４と対話する。ユーザ２１２は、クライアント装置２１４、ブラウザ２１６、またはユーザとその他の装置およびサービスとのインターフェースとして動作する任意の他のソフトウェアとは別個のものである。場合によっては、以下の説明により、クライアント・アプリケーション内で明示的に動作するユーザと、ユーザに代わって動作するクライアント・アプリケーションとを区別することができる。しかし、一般に、リクエスタは、クライアントベースのアプリケーション、ブラウザ、ＳＯＡＰクライアントなど、ユーザに代わって動作するものと想定できる仲介者である。
【００６３】
ブラウザ・アプリケーション２１６は、ＨＴＴＰ通信コンポーネント２２０およびマークアップ言語（ＭＬ）インタープリタ２２２などの多くのモジュールを有する典型的なブラウザにすることができる。また、ブラウザ・アプリケーション２１６は、Ｗｅｂサービス・クライアント２２４あるいはダウンロード可能アプレットまたはその両方などのプラグインもサポートすることができ、そのアプレットは仮想計算機ランタイム環境を必要とする場合もあれば必要としない場合もある。Ｗｅｂサービス・クライアント２２４は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）を使用することができ、これは非集中分散環境における構造化および型付き情報の交換を定義するための軽量プロトコルである。ＳＯＡＰは、メッセージ内に何が含まれているかならびにそれをどのように処理するかを記述するためのフレームワークを定義するエンベロープと、アプリケーション定義のデータ型のインスタンスを表すための１組のエンコード・ルールと、リモート・プロシージャ・コールおよび応答を表すための規則という３つの部分からなるＸＭＬベースのプロトコルである。ユーザ２１２は、ブラウザ・アプリケーション２１６を使用してＷｅｂベース・サービスにアクセスすることができるが、ユーザ２１２は、クライアント装置２１４上の他のＷｅｂサービス・クライアントによりＷｅｂサービスにアクセスすることもできる。以下の図に示した本発明の例のいくつかは、フェデレーテッド環境内のエンティティ間で情報を交換するために、ユーザのブラウザによるＨＴＴＰリダイレクトを使用する。しかし、本発明は、様々な通信プロトコルにより実施することができ、ＨＴＴＰベースの通信に制限されるものではないことに留意されたい。たとえば、フェデレーテッド環境内のエンティティは、必要なときに直接通信することができ、ユーザのブラウザによりメッセージをリダイレクトする必要はない。
【００６４】
本発明は、フェデレーテッド環境に必要なコンポーネントを既存のシステムと統合できるように実現することができる。図７は、既存のシステムへのフロントエンドとしてこれらのコンポーネントを実現するための一実施形態を描写している。フェデレーテッド・ドメインにある既存のコンポーネントは、図８に示したものと同様に認証サービス・ランタイム（ＡＳＲ：authentication service runtime）サーバ２３２を含む、レガシー・アプリケーションまたはバックエンド処理コンポーネント２３０と見なすことができる。ＡＳＲサーバ２３２は、そのドメインがアプリケーション・サーバ２３４へのアクセスを制御するときにユーザの認証を担当し、そのアプリケーション・サーバ２３４は保護リソースを生成するか、検索するか、またはその他の方法で処理するものと見なすことができる。このドメインは引き続きレガシー・ユーザ登録アプリケーション２３６を使用して、アプリケーション・サーバ２３４へのアクセスについてユーザを登録することができる。登録済みユーザを認証するために必要な情報は、レガシー・ユーザ・レジストリ２３８に保管される。
【００６５】
フェデレーテッド環境に加入後、そのドメインは、フェデレーテッド・コンポーネントの介入なしに機能し続けることができる。換言すれば、そのドメインは、ポイントオブコンタクト・サーバまたはこのポイントオブコンタクト・サーバ機能を実現するその他のコンポーネントを通過せずに、ユーザが特定のアプリケーション・サーバまたは他の保護リソースに直接アクセスし続けることができるように構成することができ、このようにシステムにアクセスするユーザは、典型的な認証フローおよび典型的なアクセスを経験することになるであろう。しかし、このようにする際に、レガシー・システムに直接アクセスするユーザは、そのドメインのポイントオブコンタクト・サーバに知られているフェデレーテッド・セッションを確立できないであろう。
【００６６】
そのドメインのレガシー機能は、フェデレーテッド・フロントエンド処理２４０の使用によりフェデレーテッド環境に統合することができ、そのフェデレーテッド・フロントエンド処理２４０はポイントオブコンタクト・サーバ２４２とトラスト・プロキシ・サーバ２４４（またはより単純にトラスト・プロキシ２４４）とを含み、そのトラスト・プロキシ・サーバ２４４自体はセキュリティ・トークン・サービス（ＳＴＳ：Security Token Service）２４５を含み、これらのすべてについては図８に関し以下により詳細に説明する。フェデレーション構成アプリケーション２４６により、管理ユーザは、フェデレーテッド・フロントエンド・コンポーネントがフェデレーテッド・インターフェース・ユニット２４８によりレガシー・バックエンド・コンポーネントとのインターフェースを取れるようにそのフェデレーテッド・フロントエンド・コンポーネントを構成することができる。
【００６７】
所与の企業におけるレガシーまたは既存の認証サービスは、ユーザ名／パスワードまたはスマートカード・トークンベースの情報など、様々な周知の認証方法またはトークンを使用することができる。しかし、本発明では、ポイントオブコンタクト・サーバの使用により、レガシー認証サービスの機能をフェデレーテッド環境で使用することができる。ユーザは、ポイントオブコンタクト・サーバを通過せずにレガシー認証サーバに直接アクセスし続けることができるが、このようにシステムにアクセスするユーザは典型的な認証フローおよび典型的なアクセスを経験することになり、レガシー認証システムに直接アクセスするユーザは、本発明によりＩＤの証明としてフェデレーテッド認証アサーションを生成できないであろう。フェデレーテッド・フロントエンドの役割の１つは、ポイントオブコンタクト・サーバで受信したフェデレーテッド認証トークンを、レガシー認証システムによって理解されるフォーマットに変換することである。このため、ポイントオブコンタクト・サーバを介してフェデレーテッド環境にアクセスするユーザは必ずしも、レガシー認証サービスに対する再認証を受ける必要はなくなるであろう。好ましくは、ユーザは、ユーザが認証ダイアログに従事している場合と同様にそれが現れるように、ポイントオブコンタクト・サーバとトラスト・プロキシとの組合せによって、レガシー認証サービスに対して認証されることになるであろう。
【００６８】
フェデレーテッド・アーキテクチャ――ポイントオブコンタクト・サーバ、トラスト・プロキシ、およびトラスト・ブローカ
次に図８を参照すると、ブロック図は、本発明の一実現例によるフェデレーテッド・アーキテクチャを描写している。フェデレーテッド環境は、ユーザに様々なサービスを提供するフェデレーテッド企業または同様のエンティティを含む。ユーザは、クライアント装置上のアプリケーションにより、企業２５０などの様々なエンティティにあるリソースにアクセスしようと試みることができる。企業２５０のポイントオブコンタクト（ＰＯＣ）サーバ２５２など、各フェデレーテッド企業のポイントオブコンタクト・サーバは、そのユーザのフェデレーテッド環境へのエントリ・ポイントである。ポイントオブコンタクト・サーバはフェデレーション要件の多くを処理するので、ポイントオブコンタクト・サーバは既存の非フェデレーテッド・アーキテクチャ内の既存のコンポーネント、たとえば、レガシー・システムへの影響を最小限にする。ポイントオブコンタクト・サーバは、セッション管理、プロトコル変換を可能にし、おそらく、認証アサーション変換を開始する。たとえば、ポイントオブコンタクト・サーバは、ＨＴＴＰまたはＨＴＴＰＳメッセージをＳＯＡＰに変換することができ、またその逆も変換することができる。以下により詳細に説明するように、ポイントオブコンタクト・サーバは、トラスト・プロキシを呼び出して認証アサーションを変換するために使用することもでき、たとえば、発行側パーティから受信したＳＡＭＬトークンは受信側パーティによって理解されるＫｅｒｂｅｒｏｓトークンに変換することができる。
【００６９】
企業２５０のトラスト・プロキシ（ＴＰ）２５４などのトラスト・プロキシまたはトラスト・プロキシ・サーバは、フェデレーション内の２つのエンティティ間の信頼関係を確立し維持する。トラスト・プロキシは一般に、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換（以下に詳述するセキュリティ・トークン・サービスによる）を処理する能力を有する。
【００７０】
全体的に、ポイントオブコンタクト・サーバとトラスト・プロキシの使用は、フェデレーテッド・アーキテクチャの実現が既存の非フェデレーテッド・システム・セットに及ぼす影響を最小限にする。このため、本発明のフェデレーテッド・アーキテクチャは、そのエンティティが企業であるか、ドメインであるか、その他の論理エンティティまたは物理エンティティであるかにかかわらず、フェデレーテッド・エンティティ当たり少なくとも１つのポイントオブコンタクト・サーバと少なくとも１つのトラスト・プロキシの実現を必要とする。しかし、本発明のフェデレーテッド・アーキテクチャは必ずしも、既存の非フェデレーテッド・システム・セットに対する変更を必要としない。好ましくは、所与のフェデレーテッド・エンティティについて単一のトラスト・プロキシが存在するが、可用性のために複数のトラスト・プロキシが存在する可能性もあり、あるいはフェデレーテッド・エンティティ内のより小さい様々なエンティティ、たとえば、企業内の個別の子会社のために、複数のトラスト・プロキシが存在する可能性もある。単一トラスト・プロキシは複数のフェデレーション内の信頼関係を管理することができるので、このシナリオは必ずしも複数のトラスト・プロキシを必要としないであろうが、所与のエンティティが２つ以上のフェデレーションに属すことができることは起こり得ることである。
【００７１】
トラスト・プロキシの役割の１つは、他のドメインあるいはそのドメイン内のトラスト・プロキシまたはその両方によって必要なトークン・タイプを決定することである。トラスト・プロキシは、発行側パーティによって使用されるフォーマットから受信側パーティによって理解されるフォーマットへの認証トークン・フォーマット変換を処理する能力を有する。また、トラスト・プロキシ２５４は、企業２５０に関して行われる任意のユーザＩＤ変換または属性変換も担当する。しかし、トラスト・プロキシは、以下に詳述する通り、支援のためにトラスト・ブローカを呼び出すことができる。ＩＤ変換は、発行側パーティに知られているユーザＩＤおよび属性を受信側パーティにとって意味のあるものにマッピングする必要がある場合がある。この変換は、発行側ドメインのトラスト・プロキシまたは受信側ドメインのトラスト・プロキシのいずれかによって呼び出すことができる。
【００７２】
トラスト・プロキシ２５４は、セキュリティ・トークン・サービス（ＳＴＳ）コンポーネント２５５として示される内部化コンポーネント（internalized component）を含むことができ、そのコンポーネントはトークン変換を可能にし、認証サービス・ランタイム（ＡＳＲ）２５６を呼び出してトークンを妥当性検査し生成することになる。セキュリティ・トークン・サービスは、トラスト・プロキシが必要とするトークン発行および妥当性検査サービスを提供する。したがって、セキュリティ・トークン・サービスは、既存の認証サービス・ランタイムへのインターフェースを含むか、またはそのサージス自体に認証サービス・ランタイムを組み込む。トラスト・プロキシ内に内部化されるのではなく、セキュリティ・トークン・サービス・コンポーネントは、たとえば、トラスト・プロキシによって呼び出されるスタンドアロン・コンポーネントとして実現することもでき、あるいは、たとえば、アプリケーション・サーバの一部として、トランザクション・サーバ内に内部化することもできる。
【００７３】
たとえば、ＳＴＳコンポーネントは、Ｋｅｒｂｅｒｏｓトークンを発行するための要求を受信することができる。そこからトークンが作成されるユーザの認証情報の一部として、要求は、ユーザ名とパスワードを含むバイナリ・トークンを含むことができる。ＳＴＳコンポーネントは、たとえば、ＬＤＡＰランタイム（典型的な認証）に照らし合わせてユーザ名およびパスワードを妥当性検査することになり、Ｋｅｒｂｅｒｏｓ ＫＤＣ（鍵配布センタ：Key Distribution Center）を呼び出して、このユーザに関するＫｅｒｂｅｒｏｓチケットを生成することになる。このトークンは、企業内で使用するためにトラスト・プロキシに返されるが、この使用は、フェデレーション内の他のドメインに転送するためにトークンを外部化することを含む可能性がある。
【００７４】
図４に関して説明したものと同様に、ユーザは、企業２５０および企業２６０の両方など、フェデレーテッド環境内の複数企業のリソースにアクセスすることを所望する可能性がある。企業２５０に関して上述したものと同様に、企業２６０は、ポイントオブコンタクト・サーバ２６２と、トラスト・プロキシ２６４と、セキュリティ・トークン・サービス２６５と、認証サービス・ランタイム２６６とを有する。ユーザは各企業との個別のトランザクションを直接開始することができるが、ユーザは、フェデレーテッド環境全体にわたってカスケードする企業２５０とのトランザクションを開始することができる。ユーザがトランザクションを開始したときにユーザがその必要性を認識していなかった可能性がある場合でも、企業２５０は、特定のトランザクションを完了するために、企業２６０などのフェデレーテッド環境内の他の複数の企業とのコラボレーションを必要とする場合がある。企業２６０はダウンストリーム・ドメインとして関係することになり、本発明により、企業２５０は、ユーザのトランザクションを促進するために必要であれば、フェデレーテッド・アサーションを企業２６０に提示することができる。
【００７５】
関連ポイントオブコンタクト・サーバによって受信された認証トークンを解釈する方法あるいは所与のユーザＩＤおよび属性を変換する方法またはその両方をトラスト・プロキシが把握していないということが実情である場合もある。この場合、トラスト・プロキシは、トラスト・ブローカ２６８などのトラスト・ブローカ・コンポーネントで機能を呼び出すことを選択することができる。トラスト・ブローカは、個々のトラスト・プロキシとの関係を維持し、それにより、トラスト・プロキシ間の推移的な信頼関係を提供する。トラスト・ブローカを使用すると、企業２５０および２６０などのフェデレーテッド環境内の各エンティティは、フェデレーテッド環境内の各ドメインとの複数の個別信頼関係を確立するのではなく、トラスト・ブローカとの信頼関係を確立することができる。たとえば、企業２６０が企業２５０のユーザによって開始されたトランザクションについてダウンストリーム・ドメインとして関係することになったときに、企業２５０のトラスト・プロキシ２５４は、必要な場合にトラスト・ブローカ２６８で支援を呼び出すことにより、企業２６０のトラスト・プロキシ２６４がトラスト・プロキシ２５４からのアサーションを理解できることを確信することができる。図８は、単一トラスト・ブローカを備えたフェデレーテッド環境を描写しているが、フェデレーテッド環境は複数のトラスト・ブローカを有することができる。
【００７６】
図８はポイントオブコンタクト・サーバ２５２、トラスト・プロキシ２５４、セキュリティ・トークン・サービス・コンポーネント２５５、および認証サービス・ランタイム２５６を別個のエンティティとして描写しているが、これらのコンポーネントを個別のデバイスとして実現する必要はないことに留意されたい。たとえば、これらの個別のコンポーネントの機能を、単一物理装置上のアプリケーションとして実現するかまたは単一アプリケーションに結合することは可能である。加えて、図８は、１つの企業のための単一ポイントオブコンタクト・サーバ、単一トラスト・プロキシ、および単一セキュリティ・トークン・サーバを描写しているが、代替構成は、各企業用の複数のポイントオブコンタクト・サーバ、複数のトラスト・プロキシ、および複数のセキュリティ・トークン・サーバを含むことができる。ポイントオブコンタクト・サーバ、トラスト・プロキシ、セキュリティ・トークン・サービス、およびその他のフェデレーテッド・エンティティは、ソフトウェア・アプリケーション、オブジェクト、モジュール、ソフトウェア・ライブラリなどの様々な形で実現することができる。
【００７７】
トラスト・プロキシ／ＳＴＳは、ユーザ名とパスワードの組合せおよびＫｅｒｂｅｒｏｓチケットなどの伝統的な信用証明情報を含む多種多様な認証信用証明情報ならびにサード・パーティによって生成される認証トークンを含むフェデレーテッド認証トークン・フォーマットを受諾し妥当性検査することができる。トラスト・プロキシ／ＳＴＳは、他の場所で認証の証明として認証トークンの受諾を可能にすることができる。認証トークンは、発行側パーティによって生成され、ユーザがその発行側パーティに対してすでに認証を受けていることを示すために使用される。発行側パーティは、ユーザの認証済みＩＤをアサートする手段として、認証トークンを生成する。
【００７８】
セキュリティ・トークン・サービスは、必要に応じて、認証サービス・ランタイムを呼び出す。認証サービス・ランタイムは、ユーザを認証できる認証サービスをサポートする。認証サービスは、認証応答を介して認証試行の成功または失敗の表示を提供する認証機関として動作する。トラスト・プロキシ／ＳＴＳは、認証サービス、たとえば、既存のレガシー・インフラストラクチャと対話する必要がないＷｅｂサービスの真新しいインストールが存在するというシナリオを内部化することができる。そうではない場合、ＳＴＳコンポーネントは、認証トークンの妥当性検査のために外部認証サービスを呼び出すことになる。たとえば、ＳＴＳコンポーネントは、ユーザ名／パスワードを含むバイナリ・トークンを「アンパック」し、次にＬＤＡＰサービスを使用してユーザ・レジストリにアクセスし、提示された信用証明情報を妥当性検査することができるであろう。
【００７９】
アプリケーション・サーバなどの他のコンポーネントによって使用される場合、ＳＴＳコンポーネントは、レガシー認証システムへのシングル・サインオンに必要なトークンを生成するために使用することができる。このため、ＳＴＳコンポーネントは、内部目的のために、すなわち、１つの企業内で、ならびに外部目的のために、すなわち、１つのフェデレーション内の複数企業の全域で、トークン変換に使用することができる。内部目的の一例として、Ｗｅｂアプリケーション・サーバは、ＩＢＭ ＣＩＣＳ（顧客情報管理システム：Customer Information Control System）トランザクション・ゲートウェイを介してメインフレームとのインターフェースを取ることができ、ＣＩＣＳは、企業レベルのオンライン・トランザクション管理および接続性を主幹業務アプリケーションに提供するアプリケーション・サーバおよびコネクタのファミリである。Ｗｅｂアプリケーション・サーバは、Ｋｅｒｂｅｒｏｓチケット（Ｗｅｂアプリケーション・サーバによって内部で使用されるもの）を、ＣＩＣＳトランザクション・ゲートウェイが要求するＩＢＭ ＲＡＣＦ（商標）パスチケットに変換するために、ＳＴＳコンポーネントを呼び出すことができる。
【００８０】
図８に示したエンティティは、上記で紹介した用語、たとえば、「発行側パーティ」および「依存側パーティ」を使用して説明することができる。信頼関係を確立し維持することの一部として、発行側パーティのトラスト・プロキシは、依存側パーティのトラスト・プロキシによってどのトークン・タイプが要求／受諾されるかを決定することができる。したがって、トラスト・プロキシは、セキュリティ・トークン・サービスからトークン・サービスを呼び出すときに、この情報を使用する。発行側ドメインのトラスト・プロキシが依存側パーティに関する認証アサーションを生成することを要求された場合、そのトラスト・プロキシは、必要なトークン・タイプを決定し、セキュリティ・トークン・サービスから適切なトークンを要求する。
【００８１】
依存側ドメインのトラスト・プロキシが発行側パーティから認証アサーションを受信すると、そのトラスト・プロキシは、どのタイプのアサーションをそれが予想していたか、ならびに依存側ドメイン内の内部使用のためにどのタイプのアサーションを必要としているかを把握する。したがって、依存側ドメインのトラスト・プロキシは、受信した認証アサーション内のトークンに基づいて、セキュリティ・トークン・サービスが必要な内部使用トークンを生成することを要求する。
【００８２】
トラスト・プロキシとトラスト・ブローカはどちらも、発行側パーティから受信したアサーションを、依存側パーティによって理解されるフォーマットに変換する能力を有する。トラスト・ブローカは、それとの直接的信頼関係が存在するトラスト・プロキシのそれぞれに関するアサーション・フォーマット（複数も可）を解釈する能力を有し、それにより、トラスト・ブローカが発行側パーティと依存側パーティとの間のアサーション変換を行えるようにする。この変換は、そのローカル・トラスト・プロキシによりいずれかのパーティによって要求することができる。したがって、発行側パーティのトラスト・プロキシは、それが依存側パーティに送信される前にアサーションの変換を要求することができる。同様に、依存側パーティのトラスト・プロキシは、発行側パーティから受信されたアサーションの変換を要求することができる。
【００８３】
アサーション変換は、ユーザＩＤ変換、認証アサーション変換、属性アサーション変換、またはその他の形式のアサーション変換を含む。上記のポイントを繰り返すと、アサーション変換は、フェデレーション内のトラスト・コンポーネント、すなわち、トラスト・プロキシとトラスト・ブローカによって処理される。トラスト・プロキシは、発行側ドメインまたは依存側ドメインのいずれかで、この変換をローカルで実行する場合もあれば、トラスト・ブローカから支援を呼び出す場合もある。
【００８４】
発行側パーティと依存側パーティがすでにトラスト・ブローカとの個別信頼関係を有すると想定すると、トラスト・ブローカは、必要であれば発行側パーティと依存側パーティとの間の新しい信頼関係を動的に作成する、すなわち、ブローカリングすることができる。トラスト・ブローカによって提供される初期信頼関係ブローカリング操作の後、発行側パーティと依存側パーティは、将来の変換要件のためにトラスト・ブローカを呼び出す必要がないように、その関係を直接維持することができる。認証トークンの変換は、発行側パーティのトラスト・プロキシ、依存側パーティのトラスト・プロキシ、およびトラスト・ブローカという考えられる３つの箇所で起こる可能性があることに留意されたい。好ましくは、発行側パーティのトラスト・プロキシは、依存側パーティに送信するためにトラスト・ブローカによって理解される認証アサーションを生成する。次に依存側パーティは、トラスト・ブローカからのこのトークンを依存側パーティによって認識可能なフォーマットに変換することを要求する。トークン変換は、認証アサーションの伝送前に、伝送後に、または伝送前と伝送後の両方で行うことができる。
【００８５】
フェデレーテッド・アーキテクチャ内の信頼関係
本発明により実現されるフェデレーテッド環境内には、企業トラスト・ドメインとフェデレーション・トラスト・ドメインという、管理しなければならない２つのタイプの「トラスト・ドメイン」が存在する。この２つのタイプのトラスト・ドメイン間の相違点は、部分的に、トラスト・ドメインとの信頼関係を支配する事業協定と、信頼を確立するために使用される技術とに基づいている。企業トラスト・ドメインは、その企業によって管理されるコンポーネントを含み、そのトラスト・ドメイン内のすべてのコンポーネントは互いに信頼する。一般に、たとえば、コンポーネント間で相互に認証されたＳＳＬセッションを要求することにより、配置された技術が１つの企業内で固有の信頼関係を作り出すので、１つの企業内で信頼を確立するために必要な事業協定はまったく存在しない。図７を参照すると、レガシー・アプリケーションおよびバックエンド処理システムは企業トラスト・ドメインを表すことができる。
【００８６】
フェデレーション・トラスト・ドメインは企業境界を越えるものであり、ある視点によると、フェデレーション・トラスト・ドメインは、別個の企業トラスト・ドメイン間の信頼関係を表すことができる。フェデレーション・トラスト・ドメインは、企業境界の全域でトラスト・プロキシにより確立される。フェデレーテッド信頼関係は、それによりトラスト・プロキシ間に初期信頼が確立される、ある種のブートストラッピング・プロセスを必要とする。このブートストラップ・プロセスの一部は、予想あるいは許可またはその両方のトークン・タイプとＩＤ変換を定義するルールならびに共有秘密鍵の確立を含むことができる。一般に、このブートストラッピング・プロセスは、ある企業のフェデレーションへの参加を支配する事業協定の確立と、この参加に関連する責任も含むので、このプロセスはアウト・オブ・バンドで実現される。
【００８７】
フェデレーテッド・ビジネス・モデルには信頼を確立するためのメカニズムがいくつか存在する。フェデレーション・モデルでは、参加者間で転送されるアサーション（トークンおよび属性情報を含む）が有効であるという、あるレベルの保証を提供するために、ビジネス上の理由でフェデレーション参加者間の信頼の基本概念が必要である。信頼関係がまったくない場合、依存側ドメインは発行側ドメインから受信したアサーションに依存することができず、発行側パーティから受信した任意の情報を解釈する方法を決定するために依存側ドメインがそれを使用することができない。
【００８８】
たとえば、大企業は、数千のグローバル・カスタマ（globalcustomer）をリンクしたいと希望する可能性があり、その企業は従来技術のソリューションを使用できるであろう。第１の例として、その企業は、相互信頼を確立するために商用証明局からのデジタル証明書を使用することをグローバル・カスタマに要求できるであろう。商用証明局は、その企業のサーバがそれぞれのグローバル・カスタマに位置するサーバを信頼できるようにする。第２の例として、その企業はＫｅｒｂｅｒｏｓを使用してサード・パーティの信頼を実現でき、その企業とそのグローバル・カスタマは共有秘密鍵ベースの信頼を実現するトラステッド・サード・パーティＫｅｒｂｅｒｏｓドメイン・サービスを実現できるであろう。第３の例として、その企業は、そのグローバル・カスタマのサーバによって相互に信頼される独自のセキュリティ・メッセージ・トークンにより専用方式を確立できるであろう。
【００８９】
その企業が少数のグローバル・カスタマとの信頼関係を管理する必要がある場合、上記の手法のいずれか１つが受入れ可能である可能性があるが、数百または数千の潜在的なフェデレーション・パートナが存在する場合には、これは管理不能になる可能性がある。たとえば、企業がより小規模なパートナに専用方式の実現を強制することは可能である場合もあるが、企業がより大規模なパートナに多くの要件を賦課できるようになることはありそうもないことである。
【００９０】
本発明では、企業は、トラスト・プロキシと、おそらくトラスト・ブローカにより確立され維持された信頼関係を使用することになる。本発明のフェデレーテッド・アーキテクチャの利点の１つは、ある企業およびその潜在的なフェデレーション・パートナの現行インフラストラクチャ以上の追加要件を賦課しないことである。
【００９１】
しかし、本発明は、フェデレーションへの参加に必要な事業および責任協定を確立するために必要な予備作業から企業およびその潜在的なフェデレーション・パートナを救済するものではない。加えて、参加者は信頼関係の技術的ブートストラッピングを無視することができない。本発明はこのブートストラッピングを柔軟なものにすることができ、たとえば、第１のフェデレーション・パートナは特定の情報でＫｅｒｂｅｒｏｓチケットを発行することができ、第２のフェデレーション・パートナは特定の情報でＳＡＭＬ認証アサーションを発行することができる。
【００９２】
本発明では、２つのトラスト・プロキシ間で事前確立された関係に基づいて発行側パーティから受信されるトークンを妥当性検査し変換するセキュリティ・トークン・サービスを含むことができるフェデレーション・トラスト・プロキシにより信頼関係が管理される。フェデレーテッド企業が他のフェデレーテッド企業との信頼関係（およびトークン変換）を確立することが実現可能ではない状況では、トラスト・ブローカを呼び出すことができる。しかし、フェデレーテッド企業は依然として、トラスト・ブローカとの関係を確立しなければならない。
【００９３】
次に図９を参照すると、ブロック図は、本発明によりトラスト・プロキシとトラスト・ブローカとを使用するフェデレーテッド・ドメイン間の例示的な１組の信頼関係を描写している。図８はトラスト・ブローカを紹介したが、図９は本発明のフェデレーテッド・アーキテクチャ内の推移的な信頼関係の重要性を示している。
【００９４】
フェデレーテッド・ドメイン２７１〜２７３はトラスト・プロキシ２７４〜２７６をそれぞれ組み込んでいる。トラスト・プロキシ２７４はトラスト・プロキシ２７５との直接的信頼関係２７７を有する。トラスト・ブローカ２８０はトラスト・プロキシ２７５との直接的信頼関係２７８を有し、トラスト・ブローカ２８０はトラスト・プロキシ２７９との直接的信頼関係２７９を有する。トラスト・ブローカ２８０は、フェデレーション参加者に代わって、他のフェデレーション・パートナとの推移的な信頼関係に基づいて信頼関係を確立するために使用される。推移的な信頼関係の原理により、トラスト・プロキシ２７５およびトラスト・プロキシ２７６はトラスト・ブローカ２８０を介して信頼関係２８１をブローカリングしてもらうことができる。トラスト・プロキシ２７５または２７６はいずれも、もう一方のアサーションを変換または妥当性検査する方法を把握している必要はなく、有効であり、信頼され、もう一方のトラスト・プロキシで理解されるものにアサーションを変換するために、トラスト・ブローカを呼び出すことができる。
【００９５】
フェデレーテッド企業間の信頼関係に関する契約上の義務および責任を指定する事業協定は、ｅｂＸＭＬ（ＸＭＬを使用する電子ビジネス）規格の使用によりＸＭＬで表すことができる。たとえば、直接的信頼関係はｅｂＸＭＬドキュメントで表すことができ、直接的信頼関係を共用する各フェデレーテッド・ドメインはｅｂＸＭＬドキュメントとして表された契約書のコピーを有することになるであろう。フェデレーション内の様々なエンティティに関する動作特性は、ｅｂＸＭＬ振り付け（choreography）内に指定し、ｅｂＸＭＬレジストリ内で公開することができ、たとえば、トラスト・プロキシまたはトラスト・ブローカを操作するために、特定のフェデレーションに参加することを希望する任意の企業は、そのフェデレーション内のすべてのトラスト・プロキシまたはトラスト・ブローカについてその特定のフェデレーションによって指定された公開要件に適合する必要があるであろう。セキュリティ・トークン・サービスは、他のドメインからのトークンを変換する方法に関する操作上の詳細について、これらのｅｂＸＭＬドキュメントを構文解析できるであろう。しかし、フェデレーション内の信頼関係が実現される方法に関する詳細を指定するために、本発明により他の規格およびメカニズムを使用できることに留意されたい。
【００９６】
フェデレーテッド・アーキテクチャ内のアサーション処理
上記の通り、フェデレーション内のユーザの経験は、部分的に、複数ドメインの全域で転送される、ユーザに関するかまたはそのユーザのためのアサーションによって支配される。アサーションは、ユーザの認証状況に関する情報、属性情報、およびその他の情報を提供する。認証アサーションを使用すると、ユーザが、アクセスしたサイトごとに再認証を受ける必要性を除去することができる。フェデレーテッド環境内には、発行側パーティから依存側パーティへのアサーションを取得するために、プッシュ・モデル（push model）とプル・モデル（pull model）という２つのモデルが存在する。プッシュ・モデルでは、ユーザのアサーションはユーザの要求とともに発行側パーティに移動する。プル・モデルでは、ユーザの要求はいかなる情報もなしで依存側パーティで受信され、次に依存側パーティは発行側パーティから関連アサーションまたは必要なアサーションを要求する。
【００９７】
フェデレーテッド環境内でアサーションを使用するためのこれらのモデルを考慮して、次に本発明の説明では、本発明のフェデレーテッド環境内でアサーションを作成し使用するための１組のプロセスを記述する１組の図面を参照する。図１０は、フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写しており、図１１は、アサーションを「取り壊す」ため、すなわち、その情報を抽出し分析することにより、アサーションをその本質的情報まで削減するための依存側ドメインにおける汎用プロセスを描写している。図１２および図１３は、アサーションが発行側ドメイン内で生成され、次にユーザの要求とともに依存側ドメインに転送される、プッシュ・モデルの２つの変形を描写することにより、図１０に示した汎用プロセスに関するより詳細なプロセスを示している。図１４は、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。
【００９８】
次に図１０を参照すると、フローチャートは、フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを描写している。このプロセスは、発行側ドメインのポイントオブコンタクト・サーバがアサーションのためにトリガされたときに始まる（ステップ３０２）。ポイントオブコンタクト・サーバは、依存側ドメインから所与のユーザ用の特定のアサーションに関する要求を受信する場合もあれば、アサーションを必要とする既知の依存側ドメインに対する発信要求をインターセプトする場合もあり、これらのシナリオについてはそれぞれ図１２および１３に関して以下により詳細に説明する。アサーションのためにトリガされたことに応答して、発行側ドメインのポイントオブコンタクト・サーバは発行側ドメインのトラスト・プロキシからアサーションを要求し（ステップ３０４）、発行側ドメインのトラスト・プロキシがアサーションを生成し（ステップ３０６）、発行側ドメインのトラスト・プロキシは、必要であれば、必要なアサーションを生成するためにトラスト・ブローカから支援を要求することができる。アサーションを生成した後、発行側ドメインのトラスト・プロキシは発行側ドメインのポイントオブコンタクト・サーバにアサーションを返し（ステップ３０８）、次に発行側ドメインのポイントオブコンタクト・サーバが適切な方法で、たとえば、発信ＨＴＴＰまたはＳＯＡＰメッセージにアサーションを挿入することにより、出力データストリームにアサーションを注入し（ステップ３１０）、それにより、プロセスを完了する。
【００９９】
図１０は、「ローカル・ウォレット」の使用なしに発行側ドメインでアサーションを作成するためのプロセスを描写している。しかし、本発明はローカル・ウォレット機能の組込みを可能にするものである。一般に、ローカル・ウォレットは、トランザクションを容易にするためにユーザ属性情報またはその他の情報に関するセキュア・データ・ストアとして動作可能なクライアント側のコードであり、このクライアント側のコードはアサーション転送のプッシュ・モデルあるいはプル・モデルまたはその両方に参加することもできる。ローカル・ウォレットが積極的にプロトコルに参加すると、それは、アサーションを生成し、それをプロトコル・フローに挿入するという点でポイントオブコンタクト・サーバ機能の機能サブセットを実現する。ローカル・ウォレットを使用することにより、ローカル・ウォレットが、ポイントオブコンタクト・サーバとトラスト・プロキシとの間で行われるトラストベースの対話を実現できるわけではない。追加の信頼関係が必要な場合、ポイントオブコンタクト・サーバを呼び出さなければならない。
【０１００】
次に図１１を参照すると、フローチャートは、アサーションを取り壊すための依存側ドメインにおける汎用プロセスを描写している。このプロセスは、依存側ドメインのポイントオブコンタクト・サーバが関連アサーションとともにメッセージを受信したときに始まり（ステップ３２２）、その後、依存側ドメインのポイントオブコンタクト・サーバはアサーションを抽出し、依存側ドメインのトラスト・プロキシにアサーションを転送する（ステップ３２４）。依存側ドメインのトラスト・プロキシは、発行側ドメインから受信したトークンを含む情報をアサーションから抽出し（ステップ３２６）、依存側ドメインのトラスト・プロキシは、セキュリティ・トークン・サービスを呼び出してこのトークンを妥当性検査することになり、適切であれば、そのユーザに関してローカルで有効なトークンを返す（ステップ３２８）。
【０１０１】
ステップ３２６の一部として、トラスト・プロキシは、アサーションのソース、すなわち、発行側パーティを決定することになる。トラスト・プロキシがこの発行側ドメインから受信したトラスト・アサーションを理解できる場合、トラスト・プロキシはステップ３２８を内部で実行することになる。トラスト・プロキシが発行側ドメインから受信したアサーションを理解／信頼できない場合、トラスト・プロキシはトラスト・ブローカからの支援を呼び出すことができる。アサーションを妥当性検査できない場合、適切なエラー応答を生成することになるであろう。
【０１０２】
アサーションが妥当性検査されたと想定すると、依存側ドメインのトラスト・プロキシは、そのユーザについて必要なローカル情報を構築する（ステップ３３０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって必要とされる認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインのポイントオブコンタクト・サーバに返し（ステップ３３２）、そのポイントオブコンタクト・サーバがそのユーザのためのローカル・セッションを構築する。
【０１０３】
ポイントオブコンタクト・サーバがそのユーザのためのセッションを構築した後、そのユーザは認証ユーザとして現れる。ポイントオブコンタクト・サーバは、ログアウトまたはタイムアウト・イベントが開始されるまでユーザがそのドメインとの間で行っている任意のトランザクションをさらに支配するために、このセッション情報を使用することができる。ポイントオブコンタクト・サーバがそのユーザに関する認証済みＩＤを有していることを考慮すると、ポイントオブコンタクト・サーバは、この特定のユーザのＩＤとこの特定のユーザに関連する任意の許可ポリシーに基づいて、必要であれば、この要求に関する許可を入手することができる。次にポイントオブコンタクト・サーバは、要求されたバックエンド・アプリケーションまたはサービスに任意の関連情報とともにユーザの要求を転送し（ステップ３３４）、それにより、プロセスを完了する。
【０１０４】
ポイントオブコンタクト・サーバとトラスト・プロキシとの間で転送されるデータ項目およびそのデータ項目のフォーマットは様々になる可能性があることに留意されたい。メッセージからアサーションを抽出し、アサーションのみをトラスト・プロキシに転送するのではなく、ポイントオブコンタクト・サーバは、メッセージ全体をトラスト・プロキシに転送することができる。たとえば、トラスト・プロキシにおける処理は、ＳＯＡＰメッセージ関するシグニチャ妥当性検査のようなステップを含むことができ、これはＳＯＡＰエンベロープ全体を必要とするであろう。
【０１０５】
次に図１２を参照すると、フローチャートは、発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが発行側ドメイン内のＷｅｂページまたは同様のリソースから依存側ドメインへのリンクにアクセスしたときに始まり（ステップ３４２）、それにより、特定のアサーションを構築するために何らかの形のＣＧＩ（コモン・ゲートウェイ・インターフェース）タイプの処理を呼び出す。依存側ドメインによるアサーションの必要性を認識する発行側ドメインの能力は、本発明のフェデレーテッド・インフラストラクチャが実現される既存のレガシー・システムとの緊密統合を示している。また、これは、発行側パーティが必要なアサーションを構築するためにトラスト・プロキシを呼び出す必要がないような、発行側パーティと依存側パーティとの緊密結合も示しており、この緊密結合は、適切に確立された信頼関係を有する特定のタイプのフェデレーテッド・エンティティ間では適切なものである可能性がある。
【０１０６】
発行側ドメインにおけるバックエンド処理は、必要なアサーションを構築するために呼び出され（ステップ３４４）、これは、ローカル・トラスト・プロキシにおける呼出し機能を含む可能性がある。次に、必要なアサーションを含む、依存側ドメインへのユーザの要求が構築され（ステップ３４６）、発行側ドメインはユーザの要求とともにアサーションを依存側ドメインに転送し（ステップ３４８）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションを妥当性検査することになるであろう。
【０１０７】
次に図１３を参照すると、フローチャートは、依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを描写している。このプロセスは、ユーザが依存側ドメインにおける保護リソースを要求したときに始まる（ステップ３５２）。ポイントオブコンタクト・サーバは、たとえば、所定のユニフォーム・リソース・アイデンティファイア（ＵＲＩ）、特定のタイプのメッセージ、特定のタイプのメッセージ・コンテンツについて発信メッセージをフィルタリングすることによるか、またはその他の何らかの方法で、発信要求をインターセプトする（ステップ３５４）。次に発行側ドメインのポイントオブコンタクト・サーバは、発行側ドメインのトラスト・プロキシから適切なアサーションの生成を要求し（ステップ３５６）、そのトラスト・プロキシは必要であればトラスト・ブローカからの支援によりアサーションを生成する（ステップ３５８）。次に発行側ドメインは、生成したアサーションとともにユーザの要求を依存側パーティに転送し（ステップ３６０）、それにより、プロセスを完了する。依存側ドメインが要求とそれに関連するアサーションを受信すると、依存側ドメインは図１１に示したようにアサーションを妥当性検査することになるであろう。
【０１０８】
次に図１４を参照すると、フローチャートは、要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを描写している。このプロセスは、依存側ドメインが保護リソースに関するユーザ要求を受信したときに始まる（ステップ３７２）。図１２または図１３に示した例とは対照的に、図１４に示した例は、ユーザに関する必要なアサーションがない場合に依存側ドメインで受信されるユーザの要求に関連する処理を記述している。この場合、発行側ドメインは、ユーザの要求に必要なアサーションを挿入するためにユーザの要求をインターセプトするかまたはその他の方法で処理する能力を持っていない。たとえば、ユーザは、発信要求が発行側ドメインのポイントオブコンタクト・サーバによってインターセプトされないように、ユニフォーム・リソース・ロケータ（ＵＲＬ）を入力したかまたはリソースへのブックマーク付き参照を使用した可能性がある。このため、依存側ドメインは発行側ドメインからアサーションを要求する。
【０１０９】
次に依存側ドメインは、ユーザのホーム・ドメイン、すなわち、関連発行側ドメインを決定する（ステップ３７４）。ＨＴＴＰベースの実現例では、ユーザは、すでに依存側ドメインとの関係を事前設定しており、その結果、ユーザのクライアント装置で依存側ドメインによって永続Ｃｏｏｋｉｅが設定された可能性がある。この永続Ｃｏｏｋｉｅは、ユーザのホーム・ドメイン、すなわち、発行側ドメインのＩＤを含むことになるであろう。ユーザが何らかの方法でＷｅｂサービス・クライアントを操作するＳＯＡＰベースの実現例では、依存側ドメインにおけるＷｅｂサービスは、トークン要件を含む、ＷＳＤＬ（Ｗｅｂサービス記述言語：Web Services Description Language）によるサービス要件を公示したと考えられる。次にこれは、必要なトークン・タイプを提供するためにユーザのＷｅｂサービス・クライアント／ＳＯＡＰ実現例を必要とするであろう。この要件が達成されなかった場合、Ｗｅｂサービスは技術的にエラーを返すことになるであろう。場合によっては、これは、その要求を適切なトークンで繰り返すことができるように、認証情報を入力するようユーザのＷｅｂサービス・クライアントに促すことができるエラー・コードを返す可能性がある。
【０１１０】
依存側ドメインのポイントオブコンタクト・サーバは、依存側ドメインのトラスト・プロキシによりアサーション要求を開始し（ステップ３７６）、それは発行側ドメインのトラスト・プロキシからユーザに関するアサーションを要求する（ステップ３７８）。この実施形態がＨＴＴＰベースの通信を使用している場合、依存側ドメインのトラスト・プロキシから発行側ドメインのトラスト・プロキシへのアサーション要求は、ユーザのブラウザ・アプリケーションによるリダイレクトを介して依存側ドメインのポイントオブコンタクト・サーバによって発行側ドメインのポイントオブコンタクト・サーバに伝送することができ、そのポイントオブコンタクト・サーバはアサーション要求を発行側ドメインのトラスト・プロキシに転送する。
【０１１１】
この実施形態がＳＯＡＰベースの実現例を使用している場合、依存側パーティは、ユーザのＷｅｂサービス・クライアントにエラー・コードを返すことができる。このエラー・コードにより、Ｗｅｂサービス・クライアントによって認証情報を入力するようユーザに促すことができる。次にＷｅｂサービス・クライアントは、要求されたトークンを生成することになるであろう。依存側ドメインのトラスト・プロキシがＵＤＤＩ（ユニバーサル記述、ディスカバリ、および統合：Universal Description, Discovery, and Integration）レジストリで公示され、ユーザのＷｅｂサービス・クライアントがトラスト・プロキシを見つけられるようにしている場合、ユーザのＷｅｂサービス・クライアントはトラスト・プロキシを直接呼び出すことができるであろう。一般に、このシナリオは内部ユーザについてのみ有効であり、その場合、トラスト・プロキシがインターネット上の公用ＵＤＤＩで公示されるかまたはフェデレーション外で一般にアクセス可能になることはありそうもないので、トラスト・プロキシは企業内の専用ＵＤＤＩで公示されている。
【０１１２】
発行側ドメインのトラスト・プロキシは、アサーション要求が受信された方法をミラーリングする方法で、要求されたアサーションを生成し（ステップ３８０）、それを返す（ステップ３８２）。依存側ドメインのトラスト・プロキシが要求されたアサーションを受信した後（ステップ３８４）、依存側ドメインのトラスト・プロキシはアサーションから情報を抽出し（ステップ３８６）、アサーションを解釈するかあるいは妥当性検査するかまたはその両方を行い（ステップ３８８）、トラスト・プロキシはアサーションの変換のために必要であれば、トラスト・ブローカからの支援を呼び出すことができる。そのアサーションを妥当性検査できない場合、適切なエラー応答が生成されることになるであろう。アサーションが妥当性検査されると想定すると、依存側ドメインのトラスト・プロキシは、保護リソースに関するユーザの要求を達成しようと試みるバックエンド・サービスによる使用に必要な適切なフォーマットでローカル情報を構築する（ステップ３９０）。たとえば、ローカル情報は、バックエンド・レガシー・アプリケーションによって要求される認証信用証明情報を含むことができる。依存側ドメインのトラスト・プロキシは、必要な情報を依存側ドメインのポイントオブコンタクト・サーバに返し（ステップ３９２）、次にそれはユーザに関するローカル・セッションを構築し、関連情報とともにユーザの要求を要求されたバックエンド・アプリケーションまたはサービスに転送し（ステップ３９４）、それにより、プロセスを完了する。
【０１１３】
フェデレーテッド・アーキテクチャ内のシングル・サインオン
図６〜図９の説明は本発明によるフェデレーテッド・データ処理環境内のエンティティの動作特性に焦点を合わせているが、図１０〜図１４の説明はこれらのエンティティ間で行われるプロセスのいくつかに焦点を合わせている。これらの説明とは対照的に、ユーザにシングル・サインオン経験を提供しながら、ユーザに関するトランザクションを完了するという目標に焦点を合わせる本発明の説明のために、図１５を参照する。
【０１１４】
換言すれば、以下の説明は、ユーザがユーザのセッション内でシングル・サインオン経験を持つことができる方法に関して本発明の概略視点に焦点を合わせているが、すでに前述したエンティティおよびプロセスについて論ずるものである。セッションは、初期ユーザ認証、すなわち、ログオンから（これを含む）ログアウトまでの１組のトランザクションとして定義することができる。セッション内のユーザのアクションは、部分的に、そのセッションに関してユーザに付与された権限によって支配されることになる。フェデレーション内のユーザは、そのセッション中にアクセスしたフェデレーション・パートナにかかわらず、ユーザが単一認証操作を完了し、そのセッションの期間の間、この認証操作で十分であるシングル・サインオン経験を持つことを期待する。
【０１１５】
ユーザのセッション中に、ユーザは、多くのフェデレーテッド・ドメインにアクセスして、そのドメインによって提供されるＷｅｂサービスを使用することができる。ドメインは、ＵＤＤＩおよびＷＳＤＬなどの標準規格を使用して、そのドメインが提供するサービスの記述を公開することができ、そのいずれも共通データ・フォーマットとしてＸＭＬを使用する。ユーザは、同じくこれらの標準規格に準拠するアプリケーションにより、使用可能なサービスおよびサービス・プロバイダを見つける。ＳＯＡＰは、ＸＭＬで表された要求および応答を伝達するためのパラダイムを提供する。フェデレーテッド環境内のエンティティは、とりわけ、これらの規格を使用することができる。
【０１１６】
シングル・サインオン経験を容易にするために、フェデレーテッド環境をサポートするＷｅｂサービスは、ユーザの認証の証明を提供するためにサード・パーティによって生成された認証アサーションまたはセキュリティ・トークンの使用もサポートすることになる。このアサーションは、そのユーザ用のＩＤとともに、発行側パーティに対するユーザの認証の成功を示すある種の証拠を含むことになる。したがって、ユーザは、あるフェデレーション・パートナに対し、伝統的な認証信用証明情報、たとえば、ユーザ名およびパスワードを提示し、異なるフェデレーション・パートナに対し、認証／発行側パーティによって生成されたＳＡＭＬ認証アサーションを提供することができる。
【０１１７】
Ｗｅｂサービス環境内の認証は、企業が許可クライアントにアクセスを制限できるように、Ｗｅｂサービス要求の請求されたＩＤを検証する行為である。Ｗｅｂサービスを要求するかまたは呼び出すユーザは、ほとんど常に認証され、したがって、本発明のフェデレーテッド環境内の認証の必要性はユーザ認証のためのＷｅｂサービスの現行要件とは少しも異ならないものである。また、フェデレーテッド環境により、Ｗｅｂサービスまたはその他のアプリケーションはＷｅｂサービスを要求することができ、これらのＷｅｂサービスも認証されることになるであろう。
【０１１８】
フェデレーテッド・セッションに参加していないユーザの認証は、本発明のフェデレーテッド・アーキテクチャによる影響を受けない。たとえば、特定のドメインの非フェデレーテッド・リソースにアクセスするためにＨＴＴＰ／Ｓによる用紙ベースの認証メカニズムで認証を受ける既存のユーザは、フェデレーテッド環境に関するそのドメインのサポートを導入することによって影響されない。認証は、部分的に、ポイントオブコンタクト・サーバによって処理され、次にそのポイントオブコンタクト・サーバが個別のトラスト・プロキシ・コンポーネントを呼び出すことができる。ポイントオブコンタクト・サーバの使用は、既存のドメインのインフラストラクチャに対する影響を最小限にする。たとえば、ポイントオブコンタクト・サーバは、そのドメインのバックエンドまたはレガシー・アプリケーションおよびシステムによって処理されるすべての非フェデレーテッド要求を通過するように構成することができる。
【０１１９】
ポイントオブコンタクト・サーバは、基本認証、用紙ベースの認証、またはその他の何らかの認証方法などのＨＴＴＰベースの認証方法を呼び出すことを選択することができる。また、ポイントオブコンタクト・サーバは、ＳＡＭＬ認証アサーションなど、認証の証明としてユーザによって提示されたアサーションを認識することにより、フェデレーテッド・トラスト・ドメインもサポートし、そのアサーションは企業トラスト・ドメイン間を越えている。ポイントオブコンタクト・サーバはトラスト・プロキシを呼び出すことができ、次にそのトラスト・プロキシは認証信用証明情報／セキュリティ・トークンの妥当性検査のためにそのセキュリティ・トークン・サービスを呼び出すことができる。
【０１２０】
Ｗｅｂサービスまたはその他のアプリケーションの認証は、ユーザの認証と同じプロセスを有する。Ｗｅｂサービスからの要求は、認証アサーションを含むセキュリティ・トークンを伝達し、このセキュリティ・トークンはユーザによって提示されるトークンと同じようにトラスト・プロキシ／セキュリティ・トークン・サービスによって妥当性検査されることになるであろう。ＷｅｂサービスはＵＤＤＩで公示された要求されたサービスによってどの認証アサーション／セキュリティ・トークンが要求されているかをすでに発見していると考えられるので、Ｗｅｂサービスからの要求は必ずそれとともにこのトークンを伝達しなければならない。
【０１２１】
次に図１５を参照すると、ブロック図は、フェデレーテッド・シングル・サインオン操作をサポートするフェデレーテッド環境を描写している。ユーザ４００は、クライアント装置およびブラウザなどの適切なクライアント・アプリケーションにより、企業／ドメイン４１０によって提供されるＷｅｂサービスにアクセスすることを所望し、その企業／ドメインは、フェデレーテッド環境内のフェデレーテッド・ドメインとして動作するデータ処理システムをサポートする。ドメイン４１０はポイントオブコンタクト・サーバ４１２およびトラスト・プロキシ４１４をサポートし、同様に、ドメイン４２０はポイントオブコンタクト・サーバ４２２およびトラスト・プロキシ４２４をサポートし、ドメイン４３０はポイントオブコンタクト・サーバ４３２およびトラスト・プロキシ４３４をサポートする。トラスト・プロキシは、上述の通り、支援のためにトラスト・ブローカ４５０を当てにする。追加のドメインおよびトラスト・プロキシもフェデレーテッド環境に参加することができる。図１５は、ドメイン４１０とドメイン４２０との間のフェデレーテッド・シングル・サインオン操作を記述しており、同様の操作はドメイン４１０とドメイン４３０との間でも行うことができる。
【０１２２】
ユーザはドメイン４１０に関する認証操作を完了し、この認証操作はポイントオブコンタクト・サーバ４１２によって処理される。たとえば、アクセス制御またはパーソナライゼーションのために、認証済みＩＤを必要とする何らかのリソースへのアクセスをユーザが要求すると、認証操作がトリガされる。ポイントオブコンタクト・サーバ４１２は、レガシー認証サービスを呼び出す場合もあれば、トラスト・プロキシ４１４を呼び出してユーザが提示した認証信用証明情報を妥当性検査する場合もある。ドメイン４１０は、ユーザのフェデレーテッド・セッションの期間中、ユーザのホーム・ドメインになる。
【０１２３】
その後のある時点で、ユーザは、同じくフェデレーテッド・ドメインをサポートする企業４２０などのフェデレーション・パートナにおいてトランザクションを開始し、それにより、フェデレーテッド・シングル・サインオン操作をトリガする。たとえば、ユーザがドメイン４２０で新しいトランザクションを開始する場合もあれば、ユーザの元のトランザクションが他のドメインにおける１つまたは複数の追加トランザクションにカスケードする場合もある。もう１つの例として、ユーザは、たとえば、ドメイン４１０内でホストとして処理されるＷｅｂページ上の特殊リンクを選択するか、またはドメイン４１０内でホストとして処理されるがドメイン４２０内でホストとして処理されるリソースを表示するポータル・ページを要求することにより、ポイントオブコンタクト・サーバ４１２を介してドメイン４２０内のリソースへのフェデレーテッド・シングル・サインオン操作を呼び出すこともできる。ポイントオブコンタクト・サーバ４１２は、ドメイン４２０によって理解または信頼されるようにフォーマットされた、そのユーザ用のフェデレーション・シングル・サインオン・トークンを生成するために、トラスト・プロキシ４１４に要求を送信する。トラスト・プロキシ４１４はこのトークンをポイントオブコンタクト・サーバ４１２に返し、そのポイントオブコンタクト・サーバ４１２はこのトークンをドメイン内のポイントオブコンタクト・サーバ４２２に送信する。ドメイン４１０は、依存側パーティとして動作するドメイン４２０のユーザのための発行側パーティとして動作する。ユーザのトークンはユーザの要求とともにドメイン４２０に転送されると考えられ、このトークンはユーザのブラウザによるＨＴＴＰリダイレクトを使用して送信される場合もあれば、トラスト・プロキシ４１４によって供給されるトークンで識別されるユーザに代わって（ＨＴＴＰまたはＨＴＴＰによるＳＯＡＰにより）ポイントオブコンタクト・サーバ４２２の要求を直接呼び出すことにより送信される場合もある。
【０１２４】
ポイントオブコンタクト・サーバ４２２は、フェデレーション・シングル・サインオン・トークンとともにその要求を受信し、トラスト・プロキシ４２４を呼び出す。トラスト・プロキシ４２４は、フェデレーション・シングル・サインオン・トークンを受信し、そのトークンを妥当性検査し、そのトークンが有効で信頼されているものと想定して、ユーザのためにローカルで有効なトークンを生成する。トラスト・プロキシ４２４はローカルで有効なトークンをポイントオブコンタクト・サーバ４２２に返し、そのポイントオブコンタクト・サーバはドメイン４２０内でそのユーザに関するセッションを確立する。必要であれば、ポイントオブコンタクト・サーバ４２２は、他のフェデレーテッド・パートナにおいてフェデレーテッド・シングル・サインオンを開始することができる。
【０１２５】
ドメイン４２０におけるトークンの妥当性検査は、おそらく、セキュリティ・トークン・サービスからの支援により、トラスト・プロキシ４２４によって処理される。ドメイン４１０によって提示されたトークンのタイプに応じて、セキュリティ・トークン・サービスは、ドメイン４２０のユーザ・レジストリにアクセスする必要がある場合もある。たとえば、ドメイン４２０は、ドメイン４２０のユーザ・レジストリに照らし合わせて妥当性検査すべき、ユーザの名前とパスワードを含むバイナリ・セキュリティ・トークンを提供することができる。このため、この例では、企業は単に、フェデレーテッド・パートナからのセキュリティ・トークンを妥当性検査するだけである。ドメイン４１０と４２０との信頼関係は、ユーザに代わってドメイン４１０によって提示されたセキュリティ・トークンをドメイン４２０が理解し信頼できることを保証する。
【０１２６】
フェデレーテッド・シングル・サインオンは、ユーザに代わって依存側ドメインに提示されるセキュリティ・トークンの妥当性検査のみならず、セキュリティ・トークンに含まれる情報に基づいて依存側ドメインにおいてローカルで有効なユーザＩＤを決定することも必要とする。このような関係を確立するために必要な直接的信頼関係と事業協定の結果の１つとして、少なくとも１つのパーティ、発行側ドメインあるいは依存側ドメインのいずれか一方またはその両方は、発行側ドメインによって提供された情報を依存側ドメインで有効なＩＤに変換する方法を把握することになる。上記の簡単な例では、発行側ドメイン、すなわち、ドメイン４１０が依存側ドメイン、すなわち、ドメイン４２０にドメイン４２０で有効なユーザＩＤを提供できるものと想定されていた。そのシナリオでは、依存側ドメインは、ＩＤマッピング機能を呼び出す必要はなかった。ドメイン４２０におけるトラスト・プロキシ４２４は、このユーザの「保証人となる」、ユーザ用のセキュリティ・トークンを生成することになる。受諾されるトークンのタイプ、トークン上で必要なシグニチャ、およびその他の要件はいずれも、フェデレーションの事業協定の一部として事前確立される。ＩＤ変換を支配するルールおよびアルゴリズムも、フェデレーションの事業協定の一部として事前確立される。２つの参加者間の直接的信頼関係の場合、ＩＤ変換アルゴリズムは、その２つのパーティについて確立されていることになり、フェデレーション内の他のどのパーティにも関連しない可能性がある。
【０１２７】
しかし、ドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングする方法を発行側ドメインが把握することが常に実情であるわけではない。場合によっては、このマッピングを実行する方法を把握しているのは依存側ドメインである可能性があり、さらに他の場合には、いずれのパーティもこの変換を実行する方法を把握しなくなり、その場合、サード・パーティのトラスト・ブローカを呼び出す必要がある可能性もある。換言すれば、ブローカリングされた信頼関係の場合、発行側ドメインと依存側ドメインは互いに直接的信頼関係を持っていない。しかし、それらのドメインは、トラスト・ブローカ４５０などのトラスト・ブローカとの直接的信頼関係を持つことになる。ＩＤマッピング・ルールおよびアルゴリズムは、この関係の一部として確立されたものになり、トラスト・ブローカはこの情報を使用して、ブローカリングされた信頼関係に必要なＩＤ変換を支援することになる。
【０１２８】
ドメイン４２０は、ポイントオブコンタクト・サーバ４２２においてドメイン４１０によって発行されたトークンを受信し、そのポイントオブコンタクト・サーバはトラスト・プロキシ４２４を呼び出して、トークンを妥当性検査し、ＩＤマッピングを実行する。この場合、トラスト・プロキシ４２４はドメイン４１０用のローカルＩＤからドメイン４２０用のローカルＩＤにユーザをマッピングすることができないので、トラスト・プロキシ４２４はトラスト・ブローカ４５０を呼び出し、そのトラスト・ブローカがトークンを妥当性検査し、ＩＤマッピングを実行する。そのユーザ用のローカルＩＤを入手した後、トラスト・プロキシ４２４は、おそらくそのセキュリティ・トークン・サービスにより、ドメイン４２０においてバックエンド・アプリケーションによって要求される任意のローカル・トークンを生成することができ、たとえば、ポイントオブコンタクト・サーバからアプリケーション・サーバへのシングル・サインオンを容易にするためにＫｅｒｂｅｒｏｓトークンが要求される可能性がある。必要であれば、ローカルで有効なトークンを入手した後、ポイントオブコンタクト・サーバはそのユーザ用のローカル・セッションを構築することができる。また、ポイントオブコンタクト・サーバは、ユーザ要求の粗雑な許可を処理し、ドメイン４２０内の適切なアプリケーション・サーバに許可された要求を転送することになる。
【０１２９】
ユーザのセッションは、ユーザがログアウトまたはサインオフしたときに終了する。ユーザがそのホーム・ドメインとのセッションからログアウトすると、ホーム・ドメインはすべての依存側ドメイン、すなわち、それがセキュリティ・トークンを発行したドメインに通知し、これらのドメインにおいてユーザ・ログアウトを呼び出すことになるであろう。次にこれらの依存側ドメインのいずれかが同じユーザのための発行側ドメインとして動作した場合、そのドメインは、カスケード式にユーザ・ログアウト要求についてその依存側ドメインのすべてに通知することになるであろう。各ドメインのトラスト・プロキシは、ユーザのログアウト要求をすべての依存側ドメインに通知することを担当することになり、トラスト・プロキシはこのプロセスの一部としてトラスト・ブローカを呼び出すことができる。
【０１３０】
上記で提供されている本発明の詳細な説明を考慮すると、本発明の利点は明らかであるはずである。従来技術のソリューションは、ドメイン・セキュリティ・サービスを階層として編成し、それにより、ドメインは堅い信頼関係と本質的に互換性のある技術を有する必要がある。その他の手法は、認証アサーションに均一フォーマットを賦課するかまたは認証アサーションの転送を可能にせず、ときには、それからローカル・アサーションが構築される認証済みＩＤを転送する。
【０１３１】
本発明の利点の中で、トラスト・プロキシは、所与のドメイン内の既存のセキュリティ・サービスが、同じトラスト・ルートに加入するかまたは同じ信頼確立技術を使用する必要なしに、他のドメインとの信頼関係を確立できるようにするものである。このため、本発明のフェデレーテッド・アーキテクチャは、エンティティの疎結合を提供する。ホーム・ドメインは認証を管理し、各ドメインはそれ自体の登録済みユーザのみの認証を管理する。各ドメインは、ユーザＩＤおよび属性に関する任意の他のドメインのステートメントを自由に受諾、拒否、または変更することができる。依存側ドメインは、ＩＤおよび属性に関する発行側ドメイン（最終的に、ホーム・ドメイン）のアサーションを当てにするが、各ドメインは任意の認証プロトコルを実現することができ、そのドメインがフェデレーションに参加するために前にサポートされていないプロトコルを実現するよう所与のドメイン内のアプリケーションを変更する必要はない。フェデレーションは特定のトラスト・モデルを必要とせず、１組のエンティティは、参加エンティティがすでに確立している可能性のあるトラスト・モデルに適合するフェデレーションを形成することができる。アサーション変換は、トラスト・プロキシあるいはトラスト・ブローカまたはその両方でのみ行われ、フェデレーション・アーキテクチャは、既存のレガシー・システムに対する最小限の影響で実現可能なフロントエンド・インフラストラクチャとして動作する。
【０１３２】
フェデレーションにより、ユーザは、シングル・サインオン方式で所与のフェデレーション内の種々のサイトをシームレスにトラバースすることができる。フェデレーション参加者間で信頼関係が確立されているので、ある参加者はあるユーザを認証し、その後、そのユーザのための発行側パーティとして動作することができる。他のフェデレーション・パートナは依存側パーティになり、それにより、そのパートナは、ユーザの直接的関与なしに発行側パーティによってユーザに関して提供される情報を当てにする。
【０１３３】
完全に機能するデータ処理システムに関連して本発明を説明してきたが、当業者であれば、配布を実行するために実際に使用される特定のタイプの信号運搬メディアにかかわらず、本発明のプロセスがコンピュータ可読メディア内の命令の形および様々なその他の形で配布可能であることが分かることは、留意すべき重要なことである。コンピュータ可読メディアの例としては、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フレキシブル・ディスク、ハードディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどのメディア、ならびにデジタルおよびアナログ通信リンクなどの伝送タイプのメディアを含む。
【０１３４】
１つの方法は一般に、所望の結果に至る首尾一貫したステップのシーケンスであると考えられている。これらのステップは、物理量の物理的操作を必要とする。必ずではないが、通常、これらの量は、保管、転送、結合、比較、およびその他の操作が可能な電気信号または磁気信号の形を取る。時には、主に一般的使用の理由で、これらの信号をビット、値、パラメータ、項目、エレメント、オブジェクト、記号、文字、項、数などと呼ぶと便利である。しかし、これらの用語および同様の用語はいずれも適切な物理量に関連付けられるものであり、単にこれらの量に適用された便利なラベルにすぎないことに留意されたい。
【０１３５】
本発明の説明は、例示のために提示されたものであり、網羅的なものまたは開示された実施形態に限定されるものではない。当業者には、多くの変更および変形が明らかになるであろう。実施形態は、本発明の原理およびその実際的な適用例を説明し、他の企図された使用法に適している可能性がある様々な変更を含む様々な実施形態を実現するために他の当業者が本発明を理解できるようにするために選択されたものである。
【図面の簡単な説明】
【０１３６】
【図１】そのそれぞれが本発明を実現可能な複数データ処理システムの典型的なネットワークを示す図である。
【図２】本発明を実現可能なデータ処理システム内で使用できる典型的なコンピュータ・アーキテクチャを示す図である。
【図３】クライアントがサーバ側の保護リソースにアクセスしようと試みるときに使用できる典型的な認証プロセスを示すデータ・フロー・ダイアグラムである。
【図４】本発明を実現可能な典型的なＷｅｂベース環境を示すネットワーク・ダイアグラムを示す図である。
【図５】ユーザからの複数の認証操作を必要とする可能性のある典型的なオンライン・トランザクションの一例を示すブロック図である。
【図６】第１のフェデレーテッド企業に対してユーザによって開始され、それに応答して、フェデレーテッド環境内のダウンストリーム・エンティティでアクションを呼び出すトランザクションに関するフェデレーテッド環境の用語を示すブロック図である。
【図７】本発明の一実施形態により本発明のフェデレーテッド・アーキテクチャ・コンポーネントのいくつかと所与のドメインにある既存のシステムとの統合を示すブロック図である。
【図８】本発明の一実現例によるフェデレーテッド・アーキテクチャを示すブロック図である。
【図９】本発明によりトラスト・プロキシとトラスト・ブローカとを使用するフェデレーテッド・ドメイン間の例示的な１組の信頼関係を示すブロック図である。
【図１０】フェデレーテッド環境内でアサーションを作成するための発行側ドメインにおける汎用プロセスを示すフローチャートである。
【図１１】アサーションを取り壊すための依存側ドメインにおける汎用プロセスを示すフローチャートである。
【図１２】発行側ドメインにおけるユーザ・アクションに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。
【図１３】依存側ドメインに対する発信要求を積極的にインターセプトする発行側ドメインに応答して発行側ドメインから依存側ドメインにアサーションをプッシュするための特定のプロセスを示すフローチャートである。
【図１４】要求側ユーザから依存側ドメインによって受信されたリソース要求を満足しようと試みながら、依存側ドメインが発行側ドメインからユーザに関して必要なアサーションを要求するプル・モデルを示すフローチャートである。
【図１５】フェデレーテッド・シングル・サインオン操作をサポートするフェデレーテッド環境を示すブロック図である。
【特許請求の範囲】
【請求項１】
データ処理システム内でユーザを認証するための方法において、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するステップと、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するステップと、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するステップと、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するステップと、
を有する、方法。
【請求項２】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするステップ
をさらに有する、請求項１に記載の方法。
【請求項３】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するステップと、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするステップと、
をさらに有する、請求項１に記載の方法。
【請求項４】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするステップ
をさらに有する、請求項１に記載の方法。
【請求項５】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するステップ
をさらに有する、請求項１に記載の方法。
【請求項６】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するステップ
をさらに有する、請求項１に記載の方法。
【請求項７】
データ処理システム内でユーザを認証するための装置において、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するための手段と、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するための手段と、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するための手段と、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するための手段と、
を有する、装置。
【請求項８】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするための手段
をさらに有する、請求項７に記載の装置。
【請求項９】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するための手段と、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするための手段と、
をさらに有する、請求項７に記載の装置。
【請求項１０】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするための手段
をさらに有する、請求項７に記載の装置。
【請求項１１】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するための手段
をさらに有する、請求項７に記載の装置。
【請求項１２】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するための手段
をさらに有する、請求項７に記載の装置。
【請求項１３】
ユーザを認証するためにデータ処理システム内で使用するためのコンピュータ可読メディア内のコンピュータ・プログラムにおいて、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するための手段と、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するための手段と、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するための手段と、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するための手段と、
を有する、コンピュータ・プログラム。
【請求項１４】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１５】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するための手段と、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするための手段と、
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１６】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１７】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１８】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【特許請求の範囲】
【請求項１】
ユーザの認証するための複数の認証ドメインを含む分散コンピューティング環境に適用される方法であり、
第１の認証トークン・フォーマットによりフォーマットされた認証アサーションを第１の認証ドメイン内のシステムから、第２の認証ドメイン内のシステムにおいて、受信するステップと、
前記第２の認証ドメインに関連するトラスト・プロキシに対して前記認証アサーションを経路指定するステップと
前記第１の認証トークン・フォーマットから前記第２の認証ドメイン内で使用される第２の認証トークン・フォーマットに前記認証アサーションを変換することを前記トラスト・プロキシで決定するステップと、
前記認証アサーションを前記第２の認証トークン・フォーマットに変換するステップと、
を有する、方法。
【請求項２】
前記第２の認証ドメイン内のポイントオブコンタクト・サーバで前記受信ステップと前記経路指定ステップを実行する
、請求項１に記載の方法。
【請求項３】
前記第１の認証ドメイン内の認証の証明またはＩＤのアサーションとして前記第２の認証ドメイン内で前記認証アサーションを受諾するステップ
をさらに有する、請求項１に記載の方法。
【請求項４】
前記分散コンピューティング環境内でシングル・サインオン操作を実現するために、前記第２の認証ドメイン内で前記認証アサーションを受諾するステップ
をさらに有する、請求項１に記載の方法。
【請求項５】
前記第２の認証ドメイン内で識別可能なリソースに関する要求を前記第１の認証ドメイン内の前記システムから、前記第２の認証ドメイン内の前記システムにおいて、受信するステップと、
前記第２の認証ドメイン内でホストとして処理されるアプリケーション・サーバに前記リソースに関する前記要求を経路指定するステップと、
前記アプリケーション・サーバにより認証質問をトリガするステップと、
前記第２の認証トークン・フォーマットに変換された前記認証アサーション内の情報を使用して、前記第２の認証ドメイン内のシステムにより、前記認証質問に応答するステップと、
をさらに有する、請求項１に記載の方法。
【請求項６】
前記第２の認証ドメイン内で有効なトークン・フォーマットに前記認証アサーションを変換するためにトラスト・ブローカからの支援を呼び出すステップであって、前記トラスト・ブローカが前記分散コンピューティング環境内の複数の認証ドメインとの信頼関係を維持するステップ
をさらに有する、請求項１に記載の方法。
【請求項７】
前記第２の認証ドメイン内でホストとして処理されるセキュリティ・トークン・サービス内でセキュリティ・トークンの変換を実行するステップ
をさらに有する、請求項１に記載の方法。
【請求項８】
請求項１ないし７のいずれか１項に記載の前記方法の各ステップを実行する手段を有する装置。
【請求項９】
請求項１ないし７のいずれか１項に記載の前記方法の各ステップをコンピュータに実行させる命令を有するコンピュータ・プログラム。
【請求項１】
データ処理システム内でユーザを認証するための方法において、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するステップと、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するステップと、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するステップと、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するステップと、
を有する、方法。
【請求項２】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするステップ
をさらに有する、請求項１に記載の方法。
【請求項３】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するステップと、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするステップと、
をさらに有する、請求項１に記載の方法。
【請求項４】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするステップ
をさらに有する、請求項１に記載の方法。
【請求項５】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するステップ
をさらに有する、請求項１に記載の方法。
【請求項６】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するステップ
をさらに有する、請求項１に記載の方法。
【請求項７】
データ処理システム内でユーザを認証するための装置において、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するための手段と、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するための手段と、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するための手段と、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するための手段と、
を有する、装置。
【請求項８】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするための手段
をさらに有する、請求項７に記載の装置。
【請求項９】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するための手段と、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするための手段と、
をさらに有する、請求項７に記載の装置。
【請求項１０】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするための手段
をさらに有する、請求項７に記載の装置。
【請求項１１】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するための手段
をさらに有する、請求項７に記載の装置。
【請求項１２】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するための手段
をさらに有する、請求項７に記載の装置。
【請求項１３】
ユーザを認証するためにデータ処理システム内で使用するためのコンピュータ可読メディア内のコンピュータ・プログラムにおいて、
第１のドメイン内の第１のトラスト・プロキシで前記ユーザに関する認証アサーションを生成するための手段と、
第２のドメイン内のシステムで、前記第２のドメイン内の被制御リソースにアクセスするために前記ユーザによって操作されるクライアントからの要求を受信するための手段と、
前記第１のドメインから前記第２のドメイン内の第２のトラスト・プロキシに前記認証アサーションを送信するための手段と、
前記第２のドメイン内の前記第２のトラスト・プロキシで前記認証アサーションを妥当性検査するための手段と、
を有する、コンピュータ・プログラム。
【請求項１４】
前記第２のトラスト・プロキシにおける前記認証アサーションの妥当性検査の成功に応答して、前記被制御リソースへのアクセスを可能にするための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１５】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信する前に、前記第１のトラスト・プロキシで前記ユーザに関する前記認証アサーションを生成することを前記第１のドメイン内で決定するための手段と、
前記被制御リソースに関する前記要求とともに前記第１のドメインから前記第２のドメインに前記認証アサーションをプッシュするための手段と、
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１６】
前記第２のドメイン内の前記システムで前記被制御リソースに関する前記要求を受信した後で、前記第２のトラスト・プロキシからの前記認証アサーションを前記第１のトラスト・プロキシからプルするための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１７】
前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の信頼関係を確立するための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【請求項１８】
トラスト・ブローカにより前記第１のトラスト・プロキシと前記第２のトラスト・プロキシとの間の間接的関係を維持するための手段
をさらに有する、請求項１３に記載のコンピュータ・プログラム。
【特許請求の範囲】
【請求項１】
ユーザの認証するための複数の認証ドメインを含む分散コンピューティング環境に適用される方法であり、
第１の認証トークン・フォーマットによりフォーマットされた認証アサーションを第１の認証ドメイン内のシステムから、第２の認証ドメイン内のシステムにおいて、受信するステップと、
前記第２の認証ドメインに関連するトラスト・プロキシに対して前記認証アサーションを経路指定するステップと
前記第１の認証トークン・フォーマットから前記第２の認証ドメイン内で使用される第２の認証トークン・フォーマットに前記認証アサーションを変換することを前記トラスト・プロキシで決定するステップと、
前記認証アサーションを前記第２の認証トークン・フォーマットに変換するステップと、
を有する、方法。
【請求項２】
前記第２の認証ドメイン内のポイントオブコンタクト・サーバで前記受信ステップと前記経路指定ステップを実行する
、請求項１に記載の方法。
【請求項３】
前記第１の認証ドメイン内の認証の証明またはＩＤのアサーションとして前記第２の認証ドメイン内で前記認証アサーションを受諾するステップ
をさらに有する、請求項１に記載の方法。
【請求項４】
前記分散コンピューティング環境内でシングル・サインオン操作を実現するために、前記第２の認証ドメイン内で前記認証アサーションを受諾するステップ
をさらに有する、請求項１に記載の方法。
【請求項５】
前記第２の認証ドメイン内で識別可能なリソースに関する要求を前記第１の認証ドメイン内の前記システムから、前記第２の認証ドメイン内の前記システムにおいて、受信するステップと、
前記第２の認証ドメイン内でホストとして処理されるアプリケーション・サーバに前記リソースに関する前記要求を経路指定するステップと、
前記アプリケーション・サーバにより認証質問をトリガするステップと、
前記第２の認証トークン・フォーマットに変換された前記認証アサーション内の情報を使用して、前記第２の認証ドメイン内のシステムにより、前記認証質問に応答するステップと、
をさらに有する、請求項１に記載の方法。
【請求項６】
前記第２の認証ドメイン内で有効なトークン・フォーマットに前記認証アサーションを変換するためにトラスト・ブローカからの支援を呼び出すステップであって、前記トラスト・ブローカが前記分散コンピューティング環境内の複数の認証ドメインとの信頼関係を維持するステップ
をさらに有する、請求項１に記載の方法。
【請求項７】
前記第２の認証ドメイン内でホストとして処理されるセキュリティ・トークン・サービス内でセキュリティ・トークンの変換を実行するステップ
をさらに有する、請求項１に記載の方法。
【請求項８】
請求項１ないし７のいずれか１項に記載の前記方法の各ステップを実行する手段を有する装置。
【請求項９】
請求項１ないし７のいずれか１項に記載の前記方法の各ステップをコンピュータに実行させる命令を有するコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２００６−５１５４４７（Ｐ２００６−５１５４４７Ａ）
【公表日】平成１８年５月２５日（２００６．５．２５）
【国際特許分類】
【出願番号】特願２００４−５６３２０３（Ｐ２００４−５６３２０３）
【出願日】平成１５年１１月２７日（２００３．１１．２７）
【国際出願番号】ＰＣＴ／ＥＰ２００３／０１４８５２
【国際公開番号】ＷＯ２００４／０５９４１５
【国際公開日】平成１６年７月１５日（２００４．７．１５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１８年５月２５日（２００６．５．２５）
【国際特許分類】
【出願日】平成１５年１１月２７日（２００３．１１．２７）
【国際出願番号】ＰＣＴ／ＥＰ２００３／０１４８５２
【国際公開番号】ＷＯ２００４／０５９４１５
【国際公開日】平成１６年７月１５日（２００４．７．１５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]