JP5765836B2 - パブリッシュ−サブスクライブ・モデルを用いたアイデンティティ・プロバイダ・ディスカバリ・サービス - Google Patents

Description

本開示は、フェデレーテッド環境におけるコンピューティング・リソースの管理に関し、本発明は特に、パブリッシュ−サブスクライブ・モデルを用いたアイデンティティ・プロバイダ・ディスカバリ・サービスのための方法に関する。

当該技術分野において、フェデレーテッド環境は周知である。フェデレーションとは、ユーザにシングルサインオンの使いやすい経験を提供するために協働する、たとえば企業、組織、機関などの別個のエンティティの組である。フェデレーテッド環境が典型的なシングルサインオン環境と異なる点は、２つの企業がユーザに関してどの情報をどのように移送するかを定義する直接の予め確立された関係を有する必要がないことである。フェデレーテッド環境内で、エンティティは、ユーザの認証、他のエンティティによって提示された認証アサーション（例、認証トークン）の受諾、および保証されたユーザのアイデンティティをローカル・エンティティ内で理解されるアイデンティティに変換する何らかの形の変換の提供に対処するサービスを提供する。フェデレーションは、サービス・プロバイダにおける管理の負担を軽減する。サービス・プロバイダ（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ：ＳＰ）は、フェデレーション全体に関してその信頼関係に依拠できる。すなわちサービス・プロバイダは、ユーザが認証を行うドメインであるユーザの認証ホーム・ドメインによって遂行される認証に依拠できるため、たとえばユーザ・パスワード情報などの認証情報を管理する必要がない。

特に、フェデレーテッド・エンティティは、フェデレーテッド・ユーザに関するアイデンティティ情報および属性情報を提供するユーザのホーム・ドメインとして働いてもよい。アイデンティティ情報、アイデンティティもしくは認証アサーション、またはアイデンティティ・サービスを提供するフェデレーテッド・コンピューティング環境内のエンティティは、アイデンティティ・プロバイダ（ｉｄｅｎｔｉｔｙ ｐｒｏｖｉｄｅｒ：ＩｄＰ）と呼ばれる。同じフェデレーション内の他のエンティティまたはフェデレーション・パートナは、たとえばユーザのアイデンティティ・プロバイダによって提供されるシングルサインオン・トークンを受諾するなど、ユーザの認証証明の一次管理に対してアイデンティティ・プロバイダに依拠してもよい。アイデンティティ・プロバイダは、フェデレーテッド・コンピューティング環境内の他のエンティティに対するサービスとしてアイデンティティ情報を提供する特定のタイプのサービスである。

フェデレーテッド・シングルサインオン（Ｆｅｄｅｒａｔｅｄ ｓｉｎｇｌｅ ｓｉｇｎ−ｏｎ：Ｆ−ＳＳＯ）は、ユーザがサービス・プロバイダ（ＳＰ）と直接対話して、認証の状況においてアイデンティティ情報を受取る目的のためにＳＰとＩｄＰとの間の安全な信頼関係を利用することを可能にする。

アイデンティティ・プロバイダ・ディスカバリに対する典型的なモデルは、エンド・ユーザと直接対話するサービスである。このアプローチは、たとえばエンド・ユーザが利用可能なアイデンティティ・プロバイダのリストから選ぶことを可能にすること、または属性同意（ａｔｔｒｉｂｕｔｅ ｃｏｎｓｅｎｔ）を容易にすることなど、広範囲のシナリオにおいて有用である。公知のディスカバリ・サービスの実施は典型的にスタンドアロンの態様で動作するか、またはサービス・プロバイダに直接埋め込まれることによって動作する。高レベルにおいて、典型的なディスカバリ・モデルの１つは次のとおりに動作する。エンド・ユーザはアプリケーション（ＳＰ）にアクセスし、次いでアイデンティティ・プロバイダを手動で選択する。次いで、サービス・プロバイダはエンド・ユーザを選択されたアイデンティティ・プロバイダにリダイレクトする。エンド・ユーザはアイデンティティ・プロバイダに対する認証を行い、次いでアイデンティティ・プロバイダは（認証後に）エンド・ユーザを（典型的にＨＴＴＰに基づくリダイレクトによって）リダイレクトしてアプリケーションに戻す。加えてＩｄＰは、そのフェデレーテッド・ユーザが認証されたという証拠を提供する、たとえばセキュリティ・アサーション・マークアップ言語（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：ＳＡＭＬ）アサーションまたはトークンなどのアイデンティティ・アサーションをＳＰに提供する。次いで、プロセスを完了するためにフェデレーテッド・ユーザとＳＰとの間にエンド・ユーザ・セッションが確立される。

別の典型的なディスカバリ・アプローチは、ＳＰがユーザを別のサービスにリダイレクトし、そのサービスがユーザと対話してＩｄＰを選択させるためのものである。次いでそのサービスは認証のためにユーザをＩｄＰにリダイレクトし、次いでユーザはＳＰに戻るようリダイレクトされる。

いくつかのシナリオにおいては、地理的に分散されたインスタンスに対して単一のアイデンティティ・プロバイダが実現されてもよい。この場合、ＳＰへのアクセスを試みるユーザは、最も近いＩｄＰインスタンスまたは最も適切なＩｄＰインスタンスに向けられる必要がある。共有される特許文献１に記載されるとおり、この動作はアイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスによって提供されてもよい。ＩｄＰインスタンス・ディスカバリ・サービスは、アイデンティティ・プロバイダ・インスタンスの組のうちの特定のアイデンティティ・プロバイダ・インスタンスの自動ディスカバリおよびそこへのバインディングを提供する。このアプローチにおいて、特定のアイデンティティ・プロバイダの選択は、たとえばユーザの（ネットワークまたは地理的）近接、ＩｄＰインスタンスの負荷または可用性、ＩｄＰインスタンスの能力、特定のインスタンスに関連する性能メトリック、既存のＩｄＰバインディング、または何らかの組み合わせなど、１つまたはそれ以上の基準に基づいていてもよい。

米国特許出願第１２／９５９，４１３号

ＩｄＰインスタンス・ディスカバリ・サービスは、サービス・プロバイダがＦ−ＳＳＯプロトコルの完了のために適切なＩｄＰインスタンスの場所を動的に検索することを可能にするが、こうした技術はＦ−ＳＳＯ環境に対して外部から動作するように設計されており、それらの技術は必要に応じてＩｄＰインスタンス情報を得るために「プル型（ｐｕｌｌ−ｂａｓｅｄ）」アプローチに依存している。

本発明は、強化されたアイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービス（ｉｄｅｎｔｉｔｙ ｐｒｏｖｉｄｅｒ ｉｎｓｔａｎｃｅ ｄｉｓｃｏｖｅｒｙ ｓｅｒｖｉｃｅ：ＩｄＰＩＤＳ）を記載する。このアプローチにおいて、ディスカバリ・サービス・プロキシは好ましくは（クラウド型であってもよい）Ｆ−ＳＳＯ環境に統合されており、外部ＩｄＰインスタンス・ディスカバリ・サービスと対話するために用いられる。ディスカバリ・サービス・プロキシは、ＩｄＰインスタンス要求をディスカバリ・サービスにプロキシし、かかる要求に対する応答を受取る。応答は典型的に、要求を処理するためにディスカバリ・サービスによって割り当てられたインスタンスのアイデンティティを含む。プロキシは、インスタンス割り当て（単数または複数）を保存するキャッシュを維持する。プロキシにおいて新たなインスタンス要求を受取るとき、プロキシはそれらの要求をディスカバリ・サービスにプロキシする代わりに、キャッシュされた割り当てデータを用いて適切な応答を提供することによって、要求されるＩｄＰインスタンスを識別するために必要な時間を減らすことができる。プロキシは、ディスカバリ・サービスからの更新をサブスクライブすることによって自身のローカル・キャッシュを動的に維持および管理し、その更新は、ＩｄＰサービスを含む地理的に分散されたインスタンスの組において起こるＩｄＰインスタンスの変化（たとえばサーバがメンテナンスのためにオフラインにされること、新たなサービスが追加されることなど）を識別するものである。好ましくは、更新がパブリケーション−サブスクリプション（ｐｕｂｌｉｃａｔｉｏｎ−ｓｕｂｓｃｒｉｐｔｉｏｎ：ｐｕｂ−ｓｕｂ）モデルを用いてプロキシに提供されることによって、プロキシがバックエンドＩｄＰサービスの変更に関する通知をプロアクティブに受取るようにする。

前述は、本発明のより関係のある特徴のいくつかを概説したものである。これらの特徴は単なる例示であると解釈されるべきである。開示される発明を異なる態様で適用するか、または以下に記載されるとおりに本発明を修正することによって、多くの他の有益な結果が達成され得る。

第１の局面から見て、本発明は、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するための方法を提供し、この方法は、アイデンティティ・プロバイダ・インスタンスに対する要求がディスカバリ・サービスによって処理されるときに、アイデンティティ・プロバイダ・インスタンスを識別するデータを受取りかつ保存するステップと、ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、その更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、更新に基づいてデータを修正するステップと、アイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、その修正されたデータを用いることにより、その新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップとを含む。

好ましくは、本発明が提供する方法において、そのデータは、要求と、その要求に対してサービスするためにディスカバリ・サービスによって選択されるアイデンティティ・プロバイダ・インスタンスとを関連付ける割り当てデータである。

好ましくは、本発明が提供する方法において、更新は定期的または非同期的に受取られる。

好ましくは、本発明が提供する方法において、通知サービスは、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスによって提供されるウェブ・サービスである。

好ましくは、本発明が提供する方法は、更新をサブスクライブするステップをさらに含む。

好ましくは、本発明が提供する方法において、更新は、アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上に関連する負荷、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスの可用性、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する性能メトリック、および１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディングのうちの１つを含む。

好ましくは、本発明が提供する方法において、データはポリシまたはビジネス論理に従って修正される。

別の局面から見て、本発明は、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するための装置を提供し、この装置は、プロセッサと、コンピュータ・プログラム命令を保持するコンピュータ・メモリとを含み、そのコンピュータ・プログラム命令は、プロセッサによって実行されるときに、アイデンティティ・プロバイダ・インスタンスに対する要求がディスカバリ・サービスによって処理されるときに、アイデンティティ・プロバイダ・インスタンスを識別するデータを受取りかつ保存するステップと、ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、その更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、更新に基づいてデータを修正するステップと、アイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、その修正されたデータを用いることにより、その新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップとを含む方法を実行する。

好ましくは、本発明が提供する装置において、そのデータは、要求と、その要求に対してサービスするためにディスカバリ・サービスによって選択されるアイデンティティ・プロバイダ・インスタンスとを関連付ける割り当てデータである。

好ましくは、本発明が提供する装置において、更新は定期的または非同期的に受取られる。

好ましくは、本発明が提供する装置において、通知サービスは、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスによって提供されるウェブ・サービスである。

好ましくは、本発明が提供する装置において、その方法は、更新をサブスクライブするステップをさらに含む。

好ましくは、本発明が提供する装置において、更新は、アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上に関連する負荷、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスの可用性、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する性能メトリック、および１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディングのうちの１つを含む。

好ましくは、本発明が提供する装置において、データはポリシまたはビジネス論理に従って修正される。

別の局面から見て、本発明は、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するためにデータ処理システムにおいて用いるためのコンピュータ読取り可能媒体内のコンピュータ・プログラム製品を提供し、このコンピュータ・プログラム製品はコンピュータ・プログラム命令を保持し、そのコンピュータ・プログラム命令は、データ処理システムによって実行されるときに、アイデンティティ・プロバイダ・インスタンスに対する要求がディスカバリ・サービスによって処理されるときに、アイデンティティ・プロバイダ・インスタンスを識別するデータを受取りかつ保存するステップと、ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、その更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、更新に基づいてデータを修正するステップと、アイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、その修正されたデータを用いることにより、その新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップとを含む方法を実行する。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、そのデータは、要求と、その要求に対してサービスするためにディスカバリ・サービスによって選択されるアイデンティティ・プロバイダ・インスタンスとを関連付ける割り当てデータである。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、更新は定期的または非同期的に受取られる。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、通知サービスは、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスによって提供されるウェブ・サービスである。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、その方法は、更新をサブスクライブするステップをさらに含む。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、更新は、アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上に関連する負荷、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスの可用性、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する性能メトリック、および１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディングのうちの１つを含む。

好ましくは、本発明が提供するコンピュータ・プログラム製品において、データはポリシまたはビジネス論理に従って修正される。

別の局面から見て、本発明は、アイデンティティ・プロバイダ・インスタンスを識別するためのシステムを提供し、このシステムは、ハードウェア・エレメント上でサポートされ、かつ関連するキャッシュを有するプロキシであって、このプロキシはアイデンティティ・プロバイダ・インスタンス・ディスカバリ要求を発行する、プロキシと、プロキシによって発行される各アイデンティティ・プロバイダ・インスタンス・ディスカバリ要求を受取り、選択を行い、かつその選択を識別するデータをプロキシに戻し、キャッシュに保存するアイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスと、プロキシがアイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスから更新を受取るためにサブスクライブするための通知サービスとを含み、少なくとも１つの更新はディスカバリ・サービスに関連するリソースに関連し、かつキャッシュに保存されたデータを更新するためにプロキシによって用いられる。

好ましくは、本発明が提供するシステムにおいて、通知サービスはパブリッシュ−サブスクライブ・モデルに従って動作する。

好ましくは、本発明が提供するシステムにおいて、更新は定期的または非同期的に提供される。

好ましくは、本発明が提供するシステムにおいて、キャッシュに保存されるデータはポリシまたはビジネス論理に従って更新される。

添付の図面を参照して、本発明の好ましい実施形態を単なる例として説明する。

例示的実施形態の例示的局面が実現され得る分散データ処理環境の例示的ブロック図である。 例示的実施形態の例示的局面が実現され得るデータ処理システムの例示的ブロック図である。 記載される主題の実施形態をサポートするために用いられ得るフェデレーテッド・アーキテクチャ・コンポーネントと、所与のドメインにおけるデータ処理システムとの統合を示すブロック図である。 本発明の実施形態に従ってアイデンティティ・プロバイダ・ディスカバリ・プロセスが実現され得るクラウド・コンピュート環境の抽象化モデル層を示す図である。 アイデンティティ・プロバイダのディスカバリを可能にするための一般的技術を示す図である。 エンド・ユーザを特定のＩｄＰインスタンスにバインディングまたはルーティングするための公知のロード・バランシングＤＮＳに基づく機構を示す図である。 公知の企業内ＩｄＰインスタンス・ディスカバリ・サービス（ＩｄＰＩＤＳ）を示す図である。 図７の実施形態におけるＳＰ、ＩｄＰＩＤＳおよびＩｄＰコンポーネント間の対話を示す図である。 Ｆ−ＳＳＯクラウド・コンピュート環境内のディスカバリ・サービス・プロキシの実現を示す図である。 本開示の教示に従う、ディスカバリ・サービス・プロキシおよびＩｄＰＩＤＳによって実現されるパブリッシュ−サブスクライブ機構を示す図である。 ＷＳ通知サービスとして実現される代表的なパブリッシュ−サブスクライブ機構を示す図である。

図面を参照し、特に図１〜２を参照すると、本開示の例示的実施形態が実現され得るデータ処理環境の例示的な図が提供される。図１〜２は単なる例示であって、開示される主題の局面または実施形態が実現され得る環境に関するいかなる限定を主張または暗示することも意図されないことが認識されるべきである。本発明の趣旨および範囲から逸脱することなく、図示される環境に多くの修正がなされてもよい。

クライアント−サーバ・モデル
ここで図面を参照すると、図１は、例示的実施形態の局面が実現され得る例示的分散データ処理システムの図形表現を示す。分散データ処理システム１００は、例示的実施形態の局面が実現され得るコンピュータのネットワークを含んでもよい。分散データ処理システム１００は、分散データ処理システム１００内でともに接続されるさまざまなデバイスおよびコンピュータ間の通信リンクを提供するために用いられる媒体である少なくとも１つのネットワーク１０２を含む。ネットワーク１０２は、たとえばワイヤ、無線通信リンク、または光ファイバ・ケーブルなどの接続を含んでもよい。

図示される例において、サーバ１０４およびサーバ１０６は、記憶ユニット１０８とともにネットワーク１０２に接続される。加えて、クライアント１１０、１１２および１１４もネットワーク１０２に接続される。これらのクライアント１１０、１１２および１１４は、たとえばパーソナル・コンピュータまたはネットワーク・コンピュータなどであってもよい。図示される例において、サーバ１０４は、たとえばブート・ファイル、オペレーティング・システム画像、およびアプリケーションなどのデータをクライアント１１０、１１２および１１４に提供する。図示される例において、クライアント１１０、１１２および１１４はサーバ１０４に対するクライアントである。分散データ処理システム１００は、図示されない付加的なサーバ、クライアント、およびその他のデバイスを含んでもよい。

図示される例において、分散データ処理システム１００はインターネットであり、ネットワーク１０２は、互いに通信するために伝送制御プロトコル／インターネット・プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰ）のプロトコルの組を用いるネットワークおよびゲートウェイの世界的集合体を表す。インターネットの中心には、データおよびメッセージをルーティングする何千もの商業用、政府用、教育用およびその他のコンピュータ・システムからなる主要ノードまたはホスト・コンピュータ間の高速データ通信ラインのバックボーンがある。もちろん分散データ処理システム１００は、たとえばイントラネット、ローカル・エリア・ネットワーク（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＬＡＮ）、または広域ネットワーク（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＡＮ）など、いくつかの異なるタイプのネットワークを含むように実現されてもよい。上述のとおり、図１は開示される主題の異なる実施形態に対するアーキテクチャ上の限定ではなく、例であることが意図されているため、図１に示される特定のエレメントは、本発明の例示的実施形態が実現され得る環境に関する限定であると考えられるべきではない。

ここで図２を参照すると、例示的実施形態が実現され得るデータ処理システムのブロック図が示される。データ処理システム２００は、たとえば図１におけるサーバ１０４またはクライアント１１０などのコンピュータの例であり、その中には例示的実施形態に対するプロセスを実現するコンピュータ使用可能プログラム・コードまたは命令が位置していてもよい。この例示的実施例において、データ処理システム２００は通信ファブリック２０２を含み、通信ファブリック２０２は、プロセッサ・ユニット２０４、メモリ２０６、永続的記憶装置２０８、通信ユニット２１０、入出力（ｉｎｐｕｔ／ｏｕｔｐｕｔ：Ｉ／Ｏ）ユニット２１２、およびディスプレイ２１４の間の通信を提供する。

プロセッサ・ユニット２０４は、メモリ２０６にロードされてもよいソフトウェアに対する命令を実行する働きをする。プロセッサ・ユニット２０４は、特定の実施によって１つまたはそれ以上のプロセッサの組であってもよいし、マルチプロセッサ・コアであってもよい。さらに、プロセッサ・ユニット２０４は、単一のチップ上にメイン・プロセッサが２次プロセッサとともに存在する１つまたはそれ以上の異種プロセッサ・システムを用いて実現されてもよい。別の例示的実施例として、プロセッサ・ユニット２０４は、同タイプの複数のプロセッサを含む対称マルチプロセッサ・システムであってもよい。

メモリ２０６および永続的記憶装置２０８は、記憶装置の例である。記憶装置とは、一時的態様もしくは永続的態様またはその両方で情報を保存できるあらゆるハードウェアのことである。これらの例におけるメモリ２０６は、たとえばランダム・アクセス・メモリまたはあらゆるその他の好適な揮発性もしくは不揮発性の記憶装置などであってもよい。永続的記憶装置２０８は、特定の実施に依存してさまざまな形を取ってもよい。たとえば、永続的記憶装置２０８は１つまたはそれ以上のコンポーネントまたはデバイスを含んでもよい。たとえば、永続的記憶装置２０８はハード・ドライブ、フラッシュ・メモリ、書換え可能光ディスク、書換え可能磁気テープ、または上記の何らかの組み合わせなどであってもよい。加えて、永続的記憶装置２０８によって用いられる媒体はリムーバブルであってもよい。たとえば、永続的記憶装置２０８に対してリムーバブル・ハード・ドライブが用いられてもよい。

これらの例における通信ユニット２１０は、他のデータ処理システムまたはデバイスとの通信を提供する。これらの例において、通信ユニット２１０はネットワーク・インタフェース・カードである。通信ユニット２１０は、物理的通信リンクおよび無線通信リンクのいずれかまたは両方を用いることによって、通信を提供してもよい。

入出力ユニット２１２は、データ処理システム２００に接続され得る他のデバイスとのデータの入力および出力を可能にする。たとえば、入出力ユニット２１２は、キーボードおよびマウスを通じたユーザ入力のための接続を提供してもよい。さらに、入出力ユニット２１２はプリンタに出力を送ってもよい。ディスプレイ２１４は、ユーザに対して情報を表示するための機構を提供する。

オペレーティング・システムおよびアプリケーションまたはプログラムに対する命令は、永続的記憶装置２０８に位置する。これらの命令は、プロセッサ・ユニット２０４による実行のためにメモリ２０６にロードされてもよい。異なる実施形態のプロセスは、たとえばメモリ２０６などのメモリに位置してもよい、コンピュータに実現される命令を用いて、プロセッサ・ユニット２０４によって行われてもよい。これらの命令は、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ読取り可能プログラム・コードと呼ばれ、それはプロセッサ・ユニット２０４内のプロセッサによって読取られて実行されてもよい。異なる実施形態におけるプログラム・コードは、たとえばメモリ２０６または永続的記憶装置２０８など、異なる物理的コンピュータ読取り可能媒体または有形のコンピュータ読取り可能媒体において具現化されてもよい。

コンピュータ読取り可能媒体２１８上にはプログラム・コード２１６が機能的な形で位置しており、コンピュータ読取り可能媒体２１８は選択的にリムーバブルであり、かつプロセッサ・ユニット２０４による実行のためにデータ処理システム２００にロードされるか、または移送されてもよい。これらの例において、プログラム・コード２１６およびコンピュータ読取り可能媒体２１８はコンピュータ・プログラム製品２２０を形成する。一実施例において、コンピュータ読取り可能媒体２１８は、たとえば記憶装置への移送のために永続的記憶装置２０８の部分であるドライブまたはその他のデバイス、たとえば永続的記憶装置２０８の部分であるハード・ドライブなどの中に挿入または設置される光ディスクまたは磁気ディスクなどの有形の形態であってもよい。有形の形態のコンピュータ読取り可能媒体２１８はさらに、データ処理システム２００に接続される永続的記憶装置、たとえばハード・ドライブ、サム・ドライブ、またはフラッシュ・メモリなどの形を取ってもよい。有形の形態のコンピュータ読取り可能媒体２１８は、コンピュータ記録可能記憶媒体とも呼ばれる。場合によって、コンピュータ読取り可能媒体２１８はリムーバブルでなくてもよい。

代替的に、プログラム・コード２１６は通信リンクを通じて通信ユニット２１０へ、もしくは接続を通じて入出力ユニット２１２へ、またはその両方で移送されることによって、コンピュータ読取り可能媒体２１８からデータ処理システム２００に移送されてもよい。例示的実施例において、通信リンクもしくは接続またはその両方は、物理的なものであっても無線であってもよい。加えてコンピュータ読取り可能媒体は、たとえばプログラム・コードを含む通信リンクまたは無線送信などの非有形媒体の形を取ってもよい。データ処理システム２００に対して例示される異なるコンポーネントは、異なる実施形態が実現され得る態様にアーキテクチャ上の限定を与えることを意味するものではない。データ処理システム２００に対して例示されるコンポーネントに追加されるか、またはその代わりのコンポーネントを含むデータ処理システムにおいて、異なる例示的実施形態が実現されてもよい。図２に示される他のコンポーネントが、図示される例示的実施例と異なっていてもよい。一例として、データ処理システム２００における記憶装置は、データを保存し得るあらゆるハードウェア装置である。メモリ２０６、永続的記憶装置２０８、およびコンピュータ読取り可能媒体２１８は、有形の形態の記憶装置の例である。

別の例においては、通信ファブリック２０２を実現するためにバス・システムが用いられてもよく、バス・システムはたとえばシステム・バスまたは入出力バスなどの１つまたはそれ以上のバスで構成されてもよい。もちろんバス・システムは、バス・システムに取付けられた異なるコンポーネントまたはデバイス間のデータの移送を提供するあらゆる好適なタイプのアーキテクチャを用いて実現されてもよい。加えて通信ユニットは、たとえばモデムまたはネットワーク・アダプタなど、データを送信および受信するために用いられる１つまたはそれ以上のデバイスを含んでもよい。さらにメモリは、たとえばメモリ２０６、またはたとえば通信ファブリック２０２に存在し得るインタフェースおよびメモリ・コントローラ・ハブにおいて見出されるものなどのキャッシュなどであってもよい。

本発明の動作を行うためのコンピュータ・プログラム・コードは、オブジェクト指向プログラミング言語、たとえばＪａｖａ（商標）、Ｓｍａｌｌｔａｌｋ（商標）、Ｃ＋＋など、および従来の手続き型プログラミング言語、たとえば「Ｃ」プログラミング言語または類似のプログラミング言語などを含む、１つまたはそれ以上のプログラミング言語のあらゆる組み合わせで書かれていてもよい。プログラム・コードは、すべてがユーザのコンピュータで実行されてもよいし、スタンド・アロン・ソフトウェア・パッケージとして部分的にユーザのコンピュータで実行されてもよいし、一部がユーザのコンピュータで、一部がリモート・コンピュータで実行されてもよいし、すべてがリモート・コンピュータまたはサーバで実行されてもよい。後者のシナリオにおいて、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含むあらゆるタイプのネットワークを通じてユーザのコンピュータに接続されてもよいし、（たとえば、インターネット・サービス・プロバイダを用いてインターネットを通じて）外部コンピュータへの接続が行われてもよい。

図１〜２のハードウェアは実施によって変化してもよいことを通常の当業者は認識するだろう。図１〜２に示されるハードウェアに加えて、またはその代わりに、たとえばフラッシュ・メモリ、同等の不揮発性メモリ、または光ディスク・ドライブなど、他の内部ハードウェアまたは周辺デバイスが用いられてもよい。加えて、例示的実施形態のプロセスは、開示される主題の趣旨および範囲から逸脱することなく、前述のＳＭＰシステム以外のマルチプロセッサ・データ処理システムに適用されてもよい。

以下から分かるとおり、本明細書に記載される技術は、たとえば図１に示されるものなどの標準的なクライアント−サーバ・パラダイム内でともに動作してもよく、ここではクライアント・マシンが、１つまたはそれ以上のマシンの組において実行するインターネット・アクセス可能なウェブベースのポータルと通信する。エンド・ユーザは、ポータルにアクセスして対話できるインターネット接続可能デバイス（例、デスクトップ・コンピュータ、ノート型コンピュータ、インターネット接続可能モバイル・デバイスなど）を動作させる。典型的に、各クライアントまたはサーバ・マシンは、ハードウェアおよびソフトウェアを含むたとえば図２に示されるものなどのデータ処理システムであり、これらのエンティティは、たとえばインターネット、イントラネット、エクストラネット、プライベート・ネットワーク、またはあらゆるその他の通信媒体もしくはリンクなどのネットワーク上で互いに通信する。データ処理システムは典型的に、１つまたはそれ以上のプロセッサと、オペレーティング・システムと、１つまたはそれ以上のアプリケーションと、１つまたはそれ以上のユーティリティとを含む。データ処理システム上のアプリケーションは、ＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩおよびＷＳＦＬなどに対するサポートを限定なしに含む、ウェブ・サービスに対するネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩおよびＷＳＦＬに関する情報は、これらの規格を開発および維持する責を負うワールド・ワイド・ウェブ・コンソーシアム（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ：Ｗ３Ｃ）より入手可能である。ＨＴＴＰおよびＸＭＬに関するさらなる情報は、インターネット技術タスク・フォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ：ＩＥＴＦ）より入手可能である。これらの規格に精通していることが前提とされる。

フェデレーション・モデル
上述のとおり、本明細書における一実施形態において、アイデンティティ・プロバイダ・インスタンス・ディスカバリは「フェデレーテッド」環境の状況において実現される。よって以下の背景が提供される。一般的に、企業は独自のユーザ・レジストリを有し、独自のユーザの組との関係を維持する。典型的に、各企業はこれらのユーザを認証する独自の手段を有する。しかし、フェデレーテッド・スキームにおいては、企業が集合的態様で協働することによって、企業が企業のフェデレーションに参加することによって、１つの企業のユーザが、企業の組との関係を利用できるようにする。ユーザは、あたかも各企業と直接関係を有しているかのように、フェデレーテッド企業のいずれにおけるリソースへのアクセスも認められ得る。ユーザは目的の各ビジネスに登録することを要求されないし、ユーザは自身を識別および認証することを絶えず要求されることがない。よって、このフェデレーテッド環境内で、認証スキームは、情報技術における急速に発展する異種環境内でのシングルサインオン経験を可能にする。

周知のとおり、フェデレーションとは、ユーザにシングルサインオンの使いやすい経験を提供するために協働する、たとえば企業、企業内の論理ユニット、組織、機関などの別個のエンティティの組である。フェデレーテッド環境が典型的なシングルサインオン環境と異なる点は、２つの企業がユーザに関してどの情報をどのように移送するかを定義する直接の予め確立された関係を有する必要がないことである。フェデレーテッド環境内で、エンティティは、ユーザの認証、他のエンティティによって提示された認証アサーション（例、認証トークン）の受諾、および保証されたユーザのアイデンティティをローカル・エンティティ内で理解されるアイデンティティに変換する何らかの形の変換の提供に対処するサービスを提供する。

フェデレーションは、サービス・プロバイダにおける管理の負担を軽減する。サービス・プロバイダは、フェデレーション全体に関してその信頼関係に依拠できる。すなわちサービス・プロバイダは、ユーザの認証ホーム・ドメインまたはアイデンティティ・プロバイダによって遂行される認証に依拠できるため、たとえばユーザ・パスワード情報などの認証情報を管理する必要がない。フェデレーテッド環境は、ユーザが第１のエンティティにおいて認証を行うことを可能にし、第１のエンティティは、第２のエンティティにおいて用いるためのユーザに関する認証アサーションを発行するための発行者（ｉｓｓｕｉｎｇ ｐａｒｔｙ）の役割をしてもよい。次いでユーザは、第２のエンティティにおいて明確に再認証を行う必要なく、第１のエンティティによって発行された認証アサーションを提示することによって、依拠者（ｒｅｌｙｉｎｇ ｐａｒｔｙ）と呼ばれる第２の別個のエンティティにおける保護されたリソースにアクセスできる。発行者から依拠者に渡される情報はアサーションの形であり、このアサーションはステートメントの形の異なるタイプの情報を含んでもよい。たとえば、アサーションはユーザの認証アイデンティティに関するステートメントであってもよいし、特定のユーザに関連するユーザ属性情報に関するステートメントであってもよい。さらに、依拠者のアクセス制御規則、アイデンティティ・マッピング規則、およびおそらくは依拠者によって維持されるいくつかのユーザ属性に基づいて、依拠者のリソースへのアクセスを提供するために、この情報が依拠者によって用いられてもよい。

アイデンティティ・プロバイダ（ＩｄＰ）とは、フェデレーテッド・コンピューティング環境内の他のエンティティに対するサービスとして、アイデンティティ情報を提供する特定のタイプのサービスである。ほとんどのフェデレーテッド・トランザクションに関して、認証アサーションのための発行者は通常アイデンティティ・プロバイダとなる。あらゆるその他のエンティティは、アイデンティティ・プロバイダとは区別され得る。フェデレーテッド・コンピューティング環境内でサービスを提供するあらゆるその他のエンティティは、サービス・プロバイダと分類され得る。一旦ユーザがアイデンティティ・プロバイダに対して認証を行うと、所与のフェデレーテッド・セッションまたは所与のフェデレーテッド・トランザクションの期間にわたり、フェデレーションの他のエンティティまたは企業は単なるサービス・プロバイダとみなされてもよい。

たとえば、ユーザの認証証明を生成および確認する能力を有する企業が複数存在し得るなどの理由によって、フェデレーテッド環境内にアイデンティティ・プロバイダとして働き得る複数の企業が存在し得ることが可能かもしれないが、フェデレーテッド・トランザクションは通常単一のアイデンティティ・プロバイダのみを伴う。たとえば、フェデレーション内にユーザがフェデレーテッド記載または登録動作を行ったエンティティがただ１つしか存在しないなどの理由によって、ユーザを認証できる単一のフェデレーテッド・エンティティしか存在しないとき、フェデレーテッド環境全体にわたるユーザのトランザクションをサポートするために、このエンティティがユーザのアイデンティティ・プロバイダとして働くことが期待される。

ここで図３を参照すると、ブロック図は、アイデンティティ・プロバイダをサポートするために用いられ得るいくつかのフェデレーテッド・アーキテクチャ・コンポーネントと、所与のドメインにおける既存のデータ処理システムとの統合を示す。フェデレーテッド環境は、ユーザに対するさまざまなサービスを提供するフェデレーテッド・エンティティを含む。ユーザ３１２はクライアント・デバイス３１４と対話し、クライアント・デバイス３１４はブラウザ・アプリケーション３１６およびさまざまなその他のクライアント・アプリケーション３１８をサポートしてもよい。ユーザ３１２は、クライアント・デバイス３１４、ブラウザ３１６、またはユーザと他のデバイスおよびサービスとの間のインタフェースとして働くあらゆるその他のソフトウェアとは異なる。いくつかの場合に、以下の説明ではクライアント・アプリケーション内で明示的に動作するユーザと、そのユーザの代理として働くクライアント・アプリケーションとを区別することがある。しかし一般的にリクエスタは、ユーザの代理として働くことが想定され得る、たとえばクライアントに基づくアプリケーション、ブラウザ、またはＳＯＡＰクライアントなどの中間者である。

ブラウザ・アプリケーション３１６は、たとえばＨＴＴＰ通信コンポーネント３２０およびマークアップ言語（ＭＬ）インタープリタ３２２などの多くのモジュールを含む典型的なブラウザであってもよい。ブラウザ・アプリケーション３１６はさらに、仮想マシン・ランタイム環境を必要としてもしなくてもよい、たとえばウェブ・サービス・クライアント３２４もしくはダウンロード可能アプレットまたはその両方などのプラグインをサポートしてもよい。ウェブ・サービス・クライアント３２４は、非集中化された分散環境における構造化および型付けされた情報の交換を定めるための軽量プロトコルであるシンプル・オブジェクト・アクセス・プロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ：ＳＯＡＰ）を用いてもよい。ＳＯＡＰは、次の３つの部分からなるＸＭＬに基づくプロトコルである。すなわち、メッセージ内に何があるかおよびそれをどのように処理するかを説明するためのフレームワークを定めるエンベロープと、アプリケーションの定めたデータ・タイプのインスタンスを表すための符号化規則の組と、リモート・プロシージャ・コールおよび応答を表現するための規定（ｃｏｎｖｅｎｔｉｏｎ）とである。ユーザ３１２はブラウザ・アプリケーション３１６を用いてウェブベースのサービスにアクセスしてもよいが、ユーザ３１２はクライアント・デバイス３１４上の他のウェブ・サービス・クライアントを通じてウェブ・サービスにアクセスしてもよい。フェデレーテッド動作のいくつかは、フェデレーテッド環境内のエンティティ間で情報を交換するために、ユーザのブラウザを介したＨＴＴＰリダイレクションを用いてもよい。しかし、記載される技術はさまざまな通信プロトコルにわたってサポートされてもよく、ＨＴＴＰに基づく通信に限定されることは意味されない。たとえば、フェデレーテッド環境におけるエンティティは、必要なときには直接通信してもよい。すなわち、ユーザのブラウザを通じてメッセージをリダイレクトする必要はない。

フェデレーテッド環境に必要とされるコンポーネントが、既存のシステムと統合されてもよい。図３は、これらのコンポーネントを既存のシステムに対するフロントエンドとして実現するための一実施形態を示す。フェデレーテッド・ドメインにおける既存のコンポーネントは、レガシ・アプリケーションまたはバックエンド処理コンポーネント３３０と考えられてもよく、これは図４に示されるのと類似の態様で認証サービス・ランタイム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ ｒｕｎｔｉｍｅ：ＡＳＲ）サーバ３３２を含む。ＡＳＲサーバ３３２は、保護リソース３３５を生成、検索、または別様にサポートもしくは処理すると考えられ得る、アプリケーション・サーバ３３４へのアクセスをドメインが制御するときに、ユーザを認証する責を負う。ドメインは、アプリケーション・サーバ３３４へのアクセスのためにユーザを登録するためにレガシ・ユーザ登録アプリケーション３３６を使い続けてもよい。レガシ動作に関して登録ユーザを認証するために必要とされる情報は、企業ユーザ・レジストリ３３８に保存される。企業ユーザ・レジストリ３３８もフェデレーション・コンポーネントにアクセス可能であってもよい。

ドメインは、フェデレーテッド環境に加わった後に、フェデレーテッド・コンポーネントの介入なしに動作し続けてもよい。言い換えると、ドメインは、ユーザがポイントオブコンタクト（ｐｏｉｎｔ−ｏｆ−ｃｏｎｔａｃｔ）サーバまたはこのポイントオブコンタクト・サーバ機能を実現する他のコンポーネントを通過することなく特定のアプリケーション・サーバまたはその他の保護リソースに直接アクセスし続けてもよいように構成されてもよい。この態様でシステムにアクセスするユーザは、典型的な認証の流れおよび典型的なアクセスを経験する。しかしこれを行うとき、レガシ・システムに直接アクセスするユーザは、ドメインのポイントオブコンタクト・サーバに知られるフェデレーテッド・セッションを確立することができない。

フェデレーション・フロントエンド処理３４０を用いることによって、ドメインのレガシ機能がフェデレーテッド環境に統合されてもよく、フェデレーション・フロントエンド処理３４０はポイントオブコンタクト・サーバ３４２およびトラスト・プロキシ（ｔｒｕｓｔ ｐｒｏｘｙ）サーバ３４４（またはより簡単に、トラスト・プロキシ３４４もしくはトラスト・サービス３４４）を含み、トラスト・プロキシ３４４自身がセキュリティ・トークン・サービス（Ｓｅｃｕｒｉｔｙ Ｔｏｋｅｎ Ｓｅｒｖｉｃｅ：ＳＴＳ）３４６と対話する。フェデレーション構成アプリケーション３４８は、フェデレーション・インタフェース・ユニット３５０を通じてフェデレーション・フロントエンド構成要素がレガシ・バックエンド構成要素とインタフェースすることを可能にするために、管理ユーザがフェデレーション・フロントエンド構成要素を構成することを可能にする。フェデレーテッド機能は、別個のシステム構成要素またはモジュールにおいて実現されてもよい。典型的に、フェデレーション動作を行うための機能のほとんどは、単一のフェデレーション・アプリケーション内の論理構成要素の集合体によって実現されてもよい。フェデレーテッド・ユーザ・ライフサイクル管理（ｆｅｄｅｒａｔｅｄ ｕｓｅｒ ｌｉｆｅｃｙｃｌｅ ｍａｎａｇｅｍｅｎｔ）アプリケーション３５２は、トラスト・サービス３４４をシングルサインオン・プロトコル・サービス（ｓｉｎｇｌｅ−ｓｉｇｎ−ｏｎ ｐｒｏｔｏｃｏｌ ｓｅｒｖｉｃｅ：ＳＰＳ）３５４とともに含む。トラスト・サービス３４４は、アイデンティティおよび属性サービス（ｉｄｅｎｔｉｔｙ−ａｎｄ−ａｔｔｒｉｂｕｔｅ ｓｅｒｖｉｃｅ：ＩＡＳ）３５６を含んでもよく、これはフェデレーション機能の部分としてのアイデンティティ・マッピングおよび属性検索などを含む動作に対する責を負うサービスである。加えてアイデンティティおよび属性サービス３５６は、シングルサインオン動作の際にシングルサインオン・プロトコル・サービス３５４によって用いられてもよい。特定の状況においては、フェデレーションの特定的な目的でユーザに関する情報を維持するためにフェデレーション・ユーザ・レジストリ３５８が用いられてもよい。

クラウド・コンピューティング・モデル
付加的な背景として、クラウド・コンピューティングとは、サービスのプロバイダによる最小限の管理努力または対話によって迅速に供給および解放され得る構成可能なコンピューティング・リソースの共有プール（例、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシン、およびサービス）への簡便なオンデマンド・ネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特性と、少なくとも３つのサービス・モデルと、少なくとも４つの配備モデルとを含んでもよく、これらはすべて、２００９年１０月７日付のＰｅｔｅｒ ＭｅｌｌおよびＴｉｍ Ｇｒａｎｃｅによる「Ｄｒａｆｔ ＮＩＳＴ Ｗｏｒｋｉｎｇ Ｄｅｆｉｎｉｔｉｏｎ ｏｆ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ」においてより特定的に記載および定義されるとおりである。

特に、以下は典型的な特性である。

オンデマンド・セルフサービス。クラウド消費者は、たとえばサーバ時間およびネットワーク記憶装置などのコンピューティング能力を、サービスのプロバイダと人間との対話を必要とせずに必要に応じて自動的に、一方的に供給できる。

幅広いネットワーク・アクセス。能力はネットワークを通じて入手可能であり、異種のシンまたはシック・クライアント・プラットフォーム（例、携帯電話、ラップトップおよびＰＤＡ）による使用を促進する標準的機構を通じてアクセスされる。

リソース・プーリング。プロバイダのコンピューティング・リソースは、マルチテナント・モデルを用いて複数の消費者に供するためにプールされ、異なる物理リソースおよび仮想リソースは要求に従って動的に割り当ておよび再割り当てされる。一般的に、消費者は提供されたリソースの正確な位置に対する制御または知識を有さないが、より高レベルの抽象化における位置（例、国、州、またはデータセンタ）を指定できてもよいという点で、位置独立性の意味がある。

迅速な弾性。能力は、速やかにスケール・アウトするために迅速かつ弾性的に、場合によっては自動的に供給されてもよく、かつ速やかにスケール・インするために迅速に解放されてもよい。消費者にとって、供給のために利用可能な能力はしばしば無制限に見え、いつでもあらゆる量が購入可能である。

測定サービス。クラウド・システムは、サービスのタイプ（例、記憶、処理、帯域幅、および活動中のユーザ・アカウント）に対して適切な何らかのレベルの抽象化において計測能力を強化することによって、リソースの使用を自動的に制御および最適化する。リソースの使用がモニタされ、制御され、かつ報告されることで、利用されるサービスのプロバイダおよび消費者の両方に対する透明性が提供されてもよい。

サービス・モデルは典型的に以下のとおりである。

サービスとしてのソフトウェア（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ：ＳａａＳ）。消費者に提供される能力は、クラウド・インフラストラクチャにおいて実行中のプロバイダのアプリケーションを用いることである。このアプリケーションは、たとえばウェブ・ブラウザ（例、ウェブベースのｅメール）などのシン・クライアント・インタフェースを通じて、さまざまなクライアント・デバイスからアクセス可能である。消費者は、限定されたユーザ特定的なアプリケーション構成設定はおそらく例外として、ネットワーク、サーバ、オペレーティング・システム、記憶装置、または個々のアプリケーション能力さえも含む基礎的なクラウド・インフラストラクチャを管理も制御もしない。

サービスとしてのプラットフォーム（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ：ＰａａＳ）。消費者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを用いて作成された、消費者が作成または取得したアプリケーションを、クラウド・インフラストラクチャ上に配備することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、または記憶装置を含む基礎的なクラウド・インフラストラクチャを管理も制御もしないが、配備されたアプリケーションおよびおそらくはアプリケーション・ホスティング環境構成に対する制御を有する。

サービスとしてのインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ：ＩａａＳ）。消費者に提供される能力は、消費者がオペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアを配備して実行できる、処理、記憶装置、ネットワーク、およびその他の基本的なコンピューティング・リソースを供給することである。消費者は基礎的なクラウド・インフラストラクチャを管理も制御もしないが、オペレーティング・システム、記憶装置、配備されたアプリケーションに対する制御を有し、おそらくは選択ネットワーキング・コンポーネント（例、ホスト・ファイアウォール）の制限された制御を有する。

配備モデルは典型的に以下のとおりである。

プライベート・クラウド。このクラウド・インフラストラクチャは、ある組織のためにのみ動作される。このクラウド・インフラストラクチャはその組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスで存在してもよい。

コミュニティ・クラウド。このクラウド・インフラストラクチャはいくつかの組織によって共有され、共有事項（例、ミッション、セキュリティ要求、ポリシ、およびコンプライアンスの考慮）を有する特定のコミュニティをサポートする。このクラウド・インフラストラクチャはそれらの組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスで存在してもよい。

パブリック・クラウド。このクラウド・インフラストラクチャは一般市民または大きな産業グループに利用可能にされており、クラウド・サービスを販売する組織に所有されている。

ハイブリッド・クラウド。このクラウド・インフラストラクチャは２つまたはそれ以上のクラウド（プライベート、コミュニティまたはパブリック）の複合体であり、それらのクラウドは一意のエンティティを残しているが、データおよびアプリケーションの移植性を可能にする標準化技術または専有技術（例、クラウド間のロード・バランシングのためのクラウド・バースティング）によってともにバインドされている。

クラウド・コンピューティング環境は、ステートレス性（ｓｔａｔｅｌｅｓｓｎｅｓｓ）、低結合度、モジュラリティ、および意味論的インターオペラビリティに焦点を当てたサービス指向である。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。代表的なクラウド・コンピューティング・ノードは上の図２に示されるとおりである。特に、クラウド・コンピューティング・ノード内には、多数の他の汎用または特定目的のコンピューティング・システム環境または構成とともに動作可能なコンピュータ・システム／サーバが存在する。コンピュータ・システム／サーバとともに用いるために好適であり得る周知のコンピューティング・システム、環境もしくは構成、またはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサに基づくシステム、セット・トップ・ボックス、プログラマブルな家電製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスのいずれかを含む分散クラウド・コンピューティング環境などを含むが、それに限定されない。コンピュータ・システム／サーバは、コンピュータ・システムによって実行される、たとえばプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的状況において説明されてもよい。一般的に、プログラム・モジュールは、特定のタスクを行うか、または特定の抽象データ・タイプを実現するルーチン、プログラム、オブジェクト、コンポーネント、論理、およびデータ構造などを含んでもよい。コンピュータ・システム／サーバは、通信ネットワークによってリンクされたリモート処理デバイスによってタスクが実行される分散クラウド・コンピューティング環境において実行されてもよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモートのコンピュータ・システム記憶媒体の両方に位置してもよい。

ここで図４を参照すると、付加的な背景として、クラウド・コンピューティング環境によって提供される機能抽象（ｆｕｎｃｔｉｏｎａｌ ａｂｓｔｒａｃｔｉｏｎ）層の組が示される。図４に示されるコンポーネント、層および機能は例示であることのみが意図されており、本発明の実施形態はそれに限定されないことが予め理解されるべきである。図示されるとおり、以下の層および対応する機能が提供される。

ハードウェアおよびソフトウェア層４００は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、メインフレーム、一例においてはＩＢＭ（ＩＢＭ社の登録商標）ｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）システムと、ＲＩＳＣ（縮小命令セット・コンピュータ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ））アーキテクチャに基づくサーバ、一例においてはＩＢＭ（ＩＢＭ社の登録商標）ｐＳｅｒｉｅｓ（ＩＢＭ社の登録商標）システムと、ＩＢＭ（ＩＢＭ社の登録商標）ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）システムと、ＩＢＭ（ＩＢＭ社の登録商標）ＢｌａｄｅＣｅｎｔｅｒ（ＩＢＭ社の登録商標）システムと、記憶装置と、ネットワークおよびネットワーキング・コンポーネントとを含む。ソフトウェア・コンポーネントの例は、ネットワーク・アプリケーション・サーバ・ソフトウェア、一例においてはＩＢＭ（ＩＢＭ社の登録商標）ＷｅｂＳｐｈｅｒｅ（ＩＢＭ社の登録商標）アプリケーション・サーバ・ソフトウェアと、データベース・ソフトウェア、一例においてはＩＢＭ（ＩＢＭ社の登録商標）ＤＢ２（ＩＢＭ社の登録商標）データベース・ソフトウェアとを含む。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｐＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅおよびＤＢ２は、世界の多くの管轄権で登録されたインターナショナル・ビジネス・マシーンズ社（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ）の登録商標である。）

仮想化層４０２は、以下の仮想エンティティの例が提供され得る抽象化層を提供する。すなわち、仮想サーバ、仮想記憶装置、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーションおよびオペレーティング・システム、ならびに仮想クライアントである。

一実施例において、管理層４０４は以下に説明される機能を提供してもよい。「リソース・プロビジョニング」は、クラウド・コンピューティング環境内でタスクを行うために用いられるコンピューティング・リソースおよびその他のリソースの動的調達を提供する。「計測および価格付け」は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡と、これらのリソースの消費に対する請求書またはインボイス送付とを提供する。一実施例において、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含んでもよい。「セキュリティ」は、クラウド消費者およびタスクに対するアイデンティティ検証と、データおよびその他のリソースに対する保護とを提供する。「ユーザ・ポータル」は、消費者およびシステム管理者に対するクラウド・コンピューティング環境へのアクセスを提供する。「サービス・レベル管理」は、必要とされるサービス・レベルが満たされるようなクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。「サービス・レベル合意（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ：ＳＬＡ）計画および遂行」は、ＳＬＡに従って将来の要求が予期されるクラウド・コンピューティング・リソースの準備（ｐｒｅ−ａｒｒａｎｇｅｍｅｎｔ）および調達を提供する。

作業負荷層４０６は、クラウド・コンピューティング環境がそれに対して用いられ得る機能の例を提供する。この層から提供され得る作業負荷および機能の例は、マッピングおよびナビゲーションと、ソフトウェア開発およびライフサイクル管理と、仮想教室教育配信と、データ解析処理と、トランザクション処理と、本開示の教示に従うアイデンティティ・プロバイダ・インスタンス・ディスカバリとを含む。

本開示はクラウド・コンピューティングに対する詳細な説明を含むが、本明細書において述べられる教示の実現はクラウド・コンピューティング環境に限定されないことが予め理解される。本発明の実施形態は、現在公知であるか、または後に開発されるあらゆるその他のタイプのコンピューティング環境とともに実現され得る。

よって、代表的なクラウド・コンピューティング環境は、フロントエンド・アイデンティティ・マネージャと、ビジネス支援サービス（ｂｕｓｉｎｅｓｓ ｓｕｐｐｏｒｔ ｓｅｒｖｉｃｅｓ：ＢＳＳ）機能コンポーネントと、動作支援サービス（ｏｐｅｒａｔｉｏｎａｌ ｓｕｐｐｏｒｔ ｓｅｒｖｉｃｅｓ：ＯＳＳ）機能コンポーネントと、コンピュート・クラウド・コンポーネントとを含む、高レベル機能コンポーネントの組を有する。アイデンティティ・マネージャは、要求クライアントとインタフェースしてアイデンティティ管理を提供する責を負い、このコンポーネントは、たとえばニューヨーク州アーモンクのＩＢＭ社より入手可能なＴｉｖｏｌｉ（ＩＢＭ社の登録商標）フェデレーテッド・アイデンティティ・マネージャ（Ｆｅｄｅｒａｔｅｄ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｒ）（ＴＦＩＭ）など、１つまたはそれ以上の公知のシステムによって実現されてもよい。適切な状況において、ＴＦＩＭは他のクラウド・コンポーネントにＦ−ＳＳＯを提供するために用いられてもよい。ビジネス支援サービス・コンポーネントは、たとえば請求支援などの特定の管理機能を提供する。動作支援サービス・コンポーネントは、たとえば仮想マシン（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ：ＶＭ）インスタンスなど、他のクラウド・コンポーネントのプロビジョニングおよび管理を提供するために用いられる。クラウド・コンポーネントとは主要な計算リソースを表し、それは典型的にはクラウドを介したアクセスに対して利用可能にされる目標アプリケーション４１０を実行するために用いられる複数の仮想マシン・インスタンスである。ディレクトリ、ログ、およびその他の作業データを保存するために１つまたはそれ以上のデータベースが用いられる。（フロントエンド・アイデンティティ・マネージャを含む）これらのコンポーネントすべてがクラウド「内」に置かれるが、これは必要条件ではない。代替的実施形態において、アイデンティティ・マネージャはクラウドの外部で動作されてもよい。

アイデンティティ・プロバイダ・インスタンス・ディスカバリ
加えて、アイデンティティ・プロバイダ（ＩｄＰ）インスタンス・ディスカバリ・サービスを提供することが公知であり、これはときには「ＩｄＰＩＤＳ」と呼ばれる。好ましくは、エンド・ユーザがアプリケーションからのサービスを得るためにサービス・プロバイダにアクセスした後に、フェデレーテッド・サービス・プロバイダ（ＳＰ）からＩｄＰＩＤＳが（例、ウェブ・サービス・コールを介して）自動的にアクセスされる。一般的にＩｄＰＩＤＳは、アイデンティティ・プロバイダ・インスタンスを複数のそうしたインスタンスの中から選択する（ｓｅｌｅｃｔ）（または「選ぶ（ｃｈｏｏｓｅ）」）ように動作する。本明細書において用いられる「インスタンス」とは、アイデンティティ・プロバイダによって実行される機能の組を示し、こうした機能は互いの「インスタンス」に複製またはミラーリングされる。よって各アイデンティティ・プロバイダ「インスタンス」は、少なくともエンド・ユーザ・クライアントの対話の処理に関しては、別のこうしたインスタンスと機能的に同等であると考えられてよい。よって、特定のアイデンティティ・プロバイダ・インスタンスは特定の位置、特定の時間、または所与の出現の際に存在してもよい。一般的にＩｄＰＩＤＳは、エンド・ユーザ・クライアントのバインディングを受取るために用いられ得る複数のこうしたインスタンスの中から「最適な」アイデンティティ・プロバイダ・インスタンスを捜し出すように動作するが、この「最適な」という用語は開示される主題を限定するものと取られるべきではない。特定の「インスタンス」は別のこうしたインスタンス「より良い」かもしれないが、何らかの抽象または定義された基準に関して必ずしも「最高」ではない。最低限、ＩｄＰＩＤＳは所与の「選択」基準に基づいて別のこうしたインスタンスよりも所与のＩｄＰインスタンスを選択するように動作する。以下により詳細に説明されるとおり、選択基準はかなり多様であってもよく、それは典型的には以下のうちの１つである。すなわち、コンピューティング・エンティティ（例、エンド・ユーザ・クライアント・マシン、または何らかの他のマシン）とアイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上との間のネットワーク近接、コンピューティング・エンティティとアイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上との間の地理的近接、アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上に関連する負荷、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスの可用性、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する能力（そのＩｄＰインスタンスが要求されるＦ−ＳＳＯプロトコル／方法をサポートするかどうかを限定なしに含む）、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する性能メトリック、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディング、およびＳＰが１つまたはそれ以上の特定のインスタンスとパートナ関係を確立しているかどうかなどである。

以下に、一般的なアイデンティティ・プロバイダ・ディスカバリの基本的問題に対する付加的な背景を提供する。図５において、エンド・ユーザ５００はサービス・プロバイダ５０２からサービスを得ようとしており、かついくつかの別個のアイデンティティ・プロバイダ・オプション、たとえばアイデンティティ・プロバイダ５０４、５０６、５０８および５１０などを有するものと仮定する。この例において、アイデンティティ・プロバイダは互いに提携していない商業的認証サービスである。図５に示されるものなどの公知のディスカバリ・サービス実施は、スタンドアロンの態様で動作するか、またはサービス・プロバイダに直接埋め込まれることによって動作する。高レベルにおいて、ディスカバリ・モデルは以下のとおりに働く。エンド・ユーザ５００はサービス・プロバイダ５０２（本明細書において用いられる「サービス・プロバイダ」および関連するＳＰ「アプリケーション」は同じ意味で用いられることがある）にアクセスし、次いでアイデンティティ・プロバイダを手動で選択する。次いでサービス・プロバイダは、エンド・ユーザを彼または彼女が使用希望する選択されたアイデンティティ・プロバイダに、たとえば「ｗｗｗ．ｙａｈｏｏ．ｃｏｍ」ＩｄＰ５０４などにリダイレクトする。エンド・ユーザはアイデンティティ・プロバイダに対する認証を行い、次いでアイデンティティ・プロバイダは（認証後に）エンド・ユーザを（典型的にＨＴＴＰに基づくリダイレクトによって）リダイレクトしてＳＰ５０２に戻す。加えてＩｄＰ５０４は、たとえばセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）のアサーションまたはトークンなどである、そのフェデレーテッド・ユーザが認証されたという証拠となるアイデンティティ・アサーションをＳＰ５０２に提供する。次いで、プロセスを完了するためにフェデレーテッド・ユーザとＳＰとの間にエンド・ユーザ・セッションが確立される。

図５に示されるアプローチには、アイデンティティ・プロバイダ「インスタンス」は関与していない。なぜなら、各アイデンティティ・プロバイダ５０４、５０６、５０８および５１０が独立して動作するからである。ここで図６を参照すると、複数のＩｄＰインスタンスを有する公知の単一論理ＩｄＰディスカバリ・サービスが提供される。このディスカバリ・サービスはサービス・プロバイダ６０２によってアクセス可能である。この実施形態において、すべてのＩｄＰインスタンス６０４、６０６、６０８および６１０は共通のサイト（ＤＮＳ）名、たとえば「ｉｄｐ．ｘｙｚ．ｃｏｍ」などを共有することが好ましく、各インスタンスは特定の場所（東京、バンガロール、ロンドンおよびニューヨーク）に位置する。グローバル・サービス・ロード・バランシング（ｇｌｏｂａｌ ｓｅｒｖｉｃｅ ｌｏａｄ ｂａｌａｎｃｉｎｇ：ＧＳＬＢ）機構６０５は、エンド・ユーザ６００を特定のＩｄＰインスタンスにルーティングする。アプローチの１つにおいて、ルーティングは従来のＯＳＩモデルの他の層で行われてもよいが、ＧＳＬＢはＤＮＳに基づくものである。よって、代替的アプローチにおいては、どのインスタンスが選択されるかを定めるために、ＢＧＰに基づくルーティング基準が用いられてもよい。より高度なＧＳＬＢに基づくアプローチは、より細粒度のサイト選択基準を可能にするアドバイザ・コンポーネントを含んでもよい。

図７は、ある実施形態における企業内ＩｄＰディスカバリ技術を説明するものであり、ここで企業は複数のＩｄＰインスタンスを有し、かつフェデレーテッド・サービス・プロバイダとして実現される複数のアプリケーションをサポートしている。本実施形態においては、図６と同様に複数のアイデンティティ・プロバイダ・インスタンス７０４、７０６、７０８および７１０が存在し、それらは例示の目的だけのために、たとえば東京、バンガロール、ロンドンおよびニューヨークなどの別個の地理的場所に位置している。ＩｄＰインスタンスを選択するためにＧＳＬＢに基づくルーティング機構が用いられる図６とは異なり、ここではアイデンティティ・プロバイダ・ディスカバリがそれ自体「サービス」として実行または実現される。このディスカバリ方法は、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービス、すなわち「ＩｄＰＩＤＳ」によって提供される。このシナリオにおいて、エンド・ユーザ７００はサービス・プロバイダ７０２に要求を送り、この要求は自動的に（またはプログラムによって）ＩｄＰＩＤＳサービス７０５を呼び出し、次いでＩｄＰＩＤＳサービス７０５を用いてインスタンス７０４、７０６、７０８および７１０の中からＩｄＰインスタンスが選択され、各々のインスタンスは一意のサブドメイン［都市名］．ｉｄｐ．ｘｙｚ．ｃｏｍによって識別される。図７にさらに示されるとおり、１つまたはそれ以上の他のサービス・プロバイダ、たとえばＳＰ７１２などもＩｄＰＩＤＳサービス７０５を使用する。ＩｄＰＩＤＳサービスは、各ＩｄＰに対するユーザの（ネットワークまたは地理的）近接、ＩｄＰの負荷または可用性、ＩｄＰの能力、既存のＩｄＰバインディング、またはその何らかの組み合わせを限定なしに含む１つまたはそれ以上の基準に基づいて、所与のＩｄＰインスタンスを選択する。好ましくは、このサービスは、所与のインスタンスを選択するプロセスにおいて、エンド・ユーザの直接の関与を必要とせずに選択を行う（ただし、エンド・ユーザは最初にアイデンティティ・プロバイダ・サービスを選択するときには関与してもよい）。

図８は、ＩｄＰインスタンス・ディスカバリ・プロセスをより詳細に示す。この実施例において、エンド・ユーザ８００は、好ましくはＳＳＬまたはＴＬＳなどを介してサービス・プロバイダ８０２への接続を確立している。ステップ（１）において、クライアント・ブラウザは、たとえば「ｈｔｔｐｓ：／／ｗｗｗ．ｘｙｚ．ｃｏｍ／ａｐｐｌｉｃａｔｉｏｎ／」などの要求をサービス・プロバイダ８０２に送る。ステップ（２）において、サービス・プロバイダ８０２はＩｄＰＩＤＳサービス８０５にＩｄＰインスタンスに対するウェブ・サービス要求を送る。ステップ（３）において、ＩｄＰＩＤＳはインスタンス８０４、８０６、８０８および８１０の中からＩｄＰインスタンスを選択する。本実施例において、ＩｄＰＩＤＳ８０５はロンドンのインスタンスを選択する。よってステップ（４）において、ＩｄＰＩＤＳ８０５はステップ（２）で送られた要求に対する応答を戻す。典型的に、この応答はＵＲＬであり、これはステップ（５）においてリダイレクト目標としてＳＰからクライアント・ブラウザに戻される。ステップ（６）において、ブラウザは選択されたＩｄＰインスタンスに、この場合にはロンドン・インスタンス８０８にリダイレクトされ、ロンドンＩｄＰインスタンスに対する認証が要求される。ユーザが公知の態様で認証された後、ステップ（７）において、ロンドンに基づくＩｄＰインスタンス８０８はエンド・ユーザ・ブラウザにリダイレクトを発行し、このリダイレクトによってクライアント・ブラウザはサービス・プロバイダ８０２に戻される。これがステップ（８）である。サービス・プロバイダ８０２は、選択されたＩｄＰインスタンスとの信頼関係を有する（図３に関して上述したとおり）。しかし、ＳＰは各ＩｄＰインスタンスとの信頼関係を有しても有しなくてもよい。すなわち、適切な状況においては、上述のとおり、こうした関係の存在（またはその不在）は使用される選択基準の中にあってもよい。ユーザの認証されたアイデンティティは、ＳＡＭＬまたはＯｐｅｎＩＤなどを含むさまざまな公知の機構を用いて実現されてもよいこのフェデレーテッド信頼関係８１２を通じて、ＩｄＰインスタンス８０８からサービス・プロバイダ８０２に送られる。これによって処理が完了する。

よってこの実施形態に従うと、エンド・ユーザ（クライアント）がアプリケーション（サービス・プロバイダ）にアクセスするとき、サービス・プロバイダはＩｄＰＩＤＳに要求を送り、ＩｄＰＩＤＳにクライアントのＩＰアドレスまたはその他の関連情報（例、アプリケーション識別子、前のＩｄＰバインディングを示すクッキーなど）を送る。サービスとして、ＩｄＰＩＤＳは１つまたはそれ以上の技術によって適切なＩｄＰインスタンスを決定し、サービス・プロバイダへの応答に戻す。次いでサービス・プロバイダは、典型的にはＨＴＴＰリダイレクトを通じてクライアントをＩｄＰにリダイレクトする。このリダイレクションは、使用される特定のＦ−ＳＳＯプロトコル／バインディングおよびローカル構成のあらゆる要求に依存して、ＩｄＰまたはＳＰの開始したＦ−ＳＳＯのエンドポイントを適切に伴ってもよい。ＩｄＰは通常の態様でクライアントを認証し、次いでユーザを再びサービス・プロバイダに（もう１度ＨＴＴＰ３０２を介して）リダイレクトする。（選択されたＩｄＰインスタンスによって生成された）ユーザの認証アイデンティティは、フェデレーテッド信頼関係を介してサービス・プロバイダに送られる。この態様で、選択されたＦ−ＳＳＯプロトコル／バインディングが用いられて適切なアイデンティティ情報がＳＰに送られ、最終的にユーザは最初に要求したサービスにリダイレクトされる。

上述のとおり、ＩｄＰＩＤＳは適切なインスタンスを定めるためにさまざまな手段を実現してもよい。たとえば、クライアントＩＰアドレスに基づいて、ＩｄＰＩＤＳはＩｄＰインスタンスに対する近接（ｃｌｏｓｅ）（または最適）ネットワーク近接（ｐｒｏｘｉｍｉｔｙ）に基づいて選択を行ってもよい。ネットワーク近接は、待ち時間、ラウンドトリップ・タイム（ｒｏｕｎｄ−ｔｒｉｐ ｔｉｍｅ：ＲＴＴ）、自律システム（ａｕｔｏｎｏｍｏｕｓ ｓｙｓｔｅｍ：ＡＳ）のホップ数、パケット損失、またはその何らかの組み合わせによって定められてもよい。ネットワーク近接の代わりに、地理的近接に基づいて決定が行われてもよく、この場合には「最も近い」データ・センタが選択されてもよい。このプロセスの際に、ＩＰ範囲マッピングまたはＩＰ対国／地理的マッピングが用いられてもよい。選択基準は、ネットワークおよび地理的場所の両方の所与の関数であってもよい。または選択プロセスは、特定のＩｄＰインスタンスがどれほど「ビジー」（負荷がかかっている）か、もしくは特定の要求の時間にそのＩｄＰインスタンスが利用可能かどうかに基づいていてもよい。その目的のために、好ましくは各ＩｄＰインスタンスがＩｄＰＩＤＳサービスと通信しており、好適な要求−応答プロトコルを用いて状態および負荷データがＩｄＰインスタンスからサービスに移送される。一般化すると、典型的に各ＩｄＰインスタンスの状態をすべてのＩｄＰＩＤＳインスタンスが知っており（または知ることができ）、これはたとえば、特定のＩｄＰコンポーネントまたは従属エンティティに関するデータを潜在的に含む、ＩｄＰインスタンスの「健康状態（ｈｅａｌｔｈ）」または可用性を示すデータをＩｄＰＩＤＳインスタンスに直接通知または提供するモニタリング能力を用いることなどのさまざまな手段によって達成されてもよい。負荷データは、ＣＰＵ負荷または記憶負荷などを限定なしに含んでもよい。インスタンス負荷が考慮されるとき、サービスは、要求時にどのインスタンスの負荷が最も小さいかという機能としてインスタンス選択を行ってもよい。代替的に、インスタンス選択は、ネットワークもしくは地理的場所またはその両方と、負荷との組み合わせに基づいてもよい。よってたとえば、特定のＩｄＰインスタンスは別のＩｄＰインスタンスよりも（ネットワークにおいて）近いが、より負荷が大きいかもしれず、その場合にＩｄＰは（ネットワークにおいて）遠く離れたより負荷が小さいＩｄＰインスタンスの方を選択してもよい。

選択基準は他の要素に基づいていてもよい。たとえば、アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上（すなわち、より一般的には部分集合）は、すべてのインスタンスが共有していない特定の能力を有することがある。こうした場合、ＩｄＰＩＤＳは、インスタンスのうち所望の能力を有する１つ（または、その能力を共有するものが複数あるときは、最も近いかもしくは最も負荷が小さいインスタンスであってもよい）に要求を向ける。一般的にこの選択は、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する何らかの他の性能メトリックに基づいていてもよい。またはその選択は、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディングを利用してもよい。そのバインディングは、たとえばクッキーなどのあらゆる公知の態様で捕捉されてもよい。

場所、負荷、能力または可用性に加えて、選択はラウンドロビン機構に基づいていてもよい。

アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスがインスタンス選択を行うさまざまな技術についての上記の説明は、単なる代表的なものである。これらの基準の１つまたはそれ以上が互いに組み合わされて用いられてもよく、サービスはこれらの技術を特定の状況において（例、特定の日、特定の時間、異なる負荷条件下など）のみ用いてもよく、サービスはデフォルトによって、または特定のサービス・プロバイダ（のみ）とともに、または特定のタイプのフェデレーテッド・エンド・ユーザに対してなどの条件で、１つまたはその他の技術を用いてもよい。こうした変形はすべて、本明細書において実現されるディスカバリ機構および方法の範囲内にあるものとみなされる。

ＩｄＰＩＤＳは、図４に表されるものなどのクラウド・サービスとして実現されてもよい。

スケーリングもしくは性能またはその両方、および可用性のために、ＩｄＰＩＤＳ自身が複数の配信サイトに複数のクラスタ化されたインスタンスを有してもよい。「クラスタ化された（ｃｌｕｓｔｅｒｅｄ）」ＩｄＰＩＤＳサービス実施形態は、複数のフェデレーテッド・アプリケーションに対する高度にスケーラブルでありかつ可用性の高いアイデンティティ・プロバイダ「バックエンド」ディスカバリ・サービスを提供する。このアプローチにおいて、（ユーザと直接対話する典型的なフロントエンド・サービスとは反対に）バックエンド・サービスはアプリケーション要求によって駆動される。ＩｄＰインスタンスは編成されて「クラスタ」となり、各クラスタは所与の場所に位置し、クラスタ内の各インスタンスはそのクラスタ内のその他すべてのインスタンスと「同じ場所に位置する（ｃｏ−ｌｏｃａｔｅｄ）」。各「クラスタ」自身が独自のＩｄＰＩＤＳサービスを実行する。すなわち、ＩｄＰＩＤＳ自体が各クラスタの場所に「複製」または「ミラーリング」される。一般的に、特定のクラスタにおけるＩｄＰＩＤＳサービス・インスタンスが同じ場所に位置するインスタンス自体の中から「インスタンス」選択を行うか、またはＩｄＰＩＤＳは別のサイトに位置する別のＩｄＰＩＤＳサービス（すなわち別のクラスタ）に要求を向けてもよい。よってユーザは、以下の複数の理由の１つによって、異なる配信サイトのアイデンティティ・プロバイダに向けられてもよい。すなわち、その時のローカルＩｄＰＩＤＳが利用不可能もしくは過負荷であるとき、その他のロード・バランシングの目的があるとき、またはそのローカルＩｄＰＩＤＳがアプリケーションの要求する特定の能力を提供しないときである。加えてこのクラスタ化アプローチは、バックエンド・サービスを使用しているフェデレーテッド・アプリケーションに対する全Ｆ−ＳＳＯ能力を保持しながら、ローカルＩｄＰインスタンス（またはこうしたインスタンスのクラスタ）をメンテナンスのために取外すことを可能にするために有利である。

ＩｄＰＩＤＳによって戻される特定の要求への応答は、フェデレーションに特定的なＵＲＬを含んでもよい。

グローバル・サービス・ロード・バランシング（ＧＳＬＢ）機構を用いて、特定のＩｄＰインスタンスを仮想化してもよい。

ディスカバリ・サービス・プロキシ − パブリッシュ−サブスクライブによるＩｄＰインスタンス・ディスカバリ
上述を背景として、本開示の技術を説明する。

本アプローチにおいて、「ディスカバリ・サービス・プロキシ」はＦ−ＳＳＯクラウド型環境内に統合されており、たとえば上述のＩｄＰＩＤＳ実施形態のいずれかなど、外部のアイデンティティ・プロバイダ（ＩｄＰ）インスタンス・ディスカバリ・サービスと対話する。一般的に、プロキシはＩｄＰインスタンス要求をディスカバリ・サービスにプロキシし、ＩｄＰインスタンス割り当ておよびおそらくはその他のデータ（たとえばインスタンス状態など）を含む応答を受取る。プロキシはインスタンス割り当て（単数または複数）のキャッシュ（ローカル・キャッシュと呼ばれることもある）を維持する。新たなインスタンス要求を受取るときには、これらの要求をディスカバリ・サービスにプロキシする代わりに、キャッシュされた割り当てデータ（以下に説明されるとおり、もし現行であれば）を用いて適切な応答を提供する。ＩｄＰＩＤＳは典型的にＦ−ＳＳＯ環境から離れた位置にあるため、ローカルにキャッシュされたインスタンス割り当てデータを使用することによって、要求されるＩｄＰインスタンスを識別するために必要な時間を削減する。本開示に従うと、プロキシは、ディスカバリ・サービスからの更新をサブスクライブすることによって、自身のキャッシュを動的に維持および管理する。その更新は、ＩｄＰサービスを含む地理的に分散されたインスタンスの組（またはインスタンス・クラスタ）において起こるか、またはそれに関連して起こるＩｄＰインスタンスの変化（たとえばサーバがメンテナンスのためにオフラインにされること、新たなサービスが追加されること、およびバックエンド・ネットワークの停電など）を識別するものである。好ましくは、更新はパブリケーション−サブスクリプション・モデルを介してＩｄＰＩＤＳからプロキシに提供される。この態様で、プロキシは変更通知をプロアクティブに（かつインスタンス要求に関して非同期的に）受取る。プロキシはこの情報を用いて自身のローカル・キャッシュを更新することにより、インスタンス割り当てがＩｄＰインスタンス（またはインスタンス・クラスタ）の当時存在する真のバックエンド状態を反映する現行のものとなるようにする。

典型的に説明されたものなどのディスカバリ・サービス・プロキシは、たとえば図２に示して上述したものなどのように、ハードウェアおよびソフトウェアにおいて実現される。プロキシは、インスタンス割り当てデータを維持するキャッシュ（またはより一般的にはデータ記憶装置）を含む（または自身に関連させる）。プロキシにおける１つまたはそれ以上の制御ルーチンを用いて、キャッシュのさまざまな機能、すなわちキャッシュの初期化、初期インスタンス割り当てデータのキャッシュへの格納、インスタンス割り当て要求の受取りおよびキャッシュされた割り当てデータを用いたそれへの応答、ならびに（好ましくはｐｕｂ−ｓｕｂサブスクリプション・モデルを介した）リモート・ディスカバリ・サービスからの変更通知の受取りおよびキャッシュの適切な更新が提供される。これらの機能について、以下により詳細に説明する。

図９は、Ｆ−ＳＳＯ認証およびクラウド内でサポートされる１つまたはそれ以上のビジネス・アプリケーションへのアクセスを実現するクラウド型の実施形態の状況におけるディスカバリ・サービス・プロキシの実現を示す。一般的に、以下に説明されるとおり、ディスカバリ・サービス・プロキシは、特定のＩｄＰインスタンス要求に対してサービスするために用いられるべき適切なＩｄＰインスタンスの決定のための（典型的にリモートの）ディスカバリ・サービスに対するインタフェースを提供するために用いられる。

一般的に上述されるとおり、クラウド環境９００は、典型的にフロントエンド・アイデンティティ・マネージャと、ビジネス支援サービス（ＢＳＳ）機能コンポーネントと、動作支援サービス（ＯＳＳ）機能コンポーネント（図示せず）と、コンピュート・クラウド・コンポーネントとを含む高レベル機能コンポーネントの組を含む。説明の目的のために簡略化された図９に示されるとおり、ベース・アクセス・マネージャ９０２は、ＩＢＭ（ＩＢＭ社の登録商標）より商業的に入手可能なＴｉｖｏｌｉ（ＩＢＭ社の登録商標）Ａｃｃｅｓｓ Ｍａｎａｇｅｒ ｆｏｒ ｅ−ｂｕｓｉｎｅｓｓ（ＴＡＭｅｂ）製品を介して実現される。Ｆ−ＳＳＯサポートは、ＩＢＭ（ＩＢＭ社の登録商標）より入手可能なＴｉｖｏｌｉ（ＩＢＭ社の登録商標）フェデレーテッド・アイデンティティ・マネージャ（ＴＦＩＭ）によって実現され得るプロトコル・サービス・モジュール９０４によって提供される。プロトコル・サービス・モジュール９０４は、セキュリティ・トークンの発行、交換および確認のための付加的な拡張を定めるためにウェブ・サービス・トラスト（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｔｒｕｓｔ：ＷＳ−Ｔｒｕｓｔ）の安全なメッセージ通信機構を実現する、関連するセキュリティ・トークン・サービス（ｓｅｃｕｒｉｔｙ ｔｏｋｅｎ ｓｅｒｖｉｃｅ：ＳＴＳ）９０６を含む。ＷＳ−Ｔｒｕｓｔプロトコルは、ウェブ・サービス・クライアントが、特定のセキュリティ・トークンが互いに交換される何らかの信頼のある権限を要求することを可能にする。典型的にはＴＡＭコンポーネントである、高性能のマルチスレッド・ウェブ・サーバ９０８（図面ではＷｅｂＳＥＡＬと称する）がアイデンティティ・マネージャへのアクセスを管理する。前述のとおり、ビジネス支援サービス（ＢＳＳ）コンポーネント９１０は、環境に対する管理機能を提供する。この実施例において、１つまたはそれ以上のビジネス・アプリケーション（単数または複数）９１２は、複数の仮想マシン・インスタンス（図示せず）において実行される。顧客の外部データはＬＤＡＰディレクトリ９１４においてサポートされる。顧客の環境９１６は、ポイントオブコンタクト９１８（ＷｅｂＳＥＡＬなど）およびＬＤＡＰディレクトリ９１８を含む。クライアント・アクセスは、ウェブ・ブラウザ９２０を介して提供されるか、または「リッチ」クライアント、すなわち直接アクセス・クライアントをサポートするマシンを介して提供される。その他の一般的な管理プラットフォーム・コンポーネント、データベースおよびサービスは、公知の態様で提供される。もちろん、クラウド・コンピュート・インフラストラクチャの特定の詳細は限定となることは意図されない。

図９において、クラウド・コンピュート環境内にディスカバリ・サービス・プロキシ９２２が位置し、それはウェブ・サービス・クライアント（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｃｌｉｅｎｔ：ＷＳ−Ｃ）９２４を含む。代替的に、ＷＳ−Ｃ９２４は、ＷｅｂＳＥＡＬプロキシ９０８内、またはＴＦＩＭ ＳＳＯプロトコル・サービス・モジュール９０４内、または何らかの他のコンポーネント内に埋め込まれてもよい。ＷＳ−Ｃ９２４は、使用されるべき適切なアイデンティティ・プロバイダ・インスタンスのアイデンティティ（ＵＲＬ）を検索するためにリモート・アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービス（ＩｄＰＩＤＳ）９２６を呼び出す。上述したとおり、（ＩｄＰＩＤＳによる）この決定は、たとえばディスカバリ・サービス・プロキシの現在位置、意図されるＩｄＰ、Ｆ−ＳＳＯを要求しているアプリケーション、ならびに、たとえば負荷およびネットワーク状態など、ＩｄＰＩＤＳに既知である「バックエンド」情報を限定なしに含むその他の情報などのいくつかの要素に基づいてもよい。

ＩｄＰＩＤＳサービス自体が利用できなくなっても動作できる環境を含む、より高性能の環境をサポートするために、ディスカバリ・サービス・プロキシ９２２はインスタンス割り当てのキャッシュ９２８を維持する。上記のとおり、プロキシはさらに、自身のローカル・キャッシュを動的に維持および管理するために更新サービスを実行する。この動作について説明する。

図１０は、本技術の好ましい動作を示す。本実施例において、ディスカバリ・サービス・プロキシ１０００は、関連するＷＳ−Ｃ１００２を用いてリモートＩｄＰＩＤＳ１００４と通信する。この対話は、たとえばＲＥＳＴ、ＳＯＡＰ、ＨＴＴＰ、ＴＬＳ（トランスポート層セキュリティ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ））上のＨＴＴＰなど、またはその何らかの組み合わせなどのあらゆる好適なプロトコルを通じて行われてもよい。ディスカバリ・サービス・プロキシ１０００はさらに、以下に説明されるとおり、ディスカバリ・サービスによってパブリッシュされる変更通知をサブスクライブする。この動作シナリオにおいて、ディスカバリ・サービス・プロキシ１０００は、ＩｄＰインスタンスに対する要求を受取るときに（インスタンス・ディスカバリ・サービス１００４に対する）一連の初期集団要求（ｉｎｉｔｉａｌ ｐｏｐｕｌａｔｉｏｎ ｒｅｑｕｅｓｔｓ）を行う。これらの要求は、たとえばこの例においては「ｗｗｗ．ｃｌｏｕｄ−ｉｂｍ．ｃｏｍ」などの特定のホスト名に関連している。好ましくは、ＩｄＰインスタンス要求は、目標ＵＲＬ（「ｗｗｗ．ｃｌｏｕｄ−ｉｂｍ．ｃｏｍ」）、ローカルＩＰアドレス（例、フロントエンド・ウェブ・サーバ１００６の９．ｘ．ｘ．ｘ）、およびＦ−ＳＳＯを要求するアプリケーション（ウェブ・サーバ１００６がＦ−ＳＳＯを仲介しているＵＲＬ）などによって区別される。よってＩｄＰ要求データは、こうした情報の１つまたは組み合わせを含んでもよい。図１０を参照して、ステップ（１）はＷＳ−Ｃがホスト名に関するＩｄＰインスタンスの要求を発行することを示し、ステップ（２）はディスカバリ・サービスが、その特定の要求に対してサービスするために用いられるべきであるとそれ（サービス）が判断したＩｄＰインスタンスを提供することを示す。インスタンス・ディスカバリ・サービス１００４によってこれらの初期集団要求（単数または複数）がサービスされるときに、ディスカバリ・サービス・プロキシはＩｄＰ割り当てを受取る。すなわち、割り当ては「要求データ」を「ＩｄＰインスタンス」に関連付ける。ステップ（３）において、プロキシは自身のローカル・キャッシュにインスタンス割り当てデータを格納し、このデータはたとえばタイムスタンプなどの他の情報を含んでもよい。キャッシュのデータ記憶、ルックアップおよび検索は、ＩｄＰ要求のあらゆる情報に基づいてもよい。新たなクラスの要求が来るときに、プロキシは自身のローカル・キャッシュに意図される宛先（ＵＲＬ／ＩＰアドレス）を格納する。図１０には示されないが、プロキシにおいて繰り返し要求が受取られるとき、ディスカバリ・サービス・プロキシはキャッシュへのルックアップを行い、既存の情報がまだ現行であればそれを再使用する。よって、特定の割り当てデータはキャッシュ内での生存時間（ｔｉｍｅ−ｔｏ−ｌｉｖｅ：ＴＴＬ）を有してもよい。すなわち、プロキシに新たな（繰り返し）要求が受取られるときに、プロキシはそれがホスト名（または他の要求データ）に対する現行割り当てデータを有するかどうかを定めるためのチェックを行う。もしそうであれば、キャッシュはその要求をリモート・ディスカバリ・サービスにプロキシする代わりに、保存された割り当てデータを再使用する。

上記のとおり、プロキシ１０００はさらにインスタンス・ディスカバリ・サービスによってパブリッシュされる変更通知をサブスクライブすることによって、サービス全体の性能、信頼性および可用性の付加的な向上を提供する。この目的のために、ディスカバリ・サービスは変更通知サービスを提供し、ディスカバリ・サービス・プロキシはその変更通知サービスをサブスクライブする。サブスクリプション−通知機構は、１対１または１対多数の態様で動作してもよい。よって、ディスカバリ・サービス通知サービスは、複数のプロキシが入手可能である更新をパブリッシュしてもよい。特定のサブスクリプション−通知機構は、実施によってあらゆる簡便なタイプのものであってもよい。例示的実施形態においては、ＷＳ通知（ＷＳ−Ｎｏｔｉｆｉｃａｔｉｏｎ）によって指定されるサブスクリプション−通知機構が用いられてもよい。ＷＳ通知は、トピックに基づくパブリッシュ／サブスクライブ・メッセージ通信パターンを用いたウェブ・サービス通信に対するオープン規格を提供するものである。特定のＷＳ通知はＩｄＰＩＤＳ実現の詳細によって変わるが、例示的実施形態の１つにおいて、通知サービスはＩＢＭ（ＩＢＭ社の登録商標）ＷｅｂＳｐｈｅｒｅ（ＩＢＭ社の登録商標）アプリケーション・サーバＶ７．０を用いて実現されてもよく、これはバージョン７．０ＷＳ通知として公知である、ＸＭＬに基づくウェブ・サービスに対するＪａｖａ（商標）ＡＰＩ（Ｊａｖａ ＡＰＩ ｆｏｒ ＸＭＬ−ｂａｓｅｄ Ｗｅｂ Ｓｅｒｖｉｃｅｓ）（ＪＡＸ−ＷＳ）に基づくＷＳ通知を実現する。

代替的に、ＯＧＳＩ（オープン・グリッド・サービス・インフラストラクチャ（Ｏｐｅｎ Ｇｒｉｄ Ｓｅｒｖｉｃｅｓ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ））において指定されるサブスクリプション−通知機構が用いられてもよい。この目的のために用いられ得るその他のパブリッシュ−サブスクライブ（ｐｕｂ−ｓｕｂ）機構は、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）（登録商標）より入手可能なＷＳＰを限定なしに含む。

一般化すると、図１１に示されるとおり、通知サービスはＩｄＰＩＤＳにおいて実行する通知生産者コンポーネントと、プロキシ（またはそれに関連するＷＳ−Ｃ）において実行する通知消費者コンポーネントとを含む。こうしたコンポーネントの各々は、ソフトウェアにおいて実現され、コンピュータ・プログラム命令の組としてコンピュータ・メモリに保存され、特定化マシンまたは専用マシンとしての１つまたはそれ以上のプロセッサによって実行される。適切なウェブベース・インタフェースまたはプログラマティック・インタフェースを用いて、１つまたはそれ以上の「サブスクリプション」が生成される。サブスクリプションとは、通知消費者コンポーネント、通知生産者コンポーネント、トピック、ならびにさまざまなその他のフィルタ表現、ポリシおよびコンテキスト情報の間の関係を表すＷＳリソースである。サブスクライバとは、通知生産者コンポーネントにサブスクライブ要求メッセージを送るサービス・リクエスタとして働くエンティティ（この場合はプロキシまたはＷＳ−Ｃ）である。サブスクライバは通知消費者コンポーネントとは異なっていてもよい。付加的な規模を有する通知サービスを生成するために、ＷＳ通知仕様に一致する公知の態様で、サブスクリプション・マネージャもしくはサブスクリプション・ブローカ・コンポーネントまたはその両方が実現されてもよい。

このタイプのｐｕｂ−ｓｕｂモデルを用いて、本開示のディスカバリ・サービス・プロキシはディスカバリ・サービスからの更新をサブスクライブする。これによってサービス・プロキシは、ＩｄＰインスタンス・ディスカバリ・サービスを含むリソース（例、ネットワーク、サーバ・クラスタ、サーバ、およびサービスなど）の変更に関する通知を受取ることができる。この通知はかなり多様であってもよく、あらゆるフォーマットで提供されてもよい。すなわち、ＷＳ通知仕様の意味におけるあらゆるトピックが実現されてもよい。通知は、一般的なディスカバリ・サービスおよびディスカバリ・サービスの特定のリソースに関する最新情報および時間情報をサービス・プロキシに提供する。よって、通知は限定なしにあらゆる性質およびタイプのものであってもよい。通知は粗粒度（例、「ディスカバリ・サービスは生きている」）または細粒度（例、「位置Ａのディスカバリ・サービス・クラスタ・インスタンスは現在メンテナンスのため休止中である」）などであってもよく、かつ通知は定期的（毎時、毎分もしくは秒ごと）または非同期的（特定の事象が発生した際）に提供されても、その何らかの組み合わせで提供されてもよい。通知は、たとえば「［リソース名］は現在７５％の負荷」、「［リソース名］応答時間＞２ｍｓ」など、リソースに特定的なものであってもよい。加えて、通知はディスカバリを容易にするためにプロキシによって使用され得る情報を提供してもよく、その例は「属性サービスは利用不可能、属性を必要とするすべての要求はＸにルーティングされるべきである」などである。後者の例においては、次いで戻された基準に基づいてＩｄＰインスタンスが選択されてもよい。もちろん、これらの例はすべて単なる例示の目的のためのものであって、限定するものと考えられるべきではない。

典型的に、サブスクリプションは、特定のホスト名またはディスカバリ・サービス内のその他の識別可能なリソースに関連付けられる。通知サービスは、好ましくはＩｄＰＩＤＳプロバイダによって構成可能であるか、またはサービス・プロキシ自身に関連して構成可能である。よって一実施において、サービス・プロキシは、そこで通知が構成され得る１つまたはそれ以上のディスプレイ画面を含むウェブ・インタフェースをエクスポートする。

再び図１０を参照して、ステップ（４）はディスカバリ・サービス・プロキシがＩｄＰインスタンス「ｗｗｗ．ｃｌｏｕｄ−ｉｂｍ．ｃｏｍ」に対する更新をサブスクライブすることを示し、ステップ（５）はディスカバリ・サービスがこのインスタンスに対する更新をパブリッシュすることを示す。プロキシが更新を受取るとき、プロキシは（ポリシまたはその他のビジネス論理に基づいて）自身のインスタンス割り当てデータのキャッシュを更新するかどうか、およびどのように更新するかを判断する。特定のポリシまたはビジネス論理はかなり多様であってもよいが、典型的に更新の受取りは１つまたはそれ以上のキャッシュ無効化規則を実施する。よってたとえば、時間ｔにおける前のインスタンス要求に対してサービスするためにディスカバリ・サービスにおけるサーバ１．２．３．４が用いられていたとき、キャッシュはたとえばｗｗｗ．ｃｌｏｕｄ−ｉｂｍ．ｃｏｍ→サーバ１．２．３．４｛時間ｔ｝などのエントリを保存してもよい。サーバ１．２．３．４がメンテナンスのために終了されることを示す更新を受取るとき、キャッシュは次いでこのキャッシュ・エントリを（例、フラッシュすることによって）無効化するか、または別様でこの関連付けを何らかの他の割り当てに変更してもよい。この態様で、プロキシがそのホスト名に対する新たな（繰り返し）要求を受取るときに、より最新の（または「現行の」）割り当てが要求クライアントに提供されてもよい。ディスカバリ・サービス更新に基づいてキャッシュを更新することによって、プロキシはバックエンドＩｄＰインスタンスに関する情報を動的に維持および管理する。これによってプロキシは自身のローカル・キャッシュからインスタンス要求に信頼性高く、かつスケーラブルな態様でサービスすることができ、それによって（典型的にはリモートの）ディスカバリ・サービスによってサービスされる必要がある要求をオフロード（ｏｆｆ−ｌｏａｄｉｎｇ）できる。

一般化すると、通知サービスはＩｄＰＩＤＳにおいて実行する通知生産者コンポーネントと、プロキシ（またはそれに関連するＷＳ−Ｃ）において実行する通知消費者コンポーネントとを含む。こうしたコンポーネントの各々は、ソフトウェアにおいて実現され、コンピュータ・プログラム命令の組としてコンピュータ・メモリに保存され、特定化マシンまたは専用マシンとしての１つまたはそれ以上のプロセッサによって実行される。適切なウェブベース・インタフェースまたはプログラマティック・インタフェースを用いて、１つまたはそれ以上の「サブスクリプション」が生成される。サブスクリプションとは、通知消費者コンポーネント、通知生産者コンポーネント、トピック、ならびにさまざまなその他のフィルタ表現、ポリシおよびコンテキスト情報の間の関係を表すＷＳリソースである。付加的な規模を有する通知サービスを生成するために、ＷＳ通知仕様に一致する公知の態様で、サブスクリプション・マネージャもしくはサブスクリプション・ブローカ・コンポーネントまたはその両方が実現されてもよい。

説明してきたとおり、上述の技術は多数の利点を提供する。プロキシはインスタンス・ディスカバリをオフロードする。それによって、Ｆ−ＳＳＯ動作をクラウド環境内で安全かつ効率的に実施することができる。さらに、パブリッシュ−サブスクライブ・モデルはプロキシとディスカバリ・サービスとの間の変更通知サービスを容易にすることによって、プロキシの割り当てデータのキャッシュがディスカバリ・サービスが利用可能なリソースの実際の状態を反映する現行のものであることを確実にすることによって、プロキシの動作を向上させる。このアプローチは、バックエンド・リソースに関する可用性の問題（例、ＩｄＰインスタンスがオフラインにされること、過負荷であること、または別様で利用不可能であること）についてディスカバリ・サービス・プロキシが知ることを確実にする。よってプロキシは、自身のキャッシュの現行割り当てデータを用いて要求に応答してもよいし、もし要求が（例、キャッシュ・ミスまたは別様のために）サービスに向けて前進する必要があれば、その要求は続く。プロキシのローカル・キャッシュをこの態様で動的に維持および管理することによって、必要とされるＩｄＰインスタンスを識別するための時間が最小化される。加えて、キャッシュにおいてインスタンス要求に応答することによって、サービスにおける負荷が最小化される。サービスに対する要求が必要なとき、通知サービスはこうした要求が活動中のリソースに向けられることを確実にする。その結果、より可用性が高く、信頼性が高く、かつ高度にスケーラブルなディスカバリ・サービスが得られる。

上述の機能は、たとえばプロセッサによって実行されるソフトウェアに基づく機能などのスタンドアロン・アプローチとして実現されてもよいし、（ＳＯＡＰ／ＸＭＬインタフェースを介したウェブ・サービスを含む）管理されたサービスとして利用可能であってもよい。本明細書に記載される特定のハードウェアおよびソフトウェア実施の詳細は単なる例示の目的のためのものであって、記載される主題の範囲を限定することは意味されない。

より一般的に、開示される発明の状況におけるコンピュータ・デバイスの各々は、ハードウェアおよびソフトウェアを含む（図２に示されるものなどの）データ処理システムであり、これらのエンティティは、たとえばインターネット、イントラネット、エクストラネット、プライベート・ネットワーク、またはあらゆるその他の通信媒体もしくはリンクなどのネットワーク上で互いに通信する。データ処理システム上のアプリケーションは、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＳＡＭＬ、リバティ（Ｌｉｂｅｒｔｙ）、シボレス（Ｓｈｉｂｂｏｌｅｔｈ）、ＯｐｅｎＩＤ、ＷＳフェデレーション、Ｃａｒｄｓｐａｃｅ、ＷＳ−Ｔｒｕｓｔ、ＵＤＤＩおよびＷＳＦＬなどに対するサポートを限定なしに含む、ウェブおよびその他の公知のサービスおよびプロトコルに対するネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩおよびＷＳＦＬに関する情報は、これらの規格を開発および維持する責を負うワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）より入手可能である。ＨＴＴＰ、ＦＴＰ、ＳＭＴＰおよびＸＭＬに関するさらなる情報は、インターネット技術タスク・フォース（ＩＥＴＦ）より入手可能である。これらの公知の規格およびプロトコルに精通していることが前提とされる。

本明細書に記載されるスキームは、クラウド型インフラストラクチャ以外のさまざまなサーバ側アーキテクチャの中で、またはそれとともに実現されてもよい。これらのサーバ側アーキテクチャは、単純なｎ階層アーキテクチャ、ウェブ・ポータル、およびフェデレーテッド・システムなどを限定なしに含む。

上記実施例が示すとおり、アイデンティティ・プロバイダ・インスタンス・ディスカバリ機能の１つまたはそれ以上は、クラウドの内部または外部でホストされてもよい。

さらにより一般的に、本明細書に記載される主題は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアおよびソフトウェア・エレメントの両方を含む実施形態の形を取ってもよい。好ましい実施形態において、層状のログアウト機能はソフトウェアにおいて実現され、このソフトウェアはファームウェア、常駐ソフトウェア、およびマイクロコードなどを含むがそれに限定されない。データはデータ構造（例、アレイ、リンクされたリストなど）に構成されてもよく、かつたとえばコンピュータ・メモリなどのデータ記憶装置に保存されてもよい。さらに上記のとおり、本明細書に記載されるアイデンティティ・プロバイダ・インスタンス・ディスカバリ機能は、コンピュータもしくはあらゆる命令実行システムによる使用、またはそれに関連する使用のためのプログラム・コードを提供するコンピュータ使用可能媒体もしくはコンピュータ読取り可能媒体からのアクセスが可能なコンピュータ・プログラム製品の形を取ってもよい。本記載の目的のために、コンピュータ使用可能媒体またはコンピュータ読取り可能媒体とは、命令実行システム、装置もしくはデバイスによる使用またはそれに関連する使用のためのプログラムを含有または保存できるあらゆる装置であってもよい。媒体は電子、磁気、光学、電磁気、赤外、または半導体のシステム（または装置またはデバイス）であってもよい。コンピュータ読取り可能媒体の例は、半導体または固体メモリ、磁気テープ、リムーバブル・コンピュータ・ディスケット、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ＲＡＭ）、リード・オンリ・メモリ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：ＲＯＭ）、剛性磁気ディスク、および光ディスクを含む。光ディスクの現在の例は、コンパクト・ディスク−リード・オンリ・メモリ（ｃｏｍｐａｃｔ ｄｉｓｋ−ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＣＤ−ＲＯＭ）、コンパクト・ディスク−読取り／書込み（ｃｏｍｐａｃｔ ｄｉｓｋ−ｒｅａｄ／ｗｒｉｔｅ：ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。コンピュータ読取り可能媒体は有形の物品である。

コンピュータ・プログラム製品は、記載される機能の１つまたはそれ以上を実施するためのプログラム命令（またはプログラム・コード）を有する製品であってもよい。それらの命令またはコードは、リモート・データ処理システムからネットワークを通じてダウンロードされた後に、データ処理システム内のコンピュータ読取り可能記憶媒体に保存されてもよい。または、それらの命令またはコードは、サーバ・データ処理システム内のコンピュータ読取り可能記憶媒体に保存されてもよく、かつリモート・システム内のコンピュータ読取り可能記憶媒体における使用のためにネットワークを通じてリモート・データ処理システムにダウンロードされるように適合されてもよい。

代表的な実施形態において、アイデンティティ・プロバイダ・インスタンス・ディスカバリ・コンポーネントは、特定目的のコンピュータにおいて、好ましくは１つまたはそれ以上のプロセッサによって実行されるソフトウェアにおいて実現される。関連する構成（セキュリティ・レベル、状態、タイマ）は、関連するデータ記憶装置に保存される。加えてこのソフトウェアは１つまたはそれ以上のプロセッサに関連する１つもしくはそれ以上のデータ記憶装置またはメモリにおいて維持され、かつソフトウェアは１つまたはそれ以上のコンピュータ・プログラムとして実現されてもよい。

アイデンティティ・プロバイダ・インスタンス・ディスカバリ機能は、既存のアクセス・マネージャまたはポリシ管理ソリューションに対する補助または拡張として実現されてもよい。

上記には本発明の特定の実施形態によって行われる動作の特定の順序が記載されているが、こうした順序は例示的なものであり、代替的実施形態はその動作を異なる順序で行っても、特定の動作を組み合わせても、特定の動作を重複しても、その他を行ってもよいことが理解されるべきである。明細書における所与の実施形態の参照は、記載される実施形態が特定の特徴、構造または特性を含んでもよいことを示すが、すべての実施形態が必ずしもその特定の特徴、構造または特性を含まなくてもよい。

最後に、システムの所与のコンポーネントを別々に説明したが、所与の命令、プログラム・シーケンス、およびコード部分などにおいて、機能のいくつかが組み合わされたり共有されたりしてもよいことを通常の当業者は認識するだろう。

本明細書において用いられる「クライアント側」アプリケーションとは、アプリケーション、そのアプリケーションに関連するページ、またはアプリケーションに対するクライアント側の要求によって呼び出された何らかの他のリソースもしくは機能を示すように広く解釈されるべきである。本明細書において用いられる「ブラウザ」とは、あらゆる特定のブラウザ（例、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、サファリ（Ｓａｆａｒｉ）、ファイアフォックス（ＦｉｒｅＦｏｘ）など）を示すことは意図されておらず、インターネット・アクセス可能なリソースにアクセスしてそれを表示できるあらゆるクライアント側レンダリング・エンジンを示すように広く解釈されるべきである。さらに、典型的にクライアント−サーバの対話はＨＴＴＰを用いて行われるが、このことも限定ではない。クライアント−サーバの対話は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）に準拠するようにフォーマットされて、ＨＴＴＰ（パブリック・インターネット上）、ＦＴＰを通じて移動してもよいし、またはあらゆるその他の信頼性の高い輸送機構（たとえば企業イントラネット上の輸送に対するＩＢＭ（ＩＢＭ社の登録商標）ＭＱＳｅｒｉｅｓ（ＩＢＭ社の登録商標）技術およびＣＯＲＢＡなど）が用いられてもよい。本明細書に記載されるあらゆるアプリケーションまたは機能は、ネイティブ・コードとして実現されたり、別のアプリケーションへのフックを提供することによって実現されたり、その機構をプラグインとして用いることを容易にすることによって実現されたり、その機構にリンクすることによって実現されたりなどしてもよい。

本明細書において用いられる「アイデンティティ・プロバイダ・インスタンス」とは、１つまたはそれ以上の他のこうしたインスタンスにおいても利用可能であるアイデンティティ・プロバイダのインスタンシエーションまたはインプリメンテーションである。よって一般的に、典型的に「インスタンス」とはフル機能のアイデンティティ・プロバイダ（ＩｄＰ）であって、その機能が少なくとも１つの他のこうしたインスタンスにミラーリングまたは複製されているものである。

もちろん、本明細書におけるあらゆる商業製品の識別は、開示される主題を限定することを意味するものではない。

本発明を説明してきたが、出願人が請求するものは以下のとおりである。

Claims (10)

1. アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するための方法であって、
   アイデンティティ・プロバイダ・インスタンスに対する要求が前記ディスカバリ・サービスによって処理されるときに、プロキシが前記アイデンティティ・プロバイダ・インスタンスを識別するデータを前記ディスカバリ・サービスから受取りかつ保存するステップと、
   前記プロキシが前記ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、前記更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、
   前記プロキシが前記更新に基づいて前記データを修正するステップと、
   前記プロキシがアイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、前記修正されたデータを用いることにより、前記新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップと
   を含む、方法。
2. 前記プロキシが前記アイデンティティ・プロバイダ・ディスカバリ・サービスから受取るデータは、要求と、当該要求に対してサービスするために前記ディスカバリ・サービスによって選択されるアイデンティティ・プロバイダ・インスタンスとを関連付ける割り当てデータである、請求項１に記載の方法。
3. 前記プロキシが前記更新を定期的または非同期的に受取る、請求項１に記載の方法。
4. 前記通知サービスは、前記アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスが提供するウェブ・サービスである、請求項１に記載の方法。
5. 前記プロキシが前記更新を受取るためにサブスクライブするステップをさらに含む、請求項１に記載の方法。
6. 前記プロキシが受取る前記更新は、前記アイデンティティ・プロバイダ・インスタンスの１つまたはそれ以上に関連する負荷、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスの可用性、１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する性能メトリック、および１つまたはそれ以上のアイデンティティ・プロバイダ・インスタンスに関連する既存のバインディングのうちの１つを含む、請求項１に記載の方法。
7. 前記プロキシが前記データをポリシまたはビジネス論理に従って修正する、請求項１に記載の方法。
8. アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するための装置であって、
   プロセッサと、
   コンピュータ・プログラム命令を保持するコンピュータ・メモリとを含み、前記コンピュータ・プログラム命令は、前記プロセッサによって実行されることによって、前記装置に、
   アイデンティティ・プロバイダ・インスタンスに対する要求が前記ディスカバリ・サービスによって処理されるときに、前記アイデンティティ・プロバイダ・インスタンスを識別するデータを前記ディスカバリ・サービスから受取りかつ保存するステップと、
   前記ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、前記更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、
   前記更新に基づいて前記データを修正するステップと、
   アイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、前記修正されたデータを用いることにより、前記新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップと
   を実行させる、装置。
9. アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスを用いたアイデンティティ・プロバイダ・サービスを提供するためにデータ処理システムにおいて用いるためのコンピュータ読取り可能媒体内のコンピュータ・プログラムであって、前記コンピュータ・プログラムはコンピュータ・プログラム命令を保持し、前記コンピュータ・プログラム命令は、前記データ処理システムに、
   アイデンティティ・プロバイダ・インスタンスに対する要求が前記ディスカバリ・サービスによって処理されるときに、前記アイデンティティ・プロバイダ・インスタンスを識別するデータを前記ディスカバリ・サービスから受取りかつ保存するステップと、
   前記ディスカバリ・サービスに関連するリソースに関する更新を受取るステップであって、前記更新はハードウェア・エレメント上でサポートされるパブリッシュ−サブスクライブ通知サービスを介して受取られる、ステップと、
   前記更新に基づいて前記データを修正するステップと、
   アイデンティティ・プロバイダ・インスタンスに対する新たな要求を受取ると、前記修正されたデータを用いることにより、前記新たな要求に対する応答に用いるためのアイデンティティ・プロバイダ・インスタンスを識別するステップと
   を実行させる、コンピュータ・プログラム。
10. アイデンティティ・プロバイダ・インスタンスを識別するためのシステムであって、
    ハードウェア・エレメント上でサポートされ、かつ関連するキャッシュを有するプロキシであって、前記プロキシはアイデンティティ・プロバイダ・インスタンス・ディスカバリ要求を発行する、プロキシと、
    前記プロキシによって発行される各アイデンティティ・プロバイダ・インスタンス・ディスカバリ要求を受取り、選択を行い、かつ前記選択を識別するデータを、前記キャッシュに保存するために前記プロキシに戻すアイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスと、
    前記プロキシが前記アイデンティティ・プロバイダ・インスタンス・ディスカバリ・サービスから更新を受取るためにサブスクライブするための通知サービスとを含み、少なくとも１つの更新は、前記ディスカバリ・サービスに関連するリソースに関連し、かつ前記キャッシュに保存された前記データを更新するために前記プロキシによって用いられる、システム。
    

Images