JP6185934B2 - サーバー・アプリケーションと多数の認証プロバイダーとの統合 - Google Patents

Description

[0001] 多数の構内(on-premises)およびオンライン環境に跨がって分散されるサーバーおよびサービスの展開トポロジーは、増々複雑化しつつある。アプリケーションは、これらのサーバーおよびサービスの展開特性や位置には関係なく、これらを跨いだ安全なアクセスを要求する。通常、安全なアクセスの成功は、サーバーおよびサービスによる認証方式サポートによって左右される。通例、サーバーまたはサービスが他のサーバーまたはサービスに要求を行うとき、その要求が成功するように、どのようにそれを認証するか知る必要がある。

[0002] 成功する認証のために、サーバーおよびサービスは、OAuthプロトコルのような標準的な認証プロトコルを用いることができる。しかしながら、このような標準的なプロトコルは、サーバーおよびサービスの間で成功するためにはどのように信頼を築くか十分に記述していない。加えて、既存の認証プロトコルは、オンラインおよび構内環境にわたる複雑な展開トポロジーを考慮していない。

[0003] 例えば、OAuthプロトコルでは、多くの場合、全てのアプリケーションおよびサービスが認証のために信任状を取得するのに成功するには、１つの認証サーバーを信頼し(trust)それを頼りにする(rely on)ことが必要になる。しかしながら、多くのシナリオでは、この単一認証サーバーの概念を用いることができない。

[0004] 加えて、OAuthプロトコルはプロトコル・フローを詳細に記述するが、このプロトコルは当該プロトコルのセマンティクスおよび内容についての詳細を、認証サーバーの特定的な実施態様に委ねる(leave)。これが意味するのは、１つの認証サーバーと統合するサーバーまたはサービスは、異なる認証サーバーと統合する他のサーバーまたはサービスに要求を行うために、この同じ認証サーバーを首尾良く使用することには必ずしも頼ることができないということである。多くのシナリオでは、特に構内のシナリオでは、サーバーまたはサービスはいずれの認証サーバーとも全く統合することができない。

[0005] 最後に、認証に成功した後、サーバーおよびサービスは、通常、リソースを望ましくないアクセスから保護するために、認証メカニズムを実施する。通常、これらの認証メカニズムはサービスに固有であるが、認証のために問い合わせられる信任状の一部として提供される識別(identity)に基づく。OAuthプロトコルでは、クライアント・アプリケーションは、検証され信頼された識別である。クライアント・アプリケーションの識別が変化すると、認証を再構成しなければならず、新たなクライアント・アプリケーションの識別で検証されるまでは、認証は利用できない。

[0006] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いられることを意図するのでもない。

[0007] 実施形態は、OAuth2.0プロトコルのような、標準的な認証プロトコルを用いて認証に成功するための、サービスおよびサーバー・アプリケーションのための一般的なモデルを提供する。サーバーおよびサービスは、異なるプロトコル・セマンティクスを実現する多数の認証サーバーと統合することができる。他のサーバーおよびサービスというようなクライアントは、認証サーバーがない場合、証明書利用者(relying party)にアクセスするために標準的なプロトコルを用いることもできる。証明書利用者に対して認証するための信任状の適した発行元を選択することをクライアントに可能にする告知メカニズムが、証明書利用者に設けられる。

[0008] 本発明の実施形態の以上のおよびその他の利点や特徴を一層明確にするために、添付図面を参照して、本発明の実施形態の更に特定的な説明を行う。尚、これらの図面は、本発明の典型的な実施形態のみを描画し、したがってその範囲を限定するように解釈してはならないことは認められよう。添付図面の使用により、更に具体性および詳細を加えて、本発明について説明する。
図１は、容認可能な認証ソースを識別するために互いに通信する２つのサービスを示す。 図２は、認証信任状の信頼発行元(trusted issuer)を識別する方法またはプロセスを示す。 図３Ａは、発行元照合を用いてアウトバウンド・トークンの発行元を選択するアプリケーションのためのアウトバウンド・トークンの組み立て方法またはプロセスを示すフロー・チャートである。 図３Ｂは、発行元照合を用いてアウトバウンド・トークンの発行元を選択するアプリケーションのためのアウトバウンド・トークンの組み立て方法またはプロセスを示すフロー・チャートである。 図４は、図１から図３の例を実現することができる、適した計算およびネットワーキング環境の一例を示す。

[0013] 図１は、容認可能な認証ソースを識別するために互いに通信する２つのサービス１０１および１０２を示す。実施形態では、サービス１０１および１０２が同じサーバー上および／または同じ建造物(premise)上に配置されてもよく、同じアドミニストレーターによって構成されてもよい。他の実施形態では、サービス１０１および１０２が、別のサーバー上および／または別の建造物上に互いから離れて配置され、異なるアドミニストレーターによって構成されてもよい。このような構成では、サーバー１０１および１０２は、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、イントラネット、またはインターネットというような、ワイヤレスまたは有線ネットワークを通じて通信すればよい。これらの構成を本明細書では「構内」(on-premise)構成と呼ぶこともできる。サービス１０１および１０２がクラウドにおいてホストされる環境であり、別のホスティング組織によって管理される場合、この構成は、本明細書では、「オンライン」構成と呼ばれる。

[0014] サービス１０１および１０２は、異なるアプリケーションの別々のインスタンスであってもよく、または同じアプリケーションの別々のインスタンスであってもよい。いずれの場合でも、ユーザーがサービス１０１および１０２間において情報およびデーターを共有することを望むかもしれない。例えば、あるユーザーがサービス１０１上で作業することを望み、そしてサービス１０２上でアクションを実行するかまたはデーターをサービス１０２と交換することを望むかもしれない。サービスＡ１０１は、このようなアクションを実行する要求またはデーターを交換する要求１０３をサービスＢ１０２に送る。サービスＢ１０２が要求１０３に対して動作する前に、サービスＢ１０２は要求１０３を認証しなければならない。サービス１０１には、認証信任状またはトークンの承認済みソースを識別する信頼発行元リスト１０４が構成される。同様に、サービス１０２はそれ自体の信頼発行元リスト１０５を有する。信頼発行元リストは、例えば、１つ以上の認証サービス１０６、１０７を識別することができる。各サービス１０１および１０２は、それ自体の容認可能な認証サービスのリストを有することができる。例えば、サービス１０１は、認証サービス１０６および１０７を信頼するかもしれないが、サービス１０２は認証サービス１０７だけを信頼するかもしれない。

[0015] 直接信頼(direct-trust)の実施形態では、サービス１０１および１０２が自己認証するか、あるいはそれら自体の認証信任状またはトークンを作成できるのでもよい場合がある。

[0016] OAuthプロトコルのような標準的な認証プロトコルが、サービス１０１および１０２を互いに認証するために用いられてもよい。しかしながら、このようなプロトコルは常に好結果が得られる訳ではない。何故なら、サービス１０１および１０２は同じ認証サービス１０６、１０７を共有しないかもしれず、互換性のない認証構成を有するかもしれないからである。

[0017] サーバー１０２が要求１０３を受けると、４０１（無許可）応答１０８を返送する。この応答１０８は、要求１０３が認証を必要とすることを示す。クライアントは、適した認証ヘッダ・フィールドがある要求１０３を繰り返すことができる。認証フィールド値は、要求されるリソースの範囲に対するアプリケーションの認証情報を収容する信任状を含む(consist of)。

[0018] 一実施形態では、４０１−無許可応答１０８は、応答するサービス１０２からの信頼発行元リスト１０５を含む。したがって、応答１０８は、要求１０３が認証されなければならないことをサービス１０１に伝え、信頼されたソースのリストを供給し、サービス１０１は、このリストから、必要な認証信任状またはトークンを得ることができる。サービス１０１は、信頼されたまたは認証された認証サーバーのリスト１０４を有する。サービス１０１は、受信した信頼リスト１０５をそれ自体の信頼リスト１０４と比較し、これら２つのリスト間においてあらゆる一致を識別する。例えば、サービス１０１が認証サービス１０６および１０７を信頼し、サービス１０２が認証サービス１０７を信頼する場合、サービス１０１は、しかるべき信任状を得るために、認証サービス１０７を用いることができる。

[0019] サービス１０１および１０２に対する信頼発行元リスト１０４、１０５は、好ましい認証サービスのソースを識別することができる。例えば、信頼発行元リスト１０４は、（１）同じアプリケーションの他の展開(deployment)の直接信頼、（２）認証サービス１０５、および（３）認証サービス１０６として、ソースの優先順位を決める、または順位付けすることができる。一実施形態では、サービス１０１は、そのリスト１０４および受信したリスト１０５を比較し、最も好ましい発行元を選択する。

[0020] 図２は、認証信任状の信頼発行元を識別する方法またはプロセスを示す。ステップ２０１において、要求が第１サービスから第２サービスに送られる。ステップ２０２において、第１サービスは、この要求には認証が要求されることを示す応答を受信する。この応答は、第２サービスに対する信頼認証発行元のリストを含む。ステップ２０３において、第１サービスは、第２サーバーからの信頼発行元リストをそれ自体の信頼発行元リストと比較する。ステップ２０４において、第１サービスは、第１および第２サービス双方によって信頼される認証発行元を識別する。

[0021] ステップ２０５において、第１サービスは認証信任状を、双方のサービスから信頼される認証発行元から得る。ステップ２０６において、第１サービスは、この認証信任状を含む新たな要求を生成する。この認証信任状は双方のサービスによって信頼されるソースから来るので、第２サービスは通例第２要求を受け入れる。
構成
[0022] 信頼発行元識別プロセスに関与するためには、各サーバーまたはサービスにはしかるべき情報を構成しなければならない。一実施形態では、以下の情報がサーバーまたはサービス毎に構成される。

[0023] アプリケーション発行元識別子。アプリケーション発行元識別子は、自己発行トークンの発行元フィールドにおいて用いられる。アプリケーション発行元識別子は、PIDapp@realmというフォーマットを有する。アプリケーション発行元識別子の要求されるフィールドは、次のように定式化される。

[0024] PIDappフィールドは、アプリケーションの主要識別子である。一実施形態では、これは現在のアプリケーションを表すグローバル一意識別子(GUID)である。他の実施形態では、これらの識別子にわたって一意性を保証するのであれば、いずれの実施態様でも用いてもよい。Realmフィールドは、構内インストールではデフォルト・ドメインとすることができる。オンライン・インストールでは、Realm値は、テナント識別子とすればよい。しかしながら、テナント識別子は、Realmフィールドに可能な値の１つに過ぎず、何らかの他の値に設定されてもよい。

[0025] セキュリティ・トークン・サービス（ＳＴＳ）。１つ以上のＳＴＳもサーバーまたはサービス毎に構成される。各ＳＴＳはPIDsts@[TID] , metadataURLというフォーマットを有する。

[0026] PIDstsフィールドは、ＳＴＳを表すＧＵＩＤである。
[0027] TIDフィールドは、以下のように構成される。
構内インストールでは、TIDフィールドはテナント識別子(TenantID)であり、これは、ＧＵＩＤまたは特定のテナントを識別する一意性を保証するいずれかの実施態様(implementation)である。殆どのオンライン・インストールでは、TIDフィールドは空（または*）であり、しかるべきテナントＩＤで置き換えられなければならない。

特定のテナント内部のオンライン・インストールでは、異なる展開における同じカンパニー(company)を表すテナント間の信頼のために必要とされ、例えば、TIDフィールドはTenantIDである。

[0028] metadataURLフィールドは、ＳＴＳとの信頼確立のために証明書を引き出すために用いられるＵＲＬを収容する。
[0029] アプリケーションの中には、発行元識別子を格納せず、代わりに鍵、鍵識別子（例えば、証明書サムプリント）、およびメタデーターＵＲＬだけを格納するものがある。

[0030] 構成されたパートナー・アプリ(Configured Partner App)。構成されたパートナー・アプリは、PIDapp@f[realm] , {UseSTS|metadataURL}というフォーマットを有する。

[0031] PIDappフィールドは、他のサーバーまたはサービスのような、パートナー・アプリケーション（ＰＡ）を表すＧＵＩＤである。
[0032] Realmフィールドは、オンライン・インストールでは空（または*）であり、しかるべきテナントＩＤによって置き換えられなければならない。Realmフィールドは、構内インストールに対してデフォルト・ドメインを保持する。

[0033] UseSTSフィールドは、このＰＡに対する着信トークンが、構成されたＳＴＳの内の１つによって発行されなければならないか否か選択するために用いられる。
[0034] metadataURLフィールドは、アプリケーションとの直接信頼のために証明書を引き出すために用いることができるＵＲＬである。

[0035] アプリケーションの中には、発行元識別子を格納せず、代わりに、鍵、鍵識別子（例えば、証明書サムプリント）、およびメタデーターＵＲＬだけを格納するものがある。

[0036] 有効ドメインまたは領域リスト。信頼発行元リストは、オンラインおよび構内構成毎に構成される。オンライン・インストールでは、信頼発行元リストは、テナントによってマッピングされた全てのテナント・ドメイン・サフィックス(tenant domain suffix)のリストである。構内インストールでは、信頼発行元リストは、全ての有効なドメイン・サフィックスのリストである。

[0037] 一般に、空領域は、「*」領域と同じことを意味するように解釈される。「*」エントリーは、グローバル構成テンプレートをサポートするために用いられ、１つの構成されたエントリーが、数百万のテナントをサポートし、構成および格納要件を簡素化することができる。

[0038] 領域(realm)とはセキュリティ境界の識別子であり、ＰＩＤ（主要ＩＤ）は領域によって限定される(qualify)（即ち、領域に関して一意である）。ＴＩＤ（テナントＩｄ）は、領域に可能な値のストリングである。ＴＩＤは、データーセンターにおける領域の主要名称である。ＤＮＳドメイン名は、構内構成において用いられる領域に可能な他の値のストリングである。ＤＮＳドメイン名は、オーディエンス／リソース(audience/resource)において領域としてＳＴＳに送ることができるが、ドメイン名は、ＳＴＳが発行するトークンにおいてＴＩＤと置き換えられる。
発行元情報の公開
[0039] 発行元のリストは、認証を失敗した許可ヘッダにおいて、ベアラ方式(Bearer scheme)を有するあらゆる４０１応答において返送される。

[0040] 各アプリケーション・ホストは、信頼発行元のリストを作り、このリストから、トークンを受け入れる。一実施形態では、このリストは、以上の構成からの全てのＳＴＳ、および信頼のためにＳＴＳに依存しない全てのパートナー・アプリケーション（即ち、直接信頼を用いる全てのパートナー・アプリケーション）を含む。実施形態では、構成データーに発行元識別子を格納しないが代わりに鍵およびそれらの識別子だけを格納するアプリケーションは、発行元リストを作ることができない場合もある。

[0041] アプリケーションによって発行元リストを作ることができない場合、一実施形態では、アプリケーションはこの場合ではその識別子（例えば、client_id)および領域を返す。Realm値はテナント識別子であってもよい。発行元リストが作られる場合、領域は任意となり、通例、アプリケーション間を直接信頼とした（即ち、ＳＴＳなし）純粋な構内展開において、または４０１応答を生成したアプリケーションのエンドポイントＵＲＬから領域を明確に決定することができるときに、領域が供給される。

[0042] 例えば、要求は、
POST /resource HTTP/1.1
Authorization: Bearer
のようにフォーマットされてもよい。

[0043] ４０１応答は、以下のように、「WWW-Authenticate」ヘッダにおいて「ベアラ」認証方式の「trusted_issuers」パラメーターにおいて、コンマで分離された発行元のリストを搬送する。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer trusted_issuers="PIDsts @*,PIDapp@realm",
realm="realm", client_id="PID"
[0044] 構内インストールは、ＰＩＤ、領域、および証明書をメタデーター文書において公開し、ＳＴＳを用いずに構内インストール間における直接信頼の確立を容易にすることができる。オンライン・インストールでは、公開は必要でない。
アウトバウンド・トークンの組み立て
[0045] 図３Ａおよび図３Ｂは、アウトバウンド・トークンに発行元を選択するために発行元照合を用いるアプリケーションのためのアウトバウンド・トークンの組み立て方法またはプロセス３００を示すフロー・チャートである。プロセス３００は、以下の入力パラメーターを有する。

user@user-domainというフォーマットを有するユーザーまたはＵＲＩ。
パートナー・アプリ識別子（PIDpa）。
宛先ホスト（pahost）。

オンライン構成のみにテナントＩＤ（tid）。
グローバルＳＴＳ、および特定のテナントに対するエントリー（オンラインのみ）を含む、アウトバウンドＳＴＳのリスト。

[0046] ステップ３０１において、アプリケーションは、trusted_issuersパラメーターが、失敗した要求に対する回答において受信された４０１応答に収容されているか否か判定する。この要求は「Bearer」方式を有していた。ステップ３０２において、アプリケーションは、４０１応答メッセージにおいて、WWW-Authenticateヘッダのtrusted_issuersパラメーターから発行元のリスト（即ち、着信発行元リスト）を得る。４０１応答メッセージにおけるWWW-Authenticateヘッダにtrusted_issuersパラメーターが存在しない場合、本プロセスは３１２に移る。

[0047] ステップ３０３において、アプリケーションは、着信発行元リストにおける発行元の内１つが、ローカル・アプリケーション発行元識別子(PIDapp@realm)と一致するか否か判定する。一実施形態では、ＰＩＤおよび領域コンポーネントの全てが正確に、着信リスト上の発行元とローカル・アプリケーション発行元識別子との間で一致しなければならない。

[0048] ＰＩＤおよび領域コンポーネントがステップ３０３において一致した場合、本プロセスはステップ３０４に移り、自己発行トークンを作成する。自己発行トークンは、次のエレメントを含む。

iss: PIDapp@realm、
nameid: PIDapp@realm、
およびaud: PIDpa@target-realm/pahost@user-domain。

[0049] iss（発行元）およびnameid（名称識別子）エレメントは、ローカル・アプリケーション発行元識別子に対応する。aud（オーディエンス）エレメントは、パートナー・アプリケーション(PIDpa)、宛先ホスト(pahost)、およびユーザー・ドメイン(user-domain)に基づいて組み立てられる。taget-realmフィールドは、サービスがコールしようとしているアプリケーションの領域である。

[0050] ステップ３０３において、ローカル・アプリケーション発行元識別子との一致がない場合、本プロセスはステップ３０５に移る。ステップ３０５において、アプリケーションは、着信発行元リストにおける発行元の内１つが、STSを表すＧＵＩＤであるPIDstsのみを用いて構成されたＳＴＳの１つと一致するか否か判定する。アプリケーションは、この照合では、領域パラメーターを無視する。ステップ３０５において一致があった場合、ステップ３０６において、アプリケーションは、一致したＳＴＳの構成エントリーが空のＴＩＤを有するか否か判定する。

[0051] ステップ３０７において、一致したＳＴＳの構成エントリーが空でないＴＩＤを含む場合、アプリケーションは、一致したＳＴＳエントリーからのＴＩＤを、ＳＴＳのためにトークンを組み立てるときに領域パラメーターとして用いる。あるいは、ステップ３０８において、一致したＳＴＳの構成エントリーが空のＴＩＤを有する場合、アプリケーションは、先の入力パラメーターからのテナントＩＤを、ＳＴＳのためにトークンを組み立てるときに領域パラメーターとして用いる。

[0052] ステップ３０９において、アプリケーションはＳＴＳのために自己発行トークンを作成する。ＳＴＳのための自己発行トークンは、以下のパラメーターを含む。
iss: PIDapp@tid、
nameid: PIDapp@tid、
aud: PIDsts@tid/pahost@user-domain、および
resource: PIDpa @target-realm/pahost@user-domain。

[0053] iss／nameidPIDエレメント(PIDapp)は、アプリケーション発行元識別子から来る。領域エレメント(tid)は、ステップ３０７／３０８から選択され、構成されたＳＴＳ ＴＩＤまたは先の入力パラメーターからのテナントＩＤのいずれかに基づく。audPIDエレメント(PIDsts)は、ＳＴＳ構成エントリーから来る。リソース・エレメントは、パートナー・アプリケーションのＩＤ(PIDpa)およびユーザー・ドメインに基づく。

[0054] 自己発行トークンは、次に、ＳＴＳに供給され、ＳＴＳはステップ３１０において以下のパラメーターを用いてトークンを生成する。
iss: PIDsts@tid、
nameid: PIDapp@tid、および
aud: PIDpa@tid/desthost@tid。

[0055] ＳＴＳは、issエレメントに、それ自体のissuer@tenantIDを用いる。nameidエレメントの有効性が判断され、自己発行トークンからコピーされる。audエレメントの有効性が判断され、トークン要求パラメーターのリソース・エレメントからコピーされる。領域がＤＮＳドメインとして供給される場合、これは実際のテナントＩＤと置き換えられる。領域がテナントｉｄとして供給される場合、置き換えは不要である。

[0056] ステップ３０３および３０５において一致がない場合、トークンを作成することができず、本プロセスはステップ３１１において終了する。
[0057] ステップ３０１において、trusted_issuersパラメーターが４０１応答に存在しない場合、本プロセスはステップ３１２に移る。

[0058] ステップ３１２において、アプリケーションは、４０１応答のWWW-Authenticateに領域パラメーターがあるか否か判定する。ステップ３１３において、アプリケーションは、「＠」および４０１における領域値と連結されたパートナー・アプリ識別子（例えば、PIDpa@realm）が、構成されたパートナー・アプリケーションの１つと正確に一致するか否か判定する。ステップ３１３において、PIDpa@realmが構成されたパートナー・アプリケーションの１つと正確に一致し、そして直接信頼が構成される場合、アプリケーションは、ステップ３１４において、自己発行トークンを作成する。自己発行トークンは、次のパラメーターを用いてフォーマットされる。

iss: PIDapp@realm、
nameid: PIDapp@realm、および
aud: PIDpa@realm/pahost@realm。

[0059] issおよびnameidエレメント(PIDapp@realm)は、ローカル・アプリケーションの発行元識別子に対応する。audエレメントは、パートナー・アプリケーションのＩＤ(PIDpa)および４０１において戻された領域値に基づいて組み立てられる。

[0060] ステップ３１３において、PIDapp@realmと構成されたパートナー・アプリケーションの１つとの間に一致がなかった場合、本プロセスはステップ３１５に移る。ステップ３１５において、アプリケーションは、４０１応答において戻された領域値が、いずれかの構成されたＳＴＳの領域と正確に一致するか否か判定する。

[0061] ステップ３１５において一致がなかった場合、アプリケーションは、ステップ３１６において、領域が空のＳＴＳ構成を選択する。
[0062] ステップ３１５または３１６において一致があった場合、ステップ３１７において、アプリケーションは、一致したＳＴＳの構成エントリーが空のＴＩＤを含むか否か判定する。一致したＳＴＳの構成エントリーが空でないＴＩＤを含む場合、ステップ３１８において、アプリケーションは、一致したＳＴＳ構成からのＴＩＤを領域として用いて、ＳＴＳのために自己発行トークンを組み立てる。一致したＳＴＳの構成エントリーが空／「*」領域を有する場合、ステップ３１９において、アプリケーションは、先の入力パラメーターから領域[TID]を用いて、ＳＴＳのために自己発行トークンを組み立てる。自己発行トークンは、次のパラメーターを有する。

iss: PIDapp@tid、
nameid: PIDapp@tid、
aud: PIDsts@tid/stshost@tid、および
resource: PIDpa@target-realm/pahost@user-domain。

[0063] issおよびnameidエレメントＰＩＤ(PIDapp)は、アプリケーション発行元識別子から来る。audエレメントＰＩＤ(PIDsts)は、ＳＴＳ構成エントリーから来る。iss、nameid、およびaudエレメント(tid)に対する領域は、構成されたＳＴＳ ＴＩＤまたは入力パラメーターからのテナントＩＤに基づいて選択される。stshostエレメントは、STSメタデーター文書における発行元エンドポイントから来る。リソース・エレメントは、パートナー・アプリケーションのＩＤ(PIDpa)およびユーザー・ドメインに基づいて組み立てられる。

[0064] 次いで、ステップ３１８または３１９からの自己発行トークンがＳＴＳに供給される。ＳＴＳは、ステップ３２０において、以下のパラメーターを用いてトークンを生成する。

iss: PIDsts@tid、
nameid: PIDapp@tid、および
aud: PIDpa@tid/desthost@tid。

[0065] ＳＴＳは、それ自体のissuer@tenantIDをissエレメントに用いる。nameidエレメントの有効性が判断され、自己発行トークンからコピーされる。audエレメントの有効性が判断され、自己発行トークンのリソース・エレメントからコピーされる。ＤＮＳドメインが供給される場合、ＤＮＳ領域が実際のテナントＩＤ(tid)と置き換えられる。そうでなければ、テナントｉｄが供給される場合、置き換えは必要ない。

[0066] 図３Ａおよび図３Ｂのステップから一致が全く得られない場合、本プロセスは停止し、トークンを作成することはできない。
[0067] １つのアウトバウンド発行元を用いるアプリケーションでは、当該アプリケーションは、その発行元だけを用い、ステップ３１７から３２０までを用いてトークンを生成しなければならない。
インバウンド・トークンの有効性判断
[0068] アプリケーションが発行元識別子に基づくトークンの有効性判断を実施する場合、アプリケーションは発行元識別子を入手し、トークン署名有効性判断のための証明書を突き止める。アプリケーションは発行元をそのＳＴＳのリストと照合する。このリストは、アプリケーションのグローバル構成の一部である。発行元におけるＰＩＤが、ＳＴＳ構成と正確に一致しなければならない。領域は、ＳＴＳ構成エントリーにおいてそれが指定される（即ち、空でない）場合にのみ、一致しなければならない。ＳＴＳ構成エントリーが空の領域または「*」を有する場合、発行元識別子における領域の値は有効なテナントＩＤでなければならない。

[0069] トークンは、直接信頼を有するパートナー・アプリケーションのリストと照合されるのでもよい。直接信頼を有するアプリケーションのリストは、アプリケーションのグローバル構成から来る。実施形態では、直接信頼が、テナント構成からのアプリケーションを含む場合もある。テナントは、トークンのオーディエンス（aud:）フィールドにおける領域に基づいて調べられる。一実施形態では、全てのフィールド(PID@realm)が正確に直接信頼に対して一致しなければならず、ワイルドカードの一致は許されない。トークンにおける名称識別子のテナントのＰＩＤおよび領域は、発行元のＰＩＤおよび領域と同じでなければならない。

[0070] 一致がない場合、アプリケーションはトークンを拒絶する。それ以外の場合、アプリケーションは証明書を引き出すことができる。証明書は、ＳＴＳまたはパートナー・アプリケーションに関連するメタデーター文書から得ることができる。あるいは、証明書の直接構成も許される。

[0071] アプリケーションが鍵識別子に基づくトークンの有効性判断を実施する場合、アプリケーションは、証明書サムプリント(certificate thumbprint)のような鍵識別子をトークンから入手し、それを構成における全ての有効な鍵識別子と照合する。一致がない場合、アプリケーションはこのトークンを拒絶する。それ以外の場合、アプリケーションは、この鍵に関連するメタデーター文書から証明書を引き出すことができ、または証明書をそれ自体で構成することもできる。

[0072] アプリケーションは、引き出した証明書を用いて、トークンの署名の有効性を判断する。
[0073] 一実施形態では、アプリケーションは名称識別子を入手し、それをパートナー・アプリケーション・リストと照合する。ＰＩＤは正確に一致しなければならない。領域は、それがパートナー・アプリケーションの構成エントリーにおいて指定される（即ち、空でないまたは「*」）場合にのみ一致しなければならない。パートナー・アプリケーションの構成エントリーが空の領域を有する場合、名称識別子の領域は、発行元の領域と同じでなければならない。

[0074] アプリケーションは、オーディエンスを入手して、そのフィールドを照合する。ＰＩＤは、アプリケーションがアクセスされた際のローカル・アプリケーションＰＩＤおよびホスト名と正確に一致しなければならない。ＳＴＳ発行トークンでは、領域は発行元の領域（テナントＩＤ）と一致しなければならない。アプリケーション発行トークンでは、領域はローカルに構成されたグローバルまたはテナント・ドメインの内１つと一致しなければならない。オンラインまたはマルチ・テナント環境では、領域は有効なテナントＩＤまたは有効なテナントを解決する(resolve to)ドメインでなければならない。

[0075] 尚、本明細書において説明したトークンの組み立ておよび有効性判断は、２つ以上の関与物(participant)によって用いられてもよいことは理解されよう。関与物は、アプリケーション、サーバー、サービス、デバイス、製品等を含むこともできる。関与物は、構成されたＳＴＳ、パートナー・アプリケーション、および信頼発行元を識別するように構成することができる。次いで、関与物は、以上で説明したように、トークンを作成、交換し、その有効性を判断する。

[0076] 尚、図２に示したプロセスのステップ２０１〜２０６、および図３に示したプロセスのステップ３０１〜３２０は、同時におよび／または順次に実行してもよいことは理解されよう。更に、各ステップは、いずれの順序で実行してもよく、１回または繰り返し実行してもよいことも理解されよう。

[0077] 図４は、図１〜図３の例を実現することができる適した計算およびネットワーキング環境４００の一例を示す。認証信任状を得るための、本明細書で説明した、認証サービス、サービス、およびアプリケーションは、コンピューター・システム４００上において具体化することができる。計算システム環境４００は、適した計算環境の一例に過ぎず、本発明の使用範囲や機能に関して何ら限定を示唆する意図はない。本発明は、複数の他の汎用または特殊目的計算システム環境あるいは構成でも動作する。本発明との使用に適すると考えられる周知の計算システム、環境、および／または構成の例には、パーソナル・コンピューター、サーバー・コンピューター、ハンドヘルドまたはラップトップ・コンピューター、タブレット・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベース・システム、セット・トップ・ボックス、プログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、以上のシステムまたはデバイスのいずれかを含む分散型計算環境等が含まれるが、これらに限定されるのではない。

[0078] 本発明は、コンピューターによって実行される、プログラム・モジュールのような、コンピューター実行可能命令という一般的なコンテキストで説明することができる。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含み、特定のタスクを実行するかまたは特定の抽象データー型を実装する。また、本発明は分散型計算環境において実施することもでき、この場合、タスクは、通信ネットワークを介してリンクされたリモート処理デバイスによって実行される。分散型計算環境では、プログラム・モジュールは、メモリー記憶デバイスを含む、ローカルおよび／またはリモート・コンピューター記憶媒体に配置することができる。

[0079] 図４を参照すると、本発明の種々の実施形態を実現するシステム例は、コンピューター４００の形態とした汎用計算デバイスを含むことができる。コンポーネントは、処理ユニット４０８、システム・メモリーのようなデーター・ストレージ４０２、およびデーター・ストレージ４０２から処理ユニット４０８までを含む種々のシステム・コンポーネントを結合するシステム・バス４０３を含むことができるが、これらに限定されるのではない。システム・バス４０３は、メモリー・バスまたはメモリー・コントローラ、周辺バス、および種々のバス・アーキテクチャーの内いずれかを使用するローカル・バスを含む、様々なタイプのバス構造のいずれでもよい。一例として、そして限定ではなく、このようなアーキテクチャーは、業界標準アーキテクチャー（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャー（ＭＣＡ）、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格連合（ＶＥＳＡ）ローカル・バス、およびMezzanineバスとしても知られる周辺コンポーネント相互接続（ＰＣＩ）バスを含む。

[0080] コンピューター４００は、通例、種々のコンピューター読み取り可能媒体４０４を含む。コンピューター読み取り可能媒体４０４は、コンピューター４００によってアクセスすることができるいずれの入手可能な媒体とすることもでき、揮発性および不揮発性、ならびにリムーバブルおよび非リムーバブル媒体の双方を含むが、伝搬信号を除外する。一例として、そして限定ではなく、コンピューター読み取り可能媒体４０４は、コンピューター記憶媒体および通信媒体を含むことができる。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のためのいずれかの方法または技術で実現される。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、または所望の情報を格納するために使用することができそしてコンピューター４００によってアクセスすることができる他のあらゆる媒体を含むが、これらに限定されるのではない。通信媒体は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターを、搬送波のような変調データー信号または他の伝達メカニズムに具体化し、あらゆる情報配信媒体を含む。「変調データー信号」という用語は、その信号内に情報をエンコードするようなやり方で、その特性の１つ以上が設定または変更された信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続というような有線媒体と、音響、ＲＦ、赤外線、および他のワイヤレス媒体というようなワイヤレス媒体とを含む。以上のいずれの組み合わせも、コンピューター読み取り可能媒体の範囲に含むことができる。コンピューター読み取り可能媒体は、コンピューター記憶媒体上に格納されたソフトウェアのような、コンピューター・プログラム生産物として具体化することもできる。

[0081] データー・ストレージまたはシステム・メモリー４０２は、リード・オンリー・メモリー（ＲＯＭ）およびランダム・アクセス・メモリー（ＲＡＭ）のような、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含む。基本入力／出力システム（ＢＩＯＳ）は、起動中におけるように、コンピューター４００内部にあるエレメント間で情報を伝えるのに役立つ基本的なルーチンを含み、通例ＲＯＭに格納される。ＲＡＭは、通例、処理ユニット４０８によって直ちにアクセス可能な、および／または現在処理ユニットによって処理されているデーターおよび／またはプログラム・モジュールを含む。一例として、そして限定ではなく、データー・ストレージ４０２は、オペレーティング・システム、アプリケーション・プログラム、ならびに他のプログラム・モジュールおよびプログラム・データーを保持する。

[0082] また、データー・ストレージ４０２は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体も含むことができる。一例としてに過ぎないが、データー・ストレージ４０２は、非リムーバブル、不揮発性磁気媒体に対して読み取りまたは書き込みを行うハード・ディスク・ドライブ、リムーバブル、不揮発性磁気ディスクに対して読み取りまたは書き込みを行う磁気ディスク・ドライブ、およびＣＤ−ＲＯＭまたは他の光媒体のようなリムーバブル、不揮発性光ディスクに対して読み取りまたは書き込みを行う光ディスクであってもよい。この動作環境例において使用することができる他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体には、磁気テープ・カセット、フラッシュ・メモリー・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれるが、これらに限定されるのではない。以上で説明し図４に示すこれらのドライブおよびそれに関連するコンピューター記憶媒体は、コンピューター４００のためのコンピューター読み取り可能命令、データー構造、プログラム・モジュール、および他のデーターの格納を考慮している。

[0083] ユーザーは、ユーザー・インターフェース４０５、あるいはタブレット、電子ディジタイザー、マイクロフォン、キーボード、および／または一般にマウス、トラックボール、またはタッチ・パッドと呼ばれるポインティング・デバイスというような他の入力デバイスによって、コマンドおよび情報を入力することができる。他の入力デバイスには、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナ等を含むことができる。加えて、音声入力または自然ユーザー・インターフェース（ＮＵＩ）も使用することができる。これらおよび他の入力デバイスは、多くの場合、ユーザー入力インターフェース４０５を介して処理ユニット４０８に接続される。ユーザー入力インターフェース４０５は、システム・バス４０３に結合されるが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のような他のインターフェースおよびバス構造によって接続されてもよい。また、モニター４０６または他のタイプのディスプレイ・デバイスも、ビデオ・インターフェースのようなインターフェースを介して、システム・バス４０３に接続される。また、モニター４０６にはタッチ・スクリーン・パネル等が統合されてもよい。尚、モニターおよび／またはタッチ・スクリーン・パネルは、タブレット型パーソナル・コンピューターにおけるように、計算デバイス４００が組み込まれる筐体に物理的に結合できることを注記しておく。加えて、計算デバイス４００のようなコンピューターは、スピーカーおよびプリンターのような他の周辺出力デバイスも含むことができ、これらは出力周辺インターフェース等を介して接続されればよい。

[0084] コンピューター４００は、リモート・コンピューターのような１つ以上のリモート・コンピューターへの論理接続４０７を使用して、ネットワーク接続環境において動作することもできる。例えば、認証サービス、サービス、およびアプリケーションは、ネットワーク接続を介して通信して認証信任状を得ることができる。リモート・コンピューターは、パーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイス、または他の一般的なネットワーク・ノードであってよく、通例、コンピューター４００に関して先に説明したエレメントの多くまたは全部を含む。図４に示す論理接続は、１つ以上のローカル・エリア・ネットワーク（ＬＡＮ）および１つ以上のワイド・エリア・ネットワーク（ＷＡＮ）を含むが、他のネットワークを含むこともできる。このようなネットワーク接続環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネット、およびインターネットでは極普通である。

[0085] ＬＡＮネットワーク接続環境において使用される場合、コンピューター４００は、ネットワーク・インターフェースまたはアダプター４０７を介してＬＡＮに接続することができる。ＷＡＮネットワーク接続環境において使用される場合、コンピューター４００は、通例、インターネットのようなＷＡＮを介して通信を確立するモデムまたは他の手段を含む。モデムは、内蔵型でも外付けでもよく、ネットワーク・インターフェース４０７または他のしかるべきメカニズムを介してシステム・バス４０３に接続することができる。インターフェースおよびアンテナを含むというような、ワイヤレス・ネットワーク接続コンポーネントは、アクセス・ポイントまたはピア・コンピューターというような適したデバイスを介して、ＷＡＮまたはＬＡＮに結合することができる。ネットワーク接続環境において、コンピューター４００に関して図示したプログラム、またはその一部が、リモート・メモリー記憶デバイスに格納されてもよい。尚、図示したネットワーク接続は一例であり、コンピューター間に通信リンクを確立する他の手段を使用してもよいことは認められよう。

[0086] 以上、構造的特徴および／または方法論的動作に特定の文言で本主題について説明したが、添付した特許請求の範囲において定められる主題は、必ずしも以上で説明した具体的な特徴や動作には限定されないことは、理解されてしかるべきである。逆に、以上で説明した具体的な特徴および動作は、特許請求の範囲を実現する形態例として開示されたまでである。

Claims (16)

1. 処理装置から、第１アプリケーションから第２アプリケーションへの要求を送るステップと、
   前記処理装置において、前記要求に対する応答を受け取るステップであって、前記応答は、前記第２アプリケーションによって信頼された認証発行元のリストを含む、ステップと、
   前記処理装置において、前記第２アプリケーションによって信頼された認証発行元の前記リストを、前記第１アプリケーションに対して承認された認証発行元のリストと比較するステップと、
   前記処理装置において、前記リスト間における認証発行元の一致を識別するステップと、
   前記処理装置において、承認された認証発行元構成からのテナント識別子を用いて、認証発行元のためのトークンを組み立てるステップと、
   前記処理装置において、前記トークンを用いて前記認証発行元から認証信任状を得るステップと、
   前記処理装置において、前記認証信任状を用いて前記第２アプリケーションへの修正要求を生成するステップと、
   を含む、方法。
2. 前記応答は、非認証要求を示す４０１応答であり、前記第２アプリケーションによって信頼された認証発行元の前記リストは、前記４０１応答のWWW-Authenticateヘッダで搬送される、請求項１に記載の方法。
3. 前記処理装置において、グローバル一意識別子（ＧＵＩＤ）を用いて、前記第２アプリケーションによって信頼された認証発行元が前記第１アプリケーションに対して承認された認証発行元と一致するか否かを判定するステップを更に含む、請求項１に記載の方法。
4. 前記処理装置において、所定の入力パラメーターからのテナント識別子を用いて、認証発行元のためのトークンを組み立てるステップと、
   を更に含む、請求項３に記載の方法。
5. 前記処理装置において、承認された認証発行元構成に一致するグローバル一意識別子（ＧＵＩＤ）と、前記承認された認証発行元構成からのテナント識別子とを用いて、前記認証発行元のための自己発行トークンを作成するステップを更に含む、請求項１に記載の方法。
6. 前記処理装置において、前記認証発行元から、前記自己発行トークンを用いて前記認証発行元によって生成された認証トークンを受け取るステップを更に含む、請求項５に記載の方法。
7. ハードウェア・プロセッサー上で動作しているアプリケーションにおいて、領域パラメーターとアプリケーション識別子パラメーターとを有するヘッダを備えた応答をパートナー・アプリケーションから受け取るステップと、
   前記アプリケーションにおいて、前記パートナー・アプリケーションの識別子を前記領域パラメーターと連結して連結値を生成するステップと、
   前記アプリケーションにおいて、前記連結値が構成されたパートナー・アプリケーションのリスト中のエントリーと一致するか否かを判定するステップと、
   前記アプリケーションにおいて、一致が存在することを判定したことに応答して、前記パートナー・アプリケーションまたは認証発行元のための自己発行トークンを生成するステップと、
   を含む方法。
8. 前記アプリケーションにおいて、一致が存在しないことを判定したことに応答して、前記応答の中の領域値が構成された認証発行元と一致するか否かを判定するステップと、
   前記アプリケーションにおいて、テナント識別子を用いて前記認証発行元のための自己発行トークンを生成するステップと、
   を更に含む、請求項７に記載の方法。
9. 前記自己発行トークンは、前記認証発行元によって用いられて認証トークンを生成するように適合されている、請求項７に記載の方法。
10. 前記アプリケーションにおいて、パートナー・アプリケーションと承認された認証発行元を識別するようにアプリケーションを構成するステップを更に含む、請求項７に記載の方法。
11. 承認された認証発行元構成は、前記承認された認証発行元に対するグローバル一意識別子（ＧＵＩＤ）を識別するが、アプリケーションがオンライン・インストール向けに構成されている場合はテナント識別子を識別しない、請求項１０に記載の方法。
12. 承認された認証発行元構成は、前記承認された認証発行元に対するグローバル一意識別子（ＧＵＩＤ）を識別し、アプリケーションが構内インストール向けに構成されている場合はテナント識別子を識別する、請求項１０に記載の方法。
13. １または複数のプロセッサーと、
    システム・メモリーと、
    コンピューター実行可能命令が格納された１または複数のコンピューター読み取り可能記憶媒体と、を備え、
    前記コンピューター実行可能命令は、前記１または複数のプロセッサーによって実行されると、認証信任状を生成するための方法を前記プロセッサーに実施させ、前記プロセッサーは、
    第１アプリケーションから第２アプリケーションへの要求を送り、
    前記要求に対する応答であって、前記第２アプリケーションによって信頼された認証発行元のリストを含む応答を受け取り、
    前記第２アプリケーションによって信頼された認証発行元の前記リストを、前記第１アプリケーションに対して承認された認証発行元のリストと比較し、
    両方のリストに一致する認証発行元を識別し、
    承認された認証発行元構成からのテナント識別子を用いて、認証発行元のためのトークンを組み立て、
    前記トークンを用いて前記認証発行元から認証信任状を取得し、
    前記認証信任状を用いて前記第２アプリケーションへの修正要求を生成する、
    ように動作する、コンピューター・システム。
14. 前記応答は、非認証要求を示す４０１応答であり、前記第２アプリケーションによって信頼された認証発行元の前記リストは、前記４０１応答のWWW-Authenticateヘッダで搬送され、
    前記プロセッサーは、更に、
    グローバル一意識別子（ＧＵＩＤ）を用いて、前記第２アプリケーションによって信頼された認証発行元が前記第１アプリケーションに対して承認された認証発行元と一致するか否かを判定し、
    承認された認証発行元構成からのテナント識別子を用いて、認証発行元のためのトークンを組み立てる、
    ように動作する、請求項１３に記載のコンピューター・システム。
15. 前記応答は、非認証要求を示す４０１応答であり、前記第２アプリケーションによって信頼された認証発行元の前記リストは、前記４０１応答のWWW-Authenticateヘッダで搬送され、
    前記プロセッサーは、更に、
    グローバル一意識別子（ＧＵＩＤ）を用いて、前記第２アプリケーションによって信頼された認証発行元が前記第１アプリケーションに対して承認された認証発行元と一致するか否かを判定し、
    所定の入力パラメーターからのテナント識別子を用いて、認証発行元のためのトークンを組み立てる、
    ように動作する、請求項１３に記載のコンピューター・システム。
16. 前記プロセッサーは、更に、自己発行トークンを用いて前記認証発行元によって生成された認証トークンを前記認証発行元から受け取るように動作する、請求項１３に記載のコンピューター・システム。

Images