JP4832822B2 - データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム） - Google Patents

データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム） Download PDF

Info

Publication number
JP4832822B2
JP4832822B2 JP2005210414A JP2005210414A JP4832822B2 JP 4832822 B2 JP4832822 B2 JP 4832822B2 JP 2005210414 A JP2005210414 A JP 2005210414A JP 2005210414 A JP2005210414 A JP 2005210414A JP 4832822 B2 JP4832822 B2 JP 4832822B2
Authority
JP
Japan
Prior art keywords
federated
user
trust
domain
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005210414A
Other languages
English (en)
Other versions
JP2006031714A (ja
Inventor
ヘザー・マリア・ヒントン
ドラポ・マーティン・ファロラ
アンソニー・スコット・モラン
パトリック・リャン・ワードップ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2006031714A publication Critical patent/JP2006031714A/ja
Application granted granted Critical
Publication of JP4832822B2 publication Critical patent/JP4832822B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Description

本発明は、改良されたデータ処理システムに関し、具体的には、マルチコンピュータ・データ転送の方法および装置に関する。さらに具体的には、本発明は、ネットワーク化されたコンピュータ・システムを対象とする。
本願は、本願と同一の譲受人に譲渡された次の特許出願に関連する。
米国特許出願第１０／８９６３５３号明細書（弁理士整理番号第ＡＵＳ９２００４０３６３ＵＳ)号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR PLUGGABILITY OFFEDERATION PROTOCOL RUNTIMES FOR FEDERATED USER LIFECYCLE MANAGEMENT」、
米国特許出願第１０／８９６３１６号明細書（弁理士整理番号第ＡＵＳ９２００４０３６４ＵＳ１号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR ENABLING FEDERATED USER LIFECYCLE MANAGEMENT」、
米国特許出願第１０／８９６２８５号明細書（弁理士整理番号第ＡＵＳ９２００４０４１９ＵＳ１号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR ESTABLISHING FEDERATION RELATIONSHIPS THROUGHIMPORTED CONFIGURATION FILES」。
企業は、一般に、インターネットを含むさまざまなネットワークを介して、許可されたユーザに、ユーザフレンドリな形で保護されたリソースへのセキュア・アクセスを提供することを望む。セキュア認証機構を提供することによって、保護されたリソースへの許可されたにアクセスの危険性が減るが、これらの認証機構は、保護されたリソースへのアクセスに対する障壁になる可能性がある。ユーザは、一般に、アプリケーションをサポートする各特定のシステムを保護する認証障壁にかまわずに、あるアプリケーションとの対話から別のアプリケーショとの対話に切り替える能力を望む。
ユーザは、洗練されてくるにつれて、コンピュータ・システムがユーザのアクションを調整し、その結果、ユーザに対する重荷が減らされることを期待する。このタイプの期待は、認証処理にも適用される。ユーザは、あるコンピュータ・システムによって認証されたならば、ユーザにほとんど不可視のさまざまなコンピュータ・アーキテクチャ境界にかまわずに、その認証が、そのユーザの作業セッション全体を通じて有効であるか、少なくとも特定の時間期間の間だけ有効であると仮定する場合がある。企業は、一般に、ユーザ効率が従業員の生産性または顧客満足度のどちらに関係する場合であっても、ユーザを懐柔するだけではなくユーザ効率を高めるために、展開されたシステムの動作特性でこれらの期待を満足しようとする。
具体的に言うと、多数のアプリケーションが、共通のブラウザを介してアクセス可能なウェブベース・ユーザ・インターフェースを有する現在のコンピューティング環境で、ユーザは、よりユーザフレンドリであることと、あるウェブベース・アプリケーションから別のウェブベース・アプリケーションへの移動に対する低いまたは頻繁でない障壁を期待する。これに関して、ユーザは、各特定のドメインを保護する認証障壁にかまわずに、あるインターネット・ドメイン上のアプリケーションとの対話から別のドメインの別のアプリケーションとの対話にジャンプする能力を期待するようになっている。しかし、多数のシステムが、使い易いウェブベース・インターフェースを介するセキュア認証を提供しているが、ユーザは、まだ、１組のドメインにまたがるユーザ・アクセスを妨害する複数の認証処理を処理することを強制される可能性がある。ユーザを所与の時間枠内で複数の認証処理にさらすことは、ユーザの効率に大きく影響する可能性がある。
たとえば、ユーザおよびコンピュータ・システム管理者に対する認証の重荷を減らすためにさまざまな技法が使用されてきた。これらの技法を、一般に、「シングルサインオン」（ＳＳＯ）処理と称する。というのは、これらが、ユーザがサインオン動作を完了した後すなわち認証された後に、そのユーザが、その後、別の認証動作を実行する必要がなくなるという共通の目的を有するからである。したがって、目標は、特定のユーザ・セッション中に、ユーザが１つの認証処理だけを完了することを要求されることである。
ユーザ管理のコストを減らし、企業の間のインターオペラビリティを改善するために、連合コンピューティング・スペース（federated computing space）が作成された。連合（federation）は、インターオペラビリティのある標準規格を厳守する企業の疎結合提携であり、連合は、連合内のユーザに関するある計算動作に関するこれらの企業間の信頼の機構を提供する。たとえば、連合パートナは、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダ（identityprovider）として働くことができる。同一の連合内の他のパートナは、ユーザのアイデンティティ・プロバイダによって提供されるシングルサインオン・トークンを受け入れるなど、ユーザ認証信任証の主な管理についてユーザのアイデンティティ・プロバイダに頼ることができる。
企業が、連合ビジネス対話をサポートするために動く時に、これらの企業は、２つの会社の間の高められた協力を反映するユーザ経験を提供しなければならない。上で注記したように、ユーザは、アイデンティティ・プロバイダとして働く１つの当事者に対して認証し、その後、サービス・プロバイダとして働く連合したビジネス・パートナにシングルサインオンすることができる。このシングルサインオン機能性と共に、アカウント・リンク／リンク解除およびシングルサインオフなどの追加のユーザ・ライフサイクル機能性も、特にこの連合ユーザ・ライフサイクル管理（ＦＵＬＭ）機能性が各当事者のインフラストラクチャの変更を必要としない形で、サポートされなければならない。
現在のコンピューティング環境は、シングルサインオン機能性を提供することだけによって、または独自プロトコルを使用することによって、連合ユーザ・ライフサイクル管理機能性の問題を解決している。しかし、これらの解決策は、「疎結合」環境すなわち、どちらの側の環境も変更せずに、新しいパートナをオンラインにするか、古いパートナをコンピューティング環境から除去することが簡単である環境を可能にするようにスケーリングされない。さらに、これらの以前の解決策は、単一のエンティティが複数の役割を引き受けること、たとえば、ある会社が、あるパートナについてアイデンティティ・プロバイダとして働き、その後、別のパートナについてサービス・プロバイダとして働けることを、許容しない。これらの従来技術の解決策は、各パートナが個別に管理される、明示的なパートナ対パートナ解決策であり、この手法のスケーラビリティが、大規模な採用を妨げてきた。
米国特許出願第１０／８９６３５３号明細書（弁理士整理番号第ＡＵＳ９２００４０３６３ＵＳ)号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR PLUGGABILITY OFFEDERATION PROTOCOL RUNTIMES FOR FEDERATED USER LIFECYCLE MANAGEMENT」 米国特許出願第１０／８９６３１６号明細書（弁理士整理番号第ＡＵＳ９２００４０３６４ＵＳ１号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR ENABLING FEDERATED USER LIFECYCLE MANAGEMENT」 米国特許出願第１０／８９６２８５号明細書（弁理士整理番号第ＡＵＳ９２００４０４１９ＵＳ１号）、出願日２００４年７月２１日、名称「METHOD AND SYSTEM FOR ESTABLISHING FEDERATION RELATIONSHIPS THROUGHIMPORTED CONFIGURATION FILES」 コール（Kohl）他、「ケルベロス・ネットワーク認証サービス（Ｖ５）（TheKerberos Network Authentication Service (V5)）」、インターネット・エンジニアリング・タスク・フォース（InternetEngineering Task Force、IETF）コメント要求（Request for Comments、RFC）１５１０、１９９３年９月 「ＯＡＳＩＳセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）のアサーションおよびプロトコル（Assertions and Protocol for the OASIS Security Assertion MarkupLanguage (SAML)）」、委員会仕様０１、２００２年５月３１日
したがって、信頼（trust）関係（およびその信頼関係の管理）と、連合ユーザ・ライフサイクル管理機能性解決策を提供するのに必要な機能性の分離を可能にする方法およびシステムを有することが有利である。
連合コンピューティング環境内の異なる企業のコンピューティング環境が対話する方法およびシステムを提示する。連合動作は、異なる連合コンピューティング環境のユーザの代わりに、連合パートナのコンピューティング環境で開始することができる。接触点（point-of-contact）サービスが、信頼サービスに頼って、コンピューティング環境と連合パートナのコンピューティング環境の間の信頼関係を管理する。信頼サービスは、鍵管理サービス、アイデンティティ／属性サービス、およびセキュリティ・トークン・サービスを使用する。連合ユーザ・ライフサイクル管理サービスは、連合ユーザ・ライフサイクル機能を実装し、接触点サービスおよび信頼サービスと対話する。鍵管理サービスは、ドメインとの通信を保護するのに使用される暗号鍵を管理する。アイデンティティ／属性サービスは、ドメインで処理されるセキュリティ・トークンに含まれるアイデンティティまたは属性あるいはその両方を管理する。セキュリティ・トークン・サービスは、ドメインから送信されるセキュリティ・トークンまたはセキュリティ・アサーションを生成し、ドメインで受信されたセキュリティ・トークンまたはセキュリティ・アサーションを有効化する。連合ユーザ・ライフサイクル管理サービスは、信頼サービスとインターフェースし、信頼サービスが、鍵管理サービスとインターフェースする手段、アイデンティティ／属性サービスとインターフェースする手段、およびセキュリティ・トークン・サービスとインターフェースする手段の詳細を、連合ユーザ・ライフサイクル管理サービスから隠蔽するようになっている。
本発明に特有と思われる新規の特徴を、請求項に示す。本発明自体、そのさらなる目的、および利益は、添付図面と共に読まれる時に、次の詳細な説明を参照することによって最もよく理解される。
一般に、本発明を含むか本発明に関係するデバイスに、さまざまなデータ処理技術が含まれる。したがって、背景として、分散データ処理システム内のハードウェア構成要素およびソフトウェア構成要素の通常の編成を、本発明の詳細な説明の前に説明する。
図面を参照すると、図１に、それぞれが本発明を実施できるデータ処理システムの通常のネットワークが示されている。分散データ処理システム１００に、ネットワーク１０１が含まれ、このネットワーク１０１は、分散データ処理システム１００内で一緒に接続されたさまざまなデバイスおよびコンピュータの間の通信リンクを提供するのに使用できる媒体である。ネットワーク１０１に、ワイヤまたは光ファイバ・ケーブルなどの永久的接続と、電話または無線通信を介して作られる一時的接続を含めることができる。図示の例では、サーバ１０２およびサーバ１０３が、記憶装置１０４と共にネットワーク１０１に接続されている。さらに、クライアント１０５から１０７も、ネットワーク１０１に接続されている。クライアント１０５から１０７およびサーバ１０２から１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）などのさまざまなコンピューティング・デバイスによって表すことができる。分散データ処理システム１００に、図示されていない、追加のサーバ、クライアント、ルータ、他のデバイス、およびピアツーピア・アーキテクチャを含めることができる。
図示の例では、分散データ処理システム１００に、インターネットを含めることができ、ネットワーク１０１は、ＬＤＡＰ（Lightweight Directory Access Protocol）、ＴＣＰ／ＩＰ（転送制御プロトコル／インターネット・プロトコル）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）などのさまざまなプロトコルを使用して互いに通信するネットワークの全世界の集合を表す。もちろん、分散データ処理システム１００に、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、または広域ネットワーク（ＷＡＮ）などの多数の異なるタイプのネットワークも含めることができる。たとえば、サーバ１０２は、クライアント１０９およびネットワーク１１０を直接にサポートし、このネットワーク１１０には、無線通信リンクが組み込まれている。ネットワーク対応電話機１１１が、無線リンク１１２を介してネットワーク１１０に接続され、ＰＤＡ １１３が、無線リンク１１４を介してネットワーク１１０に接続される。電話機１１１およびＰＤＡ １１３は、Ｂｌｕｅｔｏｏｔｈ（商標）無線技術などの適当な技術を使用することによって無線リンク１１５を介してそれら自体の間で直接にデータを転送して、いわゆるパーソナル・エリア・ネットワークまたはパーソナル・アドホック・ネットワークを作成することもできる。類似する形で、ＰＤＡ １１３が、無線通信リンク１１６を介してＰＤＡ １０７にデータを転送することができる。
本発明は、さまざまなハードウェア・プラットフォームおよびソフトウェア・プラットフォームで実施することができる。図１は、異種コンピューティング環境の例であることを意図されたものであり、本発明に関するアーキテクチャ的制限として意図されたものではない。
図２を参照すると、図に、本発明を実施できる、図１に示されたものなどのデータ処理システム内の通常のコンピュータ・アーキテクチャが示されている。データ処理システム１２０に、内部システム・バス１２３に接続された１つまたは複数の中央処理装置（ＣＰＵ）１２２が含まれ、内部システム・バス１２３は、ランダム・アクセス・メモリ（ＲＡＭ）１２４、読取専用メモリ１２６、および入出力アダプタ１２８を相互接続し、入出力アダプタ１２８は、プリンタ１３０、ディスク装置１３２、またはオーディオ出力システムなどの図示されていない他のデバイスなどのさまざまな入出力デバイスをサポートする。システム・バス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４にも接続される。ユーザ・インターフェース・アダプタ１４８が、キーボード１４０およびマウス１４２、またはタッチ・スクリーン、スタイラス、マイクロホンなどの図示されていない他のデバイスなどのさまざまなユーザ・デバイスに接続される。ディスプレイ・アダプタ１４４が、システム・バス１２３を表示デバイス１４６に接続する。
当業者は、システム実施形態に応じて、図２のハードウェアを変更できることを諒解するであろう。たとえば、このシステムは、Ｉｎｔｅｌ（Ｒ）Ｐｅｎｔｉｕｍ（Ｒ）ベース・プロセッサおよびディジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性および不揮発性のメモリとを有することができる。他の周辺デバイスを、図２に示されたハードウェアに追加してまたはその代わりに使用することができる。図示の例は、本発明に関するアーキテクチャ的制限を暗示することを意図されたものではない。
さまざまなハードウェア・プラットフォームで実施できることに加えて、本発明は、さまざまなソフトウェア環境で実施することができる。通常のオペレーティング・システムを使用して、各データ処理システムでのプログラム実行を制御することができる。たとえば、あるデバイスが、Ｕｎｉｘ（Ｒ）オペレーティング・システムを稼動させることができ、別のデバイスに、単純なＪａｖａ（Ｒ）ランタイム環境を含めることができる。代表的なコンピュータ・プラットフォームに、ブラウザを含めることができ、ブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、拡張マークアップ言語（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ＨＤＭＬ（Handheld Device Markup Language）、ＷＭＬ（Wireless Markup Language）、およびさまざまな他のフォーマットおよびタイプのファイルなど、さまざまなフォーマットのハイパーテキスト文書にアクセスする周知のソフトウェア・アプリケーションである。図１に示された分散データ処理システムが、さまざまなピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできることが企図されていることにも留意されたい。
図３を参照すると、データ・フロー図に、クライアントがサーバの保護されたリソースへのアクセスを試みる時に使用できる通常の認証処理が示されている。図からわかるように、クライアント・ワークステーション１５０のユーザが、コンピュータ・ネットワークを介し、クライアント・ワークステーションで実行中のユーザのウェブ・ブラウザを介してサーバ１５１の保護されたリソースへのアクセスを求める。保護されたリソースまたは制御されたリソースは、アクセスが制御されるか制限されるリソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプリソースなど）である。保護されたリソースは、認証されたユーザまたは許可されたユーザあるいはその両方によってのみアクセスできる、ＵＲＬ（Uniform Resource Locator）またはより一般的にＵＲＩ（Uniform Resource Identifier）によって識別される。コンピュータ・ネットワークは、図１または図２に示されているように、インターネット、イントラネット、または他のネットワークとすることができ、サーバは、ウェブ・アプリケーション・サーバ（ＷＡＳ）、サーバ・アプリケーション、サーブレット・プロセス、または類似物とすることができる。
この処理は、ユーザが、ドメイン“ibm.com”内のウェブ・ページなどのサーバ側の保護されたリソースを要求する時に開始される（ステップ１５２）。用語「サーバ側」および「クライアント側」は、それぞれ、ネットワーク化された環境内の、サーバまたはクライアントでのアクションまたはエンティティを指す。ウェブ・ブラウザ（または関連するアプリケーションもしくはアプレット）は、ＨＴＴＰ要求を生成し（ステップ１５３）、このＨＴＴＰ要求が、ドメイン“ibm.com”をホスティングするウェブ・サーバに送信される。用語「要求」および「応答」は、メッセージ、通信プロトコル情報、または他の関連する情報など、特定の動作に用いられる情報の転送に適当なデータ・フォーマッティングを含むものして理解されなければならない。
サーバは、そのクライアントに関するアクティブ・セッションを有しないことを判定し（ステップ１５４）、したがって、サーバは、サーバとクライアントの間のＳＳＬ（Secure Sockets Layer）セッションの確立を開始し、完了する（ステップ１５５）が、これには、クライアントとサーバの間での複数の情報転送が含まれる。ＳＳＬセッションを確立した後に、後続の通信メッセージが、ＳＳＬセッション内で転送され；ＳＳＬセッション内の暗号化された通信メッセージのゆえに、秘密情報が秘密のままになる。
しかし、サーバは、ユーザが保護されたリソースへのアクセスを有することを許可する前に、ユーザのアイデンティティを判定する必要があり、したがって、サーバは、クライアントにあるタイプの認証チャレンジを送信する（ステップ１５６）ことによって、認証処理を実行するようにユーザに要求する。認証チャレンジは、ＨＴＭＬフォームなど、さまざまなフォーマットとすることができる。次に、ユーザが、ユーザ名または他のタイプのユーザ識別子と、それに関連するパスワードまたは他の形の秘密情報など、要求された情報または必要な情報を供給する（ステップ１５７）。
認証応答情報が、サーバに送信され（ステップ１５８）、その時点で、サーバが、たとえば以前にサブミットされた登録情報を取り出し、提示された認証情報をユーザの保管された情報と突き合わせることによって、ユーザまたはクライアントを認証する（ステップ１５９）。認証が成功であると仮定すると、アクティブ・セッションが、認証されたユーザまたはクライアントのために確立される。サーバが、クライアントのセッション識別子を作成し、そのセッションでのクライアントからの後続の要求メッセージのすべてに、このセッション識別子が付随することになる。
次に、サーバは、最初に要求されたウェブ・ページを取り出し、クライアントにＨＴＴＰ応答メッセージを送信し（ステップ１６０）、これによって、保護されたリソースに関するユーザの最初の要求が満足される。その時点で、ユーザは、ブラウザ・ウィンドウ内のハイパーテキスト・リンクをクリックすることによって、“ibm.com”内の別のページを要求する（ステップ１６１）ことができ、ブラウザは、サーバに別のＨＴＴＰ要求メッセージを送信する（ステップ１６２）。その時点で、サーバは、このユーザのセッション識別子が、ＨＴＴＰ要求メッセージでサーバに返されるので、このユーザがアクティブ・セッションを有することを認識し（ステップ１６３）、サーバは、もう１つのＨＴＴＰ応答メッセージで、要求されたウェブ・ページをクライアントに送り返す（ステップ１６４）。図３に、通常の従来技術の処理を示したが、アクティブ・セッションを有するユーザを識別するためのＵＲＬ書換またはクッキーの使用など、他の代替セッション状態管理技法を示すことができることに留意されたい。クッキーの使用に、認証の証明を提供するのに使用されるものと同一のクッキーの使用を含めることができる。
図４を参照すると、ネットワーク図に、本発明を実施できる通常のウェブベース環境が示されている。この環境では、クライアント１７１のブラウザ１７０のユーザが、ＤＮＳドメイン１７３内のウェブ・アプリケーション・サーバ１７２またはＤＮＳドメイン１７５内のウェブ・アプリケーション・サーバ１７４にある保護されたリソースへのアクセスを望む。
図３に示されたものに似た形で、ユーザは、多数のドメインの１つにある保護されたリソースを要求することができる。特定のドメインにある単一のサーバだけを示す図３と対照的に、図４の各ドメインは、複数のサーバを有する。具体的に言うと、各ドメインは、関連する認証サーバ１７６および１７７を有することができる。
この例では、クライアント１７１が、ドメイン１７３の保護されたリソースに関する要求を発行した後に、ウェブ・アプリケーション・サーバ１７２が、クライアント１７１に関するアクティブ・セッションを有しないと判定し、認証サーバ１７６がクライアント１７１との適当な認証動作を実行することを要求する。認証サーバ１７６は、この認証動作の結果をウェブ・アプリケーション・サーバ１７２に通信する。ユーザ（または、ユーザの代わりのブラウザ１７０もしくはクライアント１７１）が成功裡に認証された場合に、ウェブ・アプリケーション・サーバ１７２は、クライアント１７１のセッションを確立し、要求された保護されたリソースを返す。通常、ユーザが認証サーバによって認証されたならば、クッキーをセットし、ブラウザのクッキー・キャッシュに保管することができる。図４は、単に、特に認証動作を実行するためにドメインの処理リソースを複数のサーバの間で共有できる形の例である。
類似する形で、クライアント１７１が、ドメイン１７５の保護されたリソースに関する要求を発行した後に、認証サーバ１７７が、クライアント１７１との適当な認証動作を実行し、その後、ウェブ・アプリケーション・サーバ１７４が、クライアント１７１とのセッションを確立し、要求された保護されたリソースを返す。したがって、図４には、クライアント１７１が、異なるドメインで複数の同時セッションを有することができるが、これらの同時セッションを確立するために複数の認証動作を完了することを要求されることが示されている。
図５を参照すると、ブロック図に、ユーザからの複数の認証動作を必要とする可能性がある通常のオンライン・トランザクションの例が示されている。図３および図４をもう一度参照すると、ユーザは、図３に示されているように、制御されたリソースへのアクセスを得る前に、認証動作を完了することを要求される場合がある。図３には示されていないが、認証マネージャをサーバ１５１に展開して、ユーザを認証するのに必要なユーザ情報を取り出し、使用することができる。図４からわかるように、ユーザは、異なるドメイン１７３および１７５内で複数の同時セッションを有することができ、図４には示されていないが、各ドメインは、認証サーバの代わりにまたはこれに加えて認証マネージャを使用することができる。類似する形で、図５に、それぞれがあるタイプの認証マネージャをサポートする１組のドメインも示す。図５は、ユーザが各ドメインについて認証動作を完了することを必要とする複数のドメインにアクセスする時にユーザが経験する可能性がある問題の一部が示されている。
ユーザ１９０を、ＩＳＰドメイン１９１で登録することができ、このＩＳＰドメイン１９１は、ドメイン１９１に関するトランザクションを完了するためにユーザ１９０を認証する認証マネージャ１９２をサポートすることができる。ＩＳＰドメイン１９１は、インターネット接続サービス、電子メール・サービス、および多分他のｅ−ｃｏｍｍｅｒｃｅサービスを提供するインターネット・サービス・プロバイダ（ＩＳＰ）とすることができる。その代わりに、ＩＳＰドメイン１９１を、ユーザ１９０が頻繁にアクセスするインターネット・ポータルとすることができる。
同様に、ドメイン１９３、１９５、および１９７は、通常のウェブ・サービス・プロバイダを表す。政府ドメイン１９３は、さまざまな政府関連トランザクションを完了するためにユーザを認証する認証マネージャ１９４をサポートする。バンキング・ドメイン１９５は、オンライン銀行とのトランザクションを完了するためにユーザを認証する認証マネージャ１９６をサポートする。ｅ−ｃｏｍｍｅｒｃｅドメイン１９７は、オンライン購入を完了するためにユーザを認証する認証マネージャ１９８をサポートする。
前に注記したように、ユーザが、異なるドメインにあるリソースにアクセスすることによって、インターネット内またはワールド・ワイド・ウェブ内であるドメインから別のドメインに移動することを試みる時に、ユーザは、複数のユーザ認証要求またはユーザ認証要件の対象になる場合があり、これが、ドメインの組にまたがるユーザの進行をかなり低速にする可能性がある。図５を例示的な環境として使用すると、ユーザ１９０が、ｅ−ｃｏｍｍｅｒｃｅドメイン１９７との複雑なオンライン・トランザクションにかかわる場合があり、このトランザクションで、そのユーザは、少なくとも１８歳であり、有効な運転免許証、有効なクレジット・カード、および米国銀行の口座を有するユーザに制限されたオンライン・サービスの購入を試みている。このオンライン・トランザクションは、ドメイン１９１、１９３、１９５、および１９７を伴う可能性がある。
通常、ユーザは、通常のオンライン・トランザクションに参加する各ドメイン内でアイデンティティまたは属性あるいはその両方を維持することができない。この例では、ユーザ１９０は、そのユーザのＩＳＰにそのユーザのアイデンティティを登録済みであることができるが、このオンライン・トランザクションを完了するために、ドメイン１９３、１９５、および１９７への認証も要求される可能性がある。ドメインのそれぞれが、このユーザのアイデンティティを維持しない場合に、このユーザのオンライン・トランザクションが失敗になる可能性がある。ユーザが、各ドメインによって認証されることができる場合であっても、このユーザのトランザクションを完了するために、異なるドメインが、それらの間で情報を転送できることは保証されない。図５に示されたユーザ１９０について、ユーザ１９０が、第１ウェブ・サイト、たとえばＩＳＰ １９１で認証でき、次に、ドメイン１９３、１９５、および１９７などの他のウェブ・サービス・プロバイダに、シングルサインオンのために認証トークンを転送できるようにする従来技術の環境はない。
ある現在の技術に関する前述の短い説明を与えたので、残りの図面の説明は、本発明が動作できる連合コンピュータ環境に関する。しかし、本発明を詳細に説明する前に、いくつかの用語を導入する。
用語
用語「エンティティ」または「当事者」は、一般に、組織、個人、または別のシステムの代わりに動作する組織、個人、またはシステムを指す。用語「ドメイン」は、ネットワーク環境内の追加の特性を意味するが、用語「エンティティ」、「当事者」、および「ドメイン」を、交換可能に使用することができる。たとえば、用語「ドメイン」は、ＤＮＳ（ドメイン・ネーム・システム）ドメインも指すことができ、あるいは、より一般的に、外部エンティティに論理的単位に見えるさまざまなデバイスおよびアプリケーションを含むデータ処理システムを指す。
用語「要求」および「応答」は、メッセージ、通信プロトコル情報、または他の関連する情報など、特定の動作に用いられる情報の転送に適当なデータ・フォーマッティングを含むものとして理解されなければならない。保護されたリソースは、アクセスが制御または制限されるリソース（アプリケーション、オブジェクト、文書、ページ、ファイル、実行可能コード、または他の計算リソース、通信タイプリソースなど）である。
トークンは、成功裡の動作の直接の証拠を提供し、その動作を実行するエンティティによって作られ、たとえば、成功裡の認証動作の後に生成される認証トークンである。ケルベロス・トークンは、本発明で使用できる認証トークンの一例である。ケルベロスに関するさらなる情報は、コール（Kohl）他、「ケルベロス・ネットワーク認証サービス（Ｖ５）（The Kerberos Network AuthenticationService (V5)）」、インターネット・エンジニアリング・タスク・フォース（Internet Engineering Task Force、IETF）コメント要求（Requestfor Comments、RFC）１５１０、１９９３年９月に記載されている。
アサーションは、あるアクションの間接的な証拠を提供する。アサーションは、アイデンティティ、認証、属性、許可、判断、あるいは他の情報または動作あるいはその両方の間接的な証拠を提供することができる。認証アサーションは、認証サービスではないが認証サービスをリスンするエンティティによる認証の間接的な証拠を提供する。
ＳＡＭＬ（Security Assertion Markup Language）アサーションは、本発明で使用できる可能なアサーション・フォーマットの例である。ＳＡＭＬは、非営利的な政府協会であるＯＡＳＩＳ（Organizationfor the Advancement of Structured Information Standards）によって公布された。ＳＡＭＬは、「ＯＡＳＩＳセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）のアサーションおよびプロトコル（Assertionsand Protocol for the OASIS Security Assertion Markup Language (SAML)）」、委員会仕様０１、２００２年５月３１日に次のように記載されている。
ＳＡＭＬ（Security Assertion Markup Language）は、セキュリティ情報を交換する、ＸＭＬベースのフレームワークである。このセキュリティ情報は、対象に関するアサーションの形で表現され、対象は、あるセキュリティ・ドメイン内のアイデンティティを有するエンティティ（人またはコンピュータ）である。対象の通常の例は、具体的にはインターネットＤＮＳドメイン内の電子メール・アドレスによって識別される人である。アサーションは、対象によって実行された認証動作に関する情報、対象の属性、および対象があるリソースへのアクセスを許可されるかどうかに関する許可判断を伝えることができる。アサーションは、ＸＭＬ構造として表現され、入れ子構造を有し、これによって、単一のアサーションに、認証、許可、および属性に関する複数の異なる内部ステートメントを含めることができる。認証ステートメントを含むアサーションが、単に、以前に行われた認証の動作を記述することに留意されたい。アサーションは、ＳＡＭＬオーソリティ（SAMLauthority）すなわち認証オーソリティ（authentication authority）、属性オーソリティ（attribute authority）、およびポリシ決定ポイント（policydecision point）によって発行される。ＳＡＭＬによって、クライアントがＳＡＭＬオーソリティにアサーションを要求し、ＳＡＭＬオーソリティから応答を得ることができるプロトコルが定義される。このプロトコルは、ＸＭＬベースの要求メッセージ・フォーマットおよび応答メッセージ・フォーマットからなるが、多数の異なる基礎になる通信プロトコルおよびトランスポート・プロトコルにバインドすることができ、ＳＡＭＬでは、現在、ＳＯＡＰ ｏｖｅｒ ＨＴＴＰへの１つのバインディングが定義されている。ＳＡＭＬオーソリティは、応答の作成時に要求内の入力として受け取られる外部ポリシ・ストアおよびアサーションなど、情報のさまざまなソースを使用することができる。したがって、クライアントは、必ずアサーションを消費するが、ＳＡＭＬオーソリティは、アサーションのプロデューサおよびコンシューマの両方になることができる。
ＳＡＭＬ仕様は、アサーションが、発行者によって作られた１つまたは複数のステートメントを供給する情報のパッケージであると述べている。ＳＡＭＬを用いると、発行者が、３つの異なる種類のアサーション・ステートメントすなわち、指定された対象が特定の手段によって特定の時に認証された、認証；指定された対象が指定されたリソースにアクセスできるようにする要求が許可または拒否された、許可；および指定された対象が指定された属性に関連する、属性；を作ることができるようになる。下でさらに説明するように、必要な時に、さまざまなアサーション・フォーマットを他のアサーション・フォーマットに変換することができる。
認証は、ユーザによってまたはユーザの代わりに提供される信任証の組を有効化する処理である。認証は、ユーザが知っていること、ユーザが持っているもの、またはユーザがそれであるものすなわちユーザに関する物理的特性を有効化することによって達成される。ユーザが知っていることに、ユーザのパスワードなどの共用される秘密を含めることができ、あるいは、ユーザの暗号鍵など、特定のユーザだけが知っていることを有効化することによるものとすることができる。ユーザが持っているものに、スマートカードまたはハードウェア・トークンを含めることができる。ユーザに関する物理的特性に、指紋または網膜マップなど、バイオメトリック入力を含めることができる。
認証信任証は、さまざまな認証プロトコルで使用されるチャレンジ／レスポンス情報の組である。たとえば、ユーザ名およびパスワードの組合せが、認証信任証の最もありふれた形である。認証信任証の他の形に、チャレンジ／レスポンス情報、公開鍵インフラストラクチャ（ＰＫＩ）証明書、スマートカード、バイオメトリックスなどを含めることができる。認証信任証は、認証アサーションと区別される。認証信任証は、認証サーバまたは認証サービスとの認証プロトコル・シーケンスの一部としてユーザによって提示され、認証アサーションは、後に必要な時にエンティティの間で転送される、ユーザの認証信任証の成功裡の貞治および有効化に関するステートメントである。
従来技術のシングルサインオン解決策の区別
上で注記したように、従来技術のシングルサインオン解決策は、参加する企業の間に事前に確立されたビジネス契約がある、同種環境に制限されている。これらのビジネス契約は、企業の間で信頼を確立し、情報の保護された転送を定義する。これらのビジネス契約に、ユーザ・アイデンティティをある企業から別の企業に変換するかマッピングする規則に関する技術的合意と、参加企業の間でユーザを保証するのに使用される情報を転送する方法に関する技術的合意も含まれる。
言い換えると、以前のシングルサインオン解決策は、ある企業が、事前に折衝された契約または事前に構成された契約に基づいて、異なる企業によって作られた認証アサーションを（アサーションで提供されるユーザのアイデンティティと共に）信頼できるようにする。各別個の企業は、ｅ−ｃｏｍｍｅｒｃｅマーケットプレイス内の企業など、類似する契約を交換した他の企業が理解できる認証アサーションを作成し、解釈する方法を知っている。これらのシステムにまたがってユーザ・アイデンティティをマッピングする、企業に既知の決定論的関係があるので、これらの同種環境は密結合されている。この密結合は、シングルサインオン環境を確立するのに使用されるビジネス契約のゆえに可能である。
本発明の連合モデル
ワールド・ワイド・ウェブのコンテキストで、ユーザは、あるインターネット・ドメインでのアプリケーションとの対話から別のドメインの別のアプリケーションへ、各特定のドメインの間の情報障壁を最小限だけ顧慮してジャンプする能力を期待するようになっている。ユーザは、単一のトランザクションに関して複数のドメインに認証する必要があることによって引き起こされるフラストレーションを求めていない。言い換えると、ユーザは、組織がインターオペレートしなければならないと期待しているが、ユーザは、一般に、ドメインがユーザのプライバシを尊重することを求める。さらに、ユーザは、プライベート情報を永久的に保管するドメインを制限することを好む可能性がある。このユーザの期待は、多数の企業および組織が競合する認証技法を公表している素早く発展する異種環境に存在する。
従来技術のシステムとは対照的に、本発明は、企業がユーザにシングルサインオン経験を提供できるようにする連合モデルを提供する。言い換えると、本発明は、連合した異種環境をサポートする。本発明の目的の例として、図５をもう一度参照すると、ユーザ１９０は、ドメイン１９１に認証することができ、その後、ドメイン１９１に、１つのトランザクションに含まれる可能性がある下流ドメインのそれぞれに適当なアサーションを供給させることができる。これらの下流ドメインは、ドメイン１９１とこれらの他の下流ドメインとの間に事前に確立されたアサーション・フォーマットがない場合であっても、認証アサーションまたは他のタイプのアサーションあるいはその両方を理解でき、信頼できることが必要である。アサーションの認識の他に、下流ドメインは、事前に確立されたアイデンティティ・マッピング関係がない場合であっても、アサーションに含まれるアイデンティティを、特定のドメイン内でユーザ１９０を表すアイデンティティに変換できることが必要である。しかし、本発明が、さまざまなタイプのドメインに適用可能であり、図５で例示的なドメインとして表されたＩＳＰタイプ・ドメインに制限されないことに留意されたい。
本発明は、連合環境を対象とする。一般に、企業は、それ自体のユーザ・レジストリを有し、ユーザのそれ自体の組との関係を維持する。各企業は、通常、これらのユーザを認証するそれ自体の手段を有する。しかし、本発明の連合方式を用いると、ある企業のユーザが企業の連合への企業の参加を介する企業の組との関係を活用できる集合的な形で企業が協力できるようになる。ユーザは、各企業との直接の関係を有するかのように、連合した企業のどれにあるリソースへのアクセスでも許可されることができる。ユーザは、関心がある企業のそれぞれで登録することを要求されず、ユーザは、彼ら自体を識別し、認証することを常に要求されるのではない。したがって、この連合環境内で、認証方式によって、情報技術の素早く発展する異種環境内でのシングルサインオン経験が可能になる。
本発明では、連合が、企業、組織、機関など、ユーザにシングルサインオンの使い易い経験を提供するために協力する別個のエンティティの組である。本発明では、２つの企業が、ユーザに関するどの情報をどのように転送するかを定義する直接の事前に確立された関係を有する必要がないという点で、連合環境が、通常のシングルサインオン環境と異なる。連合環境内で、エンティティは、ユーザ認証、他のエンティティによって提示される認証トークンなどの認証アサーションの受入れ、および証明されたユーザのアイデンティティのローカル・エンティティ内で理解されるアイデンティティへのある形の変換の提供を扱うサービスを提供する。
連合は、サービス・プロバイダに対する管理の重荷を軽くする。サービス・プロバイダは、連合全体に関してその信頼関係に頼ることができ、サービス・プロバイダは、ユーザ・パスワード情報などの認証情報を管理する必要がない。というのは、サービス・プロバイダが、ユーザの認証ホーム・ドメイン／アイデンティティ・プロバイダによって達成される認証に頼ることができるからである。
本発明は、疎結合された認証、ユーザ・エンロールメント、ユーザ・プロファイル管理、または許可サービス、あるいはこれらの組合せが、セキュリティ・ドメインにまたがって協力する基礎を確立する連合アイデンティティ管理システムにも関する。連合アイデンティティ管理によって、異なるセキュリティ・ドメインに常駐するサービスが、これらの異なるドメインにある基礎になるセキュリティ機構およびオペレーティング・システム・プラットフォームに差がある場合であっても、セキュアにインターオペレートでき、協力できるようになる。ユーザが連合への参加を確立したならば、シングルサインオン経験が確立される。
ホーム・ドメインまたはアイデンティティ・プロバイダ対依存ドメインまたは依存サービス・プロバイダ
下で詳細に説明するように、本発明は、大きいユーザ利益を提供する。本発明は、ユーザが、下でユーザのホーム・ドメイン、ユーザの認証ホーム・ドメイン、またはユーザのアンデンティティ・プロバイダと称する第１エンティティで認証できるようにする。この第１エンティティは、発行当事者として働くことができ、発行当事者は、一般化されたサービス・プロバイダと見なすことができる第２エンティティでの使用のために、そのユーザに関する認証アサーションを発行する。次に、ユーザは、第２エンティティすなわちサービス・プロバイダで明示的に再認証する必要なしに、第１エンティティによって発行された認証アサーションを提示することによって、依存当事者と称する第２の別個のエンティティにある保護されたリソースにアクセスすることができる。発行当事者から依存当事者に渡される情報は、アサーションの形であり、このアサーションに、ステートメントの形のさまざまなタイプの情報を含めることができる。たとえば、アサーションは、ユーザの認証されたアイデンティティに関するステートメントとすることができ、あるいは、特定のユーザに関連するユーザ属性情報に関するステートメントとすることができる。
図６を参照すると、ブロック図に、連合環境内の下流エンティティでのアクションを呼び出す、ユーザによって第１連合企業に対して開始されたトランザクションに関する連合環境の用語が示されている。図６に、用語が、所与の連合動作に関する連合内のエンティティの展望に応じて変化することが示されている。具体的に言うと、図６に、本発明が、信頼の推移性および認証アサーション処理の推移性をサポートすることが示されており、ドメインは、別のドメインによってアサートされたアイデンティティへの信頼に基づいてアサーションを発行することができる。ユーザ２０２は、企業２０４にある保護されたリソースに関する要求を介してトランザクションを開始する。ユーザ２０２が、企業２０４によって認証されているか、トランザクションの途中で最終的に企業２０４によって認証される場合に、その企業２０４が、この連合セッションに関する、ユーザのホーム・ドメインすなわち、そのユーザのアイデンティティ・プロバイダである。トランザクションが、企業２０６によるあるタイプの動作を必要とし、企業２０４が企業２０６にアサーションを転送すると仮定すると、企業２０４は、その特定の動作に関する発行ドメインであり、企業２０６は、その動作に関する依存ドメインである。言い換えると、企業２０６は、現在のトランザクションに関するサービス・プロバイダである。トランザクションが、さらなる動作を必要とし、企業２０６が企業２０８にアサーションを転送すると仮定すると、企業２０６は、この必要な動作に関する発行ドメインであり、企業２０８は、この動作に関する依存ドメインである。この場合に、企業２０８は、もう１つの下流サービス・プロバイダと見なすことができるが、連合トランザクションは、通常、２つのドメインすなわちアイデンティティ・プロバイダとサービス・プロバイダだけについて記述することができる。
本発明の連合環境では、ユーザが認証するドメインを、ユーザの（認証）ホーム・ドメインまたはユーザのアイデンティティ・プロバイダと称する。アイデンティティ・プロバイダは、認証信任証を維持し、この認証信任証は、ユーザの雇用者、ユーザのＩＳＰ、または他の商業エンティティによって物理的にサポートすることができる。あるユーザの認証信任証を生成し、有効化する能力を有する複数の企業が存在し得るので、連合環境内に、あるユーザのホーム・ドメインとして働くことができる複数の企業が存在できることが可能である可能性があるが、連合トランザクションを、通常、単一のアイデンティティ・プロバイダだけを伴うものとして記述することができる。
認証の展望から、認証アサーションの発行当事者は、通常、ユーザのアイデンティティ・プロバイダすなわち、ユーザの認証ホーム・ドメインである。ユーザのホーム・ドメインは、そのユーザの個人情報またはプロファイル情報を維持する場合とそうでない場合がある。したがって、個人的に識別可能な情報、パーソナライゼーション情報、または他のユーザ属性を含む属性の展望から、属性アサーションの発行当事者は、ユーザのホーム・ドメインである場合とそうでない場合がある。混乱を避けるために、属性ホーム・ドメインと認証ホーム・ドメインについて別々の用語を使用することができるが、用語「ホーム・ドメイン」は、下では、認証ホーム・ドメインを指すものと解釈することができる。
しかし、所与の連合セッションのスコープ内で、通常、ユーザのアイデンティティ・プロバイダすなわちユーザのホーム・ドメインとして働くドメインは、１つだけがある。ユーザが、このドメインに対して認証されたならば、連合内の他のすべてのドメインまたは企業は、そのセッションの期間中に、単なるサービス・プロバイダすなわち依存当事者として扱われる。
本発明が、既存の非連合アーキテクチャに対する影響を最小にしながら既存システムに追加できる連合アーキテクチャを提供するならば、ホーム・ドメインも連合環境に参加できるという事実によって、ユーザのホーム・ドメインでの認証は必ずしも変更されない。言い換えると、ホーム・ドメインを、本発明に従って実施される連合環境に統合することができる場合であっても、ユーザは、ユーザのホーム・ドメインで認証動作を実行しながら同一のエンドユーザ経験を有しなければならない。ただし、所与の企業のユーザのすべてが、必ずしも連合環境に参加しないことに留意されたい。
さらに、たとえばユーザ・アカウントの確立などのユーザ登録は、ホーム・ドメインも連合環境に参加できるという事実によって必ずしも変更されない。たとえば、ユーザは、まだ、連合環境と独立のレガシ登録処理または既存の登録処理を介してドメインでアカウントを確立することができる。言い換えると、ホーム・ドメインでのユーザ・アカウントの確立に、たとえばアイデンティティ変換情報を介して、連合にまたがって有効なアカウント情報の確立を含めても含めなくてもよい。しかし、ユーザを認証できる単一の連合ドメインがあるすなわち、ユーザが登録したドメインが連合内に１つだけある場合に、このドメインが、連合環境全体を通じてユーザのトランザクションをサポートするために、そのユーザのホーム・ドメインまたはアイデンティティ・プロバイダとして働くことが期待される。
ユーザが、連合環境内に複数の可能なホーム・ドメインを有する場合に、ユーザは、複数のエントリ・ポイントを介して連合に入ることができる。言い換えると、ユーザは、そのユーザのアイデンティティ・プロバイダとして働くことができる複数のドメインのアカウントを有することができ、これらのドメインは、必ずしも、他のドメインに関する情報および他のドメインでのユーザのアイデンティティに関する情報を有しない。
ユーザが認証するドメインを、ユーザのホーム・ドメインまたはユーザのアイデンティティ・プロバイダと称するが、発行ドメインは、別のドメインすなわち依存ドメインによる使用のためにアサーションを発行する連合エンティティである。発行ドメインは、必ずではないが通常、ユーザのホーム・ドメインまたはユーザのアイデンティティ・プロバイダである。したがって、通常は、発行当事者が、上で述べたように通常の認証プロトコルを介してユーザを認証している。しかし、発行当事者が、前に依存当事者として働き、これによって、異なる発行当事者からアサーションを受け取ったものであることも可能である。言い換えると、ユーザが開始したトランザクションが、連合環境内の一連の企業を介してカスケードされる可能性があるので、受け取る当事者が、その後、下流トランザクションに関する発行当事者として働くことができる。一般に、ユーザの代わりに認証アサーションを発行する能力を有するすべてのドメインが、発行ドメインとして働くことができる。
依存ドメインは、発行当事者からアサーションを受け取るドメインである。依存当事者は、ユーザの代わりの第三者すなわち発行ドメインによって発行されたアサーションを受け入れ、信頼し、理解することができる。一般に、適当な認証オーソリティを使用して認証アサーションを解釈するのは、依存当事者の義務である。さらに、依存当事者が、特定のユーザを認証できる、すなわち、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダとして働くことができることが可能であるが、依存当事者が、普通の方法を介して特定のユーザを認証できない場合があることも可能である。したがって、依存当事者は、ユーザによって提示された認証アサーションに頼り、ユーザとの対話セッションの一部としてユーザの認証信任証についてユーザにプロンプトを出すのではなくシングルサインオン経験をユーザに提供するドメインまたは企業である。
連合アーキテクチャ−レガシ・システム用の連合フロントエンド
図７を参照すると、ブロック図に、本発明の実施形態による、所与のドメインの既存のシステムの、本発明の連合アーキテクチャ構成要素の一部との統合が示されている。連合環境に、ユーザにさまざまなサービスを提供する連合したエンティティが含まれる。ユーザ２１２は、クライアント・デバイス２１４と対話し、クライアント・デバイス２１４は、ブラウザ・アプリケーション２１６およびさまざまな他のクライアント・アプリケーション２１８をサポートすることができる。ユーザ２１２は、クライアント・デバイス２１４、ブラウザ２１６、またはユーザと他のデバイスおよびサービスとの間のインターフェースとして働く他のソフトウェアと別個である。いくつかの場合に、次の記述で、明示的にクライアント・アプリケーション内で動作するユーザと、ユーザの代わりに働くクライアント・アプリケーションを区別する場合がある。しかし、一般に、リクエスタは、クライアントベースのアプリケーション、ブラウザ、ＳＯＡＰクライアントなど、ユーザの代わりに働くと仮定できる媒介物である。
ブラウザ・アプリケーション２１６は、モバイル・デバイスで見られるものを含む、ＨＴＴＰ通信構成要素２２０およびマークアップ言語（ＭＬ）インタープリタ２２２などの多数のモジュールを含む通常のブラウザとすることができる。ブラウザ・アプリケーション２１６は、ウェブ・サービス・クライアント２２４およびダウンローダブル・アプレットあるいはその両方など、仮想マシン・ランタイム環境を必要としてもしなくてもよい、プラグインもサポートすることができる。ウェブ・サービス・クライアント２２４は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を使用することができ、ＳＯＡＰは、非集中分散環境で構造化された型付きの情報の交換を定義する軽量プロトコルである。ＳＯＡＰは、３つの部分すなわち、メッセージに何が含まれるかとそれを処理する方法を記述したフレームワークを定義するエンベロープと；アプリケーション定義のデータ型のインスタンスを表現するエンコーディング・ルールの組と；リモート・プロシージャ呼び出しおよび応答を表す規約とからなるＸＭＬベースのプロトコルである。ユーザ２１２は、ブラウザ・アプリケーション２１６を使用してウェブベース・サービスにアクセスすることができるが、ユーザ２１２は、クライアント・デバイス２１４の他のウェブ・サービス・クライアントを介してウェブ・サービスにアクセスすることもできる。次の図で示される本発明の例の一部は、ユーザのブラウザを介するＨＴＴＰリダイレクションを使用して、連合環境内のエンティティの間で情報を交換する。しかし、本発明を、さまざまな通信プロトコルを介して行うことができ、ＨＴＴＰベース通信に制限されることが意図されていないことに留意されたい。たとえば、連合環境のエンティティが、必要な時に直接に通信することができ、メッセージが、ユーザのブラウザを介してリダイレクトされる必要はない。
本発明は、連合環境に必要な構成要素を既存のシステムと一体化できる形で実施することができる。図７に、既存のシステムへのフロントエンドとしてこれらの構成要素を実施する一実施形態を示す。連合ドメイン側の既存の構成要素は、レガシ・アプリケーションまたはバックエンド処理構成要素２３０と見なすことができ、これには、図８に示されたものに類似する形の認証サービス・ランタイム（ＡＳＲ）サービス２３２が含まれる。ＡＳＲサービス２３２は、ドメインが、アプリケーション・サービス２３４（保護されたリソース２３５を生成し、取り出し、または他の形でサポートするか処理すると考えることができる）へのアクセスを制御する時に、ユーザを認証する責任を負う。ドメインは、アプリケーション・サービス２３４へのアクセスに関してユーザを登録するのにレガシ・ユーザ登録アプリケーション２３６を使い続けることができる。登録ユーザを認証するのに必要な情報は、レガシ・ユーザ・レジストリ２３８に保管される。
連合環境に加わった後に、ドメインは、連合したコンポーネントの介入なしで動作し続けることができる。言い換えると、ユーザが、接触点サーバまたはこの接触点サーバ機能性を実施する他の構成要素を介することなく特定のアプリケーション・サーバまたは他の保護されたリソースに直接にアクセスし続けることができるように、ドメインを構成することができる。この形でシステムにアクセスするユーザは、通常の認証フローおよび通常のアクセスを経験する。しかし、それを行う際に、レガシ・システムに直接にアクセスするユーザは、ドメインの接触点サーバに既知の連合セッションを確立することができない。
ドメインのレガシ機能性は、連合フロントエンド処理２４０の使用を介して連合環境に一体化することができ、この連合フロントエンド処理２４０には、連合ユーザ・ライフサイクル管理サーバ／サービス２４６と共に、接触点サーバ２４２および信頼プロキシ・サーバ２４４（または、より単純に信頼プロキシ２４４もしくは信頼サービス２４４）が含まれ、信頼プロキシ・サーバ２４４自体は、セキュリティ・トークン・サービス（ＳＴＳ）２４５と相互作用し、これらのすべてを、図８に関して下で詳細に説明する。連合構成アプリケーション２４７は、管理ユーザが連合フロントエンド構成要素を構成できるようにして、彼らが連合インターフェース・ユニット２４８を介してレガシ・バックエンド構成要素と対話できるようにする。
所与の企業のレガシまたは既存の認証サービスは、ユーザ名／パスワードまたはスマート・カード・トークンベースの情報など、さまざまな周知の認証方法または認証トークンを使用する場合がある。しかし、本発明に関して、レガシ認証サービスの機能性を、接触点サーバの使用を介して連合環境で使用することができる。ユーザは、接触点サーバを経由せずにレガシ認証サーバに直接にアクセスし続けることができるが、この形でシステムにアクセスするユーザは、通常の認証フローおよび通常のアクセスを経験する。レガシ認証システムに直接にアクセスするユーザは、本発明によるアイデンティティの証明としての連合認証アサーションを生成することができない。連合フロントエンドの役割の１つが、接触点サーバで受け取られた連合認証トークンを、レガシ認証サービスによって理解されるフォーマットに変換することである。したがって、接触点サーバを介して連合環境にアクセスするユーザは、必ずしも、レガシ認証サービスへの再認証を要求されない。ユーザが認証ダイアログにかかわるかのように、接触点サーバおよび信頼プロキシの組合せによってレガシ認証サービスに対してユーザが認証されることが好ましい。
連合アーキテクチャ−接触点サーバ、信頼プロキシ、および信頼ブローカ
図８を参照すると、ブロック図に、本発明の実施形態による連合アーキテクチャが示されている。連合環境に、連合した企業、またはユーザにさまざまなサービスを提供する類似するエンティティが含まれる。ユーザは、クライアント・デバイスのアプリケーションを介して、企業２５０などのさまざまなエンティティにあるリソースへのアクセスを試みることができる。企業２５０の接触点（ＰＯＣ）サーバ２５２など、各連合企業にある接触点サーバが、連合環境へのユーザのエントリ・ポイントである。接触点サーバは、たとえばレガシ・システムなど、既存の非連合アーキテクチャ内の既存構成要素に対する影響を最小限にする。というのは、接触点サーバが、多数の連合要件を処理するからである。接触点サーバは、セッション管理、プロトコル変換を提供し、多分認証または属性あるいはこの両方のアサーション変換を開始する。たとえば、接触点サーバは、ＨＴＴＰメッセージまたはＨＴＴＰＳメッセージをＳＯＡＰに変換し、その逆に変換することができる。下で詳細に説明するように、接触点サーバは、アサーションを変換するために信頼プロキシを呼び出すのにも使用することができ、たとえば、発行当事者から受け取ったＳＡＭＬトークンを、受取り側当事者が理解するケルベロス・トークンに変換することができる。
企業２５０の信頼プロキシ（ＴＰ）２５４などの信頼プロキシ（信頼プロキシ・サーバまたは信頼サービス）は、連合内の２つのエンティティの間の信頼関係を確立し、維持する。信頼プロキシは、一般に、発行当事者によって使用されるフォーマットから受取り側当事者によって理解されるフォーマットへの認証トークン・フォーマット変換（下で詳細に説明するセキュリティ・トークン・サービスを介する）を処理する能力を有する。
接触点サーバと信頼プロキシを一緒に使用することによって、システムの既存の連合していない組に対する連合アーキテクチャの実施の影響が最小限になる。したがって、本発明の連合アーキテクチャは、エンティティが企業、ドメイン、または他の論理エンティティもしくは物理エンティティのどれであれ、連合したエンティティごとに少なくとも１つの接触点サーバおよび少なくとも１つの信頼プロキシの実施を必要とする。本発明の連合アーキテクチャは、システムの既存の連合していない組に対する変更を必ずしも必要としない。所与の連合したエンティティに単一の信頼プロキシがあることが好ましいが、可用性のために複数の信頼プロキシを設けることができ、あるいは、たとえば企業内の別々の子会社など、連合したエンティティ内のさまざまなより小さいエンティティのために複数の信頼プロキシを設けることができる。所与のエンティティが、複数の連合に属することができることが可能であるが、単一の信頼プロキシが、複数の連合内の信頼関係を管理することができるので、このシナリオは、必ずしも複数の信頼プロキシを必要としない。
信頼プロキシの役割の１つを、別のドメインまたはそのドメイン内の信頼プロキシあるいはその両方によって要求されるトークン・タイプを判定することまたはその判定の責任を負うこととすることができる。信頼プロキシは、発行当事者によって使用されるフォーマットから受取り側当事者によって理解されるフォーマットへの認証トークン・フォーマット変換を処理する能力または責任を有する。信頼プロキシ２５４は、企業２５０に関して行われるすべてのユーザ・アイデンティティ変換または属性変換の責任も負うことができる。さらに、信頼プロキシは、ユーザの実世界のアイデンティティに関する追加情報を一切提供せずにユーザを一意に識別するユーザ・アイデンティティの代表としてのエイリアスの実装をサポートすることができる。さらに、信頼プロキシは、接触点サーバによる使用のために認証信任証またはセッション信任証あるいはその両方を発行することができる。しかし、信頼プロキシは、下でさらに説明するように、援助のために信頼ブローカを呼び出すことができる。アイデンティティ変換は、発行当事者に既知のユーザのアイデンティティおよび属性を受取り側当事者新見のあるアイデンティティおよび属性にマッピングするのに必要になる場合がある。この変換をは、発行ドメインの信頼プロキシ、受取り側ドメインの信頼プロキシ、あるいはその両方によって呼び出すことができる。
信頼プロキシ２５４は、セキュリティ・トークン・サービス（ＳＴＳ）構成要素２５５として示された、トークン変換を提供し、トークンの有効化および生成のために認証サービス・ランタイム（ＡＳＲ）２５６を呼び出す内部化された構成要素を含む（またはこれと対話する）ことができる。セキュリティ・トークン・サービスは、アイデンティティ変換を含めることができる、信頼プロキシによって要求されるトークン発行サービスおよびトークン有効化サービスを提供する。したがって、セキュリティ・トークン・サービスに、既存の認証サービス・ランタイムへのインターフェースが含まれ、あるいは、認証サービス・ランタイムがこのサービス自体に組み込まれる。信頼プロキシによって内部化されるのではなく、セキュリティ・トークン・サービス構成要素を、たとえば信頼プロキシによって呼び出される、独立構成要素として実施することもでき、あるいは、たとえばアプリケーション・サーバの一部として、トランザクション・サーバ内で内部化することができる。
たとえば、ＳＴＳ構成要素は、ケルベロス・トークンを発行する要求を受け取る場合がある。トークンが作成されるユーザの認証情報の一部として、その要求に、ユーザ名およびパスワードを含むバイナリ・トークンを含めることができる。ＳＴＳ構成要素は、たとえばＬＤＡＰランタイム（通常の認証）に対してユーザ名およびパスワードを有効化し、ケルベロスＫＤＣ（鍵配布センタ）を呼び出して、このユーザのケルベロス・チケットを生成する。このトークンは、企業内での使用のために信頼プロキシに返されるが、この使用に、連合内の別のドメインへの転送のためのトークンの外部化を含めることができる。
図４に関して説明したものに類似する形で、ユーザは、企業２５０および企業２６０の両方など、連合環境内の複数の企業にあるリソースへのアクセスを望む場合がある。企業２５０に関して上で説明したものに似た形で、企業２６０に、接触点サーバ２６２、信頼プロキシ２６４、セキュリティ・トークン・サービス２６５、および認証サービス・ランタイム２６６が含まれる。ユーザは、各企業との別々のトランザクションを直接に開始することができるが、ユーザは、企業２５０とのトランザクションを開始することができ、この企業２５０が、連合環境を介してカスケードする。企業２５０は、特定のトランザクションを完了するために、企業２６０など、連合環境内の複数の他の企業との協力を必要とする場合があるが、ユーザは、トランザクションを開始した時にこの必要に気付かなかった可能性がある。企業２６０は、下流ストリームとして含まれるようになり、本発明は、企業２５０が、さらなるユーザのトランザクションのために必要な場合に、企業２６０に連合アサーションを提示できるようにする。
信頼プロキシが、関連する接触点サーバによって受け取られた認証トークンを解釈する方法、または所与のユーザ・アイデンティティおよび属性を変換する方法、あるいはその両方を知らない場合があり得る。この場合に、信頼プロキシは、信頼ブローカ２６８などの信頼ブローカ構成要素の機能性を呼び出すことを選択することができる。信頼ブローカは、個々の信頼プロキシとの関係を維持し、これによって、信頼プロキシの間の推移的信頼を提供する。信頼ブローカを使用することによって、企業２５０および２６０などの連合環境内の各エンティティが、連合環境内の各ドメインとの複数の個別の信頼関係を確立するのではなく、信頼ブローカとの信頼関係を確立することができるようになる。たとえば、企業２６０が、企業２５０でユーザによって開始されたトランザクションの下流ドメインとして含まれるようになった時に、企業２５０の信頼プロキシ２５４は、企業２６０の信頼プロキシ２６４が、必要な場合に信頼ブローカ２６８の援助を呼び出すことによって信頼プロキシ２５４からのアサーションを理解できることを確信することができる。図８に、単一の信頼ブローカを有する連合環境が示されているが、１つの連合環境が、複数の信頼ブローカを有することができる。
図８に、接触点サーバ２５２、信頼プロキシ２５４、セキュリティ・トークン・サービス構成要素２５５、および認証サービス・ランタイム２５６が、別個のエンティティとして図示されているが、これらの構成要素を別々のデバイスで実施する必要はない。たとえば、これらの別々のコンポーネントの機能性を、単一の物理デバイスの複数のアプリケーションとして実施するか、単一のアプリケーションに組み合わせることが可能である。さらに、図８に、ある企業の単一の接触点サーバ、単一の信頼プロキシ、および単一のセキュリティ・トークン・サーバが示されているが、代替構成に、企業ごとに複数の接触点サーバ、複数の信頼プロキシ、および複数のセキュリティ・トークン・サーバを含めることができる。接触点サーバ、信頼プロキシ、セキュリティ・トークン・サービス、および他の連合エンティティは、ソフトウェア・アプリケーション、オブジェクト、モジュール、ソフトウェア・ライブラリなど、さまざまな形で実施することができる。
信頼プロキシ／ＳＴＳは、ユーザ名およびパスワードの組合せとケルベロス・チケットなどの従来の信任証を含む多数の異なる認証信任証ならびに第三者によって作られた認証トークンを含む連合認証トークン・フォーマットを受け入れ、有効化することができるものとすることができる。信頼プロキシ／ＳＴＳは、他所での認証の証拠としての認証トークンの受入れを許容することができる。認証トークンは、発行当事者によって作られ、ユーザがその発行当事者に対して既に認証されていることを示すのに使用される。発行当事者は、ユーザの認証されたアイデンティティをアサートする手段として認証トークンを作る。信頼プロキシ／ＳＴＳは、属性トークンまたは、ＳＳＬセッション識別子に類似する形でセッション情報を管理するのに使用されるものなどのセキュア通信セッションまたは会話に使用されるトークンを処理することができる。
セキュリティ・トークン・サービスは、必要に応じて認証サービス・ランタイムを呼び出す。認証サービス・ランタイムは、ユーザを認証できる認証サービスをサポートする。認証サービスは、認証応答を介して成功裡のまたは失敗した認証の試みの表示を供給する認証オーソリティとして働く。信頼プロキシ／ＳＴＳは、認証サービスを内部化することができ、これは、たとえば、既存のレガシ・インフラストラクチャと対話する必要がないウェブ・サービスの完全に新規のインストールがあるシナリオである。そうでない場合に、ＳＴＳ構成要素は、認証トークンの有効化のために外部の認証サービスを呼び出す。たとえば、ＳＴＳ構成要素は、ユーザ名／パスワードを含むバイナリ・トークンを「パック解除」し、その後、ＬＤＡＰサービスを使用してユーザ・レジストリにアクセスして、提示された信任証を有効化することができる。
アプリケーション・サーバなどの別の構成要素によって使用される時に、ＳＴＳ構成要素を使用して、レガシ認証システムへのシングルサインオンに必要なトークンを作ることができる。したがって、ＳＴＳ構成要素は、内部目的すなわち企業内での、および外部目的すなわち連合内の企業間での、トークン変換に使用することができる。内部目的の例として、ウェブ・アプリケーション・サーバが、ＩＢＭ ＣＩＣＳ（顧客情報管理システム）トランザクション・ゲートウェイを介してメインフレームとインターフェースすることができる。ＣＩＣＳは、ミッションクリティカル・アプリケーションの企業レベルのオンライン・トランザクション管理および接続性を提供するアプリケーション・サーバおよびコネクタのファミリである。ウェブ・アプリケーション・サーバは、ＳＴＳ構成要素を呼び出して、ケルベロス・チケット（ウェブ・アプリケーション・サーバによって内部で使用される）を、ＣＩＣＳトランザクション・ゲートウェイが必要とするＩＢＭ ＲＡＣＦ（Ｒ）パスチケットに変換することができる。
図８に示されたエンティティは、上で導入した用語、たとえば、「発行エンティティ」および「依存当事者」または「アイデンティティ・プロバイダ」および「サービス・プロバイダ」を使用して説明することができる。信頼関係の確立および維持の一部として、アイデンティティ・プロバイダの信頼プロキシは、どのトークン・タイプがサービス・プロバイダの信頼プロキシによって要求される／受け入れられるかを判定することができる。したがって、信頼プロキシは、セキュリティ・トークン・サービスからトークン・サービスを呼び出す時に、この情報を使用する。アイデンティティ・プロバイダの信頼プロキシが、サービス・プロバイダ用の認証アサーションを作る必要がある場合に、その信頼プロキシは、必要なトークン・タイプを判定し、セキュリティ・トークン・サービスに適当なトークンを要求する。
サービス・プロバイダの信頼プロキシが、アイデンティティ・プロバイダから認証アサーションを受け取る時に、信頼プロキシは、それが期待するアサーションのタイプおよびサービス・プロバイダ内の内部使用に必要なアサーションのタイプを知っている。したがって、サービス・プロバイダの信頼プロキシは、受け取った認証アサーション内のトークンに基づいて、セキュリティ・トークン・サービスが必要な内部使用トークンを生成することを要求する。
信頼プロキシと信頼ブローカの両方が、アイデンティティ・プロバイダから受け取ったアサーションを、サービス・プロバイダによって理解されるフォーマットに変換する能力を有する。信頼ブローカは、直接信頼関係がある信頼プロキシのそれぞれについてアサーション・フォーマット（１つまたは複数）を解釈する能力を有し、これによって、信頼ブローカが、アイデンティティ・プロバイダとサービス・プロバイダの間でのアサーション変換を提供できるようにする。この変換は、いずれかの当事者がそのローカル信頼プロキシを介して要求することができる。したがって、アイデンティティ・プロバイダの信頼プロキシは、アサーションをサービス・プロバイダに送信する前に、そのアサーションの変換を要求することができる。同様に、サービス・プロバイダの信頼プロキシは、アイデンティティ・プロバイダから受け取ったアサーションの変換を要求することができる。
アサーション変換に、ユーザ・アイデンティティ変換、認証アサーション変換、属性アサーション変換、または他の形のアサーション変換が含まれる。上の要点を繰り返すと、アサーション変換は、連合内の信頼構成要素すなわち信頼プロキシおよび信頼ブローカによって処理される。信頼プロキシは、アイデンティティ・プロバイダまたはサービス・プロバイダのいずれかで、ローカルに変換を実行することができ、あるいは、信頼プロキシは、信頼ブローカからの援助を呼び出すことができる。
アイデンティティ・プロバイダおよびサービス・プロバイダが、信頼ブローカとの個々の信頼関係を既に有すると仮定すると、信頼ブローカは、必要な場合に、発行当事者と依頼当事者の間の新しい信頼関係を動的に作成するすなわち、仲介することができる。信頼ブローカによって提供される最初の信頼関係仲介動作の後に、アイデンティティ・プロバイダおよびサービス・プロバイダは、その関係を直接に維持することができ、その結果、信頼ブローカは、将来の変換の必要について呼び出される必要がなくなる。認証トークンの変換を、３つの可能な場所すなわち、アイデンティティ・プロバイダの信頼プロキシ、サービス・プロバイダの信頼プロキシ、および信頼ブローカで行えることに留意されたい。アイデンティティ・プロバイダの信頼プロキシが、サービス・プロバイダに送信するために信頼ブローカによって理解される認証アサーションを生成することが好ましい。次に、サービス・プロバイダは、信頼ブローカに、このトークンをサービス・プロバイダによって認識可能なフォーマットへの変換を要求する。トークン変換は、認証アサーションの送信前、送信後、あるいは送信前と送信後の両方に行うことができる。
連合アーキテクチャ内の信頼関係
本発明に従って実施された連合環境内に、管理されなければならない２タイプの「信頼ドメイン」すなわち、企業信頼ドメインおよび連合信頼ドメインがある。この２タイプの信頼ドメインの間の差は、部分的に、信頼ドメインとの信頼関係を決定するビジネス契約と、信頼を確立するのに使用される技術とに基づく。企業信頼ドメインに、企業によって管理される構成要素が含まれ、その信頼ドメイン内のすべての構成要素が、お互いを信頼する。一般に、企業内で信頼を確立するのに必要なビジネス契約はない。というのは、展開される技術が、たとえば構成要素間の相互に認証されたＳＳＬセッションを要求することによって、または物理的な制御および近接が暗黙の信頼を実証するように単一の密に制御されたデータ・センタ内に構成要素を配置することによって、企業内で固有の信頼を作成するからである。図７を参照すると、レガシ・アプリケーションおよびバックエンド処理システムが、構成要素がセキュア内部ネットワーク上で通信する、企業信頼ドメインを表すことができる。
連合信頼ドメインは、企業境界にまたがるドメインであり、ある展望から、連合信頼ドメインは、別個の企業信頼ドメインの間の信頼関係を表すことができる。連合信頼ドメインは、連合パートナの間の企業境界にまたがる信頼プロキシを介して確立される。信頼関係に、最初の信頼が信頼プロキシの間で確立される、ある種のブートストラップ処理が含まれる。このブートストラップ処理の一部に、期待されるまたは許容されるあるいはその両方のトークン・タイプ変換および識別子変換を定義する、共用される秘密鍵および規則の確立を含めることができる。一般に、このブートストラップ処理は、アウトオブバンドで実施することができる。というのは、この処理に、連合への企業の参加およびこの参加に関連する責任を決定するビジネス契約の確立も含めることができるからである。
連合ビジネス・モデルで信頼を確立する複数の可能な機構がある。連合モデルでは、連合参加者の間の信頼という基本的な概念が、参加者の間で転送されるアサーション（トークン情報および属性情報を含む）が有効であることのあるレベルの保証を提供するために、ビジネス上の理由から必要である。信頼関係がない場合に、サービス・プロバイダは、アイデンティティ・プロバイダから受け取られたアサーションに依存することができず、これらのアサーションは、アイデンティティ・プロバイダから受け取られた情報を解釈する方法を決定するのにサービス・プロバイダが使用することができない。
たとえば、大きい会社が、数千の全世界の顧客をリンクしたい場合があり、その会社が、従来技術の解決策を使用することができる。第１の例として、その会社は、全世界の顧客に、相互信頼を確立するために商業認証局からのディジタル証明書を使用するように要求することができる。商業認証局は、その会社のサーバが、全世界の顧客のそれぞれに配置されたサーバを信頼できるようにする。第２の例として、その会社が、ケルベロスを使用して第三者信頼を実装することができる。その会社およびその全世界の顧客が、共用秘密ベースの信頼を実施する信頼される第三者ケルベロス・ドメイン・サービスを実施することができる。第３の例として、その会社が、その全世界の顧客のサーバによって相互に信頼される独自のセキュリティ・メッセージ・トークンを用いるプライベート方式を確立することができる。
その会社が、少数の全世界の顧客との信頼関係を維持することを必要とする場合に、これらの手法のどれもが許容可能となり得るが、数百または数千の潜在的な連合パートナがある場合には、これが御しがたくなる可能性がある。たとえば、その会社が、より小さいパートナにプライベート方式を実施することを強制することが可能である場合があるが、その会社がより大きいパートナに多数の要件を課すことができる可能性は低い。
本発明を用いると、企業は、信頼プロキシおよび多分信頼ブローカを介して確立され、維持される信頼関係を使用する。本発明の連合アーキテクチャの長所は、企業およびその潜在的な連合パートナの現在のインフラストラクチャを超える追加要件を課さないことである。
しかし、本発明は、連合への参加に必要なビジネス契約および責任契約を確立するのに必要な予備作業から企業およびその潜在的な連合パートナを解放しない。さらに、参加者は、信頼関係の技術的ブートストラップを無視することができない。本発明は、このブートストラップを柔軟にすることを可能にし、たとえば、第１連合パートナが、ある情報を有するケルベロス・チケットを発行することができ、第２連合パートナが、ある情報を有するＳＡＭＬ認証アサーションを発行することができる。
本発明では、信頼関係が、信頼プロキシによって管理され、信頼プロキシは、２つの信頼プロキシの間の事前に確立された関係に基づいてアイデンティティ・プロバイダから受け取られたトークンを有効化し、変換するセキュリティ・トークン・サービスを含む（またはこれと対話する）ことができる。連合した企業がもう１つの連合した企業との信頼関係（およびトークン変換）を確立することが実現可能でない状況では、信頼ブローカを呼び出すことができるが、連合した企業は、信頼ブローカとの関係を確立する必要がある。
図９を参照すると、ブロック図に、本発明による、信頼プロキシおよび信頼ブローカを使用する連合ドメインの間の信頼関係の例示的な組が示されている。図８で信頼ブローカを導入したが、図９には、本発明の連合アーキテクチャ内の推移的信頼関係の重要性が示されている。
連合ドメイン２７１から２７３に、それぞれ、信頼プロキシ２７４から２７６が組み込まれている。信頼プロキシ２７４は、信頼プロキシ２７５との直接信頼関係２７７を有する。信頼ブローカ２８０は、信頼プロキシ２７５との直接信頼関係２７８を有し、信頼ブローカ２８０は、信頼プロキシ２７６との直接信頼関係２７９を有する。信頼ブローカ２８０は、連合参加者の代わりに、他の連合パートナとの推移的信頼に基づく信頼関係を確立するのに使用される。推移的信頼の原理を用いると、信頼プロキシ２７５および信頼プロキシ２７６が、信頼ブローカ２８０を介して信頼関係２８１を仲介させることができるようになる。信頼プロキシ２７５および２７６が、お互いのアサーションを変換または有効化する方法を知る必要はない。信頼ブローカを呼び出して、アサーションを、他方の信頼プロキシで理解される有効で信頼されるアサーションに変換することができる。
連合した企業の間の信頼関係に関する契約上の義務および責任を指定するビジネス契約は、ｅｂＸＭＬ（Electronic Business using XML）標準規格の使用を介してＸＭＬで表すことができる。たとえば、直接信頼関係を、ｅｂＸＭＬ文書で表すことができ、直接信頼関係を共用する各連合ドメインは、ｅｂＸＭＬ文書で表された契約のコピーを有する。連合内のさまざまなエンティティの動作特性は、ｅｂＸＭＬコレオグラフィ（choreography）内で指定され、ｅｂＸＭＬレジストリ内でパブリッシュされる。特定の連合に参加し、たとえば信頼プロキシまたは信頼ブローカを運営することを望むすべての企業が、その特定の連合内のすべての信頼プロキシまたは信頼ブローカについてその連合によって指定されるパブリッシュされた要件に従う必要がある。セキュリティ・トークン・サービスは、他の文書からのトークンが変換される形の動作詳細に関してこれらのｅｂＸＭＬ文書を解析することができる。しかし、連合内の信頼関係が実施される形に関する詳細を指定するために、本発明によって他の標準規格および機構を使用できることに留意されたい。
連合アーキテクチャ内のアサーション処理
上で注記したように、連合内でのユーザの経験は、部分的に、ドメインの間で転送される、ユーザに関するまたはユーザのためのアサーションによって左右される。アサーションは、ユーザの認証状況に関する情報、属性情報、および他の情報を提供する。認証アサーションを使用することによって、ユーザが訪問するすべてのサイトでユーザが再認証する必要をなくすことができる。連合環境内で、発行ドメインから依存ドメインにアサーションを得る２つのモデルすなわち、プッシュ・モデルとプル・モデルがある。プッシュ・モデルでは、ユーザのアサーションが、ユーザの要求と共に依存ドメインに移動する。プル・モデルでは、ユーザの要求が、ある必要な情報なしで依存ドメインで受け取られ、依存ドメインが、関連するアサーションまたは必要なアサーションを発行ドメインに要求する。
連合環境内でアサーションを使用するこれらのモデルを与えられたので、本発明の説明は、本発明の連合環境内でアサーションを作成し、使用する処理の組を説明する図面の組に移る。図１０に、連合環境内でアサーションを作成する、発行ドメインまたは発行当事者での一般化された処理を示し、図１１に、アサーションを「分解」するすなわち、情報を抽出し、分析することによってアサーションをその本質的な情報に縮小する、依存ドメインまたは依存当事者での一般化された処理を示す。図１２および図１３に、アサーションが発行ドメイン内で作られ、その後、ユーザの要求と共に依存ドメインに転送される、プッシュ・モデルの２つの変形形態を示すことによって、図１０に示された一般化された処理の詳細な処理を示す。図１４に、依存ドメインが、発行ドメインにユーザの必要なアサーションを要求すると同時に、依存ドメインが要求元ユーザから受信したリソース要求の満足を試みる、プル・モデルを示す。
図１０を参照すると、流れ図に、連合環境内でアサーションを作成する、発行ドメインでの一般化された処理が示されている。この処理は、発行ドメインの接触点サーバが、アサーションについてトリガされた時に開始される（ステップ３０２）。接触点サーバは、依存ドメインから、所与のユーザの特定のアサーションに関する要求を受け取る場合があり、あるいは、アサーションを必要とする既知の依存ドメインへの発信要求をインターセプトする場合がある。これらのシナリオを、それぞれ図１２および図１３に関して下で詳細に説明する。アサーションについてトリガされたことに応答して、発行ドメインの接触点サーバが、発行ドメインの信頼プロキシにアサーションを要求し（ステップ３０４）、発行ドメインの信頼プロキシが、アサーション／トークンの暗号化／署名など、信頼情報を追加することと共に、アサーションを生成し（ステップ３０６）、発行ドメインの信頼プロキシは、必要な場合に、要求されたアサーションを生成するために信頼ブローカに援助を要求することができる。アサーションを生成した後に、発行ドメインの信頼プロキシが、発行ドメインの接触点サーバにアサーションを返し（ステップ３０８）、発行ドメインの接触点サーバが、たとえばアサーションを発信ＨＴＴＰメッセージまたは発信ＳＯＡＰメッセージに注入することによって、適当な形でアサーションを出力データストリームに注入し（ステップ３１０）、これによって処理が完了する。
図１０に、「ローカル・ウォレット」の使用なしでの発行ドメインでのアサーションの作成の処理が示されている。しかし、本発明は、ローカル・ウォレット機能性を含めることを可能にする。一般に、ローカル・ウォレットは、トランザクションを容易にするユーザ属性または他の情報に関するセキュア・データストアとして働くことができるクライアント側コードであり、このクライアント側コードは、アサーション転送のプッシュ・モデルまたはプル・モデルあるいはその両方に参加することもできる。ローカル・ウォレットが、プロトコルに能動的に参加する場合に、ローカル・ウォレットは、アサーションの生成およびプロトコル・フローへの挿入に関して、接触点サーバ機能性の機能性のサブセットを実装する。ローカル・ウォレットを使用することは、ローカル・ウォレットが接触点サーバと信頼プロキシの間で行われる信頼ベース対話を実装できるようにしない。追加の信頼関係が必要な場合には、接触点サーバを呼び出さなければならない。
図１１を参照すると、流れ図に、アサーションを分解する、依存ドメインでの一般化された処理が示されている。この処理は、依存ドメインの接触点サーバが、関連するアサーションと共にメッセージを受け取る時に開始され（ステップ３２２）、その後、依存ドメインの接触点サーバが、アサーションを抽出し、そのアサーションを依存ドメインの信頼プロキシに転送する（ステップ３２４）。依存ドメインの信頼プロキシが、発行ドメインから受け取ったトークンを含む情報をアサーションから抽出し（ステップ３２６）、依存ドメインの信頼プロキシは、トークン内の情報と暗号化および署名などのトークンに関する信頼情報を含むこのトークンを有効化するためにセキュリティ・トークン・サービスを呼び出し、その後、適当な場合にローカルに有効なトークンをユーザに返す（ステップ３２８）。
ステップ３２６の一部として、信頼プロキシは、アサーションのソースすなわち発行当事者を判定する。信頼プロキシが、この発行ドメインから受け取った信頼アサーションを理解できる場合には、信頼プロキシは、ステップ３２８を内部で実行する。信頼プロキシが、その発行ドメインから受け取ったアサーションを理解／信頼できない場合には、信頼プロキシは、信頼ブローカからの援助を呼び出すことができる。アサーションを有効化できない場合には、適当なエラー応答が生成される。
アサーションが有効化されたと仮定すると、依存ドメインの信頼プロキシが、ユーザについて要求されたローカル情報を作成する（ステップ３３０）。たとえば、このローカル情報に、バックエンド・レガシ・アプリケーションによって要求された認証信任証を含めることができる。依存ドメインの信頼プロキシが、要求された情報を依存ドメインの接触点サーバに返し（ステップ３３２）、この接触点サーバが、ユーザに関するローカル・セッションを作成する。
接触点サーバが、ユーザのセッションを作成した後に、ユーザは、認証されたユーザに見える。接触点サーバは、このセッション情報を使用して、ログアウトまたはタイムアウト・イベントが開始されるまで、そのユーザがドメインに関して有するすべてのトランザクションを左右することができる。接触点サーバが、ユーザの認証されたアイデンティティを有するならば、接触点サーバは、この特定のユーザのアイデンティティおよびこの特定のユーザに関連する許可ポリシに基づいて必要な場合に、この要求に関する許可を入手することができる。接触点サーバは、次に、ユーザの要求を関連する情報と共に要求されたバックエンド・アプリケーションまたはサービスに転送し（ステップ３３４）、これによって処理が完了する。
接触点サーバと信頼プロキシの間で転送されるデータ項目およびこのデータ項目のフォーマットを変更できることに留意されたい。メッセージからアサーションを抽出し、信頼プロキシにアサーションだけを転送するのではなく、接触点サーバは、メッセージ全体を信頼プロキシに転送することができる。たとえば、信頼プロキシでの処理に、ＳＯＡＰメッセージのシグネチャ有効化などのステップを含めることができるが、これはＳＯＡＰエンベロープ全体を必要とする。
図１２を参照すると、流れ図に、発行ドメインでのユーザ・アクションに応答する、発行ドメインから依存ドメインへのアサーションのプッシュに関する特定の処理が示されている。この処理は、ユーザが、発行ドメイン内のウェブ・ページまたは類似するリソースから依存ドメインへのリンクにアクセスする時に開始され（ステップ３４２）、これによって、ある形のＣＧＩタイプ（コモン・ゲートウェイ・インターフェース）処理が呼び出されて、特定のアサーションが作成される。依存ドメインによるアサーションの必要を認識する発行ドメインの能力は、本発明の連合インフラストラクチャが実施される既存レガシ・システムとの緊密な統合を暗示する。これは、発行当事者が必要なアサーションを作成するために信頼プロキシを呼び出す必要がなくなるようにする、発行当事者と依存当事者の間の密結合も暗示し、この密結合は、明確に確立された信頼関係を有するあるタイプの連合エンティティの間で適当である可能性がある。
発行ドメインのバックエンド処理が、必要なアサーションを作成するために呼び出され（ステップ３４４）、これには、ローカル信頼プロキシでの機能性を呼び出すことを含めることができる。必要なアサーションを含む依存ドメインに対するユーザの要求が、作成され（ステップ３４６）、発行ドメインが、依存ドメインに、ユーザの要求と共にアサーションを転送し（ステップ３４８）、これによって処理が完了する。依存ドメインが、この要求および関連するアサーションを受け取る時に、依存ドメインは、図１１に示した形でアサーションを有効化する。
図１３を参照すると、流れ図に、発行ドメインが依存ドメインへの発信要求を能動的にインターセプトすることに応答する、発行ドメインから依存ドメインへのアサーションのプッシュに関する特定の処理が示されている。この処理は、ユーザが、依存ドメインの保護されたリソースを要求する時に開始される（ステップ３５２）。接触点サーバが、たとえば、所定のＵＲＩ（Uniform Resource Identifier）、あるタイプのメッセージ、あるタイプのメッセージ内容、または他の形で発信メッセージをフィルタリングすることによって、発信要求をインターセプトする（ステップ３５４）。次に、発行ドメインの接触点サーバが、発行ドメインの信頼プロキシに適当なアサーションを生成するように要求し（ステップ３５６）、この発行ドメインの信頼プロキシが、必要な場合に信頼ブローカから援助を得て、アサーションを生成する（ステップ３５８）。次に、発行ドメインが、生成されたアサーションと共にユーザの要求を依存当事者に転送し（ステップ３６０）、これによって処理が完了する。依存ドメインは、要求およびそれに関連するアサーションを受け取った時に、図１１に示した形でアサーションを有効化する。
図１４を参照すると、流れ図に、依存ドメインが、発行ドメインにユーザの必要なアサーションを要求すると同時に、依存ドメインが要求元ユーザから受信したリソース要求の満足を試みる、プル・モデルが示されている。この処理は、依存ドメインが、保護されたリソースに関するユーザ要求を受信した時に開始される（ステップ３７２）。図１２または図１３に示された例とは対照的に、図１４に示された例では、ユーザに関する必要なアサーションなしで依存ドメインで受信されたユーザの要求に関連する処理を説明する。この場合に、発行ドメインは、必要なアサーションをユーザの要求に挿入するためにユーザの要求をインターセプトするか他の形で処理する能力を有しなかった。たとえば、ユーザは、発信要求が発行ドメインの接触点サーバによってインターセプトされない形で、ＵＲＬ（Uniform Resource Locator）を入力したか、リソースへのブックマークに記録された参照を使用した可能性がある。したがって、依存ドメインは、発行ドメインにアサーションを要求する。
次に、依存ドメインが、ユーザのホーム・ドメインすなわち、関連する発行ドメインを判定する（ステップ３７４）。ＨＴＴＰベースの実施形態では、ユーザが、ユーザのクライアント・デバイスで依存ドメインによってセットされた永続クッキーをもたらした、依存ドメインとの事前に確立された関係を有する場合がある。永続クッキーに、ユーザのホーム・ドメインまたはアイデンティティ・プロバイダすなわち関連する発行ドメインのアイデンティティが含まれる。ユーザがある形でウェブ・サービス・クライアントを操作しているＳＯＡＰベースの実施形態では、依存ドメイン側のウェブ・サービスが、トークン要件を含むサービス要件をＷＳＤＬ（Web Services Description Language）を介してアドバタイズ済みである。これは、ユーザのウェブ・サービス・クライアント／ＳＯＡＰ実施形態が必要なトークン・タイプを提供することを必要とする。この要件が満足されない場合に、ウェブ・サービスは、技術的にエラーを返す。いくつかの場合に、ウェブ・サービスは、ユーザのウェブ・サービス・クライアントが認証情報についてプロンプトを出され、その結果、この要求を適当なトークンを用いて繰り返せるようにするエラー・コードを返すことができる。
依存ドメインの接触点サーバが、依存ドメインの信頼プロキシと共にアサーション要求を開始し（ステップ３７６）、依存ドメインの信頼プロキシが、発行ドメインの信頼プロキシにユーザのアサーションを要求する（ステップ３７８）。実施形態が、ＨＴＴＰベース通信を使用している場合に、依存ドメインの信頼プロキシから発行ドメインの信頼プロキシへのアサーション要求を、ユーザのブラウザ・アプリケーションを介するリダイレクションを介して依存ドメインの接触点サーバによって発行ドメインの接触点サーバに送信することができ、発行ドメインの接触点サーバは、このアサーション要求を発行ドメインの信頼プロキシに転送する。
実施形態が、ＳＯＡＰベースの実施形態を使用している場合に、依存当事者は、ユーザのウェブ・サービス・クライアントにエラー・コードを返すことができる。このエラー・コードを用いて、ユーザに、ウェブ・サービス・クライアントによって認証情報を求めるプロンプトを出すことができる。次に、ウェブ・サービス・クライアントが、要求されたトークンを生成する。依存ドメインの信頼プロキシがＵＤＤＩ（Universal Description, Discovery, and Integration）レジストリでアドバタイズされ、ユーザのウェブ・サービス・クライアントがその信頼プロキシを見つけることができるならば、ユーザのウェブ・サービス・クライアントは、信頼プロキシを直接に呼び出すことができる。一般に、このシナリオは、信頼プロキシが企業内のプライベートＵＤＤＩでアドバタイズされた内部ユーザに限って有効である。というのは、信頼プロキシが、インターネットまたは一般にアクセス可能な連合の外部にあるパブリックＵＤＤＩでアドバタイズされる可能性が低いからである。
発行ドメインの信頼プロキシは、アサーション要求が受信された形の鏡像の形で、要求されたアサーションを生成し（ステップ３８０）、返す（ステップ３８２）。依存ドメインの信頼プロキシが、要求されたアサーションを受信（ステップ３８４）した後に、依存ドメインの信頼プロキシが、アサーションから情報を抽出し（ステップ３８６）、アサーションの解釈または有効化あるいはその両方を試み（ステップ３８８）、この信頼プロキシは、アサーションの変換に必要な場合に、信頼ブローカからの援助を呼び出すことができる。アサーションを有効化できない場合に、適当なエラー応答が生成される。アサーションが有効化されたと仮定すると、依存ドメインの信頼プロキシが、保護されたリソースに関するユーザの要求を満足することを試みるバックエンド・サービスによる使用に必要な適当なフォーマットでローカル情報を作成する（ステップ３９０）。たとえば、このローカル情報に、バックエンド・レガシ・アプリケーションが必要とする認証信任証を含めることができる。依存ドメインの信頼プロキシが、依存ドメインの接触点サーバに必要な情報を返し（ステップ３９２）、依存ドメインの接触点サーバが、ユーザのローカル・セッションを作成し、ユーザの要求をすべての関連情報と共に、要求されたバックエンド・アプリケーションまたはサービスに転送し（ステップ３９４）、これによって処理が完了する。
連合アーキテクチャ内のシングルサインオン
図６から９の説明では、本発明による連合したデータ処理環境内のエンティティの動作特性に焦点を合わせ、図１０から１４の説明では、これらのエンティティの間で行われる処理の一部に焦点を合わせた。この説明と対照的に、ユーザにシングルサインオン経験を提供しながらユーザのトランザクションを完了するという目標に焦点を合わせた本発明の説明のために、図１５を参照する。
言い換えると、下の説明では、既に上で述べたエンティティおよび処理を述べるが、次の説明では、ユーザがユーザのセッション内でシングルサインオン経験を有することができる形に関する本発明の概要の展望に焦点を合わせる。セッションは、最初のユーザ認証すなわちログオンから（これを含む）ログアウトまでのトランザクションの組と定義することができる。セッション内で、ユーザのアクションは、部分的に、そのセッションについてユーザに与えられる特権によって左右される。連合内で、ユーザは、セッション中に訪問される連合パートナに無関係に、ユーザが単一の認証動作を実行し、そのセッションの期間中にこの認証動作で十分である、シングルサインオン経験を有することを期待する。
ユーザのセッション中に、ユーザは、多数の連合ドメインを訪問して、これらのドメインによって提供されるウェブ・サービスを使用することができる。ドメインは、ＵＤＤＩおよびＷＳＤＬ（両方が共通データ・フォーマットとしてＸＭＬを使用する）などの標準仕様を使用することによって、提供するサービスの記述をパブリッシュすることができる。ユーザは、やはりこの標準仕様を厳守するアプリケーションを介して、使用可能なサービスおよびサービス・プロバイダを見つける。ＳＯＡＰは、ＸＭＬで表された要求および応答を通信するパラダイムを提供する。連合環境内のエンティティは、とりわけ、これらの標準規格を使用することができる。
シングルサインオン経験を容易にするために、連合環境をサポートするウェブ・サービスは、ユーザの認証の証拠を提供するために第三者によって生成された認証アサーションまたはセキュリティ・トークンの使用をサポートする。このアサーションに、ユーザの識別子と共に、発行当事者へのそのユーザの成功裡の認証のある種の証拠が含まれる。したがって、ユーザは、たとえばユーザ名およびパスワードなどの伝統的な認証信任証をある連合パートナに提示し、その後、認証する／発行する当事者によって生成されたＳＡＭＬ認証アサーションを異なる連合パートナに供給することができる。
ウェブ・サービス環境での認証は、ウェブ・サービス要求の主張されたアイデンティティを検証し、その結果、企業が、アクセスを、許可されたクライアントに制限できるようにする動作である。ウェブ・サービスを要求するか呼び出すユーザは、ほとんど必ず認証され、したがって、本発明の連合環境内での認証の必要は、ユーザ認証に関するウェブ・サービスの現在の要件と異ならない。連合環境は、ウェブ・サービスまたは他のアプリケーションがウェブ・サービスを要求することも可能にし、これらのウェブ・サービスも、認証される。
連合セッションに参加していないユーザの認証は、本発明の連合アーキテクチャによって影響されない。たとえば、ＨＴＴＰ／Ｓを介するフォームベースの認証機構を用いて認証して、特定のドメインの非連合リソースにアクセスする既存ユーザは、そのドメインでの連合環境に関するサポートの導入によって影響されない。認証は、部分的に、接触点サーバによって処理され、この接触点サーバは、別々の信頼プロキシ構成要素を呼び出すことができる。接触点サーバを使用することによって、既存ドメインのインフラストラクチャに対する影響が最小限になる。たとえば、ドメインのバックエンド・アプリケーションまたはレガシ・アプリケーションおよびシステムによって処理される非連合要求のすべてをパス・スルーするように接触点サーバを構成することができる。
接触点サーバは、基本的な認証、フォームベース認証、または他の認証方法など、ＨＴＴＰベースの認証方法を呼び出すことを選択することができる。接触点サーバは、ＳＡＭ認証アサーションなど、認証の証拠としてユーザによって提示されたアサーションを認識することによって、連合信頼ドメインもサポートし、ここで、アサーションは、企業信頼ドメインの間を横切っている。接触点サーバは、信頼プロキシを呼び出すことができ、この信頼プロキシは、認証信任証／セキュリティ・トークンの有効化のためにそのセキュリティ・トークン・サービスを呼び出すことができる。
ウェブ・サービスまたは他のアプリケーションの認証に、ユーザの認証と同一の処理が含まれる。ウェブ・サービスからの要求は、認証アサーションを含むセキュリティ・トークンを担持し、このセキュリティ・トークンは、ユーザによって提示されるトークンと同一の形で、信頼プロキシ／セキュリティ・トークン・サービスによって有効化される。ウェブ・サービスからの要求は、必ずこのトークンをそれと共に担持しなければならない。というのは、ウェブ・サービスが、ＵＤＤＩでアドバタイズされた、要求されるサービスが要求した認証アサーション／セキュリティ・トークンを発見しているからである。
図１５を参照すると、ブロック図に、連合シングルサインオン動作をサポートする連合環境が示されている。ユーザ４００は、クライアント・デバイスおよびブラウザなどの適当なクライアント・アプリケーションを介して、企業／ドメイン４１０によって提供されるウェブ・サービスにアクセスすることを望み、企業／ドメイン４１０は、連合環境内で連合ドメインとして働くデータ処理システムをサポートする。ドメイン４１０は、接触点サーバ４１２および信頼プロキシ４１４をサポートし、同様に、ドメイン４２０は、接触点サーバ４２２および信頼プロキシ４２４をサポートし、ドメイン４３０は、接触点サーバ４３２および信頼プロキシ４３４をサポートする。信頼プロキシは、上で説明したように、援助について信頼ブローカ４５０に頼る。追加のドメインおよび信頼プロキシが、この連合環境に参加することができる。図１５では、ドメイン４１０とドメイン４２０の間の連合シングルサインオン動作が説明されており、類似する動作を、ドメイン４１０とドメイン４３０の間で行うことができる。
ユーザは、ドメイン４１０に関して認証動作を完了する。この認証動作は、接触点サーバ４１２によって処理される。この認証動作は、ユーザが、たとえばアクセス制御のためまたはパーソナライゼーションのために、認証されたアイデンティティを必要とするあるリソースへのアクセスを要求する時にトリガされる。接触点サーバ４１２は、レガシ認証サービスを呼び出すことができ、あるいは、信頼プロキシ４１４を呼び出して、ユーザが提示した認証信任証を有効化することができる。ドメイン４１０は、このユーザの連合セッション中に、このユーザのアイデンティティ・プロバイダまたはホーム・ドメインになる。
ある後の時点で、ユーザが、やはり連合ドメインをサポートする企業４２０などの連合パートナでのトランザクションを開始し、これによって連合シングルサインオン動作をトリガする。たとえば、ユーザが、ドメイン４２０で新しいトランザクションを開始することができ、あるいは、ユーザのオリジナル・トランザクションが、他のドメインの１つまたは複数の追加トランザクションにカスケードされる場合がある。もう１つの例として、ユーザが、たとえば、ドメイン４１０内でホスティングされるウェブ・ページの特殊なリンクを選択することによって、またはドメイン４１０でホスティングされるがドメイン４２０でホスティングされるリソースを表示するポータル・ページを要求することによって、接触点サーバ４１２を介してドメイン４２０内のリソースへの連合シングルサインオン動作を開始することができる。接触点サーバ４１２は、ドメイン４２０によって理解されるか信頼されるフォーマットにされた、そのユーザの連合シングルサインオン・トークンを生成する要求を信頼プロキシ４１４に送る。信頼プロキシ４１４は、このトークンを接触点サーバ４１２に返し、接触点サーバ４１２は、このトークンをドメイン内の接触点サーバ４２２に送信する。ドメイン４１０は、ドメイン４２０でユーザの発行当事者として働き、ドメイン４２０は、依存当事者として働く。ユーザのトークンは、ユーザの要求と共にドメイン４２０に転送される。このトークンは、ユーザのブラウザを介してＨＴＴＰリダイレクションを使用して送信することができ、あるいは、信頼プロキシ４１４によって供給されるトークンで識別されるユーザの代わりに接触点サーバ４２２について（ＨＴＴＰまたはＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰを介して）直接に要求を呼び出すことによって送信することができる。
接触点サーバ４２２は、連合シングルサインオン・トークンと一緒に要求を受信し、信頼プロキシ４２４を呼び出す。信頼プロキシ４２４は、連合シングルサインオン・トークンを受け取り、このトークンを有効化し、トークンが有効であり、信頼されると仮定すると、ユーザに関するローカルに有効なトークンを生成する。信頼プロキシ４２４は、ローカルに有効なトークンを接触点サーバ４２２に返し、接触点サーバ４２２は、ドメイン４２０内でユーザのセッションを確立する。必要な場合に、接触点サーバ４２２は、別の連合パートナで連合シングルサインオンを開始することができる。
ドメイン４２０でのトークンの有効化は、信頼プロキシ４２４によって、多分セキュリティ・トークン・サービスの援助を得て処理される。ドメイン４１０によって提示されるトークンのタイプに応じて、セキュリティ・トークン・サービスが、ドメイン４２０のユーザ・レジストリにアクセスする必要がある場合がある。たとえば、ドメイン４２０は、ドメイン４２０のユーザ・レジストリに対して有効化されるユーザの名前およびパスワードを含むバイナリ・セキュリティ・トークンを提供することができる。したがって、この例では、企業が、単純に、連合パートナからのセキュリティ・トークンを有効化する。ドメイン４１０と４２０の間の信頼関係によって、ドメイン４２０が、ユーザの代わりにドメイン４１０によって提示されたセキュリティ・トークンを理解でき、信頼できることが保証される。
連合シングルサインオンは、ユーザの代わりに依存ドメインに提示されるセキュリティ・トークンの有効化だけではなく、セキュリティ・トークンに含まれる情報に基づく依存ドメインでのローカルに有効なユーザ識別子の判定も必要とする。直接信頼関係と、そのような関係を確立するのに必要なビジネス契約の結果の１つが、少なくとも１つの当事者すなわち発行ドメインまたは依存ドメインの一方または両方が、発行ドメインによって供給された情報を依存ドメインで有効な識別子に変換する方法を知っていることである。上の短い例では、発行ドメインすなわちドメイン４１０が、依存ドメインすなわちドメイン４２０に、ドメイン４２０で有効なユーザ識別子を供給できると仮定した。そのシナリオでは、依存ドメインが、アイデンティティ・マッピング機能性を呼び出す必要がなかった。ドメイン４２０の信頼プロキシ４２４が、ユーザを「保証」する、そのユーザのセキュリティ・トークンを生成する。受け入れられるトークンのタイプ、トークンに必要な署名、および他の要件は、すべて、連合のビジネス契約の一部として事前に確立されたものである。識別子変換を決定する規則およびアルゴリズムも、連合のビジネス契約の一部として事前に確立されたものである。２つの当事者の間の直接信頼関係の場合に、識別子変換アルゴリズムは、この２つの当事者について確立され、連合の他の当事者に関連しない場合がある。
しかし、発行ドメインが、必ず、ドメイン４１０のローカル識別子からドメイン４２０のローカル識別子へユーザをマッピングする方法を知っているとは限らない。いくつかの場合に、このマッピングの方法を知っているのが依存ドメインである場合があり、別の場合に、両方の当事者がこの変換の方法を知らない場合があり、この場合には、第三者の信頼ブローカを呼び出す必要がある場合がある。言い換えると、仲介された信頼関係の場合に、発行ドメインおよび依存ドメインは、お互いに関する直接信頼関係を有しない。しかし、これらは、信頼ブローカ４５０などの信頼ブローカとの直接信頼関係を有する。識別子マッピングの規則およびアルゴリズムは、この関係の一部として確立され、信頼ブローカは、この情報を使用して、仲介された信頼関係に必要な識別子変換において援助する。
ドメイン４２０は、ドメイン４１０によって発行されたトークンを接触点サーバ４２２で受信し、接触点サーバ４２２は、信頼プロキシ４２４を呼び出して、このトークンを有効化し、アイデンティティ・マッピングを実行する。この場合に、信頼プロキシ４２４は、ドメイン４１０のローカル識別子からドメイン４２０のローカル識別子にユーザをマッピングすることができないので、信頼プロキシ４２４は、信頼ブローカ４５０を呼び出し、信頼ブローカ４５０が、トークンを有効化し、識別子マッピングを実行する。ユーザのローカル識別子を入手した後に、信頼プロキシ４２４は、多分そのセキュリティ・トークン・サービスを介して、ドメイン４２０のバックエンド・アプリケーションが必要とするローカル・トークンを生成することができ、たとえば、接触点サーバからアプリケーション・サーバへのシングルサインオンを容易にするために、ケルベロス・トークンが必要である場合がある。ローカルに有効なトークンを入手した後に、必要な場合に、接触点サーバは、ユーザのローカル・セッションを作成することができる。接触点サーバは、ユーザ要求の粗粒度許可も処理し、許可された要求をドメイン４２０内の適当なアプリケーション・サーバに転送する。
ユーザのセッションは、ユーザがログアウトするかサインオフする時に打ち切られる。ユーザが、ホーム・ドメインのセッションからログ・アウトする時に、ホーム・ドメインは、すべての依存ドメインすなわち、そのホーム・ドメインがセキュリティ・トークンを発行したドメインに通知し、これらのドメインでのユーザ・ログアウトを呼び出す。これらの依存ドメインのいずれかが、同一ユーザについて発行ドメインとして働いた場合に、これらのドメインも、カスケードする形で、そのすべての依存ドメインにユーザ・ログアウト要求について通知する。各ドメインの信頼プロキシは、ユーザのログアウト要求についてすべての依存ドメインに通知する責任を負い、信頼プロキシは、この処理の一部として信頼ブローカを呼び出すことができる。
連合ユーザ・ライフサイクル管理
上の図６から１５の説明の一部で、連合環境で使用できる構成要素の編成を説明し、他の部分で、連合環境にまたがるシングルサインオン動作をサポートする処理を説明した。連合環境内のサービス・プロバイダまたは依存ドメインは、必ずしもユーザの認証信任証を管理する必要がなく、これらの依存ドメインは、ユーザのアイデンティティ・プロバイダまたはホーム・ドメインによって提供される単一のシングルサインオン・トークンを活用することができる。しかし、上の図６から１５の説明では、連合ユーザ・ライフサイクル管理を連合パートナの連合ドメインで有利な形で達成できる明示的な処理を説明しなかった。
連合ユーザ・ライフサイクル管理機能性／サービスに、複数の連合ドメインで所与のユーザの特定のユーザ・アカウントまたはユーザ・プロファイルに関する連合した動作をサポートまたは管理する機能が含まれる。いくつかの場合に、これらの機能または動作は、ユーザに関する所与の連合セッションに制限される。言い換えると、連合ユーザ・ライフサイクル管理機能性は、多分連合コンピューティング環境内での単一のユーザ・セッションのライフサイクル中だけの、複数の連合パートナにまたがる連合した動作の管理を可能にする機能を指す。
各連合ドメインは、各めいめいの連合ドメインでの機能に関して、ある種のユーザ・アカウント、ユーザ・プロファイル、またはユーザ・セッションを管理することができる。たとえば、特定の連合ドメインが、その特定の連合ドメイン内でローカル・ユーザ・アカウントまたはローカル・ユーザ・プロファイルを管理しない場合があるが、その連合ドメインは、その連合ドメインでのシングルサインオン動作の成功裡の完了後に、連合トランザクションのローカル・ユーザ・セッションを管理することができる。その特定の連合ドメインによってサポートされる連合ユーザ・ライフサイクル管理機能性の一部として、その連合ドメインは、連合トランザクションが完了した後にその連合ドメインがローカル・ユーザ・セッションを打ち切ることを可能にするシングルサインオン動作に参加することができ、これによって、セキュリティを改善し、リソースの効率的な使用を促進することができる。
連合ユーザ・ライフサイクル管理機能性の使用のもう１つの例で、ユーザは、複数の連合ドメインの参加を必要とするオンライン・トランザクションにかかわることができる。連合ドメインは、連合ドメインを含むユーザの連合セッションのそれぞれの間の連合ドメインに関するユーザの経験を調整するために、ユーザ・プロファイルをローカルに管理することができる。その特定の連合ドメインによってサポートされる連合ユーザ・ライフサイクル管理機能性の一部として、連合ドメインのローカル・ユーザ・プロファイルの情報を、所与の連合トランザクション中に、所与の連合トランザクションに参加している他の連合ドメインの他のプロファイルからの情報と共にシームレスな形で使用することができる。たとえば、ユーザの複数のローカル・ユーザ・プロファイルからの情報を、あるタイプのマージ動作で組み合わせ、ユーザの情報を、たとえばウェブ・ページ内で、ユーザがユーザの情報の異なる出所またはソースを知らない形でユーザに視覚的に提示することができる。
連合ユーザ・ライフサイクル管理機能性に、アカウント・リンク／リンク解除の機能も含めることができる。ユーザは、連合パートナにまたがる共通の一意ユーザ識別子を与えられ、これによって、１つの連合パートナでの要求の満足の一部として、シングルサインオンおよびユーザに関する属性の取り出し（必要な場合に）が可能になる。さらに、連合パートナは、匿名の形でユーザに言及するために、共通の一意ユーザ識別子を使用して、アイデンティティ・プロバイダに追加属性を要求することができる。
上で、連合ユーザ・ライフサイクル管理機能性を使用して達成できる動作の異なる例に注意した後に、下で、残りの図面で、本発明が有利な形で連合ユーザ・ライフサイクル管理機能性を提供し、サポートする形を示す。
図１６を参照すると、ブロック図に、本発明の実施形態による、連合ユーザ・ライフサイクル管理機能性を実施する連合ドメイン内の構成要素の一部が示されている。図１６に、図８に示された企業２５０によって運営される連合ドメインなどの単一の連合ドメインの要素が示されている。図１６の要素の一部は、図７などの他の図面に関して上で述べた要素に類似するか、これと同一である。接触点サーバ／サービス５０２は、接触点サーバ２４２と同等であり、アプリケーション・サーバ５０４すなわちリソース制御サービスは、アプリケーション・サービス２３４と同等であり、保護されたリソースまたは制御されたリソース５０６は、保護されたリソース２３５と同等であり、連合ユーザ・ライフサイクル管理（ＦＵＬＭ）アプリケーション５０８は、連合ユーザ・ライフサイクル管理サーバ２４６と同等である。ファイヤウォールは、図７には示されていないが、図１６には示されている。ファイヤウォール５１０およびファイヤウォール５１２は、企業のコンピューティング環境を、たとえばインターネットを介する、企業のドメインの外部のコンピューティング脅威から保護する外部ＤＭＺ（電子非武装地帯）を作成する。
図１６および図７に示された異なる展望は、非互換であるか相反する目的を有する。図１６に示された例と対照的に、図７には、ファイヤウォールが示されていないが、接触点サーバ２４２は、連合フロントエンド２４０内に常駐し、さらに、連合ユーザ・ライフサイクル管理サーバ２４６は、連合フロントエンド２４０に含まれる。図１６では、接触点サーバ５０２が、ファイヤウォール５１０および５１２の間のＤＭＺ内にあるものとして図示され、ファイヤウォール５１０および５１２は、企業ドメインへの電子フロントエンドまたは物理フロントエンドを形成する。さらに、連合ユーザ・ライフサイクル管理アプリケーション／サービス５０８は、電子的にファイヤウォール５１２の背後にある。図７の連合フロントエンド２４０およびバックエンド２３０を構成要素の論理編成と見なし、図１６のＤＭＺおよび他の構成要素を、連合構成要素を含むことができる物理フロントエンドまたは電子フロントエンドおよび物理バックエンドまたは電子バックエンドと見なすことによって、異なる展望を調和させることができる。
接触点エンティティ／サービスの役割を繰り返すと、接触点エンティティは、少なくとも企業のコンピューティング環境との連合機能性とのユーザ対話に関して、セッション管理を提供し、企業のコンピューティング環境のレガシ・バックエンド内のアプリケーションも、それ自体のセッション管理機能性を実施することができる。企業が、連合コンピューティング環境に関するポリシ機能性を実施すると仮定すると、接触点エンティティは、他の連合パートナのポリシ決定ポイントに対するポリジ実施ポイントとして働くことができる。さらに、連合機能の実施を条件にこれが許されると仮定すると、接触点エンティティは、シングルサインオン動作が使用されないシナリオでユーザに対して方向認証（direction authentication）動作を開始する責任を負う。したがって、接触点エンティティは、たとえば逆プロキシ・サーバとして、ウェブ・サーバ・プラグインとして、または他の形でなど、さまざまな形で実施することができる。接触点機能性は、アプリケーション・サーバ自体の中で実施することもでき、この場合に、連合ユーザ・ライフサイクル管理サービスを、ＤＭＺ内に置くことができる。
より重要なことに、図１６を参照すると、連合ユーザ・ライフサイクル管理アプリケーション５０８に、図７に示されていない連合ユーザ・ライフサイクル管理プラグイン５１４にインターフェースし、これと対話し、または他の形でインターオペレートするためのサポートも含まれる。本発明では、連合プロトコル・ランタイム・プラグインが、WS-Federation Passive Client；Liberty Alliance ID-FFシングル・サイン・オン（Ｂ／Ａ、Ｂ／Ｐ、およびＬＥＣＰ）；RegisterName Identifier；Federation Termination Notification；およびSingle Logoutなどのさまざまなタイプの独立にパブリッシュまたは開発された連合ユーザ・ライフサイクル管理の標準規格またはプロファイルの機能性を提供する。
本発明の例示的実施形態では、連合プロトコルの異なる組に、異なるＵＲＩでアクセスすることができる。この手法を用いると、連合ユーザ・ライフサイクル管理アプリケーションが、たとえばWS-Federationウェブ・サービス仕様対Liberty Allianceの仕様など、連合ユーザ・ライフサイクル管理の複数の標準規格または仕様を単一のアプリケーション内で同時にサポートできるようになり、これによって、異なる連合プロトコルをサポートするための環境全体に対する構成の影響が最小になる。
具体的に言うと、適当な連合ユーザ・ライフサイクル管理機能性が、接触点サーバによって、適当にユーザ要求を連合ユーザ・ライフサイクル管理アプリケーションにリダイレクトまたは転送あるいはその両方を行うことによって呼び出される。もう一度図１６を参照すると、接触点サーバ５０２は、ユーザ要求５２０を受け取り、このユーザ要求５２０が分析されて、受け取られた要求のタイプが判定され、このタイプは、受け取られた要求メッセージのタイプによって、または上で注記したように、要求メッセージ内の宛先ＵＲＩを判定することによって示すことができる。保護されたリソースに関する要求５２２は、アプリケーション・サーバ５０４に転送され続けるが、連合ユーザ・ライフサイクル管理機能に関する要求５２４、たとえばシングルサインオフ動作を呼び出す要求は、連合ユーザ・ライフサイクル管理アプリケーション５０８に転送され、連合ユーザ・ライフサイクル管理アプリケーション５０８は、受け取った要求を満足する必要に応じて、適当な連合ユーザ・ライフサイクル管理プラグインを呼び出す。新しい連合プロトコルまたは新しい連合機能が定義される時、または既存の連合プロトコルまたは連合機能が変更されるか再定義される時に、サポートを、単純に新しいサポート・モジュールをプラグすることによって追加でき、あるいは、前にインストールされたプラグインを変更することによって再定義することができる。
図１６の連合ユーザ・ライフサイクル管理アプリケーションの例示的実施形態には、連合ユーザ・ライフサイクル管理アプリケーションが、プラグ可能性特徴を提供しながら、複数の同時の連合ユーザ・ライフサイクル管理機能をサポートすることができ、これによって、必要な時に、既存インフラストラクチャに対する変更を必要とせずに、プラグインの形で新しい機能性を連合ユーザ・ライフサイクル管理アプリケーションに追加できることが示されている。たとえば、本発明が、Ｊａｖａ（商標）ベース連合ユーザ・ライフサイクル管理アプリケーションを使用して実施されると仮定すると、新たにパブリッシュされたシングルサインオン・プロトコルなどの新しい連合プロトコルのサポートは、新たに開発されたＪａｖａ（商標）クラスを構成することによって、連合ユーザ・ライフサイクル管理アプリケーションのＪａｖａ（商標）ＣＬＡＳＳＰＡＴＨに追加でき、これらの新しいクラスは、本発明のプロトコル・インターフェースと共に新しい標準規格をサポートする。
本発明は、連合ユーザ・ライフサイクル管理解決策を統合できる既存環境を活用する。連合ユーザ・ライフサイクル管理アプリケーションは、新しいプロトコル／標準規格をサポートするために簡単に変更することができる。というのは、インフラストラクチャ全体に対する最小限の変更が展開されるからである。新しい連合ユーザ・ライフサイクル管理機能性をサポートするのに必要になる可能性がある変更は、ほぼ排他的に、連合ユーザ・ライフサイクル管理アプリケーション内にあり、これは、追加機能性を理解するように連合ユーザ・ライフサイクル管理アプリケーションを構成することを必要とする。
インフラストラクチャ全体が新しい連合ユーザ・ライフサイクル管理機能性を呼び出すことができると同時に既存連合ユーザ・ライフサイクル管理機能性をサポートし続けることを可能にするために、たとえば、接触点サーバなどの他の連合構成要素内に、最小限の構成変更がある可能性がある。しかし、連合ユーザ・ライフサイクル管理アプリケーションは、連合ユーザ・ライフサイクル管理アプリケーションが連合環境の他の連合構成要素との最小限の対話だけを必要とする可能性があるという点で、連合構成要素の残りと機能的に独立である。たとえば、例示的実施形態で、Liberty AllianceプロファイルによるNameIdentifier値などの連合ユーザ・ライフサイクル管理情報が、外部エンティティに明白またはアクセス可能でないプライベートな内部の連合ユーザ・ライフサイクル管理データストアではなく、外部からアクセス可能な連合ユーザ・ライフサイクル管理データストアに保管される場合に、連合ユーザ・ライフサイクル管理機能性を、たとえばＬＤＡＰデータストアなどの企業ベース・データストアと一体化することができる。
したがって、既存環境は、本発明に従って実施される時に、連合ユーザ・ライフサイクル管理機能性をサポートするために最小限の変更を必要とする。さらに、新しい機能性の追加を含む連合ユーザ・ライフサイクル管理機能性に対する変更は、既存の連合環境に対する最小限の影響を有する。したがって、新しいシングルサインオン標準規格がパブリッシュされた時に、この標準規格のサポートが簡単に追加される。
伝統的なユーザ認証は、企業のコンピューティング環境とエンドユーザだけの間の対話を用いる。企業がこの認証交換を実施するために選択する形は、その企業の選択であり、他の企業への影響を有しない。しかし、連合シングルサインオン機能性またはクロスドメイン・シングルサインオン機能性のサポートが望まれる時に、企業パートナが互いに対話することが要件になる。この要件は、独自プロトコルを使用する場合にスケーラブルに行うことができない。標準規格ベースの連合プロトコルのサポートを接触点エンティティに直接に追加することが、堅牢な解決策のように見えるが、既に企業のコンピューティング環境内の既存コンポーネントである接触点エンティティを、変更しなければならず、さらに、これらのパブリック連動プロトコルの１つが変更されるたびに、この接触点エンティティを変更しなければならない。
本発明は、この機能性を接触点エンティティから移動することによって、よりモジュラな手法を提供する。しかし、接触点エンティティは、これらのパブリック・プロトコルに対する頻繁な変更も扱わなければならず、この機能性をプラグ可能にすることを可能にすることによって、これらのプロトコルへの移行またはアップグレードを維持するのが簡単になる。
連合ユーザ・ライフサイクル管理の機能的サポート
WS-Federation仕様またはLiberty Alliance ID-FFプロファイルなどの従来技術の標準規格ベースのシングルサインオン解決策は、ある程度まで、連合ユーザ・ライフサイクル管理のモデルを提供する。これらの仕様は、公に入手可能であり、独立のベンダおよび会社が実施することができる。しかし、これらの従来技術の仕様は、これらの仕様で定義された機能性を含めるために既存環境を変更する形に対処していない。これらの従来技術の仕様には、指定された機能性を組み込むために既存コンピューティング環境のインフラストラクチャで必要な変更がこれらの仕様の採用を妨げる可能性があることの含意がある。たとえば、すべての従来技術の独自のシングルサインオン解決策が、この形で動作してきた。
対照的に、本発明の目標は、前に上で述べたように、既存コンピューティング環境のインフラストラクチャで最小限の変更が必要になるように、連合仕様を実施する機能性を組み込む方法およびシステムを提供することである。この目標は、連合ユーザ・ライフサイクル管理をサポートする機能性の組込みにも適用可能である。図７および図１６に、連合ユーザ・ライフサイクル管理機能性に関して本発明の実施形態を実施するのに使用できる構成要素の論理編成の例を示したが、図１７に、本発明の実施形態による、連合ユーザ・ライフサイクル管理機能性を可能にする処理を示す。
より重要なことに、図１７に、接触点機能性が連合ドメイン内で実施される形と独立の形で、連合ユーザ・ライフサイクル管理機能性を実施できるようにする処理が示されている。接触点機能性エンティティは、ユーザ／クライアントのセッション管理を実行できるエンティティに対応する。セッション管理に、前の成功裡の直接認証動作、現在の成功裡の直接認証動作、または成功裡のシングルサインオン動作あるいはこれらの組合せのどれであれ、ある形の情報に基づいて、セッションを作成することが含まれ、セッション管理に、任意選択の許可判断を含めることができ、セッション満了、削除、インアクティビティ・タイムアウトなどのセッション終了も含めることができる、セッションに対する他の動作も含まれる。接触点サーバは、ユーザのとの直接のチャレンジ／レスポンス対話を処理することができる認証動作のサポートも提供し続けることができる。接触点エンティティは、ポリシ実施ポイントとしても働くことができ、これによって、セッション管理の一部としての許可サービスが可能になる。
連合ユーザ・ライフサイクル管理機能性は、シングルサインオン・サービスを提供する（他の連合動作と共に）。というのは、これらの動作が、エンドユーザだけではなく、アイデンティティ・プロバイダなどの第三者との対話を含むからである。連合ユーザ・ライフサイクル管理機能性は、セッション管理サービスについて接触点機能性に頼る。連合ユーザ・ライフサイクル管理機能性は、下で詳細に説明する他の構成要素によって提供される信頼サービスを必要とするか、これに頼る。信頼サービスは、分散構成要素または連合ユーザ・ライフサイクル管理構成要素と一緒にある論理的に別々の構成要素を含めて、論理的に別々になる形で実施することができ、あるいはその代わりに、信頼サービスを、たとえばＥＡＲファイルなど、単一のアプリケーションの一部として連合ユーザ・ライフサイクル管理と一緒に実施することができる。
上の、図面の前の議論では、連合ドメイン内でサポートされる専用の接触点サーバを説明したが、図１７に関して説明する処理は、専用の接触点サーバを必要としない。図１７で説明する本発明の実施形態では、接触点機能性を、接触点機能性を提供するアプリケーションまたは他のエンティティを使用して実施することができる。接触点アプリケーションは、逆プロキシ・サーバ、ウェブ・サーバ、ウェブ・サーバ・プラグイン、サーブレット・フィルタ、または他のタイプのサーバもしくはアプリケーションとすることができる。後続の実施形態を実施する例示的な処理に関して下で説明する接触点機能性を、上で説明した接触点サーバと区別するために、下で、接触点機能性を、接触点エンティティまたは接触点サービスと称する。
図１７に、連合コンピューティング環境内のシングルサインオン動作を示すが、本発明の異なる実施形態に従って、たとえばシングルサインオフ動作など、他のタイプの連合動作のために類似する処理を実施できることにも留意されたい。
図１７を参照すると、データフロー図に、本発明の実施形態による、連合ユーザ・ライフサイクル管理機能性を使用してシングルサインオン動作を実行する処理が示されている。図１７に、特に本発明によって提供される連合ユーザ・ライフサイクル管理機能性に関して、本発明による連合機能性をサポートする、アイデンティティ・プロバイダとサービス・プロバイダの間のデータフローおよび対話の擬似ＵＭＬ図を示す。一般に、図１７に示された処理は、サービス・プロバイダの接触点エンティティが、サービス・プロバイダの連合コンピューティング環境内でサポートされる保護されたリソースに関する要求を受信した時に開始される。それ自体の認証方法を呼び出すのではなく、サービス・プロバイダの接触点エンティティは、要求をリダイレクトするか、要求を転送するか、他の形で機能性を呼び出して、オリジナル要求を、アイデンティティ・プロバイダの連合コンピューティング環境内でサポートされる連合ユーザ・ライフサイクル管理アプリケーションに送る。下で詳細に説明するように、連合ユーザ・ライフサイクル管理アプリケーションは、ユーザを認証する適当な形と、サービス・プロバイダでユーザのセッションを開始するためおよびユーザがサービス・プロバイダに関して直接に認証動作を完了したかのようにサービス・プロバイダでユーザのトランザクションの残りを処理するために接触点エンティティが必要とする情報を接触点エンティティに返す適当な形とを判定することができる。
図１７の処理は、サービス・プロバイダの接触点エンティティが、認証されたユーザから制御されたリソースに関するオリジナル要求を受信することから開始される（ステップ６０２）。オリジナル要求は、ユーザのトランザクションを開始するものと見なすことができるが、受信された要求を、単に、より複雑なトランザクションをサポートする多数の下流トランザクションの１つとすることができる。一実施形態で、サービス・プロバイダは、要求が、サービス・プロバイダがそれに関する進行中のセッションのレコードを有するエンドユーザまたはエンド・アプリケーションから来たことを検出することによって、オリジナル要求が認証されていないユーザからであることを判定することができる。
次に、接触点エンティティは、オリジナル要求をサービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションにリダイレクトするか、転送するか、送信する他の機能性を呼び出す要求を生成する（ステップ６０４）。接触点エンティティは、連合ユーザ・ライフサイクル管理機能性が、アイデンティティ・プロバイダに送らなければならない応答メッセージを作成できるようにする、連合ユーザ・ライフサイクル管理機能性を呼び出すどの手段でも使用することができる。言い換えると、接触点エンティティは、この複雑なシングルサインオン・メッセージにサービスし／応答する機能性を含む必要がない。図１７に示された例では、オリジナル要求が、起点アプリケーション、たとえばエンドユーザによって操作されているブラウザ・アプリケーションを介して、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションに、後にリダイレクトされる（ステップ６０６）。
要求を受け取った後に、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションは、エンドユーザ・アプリケーションと通信することによって、そのユーザに適当なアイデンティティ・プロバイダを判定する（ステップ６０８）。このステップは、任意選択である。このアイデンティティ・プロバイダが、特定の連合コンピューティング環境内のサービス・プロバイダの連合パートナであるならば、サービス・プロバイダは、アイデンティティ・プロバイダでの接触点エンティティの位置の情報または連絡情報、たとえばＵＲＬを用いて既に構成されている可能性があり、その代わりに、サービス・プロバイダが、このエンドユーザのトランザクションに使用される特定のアイデンティティ・プロバイダのアイデンティティを判定した後に、そのアイデンティティ・プロバイダの接触点エンティティの位置または連絡情報を入手するためにルックアップ動作を実行することができる。いくつかの場合に、サービス・プロバイダは、使用されるアイデンティティ・プロバイダのアイデンティティを知っている可能性がある。というのは、サービス・プロバイダが、１つのアイデンティティ・プロバイダに関してのみ知っており、選択肢がないからである。他の場合に、サービス・プロバイダは、永続ＨＴＴＰクッキーなど、永続的なユーザ側で維持される情報に基づいてアイデンティティ・プロバイダのアイデンティティを知ることができる。さらに別の場合に、サービス・プロバイダは、ステップ６０８でユーザと対話して、ユーザに、ユーザが現在の連合トランザクションに使用することを望むアイデンティティ・プロバイダのアイデンティティに関する情報をサービス・プロバイダに提供させる必要がある場合がある。サービス・プロバイダが、アイデンティティ・プロバイダのアイデンティティを得たならば、サービス・プロバイダは、適当なデータストアからそのアイデンティティ・プロバイダのシングルサインオン機能性（または、現在完了されつつある連合動作またはトランザクションのタイプに応じて、他の連合機能性）の適当なＵＲＩを入手することができる。本発明は、ステップ６０８を実行する別の形とも互換性がある。Liberty Alliance仕様に、ユーザが、クッキーから情報を入手できる他のサイトへのリダイレクトを実際に指示し（ＤＮＳクッキーに関する動作に対する制限に起因してこの形で実行される）、これが、直接ユーザ対話なしで、たとえばユーザにＨＴＭＬフォーム内で情報を提供させることなく、連合ユーザ・ライフサイクル管理機能性に返される対話が記載されている。
次に、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションが、シングルサインオン動作を成功裡に完了するのに適当な情報を入手する要求など、アイデンティティ・プロバイダでの連合ユーザ・ライフサイクル管理機能または連合ユーザ・ライフサイクル管理動作に関する要求を生成し、送信する（ステップ６１０）。この要求は、アイデンティティ・プロバイダがサービス・プロバイダからの通信を信頼できることを示すセキュリティ・トークンに埋め込むか、これを付随させることができる。サービス・プロバイダとアイデンティティ・プロバイダの間の信頼は、要求メッセージの署名および暗号化によって提供されることが好ましく、セキュリティ・トークンを、要求に付随するディジタル証明書によって表すことができる。連合ユーザ・ライフサイクル管理動作に関する要求に、エンドユーザ・アプリケーションからのオリジナル要求に関する情報を付随させることができる。というのは、連合ユーザ・ライフサイクル管理動作が、エンドユーザ・アプリケーションによってサービス・プロバイダに対して行われた要求のタイプに応じてさまざまな形で実行される可能性があるからである。
連合ユーザ・ライフサイクル管理機能または連合ユーザ・ライフサイクル管理動作に関する要求が、受け取られ、アイデンティティ・プロバイダで接触点エンティティに関して前に判定された連絡情報を使用して、エンドユーザ・アプリケーションを介してアイデンティティ・プロバイダの接触点エンティティにリダイレクトされる（ステップ６１２）。本発明は、ステップ６１２を達成するさまざまな形と互換である。たとえば、Liberty Alliance仕様は、リダイレクションのタイプをデバイス固有にすることの許容を有し、本発明の連合ユーザ・ライフサイクル管理機能性は、モバイル・デバイス対インターネットに基づくＨＴＴＰ ＰＯＳＴメッセージを使用して、状況値「０３２」を有するＨＴＴＰ応答に反応するＨＴＰＰリダイレクションと状況値「２００」（ＯＫ）を有するＨＴＴＰ応答に反応するＨＴＰＰリダイレクションを入れ替えることができる。
アイデンティティ・プロバイダの接触点エンティティが、連合ユーザ・ライフサイクル管理機能または連合ユーザ・ライフサイクル管理動作に関する要求を受け取った後に、アイデンティティ・プロバイダの接触点エンティティは、エンドユーザまたはエンドユーザのアプリケーションに関する任意選択の認証動作を実行することができる（ステップ６１４）。認証動作は、アイデンティティ・プロバイダがそのユーザの有効なセッションを有しない場合に必ず必要であり、このセッションがなければ、アイデンティティ・プロバイダは、シングルサインオンに関して誰がユーザであるかを判定することができない。認証は、ユーザの有効なセッションがある場合であっても、ユーザがまだアクティブであることを保証するために、またはより高いレベルの信任証を提供できるようにするために、必要である場合がある。ユーザの有効なセッションがない場合など、アイデンティティ・プロバイダが新しい認証動作を行ってはならないことをサービス・プロバイダが指定でき、その場合にシングルサインオン動作が失敗しなければならないことに留意されたい。認証動作のタイプは、自動的に実行できるように、またはユーザ、バイオメトリックまたは他のタイプの認証デバイス、もしくは他の情報ソースからの入力を要求できるように、変更することができる。たとえば、新しい認証動作が、たとえばエンドユーザがオリジナル要求で識別される制御されたリソースに関する許可されたリクエスタであることを保証する高いレベルのセキュリティを維持するために、必要である場合に、認証動作を要求することができる。異なるシナリオで、認証動作を要求することができるが、アイデンティティ・プロバイダの接触点エンティティが、アイデンティティ・プロバイダがエンドユーザのアクティブ・セッションを既に有することを示す情報へのアクセスを有する場合があり、これによって、ステップ６１４で後続の認証動作を完了する必要がなくなる。
次に、アイデンティティ・プロバイダの接触点エンティティは、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションによって要求された連合ユーザ・ライフサイクル管理機能または連合ユーザ・ライフサイクル管理動作に関する受け取られた要求を、アイデンティティ・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションに送る（ステップ６１６）。要求を分析した後に、アイデンティティ・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションは、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションが求めるエンドユーザ固有情報を含むかこれが付随する応答を作成する（ステップ６１８）。たとえば、アイデンティティ・プロバイダは、連合コンピューティング環境の他所に保管されていない、エンドユーザに関する秘密のアイデンティティ情報または他の属性情報を含むデータベースをサポートすることができる。上で注記したように、連合ユーザ・ライフサイクル管理動作に関する受け取られた要求に、エンドユーザ・アプリケーションからのオリジナル要求に関する情報が付随している場合がある。というのは、連合ユーザ・ライフサイクル管理動作が、エンドユーザ・アプリケーションによってサービス・プロバイダに対して行われた要求のタイプに応じて、さまざまな形で実行される可能性があるからである。同様に、アイデンティティ・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションからの応答は、ある形で、最初に識別された制御されたリソースに合わせて調整される場合がある。
アイデンティティ・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションは、たとえばＨＴＴＰ ＰＯＳＴ／リダイレクト・メッセージを使用して、エンドユーザ・アプリケーションに応答を送信し（ステップ６２０）、エンドユーザ・アプリケーションは、このメッセージをサービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションにリダイレクトする（ステップ６２２）。アイデンティティ・プロバイダが、単に、サービス・プロバイダによって期待される情報へのポインタまたはこれをポイントする類似するタイプの間接参照データ項目を返すことができることに留意されたい。この場合に、サービス・プロバイダは、たとえばサービス・プロバイダによって使用されるユーザ固有情報を取り出すためにアイデンティティ・プロバイダへのバックチャネル要求を実行することによるなど、情報を取り出すのに受け取ったポインタ（アーティファクトと称する）を使用しなければならない。
受け取られたメッセージに、アイデンティティ・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションが要求された連合ユーザ・ライフサイクル管理機能または連合ユーザ・ライフサイクル管理動作を成功裡に完了できなかったことを示すエラー・コードまたは他の表示が含まれないと仮定すると、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションは、受け取った応答から必要な情報を抽出し、サービス・プロバイダの接触点エンティティへの応答を作成する（ステップ６２４）。次に、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションが、生成された応答を、ある形でサービス・プロバイダの接触点エンティティに送る／返す（ステップ６２６）。
連合ユーザ・ライフサイクル管理アプリケーションは、たとえばＥＡＲファイルなど、ドメイン内のファイヤウォールの背後にインストールされるＪａｖａ（商標）アプリケーションとして実施することができる。接触点エンティティに返される応答の特性は、連合ユーザ・ライフサイクル管理アプリケーションのインストールおよび構成の一部として構成することができる。したがって、連合ユーザ・ライフサイクル管理アプリケーションは、接触点エンティティの形に依存しない。言い換えると、連合ユーザ・ライフサイクル管理アプリケーションは、接触点エンティティの識別情報また配置情報すなわち、トランザクション制御が返される形と、トランザクション制御を返す時に必要な情報の内容を除いて、接触点エンティティの性質に依存しない。この手法は、すべての連合ユーザ・ライフサイクル管理機能性、たとえばシングルサインオン動作、シングルサインオフ動作、アカウント・リンク、アカウント・リンク解除などを、接触点エンティティによって提供されるセッション管理機能性から結合解除できるようにすることによって、連合パートナのコンピューティング環境の既存インフラストラクチャに対する影響を最小限にする。
サービス・プロバイダの接触点エンティティが、サービス・プロバイダの連合ユーザ・ライフサイクル管理アプリケーションから成功裡の応答を受け取ると仮定すると、サービス・プロバイダの接触点エンティティは、エンドユーザ・アプリケーションからのオリジナル要求の処理に進み（ステップ６２８）、これには、この例では、ユーザ・セッションの作成、任意選択のアクセス制御動作または許可制御動作の実行、制御されたリソースへのアクセスを管理するか他の形で提供するバックエンド・アプリケーションへの制御されたリソースへのアクセスの要求の送出または転送が含まれ（ステップ６３０）、これによって処理が完了する。
図１７に示された例の要約として、エンドユーザは、オリジナル要求がサービス・プロバイダの接触点エンティティで受信された時に、サービス・プロバイダに関して認証されていなかった。サービス・プロバイダの制御の下で認証動作を直接に実行するのではなく、サービス・プロバイアは、連合シングルサインオン動作の完了をアイデンティティ・プロバイダに延期する。サービス・プロバイダの接触点エンティティは、連合シングルサインオン動作がサービス・プロバイダおよびアイデンティティ・プロバイダ（連合コンピューティング環境内のパートナである）の連合ユーザ・ライフサイクル管理アプリケーションを介して成功裡に完了したことの表示／メッセージを待つ。サービス・プロバイダの接触点エンティティが、連合シングルサインオン動作が成功裡に完了したことの表示／メッセージを受け取った後に、オリジナル要求が、さらに処理される。
本発明は、連合ユーザ・ライフサイクル管理解決策が一体化される既存環境を活用する。連合ユーザ・ライフサイクル管理アプリケーションのサポートは、既存環境に基づいて、Ｊ２ＥＥ／Ｃ＃アプリケーションとして実施することができる。連合ユーザ・ライフサイクル管理アプリケーションは、エンドユーザからの要求に応答して、接触点エンティティによって呼び出される。この要求は、認証されていないユーザによる保護されたリソースに関する要求程度の単純なものとすることができ、あるいは、上で図１５に関して説明したように、連合ユーザ・ライフサイクル管理機能性に関する明示的要求とすることができる。連合ライフサイクル管理アプリケーションは、コンピューティング環境の他の部分と対話する必要がないという点で独立であり、必要なプロトコルが成功裡に完了したならば、制御が、ユーザの要求が最初に受け取られた接触点エンティティに返される。したがって、既存環境は、この連合ユーザ・ライフサイクル管理機能性をサポートするために最小限の変更を必要とする。たとえば、呼び出される連合ユーザ・ライフサイクル管理機能性が、シングルサインオン要求である場合に、これは、認証されていないユーザによる保護されたリソースに関する要求に応答するものである可能性があり、ここで、通常の認証処理ではなく、連合ユーザ・ライフサイクル管理シングルサインオン機能性が呼び出される。本発明を用いると、これが、レガシ・ログオン処理ではなく連合ユーザ・ライフサイクル管理アプリケーションにユーザをリダイレクトできるようにする単純な構成変更を必要とする。
連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポート
上で注記したように、連合ユーザ・ライフサイクル管理機能性を提供する従来技術の解決策は、新しいパートナをオンラインにするか古いパートナをコンピューティング環境から除去することがどちらの側の環境に対する変更もなしに簡単である、疎結合環境を可能にするようにはスケーリングされない。連合ユーザ・ライフサイクル管理解決策によって可能にされる疎結合特性は、連合パートナの間の対応と、これらのパートナ環境のコンピューティング環境内の制御されたリソースにエンドユーザがアクセスする能力に関する。この疎結合特性は、一般に、連合パートナまたは当事者の間の信頼関係に適用されない。したがって、トレードオフがあり、疎結合特性は、信頼関係に関する連合パートナまたは企業の間の密結合特性を維持することによって達成される。この密結合された信頼関係は、連合環境内でエンドユーザが使用できる機能性を定義し、信頼し、この連合環境内の通信を保護するのに使用される計算機構も定義する。
本発明では、２つのパートナ／当事者の間の信頼関係の密結合特性を、信頼関連情報またはセキュリティ関連情報によって表現できることが認識されている。具体的に言うと、本発明は、信頼関係を定義する、暗号鍵、セキュリティ・トークン、およびアイデンティティ変換の機能性を含む信頼サービスを実施する。
本発明によって使用される暗号信頼の種類と、ＳＳＬ証明書を用いるトランスポート層での信頼の間に区別があることに留意されたい。プロトコル／アプリケーション層で信頼を実行する時には、証明書で主張されるアイデンティティの、ビジネス／法的契約に達したアイデンティティへの追加の「束縛」の必要がある。したがって、既存のＳＳＬ／トランスポート層信頼関係を単純に活用することは十分でない。というのは、これが、このタイプの機能性に必要な十分な追加の束縛を有しないからである。
鍵、トークン、およびアイデンティティ変換の組合せは、次の理由から信頼関係を表すのに選択された。所与の信頼関係で、暗号鍵の組が、パートナの間のメッセージに署名し、そのメッセージを暗号化するのに使用される。パートナの間のトランザクションに使用される鍵の知識は、通常、すべてのトランザクションに先立って確立され、これによって、一方のパートナが、メッセージに署名／暗号化でき、他方のパートが、これらのメッセージを有効化／暗号化解除できるようになる。さらに、署名／暗号化できるメッセージの要素の１つが、エンドユーザのアイデンティティまたは役割をアサートするのに使用されるセキュリティ・トークンである。このセキュリティ・トークンの構造も、パートナの間でトランザクションに先立って確立され、その結果、両方の当事者が、セキュリティ・トークンの内容を理解することが保証される。この保証は、パートナの間の仲介物として働くことができる第三者の信頼ブローカでの援助の呼び出しの結果とすることができる。さらに、セキュリティ・トークン内に、アイデンティティ・プロバイダによってアサートされるデータ・フォーマットからサービス・プロバイダが使用するデータ・フォーマットに変換できる、主張されるアイデンティティ、役割の組、または属性の組あるいはこれらの組合せがある。この変換は、アイデンティティ変換に基づいて達成され、このアイデンティティ変換は、セキュリティ・トークンで主張される合意された属性に従って前に定義されたものである。
したがって、本発明は、セキュリティ関連情報のタプル、具体的には｛暗号鍵、セキュリティ・トークン、およびアイデンティティ変換｝を含む情報項目の組として、２つのパートナの間の信頼関係の密結合特性を表すためのサポートを提供する。言い換えると、本発明では、このタプルが、信頼関係を表す。本発明は、信頼関係（およびその信頼関係の管理）と、連合ユーザ・ライフサイクル管理機能性解決策を提供するのに必要な機能性との間の分離を可能にする方法およびシステムを対象とする。具体的に言うと、暗号鍵、セキュリティ・トークン、およびアイデンティティ変換のタプルを含むものとして信頼関係を定義し、次に、少なくとも２つの連合したパートナが使用可能な機能性の定義と独立な形でこれらの連合したパートナの組に所与のタプルを束縛することによって、下で詳細に説明する、連合管理に対するスケーラブルな手法が提供される。
図１８を参照すると、ブロック図に、信頼関係管理を連合ユーザ・ライフサイクル管理から分離する論理構成要素の編成が示されている。連合ユーザ・ライフサイクル管理アプリケーション７０２は、図１６に示した連合ユーザ・ライフサイクル管理アプリケーション５０８に似ている。連合ユーザ・ライフサイクル管理アプリケーション７０２に、シングルサインオン、シングルサインオフ、アカウント・リンク／リンク解除、またはアイデンティティ・プロバイダ判定などの実施できる他の追加の連合機能性あるいはこれらの組合せのサポートが含まれる。この機能性のすべてが、ある形で、パートナの間の信頼関係を活用する。連合ユーザ・ライフサイクル管理アプリケーション７０２が、たとえば、連合環境内のエンドユーザ／アプリケーションを参照するためにセキュリティ・トークンを要求する時に、この情報が、信頼サービス呼び出し／メッセージ７０６を介して信頼サービス７０４に要求され、連合ユーザ・ライフサイクル管理アプリケーションと信頼サービスの間のさまざまなタイプのインターフェースを実施することができる。さらに、信頼サービスは、接触点サーバを含む、連合ドメイン内の他のコンポーネントとインターフェースすることができる。信頼関係管理機能性７０８は、単に、所与の連合パートナに関する信頼関係の管理のサポートに加わる機能モジュールを区別する論理的境界である。
信頼サービス７０４は、図７に示した信頼プロキシ／サービス２４４または図８に示した信頼プロキシ／サービス２５４などの上で述べた信頼プロキシ／サービスに似た、信頼プロキシ／サービスの例示的実施形態である。しかし、信頼サービス７０４は、信頼プロキシ／サービスが特定の形で信頼関係を管理する機能性を含むように拡張された、本発明の実施形態を表す。本発明の信頼関係管理に、暗号鍵管理、セキュリティ・トークン管理、およびアイデンティティ変換管理の機能性が含まれる。したがって、信頼サービス７０４は、セキュリティ・トークンに必要な署名／暗号化を含む適当なセキュリティ・トークンの作成と、その代わりに連合要求が行われているエンドユーザ／アプリケーションの適当な識別の責任を負う。
信頼サービス７０４は、さまざまな独立のセキュリティ関連サービスまたは信頼関連サービスへのアクセスを仲介するものと見なすことができる。信頼サービスを含むこれらの独立のサービスは、共通のデバイスまたは共通のサーバで、または共通のアプリケーション内で実施することができ、代替案では、各サービスが、独立のサーバ・アプリケーションとして実施される。鍵管理サービス７１０は、信頼関係のコンテキスト内で情報を通信するのに必要な暗号鍵またはディジタル証明書あるいはその両方を管理する。セキュリティ・トークン・サービス７１２は、セキュア通信またはパートナ間のセキュリティ関連通信に使用される独立のトークン・インスタンスを管理する責任を負い、セキュリティ・トークン・プラグイン７１４は、さまざまなタイプの独立にパブリッシュまたは開発されたセキュリティ・トークン標準規格またはセキュリティ・トークン仕様のための機能性を提供する。アイデンティティ・サービス７１６（またはアイデンティティ／属性サービス７１６）は、セキュリティ・トークンに含まれるアイデンティティまたは属性あるいはこの両方を管理する責任を負い、これには、トークンに追加されなければならない属性の突き止め、アイデンティティ・プロバイダから受け取られたトークンに基づくサービス・プロバイダの接触点サーバに対するローカル応答に追加されなければならない属性の突き止めが含まれる。
連合ユーザ・ライフサイクル管理機能性を信頼関係管理機能性から分離することは、この２つの異なるタイプの機能性の管理も分離されることを意味する。これは、信頼関係に関する情報が変更され、たとえば暗号鍵がセキュリティのために置換される場合に、必要な変更が、連合ユーザ・ライフサイクル管理機能性に影響しないことを意味する。さらに、同一の機能性を、異なるパートナが使用可能にすることができる。というのは、これらのパートナの信頼関係管理が、連合ユーザ・ライフサイクル管理機能性に束縛されないからである。さらに、信頼関係管理の分離は、新しい機能性が既存信頼関係に追加される時、たとえば、シングルサインオフ動作のサポートが、前にシングルサインオン動作だけをサポートした所与の関係に追加される場合に、信頼関係が維持されることを意味する。最後に、信頼関係の分離は、ウェブ・サービス・セキュリティ管理またはウェブ・サービス指向アーキテクチャなどの他のコンテキスト内で信頼関係およびその管理を再利用できることを意味し、したがって、本発明は、ブラウザベースの受動的クライアント・アーキテクチャに制限されない。
インポートされた構成ファイルを介する連合関係の確立
下の図１９から２２の説明は、連合関係の概念の説明および、本発明の前に説明した特徴が、電子通信を使用するビジネス・パートナの間の連合関係の確立を容易にする、本発明の実施形態の後続の説明のコンテキストを提供するために本発明の概念の一部を要約するように働く。図１９から２２は、本発明によって提供される機能性の区画分けを強調したブロック図である。具体的に言うと、図１９から２２は、機能性の異なる組を区画分けして、連合機能性とインターフェースするための既存のコンピューティング環境に対する最小限の変更に関する複数の連合仕様に同時に対処できる連合コンピューティング環境を実施する際の効率を作成する、本発明の実施形態を示す図である。図１９から２２の説明では、共通の符号を有する類似する要素に言及する。
図１９を参照すると、ブロック図に、連合コンピューティング環境の論理的機能性の高水準抽象が示されている。上で短く注記したように、企業およびその潜在的な連合パートナは、連合コンピューティング環境に参加する前に、ある量の予備作業を完了しなければならない。本発明の連合アーキテクチャの利益は、所与の企業ドメイン８００について、本発明が、連合インフラストラクチャ機能性８０６とインターフェースするために、企業およびその連合パートナの既存のコンピューティング環境機能性８０４に対する最小限のインフラストラクチャ機能性変更８０２を必要とすることである。これらの特徴を、上で図７に関して詳細に説明した。
図２０を参照すると、ブロック図に、本発明が、連合機能性および接触点機能性の信頼関係管理機能性からの分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象が示されている。上で説明したように、本発明の連合インフラストラクチャ機能性８０６内で、接触点機能性および連合動作機能性の組合せ８０８が、信頼関係管理機能性８１０から分離され、これによって、連合内のユーザが、既存のアプリケーション・サーバ８１４を介し、本発明のさまざまな実施形態による連合機能性を介して、保護されたリソース８１２にアクセスできるようになる。この信頼関係管理機能性からの接触点機能性の分離およびそれからの利益は、上で、図８および図１５に示された連合インフラストラクチャ構成要素に関して、および図１０から１４に示された機能処理に関して、詳細に説明した。
ただし、予備的図面すなわち図１５を介する連合機能性の説明で、連合パートナの間で達成できる多数のタイプの連合機能性および連合動作をさらに区別せずに、特にシングルサインオン動作すなわち連合認証動作に関して、信頼プロキシ／サービスの助けを得てのセキュリティ・アサーションおよびセキュリティ・トークンの処理のハンドリングなど、連合機能および連合動作と共に接触点動作を実行するものとして接触点サーバを説明したことに留意されたい。言い換えると、予備的図面での連合機能性の説明は、接触点機能性と連合動作機能性を区別していない。接触点サーバは、機能の組合せを実行するものとして説明されたが、接触点サーバの責任の一部は、連合した企業ドメインの接触点エンティティとして働くことであり、接触点サーバの責任の残りは、信頼／セキュリティ動作を処理するために信頼プロキシ／サービスに頼りながら、連合動作および連合機能のすべてを実行することである。しかし、図１５以降の本発明の説明では、図２１に関して注記するように、本発明の実施形態が接触点機能性と他の連合動作機能性の区別を実施できる形をさらに提供する。
図２１を参照すると、ブロック図に、本発明が、連合動作機能性の接触点機能性からのさらなる分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象が示されている。上で説明したように、本発明の連合インフラストラクチャ機能性８０６内で、信頼関係管理機能性８１０が、本発明の連合インフラストラクチャ内で提供される他の機能から分離され、さらに、これらの他の機能の間でさらなる区別を行うことができ、接触点機能性８１６を、連合動作機能性８１８から分離されたものとして図示することができる。この接触点機能性の連合動作機能性からの分離およびそれからの利益は、上で、図１５に示された連合インフラストラクチャ構成要素に関して、および図１７に示された機能処理に関して説明したが、図１６の連合ユーザ・ライフサイクル管理アプリケーション５０８（同様に図１７のＦＵＬＭアプリケーション）は、連合動作機能性の１つの態様を表す。
したがって、本発明は、異なる機能性の区画分けまたはモジュール化を容易にする。本発明の一実施形態で、接触点機能性と連合動作機能性の組合せが、信頼関係管理機能性から分離される。本発明のもう１つの実施形態で、信頼関係管理機能性の区画分けの継続の他に、接触点機能性が、連合動作機能性すなわち連合ユーザ・ライフサイクル管理機能性の一態様から分離される。信頼関係管理機能性および連合ユーザ・ライフサイクル管理機能性の分離に関するさらなる区別を、上で図１８に介して説明した。これらの区画分けがあるものとして、図２２に、さらなる区別が図示された本発明のもう１つの実施形態を示す。
図２２を参照すると、ブロック図に、本発明が、連合動作機能性の連合ユーザ・ライフサイクル管理機能性および連合関係管理機能性へのさらなる分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象が示されている。上で図２１に関して注記したように、接触点機能性８１６を、連合動作機能性８１８から分離されたものとして図示することができる。さらに、図１６および図１７に関して説明したように、接触点エンティティは、保護されたリソースへのアクセスの要求と比較した連合動作に関する入力要求を認識するための最小限の構成変更だけを用いて、ドメイン内の連合動作機能性と独立に動作することができる。したがって、この能力は、図２２では、接触点機能性８２０が連合インフラストラクチャ機能性８０６と別々であることを示すことによって反映されている。
上で図２０に関して注記したように、本発明の実施形態で、接触点機能性および連合動作機能性の組合せ８０８を、連合インフラストラクチャ機能性８０６内で信頼関係管理機能性８１０から分離することができる。連合ユーザ・ライフサイクル管理機能性を上で図１６および図１７に関して説明した後に、図１８の説明で、信頼関係管理機能性を、連合ユーザ・ライフサイクル管理機能性と別々に実施し続けることができることを説明した。さらに、図１８の説明で、同一の機能性を、モジュールの形で異なる連合パートナが使用可能にすることができることを注記した。
言い換えると、信頼関係管理機能性は、これが連合インフラストラクチャ機能性とインターフェースするが、そのような機能性と独立である形で実施することができる。したがって、この能力は、図２２では、信頼関係管理機能性８２２が連合インフラストラクチャ機能性８０６と別々であることを示すことによって反映されている。この区別の重要性を、下で詳細に示す。
図２２に、本発明の連合動作機能性でのさらなる区別も示されている。連合動作機能性８１８などの連合動作機能性に、連合コンピューティング環境内の連合パートナの間のトランザクションまたは対話を可能にする動作または機能が含まれる。連合動作機能性は、たとえば連合インフラストラクチャ機能性８０６などの連合インフラストラクチャ機能性と対比することができ、この連合インフラストラクチャ機能性には、連合パートナが既存の企業機能性と共に連合動作機能性を実施できるようにする動作または機能が含まれる。
上で、たとえば図１５の連合ユーザ・ライフサイクル管理アプリケーション５０８および図１７のＦＵＬＭアプリケーションによって表されるものなどの連合ユーザ・ライフサイクル管理機能性が、単に、連合動作機能性の一態様であることを注記した。上で定義したように、連合ユーザ・ライフサイクル管理機能性に、複数の連合ドメインでの所与のユーザの特定のユーザ・アカウントまたはユーザ・プロファイルに関する連合動作をサポートするか管理する機能が含まれる。いくつかの場合に、この機能または動作が、ユーザの所与の連合セッションに制限される。言い換えると、連合ユーザ・ライフサイクル管理機能性は、おそらくは連合コンピューティング環境内の単一のユーザ・セッションのライフサイクル中だけの、複数の連合パートナにまたがる連合動作の管理を可能にする機能を指す。
図２２は、本発明の連合動作機能性に複数の態様を含められることを反映している。連合動作機能性の一態様としての連合ユーザ・ライフサイクル管理機能性８２４と共に、本発明の実施形態は、下で詳細に示すように、連合関係機能性８２６も実施することができる。連合パートナ間の信頼関係と連合パートナ間の連合関係の間の差も、下で詳細に説明する。
図２３から２４を参照すると、ベン図に、連合関係に連合機能性の選択に関連する信頼関係が含まれる形が示されている。連合のコア・オブジェクトは、ビジネス・パートナの間のビジネス・プロセスの露出である。ただし、企業のビジネス・プロセスの露出は、多数の要因の考慮なしでは実行されない。たとえば、企業は、信頼されるパートナへのビジネス・プロセスの露出だけを検討する。したがって、本発明では、特に、異なるビジネス・パートナがその間に異なるレベルの信頼を有する場合があるという事実に鑑みて、企業が、信頼される連合パートナだけにビジネス・プロセスの露出を制限できるようにする必要が認識されている。
しかし、同一の連合コンピューティング環境内であっても、連合パートナの異なる組が、お互いとの対話に関する異なる要件を有する。したがって、本発明では、企業が、そのビジネス・プロセスの異なる連合パートナへの露出を異なる形で制限できるようにする必要が認識されている。
したがって、本発明では、連合機能性に、信頼される連合パートナの間の電子トランザクションをサポートする電子動作または電子機能が含まれる。ビジネス・プロセスを露出する前に、連合パートナの間のあるレベルの信頼がある必要があるので、連合関係が関連する前に、連合パートナの間に信頼関係が存在しなければならない。言い換えると、連合機能性に、後に信頼関係に関連付けられる電子トランザクションの選択が含まれる。この論理が、図２３から２４のベン図に反映されている。
図２３を参照すると、図に、２つの連合パートナの間の連合関係９０２に、この２つの連合パートナの信頼関係９０４と、この２つの連合パートナによって実施される連合動作／機能９０６の組の選択との間の関連が含まれる。図２３の図を、本発明の実施形態が企業のコンピューティング環境内で信頼関係管理機能性および連合インフラストラクチャ機能性を編成できる形と比較した時に、下で詳細に説明するように、連合コンピューティング環境を実施することの利益が明白になる。
図２４を参照すると、図に、２つの連合パートナが、これら自体の間で複数の連合関係を有することができることが示されている。２つの連合パートナの間の第１連合関係９１２に、この２つの連合パートナの第１信頼関係９１４とこの２つの連合パートナによって実施される連合動作／機能の組の第１選択９１６との間の関連が含まれる。さらに、２つの連合パートナの間の第２連合関係９２２に、この２つの連合パートナの第２信頼関係９２４とこの２つの連合パートナによって実施される連合動作／機能の組の第２選択９２６との間の関連が含まれる。この実施形態では、２つの連合パートナの間の複数の信頼関係が、複数の連合関係内で使用される。この複数の信頼関係は、類似する特性を有するが異なる実施データ、たとえば、類似するサイズの異なる暗号鍵または単に異なるディジタル証明書を有することができ、これによって、たとえば、異なるディジタル証明書を用いて異なる連合動作を実行できるようになる。
しかし、機能性９１６および９２６の２つの異なる選択は、異なる特性を有する信頼関係を使用することができ、これによって、異なる強さを有する信頼関係に関して異なる連合動作を実行できることが暗示される。信頼関係の異なる強さは、たとえば、異なる暗号アルゴリズムまたは異なる暗号鍵サイズなど、さまざまな判断基準に基づくものとすることができる。たとえば、シングルサインオン動作を、より弱い信頼関係を使用して実行すると同時に、ユーザのプロビジョニングなどの他の連合動作を、より強い信頼関係を使用して実行することができる。
たとえば、連合パートナの対が、多分多数の他の連合パートナを伴う第１商業プロジェクトをサポートするために対話することができ、その商業プロジェクトが、さまざまな折衝されたビジネス契約を介して、特定の特性を有する第１信頼関係の仕様を要求する場合がある。それと同時に、これらの連合パートナが、多分連合パートナの異なる組を伴う第２商業プロジェクトをサポートするために対話することができ、この商業プロジェクトが、第１信頼関係と異なる特性を有する第２信頼関係の使用を要求する場合があり、これらのすべてが、ビジネス契約の異なる組によって決定される。したがって、このシナリオでは、異なる商業プロジェクトが、異なる信頼関係を含む異なる連合関係を必要とする。
図２５を参照すると、データフロー図に、本発明による、連合コンピューティング環境内で対話するためにビジネス・パートナの対によって実行される一連の動作が示されている。企業、たとえばパートナ１００２と、その潜在的な連合パートナ、たとえばパートナ１００４は、連合コンピューティング環境内で対話を試みる前に、連合関係を確立しなければならない。しかし、上で注記したように、連合関係は、信頼関係に基づく。この信頼関係は、連合パートナのビジネス契約および法的契約への信頼を表し、これによって、パートナが、たとえば、特定の信頼関係の援助の下で実行されると仮定して、所与のアクションに関連するある種の責任などの対話の諸態様を判定できるようになり、これによって、パートナが、それらが要求した信頼関係のタイプに対して許容可能なアクションを左右するポリシを適用できるようになる。したがって、企業およびその潜在的な連合パートナは、対話データフロー１００６によって示されているように、連合内で対話を試みる前に、信頼関係を確立しなければならない。連合関係が、連合機能性の選択物を信頼関係に関連付けるならば、連合機能性が、構成動作１００８および１０１０として示されているように、各パートナで構成されなければならず、その後、対話データフロー１０１２によって示されているように、連合関係を作成することができる。連合関係を確立した後に、ビジネス・パートナは、対話データフロー１０１４によって示されているように、連合トランザクションにかかわることによって、連合した形で対話することができる。
ただし、企業が、連合トランザクションを成功裡に完了するための正しいサポートを有すること望むと仮定すると、連合機能性の構成が、連合トランザクションの開始の前のある時に実行されることだけが必要であることに留意されたい。たとえば、連合機能性を、信頼関係が確立される前に構成することができる。これによって、連合関係を構成する時の連合機能性の選択が容易になる可能性があるが、連合機能性の構成は、連合関係が確立された後に実行することもできる。さらに、本発明では、連合機能性を、連合関係が確立された後に、特に連合機能性の機能強化に関して、前に確立された連合関係の変更を必要とせずに変更することができる。
図２６を参照すると、ブロック図に、本発明の実施形態による、連合関係を確立するのに備えて信頼関係を確立するためのビジネス・パートナの間の対話が示されている。上で注記したように、信頼関係に、最初の信頼をビジネス・パートナの間で確立する、ある種のブートストラップ処理が含まれる。このブートストラップ処理の一部に、期待されるまたは許容されるあるいはその両方のトークン・タイプおよびアイデンティティ変換を定義する共用される秘密鍵および規則の確立を含めることができる。このブートストラップ処理は、アウトオブバンドで実施することができる。というのは、この処理に、連合への企業の参加およびこの参加に関連する法的責任を決定するビジネス契約の確立も含めることができるからである。
このブートストラップ処理の目的は、ビジネス・パートナすなわち企業の、ビジネス・パートナの信頼情報への束縛を提供することである。これは、ビジネス・パートナのディジタル証明書の作成の一部としての暗号鍵へのアイデンティティの束縛に加えてのものである。証明書作成は、ビジネス・パートナのアイデンティティを単純にアサートする認証局によって処理される。この連合信頼ブートストラップは、たとえばディジタル証明書で主張されるパートナのアイデンティティが、前に折衝されたビジネス契約、法的契約または類似するタイプの関連に束縛されることをアサートする。
本発明は、信頼関係の形を柔軟にすることを可能にし、たとえば、連合パートナが、異なるタイプのセキュリティ・トークンを使用して対話することができる。図１８に関して上で説明したように、本発明の実施形態は、所与の企業とそのビジネス・パートナの間の信頼関係を管理すると同時に信頼関係の管理の機能性を連合ユーザ・ライフサイクル管理の機能性から分離する信頼サービスを組み込むことができる。しかし、図１８の説明では、信頼関係を確立する形のさらなる説明を提供しなかった。
図２６に、図１８に示されたものなどの信頼サービス７０４が、連合パートナ１１０４との信頼関係を確立するために連合パートナ１１０２のコンピューティング環境で機能サポートを提供する形を示す。コンピューティング環境１１０２内の信頼関係管理コンソール・アプリケーション１１０６が、信頼サービス７０４に頼って、連合パートナ１１０４のコンピューティング環境内の類似する構成アプリケーションなどの連合パートナ１１０４のエンティティとの情報の交換を可能にする。上で注記したように、２つのパートナの間の信頼関係は、本発明では、セキュリティ関係情報のタプル、具体的には、｛暗号鍵、セキュリティ・トークン、およびアイデンティティ変換｝を含む情報項目の組として表される。したがって、信頼サービス７０４は、期待されるトークン・フォーマットに関する情報の交換１１０８、暗号鍵の交換１１１０、およびアイデンティティ変換の交換１１１２を可能にし、これらの情報は、信頼関係管理コンソール・アプリケーション１１０６または信頼サービス７０４によって信頼関係データベース１１１４に保管される。信頼関係データベース１１１４内で表される信頼関係のそれぞれが、その信頼関係を記述するか実施する追加情報を有することができることに留意されたい。
図２７を参照すると、ブロック図に、連合機能性を含むコンピューティング環境の構成が示されている。図２５に関して上で注記したように、連合機能性の構成は、連合トランザクションを開始する前のある時点に実行される必要がある。図１６に関して上で注記したように、連合ユーザ・ライフサイクル管理アプリケーション５０８に、図２７にも示された連合ユーザ・ライフサイクル管理プラグイン５１４とインターフェースするか、これと対話するか、他の形でインターオペレートするためのサポートが含まれる。
本発明の一実施形態で、連合プロトコル・ランタイム・プラグインは、さまざまなタイプの独立のパブリッシュまたは開発された連合ユーザ・ライフサイクル管理の標準規格またはプロファイルの機能性を提供する。図２７を参照すると、企業のコンピューティング環境内のシステム管理ユーザは、ランタイム環境管理コンソール・アプリケーション１２０２を使用して、ＦＵＬＭアプリケーション５０８および連合ユーザ・ライフサイクル管理プラグイン５１４を管理する。たとえば、管理者は、ランタイム環境管理コンソール・アプリケーション１２０２によって提供されるグラフィカル・ユーザ・インターフェースを使用して、特定のサーバの特定のディレクトリ内のプラグイン５１４を構成することができる。新しい連合動作がサポートされる時に、新しいプラグインを、管理者が、新しいプラグインを適当なディレクトリに保管することによって展開することができ、新しいプラグインの更新されたバージョンを、管理アプリケーションによって第三者のベンダ、集中連合データベース、または他の位置から取り出すことができる。構成ファイルまたはプロパティ・ファイルあるいはその両方に、連合トランザクション中に使用されるＵＲＩなどの、プラグイン５１４のランタイム・パラメータが含まれ、これらは、ランタイム環境管理コンソール・アプリケーション１２０２を介して管理者が作成し、変更し、削除することができる。
図２８を参照すると、ブロック図に、本発明の実施形態による、企業のコンピューティング環境内で連合関係を確立するためにシステム管理ユーザが使用できる連合関係管理コンソール・アプリケーションが示されている。上で注記したように、連合関係に、パートナの間で合意されなければならない連合機能性の選択が含まれ、たとえば、両方のパートナが、シングルサインオン機能性の活用に合意することができる。しかし、この機能性を実施するために、両方の当事者が、シングルサインオン要求／応答メッセージを送信する先のＵＲＩなど、選択された機能性に関するパートナ固有情報を知る必要もある。一方の連合パートナによって他方の連合パートナから収集される必要があるパートナ固有情報は、連合パートナの間の特定の連合関係について定義されたか選択された連合機能性に依存する。このパートナ固有情報は、パートナの間で交換される必要がある。
したがって、各連合パートナからの必要な情報が異なる可能性があるので、第１連合パートナによってすべての連合パートナに単一の構成フォーム・ファイルまたはテンプレート・ファイルを配布することはできない。定義された連合関係に従って連合トランザクションを実行するためにランタイムに必要な情報は、パートナ固有である。第１パートナの管理者が、特定の連合関係の構成された機能性に基づいて、連合パートナごとにこの構成フォームまたは構成テンプレートを調整しなかった場合に、他方のパートナは、その特定の連合関係に必要であるか否かに無関係に、構成フォームまたは構成テンプレート内で要求される可能性があるすべての情報を提供する必要がある。
本発明は、連合関係が作成されつつある間に、連合関係固有ＸＭＬ構成ファイルが動的に生成され、連合パートナにエクスポートされ、この連合パートナが、要求されたパートナ固有構成情報を提供し、要求元に返すという手法をとる。完全なファイルがパートナから受信された後に、要求元パートナは、下で詳細に説明するように、パートナ固有構成情報をインポートし、適当な連合関係に関連付けることができる。
図２８を参照すると、管理ユーザは、連合関係管理コンソール・アプリケーション１３００を使用して、連合関係を確立する。各連合関係に、信頼関係が含まれるので、連合関係管理コンソール・アプリケーション１３００は、信頼関係データベース１３０２から、以前に確立された信頼関係に関する情報を取り出す。信頼関係データベース１３０２には、たとえば図２６に関して上で述べたように、企業とその信頼されるビジネス・パートナとの間で確立された信頼関係ごとに１つの項目が含まれる。図２８の信頼関係データベース１３０２は、図２６のの信頼関係データベース１１１４に類似する。本明細書に記載のデータベース、構成ファイル、データ構造などを、汎用データストアまたは複数の異なるタイプのデータストアとして実施でき、すべてのデータストアを、データベース、ファイル、データ構造などとして実施できることに留意されたい。図２８に示された例では、信頼関係データベース１３０２に、“Ｔｒｕｓｔ−−ＸＹ”という名前の信頼関係が含まれ、これが、信頼関係データベース項目１３０４によって表されている。上で説明したように、各信頼関係に、情報のタプルが含まれる。信頼関係データベース項目１３０４に、タプル１３０６が含まれ、タプル１３０６に、暗号鍵情報１３０８、トークン・フォーマット情報１３１０、およびアイデンティティ変換情報１３１２が含まれる。各信頼関係に、表される信頼関係を実施する追加のパートナ固有情報、たとえば、信頼関係に参加するパートナのアイデンティティ、信頼関係に関する動作を実行するために連絡することができる信頼サービスのアイデンティティまたは位置に関する情報、または他の類似するタイプの情報も含めることができる。
連合関係に、その連合関係内でサポートされる連合機能性に関するパートナ固有情報も含まれるので、連合関係管理コンソール・アプリケーション１３００は、企業のコンピューティング環境内で既に構成されている可能性があるか企業のドメインまたはコンピューティング環境内で構成される、連合機能性に関する連合機能固有情報も取り出す。たとえば、企業のコンピューティング環境が、上で図１６に関して説明したものに似た本発明の実施形態に従って実施されていると仮定すると、連合関係管理コンソール・アプリケーション１３００は、ＦＵＬＭアプリケーションまたはそれに関連するプラグインあるいはその両方に関する情報を、さまざまな情報ソースから、たとえばこれらのファイルを含むディレクトリをスキャンすることによるか、ＦＵＬＭアプリケーションまたはそれに関連するプラグインあるいはその両方に関連する構成ファイルまたはプロパティ・ファイルあるいはその両方１３１４を読み取ることによるか、他の形で取り出すことができる。一実施形態で、この情報を収集した後に、連合関係管理コンソール・アプリケーション１３００は、レジストリ１３１６を作成することができ、このレジストリ１３１６は、その企業のドメインまたはコンピューティング環境内でサポートされるか、その企業のドメインまたはコンピューティング環境から使用可能な連合機能性に関する情報を集めたものである。図２８に示された例では、レジストリ１３１６に、使用可能な連合機能のタイプの項目１３１８が含まれ、レジストリ項目１３１８は、所与の連合機能によって要求される複数のメタデータ・パラメータを表す複数のフィールド１３２０に関連し、このメタデータは、連合機能を使用する連合トランザクションのインスタンス中に所与の連合機能を呼び出すか管理するのに連合パートナが必要とするパートナ固有構成データを示す。一実施形態で、レジストリ１３１６は、連合関係管理コンソール・アプリケーション１３００が管理ユーザによって使用されるたびに動的に生成される一時データストアまたは一時データ構造であり、代替実施形態では、レジストリ１３１６が、企業のドメインまたはコンピューティング環境内の他の構成ユーティリティ、たとえば、図２７に示されたランタイム環境管理コンソール・アプリケーション１２０２などによって維持される。
いくつかの場合に、連合機能に関連するメタデータ・パラメータに関する情報は、連合機能を実施するソフトウェア・モジュールが作成される時に判定される。言い換えると、これらのメタデータ・パラメータは、連合機能固有であり、メタデータ・パラメータは、ある形で、これらの連合機能を実施するソフトウェア・モジュールに関連する。したがって、連合機能に関連するメタデータ・パラメータ１３２０のアイデンティティは、連合機能を実施するソフトウェア・モジュールに、好ましくは構成ファイルまたはプロパティ・ファイルあるいはその両方１３１４内の機能固有メタデータ・パラメータとして、付随しなければならない。この構成ファイルまたはプロパティ・ファイルあるいはその両方１３１４は、ソフトウェア・モジュールが展開される時、たとえばＦＵＬＭアプリケーションまたはそのプラグインあるいはその両方が展開される時に、企業のコンピューティング環境内で展開または構成される。代替案では、メタデータ・パラメータ１３２０の個数および性質を、共通の集中連合データベースなどの他のデータ・ソースから取り出すことができる。もう１つの代替案では、メタデータ・パラメータ１３２０の個数および性質を、連合プロトコルの仕様を定義する電子ファイルから導出することができる。この仕様ファイルは、特定の連合プロトコルを厳守する連合機能に関する連合機能の実装が、あるメタデータ・パラメータを必要とするように、メタデータ・パラメータの標準セットを記述することができ、これによって、連合プロトコルに関するソフトウェア・モジュールによって実施されることが期待されるインターフェースまたはデータ交換が指示される。どの場合でも、メタデータ・パラメータ１３２０の個数および性質は、連合関係管理コンソール・アプリケーション１３００による取り出しのために使用可能である。
連合関係管理コンソール・アプリケーション１３００は、信頼関係および連合機能性に関する情報を取り出すと同時に、管理ユーザが連合関係を確立するのをサポートする。これらの連合関係は、連合関係データベース１３２２内の項目によって表される。図２８に示された例では、連合関係データベース項目１３２４が、“Fed--XY--ProjectX”という名前の連合関係を表し、この例では、連合関係の識別子が、たとえばパートナ“Ｘ”およびパートナ“Ｙ”など、連合関係で協力している連合パートナのアイデンティティを、連合関係の目的の表示と共に提供する。連合パートナが、多数の異なる目的のために対話でき、各目的がそれ自体の要件を有することができるならば、連合パートナの対が、図２３から２４に関して上で説明したように、複数の連合関係を有することができる。
図２８に示された例では、信頼関係データベース項目１３０４が、信頼関係データ１３２６として連合関係データベース項目１３２４にコピーされ、信頼関係データ１３２６に、暗号鍵１３３０、トークン・フォーマット情報１３３２、およびアイデンティティ／属性変換情報１３３４を含む信頼関係タプル１３２８が含まれる。代替案では、連合関係データベース項目１３２４に、単に、信頼関係データベース１３０２内の信頼関係データベース項目１３０４への参照またはポインタを保管することができ、信頼関係データベース項目１３０４を、連合関係データベース項目１３２４に対する更新を必要とせずに変更することができ、暗号鍵および証明書などの信頼関係の要素を含む個々のデータ項目も、これらのデータ項目を管理する効率を高めるために、単に参照によって含めることもできる。連合関係データベース項目１３２４に、たとえば、機能１３３６および１３３８とその実施要件に関する関連するメタデータ情報１３４０および１３４２など、連合関係データベース項目１３２４によって表される連合関係によってサポートされる連合動作／機能に関する情報も含まれる。代替案では、連合関係データベース項目１３２４に、単に、構成ファイルまたはプロパティ・ファイルあるいはその両方１３１４など、適当な位置への参照またはポインタを保管することができ、この構成ファイルまたはプロパティ・ファイルあるいはその両方１３１４から、サポートされる連合機能／動作に関する情報を取り出すことができる。
将来のある時点で、連合関係データベース項目１３２４が、連合関係データベース項目１３２４内で示される連合機能性、すなわち機能１３３６および１３３８を使用する連合トランザクションの初期化に使用される。しかし、連合トランザクションを開始するか完了するために、パートナ固有情報が必要であることを連合機能性がそのメタデータ情報を介してすなわち機能１３３６および１３３８に関連する情報１３４０および１３４２に従って示す場合に、パートナ固有情報を使用しなければならない。たとえば、このパートナ固有情報に、特定の連合パートナとの連合トランザクションを要求するために連合パートナに送信されなければならない要求メッセージのターゲット宛先を示す１つまたは複数のＵＲＩを含めることができる。
本発明の一実施形態で、管理ユーザが連合関係管理コンソール・アプリケーション１３００または類似する管理ソフトウェア・ツールを使用して連合関係を作成するか確立する間に、連合関係管理コンソール・アプリケーション１３００は、パートナ固有情報の入手を試み、これを、たとえばデータ項目１３４４および１３４６など、パートナ固有データ項目として連合関係データベース項目１３２４に保管する。それを行うために、連合関係管理コンソール・アプリケーション１３００は、連合関係確立テンプレート・ファイル１３４８を動的に生成する。これは、ＸＭＬフォーマットのファイルまたは他のタイプのファイルとすることができる。テンプレート１３４８は、起点パートナ、たとえばパートナ“Ｘ”によって、管理ユーザが連合関係の確立を試みている、信頼関係データ１３２６内で示される信頼されるパートナ、たとえばパートナ“Ｙ”にエクスポートされる。信頼されるパートナが、必要なパートナ固有情報を含めるためにテンプレート１３４８を変更することによってこの情報を提供した時に、要求元パートナの連合関係管理コンソール・アプリケーション１３００は、下で詳細に説明するように、変更されたテンプレート１３４８をインポートし、提供された情報を抽出し、連合関係データベース項目１３２４に保管する。
パートナ固有構成情報が、上で述べた管理ユーザのコンピューティング環境すなわち起点／ソース・パートナまたはパートナ“Ｘ”から協力する／ターゲット連合パートナすなわちパートナ“Ｙ”に送信される必要もある場合があることに留意されたい。ターゲット連合パートナが、協力する／ターゲット連合パートナの展望から連合関係を構成するために起点パートナに関するあるパートナ固有情報を必要とする場合があり、たとえば、連合パートナは、接触点サーバのＵＲＩなどの類似するメタデータ情報を必要とする場合があり、その結果、協力する／ターゲット連合パートナは、管理ユーザのドメイン、たとえばパートナ“Ｘ”（この例では２つのパートナの間の連合パートナシップの作成を以前に開始した連合パートナである）に向かう反対の方向でパートナ固有構成データと共に連合機能性を使用して連合トランザクションを開始することができるようになる。したがって、テンプレート・ファイル１３４８に、管理ユーザのドメインすなわちパートナ“Ｘ”のパートナ固有情報も含めることができる。代替案では、起点パートナすなわちパートナ“Ｘ”のパートナ固有情報を、付随するファイルでまたは後に送信されるファイルで送信することができ、２つのファイルが、パートナ固有情報をパートナの間で転送するのに使用されるようになる。起点／ソース・パートナから協力する／ターゲット・パートナに送信されるパートナ固有情報は、管理ユーザが、連合関係を作成している間に連合関係管理コンソール・アプリケーション１３００を介して入力することができ、あるいは、データの一部またはすべてを、やはり連合関係管理コンソール・アプリケーション１３００によって管理される構成データベースから入手することができる。
しかし、上で説明した形で連合パートナの間で交換されるパートナ固有情報が、対称でない場合があることにも留意されたい。言い換えると、連合パートナは、非常に異なる役割を引き受けることによって連合トランザクションにかかわることができ、これらの異なる役割が、異なるタイプの情報がめいめいの連合パートナに提供されることを必要とする場合がある。たとえば、管理ユーザは、アイデンティティ・プロバイダとして働く企業を運営することができる。連合関係が、Liberty AllianceのLiberty ID-FF仕様によって指定される機能性のサブセットをサポートすることができる。このシナリオでは、連合機能性に、ブラウザ／アーティファクト・シングルサインオン、アイデンティティ・プロバイダが開始するＨＴＴＰリダイレクトベースのRegisterName Identifier、およびサービス・プロバイダが開始するSOAP/HTTP Federation Termination Notificationを含めることができる。この特定の連合機能性に関して、アイデンティティ・プロバイダによってサービス・プロバイダに供給されるパートナ固有情報のタイプは、サービス・プロバイダによってアイデンティティ・プロバイダに供給されるパートナ固有情報のタイプと異なる場合がある。パートナ固有情報が、連合関係に関する連合パートナが引き受けた役割に従って異なる場合に、管理ユーザは、管理ユーザの企業によって実行される役割が、構成ファイルまたは連合関係管理データベースで既に以前に構成または保管されていないと仮定して、この役割について連合関係管理コンソール・アプリケーション１３００に知らせ；管理ユーザは、たとえば図２９に示されたものなどの連合関係管理コンソール・アプリケーションによって提供されるＧＵＩ内で、適当なデータ・オプションを選択または入力することによって、連合関係管理コンソール・アプリケーションに知らせることができる。
図２９を参照すると、図に、本発明の実施形態による、連合パートナの間の連合関係を確立するために管理ユーザが使用する連合関係管理アプリケーション内のグラフィカル・ユーザ・インターフェース・ウィンドウが示されている。ダイアログ・ウィンドウ１３５０に、図２８に示された連合関係管理コンソール・アプリケーション１３００など、連合関係管理コンソール・アプリケーションによって作成されつつある連合関係が基づく信頼関係をユーザが選択できるようにするドロップダウン・メニュー１３５２が含まれる。代替案では、必要な場合に、特定の連合関係に関する新しい信頼関係を動的に作成するために、ユーザが、たとえばメニュー項目を選択することまたはダイアログ・ボタンを押すことによって、連合関係管理コンソール・アプリケーションまたは図２６に示された信頼関係管理コンソール・アプリケーション１１０６などの他のアプリケーション内で機能性を呼び出せるようにすることができる。信頼関係の作成には、既存の秘密鍵、ディジタル証明書、トークン、アイデンティティ・マッピング情報など、管理ユーザの企業の既存の情報を使用することを含めることができる。管理ユーザは、次に、使用可能な場合に、たとえば公開鍵、ディジタル証明書、アイデンティティ・マッピング情報など、信頼されるパートナの既知の情報を使用して信頼関係の残りを構成することができるが、トークン情報は、各パートナによって変更不能に構成されるので、構成されない。
ドロップダウン・メニュー１３５４は、ユーザが、作成されつつある連合関係内でサポートされなければならない連合機能を選択できるようにする。テキスト入力フィールド１３５６は、作成されつつある連合関係の名前を入力するのに使用することができる。ボタン１３５８は、このダイアログ・ウィンドウを閉じ、たとえば図２８に示されたものに似た形で、適当なデータベース内の項目を生成することによって連合関係の作成を継続し、ボタン１３６０は、このダイアログ・ウィンドウを閉じ、連合関係の作成を取り消す。たとえば、管理ユーザがボタン１３５８を選択した時に、コンソール・アプリケーションが、たとえば、上で述べ、下で詳細に説明するパートナ固有連合関係確立テンプレート・ファイルをエクスポートし、インポートすることによって、連合関係に参加する２つのパートナの間でのパートナ固有構成情報の転送を開始する。
図３０から３１を参照すると、ブロック図に、本発明の実施形態による、企業のコンピューティング環境内で連合関係を確立するためにパートナ固有データを入手するために連合関係管理コンソール・アプリケーションによって開始されるデータフローが示されている。上で図２８に関して注記したように、連合関係管理コンソール・アプリケーション１３００は、連合関係確立テンプレート・ファイル１３４８を動的に生成する。たとえば、連合関係管理コンソール・アプリケーション１３００は、ユーザが、図２９に示されたダイアログ・ウィンドウ１３５０を介してそうするようにアプリケーションに指示した後に、テンプレート１３４８を作成することができる。テンプレート１３４８の内容は、連合関係管理コンソール・アプリケーション１３００がパートナ固有データの入手を試みている連合関係に基づいて動的に決定される。図３０を参照すると、連合関係管理コンソール・アプリケーション１３００は、連合関係データベース項目１３２４によって表される連合関係に基づいてテンプレート１３４８を作成する。図２８に類似する形で、連合関係データベース項目１３２４に、連合関係データベース項目１３２４によって表される連合関係によってサポートされる連合動作／機能に関する情報、たとえば機能１３３６および関連する機能を実施するのに必要なパラメータに関する関連するメタデータ情報１３４０などが含まれる。連合関係管理コンソール・アプリケーション１３００がテンプレート１３４８を生成する時に、アプリケーションは、必要に応じて、連合関係データベース項目１３２４から、示されたメタデータ・パラメータについてテンプレート１３４８内のメタデータ情報１３４０を抽出し、多分名前−値対としてフィールドまたは要素１３５４を作成する。テンプレート１３４８がＸＭＬベースのファイルである場合に、名前−値対を、タグ付き要素としてファイルに含めることができる。この時点で、テンプレート１３４８には、まだパートナ固有データが含まれない。後のある時点に、テンプレート１３４８が、協力する／ターゲット連合パートナに送信されて、将来のある時点で協力する／ターゲット連合パートナとの連合トランザクションを実行するのに必要なパートナ固有データが入手される。
図３１を参照すると、テンプレート１３４８に、協力する／ターゲット連合パートナがテンプレート１３４８を返した後に、変更された名前−値対１３５６が含まれる。協力する／ターゲット連合パートナは、テンプレート１３４８を解析し、名前−値対の要求を抽出し、多分自動処理の形であるが協力する／ターゲット連合パートナのグラフィカル・ユーザ・インターフェース・アプリケーションを介する管理ユーザとの対話を介して、要求された値を入手した。その後、起点／ソース連合パートナで、連合関係管理コンソール・アプリケーション１３００が、返された名前−値対１３５６を抽出し、データ項目１３５８から１３６２として協力する／ターゲット連合パートナによって供給されたパートナ固有情報を連合関係データベース項目１３２４に保管する。データ項目１３５８から１３６２は、その後、将来のある時点に、連合パートナとの連合トランザクションを完了するのに使用される。やはり、起点／ソース連合パートナに関するパートナ固有構成情報を、テンプレート１３４８で連合パートナに送信することができ、連合パートナは、その後、反対方向の類似する連合トランザクションを開始するか、単に連合トランザクションに加わるために、同等のまたは対応する情報を有する。この形で、単一のファイルが、行き来して送信されるが、返される前に変更される。
代替案では、起点／ソース連合パートナすなわち、２つのパートナの間の連合パートナの作成を開始した連合パートナに関するパートナ固有構成情報を、第１ファイルの送信と同時にまたは後の時点のいずれかに、第２のメッセージまたはファイルで送信することができる。この第２ファイルは、起点／ソース連合パートナに関するパートナ固有情報を協力する／ターゲット連合パートナに提供し、返されない。たとえば、第１ファイルが、協力する／ターゲット連合パートナからのパートナ固有情報の包含を固有に要求する「空」のファイルとして連合パートナに送信され、このファイルが変更されて返され、第１ファイルに、連合パートナのパートナ固有情報が含まれるようになる。対照的に、第２ファイルは、起点／ソース連合パートナから協力する／ターゲット連合パートナにパートナ固有情報を供給する「満杯」のファイルとして連合パートナに送信される。
図３２を参照すると、流れ図に、本発明の実施形態による、連合関係を介して対話する連合パートナの間で交換されるエクスポート／インポートされるファイルの使用を介して自動化された形で連合関係が確立される処理が示されている。この処理は、たとえばパートナ“Ｘ”として識別される所与の企業のコンピューティング環境を有する管理ユーザが、たとえばパートナ“Ｙ”として識別される信頼されるビジネス・パートナとの連合関係を確立する通知を受信する時に開始される（ステップ１４０２）。この通知は、あるアウトオブバンドの形で受信することができるが、この通知は、図２８に示された連合関係管理コンソール・アプリケーションなどの管理コンソール・アプリケーション内で、電子メールを介するかある形で電子的に受信されることが好ましいが、郵便または電話などの手動の形で行うこともできる。一般に、連合は、しばしば、連合関係に関する情報を構成する起点／ソース・パートナとして働く連合パートナであるパワー・スポンサ（power sponsor）という概念を有する。
管理ユーザは、まだそれを行っていない場合に、連合関係管理コンソール・アプリケーションを呼び出す（ステップ１４０４）。代替案では、この機能性を、起点／ソース連合パートナのコンピューティング環境内のアプリケーションによって開始されるあるワークフロータイプのアクションを介して開始するか、実行するか、その両方を行うことができる。したがって、図３２に示された処理は、好ましくは、たとえば多分WS-Policy仕様を実施するように構成された機能性を使用して、コンピューティング環境のインフラストラクチャに組み込まれたポリシ決定に基づいて、完全に自動化することができる。
図３２に示された処理が、起点／ソース連合パートナである連合パートナ“Ｘ”の展望から描かれ、図３２に関して説明する処理ステップが、起点／ソース連合パートナである連合パートナ“Ｘ”のコンピューティング環境内で行われることに留意されたい。類似するアクションが、下で詳細に説明するように、連合パートナ“Ｘ”からの情報の受信に応答して、連合パートナ“Ｙ”連合パートナで行われる可能性がある。
管理ユーザは、連合パートナ“Ｘ”の連合関係管理コンソール・アプリケーション内で新しい連合関係の構成または作成を開始する（ステップ１４０６）。このユーザは、たとえば“Fed--XY--PROJECTXなど、新しい連合関係の名前または識別子を入力する（ステップ１４０８）、あるいは、この名前または識別子が、連合関係を作成するパートナなどの情報の組に基づいて自動的に作成される。
連合関係を構成／作成する動作が、ワークフロー処理を介して自動的に開始される場合に、受信された要求メッセージまたは類似する開始するイベントに、要求された連合関係でサポートされなければならない連合機能性の表示を含めることができる。その代わりにまたはそれに加えて、ユーザは、たとえば図２９に示されたものなど、連合関係管理コンソール・アプリケーション内で適当な連合機能を選択する（ステップ１４１０）ことができ、あるいは、受信した要求メッセージを自動的に処理して、必要な連合機能性を判定することができる。
次に、ユーザは、たとえば図２９に示されているように、連合関係が基づく信頼関係を選択するか構成するか作成する（ステップ１４１２）。パートナの間の単一の信頼関係だけが存在する場合に、その信頼関係を自動的に選択することができる。既存の信頼関係のどれもが、選択された連合機能性に適当でない場合には、連合関係管理コンソール・アプリケーションが、新しい信頼関係を構成または作成するようにユーザにプロンプトを出すことができる。
下で詳細に説明するように、２つのビジネス・パートナの間の信頼関係は、この２つのビジネス・パートナの間で連合関係が構成または作成されるのと同時に構成または作成することができる。したがって、信頼関係を構成するための情報は、連合関係を構成する情報が転送されるのと同一の時間期間中にビジネス・パートナの間で転送することができる。
対照的に、連合関係を構成しつつある連合パートナが、既に信頼関係を有する場合がある。この信頼関係は、連合内での協力以外の目的のために構成されたものである場合がある。この信頼関係は、情報の単純な交換を介して構成されたものである場合があり、その代わりに、この信頼関係が、めいめいのコンピューティング環境内だが連合の考慮の外の他のソフトウェア・アプリケーションを使用して構成されたものである場合がある。たとえば、連合パートナが、公開鍵／ディジタル証明書および連合パートナ間のトランザクションに使用することを連合パートナが望む他の信頼関係情報を既に交換している場合があり、この情報は、電子情報の単純な転送を介して、ある他のタイプのソフトウェア・アプリケーションを介して、または他の形で交換されたものである可能性がある。
さらに、既存の信頼関係が、連合内の対話のために既に作成されている場合がある。言い換えると、ビジネス・パートナの対が複数の並行する連合関係を介して協力する可能性があるならば、信頼関係が、前に確立された連合関係のために既に作成されている可能性がある。
どの場合でも、２つのパートナの間の既存の連合関係があるか否かにかかわらず、新しい連合関係を作成または構成することを望む２つのビジネス・パートナの間に１つまたは複数の既存の信頼関係がある場合がある。少なくとも１つの既存の信頼関係がある場合に、その信頼関係の信頼関連情報を、連合関係管理コンソール・アプリケーション内で提示できる一意の名前付きの信頼関係として論理的にパッケージ化することができる。そうである場合に、管理ユーザは、グラフィカル・ユーザ・インターフェース内で、この既存の形式的に定義された信頼関係を単純に選択できる可能性がある。
その代わりに、１つまたは複数の既存の信頼関係の信頼関連情報を、グラフィカル・ユーザ・インターフェース内で、信頼関連情報の別々のデータ項目として管理ユーザに提示することができる。このシナリオでは、ユーザが、新しい信頼関係に使用されるデータ項目を選択することによって、新しい信頼関係を構成または作成することができる。たとえば、単一のディジタル証明書を、複数の信頼関係で使用することができる。というのは、複数の信頼関係の他の信頼関連情報が、異なる可能性があり、これによって、複数の信頼関係が一意になると同時に、同一のディジタル証明書がそれぞれで使用されるからである。
もう１つの代替案では、パートナが、既存の信頼関係を有しない場合がある。このシナリオでは、管理ユーザが、パートナの「それ自体の」情報すなわち、起点／ソース・パートナに関する信頼情報を入力または選択する。これは、ディジタル証明書などのパートナ固有情報とすることができるが、さまざまな信頼関連プロトコル仕様で指定できる単純な非パートナ固有の値によって表すことができる信頼関係に関する好ましい特性も含めることができる。たとえば、管理ユーザは、連合関係を確立するコンソール・アプリケーションがパートナのコンピューティング環境内でキーストアから取り出した複数の非対称暗号鍵対の中から選択することができる。さらに、このユーザは、グラフィカル・ユーザ・インターフェース内のチェック・ボックス、ラジオ・ボタン、メニューなどを介してさまざまな信頼関連特性パラメータを選択することができ、ここで、これらの信頼関連特性パラメータは、信頼関連情報に関する異なる処理オプションを示す。
信頼関係が、パートナの間の対話を必要とするならば、さまざまな信頼関連特性の選択と共のパートナ固有の信頼関連情報の選択は、起点／ソース・パートナが協力する／ターゲット・パートナに要求するパートナ固有信頼関連情報を指示する。言い換えると、パートナの間で交換される情報は、ある形で対応しなければならない。したがって、管理ユーザの選択は、その後、協力する／ターゲット・パートナにエクスポートされるテンプレート／構成ファイル内の起点／ソース・パートナのパートナ固有信頼関連情報を含めることをもたらす。さらに、管理ユーザの選択は、その後、起点／ソース・パートナによって協力する／ターゲット・パートナにエクスポートされるテンプレート／構成ファイルに情報要求要素を含めることをもたらす。いくつかの場合に、連合機能性が、信頼サポートを必要としない場合があり、したがって、信頼関係を選択する必要がなくなる。連合関係は、信頼関係を含むものとして定義されるので、このシナリオでは、連合関係を、ヌル信頼関係を含むものとして記述することができる。
信頼関係または信頼関係情報あるいはその両方が、連合機能性が選択された後に選択または入力されることが好ましい。というのは、ある機能性が、ある信頼関係すなわち信頼関連処理に関するオプションのある選択により適切に関連付けられる可能性があるからである。たとえば、特定のトークン・タイプが、トークン・タイプのインスタンスに対して実行されなければならない暗号化または署名に関する要件を有する場合がある。
連合関係の作成を連合パートナ“Ｘ”で開始した後に、連合関係確立テンプレート・ファイルを動的に生成する（ステップ１４１４）。このテンプレート・ファイルは、上で図３０に関して述べたように、連合パートナから収集される必要があるデータに従って構造化される。次に、テンプレート・ファイルを連合パートナ“Ｙ”に送信し（ステップ１４１６）、連合パートナ“Ｙ”は、必要なパートナ固有情報を含むように、受信したテンプレート・ファイルを変更し、その後、変更されたテンプレート・ファイルを連合パートナ“Ｘ”に返す。変更されたテンプレート・ファイルを受信（ステップ１４１８）した後に、必要なパートナ固有情報を抽出し（ステップ１４２０）、後続の連合トランザクション中に使用するために連合パートナ“Ｘ”で保管し（ステップ１４２２）、これによって処理を完了する。
テンプレート・ファイル（または第２ファイル内）に、パートナ“Ｙ”に送信されるパートナ“Ｘ”に関するパートナ固有情報を含めることができることに留意されたい。連合パートナ“Ｘ”に関する情報を有するテンプレート・ファイルが、連合パートナ“Ｙ”に送信される時に、この情報が、連合パートナ“Ｙ”のコンピューティング環境にインポートされて、連合パートナ“Ｙ”で連合関係が構成される。連合パートナ“Ｙ”のコンピューティング環境の連合パートナ“Ｘ”に関する情報のインポートは、自動的に実行することができ、パートナ“Ｙ”の管理ユーザが、連合関係に関する情報を手動で構成する必要がなくなる。
もう１つの代替実施形態では、前に作成された信頼関係を選択するのではなく、信頼関係を、連合関係が作成されている間に、多分図２６に示された信頼関係管理コンソール・アプリケーション内の機能性を図２８に示された連合関係管理コンソール・アプリケーションと共に使用して作成することもできる。その代わりに、連合関係管理コンソール・アプリケーションに、管理ユーザから信頼情報を入力する機能性またはキーストアなどの適当なデータストアから信頼情報を入手する機能性を含めることもできる。この場合に、管理ユーザも、たとえば複数の秘密鍵または複数の証明書から選択するかこれを入力することによって、連合関係が基づく信頼関係を作成するために情報を入力するか情報を選択する。管理ユーザの企業、たとえばパートナ“Ｘ”は、たとえば公開鍵証明書などの信頼情報を、テンプレート・ファイルまたは連合パートナに送信される付随ファイルに追加することができる。同様に、連合パートナから受信された変更されたテンプレート・ファイルが、連合関係を作成するためのパートナ固有情報に加えて、信頼関係を作成するためのパートナ固有情報を有することができる。信頼関係情報は、連合関係情報と共に受信されたファイルから抽出され、抽出された信頼関係情報は、ある形で連合関係に関する構成情報に関連付けられる。管理ユーザが、１つまたは複数の他のソースから信頼関係情報または連合関係情報あるいはその両方のすべてまたは残りを入手し、その後、連合関係管理コンソール・アプリケーションを介してこの情報を入力して、所望の信頼関係または所望の連合関係を構成できることにも留意されたい。
したがって、信頼関係が２フェーズで作成されることに留意されたい。第１フェーズでは、管理ユーザが、たとえば暗号化またはディジタル署名あるいはその両方によって、連合パートナ“Ｙ”または他の連合パートナあるいはその両方に送信される情報を保護するのに使用される、たとえば秘密鍵などの連合パートナ“Ｘ”の信頼情報のすべてを収集する。連合パートナ“Ｘ”が、１組の暗号鍵だけを有する場合に、連合パートナ“Ｘ”での管理ユーザに関する信頼関係の選択肢がない場合があるが、管理ユーザは、新しい関係も構成するように、連合関係を構成する時に新しい鍵を追加するオプションを有する。
第２フェーズでは、連合パートナ“Ｙ”から受信された情報の妥当性検査または有効化に使用される、たとえば公開鍵またはディジタル証明書あるいはその両方など、信頼情報のすべてが、連合パートナ“Ｙ”について収集される。連合パートナ“Ｘ”が、連合パートナ“Ｙ”に関するそのような情報を既に保管している場合に、管理ユーザは、その情報を使用することができ、管理ユーザに、管理コンソール・アプリケーションを介して信頼関係を構成している間に、暗号鍵などのリストを提示することができる。連合パートナ“Ｘ”が、連合パートナ“Ｙ”に関するそのような情報をまだ保管していない場合に、パートナ“Ｘ”の管理ユーザは、管理コンソール・アプリケーションを使用して、ランタイムに、新しい鍵などの信頼情報を追加することを選択することができる。代替案では、上で述べたように、連合パートナ“Ｘ”の管理ユーザが、パートナ固有構成ファイルを介して連合パートナ“Ｙ”の信頼情報をインポートすることを選択することができ、その後、連合パートナ“Ｘ”の適当なアプリケーションが、連合パートナ“Ｘ”のデータストア内の連合パートナ“Ｙ”に関する信頼情報を自動的に更新し、これによって、この２つの連合パートナの間の信頼関係が確立される。
結論
本発明の利益は、上で示した本発明の詳細な説明に鑑みて明白である。連合ユーザ・ライフサイクル管理機能性を信頼関係管理機能性から分離することは、２つの異なるタイプの機能性の管理も分離できることを意味する。さらに、同一の機能性を、異なるパートナから使用可能にすることができる。というのは、これらのパートナの信頼関係管理が、連合ユーザ・ライフサイクル管理機能性に束縛されないからである。さらに、信頼関係管理の分離は、新しい機能性が既存の信頼関係に追加される場合、たとえば、シングルサインオフ動作のサポートが、前にシングルサインオン動作だけをサポートした所与の関係に追加される場合に、信頼関係を維持できることを意味する。
本発明を、完全に機能するデータ処理システムの文脈で説明したが、本発明の処理を、配布の実行に実際に使用される信号担持媒体の特定のタイプに無関係に、コンピュータ可読媒体内の命令の形およびさまざまな形で配布できることを当業者が諒解することに留意することが重要である。コンピュータ可読媒体の例に、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ならびにディジタル通信リンクおよびアナログ通信リンクなどの伝送型媒体などの媒体が含まれる。
方法は、一般に、所望の結果につながるステップの首尾一貫したシーケンスと考えられる。これらのステップは、物理的な量の物理的な操作を必要とする。必ずではないが通常、これらの量は、保管、転送、組合せ、比較、または他の形の操作が可能な電気信号または磁気信号の形をとる。時々、主に一般的な使用のために、これらの信号を、ビット、値、パラメータ、項目、要素、オブジェクト、記号、文字、項、数などと呼ぶことが便利である。しかし、これらの用語および類似する用語のすべてが、適当な物理的な量に関連しなければならず、これらの量に適用される単に便利なラベルであることに留意されたい。
本発明の説明は、例示のために提示されたのであって、網羅的であることおよび開示される実施形態に制限することは意図されていない。多数の修正形態および変形形態が、当業者に明白である。実施形態は、本発明およびその実用的な応用例の原理を説明し、当業者が、他の企図される使用に適するさまざまな変更を加えてさまざまな実施形態を実施するために本発明を理解できるようにするために選択されたものである。
それぞれが本発明を実施できるデータ処理システムの通常のネットワークを示す図である。 本発明を実施できるデータ処理システム内で使用できる通常のコンピュータ・アーキテクチャを示す図である。 クライアントがサーバの保護されたリソースへのアクセスを試みる時に使用できる通常の認証処理を示すデータ・フロー図である。 本発明を実施できる通常のウェブベース環境を示すネットワーク図である。 ユーザからの複数の認証動作を必要とする可能性がある通常のオンライン・トランザクションの例を示すブロック図である。 連合環境内の下流エンティティでのアクションを呼び出す、ユーザによって第１連合企業に対して開始されたトランザクションに関する連合環境の用語を示すブロック図である。 本発明の実施形態による、所与のドメインの既存のシステムの、本発明の連合アーキテクチャ構成要素の一部との統合を示すブロック図である。 本発明の実施形態による連合アーキテクチャを示すブロック図である。 本発明による、信頼プロキシおよび信頼ブローカを使用する連合ドメインの間の信頼関係の例示的な組を示すブロック図である。 連合環境内でアサーションを作成する、発行ドメインでの一般化された処理を示す流れ図である。 アサーションを分解する、依存ドメインでの一般化された処理を示す流れ図である。 発行ドメインでのユーザ・アクションに応答する、発行ドメインから依存ドメインへのアサーションのプッシュに関する特定の処理を示す流れ図である。 発行ドメインが依存ドメインへの発信要求を能動的にインターセプトすることに応答する、発行ドメインから依存ドメインへのアサーションのプッシュに関する特定の処理を示す流れ図である。 依存ドメインが、発行ドメインにユーザの必要なアサーションを要求すると同時に、依存ドメインが要求元ユーザから受信したリソース要求の満足を試みる、プル・モデルを示す流れ図である。 連合シングルサインオン動作をサポートする連合環境を示すブロック図である。 本発明の実施形態による、連合ユーザ・ライフサイクル管理機能性を実施する連合ドメイン内の構成要素の一部を示すブロック図である。 本発明の実施形態による、連合ユーザ・ライフサイクル管理機能性を使用してシングルサインオン動作を実行する処理を示すデータフロー図である。 信頼関係管理を連合ユーザ・ライフサイクル管理から分離する論理構成要素の編成を示すブロック図である。 連合コンピューティング環境の論理的機能性の高水準抽象を示すブロック図である。 本発明が、連合機能性および接触点機能性の信頼関係管理機能性からの分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象を示すブロック図である。 本発明が、連合動作機能性の接触点機能性からのさらなる分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象を示すブロック図である。 本発明が、連合動作機能性の連合ユーザ・ライフサイクル管理機能性および連合関係管理機能性へのさらなる分離を提供する形を示す、連合コンピューティング環境の論理的機能性の高水準抽象を示すブロック図である。 連合関係に連合機能性の選択に関連する信頼関係が含まれる形を示すベン図である。 連合関係に連合機能性の選択に関連する信頼関係が含まれる形を示すベン図である。 連合コンピューティング環境内で対話するためにビジネス・パートナの対によって実行される一連の動作を示すデータフロー図である。 連合関係を確立するのに備えて信頼関係を確立するためのビジネス・パートナの間の対話を示すブロック図である。 連合機能性を含むコンピューティング環境の構成を示すブロック図である。 企業のコンピューティング環境内で連合関係を確立するために管理ユーザが使用できる連合関係管理コンソール・アプリケーションを示すブロック図である。 連合パートナの間の連合関係を確立するために管理ユーザが使用する連合関係管理アプリケーション内のグラフィカル・ユーザ・インターフェース・ウィンドウを示す図である。 企業のコンピューティング環境内で連合関係を確立するためにパートナ固有データを入手するために連合関係管理コンソール・アプリケーションによって開始されるデータフローを示すブロック図である。 企業のコンピューティング環境内で連合関係を確立するためにパートナ固有データを入手するために連合関係管理コンソール・アプリケーションによって開始されるデータフローを示すブロック図である。 連合関係を介して対話する連合パートナの間で交換されるエクスポート／インポートされるファイルの使用を介して自動化された形で連合関係が確立される処理を示す流れ図である。
符号の説明
２１２ ユーザ
２１４ クライアント・デバイス
２１６ ブラウザ・アプリケーション
２２０ ＨＴＴＰ
２２２ ＭＬインタープリタ
２２４ ウェブ・サービス・クライアント
２１８ 他のアプリケーション
２４２ 接触点（ＰＯＣ）サーバ
２４０ 企業／ドメイン用の連合フロントエンド
２４４ 信頼プロキシ（ＴＰ）（または信頼サービス）
２４５ セキュリティ・トークン・サービス（ＳＴＳ）
２４６ 連合ユーザ・ライフサイクル管理（ＦＵＬＭ）サーバ
２４７ 連合構成アプリケーション
２４８ 連合インターフェース・ユニット
２３０ 企業／ドメイン用のレガシ・アプリケーションまたはバックエンド処理
２３２ 認証サービス・ランタイム（ＡＳＲ）サービス
２３４ アプリケーション・サービス
２３５ 保護されたリソース
２３６ レガシ・ユーザ登録
２３８ レガシ・ユーザ・レジストリ・アプリケーション

Claims (10)

  1. 複数のコンピュータ・デバイスがネットワークを介して互いに接続されてなるコンピューティング環境であって、連合コンピューティング環境としての複数のコンピューティング環境と連携して動作する前記コンピューティング環境内で、単一のユーザ・セッションのライフサイクル中の前記複数のコンピューティング環境に跨る動作の管理を行う連合ユーザ・ライフサイクル管理サービスを実施する手段と、
    前記コンピューティング環境内で、前記コンピューティング環境と前記連合コンピューティング環境との間のセキュリティ関連情報を管理し、前記連合ユーザ・ライフサイクル管理サービスを実施しているときに該セキュリティ関連情報を使用して前記コンピューティング環境と前記連合コンピューティング環境との間の信頼関係を確立する信頼サービスを実施する手段と
    を含み、
    前記連合ユーザ・ライフサイクル管理サービスを実施する手段が、少なくともシングルサインオン・サービスを実施するものであり、前記シングルサインオン・サービスの実施においてユーザを認証した前記コンピューティング環境が該ユーザから前記連合コンピューティング環境内のリソースに関する要求を受け付けたことに応答して、前記信頼サービスを実施する手段に対し、前記セキュリティ関連情報を要求し、前記セキュリティ関連情報を使用して認証アサーションを生成させ、前記連合コンピューティング環境で前記認証アサーションを提示して前記ユーザを前記リソースにアクセス可能にさせ、前記コンピュータ環境と前記連合コンピュータ環境との間の通信を、前記セキュリティ関連情報を用いて実行させる、データ処理システム。
  2. 前記セキュリティ関連情報は、暗号鍵、セキュリティ・トークン、アイデンティティ変換を含み、
    前記信頼サービスを実施する手段は、前記通信を、前記暗号鍵を用いて実行させ、前記認証アサーションを生成するために必要とされるトークンのタイプを、前記セキュリティ・トークンを用いて判定し、前記連合コンピューティング環境で提示するために前記認証アサーションに含める前記ユーザを表すアイデンティティのフォーマットを、前記アイデンティティ変換を用いて変換する、請求項１に記載のデータ処理システム。
  3. 前記連合ユーザ・ライフサイクル管理サービスを実施する手段からの要求を受け付けて、前記信頼サービスを実施する手段に前記信頼サービスを実施させるインターフェース手段
    をさらに含み、前記インターフェース手段の介在により、前記連合ユーザ・ライフサイクル管理サービスを実施する手段に対し、前記信頼サービスの内容が隠蔽される、請求項２に記載のデータ処理システム。
  4. 前記データ処理システムは、前記連合ユーザ・ライフサイクル管理サービスを実施する手段と前記信頼サービスを実施する手段とを備えるサーバを含む、請求項１に記載のデータ処理システム。
  5. 前記データ処理システムで同一のアプリケーションを実行することにより前記連合ユーザ・ライフサイクル管理サービスを実施する手段と前記信頼サービスを実施する手段として機能させる、請求項１に記載のデータ処理システム。
  6. 前記連合ユーザ・ライフサイクル管理サービスを実施する手段と前記信頼サービスを実施する手段が、同一の前記コンピューティング環境内に含まれる、請求項１に記載のデータ処理システム。
  7. 複数のコンピュータ・デバイスがネットワークを介して互いに接続されてなるコンピューティング環境であって、連合コンピューティング環境としての複数のコンピューティング環境と連携して動作する前記コンピューティング環境内で、単一のユーザ・セッションのライフサイクル中の前記複数のコンピューティング環境に跨る動作の管理を行う連合ユーザ・ライフサイクル管理サービスを実施する手段と、前記コンピューティング環境内で、前記コンピューティング環境と前記連合コンピューティング環境との間のセキュリティ関連情報を管理し、前記連合ユーザ・ライフサイクル管理サービスを実施しているときに該セキュリティ関連情報を使用して前記コンピューティング環境と前記連合コンピューティング環境との間の信頼関係を確立する信頼サービスを実施する手段とを含むデータ処理システムで行われる前記コンピューティング環境間の対話方法であって、
    前記連合ユーザ・ライフサイクル管理サービスを実施する手段が、少なくともシングルサインオン・サービスを実施するものであり、前記シングルサインオン・サービスの実施においてユーザを認証した前記コンピューティング環境が該ユーザから前記連合コンピューティング環境のリソースに関する要求を受け付けたことに応答して、前記信頼サービスを実施する手段に対し、前記セキュリティ関連情報および認証アサーションの生成を要求するステップと、
    前記信頼サービスを実施する手段が、前記セキュリティ関連情報を使用して前記認証アサーションを生成し、前記連合コンピューティング環境で前記認証アサーションを提示して前記ユーザを前記リソースにアクセス可能にさせ、前記コンピュータ環境と前記連合コンピュータ環境との間の通信を、前記セキュリティ関連情報を用いて実行させるステップとを含む、方法。
  8. 前記セキュリティ関連情報は、暗号鍵、セキュリティ・トークン、アイデンティティ変換を含み、
    前記実行させるステップでは、前記通信を、前記暗号鍵を用いて実行させ、前記認証アサーションを生成するために必要とされるトークンのタイプを、前記セキュリティ・トークンを用いて判定し、前記連合コンピューティング環境で提示するために前記認証アサーションに含める前記ユーザを表すアイデンティティのフォーマットを、前記アイデンティティ変換を用いて変換する、請求項７に記載の方法。
  9. 前記データ処理システムは、インターフェース手段をさらに含み、前記インタフェース手段が、前記連合ユーザ・ライフサイクル管理サービスを実施する手段からの要求を受け付けて、前記信頼サービスを実施する手段に前記信頼サービスを実施させるステップをさらに含み、前記インターフェース手段の介在により、前記連合ユーザ・ライフサイクル管理サービスを実施する手段に対し、前記信頼サービスの内容が隠蔽される、請求項８に記載の方法。
  10. 請求項７〜９のいずれか１項に記載の方法を実行するためのデータ処理システムで使用されるコンピュータ・デバイスにより可読なコンピュータ・プログラム。
JP2005210414A 2004-07-21 2005-07-20 データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム） Expired - Fee Related JP4832822B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/896,286 US20060021018A1 (en) 2004-07-21 2004-07-21 Method and system for enabling trust infrastructure support for federated user lifecycle management
US10/896,286 2004-07-21

Publications (2)

Publication Number Publication Date
JP2006031714A JP2006031714A (ja) 2006-02-02
JP4832822B2 true JP4832822B2 (ja) 2011-12-07

Family

ID=35658787

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005210414A Expired - Fee Related JP4832822B2 (ja) 2004-07-21 2005-07-20 データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム）

Country Status (3)

Country Link
US (1) US20060021018A1 (ja)
JP (1) JP4832822B2 (ja)
CN (1) CN100571129C (ja)

Families Citing this family (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006139747A (ja) * 2004-08-30 2006-06-01 Kddi Corp 通信システムおよび安全性保証装置
US7562382B2 (en) * 2004-12-16 2009-07-14 International Business Machines Corporation Specializing support for a federation relationship
US7784092B2 (en) * 2005-03-25 2010-08-24 AT&T Intellectual I, L.P. System and method of locating identity providers in a data network
US7895644B1 (en) * 2005-12-02 2011-02-22 Symantec Operating Corporation Method and apparatus for accessing computers in a distributed computing environment
JP5123209B2 (ja) * 2006-01-24 2013-01-23 ▲ホア▼▲ウェイ▼技術有限公司 モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ
MX2008010317A (es) * 2006-02-13 2008-09-23 Epostal Services Inc Sistema y metodo para la administracion de mensajeria y documentos.
US20070255958A1 (en) * 2006-05-01 2007-11-01 Microsoft Corporation Claim transformations for trust relationships
JP4819656B2 (ja) * 2006-11-17 2011-11-24 株式会社野村総合研究所 情報提供サーバ、情報提供システム、プログラム、及び記録媒体
US8171536B2 (en) * 2007-05-23 2012-05-01 Sony Computer Entertainment America Inc. Method and apparatus for authenticating users in a network
US8528058B2 (en) * 2007-05-31 2013-09-03 Microsoft Corporation Native use of web service protocols and claims in server authentication
US8347358B2 (en) 2007-06-25 2013-01-01 Microsoft Corporation Open enhanced federation security techniques
WO2009041319A1 (ja) * 2007-09-25 2009-04-02 Nec Corporation 証明書生成配布システム、証明書生成配布方法および証明書生成配布用プログラム
US8490160B2 (en) * 2007-10-04 2013-07-16 Microsoft Corporation Open federation security techniques with rate limits
US10594695B2 (en) * 2007-12-10 2020-03-17 Nokia Technologies Oy Authentication arrangement
US8291474B2 (en) * 2008-04-16 2012-10-16 Oracle America, Inc. Using opaque groups in a federated identity management environment
US8893242B2 (en) * 2008-04-29 2014-11-18 Ebay Inc. System and method for pool-based identity generation and use for service access
WO2010009176A1 (en) 2008-07-14 2010-01-21 Borland Software Corporation Open application lifecycle management framework
US8196177B2 (en) * 2008-10-16 2012-06-05 International Business Machines Corporation Digital rights management (DRM)-enabled policy management for a service provider in a federated environment
US9836702B2 (en) 2008-10-16 2017-12-05 International Business Machines Corporation Digital rights management (DRM)-enabled policy management for an identity provider in a federated environment
US8856512B2 (en) * 2008-12-30 2014-10-07 Intel Corporation Method and system for enterprise network single-sign-on by a manageability engine
JP2011034462A (ja) * 2009-08-04 2011-02-17 Canon Inc 情報処理装置及びその処理方法
US8544076B2 (en) * 2009-11-11 2013-09-24 Blackberry Limited Using a trusted token and push for validating the request for single sign on
US9544143B2 (en) 2010-03-03 2017-01-10 Duo Security, Inc. System and method of notifying mobile devices to complete transactions
US9532222B2 (en) 2010-03-03 2016-12-27 Duo Security, Inc. System and method of notifying mobile devices to complete transactions after additional agent verification
CN102215107B (zh) * 2010-04-12 2015-09-16 中兴通讯股份有限公司 一种实现身份管理互操作的方法及系统
US9189649B2 (en) * 2010-06-25 2015-11-17 International Business Machines Corporation Security model for workflows aggregating third party secure services
US9560036B2 (en) * 2010-07-08 2017-01-31 International Business Machines Corporation Cross-protocol federated single sign-on (F-SSO) for cloud enablement
US9667423B2 (en) 2010-09-27 2017-05-30 Nokia Technologies Oy Method and apparatus for accelerated authentication
US8990557B2 (en) * 2011-02-17 2015-03-24 Ebay Inc. Identity assertion framework
JP2012181662A (ja) * 2011-03-01 2012-09-20 Nomura Research Institute Ltd アカウント情報連携システム
US9021135B2 (en) * 2011-04-27 2015-04-28 Perspecsys Corp. System and method for tokenization of data for storage in a cloud
US10333711B2 (en) * 2011-06-17 2019-06-25 Microsoft Technology Licensing, Llc Controlling access to protected objects
US10044713B2 (en) * 2011-08-19 2018-08-07 Interdigital Patent Holdings, Inc. OpenID/local openID security
US9467463B2 (en) 2011-09-02 2016-10-11 Duo Security, Inc. System and method for assessing vulnerability of a mobile device
US9590959B2 (en) 2013-02-12 2017-03-07 Amazon Technologies, Inc. Data security service
US10075471B2 (en) 2012-06-07 2018-09-11 Amazon Technologies, Inc. Data loss prevention techniques
US10084818B1 (en) 2012-06-07 2018-09-25 Amazon Technologies, Inc. Flexibly configurable data modification services
US9286491B2 (en) 2012-06-07 2016-03-15 Amazon Technologies, Inc. Virtual service provider zones
JP6102296B2 (ja) * 2013-02-06 2017-03-29 株式会社リコー 情報処理システム、情報処理装置、認証方法及びプログラム
US9418213B1 (en) * 2013-02-06 2016-08-16 Amazon Technologies, Inc. Delegated permissions in a distributed electronic environment
JP6064636B2 (ja) 2013-02-06 2017-01-25 株式会社リコー 情報処理システム、情報処理装置、認証方法及びプログラム
US9466051B1 (en) 2013-02-06 2016-10-11 Amazon Technologies, Inc. Funding access in a distributed electronic environment
US10210341B2 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Delayed data access
US10211977B1 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Secure management of information using a security module
US9608813B1 (en) 2013-06-13 2017-03-28 Amazon Technologies, Inc. Key rotation techniques
US9547771B2 (en) 2013-02-12 2017-01-17 Amazon Technologies, Inc. Policy enforcement with associated data
US10467422B1 (en) 2013-02-12 2019-11-05 Amazon Technologies, Inc. Automatic key rotation
US9367697B1 (en) 2013-02-12 2016-06-14 Amazon Technologies, Inc. Data security with a security module
US9300464B1 (en) 2013-02-12 2016-03-29 Amazon Technologies, Inc. Probabilistic key rotation
US9705674B2 (en) 2013-02-12 2017-07-11 Amazon Technologies, Inc. Federated key management
US9294454B2 (en) * 2013-03-15 2016-03-22 Microsoft Technology Licensing, Llc Actively federated mobile authentication
CN105247528B (zh) 2013-06-27 2018-05-18 英特尔公司 连续多因素认证
US9456003B2 (en) 2013-07-24 2016-09-27 At&T Intellectual Property I, L.P. Decoupling hardware and software components of network security devices to provide security software as a service in a distributed computing environment
US9386007B2 (en) 2013-12-27 2016-07-05 Sap Se Multi-domain applications with authorization and authentication in cloud environment
JP6248641B2 (ja) * 2014-01-15 2017-12-20 株式会社リコー 情報処理システム及び認証方法
KR102144509B1 (ko) * 2014-03-06 2020-08-14 삼성전자주식회사 근접 통신 방법 및 장치
US9411975B2 (en) 2014-03-31 2016-08-09 Intel Corporation Methods and apparatus to securely share data
US9762590B2 (en) * 2014-04-17 2017-09-12 Duo Security, Inc. System and method for an integrity focused authentication service
US9397835B1 (en) 2014-05-21 2016-07-19 Amazon Technologies, Inc. Web of trust management in a distributed system
US9444846B2 (en) 2014-06-19 2016-09-13 Xerox Corporation Methods and apparatuses for trust computation
FR3022664B1 (fr) * 2014-06-20 2017-10-27 Peugeot Citroen Automobiles Sa Procede et systeme d'authentification
US9438421B1 (en) 2014-06-27 2016-09-06 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US9866392B1 (en) 2014-09-15 2018-01-09 Amazon Technologies, Inc. Distributed system web of trust provisioning
JP2016085641A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム
JP6459398B2 (ja) * 2014-10-30 2019-01-30 株式会社リコー 情報処理システム、情報処理装置、アクセス制御方法及びプログラム
WO2016149047A1 (en) * 2015-03-13 2016-09-22 United States Postal Service Methods and systems for data authentication services
US10469477B2 (en) 2015-03-31 2019-11-05 Amazon Technologies, Inc. Key export techniques
US20160306955A1 (en) * 2015-04-14 2016-10-20 Intel Corporation Performing user seamless authentications
EP3304336B1 (en) 2015-06-01 2019-10-09 Duo Security, Inc. Method for enforcing endpoint health standards
US10341384B2 (en) * 2015-07-12 2019-07-02 Avago Technologies International Sales Pte. Limited Network function virtualization security and trust system
US10073964B2 (en) 2015-09-25 2018-09-11 Intel Corporation Secure authentication protocol systems and methods
US10645068B2 (en) 2015-12-28 2020-05-05 United States Postal Service Methods and systems for secure digital credentials
US9747378B1 (en) * 2016-08-09 2017-08-29 Afilias Plc Linked web presence pages associated with a top level domain
US10552495B2 (en) * 2016-08-09 2020-02-04 Afilias Limited Linked network presence documents associated with a unique member of a membership-based organization
WO2018057510A1 (en) 2016-09-20 2018-03-29 United States Postal Service Methods and systems for a digital trust architecture
US10243946B2 (en) 2016-11-04 2019-03-26 Netskope, Inc. Non-intrusive security enforcement for federated single sign-on (SSO)
CN108076077A (zh) * 2016-11-08 2018-05-25 华为技术有限公司 一种会话控制方法及装置
US11089028B1 (en) * 2016-12-21 2021-08-10 Amazon Technologies, Inc. Tokenization federation service
US10846387B2 (en) 2017-07-12 2020-11-24 At&T Intellectual Property I, L.P. Managing access based on activities of entities
CN107911376A (zh) * 2017-11-29 2018-04-13 南京莱斯信息技术股份有限公司 一种非入侵式的web系统单点登录和访问控制实现方法
US10412113B2 (en) 2017-12-08 2019-09-10 Duo Security, Inc. Systems and methods for intelligently configuring computer security
US11658962B2 (en) 2018-12-07 2023-05-23 Cisco Technology, Inc. Systems and methods of push-based verification of a transaction
US11159511B1 (en) * 2019-01-10 2021-10-26 Microstrategy Incorporated Authentication protocol management
CN110321192B (zh) * 2019-04-29 2023-03-31 上海连尚网络科技有限公司 一种呈现寄宿程序的方法与设备
US11570164B2 (en) * 2019-07-30 2023-01-31 Dell Products L.P. System and method of single sign on to master website and silent authentication for subservient websites
US20220070166A1 (en) * 2020-08-28 2022-03-03 Health2047, Inc. Enhanced authentication techniques using virtual persona
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
CA3230514A1 (en) * 2021-09-03 2023-03-09 Bitnobi, Inc. Federated, decentralized data sharing
CN115883119A (zh) * 2021-09-29 2023-03-31 富联精密电子(天津)有限公司 服务验证方法、电子装置及存储介质
CN114024751B (zh) * 2021-11-05 2023-05-23 抖音视界有限公司 一种应用访问控制方法、装置、计算机设备及存储介质
US11962580B2 (en) * 2021-11-17 2024-04-16 Akamai Technologies, Inc. Browser extensionless phish-proof multi-factor authentication (MFA)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7290288B2 (en) * 1997-06-11 2007-10-30 Prism Technologies, L.L.C. Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network
AU2003215813A1 (en) * 2002-04-26 2003-11-10 International Business Machines Corporation Identity management system using single sign-on
US7219154B2 (en) * 2002-12-31 2007-05-15 International Business Machines Corporation Method and system for consolidated sign-off in a heterogeneous federated environment
US20040128546A1 (en) * 2002-12-31 2004-07-01 International Business Machines Corporation Method and system for attribute exchange in a heterogeneous federated environment
US7703128B2 (en) * 2003-02-13 2010-04-20 Microsoft Corporation Digital identity management
US8234387B2 (en) * 2003-06-05 2012-07-31 Intertrust Technologies Corp. Interoperable systems and methods for peer-to-peer service orchestration
US7831693B2 (en) * 2003-08-18 2010-11-09 Oracle America, Inc. Structured methodology and design patterns for web services

Also Published As

Publication number Publication date
US20060021018A1 (en) 2006-01-26
CN100571129C (zh) 2009-12-16
CN1725680A (zh) 2006-01-25
JP2006031714A (ja) 2006-02-02

Similar Documents

Publication Publication Date Title
JP4832822B2 (ja) データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム）
US7698375B2 (en) Method and system for pluggability of federation protocol runtimes for federated user lifecycle management
US8181225B2 (en) Specializing support for a federation relationship
US10810515B2 (en) Digital rights management (DRM)-enabled policy management for an identity provider in a federated environment
US7631346B2 (en) Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment
US8607322B2 (en) Method and system for federated provisioning
US7657639B2 (en) Method and system for identity provider migration using federated single-sign-on operation
JP4370258B2 (ja) ユーザ・セッションを管理するための方法、データ処理システム、およびコンピュータ・プログラム（異機種連携環境における統合サインオフのための方法およびシステム）
US20060048216A1 (en) Method and system for enabling federated user lifecycle management
US20060021017A1 (en) Method and system for establishing federation relationships through imported configuration files
US8042162B2 (en) Method and system for native authentication protocols in a heterogeneous federated environment
US8151317B2 (en) Method and system for policy-based initiation of federation management
US8554930B2 (en) Method and system for proof-of-possession operations associated with authentication assertions in a heterogeneous federated environment
US8561161B2 (en) Method and system for authentication in a heterogeneous federated environment
US7860883B2 (en) Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US20060218628A1 (en) Method and system for enhanced federated single logout
US20080021866A1 (en) Method and system for implementing a floating identity provider model across data centers
US20040128541A1 (en) Local architecture for federated heterogeneous system
KR100992016B1 (ko) 데이터 프로세싱 시스템 내에 연합 기능성을 제공하는 방법및 장치

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080530

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20090206

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110426

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20110516

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20110516

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110726

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110802

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110825

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110913

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20110913

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110921

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140930

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees