サーバー管理ガイド

すべての UI 画面は、Red Hat Single Sign-On で国際化されています。デフォルトの言語は英語ですが、使用するロケールや、デフォルトのロケールを選択できます。

ユーザーが次回ログインすると、そのユーザーはログインページの言語を選択して、ログイン画面、Account Console、および Admin Console に使用できます。

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

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

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

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

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

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

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

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

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

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

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

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

詳細については、ステップアップ認証 と 公式の OIDC 仕様 を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Truststore SPI を使用して Red Hat Single Sign-On のグローバルトラストストアを設定します。グローバルトラストストアの設定の詳細については、サーバーのインストールおよび設定ガイド を参照してください。Truststore SPI を設定しないと、トラストストアは Java によって提供されるデフォルトのメカニズムにフォールバックします。これは、システムプロパティーが設定されていないと、javax.net.ssl. ONLY システムプロパティーまたは JDK からの cacerts ファイルによって提供されるファイルになります。

LDAP フェデレーションプロバイダー設定の Use Truststore SPI 設定プロパティーは、トラストストア SPI を制御します。デフォルトでは、Red Hat Single Sign-On はプロパティーを Only for ldaps に設定します。これは、ほとんどのデプロイメントでで十分です。LDAP への接続 URL が ldaps のみで始まる場合は、Red Hat Single Sign-On では Truststore SPI を使用します。

Import Users オプションを設定すると、LDAP プロバイダーは LDAP ユーザーの Red Hat Single Sign-On ローカルデータベースへのインポートを処理します。ユーザーの初回ログイン時に、LDAP プロバイダーは LDAP ユーザーを Red Hat Single Sign-On データベースにインポートし、LDAP パスワードを検証します。この場合、Red Hat Single Sign-On がユーザーをインポートする場合のみ、ログインが初めてログインされます。管理コンソールの Users メニューをクリックし、View all users ボタンをクリックすると、少なくとも Red Hat Single Sign-On によって少なくとも 1 度認証された LDAP ユーザーのみが表示されます。Red Hat Single Sign-On はこの方法でユーザーをインポートするため、この操作は LDAP ユーザーデータベース全体のインポートをトリガーしません。

全 LDAP ユーザーを Red Hat Single Sign-On データベースに同期する場合は、LDAP プロバイダー設定ページで Sync Settings を設定し、有効にすることができます。

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

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

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

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

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

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

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

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

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 ...

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

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

サーバーの再起動後に接続プールのメッセージがこれ以上表示されない場合は、接続プールが LDAP サーバーでは機能しないことを示すことができます。

LDAP の問題を報告する場合、ターゲットデータとともに LDAP ツリーの一部を添付すると、環境で問題が発生します。たとえば、一部のユーザーログインに多くの時間がかかる場合、さまざまなグループエントリーの member の数を表示する LDAP エントリーをアタッチすることができます。この場合、これらのグループエントリーが Red Hat Single Sign-On の一部のグループ LDAP マッパー (またはロール LDAP マッパー) にマップされるかどうかを追加するのに役立ちます。

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

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

Red Hat Single Sign-On は、D-Bus との低レベルの通信に DBus-Java を使用します。D-Bus は、Unix ソケットライブラリー によって異なります。

SSSD フェデレーションプロバイダーを有効にする前に、このライブラリーの RPM をインストールします。

$ sudo yum install rh-sso7-libunix-dbus-java

Red Hat Single Sign-On は JNA を使用して PAM で認証します。JAN パッケージがインストールされていることを確認します。

$ sudo yum install jna

sssctl user-checks コマンドを使用して設定を検証します。

  $ sudo sssctl user-checks admin -s keycloak

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

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

OTP がレルムの条件である場合、ユーザーは Red Hat Single Sign-On Account Console に移動し、新しい OTP ジェネレーターを再設定する必要があります。OTP が必要な場合は、ログイン時に新しい OTP ジェネレーターを再設定する必要があります。

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

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

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

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

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

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

Red Hat Single Sign-On に初めてログインする前に、新規ユーザーが契約条件に同意する必要のあるアクションを有効にできます。

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

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

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

declarative_user_profile 機能を有効にする他に、レルムのユーザープロファイルを有効にする必要があります。これには、左側のメニューの Realm Settings リンクをクリックし、User Profile Enabled スイッチを有効にします。

有効化して Save ボタンをクリックすると、ユーザー属性の設定を管理できる User Profile にアクセスできます。

レルムのユーザープロファイルを有効にすると、Red Hat Single Sign-On は、ユーザープロファイル設定に基づいて属性の管理方法に追加の制約を指定します。つまり、以下は、この機能が有効な場合に予想される内容のリストです。

次のトピックでは、ユーザープロファイル設定を管理する方法と、レルムへの影響を説明します。

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

Attributes サブタブでは、現在ユーザープロファイルに関連付けられている属性のリストがあります。デフォルトでは、設定はユーザー root 属性に基づいて作成され、各属性は検証およびパーミッションに関してデフォルトで設定されます。

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

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

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

Attributes サブタブで、ユーザープロファイルに関連する属性を作成、編集、および削除できます。

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

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

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

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

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

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

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

{
  "attributes": [
    {
      "name": "myattribute",
      "required": {
        "roles": [ "user", "admin" ],
        "scopes": [ "foo", "bar" ]
      },
      "permissions": {
        "view": [ "admin", "user" ],
        "edit": [ "admin", "user" ]
      },
      "validations": {
        "email": {},
        "length": {
          "max": 255
        }
      },
      "annotations": {
        "myannotation": "myannotation-value"
      }
    }
  ],
  "groups": [
    {
      "name": "personalInfo",
      "displayHeader": "Personal Information"
    }
  ]
}

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

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

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

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

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

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

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

ユーザープロファイルの主な機能の 1 つは、属性メタデータに基づいてユーザーに表示されるフォームを動的にレンダリングすることがあります。機能がレルムで有効にされている場合、登録や更新などのフォームは、ユーザープロファイル設定に基づいてページを動的にレンダリングする特定のテーマテンプレートを使用してレンダリングされます。

ただし、デフォルトのレンダリングメカニズムがニーズに対応する場合は、すべてのテンプレートをカスタマイズする必要はありません。テーマのカスタマイズをまだ必要な場合には、以下で参照する必要があるテンプレートを以下に示します。

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

"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}"
    }
  }
}
...
]

ユーザープロファイルが設定に準拠していることを確認するには、管理者は VerifyProfile の必須のアクションを使用して、最終的に Red Hat Single Sign-On への認証時にプロファイルの更新を強制することができます。

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

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

レルムにユーザープロファイル機能を有効にする前に、いくつかの重要な考慮事項に注意してください。属性メタデータを管理する単一の場所を提供することで、ユーザーや管理方法に設定できる属性は非常に厳しいものです。

ユーザー管理では、管理者はユーザープロファイル設定で定義された属性のみを管理できます。ユーザープロファイル設定で定義されておらず、ユーザープロファイル設定で定義されていない他の属性にはアクセスできません。ユーザーまたは管理者へ公開する必要のあるすべてのユーザー属性で、ユーザープロファイル設定を更新することが推奨されます。

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

LDAP_ID、LDAP_ENTRY_DN、KERBEROS_ PRINCIPAL などの Red Hat Single Sign-On 内部ユーザー属性に関しては、これらの属性をユーザープロファイル設定の属性としてアクセスできるようにする必要があります。表示可能な属性は管理者だけなので、管理コンソールを使用してユーザー属性を管理する場合や、ユーザー API でユーザーのクエリーを行う際には、この属性を表示可能としてマークすることが推奨されます。

そのため、レガシーテンプレート (ユーザー root 属性でハードコード化) へのカスタマイズがある場合、ユーザーに表示されるフォームをレンダリングする場合、これらのフォームを動的にレンダリングする新規テンプレートは使用されません。理想的には、テンプレートへのカスタマイズは回避し、これらの新規テンプレートが提供する動作のスタップをして、フォームを動的にレンダリングする必要があります。要件への対応が十分ではない場合は、それらをカスタマイズするか、フィードバックを提供してください。これにより、新しいテンプレートを拡張することが理にかっているかどうかについて話し合うことができます。

Logout all ボタンをクリックして、レルム内の全ユーザーを省略できます。

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

Sessions ページで、各クライアントをクリックして、そのクライアントの Sessions タブに移動します。Show Sessions ボタンをクリックして、アプリケーションにあるユーザーを表示します。

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

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

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

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

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

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

OTP ジェネレーターに Red Hat Single Sign-On で利用可能なアルゴリズムは時間ベースで、カウンターベースになっています。

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

Counter-Based One Time Passwords (HOTP) では、Red Hat Single Sign-On は現在の時間ではなく、共有カウンターを使用します。Red Hat Single Sign-On サーバーは、成功した各 OTP ログインでカウンターをインクリメントします。ログインに成功した後、有効な OTP が変更されます。

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

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

Red Hat Single Sign-On には複数の組み込みフローがあります。これらのフローは変更できませんが、フローの要件をニーズに合わせて変更することができます。

ドロップダウンリストで、ブラウザー を選択して Browser Flow 画面を表示します。

ドロップダウンリストの question-mark ツールにカーソルを合わせ、フローの説明を表示します。2 つのセクションがあります。

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

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

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

Red Hat Single Sign-On がフローを作成すると、Red Hat Single Sign-On に Delete、Add execution、および Add flow ボタンが表示されます。

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

リセットメールの送信から OTP の検証まで、実行にはさまざまなアクションを設定できます。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 フローに似た、ユーザーのフォームを生成するサブフローを構築します。サブフローが成功するかどうかは、含まれるサブフローを含め、実行がどのように評価されるかによります。サブフローがどのように機能するかの詳細な説明については、実行要件 セクションを参照してください。

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

実行の順序は重要であるため、名前の横にある上下ボタンで、実行とサブフローをフロー内で上下に動かすことができます。

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

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

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

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

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

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

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

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

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

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

https://{DOMAIN}/auth/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"]
                }
            }
        }

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

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

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

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

フローロジック

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

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

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

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

シナリオ例

トークンの ACR クレーム

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

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

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

ユーザーが持つことができるセッション数の制限を設定できます。セッションは、レルムごとまたはクライアントごとに制限できます。

フローにセッション制限を追加するには、次の手順を実行します。

ユーザーセッションの制限は、バインドされた Browser Flow、Direct Grant Flow、Reset Credentials、および設定された ID プロバイダーのすべての Post Login Flow に追加する必要があることに注意してください。現在、管理者は異なる設定間で整合性を維持します。

また、CIBA ではユーザーセッション制限機能は利用できないことに注意してください。

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

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

sudo kadmin.local

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

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

Red Hat Single Sign-On が稼働しているホストで 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 Single Sign-On サーバーが SPNEGO プロトコルを処理するため、OpenID Connect トークン要求または SAML アサーション属性内のアプリケーションに GSS 認証情報を反映させる必要があります。Red Hat Single Sign-On は、これを Red Hat Single Sign-On サーバーからアプリケーションに送信します。この要求をトークンまたはアサーションに挿入するには、各アプリケーションはビルトイン プロトコルマッパー gss delegation credential を有効にする必要があります。このマッパーは、アプリケーションのクライアントページの Mappers タブで利用できます。詳細は、プロトコルマッパー の章を参照してください。

アプリケーションは、Red Hat Single Sign-On から受信する要求を使用して他のサービスに対して 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);

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

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

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

ユーザーの検索は、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=(.*?)(?:,|$)

ここでは、JBoss EAP/Undertow および Red Hat Single Sign-On Server を設定して、X.509 クライアント証明書認証を有効にする方法を説明します。

<security-realms>
    <security-realm name="ssl-realm">
        <server-identities>
            <ssl>
                <keystore path="servercert.jks"
                          relative-to="jboss.server.config.dir"
                          keystore-password="servercert password"/>
            </ssl>
        </server-identities>
        <authentication>
            <truststore path="truststore.jks"
                        relative-to="jboss.server.config.dir"
                        keystore-password="truststore password"/>
        </authentication>
    </security-realm>
</security-realms>

<subsystem xmlns="urn:jboss:domain:undertow:12.0">
	....
    <server name="default-server">
	    <https-listener name="default"
                        socket-binding="https"
                        security-realm="ssl-realm"
                        verify-client="REQUESTED"/>
    </server>
</subsystem>

Red Hat Single Sign-On サーバーが直接 HTTP リクエストを受け取ると、JBoss EAP undertow サブシステムは SSL ハンドシェイクを確立し、クライアント証明書を抽出します。JBoss EAP は、サーブレット仕様で指定されたように、HTTP リクエストの javax.servlet.request.X509Certificate 属性にクライアント証明書を保存します。Red Hat Single Sign-On X509 オーセンティケーターは、この属性から証明書を検索できます。

ただし、Red Hat Single Sign-On サーバーがロードバランサーまたはリバースプロキシーの背後で HTTP リクエストをリッスンする場合は、プロキシーサーバーはクライアント証明書を抽出し、相互 SSL 接続を確立する場合があります。リバースプロキシーは通常、認証されたクライアント証明書をベースのリクエストの HTTP ヘッダーに配置します。プロキシーはリクエストをバックエンド Red Hat Single Sign-On サーバーに転送します。この場合、Red Hat Single Sign-On は、HTTP リクエストの属性ではなく、HTTP ヘッダーから X.509 証明書チェーンを検索する必要があります。

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

<spi name="x509cert-lookup">
    <default-provider>haproxy</default-provider>
    <provider name="haproxy" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>apache</default-provider>
    <provider name="apache" enabled="true">
        <properties>
            <property name="sslClientCert" value="SSL_CLIENT_CERT"/>
            <property name="sslCertChainPrefix" value="CERT_CHAIN"/>
            <property name="certificateChainLength" value="10"/>
        </properties>
    </provider>
</spi>

<spi name="x509cert-lookup">
    <default-provider>nginx</default-provider>
    <provider name="nginx" enabled="true">
        <properties>
            <property name="sslClientCert" value="ssl-client-cert"/>
            <property name="sslCertChainPrefix" value="USELESS"/>
            <property name="certificateChainLength" value="2"/>
        </properties>
    </provider>
</spi>

 ...
 server {
    ...
    ssl_client_certificate                  trusted-ca-list-for-client-auth.pem;
    ssl_verify_client                       optional_no_ca;
    ssl_verify_depth                        2;
    ...
    location / {
      ...
      proxy_set_header ssl-client-cert        $ssl_client_escaped_cert;
      ...
    }
    ...
}

...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:8.0">
...
            <logger category="org.keycloak.authentication.authenticators.x509">
                <level name="TRACE"/>
            </logger>
            <logger category="org.keycloak.services.x509">
                <level name="TRACE"/>
            </logger>

以下のテンプレートを使用して、Resource Owner Password Credentials Grant を使用してトークンを要求できます。

$ LOC=<install-dir>/intermediate1/user-certificate

$ curl --insecure https://localhost:8443/auth/realms/X509_demo/protocol/openid-connect/token --data "grant_type=password" -E $LOC/user1.crt --key $LOC/user1.key --cacert $LOC/intermediate-ca-chain.crt -d client_id=account -d client_secret=BNm5AQPJGEtbayIAoiKUetr0lkXKSlF4 | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2097 100 2013 100 84 25481 1063 -::- -::- -::- 26544
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1OUNpN0tzUjBIOEFCQXEtQ1Z4SEFDSUo1M1hNYWVhclJrYkw4cFd1VW4wIn0.eyJleHAiOjE2Njc4MzA5NjAsImlhdCI6MTY2NzgzMDY2MCwianRpIjoiNDU5YzE2OGMtODU3ZS00OWRjLTgxYjItZjVhM2M3M2MwODMzIiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODQ0My9hdXRoL3JlYWxtcy9YNTA5X2RlbW8iLCJzdWIiOiIwODZiMTgyZC00MzdhLTQzZDItYTRmZS05ZGZmYTNmOTBiZDAiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhY2NvdW50Iiwic2Vzc2lvbl9zdGF0ZSI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCIsImFjciI6IjEiLCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJwcm9maWxlIGVtYWlsIiwic2lkIjoiYzBiM2IxMmMtMzliYS00ZDQ2LWI0M2UtNmQxMzQwYmY1MDk4IiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ1c2VyMSIsImVtYWlsIjoidXNlckByZWRoYXQuY29tIn0.CDtltEkmITloDpqU5alq4U1JopqEJVeoglT-wA43edQ_DfeWSgefL0BIrPlt1SKhFMOVitwyq_9XZvfiS5ZiObE33cDmhr6eohbUtDPibU2GuEIYP9WjlVpZDMaSKQVu5SwM91m6yei22PtH-ApPOBeG4Ru0xZtNXjwGQpuIJEi_H1rZdPY3I4U2lPuQo4Uono5gnF7re_nUvf90FJi0uaOOrsvUhUkj1xEwQ0Diy1oIymcbrDL0Ek7B30StBcjn-fe3-0GpLttLQju0OGTkwD7Eb0UWTKoWAwspMlgpf9NaIGj8rmBsz6eBlGIGWBN2Qg6v3PzbJ2NXKvq435f9Zg",
"expires_in": 300,
"refresh_expires_in": 1800,
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIyMmFkZDdhMy0xN2RjLTQ5NmQtYTk4NS05YWZhNGZhODVhMTEifQ.eyJleHAiOjE2Njc4MzI0NjAsImlhdCI6MTY2NzgzMDY2MCwianRpIjoiZWU4MjJhMzYtMWEzMS00ZGEzLWIxMGEtNmY1ODkxYmI0MzlhIiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODQ0My9hdXRoL3JlYWxtcy9YNTA5X2RlbW8iLCJhdWQiOiJodHRwczovL2xvY2FsaG9zdDo4NDQzL2F1dGgvcmVhbG1zL1g1MDlfZGVtbyIsInN1YiI6IjA4NmIxODJkLTQzN2EtNDNkMi1hNGZlLTlkZmZhM2Y5MGJkMCIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJhY2NvdW50Iiwic2Vzc2lvbl9zdGF0ZSI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCIsInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsInNpZCI6ImMwYjNiMTJjLTM5YmEtNGQ0Ni1iNDNlLTZkMTM0MGJmNTA5OCJ9.MubgR9rvyrmSOcaq5ce-qVTPenVQye1KsEHJr7nh9-A",
"token_type": "Bearer",
"not-before-policy": 0,
"session_state": "c0b3b12c-39ba-4d46-b43e-6d1340bf5098",
"scope": "profile email"
}

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

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

WebAuthn オーセンティケーターを登録すると、Red Hat Single Sign-On は、WebAuthn オーセンティケーターが生成した証明ステートメントの信頼性を検証します。Red Hat Single Sign-On では、これにトラストアンカーの証明書が必要です。Red Hat Single Sign-On は Keycloak トラストストア を使用するので、事前にこれらの証明書をインポートする必要があります。

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

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

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

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

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

管理者は、通常、WebAuthn ログインレス認証用にユーザーが登録するセキュリティーキーが異なる要件を満たすことを要求します。ログインレス認証では、ユーザーがセキュリティーキーに対して認証する必要があり (たとえば、PIN コードまたは指紋を使用して)、ログインレスクレデンシャルに関連付けられた暗号化キーがセキュリティーキーに物理的に保存されている必要があります。すべてのセキュリティーキーがそのような要件を満たしているわけではありません。デバイスがユーザー検証および常駐キーをサポートしているかどうかをセキュリティーキーベンダーに確認してください。サポートされているセキュリティーキー を参照してください。

Red Hat Single Sign-On により、管理者はログインレス認証を可能にする方法で 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!

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

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

詳細は、公式の OpenShift ドキュメント を参照してください。