JP2008538247A - ランタイム・ユーザ・アカウント作成オペレーションのための方法、装置、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】フェデレーテッド・コンピューティング環境内で対話する異なる企業のコンピューティング・システムをサポートするための、方法、システム、装置、およびコンピュータ・プログラム製品を提示すること。
【解決手段】フェデレーテッド・シングル・サインオン・オペレーションは、たとえユーザがシングル・サインオン・オペレーションの開始に先立ってフェデレーション・パートナでユーザ・アカウントを確立していない場合であっても、ユーザに代わってフェデレーション・パートナのコンピューティング・システムで開始することができる。たとえばアイデンティティ・プロバイダは、ユーザに代わって制御リソースへのアクセスを取得するように試行しながら、サービス・プロバイダでシングル・サインオン・オペレーションを開始することができる。アイデンティティ・プロバイダからのシングル・サインオン・オペレーションを可能にする、ユーザに関するリンク済みユーザ・アカウントを有していないことをサービス・プロバイダが認識した場合、サービス・プロバイダはローカル・ユーザ・アカウントを作成する。サービス・プロバイダは、ユーザ・アカウント作成オペレーションを実行するために、必要に応じてアイデンティティ・プロバイダからユーザ属性を収集することもできる。
【選択図】 図７

Description

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

企業は一般に、インターネットを含む様々なネットワーク全体を通じて、保護されたリソースへのセキュアなアクセスを、許可されたユーザに対してユーザ・フレンドリな方法で提供することを望む。セキュアな認証メカニズムを提供することによって、保護されたリソースへの未許可のアクセスのリスクは減少するが、それらの認証メカニズムが保護されたリソースへのアクセスに対するバリアとなる可能性がある。ユーザは一般に、アプリケーションをサポートする各特定システムを保護する認証バリアを意識することなく、１つのアプリケーションとの対話から他のアプリケーションとの対話へと変更するための機能を望む。

ユーザが洗練されていくにつれて、ユーザにかかる負担を軽減するようにコンピュータ・システムがそれらのアクションを調整することを期待する。これらのタイプの期待は、認証プロセスにもかけられる。ユーザは、何らかのコンピュータ・システムから認証されると、ユーザにはほとんどわからない様々なコンピュータ・アーキテクチャ境界を意識することなく、その認証がユーザの作業セッション全体にわたって、または少なくとも特定の期間にわたって、有効であるはずであると想定する可能性がある。企業は一般に、ユーザの不満を静めるためだけでなく、ユーザ効率が従業員の生産性または顧客の満足度のいずれに関する場合であっても、ユーザの効率を上げるために、自社の展開したシステムの動作特性においてこれらの期待を満たそうと努力する。

とりわけ、多くのアプリケーションが一般のブラウザを介してアクセス可能なウェブ・ベースのユーザ・インターフェースを有する現在のコンピューティング環境では、ユーザは、よりユーザ・フレンドリであること、およびウェブ・ベースのアプリケーション間での移動に対する低いかまたは少ないバリアを期待する。これに関連してユーザは、あるインターネット・ドメイン上にあるアプリケーションとの対話から、別のドメイン上にある別のアプリケーションとの対話へと、各特定ドメインを保護する認証バリアを意識することなく、ジャンプできる機能を期待するようになる。しかしながら、たとえ多くのシステムが、使いやすいウェブ・ベースのインターフェースを介してセキュアな認証を提供する場合であっても、ユーザは依然として、ドメイン・セットを横切るユーザ・アクセスを妨害する複数の認証プロセスを考慮に入れなければならない可能性がある。所与の時間枠内にユーザが複数の認証プロセスを実施しなければならない場合、ユーザの効率に多大な影響を与える可能性がある。

たとえば、ユーザおよびコンピュータ・システム管理者にかかる認証の負担を軽減するために様々な技法が使用されてきた。これらの技法は、ユーザがあるサインオン・オペレーションを完了した後、すなわち認証された後は、他の認証オペレーションを実行する必要がないという、共通の目的を有することから、一般に「シングル・サインオン」（ＳＳＯ）プロセスと呼ばれる。したがって、ユーザは特定のユーザ・セッション中に１回だけ認証プロセスを完了すればよいということが目標である。

ユーザ管理のコストを削減するため、および企業間の相互協調処理容易性（interoperability）を向上させるために、フェデレーテッド（federated）コンピューティング・スペースが作成されてきた。フェデレーションとは、ある種の相互協調処理容易性の標準を遵守する企業の柔軟に結合された提携であり、フェデレーションは、フェデレーション内のユーザ向けのある種のコンピュータ・オペレーションに関して、それらの企業間の信頼のためのメカニズムを提供する。たとえばフェデレーション・パートナは、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダとして働くことができる。同じフェデレーション内の他のパートナは、たとえば、ユーザのアイデンティティ・プロバイダによって提供されるシングル・サインオン・トークンの受け入れなどの、ユーザの認証証明の主たる管理に関して、そのユーザのアイデンティティ・プロバイダに依拠することができる。

フェデレートされたビジネス対話をサポートするために企業が移動する場合、これらの企業は、２つのビジネス間で増加する連携を反映するユーザ体験を提供するはずである。前述のように、ユーザは、アイデンティティ・プロバイダとして働く一方の当事者を認証し、サービス・プロバイダとして働くフェデレーテッド・ビジネス・パートナにシングル・サインオンすることができる。シングル・サインオン機能と共に、シングル・サインオフ、ユーザ・プロビジョニング、およびアカウントのリンク／リンク解除（delink）などの、追加のユーザ・ライフサイクル機能もサポートされるはずである。

シングル・サインオン・ソリューションは、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザが色々な形で識別できることを必要とし、アイデンティティ・プロバイダはユーザを識別および認証できる必要があり、サービス・プロバイダはシングル・サインオン要求に応答してユーザに関する何らかの形のアサーションに基づいてユーザを識別できる必要がある。たとえばＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦ仕様に記載されたような、様々な従来技術のシングル・サインオン・ソリューションは、フェデレーテッド・シングル・サインオン・オペレーションに対する前提条件として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザが認証可能アカウントを有することを必要とする。いくつかのフェデレーテッド・ソリューションは、事前ユーザ・アカウントを確立するために使用されることになるドメインを横切る、事前ユーザ・アカウント作成イベントをサポートし、それによって、フェデレーテッド・シングル・サインオン・オペレーションに対する前提条件として、アイデンティティ・プロバイダおよびサービス・プロバイダの両方で、ユーザが認証可能アカウントを有するという要件を満たす。いくつかのフェデレーテッド・ソリューションは、ユーザ・アカウント作成、ユーザ・アカウント管理、ユーザ属性管理、アカウント一時停止（suspension）、およびアカウント削除などの、フェデレーテッド・ユーザ・ライフサイクル管理オペレーションの堅固なセットを提供するが、これらのフェデレーテッド管理システムは、ある種のフェデレーション・パートナまたはある種のフェデレートされた目的に好適な、軽量ソリューションを提供しない。
米国特許出願公開ＵＳ２００４／０１２８３７８Ａ１号 米国特許出願第１０／３３４６０５号 １９９３年９月付の、Ｋｏｈｌ等による「The Kerberos Network Authentication Service(V5)」、Internet Engineering Task Force (IETF)Request for Comments (RFC) 1510 ２００２年５月３１日付の「Assertions and Protocol for the OASIS Security Assertion MarkupLanguage (SAML)」、CommitteeSpecification 01

したがって、フェデレーテッド・コンピューティング環境において、大量の事前処理を必要としない軽量な形で、企業が包括的なシングル・サインオン体験をユーザに提供できる、方法およびシステムを有することが有利であろう。

フェデレーテッド・コンピューティング環境内で対話する異なる企業のコンピューティング・システムをサポートするための、方法、システム、装置、およびコンピュータ・プログラム製品が提示される。フェデレーテッド・シングル・サインオン・オペレーションは、たとえユーザがシングル・サインオン・オペレーションの開始に先立ってフェデレーション・パートナでユーザ・アカウントを確立していない場合であっても、ユーザに代わってフェデレーション・パートナのコンピューティング・システムで開始することができる。たとえばアイデンティティ・プロバイダは、ユーザに代わって制御リソースへのアクセスを取得するように試行しながら、サービス・プロバイダでシングル・サインオン・オペレーションを開始することができる。アイデンティティ・プロバイダからのシングル・サインオン・オペレーションを可能にする、ユーザに関するリンク済みユーザ・アカウントを有していないことをサービス・プロバイダが認識した場合、サービス・プロバイダは、アイデンティティ・プロバイダからの情報に数なくとも部分的に基づいてローカル・ユーザ・アカウントを作成する。サービス・プロバイダは、ユーザ・アカウント作成オペレーションを実行するために、必要に応じてアイデンティティ・プロバイダからユーザ属性を収集（pull）することもできる。

好ましくは、ユーザ属性情報を取得するために、フロント・チャネル情報取り出しメカニズムが採用される。より好ましくは、フロント・チャネル情報取り出しメカニズムにおいてＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）が使用される。

好ましくは、ユーザ属性情報を取得するために、バック・チャネル情報取り出しメカニズムが採用される。より好ましくは、バック・チャネル情報取り出しメカニズムにおいてＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）が使用される。

次に、本発明について、以下の図面に示された好ましい諸実施形態を参照しながら、単なる例として説明する。

一般に、本発明を備えるかまたは本発明に関することが可能なデバイスは、多種多彩なデータ処理技術を含む。したがって、本発明についてより詳細に説明する前に、背景として、分散データ処理システム内のハードウェアおよびソフトウェア構成要素の典型的な組織について説明する。

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

図示された例では、分散データ処理システム１００は、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの、互いに通信するために様々なプロトコルを使用する、ネットワークおよびゲートウェイの世界的な集まりを表すネットワーク１０１を備えたインターネットを含むことができる。もちろん分散データ処理システム１００は、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）などの、いくつかの異なるタイプのネットワークも含むことができる。たとえば、サーバ１０２は、
クライアント１０９と、無線通信リンクを組み込むネットワーク１１０を直接サポートする。ネットワーク対応電話１１１は無線リンク１１２を介してネットワーク１１０に接続し、ＰＤＡ １１３は無線リンク１１４を介してネットワーク１１０に接続する。電話１１１およびＰＤＡ １１３は、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを作成するために、Ｂｌｕｅｔｏｏｔｈ無線技術などの適切な技術を使用して、それらの間でデータを直接転送することもできる。同様に、ＰＤＡ １１３は、無線通信リンク１１６を介して、ＰＤＡ １０７にデータを転送することができる。

本発明は、様々なハードウェア・プラットフォームおよびソフトウェア環境で実施可能である。図１は、異機種コンピューティング環境の一例として意図されるものであって、本発明に関するアーキテクチャ上の制限としては意図されない。

次に図２を参照すると、本発明が実施可能な、図２に示されたようなデータ処理システムの典型的なコンピュータ・アーキテクチャを示す図である。データ処理システム１２０は、ランダム・アクセス・メモリ（ＲＡＭ）１２４、読み取り専用メモリ１２６、ならびに、プリンタ１３０、ディスク・ユニット１３２、またはオーディオ出力システムなどの図示されていない他のデバイスなどの様々なＩ／Ｏデバイスをサポートする、入力／出力アダプタ１２８を相互接続する、内部システム・バス１２３に接続された、１つまたは複数の中央処理ユニット（ＣＰＵ）１２２を含む。システム・バス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４も接続する。ユーザ・インターフェース・アダプタ１４８は、キーボード１４０およびマウス１４２、またはタッチ・スクリーン、スタイラス、マイクロフォンなどの図示されていない他のデバイスなどの、様々なユーザ・デバイスを接続する。ディスプレイ・アダプタ１４４は、システム・バス１２３をディスプレイ・デバイス１４６に接続する。

通常の当業者であれば、図２のハードウェアがシステム・インプリメンテーションに応じて変更可能であることを理解されよう。たとえばシステムは、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）ベース・プロセッサおよびデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、ならびに１つまたは複数タイプの揮発性および不揮発性メモリを有することができる。（Ｉｎｔｅｌ、Ｉｎｔｅｌロゴ、Ｉｎｔｅｌ Ｉｎｓｉｄｅ、Ｉｎｔｅｌ Ｉｎｓｉｄｅロゴ、Ｉｎｔｅｌ Ｃｅｎｔｒｉｎｏ、Ｉｎｔｅｌ Ｃｅｎｔｒｉｎｏロゴ、Ｃｅｌｅｒｏｎ、Ｉｎｔｅｌ Ｘｅｏｎ、Ｉｎｔｅｌ ＳｐｅｅｄＳｔｅｐ、Ｉｔａｎｉｕｍ、およびＰｅｎｔｉｕｍは、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎまたは米国および諸外国におけるその子会社の商標または登録商標である。）図２に示されたハードウェアに加えて、またはこれらの代わりに、他の周辺デバイスを使用することができる。示された例は、本発明に関してアーキテクチャ上の制限を示唆するものではない。

本発明は、様々なハードウェア・プラットフォーム上で実装可能であることに加えて、様々なソフトウェア環境でも実施可能である。各データ処理システム内でのプログラム実行を制御するために、典型的なオペレーティング・システムを使用することができる。たとえば、１つのデバイスがＵｎｉｘ(登録商標）オペレーティング・システムを実行し、他のデバイスが単純なＪａｖａランタイム環境を含むことが可能である。（ＪａｖａおよびすべてのＪａｖａベースの商標は、米国、諸外国、またはその両方におけるＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃの商標であり、ＵＮＩＸは米国および諸外国内のＴｈｅ Ｏｐｅｎ Ｇｒｏｕｐの登録商標である。）代表的なコンピュータ・プラットフォームは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張可能マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ）、無線マークアップ言語（ＷＭＬ）、ならびに様々な他のフォーマットおよびタイプのファイルなどの、様々なフォーマットのハイパーテキスト文書にアクセスするための周知のソフトウェア・アプリケーションである、ブラウザを含むことができる。図１に示された分散データ処理システムは、様々なピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできるものとして企図されることにも留意されたい。

次に図３を参照すると、クライアントがサーバでの保護されたリソースへのアクセスを試みる場合に使用可能な、典型的な認証プロセスを示すデータ流れ図である。図に示されるように、クライアント・ワークステーション１５０でのユーザは、クライアント・ワークステーション上で実行中のユーザのウェブ・ブラウザを通じて、サーバ１５１上の保護されたリソースへのコンピュータ・ネットワークを介したアクセスを求める。保護または制御されたリソースとは、それに対するアクセスが制御または制約されたリソース（アプリケーション、オブジェクト、ドキュメント、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプ・リソースなど）である。保護されたリソースは、認証されたかまたは許可された、あるいはその両方のユーザによってのみアクセスが可能な、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）によって、またはより一般的にはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）によって、識別される。コンピュータ・ネットワークは、図１または図２に示されたように、インターネット、イントラネット、または他のネットワークとすることが可能であり、サーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ）、サーバ・アプリケーション、サーブレット・プロセス、またはその他とすることが可能である。

プロセスは、ユーザがドメイン「ｉｂｍ．ｃｏｍ」内のウェブ・ページなどのサーバ側の保護されたリソースを要求した場合に開始される（ステップ１５２）。「サーバ側」および「クライアント側」という用語は、それぞれ、ネットワーク環境内のサーバまたはクライアントでのアクションまたはエンティティを言い表す。ウェブ・ブラウザ（あるいは関連付けられたアプリケーションまたはアプレット）は、ＨＴＴＰ要求を生成し（ステップ１５３）、これが、ドメイン「ｉｂｍ．ｃｏｍ」をホストしているウェブ・サーバに送信される。「要求」および「応答」という用語は、メッセージ、通信プロトコル情報、または他の関連付けられた情報などの、特定のオペレーションに関与する情報の転送に適したデータ・フォーマット設定を備えるものと理解されたい。

サーバは、自分がクライアントに対するアクティブ・セッションを有さないものと判断し（ステップ１５４）、クライアントとサーバとの間の複数の情報転送を伴う、サーバとクライアントとの間のＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）セッションの確立を開始および完了する（ステップ１５５）。ＳＳＬセッションが確立された後、ＳＳＬセッション内で後続の通信メッセージが転送され、ＳＳＬセッション内の暗号化通信により、いずれの秘密情報もセキュアなままである。

しかしながら、サーバは、ユーザが保護されたリソースにアクセスできるようにする前に、ユーザのアイデンティティを判別する必要があるため、サーバはユーザに対して、クライアントに何らかのタイプの認証チャレンジ（authentication challenge）を送信すること（ステップ１５６）によって、認証プロセスを実行するように要求する。認証チャレンジは、ＨＴＭＬ形式などの様々なフォーマットとすることができる。次いでユーザは、関連付けられたパスワードまたは他の形の秘密情報と共に、ユーザ名または他のタイプのユーザ識別子などの、要求または必要とされる情報を提供する（ステップ１５７）。

認証応答情報がサーバに送信され（ステップ１５８）、この時点でサーバは、たとえば事前に提出された登録情報を取り出すこと、および提示された認証情報とユーザの格納情報とを付き合わせることによって、ユーザまたはクライアントを認証する（ステップ１５９）。認証が正常に終了したと想定すると、認証されたユーザまたはクライアントに対するアクティブ・セッションが確立される。サーバは、クライアントに対するセッション識別子を作成し、セッション内のクライアントからの任意の後続要求メッセージに、そのセッション識別子が添付されることになる。

次にサーバは、最初に要求されたウェブ・ページを取り出して、ＨＴＴＰ応答メッセージをクライアントに送信し（ステップ１６０）、それによってユーザの保護されたリソースに対するオリジナル要求が満たされる。その時点で、ユーザは、ハイパーテキスト・リンクをクリックすることによって「ｉｂｍ．ｃｏｍ」内の他のページを要求することが可能であり（ステップ１６１）、ブラウザは他のＨＴＴＰ要求メッセージをサーバに送信する（ステップ１６２）。その時点で、ＨＴＴＰ要求メッセージ内でユーザのセッション識別子がサーバに戻されることから、サーバはユーザがアクティブ・セッションを有することを認識し（ステップ１６３）、サーバは要求されたウェブ・ページを他のＨＴＴＰ応答メッセージ内でクライアントに送信する（ステップ１６４）。図３は、典型的な従来技術のプロセスを示すが、認証の証明を提供するために使用されるものと同じクッキーを使用することを含むことができる、アクティブ・セッションを伴うユーザを識別するためのＵＲＬ書き換えまたはクッキーの使用などの、他の代替セッション状態管理技法も記載可能であることに留意されたい。

次に図４を参照すると、本発明が実施可能な典型的なウェブ・ベース環境を示す図である。この環境では、クライアント１７１でのブラウザ１７０のユーザが、ＤＮＳドメイン１７３内のウェブ・アプリケーション・サーバ１７２上、またはＤＮＳドメイン１７５内のウェブ・アプリケーション・サーバ１７４上の、保護されたリソースへのアクセスを希望する。

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

この例では、クライアント１７１がドメイン１７３にある保護されたリソースに関する要求を発行した後、ウェブ・アプリケーション・サーバ１７２は、クライアント１７１に対するアクティブ・セッションを有していないことを判別し、クライアント１７１との適切な認証オペレーションを実行するよう認証サーバ１７６に要求する。認証サーバ１７６は認証オペレーションの結果をウェブ・アプリケーション・サーバ１７２に送る。ユーザ（あるいはユーザの代わりのブラウザ１７０またはクライアント１７１）が正常に認証された場合、ウェブ・アプリケーション・サーバ１７２はクライアント１７１に対するセッションを確立し、要求された保護されたリソースを戻す。通常、ユーザが認証サーバによっていったん認証されると、クッキーを設定し、ブラウザ内のクッキー・キャッシュに格納することができる。図４は、特に認証オペレーションを実行するために、複数のサーバ間でドメインの処理リソースを共有できる方法の単なる一例にすぎない。

同様に、クライアント１７１がドメイン１７５にある保護されたリソースに関する要求を発行した後、認証サーバ１７７はクライアント１７１との適切な認証オペレーションを実行し、その後、ウェブ・アプリケーション・サーバ１７４はクライアント１７１に対するセッションを確立し、要求された保護されたリソースを戻す。したがって図４は、クライアント１７１が異なるドメイン内に複数の同時セッションを有することができることを示すが、依然としてそれらの同時セッションを確立するためには複数の認証オペレーションを完了する必要がある。

次に図５を参照すると、ユーザからの複数の認証オペレーションを必要とする可能性がある、典型的なオンライン・トランザクションの一例を示すブロック図が示される。再度図３および図４を参照すると、ユーザは、図３に示されたように制御されたリソースへのアクセスを取得するのに先立って、認証オペレーションを完了させる必要がある場合がある。図３には示されていないが、ユーザの認証に必要なユーザ情報を取り出して採用するために、サーバ１５１上に認証マネージャを配備することができる。図４に示されるように、ユーザは、異なるドメイン１７３および１７５内に複数の現行セッションを有することが可能であり、それらは図４には示されていないが、各ドメインは認証サーバの代わりに、またはそれらに加えて、認証マネージャを採用することができる。同様に図５は、それぞれが何らかのタイプの認証マネージャをサポートする、ドメインのセットも示す。図５は、ユーザが複数のドメインにアクセスする場合に体験する可能性のある、各ドメインについて認証オペレーションを完了することをユーザに要求するいくつかの問題を示す。

ユーザ１９０は、ドメイン１９１に関するトランザクションを完了する目的でユーザ１９０を認証する認証マネージャ１９２をサポートすることが可能な、ＩＳＰドメイン１９１に登録することが可能である。ＩＳＰドメイン１９１は、インターネット接続サービス、電子メール・サービス、およびおそらくは他の電子商取引サービスを提供する、インターネット・サービス・プロバイダ（ＩＳＰ）とすることができる。別の方法として、ＩＳＰドメイン１９１は、ユーザ１９０が頻繁にアクセスするインターネット・ポータルとすることもできる。

同様に、ドメイン１９３、１９５、および１９７は、典型的なウェブ・サービス・プロバイダを表す。政府ドメイン１９３は、様々な政府関係トランザクションを完了するためにユーザを認証する、認証マネージャ１９４をサポートする。銀行業務ドメイン１９５は、オンライン・バンクでのトランザクションを完了するためにユーザを認証する、認証マネージャ１９６をサポートする。電子商取引ドメイン１９７は、オンライン購入を完了するためにユーザを認証する、認証マネージャ１９８をサポートする。

前述のように、ユーザが異なるドメインにあるリソースにアクセスすることによって、インターネットまたはワールド・ワイド・ウェブ内の１つのドメインから別のドメインに移動しようと試みる場合、ユーザは、ドメインのセットをまたがるユーザの進行を大幅に遅くする可能性のある、複数のユーザ認証要求または要件を受ける可能性がある。例示的環境として図５を使用すると、ユーザ１９０は、少なくとも１８歳であり、有効な運転免許証、有効なクレジット・カード、および米国の銀行口座を有するユーザに限定されたオンライン・サービスを、ユーザが購入しようと試みている、電子商取引ドメイン１９７との複雑なオンライン・トランザクションに関与する可能性がある。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７を含むことができる。

通常、ユーザは、典型的なオンライン・トランザクションに参加する各ドメイン内で、アイデンティティまたは属性あるいはその両方を維持する可能性はない。この例では、ユーザ１９０は自分のアイデンティティをユーザのＩＳＰに登録している可能性があるが、オンライン・トランザクションを完了するためには、ドメイン１９３、１９５、および１９７にも認証される必要がある可能性がある。各ドメインがユーザに関するアイデンティティを維持していない場合、ユーザのオンライン・トランザクションは失敗する可能性がある。たとえユーザが各ドメインによって認証可能な場合であっても、異なるドメインがユーザのトランザクションを完了するためにそれらの間で情報を転送できるという保証はない。

ここまで、いくつかの現行技術に関して簡単に説明したとすれば、残りの図面についての説明は、本発明が動作可能なフェデレーテッド・コンピュータ環境に関する。しかしながら、本発明について詳細に論じる前に、いくつかの用語を紹介する。

用語
「エンティティ」または「パーティ」という用語は一般に、組織、個人、あるいは組織、個人、または他のシステムに代わって動作するシステムを言い表す。「ドメイン」という用語は、ネットワーク環境内の追加の特徴を暗示するが、「エンティティ」、「パーティ」、および「ドメイン」という用語は、相互に交換可能に使用することができる。たとえば、「ドメイン」という用語は、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）ドメイン、またはより一般的には、外部エンティティに対して論理ユニットとして現れる様々なデバイスおよびアプリケーションを含む、データ処理システムも言い表すことが可能である。

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

トークンは、正常なオペレーションの直接的な証拠を提供し、たとえば正常な認証オペレーションの後に生成される認証トークンなど、オペレーションを実行するエンティティによって生成される。ケルベロス・トークンは、本発明で使用可能な認証トークンの一例である。ケルベロスに関する詳細は、１９９３年９月付の、Ｋｏｈｌ等による「The Kerberos Network Authentication Service(V5)」、Internet Engineering Task Force (IETF)Request for Comments (RFC) 1510で見つけることができる。

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

セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）アサーションは、本発明で使用できる可能なアサーション・フォーマットの一例である。ＳＡＭＬは、非営利の国際協会である、ｔｈｅ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ（ＯＡＳＩＳ）によって推奨されてきた。ＳＡＭＬについては、２００２年５月３１日付の「Assertions and Protocol for the OASIS Security Assertion MarkupLanguage (SAML)」、CommitteeSpecification 01に、以下のように記載されている。

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

ＳＡＭＬ仕様には、アサーションは、発行者によって作成された１つまたは複数のステートメントを供給する情報のパッケージであると記されている。ＳＡＭＬは、指定された対象が特定の時間に特定の手段によって認証された、認証と、指定された対象が指定されたリソースにアクセスできるようにとの要求が認められたかまたは拒否された、許可と、指定された対象が供給された属性に関連付けられる、属性との、３つの異なる種類のアサーション・ステートメントを発行者が作成できるようにする。以下で詳細に論じるように、必要であれば、様々なアサーション・フォーマットを他のアサーション・フォーマットに変換することができる。

認証は、ユーザによってまたはユーザに代わって提供される証明セットを妥当性検査するプロセスである。認証は、ユーザが知っている何か、ユーザが有する何か、またはユーザの存在である何か、すなわちユーザに関する何らかの物理的特徴、を検証することによって実施される。ユーザが知っている何かは、ユーザのパスワード、またはユーザの暗号鍵などの特定のユーザにのみ知られている何かを検証することによって、などの、共有秘密を含むことができる。ユーザが有する何かは、スマートカードまたはハードウェア・トークンを含むことができる。ユーザに関する何らかの物理的特徴は、指紋または網膜地図などの、バイオメトリック入力を含むことができる。

認証証明は、様々な認証プロトコルで使用されるチャレンジ／応答情報のセットである。たとえば、ユーザ名およびパスワードの組み合わせは、認証証明の最も良く知られた形である。認証証明の他の形は、様々な形のチャレンジ／応答情報、公開鍵インフラストラクチャ（ＰＫＩ）証明、スマートカード、バイオメトリックなどを含むことができる。認証証明は認証アサーションとは区別され、認証証明は、ユーザによって認証サーバまたはサービスを伴う認証プロトコル・シーケンスの一部として提示され、認証アサーションは、ユーザの認証証明の正常な提示および妥当性検査に関するステートメントであって、その後、必要な場合はエンティティ間で転送される。

本発明を組み込むことが可能なコンピューティング環境のためのフェデレーション・モデル
ワールド・ワイド・ウェブとの関連において、ユーザは、各特定ドメイン間の情報バリアをほとんど意識せずに、１つのインターネット・ドメイン上のアプリケーションとの対話から、別のドメイン上のアプリケーションへとジャンプできる機能を期待するようになっている。ユーザは、単一のトランザクションについて複数のドメインに対して認証しなければならないことによるフラストレーションを望まない。言い換えればユーザは、組織は相互協調処理（interoperate）するはずであると期待するが、ユーザは一般にドメインが自分たちのプライバシーを尊重することを望む。これらのユーザの期待は、多くの企業および組織が認証技法の競い合いを公表している、急速に発展中の異機種環境にある。

本発明は、企業がシングル・サインオン体験をユーザに提供できるようにする、フェデレーション・モデル内でサポートされる。言い換えれば、本発明はフェデレートされた異機種環境内で実施可能である。フェデレートされた異機種環境から恩恵を受けるトランザクションの一例として、再度図５を参照すると、ユーザ１９０はドメイン１９１に対して認証し、その後ドメイン１９１に、トランザクションに関与できる各ダウンストリーム・ドメインへの適切なアサーションを提供させることが可能である。これらのダウンストリーム・ドメインは、たとえドメイン１９１とこれらの他のダウンストリーム・ドメインとの間に事前に確立されたアサーション・フォーマットがなくとも、認証アサーションまたは他のタイプのアサーションあるいはその両方を理解および信頼できることが必要である。アサーションの認識に加えて、ダウンストリーム・ドメインは、たとえ関係をマッピングする事前に確立されたアイデンティティがなくとも、アサーション内に含まれるアイデンティティを、特定ドメイン内のユーザ１９０を表すアイデンティティに変換できることが必要である。ただし、本発明は様々なタイプのドメインに適用可能であり、図５内に例示的ドメインとして表されたＩＳＰタイプのドメインに限定されるものではないことに留意されたい。

本発明は、フェデレーテッド環境内でサポートされる。一般に、企業は独自のユーザ・レジストリを有し、独自のユーザ・セットとの関係を維持する。各企業は、通常、これらのユーザを認証する独自の手段を有する。しかしながら、本発明で使用するためのフェデレーテッド・スキームは、企業の企業フェデレーションへの参加を通じて、１企業内のユーザが企業セットとの関係を活用できるように、企業が集合的に協働できるようにするものである。ユーザは、あたかも各企業との直接的な関係を有するかのように、フェデレートされた企業のいずれかにあるリソースへのアクセスが認められる。ユーザは関心のあるそれぞれのビジネスに登録する必要がなく、ユーザは絶えず自分自身を識別および認証する必要がない。したがって、このフェデレーテッド環境では、認証スキームが、情報技術において急速に発展中の異機種環境におけるシングル・サインオン体験を可能にする。

本発明との関連において、フェデレーションとは、シングル・サインオンの使い易さの体験をユーザに提供するために協働する企業、組織、協会などの別個のエンティティのセットであり、フェデレーテッド環境は、２つの企業が、ユーザに関する何の情報をどのように転送するかを定義する、直接的な、事前に確立された関係を有する必要がないという点において、典型的なシングル・サインオン環境とは異なる。フェデレーテッド環境内で、エンティティは、ユーザの認証と、他のエンティティによって提示された認証トークンなどの認証アサーションの受け入れと、被保証（vouched-for）ユーザのアイデンティティの、ローカル・エンティティ内で理解されたアイデンティティへの何らかの形の変換の提供とに対処する、サービスを提供する。

フェデレーションは、サービス・プロバイダにかかる管理負担を軽減する。サービス・プロバイダは、概してフェデレーションに関してその信頼関係に依拠することが可能であり、サービス・プロバイダは、ユーザの認証ホーム・ドメインまたはアイデンティティ・プロバイダによって実施される認証に依拠することができるため、ユーザ・パスワード情報などの認証情報を管理する必要がない。

本発明をサポートするシステムは、緩やかに結合された認証、ユーザ加入（enrollment）、ユーザ・プロファイル管理、または許可サービス、あるいはそれらすべてが、セキュリティ・ドメインをまたがって連携（collaborate）する基盤を確立する、フェデレーテッド・アイデンティティ管理システムにも関係する。フェデレーテッド・アイデンティティ管理は、異種のセキュリティ・ドメイン内に常駐するサービスが、たとえこれらの異種ドメインの基礎となるセキュリティ・メカニズムおよびオペレーティング・システム・プラットフォーム内に相違点が存在する可能性があっても、セキュアに相互協調処理および連携できるようにするものである。

アイデンティティ・プロバイダ対サービス・プロバイダ
前述のように、および以下でより詳細に説明するように、フェデレーテッド環境はかなりのユーザ特典を提供する。フェデレーテッド環境により、ユーザは、第２のエンティティで使用するためにユーザに関する認証アサーションを発行するための発行パーティとして動作することが可能な、第１のエンティティでの認証が可能となる。その後ユーザは、第２のエンティティで明確に再認証する必要なしに、第１のエンティティによって発行された認証アサーションを提示することによって、依拠パーティと呼ばれる第２の別個のエンティティにある保護されたリソースにアクセスすることができる。発行パーティから依拠パーティに渡される情報はアサーションの形であり、このアサーションはステートメントの形の異なるタイプの情報を含むことができる。たとえばアサーションは、ユーザの認証済みアイデンティティに関するステートメントとするか、または特定のユーザに関連付けられたユーザ属性情報に関するステートメントとすることができる。

次に図６を参照すると、フェデレーテッド環境内のダウンストリーム・エンティティでのアクションを応答して呼び出す、第１のフェデレートされた企業に対してユーザによって開始されたトランザクションに関して、フェデレーテッド環境の用語を示すブロック図が示される。図６は、所与のフェデレーテッド・オペレーションについて、フェデレーション内のエンティティの見方によって用語が異なる場合のあることを示す。より具体的に言えば、図６は、本発明をサポートするコンピューティング環境が、信頼の推移性（transitivity）および認証アサーション・プロセスの推移性をサポートすることを示し、ドメインまたはエンティティは、他のドメインまたは他のエンティティによってアサートされたアイデンティティにおけるその信頼に基づいてアサーションを発行することができる。

ユーザ２０２は、企業２０４にある保護されたリソースに対する要求を通じて、トランザクションを開始する。ユーザ２０２が企業２０４によって認証されているか、またはトランザクション中に企業２０４によって最終的に認証されることになる場合、企業２０４は、このフェデレーテッド・セッションに関するユーザのホーム・ドメインと呼ぶことができる。トランザクションが企業２０６による何らかのタイプのオペレーションを必要とし、企業２０４が企業２０６にアサーションを転送すると想定すると、企業２０４は特定のオペレーションに関して発行エンティティであり、企業２０６はそのオペレーションに関して依拠エンティティである。

発行エンティティは、依拠ドメインが使用するためのアサーションを発行し、発行エンティティは通常、ユーザのホーム・ドメインまたはユーザのアイデンティティ・プロバイダであるが、必ずしもそうとは限らない。したがって、発行パーティは通常、典型的な認証オペレーションを使用してユーザを認証していることになる。しかしながら、発行パーティは以前に依拠パーティとして動作し、それによって、異なる発行パーティからアサーションを受け取った可能性がある。言い換えれば、ユーザ開始トランザクションは、フェデレーテッド環境内の一連の企業を通じてカスケード（cascade）できるため、受け取りパーティはその後、ダウンストリーム・トランザクションに関する発行パーティとして動作することができる。一般に、ユーザに代わって認証アサーションを発行できるエンティティは、いずれも発行エンティティとして動作することができる。

依拠エンティティは、発行エンティティからアサーションを受け取るエンティティである。依拠パーティは、ユーザ、すなわち発行エンティティに代わってサード・パーティによって発行されたアサーションを受け入れ、信頼し、および理解することが可能であり、一般に、依拠エンティティの義務は、認証アサーションを解釈するために適切な認証権限を使用することである。依拠パーティとは、ユーザまたは他のエンティティに代わって提示されたアサーションに依拠するエンティティである。この場合、ユーザは、ユーザとの対話セッションの一部として、ユーザの認証証明についてユーザにプロンプトを出すよう依拠エンティティに要求する代わりに、依拠エンティティでシングル・サインオン体験をすることができる。

再度図６を参照すると、トランザクションが、企業２０６が企業２０８にアサーションを転送するようなオペレーションをさらに必要とすると想定した場合、企業２０６は、後続のまたは２次トランザクション・オペレーションに関して発行エンティティとして動作する、アップストリーム・エンティティであり、企業２０８は、このオペレーションについて依拠エンティティとして動作するダウンストリーム・エンティティであって、この場合、後続のトランザクションを２つのエンティティのみに関して記述することも可能であるが、企業２０８はオリジナル・トランザクションに関して別のダウンストリーム・エンティティとみなすことができる。

図６に示されるように、フェデレーテッド・エンティティは、フェデレーテッド・ユーザに関するアイデンティティ情報および属性情報を提供する、ユーザのホーム・ドメインとして動作可能である。アイデンティティ情報、アイデンティティまたは認証アサーション、あるいはアイデンティティ・サービスを提供する、フェデレーテッド・コンピューティング環境内のエンティティは、アイデンティティ・プロバイダと呼ぶことができる。同じフェデレーション内の他のエンティティまたはフェデレーション・パートナは、たとえば、ユーザのアイデンティティ・プロバイダによって提供されるシングル・サインオン・トークンの受け入れなどの、ユーザの認証証明の１次管理について、アイデンティティ・プロバイダに依拠することが可能であり、ユーザが認証するドメインをユーザの（認証）ホーム・ドメインと呼ぶことができる。アイデンティティ・プロバイダは、ユーザの雇用者、ユーザのＩＳＰ、または何らかの他の商業エンティティによって、物理的にサポートされることが可能である。

アイデンティティ・プロバイダとは、アイデンティティ情報を、フェデレーテッド・コンピューティング環境内の他のエンティティにサービスとして提供する、特定タイプのサービスである。ほとんどのフェデレーテッド・トランザクションに関して、認証アサーションに関する発行パーティは、通常アイデンティティ・プロバイダとなり、任意の他のエンティティがあれば、アイデンティティ・プロバイダと区別することができる。フェデレーテッド・コンピューティング環境内でサービスを提供する任意の他のエンティティは、サービス・プロバイダとして分類することができる。あるユーザがアイデンティティ・プロバイダに対して認証されると、所与のフェデレーテッド・セッションまたは所与のフェデレーテッド・トランザクションの持続期間中、フェデレーション内の他のエンティティまたは企業は単にサービス・プロバイダとみなすことができる。

いくつかの状況では、フェデレーテッド環境内にユーザに対するアイデンティティ・プロバイダとして動作可能な複数のエンティティが存在する場合がある。たとえば、ユーザは、それぞれがユーザに対するアイデンティティ・プロバイダとして動作可能な複数のフェデレーテッド・ドメインのアカウントを有する場合があり、これらのドメインは必ずしも他のドメインに関する情報、または異なるドメインにいるユーザのアイデンティティに関する情報を有するとは限らない。

たとえば、ユーザの認証証明などを生成および妥当性検査する機能を有する複数の企業が存在可能であるために、フェデレーテッド環境内にアイデンティティ・プロバイダとして動作可能な複数の企業が存在できる可能性はあるが、フェデレーテッド・トランザクションは、通常、単一のアイデンティティ・プロバイダのみを含む。たとえば、ユーザがフェデレートされた加入または登録オペレーションを実行する際に使用したエンティティがフェデレーション内に１つしか存在しないために、ユーザを認証できるフェデレーテッド・エンティティが１つしかない場合、フェデレーテッド環境全体を通じてユーザのトランザクションをサポートするために、このエンティティがユーザのアイデンティティ・プロバイダとして動作することになると予測される。

複数のサービス・プロバイダの相互協調処理を必要とするいくつかのフェデレーテッド・トランザクションでは、ダウンストリーム・サービス・プロバイダがアップストリーム・サービス・プロバイダからアサーションを受け入れることが可能であり、アップストリーム・サービス・プロバイダが、依拠パーティとして動作しているダウンストリーム・サービス・プロバイダに対する発行エンティティとして動作可能な条件は、サービス・プロバイダ間の信頼関係のタイプ、およびサービス・プロバイダ間のトランザクションのタイプによって異なる可能性がある。しかしながら、単純なフェデレーテッド・トランザクションの範囲内には、発行エンティティとして動作するエンティティが１つしかない。

本発明は、既存の非フェデレーテッド・アーキテクチャに与える影響を最小限にしながら、フェデレーテッド・インフラストラクチャを既存のシステムに追加することができる所与のコンピューティング環境内でサポート可能である。したがって、任意の所与の企業またはサービス・プロバイダでの認証オペレーションを含むオペレーションは、エンティティがフェデレーテッド環境にも参加可能であるという事実によって、必ずしも変更されるとは限らない。言い換えれば、たとえエンティティのコンピューティング・システムがフェデレーテッド環境に統合可能であっても、ユーザは、認証オペレーションを含む企業と直接の様々なオペレーションの実行を、非フェデレーテッド様式で継続することができる可能性がある。しかしながら、ユーザは、ユーザが非フェデレーテッド様式で所与のエンティティとの同様のオペレーションを実行したかのように、所与のエンティティに関してフェデレーテッド・オペレーションを実行しながら、同じエンドユーザ体験ができる可能性がある。したがって、所与の企業がフェデレーションに参加する場合に、所与の企業のすべてのユーザが、必ずしもフェデレーテッド・トランザクションに参加するとは限らず、企業の一部のユーザは、任意のフェデレーテッド・トランザクションを実行することなく企業のコンピューティング・システムと対話可能であることに留意されたい。

さらに、たとえばコンピュータ・システムにおけるユーザ・アカウントの確立などの、所与の企業のコンピューティング環境内でのユーザ登録は、企業がフェデレーテッド環境にも参加可能であるという事実によって、必ずしも変更されるとは限らない。たとえばユーザは、フェデレーテッド環境から独立したレガシー（legacy）または既存の登録プロセスを介して、依然としてドメインでアカウントを確立することができる。したがって、いくつかのケースでは、企業でのユーザ・アカウントの確立は、企業がフェデレーテッド・コンピューティング環境に参加する場合、フェデレーションにまたがって有効なアカウント情報の確立を含む場合と含まない場合とがある。

フェデレーテッド・アーキテクチャ――レガシー・システムに対するフェデレーション・フロントエンド
次に図７を参照すると、本発明の実施形態をサポートするために使用可能ないくつかのフェデレーテッド・アーキテクチャ構成要素を備えた、所与のドメインでの既存のデータ処理システムの統合を示すブロック図が示される。フェデレーテッド環境は、ユーザに様々なサービスを提供するフェデレーテッド・エンティティを含む。ユーザ３１２は、ブラウザ・アプリケーション３１６および様々な他のクライアント・アプリケーション３１８をサポート可能な、クライアント・デバイス３１４と対話する。ユーザ３１２は、クライアント・デバイス３１４、ブラウザ３１６、または、ユーザと他のデバイスおよびサービスとの間のインターフェースとして動作する任意の他のソフトウェアとは区別される。いくつかのケースでは、以下の説明で、クライアント・アプリケーション内で明確に動作しているユーザと、ユーザに代わって動作しているクライアント・アプリケーションとを区別することができる。しかしながら一般に要求者は、ユーザの代わりに動作することが推測可能な、クライアント・ベース・アプリケーション、ブラウザ、ＳＯＡＰクライアントなどの仲介者である。

ブラウザ・アプリケーション３１６は、ＨＴＴＰ通信構成要素３２０およびマークアップ言語（ＭＬ）インタプリタ３２２などの多くのモジュールを備える、移動デバイスに見られるブラウザを含む、典型的なブラウザとすることができる。ブラウザ・アプリケーション３１６は、ウェブ・サービス・クライアント３２４などのプラグイン、または、仮想マシン・ランタイム環境を必要とする場合と必要としない場合があるダウンロード可能アプレット、あるいはその両方をサポートすることもできる。ウェブ・サービス・クライアント３２４は、非集中分散環境における構造化およびタイプ別情報の交換を定義するための軽量プロトコルである、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）を使用することができる。ＳＯＡＰは、メッセージに含まれる内容およびその処理の方法を記述するためのフレームワークを定義するエンベロープと、アプリケーション定義データタイプのインスタンスを表現するための符号化規則セットと、リモート・プロシージャの呼び出しおよび応答を表すための規則との、３つの部分からなるＸＭＬベース・プロトコルである。ユーザ３１２は、ブラウザ・アプリケーション３１６を使用してウェブ・ベースのサービスにアクセスすることができるが、ユーザ３１２は、クライアント・デバイス３１４上の他のウェブ・サービス・クライアントを介してウェブ・サービスにアクセスすることもできる。いくつかのフェデレーテッド・オペレーションは、フェデレーテッド環境内のエンティティ間で情報を交換するために、ユーザのブラウザを介したＨＴＴＰリダイレクトを採用することができる。しかしながら、本発明は、様々な通信プロトコルを介してサポート可能であり、ＨＴＴＰベースの通信に限定されるものではないことに留意されたい。たとえばフェデレーテッド環境内のエンティティは、必要な場合直接通信可能であり、メッセージはユーザのブラウザを介してリダイレクトされなくてもよい。

本発明は、フェデレーテッド環境に必要な構成要素を既存のシステムと統合できるようにサポートすることができる。図７は、フロントエンド対既存システム（a front-end to a pre-existing system）としてこれらの構成要素を実装するための一実施形態を示す。フェデレーテッド・ドメインの既存の構成要素は、図８に示されるのと同様に認証サービス・ランタイム（ＡＳＲ）サーバ３３２を含む、レガシー・アプリケーションまたはバックエンド処理構成要素３３０とみなすことができる。ＡＳＲサーバ３３２は、保護されたリソース３３５を生成、取り出し、あるいはそれ以外の方法でのサポートまたは処理を行うためとみなすことが可能な、アプリケーション・サーバ３３４へのアクセスをドメインが制御する場合に、ユーザを認証する責務を負う。ドメインは、アプリケーション・サーバ３３４にアクセスするためにユーザを登録するための、レガシー・ユーザ登録アプリケーション３３６の使用を続行することができる。レガシー・オペレーションに関して登録済みユーザの認証に必要な情報は、企業ユーザ・レジストリ３３８に格納され、企業ユーザ・レジストリ３３８にはフェデレーション構成要素もアクセス可能である。

フェデレーテッド環境に加わった後、ドメインは、フェデレーテッド構成要素の介入無しに動作を続行することができる。言い換えれば、ドメインは、接点（point-of-contact）サーバまたはこの接点サーバの機能を実施する他の構成要素を通過することなく、ユーザが特定のアプリケーション・サーバまたは他の保護されたリソースへの直接のアクセスを続行できるように、構成可能であり、このようにシステムにアクセスするユーザは、典型的な認証フローおよび典型的なアクセスを体験することになる。しかしながら、このように実施する場合、レガシー・システムに直接アクセスするユーザは、ドメインの接点サーバに知られたフェデレーテッド・セッションを確立できないことになる。

ドメインのレガシー機能は、接点サーバ３４２と、それ自体がセキュリティ・トークン・サービス（ＳＴＳ）３４６と対話する信頼プロキシ・サーバ３４４（より簡単には信頼プロキシ３４４または信頼サービス３４４）とを含む、フェデレーション・フロントエンド処理３４０を通じて、フェデレーテッド環境に統合することが可能であり、これらについては図８に関して以下でより詳細に説明する。フェデレーション構成アプリケーション３４８は、フェデレーション・インターフェース・ユニット３５０を介してレガシー・バックエンド構成要素と対話できるようにするために、管理ユーザがフェデレーション・フロントエンド構成要素を構成できるようにするものである。フェデレーテッド機能は、別個のシステム構成要素またはモジュール内で実施可能である。好ましい実施形態では、フェデレーション・オペレーションを実行するための機能のほとんどが、単一のフェデレーション・アプリケーション内の論理構成要素の集合によって実施可能であり、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーション３５２は、シングル・サインオン・プロトコル・サービス（ＳＰＳ）３５４と共に信頼サービス３４４を含む。信頼サービス３４４は、フェデレーション機能の一部としてアイデンティティ・マッピング・オペレーション、属性取り出しなどの責務を負う、アイデンティティおよび属性サービス（Ｉ＆ＡＳ）３５６を備えることができる。アイデンティティおよび属性サービス３５６は、シングル・サインオン・オペレーション中にシングル・サインオン・プロトコル・サービス３５４にも採用される可能性がある。フェデレーション・ユーザ・レジスタ３５８は、フェデレーション特有の目的でユーザ関連情報を維持するために、ある状況で採用される可能性がある。

所与の企業でのレガシーまたは既存の認証サービスは、ユーザ名／パスワードまたはスマートカード・トークンベース情報などの、様々な、周知の、認証方法またはトークンを使用することができる。しかしながら、本発明をサポートするための好ましいフェデレーテッド・コンピューティング・システムでは、接点サーバを使用することによって、レガシー認証サービスの機能をフェデレーテッド環境で使用することができる。ユーザは、接点サーバを通過することなく、レガシー認証サーバへの直接のアクセスを続行することができるが、このようにシステムにアクセスするユーザは、典型的な認証フローおよび典型的なアクセスを体験することになり、レガシー認証システムに直接アクセスするユーザは、本発明に従ったアイデンティティの証明としてフェデレーテッド認証アサーションを生成できないことになる。フェデレーション・フロントエンドの役割の１つは、接点サーバで受け取ったフェデレーテッド認証トークンを、レガシー認証サービスによって理解されるフォーマットに変換することである。したがって、接点サーバを介してフェデレーテッド環境にアクセスするユーザは、必ずしもレガシー認証サービスに対して再認証する必要がないことになる。好ましくは、ユーザは、接点サーバと信頼プロキシとの組み合わせによって、あたかもユーザが認証ダイアログに関与していたかのように見えるように、レガシー認証サービスに対して認証されることになる。

フェデレーテッド・アーキテクチャ――接点サーバ、信頼プロキシ、および信頼ブローカ
次に図８を参照すると、本発明の実施をサポートするための信頼関係を確立するために、フェデレーテッド・アーキテクチャ内のいくつかの構成要素が使用可能な一例を示す、ブロック図が示される。フェデレーテッド環境は、フェデレーテッド企業または様々なサービスをユーザに提供する同様のエンティティを含む。ユーザは、クライアント・デバイス上のアプリケーションを介して、企業４１０などの様々なエンティティのリソースにアクセスを試みることができる。企業４１０の接点（ＰＯＣ）サーバ４１２などの各フェデレーテッド企業の接点サーバは、企業４１０によってサポートされ利用可能となったリソースにアクセスするための、クライアントからの要求に対するフェデレーテッド環境への入口点である。接点サーバが多くのフェデレーション要件を処理するため、接点サーバは、たとえばレガシー・システムなどの既存の非フェデレーテッド・アーキテクチャ内での、既存の構成要素への影響を最小限にする。接点サーバは、セッション管理、プロトコル変換を提供し、場合によっては認証または属性アサーション変換あるいはその両方を開始する。たとえば接点サーバは、ＨＴＴＰまたはＨＴＴＰＳメッセージをＳＯＡＰに変換すること、およびその逆が可能である。以下でより詳細に説明するように、接点サーバは、アサーションを変換するための信頼プロキシの呼び出しにも使用することが可能であり、たとえば、発行パーティから受け取ったＳＡＭＬトークンを受け取りパーティによって理解されるケルベロス・トークンに変換することができる。

企業４１０の信頼プロキシ（ＴＰ）４１４などの信頼サービス（信頼プロキシ、信頼プロキシ・サーバ、または信頼サービスとも呼ばれる）は、フェデレーション内の２つのエンティティ間の信頼関係を確立および維持する。信頼サービスは、一般に、（以下でより詳細に説明するセキュリティ・トークン・サービスを介した）発行パーティによって使用されるフォーマットから受け取りパーティによって理解されるフォーマットへの、認証トークン・フォーマット変換を処理するための機能を有する。

接点サーバおよび信頼サービスをまとめて使用することで、既存の非フェデレーテッド・システム・セット上にフェデレーテッド・アーキテクチャを実装する影響が最小限になる。したがって、例示的なフェデレーテッド・アーキテクチャは、エンティティが企業、ドメイン、あるいは他の論理または物理エンティティのいずれであっても、１フェデレーテッド・エンティティにつき、少なくとも１つの接点サーバおよび少なくとも１つの信頼サービスでの実装を必要とする。しかしながら例示的フェデレーテッド・アーキテクチャは、必ずしも既存の非フェデレーテッド・システム・セットへの変更を必要とするとは限らない。好ましくは、所与のフェデレーテッド・エンティティに対して単一の信頼サービスが存在するが、可用性の目的で、信頼サービス構成要素の複数のインスタンスが存在可能であるか、または、たとえばある企業内の別々の子会社などの、フェデレーテッド・エンティティ内の様々なより小規模なエンティティに対して複数の信頼サービスが存在可能である。所与のエンティティが複数のフェデレーションに属することが可能であるが、単一の信頼サービスが複数のフェデレーション内の信頼関係を管理できる場合、このシナリオは必ずしも複数の信頼サービスを必要としないことになる。

信頼サービスの役割の１つは、他のドメインまたはそのドメイン内の信頼サービスあるいはその両方によって、必要なトークン・タイプを決定すること、または決定する責務を負うことである。信頼サービスは、発行パーティによって使用されるフォーマットから、受け取りパーティによって理解されるフォーマットへの、認証トークン・フォーマット変換を処理する機能または責務を有する。信頼サービス４１４は、企業４１０に対して発生する任意のユーザ・アイデンティティ変換または属性変換に対する責務も負うことができるか、あるいは、この責務を、たとえば図７に示されたアイデンティティおよび属性サービス３５６などの、別個のアイデンティティおよび属性サービスによってサポートすることもできる。加えて信頼サービスは、ユーザの実世界のアイデンティティに関するいかなる追加の情報も提供することなく、ユーザを固有に識別する、ユーザ・アイデンティティの代表としての別名の実施もサポートすることができる。さらに信頼プロキシは、接点サーバが使用するための許可またはセッション証明あるいはその両方を発行することもできる。しかしながら信頼サービスは、以下でさらに説明するように、アシスタンス用の信頼ブローカを呼び出すことができる。発行パーティに知られているユーザのアイデンティティおよび属性を、受け取りパーティにとって有意なアイデンティティおよび属性にマッピングするために、アイデンティティ変換が必要な場合がある。この変換は、発行エンティティの信頼サービス、受け取りエンティティの信頼サービス、またはその両方の、いずれかによって、呼び出すことができる。

信頼サービス４１４、または前述のような別個のアイデンティティおよび属性サービスは、セキュリティ・トークン・サービス（ＳＴＳ）構成要素４１６として示される、内在的構成要素を含む（またはこれと対話する）ことが可能であり、これが、トークン変換を提供し、トークンの妥当性検査および生成のために認証サービス・ランタイム（ＡＳＲ）４１８を呼び出すことになる。セキュリティ・トークン・サービスは、アイデンティティ変換を含むことができる、信頼サービスが必要とするトークン発行および妥当性検査サービスを提供する。したがってセキュリティ・トークン・サービスは、既存の認証サービス・ランタイムへのインターフェースを含むか、または認証サービス・ランタイムをサービス自体に組み込む。信頼サービスに内在する代わりに、セキュリティ・トークン・サービス構成要素は、たとえば信頼サービスによって呼び出されることになるスタンドアロン型構成要素として実施することも可能であるか、または、たとえばアプリケーション・サーバの一部として、トランザクション・サーバ内に内在することができる。

たとえば、セキュリティ・トークン・サービス構成要素は、ケルベロス・トークンを発行するための要求を受け取ることができる。トークンの作成先であるユーザの認証情報の一部として、要求は、ユーザ名およびパスワードを含むバイナリ・トークンを含むことができる。セキュリティ・トークン・サービス構成要素は、ユーザ名およびパスワードを、たとえばＬＤＡＰランタイム（典型的な認証）に照らして妥当性検査し、このユーザに対するケルベロス・チケットを生成するためにケルベロスＫＤＣ（Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ）を呼び出すことになる。このトークンは企業内で使用するために信頼サービスに戻されるが、これの使用には、フェデレーション内の他のドメインへの転送のためにトークンを外在化することが含まれる場合がある。

図４で説明した方法と同様に、ユーザは、企業４１０および企業４２０の両方などの、フェデレーテッド環境内の複数の企業にあるリソースへのアクセスを希望する場合がある。企業４１０について上記で説明した方法と同様に、企業４２０は接点サーバ４２２、信頼サービス４２４、セキュリティ・トークン・サービス（ＳＴＳ）４２６、および認証サービス・ランタイム４２８を備える。ユーザは各企業との別々のトランザクションを直接開始することができるが、ユーザはフェデレーテッド環境全体にわたってカスケードする、企業４１０とのトランザクションを開始することができる。企業４１０は、ユーザがトランザクションを開始した際に、たとえユーザがこの必要性に気づいていない可能性があっても、特定のトランザクションを完了するために、企業４２０などのフェデレーテッド環境内の複数の他の企業との連携を必要とする可能性がある。企業４２０はダウンストリーム・エンティティとして関与するようになり、企業４１０は、ユーザのフェデレーテッド・トランザクションを進めるために必要であれば、企業４２０に対してアサーションを提示することができる。

信頼サービスが、関連付けられた接点サーバによって受け取られる認証トークンをどのように解釈するか、または、所与のユーザ・アイデンティティおよび属性をどのように変換するか、あるいはその両方が、わからないという場合もある。このケースでは、信頼サービスは、信頼ブローカ４３０などの信頼ブローカ構成要素での機能を呼び出すように選択することができる。信頼ブローカは個々の信頼プロキシ／サービスとの関係を維持し、それによって信頼サービス間に推移的信頼を提供する。信頼ブローカを使用することによって、企業４１０および４２０などのフェデレーテッド環境内の各エンティティは、フェデレーテッド環境内の各エンティティと複数の個々の信頼関係を確立するのではなく、信頼ブローカとの信頼関係を確立することができる。たとえば、企業４２０が企業４１０のユーザによって開始されたトランザクションに対するダウンストリーム・エンティティとして関与するようになった場合、企業４１０の信頼サービス４１４は、企業４２０の信頼サービス４２４が、必要であれば信頼ブローカ４３０でアシスタンスを呼び出すことによって、信頼サービス４１４からのアサーションを理解できることが保証される。図８は、単一の信頼ブローカを備えたフェデレーテッド環境を示すが、フェデレーテッド環境は複数の信頼ブローカを有することができる。

図８は、接点サーバ４１２、信頼サービス４１４、セキュリティ・トークン・サービス構成要素４１６、および認証サービス・ランタイム４１８を別個のエンティティとして示すが、これらの構成要素は必ずしも別々の構成要素上に実装される必要のないことに留意されたい。たとえば、これら別々の構成要素の機能は、単一のアプリケーションとして、単一の物理デバイス上のアプリケーションとして、または複数の物理デバイス上の分散アプリケーションとして、実施されることが可能である。加えて図８は、１企業について単一の接点サーバ、単一の信頼サービス、および単一のセキュリティ・トークン・サーバを示すが、代替の構成は、各企業について複数の接点サーバ、複数の信頼サービス、および複数のセキュリティ・トークン・サーバを含むことができる。接点サーバ、信頼サービス、セキュリティ・トークン・サービス、および他のフェデレーテッド・エンティティは、ソフトウェア・アプリケーション、オブジェクト、モジュール、ソフトウェア・ライブラリなどの、様々な形で実施可能である。

信頼サービス／ＳＴＳは、ユーザ名およびパスワードの組み合わせおよびケルベロス・チケットなどの従来の証明を含む、多くの異なる認証証明、ならびに、サード・パーティによって生成される認証トークンを含むフェデレーテッド認証トークン・フォーマット、の受け入れおよび妥当性検査が可能な場合がある。信頼サービス／ＳＴＳは、他の場所での認証の証明として認証トークンの受け入れが可能な場合がある。認証トークンは発行パーティによって生成され、ユーザがすでにその発行パーティに認証されていることを示すために使用される。発行パーティは、ユーザの認証済みアイデンティティをアサートする手段として、認証トークンを生成する。信頼サービス／ＳＴＳは、属性トークン、あるいは、たとえばＳＳＬセッション識別子と同様にセッション情報を管理するために使用されるトークンなどの、通信セッションまたは会話をセキュアにするために使用されるトークンを、処理することもできる。

セキュリティ・トークン・サービスは、必要に応じて認証サービス・ランタイムを呼び出す。認証サービス・ランタイムは、ユーザを認証できる認証サービスをサポートする。認証サービスは、認証応答を介して成功または失敗した認証試行のインジケーションを提供する認証権限として動作する。信頼サービス／ＳＴＳは、たとえば、既存のレガシー・インフラストラクチャと対話する必要のない、ウェブ・サービスの最新インストールが存在するシナリオなど、認証サービスを内在化することができる。それ以外の方法では、認証トークンの妥当性検査のために、セキュリティ・トークン・サービス構成要素が外部認証サービスを呼び出すことになる。たとえば、セキュリティ・トークン・サービス構成要素は、ユーザ名／パスワードを含むバイナリ・トークンを「アンパック」し、その後ＬＤＡＰサービスを使用してユーザ・レジストリにアクセスし、提示された証明を妥当性検査することができる。

アプリケーション・サーバなどの他の構成要素によって使用される場合、セキュリティ・トークン・サービス構成要素を使用して、レガシー認証システムへのシングル・サインオンに必要なトークンを生成することが可能であり、この機能は、図７に示されたＳＰＳ ３５４などのシングル・サインオン・プロトコル・サービス内の機能と組み合わせるか、またはこれに置き換えることができる。したがって、セキュリティ・トークン・サービス構成要素は内部用、すなわち企業内の、および外部用、すなわちフェデレーション内の企業をまたがった、トークン変換に使用することができる。内部用の一例として、ウェブ・アプリケーション・サーバは、ＩＢＭ ＣＩＣＳ（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）トランザクション・ゲートウェイを介してメインフレームにインターフェースすることが可能であり、ＣＩＣＳとは、主幹業務アプリケーションに企業レベルのオンライン・トランザクション管理および接続性を提供する、アプリケーション・サーバおよびコネクタのファミリである。ウェブ・アプリケーション・サーバは、ケルベロス・チケット（ウェブ・アプリケーション・サーバによって内部的に使用される）を、ＣＩＣＳトランザクション・ゲートウェイが必要とするＩＢＭ ＲＡＣＦパスチケットに変換するために、セキュリティ・トークン・サービス構成要素を呼び出すことができる。（ＩＢＭ、ＲＡＣＦ、およびＣＩＣＳは、インターナショナル・ビジネス・マシンズ・コーポレーションの登録商標である。）

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

サービス・プロバイダの信頼サービスがアイデンティティ・プロバイダから認証アサーションを受け取った場合、信頼サービスは、どのタイプのアサーションを期待したか、および、サービス・プロバイダ内で内部用に使用するためにどのタイプのアサーションが必要であるかがわかる。したがってサービス・プロバイダの信頼サービスは、セキュリティ・トークン・サービスに、受け取った認証アサーション内のトークンに基づいて必要な内部使用のトークンを生成するように要求する。

信頼サービスおよび信頼ブローカはどちらも、アイデンティティ・プロバイダから受け取ったアサーションを、サービス・プロバイダによって理解されるフォーマットに変換するための機能を有する。信頼ブローカは、直接の信頼関係があるそれぞれの信頼サービスに関するアサーション・フォーマットを解釈するための機能を有し、それによって信頼ブローカは、アイデンティティ・プロバイダとサービス・プロバイダとの間のアサーション変換を提供することができる。この変換は、いずれかのパーティによって、そのローカル信頼サービスを介して要求することができる。したがって、アイデンティティ・プロバイダの信頼サービスは、アサーションがサービス・プロバイダに送信される前にその変換を要求することができる。同様に、サービス・プロバイダの信頼サービスは、アイデンティティ・プロバイダから受け取ったアサーションの変換を要求することができる。

アサーション変換は、ユーザ・アイデンティティ変換、認証アサーション変換、属性アサーション変換、または他の形のアサーション変換を含む。前述のポイントを繰り返すと、アサーション変換は、たとえば信頼サービスおよび信頼ブローカなどのフェデレーション内の信頼構成要素によって処理される。信頼サービスは、アイデンティティ・プロバイダまたはサービス・プロバイダのいずれかで、ローカルに変換を実行することが可能であるか、または信頼サービスは信頼ブローカからアシスタンスを呼び出すことができる。

アイデンティティ・プロバイダおよびサービス・プロバイダがすでに信頼ブローカとの個々の信頼関係を有すると想定すると、信頼ブローカは、必要であれば発行パーティと依拠パーティとの間の新しい信頼関係を動的に作成、すなわちブローカリング、することができる。信頼ブローカによって提供された初期の信頼関係ブローカリング・オペレーションの後、アイデンティティ・プロバイダおよびサービス・プロバイダは、その関係を直接維持することができるため、その後の変換要件のために信頼ブローカを呼び出す必要はない。認証トークンの変換は、アイデンティティ・プロバイダの信頼サービス、サービス・プロバイダの信頼サービス、および信頼ブローカという、３つの可能な場所で実施できることに留意されたい。好ましくは、アイデンティティ・プロバイダの信頼サービスは、サービス・プロバイダに送信することが信頼ブローカによって理解される認証アサーションを生成する。その後サービス・プロバイダは、このトークンのサービス・プロバイダによって認識可能なフォーマットへの変換を信頼ブローカに要求する。トークン変換は、認証アサーションの伝送前、伝送後、または伝送の前後両方に実行することができる。

フェデレーテッド・アーキテクチャ内の信頼関係
本発明をサポートできる例示的フェデレーテッド環境内には、企業信頼ドメインおよびフェデレーション信頼ドメインという、管理しなければならない２つのタイプの「信頼ドメイン」がある。これら２つのタイプの信頼ドメインの相違点の一部は、信頼ドメインとの信頼関係および信頼を確立するために使用される技術を規定する業務契約に基づく。企業信頼ドメインは、企業によって管理されるそれらの構成要素を含み、その信頼ドメイン内のすべての構成要素は、暗黙的に互いに信頼し合うことができる。一般に、たとえば、構成要素間で相互に認証し合ったＳＳＬセッションを要求することによって、または、物理制御および隣接性が暗黙の信頼を立証するように単一の緊密に制御されたデータ・センタ内に構成要素を配置することによって、展開される技術が企業内に固有の信頼を作成するため、企業内で信頼を確立するために業務契約は必要でない。図７を参照すると、レガシー・アプリケーションおよびバックエンド処理システムは、構成要素がセキュアな内部ネットワーク上で通信する、企業信頼ドメインを表すことができる。

フェデレーション信頼ドメインは企業境界を横切るものであり、ある観点からすれば、フェデレーション信頼ドメインは別個の企業信頼ドメイン間の信頼関係を表すことができる。フェデレーション信頼ドメインは、フェデレーション・パートナ間の企業境界を横切る信頼プロキシを通じて確立される。信頼関係には、信頼プロキシ間での初期の信頼確立に使用される何らかのブートストラッピング・プロセスが含まれる。このブートストラップ・プロセスの一部は、予期されたかまたは許可された、あるいはその両方のトークン・タイプおよび識別子変換を定義する、共有秘密鍵および規則の確立を含むことができる。一般に、このブートストラッピング・プロセスは、このプロセスが、フェデレーションへの企業の参加とこの参加に関連付けられた賠償責任とを規定する業務契約の確立を含む場合もあるため、帯域外で実施することができる。

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

たとえば、大会社は世界中の数千もの顧客とのリンクを望む場合があり、その会社は非フェデレーテッド・ソリューションを使用することが可能であった。第１の例として、会社は世界中の顧客に商取引証明機関からのデジタル証明を使用して、相互の信用を確立するように要求することが可能であった。商取引証明機関によって、会社のサーバは、世界中のそれぞれの顧客に配置されたサーバを信用することができる。第２の例として、会社は、ケルベロスを使用してサード・パーティの信頼を実施することが可能であり、会社およびその世界中の顧客は、共有秘密ベースの信頼を実施する信頼されるサード・パーティのケルベロス・ドメイン・サービスを実施することが可能であった。第３の例として、会社は、その世界中の顧客のサーバによって相互に信頼される専有セキュリティ・メッセージ・トークンを備えた専用スキームを確立することが可能であった。

これらの手法のいずれも、会社が世界中の顧客のうちの少数のみとの信頼関係を管理すればよい場合には受け入れ可能であるが、何百何千という潜在的なフェデレーション・パートナが存在する場合は、管理不能となる可能性がある。たとえば、会社にとってはその小規模なパートナに対して専用スキームを実施させることはできる可能性があるが、会社がその大規模なパートナに多くの要件を課すことができることになる見込みはない。

企業は、信頼プロキシおよび場合によっては信頼ブローカを通じて確立および維持される、信頼関係を採用することができる。図面に示された例示的なフェデレーテッド・アーキテクチャの利点は、企業の現在のインフラストラクチャおよびその潜在的なフェデレーション・パートナ以上に、追加の要件を課さないことである。

しかしながら、この例示的フェデレーション・アーキテクチャは、企業およびその潜在的なフェデレーション・パートナを、フェデレーションに参加するために必要な業務および賠償責任契約を確立するために必要な予備作業から解放することはない。加えて、参加者は、信頼関係の技術的なブートストラッピングを無視することはできない。例示的なフェデレーション・アーキテクチャは、たとえば、第１のフェデレーション・パートナはある種の情報を備えたケルベロス・チケットを発行可能であり、第２のフェデレーション・パートナはある種の情報を備えたＳＡＭＬ認証アサーションを発行可能であるというように、このブートストラッピングをフレキシブルにすることができる。

例示的フェデレーション・アーキテクチャでは、２つの信頼プロキシ間で事前に確立された関係に基づいてアイデンティティ・プロバイダから受け取られたトークンを妥当性評価および変換する、セキュリティ・トークン・サービスを含む（またはこれと対話する）ことが可能な、信頼プロキシによって、信頼関係が管理される。他のフェデレーテッド企業との信頼関係（およびトークン変換）を確立することがフェデレーテッド企業にとって実行不可能な状況では、信頼ブローカを呼び出すことができるが、フェデレーテッド企業は信頼ブローカとの関係を確立する必要はない。

次に図９を参照すると、本発明をサポート可能な例示的フェデレーテッド・アーキテクチャに従った、信頼プロキシおよび信頼ブローカを使用するフェデレーテッド・ドメイン間の信頼関係の例示的セットを示す、ブロック図が示される。図８では信頼ブローカを紹介したが、図９では例示的フェデレーテッド・アーキテクチャ内の推移的信頼関係の重要性を示す。

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

フェデレーテッド企業間の信頼関係に関して契約上の義務および賠償責任を指定する業務契約は、ｅｂＸＭＬ（Ｅｌｅｃｔｒｏｎｉｃ Ｂｕｓｉｎｅｓｓ ｕｓｉｎｇ ＸＭＬ）規格を使用することで、ＸＭＬで表すことができる。たとえば、直接信頼関係は、ｅｂＸＭＬ文書に表すことが可能であり、直接信頼関係を共有する各フェデレーテッド・ドメインは、ｅｂＸＭＬ文書として表された契約のコピーを有することになる。フェデレーション内の様々なエンティティの動作特徴は、ｅｂＸＭＬコレオグラフィ（choreography）内に指定し、ｅｂＸＭＬレジストリ内に公表することが可能であり、たとえば信頼プロキシまたは信頼ブローカを操作するために、特定のフェデレーションへの参加を希望する企業は、フェデレーション内のすべての信頼プロキシまたは信頼ブローカに対してその特定のフェデレーションによって指定された公表された要件に従う必要がある。セキュリティ・トークン・サービスは、他のドメインからのトークンが変換されることになる方法に関する操作上の詳細について、これらのｅｂＸＭＬ文書を解析することができる。ただし、フェデレーション内で信頼関係が実施される方法に関する詳細を指定するために、他の規格およびメカニズムを採用して本発明をサポートできることに留意されたい。

フェデレーテッド・アーキテクチャ内でのシングル・サインオン
所与のユーザのセッション中に、ユーザは多くのフェデレーテッド・ドメインを訪問し、それらのドメインによって提供されるウェブ・サービスを使用することができる。ドメインは、どちらも共通のデータ・フォーマットとしてＸＭＬを使用するＵＤＤＩおよびＷＳＤＬなどの標準規格を使用して、提供するサービスの説明を公表することができる。ユーザは、これらの標準規格にも従うアプリケーションを介して、使用可能なサービスおよびサービス・プロバイダを見つける。ＳＯＡＰは、ＸＭＬで表される要求および応答を通信するためのパラダイムを提供する。フェデレーテッド環境内のエンティティは、とりわけこれらの規格を採用することができる。

フェデレーション内で、ユーザは、ユーザがシングル認証オペレーションを完了するシングル・サインオン体験をすることが予期され、この認証オペレーションは、そのセッション中に訪問したフェデレーション・パートナに関係なく、ユーザのセッションの持続期間にとって十分である。セッションは、初期ユーザ認証、すなわちログオンから（およびこれを含む）ログアウトまでのトランザクションのセットとして定義することができる。セッション中、ユーザのアクションは、そのセッションについてユーザに認められた特権によって部分的に支配される。

前述のフェデレーテッド・アーキテクチャは、シングル・サインオン・オペレーションをサポートする。シングル・サインオン体験を容易にするために、フェデレーテッド環境をサポートするウェブ・サービスは、ユーザの認証の証明を提供するために、サード・パーティによって生成された認証アサーションまたはセキュリティ・トークンの使用もサポートすることになる。このアサーションは、発行パーティに対するユーザの正常な認証の何らかの証拠、ならびにそのユーザに関する識別子を含むことになる。たとえば、ユーザは、たとえばフェデレーション・パートナがユーザに関する認証証明を構築するために使用するユーザ名およびパスワードを提供することによって、１フェデレーション・パートナを伴う従来の認証オペレーションを完了することが可能であり、その後、フェデレーション・パートナは、認証／発行パーティによって生成されたＳＡＭＬ認証アサーションを、異なるフェデレーション・パートナに提供することができる。

フェデレーテッド環境は、ウェブ・サービスまたは他のアプリケーションがウェブ・サービスを要求できるようにするものであり、これらのウェブ・サービスも認証されることになる。ウェブ・サービス環境における認証は、許可されたクライアントへのアクセスを企業が制約できるように、ウェブ・サービス要求の請求されたアイデンティティを検証する動作である。ウェブ・サービスを要求するかまたは呼び出すユーザは、ほぼ常時認証されることになるため、本発明をサポートするフェデレーテッド環境での認証の必要性は、ユーザ認証のためのウェブ・サービスの現在の要件とまったく変わらない。

フェデレーテッド・セッションに参加せずに企業の計算リソースにアクセスしているユーザの認証は、フェデレーテッド・インフラストラクチャの存在によって影響を受けることはない。たとえば、特定のドメインにある非フェデレーテッド・リソースにアクセスするために、ＨＴＴＰ／Ｓを介して、形式ベースの認証メカニズムを使用して認証する既存のユーザは、フェデレーテッド環境に関するドメインでのサポートの導入によって影響を受けることはない。認証は、接点サーバによって部分的に処理され、次にこれが別の信頼プロキシまたは信頼サービス構成要素を呼び出すことが可能であり、接点サーバを使用することで、既存のドメインのインフラストラクチャへの影響を最小限にする。たとえば、接点サーバは、ドメインのバックエンドまたはレガシー・アプリケーションおよびシステムによって処理されることになるすべての非フェデレーテッド要求を通過するように構成することができる。

接点サーバは、基本認証、形式ベース認証、または何らかの他の認証方法などの、ＨＴＴＰベースの認証方法を呼び出すように選択することができる。接点サーバは、ＳＡＭＬ認証アサーションなどの、ユーザによって認証の証明として提示されてきたアサーションを認識することによって、フェデレーション・ドメインもサポートし、このアサーションは企業ドメイン間を横切る。接点サーバは信頼サービスを呼び出すことが可能であり、次にこれが、認証証明／セキュリティ・トークンの妥当性検査のために、そのセキュリティ・トークン・サービスを呼び出すことが可能である。

ウェブ・サービスまたは他のアプリケーションの認証は、ユーザの認証と同じプロセスを有する。ウェブ・サービスからの要求は認証アサーションを含むセキュリティ・トークンを担持し、このセキュリティ・トークンは、ユーザによって提示されたトークンと同じように信頼サービスによって妥当性検査されることになる。ＵＤＤＩで宣伝されると、要求されたサービスによってどの認証アサーション／セキュリティ・トークンが要求されたかをウェブ・サービスが発見することになるため、ウェブ・サービスからの要求にはこのトークンが付随するはずである。

次に図１０を参照すると、フェデレーテッド・シングル・サインオン・オペレーションをサポートする、フェデレーテッド環境を示すブロック図が示される。ユーザ６００は、クライアント・デバイス、およびブラウザなどの適切なクライアント・アプリケーションを介して、フェデレーテッド環境内のフェデレーテッド・ドメインとして動作するデータ処理システムをサポートする、企業／ドメイン６１０によって提供されるウェブ・サービスへのアクセスを希望する。ドメイン６１０は、接点サーバ６１２および信頼プロキシまたは信頼サービス６１４をサポートし、同様に、ドメイン６２０は接点サーバ６２２および信頼プロキシまたは信頼サービス６２４をサポートし、ドメイン６３０は接点サーバ６３２および信頼プロキシまたは信頼サービス６３４をサポートする。信頼プロキシ／サービスは、前述のように、アシスタンス用の信頼ブローカ６５０に依拠する。追加のドメインおよび信頼プロキシ／サービスは、フェデレーテッド環境に参加することができる。図１０は、ドメイン６１０とドメイン６２０との間のフェデレーテッド・シングルサインオン・オペレーションを説明するために使用され、同様のオペレーションをドメイン６１０とドメイン６３０との間で実行することができる。

ユーザは、ドメイン６１０に関して認証オペレーションを完了し、この認証オペレーションは接点サーバ６１２によって処理される。認証オペレーションは、ユーザが、たとえばアクセス制御のため、または個別化のために、認証されたアイデンティティを必要とする何らかのリソースへのアクセスを要求した場合にトリガされる。接点サーバ６１２は、レガシー認証サービスを呼び出すか、またはユーザの提示された認証証明を妥当性検査するために、信頼プロキシ６１４を呼び出すことができる。ドメイン６１０は、ユーザのフェデレーテッド・セッションの持続期間中に、ユーザのアイデンティティ・プロバイダまたはホーム・ドメインになる。

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

接点サーバ６２２は、フェデレーション・シングル・サインオン・トークンと共に要求を受け取り、信頼プロキシ６２４を呼び出す。信頼プロキシ６２４はフェデレーション・シングル・サインオン・トークンを受け取り、トークンを妥当性検査し、トークンが有効で信頼できるものと想定すると、ユーザ用にローカルに有効なトークンを生成する。信頼プロキシ６２４は、ローカルに有効なトークンを接点サーバ６２２に戻し、このサーバがドメイン６２０内のユーザ用のセッションを確立する。必要であれば、接点サーバ６２２は他のフェデレーテッド・パートナでのフェデレーテッド・シングル・サインオンを開始することができる。

ドメイン６２０でのトークンの妥当性検査は、場合によってはセキュリティ・トークン・サービスからのアシスタンスを使用して、信頼プロキシ６２４によって処理される。ドメイン６１０によって提示されるトークンのタイプによって、セキュリティ・トークン・サービスはドメイン６２０のユーザ・レジストリへのアクセスを必要とする場合がある。たとえば、ドメイン６２０は、ドメイン６２０のユーザ・レジストリに照らして妥当性が検査される、ユーザの名前およびパスワードを含むバイナリ・セキュリティ・トークンを提供することができる。したがってこの例では、企業は単にフェデレーテッド・パートナからのセキュリティ・トークンを妥当性検査する。ドメイン６１０と６２０との間の信頼関係によって、ドメイン６２０が、ユーザに代わってドメイン６１０によって提示されたセキュリティ・トークンを理解および信頼できることが保証される。

フェデレーテッド・シングル・サインオンは、ユーザに代わって依拠ドメインに提示されるセキュリティ・トークンの妥当性検査のみならず、セキュリティ・トークンに含まれる情報に基づく依拠ドメインでのローカルに有効なユーザ識別子の決定を必要とする。こうした関係を確立するために必要な直接信頼関係および業務契約の結果の１つが、発行ドメインまたは依拠ドメインのいずれか、あるいはその両方の、少なくとも１つのパーティが、発行ドメインによって依拠ドメインで有効な識別子に提供された情報を変換する方法を知ることである。前述の簡単な例では、発行ドメインすなわちドメイン６１０が、ドメイン６２０で有効なユーザ識別子を伴う依拠ドメインすなわちドメイン６２０を提供できると想定された。このシナリオでは、依拠ドメインはいずれのアイデンティティ・マッピング機能も呼び出す必要がなかった。ドメイン６２０の信頼プロキシ６２４は、ユーザを「保証する」ことになるユーザ向けのセキュリティ・トークンを生成することになる。受け入れられるトークンのタイプ、トークンに必要な署名、および他の要件は、すべてフェデレーションの業務契約の一部として事前に確立される。識別子変換を規制する規則およびアルゴリズムも、フェデレーションの業務契約の一部として事前に確立される。２人の参加者間の直接信頼関係の場合、それら２つのパーティに対して識別子変換アルゴリズムが確立されることになり、フェデレーション内の任意の他のパーティには関連させることができない。

しかしながら、ドメイン６１０のローカル識別子からドメイン６２０のローカル識別子にユーザをマッピングするための方法を、常に発行ドメインが知ることになるとは限らない。場合によっては、このマッピングを実行する方法を知るのは依拠ドメインの可能性があり、さらに場合によってはどちらのパーティもこの変換の実行方法を知らないことになり、この場合、サード・パーティの信頼ブローカの呼び出しが必要な可能性がある。言い換えれば、ブローカリングされた信頼関係の場合、発行および依拠ドメインは互いに直接信頼関係を持たない。しかしながらそれらは、信頼ブローカ６５０などの信頼ブローカとは、直接信頼関係を持つことになる。識別子マッピング規則およびアルゴリズムは、この関係の一部として確立されていることになり、信頼ブローカはこの情報を使用して、ブローカリングされた信頼関係に必要な識別子変換を支援することになる。

ドメイン６２０は、ドメイン６１０によって発行されたトークンを接点サーバ６２２で受け取り、ここではトークンを妥当性検査し、アイデンティティ・マッピングを実行するために、信頼プロキシ６２４を呼び出す。この場合、信頼プロキシ６２４は、ドメイン６１０のローカル識別子からドメイン６２０のローカル識別子にユーザをマッピングすることができないため、信頼プロキシ６２４は信頼ブローカ６５０を呼び出して、これがトークンを妥当性検査し、識別子マッピングを実行する。ユーザのローカル識別子を取得した後、信頼プロキシ６２５は、場合によってはそのセキュリティ・トークン・サービスを介して、ドメイン６２０でバックエンド・アプリケーションによって必要とされるいずれかのローカル・トークンを生成することが可能であり、たとえばケルベロス・トークンは、接点サーバからアプリケーション・サーバへのシングル・サインオンを容易にするために必要とされる。ローカルに有効なトークンを取得した後、必要であれば、接点サーバはユーザ用のローカル・セッションを構築することができる。接点サーバは、ユーザ要求の粗野な許可も処理し、許可された要求をドメイン６２０内の適切なアプリケーション・サーバにも転送する。

フェデレーテッド・ユーザ・ライフサイクル管理
前述の図６〜図１０の一部では、フェデレーテッド環境で使用可能な構成要素の編成を説明したが、他の部分では、フェデレーテッド環境を横切るシングル・サインオン・オペレーションをサポートするためのプロセスを説明した。フェデレーテッド環境内のサービス・プロバイダまたは依拠ドメインが、必ずしもユーザの認証証明を管理しなければならないとは限らず、それら依拠ドメインは、ユーザのアイデンティティ・プロバイダまたはホーム・ドメインによって提供される単一のシングル・サインオン・トークンを活用することができる。しかしながら、上記図６〜図１０の記述では、フェデレーション・パートナのフェデレーテッド・ドメインで、有利な方法でフェデレーテッド・ユーザ・ライフサイクル管理を実施する際に使用できる、明示的プロセスについて説明していない。

フェデレーテッド・ユーザ・ライフサイクル管理機能／サービスは、複数のフェデレーテッド・ドメインでの所与のユーザの特定のユーザ・アカウントまたはユーザ・プロファイルに関して、フェデレーテッド・オペレーションをサポートまたは管理するための機能を有し、場合によっては、機能またはオペレーションはユーザ用の所与のフェデレーテッド・セッションに限定される。言い換えれば、フェデレーテッド・ユーザ・ライフサイクル管理機能とは、場合によってはフェデレーテッド・コンピューティング環境内の単一のユーザ・セッションのライフサイクル中にのみ、複数のフェデレーテッド・パートナにまたがってフェデレーテッド・オペレーションの管理を可能にする機能のことである。

各フェデレーテッド・ドメインは、それぞれのフェデレーテッド・ドメインでの機能に関して何らかの種類のユーザ・アカウント、ユーザ・プロファイル、またはユーザ・セッションを管理する場合がある。たとえば、特定のフェデレーテッド・ドメインは、特定のフェデレーテッド・ドメイン内のローカル・ユーザ・アカウントまたはユーザ・プロファイルを管理しないが、そのフェデレーテッド・ドメインが、そのフェデレーテッド・ドメインでのシングル・サインオンが正常に完了した後には、フェデレーテッド・トランザクション用のローカル・ユーザ・セッションを管理する場合がある。その特定のフェデレーテッド・ドメインによってサポートされるフェデレーテッド・ユーザ・ライフサイクル管理機能の一部として、フェデレーテッド・ドメインは、フェデレーテッド・トランザクション完了後、フェデレーテッド・ドメインがローカル・ユーザ・セッションを終了できるようにする、シングル・サインオン・オペレーションに参加することが可能であり、これによってセキュリティが向上し、リソースの効率的な使用が促進される。

フェデレーテッド・ユーザ・ライフサイクル管理機能使用の他の例では、ユーザは、複数のフェデレーテッド・ドメインの参加を必要とするオンライン・トランザクションに携わることができる。フェデレーテッド・ドメインは、フェデレーテッド・ドメインを伴うそれぞれのユーザのフェデレーテッド・セッション中に、フェデレーテッド・ドメインに関してユーザの体験を調整するために、ユーザ・プロファイルをローカルに管理する場合がある。その特定のフェデレーテッド・ドメインによってサポートされるフェデレーテッド・ユーザ・ライフサイクル管理機能の一部として、所与のフェデレーテッド・トランザクションに参加している他のフェデレーテッド・ドメインの他のプロファイルからの情報を利用する所与のフェデレーテッド・トランザクション中に、フェデレーテッド・ドメインのローカル・ユーザ・プロファイル内の情報を、継ぎ目なく使用することができる。たとえば、ユーザの情報の異なる発信源またはソースにユーザが気づかないように、たとえばウェブ・ページ内でユーザの情報が視覚的にユーザに提示されるように、ユーザの複数のローカル・ユーザ・プロファイルからの情報を何らかのタイプのマージング・オペレーションに組み入れることができる。

フェデレーテッド・ユーザ・ライフサイクル管理機能は、アカウント・リンク／リンク解除のための機能も有することができる。ユーザには、フェデレーション・パートナをまたがって共通のユニークなユーザ識別子が提供され、これによって、１フェデレーション・パートナでの要求の充足の一部として、ユーザに関するシングル・サインオンおよび属性の取り出し（必要であれば）が可能になる。さらに、フェデレーション・パートナは、匿名でユーザを言い表すための共通のユニークなユーザ識別子を使用して、アイデンティティ・プロバイダに追加の属性を要求することができる。

次に図１１を参照すると、本発明をサポートするためにフェデレーテッド・ユーザ・ライフサイクル管理機能を実施するための、フェデレーテッド・ドメイン内のいくつかの構成要素を示すブロック図が示される。図１１は、図７に示されたフェデレーテッド・ドメインなどの、単一のフェデレーテッド・ドメインの要素を示す。図１１のいくつかの要素は、図７などの他の図面に関して上記で論じてきた要素と同様または同一であり、接点サーバ／サービス７０２は接点サーバ３２４と等価であり、保護されたリソースへのアクセスを制御するサービスを実行するアプリケーション・サーバ７０４は、アプリケーション・サーバ３３４と等価であり、保護または制御されたリソース７０６は保護されたリソース３３５と等価であり、フェデレーテッド・ユーザ・ライフサイクル管理（ＦＵＬＭ）アプリケーション７０８はフェデレーテッド・ユーザ・ライフサイクル管理アプリケーション３５２と等価である。図７にはファイアウォールが示されていなかったが、図１１にはファイアウォールが示されている。ファイアウォール７１０およびファイアウォール７１２は、企業のコンピューティング環境を、たとえばインターネットを介する企業のドメイン外部のコンピューティング脅威から保護する、外部ＤＭＺ（電子非武装地帯）を作成する。

図７および図１１に示される異なる観点は、矛盾するかまたは食い違うものではない。図１１に示された例とは対照的に、図７はファイアウォールを示していないが、接点サーバ３４２はフェデレーション・フロントエンド３４０内に常駐し、さらに、フェデレーション・フロントエンド３４０にはフェデレーテッド・ユーザ・ライフサイクル管理アプリケーション３５２が含まれる。図１１では、接点サーバ７０２が、企業ドメインに対する電子または物理的フロントエンドを形成する、ファイアウォール７１０と７１２の間のＤＭＺ内に常駐しているように示されており、さらに、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーション／サービス７０８は、ファイアウォール７１２の後方に電子的に常駐する。信頼サービス７１４、シングル・サインオン・プロトコル・サービス７１６、およびアイデンティティおよび属性サービス７１８は、必要に応じて企業ユーザ・レジストリ７２０およびフェデレーション・ユーザ・レジストリ７２２を採用する。図７および図１１の異なる観点は、図７のフェデレーション・フロントエンド３４０およびバックエンド３３０を、構成要素の論理編成と見なす一方で、図１１のＤＭＺおよび他の構成要素を、どちらもフェデレーテッド構成要素を含むことができる、物理または電子フロントエンドおよび物理または電子バックエンドを形成すると見なすことによって、調整することができる。

接点エンティティ／サービスの役割について繰り返すと、少なくとも企業のコンピューティング環境を備えるフェデレーション機能とのユーザの対話に関して、接点エンティティはセッション管理を提供し、企業のコンピューティング環境のレガシー・バックエンド内のアプリケーションは、それ自体のセッション管理機能も実施することができる。企業がフェデレーテッド・コンピューティング環境に関してポリシー機能を実施すると想定すると、接点エンティティは、何らかの他のフェデレーション・パートナのポリシー決定ポイントに対するポリシー強制ポイントとして動作することができる。加えて、フェデレーション機能の実施が許可されると想定すると、接点エンティティは、シングル・サインオン・オペレーションが採用されないシナリオで、ユーザに対する指示（direction）認証オペレーションを開始する責務を負う。したがって接点エンティティは、たとえば逆プロキシ・サーバとして、ウェブ・サーバ・プラグインとして、または何らかの他の方法でなど、様々な形で実施することができる。接点機能は、アプリケーション・サーバ自体で実施することも可能であり、この場合、フェデレーテッド・ユーザ・ライフサイクル管理サービスを論理的にＤＭＺ内に配置することができる。

より重要なことには、再度図１１を参照すると、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーション７０８は、フェデレーテッド・ユーザ・ライフサイクル管理プラグイン７２４とのインターフェース、対話、またはそうでなければ相互協調処理するためのサポートも有し、これは図７には示されていない。図１１に示された例示的アーキテクチャでは、フェデレーテッド・プロトコル・ランタイム・プラグインは、様々なタイプの独立に公表または開発された、ＷＳ−Ｆｅｄｅｒａｔｉｏｎ Ｐａｓｓｉｖｅ Ｃｌｉｅｎｔ、ならびに、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦ Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ（Ｂ／Ａ、Ｂ／Ｐ、およびＬＥＣＰ）、Ｒｅｇｉｓｔｅｒ Ｎａｍｅ Ｉｄｅｎｔｉｆｉｅｒ、Ｆｅｄｅｒａｔｉｏｎ Ｔｅｒｍｉｎａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ、およびＳｉｎｇｌｅ Ｌｏｇｏｕｔなどの、フェデレーテッド・ユーザ・ライフサイクル管理標準またはプロファイルに関する機能を提供する。異なるＵＲＩで、異なるセットのフェデレーテッド・プロトコルにアクセスすることができる。この手法により、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションは、たとえば、ＷＳ−Ｆｅｄｅｒａｔｉｏｎ ｗｅｂ ｓｅｒｖｉｃｅｓ規格対Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅの規格など、フェデレーテッド・ユーザ・ライフサイクル管理の複数の標準または規格を同時にサポートすることが可能であり、それによって、異なるフェデレーション・プロトコルをサポートするための環境全体に与える構成の影響を最小限にする。

とりわけ、適切なフェデレーテッド・ユーザ・ライフサイクル管理機能は、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションへのユーザ要求のリダイレクトまたは転送あるいはその両方によって、適宜、接点サーバによって呼び出される。再度図１１を参照すると、接点サーバ７０２はユーザ要求７３０を受け取り、次に、前述のように、受け取られた要求メッセージのタイプによって示される可能性のある、受け取られた要求のタイプを決定するために、要求メッセージ内の宛先ＵＲＩを決定することによって、これが分析される。保護されたリソースに対する要求７３２が引き続きアプリケーション・サーバ７０４に転送される間、フェデレーテッド・ユーザ・ライフサイクル管理機能に対する要求７３４、たとえばシングル・サインオフ・オペレーションを呼び出すための要求は、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーション７０８に転送され、これが、受け取った要求を満たすために、必要に応じて適切なフェデレーテッド・ユーザ・ライフサイクル管理プラグインを呼び出す。新しいフェデレーション・プロトコルまたは新しいフェデレーテッド機能が定義される場合、または既存のものが何らかの形で修正または改良される場合、新しいサポート・モジュールをプラギング（plugging）するだけでサポートを追加することができるか、またはあらかじめインストールされたプラグインを修正することによって改良することができる。

図１１のフェデレーテッド・ユーザ・ライフサイクル管理アプリケーションの例示的実施は、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションが、プラギング可能性特徴を提供しながら、複数で同時のフェデレーテッド・ユーザ・ライフサイクル管理機能をサポートできることを示し、これによって、既存のインフラストラクチャをなんら変更する必要なしに、必要な場合、プラグインの形で新しい機能をフェデレーテッド・ユーザ・ライフサイクル管理アプリケーションに追加することができる。たとえば、本発明がＪａｖａベースのフェデレーテッド・ユーザ・ライフサイクル管理アプリケーションを使用して実施されると想定すると、新しく開発されたＪａｖａクラスを構成することによって、新しく公表されたシングル・サインオン・プロトコルなどの新しいフェデレーション・プロトコルに関するサポートを、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションのＪａｖａ ＣＬＡＳＳＰＡＴＨに追加することが可能であり、これらの新しいクラスは、本発明をサポートするためのプロトコル・インターフェースと共に、新しい標準をサポートする。

例示的フェデレーテッド・アーキテクチャは、フェデレーテッド・ユーザ・ライフサイクル管理ソリューションが統合されることになる既存の環境を活用する。フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションは、インフラストラクチャ全体への最小限の変更で展開する際に、新しいプロトコル／標準をサポートするように容易に修正可能である。新しいフェデレーテッド・ユーザ・ライフサイクル管理機能をサポートするために必要な場合のあるいかなる変更も、ほぼ例外なくフェデレーテッド・ユーザ・ライフサイクル管理アプリケーション内に配置され、追加された機能を理解するために、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションを構成する必要がある。

インフラストラクチャ全体が、既存のフェデレーテッド・ユーザ・ライフサイクル管理機能を引き続きサポートしながら、新しいフェデレーテッド・ユーザ・ライフサイクル管理機能を呼び出せるようにするために、たとえば接点サーバなどの他のフェデレーテッド構成要素で最小限の構成変更が行われる場合がある。しかしながら、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションは、フェデレーテッド・ユーザ・ライフサイクル管理アプリケーションがフェデレーテッド環境の他のフェデレーテッド構成要素と最小限の対話しか必要としない可能性があるという点で、機能的に残りのフェデレーテッド構成要素から独立している。たとえば、例示的実施形態では、外部エンティティにはわからないかまたはアクセスできない、専用の内部フェデレーテッド・ユーザ・ライフサイクル管理データストアとは対照的に、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅプロファイルに従ったＮａｍｅＩｄｅｎｔｉｆｉｅｒ値などのフェデレーテッド・ユーザ・ライフサイクル管理情報が、外部アクセス可能なフェデレーテッド・ユーザ・ライフサイクル管理データストアに格納される場合、フェデレーテッド・ユーザ・ライフサイクル管理機能は、企業ベースのデータストア、たとえばＬＤＡＰデータストアと統合することができる。

したがって既存の環境は、フェデレーテッド・ユーザ・ライフサイクル管理機能をサポートするために、最小限の修正を必要とする。さらに、新しい機能の追加を含むフェデレーテッド・ユーザ・ライフサイクル管理機能への変更は、既存のフェデレーテッド環境に最小限の影響を与える。したがって、新しいシングル・サインオン標準が公表された場合、この標準に対するサポートが容易に追加される。

従来のユーザ認証は、企業のコンピューティング環境とエンドユーザの間の対話のみを伴うが、企業がこの認証交換を実施するために選択する方法は、いかなる他の企業にも影響を与えない、企業の選択である。しかしながら、フェデレーションまたはドメイン間共通の（cross-domain）シングル・サインオン機能をサポートすることが望ましい場合、企業パートナが互いに対話し合うことが要件となる。この要件は、専有プロトコルを使用してスケーラブルに実行することができない。標準ベースのフェデレーション・プロトコルのサポートを接点エンティティに直接追加することは、堅実なソリューションのように思われるが、すでに企業のコンピューティング環境内の既存の構成要素である接点エンティティを修正しなければならず、さらに、これらの公開フェデレーション・プロトコルのうちの１つが変更されるたびに修正しなければならない。

この機能を接点エンティティの外に移すことで、よりモジュラな手法が提供され、このプラギング可能な機能によってこれらのプロトコルのマイグレーションまたは更新が維持しやすくなる。

シングル・サインオン・オペレーション中のランタイム・リンク済みユーザ・アカウントの作成
次に図１２を参照すると、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、典型的な従来技術のＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図が示される。図１２および後続の図面に示されたプロセスは、ＨＴＴＰベース通信を採用するが、本発明はＨＴＴＰベース通信に限定されず、他の通信プロトコルを採用することが可能であって、特に本発明は、ＨＴＴＰリダイレクト・ベース技法によって表されるフロント・チャネル通信に限定されず、ＳＯＡＰ／ＨＴＴＰまたはＳＯＡＰ／ＭＱなどのバック・チャネル技法に等しく適用可能である。図１２のデータ流れでは、ウェブ・ブラウザ・アプリケーションなどの、ユーザ・エージェントとしても知られるクライアントのユーザは、アイデンティティ・プロバイダでのみならず、サービス・プロバイダでもすでにユーザ・アカウントを確立しており（ステップ８０２）、ユーザはすでにアイデンティティ・プロバイダに対して認証されている（ステップ８０４）。

図１２の例示的データ流れの前提条件の１つが、最低でも、ユーザがすでにサービス・プロバイダフェデレーテッド・アカウントを有することであり、言い換えれば、サービス・プロバイダは、アイデンティティ・プロバイダによって開始された場合、ユーザに対するシングル・サインオン・オペレーションを実行するために、ユーザに関するユーザ・アイデンティティ情報をアイデンティティ・プロバイダから受け取った場合、この情報を認識する必要がある。ステップ８０４では、前提条件は、単にユーザが何らかの以前の時点でアイデンティティ・プロバイダに認証されており、現在アイデンティティ・プロバイダとの有効なセッションを有することであって、ステップ８０４でセッションが確立された理由についての要件はない。たとえば、アイデンティティ・プロバイダは、アイデンティティ・プロバイダが、ユーザとの何らかの対話の後、何らかの時点で、認証されたユーザに対するある種のオペレーションを実行するのみであると決定する、他のシナリオが可能であることに留意されたい。たとえばユーザは、たとえばブラウザ・アプリケーション内のブックマークが付けられたＵＲＬを使用することにより、サービス・プロバイダの保護されたリソースを要求することによってシングル・サインオン・オペレーションを開始することが可能であり、シングル・サインオン・プロセスを開始するための他のシナリオが可能であることにも留意されたい。

シングル・サインオン・プロセスは、アイデンティティ・プロバイダからクライアントに、フェデレーテッド・リソースへのアクセスを提供するようにとの提案を送信することによってアイデンティティ・プロバイダで開始され（ステップ８０６）、この提案は、フェデレーテッド・ウェブ・サイトにある、またはより一般的にはフェデレーテッド・ドメインにあるリソースへのハイパーリンクの形とすることが可能であり、この提案は、特定のウェブ・ページをアイデンティティ・プロバイダのウェブ・サイト上で見るために、クライアントからの以前のＨＴＴＰ要求メッセージ（図示せず）に応答する、ＨＴＴＰ応答メッセージの形で実行することができる。次にユーザは、アイデンティティ・プロバイダに知られた、サービス・プロバイダにある提案されたフェデレーテッド・リソースのうちの１つを選択し（ステップ８０８）、この選択は、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ要求メッセージによって容易にすることができる。

アイデンティティ・プロバイダは、メッセージがシングル・サインオン要求も含むように、ユーザに代わって、選択されたフェデレーテッド・リソースへのアクセスを要求するためのメッセージを構築し（ステップ８１０）、アイデンティティ・プロバイダは、たとえばＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形の、シングル・サインオン要求を備えたリソース要求をクライアントに送信する（ステップ８１２）。リダイレクト・メッセージは、たとえば、要求されたフェデレーテッド・リソースへのアクセスを制御するサービス・プロバイダでの適切なサービスを識別する、リダイレクト・メッセージの「Ｌｏｃａｔｉｏｎ」ヘッダ内にＵＲＩによって識別されるような適切な場所に、クライアントをリダイレクトする。

従来技術では、プッシュ・タイプのシングル・サインオン・オペレーションを開始する好ましい方法は、シングル・サインオン・アサーション情報を、アイデンティティ・プロバイダによって開始され、サービス・プロバイダで直接トリガされる要求に応答してサービス・プロバイダに送信される、要求に含めることであることに留意されたい。たとえば、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦ １．２規格に指定されたシングル・サインオン・オペレーションを実施するコンピューティング環境では、ＡｕｔｈｎＲｅｓｐｏｎｓｅが構築される。いくつかのシナリオでは、アイデンティティ・プロバイダがクライアントをサービス・プロバイダのトリガＵＲＬにリダイレクトすることが必要であり、その後、トリガＵＲＬがサービス・プロバイダにメッセージ、たとえば、アイデンティティ・プロバイダにリダイレクトされるＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ規格内のＡｕｔｈｎＲｅｑｕｅｓｔメッセージを、構築させることになり、次にこれによって、アイデンティティ・プロバイダに応答、たとえば、ＡｕｔｈｎＲｅｓｐｏｎｓｅを構築させることになり、これは、プッシュ・ベースのＳＳＯがＬｉｂｅｒｔｙ ＩＤ−ＦＦ １．１で実施される際に使用する手段である。

発信される要求メッセージは、２つの別個の要求を備えることが可能であり、その１つはクライアントのユーザに代わってシングル・サインオン・オペレーション向けに要求されたオペレーションであり、もう１つは、クライアントのユーザによって選択された保護されたリソースにアクセスするために要求されたオペレーションである。別の方法として、フェデレーテッド・リソースにアクセスするための要求は、シングル・サインオン・プロセスが、選択されたリソースにアクセスするためのより大規模なプロセスの単なる一部であるように、ユーザに対するシングル・サインオン・オペレーションを実行するために、暗黙の要求を含むことができる。要求されたシングル・サインオン・オペレーションに情報が提供される方法は、変わる可能性がある。たとえば、リダイレクト・メッセージの「Ｌｏｃａｔｉｏｎ」ＨＴＴＰヘッダは、シングル・サインオン・オペレーションを実施するためのセキュリティ・トークンを含む様々な情報を含む、たとえばＵＲＩに添付され、ＵＲＩ内で「？」文字で区切られた、照会構成要素を含むこともできる。

アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるように、サービス・プロバイダにある適切なサービスにＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ８１４）。この方法では、ＨＴＴＰ Ｇｅｔメッセージ内のＵＲＩが、サービス・プロバイダにあるサービスが必要とする添付された情報を依然として含むため、クライアントはサービス・プロバイダにある適切なサービスにアクセスする。

サービス・プロバイダは、クライアントから要求メッセージを受信し、ユーザがサービス・プロバイダでアクティブ・セッションを有するように、要求のシングル・サインオン面が正常に完了したと想定すると（ステップ８１６）、サービス・プロバイダは要求メッセージのリソース・アクセス面を処理する（ステップ８１８）。要求メッセージを処理した後、サービス・プロバイダはＨＴＴＰ応答メッセージを送信することによってクライアントに応答し（ステップ８２０）、それによってプロセスを終わらせる。

次に図１３〜図１４を参照すると、本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダ側でランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。図１２に示される方法と同様に、図１３〜図１４は、どちらも、選択されたサービス・プロバイダでのシングル・サインオン・オペレーションを要求する際にアイデンティティ・プロバイダが使用可能なプロセスを示す。しかしながら、図１２ではステップ８１６で一般化されたシングル・サインオン・オペレーションのみを示すが、図１３〜図１４に示されるプロセスは、シングル・サインオン・オペレーションに関して図１２に示されるプロセスとは異なる。図１２に示されるプロセスとは異なり、クライアントのユーザがサービス・プロバイダですでにユーザ・アカウントを確立しているという、図１３〜図１４に示されるプロセスに対する前提条件はない。

とりわけ、シングル・サインオン・オペレーションに対する従来技術のソリューションは、ある種の前提条件を有し、すなわち、サービス・プロバイダおよびアイデンティティ・プロバイダはどちらもユーザを認識しなければならず、それらはこのユーザを言い表す合意済み手段、すなわち別名識別子、またはより簡単に言えば別名を、持たなければならず、どちらの前提条件も、シングル・サインオン・オペレーションを成功させるために、シングル・サインオン・オペレーションの開始前に真でなければならず、そうでなければ失敗することになる。これらの従来技術ソリューションでは、別名は、アイデンティティ・プロバイダからサービス・プロバイダに送信され、ユーザを識別するためおよびユーザ用のセッションを構築するためにサービス・プロバイダによって使用される、シングル・サインオン応答に含まれる。これらの前提条件は、従来技術ソリューションに存在し、（ａ）たとえば、ユーザがサービス・プロバイダで保護されたリソースにアクセスし、サービス・プロバイダがユーザ用のセッションを必要とする場合、シングル・サインオン・オペレーションがサービス・プロバイダによってトリガされ、それにより、アイデンティティ・プロバイダに要求を送信することによってシングル・サインオン・オペレーションが開始される、あるいは、（ｂ）たとえば、アイデンティティ・プロバイダが、関係するサービス・プロバイダによってホストされるリンク済みリソースのリストを有する場合、シングル・サインオン・オペレーションがアイデンティティ・プロバイダによってトリガされ、ユーザがこれらのリンクのうちの１つを選択した後、アイデンティティ・プロバイダによってシングル・サインオン・オペレーションが開始される、のいずれかである。これに対して、以下で説明する本発明の複数の例示的実施形態によって示されるように、本発明はこれらの前提条件を排除する。

図１３を参照すると、ユーザはすでにアイデンティティ・プロバイダに認証されている（ステップ９０２）。ステップ９０２で、ユーザは以前の何らかの時点でアイデンティティ・プロバイダに認証されており、現在はアイデンティティ・プロバイダとの有効なセッションを有し、ステップ９０２でセッションが確立された理由に対する要件はない。シングル・サインオン・オペレーションを開始するための他のシナリオは、異なるステップ・シーケンスを有することができることに留意されたい。たとえば、ユーザは、認証済みセッションなしにアイデンティティ・プロバイダによって提供される情報をブラウズする場合があり、ユーザとの何らかの対話の後、何らかの時点で、ユーザは、アイデンティティ・プロバイダが認証済みユーザに対してある種のオペレーションのみを実行することを、アイデンティティ・プロバイダが決定するように、リソースを要求し、それによってユーザとの認証オペレーションが開始される。

シングル・サインオン・プロセスは、アイデンティティ・プロバイダからクライアントに、フェデレーテッド・リソースへのアクセスを提供するようにとの提案を送信することによってアイデンティティ・プロバイダで開始され（ステップ９０４）、この提案は、フェデレーテッド・ウェブ・サイトにある、またはより一般的にはフェデレーテッド・ドメインにあるリソースへのハイパーリンクの形とすることが可能であり、この提案は、特定のウェブ・ページをアイデンティティ・プロバイダのウェブ・サイト上で見るために、クライアントからの以前のＨＴＴＰ要求メッセージ（図示せず）に応答する、ＨＴＴＰ応答メッセージの形で実行することができる。次にユーザは、アイデンティティ・プロバイダに知られた、サービス・プロバイダにある提案されたフェデレーテッド・リソースのうちの１つを選択し（ステップ９０６）、この選択は、クライアントからアイデンティティ・プロバイダへのＨＴＴＰ要求メッセージによって実施することができる。

ユーザがフェデレーテッド・シングル・サインオン・オペレーションに使用することができるフェデレーテッド・アイデンティティをまだ有していない場合、アイデンティティ・プロバイダはユーザに対する別名を作成する（ステップ９０８）。アイデンティティ・プロバイダは、メッセージがシングル・サインオン要求、すなわちプッシュ・タイプのシングル・サインオン要求も含むように、ユーザに代わって、選択されたフェデレーテッド・リソースへのアクセスを要求するためのメッセージを構築する（ステップ９１０）。プッシュ・タイプのシングル・サインオン要求は、アイデンティティ・プロバイダから発信され、ユーザ・アイデンティティを認証する情報をサービス・プロバイダに提供するために、一方的にサービス・プロバイダにプッシュされるものであり、これに対してプル・タイプのシングル・サインオン要求は、請求されて、ユーザに関する認証情報の収集（pull）を試みているサービス・プロバイダから発信される。代替方法として、特に、プッシュ・タイプのシングル・サインオン・オペレーションが明示的にサポートされていない場合、プッシュ・タイプのシングル・サインオン・オペレーションをエミュレートすることができる。エミュレートされたプッシュ・タイプのシングル・サインオン・オペレーションは、たとえば、サイト間転送サービスなどのサービス・プロバイダで特化されたサービスを介して、アイデンティティ・プロバイダがサービス・プロバイダに対して要求を発行した場合に実行され、ここでサービス・プロバイダは、アイデンティティ・プロバイダに対してシングル・サインオン要求を発行し、アイデンティティ・プロバイダがサービス・プロバイダからの要求に応答した後、処理ステップは、明示的なプッシュ・タイプのシングル・サインオン・オペレーションが実行された場合と同じである。

アイデンティティ・プロバイダは、たとえばＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形の、シングル・サインオン要求を備えたリソース要求をクライアントに送信する（ステップ９１２）。リダイレクト・メッセージは、たとえば、要求されたフェデレーテッド・リソースへのアクセスを制御するサービス・プロバイダでの適切なサービスを識別する、リダイレクト・メッセージの「Ｌｏｃａｔｉｏｎ」ヘッダ内にＵＲＩによって識別されるような適切な場所に、クライアントをリダイレクトする。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されるように、サービス・プロバイダにある適切なサービスにＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ９１４）。

サービス・プロバイダは、クライアントからのメッセージを受信し、受信した要求メッセージを処理する（ステップ９１６）。ステップ９１６で、サービス・プロバイダは、アイデンティティ・プロバイダによってユーザに関連付けられているが、サービス・プロバイダの既存のユーザ・アカウントに関連付けられているとは、サービス・プロバイダによって認識されない、別名識別子または別名情報を、受信したメッセージから取り出す。したがってステップ９１６で、サービス・プロバイダは、ユーザをアイデンティティ・プロバイダにリンクさせるユーザ・アカウント、すなわち、ユーザを認証するためにアイデンティティ・プロバイダからのシングル・サインオン・オペレーションに関する情報を、サービス・プロバイダが受け入れるべきである旨を、サービス・プロバイダに通知する、リンク済みユーザ・アカウントを、ユーザが有していないと決定する。言い換えれば、ステップ９１６で、サービス・プロバイダは、サービス・プロバイダのユーザ・アカウントをアイデンティティ・プロバイダのユーザ・アカウントにリンクさせるユーザ・アカウントを、サービス・プロバイダが有していないと決定する。

この認識は、以下の理由で重要である。ユーザがサービス・プロバイダですでに１つまたは複数のアカウントを有している可能性があることに留意されたい。これらのアカウントは、ユニークなユーザ・アカウントがユニークなユーザ識別子に基づいているため、独立に使用することが可能であり、ユーザ識別子が与えられると、サービス・プロバイダは、そのユーザ識別子に関連付けられる特権、すなわち、特定のユーザ・アカウントを決定する。リンク済みユーザ・アカウントが、ユーザがサービス・プロバイダで有する可能性のある任意の他のユーザ・アカウントから独立しており、さらに、リンク済みユーザ・アカウントが、リンク済みユーザ・アカウントに関連付けられるユニークなユーザ識別子を必要とすると考えると、リンク済みユーザ・アカウントは、サービス・プロバイダに知られている任意の他のユーザ識別子に比べて、独立かつユニークなユーザ識別子に基づき、この特定のユーザ識別子は、別名識別子として知られるが、いくつかの実施形態では、複数のデータ変数内の何らかの形の別名情報を単一の別名データ変数の代わりに使用することができる。

したがって、サービス・プロバイダが、提供された別名識別子がサービス・プロバイダの既存のユーザ・アカウントに関連付けられていないと認識した後、サービス・プロバイダは、シングル・サインオン・オペレーションが正常に実行されたことを保証するために、オペレーションの実行を開始する。ユーザがまだサービス・プロバイダとフェデレートされていないため、サービス・プロバイダは、ユーザがサービス・プロバイダでアクティブ・セッションを有するように、要求メッセージ内でアイデンティティ・プロバイダによって提供された別名情報を備えたユーザ用の新しいアカウントを作成する（ステップ９１８）。

このアカウントを作成するために必要な最低限の情報は、アカウントを識別するために必要な任意のローカル情報（サービス・プロバイダによって内部的に生成される）と、アイデンティティ・プロバイダによって提供される任意の別名情報であり、その後、新しく作成されたユーザ・アカウントは、サービス・プロバイダが、アイデンティティ・プロバイダと協働してユーザに代わってシングル・サインオン・オペレーションを実行できるように、提供されたユーザの別名に基づいてアイデンティティ・プロバイダにリンクされることに留意されたい。サービス・プロバイダへの要求がユーザに関するユーザ属性ならびに別名識別子を含む場合、これらの属性をローカル・アカウントに追加することができるが、いくつかの実施形態では、サービス・プロバイダは別名識別子のみを使用して、アイデンティティ・プロバイダからの追加のユーザ属性情報なしに、場合によってはサービス・プロバイダによって決定され、アイデンティティ・プロバイダから受信されたいかなる情報からも独立した、デフォルトのユーザ属性のローカル・セットを割り当てることによって、リンク済みユーザ・アカウントを作成できることに留意されたい。任意の追加の属性が提供されるか否かによって、留意すべき点は、このアカウントが好ましくは直接認証に実行できなくなることであり、したがって、ユーザがサービス・プロバイダのリソースへのアクセス権を得るための唯一の方法は、アイデンティティ・プロバイダによってトリガされたシングル・サインオン・オペレーションから確立されたセッションの結果となる。

リンク済みユーザ・アカウントが作成された後、サービス・プロバイダは要求されたリソース・アクセスを実行する（ステップ９２０）。リソース・アクセスを実行した後、サービス・プロバイダは、ＨＴＴＰ応答メッセージをクライアントに送信することによって応答し（ステップ９２２）、それによってプロセスを終了させる。

サービス・プロバイダは、シングル・サインオン・オペレーションをサポートするために、本発明のシングル・サインオン・オペレーション中に、ユーザをアイデンティティ・プロバイダのアカウントにリンクするユーザ用のユーザ・アカウントを、サービス・プロバイダが有していないことを認識するため、本発明、たとえば図１３に示された実施形態のシングル・サインオン・オペレーションは、従来技術のシングル・サインオン・ソリューション、たとえば図１２に示されたオペレーションとは異なるが、それでも本発明を利用して、サービス・プロバイダは、シングル・サインオン・オペレーションを進行させることができるように、オペレーションを動的に実行することができる。とりわけ、サービス・プロバイダは、たとえばそのユーザ・レジストリまたはデータベース内に、サービス・プロバイダがユーザのローカル・アイデンティティを決定できるだけの十分な情報、およびシングル・サインオン・オペレーションに対するユーザの特権を有しておらず、この情報がなしでは、サービス・プロバイダがシングル・サインオン・オペレーションを進行できる場合、サービス・プロバイダは、ユーザに与えられるべき適切な特権セット、およびユーザに与えるセッション／アクセス制御権のタイプを、決定することができない。従来技術では、サービス・プロバイダは自動的にユーザ用のアクティブ・セッションを作成すること、および保護されたリソースにアクセスすることができず、本発明を使用すると、サービス・プロバイダは、アイデンティティ・プロバイダによってサービス・プロバイダに提供された、たとえばクライアントを介してアイデンティティ・プロバイダからリダイレクトされた要求内に提供された、ユーザ・アイデンティティおよび場合によっては属性情報に基づいて、リンク済みユーザ・アカウントを作成することによって、サービス・プロバイダでのランタイム・リンク済みユーザ・アカウント作成オペレーションを動的に実行する。サービス・プロバイダは、フェデレーテッド・コンピューティング環境を備えたアイデンティティ・プロバイダとのその信頼関係に基づいて、こうしたオペレーションを実行することを希望しており、これを実行することができる。この場合、シングル・サインオン要求は、サービス・プロバイダによって満たすことが可能であり、その結果、ユーザ用のアクティブ・セッションが作成され、保護されたリソースへのアクセス要求を進めることができる。

図１３に示された方法と同様に、図１４は、アイデンティティ・プロバイダが選択されたサービス・プロバイダでのシングル・サインオン・オペレーションを要求する際に使用することができるプロセスを示し、図面内の同じ要素は同じ参照番号で識別される。しかしながら、図１３は、ステップ９１８で一般化されたランタイム・ユーザ・アカウント作成オペレーションのみを示すが、図１４に示されたプロセスは、ランタイム・リンク済みユーザ・アカウント作成オペレーションに関して図１３に示されたプロセスとは異なり、図１４のステップ９３０〜９４２へと続く。図１３に示されたプロセスとは異なり、図１４に示されたプロセスでは、サービス・プロバイダは、アイデンティティ・プロバイダによってサービス・プロバイダに提供された情報に基づいて、サービス・プロバイダでのユーザ・アカウントの即時作成、または作成の即時完了は実行できない。

次に図１４を参照すると、サービス・プロバイダがシングル・サインオン・オペレーション中に、アイデンティティ・プロバイダからのシングル・サインオン要求で請求またはアサートされた、アイデンティティに関する既存のユーザ・アカウント、すなわち、ユーザの代わりにサービス・プロバイダをアイデンティティ・プロバイダにリンクさせる既存のユーザ・アカウントを、サービス・プロバイダが有していないこと、およびさらに、シングル・サインオン要求に含まれる情報がサービス・プロバイダで有効なアカウントを作成するには不十分であること、を認識するため、図１４内のシングル・サインオン処理（ステップ９３０）は異なる。したがって、サービス・プロバイダは、アイデンティティ・プロバイダからのユーザに関する追加の情報が必要であることを認識する。とりわけサービス・プロバイダは、ユーザに関するアクティブ・アカウントを作成するための十分なユーザ属性情報を有しておらず、たとえば、サービス・プロバイダによって必要とされる属性があるが、受信したシングル・サインオン要求には含まれていない可能性がある。これらの追加要件により、サービス・プロバイダは、受け取った情報に基づいて必要とするどのようなユーザ・アカウント・レジストリ／データベース・エントリも、依然として作成または完全に作成することができない。

図１４に示された実施形態では、サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）をクライアントに送信することによって応答し（ステップ９３２）、サービス・プロバイダからのメッセージは、追加のユーザ属性情報に対する要求を含む。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダにリダイレクトする。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるように、ＨＴＴＰ Ｇｅｔメッセージをアイデンティティ・プロバイダに送信する（ステップ９３４）。

次にアイデンティティ・プロバイダは、クライアントのユーザに関してアイデンティティ・プロバイダによって格納されたユーザ属性情報を含む応答を構築するために、受信したメッセージを処理する（ステップ９３６）。特定のユーザ属性が識別される方法は、変更される場合がある。たとえば、アイデンティティ・プロバイダによって提供されるユーザ属性情報は、サービス・プロバイダによって明示的に要求されたユーザ属性情報を含むことができる。加えて、または代替方法として、アイデンティティ・プロバイダによって提供されるユーザ属性情報、すなわち、サービス・プロバイダでユーザ・アカウント作成オペレーションを実行するために十分となるようにアイデンティティ・プロバイダによって決定されたユーザ属性情報は、サービス・プロバイダによって暗黙に要求されたユーザ属性情報を含むことができる。加えて、アイデンティティ・プロバイダは、サービス・プロバイダがそれを実行するための十分な理由なしにユーザ属性の取得を試みていないことを保証するために、アイデンティティ・プロバイダの以前のシングル・サインオン要求を使用して、追加のユーザ属性情報に関して受信した要求を調整するためのオペレーションを実行することができる。

アイデンティティ・プロバイダがステップ９３６でメッセージを構築した後、アイデンティティ・プロバイダは、追加のユーザ属性と共に、たとえば、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形でこのメッセージをクライアントに送信する（ステップ９３８）。リダイレクト・メッセージは、たとえば、サービス・プロバイダの適切なサービスを識別する、リダイレクト・メッセージの「Ｌｏｃａｔｉｏｎ」ヘッダ内でＵＲＩによって識別されるような、適切な場所にクライアントをリダイレクトし、この適切な場所は、追加のユーザ属性に対するその要求にサービス・プロバイダによって提供されている可能性がある。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されたような、サービス・プロバイダの適切なサービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ９４０）。

受信されたメッセージ内に追加のユーザ属性情報があるとすると、サービス・プロバイダは、受信したユーザ属性情報に基づいてリンク済みユーザ・アカウントを作成することによって、サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行し（ステップ９４２）、このように、サービス・プロバイダによってシングル・サインオン要求（および任意の後続のシングル・サインオン要求）を満たすことが可能であり、さらにユーザ用のアクティブ・セッションも作成し、ステップ９２０および９２４で保護されたリソースへのアクセス要求を進めることができる。いくつかの実施形態では、サービス・プロバイダは、ユーザ・アカウントを事前に作成し、さらにユーザ・アカウントの作成の完了を延期することが可能であり、これらの実施形態では、サービス・プロバイダはステップ９４２でユーザ・アカウントの作成を完了する。プロセスは、ＨＴＴＰリダイレクト・ベースの属性取り出しとの関連において説明されるが、これらのプロセスは、サービス・プロバイダからアイデンティティ・プロバイダへのＳＯＡＰ／ＨＴＴＰベースのＳＡＭＬ属性照会などの、バック・チャネル手法でも実施可能であることに留意されたい。

次に図１５〜図１７を参照すると、本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダによるユーザ属性を取得するための代替方法を使用して、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図が示される。図１５〜図１７に示されるプロセスは、主にサービス・プロバイダがシングル・サインオン・オペレーション中にユーザ属性を取得する方法において、図１３〜図１４に示されるプロセスとは異なり、図１３〜図１４および図１５〜図１７に示されるプロセスは、どちらも、アイデンティティ・プロバイダによって開始される。加えて、図１４に示されたデータ流れでは、サービス・プロバイダはステップ９４２でランタイム・リンク済みユーザ・アカウント作成オペレーションを実行するが、これに対して、図１５〜図１７に示されたデータ流れでは、以下でより詳細に説明するように、サービス・プロバイダは、リンク済みユーザ・アカウントを部分的に作成し、その後、ランタイム・リンク済みユーザ・アカウント作成オペレーションを完了することによって、複数のステップにわたってランタイム・リンク済みユーザ・アカウント作成オペレーションを実行することができる。

次に図１５を参照すると、プロセスは、アイデンティティ・プロバイダによってホストされるユーザ・ブラウジング公開リソース、すなわち、リソースにアクセスする前にユーザに関して認証オペレーションを必要とする、保護されたリソースではないリソースで、開始される（ステップ９５２）。その後の何らかの時点に、ユーザのクライアントは、認証オペレーションを必要とする保護されたリソースへのアクセスについての要求を、アイデンティティ・プロバイダに送信し（ステップ９５４）、たとえばユーザは、アイデンティティ・プロバイダが、サービス・プロバイダ、すなわちアイデンティティ・プロバイダのフェデレーテッド・パートナと共に参加する、フェデレーテッド・コンピューティング環境内のサービス・プロバイダのリソースに関して、アイデンティティ・プロバイダが維持する情報を、ブラウズするよう試みる。ユーザの要求に応答して、アイデンティティ・プロバイダは、ユーザに対する認証オペレーションを実行する（ステップ９５６）。この例では、その後アイデンティティ・プロバイダが、フェデレーテッド・サービス・プロバイダのリソースへのリンクを提案し（ステップ９５８）、次にユーザは、サービス・プロバイダでのリソースにアクセスするためのオペレーションを選択または開始する（ステップ９６０）。

ユーザがフェデレーテッド・シングル・サインオン・オペレーションに使用可能な別名識別子をまだ有していない場合、アイデンティティ・プロバイダはユーザに対する別名を作成し（ステップ９６２）、これは、ユーザに別名識別子を関連付けるため、特に、たとえばユーザ属性情報などの、ユーザに関連付けられた他の情報に別名識別子を関連付けるための、他のオペレーションの実行を含むことができる。アイデンティティ・プロバイダは、メッセージがシングル・サインオン要求、すなわちプッシュ・タイプのシングル・サインオン要求も含むように、ユーザに代わって、選択されたフェデレーテッド・リソースへのアクセスを要求するためのメッセージを構築する（ステップ９６４）。アイデンティティ・プロバイダは、たとえば、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形で、リソース要求をシングル・サインオン要求と共にクライアントに送信する（ステップ９６６）。リダイレクト・メッセージは、たとえば、要求されたフェデレーテッド・リソースへのアクセスを制御するサービス・プロバイダでの適切なサービスを識別する、リダイレクト・メッセージの「Ｌｏｃａｔｉｏｎ」ヘッダ内にＵＲＩによって識別されるような適切な場所に、クライアントをリダイレクトする。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるような、サービス・プロバイダの適切なサービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ９６８）。

次にサービス・プロバイダは、たとえば新しく作成されたユーザに対する別名識別子を抽出すること、およびアイデンティティ・プロバイダによってサービス・プロバイダにあらかじめ提供されていた、ユーザに関する任意のユーザ属性情報を抽出することを、含むことができる、シングル・サインオン応答を処理する（ステップ９７０）。サービス・プロバイダは、新しいユーザ・アカウントの作成を試みる（ステップ９７２）が、シングル・サインオン応答において、アイデンティティ・プロバイダによってサービス・プロバイダに提供されたフェデレーテッド・ユーザ・アイデンティティ情報に基づいて、サービス・プロバイダで完全に適切なユーザ・アカウントを、即時に作成できないか、または作成できない。言い換えれば、実施に応じて、サービス・プロバイダが、その時点でユーザ・アカウントの作成に失敗するかまたは作成できないと決定する、あるいはサービス・プロバイダが、限られた時間または限られたアクセス権限でユーザ・アカウントを作成する。とりわけ、サービス・プロバイダは、たとえばそのユーザ・レジストリまたはデータベースとアイデンティティ・プロバイダによって初期に提供された情報との組み合わせにおいて、サービス・プロバイダがユーザの適切な特権セットを決定できるのに必要な情報を有しておらず、この情報なしでは、サービス・プロバイダはユーザに与えるセッション／アクセス制御権のタイプを決定することができない。したがってサービス・プロバイダは、シングル・サインオン・オペレーション中に、サービス・プロバイダがユーザに関するリンク済みユーザ・アカウントをまだ有していないことを認識しながら、サービス・プロバイダがアイデンティティ・プロバイダからのユーザに関する追加の情報を必要とすることも認識する（ステップ９７４）。

サービス・プロバイダがユーザ・アカウント作成オペレーションを完了するために、追加のユーザ属性情報をアイデンティティ・プロバイダから収集する方法は変更が可能であり、その変更の２つの例が図１６および図１７に示されている。図１６はフロント・チャネル属性取り出しオペレーションを示し、図１７はバック・チャネル属性取り出しオペレーションを示す。したがって、図１５に示されたデータ流れ図は、図１６または図１７のいずれかへと続き、どちらの場合も、図１６および図１７のデータ流れ図は、同様の参照番号で示された同様のステップで終了する。

次に図１６を参照すると、サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）をクライアントに送信することによって、そのユーザ属性情報の欠如の決定に応答し（ステップ９７６）、サービス・プロバイダからのメッセージは、追加のユーザ属性情報に対する要求を含む。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダへとリダイレクトする。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるように、ＨＴＴＰ Ｇｅｔメッセージをアイデンティティ・プロバイダに送信する（ステップ９７８）。次にアイデンティティ・プロバイダは、クライアントのユーザに関してアイデンティティ・プロバイダによって格納されたユーザ属性情報を含む応答を構築するために、受信したメッセージを処理する（ステップ９８０）。特定のユーザ属性が識別される方法は、変更される場合がある。たとえば、アイデンティティ・プロバイダによって提供されるユーザ属性情報は、サービス・プロバイダによって明示的に要求されたユーザ属性情報を含むことができる。加えて、または代替方法として、アイデンティティ・プロバイダによって提供されるユーザ属性情報、すなわち、サービス・プロバイダでユーザ・アカウント作成オペレーションを実行するために十分となるようにアイデンティティ・プロバイダによって決定されたユーザ属性情報は、サービス・プロバイダによって暗黙に要求されたユーザ属性情報を含むことができる。加えて、アイデンティティ・プロバイダは、サービス・プロバイダがそれを実行するための十分な理由なしにユーザ属性の取得を試みていないことを保証するために、サービス・プロバイダの以前のシングル・サインオン要求を使用して、追加のユーザ属性情報に関して受信した要求を調整するためのオペレーションを実行することができる。

アイデンティティ・プロバイダがステップ９８０でメッセージを構築した後、アイデンティティ・プロバイダは、ユーザ属性と共に、たとえば、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形でこのメッセージをクライアントに送信する（ステップ９８２）。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されたような、サービス・プロバイダの適切なサービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ９８４）。

受信されたメッセージ内にユーザ属性情報があるとすると、サービス・プロバイダは、受信したユーザ属性情報に基づいてサービス・プロバイダでユーザ・アカウント作成オペレーションを実行または完了し（ステップ９８６）、このように、サービス・プロバイダによってシングル・サインオン要求を満たすことが可能であり、さらにユーザ用のアクティブ・セッションも作成し、保護されたリソースへのアクセス要求を進めることができる。図１６および図１７の両方で、サービス・プロバイダは最初に要求された保護されたリソースへのアクセスを提供し（ステップ９８８）、サービス・プロバイダは、保護されたリソースへのアクセスから導出された情報を含むＨＴＴＰ応答メッセージをクライアントに送信し（ステップ９６０）、これによってプロセスが終了する。

次に図１７を参照すると、サービス・プロバイダは、ＳＯＡＰメッセージをサービス・プロバイダからアイデンティティ・プロバイダに直接送信することによって、そのユーザ属性情報の欠如の決定に応答し（ステップ９９２）、サービス・プロバイダからのメッセージは、必要なユーザ属性情報に対する要求を含む。その後、アイデンティティ・プロバイダは、クライアントのユーザに関してアイデンティティ・プロバイダによって格納されたユーザ属性情報を含む応答を構築するために、受信したメッセージを処理し（ステップ９９４）、ここでも、特定のユーザ属性が識別される方法は前述のように変更される場合がある。アイデンティティ・プロバイダは、ＳＯＡＰ応答メッセージを必要なユーザ属性と共にクライアントに送信する（ステップ９９６）。受信したメッセージ内にユーザ属性情報があるとすれば、サービス・プロバイダは、受信したユーザ属性情報に基づいて、サービス・プロバイダでのランタイム・ユーザ・アカウント作成オペレーションを実行または完了し（ステップ９９８）、こうして、サービス・プロバイダによってシングル・サインオン要求を満たすことが可能であり、ユーザ用のアクティブ・セッションも作成し、ステップ９８８およびステップ９９０で、保護されたリソースにアクセスするための要求を進めることができる。

次に図１８を参照すると、アイデンティティ・プロバイダによって開始されたシングル・サインオン・オペレーション中に、サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行するための、より詳細なプロセスを示す流れ図が示される。図１８に示された流れ図は、図１４に示されたデータ流れ図内のサービス・プロバイダで実行される処理のうちのいくつかについて、サービス・プロバイダ中心の観点を示す。

プロセスは、サービス・プロバイダが、シングル・サインオン・オペレーションに基づいて、クライアントのユーザの代わりに、サービス・プロバイダの保護されたリソースにアクセスするためのアイデンティティ・プロバイダからの要求を受け取った場合に開始される（ステップ１００２）。保護されたリソースは、シングル・サインオン要求を満たすためのサービス・プロバイダの機能に対応するエンドポイントとすることが可能であり、言い換えれば、ユーザは、特定のバック・エンドリソースではなく、単にサービス・プロバイダへのアクセス全体を要求したため、アイデンティティ・プロバイダからの要求を、シングル・サインオン・オペレーションを実施するために知られた機能に直接リダイレクトすることが可能であることに留意されたい。サービス・プロバイダは、受信した要求メッセージからユーザ識別子を抽出し（ステップ１００４）、ユーザ識別子が認識されるか否かに関して判別する（ステップ１００６）。

ユーザ識別子がサービス・プロバイダによって認識されない場合、サービス・プロバイダは、そのホストされた計算リソースへの保護されたアクセスに関する適切なセキュリティ考慮点を備えるアクティブ・セッションを作成することができない。サービス・プロバイダは、受信したメッセージ埋め込まれている可能性のある任意のユーザ属性情報を抽出し（ステップ１００８）、たとえば、ユーザ・レジストリへのエントリを生成する必要があるように、または、サービス・プロバイダでユーザ用のローカル・ユーザ・アカウントを作成するために、サービス・プロバイダによって通常はどのようなオペレーションが実行されるかなど、サービス・プロバイダが、その時点でユーザ用にユーザ・アカウントを作成するために、ユーザに関する十分な情報を有するか否かに関して判別される（ステップ１０１０）。

サービス・プロバイダがユーザ用にユーザ・アカウントを作成するために、ユーザに関する十分な情報を有していない場合、サービス・プロバイダは、追加のユーザ属性情報を取得するためにアイデンティティ・プロバイダに要求を送信することが可能であり（ステップ１０１２）、これは、同期または非同期で実行することができる。続いてサービス・プロバイダは、アイデンティティ・プロバイダから追加のユーザ属性を受け取る（ステップ１０１４）。

本発明の実施形態が、サービス・プロバイダによるユーザ属性取り出しオペレーションが、属性情報プロバイダに関して実行可能であるように実施できることに留意されたい。たとえばサービス・プロバイダは、ユーザ属性に関する要求を、アイデンティティ・プロバイダではなく属性情報プロバイダに送信することができる。代替方法として、サービス・プロバイダは、ユーザ属性に関する要求をアイデンティティ・プロバイダに送信し、続いて属性情報プロバイダに要求を送信することによって支援を得、それによってサービス・プロバイダに代わって仲介の信頼エージェントとして動作することができる。フェデレーテッド・コンピューティング環境との関連における属性情報プロバイダの使用に関する追加の情報は、本特許出願と同じ譲受人の２００２年１２月３１日出願の米国特許出願第１０／３３４６０５号に基づく、Ｂｌａｋｌｅｙ等による２００４年７月１日付の米国特許出願公開、第ＵＳ２００４／０１２８３７８Ａ１号、「Method and system for user-determined attribute storage in afederated environment」に記載されている。

ステップ１０１４で追加のユーザ属性を受け取った後、またはステップ１００８で抽出されたオリジナルの要求に存在していた可能性のある任意のユーザ属性情報に基づいて、サービス・プロバイダは、リンク済みユーザ・アカウント作成オペレーションを実行するが（ステップ１０１６）、前述のように、サービス・プロバイダのユーザに関するリンク済みユーザ・アカウントを作成するために実行されるオペレーションは変更される可能性がある。サービス・プロバイダでリンク済みユーザ・アカウントが作成された後、サービス・プロバイダはオリジナル要求の処理を進行させることができる。

次にサービス・プロバイダは、ユーザに関してあたらしく作成されたアカウントを活動化するために十分な情報があるかどうかを判別する（ステップ１０１８）。サービス・プロバイダがユーザのアカウントを活動化するためにまだ十分な情報を有していない場合、サービス・プロバイダが、ユーザ・アカウントを活動化するためのユーザ属性を取得するために、すでにかなり多くの試行を行ったかどうかに関して判別され（ステップ１０２０）、まだ行っていない場合、プロセスはステップ１０１２に戻り、必要なユーザ属性を取得するための試行を行う。そうでない場合、サービス・プロバイダは何らかのタイプのエラー処理を実行し（ステップ１０２２）、これにはアイデンティティ・プロバイダへのエラー応答の返送を伴う場合がある。

ステップ１０１８で、サービス・プロバイダがユーザのアカウントを活動化するために十分な情報を有している場合、サービス・プロバイダは、ステップ１００６で認識されたユーザ・アイデンティティの正常な認証に基づくか、またはステップ１０１６で新しく作成されたユーザ・アイデンティティに基づくかのいずれかで、ユーザ用のアクティブ・セッションを作成する（ステップ１０２４）。次にサービス・プロバイダは、保護されたリソースにアクセスするためにオリジナル要求に対する応答を生成し（ステップ１０２６）、この応答はサービス・プロバイダによってアイデンティティ・プロバイダに送信され（ステップ１０２８）、これによってプロセスは終了する。

図１４に関して記載された例示的データ流れまたは図１８に関して記載された例示的プロセスは、図１１または図７に示された例示的データ処理システムとの関連において説明される。

シングル・サインオン・オペレーションを実行するために、アイデンティティおよび属性サービス（Ｉ＆ＡＳ）３５６または７１８は、何らかの方法で、ユーザ・レジストリ内のシングル・サインオン要求からユーザ・アイデンティティを認識できる必要がある。ユーザ・レジストリは、たとえば、フェデレーション・ユーザ・レジストリ３５８または７２０などの、フェデレーテッド機能のインストール専用のローカル・レジストリとするか、または企業ユーザ・レジストリ３３８または７２２などのように、企業内の他のアプリケーションによって共有される企業レジストリとすることができる。ユーザ・アカウント情報またはユーザ・レジストリ情報は、Ｉ＆ＡＳ ３５６または７１８が、ユーザをローカルに識別する適切な情報を構築できるようにするために必要である。この情報は、ユーザ名、たとえばグループまたは役割または権利あるいはそれらすべてなどの属性セット、あるいはＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ規格内に記載されたＮａｍｅＩｄｅｎｔｉｆｉｅｒなどのあいまいな識別子によって、表すことができる。シングル・サインオンが要求されているユーザに関して、アイデンティティ・プロバイダによってアサートされた情報が、ローカル・レジストリで見つからない場合、Ｉ＆ＡＳ ３５６または７１８は、たとえば、ローカル企業内のエンティティによって使用される有効な証明を作成するために、ユーザに関する情報をローカルに構築することができず、さらに、接点サーバ３４２または７０２はユーザ用のセッションを確立することができず、ユーザは保護されたリソースにアクセスすることができない。

本発明は、従来技術の手法では実行されるような、認識されていないユーザに関する何らかの形のエラー・コードの生成を防止するためのメカニズムを提供する。図に示される本発明の実施形態では、受け取ったユーザ・アイデンティティ情報が認識されない場合、Ｉ＆ＡＳ ３５６または７１８が、企業のデータ・ストレージ要件に適したようにユーザ・アカウント、記録、またはエントリを作成するように試行することができる。Ｉ＆ＡＳ ３５６または７１８は、これらのオペレーションを、たとえば、このタイプの動作が可能な構成済みポリシー内に提供されるような、アイデンティティ・プロバイダおよびサービス・プロバイダのフェデレーテッド・パートナ間の信頼関係に基づいて実行する。オリジナル要求で受信されたユーザ・アイデンティティ情報は、実際のユーザ名値またはＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＮａｍｅＩｄｅｎｔｉｆｉｅｒなどのあいまいなデータ値とすることが可能であり、このユーザ・アイデンティティ情報は、何らかの後の時点でこのユーザの情報にアクセスされるユーザ・レジストリへのポインタとして使用することが可能であるか、または、たとえば一時情報を含むキャッシュへのポインタなど、永続データ記録が作成されるまで一時的に使用することができる。

オリジナルのシングル・サインオン要求がユーザに関する属性データを含む場合、ユーザに関するユーザ・アカウントをローカルに作成する際に、属性情報をユーザ・レジストリに直接追加することができる。しかしながら、オリジナルに受け取られた要求は、必ずしも、ユーザに関するユーザ・アカウントを作成するためにローカルに必要なすべての情報を含むとは限らない。この場合、シングル・サインオン・プロトコル・サービス（ＳＰＳ） ３５４または７１６と協働しているＩ＆ＡＳ ３５６または７１８は、ＳＡＭＬ属性照会および／またはＷＳ−ＡｔｔｒｉｂｕｔｅＳｅｒｖｉｃｅ要求などの属性照会を、ユーザに関する追加情報を取り出すために、ユーザのアイデンティティ・プロバイダに発行することができる。結果として、サービス・プロバイダは、ランタイムで、すなわち、シングル・サインオン・オペレーションが中断されている間か、または他の時間的視点からすると、ングル・サインオン・オペレーションと同時に、またはこれの一部として、ユーザに関するユーザ・アカウントを作成することができる。

サービス・プロバイダによるこの種のランタイム・リンク済みユーザ・アカウント作成オペレーションに対応する信頼のレベルは、変更される可能性があり、必ずしもすべてのサービス・プロバイダが、完全に自動化された、動的に決定される、リンク済みユーザ・アカウント作成オペレーションを可能にしたいとは限らない。したがって、場合によっては、サービス・プロバイダは、たとえばあるタイプのローカル管理承認プロセスなどのローカル・ワークフロー・オペレーションが実行されなければならない必要がある。完全に自動化されたプロセスでは、ユーザに関するユーザ・アカウントを直接作成するのではなく、フェデレーテッド・ユーザ・ライフサイクル管理（ＦＵＬＭ）アプリケーション／サービス３５２または７０８が、追加の帯域外取出しユーザ属性を含むユーザ情報を、何らかのローカル・データストアの形に格納し、次にこれがローカル・ワークフロー／承認プロセスをトリガできる場合がある。この要件により、サービス・プロバイダの管理者ユーザは、ローカル・ポリシー要件などに従って、ユーザ・アカウントの作成を承認することができる。結果として、ランタイム・ユーザ・アカウント作成オペレーションは非同期とすることが可能であり、この場合、サービス・プロバイダは、サービス・プロバイダのユーザ用にアカウントが作成されていることを示すために、および、何らかの後の時点でサービス・プロバイダでのログイン・オペレーションを実行するようにユーザが試行できることを示すために、ユーザにメッセージを送信することができる。ユーザをＩ＆ＡＳアクセス可能ユーザ・レジストリ以外に追加する必要がある場合、ＦＵＬＭサービス３５２または７０８は、この情報をローカル・データストアに送信し、ここからローカル・ユーザ・アカウント作成プロセスを開始することが可能であり、この場合アカウント／記録は、ローカルＩ＆ＡＳアクセス可能データストアに加えて、複数の宛先でユーザに関して作成することができる。サービス・プロバイダはユーザに、限られた時間、限られたアクセス・セッションを認めるように選択し、それによって、たとえばより広範なアクセスを承認するための何らかのタイプのワークフロー・プロセスの完了、またはユーザに与えるべき権限に関して後に何らかの決定が行われるまでなど、後の何らかのイベントまで、リソースの完全なセットではなく、アクセス可能リソースのサブセットにユーザを制限することが可能であり、その後、ユーザ・アカウントは適切なレベルのリソースへのアクセスを伴って作成されることになることに留意されたい。

次に図１９を参照すると、本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図が示される。図１９〜図２２に示されるプロセスは、主にシングル・サインオン・オペレーションの開始という観点から、図１３〜図１４に示されるプロセスとは異なり、図１３〜図１４に示されるプロセスがアイデンティティ・プロバイダによって開始されるのに対して、図１９〜図２２に示されるプロセスはサービス・プロバイダによって開始される。

次に図１９を参照すると、プロセスは、サービス・プロバイダによってホストされるユーザ・ブラウジング公開リソース、すなわち、リソースにアクセスする前にユーザに関して認証オペレーションを必要とする、保護されたリソースではないリソースで、開始される（ステップ１１０２）。その後の何らかの時点に、ユーザのクライアントは、認証オペレーションを必要とする保護されたリソースへのアクセスについての要求を、サービス・プロバイダに送信する（ステップ１１０４）。サービス・プロバイダは、ユーザの好ましいアイデンティティ・プロバイダに関する識別子を有していないことを認識し、サービス・プロバイダは、たとえばウェブ・ページのユーザ選択可能コントロールを介して、ユーザに何らかの方法で情報を提供するようにプロンプトを出す（ステップ１１０６）。次にクライアントは、ユーザによって選択された好ましいアイデンティティ・プロバイダに関する適切な情報をサービス・プロバイダに送信する（ステップ１１０８）。

次にサービス・プロバイダは、プル・タイプのシングル・サインオン要求を構築する（ステップ１１１０）。この例では、サービス・プロバイダは、たとえば、アイデンティティ・プロバイダがユーザに関する何らかのタイプのフェデレーテッド別名識別子を維持すると想定することによって、ユーザがフェデレーテッド・ユーザであると想定する。サービス・プロバイダは、たとえばＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形で、シングル・サインオン要求をクライアントに送信する（ステップ１１１２）。サービス・プロバイダからのリダイレクト・メッセージの受け取りに応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるアイデンティティ・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ１１１４）。

プル・タイプのシングル・サインオン要求の受け取りに応答して、アイデンティティ・プロバイダは、必要であればクライアントのユーザに関して、クライアントとの認証オペレーションを実行し（ステップ１１１６）、たとえば、ユーザがすでにアイデンティティ・プロバイダでログオンしている場合、すなわち、ユーザがアイデンティティ・プロバイダですでにアクティブ・セッションを有する場合、認証オペレーションは必要でない場合がある。アイデンティティ・プロバイダは、受け取った要求を評価し（ステップ１１１８）、アイデンティティ・プロバイダは、サービス・プロバイダがフェデレーション要求の一部としてアイデンティティ・プロバイダにユーザ・アイデンティティを提供していないと決定する。さらにアイデンティティ・プロバイダが、ユーザがまだフェデレーテッド・アイデンティティを有していないと決定した場合、アイデンティティ・プロバイダは、たとえばユーザに関する別名識別子などの、ユーザに関するフェデレーテッド・アイデンティティを作成する（ステップ１１２０）。アイデンティティ・プロバイダは、新しく作成されたユーザに関するフェデレーテッド・アイデンティティを含み、オプションで、ユーザに関してアイデンティティ・プロバイダによって管理される追加のユーザ属性情報を含む、プル・タイプのシングル・サインオン応答を構築し（ステップ１１２２）、このプル・タイプのシングル・サインオン応答は、プッシュ・タイプのシングル・サインオン応答と同じデータ・フォーマット特性を有する場合と有さない場合がある。アイデンティティ・プロバイダは、たとえばＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形で、シングル・サインオン応答をクライアントに送信する（ステップ１１２４）。アイデンティティ・プロバイダからのリダイレクト・メッセージの受け取りに応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるサービス・プロバイダに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ１１２６）。

その後サービス・プロバイダは、たとえばユーザに関する新しく作成されたフェデレーテッド識別子の抽出などを含む可能性があり、ユーザに関する追加のユーザ属性情報の抽出も含む可能性のある、シングル・サインオン応答を処理する（ステップ１１２８）。次にサービス・プロバイダは、アイデンティティ・プロバイダによって提供されたフェデレーテッド識別子を備えたユーザに関する新しいリンク済みユーザ・アカウントを作成し（ステップ１１３０）、アイデンティティ・プロバイダがこうした情報を送信した場合、およびサービス・プロバイダが新しいユーザ・アカウントを作成する間にこの情報を必要とする場合、アイデンティティ・プロバイダからのユーザに関する何らかのユーザ属性情報の使用を伴う可能性もある。ユーザが新しく作成されたユーザ・アカウントに基づくアクティブ・セッションを有すると、その後サービス・プロバイダは、最初に要求された保護されたリソースへのアクセスを提供し（ステップ１１３２）、サービス・プロバイダは、保護されたリソースへのアクセスから導出された情報を含むＨＴＴＰ応答メッセージをクライアントに送信し（ステップ１１３４）、これによってプロセスは終了する。

次に図２０〜図２２を参照すると、本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・アイデンティティ・プロバイダからのユーザ属性情報の追加の取り出しによって、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図のセットが示される。図１９に示された方法と同様に、図２０は、サービス・プロバイダが選択されたアイデンティティ・プロバイダでのシングル・サインオン・オペレーションを要求する際に使用可能なプロセスを示し、図面内の同じ要素は同じ参照番号で識別される。しかしながら、図１９は、ステップ１１３０で一般化されたランタイム・ユーザ・アカウント作成オペレーションのみを示すが、図２０に示されたプロセスは、ランタイム・リンク済みユーザ・アカウント作成オペレーションに関して図１９に示されたプロセスとは異なり、図１９〜図２０のステップ１１５０〜１１６４へと続く。

次に図２０を参照すると、図１９に示されたプロセスとは異なり、サービス・プロバイダは新しいユーザ・アカウントを作成するように試みる（ステップ１１５０）が、シングル・サインオンでアイデンティティ・プロバイダによってサービス・プロバイダに提供されたフェデレーテッド・ユーザ・アイデンティティ情報に基づいて、サービス・プロバイダでの完全に適切なユーザ・アカウントの即時作成、または作成の即時完了は実行できない。言い換えれば、実施に応じて、サービス・プロバイダが、その時点でユーザ・アカウントの作成に失敗するかまたは作成できないと決定する、あるいはサービス・プロバイダが、限られた時間または限られたアクセス権限でユーザ・アカウントを作成する。したがってサービス・プロバイダは、シングル・サインオン・オペレーション中にサービス・プロバイダがユーザに関するリンク済みユーザ・アカウントをまだ有していないことを認識しながら、サービス・プロバイダがアイデンティティ・プロバイダからのユーザに関する追加の情報を必要とすることも認識するため、図２０のシングル・サインオン処理は異なる（ステップ１１５２）。とりわけ、サービス・プロバイダは、たとえばそのユーザ・レジストリまたはデータベース内に、サービス・プロバイダがユーザの適切な特権セットを決定できるだけの十分な情報を有しておらず、この情報なしでは、サービス・プロバイダはユーザに与えるセッション／アクセス制御権のタイプを決定することができない。

サービス・プロバイダがリンク済みユーザ・アカウント作成オペレーションを完了するために、追加のユーザ属性情報をアイデンティティ・プロバイダから収集する方法は変更が可能であり、その変更の２つの例が図２１のステップ１１５４〜１１６４または図２２のステップ１１７２〜１１７８にわたって示されている。図２１はフロント・チャネル属性取り出しオペレーションを示し、図２２はバック・チャネル属性取り出しオペレーションを示す。したがって、図２０に示されたデータ流れ図は、図２１または図２２のいずれかへと続き、どちらの場合も、図２１および図２２のデータ流れ図は同様のステップで終了する。図２１および図２２の両方で、サービス・プロバイダはステップ１１３２で、最初に要求された保護されたリソースへのアクセスを提供し、サービス・プロバイダは、ステップ１１３４で、保護されたリソースへのアクセスから導出された情報を含むＨＴＴＰ応答メッセージをクライアントに送信し、これによってプロセスが終了する。

次に図２１を参照すると、サービス・プロバイダは、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）をクライアントに送信することによって、そのユーザ属性情報の欠如の決定に応答し（ステップ１１５４）、サービス・プロバイダからのメッセージは、追加のユーザ属性情報に対する要求を含む。リダイレクト・メッセージは、以前にアイデンティティ・プロバイダによってサービス・プロバイダに提供された戻りＵＲＩを使用して、クライアントをアイデンティティ・プロバイダへとリダイレクトする。サービス・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、サービス・プロバイダからのＨＴＴＰリダイレクト・メッセージ内のＵＲＩによって示されるように、ＨＴＴＰ Ｇｅｔメッセージをアイデンティティ・プロバイダに送信する（ステップ１１５６）。次にアイデンティティ・プロバイダは、クライアントのユーザに関してアイデンティティ・プロバイダによって格納されたユーザ属性情報を含む応答を構築するために、受信したメッセージを処理する（ステップ１１５８）。特定のユーザ属性が識別される方法は、変更される場合がある。たとえば、アイデンティティ・プロバイダによって提供されるユーザ属性情報は、サービス・プロバイダによって明示的に要求されたユーザ属性情報を含むことができる。加えて、または代替方法として、アイデンティティ・プロバイダによって提供されるユーザ属性情報、すなわち、サービス・プロバイダでリンク済みユーザ・アカウント作成オペレーションを実行するために十分となるようにアイデンティティ・プロバイダによって決定されたユーザ属性情報は、サービス・プロバイダによって暗黙に要求されたユーザ属性情報を含むことができる。加えて、アイデンティティ・プロバイダは、サービス・プロバイダがそれを実行するための十分な理由なしにユーザ属性の取得を試みていないことを保証するために、サービス・プロバイダの以前のシングル・サインオン要求を使用して、追加のユーザ属性情報に関して受信した要求を調整するためのオペレーションを実行することができる。

アイデンティティ・プロバイダがステップ１１５８でメッセージを構築した後、アイデンティティ・プロバイダは、追加のユーザ属性と共に、たとえば、ＨＴＴＰリダイレクト・メッセージ（状況／理由コード「３０２」を伴うＨＴＴＰ応答メッセージ）の形でこのメッセージをクライアントに送信する（ステップ１１６０）。アイデンティティ・プロバイダからのリダイレクト・メッセージの受信に応答して、クライアントは、アイデンティティ・プロバイダからのＨＴＴＰリダイレクト・メッセージ内でＵＲＩによって示されたような、サービス・プロバイダの適切なサービスに、ＨＴＴＰ Ｇｅｔメッセージを送信する（ステップ１１６２）。

受信されたメッセージ内に追加のユーザ属性情報があるとすると、サービス・プロバイダは、受信したユーザ属性情報に基づいてサービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行または完了し（ステップ１１６４）、このように、サービス・プロバイダによってシングル・サインオン要求を満たすことが可能であり、さらにユーザ用のアクティブ・セッションも作成し、ステップ１１３２および１１３４で保護されたリソースへのアクセス要求を進めることができる。

次に図２２を参照すると、サービス・プロバイダは、ＳＯＡＰメッセージをサービス・プロバイダからアイデンティティ・プロバイダに直接送信することによって、そのユーザ属性情報の欠如の決定に応答し（ステップ１１７２）、サービス・プロバイダからのメッセージは、追加のユーザ属性情報に対する要求を含む。その後、アイデンティティ・プロバイダは、クライアントのユーザに関してアイデンティティ・プロバイダによって格納されたユーザ属性情報を含む応答を構築するために、受信したメッセージを処理し（ステップ１１７４）、ここでも、特定のユーザ属性が識別される方法は前述のように変更される場合がある。アイデンティティ・プロバイダは、ＳＯＡＰ応答メッセージを追加のユーザ属性と共にクライアントに送信する（ステップ１１７６）。受信したメッセージ内に追加のユーザ属性情報があるとすれば、サービス・プロバイダは、受信したユーザ属性情報に基づいて、サービス・プロバイダでのランタイム・ユーザ・アカウント作成オペレーションを実行または完了し（ステップ１１７８）、こうして、サービス・プロバイダによってシングル・サインオン要求を満たすことが可能であり、ユーザ用のアクティブ・セッションも作成し、ステップ１１３２およびステップ１１３４で、保護されたリソースにアクセスするための要求を進めることができる。

結論
本発明の利点は、前述の本発明の詳細な説明に鑑みて明らかとなろう。アイデンティティ・プロバイダが、サービス・プロバイダによってホストされる制御されたリソースへのアクセスを得るために、サービス・プロバイダでユーザに代わってシングル・サインオン・オペレーションの開始を試みる場合、サービス・プロバイダは、受信した要求内のユーザ識別子または他のユーザ・アイデンティティ情報を認識しない場合がある。従来技術では、このシナリオではエラーが生成されることになっていた。

本発明を使用すると、サービス・プロバイダはリンク済みユーザ・アカウント作成オペレーションをシングル・サインオン・オペレーションの一部として動的に実行することができる。必要であれば、サービス・プロバイダは、サービス・プロバイダのアイデンティティ管理機能によってローカルに必要とされるように、ユーザに関する必要なユーザ属性を取得するために、追加のユーザ属性情報をアイデンティティ・プロバイダから収集することができる。

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

方法は一般に、望ましい結果につながる、首尾一貫したシーケンスのステップとなるように想起される。これらのステップは、物理量の物理的操作を必要とする。通常、これらの量は、格納、転送、組み合わせ、比較、およびその他の操作が可能な電気または磁気信号の形を取るが、必ずしもこれらに限らない。時には、主に一般的に使用するという理由で、これらの信号をビット、値、パラメータ、アイテム、要素、オブジェクト、記号、文字、用語、数などとして言い表すことが便利である。しかしながら、これらの用語および同様の用語はすべて、適切な物理量に関連付けられ、これらの量に適用される単なる便利なラベルであることに留意されたい。

以上、本発明について例示の目的で説明してきたが、開示された諸実施形態を網羅するかまたはこれらに限定されることは意図しない。当業者であれば、多くの修正および変形形態が明らかとなろう。諸実施形態は、本発明の原理およびその実際の応用例を説明するため、ならびに、当業者が本発明を理解し、他の企図された用途に好適であると思われる様々な修正形態を使用して、様々な諸実施形態を実施するために選択されたものである。

それぞれが本発明を実施可能な、データ処理システムの典型的なネットワークを示す図である。 本発明が実施可能なデータ処理システム内で使用可能な、典型的なコンピュータ・アーキテクチャを示す図である。 クライアントがサーバでの保護されたリソースにアクセスする場合に使用可能な、典型的な認証プロセスを示すデータ流れ図である。 本発明が実施可能な典型的なウェブ・ベース環境を示す、ネットワーク図である。 ユーザからの複数の認証オペレーションを必要とする可能性がある、典型的なオンライン・トランザクションの一例を示すブロック図である。 フェデレーテッド環境内のダウンストリーム・エンティティでのアクションを応答して呼び出す、第１のフェデレートされた企業に対して、ユーザによって開始されたトランザクションに関して、フェデレーテッド環境の用語を示すブロック図である。 本発明の実施形態をサポートするために使用可能ないくつかのフェデレーテッド・アーキテクチャ構成要素を備えた、所与のドメインでの既存のデータ処理システムの統合を示すブロック図である。 本発明の実施をサポートするための信頼関係を確立するために、フェデレーテッド・アーキテクチャ内のいくつかの構成要素が使用可能な一例を示す、ブロック図である。 本発明をサポート可能な例示的フェデレーテッド・アーキテクチャに従った、信頼プロキシおよび信頼ブローカを使用するフェデレーテッド・ドメイン間の信頼関係の例示的セットを示す、ブロック図である。 フェデレーテッド・シングル・サインオン・オペレーションをサポートする、フェデレーテッド環境を示すブロック図である。 本発明をサポートするためにフェデレーテッド・ユーザ・ライフサイクル管理機能を実施するための、フェデレーテッド・ドメイン内のいくつかの構成要素を示すブロック図である。 フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、典型的な従来技術のＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダ側でランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダ側でランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダによるユーザ属性を取得するための代替方法を使用して、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダによるユーザ属性を取得するための代替方法を使用して、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダによるユーザ属性を取得するための代替方法を使用して、フェデレーテッド・サービス・プロバイダでの保護されたリソースへのアクセスを取得するために、フェデレーテッド・アイデンティティ・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのシングル・サインオン・オペレーションを示す、データ流れ図である。 アイデンティティ・プロバイダによって開始されたシングル・サインオン・オペレーション中に、サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行するための、より詳細なプロセスを示す流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・アイデンティティ・プロバイダからのユーザ属性情報の追加の取り出しによって、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・アイデンティティ・プロバイダからのユーザ属性情報の追加の取り出しによって、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図である。 本発明の実施形態に従って、フェデレーテッド・サービス・プロバイダでランタイム・リンク済みユーザ・アカウント作成オペレーションを実行する間に、フェデレーテッド・アイデンティティ・プロバイダからのユーザ属性情報の追加の取り出しによって、フェデレーテッド・サービス・プロバイダでの保護されたリソースにアクセスできるようにするために、フェデレーテッド・サービス・プロバイダによって開始される、ＨＴＴＰリダイレクト・ベースのプル・タイプのシングル・サインオン・オペレーションを示す、データ流れ図である。

Claims (21)

1. 第１のシステムおよび第２のシステムがフェデレーテッド・コンピューティング環境内で対話し、保護されたリソースへのアクセスを提供するためにシングル・サインオン・オペレーションをサポートする、分散データ処理システム内でユーザ認証を管理するための方法であって、
   前記第２のシステムによってホストされる保護されたリソースへのアクセスを取得するために、ユーザに代わってシングル・サインオン・オペレーションをトリガするステップであって、前記第２のシステムが、前記保護されたリソースへのアクセスを提供する前に、シングル・サインオン・オペレーションを完了するために、前記ユーザに関するユーザ・アカウントを必要とする、トリガするステップと、
   前記第２のシステムで、前記ユーザに関連付けられた識別子を第１のシステムから受け取るステップと、
   前記シングル・サインオン・オペレーションをトリガするステップの後であるが、前記保護されたリソースへのアクセスに応答して前記第２のシステムで生成するステップの前に、前記ユーザに関連付けられた前記受け取った識別子に少なくとも部分的に基づいて、前記第２のシステムで前記ユーザに関するユーザ・アカウントを作成するステップであって、前記作成されたユーザ・アカウントが、前記ユーザに代わって、前記第１のシステムと前記第２のシステムとの間のシングル・サインオン・オペレーションをサポートする、作成するステップと、を有する、
   方法。
2. 前記シングル・サインオン・オペレーションをトリガするステップの後に、前記第１のシステムで前記ユーザに関する別名識別子を作成するステップをさらに有する、請求項１に記載の方法。
3. 前記第２のシステムで前記ユーザに対して前記シングル・サインオン・オペレーションをトリガするために、前記第１のシステムから前記第２のシステムへと前記ユーザに関する認証情報を収集するために、前記第２のシステムから前記第１のシステムへとメッセージを送信するステップをさらに有する、請求項１または請求項２に記載の方法。
4. 前記第２のシステムで前記ユーザに対して前記シングル・サインオン・オペレーションをトリガするために、前記第１のシステムから前記第２のシステムへと前記ユーザに関する認証情報をプッシュするために、前記第１のシステムから前記第２のシステムへとメッセージを受け取るステップをさらに有する、前記請求項のいずれか１項に記載の方法。
5. 前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムが十分なユーザ属性情報を有していないという、前記第２のシステムでの決定に応答して、前記第２のシステムから前記第１のシステムへユーザ属性情報を取り出すための要求メッセージを送信するステップと、
   前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムによって採用されるユーザ属性情報を含む応答メッセージを、前記第２のシステムで前記第１のシステムから受け取るステップと、
   をさらに有する、前記請求項のいずれか１項に記載の方法。
6. 前記ユーザに関するユーザ属性情報を取り出すステップの前に、前記ユーザに関する前記ユーザ・アカウントの作成を開始するために、予備のユーザ・アカウント作成オペレーションを実行するステップと、
   前記ユーザに関するユーザ属性情報を取り出すステップの後に、前記ユーザに関する前記ユーザ・アカウントの作成を完了するために、結びのユーザ・アカウント作成オペレーションを実行するステップと、
   をさらに有する、請求項５に記載の方法。
7. 前記第１のシステムによって、第４のシステムからユーザ属性情報を取り出すステップをさらに有する、請求項５または請求項６に記載の方法。
8. 前記第１のシステムがアイデンティティ・プロバイダをサポートし、前記第２のシステムがサービス・プロバイダをサポートする、前記請求項のいずれか１項に記載の方法。
9. 前記ユーザに関連付けられた識別子を受け取るステップの前に、前記アイデンティティ・プロバイダに対して識別子を提供または選択するために、前記サービス・プロバイダによって前記ユーザにプロンプトを出すステップをさらに有する、請求項８に記載の方法。
10. 前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムが十分なユーザ属性情報を有していないという、前記第２のシステムでの決定に応答して、前記第４のシステムへユーザ属性情報を取り出すための要求メッセージを送信するステップと、
    前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムによって採用されるユーザ属性情報を含む応答メッセージを、前記第２のシステムで前記第４のシステムから受け取るステップと、
    をさらに有する、前記請求項のいずれか１項に記載の方法。
11. 第１のシステムおよび第２のシステムがフェデレーテッド・コンピューティング環境内で対話し、保護されたリソースへのアクセスを提供するためにシングル・サインオン・オペレーションをサポートする、データ処理システム内でユーザ認証を管理するための装置であって、
    前記第２のシステムによってホストされる保護されたリソースへのアクセスを取得するために、ユーザに代わってシングル・サインオン・オペレーションをトリガするための手段であって、前記第２のシステムが、前記保護されたリソースへのアクセスを提供する前に、シングル・サインオン・オペレーションを完了するために、前記ユーザに関するユーザ・アカウントを必要とする、トリガするための手段と、
    前記第２のシステムで、前記ユーザに関連付けられた識別子を第１のシステムから受け取るための手段と、
    前記シングル・サインオン・オペレーションをトリガする後であるが、前記保護されたリソースへのアクセスに応答して前記第２のシステムで生成する前に、前記ユーザに関連付けられた前記受け取った識別子に少なくとも部分的に基づいて、前記第２のシステムで前記ユーザに関するユーザ・アカウントを作成するための手段であって、前記作成されたユーザ・アカウントが、前記ユーザに代わって、前記第１のシステムと前記第２のシステムとの間のシングル・サインオン・オペレーションをサポートする、作成するための手段と、
    を有する、装置。
12. 前記シングル・サインオン・オペレーションをトリガする後に、前記第１のシステムで前記ユーザに関する別名識別子を作成するための手段をさらに有する、請求項１１に記載の装置。
13. 前記第２のシステムで前記ユーザに対して前記シングル・サインオン・オペレーションをトリガするために、前記第１のシステムから前記第２のシステムへと前記ユーザに関する認証情報を収集するために、前記第２のシステムから前記第１のシステムへとメッセージを送信するための手段をさらに有する、請求項１１または請求項１２に記載の装置。
14. 前記第２のシステムで前記ユーザに対して前記シングル・サインオン・オペレーションをトリガするために、前記第１のシステムから前記第２のシステムへと前記ユーザに関する認証情報をプッシュするために、前記第１のシステムから前記第２のシステムへとメッセージを受け取るための手段をさらに有する、前記請求項１１から請求項１３のいずれか１項に記載の装置。
15. 前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムが十分なユーザ属性情報を有していないという、前記第２のシステムでの決定に応答して、前記第２のシステムから前記第１のシステムへユーザ属性情報を取り出すための要求メッセージを送信するための手段と、
    前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムによって採用されるユーザ属性情報を含む応答メッセージを、前記第２のシステムで前記第１のシステムから受け取るための手段と、
    をさらに有する、前記請求項１１から請求項１４のいずれか１項に記載の装置。
16. 前記ユーザに関するユーザ属性情報を取り出す前に、前記ユーザに関する前記ユーザ・アカウントの作成を開始するために、予備のユーザ・アカウント作成オペレーションを実行するための手段と、
    前記ユーザに関するユーザ属性情報を取り出す後に、前記ユーザに関する前記ユーザ・アカウントの作成を完了するために、結びのユーザ・アカウント作成オペレーションを実行するための手段と、
    をさらに有する、請求項１５に記載の装置。
17. 前記第１のシステムによって、第４のシステムからユーザ属性情報を取り出すための手段をさらに有する、請求項１５または請求項１６に記載の装置。
18. 前記第１のシステムがアイデンティティ・プロバイダをサポートし、前記第２のシステムがサービス・プロバイダをサポートする、前記請求項１１から請求項１７のいずれか１項に記載の装置。
19. 前記ユーザに関連付けられた識別子を受け取る前に、前記アイデンティティ・プロバイダに対して識別子を提供または選択するために、前記サービス・プロバイダによって前記ユーザにプロンプトを出すための手段をさらに有する、請求項１８に記載の装置。
20. 前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムが十分なユーザ属性情報を有していないという、前記第２のシステムでの決定に応答して、前記第４のシステムへユーザ属性情報を取り出すための要求メッセージを送信するための手段と、
    前記第２のシステムで前記ユーザに関するユーザ・アカウントの作成を完了するために、前記第２のシステムによって採用されるユーザ属性情報を含む応答メッセージを、前記第２のシステムで前記第４のシステムから受け取るための手段と、
    をさらに有する、前記請求項１１から請求項１９のいずれか１項に記載の装置。
21. プログラムがコンピュータ上で実行される場合、前記請求項１から請求項１０のいずれか１項のすべてのステップを実行するように適合された、プログラム・コード手段を有する、コンピュータ・プログラム。

Images