Server Administration Guide

すべてのUI画面はKeycloakで国際化されています。デフォルトの言語は英語ですが、 Theme タブの Internationalization スイッチをオンにすると、サポートしたいロケールとデフォルト・ロケールを選択できます。次回ユーザーがログインすると、ログイン画面、ユーザー・アカウント管理UI、および管理コンソールで使用する言語をログインページで選択できます。Server Developer Guideでは、言語を追加する方法について説明しています。

ユーザーがパスワードを持っていない場合、またはパスワードが削除されている場合、 Set Password セクションがページに表示されます。

ユーザーのパスワードを作成するには、新しいパスワードを入力します。すべてを入力したら、 Set Password ボタンをクリックします。 Temporary スイッチがオンの場合、この新しいパスワードは1回しか使用できず、ユーザーはログイン後にパスワードの変更を求められます。

ユーザーがパスワードを既に持っている場合、 Reset Password セクションでリセットすることが出来ます。

また、電子メールが設定されている場合は、パスワードのリセットを求めるメールをユーザーに送信できます。 Reset Action リストボックスから Update Password を選択し、 Send Email をクリックしてください。 必要に応じて、レルム設定の Tokens タブから、電子メールのリンクの有効時間を変更することができます。 送信された電子メールには、パスワードの更新画面へのリンクが含まれています。

ユーザーは、パスワードタイプのクレデンシャルを1つしか持てないことに注意してください。

管理コンソール内で特定のユーザーに他の種類のクレデンシャルを設定することはできません。これはユーザーの責任です。ユーザーがOTPデバイスを紛失した場合、またはクレデンシャルが侵害された場合は、 Credentials タブでユーザーのクレデンシャルを削除だけできます。

ユーザー一覧の Add User ボタンや、ログイン画面のユーザー登録リンクを介してユーザーが作成される時に、アカウントに追加される必須アクションを指定することもできます。デフォルトの必須アクションを指定するには、左側のメニューの Authentication から、 Required Actions タブをクリックします。

新しいユーザーがログインするときに実行する必須アクションの Default Action 列のチェックボックスをクリックするだけです。

多くの組織では、新規ユーザーが初めてログインするときに、Webサイトの利用規約に同意する必要があるという要件があります。Keycloakはこの機能を必須アクションとして実装していますが、利用するためには設定が必要です。1つは、前述の Required Actions タブに移動し、 Terms and Conditions アクションを有効にする必要があります。また、 base ログインテーマの terms.ftl ファイルも編集する必要があります。テーマの拡張と作成の詳細については、Server Developer Guideを参照してください。

ボットに対する登録から保護するため、KeycloakはGoogle reCAPTCHAと連携しています。これを有効にするには、まずGoogle Recaptcha Websiteから、reCAPTCHAサイトの鍵とパスワードを取得できるようにAPIキーを作成する必要があります。参考までに、localhostはデフォルトで動作しますので、ドメインを指定する必要はありません。

次に、Keycloak管理コンソールで実行する必要のある手順がいくつかあります。左の Authentication メニューをクリックし、 Flows タブのドロップダウンリストから Registration フローを選択します。

ラジオボタンをクリックして、'reCAPTCHA’の必要条件を Required に設定します。これにより、画面上でreCAPTCHAが有効になります。次に、Google reCAPTCHAウェブサイトで生成した鍵とパスワードを入力する必要があります。reCAPTCHAフローの右側にある’Actions’ボタンをクリックし、次に"Config"リンクをクリックし、この設定ページでreCAPTCHAサイトの鍵とパスワードを入力します。

最後に、Keycloakが設定するデフォルトのHTTPレスポンス・ヘッダーを変更する必要があります。Keycloakは、ウェブサイトのiframe内にログインページを含めることを防ぎます。これはクリックジャック攻撃を防ぐためです。iframe内で登録ページを使用するためGoogleを認可する必要があります。左メニューの Realm Settings から Security Defenses タブを選んでください。 X-Frame-Options と Content-Security-Policy ヘッダーの両方の値に https://www.google.com を追加する必要があります。

ここまで設定を行うと、登録ページにreCAPTCHAが表示されます。ログインテーマの register.ftl を編集して、reCAPTCHAボタンの配置とスタイリングを行うこともできます。テーマの拡張と作成の詳細については、Server Developer Guideを参照してください。

各ポリシータイプの説明は次のとおりです。

OTPジェネレーターには、時間ベース（TOTP）およびカウンターベース（HOTP）の2つのアルゴリズムがあります。TOTPの場合、トークン・ジェネレーターは現在の時刻と共有パスワードをハッシュ化します。サーバーは、特定の時間枠内のすべてのハッシュをサブミットされた値と比較することによってOTPを検証します。したがって、TOTPは短い時間枠（通常は30秒）でのみ有効です。HOTPの場合、現在の時刻の代わりに共有カウンターが使用されます。サーバーは、成功したOTPログインごとにカウンターをインクリメントします。したがって、有効なOTPはログインが成功した後にのみ変更されます。

TOTPは、短い時間枠でのみ有効であるため、HOTPより少し安全です。HOTPは、ユーザーが急いでOTPを入力する必要がないため、ユーザー・フレンドリーです。KeycloakがTOTPを実装した方法では、この区別はもう少しぼやけてしまいます。HOTPは、サーバーがカウンターをインクリメントするたびにデータベースを更新する必要があります。これは、負荷が大きいときに認証サーバー上でパフォーマンスが低下する可能性があります。より効率的な代替手段を提供するために、TOTPは使用されるパスワードを覚えていません。これにより、DBの更新は不要ですが、有効な時間間隔でTOTPを再利用できるという欠点があります。将来のバージョンのKeycloakでは、TOTPが時間間隔内に古いOTPをチェックするかどうかを設定できるようになる予定です。

Keycloakには、一定数の組み込みフローが付属しています。これらのフローは変更できませんが、要件はニーズに合わせて変更できます。

このセクションでは、組み込みのブラウザー・ログイン・フローのウォークスルーを行います。左側のドロップダウン・リストで browser を選択して、以下に示す画面に移動します。

フロー選択リストの右側にあるツールチップ（小さな疑問符）の上にカーソルを合わせると、フローの内容とその説明が表示されます。

Auth Type 列は、実行される認証またはアクションの名前です。認証がインデントされている場合、これはサブフローにあり、親の動作に応じて実行される場合と実行されない場合があります。 Requirement 列は、アクションが実行されるかどうかを定義するラジオボタンのセットです。このコンテキストでの各ラジオボタンの意味を説明します。

このセクションでは、フローの仕組みと独自のフローの作成方法について詳しく説明します。独自のフローを設計する際には、重要な機能とセキュリティーの考慮事項があることに注意してください。不正なフローが作成されると、誰もログインできなくなるか、意図よりも少ない検証でユーザーがログインできてしまうか、または単にエラーになります。

次のいずれかで、フローを作成できます。

新しいフローを作成するときは、トップレベルのフローを作成する必要があります。

次のオプションがあります。

フローが作成されると、 New ボタンと Copy ボタンに加えて、 Delete 、 Add execution 、 Add flow ボタンがクリックできます。

最終的にフローが行うことは、フローとサブフローの構造、それらのフローのエグゼキューション、およびサブフローとエグゼキューションに設定された要件によって決まります。

Add execution ボタンで実行をエグゼキューションできます。エグゼキューションには、リセットメールの送信からOTPの検証まで、さまざまなアクションがあります。 Provider の隣のツールチップ（小さなクエスチョン・マーク）にカーソルを合わせると、エグゼキューションが実行する内容が説明されます。

これらは、 自動的エグゼキューション と 対話的エグゼキューション に分けることができます。 自動的エグゼキューション は Cookie エグゼキューションに似ており、フローで遭遇したときに自動的にアクションを実行します。 対話的エグゼキューション は、通常、ユーザー入力を取得するためにフローを停止します。正常に実行されたエグゼキューションは、 success ステータスを取得します。これは、フローが成功したかどうかの一部であるため、重要です。たとえば、空の Browser フローでは誰もログインできません。そのため、成功として評価されるエグゼキューションが少なくとも1つ、たとえば正しく入力されて送信された Username Password Form が必要です。

サブフローは、 Add flow ボタンを使用してトップレベルのフローに追加できます。このボタンは、 Create Top Level Form ページに非常によく似た Create Execution Flow ページを開きます。唯一の違いは、 Flow Type が generic （前と同様）または form のいずれかになることです。 form タイプは、組み込みの Registration フローに対して行われるように、ユーザーに対して単一のフォームを生成するサブフローを構築するために使用されます。サブフローは、含まれるエグゼキューションの評価方法に応じて成功として評価される特別なタイプの実行です（これには、含まれるサブフローの評価も含まれます）。そして、この評価のロジックは、エグゼキューションとサブフローの要件に依存します。

これを完全に理解するには、フローを評価するときに要件がどのように機能するかについて、より完全な説明が必要です（これはサブフローにも適用されます）。詳しくは エグゼキューション要件のセクション を参照してください。

エグゼキューションを追加した後、要件が正しい値に設定されていることを確認する必要があることに注意してください。必要な要件が1つしかない場合でも、設定されていない可能性があります。

フローを構築するとき、フローに追加されるすべての要素の右側に Actions メニューがあります。フローに追加されたすべての要素には、このメニューに Delete オプションがあり、フローから削除できます。実行には、 Identity Provider Redirector の場合のように、エグゼキューションを設定するための Config メニューオプションを含めることができます。サブフローには、 Add execution および Add flow メニューオプションを使用して、エグゼキューションとサブフローを追加することもできます。

最後に、実行の順序が重要であるため、名前の左側に設定された上下ボタンを使用して、それぞれのフロー内でエグゼキューションとサブフローを上下に移動できます。

フローの作成を説明するために、このセクションでは、より高度なブラウザー・ログイン・フローの作成について説明します。このフローの目的は、ユーザーがWebAuthn、およびパスワードとOTPを使用した2要素認証を使用して、パスワードなしでログインすることを選択できるようにすることです。作成するフローは標準のブラウザー・ログインに似ていますが、ユーザー名の選択に到達すると分岐します。ただし、フローをコピーする代わりに、最初からフローを作成します。

Username formは、"Browser"フローのUsername Password Formに似ていますが、ユーザー名のみを要求するため、ユーザーはパスワードレス・ログインを実行できます。ただし、これにより必然的にKeycloakサーバーでのユーザー列挙攻撃が可能であることに注意してください。これは利便性に対して避けられないセキュリティー・リスクであるため、このフローでは攻撃者がパスワードを推測するだけでは入れないようにしなければなりません。

生成される最終的なフローは次のとおりです。

ユーザー名を入力すると、このフローは次のように機能します。

WebAuthnパスワードレスのエグゼキューションは Required ではなく Alternative に設定されているため、このフローではユーザーにWebAuthnのクレデンシャルの登録を求めることはありません。ユーザーにWebAuthnのクレデンシャルを登録させるには、管理者が必須アクションを追加する必要があります。これは最初にレルムで Webauthn Register Passwordless の必須アクションが有効になっていることを確認して（WebAuthnドキュメントを参照）、次にユーザーのクレデンシャル管理メニューの Credential Reset の部分を使用して必須アクションを設定します。

このようなより高度なフローを作成すると、微妙な副作用が生じる可能性があります。たとえば、ユーザーのパスワードをリセットする機能を有効にする場合、パスワード・フォームからアクセスできます。デフォルトの"Reset Credentials"のフローでは、ユーザーはユーザー名を入力する必要があります。"Browser Password-less"フローの前半でユーザー名を既に入力しているため、これはKeycloakには不要であり、ユーザー・エクスペリエンスの観点からは最適ではありません。これを修正するには、次のことができます。

これはプラットフォームに依存します。正確な手順は、使用するOSとKerberosベンダーによって異なります。Kerberosサーバーのセットアップと設定の正確な方法については、Windows Active Directory、MIT Kerberos、およびOSのドキュメントを参照してください。

少なくとも次のことが必要です。

次に、以下のコマンドで、HTTPプリンシパルを追加し、キーをkeytabファイルにエクスポートします。

keytabファイル /tmp/http.keytab は、Keycloakサーバーが実行されるホスト上でアクセス可能である必要があります。

Kerberosクライアントをマシンにインストールする必要があります。これもプラットフォームに依存します。Fedora、Ubuntu、またはRHELを使用している場合は、Kerberosクライアントとその他のいくつかのユーティリティーを含む freeipa-client パッケージをインストールできます。Kerberosクライアントを設定してください（Linuxの場合は /etc/krb5.conf にあります）。Kerberosレルムを配置し、少なくともサーバーが稼働するHTTPドメインを設定する必要があります。レルムMYDOMAIN.ORGの例では、 domain_realm セクションを次のように設定することができます。

次に、HTTPプリンシパルを使用してkeytabファイルをエクスポートし、そのファイルがKeycloakサーバーが実行されているプロセスにアクセス可能であることを確認する必要があります。プロダクションでは、このプロセスだけで読み込めるのであれば理想的ですが、他のファイルも読み込めるわけではありません。上記のMIT Kerberosの例では、すでにkeytabを /tmp/http.keytab にエクスポートしています。KDCとKeycloakが同じホスト上で実行されている場合、そのファイルはすでに使用可能です。

クライアントはKerberosクライアントをインストールし、上記のようにkrb5.confを設定する必要があります。さらに、ブラウザーでSPNEGOログインを有効にする必要があります。そのブラウザーを使用している場合は、KerberosのためのFirefoxの設定を参照してください。URI .mydomain.org は、 network.negotiate-auth.trusted-uris 設定オプションで許可する必要があります。

Windowsドメインでは、通常、WindowsドメインのSPNEGO認証にIEがすでに参加できるため、クライアントは特別な設定を行う必要はありません。

Kerberosで簡単にテストできるように、テスト用の設定例をいくつか用意しました。

Kerberos 5は、クレデンシャルの委任の概念をサポートしています。このシナリオでは、アプリケーションがKerberosチケットにアクセスして、Kerberosでセキュリティー保護されている他のサービスとやりとりすることができます。KeycloakサーバーでSPNEGOプロトコルが処理されるため、Keycloakサーバーからアプリケーションに送信されるOpenID Connectトークンクレーム内のGSSクレデンシャルか、SAMLアサーション属性を伝播する必要があります。このクレームをトークンまたはアサーションに挿入するには、各アプリケーションで gss delegation credential と呼ばれるビルトイン・プロトコル・マッパーを有効にする必要があります。これは、アプリケーションのクライアント・ページの Mappers タブで有効になります。詳細については、プロトコル・マッパーの章を参照してください。

アプリケーションは、他のサービスに対してGSSコールを使用する前に、Keycloakから受け取ったクレームをデシリアライズする必要があります。クレデンシャルをアクセストークンからGSSクレデンシャル・オブジェクトにデシリアライズしたら、このクレデンシャルを GSSManager.createContext メソッドに渡して、次の例のようにGSSContextを作成する必要があります。

これを詳細に示した例があります。Keycloakのサンプル配布物またはデモ配布ダウンロードの examples/kerberos にあります。サンプルソースを ここ で直接チェックすることもできます。

krb5.conf ファイルで 転送可能な Kerberosチケットを設定し、ブラウザーに委任されたクレデンシャルのサポートを追加する必要があることに注意してください。

Kerberos V5プロトコルでは、 realm はKerberosデータベース（通常はLDAPサーバー）で定義されたKerberosプリンシパルのセットです。Kerberosプロトコルには、クロスレルム・トラストという概念があります。たとえば、2つのケルベロス・レルムAとBがある場合、クロスレルム・トラストは、レルムAのユーザーがレルムBのリソース（サービス）にアクセスできるようにします。つまり、レルムBはレルムAを信頼します。

Keycloakサーバーは、クロスレルム・トラストをサポートしています。これを達成するために必要なことがいくつかあります。

課題がある場合は、追加のログを有効にして問題をデバッグすることをお勧めします。

正規表現フィルタリングは、 Identity Source が Match SubjectDN using regular expression か、 Match IssuerDN using regular expression のどちらかにセットされている場合にのみ適用されます。

以下のセクションでは、X.509クライアント証明書認証を有効にするためにWildFly/UndertowとKeycloakサーバーを設定する方法について説明します。

HTTPリクエストがKeycloakサーバーに直接送信されると、WildFly undertowサブシステムはSSLハンドシェイクを確立し、クライアント証明書を抽出します。クライアント証明書は、サーブレット仕様で指定されているHTTPリクエストの属性 javax.servlet.request.X509Certificate に保存されます。Keycloak X509オーセンティケーターは、この属性から証明書を検索できます。

ただし、Keycloakサーバーがロードバランサーまたはリバース・プロキシーの背後にあるHTTPリクエストをリッスンする場合、クライアント証明書を抽出してMutual SSL接続を確立するのはプロキシー・サーバーであるかもしれません。リバース・プロキシーは通常、認証されたクライアント証明書を基礎となるもとのリクエストのHTTPヘッダーに入れ、バックエンドのKeycloakサーバーに転送します。この場合、Keycloakは、Undertowの場合と同様に、HTTPリクエストの属性ではなく、HTTPヘッダーからX.509証明書チェーンをルックアップできる必要があります。

Keycloakがリバース・プロキシーの背後にある場合、通常はKEYCLOAK_HOME/standalone/configuration/standalone.xmlに x509cert-lookup SPIの代替プロバイダーを設定する必要があります。HTTPヘッダーから証明書を検索する default プロバイダーに加えて、次に説明する haproxy と apache という2つの組み込みプロバイダーも追加されています。

2FAのWebAuthnサポートのセットアップ手順は次のとおりです。

WebAuthn Authenticator を用いた条件サブフローが使用された認証フロー設定の場合、WebAuthnオーセンティケーターの登録後、ユーザーは以下の操作を行います。

WebAuthnオーセンティケーターを登録するとき、KeycloakはこのWebAuthnオーセンティケーターによって生成された認証ステートメントを検証します。この検証プロセスで、Keycloakはこの認証ステートメントの信頼性を検証します。トラストアンカーの証明書が必要です。Keycloakは Keycloak truststore を使用するため、これらの証明書を事前にインポートする必要があります。

この検証ステートメントの信頼性検証を省略する場合は、このトラストストアを無効にするか、WebAuthnポリシーの設定項目"Attestation Conveyance Preference"を"none"に設定してください。

WebAuthnは二要素認証によく使用されますが、認証の第一要素として使用したい場合もあります。この場合、 passwordless WebAuthnクレデンシャルを持つユーザーはKeycloakにパスワード無しで認証することが出来ます。Keycloakは単一のレルムのコンテキスト、更には単一の認証フローのコンテキストでも、パスワードレスと二要素認証の両方でWebAuthnを使用することができます。

管理者は一般に、WebAuthnパスワードレス認証にユーザーが登録したセキュリティキーに対して、異なる（通常より強力な）要件を満たすことを要求する場合があります。たとえば、それらのセキュリティキーは、ユーザーがそのセキュリティキーに対してPINを用いて認証することを要求したり、そのセキュリティキーが強力な認証局で構成証明されていることを要求する場合があります。

このため、Keycloakでは管理者が個別に WebAuthn Passwordless Policy を設定できます。個別の Webauthn Register Passwordless タイプの必須アクションや、個別の WebAuthn Passwordless Authenticator タイプのオーセンティケーターを設定します。

OIDCには、クライアントまたはアプリケーションがユーザーを認証し、 ID トークンおよび アクセス トークンを受け取るさまざまな方法があります。どの方法を使用するかは、アクセスを要求するアプリケーションまたはクライアントのタイプによって大きく異なります。これらのフローはすべてOIDCおよびOAuth 2.0の仕様で説明されていますので、ここでは簡単な概要のみを説明します。

Keycloakが発行するOIDCエンドポイントのリストです。これらのURLは、Keycloak以外のクライアント・アダプターを使用して、認証サーバーとOIDCでやりとりしている場合に便利です。これらはすべてが相対URLであり、URLのルートはHTTP(S)プロトコル、ホスト名、通常は /auth のプレフィックス付きのパスからなります。例： https://localhost:8080/auth

これらのURLすべてで、 {realm-name} はレルムの名前に置き換えてください。

SAMLは、認証プロトコルを実行する際にXMLドキュメントを交換するためのいくつかの異なる方法を定義しています。 REDIRECT バインディングと POST バインディングは、ブラウザーベースのアプリケーションをカバーします。 ECP バインディングは、REST呼び出しを扱います。他のバインディング種別もありますが、Keycloakはこれらの3つしかサポートしていません。

KeycloakではすべてのSAMLリクエストに対して1つのエンドポイントしかありません。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/saml

すべてのバインディングはこのエンドポイントを使用します。

Docker API documentationはこのプロセスを最もよく説明していますが、Keycloak認証サーバーの観点から、簡単な概要を以下に示します。

Keycloakは、すべてのDocker認証v2リクエストに対して、実際には1つのエンドポイントしか持っていません。

http(s)://authserver.host/auth/realms/{realm-name}/protocol/docker-v2

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

Mutual TLSは、アクセストークンとリフレッシュトークンを、TLSハンドシェイク中に交換されるクライアント証明書にバインドします。これは、これらのトークンを盗む方法を見つけた攻撃者がトークンを行使するのを防ぎます。このタイプのトークンは、holder-of-keyトークンと呼ばれます。ベアラートークンとは異なり、holder-of-keyトークンの受信者は、トークンの送信者が正当であるかどうかを検証することができます。

トークン・リクエストで次の条件が満たされた場合、Keycloakはアクセストークンとリフレッシュトークンをクライアント証明書でバインドし、holder-of-keyトークンとして発行します。すべての条件が満たされない場合、Keycloakはトークン・リクエストを拒否します。

KeycloakでMutual TLSを有効にするには、WildFlyでMutual SSLを有効にするを参照してください。

以下の場合、Keycloakはクライアントがアクセストークンまたはリフレッシュトークンを送信していることを確認します。検証に失敗した場合、Keycloakはトークンを拒否します。

詳細については、OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokensの Mutual TLS Client Certificate Bound Access Tokens を参照してください。

Proof Key for Code Exchange（PKCE）

攻撃者が正当なクライアントに発行された認可コードを盗んだとしても、PKCEは攻撃者がそのコードと引き換えてトークンを受信できないようにします。

管理者は、次の3つのオプションを選択できます。

Proof Key for Code Exchange Code Challenge Method

詳細については、 RFC 7636 Proof Key for Code Exchange by OAuth Public Clients を参照してください。

Signed and Encrypted ID Token Support

Keycloakは、 Json Web Encryption (JWE) の仕様に従ってIDトークンを暗号化できます。管理者は、クライアントごとにIDトークンを暗号化するかどうかを決定できます。この機能はデフォルトで無効になっています。

IDトークンを暗号化するためのキーは、Content Encryption Key (CEK)と呼ばれます。Keycloakとクライアントは、使用するCEKとその配信方法について交渉する必要があります。これを行う方法は、Key Management Modeと呼ばれます。

JWE仕様は、5種類のKey Management Modeを決定します。Keycloakはそれらの間で Key Encryptionをサポートします。

Key Encryptionでは、クライアントは非対称暗号化のキーペアを生成します。公開鍵はCEKの暗号化に使用されます。KeycloakはIDトークンごとにCEKを生成し、この生成されたCEKによってIDトークンを暗号化し、このクライアントの公開キーによってこのCEKを暗号化します。クライアントは、この暗号化されたCEKを自分の秘密鍵で復号し、復号されたCEKでIDトークンを復号します。したがって、クライアント以外の第三者はIDトークンを復号できません。

クライアントは、CEKを暗号化するための公開鍵をKeycloakに渡す必要があります。Keycloakは、クライアントが提供するURLからの公開鍵のダウンロードをサポートしています。クライアントは Json Web Keys (JWK) の仕様に従って公開鍵を提供する必要があります。その方法は、 Confidential Client Credentials の Signed JWT で定義されています。詳細な手順は次のとおりです。

鍵暗号化のアルゴリズムは、 Json Web Algorithm (JWA) の仕様で定義されています。Keycloakは、デフォルトのパラメーター（RSA-OAEP）を使用してRSAES-PKCS1-v1_5（RSA1_5）およびRSAES OAEPをサポートします。このアルゴリズムを選択する詳細な手順は次のとおりです。

CEKによるIDトークン暗号化アルゴリズムは、 JWA の仕様でも定義されています。Keycloakは、AES_128_CBC_HMAC_SHA_256認証暗号化（A128CBC-HS256）および128ビットキーを使用したAES GCM（A128GCM）をサポートしています。このアルゴリズムを選択する詳細な手順は次のとおりです。

クライアントの Settings タブでクライアントのアクセスタイプを confidential に設定した場合、新しい Credentials タブが表示されます。このタイプのクライアントを扱う際には、クライアントのクレデンシャルを設定する必要があります。

Client Authenticator リストボックスはコンフィデンシャル・クライアントのために使用するクレデンシャルのタイプを指定します。デフォルトでは、クライアントIDとシークレットが使用されます。シークレットは自動的に生成され、 Regenerate Secret ボタンを使用して、必要に応じてこのシークレットを再生成することができます。

また、シークレットではなく署名付きJSON Web Token（JWT）またはx509証明書検証（Mutual TLSとも呼ばれます）を使用することもできます。

このクレデンシャル・タイプを選択するときは、クライアント用の秘密鍵と証明書も生成する必要があります。秘密鍵はJWTに署名するために使用され、証明書はサーバーによって署名の検証に使用されます。この手順を開始するには、 Generate new keys and certificate ボタンをクリックしてください。

これらの鍵を生成すると、Keycloakが証明書を保管するので、使用するクライアントの秘密鍵と証明書をダウンロードする必要があります。必要なアーカイブ形式を選択し、秘密鍵とストアのパスワードを指定します。

また、外部ツールを使用してこれらを生成し、クライアントの証明書をインポートすることもできます。

インポートできるフォーマットは複数あります。証明書が保存されているアーカイブ形式を選択し、ファイルを選択して、 Import ボタンをクリックします。

最後に注意ですが、 Use JWKS URL を選択した場合は、証明書をインポートする必要はありません。その場合、クライアントが公開鍵を JWK 形式で公開するURLを指定することができます。クライアントが鍵を変更すると、Keycloakが自動的にダウンロードするため、Keycloak側で再インポートする必要がなく、柔軟性があります。

Keycloakアダプターで保護されたクライアントを使用する場合は、 https://myhost.com/myapp がクライアント・アプリケーションのルートURLであるとすると、 https://myhost.com/myapp/k_jwks のようなJWKS URLを設定できます。詳細については、Server Developer Guideを参照してください。

Client Authenticator リストボックスでこのオプションを選択すると、秘密鍵の代わりにクライアント・シークレットで署名されたJWTを使うことができます。

このクライアント・シークレットは、クライアントによってJWTに署名するために使用されます。

このオプションを有効にすると、KeycloakはTLSハンドシェイク中にクライアントが適切なX509証明書を使用するかどうかを検証します。

バリデーターは、設定された正規表現の検証式を使用して、証明書のSubject DNフィールドもチェックします。いくつかのユースケースでは、すべての証明書を受け入れるだけで十分です。その場合、 (.*?)(?:$) 式を使うことができます。

KeycloakがリクエストからクライアントIDを取得するには、2つの方法があります。最初のオプションは、クエリーの client_id パラメーターです（ OAuth 2.0 Specification のセクション2.2で説明されています）。2番目のオプションは、フォーム・パラメーターとして client_id を提供することです。

各OIDCクライアントには、 サービス・アカウント が組み込まれており、アクセストークンを取得できます。これは、OAuth 2.0仕様のクライアント・クレデンシャル・グラントで説明されています。この機能を使用するには、クライアントのアクセスタイプを confidential に設定する必要があります。これを行うと、 Service Accounts Enabled スイッチが現れます。このスイッチをオンにする必要があります。また、クライアント・クレデンシャルを設定していることを確認してください。

サービス・アカウントを使用するには、有効な confidential クライアントを登録していなければなりません。また、そのクライアントのKeycloak管理コンソールの Service Accounts Enabled スイッチをオンにする必要があります。 Service Account Roles タブでは、このクライアントに代わって取得されたサービス・アカウントで使用可能なロールを設定できます。 Full Scope Allowed をオンにしない限り、このクライアントのロール・スコープ・マッピング（ Scope タブ）でロールを利用可能にする必要があることに注意してください。通常のログインと同様に、アクセストークンのロールは以下の論理積となります。

呼び出すREST URLは /auth/realms/{realm-name}/protocol/openid-connect/token です。このURLを呼び出すのはPOSTリクエストで、クライアントのクレデンシャルを送信する必要があります。デフォルトでは、クライアントのクレデンシャルはクライアントのclientIdとclientSecretによって Authorization: Basic ヘッダーで表されますが、署名されたJWTアサーションまたはクライアント認証のためのその他のカスタム・メカニズムでクライアントを認証することもできます。また、OAuth2仕様に従ってパラメーター grant_type=client_credentials を使う必要があります。

たとえば、サービス・アカウントを取得するためのPOST呼び出しは次のようになります。

このレスポンスは、OAuth 2.0仕様の standard JSON document になります。

取得したアクセストークンはリフレッシュされたり、有効期間を超えたリクエストによりログアウトされます。

Keycloakがデプロイされる典型的な環境は、一般に、認証にKeycloakを使用する confidential または public なクライアント・アプリケーション（フロントエンド・クライアント・アプリケーション）のセットで構成されています。

フロントエンドのクライアント・アプリケーションからのリクエストを処理し、リソースを提供する サービス（OAuth 2の仕様では リソースサーバー と呼ばれます）もあります。これらのサービスは通常、特定のリクエストに対して認証するためにサービスに送信される アクセストークン （ベアラートークン）を必要とします。このトークンは、クライアント・アプリケーションがKeycloakに対してログインを試行したときに取得されたものです。

サービス間の信頼性が低い環境では、次のシナリオが発生する可能性があります。

このフローは、サービス間の信頼性が高い多くの環境では問題にならないかもしれません。しかし、サービス間の信頼性が低い他の環境では、これが問題になる可能性があります。

上記の例のようにアクセストークンの誤用を防ぐために、トークンの Audience を制限し、トークンのAudienceを検証するようにサービスを設定することをお勧めします。これが行われると、上記のフローは次のように変わります。

my-app が後で good-service を呼び出したい場合は、 scope = good-service を指定してSSOログインを発行し、別のトークンを取得する必要があります。返されたトークンはAudienceとして good-service を含みます。

そして good-service を呼び出すために使うことができます。

IDP Initiated ログインは、特定のアプリケーション／クライアントにログインするエンドポイントをKeycloakサーバーに設定できるようにする機能です。クライアントの Settings タブで、 IDP Initiated SSO URL Name を指定する必要があります。これは空白を含まない単純な文字列です。その後、 root/auth/realms/{realm}/protocol/saml/clients/{url-name} のURLでクライアントを参照することができます 。

IdP initiated loginの実装は、REDIRECT バインディングよりも POST バインディングを優先します（詳細についてはSAMLバインディングをチェックしてください）。したがって、最終的なバインディングとSPのURLは次のように選択されます。

クライアントが特別なリレーステートを必要とする場合は、 IDP Initiated SSO Relay State フィールドの Settings タブでこれを設定することもできます。あるいはブラウザーは RelayState クエリー・パラメーター root/auth/realms/{realm}/protocol/saml/clients/{url-name}?RelayState=thestate でリレーステートを指定することができます。

アイデンティティー・ブローカリングを使用する場合、クライアントに対して外部IDPからのIDP Initiated ログインを設定することができます。実際のクライアントは、上記のようにブローカーIDPでIDP Initiated ログインするように設定されます。外部IDPはクライアントを、特別なURLを指し示す、アプリケーションIDP Initiated ログインのためにセットアップする必要があります。URLはブローカーを指し、ブローカリングIDPで選択されたクライアントのために、IDP Initiated ログイン・エンドポイントを代理します。つまり、外部IDPのクライアント設定では次のようになります。

基本的なクライアント設定をブローカリングIDPから外部IDPのクライアント設定にインポートすることができます。ブローカリングIDPのアイデンティティー・プロバイダーの設定から利用可能なSP 記述子を使用し、 clients/client-id をエンドポイントURLに追加します。

手動でSAML 2.0クライアントを登録する代わりに、標準のSAMLエンティティー記述子XMLファイルを使用してインポートできます。Add Clientページには Import オプションがあります。

Select File ボタンをクリックし、エンティティー記述子ファイルを読み込みます。そこにあるすべての情報を見直して、すべてが正しく設定されていることを確認してください。

mod-auth-mellon のような一部のSAMLクライアント・アダプターでは、IDPのXMLエンティティー記述子が必要です。公開URL root/auth/realms/{realm}/protocol/saml/descriptor にアクセスすれば、これを取得することができます。

マッパーの実装には 優先順位 があります。この優先順位はマッパーの設定プロパティーではなく、むしろそれはマッパーの具体的な実装のプロパティーです。

マッパーは、管理コンソールにおけるマッパーのリストの順序に従ってソートされ、トークンまたはアサーションの変更はその順序で最も低いものが最初に適用されます。これは、他の実装に依存している実装が必要な順序で処理されることを意味します。

たとえば、最初にトークンに含まれるロールを割り出したい場合は、まずそれらのロールに基づいてオーディエンスを解決します。次に、トークンですでに利用可能なロールとオーディエンスを使用するJavaScriptのスクリプトを処理します。

ユーザー・セッションの詳細は、マッパーを介し、さまざまな基準に依存します。クライアントである機能を使用または有効にすると、ユーザー・セッションの詳細が自動的に含まれます。セッションの詳細を含めるために、 Add builtin ボタンをクリックすることもできます。

代理ユーザー・セッションは、次の詳細を提供します。

サービス・アカウント・セッションは、次の詳細を提供します。

Script Mapper を使用すると、ユーザー定義のJavaScriptコードを実行して、クレームをトークンにマッピングできます。サーバーにスクリプトをデプロイする方法の詳細については、JavaScriptプロバイダーを参照してください。

スクリプトをデプロイしたら、使用可能なマッパーのリストからデプロイしたスクリプトを選択できるはずです。

クライアント・スコープを作成するときは、 Protocol を選択する必要があります。同じプロトコルを使用するクライアントだけがこのクライアント・スコープにリンクできます。

新しいレルムを作成すると、あらかじめ定義された（ビルトインの）クライアント・スコープの一覧がメニューに表示されます。

クライアント・スコープの offline_access は、クライアントがオフライントークンを取得したいときに便利です。オフライントークンについては、オフライン・アクセスのセクションまたは OpenID Connect仕様 を参照してください。ここでは、スコープ・パラメーターは offline_access 値で定義されています。

クライアント・スコープの profile 、 email 、 address および phone も OpenID Connect仕様 で定義されています。これらのクライアント・スコープには、ロール・スコープ・マッピングは定義されていませんが、いくつかのプロトコル・マッパーが定義されています。これらのマッパーは、OpenID Connect仕様で定義されたクレームに対応しています。

たとえば、 phone のクライアント・スコープを開き、Mappers タブを開くためにクリックすると、 phone スコープの仕様で定義されているクレームに対応するプロトコル・マッパーが表示されます。

phone クライアント・スコープがクライアントにリンクされると、そのクライアントは自動的に phone クライアント・スコープで定義されたすべてのプロトコル・マッパーを継承します。このクライアント用に発行されたアクセストークンには、ユーザーに関する電話番号情報が格納されます（定義された電話番号をユーザーが持っていると仮定する場合）。

ビルトインのクライアント・スコープには、仕様に従って定義されたプロトコル・マッパーが完全に含まれていますが、クライアント・スコープの編集やプロトコル・マッパー（またはロール・スコープ・マッピング）の作成/更新/削除は自由にでできます。

クライアント・スコープの roles はOpenID Connectの仕様では定義されておらず、アクセストークンの scope のクレームにも自動的に追加されません。このクライアント・スコープにはいくつかのマッパーがあります。マッパーは、ユーザーのロールをアクセストークンに追加し、オーディエンスのセクションで説明されているように少なくとも1つのクライアントロールを持つクライアントにオーディエンスを追加するために使用されます。

クライアント・スコープ web-origins もOpenID Connect仕様で定義されておらず、scope クレームに追加されていません。これは、許可されたWebオリジンをアクセストークンの allowed-origins クレームに追加するために使用されます。

クライアント・スコープ microprofile-jwt は、 MicroProfile/JWT Auth Specification で定義されているクレームを処理するために作成されました。このクライアント・スコープは、 upn クレーム用のユーザー・プロパティー・マッパーと groups クレーム用のレルム・ロール・マッパーを定義します。MicroProfile/JWT固有のクレームを作成するためさまざまなプロパティーを使用できるように、これらのマッパーは必要に応じて変更できます。

クライアント・スコープには、同意画面に関連するオプションが含まれています。これらのオプションは、リンクされたクライアントが同意を要求するように設定されている場合（クライアント上で Consent Required スイッチが有効になっている場合）にのみ有効です。

クライアント・スコープとクライアントとの間のリンクは、特定のクライアントの Client Scopes タブで設定されます。クライアント・スコープとクライアントをリンクする方法は2つあります。

クライアントの Mappers と Scope タブには、このクライアント用に宣言されたプロトコル・マッパーとロールスコープのマッピングが含まれています。クライアント・スコープから継承されたマッパーとスコープ・マッピングは含まれていません。ただし、特定のクライアントのトークンを生成するときに、有効なプロトコル・マッパー（クライアント自体で定義され、リンクされたクライアント・スコープから継承されたプロトコル・マッパー）がどれであるか、有効なロール・スコープ・マッピングが使用されているかを確認すると便利です。

クライアントの Client Scopes タブをクリックし、 Evaluate サブタブを開くと、これらのすべてを見ることができます。ここから、適用するオプションのクライアント・スコープを選択できます。これは scope パラメーターの値も表示します。このパラメーターは、アプリケーションからKeycloak OpenID Connect認可エンドポイントに送信する必要があります。

特定のユーザーに対してトークンを発行する場合、そのユーザーがそのトークンの使用を許可されている場合にのみクライアント・スコープが適用されます。クライアント・スコープにロール・スコープ・マッピングが定義されていない場合、各ユーザーはこのクライアント・スコープの使用を自動的に許可されます。ただし、クライアント・スコープにそれ自体で定義されているロール・スコープ・マッピングがある場合、そのユーザーは少なくとも1つのロールのメンバーである必要があります。つまり、ユーザーロールとクライアント・スコープのロールの間には共通部分がなければなりません。この共通部分を評価するときには、複合ロールが考慮されます。

ユーザーがクライアント・スコープの使用を許可されていない場合、トークンの生成時にプロトコル・マッパーまたはロール・スコープ・マッピングは使用されず、クライアント・スコープはトークンの scope 値に表示されません。

Realm Default Client Scopes は、新しく作成されたクライアントに自動的にリンクされるクライアント・スコープのセットを定義することを可能にします。

左側のメニュー項目の Client Scopes を開き、Default Client Scopes を選択します。

ここから、新しく作成したクライアントに Default Client Scopes と Optional Client Scopes として追加するクライアント・スコープを選択します。

クライアントが作成されると、必要に応じてデフォルトのクライアント・スコープのリンクを解除できます。これは、デフォルトロールを削除する方法と似ています。

scope という用語は、Keycloakのいくつかの場所で使用されています。これらのスコープはお互いに関連していますが、異なるコンテキストと意味を持つことがあります。ここでは、Keycloakで使用されるさまざまな scopes について説明します。

デフォルトロールを使用すると、アイデンティティー・ブローカリングを使用してユーザーを新規作成またはインポートしたときに、ユーザー・ロール・マッピングを自動的に割り当てることができます。デフォルトロールを指定するには、左側のメニュー項目 Roles に移動し、 Default Roles タブをクリックします。

スクリーンショットから分かるように、デフォルトでは多くの デフォルトロール がすでに設定されています。

master レルムには次の2つのレルムレベルのロールがあります。

admin ロールを持つユーザーはスーパーユーザーであり、サーバー上のあらゆるレルムを管理する完全なアクセス権を持っています。 create-realm ロールを持つユーザーは、新しいレルムを作成することができます。このユーザーは、自身が作成した全ての新しいレルムに対して、完全にアクセスできるようになります。

master レルム内の管理ユーザーは、システム内の1つ以上の他のレルムに対して管理権限を与えることができます。Keycloakの各レルムは、 master レルムのクライアントによって表されます。クライアントの名前は <realm name>-realm です。これらのクライアントには、個々のレルムを管理するためのさまざまなアクセスのレベルを定義したクライアントレベルのロールが定義されています。

利用可能なロールは次のとおりです。

ユーザーに必要なロールを割り当てると、管理コンソールの特定の部分のみを使用できます。

最初に、管理者が1つのクライアントだけを管理できるようにしましょう。この例では、 test というレルムと sales-application というクライアントがあります。レルム test では、レルムのユーザーに、そのアプリケーションだけを管理するパーミッションを与えます。

もう一つは、管理者がユーザーへの割り当てを許可したロールを制限することです。最後の例に続けて、 sales-admin ユーザーのパーミッション・セットを拡張して、このアプリケーションにアクセスできるユーザーを制御できるようにしましょう。きめ細かいパーミッションを使用して、 sales-admin が sales-application に特定のアクセスを許可するロールのみを割り当てることができます。また、管理者だけがロールを割り当てることができ、その他のユーザー管理は実行できないように制限することもできます。

sales-application には3つの異なるクライアント・ロールを定義しています。

sales-admin ユーザーが、これらのロールをシステム内のどのユーザーにも割り当てられるようにしたいです。これを行うための最初のステップは、管理者によってロールを割り当て可能とすることです。 viewLeads ロールをクリックすると、このロールの Permissions タブがあります。

そのタブをクリックし、 Permissions Enabled をONにすると、ポリシーを適用できるアクションが表示されます。

ここで知りたいのは map-role です。このパーミッションをクリックし、前の例で作成したユーザーポリシーを追加します。

これまでに行ったことは、 sales-admin が viewLeads ロールを割り当て可能とすることです。これから行うことは、管理者がこのロールをどのように割り当てることができるかを指定することです。これを行うには、このレルムの管理コンソールの Users セクションに移動する必要があります。左のメニュー項目の Users をクリックすると、レルムのユーザー・インターフェイスが表示されます。 Permissions タブから、 Permissions Enabled をクリックして有効にします。

ここで知りたいパーミッションは map-roles です。これは、管理者がロールをユーザーに割り当てる機能のみを許可するという点で、制限的なポリシーです。 map-roles パーミッションをクリックし、これに対して作成したユーザーポリシーを再度追加すると、 sales-admin はロールを任意のユーザーに割り当てることができます。

最後に、 view-users ロールを sales-admin に追加します。これにより、管理者は sales-application ロールを追加したいレルムのユーザーを表示することができます。

特定のクライアントやクライアントの特定のロールを管理する以外にも、きめ細かいパーミッションを使用すると、さらに多くのことを行うことができます。この章では、レルムで記述できるパーミッション種別の一覧を示します。

鍵を定期的にローテーションさせることをお勧めします。ローテーションを行うには、既存のアクティブな鍵よりも優先度の高い新しい鍵を作成することから始めます。または、同じ優先度で新しい鍵を作成し、以前の鍵をパッシブにします。

新しい鍵が利用可能になると、新しいトークンとCookieはすべて新しい鍵で署名されます。ユーザーがアプリケーションを認証すると、SSO Cookieは新しい署名で更新されます。OpenID Connectトークンをリフレッシュすると、新しいトークンが新しい鍵で署名されます。つまり、すべてのトークンとCookieが新しい鍵を使用するようになるため、しばらく経つと古い鍵を削除することができます。

古い鍵を削除するのにどれくらいかかるのかは、セキュリティーと、すべてのCookieとトークンが確実に更新される時間とのトレードオフです。一般的には、数週間後に古い鍵を削除することが可能となるべきでしょう。追加された新しい鍵と古い鍵が削除されるまでの間にアクティブでなかったユーザーは、再認証する必要があります。

これは、オフライン・トークンにも適用されます。トークンが更新されていることを確認するには、古い鍵が削除される前にアプリケーションでトークンをリフレッシュする必要があります。

ガイドラインとして、3～6か月ごとに新しい鍵を作成し、新しい鍵が作成されてから1～2か月後に古い鍵を削除することをお勧めします。

新しい鍵ペアを追加するには、 Providers を選択し、ドロップダウンから rsa-generated を選択します。優先順位を変更して、新しい鍵ペアがアクティブな鍵ペアになるようにすることができます。より小さい、またはより大きい鍵を必要とする場合、 鍵のサイズ を変更することもできます（デフォルトは2048、サポートされている値は1024、2048、および4096）。

新しい鍵を追加するには Save をクリックしてください。これにより、自己署名証明書を含む新しい鍵ペアが生成されます。

プロバイダーの優先順位を変更しても鍵は再生成されませんが、鍵のサイズを変更したい場合は、プロバイダーを編集して新しい鍵を生成することができます。

他で取得した鍵ペアと証明書を追加するには、 Providers を選択し、ドロップダウンから rsa を選択します。優先順位を変更することで、新しい鍵ペアをアクティブな鍵ペアにすることができます。

秘密鍵をアップロードするには、 Private RSA Key の Select file をクリックしてください。ファイルはPEM形式でエンコードする必要があります。公開鍵は、秘密鍵から自動的に抽出されるため、アップロードする必要はありません。

鍵の署名付き証明書を持っている場合、 X509 Certificate の横の Select file をクリックしてください。持っていない場合は、これをスキップすることができ、自己署名証明書が生成されます。

ホスト上のJavaキーストア・ファイルに格納されている鍵ペアと証明書を追加するには、 Providers を選択し、ドロップダウンから java-keystore を選択します。優先順位を変更して、新しい鍵ペアをアクティブにすることができます。

Keystore 、 Keystore Password 、 Key Alias 、 Key Password の値を入力し、 Save をクリックします。

Active で鍵ペアを見つけて、 Provider 列のプロバイダーをクリックします。これにより、鍵のプロバイダーの設定画面が表示されます。 Active のスイッチをクリックして OFF にし、 Save をクリックします。鍵はアクティブでなくなり、署名の検証にのみ使用できます。

Active で鍵ペアを見つけて、 Provider 列のプロバイダーをクリックします。これにより、鍵のプロバイダーの設定画面が表示されます。 Enabled のスイッチをクリックして OFF にし、 Save をクリックします。鍵は無効化されます。

また、 Providers テーブルからプロバイダーを削除することもできます。

Keycloakでは署名鍵がローカルに格納されており、クライアント・アプリケーション、ユーザーまたは他のエンティティーと共有されることはありません。しかし、レルムの署名鍵が漏洩したと思われる場合は、先に説明したように新しい鍵ペアを生成してから、即座に漏洩した鍵ペアを削除する必要があります。

次に、クライアント・アプリケーションが漏洩した鍵で署名されたトークンを受け入れないようにするためには、管理コンソールから実行可能なレルムのnot-beforeポリシーを更新して適用する必要があります。新しいポリシーを適用すると、クライアント・アプリケーションは、漏洩した鍵で署名された既存のトークンを受け入れなくなり、クライアント・アプリケーションはKeycloakから新しい鍵ペアをダウンロードすることになります。したがって、漏洩した鍵で署名されたトークンは有効でなくなります。RESTとコンフィデンシャル・クライアントは Admin URL を設定する必要があるので、Keycloakは適用されたnot-beforeポリシーに関するリクエストを送ることができます。

Bitbucketでログインできるようにするには、いくつかのステップを完了しなければなりません。

まず、 Identity Providers の左メニュー項目に移動し、Add provider ドロップダウン・リストから Bitbucket を選択します。これにより、 Add identity provider ページが表示されます。

Save をクリックする前に、Bitbucketから Client ID と Client Secret を取得する必要があります。

Bitbucketでログインできるようにするには、まずアプリケーション・プロジェクトを OAuth on Bitbucket Cloud に登録する必要があります。

Add consumer ボタンをクリックします。

Keycloakの Add Identity Provider ページから Redirect URI をコピーし、BitbucketのAdd OAuth ConsumerページのCallback URLフィールドに入力します。

同じページで、 Account の下の Email と Read のチェックボックスをマークして、アプリケーションがユーザーの電子メールを読めるようにします。

登録が完了したら、 Save をクリックしてください。これにより、Bitbucketのアプリケーション管理ページが開きます。このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。 Save をクリックしてください。

Facebookでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから Facebook を選択します。これにより、 Add identity provider ページが表示されます。

Facebookから Client ID と Client Secret を取得する必要があるので、まだ保存ボタンをクリックすることはできません。このページで必須入力のデータの1つは、 Redirect URI です。FacebookにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

Facebookでのログインを可能にするには、まず Facebook Developer Console でプロジェクトとクライアントを作成する必要があります。

コンソールにログインすると、画面の右上に My Apps と表示されるプル・ダウン・メニューが表示されます。 Add a New App メニュー項目を選択します。

Website アイコンを選択します。 Skip and Create App ID ボタンをクリックします。

メールアドレスとアプリのカテゴリーは必須フィールドです。作業が完了すると、アプリケーションのダッシュボードに移動します。 Settings の左のメニュー項目をクリックしてください。

このページの最後にある + Add Platform ボタンをクリックし、 Website アイコンを選択します。Keycloakの Add identity provider ページの Redirect URI をコピーして、Facebookの Website 設定ブロックの Site URL に貼り付けます。

この後、Facebookアプリを公開する必要があります。左のメニューの App Review をクリックし、ボタンを"Yes"に切り替えます。

このページからApp IDとApp Secretを取得して、Keycloakの Add identity provider ページに入力する必要があります。これを取得するには、左のメニュー項目 Dashboard をクリックし、 App Secret の下の Show をクリックします。Keycloakに戻り、これらの項目を指定し、最後にFacebookアイデンティティー・プロバイダーを保存します。

Facebook用の Add identity provider ページで注意が必要な1つの設定オプションは、 Default Scopes フィールドです。 このフィールドでは、このプロバイダーで認証するときに、ユーザーが承認する必要があるスコープを手動で指定できます。スコープの完全なリストについては、 https://developers.facebook.com/docs/graph-api を参照してください。デフォルトでは、Keycloakは email のスコープを使用します。

GitHubでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから GitHub を選択します。これにより、 Add identity provider ページが表示されます。

GitHubから Client ID と Client Secret を取得する必要があるので、まだ保存をクリックすることはできません。このページから必要なデータの1つは、 Redirect URI です。GitHubにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

GitHubでログインを可能にするには、まず GitHub Developer applications でアプリケーションを登録する必要があります。

Register a new application ボタンをクリックします。

Keycloakの Add Identity Provider ページから Redirect URI をコピーし、GitHubの Register a new OAuth application ページの Authorization callback URL フィールドにそれを入力する必要があります。このページを完了すると、アプリケーションの管理ページに移動します。

このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。Keycloakに戻り、それらの項目を入力します。

GitLabでログインできるようにするには、いくつかのステップを完了しなければなりません。

まず、 Identity Providers の左メニュー項目に移動し、Add provider ドロップダウン・リストから GitLab を選択します。これにより、 Add identity provider ページが表示されます。

Save をクリックする前に、GitLabから Client ID と Client Secret を取得する必要があります。

GitLabでログインできるようにするには、まずアプリケーションを GitLab as OAuth2 authentication service provider に登録する必要があります。

Keycloakの Add Identity Provider ページから取得した Redirect URI をコピーし、GitLabのAdd new applicationページのRedirect URIフィールドに入力します。

登録が完了したら、 Save application をクリックしてください。 これにより、GitLabのアプリケーション管理ページが開きます。このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。

終了するには、Keycloakに戻り、それらを入力してください。 Save をクリックします。

Googleでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから Google を選択します。これにより、 Add identity provider ページが表示されます。

Googleから Client ID と Client Secret を取得する必要があるので、まだ保存ボタンをクリックすることはできません。このページで必須入力のデータの1つは、 Redirect URI です。GoogleにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

Googleでのログインを可能にするには、まず Google Developer Console でプロジェクトとクライアントを作成する必要があります。次に、クライアントIDとシークレットをKeycloakの管理コンソールにコピーする必要があります。

最初にGoogleでプロジェクトを作成する方法を説明します。

Google Developer Consoleにログインします。

Create Project ボタンをクリックします。 Project name と Project ID に任意の値を使用し、 Create ボタンをクリックします。プロジェクトが作成されるのを待ちます（これには時間がかかることがあります）。作成されると、プロジェクトのダッシュボードに遷移します。

次に、Googleデベロッパーコンソールの APIs & Services セクションに移動します。その画面で、 Credentials 管理に移動します。

ユーザーがKeycloakからGoogleにログインすると、Googleからの同意画面が表示され、Keycloakにユーザー・プロファイルに関する情報の表示が許可されているかどうかが尋ねられます。そのため、Googleはプロダクトのシークレットを作成する前に、プロダクトに関するいくつかの基本情報を必要とします。新しいプロジェクトのために、あなたは最初に OAuth同意画面 を設定しなければなりません。

非常に基本的な設定では、アプリケーション名を入力するだけで十分です。このページでは、Google APIのスコープなど、追加の詳細を設定することもできます。

次のステップは、OAuthクライアントIDとクライアント・シークレットを作成することです。 Credentials 管理に戻り、Credentials タブに行き、 Create credentials ボタンの下の OAuth client ID を選択してください。

そうすると Create OAuth client ID ページが表示されます。アプリケーション・タイプとして Web application を選択します。また、Keycloakの Add Identity Provider ページから Redirect URI をコピーし、 Authorized redirect URIs フィールドに貼り付ける必要があります。これを済ませたら、 Create ボタンをクリックします。

Create をクリックすると、 Credentials ページが表示されます。新しいOAuth 2.0クライアントのIDをクリックすると、新しいGoogleクライアントの設定が表示されます。

このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。Keycloakに戻り、それらの項目を入力します。

Google用の Add identity provider ページで注意が必要な1つの設定オプションは、 Default Scopes フィールドです。 このフィールドでは、プロバイダーで認証するときにユーザーが認可する必要があるスコープを手動で指定できます。スコープの一覧については、 https://developers.google.com/oauthplayground/ を参照してください。 デフォルトでは、Keycloakは openid profile email のスコープを使用します。

あなたの組織がG Suiteを使用していて、組織のメンバーだけにアクセスを制限したい場合は、G Suiteに対して使用するドメインを Hosted Domain フィールドに入力して有効にする必要があります。

LinkedInでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから LinkedIn を選択します。 これにより、 Add identity provider ページが表示されます。

LinkedInから Client ID と Client Secret を取得する必要があるので、まだ保存をクリックすることはできません。このページから必要なデータの1つは、 Redirect URI です。クライアントとしてKeycloakを登録するときに、LinkedInにそれを提供する必要がありますので、このURIをクリップボードにコピーしておいてください。

LinkedInでログインを可能にするには、まず LinkedIn Developer Network でアプリケーションを作成する必要があります。

Create Application ボタンをクリックします。これにより、 Create a New Application ページが表示されます。

フォームに適切な値を入力し、 Submit ボタンをクリックします。 これにより、新しいアプリケーションの設定ページが表示されます。

Default Application Permissions セクションで r_basicprofile と r_emailaddress を選択してください。Keycloakの Add Identity Provider ページから Redirect URI をコピーし、それをLinkedInアプリ設定ページの OAuth 2.0 の Authorized Redirect URLs フィールドに入力する必要があります。入力後、 Update ボタンをクリックすることを忘れないでください！

このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。Keycloakに戻り、それらの項目を入力します。

Microsoftでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから Microsoft を選択します。これにより、 Add identity provider ページが表示されます。

Microsoftから Client ID と Client Secret を取得する必要があるので、まだ保存ボタンをクリックすることはできません。このページで必須入力のデータの1つは、 Redirect URI です。MicrosoftにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

Microsoftアカウントでログインを可能にするには、まずMicrosoftでOAuthアプリケーションを登録する必要があります。 Microsoft Application Registration のURLにアクセスします。

アプリケーション名を入力し、 Create application をクリックします。 これにより、新しいアプリケーションのアプリケーション設定ページが表示されます。

Keycloakの Add Identity Provider ページから Redirect URI をコピーし、それをMicrosoftアプリケーション・ページの Redirect URIs フィールドに追加する必要があります。 Add Url ボタンをクリックし、変更を Save してください。

最後に、このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。Keycloakに戻り、それらの項目を入力します。

OpenShiftでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから OpenShift を選択します。これにより、 Add identity provider ページが表示されます。

oc コマンドライン・ツールを使ってクライアントを登録することができます。

oc create コマンドで定義されたクライアントIDとシークレットを使用して、Keycloakの Add identity provider ページに入力します。Keycloakに戻り、それらの項目を入力します。

詳細なガイドについては、 official OpenShift documentation を参照してください。

OpenShift 4でログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから OpenShift 4 を選択します。これにより、 Add identity provider ページが表示されます。

oc コマンドライン・ツールを使ってクライアントを登録することができます。

oc create コマンドで定義されたクライアントIDとシークレットを使用して、Keycloakの Add identity provider ページに入力します。Keycloakに戻り、それらの項目を入力します。

詳細なガイドについては、 official OpenShift documentation を参照してください。

PayPalでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから PayPal を選択します。これにより、 Add identity provider ページが表示されます。

PayPalから Client ID と Client Secret を取得する必要があるので、まだ保存ボタンをクリックすることはできません。このページで必須入力のデータの1つは、 Redirect URI です。PayPalにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

PayPalでログインを可能にするには、まず PayPal Developer applications でアプリケーションを登録する必要があります。

Create App ボタンをクリックします。

これで、アプリケーションの設定ページが表示されます。

Stack Overflowでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add provider のドロップダウン・リストから Stack Overflow を選択します。これにより、 Add identity provider ページが表示されます。

Stack Overflowでログインを可能にするには、まず Stack Apps にOAuthアプリケーションを登録する必要があります。 registering your application on Stack Apps のURLにアクセスしてログインします。

アプリケーション名とOAuthドメイン名を入力し、 Register your Application をクリックします。他の項目に必要なものを入力してください。

最後に、このページからクライアントIDとシークレットを取得し、Keycloakの Add identity provider ページに入力する必要があります。Keycloakに戻り、それらの項目を入力します。

Twitterでログインできるようにするには、いくつかのステップを完了する必要があります。まず、左のメニュー項目の Identity Providers に移動し、 Add identity provider のドロップダウン・リストから Twitter を選択します。これにより、 Add identity provider ページが表示されます。

Twitterから Client ID と Client Secret を取得する必要があるので、まだ保存ボタンをクリックすることはできません。このページで必須入力のデータの1つは、 Redirect URI です。TwitterにKeycloakをクライアントとして登録するときに提供する必要があるため、このURIをクリップボードにコピーしてください。

Twtterでログインを可能にするには、まず Twitter Application Management でアプリケーションを作成する必要があります。

Create New App ボタンをクリックします。これにより、 Create an Application ページが表示されます。

NameとDescriptionを入力します。Websiteは何でも構いませんが、 localhost アドレスを持つことはできません。 Callback URL には、Keycloak の Add Identity Provider ページから Redirect URI をコピーする必要があります。

保存をクリックすると、 Details ページに移動します。

次に、 Keys and Access Tokens タブをクリックします。

最後に、このページからAPIキーとシークレットを取得し、Keycloakの Add identity provider ページの Client ID フィールドと Client Secret フィールドにコピーする必要があります。

SAMLプロバイダーを作成すると、そのプロバイダーを表示するときに EXPORT ボタンも表示されます。このボタンをクリックすると、外部SPにインポートするために使用できるSAML SPエンティティー記述子がエクスポートされます。

このメタデータは、このURLにアクセスすることで一般公開されています。

First Broker Login フローによって提供されるデフォルトの動作について説明します。

プロンプトを表示せずにユーザーを自動的にリンクする最初のログインフローを設定するには、次の2つのオーセンティケーターを使用して新しいフローを作成します。

デフォルトの最初のログインフローは、外部アイデンティティーと一致するKeycloakアカウントを検索し、それらをリンクすることを提案します。一致するKeycloakアカウントがない場合は、自動的に作成されます。このデフォルトの動作は、たとえば読み取り専用のLDAPユーザーストアを使用する場合（つまり、すべてのユーザーが事前に作成されている場合）など、設定によっては適さない場合があります。この場合、自動ユーザー作成をオフにする必要があります。ユーザーの作成を無効にするには以下を実施します。

この設定は、Keycloak自体が、外部アイデンティティーに対応する内部アカウントを判別できないことも意味します。したがって、 Verify Existing Account By Re-authentication オーセンティケーターは、ユーザーにユーザー名とパスワードの両方を提供するように要求します。

すべてのSSO Cookieセットが無効になり、アクティブなブラウザー・セッションで認証を要求するクライアントは再ログインする必要があります。このログアウト・イベントは、特定のクライアント（特に、Keycloak OIDCクライアント・アダプターを使用しているクライアント）にのみ通知されます。SAMLのような他のクライアント・タイプはバックチャネル・ログアウト・リクエストを受信しません。

Logout all をクリックしても、未処理のアクセストークンは取り消されないことに注意することが重要です。それらは失効する必要があります。失効ポリシーをクライアントにプッシュする必要がありますが、これもKeycloak OIDCクライアント・アダプターを使用するクライアントだけで機能します。

Sessions ページでは、各クライアントにドリルダウンすることもできます。これにより、そのクライアントの Sessions タブが表示されます。 Show Sessions ボタンをクリックすると、そのアプリケーションにログインしているユーザーを参照できます。

個々のユーザーの Sessions タブに移動すると、セッション情報を表示することもできます。

デフォルトでは、KeycloakはLDAPからローカルKeycloakユーザー・データベースにユーザーをインポートします。このユーザーのコピーは、要求に応じて同期されるか、または定期的なバックグラウンド・タスクによって同期されます。1つの例外はパスワードです。パスワードはインポートされず、パスワードの検証はLDAPサーバーに委任されます。このアプローチの利点は、必要とされる追加のユーザーごとにデータをローカルに保存できるため、すべてのKeycloak機能が動作することです。また、この方法は、キャッシュされていないユーザーが2回目のアクセス時にKeycloakデータベースからロードされるため、LDAPサーバーの負荷を軽減します。LDAPサーバーにかかる唯一の負荷はパスワードの検証です。このアプローチの欠点は、ユーザーが最初に照会されたときに、Keycloakのデータベースへの挿入が必要になることです。インポートも、必要に応じてLDAPサーバーと同期する必要があります。

また、ユーザーをKeycloakユーザー・データベースにインポートしないように選択することもできます。この場合、Keycloakランタイムが使用する共通ユーザーモデルは、LDAPサーバーによってのみバックアップされます。つまり、LDAPがKeycloakの機能に必要なデータをサポートしていない場合、その機能は動作しません。この方法の利点は、LDAPユーザーのコピーをKeycloakのユーザー・データベースにインポートして同期するオーバーヘッドがないことです。

このストレージモードは Import Users スイッチによって制御されます。ユーザーをインポートするには On に設定します。

ユーザーはユーザー・アカウント・サービスを介して、管理者は管理コンソールを介して、ユーザーのメタデータを変更できます。設定に応じて、LDAPの更新権限がある場合とない場合があります。 Edit Mode 設定オプションは、LDAPストアの編集ポリシーを定義します。

LDAPストアへのセキュリティー保護された接続URL（たとえば ldaps://myhost.com:636 ）を設定すると、KeycloakはLDAPサーバーとの通信にSSLを使用します。重要なことは、Keycloakサーバー側でトラストストアを適切に設定することです。そうしないと、KeycloakはLDAPへのSSL接続を信頼できません。

Keycloakのグローバル・トラストストアは、トラストストアSPIで設定できます。詳細については、 Server Installation and Configuration Guide のリンクを参照してください。トラストストアSPIを設定しないと、トラストストアは、Javaによって提供されるデフォルトのメカニズム（システム・プロパティー javax.net.ssl.trustStore によって提供されるファイルか、システム・プロパティーが設定されていなければJDKのcacertsファイル）にフォールバックします。

LDAPフェデレーション・プロバイダーの設定には、設定プロパティー Use Truststore SPI があり、トラストストアSPIを使用するかどうかを選択できます。デフォルト値は Only for ldaps です。ほとんどのデプロイメントで問題ありません。トラストストアSPIは、LDAPへの接続URLが ldaps で始まる場合にのみ使用されます。

インポートを有効としている場合、LDAPプロバイダーは必要なLDAPユーザーの同期（インポート）をKeycloakローカル・データベースに自動的に行います。ユーザーがログインすると、LDAPプロバイダーはLDAPユーザーをKeycloakデータベースにインポートし、LDAPパスワードに対して認証します。これは、ユーザーがインポートされる唯一の時です。管理コンソールの左側の Users メニュー項目に移動し、 View all users ボタンをクリックすると、Keycloakによって少なくとも1回は認証されたLDAPユーザーのみが表示されます。この操作によりLDAPのユーザーDB全体をインポートしないように、この方法で実装されています。

すべてのLDAPユーザーをKeycloakのデータベースに同期させたい場合は、LDAPプロバイダー設定ページの Sync Settings を設定して有効にすることができます。2種類の同期が存在します。

同期を処理する最善の方法は、LDAPプロバイダーを最初に作成するときに Synchronize all users ボタンをクリックして、その後、変更されたユーザーの定期的な同期を設定することです。

LDAPマッパーは リスナー であり、さまざまな時点でLDAPプロバイダーによってトリガーされ、LDAP統合の別の拡張ポイントを提供します。これらは、ユーザーがLDAP経由でログインしてインポートが要求されたとき、Keycloakの登録が開始されたとき、または、ユーザーが管理コンソールから問い合わせを受けたときにトリガーされます。LDAPフェデレーション・プロバイダーを作成すると、Keycloakは自動的にこのプロバイダー用の組込み マッパー セットを提供します。このセットを変更して新しいマッパーを作成したり、既存のマッパーを更新／削除することが自由にできます。