Authorization Services Guide

Keycloakを使用してアプリケーションにきめ細かな権限を与える方法を、理解するために必要な手順を定義する3つの主要なプロセスは、以下のとおりです。

認可サービスは以下のRESTFul APIで構成されています。

これらの各サービスは、認可プロセスに関わるさまざまなステップをカバーする特定のAPIを提供します。

エンタイトルメントAPIは、RPTを発行するための1-leggedプロトコルを提供します。認可APIとは異なり、エンタイトルメントAPIはアクセストークンのみを要求します。

このAPIから、ユーザー（特定のリソースサーバーによって管理されるリソースに基づいた）のすべてのエンタイトルメントまたはパーミッション、または1つ以上のリソースのセットに対するエンタイトルメントのみを取得できます。

より詳細な情報はエンタイトルAPIを参照してください。

OAuth2の用語では、リソース・サーバーは保護されたリソースをホスティングし、保護されたリソースへのリクエストを受け入れてレスポンスを返すことができます。

通常、リソース・サーバーは、保護されたリソースへのアクセスを許可するかどうかを決定するために、何らかの情報に依存しています。RESTfulベースのリソース・サーバーの場合、大抵、その情報はセキュリティー・トークンに格納され、一般的に、サーバーへのすべてのリクエストと一緒にベアラー・トークンとして送信されます。セッションを利用してユーザーを認証するWebアプリケーションは、その情報をユーザーのセッションに格納し、リクエストごとにそこから取得します。

Keycloakでは、 confidential クライアント・アプリケーションはリソース・サーバーとして動作できます。このクライアントのリソースとそれぞれのスコープは、一連の認可ポリシーによって保護、管理されます。

リソースは、アプリケーションと組織の資産の一部です。これは、1つ以上のエンドポイントのセット（HTMLページなどの古典的なWebリソースなど）です。認可ポリシーの用語では、リソースは保護される object です。

すべてのリソースには、単一のリソースまたはリソースのセットを表すことができる一意の識別子があります。例えば、すべての銀行口座に対して一連の認可ポリシーを表し定義する Banking Account Resource を管理することができます。ただし、 Alice’s Banking Account と呼ばれる別のリソースを持つこともできます。これは、単一の顧客が所有する単一のリソースを表し、独自の一連の認可ポリシーを持つことができます。

リソースのスコープは、リソース上で実行可能な限定されたアクセスの範囲です。認可ポリシーの用語では、スコープは論理的にリソースに適用できる、潜在的に多くの verbs の1つです。

通常は、特定のリソースで何ができるかを示します。スコープの例としては、表示、編集、削除などです。ただし、リソースによって提供される特定の情報に関連付けることもできます。この場合、プロジェクト・リソースとコスト・スコープを持つことができます。コスト・スコープは、ユーザーがプロジェクトのコストにアクセスするための特定のポリシーとパーミッションを定義するために使用されます。

シンプルでとても一般的なパーミッションを考えてみましょう。

パーミッションは、保護されるオブジェクトと、アクセスが許可されるかどうかを判断するために評価されなければならないポリシーとを関連付けます。

Keycloakは、単純なルールから非常に複雑なルールベースの動的なパーミッションまで、幅広いパーミッション戦略を構築するための豊富なプラットフォームを提供します。柔軟性を提供し、次のことに役立ちます。

ポリシーは、オブジェクトへのアクセスを許可するために必要な条件を定義します。パーミッションとは異なり、保護されるオブジェクトを指定するのではなく、特定のオブジェクト（リソース、スコープ、またはその両方）へのアクセスを満たす条件を指定します。ポリシーは、リソースを保護するために使用できるさまざまなアクセス・コントロール・メカニズム（ACM）に強く関連しています。ポリシーを使用すると、属性ベースのアクセス・コントロール（ABAC）、ロールベースのアクセス・コントロール（RBAC）、コンテキストベースのアクセス・コントロール、またはこれらの任意の組み合わせのための戦略を実装できます。

Keycloakは、"ポリシーのポリシー"を構築して評価の動作を制御できる集約されたポリシーの概念を提供することによって、ポリシーの概念とその定義方法を活用します。特定のリソースへのアクセスを満たすすべての条件を含んだ1つの大きなポリシーを書くのではなく、Keycloak認可サービスのポリシー実装は分割統治のテクニックに従います。つまり、個々のポリシーを作成し、異なる権限でそれらを再利用し、個々のポリシーを組み合わせてより複雑なポリシーを構築することができます。

ポリシー・プロバイダーは、特定のポリシー・タイプの実装です。Keycloakには、対応するポリシー・プロバイダーに基づいた組み込みのポリシーが用意されており、独自のポリシー・タイプを作成して特定の要件をサポートすることができます。

Keycloakには、独自のポリシー・プロバイダー実装をプラグイン化するために使用できるSPI（サービス・プロバイダー・インターフェイス）が用意されています。

パーミッション・チケットは、 OAuth2のUMA（User-Managed Access）プロファイル 仕様で定義された特別なタイプのトークンで、フォームが認可サーバーによって決定される不透明なストラクチャーを提供します。このストラクチャーは、クライアントによって要求されているリソースおよび（または）スコープ、および認可データのリクエスト（リクエスティング・パーティー・トークン[RPT]）に適用する必要のあるポリシーを表します。

UMAでは、個人対個人の共有や個人対組織の共有をサポートするためにパーミッション・チケットが重要です。承認ワークフローにパーミッション・チケットを使用すると、単純なものから複雑なものまでさまざまなシナリオが可能になります。リソース・オーナーとリソース・サーバーは、これらのリソースへのアクセスを管理するきめ細かいポリシーに基づいてリソースを完全に制御できます。

UMAのワークフローでは、パーミッション・チケットは認可サーバーによってリソース・サーバーに発行されます。リソース・サーバーは、保護されたリソースにアクセスしようとするクライアントにパーミッション・チケットを返します。クライアントは、チケットを受信すると、チケットを認可サーバーに送り返すことによって、RPT（認可データを保持する最後のトークン）を要求することができます。

パーミッション・チケットの詳細については、認可APIおよび UMA 仕様を参照してください。

アプリケーションをビルドおよびデプロイする前に、まずアダプターの設定を取得する必要があります。

Keycloak管理コンソールからアダプターの設定を取得するには、以下の手順を実行します。

アプリケーションをビルドしてデプロイするには、次のコマンドを実行します。

アプリケーションが正常にデプロイされた場合は、 http://localhost:8080/app-authz-vanilla でアクセスできます。Keycloakログインページが開きます。

ユーザー alice として、指定したパスワードでログインします。認証後、次のページが表示されます。

クライアント・アプリケーションの認可サービスを有効にしたときに、Keycloakで定義されたデフォルト設定は、このポリシーで保護されているリソースへのアクセスを常に許可する単純なポリシーを提供します。

まず、デフォルトのアクセス許可とポリシーを変更し、アプリケーションの応答方法をテストするか、Keycloakが提供するさまざまなポリシータイプを使用して新しいポリシーを作成します。

このアプリケーションをテストするために今できることはたくさんあります。例えば、クライアントのAuthorizationタブをクリックし、 Policies タブをクリックして、デフォルトポリシーを変更することができます。次に、リスト内の `Default Policy`をクリックします。

さて、デモアプリケーションからログアウトして、もう一度ログインしてください。アプリケーションにアクセスできなくなりました。

これを修正してみましょう。 Default Policy コードを変更する代わりに、ポリシー・コードのテキストエリアの下にあるドロップダウン・リストを使用して、 Logic を Negative に変更します。これにより、デフォルトではすべてのアクセス要求が拒否されますが、そのポリシーの結果が否定されるため、アプリケーションへのアクセスが再度有効になります。再度、この変更をテストする前に、必ずログアウトして再ログインしてください。

追加で次のようなことができます。

リソースサーバー設定ページでは、ポリシーの強制モードの設定や、リモートリソース管理の許可、認可構成の設定のエクスポートができます。

デフォルトの設定を変更するには、デフォルトのリソース、ポリシー、またはパーミッションの定義を削除し、独自の定義を作成します。

デフォルトのリソースは、 /* パターンを使用してアプリケーション内のリソースまたはパスにマップされる URI で作成されます。独自のリソース、権限、ポリシーを作成する前に、デフォルト設定が自分の設定と矛盾しないことを確認してください。

設定ファイルをエクスポートするには、次の手順を実行します。

設定ファイルはJSON形式でエクスポートされ、テキストエリアに表示されます。そこからコピーして貼り付けることができます。 また、 Download をクリックし、設定ファイルをダウンロードして保存することもできます。

リソースサーバーの設定ファイルをインポートするには、 Select file をクリックして、インポートしたい設定ファイルを選択します。

リソースのタイプ・フィールドは、さまざまなリソースをグループ化するために使用できます。そのため、共通のパーミッションのセットを使用して保護することができます。

リソースはオーナーを持ちます。デフォルトでは、リソースはリソース・サーバーによって所有されています。

ただし、リソースはユーザーと関連付けることもできるため、リソース・オーナーに基づいてパーミッションを作成できます。例えば、リソース・オーナーだけが特定のリソースを削除または更新することができます。

リソース管理は、保護APIを介しても公開され、リソース・サーバーがリソースをリモートで管理できます。

保護APIを使用すると、リソース・サーバーを実装して、ユーザーが所有するリソースを管理できます。この場合、リソースを特定のユーザーに属するものとして設定するためのユーザー識別子を指定できます。

ロールベース・ポリシーを定義するとき、特定のロールを Required と指定することができます。こうすることで、 全て の 必須 ロールを付与されたユーザーにのみアクセス権を与えることができます。レルムロールとクライアントロールの両方にこの設定を適用することができます。

ロールを必須と指定するには、そのロールの Required チェックボックスをチェックします。

複数のロールがポリシーに定義されており、そのうちのいくつかが必須の場合にこの機能は有用です。より細かいロールベース・アクセス・コントロール(RBAC)のためにレルムロールとクライアントロールを組み合わせることが可能です。例えば、あるクライアントに適用されるポリシーがある場合、そのクライアントに関連付けられた特定のクライアントロールを必須とすることができます。また、特定のレルムロールを持つ場合のみアクセスを許可することもできます。1つのポリシーに両方のアプローチを適用することもできます。

コンテキストから取得した属性で条件を定義するために、属性ベース・アクセス・コントロール（ABAC）を使用するJavaScriptベースポリシーの簡単な例です。

ロール・ベース・アクセス・コントロール（RBAC）を使用することもできます。以下の例では、ユーザーが keycloak_user レルム ロールを与えられているかどうかを調べています。

または、ユーザが my-client-role クライアント ・ロールを与えられているかどうかを確認できます。my-clientはクライアント・アプリケーションのクライアントIDです。

いくつかのアクセス・コントロール機構の組み合わせを使用することもできます。 以下の例は、同じポリシー内でロール（RBAC）とクレーム/属性（ABAC）のチェックをどのように使用できるかを示しています。この場合は、ユーザーが admin ロールを与えられているか、または、keycloak.org ドメインの電子メールを持っているかどうかを調べています。

認証されたユーザーがリクエストされたリソースのオーナーである場合にのみ、GRANTに評価される条件を定義するために属性ベースのアクセス・コントロール（ABAC）を使用するDroolsベースのポリシーの簡単な例を次に示します。

アイデンティティから属性を取得し、それに応じて条件を定義するために、ABAC（属性ベースのアクセス・コントロール）の別のバリアントを使用することもできます。

org.keycloak.authorization.policy.evaluation.Evaluation インターフェイスからアクセスできるものの詳細については、<< _ policy_evaluation_api, 評価 API >>を参照してください。

アクセスは、すべての条件が満たされている場合にのみ許可されます。Keycloakは、各条件の結果に基づいて AND を実行します。

集約されたポリシーを作成する際には、各ポリシーの結果に基づいて最終的な決定をするために使用される決定戦略を定義することもできます。

デフォルトでは、グループをポリシーに追加したとき、選択されたグループのみにアクセス制限が適用されます。

このアクセス制限を、選択したグループだけでなく、その子グループにも適用したい場合があるかもしれません。その場合、 Extend to Children のチェックボックスをチェックすることで、任意のグループへのアクセス権をその子グループにまで拡大適用することができます。

上の例では、 IT グループとその子グループに属する任意のユーザーに対してアクセス権が付与されます。

評価コンテキストは、評価中にポリシーに有用な情報を提供します。

このインターフェイスから、ポリシーは以下を取得できます。

Identity は、認可リクエストとともに送信されたOAuth2アクセス・トークンに基づいて作成され、このコンストラクトはオリジナルのトークンから抽出されたすべてのクレームにアクセスできます。例えば、 Protocol Mapper を使用してカスタム・クレームをOAuth2アクセス・トークンに含める場合、ポリシーからこのクレームにアクセスして、条件を作成することもできます。

EvaluationContext は、実行およびランタイム環境の両方に関連する属性へのアクセスも提供します。今のところ、いくつかの組み込み属性しかありません。

リソース・パーミッションは、特定のタイプのすべてのリソースに適用されるポリシーを定義するためにも使用できます。この形式のリソース・ベースのパーミッションは、共通のアクセス要件と制約を共有するリソースを持つ場合に役立ちます。

多くの場合、アプリケーション内のリソースは、カプセル化したデータまたは提供する機能に基づいて分類（またはタイプ指定）できます。例えば、金融アプリケーションは、それぞれが特定の顧客に属する異なる銀行口座を管理することができます。それらは異なる銀行口座であるが、銀行組織によって全体的に定義される共通のセキュリティ要件および制約を共有します。タイプされたリソース・パーミッションを使用して、以下のようなすべての銀行口座に適用する共通ポリシーを定義することができます。

タイプ付きリソースのパーミッションを作成するには、新しいリソース・ベースのパーミッションを作成するときに、Apply to Resource Typeをクリックします。 Apply to Resource Type を On に設定すると、保護するタイプと、指定したタイプのすべてのリソースへのアクセスを制御するために適用されるポリシーを指定できます。

保護APIトークン （PAT）は、 uma_protection として定義されたスコープを持つ特殊なOAuth2アクセストークンです。リソースサーバーを作成すると、Keycloakは対応するクライアント・アプリケーションのロール uma_protection を自動的に作成し、クライアントのサービス・アカウントに関連付けます。

リソースサーバーは、Keycloakから他のOAuth2アクセストークンと同様にPATを取得できます。たとえば、次のようにcurlを使用します。

上記の例では、 client_credentials グラントタイプを使用してサーバーからPATを取得しています。その結果、サーバーは次のような応答を返します。

リソースサーバーは、UMA準拠のエンドポイントを使用して、リモートでリソースを管理できます。

This endpoint provides registration operations outlined as follows (entire path omitted for clarity):

各操作の規約の詳細については、 UMAリソースセットの登録 を参照してください。

UMAプロトコルを使用するリソースサーバーは、特定のエンドポイントを使用してパーミッション・リクエストを管理できます。このエンドポイントは、パーミッション・リクエストを登録し、パーミッション・チケットを取得するためのUMA準拠のフローを提供します。

パーミッション・チケットは、パーミッション・リクエストを表す特殊なセキュリティ・トークン・タイプです。 UMA仕様では、パーミッション・チケットは次のとおりです。

認可サーバーからリソースサーバー、リソースサーバーからクライアント、最終的にはクライアントから認可サーバーに伝達され、認可サーバーが認可データの要求に適用する正しいポリシーを評価できるようにする相関ハンドル。

ほとんどの場合、このエンドポイントを直接処理する必要はありません。Keycloakは、リソースサーバーのUMAを有効にするポリシー・エンフォーサーを提供し、認可サーバーからパーミッション・チケットを取得し、このチケットをクライアント・アプリケーションに戻し、最後にリクエスティング・パーティ・トークン（RPT）に基づいて認可決定を実施することができます。

Keycloakからパーミッション・チケットを取得するプロセスは、クライアントがリソースにアクセスするために必要な許可なく保護されたリソースにアクセスしようとしたときに、パーミッション・チケットが取得される通常のクライアント・アプリケーションではなくリソースサーバーによって実行されます。パーミッション・チケットの発行は、UMAを使用する際の重要な側面です。これにより、リソースサーバーは次のことが可能になります。

クライアントの賢明な点として、パーミッション・チケットには重要な側面もあります。

これらは、UMAの他の側面が、特にプライバシーとリソースへのアクセス制御されたユーザーに関するパーミッション・チケットに強く基づいたUMAのメリットのほんの一部です。

認可APIトークン（AAT）は、 uma_authorization というスコープを持つ特別なOAuth2アクセス・トークンです。ユーザーを作成すると、Keycloakは自動的に uma_authorization というロールをユーザーに割り当てます。 uma_authorization ロールは、デフォルトのレルム・ロールです。

AATを使用すると、クライアント・アプリケーションはサーバーにユーザーのパーミッションを問い合わせることができます。

クライアント・アプリケーションは、他のOAuth2アクセス・トークンと同様にKeycloakからAATを取得できます。通常、クライアント・アプリケーションは、Keycloakでユーザーが正常に認証された後にAATを取得します。デフォルトでは、 authorization_code グラント・タイプはユーザーの認証に使用され、サーバーは代わりにクライアント・アプリケーションにOAuth2アクセス・トークンを発行します。

以下の例では、リソース・オーナー・パスワード・クレデンシャル・グラント・タイプを使用してAATをリクエストしています。

その結果、サーバーの応答は次のようになります。

UMAプロトコルを使用するクライアント・アプリケーションは、特定のエンドポイントを使用して、リクエスティング・パーティー・トークン（RPT）と呼ばれる特別なセキュリティー・トークンを取得できます。このトークンは、要求されているリソースに関連するパーミッションおよび認可ポリシーの評価の結果として、ユーザーに付与されたすべてのパーミッションで構成されます。RPTを使用すると、クライアント・アプリケーションはリソースサーバーで保護されたリソースにアクセスできます。

RPTを要求するときは、次の2つのことを指定する必要があります。

パーミッション・チケットは、ベアラートークンとしてAATを使用してリクエストを認証するために、AATが Authorization ヘッダーに含まれているかどうかを示すパラメーターとして、HTTPリクエストに追加されます。

その結果、サーバーの応答は次のようになります。

クライアント・アプリケーションは、特定のエンドポイントを使用して、リクエスティング・パーティー・トークン（RPT）と呼ばれる特別なセキュリティ・トークンを取得できます。このトークンは、要求されているリソースに関連する権限および認可ポリシーの評価の結果として、ユーザーのすべてのエンタイトルメント（または権限）で構成されます。RPTを使用すると、クライアント・アプリケーションはリソース・サーバーで保護されたリソースにアクセスできます。

Keycloakでリソースサーバーとして機能するクライアント・アプリケーションを識別するために、上記の client_id パラメーターを指定する必要があります。評価の範囲を特定のリソースサーバーによって管理されるリソース、スコープおよび権限に制限するには、クライアント識別子を指定する必要があります。

エンタイトルメントAPIには次の2種類があります。

エンタイトルメントAPIエンドポイントは、ユーザーの識別情報を表すリクエスト内のアクセス・トークンと、ユーザーの代理として認可データにアクセスするための同意を期待します。アクセス・トークンは、HTTP Authorization ヘッダーを使用してベアラー・トークンとして送信する必要があります。

エンタイトルメントAPIエンドポイントを正常に呼び出すと、サーバーによって付与されたすべての権限を持つRPTが取得されます。

エンタイトルメントを要求するとき、クライアント・アプリケーションは、メタデータ情報をリクエストに関連付けさせて、パーミッションの取得方法を定義することができます。

次のセクションでは、エンタイトルメント・リクエストに含めることができるさまざまな情報を、メタデータとして使用する方法とタイミングについて説明します。

クライアントは、 include_resource_name を使用して、サーバーによって付与された各パーミッションにリソースの名前を含めるかどうかを決定できます。このオプションを使用すると、RPTのサイズを縮小し、クライアントとサーバー間の通信を最適化できます。

デフォルトでは、RPT内のパーミッションには、単一のパーミッションごとに付与されたリソースのIDと名前の両方が含まれています。このオプションは、リソース・サーバーがリソースのIDに基づいてのみリソースをマップできる場合に特に便利です。

クライアントは、 limit を使用して、サーバーから返されるRPT内で予想されるパーミッションの数を指定できます。制限オプションは次のように動作します。

このオプションを使用すると、クライアントはRPTのサイズを制御し、サーバーによって付与された最後の権限のみを保持できます。クライアントが以前に発行されたRPTを送信することができ、新しい権限（別名: Incremental Authorization）を求めている場合にのみ意味があります。

場合によっては、リクエスティング・パーティー・トークン（RPT）をイントロスペクトして、その有効性をチェックしたり、トークン内の権限を取得して、リソース・サーバー側で認可の決定を行うことがあります。

トークンのイントロスペクションが役立つ2つの主な使用例があります。

トークン・イントロスペクションは基本的に、RPTに関する情報を取得するための OAuth2トークン・イントロスペクション 準拠のエンドポイントです。

このエンドポイントを使用してRPTをイントロスペクションするには、次のようにしてサーバーにリクエストを送信します。

イントロスペクション・エンドポイントには2つのパラメータが必要です。

その結果、サーバーの応答は次のようになります。

RPTがアクティブでない場合、代わりにこのレスポンスが返されます。

いいえ、両方のエンタイトルメントAPIは、RPTのデフォルトの形式として JSON web token（JWT） 仕様を使用します。

リモート・イントロスペクション・エンドポイントを呼び出さずにこれらのトークンを検証する場合は、RPTをデコードしてローカルでその有効性を問い合わせることができます。トークンをデコードすると、トークン内の権限を使用して認可の決定を行うこともできます。

これは本来、ポリシー・エンフォーサーが行うことです。次のことを確認してください。

クライアントの設定は、 keycloak.json ファイルで次のように定義されています。

設定ファイルは通常、クライアントの keycloak.json ファイルを見つける際のデフォルトのローケーションであるアプリケーションのクラスパスにあります。

クラスパスに keycloak.json ファイルがあることを考慮して、次のように新しい AuthzClient インスタンスを作成することができます。

ユーザー・エンタイトルメントを取得する方法の例を示します。

1つ以上のリソースのセットに対してユーザー・エンタイトルメントを取得する方法の例を示します。

アプリケーションのポリシー適用を有効にするには、 keycloak.json ファイルに次のプロパティーを追加します。

または、保護されているリソースを手動で定義する場合は、以下のようにもう少し詳細化します。

各設定オプションの説明は次のとおりです。

アダプターが bearer-only の設定オプションで設定されている場合、ポリシー・エンフォーサーは、ベアラー・トークンのパーミッションに基づいて、保護されたリソースへのアクセス・リクエストが許可または拒否されるかどうかを決定します。

この例では、アプリケーションの keycloak.json ファイルは次のようになります。

ポリシーの施行が有効になっている場合、サーバーから取得したパーミッションは org.keycloak.AuthorizationContext で利用できます。このクラスは、パーミッションを取得し、特定のリソースまたはスコープに対してアクセス権が付与されているかどうかを確認するために使用できるいくつかのメソッドを提供します。

サーブレット・コンテナ－内の認可コンテキストの取得

認可コンテキストを使用すると、サーバーによって行われて返された決定を、より詳細に制御できます。たとえば、リソースまたはスコープに関連付けられたパーミッションに応じて、アイテムを表示または非表示にする動的なメニューを作成することができます。

AuthorizationContext は、Keycloak認可サービスのメイン機能の1つです。上記の例から、保護されたリソースはそれらを管理するポリシーに直接関連付けられていないことが分かります。

次のような、ロールベースのアクセス制御（RBAC）を使用した同様のコードを考えてみましょう。

どちらの例も同じ要件に対応していますが、異なる方法で対応しています。RBACでは、ロールはリソースに対するアクセスのみを 暗黙的に 定義します。Keycloakを使用すると、RBAC、属性ベースのアクセス制御（ABAC）、その他のBACバリアントのいずれを使用していても、リソースに直接フォーカスした管理しやすいコードを作成できます。与えられたリソースまたはスコープに対するパーミッションを持っているかどうかです。

セキュリティ要件が変更され、プロジェクト・マネージャーに加えて、PMOが新しいプロジェクトを作成できるようになったとします。

セキュリティ要件は変更されますが、Keycloakを使用すると、新しい要件を満たすためにアプリケーションコードを変更する必要はありません。アプリケーションがリソースとスコープの識別子に基づいていれば、認可サーバー内の特定のリソースに関連付けられているパーミッションまたはポリシーの設定を変更するだけで済みます。この場合、 Project Resource および（または）スコープ urn:project.com:project:create に関連するパーミッションとポリシーが変更されます。

AuthorizationContext は、以下のようにアプリケーションに設定された認可クライアントAPIへの参照を取得するためにも使用できます。

場合によっては、ポリシー・エンフォーサーによって保護されたリソース・サーバーが、認可サーバーによって提供されるAPIにアクセスする必要があります。取得した AuthzClient インスタンスで、リソース・サーバーはリソースを作成したり、プログラムで特定のパーミッションをチェックするためにサーバーとやりとりすることができます。

Keycloakサーバーには、ポリシー・エンフォーサーによって保護されたリソース・サーバーと対話するために使用できるJavaScriptライブラリが付属しています。このライブラリはKeycloak JavaScriptアダプターに基づいています。これを統合すると、クライアントはKeycloakサーバーからアクセス権を取得できます。

次の script タグをWebページに含めることで、実行中のKeycloakサーバー・インスタンスからこのライブラリを入手できます。

これを実行すると、次のように KeycloakAuthorization インスタンスを作成できます。

keycloak-authz.js ライブラリには2つの主な機能があります。

いずれの場合も、リソース・サーバーとKeycloak認可サービスの両方との対話を容易にし、クライアントがリソース・サーバー上の保護されたリソースにアクセスするベアラー・トークンとして使用できる権限を持つトークンを取得できます。

サーバーでHTTPSを使用する場合は、アダプターが次のように設定されていることを確認してください。

上記の設定により、認可クライアントでTLS/HTTPSが有効になり、HTTPSスキームを使用してリモートからKeycloakサーバーにアクセスできるようになります。