Server Administration Guide

Keycloakでは、すべてのUI画面が国際化されます。デフォルトの言語は英語ですが、どのロケールに対応するか、またどれをデフォルトのロケールにするかを選択できます。

次回ログイン時に、ログイン画面、アカウントコンソール、管理コンソールで使用する言語を選択できます。

ロケール・セレクター・プロバイダーは、入手した情報から最適なロケールを提案します。しかし、ユーザーが誰であるかは不明なことが多いため、以前に認証されたユーザーのロケールを永続化されたCookieに記憶させます。

ロケールを選択するためのロジックは、以下の利用可能な最初のものが使用されます。

ユーザーが認証されると、前述の永続化されたCookieのロケールを更新するアクションがトリガーされます。ユーザーがログインページのロケール・セレクターを介してアクティブにロケールを切り替えた場合、ユーザーロケールもこの時点で更新されます。

ロケールを選択するロジックを変更したい場合は、カスタムの LocaleSelectorProvider を作成するオプションがあります。詳しくは Server Developer Guide を参照してください。ユーザーが認証されると、先ほどの永続化されたCookieのロケールを更新するためのアクションが発生します。ユーザーがログインページのロケール・セレクターでロケールを積極的に切り替えていた場合、この時点でユーザーのロケールも更新されます。

ロケールを選択するロジックを変更したい場合は、カスタムの LocaleSelectorProvider を作成するオプションがあります。詳しくは Server Developer Guide を参照してください。

Forgot Password を有効にすると、ユーザーがパスワードを忘れたり、OTPジェネレーターを紛失した場合に、ログイン・クレデンシャルをリセットすることができます。

電子メールで送信されるテキストは設定可能です。詳しくはServer Developer Guideを参照してください。

ユーザーがメールのリンクをクリックすると、Keycloakのパスワードを更新するように求められ、OTPジェネレーターを設定している場合は、KeycloakのOTPジェネレーターを再設定するように求められます。 組織のセキュリティー要件によっては、ユーザーに電子メールでOTPジェネレーターをリセットさせたくない場合もあります。

この動作を変更するには、以下の手順を実行します。

ログインしたユーザーがブラウザーを閉じると、セッションが破棄され、再度ログインする必要があります。Keycloakを設定すると、ログイン時に Remember Me のチェックボックスをクリックした場合に、ユーザーのログインセッションを維持することができます。このアクションは、ログインCookieをセッションのみのCookieから永続的なCookieに変えます。

この設定を保存すると、レルムのログインページに remember me のチェックボックスが表示されます。

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

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

古い鍵を削除する頻度は、セキュリティーとすべてのCookieとトークンの更新を確認することとのトレードオフになります。新しい鍵は3〜6カ月ごとに作成し、古い鍵は新しい鍵を作成してから1〜2カ月後に削除することを検討してください。新しい鍵が追加されてから古い鍵が削除されるまでの間にユーザーが活動していなかった場合、そのユーザーは再認証を行う必要があります。

鍵のローテーションは、オフライントークンにも適用されます。確実に更新されるように、アプリケーションは古い鍵が削除される前にトークンをリフレッシュする必要があります。

この操作により、自己署名入り証明書を含む新しいキーペアが生成されます。

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

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

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

関連する証明書チェーンを読み込むためには、キーペアを読み込むために使用したのと同じ Key Alias を使って、JavaのKeystoreファイルにインポートする必要があります。

Keycloakは、署名鍵をローカルにのみ保存し、クライアント・アプリケーションやユーザーまたは他のエンティティーと共有することはありません。しかし、レルムの署名鍵が漏洩したと思われる場合は、まず上記のように新しい鍵ペアを生成し、漏洩した鍵ペアを直ちに削除する必要があります。

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

not-beforeポリシーをプッシュすることで、クライアント・アプリケーションは、漏洩した鍵によって署名された既存のトークンを受け入れないようにすることができます。クライアント・アプリケーションは、Keycloakから新しいキーペアをダウンロードすることを強制されるので、漏洩した鍵によって署名されたトークンは無効となります。

Keycloakは、LDAP からローカルのKeycloakユーザー・データベースにユーザーをインポートします。このユーザー・データベースのコピーは、オンデマンドまたは定期的なバックグラウンド・タスクによって同期されます。パスワードの同期については例外が存在します。Keycloakは決してパスワードをインポートしません。パスワードの検証は常にLDAPサーバー上で行われます。

同期の利点は、ユーザーごとに必要な追加のデータがローカルに保存されるため、すべてのKeycloakの機能が効率的に動作することです。欠点は、Keycloakが特定のユーザーに初めて問い合わせるたびに、Keycloakが対応するデータベースの挿入を実行することです。

インポートをLDAPサーバーと同期させることができます。LDAPマッパーが常にデータベースではなくLDAPから特定の属性を読み取る場合、インポートの同期は不要です。

Keycloakのユーザー・データベースにユーザーをインポートすることなく、KeycloakでLDAPを使用することができます。LDAP サーバーは、Keycloakのランタイムが使用する共通ユーザーモデルをバックアップします。あるKeycloakの機能が必要とするデータをLDAPがサポートしていない場合、その機能は動作しません。この方法の利点は、LDAPユーザーのコピーをKeycloakユーザー・データベースにインポートして同期させるというリソース利用がないことです。

LDAP設定ページの Import Users スイッチは、このストレージモードを制御します。ユーザーをインポートするには、このスイッチを ON に切り替えます。

ユーザのメタデータは、ユーザーはアカウント・コンソールから、管理者は管理コンソールから修正することができます。LDAP設定ページの Edit Mode の設定は、ユーザーのLDAP更新権限を定義します。

LDAPストアへのセキュアな接続URL (例: ldaps://myhost.com:636 ) を設定すると、KeycloakはLDAPサーバーとの通信にSSLを使用します。KeycloakがLDAPへのSSL接続を信頼できるように、Keycloakサーバー側でトラストストアを設定します。

Truststore SPIを使用してKeycloakのグローバル・トラストストアを設定します。グローバル・トラストストアの設定の詳細については、 Server Installation and Configuration Guide を参照してください。これは、javax.net.ssl.trustStore システム・プロパティーが提供するファイル、またはシステム・プロパティーが未設定の場合はJDKのcacertsファイルです。

LDAPフェデレーション・プロバイダーの設定にある Use Truststore SPI の設定プロパティーは、トラストストアのSPIを制御します。デフォルトでは、Keycloakはこのプロパティーを Only for ldaps に設定しており、ほとんどの配備で適切な値になっています。Keycloakは、LDAPへの接続URLが ldaps のみで始まっている場合、Truststore SPI を使用します。

ImportUsers オプションを設定すると、LDAPプロバイダーはLDAPユーザーのKeycloakローカル・データベースへのインポートを処理するようになります。ユーザーが初めてログインするとき、LDAPプロバイダーはLDAPユーザーをKeycloakデータベースにインポートし、LDAPパスワードを検証します。Keycloakがユーザーをインポートするのは、この初回ログイン時のみです。管理コンソールの Users メニューをクリックし、 View all users ボタンをクリックすると、Keycloakによって少なくとも一度は認証されたLDAPユーザーだけが表示されます。Keycloakはこの方法でユーザーをインポートするため、この操作によってLDAPユーザーデータベース全体のインポートが開始されることはありません。

すべてのLDAPユーザーをKeycloakデータベースに同期させたい場合は、LDAPプロバイダーの設定ページで Sync Settings を設定し、有効にしてください。

同期には次の2つのタイプが存在します。

LDAPプロバイダーを最初に作成する際に、 Synchronize all users をクリックし、変更されたユーザーを定期的に同期させるように設定するのが最も良い方法です。

LDAPマッパーはLDAPプロバイダーによって起動される listeners です。LDAPマッパーはLDAP統合のためのもう一つの拡張ポイントを提供します。LDAPマッパーは以下のような場合に起動されます。

LDAPフェデレーションプロバイダーを作成すると、Keycloakは自動的にこのプロバイダー用の mappers セットを提供します。このセットはユーザーが変更可能であり、ユーザーはマッパーを開発したり、既存のマッパーを更新・削除したりすることができます。

ユーザー属性マッパー。ユーザー名、名、姓、電子メールなどの基本的な Keycloakのユーザー属性を、対応するLDAP属性にマッピングします。これらを拡張して、独自の属性マッピングを追加することができます。管理コンソールは、対応するマッパーの設定を支援するツールチップを提供します。

Keycloakがパスワードを更新するとき、Keycloakはパスワードをプレーンテキスト形式で送信します。この動作は、組み込みのKeycloakデータベースでパスワードを更新する場合、Keycloakがパスワードをデータベースに送信する前にハッシュとソルトを行う場合とは異なります。LDAPの場合、KeycloakはLDAPサーバに依存して、パスワードをハッシュし、ソルトします。

デフォルトでは、MSAD、RHDS、FreeIPAなどのLDAPサーバーは、パスワードをハッシュおよびソルトします。OpenLDAPやApacheDSなどの他のLDAPサーバーは、 RFC3062 で説明されている LDAPv3 Password Modify Extended Operation を使用しない限り、パスワードをプレーンテキストで保存します。LDAP設定ページでLDAPv3 Password Modify Extended Operationを有効にしてください。詳細は、LDAPサーバーのドキュメントを参照してください。

カテゴリー org.keycloak.storage.ldap のログレベルをTRACEに上げると便利です。 standalone(-ha).xml ファイルのロギング・サブシステムでこのレベルを上げます。この設定では、LDAPサーバーへのすべてのクエリーのログと、クエリーの送信に使用されたパラメーターを含む、多くのログメッセージが TRACE レベルで server.log ファイルに送信されます。ユーザー・フォーラムまたはJIRAでLDAPの質問を作成する場合は、TRACEログを有効にしてサーバーログを添付することを検討してください。大きすぎる場合は、問題が発生する操作の際にログに追加されたメッセージとサーバーログのスニペットだけを含めることをお勧めします。

LDAPプロバイダーの設定が表示されます。質問したりバグを報告したりする前に、このメッセージを含めてLDAPの設定を表示するとよいでしょう。最終的には、含めたくない設定の変更をいくつかのプレースホルダー値で自由に置き換えてください。 一例は bindDn=some-placeholder です。 connectionUrl についても、同様に自由に置き換えることができますが、少なくとも使用されたプロトコル ( ldap と ldaps ) を含めることは一般的に役立ちます。同様に、DEBUGレベルで次のようなメッセージとともに表示されるLDAPマッパーの設定の詳細を含めると便利です。

これらのメッセージは、DEBUGロギングが有効になっている場合にのみ表示されることに注意してください。

パフォーマンスまたは接続プーリングの問題を追跡するには、LDAPプロバイダーのプロパティー Connection Pool Debug Level の値を all に設定することを検討してください。これにより、サーバーログにLDAP接続プーリングのログが含む多くのメッセージが追加されます。これは、接続プーリングまたはパフォーマンスに関連する問題を追跡するために使用できます。

サーバーを再起動しても接続プールに関するメッセージが表示されない場合は、接続プールがLDAPサーバーで機能していないことを示している可能性があります。

LDAPの問題を報告する場合、LDAPツリーの一部をターゲット・データと一緒に添付することが考えられます。たとえば、あるユーザーのログインに時間がかかる場合、様々な"group"エントリーの member 属性の数を示す彼のLDAPエントリーを添付することを検討できます。この場合、これらのグループ・エントリーがKeycloakなどのグループLDAPマッパー（またはロールLDAPマッパー）にマップされているかどうかを追加すると便利でしょう。

FreeIPA Dockerイメージは、Docker Hubで公開されています。FreeIPAサーバーのセットアップは、 FreeIPAのドキュメント を参照してください。

フェデレーション・プロバイダーはD-BUSを用いてSSSDからデータを取得し、PAMを用いてデータを認証します。

KeycloakはDBus-Javaを使ってD-Busと低レベルで通信します。D-Bus は Unix Sockets Library に依存しています。

このライブラリーのRPMは、 Keycloakのリポジトリーで見つけることができます。このRPMをインストールする前に、このコマンドでRPMの署名を確認してください。

このコマンドでRPMをインストールします。

Keycloakは、JNAを使用してPAMで認証しています。JANパッケージがインストールされていることを確認してください。

設定を確認するには、 ssctl user-checks コマンドを使用します。

この機能を有効にするには、 Required Actions タブで設定します。

特定のユーザーにアカウントの削除を許可するロールを与えることができます。

delete-account ロールを取得すると、自分のアカウントを削除できるようになります。

すでにパスワードが設定されている場合は、 Reset Password の項目で再設定することができます。

または、ユーザーにOTPジェネレーターのリセットを要求するメールを送信することもできます。次の手順は、ユーザーがすでに OTP クレデンシャルを持っている場合にも適用されます。

どのユーザーに対しても必須アクションを設定できます。

すべての新規ユーザーの初回ログイン前に必要なアクションを指定することができます。この条件は、 Users ページの Add User ボタン、またはログインページの Register リンクで作成されたユーザーに適用されます。

新規ユーザーがKeycloakに初めてログインする前に、利用規約に同意しなければならないという必須アクションを有効にすることができます。

この設定を有効にすると、管理コンソールのログインページに Register リンクが表示されます。

declarative_user_profile 機能を有効にすることに加えて、レルムに対してユーザー・プロフィールを有効にする必要があります。これを行うには、左サイドメニューの Realm Settings リンクをクリックし、 User Profile Enabled スイッチをオンにします。

この機能を有効にし、 Save ボタンをクリックすると、 User Profile タブにアクセスすることができ、ここからユーザー属性の設定を管理できるようになります。

レルムのユーザー・プロフィールを有効にすることで、Keycloakはユーザー・プロフィールの構成に基づいて、属性を管理する方法について追加の制約を課そうとします。まとめると、この機能が有効になった際に期待されることは以下の通りです。

次のトピックでは、ユーザー・プロフィールの構成を管理する方法と、それがレルムにどのような影響を与えるかを探ります。

ユーザー・プロフィールの設定は、レルム単位で管理されます。そのためには、左サイドメニューの Realm Settings リンクをクリックし、User Profile タブをクリックします。

Attributes サブタブには、ユーザー・プロフィールに現在関連付けられている属性のリストが表示されます。デフォルトでは、ユーザーのルート属性に基づいて作成され、各属性はバリデーションとパーミッションの観点からいくつかのデフォルト設定がされています。

Attribute Groups のサブタブでは、属性グループを管理することができます。属性グループは、ユーザー向けフォームをレンダリングする際に、属性を関連付けて表示することができます。

JSON Editor サブタブでは、明確に定義されたJSONスキーマを使用して設定を表示および編集することができます。他のタブで行った変更は、このタブで表示されるJSON設定に反映されます。

次のセクションでは、 Attributes サブタブで設定を管理する方法を学びます。

Attributes サブタブでは、ユーザー・プロフィールに関連する属性の作成、編集、削除を行うことができます。

新しい属性を定義してユーザー・プロフィールと関連付けるには、属性一覧の右上にある Create ボタンをクリックします。

属性を設定する際に、以下の設定を定義することができます。

Attribute Groups サブタブでは、属性グループの作成、編集、削除を行うことができます。属性グループは、関連する属性のコンテナーを定義することができ、ユーザー向けフォームに表示される際に一緒に表示されます。

新しいグループを作成するには、属性グループ一覧の右上にある Create ボタンをクリックします。

グループを構成する際に、以下の設定を定義することができます。

ユーザー・プロフィールの設定は、明確に定義されたJSONスキーマを使用して保存されます。 JSON Editor サブタブをクリックすることで、ユーザー・プロフィールの設定を直接編集することができます。

JSONスキーマは以下のように定義されています。

スキーマは必要な数だけ属性をサポートします。

各属性には name と、オプションで required 、 permission 、 annotations の設定を定義する必要があります。

ユーザー・プロフィールの主な機能の1つは、属性のメタデータに基づいてユーザー向けのフォームを動的にレンダリングする可能性です。この機能をレルムで有効にすると、登録やプロフィールの更新などのフォームが特定のテーマ・テンプレートを使ってレンダリングされ、ユーザー・プロフィールの設定に基づいたページが動的にレンダリングされます。

ですから、デフォルトのレンダリング機構がニーズに合っていれば、テンプレートをカスタマイズする必要は全くありません。それでもなお、テーマのカスタマイズが必要な場合は、以下のテンプレートを参照してください。

デフォルトのレンダリング機構は、以下の機能を提供します。

ユーザーのプロフィールが設定に準拠していることを確認するために、管理者は VerifyProfile 必須アクションを使用して、最終的にKeycloakで認証する際にユーザーのプロフィールを強制的に更新させることができます。

VerifyProfile アクションを有効にすると、ユーザー認証の際に次のような処理を行います。

デフォルトでは、 VerifyProfile アクションは無効になっています。有効にするには、左サイドメニューの Authentication リンクをクリックし、Required Actions タブをクリックします。このタブで Register ボタンをクリックし、 VerifyProfile アクションを選択します。

レルムに対してユーザー・プロフィール機能を有効にする前に、注意すべき重要な点がいくつかあります。属性メタデータを管理するための単一の場所を提供することで、この機能はユーザーに設定できる属性とその管理方法について非常に厳格なものとなっています。

ユーザー管理に関しては、管理者はユーザー・プロフィールの構成で定義された属性のみを管理することができます。ユーザーに設定された他の属性で、まだユーザー・プロフィール構成で定義されていないものは、アクセスできません。ユーザーまたは管理者のいずれかに公開したい、すべてのユーザー属性を定義したユーザー・プロフィール構成に更新することをお勧めします。

ユーザー情報を照会するためにUser REST APIにアクセスする場合にも、同様の推奨事項が適用されます。

LDAP_ID 、 LDAP_ENTRY_DN 、 KERBEROS_PRINCIPAL などのKeycloak内部ユーザー属性に関して、これらの属性にアクセスしたい場合は、ユーザー・プロフィール構成に属性として設定する必要があります。推奨は、これらの属性を管理者のみ参照可能とし、管理コンソールでユーザー属性を管理する際や、User APIでユーザーを照会する際に参照できるようにすることです。

テーマに関して、従来のテンプレート（ユーザーのルート属性でハードコードされたもの）をカスタマイズしている場合、ユーザー向けのフォームをレンダリングする際に、そのカスタム・テンプレートは使われず、これらのフォームを動的にレンダリングする新しいテンプレートが使用されます。理想的には、テンプレートのカスタマイズを避け、新しいテンプレートが提供する動的にフォームをレンダリングする動作を維持するようにします。それでも不十分な場合は、テンプレートをカスタマイズするか、新しいテンプレートを強化するかどうかを検討しますので、ご意見をお聞かせください。

Logout all ボタンをクリックすると、レルム内のすべてのユーザーをログアウトすることができます。

Logout all ボタンをクリックすると、すべてのSSOクッキーが無効になり、アクティブなブラウザー・セッション内で認証を要求しているクライアントは再度ログインする必要があります。Keycloakは、OIDCクライアント・アダプターを使用して、ログアウト・イベントをクライアントに通知します。SAMLなどのクライアント・タイプは、バックチャネルのログアウト・リクエストを受信しません。

Sessions ページで、各クライアントをクリックすると、そのクライアントの Sessions タブに移動することができます。そこにある Show Sessions ボタンをクリックすると、どのユーザーがアプリケーションに参加しているかがわかります。

個々のユーザーの Sessions タブを開くと、そのユーザーのセッション情報を見ることもできます。

複合ロールは、同じ機能を提供するため、グループと似ています。両者の違いは概念的なものです。複合ロールは、一連のサービスおよびアプリケーションにパーミッション・モデルを適用します。アプリケーションとサービスを管理するには、複合ロールを使用します。

グループは、組織内のユーザーとそのロールの集合体にフォーカスします。ユーザーを管理するには、グループを使用します。

このスクリーン・ショットは、いくつかの default groups が既に存在していることを示しています。

OTPジェネレーターに使用できるKeycloakのアルゴリズムは、タイムベースとカウンターベースがあります。

タイムベースのワンタイムパスワード（TOTP）では、トークン生成器が現在の時刻と共有のシークレットをハッシュ化します。サーバーは、時間枠内のハッシュと提出された値を比較することで、OTPを検証します。TOTPは、短い時間枠の中で有効です。

カウンターベースのワンタイムパスワード（HOTP）では、Keycloak は現在時刻ではなく、共有カウンターを使用します。project_name}サーバーは、OTPログインが成功するたびにカウンターを増加させる。有効なOTPはログインに成功すると変化します。

TOTPは、HOTPのOTPが不定期に有効なのに対し、マッチング可能なOTPが短時間で有効なため、HOTPよりも安全性が高い。HOTPは、OTPの入力に時間制限がないため、TOTPよりもユーザーフレンドリーである。

HOTPは、サーバーがカウンターをインクリメントするたびに、データベースの更新を必要とします。この更新は、高負荷時に認証サーバーのパフォーマンスを低下させる。効率を上げるため、TOTPは使用したパスワードを記憶しないので、データベースの更新を行う必要はありません。欠点は、有効時間内にTOTPを再利用することが可能なことである。

Keycloakには、いくつかの組み込みフローがあります。これらのフローを変更することはできませんが、フローの要件を自分のニーズに合わせて変更することは可能です。

ドロップ・ダウンリストで、 browser を選択すると、Browser Flow画面が表示されます。

ドロップダウンリストのクエスチョン・マークのツールチップにカーソルを合わせると、フローの説明が表示されます。2つのセクションが存在します。

フローを設計する際には、重要な機能性とセキュリティーに関する考慮事項が適用されます。

フローを作成するには、以下を実行します。

新しいフローを作成する場合、まず次のオプションでトップレベルのフローを作成する必要があります。

Keycloakがフローを作成すると、Keycloakは Delete 、 Add execution 、 Add flow ボタンを表示します。

フローとサブフローの挙動は3つの要因で決まります。

リセットメールの送信からワンタイムパスワードの認証まで、さまざまなアクションを実行できます。実行を追加するには、 Add execution ボタンをクリックします。 Provider の横にあるクエスチョン・マークにカーソルを合わせると、実行の説明が表示されます。

自動エグゼキューション と 対話型エグゼキューション の2種類が存在します。 自動エグゼキューション は Cookie エグゼキューションと同様で、フロー内で自動的にアクションを実行します。 対話型エグゼキューション は、入力を得るためにフローを停止させます。実行が成功すると、ステータスが success に設定されます。フローが完了するには、ステータスが success である実行が少なくとも1つ必要です。

トップレベルのフローにサブフローを追加するには、 Add flow ボタンを使用します。 Add flow ボタンを押すと、 Create Execution Flow ページが表示されます。このページは、 Create Top Level Form ページと似ています。違いは、 Flow Type に generic （デフォルト）または form を指定できることです。 form 型は、組み込みの Registration フローと同様に、ユーザー用のフォームを生成するサブフローを構築します。サブフローの成功は、含まれるサブフローを含め、そのエグゼキューションのRequirementがどのように評価されるかに依存します。サブフローがどのように機能するかについての詳細な説明は、エグゼキューションのRequirementのセクションを参照してください。

フロー内のすべての要素には、 Actions メニューに Delete オプションがあります。このアクションは、フローからエレメントを削除します。実行には、実行を設定するための Config メニューオプションがあります。また、Add execution および Add flow メニューオプションを使用して、実行とサブフローを追加することも可能です。

エグゼキューションの順序は重要です。エグゼキューションやサブフローは、その名前の横にある上下のボタンで、フロー内で上下に移動させることができます。

フローの作成を説明するために、ここでは高度なブラウザー・ログイン・フローの作成について説明します。このフローの目的は、WebAuthnを使ったパスワードレスでのログインと、パスワードとOTPによる二要素認証のどちらかをユーザーが選択できるようにすることです。

この段階では、フォームにはユーザー名は必要ですが、パスワードは必要ありません。セキュリティー・リスクを回避するために、パスワード認証を有効にする必要があります。

最後に、バインディングを変更します。

ユーザー名を入力すると、次のような流れで動作します。

ユーザーがWebAuthnのパスワードレス・クレデンシャルを記録している場合、このクレデンシャルを使って直接ログインすることができます。これがパスワードレス・ログインです。 WebAuthn Passwordless のエグゼキューションと Password with OTP フローが Alternative に設定されているため、ユーザーは Password with OTP を選択することもできます。これらが Required に設定されている場合、ユーザーはWebAuthn、パスワード、OTPを入力する必要があります。

WebAuthnパスワードレス認証で Try another way リンクを選択した場合、ユーザーは Password と Security Key （WebAuthnパスワードレス）のどちらかを選択することができます。パスワードを選択した場合、ユーザーは割り当てられたワンタイムパスワードでログインを続ける必要があります。WebAuthnのクレデンシャルを持っていない場合、ユーザーはパスワードを入力し、次にOTPを入力する必要があります。ユーザーが OTP クレデンシャルを持っていない場合は、OTP を記録するように求められます。

Kerberosサーバーをセットアップする手順は、オペレーティング・システム（OS）とKerberosベンダーに依存します。Windows Active Directory、MIT Kerberos、およびお使いのOSのマニュアルを参照して、Kerberosサーバーのセットアップと設定を確認してください。

セットアップ時には、以下の手順で行ってください。

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

Keycloakが動作しているホストで、keytabファイル /tmp/http.keytab にアクセスできることを確認します。

マシンにKerberosクライアントをインストールします。

クライアントマシンはKerberosクライアントを持ち、上で説明したように krb5.conf を設定する必要があります。また、クライアント・マシンは、ブラウザーでSPNEGOログインサポートを有効にしなければなりません。Firefoxを使用している場合は、Kerberos用にFirefoxを設定するを参照してください。

.mydomain.org のURI は network.negotiate-auth.trusted-uris 設定オプションに含まれていなければなりません。

Windowsドメインでは、クライアント側で設定を調整する必要はありません。Internet ExplorerとEdgeは、すでにSPNEGO認証に参加することができます。

Kerberosはクレデンシャルの委譲をサポートします。アプリケーションは、Kerberosチケットにアクセスする必要があり、Kerberosでセキュリティー保護された他のサービスと対話するためにそれを再使用することができます。KeycloakサーバーはSPNEGOプロトコルを処理したため、OpenID ConnectトークンのクレームまたはSAMLアサーションの属性内で GSSクレデンシャルをアプリケーションに伝搬させる必要があります。Keycloak は、これをKeycloakサーバーからアプリケーションに送信します。このクレームをトークンまたはアサーションに挿入するには、各アプリケーションは組み込みのプロトコル・マッパーである gss delegation credential を有効にする必要があります。このマッパーは、アプリケーションのクライアント・ページの Mappers タブで利用可能です。 詳細はプロトコル・マッパー の章を参照してください。

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

このコードの例は、Keycloakのサンプル配布ファイルまたはデモ配布ファイルのダウンロードの examples/kerberos に存在します。また、サンプルのソースを ここで 直接確認することもできます。

Kerberosプロトコルにおいて、 realm はKerberosプリンシパルの集合です。これらのプリンシパルの定義はKerberosデータベースに存在し、それは通常LDAPサーバーです。

Kerberosプロトコルは、レルム間の信頼を可能にします。たとえば、2つのKerberosレルム、AとBが存在する場合、レルム間信頼はレルムAからのユーザがレルムBのリソースにアクセスすることを可能にします。レルムBはレルムAを信頼します。

Keycloakサーバーは、クロス・レルム・トラストをサポートしています。これを実装するには、以下を実行します。

たとえば、Kerberosのプリンシパル・ユーザーである john@A は、LDAPにおいて uid=john,ou=People,dc=example,dc=com といったLDAP DNで利用可能でなければなりません。レルムAとレルムBのユーザーを認証したい場合は、LDAPがレルムAとレルムBの両方のユーザーを見つけることができることを確認してください。

問題が発生した場合は、追加のログを有効にしてデバッグしてください。

サポートされている証明書のアイデンティティー・ソース

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

project_name} サーバーが直接 HTTP リクエストを受け取ると、WildFly サーブレットサブシステムは SSL ハンドシェイクを確立し、クライアント証明書を抽出します。appserver_name} は、サーブレット仕様で規定されているように、HTTPリクエストの javax.servlet.request.X509Certificate 属性にクライアント証明書を保存します。project_name} X509認証ツールは、この属性から証明書を検索することができます。

しかし、Keycloakサーバーがロードバランサーやリバース・プロキシーの背後でHTTPリクエストをリッスンしている場合、プロキシー・サーバーはクライアント証明書を抽出し、相互のSSL接続を確立することがあります。リバース・プロキシーは一般に、認証されたクライアント証明書を基礎となるリクエストのHTTPヘッダーにセットします。プロキシーはリクエストをバックエンドKeycloakサーバーに転送します。この場合、KeycloakはHTTPリクエストの属性ではなくHTTPヘッダーからX.509証明書チェーンを調べなければなりません。

Keycloakがリバース・プロキシーの背後にある場合、一般的には KEYCLOAK_HOME/standalone/configuration/standalone.xml で x509cert-lookup SPI の代替プロバイダーを設定する必要があります。HTTPヘッダー証明書を検索する default プロバイダーには、さらに2つの組み込みプロバイダー haproxy と apache が存在します。

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

WebAuthnオーセンティケーターを登録した後、ユーザーは以下の操作を行います。

WebAuthnオーセンティケーターを登録する際、KeycloakはWebAuthnオーセンティケーターが生成するAttestation文の信頼性を検証します。Keycloakは、このためにトラストアンカーの証明書を必要とします。Keycloakは Keycloak truststore を利用しているので、事前にこれらの証明書をインポートしておく必要があります。

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

Keycloakは二要素認証にWebAuthnを使っていますが、一要素認証にWebAuthnを使うこともできます。この場合、 passwordless のWebAuthn のクレデンシャルを持つユーザーは、パスワードなしでKeycloakを認証することができます。Keycloakは、ひとつのレルムとひとつの認証フローで、WebAuthnをパスワードなし認証と二要素認証の両方の仕組みとして使うことができます。

管理者は通常、WebAuthnパスワードレス認証のためにユーザーが登録したセキュリティー鍵が、異なる要件を満たすことを要求します。たとえば、セキュリティー鍵は、ユーザーがPINを使用してセキュリティー鍵に認証することを要求したり、セキュリティー鍵がより強力な認証局で認証することを要求したりすることがあります。

このため、Keycloakは管理者に個別の WebAuthn Passwordless Policy を設定することを許可しています。 WebAuthn Register Passwordless のアクションが必要で、 WebAuthn Passwordless Authenticator タイプのオーセンティケーターが別途必要です。

条件付きフローでリソースへのアクセスを許可または拒否できます。2つのオーセンティケーター Deny Access と Allow Access は、条件によってリソースへのアクセスを制御します。

これは、ロール role1 を持たないすべてのユーザーへのアクセスを拒否し、プロパティー deny-role1 で定義されたエラーメッセージを表示する方法の例です。この例には、 Condition - User Role および Deny Access のエグゼキューションが含まれます。

最後に、ログインテーマの messages_en.properties（英語の場合）でエラーメッセージを含むプロパティーを定義します。

Bitbucketでログインするには、以下の手順で行います。

Keycloak デフォルトでは、プロファイル・リクエストを graph.facebook.com/me?fields=id,name,email,first_name,last_name に送信します。レスポンスには、id、name、email、first_name、last_nameの各フィールドのみが含まれます。Facebookのプロフィールから追加のフィールドを取得するには、対応するスコープを追加して、 Additional user’s profile fields という設定オプションのフィールドにフィールド名を追加します。

Githubでログインするには、以下の手順で行います。