信頼関係に対するクレーム変換
本開示は、信頼関係において複数のクレーム変換モジュールを使用する能力に関する。クレーム変換モジュールは、クレーム又はクレームセットを変換して、信頼されたパートナーおよび／又はアプリケーションにより使用される変換されたクレーム又はクレームセットにする。複数のクレーム変換モジュールに、パイプライン形式でクレーム又はクレームセット上で作動する機会を与えることができる。別の実施形態では、複数のクレーム変換モジュールが存在するが、適切なクレーム変換モジュール（単数又は複数）だけに、クレーム又はクレームセット上で作動する機会を与える。ある実施形態では、関連するクレームは、連合認証システム内の信頼されたパートナー間の認証目的で使用されるセキュリティクレームである。
【発明の詳細な説明】
【背景技術】
【０００１】
他と異なる個々のコンピュータシステムを持つ個々の組織では、お互いに、特に互いの従業員や顧客に効率よく情報を提供することをしばしば望んでいる。組織から情報を入手するために、ユーザは一般に、例えばユーザ名およびパスワードといった信用証明物を所有していることを証明することにより、情報を求める組織に対して自分のアイデンティティを認証又は証明することを要求される。しかしながら、個々の組織のウェブサイトより提供される情報にアクセスするために、例えばユーザ名やパスワードといった個々のセキュリティログオン信用証明物を要求する代わりに、個々の組織は情報を共有しアクセスするようお互いにビジネスレベルで合意することがある。連合認証システムは、パートナーが自分の連合サービスを展開することにより、情報を共有してアクセスできるようにしたシステムの例である。そのような情報を共有してアクセスするために、第１のパートナーはアイデンティティデータおよび／又は認証に関するデータを使用して、第２のパートナーに対して「クレーム」を作成することができる。そのような関係では、第２のパートナーは、第１のパートナーがユーザを認証し、そのユーザについてのあるクレームを作成するよう任せる。しかしながら、第２のパートナーは、第１のパートナーにより提示されたクレームを理解することができない場合もある。例えば、そのクレームが第２のパートナーが承認できるフォーマットになっていないこともある。組織が複数のパートナーと通信する場合、問題は深刻である。
【０００２】
この「背景技術」の元で特定の問題に取組んでいるが、本開示は決してそれらの特定の問題を解決することに限定するよう意図していない。
【０００３】
【特許文献１】米国特許出願第１１／１１９２３６号 （ＭＳ３１２１６１．０１）
【発明の開示】
【課題を解決するための手段】
【０００４】
本発明の実施形態は、一般的に信頼されたパートナー間で共有するためのクレーム又は認証情報の変換に関する。さらに、実施形態は連合システム内の複数のクレーム変換モジュールの使用に関する。
【０００５】
本明細書で議論するように、ある特定の実施形態の態様は、拡張ポイントの一部としての複数のカスタムクレーム変換モジュールの使用に関する。１実施形態では、複数のクレーム変換モジュールに、クレーム又はクレームセット上でパイプライン形式で作動して変換されたクレーム又はクレームセットを作成する機会を与えることができる。別の実施形態では、複数のクレーム変換モジュールが存在するが、適切なクレーム変換モジュール（単数又は複数）だけにクレーム又はクレームセット上で作動する機会を与える。
【０００６】
この「課題を解決するための手段」は、下記「発明を実施するための最良の形態」で詳細に記述する、概念の選択を簡易な形態で紹介するために提供される。この「課題を解決するための手段」は、特許請求の主題の主要な、又は本質的な特徴を特定することを意図しておらず、決して特許請求の主題の範囲を限定するために使用することを意図していない。
【発明を実施するための最良の形態】
【０００７】
本開示では、幾つかの実施形態を示す添付図面を参照して、幾つかの例示的実施形態についてより詳細に記述する。しかしながら、多数の異なる形態で具現化される他の態様もあり、本開示中の特定の実施形態を含めることは、そのような態様を本明細書で説明する実施形態に限定すると解釈してはならない。むしろ、図面に描かれた実施形態は、綿密でおよび完全ならびに当業者に意図している範囲を十分に伝える開示を提供するために含まれる。図面を参照する際、全体を通して示す同様の構造や要素は、同じ参照番号で指示される。
【０００８】
アイデンティティプロバイダ１０２とも呼ばれ、トークンがアイデンティティプロバイダ１０２により暗号を使用して署名され１つのクレーム又は複数のクレームを含むセキュリティトークン１０８を共有する第１の組織１０２を、リソースプロバイダ１０４とも呼ばれる第２の組織１０４と共に示す環境１００を図１に示す。本発明の１実施形態では「クレーム」と呼ぶが、本発明の別の実施形態に従ってセキュリティトークン１０８には単一のクレームを含むこともできる。この例示的な実施形態では、ユーザ１０３は、ネットワーク１０５上でアイデンティティプロバイダ１０２に送信される何らかの信用証明物を使用して認証を行う。ユーザは、リソースプロバイダ１０４に対して認証するのに使用することができるセキュリティトークン１０８を要求する。元の認証イベントを活用して、アイデンティティプロバイダ１０２は、ユーザについての様々なクレームを含むセキュリティトークン１０８を形成する。ユーザ１０３はセキュリティトークン１０８をリソースプロバイダ１０４に提示して、リソースプロバイダ１０４が、セキュリティトークンが信頼されたパーティにより発行され、そのパーティはその中でクレームを作成することを承認されたということを検証してから、そのリソースプロバイダ１０４は、それらのクレームに基づいたリソースへのアクセスを許可する。
【０００９】
１実施形態では、暗号を使用して署名されたセキュリティトークンは、アイデンティティプロバイダ１０２、又は「クレーム作成者（ｃｌａｉｍａｎｔ）」がリソースプロバイダ１０４に信頼されているという暗号化証明を構成する。このように、リソースプロバイダ１０４は、アイデンティティプロバイダ１０２がユーザ１０３を認証し、そのユーザについてのあるクレームを作成するよう任せる。リソースプロバイダ１０４がアイデンティティプロバイダ１０２を「信頼する」ので、この関係を「信頼関係」と呼ぶ。リソースプロバイダ１０４とアイデンティティプロバイダ１０２との間の信頼関係は、リソースプロバイダ１０４ドメインとアイデンティティプロバイダ１０２ドメインとの間の論理的な関係としてこのように定義され、その関係においてリソースプロバイダ１０４はそのユーザ（複数）１０３についてのアイデンティティプロバイダ１０２のクレームを尊重する。「信頼関係」という用語を使用するが、この関係は決して相互的ではない。その代り、リソースプロバイダ１０４がアイデンティティプロバイダ１０２を信頼し、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、信頼パートナーと呼ばれる。
【００１０】
図１の例示的な実施形態において、組織１０２および１０４はこのように、リソースプロバイダ１０４に対して認証するのに使用できるセキュリティトークン１０８を、ネットワーク１０６上で組織１０４に送信するというような信頼関係を有する。図１に示す例示的な実施形態に従って、セキュリティトークン１０８が信頼されたパーティ、即ちアイデンティティプロバイダ１０２により発行されるリソースプロバイダ１０４に対してセキュリティトークン１０８は、ユーザ１０３を認証する。セキュリティトークン１０８に含まれるクレームは、ユーザ１０３の体験をカスタマイズするおよび／又は承認決定を行うことに対する認証を行った後で使用される。信頼関係はこのように、アイデンティティプロバイダ１０２とリソースプロバイダ１０４との間の異なった情報のフローを可能にする。情報のフローは存在するが、１実施形態では、セキュリティトークン１０８内で送信されたクレームは、共用する前にあるフォーマットから別のフォーマットに変換されている。セキュリティトークン１０８内のクレーム情報のこのような変換は、アイデンティティプロバイダ１０２のドメイン内の拡張ポイント１２４の一部として挿入されたクレーム変換モジュールを使用することにより行われる。単一のクレーム変換モジュールを使用することもできるが、拡張ポイントの一部として複数のクレーム変換モジュールをプラグインすることもできる。別の実施形態では、クレーム情報を拡張性のあるクレーム変換モジュール１２６の使用を通してネットワーク１０６上で送信した後、変換することができる。この実施形態の態様も、複数のクレーム変換モジュールの使用を可能にする。
【００１１】
図１は、アイデンティティプロバイダ１０２からリソースプロバイダ１０４へのクレーム情報１０８のフローを示す。本発明の１実施形態に従って、セキュリティトークン１０８内のクレーム情報は、クレームセット１１０として示すように、実際は特定のクレームのセットである。各々のクレームは、一般に特定の人又はユーザに関する識別情報に関する。例えば、あるクレームはユーザ名１１２を含むことができ、別のクレームはユーザの電子メールアドレスを含むことができる。他のクレームは、ユーザの従業員識別番号１１６、社会保障番号１１８、例えば髪の色等の身体的特徴１２０、その他１２２に関することができる。セキュリティトークン１０８内に含まれるクレーム情報は、ユーザの体験をカスタマイズする、および／又は承認決定をするために使用する。とは言っても以下で議論するように、クレームのフォーマット（又は内容）を、リソースプロバイダに依存して修正することができる。１実施形態では、アイデンティティプロバイダ１０２のユーザに対するアカウントを検証又は認証するために、クレームはリソースプロバイダ１０４により使用される。図１に示すセキュリティトークン１０８内に含まれる複数のクレームを有する実施形態もあれば、単一のクレームからなるフローを伴う実施形態もある。
【００１２】
上述のように本発明の実施形態では、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は信頼パートナーである。アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、例えば、ほんの一例としては、会社、企業、個人等 エンティティのいずれのタイプであってもよい。認識されているように、どのようなコンピュータシステムでも、そのようなエンティティとして動作できる。同様に、認識されているように、そのようなエンティティ間の信頼関係は当業者には周知されている。一般に、信頼関係は、組織のリソースへのアクセスを許可する前に、ユーザを認証するためにセキュリティ認証を要求する。ウェブサービス（ＷＳ）連合は、組織の境界を越えてアイデンティティ情報の共有を可能にする機構であり、各信頼パートナーは連合化されたサービスを展開して情報の共有やアクセスができるようにする。そのような信頼関係は、「連合」認証関係とも呼ばれ、クレームはネットワークを通じてアイデンティティプロバイダ１０２からリソースプロバイダ１０４へ「連合されている」と言うことができる。そのような共有を可能にするために、ＷＳ連合は一般にＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）セキュリティトークンを使用するが、そのようなセキュリティトークンはＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）又はＸｒＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｒｉｇｈｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のフォーマットを利用している。これらのセキュリティトークンは、限定はしないが、クレーム情報を含む。ＷＳ連合は、通信プロトコルを記述する仕様である。ＷＳ連合プロトコルは、マイクロソフト社製Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｆｅｄｅｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（「ＡＤＦＳ」）により実装されている。
【００１３】
本発明の１実施形態では、アイデンティティプロバイダ１０２は拡張性のあるクレーム変換モジュール１２４を有し、１つのフォーマットからリソースプロバイダ１０４により指定されたフォーマットへクレーム情報の変換を遂行する。変換モジュール１２４が作動して、クレーム又はクレームセットを望ましいフォーマットへ変換する。同様に別の実施形態では、リソースプロバイダが複数の異なったアプリケーションを展開することもでき、そのようなアプリケーションは同じフォーマットで全てのセキュリティクレームを受信することはできない。ほんの一例だが、ユーザの誕生日を要求するリソースプロバイダのアプリケーションもあれば、ユーザの年齢を年数で要求するアプリケーションもある。従って、リソースプロバイダは、アイデンティティプロバイダにより提供されたクレームのフォーマットを、特定のリソースアプリケーションが要求するフォーマットに変換することが必要になる。したがって、１実施形態では、限定はしないが、アイデンティティプロバイダ１０２がリソースプロバイダ１０４に承認又は要求された適切なフォーマットでクレームを提供しない場合、又は特定のリソースアプリケーションのために、クレームのさらなる又は異なる変換を要求された場合を含む状況で、拡張性のあるリソースプロバイダクレーム変換モジュール１２６が使用される。実施形態において、アイデンティティプロバイダクレーム変換モジュールおよびリソースプロバイダクレーム変換モジュールは、信頼関係にある特定のアイデンティティプロバイダ１０２および特定のリソースプロバイダ１０４に対して（又は、同様に、特定のリソースアプリケーションに対して）このようにカスタマイズされ、「カスタム」クレーム変換モジュールとも呼ぶこともできる。
【００１４】
上述のように、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、ネットワーク１０６を通じて情報を共有してアクセスする。ネットワーク１０５および１０６は、従来当業者に周知のネットワークのいずれのタイプであってもよい。１例示的実施形態に従って、ネットワークはグローバルネットワーク（即ち、インターネット、又はワールドワイドウェブ）であることができる。ローカルエリアネットワーク、又は広域ネットワークの場合もある。別の実施形態では、組織が全体として個々の他と異なる管理のドメインを持つことになるが、ネットワークは例えばイントラネットのようなプライベートネットワークであることもできる。ネットワーク１０６は従来当業者に周知のネットワークのいずれのタイプであってもよいが、「ワールドワイドウェブ」（即ち、略して「ウェブ」）として１例示的実施形態に従って記述される。そのため、１又は複数の標準のパケットベースのフォーマット（例えば、Ｈ．３２３、ＩＰ、イーサネット、ＡＴＭ）に従って、ネットワーク１０６上の通信が発生する。
【００１５】
次に本発明の１実施形態に従って連合認証システムのさらに詳細な説明ついて見ると、図２はアイデンティティプロバイダ１０２とリソースプロバイダ１０４との間のネットワーク１０６を通じたクレームデータのフローを示す。ゼネラルフロー２００は、アイデンティティプロバイダ１０２側のアカウントストア２０２で始まるが、アイデンティティプロバイダ１０２がクレームを作成するのに使用するアイデンティティ情報をアカウントストア２０２が提供する。この実施形態では、アカウントストア２０２は、アイデンティティプロバイダ１０２に関連づけたアカウント（例えば、ユーザ）を認証するためのデータを管理するコンポーネントである。ほんの一例だが、アカウントストア２０２はＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ａｐｐｌｉｃａｔｉｏｎ Ｍｏｄｅ（ＡＤＡＭ）、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）システム、又は同様のシステムを含むことができる。
【００１６】
アカウントストア２０２は、セキュリティ情報と共にアカウント組織クレーム（「クレーム」）２０６をポピュレートする２０４。次いでクレーム２０６は、拡張性のあるアイデンティティプロバイダ変換モジュール２０８内で、アカウントストアに特有のフォーマットから、リソースプロバイダ１０４に承認された連合フォーマットに変換される。変換されたクレームは、セキュリティトークン１０８等のセキュリティトークン内にパッケージされる出力クレーム２１０として変換モジュール２０８から離れ、ネットワーク１０６上でリソースプロバイダ１０４に送信される２１２。出力クレーム２１０は入来クレーム２１４として、リソースプロバイダ１０４側に入る。「出力クレーム」２１０および「入来クレーム」２１４という用語を使用するが、そのようなクレームは例えばセキュリティトークン１０８等のセキュリティトークン内に含まれ、又はパッケージされると理解されるべきである。リソースプロバイダ側１０４でのさらなる処理の前に、セキュリティトークン１０８の暗号化署名は、発行者、即ち図１の例示的実施形態内のアイデンティティプロバイダ１０２がセキュリティトークン１０８内でクレームを作成することを任されていることを保証することを検証される。一旦検証されると、リソースプロバイダ側１０４で処理が継続される。セキュリティトークン１０８内のクレームのフォーマットは、リソースプロバイダ１０４により承認されたフォーマットに既に変換されているが、そのような変換が発生していない、又はさらなる変換が必要な実施形態では、拡張性のあるリソースプロバイダ変換モジュール２１６は入来クレーム２１４を、連合フォーマットから、リソース組織クレーム（「クレーム」）としてリソースアプリケーション２２２により承認されたフォーマットへ変換、又はさらに変換することができる。このステップはオプションと考えられるので、リソースプロバイダカスタムクレーム変換モジュール２１６は、図２では破線のフォーマットで示される。１実施形態では、アイデンティティプロバイダカスタムクレーム変換モジュール２０８もオプションと考えられる。別の実施形態では、リソースプロバイダカスタムクレーム変換モジュール２１６だけが、あるいは、アイデンティティプロバイダカスタムクレーム変換モジュール２０８だけがオプションと考えられる。クレームは次いでリソースアプリケーション２２２により使用するためにイネーブル２２０される。クレームデータの全てがリソースアプリケーション２２２に送付されないように、イネーブル２２０ステップはクレームデータのフィルタリングを含む。アイデンティティプロバイダおよびリソースプロバイダ変換モジュール２０８および２１６は、連合認証システム２００内で単一ブロックとして示されているが、これらの変換モジュールは議論したように、複数のクレーム変換モジュール又はサブモジュールの使用に対して拡張性ポイントになりうるということには留意すべきである。
【００１７】
図２のクレームデータのフローは、特定のアイデンティティプロバイダ１０２と特定のリソースプロバイダ１０４との間のものである。例えば、アイデンティティプロバイダ１０２側では、アイデンティティプロバイダ変換モジュール２０８は、入来するアカウント組織クレーム２０６をアカウントストア２０２に特定のフォーマットからリソースプロバイダ１０４により承認された連合フォーマットに変換する。この変換には１つ又は複数の中間ステップを含むことができる。その例示的な実施形態は、一般出願人マイクロソフト社に譲渡された、「特許文献１」に「Ｓｅｃｕｒｉｔｙ Ｃｌａｉｍ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ ｗｉｔｈ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｃｌａｉｍｓ」と題して記述され、その開示全体は本明細書に組み込まれている。本発明の実施形態に従って、その結果のクレーム情報を、複数のカスタムクレーム変換モジュール又はサブモジュールを使用して変換することができる。
【００１８】
実施形態のいくつかに従って、所与のアイデンティティプロバイダが連合に加わり、クレーム情報を幾つかの異なったリソースプロバイダに送信することができる。図２に戻ると、拡張性のあるクレーム変換モジュール、例えばアイデンティティプロバイダクレーム変換モジュール２０８、が図中に描かれているが、本発明の１実施形態はアイデンティティプロバイダ「Ａ」１０２側の拡張ポイントの一部として挿入された単一のカスタムクレーム変換モジュールの使用を含み、この変換モジュールは、そのアイデンティティプロバイダが信頼関係にある、予め決められたリソースプロバイダ「Ａ」１０４に承認されたフォーマットにクレームを変換するようにカスタマイズされている。しかしながら、アイデンティティプロバイダ「Ａ」１０２により異なったリソースプロバイダ「Ｂ」との新しい信頼関係が生成されると、アイデンティティプロバイダカスタムクレーム変換モジュールを変更して、新しいリソースプロバイダ「Ｂ」により、そしてその後は各々の新しいリソースプロバイダ「ｎ」により承認された連合フォーマットにクレームの変換をカスタマイズする必要がある。
【００１９】
複数の信頼関係およびカスタムクレーム変換モジュールがこのように可能であり、それらを図３においてネットワーク環境３００の論理的表現中に示す。アイデンティティプロバイダ「Ａ」１０２はリソースプロバイダ「Ａ」１０４と信頼関係があり、クレームはカスタムクレーム変換モジュールＴｘ１ ３０４により変換される。新しい信頼関係が、アイデンティティプロバイダ「Ａ」１０２と異なるリソースプロバイダ「Ｂ」３０２との間に生成され、クレーム変換モジュールはこの新しいペアに対して書き換えられＴｘ２ ３０６としてカスタマイズされる。そのような関係およびカスタムクレーム変換モジュールは、楕円３１２で示すように、不確定数のリソースプロバイダ「ｎ」３０８および対応するカスタムクレーム変換モジュールＴｘｎ ３１０まで存在することができる。同様に、可能なかぎり多数の予め決められた個々で他と異なるリソースアプリケーション２２２に対して変換されたある特定の連合フォーマットを入来クレームが有する一般的な連合認証システムのリソースプロバイダ側１０４で、複数の変換が必要となる。
【００２０】
しかしながら、対になるアイデンティティおよびリソースプロバイダ各々に対して単一のカスタムクレーム変換モジュールを有する代わりに、および新しいリソースプロバイダと各々新しい信頼関係を生成するとその単一のモジュールを変更しなければならない代わりに、本発明の実施形態は、連合認証システムの変換モジュール２０８および／又は２１６の拡張ポイントにプラグインされた複数のカスタムクレーム変換サブモジュールを有する。本明細書では「サブモジュール」という用語を使用するが、これらの「サブモジュール」は技術的に独立したエンティティであり、本発明の実施形態に従って単独、又は組み合わせて使用することができる。このように、「モジュール」という用語はこれらの独立したエンティティを記述するのに使用できる。しかしながら、「サブモジュール」という用語は、本明細書では拡張性のある変換モジュール２０８および／又は２１６全体を備えるそれらのモジュールを指すという単純な目的で使用する。図４について見ると、変換モジュールの実施形態４００を示し、変換モジュール２０８および／又は２１６の拡張ポイントにおいて、接続（又はパイプライン）形式でそのようなサブモジュールを連合認証システムにプラグインすることができる。これらのパイプライン状の変換サブモジュールを、次いでパイプライン形式で呼び出し、変換サブモジュール各々は適用可能な場所であるクレームセット上で動作して、リソースプロバイダの信頼パートナーへの送信用に結果のクレームセットを構築することができる。これら複数のカスタムクレーム変換サブモジュールは、パイプライン形式で呼び出され、１つのクレームセットを片付ける。上述のように、本発明の実施形態は単一のクレームを含むこともあれば、他の実施形態ではクレームセットを含むこともある。図４に示すように、入来するアカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）は、先ず変換サブモジュール１（「Ｔｘ１」）３０４により処理され、次いでＴｘ２ ３０６により処理され、というように「ｎ」個の異なった変換モジュールＴｘｎ ３１０に対してパイプライン形式で、出力クレーム２１０に向けて（又は別の実施形態ではイネーブル２２０に向けて）処理される。変換サブモジュール各々はパイプライン形式で呼び出されるが、要求された特定の変換のために書かれたそれらのサブモジュールだけが、実際にはクレーム、又はクレームセットに作用、即ちそれらを変換する。
【００２１】
図４に描かれた例示的な実施形態を参照すると、Ｔｘ１ ３０４がアイデンティティプロバイダ１０２からリソースプロバイダ１０４に承認されたフォーマットにクレームを変換するように書かれている場合、次いで入来クレームがアイデンティティプロバイダ１０２からのもので、出力クレーム２１０がリソースプロバイダ１０４に向かうものである場合だけ、そのクレームに作用する。例えば、アイデンティティプロバイダ１０２およびリソースプロバイダ３０２が関係しているが、Ｔｘ１ ３０４がアイデンティティプロバイダ１０２からリソースプロバイダ１０４にクレームを変換するように書かれている場合、Ｔｘ１ ３０４はそのクレームには作用せず、クレームは（図４に示すように）Ｔｘ２ ３０６に移る。同様に、Ｔｘ１ ３０４は入来クレーム２１４を特定の連合フォーマットで特定のリソースアプリケーション２２２に変換するように書かれ、一方Ｔｘ２ ３０６は異なる個々のリソースアプリケーションに対してそのような変換を生じさせるように書かれている場合もある。
【００２２】
図５に関しては、パイプライン形式で編成された複数のカスタムクレーム変換サブモジュールの使用を通じて、クレーム又はクレームセットを変換するプロセス５００が、本開示の１実施形態に従って示されている。ここでは、本発明の１実施形態に従って、クレームセットが変換されるが、その変換はクレームセット内の全てのクレームに適用されるものであり、個々のクレームに適用されるものではない。したがって、１実施形態では、幾つかのクレーム値に基づいて変更がなされるか、あるいは１つのクレームが結果として幾つかの新しいクレームになることもある。変換モジュール２０８および２１６は、一般的な意味では一定量のクレームの操作が可能だが、パイプライン形式で編成された複数のカスタムクレーム変換モジュール又はサブモジュールを使用することにより、クレームのこれらの操作をモジュール化することが可能となる。開始操作５０２で始まる操作フローを使用して変換プロセス５００が行われる。
【００２３】
開始操作５０２は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）のポピュレートに引き続いて開始される。プロセス５００の操作フローは、開始操作５０２から受信操作５０４に進む。受信操作５０４は、入来するアカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。操作フローは、受信操作５０４からカスタムクレーム変換操作Ｔｘ１ ５０６に移る。Ｔｘ１変換操作は、適用可能であればクレームを変換する。次いで操作はクエリ操作５０８に移る。クエリ操作５０８は、別のカスタムクレーム変換サブモジュールおよびその結果の変換操作が存在するかどうかを判定する。クエリ操作５０８が別のカスタムクレーム変換が存在すると判定する場合、フローはＹＥＳの方に分岐して、不定数のカスタムクレーム変換サブモジュールおよびクエリ操作のためにカスタムクレーム変換サブモジュールＴｘｎ５１０に進む。クエリ操作５０８で別のカスタムクレーム変換サブモジュールが検出されない場合、フローはＮＯに分岐して、何らかの変更がされたかどうかを判定するクエリ操作５１８に進む。変更が検出される場合、フローはＹＥＳの方に分岐してカスタムクレーム変換サブモジュールパイプラインを通して繰り返し処理するために受信操作５０４に戻る。変更に基づいたクレームの再処理は、１つの変換サブモジュールが、別のカスタムクレーム変換のそれとは矛盾した変更をするのを許可しないよう、セキュリティの特徴として作動する。
【００２４】
一方、クエリ操作５１８がクレームに対する変更を検出しない場合、定常状態が実現され変換プロセス５００の操作フローはＮＯの方に分岐して、終了操作５２０に進む。終了操作５２０は、変換プロセスを終了させる。セキュリティの特徴の追加として、変換チェッククエリ操作５２２を通して、操作フローを移し、いかなるカスタムクレーム変換サブモジュール（複数）によっても、矛盾する又はそうでなければ許可されない変更がされていないことを確認することも可能である。この最終チェックステップはオプションであり、したがって図５では破線フォーマットでクエリ操作５２２として示す。クエリ操作５２２が、最終チェックを十分ではない、即ち許可されない変更が存在すると判定する場合、フローはＮＯの方に分岐して修正操作５２４に進む。修正操作５２４は、矛盾する又は許可されない如何なるクレームも修正する。プロセス５００は、修正操作５２４から訂正したクレーム（又はクレームセット）を作成する作成操作５２６に進む。訂正されたクレーム又はクレームセットの作成に引き続いて、フローは、変更が再処理されるように処理を再スタートするべきかどうかを判定する再スタートクエリ５２８へ進む。再スタートクエリ５２８が再処理を行うべきと判定する場合、フローはＹＥＳの方に分岐して受信操作５０４に進む。再スタートクエリ５２８が再処理を行うべきでないと判定する場合、フローはＮＯの方に分岐して終了処理５２０に進む。同様にして、クエリ操作５２２が最終チェックは十分である、即ち変更が許可され、および／又は矛盾がないと判定する場合、フローはＹＥＳの方に分岐して終了操作５２０に進む。終了操作５２０は、変換プロセス５００を終了させる。そこから、出力クレームがネットワーク１０６を介してリソースプロバイダ１０４に送信される。あるいは、しかし同様に、リソースプロバイダ変換モジュール２１６により変換されたクレームは、リソースアプリケーション２２２のためにイネーブル２２０される。クレームをイネーブル２２０する際、必要であればクレームデータはフィルタリングされる。
【００２５】
次に図６を見ると、複数のカスタムクレーム変換モジュール又はサブモジュールを含むマッピングプロセス６００が、本開示の１実施形態に従って示される。マッピングプロセス６００とは、適切なカスタムクレーム変換サブモジュール（単数又は複数）だけが、セキュリティクレーム又はクレームセットに作用する機会が与えられている実施形態のことをいう。例えば、本発明の１実施形態に関して記述された連合認証システムのアイデンティティプロバイダ側１０２上の変換の場合、「適切な」とは特定のアイデンティティプロバイダおよび信頼関係に関与する一対となったリソースプロバイダのために書かれたそれらのカスタムクレーム変換サブモジュールのことを言う。同様に、一般的な連合認証システムリソースプロバイダ側１０４上の変換を含む別の実施形態でも、「適切な」とは、例えば、ある特定の連合クレームフォーマットおよび予め決められたリソースアプリケーション又はサービス２２２のために書かれたそれらの変換のことを言う。
【００２６】
アカウント組織クレーム２０６のポピュレート（又は別の実施形態では入来クレーム２１４の受信）に引き続いて開始される開始操作６０２で開始する操作フローを使用して行われる１例示的実施形態に従って、変換マッピングプロセス６００を記述する。上で議論したように、単一のクレームを含む実施形態もあれば、１つのクレームセットを含む別の実施形態もある。１つのクレームセットが変換される場合、その変換はそのクレームセット内のクレーム全てに適用される。開始操作６０２から、プロセス６００の操作フローは受信操作６０４に進む。受信操作６０４は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。操作フローは、受信操作６０４から評価操作６０６に移る。評価操作６０６は、適切なカスタムクレーム変換サブモジュール、すなはちＴｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２のいずれに、変換のためにクレームを送信すべきかを判定する。本発明の１実施形態に従って、楕円６１１で示されるように、１又は複数のクレーム変換サブモジュールが使用できる。どのカスタムクレーム変換サブモジュールが適切かを判定するために、評価操作６０６はクレームを解析して６２６、マッピング選択６２８を調べ、もしあれば変更（受信操作６０４で受信したクレームが既に変換されている実施形態では変更が既になされている）を比較６３０する、等を行う。更に、１つ以上の変換サブモジュールが「適切」で１実施形態では、そのような適切なクレーム変換サブモジュール各々はクレーム上で動作する機会が与えられていることを、評価操作６０６は保証している。例えば、１実施形態では、評価操作６０６は適切なカスタムクレーム変換モジュールを判定する。そして１つ以上のそのようなモジュールが適切であると思われる場合、万一クレームが同じカスタムクレーム変換サブモジュールに繰返し送信される場合そうなる可能性のある、定常状態変化の間違った出現が起こらないように、評価操作６０６はクレームを交互方式６３２で適切なカスタムクレーム変換サブモジュールに送信する。
【００２７】
クレームを送信すべき適切な変換サブモジュールを判定すると、クレームはＴｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２に送信される。カスタムクレーム変換Ｔｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２に引き続いて、操作はクエリ操作６１４に進む。クエリ操作６１４は、クレームに対して何らかの変更が行われたかどうかを判定する。クエリ操作がクレームに対する変更が存在すると判定する場合、フローはＹＥＳの方に分岐して受信操作６０４に進み、次いで評価操作６０６に進み、そこでクレームは再び解釈され６２６、マッピングが評価され６２８、変更が比較され６３０、交互方式の「適切な」変換サブモジュールパターンが、もしあれば、検出される６３２、等が行われる。
【００２８】
クエリ操作６１４が、クレームの変更が存在せず、定常状態が達成されたことを判定するまで、この操作フローは繰り返される。変更が存在しないとクエリ操作６１４が判定する場合、フローはＮＯの方に分岐して終了操作６１６に進む。セキュリティの特徴の追加として、変換チェッククエリ操作６１８を通して操作フローを移し、矛盾した又はそうでなければ許可されない変更がカスタムクレーム変換サブモジュール（複数）によりなされていないことを確認することも可能である。この最終チェックステップはオプションであり、したがって図６では破線フォーマットでクエリ操作６１８として示す。クエリ操作６１８が、最終チェックは十分でない、即ち許可されない変更（複数）が存在すると判定する場合、フローはＮＯの方に分岐して訂正操作６２０に進む。訂正操作６２０は、矛盾する又は許可されない如何なる変更も訂正する。プロセス６００は、訂正操作６２０から訂正されたクレーム（又は１実施形態ではクレームセット）を作成する作成操作６２２に進む。訂正されたクレームの作成に引き続いて、フローは、変更が再処理されるように処理を再スタートすべきかどうかを判定する再スタートクエリ６２４へ進む。再スタートクエリ６２４が再処理を行うべきであると判定する場合、フローはＹＥＳの方に分岐して受信操作６０４に進む。再スタートクエリ６２４が、再処理を行うべきでないと判定する場合、フローはＮＯの方に分岐して終了操作６１６に進む。同様に、クエリ操作６１８が、最終チェックは十分である、即ち変更が許可されていると判定する場合、フローはＹＥＳの方に分岐して終了操作６１６に進む。終了操作６１６は変換プロセス６００を終了する。そこから、出力クレームはネットワーク１０６を介してリソースプロバイダ１０４に送信される。あるいは、しかし同様に、リソースプロバイダ変換モジュール２１６により変換されたクレームは、リソースアプリケーション２２２のためにイネーブル２２０される。クレームをイネーブル２２０する際に、必要であればクレームデータはフィルタリングされる。
【００２９】
当然のことながら、図５と図６に示した、従って本明細書に記述したプロセスは、一般的な連合認証システムのアイデンティティプロバイダ１０２側、又はリソースプロバイダ１０４側のどちらかでのクレームの変換に適用可能である。例えば、アイデンティティプロバイダ側の適切なクレーム変換サブモジュールにマッピングすることは、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４のアイデンティティを判定することを含む。同様に、適切なリソースプロバイダクレーム変換サブモジュールにマッピングすることは、同様の判定プロセスを含むが、連合入来クレームのフォーマット、およびクレームを提供するよう意図する特定のリソースアプリケーション又はサービスが要求するフォーマットについての判定を含む。したがって、受信操作６０４は、本発明の実施形態に従って、アカウント組織セキュリティクレーム２０６、又は入来クレーム２１４に適用することができる。
【００３０】
次に図７、図８を見ると、本開示の例示的な実施形態に従ってプロセス７００およびプロセス８００が示されており、そこでは各変換サブモジュールが元のクレーム又はクレームセットのみに作用するように、各カスタムクレーム変換サブモジュールからの結果クレーム又はクレームセットが分離されている。次いでプロセス７００および８００は結果クレームを維持して統合する。開始操作７０２は、アカウント組織クレーム２０６のポピュレート（又はリソースプロバイダ側１０４を含む別の実施形態では入来クレーム２１４の送信）に応じて開始される。プロセス７００の操作フローは、開始操作７０２から受信操作７０４に進む。受信操作７０４は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。フローは、受信操作７０４から、適用可能であれば、クレームを結果クレーム１ ７０８に変換するカスタム変換操作Ｔｘ１ ７０６に移る。元のクレームの変更されていない形式は、適用可能であれば、クレームを結果クレーム２ ７１２に変換するＴｘ２ ７１０に移る。本発明の実施形態に従って、楕円７１１と楕円７１３で示すように、単一の変換モジュール７０６又は「ｎ」個の変換モジュール７１４、および単一の結果クレーム７０８又は「ｎ」個の結果クレーム７１６が使用できる。元のクレームは、パイプライン形式でＴｘｎサブモジュール７１４および結果クレーム「ｎ」７１６に移る。結果クレーム７０８、７１２および７１６は維持されて、次いでフローは、結果クレームを統合して最終的なクレーム又はクレームセットを作成する７２０統合操作７１８に進む。終了操作７２２がプロセスを終了させる。
【００３１】
同様に、プロセス８００は、上記の開始操作７０２に関しての記述と同様に開始される開始操作８０２で開始する。次いで操作フローはまた、上記受信操作７０４についての記述と同様に、受信操作８０４に進む。操作フローは、受信操作８０４から、元のクレームを送信すべき適切な変換サブモジュールを判定する評価操作８０６（上記図６に記述され描かれているように）に移る。本発明の実施形態に従って、楕円８１５と楕円８１７で示すように、単一の変換サブモジュール８０８又は「ｎ」個の変換サブモジュール８１６、および単一の結果クレーム８１０又は「ｎ」個の結果クレーム８１８が使用できる。次いで変換サブモジュールＴｘ１ ８０８、Ｔｘ２ ８１２、．．．Ｔｘｎ ８１６が、元のクレーム又はクレームセット上で分離して動作して、結果クレーム８１０、８１４および８１８をそれぞれ作成する。操作は、結果クレームを統合して最終クレーム又はクレームセットを作成する８２２統合操作８２０に進む。終了操作８２４がプロセスを終了させる。図７とプロセス７００について記述したように、図８に関する別の実施形態は受信操作８０４への入来クレーム２１４を含み、入来クレーム２１４は図２で描かれているリソースプロバイダ１０４側に存在している。
【００３２】
当然のことながら、本発明の他の実施形態は、定常状態操作を実現するために、例えばクレームの変更に関するチェックを許可するようにプロセス７００およびプロセス８００に追加する追加のステップを提供することができる。プロセス７００およびプロセス８００は、カスタムクレーム変換サブモジュール各々から結果クレーム又はクレームセットを分離するコンセプトを示すように、一般化された形式で示されている。その他の図に関しては、図７および図８の一般化された形式は、本明細書で描かれ、又は記述された特定のステップに限定されると決して解釈されてはならない。
【００３３】
図９に示す１実施形態の態様に従って、図１および図３を参照して上で議論したように、組織はクレーム要件および変換能力をカスタマイズすることができる。それに関するフロー操作を図９に示す。プロセス９００は開始操作９０２で開始するが、図１および図２に特定の実施形態として描かれているように、拡張性のある認証システムとの信頼環境の生成に応じて開始操作９０２は開始される。フローは、拡張ポイント１２４、１２６、２０８および／又は２１６の存在を識別する識別操作９０４に進む。１実施形態においては、フローは識別操作９０４から、アイデンティティプロバイダ１０２のクレームフォーマット、およびリソースプロバイダ１０４に必要な又は好ましいクレームフォーマットを判定するフォーマット判定操作９０６に進む。図２に示すクレームデータのフローのリソースプロバイダ１０４側を含む別の実施形態においては、フォーマット判定操作９０６は、入来クレーム２１４のクレームフォーマットおよび予め決められたリソースアプリケーション２２２に必要なフォーマットを判定する。フォーマット判定操作９０６に引続き、フローはカスタムクレーム変換サブモジュール生成操作９０８に進む。１実施形態に従って、生成操作９０８はカスタムクレーム変換サブモジュール、例えば、３０４、３０６又は３１０を生成し、アイデンティティプロバイダ１０２のクレームフォーマットからリソースプロバイダ１０４に必要な又は好ましいクレームフォーマットにクレームフォーマットを変更する。別の実施形態では、操作９０８はカスタムクレーム変換サブモジュール、例えば３０４を生成して、入来クレーム２１４のクレームフォーマットから予め決められたリソースアプリケーション又はサービス２２２に必要なクレームフォーマットへクレームフォーマットを変更する。
【００３４】
フローは、生成操作９０８から、生成操作９０８内で生成されたカスタムクレーム変換サブモジュールが識別操作９０４内で識別された拡張ポイントの一部としてプラグインされる、プラグイン及び構成操作９１０に進む。１実施形態では、カスタムクレーム変換サブモジュール３０４は拡張性のある変換モジュール１２４、１２６、２０８および／又は２１６の一部としてパイプライン形式で構成された他のカスタムクレーム変換サブモジュールと共にプラグインされる。別の実施形態では、カスタムクレーム変換サブモジュール３０４は、図６を参照して上で説明、議論したように、そのような処理に対して適切であると判定されたそれらのサブモジュールに対してのみ変換のためのクレームを送信するように構成されている拡張性のある変換、例えば１２４、の一部としてプラグインされることができる。その他の実施形態は追加の、および／又は異なる構成を含むことができるが、本明細書に記述されたタイプは決して制限するものと解釈してはならない。更に、変換３０４又は１２４への参照は、例示的な目的のためだけである。変換モジュール又はサブモジュールはいずれも使用可能である。終了プロセス９１２がプロセス９００を終了させる。
【００３５】
本明細書に記述し、説明したシステムおよび方法を実装する例示的なコンピューティング環境を図１０に示す。非常に基本的な構成では、コンピューティングシステム１０００は一般に、少なくとも１つのＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１００２、および１実施形態でのアカウントストア２０２と同様にセキュリティトークン１０８内にクレーム情報を格納するというようなメモリ１００４を含む。コンピューティング装置の正確な構成とタイプにより、メモリ１００４は揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭ、フラッシュメモリ等）、又はその２つのなんらかの組み合わせであることができる。あるいは、コンピューティング装置１０００は、追加の特徴／機能性を有することもできる。例えば、コンピューティング装置１０００は、複数のＣＰＵを含むことができる。記述した方法は、コンピューティング装置１０００内のどの処理ユニットによっても如何なる方法によっても実行可能である。例えば、記述したプロセスは複数のＣＰＵによって並行して実行できる。
【００３６】
コンピューティング装置１０００は、１実施形態によるアカウントストア２０２と同様にセキュリティトークン１０８内にクレーム情報を格納するための、限定はしないが、磁気もしくは光ディスク又はテープを含む追加のストレージ１００６（取り外し可能、および／又は取り外し不能）も含むことができる。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータ等の情報の格納のために任意の方法又は技術で実装された、揮発性及び不揮発性、取り外し可能及び取り外し不能媒体を含む。メモリ１００４およびストレージ１００６は、全てコンピュータストレージ媒体の例である。コンピュータストレージ媒体は、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋｓ）又は他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又は他の磁気ストレージ装置、又は所望の情報を格納するのに使用でき、コンピューティング装置１０００によりアクセス可能な任意のその他の媒体を含む。そのようなコンピュータストレージ媒体はいずれもコンピューティング装置１０００の一部になることができる。
【００３７】
本発明の１実施形態に従って、コンピューティング装置１０００は、信頼パートナー１０２と１０４との間において、セキュリティトークン１０８内のクレーム情報を送信するというような、他の装置と通信することを可能にする通信装置（複数）１０１２も含むことができる。通信装置（複数）１０１２は、通信媒体の一例である。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、又は搬送波等の変調データ信号もしくは他のトランスポート機構における他のデータを具現化し、任意の媒体を含む。「変調データ信号」という用語は、１又は複数の自己の特性セットを有する信号、又は信号中の情報を符号化するといった方法で変更された信号を意味する。例をあげれば、限定するものではないが、通信媒体は、有線ネットワーク（例えば、１実施形態に従って示されるネットワーク１０５又は１０６）、又は直接有線接続等の有線媒体、および音響、ＲＦ、赤外線および他の無線媒体等の無線媒体を含む。本明細書で使用するコンピュータ可読媒体という用語は、コンピュータストレージ媒体および通信媒体の両方を含む。記述した方法は、いかなるコンピュータ可読媒体でも、データ、コンピュータ実行可能命令等の任意の形態で符号化することができる。
【００３８】
コンピューティング装置１０００は又、キーボード、マウス、ペン、音声入力装置、タッチ入力装置等の入力装置（複数）１０１０を有することができる。更に、表示装置、スピーカ、プリンタ等の出力装置（複数）１００８も含むことができる。これらの装置は、当業者には周知のものであり、詳細に議論する必要はない。コンピューティング装置１０００のコンポーネントに関して特定の例が与えられているが、これらの例は決して限定することは意図していない。
【００３９】
上に提供した開示を考慮すると、本発明が多数の利点を提供するということは当業者にとっては容易に明らかになる。例えば、クレーム又はクレームセットの単一認証のために図４、図５および図６を参照して議論した複数の変換サブモジュールを呼び出すことができるのは、機能を統合する目的には有益である。本発明は、図４、図５および図６で描かれているように、クレーム変換コードを、例えば、複数のモジュール又はサブモジュールに分割して、コアランタイムライブラリの異種のバージョンと共に統合するという能力においても有利である。本発明では、複数のカスタムクレーム変換モジュール又はサブモジュールが、変換モジュール２０８および／又は２１６の拡張ポイントでプラグインできるようにしているので、本発明はサードパーティのクレーム変換モジュール又はサブモジュールをシステムにプラグインすることができる。更に本発明は、例えば図５および図６に描かれているように、および上述のように順方向連鎖変換のための定常状態を判定する構成概念の導入を可能にする。
【００４０】
更に本発明は、複数のセキュリティの特徴を提供において有益である。例えば、変換チェック操作５２２および６１８として示し、記述しているように、他の変換の最後に動作することが保証されている追加のクレーム変換モジュール又はサブモジュールを使用してクレームを完成させるという本発明の能力により、セキュリティの強化を実現する。例えば、評価操作６０６、および解析基準６２８、６３０ならびに６３２に関して示し、記述しているように、各変換モジュールはどのクレーム（複数）又はクレームセット（複数）を操作することを許可されているかを制御する管理者の能力の中にセキュリティの特徴の追加が提供されている。図７および図８に示すように、セキュリティの特徴はさらに本開示の１実施形態に関連づけられており、変換モジュール又はサブモジュール各々が元のクレーム又はクレームセットのコンテキストでのみ動作するように、結果のクレームセットは変換モジュール又はサブモジュール各々とは分離されている。次いでそのシステムは結果クレームを維持して統合する。最終クレーム又はクレームセットの制御を保持することによりセキュリティを提供する能力において、そのようなシステムは有益である。
【００４１】
上図を参照して本開示の実施形態を記述したが、当然のことながら、すぐに当業者の念頭に浮かび、開示した本発明の範囲と精神に含まれ、かつ添付した特許請求の範囲に定義されているような多数の修正を本発明に対して行うことができる。事実、現在好適な実施形態は、本開示の目的のために記述されているが、十分本発明の範囲内にある変更や修正を多数行うことができる。
【００４２】
同様にして、本開示は構造特徴、方法論的な行為、およびそのような行為を含むコンピュータ可読媒体に特有な言語を使用しているが、添付した特許請求の範囲で定義している本発明は、本明細書に記述されている特定の構造、行為、又は媒体に必ずしも限定されないことは理解されるべきである。例えば、本開示はリソースプロバイダを信頼関係のある信頼パートナーと呼んでいるが、どのようなタイプのパートナーでも本発明から利益を得ることができる。ほんの一例だが、リソースプロバイダはサービスプロバイダ又は信頼するパーティと呼ぶことができる。当業者であれば、本発明の範囲と精神内にある他の実施形態又は改善を認識できるであろう。従って、特定の構造、行為又は媒体は主張する発明を実装している例示的な実施形態として開示している。本発明は添付した特許請求の範囲により定義される。
【図面の簡単な説明】
【００４３】
【図１】本発明の１実施形態に従って、第１の組織はアイデンティティプロバイダ、および第２の組織はリソースプロバイダである２つの組織間で、アイデンティティデータおよび／又は認証に関係するデータからなる「クレーム」情報を共有するためのネットワーク環境の論理的表現を示す図である。
【図２】本発明の１実施形態に従って、１つの組織から別の組織へ、例えば図１に示すアイデンティティプロバイダからリソースプロバイダへのクレームデータのフローを示し、拡張性のあるクレーム変換モジュールを有する、一般的な認証環境を示す図である。
【図３】本発明の１実施形態に従って、図１に示すサンプル関係に加えての複数の信頼関係および複数のカスタムクレーム変換モジュールの使用を示すネットワーク環境の論理的表現を示す図である。
【図４】本発明の１実施形態に従って、図４の複数のカスタムクレーム変換モジュールを拡張ポイントの一部として、およびパイプライン形式で配置して描いた図である。
【図５】本発明の１実施形態に従って、図４に示す複数の、パイプライン状のカスタムクレーム変換サブモジュールの使用を通じて、クレーム情報を変換するプロセスの操作特性を示すフロー図である。
【図６】本発明の別の実施形態に従って、図３の複数のカスタムクレーム変換サブモジュールを含み、クレームを適切なカスタムクレーム変換サブモジュールへマッピングするプロセスの操作特性を示すフロー図である。
【図７】分離された結果クレームを統合するための図５に関連する別の実施形態を示す図である。
【図８】分離された結果クレームを統合するための図６に関連する追加の１実施形態を示す図である。
【図９】図３のカスタムクレーム変換サブモジュールの生成、プラグインおよび構成を含むプロセスの操作特性を示すフロー図である。
【図１０】本開示の実施形態を実装することができる、例示的なコンピュータシステムを示す図である。
【背景技術】
【０００１】
他と異なる個々のコンピュータシステムを持つ個々の組織では、お互いに、特に互いの従業員や顧客に効率よく情報を提供することをしばしば望んでいる。組織から情報を入手するために、ユーザは一般に、例えばユーザ名およびパスワードといった信用証明物を所有していることを証明することにより、情報を求める組織に対して自分のアイデンティティを認証又は証明することを要求される。しかしながら、個々の組織のウェブサイトより提供される情報にアクセスするために、例えばユーザ名やパスワードといった個々のセキュリティログオン信用証明物を要求する代わりに、個々の組織は情報を共有しアクセスするようお互いにビジネスレベルで合意することがある。連合認証システムは、パートナーが自分の連合サービスを展開することにより、情報を共有してアクセスできるようにしたシステムの例である。そのような情報を共有してアクセスするために、第１のパートナーはアイデンティティデータおよび／又は認証に関するデータを使用して、第２のパートナーに対して「クレーム」を作成することができる。そのような関係では、第２のパートナーは、第１のパートナーがユーザを認証し、そのユーザについてのあるクレームを作成するよう任せる。しかしながら、第２のパートナーは、第１のパートナーにより提示されたクレームを理解することができない場合もある。例えば、そのクレームが第２のパートナーが承認できるフォーマットになっていないこともある。組織が複数のパートナーと通信する場合、問題は深刻である。
【０００２】
この「背景技術」の元で特定の問題に取組んでいるが、本開示は決してそれらの特定の問題を解決することに限定するよう意図していない。
【０００３】
【特許文献１】米国特許出願第１１／１１９２３６号 （ＭＳ３１２１６１．０１）
【発明の開示】
【課題を解決するための手段】
【０００４】
本発明の実施形態は、一般的に信頼されたパートナー間で共有するためのクレーム又は認証情報の変換に関する。さらに、実施形態は連合システム内の複数のクレーム変換モジュールの使用に関する。
【０００５】
本明細書で議論するように、ある特定の実施形態の態様は、拡張ポイントの一部としての複数のカスタムクレーム変換モジュールの使用に関する。１実施形態では、複数のクレーム変換モジュールに、クレーム又はクレームセット上でパイプライン形式で作動して変換されたクレーム又はクレームセットを作成する機会を与えることができる。別の実施形態では、複数のクレーム変換モジュールが存在するが、適切なクレーム変換モジュール（単数又は複数）だけにクレーム又はクレームセット上で作動する機会を与える。
【０００６】
この「課題を解決するための手段」は、下記「発明を実施するための最良の形態」で詳細に記述する、概念の選択を簡易な形態で紹介するために提供される。この「課題を解決するための手段」は、特許請求の主題の主要な、又は本質的な特徴を特定することを意図しておらず、決して特許請求の主題の範囲を限定するために使用することを意図していない。
【発明を実施するための最良の形態】
【０００７】
本開示では、幾つかの実施形態を示す添付図面を参照して、幾つかの例示的実施形態についてより詳細に記述する。しかしながら、多数の異なる形態で具現化される他の態様もあり、本開示中の特定の実施形態を含めることは、そのような態様を本明細書で説明する実施形態に限定すると解釈してはならない。むしろ、図面に描かれた実施形態は、綿密でおよび完全ならびに当業者に意図している範囲を十分に伝える開示を提供するために含まれる。図面を参照する際、全体を通して示す同様の構造や要素は、同じ参照番号で指示される。
【０００８】
アイデンティティプロバイダ１０２とも呼ばれ、トークンがアイデンティティプロバイダ１０２により暗号を使用して署名され１つのクレーム又は複数のクレームを含むセキュリティトークン１０８を共有する第１の組織１０２を、リソースプロバイダ１０４とも呼ばれる第２の組織１０４と共に示す環境１００を図１に示す。本発明の１実施形態では「クレーム」と呼ぶが、本発明の別の実施形態に従ってセキュリティトークン１０８には単一のクレームを含むこともできる。この例示的な実施形態では、ユーザ１０３は、ネットワーク１０５上でアイデンティティプロバイダ１０２に送信される何らかの信用証明物を使用して認証を行う。ユーザは、リソースプロバイダ１０４に対して認証するのに使用することができるセキュリティトークン１０８を要求する。元の認証イベントを活用して、アイデンティティプロバイダ１０２は、ユーザについての様々なクレームを含むセキュリティトークン１０８を形成する。ユーザ１０３はセキュリティトークン１０８をリソースプロバイダ１０４に提示して、リソースプロバイダ１０４が、セキュリティトークンが信頼されたパーティにより発行され、そのパーティはその中でクレームを作成することを承認されたということを検証してから、そのリソースプロバイダ１０４は、それらのクレームに基づいたリソースへのアクセスを許可する。
【０００９】
１実施形態では、暗号を使用して署名されたセキュリティトークンは、アイデンティティプロバイダ１０２、又は「クレーム作成者（ｃｌａｉｍａｎｔ）」がリソースプロバイダ１０４に信頼されているという暗号化証明を構成する。このように、リソースプロバイダ１０４は、アイデンティティプロバイダ１０２がユーザ１０３を認証し、そのユーザについてのあるクレームを作成するよう任せる。リソースプロバイダ１０４がアイデンティティプロバイダ１０２を「信頼する」ので、この関係を「信頼関係」と呼ぶ。リソースプロバイダ１０４とアイデンティティプロバイダ１０２との間の信頼関係は、リソースプロバイダ１０４ドメインとアイデンティティプロバイダ１０２ドメインとの間の論理的な関係としてこのように定義され、その関係においてリソースプロバイダ１０４はそのユーザ（複数）１０３についてのアイデンティティプロバイダ１０２のクレームを尊重する。「信頼関係」という用語を使用するが、この関係は決して相互的ではない。その代り、リソースプロバイダ１０４がアイデンティティプロバイダ１０２を信頼し、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、信頼パートナーと呼ばれる。
【００１０】
図１の例示的な実施形態において、組織１０２および１０４はこのように、リソースプロバイダ１０４に対して認証するのに使用できるセキュリティトークン１０８を、ネットワーク１０６上で組織１０４に送信するというような信頼関係を有する。図１に示す例示的な実施形態に従って、セキュリティトークン１０８が信頼されたパーティ、即ちアイデンティティプロバイダ１０２により発行されるリソースプロバイダ１０４に対してセキュリティトークン１０８は、ユーザ１０３を認証する。セキュリティトークン１０８に含まれるクレームは、ユーザ１０３の体験をカスタマイズするおよび／又は承認決定を行うことに対する認証を行った後で使用される。信頼関係はこのように、アイデンティティプロバイダ１０２とリソースプロバイダ１０４との間の異なった情報のフローを可能にする。情報のフローは存在するが、１実施形態では、セキュリティトークン１０８内で送信されたクレームは、共用する前にあるフォーマットから別のフォーマットに変換されている。セキュリティトークン１０８内のクレーム情報のこのような変換は、アイデンティティプロバイダ１０２のドメイン内の拡張ポイント１２４の一部として挿入されたクレーム変換モジュールを使用することにより行われる。単一のクレーム変換モジュールを使用することもできるが、拡張ポイントの一部として複数のクレーム変換モジュールをプラグインすることもできる。別の実施形態では、クレーム情報を拡張性のあるクレーム変換モジュール１２６の使用を通してネットワーク１０６上で送信した後、変換することができる。この実施形態の態様も、複数のクレーム変換モジュールの使用を可能にする。
【００１１】
図１は、アイデンティティプロバイダ１０２からリソースプロバイダ１０４へのクレーム情報１０８のフローを示す。本発明の１実施形態に従って、セキュリティトークン１０８内のクレーム情報は、クレームセット１１０として示すように、実際は特定のクレームのセットである。各々のクレームは、一般に特定の人又はユーザに関する識別情報に関する。例えば、あるクレームはユーザ名１１２を含むことができ、別のクレームはユーザの電子メールアドレスを含むことができる。他のクレームは、ユーザの従業員識別番号１１６、社会保障番号１１８、例えば髪の色等の身体的特徴１２０、その他１２２に関することができる。セキュリティトークン１０８内に含まれるクレーム情報は、ユーザの体験をカスタマイズする、および／又は承認決定をするために使用する。とは言っても以下で議論するように、クレームのフォーマット（又は内容）を、リソースプロバイダに依存して修正することができる。１実施形態では、アイデンティティプロバイダ１０２のユーザに対するアカウントを検証又は認証するために、クレームはリソースプロバイダ１０４により使用される。図１に示すセキュリティトークン１０８内に含まれる複数のクレームを有する実施形態もあれば、単一のクレームからなるフローを伴う実施形態もある。
【００１２】
上述のように本発明の実施形態では、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は信頼パートナーである。アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、例えば、ほんの一例としては、会社、企業、個人等 エンティティのいずれのタイプであってもよい。認識されているように、どのようなコンピュータシステムでも、そのようなエンティティとして動作できる。同様に、認識されているように、そのようなエンティティ間の信頼関係は当業者には周知されている。一般に、信頼関係は、組織のリソースへのアクセスを許可する前に、ユーザを認証するためにセキュリティ認証を要求する。ウェブサービス（ＷＳ）連合は、組織の境界を越えてアイデンティティ情報の共有を可能にする機構であり、各信頼パートナーは連合化されたサービスを展開して情報の共有やアクセスができるようにする。そのような信頼関係は、「連合」認証関係とも呼ばれ、クレームはネットワークを通じてアイデンティティプロバイダ１０２からリソースプロバイダ１０４へ「連合されている」と言うことができる。そのような共有を可能にするために、ＷＳ連合は一般にＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）セキュリティトークンを使用するが、そのようなセキュリティトークンはＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）又はＸｒＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｒｉｇｈｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のフォーマットを利用している。これらのセキュリティトークンは、限定はしないが、クレーム情報を含む。ＷＳ連合は、通信プロトコルを記述する仕様である。ＷＳ連合プロトコルは、マイクロソフト社製Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｆｅｄｅｒａｔｅｄ Ｓｅｒｖｉｃｅｓ（「ＡＤＦＳ」）により実装されている。
【００１３】
本発明の１実施形態では、アイデンティティプロバイダ１０２は拡張性のあるクレーム変換モジュール１２４を有し、１つのフォーマットからリソースプロバイダ１０４により指定されたフォーマットへクレーム情報の変換を遂行する。変換モジュール１２４が作動して、クレーム又はクレームセットを望ましいフォーマットへ変換する。同様に別の実施形態では、リソースプロバイダが複数の異なったアプリケーションを展開することもでき、そのようなアプリケーションは同じフォーマットで全てのセキュリティクレームを受信することはできない。ほんの一例だが、ユーザの誕生日を要求するリソースプロバイダのアプリケーションもあれば、ユーザの年齢を年数で要求するアプリケーションもある。従って、リソースプロバイダは、アイデンティティプロバイダにより提供されたクレームのフォーマットを、特定のリソースアプリケーションが要求するフォーマットに変換することが必要になる。したがって、１実施形態では、限定はしないが、アイデンティティプロバイダ１０２がリソースプロバイダ１０４に承認又は要求された適切なフォーマットでクレームを提供しない場合、又は特定のリソースアプリケーションのために、クレームのさらなる又は異なる変換を要求された場合を含む状況で、拡張性のあるリソースプロバイダクレーム変換モジュール１２６が使用される。実施形態において、アイデンティティプロバイダクレーム変換モジュールおよびリソースプロバイダクレーム変換モジュールは、信頼関係にある特定のアイデンティティプロバイダ１０２および特定のリソースプロバイダ１０４に対して（又は、同様に、特定のリソースアプリケーションに対して）このようにカスタマイズされ、「カスタム」クレーム変換モジュールとも呼ぶこともできる。
【００１４】
上述のように、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４は、ネットワーク１０６を通じて情報を共有してアクセスする。ネットワーク１０５および１０６は、従来当業者に周知のネットワークのいずれのタイプであってもよい。１例示的実施形態に従って、ネットワークはグローバルネットワーク（即ち、インターネット、又はワールドワイドウェブ）であることができる。ローカルエリアネットワーク、又は広域ネットワークの場合もある。別の実施形態では、組織が全体として個々の他と異なる管理のドメインを持つことになるが、ネットワークは例えばイントラネットのようなプライベートネットワークであることもできる。ネットワーク１０６は従来当業者に周知のネットワークのいずれのタイプであってもよいが、「ワールドワイドウェブ」（即ち、略して「ウェブ」）として１例示的実施形態に従って記述される。そのため、１又は複数の標準のパケットベースのフォーマット（例えば、Ｈ．３２３、ＩＰ、イーサネット、ＡＴＭ）に従って、ネットワーク１０６上の通信が発生する。
【００１５】
次に本発明の１実施形態に従って連合認証システムのさらに詳細な説明ついて見ると、図２はアイデンティティプロバイダ１０２とリソースプロバイダ１０４との間のネットワーク１０６を通じたクレームデータのフローを示す。ゼネラルフロー２００は、アイデンティティプロバイダ１０２側のアカウントストア２０２で始まるが、アイデンティティプロバイダ１０２がクレームを作成するのに使用するアイデンティティ情報をアカウントストア２０２が提供する。この実施形態では、アカウントストア２０２は、アイデンティティプロバイダ１０２に関連づけたアカウント（例えば、ユーザ）を認証するためのデータを管理するコンポーネントである。ほんの一例だが、アカウントストア２０２はＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ａｐｐｌｉｃａｔｉｏｎ Ｍｏｄｅ（ＡＤＡＭ）、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）システム、又は同様のシステムを含むことができる。
【００１６】
アカウントストア２０２は、セキュリティ情報と共にアカウント組織クレーム（「クレーム」）２０６をポピュレートする２０４。次いでクレーム２０６は、拡張性のあるアイデンティティプロバイダ変換モジュール２０８内で、アカウントストアに特有のフォーマットから、リソースプロバイダ１０４に承認された連合フォーマットに変換される。変換されたクレームは、セキュリティトークン１０８等のセキュリティトークン内にパッケージされる出力クレーム２１０として変換モジュール２０８から離れ、ネットワーク１０６上でリソースプロバイダ１０４に送信される２１２。出力クレーム２１０は入来クレーム２１４として、リソースプロバイダ１０４側に入る。「出力クレーム」２１０および「入来クレーム」２１４という用語を使用するが、そのようなクレームは例えばセキュリティトークン１０８等のセキュリティトークン内に含まれ、又はパッケージされると理解されるべきである。リソースプロバイダ側１０４でのさらなる処理の前に、セキュリティトークン１０８の暗号化署名は、発行者、即ち図１の例示的実施形態内のアイデンティティプロバイダ１０２がセキュリティトークン１０８内でクレームを作成することを任されていることを保証することを検証される。一旦検証されると、リソースプロバイダ側１０４で処理が継続される。セキュリティトークン１０８内のクレームのフォーマットは、リソースプロバイダ１０４により承認されたフォーマットに既に変換されているが、そのような変換が発生していない、又はさらなる変換が必要な実施形態では、拡張性のあるリソースプロバイダ変換モジュール２１６は入来クレーム２１４を、連合フォーマットから、リソース組織クレーム（「クレーム」）としてリソースアプリケーション２２２により承認されたフォーマットへ変換、又はさらに変換することができる。このステップはオプションと考えられるので、リソースプロバイダカスタムクレーム変換モジュール２１６は、図２では破線のフォーマットで示される。１実施形態では、アイデンティティプロバイダカスタムクレーム変換モジュール２０８もオプションと考えられる。別の実施形態では、リソースプロバイダカスタムクレーム変換モジュール２１６だけが、あるいは、アイデンティティプロバイダカスタムクレーム変換モジュール２０８だけがオプションと考えられる。クレームは次いでリソースアプリケーション２２２により使用するためにイネーブル２２０される。クレームデータの全てがリソースアプリケーション２２２に送付されないように、イネーブル２２０ステップはクレームデータのフィルタリングを含む。アイデンティティプロバイダおよびリソースプロバイダ変換モジュール２０８および２１６は、連合認証システム２００内で単一ブロックとして示されているが、これらの変換モジュールは議論したように、複数のクレーム変換モジュール又はサブモジュールの使用に対して拡張性ポイントになりうるということには留意すべきである。
【００１７】
図２のクレームデータのフローは、特定のアイデンティティプロバイダ１０２と特定のリソースプロバイダ１０４との間のものである。例えば、アイデンティティプロバイダ１０２側では、アイデンティティプロバイダ変換モジュール２０８は、入来するアカウント組織クレーム２０６をアカウントストア２０２に特定のフォーマットからリソースプロバイダ１０４により承認された連合フォーマットに変換する。この変換には１つ又は複数の中間ステップを含むことができる。その例示的な実施形態は、一般出願人マイクロソフト社に譲渡された、「特許文献１」に「Ｓｅｃｕｒｉｔｙ Ｃｌａｉｍ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ ｗｉｔｈ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｃｌａｉｍｓ」と題して記述され、その開示全体は本明細書に組み込まれている。本発明の実施形態に従って、その結果のクレーム情報を、複数のカスタムクレーム変換モジュール又はサブモジュールを使用して変換することができる。
【００１８】
実施形態のいくつかに従って、所与のアイデンティティプロバイダが連合に加わり、クレーム情報を幾つかの異なったリソースプロバイダに送信することができる。図２に戻ると、拡張性のあるクレーム変換モジュール、例えばアイデンティティプロバイダクレーム変換モジュール２０８、が図中に描かれているが、本発明の１実施形態はアイデンティティプロバイダ「Ａ」１０２側の拡張ポイントの一部として挿入された単一のカスタムクレーム変換モジュールの使用を含み、この変換モジュールは、そのアイデンティティプロバイダが信頼関係にある、予め決められたリソースプロバイダ「Ａ」１０４に承認されたフォーマットにクレームを変換するようにカスタマイズされている。しかしながら、アイデンティティプロバイダ「Ａ」１０２により異なったリソースプロバイダ「Ｂ」との新しい信頼関係が生成されると、アイデンティティプロバイダカスタムクレーム変換モジュールを変更して、新しいリソースプロバイダ「Ｂ」により、そしてその後は各々の新しいリソースプロバイダ「ｎ」により承認された連合フォーマットにクレームの変換をカスタマイズする必要がある。
【００１９】
複数の信頼関係およびカスタムクレーム変換モジュールがこのように可能であり、それらを図３においてネットワーク環境３００の論理的表現中に示す。アイデンティティプロバイダ「Ａ」１０２はリソースプロバイダ「Ａ」１０４と信頼関係があり、クレームはカスタムクレーム変換モジュールＴｘ１ ３０４により変換される。新しい信頼関係が、アイデンティティプロバイダ「Ａ」１０２と異なるリソースプロバイダ「Ｂ」３０２との間に生成され、クレーム変換モジュールはこの新しいペアに対して書き換えられＴｘ２ ３０６としてカスタマイズされる。そのような関係およびカスタムクレーム変換モジュールは、楕円３１２で示すように、不確定数のリソースプロバイダ「ｎ」３０８および対応するカスタムクレーム変換モジュールＴｘｎ ３１０まで存在することができる。同様に、可能なかぎり多数の予め決められた個々で他と異なるリソースアプリケーション２２２に対して変換されたある特定の連合フォーマットを入来クレームが有する一般的な連合認証システムのリソースプロバイダ側１０４で、複数の変換が必要となる。
【００２０】
しかしながら、対になるアイデンティティおよびリソースプロバイダ各々に対して単一のカスタムクレーム変換モジュールを有する代わりに、および新しいリソースプロバイダと各々新しい信頼関係を生成するとその単一のモジュールを変更しなければならない代わりに、本発明の実施形態は、連合認証システムの変換モジュール２０８および／又は２１６の拡張ポイントにプラグインされた複数のカスタムクレーム変換サブモジュールを有する。本明細書では「サブモジュール」という用語を使用するが、これらの「サブモジュール」は技術的に独立したエンティティであり、本発明の実施形態に従って単独、又は組み合わせて使用することができる。このように、「モジュール」という用語はこれらの独立したエンティティを記述するのに使用できる。しかしながら、「サブモジュール」という用語は、本明細書では拡張性のある変換モジュール２０８および／又は２１６全体を備えるそれらのモジュールを指すという単純な目的で使用する。図４について見ると、変換モジュールの実施形態４００を示し、変換モジュール２０８および／又は２１６の拡張ポイントにおいて、接続（又はパイプライン）形式でそのようなサブモジュールを連合認証システムにプラグインすることができる。これらのパイプライン状の変換サブモジュールを、次いでパイプライン形式で呼び出し、変換サブモジュール各々は適用可能な場所であるクレームセット上で動作して、リソースプロバイダの信頼パートナーへの送信用に結果のクレームセットを構築することができる。これら複数のカスタムクレーム変換サブモジュールは、パイプライン形式で呼び出され、１つのクレームセットを片付ける。上述のように、本発明の実施形態は単一のクレームを含むこともあれば、他の実施形態ではクレームセットを含むこともある。図４に示すように、入来するアカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）は、先ず変換サブモジュール１（「Ｔｘ１」）３０４により処理され、次いでＴｘ２ ３０６により処理され、というように「ｎ」個の異なった変換モジュールＴｘｎ ３１０に対してパイプライン形式で、出力クレーム２１０に向けて（又は別の実施形態ではイネーブル２２０に向けて）処理される。変換サブモジュール各々はパイプライン形式で呼び出されるが、要求された特定の変換のために書かれたそれらのサブモジュールだけが、実際にはクレーム、又はクレームセットに作用、即ちそれらを変換する。
【００２１】
図４に描かれた例示的な実施形態を参照すると、Ｔｘ１ ３０４がアイデンティティプロバイダ１０２からリソースプロバイダ１０４に承認されたフォーマットにクレームを変換するように書かれている場合、次いで入来クレームがアイデンティティプロバイダ１０２からのもので、出力クレーム２１０がリソースプロバイダ１０４に向かうものである場合だけ、そのクレームに作用する。例えば、アイデンティティプロバイダ１０２およびリソースプロバイダ３０２が関係しているが、Ｔｘ１ ３０４がアイデンティティプロバイダ１０２からリソースプロバイダ１０４にクレームを変換するように書かれている場合、Ｔｘ１ ３０４はそのクレームには作用せず、クレームは（図４に示すように）Ｔｘ２ ３０６に移る。同様に、Ｔｘ１ ３０４は入来クレーム２１４を特定の連合フォーマットで特定のリソースアプリケーション２２２に変換するように書かれ、一方Ｔｘ２ ３０６は異なる個々のリソースアプリケーションに対してそのような変換を生じさせるように書かれている場合もある。
【００２２】
図５に関しては、パイプライン形式で編成された複数のカスタムクレーム変換サブモジュールの使用を通じて、クレーム又はクレームセットを変換するプロセス５００が、本開示の１実施形態に従って示されている。ここでは、本発明の１実施形態に従って、クレームセットが変換されるが、その変換はクレームセット内の全てのクレームに適用されるものであり、個々のクレームに適用されるものではない。したがって、１実施形態では、幾つかのクレーム値に基づいて変更がなされるか、あるいは１つのクレームが結果として幾つかの新しいクレームになることもある。変換モジュール２０８および２１６は、一般的な意味では一定量のクレームの操作が可能だが、パイプライン形式で編成された複数のカスタムクレーム変換モジュール又はサブモジュールを使用することにより、クレームのこれらの操作をモジュール化することが可能となる。開始操作５０２で始まる操作フローを使用して変換プロセス５００が行われる。
【００２３】
開始操作５０２は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）のポピュレートに引き続いて開始される。プロセス５００の操作フローは、開始操作５０２から受信操作５０４に進む。受信操作５０４は、入来するアカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。操作フローは、受信操作５０４からカスタムクレーム変換操作Ｔｘ１ ５０６に移る。Ｔｘ１変換操作は、適用可能であればクレームを変換する。次いで操作はクエリ操作５０８に移る。クエリ操作５０８は、別のカスタムクレーム変換サブモジュールおよびその結果の変換操作が存在するかどうかを判定する。クエリ操作５０８が別のカスタムクレーム変換が存在すると判定する場合、フローはＹＥＳの方に分岐して、不定数のカスタムクレーム変換サブモジュールおよびクエリ操作のためにカスタムクレーム変換サブモジュールＴｘｎ５１０に進む。クエリ操作５０８で別のカスタムクレーム変換サブモジュールが検出されない場合、フローはＮＯに分岐して、何らかの変更がされたかどうかを判定するクエリ操作５１８に進む。変更が検出される場合、フローはＹＥＳの方に分岐してカスタムクレーム変換サブモジュールパイプラインを通して繰り返し処理するために受信操作５０４に戻る。変更に基づいたクレームの再処理は、１つの変換サブモジュールが、別のカスタムクレーム変換のそれとは矛盾した変更をするのを許可しないよう、セキュリティの特徴として作動する。
【００２４】
一方、クエリ操作５１８がクレームに対する変更を検出しない場合、定常状態が実現され変換プロセス５００の操作フローはＮＯの方に分岐して、終了操作５２０に進む。終了操作５２０は、変換プロセスを終了させる。セキュリティの特徴の追加として、変換チェッククエリ操作５２２を通して、操作フローを移し、いかなるカスタムクレーム変換サブモジュール（複数）によっても、矛盾する又はそうでなければ許可されない変更がされていないことを確認することも可能である。この最終チェックステップはオプションであり、したがって図５では破線フォーマットでクエリ操作５２２として示す。クエリ操作５２２が、最終チェックを十分ではない、即ち許可されない変更が存在すると判定する場合、フローはＮＯの方に分岐して修正操作５２４に進む。修正操作５２４は、矛盾する又は許可されない如何なるクレームも修正する。プロセス５００は、修正操作５２４から訂正したクレーム（又はクレームセット）を作成する作成操作５２６に進む。訂正されたクレーム又はクレームセットの作成に引き続いて、フローは、変更が再処理されるように処理を再スタートするべきかどうかを判定する再スタートクエリ５２８へ進む。再スタートクエリ５２８が再処理を行うべきと判定する場合、フローはＹＥＳの方に分岐して受信操作５０４に進む。再スタートクエリ５２８が再処理を行うべきでないと判定する場合、フローはＮＯの方に分岐して終了処理５２０に進む。同様にして、クエリ操作５２２が最終チェックは十分である、即ち変更が許可され、および／又は矛盾がないと判定する場合、フローはＹＥＳの方に分岐して終了操作５２０に進む。終了操作５２０は、変換プロセス５００を終了させる。そこから、出力クレームがネットワーク１０６を介してリソースプロバイダ１０４に送信される。あるいは、しかし同様に、リソースプロバイダ変換モジュール２１６により変換されたクレームは、リソースアプリケーション２２２のためにイネーブル２２０される。クレームをイネーブル２２０する際、必要であればクレームデータはフィルタリングされる。
【００２５】
次に図６を見ると、複数のカスタムクレーム変換モジュール又はサブモジュールを含むマッピングプロセス６００が、本開示の１実施形態に従って示される。マッピングプロセス６００とは、適切なカスタムクレーム変換サブモジュール（単数又は複数）だけが、セキュリティクレーム又はクレームセットに作用する機会が与えられている実施形態のことをいう。例えば、本発明の１実施形態に関して記述された連合認証システムのアイデンティティプロバイダ側１０２上の変換の場合、「適切な」とは特定のアイデンティティプロバイダおよび信頼関係に関与する一対となったリソースプロバイダのために書かれたそれらのカスタムクレーム変換サブモジュールのことを言う。同様に、一般的な連合認証システムリソースプロバイダ側１０４上の変換を含む別の実施形態でも、「適切な」とは、例えば、ある特定の連合クレームフォーマットおよび予め決められたリソースアプリケーション又はサービス２２２のために書かれたそれらの変換のことを言う。
【００２６】
アカウント組織クレーム２０６のポピュレート（又は別の実施形態では入来クレーム２１４の受信）に引き続いて開始される開始操作６０２で開始する操作フローを使用して行われる１例示的実施形態に従って、変換マッピングプロセス６００を記述する。上で議論したように、単一のクレームを含む実施形態もあれば、１つのクレームセットを含む別の実施形態もある。１つのクレームセットが変換される場合、その変換はそのクレームセット内のクレーム全てに適用される。開始操作６０２から、プロセス６００の操作フローは受信操作６０４に進む。受信操作６０４は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。操作フローは、受信操作６０４から評価操作６０６に移る。評価操作６０６は、適切なカスタムクレーム変換サブモジュール、すなはちＴｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２のいずれに、変換のためにクレームを送信すべきかを判定する。本発明の１実施形態に従って、楕円６１１で示されるように、１又は複数のクレーム変換サブモジュールが使用できる。どのカスタムクレーム変換サブモジュールが適切かを判定するために、評価操作６０６はクレームを解析して６２６、マッピング選択６２８を調べ、もしあれば変更（受信操作６０４で受信したクレームが既に変換されている実施形態では変更が既になされている）を比較６３０する、等を行う。更に、１つ以上の変換サブモジュールが「適切」で１実施形態では、そのような適切なクレーム変換サブモジュール各々はクレーム上で動作する機会が与えられていることを、評価操作６０６は保証している。例えば、１実施形態では、評価操作６０６は適切なカスタムクレーム変換モジュールを判定する。そして１つ以上のそのようなモジュールが適切であると思われる場合、万一クレームが同じカスタムクレーム変換サブモジュールに繰返し送信される場合そうなる可能性のある、定常状態変化の間違った出現が起こらないように、評価操作６０６はクレームを交互方式６３２で適切なカスタムクレーム変換サブモジュールに送信する。
【００２７】
クレームを送信すべき適切な変換サブモジュールを判定すると、クレームはＴｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２に送信される。カスタムクレーム変換Ｔｘ１ ６０８、Ｔｘ２ ６１０、．．．Ｔｘｎ ６１２に引き続いて、操作はクエリ操作６１４に進む。クエリ操作６１４は、クレームに対して何らかの変更が行われたかどうかを判定する。クエリ操作がクレームに対する変更が存在すると判定する場合、フローはＹＥＳの方に分岐して受信操作６０４に進み、次いで評価操作６０６に進み、そこでクレームは再び解釈され６２６、マッピングが評価され６２８、変更が比較され６３０、交互方式の「適切な」変換サブモジュールパターンが、もしあれば、検出される６３２、等が行われる。
【００２８】
クエリ操作６１４が、クレームの変更が存在せず、定常状態が達成されたことを判定するまで、この操作フローは繰り返される。変更が存在しないとクエリ操作６１４が判定する場合、フローはＮＯの方に分岐して終了操作６１６に進む。セキュリティの特徴の追加として、変換チェッククエリ操作６１８を通して操作フローを移し、矛盾した又はそうでなければ許可されない変更がカスタムクレーム変換サブモジュール（複数）によりなされていないことを確認することも可能である。この最終チェックステップはオプションであり、したがって図６では破線フォーマットでクエリ操作６１８として示す。クエリ操作６１８が、最終チェックは十分でない、即ち許可されない変更（複数）が存在すると判定する場合、フローはＮＯの方に分岐して訂正操作６２０に進む。訂正操作６２０は、矛盾する又は許可されない如何なる変更も訂正する。プロセス６００は、訂正操作６２０から訂正されたクレーム（又は１実施形態ではクレームセット）を作成する作成操作６２２に進む。訂正されたクレームの作成に引き続いて、フローは、変更が再処理されるように処理を再スタートすべきかどうかを判定する再スタートクエリ６２４へ進む。再スタートクエリ６２４が再処理を行うべきであると判定する場合、フローはＹＥＳの方に分岐して受信操作６０４に進む。再スタートクエリ６２４が、再処理を行うべきでないと判定する場合、フローはＮＯの方に分岐して終了操作６１６に進む。同様に、クエリ操作６１８が、最終チェックは十分である、即ち変更が許可されていると判定する場合、フローはＹＥＳの方に分岐して終了操作６１６に進む。終了操作６１６は変換プロセス６００を終了する。そこから、出力クレームはネットワーク１０６を介してリソースプロバイダ１０４に送信される。あるいは、しかし同様に、リソースプロバイダ変換モジュール２１６により変換されたクレームは、リソースアプリケーション２２２のためにイネーブル２２０される。クレームをイネーブル２２０する際に、必要であればクレームデータはフィルタリングされる。
【００２９】
当然のことながら、図５と図６に示した、従って本明細書に記述したプロセスは、一般的な連合認証システムのアイデンティティプロバイダ１０２側、又はリソースプロバイダ１０４側のどちらかでのクレームの変換に適用可能である。例えば、アイデンティティプロバイダ側の適切なクレーム変換サブモジュールにマッピングすることは、アイデンティティプロバイダ１０２およびリソースプロバイダ１０４のアイデンティティを判定することを含む。同様に、適切なリソースプロバイダクレーム変換サブモジュールにマッピングすることは、同様の判定プロセスを含むが、連合入来クレームのフォーマット、およびクレームを提供するよう意図する特定のリソースアプリケーション又はサービスが要求するフォーマットについての判定を含む。したがって、受信操作６０４は、本発明の実施形態に従って、アカウント組織セキュリティクレーム２０６、又は入来クレーム２１４に適用することができる。
【００３０】
次に図７、図８を見ると、本開示の例示的な実施形態に従ってプロセス７００およびプロセス８００が示されており、そこでは各変換サブモジュールが元のクレーム又はクレームセットのみに作用するように、各カスタムクレーム変換サブモジュールからの結果クレーム又はクレームセットが分離されている。次いでプロセス７００および８００は結果クレームを維持して統合する。開始操作７０２は、アカウント組織クレーム２０６のポピュレート（又はリソースプロバイダ側１０４を含む別の実施形態では入来クレーム２１４の送信）に応じて開始される。プロセス７００の操作フローは、開始操作７０２から受信操作７０４に進む。受信操作７０４は、アカウント組織クレーム２０６（又は別の実施形態では入来クレーム２１４）を受信する。フローは、受信操作７０４から、適用可能であれば、クレームを結果クレーム１ ７０８に変換するカスタム変換操作Ｔｘ１ ７０６に移る。元のクレームの変更されていない形式は、適用可能であれば、クレームを結果クレーム２ ７１２に変換するＴｘ２ ７１０に移る。本発明の実施形態に従って、楕円７１１と楕円７１３で示すように、単一の変換モジュール７０６又は「ｎ」個の変換モジュール７１４、および単一の結果クレーム７０８又は「ｎ」個の結果クレーム７１６が使用できる。元のクレームは、パイプライン形式でＴｘｎサブモジュール７１４および結果クレーム「ｎ」７１６に移る。結果クレーム７０８、７１２および７１６は維持されて、次いでフローは、結果クレームを統合して最終的なクレーム又はクレームセットを作成する７２０統合操作７１８に進む。終了操作７２２がプロセスを終了させる。
【００３１】
同様に、プロセス８００は、上記の開始操作７０２に関しての記述と同様に開始される開始操作８０２で開始する。次いで操作フローはまた、上記受信操作７０４についての記述と同様に、受信操作８０４に進む。操作フローは、受信操作８０４から、元のクレームを送信すべき適切な変換サブモジュールを判定する評価操作８０６（上記図６に記述され描かれているように）に移る。本発明の実施形態に従って、楕円８１５と楕円８１７で示すように、単一の変換サブモジュール８０８又は「ｎ」個の変換サブモジュール８１６、および単一の結果クレーム８１０又は「ｎ」個の結果クレーム８１８が使用できる。次いで変換サブモジュールＴｘ１ ８０８、Ｔｘ２ ８１２、．．．Ｔｘｎ ８１６が、元のクレーム又はクレームセット上で分離して動作して、結果クレーム８１０、８１４および８１８をそれぞれ作成する。操作は、結果クレームを統合して最終クレーム又はクレームセットを作成する８２２統合操作８２０に進む。終了操作８２４がプロセスを終了させる。図７とプロセス７００について記述したように、図８に関する別の実施形態は受信操作８０４への入来クレーム２１４を含み、入来クレーム２１４は図２で描かれているリソースプロバイダ１０４側に存在している。
【００３２】
当然のことながら、本発明の他の実施形態は、定常状態操作を実現するために、例えばクレームの変更に関するチェックを許可するようにプロセス７００およびプロセス８００に追加する追加のステップを提供することができる。プロセス７００およびプロセス８００は、カスタムクレーム変換サブモジュール各々から結果クレーム又はクレームセットを分離するコンセプトを示すように、一般化された形式で示されている。その他の図に関しては、図７および図８の一般化された形式は、本明細書で描かれ、又は記述された特定のステップに限定されると決して解釈されてはならない。
【００３３】
図９に示す１実施形態の態様に従って、図１および図３を参照して上で議論したように、組織はクレーム要件および変換能力をカスタマイズすることができる。それに関するフロー操作を図９に示す。プロセス９００は開始操作９０２で開始するが、図１および図２に特定の実施形態として描かれているように、拡張性のある認証システムとの信頼環境の生成に応じて開始操作９０２は開始される。フローは、拡張ポイント１２４、１２６、２０８および／又は２１６の存在を識別する識別操作９０４に進む。１実施形態においては、フローは識別操作９０４から、アイデンティティプロバイダ１０２のクレームフォーマット、およびリソースプロバイダ１０４に必要な又は好ましいクレームフォーマットを判定するフォーマット判定操作９０６に進む。図２に示すクレームデータのフローのリソースプロバイダ１０４側を含む別の実施形態においては、フォーマット判定操作９０６は、入来クレーム２１４のクレームフォーマットおよび予め決められたリソースアプリケーション２２２に必要なフォーマットを判定する。フォーマット判定操作９０６に引続き、フローはカスタムクレーム変換サブモジュール生成操作９０８に進む。１実施形態に従って、生成操作９０８はカスタムクレーム変換サブモジュール、例えば、３０４、３０６又は３１０を生成し、アイデンティティプロバイダ１０２のクレームフォーマットからリソースプロバイダ１０４に必要な又は好ましいクレームフォーマットにクレームフォーマットを変更する。別の実施形態では、操作９０８はカスタムクレーム変換サブモジュール、例えば３０４を生成して、入来クレーム２１４のクレームフォーマットから予め決められたリソースアプリケーション又はサービス２２２に必要なクレームフォーマットへクレームフォーマットを変更する。
【００３４】
フローは、生成操作９０８から、生成操作９０８内で生成されたカスタムクレーム変換サブモジュールが識別操作９０４内で識別された拡張ポイントの一部としてプラグインされる、プラグイン及び構成操作９１０に進む。１実施形態では、カスタムクレーム変換サブモジュール３０４は拡張性のある変換モジュール１２４、１２６、２０８および／又は２１６の一部としてパイプライン形式で構成された他のカスタムクレーム変換サブモジュールと共にプラグインされる。別の実施形態では、カスタムクレーム変換サブモジュール３０４は、図６を参照して上で説明、議論したように、そのような処理に対して適切であると判定されたそれらのサブモジュールに対してのみ変換のためのクレームを送信するように構成されている拡張性のある変換、例えば１２４、の一部としてプラグインされることができる。その他の実施形態は追加の、および／又は異なる構成を含むことができるが、本明細書に記述されたタイプは決して制限するものと解釈してはならない。更に、変換３０４又は１２４への参照は、例示的な目的のためだけである。変換モジュール又はサブモジュールはいずれも使用可能である。終了プロセス９１２がプロセス９００を終了させる。
【００３５】
本明細書に記述し、説明したシステムおよび方法を実装する例示的なコンピューティング環境を図１０に示す。非常に基本的な構成では、コンピューティングシステム１０００は一般に、少なくとも１つのＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１００２、および１実施形態でのアカウントストア２０２と同様にセキュリティトークン１０８内にクレーム情報を格納するというようなメモリ１００４を含む。コンピューティング装置の正確な構成とタイプにより、メモリ１００４は揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭ、フラッシュメモリ等）、又はその２つのなんらかの組み合わせであることができる。あるいは、コンピューティング装置１０００は、追加の特徴／機能性を有することもできる。例えば、コンピューティング装置１０００は、複数のＣＰＵを含むことができる。記述した方法は、コンピューティング装置１０００内のどの処理ユニットによっても如何なる方法によっても実行可能である。例えば、記述したプロセスは複数のＣＰＵによって並行して実行できる。
【００３６】
コンピューティング装置１０００は、１実施形態によるアカウントストア２０２と同様にセキュリティトークン１０８内にクレーム情報を格納するための、限定はしないが、磁気もしくは光ディスク又はテープを含む追加のストレージ１００６（取り外し可能、および／又は取り外し不能）も含むことができる。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータ等の情報の格納のために任意の方法又は技術で実装された、揮発性及び不揮発性、取り外し可能及び取り外し不能媒体を含む。メモリ１００４およびストレージ１００６は、全てコンピュータストレージ媒体の例である。コンピュータストレージ媒体は、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋｓ）又は他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又は他の磁気ストレージ装置、又は所望の情報を格納するのに使用でき、コンピューティング装置１０００によりアクセス可能な任意のその他の媒体を含む。そのようなコンピュータストレージ媒体はいずれもコンピューティング装置１０００の一部になることができる。
【００３７】
本発明の１実施形態に従って、コンピューティング装置１０００は、信頼パートナー１０２と１０４との間において、セキュリティトークン１０８内のクレーム情報を送信するというような、他の装置と通信することを可能にする通信装置（複数）１０１２も含むことができる。通信装置（複数）１０１２は、通信媒体の一例である。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、又は搬送波等の変調データ信号もしくは他のトランスポート機構における他のデータを具現化し、任意の媒体を含む。「変調データ信号」という用語は、１又は複数の自己の特性セットを有する信号、又は信号中の情報を符号化するといった方法で変更された信号を意味する。例をあげれば、限定するものではないが、通信媒体は、有線ネットワーク（例えば、１実施形態に従って示されるネットワーク１０５又は１０６）、又は直接有線接続等の有線媒体、および音響、ＲＦ、赤外線および他の無線媒体等の無線媒体を含む。本明細書で使用するコンピュータ可読媒体という用語は、コンピュータストレージ媒体および通信媒体の両方を含む。記述した方法は、いかなるコンピュータ可読媒体でも、データ、コンピュータ実行可能命令等の任意の形態で符号化することができる。
【００３８】
コンピューティング装置１０００は又、キーボード、マウス、ペン、音声入力装置、タッチ入力装置等の入力装置（複数）１０１０を有することができる。更に、表示装置、スピーカ、プリンタ等の出力装置（複数）１００８も含むことができる。これらの装置は、当業者には周知のものであり、詳細に議論する必要はない。コンピューティング装置１０００のコンポーネントに関して特定の例が与えられているが、これらの例は決して限定することは意図していない。
【００３９】
上に提供した開示を考慮すると、本発明が多数の利点を提供するということは当業者にとっては容易に明らかになる。例えば、クレーム又はクレームセットの単一認証のために図４、図５および図６を参照して議論した複数の変換サブモジュールを呼び出すことができるのは、機能を統合する目的には有益である。本発明は、図４、図５および図６で描かれているように、クレーム変換コードを、例えば、複数のモジュール又はサブモジュールに分割して、コアランタイムライブラリの異種のバージョンと共に統合するという能力においても有利である。本発明では、複数のカスタムクレーム変換モジュール又はサブモジュールが、変換モジュール２０８および／又は２１６の拡張ポイントでプラグインできるようにしているので、本発明はサードパーティのクレーム変換モジュール又はサブモジュールをシステムにプラグインすることができる。更に本発明は、例えば図５および図６に描かれているように、および上述のように順方向連鎖変換のための定常状態を判定する構成概念の導入を可能にする。
【００４０】
更に本発明は、複数のセキュリティの特徴を提供において有益である。例えば、変換チェック操作５２２および６１８として示し、記述しているように、他の変換の最後に動作することが保証されている追加のクレーム変換モジュール又はサブモジュールを使用してクレームを完成させるという本発明の能力により、セキュリティの強化を実現する。例えば、評価操作６０６、および解析基準６２８、６３０ならびに６３２に関して示し、記述しているように、各変換モジュールはどのクレーム（複数）又はクレームセット（複数）を操作することを許可されているかを制御する管理者の能力の中にセキュリティの特徴の追加が提供されている。図７および図８に示すように、セキュリティの特徴はさらに本開示の１実施形態に関連づけられており、変換モジュール又はサブモジュール各々が元のクレーム又はクレームセットのコンテキストでのみ動作するように、結果のクレームセットは変換モジュール又はサブモジュール各々とは分離されている。次いでそのシステムは結果クレームを維持して統合する。最終クレーム又はクレームセットの制御を保持することによりセキュリティを提供する能力において、そのようなシステムは有益である。
【００４１】
上図を参照して本開示の実施形態を記述したが、当然のことながら、すぐに当業者の念頭に浮かび、開示した本発明の範囲と精神に含まれ、かつ添付した特許請求の範囲に定義されているような多数の修正を本発明に対して行うことができる。事実、現在好適な実施形態は、本開示の目的のために記述されているが、十分本発明の範囲内にある変更や修正を多数行うことができる。
【００４２】
同様にして、本開示は構造特徴、方法論的な行為、およびそのような行為を含むコンピュータ可読媒体に特有な言語を使用しているが、添付した特許請求の範囲で定義している本発明は、本明細書に記述されている特定の構造、行為、又は媒体に必ずしも限定されないことは理解されるべきである。例えば、本開示はリソースプロバイダを信頼関係のある信頼パートナーと呼んでいるが、どのようなタイプのパートナーでも本発明から利益を得ることができる。ほんの一例だが、リソースプロバイダはサービスプロバイダ又は信頼するパーティと呼ぶことができる。当業者であれば、本発明の範囲と精神内にある他の実施形態又は改善を認識できるであろう。従って、特定の構造、行為又は媒体は主張する発明を実装している例示的な実施形態として開示している。本発明は添付した特許請求の範囲により定義される。
【図面の簡単な説明】
【００４３】
【図１】本発明の１実施形態に従って、第１の組織はアイデンティティプロバイダ、および第２の組織はリソースプロバイダである２つの組織間で、アイデンティティデータおよび／又は認証に関係するデータからなる「クレーム」情報を共有するためのネットワーク環境の論理的表現を示す図である。
【図２】本発明の１実施形態に従って、１つの組織から別の組織へ、例えば図１に示すアイデンティティプロバイダからリソースプロバイダへのクレームデータのフローを示し、拡張性のあるクレーム変換モジュールを有する、一般的な認証環境を示す図である。
【図３】本発明の１実施形態に従って、図１に示すサンプル関係に加えての複数の信頼関係および複数のカスタムクレーム変換モジュールの使用を示すネットワーク環境の論理的表現を示す図である。
【図４】本発明の１実施形態に従って、図４の複数のカスタムクレーム変換モジュールを拡張ポイントの一部として、およびパイプライン形式で配置して描いた図である。
【図５】本発明の１実施形態に従って、図４に示す複数の、パイプライン状のカスタムクレーム変換サブモジュールの使用を通じて、クレーム情報を変換するプロセスの操作特性を示すフロー図である。
【図６】本発明の別の実施形態に従って、図３の複数のカスタムクレーム変換サブモジュールを含み、クレームを適切なカスタムクレーム変換サブモジュールへマッピングするプロセスの操作特性を示すフロー図である。
【図７】分離された結果クレームを統合するための図５に関連する別の実施形態を示す図である。
【図８】分離された結果クレームを統合するための図６に関連する追加の１実施形態を示す図である。
【図９】図３のカスタムクレーム変換サブモジュールの生成、プラグインおよび構成を含むプロセスの操作特性を示すフロー図である。
【図１０】本開示の実施形態を実装することができる、例示的なコンピュータシステムを示す図である。
【特許請求の範囲】
【請求項１】
クレームを１つのフォーマットから異なるフォーマットに変換するクレーム変換システムであって、
第１のクレーム変換サブモジュールと、
第２のクレーム変換サブモジュールと
を備え、
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、クレームを１つのフォーマットから複数の異なるフォーマットへ変換する能力を有することを特徴とするシステム。
【請求項２】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、パイプライン形式で配置されることを特徴とする請求項１に記載のクレーム変換システム。
【請求項３】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、前記クレームに対する変更が検出されなくなるまで前記クレームを変換するよう配置されることを特徴とする請求項２に記載のクレーム変換システム。
【請求項４】
前記システムは、他のサブモジュールによりなされた如何なる変更も許可しないかどうかを検証するクレーム変換サブモジュールをさらに備えることを特徴とする請求項３に記載のクレーム変換システム。
【請求項５】
前記第１のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第１の結果クレームを作成することと、
前記第２のクレーム変換サブモジュールは、元のフォーマットの前記クレームを処理して第２の結果クレームを作成することと、
統合モジュールは、前記第１の結果クレームおよび前記第２の結果クレームを統合して最終クレームを作成すること
を特徴とする請求項１に記載のクレーム変換システム。
【請求項６】
前記第１のクレーム変換サブモジュールは前記処理に適切であると判定される場合、前記システムは前記クレームを前記第１のクレーム変換サブモジュールに向けること、
前記第２のクレーム変換サブモジュールは前記処理に適切であると判定される場合、前記システムは前記クレームを前記第２のクレーム変換サブモジュールに向けること
を特徴とする請求項１に記載のクレーム変換システム。
【請求項７】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、変更が検出されなくなるまで前記クレームを変換することを特徴とする請求項６に記載のクレーム変換システム。
【請求項８】
前記システムは、他のサブモジュールによりなされた如何なる変更も許可しないかどうかを検証するクレーム変換サブモジュールをさらに備えることを特徴とする請求項７に記載のクレーム変換システム。
【請求項９】
前記第１のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第１の結果のクレームを作成することと、
前記第２のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第２の結果のクレームを作成することと、
統合モジュールは、前記結果クレームを統合して最終クレームを作成すること
を特徴とする請求項６に記載のクレーム変換システム。
【請求項１０】
信頼関係環境内の拡張ポイントでクレームを変換する方法であって、
信頼関係環境内で拡張ポイントを維持するステップであって、単一のクレーム変換サブモジュール又は複数のクレーム変換サブモジュールをプラグインできるステップと、
前記クレームの第１のフォーマットを判定するステップと、
前記クレームの第２のフォーマットを判定するステップと、
前記クレームフォーマットを前記第１のフォーマットから前記第２のフォーマットに変更するようにカスタマイズされたクレーム変換サブモジュールを生成するステップと、
前記変換サブモジュールを前記拡張ポイントにプラグインするステップと
を含むことを特徴とする方法。
【請求項１１】
前記方法は、前記拡張ポイントの一部として前記サブモジュールをパイプライン状に構成するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記方法は、追加のサブモジュールをプラグインするステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記方法は、前記クレームを送信すべき適切なクレーム変換モジュールを判定するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１４】
前記方法は、定常状態が達成されるまで前記クレームを処理するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１５】
クレームセットが含まれること、および前記変換を前記クレームセット内のクレーム全てに適用することを特徴とする請求項１０に記載の方法。
【請求項１６】
元のフォーマットの前記クレームをクレーム変換モジュールに送信して前記クレームを結果クレームに変換するステップと、
クレーム変換サブモジュールからの前記結果クレームを、他のクレーム変換サブモジュールからの前記結果クレームから分離するステップと、
前記結果クレームを集めるステップと、
前記結果のクレームを統合して最終クレームを作成するステップと
をさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１７】
信頼関係においてクレーム情報を共有して変換する拡張性のあるシステムであって、
アカウントを認証する情報を要求するリソースプロバイダと、
前記リソースプロバイダに認証情報を提供するアイデンティティプロバイダと、
認証情報を維持して前記要求するリソースプロバイダに送信するクレームをポピュレートするアカウントストアと、
拡張ポイントであって、１又は複数のクレーム変換サブモジュールをそのようなポイントの一部としてプラグインして、前記アイデンティティプロバイダにより提供される第１のフォーマットから前記リソースプロバイダにより承認される第２のフォーマットへクレームを変換することができる拡張ポイントと
をさらに備えることを特徴とするシステム。
【請求項１８】
前記クレーム変換サブモジュールがパイプライン形式で配置されることを特徴とする請求項１７に記載の拡張性のあるシステム。
【請求項１９】
前記クレームを処理するために適切と思われる前記クレーム変換サブモジュールにのみ前記クレームを送信することを特徴とする請求項１７に記載の拡張性のあるシステム。
【請求項２０】
前記アイデンティティプロバイダから受信したクレームの前記フォーマットをリソースアプリケーションに承認されるフォーマットに変換するために、追加の拡張ポイントが存在することを特徴とする請求項１７に記載の拡張性のあるシステム。
【請求項１】
クレームを１つのフォーマットから異なるフォーマットに変換するクレーム変換システムであって、
第１のクレーム変換サブモジュールと、
第２のクレーム変換サブモジュールと
を備え、
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、クレームを１つのフォーマットから複数の異なるフォーマットへ変換する能力を有することを特徴とするシステム。
【請求項２】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、パイプライン形式で配置されることを特徴とする請求項１に記載のクレーム変換システム。
【請求項３】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、前記クレームに対する変更が検出されなくなるまで前記クレームを変換するよう配置されることを特徴とする請求項２に記載のクレーム変換システム。
【請求項４】
前記システムは、他のサブモジュールによりなされた如何なる変更も許可しないかどうかを検証するクレーム変換サブモジュールをさらに備えることを特徴とする請求項３に記載のクレーム変換システム。
【請求項５】
前記第１のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第１の結果クレームを作成することと、
前記第２のクレーム変換サブモジュールは、元のフォーマットの前記クレームを処理して第２の結果クレームを作成することと、
統合モジュールは、前記第１の結果クレームおよび前記第２の結果クレームを統合して最終クレームを作成すること
を特徴とする請求項１に記載のクレーム変換システム。
【請求項６】
前記第１のクレーム変換サブモジュールは前記処理に適切であると判定される場合、前記システムは前記クレームを前記第１のクレーム変換サブモジュールに向けること、
前記第２のクレーム変換サブモジュールは前記処理に適切であると判定される場合、前記システムは前記クレームを前記第２のクレーム変換サブモジュールに向けること
を特徴とする請求項１に記載のクレーム変換システム。
【請求項７】
前記第１のクレーム変換サブモジュールおよび前記第２のクレーム変換サブモジュールは、変更が検出されなくなるまで前記クレームを変換することを特徴とする請求項６に記載のクレーム変換システム。
【請求項８】
前記システムは、他のサブモジュールによりなされた如何なる変更も許可しないかどうかを検証するクレーム変換サブモジュールをさらに備えることを特徴とする請求項７に記載のクレーム変換システム。
【請求項９】
前記第１のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第１の結果のクレームを作成することと、
前記第２のクレーム変換サブモジュールは、元のフォーマットの前記クレームを変換して第２の結果のクレームを作成することと、
統合モジュールは、前記結果クレームを統合して最終クレームを作成すること
を特徴とする請求項６に記載のクレーム変換システム。
【請求項１０】
信頼関係環境内の拡張ポイントでクレームを変換する方法であって、
信頼関係環境内で拡張ポイントを維持するステップであって、単一のクレーム変換サブモジュール又は複数のクレーム変換サブモジュールをプラグインできるステップと、
前記クレームの第１のフォーマットを判定するステップと、
前記クレームの第２のフォーマットを判定するステップと、
前記クレームフォーマットを前記第１のフォーマットから前記第２のフォーマットに変更するようにカスタマイズされたクレーム変換サブモジュールを生成するステップと、
前記変換サブモジュールを前記拡張ポイントにプラグインするステップと
を含むことを特徴とする方法。
【請求項１１】
前記方法は、前記拡張ポイントの一部として前記サブモジュールをパイプライン状に構成するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記方法は、追加のサブモジュールをプラグインするステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記方法は、前記クレームを送信すべき適切なクレーム変換モジュールを判定するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１４】
前記方法は、定常状態が達成されるまで前記クレームを処理するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１５】
クレームセットが含まれること、および前記変換を前記クレームセット内のクレーム全てに適用することを特徴とする請求項１０に記載の方法。
【請求項１６】
元のフォーマットの前記クレームをクレーム変換モジュールに送信して前記クレームを結果クレームに変換するステップと、
クレーム変換サブモジュールからの前記結果クレームを、他のクレーム変換サブモジュールからの前記結果クレームから分離するステップと、
前記結果クレームを集めるステップと、
前記結果のクレームを統合して最終クレームを作成するステップと
をさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１７】
信頼関係においてクレーム情報を共有して変換する拡張性のあるシステムであって、
アカウントを認証する情報を要求するリソースプロバイダと、
前記リソースプロバイダに認証情報を提供するアイデンティティプロバイダと、
認証情報を維持して前記要求するリソースプロバイダに送信するクレームをポピュレートするアカウントストアと、
拡張ポイントであって、１又は複数のクレーム変換サブモジュールをそのようなポイントの一部としてプラグインして、前記アイデンティティプロバイダにより提供される第１のフォーマットから前記リソースプロバイダにより承認される第２のフォーマットへクレームを変換することができる拡張ポイントと
をさらに備えることを特徴とするシステム。
【請求項１８】
前記クレーム変換サブモジュールがパイプライン形式で配置されることを特徴とする請求項１７に記載の拡張性のあるシステム。
【請求項１９】
前記クレームを処理するために適切と思われる前記クレーム変換サブモジュールにのみ前記クレームを送信することを特徴とする請求項１７に記載の拡張性のあるシステム。
【請求項２０】
前記アイデンティティプロバイダから受信したクレームの前記フォーマットをリソースアプリケーションに承認されるフォーマットに変換するために、追加の拡張ポイントが存在することを特徴とする請求項１７に記載の拡張性のあるシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００９−５３５７２９（Ｐ２００９−５３５７２９Ａ）
【公表日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願番号】特願２００９−５０９５６２（Ｐ２００９−５０９５６２）
【出願日】平成１９年３月１５日（２００７．３．１５）
【国際出願番号】ＰＣＴ／ＵＳ２００７／００６５７５
【国際公開番号】ＷＯ２００７／１３０２２６
【国際公開日】平成１９年１１月１５日（２００７．１１．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願日】平成１９年３月１５日（２００７．３．１５）
【国際出願番号】ＰＣＴ／ＵＳ２００７／００６５７５
【国際公開番号】ＷＯ２００７／１３０２２６
【国際公開日】平成１９年１１月１５日（２００７．１１．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．ＥＥＰＲＯＭ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]