サーバー管理ガイド

ロケールセレクタープロバイダーは、利用可能な情報に関する最適なロケールを提案します。ただし、多くの場合は、ユーザーに不明です。このため、以前に認証されたユーザーのロケールは永続化されたクッキーに記憶されます。

ロケールを選択するには、以下の最初の項目を使用します。

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

ロケールを選択するロジックを変更する場合は、LocaleSelectorProvider を作成するオプションがあります。詳細は、サーバー開発者ガイド を参照してください。

Forgot password を有効にすると、パスワードを取得するか、OTP ジェネレーターを失う場合に、ログイン認証情報をリセットできます。

メールで送信されるテキストは設定可能です。詳細は、サーバー開発者ガイド を参照してください。

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

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

ブラウザーを閉じたログインユーザーはセッションを破棄し、そのユーザーは再度ログインする必要があります。ユーザーがログイン時に Remember Me チェックボックスをクリックした場合に、そのユーザーのログインセッションを開いたままにするように Red Hat build of Keycloak を設定できます。このアクションは、ログインクッキーをセッションのみのクッキーから永続クッキーに変換します。

レルムのログイン設定では、どの Authentication Context Class Reference (ACR) 値をどの Level of Authentication (LoA) マップするかを定義できます。ACR は任意の値にすることができますが、LoA は数値にする必要があります。acr 要求は、OIDC 要求で送信される claim または acr_values パラメーターで要求でき、アクセストークンおよび ID トークンにも含めることができます。マッピングされた番号は、認証フロー条件で使用されます。

特定のクライアントがレルムとは異なる値を使用する必要がある場合は、マッピングをクライアントレベルで指定することもできます。ただし、レルムマッピングを行うのがベストプラクティスです。

詳細は、Step-up Authentication と 公式の OIDC 仕様 を参照してください。

このワークフローでは、ユーザーは UPDATE_EMAIL アクションを使用して独自のメールアドレスを変更する必要があります。

アクションは、単一のメール入力フォームに関連付けられます。レルムの電子メール検証が無効な場合は、この動作により、検証なしに電子メールを更新できます。レルムで電子メールの検証が有効になっている場合は、アカウントメールを変更せずにアクションが新しいメールアドレスにメール更新アクショントークンを送信します。トリガーされるアクショントークンのみがメールの更新を完了します。

アプリケーションは UPDATE_EMAIL を AIA (Application Initiated Action) として利用することで、ユーザーをメール更新フォームに送信できます。

鍵を定期的にローテーションすることが推奨されます。既存のアクティブなキーよりも優先度の高い新しいキーを作成することから始めます。代わりに、同じ優先度で新しいキーを作成し、以前のキーをパッシブにすることができます。

新しいキーが使用可能になると、すべての新しいトークンと cookie はその新しいキーで署名されます。ユーザーがアプリケーションに対して認証されると、SSO Cookie が新しい署名で更新されます。OpenID Connect トークンを更新すると、新しいキーで新たなトークンが署名されます。最終的には、すべての Cookie とトークンは新しいキーを使用し、しばらくすると、古いキーを削除できます。

古いキーを削除する頻度は、セキュリティー間のトレードオフであり、すべてのクッキーとトークンが更新されるようにすることです。新しいキーの作成後に、3 カ月から 6 カ月までのすべてのキーを作成し、古いキーを 2 カ月に削除することを検討してください。新しいキーが追加され、古いキーが削除されるまでの期間にユーザーが非アクティブである場合、そのユーザーは再認証する必要があります。

鍵をローテーションすると、オフライントークンにも適用されます。これらのアプリケーションが古いキーが削除される前にトークンを更新する必要のあることを確認するには、アプリケーションを更新します。

この手順を使用して、自己署名付き証明書を含むキーペアを生成できます。

プロバイダーの優先度を変更すると、キーが再生成されますが、キーサイズを変更する場合はプロバイダーを編集し、新しいキーが生成されます。

RSA で生成されたキーペアから証明書を抽出し、その証明書を新しいキーストアで使用することにより、キーをローテーションできます。

別のユーザーが取得したキーペアと証明書を追加するには、Providers を選択し、ドロップダウンから rsa を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更できます。

ホストの Java Keystore ファイルに保存されているキーペアと証明書を追加するには、Provider を選択し、ドロップダウンから java-keystore を選択します。新たなキーペアがアクティブなキーペアになるように、優先度を変更できます。

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

Red Hat build of Keycloak は署名鍵をローカルにのみ保存し、それをクライアントアプリケーション、ユーザー、または他のエンティティーと共有することはありません。ただし、レルム署名鍵が侵害されたと思われる場合は、上記のとおり最初に新しいキーペアを生成し、侵害されたキーペアを即座に削除する必要があります。

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

not-before ポリシーをプッシュすると、クライアントアプリケーションは、セキュリティー侵害を受けたキーで署名された既存のトークンを受け入れないようにします。クライアントアプリケーションは Red Hat build of Keycloak から新しいキーペアをダウンロードするように強制されるため、侵害されたキーで署名されたトークンは無効になります。

Red Hat build of Keycloak は、LDAP からローカルの Red Hat build of Keycloak ユーザーデータベースにユーザーをインポートします。このユーザーデータベースのコピーは、オンデマンドまたは定期的なバックグラウンドタスクを介して同期します。パスワード同期の例外が存在します。Red Hat build of Keycloak がパスワードをインポートすることはありません。パスワードの検証は LDAP サーバーで常に行われます。

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

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

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

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

ユーザーと管理者はユーザーメタデータを変更できます。ユーザーは Account Console から、管理者は管理コンソールから変更できます。LDAP 設定ページの Edit Mode 設定により、ユーザーの LDAP 更新権限が定義されます。

LDAP ストアへの安全な接続 URL (たとえば、ldaps://myhost.com:636) を設定すると、Red Hat build of Keycloak は SSL を使用して LDAP サーバーと通信します。Red Hat build of Keycloak が LDAP への SSL 接続を信頼できるように、Red Hat build of Keycloak サーバー側でトラストストアを設定します。トラストストアの設定 の章を参照してください。

Use Truststore SPI 設定プロパティーの使用は非推奨です。通常は Always のままにしてください。

Import Users オプションを設定すると、LDAP プロバイダーが Red Hat build of Keycloak ローカルデータベースへの LDAP ユーザーのインポートを処理します。ユーザーが初めてログインするとき、またはユーザークエリーの一部として返されるとき (例: 管理コンソールの検索フィールドを使用する場合)、LDAP プロバイダーは LDAP ユーザーを Red Hat build of Keycloak データベースにインポートします。認証中に、LDAP パスワードが検証されます。

すべての LDAP ユーザーを Red Hat build of Keycloak データベースに同期する場合は、LDAP プロバイダー設定ページで Sync Settings を設定して有効にします。

2 種類の同期が存在します。

同期する最適な方法として、LDAP プロバイダーの初回作成時にすべてのユーザーの同期をクリックし、変更したユーザーの定期的な同期を設定するのが最適です。

LDAP マッパーは LDAP プロバイダーによってトリガーされる listeners です。別の拡張は LDAP 統合を指定します。LDAP マッパーは、以下の場合にトリガーされます。

LDAP フェデレーションプロバイダーを作成すると、Red Hat build of Keycloak がこのプロバイダーの mappers セットを自動的に提供します。これは、ユーザーはマッパーの開発や、既存マッパーの更新/削除を行えます。

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

Red Hat build of Keycloak は、パスワードを更新するとそのパスワードをプレーンテキスト形式で送信します。このアクションは、Red Hat build of Keycloak がデータベースに送信する前にパスワードをハッシュ化してソルト化する、Red Hat build of Keycloak のビルトインデータベースにおけるパスワード更新とは異なります。LDAP の場合、Red Hat build of Keycloak は LDAP サーバーに依存してパスワードのハッシュ化とソルト化を行います。

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

LDAP 接続の管理効率を高め、複数の接続を処理する際のパフォーマンスを向上させるために、接続プールを有効にできます。そうすることで、接続が閉じたときに、将来使用できるようにプールに戻されるため、常に新しい接続を作成するコストが削減されます。

LDAP 接続プールの設定は、次のシステムプロパティーを使用して設定します。

詳細は、Java LDAP Connection Pooling Configuration ドキュメントを参照してください。

これらのプロパティーを設定するには、JAVA_OPTS_APPEND 環境変数を設定します。

export JAVA_OPTS_APPEND=-Dcom.sun.jndi.ldap.connect.pool.initsize=10 -Dcom.sun.jndi.ldap.connect.pool.maxsize=50

export JAVA_OPTS_APPEND=-Dcom.sun.jndi.ldap.connect.pool.initsize=10 -Dcom.sun.jndi.ldap.connect.pool.maxsize=50

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

Creating new LDAP Store for the LDAP storage provider: ...

Creating new LDAP Store for the LDAP storage provider: ...

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

Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ...

Mapper for provider: XXX, Mapper name: YYY, Provider: ZZZ ...

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

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

FreeIPA コンテナーイメージ は Quay.io で入手できます。FreeIPA サーバーを設定するには、FreeIPA のドキュメント を参照してください。

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

Red Hat build of Keycloak は、DBus-Java プロジェクトを使用して D-Bus および JNA と低レベルで通信し、オペレーティングシステムのプラグ可能な認証モジュール (PAM) 経由で認証します。

現在、Red Hat build of Keycloak には SSSD プロバイダーの実行に必要なライブラリーがすべて含まれていますが、JDK バージョン 17 が必要です。そのため、ホスト設定が正しく、Red Hat build of Keycloak の実行に JDK 17 が使用されている場合に限り、SSSD プロバイダーが表示されます。

インストール後に、フェデレーションされた SSSD ストアを設定します。

これで、Red Hat build of Keycloak に対して、FreeIPA/IdM ユーザーと認証情報を使用して認証できるようになりました。

デフォルトで、Red Hat build of Keycloak は、最も一般的なユーザー属性の一部を含む基本的なユーザープロファイル設定を提供します。

Red Hat build of Keycloak の username 属性と email 属性は、ユーザーアカウントの識別、認証、リンクによく使用されるため、特別に扱われています。これらの属性は、設定の変更のみが可能であり、削除することはできません。

次のセクションで説明するように、独自の属性を追加したり、利用可能な属性の設定を変更したりして、ニーズに合わせてデフォルト設定を自由に変更できます。

Red Hat build of Keycloak では、ユーザーは以下のさまざまなコンテキストを通じて管理されます。

Administrative コンテキストを除く他のすべてのコンテキストは、ユーザーのセルフサービスフローに関連しているため、エンドユーザーコンテキストと見なされます。

これらのコンテキストを知ることは、ユーザーを管理するときにユーザープロファイル設定がどこで有効になるかを理解する上で重要です。ユーザーが管理されているコンテキストに関係なく、UI のレンダリングと属性値の検証には、同じユーザープロファイル設定が使用されます。

次のセクションで説明するように、特定の属性を管理コンテキストからのみ使用できるように制限し、エンドユーザーに対して完全に無効にすることができます。その逆も同様です。管理者に特定のユーザー属性へのアクセスを許可せず、エンドユーザーのみにアクセスを許可する場合は、それを行うことができます。

デフォルトでは、Red Hat build of Keycloak は、ユーザープロファイル設定で定義された属性のみを認識します。そこで明示的に定義されていない他の属性は無視されます。

Red Hat build of Keycloak は、ユーザーに設定できるユーザー属性とその値の検証方法を厳密に規定することで、レルムに別の防御バリアを追加し、ユーザーに予期しない属性や値が関連付けられるのを防止できます。

そのため、ユーザー属性は次のように分類できます。

管理対象外の属性はデフォルトでは無効になっていますが、さまざまなポリシーを使用してレルムを設定することで、サーバーによる管理対象外の属性の処理方法を定義できます。これを行うには、左側のメニューで Realm Settings をクリックし、General タブをクリックして、Unmanaged Attributes 設定から次のいずれかのオプションを選択します。

これらのポリシーを使用すると、サーバーが管理対象外の属性を処理する方法をきめ細かく制御できます。管理コンテキストからユーザーを管理するときに、管理対象外の属性を完全に無効にするか、管理対象外の属性のみをサポートするかを選択できます。

管理対象外の属性が (部分的にでも) 有効になっている場合、User Details UI の Attributes タブにある管理コンソールから属性を管理できます。ポリシーが Disabled に設定されている場合、このタブは使用できません。

セキュリティー上の推奨事項として、エンドユーザーコンテキストからユーザーがプロファイルを管理するときに予期しない属性 (および値) が設定されないように、可能な限り最も厳格なポリシー (例: Disabled または Admin can edit) に準拠するようにしてください。Enabled ポリシーの設定は避け、エンドユーザーが管理できるすべての属性をユーザープロファイル設定で管理できるように定義することを推奨します。

次のセクションで説明するように、ユーザーや管理者が属性を表示または書き込みできるようにするかどうかを選択することで、属性の対象者を制限することもできます。

管理対象外の属性の場合、最大長は 2048 文字です。異なる最小長または最大長を指定するには、管理対象外の属性を管理対象の属性に変更し、length バリデーターを追加します。

ユーザープロファイル設定は、レルムごとに管理されます。これには、左側のメニューで Realm Settings リンクをクリックし、User Profile タブをクリックします。

Attributes サブタブには、すべての管理対象属性のリストが表示されます。

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

JSON Editor サブタブでは、JSON 設定を表示および編集できます。このタブを使用して、現在の設定を取得したり、手動で管理したりできます。このタブに加えた変更は他のタブに反映されます。その逆も同様です。

次のセクションでは、属性を管理する方法を説明します。

Attributes サブタブでは、管理対象の属性を作成、編集、削除できます。

新しい属性を定義してユーザープロファイルに関連付けるには、属性リストの上部にある Create attribute ボタンをクリックします。

属性の設定時に、以下の設定を定義できます。

属性を作成すると、属性が予期せずエンドユーザーに公開されるのを避けるために、その属性は管理コンテキストからのみ使用可能になります。実際、エンドユーザーがエンドユーザーコンテキストからプロファイルを管理しているときに、その属性にアクセスすることはできません。Permissions 設定は、必要に応じていつでも変更できます。

管理対象の属性に対する検証を有効にして、属性値が特定のルールに準拠していることを確認できます。そのためには、属性を管理するときに、Validations 設定からバリデーターを追加または削除できます。

検証は、属性への書き込み時に随時実行されます。値が検証に失敗したときに、エラーを出力して UI に表示できます。

セキュリティー上の理由から、ユーザーが編集可能なすべての属性に、ユーザーが入力する値のサイズを制限する検証を指定する必要があります。length バリデーターが指定されていない場合、Red Hat build of Keycloak ではデフォルトで最大長が 2048 文字に設定されます。

フロントエンドに追加情報を渡すには、属性をレンダリングする方法を決定するアノテーションで属性を切り分けることができます。この機能は主に、Red Hat build of Keycloak テーマを拡張して、属性に関連付けられたアノテーションに基づきページを動的にレンダリングする場合に役立ちます。

アノテーションは、たとえば、次のセクションで説明するように、属性の HTML type を変更 したり、属性の DOM 表現を変更 したりするために使用されます。

アノテーションは、キーと値のペアであり、属性に対応する HTML 要素のレンダリング方法を変更できるように UI と共有されます。レルムで使用されているテーマによってアノテーションがサポートされている限り、任意のアノテーションを属性に設定できます。

"attributes": [
<...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select",
    "inputOptionLabels": {
      "sweng": "Software Engineer",
      "swarch": "Software Architect"
    }
  }
}
...
]

"attributes": [
<...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select",
    "inputOptionLabels": {
      "sweng": "Software Engineer",
      "swarch": "Software Architect"
    }
  }
}
...
]

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select-radiobuttons",
    "inputOptionLabels": {
      "sweng": "${jobtitle.swengineer}",
      "swarch": "${jobtitle.swarchitect}"
    }
  }
}
...
]

"attributes": [
...
{
  "name": "jobTitle",
  "validations": {
    "options": {
      "options":[
        "sweng",
        "swarch"
      ]
    }
  },
  "annotations": {
    "inputType": "select-radiobuttons",
    "inputOptionLabels": {
      "sweng": "${jobtitle.swengineer}",
      "swarch": "${jobtitle.swarchitect}"
    }
  }
}
...
]

import { registerElementAnnotatedBy } from "./userProfile.js";

registerElementAnnotatedBy({
  name: 'kcMyCustomValidation',
  onAdd(element) {
    var listener = function (event) {
        // do something on keyup
    };

    element.addEventListener("keyup", listener);

    // returns a cleanup function to remove the event listener
    return () => element.removeEventListener("keyup", listener);
  }
});

import { registerElementAnnotatedBy } from "./userProfile.js";

registerElementAnnotatedBy({
  name: 'kcMyCustomValidation',
  onAdd(element) {
    var listener = function (event) {
        // do something on keyup
    };

    element.addEventListener("keyup", listener);

    // returns a cleanup function to remove the event listener
    return () => element.removeEventListener("keyup", listener);
  }
});

document.querySelectorAll(`[data-kcMyCustomValidation]`).forEach((element) => {
    var listener = function (evt) {
        // do something on keyup
    };

    element.addEventListener("keyup", listener);
  });

document.querySelectorAll(`[data-kcMyCustomValidation]`).forEach((element) => {
    var listener = function (evt) {
        // do something on keyup
    };

    element.addEventListener("keyup", listener);
  });

属性グループ サブタブで、属性グループを作成、編集、および削除できます。属性グループを使用すると、相関属性のコンテナーを定義でき、ユーザーに表示されるフォームで一緒にレンダリングできます。

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

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

ユーザープロファイル設定は、明確に定義された JSON スキーマを使用して保存されます。JSON Editor サブタブで直接ユーザープロファイル設定の編集を選択できます。

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

{
  "unmanagedAttributePolicy": "DISABLED",
  "attributes": [
    {
      "name": "myattribute",
      "multivalued": false,
      "displayName": "My Attribute",
      "group": "personalInfo",
      "required": {
        "roles": [ "user", "admin" ],
        "scopes": [ "foo", "bar" ]
      },
      "permissions": {
        "view": [ "admin", "user" ],
        "edit": [ "admin", "user" ]
      },
      "validations": {
        "email": {
          "max-local-length": 64
        },
        "length": {
          "max": 255
        }
      },
      "annotations": {
        "myannotation": "myannotation-value"
      }
    }
  ],
  "groups": [
    {
      "name": "personalInfo",
      "displayHeader": "Personal Information",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
    }
  ]
}

{
  "unmanagedAttributePolicy": "DISABLED",
  "attributes": [
    {
      "name": "myattribute",
      "multivalued": false,
      "displayName": "My Attribute",
      "group": "personalInfo",
      "required": {
        "roles": [ "user", "admin" ],
        "scopes": [ "foo", "bar" ]
      },
      "permissions": {
        "view": [ "admin", "user" ],
        "edit": [ "admin", "user" ]
      },
      "validations": {
        "email": {
          "max-local-length": 64
        },
        "length": {
          "max": 255
        }
      },
      "annotations": {
        "myannotation": "myannotation-value"
      }
    }
  ],
  "groups": [
    {
      "name": "personalInfo",
      "displayHeader": "Personal Information",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
    }
  ]
}

このスキーマでは、属性とグループを必要な数だけ使用できます。

unmanagedAttributePolicy プロパティーは、次のいずれかの値を設定して、管理対象外の属性のポリシーを定義します。詳細は、管理対象の属性と管理対象外の属性について を参照してください。

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {}
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {}
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "scopes": ["foo"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "scopes": ["foo"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "permissions": {
        "view": ["admin"],
        "edit": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "permissions": {
        "view": ["admin"],
        "edit": ["user"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
  ]
}

{
  "attributes": [
    {
      "name": "myattribute",
      "annotations": {
        "foo": ["foo-value"],
        "bar": ["bar-value"]
      }
  ]
}

ユーザープロファイルコンテキスト (管理コンソールを含む) の UI は、すべてユーザープロファイル設定に応じて動的にレンダリングされます。

デフォルトのレンダリングメカニズムは、次の機能を提供します。

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

有効にすると、ユーザー認証時に VerifyProfile アクションは以下の手順を実行します。

VerifyProfile アクションはデフォルトで有効になっています。無効にするには、左側のメニューの Authentication リンクをクリックし、Required タブをクリックします。このタブで、VerifyProfile アクションの Enabled スイッチを使用して無効にします。

属性、属性グループ、アノテーションを設定するときに国際化されたメッセージを使用する場合は、メッセージバンドルのメッセージに変換するプレースホルダーを使用して、表示名、説明、値を設定できます。

そのためには、プレースホルダーを使用して、${myAttributeName} などのメッセージキーを解決します。myAttributeName は、メッセージバンドル内のメッセージのキーです。詳細は、サーバー開発者ガイド を参照し、カスタムテーマにメッセージバンドルを追加する方法を確認してください。

ユーザーにパスワードがない場合や、パスワードが削除された場合、パスワードの設定 セクションが表示されます。

ユーザーのパスワードがすでにある場合は、Reset Password セクションでリセットできます。

ユーザーに、パスワードをリセットするように要求することもできます。

OTP がレルムの条件である場合、ユーザーは Red Hat build of Keycloak アカウントコンソールに移動し、新しい OTP ジェネレーターを再設定する必要があります。OTP が必要な場合は、ログイン時に新しい OTP ジェネレーターを再設定する必要があります。

この代わりに、ユーザーが OTP ジェネレーターをリセットするユーザーへメールを送信することもできます。以下の手順では、ユーザーが OTP 認証情報をすでに持っているかどうかも適用されます。

ユーザーが自己登録できるようにします。

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

新しいユーザーとして、初回ログインするには、登録フォームを完了する必要があります。プロファイル情報と、登録するパスワードを追加します。

ユーザーの登録時に、利用規約への同意を要求できます。

任意のユーザーに必要なアクションを設定できます。

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

新規ユーザーが Red Hat build of Keycloak に初めてログインする前に、利用規約に同意する必須アクションを有効にできます。

アクティブな SSO セッションによりユーザーがすでに認証されている場合、通常、そのユーザーはアクティブに再認証する必要はありません。ただし、そのユーザーが 5 分以上前にアクティブに認証されている場合、クライアントは AIA が要求されたときに再認証を要求できます。このガイドラインには次のような例外があります。

一部の AIA では、アクション名とともにパラメーターを送信することが必要になる場合があります。たとえば、Delete Credential アクションは AIA によってのみトリガーでき、削除された認証情報の ID を指すパラメーターをアクション名とともに送信する必要があります。したがって、この例の URL は kc_action=delete_credential:ce1008ac-f811-427f-825a-c0b878d1c24b になります。この場合、コロン文字の後の部分には (ce1008ac-f811-427f-825a-c0b878d1c24b) には、削除する特定のユーザーの認証情報の ID が含まれます。Delete Credential アクションでは、ユーザーが認証情報の削除に同意するかどうかを確認できる確認画面が表示されます。

利用可能なすべてのアクションを表示するには、管理コンソールにログインし、右上隅にある Realm info → Provider info タブ→プロバイダーの required-action 検索をクリックします。ただし、Required actions タブでレルムに対して有効になっているアクションに基づいて、これがさらに制限される可能性があることに注意してください。

この機能により、Required Actionsタブでこの機能を有効にします。

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

delete-account ロールを取得したら、独自のアカウントを削除できます。

レルム内のすべてのユーザーをサインアウトできます。Action リストから、Sign out all active sessions を選択します。すべての SSO Cookie が無効になります。Red Hat build of Keycloak は、Red Hat build of Keycloak OIDC クライアントアダプターを使用してクライアントにログアウトイベントを通知します。アクティブなブラウザーセッション内で認証を要求するクライアントは、再度ログインする必要があります。SAML などのクライアントタイプは、バックチャネルログアウト要求を受信しません。

グループとロールには、いくつかの類似点と違いがあります。Red Hat build of Keycloak では、グループはロールと属性を適用するユーザーのコレクションです。ロールは、ユーザーとアプリケーションのタイプを定義し、パーミッションをロールに割り当てます。

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

グループは、組織におけるユーザーとロールのコレクションに重点を置きます。グループを使用してユーザーを管理します。

Identity Brokering を介して作成またはインポートされたユーザーにグループメンバーシップを自動的に割り当てるには、デフォルトのグループを使用します。

このスクリーンショットは、一部の デフォルトグループ がすでに存在していることを示しています。

Red Hat build of Keycloak では、OTP ジェネレーター用に時間ベースとカウンターベースのアルゴリズムを使用できます。

タイムベースのワンタイムパスワード (TOTP) を使用すると、トークンジェネレーターは現在の時刻と共有秘密をハッシュ化します。サーバーは、ウィンドウ内のハッシュを送信した値と比較することにより、OTP を検証します。TOTP は短時間に有効です。

カウンターベースのワンタイムパスワード (HOTP) を使用すると、Red Hat build of Keycloak は現在の時刻ではなく共有カウンターを使用します。Red Hat build of Keycloak サーバーは、OTP ログインが成功するたびにカウンターをインクリメントします。ログインに成功した後、有効な OTP が変更されます。

一致可能な OTP は短時間で有効になり、OTP for HOTP は終了期間に有効であるため、TOTP は HOTP よりも安全です。OTP に入るのに時間制限が存在しないため、HOTP は TOTP よりも使いやすいことです。

HOTP では、サーバーがカウンターをインクリメントするたびにデータベースの更新が必要になります。この更新は、負荷が大きい間認証サーバーでのパフォーマンスドレイン (解放) です。TOTP は、効率性を向上させるために、使用するパスワードを記憶しないため、データベースの更新を行う必要はありません。欠点は、有効な期間で TOTP を再使用できることです。

Red Hat build of Keycloak には、いくつかのビルトインフローがあります。これらのフローは変更できませんが、フローの要件をニーズに合わせて変更することができます。

フローの設計時に、重要な機能およびセキュリティー上の考慮事項が適用されます。

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

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

Red Hat build of Keycloak がフローを作成すると、Red Hat build of Keycloak に Add step ボタンと Add sub-flow ボタンが表示されます。

3 つの要因により、フローとサブフローの動作が決定されます。

リセットメールの送信から OTP の検証まで、実行にはさまざまなアクションを設定できます。Add step ボタンを使用して実行を追加します。

認証実行では、必要に応じて参照値を設定できます。これは、Authentication Method Reference (AMR) プロトコルマッパーで利用して、OIDC アクセストークンと ID トークンに amr クレームを入力するために使用できます (AMR クレームの詳細は、RFC-8176 を参照してください)。Authentication Method Reference (AMR) プロトコルマッパーがクライアント用に設定されている場合、認証フロー中にユーザーが正常に完了したオーセンティケーター実行の参照値が amr クレームに入力されます。

自動実行とインタラクティブな実行の 2 種類の実行があります。自動実行 は Cookie 実行に類似し、フローのアクションを自動的に実行します。インタラクティブな実行は、入力を取得するためにフローを停止します。正常に実行されると、ステータスを success に設定します。フローが完了するには、ステータスが success の実行が少なくとも 1 つ必要です。

Add sub-flow ボタンを使用して、サブフローを最上位のフローに追加できます。Add sub-flow ボタンをクリックすると、Create Execution Flow ページが表示されます。このページは Create Top Level Form ページに似ています。違いは、Flow Type に basic (デフォルト) と form がある点です。form タイプは、ビルトイン Registration フローに似た、ユーザーのフォームを生成するサブフローを構築します。サブフローが成功するかどうかは、含まれるサブフローを含め、実行がどのように評価されるかによります。サブフローがどのように機能するかの詳細な説明は、実行要件 セクションを参照してください。

フロー内のすべての要素には、要素の横に Delete オプションがあります。一部の実行には、実行を設定するための ⚙️ メニュー項目 (歯車アイコン) があります。Add step および Add sub-flow リンクで、サブフローに実行とサブフローに追加することもできます。

実行の順序は重要であるため、名前をドラッグして実行とサブフローを上下に移動できます。

フローの作成を説明するために、このセクションでは高度なブラウザーログインフローの作成を説明します。このフローの目的は、ユーザーが、WebAuthn によるパスワードなしの方法でのログインと、パスワードと OTP を使用した二要素認証を選択できるようにすることです。

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

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

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

ユーザーの WebAuthn パスワードレス認証情報が記録されている場合は、これらの認証情報を使用して直接ログインできます。これはパスワードなしのログインです。WebAuthn Passwordless 実行および Password with OTP フローが Alternative に設定されているため、ユーザーは Password with OTP を選択することもできます。Required に設定されている場合は、ユーザーは WebAuthn、パスワード、および OTP を入力する必要があります。

ユーザーが WebAuthn passwordless 認証で Try another way リンクを選択した場合、ユーザーは Password と Passkey (WebAuthn passwordless) のどちらかを選択できます。パスワードを選択すると、ユーザーは続行して、割り当てられた OTP でログインする必要があります。ユーザーに WebAuthn 認証情報がない場合は、ユーザーはパスワードを入力し、続いて OTP を入力する必要があります。ユーザーに OTP 認証情報がない場合は、記録することが要求されます。

このセクションでは、ステップアップメカニズムを使用して高度なブラウザーログインフローを作成する方法を説明します。ステップ認証の目的は、ユーザーの特定の認証レベルに基づいてクライアントまたはリソースへのアクセスを許可することです。

最初の認証レベルのフローを設定します。

これで、2 つ目の認証レベルのフローが設定されます。

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

https://{DOMAIN}/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

https://{DOMAIN}/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

claims パラメーターは JSON 表現で指定されます。

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

Red Hat build of Keycloak の JavaScript アダプターは、この JSON を簡単に構築し、ログイン要求で送信できるようにサポートします。詳細は、JavaScript アダプターのドキュメント を参照してください。

また、claims パラメーターの代わりに単純なパラメーター acr_values を使用して、特定のレベルを必須ではないものとして要求することもできます。これは OIDC 仕様で説明されています。

特定のクライアントのデフォルトレベルを設定することもできます。これは、acr_values パラメーターまたは acr 要求のある claims パラメーター要求が存在しない場合に使用されます。詳細は、クライアント ACR 設定 を参照してください。

詳細は、公式の OIDC 仕様 を参照してください。

フローロジック

以前に設定された認証フローのロジックは次のとおりです。
クライアントが高い認証レベル、つまり認証レベル 2 (LoA 2) を要求した場合、ユーザーは完全な 2 要素認証 (ユーザー名/パスワード + OTP) を実行する必要があります。ただし、ユーザーがすでに Red Hat build of Keycloak でセッションを持っていて、ユーザー名とパスワード (LoA 1) を使用してログインしている場合、ユーザーには 2 番目の認証要素 (OTP) のみが求められます。

条件の Max Age 時間オプションは、後続の認証レベルが有効である期間 (秒数) を決定します。この設定は、ユーザーが後続の認証中に認証要素を再度提示するように求められるかどうかを決定するのに役立ちます。特定のレベル X が claims または acr_values パラメーターによって要求され、ユーザーがすでにレベル X で認証されているが、有効期限が切れている場合 (たとえば、最大年齢が 300 に設定され、ユーザーが 310 秒前に認証された場合)、ユーザーは再認証を求められます。特定のレベルで再度認証します。ただし、レベルが期限切れでない場合、ユーザーは自動的にそのレベルで認証されていると見なされます。

Max Age を値 0 で使用すると、その特定のレベルはこの単一認証でのみ有効です。そのため、そのレベルを要求するすべての再認証では、そのレベルで再度認証する必要があります。これは、アプリケーションでより高いセキュリティーを必要とし (支払いの送信など)、常に特定のレベルでの認証を必要とする操作に役立ちます。

パラメーターによって明示的なレベルが要求されていない場合、Red Hat build of Keycloak では、前の例のユーザー名/パスワードなど、認証フローで最初に見つかった LoA 条件での認証が必要になります。ユーザーがそのレベルですでに認証され、そのレベルの有効期限が切れると、ユーザーは再認証する必要はありませんが、トークンの acr の値は 0 になります。この結果は、OIDC Core 1.0 仕様のセクション 2 で説明されているように、long-lived browser cookie のみに基づく認証と見なされます。

シナリオ例

トークンの ACR クレーム

ACR 要求は、acr クライアントスコープで定義された acr loa level のプロトコルマッパーによってトークンに追加されます。このクライアントスコープはレルムのデフォルトのクライアントスコープであるため、レルム内に新しく作成されたすべてのクライアントに追加されます。

トークン内で acr クレームが必要ない場合、またはトークンを追加するためのカスタムロジックが必要な場合は、クライアントからクライアントスコープを削除できます。

ログイン要求が acr を essential クレームとして要求する claims パラメーターを使用して要求を開始すると、Red Hat build of Keycloak は常に指定されたレベルの 1 つを返すことに注意してください。指定されたレベルの 1 つを返すことができない場合 (たとえば、要求されたレベルが不明であるか、認証フローで設定された条件よりも大きい場合)、Red Hat build of Keycloak はエラーを出力します。

通常、ユーザーがクライアントアプリケーションから Red Hat build of Keycloak にリダイレクトされると、browser フローがトリガーされます。このフローでは、レルム登録が有効になっていて、ユーザーがログイン画面で Register をクリックした場合に、ユーザーが 登録 できるようになります。また、レルムに対して Forget password が有効になっている場合、ユーザーはログイン画面で Forget password をクリックすることができ、これにより Reset credentials フローがトリガーとなり、ユーザーはメールアドレスの確認後に認証情報をリセットできます。

クライアントアプリケーションがユーザーを Registration 画面または Reset credentials フローに直接リダイレクトすると便利な場合があります。結果のアクションは、ユーザーが通常のログイン画面で Register または Forget password をクリックしたときのアクションと一致します。登録画面または認証情報のリセット画面への自動リダイレクトは、次のように実行できます。

Kerberos サーバーを設定する手順は、オペレーティングシステム (OS) および Kerberos ベンダーによって異なります。Kerberos サーバーのセットアップおよび設定方法は、Windows Active Directory、MIT Kerberos、および OS のドキュメントを参照してください。

セットアップ時に、以下の手順を実行します。

sudo kadmin.local

sudo kadmin.local

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

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

Red Hat build of Keycloak が実行されているホスト上で、keytab ファイル /tmp/http.keytab にアクセスできることを確認します。

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

クライアントマシンには Kerberos クライアントが必要であり、上記 のように、krb5.conf を設定する必要があります。クライアントマシンは、ブラウザーの SPNEGO ログインサポートも有効にする必要があります。Firefox ブラウザーを使用している場合は、configuring Firefox for Kerberos を参照してください。

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

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

Kerberos は認証情報の委譲をサポートします。アプリケーションは Kerberos チケットを再利用して Kerberos でセキュリティーが保護された他のサービスと対話できるように、チケットへのアクセスが必要になる場合があります。Red Hat build of Keycloak サーバーが SPNEGO プロトコルを処理するため、OpenID Connect トークン要求または SAML アサーション属性内のアプリケーションに GSS 認証情報を反映させる必要があります。Red Hat build of Keycloak はこれを Red Hat build of Keycloak サーバーからアプリケーションに送信します。この要求をトークンまたはアサーションに挿入するには、各アプリケーションはビルトインプロトコルマッパー gss delegation credential を有効にする必要があります。このマッパーは、アプリケーションのクライアントページの Mappers タブで利用できます。詳細は、プロトコルマッパー の章を参照してください。

アプリケーションは、Red Hat build of Keycloak から受信する要求を使用して他のサービスに対して GSS 呼び出しを行う前に、その要求をデシリアライズする必要があります。アクセストークンから GSSCredential オブジェクトに認証情報をデシリアライズする場合は、GSSManager.createContext メソッドに渡されるこのクレデンシャルで GSSContext を作成します。以下に例を示します。

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve Kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other Kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve Kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other Kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);

Kerberos プロトコルでは、レルム は Kerberos プリンシパルのセットです。これらのプリンシパルの定義は Kerberos データベース (通常は LDAP サーバー) に存在します。

Kerberos プロトコルは、レルム間の信頼を許可します。たとえば、2 つの Kerberos レルム A および B が存在する場合は、レルム間の信頼により、レルム A のユーザーがレルム B のリソースにアクセスできるようになります。レルム B がレルム A を信頼します。

Red Hat build of Keycloak サーバーは、レルム間の信頼をサポートします。これを実装するには、以下を実行します。

ユーザーの検索は、LDAP ストレージプロバイダーオプションの Kerberos principal attribute に基づきます。これがたとえば userPrincipalName などの値で設定されている場合、ユーザー john@A の SPNEGO 認証後、Red Hat build of Keycloak は john@A と同等の userPrincipalName 属性を持つ LDAP ユーザーを検索しようとします。Kerberos principal attribute が空のままの場合、Red Hat build of Keycloak は、レルムを省略した Kerberos プリンシパルの接頭辞に基づき LDAP ユーザーを検索します。たとえば、Kerberos プリンシパルユーザーの john@A は、LDAP 内 (通常は uid=john,ou=People,dc=example,dc=com などの LDAP DN 配下) でユーザー名 john として使用できる必要があります。レルム A および B からのユーザーを認証する場合は、LDAP がレルム A と B 両方からのユーザーを見つけられるようにします。

すべてのユーザーは、認証に使用される Kerberos プリンシパルを参照する KERBEROS_PRINCIPAL 属性を持ち、これを使用してさらにユーザーを検索するため、複数の Kerberos レルムからのユーザーの認証が許可されています。Kerberos レルム A と B の両方に john というユーザーが存在する場合、競合を回避するために Red Hat build of Keycloak ユーザーのユーザー名には Kerberos レルムが小文字で含まれる場合があります。たとえば、ユーザー名は john@a になります。設定された Kerberos realm とレルムが一致する場合に備えて、生成されたユーザー名からレルムの接尾辞が省略される場合があります。たとえば、Kerberos プロバイダーで設定された Kerberos realm が A である限り、Kerberos プリンシパル john@A のインスタンスユーザー名は john になります。

問題がある場合は、追加のロギングを有効にして問題をデバッグしてください。

サポートされる証明書アイデンティティーソース:

emailAddress=(.*?)(?:,|$)

emailAddress=(.*?)(?:,|$)

2FA の WebAuthn サポートの設定手順は、以下のようになります。

全ユーザーの WebAuthn が必要な場合は、以下を実行します。

WebAuthn 認証情報が登録されている場合に限り、ユーザーは WebAuthn でログインできます。そのため、WebAuthn Authenticator 実行を追加する代わりに、以下を実行できます。

ユーザーは、2 つ目の要素に WebAuthn または OTP のいずれかを使用することを選択できます。

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

WebAuthn オーセンティケーターを登録すると、Red Hat build of Keycloak は、WebAuthn オーセンティケーターが生成した証明ステートメントの信頼性を検証します。Red Hat build of Keycloak では、トラストストア にトラストアンカーの証明書をインポートする必要があります。

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

Red Hat build of Keycloak は、2 要素認証に WebAuthn を使用しますが、第一要素認証として WebAuthn を使用できます。この場合、passwordless の WebAuthn 認証情報を持つユーザーは、パスワードなしで Red Hat build of Keycloak に対して認証できます。Red Hat build of Keycloak では、レルムおよび単一の認証フローのコンテキストで、パスワードレス認証および 2 要素認証のメカニズムとして WebAuthn を使用できます。

通常、管理者は、WebAuthn パスワードレス認証用にユーザーが登録したパスキーがさまざまな要件を満たしていることを要求します。たとえば、ユーザーが PIN を使用してパスキーに対して認証することを要求したり、より強力な認証局でパスキーを証明するように要求する場合があります。

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

Red Hat build of Keycloak は、2 要素認証に WebAuthn を使用しますが、第一要素認証として WebAuthn を使用できます。この場合、passwordless の WebAuthn 認証情報を持つユーザーは、ログインやパスワードなしで Red Hat build of Keycloak に対して認証できます。Red Hat build of Keycloak は、レルムのコンテキストで、ログインレス/パスワードレスおよび 2 要素認証メカニズムとして WebAuthn を使用できます。

通常、管理者は、WebAuthn ログインレス認証用にユーザーが登録したパスキーがさまざまな要件を満たしていることを要求とします。ログインレス認証では、ユーザーがパスキーに対して (PIN コードや指紋などを使用して) 認証する必要があり、ログインレス認証情報に関連付けられた暗号化キーをパスキーに物理的に保存する必要があります。すべてのパスキーがそのような要件を満たしているわけではありません。ベンダーに問い合わせて、デバイスが 'ユーザー検証' と '検出可能な認証情報' をサポートしているかどうかを確認してください。サポートされているパスキー を参照してください。

Red Hat build of Keycloak により、管理者はログインレス認証を可能にするように WebAuthn Passwordless Policy を設定できます。ログインレス認証は、WebAuthn Passwordless Policy と WebAuthn Passwordless クレデンシャルでのみ設定できることに注意してください。WebAuthn ログインレス認証と WebAuthn パスワードレス認証は同じレルムで設定できますが、同じポリシー WebAuthn Passwordless Policy ポリシーを共有します。

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

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

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

deny-role1 = You do not have required role!

deny-role1 = You do not have required role!

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

デフォルトでは、Red Hat build of 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 でログインするには、以下の手順を実行します。