11.3. 権限を使用したレルム管理の委任

レルムでは、ユーザー、グループ、クライアント、クライアントスコープ、ロールなど、さまざまな種類のリソースを管理できます。レルム管理者は、常にこのようなリソースを管理して、アイデンティティーおよびそれらの認証方法とレルムおよびアプリケーションへのアクセスの承認方法も管理します。

この機能は、レルムリソースを管理するときにアクセス制御を適用するために必要なメカニズムを提供します。対象は、以下のみとなっています。

特定のリソースタイプのすべてのリソース (レルム内のすべてのユーザーなど) の権限、または特定のレルムリソース (レルム内の特定のユーザーまたはユーザーセットなど) の権限を管理できます。

各レルムリソースは、view や manage のような管理操作やスコープ、さらにグループの場合で言えば view-members のようなリソース固有の操作など、明確に定義された管理操作またはスコープのセットをサポートしています。

権限を管理するときは、リソースタイプから 1 つ以上のスコープのセットを選択して、レルム管理者がリソースタイプに対して特定の操作を実行できるようにします。たとえば、view スコープを付与すると、レルム管理者にレルムリソースのリスト表示、検索、表示のアクセス権が付与されます。一方、manage スコープでは、管理者は更新や削除を実行できます。

スコープは互いに完全に独立しています。レルムリソースの manage アクセス権を付与しても、view スコープが自動的に付与されるわけではありません。スコープ間に推移的な依存関係は存在しません。個々のスコープを選択する必要があるため、権限を管理するときに全体的なユーザーエクスペリエンスに影響する可能性がありますが、特定のスコープへのアクセス制限を適用する権限をより簡単に識別できるという利点があります。

あるリソースタイプの特定のスコープには、別のリソースタイプのスコープとの (推移的な依存関係ではない) 関係があります。この関係は主に、レルムグループとそのメンバーなど、レルムリソースのグループを表すリソースタイプを管理する場合に当てはまります。

レルムで fine-grained admin permissions を有効にするには、次の手順に従います。

有効にすると、管理コンソールの左側のメニューに Permissions セクションが表示されます。

このセクションから、レルムリソースの権限を管理できます。

Permissions タブには、レルム内のすべてのアクティブな権限の概要が表示されます。ここから、管理者は権限を作成、更新、削除、または検索できます。作成した権限を事前に評価して、期待どおりにレルムリソースへのアクセスが適用されているかどうかを確認することもできます。詳細は、権限の評価 を参照してください。

権限を作成するには、Create permission ボタンをクリックし、保護するリソースの種類を選択します。

リソースタイプを選択したら、選択したタイプの 1 つ以上のリソースのセットに対してアクセスをどのように適用するかを定義できます。

権限を管理する場合、次の設定を定義できます。

権限を作成すると、選択した (すべての) リソースとスコープへのアクセス制限を適用するときに、権限が自動的に有効になります。実稼働環境で権限を作成および更新するときは、この点に留意してください。

Policies タブでは、管理者はさまざまなアクセス制御方法を使用して条件を定義し、レルムリソースに対して操作を実行しようとする管理者に権限を付与するかどうかを決定できます。権限を管理するときは、レルムリソースへのアクセスを許可または拒否するために、少なくとも 1 つのポリシーを関連付ける必要があります。

ポリシーは基本的に、GRANT または DENY のいずれかに評価される条件です。その結果によって、付与するか拒否するかが決まります。

権限は、関連付けられているすべてのポリシーが GRANT と評価された場合にのみ付与されます。そうでない場合、権限は拒否され、レルム管理者は保護されたリソースにアクセスできなくなります。

Red Hat build of Keycloak には、選択可能な一連の組み込みポリシーが用意されています。

レルムに対して明確かつ安定した権限モデルが確立されると、ポリシーを作成する必要性は少なくなります。代わりに、既存のポリシーを再利用して、さらに多くの権限を作成することもできます。

各ポリシータイプの詳細は、ポリシーの管理 を参照してください。

Evaluation タブには、権限が期待どおりにアクセス制限を適用していることを管理者が検証できるようにテスト環境が提供されます。管理者は、特定のリソースへのアクセス制限を適用するときにどのような権限が関係しているか、またその結果はどうなるかを確認できます。

評価を実行するには、一連のフィールドを指定する必要があります。

Evaluate ボタンをクリックすると、選択した User が管理コンソールまたは管理 API を使用してリソースにアクセスしようとした場合と同様に、選択したリソースとスコープに関連付けられているすべての権限がサーバーによって評価されます。

たとえば、上記の例では、Allow managing all realm users 権限が PERMIT に投票され、manage スコープへのアクセスが許可されているため、ユーザー myadmin がユーザー user-1 を 管理 できることがわかります。しかし、他のスコープはすべて拒否されています。

Permissions タブの検索機能と組み合わせることで、トラブルシューティングを実行し、期待どおりに動作していない権限を特定できます。

権限を評価する際には、次のルールが適用されます。

レルム管理者は、割り当てられたレルム内のリソースを管理できる専用のレルム固有の管理コンソールにアクセスできます。このコンソールは、通常サーバー管理者が使用する Red Hat build of Keycloak とは別です。

専用レルム管理コンソールと利用可能なロールの詳細は、専用管理コンソール を参照してください。

管理コンソールにアクセスするには、管理する必要があるリソースに応じて、レルム管理者に少なくとも次のロールの 1 つが割り当てられている必要があります。

これらのロールのいずれかをレルムユーザーに付与すると、そのユーザーは管理コンソールにアクセスできるようになりますが、アクセスできるのは付与されたロールに対応する領域のみです。たとえば、query-users ロールを割り当てると、レルム管理者は管理コンソールの Users セクションにのみアクセスできるようになります。管理者が複数のリソースタイプ (ユーザーとグループの両方など) を担当している場合は、対応するすべての "query-*" ロールを割り当てる必要があります。

これらのロールは、クエリーリソースへの基本的なアクセスを許可しますが、それらを表示または変更する権限は付与しません。レルムリソースへのアクセスを許可または拒否するには、各リソースタイプで使用可能な操作の権限を設定する必要があります。詳細は、権限の管理 を参照してください。

管理者が、管理者グループに属するユーザーを除くレルム内のすべてのユーザーを管理者グループにより管理できるようにする場合があります。この例には、test レルムと test-admins グループが含まれています。

レルムに対してこの機能を有効にすると、レルム管理者がサポートされているリソースタイプのいずれかを管理するときに追加のオーバーヘッドが発生します。これは主に次の操作を実行する場合に当てはまります。

この機能では、定義した権限をもとにアクセス制御を適用するためにレルムリソースを表示または管理する場合に必ず、追加のチェックが行われます。主にレルムリソースをクエリーする場合にこの追加のチェックが行われます。理由として、レルム管理者の権限を部分的に評価して結果をフィルタリングおよびページネーションするため、余計なオーバーヘッドが発生するためです。

レルム管理者ユーザーを参照する権限を減らし、アクセスできるリソースの大半を制限するほうが適切です。たとえば、ユーザーを管理するためにレルム管理者にアクセス権を委任する場合は、それらのユーザーをグループのメンバーにすることが適切です。そうすることで、権限を評価する際のパフォーマンスが向上するだけでなく、管理のしやすい権限モデルを形成できます。

レルムリソースを照会するときに、アクセス制限の影響を主に受けます。たとえば、レルム管理者が、ユーザー、ロールまたはグループポリシーなどにおいて何千もの権限で参照されている場合に、レルムリソースのクエリーをするときに、部分的評価のメカニズムが使用されると、データベースからそのような権限がすべてクエリーされてしまいます。より簡潔で最適化されたモデルを使用すると、取得する権限を少なくしながらも、領域リソースへのアクセスを許可または拒否するのに十分な権限を取得できます。

たとえば、レルム内のユーザーの表示および管理の権限をレルム管理者に付与する場合は、レルム内の個々のユーザーごとに個別の権限を作成するよりも、グループ権限を使用する方が適切です。また、ポリシーに、直接参照 (ユーザーポリシー) または間接 (ロールまたはグループポリシー) 参照のいずれかでレルム管理者を参照する権限が含まれている場合に、リソースタイプに関係なく、複数 (何千) の権限にまたがらないようにしてください。

たとえば、レルム内にユーザーが 3 つあり、レルム管理者の bob にそれらのユーザーの view および manage 権限を付与するとします。権限モデルが最適でない場合、ユーザーポリシーで bob へのアクセスを許可し、ユーザーごとに 3 つの異なる権限を作成します。そうではなく、同じユーザーポリシーを使用して bob にアクセスを許可しながら、これら 3 つのユーザーをまとめて単一のグループ権限、または単一のユーザー権限を指定できます。

これら 3 つのユーザーにさらに多くのレルム管理者のアクセス権を付与する場合も同様です。個別のポリシーを作成する代わりに、グループポリシーまたはロールポリシーの使用を検討することもできます。権限モデルはユースケースに固有ですが、これらの推奨事項は、管理性を向上させるだけでなく、レルムリソースの管理にあたり、サーバーの全体的なパフォーマンスを向上させるためにも重要です。

サーバー設定に関しては、レルムのサイズと、所有する権限およびポリシーの数に応じて、キャッシュ設定を変更して次のキャッシュのサイズを増やすことを検討してください。

デプロイメントのサイズを決定する場合、最適な値を見つけられるように、これらのキャッシュのサーバーメトリクスを確認することを検討してください。

リソースをフィルタリングする場合、部分評価メカニズムは最終的に SQL ステートメントの IN 句をもとに結果をフィルタリングします。データベースによっては、IN 句のパラメーターの数に制限がある場合があります。これは、1000 個までというパラメーターの厳しい制限がある、過去バージョンの Oracle データベースなどの場合に当てはまります。このような問題を回避するには、単一のレルム管理者にアクセスを許可または拒否する権限の数に関する、上記の考慮事項に留意してください。