JP2017530472A - 共通エンドポイントにアクセスするために異なるディレクトリに記憶される認証情報を使用すること - Google Patents

Abstract

グローバルエンドポイントは、組織名、及び異なる地理的地域に位置する複数のディレクトリと関連付けられてよい。グローバルエンドポイントは、アプリケーションまたはサービスにアクセスするためにユーザーによって使用されるページをホストするコンピューティングシステムであってよい。ユーザーは、すでに存在する認証情報を使用し、アプリケーションまたはサービスにアクセスできてよい。例えば、ユーザーは、ユーザーが所属しているエンティティによって記憶され、維持される認証情報を使用し、アプリケーションまたはサービスにアクセスしてよい。異なる地理的地域に記憶される認証情報を有するユーザーは、同じグローバルエンドポイントを介してアプリケーションまたはサービスにアクセスできてよい。【選択図】図１Ｂ

Description

本発明は、共通エンドポイントにアクセスするために異なるディレクトリに記憶される認証情報を使用することに関する。

管理者はしばしば、ユーザー及び／またはコンピューティングリソース管理用のディレクトリを作成し、維持するために、及び／またはさまざまなコンピューティングリソース（例えば、ファイルシステム、ファイル、ユーザー、セキュリティ方針、ネットワークリソース、アプリケーション、システムストレージ等）にアクセスを提供するためのディレクトリサービスを活用する。ディレクトリサービスは管理者によって操作されるデータサーバ内（例えば、オンプレミス）に実装されてよい。また、管理者はユーザーによって操作される複数のクライアントデバイスを管理してもよく、複数のクライアントデバイスのそれぞれはネットワークまたはドメインをデータサーバと共有する。クライアントデバイスを安全に保ち、ドメイン全体で互換性を保証するために、データサーバはクライアントデバイスに対してセキュリティ方針を割り当て、施行し、クライアントデバイスで実行中のソフトウェアをインストールまたは更新してよい。

ただし、データサーバをインストールすること、保守すること、及び操作することは面倒である場合がある。データサーバ自体がいくつかのコンピューティングシステムを含み、このようにして高価なハードウェアの購入及び複雑なソフトウェアの構成を必要とすることがある。いくつかの場合、データサーバに電力を供給し、冷却するための専用施設が必要とされることもある。データサーバとクライアントデバイスとの間で接続性を確立し、維持することは、高価なネットワーク設備の設置を必要とすることがある。さらに、データサーバが故障する、またはデータがそれ以外の場合失われた場合にバックアップ手順及び回復手順を実施するために、追加のハードウェア及び／またはソフトウェアが必要とされることがある。

グローバルエンドポイントは、組織名、及び異なる地理的地域に位置する複数のディレクトリと関連付けられてよい。グローバルエンドポイントは、アプリケーションまたはサービスにアクセスするためにユーザーによって使用されるページをホストするコンピューティングシステムであってよい。ユーザーは、すでに存在する認証情報を使用し、アプリケーションまたはサービスにアクセスできてよい。例えば、ユーザーは、ユーザーが所属しているエンティティによって記憶され、維持される認証情報を使用し、アプリケーションまたはサービスにアクセスしてよい。異なる地理的地域に記憶される認証情報を有するユーザーは、同じグローバルエンドポイントを介してアプリケーションまたはサービスにアクセスできてよい。

図面を通して、参照された要素の間の対応を示すために参照番号が再利用されてよい。図面は本明細書に説明される例の実施形態を示すために提供され、本開示の範囲を制限することを目的としていない。

一実施形態に係るディレクトリサービスを提供する多様な領域を有する管理ディレクトリサービス環境を示す図である。 本開示のディレクトリ管理機能、ならびにユーザー、グループ、及びデバイスの管理及び認証機能をいくつかの実施形態に従って実装できる例のネットワーク環境を示す図である。 ユーザーデバイスによってアクセスされるサービスにトークンを提供するプロセス中のユーザー管理及び認証モジュール１４２との間の対話を示す図である。 トークンを提供し、ＡＰＩコールを取り扱うプロセス中のユーザー管理及び認証モジュール１４２との間の対話を示す図である。 サードパーティアプリケーションサーバまたはコンピュータリソースサービスプロバイダシステムによって提供されるアプリケーションもしくはサービスによって使用されてよい、異なる領域の複数のディレクトリと関連付けられた共通エンドポイントでユーザーを認証するためのプロセスを示す図である。 図１Ａ〜図１Ｂのユーザーデバイス等、ユーザーデバイスで見られるネットワークページの表現の例を示す図である。 図１Ａ〜図１Ｂのユーザーデバイス等、ユーザーデバイスで見られるネットワークページの表現の例を示す図である。

前書き‐組織名を用いるグローバルエンドポイント
上述されたように、ディレクトリサービスを実装するオンプレミスデータサーバは面倒である場合がある。したがって、いくつかの従来のシステムでは、管理ディレクトリサービス（例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＡＣＴＩＶＥ ＤＩＲＥＣＴＯＲＹ（登録商標）等のコンピュータオペレーティングシステムのディレクトリに情報を記憶し、編成し、情報へのアクセスを提供するシステム）は、遠隔に位置し、複数の管理者及び／または組織によって共有される中央管理データサーバによって実装できる。管理ディレクトリサービスは複数のディレクトリを管理してよい。中央管理データサーバは、ネットワーク（例えば、インターネット）を介して管理ディレクトリサービスにアクセスを提供してよく、管理者はディレクトリを管理するために既存のネットワークによって有効にされたクライアントデバイスを使用してよい。例えば、管理者は、中央管理データサーバを提供するエンティティとアカウントを確立してよい。アカウントにアクセスするとき、管理者は１つまたは複数のディレクトリを作成し、ディレクトリの中でドメイン（例えば、すべてのユーザーアカウント及びコンピュータ、プリンタ、スキャナ、サーバ、プロセス、スレッド等のコンピューティングリソースが単一のディレクトリサービスに登録されるコンピュータネットワーク）を作成し、ドメインにメンバーサーバ（例えば、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）、ケルベロス、ドメインネームシステム（ＤＮＳ）サービス、またはディレクトリのレコードを管理するための他のアクティブディレクトリツールを実装するサーバ）を追加することができる。管理者は、ドメインに追加されたメンバーサーバを使用し、ドメインユーザーを作成し、管理することができる。したがって、管理者はディレクトリサービスを実装するために通常使用されるインフラストラクチャをインストールするまたは保守する必要なくディレクトリサービスを実装できる。

既存の管理ディレクトリサービスはいくつかの制限を有する。例えば、２つ以上のエンティティが管理ディレクトリサービスを使用し、ディレクトリを作成した可能性がある。エンティティは別々であり、別々のディレクトリを作成したため、ユーザーはそのそれぞれのエンティティのディレクトリにアクセスすることによって認証されてよい。いくつかの場合、エンティティはリソースまたはコンテンツを共有する希望を有することがある。エンティティがリソースまたはコンテンツを共有する１つの考えられる方法は、どちらかのエンティティと関連付けられたユーザーによってアクセス可能な共通エンドポイントとして働く共有組織を作成することだろう。ただし、エンティティは異なるディレクトリを維持するため、あるエンティティのユーザーは、新しいユーザーアカウントが作成されない限り別のエンティティによって作成されるディレクトリにアクセスするために自分の既存の認証情報を使用することができない可能性があり、逆も同様である。さらに、共通エンドポイントが認証情報を維持するディレクトリにアクセスを有さない可能性がある。エンティティは、認証情報が別々のディレクトリと関連付けられても、どちらかのエンティティからのユーザーが認証の目的で自分の既存の認証情報を入力できる共通エンドポイント及びログインシステムを所望することがある。

これらの問題の少なくともいくつかに取り組む共通のグローバルエンドポイントが本明細書で説明される。グローバルエンドポイントは、既存の認証情報を介してアプリケーションまたはサービスにアクセスするために使用されるページ（例えば、ウェブページ等のコンテンツページまたはネットワークページ）をホストするコンピューティングシステムであってよい。グローバルエンドポイントは組織名別に識別されてよく、グローバルエンドポイントの場所（例えば、インターネットプロトコル（ＩＰ）アドレス）は、組織名（例えば＜ｏｒｇａｎｉｚａｔｉｏｎ ｎａｍｅ＞．＜ａｐｐｌｉｃａｔｉｏｎ ｈｏｓｔ＞．ｃｏｍ）を識別するユニフォームリソースロケータ（ＵＲＬ）と関連付けられてよい。グローバルエンドポイントは、そのユーザーに、ユーザーの既存の認証情報を使ったアプリケーションまたはサービスへのアクセスを提供することを希望するエンティティによって作成されたディレクトリ等の複数のディレクトリと関連付けられてよい。

管理ディレクトリサービスは異なる地理的地域に分散されてよい。例えば、１つまたは複数のコンテンツ配信ネットワーク（ＣＤＮ）がバックエンドサーバと構成されてよく、バックエンドサーバは管理ディレクトリサービスを実装するシステムと通信してよい。管理ディレクトリサービスを実装するシステムは、マルチリージョンの分散コンピュータシステムの単一の領域内で動作してよく、単一領域の他のデバイスまたはシステムだけと通信してよい。したがって、ＣＤＮは領域エンドポイントとして見なされてよく、管理ディレクトリサービスを実装するシステムは単一エンドポイントと見なされてよい。ＣＤＮを使用し、管理ディレクトリサービスを多様な領域に分散することは、（例えば、データのキャッシングを介して）より低遅延の通信、及び（例えば、単一のエンドポイントから計算をオフロードすることによって）改善されたリソースバランシング等のいくつかの利点を提供してよい。しかしながら、ユーザーの認証情報を認証するために、グローバルエンドポイントはまず、受け取られた認証情報と関連付けられたディレクトリが位置する領域を特定しなければならないことがある。

ディレクトリが位置する領域を識別するのを助けるために、ＤＮＳエントリ（例えば、対応するＩＰアドレス）とのグローバルエンドポイントの組織名のマッピングを含むルートサービス（例えば、ドメインネームシステム（ＤＮＳ）ウェブサービス）を維持できる。例えば、マッピングは、グローバルエンドポイントが組織または組織のグループに作成されるときにルートサービスに記憶されてよい。ルートサービスは、１つまたは複数のＣＤＮのアドレスとのＤＮＳエントリのマッピングをさらに含んでよい。したがって、ルートサービスは、グローバルエンドポイントの組織名と関連付けられたＤＮＳエントリを識別するために問い合わせを行われることがあり、ＤＮＳエントリと関連付けられた１つまたは複数のＣＤＮのアドレスを識別するために問い合わせを行われることがある。ルートサービスは、次いで識別されたＣＤＮにグローバルエンドポイントを向けることができる。識別されたＣＤＮの内の１つまたは複数は、記憶されているマッピングに基づいて領域サービス（例えば、管理ディレクトリサービス）にグローバルエンドポイントを向けることができ、組織名に基づいた地域サービスはディレクトリの場所を識別できる。

例えば、領域の中のディレクトリまたは他のコンピューティングシステムエンティティは、領域の中のコンピューティングシステムエンティティが利用可能である、及び／または領域の外部のコンピューティングシステムエンティティが利用できない一意の識別子（例えば、ユニフォームリソースアイデンティファイア、ＵＲＬ、または任意の他のリソース識別子）を有してよい。一意の識別子は、（例えば、エンティティのためのディレクトリの特定の場所及びタイプが非表示のままであるように）セキュリティのために、及び／または一意の識別子が変化することがあるため、領域外のコンピューティングシステムエンティティは利用できないことがある。一意の識別子は利用できないことがあるため、ＣＤＮまたはＣＤＮを介した領域サービスは、グローバルエンドポイント及びルートサービス等の分散コンピューティングシステムの多様なコンピューティングシステムに対して、ディレクトリの実際の一意の識別子に対するエイリアスとしての機能を果たす異なる一意の識別子を提供してよい。したがって、グローバルエンドポイントがエイリアス識別子を使用してディレクトリにアクセスする要求を示す場合、ルートサービスは適切なＣＤＮに要求をリダイレクトできる。ＣＤＮは、次いでエイリアス識別子のコンテンツに基づいて適切なディレクトリを決定できる領域サービスを識別してよい。適切なエンドポイントにコールまたは要求をリダイレクトするために係る技法を使用することは、その内容が全体として参照することにより本明細書に組み込まれる、「ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＮＥＴＷＯＲＫ ＲＥＤＩＲＥＣＴＩＯＮ」と題し、２０１３年１２月１２日に出願された米国特許出願第１４／０９８，４４６号により詳細に説明される。

いったん適切な領域が識別され、領域サービスがグローバルエンドポイントを適切なディレクトリに向けると、ユーザーの既存の認証情報は適切なディレクトリによって認証できる。認証が合格すると、ユーザーは無事にログインし、アプリケーションまたはサービスにアクセスしてよい。このようにして、ユーザーは自分の既存の認証情報とは別個に認証情報の新しいセットを作成するまたは使用する必要なく、アプリケーションまたはサービスにアクセスできる。

ユーザーがアプリケーションまたはサービスにアクセスするために自分の認証情報を使用し、ログインするとき、ブラウザアプリケーションのＵＲＬバーは、ルートサービスが（グローバルエンドポイントの要求で）グローバルエンドポイントからＣＤＮにユーザーをリダイレクトし、ＣＤＮが領域サービスを識別するとしても変化しないままであってよい。例えば、ユーザーは組織名別に識別されるページにアクセスしてよく、ＵＲＬバーは組織名を表示してよい。組織名を入力すると同時に、グローバルエンドポイントは、ユーザーが自分の既存の認証情報を入力することができ、ＵＲＬバーが未変更のままとなり得るように、ブラウザアプリケーションを領域サービスによって生成されるログインページにリダイレクトさせてよい。代わりに、ユーザーは、組織名及びサービスを識別するＵＲＬを入力してよい（例えば、ニュースサービスが識別されたサービスである、＜ｏｒｇａｎｉｚａｔｉｏｎ ｎａｍｅ＞．＜ａｐｐｌｉｃａｔｉｏｎ ｈｏｓｔ＞．ｃｏｍ／ｎｅｗｓ−ｓｅｒｖｉｃｅ）。ＵＲＬバーは識別された組織名及びサービスを表示してよいが、ブラウザアプリケーションは領域サービスによって生成されるログインページにリダイレクトされてよい。いったんログインすると、ユーザーはアプリケーションまたはサービスのホームページにリダイレクトされてよい。しかもＵＲＬバーは依然として元のＵＲＬを表示してよい。

前書き‐組織名を使用するディレクトリの管理
概して、上述されたように、メンバーサーバはディレクトリのリソースを管理するために使用される。ただし、一部の管理者はメンバーサーバに対するアクセスを有さないことがある、またはメンバーサーバ（例えば、ウェブ開発者、アプリケーション開発者、モバイルアプリケーション開発者等）を操作することを希望しないことがあり、したがっていかなるユーザー管理も実行することができない、またはそれ以外の場合ディレクトリのリソースを管理できないことがある。例えば、アプリケーションサーバによってホストされるグローバルエンドポイントは、メンバーサーバでないことがあり、通常、ディレクトリを管理するまたはディレクトリにアクセスするために使用されないことがある。ただし、本明細書に説明される実施形態は、管理者がアプリケーションプログラミングインタフェース（ＡＰＩ）のセットを経由して、グローバルエンドポイント等のコンピューティングシステムを介してディレクトリを管理するまたはディレクトリにアクセスすることを可能にするユーザー管理及び認証システムも提示する。

ユーザー管理及び認証システムは、本明細書に説明される機能性を提供するために管理ディレクトリサービスと併せて機能するアドオンシステムであってよい。例えば、ユーザー管理及び認証システムは、いったんルートサービスが正しいＣＤＮにグローバルエンドポイントをリダイレクトし、ＣＤＮが領域を解像すると、グローバルエンドポイントによってアクセスできるログインページのセット（例えば、ウェブページ等のコンテンツまたはネットワークページ）を生成してよい。管理者は、自分の認証情報、ドメインへのアクセスを要求しているアプリケーションまたはサービスを識別するクライアント識別、リダイレクトページ（例えば、管理者がグローバルエンドポイントを介してアクセスしようと試みているアプリケーションまたはサービスによって生成されるページ）、及び／または組織名（例えば、グローバルエンドポイントを識別する名前、つまりディレクトリの名前）を入力できる。ユーザー管理及び認証システムは、組織と関連付けられたディレクトリに認証情報を送信してよく、ディレクトリは、認証情報が認証できるかどうか（例えば、管理者がディレクトリにアクセスできるかどうか）を判断してよい。認証情報を認証できる場合、ユーザー管理及び認証システムは通知され、認証コード（例えば、ＯＡｕｔｈコード）を生成する。

認証コードは、リダイレクトページにアクセスする命令とともにユーザー管理及び認証システムによってユーザーデバイスに送信されてよい。認証コードは、設定された期間（例えば、１０分、１時間等）有効である使い捨てのコードであってよく、認証コードの期限切れの前に、組織と関連付けられたディレクトリへのアクセスを開始するためにリダイレクトページと関連付けられたアプリケーションまたはサービスによって使用されてよい。例えば、ユーザー管理及び認証システムはｇｅｔＴｏｋｅｎ ＡＰＩを含んでよい。アプリケーションまたはサービスはｇｅｔＴｏｋｅｎ ＡＰＩを呼び出して、パラメータとして認証コードを渡してよい。

ｇｅｔＴｏｋｅｎ ＡＰＩは、有効な認証コードを受け取ることに応えてアクセストークン及び／またはリフレッシュトークンを生成し、アプリケーションまたはサービスにトークンを提供してよい。アクセストークン及び／またはリフレッシュトークンは、認証情報及び／または組織名に基づいて生成されてよい。例えば、アクセストークン及び／またはリフレッシュトークンは、安全なフォーマットで認証情報及び／または組織名を含んでよい。アクセストークンは、アプリケーションまたはサービスがＡＰＩのセットを介して組織と関連付けられたディレクトリにアクセスする及び／またはディレクトリを管理することを可能にし、管理者によって定められた期間または事前に設定された期間（例えば、１時間、１日等）有効であってよい。リフレッシュトークンは、管理者によって定義された期間または事前に設定された期間（例えば、１週間、１カ月等）有効であってよく、いったん以前のアクセストークンが期限切れになると、新しいアクセストークンを受け取るためにアプリケーションまたはサービスによって使用できる。いくつかの実施形態では、リフレッシュトークンは、どの時間量も有効ではないことがある（例えば、いったんアクセストークンが期限切れになると、アクセストークンはリフレッシュされないことがある）。

実施形態では、ユーザー管理及び認証システムはいくつかのＡＰＩを提供する。係るＡＰＩは、ユーザーＡＰＩ、グループＡＰＩ、組織単位ＡＰＩ、パスワードＡＰＩ、アクセストークンＡＰＩ、及び／またはサービスＡＰＩを含んでよい。ユーザーＡＰＩは（例えば、ディレクトリでユーザーを作成するための）ｃｒｅａｔｅＵｓｅｒ ＡＰＩ、（例えば、ディレクトリの中の任意の数のユーザー及びユーザーの属性を一覧表示するための）ｄｅｓｃｒｉｂｅＵｓｅｒｓ ＡＰＩ、（例えば、ディレクトリのユーザーの属性を更新するための）ｕｐｄａｔｅＵｓｅｒ ＡＰＩ、（例えば、ディレクトリからユーザーを削除するための）ｄｅｌｅｔｅＵｓｅｒ ＡＰＩ、及び／または（例えば、ディレクトリの中のすべてのまたは任意の数のユーザー及びユーザーのグループを一覧表示するための）ｌｉｓｔＧｒｏｕｐＦｏｒＵｓｅｒ ＡＰＩを含んでよい。グループＡＰＩは、（例えば、ディレクトリの中に新しいグループを作成するための）ｃｒｅａｔｅＧｒｏｕｐ ＡＰＩ、（例えば、グループ及びディレクトリの中のグループの属性を一覧表示するための）ｄｅｓｃｒｉｂｅＧｒｏｕｐｓ ＡＰＩ、（ディレクトリの既存のグループを更新するための）ｕｐｄａｔｅＧｒｏｕｐ ＡＰＩ、（例えば、ディレクトリからグループを削除するための）ｄｅｌｅｔｅＧｒｏｕｐ ＡＰＩ、（例えばディレクトリのグループのメンバーを一覧表示するための）ｌｉｓｔＭｅｍｂｅｒｓＩｎＧｒｏｕｐ ＡＰＩ、（例えば、ディレクトリのグループにメンバー（ユーザーまたはグループ）を追加するための）ａｄｄＭｅｍｂｅｒＴｏＧｒｏｕｐ ＡＰＩ及び／または（例えば、ディレクトリのグループからメンバーを削除するための）ｒｅｍｏｖｅＭｅｍｂｅｒＦｒｏｍＧｒｏｕｐ ＡＰＩを含んでよい。組織単位ＡＰＩは、（例えば、ディレクトリの中のすべてのまたは任意の数の組織単位及びその属性を示すための）ｄｅｓｃｒｉｂｅＯｒｇａｎｉｚａｔｉｏｎａｌＵｎｉｔｓ ＡＰＩを含んでよい。パスワードＡＰＩは、（例えば、ディレクトリのユーザーを認証し、認証コードを返すための）ａｕｔｈｅｎｔｉｃａｔｅＵｓｅｒ ＡＰＩ、（例えば、ディレクトリのユーザーを認証し、認証コードを返すための）ａｕｔｈｅｎｔｉｃａｔｅＫｅｒｂｅｒｏｓＵｓｅｒ ＡＰＩ、（例えば、ディレクトリと関連付けられたラディアスサーバに対してユーザーを認証し、認証コードを返すための）ａｕｔｈｅｎｔｉｃａｔｅＲａｄｉｕｓＵｓｅｒ ＡＰＩ、（例えば、ユーザーのパスワードをリセットするための）ｒｅｓｅｔＰａｓｓｗｏｒｄ ＡＰＩ、及び／または（例えば、ユーザーのパスワードを変更するための）ｃｈａｎｇｅＰａｓｓｗｏｒｄ ＡＰＩを含んでよい。アクセストークンＡＰＩは、（例えば、記憶するための匿名トークンを作成するための）ｃｒｅａｔｅＡｎｏｎｙｍｏｕｓＴｏｋｅｎ ＡＰＩ、（例えば、認証コードに基づいてアクセストークン及び／またはリフレッシュトークンを生成するための）ｇｅｔＴｏｋｅｎ ＡＰＩ、（例えば、以前に発行されたアクセストークンまたは匿名トークンが依然として有効であることを検証するための）ｖａｌｉｄａｔｅＴｏｋｅｎ ＡＰＩ、（例えば、以前に発行されたリフレッシュトークンを使用し、新しいアクセストークンを生成するための）ｒｅｆｒｅｓｈＴｏｋｅｎ ＡＰＩ、及び／または（例えば、以前に発行されたアクセストークン、匿名トークン、またはリフレッシュトークンを無効にするための）ｒｅｖｏｋｅＴｏｋｅｎ ＡＰＩを含んでよい。サービスＡＰＩは、（例えば、登録アプリケーションまたはサービスがドメイン結合認証情報を取り出すことができるようにするための）ｇｅｔＳｅｒｖｉｃｅＡｃｃｏｕｎｔＣｒｅｄｓ ＡＰＩを含んでよい。

アプリケーションまたはサービスは、ユーザー管理及び認証システムによってサポートされるＡＰＩのいずれかを呼び出すためにアクセストークンを使用できる。例えば、アクセストークン及び／または他の操作特有のパラメータは、ディレクトリを管理するためにＡＰＩを介してユーザー管理及び認証システムに提供できる。上述されたように、アクセストークンは、認証コード及び／または組織名に基づいて生成されてよい。したがって、ＡＰＩを介した受取りと同時にユーザー管理及び認証システムによって開封されるとき、アクセストークンは認証コード、したがってアクションを実行している管理者及び／またはアクションが実行されるディレクトリを識別してよい。したがって、アプリケーションまたはサービスは、アクセスされる及び／または管理されるディレクトリを別々に識別しなくてもよい。ディレクトリを別々に識別しないことは、従来のシステムでは見つからない追加のセキュリティレベルを提供し得る。単一のディレクトリにアクセスし、管理することを概して含む従来のシステムでは、管理者は、単にディレクトリ名及び／または他の操作特有のパラメータを提供することによってディレクトリを管理してよい。ただし、本明細書に開示される実施形態では、ユーザーまたは管理者は、単に組織名及び／または他の操作特有のパラメータを提供することによって許可されない方法でディレクトリにアクセスし、ディレクトリを操作できない場合がある。むしろ、特定のディレクトリにアクセスする及び／または特定のディレクトリを操作するためにはアクセストークンが必要とされ、ユーザーまたは管理者は、本明細書に説明されるように、自分の認証情報が特定のディレクトリで検証できるようになった後（例えば、認証コードが受け取られた後）にだけアクセストークンを入手してよい。

実施形態では、アクセストークンを生成するとき、ユーザー管理及び認証システムは、組織名と関連付けられたディレクトリにアクセスするためにメンバーサーバによって通常使用できるだろうディレクトリサービストークン（例えば、ケルベロストークン、他のディレクトリ特有の認証情報等）にアクセストークンをマッピングしてよい。このようにして、アプリケーションまたはサービスがアクセストークンを使用し、ＡＰＩを呼び出すとき、ユーザー管理及び認証システムはアクセストークンにマッピングするトークンを決定するためにデータベースにアクセスし、ＡＰＩの呼出しを介して要求されたアクションまたは操作を実行するために、管理ディレクトリサービスにマッピングされたトークン（及び／またはアプリケーションもしくはサービスによって提供される他の操作特有のパラメータ）を渡してよい。いくつかの実施形態では、リフレッシュトークンの有効性は、（例えば、寿命が管理者によって事前に設定できるまたは定義できる）マッピングされたトークンの有効性と結び付けられてよい。もしあれば、結果は、管理ディレクトリサービスによってユーザー管理及び認証システムに返されてよく、ユーザー管理及び認証システムはアプリケーションまたはサービスに結果を転送してよい。

アプリケーションまたはサービスは、管理者によって操作される１つまたは複数のディレクトリにアクセストークンを生成するためにこのプロセスを繰り返すことができる。したがって、管理者は、アプリケーションまたはサービスを使用し、複数のディレクトリにアクセスする及び／または複数のディレクトリを管理することができる。

追加の実施形態では、ユーザー管理及び認証システムは、単一因子認証及び／または多因子認証をサポートする（例えば、認証情報の複数の異なるセットは、アクセスが許可される前に認証のためにユーザーによって提供されてよい）。ユーザー管理及び認証システムは、ユーザーインタフェース及び／またはＡＰＩを介してどちらかのタイプの認証をサポートしてよい。ユーザー管理及び認証システムは、単一サインオンをサポートしてもよい（例えば、管理者は一度ログインし、ディレクトリがアクセスされるたびに再びログインするようにプロンプトを表示されることなく、すべての適切なディレクトリへのアクセスを獲得できてよい。

システム構成要素
図１Ａは、一実施形態に従ってディレクトリサービスを提供する多様な領域を有する管理ディレクトリサービス環境を示す。図１Ａに示される管理ディレクトリサービス環境は、多様なユーザーデバイス１０２、ルートサービス１３０、サードパーティアプリケーションサーバ１０８、多様なＣＤＮ１５０Ａ〜Ｂ、多様なコンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ、及び多様なスケーラブルなプライベートサーバシステム１７０を含む。多様なユーザーデバイス１０２、ルートサービス１３０、サードパーティアプリケーションサーバ１０８、及び多様なＣＤＮ１５０Ａ〜Ｂは、１つまたは複数の通信ネットワーク１１０を介して互いと通信してよい。ネットワーク１１０は、インターネット等、おそらく多様な別々のパーティによって操作されるリンクされたネットワークの公的にアクセス可能なネットワークであってよい。他の実施形態では、ネットワーク１１０は、それぞれがインターネットへのアクセス及び／またはインターネットからのアクセスを有する、プライベートネットワーク、パーソナルエリアネットワーク、ローカルエリアネットワーク、広域ネットワーク、ケーブルネットワーク、衛星ネットワーク、セルラー電話網等、またはその組合せを含んでよい。

コンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ及び多様なプライベートサーバシステム１７０Ａ〜Ｃは、それぞれ別々の通信ネットワーク１６０Ａ〜Ｃを介して互いと通信してよい。ネットワーク１６０Ａ〜Ｃは、２つのエンドポイント、つまりコンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ、及びネットワーク１６０Ａ〜Ｃと関連付けられたプライベートサーバシステム１７０Ａ〜Ｃを有するプライベートネットワークであってよい。多様なプライベートサーバシステム１７０Ａ〜Ｃは、ネットワーク１６０Ａ〜Ｃを共有しないことがある。むしろ、各ネットワーク１６０Ａ〜Ｃは、特定のプライベートサーバシステム１７０Ａ〜Ｃに専用であってよい。

当業者によって理解されるように、管理ディレクトリサービス環境は、任意の数の別個のユーザーデバイス１０２、コンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ、ＣＤＮ１５０Ａ〜Ｂ、及び／またはプライベートサーバシステム１７０Ａ〜Ｃを含んでよい。別々のコンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃは、それらが現在のまたは潜在的なユーザーデバイス１０２またはプライベートサーバシステム１７０Ａ〜Ｃのグループに（地理的な意味またはネットワーキングの意味のどちらかで）近くなるように位置してよい。

実施形態では、管理ディレクトリサービスは、異なる地理的地域１２０Ａ〜Ｂに分散される。例えば、１つまたは複数のＣＤＮ１５０Ａ〜Ｂはバックエンドサーバと構成されてよく、バックエンドサーバは、コンピューティングリソースサービスプロバイダシステム１４０Ａ〜Ｃ等の管理ディレクトリサービスを実装するシステムと通信してよい。コンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃは、マルチリージョンの分散コンピュータシステムの単一の領域で動作してよく、単一の領域の他のデバイスまたはシステムだけと通信してよい。したがって、ＣＤＮ１５０Ａまたは１５０Ｂは領域エンドポイントと見なされてよく、コンピューティングリソースサービスプロバイダシステム１４０Ａ〜Ｃは単一エンドポイントと見なされてよい。

ユーザーデバイス１０２は、メンバーサーバ、パーソナルコンピューティング装置、端末コンピューティング装置、ラップトップコンピューティング装置、タブレットコンピューティング装置、電子ブックリーダー、モバイル装置（例えば、携帯電話、メディアプレーヤー、ハンドヘルドゲーム機等）、ネットワークアクセス及びプログラム実行機能を有するウェアラブルデバイス（例えば、「スマートウォッチ」または「スマート眼鏡」）、ワイヤレス機器、セットトップボックス、ゲームコンソール、娯楽システム、ネットワークアクセス機能及びプログラム実行機能を有するテレビ（例えば、「スマートテレビ」）、及び多様な他の電子機器及び器具を含んだ多岐に渡るコンピューティング装置を含むことがある。個々のユーザーデバイス１０２は、１つまたは複数のディレクトリを管理するために、ネットワーク１１０を介してコンピューティングリソースサービスプロバイダシステム１０４と通信するためにアプリケーションを実行してよい。例えば、アプリケーションは、ユーザーデバイス１０２にインストールされるスタンドアロンアプリケーションであってよい。別の例として、アプリケーションは、コンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ、サードパーティアプリケーションサーバ１０８、及び／または別のコンピューティングシステム（不図示）によってホストされるアプリケーションまたはサービス（例えば、ウェブサービス）にアクセスするブラウザ（例えば、ウェブブラウザ）であってよい。

サードパーティアプリケーションサーバ１０８は、アプリケーションまたはサービス（例えば、ディレクトリ管理サービス、文書共有サービス、ワープロアプリケーション等）をホストし、アプリケーションまたはサービス（例えば、ディレクトリ管理サービス、文書共有サービス、ワープロアプリケーション等）へのアクセスを提供するコンピューティングシステムであってよい。例えば、サードパーティアプリケーションサーバ１０８は、ホストされるアプリケーションまたはサービスにアクセスを提供する異なる組織名と関連付けられた多様なページをホストしてよい。ページは、以下のフォーマット、つまり＜ｏｒｇａｎｉｚａｔｉｏｎ ｎａｍｅ＞．＜ａｐｐｌｉｃａｔｉｏｎ ｈｏｓｔ＞．ｃｏｍのＵＲＬを有してよい。したがって、サードパーティアプリケーションサーバ１０８は、１つまたは複数のエンティティと関連付けられたページにアクセスしようと試みている管理者またはユーザーのためのグローバルエンドポイントとして働いてよい。サードパーティアプリケーションサーバ１０８によってホストされる単一ページは、ユーザーの既存の認証情報を使用し、サードパーティアプリケーションサーバ１０８によってホストされるアプリケーションまたはサービスへのアクセスをそのユーザーに提供することを希望するエンティティによって作成されるディレクトリ等の複数のディレクトリと関連付けられてよい。サードパーティアプリケーションサーバ１０８は、領域１２０Ａまたは領域１２０Ｂ等の任意の領域に位置してよい。

ユーザーデバイス１０２は、ネットワーク１１０を介してホストされているアプリケーションまたはサービスにアクセスしてよい。アプリケーションまたはサービスは、コンピューティングリソースサービスプロバイダシステム１０４を操作するエンティティに所属してよい、またはサードパーティエンティティによって操作されてよい。実施形態では、コンピューティングリソースサービスプロバイダシステム１０４に登録しているサードパーティサーバ１０８またはコンピューティングリソースサービスプロバイダシステム１０４によって提供されるアプリケーションまたはサービスは、本明細書に説明される機能にアクセスしてよい。コンピューティングリソースサービスプロバイダシステム１０４に登録していない、及び／またはコンピューティングリソースサービスプロバイダシステム１０４の管理者によって承認されていないアプリケーションまたはサービスは、本明細書に説明される機能にアクセスすることを禁じられることがある。

プライベートサーバシステム１７０Ａ〜Ｃは、エンティティと関連付けられたディレクトリを記憶してよい。例えば、プライベートサーバシステム１７０Ａ〜Ｃは、組織のためにオンプレミスディレクトリを記憶してよい。いくつかの実施形態では、プライベートサーバシステム１７０Ａ〜Ｃは、同じエンティティのために複数のディレクトリを記憶できる。ディレクトリは、図１Ｂに関して以下により詳しく説明されるように、それぞれのコンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃによって管理されてよい。

ルートサービス１３０は、ディレクトリが位置する領域を識別するのに役立つことがあるＣＤＮ１５０Ａ〜Ｂを識別するのに役立ってよい。ルートサービス１３０（例えば、ドメインネームシステム（ＤＮＳ）ウェブサービス）は、ＤＮＳエントリ（例えば、対応するＩＰアドレス）とのアプリケーションサーバ１４０によって作成される組織名のマッピングを含むことがある。例えば、マッピングは、組織名が組織（例えば、複数のエンティティ）のために作成されるときにルートサービス１３０に記憶されてよい。ルートサービス１３０は、１つまたは複数のＣＤＮ１５０Ａ〜ＢのアドレスとのＤＮＳエントリのマッピングをさらに含んでよい。したがって、ルートサービス１３０は、組織名と関連付けられたＤＮＳエントリを識別するために問い合わせを行われることがあり、ＤＮＳエントリと関連付けられた１つまたは複数のＣＤＮ１５０Ａ〜Ｂのアドレスを識別するために問い合わせを行われることがある。ルートサーバ１３０は、次いでユーザーデバイス１０２（例えば、ブラウザ）上で実行されたアプリケーションを識別されたＣＤＮ１５０Ａ〜Ｂに向けることができる。識別されたＣＤＮ１５０Ａ〜Ｂの内の１つは、記憶されたマッピングに基づいて領域サービス（例えば、コンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃ）にユーザーデバイス１０２を向けることができ、領域サービスは組織名に基づいてディレクトリの場所を識別できる。

例えば、領域１２０Ａの中のディレクトリまたは他のコンピューティングシステムエンティティは、領域１２０Ａの中のコンピューティングシステムエンティティが利用できる、及び／または領域１２０Ａの外のコンピューティングシステムエンティティが利用できない一意の識別子（例えば、ユニフォームリソースアイデンティファイア、ＵＲＬ、または任意の他のリソース識別子）を有してよい。上述されたように、一意の識別子は、（例えば、エンティティのためのディレクトリの特定の場所及びタイプが非表示のままであるように）セキュリティのために、及び／または一意の識別子が変化することがあるため、領域１２０Ａ外のコンピューティングシステムエンティティは利用できないことがある。一意の識別子は利用できないことがあるため、ＣＤＮ１５０ＡまたはＣＤＮ１５０Ａを介するコンピューティングリソースサービスプロバイダシステム１０４Ａは、アプリケーションサーバ１４０及びルートサービス１３０等の分散コンピューティングシステムの多様なコンピューティングシステムに対して、ディレクトリの実際の一意の識別子に対するエイリアスとしての機能を果たす異なる一意の識別子を提供してよい。したがって、アプリケーションサーバ１４０がエイリアス識別子を使用し、ディレクトリにアクセスする要求を生成する場合、ルートサービス１３０は適切なＣＤＮ１５０Ａまたは１５０Ｂに要求をリダイレクトできる。ＣＤＮ１５０Ａまたは１５０Ｂは、次いでエイリアス識別子のコンテンツに基づいて適切なディレクトリを決定できるコンピューティングリソースサービスプロバイダシステム１０４Ａ〜Ｃを識別してよい。

例のネットワーク実施形態
図１Ｂは、本開示のディレクトリ管理機能、ならびにユーザー、グループ、及びデバイスの管理及び認証機能がいくつかの実施形態に従って実装できる例のネットワーク環境を示す。図１Ｂに示されるネットワーク環境は、簡略にするために１つの領域の構成要素を含む。本明細書で使用されるように、用語「ディレクトリ」は概してコンピュータネットワークのユーザー、デバイス、アプリケーション、及び他の共通のリソースについてのデータの編成された集合体を指す。コンピュータネットワーク（またはそのなんらかのサブセット）上の各リソースはディレクトリ内でオブジェクトとして表現されてよく、特定のリソースについての情報（例えば、名前、アドレス、許可等）はオブジェクトの属性として記憶できる。情報は、十分な許可を有するユーザーだけが情報にアクセスする、情報を修正する、またはそれ以外の場合情報を使用することができるように、オブジェクトの中にまたはオブジェクトと関連して安全に記憶できる。

図示されるように、ネットワーク環境は多様なユーザーデバイス１０２、コンピューティングリソースサービスプロバイダシステム１０４、組織１０６、及び１つまたは複数のネットワーク１１０を介して通信するサードパーティアプリケーションサーバ１０８を含む。コンピューティングリソースサービスプロバイダシステム１０４は、アプリケーション、ディレクトリ管理サービス、ユーザー、グループ、及びデバイスの管理及び認証サービス、ならびに／または他のネットワークベースのサービスを多様な組織または他のカスタマに提供できる。組織１０６Ａ〜Ｃ（または他のカスタマ）は、組織と関連付けられたユーザーにアプリケーションアクセスを提供し、組織のディレクトリを管理する等のためにコンピューティングリソースサービスプロバイダシステム１０４を利用できる。個々のユーザーは、そのそれぞれの組織１０６Ａ〜１０６Ｃからの認証情報を使用し、コンピューティングリソースサービスプロバイダシステム１０４（またはサードパーティアプリケーションサーバ１０８）によってホストされるアプリケーションにアクセスするためにユーザーデバイス１０２を使用できる。さらに、コンピューティングリソースサービスプロバイダシステム１０４は、それぞれの組織の裁量でアプリケーションに多様な組織１０６Ａ〜Ｃのディレクトリへのアクセスを提供できる。

いくつかのユーザーデバイス１０２は、特定の組織１０６Ａ〜Ｃと関連付けられてよい。例えば、組織は、オンプレミスのままである、また従業員、管理者、または組織と関連付けられた他のユーザーによって主にオフプレミスで使用される多様なユーザーデバイス１０２を有してよい。いくつかの実施形態では、ユーザーデバイス１０２のいくつかまたはすべては、ディレクトリを管理することまたは特定の組織１０６Ａ〜Ｃもしくはコンピューティングリソースサービスプロバイダシステム１０４の他のカスタマと関連付けられた認証情報を使用してアプリケーションにアクセスすることを含んでよい多様なタスクを実行するために任意の数のユーザーによって使用されるパブリックコンピュータまたはホームコンピュータ等の任意の組織から離れていてよい。

コンピューティングリソースサービスプロバイダシステム１０４は、アプリケーション１４４（ワープロアプリケーション、写真編集アプリケーション、電子メールアプリケーション等）をホストするまたはそれ以外の場合アプリケーション１４４にアクセスを提供する、別々のカスタマ組織１０６Ａ〜Ｃのディレクトリを管理する、及び／または他のネットワークベースのサービス及びリソース（例えば、文書共有サービス、バーチャルマシンサービス等）を提供するように構成されたコンピューティングシステムであることがある。例えば、コンピューティングリソースプロバイダシステム１０４は、通信ネットワーク１１０を介してアクセスされてよいサーバまたはサーバのグループであることがある。コンピューティングリソースサービスプロバイダシステム１０４は、管理ディレクトリシステムまたはサービス１４０、ユーザー管理及び認証モジュール１４２、ならびに組織１０６及びユーザーデバイス１０２によってアクセスできる１つもしくは複数のアプリケーションまたはアプリケーションサーバ１４４等の、本明細書に説明される多様な機能を提供するためにいくつかの構成要素を含むことがある。また、コンピューティングリソースサービスプロバイダシステム１０４は、以下に説明されるように、組織１６０Ｂのためのオフプレミスディレクトリ等の多様なオフプレミスディレクトリ１４６を記憶してもよい。いくつかの実施形態では、コンピューティングリソースサービスプロバイダシステム１０４は、上述され、より詳細に以下に説明される機能を提供するため、追加の構成要素または図１に示されるよりも少ない構成要素を含んでよい。

本明細書に説明されるように、用語「オフプレミスディレクトリ」は、係るディレクトリを組織の構内に位置するディレクトリから区別するために、ディレクトリが関連付けられる組織から遠く離れたディレクトリを指す。したがって、ディレクトリはコンピューティングリソースサービスプロバイダシステム１０４の構内で物理的に保管されてよいが、それにも関わらず、ディレクトリは、それが属する組織（例えば、ディレクトリによって記述されるネットワークを所有するまたは運用する組織）に関してオフプレミスであるため、オフプレミスディレクトリと呼ばれることがある。さらに、ディレクトリはコンピューティングリソースサービスプロバイダシステム１０４の構内から離れて物理的に保管されてよいが、ディレクトリは、それにも関わらず、ディレクトリが、それが属する組織に関してオンプレミスであるため、オンプレミスディレクトリと呼ばれることがある。

例示的には、管理者は、組織１０６Ａ〜Ｃの内の１つ等の管理者の組織によって所有されるまたは運用される１つまたは複数のディレクトリを管理するためにユーザーデバイス１０２によって実行されるアプリケーションを使用してよい。アプリケーションは、管理ディレクトリサーバ１４０並びに／またはユーザー管理及び認証モジュール１４２と対話してよい。管理ディレクトリサービス１４０は、管理ディレクトリサービスを実装するコンピューティングシステムであってよい。実施形態で、管理ディレクトリサービス１４０は、１つまたは複数のディレクトリを作成し、監視し、管理するように構成される。例えば、管理ディレクトリサービス１４０は、オフプレミスディレクトリ１４６及び／またはオンプレミスディレクトリ１６０と通信し、オフプレミスディレクトリ１４６及び／またはオンプレミスディレクトリ１６０を管理してよい。上述されたように、管理者は、ユーザーデバイス１０２がメンバーサーバである場合に、ディレクトリを作成する、監視する、及び／または管理するために管理ディレクトリサービス１４０を使用してよい。しかしながら、ユーザーデバイス１０２がメンバーサーバではない場合、管理者は、ユーザー管理及び認証モジュール１４２によって提供されるＡＰＩを介してディレクトリを作成し、監視し、及び／または管理してよい。

ユーザー管理及び認証モジュール１４２は、ユーザー、グループ、及びデバイスの管理及び認証システムを実装するコンピューティングシステムであってよい。実施形態では、ユーザー管理及び認証モジュール１４２は、管理者が、上述されたＡＰＩ等のＡＰＩのセットを介して、メンバーサーバではない（例えば、それぞれのディレクトリのドメインと関連付けられていない）ユーザーデバイス１０２で１つまたは複数のディレクトリを管理できるようにする。また、ユーザー管理及び認証モジュール１４２は、ユーザーデバイス１０２によって実行されるアプリケーションまたは実行されたアプリケーションによってアクセスされるアプリケーションもしくはサービスが、たとえ実行されたアプリケーションまたはアクセスされたアプリケーションもしくはサービスがディレクトリの作成されたユーザーのリストに直接的なアクセスを有さない場合にも、ディレクトリのコンテンツまたはリソースにアクセスできるようにするための許可機構及び認証機構を提供してもよい。例えば、ユーザー管理及び認証モジュール１４２は管理ディレクトリサービス１４０と通信してよく、ユーザーデバイス１０２が管理ディレクトリサービス１４０によって管理される１つまたは複数のディレクトリを管理できるように、ユーザーデバイス１０２と管理ディレクトリサービス１４０との間のインタフェースとしての機能を果たしてよい。ユーザーデバイス１０２は、ユーザー管理及び認証モジュール１４２によって提供されるＡＰＩを呼び出すことができ、ユーザー管理及び認証モジュール１４２は呼び出されたＡＰＩによって示されるアクションを実行するように管理ディレクトリサービス１４０に命令できる。ユーザーデバイス１０２と管理ディレクトリサービス１４０とユーザー管理及び認証モジュール１４２との間の対話は、図２Ａ〜図２Ｂに関して以下により詳細に説明される。

追加の実施形態では、ユーザー管理及び認証モジュール１４２は単一因子認証及び／または多因子認証をサポートする。ユーザー管理及び認証モジュール１４２は、ユーザーインタフェース及び／またはＡＰＩを介してどちらかのタイプの認証をサポートしてよい。また、ユーザー管理及び認証モジュール１４２は、単一サインオンをサポートしてもよい（例えば、管理者は一度ログインし、ディレクトリがアクセスされるたびに再びログインするようにプロンプトを表示されることなくすべての適切なディレクトリへのアクセスを獲得できてよい）。

コンピューティングリソースサービスプロバイダシステム１０４は単一のコンピューティング装置であってよい、またはコンピューティングリソースサービスプロバイダシステム１０４は、サーバシステムとして集合的に動作するために論理的にまたは物理的にともにグループ化される、コンピュータサーバ等の複数の別個のコンピューティング装置を含んでよい。コンピューティングリソースサービスプロバイダシステム１０４の構成要素は、ソフトウェアが必要ではないように、またはハードウェア及びソフトウェアの組合せとして、それぞれアプリケーションに特有のハードウェア（例えば、１つまたは複数のＡＳＩＣを有するサーバコンピューティング装置）で実装できる。さらに、コンピューティングリソースサービスプロバイダシステム１０４のモジュール及び構成要素は、１つのサーバコンピューティング装置で結合できる、または個別にもしくはいくつかのサーバコンピューティング装置上でグループに分離できる。

さらに、複数の（例えば、２つ以上の）コンピューティングリソースサービスプロバイダシステム１０４が使用されてよい。例えば、コンピューティングリソースサービスプロバイダシステム１０４は別々の領域に位置してよく、互いと対話することもあれば、対話しないこともある。別々のコンピューティングリソースサービスプロバイダシステム１０４は、それらが現在のまたは潜在的なユーザーデバイス１０２または組織１６０Ａ〜Ｃのグループに（地理的な意味またはネットワーキングの意味のどちらかで）近くなるように位置してよい。

いくつかの実施形態では、コンピューティングリソースサービスプロバイダシステム１０４によって提供される機能及びサービスは、通信ネットワーク１１０を介して消費可能なウェブサービスとして実装されてよい。追加の実施形態では、コンピューティングリソースサービスプロバイダシステム１０４は、ホストされているコンピューティング環境で実装されるもう１つのバーチャルマシンによって提供される。ホストされるコンピューティング環境は、コンピューティングリソースがコンピューティング装置、ネットワーキングデバイス、及び／またはストレージデバイスを含んでよい、１つまたは複数の急速にセットアップされ、リリースされるコンピューティングリソースを含んでよい。また、ホストされるコンピューティング環境は、クラウドコンピューティング環境と呼ばれることもある。

組織１０６Ａ〜Ｃは、コンピューティングリソースサービスプロバイダシステム１０４の多様なカスタマに対応できる。用語「組織」が本明細書で使用されるが、係る組織を含んだ機能は、さらにまたは代わりに（オンプレミスであるのか、それともオフプレミスであるのかに関わりなく）ディレクトリを有し、ディレクトリを管理し、コンピューティングリソースサービスプロバイダ１０４またはサードパーティアプリケーションサーバ１０８によってホストされるアプリケーションによるディレクトリへのアクセスを制御するためにコンピューティングリソースサービスプロバイダシステム１０４を使用することを希望する任意のカスタマを含んでよい。

オンプレミスディレクトリ１６０を維持する組織は、ディレクトリ１６０が記憶される１つまたは複数のサーバを有してよい。例えば、組織１０６Ａは、多様なサーバを含むデータセンタを有してよく、オンプレミスディレクトリ１６０はサーバの内の１つまたは複数に記憶されてよい。オフプレミスディレクトリを維持する組織は、オフプレミスディレクトリデータストア１４６にオフプレミスディレクトリを記憶してよいコンピューティングリソースサービスプロバイダシステム１０４のサービスを利用してよい。例えば、組織１０６Ｂは、オンプレミスディレクトリをまったく維持しないことがあるが、組織のディレクトリ１４６を維持するために代わりにコンピューティングリソースサービスプロバイダシステム１０４に頼ることがある。いくつかの組織は、オンプレミス及び／またはオフプレミスに複数のディレクトリを維持することを選んでよい。例えば、組織１０６Ｃは、それぞれ（上述された）組織１０６Ａと同様に複数のオンプレミスディレクトリ１６０を記憶することがあり、組織１０６Ｃはオフプレミスディレクトリ１４６を維持するためにコンピューティングリソースサービスプロバイダシステム１０４を利用することを選んでもよい。この例のコンピューティングリソースサービスプロバイダシステム１０４によって維持されるディレクトリ１４６は（例えば、バックアップのためまたは災害復旧のために）オンプレミスディレクトリのミラーもしくはサブセットであってよい、またはコンピューティングリソースサービスプロバイダシステム１０４によって維持されるディレクトリ１４６は完全に別のディレクトリ（例えば、オンプレミスディレクトリ１６０とは異なるコンピューティングリソースのディレクトリ）であってよい。

通信ネットワーク１１０は、インターネット等、おそらく多様な別個のパーティによって運用されるリンクされたネットワークの内の公的にアクセス可能なネットワークであってよい。いくつかの実施形態では、通信ネットワーク１１０は、インターネット、プライベートネットワーク、パーソナルエリアネットワーク、ローカルエリアネットワーク、広域ネットワーク、ケーブルネットワーク、衛星ネットワーク、セルラー電話ネットワーク等、もしくはその組合せであってよい、またはインターネット、プライベートネットワーク、パーソナルエリアネットワーク、ローカルエリアネットワーク、広域ネットワーク、ケーブルネットワーク、衛星ネットワーク、セルラー電話ネットワーク等、もしくはその組合せを含んでよい。

ユーザー管理及び認証モジュールとの間の対話の例
図２Ａは、ユーザーデバイスによってアクセスされるサービスにトークンを提供するプロセス中のユーザー管理及び認証モジュール１４２との間の対話を示す。図２Ａに示されるように、ディレクトリサービスモジュール１４０は複数のエージェント２１５Ａ〜Ｂと対話してよく、エージェント２１５Ａ〜Ｂはユーザー管理及び認証モジュール１４２と対話してよい。

実施形態では、各エージェント２１５Ａ〜Ｂは、１つまたは複数の別々のディレクトリと関連付けられ、管理のためにその関連付けられたディレクトリと直接的にインタフェースをとる。エージェント２１５Ａ〜Ｂは、オンプレミスディレクトリ及び／またはオフプレミスディレクトリと関連付けられて、オンプレミスディレクトリ及び／またはオフプレミスディレクトリと通信してよい。例えば、エージェント２１５Ａはオフプレミスディレクトリ１４６と関連付けられてよく、エージェント２１５Ｂはオンプレミスディレクトリ１６０と関連付けられてよい。管理ディレクトリサービス１４０は、エージェント２１５Ａ〜Ｂを作成する、監視する、及び／または管理するように構成されてよい。２つのエージェント２１５Ａ〜Ｂが示されているが、これは制限的となることを意図されていない。コンピューティングリソースサービスプロバイダシステム１０４は、任意の数のエージェント（例えば、管理ディレクトリサービス１４０によって管理されるすべてのディレクトリを処理するために十分ないくつかのエージェント）を含んでよい。

エージェント２１５Ａ〜Ｂは、ユーザー管理及び認証モジュール１４２に対してなされるＡＰＩコールの変換バージョンを受け取ってよい。ユーザー管理及び認証モジュール１４２に対してなされるＡＰＩの変換されたバージョンは、管理ディレクトリサービス１４０によって実行できるディレクトリ特有のＡＰＩコール（例えば、ＬＤＡＰ、ケルベロス、ＤＮＳ他）であってよい。一例として、ＡＰＩコールの変換は、ディレクトリサービストークンへアクセストークンをマッピングすることを含んでよい（例えば、ケルベロストークン、ユーザー名とパスワードの対、ＮＴＬＡＮマネージャ（ＮＴＬＭ）ハッシュ等を含んでよい）。

実施形態では、ユーザー管理及び認証モジュール１４２は、コンソール２２０、制御プレーン２２５、ならびにロードバランサ２３０及び２３５を含む。コンソール２２０は、ユーザーデバイス１０２に送信されるユーザーインタフェースを生成するように構成されてよい。ユーザーインタフェースは、ユーザーデバイス１０２が、ログインする、パスワードをリセットする、パスワードを変更する、及び／または本明細書に説明される他の操作を実行するために、ユーザー管理及び認証モジュール１４２によって提供されるＡＰＩを呼び出すときにユーザーデバイス１０２に送信されてよいログインページであってよい。コンソール２２０は、例えば新しいユーザーが作成されるとき等に、ユーザーデバイス１０２に送信できるリンク（例えば、ユニフォームリソースロケータ（ＵＲＬ））を生成してもよい。また、リンクは有限の期間（例えば、７日間、２週間等）有効であってよく、選択時、管理者がユーザープロファイル情報等の追加の情報を入力できるようにするコンテンツページに、ユーザーデバイス１０２によって実行されるアプリケーションをリダイレクトしてよい。また、コンソール２２０は、ユーザーデバイス１０２がパスワードをリセットするためにユーザー管理及び認証モジュール１４２によって提供されるＡＰＩを呼び出すときに管理者と関連付けられたアカウントへのリンクを含む電子メッセージ（例えば、ｅメール、テキストメッセージ等）を送信してもよい。電子メッセージは、パスワードリセットプロセスを完了するためにユーザーデバイス１０２によって使用できるワンタイムユーザートークンを含んでよい。

制御プレーン２２５は、ユーザーデバイス１０２にＡＰＩを露呈するように構成されてよい。例えば、制御プレーン２２５は本明細書に説明されるＡＰＩのようなＡＰＩを露呈してよい。また、制御プレーン２２５はエージェント２１５Ａ〜Ｂと対話するように構成されてもよい。例えば、制御プレーン２２５はユーザーデバイス１０２から受け取られたＡＰＩコールを、管理ディレクトリサービス１４０によって実行できるディレクトリ特有のＡＰＩコールに変換し、適切なエージェント２１５Ａ〜Ｂ（例えば、ＡＰＩコールに従ってアクションが実行されるディレクトリと関連付けられたエージェント）にディレクトリ特有のＡＰＩコールを提供してよい。制御プレーン２２５は、図２Ｂに関して以下により詳細に説明される。

コンソール２２０及び制御プレーン２２５は、それぞれロードバランサ２３０または２３５の後方にあってよい。コンソール２２０及び制御プレーン２２５はそれぞれ複数のコンピューティングリソースを含んでよく、ロードバランサ２３０及び２３５はリソース使用を最適化するため、スループットを最大化するため、及び／またはあらゆる単一のリソースが過重負担になるリスクを最小限に抑えるために複数のコンピューティングリソースにわたって作業負荷を分散してよい。例えば、ロードバランサ２３０及び２３５は、ユーザーデバイス１０２からＡＰＩコールを受け取って、コンソール２２０または制御プレーン２２５の適切なコンピューティングリソースにＡＰＩコールを分散してよい。

（１）で、管理者は最初に、ユーザーデバイス１０２を介して自分の認証情報を認証するためにロードバランサ２３５と通信してよい。ロードバランサ２３５はコンソール２２０に認証要求及び認証情報を転送してよく、コンソール２２０はロードバランサ２３０に認証要求及び認証情報を転送してよい。ロードバランサ２３０は、制御プレーン２２５に認証要求及び認証情報を転送してよい。制御プレーン２２５は認証情報と関連付けられたディレクトリを決定し、適切なエージェント２１５Ａまたは２１５Ｂに認証要求及び認証情報を送信してよい。いったん適切なエージェント２１５Ａまたは２１５Ｂが認証要求及び認証情報を受け取ると、エージェント２１５Ａまたは２１５Ｂは、その関連付けられたディレクトリ（例えば、オフプレミスディレクトリ１４６またはオンプレミスディレクトリ１６０）に接触することによって認証を実行してよい。

（２）で、管理者の認証情報を認証できる旨の判断に応えて、制御プレーン２２５は認証コードを生成する。制御プレーン２２５は、ユーザーデバイス１０２に転送するためにロードバランサ２３０に認証コードを送信する。

（３）で、ユーザーデバイス１０２はサードパーティアプリケーションサーバ１０８によって提供されるサービスにアクセスする。図示されていない代替実施形態では、ユーザーデバイス１０２は、コンピュータリソースサービスプロバイダシステム１０４によって提供されるアプリケーション１４４の中のアプリケーションにアクセスする。

（４）で、アクセスされたサービスは、アクセストークン及び／またはリフレッシュトークンを受け取るためにロードバランサ２３０に認証コードを送信する。ロードバランサ２３０は、制御プレーン２２５に認証コードを転送してよい。

（５）で、制御プレーン２２５は、受け取られた認証コードに基づいてアクセストークン及び／またはリフレッシュトークンを生成する。制御プレーン２２５は、認証コードが期限切れ前に受け取られる場合、アクセストークンを生成してよい。制御プレーン２２５は、アクセスされたサービスに転送するためにロードバランサ２３０にアクセストークン及び／またはリフレッシュトークンを送信してよい。

図２ｂは、トークンを提供し、ＡＰＩコールを処理するプロセス中のユーザー管理及び認証モジュール１４２との間の対話を示す。図２Ｂに示されるように、制御プレーン２２５は、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０、認証ＡＰＩモジュール２４５、認証情報マッパーモジュール２５０に対する認証トークン、ディレクトリルックアップモジュール２５５、ディレクトリデータベース２６０、サービスヘルス監視モジュール２６５、及び認証寿命管理リーパーモジュール２７０を含んでよい。不図示の代替実施形態では、ディレクトリルックアップモジュール２５５は、エージェント２１５Ａまたは２１５Ｂの構成要素である。

認証ＡＰＩモジュール２４５は、認証コード、リフレッシュトークン、及び／またはアクセストークンを生成してよい。例えば、認証ＡＰＩモジュール２４５は管理者認証情報、ドメインへのアクセスを要求しているアプリケーションサーバ１４０によってホストされるアプリケーションまたはサービスを識別するクライアント識別、リダイレクトページ（例えば、ユーザー管理及び認証モジュール１５０がユーザーデバイス１０２に、いったん認証が完了するとアクセスするように命令する必要があるアプリケーションまたはサービスと関連付けられたページ）、及び／または組織名または識別子（例えば、グローバルエンドポイントまたはディレクトリ識別子を識別する識別子）を受け取ってよい。認証ＡＰＩモジュール２４５は、組織名と関連付けられるディレクトリと対応するエージェント２１５Ａまたは２１５Ｂに認証情報を送信してよい。エージェント２１５Ａまたは２１５Ｂは、認証情報が認証できるかどうか（例えば、管理者がディレクトリへのアクセスを有するかどうか）を判断するためにディレクトリサービスモジュール１４０に認証情報を渡してよい。認証情報が認証できる場合、認証ＡＰＩモジュール２４５が通知され、認証コード（例えば、ＯＡｕｔｈコード）を生成する。

（１）で、上述されたように、認証コードは有限期間（例えば、１０分、１時間等）有効である使い捨てのコードであってよい。認証ＡＰＩモジュール２４５は、ユーザーデバイス１０２に認証コードを送信してよい。また、認証ＡＰＩモジュール２４５は、リダイレクトページにアクセスする命令をユーザーデバイス１０２に送信してよい。

（２）で、ユーザーデバイス１０２は、サードパーティアプリケーションサーバ１０８によって提供されるサービスにアクセスする。不図示の代替実施形態では、ユーザーデバイス１０２はコンピュータリソースサービスプロバイダシステム１０４によって提供されるアプリケーション１４４の中のアプリケーションにアクセスする。

（３）で、認証ＡＰＩモジュール２４５は、アクセスされたサービス（例えば、ブラウザを介してアクセスされる）から認証コードを受け取る。例えば、認証ＡＰＩモジュール２４５は、ｇｅｔＴｏｋｅｎ ＡＰＩが呼び出される場合、認証コードを受け取ってよい（例えば、認証コードがパラメータとして含まれてよい）。

期限が切れていない認証コードが受け取られると、認証ＡＰＩモジュール２４５はアクセストークン及び／またはリフレッシュトークンを生成してよい。アクセストークン及び／またはリフレッシュトークンは、認証情報及び／または組織名に基づいて生成されてよい。例えば、開封時、アクセストークン及び／またはリフレッシュトークンは認証コード（したがって認証情報及び認証情報と関連付けられた管理者）、ならびにトークンと関連付けられた組織名を示してよい。アクセストークンは、アクセスされたサービスが、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０によって提供されるＡＰＩのセットを介して組織名と関連付けられたディレクトリを管理できるようにしてよい。アクセストークンは、管理者によって定められた期間または有限期間（例えば、１時間、１日等）有効であってよい。リフレッシュトークンは管理者によって定められた期間または有限期間（例えば、１週間、１カ月等）有効であってよく、いったん以前のアクセストークンが期限切れになると、新しいアクセストークンを受け取るためにユーザーデバイス１０２及び／またはアクセスされたアプリケーションまたはサービスによって使用できる。いくつかの実施形態では、リフレッシュトークンは任意の期間、有効でなくてよい（例えば、アクセストークンがいったん期限切れになると、アクセストークンはリフレッシュされないことがある）。

（４）で、いくつかの実施形態では、認証ＡＰＩモジュール２４５は、アクセストークン、リフレッシュトークン、認証情報、及び／またはディレクトリ識別子を認証情報マッパーモジュール２５０に対する認証トークンに送信する。認証情報マッパーモジュール２５０に対する認証トークンは、アクセストークン及び／またはリフレッシュトークンに、認証情報及び／または組織名（または組織のエンティティの内の１つと関連付けられたディレクトリの識別子）をマッピングし、ディレクトリデータベース２６０にこのマッピングを記憶するために基本的なディレクトリ論理を使用してよい。

（５）で、認証ＡＰＩモジュール２４５はアクセストークン及び／またはリフレッシュトークンをアクセスされたサービスに送信してもよい。ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、上述されたＡＰＩの内の１つまたは複数を提供してよく、アクセスされたサービスは提供されたＡＰＩの内の１つまたは複数を呼び出すためにアクセストークン及び／または他の操作特有のパラメータを使用してよい。不図示のいくつかの実施形態では、認証ＡＰＩモジュール２４５は、（４）に関して説明された操作を実行する前に、アクセスされたサービスにアクセストークン及び／またはリフレッシュトークンを送信する。

（６）で、実施形態では、呼び出し側サービスからのアクセストークンを含むＡＰＩコールを受け取ると同時に、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０はディレクトリルックアップモジュール２５５に問い合わせを行うことによってアクセストークンと関連付けられたディレクトリを識別する。例えば、ディレクトリルックアップモジュール２５５はディレクトリデータベース２６０にアクセストークンを渡し、アクセストークンと関連付けられたディレクトリを識別し、識別されたディレクトリをユーザー、グループ、及びパスワードＡＰＩモジュール２４０に送り返してよい。

（７）で、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、次いで識別されたディレクトリと関連付けられたエージェント２１５Ａまたは２１５Ｂを識別し、ディレクトリ特有のＡＰＩコールにＡＰＩコールを変換し、ディレクトリ特有のＡＰＩコール及びその操作特有のパラメータを適切なエージェント２１５Ａまたは２１５Ｂに渡してよい。ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、ディレクトリルックアップモジュール２５５によって提供される情報に基づいてディレクトリ特有のＡＰＩコールにＡＰＩコールを変換する方法を決定してよい。不図示の代替実施形態では、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、（例えば、内部ルックアップテーブルまたはデータベースを介して）ディレクトリルックアップモジュール２５５に問い合わせを行うことなくアクセストークンと関連付けられたディレクトリを直接的に識別する。

上述されたように、エージェント２１５Ａ〜Ｂは、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０によって受け取られるＡＰＩコールから変換されたディレクトリ特有のＡＰＩコールを受け取ってよい。例として、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、ディレクトリサービストークン（例えば、ケルベロストークン）にユーザー、グループ、及びパスワードＡＰＩモジュール２４０によって受け取られるアクセストークンをマッピングしてよく、ディレクトリサービストークンは適切なディレクトリにアクセスするためにエージェント２１５Ａ〜Ｂに提供されてよい。

（８）で、もしあれば、結果は、管理ディレクトリサービス１４０からエージェント２１５Ａ〜Ｂによって受け取られ、ユーザー、グループ、及びパスワードＡＰＩモジュール２４０に転送されてよい。ユーザー、グループ、及びパスワードＡＰＩモジュール２４０は、次いで呼び出し側サービスに結果を送信してよい。

サービスヘルス監視モジュール２６５は、ディレクトリサービスのヘルスを監視するコンピューティングシステムであってよい。例えば、サービスヘルス監視モジュール２６５は、ディレクトリサービスモジュール１４０のヘルスを監視してよい。

認証寿命管理リーパーモジュール２７０は、ディレクトリデータベース２６０に対して保守を実行してよい。例えば、認証寿命管理リーパーモジュール２７０は、期限切れとなったアクセストークン及び／またはリフレッシュトークン（及びその関連付けられた認証情報及びディレクトリ識別）を取り除いてよいまたは削除してよい。

異なる領域の異なるディレクトリと関連付けられた共通エンドポイントでユーザーを認証するための例のプロセス
図３は、サードパーティアプリケーションサーバまたはコンピュータリソースサービスプロバイダシステムによって提供されるアプリケーションもしくはサービスによって使用されてよい異なる領域で複数のディレクトリと関連付けられた共通エンドポイントでユーザーを認証するためのプロセス３００を示す。例として、図１Ａ〜図１Ｂのサードパーティアプリケーションサーバ１０８またはコンピュータリソースサービスプロバイダシステム１０４は、認証プロセス３００を実行するように構成できる。認証プロセス３００は、ブロック３０２で開始する。

ブロック３０４で、組織名と関連付けられたページを介してアプリケーションにアクセスする要求が受け取られる。例えば、組織名はグローバルエンドポイントを識別してよい。複数のディレクトリは組織名と関連付けられてよい。例えば、組織名は複数のエンティティと関連付けられてよい。各エンティティは別々のディレクトリを記憶し、維持してよい。実施形態では、複数の中のディレクトリの内の１つまたは複数は別々の領域に位置する。各個別領域でのコンピューティング装置は、他の領域でコンピューティング装置と通信しないことがある。

ブロック３０６で、ユーザー認証情報が受け取られる。ユーザー認証情報は、複数のディレクトリの第１のディレクトリと関連付けられてよい。例えば、ユーザー認証情報と関連付けられたユーザーは第１のディレクトリを記憶し、維持するエンティティの従業員であってよい。

ブロック３０８で、第１のディレクトリが位置する領域が決定される。実施形態では、ルートサービス１３０等のルートサービスは、組織名と関連付けられたページへのＤＮＳエントリのマッピングを含む。また、ルートサービスはＣＤＮエントリに対するＤＮＳエントリのマッピングを含んでもよい。ＣＤＮは多様な領域サービスへのマッピングを含んでよい。例えば、第１のディレクトリは、ＣＤＮまたは領域サービスによってＣＤＮを介してルートサービス及び／またはコンピューティングリソースサービスプロバイダシステムもしくはサードパーティアプリケーションサーバによって提供されるエイリアス識別子と識別されてよい。コンピューティングリソースサービスプロバイダシステムまたはサードパーティアプリケーションサーバからエイリアス識別子を受け取ると同時に、ルートサービスは適切なＣＤＮにユーザーデバイスをリダイレクトできてよい。ＣＤＮは、第１のディレクトリを管理する領域サービスを識別し、それによって第１のディレクトリの領域を識別してよい（例えば、領域サービスは第１のディレクトリと同じ領域にある）。

ブロック３１０で、ユーザー認証情報は認証のために決定された領域に送信される。ユーザー認証情報が決定された領域に送信された後、認証プロセス３００はブロック３１２に示されるように完了してよい。

グローバルエンドポイントにアクセスするための例のユーザーインタフェース
図４Ａ〜図４Ｂは、ユーザーデバイス１０２等のユーザーデバイスで見られるネットワークページ４００の表現の例を示す。ネットワークページ４００は、コンピューティングリソースサービスプロバイダシステム１０４等の領域サービスによって生成され、ユーザーデバイス１０２によって実行されるブラウザアプリケーションのユーザーインタフェースの中に表示されてよい。図４Ａに示されるように、ネットワークページ４００は、ユーザーがアプリケーションにアクセスするために認証情報（例えば、ユーザー名及びパスワード）を入力できるようにする。例えば、ユーザーはフィールド４０２にユーザー名を、フィールド４０４にパスワードを入力できる。

ＵＲＬバー４０６は、ユーザーによって提供されるＵＲＬを示す。実施形態では、ＵＲＬはログインプロセスを通して変化しないままである。例えば、ユーザーが、第１のコンピューティングリソースサービスプロバイダシステム１０４またはサードパーティアプリケーションサーバ１０８によってホストされるニュースサービスにアクセスするために、ＵＲＬ＜Ｏｒｇ Ｎａｍｅ＞．ＸＹＺＡＰＰＳ．ＣＯＭ／ＮＥＷＳを提供した可能性がある。しかしながら、ユーザーはまだログインしていないため、第１のコンピューティングリソースサービスプロバイダシステム１０４またはサードパーティアプリケーションサーバ１０８はネットワークページ４００によって表現されるログインページにユーザーをリダイレクトする。ネットワークページ４００によって表現されるログインページは、ユーザーの組織に対応するディレクトリと関連付けられるコンピューティングリソースサービスプロバイダシステム１０４等、第１のコンピューティングリソースサービスプロバイダシステム１０４またはサードパーティアプリケーションサーバ１０８とは異なるコンピューティングリソースサービスプロバイダシステム１０４によって生成されてよい。コンピューティングリソースサービスプロバイダシステム１０４及びサードパーティアプリケーションサーバ１０８は、異なる領域に位置してよい。したがって、ブラウザアプリケーションは、ログインプロセスを完了するためにある領域のホストによって生成されるページから別の領域の別のホストによって生成される別のページにリダイレクトされた可能性がある。ブラウザアプリケーションは、ルートサービス１３０に記憶されるマッピングに基づいて、及びＣＤＮ１５０Ａまたは１５０Ｂに記憶されるマッピングに基づいてこのようにリダイレクトされた可能性がある。ただし、ＵＲＬバー４０６は、依然としてＵＲＬ＜Ｏｒｇ Ｎａｍｅ＞．ＸＹＺＡＰＰＳ．ＣＯＭ／ＮＥＷＳを表示してよい。

図４Ｂに示されるように、ユーザーは無事にログインし、第１のコンピューティングリソースサービスプロバイダシステム１０４またはサードパーティアプリケーションサービス１０８によって生成されるニュースサービスがネットワークページ４５０に表示される。しかしながら、ユーザーがネットワークページ４００からネットワークページ４５０にリダイレクトされ、したがってある領域に位置するホストから別の領域に位置する別のホストにリダイレクトされても、ＵＲＬバー４０６は再び同じＵＲＬを表示する。

専門用語
本明細書に説明される方法及びタスクのすべてはコンピュータシステムによって実行され、完全に自動化され得る。コンピュータシステムは、いくつかの場合、説明されている機能を実行するためにネットワーク上で通信し、相互運用する複数の別個のコンピュータまたはコンピューティング装置（例えば、物理サーバ、ワークステーション、ストレージアレイ、クラウドコンピューティングリソース）を含んでよい。それぞれの係るコンピューティング装置は、通常、メモリまたは他の非一過性のコンピュータ可読記憶媒体または装置（例えば、ソリッドステートストレージデバイス、ディスクドライブ等）に記憶されるプログラム命令またはモジュールを実行する１つのプロセッサ（または複数のプロセッサ）を含む。本明細書に開示される多様な機能は係るプログラム命令で実施されてよい、及び／またはコンピュータシステムのアプリケーション特有の回路網（例えば、ＡＳＩＣまたはＦＰＧＡ）で実装されてよい。コンピュータシステムが複数のコンピューティング装置を含む場合、これらの装置は同一場所に配置されてよいが、同一場所に配置される必要はない。開示されている方法及びタスクの結果は、ソリッドステートメモリチップ及び／または磁気ディスク等の物理ストレージデバイスを異なる状態に変換することによって持続的に記憶されてよい。いくつかの実施形態では、コンピュータシステムは、処理リソースが複数の別個の企業エンティティまたは他のユーザーによって共有されるクラウドベースのコンピューティングシステムであってよい。

実施形態によると、本明細書に説明されるプロセスまたはアルゴリズムのいずれかの特定の行為、イベント、または機能は、異なるシーケンスで実行でき、全体で追加する、マージする、または除外することができる（例えば、すべての説明されている操作またはイベントがアルゴリズムの実践に必要なわけではない）。さらに、特定の実施形態では、操作またはイベントは、順次によりむしろ、例えばマルチスレッド処理、割込み処理、または複数のプロセッサもしくはプロセッサコアを通して、または他の並列アーキテクチャ上で同時に実行できる。

本明細書に開示される実施形態と関連して説明される多様な例示的な論理ブロック、モジュール、ルーチン、及びアルゴリズムステップは、電子ハードウェア（例えば、ＡＳＩＣまたはＦＰＧＡデバイス）、汎用コンピュータハードウェアで実行するコンピュータソフトウェア、または両方の組合せとして実装できる。ハードウェア及びソフトウェアのこの互換性を明確に示すために、多様な例示的な構成要素、ブロック、モジュール、及びステップは、概してその機能性に関して上述されている。係る機能性が汎用ハードウェア上で実行するソフトウェアに対して特殊なハードウェアとして実装されるかどうかは、特定のアプリケーション及び全体的なシステムに課される設計制約に依存する。説明されている機能性は特定のアプリケーションごとに変化する方法で実装できるが、係る実装の決定は本開示の範囲からの逸脱を引き起こすとして解釈されるべきではない。

さらに、本明細書に開示される実施形態と関連して説明される多様な例示的な論理ブロック及びモジュールは、汎用プロセッサデバイス、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラム可能論理デバイス、離散ゲート論理もしくはトランジスタ論理、離散ハードウェア構成要素、または本明細書に説明される機能を実行するように設計されたその組合せ等のマシンによって実装または実行できる。汎用プロセッサデバイスはマイクロプロセッサであることがあるが、代替策では、プロセッサデバイスはコントローラ、マイクロコントローラ、または状態機械、これらの組合せ等であることがある。プロセッサデバイスは、コンピュータ実行可能な命令を処理するように構成された電気回路網を含むことがある。別の実施形態では、プロセッサデバイスは、コンピュータ実行可能命令を処理せずに論理演算を実行するＦＰＧＡまたは他のプログラム可能デバイスを含む。また、プロセッサデバイスは、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１つもしくは複数のマイクロプロセッサ、または任意の他の係る構成等、コンピューティング装置の組合せとしても実装できる。主にデジタル技術に関して本明細書に説明されるが、プロセッサデバイスは主にアナログ構成要素も含んでよい。例えば、本明細書に説明されるレンダリング技法のいくつかまたはすべてはアナログ回路網または混合アナログ及びデジタル回路網で実装されてよい。コンピューティング環境は、２〜３例を挙げると、マイクロプロセッサ、メインフレームコンピュータ、デジタルシグナルプロセッサ、携帯コンピューティング装置、デバイスコントローラ、または器具の中の計算エンジンに基づいたコンピュータシステムを含むが、これに限定されるものではない任意のタイプのコンピュータシステムを含むことがある。

本明細書に開示される実施形態と関連して説明される方法、プロセス、ルーチン、またはアルゴリズムの要素は、ハードウェアで、プロセッサデバイスによって実行されるソフトウェアモジュールで、または２つの組合せで直接的に実施できる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または任意の他の形式の非一過性コンピュータ可読記憶媒体に常駐することがある。例示的な記憶媒体は、プロセッサデバイスが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるようにプロセッサデバイスに結合できる。代替策では、記憶媒体はプロセッサデバイスに一体化されることがある。プロセッサデバイス及び記憶媒体はＡＳＩＣに常駐することがある。ＡＳＩＣはユーザー端末に常駐することがある。代替策では、プロセッサデバイス及び記憶媒体は、ユーザー端末に離散構成要素として常駐することがある。

とりわけ、「ｃａｎ（できる）」、「ｃｏｕｌｄ（ことがあるだろう）」、「ｍｉｇｈｔ（可能性がある）」、「ｍａｙ（してよい）」、「ｅ．ｇ．（例えば）」等の本明細書で使用される条件言語は、特に明記しない限り、または使用される文脈の中でそれ以外に理解されない限り、概して、特定の実施形態が特定の機能、要素、及び／またはステップを含むが、一方他の実施形態は含まないことを伝えることを目的としている。したがって、係る条件言語は、機能、要素、及び／もしくはステップは１つまたは複数の実施形態に決して必要とされない、または１つもしくは複数の実施形態が、他の入力またはプロンプティングを使用して、または使用せずに、これらの機能、要素、及び／もしくはステップが任意の特定の実施形態に含まれるのか、または任意の特定の実施形態で実行されるのかを決定するための論理を必ず含むことを暗示することを概して目的としてない。用語「ｃｏｍｐｒｉｓｉｎｇ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含む）」、「ｈａｖｉｎｇ（有する）」等は同義であり、オープンエンド形式で包括的に使用され、追加の要素、機能、行為、操作等を除外しない。また、用語「ｏｒ（または）」は、例えば要素のリストを接続するために使用されるときに、用語「ｏｒ（または）」はリスト中の要素の１つ、いくつか、またはすべてを意味するようにその包括的な意味で（及びその排他的な意味ではなく）使用される。

句「Ｘ、Ｙ、Ｚの内の少なくとも１つ」等の離接的な言語は、特に明記しない限り、概して、項目、用語等がＸ、Ｙ、もしくはＺ、またはその任意の組合せ（例えば、Ｘ、Ｙ、及び／またはＺ）のどちらかであってよいことを提示するために使用されるとして文脈でそれ以外の場合理解される。したがって、係る離接的な言語は概して、特定の実施形態がＸの内の少なくとも１つ、Ｙの内の少なくとも１つ、またはＺの内の少なくとも１つがそれぞれ存在することを必要とすることを暗示することを概して目的とせず、暗示するべきではない。

上記の発明を実施するための形態は、多様な実施形態に適用されるとして新規の機能を示し、説明し、指摘しているが、示されているデバイスまたはアルゴリズムの形式及び詳細における多様な省略、置換、及び変更が本開示の精神から逸脱することなく行うことができることが理解できる。認識できるように、いくつかの機能は他と別個に使用または実践できるので、本明細書に説明される特定の実施形態は、本明細書に説明される機能及び利点のすべてを提供しない形式で実施できる。本明細書に開示される特定の実施形態の範囲は、上述の説明によってよりもむしろ添付の特許請求の範囲によって示される。特許請求の範囲の同等性の意味及び範囲の中に入るすべての変更がその範囲内に包含されるべきである。

本開示の実施形態は、以下の条項を考慮して説明できる。
１．システムであって、
ネットワークのあるコンピューティング装置から別のコンピューティング装置へのルートを決定するように構成されたルートサービスシステムと、
１つまたは複数のコンピューティング装置を備えるアプリケーションサーバであって、複数のコンテンツ配信ネットワークと通信し、
ユーザーデバイスから、組織名と関連付けられたコンテンツページを介してアプリケーションにアクセスする要求を受け取るように構成されたネットワークインタフェースであって、複数のディレクトリが前記組織名と関連付けられ、前記複数のディレクトリの各ディレクトリは複数の領域の中の別個の領域に位置し、
前記ネットワークインタフェースが前記ユーザーデバイスからユーザー認証情報を受け取るようにさらに構成され、前記ユーザー認証情報が前記複数のディレクトリの内の第１のディレクトリと関連付けられる、ネットワークインタフェースと、
前記組織名と関連付けられる前記ルートサービスシステムに記憶されるデータに基づいて、前記第１のディレクトリが位置する前記複数の領域内の領域を決定するように構成されたディレクトリ識別子モジュールであって、
前記ネットワークインタフェースが認証のために前記決定された領域のサービスに前記ユーザー認証情報を送信するようにさらに構成され、
前記ネットワークインタフェースが前記決定された領域の前記サービスから前記認証の結果を受け取るようにさらに構成される、ディレクトリ識別子モジュールと、
を実装するようにプログラミングされたアプリケーションサーバと、
を備える、前記システム。

２．前記決定された領域の前記サービスが、
前記決定された領域の前記第１のディレクトリの場所を決定し、
前記決定された領域の前記第１のディレクトリの前記場所に前記ユーザー認証情報を送信する
ように構成される、条項１に記載のシステム。

３．前記ルートサービスシステムが、前記組織名とドメインネームシステム（ＤＮＳ）エントリとの間のマッピングを備える、条項１に記載のシステム。

４．前記ルートサービスシステムが、前記ＤＮＳエントリと、前記サービスと通信するコンテンツ配信ネットワークとの間のマッピングを備える、条項３に記載のシステム。

５．前記ネットワークインタフェースが、第２のユーザーデバイスから、前記組織名と関連付けられた前記コンテンツページを介して前記アプリケーションにアクセスする要求を受け取るようにさらに構成され、前記ネットワークインタフェースが前記第２のユーザーデバイスから第２のユーザー認証情報を受け取るようにさらに構成され、前記第２のユーザー認証情報が前記複数のディレクトリの第２のディレクトリと関連付けられる、条項１に記載のシステム。

６．前記ディレクトリ識別子モジュールが、前記組織名と関連付けられる前記ルートサービスシステムに記憶される前記データに基づいて、前記第２のディレクトリが位置する前記複数の領域の第２の領域を決定するようにさらに構成され、前記ネットワークインタフェースが認証のために前記決定された第２の領域の第２のサービスに前記第２のユーザー認証情報を送信するようにさらに構成される、条項５に記載のシステム。

７．前記ユーザー認証情報が、前記第１のディレクトリに管理されるユーザー名及びパスワードを備える、条項１に記載のシステム。

８．前記ネットワークインタフェースが、認証のために前記決定された領域の前記サービスに第２のユーザー認証情報を送信するようにさらに構成され、前記ネットワークインタフェースが前記第２のユーザー認証情報の前記認証の結果を受け取るようにさらに構成される、条項１に記載のシステム。

９．１つまたは複数のディレクトリの前記管理のために管理者を認証するコンピュータ実装方法であって、
１つまたは複数のコンピューティング装置を備え、特定の実行可能な命令で構成されるアプリケーションサーバによって実装されるように、
ユーザーデバイスから、組織名と関連付けられたコンテンツページを介してアプリケーションにアクセスする要求を受け取ることであって、複数のディレクトリが前記組織名と関連付けられ、前記複数の内の前記ディレクトリの少なくともいくつかが他とは異なる地理的地域に位置する、アプリケーションにアクセスする要求を受け取ることと、
前記ユーザーデバイスからユーザー認証情報を受け取ることであって、前記ユーザー認証情報が前記複数のディレクトリの第１のディレクトリと関連付けられる、ユーザー認証情報を受け取ることと、
ネットワークルートサービスによって提供される情報に基づいて、前記第１のディレクトリが位置する第１の地理的地域を決定することと、
前記第１のディレクトリとの認証のために前記第１の地理的地域のサービスに前記ユーザー認証情報を送信することと、
前記第１の地理的地域の前記サービスから前記認証の結果を受け取ることと、
を含む、前記コンピュータ実装方法。

１０．前記第１の地理的地域の前記サービスが、前記第１の地理的地域の前記第１のディレクトリの場所に前記ユーザー認証情報を送信することによって前記認証の前記結果を決定する、条項９に記載のコンピュータ実装方法。

１１．前記ネットワークルートサービスが、前記組織名とドメインネームシステム（ＤＮＳ）エントリとの間のマッピングを提供する、条項９に記載のコンピュータ実装方法。

１２．前記ネットワークルートサービスが、前記ＤＮＳエントリと、前記第１の地理的地域の前記サービスと通信するコンテンツ配信ネットワークとの間のマッピングをさらに提供する、条項１１に記載のコンピュータ実装方法。

１３．第１の地理的地域を決定することが、前記ＤＮＳエントリと関連付けられた前記コンテンツ配信ネットワークに問い合わせを行うことを含む、条項１２に記載のコンピュータ実装方法。

１４．第２のユーザーデバイスから、前記組織名と関連付けられた前記コンテンツページを介して前記アプリケーションにアクセスする要求を受け取ることと、
前記第２のユーザーデバイスから第２のユーザー認証情報を受け取ることであって、前記第２のユーザー認証情報が、前記複数のディレクトリの第２のディレクトリと関連付けられる、第２のユーザー認証情報を受け取ることと、
をさらに含む、条項９に記載のコンピュータ実装方法。

１５．前記ネットワークルートサービスによって提供される情報に基づいて、前記第２のディレクトリが位置する第２の地理的地域を決定することと、
前記第２のディレクトリとの認証のために、前記第２の地理的地域の第２のサービスに前記第２のユーザー認証情報を送信することと、
をさらに含む、条項１３に記載のコンピュータ実装方法。

１６．前記ユーザー認証情報が、前記第１のディレクトリによって管理されるユーザー名及びパスワードを備える、条項９に記載のコンピュータ実装方法。

１７．前記第１のディレクトリとの認証のために前記第１の地理的地域の前記サービスに第２のユーザー認証情報を送信することと、
前記第１の地理的地域の前記サービスから前記第２のユーザー認証情報の前記認証の結果を受け取ることと、
をさらに含む、条項９に記載のコンピュータ実装方法。

１８．非一過性のストレージデバイスを備える非一過性のコンピュータストレージシステムであって、前記コンピュータストレージシステムが、前記コンピュータストレージシステム上に、コンピュータシステムに少なくとも
ユーザーデバイスから、組織名と関連付けられたコンテンツページを介してアプリケーションにアクセスする要求を受け取り、複数のディレクトリが前記組織名と関連付けられ、前記複数の中の前記ディレクトリの内の少なくともいくつかが他とは異なる地理的地域に位置し、
前記ユーザーデバイスからユーザー認証情報を受け取り、前記ユーザー認証情報が前記複数のディレクトリの第１のディレクトリと関連付けられ、
ネットワークルートサービスによって提供される情報に基づいて、前記第１のディレクトリが位置する第１の地理的地域を決定し、
前記ユーザー認証情報が前記第１のディレクトリによって認証できるかどうかを判断するために前記第１のディレクトリに前記ユーザー認証情報を送信する
ように命令する実行可能プログラム命令を有する、前記一過性のコンピュータストレージシステム。

１９．前記実行可能プログラム命令がさらに前記コンピュータシステムに少なくとも、
前記第１の地理的地域のサービスを介して前記第１のディレクトリに前記ユーザー認証情報を送信し、
前記第１の地理的地域の前記サービスから前記認証の結果を受け取る
ようにさらに命令する、条項１８に記載の非一過性コンピュータストレージシステム。

２０．前記ネットワークルートサービスが、前記組織名とインターネットプロトコル（ＩＰ）アドレスとの間のマッピングを提供する、条項１８に記載の前記非一過性コンピュータストレージシステム。

２１．前記ネットワークルートサービスは、前記ＩＰアドレスとコンテンツ配信ネットワークのアドレスとの間のマッピングをさらに提供する、条項２０に記載の非一過性コンピュータストレージシステム。

２２．前記実行可能プログラム命令が、前記コンテンツ配信ネットワークの前記アドレスを識別するために前記ネットワークルートサービスに少なくとも問い合わせを行うように前記コンピュータシステムにさらに命令する、条項２１に記載の非一過性コンピュータストレージシステム。

２３．前記実行可能プログラム命令が、前記コンピュータシステムに少なくとも
第２のユーザーデバイスから、前記組織名と関連付けられた前記コンテンツページを介して前記アプリケーションにアクセスする要求を受け取り、
前記第２のユーザーデバイスから第２のユーザー認証情報を受け取り、前記第２のユーザー認証情報が前記複数のディレクトリの第２のディレクトリと関連付けられ、
前記ネットワークルートサービスによって提供される情報に基づいて、前記第２のディレクトリが位置する第２の地理的地域を決定し、
前記第２のユーザー認証情報が前記第２のディレクトリによって認証できるかどうかを判断するために、前記第２の地理的地域の第２のサービスに前記第２のユーザー認証情報を送信する
ようにさらに命令する、条項１８に記載の非一過性コンピュータストレージシステム。

２４．前記ユーザー認証情報が、前記第１のディレクトリによって管理されるユーザー名及びパスワードを備える、条項１８に記載の非一過性コンピュータストレージシステム。

前記実行可能プログラム命令が、前記コンピュータシステムに、前記第２のユーザー認証情報が前記第１のディレクトリによって認証できるかどうかを判断するために前記第１のディレクトリに第２のユーザー認証情報を少なくとも送信するようにさらに命令する、条項１８に記載の非一過性コンピュータストレージシステム。

Claims (15)

1. システムであって、
   ネットワークのあるコンピューティング装置から別のコンピューティング装置へのルートを決定するように構成されたルートサービスシステムと、
   １つまたは複数のコンピューティング装置を備えるアプリケーションサーバであって、複数のコンテンツ配信ネットワークと通信し、
   ユーザーデバイスから、組織名と関連付けられたコンテンツページを介してアプリケーションにアクセスする要求を受け取るように構成されたネットワークインタフェースであって、複数のディレクトリが前記組織名と関連付けられ、前記複数のディレクトリの各ディレクトリは複数の領域の中の別個の領域に位置し、
   前記ネットワークインタフェースが前記ユーザーデバイスからユーザー認証情報を受け取るようにさらに構成され、前記ユーザー認証情報が前記複数のディレクトリの内の第１のディレクトリと関連付けられる、ネットワークインタフェースと、
   前記組織名と関連付けられる前記ルートサービスシステムに記憶されるデータに基づいて、前記第１のディレクトリが位置する前記複数の領域内の領域を決定するように構成されたディレクトリ識別子モジュールであって、
   前記ネットワークインタフェースが認証のために前記決定された領域のサービスに前記ユーザー認証情報を送信するようにさらに構成され、
   前記ネットワークインタフェースが前記決定された領域の前記サービスから前記認証の結果を受け取るようにさらに構成される、ディレクトリ識別子モジュールと、
   を実装するようにプログラミングされたアプリケーションサーバと、
   を備える、前記システム。
2. 前記決定された領域の前記サービスが、
   前記決定された領域の前記第１のディレクトリの場所を決定し、
   前記決定された領域の前記第１のディレクトリの前記場所に前記ユーザー認証情報を送信する
   ように構成される、請求項１に記載のシステム。
3. 前記ルートサービスシステムが、前記組織名とドメインネームシステム（ＤＮＳ）エントリとの間のマッピングを備える、請求項１に記載のシステム。
4. 前記ルートサービスシステムが、前記ＤＮＳエントリと、前記サービスと通信するコンテンツ配信ネットワークとの間のマッピングを備える、請求項３に記載のシステム。
5. 前記ネットワークインタフェースが、第２のユーザーデバイスから、前記組織名と関連付けられた前記コンテンツページを介して前記アプリケーションにアクセスする要求を受け取るようにさらに構成され、前記ネットワークインタフェースが前記第２のユーザーデバイスから第２のユーザー認証情報を受け取るようにさらに構成され、前記第２のユーザー認証情報が前記複数のディレクトリの第２のディレクトリと関連付けられる、請求項１に記載のシステム。
6. 前記ディレクトリ識別子モジュールが、前記組織名と関連付けられる前記ルートサービスシステムに記憶される前記データに基づいて、前記第２のディレクトリが位置する前記複数の領域の第２の領域を決定するようにさらに構成され、前記ネットワークインタフェースが認証のために前記決定された第２の領域の第２のサービスに前記第２のユーザー認証情報を送信するようにさらに構成される、請求項５に記載のシステム。
7. 前記ユーザー認証情報が、前記第１のディレクトリに管理されるユーザー名及びパスワードを備える、請求項１に記載のシステム。
8. 前記ネットワークインタフェースが、認証のために前記決定された領域の前記サービスに第２のユーザー認証情報を送信するようにさらに構成され、前記ネットワークインタフェースが前記第２のユーザー認証情報の前記認証の結果を受け取るようにさらに構成される、請求項１に記載のシステム。
9. １つまたは複数のディレクトリの前記管理のために管理者を認証するコンピュータ実装方法であって、
   １つまたは複数のコンピューティング装置を備え、特定の実行可能な命令で構成されるアプリケーションサーバによって実装されるように、
   ユーザーデバイスから、組織名と関連付けられたコンテンツページを介してアプリケーションにアクセスする要求を受け取ることであって、複数のディレクトリが前記組織名と関連付けられ、前記複数の内の前記ディレクトリの少なくともいくつかが他とは異なる地理的地域に位置する、アプリケーションにアクセスする要求を受け取ることと、
   前記ユーザーデバイスからユーザー認証情報を受け取ることであって、前記ユーザー認証情報が前記複数のディレクトリの第１のディレクトリと関連付けられる、ユーザー認証情報を受け取ることと、
   ネットワークルートサービスによって提供される情報に基づいて、前記第１のディレクトリが位置する第１の地理的地域を決定することと、
   前記第１のディレクトリとの認証のために前記第１の地理的地域のサービスに前記ユーザー認証情報を送信することと、
   前記第１の地理的地域の前記サービスから前記認証の結果を受け取ることと、
   を含む、前記コンピュータ実装方法。
10. 前記第１の地理的地域の前記サービスが、前記第１の地理的地域の前記第１のディレクトリの場所に前記ユーザー認証情報を送信することによって前記認証の前記結果を決定する、請求項９に記載のコンピュータ実装方法。
11. 前記ネットワークルートサービスが、前記組織名とドメインネームシステム（ＤＮＳ）エントリとの間のマッピングを提供する、請求項９に記載のコンピュータ実装方法。
12. 前記ネットワークルートサービスが、前記ＤＮＳエントリと、前記第１の地理的地域の前記サービスと通信するコンテンツ配信ネットワークとの間のマッピングをさらに提供する、請求項１１に記載のコンピュータ実装方法。
13. 第２のユーザーデバイスから、前記組織名と関連付けられた前記コンテンツページを介して前記アプリケーションにアクセスする要求を受け取ることと、
    前記第２のユーザーデバイスから第２のユーザー認証情報を受け取ることであって、前記第２のユーザー認証情報が、前記複数のディレクトリの第２のディレクトリと関連付けられる、第２のユーザー認証情報を受け取ることと、
    をさらに含む、請求項９に記載のコンピュータ実装方法。
14. 前記ネットワークルートサービスによって提供される情報に基づいて、前記第２のディレクトリが位置する第２の地理的地域を決定することと、
    前記第２のディレクトリとの認証のために、前記第２の地理的地域の第２のサービスに前記第２のユーザー認証情報を送信することと、
    をさらに含む、請求項１３に記載のコンピュータ実装方法。
15. 前記第１のディレクトリとの認証のために前記第１の地理的地域の前記サービスに第２のユーザー認証情報を送信することと、
    前記第１の地理的地域の前記サービスから前記第２のユーザー認証情報の前記認証の結果を受け取ることと、
    をさらに含む、請求項９に記載のコンピュータ実装方法。