(57)【要約】【課題】マイクロサービス・アーキテクチャにおけるアクセス制御を提供する。【解決手段】例えば、エンド・ユーザ、ボット、開発者、または他のアプリとすることができるシステム・アクタによる使用に応じることができるクライアントのためにマイクロサービス・ベース・アプリケーション、すなわち、アプリを管理するように動作可能なアプリケーション・サーバに関連する方法、システム、およびコンピュータ・プログラム製品。許可バリデータは、クライアントの要求に応じて有効な許可を計算するために使用される。要求は、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、認可または拒否される。有効な許可は、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算される。【選択図】図３
2021500651.tif 000002
【特許請求の範囲】
【請求項１】
クライアントのためのアプリケーションの管理をサポートするためのコンピュータ自動化方法であって、前記クライアントがシステム・アクタによる使用に応じることができ、前記アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含み、前記方法が、
機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、
有効な許可のセットを、前記要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分からプロセッサによって計算することであり、前記アクタ許可が、システム・アクタに割り当てられた許可であり、前記クライアント許可が、前記システム・アクタのクライアントに割り当てられた許可であり、前記リソース許可が、前記システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、
前記有効な許可が、要求されている前記リソースに必要な前記アプリのマイクロサービスのうちのいずれかによって与えられる必要がある前記許可の少なくともサブセットであることを条件として、前記要求を前記プロセッサによって認可または拒否することと
を含む、方法。
【請求項２】
前記アクタ許可のセットと前記クライアント許可のセットとの共通部分を記憶するクライアント・アクセス可能許可資格情報を生成することであり、前記有効な許可のセットを計算するために、前記許可資格情報が、アクタ許可とクライアント許可との前記共通部分を抽出するために読み出され、次いで、前記有効な許可に達するために前記リソース許可と交差される、生成することをさらに含む、請求項１に記載の方法。
【請求項３】
少なくとも１つのアクタ・タイプが、許可資格情報を管理する権利を有する、請求項２に記載の方法。
【請求項４】
前記権利が、許可資格情報の生成を要求する権利、許可資格情報を取り消す権利、および現在存在する許可資格情報を示す権利のうちの少なくとも１つを含む、請求項３に記載の方法。
【請求項５】
前記許可資格情報がトークンである、請求項２に記載の方法。
【請求項６】
前記トークンがＪＳＯＮウェブ・トークンである、請求項５に記載の方法。
【請求項７】
許可バリデータが前記有効な許可のセットを計算し、前記許可バリデータが、それ自体、前記複数のマイクロサービスによって呼び出されるのに有効なマイクロサービスとして配達される、請求項２に記載の方法。
【請求項８】
クライアントのためのアプリケーションの管理をサポートするためのコンピュータ・プログラム製品であって、前記クライアントがシステム・アクタによる使用に応じることができ、前記アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含み、前記コンピュータ・プログラム製品が、プログラム・コードの具現化されたコンピュータ可読記憶媒体を含み、前記プログラム・コードが、
機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、
有効な許可のセットを、前記要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算することであり、前記アクタ許可が、システム・アクタに割り当てられた許可であり、前記クライアント許可が、前記システム・アクタのクライアントに割り当てられた許可であり、前記リソース許可が、前記システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、
前記有効な許可が、要求されている前記リソースに必要な前記アプリのマイクロサービスのうちのいずれかによって与えられる必要がある前記許可の少なくともサブセットであることを条件として、前記要求を認可または拒否することと
を行うためのプログラミング命令を含む、コンピュータ・プログラム製品。
【請求項９】
前記プログラム・コードが、
前記アクタ許可のセットと前記クライアント許可のセットとの共通部分を記憶するクライアント・アクセス可能許可資格情報を生成することであり、前記有効な許可のセットを計算するために、前記許可資格情報が、アクタ許可とクライアント許可との前記共通部分を抽出するために読み出され、次いで、前記有効な許可に達するために前記リソース許可と交差される、生成すること
を行う前記プログラミング命令をさらに含む、請求項８に記載のコンピュータ・プログラム製品。
【請求項１０】
少なくとも１つのアクタ・タイプが、許可資格情報を管理する権利を有する、請求項９に記載のコンピュータ・プログラム製品。
【請求項１１】
前記権利が、許可資格情報の生成を要求する権利、許可資格情報を取り消す権利、および現在存在する許可資格情報を示す権利のうちの少なくとも１つを含む、請求項１０に記載のコンピュータ・プログラム製品。
【請求項１２】
前記許可資格情報がトークンである、請求項９に記載のコンピュータ・プログラム製品。
【請求項１３】
前記トークンがＪＳＯＮウェブ・トークンである、請求項１２に記載のコンピュータ・プログラム製品。
【請求項１４】
許可バリデータが前記有効な許可のセットを計算し、前記許可バリデータが、それ自体、前記複数のマイクロサービスによって呼び出されるのに有効なマイクロサービスとして配達される、請求項９に記載のコンピュータ・プログラム製品。
【請求項１５】
システムであって、
クライアントのためのアプリケーションの管理をサポートするためのコンピュータ・プログラムを記憶するためのメモリ・ユニットであり、前記クライアントがシステム・アクタによる使用に応じることができ、前記アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含む、メモリ・ユニットと、
前記メモリ・ユニットに結合されたプロセッサであり、前記プロセッサが、
機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、
有効な許可のセットを、前記要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算することであり、前記アクタ許可が、システム・アクタに割り当てられた許可であり、前記クライアント許可が、前記システム・アクタのクライアントに割り当てられた許可であり、前記リソース許可が、前記システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、
前記有効な許可が、要求されている前記リソースに必要な前記アプリのマイクロサービスのうちのいずれかによって与えられる必要がある前記許可の少なくともサブセットであることを条件として、前記要求を認可または拒否することと
を含む前記コンピュータ・プログラムのプログラム命令を実行するように構成される、プロセッサと
を含むシステム。
【請求項１６】
前記コンピュータ・プログラムの前記プログラム命令が、
前記アクタ許可のセットと前記クライアント許可のセットとの共通部分を記憶するクライアント・アクセス可能許可資格情報を生成することであり、前記有効な許可のセットを計算するために、前記許可資格情報が、アクタ許可とクライアント許可との前記共通部分を抽出するために読み出され、次いで、前記有効な許可に達するために前記リソース許可と交差される、生成すること
をさらに含む、
請求項１５に記載のシステム。
【請求項１７】
少なくとも１つのアクタ・タイプが、許可資格情報を管理する権利を有する、請求項１６に記載のシステム。
【請求項１８】
前記権利が、許可資格情報の生成を要求する権利、許可資格情報を取り消す権利、および現在存在する許可資格情報を示す権利のうちの少なくとも１つを含む、請求項１７に記載のシステム。
【請求項１９】
前記許可資格情報がトークンである、請求項１６に記載のシステム。
【請求項２０】
前記トークンがＪＳＯＮウェブ・トークンである、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、アクセス制御に関し、より詳細には、マイクロサービス・アーキテクチャにおけるアクセス制御を提供することに関する。
【背景技術】
【０００２】
アクセス制御は情報技術の既知の分野である。過去５０年にわたって、いくつかのアクセス制御モデルが開発されてきた。しかしながら、現代のコンピュータ・プログラム・パラダイムは、それらのモデルの改良および実用的解釈を必要とする。これは、さらに短い時間で新しいアプリケーションを開発および配達する必要があるアジャイル開発技法に関連して特に重要である。複雑なアプリケーションに適切なアクセス制御フレームワークを提供することは軽微なことではなく、既知のモデルは簡単には採用できない。
【０００３】
マイクロサービス・アーキテクチャは、ますます一般的になっている。マイクロサービス・アーキテクチャは、アプリケーションを小さい相互動作するアプリケーションのセットに分解する。これらの小さいアプリケーションがマイクロサービスである。各マイクロサービスは、より高レベルなサービスから切り離して機能の特定の要素に焦点を当てる。マイクロサービスの概念により、開発者は、アプリケーションのシステム・レベル動作を理解する必要なしに小片の機能に焦点を当てることができるので、アプリケーションを更新および変更することが容易になる。アクセス制御の従来の手法は、最上システム・レベルに共通アクセス制御層を設けることである。しかしながら、この手法は、マイクロサービス・アーキテクチャ・モデルに反する。その理由は、共通アクセス制御層が、すべてのマイクロサービスから少なくともいくつかの論理を複製しなければならない構成要素であり、それゆえに、マイクロサービスのうちの１つに変更があるかまたは新しいマイクロサービスが追加されるたびに更新または少なくともレビューされる必要があるからである。これは、マイクロサービスと共通アクセス制御層との間の変更の調整を必要とすることにより開発費を上昇させる。
【０００４】
加えて、現代のエンタープライズ・アプリケーションは、一般に、サーバ側アプリケーション・プログラミング・インタフェース（ＡＰＩ）層をクライアント側層から分離する。（ＡＰＩは、例えば、ＲＥＳＴ−ｆｕｌ  ＡＰＩとすることができ、ここで、ＲＥＳＴはRepresentational State Transferを意味する。）多くの場合、そのようなアプリケーションは、アプリケーションのコアの外部でクライアントと対話し、エンドユーザ・アプリケーションは２つの別個の構成要素として動作する。多くの場合マイクロサービスのセットによって提供されるＡＰＩのみを備えるサーバ側アプリケーションと、ユーザ・インタフェースを備え、ＡＰＩ層と対話するクライアント側アプリケーションとがある。そのようなアプリには、サービス・アプリ、モバイル・アプリ、およびデスクトップ・アプリなどのデフォルト・ウェブＵＩ（ユーザ・インタフェース）が含まれるが、さらに、サービス機能を拡張およびカスタマイズするサード・パーティ・アプリが含まれる。
【０００５】
異なるクライアントは、アプリケーションへの異なるアクセス権が与えられることがある。内部／デフォルト・アプリなどのあるものは事前定義されたアクセス権が与えられることがあり、一方、他のものは組織管理者またはエンド・ユーザによるアクセスに対する明確な承認を必要とすることがある。多数のサービスおよび多数のクライアントをサポートできるだけでなく、アクセス制御機構は、リソース固有のポリシー、ユーザ役割、サービス間アクセスなどのような典型的なエンタープライズ・ユース・ケースをサポートできる必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
マイクロサービス・アーキテクチャにおけるアクセス制御方法、システム、プログラムを提供することである。
【課題を解決するための手段】
【０００７】
１つの態様によれば、クライアントのためのアプリケーションの管理をサポートするためのコンピュータ自動化方法が提供され、クライアントがシステム・アクタによる使用に応じることができ、アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含み、この方法は、機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることを含む。この方法は、有効な許可のセットを、要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分からプロセッサによって計算することであり、アクタ許可が、システム・アクタに割り当てられた許可であり、クライアント許可が、システム・アクタのクライアントに割り当てられた許可であり、リソース許可が、システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することをさらに含む。この方法は、追加として、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、要求をプロセッサによって認可または拒否することを含む。
【０００８】
別の態様によれば、クライアントためのアプリケーションの管理をサポートするためのコンピュータ・プログラム製品が提供され、クライアントがシステム・アクタによる使用に応じることができ、アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含み、コンピュータ・プログラム製品が、プログラム・コードの具現化されたコンピュータ可読記憶媒体を含み、プログラム・コードが、機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、有効な許可のセットを、要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算することであり、アクタ許可が、システム・アクタに割り当てられた許可であり、クライアント許可が、システム・アクタのクライアントに割り当てられた許可であり、リソース許可が、システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、要求を認可または拒否することとを行うためのプログラミング命令を含む。
【０００９】
別の態様によれば、クライアントためのアプリケーションの管理をサポートするためのコンピュータ・プログラムを記憶するためのメモリ・ユニットであり、クライアントがシステム・アクタによる使用に応じることができ、アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含む、メモリ・ユニットと、メモリ・ユニットに結合されたプロセッサであり、プロセッサが、機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、有効な許可のセットを、要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算することであり、アクタ許可が、システム・アクタに割り当てられた許可であり、クライアント許可が、システム・アクタのクライアントに割り当てられた許可であり、リソース許可が、システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、要求を認可または拒否することとを含むコンピュータ・プログラムのプログラム命令を実行するように構成される、プロセッサとを含むシステムが提供される。
【００１０】
先述は、以下の本発明の詳細な説明がよりよく理解されるように本発明の１つまたは複数の実施形態の特徴および技術的利点をやや一般的に略述した。本発明の特許請求の範囲の主題を形成する本発明の追加の特徴および利点が以下で説明される。
【００１１】
本発明の好ましい実施形態が、次に、単なる例示として、以下の図面を参照して説明される。
【図面の簡単な説明】
【００１２】
【図１】本開示の一実施形態によるクラウド・コンピューティング環境を示す図である。
【図２】本開示の一実施形態による抽象化モデル層を示す図である。
【図３】本発明の一実施形態による、ＪＷＴｏｋｅｎに含まれるようなクライアントまたはアイデンティティの動的許可とマイクロサービスに含まれるようなグループなどのリソースの静的許可との間の区分と、許可が検査される方法とを示す図式表示の図である。
【図４】許可と図３による有効な許可との間の例示のマッピングの図式表示の図である。
【図５】開発者が新しいアプリを作成する、ユーザがアプリをアプリケーションに追加する、およびアプリがＡＰＩ呼び出しを行うことに関連するデータ・フローを示す図である。
【図６】アプリがそれ自体のためにＪＷＴｏｋｅｎを得る方法と、さらに、後続の許可評価とを示す図である。
【図７】アプリがユーザのためにＪＷＴｏｋｅｎを得る方法と、さらに、後続の許可評価とを示す図である。
【図８】アプリのために発行されたＪＷＴｏｋｅｎのライフサイクル管理に関連するパーティの役割を示す図である。
【図９】ユーザのために発行されたＪＷＴｏｋｅｎのライフサイクル管理に関連するパーティの役割を示す図である。
【図１０】本発明のいくつかの実施形態によるコンピュータ・システムの一部として使用され得る汎用コンピュータ・デバイスを示す図である。
【発明を実施するための形態】
【００１３】
本開示の目標は、マイクロサービス・ベース・システム環境に適合するアクセス制御モデルを提供することである。全モデルの中で、１つの実施形態は、マイクロサービスの使用を反映する方法で実施されたランタイム時にアクセス制御を行うための方法およびコンピュータ・プログラム製品を提供する。別の実施形態は、許可要件がアプリケーションに自動的に統合される方法で新しいマイクロサービスをアプリケーションに追加するためのツールをソフトウェア開発者に提供する。新しいマイクロサービスは、完全に新しくてもよく、または既存のマイクロサービスの更新バージョンでもよい。
【００１４】
提案するアクセス制御モデルは、システム・アクタ、クライアント、およびリソースに適用することができる別個のアクセス制御ルールを提供すると同時に、マイクロサービス開発者に単一ステップ・チェックを提供し、それによって、開発されるマイクロサービスの範囲外の要因を考慮する必要から開発者を切り離す。
【００１５】
提案するモデルは、さらに、アイデンティティ（例えば、ユーザ）役割と特定のアクセス制御決定との間のマッピングを、許可評価を行うことが役割である特定のマイクロサービス内に含めることを可能にし、一方、許可を評価するマイクロサービスに埋め込まれた決定の背後の論理を理解するかまたはその知識を有する必要なしに、他のサービスが、マイクロサービスであるかより高レベルなサービスであるかにかかわらず、許可を評価するマイクロサービスによってなされたアクセス決定を使用することを可能にする。
【００１６】
本開示の１つの実施形態によれば、クライアントのためのアプリケーションを管理するように動作可能なアプリケーション・サーバであり、クライアントがシステム・アクタによる使用に応じることができ、アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含む、アプリケーション・サーバと、システム・アクタの命令の下で行われるクライアントによる要求に応じて、機能を実行するためにリソースにアクセスするための有効な許可のセットを計算し、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、要求を認可または拒否するように動作可能な許可バリデータとを含むコンピュータ・システムが提供され、有効な許可が、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算され、アクタ許可はシステム・アクタに割り当てられた許可であり、クライアント許可は前記システム・アクタのクライアントに割り当てられた許可であり、リソース許可は、前記システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である。
【００１７】
いくつかの実施形態では、アプリケーション・サーバは、要求に応じて、アクタ許可のセットとクライアント許可のセットとの共通部分を記憶するクライアント・アクセス可能な許可資格情報を生成するように動作可能であり、許可バリデータは、有効な許可を計算するときにアクタ許可とクライアント許可との共通部分を抽出するために許可資格情報を読み出すように動作可能である。１つまたは複数のアクタ・タイプに、許可資格情報を管理する権利を与えることができる。前記権利には、許可資格情報の生成を要求する権利、許可資格情報を取り消す権利、および現在存在する許可資格情報を示す権利のうちの１つまたは複数を含むことができる。
【００１８】
１つの例示の許可資格情報は、トークン、例えばＪＳＯＮウェブ・トークンである。
【００１９】
許可バリデータは、それ自体、複数のマイクロサービスが呼び出すのに利用可能なマイクロサービスとして配達され得る。
【００２０】
いくつかの実施形態では、各リソースは、そのリソースに関するリソース許可のセットを記憶するか、またはそれのために記憶しているように構成される。
【００２１】
コンピュータ・システムは、アプリがアプリケーション・サーバとは別に実施されるサード・パーティ・サーバをさらに含むことができ、許可バリデータ・マイクロサービスは、そのようなサード・パーティ・サーバによってホストされ得る。代替として、許可バリデータ・マイクロサービスは、アプリケーション・サーバによってホストされ得る。
【００２２】
いくつかの実施形態におけるアクタは、エンドユーザ・タイプを含み、その場合、クライアントは、エンドユーザ・タイプ・アクタのためのユーザ・インタフェースを備えることができる。いくつかの実施形態におけるアクタは、開発者−ユーザ・タイプを含み、その場合、クライアントは、開発者−ユーザ・タイプ・アクタのためのユーザ・インタフェースを備えることができる。いくつかの実施形態におけるアクタは、アプリ・タイプを含み、それにより、アプリは、機能を呼び出し、それに応じて許可を認可または拒否することができる。
【００２３】
本開示の１つの態様によれば、クライアントのためのアプリケーションの管理をサポートするためのコンピュータ自動化方法が提供され、クライアントがシステム・アクタによる使用に応じることができ、アプリケーションが１つまたは複数のリソースをクライアントに提供し、各リソースが少なくとも１つのアプリに関連し、各アプリが複数のマイクロサービスを含み、この方法は、機能を実行するためにリソースにアクセスするための、システム・アクタの命令の下で行われるクライアントによる要求を受け取ることと、有効な許可のセットを、要求に応じて、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算することであり、アクタ許可が、システム・アクタに割り当てられた許可であり、クライアント許可が、前記システム・アクタのクライアントに割り当てられた許可であり、リソース許可が、前記システム・アクタに対するリソースの要求可能な機能に割り当てられた許可である、計算することと、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、要求を認可または拒否することとを含む。
【００２４】
本開示の別の態様によれば、コンピュータ可読媒体に記憶され、コンピュータ装置の内部記憶にロード可能であるコンピュータ・プログラムであり、前記プログラムがコンピュータ装置上で実行されるとき、上述で定義された方法を実行するためのソフトウェア・コード部分を含む、コンピュータ・プログラムが提供される。コンピュータ・プログラムは、サービスとして配達可能であるマイクロサービスに含まれ得る。上記のコンピュータ・プログラムを記憶するコンピュータ・プログラム製品も提供することができる。
【００２５】
以下の詳細な説明では、限定ではなく説明のために、特定の詳細が、本開示のより良い理解を提供するために説明される。本開示はこれらの特定の詳細から逸脱する他の実施形態において実施できることが当業者には明らかであろう。
【００２６】
本開示はクラウド・コンピューティングに関する詳細な説明を含むが、本明細書に列挙された教示の実施態様はクラウド・コンピューティング環境に限定されないことが理解されるべきである。むしろ、本発明の実施形態は、現在知られているかまたは後に開発される任意の他のタイプのコンピューティング環境に関連して実施することができる。
【００２７】
クラウド・コンピューティングは、最小限の管理労力またはサービスのプロバイダとの対話により迅速にプロビジョンおよび解放され得る設定可能なコンピューティング・リソースの共有プール（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）への便利でオン・デマンドのネットワーク・アクセスを可能にするためのサービス配達のモデルである。このクラウド・モデルは、少なくとも５つの特性、少なくとも３つのサービス・モデル、および少なくとも４つの配備モデルを含むことができる。
【００２８】
特徴は以下の通りである。
オン・デマンドのセルフ・サービス：クラウド利用者は、サービスのプロバイダとの人的対話を必要とすることなく、必要に応じて自動的に、サーバ時刻およびネットワーク・ストレージなどのコンピューティング機能を一方的にプロビジョンすることができる。
広範囲のネットワーク・アクセス：機能は、ネットワークを介して利用可能であり、異種のシン・クライアントまたはシック・クライアントのプラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による使用を容易にする標準機構によりアクセスされる。
リソース・プーリング：プロバイダのコンピューティング・リソースが、マルチテナント・モデルを使用して多数の利用者に役立つようにプールされ、異なる物理的およびバーチャルリソースが、需要に応じて動的に割り当ておよび再割り当てされる。利用者は、通常、提供されるリソースの正確な場所に関する制御や知識を有していないという点で位置独立の感覚があるが、より高い抽象化レベルでの場所（例えば、国、州、またはデータセンタ）を指定することができる場合がある。
迅速な順応性：機能は、速くスケールアウトするために、場合によっては自動的に、迅速におよび柔軟にプロビジョンされ、速くスケールインするため迅速に解放され得る。利用者には、プロビジョニングのために利用可能な機能は、多くの場合、無制限であるように見え、いつでも任意の量で購入することができる。
従量に基づくサービス：クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、およびアクティブ・ユーザ・アカウント）にとって適切なある抽象レベルで計量機能を活用することによって、リソースの使用を自動的に制御および最適化する。資源の利用は、モニタし、制御し、報告することができ、それにより、利用されるサービスのプロバイダと利用者の両方に透明性が提供される。
【００２９】
サービス・モデルは以下の通りである。
サービスとしてのソフトウェア（ＳａａＳ）：利用者に提供される機能は、クラウド・インフラストラクチャ上で動作するプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インタフェース（例えば、ウェブベースの電子メール）を通して様々なクライアント・デバイスからアクセス可能である。利用者は、限定的なユーザ固有のアプリケーション構成設定のあり得る例外を除き、ネットワーク、サーバ、オペレーティング・システム、ストレージ、またはさらに個別のアプリケーション機能を含む基礎をなすクラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム（ＰａａＳ）：利用者に提供される機能は、プロバイダによってサポートされたプログラミング言語およびツールを使用して作成された利用者作成または取得アプリケーションを、クラウド・インフラストラクチャに配備することである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎をなすクラウド・インフラストラクチャを管理または制御しないが、配備されたアプリケーションおよび場合によってはアプリケーションホスト環境の設定を制御する。
サービスとしてのインフラストラクチャ（ＩａａＳ）：利用者に提供される機能は、処理、ストレージ、ネットワーク、およびその他の基本コンピューティング・リソースをプロビジョンすることであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアを配備および実行することができる。利用者は、基礎をなすクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、配備されたアプリケーションを制御し、場合によっては選択ネットワーキング構成要素（例えばホスト・ファイアウォール）を限定的に制御する。
【００３０】
配備モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは単に組織のために運営される。クラウド・インフラストラクチャは、組織またはサード・パーティが管理することができ、施設内または施設外に存在することができる。
コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織によって共有され、共通の関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、組織またはサード・パーティが管理することができ、施設内または施設外に存在することができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大企業グループにとって利用可能であり、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データおよびアプリケーション可搬性を可能にする標準技術または独自技術（例えば、クラウド間のロード・バランシングのためのクラウド・バースティング）によって結合された、２つ以上のクラウド（例えば、プライベート、コミュニティ、またはパブリック）の複合である。
【００３１】
クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味相互運用性に重点をおいたサービス指向である。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。
【００３２】
次に、図１を参照すると、例示的なクラウド・コンピューティング環境５０が示される。図示のように、クラウド・コンピューティング環境５０は、クラウド利用者によって使用されるローカル・コンピューティング・デバイス、例えば、携帯情報端末（ＰＤＡ）もしく携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはその組合せなどが通信できる１つまたは複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。ノード１０は、本明細書で上述したようなプライベート、コミュニティ、パブリック、もしくはハイブリッド・クラウド、またはその組合せなどの１つまたは複数のネットワークにおいて物理的にまたは仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド利用者がローカル・コンピューティング・デバイスにリソースを維持する必要がないサービスとして、インフラストラクチャ、プラットフォーム、またはソフトウェア、あるいはその組合せを提供することができる。図１に示されたコンピューティング・デバイス５４Ａ〜５４Ｎのタイプは単に例示であることが意図されていることと、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意のタイプのネットワークまたはネットワーク・アドレス可能な接続（例えば、ウェブ・ブラウザを使用して）、あるいはその両方を介して任意のタイプのコンピュータ化デバイスと通信できることとが理解される。
【００３３】
次に、図２を参照すると、クラウド・コンピューティング環境５０（図１）によって提供される機能抽象化層のセットが示される。図２に示された構成要素、層、および機能は、単に例示であるように意図され、本発明の実施形態はそれに限定されないことを予め理解されるべきである。図示のように、以下の層および対応する機能が提供される。
【００３４】
ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェア構成要素を含む。ハードウェア構成要素の例には、メインフレーム６１と、ＲＩＳＣ（縮小命令セット・コンピュータ）アーキテクチャ・ベース・サーバ６２と、サーバ６３と、ブレード・サーバ６４と、ストレージ・デバイス６５と、ネットワークおよびネットワーク構成要素６６とが含まれる。実施形態によっては、ソフトウェア構成要素は、ネットワーク・アプリケーション・サーバ・ソフトウェア６７と、データベース・ソフトウェア６８とを含む。
【００３５】
仮想化層７０は、仮想エンティティの以下の例、すなわち、仮想サーバ７１と、仮想ストレージ７２と、仮想プライベート・ネットワークを含む仮想ネットワーク７３と、バーチャルアプリケーションおよびオペレーティング・システム７４と、仮想クライアント７５とを備えることができる抽象化層を提供する。
【００３６】
１つの例では、管理層８０は、以下で説明する機能を提供することができる。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソースおよび他のリソースの動的調達を行う。計量および価格設定８２は、リソースがクラウド・コンピューティング環境内で利用されたときにコスト追跡を行い、これらのリソースの消費に対する請求書または送り状を送る。１つの例では、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド利用者およびタスクのアイデンティティ検証、ならびにデータおよび他のリソースの保護を行う。ユーザ・ポータル８３は、利用者およびシステム管理者にクラウド・コンピューティング環境へのアクセス権を提供する。サービス・レベル管理８４は、必要なサービス・レベルが満たされるようにクラウド・コンピューティング・リソース割り当ておよび管理を行う。サービス内容合意書（ＳＬＡ）計画および履行８５は、将来の要求がＳＬＡに従って予想されるクラウド・コンピューティング・リソースの事前配置および調達を行う。
【００３７】
ワークロード層９０は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供できるワークロードおよび機能の例には、本発明の実施形態による、マッピングおよびナビゲーション９１と、ソフトウェア・ライフサイクル管理９２と、仮想教室教育配達９３と、データ分析処理９４と、トランザクション処理９５と、ソフトウェア開発サイクル管理９６とが含まれる。
【００３８】
図３は、本発明の一実施形態による、クライアントまたはアイデンティティの動的許可とグループなどのリソースの静的許可との間の区分の図式表示であり、さらに、許可が検査される方法を示す。許可検査プロセスは、サーバ側アプリケーションとクライアント側アプリケーションとの間の分離を用いて、クライアント・サーバ・システム、例えば、エンタープライズ・クラウド・アプリケーションによって例示されるものなどで行われることが想定される。具体的には、ＲＥＳＴｆｕｌ  ＡＰＩなどのクライアント側のサーバ側ＡＰＩ層と、いくつかの相互運用可能マイクロサービスを含むサーバ側層とを有するシステムを考える。サーバ側アプリケーションは、マイクロサービスのセットを通してＡＰＩを提供し、クライアント側アプリケーションは、ユーザとサーバ側ＡＰＩ層との間のバッファとして働くＵＩを提供する。例示のクライアント側アプリは、サービス・アプリ、モバイル・アプリ、およびデスクトップ・アプリなどのデフォルト・ウェブＵＩ（ユーザ・インタフェース）を含むことができるが、さらに、サービス機能を拡張およびカスタマイズするサード・パーティ・アプリを含むことができる。許可は、ＪＳＯＮウェブ・トークン（ＪＷＴｏｋｅｎ）に含まれ、それによって伝えられる。ＪＳＯＮは、ＲＦＣ７５１９、ＲＦＣ７５１５、ＲＦＣ７５１６、およびＲＦＣ７７９７に定義されている公開標準である。これらの標準のうちのＲＦＣ７５１９は、ＪＷＴｏｋｅｎｓの作成に関連する。ＪＷＴｏｋｅｎがサーバのキーによって署名され、それにより、クライアントはその真正性を検証することができる。ＪＷＴｏｋｅｎの目的は、クライアントとサーバとの間の安全な通信を可能にすることである。ＪＷＴｏｋｅｎｓは、クライアントがサーバに対して行う「クレーム」を含む、クライアントのためにサーバによって作成されたアクセス・トークンであり、「クレーム」は、ＲＦＣ７５１９で使用される用語である。本文書の文脈では、ＲＦＣ７５１９で言及されるクレームは許可である。ＪＷＴｏｋｅｎｓは、クライアントにおいてクライアント側ストレージに、例えば、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ  ＬｏｃａｌＳｔｏｒｅに記憶され得る。ＪＷＴｏｋｅｎは、一種のクライアント・アクセス可能資格情報である。
【００３９】
ＪＷＴｏｋｅｎの簡単化された形式は以下の通りである。
｛...  ｈｅａｄｅｒ  ..｝
｛
”ｉｓｓ”：  ”Ｓｏｍｅ  Ｓｅｒｖｉｃｅ”，
”ｉａｔ”：  １４７８５２６９７４，
”ｅｘｐ”：  １５１００６２９７４，
”ａｕｄ”：  ”ｔｅｓｔ”，
”ｓｕｂ”：  ”ｊｏｈｈ．ｓｍｉｔｈ＠ｅｘａｍｐｌｅ．ｃｏｍ”
｝
署名
【００４０】
図３に例として示されるように、ＪＷＴｏｋｅｎは、クライアントおよびアイデンティティに関連する動的許可を含めるために使用される。グループなどのリソースに関する静的許可は、他の場所、例えば、そのリソースに関連するマイクロサービスに記憶される。
【００４１】
解決策を説明するために定義する重要な用語は以下の通りである。
アイデンティティ  −  システム内のアクタ（例えば、エンド・ユーザ、ボット、アプリ、開発者、管理者、内部サービス）。
クライアント  −  例えば、システムのＡＰＩを介してサーバと対話する任意のソフトウェア構成要素。例示のクライアントは以下の通りである。ウェブ・クライアント、モバイル・クライアント、例えばサブスクリプション管理者のためのユーザ・インタフェース（ウェブ・クライアントのサブタイプと考えることができる）、アプリ・レビューア、アプリ開発者、ＡＰＩ呼び出しを開発し、テストし、探査するために開発者によって使用されるＰｏｓｔｍａｎなどの外部ツール。
リソース  −  システム内の任意のリソース（例えば、ファイル、グループ、チャット・ルーム）。
許可  −  機能を実行するための特定のアクセス許可（例えば、ファイルをアップロードする許可）。許可タイプは、ベース許可（base permissions）および集約許可（aggregated permissions）を含む。集約許可は、ベース許可を含めるかまたは排除するように既存の許可の拡張を変更する（コード変更によって）ことができるという点で、静的許可と動的許可との間の中間段階である。これにより、ＪＷＴｏｋｅｎの有効な許可を、ユーザがそれをまだ所有している間に変更することができる。
【００４２】
許可は、アイデンティティ、クライアント、およびリソースに別個に適用される。Ｐが、所与のアイデンティティ（Ｉ）、クライアント（Ｃ）、およびリソース（Ｒ）に許可のセットを提供する関数を定義するとする。ＣがＲにアクセスするために使用するＩに対する有効な許可のセットは、以下のように定義される：
有効な許可＝Ｐ（Ｉ）∩Ｐ（Ｃ，Ｉ）∩Ｐ（Ｒ，Ｉ）
【００４３】
この式によれば、有効な許可は、特定のアイデンティティに対する許可と、そのアイデンティティおよびクライアントに対する許可と、そのアイデンティティおよびアクセスされることになるリソースに対する許可との共通部分から決定される：以下では、上述の式によって定義された意味で「有効な許可」という用語を使用して、それを、他の種類の許可についての話題と区別する。有効な許可は、一般に、記憶されるのではなく、必要なときに計算される。
【００４４】
発明者等の提案する手法では、許可は、動的（すなわち、ランタイム）タイプと静的タイプとに分けられる。アイデンティティ許可およびクライアント許可は動的になり、リソース許可は静的になることになる。動的許可は、ランタイムに固有であり、例えば、ＪＷＴｏｋｅｎなどのトークンとすることができる資格情報を発行することによって、動的に割り当てられる、例えば、特にユーザ・セッションに割り当てられる。リソースに関連する許可は、リソースのプロパティであり、したがって、静的である、すなわち、セッションから独立していることになる。これらの静的許可、例えばグループ許可は、それぞれのリソースに関連するそれぞれのマイクロサービスに記憶され、それぞれのマイクロサービスで管理することができる。静的許可は、関連するリソースに関連するアクセス権を確認する必要がある場合、取り出すかまたは読み出すことができる。
【００４５】
このように、特定のリソースに関連しないアクセス確認は、単にユーザ・セッションに基づいて、例えば、ＪＷＴｏｋｅｎに記憶された許可を確認することによって実行することができる。他方、リソースに関連するアクセス確認は、例えばＪＷＴｏｋｅｎを介したランタイム許可に関する確認と、関連するマイクロサービスから得られたリソース固有の静的許可の確認の両方を含む。
【００４６】
マイクロサービス間で許可を確認するための機能を実装する発明者等の好ましい方法は、１つまたは複数のマイクロサービスを通してこの機能を提供することである。しかしながら、外部エージェントまたはより高いレベルの制御層を通して許可確認機能を提供することもできる。例えば、許可確認は、ＪＷＴｏｋｅｎへのアクセス権と、さらに、リソースおよびグループ許可とを有する「ファイアウォール」層に移動されてもよい。ファイアウォール層は、グループ・サービス・データベースを介してリソース許可へのアクセス権を与えられ、またはグループ許可を得るためにグループ・サービスへのＡＰＩ呼び出しを行う能力を与えられ、あるいはその両方であり得る。その上、＠Ｐｅｒｍｉｓｓｉｏｎｓ  ＪＡＶＡ（Ｒ）アノテーションによって現在宣言されている許可定義が、データベースに移動、コピー、または抽出されて、エンドポイントごとの必要な許可の検索を可能にすることができる。
【００４７】
単一のマイクロサービスは、すべての許可検査機能を提供することができる。しかしながら、最良の態様では、発明者等は、各々が異なる種類の許可のためのものである多数のマイクロサービスを提供することを提案する。許可を提供するこれらのマイクロサービスの名前および役割は変わることがあるが、許可を提供するマイクロサービスのあり得るセットは以下の通りである。
アイデンティティ・サービス：記録のシステムをシステム・アクタに提供し、特定のアイデンティティに対して可能な最大レベルのアクセスを定義する構成要素。最大レベルは、可能であることの技術的制約によって、または許容されるもののポリシー制約によって定義することができる。実際には、アイデンティティ・サービスは、これらの許可を確立するために、例えば、ユーザの資格またはアクティブ・サブスクリプションを確認することによって、追加のマイクロサービスを呼び出すことができる。
認証サービス：セッション中にクライアントなどのユーザに認証トークンを動的に発行し、ユーザ／クライアント・レベル許可の確立に関与する構成要素。認証サービスは、エンドユーザの承認を要求するか、またはユーザ、クライアント、もしくは他の基準の任意の既存の認定を探すことができる。
機能サービス：チャット・ルームなどの特定のリソースの管理に関与し、それ自体の能力でそのリソースに関連する許可に関する情報を提供する構成要素。例えば、チャット・ルームにおけるユーザ役割を認識しているチャット・ルーム・サービスは、設定可能なポリシーに基づいてそのチャット・ルームにおけるユーザ・アクションのための特定の許可にユーザをマッピングする。このように、サービスはそれらの許可を識別するための機構を有しているが、許可の意味を認識する必要はない。
【００４８】
アプリとの開発者およびユーザの対話は、当然、全く異なることになる。開発者は、開発しているアプリの許可のセットを設定すること焦点を当てることになり、その結果、アプリがアプリケーションに配置されて、ユーザがアクセスすると、アプリは所望に応じて機能することになる。ユーザは、他方では、構成に利用可能である許可のセットをレビューすることになり、それを特定のアプリに認可すべきかまたは拒否すべきかを決定する。開発者およびユーザの許可と対話しやすくするために、それぞれのテンプレートを提供する。
ｐｅｒｍｉｓｓｉｏｎＴｅｍｐｌａｔｅ：アプリが特定のグループに追加されるときにそのグループのアプリに割り当てられることになる許可のセットを定義するアプリ・エンティティのためのもの。
ｓｃｏｐｅＴｅｍｐｌａｔｅ：クライアントに割り当てられる許可のセットを定義するクライアントのためのもの。
【００４９】
アプリは、ユーザのためにまたはそれ自体のために働くことができる（例えば、ＡＰＩエンドポイントを呼び出す）。アプリがユーザのために働くとき、アプリは、そのユーザのアイデンティティを分担する。その許可は、ユーザの許可、ＪＷＴｏｋｅｎを得るために要求される許可、およびアプリ・レジストリ中のアプリのエンティティに定義されているｓｃｏｐｅＴｅｍｐｌａｔｅの共通部分である。許可はＯＡｕｔｈフロー中で要求されてもよく、ＯＡｕｔｈは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）内の（ウェブ）サーバへのクライアント・アクセスを可能にする公開標準である。ＯＡｕｔｈは、リソース・オーナーの承認により、アクセス・トークンが認定サーバによってクライアントに発行されるフレームワークを提供する。次いで、クライアントは、アクセス・トークンを使用して、リソース・サーバによってホストされている保護されたリソースにアクセスする。
【００５０】
アプリがそれ自体のために働く場合、アイデンティティはそのアプリのアイデンティティである。
【００５１】
アプリが「ユーザのために」呼び出されると言う場合、これは、呼び出し側を基準にした説明であることに留意されたい。ＡＰＩバックエンドは、ＪＷＴｏｋｅｎを、アプリ・アイデンティティ（それ自体のためのアプリ）のためのものであるかまたはユーザ・アイデンティティ（ユーザのためのアプリ）のためのものであるかのいずれかと理解することになる。両方の場合に、呼び出し元が同じアプリであることは、分からないかまたはほとんどの場合分かる必要がないが、これは、必要に応じてサービスごとの呼び出しにより決定することができる。
【００５２】
次に、例示の実施態様を説明する。コラボレーション・アプリケーションにより、ユーザは、永続的なチャット・ルームを使用して通信することができる。チャット・ルームは、ユーザおよびボットを含むことができる。チャット・ルームごとに、メンバは、メッセージの送信、ファイルおよび画像のアップロードなどを行うことができる。アプリケーションは、マイクロサービスのセットとして実装される。例えば、「グループ・サービス」はチャット・ルーム・メンバシップを管理する、「チャット・サービス」はメッセージを扱う、「ファイル・サービス」はファイルのアップロードおよびダウンロードを管理する、などである。ユーザには、チャット・ルーム・サービス内の異なるレベルのアクセス権を与えることができる。例えば、「人間のユーザ」はチャット・ルームを作成することができ、「ボット」は作成することができない。その上、アプリケーションは、ユーザおよび管理者などの役割を許可し、これらの役割がユーザのアクセス許可を区別する。例えば、「チャット・ルーム・オーナー」は、新しいアプリをチャット・ルームに追加することができるが、通常のユーザは追加することができない。加えて、アプリケーションにより、ユーザは、それ自体のために働くように任意の数のアプリを認定することができ、アプリケーションは、それらのアプリに異なるレベルのアクセス権（ユーザが既に有するアクセス許可内で）を与える。特に、アプリケーションのためのデフォルトＵＩは、デフォルトによって事前承認されているそのようなアプリのうちの選択されたものである。そのアプリケーションはＪＷＴｏｋｅｎを使用して、クライアントがＡＰＩにアクセスするのを可能にする。さらに、チーム概念を含めることができ、それによって、ユーザを、１つまたは複数のチームに属するものとして割り当てることができる。各チームは、システムのリソースを管理するためのアクセスを認める追加のアクセス許可をもつ管理者を有することができる。課題は、各々が特定の機能を扱い、通常、他のものの動作を認識していない多数のマイクロサービスを使用して実装されたアプリケーションでそれらの認証概念をすべて表す方法である。
【００５３】
例えば、以下の理由で、ランタイム時にファイル削除操作が許可されることもあり許可されないこともある。
・  ユーザ・タイプが、ファイルを削除することを許されている、
・  クライアントが、ユーザのためにファイルを削除することを承認されている、
・  ユーザが、特定のチャット・ルームのファイルを削除することを認めているチャット・ルームの役割を有する、
・  チャット・ルームが、ファイル操作の機能（例えば、ファイル操作を許可するライセンスをもつチームのために作成された）を有する、
・  組織管理者が、その組織のチャット・ルームの任意のファイルを削除することができる、
・  内部サービスが、任意のチャット・ルームのファイルを削除することができる（例えば、ファイルがウィルスを含むかまたは不適切なものとして報告される場合）、
・  その他。
【００５４】
それらの決定要因のすべてをファイル・サービスに符号化することは、意図した手法ではない。その理由は、設計目標が、ファイル・サービスが上述でリストされたものなどのすべての関連する断片的な要因に関連する論理を理解する必要がないことであるからである。そのような手法は、ファイル・サービスに不必要な複雑さをもたらすだけでなく、さらに、ポリシー、例えば、ファイルを削除できる役割を変更することまたは管理者のアクセス権のすべてではなく一部を用いて新しい役割を追加することなどを理解し変更することを困難にする。むしろ、提案する手法により、上述で定義された機能サービスの一例であるファイル・サービスが提供される。ファイル・サービスは、コピー、移動、削除、作成、複製（ｆｉｌｅ．ｃｏｐｙ、ｆｉｌｅ．ｍｏｖｅ、ｆｉｌｅ．ｄｅｌｅｔｅ、ｆｉｌｅ．ｃｒｅａｔｅ、ｆｉｌｅ．ｄｕｐｌｉｃａｔｅで表される）などのファイルへのアクションを実行する許可を認可することに関与する。例えば、ファイル削除要求を承認または拒否するのに、ファイル・サービスは、削除操作が要求された特定のチャット・ルームのコンテキスト中の許可「ｆｉｌｅ．ｄｅｌｅｔｅ」しか確認する必要がないことになる。これは、以下の操作がファイル・サービスによって実行されることしか必要としない。
・  「ｆｉｌｅ．ｄｅｌｅｔｅ」がＪＷＴのアイデンティティ許可に含まれているかどうかを確認する。これは、ユーザ役割もしくは資格、ユーザ・タイプ、または内部サービスに基づくことができる。
・  「ｆｉｌｅ．ｄｅｌｅｔｅ」がＪＷＴのクライアント許可に含まれているかどうかを確認する。これは、ファイル操作を実行するためにユーザがクライアントを認定することに基づくことができる。
・  グループ・サービスにアクセスすることによって、「ｆｉｌｅ．ｄｅｌｅｔｅ」が特定のリソース（この場合チャット・ルーム）のリソース許可に含まれているかどうかを確認する。これは、ユーザがチャット・ルームにおいて特定の役割を有することに基づくことができる。
【００５５】
有効な許可のための共通部分の式が、必要な許可が存在すると決定するときにのみ、ファイル削除が実行される。ここで、許可を確認するために必要な論理の個々の要素がそれぞれのマイクロサービスにすべて完備していることにも留意する。
【００５６】
次に、アプリの許可（アイデンティティ、クライアント、リソース）の使用の概要を提供する。ＩＢＭ  Ｗａｔｓｏｎ  Ｗｏｒｋｓｐａｃｅなどのグループ・メッセージング・クライアントのためのアプリケーションにおける多くのアクションは、許可によって保護されることになる。呼び出し元が要求された許可を有する場合のみ、アクションが実行される。そのようなアクションの１つの例は、ＡＰＩ呼び出しである。まず、「アプリ」が様々な概念およびコンテキストを伝えるために形容詞として使用される場合のアプリ関連用語を定義する。
【００５７】
アプリ・アイデンティティ（例えば、アプリ・ユーザ）：アプリ・ユーザのアイデンティティ。これは、Ｐｅｏｐｌｅ  Ｓｅｒｖｉｃｅと呼ばれるサービスに記憶される。これは、新しいアプリがアプリ・レジストリへのＡＰＩ呼び出しを介して作成されるときに作成される。ＪＷＴｏｋｅｎは、例えば、ウェブサーバ・アプリのためのＡｐｐ＿ＩＤ、すなわち、Ｃｌｉｅｎｔ＿ＩＤ、およびオプションとしてクライアント・シークレットのＣｌｉｅｎｔ＿Ｓｅｃｒｅｔを用いて、ＯＡｕｔｈを呼び出すことによってアプリ・アイデンティティに発行される。ＯＡｕｔｈにおいて、Ｃｌｉｅｎｔ＿ＩＤはアプリの公開識別子である。
【００５８】
アプリ・エンティティ：アプリ・レジストリ・データベース内のエンティティである。それは、アプリ・アイデンティティのＩＤおよびそのパスワード（Ｃｌｉｅｎｔ＿Ｓｅｃｒｅｔ）を含む。それは、さらに、アウトバウンド・ウェブフックおよび会話を含み、それらは、他のマイクロサービスに記憶され、アプリｉｄによりアクセスすることができる。
【００５９】
アプリ実装：典型的にはサード・パーティ・サーバ上へのアプリ機能の実装。Ｗｅｂｈｏｏｋ  ＵＲＬ、構成ＵＲＬ、サービス利用規約ＵＲＬはすべて一般にアプリ実装を指し示す。
【００６０】
アプリ概念：アプリ概念は、アプリの個々の要素、主にアプリ・アイデンティティ、アプリ・エンティティ、およびアプリ実装の総称である。アプリは、外部サービスに実装され、データベース内でアプリ・エンティティとして表され、アプリの名前でＡＰＩ呼び出しを行うために使用することができるアイデンティティを有する。いくつかの議論では、アプリという用語は、アプリ概念の同義語として、またはアプリの１つの特定の要素を参照するときに使用されることがある。開発者の観点から、アプリ（概念）の開発は以下のものを含む。その実装を行う（例えば、サーバをレンタルしてそれをホストとして働かせる）こと、アプリ・レジストリ・マイクロサービスのデータベースにアプリ・エンティティを作成するためにアプリケーションにアプリを登録すること、およびアプリ・アイデンティティおよびパスワードを提供することによってアプリ・アイデンティティを設定および管理すること。
【００６１】
これらの例は、許可がアイデンティティに結合されるが、１つのアイデンティティが、異なるコンテキストでは異なる許可を有することができるというより一般的な原理を示している。
【００６２】
アプリ、ユーザ、または開発者がＡＰＩ呼び出しを行うとき、許可の２つのセットが比較される。ＡＰＩを実装するマイクロサービスが呼び出しの要件として定義する許可、および呼び出し元に認可された許可。呼び出し元が必要な許可をすべて有するときのみ、呼び出しが受入れられる。
【００６３】
評価プロセスは、以下の構成要素を含むことができる。
・  ＡＰＩ呼び出しを保護する許可のセット（保護許可）を決定する。
・  保護許可をベース許可のセットに拡張する。
・  呼び出し元に認可される以下の許可のセット（認可された許可）を決定する。認可された許可のセットは以下である。
ｏ  呼び出し元によってのみ定義されるアイデンティティ許可。
ｏ  呼び出しを行うために使用される、呼び出し元によっておよびクライアントによって定義されるクライアント許可。
ｏ  オプションとして、グループのメンバとしてのアイデンティティによって定義されたグループ許可（例えば、スペース）。グループ許可は、グループのコンテキストにおいて行われるＡＰＩ呼び出しに対して評価される。
・  認可された許可セットをベース許可のセットに別々に拡張する。
・  認可されたベース許可のすべてのセットの共通部分を計算する。
【００６４】
このようにして、有効な許可に達することができる。
【００６５】
図４は、たった今説明したプロセスに続く、許可と図３による有効な許可との間の例示のマッピングの図式表示である。ここで、アイデンティティ許可のリストは、クライアント−および−アイデンティティ許可のリストとＡＮＤ演算され、次いで、結果のリストがＪＷＴにロードされ、ＪＷＴは、次いで、グループ−および−アイデンティティ許可のリストとＡＮＤ演算されて、最終結果、すなわち、認可されたベース許可の３つのセットすべての共通部分である有効な認可が提供される。許可評価の最後の部分は、図３に示されるように、有効な許可を必要な許可と比較することである。ここで、必要な許可はアクセスを保護しているものと考えることができる。したがって、リソースへのアクセスは、必要な許可が有効な許可の少なくともサブセットであることを条件として認可される。（疑念を避けるために、図４のリストのテキスト、論理演算リンク、およびＡＮＤ演算は、本開示の書面の説明の一部を形成することに留意されたい。）
【００６６】
図５は、開発者が新しいアプリを作成する、ユーザがアプリをアプリケーションに追加する、およびアプリがＡＰＩ呼び出しを行うことに関連するデータ・フローを示す。開発者が新しいアプリをアプリケーションに追加することに関連するデータ・フローを最初に説明する。開発者は、新しいアプリを作成し、それがアプリケーションに追加された後、アウトバウンド・ウェブフックを受け取ることによって、インバウンド・ウェブフックを送ることによって、またはＡＰＩ呼び出しを行うことによって、アプリがより高いレベルのワークスペースと通信できるようにする必要がある。開発者は、さらに、アプリを設定可能にする必要がある。開発者は、開発者用のＵＩ（当技術分野ではＤＸ  ＵＩと呼ばれる、ここで、ＤＸは開発者体験を表す）にブラウズし、「新しいアプリを作成する」のためにボタンまたは他の機能をクリックし、その許可を構成する。許可の１つのセットは、アプリのためのものであり、アプリがアプリケーションに追加されるときにエンド・ユーザに表示されるべき許可である。許可の第２のセットは、ユーザのためのものであり、ＯＡｕｔｈフローの間エンド・ユーザに表示される。開発者は、許可および範囲のリスト（すなわち、グループおよびクライアント許可）を編集することができる。オプションとして、構成は、許可と他のアプリ機能との間のクロスオーバーを扱うことを含むことができる。例えば、アウトバウンド・ウェブフックが追加される（同じウェブ・ページであるが異なるダイアログ）場合、必要な許可が、自動的に確認されるか、または開発者によって手動で確認され得る。例えば、ＤＸ  ＵＩダイアログは、以下のものを設定および変更するための機能を提供することになる。
・  アプリのためのグループ許可（例えば、ｐｅｒｍｉｓｓｉｏｎＴｅｍｐｌａｔｅに記憶され、アプリがスペースに追加されるときにエンド・ユーザに提示される）、
・  アプリのためのクライアント許可（例えば、明確に記憶されるかまたはエンド・ユーザに提示されることはないが、アプリは、作成されるとすぐにクライアント許可を使用することができ、スペースに追加されない場合でさえ、そのアプリｉｄおよびクライアント・シークレットを所有する）、
・  ユーザのためのグループ許可、または
・  ユーザのためのクライアント許可（ＯＡｕｔｈフローで使用され、次いで、エンド・ユーザに表示される）
あるいはその組合せである。
【００６７】
アプリのためのクライアント許可は、アプリ・レジストリに設定されるとすぐに有効になる。アプリのスペースへの追加またはＯＡｕｔｈフローは必要とされない。既存のアプリの許可は、アプリの作成についてたった今説明した同じ方法で、しかし作成ステップなしに、管理されることになる。
【００６８】
図５の中央部分に示すようにユーザがアプリをアプリケーションに追加することに関連するデータ・フローを次に説明する。エンド・ユーザは、利用可能なアプリがそれ自体のボタンを有するウェブベースＵＩにログオンする。ウェブ・ページを介して、ユーザは、アプリのためのアプリケーションを選択し、さらに、アプリによって必要とされる許可を表示する。アプリを追加するコマンドを発行することによって、ユーザは、アプリへの要求された許可を暗黙で認可する。次いで、ユーザは、アプリが設定可能である範囲でアプリを構成することができる。ユーザのＷｅｂＵＩとの対話は、サーバ・バックエンドへのＧｒａｐｈＱＬ呼び出しをもたらす（ＧｒａｐｈＱＬ−スキーマ）。ＧｒａｐｈＱＬ要求および変更は、内部マイクロサービス、例えば、チャット・サービスへのＲＥＳＴ  ＡＰＩ呼び出しに変換され、チャット・サービスは、他の内部マイクロサービス、ここでは、グループ・サービスおよびアプリ・レジストリを呼び出すことができる。アプリ・レジストリは、ｐｅｒｍｉｓｓｉｏｎＴｅｍｐｌａｔｅを記憶し、それは、スペースに追加されるアプリの許可のセットと比較される。次いで、これらの許可は、グループ・サービスのデータベースに記憶される。
【００６９】
最後に、図５は、さらに、右側に、ＡＰＩによるアプリ呼び出しに適応するためにデータ・フローが変更される方法を示す。他の例と同様に、ＡＰＩは、グループ・サービスから適切な許可の存在の検証を求めることができる。
【００７０】
次に、本開示の範囲内にある様々なユース・ケースを説明する。ユース・ケースで考慮されるパラメータは以下の通りである。
・  許可：アイデンティティ、クライアント、またはグループごとの許可。
・  アプリ・ユーザ：アプリは、ユーザのために働くかまたはそれ自体のために働く。
・  アクタ：開発者またはエンド・ユーザ。
【００７１】
ユース・ケースは、アプリがそれ自体のためにまたはユーザのために働くかどうかと、アイデンティティ、すなわち、アクタが開発者またはエンド・ユーザであるかどうかとを組み合わせた４つの配列に関連する。以下のユース・ケースは、ＵＩを介した対話に関して記載される。ＡＰＩを介したアプリケーションへの直接呼び出しは同様である。
【００７２】
図６は、例えば、ＡＰＩ呼び出しを行うことができるかどうかを確認するために、アプリがそれ自体のためにＪＷＴｏｋｅｎを得る方法と、さらに、後続の許可評価とを示す。ステップ０において、アプリがスペースに追加されると、アプリのグループ許可がグループ・サービスに設定される。これには、ユーザによる認定が含まれる。ステップ１において、例えばサード・パーティ・サーバに実装されるようなアプリが、ＪＷＴｏｋｅｎの要求を発行し、さらに、要求されたクライアント許可を送る。ステップ２において、ＯＡｕｔｈサービスは、アプリ・レジストリにｐｅｒｍｉｓｓｉｏｎＴｅｍｐｌａｔｅを求める。ステップ３において、アプリ・レジストリは、ｐｅｒｍｉｓｓｉｏｎＴｅｍｐｌａｔｅを返し、それをデフォルト・アイデンティティ許可（またはデータベースからの例外）と交差させる。ステップ４において、結果として生じる許可セットは、アイデンティティ許可セットおよびクライアント許可セットとして新しいＪＷＴｏｋｅｎに記憶される。ステップ５において、ＪＷＴｏｋｅｎのアイデンティティおよびクライアント許可は、互いに交差され、オプションとして、さらに、グループ・コンテキストの場合にはアプリのグループ許可セットと交差される。共通部分の結果として、ステップ６において、有効な許可、すなわち、有効なグループ許可セットおよび有効なクライアント許可セットが得られる。有効なグループ許可は、クライアント許可およびアイデンティティ許可（既に述べたような）と、さらにグループ許可との共通部分である。その結果、アイデンティティ許可との共通部分が結果として生じるセットを「有効な」として定義するものであるので、この場合には有効なアイデンティティ許可が存在しない。次いで、結果として生じる有効な許可のセットは、評価において、要求されたアクションに対する必要な許可と比較することができる。
【００７３】
図７は、例えば、ＡＰＩ呼び出しを行うことができるかどうかを確認するために、アプリが、ユーザのためにＪＷＴｏｋｅｎ（ユーザは一種のアイデンティティであることに注意せよ）を得る方法と、さらに、後続の許可評価とを示す。ステップ０において、ユーザがスペースに追加されるとき、そのグループ許可が、共通ライブラリのデフォルト・セットから得られる。ステップ１において、例えばサード・パーティ・サーバに実装することができるアプリが、ユーザのためにＪＷＴｏｋｅｎの要求を行い、さらに、要求された許可を送る。ステップ２において、ＯＡｕｔｈサービスは、アプリ・レジストリにｓｃｏｐｅＴｅｍｐｌａｔｅを求める。ステップ３において、アプリ・レジストリは、ｓｃｏｐｅＴｅｍｐｌａｔｅを返す。ステップ４において、ＯＡｕｔｈサービスは、許可を、要求された許可と交差させた後にユーザに提示する。ステップ５において、ユーザはアクセスを認可する。ステップ６において、ＯＡｕｔｈサービスは、ＪＷＴｏｋｅｎを作成し、その中に、アプリ・レジストリから得られた許可を要求された許可と交差させたものをクライアント許可として、およびグローバル許可の構成から得られたものをアイデンティティ許可として記憶する。ステップ７において、新しいＪＷＴｏｋｅｎに関する情報が、後のトークン取り消しを含めてトークン状態を管理するためにトークン・データベースにＯＡｕｔｈサービスによって記憶される。ステップ８において、ＪＷＴｏｋｅｎのアイデンティティおよびクライアント許可が、互いに交差され、オプションとして、さらに、グループ・コンテキストの場合、ユーザの（アプリでない）グループ許可と交差される。ステップ９において、有効な許可が、共通部分の結果として得られる。次いで、結果として生じる有効な許可のセットは、評価を実行するために、要求されたアクションに対する必要な許可と比較することができる。
【００７４】
図８は、アプリのために発行された、すなわち、図６に示されるようなＪＷＴｏｋｅｎのライフサイクル管理に関連するパーティの役割を示す。ユーザのために発行されるＪＷＴｏｋｅｎｓの管理およびライフサイクルには、３つのパーティ、すなわちアプリ、ユーザ、およびＯＡｕｔｈサービスが含まれる。トークン・ライフサイクルは、アプリ実装で始まり、例えば、サード・パーティ・サーバでホストされ、例えばアプリの構成のためにトークンを要求する。例えばアプリケーション・サーバでホストされるＯＡｕｔｈサービスは、新しいトークン要求を処理する。トークンが返される前に、ＯＡｕｔｈサービスは、要求するアプリに対して要求された許可を与えるための認定のために、例えばウェブＵＩを介して、関連するユーザにメッセージを送る。ＯＡｕｔｈサービスは、これが許可されているというユーザからの確認を受け取ることを条件として、アプリのトークンを作成する。その後いつでも、ユーザはこのトークンを取り消すことができる。より一般的には、トークン管理に関して、ユーザは、いつでも、ユーザのために以前に発行されたＪＷＴｏｋｅｎｓをすべてリストし、それらのうちの一部またはすべてを取り消すことができる。
【００７５】
図９は、ユーザのために発行された、すなわち、図７に示されるようなＪＷＴｏｋｅｎのライフサイクル管理に関連するパーティの役割を示す。アプリのためのＪＷＴｏｋｅｎｓの管理は、各アプリが許可のセットに関連しているので、アプリをアプリケーションに追加するおよびアプリをアプリケーションから除去するアクションに引き続いて生じる。アプリとのユーザ通信は、アプリ・レジストリと、ＧｒａｐｈＱＬなどのクライアント−サーバ・インタフェースとにより仲介されることになる。チャット・サービス、グループ・サービス、およびＯＡｕｔｈサービスなどの他のサービスは、バックグラウンドに含まれる。現在、発明者等のシステムは、アプリに発行されたＪＷＴｏｋｅｎを、直接取り消すことはできないが、ＪＷＴｏｋｅｎに関連するアプリをアプリケーションから除去するアクションによって効果的に取り消すように設計されている。他の設計では、トークンを直接取り消す機能を備えることができる。
【００７６】
図１０は、本発明の実施形態を実施するために使用することができるコンピュータ・システム５０１の構造およびコンピュータ・プログラム５０７を示し、コンピュータ・システムは、クライアント、または上述で言及したアプリケーション・サーバもしくはサード・パーティ・サーバなどのサーバなどのネットワーク・ノードとすることができ、コンピュータ・プログラム５０７は、上述で言及したアプリまたはマイクロサービスとすることができる。コンピュータ・システム５０１は、グラフィック・オブジェクト要求を管理することができる１つまたは複数のハードウェア・データ・ストレージ・デバイス５１１および１つまたは複数のＩ／Ｏデバイス５１３と、グラフィックス・オブジェクトを表示することができるディスプレイ５１５とに１つまたは複数のＩ／Ｏインタフェース５０９を通して結合されたプロセッサ・リソースを提供するためのプロセッサ５０３を含む。プロセッサ５０３は、さらに、１つまたは複数のメモリ・デバイス５０５に接続することができる。メモリ・リソースを提供する少なくとも１つのメモリ・デバイス５０５は、コンピュータ実行可能命令を含むコンピュータ・プログラムである記憶されたコンピュータ・プログラム５０７を含む。データ・ストレージ・デバイス５１１は、コンピュータ・プログラム５０７を記憶することができる。ストレージ・デバイス５１１に記憶されたコンピュータ・プログラム５０７は、メモリ・デバイス５０５を介してプロセッサ５０３によって実行されるように構成される。プロセッサ５０３は、記憶されたコンピュータ・プログラム５０７を実行する。
【００７７】
好ましい実施形態の論理プロセス・ステップのすべてまたは一部は、代替として、本方法の論理プロセス・ステップを実行するように構成された論理要素を含む１つのまたは複数の論理装置で具現することができること、およびそのような論理要素は、ハードウェア構成要素、ファームウェア構成要素、またはそれらの組合せを含むことができることが当業者には明らかであろう。
【００７８】
好ましい実施形態の論理構成要素のすべてまたは一部は、代替として、本方法のステップを実行するための論理要素を含む論理装置で具現することができること、およびそのような論理要素は、例えばプログラマブル論理アレイまたは特定用途向け集積回路の論理ゲートなどの構成要素を含むことができることが当業者には同様に明らかであろう。そのような論理構成は、さらに、固定または伝送可能なキャリア媒体を使用して記憶および伝送することができる、例えば、仮想ハードウェア・ディスクリプタ言語を使用してそのようなアレイまたは回路内の論理構造を一時的にまたは恒久的に確立するためのイネーブリング要素で具現することができる。
【００７９】
さらなる代替実施形態では、本発明は、コンピュータ・インフラストラクチャに配備され、そこで実行されるとき、コンピュータ・システムに方法のステップをすべて実行させるように動作可能なコンピュータ・プログラムを配備するステップを含むサービスを配備するコンピュータ実施方法の形態で実現することができる。
【００８０】
好ましい実施形態の方法および構成要素は、代替として、並列ソフトウェアを実行するための２つ以上のプロセッサを含む並列コンピューティング・システムで完全にまたは部分的に具現できることが理解されよう。
【００８１】
本発明のさらなる実施形態は、システムおよび方法に関して定義されたコンピュータ・プログラム製品である。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有する１つのコンピュータ可読記憶媒体（または複数の媒体）を含むことができる。
【００８２】
コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することができる有形デバイスとすることができる。
【００８３】
本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組合せとすることができる。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有する１つのコンピュータ可読記憶媒体（または複数の媒体）を含むことができる。
【００８４】
コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は、例えば、限定はしないが、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、または前述のものの任意の適切な組合せとすることができる。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストには、以下のもの、すなわち、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）・ディスク、パンチカードまたは命令が記録された溝内の隆起構造などの機械的符号化デバイス、および前述のものの任意の適切な組合せが含まれる。本明細書で使用されるコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波路もしくは他の伝送媒体を通って伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、またはワイヤを通して伝送される電気信号などのそれ自体が一過性信号であると解釈されるべきではない。
【００８５】
本明細書に記載されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、または無線ネットワーク、あるいはその組合せを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードされてもよい。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組合せを含むことができる。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、ネットワークからのコンピュータ可読プログラム命令を受け取り、コンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶するために転送する。
【００８６】
本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＳｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのようなオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組合せで書かれたソース・コードもしくはオブジェクト・コードのいずれかとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上でおよび部分的にリモート・コンピュータ上で、または完全にリモート・コンピュータもしくはサーバ上で実行することができる。後者のシナリオでは、リモート・コンピュータは、任意のタイプのネットワークを通してユーザのコンピュータに接続されてもよく、またはその接続が外部コンピュータに（例えば、インターネット・サービス・プロバイダを使用してインターネットを通して）なされてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、電子回路を個人専用にするためのコンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行することができる。
【００８７】
本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照して本明細書に記載されている。流れ図またはブロック図あるいはその両方の各ブロック、および流れ図またはブロック図あるいはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実現され得ることが理解されるであろう。
【００８８】
これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が流れ図またはブロック図あるいはその両方の１つまたは複数のブロック中に指定された機能／動作を実現するための手段を作り出すように、汎用コンピュータ、専用コンピュータ、または機械を生成するための他のプログラマブル・データ処理装置のプロセッサに提供され得る。これらのコンピュータ可読プログラム命令はまた、命令が記憶されたコンピュータ可読記憶媒体が流れ図またはブロック図あるいはその両方の１つまたは複数のブロック中に指定された機能／動作の態様を実現する命令を含む製品を構成するように、コンピュータ、プログラマブル・データ処理装置、または他のデバイス、あるいはその組合せに対し、特定のやり方で機能するように指示することができるコンピュータ可読記憶媒体に記憶されてもよい。
【００８９】
コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブル装置、または他のデバイス上で実行される命令が流れ図またはブロック図あるいはその両方の１つまたは複数のブロック中に指定された機能／動作を実施するように、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスにロードされて、一連の動作ステップをコンピュータ、他のプログラマブル装置、または他のデバイス上で実行させて、コンピュータ実装プロセスを生じさせてもよい。
【００９０】
要約すると、例えば、エンド・ユーザ、ボット、開発者、または他のアプリとすることができるシステム・アクタによる使用に応じることができるクライアントのためにマイクロサービス・ベース・アプリケーション、すなわち、アプリを管理するように動作可能なアプリケーション・サーバに関連するコンピュータ・システムおよびコンピュータ自動化方法を説明した。許可バリデータは、クライアントの要求に応じて有効な許可を計算するために使用される。要求は、有効な許可が、要求されているリソースに必要なアプリのマイクロサービスのうちのいずれかによって与えられる必要がある許可の少なくともサブセットであることを条件として、認可または拒否される。有効な許可は、アクタ許可のセット、クライアント許可のセット、およびリソース許可のセットの共通部分から計算される。
【００９１】
本開示の範囲から逸脱することなく、多くの改善および変形を前述の例示的な実施形態に行うことができることが当業者には明らかであろう。
【図１】
2021500651.tif 000003
【図２】
2021500651.tif 000004
【図３】
2021500651.tif 000005
【図４】
2021500651.tif 000006
【図５】
2021500651.tif 000007
【図６】
2021500651.tif 000008
【図７】
2021500651.tif 000009
【図８】
2021500651.tif 000010
【図９】
2021500651.tif 000011
【図１０】
2021500651.tif 000012
【国際調査報告】
2021500651.tif 000013
2021500651.tif 000014