詳細な説明
実施形態は、マルチテナントでクラウドスケールのアイデンティティおよびアクセス管理(identity and access management:「IAM」)プラットフォームを提供するアイデンティティクラウドサービス(Identity Cloud Service:「IDCS」)におけるシングルサインオン(「SSO」)機能を提供する。一実施形態では、グローバルセッションを提供し、次にグローバルセッションに基づいてプロトコル固有のトークンを生成することにより、SSO機能を実現する。実施形態はさらに、クッキーを利用して複数のアプリケーションから繰り返しログアウトし、安全情報がクッキーに格納されないようリダイレクトを使用することにより、シングルログアウト(「SLO」)機能を提供する。
実施形態が提供するアイデンティティクラウドサービスは、マイクロサービスベースのアーキテクチャを実現するとともに、マルチテナントアイデンティティおよびデータセキュリティの管理ならびにクラウドベースのアプリケーションへの安全なアクセスを提供する。実施形態は、ハイブリッドクラウドのデプロイメント(すなわちパブリッククラウドとプライベートクラウドとを組み合わせたものを含むクラウドのデプロイメント)について安全なアクセスをサポートする。実施形態は、クラウド内およびオンプレミス双方におけるアプリケーションおよびデータを保護する。実施形態は、ウェブ、モバイル機器、およびアプリケーションプログラミングインターフェイス(application programming interface:「API」)を介したマルチチャネルアクセスをサポートする。実施形態は、顧客、パートナー、および被雇用者など、さまざまなユーザのアクセスを管理する。実施形態は、クラウドを通じたアクセスおよびオンプレミスのアクセス双方を管理、制御、および監査する。実施形態は、新たなおよび既存のアプリケーションおよびアイデンティと統合される。実施形態は横方向にスケーラブルである。
一実施形態は、ステートレスな中間層環境において多数のマイクロサービスを実現することによりクラウドベースのマルチテナントアイデンティティおよびアクセス管理サービスを提供するシステムである。一実施形態において、要求された各アイデンティティ管理サービスは、リアルタイムタスクとニア・リアルタイムタスクとに分割される。リアルタイムタスクは中間層のマイクロサービスによって処理されるのに対し、ニア・リアルタイムタスクはメッセージキューにオフロードされる。実施形態は、ルーティング層および中間層によって消費されるアクセストークンを実現することにより、マイクロサービスにアクセスするためのセキュリティモデルを強化する。したがって、実施形態は、マルチテナントのマイクロサービスアーキテクチャに基づいてクラウドスケールのIAMプラットフォームを提供する。
一実施形態は、組織が、その新たなビジネス構想のために高速で信頼性が高くかつ安全なサービスを迅速に開発できるようにするアイデンティティクラウドサービスを提供する。一実施形態において、アイデンティティクラウドサービスは多数のコアサービスを提供する。各コアサービスは、多くの企業が直面する固有の課題を解決する。一実施形態において、アイデンティティクラウドサービスは、たとえば、最初にユーザのオンボード/インポートを行うとき、ユーザメンバとともにグループをインポートするとき、ユーザを作成/更新/ディスエーブル/イネーブル/削除するとき、ユーザをグループに割り当てる/グループへのユーザ割り当てを解除するとき、グループを作成/更新/削除するとき、パスワードをリセットするとき、ポリシーを管理するとき、アクティベーションを送信するときなどの、アドミニストレータをサポートする。
統一されたアクセスセキュリティ
一実施形態は、クラウド環境およびオンプレミス環境双方におけるアプリケーションおよびデータを保護する。本実施形態は、どのデバイスからの誰によるどのアプリケーションへのアクセスも安全にする。本実施形態は、これらの環境双方にわたる保護を提供する。なぜなら、これら2つの環境の間でセキュリティに矛盾があればリスクが高くなる可能性があるからである。たとえば、このような矛盾があった場合、販売員は、離反して競合他社に移った後であっても、その顧客関係管理(Customer Relationship Management:「CRM」)アカウントへのアクセス権を有し続ける場合がある。したがって、実施形態は、オンプレミス環境においてプロビジョニングされたセキュリティ制御をクラウド環境に拡張する。たとえば、ある人物が会社を辞めた場合、実施形態は、そのアカウントがオンプレミスおよびクラウド双方においてディスエーブルされることを保証する。
一般的に、ユーザは、ウェブブラウザ、デスクトップ、携帯電話、タブレット、スマートウォッチ、その他のウェアラブル機器などの多種多様なチャネルを通してアプリケーションおよび/またはデータにアクセスし得る。したがって、一実施形態は、これらすべてのチャネルについて、これらを通るアクセスを安全なものにする。たとえば、ユーザは、その携帯電話を用いて、自身のデスクトップ上で開始したトランザクションを完了させることができる。
一実施形態はさらに、顧客、パートナー、被雇用者など、さまざまなユーザのアクセスを管理する。一般的に、アプリケーションおよび/またはデータは、被雇用者だけでなく、顧客または第三者によってもアクセスされる場合がある。既知の多くのシステムは、被雇用者のオンボード時に安全対策を講じるが、この安全対策は通常、顧客、第三者、パートナーなどにアクセス権を付与するときの安全対策と同じレベルではないので、結果として、適切に管理されていない者によってセキュリティが破られる可能性がある。しかしながら、実施形態は、被雇用者だけでなく各タイプのユーザのアクセスについて十分な安全対策が提供されることを保証する。
アイデンティティクラウドサービス
実施形態は、マルチテナントでクラウドスケールのIAMプラットフォームであるIDCSを提供する。IDCSは、認証、認可、監査、および連携(federation)を提供する。IDCSは、パブリッククラウドおよびオンプレミスシステム上で実行されているカスタムアプリケーションおよびサービスへのアクセスを管理する。これに代わるまたはこれに加えられる実施形態において、IDCSは、パブリッククラウドサービスへのアクセスも管理し得る。たとえば、IDCSを用いて、このような多様なサービス/アプリケーション/システムにまたがるSSO機能を提供することができる。
実施形態は、クラウドスケールのソフトウェアサービスを設計、構築、および配信するためのマルチテナントマイクロサービスアーキテクチャに基づく。マルチテナンシーとは、あるサービスを物理的に実現したものがありこのサービスが当該サービスを購入した複数の顧客を安全にサポートするサービスであることを言う。サービスは、異なるクライアントが異なる目的のために再使用できるソフトウェア機能またはソフトウェア機能のセット(指定された情報を取り出すことまたは一組の動作を実行することなど)に、(たとえばサービスを要求しているクライアントのアイデンティティに基づく)その使用を管理するポリシーを合わせたものである。一実施形態において、サービスは、1つ以上の機能へのアクセスを可能にするメカニズムであり、このアクセスは、所定のインターフェイスを用いて提供され、サービスの記述によって明記された制約およびポリシーに従って実行される。
一実施形態において、マイクロサービスは独立してデプロイ可能なサービスである。一実施形態において、マイクロサービスという用語は、言語に依存しないAPIを用いて相互に通信する小さな独立したプロセスから複雑なアプリケーションが構成されている、ソフトウェアアーキテクチャ設計パターンを意図している。一実施形態において、マイクロサービスは、細かく分離された小さなサービスであり、各サービスは、小さなタスクの実行に集中し得る。一実施形態において、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを小さなサービス一式として開発する手法であり、各サービスは、自身のプロセスにおいて実行され、軽量のメカニズム(たとえばハイパーテキスト・トランスファー・プロトコル(Hypertext Transfer Protocol:「HTTP」)リソースAPI)と通信する。一実施形態において、マイクロサービスは、同一機能すべてをまたは同一機能のうちの多くを実行するモノリシックサービスと比較すると、交換がより簡単である。加えて、マイクロサービスは各々、その他のマイクロサービスに悪影響を与えることなく更新し得る。これに対し、モノリシックサービスの一部を更新すると、当該モノリシックサービスの他の部分に望ましくないまたは意図せぬ悪影響が及ぶ可能性がある。一実施形態において、マイクロサービスはその機能を中心として有益に編成し得る。一実施形態において、マイクロサービスのコレクションのうち各マイクロサービスのスタートアップ時間は、これらのマイクロサービスのうちのすべてのサービスをまとめて実行する単一のアプリケーションのスタートアップ時間よりも遥かに短い。いくつかの実施形態において、このようなマイクロサービス各々のスタートアップ時間は約1秒以下であるのに対し、このような単一のアプリケーションのスタートアップ時間は約1分、数分、またはそれよりも長い場合がある。
一実施形態において、マイクロサービスアーキテクチャとは、フレキシブルで、独立してデプロイ可能なソフトウェアシステムを構築するための、サービス指向アーキテクチャ(service oriented architecture(「SOA」))の専門化(すなわちシステム内におけるタスクの分離)および実現の手法のことである。マイクロサービスアーキテクチャにおけるサービスは、目的を達成するためにネットワークを通して相互に通信するプロセスである。一実施形態において、これらのサービスは、技術に依存しないプロトコルを使用する。一実施形態において、サービスは、細分性が小さく軽量であるプロトコルを使用する。一実施形態において、サービスは独立してデプロイ可能である。システムの機能を異なる小さなサービスに分散させることにより、システムの結束性は向上し、システムのカップリングは減少する。それにより、システム変更が容易になり、任意の時点でシステムに機能および品質を追加することが容易になる。また、それによって、個々のサービスのアーキテクチャが、絶え間ないリファクタリングを通して出現することが可能になり、したがって、大規模な事前の設計の必要性は低下しソフトウェアを早期に連続してリリースすることが可能になる。
一実施形態において、マイクロサービスアーキテクチャでは、アプリケーションがサービスのコレクションとして開発され、各サービスはそれぞれのプロセスを実行し軽量のプロトコルを用いて通信する(たとえばマイクロサービスごとの固有API)。マイクロサービスアーキテクチャにおいて、1つのソフトウェアを個々のサービス/機能に分解することは、提供するサービスに応じて異なるレベルの粒度で行うことができる。サービスはランタイムコンポーネント/プロセスである。各マイクロサービスは、他のモジュール/マイクロサービスに対してトークすることができる内蔵モジュールである。各マイクロサービスは、他からコンタクトできる無名ユニバーサルポートを有する。一実施形態において、マイクロサービスの無名ユニバーサルポートは、従来マイクロサービスがエクスポーズする標準通信チャネルであり(たとえば従来のハイパーテキスト転送プロトコル(「HTTP」)ポートのような)、同一サービス内の他のモジュール/マイクロサービスがそれに対してトークできるようにする標準通信チャネルである。マイクロサービスまたはその他の内蔵機能モジュールを包括的に「サービス」と呼ぶことができる。
実施形態は、マルチテナントアイデンティティ管理サービスを提供する。実施形態は、さまざまなアプリケーションとの容易な統合を保証するオープン標準に基づいており、標準ベースのサービスを通してIAM機能を提供する。
実施形態は、アイデンティティがアクセスできる対象、このようなアクセスを付与できる者、このようなアクセスを管理できる者などを判断し施行することを伴うユーザアイデンティティのライフサイクルを管理する。実施形態は、クラウド内でアイデンティティ管理ワークロードを実行し、このクラウド内に存在するとは限らないアプリケーションのセキュリティ機能をサポートする。これらの実施形態が提供するアイデンティティ管理サービスはクラウドから購入されてもよい。たとえば、企業は、このようなサービスをクラウドから購入してその被雇用者の当該企業のアプリケーションに対するアクセスを管理してもよい。
実施形態は、システムセキュリティ、大規模なスケーラビリティ、エンドユーザのユーザビリティ、およびアプリケーションのインターオペラビリティを提供する。実施形態は、クラウドの成長と、顧客によるアイデンティティサービスの使用とを扱っている。マイクロサービスに基づく基礎は、横方向のスケーラビリティ条件を扱うのに対し、サービスの綿密な調整は機能条件を扱う。これらの目標双方を達成するには、ビジネスロジックを(可能な限り)分解することにより、最終的には一貫性のあるステートレスを達成する一方で、リアルタイム処理を受けない動作論理のほとんどが、配信と処理が保証されたスケーラビリティが高い非同期イベント管理システムに、オフロードされることにより、ニア・リアルタイムにシフトする。実施形態は、コスト効率を実現しシステム管理を容易にするために、ウェブ層からデータまで完全にマルチテナントである。
実施形態は、さまざまなアプリケーションと統合し易くするために、業界の標準(たとえば、OpenID Connect、OAuth2、セキュリティ・アサーション・マークアップ言語(Security Assertion Markup Language)2(「SAML2」)、クロスドメインアイデンティティ管理用システム(System for Cross-domain Identity Management:「SCIM」)、レプレゼンテーショナル・ステート・トランスファー(Representational State Transfer:「REST」)など)に従う。一実施形態は、クラウドスケールAPIプラットフォームを提供し、エラスティックスケーラビリティのために横方向にスケーラブルなマイクロサービスを実現する。本実施形態は、クラウド原理を強化し、テナントごとにデータを分離したマルチテナントアーキテクチャを提供する。本実施形態はさらに、テナントセルフサービスを介してテナントごとのカスタマイズを提供する。本実施形態は、他のアイデンティサービスとのオンデマンドの統合の際にはAPIを介して利用することができ、連続したフィーチャーリリースを提供する。
一実施形態は、インターオペラビリティを提供し、クラウドおよびオンプレミスにおけるアイデンティティ管理(identity management:「IDM」)機能への投資を強化する。本実施形態は、オンプレミスの軽量ディレクトリアクセスプロトコル(Lightweight Directory Access Protocol:「LDAP」)データからクラウドデータへの、およびその逆の、自動化されたアイデンティティ同期化を提供する。本実施形態は、クラウドと企業との間にSCIMアイデンティティバスを提供し、ハイブリッドクラウドのデプロイの各種オプションを可能にする(たとえば、アイデンティティ連携および/または同期化、SSOエージェント、ユーザプロビジョニングコネクタなど)。
したがって、一実施形態は、ステートレスな中間層において多数のマイクロサービスを実現することによりクラウドベースのマルチテナントアイデンティティおよびアクセス管理サービスを提供するシステムである。一実施形態において、要求された各アイデンティティ管理サービスは、リアルタイムタスクとニア・リアルタイムタスクとに分割される。リアルタイムタスクは中間層のマイクロサービスによって処理されるのに対し、ニア・リアルタイムタスクはメッセージキューにオフロードされる。実施形態は、ルーティング層によって消費されて、マイクロサービスにアクセスするためのセキュリティモデルを実施するトークンを実現する。したがって、実施形態は、マルチテナントのマイクロサービスアーキテクチャに基づくクラウドスケールのIAMプラットフォームを提供する。
一般的に、周知のシステムは、たとえば、企業クラウドアプリケーション、パートナークラウドアプリケーション、第三者クラウドアプリケーション、および顧客アプリケーションなど、各種環境によって提供されるアプリケーションに対するサイロ化されたアクセスを提供する。このようなサイロ化されたアクセスは、複数のパスワード、異なるパスワードポリシー、異なるアカウントプロビジョニングおよびデプロビジョニング手法、異種の監査などを必要とする場合がある。しかしながら、一実施形態は、IDCSを実現することにより、このようなアプリケーションに対し統一されたIAM機能を提供する。図1は、ユーザおよびアプリケーションをオンボードするための統一されたアイデンティティプラットフォーム126を提供する、IDCS118を用いる実施形態の一例のブロック図100である。本実施形態は、企業クラウドアプリケーション102、パートナークラウドアプリケーション104、第三者クラウドアプリケーション110、および顧客アプリケーション112などのさまざまなアプリケーションにまたがるシームレスなユーザ体験を提供する。アプリケーション102、104、110、112は、異なるチャネルを通してアクセスされてもよく、たとえば、携帯電話ユーザ108が携帯電話106を介して、デスクトップコンピュータのユーザ116がブラウザ114を介して、アクセスしてもよい。ウェブブラウザ(一般的にブラウザと呼ばれる)は、ワールドワイドウェブ上で情報リソースを取得、提示、およびトラバースするためのソフトウェアアプリケーションである。ウェブブラウザの例としては、Mozilla(登録商標) Firefox(登録商標)、Google Chrome(登録商標)、Microsoft(登録商標) Internet Explorer(登録商標)、およびApple(登録商標) Safari(登録商標)が挙げられる。
IDCS118は、ユーザのアプリケーションの統一されたビュー124、(アイデンティティプラットフォーム126を介する)デバイスおよびアプリケーションにまたがる統一された安全なクレデンシャル、および(管理コンソール122を介する)統一された管理方法を、提供する。IDCSサービスは、IDCS API142にコールすることによって取得されてもよい。このようなサービスは、たとえば、ログイン/SSOサービス128(たとえばOpenID Connect)、連携サービス130(たとえばSAML)、トークンサービス132(たとえばOAuth)、ディレクトリサービス134(たとえばSCIM)、プロビジョニングサービス136(たとえばSCIMまたはAny Transport over Multiprotocol(「AToM」))、イベントサービス138(たとえばREST)、およびロールベースアクセス制御(role-based access control:「RBAC」)サービス140(たとえばSCIM)を含み得る。IDCS118はさらに、提供されるサービスに関するレポートおよびダッシュボード120を提供し得る。
統合ツール
通常、大企業では、そのオンプレミスのアプリケーションへの安全なアクセスのために、IAMシステムを適所に設けるのが一般的である。ビジネス手法は通常オラクル社の「Oracle IAM Suite」などのインハウスIAMシステムを中心として成熟し標準化される。小〜中規模組織でも、通常は、そのビジネスプロセスを、Microsoft Active Directory(「AD」)などの単純なディレクトリソリューションを通してユーザアクセスを管理することを中心として設計されている。オンプレミス統合を可能にするために、実施形態は、顧客がそのアプリケーションをIDCSと統合できるようにするツールを提供する。
図2は、オンプレミス206のAD204との統合を提供する、クラウド環境208内のIDCS202を用いる実施形態の一例のブロック図200である。本実施形態は、たとえば、クラウドサービス210、クラウドアプリケーション212、パートナーアプリケーション214、および顧客アプリケーション216などのクラウド208内のさまざまなアプリケーション/サービスならびにオンプレミスアプリケーション218などのオンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがる、シームレスなユーザ体験を提供する。クラウドアプリケーション212は、たとえば、ヒューマン・キャピタル・マネージメント(Human Capital Management:「HCM」)、CRM、タレント取得(たとえばオラクル社のOracle Taleoクラウドサービス)、構成、価格設定、および見積もり(Configure Price and Quote「CPQ」)などを含み得る。クラウドサービス210は、たとえば、サービスとしてのプラットフォーム(Platform as a Service:「PaaS」)、Java(登録商標)、データベース、ビジネスインテリジェンス(business intelligence:「BI」)、文書などを含み得る。
アプリケーション210、212、214、216、218は、異なるチャネルを通してアクセスされてもよく、たとえば、携帯電話ユーザ220が携帯電話222を介して、デスクトップコンピュータのユーザ224がブラウザ226を介して、アクセスしてもよい。本実施形態は、クラウド208と企業206との間のSCIMアイデンティティバス234を介して、オンプレミスのADデータからクラウドデータに、アイデンティティの同期化を自動的に行う。本実施形態はさらに、クラウド208からオンプレミスAD204への、(たとえばパスワード232を用いて)認証を連携させるためのSAMLバス228を提供する。
一般的に、アイデンティティバスは、アイデンティティ関連サービスのためのサービスバスである。サービスバスは、メッセージをあるシステムから別のシステムに伝えるためのプラットフォームを提供する。これは、たとえばサービス指向アーキテクチャ(service oriented architecture:「SOA」)において、信頼されているシステム間で情報を交換するための制御されたメカニズムである。アイデンティティバスは、ウェブサービス、ウェブサーバプロキシなどの標準的なHTTPベースのメカニズムに従って構築された論理バスである。アイデンティティバスにおける通信は、各プロトコル(たとえばSCIM、SAML、OpenID Connectなど)に従って実行されてもよい。たとえば、SAMLバスは、SAMLサービスに関するメッセージを伝えるための、2つのシステム間のHTTPベースの接続である。同様に、SCIMバスを用い、SCIMプロトコルに従って、SCIMメッセージを伝える。
図2の実施形態は、顧客のAD204とともにオンプレミス206でダウンロードおよびインストールすることができる小バイナリ(たとえば大きさが1MB)のアイデンティティ(「ID」)ブリッジ230を実現する。IDブリッジ230は、顧客によって選択された組織ユニット(organizational unit:「OU」)のユーザおよびグループ(たとえばユーザのグループ)をリッスンし、これらのユーザをクラウド208に対して同期させる。一実施形態において、ユーザのパスワード232はクラウド208に対して同期されていない。顧客は、IDCSユーザのグループを、IDCS208において管理されているクラウドアプリケーションにマッピングすることにより、ユーザのアプリケーションアクセスを管理することができる。ユーザのグループメンバーシップがオンプレミス206で変更されるたびに、対応するクラウドアプリケーションアクセスは自動的に変更される。
たとえば、技術部門から販売部門に異動した被雇用者は、販売クラウドへのアクセスをほぼ瞬間的に取得することができ、開発者クラウドへのアクセスは失う。この変化がオンプレミスAD204に反映されると、クラウドアプリケーションのアクセスの変更がニア・リアルタイムで実現される。同様に、IDCS208で管理されているクラウドアプリケーションへの、この企業から去るユーザのアクセスは、取消される。完全自動化のために、顧客は、たとえばAD連携サービス(「AD/FS」またはSAML連携を実現するその他の何らかのメカニズム)を通して、オンプレミスAD204とIDCS208との間のSSOをセットアップして、エンドユーザが、単一の企業パスワード332を用いて、クラウドアプリケーション210、212、214、216およびオンプレミスアプリケーション218にアクセスできるようにしてもよい。
図3は、図2と同一のコンポーネント202、206、208、210、212、214、216、218、220、222、224、226、228、234を含む実施形態の一例のブロック図300である。しかしながら、図3の実施形態において、IDCS202は、オラクルIDMのようなオンプレミスIDM304との統合を提供する。オラクルIDM304は、IAM機能を提供するための、オラクル社のソフトウェアスイートである。本実施形態は、オンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがるシームレスなユーザ体験を提供する。本実施形態は、クラウド202と企業206との間のSCIMアイデンティティバス234を介したオンプレミスIDM304からIDCS208へのユーザアイデンティティをプロビジョニングする。本実施形態はさらに、クラウド208からオンプレミス206への認証の連携のためのSAMLバス228(またはOpenID Connectバス)を提供する。
図3の実施形態において、オラクル社のオラクルアイデンティティマネージャ(Oracle Identity Manager:「OIM」)コネクタ302およびオラクル社のオラクルアクセスマネージャ(Oracle Access Manager:「OAM」)連携モジュール306は、オラクルIDM304の拡張モジュールとして実現される。コネクタは、システムに話しかける方法について物理的な認識があるモジュールである。OIMは、ユーザアイデンティティを管理するように構成されたアプリケーションである(たとえば、ユーザがアクセス権を持つべき対象とアクセス権を持つべきでない対象に基づいて異なるシステムのユーザアカウントを管理する)。OAMは、ウェブSSO、アイデンティコンテキスト、認証および認可、ポリシー管理、テスト、ロギング、監査などのアクセス管理機能を提供するセキュリティアプリケーションである。OAMはSAMLに対するビルトイン(built-in)サポートを有する。ユーザがIDCS202のアカウントを有する場合、OIMコネクタ302およびOAM連携306をオラクルIDM304とともに使用することにより、このアカウントを作成/削除し、このアカントからのアクセスを管理することができる。
図4は、図2および図3と同一のコンポーネント202、206、208、210、212、214、216、218、220、222、224、226、234を含む実施形態の一例のブロック図400である。しかしながら、図4の実施形態において、IDCS202は、クラウドアイデンティをオンプレミスアプリケーション218に拡張するための機能を提供する。本実施形態は、オンプレミスアプリケーションおよび第三者アプリケーションを含むすべてのアプリケーションにまたがるアイデンティティのシームレスなビューを提供する。図4の実施形態において、SCIMアイデンティティバス234を用いることにより、IDCS202のデータを「クラウドキャッシュ」402と呼ばれるオンプレミスLDAPデータと同期させる。クラウドキャッシュ402は以下でより詳細に開示される。
一般的に、LDAPに基づいて通信するように構成されたアプリケーションは、LDAP接続を必要とする。このようなアプリケーションはLDAP接続をURLを用いて構築しないかもしれない(たとえばGoogle(登録商標)に接続する「www.***.com」とは違って)。なぜなら、LDAPはローカルネットワーク上になければならないからである。図4の実施形態において、LDAPベースのアプリケーション218は、クラウドキャッシュ402に接続し、クラウドキャッシュ402は、IDCS202に接続してから、要求されているデータをIDCS202から引出す。IDCS202とクラウドキャッシュ402との間の通信は、SCIMプロトコルに従って実現されてもよい。たとえば、クラウドキャッシュ402はSCIMバス234を用いてSCIM要求をIDCS202に送信し、それに対応するデータを受信してもよい。
一般的に、あるアプリケーションの完全な実現は、コンシューマポータルを構築することと、外部ユーザ集団に対してマーケティングキャンペーンを実行することと、ウェブおよびモバイルチャネルをサポートすることと、ユーザ認証、セッション、ユーザプロファイル、ユーザグループ、アプリケーションロール、パスワードポリシー、セルフサービス/登録、社会的統合、アイデンティ連携などを処理することとを含む。一般的に、アプリケーションの開発者はアイデンティティ/セキュリティの専門家ではない。このため、オンデマンドのアイデンティティ管理サービスが望ましいのである。
図5は、図2〜図4と同一のコンポーネント202、220、222、224、226、234、402を含む実施形態の一例のブロック図500である。しかしながら、図5の実施形態において、IDCS202は、オンデマンドで安全なアイデンティティ管理を提供する。本実施形態は、オンデマンドの、IDCS202のアイデンティサービスとの統合を提供する(たとえばOpenID Connect、OAuth2、SAML2、またはSCIMなどの標準に基づいて)。(オンプレミスであってもパブリッククラウド内またはプライベートクラウド内にあってもよい)アプリケーション505は、IDCS202のアイデンティティサービスAPI504をコールしてもよい。IDCS202が提供するサービスは、たとえば、セルフサービス登録506、パスワード管理508、ユーザプロファイル管理510、ユーザ認証512、トークン管理514、社会的統合516などを含み得る。
本実施形態において、SCIMアイデンティティバス234を用いることにより、IDCS202内のデータを、オンプレミスのLDAPクラウドキャッシュ402内のデータと同期させる。さらに、ウェブサーバ/プロキシ(たとえばNGINX、Apacheなど)上で実行している「クラウドゲート」502を、アプリケーション505が用いて、IDCS202からユーザウェブSSOおよびREST APIセキュリティを取得してもよい。クラウドゲート502は、クライアントアプリケーションが有効なアクセストークンを提供すること、および/またはユーザがSSOセッション構築のために正常に認証することを保証することによって、マルチテナントIDCSマイクロサービスへのアクセスを安全なものするコンポーネントである。クラウドゲート502は以下でさらに開示される。クラウドゲート502(webgate/webagentと同様の実施ポイント)は、サポートされているウェブサーバの背後で実行されているアプリケーションがSSOに参加することを可能にする。
一実施形態は、SSOおよびクラウドSSO機能を提供する。多くの組織において、オンプレミスIAMおよびIDCSいずれにおいても一般的なエントリポイントはSSOである。クラウドSSOは、ユーザが、1回のユーザサイン・インで複数のクラウドリソースにアクセスできるようにする。組織はそのオンプレミスアイデンティティの連携を希望することが多い。したがって、実施形態は、オープン標準を利用することで、既存のSSOとの統合を実現することにより、投資の節約と拡大を可能にする(たとえば、アイデンティティクラウドサービス手法への最終的な完全移行まで)。
一実施形態は以下の機能を提供し得る。
・アイデンティティストアを維持することにより、既に認可されているユーザアカウント、所有権、アクセス、および許可を追跡する。
・ワークフローとの統合により、アプリケーションのアクセスに必要なさまざまな承認(たとえば管理、IT、人的資源、法律、およびコンプライアンス)を簡単にする。
・選択的装置(たとえばモバイルおよびパーソナルコンピュータ(「PC」))に対するSaaSユーザアカウントをプロビジョニングする。ユーザポータルへのアクセスは、多数のプライベートおよびパブリッククラウドリソースを含む。
・規則および現在の職責へのコンプライアンスのための定期的な管理立証を容易にする。
これらの機能に加えて、実施形態はさらに、
・クラウドアプリケーションにおけるアカウントライフサイクルの管理のためのクラウドアカウントのプロビジョニング、
・よりロバストなマルチファクタ認証(multifactor authentication:「MFA」)の統合、
・拡張モバイルセキュリティ機能、および
・動的認証オプション
を提供し得る。
一実施形態は、適応認証およびMFAを提供する。一般的に、パスワードおよび確認のための質問は、不十分でありフィッシングなどのよくある攻撃に晒され易いとみなされてきた。現代の大半の企業体は、リスクを下げるために何らかの形態のMFAに注目している。しかしながら、ソリューションが首尾よくデプロイされるためには、ソリューションをエンドユーザが簡単にプロビジョニング、維持、および理解する必要がある。なぜなら、エンドユーザは通常、そのデジタル体験を妨害するものに対し、それが何であろうと抵抗するからである。企業は、MFAを、シームレスなユーザアクセス体験のほぼトランスペアレントなコンポーネントにしつつ、私物の業務利用(bring your own device:「BYOD」)、社会的アイデンティティ、遠隔ユーザ、顧客、および契約者を安全に組込む方法を探している。MFAのデプロイにおいて、OAuthおよびOpenID Connectなどの産業標準は、既存のマルチファクタソリューションの統合と、より新しい適応認証技術の導入とを保証するのに不可欠である。したがって、実施形態は、動的(または適応)認証を、利用できる情報(すなわちIPアドレス、場所、時刻、およびバイオメトリクス)の評価として定義することにより、ユーザセッション開始後のアイデンティを証明する。適切な標準(たとえばオープン認証(open authentication:「OATH」)および高速オンライン認証(fast identity online:「FIDO」)の統合と、拡張可能なアイデンティティ管理フレームワークとを用いて、実施形態は、エンド・ツー・エンドの安全なIAMデプロイの一部としてIT組織内で簡単に採用、アップグレード、および統合できるMFAソリューションを提供する。MFAおよび適応ポリシーを検討する場合、組織は、ハイブリッドのIDCSおよびオンプレミスIAM環境においてシステム間の統合を必要とするオンプレミスリソースおよびクラウドリソースにわたって一貫したポリシーを実現しなければならない。
一実施形態は、ユーザプロビジョニングおよび証明を提供する。一般的に、IAMソリューションの基本機能は、ユーザプロビジョニングライフサイクル全体を可能にしかつサポートすることである。これは、ユーザに対し、組織内におけるそのアイデンティティおよびロール(role)に適したアプリケーションアクセスを与えること(たとえば、ユーザのロールまたはそのロールの中で使用されるタスクもしくはアプリケーションは時間の経過に伴って変化するので)と、ユーザが組織から脱退するときに必要な、素早いユーザデプロビジョニングとを含む。これは、さまざまなコンプライアンス条件を満たすために重要であるだけでなく、不適切なインサイダーアクセスがセキュリティ侵害および攻撃の主要な原因であるので、重要である。アイデンティティクラウドソリューションにおける、自動化されたユーザプロビジョニング機能は、それ自身の権利において重要になり得るだけでなく、ハイブリッドIAMソリューションの一部としても重要であり、したがって、IDCSプロビジョニングは、企業が縮小、拡大、合併する、または既存のシステムをIaaS/PaaS/SaaS環境と統合しようとする場合、移行時において、オンプレミスソリューションよりも高い柔軟性を提供し得る。IDCS手法は、一度限りのアップグレードにおいて時間と労力を節約することができ、必要な部門、事業部、およびシステムの適切な統合を保証する。企業ではこの技術をスケーリングする必要性が密かに発生することが多く、企業体系全体にスケーラブルなIDCS機能を迅速に提供することは、柔軟性、コスト、および制御の点で利益をもたらし得る。
一般的に、被雇用者は、長年にわたり、職種の変化に応じて追加の権限が付与される(すなわち「権限のクリープ」)。規制が緩やかな企業は一般的に「立証」プロセスが欠落している。このプロセスは、企業の被雇用者の権限(たとえばネットワーク、サーバ、アプリケーション、およびデータへのアクセス権)を定期的に監査して、過剰な権限が付与されたアカウントの原因となる権限のクリープを止めるまたは減速させる管理者を必要とする。したがって、一実施形態は、定期的に実施される(少なくとも1年に一度)立証プロセスを提供し得る。さらに、合併および買収に伴い、これらのツールおよびサービスの必要性は急激に増す。ユーザが、SaaSシステムに存在する、オンプレミス上に存在する、異なる部門にまたがっている、および/またはデプロビジョニングされているもしくは再度割り当てられているからである。クラウドへの動きはこの状況をさらに混乱させる可能性があり、事態は、既存の手動管理されることが多い証明方法を超えて急速にエスカレートする可能性がある。したがって、一実施形態は、これらの機能を自動化し、高度な分析を、ユーザプロファイル、アクセス履歴、プロビジョニング/デプロビジョニング、および細分化された権利に適用する。
一実施形態はアイデンティティ分析を提供する。一般的に、アイデンティティ分析を、包括的な証明および立証のためにIAMエンジンと統合する機能は、組織のリスクプロファイルを安全にするためには不可欠となる可能性がある。適切にデプロイされたアイデンティティ分析は、内部ポリシー全体の施行を要求する可能性がある。クラウドおよびオンプレミス全体で統一された単一管理ビューを提供するアイデンティティ分析は、予防的ガバナンス、リスク、およびコンプライアンス(governance, risk, and compliance:「GRC」)企業環境における必要性が高く、リスクを低減しコンプライアンス規則を満たすための閉ループプロセスを提供するのに役立ち得る。したがって、一実施形態はアイデンティティ分析を提供する。アイデンティティ分析は、管理者、幹部職員、および監査役が必要とするレポートおよび分析のために、クライアントが簡単にカスタマイズすることで特定の産業条件および政府規則に適合する。
一実施形態は、セルフサービスおよびアクセス要求機能を提供することにより、エンドユーザの体験および効率を改善するとともに、ヘルプデスクコールに要するコストを低減する。一般的に、多数の企業はその従業員のためにオンプレミスのセルフサービスアクセス要求をデプロイするが、多くは、これらのシステムを正式な企業の壁の外側まで適切に拡張していない。従業員の用途の範囲外の、ポジティブなデジタル顧客体験が、ビジネスの信頼性を高め最終的には収入の増加に貢献し、企業は、顧客ヘルプデスクコールを減じるだけでなく顧客の満足度を高める。したがって、一実施形態は、オープン標準に基づいておりかつ必要に応じて既存のアクセス制御ソフトウェアおよびMFAメカニズムとシームレスに統合される、アイデンティティクラウドサービス環境を提供する。SaaS配信モデルは、以前はシステムのアップグレードおよびメンテナンスに費やされていた時間と労力を省き、IT専門スタッフを解放してより中心的なビジネスアプリケーションに集中できるようにする。
一実施形態は、特権アカウント管理(privileged account management:「PAM」)を提供する。一般的に、すべての組織は、SaaS、PaaS、IaaSまたはオンプレミスアプリケーションいずれを使用しても、システムアドミニストレータ、幹部職員、人事担当役員、契約者、システムインテグレータなどのスーパーユーザのアクセスクレデンシャルを用いたインサイダーによる特権アカウントの不正使用に弱い。加えて、外部の脅威は一般的に、先ず低レベルユーザアカウントを侵害し、最終的には企業システム内の特権ユーザアクセス制御に到達してこれを利用する。したがって、一実施形態は、PAMを提供することにより、このような不正なインサイダーによるアカウントの使用を防止する。PAMソリューションの主要コンポーネントはパスワードボールト(password vault)であり、これはさまざまなやり方で供給し得る。たとえば、企業サーバ上にインストールされるソフトウェアとして、これも企業サーバ上の仮想アプライアンスとして、パッケージングされたハードウェア/ソフトウェアアプライアンスとして、または、クラウドサービスの一部として、さまざまなやり方で供給し得る。PAM機能は、エンベロープ内で保持されサインインおよびサイン・アウトのためのマニフェストで定期的に変更されるパスワードを格納するために使用される物理的な安全場所と同様である。一実施形態は、パスワードのチェックアウトだけでなく、タイムリミットの設定、強制的な期間変更、自動的なチェックアウトの追跡、およびすべてのアクティビティに関する報告を、可能にする。一実施形態は、要求されたリソースに、ユーザがパスワードを知らない状態で、直接接続する方法を提供する。この機能はまた、セッション管理およびその他の機能の方法に道を開く。
一般的に、ほとんどのクラウドサービスは、APIおよび管理インターフェイスを利用している。これらは、侵入者がセキュリティを迂回する機会を与える。したがって、一実施形態は、PAMの実施におけるこれらの欠陥を埋める。クラウドへの移行によってPAMに新たな課題が発生するからである。小規模から中規模の多くのビジネスは現在自身のSaaSシステム(たとえばOffice 365)を管理しているが、大企業は自身のSaaSおよびIaaSサービスの回転数を上げる個々のビジネス単位を持つことが増えている。これらの顧客は、PAM機能がアイデンティティクラウドサービスソリューションに含まれるかまたはそのIaaS/PaaSプロバイダから得られるが、この責務を扱った経験がほとんどない。加えて、場合によっては、多くの異なる地理的に分散したビジネス単位が、同じSaaSアプリケーションの管理責任を分離しようとする。したがって、一実施形態は、こういった状況にある顧客が、既存のPAMをアイデンティティクラウドサービスの全体的なアイデンティティフレームワークの中にリンクさせ、より高い安全性とコンプライアンスに向けて、ビジネスニーズが要求するクラウドロード条件に合わせて確実に調整することを、可能にする。
APIプラットフォーム
実施形態が提供するAPIプラットフォームは、機能のコレクションをサービスとしてエクスポーズする。APIはマイクロサービスに集約され、各マイクロサービスは、1つ以上のAPIをエクスポーズする。すなわち、各マイクロサービスは異なる種類のAPIをエクスポーズし得る。一実施形態において、各マイクロサービスはそのAPIを通してしか通信しない。一実施形態において、各APIはマイクロサービスであってもよい。一実施形態において、複数のAPIが1つのサービスに、このサービスが提供するターゲット機能に基づいて集約される(たとえばOAuth、SAML、Adminなど)。結果として、同様のAPIは別々のランタイムプロセスとしてエクスポーズされない。APIは、IDCSが提供するサービスを使用するためにサービス顧客が利用できるようにされるものである。
一般的に、IDCSのウェブ環境において、URLは、3つの部分として、ホストと、マイクロサービスと、リソースとを含む(たとえばホスト/マイクロサービス/リソース)。一実施形態において、マイクロサービスは、特定のURLプレフィックスを有することを特徴とし(たとえば「host/oauth/v1」)、実際のマイクロサービスは「oauth/v1」である。「oauth/v1」の下で複数のAPIが存在し、たとえば、トークン(token)を要求するためのAPI:「host/oauth/v1/token」、ユーザを認証する(authorize)ためのAPI:「host/oauth/v1/authorize」などである。すなわち、URLはマイクロサービスを実現し、URLのリソース部分はAPIを実現する。したがって、同じマイクロサービスの下で複数のAPIが集約される。一実施形態において、URLのホスト部分はテナントを特定する(たとえばhttps://tenant3.identity.oraclecloud.com:/oauth/v1/token)。
必要なエンドポイントを有する外部サービスと統合するアプリケーションを構成し当該構成を最新状態に保つことは、一般的に難題である。この難題を克服するために、実施形態は、パブリックディスカバリAPIを周知の場所にエクスポーズし、そこから、アプリケーションは、ADCS APIを消費するために必要なIDCSに関する情報を発見する(discover)ことができる。一実施形態において、2つのディスカバリ文献がサポートされ、それらは、IDCS構成(たとえば、<IDCS-URL>/.well-known/idcs-configurationのIDCS、SAML、SCIM、OAuth、およびOpenID Connect構成を含む)と、(たとえば<IDCS-URL>/.well-known/openid-configurationの)産業標準OpenID Connect構成とである。アプリケーションは、単一のIDCS URLで構成されることにより、ディスカバリ文献を取り出すことができる。
図6は、一実施形態におけるIDCSのシステムビュー600を提供するブロック部である。図6において、さまざまなアプリケーション/サービス602のうちのいずれも、IDCS APIに対してHTTPコールを行うことにより、IDCSサービスを使用することができる。このようなアプリケーション/サービス602の例は、ウェブアプリケーション、ネイティブアプリケーション(たとえばWindows(登録商標)アプリケーション、iOS(登録商標)アプリケーション、アンドロイド(登録商標)アプリケーションなど、特定のオペレーティングシステム上で走るように構築されたアプリケーション)、ウェブサービス、顧客アプリケーション、パートナーアプリケーション、または、サービスとしてのソフトウェア(Software as a Service:「SaaS」)、PaaS、およびサービスとしてのインフラストラクチャ(Infrastructure as a Service:「IaaS」)など、パブリッククラウドによって提供されるサービスである。
一実施形態において、IDCSサービスを要求するアプリケーション/サービス602のHTTP要求は、オラクルパブリッククラウドBIG−IPアプライアンス604およびIDCS BIG−IPアプライアンス606(またはロードバランサなどの同様の技術、または、適切なセキュリティルールを実現してトラフィックを保護するサービスとしてのクラウドロードバランサ(Cloud Load Balancer as a Service:「LBaaS」)と呼ばれているコンポーネント)を通る。しかしながら、この要求はどのようなやり方で受信されてもよい。IDCS BIG−IPアプライアンス606(または、適用できる場合は、ロードバランサまたはクラウドLBaaSなどの同様の技術)において、クラウドプロビジョニングエンジン608は、テナントおよびサービスの調整を実行する。一実施形態において、クラウドプロビジョニングエンジン608は、クラウドにオンボードされている新たなテナントに対応付けられた内部セキュリティアーティファクト、または、顧客が購入した新たなサービスインスタンスを管理する。
このHTTP要求は次にIDCSウェブルーティング層610によって受信される。このルーティング層は、セキュリティゲート(すなわちクラウドゲート)を実現し、サービスルーティングならびにマイクロサービス登録および発見612を提供する。要求されるサービスに応じて、HTTP要求は、IDCS中間層614のIDCSマイクロサービスに転送される。IDCSマイクロサービスは、外部および内部HTTP要求を処理する。IDCSマイクロサービスは、プラットフォームサービスおよびインフラストラクチャサービスを実現する。IDCSプラットフォームサービスは、IDCSのビジネスを実現する、別々にデプロイされたJavaベースのランタイムサービスである。IDCSインフラストラクチャサービスは、IDCSに対してインフラストラクチャサポートを提供する、別々にデプロイされたランタイムサービスである。IDCSはさらに、IDCSサービスによって使用される共有ライブラリとしてパッケージングされた共通コードであるインフラストラクチャライブラリと、共有ライブラリとを含む。インフラストラクチャサービスおよびライブラリは、プラットフォームサービスがその機能を実現するために要求するサポート機能を提供する。
プラットフォームサービス
一実施形態において、IDCSは標準認証プロトコルをサポートし、したがって、IDCSマイクロサービスは、OpenID Connect、OAuth、SAML2、クロスドメインアイデンティティ管理のためのシステム(System for Cross-domain Identity Management++:「SCIM++」)などのプラットフォームサービスを含む。
OpenID Connectプラットフォームサービスは、標準OpenID Connectログイン/ログアウトフローを実現する。対話型のウェブベースおよびネイティブアプリケーションは、標準のブラウザベースのOpenID Connectフローを推進することによりユーザ認証を要求し、ユーザの認証されたアイデンティティを伝達するJavaScript(登録商標)オブジェクト表記(JavaScript Object Notation(「JSON」)ウェブトークン(Web Token「JWT」)である標準アイデンティティトークンを受信する。内部において、ランタイム認証モデルはステートレスであり、ユーザの認証/セッション状態をホストHTTPクッキー(JWTアイデンティティトークンを含む)の形態で維持する。OpenID Connectプロトコルを介して開始された認証対話は、ローカルおよび連携ログインのためにユーザのログイン/ログアウトセレモニーを実現する信頼できるSSOサービスに委任される。この機能のさらなる詳細は以下において図10および図11を参照しながら開示される。一実施形態において、OpenID Connect機能は、たとえばOpenID Foundation標準に従って実現される。
OAuth2プラットフォームサービスは、トークン認可サービスを提供する。これは、ユーザの権利を伝達するアクセストークンを作成し検証してAPIコールを行うためのリッチなAPIインフラストラクチャを提供する。これは、ある範囲の有用なトークン付与タイプをサポートし、顧客がクライアントをそのサービスに安全に接続することを可能にする。これは、標準の2者間および3者間OAuth2トークン付与タイプを実現する。OpenID Connect(「OIDC」)をサポートすることにより、コンプライアントなアプリケーション(OIDCリレーパーティ(「RP」))が、アイデンティティプロバイダとしてのIDCSと統合されることを可能にする(OIDC OpenIDプロバイダ(「OP」)。同様に、OIDC RPとしてのIDCSをソーシャルOIDC OP(たとえばFacebook(登録商標)、Google(登録商標)など)と統合することにより、顧客は、アプリケーションに対する社会的アイデンティのポリシーベースアクセスを可能にする。一実施形態において、OAuth機能は、たとえば、インターネットエンジニアリングタスクフォース(Internet Engineering Task Force:「IETF」)、コメント要求(Request for Comments:「RFC」)6749に従って実現される。
SAML2プラットフォームサービスは、アイデンティティ連携サービスを提供する。これは、顧客が、SAMLアイデンティティプロバイダ(identity provider:「IDP」)およびSAMLサービスプロバイダ(service provider:「SP」)関係モデルに基づいて、そのパートナーとの連携合意を設定することを可能にする。一実施形態において、SAML2プラットフォームサービスは、標準SAML2ブラウザポストログインおよびログアウトプロファイルを実現する。一実施形態において、SAML機能は、たとえばIETF、RFC7522に従って実現される。
SCIMは、ユーザアイデンティ情報を、たとえばIETF、RFC 7642、7643、7644によって提供される、アイデンティティドメインまたは情報技術(「IT」)システム間でのユーザアイデンティティ情報の交換を自動化するためのオープン標準である。SCIM++プラットフォームサービスは、アイデンティティ管理サービスを提供し、顧客がIDCSのIDPフィーチャー(feature)にアクセスすることを可能にする。管理サービスは、アイデンティティライフサイクル、パスワード管理、グループ管理などをカバーするステートレスなRESTインターフェイス(すなわちAPI)のセットをエクスポーズし、ウェブアクセス可能なリソースのようなアーティファクトをエクスポーズする。
すべてのIDCS構成アーティファクトはリソースであり、管理サービスのAPIは、IDCSリソース(たとえばユーザ、ロール、パスワードポリシー、アプリケーション、SAML/OIDCアイデンティティプロバイダ、SAMLサービスプロバイダ、キー、証明、通知テンプレートなど)の管理を可能にする。管理サービスは、SCIM標準を強化および拡張することにより、すべてのIDCSリソースに対する作成(Create)、読み取り(Read)、更新(Update)、削除(Delete)、および問合せ(Query)(「CRUDQ」)動作のためにスキーマベースのREST APIを実現する。加えて、IDCS自体の管理および構成に使用されるIDCSのすべての内部リソースは、SCIMベースのREST APIとしてエクスポーズされる。アイデンティティストア618へのアクセスはSCIM++APIに分離される。
一実施形態において、たとえば、SCIM標準は、SCIM規格によって規定されるユーザおよびグループリソースを管理するように実現されるのに対し、SCIM++は、SCIM規格によって規定される言語を用いてさらに他のIDCS内部リソース(たとえばパスワードポリシー、ロール、設定など)をサポートするように構成される。
管理サービスは、SCIM2.0標準エンドポイントを、標準SCIM2.0コアスキーマと、必要に応じてスキーマ拡張とを用いてサポートする。加えて、管理サービスは、いくつかのSCIM2.0準拠エンドポイント拡張をサポートすることにより、その他のIDCリソースを、たとえばユーザ、グループ、アプリケーション、設定などを、管理する。管理サービスはまた、CRUDQ動作は実行しないがその代わりに機能サービスを、たとえば「UserPasswordGenerator」、「UserPasswordValidator」などを提供する、リモートプロシージャコールスタイル(remote procedure call-style:「RPCスタイル」)RESTインターフェイスのセットをサポートする。
IDCS管理APIは、OAuth2プロトコルを認証および認可に使用する。IDCSは、ウェブサーバ、モバイル、およびJavaScriptアプリケーションのためのシナリオといった共通のOAuth2シナリオをサポートする。IDCS APIへのアクセスはアクセストークンによって保護される。IDCS管理APIにアクセスするために、アプリケーションは、IDCS管理コンソールを通してOAuth2クライアントとしてまたはIDCSアプリケーションとして(この場合OAuth2クライアントは自動的に作成される)登録される必要があり、また、所望のIDCS管理ロールを与えられる必要がある。IDCS管理APIコールを行うとき、アプリケーションは先ず、IDCS OAuth2サービスにアクセストークンを要求する。このトークンを取得した後に、このアプリケーションはアクセストークンを、そこにHTTP認可ヘッダを含めて送信する。アプリケーションは、IDCS管理REST APIを直接使用することができる、または、IDCSJavaクライアントAPIライブラリを使用することができる。
インフラストラクチャサービス
IDCSインフラストラクチャサービスは、IDCSプラットフォームサービスの機能をサポートする。これらのランタイムサービスは、(ユーザ通知、アプリケーション申込、およびデータベースに対する監査を非同期的に処理するための)イベント処理サービスと、(ジョブをスケジューリングして実行するため、たとえば、ユーザの介入が不要な長時間実行タスクを直ちに実行するまたは設定時間に実行するための)ジョブスケジューラサービスと、キャッシュ管理サービスと、(パブリッククラウドストレージサービスと統合するための)ストレージ管理サービスと、(レポートおよびダッシュボードを生成するための)レポートサービスと、(内部ユーザ認証およびSSOを管理するための)SSOサービスと、(異なる種類のユーザインターフェイス(user interface:「UI」)クライアントをホストするための)ユーザインターフェイス(「UI」)サービスと、サービスマネージャサービスとを含む。サービスマネージャは、オラクルパブリッククラウドとIDCSとの間の内部インターフェイスである。サービスマネージャは、オラクルパブリッククラウドによって発行されたコマンドを管理し、このコマンドはIDCSによって実現される必要がある。たとえば、顧客が、何かを購入できる状態になる前にクラウドストア内のアカウントに対してサインアップした場合、クラウドは、テナントを作成することを依頼するための要求をIDCSに送信する。この場合、サービスマネージャは、IDCSがサポートするとクラウドが予測するクラウド固有の動作を実現する。
IDCSマイクロサービスは、ネットワークインターフェイスを通して別のIDCSマイクロサービスをコールしてもよい(すなわちHTTP要求)。
一実施形態において、IDCSはまた、データベーススキーマを使用できるようにするスキーマサービス(またはパーシステンス(persistence)サービス)を提供し得る。スキーマサービスは、データベーススキーマを管理する責任をIDCSに委任することを可能にする。したがって、IDCSのユーザはデータベースを管理する必要がない。なぜなら、この機能を提供するIDCSサービスが存在するからである。たとえば、ユーザは、データベースを用いてテナントごとにスキーマをパーシストしてもよく、データベース内にスペースがなくなったときにはスキーマサービスが、ユーザがデータベースを自身で管理しなくてもよいように、別のデータベースを取得し上記空間を拡大するという機能を管理する。
IDCSはさらに、IDCSが必要とする/生成するデータリポジトリであるデータストアを含む。これは、(ユーザ、グループなどを格納する)アイデンティティストア618、(IDCSが自身を構成するために使用する構成データを格納する)グローバルデータベース620、(テナントごとにスキーマを分離し顧客ごとに顧客データを格納する)オペレーショナルスキーマ622、(監査データを格納する)監査スキーマ624、(キャッシュされたオブジェクトを格納することにより実施速度を高める)キャッシングクラスタ626などを含む。内部および外部のすべてのIDCSコンシューマは、標準ベースのプロトコルに従ってアイデンティティサービスと統合される。これにより、ドメインネームシステム(domain name system:「DNS」)を用いて、どこに要求をルーティングすべきかを決定することができ、アプリケーションを消費することをアイデンティティサービスの内部実現を理解することから切離す。
リアルタイムおよびニア・リアルタイムタスク
IDCSは、要求されたサービスのタスクを、同期リアルタイムタスクと非同期ニア・リアルタイムタスクとに分離する。リアルタイムタスクは、ユーザが進むのに必要なオペレーションのみを含む。一実施形態において、リアルタイムタスクは、最少の遅延で実行されるタスクであり、ニア・リアルタイムタスクは、バックグラウンドにおいて、ユーザが待つことなく実行されるタスクである。一実施形態において、リアルタイムタスクは、実質的に遅延なしでまたはごくわずかな遅延で実行されるタスクであり、ユーザには、ほぼ瞬時に実行されているように見えるタスクである。
リアルタイムタスクは、特定のアイデンティティサービスの主要なビジネス機能を実行する。たとえば、ログインサービスを要求するとき、アプリケーションは、メッセージを送信してユーザのクレデンシャルを認証しそれに対するセッションクッキーを取得する。ユーザが体験するのは、システムへのログインである。しかしながら、ユーザのログインに関しては、ユーザが誰であるかの検証、監査、通知の送信など、その他いくつかのタスクが実行されるであろう。したがって、クレデンシャルの検証は、ユーザがHTTPクッキーを与えられてセッションを開始するように、リアルタイムで実行されるタスクであるが、通知(たとえば電子メールを送信してアカウント作成を通知すること)、監査(たとえば追跡/記録)などに関連するタスクは、ユーザが最少の遅延で進むことができるよう非同期的で実行することができるニア・リアルタイムタスクである。
マイクロサービスを求めるHTTP要求が受信されると、対応するリアルタイムタスクが中間層のマイクロサービスによって実行され、必ずしもリアルタイム処理を受けない演算ロジック/イベントなどの残りのニア・リアルタイムタスクは、メッセージキュー628にオフロードされる。メッセージキュー628は、配信および処理が保証された状態でスケーラビリティが高い非同期イベント管理システム630をサポートする。したがって、特定の挙動は、フロントエンドからバックエンドにプッシュされることにより、IDCSが、応答時間のレイテンシを少なくすることにより、ハイレベルサービスを顧客に提供することを、可能にする。たとえば、ログインプロセスは、クレデンシャルの検証、ログレポートの提出、最後のログイン時間の更新などを含み得るが、これらのタスクは、メッセージキューにオフロードして、リアルタイムではなくニア・リアルタイムで実行することができる。
一例において、システムが新たなユーザを登録または作成する必要がある場合がある。システムは、IDCS SCIM APIをコールしてユーザを作成する。最終結果として、ユーザがアイデンティティストア618において作成されたときにこのユーザがそのパスワードをリセットするためのリンクを含む通知電子メールを得る。IDCSが、新たなユーザを登録または作成することを求める要求を受けると、対応するマイクロサービスは、オペレーショナルデータベース(図6のグローバルデータベース620内に位置する)にある構成データに注目し、「ユーザ作成」という動作が「ユーザ作成」イベントでマーキングされていると判断する。この動作は、構成データにおいて非同期動作であることが識別される。マイクロサービスは、クライアントに戻り、ユーザの作成が正常に行われたことを示すが、通知電子メールの実際の送信は延期されバックエンドにプッシュされる。そうするために、マイクロサービスは、メッセージングAPI616を用いてこのメッセージを、ストアであるキュー628に入れる。
キュー628から出すために、インフラストラクチャマイクロサービスであるメッセージングマイクロサービスは、バックグラウンドにおいて継続的に実行され、キュー628の中にあるイベントを探してキュー628をスキャンする。キュー628の中にあるイベントは、監査、ユーザ通知、アプリケーション申込、データ解析などのイベントサブスクライバ630によって処理される。イベントによって示されるタスクに応じて、イベントサブスクライバ630は、たとえば、監査スキーマ624、ユーザ通知サービス634、アイデンティティイベントサブスクライバ632などと通信し得る。たとえば、メッセージングマイクロサービスは、キュー628の中に「ユーザ作成」イベントを発見した場合、対応する通知ロジックを実行し対応する電子メールをユーザに送信する。
一実施形態において、キュー628は、マイクロサービス614によってパブリッシュされたオペレーショナルイベントと、IDCSリソースを管理するAPI616によってパブリッシュされたリソースイベントとをキューの中に入れる。
IDCSは、リアルタイムキャッシング構造を用いてシステムパフォーマンスおよびユーザ体験を向上させる。キャッシュそのものは、マイクロサービスとしても提供される。IDCSは、IDCSによってサポートされている顧客の数の増加に伴って増大するエラスティック・キャッシュクラスタ626を実現する。キャッシュクラスタ626は、以下でより詳細に開示される分散型データグリッドで実現されてもよい。一実施形態において、書込専用リソースがキャッシュをバイパスする。
一実施形態において、IDCSランタイムコンポーネントは、ヘルスおよびオペレーショナルメトリクスを、オラクル社のオラクルパブリッククラウドなどのパブリッククラウドのこのようなメトリクスを収集するパブリッククラウドモニタリングモジュール636に対してパブリッシュする。
一実施形態において、IDCSを用いてユーザを作成してもよい。たとえば、クライアントアプリケーション602は、REST APIコールを発行してユーザを作成してもよい。管理サービス(614のプラットフォームサービス)は、このコールをユーザマネージャ(614のインフラストラクチャライブラリ/サービス)に委任する。そうすると、ユーザマネージャは、このユーザを、IDストア618内の特定テナント用IDストアストライプにおいて作成する。「ユーザ作成成功(User Create Success)」の場合、ユーザマネージャは、オペレーションを監査することにより監査スキーマ624内のテーブルを監査し、メッセージキュー628に対して「identity.user.create.success」をパブリッシュする。アイデンティティサブスクライバ632は、このイベントをピックアップし、新たに作成されたログイン詳細を含む「ウェルカム」電子メールを、新たに作成されたユーザに送信する。
一実施形態において、IDCSを用いてロールをユーザに与えて、その結果ユーザがアクションをプロビジョニングしてもよい。たとえば、クライアントアプリケーション602は、REST APIコールを発行してユーザにロールを付与してもよい。管理サービス(614のプラットフォームサービス)は、このコールをロールマネージャ(614のインフラストラクチャライブラリ/サービス)に委任してもよい。このロールマネージャは、IDストア618内の特定テナント用IDストアストライプにおけるロールを付与する。「ロール付与成功(Role Grant Success)」の場合、ロールマネージャは、監査スキーマ624における監査テーブルに対するオペレーションを監査し、メッセージキュー628に対して「identity.user.role.grant.success」をパブリッシュする。アイデンティティサブスクライバ632は、このイベントをピックアップしプロビジョニング付与ポリシーを評価する。付与されているロールに対するアクティブなアプリケーション付与があった場合、プロビジョニングサブスクライバは、何らかの検証を実行し、アカウント作成を開始し、ターゲットシステムをコールアウトし、ターゲットシステムにアカウントを作成し、アカウント作成が成功したとマーキングする。これらの機能各々の結果として、「prov.account.create.initiate」、「prov.target.create.initiate」、「prov.target.create.success」または「prov.account.create.success」などの対応するイベントがパブリッシュされることになり得る。これらのイベントは、直近N日間でターゲットシステムにおいて作成されたアカウントの数を合計する自身のビジネスメトリクスを有し得る。
一実施形態において、IDCSはユーザのログインのために使用することができる。たとえば、クライアントアプリケーション602は、サポートされている認証フローのうちの1つを用いてユーザのログインを要求してもよい。IDCSは、ユーザを認証し、成功すると、監査スキーマ624における監査テーブルに対するオペレーションを監査する。失敗すると、IDCSは、監査スキーマ624における失敗を監査し、メッセージキュー628の「login.user.login.failure」イベントをパブリッシュする。ログインサブスクライバは、このイベントをピックアップし、ユーザに対するそのメトリクスを更新し、ユーザのアクセス履歴についての追加分析を実行する必要があるか否かを判断する。
したがって、「制御の反転」機能を実現する(たとえば実行の流れを変更することにより、後の時点におけるオペレーションの実行を、当該オペレーションが別のシステムの支配下になるように、スケジュールする)ことにより、実施形態は、その他のイベントキューおよびサブスクライバを動的に追加して、小さなユーザサンプルに対する新たな特徴を、より広いユーザベースにデプロイする前にテストする、または、特定の内部または外部の顧客のための特定のイベントを処理することができる。
ステートレス機能
IDCSマイクロサービスはステートレスである。これは、マイクロサービスそのものはステートを保持しないことを意味する。「ステート」とは、アプリケーションがその機能を果たすために使用するデータのことを言う。IDCSは、マルチテナント機能を、すべてのステートを、IDCSデータ層内の特定テナント向けリポジトリにパーシストすることによって提供する。中間層(すなわち要求を処理するコード)は、アプリケーションコードと同じ場所に格納されているデータを有しない。したがって、IDCSは横方向および縦方向双方においてスケーラビリティが高い。
縦方向のスケーリング(またはスケールアップ/ダウン)は、システム内の1つのノードにリソースを追加する(またはこのノードからリソースを削除する)ことを意味し、1つのコンピュータにCPUまたはメモリを追加することを伴うのが一般的である。縦方向のスケーラビリティによって、アプリケーションはそのハードウェアの限界までスケールアップすることができる。横方向のスケーリング(またはスケールアウト/イン)は、新たなコンピュータを分散型ソフトウェアアプリケーションに追加するといったように、より多くのノードをシステムに追加する(またはシステムからノードを削除する)ことを意味する。横方向のスケーラビリティにより、アプリケーションはほぼ無限にスケーリング可能であり、ネットワークによって提供される帯域幅の量のみの制約を受ける。
IDCSの中間層がステートレスであることにより、CPUをさらに追加するだけで横方向にスケーラブルになり、アプリケーションの仕事を実行するIDCSコンポーネントは、特定なアプリケーションが走っている指定された物理的インフラストラクチャを持つ必要がない。IDCSの中間層がステートレスであることにより、非常に多くの顧客/テナントにアイデンティティサービスを提供しているときであっても、IDCSの可用性が高くなる。IDCSアプリケーション/サービスを通る各パスは、専らアプリケーショントランザクションを実行するためにCPU用途に集中するが、データの格納にハードウェアを使用しない。スケーリングは、必要に応じてより多くのコピーを追加できるパーシステンス層にトランザクション用のデータが格納される一方で、アプリケーションが走っているときにより多くのスライスを追加することによって実現される。
IDCSウェブ層、中間層、およびデータ層は各々独立してかつ別々にスケーリング可能である。ウェブ層をスケーリングすることにより、より多くのHTTP要求を扱うことができる。中間層をスケーリングすることにより、より多くのサービス機能をサポートすることができる。データ層をスケーリングすることにより、より多くのテナントをサポートすることができる。
IDCS機能ビュー
図6Aは、一実施形態におけるIDCSの機能ビューのブロック図の一例600bである。ブロック図600bにおいて、IDCS機能スタックは、サービスと、共有ライブラリと、データストアとを含む。サービスは、IDCSプラットフォームサービス640bと、IDCSプレミアムサービス650bと、IDCSインフラストラクチャサービス662bとを含む。一実施形態において、IDCSプラットフォームサービス640bおよびIDCSプレミアムサービス650bは、別々にデプロイされたJavaベースのランタイムサービスであり、IDCSのビジネスを実現する。IDCSインフラストラクチャサービス662bは、別々にデプロイされたランタイムサービスであり、IDCSに対するインフラストラクチャサポートを提供する。共有ライブラリは、IDCSサービスによって使用される共有ライブラリとしてパッケージングされた共通コードであるIDCSインフラストラクチャライブラリ680bと、共有ライブラリとを含む。データストアは、IDCSが必要とする/生成するデータリポジトリであり、アイデンティティストア698b、グローバル構成700b、メッセージストア702b、グローバルテナント704b、パーソナライゼーション設定706b、リソース708b、ユーザ一時データ710b、システム一時データ712b、テナントごとのスキーマ(管理されたExaData)714b、オペレーショナルストア(図示せず)、キャッシングストア(図示せず)などを含む。
一実施形態において、IDCSプラットフォームサービス640bは、たとえばOpenID Connectサービス642b、OAuth2サービス644b、SAML2サービス646b、およびSCIM++サービス648bを含む。一実施形態において、IDCSプレミアムサービスは、たとえば、クラウドSSOおよびガバナンス652b、企業ガバナンス654b、AuthNブローカー656b、連携ブローカー658b、およびプライベートアカウント管理660bを含む。
IDCSインフラストラクチャサービス662bおよびIDCSインフラストラクチャライブラリ680bは、IDCSプラットフォームサービス640bがその仕事を実行するのに必要とする機能のサポートを提供する。一実施形態において、IDCSインフラストラクチャサービス662bは、ジョブスケジューラ664b、UI666b、SSO668b、レポート670b、キャッシュ672b、ストレージ674b、サービスマネージャ676b(パブリッククラウド制御)、およびイベントプロセッサ678b(ユーザ通知、アプリケーション申込、監査、データ解析)を含む。一実施形態において、IDCSインフラストラクチャライブラリ680bは、データマネージャAPI682b、イベントAPI684b、ストレージAPI686b、認証API688b、認可API690b、クッキーAPI692b、キーAPI694b、およびクレデンシャルAPI696bを含む。一実施形態において、クラウド計算サービス602b(内部Nimbula)は、IDCSインフラストラクチャサービス662bおよびIDCSインフラストラクチャライブラリ680bの機能をサポートする。
一実施形態において、IDCSは、顧客エンドユーザUI604b、顧客管理UI606b、DevOps管理UI608b、およびログインUI610bなど、IDCSサービスのコンシューマのためのさまざまなUI602bを提供する。一実施形態において、IDCSは、アプリケーション(たとえば顧客アプリケーション614b、パートナーアプリケーション616b、およびクラウドアプリケーション618b)の統合612bならびにファームウェア統合620bを可能にする。一実施形態において、さまざまな環境がIDCSと統合されてそのアクセス制御のニーズをサポートしてもよい。このような統合は、たとえば、アイデンティティブリッジ622b(AD統合、WNA、およびSCIMコネクタを提供)、アパッチエージェント624b、またはMSFTエージェント626bによって提供される。
一実施形態において、内部および外部のIDCSコンシューマは、OpenID Connect630b、OAuth2 632b、SAML2 634b、SCIM636b、およびREST/HTTP638bなどの標準ベースのプロトコル628bに対するIDCSのアイデンティティサービスと統合される。これにより、ドメインネームシステム(domain name system:「DNS」)を用いて、要求をどこにルーティングするかを判断することができ、アプリケーションの消費を、アイデンティティサービスの内部実現を理解することから切離す。
図6AのIDCS機能ビューはさらに、IDCSが、ユーザ通知(クラウド通知サービス718b)、ファイルストレージ(クラウドストレージサービス716b)、およびDevOPsのためのメトリクス/警告(クラウドモニタサービス(EM)722bおよびクラウドメトリクスサービス(グラファイト)720b)のために依存する共通機能を提供する、パブリッククラウドインフラストラクチャサービスを含む。
クラウドゲート
一実施形態において、IDCSはウェブ層において「クラウドゲート」を実現する。一実施形態において、クラウドゲートは、ウェブアプリケーションがユーザSSOをアイデンティティ管理システム(たとえばIDCS)に外部化することを可能にするウェブサーバプラグインによって実現され、これは、企業IDMスタックと協力するWebGateまたはWebAgent技術と同様である。一実施形態において、クラウドゲートは、IDCS APIに対するアクセスを安全にするセキュリティゲートキーパの役割を果たす。一実施形態において、クラウドゲートは、OAuthに基づいてHTTPリソースを保護するためにウェブポリシー施行点(Policy Enforcement Point:「PEP」)を提供するウェブ/プロキシサーバプラグインによって実現される。一実施形態において、クラウドゲートは認証も行う(たとえばOAuth認証)。
一実施形態において、クラウドゲートをデプロイすることにより、シングルテナントアプリケーションまたはマルチテナントアプリケーションを保護することができる。また、クラウドゲートは、プロキシモードのフロントエンドの各種アプリケーションにおいてデプロイすることができる。一実施形態において、クラウドゲートは、シングルテナントアプリケーションおよびマルチテナントアプリケーションを、<Tenant>(どのようなテナントがクラウドゲートインスタンスを所有するかを表す)および<Host Identifier>(どのようなアプリケーションがアクセスされているかを表す)についてそれぞれのデフォルト構成を使用することにより、サポートすることができる。一実施形態において、ローカル構成は、これらのアーティファクトについてデフォルト値を指定する。また、ローカル構成は、ルーティング層から与えられるHTTPヘッダを介して、要求ごとに上書きすることができる。たとえば、マルチテナントアプリケーションの場合、<Tenant>は、クラウドゲートのテナンシーを規定し、IDCSサーバにコンタクトするときにIDCSサービスのURLを構成するために使用され、<tenant-name>(たとえば「acme」)を含む任意のX-RESOURCE-IDENTITY-DOMAIN-NAMEヘッダにより、要求ごとに上書きすることができる。さらに、マルチテナントアプリケーションの場合、<Host Identifier>は、クッキードメインを規定し、ローカルセッションクッキーを管理するために使用され、クライアントまたはルーティング層(たとえば「acme.pcs1.dc4.oraclecloud.com」)から与えられる任意の「ホスト」ヘッダにより、要求ごとに上書きすることができる。
一実施形態において、クラウドゲートの1つのインスタンスをテナントごとにデプロイする。しかしながら、代替実施形態において、たとえばレプリケーションおよびフェイルオーバーを提供する高可用性サーバクラスタにおいて、あるテナントに対してデプロイされたクラウドゲートのインスタンスが複数存在していてもよい。一実施形態において、クラウドゲートはマルチテナントモードを提供する。マルチテナントモードは、たとえば、「インフラストラクチャ」クラウドゲートが(テナントのアプリケーションの前ではなく)IDCS自体の前にあり複数のテナントからの要求をIDCSサービスに送る前に処理するときに、1つのクラウドゲートインスタンスが複数のテナントをサポートすることを可能にする。
一実施形態において、クラウドゲートは、特定のテナントを、送られてきた要求のヘッダ値から判断することにより、マルチテナンシーをサポートする。クラウドゲートは、さまざまなURLにおけるテナンシーに置き換わり、URLを用いてアプリケーション/ホスト固有のポリシーをルックアップする。クラウドゲートは、要求についてこれらのポリシーを適用し、その情報を用いて要求をIDCSの適切なコンポーネントに送る。
一実施形態において、入力要求に示されているテナントは、置き換えられない(すなわち入力要求は修正されない)が、IDCSサービスに対してクラウドゲート自身が行った要求において使用される(たとえば、ポリシールックアップ、クレデシャル検証など)。一実施形態において、クラウドゲートは、IDCSサービスのURLでプロビジョニングされ、これらのURLは、テナントのプレースホルダ(たとえば「http://%tenant%.idcs.oracle.com」)を有することができる、または、クラウドゲートのテナントを示すことができる。この実施形態において、プレースホルダまたはクラウドゲートのテナントは、入力要求に示されているテナントに置き換えられ、クラウドゲートからIDCSサービスへの要求は、入力要求において指定されたテナントを用いて行われる。
たとえば、クラウドゲートは、企業クラウドにおけるドケッティングアプリケーションを保護している場合がある。このアプリケーションは、要求されているIDCSサービスに属していてもよく(たとえばテナント固有またはユーザ固有の管理コンソールなど、IDCSによって開発されたアプリケーションであってもよい)、または、IDCSのテナントによって開発されたものでもよい。ドケッティングアプリケーションは、IDCSのテナントそれぞれに対応する複数の顧客によって使用されてもよい。顧客は、このアプリケーションにアクセスする必要がある場合、要求をIDCSに送信する。顧客のテナンシーはこの要求のヘッダに示されている。クラウドゲートは、テナンシーをこの要求から推測し、このテナンシーに対して適用する必要がある特定のポリシーをルックアップする。次に、クラウドゲートはこのポリシーを上記要求に適用する。このポリシーが要求の通過を許可する場合、クラウドゲートはテナンシーをアサートし要求がドケッティングアプリケーションに到達できるようにする。一実施形態において、クラウドゲートは、テナンシーを、テナント名とともにヘッダを要求に追加することによってアサートする。そうすると、要求は起点サーバに転送される。一実施形態において、クラウドゲートはこのようにしてテナントのうちのいくつかのみをアサートすることができる。その他のテナントのヘッダは、既に要求に存在しているか、または、前のロードバランシングサーバによって追加されている可能性がある。
一実施形態において、要求のエンドポイントを通して特定された特定のリソースへのアクセスが許可されるか否か、および、どの特定のアクセス方法がリソースへのアクセスの取得のために許可されるかを、ポリシーが規定する。一実施形態において、たとえば、「/admin/v1/HTTPAuthenticator」は、ブラウザベースのHTTP基本認証のためのユーザクレデンシャルを検証するためのエンドポイントであり、この場合のリソースはクレデンシャル検証サービスである。一実施形態において、たとえば、あるテナントに対するパブリックアクセスポリシーは、このテナント内の誰もが、リソース(たとえば、ログインページに対する、公衆に見えるエンドポイントである「/ui/v1/signin」、パスワード変更およびリセットページに対する「/ui/v1/pwdmustchange」および「/ui/v1/resetpwd」など)にアクセスできることを示すことができる。あるテナントに対するパブリックアクセスポリシーが、そのテナント内の誰もがリソースにアクセスできることを示す場合、クラウドゲートは、そのテナンシーからそのリソースにアクセスすることを求める要求が通過できるようにする。別のポリシーが、ユーザに対し、(たとえば基本認証に基づいて)リソースにアクセスするためにユーザ名およびパスワードを提供することを要求する場合があり、ユーザ名およびパスワードは、アイデンティティに照らして検証される。さらに他のポリシーは、OAuthに基づいたトークンベースの認証を要求する場合がある。この場合、リソースは、バックエンドのリソースへのアクセスを取得するためにユーザまたはプログラマティックアプリケーションによって提供されるOAuthアクセストークンを要求する。たとえば、ユーザは、OpenIDフローを開始することにより、OAuthアクセストークンを取得して、リソースへのアクセスを得ることができる、または、クライアントアプリケーションが、リソースへのプログラマティックアクセスを、事前にトークンを取得しそれからこのトークンをそのクレデンシャルとともに提供してリソースへのアクセスを得ることにより、取得することができる。
一実施形態において、ポリシーは、クラウドゲートが管理するファイルに明記されている。一実施形態において、このファイルはクラウドゲートにローカル保存される。代替のまたは追加の実施形態において、このファイルは、IDCS内のサーバ側(たとえばポリシーストア内)に格納することができる。
図7は、クラウドゲート702を実現する実施形態のブロック図700である。クラウドゲート702は、ウェブサーバ712内で実行され、ポリシー施行点(「PEP」)の役割を果たす。ポリシー施行点は、オープン標準(たとえばOAuth2、OpenID Connectなど)を用いるIDCSポリシー決定点(Policy Decision Point:「PDP」)と統合され、一方でウェブブラウザおよびアプリケーションのREST APIリソース714へのアクセスを安全にするように構成されている。いくつかの実施形態において、PDPは、IDCSのOAuthおよび/またはOpenID Connectマイクロサービス704で実現される。
図7の実施形態において、プログラムまたはアプリケーションクライアント708が、クラウドゲート702によって保護されているリソース714にアクセスしようと試みているか、または、エンドユーザ710が、そのコンピュータ上のウェブブラウザ706を利用して、クラウドゲート702によって保護されているリソース714にアクセスする可能性がある。一実施形態において、クラウドゲート702は、リソース714がエンドユーザ710によってアクセスされているかプログラマティックアプリケーションクライアント708によってアクセスされているかに応じて、リソース714の保護のために異なる機能を実現することができる。
一実施形態において、ユーザブラウザ706がユーザ710のログインを求める要求をIDCSに送信すると、対応するIDCS PDPは、クレデンシャルを検証した後に、このクレデンシャルが十分であるか否か(たとえば第2のパスワードなどのその他のクレデンシャルを要求するか否か)を判断する。図7の実施形態において、クラウドゲート702は、ローカルセッションを有するので、PEPとしてもPDPとしてもその役割を果たし得る。一実施形態において、クラウドゲートは、ポリシー施行を処理し如何にしてユーザを認証すべきか(またはユーザを認証すべきか否か)を判断することにより、PEPとして機能する。一実施形態において、クラウドゲートは、(たとえば「パブリック」ポリシーを介して)認証が要求されなければ、または、クラウドゲートのセッションクッキーが存在しこのクッキーの検証をクレデンシャルの検証の代わりに実行できる場合、PDPとして機能することができる。
一実施形態において、たとえば、リソース714にアクセスするために、ユーザ710は、対応するURLをブラウザ706にタイプすることができる。ブラウザ706はユーザ710をウェブサーバ712に導く。そうすると、クラウドゲート702は対応するポリシーをロードする。リソース714が保護されていることをポリシーが示している場合、クラウドゲート702は、必要な認証プロセスを開始する。一実施形態において、クラウドゲート702は、ユーザに直接問いかけるのではなく(すなわち、UIの役割を担っていない)、ユーザが認証のために問いかけられると、クラウドゲート702はユーザのクレデンシャルを検証する(たとえば基本認証)。たとえば、ユーザ710がユーザ名およびパスワードを入力すると、クラウドゲート702は、ユーザ名およびパスワードを、ユーザ710の認証のためにIDCS(たとえばOAuth2)の対応するマイクロサービス704に送信する。認証が成功すれば、クラウドゲート702はユーザ710がリソース714にアクセスできるようにする。
一実施形態において、クラウドゲート702は、HTTP基本認証オーセンティケータとして機能し、HTTP基本認証クレデンシャルを、IDCSに照らし合わせて検証する。この行為は、セッションレスモードでも、セッションベース(ローカルセッションクッキー)モードでもサポートされる。この場合、サーバ側IDCSセッションは生成されない。HTTP基本認証の場合、クラウドゲート702は、HTTP「未認証」ステータスコードをブラウザに戻し、ブラウザはそれに応じてユーザ名/パスワードを促すダイアログを表示する。これらのクレデンシャルはクラウドゲート702にサブミットされ、クラウドゲート702はこれらをIDCSに照らし合わせて認証する。
一実施形態において、OAuthに従う認証のために、クラウドゲート702は、HTTPリダイレクトステータスコードを返す。このコードはブラウザをOAuthマイクロサービスに導く。OAuthマイクロサービスは、SSOマイクロサービスとともに、実際のログインフローを処理する。これは、ログインページをブラウザに表示することと、ユーザから提供されたクレデンシャルを認証することとを含む。ウェブブラウザベースのユーザアクセス中、クラウドゲート702は、ユーザ認証フローを開始するOIDC RP718として機能する。ユーザ710が有効なローカルユーザセッションを有していない場合、クラウドゲート702は、ユーザをSSOマイクロサービスにリダイレクトし、SSOマイクロサービスとともにOIDC「認証コード」フローに参加する。このフローは、アイデンティティトークンとしてのJWTの配信で終了する。クラウドゲート708は、JWTを検証し(たとえば署名、満了、宛先/オーディエンスなどに注目し)、ユーザ710に関するローカルセッションクッキーを発行する。これは、保護されているリソースへのウェブブラウザのアクセスを安全にしかつローカルセッションクッキーを発行、更新、および検証するセッションマネージャ716として機能する。これはまた、そのローカルセッションクッキーの削除のためのログアウトURLを提供する。
一実施形態において、たとえば、クラウドゲート702によって保護されているリソース714にアクセスするために、プログラマティックアプリケーションクライアント708は、ウェブサーバ712に対し、対応する要求を行い、アプリケーションクライアント708は、この要求とともに、OAuthトークンを送信する。クラウドゲート702は、このトークンを受信し、OAuthサービス704に接続することにより、OAuthトークンをOAuth2サービス704に照らし合わせて検証する。トークンが検証されると、クラウドゲート702は、保護されているリソース714にアプリケーションクライアント708がアクセスすることを可能にする。
一実施形態において、アプリケーションクライアント708は、上記トークンを、事前登録プロセス(たとえばアドミニストレータによって実行される)において取得することができる。事前登録プロセスにおいて、アプリケーションクライアント708は、自身を、保護されているリソース714へのアクセスが可能な信頼できるアプリケーションとして、IDCSに登録する。このトークンは、IDCS OAuthマイクロサービスによって生成されてもよい。
ワンタイム・デプロイメントの一部として、クラウドゲート702は、OAuth2クライアントとしてIDCSに登録され、IDCSに対しOIDCおよびOAuth2動作を要求できるようにする。その後、これは、要求マッチングルール(URLをたとえばワイルドカード、正規表現などに対して突き合わせる方法)が適用される、アプリケーションの保護されているリソースおよび保護されていないリソースに関する構成情報を保持する。クラウドゲート702をデプロイすることにより、異なるセキュリティポリシーを有する異なるアプリケーションを保護することができる。保護されているアプリケーションはマルチテナントであってもよい。
REST APIクライアント708によるプログラムアクセス中、クラウドゲート702は、アプリケーションの保護されているREST API714のためのOAuth2リソースサーバ/フィルタ720の役割を果たし得る。これは、認証ヘッダおよびアクセストークンに対して要求が存在するか否かを検査する。クライアント708(たとえばモバイル、ウェブアプリケーション、JavaScriptなど)が(IDCSによって発行された)アクセストークンを、保護されているREST API714とともに使用するために示すと、クラウドゲート702は、APIへのアクセスを許可する前にアクセストークンを検証する(たとえば署名、満了、オーディエンスなど)。元のアクセストークンは修正無しで送られる。
図7Aは、クラウドゲート702Bが如何にしてホスト識別子を処理するかを示す、一例としてのブロック図700Bである。各ホスト識別子は、クラウドゲート702Bによって保護されるアプリケーションに対応付けられた論理ウェブドメインを表す。図7Aの実施形態の例において、サービスとしてのルーティング層(Routing Tier as a Service「RTaaS」)704Bが受けるURLの一般フォーマットは、
https://<tenant>.<service>.<dc>.oraclecloud.com/<resource>
であり、これは、最初にテナンシーを特定し(<tenant>)、次にサービス(<service>)、データセンター(<dc>)、ルートドメイン(<oraclecloud.com>)を特定し、最後にリソースAPIエンドポイントを特定する(<resource>)。一実施形態において、要求処理中のランタイムに、クラウドゲート702Bは、クライアントまたはルーティング層(すなわちRTaaS 704B)から「ホスト」ヘッダを介して与えられたホスト識別子を使用する。ホスト識別子がルーティング層から得られない場合、または一致が発見されない場合、クラウドゲート702Bは、それ自身の「<default host identifier>」からホスト識別子を構成する。一実施形態において、あるアプリケーションについて2つ以上のホスト識別子をIDCSルーティング層が使用してもよく、クラウドゲート702Bを通過する各要求は、ローカルセッションクッキーのスコーピングおよびアクセスポリシーファイルの解明を含む、それぞれのホスト識別子のコンテキストで処理される。たとえば、クラウドゲート702Bは、URLを受けると、対応するホスト識別子を見てどのようなポリシーを適用する必要があるかを判断する。
一実施形態において、RTaaS 704Bは、RTaaS IDCSアカウント708Bにおいて規定されている物理クラウドゲート702Bを各々が有する複数の物理ウェブプロキシを有する。各ウェブプロキシおよびその対応するクラウドゲート702Bは、いくつかの仮想ホスト(たとえば1〜30000の間の仮想ホスト)をサポートする。各仮想ホストは、RTaaS 704Bによって割り当てられたサービスインスタンス706Bごとのウェブ層を表す。各要求に応じて、RTaaS 704Bは、ヘッダに、仮想ホストの名称(たとえば「coke.docs.dc4.oraclecloud.com」、「pepsi.mcs.dc4.oraclecloud.com」、「intel.pcs.dc4.oraclecloud.com」など)を設定する。一実施形態において、クラウドゲート702Bにおけるセッションクッキーは、仮想ホストに対してスコーピングされ、適切な再エントランス機能が実現される。たとえば、クラウドゲート702Bは、「redirect_uri」エンドポイント714BでAZコードを受けてクッキーをセットすることができ、「logout_uri」エンドポイント712Bで要求を受けてクッキーをクリアすることができる。
一実施形態において、各物理クラウドゲートインスタンスは、このクラウドゲートインスタンスのために登録されたOAuthプロファイルにおいて規定されている、対応する固定された「redirect_uri」エンドポイント714Bおよび対応する固定された「logout_uri」エンドポイント712Bを、公開する。URIは、クラウドゲート702BとOIDCとの間のやりとりで使用される。一実施形態において、OIDCは、「redirect_uri」パラメータを、要求の発生元であるクラウドゲートの既知のリダイレクトURIと照らし合わせて検証する。一実施形態において、一致は、ストリング値の比較という点において「正確」である必要はないが、マッチングアルゴリズムとは関係なく、クラウドゲートの同一の物理インスタンスであるという条件を満たす必要がある。一実施形態において、「logout_uri」は、IDCS 710Bに、クラウドゲートの登録されたOAuthプロファイルの一部として、保存され、このクラウドゲートは、そのどのようなやりとりにおいても「logout_uri」をサーバに渡さない。完全に構成されると、「redirect_uri」および「logout_uri」はテナントテンプレートを含むと想定され、各クラウドゲート702BおよびOIDCによって使用される前に変換される。
一実施形態において、クラウドゲート702BとIDCSサーバ710Bとの間のやり取りは、物理クラウドゲート702Bとホスト識別子との組み合わせを、1つの論理Oauth RPとして扱う。クラウドゲート702Bが開始するIDCS OIDCマイクロサービスに対する動作およびIDCS OIDCマイクロサービスが開始するクラウドゲート702Bに対する動作において、ホスト識別子は、「X-HOST-IDENTIFIER-NAME」クエリストリングパラメータを介して送信される。クラウドゲート702Bがログイン/ログアウト要求を呼び出すとき、ホスト識別子のクエリストリングパラメータが、クラウドゲート702Bによって、クライアントまたはルーティング層から受けたホスト識別子のヘッダから送られる。IDCS OIDCマイクロサービスが生成した要求クッキーにおけるRPを追跡しているとき、ホスト識別子のクエリストリングパラメータの値が、要求クッキーにおいてRPごとに保存される。RPの「redirect_uri」および「logout_uri」をIDCS OIDCマイクロサービスが呼び出すとき、ホスト識別子のクエリストリングパラメータが、IDCS OIDCマイクロサービスにより、要求クッキーに保存されたホスト識別子の値から、送信される。
一般的に、OAuthを用いてクライアントアイデンティティ伝播トークン(たとえばクライアントが誰であるかを示す)またはユーザアイデンティティ伝播トークン(たとえばユーザが誰であるかを示す)を生成する。本実施形態において、クラウドゲートにおけるOAuthの実現は、たとえばIETF、RFC7519によって提供されるようなウェブトークンのフォーマットを定めるJWTに基づく。
ユーザがログインすると、JWTが発行される。JWTは、IDCSによって署名され、IDCSにおけるマルチテナント機能をサポートする。クラウドゲートは、IDCSが発行したJWTを検証することにより、IDCSにおけるマルチテナント機能を可能にする。したがって、IDCSは、物理構造においても、セキュリティモデルを支持する論理ビジネスプロセスにおいてもマルチテナンシーを提供する。
テナンシーの種類
IDCSは3種類のテナンシーとして、顧客テナンシー、クライアントテナンシー、およびユーザテナンシーを特定する。顧客またはリソーステナンシーは、IDCSの顧客が誰であるか(すなわち作業が誰に対して実行されているか)を特定する。クライアントテナンシーは、どのクライアントアプリケーションがデータにアクセスしようとしているか(すなわちどのアプリケーションが作業を実行しているか)を特定する。ユーザテナンシーは、どのユーザがアプリケーションを用いてデータにアクセスしているか(すなわち誰によって作業が実行されているか)を特定する。たとえば、専門サービス企業が大型ディスカウントショップを対象とするシステム統合機能を提供しこの大型ディスカウントショップのシステムのアイデンティティ管理を提供するためにIDCSを使用するとき、ユーザテナンシーは、この専門サービス企業に相当し、クライアントテナンシーはシステム統合機能を提供するために使用されるアプリケーションに相当し、顧客テナンシーは大型ディスカウントショップである。
これら3つのテナンシーを分離および統合することによってクラウドベースのサービスにおけるマルチテナント機能が可能になる。一般的に、オンプレミスの物理的なマシンにインストールされているオンプレミスソフトウェアの場合、これら3つのテナンシーを特定する必要はない。なぜなら、ユーザはログインするのに物理的にマシン上にいなければならないからである。しかしながら、クラウドベースのサービス構造の場合、実施形態は、トークンを持いて、誰がどのアプリケーションを使用してどのリソースにアクセスするかを判断する。3つのテナンシーは、トークンによってコーディファイ(codify)され、クラウドゲートによって施行され、中間層のビジネスサービスによって使用される。一実施形態において、OAuthサーバがトークンを生成する。さまざまな実施形態において、このトークンは、OAuth以外のセキュリティプロトコルとともに使用されてもよい。
ユーザ、クライアント、およびリソーステナンシーを分離することにより、IDCSが提供するサービスのユーザには実質的なビジネス上の利点が与えられる。たとえば、そうすることにより、ビジネス(たとえば健康ビジネス)のニーズおよびそのアイデンティティ管理の問題を理解するサービスプロバイダは、IDCSが提供するサービスを購入し、IDCSのサービスを消費する自身のバックエンドアプリケーションを開発し、このバックエンドアプリケーションをターゲットビジネスに提供することができる。したがって、サービスプロバイダは、IDCSのサービスを拡張してその所望の機能を提供するとともにそれらを特定のターゲットビジネスに対して差出すことができる。サービスプロバイダは、ソフトウェアを構築し実行してアイデンティサービスを提供する必要はないが、その代わりに、IDCSのサービスを拡張しカスタマイズしてターゲットビジネスのニーズに合うようにすることができる。
周知のシステムの中には、顧客テナンシーである単一のテナンシーしか説明しないものがある。しかしながら、そのようなシステムは、顧客ユーザ、顧客のパートナー、顧客のクライアント、クライアント自身、または、アクセスが顧客から委任されたクライアントなどのユーザの組み合わせによるアクセスを処理するときには不十分である。本実施形態において複数のテナンシーを規定し施行することにより、これらの多様なユーザに対して管理機能を特定することが容易になる。
一実施形態において、IDCSの1エンティティは、複数のテナントに同時に属しているのではなく、1つのテナントのみに属し、「テナンシー」はアーティファクトが存在する場所である。一般的に、特定の機能を実現するコンポーネントは複数存在し、これらのコンポーネントは複数のテナントに属することが可能であるまたはインフラストラクチャに属することが可能である。インフラストラクチャは、テナントの代わりに機能する必要があるとき、テナントの代わりにエンティティサービスと対話する。この場合、インフラストラクチャそのものは自身のテナンシーを有し、顧客は自身のテナンシーを有する。要求がサブミットされたとき、この要求に関わる複数のテナンシーが存在する。
たとえば、「テナント1」に属するクライアントが、「テナント3」におけるユーザを指定する「テナント2」のためのトークンを取得することを求める要求を実行する場合がある。別の例として、「テナント1」に存在するユーザが、「テナント2」が所有するアプリケーションにおけるアクションを実行する必要がある場合がある。よって、ユーザは、「テナント2」のリソースネームスペースに行きそのためのトークンを要求する必要がある。したがって、権限の委任は、「誰が」「何を」「誰」に対して行うことができるかを特定することによって実現される。もう1つの例として、第1の組織(「テナント1」)のために働く第1のユーザが、第2の組織(「テナント2」)のために働く第2のユーザが第3の組織(「テナント3」)がホストする文書にアクセスすることを、許可してもよい。
一例において、「テナント1」のクライアントは、「テナント3」のアプリケーションにアクセスするために「テナント2」のユーザのためのアクセストークンを要求してもよい。クライアントは、「http://tenant3/oauth/token」に行きこのトークンを求めるOAuth要求を呼び出すことによって当該トークンを要求してもよい。クライアントは、「クライアントアサーション」を要求に含めることにより、自身が「テナント1」に存在するクライアントであることを明らかにする。このクライアントアサーションは、クライアントID(たとえば「クライアント1」)とクライアントテナンシー(「テナント1」)とを含む。「テナント1」の「クライアント1」として、クライアントは、「テナント3」に対するトークンを求める要求を呼び出す権利を有し、「テナント2」のユーザのためのトークンを所望する。したがって、「ユーザアサーション」も同じHTTP要求の一部として送られて「テナント2」をユーザのテナンシーであると特定し、要求のヘッダは、「テナント3」をリソース/アプリケーションのテナンシーであると特定する。その結果、要求は、クライアントのテナンシー、ユーザのテナンシー、およびリソースのテナンシーを特定する。生成されるアクセストークンは、アプリケーションテナンシー(「テナント3」)であるターゲットテナンシーのコンテキストにおいて発行され、ユーザテナンシー(「テナント2」)を含む。したがって、アクセストークンは、リソース/アプリケーションのテナンシーおよびユーザのテナンシーを特定する。
一実施形態において、データ層における各テナントは、独立したストライプとして実現される。データ管理の観点からすると、アーティファクトはテナントに存在する。サービスの観点からすると、サービスは、異種のテナントとどのようにして協力するかを知っており、複数のテナンシーは、サービスのビジネス機能における異なるディメンションである。図8は、ある実施形態において複数のテナンシーを実現するシステムの一例800を示す。システム800はクライアント802を含み、クライアント802は、如何にしてデータベース806のデータ用いて作業するかを理解しているマイクロサービス804が提供するサービスを要求する。データベース806は複数のテナント808を含み、各テナントは対応するテナンシーのアーティファクトを含む。一実施形態において、マイクロサービス804は、「テナント1」のクライアントが、「テナント2」のユーザが「テナント3」のアプリケーションにアクセスするためのトークンを得ようとしてhttps://tenant3/oauth/tokenを通して要求する、OAuthマイクロサービスである。データベース806は、クライアントのテナンシー(「テナント1」)、ユーザのテナンシー(「テナント2」)、およびリソース/アプリケーションのテナンシー(「テナント3」)のデータを格納する。OAuthマイクロサービスの機能が、マイクロサービス804において、データベース806からのデータを用いて実行されることにより、クライアント802の要求が正当であるか否かが検証され、正当である場合は、異なるテナンシー808からのデータが使用されてトークンが構成される。したがって、システム800は、各テナンシーに与えられるサービスをサポートするだけでなく各種テナントに代わって機能し得るサービスをサポートすることによりクロステナント環境において作業できるという点において、マルチテナントである。
システム800は好都合である。理由は次の通りである。マイクロサービス804はデータベース806のデータから物理的に切離されており、クライアントにより近い場所を通ってデータを複製することにより、マイクロサービス804をクライアントに対するローカルサービスとして提供することができ、システム800はサービスのアベイラビリティを管理しそれをグローバルに提供することができる。
一実施形態において、マイクロサービス804はステートレスである。これは、マイクロサービス804を走らせるマシンが、特定のテナントに対するサービスを示すマーカを保持していないことを意味する。その代わりに、テナンシーは、たとえば、入ってくる要求のURLのホスト部分にマーキングされてもよい。このテナンシーはデータベース806のテナント808のうちの1つを示す。多数のテナント(たとえば何百万ものテナント)をサポートする場合、マイクロサービス804は、データベース806への同数の接続を有することはできない。マイクロサービス804はその代わりに、データベースユーザというコンテキストにおいてデータベース806への実際の物理接続を提供する接続プール810を使用する。一般的に、接続は、基礎をなすドライバまたはプロバイダに接続ストリングを提供することによって構築される。接続ストリングは、特定のデータベースまたはサーバをアドレス指定するために、かつ、インスタンスおよびユーザ認証クレデンシャルを与えるために使用される(たとえば「Server=sql_box;Database=Common;User ID=uid;Pwd=password;」)。接続は、一旦構築されると、開閉が可能であり、プロパティ(たとえばコマンドタイムアウト長さ、または存在するのであればトランザクション)を設定することができる。接続ストリングは、データプロバイダのデータアクセスインターフェイスによって指示されるキーと値とのペアのセットを含む。接続プールは、データベースに対する未来の要求が必要なときに接続を再使用できるように保持されるデータベース接続のキャッシュである。接続プーリングにおいて、接続は、作成後にプールに置かれ、新たな接続を確立しなくてもよいように、再使用される。たとえば、マイクロサービス804とデータベース808との間に10の接続が必要な場合、接続プール810には、すべてデータベースユーザというコンテキストにおいて(たとえば特定のデータベースユーザに関連して、たとえば、誰がこの接続の所有者か、誰のクレデンシャルが検証中なのか、それはデータベースユーザか、それはシステムクレデンシャルかなどに関連して)開いている10の接続があるであろう。
接続プール810内の接続は、何にでもアクセスできるシステムユーザのために作成される。したがって、テナントに代わって要求を処理するマイクロサービス804による監査および特権を正しく扱うために、データベース動作は、特定のテナントに割り当てられたスキーマ所有者に関連する「プロキシユーザ」812というコンテキストで実行される。このスキーマ所有者は、このスキーマ作成の目的であったテナンシーにのみアクセスでき、このテナンシーの値はこのスキーマ所有者の値である。データベース806内のデータを求める要求がなされると、マイクロサービス804は、接続プール810内の接続を用いてこのデータを提供する。したがって、マルチテナンシーは、リソーステナンシーに対応付けられたデータストアプロキシユーザというコンテキストにおいて(たとえばそれに関連して)作成されたデータ接続のトップにある要求ごとに構築された特定テナント向けデータストアバインディングというコンテキストにおいて(たとえばそれに関連して)入ってくる要求を処理するステートレスでエラスティックな中間層サービスを持つことによって得られ、データベースは、サービスとは無関係にスケーリングできる。
以下は、プロキシユーザ812を実現するための機能の例を提供する。
この機能において、マイクロサービス804は、接続プール810内のデータベース接続を使用する一方で、接続プール810から引出された接続に対する「プロキシユーザ(Proxy User)」設定を、「テナント(Tenant)」にセットし、テナントというコンテキストにおいてデータオペレーションを実行する。
すべてのテーブルをストライピングすることにより同じデータベースにおいて異なるテナント用に異なるコラムを構成するとき、1つのテーブルは、混合されたすべてのテナントのデータを含み得る。これに対し、一実施形態は、テナント駆動のデータ層を提供する。本実施形態は、異なるテナント用に同一データベースをストライピングするのではなく、テナントごとに異なる物理データベースを提供する。たとえば、マルチテナンシーは、プラガブルデータベース(たとえばオラクル社のOracle Database12c)を用いて実現されてもよく、この場合、各テナントには別々のパーティションが割り当てられる。データ層では、リソースマネージャが要求を処理し、その後、その要求のデータソースを求める(メタデータとは別)。本実施形態は、要求ごとに各データソース/ストアへのランタイムスイッチを実行する。各テナントのデータをその他のテナントから分離することにより、本実施形態は改善されたデータセキュリティを提供する。
一実施形態において、互いに異なるトークンは、異なるテナンシーをコーディファイする。URLトークンは、サービスを要求するアプリケーションのテナンシーを特定し得る。アイデンティティトークンは、認証すべきユーザのアイデンティティをコーディファイし得る。アクセストークンは複数のテナンシーを特定し得る。たとえば、アクセストークンは、このようなアクセスのターゲットであるテナンシー(たとえばアプリケーションテナンシー)と、アクセス権が付与されたユーザのユーザテナンシーとをコーディファイし得る。クライアントアサーショントークンは、クライアントIDおよびクライアントテナンシーを特定し得る。ユーザアサーショントークンは、ユーザおよびユーザテナンシーを特定し得る。
一実施形態において、アイデンティティトークンは、ユーザテナント名(すなわちユーザがどこに存在しているか)を示す少なくとも「クレーム(claim)」(セキュリティ分野の当業者が使用する)を含む。認可トークンに関連する「クレーム」は、ある主体が自身についてまたは別の主体について述べるステートメントである。ステートメントは、たとえば、名称、アイデンティ、キー、グループ、特権、または機能に関するものであってもよい。クレームは、プロバイダによって発行され、1つ以上の値が与えられた後に、セキュリティトークンサービス(security token service:「STS」)として一般に知られている発行者によって発行されたセキュリティトークンにパッケージングされる。
一実施形態において、アクセストークンは、少なくとも、アクセストークンを求める要求がなされた時点のリソーステナント名(たとえば顧客)を示すクレーム/ステートメントと、ユーザテナント名を示すクレーム/ステートメントと、要求しているOAuthクライアントの名を示すクレームと、クライアントテナント名を示すクレーム/ステートメントとを含む。
一実施形態において、アクセストークンは、以下のJSON機能に従って実現されてもよい。
一実施形態において、クライアントアサーショントークンは、少なくとも、クライアントテナント名を示すクレーム/ステートメントと、要求を出しているOAuthクライアントの名前を示すクレーム/ステートメントとを含む。
本明細書に記載のトークンおよび/または複数のテナンシーは、IDCS以外のマルチテナントのクラウドベースのサービスによって実現されてもよい。たとえば、本明細書に記載のトークンおよび/または複数のテナンシーは、SaaSまたは企業リソースプランニング(Enterprise Resource Planning:「ERP」)サービスにおいて実現されてもよい。
図9は、一実施形態におけるIDCSのネットワークビュー900のブロック図である。図9は、一実施形態においてアプリケーション「ゾーン」904間で行われるネットワーク対話を示す。アプリケーションは、要求される保護レベルと、その他さまざまなシステムへの接続の実現に基づいてゾーンに分割される(たとえばSSLゾーン、no SSLゾーンなど)。アプリケーションゾーンのうち、いくつかはIDCS内部からのアクセスを要するサービスを提供するアプリケーションゾーンであり、いくつかはIDCS外部からのアクセスを要するサービスを提供するアプリケーションゾーンであり、いくつかはオープンアクセスである。したがって、各保護レベルは各ゾーンに対して強化される。
図9の実施形態において、サービス間の通信は、HTTP要求を用いて行われる。一実施形態において、IDCSは、本明細書に記載のアクセストークンを用いて、サービスを提供するだけでなく、IDCSへのアクセスおよびIDCS自身の内部におけるアクセスを安全なものにする。一実施形態において、IDCSマイクロサービスは、RESTfulインターフェイスを通してエクスポーズされ、本明細書に記載のトークンによって安全なものにされる。
図9の実施形態において、さまざまなアプリケーション/サービス902のうちのいずれか1つが、IDCS APIに対してHTTPコールすることにより、IDCSサービスを使用してもよい。一実施形態において、アプリケーション/サービス902のHTTP要求は、オラクルパブリッククラウドロードバランシング外部仮想IPアドレス(「VIP」)906(またはその他同様の技術)、パブリッククラウドウェブルーティング層908、およびIDCSロードバランシング内部VIPアプライアンス910(またはその他同様の技術)を通って、IDCSウェブルーティング層912により受信されてもよい。IDCSウェブルーティング層912は、IDCSの外部または内部からの要求を受信し、IDCSプラットフォームサービス層914またはIDCSインフラストラクチャサービス層916を通してルーティングする。IDCSプラットフォームサービス層914は、OpenID Connect、OAuth、SAML,SCIMなどのIDCSの外部から呼び出されたIDCSマイクロサービスを含む。IDCSインフラストラクチャサービス層916は、その他のIDCSマイクロサービスの機能をサポートするためにIDCSの内部から呼び出されたサポートマイクロサービスを含む。IDCSインフラストラクチャマイクロサービスの例は、UI、SSO、レポート、キャッシュ、ジョブスケジューラ、サービスマネージャ、キーを作るための機能などである。IDCSキャッシュ層926は、IDCSプラットフォームサービス層914およびIDCSインフラストラクチャサービス層916のためのキャッシング機能をサポートする。
IDCSへの外部アクセスおよびIDCS内部アクセス双方のセキュリティを強化することにより、IDCSの顧客に、それが実行するアプリケーションのための傑出したセキュリティコンプライアンスを与えることができる。
図9の実施形態において、構造化照会言語(Structured Query Language:「SQL」)に基づいて通信するデータ層918およびLDAPに基づいて通信するIDストア層920以外については、OAuthプロトコルを使用することにより、IDCS内のIDCSコンポーネント(たとえばマイクロサービス)間の通信を保護し、IDCS外部からのアクセスを安全なものにするために使用される同じトークンをIDCS内のセキュリティのためにも使用する。すなわち、ウェブルーティング層912は、要求がIDCSの外部から受けたものであろうとIDCSの内部から受けたものであろうと、受信した要求を処理するための同じトークンおよびプロトコルを使用する。したがって、IDCSは、システム全体を保護するために1つの一貫したセキュリティモデルを提供することにより、傑出したセキュリティコンプライアンスを可能にする。なぜなら、システム内に実現されるセキュリティモデルが少ないほど、システムの安全性は高くなるからである。
IDCSクラウド環境において、アプリケーションは、ネットワークコールを行うことによって通信する。ネットワークコールは、HTTP、伝送制御プロトコル(Transmission Control Protocol:「TCP」)、ユーザデータグラムプロトコル(User Datagram Protocol:「UDP」)などの適用可能なネットワークプロトコルに基づいていればよい。たとえば、アプリケーション「X」は、アプリケーション「Y」と、HTTPに基づいて、アプリケーション「Y」をHTTPユニフォーム・リソース・ロケータ(Uniform Resource Locator:「URL」)としてエクスポーズすることにより、通信し得る。一実施形態において、「Y」は、各々がある機能に対応する多数のリソースをエクスポーズするIDCSマイクロサービスである。「X」(たとえば別のIDCSマイクロサービス)は、「Y」をコールする必要があるとき、「Y」と、呼び出す必要があるリソース/機能とを含むURLを構成し(たとえばhttps:/host/Y/resource)、ウェブルーティング層912を通って「Y」に導かれる対応するRESTコールを行う。
一実施形態において、IDCS外部の呼出元は、「Y」がどこにあるかを知る必要がない場合があるが、ウェブルーティング層912はアプリケーション「Y」がどこで走っているかを知る必要がある。一実施形態において、IDCSは、発見機能を実現する(OAuthサービスによって実現される)ことにより、各アプリケーションがどこで走っているかを判断し、スタティックなルーティング情報の可用性が必要ではなくなるようにする。
一実施形態において、企業マネージャ(enterprise manager:「EM」)922は、オンプレミスおよびクラウドベース管理をIDCSに拡張する「一枚のガラス」を提供する。一実施形態において、Chef Software社の構成管理ツールである「シェフ(Chef)」サーバ924は、さまざまなIDCS層のための構成管理機能を提供する。一実施形態において、サービスデプロイメントインフラストラクチャおよび/または永続格納モジュール928は、テナントライフサイクル管理動作、パブリッククラウドライフサイクル管理動作、またはその他の動作のために、OAuth2 HTTPメッセージをIDCSウェブルーティング層912に送信してもよい。一実施形態において、IDCSインフラストラクチャサービス層916は、ID/パスワードHTTPメッセージを、パブリッククラウド通知サービス930またはパブリッククラウドストレージサービス932に送信してもよい。
クラウドアクセス制御‐SSO
一実施形態は、クラウドスケールSSOサービスを実現するために軽量クラウド標準をサポートする。軽量クラウド標準の例としては、HTTP、REST、および、ブラウザを通してアクセスを提供する標準(ウェブブラウザは軽量であるため)が挙げられる。逆に、SOAPは、クライアントを構築するためにより多くの管理、構成、およびツールを必要とする重いクラウド標準の一例である。本実施形態は、アプリケーションのためにOpenID Connectセマンティックスを使用することにより、IDCSに対してユーザ認証を要求する。本実施形態は、軽量HTTPクッキーベースのユーザセッション追跡を用いて、ステートフルなサーバ側セッションサポートなしで、IDCSにおけるユーザのアクティブなセッションを追跡する。本実施形態は、使用するアプリケーションに対して、認証されたアイデンティティを自身のローカルセッションに戻すマッピングを行うときに、JWTベースのアイデンティティトークンを使用する。本実施形態は、連携されているアイデンティティ管理システムとの統合をサポートし、IDCSに対してユーザ認証を要求するために企業デプロイメントのSAML IDPサポートをエクスポーズする。
図10は、一実施形態におけるIDCS内のSSO機能のシステムアーキテクチャビューのブロック図1000である。本実施形態は、クライアントアプリケーションが標準ベースのウェブプロトコルを推進してユーザ認証フローを開始することを可能にする。クラウドシステムとSSOの統合を要求するアプリケーションは、企業データセンターにあってもよく、遠隔パートナーデータセンターにあってもよく、またはオンプレミスの顧客によって操作されてもよい。一実施形態において、異なるIDCSプラットフォームサービスが、接続されているネイティブなアプリケーション(すなわちIDCSと統合するためにOpenID Connectを利用するアプリケーション)からのログイン/ログアウト要求を処理するためのOpenID Connect、接続されているアプリケーションからのブラウザベースのログイン/ログアウト要求を処理するためのSAML IDPサービス、外部SAML IDPに対してユーザ認証を調整するためのSAML SPサービス、および、ローカルなまたは連携されたログインフローを含みIDCSホストセッションクッキーを管理するためのエンドユーザログインセレモニーを調整するための内部IDCS SSOサービスなどの、SSOのビジネスを実現する。一般的に、HTTPは、フォームありでまたはフォームなしで機能する。フォームありで機能するとき、このフォームはブラウザ内で見えるフォームである。フォームなしで機能するとき、これはクライアントからサーバへの通信として機能する。OpenID ConnectもSAMLも、フォームをレンダリングする能力を必要とするが、これは、ブラウザの存在によって実現される、または、ブラウザが存在しているかのように機能するアプリケーションによって仮想的に実行される。一実施形態において、ユーザ認証/SSOをIDCSを通して実現するアプリケーションクライアントは、IDCSにおいて、OAuth2クライアントとして登録される必要があり、クライアント識別子およびクレデンシャル(たとえばID/パスワード、ID/証明書など)を取得する必要がある。
図10の実施形態の例は、2つのプラットフォームマイクロサービスとしてのOAuth2 1004およびSAML2 1006と、1つのインフラストラクチャマイクロサービスとしてのSSO1008とを含む、ログイン機能をまとめて提供する3つのコンポーネント/マイクロサービスを含む。図10の実施形態において、IDCSは「アイデンティティメタシステム」を提供する。このメタシステムにおいて、SSOサービス1008は、異なる種類のアプリケーションに対して提供される。これらのアプリケーションは、3者間OAuthフローを必要としOpenID Connectリレーパーティ(relaying party:「RP」、そのユーザ認証機能をIDPにアウトソーシングするアプリケーション)として機能するブラウザベースのウェブまたはネイティブアプリケーション1010、2者間OAuthフローを必要としOpenID Connect RPとして機能するネイティブアプリケーション1011、およびSAML SPとして機能するウェブアプリケーション1012などである。
一般的に、アイデンティティメタシステムは、デジタルアイデンティティのための相互運用可能なアーキテクチャであり、複数の基礎となる技術、実装、およびプロバイダの集合体を用いることを可能にする。LDAP、SAML、およびOAuthは、アイデンティティ機能を提供する異なるセキュリティ標準の例であり、アプリケーションを構築するための基礎となることが可能であり、アイデンティティメタシステムは、このようなアプリケーションに対して統一されたセキュリティシステムを提供するように構成されてもよい。LDAPセキュリティモデルは、アイデンティティを扱うための特定のメカニズムを指定し、システムを通るすべてのパスは厳密に保護されねばならない。SAMLは、一組のアプリケーションが、異なるセキュリティドメインの異なる組織に属する別の一組のアプリケーションとの間で安全に情報を交換できるようにするために開発されたものである。これら2つのアプリケーションの間に信頼はないので、SAMLは、一方のアプリケーションが、同じ組織に属していない別のアプリケーションを認証できるように開発された。OAuthは、ウェブベースの認証を実行するための軽量プロトコルであるOpenID Connectを提供する。
図10の実施形態において、OpenIDアプリケーション1010がIDCS内のOpenIDサーバに接続すると、その「チャネル」はSSOサービスを要求する。同様に、SAMLアプリケーション1012がIDCS内のSAMLサーバに接続すると、その「チャネル」もSSOサービスを要求する。IDCSにおいて、各マイクロサービス(たとえばOpenIDマイクロサービス1004およびSAMLマイクロサービス1006)はアプリケーション各々を処理し、これらのマイクロサービスはSSOマイクロサービス1008からのSSO機能を要求する。プロトコルごとにマイクロサービスを追加してからSSO機能のためにSSOマイクロサービス1008を用いることにより、このアーキテクチャを拡張して任意の数のその他のセキュリティプロトコルをサポートすることができる。SSOマイクロサービス1008は、セッションを発行し(すなわちSSOクッキー1014が提供される)、このアーキテクチャにおいてセッションを発行する権限を有する唯一のシステムである。IDCSセッションは、ブラウザ1002がSSOクッキー1014を使用することによって実現される。ブラウザ1002はまた、ローカルセッションクッキー1016を用いてそのローカルセッションを管理する。
一実施形態において、たとえば、ブラウザ内で、ユーザは、SAMLに基づいて第1のアプリケーションを使用してログインし、その後、OAuthなどの異なるプロトコルを用いて構築された第2のアプリケーションを使用してもよい。ユーザには、同じブラウザ内の第2のアプリケーション上のSSOが与えられる。したがって、ブラウザは、ステートまたはユーザエージェントであり、クッキーを管理する。
一実施形態において、SSOマイクロサービス1008は、ログインセレモニー1018、ID/パスワードリカバリ1020、第1回ログインフロー1022、認証マネージャ1024、HTTPクッキーマネージャ1026、およびイベントマネージャ1028を提供する。ログインセレモニー1018は、顧客設定および/またはアプリケーションコンテキストに基づいてSSO機能を実現し、ローカルフォーム(たとえばベーシックAuth)、外部SAML IDP、外部OIDC IDPなどに従って構成されてもよい。ID/パスワードリカバリ1020は、ユーザのIDおよび/またはパスワードの回復のために使用される。第1回ログインフロー1022は、ユーザが1回目にログインしたときに実現される(すなわちSSOセッションはまだ存在しない)。認証マネージャ1024は、認証に成功すると認証トークンを発行する。HTTPクッキーマネージャ1026は認証トークンをSSOクッキーに保存する。イベントマネージャ1028はSSO機能に関連するイベントをパブリッシュする。
一実施形態において、OAuthマイクロサービス1004とSSOマイクロサービス1008との間の対話は、ブラウザリダイレクトに基づいており、SSOマイクロサービス1008は、HTMLフォームを用いてユーザに問いかけ、クレデンシャルを検証し、セッションクッキーを発行する。
一実施形態において、たとえば、OAuthマイクロサービス1004は、ブラウザ1002から認証要求を受け、3者間OAuthフローに従ってアプリケーションのユーザを認証する。よって、OAuthマイクロサービス1004は、OIDCプロバイダ1030として機能し、ブラウザ1002をSSOマイクロサービス1008にリダイレクトし、アプリケーションコンテキストに沿って進む。ユーザが有効なSSOセッションを有するか否かに応じて、SSOマイクロサービス1008は、既存のセッションを検証するかまたはログインセレモニーを実行する。認証または検証に成功すると、SSOマイクロサービス1008は、認証コンテキストをOAuthマイクロサービス1004に返す。そうすると、OAuthマイクロサービス1004はブラウザ1002を認証(「AZ」コードを有するコールバックURLにリダイレクトする。ブラウザ1002は、AZコードをOAuthマイクロサービス1004に送信し、必要なトークン1032を要求する。また、ブラウザ1002は、HTTP認証ヘッダにおいてそのクライアントクレデンシャル(IDCSをOAuth2クライアントとして登録したときに取得)を含む。これに対し、OAuthマイクロサービス1004は、要求されたトークン1032をブラウザ1002に与える。一実施形態において、ブラウザ1002に与えられるトークン1032は、JWアイデンティティと、IDCS OAuth2サーバによって署名されたアクセストークンとを含む。この機能のさらなる詳細は、以下で図11を参照しながら開示される。
一実施形態において、たとえば、OAuthマイクロサービス1004は、ネイティブアプリケーション1011から認可要求を受け、2者間OAuthフローに従ってユーザを認証する。この場合、OAuthマイクロサービス1004の認証マネージャ1034は対応する認証を(たとえばクライアント1011から受けたID/パスワードに基づいて)実行し、トークンマネージャ1036は、認証に成功すると、対応するアクセストークンを発行する。
一実施形態において、たとえば、SAMLマイクロサービス1006は、ブラウザからSSO POST要求を受け、SAML SPとして機能するウェブアプリケーション1012のユーザを認証する。SAMLマイクロサービス1006は次に、SAML IDP1038として機能し、ブラウザ1002をSSOマイクロサービス1008にリダイレクトし、アプリケーションコンテキストに沿って進む。ユーザが有効なSSOセッションを有しているか否かに応じて、SSOマイクロサービス1008は、既存のセッションを検証するか、またはログインセレモニーを実行する。認証または検証に成功すると、SSOマイクロサービス1008は、認証コンテキストをSAMLマイクロサービス1006に返す。そうすると、SAMLマイクロサービスは、必要なトークンでSPにリダイレクトする。
一実施形態において、たとえば、SAMLマイクロサービス1006は、SAML SP1040として機能してもよく、遠隔SAML IDP1042(たとえばアクティブディレクトリ連携サービス(active directory federation service:「ADFS」)に進んでもよい。一実施形態は、標準SAML/ADフローを実現する。一実施形態において、SAMLマイクロサービス1006とSSOマイクロサービス1008との間の対話は、ブラウザのリダイレクトに基づいており、SSOマイクロサービス1008は、HTMLフォームを用いてユーザに問いかけ、クレデンシャルを検証し、セッションクッキーを発行する。
一実施形態において、IDCS内部のコンポーネント(たとえば1004、1006、1008)と、IDCS外部のコンポーネント(たとえば1002、1011、1042)との間の対話は、ファイアウォール1044を通して行われる。
SSOサービス
一実施形態において、IDCSのクラウド環境では、テナントがプロビジョニングされそのアプリケーションの保護を要求すると、IDCSは、認証、認可、監査といったアイデンティティ機能を提供する。ユーザがアプリケーションの使用を必要とするとき、IDCSは、ユーザのアイデンティティの完全なセキュリティを提供し、特定種類のトークンが生成され、このアプリケーションについてユーザアクセスが確立されるまたはユーザアクセスのセキュリティが確保される。
一実施形態において、SSOサービスは、種類が異なるクライアント/アプリケーションを保護するために使用され、特定の各アプリケーションへのアクセスは、OAuthまたはSAMLといった標準プロトコルによって保護される。このプロトコルは、トークンフォーマット、どのようなトークンが必要か、および、特定のトークンを生成するにはどのようなブラウザセマンティックスが必要かを、指定する。アプリケーションは、トークンを受けると、トークンベースのクレームを使用することにより、特定のユーザにアクセスを与えることができる。一実施形態において、トークンは、ユーザは誰であるか、アクターは誰であるか、スコープは何であるか、および、アクセスされているオーディエンスは何であるかを尋ねる。一実施形態において、トークンは、OAuthとSAMLとで異なり、ユーザが認証後に確立するユーザクレーム/ステートメントのセマンティックスを含む。
一般的に、OAuthおよびSAMLといった標準ベースのプロトコルは、如何にしてトークンを生成するか、または如何にしてユーザは認証されるべきかを示す何らかの仕様を指定または提供しないが、代わりに、ユーザが認証されることのみを要求し、どのトークンを取得すべきかを指定する。たとえば、OAuthまたはSAMLトークンの場合、プロトコルは、このトークンのセマンティックスを指定するだけであり、如何にしてユーザが認証され、ログイン、ログアウトされるべきかなどを、指定または特定しない。
しかしながら、一実施形態において、IDCS SSOサービスは、如何にして特定のユーザが認証されるか(たとえば認証が1ファクタ、2ファクタ、生体認証などであるか否か)を規定する。この実施形態において、サインオンポリシーまたはアクセスポリシーは、アプリケーションにアクセスするためにユーザが如何にして認証されるかを示す。一実施形態において、IDCSは、認証の実行後に、認証を、IDCSセッションまたは「グローバルセッション」(たとえば、セッションクッキーまたはセッショントークンとして構成される)に変換する。グローバルセッションは、特定のセマンティックス/フォーマットを有する、クラウドが認識しているセッションであり、IDCSマルチテナント環境のために構成される。アプリケーションのために実行される特定のアイデンティティタスクに応じて、IDCSは、グローバルセッションを、適用可能なトークン(たとえばOAuthトークン、SAMLトークンなど)に変換し、このトークンをアプリケーションに与えることができる。
一実施形態において、SSOサービスは、どのプロトコル(たとえばOAuth、SAML、ソーシャルトークン、ソーシャルサービスなど、または新たに開発された何らかの仕様)に対しても使用できる、共通コントローラシステムである。一実施形態において、要求がSSOサービスによって受信されると、要求パラメータが正規化される。このため、SSOサービスは、共通である状態にとどまり、各種トークンを扱うことができる。SSOサービスは、特定のプロトコルセマンティックス(たとえばOAuth固有のセマンティックスまたはSAML固有のセマンティックス)を把握している必要はない。
一実施形態において、SSOサービスは、完全なログインセレモニーを共通ロジックとして定義する。ログインセレモニーは、如何にしてユーザがログインするか、認証にどのファクタが用いられるか、如何にしてシステムがファクタ認証を実行するか、ユーザとIDCS SSOサービスとの間でどのようにオーケストレーションが発生するか、などを、指定する。また、SSOサービスは、グローバルセッションから如何にしてログアウトするかおよび異なるプロトコルを如何にして再現するかを指定するログアウトセレモニーを規定する。SSOサービスは、プロトコル駆動型アプリケーションログアウトを提供する。
一実施形態において、完全なログインセレモニーは、SSOサービスとUIインタラクションとの間で発生する。ログインセレモニーは、ログインするためにユーザが使用しているファクタ(たとえば、ユーザIDおよびパスワード、証明書に基づく認証、モバイルファクタに基づく認証など)に応じて決まる。
一実施形態は、SSOサービスを、共通コントローラとして実現し、また、認証モジュールプラグインを、各ログインセレモニーのためのバックエンドオーセンティケータとして実現する。たとえば、ユーザIDおよびパスワードに基づく認証の場合、本実施形態は、ユーザIDおよびパスワードを含むアイデンティティストアに行くためにプラグインを実現する。次に、プラグインは、そのストアに対するユーザクレデンシャルを認証する。別の例として、ユーザがX.509証明書といったユーザクレデンシャルの証明書を提供した場合、SSOサービスは、この場合は証明書モジュールである適切な認証モジュールを決定する。この証明書モジュールは、証明書ストアに行き、提供された証明書を、証明書ストアに照らして検証する。一実施形態において、ユーザは、ショートメッセージサービス(short message service:「SMS」)または時間に基づくワンタイムパスワード(time-based one-time password:「TOTP」)といったモバイル認証ファクタを提供することができる。
いくつかの実施形態において、SSOサービスは、ユーザを認証するために、マルチファクタ認証プラグインに行くと決定することができる。SSOサービスは、各プラグインの必要条件を調整する。さまざまな実施形態において、プラグインには、1ユーザIDおよびパスワードの場合のようにユーザとの1回のやり取りが必要な場合、または、複数ページの場合のようにユーザとの複数回のやり取りが必要な場合がある。
したがって、SSOサービスは、異なる種類のユーザ認証のためのログインセレモニー全体を調整する。一旦ユーザが認証されると、SSOサービスはグローバルセッションを確立する。一実施形態において、グローバルセッションには、ユーザID、ユーザプリファレンス、ユーザロケール、ユーザタイムゾーン、認証されたファクタまたはモジュール、認証時間など、さまざまなユーザ情報がポピュレートされる。
一実施形態において、IDCSのクラウドアーキテクチャでは、サービスは、ステートレスで横方向にスケーラブルなものとして構成され、サーバにおいて保持される状態(ステート)はない。したがって、サービスは、クライアントセッションのセッション状態を保持できないので、グローバルセッションであるセッション全体はクライアントクッキーに入れられる。すなわち、本実施形態は、グローバルセッションをクライアントクッキーとして構成し、クライアントセッションは、グローバルセッション全体が保存されるクッキーである。一実施形態において、クッキーは要求ヘッダの一部であり、要求が「302」でブラウザに戻りリダイレクトが別のサービスに帰るたびに、クッキーはリプレイされる(すなわちヘッダがリプレイされる)。
一実施形態において、グローバルセッションのコンテンツを、プロトコルバッファを用いて格納することにより、そのサイズを最小にして、グローバルセッションをクッキーに含めることができるようにする。一実施形態は、グローバルセッションを保存しそのサイズを最適化しクッキーまたはクライアントセッションを特定のプロトコルベースのトークンに変換するためのセマンティックスを提供する。
一実施形態において、ユーザが既にシステムにログインしており(したがってシステム内のグローバルセッションを有する)同一のブラウザセッションで別のアプリケーションにアクセスしているときに、第1のフローがコールされる。このフローにおいて、プロトコルレイヤ(たとえば図10の1004および1006)は、グローバルセッションを理解しないので、ユーザが有効セッションを有するか否かを判断しない。その代わりに、ユーザが有効なグローバルセッションを有するか否かを判断するようSSOサービスに要求する。そうすると、SSOサービスは、プロトコルに応じて有効セッションとの調整を行う異なるフローが存在するモードに入る。特定のパラメータに基づいてセッションの有効性を判断し、ユーザが有効なグローバルセッションを有する場合は、プロトコル固有のトークンを生成しアクセスを与える。
一実施形態において、セッションの有効性が十分ではなくユーザがアサートされる必要がありローカルアイデンティティが必要であるときに、第2のフローがコールされる。
一実施形態において、1回目のログインに対して第3のフローがコールされる。ユーザが認証され(各認証モジュールを用いて)、調整が実施された後にSSOサービスがセッションを生成しようとしているときに、本実施形態は、ローカルIDCSユーザストアにユーザが存在することを保証する。ユーザは、ローカルアイデンティティの存在を必要とする(たとえば、ユーザが遠隔認証された場合はパスワードではないであろうが、少なくとも何らかの最小のプロファイル情報)。同様に、上記フローにおいて、既存の有効セッションが存在する場合、SSOサービスは、ローカルストアのユーザをアサートし、ローカルIDCSアイデンティティストアにユーザが存在することを保証する。
一実施形態は、一組のフローを連携システムのために提供する。連携は、ドメイン横断SSOを提供し、SP、IDP、またはその他のアクターおよびエンティティを含み得る。たとえば、SPおよびIDPは、異なるドメイン(たとえば、クッキードメイン、アイデンティティドメインなど)上にあってもよく、セッションは、SAML2といった連携プロトコルを用いて別のドメインに移されることが必要な場合がある。1つのドメインにおいて、本実施形態は、別のドメインが読み取ることができないローカルセッションまたはグローバルセッションを作成することができる。したがって、他のドメイン(信頼できるドメインでもなければならない)に行く前に、本実施形態は、グローバルセッションをSAMLトークンに変換し、SAMLトークンを、自身が検証されアサートされることができる他のドメインに移す。
一実施形態において、SAML SPまたはIDPとして動作するときにSSOサービスによって調整される異なるフローが存在する。一般的に、ユーザは、ローカルに存在していないとき、遠隔IDPに対して認証される。たとえば、ユーザは、クラウドサービスを利用するためにクライドアカウントを有し得るが、そのユーザアイデンティティをクラウドストアに複製することを望まないオンプレミスユーザまたは既存の企業ユーザであってもよい。ユーザアイデンティティはオンプレミスであるため、オンプレミスは遠隔IDPになる。この場合、ローカルIDCS SSOサービスは、SPとして動作し遠隔IDPにコンタクトする。
SPとして機能するSSOサービスにユーザが来たとき、SSOサービスは、SAMLといった連携プロトコルを利用して遠隔IDPに行く。認証は遠隔IDPで行われ、SAMLトークンはこの遠隔IDP上で生成される。遠隔IDPは、このSAMLトークンをSSOサービスに送る。IDCS SAMLサービスは、このSAMLトークンを抽出し、必要な属性/ステートメントをSAMLトークンから抽出し(たとえば、認証ステートメント、認可ステートメント、名称、IDなど)、この情報を特定のフォーマットで正規化し、次にこれをSSOサービスに送る。IDCS SAMLサービスはアサーションを実行しない。SSOサービスはユーザログインセレモニーを調整する必要はない。なぜなら、遠隔認証は既に遠隔IDPでオンプレミスで行われているからである。代わりに、SSOサービスは、正規化された属性フォーマットの正規化されたSAML状態を取得し、ローカルシステムにおいてこの状態をアサートする(これらの属性をアサートする)。
一実施形態は、たとえば、ユーザは遠隔で認証されてもローカルに存在しなければならないか否か、ローカルシステムにおけるユーザの存在を無視すべきか否かなど、連携のための異なるオプション/フラグまたは構成を提供する。これに基づいて、SSOサービスは、ユーザをローカルでアサートするか、または、ただクレームをアサートし、その後グローバルセッションを作成する。次に、SSOサービスは、この要求をプロトコル層に戻す(すなわちSAMLサービス)。
一実施形態において、IDCSシステム全体におけるグローバルセッションは、生成すべきどのプロトコルトークンにとっても、信頼できる情報源である。グローバルセッションは、SSOサービスにより、新たな認証、既存のセッション、連携のための遠隔認証、OAuthまたはソーシャログインのための遠隔認証といった、調整する各種フローに基づいて、生成される。その後、IDCSシステムは、異なるプロトコルに対して1つのトークンを生成しこのトークンをアプリケーションに戻すことができる。このトークンに基づいて、クライアントはテナントアプリケーションにアクセスすることができる。
正規化状態
一実施形態は、グローバルセッションを、SAMLおよびOAuthといった異なるプロトコルについて正規化されたパラメータを提供することによってサポートする。一方、OAuthサービスおよびSAMLサービスは各々、それぞれのトークンを受ける。たとえば、SAMLサービスは、ヘッダとボディとを有するXMLブロックであるSAMLアサーションを受ける。このヘッダは、トークンの種類、または認証を生成するために使用されるセキュリティメカニズムの種類を規定する。これはたとえばX.509、ユーザID/パスワードなどであってもよい。一実施形態において、SAMLトークンは、SAML2仕様に準拠する。SAMLサービスは、SAMLトークンを抽出し、読み取り、その各部分を検証する。トークンのボディは、名称ID、認証ステートメント(遠隔IDPによって使用される認証の種類を示す)などのSAMLアサーションを含み得る。
このトークンはまた、認証ステートメント(認証に使用された属性を示す)と、認証がいくつかの属性を移した後の属性ステートメント(遠隔IDPを示す)とを含む。一実施形態において、遠隔IDPは、ユーザのためのリアルアイデンティティストアを有し、これを用いてユーザを認証し、属性ステートメントの必要条件に基づいてSAMLトークンの中のいくつかの属性を送り返す。送る必要がある属性は、IDPとSPとの間で確立されたSAML構成に基づいて判断される。一実施形態において、エンティティがSPのためのIDPまたはIDPのためのSPになる前に、双方のエンティティは信頼できるエンティティでなければならず、前提条件としてメタデータ交換が実行される。これらはまた、各々が他方に求める信頼および構成を確立するためにそれぞれの証明書(たとえば公開キー/証明書)を共有する。SPがSAMLアサーションを得たとき、属性ステートメントは、SPがIDPに対して指定した構成ステートメントに基づく(たとえば、SAMLトークンの生成後にどのような属性がSPに送信されるべきか)。
一実施形態において、SAMLサービスは、SAMLセマンティックスのみを把握している。これは、SAMLトークンをオープンにし、署名を検証し、それが暗号化されていればサインおよび暗号化アルゴリズムに基づいて解読することができる。このアルゴリズムはまた、SPとIDPとの間の構成の一部である。一実施形態において、これはすべて、SAMLサービスがトークンから属性を取得するプロトコルレイヤで実行される。一実施形態において、SAMLサービスは、属性を、キー/値ペア(たとえば属性名と値)として正規化する。この実施形態において、キー/値ペア構成は、どの特定のプロトコルにも基づいていない汎用フォーマットである。属性の正規化状態は、SSOサービスが、キー/値ペアとして受信する。一実施形態において、同じ正規化が、プロトコルレベルクレームにおけるOAuthトークンに対して実行される。すなわち、OAuthクレームも同一のキー/値ペアフォーマットで正規化される。
一実施形態において、プロトコルは、認証プロトコルの一部として属性を与え、属性を要求し、および/またはグローバルセッションの確立後に、認証/検証の実行後にSSOサービスが戻るべき場所を指定することができる(たとえばコールバックするプロトコル−サービスベースの戻りURL)。たとえば、SAMLの場合、属性はSSOサービスが受けるが、OAuthの場合、SSOサービスが属性を提供する。なぜならこれがユーザを認証したからである。一実施形態において、たとえば、SAMLプロトコルは、属性を遠隔エンティティ(たとえば遠隔IDP)から受ける、または属性が戻されることを必要とすることを示す。OAuthの場合、プロトコルは、グローバルセッションの確立後プロトコルはいくつかの属性が戻されることでエンドアプリケーションのためのOAuthに基づくクレームを生成する。一実施形態において、OAuthまたはSAMLは、特定のエンドポイント/URLに行くのにSSOサービスを要する場合がある。この情報は、双方のプロトコルから、状態情報としてSSOサービスに戻る。
一実施形態において、プロトコルレイヤ(たとえばSAMLおよびOAuthサービス)およびSSOサービスへの/からの通信は、(HTTP303を介した)「リダイレクト」によるものであり、これらは、暗号化されたクッキーにおいて共通の状態を共有する。暗号化されたクッキーは、プロトコル情報と、各種ブラウザの制限(たとえばヘッダサイズ、クッキーサイズなど)について正確で適切なものとなるように構成された正規化されたフォーマットとを、格納する。
要求状態
本実施形態のクラウドアーキテクチャにおいて、サービスはステートレスである。したがって、一実施形態は、異なるレイヤが相互にやり取りできるようフロースルー(flow through)する共通状態を提供する。本実施形態は、たとえば、プロトコルレイヤが認証のためにSSOサービスにコンタクトする(HTTPがリダイレクトする)とき、SSOセッションがないとき、プロトコルレイヤがセッション検証および既存のセッションでのユーザアサーションのときなど、さまざまなフローの期間中、クライアントに状態を(暗号化されたホストクッキーの形態で)保存する。
一実施形態において、共通状態は、クライアントセッションおよびクライアント状態を含む。本実施形態は、「要求状態」を提供し、これを「要求クッキー」にヘッダとして含める。要求クッキーは、SSOクッキーでも、認証されたセッションでもなく、異なるサービス(たとえば、プロトコルサービス、SSOサービスなど)にまたがって維持される、予め認証されている状態である。これはまた、実行コンテキスト(たとえば監査、診断などの状態)を含む。正規化状態(たとえば、属性、戻りURL、異なるフローに対して何が必要か、など)も、要求状態に取り込まれ、要求クッキーに置かれる。一実施形態において、このクッキーは暗号化され、暗号化キーは、安全に格納され、ハイジャックできないように定期的にロールオーバされる(たとえば12時間ごとに)。
一実施形態において、要求状態に格納される状態情報は、パスワードといったユーザセキュリティデータを含まない。一実施形態において、プロトコル間のやり取りの間でさえ、クレームのみが要求状態に格納され、署名はクレームに添付される。
一実施形態において、ログインプロセス(たとえばログインセレモニーまたは異なるフロー)中に用いられる要求状態は、ログアウトプロセス中に使用することもできる。なぜなら、この状態は、ユーザが訪れたことがあり戻る必要があるまたはプロトコルのためにログアウトする必要がある異なるエンドポイント、プロトコルごとの正規化状態、クレーム、アイデンティティシステムにおいてユーザをアサートするのに必要な属性などに関する情報を含むからである。
一実施形態において、さまざまなフローの期間中に状態をクライアントで(暗号化されたホストクッキーの形態で)保存するために、以下の表現が実現される。
・「UserRequestData」は、既存のセッションの作成/検証のためにSSOサービスに対してプロトコルレイヤが新たな要求を開始するたびに作成される。
・「UserSessionData」は、プロトコルレイヤからの要求の処理が完了するとSSOサービスによって作成される(一旦作成されると、「UserRequestData」は削除され、関連するすべてのデータがそこにパーシストされる)。
・「AbstractUserData」は、「UserRequestData」および「UserSessionData」の親であり、双方によって使用される共通状態データ構造を含む。
表1は、一実施形態において「UserRequestData」表現に含まれる機能を提供する。
一実施形態において、「UserSessionData」表現は、ユーザセッションデータの正確なバイナリ表現である「byte[]authnContext」を含む。これはたとえば「AuthContext」オブジェクトによって定められる属性である。プロトコルバッファライブラリを使用することにより、バイナリフォーマットでデータを効果的に表現する。これはたとえば12時間ごとにロールオーバされるプライベート鍵を用いて暗号化される。表2は、一実施形態における「AuthContext」表現に含まれる機能を提供する。
表3は、一実施形態において「AbstractUserData」表現に含まれる機能の例を提供する
一実施形態において、「Map<Integer, byte[]> componentData」に対応するコンポーネントは、たとえば、SSO、OAuth2、およびSAMLサーバである。データはバイナリであり、よって暗号化することができ、プライベート鍵の管理はコンポーネントデータ表現から抽出することができる。「UserSessionData」の一部として、これは、セッションの期間中に発行したトークン/アサーションの対象である各クライアントまたはパートナーの追跡データを保持する。これはグローバルログアウトでも役立つ。「UserRequestData」の一部として、これは、コンポーネントレベル要求スコープデータを保持する。
一実施形態において、SSOサービスは、リソースマネージャおよびSSOランタイムを実現する。リソースマネージャは、IDCSの共通データアクセスレイヤである。これは駆動されるメタデータであり、SCIMに従うリソースタイプおよびスキーマ定義において規定されている何らかのリソースタイプを管理することができる。リソースマネージャは、属性、データタイプ、要求される値、カノニカル値(canonical value)などの、スキーマに基づく検証を含む、すべてのリソースタイプのすべての共通ロジックを処理する。これはまた、デフォルト値の設定、「作成/更新日」値の設定、「による作成/更新」値の設定、センシティブな属性の保護、ターゲット属性へのマッピング、認証チェック、およびイベント公開を処理する。リソースタイプデータマネージャの外部インターフェイスはHTTP/REST(IDCS管理サーバでデプロイされ「serviceUp」コマンドによってもたらされたもの)であり、その内部実現はJavaインターフェイスを通して行われる。一実施形態において、実装例は、Java固有要求(Java Specific Request:「JSR」)330に基づいて、Hundred-Kilobyte Kernel(「HK2」)を用いて注入される。リソースタイプペイロードは、SCIM2.0によって概要が示されているリソースモデルに従う。たとえば、「/Applications」および「/Credentials」は、特定のリソースタイプである。
リソース定義およびスキーマは、「/ResourceTypes」および「/Schemas」を通して発見可能である。リソースタイプデータマネージャは、テナント(たとえばユーザ、グループ、トークン、リソースタイプ、スキーマなど)ごとのオペレーショナルデータ、テナント設定(サービス横断テナント固有設定およびサービス固有テナント固有設定)、およびグローバル構成(サービス横断グローバル構成およびサービス固有グローバル構成)を管理する。
SSOランタイム
図10Aは、一実施形態におけるSSOランタイムの、一例としてのブロック図1000Aを示す。この実施形態では、SSOサービス1002Aが、ローカルログインおよび連携ログインのためのユーザログイン/ログアウトセレモニーを実現する。クラウドSSO統合アーキテクチャは、ブラウザベースのユーザログインに対し、標準OpenID Connectユーザ認証フローを使用する。クラウドログインはOpenID Connectに基づくので、OpenIDプロバイダ(「OP」、図1000AにおいてOAuth OP 1004Aとして示されている)は、ログイン要求がSSO 1002Aに到達する場所である。内部では、ランタイム認証モデルはステートレスであり、ユーザのSSO状態をホストHTTPクッキーの形態で保持する。
ユーザログイン要求のフローは次の通りである。ユーザがブラウザベースのアプリケーションまたはモバイル/ネイティブアプリケーションにアクセスし、接続アプリケーション(OAuth RP 1006Aまたはアプリケーションの実施ポイント)が、ユーザはローカルアプリケーションセッションを有しておらずユーザ認証を要求していることを検出し、接続アプリケーション(OAuth RP 1006Aまたはアプリケーションの実施ポイント)が、OAuth2サービスに対してOpenID Connectログインフローを開始し(スコープ=「openidプロファイル」である3レッグAZグラントフロー)、OAuth2サービス(OAuth OP 1004A)が、アプリケーションコンテキストを構築しSSOサービス1002Aにリダイレクトする。
一実施形態において、OAuth OP 1004AとSSO 1002Aとの間のサービスレベル協定(service level agreement:「SLA」)は以下を含む。
● IDCS_REQUEST−IDCS_REQUEST HTTPクッキーは、SSO 1002Aとチャネルコンポーネントとの間のさまざまな要求/レスポンスフロー間の状態を維持するために使用される。
○CallbackURL:これは、SSO 1002Aにリダイレクトする前にOAuth OP 1004Aによって設定される。SSO 1002Aは処理後にこのURLにリダイレクトする。
○ErrorCode:これは、発生した何らかのエラーについて、SSO 1002Aが逆にOAuth OP 1004Aに如何にして伝達するかである。
○ErrorMessage:ローカライズされたSSOエラーメッセージ。
●IDCS_セッション
○認証ステータスが「成功」であれば、SSO 1002Aは認証付きのIDCS_SESSIONを作成し、ユーザをIDCS_REQUESTにおける/callBackUrlにリダイレクトする。
○有効なIDCS_SESSIONが既に存在していれば、SSO 1002Aは、IDCS_SESSIONクッキーからフェッチしたユーザをアサートする。
一実施形態はまた、ユーザロケールなどのユーザプリファレンスを格納できるパーシステントクッキーを実現し得る。このクッキーは、エラーメッセージをユーザ固有ロケールに変換するために使用できる。
一実施形態において、IDCSマイクロサービスアーキテクチャに従い、UIサービス1008A(Login App/Logout)が、SSO 1002Aの一部としてではなく、別個のサービスとして実現される。UIサービス1008AおよびSSOサービス1002Aは、図1000AのRESTレイヤ1010Aにおいて実現されるRESTエンドポイントを介して互いにやり取りし、状態情報は、SSOサービス1002AとRESTレイヤ1010Aとの間でJSONペイロードとして送られる。
一実施形態において、SSOサービス1002Aは、RESTレイヤ1010Aと、SSOコントローラ1012Aと、クレデンシャルコレクター1014Aと、認証マネージャ1016A(異なるモジュールにログインするためであり、互いにコール、認証、および検証する)と、セッションマネージャ1018Aと、SSOイベントマネージャ1020Aと、SSOクライアントAPIインテグレータ1022Aと、エラーハンドリング1024Aと、アサータ(異なるアイデンティティに基づきアサートする、図1000Aには示されていない)とを含む。一実施形態において、認証要求が「/sso」でSSO 1002AのGET方法に到達したとき、この要求は、IDCS_REQUEST HTTPクッキーとして、OAuth OP 1004A(OAuth RP 1006Aに対応)またはSAML IDP 1005A(SAML SP 1007Aに対応)によってSSO 1002Aにサブミットされる要求および状態データを含む。IDCS_REQUESTクッキーは、解読およびパースされ、パラメータおよびその他のHTTPヘッダが、要求コンテキストオブジェクトに取り込まれ、SSOコントローラ1012Aに送られる。SSO 1002Aは、ユーザのクレデンシャルを、ログインページ(UIサービス1008Aによって実現される)にリダイレクトすることによって収集し、ログインページは、このクレデンシャルを、SSO 1002AのPOST方法にサブミットする。この状態情報は、これらの間においてJSONペイロードとして送られる。
一実施形態において、SSOコントローラ1012Aは、要求の状態に応じてどのようなアクションをすべきかを判断するクラスである。クレデンシャル収集、クレデンシャル検証、新規ユーザ、忘れられたパスワード、パスワードリセットなどを示す、さまざまな状態がある。SSOコントローラ1012Aは各種条件に応じてこのフローを他のコンポーネントに対して調整する。
一実施形態は2つの形態の認証として、BasicおよびFormをサポートする。ユーザ名、パスワード、およびテナント名などの必要なクレデンシャルが、クレデンシャルコレクター1014Aで収集され、認証のために送られる。このクラスは、ログインUIに送信されるJSON要求を準備し、ログインアプリケーションから受けたレスポンスをパースする。
認証マネージャ1016Aは、IDCSユーザID/パスワードを検証し、および/または認証トークンを発行するクラスである。認証成功、無効なクレデンシャル、無効なユーザ、パスワード期限切れ、パスワードのリセット要など、さまざまな認証結果が存在し得る。適切なエラーコードはSSOレスポンスの一部として戻される。認証マネージャ1016Aは、ユーザ/アイデンティティマネージャ1030A(管理サービス内のリソースマネージャ)の「/UserAuthenticator」RESTエンドポイントに対してトークすることにより、クレデンシャルの実際の検証を実行する。一実施形態において、認証コンテキスト1017A(グローバルセッション)およびユーザの認証クレームが、認証マネージャ1016Aで生成される。認証コンテキスト1017Aは、既に要求の中にある場合、クレデンシャルを検証する代わりに、同じユーザ認証サービスに対してトークしてトークンをアサートすることによってアサートされる。
一実施形態において、セッションマネージャ1018Aはクッキーマネージャ1028Aと通信し、SSOクッキーを管理する。これは、認証コンテキストおよび接続アプリケーションのメタデータを格納することを含む。クッキーマネージャ1028Aは、その他すべてのレイヤと共有される共通レイヤであり、クライアントセッションクッキーとするグローバルセッション状態を生成して最適化する。認証または検証が成功すると、SSOサービス1002Aは、ユーザの認証トークンを含む新たに作成/更新されたSSOホストHTTPクッキーとともにOAuthサービスに戻るようにリダイレクトする。SSOサービス1002Aは、クッキーから要求固有のデータを削除する。以下は、HTTPサーブレット要求からクッキーデータを読み取るための機能の一例である。
一実施形態において、HTTP要求におけるクッキーデータの一例は次の通りである。
一実施形態において、SSOイベントマネージャ1020Aは、イベントマネージャ1032Aと通信し、SSOフローに対応付けられたイベントを公開する。一実施形態は、SSOイベントを定義しこれらのイベントのターゲットは何かを定義する(たとえば、監査、解析、通知、メトリクスなど)。以下は対応する機能の例である。
一実施形態において、SSOクライアントAPIインテグレータ1022Aはリソースマネージャ1026Aと通信し、テナント固有SSO設定が格納され管理サーバのリソースマネージャ1026Aで利用できる。認証スキーム、セッションタイムアウトなどのSSO設定は、SSOランタイムサーバに、REST要求を介して読み込まれる。これらの設定の読み込みはネットワークコールを必要とするので、これらの設定に何らかの変化があれば通知されるコールバック機構があるという前提において、テナントごとにキャッシュすることができる。以下は、リセットマネージャ1026Aの機能の一例である。
一実施形態において、UIサービス1008Aは、SSOサービス1002Aを消費するエンドユーザのための対話ポイントを提供し、以下のような動作を提供する。
・認証、パスワード管理のためのエンドユーザからのクレデンシャル収集、およびJSONベースのRESTコールを介した各SSOサービスエンドポイントの呼び出し
・SSOサービス1002Aで開始されたJSONのRESTコールのさまざまなエラーシナリオの処理
・SSOサービス1002Aが引き起こしたさまざまなエラーであって、SSOサービス1002Aが開始したリダイレクトを通してプロトコルレイヤとやり取りする間に発生したさまざまなエラーの処理
一実施形態において、SSOコントローラ1012Aは、上記ケースの場合、以下のフローに従って、UIサービス1008Aを提供する。
プロトコル3レッグエンドユーザフローにおいて
・エンドユーザが、RP1006A(たとえば、プロトコル固有ゲートキーパーエージェント)によって保護されるアプリケーションにアクセスする。
・RP1006Aは、プロトコルのインタラクションをトリガし、プロトコルレイヤはエンドポイント「/sso/v1/user/login」にリダイレクトする。
・エンドポイントは、IDAAS_REQクッキーにコンテキストを設定した後にSSOサービス1002Aに戻る。
・SSOサービス1002Aは、IDAAS_REQクッキー内のテナントヘッダを読み取り、テナント構成に基づいて、エンドポイント「/member/v1/signin」にリダイレクトすることにより、遠隔IDP 1036AかまたはログインUIサービス1008Aをコールする。
・UIサービス1008Aは、クレデンシャルを収集し、エンドポイント「sso/v1/user/login」上のポスト方法に、JSON要求を介してこれらのクレデンシャルをサブミットする。
・SSOサービス1002Aはクレデンシャルを検証する。失敗の場合、階層(たとえば2レベル:メジャーおよびマイナー)エラーコードでUIサービス1008Aに応答する。パスワードリセット時は、次の動作(「nextOp」)およびそれぞれのエラーコードがUIサービス1008Aに送信される。成功の場合、ポストログインがイネーブルされているのであれば、それぞれのnextOpがUIサービス1008Aに送信される。成功の場合、ポストログインがディスエーブルされているのであれば、JSONレスポンスは、nextOpとともに、ペイロード内の「redirectUrl」を有する「リダイレクト」として、戻される。「redirectUrl」は、IDAAS_REQクッキーから得たプロトコルレイヤのコールバックURLである。どちらの成功のケースにおいても、IDCS_SSOクッキーが生成されレスポンス時にユーザのブラウザに設定される。
・ポストログインがイネーブルされ動作がUIによって完了したときに、不同意または同意の場合、コントロールはJSON要求を通してSSOサービス1002Aに戻る。
・SSOサービス1002Aは、同意/不同意でIDAAS_クッキーを更新し、レスポンスを、nextOpとともに、ペイロード内の「redirectUrl」を有する「リダイレクト」として送信する。
・プロトコルレイヤは、IDCS_SSOクッキーを読み取り、RP1006Aに戻すプロトコル固有トークンを生成する。
・RP1006Aは、トークンを読み取ってアプリケーション固有クッキーを設定し、そうすると、ユーザはアクセスが付与されクッキーを有するアプリケーションにアクセスできる。
クラウドゲートからの基本的な認証フローにおいて
・エンドユーザ/クライアントが、ユーザ名およびパスワード認証ヘッダでクラウドゲートにより保護されているリソースにアクセスする。
・クラウドゲートは、リソースが基本認証によって保護されていることを確認し、ペイロード内のポストHTTP要求およびクレデンシャルデータで、「/sso/v1/user/login」のエンドポイントをコールする。
・IDCS_REQUESTはなく属性は存在する:「RPID」、「リファラー」は、SSOコントローラのフローを異なるハンドラ「BasicAuthHandler.java」に分岐させて基本認証を処理する条件である。
・「BasicAuthHandler」は、JSONペイロード内のクレデンシャルの検証のみを実行し、認証コンテキストを有するIDCS_SSOクッキーを設定することなく、成功/失敗情報で応答する。
・これはまた、認証のためのSSOイベントを処理し、JSONレスポンスのクレデンシャル検証中にエラーコードを伝播させる。
自動ログイン(初めての使用)およびUIからのパスワード変更フローにおいて
・テナントアドミニストレータが管理UIからのユーザおよびその電子メールをプロビジョニングし、期間限定トークンを有するURLを含む電子メールがユーザに送信される。
・ユーザは、トークンで、UIサービス1008Aにアクセスするためのリンクをクリックする。UIサービス1008Aは、トークンをアイデンティティサービスで検証し、クレデンシャルを収集する。
・UIサービス1008Aは、クレデンシャルをアイデンティティサービスに通知してバックエンドを更新する。
・UIサービス1008Aはさらに、operation/op:「cred_submit」を有しIDCS_REQクッキーなしの、JSONペイロード内に設定された「redirectURL」属性で、自動ログインのためにSSOコントローラのエンドポイント「/sso/v1/user/login」を通知する。これは、「CredSubmitHandler」によって処理される。
・SSOコントローラ1012Aは、リダイレクトURLを以下の優先順位で取得する。
1)IDCS_REQUESTからのコールバックURL
2)IDCS_REQUESTクッキーが存在しない場合に限り、JSONペイロード内の「redirectURL」属性
3)「IDCS_REQUEST」クッキーも「redirectURL」属性も存在しない場合は、認証が成功するとリダイレクトのために「マイサービス」URLを使用
SSO状態およびフロー
図10Bは、一実施形態におけるSSO機能の状態およびフロー図の一例1000Bを示す。図10Bの実施形態は、忘れられたパスワード、アカウントログ、SAML SPからの要求およびIDPなどのアイデンティティ動作ごとのSSOコントローラエンジンフロー図の一例を提供する。この実施形態において、SSOサービス1002aはモジュラー構成を有する。この構成では、モジュールがグローバル状態を利用し互いにおよびプロトコルレイヤとやり取りする(たとえばOpenID接続、SAMLなど)。本実施形態は、状態を安全に伝達するための新たなメカニズムを提供する。状態のサイズは、状態が小さな空間を占め動作がより高速で実行されるよう、効率的に構成される。本実施形態は、マルチファクタ認証、ステップアップ認証などまで向上できることを保証するのに適したやり方で構成される。本実施形態は、追加の認証プラグインが簡単に追加でき追加のステップアップ認証を提供できるように適応構成を提供する。本実施形態はまた、同一のコンポーネント/モジュールを用いて、ポリシーベースの認証チェックといった他の機能を実行することができる。
一実施形態において、プロトコルレイヤ(たとえばOAuth、SAMLなど)とSSOサービス1002aとの間のやり取りは、HTTPを通して実行される。これらは、要求コンテキスト(クッキーにおいてパースされた)における特定の状態の相違を通して通信し、(その状態の固定属性に基づいて)どこに戻るべきかを常に把握している。たとえば、SSOサービス1002aが主導権を得て、要求の取得元であるプロトコルに基づき、どこへ行くべきか判断する。プロトコルは、エンドURLまたはリターンURLを状態に設定している。SSOサービス1002aは、これに従うにあたり、認証後に、または成功もしくは失敗後に、SSOサービス1002aが何を見出すかに基づく。同様に、プロトコルは、たとえばトークンを求める要求に関する何らかの情報を得ると、要求クッキーにおいて指定されたコンポーネントにおいて追跡する。
一実施形態において、状態は、プロトコルごとのコンポーネントデータを含む異なるマップオブジェクトを含む。たとえば、認証された要求をOAuthが取得したとき、これは、要求を誰から取得したかなどを示す追跡情報を含む。一実施形態において、OAuthは、特定のコンポーネントデータにおいてこの情報を追跡し、要求クッキーを初期化する。要求クッキーに書き込むためのキーは、コンポーネント(たとえば、OAuth、SAML、SSOなど)間で共有され、これらのコンポーネント間には、たとえば、どのようなデータをどこに書き込むべきか、データはいつ書き込むべきかなどについて、共通理解がある。たとえば、本実施形態が「n」個のラウンドトリップの記録をとる必要があるとき、どのような量のデータを要求クッキーに入れるべきかについて共通理解があり、そのため、次のコンポーネントはできるだけ多くのクッキーを利用できる。状態は、暗号化された安全なクッキーとしてフロースルーする。暗号化されたクッキーとしてデータをフローするという点についてセキュリティが懸念されるとき、一実施形態は、「302」に参加する要求クッキーではなく、暗号化されたペイロードポストとして状態を構成する。本実施形態はHTTPポストとしてポートする(port)。
一実施形態において、たとえば、RP 1016aは、保護されているリソースにアクセスするための要求をブラウザから受信する場合がある。RP 1016aは、302 /認可または302 SSO/SLOをIDCS OP/IDP/SAML SP 1020aに送ると、これは、302/sso/v1/ユーザログインを、IDCS_REQUESTアプリケーションコンテキストとともに、SSOコントローラ1004aに送信する。
IDCSログインフローは、SSO、OP、SAML、IDP、SAML SPおよびログインアプリケーション(クレデンシャル収集およびパスワード管理JSクライアント)間の要求/レスポンスのシーケンスであり、ウェブシングルサインオンを提供する。IDCS_REQUESTクッキーは、SSOとチャネルコンポーネントとの間のさまざまな要求/レスポンスフロー間の状態を維持するために使用される。IDCS_REQUESTクッキーのキーは、SSOとチャネルコンポーネントとの間で共有される。ログインアプリケーションおよびSSOサービスは、RESTエンドポイントを介して互いにやり取りする。状態情報は、これらの間でJSONペイロードとして送られる。
要求の振る舞い
IDCS SSOサービス1002aは、以下の異なる種類の要求を処理する。(1)IDCS OP/IDPサービス1020aからの要求、(2)IDCS SPサービス1020aからの要求、(3)ログインアプリケーション1042bから認証クレデンシャルをサブミットするログインアプリケーションからのAjax HTTP POST要求、(4)パスワード管理動作の完了に成功した後のログインアプリケーション1042bからのAjax HTTP POST要求、および(5)ポストログイン動作の完了に成功した後のログインアプリケーション1042bからのAjax HTTP POST要求である。
OP/IDPサービス1020aからの要求は、IDCS_REQUEST httpクッキーとしてOP/IDPからSSOにサブミットされる要求+状態データを有するであろう。クッキーは、暗号化されたデータなどとともに、IDCSホストクッキーとして保存されるであろう。クッキーのキーは、OP/IDP/SSO間で共有されるであろう。このキーは、以下のようにテナント作成動作中にテナントデータを初期化する時点で作成されるキーリソースと呼ばれるものであろう。
1.RP ID:RP/SPによって表される接続されたアプリケーションのid
2.リファラー:ユーザブラウザがOP/IDPにリダイレクトされる時点におけるHTTPリファラー
3.コールバックURL:戻ってOP/IDPログインレスポンスフローを示すURL
OP/IDPからの要求に対するレスポンスの振る舞いについて
1.SSOは、ログインアプリケーション状態でIDCS_REQUESTを更新し、ログインアプリケーションにリダイレクトすることによって、構成されたすべてのログインオプションとともに動的ログインを示す。
2.連携SSOが唯一の選択肢である場合は、SSOそのものがIDCS SPサービスにリダイレクトして連携SSOを遠隔IDPとともに開始する。
3.有効IDCS_SESSIONの場合、SSOは、IDCS_SESSIONクッキーからフェッチしたユーザをアサートする。
a.ユーザのアサートに失敗した場合、SSOは、アサート失敗の詳細でIDCS_REQUESTクッキーを更新し、IDCS_SESSIONクッキーを削除し、ログインアプリケーションにリダイレクトする。ログインアプリケーションは、ログインアプリケーション状態に基づいてカスタマイズされたエラーとともにログインページを示す。
b.アサートに成功した場合、SSOは、もしそこになければチャネルログアウト詳細でIDCS_SESSIONを更新し、IDCS要求クッキーの内容をIDCS_REQクエリ/POSTパラメータとして設定し、IDCS要求クッキーを削除し、IDCS_REQUESTクッキーに格納されているIDCSチャネル/callbackUrlにリダイレクトする。
SPサービスからの要求について、SPサービスは、
1.IDCS要求クッキーからSAML−SP状態を読み取って削除し、
2.SAMLアサーションを処理しこれをローカルユーザにマッピングし、
3.連携SSO動作の結果(ステータス、userID...)をOCIS_REQ_SPクエリ/POSTパラメータとして設定し、
4.IDCS_REQクエリ/POSTパラメータとともにSSOサービスにリダイレクトする。
SPからの要求に対するレスポンスの振る舞いについて、SP状態の有効なIDCS_REQUESTの場合、SSOは、SP状態をチェックし、
1.SP状態ステータスが失敗であれば、SSOは、アサート失敗の詳細でIDCS_REQUESTクッキーを更新し、ログインアプリケーションにリダイレクトする。ログインアプリケーションは、ログインアプリケーション状態に基づいてカスタマイズされたエラーとともにログインページを示す。
2.SP状態ステータスが成功であれば、SSOは、認証コンテキストとともにIDCS_SESSIONを作成し、IDP開始連携であるか否かをチェックし、ポストログインがイネーブルされていなければ、
a.idcsSSOInitiated:フローがSSOサービスによって開始されたか否かを含む(ブール)
b.偽であれば、SSOサービスは、ssoResponseFedSSOReturnURLをチェックする必要があり、
i.ssoResponseFedSSOReturnURLがナルであれば、SSOサービスはIDCS要求クッキーを削除しMyConsoleにリダイレクトし、
ii.そうでなければ、SSOサービスは、IDCS要求クッキーを削除し、ssoResponseFedSSOReturnURLにリダイレクトし、
c.真であれば、SSOサービスはcallbackURLにリダイレクトする。なぜなら、連携SSOフローはIDCS SSOサービスによって開始されたからである。
3.ポストログインがイネーブルされた場合、SSOは、ポストログインフローであることを示すためにフラグで更新されたログインアプリケーション状態のログインアプリケーションにユーザをリダイレクトする。
認証クレデンシャルをサブミットするログインアプリケーションからの要求について、ログインアプリケーションは、クレデンシャルを収集し、これらのクレデンシャルをSSOサービスRESTエンドポイントに通知する。クレデンシャルはJSONペイロードとして送られる。
認証クレデンシャルをサブミットするログインアプリケーションからの要求に対するレスポンスの振る舞いについて、SSOは、通知されたクレデンシャルを認証し、次のように検証する。
1.認証ステータスが成功であれば、SSOは、認証とともにIDCS_SESSIONを作成し、ユーザをIDCS_REQUEST内の/callBackUrlにリダイレクトする、または、Ajaxレスポンスを、テナント固有の構成に基づいてログインアプリケーションに送る。
2.認証ステータスが失敗でその理由が「パスワード期限切れ」の場合、SSOは、パスワード管理状態を有するJSONペイロードとともにAjaxレスポンスを送り、パスワードリセット動作をログインアプリケーションが開始するようにする。状態は、ユーザアイデンティティ情報とフラグとを含み、意図されている動作が「期限切れパスワードのパスワードリセット」であることを示す。
3.その他すべての認証ステータス失敗理由について、SSOは、ログインアプリケーション状態を有するJSONペイロードとともにAjaxレスポンスを送る。ログインアプリケーション状態をログインアプリケーションが使用してカスタムエラーメッセージを示す。
パスワード管理動作の完了に成功した後のログインアプリケーションからの要求に対し、ログインアプリケーションは、新たなパスワードを収集し、これを、構成されたテナント固有ポリシールールを用いて検証する。パスワードリセットの完了に成功すると、ログインアプリケーションは、IDCS_REQUESTクッキーの可用性をチェックする。IDCS_REQUESTクッキーが利用できる場合、これは、Ajax POST要求を、パスワード管理状態を有するJSONペイロードとともにSSOサービスRESTエンドポイントに送る。IDCS_REQUESTクッキーが存在しない場合、ログインアプリケーションはIDCS管理コンソールURLにリダイレクトする。
パスワード管理動作の完了に成功した後のログインアプリケーションからの要求に対するレスポンスの振る舞いについて、SSOは、パスワード管理状態のユーザ情報をアサートする。
1.アサートが失敗に終わった場合、SSOは、Ajaxレスポンスを失敗の詳細とともにJSONペイロードとしてログインアプリケーション状態に送る。
2.アサートが成功した場合、SSOは、IDCS_SESSIONを作成し、ポストログインが不要であればIDCS_REQUESTの/callBackUrlにユーザをリダイレクトするか、または、ログインアプリケーション状態とともにJSONペイロードとしてAjaxレスポンスをログインアプリケーションに送ることによりポストログインページを示す。
ポストログイン動作の完了が成功した後のログインアプリケーションからの要求について、ログインアプリケーションは、ポストログインページを示し、ポストログイン関連動作を処理する。ポストログイン動作の完了に成功すると、ログインアプリケーションは、フラグとともにログインアプリケーション状態のAjaxポスト要求を送ることにより、JSONペイロードとして、ポストログイン動作に成功したことを示す。IDCS_REQUESTクッキーでなければ、ログインアプリケーションはIDCS管理コンソールURLにリダイレクトする。
ポストログイン動作の完了に成功した後のログインアプリケーションからの要求に対するレスポンスの振る舞いについて、SSOは、ポストログインフラグがログインアプリケーションによってログインアプリケーション状態に設定されているか否かをチェックする。設定されている場合、
1.idcsSSOInitiated:フローがSSOサービスによって開始されたか否かを含む(ブール)
A.偽であれば、SSOサービスは、ssoResponseFedSSOReturnURLをチェックする必要があり、
i.ssoResponseFedSSOReturnURLがナルであれば、SSOサービスはIDCS要求クッキーを削除しMyConsoleにリダイレクトし、
ii.そうでなければ、SSOサービスは、IDCS要求クッキーを削除し、ssoResponseFedSSOReturnURLにリダイレクトし、
B.真であれば、SSOサービスはcallbackURLにリダイレクトする。なぜなら、連携SSOフローはIDCS SSOサービスによって開始されたからである。
開示されている通り、実施形態は、如何にしてユーザが認証され如何にしてログインセレモニーが実行されるかを指示するSSOサービスを提供する。ログインは、異なる種類の認証ファクタ構成(たとえば、1ファクタ、2ファクタ、生体認証など)に基づいていてもよい。本実施形態は、モジュール方式であり(モノリシックな1つのコードではない)、コントローラレイヤを含み、特定の各認証はプラグインとして実現される(たとえば、LDAPに対して認証することができるユーザIDパスワードのためのプラグインモジュール、証明書ストアに対して認証するためのX.509認証用のプラグインモジュール、SMSのモバイルファクタに基づくモバイル認証のためのプラグイン、QRコード(登録商標)に基づく登録のためのプラグインなど)。一実施形態において、SSOシステムは、認証モジュールをプラグインできるサービスプロバイダインターフェイス(service provider interface:「SPI」)レイヤを含む。本実施形態は、検証対象のクレデンシャルをUIがサブミットするフローを調整する。本実施形態は、プロトコルレイヤとは関係なく、たとえばOpenID Connectであろうと、SAMLであろうと、OAuthであろうと、SSO機能を実行する。本実施形態は、ログインフローおよびログアウトフローのためのIDCSアクセス全体のための中央コントローラの役割を果たすSSOサービスを提供し、すべてのプロトコルに対してサービスが寛容になるようにするために、豊かで最適化され正規化された状態を使用する。一実施形態は、異なるアイデンティティストア(たとえば遠隔IDP、ローカルアイデンティティストアなど)に対してユーザをアサートするための機能を提供する。
シングルログアウト(「SLO」)
一実施形態は、アプリケーション各々を保護するために使用されるプロトコルに対して寛容であるグローバルログアウトプロシージャを提供する。一実施形態において、ログアウトプロシージャは、各プロトコルエンドポイントのログアウトをトリガすることができ、かつ、各プロトコルが保護している実際のアプリケーションのログアウトもトリガすることができる。
一実施形態において、たとえば、OAuthによって保護されるアプリケーションがいくつか存在するとき、OAuthサービスは、SSOサービスに接触することにより、グローバルセッションおよびグローバル状態全体を取得する。グローバル状態は、マップとして保持され、各プロトコルからの正規化状態を含む。プロトコルごとに、グローバル状態は、帰るためのエンドポイントと、当該プロトコルが保護している訪れたURLとを保存する。SSOログアウトは、プロトコルログアウトだけでなく、各アプリケーションのログアウト、ログアウト画像、またはログアウトエンドポイントもトリガすることができる。
一実施形態において、各ログアウト後に、コントロールはSSOサービスに戻り(すなわち要求フローがSSOサービスに戻る)、よって本実施形態は新規の中央ログアウトコントローラを提供することができる。たとえば、ログアウトは、アプリケーションエンドポイントから始まりその後対応するプロトコルに進むことができる。次に、当該プロトコルはSSOサービスに来る。SSOサービスは、このプロトコルのログアウトをトリガするとともに、このプロトコルが保護する訪れたアプリケーションをトリガする。これが行われると、コントロールは再びSSOサービスに戻る。
次に、SSOサービスは、グローバルログアウトが実現されるようSSOサービスがログアウトをトリガする必要があるグローバル状態のものが他にあるか否かを判断する。たとえば、OAuthのログアウトが行われた場合、SSOサービスは、そのログアウトがまだ行われていない別のプロトコルがあるか否かを判断する。次のプロトコルは、たとえばSAMLの可能性がある。この情報はすべて正規化されたグローバル状態である。
ログアウトが必要な次のプロトコルがSAMLである場合、SSOサービスは同じようにしてSAMLログアウトをトリガする(たとえば、プロトコルログアウト、実際に訪れた状態プロトコルまたはアプリケーションなどのログアウト)。SAMLログアウトが行われると、コントロールは再びSSOサービスに戻り、SSOサービスはトリガする次のプロトコルログアウトを判断する。したがって、SSOサービスは、プロトコルすべておよび訪れたアプリケーション(グローバル状態と特定)すべてのログアウトをトリガし続けることにより、グローバルログアウトを完了する。
一実施形態は、グローバル状態の正規化されたログアウトエンドポイント情報を安全に格納する。一実施形態は、すべてのログアウトリダイレクトURLを格納するのではなく、アクセス権を有する各クライアントに対するポインタを格納する。一般的に、OAuthおよびSAMLはいずれも、個々のアプリケーションのログアウトリダイレクトURLを格納するためのプロビジョンを含む。OAuthアプリケーションがOAuthサービスにアクセスすると、対応するクライアントIDが追跡され、SSOセッションにおいてそれぞれの特定のコンポーネントにおいてパーシストされる。同様に、SAMLアプリケーションがSAMLサービスにアクセスすると、対応するSP IDが追跡され、SSOセッションにおいてそれぞれの特定のコンポーネントにおいてパーシストされる。グローバルログアウトURLが(たとえば、アプリケーションログアウトURL、SSOグローバルログアウトURLなどのうちの1つにアクセスすることによって)トリガされると、コントロールは常にSSOサービスに来る。そうすると、SSOサービスは、グローバルセッションを削除し、それ以上使用されないように有効期限を現在の時間に設定してセッションクッキーを更新し、各コンポーネントをログアウトさせる。
一実施形態は、各ログアウト後にコントロールが確実にSSOサービスに戻るようにする。そうするために、ログアウトをトリガするときに、本実施形態は、セッションの一部としてアクセスまたは追跡されたアプリケーションのリストを求め、HTMLページに埋め込まれた画像のソースとしてログアウトURLを構成し、最後の画像ソースをSSOのリダイレクトURLとして構成する。ダミーHTMLページがユーザブラウザへのレスポンスとして送信されHTMLページがロードされると、画像ソースは非同期でロードされる。各画像ソースはログアウトURLであるので、ログアウトがトリガされ、レスポンスは、個々のアプリケーション各々のクッキーをアンセットするセットされたクッキーコールである。最後の画像の一部分がSSOのリダイレクトURLなので、本実施形態は、SSOサービスを非同期でコールし、要求フローはSSOサービスに戻る。
一実施形態において、SSOサービスが、このHTMLページを、ログアウトが既にトリガされているコンポーネントのリストとともに送信すると、これは、これらのコンポーネントを削除する。そのため、次回コントロールがSSOサービスに戻ったときに、どのようなログアウトが実施されたかおよびこれから何をログアウトするかを把握しており、リストが空になるまで続ける。
このように、一実施形態は、グローバルログアウトを、異なるアプリケーションの異なるログアウトエンドポイントを統合して画像にし、これらをHTMLページに埋め込み、プロトコルをこのページにリダイレクトさせて、すべての画像がロードされログアウトURLが続くようにし、また、画像を埋め込んでSSOサービスに戻るようにする。異なるアプリケーションの異なるログアウトエンドポイントは、たとえばSAML、OAuthなどの異なるプロトコルに基づいていてもよい。
一実施形態において、たとえば、OAuthによって保護されるいくつかのアプリケーションをエンドユーザが有しているとき、SSOサービスはグローバルセッションを構築する。これらのアプリケーションにアクセスしている間、ユーザはまた同じグローバルセッションに基づくSAMLトークンによって保護されるその他いくつかのアプリケーションを有し得る。これらのアプリケーション(SAMLまたはOAuth)のうちのいずれか1つからユーザがログアウトしグローバルログアウトを所望すると、ユーザは、すべてのプロトコルから、そのプロトコルとは無関係に、ログアウトする。
一実施形態において、SAMLの場合、遠隔IDP認証の可能性がある。IDPは、それ自身のログアウトを呼び出すことを所望することがある外部パーティである。この場合、本実施形態は、SAML呼出ログアウトを示す要求クッキーに情報を実現する。したがって、本実施形態は、遠隔認証ログアウトを呼び出すことができるよう、機能を提供する。
一実施形態において、SSOクッキーは、IDCSホストのみを対象にする安全なホストクッキーであり、信頼できる情報源である。IDCSコンポーネントを除いて、ホストクッキーを受けるエンティティはない。代わりに、各トークンが生成され、IDCSの外側にあるアプリケーションに与えられる。
ログイン/ログアウトフロー
図11は、一実施形態における、IDCSによって提供されるSSO機能のメッセージシーケンスフロー1100である。ユーザがブラウザ1102を用いてクライアント1106(たとえばブラウザベースのアプリケーションまたはモバイル/ネイティブアプリケーション)にアクセスするとき、クラウドゲート1104は、アプリケーション施行点として機能し、ローカルポリシーテキストファイルに規定されているポリシーを施行する。クラウドゲート1104は、ユーザがローカルアプリケーションセッションを有していないことを検出した場合、ユーザの認証を要求する。そうするために、クラウドゲート1104は、ブラウザ1102をOAuth2マイクロサービス1110にリダイレクトすることにより、OAuth2マイクロサービス1110に対するOpenID Connectログインフローを開始する(3者間AZ Grantフローであり、範囲=「openid profile」)。
ブラウザ1102の要求は、IDCSルーティング層ウェブサービス1108およびクラウドゲート1104を横断してOAuth2マイクロサービス1110に到達する。OAuth2マイクロサービス1110は、アプリケーションコンテキスト(すなわちアプリケーションを記述するメタデータ、たとえば接続するアプリケーションのアイデンティティ、クライアントID、構成、アプリケーションは何ができるかなど)を構成し、ブラウザ1102をログインのためにSSOマイクロサービス1112にリダイレクトする。
ユーザが有効なSSOセッションを有する場合、SSOマイクロサービス1112は、ログインセレモニーを開始することなく既存のセッションを検証する。ユーザが有効なSSOセッションを有していない場合(すなわちセッションクッキーが存在しない)、SSOマイクロサービス1112は、顧客のログインプリファレンスに従ってユーザログインセレモニーを開始する(たとえば商標付ログインページを表示する)。そうするために、SSOマイクロサービス1112は、ブラウザ1102を、JavaScriptで実現されるログインアプリケーションサービス1114にリダイレクトする。ログインアプリケーションサービス1114はブラウザ1102にログインページを提供する。ブラウザ1102はログインクレデンシャルを含むREST POSTをSSOマイクロサービス1112に送信する。SSOマイクロサービス1112は、アクセストークンを生成し、REST POSTのクラウドゲート1104に送信する。クラウドゲート1104は、認証情報を管理SCIMマイクロサービス1116に送信することによりユーザのパスワードを検証する。管理SCIMマイクロサービス1116は、認証が成功したと判断し、対応するメッセージをSSOマイクロサービス1112に送信する。
一実施形態において、ログインセレモニー中、ログインページは同意ページを表示しない。「ログイン」オペレーションはさらなる同意を要しないからである。代わりに、アプリケーションに対してエクスポーズされている特定のプロファイル属性についてユーザに知らせるプライバシーポリシーが、ログインページ上に記載される。ログインセレモニー中、SSOマイクロサービス1112は顧客のIDPプリファレンスを尊重し、構成され次第、構成されたIDPに対する認証のためにIDPにリダイレクトする。
認証または検証が成功すると、SSOマイクロサービス1112は、ブラウザ1102を、ユーザの認証トークンを含む、新たに作成/更新されたSSOホストHTTPクッキー(たとえば「HOSTURL」が示すホストのコンテキストで作成されたクッキー)を用いて、OAuth2マイクロサービス1110に戻るようにブラウザ1102をリダイレクトする。OAuth2マイクロサービス1110は、AZコード(たとえばOAuthコンセプト)をブラウザ1102に戻しクラウドゲート1104にリダイレクトする。ブラウザ1102はAZコードをクラウドゲート1104に送信し、クラウドゲート1104はREST POSTをOAuth2マイクロサービス1110に送信してアクセストークンおよびアイデンティティトークンを要求する。これらのトークンはどちらも、OAuthマイクロサービス1110にスコーピングされる(オーディエンストークンクレームによって示される)。クラウドゲート1104はこれらのトークンをOAuth2マイクロサービス1110から受ける。
クラウドゲート1104は、アイデンティティトークンを用いて、認証されたユーザのアイデンティティをその内部アカウント表現にマッピングし、これは、このマッピングを自身のHTTPクッキーに保存してもよい。クラウドゲート1104は次に、ブラウザ1102をクライアント1106にリダイレクトする。すると、ブラウザ1102は、クライアント1106に到達し、対応するレスポンスをクライアント1106から受ける。この時点以降、ブラウザ1102は、アプリケーションのローカルクッキーが有効である限り、アプリケーション(すなわちクライアント1106)にシームレスにアクセスすることができる。ローカルクッキーが無効になると、認証プロセスは繰返される。
クラウドゲート1104はさらに、要求に含められたアクセストークンを用いて、「userinfo」をOAuth2マイクロサービス1110からまたはSCIMマイクロサービスから取得する。このアクセストークンは、「プロファイル」スコープによって与えられる属性の「userinfo」リソースにアクセスするには十分である。これは、SCIMマイクロサービスを介して「/me」リソースにアクセスするのにも十分である。一実施形態において、デフォルトで、含まれているアクセストークンは、「プロファイル」スコープの下で与えられるユーザプロファイル属性に対してのみ十分である。他のプロファイル属性へのアクセスは、クラウドゲート1104によって発行されたAZグラントログイン要求において提示された追加の(任意の)スコープに基づいて認可される。
ユーザがOAuth2が統合された別のアプリケーションにアクセスする場合、同じプロセスが繰返される。
一実施形態において、SSO統合アーキテクチャは、ブラウザベースのユーザログアウトに対し、同様のOpenID Connectユーザ認証フローを使用する。一実施形態において、既存のアプリケーションセッションを有するユーザは、クラウドゲート1104にアクセスしてログアウトを開始する。その代わりに、ユーザは、IDCS側でログアウトを開始している場合がある。クラウドゲート1104は、特定用途向けのユーザセッションを終了し、OAuth2マイクロサービス1110に対しOAuth2 OpenID プロバイダ(「OP」)ログアウト要求を開始する。OAuth2マイクロサービス1110は、ユーザのホストSSOクッキーを削除するSSOマイクロサービス1112にリダイレクトする。SSOマイクロサービス1112は、ユーザのSSOクッキーにおいて追跡された既知のログアウトエンドポイントに対し一組のリダイレクト(OAuth2 OPおよびSAML IDP)を開始する。
一実施形態において、クラウドゲート1104がSAMLプロトコルを用いてユーザ認証(たとえばログイン)を要求する場合、同様のプロセスが、SAMLマイクロサービスとSSOマイクロサービス1112との間で開始される。
クラウドキャッシュ
一実施形態は、クラウドキャッシュと呼ばれるサービス/機能を提供する。クラウドキャッシュは、IDCSに与えられて、LDAPベースのアプリケーション(たとえば電子メールサーバ、カレンダーサーバー、何らかのビジネスアプリケーションなど)との通信をサポートする。なぜなら、IDCSはLDAPに従って通信するのではないが、このようなアプリケーションはLDAPに基づいてのみ通信するように構成されているからである。典型的には、クラウドディレクトリは、REST APIを介してエクスポーズされ、LDAPプロトコルに従って通信するのではない。一般的に、企業ファイアウォオールを通してLDAP接続を管理するには、セットアップおよび管理が難しい特殊な構成が必要である。
LDAPベースのアプリケーションをサポートするために、クラウドキャッシュは、LDAP通信を、クラウドシステムとの通信に適したプロトコルに変換する。一般的に、LDAPベースのアプリケーションは、LDAPを介してデータベースを使用する。代わりに、アプリケーションは、SQLのような異なるプロトコルを介してデータベースを使用するように構成されてもよい。しかしながら、LDAPはツリー構造のリソースの階層表現を提供するのに対し、SQLはデータをテーブルとフィールドとして表現する。したがって、LDAPは検索機能用であることがより望ましいであろう。一方、SQLはトランザクション機能用であることがより望ましいであろう。
一実施形態において、IDCSが提供するサービスを、LDAPベースのアプリケーションで使用して、たとえば、アプリケーションのユーザを認証する(すなわちアイデンティティサービス)、またはアプリケーションのセキュリティポリシーを施行する(すなわちセキュリティサービス)ことができる。一実施形態において、IDCSとのインターフェイスは、ファイアウォールを通り、HTTP(たとえばREST)に基づく。典型的に、企業ファイアウォールは、内部LDAP通信へのアクセスを、当該通信がセキュア・ソケット・レイヤ(Secure Sockets Layer:「SSL」)を実現する場合であっても許可しない。また、企業ファイアウォールは、TCPポートがファイアウォールを通してエクスポーズされることを許可しない。しかしながら、クラウドキャッシュは、LDAPとHTTPとの間の変換を行って、LDAPベースのアプリケーションが、IDCSが提供するサービスに到達できるようにし、ファイアウォールはHTTPに対してオープンである。
一般的に、LDAPディレクトリは、マーケティングおよび開発などのビジネスライン(line of business)で使用されてもよく、ユーザ、グループ、業務などを規定する。一例において、マーケティングおよび開発ビジネスは、多様な顧客を対象としている場合があり、顧客ごとに、独自のアプリケーション、ユーザ、グループ、業務などを有し得る。LDAPキャッシュディレクトリを実行し得るビジネスラインの別の例は、無線サービスプロバイダである。この場合、無線サービスプロバイダのユーザが行う各コールは、LDAPディレクトリに対してユーザのデバイスを認証し、LDAPディレクトリ内の対応する情報の一部は課金システムと同期させてもよい。これらの例において、LDAPは、実行時に探索されるコンテンツを物理的に分離するための機能を提供する。
一例において、無線サービスプロバイダは、短期マーケティングキャンペーンを支援するIDCSが提供するサービスを使用する一方で、自身のアイデンティティ管理サービスをそのコアビジネス(たとえば通常のコール)のために扱ってもよい。この場合、クラウドキャッシュは、LDAPを、クラウドに対して実行する一組のユーザおよび一組のグループを有する場合は「平坦にする」。一実施形態において、IDCSにおいて実現されるクラウドキャッシュの数はいくつであってもよい。
分散型データグリッド
一実施形態において、IDCSにおけるキャッシュクラスタは、たとえばその開示を本明細書に引用により援用する米国特許公開第2016/0092540号に開示されている分散型データグリッドに基づいて実現される。分散型データグリッドは、分散環境またはクラスタ環境内で1つ以上のクラスタにおいてコンピュータサーバの集合体が、一緒に作業することにより情報を管理し計算などの関連動作を管理するシステムである。分散型データグリッドを用いることで、サーバ間で共有されるアプリケーションオブジェクトおよびデータを管理することができる。分散型データグリッドは、短いレスポンスタイム、高いスループット、予測可能なスケーラビリティ、継続的なアベイラビリティ、および情報の信頼性を提供する。具体的な例として、たとえばオラクル社のOracle Coherenceのデータグリッドのような分散型データグリッドは、情報をインメモリに格納することによりさらに高いパフォーマンスを達成し、複数のサーバにわたって同期が取られた情報のコピーを保持するにあたって冗長性を用いることにより、サーバ故障イベント時におけるシステムの回復力とデータの継続的なアベイラビリティとを保証する。
一実施形態において、IDCSは、Coherenceなどの分散型データグリッドを実現して、すべてのマイクロサービスがブロックされることなく共有キャッシュオブジェクトへのアクセスを要求できるようにする。Coherenceは、従来のリレーショナルデータベース管理システムと比較して、より高い信頼性、スケーラビリティ、およびパフォーマンスが得られるように設計された、所有権を主張できるJavaベースのインメモリデータグリッドである。Coherenceは、ピアトゥピア(すなわち中央マネージャがない)インメモリ分散型キャッシュを提供する。
図12は、データを格納しデータアクセス権をクライアント1250に与え本発明の実施形態を実現する分散型データグリッド1200の一例を示す。「データグリッドクラスタ」または「分散型データグリッド」は、分散環境またはクラスタ環境内で1つ以上のクラスタ(たとえば1200a、1200b、1200c)において一緒に作業することにより情報を格納し関連する計算などの動作を管理する複数のコンピュータサーバ(たとえば1220a、1220b、1220c、および1220d)を含むシステムである。分散型データグリッド1200は、クラスタ1200aにおいて5つのデータノード1230a、1230b、1230c、1230d、および1230eとともに4つのサーバ1220a、1220b、1220c、1220dを含むものとして示されているが、分散型データグリッド1200は、任意の数のクラスタおよび各クラスタにおける任意の数のサーバおよび/またはノードを含み得る。ある実施形態において、分散型データグリッド1200は本発明を実現する。
図12に示されるように、分散型データグリッドは、一緒に作業する多数のサーバ(たとえば1220a、1220b、1220c、および1220d)にデータを分散させることによってデータ格納および管理機能を提供する。データグリッドクラスタの各サーバは、たとえば、1つから2つのプロセッサソケットと1プロセッサソケット当たり2つから4つのCPUコアとを有する「コモディティ(commodity)x86」サーバハードウェアプラットフォームのような、従来のコンピュータシステムであってもよい。各サーバ(たとえば1220a、1220b、1220c、および1220d)は、1つ以上のCPUと、ネットワークインターフェイスカード(Network Interface Card:「NIC」)と、たとえば最小で4GBのRAM最大で64GB以上のRAMを含むメモリとで構成されている。サーバ1220aは、CPU1222aと、メモリ1224aと、NIC1226aとを有するものとして示されている(これらの要素は他のサーバ1220b、1220c、1220d上にもあるが図示されていない)。任意で、各サーバにフラッシュメモリ(たとえばSSD 1228a)を設けることで過剰な記憶容量を提供してもよい。提供時、SSD容量は、好ましくはRAMのサイズの10倍である。データグリッドクラスタ1200aのサーバ(たとえば1220a、1220b、1220c、1220d)は、高帯域幅のNIC(たとえばPCI−XまたはPCIe)を用いて高性能ネットワークスイッチ1220(たとえばギガビット以上のイーサネット(登録商標))に接続されている。
クラスタ1200aは、故障中にデータが失われる可能性を避けるために最小で4つの物理サーバを含むことが好ましいが、典型的な設備はより多くのサーバを有する。各クラスタに存在するサーバが多いほど、フェイルオーバーおよびフェイルバックの効率は高く、サーバの故障がクラスタに与える影響は小さくなる。サーバ間の通信時間を最短にするために、各データグリッドクラスタは、サーバ間の単一ホップ通信を提供する単一のスイッチ1202に限定されることが理想的である。このように、クラスタは、スイッチ1202上のポートの数によって制限される。したがって、典型的なクラスタは4〜96の物理サーバを含む。
分散型データグリッド1200のほとんどの広域ネットワーク(Wide Area Network:「WAN」)構成において、WAN内の各データセンターは、独立しているが相互に接続されているデータグリッドクラスタ(たとえば1200a、1200b、および1200c)を有する。WANは、たとえば図12に示されるクラスタよりも多くのクラスタを含み得る。加えて、相互接続されているが独立しているクラスタ(たとえば1200a、1200b、1200c)を用いることにより、および/または相互接続されているが独立しているクラスタを、互いに離れているデータセンター内に配置することにより、分散型データグリッドは、自然災害、火災、洪水、長期停電などによって生じる、1つのクラスタのすべてのサーバの同時損失を防止すべく、クライアント1250に対するデータおよびサービスを保証することができる。
1つ以上のノード(たとえば1230a、1230b、1230c、1230dおよび1230e)は、クラスタ1200aの各サーバ(たとえば1220a、1220b、1220c、1220d)上で動作する。分散型データグリッドにおいて、ノードは、たとえばソフトウェアアプリケーション、仮想マシンなどであってもよく、サーバは、ノードがその上で動作するオペレーティングシステム、ハイパーバイザなど(図示せず)を含み得る。Oracle Coherenceのデータグリッドでは、各ノードはJava仮想マシン(Java virtual machine:「JVM」)である。CPUの処理能力およびサーバ上で利用できるメモリに応じて、各サーバ上に多数のJVM/ノードを設けてもよい。JVM/ノードは、分散型データグリッドの要求に応じて、追加、起動、停止、および削除されてもよい。Oracle Coherenceを実行するJVMは、起動時に自動的に参加しクラスタ化する。クラスタに加わるJVM/ノードは、クラスタメンバまたはクラスタノードと呼ばれる。
各クライアントまたはサーバは、情報伝達のためにバスまたはその他の通信機構を含み、情報処理のためにバスに結合されたプロセッサを含む。プロセッサは、どのタイプの汎用または専用プロセッサであってもよい。各クライアントまたはサーバはさらに、プロセッサによって実行される命令および情報を格納するためのメモリを含み得る。メモリは、ランダムアクセスメモリ(「RAM」)、読出専用メモリ(「ROM」)、磁気もしくは光ディスクなどのスタティックストレージ、またはその他任意の種類のコンピュータ読取可能媒体を組み合わせたもので構成することができる。各クライアントまたはサーバはさらに、ネットワークへのアクセス提供のためにネットワークインターフェイスカードなどの通信デバイスを含み得る。したがって、ユーザは、各クライアントまたはサーバに対して、直接、またはネットワークを通して遠隔から、またはその他任意の手段で、インターフェイスすることができる。
コンピュータ読取可能な媒体は、プロセッサからアクセスすることが可能な利用可能な媒体であればどのようなものでもよく、揮発性媒体および不揮発性媒体、リムーバブルおよび非リムーバブル媒体、ならびに通信媒体を含む。通信媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、または、たとえば搬送波もしくはその他の搬送機構などの変調されたデータ信号内のその他のデータを含んでいてもよく、任意の情報伝達媒体を含む。
プロセッサはさらに、液晶ディスプレイ(「LCD」)などのディスプレイにバスを介して結合されてもよい。キーボード、およびコンピュータマウスなどのカーソル制御デバイスが、さらにバスに結合されることにより、ユーザが各クライアントまたはサーバに対してインターフェイスできるようにしてもよい。
一実施形態において、メモリは、プロセッサが実行すると機能を提供するソフトウェアモジュールを格納する。モジュールは、各クライアントまたはサーバにオペレーティングシステム機能を提供するオペレーティングシステムを含む。モジュールはさらに、クラウドアイデンティティ管理機能を提供するためのクラウドアイデンティティ管理モジュールと、本明細書に開示されているその他すべての機能とを含み得る。
クライアントは、クラウドサービスなどのウェブサービスにアクセスし得る。一実施形態において、ウェブサービスは、オラクル社のWebLogicサーバ上で実現されてもよい。他の実施形態ではウェブサービスの他の実装形態を使用してもよい。ウェブサービスは、クラウドデータを格納しているデータベースにアクセスする。
開示されている通り、実施形態は、マイクロサービスに基づくアーキテクチャを実現してクラウドベースのマルチテナントIAMサービスを提供する。一実施形態において、要求された各アイデンティティ管理サービスは、中間層のマイクロサービスによって処理されるリアルタイムタスク、および、メッセージキューにオフロードされるニア・リアルタイムタスクに分割される。このように、実施形態はクラウドスケールのIAMプラットフォームを提供する。
図13は、ある実施形態に従うクラウドベースのIAM機能のフロー図1300である。一実施形態において、図13のフロー図の機能は、メモリまたはその他のコンピュータ読取可能なまたは有形の媒体に格納されプロセッサによって実行されるソフトウェアにより、実現される。その他の実施形態において、この機能は、ハードウェアによって(たとえば、特定用途向け集積回路(「ASIC」)、プログラマブルゲートアレイ(「PGA」)、フィールドプログラマブルゲートアレイ(「FPGA」)などを通して)実行されてもよく、または、ハードウェアとソフトウェアとの何らかの組み合わせであってもよい。
1302で、アプリケーションにアクセスすることを可能にするように構成されたアイデンティティ管理サービスを求める第1の要求を受信する。一実施形態において、たとえば、第1の要求を受信するのは、たとえば本明細書において図6のウェブルーティング層610を参照して説明したクラウドゲートおよび/または図7のクラウドゲート702などの、セキュリティゲートである。一実施形態において、第1の要求は、アイデンティティ管理サービスおよびこのアイデンティティ管理サービスを実行するように構成されたマイクロサービスを特定するAPIに対するコールを含む。一実施形態において、マイクロサービスは、他のモジュール/マイクロサービスと通信可能な内蔵モジュールであり、各マイクロサービスは、他からコンタクト可能な無名ユニバーサルポートを有する。たとえば、一実施形態において、図6に示されるようにIDCSマイクロサービス614を使用するためにさまざまなアプリケーション/サービス602がIDCS APIに対するHTTPコールを実施することができる。一実施形態において、マイクロサービスはランタイムコンポーネント/プロセスである。
1304で、第1の要求をマイクロサービスに送信し、マイクロサービスは、トークンを生成することによってアイデンティティ管理サービスを実行し、マイクロサービスは、シングルサインオンマイクロサービスに第2の要求を送信することによって少なくとも部分的にトークンを生成し、シングルサインオンマイクロサービスは、異なるプロトコルに基づく異なるマイクロサービスにまたがるシングルサインオン機能を提供するように構成されている。
1306で、トークンをマイクロサービスから受信し、1308で、トークンをアプリケーションに与える。トークンは、アプリケーションにアクセスすることを可能にする。
図14は、一実施形態に従う、コンポーネントの各種機能およびクッキー伝播機能を示すログアウトフローである。図14に含まれるコンポーネントまたはレイヤは、エンドユーザクライアント(または依拠当事者1(relying party:「RP1」))1401、OIDCレイヤ1402、SSOレイヤ1403およびSAMLレイヤ1404を含む。図14は、ログアウトおよびクッキーのクリアに関連している。
1420で、クライアント1401は、典型的にはログアウトURLを通してログアウトをトリガする。1421で、OIDC1402は、クライアント1401のためのリターンURLをクッキー(たとえばIDCS_REQクッキー)に格納する。これは、クライアント1401の対応するブラウザに格納される。リターンURLは、クライアント1401の最終の成功ログアウトランディングページであってもよい。
1429で、認証コンテキストがクリアされる。1430で、SSOクッキーのコンポーネントデータマップからのSSOコンポーネントエントリがクリアされる。1431で、OAuthエントリがこのコンポーネントデータマップにあるか否かが判断される。
1431でyesの場合、HTML303はOIDC1402レイヤにリダイレクトし、1423で、OAuthエントリ値が読み取られ、クライアントIDが取り出される。
1424で、クライアントIDに対応するログアウトURLがフェッチされる。一実施形態において、クライアントAPIを用いて特定のクライアントIDのログアウトURLをクエリする。1425で、OAuthコンポーネントが、SSOクッキーのコンポーネントデータマップからクリアされる。1427で、HTMLレスポンスが、src属性がRPのログアウトURLに設定されている画像タグとともに生成される。最後の画像タグは、SSOサービスログアウトURLに設定されたsrc属性を有するであろう。1428で、HTMLレスポンスがレンダリングされる一方で、SSOサービスエンドポイントへのsrc属性を有する最後の画像タグを実行する。新たなHTTP GET要求が、SSOサービスログアウトエンドポイントに送信される。HTML302リダイレクトは、機能をSSOレイヤ1403に移し、1429で機能は続行される。
1431でnoであれば、1432で、コンポーネントデータマップにSAMLエントリがあるか否かを判断する。1432でyesであれば、1433で、SAMLログアウトフラグ(「logoutSAMLInvoke」)がクッキーにおいて真として設定されたか否か判断する。1433でnoであれば、1434でクッキーからログアウトリダイレクトURL値を読み出す。1432でnoであれば1434も実行される。
1435で、ログアウトリダイレクトURL値が空であるかナルであるかを判断する。1435でyesであれば、1436でテナントのログアウトランディングページがSSO設定からフェッチされる。1435でnoであれば、または1436の後に、1437でSAMLログアウトをスキップするか否かが判断される。
1437でyesであれば、1438で、HTML302は、もしあればログアウトリダイレクトURLにリダイレクトする、または、SSO設定からのテナントログアウトランディングページにリダイレクトする。リダイレクトは、クライアント1401のログアウトランディングページへのリダイレクトであろう。次に、1426で、ログアウトページをクライアント1401でレンダリングする。1437でnoであれば、未設定のクッキーを1439で削除し、その後機能は1438に進む。
1433でyesであれば、1442で、SAML1404レイヤにリダイレクトしたHTML300はSAMLログアウトを実行し、接続されているSPのログアウトをトリガする。次に、1441でSAMLエントリをSSOクッキーのコンポーネントデータマップから削除し、機能はSSOレイヤ1403〜1429に進む。
クエリパラメータを用いたSAML−SPからSSOサービスへのリダイレクトURLの一例(SAMLアサート成功)は、1442に示され、たとえば、
http://HOST.us.oracle.com:8990/sso/v1/user/login?OCIS_REQ_SP=kERRx9mNY1SWxvcv5ohVeLjwL0pJAI5yLBNhZRNkK88xD...であろう。「OCIS_REQ」が挿入されている要求パラメータは、SSOによってプロトコル/チャネルコンポーネントに送信される。SAMLからSSOへ、これは上記のように「OCIS_REQ_SP」である。このリダイレクトは、IDCSがオンプレミスidPを用いてユーザを認証するように構成されているときである。IdPがユーザへの問いかけに成功した後、IdPは、SAMLアサーションとともにユーザをIDCS SAML SPにリダイレクトする。IDCS SAML SPはSAMLアサーションを検証し、ユーザをIDCSユーザ記録にマッピングする。IDCS SAML SPは、SAMLのコンポーネントデータをIDCSセッションクッキー「ORA_OCIS」に保存する。次に、IDCS SAML SPは、ユーザをSSOにリダイレクトし、OCIS_REQ_SPクエリ/ポストパラメータに、ユーザデータを、SAMLからSSOへの302/POSTFORMリダイレクトの一部として、与える。OCIS_REQクエリ/フォームパラメータは、SSOからSAML IdPまたはOAuth IdPへの通信時に用いられ、一方、OCIS_REQ_SPクエリ/フォームパラメータは、SAML SPからSSOへの通信時に用いられる。
以下は、一実施形態に従う、連携SAMLアイデンティティプロバイダとのやり取りを開始するためにSSOサービスが使用するSAML SPサービスによって実行されるステップである。SSOサービスは、如何にしてユーザを認証すべきかを判断する。可能性のうちの1つは、連携SSOを用いてユーザを認証することであり、言い換えると、ユーザ認証を、オンプレミスIdPまたは顧客が使用するクラウドサービスIdPである遠隔IdPに委任する。
SSOサービスがユーザを連携サービスにリダイレクトするとき、SSOモジュールは、
・連携SSOに対してどのSAML IdPを使用すべきか
を示すことができなければならない。
連携サービスがユーザをSSOコンポーネントに戻すとき、以下の情報
・ユーザID
・認証時間
・有効期限
・連携メッセージ属性
・IdPパートナー名
が提供されなければならない。
認証要求中の実行時において、SSOサービスは、
●クッキーマネージャを使用して、SAMLサービスが要求したデータを要求クッキーに格納する。
○SSORequestFedSSOIdP:遠隔IDPのIDである。
●ユーザをSAMLサービス認証URL(http://tenant-hostname/fed/v1/user/request/login)にリダイレクトする。
認証要求中における実行時にSAMLサービスが実施することは次の通りである。
●要求クッキーを読み取り、SSOサービスが設定したデータを抽出しかつ削除する。
○SSORequestFedSSOIdP:遠隔IDPのIDである。
●要求クッキーを読み取り、以下のデータを抽出しかつ削除しない。
○SSOECID:OAuth/SAML−IdPサービスによって設定されるECID。SAMLがイベントを記録するために使用する。
●遠隔IdPとともに連携SSOを開始し、
●SAMLユーザに対する入力SAMLアサーションを検証してマッピングし、
●セッションクッキーに書き込むことにより連携データを格納し、
●既存の要求クッキーには接触せず、
●連携SSO動作後のSAML−SPは、連携SSO動作の結果を記述するSSOExternalIdPResponseを作成する。
○ssoResponseFedSSOStatus:ステータスを示すストリング
・SUCCESSは成功を意味し、
・その他のストリングはSAMLエラーコード(たとえばerror.samlsrv.sp.sso.bindingUnknown)である。
○ssoResponseFedSSOUserID:この動作が成功であった場合、このフィールドはユーザGUIDを含むであろう(ストリング)。
○ssoResponseFedSSOIdP:この動作が成功であった場合、このフィールドはIdPパートナー名を含むであろう(ストリング)。
○ssoResponseFedSSONameID:この動作が成功であった場合、このフィールドはSAMLアサーションNameIDを含むであろう(ストリング)。
○ssoResponseFedSSOReturnURL:この動作が成功であった場合であってかつフローがSSOサービスによって開始されなかった場合、このフィールドは、ユーザがリダイレクトする必要があるURLを含むであろう(ストリング)。
○ssoResponseFedSSOAssertionAttributes:この動作が成功であった場合、このフィールドはSAMLアサーション属性を含むであろう(マップ)。
○ssoResponseFedSSOTimeout:この動作が成功であった場合、このフィールドはIdPセッションタイムアウトを含むであろう(ロング)。
○ssoECID:ECIDを含む。
○idcsSSOInitiated:フローがSSOサービスによって開始されたか否かを含む(ブール)。
・偽であれば、SSOサービスはssoResponseFedSSOReturnURLをチェックする必要がある。
・ssoResponseFedSSOReturnURLがナルであれば、SSOサービスはIDCS要求クッキーを削除しMyConsoleにリダイレクトする。
・そうでなければ、SSOサービスは、IDCS要求クッキーを削除し、ssoResponseFedSSOReturnURLにリダイレクトする。
・真であれば、SSOサービスはcallbackURLにリダイレクトする。なぜなら、連携SSOフローはIDCS SSOサービスによって開始されたからである。
●SAML−SPからSSOサービスへのリダイレクトURLは、たとえば、「http://HOST.us.oracle.com:8990/sso/v1/user/login?OCIS_REQ_SP=kERRx9mNY1SWxvcv5ohVeLjwL0pJAI5yLBNhZRNkK88xD...」である。
認証レスポンス中の実行時にSSOサービスが実施することは次の通りである。
●SSOサービスは、クエリパラメータOCIS_REQ_SPの値を取り出してデコードし、データセットをSAMLサービスによって読み取る。
○SSOResponseFedSSOStatus:SUCCESSは成功を示し、FAILUREはエラーコード(たとえばerror.samlsrv.sp.sso.assertion.noUserReturnedViaNameID)に付随し、SSOResponseFedSSOUserID:成功した場合のIDCS UserIDである。
○SSOResponseFedSSOIdP:遠隔IdPのIDである。
○SSOResponseFedSSOTimeout:IdPセッションがタイムアウトする時間(単位:秒)(−1に設定)。
○SSOResponseFedSSONameID:SAMLアサーションNameIDフィールドで使用される識別子。
○SSOResponseFedSSOReturnURL:SSOサービスがIDCSセッションを作成した後にユーザがリダイレクトされるべきURL。このパラメータは、IdPがSSOフローを開始する間にのみ設定される。
○SSOResponseFedSSOAssertionAttributes:SAML SSOアサーションに含まれる属性のリスト。
●要求クッキーを読み取り、抽出して削除する。
○SSOECID:OAuth/SAML−IdPサービスによって設定されるECID。SSOがイベントを記録するために使用。
○rpId、rpName
●ユーザのためにIDCSセッションを作成しデータをセッションクッキーに格納。
●ユーザを以下にリダイレクトする。
●idcsSSOInitiated:フローがSSOサービスによって開始されたか否かを含む(ブール)。
○偽であれば、SSOサービスはssoResponseFedSSOReturnURLをチェックする必要があり、
・ssoResponseFedSSOReturnURLがナルであれば、SSOサービスはIDCS要求クッキーを削除し、MyConsoleにリダイレクトし、
・そうでなければ、SSOサービスは、IDCS要求クッキーを削除し、ssoResponseFedSSOReturnURLにリダイレクトする。
○真であれば、SSOサービスはcallbackURLにリダイレクトする。なぜなら、連携SSOフローはIDCS SSOサービスによって開始されたからである。
一実施形態において、SLOを実行するためのSSO機能/ステップは次の通りである。
1.ユーザのセッションをセッションクッキー、すなわちAuthNContextから削除する。
2.コンポーネントデータ内のOAuthエントリについて、もしあれば、OAuthログアウトエンドポイントにリダイレクトする。
3.OAuth/OIDCは、RPのログアウトURLをクライアントidからフェッチし、OAuthエントリをコンポーネントデータからクリアし、異なるRPログアウトURLを有するHTMLソースを生成し(非同期プロセス)、最後にSSOログアウトに戻る(最後のimg srcはSSOログアウト)。
4.SSOは、コンポーネントデータ内のSAMLエントリをチェックし、もしあれば、IDCS_REQクッキー内の「SAMLフラグを呼び出さない」をチェックし、真に設定されているまたは存在しなければ、リダイレクトによってSAML/ログアウトに委任し、SAMLはそのSPログアウトフローを完了し、SAMLエントリをコンポーネントデータからクリアし、SSO/ログアウトに戻る。
5.SAMLサービスは、SAML2.0ログアウトプロトコル動作を開始し、ユーザを、ログアウトのためにさまざまな遠隔連携パートナーにリダイレクトする。
6.実行されると、SAMLサービスはSAMLデータをIDCSセッションクッキーから削除する。
7.SAMLサービスはユーザをSSOサービス(SSOサービスからのURL TBD)にリダイレクトする。
8.SSOログアウトは「リターンURL」を取得し、セッションクッキーをクリアし(SAMLコンポーネントデータはもしあれば削除してはならない)、最後に「リターンURL」にリダイレクトする。「リターンURL」が存在しなければ、テナント固有のログアウトランディングページにリダイレクトする。
一実施形態において、マイクロサービスは、プロトコルに基づいて認証機能を提供するように構成される。一実施形態において、このプロトコルはOAuthまたはSAMLであり、シングルサインオンマイクロサービスは、OAuthおよびSAML双方にまたがるシングルサインオン機能を提供するように構成される。一実施形態において、シングルサインオンマイクロサービスは、セッションクッキーとして構成されたグローバルセッションを生成し、このグローバルセッションをマイクロサービスに与える。一実施形態において、マイクロサービスはグローバルセッションをトークンに変換する。一実施形態において、シングルサインオンマイクロサービスは、第2の要求の要求パラメータを正規化する。
一実施形態において、本アプリケーションは、上記テナンシーを含む複数のテナンシーによって使用されるように構成されている。一実施形態において、マイクロサービスは、ステートレスであり、データをデータベースから取り出してアイデンティティ管理サービスを実行する。一実施形態において、データベースおよびマイクロサービスは、互いに独立してスケーリングするように構成されている。一実施形態において、データベースは分散型データグリッドを含む。
開示されている通り、実施形態は、グローバルセッションを実現しこのグローバルセッションを適切なプロトコルトークンに変換することにより、さまざまなプロトコルにまたがるSSO機能を提供する、マルチテナントクラウドスケールIAMを提供する。さらに、実施形態は、クッキーを使用し、リダイレクトすることにより、すべてのアプリケーションについてSLO機能を果たす。
本明細書ではいくつかの実施形態が具体的に例示および/または記載されている。しかしながら、開示されている実施形態の修正および変形は、本発明の精神および意図する範囲から逸脱することなく、上記教示によってカバーされ以下の請求項の範囲に含まれることが、理解されるであろう。