特開 2023-166473 マルチテナントアイデンティクラウドサービスのデータレプリケーション競合の検出および解決

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023166473

(43)【公開日】2023-11-21

(54)【発明の名称】マルチテナントアイデンティクラウドサービスのデータレプリケーション競合の検出および解決

(51)【国際特許分類】

   G06F 16/27 20190101AFI20231114BHJP

   G06F 21/41 20130101ALI20231114BHJP

【ＦＩ】

G06F16/27

G06F21/41

【審査請求】有

【請求項の数】14

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023138968

(22)【出願日】2023-08-29

(62)【分割の表示】P 2019572182の分割

【原出願日】2019-04-02

(31)【優先権主張番号】62/651,367

(32)【優先日】2018-04-02

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/108,315

(32)【優先日】2018-08-22

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】メダム，ベンカテスワラ・レディ

(72)【発明者】

【氏名】ホー，ファニー

(72)【発明者】

【氏名】シー，クアン－ユー

(72)【発明者】

【氏名】バルー，バラクマール

(72)【発明者】

【氏名】スリニバサン，スディール・クマール

(57)【要約】      （修正有）

【課題】マルチテナントクラウドベースのシステムにおけるアプリケーションの管理を提供する。
【解決手段】第１のデータセンターと第２の遠隔データセンターとを有するマルチテナントクラウドシステムであって、第１のデータセンターは、第１のクライアントを認証し、第１のクライアントに対応するリソースを格納し、第２のデータセンターと通信する。第２のデータセンターは、第１のクライアントを認証しリソースをリプリケートする。第１のデータセンターは、第１のクライアントの書込要求を受け、書込要求を書き込みと変更イベントメッセージを第１の順序で生成する。第１のデータセンターは、ＲＥＳＴ ＡＰＩコールを介して変更イベントメッセージを第２のデータセンターにプッシュする１４５１。第２のデータセンターは、変更イベントメッセージを受けたことに応じて変更イベントメッセージをそのローカルデータベースに第１の順序で書き込む。
【選択図】図１４

【特許請求の範囲】

【請求項1】

マルチテナントクラウドシステムを動作させる方法であって、前記方法は、
第１のデータセンターで、第１のクライアントを認証し前記第１のクライアントに対応するリソースを格納するステップを含み、前記第１のデータセンターは、前記第１のクライアントを認証し前記リソースをレプリケートするように構成された第２のデータセンターと通信し、
前記第１のデータセンターが、前記第１のクライアントの書込要求を受け、前記書込要求を書き込み、変更イベントメッセージを第１の順序で生成するステップと、
前記第１のデータセンターが、ＲＥＳＴ ＡＰＩコールを介して前記変更イベントメッセージを前記第２のデータセンターにプッシュするステップとを含み、
前記第２のデータセンターは、前記変更イベントメッセージを受けたことに応じて前記変更イベントメッセージをそのローカルデータベースに前記第１の順序で書き込むように構成されている、方法。

【請求項2】

前記変更イベントメッセージは、前記第１のデータセンターの１つ以上の第１のシャードキューに書き込まれる、請求項１に記載の方法。

【請求項3】

第１のテナントに対応付けられたすべての前記変更イベントメッセージが同じシャードキューに書き込まれる、請求項２に記載の方法。

【請求項4】

前記変更イベントメッセージは、前記第２のデータセンターの１つ以上の第２のシャードキューに書き込まれる、請求項２に記載の方法。

【請求項5】

前記第２のデータセンターは、前記第２のデータセンターにおける適用ハンドラとともに構成され、前記適用ハンドラは、レプリケートされたリソースが既に存在する場合、作成動作に応じて、前記変更イベントメッセージを無視することまたは前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１に記載の方法。

【請求項6】

前記適用ハンドラは、前記レプリケートされたリソースが存在しない場合、更新動作に応じて、前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項５に記載の方法。

【請求項7】

前記第１のデータセンターは、各々が対応するパーティションを有する複数のテナントを含み、前記方法は、前記第１のクライアントの対応するパーティションに対応するハッシュを計算するステップをさらに含む、請求項１に記載の方法。

【請求項8】

複数のプロセッサのうちの少なくとも１つのプロセッサによって実行されると前記プロセッサにマルチテナントクラウドシステムを動作させる命令を格納する非一時的なコンピュータ読取可能媒体であって、前記動作は、
第１のデータセンターで、第１のクライアントを認証し前記第１のクライアントに対応するリソースを格納することを含み、前記第１のデータセンターは、前記第１のクライアントを認証し前記リソースをレプリケートするように構成された第２のデータセンターと通信し、前記動作はさらに、
前記第１のデータセンターが、前記第１のクライアントの書込要求を受け、前記書込要求を書き込み、変更イベントメッセージを第１の順序で生成することと、
前記第１のデータセンターが、ＲＥＳＴ ＡＰＩコールを介して前記変更イベントメッセージを前記第２のデータセンターにプッシュすることとを含み、
前記第２のデータセンターは、前記変更イベントメッセージを受けたことに応じて前記
変更イベントメッセージをそのローカルデータベースに前記第１の順序で書き込むように構成されている、非一時的なコンピュータ読取可能媒体。

【請求項9】

前記変更イベントメッセージは、前記第１のデータセンターの１つ以上の第１のシャードキューに書き込まれる、請求項８に記載の非一時的なコンピュータ読取可能媒体。

【請求項10】

第１のテナントに対応付けられたすべての前記変更イベントメッセージが同じシャードキューに書き込まれる、請求項９に記載の非一時的なコンピュータ読取可能媒体。

【請求項11】

前記変更イベントメッセージは、前記第２のデータセンターの１つ以上の第２のシャードキューに書き込まれる、請求項９に記載の非一時的なコンピュータ読取可能媒体。

【請求項12】

前記第２のデータセンターは、前記第２のデータセンターにおける適用ハンドラとともに構成され、前記適用ハンドラは、レプリケートされたリソースが既に存在する場合、作成動作に応じて、前記変更イベントメッセージを無視することまたは前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項８に記載の非一時的なコンピュータ読取可能媒体。

【請求項13】

前記適用ハンドラは、前記レプリケートされたリソースが存在しない場合、更新動作に応じて、前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１２に記載の非一時的なコンピュータ読取可能媒体。

【請求項14】

前記第１のデータセンターは、各々が対応するパーティションを有する複数のテナントを含み、前記動作は、前記第１のクライアントの対応するパーティションに対応するハッシュを計算することをさらに含む、請求項８に記載の非一時的なコンピュータ読取可能媒体。

【請求項15】

マルチテナントクラウドシステムデータセンターであって、
第１のクライアントを認証し前記第１のクライアントに対応するリソースを格納するようにされた管理サービスを備え、前記データセンターは、前記第１のクライアントを認証し前記リソースをレプリケートするように構成された第２のデータセンターと通信し、
前記管理サービスに結合されたデータストアを備え、
前記管理サービスは、前記第１のクライアントの書込要求を受け、前記書込要求を書き込み、変更イベントメッセージを第１の順序で生成するようにされ、
ＲＥＳＴ ＡＰＩコールを介して前記変更イベントメッセージを前記第２のデータセンターにプッシュするようにされたレプリケーションサービスを備え、
前記第２のデータセンターは、前記変更イベントメッセージを受けたことに応じて前記変更イベントメッセージをそのローカルデータベースに前記第１の順序で書き込むように構成されている、マルチテナントクラウドシステムデータセンター。

【請求項16】

１つ以上の第１のシャードキューをさらに備え、前記変更イベントメッセージは前記第１のシャードキューに書き込まれる、請求項１５に記載のマルチテナントクラウドシステムデータセンター。

【請求項17】

第１のテナントに対応付けられたすべての前記変更イベントメッセージが同じシャードキューに書き込まれる、請求項１６に記載のマルチテナントクラウドシステムデータセンター。

【請求項18】

前記変更イベントメッセージは、前記第２のデータセンターの１つ以上の第２のシャー
ドキューに書き込まれる、請求項１６に記載のマルチテナントクラウドシステムデータセンター。

【請求項19】

前記第２のデータセンターは、前記第２のデータセンターにおける適用ハンドラとともに構成され、前記適用ハンドラは、レプリケートされたリソースが既に存在する場合、作成動作に応じて、前記変更イベントメッセージを無視することまたは前記データセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１５に記載のマルチテナントクラウドシステムデータセンター。

【請求項20】

前記適用ハンドラは、前記レプリケートされたリソースが存在しない場合、更新動作に応じて、前記データセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１９に記載のマルチテナントクラウドシステムデータセンター。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１８年４月２日出願の米国仮特許出願第６２／６５１，３６７号に基づく優先権を主張し、その開示を本明細書に引用により援用する。

【0002】

分野
一実施形態は、概してアイデンティティ管理に関し、特にクラウドシステムにおけるアイデンティ管理に関する。

【背景技術】

【0003】

背景情報
一般的に、多様なデバイス（たとえばデスクトップおよびモバイルデバイス）および多様なユーザ（たとえば被雇用者、パートナー、顧客など）からアクセスされる、クラウドベースのアプリケーション（たとえば企業パブリッククラウドアプリケーション、第三者クラウドアプリケーションなど）の使用が、急激に増加している。クラウドベースのアプリケーションは、その多様性およびアクセシビリティが高いので、アイデンティティの管理およびアクセスのセキュリティが中心的な関心事になっている。クラウド環境における典型的なセキュリティの問題は、不正アクセス、アカウントのハイジャック、悪意のあるインサイダーなどである。したがって、クラウドベースのアプリケーションであっても、どこに存在するアプリケーションであっても、アプリケーションにアクセスするデバイスの種類またはユーザの種類にかかわらず、安全なアクセスが必要とされている。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
実施形態は、第１のデータセンターと第２の遠隔データセンターとを有するマルチテナントクラウドシステムを含む。第１のデータセンターは、第１のクライアントを認証し、第１のクライアントに対応するリソースを格納し、第２のデータセンターと通信する。第２のデータセンターは、第１のクライアントを認証しリソースをリプリケートする。第１のデータセンターは、第１のクライアントの書込要求を受け、書込要求を書き込み、変更イベントメッセージを第１の順序で生成する。第１のデータセンターは、ＲＥＳＴ ＡＰＩコールを介して変更イベントメッセージを第２のデータセンターにプッシュする。第２のデータセンターは、変更イベントメッセージを受けたことに応じて変更イベントメッセージをそのローカルデータベースに第１の順序で書き込むように構成されている。

【図面の簡単な説明】

【0005】

【図1】クラウドベースのアイデンティティ管理を提供する実施形態の一例のブロック図である。

【図2】クラウドベースのアイデンティティ管理を提供する実施形態の一例のブロック図である。

【図3】クラウドベースのアイデンティティ管理を提供する実施形態の一例のブロック図である。

【図4】クラウドベースのアイデンティティ管理を提供する実施形態の一例のブロック図である。

【図5】クラウドベースのアイデンティティ管理を提供する実施形態の一例のブロック図である。

【図6】ある実施形態のシステムビューを提供するブロック図である。

【図6A】ある実施形態の機能ビューを提供するブロック図である。

【図7】クラウドゲートを実現するある実施形態のブロック図である。

【図8】一実施形態における複数のテナンシーを実現するシステムの一例を示す図である。

【図9】ある実施形態のネットワークビューのブロック図である。

【図10】一実施形態におけるシングルサインオン（「ＳＳＯ」）機能のシステムアーキテクチャビューのブロック図である。

【図11】一実施形態におけるＳＳＯ機能のメッセージシーケンスフローの図である。

【図12】一実施形態における分散型データグリッドの一例を示す図である。

【図13】本発明の実施形態に係る、各々が「地域」を形成するデプロイされた複数のデータセンター（「ＤＣ」で示される）を示す図である。

【図14】本発明の実施形態に係る、マスターＩＤＣＳデプロイメントとレプリカＩＤＣＳデプロイメントとの間におけるレプリケーション変更イベント／ログの処理フローを示す図である。

【図15】本発明の実施形態に係る、マスターＩＤＣＳデプロイメントとレプリカＩＤＣＳデプロイメントとの間における競合解決の処理フローを示す図である。

【図16】本発明の実施形態に係る、マスターＩＤＣＳデプロイメントおよびレプリカＩＤＣＳデプロイメントの詳細をさらに示すブロック図である。

【図17】本発明の実施形態に係る、レプリケーションに応じた競合解決のフロー図である。

【発明を実施するための形態】

【0006】

詳細な説明
実施形態は、マルチテナントクラウドシステム内における異なる地理的領域の複数のアイデンティティ管理システムデプロイメント間のデータのレプリケーションを提供する。このため、ある地理的領域のあるデプロイメントのテナントは、第２の地理的領域の同じリソースにアクセスすることができる。実施形態は、このデータを、変更イベントの逐次処理を用いてレプリケートする。実施形態はさらに、データレプリケーション中に生じ得るいかなるデータ競合に対しても解決を提供する。

【0007】

実施形態は、マルチテナントクラウドベースのシステムにおけるアプリケーションの管理を提供する。各アプリケーションは、当該アプリケーションの挙動を定めるファセットを含む。１つの管理インターフェイスにより、ユーザはすべてのアプリケーションを構成することができ、１つの統合データモデルにより、すべてのランタイムサービスは同じデータコピーに対して動作することができる。

【0008】

実施形態が提供するアイデンティティクラウドサービスは、マイクロサービスベースのアーキテクチャを実現するとともに、マルチテナントアイデンティティおよびデータセキュリティの管理ならびにクラウドベースのアプリケーションへの安全なアクセスを提供する。実施形態は、ハイブリッドクラウドのデプロイメント（すなわちパブリッククラウドとプライベートクラウドとを組み合わせたものを含むクラウドのデプロイメント）について安全なアクセスをサポートする。実施形態は、クラウド内およびオンプレミス双方におけるアプリケーションおよびデータを保護する。実施形態は、ウェブ、モバイル機器、およびアプリケーションプログラミングインターフェイス（application programming interface）（「ＡＰＩ」）を介したマルチチャネルアクセスをサポートする。実施形態は、
顧客、パートナー、および被雇用者など、さまざまなユーザのアクセスを管理する。実施形態は、クラウドを通じたアクセスおよびオンプレミスのアクセス双方を管理、制御、および監査する。実施形態は、新たなおよび既存のアプリケーションおよびアイデンティと
統合される。実施形態は横方向にスケーラブルである。

【0009】

一実施形態は、ステートレスな中間層環境において多数のマイクロサービスを実現することによりクラウドベースのマルチテナントアイデンティティおよびアクセス管理サービスを提供するシステムである。一実施形態において、要求された各アイデンティティ管理サービスは、リアルタイムタスクとニア・リアルタイムタスクとに分割される。リアルタイムタスクは中間層のマイクロサービスによって処理されるのに対し、ニア・リアルタイムタスクはメッセージキューにオフロードされる。実施形態は、ルーティング層および中間層によって消費されるアクセストークンを実現することにより、マイクロサービスにアクセスするためのセキュリティモデルを強化する。したがって、実施形態は、マルチテナントのマイクロサービスアーキテクチャに基づいてクラウドスケールのアイデンティティおよびアクセス管理（Identity and Access Management）（「ＩＡＭ」）プラットフォームを提供する。

【0010】

一実施形態は、組織が、その新たなビジネス構想のために高速で信頼性が高くかつ安全なサービスを迅速に開発できるようにするアイデンティティクラウドサービスを提供する。一実施形態において、アイデンティティクラウドサービスは多数のコアサービスを提供する。各コアサービスは、多くの企業が直面する固有の課題を解決する。一実施形態において、アイデンティティクラウドサービスは、たとえば、最初にユーザのオンボード／インポートを行うとき、ユーザメンバとともにグループをインポートするとき、ユーザを作成／更新／ディスエーブル／イネーブル／削除するとき、ユーザをグループに割り当てる／グループへのユーザ割当を解除するとき、グループを作成／更新／削除するとき、パスワードをリセットするとき、ポリシーを管理するとき、アクティベーションを送信するときなどの、アドミニストレータをサポートする。

【0011】

統一されたアクセスセキュリティ
一実施形態は、クラウド環境およびオンプレミス環境双方におけるアプリケーションおよびデータを保護する。本実施形態は、どのデバイスからの誰によるどのアプリケーションへのアクセスも安全にする。本実施形態は、これらの環境双方にわたる保護を提供する。なぜなら、これら２つの環境の間でセキュリティに矛盾があればリスクが高くなる可能性があるからである。たとえば、このような矛盾があった場合、販売員は、離反して競合他社に移った後であっても、その顧客関係管理（Customer Relationship Management）（「ＣＲＭ」）アカウントへのアクセス権を有し続ける場合がある。したがって、実施形態は、オンプレミス環境においてプロビジョニングされたセキュリティ制御をクラウド環境に拡張する。たとえば、ある人物が会社を辞めた場合、実施形態は、そのアカウントがオンプレミスおよびクラウド双方においてディスエーブルされることを保証する。

【0012】

一般的に、ユーザは、ウェブブラウザ、デスクトップ、携帯電話、タブレット、スマートウォッチ、その他のウェアラブル機器などの多種多様なチャネルを通してアプリケーションおよび／またはデータにアクセスし得る。したがって、一実施形態は、これらすべてのチャネルについて、これらを通るアクセスを安全なものにする。たとえば、ユーザは、その携帯電話を用いて、自身のデスクトップ上で開始したトランザクションを完了させることができる。

【0013】

一実施形態はさらに、顧客、パートナー、被雇用者など、さまざまなユーザのアクセスを管理する。一般的に、アプリケーションおよび／またはデータは、被雇用者だけでなく、顧客または第三者によってもアクセスされる場合がある。既知の多くのシステムは、被雇用者のオンボード時に安全対策を講じるが、この安全対策は通常、顧客、第三者、パートナーなどにアクセス権を付与するときの安全対策と同じレベルではないので、結果として、適切に管理されていない者によってセキュリティが破られる可能性がある。しかしな
がら、実施形態は、被雇用者だけでなく各タイプのユーザのアクセスについて十分な安全対策が提供されることを保証する。

【0014】

アイデンティティクラウドサービス
実施形態は、マルチテナントでクラウドスケールのＩＡＭプラットフォームであるアイデンティティクラウドサービス（Identity Cloud Service）（「ＩＤＣＳ」）を提供する。ＩＤＣＳは、認証、認可、監査、および連携（federation）を提供する。ＩＤＣＳは、パブリッククラウドおよびオンプレミスシステム上で実行されているカスタムアプリケーションおよびサービスへのアクセスを管理する。これに代わるまたはこれに加えられる実施形態において、ＩＤＣＳは、パブリッククラウドサービスへのアクセスも管理し得る。たとえば、ＩＤＣＳを用いて、このような多様なサービス／アプリケーション／システムにまたがるシングルサインオン（Single Sign On）（「ＳＳＯ」）機能を提供することができる。

【0015】

実施形態は、クラウドスケールのソフトウェアサービスを設計、構築、および配信するためのマルチテナントマイクロサービスアーキテクチャに基づく。マルチテナンシーとは、あるサービスを物理的に実現したものがありこのサービスが当該サービスを購入した複数の顧客を安全にサポートするサービスであることを言う。サービスは、異なるクライアントが異なる目的のために再使用できるソフトウェア機能またはソフトウェア機能のセット（指定された情報を取り出すことまたは一組の動作を実行することなど）に、（たとえばサービスを要求しているクライアントのアイデンティティに基づく）その使用を管理するポリシーを合わせたものである。一実施形態において、サービスは、１つ以上の機能へのアクセスを可能にするメカニズムであり、このアクセスは、所定のインターフェイスを用いて提供され、サービスの記述によって明記された制約およびポリシーに従って実行される。

【0016】

一実施形態において、マイクロサービスは独立してデプロイ可能なサービスである。一実施形態において、マイクロサービスという用語は、言語に依存しないＡＰＩを用いて相互に通信する小さな独立したプロセスから複雑なアプリケーションが構成されている、ソフトウェアアーキテクチャ設計パターンを意図している。一実施形態において、マイクロサービスは、細かく分離された小さなサービスであり、各サービスは、小さなタスクの実行に集中し得る。一実施形態において、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを小さなサービス一式として開発する手法であり、各サービスは、自身のプロセスにおいて実行され、軽量のメカニズム（たとえばハイパーテキスト・トランスファー・プロトコル（Hypertext Transfer Protocol）（「ＨＴＴＰ」）リソースＡ
ＰＩ）と通信する。一実施形態において、マイクロサービスは、同一機能すべてをまたは同一機能のうちの多くを実行するモノリシックサービスと比較すると、交換がより簡単である。加えて、マイクロサービスは各々、その他のマイクロサービスに悪影響を与えることなく更新し得る。これに対し、モノリシックサービスの一部を更新すると、当該モノリシックサービスの他の部分に望ましくないまたは意図せぬ悪影響が及ぶ可能性がある。一実施形態において、マイクロサービスはその機能を中心として有益に編成し得る。一実施形態において、マイクロサービスのコレクションのうち各マイクロサービスのスタートアップ時間は、これらのマイクロサービスのうちのすべてのサービスをまとめて実行する単一のアプリケーションのスタートアップ時間よりも遥かに短い。いくつかの実施形態において、このようなマイクロサービス各々のスタートアップ時間は約１秒以下であるのに対し、このような単一のアプリケーションのスタートアップ時間は約１分、数分、またはそれよりも長い場合がある。

【0017】

一実施形態において、マイクロサービスアーキテクチャとは、フレキシブルで、独立してデプロイ可能なソフトウェアシステムを構築するための、サービス指向アーキテクチャ
（service oriented architecture（「ＳＯＡ」））の専門化（すなわちシステム内にお
けるタスクの分離）および実現の手法のことである。マイクロサービスアーキテクチャにおけるサービスは、目的を達成するためにネットワークを通して相互に通信するプロセスである。一実施形態において、これらのサービスは、技術に依存しないプロトコルを使用する。一実施形態において、サービスは、細分性が小さく軽量であるプロトコルを使用する。一実施形態において、サービスは独立してデプロイ可能である。システムの機能を異なる小さなサービスに分散させることにより、システムの結束性は向上し、システムのカップリングは減少する。それにより、システム変更が容易になり、任意の時点でシステムに機能および品質を追加することが容易になる。また、それによって、個々のサービスのアーキテクチャが、絶え間ないリファクタリングを通して出現することが可能になり、したがって、大規模な事前の設計の必要性は低下しソフトウェアを早期に連続してリリースすることが可能になる。

【0018】

一実施形態において、マイクロサービスアーキテクチャでは、アプリケーションがサービスのコレクションとして開発され、各サービスはそれぞれのプロセスを実行し軽量のプロトコルを用いて通信する（たとえばマイクロサービスごとの固有ＡＰＩ）。マイクロサービスアーキテクチャにおいて、１つのソフトウェアを個々のサービス／機能に分解することは、提供するサービスに応じて異なるレベルの粒度で行うことができる。サービスはランタイムコンポーネント／プロセスである。各マイクロサービスは、他のモジュール／マイクロサービスに対してトークすることができる内蔵モジュールである。各マイクロサービスは、他からコンタクトできる無名ユニバーサルポートを有する。一実施形態において、マイクロサービスの無名ユニバーサルポートは、従来マイクロサービスがエクスポーズする標準通信チャネルであり（たとえば従来のＨＴＴＰポートのような）、同一サービス内の他のモジュール／マイクロサービスがそれに対してトークできるようにする標準通信チャネルである。マイクロサービスまたはその他の内蔵機能モジュールを包括的に「サービス」と呼ぶことができる。

【0019】

実施形態は、マルチテナントアイデンティティ管理サービスを提供する。実施形態は、さまざまなアプリケーションとの容易な統合を保証するオープン標準に基づいており、標準ベースのサービスを通してＩＡＭ機能を提供する。

【0020】

実施形態は、アイデンティティがアクセスできる対象、このようなアクセスを付与できる者、このようなアクセスを管理できる者などを判断し施行することを伴うユーザアイデンティティのライフサイクルを管理する。実施形態は、クラウド内でアイデンティティ管理ワークロードを実行し、このクラウド内に存在するとは限らないアプリケーションのセキュリティ機能をサポートする。これらの実施形態が提供するアイデンティティ管理サービスはクラウドから購入されてもよい。たとえば、企業は、このようなサービスをクラウドから購入してその被雇用者の当該企業のアプリケーションに対するアクセスを管理してもよい。

【0021】

実施形態は、システムセキュリティ、大規模なスケーラビリティ、エンドユーザのユーザビリティ、およびアプリケーションのインターオペラビリティを提供する。実施形態は、クラウドの成長と、顧客によるアイデンティティサービスの使用とを扱っている。マイクロサービスに基づく基礎は、横方向のスケーラビリティ条件を扱うのに対し、サービスの綿密な調整は機能条件を扱う。これらの目標双方を達成するには、ビジネスロジックを（可能な限り）分解することにより、最終的には一貫性のあるステートレスを達成する一方で、リアルタイム処理を受けない動作論理のほとんどが、配信と処理が保証されたスケーラビリティが高い非同期イベント管理システムに、オフロードされることにより、ニア・リアルタイムにシフトする。実施形態は、コスト効率を実現しシステム管理を容易にするために、ウェブ層からデータまで完全にマルチテナントである。

【0022】

実施形態は、さまざまなアプリケーションと統合し易くするために、業界の標準（たとえば、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、ＯＡｕｔｈ２、セキュリティ・アサーション・マークアップ言語（Security Assertion Markup Language）２（「ＳＡＭＬ２」)、クロス
ドメインアイデンティティ管理用システム（System for Cross-domain Identity Management）（「ＳＣＩＭ」）、レプレゼンテーショナル・ステート・トランスファー(Representational State Transfer）（「ＲＥＳＴ」)など）に従う。一実施形態は、クラウドスケールＡＰＩプラットフォームを提供し、エラスティックスケーラビリティのために横方向にスケーラブルなマイクロサービスを実現する。本実施形態は、クラウド原理を強化し、テナントごとにデータを分離したマルチテナントアーキテクチャを提供する。本実施形態はさらに、テナントセルフサービスを介してテナントごとのカスタマイズを提供する。本実施形態は、他のアイデンティサービスとのオンデマンドの統合の際にはＡＰＩを介して利用することができ、連続したフィーチャーリリースを提供する。

【0023】

一実施形態は、インターオペラビリティを提供し、クラウドおよびオンプレミスにおけるアイデンティティ管理（identity management）（「ＩＤＭ」）機能への投資を強化す
る。本実施形態は、オンプレミスの軽量ディレクトリアクセスプロトコル（Lightweight Directory Access Protocol）（「ＬＤＡＰ」）データからクラウドデータへの、および
その逆の、自動化されたアイデンティティ同期化を提供する。本実施形態は、クラウドと企業との間にＳＣＩＭアイデンティティバスを提供し、ハイブリッドクラウドのデプロイの各種オプションを可能にする（たとえば、アイデンティティ連携および／または同期化、ＳＳＯエージェント、ユーザプロビジョニングコネクタなど）。

【0024】

したがって、一実施形態は、ステートレスな中間層において多数のマイクロサービスを実現することによりクラウドベースのマルチテナントアイデンティティおよびアクセス管理サービスを提供するシステムである。一実施形態において、要求された各アイデンティティ管理サービスは、リアルタイムタスクとニア・リアルタイムタスクとに分割される。リアルタイムタスクは中間層のマイクロサービスによって処理されるのに対し、ニア・リアルタイムタスクはメッセージキューにオフロードされる。実施形態は、ルーティング層によって消費されて、マイクロサービスにアクセスするためのセキュリティモデルを実施するトークンを実現する。したがって、実施形態は、マルチテナントのマイクロサービスアーキテクチャに基づくクラウドスケールのＩＡＭプラットフォームを提供する。

【0025】

一般的に、周知のシステムは、たとえば、企業クラウドアプリケーション、パートナークラウドアプリケーション、第三者クラウドアプリケーション、および顧客アプリケーションなど、各種環境によって提供されるアプリケーションに対するサイロ化されたアクセスを提供する。このようなサイロ化されたアクセスは、複数のパスワード、異なるパスワードポリシー、異なるアカウントプロビジョニングおよびデプロビジョニング手法、異種の監査などを必要とする場合がある。しかしながら、一実施形態は、ＩＤＣＳを実現することにより、このようなアプリケーションに対し統一されたＩＡＭ機能を提供する。図１は、ユーザおよびアプリケーションをオンボードするための統一されたアイデンティティプラットフォーム１２６を提供する、ＩＤＣＳ１１８を用いる実施形態の一例のブロック図１００である。本実施形態は、企業クラウドアプリケーション１０２、パートナークラウドアプリケーション１０４、第三者クラウドアプリケーション１１０、および顧客アプリケーション１１２などのさまざまなアプリケーションにまたがるシームレスなユーザ体験を提供する。アプリケーション１０２、１０４、１１０、１１２は、異なるチャネルを通してアクセスされてもよく、たとえば、携帯電話ユーザ１０８が携帯電話１０６を介して、デスクトップコンピュータのユーザ１１６がブラウザ１１４を介して、アクセスしてもよい。ウェブブラウザ（一般的にブラウザと呼ばれる）は、ワールドワイドウェブ上で情報リソースを取得、提示、およびトラバースするためのソフトウェアアプリケーション
である。ウェブブラウザの例としては、Mozilla（登録商標） Firefox（登録商標）、Google Chrome（登録商標）、Microsoft（登録商標） Internet Explorer（登録商標）、お
よびApple（登録商標） Safari（登録商標）が挙げられる。

【0026】

ＩＤＣＳ１１８は、ユーザのアプリケーションの統一されたビュー１２４、（アイデンティティプラットフォーム１２６を介する）デバイスおよびアプリケーションにまたがる統一された安全なクレデンシャル、および（管理コンソール１２２を介する）統一された管理方法を、提供する。ＩＤＣＳサービスは、ＩＤＣＳ ＡＰＩ１４２にコールすることによって取得されてもよい。このようなサービスは、たとえば、ログイン／ＳＳＯサービス１２８（たとえばＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ）、連携サービス１３０（たとえばＳＡＭＬ）、トークンサービス１３２（たとえばＯＡｕｔｈ）、ディレクトリサービス１３４（たとえばＳＣＩＭ）、プロビジョニングサービス１３６（たとえばＳＣＩＭまたはAny Transport over Multiprotocol（「ＡＴｏＭ」））、イベントサービス１３８（たとえばＲＥＳＴ）、およびロールベースアクセス制御（role-based access control）（「Ｒ
ＢＡＣ」）サービス１４０（たとえばＳＣＩＭ）を含み得る。ＩＤＣＳ１１８はさらに、提供されるサービスに関するレポートおよびダッシュボード１２０を提供し得る。

【0027】

統合ツール
通常、大企業では、そのオンプレミスのアプリケーションへの安全なアクセスのために、ＩＡＭシステムを適所に設けるのが一般的である。ビジネス手法は通常オラクル社の「Oracle IAM Suite」などのインハウスＩＡＭシステムを中心として成熟し標準化される。小～中規模組織でも、通常は、そのビジネスプロセスを、Microsoft Active Directory（「ＡＤ」）などの単純なディレクトリソリューションを通してユーザアクセスを管理することを中心として設計されている。オンプレミス統合を可能にするために、実施形態は、顧客がそのアプリケーションをＩＤＣＳと統合できるようにするツールを提供する。

【0028】

図２は、オンプレミス２０６のＡＤ２０４との統合を提供する、クラウド環境２０８内のＩＤＣＳ２０２を用いる実施形態の一例のブロック図２００である。本実施形態は、たとえば、クラウドサービス２１０、クラウドアプリケーション２１２、パートナーアプリケーション２１４、および顧客アプリケーション２１６などのクラウド２０８内のさまざまなアプリケーション／サービスならびにオンプレミスアプリケーション２１８などのオンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがる、シームレスなユーザ体験を提供する。クラウドアプリケーション２１２は、たとえば、ヒューマン・キャピタル・マネージメント（Human Capital Management）（「ＨＣＭ」）、ＣＲＭ、タレント取得（たとえばオラクル社のOracle Taleoクラウドサービス）、構成、価格設定、および見積もり（Configure Price and Quote「ＣＰＱ」）
などを含み得る。クラウドサービス２１０は、たとえば、サービスとしてのプラットフォーム（Platform as a Service）（「ＰａａＳ」）、Ｊａｖａ（登録商標）、データベー
ス、ビジネスインテリジェンス（business intelligence）（「ＢＩ」）、文書などを含
み得る。

【0029】

アプリケーション２１０、２１２、２１４、２１６、２１８は、異なるチャネルを通してアクセスされてもよく、たとえば、携帯電話ユーザ２２０が携帯電話２２２を介して、デスクトップコンピュータのユーザ２２４がブラウザ２２６を介して、アクセスしてもよい。本実施形態は、クラウド２０８と企業２０６との間のＳＣＩＭアイデンティティバス２３４を介して、オンプレミスのＡＤデータからクラウドデータに、アイデンティティの同期化を自動的に行う。本実施形態はさらに、クラウド２０８からオンプレミスＡＤ２０４への、（たとえばパスワード２３２を用いて）認証を連携させるためのＳＡＭＬバス２２８を提供する。

【0030】

一般的に、アイデンティティバスは、アイデンティティ関連サービスのためのサービスバスである。サービスバスは、メッセージをあるシステムから別のシステムに伝えるためのプラットフォームを提供する。これは、たとえばサービス指向アーキテクチャ（service oriented architecture）（「ＳＯＡ」）において、信頼されているシステム間で情報
を交換するための制御されたメカニズムである。アイデンティティバスは、ウェブサービス、ウェブサーバプロキシなどの標準的なＨＴＴＰベースのメカニズムに従って構築された論理バスである。アイデンティティバスにおける通信は、各プロトコル（たとえばＳＣＩＭ、ＳＡＭＬ、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔなど）に従って実行されてもよい。たとえば、ＳＡＭＬバスは、ＳＡＭＬサービスに関するメッセージを伝えるための、２つのシステム間のＨＴＴＰベースの接続である。同様に、ＳＣＩＭバスを用い、ＳＣＩＭプロトコルに従って、ＳＣＩＭメッセージを伝える。

【0031】

図２の実施形態は、顧客のＡＤ２０４とともにオンプレミス２０６でダウンロードおよびインストールすることができる小バイナリ（たとえば大きさが１ＭＢ）のアイデンティティ（「ＩＤ」）ブリッジ２３０を実現する。ＩＤブリッジ２３０は、顧客によって選択された組織ユニット（organizational unit）（「ＯＵ」）のユーザおよびグループ（た
とえばユーザのグループ）をリッスンし、これらのユーザをクラウド２０８に対して同期させる。一実施形態において、ユーザのパスワード２３２はクラウド２０８に対して同期されていない。顧客は、ＩＤＣＳユーザのグループを、ＩＤＣＳ２０８において管理されているクラウドアプリケーションにマッピングすることにより、ユーザのアプリケーションアクセスを管理することができる。ユーザのグループメンバーシップがオンプレミス２０６で変更されるたびに、対応するクラウドアプリケーションアクセスは自動的に変更される。

【0032】

たとえば、技術部門から販売部門に異動した被雇用者は、販売クラウドへのアクセスをほぼ瞬間的に取得することができ、開発者クラウドへのアクセスは失う。この変化がオンプレミスＡＤ２０４に反映されると、クラウドアプリケーションのアクセスの変更がニア・リアルタイムで実現される。同様に、ＩＤＣＳ２０８で管理されているクラウドアプリケーションへの、この企業から去るユーザのアクセスは、取消される。完全自動化のために、顧客は、たとえばＡＤ連携サービス（「ＡＤ／ＦＳ」またはＳＡＭＬ連携を実現するその他の何らかのメカニズム）を通して、オンプレミスＡＤ２０４とＩＤＣＳ２０８との間のＳＳＯをセットアップして、エンドユーザが、単一の企業パスワード３３２を用いて、クラウドアプリケーション２１０、２１２、２１４、２１６およびオンプレミスアプリケーション２１８にアクセスできるようにしてもよい。

【0033】

図３は、図２と同一のコンポーネント２０２、２０６、２０８、２１０、２１２、２１４、２１６、２１８、２２０、２２２、２２４、２２６、２２８、２３４を含む実施形態の一例のブロック図３００である。しかしながら、図３の実施形態において、ＩＤＣＳ２０２は、オラクルＩＤＭのようなオンプレミスＩＤＭ３０４との統合を提供する。オラクルＩＤＭ３０４は、ＩＡＭ機能を提供するための、オラクル社のソフトウェアスイートである。本実施形態は、オンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがるシームレスなユーザ体験を提供する。本実施形態は、クラウド２０２と企業２０６との間のＳＣＩＭアイデンティティバス２３４を介したオンプレミスＩＤＭ３０４からＩＤＣＳ２０８へのユーザアイデンティティをプロビジョニングする。本実施形態はさらに、クラウド２０８からオンプレミス２０６への認証の連携のためのＳＡＭＬバス２２８（またはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔバス）を提供する。

【0034】

図３の実施形態において、オラクル社のオラクルアイデンティティマネージャ（Oracle
Identity Manager）（「ＯＩＭ」）コネクタ３０２およびオラクル社のオラクルアクセ
スマネージャ（Oracle Access Manager）（「ＯＡＭ」）連携モジュール３０６は、オラ
クルＩＤＭ３０４の拡張モジュールとして実現される。コネクタは、システムに話しかける方法について物理的な認識があるモジュールである。ＯＩＭは、ユーザアイデンティティを管理するように構成されたアプリケーションである（たとえば、ユーザがアクセス権を持つべき対象とアクセス権を持つべきでない対象に基づいて異なるシステムのユーザアカウントを管理する）。ＯＡＭは、ウェブＳＳＯ、アイデンティコンテキスト、認証および認可、ポリシー管理、テスト、ロギング、監査などのアクセス管理機能を提供するセキュリティアプリケーションである。ＯＡＭはＳＡＭＬに対するビルトイン（built-in）サポートを有する。ユーザがＩＤＣＳ２０２のアカウントを有する場合、ＯＩＭコネクタ３０２およびＯＡＭ連携３０６をオラクルＩＤＭ３０４とともに使用することにより、このアカウントを作成／削除し、このアカントからのアクセスを管理することができる。

【0035】

図４は、図２および図３と同一のコンポーネント２０２、２０６、２０８、２１０、２１２、２１４、２１６、２１８、２２０、２２２、２２４、２２６、２３４を含む実施形態の一例のブロック図４００である。しかしながら、図４の実施形態において、ＩＤＣＳ２０２は、クラウドアイデンティをオンプレミスアプリケーション２１８に拡張するための機能を提供する。本実施形態は、オンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがるアイデンティティのシームレスなビューを提供する。図４の実施形態において、ＳＣＩＭアイデンティティバス２３４を用いることにより、ＩＤＣＳ２０２のデータを「クラウドキャッシュ」４０２と呼ばれるオンプレミスＬＤＡＰデータと同期させる。クラウドキャッシュ４０２は以下でより詳細に開示される。

【0036】

一般的に、ＬＤＡＰに基づいて通信するように構成されたアプリケーションは、ＬＤＡＰ接続を必要とする。このようなアプリケーションはＬＤＡＰ接続をＵＲＬを用いて構築しないかもしれない（たとえばGoogle（登録商標）に接続する「www.google.com」とは違って）。なぜなら、ＬＤＡＰはローカルネットワーク上になければならないからである。図４の実施形態において、ＬＤＡＰベースのアプリケーション２１８は、クラウドキャッシュ４０２に接続し、クラウドキャッシュ４０２は、ＩＤＣＳ２０２に接続してから、要求されているデータをＩＤＣＳ２０２から引出す。ＩＤＣＳ２０２とクラウドキャッシュ４０２との間の通信は、ＳＣＩＭプロトコルに従って実現されてもよい。たとえば、クラウドキャッシュ４０２はＳＣＩＭバス２３４を用いてＳＣＩＭ要求をＩＤＣＳ２０２に送信し、それに対応するデータを受信してもよい。

【0037】

一般的に、あるアプリケーションの完全な実現は、コンシューマポータルを構築することと、外部ユーザ集団に対してマーケティングキャンペーンを実行することと、ウェブおよびモバイルチャネルをサポートすることと、ユーザ認証、セッション、ユーザプロファイル、ユーザグループ、アプリケーションロール、パスワードポリシー、セルフサービス／登録、社会的統合、アイデンティ連携などを処理することとを含む。一般的に、アプリケーションの開発者はアイデンティティ／セキュリティの専門家ではない。このため、オンデマンドのアイデンティティ管理サービスが望ましいのである。

【0038】

図５は、図２～図４と同一のコンポーネント２０２、２２０、２２２、２２４、２２６、２３４、４０２を含む実施形態の一例のブロック図５００である。しかしながら、図５の実施形態において、ＩＤＣＳ２０２は、オンデマンドで安全なアイデンティティ管理を提供する。本実施形態は、オンデマンドの、ＩＤＣＳ２０２のアイデンティサービスとの統合を提供する（たとえばＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、ＯＡｕｔｈ２、ＳＡＭＬ２、またはＳＣＩＭなどの標準に基づいて）。（オンプレミスであってもパブリッククラウド内またはプライベートクラウド内にあってもよい）アプリケーション５０５は、ＩＤＣＳ２０２のアイデンティティサービスＡＰＩ５０４をコールしてもよい。ＩＤＣＳ２０２が
提供するサービスは、たとえば、セルフサービス登録５０６、パスワード管理５０８、ユーザプロファイル管理５１０、ユーザ認証５１２、トークン管理５１４、社会的統合５１６などを含み得る。

【0039】

本実施形態において、ＳＣＩＭアイデンティティバス２３４を用いることにより、ＩＤＣＳ２０２内のデータを、オンプレミスのＬＤＡＰクラウドキャッシュ４０２内のデータと同期させる。さらに、ウェブサーバ／プロキシ（たとえばＮＧＩＮＸ、Apacheなど）上で実行している「クラウドゲート」５０２を、アプリケーション５０５が用いて、ＩＤＣＳ２０２からユーザウェブＳＳＯおよびＲＥＳＴ ＡＰＩセキュリティを取得してもよい。クラウドゲート５０２は、クライアントアプリケーションが有効なアクセストークンを提供すること、および／またはユーザがＳＳＯセッション構築のために正常に認証することを保証することによって、マルチテナントＩＤＣＳマイクロサービスへのアクセスを安全なものするコンポーネントである。クラウドゲート５０２は以下でさらに開示される。クラウドゲート５０２（webgate／webagentと同様の実施ポイント）は、サポートされて
いるウェブサーバの背後で実行されているアプリケーションがＳＳＯに参加することを可能にする。

【0040】

一実施形態は、ＳＳＯおよびクラウドＳＳＯ機能を提供する。多くの組織において、オンプレミスＩＡＭおよびＩＤＣＳいずれにおいても一般的なエントリポイントはＳＳＯである。クラウドＳＳＯは、ユーザが、１回のユーザサイン・インで複数のクラウドリソースにアクセスできるようにする。組織はそのオンプレミスアイデンティティの連携を希望することが多い。したがって、実施形態は、オープン標準を利用することで、既存のＳＳＯとの統合を実現することにより、投資の節約と拡大を可能にする（たとえば、アイデンティティクラウドサービス手法への最終的な完全移行まで）。

【0041】

一実施形態は以下の機能を提供し得る。
・アイデンティティストアを維持することにより、既に認可されているユーザアカウント、所有権、アクセス、および許可を追跡する。
・ワークフローとの統合により、アプリケーションのアクセスに必要なさまざまな承認（たとえば管理、ＩＴ、人的資源、法律、およびコンプライアンス）を簡単にする。
・選択的装置（たとえばモバイルおよびパーソナルコンピュータ（「ＰＣ」））に対するＳａａＳユーザアカウントをプロビジョニングする。ユーザポータルへのアクセスは、多数のプライベートおよびパブリッククラウドリソースを含む。
・規則および現在の職責へのコンプライアンスのための定期的な管理立証を容易にする。

【0042】

これらの機能に加えて、実施形態はさらに、
・クラウドアプリケーションにおけるアカウントライフサイクルの管理のためのクラウドアカウントのプロビジョニング、
・よりロバストなマルチファクタ認証（multifactor authentication）（「ＭＦＡ」）の統合、
・拡張モバイルセキュリティ機能、および
・動的認証オプション
を提供し得る。

【0043】

一実施形態は、適応認証およびＭＦＡを提供する。一般的に、パスワードおよび確認のための質問は、不十分でありフィッシングなどのよくある攻撃に晒され易いとみなされてきた。現代の大半の企業体は、リスクを下げるために何らかの形態のＭＦＡに注目している。しかしながら、ソリューションが首尾よくデプロイされるためには、ソリューションをエンドユーザが簡単にプロビジョニング、維持、および理解する必要がある。なぜなら、エンドユーザは通常、そのデジタル体験を妨害するものに対し、それが何であろうと抵
抗するからである。企業は、ＭＦＡを、シームレスなユーザアクセス体験のほぼトランスペアレントなコンポーネントにしつつ、私物の業務利用（bring your own device）（「
ＢＹＯＤ」）、社会的アイデンティティ、遠隔ユーザ、顧客、および契約者を安全に組込む方法を探している。ＭＦＡのデプロイにおいて、ＯＡｕｔｈおよびＯｐｅｎＩＤ Ｃｏｎｎｅｃｔなどの産業標準は、既存のマルチファクタソリューションの統合と、より新しい適応認証技術の導入とを保証するのに不可欠である。したがって、実施形態は、動的（または適応）認証を、利用できる情報（すなわちＩＰアドレス、場所、時刻、およびバイオメトリクス）の評価として定義することにより、ユーザセッション開始後のアイデンティを証明する。適切な標準（たとえばオープン認証（open authentication）（「ＯＡＴ
Ｈ」）および高速オンライン認証（fast identity online）（「ＦＩＤＯ」）の統合と、拡張可能なアイデンティティ管理フレームワークとを用いて、実施形態は、エンド・ツー・エンドの安全なＩＡＭデプロイの一部としてＩＴ組織内で簡単に採用、アップグレード、および統合できるＭＦＡソリューションを提供する。ＭＦＡおよび適応ポリシーを検討する場合、組織は、ハイブリッドのＩＤＣＳおよびオンプレミスＩＡＭ環境においてシステム間の統合を必要とするオンプレミスリソースおよびクラウドリソースにわたって一貫したポリシーを実現しなければならない。

【0044】

一実施形態は、ユーザプロビジョニングおよび証明を提供する。一般的に、ＩＡＭソリューションの基本機能は、ユーザプロビジョニングライフサイクル全体を可能にしかつサポートすることである。これは、ユーザに対し、組織内におけるそのアイデンティティおよびロール（role）に適したアプリケーションアクセスを与えること（たとえば、ユーザのロールまたはそのロールの中で使用されるタスクもしくはアプリケーションは時間の経過に伴って変化するので）と、ユーザが組織から脱退するときに必要な、素早いユーザデプロビジョニングとを含む。これは、さまざまなコンプライアンス条件を満たすために重要であるだけでなく、不適切なインサイダーアクセスがセキュリティ侵害および攻撃の主要な原因であるので、重要である。アイデンティティクラウドソリューションにおける、自動化されたユーザプロビジョニング機能は、それ自身の権利において重要になり得るだけでなく、ハイブリッドＩＡＭソリューションの一部としても重要であり、したがって、ＩＤＣＳプロビジョニングは、企業が縮小、拡大、合併する、または既存のシステムをＩａａＳ／ＰａａＳ／ＳａａＳ環境と統合しようとする場合、移行時において、オンプレミスソリューションよりも高い柔軟性を提供し得る。ＩＤＣＳ手法は、一度限りのアップグレードにおいて時間と労力を節約することができ、必要な部門、事業部、およびシステムの適切な統合を保証する。企業ではこの技術をスケーリングする必要性が密かに発生することが多く、企業体系全体にスケーラブルなＩＤＣＳ機能を迅速に提供することは、柔軟性、コスト、および制御の点で利益をもたらし得る。

【0045】

一般的に、被雇用者は、長年にわたり、職種の変化に応じて追加の権限が付与される（すなわち「権限のクリープ」）。規制が緩やかな企業は一般的に「立証」プロセスが欠落している。このプロセスは、企業の被雇用者の権限（たとえばネットワーク、サーバ、アプリケーション、およびデータへのアクセス権）を定期的に監査して、過剰な権限が付与されたアカウントの原因となる権限のクリープを止めるまたは減速させる管理者を必要とする。したがって、一実施形態は、定期的に実施される（少なくとも１年に一度）立証プロセスを提供し得る。さらに、合併および買収に伴い、これらのツールおよびサービスの必要性は急激に増す。ユーザが、ＳａａＳシステムに存在する、オンプレミス上に存在する、異なる部門にまたがっている、および／またはデプロビジョニングされているもしくは再度割り当てられているからである。クラウドへの動きはこの状況をさらに混乱させる可能性があり、事態は、既存の手動管理されることが多い証明方法を超えて急速にエスカレートする可能性がある。したがって、一実施形態は、これらの機能を自動化し、高度な分析を、ユーザプロファイル、アクセス履歴、プロビジョニング／デプロビジョニング、および細分化された権利に適用する。

【0046】

一実施形態はアイデンティティ分析を提供する。一般的に、アイデンティティ分析を、包括的な証明および立証のためにＩＡＭエンジンと統合する機能は、組織のリスクプロファイルを安全にするためには不可欠となる可能性がある。適切にデプロイされたアイデンティティ分析は、内部ポリシー全体の施行を要求する可能性がある。クラウドおよびオンプレミス全体で統一された単一管理ビューを提供するアイデンティティ分析は、予防的ガバナンス、リスク、およびコンプライアンス（governance, risk, and compliance）（「ＧＲＣ」）企業環境における必要性が高く、リスクを低減しコンプライアンス規則を満たすための閉ループプロセスを提供するのに役立ち得る。したがって、一実施形態はアイデンティティ分析を提供する。アイデンティティ分析は、管理者、幹部職員、および監査役が必要とするレポートおよび分析のために、クライアントが簡単にカスタマイズすることで特定の産業条件および政府規則に適合する。

【0047】

一実施形態は、セルフサービスおよびアクセス要求機能を提供することにより、エンドユーザの体験および効率を改善するとともに、ヘルプデスクコールに要するコストを低減する。一般的に、多数の企業はその従業員のためにオンプレミスのセルフサービスアクセス要求をデプロイするが、多くは、これらのシステムを正式な企業の壁の外側まで適切に拡張していない。従業員の用途の範囲外の、ポジティブなデジタル顧客体験が、ビジネスの信頼性を高め最終的には収入の増加に貢献し、企業は、顧客ヘルプデスクコールを減じるだけでなく顧客の満足度を高める。したがって、一実施形態は、オープン標準に基づいておりかつ必要に応じて既存のアクセス制御ソフトウェアおよびＭＦＡメカニズムとシームレスに統合される、アイデンティティクラウドサービス環境を提供する。ＳａａＳ配信モデルは、以前はシステムのアップグレードおよびメンテナンスに費やされていた時間と労力を省き、ＩＴ専門スタッフを解放してより中心的なビジネスアプリケーションに集中できるようにする。

【0048】

一実施形態は、特権アカウント管理（privileged account management）（「ＰＡＭ」
）を提供する。一般的に、すべての組織は、ＳａａＳ、ＰａａＳ、ＩａａＳまたはオンプレミスアプリケーションいずれを使用しても、システムアドミニストレータ、幹部職員、人事担当役員、契約者、システムインテグレータなどのスーパーユーザのアクセスクレデンシャルを用いたインサイダーによる特権アカウントの不正使用に弱い。加えて、外部の脅威は一般的に、先ず低レベルユーザアカウントを侵害し、最終的には企業システム内の特権ユーザアクセス制御に到達してこれを利用する。したがって、一実施形態は、ＰＡＭを提供することにより、このような不正なインサイダーによるアカウントの使用を防止する。ＰＡＭソリューションの主要コンポーネントはパスワードボールト（password vault）であり、これはさまざまなやり方で供給し得る。たとえば、企業サーバ上にインストールされるソフトウェアとして、これも企業サーバ上の仮想アプライアンスとして、パッケージングされたハードウェア／ソフトウェアアプライアンスとして、または、クラウドサービスの一部として、さまざまなやり方で供給し得る。ＰＡＭ機能は、エンベロープ内で保持されサインインおよびサイン・アウトのためのマニフェストで定期的に変更されるパスワードを格納するために使用される物理的な安全場所と同様である。一実施形態は、パスワードのチェックアウトだけでなく、タイムリミットの設定、強制的な期間変更、自動的なチェックアウトの追跡、およびすべてのアクティビティに関する報告を、可能にする。一実施形態は、要求されたリソースに、ユーザがパスワードを知らない状態で、直接接続する方法を提供する。この機能はまた、セッション管理およびその他の機能の方法に道を開く。

【0049】

一般的に、ほとんどのクラウドサービスは、ＡＰＩおよび管理インターフェイスを利用している。これらは、侵入者がセキュリティを迂回する機会を与える。したがって、一実施形態は、ＰＡＭの実施におけるこれらの欠陥を埋める。クラウドへの移行によってＰＡ
Ｍに新たな課題が発生するからである。小規模から中規模の多くのビジネスは現在自身のＳａａＳシステム（たとえばOffice 365）を管理しているが、大企業は自身のＳａａＳおよびＩａａＳサービスの回転数を上げる個々のビジネス単位を持つことが増えている。これらの顧客は、ＰＡＭ機能がアイデンティティクラウドサービスソリューションに含まれるかまたはそのＩａａＳ／ＰａａＳプロバイダから得られるが、この責務を扱った経験がほとんどない。加えて、場合によっては、多くの異なる地理的に分散したビジネス単位が、同じＳａａＳアプリケーションの管理責任を分離しようとする。したがって、一実施形態は、こういった状況にある顧客が、既存のＰＡＭをアイデンティティクラウドサービスの全体的なアイデンティティフレームワークの中にリンクさせ、より高い安全性とコンプライアンスに向けて、ビジネスニーズが要求するクラウドロード条件に合わせて確実に調整することを、可能にする。

【0050】

ＡＰＩプラットフォーム
実施形態が提供するＡＰＩプラットフォームは、機能のコレクションをサービスとしてエクスポーズする。ＡＰＩはマイクロサービスに集約され、各マイクロサービスは、ＡＰＩのうちの１つ以上をエクスポーズする。すなわち、各マイクロサービスは異なる種類のＡＰＩをエクスポーズし得る。一実施形態において、各マイクロサービスはそのＡＰＩを通してしか通信しない。一実施形態において、各ＡＰＩはマイクロサービスであってもよい。一実施形態において、複数のＡＰＩが１つのサービスに、このサービスが提供するターゲット機能に基づいて集約される（たとえばＯＡｕｔｈ、ＳＡＭＬ、Ａｄｍｉｎなど）。結果として、同様のＡＰＩは別々のランタイムプロセスとしてエクスポーズされない。ＡＰＩは、ＩＤＣＳが提供するサービスを使用するためにサービス消費者が利用できるようにされたものである。

【0051】

一般的に、ＩＤＣＳのウェブ環境において、ＵＲＬは、３つの部分として、ホストと、マイクロサービスと、リソースとを含む（たとえばホスト／マイクロサービス／リソース）。一実施形態において、マイクロサービスは、特定のＵＲＬプレフィックスを有することを特徴とし（たとえば「host/oauth/v1」）、実際のマイクロサービスは「oauth/v1」
である。「oauth/v1」の下で複数のＡＰＩが存在し、たとえば、トークン（token）を要
求するためのＡＰＩ：「host/oauth/v1/token」、ユーザを認証する（authorize）ためのＡＰＩ：「host/oauth/v1/authorize」などである。すなわち、ＵＲＬはマイクロサービ
スを実現し、ＵＲＬのリソース部分はＡＰＩを実現する。したがって、同じマイクロサービスの下で複数のＡＰＩが集約される。一実施形態において、ＵＲＬのホスト部分はテナントを特定する（たとえば、https://tenant3.identity.oraclecloud.com:/oauth/v1/token）。

【0052】

必要なエンドポイントを有する外部サービスと統合するアプリケーションを構成し当該構成を最新状態に保つことは、一般的に難題である。この難題を克服するために、実施形態は、パブリックディスカバリＡＰＩを周知の場所にエクスポーズし、そこから、アプリケーションは、ＡＤＣＳ ＡＰＩを消費するために必要なＩＤＣＳに関する情報を発見する（discover）ことができる。一実施形態において、２つのディスカバリ文献がサポートされ、それらは、ＩＤＣＳ構成（たとえば、<IDCS-URL>/.well-known/idcs-configurationのＩＤＣＳ、ＳＡＭＬ、ＳＣＩＭ、ＯＡｕｔｈ、およびＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ
構成を含む）と、（たとえば<IDCS-URL>/.well-known/openid-configurationの）産業標
準ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ構成とである。アプリケーションは、単一のＩＤＣＳ ＵＲＬで構成されることにより、ディスカバリ文献を取り出すことができる。

【0053】

図６は、一実施形態におけるＩＤＣＳのシステムビュー６００を提供するブロック部である。図６において、さまざまなアプリケーション／サービス６０２のうちのいずれも、ＩＤＣＳ ＡＰＩに対してＨＴＴＰコールを行うことにより、ＩＤＣＳサービスを使用す
ることができる。このようなアプリケーション／サービス６０２の例は、ウェブアプリケーション、ネイティブアプリケーション（たとえばWindows（登録商標）アプリケーショ
ン、ｉＯＳ（登録商標）アプリケーション、アンドロイド（登録商標）アプリケーションなど、特定のオペレーティングシステム上で走るように構築されたアプリケーション）、ウェブサービス、顧客アプリケーション、パートナーアプリケーション、または、サービスとしてのソフトウェア（Software as a Service）（「ＳａａＳ」）、ＰａａＳ、およ
びサービスとしてのインフラストラクチャ（Infrastructure as a Service）（「Ｉａａ
Ｓ」）など、パブリッククラウドによって提供されるサービスである。

【0054】

一実施形態において、ＩＤＣＳサービスを要求するアプリケーション／サービス６０２のＨＴＴＰ要求は、オラクルパブリッククラウドＢＩＧ－ＩＰアプライアンス６０４およびＩＤＣＳ ＢＩＧ－ＩＰアプライアンス６０６（またはロードバランサなどの同様の技術、または、適切なセキュリティルールを実現してトラフィックを保護するサービスとしてのクラウドロードバランサ（Cloud Load Balancer as a Service）（「ＬＢａａＳ」）と呼ばれているコンポーネント）を通る。しかしながら、この要求はどのようなやり方で受信されてもよい。ＩＤＣＳ ＢＩＧ－ＩＰアプライアンス６０６（または、適用できる場合は、ロードバランサまたはクラウドＬＢａａＳなどの同様の技術）において、クラウドプロビジョニングエンジン６０８は、テナントおよびサービスの調整を実行する。一実施形態において、クラウドプロビジョニングエンジン６０８は、クラウドにオンボードされている新たなテナントに対応付けられた内部セキュリティアーティファクト、または、顧客が購入した新たなサービスインスタンスを管理する。

【0055】

このＨＴＴＰ要求は次にＩＤＣＳウェブルーティング層６１０によって受信される。このルーティング層は、セキュリティゲート（すなわちクラウドゲート）を実現し、サービスルーティングならびにマイクロサービス登録および発見６１２を提供する。要求されるサービスに応じて、ＨＴＴＰ要求は、ＩＤＣＳ中間層６１４のＩＤＣＳマイクロサービスに転送される。ＩＤＣＳマイクロサービスは、外部および内部ＨＴＴＰ要求を処理する。ＩＤＣＳマイクロサービスは、プラットフォームサービスおよびインフラストラクチャサービスを実現する。ＩＤＣＳプラットフォームサービスは、ＩＤＣＳのビジネスを実現する、別々にデプロイされたＪａｖａベースのランタイムサービスである。ＩＤＣＳインフラストラクチャサービスは、ＩＤＣＳに対してインフラストラクチャサポートを提供する、別々にデプロイされたランタイムサービスである。ＩＤＣＳはさらに、ＩＤＣＳサービスによって使用される共有ライブラリとしてパッケージングされた共通コードであるインフラストラクチャライブラリと、共有ライブラリとを含む。インフラストラクチャサービスおよびライブラリは、プラットフォームサービスがその機能を実現するために要求するサポート機能を提供する。

【0056】

プラットフォームサービス
一実施形態において、ＩＤＣＳは標準認証プロトコルをサポートし、したがって、ＩＤＣＳマイクロサービスは、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、ＯＡｕｔｈ、ＳＡＭＬ２、クロスドメインアイデンティティ管理のためのシステム（System for Cross-domain Identity Management++：「ＳＣＩＭ＋＋」）などのプラットフォームサービスを含む。

【0057】

ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔプラットフォームサービスは、標準ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔログイン／ログアウトフローを実現する。対話型のウェブベースおよびネイティブアプリケーションは、標準のブラウザベースのＯｐｅｎＩＤ Ｃｏｎｎｅｃｔフローを推進することによりユーザ認証を要求し、ユーザの認証されたアイデンティティを伝達するＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（JavaScript Object Notation（「ＪＳＯＮ」）ウェブトークン（Web Token「ＪＷＴ」）である標準アイデンティテ
ィトークンを受信する。内部において、ランタイム認証モデルはステートレスであり、ユ
ーザの認証／セッション状態をホストＨＴＴＰクッキー（ＪＷＴアイデンティティトークンを含む）の形態で維持する。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔプロトコルを介して開始された認証対話は、ローカルおよび連携ログインのためにユーザのログイン／ログアウトセレモニーを実現する信頼できるＳＳＯサービスに委任される。この機能のさらなる詳細は以下において図１０および図１１を参照しながら開示される。一実施形態において、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ機能は、たとえばＯｐｅｎＩＤ Ｆｏｕｎｄａｔｉｏｎ標準に従って実現される。

【0058】

ＯＡｕｔｈ２プラットフォームサービスは、トークン認可サービスを提供する。これは、ユーザの権利を伝達するアクセストークンを作成し検証してＡＰＩコールを行うためのリッチなＡＰＩインフラストラクチャを提供する。これは、ある範囲の有用なトークン付与タイプをサポートし、顧客がクライアントをそのサービスに安全に接続することを可能にする。これは、標準の２者間および３者間ＯＡｕｔｈ２トークン付与タイプを実現する。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ（「ＯＩＤＣ」）をサポートすることにより、コンプライアントなアプリケーション（ＯＩＤＣリレーパーティ（「ＲＰ」））が、アイデンティティプロバイダとしてのＩＤＣＳと統合されることを可能にする（ＯＩＤＣ ＯｐｅｎＩＤプロバイダ（「ＯＰ」）。同様に、ＯＩＤＣ ＲＰとしてのＩＤＣＳをソーシャルＯＩＤＣ ＯＰ（たとえばFacebook（登録商標）、Google（登録商標）など）と統合することにより、顧客は、アプリケーションに対する社会的アイデンティのポリシーベースアクセスを可能にする。一実施形態において、ＯＡｕｔｈ機能は、たとえば、インターネットエンジニアリングタスクフォース（Internet Engineering Task Force）（「ＩＥＴＦ」）
、コメント要求（Request for Comments）（「ＲＦＣ」）６７４９に従って実現される。

【0059】

ＳＡＭＬ２プラットフォームサービスは、アイデンティティ連携サービスを提供する。これは、顧客が、ＳＡＭＬアイデンティティプロバイダ（identity provider）（「ＩＤ
Ｐ」）およびＳＡＭＬサービスプロバイダ（service provider）（「ＳＰ」）関係モデルに基づいて、そのパートナーとの連携合意を設定することを可能にする。一実施形態において、ＳＡＭＬ２プラットフォームサービスは、標準ＳＡＭＬ２ブラウザポストログインおよびログアウトプロファイルを実現する。一実施形態において、ＳＡＭＬ機能は、たとえばＩＥＴＦ、ＲＦＣ７５２２に従って実現される。

【0060】

ＳＣＩＭは、ユーザアイデンティ情報を、たとえばＩＥＴＦ、ＲＦＣ ７６４２、７６４３、７６４４によって提供される、アイデンティティドメインまたは情報技術（「ＩＴ」）システム間でのユーザアイデンティティ情報の交換を自動化するためのオープン標準である。ＳＣＩＭ＋＋プラットフォームサービスは、アイデンティティ管理サービスを提供し、顧客がＩＤＣＳのＩＤＰフィーチャー（feature）にアクセスすることを可能にす
る。管理サービスは、アイデンティティライフサイクル、パスワード管理、グループ管理などをカバーするステートレスなＲＥＳＴインターフェイス（すなわちＡＰＩ）のセットをエクスポーズし、ウェブアクセス可能なリソースのようなアーティファクトをエクスポーズする。

【0061】

すべてのＩＤＣＳ構成アーティファクトはリソースであり、管理サービスのＡＰＩは、ＩＤＣＳリソース（たとえばユーザ、ロール、パスワードポリシー、アプリケーション、ＳＡＭＬ／ＯＩＤＣアイデンティティプロバイダ、ＳＡＭＬサービスプロバイダ、キー、証明、通知テンプレートなど）の管理を可能にする。管理サービスは、ＳＣＩＭ標準を強化および拡張することにより、すべてのＩＤＣＳリソースに対する作成（Create）、読み取り（Read）、更新（Update）、削除（Delete）、および問合せ（Query）（「ＣＲＵＤ
Ｑ」）動作のためにスキーマベースのＲＥＳＴ ＡＰＩを実現する。加えて、ＩＤＣＳ自体の管理および構成に使用されるＩＤＣＳのすべての内部リソースは、ＳＣＩＭベースのＲＥＳＴ ＡＰＩとしてエクスポーズされる。アイデンティティストア６１８へのアクセ
スはＳＣＩＭ＋＋ＡＰＩに分離される。

【0062】

一実施形態において、たとえば、ＳＣＩＭ標準は、ＳＣＩＭ規格によって規定されるユーザおよびグループリソースを管理するように実現されるのに対し、ＳＣＩＭ＋＋は、ＳＣＩＭ規格によって規定される言語を用いてさらに他のＩＤＣＳ内部リソース（たとえばパスワードポリシー、ロール、設定など）をサポートするように構成される。

【0063】

管理サービスは、ＳＣＩＭ２．０標準エンドポイントを、標準ＳＣＩＭ２．０コアスキーマと、必要に応じてスキーマ拡張とを用いてサポートする。加えて、管理サービスは、いくつかのＳＣＩＭ２．０準拠エンドポイント拡張をサポートすることにより、その他のＩＤＣリソースを、たとえばユーザ、グループ、アプリケーション、設定などを、管理する。管理サービスはまた、ＣＲＵＤＱ動作は実行しないがその代わりに機能サービスを、たとえば「UserPasswordGenerator」、「UserPasswordValidator」などを提供する、リモートプロシージャコールスタイル（remote procedure call-style）（「ＲＰＣスタイル
」）ＲＥＳＴインターフェイスのセットをサポートする。

【0064】

ＩＤＣＳ管理ＡＰＩは、ＯＡｕｔｈ２プロトコルを認証および認可に使用する。ＩＤＣＳは、ウェブサーバ、モバイル、およびＪａｖａＳｃｒｉｐｔアプリケーションのためのシナリオといった共通のＯＡｕｔｈ２シナリオをサポートする。ＩＤＣＳ ＡＰＩへのアクセスはアクセストークンによって保護される。ＩＤＣＳ管理ＡＰＩにアクセスするために、アプリケーションは、ＩＤＣＳ管理コンソールを通してＯＡｕｔｈ２クライアントとしてまたはＩＤＣＳアプリケーションとして（この場合ＯＡｕｔｈ２クライアントは自動的に作成される）登録される必要があり、また、所望のＩＤＣＳ管理ロールを与えられる必要がある。ＩＤＣＳ管理ＡＰＩコールを行うとき、アプリケーションは先ず、ＩＤＣＳ
ＯＡｕｔｈ２サービスにアクセストークンを要求する。このトークンを取得した後に、このアプリケーションはアクセストークンを、そこにＨＴＴＰ認可ヘッダを含めて送信する。アプリケーションは、ＩＤＣＳ管理ＲＥＳＴ ＡＰＩを直接使用することができる、または、ＩＤＣＳＪａｖａクライアントＡＰＩライブラリを使用することができる。

【0065】

インフラストラクチャサービス
ＩＤＣＳインフラストラクチャサービスは、ＩＤＣＳプラットフォームサービスの機能をサポートする。これらのランタイムサービスは、（ユーザ通知、アプリケーション申込、およびデータベースに対する監査を非同期的に処理するための）イベント処理サービスと、（ジョブをスケジューリングして実行するため、たとえば、ユーザの介入が不要な長時間実行タスクを直ちに実行するまたは設定時間に実行するための）ジョブスケジューラサービスと、キャッシュ管理サービスと、（パブリッククラウドストレージサービスと統合するための）ストレージ管理サービスと、（レポートおよびダッシュボードを生成するための）レポートサービスと、（内部ユーザ認証およびＳＳＯを管理するための）ＳＳＯサービスと、（異なる種類のユーザインターフェイス（user interface）（「ＵＩ」）クライアントをホストするための）ユーザインターフェイス（「ＵＩ」）サービスと、サービスマネージャサービスとを含む。サービスマネージャは、オラクルパブリッククラウドとＩＤＣＳとの間の内部インターフェイスである。サービスマネージャは、オラクルパブリッククラウドによって発行されたコマンドを管理し、このコマンドはＩＤＣＳによって実現される必要がある。たとえば、顧客が、何かを購入できる状態になる前にクラウドストア内のアカウントに対してサインアップした場合、クラウドは、テナントを作成することを依頼するための要求をＩＤＣＳに送信する。この場合、サービスマネージャは、ＩＤＣＳがサポートするとクラウドが予測するクラウド固有の動作を実現する。

【0066】

ＩＤＣＳマイクロサービスは、ネットワークインターフェイスを通して別のＩＤＣＳマイクロサービスをコールしてもよい（すなわちＨＴＴＰ要求）。

【0067】

一実施形態において、ＩＤＣＳはまた、データベーススキーマを使用できるようにするスキーマサービス（またはパーシステンス（persistence）サービス）を提供し得る。ス
キーマサービスは、データベーススキーマを管理する責任をＩＤＣＳに委任することを可能にする。したがって、ＩＤＣＳのユーザはデータベースを管理する必要がない。なぜなら、この機能を提供するＩＤＣＳサービスが存在するからである。たとえば、ユーザは、データベースを用いてテナントごとにスキーマをパーシストしてもよく、データベース内にスペースがなくなったときにはスキーマサービスが、ユーザがデータベースを自身で管理しなくてもよいように、別のデータベースを取得し上記空間を拡大するという機能を管理する。

【0068】

ＩＤＣＳはさらに、ＩＤＣＳが必要とする／生成するデータリポジトリであるデータストアを含む。これは、（ユーザ、グループなどを格納する）アイデンティティストア６１８、（ＩＤＣＳが自身を構成するために使用する構成データを格納する）グローバルデータベース６２０、（テナントごとにスキーマを分離し顧客ごとに顧客データを格納する）オペレーショナルスキーマ６２２、（監査データを格納する）監査スキーマ６２４、（キャッシュされたオブジェクトを格納することにより実施速度を高める）キャッシングクラスタ６２６などを含む。内部および外部のすべてのＩＤＣＳコンシューマは、標準ベースのプロトコルに従ってアイデンティティサービスと統合される。これにより、ドメインネームシステム（domain name system）（「ＤＮＳ」）を用いて、どこに要求をルーティングすべきかを決定することができ、アプリケーションを消費することをアイデンティティサービスの内部実現を理解することから切離す。

【0069】

リアルタイムおよびニア・リアルタイムタスク
ＩＤＣＳは、要求されたサービスのタスクを、同期リアルタイムタスクと非同期ニア・リアルタイムタスクとに分離する。リアルタイムタスクは、ユーザが進むのに必要なオペレーションのみを含む。一実施形態において、リアルタイムタスクは、最少の遅延で実行されるタスクであり、ニア・リアルタイムタスクは、バックグラウンドにおいて、ユーザが待つことなく実行されるタスクである。一実施形態において、リアルタイムタスクは、実質的に遅延なしでまたはごくわずかな遅延で実行されるタスクであり、ユーザには、ほぼ瞬時に実行されているように見えるタスクである。

【0070】

リアルタイムタスクは、特定のアイデンティティサービスの主要なビジネス機能を実行する。たとえば、ログインサービスを要求するとき、アプリケーションは、メッセージを送信してユーザのクレデンシャルを認証しそれに対するセッションクッキーを取得する。ユーザが体験するのは、システムへのログインである。しかしながら、ユーザのログインに関しては、ユーザが誰であるかの検証、監査、通知の送信など、その他いくつかのタスクが実行されるであろう。したがって、クレデンシャルの検証は、ユーザがＨＴＴＰクッキーを与えられてセッションを開始するように、リアルタイムで実行されるタスクであるが、通知（たとえば電子メールを送信してアカウント作成を通知すること）、監査（たとえば追跡／記録）などに関連するタスクは、ユーザが最少の遅延で進むことができるよう非同期的で実行することができるニア・リアルタイムタスクである。

【0071】

マイクロサービスを求めるＨＴＴＰ要求が受信されると、対応するリアルタイムタスクが中間層のマイクロサービスによって実行され、必ずしもリアルタイム処理を受けない演算ロジック／イベントなどの残りのニア・リアルタイムタスクは、メッセージキュー６２８にオフロードされる。メッセージキュー６２８は、配信および処理が保証された状態でスケーラビリティが高い非同期イベント管理システム６３０をサポートする。したがって、特定の挙動は、フロントエンドからバックエンドにプッシュされることにより、ＩＤＣＳが、応答時間のレイテンシを少なくすることにより、ハイレベルサービスを顧客に提供
することを、可能にする。たとえば、ログインプロセスは、クレデンシャルの検証、ログレポートの提出、最後のログイン時間の更新などを含み得るが、これらのタスクは、メッセージキューにオフロードして、リアルタイムではなくニア・リアルタイムで実行することができる。

【0072】

一例において、システムが新たなユーザを登録または作成する必要がある場合がある。システムは、ＩＤＣＳ ＳＣＩＭ ＡＰＩをコールしてユーザを作成する。最終結果として、ユーザがアイデンティティストア６１８において作成されたときにこのユーザがそのパスワードをリセットするためのリンクを含む通知電子メールを得る。ＩＤＣＳが、新たなユーザを登録または作成することを求める要求を受けると、対応するマイクロサービスは、オペレーショナルデータベース（図６のグローバルデータベース６２０内に位置する）にある構成データに注目し、「ユーザ作成」という動作が「ユーザ作成」イベントでマーキングされていると判断する。この動作は、構成データにおいて非同期動作であることが識別される。マイクロサービスは、クライアントに戻り、ユーザの作成が正常に行われたことを示すが、通知電子メールの実際の送信は延期されバックエンドにプッシュされる。そうするために、マイクロサービスは、メッセージングＡＰＩ６１６を用いてこのメッセージを、ストアであるキュー６２８に入れる。

【0073】

キュー６２８から出すために、インフラストラクチャマイクロサービスであるメッセージングマイクロサービスは、バックグラウンドにおいて継続的に実行され、キュー６２８の中にあるイベントを探してキュー６２８をスキャンする。キュー６２８の中にあるイベントは、監査、ユーザ通知、アプリケーション申込、データ解析などのイベントサブスクライバ６３０によって処理される。イベントによって示されるタスクに応じて、イベントサブスクライバ６３０は、たとえば、監査スキーマ６２４、ユーザ通知サービス６３４、アイデンティティイベントサブスクライバ６３２などと通信し得る。たとえば、メッセージングマイクロサービスは、キュー６２８の中に「ユーザ作成」イベントを発見した場合、対応する通知ロジックを実行し対応する電子メールをユーザに送信する。

【0074】

一実施形態において、キュー６２８は、マイクロサービス６１４によってパブリッシュされたオペレーショナルイベントと、ＩＤＣＳリソースを管理するＡＰＩ６１６によってパブリッシュされたリソースイベントとをキューの中に入れる。

【0075】

ＩＤＣＳは、リアルタイムキャッシング構造を用いてシステムパフォーマンスおよびユーザ体験を向上させる。キャッシュそのものは、マイクロサービスとしても提供される。ＩＤＣＳは、ＩＤＣＳによってサポートされている顧客の数の増加に伴って増大するエラスティック・キャッシュクラスタ６２６を実現する。キャッシュクラスタ６２６は、以下でより詳細に開示される分散型データグリッドで実現されてもよい。一実施形態において、書込専用リソースがキャッシュをバイパスする。

【0076】

一実施形態において、ＩＤＣＳランタイムコンポーネントは、ヘルスおよびオペレーショナルメトリクスを、オラクル社のオラクルパブリッククラウドなどのパブリッククラウドのこのようなメトリクスを収集するパブリッククラウドモニタリングモジュール６３６に対してパブリッシュする。

【0077】

一実施形態において、ＩＤＣＳを用いてユーザを作成してもよい。たとえば、クライアントアプリケーション６０２は、ＲＥＳＴ ＡＰＩコールを発行してユーザを作成してもよい。管理サービス（６１４のプラットフォームサービス）は、このコールをユーザマネージャ（６１４のインフラストラクチャライブラリ／サービス）に委任する。そうすると、ユーザマネージャは、このユーザを、ＩＤストア６１８内の特定テナント用ＩＤストアストライプにおいて作成する。「ユーザ作成成功（User Create Success）」の場合、ユ
ーザマネージャは、オペレーションを監査することにより監査スキーマ６２４内のテーブルを監査し、メッセージキュー６２８に対して「identity.user.create.success」をパブリッシュする。アイデンティティサブスクライバ６３２は、このイベントをピックアップし、新たに作成されたログイン詳細を含む「ウェルカム」電子メールを、新たに作成されたユーザに送信する。

【0078】

一実施形態において、ＩＤＣＳを用いてロールをユーザに与えて、その結果ユーザがアクションをプロビジョニングしてもよい。たとえば、クライアントアプリケーション６０２は、ＲＥＳＴ ＡＰＩコールを発行してユーザにロールを付与してもよい。管理サービス（６１４のプラットフォームサービス）は、このコールをロールマネージャ（６１４のインフラストラクチャライブラリ／サービス）に委任してもよい。このロールマネージャは、ＩＤストア６１８内の特定テナント用ＩＤストアストライプにおけるロールを付与する。「ロール付与成功（Role Grant Success）」の場合、ロールマネージャは、監査スキーマ６２４における監査テーブルに対するオペレーションを監査し、メッセージキュー６２８に対して「identity.user.role.grant.success」をパブリッシュする。アイデンティティサブスクライバ６３２は、このイベントをピックアップしプロビジョニング付与ポリシーを評価する。付与されているロールに対するアクティブなアプリケーション付与があった場合、プロビジョニングサブスクライバは、何らかの検証を実行し、アカウント作成を開始し、ターゲットシステムをコールアウトし、ターゲットシステムにアカウントを作成し、アカウント作成が成功したとマーキングする。これらの機能各々の結果として、「prov.account.create.initiate」、「prov.target.create.initiate」、「prov.target.create.success」または「prov.account.create.success」などの対応するイベントがパブリッシュされることになり得る。これらのイベントは、直近Ｎ日間でターゲットシステムにおいて作成されたアカウントの数を合計する自身のビジネスメトリクスを有し得る。

【0079】

一実施形態において、ＩＤＣＳはユーザのログインのために使用することができる。たとえば、クライアントアプリケーション６０２は、サポートされている認証フローのうちの１つを用いてユーザのログインを要求してもよい。ＩＤＣＳは、ユーザを認証し、成功すると、監査スキーマ６２４における監査テーブルに対するオペレーションを監査する。失敗すると、ＩＤＣＳは、監査スキーマ６２４における失敗を監査し、メッセージキュー６２８の「login.user.login.failure」イベントをパブリッシュする。ログインサブスクライバは、このイベントをピックアップし、ユーザに対するそのメトリクスを更新し、ユーザのアクセス履歴についての追加分析を実行する必要があるか否かを判断する。

【0080】

したがって、「制御の反転」機能を実現する（たとえば実行の流れを変更することにより、後の時点におけるオペレーションの実行を、当該オペレーションが別のシステムの支配下になるように、スケジュールする）ことにより、実施形態は、その他のイベントキューおよびサブスクライバを動的に追加して、小さなユーザサンプルに対する新たな特徴を、より広いユーザベースにデプロイする前にテストする、または、特定の内部または外部の顧客のための特定のイベントを処理することができる。

【0081】

ステートレス機能
ＩＤＣＳマイクロサービスはステートレスである。これは、マイクロサービスそのものはステートを保持しないことを意味する。「ステート」とは、アプリケーションがその機能を果たすために使用するデータのことを言う。ＩＤＣＳは、マルチテナント機能を、すべてのステートを、ＩＤＣＳデータ層内の特定テナント向けリポジトリにパーシストすることによって提供する。中間層（すなわち要求を処理するコード）は、アプリケーションコードと同じ場所に格納されているデータを有しない。したがって、ＩＤＣＳは横方向および縦方向双方においてスケーラビリティが高い。

【0082】

縦方向のスケーリング（またはスケールアップ／ダウン）は、システム内の１つのノードにリソースを追加する（またはこのノードからリソースを削除する）ことを意味し、１つのコンピュータにＣＰＵまたはメモリを追加することを伴うのが一般的である。縦方向のスケーラビリティによって、アプリケーションはそのハードウェアの限界までスケールアップすることができる。横方向のスケーリング（またはスケールアウト／イン）は、新たなコンピュータを分散型ソフトウェアアプリケーションに追加するといったように、より多くのノードをシステムに追加する（またはシステムからノードを削除する）ことを意味する。横方向のスケーラビリティにより、アプリケーションはほぼ無限にスケーリング可能であり、ネットワークによって提供される帯域幅の量のみの制約を受ける。

【0083】

ＩＤＣＳの中間層がステートレスであることにより、ＣＰＵをさらに追加するだけで横方向にスケーラブルになり、アプリケーションの仕事を実行するＩＤＣＳコンポーネントは、特定なアプリケーションが走っている指定された物理的インフラストラクチャを持つ必要がない。ＩＤＣＳの中間層がステートレスであることにより、非常に多くの顧客／テナントにアイデンティティサービスを提供しているときであっても、ＩＤＣＳの可用性が高くなる。ＩＤＣＳアプリケーション／サービスを通る各パスは、専らアプリケーショントランザクションを実行するためにＣＰＵ用途に集中するが、データの格納にハードウェアを使用しない。スケーリングは、必要に応じてより多くのコピーを追加できるパーシステンス層にトランザクション用のデータが格納される一方で、アプリケーションが走っているときにより多くのスライスを追加することによって実現される。

【0084】

ＩＤＣＳウェブ層、中間層、およびデータ層は各々独立してかつ別々にスケーリング可能である。ウェブ層をスケーリングすることにより、より多くのＨＴＴＰ要求を扱うことができる。中間層をスケーリングすることにより、より多くのサービス機能をサポートすることができる。データ層をスケーリングすることにより、より多くのテナントをサポートすることができる。

【0085】

ＩＤＣＳ機能ビュー
図６Ａは、一実施形態におけるＩＤＣＳの機能ビューのブロック図の一例６００ｂである。ブロック図６００ｂにおいて、ＩＤＣＳ機能スタックは、サービスと、共有ライブラリと、データストアとを含む。サービスは、ＩＤＣＳプラットフォームサービス６４０ｂと、ＩＤＣＳプレミアムサービス６５０ｂと、ＩＤＣＳインフラストラクチャサービス６６２ｂとを含む。一実施形態において、ＩＤＣＳプラットフォームサービス６４０ｂおよびＩＤＣＳプレミアムサービス６５０ｂは、別々にデプロイされたＪａｖａベースのランタイムサービスであり、ＩＤＣＳのビジネスを実現する。ＩＤＣＳインフラストラクチャサービス６６２ｂは、別々にデプロイされたランタイムサービスであり、ＩＤＣＳに対するインフラストラクチャサポートを提供する。共有ライブラリは、ＩＤＣＳサービスによって使用される共有ライブラリとしてパッケージングされた共通コードであるＩＤＣＳインフラストラクチャライブラリ６８０ｂと、共有ライブラリとを含む。データストアは、ＩＤＣＳが必要とする／生成するデータリポジトリであり、アイデンティティストア６９８ｂ、グローバル構成７００ｂ、メッセージストア７０２ｂ、グローバルテナント７０４ｂ、パーソナライゼーション設定７０６ｂ、リソース７０８ｂ、ユーザ一時データ７１０ｂ、システム一時データ７１２ｂ、テナントごとのスキーマ（管理されたＥｘａＤａｔａ）７１４ｂ、オペレーショナルストア（図示せず）、キャッシングストア（図示せず）などを含む。

【0086】

一実施形態において、ＩＤＣＳプラットフォームサービス６４０ｂは、たとえばＯｐｅｎＩＤ Ｃｏｎｎｅｃｔサービス６４２ｂ、ＯＡｕｔｈ２サービス６４４ｂ、ＳＡＭＬ２サービス６４６ｂ、およびＳＣＩＭ＋＋サービス６４８ｂを含む。一実施形態において、ＩＤＣＳプレミアムサービスは、たとえば、クラウドＳＳＯおよびガバナンス６５２ｂ、
企業ガバナンス６５４ｂ、ＡｕｔｈＮブローカー６５６ｂ、連携ブローカー６５８ｂ、およびプライベートアカウント管理６６０ｂを含む。

【0087】

ＩＤＣＳインフラストラクチャサービス６６２ｂおよびＩＤＣＳインフラストラクチャライブラリ６８０ｂは、ＩＤＣＳプラットフォームサービス６４０ｂがその仕事を実行するのに必要とする機能のサポートを提供する。一実施形態において、ＩＤＣＳインフラストラクチャサービス６６２ｂは、ジョブスケジューラ６６４ｂ、ＵＩ６６６ｂ、ＳＳＯ６６８ｂ、レポート６７０ｂ、キャッシュ６７２ｂ、ストレージ６７４ｂ、サービスマネージャ６７６ｂ（パブリッククラウド制御）、およびイベントプロセッサ６７８ｂ（ユーザ通知、アプリケーション申込、監査、データ解析）を含む。一実施形態において、ＩＤＣＳインフラストラクチャライブラリ６８０ｂは、データマネージャＡＰＩ６８２ｂ、イベントＡＰＩ６８４ｂ、ストレージＡＰＩ６８６ｂ、認証ＡＰＩ６８８ｂ、認可ＡＰＩ６９０ｂ、クッキーＡＰＩ６９２ｂ、キーＡＰＩ６９４ｂ、およびクレデンシャルＡＰＩ６９６ｂを含む。一実施形態において、クラウド計算サービス６０２ｂ（内部Nimbula）は、
ＩＤＣＳインフラストラクチャサービス６６２ｂおよびＩＤＣＳインフラストラクチャライブラリ６８０ｂの機能をサポートする。

【0088】

一実施形態において、ＩＤＣＳは、顧客エンドユーザＵＩ６０４ｂ、顧客管理ＵＩ６０６ｂ、ＤｅｖＯｐｓ管理ＵＩ６０８ｂ、およびログインＵＩ６１０ｂなど、ＩＤＣＳサービスのコンシューマのためのさまざまなＵＩ６０２ｂを提供する。一実施形態において、ＩＤＣＳは、アプリケーション（たとえば顧客アプリケーション６１４ｂ、パートナーアプリケーション６１６ｂ、およびクラウドアプリケーション６１８ｂ）の統合６１２ｂならびにファームウェア統合６２０ｂを可能にする。一実施形態において、さまざまな環境がＩＤＣＳと統合されてそのアクセス制御のニーズをサポートしてもよい。このような統合は、たとえば、アイデンティティブリッジ６２２ｂ（ＡＤ統合、ＷＮＡ、およびＳＣＩＭコネクタを提供）、アパッチエージェント６２４ｂ、またはＭＳＦＴエージェント６２６ｂによって提供される。

【0089】

一実施形態において、内部および外部のＩＤＣＳコンシューマは、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ６３０ｂ、ＯＡｕｔｈ２ ６３２ｂ、ＳＡＭＬ２ ６３４ｂ、ＳＣＩＭ６３６ｂ、およびＲＥＳＴ／ＨＴＴＰ６３８ｂなどの標準ベースのプロトコル６２８ｂに対するＩＤＣＳのアイデンティティサービスと統合される。これにより、ドメインネームシステム（domain name system）（「ＤＮＳ」）を用いて、要求をどこにルーティングするかを判断することができ、アプリケーションの消費を、アイデンティティサービスの内部実現を理解することから切離す。

【0090】

図６ＡのＩＤＣＳ機能ビューはさらに、ＩＤＣＳが、ユーザ通知（クラウド通知サービス７１８ｂ）、ファイルストレージ（クラウドストレージサービス７１６ｂ）、およびＤｅｖＯＰｓのためのメトリクス／警告（クラウドモニタサービス（ＥＭ）７２２ｂおよびクラウドメトリクスサービス（グラファイト）７２０ｂ）のために依存する共通機能を提供する、パブリッククラウドインフラストラクチャサービスを含む。

【0091】

クラウドゲート
一実施形態において、ＩＤＣＳはウェブ層において「クラウドゲート」を実現する。クラウドゲートは、ウェブアプリケーションがユーザＳＳＯをアイデンティティ管理システム（たとえばＩＤＣＳ）に外部化することを可能にするウェブサーバプラグインであり、これは、企業ＩＤＭスタックと協力するＷｅｂＧａｔｅまたはＷｅｂＡｇｅｎｔ技術と同様である。クラウドゲートは、ＩＤＣＳ ＡＰＩに対するアクセスを安全にするセキュリティゲートキーパの役割を果たす。一実施形態において、クラウドゲートは、ＯＡｕｔｈに基づいてＨＴＴＰリソースを保護するためにウェブポリシー施行点（Policy Enforceme
nt Point）（「ＰＥＰ」）を提供するウェブ／プロキシサーバプラグインによって実現される。

【0092】

図７は、クラウドゲート７０２を実現する実施形態のブロック図７００である。クラウドゲート７０２は、ウェブサーバ７１２内で実行され、ポリシー施行点（「ＰＥＰ」）の役割を果たす。ポリシー施行点は、オープン標準（たとえばＯＡｕｔｈ２、ＯｐｅｎＩＤ
Ｃｏｎｎｅｃｔなど）を用いるＩＤＣＳポリシー決定点（Policy Decision Point）（
「ＰＤＰ」）と統合され、一方でウェブブラウザおよびアプリケーションのＲＥＳＴ ＡＰＩリソース７１４へのアクセスを安全にするように構成されている。いくつかの実施形態において、ＰＤＰは、ＯＡｕｔｈおよび／またはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔマイクロサービス７０４で実現される。たとえば、ユーザブラウザ７０６がユーザ７１０のログインを求める要求をＩＤＣＳに送信すると、対応するＩＤＣＳ ＰＤＰは、クレデンシャルを検証した後に、このクレデンシャルが十分であるか否か（たとえば第２のパスワードなどのその他のクレデンシャルを要求するか否か）を判断する。図７の実施形態において、クラウドゲート７０２は、ローカルポリシーを有するので、ＰＥＰとしてもＰＤＰとしてもその役割を果たし得る。

【0093】

ワンタイム・デプロイメントの一部として、クラウドゲート７０２には、ＯＡｕｔｈ２クライアントとしてのＩＤＣＳが登録され、これが、ＩＤＣＳに対してＯＩＤＣおよびＯＡｕｔｈ２オペレーションを要求することを可能にする。その後、これは、要求マッチングルール（ＵＲＬをたとえばワイルドカード、通常表現などに対して如何にしてマッチングするか）の適用を受ける、アプリケーションの保護されたリソースおよび保護されていないリソースに関する構成情報を保持する。クラウドゲート７０２をデプロイすることにより、異なるセキュリティポリシーを有する異なるアプリケーションを保護することができ、保護されるアプリケーションはマルチテナントであってもよい。

【0094】

ブラウザベースのユーザアクセス中、クラウドゲート７０２は、ユーザ認証フローを開始するＯＩＤＣ ＲＰ７１８として機能する。ユーザ７１０が有効なローカルユーザセッションを有していない場合、クラウドゲート７０２は、ユーザをＳＳＯマイクロサービスにリダイレクトし、ＳＳＯマイクロサービスとともにＯＩＤＣ「認証コード」フローに参加する。このフローは、アイデンティティトークンとしてのＪＷＴの配信で終了する。クラウドゲート７０８は、ＪＷＴを検証し（たとえば署名、満了、宛先／オーディエンスなどに注目し）、ユーザ７１０に関するローカルセッションクッキーを発行する。これは、保護されているリソースへのウェブブラウザのアクセスを安全にしかつローカルセッションクッキーを発行、更新、および検証するセッションマネージャ７１６として機能する。これはまた、そのローカルセッションクッキーの削除のためのログアウトＵＲＬを提供する。

【0095】

クラウドゲート７０２はまた、ＨＴＴＰベーシックＡｕｔｈ認証者の役割を果たし、ＩＤＣＳに対するＨＴＴＰベーシックＡｕｔｈクレデンシャルを検証する。この行動は、セッションレスおよびセッションベースの（ローカルセッションクッキー）モードでサポートされる。この場合、サーバ側ＩＤＣＳセッションは生成されない。

【0096】

ＲＥＳＴ ＡＰＩクライアント７０８によるプログラムアクセス中、クラウドゲート７０２は、アプリケーションの保護されているＲＥＳＴ ＡＰＩ７１４のためのＯＡｕｔｈ２リソースサーバ／フィラー７２０の役割を果たし得る。これは、認証ヘッダおよびアクセストークンに対して要求が存在するか否かを検査する。クライアント７０８（たとえばモバイル、ウェブアプリケーション、ＪａｖａＳｃｒｉｐｔなど）が（ＩＤＣＳによって発行された）アクセストークンを、保護されているＲＥＳＴ ＡＰＩ７１４とともに使用するために示すと、クラウドゲート７０２は、ＡＰＩへのアクセスを許可する前にアクセ
ストークンを検証する（たとえば署名、満了、オーディエンスなど）。元のアクセストークンは修正なしで送られる。

【0097】

一般的に、ＯＡｕｔｈを用いてクライアントアイデンティティ伝播トークン（たとえばクライアントが誰であるかを示す）またはユーザアイデンティティ伝播トークン（たとえばユーザが誰であるかを示す）を生成する。本実施形態において、クラウドゲートにおけるＯＡｕｔｈの実現は、たとえばＩＥＴＦ、ＲＦＣ７５１９によって提供されるようなウェブトークンのフォーマットを定めるＪＷＴに基づく。

【0098】

ユーザがログインすると、ＪＷＴが発行される。ＪＷＴは、ＩＤＣＳによって署名され、ＩＤＣＳにおけるマルチテナント機能をサポートする。クラウドゲートは、ＩＤＣＳが発行したＪＷＴを検証することにより、ＩＤＣＳにおけるマルチテナント機能を可能にする。したがって、ＩＤＣＳは、物理構造においても、セキュリティモデルを支持する論理ビジネスプロセスにおいてもマルチテナンシーを提供する。

【0099】

テナンシーの種類
ＩＤＣＳは３種類のテナンシーとして、顧客テナンシー、クライアントテナンシー、およびユーザテナンシーを特定する。顧客またはリソーステナンシーは、ＩＤＣＳの顧客が誰であるか（すなわち作業が誰に対して実行されているか）を特定する。クライアントテナンシーは、どのクライアントアプリケーションがデータにアクセスしようとしているか（すなわちどのアプリケーションが作業を実行しているか）を特定する。ユーザテナンシーは、どのユーザがアプリケーションを用いてデータにアクセスしているか（すなわち誰によって作業が実行されているか）を特定する。たとえば、専門サービス企業が大型ディスカウントショップを対象とするシステム統合機能を提供しこの大型ディスカウントショップのシステムのアイデンティティ管理を提供するためにＩＤＣＳを使用するとき、ユーザテナンシーは、この専門サービス企業に相当し、クライアントテナンシーはシステム統合機能を提供するために使用されるアプリケーションに相当し、顧客テナンシーは大型ディスカウントショップである。

【0100】

これら３つのテナンシーを分離および統合することによってクラウドベースのサービスにおけるマルチテナント機能が可能になる。一般的に、オンプレミスの物理的なマシンにインストールされているオンプレミスソフトウェアの場合、これら３つのテナンシーを特定する必要はない。なぜなら、ユーザはログインするのに物理的にマシン上にいなければならないからである。しかしながら、クラウドベースのサービス構造の場合、実施形態は、トークンを持いて、誰がどのアプリケーションを使用してどのリソースにアクセスするかを判断する。３つのテナンシーは、トークンによってコーディファイ（codify）され、クラウドゲートによって施行され、中間層のビジネスサービスによって使用される。一実施形態において、ＯＡｕｔｈサーバがトークンを生成する。さまざまな実施形態において、このトークンは、ＯＡｕｔｈ以外のセキュリティプロトコルとともに使用されてもよい。

【0101】

ユーザ、クライアント、およびリソーステナンシーを分離することにより、ＩＤＣＳが提供するサービスのユーザには実質的なビジネス上の利点が与えられる。たとえば、そうすることにより、ビジネス（たとえば健康ビジネス）のニーズおよびそのアイデンティティ管理の問題を理解するサービスプロバイダは、ＩＤＣＳが提供するサービスを購入し、ＩＤＣＳのサービスを消費する自身のバックエンドアプリケーションを開発し、このバックエンドアプリケーションをターゲットビジネスに提供することができる。したがって、サービスプロバイダは、ＩＤＣＳのサービスを拡張してその所望の機能を提供するとともにそれらを特定のターゲットビジネスに対して差出すことができる。サービスプロバイダは、ソフトウェアを構築し実行してアイデンティサービスを提供する必要はないが、その
代わりに、ＩＤＣＳのサービスを拡張しカスタマイズしてターゲットビジネスのニーズに合うようにすることができる。

【0102】

周知のシステムの中には、顧客テナンシーである単一のテナンシーしか説明しないものがある。しかしながら、そのようなシステムは、顧客ユーザ、顧客のパートナー、顧客のクライアント、クライアント自身、または、アクセスが顧客から委任されたクライアントなどのユーザの組み合わせによるアクセスを処理するときには不十分である。本実施形態において複数のテナンシーを規定し施行することにより、これらの多様なユーザに対して管理機能を特定することが容易になる。

【0103】

一実施形態において、ＩＤＣＳの１エンティティは、複数のテナントに同時に属しているのではなく、１つのテナントのみに属し、「テナンシー」はアーティファクトが存在する場所である。一般的に、特定の機能を実現するコンポーネントは複数存在し、これらのコンポーネントは複数のテナントに属することが可能であるまたはインフラストラクチャに属することが可能である。インフラストラクチャは、テナントの代わりに機能する必要があるとき、テナントの代わりにエンティティサービスと対話する。この場合、インフラストラクチャそのものは自身のテナンシーを有し、顧客は自身のテナンシーを有する。要求がサブミットされたとき、この要求に関わる複数のテナンシーが存在する。

【0104】

たとえば、「テナント１」に属するクライアントが、「テナント３」におけるユーザを指定する「テナント２」のためのトークンを取得することを求める要求を実行する場合がある。別の例として、「テナント１」に存在するユーザが、「テナント２」が所有するアプリケーションにおけるアクションを実行する必要がある場合がある。よって、ユーザは、「テナント２」のリソースネームスペースに行きそのためのトークンを要求する必要がある。したがって、権限の委任は、「誰が」「何を」「誰」に対して行うことができるかを特定することによって実現される。もう１つの例として、第１の組織（「テナント１」）のために働く第１のユーザが、第２の組織（「テナント２」）のために働く第２のユーザが第３の組織（「テナント３」）がホストする文書にアクセスすることを、許可してもよい。

【0105】

一例において、「テナント１」のクライアントは、「テナント３」のアプリケーションにアクセスするために「テナント２」のユーザのためのアクセストークンを要求してもよい。クライアントは、「http://tenant3/oauth/token」に行きこのトークンを求めるＯＡｕｔｈ要求を呼び出すことによって当該トークンを要求してもよい。クライアントは、「クライアントアサーション」を要求に含めることにより、自身が「テナント１」に在住するクライアントであることを明らかにする。このクライアントアサーションは、クライアントＩＤ（たとえば「クライアント１」）とクライアントテナンシー（「テナント１」）とを含む。「テナント１」の「クライアント１」として、クライアントは、「テナント３」に対するトークンを求める要求を呼び出す権利を有し、「テナント２」のユーザのためのトークンを所望する。したがって、「ユーザアサーション」も同じＨＴＴＰ要求の一部として送られる。生成されるアクセストークンは、アプリケーションテナンシー（「テナント３」）であるターゲットテナンシーのコンテキストにおいて発行され、ユーザテナンシー（「テナント２」）を含む。

【0106】

一実施形態において、データ層における各テナントは、独立したストライプとして実現される。データ管理の観点からすると、アーティファクトはテナントに存在する。サービスの観点からすると、サービスは、異種のテナントとどのようにして協力するかを知っており、複数のテナンシーは、サービスのビジネス機能における異なるディメンションである。図８は、ある実施形態において複数のテナンシーを実現するシステムの一例８００を示す。システム８００はクライアント８０２を含み、クライアント８０２は、如何にして
データベース８０６のデータ用いて作業するかを理解しているマイクロサービス８０４が提供するサービスを要求する。このデータベースは複数のテナント８０８を含み、各テナントは対応するテナンシーのアーティファクトを含む。一実施形態において、マイクロサービス８０４は、トークンを得ようとしてhttps://tenant3/oauth/tokenを通して要求さ
れるＯＡｕｔｈマイクロサービスである。ＯＡｕｔｈマイクロサービスの機能が、マイクロサービス８０４において、データベース８０６からのデータを用いて実行されることにより、クライアント８０２の要求が正当であるか否かが検証され、正当である場合は、異なるテナンシー８０８からのデータが使用されてトークンが構成される。したがって、システム８００は、各テナンシーに与えられるサービスをサポートするだけでなく各種テナントに代わって機能し得るサービスをサポートすることによりクロステナント環境において作業できるという点において、マルチテナントである。

【0107】

システム８００は好都合である。理由は次の通りである。マイクロサービス８０４はデータベース８０６のデータから物理的に切離されており、クライアントにより近い場所を通ってデータを複製することにより、マイクロサービス８０４をクライアントに対するローカルサービスとして提供することができ、システム８００はサービスのアベイラビリティを管理しそれをグローバルに提供することができる。

【0108】

一実施形態において、マイクロサービス８０４はステートレスである。これは、マイクロサービス８０４を走らせるマシンが、特定のテナントに対するサービスを示すマーカを保持していないことを意味する。その代わりに、テナンシーは、たとえば、入ってくる要求のＵＲＬのホスト部分にマーキングされてもよい。このテナンシーはデータベース８０６のテナント８０８のうちの１つを示す。多数のテナント（たとえば何百万ものテナント）をサポートする場合、マイクロサービス８０４は、データベース８０６への同数の接続を有することはできない。マイクロサービス８０４はその代わりに、データベースユーザというコンテキストにおいてデータベース８０６への実際の物理接続を提供する接続プール８１０を使用する。

【0109】

一般的に、接続は、基礎をなすドライバまたはプロバイダに接続ストリングを提供することによって構築される。接続ストリングは、特定のデータベースまたはサーバをアドレス指定するために、かつ、インスタンスおよびユーザ認証クレデンシャルを与えるために使用される（たとえば「Server=sql_box;Database=Common;User ID=uid;Pwd=password;」）。接続は、一旦構築されると、開閉が可能であり、プロパティ（たとえばコマンドタイムアウト長さ、または存在するのであればトランザクション）を設定することができる。接続ストリングは、データプロバイダのデータアクセスインターフェイスによって指示されるキーと値とのペアのセットを含む。接続プールは、データベースに対する未来の要求が必要なときに接続を再使用できるように保持されるデータベース接続のキャッシュである。接続プーリングにおいて、接続は、作成後にプールに置かれ、新たな接続を確立しなくてもよいように、再使用される。たとえば、マイクロサービス８０４とデータベース８０８との間に１０の接続が必要な場合、接続プール８１０には、すべてデータベースユーザというコンテキストにおいて（たとえば特定のデータベースユーザに関連して、たとえば、誰がこの接続の所有者か、誰のクレデンシャルが検証中なのか、それはデータベースユーザか、それはシステムクレデンシャルかなどに関連して）開いている１０の接続があるであろう。

【0110】

接続プール８１０内の接続は、何にでもアクセスできるシステムユーザのために作成される。したがって、テナントに代わって要求を処理するマイクロサービス８０４による監査および特権を正しく扱うために、データベース動作は、特定のテナントに割り当てられたスキーマ所有者に関連する「プロキシユーザ」８１２というコンテキストで実行される。このスキーマ所有者は、このスキーマ作成の目的であったテナンシーにのみアクセスで
き、このテナンシーの値はこのスキーマ所有者の値である。データベース８０６内のデータを求める要求がなされると、マイクロサービス８０４は、接続プール８１０内の接続を用いてこのデータを提供する。したがって、マルチテナンシーは、リソーステナンシーに対応付けられたデータストアプロキシユーザというコンテキストにおいて（たとえばそれに関連して）作成されたデータ接続のトップにある要求ごとに構築された特定テナント向けデータストアバインディングというコンテキストにおいて（たとえばそれに関連して）入ってくる要求を処理するステートレスでエラスティックな中間層サービスを持つことによって得られ、データベースは、サービスとは無関係にスケーリングできる。

【0111】

以下は、プロキシユーザ８１２を実現するための機能の例を提供する。

【0112】

【数1】

【0113】

この機能において、マイクロサービス８０４は、接続プール８１０内のデータベース接続を使用する一方で、接続プール８１０から引出された接続に対する「プロキシユーザ（Proxy User）」設定を、「テナント（Tenant）」にセットし、テナントというコンテキストにおいてデータオペレーションを実行する。

【0114】

すべてのテーブルをストライピングすることにより同じデータベースにおいて異なるテナント用に異なるコラムを構成するとき、１つのテーブルは、混合されたすべてのテナントのデータを含み得る。これに対し、一実施形態は、テナント駆動のデータ層を提供する。本実施形態は、異なるテナント用に同一データベースをストライピングするのではなく、テナントごとに異なる物理データベースを提供する。たとえば、マルチテナンシーは、プラガブルデータベース（たとえばオラクル社のOracle Database 12c）を用いて実現さ
れてもよく、この場合、各テナントには別々のパーティションが割り当てられる。データ層では、リソースマネージャが要求を処理し、その後、その要求のデータソースを求める（メタデータとは別）。本実施形態は、要求ごとに各データソース／ストアへのランタイムスイッチを実行する。各テナントのデータをその他のテナントから分離することにより、本実施形態は改善されたデータセキュリティを提供する。

【0115】

一実施形態において、互いに異なるトークンは、異なるテナンシーをコーディファイする。ＵＲＬトークンは、サービスを要求するアプリケーションのテナンシーを特定し得る。アイデンティティトークンは、認証すべきユーザのアイデンティティをコーディファイし得る。アクセストークンは複数のテナンシーを特定し得る。たとえば、アクセストークンは、このようなアクセスのターゲットであるテナンシー（たとえばアプリケーションテナンシー）と、アクセス権が付与されたユーザのユーザテナンシーとをコーディファイし得る。クライアントアサーショントークンは、クライアントＩＤおよびクライアントテナンシーを特定し得る。ユーザアサーショントークンは、ユーザおよびユーザテナンシーを特定し得る。

【0116】

一実施形態において、アイデンティティトークンは、少なくとも、ユーザテナント名（すなわちユーザが在住している場所）を示す「クレーム／ステートメント」を含む。認証トークンに関連する「クレーム」（セキュリティ分野の当業者が使用）は、ある主体が自身または別の主体に関して作成するステートメントである。ステートメントは、たとえば名称、アイデンティティ、キー、グループ、権限、または能力に関するものであってもよ
い。クレームは、プロバイダによって発行され、１つ以上の値が与えられた後に、セキュリティトークンサービス（security token service）（「ＳＴＳ」）として一般的に知られている発行者が発行したセキュリティトークンにパッケージングされる。

【0117】

一実施形態において、アクセストークンは、少なくとも、アクセストークンを求める要求がなされた時点のリソーステナント名（たとえば顧客）を示すクレーム／ステートメントと、ユーザテナント名を示すクレームと、要求しているＯＡｕｔｈクライアントの名称を示すクレームと、クライアントテナント名を示すクレームとを含む。一実施形態において、アクセストークンは、以下のＪＳＯＮ機能に従って実現されてもよい。

【0118】

【数2】

【0119】

一実施形態において、クライアントアサーショントークンは、少なくとも、クライアントテナント名を示すクレームと、要求しているＯＡｕｔｈクライアントの名称を示すクレームとを含む。

【0120】

本明細書に記載のトークンおよび／または複数のテナンシーは、ＩＤＣＳ以外の任意のマルチテナントクラウドベースサービスによって実現されてもよい。たとえば、本明細書に記載のトークンおよび／または複数のテナンシーは、ＳａａＳまたは企業リソースプランニング（Enterprise Resource Planning）（「ＥＲＰ」）サービスにおいて実現されてもよい。

【0121】

図９は、一実施形態におけるＩＤＣＳのネットワークビュー９００のブロック図である。図９は、一実施形態においてアプリケーション「ゾーン」９０４間で行われるネットワーク対話を示す。アプリケーションは、要求される保護レベルと、その他さまざまなシステムへの接続の実現に基づいてゾーンに分割される（たとえばＳＳＬゾーン、ｎｏ ＳＳＬゾーンなど）。アプリケーションゾーンのうち、いくつかはＩＤＣＳ内部からのアクセスを要するサービスを提供するアプリケーションゾーンであり、いくつかはＩＤＣＳ外部からのアクセスを要するサービスを提供するアプリケーションゾーンであり、いくつかはオープンアクセスである。したがって、各保護レベルは各ゾーンに対して強化される。

【0122】

図９の実施形態において、サービス間の通信は、ＨＴＴＰ要求を用いて行われる。一実施形態において、ＩＤＣＳは、本明細書に記載のアクセストークンを用いて、サービスを提供するだけでなく、ＩＤＣＳへのアクセスおよびＩＤＣＳ自身の内部におけるアクセスを安全なものにする。一実施形態において、ＩＤＣＳマイクロサービスは、ＲＥＳＴｆｕｌインターフェイスを通してエクスポーズされ、本明細書に記載のトークンによって安全なものにされる。

【0123】

図９の実施形態において、さまざまなアプリケーション／サービス９０２のうちのいずれか１つが、ＩＤＣＳ ＡＰＩに対してＨＴＴＰコールすることにより、ＩＤＣＳサービスを使用してもよい。一実施形態において、アプリケーション／サービス９０２のＨＴＴＰ要求は、オラクルパブリッククラウドロードバランシング外部仮想ＩＰアドレス（「ＶＩＰ」）９０６（またはその他同様の技術）、パブリッククラウドウェブルーティング層９０８、およびＩＤＣＳロードバランシング内部ＶＩＰアプライアンス９１０（またはその他同様の技術）を通って、ＩＤＣＳウェブルーティング層９１２により受信されてもよい。ＩＤＣＳウェブルーティング層９１２は、ＩＤＣＳの外部または内部からの要求を受信し、ＩＤＣＳプラットフォームサービス層９１４またはＩＤＣＳインフラストラクチャサービス層９１６を通してルーティングする。ＩＤＣＳプラットフォームサービス層９１４は、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、ＯＡｕｔｈ、ＳＡＭＬ，ＳＣＩＭなどのＩＤＣＳの外部から呼び出されたＩＤＣＳマイクロサービスを含む。ＩＤＣＳインフラストラクチャサービス層９１６は、その他のＩＤＣＳマイクロサービスの機能をサポートするためにＩＤＣＳの内部から呼び出されたサポートマイクロサービスを含む。ＩＤＣＳインフラストラクチャマイクロサービスの例は、ＵＩ、ＳＳＯ、レポート、キャッシュ、ジョブスケジューラ、サービスマネージャ、キーを作るための機能などである。ＩＤＣＳキャッシュ層９２６は、ＩＤＣＳプラットフォームサービス層９１４およびＩＤＣＳインフラストラクチャサービス層９１６のためのキャッシング機能をサポートする。

【0124】

ＩＤＣＳへの外部アクセスおよびＩＤＣＳ内部アクセス双方のセキュリティを強化することにより、ＩＤＣＳの顧客に、それが実行するアプリケーションのための傑出したセキュリティコンプライアンスを与えることができる。

【0125】

図９の実施形態において、構造化照会言語（Structured Query Language）（「ＳＱＬ
」）に基づいて通信するデータ層９１８およびＬＤＡＰに基づいて通信するＩＤストア層９２０以外については、ＯＡｕｔｈプロトコルを使用することにより、ＩＤＣＳ内のＩＤＣＳコンポーネント（たとえばマイクロサービス）間の通信を保護し、ＩＤＣＳ外部からのアクセスを安全なものにするために使用される同じトークンをＩＤＣＳ内のセキュリティのためにも使用する。すなわち、ウェブルーティング層９１２は、要求がＩＤＣＳの外部から受けたものであろうとＩＤＣＳの内部から受けたものであろうと、受信した要求を処理するための同じトークンおよびプロトコルを使用する。したがって、ＩＤＣＳは、システム全体を保護するために１つの一貫したセキュリティモデルを提供することにより、傑出したセキュリティコンプライアンスを可能にする。なぜなら、システム内に実現されるセキュリティモデルが少ないほど、システムの安全性は高くなるからである。

【0126】

ＩＤＣＳクラウド環境において、アプリケーションは、ネットワークコールを行うことによって通信する。ネットワークコールは、ＨＴＴＰ、伝送制御プロトコル（Transmission Control Protocol）（「ＴＣＰ」）、ユーザデータグラムプロトコル（User Datagram
Protocol）（「ＵＤＰ」）などの適用可能なネットワークプロトコルに基づいていれば
よい。たとえば、アプリケーション「Ｘ」は、アプリケーション「Ｙ」と、ＨＴＴＰに基づいて、アプリケーション「Ｙ」をＨＴＴＰユニフォーム・リソース・ロケータ（Uniform Resource Locator）（「ＵＲＬ」）としてエクスポーズすることにより、通信し得る。一実施形態において、「Ｙ」は、各々がある機能に対応する多数のリソースをエクスポーズするＩＤＣＳマイクロサービスである。「Ｘ」（たとえば別のＩＤＣＳマイクロサービス）は、「Ｙ」をコールする必要があるとき、「Ｙ」と、呼び出す必要があるリソース／機能とを含むＵＲＬを構成し（たとえばhttps:/host/Y/resource）、ウェブルーティング層９１２を通って「Ｙ」に導かれる対応するＲＥＳＴコールを行う。

【0127】

一実施形態において、ＩＤＣＳ外部の呼出元は、「Ｙ」がどこにあるかを知る必要がな
い場合があるが、ウェブルーティング層９１２はアプリケーション「Ｙ」がどこで走っているかを知る必要がある。一実施形態において、ＩＤＣＳは、発見機能を実現する（ＯＡｕｔｈサービスによって実現される）ことにより、各アプリケーションがどこで走っているかを判断し、スタティックなルーティング情報の可用性が必要ではなくなるようにする。

【0128】

一実施形態において、企業マネージャ（enterprise manager）（「ＥＭ」）９２２は、オンプレミスおよびクラウドベース管理をＩＤＣＳに拡張する「一枚のガラス」を提供する。一実施形態において、Chef Software社の構成管理ツールである「シェフ（Chef）」
サーバ９２４は、さまざまなＩＤＣＳ層のための構成管理機能を提供する。一実施形態において、サービスデプロイメントインフラストラクチャおよび／または永続格納モジュール９２８は、テナントライフサイクル管理動作、パブリッククラウドライフサイクル管理動作、またはその他の動作のために、ＯＡｕｔｈ２ ＨＴＴＰメッセージをＩＤＣＳウェブルーティング層９１２に送信してもよい。一実施形態において、ＩＤＣＳインフラストラクチャサービス層９１６は、ＩＤ／パスワードＨＴＴＰメッセージを、パブリッククラウド通知サービス９３０またはパブリッククラウドストレージサービス９３２に送信してもよい。

【0129】

クラウドアクセス制御‐ＳＳＯ
一実施形態は、クラウドスケールＳＳＯサービスを実現するために軽量クラウド標準をサポートする。軽量クラウド標準の例としては、ＨＴＴＰ、ＲＥＳＴ、および、ブラウザを通してアクセスを提供する標準（ウェブブラウザは軽量であるため）が挙げられる。逆に、ＳＯＡＰは、クライアントを構築するためにより多くの管理、構成、およびツールを必要とする重いクラウド標準の一例である。本実施形態は、アプリケーションのためにＯｐｅｎＩＤ Ｃｏｎｎｅｃｔセマンティックスを使用することにより、ＩＤＣＳに対してユーザ認証を要求する。本実施形態は、軽量ＨＴＴＰクッキーベースのユーザセッション追跡を用いて、ステートフルなサーバ側セッションサポートなしで、ＩＤＣＳにおけるユーザのアクティブなセッションを追跡する。本実施形態は、使用するアプリケーションに対して、認証されたアイデンティティを自身のローカルセッションに戻すマッピングを行うときに、ＪＷＴベースのアイデンティティトークンを使用する。本実施形態は、連携されているアイデンティティ管理システムとの統合をサポートし、ＩＤＣＳに対してユーザ認証を要求するために企業デプロイメントのＳＡＭＬ ＩＤＰサポートをエクスポーズする。

【0130】

図１０は、一実施形態におけるＩＤＣＳ内のＳＳＯ機能のシステムアーキテクチャビューのブロック図１０００である。本実施形態は、クライアントアプリケーションが標準ベースのウェブプロトコルを推進してユーザ認証フローを開始することを可能にする。クラウドシステムとＳＳＯの統合を要求するアプリケーションは、企業データセンターにあってもよく、遠隔パートナーデータセンターにあってもよく、またはオンプレミスの顧客によって操作されてもよい。一実施形態において、異なるＩＤＣＳプラットフォームサービスが、接続されているネイティブなアプリケーション（すなわちＩＤＣＳと統合するためにＯｐｅｎＩＤ Ｃｏｎｎｅｃｔを利用するアプリケーション）からのログイン／ログアウト要求を処理するためのＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、接続されているアプリケーションからのブラウザベースのログイン／ログアウト要求を処理するためのＳＡＭＬ ＩＤＰサービス、外部ＳＡＭＬ ＩＤＰに対してユーザ認証を調整するためのＳＡＭＬ ＳＰサービス、および、ローカルなまたは連携されたログインフローを含みＩＤＣＳホストセッションクッキーを管理するためのエンドユーザログインセレモニーを調整するための内部ＩＤＣＳ ＳＳＯサービスなどの、ＳＳＯのビジネスを実現する。一般的に、ＨＴＴＰは、フォームありでまたはフォームなしで機能する。フォームありで機能するとき、このフォームはブラウザ内で見えるフォームである。フォームなしで機能するとき、これはク
ライアントからサーバへの通信として機能する。ＯｐｅｎＩＤ ＣｏｎｎｅｃｔもＳＡＭＬも、フォームをレンダリングする能力を必要とするが、これは、ブラウザの存在によって実現される、または、ブラウザが存在しているかのように機能するアプリケーションによって仮想的に実行される。一実施形態において、ユーザ認証／ＳＳＯをＩＤＣＳを通して実現するアプリケーションクライアントは、ＩＤＣＳにおいて、ＯＡｕｔｈ２クライアントとして登録される必要があり、クライアント識別子およびクレデンシャル（たとえばＩＤ／パスワード、ＩＤ／証明書など）を取得する必要がある。

【0131】

図１０の実施形態の例は、２つのプラットフォームマイクロサービスとしてのＯＡｕｔｈ２ １００４およびＳＡＭＬ２ １００６と、１つのインフラストラクチャマイクロサービスとしてのＳＳＯ１００８とを含む、ログイン機能をまとめて提供する３つのコンポーネント／マイクロサービスを含む。図１０の実施形態において、ＩＤＣＳは「アイデンティティメタシステム」を提供する。このメタシステムにおいて、ＳＳＯサービス１００８は、異なる種類のアプリケーションに対して提供される。これらのアプリケーションは、３者間ＯＡｕｔｈフローを必要としＯｐｅｎＩＤ Ｃｏｎｎｅｃｔリレーパーティ（relaying party）（「ＲＰ」、そのユーザ認証機能をＩＤＰにアウトソーシングするアプリケーション）として機能するブラウザベースのウェブまたはネイティブアプリケーション１０１０、２者間ＯＡｕｔｈフローを必要としＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ ＲＰとして機能するネイティブアプリケーション１０１１、およびＳＡＭＬ ＳＰとして機能するウェブアプリケーション１０１２などである。

【0132】

一般的に、アイデンティティメタシステムは、デジタルアイデンティティのための相互運用可能なアーキテクチャであり、複数の基礎となる技術、実装、およびプロバイダの集合体を用いることを可能にする。ＬＤＡＰ、ＳＡＭＬ、およびＯＡｕｔｈは、アイデンティティ機能を提供する異なるセキュリティ標準の例であり、アプリケーションを構築するための基礎となることが可能であり、アイデンティティメタシステムは、このようなアプリケーションに対して統一されたセキュリティシステムを提供するように構成されてもよい。ＬＤＡＰセキュリティモデルは、アイデンティティを扱うための特定のメカニズムを指定し、システムを通るすべてのパスは厳密に保護されねばならない。ＳＡＭＬは、一組のアプリケーションが、異なるセキュリティドメインの異なる組織に属する別の一組のアプリケーションとの間で安全に情報を交換できるようにするために開発されたものである。これら２つのアプリケーションの間に信頼はないので、ＳＡＭＬは、一方のアプリケーションが、同じ組織に属していない別のアプリケーションを認証できるように開発された。ＯＡｕｔｈは、ウェブベースの認証を実行するための軽量プロトコルであるＯｐｅｎＩＤ Ｃｏｎｎｅｃｔを提供する。

【0133】

図１０の実施形態において、ＯｐｅｎＩＤアプリケーション１０１０がＩＤＣＳ内のＯｐｅｎＩＤサーバに接続すると、その「チャネル」はＳＳＯサービスを要求する。同様に、ＳＡＭＬアプリケーション１０１２がＩＤＣＳ内のＳＡＭＬサーバに接続すると、その「チャネル」もＳＳＯサービスを要求する。ＩＤＣＳにおいて、各マイクロサービス（たとえばＯｐｅｎＩＤマイクロサービス１００４およびＳＡＭＬマイクロサービス１００６）はアプリケーション各々を処理し、これらのマイクロサービスはＳＳＯマイクロサービス１００８からのＳＳＯ機能を要求する。プロトコルごとにマイクロサービスを追加してからＳＳＯ機能のためにＳＳＯマイクロサービス１００８を用いることにより、このアーキテクチャを拡張して任意の数のその他のセキュリティプロトコルをサポートすることができる。ＳＳＯマイクロサービス１００８は、セッションを発行し（すなわちＳＳＯクッキー１０１４が提供される）、このアーキテクチャにおいてセッションを発行する権限を有する唯一のシステムである。ＩＤＣＳセッションは、ブラウザ１００２がＳＳＯクッキー１０１４を使用することによって実現される。ブラウザ１００２はまた、ローカルセッションクッキー１０１６を用いてそのローカルセッションを管理する。

【0134】

一実施形態において、たとえば、ブラウザ内で、ユーザは、ＳＡＭＬに基づいて第１のアプリケーションを使用してログインし、その後、ＯＡｕｔｈなどの異なるプロトコルを用いて構築された第２のアプリケーションを使用してもよい。ユーザには、同じブラウザ内の第２のアプリケーション上のＳＳＯが与えられる。したがって、ブラウザは、ステートまたはユーザエージェントであり、クッキーを管理する。

【0135】

一実施形態において、ＳＳＯマイクロサービス１００８は、ログインセレモニー１０１８、ＩＤ／パスワードリカバリ１０２０、第１回ログインフロー１０２２、認証マネージャ１０２４、ＨＴＴＰクッキーマネージャ１０２６、およびイベントマネージャ１０２８を提供する。ログインセレモニー１０１８は、顧客設定および／またはアプリケーションコンテキストに基づいてＳＳＯ機能を実現し、ローカルフォーム（たとえばベーシックＡｕｔｈ）、外部ＳＡＭＬ ＩＤＰ、外部ＯＩＤＣ ＩＤＰなどに従って構成されてもよい。ＩＤ／パスワードリカバリ１０２０は、ユーザのＩＤおよび／またはパスワードの回復のために使用される。第１回ログインフロー１０２２は、ユーザが１回目にログインしたときに実現される（すなわちＳＳＯセッションはまだ存在しない）。認証マネージャ１０２４は、認証に成功すると認証トークンを発行する。ＨＴＴＰクッキーマネージャ１０２６は認証トークンをＳＳＯクッキーに保存する。イベントマネージャ１０２８はＳＳＯ機能に関連するイベントをパブリッシュする。

【0136】

一実施形態において、ＯＡｕｔｈマイクロサービス１００４とＳＳＯマイクロサービス１００８との間の対話は、ブラウザリダイレクトに基づいており、ＳＳＯマイクロサービス１００８は、ＨＴＭＬフォームを用いてユーザに問いかけ、クレデンシャルを検証し、セッションクッキーを発行する。

【0137】

一実施形態において、たとえば、ＯＡｕｔｈマイクロサービス１００４は、ブラウザ１００２から認証要求を受け、３者間ＯＡｕｔｈフローに従ってアプリケーションのユーザを認証する。よって、ＯＡｕｔｈマイクロサービス１００４は、ＯＩＤＣプロバイダ１０３０として機能し、ブラウザ１００２をＳＳＯマイクロサービス１００８にリダイレクトし、アプリケーションコンテキストに沿って進む。ユーザが有効なＳＳＯセッションを有するか否かに応じて、ＳＳＯマイクロサービス１００８は、既存のセッションを検証するかまたはログインセレモニーを実行する。認証または検証に成功すると、ＳＳＯマイクロサービス１００８は、認証コンテキストをＯＡｕｔｈマイクロサービス１００４に返す。そうすると、ＯＡｕｔｈマイクロサービス１００４はブラウザ１００２を認証（「ＡＺ」コードを有するコールバックＵＲＬにリダイレクトする。ブラウザ１００２は、ＡＺコードをＯＡｕｔｈマイクロサービス１００４に送信し、必要なトークン１０３２を要求する。また、ブラウザ１００２は、ＨＴＴＰ認証ヘッダにおいてそのクライアントクレデンシャル（ＩＤＣＳをＯＡｕｔｈ２クライアントとして登録したときに取得）を含む。これに対し、ＯＡｕｔｈマイクロサービス１００４は、要求されたトークン１０３２をブラウザ１００２に与える。一実施形態において、ブラウザ１００２に与えられるトークン１０３２は、ＪＷアイデンティティと、ＩＤＣＳ ＯＡｕｔｈ２サーバによって署名されたアクセストークンとを含む。この機能のさらなる詳細は、以下で図１１を参照しながら開示される。

【0138】

一実施形態において、たとえば、ＯＡｕｔｈマイクロサービス１００４は、ネイティブアプリケーション１０１１から認可要求を受け、２者間ＯＡｕｔｈフローに従ってユーザを認証する。この場合、ＯＡｕｔｈマイクロサービス１００４の認証マネージャ１０３４は対応する認証を（たとえばクライアント１０１１から受けたＩＤ／パスワードに基づいて）実行し、トークンマネージャ１０３６は、認証に成功すると、対応するアクセストークンを発行する。

【0139】

一実施形態において、たとえば、ＳＡＭＬマイクロサービス１００６は、ブラウザからＳＳＯ ＰＯＳＴ要求を受け、ＳＡＭＬ ＳＰとして機能するウェブアプリケーション１０１２のユーザを認証する。ＳＡＭＬマイクロサービス１００６は次に、ＳＡＭＬ ＩＤＰ１０３８として機能し、ブラウザ１００２をＳＳＯマイクロサービス１００８にリダイレクトし、アプリケーションコンテキストに沿って進む。ユーザが有効なＳＳＯセッションを有しているか否かに応じて、ＳＳＯマイクロサービス１００８は、既存のセッションを検証するか、またはログインセレモニーを実行する。認証または検証に成功すると、ＳＳＯマイクロサービス１００８は、認証コンテキストをＳＡＭＬマイクロサービス１００６に返す。そうすると、ＳＡＭＬマイクロサービスは、必要なトークンでＳＰにリダイレクトする。

【0140】

一実施形態において、たとえば、ＳＡＭＬマイクロサービス１００６は、ＳＡＭＬ ＳＰ１０４０として機能してもよく、遠隔ＳＡＭＬ ＩＤＰ１０４２（たとえばアクティブディレクトリ連携サービス（active directory federation service）（「ＡＤＦＳ」）
に進んでもよい。一実施形態は、標準ＳＡＭＬ／ＡＤフローを実現する。一実施形態において、ＳＡＭＬマイクロサービス１００６とＳＳＯマイクロサービス１００８との間の対話は、ブラウザのリダイレクトに基づいており、ＳＳＯマイクロサービス１００８は、ＨＴＭＬフォームを用いてユーザに問いかけ、クレデンシャルを検証し、セッションクッキーを発行する。

【0141】

一実施形態において、ＩＤＣＳ内部のコンポーネント（たとえば１００４、１００６、１００８）と、ＩＤＣＳ外部のコンポーネント（たとえば１００２、１０１１、１０４２）との間の対話は、ファイアウォール１０４４を通して行われる。

【0142】

ログイン／ログアウトフロー
図１１は、一実施形態における、ＩＤＣＳによって提供されるＳＳＯ機能のメッセージシーケンスフロー１１００である。ユーザがブラウザ１１０２を用いてクライアント１１０６（たとえばブラウザベースのアプリケーションまたはモバイル／ネイティブアプリケーション）にアクセスするとき、クラウドゲート１１０４は、アプリケーション施行点として機能し、ローカルポリシーテキストファイルに規定されているポリシーを施行する。クラウドゲート１１０４は、ユーザがローカルアプリケーションセッションを有していないことを検出した場合、ユーザの認証を要求する。そうするために、クラウドゲート１１０４は、ブラウザ１１０２をＯＡｕｔｈ２マイクロサービス１１１０にリダイレクトすることにより、ＯＡｕｔｈ２マイクロサービス１１１０に対するＯｐｅｎＩＤ Ｃｏｎｎｅｃｔログインフローを開始する（３者間ＡＺ Ｇｒａｎｔフローであり、範囲＝「openid
profile」）。

【0143】

ブラウザ１１０２の要求は、ＩＤＣＳルーティング層ウェブサービス１１０８およびクラウドゲート１１０４を横断してＯＡｕｔｈ２マイクロサービス１１１０に到達する。ＯＡｕｔｈ２マイクロサービス１１１０は、アプリケーションコンテキスト（すなわちアプリケーションを記述するメタデータ、たとえば接続するアプリケーションのアイデンティティ、クライアントＩＤ、構成、アプリケーションは何ができるかなど）を構成し、ブラウザ１１０２をログインのためにＳＳＯマイクロサービス１１１２にリダイレクトする。

【0144】

ユーザが有効なＳＳＯセッションを有する場合、ＳＳＯマイクロサービス１１１２は、ログインセレモニーを開始することなく既存のセッションを検証する。ユーザが有効なＳＳＯセッションを有していない場合（すなわちセッションクッキーが存在しない）、ＳＳＯマイクロサービス１１１２は、顧客のログインプリファレンスに従ってユーザログインセレモニーを開始する（たとえば商標付ログインページを表示する）。そうするために、
ＳＳＯマイクロサービス１１１２は、ブラウザ１１０２を、ＪａｖａＳｃｒｉｐｔで実現されるログインアプリケーションサービス１１１４にリダイレクトする。ログインアプリケーションサービス１１１４はブラウザ１１０２にログインページを提供する。ブラウザ１１０２はログインクレデンシャルを含むＲＥＳＴ ＰＯＳＴをＳＳＯマイクロサービス１１１２に送信する。ＳＳＯマイクロサービス１１１２は、アクセストークンを生成し、ＲＥＳＴ ＰＯＳＴのクラウドゲート１１０４に送信する。クラウドゲート１１０４は、認証情報を管理ＳＣＩＭマイクロサービス１１１６に送信することによりユーザのパスワードを検証する。管理ＳＣＩＭマイクロサービス１１１６は、認証が成功したと判断し、対応するメッセージをＳＳＯマイクロサービス１１１２に送信する。

【0145】

一実施形態において、ログインセレモニー中、ログインページは同意ページを表示しない。「ログイン」オペレーションはさらなる同意を要しないからである。代わりに、アプリケーションに対してエクスポーズされている特定のプロファイル属性についてユーザに知らせるプライバシーポリシーが、ログインページ上に記載される。ログインセレモニー中、ＳＳＯマイクロサービス１１１２は顧客のＩＤＰプリファレンスを尊重し、構成され次第、構成されたＩＤＰに対する認証のためにＩＤＰにリダイレクトする。

【0146】

認証または検証が成功すると、ＳＳＯマイクロサービス１１１２は、ブラウザ１１０２を、ユーザの認証トークンを含む、新たに作成／更新されたＳＳＯホストＨＴＴＰクッキー（たとえば「ＨＯＳＴＵＲＬ」が示すホストのコンテキストで作成されたクッキー）を用いて、ＯＡｕｔｈ２マイクロサービス１１１０に戻るようにブラウザ１１０２をリダイレクトする。ＯＡｕｔｈ２マイクロサービス１１１０は、ＡＺコード（たとえばＯＡｕｔｈコンセプト）をブラウザ１１０２に戻しクラウドゲート１１０４にリダイレクトする。ブラウザ１１０２はＡＺコードをクラウドゲート１１０４に送信し、クラウドゲート１１０４はＲＥＳＴ ＰＯＳＴをＯＡｕｔｈ２マイクロサービス１１１０に送信してアクセストークンおよびアイデンティティトークンを要求する。これらのトークンはどちらも、ＯＡｕｔｈマイクロサービス１１１０にスコーピングされる（オーディエンストークンクレームによって示される）。クラウドゲート１１０４はこれらのトークンをＯＡｕｔｈ２マイクロサービス１１１０から受ける。

【0147】

クラウドゲート１１０４は、アイデンティティトークンを用いて、認証されたユーザのアイデンティティをその内部アカウント表現にマッピングし、これは、このマッピングを自身のＨＴＴＰクッキーに保存してもよい。クラウドゲート１１０４は次に、ブラウザ１１０２をクライアント１１０６にリダイレクトする。すると、ブラウザ１１０２は、クライアント１１０６に到達し、対応するレスポンスをクライアント１１０６から受ける。この時点以降、ブラウザ１１０２は、アプリケーションのローカルクッキーが有効である限り、アプリケーション（すなわちクライアント１１０６）にシームレスにアクセスすることができる。ローカルクッキーが無効になると、認証プロセスは繰返される。

【0148】

クラウドゲート１１０４はさらに、要求に含められたアクセストークンを用いて、「userinfo」をＯＡｕｔｈ２マイクロサービス１１１０からまたはＳＣＩＭマイクロサービスから取得する。このアクセストークンは、「プロファイル」スコープによって与えられる属性の「userinfo」リソースにアクセスするには十分である。これは、ＳＣＩＭマイクロサービスを介して「／ｍｅ」リソースにアクセスするのにも十分である。一実施形態において、デフォルトで、含まれているアクセストークンは、「プロファイル」スコープの下で与えられるユーザプロファイル属性に対してのみ十分である。他のプロファイル属性へのアクセスは、クラウドゲート１１０４によって発行されたＡＺグラントログイン要求において提示された追加の（任意の）スコープに基づいて認可される。

【0149】

ユーザがＯＡｕｔｈ２が統合された別のアプリケーションにアクセスする場合、同じプ
ロセスが繰返される。

【0150】

一実施形態において、ＳＳＯ統合アーキテクチャは、ブラウザベースのユーザログアウトに対し、同様のＯｐｅｎＩＤ Ｃｏｎｎｅｃｔユーザ認証フローを使用する。一実施形態において、既存のアプリケーションセッションを有するユーザは、クラウドゲート１１０４にアクセスしてログアウトを開始する。その代わりに、ユーザは、ＩＤＣＳ側でログアウトを開始している場合がある。クラウドゲート１１０４は、特定用途向けのユーザセッションを終了し、ＯＡｕｔｈ２マイクロサービス１１１０に対しＯＡｕｔｈ２ ＯｐｅｎＩＤ プロバイダ（「ＯＰ」）ログアウト要求を開始する。ＯＡｕｔｈ２マイクロサービス１１１０は、ユーザのホストＳＳＯクッキーを削除するＳＳＯマイクロサービス１１１２にリダイレクトする。ＳＳＯマイクロサービス１１１２は、ユーザのＳＳＯクッキーにおいて追跡された既知のログアウトエンドポイントに対し一組のリダイレクト（ＯＡｕｔｈ２ ＯＰおよびＳＡＭＬ ＩＤＰ）を開始する。

【0151】

一実施形態において、クラウドゲート１１０４がＳＡＭＬプロトコルを用いてユーザ認証（たとえばログイン）を要求する場合、同様のプロセスが、ＳＡＭＬマイクロサービスとＳＳＯマイクロサービス１１１２との間で開始される。

【0152】

クラウドキャッシュ
一実施形態は、クラウドキャッシュと呼ばれるサービス／機能を提供する。クラウドキャッシュは、ＩＤＣＳに与えられて、ＬＤＡＰベースのアプリケーション（たとえば電子メールサーバ、カレンダーサーバー、何らかのビジネスアプリケーションなど）との通信をサポートする。なぜなら、ＩＤＣＳはＬＤＡＰに従って通信するのではないが、このようなアプリケーションはＬＤＡＰに基づいてのみ通信するように構成されているからである。典型的には、クラウドディレクトリは、ＲＥＳＴ ＡＰＩを介してエクスポーズされ、ＬＤＡＰプロトコルに従って通信するのではない。一般的に、企業ファイアウォオールを通してＬＤＡＰ接続を管理するには、セットアップおよび管理が難しい特殊な構成が必要である。

【0153】

ＬＤＡＰベースのアプリケーションをサポートするために、クラウドキャッシュは、ＬＤＡＰ通信を、クラウドシステムとの通信に適したプロトコルに変換する。一般的に、ＬＤＡＰベースのアプリケーションは、ＬＤＡＰを介してデータベースを使用する。代わりに、アプリケーションは、ＳＱＬのような異なるプロトコルを介してデータベースを使用するように構成されてもよい。しかしながら、ＬＤＡＰはツリー構造のリソースの階層表現を提供するのに対し、ＳＱＬはデータをテーブルとフィールドとして表現する。したがって、ＬＤＡＰは検索機能用であることがより望ましいであろう。一方、ＳＱＬはトランザクション機能用であることがより望ましいであろう。

【0154】

一実施形態において、ＩＤＣＳが提供するサービスを、ＬＤＡＰベースのアプリケーションで使用して、たとえば、アプリケーションのユーザを認証する（すなわちアイデンティティサービス）、またはアプリケーションのセキュリティポリシーを施行する（すなわちセキュリティサービス）ことができる。一実施形態において、ＩＤＣＳとのインターフェイスは、ファイアウォールを通り、ＨＴＴＰ（たとえばＲＥＳＴ）に基づく。典型的に、企業ファイアウォールは、内部ＬＤＡＰ通信へのアクセスを、当該通信がセキュア・ソケット・レイヤ（Secure Sockets Layer）（「ＳＳＬ」）を実現する場合であっても許可しない。また、企業ファイアウォールは、ＴＣＰポートがファイアウォールを通してエクスポーズされることを許可しない。しかしながら、クラウドキャッシュは、ＬＤＡＰとＨＴＴＰとの間の変換を行って、ＬＤＡＰベースのアプリケーションが、ＩＤＣＳが提供するサービスに到達できるようにし、ファイアウォールはＨＴＴＰに対してオープンである。

【0155】

一般的に、ＬＤＡＰディレクトリは、マーケティングおよび開発などのビジネスライン（line of business）で使用されてもよく、ユーザ、グループ、業務などを規定する。一例において、マーケティングおよび開発ビジネスは、多様な顧客を対象としている場合があり、顧客ごとに、独自のアプリケーション、ユーザ、グループ、業務などを有し得る。ＬＤＡＰキャッシュディレクトリを実行し得るビジネスラインの別の例は、無線サービスプロバイダである。この場合、無線サービスプロバイダのユーザが行う各コールは、ＬＤＡＰディレクトリに対してユーザのデバイスを認証し、ＬＤＡＰディレクトリ内の対応する情報の一部は課金システムと同期させてもよい。これらの例において、ＬＤＡＰは、実行時に探索されるコンテンツを物理的に分離するための機能を提供する。

【0156】

一例において、無線サービスプロバイダは、短期マーケティングキャンペーンを支援するＩＤＣＳが提供するサービスを使用する一方で、自身のアイデンティティ管理サービスをそのコアビジネス（たとえば通常のコール）のために扱ってもよい。この場合、クラウドキャッシュは、ＬＤＡＰを、クラウドに対して実行する一組のユーザおよび一組のグループを有する場合は「平坦にする」。一実施形態において、ＩＤＣＳにおいて実現されるクラウドキャッシュの数はいくつであってもよい。

【0157】

分散型データグリッド
一実施形態において、ＩＤＣＳにおけるキャッシュクラスタは、たとえばその開示を本明細書に引用により援用する米国特許公開第２０１６／００９２５４０号に開示されている分散型データグリッドに基づいて実現される。分散型データグリッドは、分散環境またはクラスタ環境内で１つ以上のクラスタにおいてコンピュータサーバの集合体が、一緒に作業することにより情報を管理し計算などの関連動作を管理するシステムである。分散型データグリッドを用いることで、サーバ間で共有されるアプリケーションオブジェクトおよびデータを管理することができる。分散型データグリッドは、短いレスポンスタイム、高いスループット、予測可能なスケーラビリティ、継続的なアベイラビリティ、および情報の信頼性を提供する。具体的な例として、たとえばオラクル社のOracle Coherenceのデータグリッドのような分散型データグリッドは、情報をインメモリに格納することによりさらに高いパフォーマンスを達成し、複数のサーバにわたって同期が取られた情報のコピーを保持するにあたって冗長性を用いることにより、サーバ故障イベント時におけるシステムの回復力とデータの継続的なアベイラビリティとを保証する。

【0158】

一実施形態において、ＩＤＣＳは、Coherenceなどの分散型データグリッドを実現して
、すべてのマイクロサービスがブロックされることなく共有キャッシュオブジェクトへのアクセスを要求できるようにする。Coherenceは、従来のリレーショナルデータベース管
理システムと比較して、より高い信頼性、スケーラビリティ、およびパフォーマンスが得られるように設計された、所有権を主張できるＪａｖａベースのインメモリデータグリッドである。Coherenceは、ピアトゥピア（すなわち中央マネージャがない）インメモリ分
散型キャッシュを提供する。

【0159】

図１２は、データを格納しデータアクセス権をクライアント１２５０に与え本発明の実施形態を実現する分散型データグリッド１２００の一例を示す。「データグリッドクラスタ」または「分散型データグリッド」は、分散環境またはクラスタ環境内で１つ以上のクラスタ（たとえば１２００ａ、１２００ｂ、１２００ｃ）において一緒に作業することにより情報を格納し関連する計算などの動作を管理する複数のコンピュータサーバ（たとえば１２２０ａ、１２２０ｂ、１２２０ｃ、および１２２０ｄ）を含むシステムである。分散型データグリッド１２００は、クラスタ１２００ａにおいて５つのデータノード１２３０ａ、１２３０ｂ、１２３０ｃ、１２３０ｄ、および１２３０ｅとともに４つのサーバ１２２０ａ、１２２０ｂ、１２２０ｃ、１２２０ｄを含むものとして示されているが、分散
型データグリッド１２００は、任意の数のクラスタおよび各クラスタにおける任意の数のサーバおよび／またはノードを含み得る。ある実施形態において、分散型データグリッド１２００は本発明を実現する。

【0160】

図１２に示されるように、分散型データグリッドは、一緒に作業する多数のサーバ（たとえば１２２０ａ、１２２０ｂ、１２２０ｃ、および１２２０ｄ）にデータを分散させることによってデータ格納および管理機能を提供する。データグリッドクラスタの各サーバは、たとえば、１つから２つのプロセッサソケットと１プロセッサソケット当たり２つから４つのＣＰＵコアとを有する「コモディティ（commodity）ｘ８６」サーバハードウェ
アプラットフォームのような、従来のコンピュータシステムであってもよい。各サーバ（たとえば１２２０ａ、１２２０ｂ、１２２０ｃ、および１２２０ｄ）は、１つ以上のＣＰＵと、ネットワークインターフェイスカード（Network Interface Card）（「ＮＩＣ」）と、たとえば最小で４ＧＢのＲＡＭ最大で６４ＧＢ以上のＲＡＭを含むメモリとで構成されている。サーバ１２２０ａは、ＣＰＵ１２２２ａと、メモリ１２２４ａと、ＮＩＣ１２２６ａとを有するものとして示されている（これらの要素は他のサーバ１２２０ｂ、１２２０ｃ、１２２０ｄ上にもあるが図示されていない）。任意で、各サーバにフラッシュメモリ（たとえばＳＳＤ １２２８ａ）を設けることで過剰な記憶容量を提供してもよい。提供時、ＳＳＤ容量は、好ましくはＲＡＭのサイズの１０倍である。データグリッドクラスタ１２００ａのサーバ（たとえば１２２０ａ、１２２０ｂ、１２２０ｃ、１２２０ｄ）は、高帯域幅のＮＩＣ（たとえばＰＣＩ－ＸまたはＰＣＩｅ）を用いて高性能ネットワークスイッチ１２２０（たとえばギガビット以上のイーサネット（登録商標））に接続されている。

【0161】

クラスタ１２００ａは、故障中にデータが失われる可能性を避けるために最小で４つの物理サーバを含むことが好ましいが、典型的な設備はより多くのサーバを有する。各クラスタに存在するサーバが多いほど、フェイルオーバーおよびフェイルバックの効率は高く、サーバの故障がクラスタに与える影響は小さくなる。サーバ間の通信時間を最短にするために、各データグリッドクラスタは、サーバ間の単一ホップ通信を提供する単一のスイッチ１２０２に限定されることが理想的である。このように、クラスタは、スイッチ１２０２上のポートの数によって制限される。したがって、典型的なクラスタは４～９６の物理サーバを含む。

【0162】

分散型データグリッド１２００のほとんどの広域ネットワーク（Wide Area Network）
（「ＷＡＮ」）構成において、ＷＡＮ内の各データセンターは、独立しているが相互に接続されているデータグリッドクラスタ（たとえば１２００ａ、１２００ｂ、および１２００ｃ）を有する。ＷＡＮは、たとえば図１２に示されるクラスタよりも多くのクラスタを含み得る。加えて、相互接続されているが独立しているクラスタ（たとえば１２００ａ、１２００ｂ、１２００ｃ）を用いることにより、および／または相互接続されているが独立しているクラスタを、互いに離れているデータセンター内に配置することにより、分散型データグリッドは、自然災害、火災、洪水、長期停電などによって生じる、１つのクラスタのすべてのサーバの同時損失を防止すべく、クライアント１２５０に対するデータおよびサービスを保証することができる。

【0163】

１つ以上のノード（たとえば１２３０ａ、１２３０ｂ、１２３０ｃ、１２３０ｄおよび１２３０ｅ）は、クラスタ１２００ａの各サーバ（たとえば１２２０ａ、１２２０ｂ、１２２０ｃ、１２２０ｄ）上で動作する。分散型データグリッドにおいて、ノードは、たとえばソフトウェアアプリケーション、仮想マシンなどであってもよく、サーバは、ノードがその上で動作するオペレーティングシステム、ハイパーバイザなど（図示せず）を含み得る。Oracle Coherenceのデータグリッドでは、各ノードはＪａｖａ仮想マシン（Java virtual machine）（「ＪＶＭ」）である。ＣＰＵの処理能力およびサーバ上で利用できる
メモリに応じて、各サーバ上に多数のＪＶＭ／ノードを設けてもよい。ＪＶＭ／ノードは、分散型データグリッドの要求に応じて、追加、起動、停止、および削除されてもよい。Oracle Coherenceを実行するＪＶＭは、起動時に自動的に参加しクラスタ化する。クラスタに加わるＪＶＭ／ノードは、クラスタメンバまたはクラスタノードと呼ばれる。

【0164】

各クライアントまたはサーバは、情報伝達のためにバスまたはその他の通信機構を含み、情報処理のためにバスに結合されたプロセッサを含む。プロセッサは、どのタイプの汎用または専用プロセッサであってもよい。各クライアントまたはサーバはさらに、プロセッサによって実行される命令および情報を格納するためのメモリを含み得る。メモリは、ランダムアクセスメモリ（「ＲＡＭ」）、読出専用メモリ（「ＲＯＭ」）、磁気もしくは光ディスクなどのスタティックストレージ、またはその他任意の種類のコンピュータ読取可能媒体を組み合わせたもので構成することができる。各クライアントまたはサーバはさらに、ネットワークへのアクセス提供のためにネットワークインターフェイスカードなどの通信デバイスを含み得る。したがって、ユーザは、各クライアントまたはサーバに対して、直接、またはネットワークを通して遠隔から、またはその他任意の手段で、インターフェイスすることができる。

【0165】

コンピュータ読取可能な媒体は、プロセッサからアクセスすることが可能な利用可能な媒体であればどのようなものでもよく、揮発性媒体および不揮発性媒体、リムーバブルおよび非リムーバブル媒体、ならびに通信媒体を含む。通信媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、または、たとえば搬送波もしくはその他の搬送機構などの変調されたデータ信号内のその他のデータを含んでいてもよく、任意の情報伝達媒体を含む。

【0166】

プロセッサはさらに、液晶ディスプレイ（「ＬＣＤ」）などのディスプレイにバスを介して結合されてもよい。キーボード、およびコンピュータマウスなどのカーソル制御デバイスが、さらにバスに結合されることにより、ユーザが各クライアントまたはサーバに対してインターフェイスできるようにしてもよい。

【0167】

一実施形態において、メモリは、プロセッサが実行すると機能を提供するソフトウェアモジュールを格納する。モジュールは、各クライアントまたはサーバにオペレーティングシステム機能を提供するオペレーティングシステムを含む。モジュールはさらに、クラウドアイデンティティ管理機能を提供するためのクラウドアイデンティティ管理モジュールと、本明細書に開示されているその他すべての機能とを含み得る。

【0168】

クライアントは、クラウドサービスなどのウェブサービスにアクセスし得る。一実施形態において、ウェブサービスは、オラクル社のWebLogicサーバ上で実現されてもよい。他の実施形態ではウェブサービスの他の実装形態を使用してもよい。ウェブサービスは、クラウドデータを格納しているデータベースにアクセスする。

【0169】

レプリケーション競合の検出および解決
一般的に、オラクルパブリッククラウド（Oracle Public Cloud）（「ＯＰＣ」）のよ
うなパブリッククラウドは、仮想マシン（virtual machine）（「ＶＭ」）、アプリケー
ション、またはストレージ等のリソースを一般大衆がインターネットを通じて利用できるようにすることにより、世界中の顧客にＩａａＳ、ＰａａＳおよびＳａａＳサービスを提供しこれらをサポートすることを意図している。パブリッククラウドは、異なる地理的地域にそれぞれが存在する複数のデータセンターを有することにより、各データセンターの最も近くに位置する顧客に対してサービスを最小の遅延で提供するものとして知られている。実施形態において、パブリッククラウドサービスは、「地域」と呼ぶ物理的境界によって分離されている顧客をカバーする異なるデータセンターにデプロイされてもよい。

【0170】

図１３は、一実施形態に係る、各々が「地域」を形成するデプロイされた複数のデータセンター（「ＤＣ」で示される）を有するパブリッククラウド１３００を示す。たとえば、データセンター１３０１はカナダの一都市に位置し、データセンター１３０２はドイツの一都市に位置し、データセンター１３０３はオーストラリアの一都市に位置する。実施形態において、１つ以上のデータセンターが、１つ以上の「コントロールプレーン」デプロイメント（「ＣＰ」で示される）が管理する１つの「アイランド」に統合される。アイランドは、１つの「クラウド」に統合された地域の集まりであり、１つのコントロールプレーンによって管理される。たとえば、コントロールプレーン１３１０はデータセンター１３０１、１３０４、１３０５、１３０６および１３０７を管理し、コントロールプレーン１３１１はデータセンター１３０８および１３０９を管理する。スケーラビリティ要求とそれぞれの地域における顧客負荷とに基づいて、典型的なコントロールプレーンデプロイメントは１つ以上の地域に対応することができる。一実施形態において、あるコントロールプレーンコンポーネントが２つ以上の地域に対応するという状況において、このコンポーネントは１つのアイデンティティですべての地域とやり取りする権限を必要とする。

【0171】

顧客アカウントは、各種パブリッククラウドサービスを購入／取得する各ユーザ／顧客ごとに、クラウド１３００によって管理される。顧客が利用できる一種のサービスとして、上で開示したマルチテナントアイデンティティ管理サービス、またはＩＤＣＳを挙げることができ、このサービスを、コントロールプレーンコンポーネントとして実現しすべての地域（すなわちすべてのデータセンター）において別々にデプロイすることにより、その地域のリソースを保護することができる。上述のように、一実施形態において、特定の地域でデプロイされていないコントロールプレーンは、これがデプロイされていない地域のコンポーネントまたはテナントとやり取りするためには固有の権限を必要とする。たとえば、ある地域に指定されたコントロールプレーンコンポーネントが、別の地域に位置する（すなわち異なるＩＤＣＳデプロイメントでホストされている）ＩＤＣＳ顧客テナンシーにアクセスすることを所望する場合がある。そのためには、一方の地域のＩＤＣＳに割り当てられたコンポーネント／顧客が他方の地域のＩＤＣＳに対してＩＤＣＳ ＡＰＩを呼び出す（たとえば図６のＩＤＣＳマイクロサービス６１４のうちの特定のマイクロサービスにアクセスする）ことができるように、これらのデプロイメント間で信頼が確立されている必要がある。周知の解決策では、ある地域に指定されこの地域に割り当てられたユーザは、この地域のリソースのみにアクセスでき、その他の地域のリソースにはアクセスできず、この地域のみから認証を受けることができ、その他の地域から認証を受けることはできない。

【0172】

これに対し、実施形態の場合、ある地域の「グローバルアクセストークン」または「トークン」と呼ばれる新規のアクセストークンを有するユーザは、このトークンを用いて別の地域（すなわち遠隔地域）のリソースにアクセスすることができる。実施形態は、ユーザ／顧客がどこにいようとリソースおよび認証機能を提供すべくさまざまなＩＤＣＳ地域を管理するために、如何にして地域間で信頼を確立するかに向けらている。一般的に、地域間信頼機能を可能にするためにはグローバルアクセストークンをユーザに与える必要がある。そうすると、このトークンは宛先セキュリティセンターによって消費される。

【0173】

たとえば、「クライアント」（すなわちユーザまたはサービスにアクセスするための任意のアプリケーションもしくはプログラム的アプローチ）が、シカゴのデータセンター１３０７（シカゴはこのデータセンターが最初に構築された場所）のみに存在する場合がある。各クライアントは、自身のアイデンティティを有しており、それを検証してトークンを取得する必要がある。クライアントが、たとえばシドニーに位置するデータセンター１３０３等の、クラウド１３００の他のデータセンター（すなわち他のデータセンターのＩＤＣＳデプロイメント）のうちのいずれにも存在していないまたはフットプリントを有し
ていないと仮定する。そのため、クライアントは、シドニーの近くに物理的に位置していても、シドニーには存在していないので、シドニーのデータセンターから認証を受けることはできない。この問題を解決するために、実施形態は、グローバルアクセストークンを生成することにより、必要な地域間の信頼を提供する。よって、クライアントは、シカゴでの認証後に、シドニーにおけるグローバルアクセストークンの回復を要求することになる。シカゴＤＣ１３０７は、トークンを生成しグローバル秘密鍵を用いてトークンに署名する。グローバル秘密鍵はすべてのＤＣで入手できる。実施形態において、グローバルアクセストークンを使用してＩＤＣＳ ＲＥＳＴ ＡＰＩのみにアクセスし、そのため、このトークンを用いて複数地域にまたがる非ＩＤＣＳ ＲＥＳＴ ＡＰＩにアクセスするとエラーが生じるであろう。

【0174】

シドニーＤＣ１３０３のＩＤＣＳデプロイメントは、トークンが提示されると、このトークンを消費し検証する。そうすると、クライアントは、シドニーでは指定されていないものの、シドニーのリソースにアクセスできる。実施形態の場合、クライアントは、１つのＩＤＣＳデプロイメントで指定されるだけでよいが、それでもなお他のデプロイメントのリソースにアクセスできる。

【0175】

しかしながら、クライアントが別の地域のリソースにアクセスすること以上を所望する場合がある。たとえば、周知のシステムにおいて、クライアントがアイデンティティクラウドアカウントまたはＩＤＣＳデプロイメントをある地域（たとえばシカゴまたは「マスター」データセンター）で作成することを所望する場合、顧客はそのアカウントを作成する。しかしながら、同じ顧客がそのアイデンティティを別の地域（たとえばアムステルダム）で用いてその地域の作業負荷を使用することを所望する場合、この顧客は先ずアムステルダムで新たなアイデンティティクラウドアカウントを作成しなければならないが、そうすると、同じ顧客に対して別々の２つのアイデンティティアカウントが作成されることになる。そうでなければ、顧客は第１の地域とは通信を続けることができるものの、顧客がアムステルダムにいてシカゴの作業負荷の使用を強いられた場合は大きな遅延が生じることになる。

【0176】

これに対し、本発明の実施形態は、シカゴ（すなわち「マスター」データセンター）における顧客のアイデンティティクラウドアカウントを、アムステルダム（すなわち「レプリカ」データセンター）またはその他任意の地域に自動的にレプリケートする。一実施形態において、顧客／テナントは、シカゴの既存のアカウントをアムステルダムから使用するという選択肢が与えられ、その場合、情報がアムステルダムにブートストラップされ、その後は変更が絶えず取り込まれてレプリケートされる。

【0177】

しかしながら、複数の地域にまたがるレプリケーションまたはブートストラップはいくつかの問題を引き起こす。たとえば、変更ログはマスターで作成されてレプリカに送信される。図１４は、本発明の実施形態に係る、マスターＩＤＣＳデプロイメント１４０１（「ＩＤＣＳ１」）とレプリカＩＤＣＳデプロイメント１４０２（「ＩＤＣＳ２」）との間におけるレプリケーション変更イベント／ログの処理フローを示す。一実施形態において、図１４（ならびに以下の図１５および図１７）のフロー図の機能は、メモリまたはその他のコンピュータ読取可能なもしくは有形の媒体に格納されたソフトウェアによって実現され、プロセッサによって実行される。その他の実施形態において、この機能は、ハードウェアによって（たとえば特定用途向け集積回路（「ＡＳＩＣ］）、プログラマブルゲートアレイ（「ＰＧＡ」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）などの使用を通して）、または、ハードウェアとソフトウェアの任意の組み合わせによって実現されてもよい。

【0178】

マスター１４０１は、管理サービス１４０５（すなわち図１１の管理ＳＣＩＭマイクロ
サービス１１１６のような管理ＳＣＩＭマイクロサービス）と、レプリケーションサービス１４０８（実施形態ではマイクロサービスとしても実現される）とを含む。同様に、レプリカ１４０２も、管理ＳＣＩＭマイクロサービス（図示せず）と、レプリケーションサービス１４０７とを含む。データストア１４０６および１４１２は、リソースのうちのいくつかとその他の関連データとを格納する。一実施形態において、各リソースはＩＤＣＳ
ＲＥＳＴ ＡＰＩリソースである。

【0179】

実施形態において、各ＩＤＣＳデプロイメント１４０１、１４０２はそれぞれ１つ以上のシャードキュー（sharded queue）１４３０、１４３１を含む。シャードキューは、シ
ステムパーティショニングによって複数の独立した物理キューにトランスペアレントに分割される１つの論理キューである。一実施形態において、シャードキューはＪａｖａメッセージングサービス（Java Messaging Service）（「ＪＭＳ」）シャードキューである。

【0180】

１４２０で、レプリケート可能なリソースのうちの１つに対するＳＣＩＭ書込要求が、マスター１４０１の管理サービス１４０５に届く。

【0181】

１４２１で、管理サービス１４０５は、この要求を処理しデータストア１４０６にリソースを書き込む。一実施形態において、リソースを「書き込む」ことは、ＳＱＬステートメントを使用しＪａｖａデータベース接続（Java Database Connection）（「ＪＤＢＣ」）を介してリソースをデータベースに「パーシストする（persist）」ことを含む。

【0182】

１４２２で、管理サービス１４０５は、（データストア１４０６にリソースを書き込んだ結果として）変更イベントを生成し、複数のシャードキュー１４３０のうちの１つに書き込む。一実施形態において、テナントに関する変更イベントは常に、計算されたハッシュに基づいて同じシャードにエンキュー（enqueue）される。

【0183】

１４２３で、各シャードキュー１４３０におけるレプリケーション変更イベントが、レプリケーションサービス１４０８の専用トランスポートハンドラ１４３５により、キュー１４３０にエンキューされたときと同じ順序でデキュー（dequeue）される。

【0184】

１４５１で、トランスポートハンドラ１４３５は、バルクメッセージの形態の変更イベントを、ＲＥＳＴ ＡＰＩコールを介してレプリカ１４０２のレプリケーションサービス１４０７にプッシュする。一実施形態において、メッセージは、ＲＦＣ７６４４に準拠する標準ＳＣＩＭ「バルク動作」に記載されているヘッダが追加された変更イベントを含むＪＳＯＮフォーマットである。

【0185】

１４５２で、レプリケーションサービス１４０７は、ローカルシャードキュー１４３１にバルクメッセージを同時に書き込む。一実施形態において、１４５２で与えられる、マスター１４０１からトランスポートされた変更イベントは常に、１４０２の対応する同じシャードにエンキューされる。たとえば、１４２２にで変更イベントがシャードＱ１に挿入された場合、同じ変更ログがレプリカ（１４０２）に入り１４５２でシャードＱ１に入る。

【0186】

１４５３で、専用適用ハンドラ１４３０が、シャードキュー１４３１からメッセージをデキューする。

【0187】

１４５４で、適用ハンドラ１４３０は、メッセージをデキューしたときと同じ順序でメッセージをローカルデータストア１４１２に書き込む。

【0188】

一般的に、図１４のレプリケーション機能により、すなわち、テナントからのメッセー
ジをマスター地域の同じシャードキューにエンキューし、トランスポートハンドラがデキューされたメッセージを同じ順序で処理し、テナントに関するトランスポートされたメッセージをレプリカ地域の同じシャードにエンキューし、適用ハンドラがデキューされたメッセージを同じ順序で処理することにより、マスターにおけるすべての変更イベントがデータの競合なしで順次処理されることを保証する。

【0189】

しかしながら、１つのマスターで変更イベントがマスター地域（マスター１４０１）からレプリカ地域（レプリカ１４０２）へと順次処理されるにもかかわらず、データ競合が発生し得るシナリオはなおもいくつか存在する。たとえば、データ競合が発生し得る理由として、（１）テナントデータブートストラップ中、エクスポートされたブートストラップデータと進行中の変更イベントとがオーバーラップする場合があり、テナントブートストラップ後にこれらのオーバーラップしている変更イベントを適用するとデータ競合が生じる可能性があること、または（２）先ずレプリカ地域に書き込みその後レプリカ地域におけるテナントサービスプロビジョニングのサービス水準合意（service-level agreements）（「ＳＬＡ」）の向上のためにマスターに逆同期（reverse sync）するとデータ競合が生じる可能性があることが、挙げられる。しかしながら、実施形態において、これらのシナリオの競合回避はまた、レプリカにおいて、マスターにおける同じシーケンスに従うので、回避される。

【0190】

図１５は、本発明の実施形態に係る、マスターＩＤＣＳデプロイメント１４０１とレプリカＩＤＣＳデプロイメント１４０２との間における競合解決の処理フローを示す。

【0191】

１５０１で、専用適用ハンドラ１４７０が、変更イベントを各シャードキュー１４３１からデキューする。

【0192】

１５０２で、適用ハンドラ１４７０は、変更をローカルデータストア１４１２において適用しようと試み、次にデータ競合があるか否かを判断する。以下の表１は、さまざまな種類の動作（すなわち、すべてのＩＤＣＳリソースに対する、作成（Create）、読出（Read）、更新（Update）、削除（Delete）、およびクエリ（Query）（「ＣＲＵＤＱ」）動
作についてのスキーマベースのＲＥＳＴ ＡＰＩの結果としての動作）と、起こり得るデータ競合の種類を示している。

【0193】

表１の競合解決ロジックの１つは、データ競合に応じて実現される。表１の競合解決ロジック１ｂ、２ａまたは４ａが実現される場合、１５０３でリソースがマスター１４０１からフェッチされる。

【0194】

１５０４で、適用ハンドラ１４７０はレプリカ１４０２においてリソースをリコンサイルする。

【0195】

【表1】

【0196】

本発明の実施形態における機能は、（データベースレベル、キャッシュレベルなどではなく）アプリケーションレベル／レイヤで実行される。具体的には、機能は、データベースではなく、１つ以上のマイクロサービス（たとえば管理サービス１４０５および／またはレプリケーションサービス１４０８、１４０７）によって実行される。そのため、実施形態は他の解決策よりも遥かに高速で実行し、実施形態はオンデマンドで自動的にリコンサイルすることができる。実施形態は、シングルマスターレプリケーションフローにおけるデータ競合を回避する。なぜなら、テナントについてのすべての変更イベントは、トランスポートハンドラおよび適用ハンドラ双方によって逐次的に処理されるからである。

【0197】

図１６は、本発明の実施形態に係る、マスターＩＤＣＳデプロイメント１４０１およびレプリカＩＤＣＳデプロイメント１４０２の詳細をさらに示すブロック図である。マスター１４０１で、テナントＤＢ１６０４（すなわちデータストア）に接続された管理サービ
ス１６０２、１６０３が、ＲＥＳＴ ＡＰＩ要求１６０１を受ける。

【0198】

マスター１４０１およびレプリカ１４０２は各々、ハッシュに基づいてメッセージ（一実施形態ではオラクルのアドバンスト・キューイング（Advanced Queuing）（「ＡＱ」）メッセージ、またはアパッチ・カフカ（Apache Kafka）メッセージ）をパーティションに対して発行するシャードキュー１６１０、１６２０を含む。マスター１４０１において、メッセージングトランスポートハンドラ１６２２は、１シャード当たり１つのスレッドトランスポートを与えることによってシーケンスを維持する。各々が１度につき１つのバッファを保持するワーカースレッドが、レプリケーションサービス１６２５に与えられる。レプリケーションサービス１６２５は、１度につき１つのバッファを受け適用キュー（すなわちシャードキュー１６２０）に対して発行することによりシーケンスを維持するエンドポイントとして機能する。メッセージング適用ハンドラ１６３０は、１シャード当たり１つのスレッド適用を与えることによってシーケンスを維持する。レプリケーションサービス１６２５も、テナントＤＢ１６４０（すなわちデータストア）に変更を適用するためのエンドポイントとして機能する。実施形態において、ＩＤＣＳデプロイメントの各レプリケーションサービスは、「マスター」および／または「レプリカ」として働く機能を有する。

【0199】

図１６は、図１４をより詳細にした図であり、パーティション、キュー、およびワーカースレッドを含む。図１６は、キューイングシステムを介した変更ログの実際のフローを示す。「マスター」側では、２つの管理サービスとしての１６０２および１６０３が並列に動作する。１６１０、１６２２、１６２０および１６３０は、一実施形態ではオラクル社の「アドバンスト・キューイング」（「ＡＱ」）として実現される「ｐｕｂ－ｓｕｂ」（出版－購読（publish-subscribe））システムを形成し、図１４の１４３０、１４３５
、１４０７および１４５２の内部をさらに詳細に示す。たとえば、１６０２または１６０３が１６１０に対してメッセージを発行すると直ちにテナントＩＤに対応する変更ログについてハッシュが計算される。このことは、特定のテナントに対応する変更ログが常に同一の「パーティション」にハッシュされることを意味する。受信側（すなわちレプリカ）では、同じロジックが適用され、テナントに対応する変更ログは常にレプリカ上の同じパーティションを介して進む（１６２０）。また、パーティションの数は固定されているので、計算されたハッシュは、「ｍｏｄテナントＩＤ」を用いてパーティションのうちの１つに割り当てられることに注意されたい（１６１０）。

【0200】

図１７は、本発明の実施形態に係る、レプリケーションに応じた競合解決のフロー図である。先に説明したように、競合解決は、シングルマスターレプリケーションモデル（すなわち図１４に関連して説明したモデル）を使用する場合であってもデータに関連する変更アプリケーションの障害を解決するために必要である。なぜなら、レプリカＩＤＣＳインスタンスに対する変更は、マルチスレッドレプリケーション処理フローロジックが原因で、または過去失敗した変更を再度適用するときに、順不同で適用される可能性があるからである。実施形態は、更新タイムスタンプを用いることによってデータ競合を解決し、この場合、各変更エントリの動作タイムスタンプを、既存のターゲットエントリの更新タイムスタンプと比較することにより、変更を適用すべきかまたはスキップすべきかを判断する。

【0201】

既存のターゲットエントリを用いて更新タイムスタンプに基づく競合解決をサポートすることに加えて、実施形態はまた、削除されたエントリに対するツームストン（tombstone)を管理する。これらのツームストンエントリは、既に削除されたターゲットエントリに対して順不同の修正変更を適用するときの競合を解決するために使用される。

【0202】

計画された競合解決ロジックに基づいて、実施形態は、変更をスキップする／適用する
か否か、または、変更リトライのために変更をメッセージキューに戻すか否かを、判断する。競合解決ロジックに基づいてスキップされたまたは適用された変更はパージすることができる。

【0203】

変更アプリケーションは、以下の理由により失敗する可能性がある。
１．ネットワーク、ターゲットＤＢもしくはＩＤＣＳレプリケートサービスがダウンするというようなシステム／リソースの問題またはその過渡的安定性の問題、
２．レプリケートサービス処理が順不同で変化すること、または、
３．前の変更を適用するときの管理エラーまたはＩＤＣＳにおけるソフトウェアバグを原因とするレプリカＩＤＣＳインスタンスに関するデータ問題。

【0204】

ケース（１）および（２）は、競合解決ロジックに加え、設定されたリトライ試み数当たりの適切な変更リトライによって解決されるであろう。ケース（３）は、恒久的な変更アプリケーション障害を生じさせる可能性がある。したがって、一実施形態において、失敗した変更は、人間による介入のために例外キューに移動させる必要がある。

【0205】

ＩＤＣＳメッセージングサービスは、レプリケーション処理フローにリトライ変更を適用するために強化された指数関数的遅延機能とともに、ビルトインメッセージリトライロジックを有する。これはまた、（１構成当たりの）適用されなかった回数があまりにも多い変更メッセージを保持するために使用される例外キューを有する。

【0206】

上記エラーハンドリング方法の結果、実施形態は、以下のレプリケーション競合回避設計の保証を得る。
・メッセージは失われない。
・メッセージは順不同で到来しない。
・ネットワーク／ＤＢエラー／タイムアウトのため、二重メッセージの可能性がある。
・リコンサイル／ブートストラップの結果、これも二重メッセージとして機能する失効メッセージが生じ得る。

【0207】

図１７の機能について、一実施形態では以下の必要条件が存在する。
・ＤＢ生成システム時間を、リソースが最後に修正された時間として設定。これは、全リソースリコンシリエーションによって生じた二重変更ログおよび失効変更ログをドロップするために、データ比較のためのタイムスタンプ／クロックの１つのソースを維持するのに必要である。
・マスターＩＤＣＳインスタンスにおいて、リソースが最後に修正された時間をＤＢから読み戻して変更ログ時間として捕捉。
・レプリカＩＤＣＳインスタンスにおいて、リソースが最後にレプリケートされた時間は、変更ログおよび全リソースのリコンシリエーションを適用すると更新される。マスターからの変更ログ時間を、最後にレプリケートされた時間として用いることにより、１つのクロックソースを維持する。

【0208】

一般的なエラーは以下を含む。
・１７０２において、テナントが存在しない（または）ＤＢ関連エラー（または）接続エラー（または）タイムアウト。適用ハンドラは成功するまでリトライする。
・１７０４において、サービスアイソレーション／リスタートは、ヘルスチェックフレームワークの一部として処理される。

【0209】

動作およびエラーハンドリング処理は以下を含む。
●作成（１７０６）
〇リソースが既に存在（１７０８）
●ペイロードの最後に修正された時間をレプリカＤＢの最後にレプリケートされた時間と比較
●タイムスタンプが同一であれば、変更ログをドロップ
●そうでなければ全リソースリコンシリエーションを実行
●置換／更新（１７１０）
〇リソースが存在しない（１７１２）
●全リソースリコンシリエーションを実行（１７１４）
〇リソースデータ不整合／破損によるエラー（１７１２）
●全リソースリコンシリエーションを実行（１７１４）
〇二重更新属性レベル（結果としてＭＶＡの場合二重エントリになる可能性）
●ペイロードの最後に修正された時間をレプリカＤＢの最後にレプリケートされた時間と比較
●タイムスタンプが同一または小さい場合、変更ログをドロップ
●そうでなければ変更ログを適用
〇ＣＭＶＡを追加／置換／削除－これは、メッセージが失われた場合に限り可能。生じてはならないこと。
●削除（１７１６）
〇リソースは存在しない（１７１８）
●メッセージを複製：変更ログをドロップ
●ｌｏｓｔを作成：生じてはならないこと。
●リコンサイル（１７１４）
〇マスターＩＤＣＳインスタンスから全リソースを取得しレプリカに適用。レプリカの最後にレプリケートされた時間をマスターからのリソースが最後に修正された時間と比較し、既にキューにある失効変更ログをドロップ。

【0210】

開示されているように、実施形態は、マルチテナントクラウドシステムを用いて、異なる地理的領域の複数のアイデンティティ管理システムデプロイメント間のデータのレプリケーションを提供する。したがって、ある地理的領域のあるデプロイメントのテナントは、第２の地理的領域の同じリソースにアクセスできる。実施形態は、変更イベントの逐次処理を用いてこのデータをレプリケートする。実施形態はさらに、データレプリケーション中に発生し得るいかなるデータ競合についても解決を提供する。

【0211】

本明細書ではいくつかの実施形態が具体的に例示および／または記載されている。しかしながら、開示されている実施形態の修正および変形は、本発明の精神および意図する範囲から逸脱することなく、上記教示によってカバーされ以下の請求項の範囲に含まれることが、理解されるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図6A】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【手続補正書】

【提出日】2023-09-26

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

マルチテナントクラウドシステムを動作させる方法であって、前記方法は、
第１のデータセンターで、第１のテナントＩＤに対応する第１のクライアントを認証して前記第１のクライアントに対応するリソースを格納するステップを含み、前記第１のデータセンターは、前記第１のクライアントを認証して前記リソースをレプリケートするように構成された第２のデータセンターと通信し、
前記第１のデータセンターが、前記リソースの変更に対応する、前記第１のクライアントについてのアプリケーションプログラミングインターフェイス（ＡＰＩ）要求を受信して、前記ＡＰＩ要求に応答して変更ログおよび対応する変更イベントメッセージを生成するステップと、
前記変更ログの前記第１のテナントＩＤに対応する第１のハッシュを計算して、前記第１のデータセンターにおける第１のキューの第１のパーティションを求めるステップと、
前記第１のデータセンターが、ＡＰＩコールを介して前記変更イベントメッセージを前記第２のデータセンターにプッシュするステップとを含み、
前記変更イベントメッセージを受信したことに応じて、前記第２のデータセンターは、前記変更ログの前記第１のテナントＩＤに対応する第２のハッシュを計算して、前記第２のデータセンターにおける第２のキューの第２のパーティションを求めるように構成されており、前記第１のキューの前記第１のパーティションは前記第２のキューの前記第２のパーティションに等しい、方法。

【請求項2】

前記第１のキューは第１のシャードキューである、請求項１に記載の方法。

【請求項3】

前記第２のデータセンターは、前記第２のデータセンターにおける適用ハンドラとともに構成され、前記適用ハンドラは、レプリケートされたリソースが既に存在する場合、作成動作に応答して、前記変更イベントメッセージを無視することまたは前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１または２に記載の方法。

【請求項4】

前記適用ハンドラは、前記レプリケートされたリソースが存在しない場合、更新動作に応答して、前記第１のデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項３に記載の方法。

【請求項5】

前記第１のデータセンターは、各々が前記第１のキューにおける対応するパーティションを有する複数のテナントを含む、請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記適用ハンドラは、前記変更ログの動作タイムスタンプをターゲットエントリの更新タイムスタンプと比較することによって競合を解決する、請求項３に記載の方法。

【請求項7】

前記適用ハンドラは、既に削除されたターゲットエントリに対する順不同の修正変更を適用するときに、削除されたエントリのツームストンを維持することによって競合を解決する、請求項３に記載の方法。

【請求項8】

請求項１～７のいずれか１項に記載の方法を複数のプロセッサのうちの少なくとも１つのプロセッサに実行させる、プログラム。

【請求項9】

マルチテナントクラウドシステムデータセンターであって、
第１のテナントＩＤに対応する第１のクライアントを認証して前記第１のクライアントに対応するリソースを格納するようにされた管理サービスを備え、前記マルチテナントクラウドシステムデータセンターは、前記第１のクライアントを認証し前記リソースをレプリケートするように構成された第２のデータセンターと通信し、
前記管理サービスに結合されたデータストアを備え、
前記管理サービスは、前記リソースの変更に対応する、前記第１のクライアントについてのアプリケーションプログラミングインターフェイス（ＡＰＩ）要求を受信するように構成されており、前記ＡＰＩ要求に応答して変更ログおよび対応する変更イベントメッセージを生成して前記変更ログの前記第１のテナントＩＤに対応する第１のハッシュを計算することにより、前記マルチテナントクラウドシステムデータセンターにおける第１のキューの第１のパーティションを求め、
ＡＰＩコールを介して前記変更イベントメッセージを前記第２のデータセンターにプッシュするように適合されたレプリケーションサービスを備え、
前記変更イベントメッセージを受けたことに応答して、前記第２のデータセンターは、前記変更ログの前記第１のテナントＩＤに対応する第２のハッシュを計算することにより、前記第２のデータセンターにおける第２のキューの第２のパーティションを求めるように構成されており、前記第１のキューの前記第１のパーティションは前記第２のキューの前記第２のパーティションに等しい、マルチテナントクラウドシステムデータセンター。

【請求項10】

前記第１のキューは第１のシャードキューである、請求項９に記載のマルチテナントクラウドシステムデータセンター。

【請求項11】

前記第２のデータセンターは、前記第２のデータセンターにおける適用ハンドラとともに構成され、前記適用ハンドラは、レプリケートされたリソースが既に存在する場合、作成動作に応答して、前記変更イベントメッセージを無視することまたは前記マルチテナントクラウドシステムデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１０に記載のマルチテナントクラウドシステムデータセンター。

【請求項12】

前記適用ハンドラは、前記レプリケートされたリソースが存在しない場合、更新動作に応答して、前記マルチテナントクラウドシステムデータセンターから前記リソースをフェッチすることにより、前記第２のデータセンターにおける競合を解決する、請求項１１に記載のマルチテナントクラウドシステムデータセンター。

【請求項13】

前記適用ハンドラは、前記変更ログの動作タイムスタンプをターゲットエントリの更新タイムスタンプと比較することによって競合を解決する、請求項１１に記載のマルチテナントクラウドシステムデータセンター。

【請求項14】

前記適用ハンドラは、既に削除されたターゲットエントリに対する順不同の修正変更を適用するときに、削除されたエントリのツームストンを維持することによって競合を解決する、請求項１１に記載のマルチテナントクラウドシステムデータセンター。

【外国語明細書】