第1章 認可サービスの概要
Red Hat build of Keycloak は詳細な認可ポリシーをサポートしており、次のようなさまざまなアクセス制御メカニズムを組み合わせることができます。
- 属性ベースのアクセス制御 (ABAC)
- ロールベースアクセス制御 (RBAC)
- ユーザーベースのアクセス制御 (UBAC)
- コンテキストベースのアクセス制御 (CBAC)
ルールベースのアクセス制御
- JavaScript の使用
- 時間ベースのアクセス制御
- SPI (Service Provider Interface) によるカスタムアクセス制御メカニズム (ACM) のサポート
Red Hat build of Keycloak は管理 UI と RESTful API のセットをベースとしており、必要な手段として保護されているリソースやスコープのパーミッションを作成し、それらのパーミッションを認可ポリシーに関連付け、アプリケーションやサービスで認可に関する決定を強制します。
リソースサーバー (アプリケーションまたはサービス提供で保護されているリソース) は、通常、保護されたリソースにアクセスを付与すべきかどうかを決定するために、一定種類の情報に依存します。RESTful ベースのリソースサーバーの場合、その情報は通常はセキュリティートークンから取得され、通常はすべてのリクエストに対してベアラートークンとして送信されます。セッションに依存してユーザーを認証する web アプリケーションでは、その情報は通常、ユーザーのセッションに保存され、各リクエストに対してそこから取得されます。
多くの場合、リソースサーバーは、ロールベースのアクセス制御 (RBAC) に基づいて認可の決定のみを行います。ここでは、保護されたリソースにアクセスしようとするユーザーに付与されたロールが、これらの同じリソースにマップされたロールと照合されます。ロールには非常に便利ですが、アプリケーションにはいくつかの制限があります。
- リソースとロールが密接に結合され、ロール (アクセスコンテキストの追加、削除、または変更など) が複数のリソースに影響する可能性があります。
- セキュリティー要件を変更すると、アプリケーションコードへの深い変更を確認して、
- アプリケーションのサイズによっては、ロール管理が困難になり、
- 最も柔軟なアクセス制御メカニズムではありません。ロールは、コンテキスト情報がなく、コンテキスト情報がないユーザーを表すことはありません。ロールを付与している場合は、少なくともいくつかのアクセスがあります。
今日、ユーザーが異なる地域に分散し、異なるローカルポリシーを持ち、異なるデバイスを使用し、情報共有の要求が高い異種環境を考慮する必要があることを考えると、Red Hat build of Keycloak の認可サービスは、以下を提供することで、アプリケーションやサービスの認可機能を向上させることができます。
- 詳細な認可ポリシーと異なるアクセス制御メカニズムを使用したリソース保護
- 一元化されたリソース、パーミッション、およびポリシー管理
- 集中ポリシー定義点
- REST ベースの認可サービスのセットに基づく REST セキュリティー
- 認可ワークフローおよびユーザー管理のアクセス
- プロジェクト全体でのコードの複製を回避するためのインフラストラクチャー (および再デプロイ) は、セキュリティー要件の変更に迅速に対応します。
1.1. アーキテクチャー
設計の観点からは、認可サービスはこれらの機能を提供する明確に定義された認可パターンのセットに基づいています。
ポリシー管理ポイント (PAP)
リソースサーバー、リソース、スコープ、パーミッション、ポリシーを管理するために、Red Hat build of Keycloak の管理コンソールをベースにした一連の UI を提供します。この一部は、保護 API を使用してリモートで実行できます。
ポリシー決定ポイント (PDP)
分散可能なポリシーの意思決定ポイントを、認可要求が送信され、ポリシーを要求するパーミッションに応じて評価されます。詳細は、パーミッションの取得 を参照してください。
ポリシー実施ポイント (PEP)
リソースサーバー側で認可決定を強制するさまざまな環境の実装を提供します。Red Hat build of Keycloak は、いくつかのビルトイン ポリシーエンフォーサー を提供します。
ポリシー情報ポイント (PIP)
Red Hat build of Keycloak の Authentication Server をベースとしており、認可ポリシーの評価時にアイデンティティーおよびランタイム環境から属性を取得できます。
1.1.1. 認可プロセス
Red Hat build of Keycloak を使用してアプリケーションに対するきめ細かな認可を有効にする方法を理解するために必要な手順を、3 つの主なプロセスで定義します。
- リソースの管理
- パーミッションおよびポリシーの管理
- ポリシーの強制
1.1.1.1. リソース管理
リソースの管理 には、保護されているものを定義するために必要なすべての手順が含まれます。
まず、保護する Red Hat build of Keycloak を指定する必要があります。これは通常、Web アプリケーションまたは 1 つ以上のサービスのセットを表します。リソースサーバーの詳細は、用語 を参照してください。
リソースサーバーは、Red Hat build of Keycloak の管理コンソールを使用して管理されます。登録済みのクライアントアプリケーションをリソースサーバーとして有効にし、保護するリソースおよびスコープの管理を開始することができます。
リソースは、Web ページ、RESTFul リソース、ファイルシステム内のファイル、EJB などになります。これらは、リソースのグループを表すことも (Java の Class のように)、単一の特定のリソースを表すこともできます。
たとえば、すべての銀行口座を表す Bank Account リソースがあり、それを使用してすべての銀行口座に共通の認可ポリシーを定義する場合があります。ただし、所有者だけが一部の情報へのアクセスや操作の実行を許可されている Alice Account (顧客に属するリソースインスタンス) に特定のポリシーを定義したい場合があります。
リソースは、Red Hat build of Keycloak の管理コンソールまたは Protection API を使用して管理できます。後者の場合、リソースサーバーはリソースをリモートで管理できます。
スコープは、通常リソースで実行できるアクションを表しますが、これらに限定されません。スコープを使用してリソース内の 1 つまたは複数の属性を表すこともできます。
1.1.1.2. パーミッションおよびポリシーの管理
リソースサーバーと保護するすべてのリソースを定義した後に、パーミッションとポリシーを設定する必要があります。
このプロセスでは、リソースを管理するセキュリティーおよびアクセス要件を実際に定義するのに必要なすべてのステップが関係します。
ポリシーは、何か (リソースやスコープ) にアクセスしたり操作を実行したりする際に満たさなければならない条件を定義するものですが、何を保護しているかには縛られていません。これらは汎用的であり、パーミッションの構築やより複雑なポリシーの構築に使用できます。
例えば、"User Premium "というロールを付与されたユーザーにのみ、あるリソース群へのアクセスを許可するには、RBAC(Role-based Access Control) を使用します。
Red Hat build of Keycloak は、最も一般的なアクセス制御メカニズムをカバーするいくつかのビルトインポリシータイプ (およびそれぞれのポリシープロバイダー) を提供します。JavaScript を使用して記述されたルールに基づいてポリシーを作成することもできます。
ポリシーを定義したら、パーミッションの定義を開始できます。パーミッションは、保護しているリソースと結合されます。ここでは、許可を許可または拒否するために満たさなければならないポリシー (リソースまたはスコープ) およびポリシーを指定します。
1.1.1.3. ポリシーの強制
ポリシーの強制 には、リソースサーバーに認可の決定を実際に強制するために必要な手順が含まれます。これは、認可サーバーと通信できるリソースサーバーで ポリシー強制ポイント または PEP を有効にし、サーバーが返した決定とパーミッションに基づいて認可データと、保護リソースへのアクセスを制御することによって使用できます。
Red Hat build of Keycloak は、実行中のプラットフォームに応じてアプリケーションを保護するために使用できるビルトイン ポリシーエンフォーサー 実装を提供します。
1.1.2. 認可サービス
認可サービスは、以下の RESTFul エンドポイントで構成されます。
- トークンエンドポイント
- リソース管理エンドポイント
- パーミッション管理エンドポイント
これらのサービスごとに、認可プロセスに関係するさまざまなステップをカバーする特定の API を提供します。
1.1.2.1. トークンエンドポイント
OAuth2 クライアント (フロントエンドアプリケーションなど) は、トークンエンドポイントを使用してサーバーからアクセストークンを取得し、その同じトークンを使用してリソースサーバー (バックエンドサービスなど) で保護されたリソースにアクセスすることができます。同様に、Red Hat build of Keycloak の Authorization Services は OAuth2 の拡張機能を提供し、要求されたリソースまたはスコープに関連するすべてのポリシーの処理に基づいてアクセストークンを発行できます。つまり、リソースサーバーは、サーバーによって付与されるパーミッションに基づいて保護されているリソースへのアクセスを強制でき、アクセストークンによって保持されます。Red Hat build of Keycloak の Authorization Services では、パーミッションのあるアクセストークンは Requesting Party Token (RPT) と呼ばれます。
関連情報
1.1.2.2. 保護 API
保護 API は、リソースサーバーの一連の UMA 準拠 のエンドポイントで、それらに関連付けられたリソース、スコープ、パーミッション、およびポリシーの管理に役立ちます。この API へのアクセスはリソースサーバーのみです。また、uma_protection スコープも必要です。
保護 API が提供する操作は、以下の 2 つのグループに分類できます。
リソースの管理
- リソースの作成
- リソースの削除
- Id で検索
- クエリー
パーミッションの管理
- パーミッションチケットの発行
デフォルトでは、Remote Resource Management は有効になります。Red Hat build of Keycloak の管理コンソールを使用してこれを変更し、コンソール経由のリソース管理のみを許可できます。
UMA プロトコルを使用する場合、保護 API による Permission Tickets の発行は、認可プロセス全体における重要な部分です。後続のセクションで説明されているように、クライアントは要求するパーミッションを表し、サーバーへ送信され、要求されるリソースおよびスコープに関連付けられたパーミッションおよびポリシーの評価時に付与されるすべてのパーミッションで最終的なトークンを取得します。
関連情報
