Menu Close
Settings Close

Language and Page Formatting Options

サーバー管理ガイド

Red Hat Single Sign-On 7.4

Red Hat Single Sign-On 7.4 向け

概要

本書は、管理者が Red Hat Single Sign-On 7.4 を設定するための情報で構成されます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージを参照してください。

第1章 概要

Red Hat Single Sign-On は、Web アプリケーションと RESTful Web サービスのソリューションに関するシングルサインオンです。Red Hat Single Sign-On の目的は、アプリケーション開発者が組織にデプロイしたアプリケーションおよびサービスのセキュリティーを保護することができるように、セキュリティーシンプルにすることです。通常、開発者は自分で作成する必要のあるセキュリティー機能は、追加設定なしで提供され、組織の個々の要件に簡単に調整できます。Red Hat Single Sign-On は、ログイン、登録、管理、アカウント管理用にカスタマイズ可能なユーザーインターフェースを提供します。Red Hat Single Sign-On を統合プラットフォームとして使用し、既存の LDAP サーバーと Active Directory サーバーへフックすることもできます。認証を Facebook や Google+ などのサードパーティーのアイデンティティープロバイダーに委任することもできます。

1.1. 機能

  • ブラウザーアプリケーションには、Single-Sign On および Single-Sign Out です。
  • OpenID Connect のサポート。
  • OAuth 2.0 サポート。
  • SAML サポート。
  • ID ブローカー: 外部 OpenID Connect または SAML ID プロバイダーで認証されます。
  • ソーシャルログイン - Google、GitHub、JWT、その他のソーシャルネットワークでのログインを有効にします。
  • ユーザーフェデレーション: LDAP および Active Directory サーバーからユーザーを同期します。
  • Kerberos ブリッジ: Kerberos サーバーにログインしたユーザーを自動的に認証します。
  • ユーザー、ロール、ロールマッピング、クライアント、および設定の一元管理のための管理コンソール。
  • ユーザーがアカウントを一元管理できるアカウントマネジメントコンソール。
  • テーマサポート: アプリケーションおよびブランディングと統合するユーザー向けページのカスタマイズ。
  • 2 要素認証: Google Authenticator または FreeOTP による TOTP/HOTP のサポート
  • ログインフロー: オプションのユーザーの自己登録、パスワードのリカバリー、電子メールの確認、パスワードの更新など。
  • セッション管理: 管理者およびユーザー自身がユーザーセッションを表示および管理できます。
  • トークンマッパー: トークンとステートメントへのユーザーの属性、ロールなどをマップします。
  • レルム、アプリケーション、ユーザーごとの失効前ポリシー。
  • CORS サポート - クライアントアダプターには CORS のサポートが組み込まれています。
  • JavaScript アプリケーション、JBoss EAP、Fuse などのクライアントアダプター。
  • OpenID Connect 依存パーティーライブラリーまたは SAML 2.0 サービスプロバイダーライブラリーを持つすべてのプラットフォーム/言語をサポートします。

1.2. セキュリティーが機能する仕組み

Red Hat Single Sign-On は、ネットワーク上で管理する別のサーバーです。アプリケーションは、このサーバーによって提供され、保護されるように設定されています。Red Hat Single Sign-On は、OpenID Connect または SAML 2.0 などのオープンプロトコル標準を使用してアプリケーションを保護します。ブラウザーアプリケーションは、ユーザーのブラウザーをアプリケーションから Red Hat Single Sign-On 認証サーバーにリダイレクトし、ユーザーに認証情報の入力を求めます。ユーザーはアプリケーションから完全に分離され、アプリケーションはユーザーの認証情報を認識しないために重要になります。アプリケーションには、暗号で署名された認証情報トークンまたはアサーションが与えられます。これらのトークンには、ユーザー名、アドレス、電子メール、他のプロファイルデータなどのアイデンティティー情報を使用できます。また、アプリケーションによる承認決定を実行できるように、パーミッションデータを保持することもできます。これらのトークンを使用して、REST ベースのサービスでセキュアな呼び出しを行うこともできます。

1.3. コアとなる概念および利用規約

Web アプリケーションと REST サービスのセキュリティーを保護するには、Red Hat Single Sign-On の使用を試行する前に、いくつかの主要な概念と用語を認識する必要があります。

ユーザー
ユーザーは、システムにログインできるエンティティーです。電子メール、ユーザー名、アドレス、電話番号、および日目などの属性を関連付けることができます。グループメンバーシップを割り当てることができ、特定のロールをそれらに割り当てることができます。
認証
ユーザーを特定し、検証するプロセスです。
認可
ユーザーに付与するプロセスです。
認証情報
認証情報は、Red Hat Single Sign-On がユーザーの ID を検証するために使用するデータの一部です。たとえば、パスワード、ワンタイムパスワード、デジタル証明書、またはフィンガープリントなどが挙げられます。
ロール
ロールはユーザーのタイプまたはカテゴリーを識別します。Adminusermanageremployee は、組織に存在する可能性のある通常のロールすべてです。アプリケーションは通常、多くの場合、個々のユーザーではなく、特定のロールにアクセスおよびパーミッションを割り当てます。これは、ユーザーの処理は複雑で、管理が困難となるためです。
ユーザーロールのマッピング
ユーザーロールのマッピングは、ロールとユーザー間のマッピングを定義します。ユーザーをゼロ以上のロールに関連付けることができます。このロールマッピング情報は、アプリケーションが管理するさまざまなリソースのアクセスパーミッションを決定することができるように、トークンとアサーションにカプセル化できます。
複合ロール
複合ロールは、他のロールに関連付けることができるロールです。たとえば、superuser の複合ロールを sales-admin ロールおよび order-entry-admin ロールに関連付けることができます。ユーザーが superuser ロールにマップされている場合は、sales-admin ロールおよび order-entry-admin ロールも継承されます。
グループ
グループはユーザーのグループを管理します。グループに対して属性を定義できます。ロールをグループにマッピングすることもできます。グループのメンバーになるユーザーは、そのグループで定義される属性とロールマッピングを継承します。
レルム
レルムは、一連のユーザー、認証情報、ロール、およびグループを管理します。ユーザーはレルムに属し、レルムにログインします。レルムは相互に分離され、制御するユーザーのみを管理および認証できます。
クライアント
クライアントは、Red Hat Single Sign-On を要求してユーザーを認証できるエンティティーです。多くの場合、クライアントは Red Hat Single Sign-On を使用して自己保護し、シングルサインオンソリューションを提供するアプリケーションとサービスです。クライアントは、ID 情報またはアクセストークンを要求するエンティティーで、Red Hat Single Sign-On によってセキュア化されるネットワーク上でその他のサービスを安全に呼び出すことができるようにすることもできます。
クライアントアダプター
クライアントアダプターは、アプリケーション環境にインストールするプラグインで、Red Hat Single Sign-On の通信およびセキュア化を可能にします。Red Hat Single Sign-On には、ダウンロード可能なさまざまなプラットフォームに多くのアダプターがあります。また、サードパーティーのアダプターも、対象外の環境で取得できます。
consent
Consent は、クライアントが認証プロセスに参加する前に、ユーザーにクライアントにパーミッションを付与する場合です。ユーザーがクレデンシャルを提供すると、Red Hat Single Sign-On がログインを要求するクライアントを特定する画面と、ユーザーの要求情報を確認する画面が表示されます。ユーザーは、要求を付与するかどうかを決定できます。
クライアントスコープ
クライアントが登録されたら、そのクライアントのプロトコルマッパーとロールスコープマッピングを定義する必要があります。多くの場合、クライアントスコープを保存し、共通の設定を共有することで新しいクライアントの作成を簡素化します。これは、一部の要求またはロールを scope パラメーターの値に基づいて条件付きで要求する場合にも便利です。Red Hat Single Sign-On では、このクライアントスコープの概念が提供されています。
クライアントロール
クライアントは、それら固有のロールを定義できます。これは基本的に、クライアント専用のロール名前空間です。
ID トークン
ユーザーに関する情報を提供するトークン。OpenID Connect 仕様の一部。
アクセストークン
呼び出されるサービスへのアクセスを付与する HTTP リクエストの一部として提供できるトークン。これは、OpenID Connect および OAuth 2.0 仕様の一部です。
アサーション
ユーザーに関する情報。これは通常、認証されたユーザーに関連するアイデンティティーメタデータを提供する SAML 認証応答に含まれる XML Blob に関連します。
サービスアカウント
各クライアントには、アクセストークンの取得を可能にする組み込み service account があります。
直接付与
REST 呼び出しでユーザーの代わりにアクセストークンを取得する方法。
プロトコルマッパー
各クライアントについて、OIDC トークンまたは SAML アサーションに保存される要求とアサーションを調整できます。プロトコルマッパーを作成および設定して、クライアントごとにこれを行います。
セッション
ユーザーがログインすると、セッションがログインセッションを管理します。セッションには、ユーザーがログインした時や、そのセッション中に単一署名に参加したアプリケーションなどの情報が含まれます。管理者およびユーザーの両方がセッション情報を表示できます。
ユーザーフェデレーションプロバイダー
Red Hat Single Sign-On はユーザーを保存して管理できます。多くの場合、ユーザーと認証情報を格納する LDAP または Active Directory サービスがすでにあります。Red Hat Single Sign-On を示すことで、外部ストアから認証情報を検証して ID 情報にプルすることができます。
アイデンティティープロバイダー
アイデンティティープロバイダー (IDP) はユーザーを認証できるサービスです。Red Hat Single Sign-On は IDP です。
ID プロバイダーフェデレーション
Red Hat Single Sign-On は、1 つ以上の IDP に認証を委譲するように設定できます。Facebook または Google+ でのソーシャルログインは、アイデンティティープロバイダーのフェデレーションの例です。また、Red Hat Single Sign-On のフックを行い、認証を他の OpenID Connect または SAML 2.0 IDP に委任することもできます。
ID プロバイダーマッパー
IDP フェデレーションを行う場合は、受信したトークンとアサーションを user および session 属性にマッピングできます。これは、外部の IDP から認証を要求するクライアントに ID 情報を伝播するのに役立ちます。
必要なアクション
必要なアクションは、ユーザーが認証プロセス中に実行する必要のあるアクションです。ユーザーは、これらのアクションが完了するまで認証プロセスを完了できません。たとえば、管理者はユーザーが毎月パスワードをリセットできるようにスケジュールすることが可能です。これらの全ユーザーに対して、update password に必要なアクションが設定されます。
認証フロー
認証フローは、システムの特定の側面と対話するときにユーザーが実行する必要のあるフローです。ログインフローは必要な認証情報タイプを定義できます。登録フローは、ユーザーが入力しなければならないプロファイル情報や、ボットをフィルターするのに reCAPTCHA などのプロファイル情報を定義します。認証情報リセットフローは、パスワードをリセットする前にユーザーが行うべきアクションを定義します。
イベント
イベントは、管理者が表示やフックを表示できる監査ストリームです。
テーマ
Red Hat Single Sign-On が提供するすべての画面は、テーマでサポートされます。テーマは、必要に応じて上書きできる HTML テンプレートとスタイルシートを定義します。

第2章 サーバーの初期化

『サーバーインストールおよび設定ガイド』で定義されたインストールおよび設定タスクをすべて実行した後に、最初の管理者アカウントを作成する必要があります。Red Hat Single Sign-On には、追加設定なしで設定されている管理アカウントがありません。このアカウントを使用すると、マスターレルムの管理コンソールにログインしてレルムの作成を開始でき、Red Hat Single Sign-On によるアプリケーション登録を行うことができます。

localhost からサーバーにアクセス可能な場合は、URL http://localhost:8080/auth に移動してこの管理ユーザーを作成できます。

Welcome ページ

initial welcome page

この初期 admin に必要なユーザー名とパスワードを指定するだけです。

localhost ホストアドレスからサーバーにアクセスできない場合や、コマンドラインから Red Hat Single Sign-On をプロビジョニングする場合は、…​/bin/add-user-keycloak スクリプトで、これを行うことができます。

add-user-keycloak スクリプト

add user script

スタンドアロン操作モードまたはドメイン操作モードを使用している場合によって、パラメーターはほとんど異なります。スタンドアロンモードの場合、ここではスクリプトの使用方法を紹介します。

Linux/Unix

$ .../bin/add-user-keycloak.sh -r master -u <username> -p <password>

Windows

> ...\bin\add-user-keycloak.bat -r master -u <username> -p <password>

ドメインモードでは、-sc スイッチを使用して、スクリプトがサーバーホストの 1 つを参照するようにする必要があります。

Linux/Unix

$ .../bin/add-user-keycloak.sh --sc domain/servers/server-one/configuration -r master -u <username> -p <password>

Windows

> ...\bin\add-user-keycloak.bat --sc domain/servers/server-one/configuration -r master -u <username> -p <password>

第3章 管理コンソール

管理タスクの大部分は、Red Hat Single Sign-On 管理コンソールを介して行われます。http://localhost:8080/auth/admin/ からコンソールの URL に直接アクセスできます。

ログインページ

login page

Welcome Page で作成したユーザー名やパスワードを入力するか、bin ディレクトリーに add-user-keycloak スクリプトを入力します。これにより、Red Hat Single Sign-On 管理コンソールが作成されます。

管理コンソール

admin console

左のドロップダウンメニューでは、管理するレルムを選択したり、新しいレルムを作成したりできます。右側のドロップダウンメニューでは、ユーザーアカウントやログアウトを表示できます。管理コンソール内の特定の機能、ボタン、またはフィールドについて知りたい場合は、クエスチョンマーク (?) アイコンにマウスを置いてください。これにより、対象のコンソールの領域を説明するヒントテキストがポップアップされます。上記のイメージはアクションのツールチップを示しています。

3.1. マスターレルム

初めて Red Hat Single Sign-On を起動すると、事前定義済みのレルムが作成されます。この初期レルムは master レルムです。レルムの階層で最上位の最上位です。このレルムの管理者アカウントには、サーバーインスタンスで作成されたその他のレルムを表示および管理するためのパーミッションがあります。最初の管理アカウントを定義する際に、master レルムにアカウントを作成します。管理コンソールへの初回ログインも master レルムを介して行われます。

master レルムを使用して組織のユーザーやアプリケーションを管理しないことが推奨されます。super 管理者がシステム内でレルムを作成し、管理するための master レルムの使用を予約します。このセキュリティーモデルに従うことで、誤って変更を回避し、ユーザーアカウントのクリメンティションに従って、現在のタスクの正常な完了に必要な特権と電源へのアクセスを許可します。

master レルムを無効にして、作成する個々の新しいレルム内に管理アカウントを定義することができます。各レルムには独自の専用管理コンソールがあり、ローカルアカウントでログインできます。本ガイドでは、「専用レルムの管理コンソール」の章でこれについて詳しく説明します。

3.2. レルムの新規作成

新規レルムの作成は非常に簡単です。Master というタイトルの左上にあるドロップダウンメニューにマウスを置きます。マスターレルムにログインしている場合、このドロップダウンメニューには作成されたすべてのレルムが一覧表示されます。このドロップダウンメニューの最後のエントリーは、常に Add Realm です。クリックしてレルムを追加します。

レルムメニューの追加

add realm menu

このメニューオプションにより、Add Realm ページが表示されます。定義するレルム名を指定して、Create ボタンをクリックします。または、新しいレルムを定義する JSON ドキュメントをインポートできます。これについては、「エクスポートとインポート」の章で詳しく説明します。

レルムの作成

create realm

レルムを作成したら、メインの Admin Console ページに戻ります。現在のレルムは作成したレルムに設定されます。異なるレルムの管理を切り替えるには、左上隅のドロップダウンメニューでマウスをかざします。

3.3. SSL モード

各レルムには SSL モードが関連付けられています。SSL モード は、レルムと対話するための SSL/HTTPS 要件を定義します。レルムと相互作用するブラウザーおよびアプリケーションは、SSL モードで定義された SSL/HTTPS 要件に従う必要があり、サーバーと対話することはできません。

警告

Red Hat Single Sign-On は、初回実行時に自己署名証明書を生成します。自己署名証明書は安全ではなく、テスト目的でのみ使用する必要があることに注意してください。Red Hat Single Sign-On サーバー自体またはリバースプロキシーに CA 署名の証明書をインストールすることを、Red Hat Single Sign-On サーバーの前にインストールすることが強く推奨されます。詳細は「サーバーインストールおよび設定ガイド」を参照してください。

レルムの SSL モードを設定するには、左側のメニュー項目 Realm Settings をクリックして Login タブにアクセスする必要があります。

ログインタブ

login tab

Require SSL オプションでは、必要な SSL モードを選択できます。各モードについて説明します。

外部要求
ユーザーは、localhost127.0.0.110.x.x.x192.168.x.x172.16.x.x などのプライベート IP アドレスに有効な限り、SSL なしで Red Hat Single Sign-On と対話できます。プライベートでない IP アドレスから SSL なしで Red Hat Single Sign-On へのアクセスを試行すると、エラーが発生します。
none
Red Hat Single Sign-On には SSL は必要ありません。これは、処理を実行し、サーバーに SSL を設定したくない場合に、この開発でのみ使用する必要があります。
すべてのリクエスト
Red Hat Single Sign-On では、すべての IP アドレスに SSL が必要です。

3.4. サーバーキャッシュの消去

Red Hat Single Sign-On は、JVM の制限中または設定している制限内のメモリー内ですべてキャッシュされます。Red Hat Single Sign-On データベースが、サーバーの REST API または管理コンソールの範囲外にあるサードパーティー (DBA) によって変更された場合、インメモリーキャッシュの一部が古い可能性があります。管理者コンソールから Realm Settings の左メニュー項目と Cache タブに移動して、リアムキャッシュ、ユーザーキャッシュ、外部公開鍵のキャッシュ (Red Hat Single Sign-On が通常特定の外部エンティティーの署名を検証するのに使用する外部クライアントや ID プロバイダーの公開鍵) をクリアすることができます。

キャッシュタブ

cache tab

エビクトするキャッシュの clear ボタンをクリックします。

3.5. メール設定

Red Hat Single Sign-On は、電子メールアドレスをユーザーに送信して、パスワードを忘れた時に、または管理者がサーバーイベントに関する通知を受け取る必要がある場合にメールを送信します。Red Hat Single Sign-On がメールを送信するには、Red Hat Single Sign-On に SMTP サーバー設定を指定する必要があります。これはレルムごとに設定されます。左側のメニュー項目 Realm Settings に移動し、Email タブをクリックします。

メールタブ

email tab

Host
Host は、電子メールの送信に使用する SMTP サーバーのホスト名を示します。
Port
Port は SMTP サーバーポートを示します。
From
From は、送信したメールの From SMTP-Header に使用されるアドレスを示します。
From Display Name
From Display Name からは、ユーザーが平易な電子メールアドレスエイリアス (任意) を設定できます。これを設定しないと、平文 From のメールアドレスはメールクライアントに表示されます。
Reply To
Reply To は、送信されるメールの SMTP-Header Reply-To に使用されるアドレスを示します (任意)。これを設定しないと、平文 From のメールアドレスが使用されます。
Reply To Display Name
Reply To Display Name メールアドレスエイリアス (任意) を設定することができます。これを設定しないと、平文 Reply To メールアドレスが表示されます。
Envelope From
Envelope From は、送信されるメールの Return-Path SMTP-Header に使用される バウンスアドレス を示します (任意)。

メールは、ユーザー名とパスワードを使用して SSL または TLS を使用することが推奨されます (特に SMTP サーバーが外部ネットワーク上にある場合)。SSLを有効にするには Enable SSL をクリックするか、TLS を有効にするには Enable TLS をクリックします。ほとんどの場合、Port も変更する必要があります (SSL/TLS のデフォルトポートは 465 です)。

SMTP サーバーで認証が必要な場合は、Enable Authentication をクリックし、Username および Password を入力します。Password フィールドの値は、外部 vault からの値を参照できます。

3.6. テーマと国際化

Red Hat Single Sign-On で UI の外観および操作感を変更できます。レルムごとに設定されます。テーマを変更するには、左側のメニュー項目 Realm Settings に移動し、Themes タブをクリックします。

テーマタブ

themes tab

UI カテゴリーごとに必要なテーマを選択し、Save をクリックします。

ログインテーマ
ユーザー名エントリー、OTP エントリー、新しいユーザー登録、およびその他の同様の画面。
アカウント: テーマ
各ユーザーに、ユーザーアカウントの管理 UI があります。
管理コンソールのテーマ
Red Hat Single Sign-On 管理コンソールのスキン。
メールテーマ
Red Hat Single Sign-On がメールを送信する必要がある場合には、このテーマに定義されているテンプレートを使用して電子メールを作成します。

サーバー開発者ガイド』では、新規の作成や既存ものの変更方法について説明します。

3.6.1. 国際化

すべての UI 画面は、Red Hat Single Sign-On で国際化されています。デフォルトの言語は英語ですが、Theme タブで Internationalization スイッチをオンにする場合は、サポートするロケールとデフォルトのロケールを選択できます。ユーザーが次にログイン時に、ログイン画面、ユーザーアカウント管理 UI、および管理コンソールに使用するログインページで言語を選択できます。『サーバー開発者ガイド』では、追加の言語を提供する方法を説明します。

3.6.1.1. ユーザーロケールの選択

ユーザーに最適なロケールを選択するには、利用可能な情報に関する最良のロケールを決定するために使用されるロケールセレクタープロバイダーがあります。ここで注意すべき点は、ユーザーが必ずしも認識されているわけではないことです。このため、以前に認証されたユーザーのロケールは、永続化されたクッキーに記憶されています。

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

  • User selected: ドロップダウンロケールセレクターを使用してロケールを選択するとき
  • User profile: 認証されたユーザーがあり、ユーザーにロケールセットが推奨されるとき
  • Client selected: ui_locales パラメーターなどを使用してクライアントにより渡される
  • Cookie: ブラウザーで選択した最後のロケール
  • 許可される言語: Accept-Language ヘッダーのロケール
  • レルムのデフォルト
  • 上記がない場合は、英語にフォールバックします。

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

第4章 ユーザー管理

本セクションでは、ユーザーを管理する管理機能を説明します。

4.1. ユーザーの検索

特定のユーザーを管理する必要がある場合は、左側のメニューバーの Users をクリックします。

ユーザー

users

このメニューオプションを使用すると、ユーザー一覧のページに移動します。検索ボックスでは、ユーザーデータベースに検索するフルネーム、姓、またはメールアドレスに入力できます。このクエリーにより、条件にマッチするすべてのユーザーが起動します。View all users ボタンは、システム内のすべてのユーザーを一覧表示します。これにより、LDAP などの一部のバックエンドにはユーザー経由でページにアクセスする方法がないため、フェデレーションデータベース (LDAP など) ではなくローカルの Red Hat Single Sign-On データベースのみを検索します。したがって、フェデレーションされたバックエンドのユーザーを Red Hat Single Sign-On データベースと同期させるには、以下のいずれかを実行する必要があります。

  • 検索条件を調整します。これにより、Red Hat Single Sign-On データベースへの基準と一致するバックエンドユーザーのみが同期します。
  • User Federation タブに移動し、フェデレーションプロバイダーとページ内で Sync all users または Sync changed users をクリックします。

詳細は、「ユーザーフェデレーション」を参照してください。

4.2. 新規ユーザーの作成

ユーザーを作成するには、左側のメニューバーの Users をクリックします。

ユーザー

users

このメニューオプションを使用すると、ユーザー一覧のページに移動します。空のユーザー一覧の右側に、ユーザーの Add User が表示されるはずです。そのユーザーをクリックして、新規ユーザーの作成を開始します。

ユーザーの追加

add user

必須のフィールドは Username のみです。Save をクリックします。これにより、新しいユーザーの管理ページに移動します。

4.3. ユーザーの削除

ユーザーを削除するには、左側のメニューバーの Users をクリックします。

ユーザー

users

このメニューオプションを使用すると、ユーザー一覧のページに移動します。View all users をクリックするか、検索して削除するユーザーを見つけます。

すべてのユーザーの表示

delete user

ユーザーの一覧で、削除するユーザーの横にある Delete をクリックします。このユーザーの削除を確認するよう求められます。確認ボックスの Delete をクリックして確定します。

4.4. user 属性

名前やメールなどの基本的なユーザーメタデータ以外に、任意のユーザー属性を保存できます。管理するユーザーを選択し、Attributes タブをクリックします。

ユーザー

user attributes

属性名および値に、空白フィールドに値を入力し、その横にある Add ボタンをクリックして新規フィールドを追加します。このページで作成した編集は、Save ボタンに到達するまで保存されません。

4.5. ユーザーの認証情報

Credentials タブにアクセスする際にユーザーを表示すると、ユーザーの認証情報を管理できます。

認証情報の管理

user credentials

認証情報は、以下のフィールドが含まれる表に一覧表示されます。

Position
この列の矢印ボタンでは、最も優先度が高い認証情報の中で、ユーザーの認証情報の優先度を達成できます。この優先順位は、ログイン時にユーザーがどの認証情報が表示されるかを決定します。ユーザーが利用可能な最高の優先度は、選択したものになります。
Type
passwordotp などの認証情報のタイプを表示します。
User Label
これは、ログイン時にクレデンシャルをオプションとして提示する割り当て可能なラベルです。認証情報を記述するために任意の値に設定できます。
Data
これは、認証情報に関する機密性ではない技術情報を表示します。当初は非表示になっていますが、Show data…​ を押して認証情報について表示することができます。
Actions
この列には 2 つのボタンがあります。Save はユーザーラベルの値を記録しますが、Delete は認証情報を削除します。

4.5.1. ユーザーのパスワードの作成

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

認証情報管理 - パスワードを設定する

user credentials set password

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

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

また、email をセットアップした場合は、ユーザーに電子メールを送信すると、パスワードのリセットを求められます。Reset Actions リストから Update Password を選択し、Send Email をクリックします。任意で、メールリンクの有効性を設定できます。このリンクは、レルム設定の Tokens タブにデフォルトで設定されます。送信されたメールには、ユーザーがパスワードの更新画面に追加するリンクが含まれます。

ユーザーは、タイプパスワードを 1 つだけ持つことができます。

4.5.2. 他の認証情報の作成

管理コンソール内で、特定ユーザーの他の種類の認証情報を設定することはできません。これはユーザーの責任です。Credentials タブでユーザーの認証情報を削除できます。たとえば、ユーザーが OTP デバイスを失った場合や、認証情報が侵害されたりするなどの場合にのみ削除できます。

4.5.2.1. OTP の作成

レルムの OTP が条件である場合は、ユーザーは User Account Management サービスにアクセスして新しい OTP ジェネレーターを再設定する必要があります。OTP が必要な場合は、ログイン時に新しい OTP ジェネレーターを再設定するよう求められます。

パスワードと同様に、OTP ジェネレーターをリセットするよう依頼するメールをユーザーに送信できます。Reset Actions リストボックスで Configure OTP を選択し、Send Email ボタンをクリックします。送信されたメールには、OTP 設定画面にユーザーを追加するリンクが含まれます。ユーザーに OTP 認証情報がすでにあり、その他の設定でもこの方法を使用できます。

4.6. 必要なアクション

必要なアクションとは、ログインが許可される前にユーザーが終了する必要があるタスクです。ユーザーは、必要なアクションを実行する前に認証情報を提供する必要があります。必要なアクションが完了すると、ユーザーは再度アクションを実行する必要はありません。以下は、ビルトインの必要なアクションタイプの一部について説明します。

パスワードの更新
これが設定されている場合、ユーザーはパスワードを変更する必要があります。
OTP の設定
これを設定すると、Free OTP または Google Authenticator アプリケーションのいずれかを使用して、モバイルデバイスにワンタイムパスワードジェネレーターを設定する必要があります。
メールの確認
これが設定されている場合、ユーザーは有効なメールアカウントを持っていることを確認する必要があります。電子メールは、クリックする必要のあるリンクと共にユーザーに送信されます。このワークフローが正常に完了したら、ログインが可能になります。
プロファイルの更新
この必要なアクションにより、ユーザーにはプロファイル情報を更新するよう要求されます (名前、アドレス、電子メール、電話番号など)。

管理者は、管理コンソールのユーザーの Details タブ内の個別ユーザーに必要なアクションを追加できます。

必要なアクションの設定

user required action

Required User Actions リストボックスで、アカウントに追加するすべてのアクションを選択します。これを削除する場合は、アクション名の横にある X をクリックします。また、追加するアクションを決定した後に Save ボタンをクリックします。

4.6.1. デフォルトに必要なアクション

また、新規ユーザーの作成時にアカウントに追加する必要なアクション (Add User ボタンをクリックするとユーザー一覧画面、または ログインページの user registration リンクから) を指定することもできます。デフォルトの必須アクションを指定するには、左側のメニュー項目 Authentication に移動し、Required Actions タブをクリックします。

デフォルトに必要なアクション

default required actions

完全に新しいユーザーのログイン時に、実行する必要なアクションの Default Action コラムのチェックボックスをクリックするだけです。

4.6.2. 契約条件

多くの組織には、新規ユーザーの初回ログイン時に、Web サイトの契約条件に同意する必要があります。Red Hat Single Sign-On には、この機能は必要なアクションとして実装されていますが、いくつかの設定が必要です。いずれかとして、前述の Required Actions タブに移動し、Terms and Conditions アクションを有効にする必要があります。base ログインテーマで terms.ftl ファイルを編集する必要もあります。テーマの拡張および作成に関する詳細は、『サーバー開発者ガイド』を参照してください。

4.7. 権限借用

多くの場合、管理者がユーザーの権限を借用すると役立ちます。たとえば、いずれかのアプリケーションにバグが発生し、管理者がその問題を複製できるかをユーザーの権限を借用できます。適切な権限を持つ管理者は、ユーザーの権限を借用できます。管理者が偽装を開始できる場所は 2 つあります。1 つ目は Users リストタブにあります。

ユーザー

user search

管理者が john を検索したことが確認できます。John のアカウントの横には、なりすましボタンが表示されます。そのユーザーをクリックしてユーザーの権限を借用します。

また、ユーザーの Details タブからユーザーの権限を借用できます。

ユーザーの詳細

user details

ページの下部付近に、Impersonate ボタンが表示されます。そのユーザーをクリックしてユーザーの権限を借用します。

権限借用を行う際、管理者とユーザーが同じレルムにある場合は、管理者がログアウトされ、権限を借用したユーザーとして自動的にログインされます。管理者とユーザーが同じレルムにない場合、管理者はログインしたままになりますが、そのユーザーのレルムにユーザーとしてログインします。いずれの場合も、ブラウザーは、切り替え後のユーザーの「ユーザーアカウント管理」ページにリダイレクトされます。

レルムの impersonation ロールを持つユーザーは、ユーザーの権限を借用できます。管理パーミッションの割り当てに関する詳細は、「管理コンソールアクセス制御」の章を参照してください。

4.8. ユーザー登録

Red Hat Single Sign-On を有効にして、ユーザーの自己登録を許可することができます。有効化されると、ログインページの登録リンクにより、ユーザーをクリックして新しいアカウントを作成できます。

ユーザーの自己登録を有効にすると、登録フォームを使用して有効なユーザー名と電子メールを検出できます。reCAPTCHA サポート を有効にすることもできます。

登録の有効化は非常に簡単です。左側のメニュー Realm Settings に移動し、クリックします。次に、Login タブに移動します。このタブには、User Registration スイッチがあります。有効化して、Save ボタンをクリックします。

ログインタブ

login tab

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

登録リンク

registration link

このリンクをクリックすると、ユーザーが一部ユーザープロファイルの情報と新しいパスワードに入力する必要がある登録ページに移動します。

登録フォーム

registration form

登録フォームのルックアンドフィールを変更したり、入力する必要のある追加のフィールドを削除または追加できます。詳細は、『サーバー開発者ガイド』を参照してください。

4.8.1. reCAPTCHA サポート

ボットから登録を保護するために、Red Hat Single Sign-On は Google reCAPTCHA と統合しています。これを有効にするには、最初に Google Recaptcha Website に移動し、reCAPTCHA サイトキーとシークレットを取得できるように API キーを作成する必要があります。(localhost はデフォルトで機能するため、ドメインを指定する必要はありません)。

次に、Red Hat Single Sign-On 管理コンソールで実行する必要がある手順がいくつかあります。左側のメニュー項目 Authentication をクリックし、Flows タブに移動します。このページのドロップダウンリストから Registration フローを選択します。

登録フロー

registration flow

適切なラジオボタンをクリックして、Required に 'reCAPTCHA' 要件を設定します。これにより、画面で reCAPTCHA が有効になります。次に、Google reCAPTCHA Website で生成した reCAPTCHA サイトキーおよびシークレットを入力する必要があります。reCAPTCHA フローエントリーの右側にある 'Actions' ボタンをクリックし、"Config" リンクから、この設定ページで reCAPTCHA サイトキーとシークレットを入力します。

reCAPTCHA 設定ページ

recaptcha config

最後のステップは、Red Hat Single Sign-On セットのデフォルトの HTTP 応答ヘッダーを変更することです。Red Hat Single Sign-On は、Web サイトに iframe 内に任意のログインページを含めないようにする予定です。これは、クリックジャック攻撃を防ぐためです。Google が iframe 内の登録ページを使用するように承認する必要があります。左側のメニュー項目 Realm Settings に移動してから、Security Defenses タブに移動します。https://www.google.com を、X-Frame-Options ヘッダーおよび Content-Security-Policy ヘッダーの値に追加します。

Iframe の承認

security headers

これを行うと、登録ページに reCAPTCHA が表示されるはずです。ログインテーマで register.ftl を編集して、reCAPTCHA ボタンの配置およびスタイルで変更できます。テーマの拡張および作成に関する詳細は、『サーバー開発者ガイド』を参照してください。

4.9. Red Hat Single Sign-On により収集された個人データ

デフォルトでは、Red Hat Single Sign-On は以下を収集します。

  • メール、名、姓などの基本ユーザープロファイル
  • ソーシャルアカウントに使用する基本的なユーザープロファイルとソーシャルログインを使用する場合のソーシャルアカウントへの参照
  • IP アドレス、オペレーティングシステム名、ブラウザー名など、監査およびセキュリティー上の目的で収集されるデバイス情報

Red Hat Single Sign-On で収集される情報は、非常にカスタマイズ可能になりました。カスタマイズを行う場合は、以下のガイドラインに注意してください。

  • 登録フォームやアカウントフォームには、誕生日、性別、国籍などのカスタムフィールドを含めることができます。管理者は Red Hat Single Sign-On を設定して、LDAP などのソーシャルプロバイダーまたはユーザーストレージプロバイダーからデータを取得できます。
  • Red Hat Single Sign-On は、パスワード、OTP コード、WebAuthn 公開鍵などのユーザーの認証情報を収集します。この情報は暗号化されてデータベースに保存されるため、Red Hat Single Sign-On の管理者には表示されないことがありません。ただし、それぞれの種類の認証情報には、パスワードのハッシュに使用されるアルゴリズムやパスワードのハッシュ化に使用されるハッシュ反復数など、管理者が見直す可能性がある、自信的なメタデータを含めることができます。
  • 認証サービスおよび UMA サポートを有効にすると、Red Hat Single Sign-On は、特定のユーザーが所有者であるオブジェクトに関する情報を保持できます。たとえば、Red Hat Single Sign-On は、ユーザーの john が、フォトアルバム album with animals と、このアルバムにある lion picturecow picture という名前のいくつかの写真の所有者であることを追跡することができます。

第5章 ログインページの設定

機能が必要な場合は、有効にできる優れたビルトインログインページ機能があります。

5.1. forgot Password

これを有効にすると、パスワードを取得したり、OTP ジェネレーターを失った場合に、ユーザーは認証情報をリセットできます。左側のメニュー項目 レルム設定 に移動し、Login タブをクリックします。Forgot Password スイッチをオンにします。

ログインタブ

login tab

ログインページに forgot password リンクが表示されます。

Forgot Password リンク

forgot password link

このリンクをクリックすると、ユーザーはユーザー名またはメールに入力でき、リンクと共にメールを受信して認証情報をリセットできます。

Forgot Password ページ

forgot password page

電子メールで送信されたテキストは完全に設定可能です。関連するテーマを拡張または編集することのみが必要になります。詳細は、『サーバー開発者ガイド』を参照してください。

ユーザーがメールリンクをクリックすると、パスワードの更新が要求されます。OTP ジェネレーターが設定されていれば、再設定を求められます。電子メールで OTP ジェネレーターをリセットできない組織のセキュリティー要件によっては、電子メールで OTP ジェネレーターをリセットできない場合があります。この動作を変更するには、左側のメニュー項目 Authentication に移動し、Flows タブをクリックして Reset Credentials フローを選択します。

認証情報のリセットフロー

reset credentials flow

OTP をリセットしない場合は、Reset OTP の右側にある 無効 なラジオボタンを選択します。

注記

Update Password を Required Actions タブで有効にしたままにしてください。そうしないと、Forgot Password は機能しません。

5.2. Remember Me

ログインしているユーザーがブラウザーを閉じると、セッションは破棄され、再度ログインする必要があります。remember me チェックボックスを選択すればブラウザーが閉じられている場合でも、ログインしたままになるように設定することができます。これは基本的にセッションのみのクッキーから永続クッキーにログインクッキーを実行します。

この機能を有効にするには、左側のメニュー項目 Realm Settings に移動し、Login タブをクリックして Remember Me スイッチをオンにします。

ログインタブ

login tab

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

Remember Me

remember me

第6章 認証

レルムに認証を設定する際に認識する必要がある機能は複数あります。多くの組織には、パスワードと OTP ポリシーが厳しいため、管理コンソールの設定で有効にすることができます。また、認証に異なる認証情報タイプを必要としない場合もあります。Kerberos 経由でログインするオプションを指定するか、さまざまな組み込み認証情報タイプを無効にすることもできます。本章では、これらのトピックをすべて説明します。

6.1. パスワードポリシー

作成された各レルムには、パスワードポリシーが関連付けられていません。ユーザーは、必要時にパスワードをセキュリティー保護していない限り、短期間と設定できます。シンプルな設定は、Red Hat Single Sign-On を開発または学習しても問題ありませんが、実稼働環境では受け入れられません。Red Hat Single Sign-On には、管理コンソールで有効化できるパスワードポリシーのセットがあります。

左側のメニュー項目 Authentication をクリックし、Password Policy タブに移動します。右側のドロップダウンリストボックスに、追加するポリシーを選択します。これにより、画面の表にポリシーが追加されます。ポリシーのパラメーターを選択します。Save ボタンをクリックして変更を保存します。

パスワードポリシー

password policy

ポリシーを保存した後、ユーザー登録と更新パスワードが必要なアクションにより、新しいポリシーが強制的に実行されます。ポリシーチェックに失敗するユーザーの例:

失敗したパスワードポリシー

failed password policy

パスワードポリシーを更新したら、すべてのユーザーに更新 パスワード アクションを設定する必要があります。自動トリガーは、今後の拡張機能としてスケジュールされます。

6.1.1. パスワードポリシータイプ

以下は、各ポリシータイプについて説明します。

ハッシュアルゴリズム
パスワードはクリアテキストとして保存されません。代わりに、保存または検証する前に、標準のハッシュアルゴリズムを使用してハッシュ化されます。サポートされる値は pbkdf2、pbkdf2-sha256 および pbkdf2-sha512 です。
ハッシュ化のハッシュ
この値は、パスワードが格納または検証される前にハッシュ化される回数を指定します。デフォルト値は 27,500 です。このハッシュは、ハッカーがパスワードデータベースにアクセスするというまれなケースで実行されます。データベースへのアクセスを取得したら、元に戻すためのユーザーパスワードを元に戻します。CPU の電源が向上するため、このパラメーターに推奨される値は毎年変わります。ハッシュの反復値が高くなると、ハッシュのために CPU 能力が多くなり、パフォーマンスに影響する可能性があります。パフォーマンスやパスワードストアを保護する上で、より重要な内容を重み付けする必要があります。パスワードストアを保護するには、よりコスト効率の高い方法です。
数字
パスワード文字列に必要な数字の数。
小文字の文字
パスワード文字列に必要な小文字の数。
大文字文字
パスワード文字列に必要な大文字の数。
特殊文字
パスワード文字列に必要な '?!#%$' などの特殊文字の数。
ユーザー名なし
これが設定されている場合、パスワードはユーザー名と同じにすることはできません。
正規表現
パスワードが一致する必要がある 1 つ以上の正規表現パターン (java.util.regex.Patternで定義) を定義します。
パスワードを失効
パスワードが有効な日数。日数が経過したら、パスワードを変更する必要があります。
最近使用されていない
このポリシーは、以前のパスワードの履歴を保存します。格納される古いパスワードの数は設定可能です。ユーザーがパスワードを変更すると、保存されたパスワードは使用できません。
パスワードのブラックリスト
このポリシーは、特定のパスワード (小文字に変換) がブラックリストファイルに含まれているかどうかを確認します。これは、非常に大きなファイルである可能性があります。パスワードブラックリストは、Unix 行を持つ UTF-8 プレーンテキストファイルで、行はすべてブラックリスト化されたパスワードを表します。大文字と小文字を区別しない比較を容易にするために、ブラックリスト内のパスワードはすべて小文字である必要があります。ブラックリストファイルのファイル名はパスワードポリシーの値として指定する必要があります (例: 10_million_password_list_top_1000000.txt)。ブラックリストファイルは、デフォルトで ${jboss.server.data.dir}/password-blacklists/ に対して解決されます。このパスは、keycloak.password.blacklists.path システムプロパティーまたは passwordBlacklist ポリシー SPI 設定の blacklistsPath プロパティーを使用してカスタマイズできます。

6.2. OTP ポリシー

Red Hat Single Sign-On には、FreeOTP または Google Authenticator のワンタイムパスワードジェネレーターに設定できるポリシーが複数あります。左側のメニュー項目 Authentication をクリックし、OTP Policy タブに移動します。

OTP ポリシー

otp policy

ここで設定したポリシーは、ワンタイムパスワードの検証に使用されます。OTP を設定する際に、FreeOTP および Google Authenticator は、Red Hat Single Sign-On の OTP set up ページで生成される QR コードをスキャンします。このバーコードは、OTP Policy タブに設定した情報からも生成されます。

6.2.1. TOTP 対HOTP

OTP ジェネレーターには、以下の 2 つのアルゴリズムを選択できます。時間ベース (TOTP) と番号ベースの (HOTP)TOTP の場合は、トークンジェネレーターが現在の時間と共有の秘密をハッシュ化します。サーバーは、特定の期間内のハッシュと送信された値を比較することで OTP を検証します。そのため、TAOTP は短期間 (通常は 30 秒) にのみ有効です。HOTP では、共有カウンターの現在の時間ではなく、共有カウンターが使用されます。サーバーは、成功した各 OTP ログインでカウンターをインクリメントします。したがって、有効な OTP は、ログインに成功してからしか変更しません。

TOTP は、HOTP の OTP は不確定な時間に対して有効であり、一致可能な OTP は短期間にのみ有効であるため、より安全であると考えられます。HOTP は、ユーザーが時間間隔を稼働する前に OTP に入力する必要がないため、より使いやすいユーザーです。Red Hat Single Sign-On が TOTP に実装されている方法により、この区別がほとんど発生しなくなります。HOTP では、サーバーがカウンターを増やすたびにデータベースを更新する必要があります。負荷が大きい場合、認証サーバーでパフォーマンスが低下する可能性があります。そのため、より効率的な代替機能を提供するために、使用されるパスワードを記憶しません。これにより DB の更新は必要ありませんが、不利な点は TOTP が有効な時間間隔で再度使用される可能性があります。Red Hat Single Sign-On の今後のバージョンでは、TOTP が時間間隔で古い OTP をチェックするかどうかが予定されています。

6.2.2. TOTP 設定オプション

OTP ハッシュアルゴリズム
デフォルトは SHA1 です。より安全なオプションは SHA256 と SHA512 です。
診断の数
OTP はどれくらいですか?Short は、ユーザー入力が必要なため、ユーザーフレンドリーであることを意味します。より多くのセキュリティーを意味します。
Ahead Window の検索
サーバーを試行してハッシュと一致する間隔はどれくらいですか?これは、TOTP ジェネレーターまたは認証サーバーが同期しなくなった場合にだけ存在します。通常、デフォルト値は 1 で十分です。たとえば、新規トークンの期間が 30 秒間隔である場合、デフォルト値の 1 は、30 秒以内に有効なトークンのみを受け入れることを意味します。この設定値を増やすと、有効なウィンドウが 30 秒後に増えます。
OTP トークン期間
サーバーがハッシュと一致する間隔 (秒単位)。間隔がパスするたびに、新しい TOTP がトークンジェネレーターによって生成されます。

6.2.3. HOTP 設定オプション

OTP ハッシュアルゴリズム
デフォルトは SHA1 です。より安全なオプションは SHA256 と SHA512 です。
診断の数
OTP はどれくらいですか?Short は、ユーザー入力が必要なため、ユーザーフレンドリーであることを意味します。より多くのセキュリティーを意味します。
Ahead Window の検索
サーバーがハッシュを試して一致させるカウンターの数デフォルト値は 1 です。これは、ユーザーのカウンターがサーバーの先に近づくケースに対応するために存在します。これは、ユーザーが特定によって手動でカウンターを手動で増やすことが頻繁に発生する可能性があります。この値は、10 の値などに大きくする必要があります。
初期カウンター
初期カウンターの値

6.3. 認証フロー

認証フローは、ログイン、登録、およびその他の Red Hat Single Sign-On ワークフロー時に発生する必要のあるすべての認証、画面、およびアクションのコンテナーです。管理コンソールの左側のメニュー項目 Authentication に移動し、Flows タブに移動する場合は、システムにある定義されたフローをすべて表示し、各フローに必要なアクションを確認し、チェックすることができます。

6.3.1. 組み込みフロー

Red Hat Single Sign-On には、一定数のビルトインフローが含まれています。これらのフローを変更することはできませんが、ニーズに合わせて要件を変更できます。

本セクションでは、ビルトインのブラウザーログインフローの手順について説明します。左側のドロップダウンリストで、browser を選択し、以下の画面に移動します。

ブラウザーフロー

browser flow

フロー選択リストに右にあるヒント (tiny question mark) にマウスをかざすと、フローの内容を説明することになります。

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

6.3.1.1. 実行要件

必須
フローが正常に実行されると評価されるには、フローの必要な要素をすべて成功したものとして評価する必要があります。つまり、要素の 1 つが原因でフローが失敗するのでない限り、フローの Required 要素すべてが上部から順に実行される必要があります。ただし、これは現在のフローに対してのみ当てはまります。サブフロー内の Required 要素は、そのサブフローが入力した場合にのみ処理されます。
代替方法
フローに Alternative 要素のみが含まれる場合、フローが正常に実行されると評価するには、1 つの要素のみを評価する必要があります。フロー内の Required フロー要素はフローを成功としてマークできるため、Required フロー要素が含まれるフロー内の Alternative フロー要素は実行されません。この場合、機能的に Disabled になります。
Disabled
Disabled 要素は評価されず、フローが成功したとマーク付けするためにカウントされません。
条件
この要件タイプは、サブフローでのみ設定できます。Conditional のサブフローには「Condition」実行を含めることができます。これらの「Condition」の実行は論理ステートメントとして評価する必要があります。すべての "Condition" 実行が true と評価すると、ConditionalRequired としてサブフローが動作します。そうでない場合は、Conditional サブフローが Disabled として動作します。「Condition」実行が設定されていない場合、Conditional サブフローは Disabled として動作します。フローに「Condition」実行が含まれ、Conditions が Conditional に設定されていない場合は、「Condition」の実行は評価されず、機能的に Disabled とみなすことができます。

これは、例で説明する方が適切です。browser 認証フローを順番に説明します。

  1. 最初の認証タイプは Cookie です。ユーザーが初めてログインすると、セッションクッキーが設定されます。このクッキーがすでに設定されている場合、この認証タイプは成功します。この場合、Cookie プロバイダーによって成功が返され、フローのこのレベルの各実行が代替であるため、他の実行は実行されず、ログインに成功します。
  2. フローの 2 回目の実行は Kerberos の実行を確認します。このオーセンティケーターはデフォルトで無効になっており、スキップされます。
  3. 3 つ目の実行は、Identity Provider Redirector です。これは Actions > Config リンクを使用して設定し、アイデンティティーブローカー化用に別の IdP に自動的にリダイレクトします。
  4. 次回の実行は、Forms と呼ばれるサブフローです。このサブフローは 代替 としてマークされているため、Cookie 認証タイプが渡されると実行されません。このサブフローには、実行する必要がある追加の認証タイプが含まれます。このサブフローの実行がロードされ、同じ処理ロジックが発生します。
  5. Forms サブフローでの最初の実行は、Username Password Form です。この認証タイプにより、ユーザー名とパスワードがレンダリングされます。ユーザーは有効なユーザー名とパスワードに入力する必要があるため、required としてマークされます。
  6. Forms サブフローの 2 番目の実行は、新しいサブフロー (Browser - Conditional OTP サブフロー) です。このサブフローは conditional であるため、どのように実行されるかは Condition - User Configured 実行の評価の結果によって異なります。存在する場合は、このサブフローの実行がロードされ、同じ処理ロジックが発生します。
  7. 次回実行は Condition - User Configured です。これは、フローの他の実行がユーザーに設定されているかどうかを確認します。つまり、Browser - Conditional OTP サブフローは、ユーザーが OTP 認証情報が設定されている場合にのみ実行されることを意味します。
  8. 最終的な実行は OTP Form です。これは required とマークされますが、conditional サブフローの設定により、ユーザーが OTP 認証情報が設定されている場合にのみ実行されます。心当たりがない場合は、OTP フォームが見られません。

6.3.2. フローの作成

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

フローを作成するには、以下のいずれかを行います。

  1. 既存のフローをコピーし、変更します。これには、既存のフロー (Browser フローなど) を選択し、Copy ボタンを押します。これにより、作成する前に新しいフローの名前を設定するよう要求されます。
  2. ゼロから新しいフローを作成します。これを行うには、New ボタンを押します。これはより一般的なケースであるため、この例ではこれを使用します。

新しいフローを作成する場合、最上位のフローを作成する必要があります。

最上位フローの作成

Create top level flow

以下のオプションを使用します。

エイリアス
フローの名前。
説明
フローに設定できる説明。
最上位のフロータイプ
フローのタイプ。client タイプはクライアント (アプリケーション) の認証にのみ使用されます。その他の場合は、generic を選択します。

フローが作成されたら、New ボタンおよび Copy ボタンに加えて、DeleteAdd execution、および Add flow の準備を行います。

空の新規フロー

New flow

最後のフローは、フローとサブフローの構造、これらのフローの実行、サブフローおよび実行に設定した要件によって決まります。

実行は Add execution ボタンで追加できます。リセットメールを OTP を検証するためのリセットメールの送信から、実行にはさまざまなアクションを使用できます。Provider の横にあるツールチップ (tiny question mark) にマウスをかざすと、実行内容が説明されています。

認証実行の追加

Create authentication execution

これらは 自動実行インタラクティブな実行 に分割できます。自動実行Cookie の実行と似ていますが、フローで問題が発生した場合にそれらのアクションが自動的に実行されます。インタラクティブな実行 は、通常は一部のユーザー入力を取得するためにフローを停止します。正常に実行されると、success な状態になります。これはフローが成功したかどうかの一部であるため、これは重要になります。たとえば、空の Browser フローでは、誰でもログインできなくなります。そのためには、正常に評価された 1 つ以上の実行が必要になります。たとえば、入力されて送信されるユーザー名パスワードフォームなどがあります。

サブフローは、Add flow ボタンを使用してトップレベルのフローに追加できます。これにより、Create Execution Flow ページと非常に似た Create Top Level Form ページが開きます。唯一の違いは、Flow Typegeneric (前のように) または form のいずれかになります。form タイプは、組み込み Registration フローに対して行われる内容など、ユーザーの単一フォームを生成するサブフローを構築するために使用されます。サブフローは、実行に含まれる評価方法に応じて、正常に評価される特別な実行タイプです (これには、含まれるサブフローの評価が含まれます)。この評価のロジックは、各実行およびサブフローの要件によって異なります。

この内容の完全な理解には、フローの評価時に要件がどのように機能するかに関する詳細な説明が必要で、これはサブフローにも適用されます。詳細は、上記の実行要件セクションを参照してください。

実行を追加したら、Requirement が正しい値に設定されていることを確認します。必要が 1 つしかない場合でも、設定されない場合もあります。

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

最後に、実行の順序は重要であるため、名前の左側に設定されている上下ボタンで、実行とサブフローを各フロー内で上下に動かすことができます。

6.3.3. パスワードなしのブラウザーログインフローの作成

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

  • レルムを選択し、認証リンクをクリックします。
  • 「new」を選択し、新規フローに固有のエイリアス (つまり「Browser Password-less」)を付与します。
  • 「Add execution」を選択し、ドロップダウンを使用して「Cookie」を選択します。「Save」を押すと、Requirement を Alternative に設定します。
  • 「Add execution」を選択し、ドロップダウンメニューで「Kerberos」を選択します。
  • 「Add execution」を選択し、ドロップダウンを使用して「Identity Provider Redirector」を選択します。「Save」を押すと、Requirement を Alternative に設定します。
  • 「Add flow」を選択し、たとえば典型的なエイリアスを選択します。たとえば「Forms」です。「Save」を押すと、Requirement を Alternative に設定します。

ブラウザーフローの共通部分

Passwordless browser login common

  • 「Forms」サブフローの右側にある Actions メニューを使用して、「Add execution」を選択します。ドロップダウンを使用して「Username Form」を選択します。「Save」を押した後、その Requirement を Required に設定します。

Username フォームは「Browser」フローのユーザー名フォームと似ていますが、ユーザーはパスワードなしのログインを実行できるように、ユーザー名のみを要求します。ただし、これにより Red Hat Single Sign-On サーバーでユーザーの列挙攻撃が可能になります。これは、利便性に避けられないセキュリティーリスクであるため、フローではユーザーが入力すべきパスワードに推測する必要はないはずです。

  • 「Forms」サブフローの右側にある Actions メニューを使用して、「Add flow」を選択します。代表的なエイリアスを選択します。たとえば、「Authentication」となります。「Save」を押した後、その Requirement を Required に設定します。
  • 「Authentication」サブフローの右側にある Actions メニューを使用して、「Add execution」を選択します。ドロップダウンを使用して、「WebAuthn passwordless Authenticator」を選択します。「Save」を押すと、Requirement を Alternative に設定します。
  • 「 Authentication」サブフローの右側にある Actions メニューを使用して、「Add flow」を選択します。代表的なエイリアスを選択します。たとえば、「Password with OTP」です。「Save」を押すと、Requirement を Alternative に設定します。
  • 「Password with OTP」サブフローの右側にある Actions メニューを使用して、「Add execution」を選択します。ドロップダウンを使用して、「Password Form」を選択します。「Save」を押した後、その Requirement を Required に設定します。
  • 「Password with OTP」サブフローの右側にある Actions メニューを使用して、「Add execution」を選択します。ドロップダウンを使用して、「OTP Form」を選択します。「Save」を押した後、その Requirement を Required に設定します。
  • 「Bindings」メニューで、ブラウザーフローを「Browser」から「Browser Password-less」に変更します。

生成される最終フローは以下のとおりです。

パスワードなしのブラウザーログイン

Passwordless browser login

ユーザー名の入力後、このフローが機能する仕組みは以下のようになります。

  • ユーザーに WebAuthn パスワードレス認証情報が記録されている場合は、そのユーザーは、直接ログインするためにそれらを使用できます。これはパスワードなしのログインです。代わりに「Password with OTP」を選択できます。これは、"WebAuthn Passwordless" 実行と "Password with OTP" フローが Alternative に設定されているため、これを実行できます。Required に設定されている場合、ユーザーは WebAuthn、password、および OTP を入力する必要があります。
  • ユーザーが「WebAuthn パスワードレス」認証を使用して画面 で Try another way を選択する場合、ユーザーは「Password」と「Security Key」(WebAuthn パスワードレス) のいずれかを選択できます。パスワードを選択すると、ユーザーは 続行して、割り当てられた OTP とともにログインする必要があります。ユーザーに WebAuthn 認証情報がない場合は、最初にパスワードを入力し、続いて OTP を入力する必要があります。ユーザーが OTP 認証情報がない場合は、記録が要求されます。

WebAuthn パスワードレス実行は、Required ではなく Alternative に設定されているため、このフローではユーザーに WebAuthn 認証情報を登録するように要求されることはありません。ユーザーに Webauthn 認証情報を取得するには、そのユーザーに管理者が必要なアクションを追加する必要があります。最初に、Webauthn Register Passwordless が必要なアクションがレルムで有効になっていることを確認した後 (WebAuthn ドキュメンテーションを参照)、ユーザーの Credentials 管理メニューの Credential Reset を使用して必要なアクションを設定します。

このような高度なフローを複数作成すると、副次的な影響があります。たとえば、ユーザーのパスワードをリセットできるようにする必要がある場合は、パスワードフォームからアクセスが可能になります。デフォルトの「Reset Credentials」フローでは、ユーザーは自分のユーザー名を入力する必要があります。「Browser Password-less」フローですでにユーザー名をすでに入力されているため、Red Hat Single Sign-On では必要がなく、ユーザーエクスペリエンスの面ではサブ最適となります。これを修正するには、以下が可能になります。

  • 「Reset Credentials」フローをコピーし、「パスワードなしの認証情報の設定」など、その名前を設定します。
  • 「Choose user」実行の右側にある Actions メニューを使用して、「Delete」を選択します。
  • 「Bindings」メニューで、「Reset Credentials」から「Reset Credentials for password-less」に対するリセットの認証情報フローを変更します。

6.4. Kerberos

Red Hat Single Sign-On は、SPNEGO プロトコルを使用した Kerberos チケットによるログインをサポートします。SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) は、セッションのログイン時にユーザーの認証後に web ブラウザーを介して透過的に認証するために使用されます。非 Web ケース、またはログイン時にチケットが利用できない場合、Red Hat Single Sign-On は Kerberos ユーザー名/パスワードでのログインもサポートします。

Web 認証の一般的なユースケースは以下のとおりです。

  1. ユーザーはデスクトップにログインします (Active Directory ドメイン、または Kerberos 統合が有効になっている Linux マシンの Windows マシン)。
  2. その後、ユーザーはこのブラウザー (IE/Firefox/Chrome) を使用して、Red Hat Single Sign-On がセキュリティーを確保した Web アプリケーションにアクセスします。
  3. アプリケーションは、Red Hat Single Sign-On ログインにリダイレクトされます。
  4. Red Hat Single Sign-On により、HTML ログイン画面がステータス 401 および HTTP ヘッダー WWW-Authenticate: Negotiate でレンダリングされます。
  5. ブラウザーにデスクトップログインからの Kerberos チケットがあると、ブラウザーはヘッダー Authorization: Negotiate 'spnego-token' で Red Hat Single Sign-On にデスクトップサインオン情報を転送します。それ以外の場合は、ログイン画面が表示されます。
  6. Red Hat Single Sign-On はブラウザーからトークンを検証し、ユーザーを認証します。LDAP からユーザーデータをプロビジョニングします (LDAPFederationProvider と Kerberos 認証のサポートの場合)、またはユーザーがプロファイルを更新し、事前入力データ (KerberosFederationProvider の場合) を可能にします。
  7. Red Hat Single Sign-On はアプリケーションに返信します。Red Hat Single Sign-On とアプリケーションの通信は、OpenID Connect または SAML メッセージを通じて行われます。Red Hat Single Sign-On が Kerberos で認証されているということは、アプリケーションから非表示にされます。そのため、Red Hat Single Sign-On は Kerberos/SPNEGO ログインに対してブローカーとして機能します。

設定には主に 3 つの部分があります。

  1. Kerberos サーバー (KDC) の設定および設定
  2. Red Hat Single Sign-On サーバーの設定および設定
  3. クライアントマシンの設定および設定

6.4.1. Kerberos サーバーの設定

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

少なくとも以下が必要です。

  • Kerberos データベースにユーザープリンシパルを追加します。Kerberos と LDAP を統合することも可能です。つまり、ユーザーアカウントが LDAP サーバーからプロビジョニングされます。
  • HTTP サービスのサービスプリンシパルを追加します。たとえば、Red Hat Single Sign-On サーバーが www.mydomain.org で動作している場合、MYDOMAIN.ORG が Kerberos レルムであると仮定して、プリンシパル HTTP/www.mydomain.org@MYDOMAIN.ORG を追加しないといけない場合があります。

    たとえば、MIT Kerberos では「kadmin」セッションを実行できます。MIT Kerberos である同じマシンにある場合は、コマンドを簡単に使用できます。

sudo kadmin.local

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

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

Keytab ファイル /tmp/http.keytab は、Red Hat Single Sign-On サーバーが稼働しているホストでアクセスできる必要があります。

6.4.2. Red Hat Single Sign-On サーバーの設定および設定

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

[domain_realm]
  .mydomain.org = MYDOMAIN.ORG
  mydomain.org = MYDOMAIN.ORG

次に、HTTP プリンシパルで keytab ファイルをエクスポートし、Red Hat Single Sign-On サーバーが実行しているプロセスでファイルにアクセスできることを確認する必要があります。実稼働環境では、このプロセスによってのみ読み取り可能であり、その他のユーザーが行うことは理想的です。上記の MIT Kerberos の例では、キータブを /tmp/http.keytab にすでにエクスポートしています。KDC と Red Hat Single Sign-On が同じホストで実行されている場合は、このファイルがすでに利用可能な状態である。

6.4.2.1. SPNEGO 処理の有効化

Red Hat Single Sign-On には、デフォルトで SPNEGO プロトコルサポートが有効ではありません。そのため、ブラウザーフロー に移動して Kerberos を有効にする必要があります。

ブラウザーフロー

browser flow

Kerberos 要件を disabled から alternative または required のいずれかに切り替えます。Alternative とは基本的に、Kerberos が任意ということになります。ユーザーのブラウザーが SPNEGO/Kerberos と連携するように設定されていない場合は、Red Hat Single Sign-On は通常のログイン画面にフォールバックします。要件を required に設定すると、すべてのユーザーがそのブラウザーに Kerberos を有効にする必要があります。

6.4.2.2. Kerberos ユーザーストレージフェデレーションプロバイダーの設定

SPNEGO プロトコルが認証サーバーで有効になっているようになったので、Red Hat Single Sign-On が Kerberos チケットを解釈する方法を設定する必要があります。これは、ユーザーストレージのフェデレーション を使用して行います。Kerberos 認証をサポートする 2 つの異なるフェデレーションプロバイダーがあります。

LDAP サーバーがサポートする Kerberos で認証する場合は、最初に LDAP Federation Provider を設定する必要があります。LDAP プロバイダーの設定ページを確認する場合は、「Kerberos 統合」の項を参照してください。

LDAP Kerberos の統合

ldap kerberos

Allow Kerberos authentication スイッチをオンにすると、Red Hat Single Sign-On 環境は Kerberos プリンシパルを使用してユーザーに関する情報を検索し、Red Hat Single Sign-On 環境にインポートできるようにします。

Kerberos ソリューションが LDAP サーバーでサポートされていない場合は、Kerberos User Storage Federation Provider を使用する必要があります。左メニューアイテム User Federation に移動し、Add provider 選択ボックスから Kerberos を選択します。

Kerberos ユーザーストレージプロバイダー

kerberos provider

このプロバイダーは、簡単なプリンシパル情報の Kerberos チケットを解析し、ローカルの Red Hat Single Sign-On データベースに小規模なインポートを行います。ユーザー名、姓、メールなどのユーザープロファイルの情報はプロビジョニングされません。

6.4.3. クライアントマシンの設定および設定

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

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

6.4.4. 認証情報の委譲

Kerberos 5 は、認証情報の委譲の概念をサポートしています。このシナリオでは、アプリケーションを使用して Kerberos チケットを再使用して、Kerberos が保護された他のサービスと相互作用できるようになります。SPNEGO プロトコルは Red Hat Single Sign-On サーバーで処理されるため、GSS 認証情報を OpenID Connect トークンクレーム 内のアプリケーションまたは Red Hat Single Sign-On サーバーからアプリケーションに送信される SAML アサーション属性のいずれかに伝播する必要があります。この要求をトークンまたはアサーションに挿入するには、各アプリケーションは gss 委任認証情報 と呼ばれる組み込みプロトコルマッパーを有効にする必要があります。これは、アプリケーションのクライアントページの Mappers タブで有効にされます。詳細は、「プロトコルマッパー」の章を参照してください。

アプリケーションは、Red Hat Single Sign-On を使用して他のサービスに対して GSS 呼び出しを行う前に、受信する要求を Red Hat Single Sign-On からデシリアライズする必要があります。アクセストークンから GSSCredential オブジェクトに認証情報をデシリアライズしたら、以下のように GSSContext が GSSManager.createContext メソッドに渡される状態で作成される必要があります。

// 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);

krb5.conf ファイルで 転送可能 な kerberos チケットを設定し、委譲された認証情報のサポートをブラウザーに追加する必要があることに注意してください。

警告

認証情報の委譲にはセキュリティーへの影響があるため、必要性が及ぶ場合に限り使用してください。HTTPS と併用することが強く推奨されます。詳細は、「アプリケーションをシングルサインオン向けに設定」の例を参照してください。

6.4.5. レルム間の信頼

Kerberos V5 プロトコルでは、レルム は Kerberos データベース (通常は LDAP サーバー) で定義される Kerberos プリンシパルのセットです。Kerberos プロトコルには、レルム間の信頼の概念があります。たとえば、2 つの Kerberos レルム A および B がある場合、クロスレルム信頼は、レルム A からのユーザーがレルム B のリソース (サービス) にアクセスできるようにします。これは、レルム B がレルム A を信頼することを意味します。

Kerberos レルム間の信頼

kerberos trust basic

Red Hat Single Sign-On サーバーは、クロスレルム信頼のサポートを持ちます。そのためには、いくつかのことが必要になります。

  • レルム間の信頼用に Kerberos サーバーを設定します。この手順は、使用される具体的な Kerberos サーバー実装によって異なります。通常、Kerberos プリンシパル krbtgt/B@A をレルム A と B の Kerberos データベースの両方に追加する必要があります。このプリンシパルは両方の Kerberos レルムに同じ鍵を持つ必要があります。これは通常、プリンシパルに同じパスワード、キーバージョン番号があり、両方のレルムで使用される暗号が同じ場合に実現されます。詳細は、Kerberos サーバーのドキュメントを参照してください。
注記

レルム間の信頼は、デフォルトで一方向です。双方向の信頼でレルム A も信頼レルム B を割り当てる場合は、両方の Kerberos データベースにプリンシパル krbtgt/A@B も追加する必要があります。ただし、デフォルトでは trust は推移的です。レルム B がレルム A を信頼し、レルム C がレルム B を信頼する場合、レルム C はプリンシパル krbtgt/C@A が利用可能でなくてもレルム A を自動的に信頼します。クライアントが信頼パスを検索できるように、Kerberos クライアント側で追加の設定 (capathsなど) が必要になる場合があります。詳細は、Kerberos のドキュメントを参照してください。

  • Red Hat Single Sign-On サーバーの設定

    • Kerberos サポートのある LDAP ストレージプロバイダーを使用する場合は、HTTP/mydomain.com@B の例のようにレルム B のサーバープリンシパルを設定する必要があります。Red Hat Single Sign-On サーバーは SPNEGO フローを実行してからユーザーを見つける必要があるため、レルム A からのユーザーが Red Hat Single Sign-On に正常に認証される必要があるため、LDAP サーバーはレルム A からユーザーを見つけなければなりません。たとえば、kerberos プリンシパルユーザー john@A は、uid=john,ou=People,dc=example,dc=com などの LDAP DN の下にあるユーザーとして利用できるようにする必要があります。レルム A および B からのユーザーの両方を認証する場合は、LDAP がレルム A と B の両方からユーザーを検索できるようにする必要があります。今後のバージョンでこの制限を改善するため、別のレルム用にさらに別の LDAP プロバイダーを作成し、SPN が両方で動作することを確認する必要があります。
    • Kerberos ユーザーストレージプロバイダー (通常は LDAP 統合なしで Kerberos) を使用する場合は、サーバープリンシパルを HTTP/mydomain.com@B として設定する必要があります。また、Kerberos レルム A と B の両方が認証できるようにする必要があります。
警告

Kerberos ユーザーストレージプロバイダーでは、Kerberos レルム間でユーザーが競合しないようにすることが推奨されます。競合するユーザーが存在する場合は、同じ Red Hat Single Sign-On ユーザーにマッピングされます。これは、今後のバージョンで改善し、Kerberos プリンシパルから Red Hat Single Sign-On ユーザー名へのより柔軟なマッピングを提供します。

6.4.6. トラブルシューティング

問題が発生した場合には、追加のロギングを有効にして問題をデバッグすることが推奨されます。

  • Kerberos または LDAP フェデレーションプロバイダーについて、管理コンソールで Debug フラグを有効にする
  • standalone/configuration/standalone.xml のログセクションのカテゴリー org.keycloak に対して TRACE を有効にして、standalone/log/server.log をさらに受け取ります。
  • システムプロパティー -Dsun.security.krb5.debug=true および -Dsun.security.spnego.debug=true を追加します。

6.5. X.509 クライアント証明書ユーザー認証

サーバーが相互 SSL 認証用に設定されている場合、Red Hat Single Sign-On は、X.509 クライアント証明書を使用したログインをサポートします。

一般的なワークフローは以下のとおりです。

  • クライアントは SSL/TLS チャンネルで認証リクエストを送信します。
  • SSL/TLS ハンドシェイクの間、サーバーとクライアントは x.509/v3 証明書を交換します。
  • コンテナー (JBoss EAP) は、証明書 PKIX パスと証明書の有効期限を検証します。
  • X.509 クライアント証明書オーセンティケーターは、以下のようにクライアント証明書を検証します。

    • 必要に応じて、CRL や CRL ディストリビューション Points を使用して証明書失効リストのステータスを確認します。
    • オプションで OCSP (Online Certificate Status Protocol) を使用して証明書失効リストのステータスを確認します。
    • 必要に応じて、証明書の鍵の使用量が予想されるキー使用量と一致するかどうかを検証します。
    • 必要に応じて、証明書の拡張鍵の使用量が予想される拡張鍵の使用と一致するかどうかを検証します。
  • 上記のチェックのいずれかが失敗すると、x.509 認証が失敗します。
  • それ以外の場合は、オーセンティケーターは証明書 ID を抽出し、既存のユーザーにマップします。
  • 証明書が既存のユーザーにマッピングされると、認証フローに応じてさまざまな動作が行われます。

    • ブラウザーフローでは、サーバーはユーザーにアイデンティティーを確認するか、無視するよう指示し、代わりにユーザー名/パスワードでサインインします。
    • Direct Grant Flow の場合、サーバーがユーザーサインインします。

6.5.1. 機能

サポート対象の証明書 ID ソース
  • 正規表現を使用した SubjectDN の一致
  • X500 サブジェクトの e-mail 属性
  • X500 サブジェクトの件名拡張 (RFC822Name 一般名) からのメール
  • サブジェクトの別名エクステンションの X500 サブジェクトの他の名前。通常、これは UPN (User Principal Name) です。
  • X500 サブジェクトのコモンネーム属性
  • 正規表現を使用した IssuerDN の一致
  • 証明書のシリアル番号
  • Certificate Serial Number および IssuerDN
  • SHA-256 証明書サムプリント
  • PEM 形式の完全な証明書
正規表現
証明書アイデンティティーは、フィルターとして正規表現を使用してサブジェクト DN または Issuer DN から抽出できます。たとえば、以下の正規表現は e-mail 属性と一致します。
emailAddress=(.*?)(?:,|$)

正規表現のフィルターは、Identity Source が、Match SubjectDN using regular expression または Match IssuerDN using regular expression のいずれかに設定されている場合にのみ適用されます。

既存のユーザーへの証明書 ID のマッピング
証明書アイデンティティーのマッピングは、抽出したユーザー ID を既存のユーザーのユーザー名またはメールアドレスにマッピングするか、または証明書 ID に一致するカスタム属性にマッピングするように設定できます。たとえば、Identity sourceSubject’s e-mail に設定し、User mapping methodUsername or email に設定すると、X.509 クライアント証明書オーセンティケーターは、証明書の Subject DN の e-mail 属性を使用して、ユーザー名または電子メールで既存のユーザーを検索します。
重要

レルム設定で Login with email を無効にすると、同じルールが証明書認証に適用されることに注意してください。つまり、ユーザーは e-mail 属性を使用してログインできません。

重要

ID ソースに Certificate Serial Number and IssuerDN を使用するには、2 つのカスタム属性が必要です。1 つはシリアル番号の場合、もう 1 つは IssuerDN です。

重要

SHA-256 Certificate thumbprint は、SHA-256 証明書のサムプリントの小文字の 16 進数表示です。

重要

ID ソースとしての Full certificate in PEM format の使用は、LDAP などの外部フェデレーションソースにマッピングされたカスタム属性に限定されます。ただし、制限が長いため、Keycloak データベースには証明書を保存できないため、Always Read Value From LDAP を有効にする必要があります。

その他機能: 拡張証明書の検証
  • CRL を使用した状態チェックの取り消し
  • CRL/分散ポイントを使用した状態チェックの取り消し
  • OCSP/Responder URI を使用した状態チェックの取り消し
  • Certificate KeyUsage 検証
  • 証明書 ExtendedKeyUsage 検証

6.5.2. X.509 クライアント証明書のユーザー認証の有効化

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

JBoss EAP での相互 SSL の有効化

JBoss EAP で SSL を有効にする方法については、「SSL の有効化」を参照してください。

  • RHSSO_HOME/standalone/configuration/standalone.xml を開き、新しいレルムを追加します。
<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>
ssl/keystore
ssl 要素には、JKS キーストアからサーバーの公開鍵ペアを読み込む方法を定義する keystore 要素が含まれます。
ssl/keystore/path
JKS キーストアへのパス
ssl/keystore/relative-to
キーストアパスを起点としたパスを定義します
ssl/keystore/keystore-password
キーストアを開くためのパスワード
ssl/keystore/alias (オプション)
キーストアのエントリーのエイリアス。キーストアに複数のエントリーが含まれる場合にこれを設定します。
ssl/keystore/key-password (オプション)
秘密のキーパスワード (キーストアパスワードと異なる場合)。
authentication/truststore
トラストストアをロードして、インバウンド/ルーティング接続のリモート側に表示される証明書を検証する方法を定義します。通常、トラストストアには信頼される CA 証明書の集合が含まれます。
authentication/truststore/path
信頼される CA (認証局) の証明書を含む JKS キーストアへのパス
authentication/truststore/relative-to
トラストストアパスが相対するパスを定義します
authentication/truststore/keystore-password
トラストストアを開くパスワード
https リスナーの有効化

WildFly で HTTPS を有効にする方法については、「HTTPS リスナー」を参照してください。

  • 以下のように <https-listener> 要素を追加します。
<subsystem xmlns="urn:jboss:domain:undertow:10.0">
	....
    <server name="default-server">
	    <https-listener name="default"
                        socket-binding="https"
                        security-realm="ssl-realm"
                        verify-client="REQUESTED"/>
    </server>
</subsystem>
https-listener/security-realm
値は、前のセクションのレルムの名前に一致する必要があります。
https-listener/verify-client
REQUESTED に設定した場合、サーバーは必要に応じてクライアント証明書を要求します。属性を REQUIRED に設定すると、クライアント証明書が提供されない場合、サーバーが受信接続を拒否します。

6.5.3. X.509 クライアント証明書認証のブラウザーフローへの追加

  • レルムを選択し、認証リンクをクリックし、「Browser」フローを選択します。
  • 組み込み「参照」フローのコピーを作成します。新しいフローに区別のある名前を付けます。"X.509 Browser"
  • ドロップダウンを使用して、コピーしたフローを選択し、「実行の追加」をクリックします。
  • ドロップダウンリストから「X509/Validate Username Form」を選択し、「Save」をクリックします。

x509 execution

  • up/down arrows を使用して、「Browser Forms」実行の上に移動し、「X509/Validate Username Form」の順序を変更し、要件を「ALTERNATIVE」に設定します。

x509 browser flow

  • "Bindings" タブを選択し、「Browser Flow」のドロップダウンを見つけます。ドロップダウンメニューから新規作成された X509 ブラウザーフローを選択し、「Save」をクリックします。

x509 browser flow bindings

X.509 クライアント証明書認証の設定
x509 configuration
User Identity Source
クライアント証明書からユーザー ID を抽出する方法を定義します。
Canonical DN representation enabled (オプション)
正規の形式を使用して識別名を判断するかどうかを定義します。この形式は、公式の Java API ドキュメントで詳細に説明されています。このオプションは、2 つの Match SubjectDN using regular expression および Match IssuerDN using regular expression にのみ影響します。新しい Red Hat Single Sign-On インスタンスを設定する場合は、このオプションを有効にすることが推奨されます。既存の Red Hat Single Sign-On インスタンスとの互換性を保つため、このオプションは無効のままにします。
Enable Serial Number hexadecimal representation (オプション)
シリアル番号の 16 進数表現を使用するオプション。RFC5280, Section-4.1.2.2 を参照してください。記号ビット 1 に設定されたシリアル番号は、00 octet で囲まれている必要があります。例:10 進数値 161 のシリアル番号、または RFC5280 に準拠した 16 進数表示の a1 では、00a1 としてエンコードする必要があります。詳細は RFC5280, appendix-B を参照してください。
A regular expression (オプション)
証明書 ID を抽出するためにフィルターとして使用する正規表現を定義します。正規表現には単一のグループが含まれている必要があります。
User Mapping Method
証明書の ID を既存ユーザーに一致させる方法を定義します。ユーザー名またはメールアドレスは、ユーザー名またはメールアドレスで既存のユーザーを検索します。Custom Attribute Mapper は、証明書 ID に一致するカスタム属性を使用して既存のユーザーを検索します。カスタム属性の名前は設定可能です。
A name of user attribute (オプション)
証明書 ID に対して値と照合されるカスタム属性。属性マッピングが複数の値に関連している場合は、複数のカスタム属性に関連します。以下に例を示します。'Certificate Serial Number および IssuerDN'.
CRL Checking Enabled (オプション)
証明書失効リストを使用して、証明書の失効ステータスを確認するかどうかを定義します。
Enable CRL Distribution Point to check certificate revocation status (オプション)
CDP を使用して証明書失効リストのステータスを確認するかどうかを定義します。ほとんどの PKI 認証局には、証明書に CDP が含まれます。
CRL file path (オプション)
CRL リストを含むファイルへのパスを定義します。CRL Checking Enabled オプションをオンにする場合は、値を有効なファイルへのパスにする必要があります。
OCSP Checking Enabled(オプション)
Online Certificate Status Protocol を使用して証明書失効リストのステータスを確認するかどうかを定義します。
OCSP Responder URI (オプション)
証明書の OCSP レスポンダー URI の値を上書きできるようにします。
Validate Key Usage (オプション)
証明書の KeyUsage 拡張ビットが設定されているかどうかを確認します。たとえば、「digitalSignature,KeyEncipherment」は、KeyUsage 拡張のビット 0 と 2 がアサートされているかどうかを確認します。キー使用の検証を無効にするには、パラメーターを空欄のままにします。RFC5280, Section-4.2.13 を参照してください。サーバーは、発行元 CA が重要なものとしてフラグを付け、キー使用拡張機能の不一致のある場合にのみエラーを出します。
Validate Extended Key Usage (オプション)
Extended Key Usage 拡張機能で定義された 1 つ以上の目的を検証します。RFC5280, Section-4.2.1.12 を参照してください。Extended Key Usage の検証を無効にするには、パラメーターを空欄のままにします。サーバーは、発行元 CA が重要なものとしてフラグを付け、キー使用拡張機能の不一致のある場合にのみエラーを出します。
Bypass identity confirmation
設定されている場合、X.509 クライアント証明書認証により、証明書 ID の確認が求められず、認証に成功するとユーザーに自動的に署名されます。

6.5.4. X.509 クライアント証明書認証の Direct Grant Flow への追加

  • Red Hat Single Sign-On 管理コンソールを使用して、「Authentication」をクリックし、「Direct Grant」フローを選択します。
  • ビルドイン「Direct Grant」フローのコピーを作成します。新しいフローに区別のある名前を付けます。"X509 Direct Grant",
  • ユーザー名の検証およびパスワード "オーセンティケーターを削除します。
  • 「Add execution」をクリックし、「X509/Validate Username」を追加し、「Save」をクリックして実行ステップを親フローに追加します。

x509 directgrant execution

  • RequirementREQUIRED に変更します。

x509 directgrant flow

  • x.509 Browser Flow セクションで前述の手順に従って x509 認証設定を設定します。
  • "Bindings" タブを選択し、「Direct Grant Flow」のドロップダウンを見つけます。ドロップダウンメニューから新規作成された X509 ダイレクトグラントフローを選択し、「Save」をクリックします。

x509 directgrant flow bindings

6.5.5. クライアント証明書ルックアップ

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

ただし、Red Hat Single Sign-On サーバーがロードバランサーまたはリバースプロキシーの背後で HTTP 要求をリッスンする場合は、クライアント証明書を抽出し、相互 SSL 接続を確立するプロキシーサーバーである可能性があります。リバースプロキシーは通常、認証されたクライアント証明書を基盤のリクエストの HTTP ヘッダーに配置し、バックエンド Red Hat Single Sign-On サーバーに転送します。この場合、Undertow に対するため、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 プロバイダーとともに、haproxyapache の 2 つの組み込みプロバイダーもあります。これについては、以下で説明します。

6.5.5.1. HAProxy 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが HAProxy リバースプロキシーの背後に配置されると、このプロバイダーを使用できます。以下のようにサーバーを設定します。

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

この設定例では、クライアント証明書が HTTP ヘッダー、SSL_CLIENT_CERT、およびチェーンからの他の証明書が CERT_CHAIN_0CERT_CHAIN_1CERT_CHAIN_9 などの HTTP ヘッダーから検索されます。certificateChainLength はチェーンの最大長であるため、最後の試行属性は CERT_CHAIN_9 になります。

クライアント証明書およびクライアント証明書チェーンの HTTP ヘッダーとそれらの適切な名前を設定する方法の詳細は、HAProxy ドキュメントを参照してください。

6.5.5.2. Apache 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが Apache リバースプロキシーの背後にある場合は、このプロバイダーを使用できます。以下のようにサーバーを設定します。

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

この設定は、haproxy プロバイダーの場合と同じです。クライアント証明書およびクライアント証明書チェーンの HTTP ヘッダーとそれらの適切な名前を設定する方法については、mod_ssl および mod_headers の Apache ドキュメントを参照してください。

6.5.5.3. Nginx 証明書ルックアッププロバイダー

Red Hat Single Sign-On サーバーが Nginx リバースプロキシーの背後に配置されると、このプロバイダーを使用できます。以下のようにサーバーを設定します。

<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>
注記

NGINX SSL/TLS モジュールはクライアント証明書チェーンを公開しないため、Keycloak NGINX 証明書ルックアッププロバイダーが Keycloak トラストストアを使用して再ビルドされます。クライアント証明書チェーンを再構築するために必要なすべてのルートおよび中間 CA を持つ keytool CLI を使用して Keycloak トラストストアを設定してください。

クライアント証明書の設定方法については、NGINX のドキュメント を参照してください。NGINX 設定ファイルの例:

 ...
 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;
      ...
    }
    ...
}
注記

trusted-ca-list-for-client-auth.pem のすべての証明書を Keycloak トラストストアに追加する必要があります。

6.5.5.4. 他のリバースプロキシーの実装

他のリバースプロキシー実装に対する組み込みサポートはありません。ただし、apache または haproxy と同様の方法で、他のリバースプロキシーを動作させることができます。また、これらのプロバイダーも使用可能です。いずれも機能しなくなる場合、org.keycloak.services.x509.X509ClientCertificateLookupFactory および org.keycloak.services.x509.X509ClientCertificateLookup プロバイダーの独自の実装を作成しなければならない場合があります。独自のプロバイダーの追加方法については、『サーバー開発者ガイド』 を参照してください。

6.5.6. トラブルシューティング

HTTP ヘッダーのダンプ
Keycloak に送信されるリバースプロキシーを確認する場合は、Undertow フィルターである RequestDumpingHandler を有効にし、server.log ファイルを参照してください。
logging サブシステムで TRACE ロギングを有効化
...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:3.0">
...
            <logger category="org.keycloak.authentication.authenticators.x509">
                <level name="TRACE"/>
            </logger>
            <logger category="org.keycloak.services.x509">
                <level name="TRACE"/>
            </logger>
WARNING: Don't use RequestDumpingHandler or TRACE logging in production.
X.509 での直接認証
以下のテンプレートを使用して、Resource Owner Password Credentials Grant を使用してトークンを要求できます。
$ curl https://[host][:port]/auth/realms/master/protocol/openid-connect/token \
       --insecure \
       --data "grant_type=password&scope=openid profile&username=&password=&client_id=CLIENT_ID&client_secret=CLIENT_SECRET" \
       -E /path/to/client_cert.crt \
       --key /path/to/client_cert.key
[host][:port]
Direct Grant Flow を使用して x.509 クライアント証明書で認証できるように設定されたリモート Red Hat Single Sign-On サーバーのホストとポート番号。
CLIENT_ID
クライアント ID。
CLIENT_SECRET
機密クライアントの場合は、クライアントシークレットです。そうでなければ、空欄のままにします。
client_cert.crt
相互 SSL 認証でクライアントの ID を検証するために使用される公開鍵証明書。証明書は PEM 形式である必要があります。
client_cert.key
公開鍵のペアの秘密鍵。PEM 形式でも想定されます。

6.6. W3C Web 認証 (WebAuthn)

Red Hat Single Sign-On では、W3C Web 認証 (WebAuthn) のサポートは限定的です。Red Hat Single Sign-On は、WebAuthn の Relying Party (RP) として機能します。

注記

WebAuthn は テクノロジープレビュー であるため、完全にサポートされていません。この機能はデフォルトでは無効にされます。

-Dkeycloak.profile=preview または -Dkeycloak.profile.feature.web_authn=enabled でサーバーの起動を有効にするには、以下を行います、詳細は「プロファイル」を参照してください。

注記

WebAuthn 操作が成功するかどうかは、オーセンティケーター、ブラウザー、およびプラットフォームをサポートするユーザーの WebAuthn によって異なります。この WebAuthn サポートを使用する場合は、これらのエンティティーが WebAuthn 仕様をサポートするエクステントを明確にしてください。

6.6.1. setup

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

6.6.1.1. Webauthn Authenticator 登録の有効化

管理者は、Admin Console で以下の操作を実行します。

  • Authentication → Required Actions タブを開きます。
  • Register をクリックします。
  • Webauthn Register必要なアクション として選択します。
  • 有効 のチェックボックスにチェックを付けます。新規に作成されたユーザーをすべて WebAuthn 認証情報を登録する必要がある場合は、オプションで デフォルトのアクション チェックボックスにマークを付けます。

6.6.1.2. WebAuthn 認証のブラウザーフローへの追加

  • レルムを選択し、Authentication のリンクをクリックし、ブラウザーフローを選択します。
  • 組み込み「参照」フローのコピーを作成します。新しいフローに、"WebAuthn Browser" など、区別的な名前を付けてください。
  • ドロップダウンを使用して、コピーしたフローを選択します。
  • Actions メニューを使用して WebAuthn Browser Browser - Conditional OTP サブフローを削除します。

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

  • WebAuthn Browser FormsActions メニューを使用して、Add execution をクリックします。
  • ドロップダウンを使用して WebAuthn Authenticator を選択し、Save をクリックします。
  • Requirement を Required に設定します。

webauthn browser flow required

  • Bindings メニューで、ブラウザーフローを WebAuthn ブラウザー に変更します。

このシナリオでは、ユーザーに WebAuthn 認証情報がない場合は、そのユーザーが強制的に登録するように必要なアクションが設定されることに注意してください。

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

  • WebAuthn Browser FormsActions メニューを使用して、Add flow をクリックします。
  • エイリアスを「Conditional 2FA」に設定し、Save をクリックします。
  • Conditional 2FA の要件を Conditional に設定します。
  • Conditional 2FAActions メニューを使用して、Add executionをクリックします。
  • ドロップダウンを使用して Condition - User Configured を選択し、Save をクリックします。
  • Condition - User Configured の要件を Requiredに設定します。
  • Conditional 2FAActions メニューを使用して、Add executionをクリックします。
  • ドロップダウンを使用して WebAuthn Authenticator を選択し、Save をクリックします。
  • Requirement を Alternative に設定します。

webauthn browser flow conditional

また、WebAuthn と OTP を使用して、2 番目の係数の使用を選択することもできます。

  • Conditional 2FAActions メニューを使用して、Add executionをクリックします。
  • ドロップダウンを使用して OTP Form を選択し、Save をクリックします。
  • Requirement を Alternative に設定します。

webauthn browser flow conditional with OTP

6.6.2. WebAuthn Authenticator での認証

WebAuthn オーセンティケーターを登録した後、ユーザーは WebAuthn Authenticator を使用して条件付きサブフローで上記の認証フロー設定が使用されていることを前提としています。

  • ログインフォームを開きます。ユーザーは、ユーザー名とパスワードで認証する必要があります。
  • ユーザーのブラウザーは、WebAuthn オーセンティケーターによる認証をユーザーに要求します。

6.6.3. 管理者として WebAuthn の管理

6.6.3.1. 認証情報の管理

WebAuthn の認証情報は、ユーザー認証情報管理 から OTP などの他の認証情報と同様に管理されます。

  • ユーザーには必要なアクションを割り当て 、Reset Actions リストから WebAuthn 認証情報を作成し、Webauthn Register を選択します。
  • 管理者は、Delete を押すと WebAuthn 認証情報を削除できます。
  • 管理者は Show data…​ を選択して、AAGUID などの認証情報のデータを表示できます。
  • 管理者は、User Label フィールドに値を設定し、データを保存することで、認証情報のラベルを設定できます。

6.6.3.2. ポリシーの管理

管理者は、WebAuthn 関連の操作をレルムごとに WebAuthn Policy として設定できます。

管理者は、Admin Console で以下の操作を実行します。

  • Authentication → WebAuthn Policy タブを開きます。
  • 項目を設定し、Save をクリックします。

設定可能な項目とその説明を以下に示します。

設定説明

エンティティー名の使用

人間が判読できるサーバー名を WebAuthn Relying Party として実行します。これは、WebAuthn オーセンティケーターの登録の操作に適用される必須の設定です。デフォルト設定は「keycloak」です。詳細は、「WebAuthn Specification」を参照してください。

署名アルゴリズム

これは、認証アセンション の署名および検証に使用できる 公開鍵認証情報 に使用する署名アルゴリズムを WebAuthn オーセンティケーターに指示します。複数のアルゴリズムを指定できます。アルゴリズムが指定されていない場合は、ES256 が適合します。デフォルト設定は ES256 です。これは、WebAuthn オーセンティケーターの登録の操作に適用される任意の設定アイテムです。詳細は、「WebAuthn Specification」を参照してください。

パート ID の使用

これは、WebAuthn Relying Party として ID で、公開鍵の認証情報の範囲を決定します。これは、オリジンの有効なドメインでなければなりません。これは、WebAuthn オーセンティケーターの登録の操作に適用される任意の設定アイテムです。エントリーを入力しないと、Red Hat Single Sign-On サーバーのベース URL のホストの部分が適用されます。詳細は、「WebAuthn Specification」を参照してください。

証明の伝達設定

これは、ブラウザー (WebAuthn クライアント)で WebAuthnAPI 実装に、Attestation ステートメントの生成方法の優先度を指示します。これは、WebAuthn オーセンティケーターの登録の操作に適用される任意の設定アイテムです。オプションが選択されていない場合、その動作は「none」の選択と同じになります。詳細は、「WebAuthn Specification」を参照してください。

オーセンティケーター添付

これは、WebAuthn オーセンティケーターの許容割り当てパターンを WebAuthn Client に伝えます。これは、WebAuthn オーセンティケーターの登録の操作に適用される任意の設定アイテムです。このオプションが選択されていない場合、WebAuthn Client はアタッチメントパターンを考慮しません。詳細は、「WebAuthn Specification」を参照してください。

識別キーが必要

これは WebAuthn オーセンティケーターに対し、公開鍵認証情報を クライアント側の公開鍵認証情報ソース として生成するよう指示します。これは、WebAuthn オーセンティケーターの登録の操作に適用される任意の設定アイテムです。オプションが選択されていない場合、その動作は「No」を選択するのと同じになります。詳細は、「WebAuthn Specification」を参照してください。

ユーザー検証要件

WebAuthn オーセンティケーターに対して、ユーザーが実際に検証されていることを確認するように指示します。これは、WebAuthn オーセンティケーターの登録と認証の操作に適用される任意の設定アイテムです。オプションが選択されていない場合、その動作は「推奨」を選択することと同じになります。詳細は、「WebAuthn Specification for registering a WebAuthn authenticator」および「WebAuthn Specification for authenticating the user by a WebAuthn authenticator」を参照してください。

タイムアウト

WebAuthn オーセンティケーターに登録し、WebAuthn オーセンティケーターでユーザーを認証するタイムアウト値を秒単位で指定します。0 に設定した場合は、WebAuthn オーセンティケーターの実装によって異なります。デフォルト値は 0 です。詳細は、「WebAuthn Specification for registering a WebAuthn authenticator」および「WebAuthn Specification for authenticating the user by a WebAuthn authenticator」を参照してください。

同じオーセンティケーター登録の回避

「ON」に設定すると、登録済みの WebAuthn オーセンティケーターが登録できません。これは、WebAuthn オーセンティケーターの登録の操作に適用されます。デフォルト設定は「OFF」です。

許可される AAGUID

WebAuthn オーセンティケーターを登録することができる AAGUID のホワイトリストこれは、WebAuthn オーセンティケーターの登録の操作に適用されます。このリストにエントリーが設定されていない場合は、すべての WebAuthn オーセンティケーターを登録できます。

6.6.4. 調整ステートメントの検証

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

attestation statement trustworthiness 検証を省略する場合は、このトラストストアを無効にするか、WebAuthn ポリシーの設定アイテム "Attestation Conveyance Preference" を "none" に設定してください。

6.6.5. ユーザーとして WebAuthn 認証情報の管理

6.6.5.1. WebAuthn Authenticator の登録

WebAuthn オーセンティケーターを登録する適切な方法は、ユーザーが Red Hat Single Sign-On にアカウントを登録しているかどうかによって異なります。

新規ユーザー

WebAuthn Register 必須の操作をレルムで Default Action として設定している場合、最初のログインに成功すると WebAuthn セキュリティーキーの設定に新しいユーザーが必要になります。新規ユーザーは以下の操作を実行します。

  • ログインフォームを開きます。
  • Register リンクをクリックします。
  • 登録フォームに項目を入力し、Register をクリックします。
  • ユーザーのブラウザーは、WebAuthn オーセンティケーターを登録するようユーザーに要求します。
  • 登録に成功すると、ユーザーのブラウザーは、登録済み WebAuthn オーセンティケーターのラベルとしてテキストを入力するよう要求します。
既存ユーザー

最初の例のように WebAuthn Authenticator が必要に応じて設定されている場合、既存のユーザーがログインを試みる際に、WebAuthn オーセンティケーターを自動的に登録する必要があります。

  • ログインフォームを開きます。
  • 項目を入力し、Save をクリックして Login をクリックします。
  • ユーザーがログインしたら、WebAuthn オーセンティケーターを登録する必要があります。
  • 登録に成功すると、ユーザーのブラウザーは、登録済み WebAuthn オーセンティケーターのラベルとしてテキストを入力するよう要求します。

6.6.6. パスワードなしの WebAuthn と 2 つのファクターの組み合わせ

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

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

このような状況では、Red Hat Single Sign-On により、管理者は個別の WebAuthn パスワードレスポリシー を設定できます。別の認証タイプ WebAuthn Passwordless Authenticator と、別の必須アクションのタイプWebauthn Register Passwordless があります。

6.6.6.1. setup

WebAuthn パスワードレスサポートのセットアップ手順は、以下のとおりです。

  • WebAuthn パスワードレスサポートに必要な新しいアクションを登録します。Webauthn Register Passwordless パスワードレスというアクションを登録する必要がある唯一の違いは、上記 の手順と同じ手順を使用してください。
  • ポリシーを設定します。上記 の手順と設定オプションは同じですが、WebAuthn Passwordless Policy タブ の管理コンソールで設定する必要があります。このポリシーを必要に応じて設定できますが、通常、2 要素ポリシーよりもセキュリティーキーの要件はより強力になります。たとえば、パスワードレスポリシーの設定時に、User Verfication ReuqirementRequired に設定できます。
  • 最後に認証フローを設定します。上記の説明にあるように WebAuthn Browser と同じフローを使用すると仮定します。ただし、以下のように設定します。

    • WebAuthn ブラウザー サブフローには、最初のオーセンティケーターとして ユーザー名フォーム が含まれます。デフォルトの Username Password Form オーセンティケーターを削除し、代わりに Username Form オーセンティケーターを追加します。この設定は、最初のステップとしてユーザーがユーザー名を提供することを意味します。
    • 必要なサブフロー (Passwordless Or Two-factor 等) があります。この設定は、Passwordless WebAuthn 認証情報または Two-factor 認証のいずれかで認証できることを示しています。
    • フローには、最初の代替 WebAuthn Passwordless Authenticator が含まれます。
    • 2 つ目の代替は、Password And Two-factor Webauthn などのサブフローです。このサブフローには、Password FormWebAuthn Authenticator が含まれます。

フローの最後の設定は以下のようになります。

webauthn passwordless flow

Red Hat Single Sign-On にすでに知られている一部のユーザーに、必要なアクションとして WebAuthn Register Passwordless を追加してテストできるようになりました。最初の認証時に、ユーザーはパスワードおよび二次的な WebAuthn 認証情報を使用する必要があります。ただし、ユーザーが認証情報を登録すると、そのユーザーは今後の認証時に選択できます。WebAuthn パスワードレス認証情報を使用する場合は、パスワードと 2 要素 WebAuthn 認証情報を指定する必要はありません。

第7章 SSO プロトコル

本章では、認証プロトコルの概要と、Red Hat Single Sign-On 認証サーバーの概要と、そのプロトコルをセキュアにするアプリケーションについて概説します。

7.1. OpenID Connect

OpenID Connect (OIDC) は、OAuth 2.0 の拡張機能である認証プロトコルです。OAuth 2.0 は承認プロトコルを構築するためのフレームワークでしかなく、主に不完全ですが、OIDC は完全な認証および承認プロトコルです。OIDC は、JWT (Json Web Token) 標準セットも多用しています。これらの標準は、アイデンティティープロバイダーの JSON 形式を定義し、そのデータをコンパクトで Web フレンドリーで暗号化する方法を定義しています。

OIDC を使用する場合は、本当に 2 つのタイプのユースケースがあります。1 つ目のアプリケーションは、Red Hat Single Sign-On サーバーがユーザーを認証するよう依頼するアプリケーションです。ログインに成功すると、アプリケーションは ID トークンアクセストークン を受け取ります。ID トークン には、ユーザー名、電子メール、その他のプロファイル情報など、ユーザーに関する情報が含まれています。アクセストークン はレルムによってデジタル署名され、アプリケーションでユーザーがアクセスできるリソースを判別するためにアプリケーションが使用できるアクセス情報 (ユーザーロールマッピングなど) が含まれます。

2 つ目のタイプのユースケースは、リモートサービスへのアクセスを取得するクライアントのものです。この場合、クライアントはユーザーの代わりに他のリモートサービスで起動するのに使用できる アクセストークン を取得するよう Red Hat Single Sign-On に要求します。Red Hat Single Sign-On はユーザーを認証し、ユーザーに要求したクライアントにアクセスを付与するよう依頼します。その後、クライアントは アクセストークン を受け取ります。この アクセストークン はレルムによってデジタル署名されます。クライアントはこの アクセストークン を使用してリモートサービスで REST 呼び出しを行うことができます。REST サービスは、アクセストークン を抽出し、トークンの署名を検証した後、トークン内のアクセス情報に基づいて、リクエストを処理するかどうかを決定します。

7.1.1. OIDC 認証フロー

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

7.1.1.1. 認可コードフロー

これはブラウザーベースのプロトコルであり、ブラウザーベースのアプリケーションの認証および承認に使用することが推奨されるものです。大量のブラウザーのリダイレクトを使用してアイデンティティーおよびアクセストークンを取得します。以下は簡単な概要です。

  1. ブラウザーはアプリケーションにアクセスします。このアプリケーションはユーザーがログインしていないことを認識し、ブラウザーを Red Hat Single Sign-On にリダイレクトして認証されます。アプリケーションは、このブラウザーリダイレクトのクエリーパラメーターとしてコールバック URL (リダイレクト URL) を渡します。このブラウザーリダイレクトでは、認証が終了すると Red Hat Single Sign-On が使用するようになります。
  2. Red Hat Single Sign-On がユーザーを認証し、1 回限り非常に短い一時的なコードを作成します。Red Hat Single Sign-On は、先に提供されたコールバック URL を使用してアプリケーションにリダイレクトし、さらに一時コードをコールバック URL にクエリーパラメーターとして追加します。
  3. アプリケーションは一時コードを抽出し、Red Hat Single Sign-On に帯域外 REST 呼び出しをバックグラウンドにし、アイデンティティーアクセスリフレッシュ トークンのコードを交換します。この一時的なコードはトークンを取得する一度使用した後、再度使用することができません。これにより、再生攻撃を防ぐことができます。

アクセストークンは通常、生み上回り、分単位で有効期限が切れてから期限切れになることに留意することが重要です。ログインプロトコルによって送信された追加のリフレッシュトークンにより、アプリケーションは有効期限が切れた後に新しいアクセストークンを取得できます。危険にさらされたシステムの状況では、この更新プロトコルが重要になります。アクセストークンの有効期間が短くなると、システム全体がアクセストークンの有効期間中は盗難トークンしか脆弱になります。admin のアクセスが取り消されると、今後の更新トークン要求は失敗します。これにより、より安全でより拡張性が高まります。

このフローのもう 1 つの重要な点として、パブリック機密性 のあるクライアントの概念があります。トークンの一時コードを交換する際にクライアントシークレットを提供するには、Confidential クライアントが必要です。パブリッククライアントは、このクライアントシークレットを提供するのには必要ありません。パブリッククライアントは、HTTPS が厳密に強制され、クライアントに登録されているリダイレクト URI が非常に厳格である限り問題ありません。クライアントシークレットをセキュアに送信する方法がないため、HTML5/JavaScript クライアントは常に public クライアントである必要があります。この場合も問題ありません。したがって、HTTPS を使用し、リダイレクト URI 登録を厳密に強制する限り問題となります。本ガイドは、『クライアントの管理』の章で詳しく説明しています。

Red Hat Single Sign-On は、任意の Proof Key for Code Exchange もサポートします。

7.1.1.2. インプリシットフロー

これは、リクエストが少なく、更新トークンがないこと以外は Authorization Code Flow に類似したブラウザーベースのプロトコルです。アクセス トークンがリダイレクト URI 経由で送信されるため、ブラウザー履歴でリークされる可能性が残るため、このフローは推奨しません (以下を参照)。また、このフローは更新トークンでクライアントを提供しないため、アクセストークンは有効期間が長くなるか、ユーザーの有効期限が切れたときに再認証する必要があります。このフローは OIDC および OAuth 2.0 仕様にあるためサポートされます。以下は、プロトコルの概要です。

  1. ブラウザーはアプリケーションにアクセスします。このアプリケーションはユーザーがログインしていないことを認識し、ブラウザーを Red Hat Single Sign-On にリダイレクトして認証されます。アプリケーションは、このブラウザーリダイレクトのクエリーパラメーターとしてコールバック URL (リダイレクト URL) を渡します。このブラウザーリダイレクトでは、認証が終了すると Red Hat Single Sign-On が使用するようになります。
  2. Red Hat Single Sign-On はユーザーを認証し、identity および access トークンを作成します。Red Hat Single Sign-On は、先に提供されたコールバック URL を使用してアプリケーションにリダイレクトし、さらにコールバック URL のクエリーパラメーターとして identity および access トークンを追加します。
  3. アプリケーションはコールバック URL から identity および access トークンを抽出します。

7.1.1.3. リソースオーナーパスワードクレデンシャルの付与 (直接アクセスグラント)

これは、管理コンソールで Direct Access Grants と呼ばれます。これは、ユーザーの代わりにトークンを取得する REST クライアントによって使用されます。HTTP POST リクエストには、ユーザーの認証情報とクライアントの ID (機密クライアントの場合) が含まれる HTTP POST リクエストがあります。ユーザーの認証情報は、フォームパラメーター内で送信されます。HTTP 応答には、identityaccess、および refresh トークンが含まれます。

7.1.1.4. クライアント認証情報の付与

これは REST クライアントでも使用しますが、外部ユーザーの代わりに機能するトークンを取得する代わりに、クライアントに関連するサービスアカウントのメタデータおよびパーミッションに基づいてトークンが作成されます。例と詳細な情報は、「サービスアカウント」の章を参照してください。

7.1.2. Red Hat Single Sign-On Server OIDC URI エンドポイント

以下は、Red Hat Single Sign-On がパブリッシュする OIDC エンドポイントの一覧です。これらの URL は、Red Hat Single Sign-On 以外のクライアントアダプターを使用して、認証サーバーと OIDC と通信させる場合に便利です。これらはすべて相対 URL と HTTP(S) プロトコル、hostname、通常は /auth で始まるパスである URL のルートです (例: https://localhost:8080/auth)。

/realms/{realm-name}/protocol/openid-connect/auth
これは、Authorization Code Flow で一時的なコードを取得する URL エンドポイントです。または、Implicit Flow、Direct Grants、または Client Grants でトークンを取得する URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/token
これは、一時コードをトークンに変換する Authorization Code Flow の URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/logout
これは、ログアウトを実行するための URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/userinfo
これは、OIDC 仕様で説明されている User Info サービスの URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/revoke
これは、RFC7009 に記載されている OAuth 2.0 Token Revocation の URL エンドポイントです。

これらはすべて、 {realm-name} をレルムの名前に置き換えます。

7.2. SAML

SAML 2.0 は OIDC と同様の仕様ですが、より古く、より成熟したものです。SOAP と plethora の WS-* 仕様にはルートがあるため、OIDC よりも詳細度が少しなる傾向があります。SAML 2.0 は主に、認証サーバーとアプリケーション間の XML ドキュメント変更によって機能する認証プロトコルです。XML 署名と暗号化は、要求と応答の検証に使用されます。

SAML を使用する場合は、主に 2 つのタイプのユースケースがあります。1 つ目のアプリケーションは、Red Hat Single Sign-On サーバーがユーザーを認証するよう依頼するアプリケーションです。ログインが成功すると、アプリケーションには、ユーザーのさまざまな属性を指定する SAML アサーションが含まれる XML ドキュメントを受け取ります。XML ドキュメントはレルムによってデジタル署名され、アプリケーションでユーザーがアクセスできるリソースを判別するためにアプリケーションが使用できるアクセス情報 (ユーザーロールマッピングなど) が含まれます。

2 つ目のタイプのユースケースは、リモートサービスへのアクセスを取得するクライアントのものです。この場合、クライアントはユーザーの代わりに他のリモートサービスで起動するのに使用できる SAML アサーションを取得するよう Red Hat Single Sign-On に要求します。

7.2.1. SAML バインディング

SAML は、認証プロトコルの実行時に XML ドキュメントを交換するさまざまな方法を定義します。Redirect および Post のバインディングはブラウザーベースのアプリケーションに対応します。ECP バインディングは、REST 呼び出しに対応します。他のバインディングタイプがありますが、Red Hat Single Sign-On はこれら 3 つのみをサポートします。

7.2.1.1. リダイレクトバインディング

Redirect バインディングは一連のブラウザーリダイレクト URI を使用して情報を交換します。これは、その仕組みの概要です。

  1. ユーザーがアプリケーションにアクセスでき、アプリケーションによってユーザーが認証されないことが検索されます。これは XML 認証リクエストドキュメントを生成し、これを Red Hat Single Sign-On サーバーにリダイレクトするために使用される URI で query param としてエンコードします。設定によっては、アプリケーションはこの XML ドキュメントにデジタル署名し、この署名をリダイレクト URI の Red Hat Single Sign-On へのクエリーパラメーターとしても使用できます。この署名は、このリクエストを送信したクライアントの検証に使用されます。
  2. ブラウザーが Red Hat Single Sign-On にリダイレクトされます。サーバーは XML 認証要求のドキュメントを抽出し、必要に応じてデジタル署名を検証します。ユーザーは、認証されるクレデンシャルに入力する必要があります。
  3. 認証後、サーバーは XML 認証応答ドキュメントを生成します。このドキュメントには、名前、アドレス、電子メールなどのユーザーに関するメタデータを保持する SAML アサーションが含まれ、ユーザーが持つ可能性のあるロールマッピングが含まれます。このドキュメントはほぼ常に XML 署名を使用してデジタル署名されており、暗号化される可能性もあります。
  4. その後、XML 認証応答ドキュメントは、ブラウザーをアプリケーションに戻すリダイレクト URI でクエリーパラメーターとしてエンコードされます。デジタル署名は、クエリーパラメーターとしても含まれています。
  5. アプリケーションはリダイレクト URI を受け取り、XML ドキュメントを展開してレルムの署名を検証し、有効な認証応答を受信していることを確認します。その後、SAML アサーション内の情報を使用して、アクセスの決定やユーザーデータの表示に使用されます。

7.2.1.2. POST バインディング

SAML POST バインディングは、Redirect バインディングとほぼ同じように動作しますが、GET リクエストの代わりに XML ドキュメントは POST リクエストによって交換されます。POST バインディングは JavaScript を使用してブラウザーを漏洩し、ドキュメント交換時に Red Hat Single Sign-On サーバーまたはアプリケーションへの POST リクエストを行います。基本的には、HTTP 応答には、埋め込み JavaScript のある HTML 形式が含まれる HTML ドキュメントが含まれています。ページが読み込まれると、JavaScript は自動的にフォームを呼び出します。本当にこのお気に入りについて把握する必要はありませんが、これは非常に分かりやすくなります。

通常、POST バインディングはセキュリティーおよびサイズの制限により推奨されます。REDIRECT を使用する場合、SAML 応答は URL の一部となる (以前説明されるようにクエリーパラメーターですが) 、ログ内でキャプチャーされ、安全性は少なくなる可能性があります。サイズに関しては、アサーションが多くの属性または大きな属性を含んでいる場合、HTT Pペイロード内で文書を送信することは、より制限された URL 内よりも常に優れています。

7.2.1.3. ECP

ECP は「Enhanced Client or Proxy」、SAML v.2.0 プロファイルを表します。これにより、Web ブラウザーのコンテキスト外にある SAML 属性を交換できます。これは、REST または SOAP ベースのクライアントで最もよく使用されます。

7.2.2. Red Hat Single Sign-On Server SAML URI エンドポイント

Red Hat Single Sign-On には、すべての SAML 要求に対してエンドポイントは 1 つしかありません。

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

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

7.3. OpenID Connect 対SAML

OpenID Connect と SAML の選択は、古い成熟したプロトコル(SAML)の代わりに新しいプロトコル (OIDC) を使用する場合でも問題はありません。

多くの場合、Red Hat Single Sign-On では、OIDC の使用を推奨します。

SAML は OIDC よりも詳細な状態である傾向があります。

交換されたデータの詳細レベルを超えた場合、SAML は Web で機能するように OIDC が Web で機能するように設計されている仕様を比較すると、Web 上で動作するように調整されました。たとえば、OIDC は、SAML よりもクライアント側に簡単に実装できるため、HTML5/JavaScript アプリケーションにも適しています。トークンは JSON 形式であるため、JavaScript による使いやすさが簡単です。また、Web アプリケーションでセキュリティーを実装するためにより優れた機能もいくつかあります。たとえば、ユーザーがログインしたままかどうかを簡単に判断するために仕様で使用されている iframe における効果的な方法 を確認してください。

SAML がその使い方もあります。OIDC 仕様が進化したように、SAML で数年以上の機能を実装することがわかります。多くの場合は、成熟度が高いため、またそれらにはセキュリティーを確保した既存のアプリケーションがすでにあるため、SAML over OIDC を選択していることがよく見られます。

7.4. Docker Registry v2 認証

注記

Docker 認証はデフォルトで無効になっています。有効にするには、「プロファイル」を参照してください。

Docker レジストリー V2 認証は、Docker レジストリーに対してユーザーを認証するために使用される OIDC-Like プロトコルです。Red Hat Single Sign-On のこのプロトコルにより、Docker クライアントによって使用される Red Hat Single Sign-On 認証サーバーに対してレジストリーに対して認証を行うことができます。このプロトコルはかなりの標準的なトークンと署名メカニズムを使用しますが、それが真の OIDC 実装として処理されないようにすることを防ぐ欠点があります。最高の相違には、要求および応答用に非常に具体的な JSON 形式が含まれており、リポジトリー名とパーミッションを OAuth スコープメカニズムにマッピングする方法を理解することができます。

7.4.1. Docker 認証フロー

Docker API ドキュメントの概要は、このプロセスについて説明していますが、Red Hat Single Sign-On 認証サーバーの視点では、簡単な概要が提供されます。

注記

このフローは、docker login コマンドがすでに実行されていることを前提としています。

  • このフローは、Docker クライアントが Docker レジストリーからリソースを要求すると開始します。リソースが保護され、要求に認証トークンがない場合、Docker レジストリーサーバーは 401 と必要なパーミッションと認可サーバーの一部の情報でクライアントに応答します。
  • Docker クライアントは Docker レジストリーからの 401 応答に基づいて認証要求を作成します。その後、クライアントは Red Hat Single Sign-On 認証サーバーへの HTTP Basic Authentication 要求の一部として、ローカルでキャッシュされた認証情報 (docker login コマンドから) を使用します。
  • Red Hat Single Sign-On 認証サーバーは、ユーザーの認証を試みます。また、OAuth スタイルの Bearer トークンが含まれる JSON ボディーを返します。
  • Docker クライアントは JSON 応答からベアラートークンを取得し、これを Authorization ヘッダーで使用し、保護されているリソースを要求します。
  • Docker レジストリーが Red Hat Single Sign-On サーバーから、保護されたリソースの新規リクエストを受信すると、レジストリーはトークンを検証し、要求されたリソースへのアクセスを許可します (必要に応じて)。
注記

Docker プロトコルを使用した認証に成功したら、Red Hat Single Sign-On 側でユーザーセッションは作成されません。ブラウザーの SSO セッションの場合、Docker プロトコルは使用されず、トークンを更新する方法がないため、特定のトークン/セッションがまだ有効であれば Red Hat Single Sign-On サーバーに尋ねる方法はありません。したがって、このプロトコルではセッションの作成は必要ではありません。詳細は「一時的なセッション」を参照してください。

7.4.2. Red Hat Single Sign-On Docker Registry v2 Authentication Server URI Endpoints

Red Hat Single Sign-On には、すべての Docker auth v2 要求に対してエンドポイントは 1 つしかありません。

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

第8章 クライアントの管理

クライアントは、ユーザーの認証を要求できるエンティティーです。クライアントは 2 つの形式で提供されます。クライアントの最初のタイプは、single-sign-on に参加するアプリケーションです。これらのクライアントは、Red Hat Single Sign-On によるセキュリティーの提供のみを行います。他のタイプのクライアントは、認証されたユーザーの代わりに他のサービスを呼び出すことができるように、アクセストークンを要求するものです。このセクションでは、クライアントの設定に関するさまざまな側面と、その方法について説明します。

8.1. OIDC クライアント

アプリケーションのセキュリティーを保護するために OpenID Connect が推奨されるプロトコルです。ギャラウンドから Web フレンドリーになり、HTML5/JavaScript のアプリケーションで最適となるように設計されました。

OIDC クライアントを作成するには、左メニュー項目 Clients に移動します。このページでは、右側に Create ボタンが表示されます。

Clients

clients

これにより、Add Client ページが表示されます。

クライアントの追加

add client oidc

クライアントの クライアント ID を入力します。これは、リクエストで使用する単純な英数字の文字列で、Red Hat Single Sign-On データベースにおいてクライアントを特定します。次に、Client Protocol ドロップダウンメニューで openid-connect を選択します。最後に、Root URL フィールドにアプリケーションのベース URL を入力し、Save をクリックします。これでクライアントが作成され、クライアント Settings タブが表示されます。

クライアントの設定

client settings oidc

このページの設定アイテムを追って説明します。

クライアント ID

これは、OIDC 要求のクライアント識別子として使用される英数字の文字列を指定します。

名前

これは、Red Hat Single Sign-On UI 画面に表示されるたびに、クライアントの表示名です。代替文字列の値 (例: ${myapp}) を設定して、このフィールドの値をローカライズできます。詳細は、『サーバー開発者ガイド』を参照してください。

説明

これはクライアントの説明を指定します。これはローカライズすることもできます。

有効

これがオフになると、クライアントは認証を要求することができません。

Consent Required

これがオンの場合、ユーザーにはそのアプリケーションへのアクセス権限を付与するかどうかをユーザーに尋ねるメッセージが表示されます。また、クライアントがアクセスする情報を正確に認識できるように、クライアントの対象となるメタデータも表示します。Google へのソーシャルログインを行った場合には、多くの場合、同様のページが表示されます。Red Hat Single Sign-On は同じ機能を提供します。

アクセスタイプ

これは OIDC クライアントのタイプを定義します。

confidential
機密性の高いアクセスタイプは、ブラウザーログインを実行し、アクセスコードをアクセストークンに変換する際にクライアントシークレットを必要とするサーバー側のクライアントタイプです (詳細は、OAuth 2.0 仕様の「Access Token Request」を参照してください)。このタイプはサーバー側のアプリケーションに使用する必要があります。
public
パブリックアクセスタイプは、ブラウザーログインの実行に必要なクライアント側のクライアント向けです。クライアント側のアプリケーションの場合、シークレットを安全に維持することはできません。代わりに、クライアントの正しいリダイレクト URI を設定してアクセスを制限することが非常に重要です。
bearer-only
ベアラーのみのアクセスタイプは、アプリケーションがベアラートークン要求のみを許可することを意味します。これがオンの場合、このアプリケーションはブラウザーログインに参加できません。

Standard Flow Enabled

これが置かれている場合、クライアントは OIDC 認証コードフローを使用できます。

Implicit Flow Enabled

これがオンの場合、クライアントは OIDC Implicit Flow を使用できます。

Direct Access Grants Enabled

これが置かれている場合、クライアントは OIDC Direct Access Grants を使用することができます。

Root URL

Red Hat Single Sign-On で設定された相対 URL が使用される場合、この値はそれらの先頭に追加されます。

Valid Redirect URIs

これは必須フィールドです。URL パターンに入力し、+ 記号をクリックして追加します。削除する URL の横にある - 記号をクリックします。Save ボタンをクリックする必要があることに注意してください。ワイルドカード (*) は URI の最後にのみ許可されます (例: http://host.com/*)。

有効なリダイレクト URI パターンを登録する場合には、追加の注意を払う必要があります。一般的に使用すると、攻撃を受けやすくなります。詳細は、「Threat Model Mitigation」の章を参照してください。

Base URL

Red Hat Single Sign-On がクライアントへのリンクが必要な場合は、この URL が使用されます。

Admin URL

Red Hat Single Sign-On 固有のクライアントアダプターでは、これはクライアントのコールバックエンドポイントになります。Red Hat Single Sign-On サーバーは、この URI を使用して、失効ポリシーのプッシュ、バックチャネルログアウトなどのコールバックを行います。Red Hat Single Sign-On サーブレットアダプターでは、サーブレットアプリケーションのルート URL を使用できます。詳細は、『アプリケーションおよびサービスガイド』を参照してください。

Web Origins

このオプションは、Cross-Origin Resource Sharing で構成される CORS を中心とします。ブラウザー JavaScript が、ドメインが JavaScript コードのいずれかとは異なるサーバーに AJAX HTTP リクエストを作成しようとする場合、リクエストは CORS を使用する必要があります。サーバーは特別な方法で CORS リクエストを処理する必要があります。処理しないと、ブラウザーは表示されず、リクエストの処理を許可しません。このプロトコルは、XSS、CSRF、およびその他の JavaScript ベースの攻撃を保護するために存在します。

Red Hat Single Sign-On は、検証された CORS リクエストをサポートします。これは、クライアントの Web Origins 設定に一覧表示されるドメインがクライアントアプリケーションに送信されるアクセストークン内に組み込まれる仕組みになります。その後、クライアントアプリケーションはこの情報を使用して、CORS リクエストの呼び出しを許可するかどうかを決定します。これは OIDC プロトコルへの拡張であるため、Red Hat Single Sign-On クライアントアダプターのみがこの機能をサポートします。詳細は、『アプリケーションおよびサービスガイド』を参照してください。

Web Origins データを入力するには、ベース URL を入力し、+ 記号をクリックして追加します。削除する URL の横にある - 記号をクリックします。Save ボタンをクリックする必要があることに注意してください。

8.1.1. 詳細設定

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

相互 TLS は、TLS ハンドシェイク時に交換されるクライアント証明書でアクセストークンおよび更新トークンをバインドします。これにより、これらのトークンを盗む方法を見つけた攻撃者がトークンを取得することができなくなります。この種類のトークンは holder-of-key トークンと呼ばれます。ベアラートークンとは異なり、holder-of-key トークンの受信側は、トークンの送信側が正当であるかどうかを検証できます。

トークンリクエストで以下の条件が満たされると、Red Hat Single Sign-On はアクセストークンをバインドし、クライアント証明書で更新トークンを取得し、それらを holder-of-key トークンとして発行します。すべての条件が満たされないと、Red Hat Single Sign-On はトークンリクエストを拒否します。

  • この機能はオンになっています。
  • トークンリクエストが、認可コードフローまたはハイブリッドフローのトークンエンドポイントに送信されます。
  • TLS ハンドシェイクでは、Red Hat Single Sign-On がクライアント証明書を要求し、クライアントがクライアント証明書を送信します。
  • TLS ハンドシェイクで Red Hat Single Sign-On がクライアント証明書を正常に検証しました。

Red Hat Single Sign-On で相互 TLS を有効にするには、「WildFly で相互 SSL の有効化」を参照してください。

以下の場合には、Red Hat Single Sign-On はアクセストークンまたは更新トークンを送信するクライアントを検証します。検証に失敗すると、Red Hat Single Sign-On はトークンを拒否します。

  • トークンの更新リクエストは、holder-of-key 更新トークンでトークンエンドポイントに送信されます。
  • UserInfo リクエストは、holder-of-key アクセストークンで UserInfo エンドポイントに送信されます。
  • ログアウトリクエストは、holder-of-key 更新トークンで Logout エンドポイントに送信されます。

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

警告

keycloak クライアントアダプターのいずれも、現在 holder-of-key トークン検証をサポートします。代わりに、keycloak アダプターは現在アクセスおよび更新トークンをベアラートークンとして扱います。

Proof Key for Code Exchange (PKCE)

攻撃者が正当なクライアントに発行した認可コードを盗むと、PKCE は攻撃者がそのコードに適用されるトークンを受信するのを防ぎます。

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

Proof Key for Code Exchange Code Challenge Method

  • (blank): クライアントが PKCE のパラメーターを Red Hat Single Sign-On の承認エンドポイントに正しく送信しない限り、Red Hat Single Sign-On は PKCE を適用しません。これはデフォルトの設定です。
  • S256: Red Hat Single Sign-On は、コードのチャレンジメソッドが S256 であるクライアント PKCE に適用されます。
  • plain: Red Hat Single Sign-On は、コードのチャレンジメソッドが plain のクライアント PKCE に適用されます。

詳細は、OAuth パブリッククライアントによるコード Exchange の RFC 7636 Proof キー を参照してください。

Signed and Encrypted ID Token Support

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

ID トークンを暗号化するキーは、コンテンツ暗号化キー (CEK) と呼ばれます。Red Hat Single Sign-On およびクライアントは、どの CEK が使用されるかと、その配信方法をネゴシエートする必要があります。これを行うには Key Management Mode と呼ばれます。

JWE 仕様は、キー管理モード の 5 種類のキー管理モードを決定します。Red Hat Single Sign-On は、その中における鍵暗号化をサポートします。

Key Encryption では、クライアントは非対称暗号のペアを生成します。公開鍵は CEK の暗号化に使用されます。Red Hat Single Sign-On は、ID トークンごとに CEK を生成し、この生成された CEK で ID トークンを暗号化し、このクライアントの公開鍵でこの CEK を暗号化します。クライアントはこの暗号化された CEK を秘密鍵で復号化し、CEK を復号化して ID トークンを復号化します。そのため、クライアント以外のユーザーは ID トークンを復号化できません。

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

  • クライアントの Credentials タブを開きます。
  • Client Authenticator プルダウンメニューから Signed Jwt を選択します。
  • ON をJWKS URL スイッチに設定
  • JWKS URL テキストボックスに URL を提供するクライアントの公開鍵を入力します。

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

  • クライアントの Settings タブを開きます。
  • 詳細設定の表示を開きます。
  • ID Token Encryption Key Management Algorithm プルダウンメニューから RSA1_5 または RSA-OAEP を選択します。

CEK による ID トークン暗号化アルゴリズムは、JWA 仕様にも定義されます。Red Hat Single Sign-On は、128 ビットキー (A128GCM) を使用した AES_128_CBC_HMAC_SHA_256 認証暗号化 (A128CBC-HS256) および AES GCM に対応しています。このアルゴリズムを選択する詳細な手順は以下のとおりです。

  • クライアントの Settings タブを開きます。
  • 詳細設定の表示を開きます。
  • ID Token Encryption Content Encryption Algorithm プルダウンメニューから A128CBC-HS256 または A128GCM を選択します。

8.1.2. 機密クライアント認証情報

クライアントの Settings タブでクライアントの access typeconfidential に設定した場合は、新しい Credentials タブが表示されます。このようなクライアントの処理の一環として、クライアントのクレデンシャルを設定する必要があります。

認証情報タブ

client credentials

Client Authenticator リストボックスは、機密クライアントに使用する認証情報のタイプを指定します。デフォルトはクライアント ID およびシークレットになります。シークレットは自動的に生成され、Regenerate Secret ボタンを使用すると、必要に応じてこのシークレットを再作成します。

または、シークレットではなく、署名済みの Json Web Token (JWT) または x509 証明書の検証 (別名 Mutual TLS) を使用することができます。

署名付き JWT

client credentials jwt

この認証情報タイプを選択すると、クライアントの秘密鍵と証明書も生成する必要があります。秘密鍵は JWT に署名するために使用されます。一方、証明書は、署名の検証にサーバーによって使用されます。Generate new keys and certificate ボタンをクリックして、このプロセスを開始します。

キーの生成

generate client keys

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

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

証明書のインポート

import client cert

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

最後に、JWKS URL の使用 を選択している場合は、証明書をインポートする必要はありません。このような場合には、クライアントが JWK 形式で公開鍵を公開する URL を指定できます。Red Hat Single Sign-On 側では、クライアントがキーを変更すると、Red Hat Single Sign-On 側ですべてのキーを再インポートする必要がないため、柔軟性があります。

Red Hat Single Sign-On アダプターで保護されたクライアントを使用している場合は、https://myhost.com/myapp がクライアントアプリケーションのルート URL であると仮定して、https://myhost.com/myapp/k_jwks のように JWKS の URL を設定することができます。詳細は『サーバー開発者ガイド』を参照してください。

警告

パフォーマンス上、Red Hat Single Sign-On は OIDC クライアントの公開鍵をキャッシュします。クライアントの秘密鍵が危険にさらされたと思われる場合は、キーの更新は明らかですが、キーの更新も適切です。詳細は、「キャッシュの消去」セクションを参照してください。

クライアントシークレットでの署名済み JWT

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

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

X509 証明書

このオプションを有効にすると、クライアントが TLS Handshake 時に適切な X509 証明書を使用する場合に Red Hat Single Sign-On を検証します。

注記

このオプションには、Red Hat Single Sign-On での相互 TLS が必要です。『WildFly での相互 SSL の有効化』を参照してください。

X509 証明書

x509 client auth

バリデーターは、証明書の Subject DN フィールドも、regexp 検証式を設定して確認します。いくつかのユースケースでは、すべての証明書を受け入れるだけで十分です。この場合は、(.*?)(?:$) 式を使用できます。

Red Hat Single Sign-On がリクエストからクライアント ID を取得する方法は 2 つあります。最初のオプションはクエリーの client_id パラメーターです (OAuth 2.0 仕様 のセクション 2.2 で説明されています)。2 つ目の方法として、client_id をフォームパラメーターとして指定します。

8.1.3. サービスアカウント

各 OIDC クライアントには、アクセストークンの取得を可能にする組み込み service account があります。これは、「クライアント認証情報の付与」の OAuth 2.0 仕様で説明されています。この機能を使用するには、クライアントの Access Typeconfidential に設定する必要があります。これを実行すると、Service Accounts Enabled スイッチが表示されます。このスイッチをオンにする必要があります。また、クライアントのクレデンシャルを設定されていることを確認してください。

このクライアントを使用するには、有効な confidential Client を登録する必要があります。また、このクライアントでは、Red Hat Single Sign-On 管理コンソールでスイッチ Service Accounts Enabled を確認する必要があります。Service Account Roles タブは、このクライアントの代わりに取得したサービスアカウントで利用可能なロールを設定できます。Full Scope Allowed が許可されていない限り、このクライアントのロールスコープマッピング (Scope タブで利用可能なロールを持っている必要があることを覚えておいてください。通常のログインでは、アクセストークンからのロールは以下の交差部分になります。

  • 特定のクライアントのロールスコープと、リンクされたクライアントスコープから継承されたロールスコープのマッピング
  • サービスアカウントロール

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

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

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

応答は、OAuth 2.0 仕様の標準の JSON ドキュメントです。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

デフォルトでは、アクセストークンのみが返されます。更新トークンが返されず、認証の成功時に Red Hat Single Sign-On 側でユーザーセッションも作成されません。更新トークンがないため、アクセストークンの期限が切れると再認証が必要ですが、セッションはデフォルトで作成されないため、Red Hat Single Sign-On サーバー側で追加のオーバーヘッドは保証されません。

このような状況では、ログアウトは必要ありません。ただし、発行されたアクセストークンは、「OpenID Connect Endpoints」セクションで説明するように、OAuth2 Revocation Endpoint にリクエストを送信して取り消すことができます。

8.1.4. オーディエンス語のサポート

Red Hat Single Sign-On がデプロイされる典型的な環境は、一般的に、認証に Red Hat Single Sign-On を使用する 秘密 または 公開 クライアントアプリケーション (フロントエンドクライアントアプリケーション) のセットで構成されています。

また、フロントエンドクライアントアプリケーションからの要求に対応し、リソースを提供する サービス (OAuth 2 仕様では Resource Servers と呼ばれる) もあります。これらのサービスは通常、特定のリクエストに対して認証を行うために、アクセストークン (Bearer トークン) を送信する必要があります。このトークンは、Red Hat Single Sign-On へのログインを試みる際に、フロントエンドアプリケーションによって取得されていました。

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

  1. my-app という名前のフロントエンドクライアントは、Red Hat Single Sign-On に対して認証される必要があります。
  2. ユーザーが Red Hat Single Sign-On で認証されています。Red Hat Single Sign-On は、my-app アプリケーションにトークンを発行しました。
  3. アプリケーション my-app は、トークンを使用してサービス evil-service を呼び出しました。このサービスは、非常に有用なデータを提供できるので、このアプリケーションは evil-service を呼び出す必要があります。
  4. evil-service アプリケーションは、my-app に応答を返しました。ただし、同時に、以前に送信されたトークンが保持されていました。
  5. 次に、evil-service は、以前に保持したトークンで、good-service と呼ばれる別のサービスを呼び出していました。呼び出しに成功し、good-service がデータを返しました。悪意のあるサービス がトークンを悪用してクライアント my-app に代わって他のサービスにアクセスするため、セキュリティーが損なわれます。

このフローは、サービス間の信頼レベルの高い環境においては問題になる可能性があります。ただし、サービス間の信頼が低くなる他の環境では、この問題が発生する可能性があります。

注記

いくつかの環境では、要求されたデータを元の呼び出し元 (my-appクライアント) に適切に返すためにevil-servicegood-service から追加データを取得する必要がある場合があるため、このワークフロー例は要求された動作である場合もあります。Kerberos 認証情報の委譲と同様の意味があります。Kerberos 認証情報の委譲と同様に、無制限のオーディエンスは、サービス間で高レベルに存在する場合にのみ役立つので、十分に大きなオーディエンスになります。それ以外の場合は、以下で説明されているようにオーディエンスを制限することが推奨されます。対象を制限できます。同時に、evil-servicegood-service から必要なデータを取得できるようにします。この場合、evil-service および good-service の両方が対象としてトークンに追加されることを確認する必要があります。

上記の例にあるように、アクセストークンが誤用しないようにするため、トークンでオーディエンスを制限し、トークンに関するオーディエンスを検証するようにサービスを設定することを推奨します。これが実行されると、以下のように上のフローが変更されます。

  1. my-app という名前のフロントエンドクライアントは、Red Hat Single Sign-On に対して認証される必要があります。
  2. ユーザーが Red Hat Single Sign-On で認証されています。Red Hat Single Sign-On は、my-app アプリケーションにトークンを発行しました。クライアントアプリケーションは、evil-service サービスを呼び出す必要があることをすでに認識しているため、Red Hat Single Sign-Onサーバーに送信される認証リクエストで scope=evil-service を使用しました。scope パラメーターの詳細は、「Client Scopes section」を参照してください。my-app クライアントに発行されたトークンには、"audience": [ "evil-service" ] のようにオーディエンスが含まれています。このアクセストークンは、クライアントがこのアクセストークンを使用して evil-service サービスを呼び出すことを望んでいることを宣言しています。
  3. evil-service アプリケーションは、my-app にリクエストを提供していました。同時に、そのトークンに送信したトークンを保持します。
  4. その後、以前に保持したトークンを使用して good-service を呼び出した evil-service アプリケーションが起動しました。good-service はトークンのオーディエンスをチェックし、オーディエンスは evil-service のみであることを確認しているため、呼び出しは成功しませんでした。これは想定内の動作であり、セキュリティーが破損していません。

クライアントが後で good-service を呼び出す場合は、scope=good-service で SSO ログインを発行し、別のトークンを取得する必要があります。返されるトークンには、対象として good-service が含まれます。

"audience": [ "good-service" ]

さらに、good-service を呼び出すことができます。

8.1.4.1. setup

オーディエンスのチェックを適切に設定するには、以下を実行します。

  • アダプター構成に verify-token-audience フラグを追加して、サービスが送信されたアクセストークンのオーディエンスを確認するように構成されていることを確認します。詳細は「アダプターの設定」を参照してください。
  • アクセストークンが Red Hat Single Sign-On により発行される際に、要求されたオーディエンスがすべて含まれ、不要なオーディエンスが含まれていないことを確認します。この対象は、次のセクション で説明されているようにクライアントロールによって自動的に追加することも、以下 のようにハードコーディングすることもできます。

8.1.4.2. オーディエンスの自動追加

デフォルトのクライアントスコープ ロール には 、Audience Resolve プロトコルマッパーが定義されています。このプロトコルマッパーは、現在のトークンが利用可能なクライアントロール 1 つ以上があるクライアントをすべてチェックします。その後、それらの各クライアントのクライアント ID が自動的にオーディエンスとして追加されます。これは、サービス (通常はベアラーのみ) クライアントがクライアントのロールに依存する場合に便利です。

たとえば、Bearer 専用のクライアント good-service と、機密クライアント my-app があり、そのクライアントを認証し、my-app に発行されたアクセストークンを使用して good-service の REST サービスを呼び出したいとします。true の場合:

  • good-service クライアントには、クライアントロール自体で定義されているクライアントロールがあります
  • ターゲットユーザーには、少なくとも 1 つのクライアントロールが割り当てられています
  • my-app クライアントには、割り当てられたロールのロールスコープのマッピングがあります。

次に、good-service は、my-app に発行されたアクセストークンに対して自動的にオーディエンスとして追加されます。

注記

オーディエンスが自動的に追加されないようにする必要がある場合は、ロールスコープマッピングを my-app クライアントに直接設定しないでください。代わりに、good-service など、専用のクライアントスコープ作成します。これには、good-service クライアントのクライアントロールのロールスコープのマッピングが含まれます。このクライアントスコープが任意のクライアントスコープとして my-app クライアントに追加されると仮定すると、client ロールとオーディエンスが、scope=good-service パラメーターで明示的に要求されている場合に限り、クライアントロールとオーディエンスがトークンに追加されます。

注記

フロントエンドクライアント自体は、アクセストークンの対象に自動的に追加されます。アクセストークンにはトークンがオーディエンスとして発行されたクライアントが含まれていないため、アクセストークンと ID トークン間で簡単に区別できます。上記の例では、my-app はオーディエンスとして追加されません。クライアント自体をオーディエンスとして必要な場合は、ハードコーディングされたオーディエンスオプションを参照してください。ただし、フロントエンドと REST サービスと同じクライアントを使用することは推奨されていません。

8.1.4.3. ハードコードされたオーディエンス

サービスがレルムロールに依存する場合や、トークンのロールに依存しない場合は、ハードコーディングされたオーディエンスを使用すると便利です。これはプロトコルマッパーで、指定されたサービスクライアントのクライアント ID をトークンに追加します。クライアント ID とは異なる対象が必要な場合は、一部の URL などのカスタム値を使用することもできます。

プロトコルマッパーはフロントエンドクライアントに直接追加できますが、オーディエンスは常に追加されます。より粒度の細かい制御が必要な場合は、専用のクライアントスコープでプロトコルマッパーを作成することができます。これは、good-service などで呼び出されます。

オーディエンスプロトコルマッパー

audience mapper

  • good-service クライアントの インストールタブ から、アダプタの構成を生成し、verify-token-audience オプションが true に設定されていることを確認することができます。これは、この生成された設定を使用する場合にアダプターがオーディエンスを確認する必要があることを示します。
  • 最後に、my-app フロントエンドクライアントがトークン内の対象として 適切なサービス を要求できるようにする必要があります。my-app クライアントで、Client Scopes タブをクリックします。次に、good-service をオプション (またはデフォルト) クライアント範囲として割り当てます。詳細は、「クライアントスコープのリンク」セクションを参照してください。
  • 必要に応じて、クライアントスコープを評価 し、サンプルアクセストークンを生成することができます。その場合、任意のクライアントスコープとして指定した場合、good-servicescope パラメーターに含まれている場合に限り、生成されたアクセストークンの対象者に good-service が追加されることに注意してください。
  • my-app アプリケーションでは、good-service にアクセスするためのトークンを発行する際に、scope パラメーターを good-service の値と共に使用することを確認する必要があります。アプリケーションがサーブレットアダプターを使用している場合は、「パラメーター転送セクション」を参照してください。また、アプリケーションが JavaScript アダプターを使用している場合は、「JavaScript アダプターセクション」を参照してください。
注記

トークンの正しい対象およびロールが分からない場合は、管理コンソールで クライアントスコープを評価 し、テストを行うとよいでしょう。

注記

Audience および Audience Resolve プロトコルマッパーの両方はデフォルトで、対象をアクセストークンに追加します。ID トークンには通常、トークンが発行されたクライアントのクライアント ID である単一のオーディエンスのみが含まれます。これは、OpenID Connect 仕様の要件です。一方、アクセストークンには、オーディエンスマッパーが追加されない限り、発行されたトークンであるクライアントのクライアント ID があるとは限りません。

8.2. SAML クライアント

Red Hat Single Sign-On は、登録したアプリケーションの SAML 2.0 をサポートします。POST およびリダイレクトバインディングの両方がサポートされます。クライアント署名の検証を必要とし、サーバーの署名や応答の暗号化も選択できます。

SAML クライアントを作成するには、左メニュー項目の Clients に移動します。このページでは、右側に Create ボタンが表示されます。

Clients

clients

これにより、Add Client ページが表示されます。

クライアントの追加

add client saml

クライアントの クライアント ID を入力します。これは通常 URL であり、アプリケーションによって送信される SAML リクエストの issuer 値になります。Client Protocol ドロップダウンボックスで次の saml を選択します。最後に、クライアント SAML エンドポイント URL を入力します。Red Hat Single Sign-On サーバーが SAML 要求および制限を送信する URL を入力します。通常、アプリケーションには SAML 要求を処理するための URL は 1 つだけあります。バインディングに異なる URL がある場合は、クライアントの Settings タブでこれを修正できます。Save をクリックします。これでクライアントが作成され、クライアント Settings タブが表示されます。

クライアントの設定

client settings saml

クライアント ID
この値は、AuthNRequests で送信される発行者の値と一致する必要があります。Red Hat Single Sign-On は、Authn SAML 要求から発行者をプルし、この値によってクライアントに一致します。
名前
これは、Red Hat Single Sign-On UI 画面に表示されるたびに、クライアントの表示名です。代替文字列の値 (例: ${myapp}) を設定して、このフィールドの値をローカライズできます。詳細は、『サーバー開発者ガイド』を参照してください。
説明
これはクライアントの説明を指定します。これはローカライズすることもできます。
有効
これがオフになると、クライアントは認証を要求することができません。
Consent Required
これがオンの場合、ユーザーにはそのアプリケーションへのアクセス権限を付与するかどうかをユーザーに尋ねるメッセージが表示されます。また、クライアントがアクセスする情報を正確に認識できるように、クライアントの対象となるメタデータも表示します。Google へのソーシャルログインを行った場合には、多くの場合、同様のページが表示されます。Red Hat Single Sign-On は同じ機能を提供します。
AuthnStatement の追加
SAML ログイン応答は、使用される認証方法 (パスワードなど) と、ログインのタイムスタンプおよびセッションの有効期限を指定できます。これはデフォルトでは有効になっており、AuthStatement 要素がログイン応答に含まれることを意味します。これを off に設定すると、クライアントが最大セッションの最大長さを判断できなくなります。そのため、クライアントセッションの期限が切れなくなる可能性があることに注意してください。
サインインドキュメント
Red Hat Single Sign-On を有効にすると、レルムの秘密鍵を使用してドキュメントに署名されます。
REDIRECT 署名キー検索の最適化
オンになると、SAML プロトコルメッセージには、署名キー ID を使用したヒントが含まれる Red Hat Single Sign-On ネイティブエクステンションが含まれます。SP はこの拡張を認識すると、既知のキーで署名を検証しようとする代わりに、署名の検証に使用できます。このオプションは、署名がクエリーパラメーターで転送される REDIRECT バインディングのみに適用されます (キー ID は常にドキュメント署名に含まれる POST バインディングメッセージ に類似しています)。現在、IDP と SP の両方が Red Hat Single Sign-On サーバーおよびアダプターによって提供される状況に関連します。このオプションは、Sign Documents がオンの場合にのみ関連します。
アサーションへの署名
Sign Documents は、ドキュメント全体に署名します。この設定では、アサーションも SAML XML 認証応答内に署名され、組み込まれます。
署名アルゴリズム
SAML ドキュメントの署名には、さまざまなアルゴリズムを選択します。
SAML 署名キー名
署名付き SAML ドキュメントには、POST バインディング経由で送信される署名済みのほか、KeyName 要素の署名キーの識別が含まれます。これには、Red Hat Single Sign-On のキー ID が含まれます。ただし、さまざまなベンダーが異なるキー名があるか、キー名が全くない場合もあります。このスイッチは、KeyName に鍵 ID (KEY_ID オプション) が含まれるか、レルムキーに対応する証明書のサブジェクト (CERT_SUBJECT オプション (Microsoft Active Directory Federation Services に必要なもの) など)、または SAML メッセージからキー名のヒントが完全に省略される (NONE オプション) かどうかを制御します。
正規化メソッド
XML 署名の正規化メソッド。
アサーションの暗号化
レルムの秘密鍵を使用して、SAML ドキュメントのアサーションを暗号化します。AES アルゴリズムはキーサイズは 128 ビットで使用されます。
クライアント署名が必要です
クライアントから送られるドキュメントが署名されるはずです。Red Hat Single Sign-On は、クライアントパブリックキーまたは SAML Keys タブで証明書を使ってこの署名を検証します。
POST バインディングの強制
デフォルトでは、Red Hat Single Sign-On は元のリクエストの最初の SAML バインディングを使用して応答します。このスイッチを有効にすると、元の要求がリダイレクトバインディングであっても、Red Hat Single Sign-On が常に SAML POST バインディングを使用して応答するように強制されます。
フロントチャンネルのログアウト
true の場合、このアプリケーションではログアウトを実行するためにブラウザーリダイレクトが必要になります。たとえば、アプリケーションでは Cookie をリセットする必要がありますが、リダイレクトでのみ実行可能です。このスイッチが false の場合、Red Hat Single Sign-On はバックグラウンド SAML 要求を呼び出してアプリケーションからログアウトします。
名前 ID フォーマットの強制
要求に名前 ID ポリシーがある場合は無視し、管理コンソールで設定された値を Name ID Format で使用されます。
名前 ID 形式
サブジェクトの名前 ID 形式。リクエストに名前 ID ポリシーが指定されていない場合や、強制名 ID Format 属性が true の場合、この値が使用されます。各形式に使用されるプロパティーは次のとおりです。
Root URL
Red Hat Single Sign-On で設定された相対 URL が使用される場合、この値はそれらの先頭に追加されます。
Valid Redirect URIs
これはオプションのフィールドです。URL パターンに入力し、+ 記号をクリックして追加します。削除する URL の横にある - 記号をクリックします。Save ボタンをクリックする必要があることに注意してください。ワイルドカード (*) は URI の最後にのみ許可されます (例: http://host.com/*)。このフィールドは、正確な SAML エンドポイントが登録されておらず、Red Hat Single Sign-On がリクエストから Assertion Consumer URL をプルする場合に使用されます。
Base URL
Red Hat Single Sign-On をクライアントにリンクする必要がある場合は、この URL が使用されます。
マスター SAML 処理 URL
この URL はすべての SAML リクエストに使用され、応答は SP に転送されます。これは、Assertion Consumer Service URL および Single Logout Service URL として使用されます。ログインリクエストに Assertion Consumer Service URL を含めますが、この URL は登録された Valid Redirect URI パターンによって検証される必要があります。
assertion Consumer Service POST バインディング URL
Assertion Consumer Service の POST バインディング URL。
assertion Consumer Service リダイレクトバインディング URL
Assertion Consumer Service のリダイレクトバインディング URL。
サービス POST バインディングのログアウト URL
Logout Service の POST バインディング URL。
サービスリダイレクトバインディング URL をログアウトする
Logout Service のリダイレクトバインディング URL。

8.2.1. IDP Initiated ログイン

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

IDP によって開始されたログイン実装は REDIRECT バインディングで POST を優先します (詳細は saml バインディングを参照)。そのため、最終バインディングおよび SP URL は以下の方法で選択されます。

  1. 特定の Assertion Consumer Service POST Binding URL が定義される場合 (クライアント設定の Fine Grain SAML Endpoint Configuration 設定)。POST バインディングはその URL で使用されます。
  2. 一般的な Master SAML Processing URL が指定されている場合には、この一般的な URL ではなく POST バインディングが使用されます。
  3. 最後に、(Fine Grain SAML Endpoint Configuration 内で) Assertion Consumer Service Redirect Binding URL が設定されている場合は、この URL で REDIRECT バインディングが使用されます。

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

アイデンティティーブローカー を使用する場合は、外部 IDP からクライアントの IDP 開始ログインを設定できます。前述のように、ブローカー IDP で IDP 開始ログインに実際のクライアントが設定されている。外部 IDP は、ブローカーを示す特別な URL を参照するアプリケーションの IDP Initiated ログインにクライアントを設定し、仲介 IDP で選択したクライアントの IDP Initiated ログインエンドポイントを表す必要があります。これは、外部 IDP のクライアント設定を意味します。

  • IDP Initiated SSO URL Name は、IDP Initiated Login initial point として公開される名前に設定されます。
  • Fine Grain SAML Endpoint Configuration セクションの Assertion Consumer Service POST Binding URL は、broker-root/auth/realms/{broker-realm}/broker/{idp-name}/endpoint/clients/{client-id} の URL に設定する必要があります。ここでは、以下のようになります。

    • broker-root はベースブローカー URL です。
    • broker-realm は、外部 IDP が宣言されるブローカーのレルムの名前です。
    • IDP-name はブローカーの外部 IDP の名前です。
    • client-id は、ブローカーで定義された SAML クライアントの IDP Initiated SSO URL Name 属性の値です。このクライアントは、外部 IDP から IDP Initiated ログインで利用できます。

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

8.2.2. SAML エンティティー記述子

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

クライアントの追加

add client saml

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

mod-auth-mellon などの SAML クライアントアダプターの中には、IDP の XML エンティティー記述子が必要です。この公開 URL (root/auth/realms/{realm}/protocol/saml/descriptor) に移動して、これを取得できます。

8.4. OIDC トークンおよび SAML アサーションマッピング

ID トークン、アクセストークン、または SAML アサーションを受信するアプリケーションは、異なるユーザーメタデータおよびロールを必要とする場合があります。Red Hat Single Sign-On を使用すると、転送するものを正確に定義できます。ロール、要求、およびカスタム属性をハードコーディングできます。ユーザーメタデータをトークンまたはアサーションにプルできます。ロールの名前を変更できます。基本的には、クライアントに戻ることを正確に制御している多くのコントロールがあります。

管理コンソール内で、登録したアプリケーションを選択すると、マッパー タブが表示されます。以下は、OIDC ベースのクライアント用です。

マッパータブ

mappers oidc

新しいクライアントにはビルトインマッパーがありませんが、クライアントスコープセクション で説明されているように、通常はクライアントスコープから一部のマッパーを継承します。プロトコルマッパーは、たとえばメールアドレスをアイデンティティーおよびアクセストークンの特定の要求にマップします。これらの関数は、それぞれの関数を名前に含める必要があります。Add Builtin ボタンをクリックして、追加可能なクライアントに割り当てられていない追加の事前設定されたマッパーがあります。

各マッパーには共通する設定と、追加するマッパーのタイプに応じて追加の設定があります。リスト内のマッパーの 1 つの横にある Edit ボタンをクリックして config 画面に移動します。

マッパーの設定

mapper config

設定オプションについて学ぶ最適な方法として、ツールチップの上にマウスをかざすことができます。

ほとんどの OIDC マッパーにより、要求を配置する場所を制御できます。Add to ID token および Add to access token スイッチを使用すると、idaccess トークンの両方から要求を組み込むか、または除外することができます。

最後に、他のマッパータイプを追加することもできます。Mappers タブに戻る場合は、Create ボタンをクリックします。

マッパーの追加

add mapper

リストボックスから Mapper Type を選択します。ツールチップにマウスをかざすと、マッパーのタイプの動作が表示されます。マッパータイプごとに異なる設定パラメーターが表示されます。

8.4.1. 優先順位

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

マッパーは、マッパーのリストの順序で並び替え、トークンまたはアサーションの変更は、最初に適用される順を使用して適用されます。つまり、他の実装に依存する実装は、必要な順序で処理されます。

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

8.4.2. OIDC ユーザーセッションノートマッパー

ユーザーセッションの詳細はマッパー経由で行われ、さまざまな基準によって異なります。クライアントで機能を使用または有効化すると、ユーザーセッションの詳細が自動的に含まれます。Add builtin ボタンをクリックして、セッションの詳細を含めることもできます。

切り替え後のユーザーセッションは以下の詳細を提供します。

  • IMPERSONATOR_ID: 偽装ユーザーの ID
  • IMPERSONATOR_USERNAME: 偽装ユーザーのユーザー名

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

  • clientID: サービスアカウントのクライアント ID
  • clientAddress: サービスアカウントの認証されたデバイスのリモートホスト IP
  • clientHost: サービスアカウントの認証デバイスのリモートホスト名

8.4.3. スクリプトマッパー

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

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

8.5. クライアントアダプター設定の生成

Red Hat Single Sign-On は、アプリケーションのデプロイメント環境にクライアントアダプターをインストールするのに使用できる設定ファイルを事前に生成します。OIDC と SAML の両方で、多くのアダプタータイプがサポートされます。設定を生成するクライアントの Installation タブに移動します。

client installation

設定用に生成された Format Option を選択します。OIDC および SAML のすべての Red Hat Single Sign-On クライアントアダプターがサポートされます。SAML の mod-auth-mellon Apache HTTPD アダプターと、標準の SAML エンティティー記述子ファイルがサポートされます。

8.6. クライアントスコープ

多くのアプリケーションを組織内で保護および登録する必要がある場合には、これらの各クライアントに プロトコルマッパーロールスコープのマッピング を設定することが簡単になります。Red Hat Single Sign-On では、共有クライアント設定を クライアントスコープ と呼ばれるエンティティーに定義できます。

クライアントスコープは OAuth 2 scope パラメーターもサポートします。これにより、アプリケーションのニーズに応じて、クライアントアプリケーションがアクセストークン内の要求またはロールを要求できます。

クライアントスコープを作成するには、以下の手順に従います。

  • 左側のメニュー項目 Client Scopes に移動します。この初期画面には、現在定義されているクライアントスコープの一覧が表示されます。

クライアントスコープの一覧

client scopes list

  • Create ボタンをクリックします。クライアントスコープに名前を付け、保存します。クライアントスコープ には、通常のクライアントと同様のタブがあります。プロトコルマッパーロールスコープマッピング を定義できます。このマッピングは、他のクライアントによって継承でき、このクライアントスコープから継承するように設定されます。

8.6.1. プロトコル

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

新しいレルムを作成したら、メニューに事前定義 (組み込み) クライアントスコープの一覧があることを確認できます。

  • SAML プロトコルには、SAML アサーションのロールリストを表示するためのプロトコルマッパーを 1 つ持つ 組み込みクライアントスコープ roles_list が 1 つあります。
  • OpenID Connect プロトコルには、クライアントスコーププロファイル profileemailaddressphoneoffline_accessrolesweb-origins、および microprofile-jwt があります。

クライアントスコープ (offline_access) は、クライアントがオフライントークンを取得する場合に便利です。Offline Access セクション または OpenID Connect 仕様 でオフライントークンについて説明します。ここで、scope パラメーターは offline_access の値で定義されます。

クライアントスコーププロファイル、profileemailaddress、および phone は、OpenID Connect 仕様 にも定義されています。これらのクライアントスコープにはロールスコープのマッピングが定義されていませんが、一部のプロトコルマッパーが定義されており、これらのマッパーは OpenID Connect 仕様で定義される要求に対応します。

たとえば、phone クライアントのスコープを開き、Mappers タブを開くと、プロトコルマッパーが表示されます。これは、スコープの phone の仕様で定義される要求に対応します。

クライアントスコープマッパー

client scopes phone

phone クライアントスコープがクライアントにリンクされると、そのクライアントは phone クライアントスコープで定義されたすべてのプロトコルマッパーを自動的に継承します。このクライアントに発行されたアクセストークンには、ユーザーに関する電話番号 (電話番号が定義されているか) が含まれます。

組み込みクライアントスコープには、仕様に定義されているプロトコルマッパーを正確に含まれますが、クライアントスコープを編集し、プロトコルマッパー (またはロールの範囲) の作成/更新/削除を行うことができます。

クライアントスコープ ロール は OpenID Connect 仕様に定義されず、アクセストークンの スコープ 要求に自動的に追加されません。このクライアントスコープにはいくつかのマッパーがあります。これは、ユーザーのロールをアクセストークンに追加するために使用され、Audience セクションに記載されているように、1 つ以上のクライアントロールを持つクライアントのオーディエンスを追加するために使用されます。

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

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

8.6.3. クライアントとリンククライアントスコープ

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

デフォルトのクライアントスコープ
これは、OpenID Connect および SAML クライアントの両方に適用されます。デフォルトのクライアントスコープは、このクライアントの OpenID Connect トークンまたは SAML アサーションを発行するときに常に適用されます。クライアントはプロトコルマッパーとロールスコープのマッピングをクライアントスコープで継承します。OpenID Connect Protocol の場合、OpenID Connect の承認要求の scope パラメーターで使用される値にかかわらず、マッパーおよびロールの範囲マッピングは常に適用されます。
オプションのクライアントスコープ
これは、OpenID Connect クライアントにのみ適用されます。オプションのクライアントスコープはこのクライアントのトークンを発行するときに適用されますが、これらは OpenID Connect 承認要求で scope パラメーターによって要求される場合にのみ適用されます。

8.6.3.1. 例

この例では、クライアントに profileemail がデフォルトのクライアントスコープとしてリンクされていることと、phoneaddress がオプションのクライアントスコープとしてリンクされていることを前提とします。クライアントは、要求を OpenID Connect 承認エンドポイントに送信する際に、scope パラメーターの値を使用します。

scope=openid phone

scope パラメーターには文字列が含まれ、スコープの値がスペースで区切られます (クライアントスコープ名にはスペース文字が含まれないためです)。openid の値は、すべての OpenID Connect 要求に使用されるメタ値であるため、この例では無視します。トークンには、クライアントスコープの profileemail (デフォルトのスコープ)、および phone (scope パラメーターで要求される任意のクライアントスコープ) からのマッパーおよびロールスコープのマッピングが含まれます。

8.6.4. クライアントスコープの評価

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

クライアントの Client Scopes タブをクリックしてからサブタブ Evaluate をクリックすると、これらすべてが表示されます。ここから、適用する任意のクライアントスコープを選択できます。また、これにより scope パラメーターの値も表示されます。これは、アプリケーションから Red Hat Single Sign-On OpenID Connect 承認エンドポイントに送信する必要があります。

クライアントスコープの評価

client scopes evaluate

注記

アプリケーションから scope パラメーターのカスタム値を送信する方法を確認したい場合は、アプリケーションがサーブレットアダプターを使用する場合は、パラメーター転送セクション、またはアプリケーションが javascript アダプターを使用する場合は javascript アダプターの項を参照してください。

8.6.4.1. サンプルトークンの生成

特定のユーザーに生成された実際のアクセストークンの例を確認し、特定のクライアントに対して発行し、scope パラメーターで指定した値を使用して、Evaluate 画面でユーザーを選択します。これにより、すべての要求およびロールマッピングを含むトークンのサンプルが生成されます。

8.6.5. クライアントスコープのパーミッション

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

ユーザーがクライアントスコープを使用できない場合、トークンの生成時にプロトコルマッパーまたはロールスコープマッピングは使用されなくなり、トークンの範囲にクライアントスコープは表示されません。

8.6.6. レルムのデフォルトクライアントスコープ

Realm Default Client Scopes を使用すると、新規作成されたクライアントへ自動的にリンクされるクライアントスコープのセットを定義できます。

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

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

デフォルトのクライアントスコープ

client scopes default

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

8.6.7. 記述されたスコープ

scope は数カ所時に Red Hat Single Sign-On で使用されます。さまざまなスコープの発生は相互に関係しますが、異なるコンテキストと意味を持つ可能性があります。ここでは、Red Hat Single Sign-On で使用されるさまざまな scopes を説明します。

クライアントスコープ
本章で参照されています。クライアントスコープは、レルムレベルで設定され、クライアントにリンクできる Red Hat Single Sign-On のエンティティーです。scope パラメーターの対応する値で Red Hat Single Sign-On 承認エンドポイントに要求を送信すると、クライアントスコープはその名前によって参照されます。詳細は、「クライアントスコープのリンク」のセクションを参照してください。
ロールスコープのマッピング
これは、クライアントまたはクライアントスコープの Scope タブを開くと表示されます。ロールスコープのマッピングにより、アクセストークンで使用できるロールを制限できます。詳細は、「ロールスコープマッピング」セクションを参照してください

第9章 Roles

ロールはユーザーのタイプまたはカテゴリーを識別します。Adminusermanageremployee は、組織に存在する可能性のある通常のロールすべてです。アプリケーションは通常、多くの場合、個々のユーザーではなく、特定のロールにアクセスおよびパーミッションを割り当てます。これは、ユーザーの処理は複雑で、管理が困難となるためです。たとえば、管理コンソールには特定のロールがあり、管理コンソール UI の部分にアクセスし、特定のアクションを実行するパーミッションを付与します。また、ロールのグローバル名前空間があり、各クライアントにはロールを定義する独自の専用の名前空間もあります。

9.1. レルムロール

レルムレベルのロールは、ロールを定義するグローバル名前空間です。左メニュー項目 Roles をクリックすると、組み込みロールおよび作成されたロールの一覧を表示できます。

roles

ロールを作成するには、このページの Add Role をクリックし、ロールの名前と説明を入力して Save をクリックします。

ロールの追加

role

description フィールドの値は、${var-name} 文字列で置換変数を指定してローカライズできます。ローカライズ値は、ご自分のテーマのプロパティーファイル内で設定されます。ローカライゼーションの詳細は、『サーバー開発者ガイド』を参照してください。

9.2. クライアントロール

クライアントロールは基本的にクライアント専用の名前空間です。各クライアントは独自の名前空間を取得します。クライアントロールは、各クライアントの Roles タブで管理されます。この UI は、レルムレベルのロールの場合と同じように対話します。

9.3. 複合ロール

レルムまたはクライアントレベルのロールは、複合ロールに変換できます。複合ロールは、1 つ以上の追加ロールに関連付けられたロールです。複合ロールがユーザーにマップされると、ユーザーはその複合に関連付けられたロールも取得します。この継承は再帰的であるため、複合の複合も継承されます。

通常のロールを複合ロールに変換するには、ロールの詳細ページに移動し、Composite Role スイッチをオンにします。

複合ロール

composite role

切り替え後、ロール選択 UI がページ下部に表示されると、レルムレベルとクライアントレベルのロールを、作成している複合に関連付けることができます。この例では、employee realm-level ロールは、developer の複合ロールに関連付けられているものです。developer ロールを持つユーザーも、employee ロールも継承されます。

注記

トークンと SAML アサーションが作成されると、複合ロールにも、クライアントに送信された認証応答のクレームおよびアサーションに追加されます。

9.4. ユーザーロールのマッピング

ユーザーロールのマッピングは、その単一のユーザーの Role Mappings タブを使用して、各ユーザーに個別に割り当てることができます。

ロールマッピング

user role mappings

上記の例では、「複合ロール」の章で作成した複合ロール developer を割り当てます。

有効なロールマッピング

effective role mappings

developer ロールが割り当てられると、developer 複合に関連する 社員 ロールが Effective Roles に表示されます。Effective Roles は、ユーザーと明示的に割り当てられたロールと、複合から継承されたロールです。

9.4.1. Default Roles

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

Default Roles

default roles

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

9.5. Role Scope Mappings

OIDC アクセストークンまたは SAML アサーションが作成されると、ユーザーのすべてのユーザーロールマッピングがデフォルトで、トークンまたはアサーションにクレームとして追加されます。アプリケーションはこの情報を使用して、そのアプリケーションが制御するリソースのアクセス決定を行います。Red Hat Single Sign-On では、アクセストークンはデジタル署名され、実際にはアプリケーションによって再利用され、リモートでセキュアな REST サービスで呼び出すことができます。つまり、アプリケーションが危険にさらされるか、レルムに登録されている不正なクライアントがある場合、攻撃者は幅広いパーミッションを持ち、ネットワーク全体に危険にさらされることができるアクセストークンを取得することができます。これは、ロールスコープのマッピングが重要な場所です。

ロールスコープのマッピングは、アクセストークン内で宣言されたロールを制限する手段です。クライアントがユーザー認証をリクエストすると、受信するアクセストークンにはクライアントのスコープに明示的に指定したロールマッピングのみが含まれます。これにより、すべてのユーザーのパーミッションにクライアントアクセスを付与するのではなく、個々のアクセストークンごとのパーミッションを制限できます。デフォルトでは、各クライアントはユーザーのすべてのロールマッピングを取得します。これは、各クライアントの Scope タブで確認できます。

フルサポート

full client scope

スコープの有効なロールがレルム内で宣言されたすべてのロールであることを図ることができます。このデフォルトの動作を変更するには、Full Scope Allowed スイッチを明示的に無効にし、各クライアントに必要な特定のロールを宣言する必要があります。または、クライアントスコープを使用してクライアントのセット全体で同じロールスコープマッピングを定義することもできます。

部分的なスコープ

client scope

第10章 グループ

Red Hat Single Sign-On のグループを使用すると、一連のユーザーの共通の属性とロールマッピングを管理できます。ユーザーは、ゼロ以上のグループのメンバーにすることができます。ユーザーは、各グループに割り当てられた属性とロールマッピングを継承します。グループの管理は、左側のメニュー項目の Groups に移動します。

グループ

groups

グループは階層です。グループには多くのサブグループを指定できますが、グループは親を 1 つだけ指定できます。サブグループは、親から属性およびロールのマッピングを継承します。これは、ユーザーにも適用されます。そのため、親グループと子グループのみに属するユーザーがある場合は、ユーザーは親と子の両方の属性とロールマッピングを継承します。この例では、最上位の Sales グループと、North America サブグループがあります。グループを追加するには、新しい子を追加する親をクリックし、New ボタンをクリックします。ツリー内の Groups アイコンを選択して最上位のグループを作成します。Create Group 画面にグループ名を入力して Save をクリックすると、個別のグループ管理ページが表示されます。

グループ

group

Attributes タブおよび Role Mappings タブは、ユーザーに類似した名前のタブと全く機能します。定義する属性とロールマッピングは、このグループのメンバーであるグループおよびユーザーによって継承されます。

ユーザーをグループに追加するには、ユーザーの詳細ページに戻り、そこに Groups タブをクリックします。

ユーザーグループ

user groups

Available Groups ツリーからグループを選択し、参加 ボタンを押してユーザーをグループに追加する。グループを削除する逆も同様です。ここでは、North America グループにユーザー Jim を追加しました。そのグループの詳細ページに戻り、Membership タブを選択すると Jim がそこに表示されます。

グループメンバーシップ

group membership

10.1. グループ 対Roles

IT 業界では、Group および Role の概念が曖昧で、混同していることがよくあります。Red Hat Single Sign-On では、グループはユーザーの集まりで、ロールおよび属性を 1 箇所に適用できます。ロールは、ユーザーやアプリケーションのタイプがロールに対してパーミッションおよびアクセス制御を割り当てます。

複合ロールもグループと類似していますか?論理的に同じ機能が提供されますが、違いは概念的です。複合ロールは、サービスやアプリケーションのセットにパーミッションモデルを適用するために使用する必要があります。グループは、組織内のユーザーおよびロールのコレクションに重点を置いてください。グループを使用してユーザーを管理します。複合ロールを使用してアプリケーションおよびサービスを管理します。

10.2. デフォルトグループ

デフォルトのグループでは、Identity Brokering を使用して新規ユーザーが作成またはインポートされるたびに、グループメンバーシップを自動的に割り当てることができます。デフォルトのグループを指定するには、左メニュー項目 Groups に移動し、Default Groups タブをクリックします。

デフォルトグループ

default groups

第11章 管理コンソールアクセス制御およびパーミッション

Red Hat Single Sign-On で作成された各レルムには、そのレルムを管理できる専用の管理コンソールがあります。master レルムは、管理者がシステムで複数のレルムを管理できるようにする特別なレルムです。異なるレルムでユーザーへの詳細なアクセスを定義して、サーバーを管理することもできます。本章では、このシナリオをすべて実施します。

11.1. マスターレルムアクセス制御

Red Hat Single Sign-On の master レルムは特別なレルムで、他のレルムとは異なる処理を行います。Red Hat Single Sign-On master レルムのユーザーは、Red Hat Single Sign-On サーバーにデプロイされるゼロ以上のレルムを管理するパーミッションを付与できます。レルムが作成されると、Red Hat Single Sign-On は、その新しいレルムにアクセスするための詳細な権限を付与するさまざまなロールを自動的に作成します。管理コンソールおよび管理 REST エンドポイントへのアクセスは、これらのロールを master レルムのユーザーにマッピングすることで制御できます。特定のレルムのみを管理できるユーザーは、複数のスーパーユーザーを作成することができます。

11.1.1. グローバルロール

master レルムには、2 つのレルムレベルのロールがあります。以下のとおりです。

  • admin
  • create-realm

admin ロールを持つユーザーはスーパーユーザーであり、サーバー上のレルムを管理するためにフルアクセスできます。create-realm ロールを持つユーザーは、新しいレルムを作成できます。このユーザーは、作成する新しいレルムに完全アクセスできます。

11.1.2. レルム固有のロール

master レルム内の管理者ユーザーには、システムの他のレルムに対して管理権限を付与できます。Red Hat Single Sign-On の各レルムは、master レルムのクライアントで表されます。クライアントの名前は <realm name>-realm です。これらのクライアントには、クライアントレベルのロールが定義されており、個別のレルムを管理するアクセスレベルを定義します。

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

  • view-realm
  • view-users
  • view-clients
  • view-events
  • manage-realm
  • manage-users
  • create-client
  • manage-clients
  • manage-events
  • view-identity-providers
  • manage-identity-providers
  • impersonation

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

重要

manage-users ロールを持つユーザー管理者は、admin ロールを所有したユーザーにのみ割り当てることができます。したがって、admin に manage-users ロールがあり、manage-realm ロールがない場合、このロールを割り当てることができます。

11.2. 専用レルム管理コンソール

各レルムには、URL /auth/admin/{realm-name}/console に移動してアクセス可能な専用の管理コンソールがあります。特定のユーザーロールマッピングを割り当てることで、そのレルム内のユーザーにレルム管理パーミッションを付与できます。

各レルムには、realm-management と呼ばれる組み込みクライアントがあります。このクライアントは、レルムの左側のメニュー項目 Clients に移動すると表示できます。このクライアントは、レルムの管理に付与できるパーミッションを指定するクライアントレベルのロールを定義します。

  • view-realm
  • view-users
  • view-clients
  • view-events
  • manage-realm
  • manage-users
  • create-client
  • manage-clients
  • manage-events
  • view-identity-providers
  • manage-identity-providers
  • impersonation

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

11.3. Fine Grain Admin Permissions

注記

Fine Grain Admin Permissions はテクノロジープレビュー機能ですが、完全にサポートされていません。この機能はデフォルトでは無効にされます。

-Dkeycloak.profile=preview または -Dkeycloak.profile.feature.admin_fine_grained_authz=enabled を使用してサーバーを起動します。詳細は「プロファイル」を参照してください。

manage-realmmanage-users などのロールは粒度が荒すぎて、より詳細なパーミッションを持つ制限された admin アカウントの作成が必要になることがあります。Red Hat Single Sign-On を使用すると、レルム管理に制限付きアクセスポリシーを定義して割り当てることができます。以下に例を示します。

  • 特定のクライアントの管理
  • 特定グループに所属するユーザーの管理
  • グループのメンバーシップの管理
  • 制限されたユーザー管理。
  • 粒度の個人設定制御
  • ユーザーの特定の制限付きロールセットを割り当てることができる。
  • 特定の制限付きロールセットを複合ロールに割り当てることができます。
  • 特定の制限付きロールのセットをクライアントのスコープに割り当てることができます。
  • ユーザー、グループ、ロール、およびクライアントを表示および管理するための新しい一般的なポリシー。

admin パーミッションに関する重要な点について、以下の重要な点に留意してください。

  • 粒度の細かい管理権限は、承認サービス に実装されました。細分のパーミッションに分割する前に、この機能に対して読むことを強く推奨します。
  • 細かいアクセス権限は、専用の管理コンソールおよびそれらのレルム内でのみ利用できます。レルム間の細かいグラザブルパーミッションを定義することはできません。
  • 追加のパーミッションを付与するのに細かいパーミッションを使用します。ビルトインの admin ロールのデフォルト動作を上書きすることはできません。

11.3.1. 特定のクライアントの管理

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

重要

レルムの細かいアクセス権限をまたがって実行できません。master レルムの管理者は、以前の章で定義された事前定義済みの admin ロールに制限されます。

11.3.1.1. パーミッションのセットアップ

最初に管理コンソールにログインし、そのクライアントのパーミッションを設定できます。きめ細かなパーミッションを定義するクライアントの管理セクションに移動します。

クライアント管理

fine grain client

Permissions というタブメニュー項目が表示されるはずです。そのタブをクリックします。

クライアントパーミッションタブ

fine grain client permissions tab off

デフォルトでは、各クライアントは細かいパーミッションを実行することはできません。したがって、Permissions Enabled をオンにしてパーミッションを初期化します。

重要

Permissions Enabled スイッチをオフに設定すると、このクライアントに定義したすべてのパーミッションが削除されます。

クライアントパーミッションタブ

fine grain client permissions tab on

Permissions Enabled を on に切り替えると、「承認サービス」を使用して、背後でさまざまなパーミッションオブジェクトを初期化します。この例では、クライアントの 管理 パーミッションが対象になります。クライアントの manage パーミッションを処理するパーミッションにリダイレクトするものをクリックします。すべての承認オブジェクトは、realm-management クライアントの Authorization タブに含まれます。

クライアントパーミッションの管理

fine grain client manage permissions

最初に初期化された場合、manage パーミッションには関連付けられたポリシーがありません。policy タブに移動して作成する必要があります。高速に進むには、上記のイメージに表示される Authorization リンクをクリックします。次に、policies タブをクリックします。

このページに、Create policy というプルダウンメニューがあります。設定可能なさまざまなポリシーがあります。ロールまたはグループに関連付けられたポリシーを定義したり、JavaScript でルールを定義したりできます。この簡単な例では、User Policy を作成します。

ユーザーポリシー

fine grain client user policy

このポリシーは、ユーザーデータベースのハードコーディングされたユーザーと一致します。この場合、これは sales-admin ユーザーです。次に、sales-application クライアントの manage パーミッションページに戻り、ポリシーをパーミッションオブジェクトに割り当てる必要があります。

ユーザーグループの割り当て

fine grain client assign user policy

sales-admin ユーザーには、sales-application クライアントを管理するパーミッションが使用できるようになりました。

さらに 1 つのことが必要です。Role Mappings タブに移動し、query-clients ロールを sales-admin に割り当てます。

query-clients の割り当て

fine grain assign query clients

これを行う必要があるのはなぜですか?このロールは、sales-admin が管理コンソールにアクセスする際にレンダリングするメニュー項目を管理コンソールに指示します。query-clients ロールは、sales-admin ユーザーのクライアントメニューをレンダリングするよう管理コンソールに指示します。

IMPORTANT query-clients ロールを設定しない場合、sales-admin などの制限された管理者が管理コンソールにログインするときにメニューオプションは表示されません。

11.3.1.2. それをテストします。

次に、master レルムからログアウトし、sales-admin をユーザー名として使用し、test レルムの 専用の管理コンソール に再ログインします。これは /auth/admin/test/console にあります。

売上管理者ログイン

fine grain sales admin login

これで、この admin がこのクライアントを 1 つ管理できるようになりました。

11.3.2. ユーザーロールのマッピングの制限

もう 1 つのことは、管理者がユーザーに割り当てることのできるロールセットを制限することです。最後のサンプルを続行して、'sales-admin' ユーザーのパーミッションセットを拡張して、このアプリケーションにアクセスできるユーザーも制御できるようにします。細かいパーミッションにより、sales-adminsales-application への特定のアクセス権限を付与するロールのみを割り当てることができます。また、管理者はロールのみをマッピングでき、他のタイプのユーザー管理を実行しないように制限することもできます。

sales-application が 3 つの異なるクライアントロールを定義しました。

売上アプリケーションロール

fine grain sales application roles

sales-admin ユーザーがこれらのロールをシステムの任意のユーザーにマッピングできるようにします。これを実行する最初のステップでは、ロールが admin でマップされるようにします。viewLeads ロールをクリックすると、このロールの Permissions タブがあることを確認できます。

Leads ロールのパーミッションタブの表示

fine grain view leads role tab

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

Leads パーミッションの表示

fine grain view leads permissions

関心のあるのは map-role です。このパーミッションをクリックし、上記の例で作成されたのと同じ User Policy を追加します。

map-roles パーミッション

fine grain map roles permission

行った内容は、sales-adminviewLeads ロールをマッピングできることを示しています。何も指定していないユーザーは、管理者がこのロールをマップできるユーザーで指定します。このレルムの管理コンソールの Users セクションに移動する必要があります。左側のメニュー項目 Users をクリックすると、レルムのユーザーインターフェースが表示されます。Permissions タブが表示されるはずです。それをクリックして有効にします。

ユーザーパーミッション

fine grain users permissions

対象のパーミッションは map-roles です。これは、管理者のみがロールをユーザーにマッピングできるようにする制限ポリシーです。map-roles パーミッションをクリックし、作成したユーザーポリシーを再度追加すると、sales-admin はロールをどのユーザーにもマッピングできます。

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

view-users の追加

fine grain add view users

11.3.2.1. それをテストします。

次に、master レルムからログアウトし、sales-admin をユーザー名として使用し、test レルムの 専用の管理コンソール に再ログインします。これは /auth/admin/test/console にあります。

これで、sess-admin がシステムにユーザーを表示できるようになります。ユーザーの 1 つを選択すると、各ユーザー詳細ページが読み取り専用であることが表示されます (Role Mappings タブを除く)。これらのタブに移動すると、sales-application ロールをブラウズした場合を除き、admin がユーザーにマップするのに 使用可能な ロールがないことが確認できます。

viewLeads の追加

fine grain add view leads

sales-adminviewLeads ロールをマッピングすることのみを指定しました。

11.3.2.2. クライアントごとのマップショートカット

sales-application を公開するすべてのクライアントロールに対してこれを行う必要がある場合や、より容易になってしまうと、管理者がクライアントで定義されているすべてのロールをマップできるように指定する方法があります。マスターレルム admin に管理コンソールにログインし、sales-application パーミッションページに戻ると、map-roles パーミッションが表示されます。

クライアント map-roles パーミッション

fine grain client permissions tab on

この特別なパッションへのアクセスを管理者に付与すると、その admin はクライアントで定義されるロールをマップできます。

11.3.3. パーミッションの完全リスト

特定のクライアントやクライアントの特定のロールの管理以外に、より詳細なパーミッションを設定することが可能です。本章では、レルムに設定できるパーミッションタイプ全体を定義します。

11.3.3.1. ロール

特定のロールの Permissions タブに移動すると、これらのパーミッションタイプが表示されます。

map-role
管理者がこのロールをユーザーにマッピングできるかどうかを決定するポリシー。これらのポリシーは、管理者がユーザーロールマッピングタスクを実行することが許可されているわけではなく、ロールをユーザーにマッピングできることのみを指定します。また、管理者は管理またはロールのマッピングパーミッションを持っている必要があります。詳細は、「ユーザーパーミッション」を参照してください。
map-role-composite
管理者がこのロールを複合としてマッピングできるかどうかを決定するポリシー。管理者は、そのクライアントのパーミッションを管理しているにも拘らず、ロールの map-role-composite 権限がない場合は、クライアントのロールを定義できます。
map-role-client-scope
管理者がこのロールをクライアントの範囲に適用するかどうかを決定するポリシー。管理者がクライアントを管理できる場合でも、この特権が付与されない限り、このロールを含むクライアントのトークンを作成するパーミッションがありません。

11.3.3.2. クライアント

特定のクライアントのパーミッションタブに移動すると、これらのパーミッションタイプが表示されます。

view
管理者がクライアントの設定を表示できるかどうかを決定するポリシー。
manage
管理者がクライアントの設定を表示および管理するかどうかを判断するポリシー。この場合、特権は意図せずにリークする可能性があるという問題があります。たとえば、管理者がロールをクライアントのスコープにマップする権限を持たない場合でも、管理者はロールをハードコーディングするプロトコルマッパーを定義できます。これは、現状に個別のパーミッションを割り当てる方法がないため、プロトコルマッパーの制限になります。
configure
クライアントを管理するプラルジのセットが減ります。これは、admin 以外の manage スコープと同様に、プロトコルマッパーの定義、クライアントテンプレートの変更、クライアントのスコープなどが許可されていません。
map-roles
管理者がクライアントで定義したロールをユーザーにマップできるかどうかを決定するポリシー。これは、クライアントによって定義されるすべてのロールにポリシーに対応できるため、ショートカットで使いやすい機能です。
map-roles-composite
管理者がクライアントで定義したロールを別のロールに複合としてマッピングできるかどうかを決定するポリシー。これはショートカットであり、使いやすく、クライアントが定義した各ロールのポリシーを定義する必要はありません。
map-roles-client-scope
管理者がクライアントで定義した任意のロールを別のクライアントのスコープにマッピングできるかどうかを決定するポリシー。これはショートカットであり、使いやすく、クライアントが定義した各ロールのポリシーを定義する必要はありません。

11.3.3.3. ユーザー

全ユーザーの Permissions タブに移動すると、全ユーザーのパーミッションタイプが一覧表示されます。

view
管理者がレルム内のすべてのユーザーを表示できるかどうかを決定するポリシー。
manage
管理者がレルム内のすべてのユーザーが管理できるかどうかを決定するポリシー。このパーミッションは管理者にユーザーロールのマッピングごとに特権を付与しますが、管理者がマッピングできるロールを指定しません。admin がマッピングできるように、各ロールに特権を定義する必要があります。
map-roles
これは、manage スコープによって付与される権限のサブセットです。この場合、管理者はロールのみをマップできます。admin は、他のユーザー管理操作を実行できません。また、admin の適用が許可されるロールは、クライアントロールに対応する場合はロールごとまたはロールのセットごとに指定する必要があります。
manage-group-membership
map-roles と同様に、グループメンバーシップに関連するものを除き、ユーザーが追加または削除できるグループです。これらのポリシーは、管理者がメンバーシップを管理できるグループではなく、グループメンバーシップを管理する admin パーミッションを付与します。各グループの manage-members パーミッションにポリシーを指定する必要があります。
切り替え
他のユーザーの権限を借用できるかを決定するポリシー。これらのポリシーは、管理者の属性およびロールマッピングに適用されます。
user-impersonated
権限を借用できるユーザーを決定するポリシー。これらのポリシーは、権限を借用するユーザーに適用されます。たとえば、管理者権限のあるユーザーを偽装するポリシーを定義する場合などです。

11.3.3.4. グループ

特定のグループの Permissions タブに移動すると、これらのパーミッションタイプが表示されます。

view
管理者がグループの情報を表示するかどうかを決定するポリシー。
manage
管理者がグループの設定を管理するかどうかを決定するポリシー。
view-members
管理者がグループのメンバーのユーザーの詳細を表示できるかどうかを決定するポリシー。
manage-members
管理者がこのグループに所属するユーザーを管理するかどうかを決定するポリシー。
manage-membership
管理者がグループのメンバーシップを変更できるかどうかを決定するポリシー。グループからメンバーを追加または削除します。

11.4. レルムキー

Red Hat Single Sign-On によって使用される認証プロトコルには、暗号化署名が必要になり、暗号化時があります。Red Hat Single Sign-On では、非対称鍵のペア (秘密鍵と公開鍵) を使用してこれを実現します。

Red Hat Single Sign-On には、同時にアクティブなキーペアが 1 つ含まれますが、複数のパッシブキーを持つこともできます。アクティブなキーペアは新規署名の作成に使用されますが、パッシブキーペアを使用して以前の署名を検証することができます。これにより、ダウンタイムやユーザーの中断なしにキーを定期的にローテーションできます。

レルムがキーペアが作成されると、自己署名証明書が自動的に生成されます。

レルムにアクティブな鍵を表示するには、管理コンソールでレルムを選択し、Realm settingsKeys をクリックします。これでレルムのアクティブなキーが表示されます。

パッシブキーまたは無効なキーを表示するには、Passive または Disabled を選択します。キーペアにはステータスが Active になりますが、現在レルムにアクティブなキーペアとして選択されません。署名に使用される選択したアクティブなペアは、優先度別にソートされた最初のキープロバイダーに基づいて選択され、アクティブなキーペアを提供できます。

11.4.1. 鍵のローテーション

鍵を定期的にローテーションすることが推奨されます。これを実行するには、既存のアクティブなキーよりも優先度が高い新しいキーを作成して開始する必要があります。または、同じ優先順位で新しいキーを作成し、以前のキーパッシブを作成します。

新しい鍵が利用可能になると、新しいトークンと cookie はすべて新しいキーで署名されます。ユーザーがアプリケーションに対して認証されると、SSO クッキーは新しい署名で更新されます。OpenID Connect トークンを更新すると、新しいキーで新たなトークンが署名されます。つまり、時間が経過するとすべての Cookie とトークンが新しいキーを使用し、古いキーを削除できる間に続きます。

古いキーを削除するまでの待機時間は、セキュリティー間のトレードオフであり、すべての cookie とトークンが更新されるようにします。通常は、数週間後に古いキーをドロップすることができます。追加された新しい鍵の間にアクティブでアクティブで、以前のキーが削除されるユーザーは再認証する必要があります。

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

ガイドラインとして、3 〜 6 か月ごとに新しいキーを作成し、新規キーの作成後に古いキー 1-2 か月を削除することが推奨されます。

11.4.2. 生成されたキーペアの追加

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

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

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

11.4.3. 既存のキーペアおよび証明書の追加

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

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

キーの署名済み証明書がある場合は、X509 Certificate の横にある Select file をクリックします。これを省略できます。これを行わないと、自己署名証明書が生成されます。

11.4.4. Java キーストアからキーを読み込む

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

KeystoreKeystore PasswordKey Alias、および Key Password の値を入力し、Save をクリックします。

11.4.5. 鍵のパッシブの作成

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

11.4.6. キーの無効化

Active でキーペアを見つけ、Provider 列でプロバイダーをクリックします。これにより、キープロバイダーの設定画面に移動します。Enabled をクリックして OFF をオンにし、Save をクリックします。この鍵は有効ではなくなります。

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

11.4.7. 侵害された鍵

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

その後、クライアントアプリケーションが、侵害された鍵によって署名されたトークンを受け入れないようにするには、管理コンソールから実行できるレルムの not-before ポリシーを更新し、プッシュする必要があります。新しいポリシーをプッシュすることで、クライアントアプリケーションが侵害された鍵によって署名された既存のトークンを受け入れないようにすることができますが、クライアントアプリケーションも Red Hat Single Sign-On から新しいキーペアをダウンロードするように強制するため、不正アクセスされたキーによって署名されたトークンは有効になりません。REST および機密クライアントには Admin URL を設定する必要があるため、Red Hat Single Sign-On はプッシュされない not-before ポリシーに関して要求を送信できることに注意してください。

第12章 ID ブローカー

Identity Broker は、複数のサービスプロバイダーを異なるアイデンティティープロバイダーに接続する中間サービスです。中間サービスとして、アイデンティティーブローカーは外部アイデンティティープロバイダーとの信頼関係を作成し、そのアイデンティティーを使用してサービスプロバイダーによって公開される内部サービスにアクセスします。

ユーザーの観点からは、ID ブローカーは、異なるセキュリティードメインまたはレルム全体でアイデンティティーを管理するユーザー中心および集中的な方法を提供します。既存のアカウントは、異なるアイデンティティープロバイダーからの 1 つ以上のアイデンティティーとリンクしたり、そこから取得されたアイデンティティー情報に基づいて作成することもできます。

ID プロバイダーは、通常、ユーザーの認証および承認情報の認証および通信に使用される特定のプロトコルに基づいています。Facebook、Google、または Twitter などのソーシャルプロバイダーになります。これは、ユーザーがサービスにアクセスする必要があるビジネスパートナーにすることができます。または、統合するクラウドベースのアイデンティティーサービスになります。

通常、アイデンティティープロバイダーは以下のプロトコルに基づきます。

  • SAML v2.0
  • OpenID Connect v1.0
  • OAuth v2.0

次のセクションでは、Red Hat Single Sign-On を ID ブローカーとして設定および使用する方法を、以下のような重要な側面を説明します。

  • Social Authentication
  • OpenID Connect v1.0 Brokering
  • SAML v2.0 Brokering
  • Identity Federation

12.1. ブローカーの概要

Red Hat Single Sign-On をアイデンティティーブローカーとして使用する場合、ユーザーは特定のレルムで認証するためにクレデンシャルの提供は強制的にされません。代わりに、これは認証が可能なアイデンティティープロバイダーの一覧と共に表示されます。

デフォルトのアイデンティティープロバイダーを設定することもできます。この場合、ユーザーには選択が指定されませんが、代わりにデフォルトプロバイダーにリダイレクトされます。

以下の図は、Red Hat Single Sign-On を使用して外部アイデンティティープロバイダーを仲介する場合に役立ちます。

Identity Broker Flow

identity broker flow

  1. ユーザーは認証されず、クライアントアプリケーションで保護されたリソースを要求します。
  2. クライアントアプリケーションは、ユーザーを Red Hat Single Sign-On にリダイレクトして認証を行います。
  3. この時点では、ユーザーがレルムに設定されたアイデンティティープロバイダーの一覧があるログインページに表示されます。
  4. ユーザーは、該当するボタンまたはリンクをクリックし、アイデンティティープロバイダーの 1 つを選択します。
  5. Red Hat Single Sign-On は、認証を要求するターゲットアイデンティティープロバイダーへの認証要求を実行し、ユーザーはアイデンティティープロバイダーのログインページにリダイレクトされます。アイデンティティープロバイダーの接続プロパティーおよびその他の設定オプションは、以前は管理コンソールの管理者が設定されました。
  6. ユーザーは、アイデンティティープロバイダーでの認証を行うために、認証情報または応答を提供します。
  7. アイデンティティープロバイダーによる認証に成功すると、ユーザーは認証応答で Red Hat Single Sign-On にリダイレクトされます。この応答には、アイデンティティープロバイダーによって実行された認証を信頼し、ユーザーの情報を取得するために Red Hat Single Sign-On によって使用されるセキュリティートークンが含まれます。
  8. Red Hat Single Sign-On は、アイデンティティープロバイダーからの応答が有効かどうかをチェックします。有効な場合は、新規ユーザーをインポートして作成するか、ユーザーがすでに存在する場合のみを省略してください。Red Hat Single Sign-On が新しいユーザーである場合は、その情報がトークンに存在しない場合は、アイデンティティープロバイダーにユーザーについての情報が尋ねられることがあります。これは、アイデンティティーフェデレーションです。ユーザーが Red Hat Single Sign-On がすでに存在する場合は、アイデンティティープロバイダーから返されたアイデンティティーを既存のアカウントにリンクするよう要求します。このプロセスは、アカウントのリンク設定 と呼ばれています。次の作業は設定可能で、最初のログインフローで設定することで指定できます。この手順の最後で、Red Hat Single Sign-On がユーザーを認証し、サービスプロバイダーで要求されたリソースにアクセスするためにユーザーに認証し、独自のトークンを発行します。
  9. ユーザーをローカルで認証されたら、Red Hat Single Sign-On は、ローカル認証時に以前に発行されたトークンを送信することで、ユーザーをサービスプロバイダーにリダイレクトします。
  10. サービスプロバイダーは Red Hat Single Sign-On からトークンを受け取り、保護されたリソースへのアクセスを許可します。

このフローは、後で通信するいくつかのバリエーションがあります。たとえば、アイデンティティープロバイダーの一覧を表示する代わりに、クライアントアプリケーションは特定のプロバイダーを要求できます。または、Red Hat Single Sign-On に、ユーザーをユーザーを ID をフェデレーションする前に追加情報を提供できるように指示できます。

注記

プロトコルによって異なる認証フローが必要になる場合があります。現時点では、Red Hat Single Sign-On でサポートされるすべてのアイデンティティープロバイダーは上記のフローを使用します。ただし、使用中のプロトコルに関係なく、ユーザーエクスペリエンスは非常に大きく行ってください。

ご覧のとおり、認証プロセスの最後に、Red Hat Single Sign-On は常に独自のトークンをクライアントアプリケーションに対して発行します。つまり、クライアントアプリケーションは、外部アイデンティティープロバイダーから完全に切り離されます。どのプロトコル (SAML、OpenID Connect、OAuth など) が使用されているか、またはユーザーのアイデンティティーが検証された方法を把握する必要はありません。Red Hat Single Sign-On を把握する必要があるのは、Red Hat Single Sign-On のみです。

12.2. デフォルトのアイデンティティープロバイダー

ログインフォームを表示する代わりに、アイデンティティープロバイダーに自動的にリダイレクトすることができます。管理コンソールの Authentication ページに移動し、Browser フローを選択します。次に、Identity Provider Redirector オーセンティケーターの設定をクリックします。Default Identity Provider を、ユーザーを自動的にリダイレクトする ID プロバイダーのエイリアスに設定します。

設定されたデフォルトのアイデンティティープロバイダーが見つからない場合は、代わりにログインフォームが表示されます。

このオーセンティケーターは、kc_idp_hint クエリーパラメーターにも対応します。詳細は、「クライアント推奨される ID プロバイダー」のセクションを参照してください。

12.3. 一般的な設定

アイデンティティーブローカー設定は、ID プロバイダーをベースとしています。アイデンティティープロバイダーは各レルムに対して作成され、デフォルトでは各アプリケーションに対して有効になります。つまり、レルムからのユーザーは、アプリケーションへのサインイン時に登録されたいずれかのアイデンティティープロバイダーを使用できます。

ID プロバイダーを作成するには、左側のメニュー項目 Identity Providers をクリックします。

ID プロバイダー

identity providers

ドロップダウンリストで、追加する ID プロバイダーを選択します。これにより、アイデンティティープロバイダータイプの設定ページに移動します。

ID プロバイダーの追加

add identity provider

上記は、Google ソーシャルログインプロバイダーを設定する例です。IDP を設定すると、オプションとして Red Hat Single Sign-On ログインページに表示されます。

IDP ログインページ

identity provider login page

ソーシャル
ソーシャルプロバイダーを使用すると、レルムでソーシャル認証を有効にできます。Red Hat Single Sign-On により、ユーザーはソーシャルネットワークのある既存のアカウントを使用してアプリケーションにログインすることが容易になります。現在サポートされるプロバイダーには、Twitter、Facebook、Google、LinkedIn、Instagram、Microsoft、PayPal、Openshift v3、GitHub、GitLab、Bitbucket、および Stack Overflow が含まれます。
プロトコルベース
プロトコルベースのプロバイダーは、ユーザーの認証および承認に特定のプロトコルに依存するものです。これにより、特定のプロトコルに準拠するアイデンティティープロバイダーに接続できます。Red Hat Single Sign-On は、SAML v2.0 プロトコルおよび OpenID Connect v1.0 プロトコルのサポートを提供します。これらのオープン標準に基づいてアイデンティティープロバイダーを簡単に設定し、ブローカーすることが容易になります。

それぞれの種類のアイデンティティープロバイダーには独自の設定オプションがありますが、それらはすべて非常に共通の設定を共有します。作成するアイデンティティープロバイダーに関係なく、以下の設定オプションを確認できます。

表12.1 共通の設定

設定説明

エイリアス

エイリアスはアイデンティティープロバイダーの一意の ID です。これはアイデンティティープロバイダーを内部で参照するために使用されます。OpenID Connect などのプロトコルには、アイデンティティープロバイダーと通信するためにリダイレクト URI やコールバック URL が必要です。この場合、エイリアスはリダイレクト URI の構築に使用されます。単一のアイデンティティープロバイダーはすべてエイリアスが必要です。例として、facebookgoogleidp.acme.com などがあります。

有効

プロバイダーのオン/オフを切り替えます。

ログインページで非表示

このスイッチがオンになると、ログインページにログインオプションとしてこのプロバイダーは表示されません。クライアントは、ログインの要求に使用する URL の 'kc_idp_hint' パラメーターを使用して、このプロバイダーの使用を引き続き要求できます。

アカウントのリンクのみ

このスイッチがオンの場合、このプロバイダーを使用してログインユーザーにはログインできず、ログインページのオプションとしては表示されません。ただし、既存のアカウントをこのプロバイダーにリンクできます。

トークンの保存

アイデンティティープロバイダーから受け取ったトークンを保存するかどうか。

保存されたトークンの読み取り可能

ユーザーが保存されたアイデンティティープロバイダートークンを取得できるかどうか。これは、broker クライアントレベルのロール read token にも適用されます。

信頼メール

アイデンティティープロバイダーがメールアドレスを提供する場合は、このメールアドレスが信頼されます。レルムにメール検証が必要な場合、この IDP からログインするユーザーはメールの検証プロセスを行う必要はありません。

GUI 順序

ログインページに、利用可能な IDP がどのように表示されているかを並べ替える注文番号。

最初のログインフロー

これは、この IDP を初めてログインしたときに Red Hat Single Sign-On にログインするユーザーにトリガーされる認証フローです。

ログイン後のフロー

ユーザーが外部アイデンティティープロバイダーでのログインを終了するとトリガーされる認証フロー。

12.4. ソーシャルアイデンティティープロバイダー

インターネット向けのアプリケーションでは、ユーザーがアクセスを取得するためにサイトに登録できるように非常にリスクがあります。別のユーザー名とパスワードの組み合わせを覚えておく必要があります。ソーシャルアイデンティティープロバイダーを使用すると、ユーザーがアカウントがすでに持っている可能性のあるセミコロンの信頼されているエンティティーに認証を委譲できます。Red Hat Single Sign-On は、Google、Facebook、Twitter、GitHub、LinkedIn、Microsoft および Stack Overflow などの最も一般的なソーシャルネットワークの組み込みサポートを提供します。

12.4.1. Bitbucket

Bitbucket を使用したログインを有効にするためには、多くの手順を完了する必要があります。

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

ID プロバイダーの追加

bitbucket add identity provider

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

注記

このページの Redirect URI は後のステップで使用します。この URI は、Red Hat Single Sign-On をクライアントとして登録する際に GitLab に提供します。

新規アプリケーションの追加

Bitbucket でのログインを有効にするには、最初に Bitbucket Cloud の OAuth にアプリケーションプロジェクトを登録する必要があります。

注記

Bitbucket は多くの場合、アプリケーション登録の外観と操作感を変更する可能性があるため、Bitbucket サイトに表示される内容が異なる場合があります。不明な場合には、Bitbucket ドキュメントを参照してください。

bitbucket developer applications

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

アプリケーションの登録

bitbucket register app

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

同じページで、Account の下の Email および Read ボックスにマークを付け、アプリケーションがユーザーのメールを読み取ることを許可します。

Bitbucket アプリケーションページ

bitbucket app page

登録が完了したら、Save をクリックします。これにより、Bitbucket でアプリケーション管理ページが開きます。このページからクライアント ID とシークレットを検索し、Red Hat Single Sign-On の Add identity provider ページにそのクライアント ID とシークレットを入力できます。Save をクリックします。

12.4.2. Facebook

Facebook を使用したログインを有効にするためには、多くの手順を完了する必要があります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから Facebook を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

facebook add identity provider

Facebook から Client ID および Client Secret を取得する必要があるため、まだ保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Facebook に提供する必要があるため、この URI をクリップボードにコピーします。

ログインを有効にするには、最初に Facebook Developer Console でプロジェクトとクライアントを作成する必要があります。

注記

Facebook は多くの場合、Facebook Developer Console の外観と操作感を変更する可能性があるため、これらの方向は常に最新の状態で、設定手順が若干異なる場合があります。

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

新規アプリケーションの追加

facebook add new app

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

新規アプリケーション ID の作成

facebook create app id

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

新規アプリケーション ID の作成

facebook app settings

このページの最後にある + Add Platform ボタンをクリックし、Website アイコンを選択します。Red Hat Single Sign-On の Add identity provider ページから、Facebook の Website 設定ブロックの Site URLRedirect URI をコピーアンドペーストします。

Web サイトの指定

facebook app settings website

その後、Facebook app public を作成する必要があります。左メニューの項目の App Review をクリックし、ボタンを "Yes" に切り替えます。

このページから App ID および App Secret を取得して、Red Hat Single Sign-On の Add identity provider ページを入力する必要もあります。これを取得するには、左側のメニュー項目 Dashboard をクリックし、App Secret の下にある Show をクリックします。Red Hat Single Sign-On に戻り、それらの項目を指定し、最後に Facebook Identity Provider を保存します。

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

12.4.3. GitHub

GitHub でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから GitHub を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

github add identity provider

GitHub から Client ID および Client Secret を取得する必要があるため、Save はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを GitHub に提供する必要があるため、この URI をクリップボードにコピーします。

GitHub でのログインを有効にするには、まず GitHub Developer アプリケーション でアプリケーションプロジェクトを登録する必要があります。

注記

GitHub は、アプリケーション登録の外観と操作感を変更することが多く、これらの対象は最新の状態で、設定手順が若干異なる場合があります。

新規アプリケーションの追加

github developer applications

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

アプリケーションの登録

github register app

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

GitHub アプリケーションページ

github app page

このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

12.4.4. GitLab

GitLab でログインを有効にするために実行する必要のある手順が複数あります。

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

ID プロバイダーの追加

gitlab add identity provider

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

注記

このページの Redirect URI は後のステップで使用します。この URI は、Red Hat Single Sign-On をクライアントとして登録する際に GitLab に提供します。

GitLab でログインを有効にするには、まず GitLab でアプリケーションを OAuth2 認証サービスプロバイダーとして登録する必要があります。

注記

GitLab は、アプリケーション登録の外観と操作感を変更することが多く、GitLab サイトに表示される内容が異なる場合があります。疑問がある場合は、GitLab ドキュメントを参照してください。

新規アプリケーションの追加

gitlab developer applications

Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、GitLab Add 新規アプリケーションページの Redirect URI フィールドにその URI を入力します。

GitLab App ページ

gitlab app page

登録が完了したら、Save application をクリックします。これにより、GitLab でアプリケーション管理ページが開きます。このページからクライアント ID とシークレットを検索し、Red Hat Single Sign-On の Add identity provider ページにそのクライアント ID とシークレットを入力できます。

終了するには、Red Hat Single Sign-On に戻り、そのクライアント ID とシークレットを入力します。Save をクリックします。

12.4.5. Google

Google でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから Google を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

google add identity provider

Google から クライアント ID および クライアントシークレット を取得する必要があるため、保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Google に提供する必要があるため、この URI をクリップボードにコピーします。

Google でログインを有効にするには、最初に Google Developer Console でプロジェクトとクライアントを作成する必要があります。クライアント ID およびシークレットを Red Hat Single Sign-On 管理コンソールにコピーする必要があります。

注記

Google は多くの場合、Google Developer Console の外観と操作感を変更する可能性があるため、これらの方向は常に最新の状態で、設定手順が若干異なる場合があります。

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

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

Google 開発者コンソール

google developer console

Create Project ボタンをクリックします。Project nameProject ID に任意の値を使用してから Create ボタンをクリックします。プロジェクトが作成されるまで待機します (しばらく時間がかかる場合があります)。作成されると、プロジェクトのダッシュボードに移動します。

ダッシュボード

google dashboard

次に、Google Developer Console の API & Services セクションに移動します。この画面で、Credentials の管理 に移動します。

Red Hat Single Sign-On から Google にログインすると、Google から consent 画面が表示され、Red Hat Single Sign-On がユーザープロファイルの情報を表示できるかどうかをユーザーに尋ねます。そのため、Google では、シークレットを作成する前に製品に関する基本的な情報が必要になります。新規プロジェクトでは、OAuth consent screen を設定しておく必要があります。

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

OAuth consent screen details

google oauth consent screen

次の手順では、OAuth クライアント ID およびクライアントシークレットを作成します。Credentials 管理に戻り、Credentials タブに移動し、Create credentials ボタンの下にある OAuth client ID を選択します。

認証情報の作成

google create credentials

その後、Create OAuth client ID ページに移動します。アプリケーションタイプとして Web application を選択します。クライアントの名前を指定します。Redirect URI を Red Hat Single Sign-On の Add Identity Provider ページから Authorized redirect URIs フィールドにコピーアンドペーストする必要があります。この作業を行ったら、Create ボタンをクリックします。

OAuth クライアント ID の作成

google create oauth id

Create をクリックすると、Credentials ページに移動します。新しい OAuth 2.0 Client ID をクリックし、新しい Google Client の設定を表示します。

Google クライアント認証情報

google client credentials

このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

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

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

12.4.6. LinkedIn

LinkedIn でログインを有効にするために実行する必要のある手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから LinkedIn を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

linked in add identity provider

Client ID および Client Secret を LinkedIn から取得する必要があるため、まだ保存をクリックします。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際に LinkedIn が提供されるため、この URI をクリップボードにコピーする必要があります。

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

注記

LinkedIn はアプリケーション登録の外観と操作感を変更する可能性があるため、これらの方向は常に最新の状態であるとは限りません。

Developer Network

linked in developer network

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

アプリケーションの作成

linked in create app

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

アプリケーション設定

linked in app settings

Default Application Permissions セクションで、r_basicprofile および r_emailaddress を選択します。Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーして、LinkedIn アプリケーション設定ページの OAuth 2.0 Authorized Redirect URLs フィールドに入力する必要があります。この作業を行ったら、忘れずに Update ボタンをクリックしてください。

次に、このページからクライアント ID およびシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページでクライアント ID とシークレットを入力できます。Red Hat Single Sign-On に戻り、その項目を指定します。

12.4.7. Microsoft

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

ID プロバイダーの追加

microsoft add identity provider

Microsoft から Client ID および Client Secret を取得する必要があるため、保存はクリックできません。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際に、Microsoft に提供する必要があります。したがって、この URI をクリップボードにコピーする必要があります。

Microsoft アカウントを使用したログインを有効にするには、まず OAuth アプリケーションを Microsoft に登録する必要があります。URL Microsoft Application Registration に移動します。

注記

Microsoft は、アプリケーション登録の外観と操作感を変更することが多く、これらの対象は最新の状態で、設定手順が若干異なる場合があります。

アプリケーションの登録

microsoft app register

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

設定

microsoft app settings

Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、Microsoft アプリケーションページの Redirect URIs フィールドに追加する必要があります。Add Url ボタンをクリックし、変更を 保存 します。

最後に、このページからアプリケーション ID とシークレットを取得する必要があります。これにより、Red Hat Single Sign-On の Add identity provider ページに戻すことができます。Red Hat Single Sign-On に戻り、その項目を指定します。

警告

2018 年 11 月以降、Microsoft は新しい Microsoft Graph API を優先して、ライブ SDK API のサポートを削除しています。Red Hat Single Sign-On の Microsoft アイデンティティープロバイダーが新しいエンドポイントを使用するように更新され、このプロバイダーを使用できるように Red Hat Single Sign-On バージョン 7.2.5 以降にアップグレードしてください。Microsoft に「Live SDK applications」の下に登録されているクライアントアプリケーションは、Microsoft Graph API と互換性のあるアプリケーション ID を取得するために、Microsoft Application Registration ポータルで再登録する必要があります。

12.4.8. OpenShift 3

注記

現時点で、OpenShift Online は開発者プレビューモードです。本書は、オンプレミスインストールおよびローカルの minishift 開発環境に基づいています。

OpenShift でログインを有効にするために実行する必要のある手順をいくつか紹介します。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから OpenShift を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

openshift add identity provider

OAuth クライアントの登録

oc コマンドラインツールを使用してクライアントを登録できます。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: v1
metadata:
 name: kc-client 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')
1
OAuth クライアントの 名前<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求の実行時に client_id 要求パラメーターとして渡されます。
2
secretclient_secret 要求パラメーターとして使用されます。
3
<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求で指定される redirect_uri パラメーターは、redirectURIs のいずれかの URI と同じ (または接頭辞が付けられた) 必要があります。
4
grantMethod は、このクライアントがトークンを要求し、ユーザーがアクセスを付与していない場合に実行するアクションを判別するために使用されます。

oc create コマンドで定義されるクライアント ID およびシークレットを使用して、Red Hat Single Sign-On の Add identity provider プロバイダーページで再度入力します。Red Hat Single Sign-On に戻り、その項目を指定します。

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

12.4.9. OpenShift 4

注記

OpenShift 4 アイデンティティープロバイダーを設定する前に、正しい OpenShift 4 API URL を確認してください。シナリオによっては、その URL はユーザーから非表示にされる可能性があります。このコマンドを取得する最も簡単な方法は、コマンド curl -s -k -H "Authorization: Bearer $(oc whoami -t)" https://<openshift-user-facing-api-url>/apis/config.openshift.io/v1/infrastructures/cluster | jq ".status.apiServerURL" を実行することです (これには jq コマンドを個別にインストールすることが必要になる場合があります)。多くの場合、アドレスは HTTPS によって保護されます。そのため、コンテナーで X509_CA_BUNDLE を設定し、これを /var/run/secrets/kubernetes.io/serviceaccount/ca.crt に設定する必要があります。それ以外の場合は、Red Hat Single Sign-On は API サーバーと通信できません。

OpenShift 4 でログインを有効にするためにには、いくつかの手順を実行する必要があります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから OpenShift v4 を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

openshift 4 add identity provider

OAuth クライアントの登録

oc コマンドラインツールを使用してクライアントを登録できます。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: v1
metadata:
 name: keycloak-broker 1
secret: "..." 2
redirectURIs:
 - "<copy pasted Redirect URI from OpenShift 4 Identity Providers page>" 3
grantMethod: prompt 4
')
1
OAuth クライアントの 名前<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求の実行時に client_id 要求パラメーターとして渡されます。name パラメーターは、OAuthClient オブジェクトと Red Hat Single Sign-On 設定で同じである必要があります。
2
secretclient_secret 要求パラメーターとして使用されます。
3
<openshift_master>/oauth/authorize および <openshift_master>/oauth/token への要求で指定される redirect_uri パラメーターは、redirectURIs のいずれかの URI と同じ (または接頭辞が付けられた) 必要があります。これを正しく設定する最も簡単な方法は、Red Hat Single Sign-On OpenShift 4 Identity Provider 設定ページから (Redirect URI フィールド) コピーすることです。
4
grantMethod は、このクライアントがトークンを要求し、ユーザーがアクセスを付与していない場合に実行するアクションを判別するために使用されます。

oc create コマンドで定義されるクライアント ID とシークレットを使用して、Red Hat Single Sign-On の Add identity provider ページで再度入力します。Red Hat Single Sign-On に戻り、その項目を指定します。

ヒント

OpenShift API サーバーは、OAuthClientnamesecret 、または redirectURIs が正しくない場合は、The client is not authorized to request a token using this method を返します。クローンした内容を Red Hat Single Sign-On OpenShift 4 Identity Provider ページに正しくコピーしてください。

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

12.4.10. PayPal

PayPal でログインを有効にするには、完了している手順が複数あります。まず、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから PayPal を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

paypal add identity provider

まだ保存することはできません。これは、PayPal からClient ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを PayPal に提供する必要があるため、この URI をクリップボードにコピーします。

PayPal でログインを有効にするには、まず PayPal Developer アプリケーション でアプリケーションプロジェクトを登録する必要があります。

新規アプリケーションの追加

paypal developer applications

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

アプリケーションの登録

paypal register app

これで、アプリケーション設定ページに移動します。

以下の変更を加えます。

  • Sandbox または Live のいずれかを設定します (Add identity provider ページのTarget Sandbox スイッチを有効にしていない場合は Live を選択します)。
  • Red Hat Single Sign-On の Add identity provider ページに貼り付けるように、クライアント ID およびシークレットをコピーします。
  • App Settings までスクロールダウン
  • Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーし、Return URL フィールドに入力します。
  • Log In with PayPal チェックボックスを選択します。
  • 個人情報セクションの Full name チェックボックスを確認します。
  • アドレス情報 セクションの下にある Email address チェックボックスを確認します。
  • ドメインの該当ページを参照するプライバシーとユーザー合意 URL の両方を追加します。

12.4.11. Stack Overflow

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

ID プロバイダーの追加

stack overflow add identity provider

Stack Overflow でログインを有効にするには、最初に StackApps で OAuth アプリケーションを登録する必要があります。Stack Apps URL およびログインでアプリケーションを登録します。

注記

スタックのオーバーコミットにより、アプリケーション登録の外観と操作感が変更されることが多く、これらの方向は常に最新の状態で、設定の手順が若干異なる場合があります。

アプリケーションの登録

stack overflow app register

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

設定

stack overflow app settings

最後に、このページからクライアント ID、シークレット、およびキーを取得し、Red Hat Single Sign-On Add Add identity provider にそれを戻す必要があります。Red Hat Single Sign-On に戻り、その項目を指定します。

12.4.12. Twitter

Twitter でログインを有効にするために必要な多くのステップがあります。最初に、Identity Providers の左側のメニュー項目に移動し、Add provider ドロップダウンリストから Twitter を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

twitter add identity provider

まだ保存することはできません。これは、Twitter から Client ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Twitter に提供する必要があるため、この URI をクリップボードにコピーします。

Twitter によるログインを有効にするには、最初に Twitter Application Management でアプリケーションを作成する必要があります。

アプリケーションの登録

twitter app register

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

アプリケーションの登録

twitter app create

Name および Description を入力します。Web サイトは任意に指定できますが、localhost アドレスを持つことはできません。Callback URL の場合は、Red Hat Single Sign-On の Add Identity Provider ページから Redirect URI をコピーする必要があります。

警告

Callback URLlocalhost を使用することはできません。代わりに、ラップトップで Twitter ログインをテストする場合は 127.0.0.1 に置き換えてください。

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

アプリケーションの詳細

twitter details

次に Keys and Access Tokens タブに移動します。

キーおよびアクセストークン

twitter keys

最後に、このページから API キーとシークレットを取得し、それらを Red Hat Single Sign-On の Add identity provider ページの Client ID および Client Secret フィールドにコピーする必要があります。

12.4.13. Instagram

Instagram でログインを有効にするために必要な多くのステップがあります。最初に、Identity Providers の左側のメニュー項目に移動し、Add provider ドロップダウンリストから Instagram を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

instagram add identity provider

まだ保存することはできません。これは、Instagram からClient ID および Client Secret を取得する必要はないためです。このページが必要とするデータの 1 つが Redirect URI です。Red Hat Single Sign-On をクライアントとして登録する際にそれを Instagram に提供する必要があるため、この URI をクリップボードにコピーします。

Instagram でログインを有効にするには、まずプロジェクトおよびクライアントを作成する必要があります。Instagram API は、Facebook Developer Console で管理されます。

注記

Facebook は多くの場合、Facebook Developer Console の外観と操作感を変更する可能性があるため、これらの方向は常に最新の状態で、設定手順が若干異なる場合があります。

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

新規アプリケーションの追加

instagram add new app

For Everything Else を選択します。

新規アプリケーション ID の作成

instagram create app id

すべての必須フィールドを入力します。この作業が完了したら、アプリケーションのダッシュボードに移動します。左側のナビゲーションパネルのメニューで、SettingsBasic を選択します。

プラットフォームの追加

instagram add platform

下部の + Add Platform を選択し、globe アイコンで [Website] をクリックします。サイトの URL を指定します。

製品の追加

instagram add product

左側のメニューから Dashboard を選択し、Instagram ボックスで Set Up をクリックします。左側のメニューで InstagramBasic Display を選択し、Create New App をクリックします。

新規 Instagram アプリケーション ID の作成

instagram create instagram app id

Display Name を指定します。

アプリケーションの設定

instagram app settings

Red Hat Single Sign-On の Add identity provider ページから、Instagram Client OAuth Settings 設定ブロックの Valid OAuth Redirect URIsRedirect URI をコピーアンドペーストします。

この URL は Deauthorize Callback URL および Data Deletion Request URL にも使用できます。Red Hat Single Sign-On は現在、それらのいずれかをサポートしていませんが、Facebook Developer Console には両方の入力が必要です。

このページから App ID および App Secret を取得して、Red Hat Single Sign-On の Add identity provider ページを入力する必要もあります。この項目を取得するには、App SecretShow をクリックします。Red Hat Single Sign-On に戻り、それらの項目を指定し、最後に Instagram Identity Provider を保存します。

その後、Instagram アプリケーションを公開する必要があります。左のメニューの App Review をクリックしてから Requests をクリックします。その後、画面の指示に従います。

12.5. OpenID Connect v1.0 アイデンティティープロバイダー

Red Hat Single Sign-On は、OpenID Connect プロトコルに基づいてブローカーアイデンティティープロバイダーを使用できます。ユーザーの認証およびアクセスを承認するには、これらの IDP は仕様によって定義された Authorization Code Flow をサポートする必要があります。

OIDC プロバイダーの設定を開始するには、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから OpenID Connect v1.0 を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

oidc add identity provider

このページの初期設定オプションは、「一般的な IDP 設定」に記載されています。OpenID Connect 設定オプションも定義する必要があります。これらは、通信している OIDC IDP を定期的に説明しています。

表12.2 OpenID Connect の設定

設定説明

認証 URL

OIDC プロトコルで必要な承認 URL エンドポイント。

トークン URL

OIDC プロトコルで必要なトークン URL エンドポイント。

ログアウト URL

OIDC プロトコルで定義された URL エンドポイントをログアウトします。この値はオプションです。

バックチャネルログアウト

Backchannel ログアウトは、バックグラウンド (アウトオブバウンド) IDP への REST 呼び出しで、ユーザーをログアウトします。一部の IDP はブラウザークッキーを介してアイデンティティーセッションのみにアクセスできる可能性があるため、ブラウザーリダイレクトによってログアウトのみを実行できます。

ユーザー情報 URL

OIDC プロトコルで定義されたユーザー Info URL エンドポイント。これは、ユーザープロファイルの情報をダウンロードできるエンドポイントです。

クライアント認証

Authorization Code Flow で使用するクライアント認証メソッドの定義に切り替えます。秘密鍵で署名される JWT の場合、レルムの秘密鍵が使用されます。他の場合は、クライアントシークレットを定義する必要があります。詳細は、「Client Authentication specifications」を参照してください。

クライアント ID

このレルムは、外部 IDP への OIDC クライアントとして機能します。Authorization Code Flow を使用して外部 IDP と対話する場合は、レルムに OIDC クライアント ID が必要です。

Client Secret

このレルムは、Authorization Code Flow を使用する場合に使用するクライアントシークレットが必要です。このフィールドの値は、外部 vault からの値を参照できます。

issuer

IDP からの応答には発行者クレームが含まれる可能性があります。この設定値はオプションです。これが指定されている場合、この要求は指定した値に対して検証されます。

Default Scopes

認証要求で送信する OIDC スコープのスペース区切りの一覧。デフォルトは openid です。

Prompt

他の任意のスイッチ。これは OIDC 仕様で定義されているプロンプトパラメーターです。これにより、再認証やその他のオプションを強制的に実行できます。詳細は、仕様を参照してください。

クライアントからの prompt=none forward を許可します。

IDP が、prompt=none クエリーパラメーターを含む転送された認証要求を受け入れるかどうかを指定します。レルムが prompt=none で認証要求を受信すると、ユーザーが現在認証されており、通常はユーザーがログインしていない場合は login_required エラーを返します。ただし、デフォルトの IDP が認証リクエストに対して (kc_idp_hint クエリーパラグラフまたはレルムのデフォルト IDP を設定して) 決定できる場合は、prompt=none の認証要求をデフォルト IDP に転送して、ユーザーが現在認証されているかどうかを確認することができます。prompt=none が設定されたすべての IDP は、認証要求をリダイレクトする前にデフォルトの IDP が param をサポートしているかどうかを示すために、このスイッチが使用されます。

ユーザーが IDP で認証されていない場合は、クライアントは login_required エラーが出されます。ユーザーが現在 IDP で認証されている場合でも、認証またはユーザーの対話を必要とするページが無駄なページであっても、クライアントは interact_required エラーが出される可能性があります。これには、必要なアクション (パスワードの変更など)、合意画面、first broker login フローまたは post broker login フローで表示される画面が含まれます。

署名の検証

他の任意のスイッチ。これは、Red Hat Single Sign-On がこのアイデンティティープロバイダーによって署名された外部 ID トークンで署名を検証するかどうかを指定します。これがオンの場合、Red Hat Single Sign-On は外部 OIDC アイデンティティープロバイダーを把握しておく必要があります。設定方法については、以下を参照してください。警告: パフォーマンスの目的で、Red Hat Single Sign-On は外部 OIDC アイデンティティープロバイダーの公開鍵をキャッシュします。クライアントアイデンティティープロバイダーの秘密鍵が危険にさらされたと思われる場合は、キーの更新は明らかですが、キーの更新も適切です。詳細は、「キャッシュの消去」セクションを参照してください。

JWKS URL の使用

Validate Signatures が有効な場合に該当します。スイッチがオンの場合、アイデンティティープロバイダーの公開鍵は指定の JWKS URL からダウンロードされます。これにより、アイデンティティープロバイダーが新しいキーペアを生成する際に、新しい鍵が常に再ダウンロードされるため、柔軟性が高くなります。スイッチがオフの場合、Red Hat Single Sign-On DB からの公開鍵 (または証明書) が使用されるため、アイデンティティープロバイダーのペアが変更されるたびに新しい鍵も Red Hat Single Sign-On DB にインポートする必要があります。

JWKS URL

ID プロバイダーの JWK キーが保存される URL。詳細は、「JWK 仕様」を参照してください。外部 Red Hat Single Sign-On を ID プロバイダーとして使用する場合は、http://broker-keycloak:8180 でブローカー設定された Red Hat Single Sign-On が実行していて、そのレルムが test であることを全体として、http://broker-keycloak:8180/auth/realms/test/protocol/openid-connect/certs などの URL を使用できます。

公開鍵の検証

Use JWKS URL をオフにした場合のみ適用可能です。以下は、外部 IDP 署名の検証に使用される PEM 形式の公開鍵です。

公開鍵 ID の検証

Use JWKS URL をオフにした場合のみ適用可能です。このフィールドは PEM 形式の公開鍵の ID を指定します。この設定値はオプションです。キーから計算する標準的な方法がないため、さまざまな外部アイデンティティープロバイダーが Red Hat Single Sign-On とは異なるアルゴリズムを使用する場合があります。このフィールドの値が指定されていない場合、外部 IDP によって送信されるキー ID に関係なく、上記で指定されたパブリックキーはすべての要求に使用されます。設定されている場合、このフィールドの値は、そのようなプロバイダーからの署名を検証するために Red Hat Single Sign-On によって使用されるキー ID として機能し、IDP で指定されるキー ID と一致する必要があります。

OpenID プロバイダーメタデータをポイントする URL またはファイルを指定してこの設定データをすべてインポートすることもできます (OIDC 検出仕様を参照)。Red Hat Single Sign-On 外部 IDP に接続する場合は、URL <root>/auth/realms/{realm-name}/.well-known/openid-configuration から IDP 設定をインポートできます。このリンクは、IDP に関するメタデータを記述する JSON ドキュメントです。

12.6. SAML v2.0 アイデンティティープロバイダー

Red Hat Single Sign-On は、SAML v2.0 プロトコルに基づいてブローカーアイデンティティープロバイダーを使用できます。

SAML v2.0 プロバイダーの設定を開始するには、左側のメニュー項目 Identity Providers に移動し、Add provider ドロップダウンリストから SAML v2.0 を選択します。これにより、Add identity provider ページが表示されます。

ID プロバイダーの追加

saml add identity provider

このページの初期設定オプションは、「一般的な IDP 設定」に記載されています。SAML 設定オプションも定義する必要があります。このユーザーは、基本的に通信している SAML IDP について説明しています。

表12.3 SAML 設定

設定説明

サービスプロバイダーエンティティー ID

これは必須フィールドで、リモートアイデンティティープロバイダーがこのサービスプロバイダーからのリクエストを識別するために使用する SAML エンティティー ID を指定します。デフォルトでは、レルムベース URL <root>/auth/realms/{realm-name} に設定されます。

Single Sign-On Service URL

これは必須フィールドで、認証プロセスを開始する SAML エンドポイントを指定します。SAML IDP が IDP エンティティー記述子を公開する場合、このフィールドの値はそこで指定します。

単一のログアウトサービス URL

これは、SAML ログアウトエンドポイントを指定する任意のフィールドです。SAML IDP が IDP エンティティー記述子を公開する場合、このフィールドの値はそこで指定します。

バックチャネルログアウト

SAML IDP がバックチャネルログアウトに対応しているかどうかを有効にします。

NameID のポリシー形式

名前識別子の形式に対応する URI 参照を指定します。デフォルトは urn:oasis:names:tc:SAML:2.0:nameid-format:persistent です。

プリンシパルタイプ

外部ユーザー ID の特定および追跡に使用される SAML アサーションの一部を指定します。Subject NameID または SAML 属性のいずれかを指定できます (名前または分かりやすい名前のいずれか)。

Principal 属性

Principal が "Attribute [Name]" または "Attribute [Friendly Name]" のいずれかに設定されている場合、このフィールドは、識別属性の名前または分かりやすい名前を指定します。

HTTP-POST バインディング応答

このレルムは外部 IDP によって送信された SAML 要求に応答すると、SAML バインディングを使用する必要があるか。off に設定すると、リダイレクトバインディングが使用されます。

AuthnRequest の HTTP-POST バインディング

このレルムが外部 SAML IDP から認証を要求すると、SAML バインディングを使用する必要がありますか?off に設定すると、リダイレクトバインディングが使用されます。

Want AuthnRequests Signed

true の場合、レルムのキーペアを使用して、外部 SAML IDP に送信される要求に署名します。

署名アルゴリズム

AuthnRequests を署名する が有効になっている場合は、使用する署名アルゴリズムを選択することもできます。

SAML 署名キー名

署名付き SAML ドキュメントには、POST バインディング経由で送信される署名済みのほか、KeyName 要素の署名キーの識別が含まれます。これには、Red Hat Single Sign-On のキー ID が含まれます。ただし、外部 SAML IDP にはそれぞれ異なるキー名を指定したり、キー名もない場合もあります。このスイッチは、KeyName に鍵 ID (KEY_ID オプション) が含まれるか、レルムキーに対応する証明書のサブジェクト (CERT_SUBJECT オプション (Microsoft Active Directory Federation Services に必要なもの) など)、または SAML メッセージからキー名のヒントが完全に省略される (NONE オプション) かどうかを制御します。

認証の強制

ユーザーがすでにログインされていても、外部 IDP で認証情報の入力を強制されることを示します。

署名の検証

レルムが外部 IDP からの SAML 要求および応答にデジタル署名されることが予想されるかどうか。有効にすることを強くお勧めします。

X509 証明書の検証

SAML 要求の署名および外部 IDP からの応答の検証に使用されるパブリック証明書。

OpenID プロバイダーメタデータをポイントする URL またはファイルを指定してこの設定データをすべてインポートすることもできます (OIDC 検出仕様を参照)。Red Hat Single Sign-On の外部 IDP に接続する場合は、URL <root>/auth/realms/{realm-name}/protocol/saml/descriptor から IDP 設定をインポートできます。このリンクは、IDP に関するメタデータを記述する XML ドキュメントです。

接続する外部 SAML IDP のエンティティー記述子を参照する URL または XML ファイルを指定して、この設定データをすべてインポートすることもできます。

12.6.1. SP 記述子

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

このメタデータは、URL に移動することで公開されています。

http[s]://{host:port}/auth/realms/{realm-name}/broker/{broker-alias}/endpoint/descriptor

12.7. クライアント提案されたアイデンティティープロバイダー

OIDC アプリケーションは、使用するアイデンティティープロバイダーのヒントを指定することで、Red Hat Single Sign-On ログインページをバイパスできます。

これには、Authorization Code Flow 承認エンドポイントに kc_idp_hint クエリーパラメーターを設定します。

Red Hat Single Sign-On OIDC クライアントアダプターを使用すると、アプリケーションでセキュアなリソースにアクセスすると、このクエリーパラメーターを指定できます。

以下に例を示します。

GET /myapplication.com?kc_idp_hint=facebook HTTP/1.1
Host: localhost:8080

この場合、レルムにエイリアス facebook を持つアイデンティティープロバイダーが含まれることが予想されます。このプロバイダーが存在しない場合はログインフォームが表示されます。

keycloak.js アダプターを使用している場合は、同じ動作を実行することもできます。

var keycloak = new Keycloak('keycloak.json');

keycloak.createLoginUrl({
	idpHint: 'facebook'
});

また、kc_idp_hint クエリーパラメーターを使用すると、Identity Provider Redirector のオーセンティケーター用に設定されている場合、クライアントはデフォルトのアイデンティティープロバイダーを上書きできるようにします。また、クライアントは kc_idp_hint クエリーパラメーターを空の値に設定することで、自動リダイレクトを無効にすることもできます。

12.8. クレームとアサーションのマッピング

レルムの環境に認証する外部 IDP が提供する SAML および OpenID Connect メタデータをインポートできます。これにより、ユーザープロファイルのメタデータやその他の情報を取得でき、アプリケーションが利用できるようにすることができます。

外部アイデンティティープロバイダー経由でレルムにログインする各新規ユーザーには、SAML または OIDC アサーションおよび要求からのメタデータに基づいて、ローカルの Red Hat Single Sign-On データベースで作成されるエントリーがあります。

レルムの Identity Providers ページに記載されている ID プロバイダーをクリックすると、IDP の Settings タブに移動します。このページには Mappers タブもあります。そのタブをクリックして、受信 IDP メタデータのマッピングを開始します。

identity provider mappers

このページには Create ボタンがあります。この作成 ボタンをクリックすると、ブローカーマッパーを作成できます。ブローカーマッパーは SAML 属性または OIDC ID/アクセストークン要求をユーザー属性とユーザーロールマッピングにインポートできます。

identity provider mapper

Mapper Type リストからマッパーを選択します。ツールチップにマウスをかざして、マッパーの機能の説明を表示します。ツールチップは、入力する必要のある設定情報についても説明します。Save をクリックすると、新しいマッパーが追加されます。

JSON ベースの要求では、ドット表記を使用して、インデックスでアレイフィールドにアクセスするため、ネスト化と角括弧を使用します。たとえば、'contact.address[0].country' です。

ソーシャルプロバイダーが提供するユーザープロファイル JSON データの構造を調べるには、DEBUG レベルのロガー org.keycloak.social.user_profile_dump を有効にします。これは、サーバーの app-server 設定ファイル (domain.xml または standalone.xml) で実行されます。

12.9. 利用可能なユーザーセッションデータ

ユーザーが外部 IDP からログインした後に、Red Hat Single Sign-On ストアがアクセスできるユーザーセッションに関する追加のメモデータがあります。このデータは、適切なクライアントマッパーを使用してトークンまたは SAML アサーションを介してログインを要求するクライアントに伝播できます。

identity_provider
これは、ログインの実行に使用されるブローカーの IDP エイリアスです。
identity_provider_identity
これは、現在認証されたユーザーの IDP ユーザー名です。これは多くの場合、Red Hat Single Sign-On のユーザー名と同じですが、必ずしもリリースされるとは限りません。たとえば、Red Hat Single Sign-On のユーザー john は、Facebook ユーザー john123@gmail.com にリンクできるため、その場合、ユーザーセッションノートの値は john123@gmail.com になります。

User Session Note 型のプロトコルマッパーを使用して 、この情報をクライアントに伝播することに注意してください。

12.10. 最初のログインフロー

ユーザーが ID ブローカーでログインすると、ユーザーのローカルデータベースがインポートされ、リンクされます。Red Hat Single Sign-On が外部アイデンティティープロバイダー経由でユーザーを認証した場合、2 つの状況が考えられます。

  • すでに Red Hat Single Sign-On ユーザーアカウントをインポートし、認証されたアイデンティティープロバイダーアカウントとリンクしています。この場合、Red Hat Single Sign-On は既存ユーザーとして認証し、アプリケーションにリダイレクトします。
  • この外部ユーザーにインポートされ、リンクされている既存の Red Hat Single Sign-On ユーザーアカウントはありません。通常は、新しいアカウントを登録して Red Hat Single Sign-On データベースに登録およびインポートするだけですが、同じメールで既存の Red Hat Single Sign-On アカウントがある場合はどうしたらよいですか?既存のローカルアカウントを外部アイデンティティープロバイダーに自動的にリンクすることは、常に外部アイデンティティープロバイダーからの情報を信頼できないセキュリティーです。

上記の競合や状況に関しては、さまざまな組織の要件が異なります。そのため、IDP 設定には First Login Flow オプションがあり、ユーザーが外部 IDP から初めてログインした後に使用するワークフローを選択できます。デフォルトでは、これは最初の first broker login フローを参照しますが、独自のフローを設定して使用することができ、異なるアイデンティティープロバイダーに異なるフローを使用することができます。

フロー自体は、Authentication タブ下の管理コンソールで設定されます。First Broker Login フローを選択すると、デフォルトで使用されているオーセンティケーターが表示されます。既存のフローを再構成できます。(たとえば、オーセンティケーターを無効にするか、required として、そのオーセンティケーターをマークし、オーセンティケーターを設定します)。

12.10.1. デフォルトの最初のログインフロー

First Broker Login フローで提供されるデフォルトの動作を説明します。

プロファイルの確認
このオーセンティケーターは、ユーザーはアイデンティティープロバイダーから取得したプロファイル情報ページが表示される場合があります。オーセンティケーターは設定可能です。Update Profile On First Login オプションを設定できます。On には常にプロファイルページと共に提示されます。この際、アイデンティティーをフェデレーションするために追加情報の入力を求めます。missing の場合、ユーザーは必須の情報 (電子メール、名、姓) がアイデンティティープロバイダーによって提供されていない場合にのみ、プロファイルページとともに提示されます。Off にすると、ユーザーが、Review profile info リンク (Confirm Link Existing Account オーセンティケーターによる最後の段階で表示される) でクリックしない限り、プロファイルページは表示されません。
Create User If Unique
このオーセンティケーターは、アイデンティティープロバイダーからのアカウントと同じメールまたはユーザー名を持つ既存の Red Hat Single Sign-On アカウントがすでにあるかどうかを確認します。ない場合は、オーセンティケーターは新しいローカルの Red Hat Single Sign-On アカウントを作成し、それをアイデンティティープロバイダーとリンクし、フロー全体を終了します。それ以外の場合は、次の Handle Existing Account サブフローが処理されます。重複アカウントがないことを確認する場合は、このオーセンティケーターを REQUIRED とマークできます。この場合、既存の Red Hat Single Sign-On アカウントがある場合、ユーザーはアカウント管理でアイデンティティープロバイダーアカウントをリンクする必要がある場合に、エラーページが表示されます。
既存のアカウントのリンクの確認
info ページで、同じメールを持つ既存の Red Hat Single Sign-On アカウントがあることを確認できます。プロファイルを再度確認し、異なるメールまたはユーザー名を使用できます (フローは再起動され、Review Profile オーセンティケーターに戻ります)。または、アイデンティティープロバイダーアカウントを既存の Red Hat Single Sign-On アカウントとリンクするかどうかを確認することができます。ユーザーがこの確認ページを表示する必要がない場合は、このオーセンティケーターを無効にしますが、メールの検証または再認証によりアイデンティティープロバイダーアカウントをリンクするよう簡単です。
既存のアカウントをメールで検証
このオーセンティケーターはデフォルトで ALTERNATIVE であるため、レルムに SMTP 設定が設定されている場合のみ使用されます。ユーザーがメールを送信します。ここで、アイデンティティープロバイダーを Red Hat Single Sign-On アカウントとリンクすることを確認できます。メールによるリンクを確認せず、常にパスワード (および OTP) で再認証する方が望ましい場合には、これを無効にします。
再認証による既存のアカウントの確認
メールオーセンティケーターが無効または利用できない場合 (SMTP がレルム用に設定されていない) 場合に使用されます。Red Hat Single Sign-On アカウントをアイデンティティープロバイダーとリンクするためにユーザーが認証する必要があるログイン画面が表示されます。ユーザーは、すでに Red Hat Single Sign-On アカウントにリンクされている異なるアイデンティティープロバイダーで再認証することもできます。ユーザーを強制的に OTP を使用するようにすることもできます。そうでなければ、OTP がユーザーアカウントに既に設定されている場合に限り使用してください。

12.10.3. 自動ユーザー作成の無効化

デフォルトの最初のログインフローは、外部アイデンティティーに一致する Keycloak アカウントを検索し、これらをリンクします。一致する Keycloak アカウントがない場合は、自動的に作成されます。このデフォルトの動作は、読み取り専用の LDAP ユーザーストア (すべてのユーザーが事前に作成されることを意味します) など、一部のセットアップでは適切ではない可能性があります。この場合、自動ユーザー作成をオフにする必要があります。ユーザーの作成を無効にするには、以下を実行します。

  • First Broker Login フロー設定を開きます。
  • Create User if UniqueDISABLED に設定します。
  • Confirm Link Existing AccountDISABLED に設定します。

この設定は、Keycloak 自体が、どの内部アカウントが外部アイデンティティーに対応するかを判断できないことも意味します。そのため、Verify Existing Account By Re-authentication オーセンティケーターにより、ユーザー名およびパスワードが提供されます。

12.11. 外部 IDP トークンの取得

Red Hat Single Sign-On を使用すると、外部 IDP を使用して認証プロセスからのトークンと応答を保存できます。これには、IDP の設定ページで Store Token 設定オプションを使用できます。

アプリケーションコードは、これらのトークンを取得し、追加のユーザー情報でプルしたり、外部 IDP でリクエストを安全に呼び出すことを行うことができます。たとえば、アプリケーションは Google トークンを使用して他の Google サービスおよび REST API で呼び出す場合があります。特定のアイデンティティープロバイダーのトークンを取得するには、以下のようにリクエストを送信する必要があります。

GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1
Host: localhost:8080
Authorization: Bearer <KEYCLOAK ACCESS TOKEN>

アプリケーションが Red Hat Single Sign-On で認証され、アクセストークンを受信している必要があります。このアクセストークンには、ブローカー のクライアントレベルのロール read-token を設定する必要があります。そのため、ユーザーにはこのロールのロールマッピングが必要で、クライアントアプリケーションにそのスコープ内にそのロールがなければなりません。この場合、Red Hat Single Sign-On で保護されたサービスにアクセスする場合には、ユーザー認証時に Red Hat Single Sign-On が発行するアクセストークンを送信する必要があります。ブローカー設定ページでは、Stored Tokens Readable スイッチを有効にして、新たにインポートしたユーザーにこのロールを自動的に割り当てることができます。

これらの外部トークンについては、プロバイダー経由で再度ログインするか、またはクライアントが開始したアカウントリンク API を使用して再度確立できます。

12.12. アイデンティティーブローカーのログアウト

Red Hat Single Sign-On からログアウトすると、Red Hat Single Sign-On は、Keycloak にログインするのに使用される外部アイデンティティープロバイダーにリクエストを送信し、ユーザーはこのアイデンティティープロバイダーからログアウトされます。この動作を省略し、外部アイデンティティープロバイダーでのログアウトを避けることができます。詳細は、アダプターのログアウトドキュメント を参照してください。

第13章 ユーザーセッション管理

ユーザーがレルムにログインすると、Red Hat Single Sign-On はユーザーセッションを維持し、セッションでアクセスした各クライアントおよびクライアントのそれぞれを覚えます。レルム管理者は、これらのユーザーセッションで実行可能な管理機能があります。レルム全体のログイン統計を表示し、各クライアントにログイン統計を表示して、ログインした場所と場所を確認できます。管理者は、ユーザーまたはユーザーのセットを管理コンソールからログアウトできます。トークンを取り消すことができ、すべてのトークンとセッションのタイムアウトを設定できます。

13.1. セッションの管理

左側のメニュー項目 Sessions に移動すると、レルム内で現在アクティブなセッション数の最上位ビューが表示されます。

セッション

sessions

クライアントの一覧と、そのクライアントに対して現在存在するアクティブなセッション数また、この一覧の右側にある Logout all ボタンをクリックして、レルムの全ユーザーをログアウトできます。

13.1.1. Logout all 操作の制限

SSO クッキーセットはすべて無効になり、アクティブなブラウザーセッションで認証を要求するクライアントを再ログインする必要があります。特定のクライアントのみが、このログアウトイベント (特に Red Hat Single Sign-On OIDC クライアントアダプターを使用しているクライアント) に通知されます。SAML などの他のクライアントタイプにはバックチャネルログアウトリクエストを受け取りません。

Logout all をクリックして、未処理のアクセストークンが取り消されていないことに注意してください。自然に期限切れになる必要があります。失効ポリシーをクライアントからプッシュする必要がありますが、Red Hat Single Sign-On OIDC クライアントアダプターを使用するクライアントでも機能することになります。

13.1.2. アプリケーションのドルダウン

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

アプリケーションセッション

application sessions

13.1.3. ユーザードリルダウン

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

ユーザーセッション

user sessions

13.2. 失効ポリシー

システムが危険にさらされたら、すべてのセッションと、省略されたアクセストークンを取り消す方法が必要になります。これには、Sessions 画面の Revocation タブに移動します。

取り消し

revocation

時間ベースの失効ポリシーのみを設定できます。コンソールでは、その期間の前にセッションまたはトークンが無効な日時を指定できます。Set to now によりポリシーが現在の時刻と日付に設定されます。Push ボタンは、この失効ポリシーを、Red Hat Single Sign-On OIDC クライアントアダプターがインストールされている登録された OIDC クライアントにプッシュします。

13.3. セッションおよびトークンのタイムアウト

Red Hat Single Sign-On により、セッション、クッキー、およびトークンのタイムアウトを細かく制御できます。これは、左側のメニュー項目 Realm SettingsTokens タブですべて行われます。

Tokens タブ

tokens tab

各ページのアイテムを追って説明します。

設定説明

デフォルトの署名アルゴリズム

このレルムにトークンを割り当てるために使用されるデフォルトのアルゴリズム。

トークンの更新の取り消し

更新トークンフローを実行する OIDC クライアントの場合、このフラグにより、その更新トークンが取り消され、クライアントが使用する要求で別のトークンを発行します。その結果、各更新トークンは 1 度だけ使用されます。

SSO Session Idle

また、OIDC クライアントも含まれます。ユーザーがこのタイムアウトよりもアクティブではない場合には、ユーザーセッションは無効になります。アイドルタイムアウトは、認証を要求するクライアントまたは更新トークンリクエストによりリセットされます。セッションの無効化が有効になる前に、アイドルタイムアウトに常に追加される小さな期間があります。以下の注記を参照してください。

SSO セッション最大

ユーザーセッションが期限切れになり、無効化される最長時間。このオプションは、ユーザーアクティビティーに関係なく、ユーザーセッションがアクティブなままになる最大時間を制御します。

SSO Session Idle Remember Me

標準の SSO Session Idle の設定と同じですが、Remember Me を有効にしてログインする場合です。ログインプロセス中に Remember Me が選択されている場合、セッションアイドル状態のタイムアウトを長く指定できるようになります。これは任意の設定であり、0 を大きな値に設定しない場合は、SSO Session Idle の設定と同じアイドルタイムアウトを使用します。

SSO Session Max Remember Me

標準の SSO Session Max と同じですが、Remember Me を有効にしてログインする場合です。これにより、ログインプロセス中に Remember Me が選択された場合に、有効期間の長いセッションを指定できます。これは任意の設定であり、0 より大きい値に設定しない場合は、SSO セッション Max 設定と同じセッションライフスパンを使用します。

オフラインセッションのアイドリング

オフラインアクセスの場合は、オフライントークンが取り消される前にセッションがアイドル状態のままになる時間になります。セッションの無効化が有効になる前に、アイドルタイムアウトに常に追加される小さな期間があります。以下の注記を参照してください。

オフラインセッションの最大制限

オフラインアクセスの場合は、このフラグがオンの場合、ユーザーアクティビティーに関係なく、オフライントークンがアクティブな状態を維持できる最大時間を制御するように Offline Session Max が有効になります。

オフラインセッションの最大

offline accessの場合、対応するオフライントークンが無効になるまでの最大時間になります。このオプションは、ユーザーアクティビティーに関係なく、オフライントークンがアクティブな状態を維持する最大時間を制御します。

アクセストークンの寿命

OIDC アクセストークンが作成されると、この値は期限切れに影響します。

インプリシットフロー (Implicit Flow) のアクセストークンのライフサイクル

Implicit Flow では更新トークンが提供されません。このため、Implicit Flow で作成されたアクセストークンには個別のタイムアウトが生じます。

クライアントログインのタイムアウト

これは、クライアントが OIDC で Authorization Code Flow を完了するために必要な最大時間です。

ログインのタイムアウト

ログインにかかる合計時間。認証がこの時間よりも長い場合は、ユーザーが認証プロセスを開始する必要があります。

ログインアクションのタイムアウト

認証プロセスの 1 つのページでユーザーが費やすことができる最大時間。

ユーザーによる開始に関するアクションライフスパン

ユーザーが送信可能なアクションの最大最大時間 (例: パスワードメール) は有効期限が切れます。この値は、ユーザーが簡単に自己作成したアクションに反応するため、短いことが推奨されます。

デフォルトの管理者開始アクションのライフサイクル

管理者がユーザーに送信可能な最大時間は有効期限が切れます。この値は、現在オフラインユーザーに管理者の送信メールができるように長く設定することを推奨します。デフォルトのタイムアウトは、トークンを発行する前にすぐに上書きできます。

ユーザーによる開始処理のオーバーライド

操作 (たとえば、パスワード、ユーザーアクション、アイデンティティープロバイダーの E-mail 検証など) ごとに独立したタイムアウトを取得する可能性を許可します。このフィールドは任意です。何も指定しないと、デフォルトは User-Initiated Action Lifespan で設定された値に設定されます。

注記

アイドルタイムアウトでは、セッションが期限切れから保たれない期間が 2 分ほどあります。たとえば、タイムアウトを 30 分に設定している場合、セッションの有効期限が切れる前に 32 分実際に実行されます。これは、クラスターと複数のデータセンター環境の一部のコーナーシナリオで必要になります。トークンが有効期限前に非常に短い時間で 1 つのクラスターノードで更新され、その他のクラスターノードはセッションの期限切れと誤って見なすため、そのセッションは期限切れと誤って見なわれていないためです。

13.4. オフラインアクセス

オフラインアクセスは、「OpenID Connect 仕様」に記載の機能です。ログイン中に、クライアントアプリケーションは、従来の更新トークンの代わりにオフライントークンを要求します。アプリケーションは、このオフライントークンをデータベースまたはディスクに保存し、ユーザーがログアウトした場合でも後で使用できます。これは、ユーザーがオンラインでない場合でも、ユーザーの代わりに「オフライン」アクションを実行する必要がある場合に有効です。この例は、毎夜ごとの一部のデータの定期的なバックアップです。

アプリケーションは、一部のストレージ (通常はデータベース) でオフライントークンを永続化してから、これを使用して Red Hat Single Sign-On サーバーから新しいアクセストークンを取得します。

従来の更新トークンとオフライントークンの違いは、オフライントークンはデフォルトで期限切れになることはありませんが、SSO Session Idle timeout および SSO Session Max lifespan の影響は受けません。オフライントークンは、ユーザーのログアウトまたはサーバーを再起動しても有効です。ただし、デフォルトでは、少なくても 30 日に 1 回、更新トークンのアクションにオフライントークンを使用する必要があります (この値である Offline Session Idle timeout は、Realm SettingsTokens タブで管理コンソールで変更できます)。さらに、Offline Session Max Limited オプションを有効にすると、更新トークンにオフライントークンを使用するかどうかに関わらず、オフライントークンは 60 日後に期限切れになります (この値である Offline Session Max は、レルム設定の Tokens タブで管理コンソールでも変更できます)。また、Revoke refresh tokens オプションを有効にすると、各オフライントークンを一度に使用できます。したがって、更新後、これまでのトークンではなく、更新応答から DB に新しいオフライントークンを保存する必要があります。

ユーザーは、User Account Service 内で付与されたオフライントークンを表示し、取り消すことができます。管理ユーザーは、特定のユーザーの Consents タブで、管理コンソールで各ユーザーのオフライントークンを取り消すことができます。管理者は、各クライアントの Offline Access タブで発行されたすべてのオフライントークンを表示することもできます。オフライントークンの取り消しは、失効ポリシーを設定して取り消すことができます。

オフライントークンを発行できるようにするには、レルムレベルのロール offline_access のロールマッピングが必要です。クライアントには、そのスコープにそのロールが必要です。最後に、クライアントに 任意のクライアントスコープ として offline_access クライアントスコープを追加する必要があります。これはデフォルトで行われます。

クライアントは、承認要求を Red Hat Single Sign-On に送信するときに scope=offline_access パラメーターを追加することでオフライントークンを要求できます。Red Hat Single Sign-On OIDC クライアントアダプターは、アプリケーションのセキュアな URL にアクセスするために使用する場合に、このパラメーターを自動的に追加します (例: http://localhost:8080/customer-portal/secured?scope=offline_access)。認証要求の本文に scope=offline_access を追加する場合は、Direct Access Grant および Service Accounts もオフライントークンをサポートします。

13.5. 一時的なセッション

Red Hat Single Sign-On には、一時的なセッションの概念があります。一時的なセッションを使用すると、認証の成功後は、ユーザーセッションは作成されません。ユーザーを正常に認証された現在のリクエストの範囲用に一時一時セッションのみが作成されます。この一時的なセッションにより、Red Hat Single Sign-On は認証後にプロトコルマッパーを実行できます。

一時的なセッションが使用されると、クライアントアプリケーションでは、トークンの更新またはイントロスペクションを行う方法や、特定のセッションが有効かどうかを確認する方法がありません。状況によっては、これらのアクションが不要となるため、ユーザーセッションの永続性の追加オーバーヘッドを避けることができます。これにより、パフォーマンスが向上し、メモリーとネットワーク通信 (クラスターおよびデータセンター環境の場合) を保存します。

第14章 ユーザーストレージフェデレーション

多くの企業には、ユーザーおよびパスワードやその他の認証情報に関する情報を保持する既存のユーザーデータベースがあります。多くの場合、既存のストアから純粋な Red Hat Single Sign-On デプロイメントに移行することはできません。Red Hat Single Sign-On では、既存の外部データベースデータベースをフェデレーションできます。デフォルトでは LDAP および Active Directory をサポートしますが、User Storage SPI を使用してカスタムユーザーデータベースの独自の拡張をコード化することもできます。

Red Hat Single Sign-On は、ユーザーがログインしたときに、独自の内部ユーザーストアを検索し、ユーザーを見つけることです。これを見つけることができない場合、レルムに設定したすべての User Storage プロバイダーに対して一致を見つけるまで繰り返されます。外部ストアからのデータは、Red Hat Single Sign-On ランタイムが使用する共通のユーザーモデルにマッピングされます。この一般的なユーザーモデルは、OIDC トークン要求と SAML アサーション属性にマッピングできます。

外部データベースデータベースは、Red Hat Single Sign-On のすべての機能をサポートするのに必要なすべてのデータを持ちます。そのため、ユーザーストレージプロバイダーは Red Hat Single Sign-On ユーザーストアにローカルに格納できるものを選択できます。ユーザーをローカルにインポートし、外部ストアと定期的に同期しているプロバイダーもあります。この方法は、プロバイダーの機能と設定によって異なります。たとえば、外部ユーザーストアは OTP に対応していない可能性があります。プロバイダーによっては、この OTP は Red Hat Single Sign-On により処理および保存できます。

14.1. プロバイダーの追加

ストレージプロバイダーを追加するには、管理コンソールの左側のメニュー項目 User Federation に移動します。

ユーザーフェデレーション

user federation

中央に、Add Provider リストボックスがあります。追加するプロバイダータイプを選択し、そのプロバイダーの設定ページに移動します。

14.2. プロバイダー障害の処理

User Storage Provider が失敗した場合 (LDAP サーバーがダウンしている場合など)、ログインに問題があり、管理コンソールでユーザーを表示できない場合があります。Red Hat Single Sign-On は、ストレージプロバイダーを使用してユーザーを検索する際に障害をキャッチしません。呼び出しを中止します。そのため、ユーザー検索中に失敗した優先度が高いストレージプロバイダーがある場合、ログインまたはユーザークエリーは完全に例外で失敗し、中止します。これは次に設定されているプロバイダーにフェイルオーバーしません。

ローカルの Red Hat Single Sign-On ユーザーデータベースは常に最初に検索され、LDAP またはカスタムのユーザーストレージプロバイダーの前にユーザーを解決します。LDAP およびカスタムバックエンドへの接続で問題が発生した場合に、ローカルの Red Hat Single Sign-On ユーザーデータベースに保存されている管理者アカウントの作成を検討できます。

各 LDAP およびカスタム User Storage Provider には、管理コンソールページに enable スイッチがあります。User Storage Provider を無効にすると、ユーザークエリーの実行時にプロバイダーをスキップし、優先順位が低い別のプロバイダーに保存されるユーザーで表示し、ログインできるようにします。プロバイダーがインポートストラテジーを使用し、無効にした場合、インポートされたユーザーは引き続き検索に利用できますが、読み取り専用モードとしてのみ使用できます。プロバイダーを再度有効にするまで、これらのユーザーを変更することはできません。

理由として、Red Hat Single Sign-On がフェイルオーバーしない理由は、ストレージプロバイダーのルックアップが失敗した場合、ユーザーデータベースの重複ユーザー名や重複メールが頻繁に行われるためです。これにより、ユーザーが別のものからロードされることを想定する際に、ユーザーが外部のストアから読み込まれる可能性があるので、セキュリティー上の問題が発生し、予期せぬ問題が発生する可能性があります。

14.3. LDAP および Active Directory

Red Hat Single Sign-On には、LDAP/AD プロバイダーが組み込まれています。同じ Red Hat Single Sign-On レルムで複数の異なる LDAP サーバーをフェデレーションすることは可能です。LDAP ユーザー属性は、Red Hat Single Sign-On の共通ユーザーモデルにマップできます。デフォルトでは、ユーザー名、電子メール、名、および姓のマッピングが行われますが、追加のマッピングを設定することができます。LDAP プロバイダーは LDAP/AD プロトコルおよび各種ストレージ、編集および同期モードによるパスワード検証もサポートします。

フェデレーションされた LDAP ストアを設定するには、管理コンソールに移動します。左側のメニューオプション User Federation をクリックします。このページを表示するには、Add Provider 選択ボックスがあります。このリストに ldap が表示されるはずです。ldap を選択すると、LDAP 設定ページに移動します。

14.3.1. ストレージモード

デフォルトでは、Red Hat Single Sign-On はユーザーを LDAP からローカルの Red Hat Single Sign-On ユーザーデータベースにインポートします。このユーザーのコピーは、オンデマンドで同期されるか、または定期的なバックグラウンドタスクを介して同期されます。これに対する 1 つの例外は、パスワードの同期です。パスワードはインポートされません。検証は常に LDAP サーバーに委譲されます。このアプローチの利点は、すべての 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 ユーザーデータベースにインポートおよび同期するオーバーヘッドを持たないことです。

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

注記

ユーザーのインポートが無効になっている場合は、Red Hat Single Sign-On データベースにユーザープロファイル属性を保存できません。また、LDAP にマッピングされたユーザープロファイルメタデータ以外のメタデータを保存することはできません。これに対する単一例外は、LDAP にマップされるユーザープロファイルメタデータです。これには、LDAP マッパーの設定に基づいたロールマッピング、グループマッピング、およびその他のメタデータが含まれる場合があります。LDAP 以外のマッピングユーザーデータの一部を変更しようとすると、ユーザーを更新することができません。たとえば、ユーザーの 有効な フラグが一部の LDAP 属性にマップされていない限り、LDAP マッピングしたユーザーを無効にすることはできません(これは通常該当しません)。

14.3.2. 編集モード

User Account Service サービスのユーザー、および管理コンソールの管理者には、ユーザーメタデータを変更する機能があります。セットアップによっては、LDAP の更新権限がある場合とない場合があります。Edit Mode 設定オプションは、LDAP ストアで設定した編集ポリシーを定義します。

READONLY
ユーザー名、メールアドレス、姓名、およびその他のマップ属性は変更できません。Red Hat Single Sign-On は、これらのフィールドの更新を試みるたびにエラーを表示します。また、パスワードの更新はサポートされません。
WRITABLE
ユーザー名、電子メール、名、姓名、その他のマップされた属性とパスワードはすべて更新され、LDAP ストアに自動的に同期されます。
未同期
ユーザー名、メールアドレス、姓、およびパスワードへの変更は、Red Hat Single Sign-On のローカルストレージに保存されます。LDAP に同期する方法を把握しているのはユーザー次第です。これにより、Red Hat Single Sign-On デプロイメントは、読み取り専用の LDAP サーバーでユーザーメタデータの更新をサポートできます。このオプションは、LDAP からローカルの Red Hat Single Sign-On ユーザーデータベースにユーザーをインポートする場合に限り有効です。
注記

LDAP プロバイダーが作成されると、初期の LDAP マッパーのセットが作成されます。マッパーは、VendorEdit Mode、および Import Users スイッチの選択した組み合わせに基づいて「ベストエフォート」に設定されます。たとえば、UNSYNCED 編集モードの場合は、特定のユーザー属性が LDAP ではなくデータベースから読み取ることが望ましい方法で、マッパーは事前設定されています。ただし、後で編集モードを変更すると、タイミングで手動で変更したかどうかを簡単に検出できないため、マッパーの設定は変更されません。つまり、Edit Mode スイッチを更新しないが、LDAP プロバイダーの作成時に常に Edit Mode を決定することが推奨されます。これは、Import Users スイッチにも該当します。

14.3.3. その他の設定オプション

コンソール表示名
このプロバイダーが管理コンソールで参照される場合に使用される名前
優先度
ユーザーを検索する、またはユーザーを追加する際のこのプロバイダーの優先度。
登録の同期
LDAP は新しいユーザーの追加をサポートしますか?管理コンソールで Red Hat Single Sign-On で作成した新規ユーザーまたは LDAP に追加する登録ページが必要な場合は、このスイッチをクリックします。
Kerberos 認証を許可
LDAP からプロビジョニングされたユーザーデータを使用して、レルムで Kerberos/SPNEGO 認証を有効にします。Kerberos セクションでは詳細を確認してください。
その他のオプション
残りの設定オプションは、分かりやすくなるはずです。管理コンソールのツールチップの上にマウスポインターをかざすと、それらに関する詳細が表示されます。

14.3.4. SSL 経由で LDAP に接続

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

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

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

14.3.5. LDAP ユーザーの Red Hat Single Sign-On への同期

ユーザーのインポートオプションを有効にすると、LDAP プロバイダーは、必要な LDAP ユーザーの同期 (インポート) を Red Hat Single Sign-On のローカルデータベースに自動的に処理します。ユーザーがログインすると、LDAP プロバイダーは LDAP ユーザーを Red Hat Single Sign-On データベースにインポートし、LDAP パスワードに対して認証します。これは、ユーザーがインポートされる唯一の時間です。管理コンソールの左側のメニュー項目 Usersに移動し、View all users ボタンをクリックすると、Red Hat Single Sign-On によって最低 1 回認証された LDAP ユーザーのみが表示されます。この操作により LDAP ユーザーデータベース全体のインポートがトリガーされないように、この方法が実装されます。

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

定期的な完全同期 (Periodic Full)
このタイプは、すべての LDAP ユーザーを Red Hat Single Sign-On データベースと同期します。Red Hat Single Sign-On にすでに存在する LDAP ユーザーは、LDAP に直接変更されたものは Red Hat Single Sign-On データベースで更新されます。たとえば、Mary Kelly ユーザーは、LDAP で、Mary Smith に変わりました。
定期的な変更したユーザー同期 (Periodic Changed)
同期が行われると、最後の同期が作成または更新されたユーザーのみが更新されたり、インポートされます。

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

14.3.6. LDAP マッパー

LDAP マッパーは、さまざまな点で LDAP プロバイダーによってトリガーされる listeners で、別のエクステンションが LDAP 統合を参照します。これらは LDAP 経由でログインし、ユーザーが Red Hat Single Sign-On の起動中にインポートする必要がある場合や、ユーザーが管理コンソールからクエリーされる場合にトリガーされます。LDAP フェデレーションプロバイダーを作成すると、Red Hat Single Sign-On はこのプロバイダーの組み込み mappers のセットを自動的に提供します。このセットを変更し、新しいマッパーを作成したり、既存のマッパーを更新/削除したりすることもできます。

ユーザー属性マッパー
これにより、Red Hat Single Sign-On ユーザーのどの属性がマッピングされる LDAP 属性を指定することができます。たとえば、Red Hat Single Sign-On データベースの LDAP 属性 mail を属性 email に設定できます。このマッパー実装には常に 1 対 1 のマッピングが存在します (1 つの LDAP 属性が 1 つの Red Hat Single Sign-On 属性にマッピングされます)。
fullName Mapper
これにより、一部の LDAP 属性 (通常は cn) に保存されているユーザーのフルネームを、Red Hat Single Sign-On データベースの firstName および lastname 属性にマッピングされるように指定できます。cn にユーザーのフルネームを含めることは、一部の LDAP デプロイメントでは一般的なケースです。
ハードコードされた属性マッパー
このマッパーは LDAP と一緒にリンクされた各 Red Hat Single Sign-On ユーザーにハードコードされた属性値を追加します。また、このマッパーは enabled または emailVerified ユーザープロパティーの値を強制することもできます。
ロールマッパー
これにより、LDAP から Red Hat Single Sign-On ロールマッピングへのロールマッピングを設定できます。ロールマッパーは、LDAP ロール (通常は LDAP ツリーの特定ブランチからのグループ) を、指定したクライアントのレルムロールまたはクライアントロールのいずれかに対応するロールにマップするために使用できます。同じ LDAP プロバイダーに対してより多くのロールマッパーを設定するのは問題ありません。たとえば、ou=main,dc=example,dc=org 下のグループからのロールマッピングはレルムロールマッピングにマッピングされ、ou=finance,dc=example,dc=org の下にあるグループからのロールマッピングが、クライアント finance のクライアントロールマッピングにマップされるように指定できます。
ハードコーディングされたロールマッパー
このマッパーは、指定された Red Hat Single Sign-On ロールを LDAP プロバイダーから各 Red Hat Single Sign-On ユーザーに付与します。
Group Mapper
これにより、LDAP ツリーの特定ブランチから、Red Hat Single Sign-On のグループに LDAP グループをマップできます。また、Red Hat Single Sign-On の LDAP からユーザーグループマッピングに、ユーザーグループマッピングも伝播されます。
MSAD ユーザーアカウントマッパー
このマッパーは、Microsoft Active Directory (MSAD) に固有のものです。MSAD ユーザーアカウント状態を Red Hat Single Sign-On アカウントの状態に密接に統合することができます (アカウントが有効な、パスワードの有効期限など)。これは、LDAP 属性 userAccountControl および pwdLastSet を使用します。これはいずれも MSAD に固有のもので、LDAP 標準ではありません。たとえば、ipwdLastSet0 の場合、パスワードを更新するには Red Hat Single Sign-On ユーザーが必要で、ユーザーに UPDATE_PASSWORD 必須アクションが追加されました。userAccountControl514 (無効なアカウント) の場合は、Red Hat Single Sign-On ユーザーも無効になります。
Certificate Mapper
このマッパーは X.509 証明書のマッピングに固有のものです。通常、これは X.509 認証と併用され、ID ソースとして Full certificate in PEM format を使用します。User Attribute Mapper と同じ動作をしますが、Red Hat Single Sign-On は PEM 形式または DER フォーマットの証明書を格納する LDAP 属性についてフィルターできます。通常、このマッパーで LDAP から Always Read Value を有効にすることが推奨されます。

デフォルトでは、ユーザー名、ファイル名、名、姓、電子メールなどの Red Hat Single Sign-On の基本属性属性を対応する LDAP 属性にマップする User 属性マッパーがあります。これらの拡張は自由に行い、追加の属性マッピングを指定することができます。管理コンソールはツールチップを提供します。これは、対応するマッパーの設定に役立ちます。

14.3.7. パスワードのハッシュ化

ユーザーのパスワードが Red Hat Single Sign-On から更新され、LDAP に送信されると、常にプレーンテキストで送信されます。これは、ハッシュと salt が DB に送信される前にパスワードに適用される場合に、パスワードを組み込み Red Hat Single Sign-On データベースに更新することとは異なります。LDAP の場合、Red Hat Single Sign-On は LDAP サーバーに依存してパスワードのハッシュおよび salt を提供します。

Microsoft Active Directory、RHDS または FreeIPA などの LDAP サーバーは、デフォルトでこれを提供します。OpenLDAP や ApacheDS などのその他の場合には、RFC3062 に従って LDAPv3 Password Modify Extended Operation を使用しない限り、デフォルトでパスワードをプレーンテキストで保存できます。LDAPv3 Password Modify Extended Operation は LDAP 設定ページで明示的に有効にする必要があります。詳細は、お使いの LDAP サーバーのドキュメントを参照してください。

警告

ldapsearch および base64 を使用して変更したディレクトリーエントリーを検査することで、ユーザーパスワードが正しくハッシュ化され、プレーンテキストとして保存されていることを確認します

14.4. SSSD および FreeIPA Identity Management の統合

Red Hat Single Sign-On には、SSSD (System Security Services Daemon) プラグインが同梱されています。SSSD は、最新の Fedora または Red Hat Enterprise Linux に含まれており、複数の ID および認証プロバイダーへのアクセスを提供します。フェイルオーバーやオフラインサポートなどの利点があります。設定オプションと詳細情報は、Red Hat Enterprise Linux Identity Management のドキュメント を参照してください。

SSSD は、認証とアクセス制御を提供する FreeIPA アイデンティティー管理(IdM)サーバーとも統合します。Red Hat Single Sign-On では、この統合認証を PAM サービスに対する認証と、SSSD からユーザーデータを取得するのに役立ちます。Linux 環境における Red Hat Identity Management の使用に関する詳細は、Red Hat Enterprise Linux Identity Management のドキュメントを参照してください

keycloak sssd freeipa integration overview

Red Hat Single Sign-On と SSSD 間の通信のほとんどは、読み取り専用の D-Bus インターフェースを介して行われます。このため、ユーザーのプロビジョニングおよび更新の唯一の方法は、FreeIPA/IdM 管理インターフェースを使用することです。デフォルトでは、LDAP フェデレーションプロバイダーと同様に、ユーザー名、メール、名、および姓しかインポートされません。

注記

グループとロールは自動的に登録されますが、同期されないため、Red Hat Single Sign-On の管理者から直接行った変更は SSSD と同期されません。

FreeIPA/IdM サーバーの設定方法に関する情報は、以下を参照してください。

14.4.1. FreeIPA/IdM Server

分かりやすくするために、すでに利用可能な FreeIPA Docker イメージが使用されます。サーバーを設定するには、FreeIPA ドキュメント を参照してください。

Docker を使用して FreeIPA サーバーを実行するには、以下のコマンドが必要です。

docker run --name freeipa-server-container -it \
-h server.freeipa.local -e PASSWORD=YOUR_PASSWORD \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-v /var/lib/ipa-data:/data:Z freeipa/freeipa-server

server.freeipa.local のパラメーター -h は FreeIPA/IdM サーバーのホスト名を表します。YOUR_PASSWORD を選択したパスワードに変更するようにしてください。

コンテナーが起動したら、/etc/hosts を以下に変更します。

x.x.x.x     server.freeipa.local

この変更を加えない場合は、DNS サーバーを設定する必要があります。

SSSD フェデレーションプロバイダーが起動し、Red Hat Single Sign-On で実行するように、IPA ドメインに Linux マシンを登録する必要があります。

ipa-client-install --mkhomedir -p admin -w password

クライアントマシンで、すべてが想定通りに機能されていることを確認するには、以下を実行します。

kinit admin

パスワードの入力が求められます。その後、以下のコマンドを使用して IPA サーバーにユーザーを追加できます。

$ ipa user-add john --first=John --last=Smith --email=john@smith.com --phone=042424242 --street="Testing street" \      --city="Testing city" --state="Testing State" --postalcode=0000000000 --password

ユーザーのパスワードの設定を強制するには、kinit を使用します。ユーザーに john を指定し、以下のコマンドを入力します。

kinit john

通常の IPA 操作を復元するには、以下のコマンドを入力します。

kdestroy -A
kinit admin

14.4.2. SSSD および D-Bus

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

まず sssd-dbus RPM をインストールする必要があります。これにより、SSSD からの情報をシステムバスで送信できるようにします。

$ sudo yum install sssd-dbus

このプロビジョニングスクリプトを実行する必要があります。

$ .../bin/federation-sssd-setup.sh

このスクリプトは、/etc/sssd/sssd.conf に必要な変更を加えます。

[domain/your-hostname.local]
...
ldap_user_extra_attrs = mail:mail, sn:sn, givenname:givenname, telephoneNumber:telephoneNumber
...
[sssd]
services = nss, sudo, pam, ssh, ifp
...
[ifp]
allowed_uids = root, yourOSUsername
user_attributes = +mail, +telephoneNumber, +givenname, +sn

また、keycloak ファイルは /etc/pam.d/ に含まれています。

auth    required   pam_sss.so
account required   pam_sss.so

dbus-send を実行して、すべてが予想どおりに機能することを確認します。

sudo dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:john

ユーザーのグループが表示されるはずです。このコマンドでタイムアウトまたはエラーが返されると、Red Hat Single Sign-On で実行されているフェデレーションプロバイダーも何も取得できないことを意味します。

これは、マシンが FreeIPA IdM サーバーに登録されていないか、SSSD サービスにアクセスするパーミッションがありません。

パーミッションがない場合は、Red Hat Single Sign-On サーバーを実行しているユーザーが、以下のセクションの /etc/sssd/sssd.conf ファイルに含まれていることを確認します。

[ifp]
allowed_uids = root, your_username

14.4.3. SSSD フェデレーションプロバイダーの有効化

Red Hat Single Sign-On は、DBus-Java を使用して D-Bus が低いレベルで通信します。これは Unix ソケットライブラリーに依存します。

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

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

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

$ sudo yum install jna

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

$ sudo sssctl user-checks admin -s keycloak

14.5. フィード SSSD ストアの設定

インストール後に、調整された SSSD ストアを設定する必要があります。

フェデレーションされている SSSD ストアを設定するには、以下の手順を実行します。

  1. 管理コンソール に移動します。
  2. 左側のメニューから User Federation. を選択します。
  3. Add Provider ドロップダウンリストから、sssd を選択します。sssd 設定ページが開きます。
  4. Save をクリックします。

これで、FreeIPA/IdM 認証情報を使用して Red Hat Single Sign-On に対する認証が可能になりました。

14.6. カスタムプロバイダー

Red Hat Single Sign-On には、独自のカスタムプロバイダーを作成するのに使用する User Storage Federation の SPI があります。詳細は『サーバー開発者ガイド』 を参照してください。

第15章 監査およびイベント

Red Hat Single Sign-On は、豊富な監査機能のセットを提供します。すべてのログインアクションはデータベースへ記録および保存でき、管理コンソールでレビューできます。すべての管理者アクションも記録し、レビューすることもできます。プラグインがこれらのイベントをリッスンし、一部のアクションを実行できる Listener SPI もあります。組み込みリスナーには、簡単なログファイルとイベントが発生したときにメールを送信する機能が含まれています。

15.1. ログインイベント

ログインイベントは、ユーザーが正常にログインしたり、一部の本文が不正なパスワードに入るとき、またはユーザーアカウントの更新時に行われます。ユーザーに発生するすべてのイベントは、記録と表示が可能です。デフォルトでは、イベントは管理コンソールに保存または表示されません。エラーイベントのみがコンソールおよびサーバーのログファイルに記録されます。永続化を開始するには、ストレージを有効にする必要があります。左側のメニュー項目 Events に移動し、Config タブを選択します。

イベント設定

login events config

イベントの保存を開始するには、Login Events SettingsSave Events スイッチをオンに切り替える必要があります。

イベントの保存

login events settings

Saved Types フィールドでは、イベントストアに保存するイベントタイプを指定できます。Clear events ボタンを使用すると、データベースのすべてのイベントを削除できます。Expiration フィールドでは、イベントの保存期間を指定できます。ログインイベントのストレージを有効にし、設定を決定したら、このページの下部にある Save ボタンをクリックしないでください。

イベントを表示するには、Login Events タブに移動します。

ログインイベント

login events

ご覧のとおり、多くの情報が保存され、すべてのイベントを保存する場合は、ログインアクションごとに多数のイベントが保存されるイベントがあります。このページの Filter ボタンを使用すると、実際に対象のイベントをフィルターできます。

ログインイベントフィルター

login events filter

このスクリーンショットでは、Login イベントのみを絞り込みています。Update ボタンをクリックしてフィルターを実行します。

15.1.1. イベントタイプ

ログインイベント:

  • Login: ユーザーがログインしている。
  • Register: ユーザーが登録済みです。
  • Logout: ユーザーがログアウトしました。
  • トークンへのコード: アプリケーション/クライアントではトークンのコードが交換されます。
  • 更新トークン: アプリケーション/クライアントでトークンが更新されました。

アカウントイベント:

  • ソーシャルリンク: アカウントがソーシャルプロバイダーにリンクされている。
  • Remove Social Link: ソーシャルプロバイダーがアカウントから削除されました。
  • Update Email: アカウントのメールアドレスが変更されました。
  • Update Profile: アカウントのプロファイルが変更されました。
  • パスワードリセットの送信: パスワードリセットメールが送信されました。
  • Update Password: アカウントのパスワードが変更されました。
  • Update TOTP: アカウントの TOTP 設定が変更になりました。
  • Remove TOTP: TOTP はアカウントから削除されました。
  • Send Verify Email: メールの検証メールが送信されました。
  • Verify Email: アカウントのメールアドレスが検証されました。

すべてのイベントには、対応するエラーイベントがあります。

15.1.2. イベントリスナー

イベントリスナーはイベントをリッスンし、そのイベントに基づいてアクションを実行します。Red Hat Single Sign-On には、Logging Event Listener と Email Event Listener の 2 つの組み込みリスナーがあります。

Logging Event リスナーは、エラーイベントが発生し、デフォルトで有効にされるたびにログファイルに書き込みます。ログメッセージの例を以下に示します。

11:36:09,965 WARN  [org.keycloak.events] (default task-51) type=LOGIN_ERROR, realmId=master,
                    clientId=myapp,
                    userId=19aeb848-96fc-44f6-b0a3-59a17570d374, ipAddress=127.0.0.1,
                    error=invalid_user_credentials, auth_method=openid-connect, auth_type=code,
                    redirect_uri=http://localhost:8180/myapp,
                    code_id=b669da14-cdbb-41d0-b055-0810a0334607, username=admin

このロギングは、fail2Ban などのツールを使用して、ユーザーパスワードの推測を試みる場所のハッカーボットがあるかどうかを検出する場合に非常に便利です。LOGIN_ERROR のログファイルを解析し、IP アドレスをプルできます。次に、この情報を Fail2Ban にフィードし、攻撃を防ぐのに役立ちます。

Logging Event リスナーは、イベントを org.keycloak.events ロガーカテゴリーに記録します。デフォルトでは、デバッグログイベントはサーバーログに含まれません。

サーバーログにデバッグログイベントを含めるには、standalone.xml ファイルを編集し、Logging Event リスナーによって使用されるログレベルを変更します。または、org.keycloak.events のログレベルを設定することもできます。

たとえば、ログレベルを変更するには、以下を追加します。

<subsystem xmlns="urn:jboss:domain:logging:...">
    ...
    <logger category="org.keycloak.events">
        <level name="DEBUG"/>
    </logger>
</subsystem>

Logging Event リスナーによって使用されるログレベルを変更するには、以下を追加します。

<subsystem xmlns="urn:jboss:domain:keycloak-server:...">
    ...
    <spi name="eventsListener">
      <provider name="jboss-logging" enabled="true">
        <properties>
          <property name="success-level" value="info"/>
          <property name="error-level" value="error"/>
        </properties>
      </provider>
    </spi>
</subsystem>

ログレベルの有効な値は debuginfowarnerror、および fatal です。

メールイベントリスナーは、イベント発生時にユーザーのアカウントにメールを送信します。

現在、Email Event リスナーは以下のイベントをサポートします。

  • ログインエラー
  • パスワードの更新
  • TOTP の更新
  • TOTP の削除

Email Listener を有効にするには Config タブに移動し、Event Listeners フィールドをクリックします。これにより、メールを選択できるドロップダウンリストが表示されます。

ディストリビューションに同梱される standalone.xmlstandalone-ha.xml、または domain.xml を編集して、1 つ以上のイベントを除外できます。以下は例になります。

<spi name="eventsListener">
  <provider name="email" enabled="true">
    <properties>
      <property name="exclude-events" value="[&quot;UPDATE_TOTP&quot;,&quot;REMOVE_TOTP&quot;]"/>
    </properties>
  </provider>
</spi>

standalone.xmlstandalone-ha.xml、または domain.xml を編集して、データベースに保存されているイベントの詳細の最大長を設定することもできます。この設定は、一部のフィールド (例: redirect_uri) が非常に長い場合に役に立ちます。以下は、最大長を定義する例です。

<spi name="eventsStore">
    <provider name="jpa" enabled="true">
        <properties>
            <property name="max-detail-length" value="1000"/>
        </properties>
    </provider>
</spi>

standalone.xmlstandalone-ha.xml、または domain.xml ファイルが存在する場所の詳細は、『サーバーインストールおよび設定ガイド』を参照してください。

15.2. 管理イベント

監査目的で、管理コンソール内で管理者が実行するアクションを記録できます。管理コンソールでは、Red Hat Single Sign-On REST インターフェースを呼び出して管理機能を実行します。Red Hat Single Sign-On の監査は、これらの REST 呼び出しです。結果となるイベントは、管理コンソールで表示できます。

管理アクションの監査を有効にするには、左側のメニュー項目 Events に移動し、Config タブを選択します。

イベント設定

login events config

Admin Events Settings セクションで、Save Events スイッチをオンにします。

管理イベント設定

admin events settings

Include Representation スイッチには、管理 REST API 経由で送信される JSON ドキュメントが含まれます。これにより、管理者が実行した内容を正確に表示できますが、データベースに保存された多くの情報が発生する可能性があります。Clear admin events ボタンを使用すると、保存されている現在の情報を消去できます。

管理イベントを表示するには、Admin Events タブに移動します。

管理イベント

admin events

Details 列に Representation ボックスがある場合は、それをクリックしてその操作で送信された JSON を表示します。

Admin Representation

admin events representation

Filter ボタンをクリックして、対象のイベントにフィルターをかけることもできます。

管理イベントフィルター

admin events filter

第16章 エクスポートおよびインポート

Red Hat Single Sign-On は、データベース全体をエクスポートおよびインポートする機能があります。これは、Red Hat Single Sign-On データベース全体をある環境から別の環境に移行する場合や、別のデータベース (MySQL から Oracle など) に移行する場合に役立ちます。エクスポートとインポートはサーバーの起動時にトリガーされ、そのパラメーターは Java システムプロパティーを使用して渡されます。インポートとエクスポートはサーバーの起動時に発生するため、サーバーやデータベースではその他のアクションが行われないため注意してください。

データベースを以下のようにエクスポート/インポートすることができます。

  • ローカルファイルシステムのディレクトリー
  • ファイルシステムの単一 JSON ファイル

ディレクトリーストラテジーを使用してインポートする場合は、ファイルは以下で指定された命名規則に従う必要があることに注意してください。以前にエクスポートされたファイルをインポートする場合、ファイルはすでにこの規則に従います。

  • <REALM_NAME>-realm.json (例: 「acme-roadrunner-affairs」という名前のレルムの場合は「acme-roadrunner-affairs-realm.json」)
  • <REALM_NAME>-users-<INDEX>.json (例: 「acme-roadrunner-affairs」という名前のレルムにおける最初のユーザーファイルの場合は「acme-roadrunner-affairs-users-0.json」)

ディレクトリーへエクスポートする場合には、各 JSON ファイルに保存されているユーザー数を指定することもできます。

注記

データベースにユーザー数が多い場合は (500 以上)、単一のファイルではなくディレクトリーにエクスポートすることを強く推奨します。1 つのファイルにエクスポートすると、非常に大きなファイルが発生する可能性があります。また、ディレクトリープロバイダーは各「ページ」(ユーザーと共にファイル) に別のトランザクションを使用するため、パフォーマンスが向上します。ファイルごとのユーザーのデフォルト数 (およびトランザクション) は 50 で、最良のパフォーマンスが得られますが、上書きが可能です (下記参照)。単一ファイルへのエクスポートでは、エクスポート全体とインポートごとに 1 つのトランザクションが使用され、ユーザーが大量のパフォーマンスが低下します。

暗号化されていないディレクトリーにエクスポートするには、以下を使用できます。

bin/standalone.sh -Dkeycloak.migration.action=export
-Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=<DIR TO EXPORT TO>

単一の JSON ファイルにエクスポートするには、以下を使用できます。

bin/standalone.sh -Dkeycloak.migration.action=export
-Dkeycloak.migration.provider=singleFile -Dkeycloak.migration.file=<FILE TO EXPORT TO>

同様に、インポートには export の代わりに -Dkeycloak.migration.action=import を使用します。以下は、インポート例です。

bin/standalone.sh -Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=singleFile -Dkeycloak.migration.file=<FILE TO IMPORT>
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING

その他の利用可能なオプションは以下のとおりです。

-Dkeycloak.migration.realmName
このプロパティーは、all ではなく、指定したレルムだけをエクスポートする場合に使用されます。指定されていない場合は、すべてのレルムがエクスポートされます。
-Dkeycloak.migration.usersExportStrategy

このプロパティーは、ユーザーのエクスポートされる場所を指定するために使用されます。以下の値が使用できます。

  • DIFFERENT_FILES: ファイルごとのユーザーの最大数に応じて、ユーザーは異なるファイルにエクスポートされます。これはデフォルト値です。
  • SKIP: ユーザーのエクスポートは完全にスキップされます。
  • REALM_FILE: すべてのユーザーはレルム設定で同じファイルにエクスポートされます。(結果は、レルムデータとユーザーの両方を持つ「foo-realm.json」などのファイルになります。)
  • SAME_FILE: すべてのユーザーは、同じファイルにエクスポートされますが、レルムファイルとは異なります。(結果は、レルムデータを含む「foo-realm.json」および「foo-users.json」などのファイルとなります。)
-Dkeycloak.migration.usersPerFile
このプロパティーは、ファイルごとにユーザー数 (および DB トランザクションごと) を指定するために使用されます。デフォルトで 50 になります。これは、usersExportStrategy が DIFFERENT_FILES である場合にのみ使用されます。
-Dkeycloak.migration.strategy

このプロパティーは、インポート中に使用されます。同じ名前のレルムがデータをインポートするデータベースに存在する場合に、続行する方法を指定できます。以下の値が使用できます。

  • IGNORE_EXISTING: この名前のレルムがすでに存在する場合には、インポートを無視します。
  • OVERWRITE_EXISTING: 既存のレルムを削除して、JSON ファイルから新しいデータでインポートします。1 つの環境を別の環境に完全移行して、新しい環境に同じデータが含まれていることを確認する場合は、これを指定できます。

これまでにエクスポートされなかったレルムファイルをインポートする場合、keycloak.import オプションを使用できます。複数のレルムファイルをインポートする必要がある場合は、ファイル名のコンマ区切りリストを指定できます。これは、マスターレルムが初期化された後にのみ行われるため、前のケースよりも適しています。例:

  • -Dkeycloak.import=/tmp/realm1.json
  • -Dkeycloak.import=/tmp/realm1.json,/tmp/realm2.json

16.1. 管理コンソールのエクスポート/インポート

ほとんどのリソースのインポートは、管理コンソールから実行したり、ほとんどのリソースをエクスポートすることもできます。ユーザーのエクスポートはサポートされていません。

注記

シークレットまたはプライベート情報を含む属性はエクスポートファイルでマスクされます。そのため、管理コンソールから取得したファイルのエクスポートファイルは、バックアップやサーバー間のデータ転送には適していません。ブートタイムエクスポートのみが適切です。

また、「startup」エクスポート中に作成されたファイルを使用して、管理 UI からインポートすることもできます。これにより、あるレルムから別のレルムにエクスポートして、別のレルムにインポートできます。または、あるサーバーからエクスポートして、別のサーバーにインポートできます。

注記

管理コンソールのエクスポート/インポートでは、ファイルごとに 1 つのレルムのみが許可されます。

警告

管理コンソールのインポートにより、選択した場合はリソースを「上書き」することができます。特に本番環境ではこの機能を使用してください。通常、Admin Console Export 操作から .json ファイルはシークレットの無効な値が含まれるため、データのインポートには適切ではありません。

警告

管理コンソールのエクスポートを使用すると、クライアント、グループ、およびロールをエクスポートできます。レルムにこれらのアセットが多数ある場合は、操作が完了するのに時間がかかる場合があります。この間、サーバーがユーザーリクエストに応答しなくなることがあります。特に本番環境ではこの機能を使用してください。

第17章 Vault を使用したシークレットの取得

管理サポートの複数のフィールドは、外部 vault からシークレットの値を取得します。

直接入力せずに vault からシークレットを取得するには、特別に作成された文字列を適切なフィールドに入力します。${vault.key}key は vault が認識されているシークレット名で置き換えます。

レルム間でシークレットのリークを防ぐために、実装は vault 式から取得した key とレルム名を組み合わせる場合があります。つまり、key は vault のエントリーに直接マップせず、レルム名と組み合わせるために使用されるアルゴリズムに従って最終的なエントリー名を作成するために使用されます。

現時点で、シークレットは以下のフィールドで vault から取得できます。

SMTP パスワード
レルム SMTP 設定
LDAP バインド認証情報
LDAP ベースのユーザーフェデレーションの LDAP 設定
OIDC アイデンティティープロバイダーシークレット
アイデンティティープロバイダーの OpenID Connect Config 内のクライアントシークレット

vault を使用するには、Red Hat Single Sign-On 内に vault プロバイダーを登録する必要があります。以下で説明されているビルトインプロバイダーを使用するか、または独自のプロバイダーを実装することができます。詳細は、『サーバー開発者ガイド』を参照してください。

注記

Red Hat Single Sign-On インスタンスごとに最大 1 つの vault プロバイダーが指定され、クラスター内の各インスタンスの vault プロバイダーを一貫して設定する必要があります。

17.1. Kubernetes / OpenShift Files Plaintext Vault Provider

Red Hat Single Sign-On は、Kubernetes シークレット の vault 実装をサポートします。これらのシークレットはデータボリュームとしてマウントでき、フラットなファイル構造を持つディレクトリーとして表示され、各シークレットはシークレット名の付いたファイルで表され、そのファイルの内容はシークレットの値になります。

このディレクトリー内のファイルは、レルム名とアンダースコアがついたシークレット名として指定する必要があります。シークレット名またはレルム名内のすべてのアンダースコアは、ファイル名で 2 倍にする必要があります。たとえば、sso_realm というレルム内のフィールドの場合、secret-name という名前のシークレットへの参照は ${vault.secret-name} と記述され、ファイル名が sso__realm_secret-name になります (レルム名でアンダースコアが 2 倍)。

このタイプのシークレットストアを使用するには、standalone.xml で files-plaintext vault プロバイダーを宣言し、マウントされたボリュームが含まれるディレクトリーにパラメーターを設定する必要があります。以下の例は、Red Hat Single Sign-On ベースディレクトリーとの関連で、vault ファイルが standalone/configuration/vault に設定されたディレクトリーを含む files-plaintext プロバイダーを示しています。

<spi name="vault">
    <default-provider>files-plaintext</default-provider>
    <provider name="files-plaintext" enabled="true">
        <properties>
            <property name="dir" value="${jboss.home.dir}/standalone/configuration/vault/" />
        </properties>
    </provider>
</spi>

以下は、CLI コマンドを使用して同等の設定です。

/subsystem=keycloak-server/spi=vault/:add
/subsystem=keycloak-server/spi=vault/provider=files-plaintext/:add(enabled=true,properties={dir => "${jboss.home.dir}/standalone/configuration/vault"})

17.2. Elytron クレデンシャルストア Vault プロバイダー

Red Hat Single Sign-On は、Elytron クレデンシャルストアに保存されたシークレットの読み取りもサポートします。elytron-cs-keystore vault プロバイダーは、クレデンシャルストアのキーストアベースの実装からシークレットを取得できます。これは Elytron によって提供されるデフォルトの実装でもあります。

この認証情報ストアはキーストアによってサポートされます (JCEKS はデフォルトの形式ですが、PKCS12 などの他の形式を使用)。ユーザーは WildFly/JBoss EAP の elytron サブシステムを使用するか、elytron-tool.sh スクリプトを使用してストアコンテンツを作成および管理できます。

このプロバイダーを使用するには、keycloak-server サブシステムで elytron-cs-keystore を宣言し、Elytron によって作成されたキーストアの場所とマスターシークレットを設定する必要があります。プロバイダーの最小限の設定例:

<spi name="vault">
    <default-provider>elytron-cs-keystore</default-provider>
    <provider name="elytron-cs-keystore" enabled="true">
        <properties>
            <property name="location" value="${jboss.home.dir}/standalone/configuration/vault/credential-store.jceks" />
            <property name="secret" value="secretpw1!"/>
        </properties>
    </provider>
</spi>

基となるキーストアの形式が JCEKS 以外の場合は、keyStoreType を使用してこの形式に通知する必要があります。

<spi name="vault">
    <default-provider>elytron-cs-keystore</default-provider>
    <provider name="elytron-cs-keystore" enabled="true">
        <properties>
            <property name="location" value="${jboss.home.dir}/standalone/configuration/vault/credential-store.p12" />
            <property name="secret" value="secretpw1!"/>
            <property name="keyStoreType" value="PKCS12"/>
        </properties>
    </provider>
</spi>

シークレットの場合、elytron-cs-keystore プロバイダーはクリアテキスト値 (上記のように) と elytron-tool.sh スクリプトを使用してマスクされた値の両方をサポートします。

<spi name="vault">
   ...
            <property name="secret" value="MASK-3u2HNQaMogJJ8VP7J6gRIl;12345678;321"/>
   ...
</spi>

elytron クレデンシャルストアの作成/管理方法や、キーストアシークレットをマスクする方法に関する詳細は、Elytron のドキュメントを参照してください。

注記

elytron-cs-keystore vault プロバイダーが WildFly 拡張として実装されており、Red Hat Single Sign-On サーバーが WildFly/JBoss EAP で実行されている場合にのみ利用可能です。

17.3. キーリゾルバー

すべてのビルトインプロバイダーは、1 つ以上のキーリゾルバーの設定をサポートします。キーリゾルバーは、基本的にはレルム名とキーを組み合わせて (${vault.key} 式から取得)、vault からシークレットの取得に使用される最終エントリー名を組み合わせるためのアルゴリズムまたはストラテジーを実装します。keyResolvers プロパティーは、プロバイダーによって使用されるリゾルバーを設定するために使用されます。この値は、リゾルバー名のコンマ区切りリストです。files-plaintext プロバイダーの設定例を以下に示します。

<spi name="vault">
    <default-provider>files-plaintext</default-provider>
    <provider name="files-plaintext" enabled="true">
        <properties>
            <property name="dir" value="${jboss.home.dir}/standalone/configuration/vault/" />
            <property name="keyResolvers" value="REALM_UNDERSCORE_KEY, KEY_ONLY"/>
        </properties>
    </provider>
</spi>

リゾルバーは、設定で宣言されるのと同じ順序で実行されます。それぞれのリゾルバーについて、レルムと vault キーを組み合わせるリゾルバーによって生成された最終エントリー名は vault のシークレットの検索に使用されます。シークレットが見つかると、すぐに返されます。そうでない場合には、次のリゾルバーが使用され、空でないシークレットが見つかるか、またはすべてのリゾルバーが試行されるまで継続され、空のシークレットが返されます。上記の例では、最初に REALM_UNDERSCORE_KEY リゾルバーが使用されます。生成する名前の vault にエントリーが存在する場合は、そのエントリーが返されます。そうでない場合は、KEY_ONLY リゾルバーが使用されます。生成する名前の vault にエントリーが存在する場合は、そのエントリーが返されます。これがないと、使用されるリゾルバーがなくなったため、空のシークレットが返されます。

現在利用可能なリゾルバーの一覧は以下のようになります。

  • KEY_ONLY: レルム名は無視され、vault 式からのキーがそのまま使用されます。
  • REALM_UNDERSCORE_KEY: レルムと鍵はアンダースコア _ を使用して結合されます。レルムまたはキーのいずれかでアンダースコアが存在する点は、別のアンダースコアでエスケープされます。したがって、レルムが master_realm と呼ばれ、キーが smtp_key の場合は、組み合わせたキーは master__realm_smtp__key になります。
  • REALM_FILESEPARATOR_KEY: レルムと鍵は、プラットフォームファイルの区切り文字を使用して組み合わせます。これは、ディレクトリー構造を使用してレルムでキーを分類する場合に便利です。

ビルトインプロバイダーにリゾルバーが設定されていない場合、REALM_UNDERSCORE_KEY はデフォルトで選択されます。

17.4. 設定例

以下は、vault およびクレデンシャルストアの設定例になります。この手順には、以下の 2 つの部分が含まれます。

  • クレデンシャルストアおよび vault を作成すると、クレデンシャルストアと vault パスワードはプレーンテキストになります。
  • クレデンシャルストアと vault を更新して、パスワードは elytron-tool.sh によって提供されるマスクを使用します。

この例では、使用されるテストターゲットは BIND DN credential: secret12 を持つ LDAP インスタンスです。ターゲットは、レルム ldaptest のユーザーフェデレーションを使用してマッピングされます。

17.4.1. マスクなしでクレデンシャルストアおよび vault を設定

クレデンシャルストアおよび vault のパスワードがプレーンテキストである vault を作成します。

前提条件

  • 実行中の LDAP インスタンスには BIND DN 認証情報(secret12)があります
  • エイリアスは、デフォルトのキーリゾルバーの使用時に <realm-name>_< key-value> 形式を使用します。この場合、インスタンスはレルム ldaptest で、ldaptest _ldap_secret は、そのレルムの ldap_secret の値に対応するエイリアスです。
注記

リゾルバーは、レルムおよびキー名のダブルアンダースコア文字に置き換えられます。たとえば、ldap test_ldap_secret キーの場合、最終キーは ldaptest_ldap__secret になります

手順

  1. Elytron クレデンシャルストアを作成します。

    [standalone@localhost:9990 /] /subsystem=elytron/credential-store=test-store:add(create=true, location=/home/test/test-store.p12, credential-reference={clear-text=testpwd1!},implementation-properties={keyStoreType=PKCS12})
  2. クレデンシャルストアにエイリアスを追加します。

    /subsystem=elytron/credential-store=test-store:add-alias(alias=ldaptest_ldap__secret,secret-value=secret12)

    リゾルバーによって鍵 ldaptest_ldap__secret がダブルアンダースコアが使用されるかに注目してください。

  3. Elytron によって生成されたキーストアの内容を検証するため、認証情報ストアからエイリアスを一覧表示します。

    keytool -list -keystore /home/test/test-store.p12 -storetype PKCS12 -storepass testpwd1!
    Keystore type: PKCS12
    Keystore provider: SUN
    
    Your keystore contains 1 entries
    
    ldaptest_ldap__secret/passwordcredential/clear/, Oct 12, 2020, SecretKeyEntry,
  4. Red Hat Single Sign-On で vault SPI を設定します。

    /subsystem=keycloak-server/spi=vault:add(default-provider=elytron-cs-keystore)
    
    /subsystem=keycloak-server/spi=vault/provider=elytron-cs-keystore:add(enabled=true, properties={location=>/home/test/test-store.p12, secret=>testpwd1!, keyStoreType=>PKCS12})

    この時点で、vault およびクレデンシャルストアのパスワードはマスクされません。

            <spi name="vault">
                    <default-provider>elytron-cs-keystore</default-provider>
                    <provider name="elytron-cs-keystore" enabled="true">
                        <properties>
                            <property name="location" value="/home/test/test-store.p12"/>
                            <property name="secret" value="testpwd1!"/>
                            <property name="keyStoreType" value="PKCS12"/>
                        </properties>
                    </provider>
                </spi>
    
             <credential-stores>
                    <credential-store name="test-store" location="/home/test/test-store.p12" create="true">
                        <implementation-properties>
                            <property name="keyStoreType" value="PKCS12"/>
                        </implementation-properties>
                        <credential-reference clear-text="testpwd1!"/>
                    </credential-store>
             </credential-stores>
  5. LDAP プロバイダーにおいて、bin DN の認証情報は ${vault.ldap_secret} に置き換えます。
  6. LDAP 接続をテストします。

    LDAP Vault

    LDAP Vault

17.4.2. クレデンシャルストアおよび vault でのパスワードのマスク

クレデンシャルストアおよび vault を更新して、elytron-tool.sh によって提供されるマスクを使用するパスワードを取得できるようになりました。

  1. salt および iteration パラメーターの値を使用してマスクされたパスワードを作成します。

    $ EAP_HOME/bin/elytron-tool.sh mask --salt SALT --iteration ITERATION_COUNT --secret PASSWORD

    たとえば、以下のようになります。

    elytron-tool.sh mask --salt 12345678 --iteration 123 --secret testpwd1!
    MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123
  2. マスクされたパスワードを使用するように Elytron クレデンシャルストア設定を更新します。

    /subsystem=elytron/credential-store=cs-store:write-attribute(name=credential-reference.clear-text,value="MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123")
  3. Red Hat Single Sign-On vault 設定を更新して、マスクされたパスワードを使用します。

    /subsystem=keycloak-server/spi=vault/provider=elytron-cs-keystore:remove()
    /subsystem=keycloak-server/spi=vault/provider=elytron-cs-keystore:add(enabled=true, properties={location=>/home/test/test-store.p12, secret=>”MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123”, keyStoreType=>PKCS12})

    vault および認証情報ストアがマスクされました。

            <spi name="vault">
                    <default-provider>elytron-cs-keystore</default-provider>
                    <provider name="elytron-cs-keystore" enabled="true">
                        <properties>
                            <property name="location" value="/home/test/test-store.p12"/>
                            <property name="secret" value="MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123"/>
                            <property name="keyStoreType" value="PKCS12"/>
                        </properties>
                    </provider>
                </spi>
             ....
             .....
             <credential-stores>
                    <credential-store name="test-store" location="/home/test/test-store.p12" create="true">
                        <implementation-properties>
                            <property name="keyStoreType" value="PKCS12"/>
                        </implementation-properties>
                        <credential-reference clear-text="MASK-3BUbFEyWu0lRAu8.fCqyUk;12345678;123"/>
                    </credential-store>
             </credential-stores>
  4. これで、${vault.ldap_secret} を使用して LDAP への接続をテストすることができます。

第18章 ユーザーアカウントサービス

Red Hat Single Sign-On には、すべてのユーザーがアクセス可能なユーザーアカウントサービスが組み込まれています。このサービスを使用すると、ユーザーはアカウントの管理、認証情報の変更、プロファイルの更新、ログインセッションの表示が可能です。このサービスの URL は <server-root>/auth/realms/{realm-name}/account です。

アカウントサービス

account service profile

最初のページは、左側のメニュー項目 Account であるユーザーのプロファイルです。これは、これらについての基本的なデータを指定する場所です。この画面を拡張して、ユーザーが追加の属性を管理できるようにします。詳細は『サーバー開発者ガイド』を参照してください。

左側のメニュー項目 Password では、ユーザーはパスワードを変更できます。

パスワードの更新

account service password

Authenticator メニューアイテムを使用すると、必要に応じて OTP をセットアップできます。これは、OTP がレルムに対して有効な認証メカニズムである場合にのみ表示されます。ユーザーには、FreeOTP または Google Authenticator をモバイルデバイスにインストールして OTP ジェネレーターとしてインストールする指示があります。画面の スナップショット に表示される QR コードは、適切なセットアップと簡単な設定を行うと、FreeOTP または Google Authenticator のモバイルアプリケーションにスキャンできます。

OTP Authenticator

account service authenticator

Federated Identity メニューアイテムは、ユーザーが自身のアカウントを ID ブローカーとリンクできます (これは通常、ソーシャルプロバイダーアカウントとリンクするのに使用されます)。これで、レルムに設定した外部アイデンティティープロバイダーの一覧が表示されます。

フェデレーションされたアイデンティティー

account service federated identity

Sessions メニューアイテムは、ログインしているデバイスや、どこからでも表示および管理できるようにします。この画面からセッションのログアウトも実行できます。

セッション

account service sessions

Applications メニュー項目には、アクセスできるアプリケーションが表示されます。

アプリケーション

account service apps

18.1. Themeable

Red Hat Single Sign-On のすべての UI と同様に、User Account サービスは完全にテーマで相互運用可能となっています。詳細は『サーバー開発者ガイド』を参照してください。

第19章 脅威モデルの軽減策

本章では、認証サーバーの予想されるセキュリティー脆弱性と Red Hat Single Sign-On による脆弱性を軽減する方法を説明します。潜在的な脆弱性の詳細の一覧と、これらを軽減するセキュリティー実装は、IETF が配置される OAuth 2.0 Threat Model ドキュメントにあります。ここで、これらの脆弱性の多くについて話し合います。

19.1. Host

Red Hat Single Sign-On では、パブリックのホスト名を使用します。たとえば、トークン発行者フィールドおよび URL で、パスワードリセットメールで送信されます。

デフォルトでは、ホスト名は要求ヘッダーをベースにしており、このホスト名が有効であることを確認するためのチェックはありません。

無効なホストヘッダーを阻止する Red Hat Single Sign-On の前にロードバランサーまたはプロキシーを使用しない場合、受け入れすべきホスト名を明示的に設定する必要があります。

Hostname SPI は、要求のホスト名の設定方法を提供します。初期状態のプロバイダーでは、フロントエンドリクエストの固定 URL を設定し、バックエンド要求をリクエスト URI を基にすることを許可します。組み込みプロバイダーが必要な機能を提供しない場合に、独自のプロバイダーを開発することもできます。

19.2. 管理エンドポイントおよびコンソール

Red Hat Single Sign-On 管理 REST API と Web コンソールはデフォルトで、管理者以外のユーザーと同じポートで公開されます。管理コンソールへのアクセスが必要ない場合は、インターネットで管理エンドポイントを公開しないことが推奨されます。

これは、Red Hat Single Sign-On で直接、または Apache または nginx などのプロキシーを使用して実現できます。

プロキシーオプションについては、プロキシーのドキュメントを参照してください。/auth/admin への要求へのアクセスを制御する必要があります。

Red Hat Single Sign-On で直接これを行うには、いくつかのオプションがあります。本書では、IP の制限と別個のポートの 2 つのオプションについて説明します。

管理コンソールが Keycloak のフロントエンド URL でアクセスできなくなったら、デフォルトのホスト名プロバイダーで固定管理 URL を設定する必要があります。

19.2.1. IP の制限

/auth/admin へのアクセスを特定の IP アドレスだけに制限することができます。

以下の例では、/auth/admin へのアクセスを、10.0.0.1 から 10.0.0.255 の範囲の IP アドレスに制限しています。

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <host name="default-host" alias="localhost">
            ...
            <filter-ref name="ipAccess"/>
        </host>
    </server>
    <filters>
        <expression-filter name="ipAccess" expression="path-prefix('/auth/admin') -> ip-access-control(acl={'10.0.0.0/24 allow'})"/>
    </filters>
    ...
</subsystem>

CLI コマンドを使用した同等の設定:

/subsystem=undertow/configuration=filter/expression-filter=ipAccess:add(,expression="path-prefix[/auth/admin] -> ip-access-control(acl={'10.0.0.0/24 allow'})")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=ipAccess:add()
注記

プロキシーを使用している場合の IP 制限には、Red Hat Single Sign-On がプロキシー IP アドレスではなくクライアントの IP アドレスを受信しないように適切に設定することが重要になります。

19.2.2. ポート制限

/auth/admin をインターネット上で公開されていない別のポートに公開することができます。

以下の例では、ポート 8444/auth/admin を公開しますが、デフォルトポート 8443 でアクセスが許可されません。

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <https-listener name="https-admin" socket-binding="https-admin" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            ...
            <filter-ref name="portAccess"/>
        </host>
    </server>
    <filters>
        <expression-filter name="portAccess" expression="path-prefix('/auth/admin') and not equals(%p, 8444) -> response-code(403)"/>
    </filters>
    ...
</subsystem>

...

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="https-admin" port="${jboss.https.port:8444}"/>
    ...
</socket-binding-group>

CLI コマンドを使用した同等の設定:

/socket-binding-group=standard-sockets/socket-binding=https-admin/:add(port=8444)

/subsystem=undertow/server=default-server/https-listener=https-admin:add(socket-binding=https-admin, security-realm=ApplicationRealm, enable-http2=true)

/subsystem=undertow/configuration=filter/expression-filter=portAccess:add(,expression="path-prefix('/auth/admin') and not equals(%p, 8444) -> response-code(403)")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=portAccess:add()

19.3. パスワード推測: ブルートフォース攻撃

ブルートフォース攻撃は、攻撃者がユーザーのパスワードの推測を試みる際に行われます。Red Hat Single Sign-On では、ブルートフォート検出機能が限定されています。オンになっていると、ログイン失敗のしきい値に達すると、ユーザーアカウントが一時的に無効になります。この機能を有効にするには、Realm Settings の左側のメニュー項目に移動し、Security Defenses タブをクリックしてから Brute Force Detection サブタブに移動します。

注記

Brute Force Detection (ブルートフォース検出) は、デフォルトでは無効になっています。この機能を有効にすると、このタイプの攻撃から保護することを強く推奨します。

Brute Force Detection

brute force

ブルートを強制的に検出するには、2 つの異なる設定、永続的なロックアウト、および一時ロックアウトがあります。永続的なロックアウトは、攻撃を検出した後にユーザーのアカウントを無効にします。管理者が有効にするまでアカウントは無効になります。一時的なロックアウトは、攻撃の検出後に期間にユーザーのアカウントを無効にします。アカウントが無効の期間は、攻撃が続行されます。

一般的なパラメーター

最大ログイン失敗
許可されるログイン失敗の最大数。デフォルト値は 30 です。
クイックログインチェックミリ秒
ログインの試行間の最小時間。デフォルトは 1000 です。
最小クイックスタートの待機
ログインの試行が Quick Login Check Milli Seconds よりも速い場合に、ユーザーが一時的に無効になる最小時間。デフォルトは 1 分です。

一時的なロックアウトパラメーター

待機インクリメント
最大ログイン失敗数 に達した後に、ユーザーが無効になるまでの期間が一時的に無効化される時間。デフォルトは 1 分です。
最大待機
ユーザーを一時的に無効にする最大時間。デフォルトは 15 分です。
失敗リセット時間
失敗数がリセットされる時間。最後に失敗したログインからタイマーが実行されます。デフォルトは 12 時間です。

永続的なロックアウトアルゴリズム

  1. 正常なログイン時

    1. count のリセット
  2. ログインの失敗

    1. count のインクリメント
    2. countMax Login Failures を超える数の場合

      1. ユーザーを完全に無効にする
    3. この失敗と最後の失敗の間にかかる時間は、Quick Login Check Milli Seconds より小さい場合

      1. 最小クイックログイン待機のユーザーを一時的に無効にする

ユーザーを無効にすると、管理者がユーザーを有効にするまでログインできません。アカウントの count リセット数を有効化してください。

一時的なロックアウトアルゴリズム

  1. 正常なログイン時

    1. count のリセット
  2. ログインの失敗

    1. この失敗と最後の失敗間の時間が失敗リセットの時間よりも大きい場合

      1. count のリセット
    2. count のインクリメント
    3. Wait Increment * (count / Max Login Failures) を使用して wait を計算します。除算は整数除算であるため、常に整数に丸められます。
    4. wait 時間がゼロで、この失敗から最後の失敗までの時間が Quick Login Check Milli Seconds よりも小さい場合は、代わりに waitMinimum Quick Login Wait に設定してください。

      1. wait 秒および Max Wait 秒の短い方のユーザーを一時的に無効にします。

ユーザーを一時的に無効にした場合にログインに失敗しても、count は増えません。

Red Hat Single Sign-On のブルート検出では、サーバーがサービス拒否攻撃に対して脆弱であることです。攻撃者は、認識しているアカウントの入力を単純に推測できるため、これらのアカウントは無効になります。ユーザーをブロックするかどうかを決定する際には、最終的にこの機能を拡張してクライアント IP アドレスを考慮します。

優れたオプションは、Fail2Ban などのツールになります。このサービスは、Red Hat Single Sign-On サーバーのログファイルでポイントできます。Red Hat Single Sign-On は、障害があるすべてのログインの失敗およびクライアント IP アドレスをログに記録します。Fail2Ban を使用して、特定の IP アドレスからの接続をブロックする攻撃を検知した後に、ファイアウォールを変更するために使用できます。

19.3.1. パスワードポリシー

もう 1 つでは、パスワード推測を防止するために、複雑なパスワードポリシーを確保して、ユーザーがパスワードの推測が困難であるようにします。詳細は、「パスワードポリシー」 の章を参照してください。

パスワード推測を防ぐ最善の方法は、サーバーがワンタイムパスワード (OTP) を使用するように設定することです。

19.4. クリックジャッキング

クリックジャッキングでは、悪意のあるサイトは、攻撃対象サイトの重要なボタンの下にダミーのボタンが配置されるように注意深く構築された透明な iframe に攻撃対象のサイトを読み込みます。ユーザーが見えるボタンを押すと、実際には隠されたページのボタン (たとえばログインボタン) がクリックされます。攻撃者はユーザーの認証情報を窃取し、リソースにアクセスすることが出来ます。

デフォルトでは、Red Hat Single Sign-On の応答はすべて、これが発生することを防止できるいくつかの特定のブラウザーヘッダーを設定します。具体的には、X-FRAME_OPTIONS および Content-Security-Policy を設定します。制御できる詳細なブラウザーアクセスが多数あるため、これらのヘッダーの両方の定義を確認する必要があります。管理コンソールでは、これらのヘッダーの任意の値を指定できます。左側のメニュー項目 Realm Settings に移動し、Security Defenses タブをクリックして Headers サブタブに遷移してください。

security headers

デフォルトでは、Red Hat Single Sign-On は、iframes に same-origin ポリシーのみを設定します。

19.5. SSL/HTTPS 要件

Red Hat Single Sign-On 認証サーバーと、セキュリティーが保護されたクライアントとの間の通信に SSL/HTTPS を使用しないと、攻撃の対象となる可能性が非常に脆弱になります。OAuth 2.0/OpenID Connect はセキュリティーにアクセストークンを使用します。SSL/HTTPS を使用しないと、攻撃者がネットワークを傍受してアクセストークンを取得することが可能です。アクセストークンを取得した後に、トークンに与えられたパーミッションの任意の操作を実行できます。

Red Hat Single Sign-On には、SSL/HTTPS 用に 3 つのモードがあります。SSL は設定が難しくなります。そのため、追加設定なしで Red Hat Single Sign-On では、localhost、192.168.x.x などのプライベート IP アドレスに対する HTTPS 以外の通信を許可します。実稼働環境では、オンボード全体で SSL が有効かつ必須になっている必要があります。

アダプター/クライアント側で、Red Hat Single Sign-On では SSL トラストマネージャーをオフにできます。トラストマネージャーは、クライアントが通信している ID を保証します。これは、DNS ドメイン名をサーバーの証明書に対して確認します。実稼働環境では、各クライアントアダプターがトラストストアを使用するように設定されていることを確認してください。そうしない場合は、中間攻撃で DNS の man に対して脆弱です。

19.6. CSRF Attacks

クロスサイトリクエストフォージェリー (CSRF) は、web ベースの攻撃で、web サイトが信頼できるユーザーまたは (HTTP リダイレクトや HTML フォームを介してなど) で認証される web ベースの攻撃です。クッキーベースの認証を使用するすべてのサイトは、これらの攻撃に対する攻撃に対して脆弱です。これらの攻撃は、投稿されたフォームまたはクエリーパラメーターに対して状態クッキーを照合することで軽減されます。

OAuth 2.0 ログイン仕様では、状態 cookie を使用し、伝送された状態 state パラメーターと照合する必要があります。すべてのログインが保護されるように、Red Hat Single Sign-On は仕様のこの部分を完全に実装します。

Red Hat Single Sign-On 管理コンソールは、バックエンド Red Hat Single Sign-On 管理 REST API への REST 呼び出しを行う純粋な JavaScript/HTML5 アプリケーションです。これらの呼び出しはすべて必要なベアラートークン認証が必要で、JavaScript Ajax 呼び出しを介して行われます。ここでは、CSRF は適用されません。管理 REST API も、CORS オリジンを検証するように設定することもできます。

CSRF にフォールバックする Red Hat Single Sign-On の唯一の部分は、ユーザーアカウント管理ページです。この Red Hat Single Sign-On を軽減するには、状態クッキーを設定し、アクションリンクの非表示フォームフィールドやクエリーパラメーターにこの状態クッキーの値を埋め込むこともできます。このクエリーまたは形式パラメーターは、ユーザーが呼び出しが作成されたことを検証するために状態クッキーに対してチェックされます。

19.7. 特定のリダイレクト URI

Authorization Code Flow では、一般的過ぎるリダイレクト URI を登録すると、アクセス範囲が広範囲に及ぶ異なるクライアントの権限になりすますことが可能です。これは、2 つのクライアントが同じドメインに存在する場合に生じる可能性があります。したがって、登録できるリダイレクト URI を実行可能とするのが得策です。

19.8. 不正アクセスおよびトークンの更新

アクセストークンを軽減し、stolen からトークンを更新する方法がいくつかあります。最も重要なことは、Red Hat Single Sign-On とクライアントおよびアプリケーション間の SSL/HTTPS 通信を適用することです。Red Hat Single Sign-On では SSL が有効化されていないため、管理者は明らかになる可能性もあります。

リークしたアクセストークンを軽減するもう 1 つのことは、寿命を短くすることです。これは、タイムアウトページ 内で指定できます。クライアントおよびアプリケーションのアクセストークンの短い寿命 (分) は、アクセストークンを更新した後にアクセストークンを更新します。管理者がリークを検出すると、すべてのサービスセッションをログアウトして、これらの更新トークンを無効にするか、取り消しポリシーを設定できます。更新トークンは常にクライアントにプライベートのままとなり、送信されることは非常に重要ではありません。

また、漏洩したアクセストークンに対して軽減し、トークンを更新するために、これらのトークンをホルダートークンの holder-of-key トークンとして発行します。詳細は、「OAuth 2.0 相互 TLS クライアント証明書バインドアクセストークン」を参照してください。

アクセストークンまたは更新トークンが漏洩された場合、まず管理コンソールに移動し、すべてのアプリケーションに not-before 失効ポリシーをプッシュする必要があります。これにより、その日付の前に発行されたすべてのトークンが無効になります。新しい not-before ポリシーをプッシュすると、アプリケーションが Red Hat Single Sign-On から新しい公開鍵を強制的にダウンロードするようにするため、レルム署名鍵の危険にさらされたと考えると、この状況にも役立ちます。詳細は、キーの章を参照してください。

また、これらのエンティティーの 1 つが完全に不正アクセスされている場合は、特定のアプリケーション、クライアント、ユーザーを無効にすることもできます。

19.9. 侵害された認証コード

OIDC Auth Code Flow では、攻撃者が Red Hat Single Sign-On 認証コードに攻撃することは非常に困難になります。Red Hat Single Sign-On は、承認コードに対して暗号で強固なランダムな値を生成するため、アクセストークンを推測することが非常に困難になります。承認コードは、アクセストークンの取得に 1 回のみ使用できます。管理コンソールでは、タイムアウトページで承認コードが有効である期間を指定できます。この値は数秒で短いため、クライアントがコードからトークンを取得するのに十分な時間で短くする必要があります。

PKCE をクライアントに適用して、リークした自動化コードに対して軽減することもできます。詳細は、「PKCE (Proof Key for Code Exchange)」を参照してください。

19.10. オープンリダイレクター

攻撃者は、エンドユーザーの承認エンドポイントとリダイレクト URI パラメーターを使用して、オープンリダイレクターとして承認サーバーを悪用することができます。オープンリディレクターは、検証を行わずにユーザーエージェントをパラメーター値で指定された場所に自動的にリダイレクトするパラメーターを使用するエンドポイントです。攻撃者は、承認サーバーでユーザーの信頼を利用してフィッシング攻撃を起動することができます。

Red Hat Single Sign-On では、登録されたすべてのアプリケーションとクライアントで少なくとも 1 つのリダイレクト URI パターンを登録する必要があります。クライアントが (ログインやログアウトなど) リダイレクトの実行を Red Hat Single Sign-On に問い合わせると、Red Hat Single Sign-On がリダイレクト URI をチェックします。有効な登録された URI パターンのリスト。オープンな redirector 攻撃を軽減するために、クライアントおよびアプリケーションが特定の URI パターンとして登録されることが重要です。

19.11. パスワードデータベースの危険にさらされました

Red Hat Single Sign-On は、パスワードを raw のテキストに保存しません。これは、PBKDF2 アルゴリズムを使用してそのハッシュを保存します。実際には、20,000 ハッシュの反復のデフォルトを使用します。これは、セキュリティーコミュニティーの推奨反復数です。これは、設計により PBKDF2 として大きなパフォーマンスヒットに加えて、大量の CPU を加速します。パスワードデータベースを保護するために深刻な設定方法を決定するのはユーザー次第です。

19.12. 制限の範囲

デフォルトでは、各クライアントアプリケーションには無制限の role scope mappings があります。つまり、そのクライアント用に作成されるすべてのアクセストークンには、ユーザーが持つすべてのパーミッションが含まれます。クライアントが不正アクセスされ、アクセストークンが漏洩されると、各システムのアクセス権限が漏洩されるようになりました。各クライアントの Scope メニューを使用してアクセストークンが割り当てられているロールを制限することが強く推奨されます。または、クライアントスコープレベルでロールスコープマッピングを設定し、Client Scope メニュー でクライアントスコープを割り当てることもできます。

19.13. トークンオーディエンスの制限

サービス間の信頼レベルが低い環境では、トークンのオーディエンスを制限することが推奨されます。この後の理由については OAuth2 Threat Model ドキュメントで説明されています。詳細情報は「オーディエンスサポート」を参照してください。

19.14. SQL インジェクション攻撃

この時点で、Red Hat Single Sign-On の SQL インジェクションの脆弱性に関するナレッジはありません。

第20章 管理 CLI

前述の章では、Red Hat Single Sign-On 管理コンソールを使用して管理タスクを実行する方法を説明しました。また、管理 CLI コマンドラインツールを使用して、コマンドラインインターフェース (CLI) からこれらのタスクを実行することもできます。

20.1. 管理 CLI のインストール

管理 CLI は、Red Hat Single Sign-On Server ディストリビューション内にパッケージ化されます。bin ディレクトリー内に実行スクリプトを見つけることができます。

Linux スクリプトは kcadm.sh と呼ばれ、Windows のスクリプトは kcadm.bat と呼ばれます。

Red Hat Single Sign-On サーバーディレクトリーを PATH に追加し、ファイルシステム上の任意の場所からクライアントを使用できます。

たとえば、以下のようになります。

  • Linux:
$ export PATH=$PATH:$KEYCLOAK_HOME/bin
$ kcadm.sh
  • Windows:
c:\> set PATH=%PATH%;%KEYCLOAK_HOME%\bin
c:\> kcadm

Red Hat Single Sign-On Server ディストリビューションを抽出したパスに KEYCLOAK_HOME 環境変数 (env) 変数が設定されていることを前提とします。

注記

繰り返し実行しないように、本書の残りの部分では、CLI の相違点が kcadm コマンド名ではなく、Windows の例のみが説明されています。

20.2. 管理 CLI の使用

管理 CLI は、管理 REST エンドポイントに HTTP 要求を行うことで機能します。アクセスは保護されており、認証が必要になります。

注記

特定のエンドポイントの JSON 属性に関する詳細は、Admin REST API のドキュメントを参照してください。

  1. 認証情報を指定し、ログインして認証されたセッションを開始します。作成、読み取り、更新、および削除 (CRUD) 操作を実行する準備が整っている。

    たとえば、

    • Linux:

      $ kcadm.sh config credentials --server http://localhost:8080/auth --realm demo --user admin --client admin
      $ kcadm.sh create realms -s realm=demorealm -s enabled=true -o
      $ CID=$(kcadm.sh create clients -r demorealm -s clientId=my_client -s 'redirectUris=["http://localhost:8980/myapp/*"]' -i)
      $ kcadm.sh get clients/$CID/installation/providers/keycloak-oidc-keycloak-json
    • Windows:

      c:\> kcadm config credentials --server http://localhost:8080/auth --realm demo --user admin --client admin
      c:\> kcadm create realms -s realm=demorealm -s enabled=true -o
      c:\> kcadm create clients -r demorealm -s clientId=my_client -s "redirectUris=[\"http://localhost:8980/myapp/*\"]" -i > clientid.txt
      c:\> set /p CID=<clientid.txt
      c:\> kcadm get clients/%CID%/installation/providers/keycloak-oidc-keycloak-json
  2. 実稼働環境では、トークンをネットワークスニファーに公開しないようにするには、https: で Red Hat Single Sign-On にアクセスする必要があります。Java のデフォルト証明書トラストストアに含まれる信頼される認証局 (CA) のいずれかによってサーバーの証明書が発行されていない場合は、truststore.jks ファイルを準備し、クライアント登録 CLI にこれを使用するように指示します。

    たとえば、以下のようになります。

    • Linux:

      $ kcadm.sh config truststore --trustpass $PASSWORD ~/.keycloak/truststore.jks
    • Windows:

      c:\> kcadm config truststore --trustpass %PASSWORD% %HOMEPATH%\.keycloak\truststore.jks

20.3. 認証

管理 CLI でログインしている場合、サーバーエンドポイント URL とレルムを指定し、ユーザー名を指定します。別のオプションとして、clientId のみを指定します。これにより、特別な「サービスアカウント」が使用されます。ユーザー名を使用してログインする場合は、指定したユーザーのパスワードを使用する必要があります。clientId を使用してログインする場合、ユーザーパスワードではなくクライアントシークレットのみが必要になります。クライアントシークレットの代わりに Signed JWT を使用することもできます。

セッションに使用されるアカウントに、Admin REST API 操作を呼び出すための適切なパーミッションがあることを確認してください。たとえば、realm-management クライアントの realm-admin ロールを指定すると、ユーザーはユーザーが定義されているレルムを管理できます。

認証には、主に 2 つのメカニズムがあります。1 つのメカニズムは kcadm config credentials を使用して認証セッションを開始します。

$ kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin --password admin

このアプローチでは、取得したアクセストークンと関連する更新トークンを保存することで、kcadm コマンド呼び出し間の認証セッションを維持します。プライベート設定ファイルで他のシークレットを保持することもできます。設定ファイルの詳細は、次の章を参照してください。

2 つ目のアプローチでは、呼び出しの間に各コマンド呼び出しが認証されるだけです。この方法では、トークンの取得でラウンドトリップで費やした時間がサーバーの負荷と長くなります。このアプローチの利点は、呼び出し間でトークンを保存する必要はありません。つまり、ディスクには保存されません。このモードは、--no-config 引数の指定時に使用されます。

たとえば、操作の実行時に、認証に必要な情報をすべて指定します。

$ kcadm.sh get realms --no-config --server http://localhost:8080/auth --realm master --user admin --password admin

管理 CLI の使用に関する詳細情報は、kcadm.sh help コマンドを実行します。

認証セッションの開始に関する詳細は、kcadm.sh config credentials --help コマンドを実行します。

20.4. 代替設定の使用

デフォルトでは、管理 CLI はユーザーのホームディレクトリー下に置かれた kcadm.config という設定ファイルを自動的に維持します。Linux ベースのシステムでは、完全パス名は $HOME/.keycloak/kcadm.config になります。Windows では、完全パス名は %HOMEPATH%\.keycloak\kcadm.config になります。--config オプションを使用して、異なるファイルまたは場所を指定して、複数の認証セッションを並行して管理することができます。

注記

単一のスレッドから単一の設定ファイルに関連付けられる操作を実行することが推奨されます。

システムの他のユーザーが設定ファイルを表示しないようにしてください。これには、プライベートに保持される必要のあるアクセストークンおよびシークレットが含まれます。デフォルトでは、~/.keycloak ディレクトリーおよびそのコンテンツは適切なアクセス制限で自動的に作成されます。ディレクトリーがすでに存在する場合、そのパーミッションは更新されません。

設定ファイル内にシークレットを保存しないようにする必要がある場合は、これを実行できます。都合は低く、トークンリクエストをより多く作成する必要があります。シークレットを保存しない場合は、すべてのコマンドで --no-config オプションを使用し、各 kcadm 呼び出しで config credentials コマンドに必要なすべての認証情報を指定します。

20.5. 基本操作およびリソース URI

管理 CLI では、特定のタスクの実行を簡素化する追加のコマンドを使用して、管理 REST API エンドポイントに対して CRUD 操作を汎用で実行することができます。

主な使用パターンを以下に示します。ここで、creategetupdate、および delete コマンドは HTTP 動詞である POSTGETPUT、および DELETE にそれぞれマッピングされます。

$ kcadm.sh create ENDPOINT [ARGUMENTS]
$ kcadm.sh get ENDPOINT [ARGUMENTS]
$ kcadm.sh update ENDPOINT [ARGUMENTS]
$ kcadm.sh delete ENDPOINT [ARGUMENTS]

ENDPOINT はターゲットリソースURI であり、絶対 (http: または https: で始まる) または相対のいずれかで、次の形式の絶対 URL を構成するために使用されます。

SERVER_URI/admin/realms/REALM/ENDPOINT

たとえば、サーバー http://localhost:8080/auth に対して認証し、レルムが master である場合は、users を ENDPOINT として使用するとリソース URL http://localhost:8080/auth/admin/realms/master/users となります。

ENDPOINT を clients に設定する場合、有効なリソース URI は http://localhost:8080/auth/admin/realms/master/clients になります。

レルムのコンテナーであるため、処理が若干異なる realms エンドポイントがあります。以下に対して解決します。

SERVER_URI/admin/realms

また、レルムに依存していないため、serverinfo エンドポイントも同じ方法として処理されます。

realm-admin 権限を持つユーザーとして認証する場合は、複数のレルムでコマンドを実行する必要がある場合があります。この場合は、コマンドが実行するレルムを明示的に指示する -r オプションを指定します。kcadm.sh config credentials--realm オプションで指定された REALM を使用する代わりに、TARGET_REALM が使用されます。

SERVER_URI/admin/realms/TARGET_REALM/ENDPOINT

以下に例を示します。

$ kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin --password admin
$ kcadm.sh create users -s username=testuser -s enabled=true -r demorealm

この例では、master レルムで admin ユーザーとして認証されたセッションを開始します。その後、リソース URL http://localhost:8080/auth/admin/realms/demorealm/users に対して POST 呼び出しを実行します。

create および update コマンドは、デフォルトで JSON ボディーをサーバーに送信します。-f FILENAME を使用して、ファイルから既製のドキュメントを読み取ることができます。-f - オプションを使用すると、メッセージの本文が標準入力から読み込まれます。前述の「ユーザーの作成」例で説明したように個別の属性とそれらの値を指定することもできます。これらは JSON ボディーによって構成され、サーバーに送信されます。

update コマンドを使用してリソースを更新する方法は複数あります。まず、リソースの現在の状態を決定してファイルに保存し、そのファイルを編集して更新のためにサーバーに送信できます。

以下に例を示します。

$ kcadm.sh get realms/demorealm > demorealm.json
$ vi demorealm.json
$ kcadm.sh update realms/demorealm -f demorealm.json

このメソッドは、送信された JSON ドキュメントのすべての属性でサーバーのリソースを更新します。

また、-s, --set オプションを使用してオンザフライで更新を実行し、新しい値を設定することもできます。

以下に例を示します。

$ kcadm.sh update realms/demorealm -s enabled=false

この方法は、enabled 属性のみを false に更新します。

デフォルトでは、update コマンドは最初に get を実行し、新しい属性値を既存の値とマージします。これは推奨される動作です。エンドポイントが PUT コマンドをサポートするかもしれませんが、GET コマンドではない場合もあります。-n オプションを使用して「no-merge」更新を実行できます。これは、GET コマンドを最初に実行せずに PUT コマンドを実行します。

20.6. レルム操作

新しいレルムの作成

realms エンドポイントで create コマンドを使用して、新しい有効なレルムを作成し、属性を realm および enabled に設定します。

$ kcadm.sh create realms -s realm=demorealm -s enabled=true

レルムはデフォルトでは有効になっていません。これを有効にすると、認証にレルムをすぐに使用できます。

新規オブジェクトの説明には、JSON 形式を使用することもできます。

$ kcadm.sh create realms -f demorealm.json

レルム属性を使用して JSON ドキュメントをファイルから直接送信するか、または標準入力にパイプして送信できます。

たとえば、以下のようになります。

  • Linux:
$ kcadm.sh create realms -f - << EOF
{ "realm": "demorealm", "enabled": true }
EOF
  • Windows:
c:\> echo { "realm": "demorealm", "enabled": true } | kcadm create realms -f -

既存のレルムの一覧表示

以下のコマンドは、すべてのレルムのリストを返します。

$ kcadm.sh get realms
注記

レルムの一覧はサーバー上でさらにフィルタリングされ、ユーザーが確認できるレルムのみを返します。

レルムの説明全体を返すと、多くの場合、情報が非常に多すぎます。ほとんどのユーザーは、レルム名やレルムが有効かどうかなど、属性のサブセットのみに関心があります。--fields オプションを使用して、返す属性を指定できます。

$ kcadm.sh get realms --fields realm,enabled

結果をコンマ区切りの値として表示することもできます。

$ kcadm.sh get realms --fields realm --format csv --noquotes

特定のレルムの取得

レルム名をコレクション URI に追加し、個別のレルムを取得します。

$ kcadm.sh get realms/master

レルムの更新

  1. レルムの属性のみを変更する場合に、-s オプションを使用して属性に新しい値を設定します。

    以下に例を示します。

    $ kcadm.sh update realms/demorealm -s enabled=false
  2. 新しい値で書き込み可能な属性をすべて設定する場合は、get コマンドを実行して、JSON ファイルの現在の値を編集し、resubmit を実行します。

    以下に例を示します。

    $ kcadm.sh get realms/demorealm > demorealm.json
    $ vi demorealm.json
    $ kcadm.sh update realms/demorealm -f demorealm.json

レルムの削除

以下のコマンドを実行してレルムを削除します。

$ kcadm.sh delete realms/demorealm

レルムのすべてのログインページオプションをオンにする

特定の機能を制御する属性を true に設定します。

以下に例を示します。

$ kcadm.sh update realms/demorealm -s registrationAllowed=true -s registrationEmailAsUsername=true -s rememberMe=true -s verifyEmail=true -s resetPasswordAllowed=true -s editUsernameAllowed=true

レルムキーの一覧表示

ターゲットレルムの keys エンドポイントで get 操作を使用します。

$ kcadm.sh get keys -r demorealm

新しいレルムキーの生成

  1. 新しい RSA 生成鍵のペアを追加する前に、ターゲットレルムの ID を取得します。

    以下に例を示します。

    $ kcadm.sh get realms/demorealm --fields id --format csv --noquotes
  2. kcadm.sh get keys -r demorealm によって明らかになったように、既存のプロバイダーよりも優先度の高い新規キープロバイダーを追加します。

    たとえば、以下のようになります。

    • Linux:

      $ kcadm.sh create components -r demorealm -s name=rsa-generated -s providerId=rsa-generated -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s 'config.priority=["101"]' -s 'config.enabled=["true"]' -s 'config.active=["true"]' -s 'config.keySize=["2048"]'
    • Windows:

      c:\> kcadm create components -r demorealm -s name=rsa-generated -s providerId=rsa-generated -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s "config.priority=[\"101\"]" -s "config.enabled=[\"true\"]" -s "config.active=[\"true\"]" -s "config.keySize=[\"2048\"]"
  3. parentId 属性をターゲットレルムの ID の値に設定します。

    新たに追加されたキーは、kcadm.sh get keys -r demorealm によって明らかになったように、アクティブキーになります。

Java キーストアファイルから新しいレルムキーの追加

  1. 新しいキープロバイダーを追加して、サーバーに JKS ファイルとしてすでに準備済みの新規キーペアを追加します。

    たとえば、以下のようになります。

    • Linux:

      $ kcadm.sh create components -r demorealm -s name=java-keystore -s providerId=java-keystore -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s 'config.priority=["101"]' -s 'config.enabled=["true"]' -s 'config.active=["true"]' -s 'config.keystore=["/opt/keycloak/keystore.jks"]' -s 'config.keystorePassword=["secret"]' -s 'config.keyPassword=["secret"]' -s 'config.alias=["localhost"]'
    • Windows:

      c:\> kcadm create components -r demorealm -s name=java-keystore -s providerId=java-keystore -s providerType=org.keycloak.keys.KeyProvider -s parentId=959844c1-d149-41d7-8359-6aa527fca0b0 -s "config.priority=[\"101\"]" -s "config.enabled=[\"true\"]" -s "config.active=[\"true\"]" -s "config.keystore=[\"/opt/keycloak/keystore.jks\"]" -s "config.keystorePassword=[\"secret\"]" -s "config.keyPassword=[\"secret\"]" -s "config.alias=[\"localhost\"]"
  2. 特定のキーストアに一致するように、keystorekeystorePasswordkeyPassword、および alias 属性値を変更するようにしてください。
  3. parentId 属性をターゲットレルムの ID の値に設定します。

鍵のパッシブの作成または鍵の無効化

  1. パッシブを作成する鍵を特定します。

    $ kcadm.sh get keys -r demorealm
  2. キーの providerId 属性を使用して、components/PROVIDER_ID などのエンドポイント URI を作成します。
  3. update を実行します。

    たとえば、以下のようになります。

    • Linux:

      $ kcadm.sh update components/PROVIDER_ID -r demorealm -s 'config.active=["false"]'
    • Windows:

      c:\> kcadm update components/PROVIDER_ID -r demorealm -s "config.active=[\"false\"]"

      他のキー属性を更新できます。

  4. 新しい enabled 値を設定してキーを無効にします(例: config.enabled=["false"])。
  5. 新規の priority の値を設定し、キーの優先度を変更します (例: config.priority=["110"])。

古いキーの削除

  1. 削除する鍵がパッシブかつ無効になっており、既存のトークンがアプリケーションに保持され、ユーザーが突然失敗するのを防ぎます。
  2. パッシブを作成する鍵を特定します。

    $ kcadm.sh get keys -r demorealm
  3. そのキーの providerId を使用して削除を実行します。

    $ kcadm.sh delete components/PROVIDER_ID -r demorealm

レルムのイベントロギングの設定

events/config エンドポイントで update コマンドを使用します。

eventsListeners 属性には、イベントを受信するすべてのイベントリスナーを指定する EventListenerProviderFactory ID の一覧が含まれます。個別に、ビルトインイベントストレージを制御する属性があり、管理 REST API 経由で過去のイベントをクエリーできます。サービス呼び出しのロギング (eventsEnabled) および監査イベントは、管理コンソールまたは管理者 REST API (adminEventsEnabled) 中にトリガーされる別個のコントロールがあります。データベースに満杯にならないように古いイベントの有効期限を設定することもできます。eventsExpiration は秒単位で表される持続可能時間に設定されます。

すべてのイベントを受信し、jboss-logging 経由でログに記録する組み込みイベントリスナーの設定例を以下に示します。(org.keycloak.events と呼ばれるロガーを使用して、エラーイベントは WARN としてログに記録され、それ以外は DEBUG としてログに記録されます。)

たとえば、以下のようになります。

  • Linux:
$ kcadm.sh update events/config -r demorealm -s 'eventsListeners=["jboss-logging"]'
  • Windows:
c:\> kcadm update events/config -r demorealm -s "eventsListeners=[\"jboss-logging\"]"

次に、利用可能なすべての ERROR イベント (監査イベントは含まない) のストレージを 2 日間有効にして、管理 REST 経由で取得できるようにする例を示します。

たとえば、以下のようになります。

  • Linux:
$ kcadm.sh update events/config -r demorealm -s eventsEnabled=true -s 'enabledEventTypes=["LOGIN_ERROR","REGISTER_ERROR","LOGOUT_ERROR","CODE_TO_TOKEN_ERROR","CLIENT_LOGIN_ERROR","FEDERATED_IDENTITY_LINK_ERROR","REMOVE_FEDERATED_IDENTITY_ERROR","UPDATE_EMAIL_ERROR","UPDATE_PROFILE_ERROR","UPDATE_PASSWORD_ERROR","UPDATE_TOTP_ERROR","VERIFY_EMAIL_ERROR","REMOVE_TOTP_ERROR","SEND_VERIFY_EMAIL_ERROR","SEND_RESET_PASSWORD_ERROR","SEND_IDENTITY_PROVIDER_LINK_ERROR","RESET_PASSWORD_ERROR","IDENTITY_PROVIDER_FIRST_LOGIN_ERROR","IDENTITY_PROVIDER_POST_LOGIN_ERROR","CUSTOM_REQUIRED_ACTION_ERROR","EXECUTE_ACTIONS_ERROR","CLIENT_REGISTER_ERROR","CLIENT_UPDATE_ERROR","CLIENT_DELETE_ERROR"]' -s eventsExpiration=172800
  • Windows:
c:\> kcadm update events/config -r demorealm -s eventsEnabled=true -s "enabledEventTypes=[\"LOGIN_ERROR\",\"REGISTER_ERROR\",\"LOGOUT_ERROR\",\"CODE_TO_TOKEN_ERROR\",\"CLIENT_LOGIN_ERROR\",\"FEDERATED_IDENTITY_LINK_ERROR\",\"REMOVE_FEDERATED_IDENTITY_ERROR\",\"UPDATE_EMAIL_ERROR\",\"UPDATE_PROFILE_ERROR\",\"UPDATE_PASSWORD_ERROR\",\"UPDATE_TOTP_ERROR\",\"VERIFY_EMAIL_ERROR\",\"REMOVE_TOTP_ERROR\",\"SEND_VERIFY_EMAIL_ERROR\",\"SEND_RESET_PASSWORD_ERROR\",\"SEND_IDENTITY_PROVIDER_LINK_ERROR\",\"RESET_PASSWORD_ERROR\",\"IDENTITY_PROVIDER_FIRST_LOGIN_ERROR\",\"IDENTITY_PROVIDER_POST_LOGIN_ERROR\",\"CUSTOM_REQUIRED_ACTION_ERROR\",\"EXECUTE_ACTIONS_ERROR\",\"CLIENT_REGISTER_ERROR\",\"CLIENT_UPDATE_ERROR\",\"CLIENT_DELETE_ERROR\"]" -s eventsExpiration=172800

以下は、保存されたイベントタイプを 利用可能なすべてのイベントタイプ にリセットする方法の例になります。すべてのイベントタイプを列挙するのと同じものになります。

$ kcadm.sh update events/config -r demorealm -s enabledEventTypes=[]

以下は、監査イベントのストレージを有効にする方法の例になります。

$ kcadm.sh update events/config -r demorealm -s adminEventsEnabled=true -s adminEventsDetailsEnabled=true

最新の 100 イベントを取得する方法の例を以下に示します。これらは最新のものから最も古いものへと順序付けられます。

$ kcadm.sh get events --offset 0 --limit 100

以下は、保存されたすべてのイベントを削除する方法の例になります。

$ kcadm delete events

キャッシュのフラッシュ

  1. create コマンドと、clear-realm-cacheclear-user-cache、または clear-keys-cache のいずれかのエンドポイントを使用します。
  2. realm をターゲットレルムと同じ値に設定します。

    以下に例を示します。

    $ kcadm.sh create clear-realm-cache -r demorealm -s realm=demorealm
    $ kcadm.sh create clear-user-cache -r demorealm -s realm=demorealm
    $ kcadm.sh create clear-keys-cache -r demorealm -s realm=demorealm

エクスポートされた .json ファイルからのレルムのインポート

  1. partialImport エンドポイントで create コマンドを使用します。
  2. ifResourceExists を、FAILSKIPOVERWRITE のいずれかに設定します。
  3. -f を使用して、エクスポートしたレルムの .json ファイルを送信します。

    以下に例を示します。

    $ kcadm.sh create partialImport -r demorealm2 -s ifResourceExists=FAIL -o -f demorealm.json

    レルムが存在しない場合は、最初に作成する必要があります。

    以下に例を示します。

    $ kcadm.sh create realms -s realm=demorealm2 -s enabled=true

20.7. ロール操作

レルムロールの作成

roles エンドポイントを使用してレルムロールを作成します。

$ kcadm.sh create roles -r demorealm -s name=user -s 'description=Regular user with limited set of permissions'

クライアントロールの作成

  1. 最初にクライアントを特定し、get コマンドを使用してクライアントロールの作成時に利用可能なクライアントを一覧表示します。

    $ kcadm.sh get clients -r demorealm --fields id,clientId
  2. clientId 属性を使用して、clients/ID/roles などのエンドポイント URI を構築して新規ロールを作成します。

    以下に例を示します。

    $ kcadm.sh create clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles -r demorealm -s name=editor -s 'description=Editor can edit, and publish any article'

レルムロールの一覧表示

roles エンドポイントで get コマンドを使用して、既存のレルムロールを一覧表示します。

$ kcadm.sh get roles -r demorealm

get-roles コマンドも使用できます。

$ kcadm.sh get-roles -r demorealm

クライアントロールの一覧表示

レルムおよびクライアントロールの一覧表示を簡素化するための専用の get-roles コマンドがあります。get コマンドの拡張機能であり、ロールを一覧表示するための追加のセマンティクスと同じように動作します。

get-roles コマンドを使用して clientId 属性 (--cclientid オプションを使用) または id (--cid オプションを使用) のいずれかを渡して、クライアントロールをリストするクライアントを特定します。

以下に例を示します。

$ kcadm.sh get-roles -r demorealm --cclientid realm-management

特定のレルムロールの取得

get コマンドおよびロール を使用して、特定のレルムロール (roles/ROLE_NAME) のエンドポイント URI を作成します。user は、既存ロールの名前に置き換えます。

以下に例を示します。

$ kcadm.sh get roles/user -r demorealm

特定の get-roles コマンドを使用して、ロール名 (--rolename オプションを使用) または ID (--roleid オプションを使用)を渡すこともできます。

以下に例を示します。

$ kcadm.sh get-roles -r demorealm --rolename user

特定のクライアントロールの取得

専用の get-roles コマンドを使用して clientId 属性 (--cclientid オプションを使用) または ID (--cid オプションを使用) のいずれかを渡してクライアントを特定し、ロール名 (--rolename オプションを使用) または ID (--roleid 経由) のいずれかを渡します。

以下に例を示します。

$ kcadm.sh get-roles -r demorealm --cclientid realm-management --rolename manage-clients

レルムロールの更新

特定のレルムロールを取得するために使用した同じエンドポイント URI で update コマンドを使用します。

以下に例を示します。

$ kcadm.sh update roles/user -r demorealm -s 'description=Role representing a regular user'

クライアントロールの更新

update コマンドを、特定のクライアントロールの取得に使用したのと同じエンドポイント URI で使用します。

以下に例を示します。

$ kcadm.sh update clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm -s 'description=User that can edit, and publish articles'

レルムロールの削除

特定のレルムロールを取得するために使用した同じエンドポイント URI で delete コマンドを使用します。

以下に例を示します。

$ kcadm.sh delete roles/user -r demorealm

クライアントロールの削除

特定のクライアントロールを取得するために使用したエンドポイント URI で delete コマンドを使用します。

以下に例を示します。

$ kcadm.sh delete clients/a95b6af3-0bdc-4878-ae2e-6d61a4eca9a0/roles/editor -r demorealm

複合ロールに割り当てられている、利用可能、有効なレルムロールの一覧表示

複合ロールに割り当てられ、利用可能な、有効なレルムロールを一覧表示するには、専用の get-roles コマンドを使用します。

  1. 複合ロールに 割り当てられた レルムロールを一覧表示するには、(--rname オプション) または ID (--rid オプション) のいずれかで、ターゲットの複号ロールを指定できます。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole --effective
  3. --available オプションを使用して、複合ロールに追加できるレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole --available

複合ロールに割り当てられている、利用可能、有効なクライアントロールの一覧表示

複合ロールに割り当てられ、利用可能な、有効なクライアントロールを一覧表示するには、専用の get-roles コマンドを使用します。

  1. 複合ロールに 割り当てられた クライアントロールを一覧表示するには、名前 (--rname オプション) または ID (--rid オプション) のいずれかでターゲット複号ロールを指定し、clientId 属性 (--cclientid オプションを使用) または ID (--cid オプションを使用) のいずれかでターゲット複合ロールを指定できます。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management --effective
  3. --available オプションを使用して、ターゲット複合ロールに追加できるレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --rname testrole --cclientid realm-management --available

レルムロールの複合ロールへの追加

レルムロールおよびクライアントロールの追加に使用できる専用の add-roles コマンドがあります。

以下の例では、user ロールを複合ロール testrole に追加します。

$ kcadm.sh add-roles --rname testrole --rolename user -r demorealm

複合ロールからのレルムロールの削除

レルムロールおよびクライアントロールの削除に使用できる専用の remove-roles コマンドがあります。

以下の例では、ターゲット複合ロール testrole から user ロールを削除します。

$ kcadm.sh remove-roles --rname testrole --rolename user -r demorealm

クライアントロールのレルムロールへの追加

レルムロールおよびクライアントロールの追加に使用できる専用の add-roles コマンドを使用します。

以下の例では、クライアント realm-management に定義したロールを追加します。create-client ロールおよび view-users ロールに定義されたロールを testrole 複合ロールに追加します。

$ kcadm.sh add-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users

クライアントロールへのクライアントロールの追加

  1. get-roles コマンドを使用して、複合クライアントロールの ID を確認します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --cclientid test-client --rolename operations
  2. test-client の clientId 属性と、support と呼ばれるクライアントロール、および operations と呼ばれる別のクライアントロールがあるクライアントがあります。これは、複合ロールになり、ID は「fc400897-ef6a-4e8c-872b-1581b7fa8a71」となります。
  3. 以下の例を使用して、別のロールを複合ロールに追加します。

    $ kcadm.sh add-roles -r demorealm --cclientid test-client --rid fc400897-ef6a-4e8c-872b-1581b7fa8a71 --rolename support
  4. get-roles --all コマンドを使用して、複合ロールのロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles --rid fc400897-ef6a-4e8c-872b-1581b7fa8a71 --all

複合ロールからのクライアントロールの削除

専用の remove-roles コマンドを使用して、複合ロールからクライアントロールを削除します。

以下の例を使用して、クライアントの realm-management で定義された 2 つのロールを削除します (create-client ロールと view-users ロール) を testrole 複合ロールから削除します。

$ kcadm.sh remove-roles -r demorealm --rname testrole --cclientid realm-management --rolename create-client --rolename view-users

クライアントロールのグループへの追加

レルムロールおよびクライアントロールの追加に使用できる専用の add-roles コマンドを使用します。

以下の例では、クライアント realm-management に定義したロールを追加します。create-client ロールおよび view-users ロールを Group グループ (--gname オプション) に追加します。代わりに、グループを ID で指定できます (--gid オプションを使用)。

グループに対して実行できる操作の詳細は、「グループ操作」を参照してください。

$ kcadm.sh add-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users

グループからのクライアントロールの削除

専用の remove-roles コマンドを使用して、クライアントロールをグループから削除します。

以下の例を使用して、クライアントの realm-management で定義された 2 つのロールを削除します (create-client ロールと view-users ロールを Group グループから削除します)。

グループに対して実行できる操作の詳細は、「グループ操作」を参照してください。

$ kcadm.sh remove-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users

20.8. クライアント操作

クライアントの作成

  1. クライアントエンドポイントで create コマンドを実行して、新しい clients エンドポイントを作成します。

    以下に例を示します。

    $ kcadm.sh create clients -r demorealm -s clientId=myapp -s enabled=true
  2. 認証するアダプターのシークレットを設定する場合は、シークレットを指定します。

    以下に例を示します。

    $ kcadm.sh create clients -r demorealm -s clientId=myapp -s enabled=true -s clientAuthenticatorType=client-secret -s secret=d0b8122f-8dfb-46b7-b68a-f5cc4e25d000

クライアントの一覧表示

clients エンドポイントで get コマンドを使用してクライアントを一覧表示します。

以下に例を示します。

$ kcadm.sh get clients -r demorealm --fields id,clientId

この例では、出力をフィルタリングして、id および clientId 属性のみを一覧表示します。

特定のクライアントの取得

クライアントの ID を使用して、クライアント/ID などの特定のクライアントをターゲットとするエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm

特定クライアントの現在のシークレットの取得

クライアントの ID を使用して、client/ID/client-secret などのエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get clients/$CID/client-secret

特定クライアントのアダプター設定ファイル (keycloak.json) の取得

クライアントの ID を使用して、clients/ID/installation/providers/keycloak-oidc-keycloak-json などの特定のクライアントをターゲットとするエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-keycloak-json -r demorealm

特定クライアントの WildFly サブシステムアダプター設定の取得

クライアントの ID を使用して、clients/ID/installation/providers/keycloak-oidc-jboss-subsystem などの特定のクライアントをターゲットとするエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/providers/keycloak-oidc-jboss-subsystem -r demorealm

特定クライアントの Docker-v2 の設定例

クライアントの ID を使用して、clients/ID/installation/providers/docker-v2-compose-yaml などの特定のクライアントをターゲットとするエンドポイント URI を作成します。

応答は in.zip 形式になることに注意してください。

以下に例を示します。

$ kcadm.sh get http://localhost:8080/auth/admin/realms/demorealm/clients/8f271c35-44e3-446f-8953-b0893810ebe7/installation/providers/docker-v2-compose-yaml -r demorealm > keycloak-docker-compose-yaml.zip

クライアントの更新

update コマンドを、特定のクライアントを取得するために使用したのと同じエンドポイント URI で使用します。

たとえば、以下のようになります。

  • Linux:
$ kcadm.sh update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s 'redirectUris=["http://localhost:8080/myapp/*"]' -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp
  • Windows:
c:\> kcadm update clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm -s enabled=false -s publicClient=true -s "redirectUris=[\"http://localhost:8080/myapp/*\"]" -s baseUrl=http://localhost:8080/myapp -s adminUrl=http://localhost:8080/myapp

クライアントの削除

特定のクライアントを取得するために使用したエンドポイント URI で delete コマンドを使用します。

以下に例を示します。

$ kcadm.sh delete clients/c7b8547f-e748-4333-95d0-410b76b3f4a3 -r demorealm

クライアントのサービスアカウントのロールの追加または削除

クライアントのサービスアカウントは、ユーザー名 service-account-CLIENT_ID を持つ特別なユーザーアカウントです。このアカウントでユーザーの操作は、通常ユーザーであるかのように実行できます。

20.9. ユーザー操作

ユーザーの作成

users エンドポイントで create コマンドを実行して新規ユーザーを作成します。

以下に例を示します。

$ kcadm.sh create users -r demorealm -s username=testuser -s enabled=true

ユーザーの一覧表示

users エンドポイントを使用してユーザーを一覧表示します。次回ログイン時に、ターゲットユーザーはパスワードを変更する必要があります。

以下に例を示します。

$ kcadm.sh get users -r demorealm --offset 0 --limit 1000

usernamefirstNamelastName、または email でユーザーを絞り込むことができます。

以下に例を示します。

$ kcadm.sh get users -r demorealm -q email=google.com
$ kcadm.sh get users -r demorealm -q username=testuser
注記

フィルタリングは完全一致を使用しません。たとえば、上記の例は、*testuser* パターンに対する username 属性の値と一致します。

複数の属性でフィルターをかけることも可能です。これは、すべての属性の条件と一致するユーザーのみを返す、-q オプションを指定して行います。

特定ユーザーの取得

ユーザーの ID を使用して、users/USER_ID などのエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm

ユーザーの更新

update コマンドを、特定のクライアントを取得するために使用したのと同じエンドポイント URI で使用します。

たとえば、以下のようになります。

  • Linux:
$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s 'requiredActions=["VERIFY_EMAIL","UPDATE_PROFILE","CONFIGURE_TOTP","UPDATE_PASSWORD"]'
  • Windows:
c:\> kcadm update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm -s "requiredActions=[\"VERIFY_EMAIL\",\"UPDATE_PROFILE\",\"CONFIGURE_TOTP\",\"UPDATE_PASSWORD\"]"

ユーザーの削除

delete コマンドを、特定のクライアントを取得するために使用したのと同じエンドポイント URI で使用します。

以下に例を示します。

$ kcadm.sh delete users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm

ユーザーのパスワードのリセット

専用の set-password コマンドを使用して、ユーザーのパスワードをリセットします。

以下に例を示します。

$ kcadm.sh set-password -r demorealm --username testuser --new-password NEWPASSWORD --temporary

このコマンドは、ユーザーに一時パスワードを設定します。次回ログイン時に、ターゲットユーザーはパスワードを変更する必要があります。

id 属性を使用してユーザーを指定する場合は、--userid を使用できます。

users/USER_ID/reset-password など、特定のユーザーから構築されたエンドポイントで update コマンドを使用すると同じ結果が得られます。

以下に例を示します。

$ kcadm.sh update users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2/reset-password -r demorealm -s type=password -s value=NEWPASSWORD -s temporary=true -n

最後のパラメーター (-n) は、前の GET コマンドなしで PUT コマンドのみが実行されるようにします。reset-password エンドポイントは GET をサポートしないため、このインスタンスには必要です。

ユーザーに割り当てられている利用可能で有効なレルムロールの一覧表示

ユーザーに割り当てられ、利用可能な、有効なレルムロールを一覧表示するには、専用の get-roles コマンドを使用できます。

  1. ユーザーに 割り当てられた レルムロールを一覧表示するには、ユーザー名または ID のいずれかでターゲットユーザーを指定します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser --effective
  3. --available オプションを使用して、ユーザーに追加できるレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser --available

ユーザーに割り当てられている利用可能で有効なクライアントロールの一覧表示

ユーザーに割り当てられ、利用可能な、有効なクライアントロールを一覧表示するには、専用の get-roles コマンドを使用します。

  1. ユーザー名 (--uusername オプション) または ID (--uid オプション) のいずれかでターゲットユーザーを指定し、clientId 属性 (--cclientid オプション) または ID (--cid オプション) のいずれかでクライアントを指定して、そのユーザーに対する assigned クライアントロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management --effective
  3. --available オプションを使用して、ユーザーに追加できるレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --uusername testuser --cclientid realm-management --available

レルムロールのユーザーへの追加

レルムロールをユーザーに追加するには、専用の add-roles コマンドを使用します。

以下の例を使用して、user ロールを testuser ユーザーに追加します。

$ kcadm.sh add-roles --uusername testuser --rolename user -r demorealm

ユーザーからのレルムロールの削除

ユーザーからレルムロールを削除するには、専用の remove-roles コマンドを使用します。

以下の例を使用して、ユーザー testuser から user ロールを削除します。

$ kcadm.sh remove-roles --uusername testuser --rolename user -r demorealm

クライアントロールのユーザーへの追加

専用の add-roles コマンドを使用して、クライアントロールをユーザーに追加します。

以下の例を使用して、クライアントの レルム管理 で定義された 2 つのロールを追加します (create-client ロールと view-users ロールをユーザー testuser に追加します)。

$ kcadm.sh add-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users

ユーザーからのクライアントロールの削除

専用の remove-roles コマンドを使用して、クライアントロールをユーザーから削除します。

以下の例を使用して、レルム管理クライアントで定義された 2 つのロールを削除します。

$ kcadm.sh remove-roles -r demorealm --uusername testuser --cclientid realm-management --rolename create-client --rolename view-users

ユーザーのセッションの一覧表示

  1. ユーザーの ID を特定し、これを使用して users/ID/sessions などのエンドポイント URI を作成します。
  2. get コマンドを使用して、ユーザーのセッションの一覧を取得します。

    以下に例を示します。

    $kcadm get users/6da5ab89-3397-4205-afaa-e201ff638f9e/sessions

特定のセッションからユーザーをログアウト

  1. 上記のようにセッションの ID を決定します。
  2. セッションの ID を使用して、sessions/ID などのエンドポイント URI を作成します。
  3. delete コマンドを使用してセッションを無効にします。

    以下に例を示します。

    $ kcadm.sh delete sessions/d0eaa7cc-8c5d-489d-811a-69d3c4ec84d1

全セッションからユーザーをログアウト

users/ID/logout などのエンドポイント URI を作成するには、ユーザーの ID が必要です。

create コマンドを使用して、そのエンドポイント URI で POST を実行します。

以下に例を示します。

$ kcadm.sh create users/6da5ab89-3397-4205-afaa-e201ff638f9e/logout -r demorealm -s realm=demorealm -s user=6da5ab89-3397-4205-afaa-e201ff638f9e

20.10. グループ操作

グループの作成

groups エンドポイントで create コマンドを使用して新規グループを作成します。

以下に例を示します。

$ kcadm.sh create groups -r demorealm -s name=Group

グループの一覧表示

groups エンドポイントで get コマンドを使用してグループの一覧を表示します。

以下に例を示します。

$ kcadm.sh get groups -r demorealm

特定グループの取得

グループの ID を使用して、groups/GROUP_ID などのエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm

グループの更新

update コマンドを、特定のユーザーを取得するために使用したのと同じエンドポイント URI で使用します。

以下に例を示します。

$ kcadm.sh update groups/51204821-0580-46db-8f2d-27106c6b5ded -s 'attributes.email=["group@example.com"]' -r demorealm

グループの削除

delete コマンドを、特定のグループを取得するために使用したのと同じエンドポイント URI で使用します。

以下に例を示します。

$ kcadm.sh delete groups/51204821-0580-46db-8f2d-27106c6b5ded -r demorealm

サブグループの作成

グループを一覧表示して親グループの ID を見つけ、その ID を使用して groups/GROUP_ID/children などのエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s name=SubGroup

別のグループでのグループの移動

  1. 既存の親グループの ID と既存の子グループの ID を検索します。
  2. 親グループの ID を使用して groups/PARENT_GROUP_ID/children などのエンドポイント URI を作成します。
  3. このエンドポイントで create コマンドを実行し、子グループの ID を JSON の本文として渡します。

以下に例を示します。

$ kcadm.sh create groups/51204821-0580-46db-8f2d-27106c6b5ded/children -r demorealm -s id=08d410c6-d585-4059-bb07-54dcb92c5094

特定ユーザーのグループを取得する

ユーザーの ID を使用してグループ内のユーザーのメンバーシップを判別し、users/USER_ID/groups などのエンドポイント URI を作成します。

以下に例を示します。

$ kcadm.sh get users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups -r demorealm

グループへのユーザーの追加

users/USER_ID/groups/GROUP_ID などのユーザーの ID とグループの ID で構成されるエンドポイント URI で update コマンドを使用し、ユーザーをグループに追加します。

以下に例を示します。

$ kcadm.sh update users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm -s realm=demorealm -s userId=b544f379-5fc4-49e5-8a8d-5cfb71f46f53 -s groupId=ce01117a-7426-4670-a29a-5c118056fe20 -n

グループからのユーザーの削除

users/USER_ID/groups/GROUP_ID などのグループにユーザーを追加するのに使用するエンドポイント URI で delete コマンドを使用し、グループからユーザーを削除します。

以下に例を示します。

$ kcadm.sh delete users/b544f379-5fc4-49e5-8a8d-5cfb71f46f53/groups/ce01117a-7426-4670-a29a-5c118056fe20 -r demorealm

グループに割り当てられている利用可能で有効なレルムロールの一覧表示

専用の get-roles コマンドを使用して、グループに割り当てられた、利用可能かつ有効なレルムロールを一覧表示します。

  1. ターゲットグループを名前 (via the --gname オプション)、パス ([command] --gpathオプション)、または ID (--gid オプション) で 指定して、グループに割り当てられた レルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group --effective
  3. --available オプションを使用して、グループに追加可能なレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group --available

グループに割り当てられた、利用可能、有効なクライアントロールの一覧表示

グループに割り当てられ、利用可能な、有効なクライアントロールを一覧表示するには、専用の get-roles コマンドを使用します。

  1. 名前 (--gname オプション) または ID (--gid オプション) のいずれかでターゲットグループを指定し、clientId 属性 ([command] --cclientid オプション) または ID (--id オプション) のいずれかでクライアントを指定して、そのユーザーに対する 割り当てられた クライアントロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management
  2. 有効な レルムロールの一覧を表示するには、追加の --effective オプションを使用します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management --effective
  3. --available オプションを使用して、グループに追加可能なレルムロールを一覧表示します。

    以下に例を示します。

    $ kcadm.sh get-roles -r demorealm --gname Group --cclientid realm-management --available

20.11. アイデンティティープロバイダー操作

利用可能なアイデンティティープロバイダーの一覧表示

serverinfo エンドポイントを使用して利用可能な ID プロバイダーを一覧表示します。

以下に例を示します。

$ kcadm.sh get serverinfo -r demorealm --fields 'identityProviders(*)'
注記

serverinfo エンドポイントは、特定のレルム外に存在するため、ターゲットレルムとの対比で解決されないという点で realms エンドポイントと同様に処理されます。

設定済みのアイデンティティープロバイダーの一覧表示

identity-provider/instances エンドポイントを使用します。

以下に例を示します。

$ kcadm.sh get identity-provider/instances -r demorealm --fields alias,providerId,enabled

特定の設定されたアイデンティティープロバイダーの取得

アイデンティティープロバイダーの alias 属性を使用して、identity-provider/instances/ALIAS などのエンドポイント URI を作成して特定のアイデンティティープロバイダーを取得します。

以下に例を示します。

$ kcadm.sh get identity-provider/instances/facebook -r demorealm

特定の設定されたアイデンティティープロバイダーの削除

delete コマンドを、特定の設定済みのアイデンティティープロバイダーを取得するために使用した同じエンドポイント URI で使用して、特定の設定済みのアイデンティティープロバイダーを削除します。

以下に例を示します。

$ kcadm.sh delete identity-provider/instances/facebook -r demorealm

Keycloak OpenID Connect アイデンティティープロバイダーの設定

  1. 新規 ID プロバイダーインスタンスの作成時に、keycloak-oidcproviderId として使用します。
  2. config 属性を指定します (authorizationUrltokenUrlclientId、および clientSecret)。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=keycloak-oidc -s providerId=keycloak-oidc -s enabled=true -s 'config.useJwksUrl="true"' -s config.authorizationUrl=http://localhost:8180/auth/realms/demorealm/protocol/openid-connect/auth -s config.tokenUrl=http://localhost:8180/auth/realms/demorealm/protocol/openid-connect/token -s config.clientId=demo-oidc-provider -s config.clientSecret=secret

OpenID Connect ID プロバイダーの設定

providerId 属性値を oidc に設定した場合を除き、Keycloak OpenID Connect プロバイダーを設定する方法で汎用 OpenID Connect プロバイダーを設定します。

SAML 2 アイデンティティープロバイダーの設定

  1. samlproviderId として使用します。
  2. config 属性 (singleSignOnServiceUrlnameIDPolicyFormatsignatureAlgorithm) を提供します。

以下に例を示します。

$ kcadm.sh create identity-provider/instances -r demorealm -s alias=saml -s providerId=saml -s enabled=true -s 'config.useJwksUrl="true"' -s config.singleSignOnServiceUrl=http://localhost:8180/auth/realms/saml-broker-realm/protocol/saml -s config.nameIDPolicyFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent -s config.signatureAlgorithm=RSA_SHA256

Facebook アイデンティティープロバイダーの設定

  1. facebookproviderId として使用します。
  2. config 属性 (clientId および clientSecret) を指定します。これらの属性は、アプリケーションの Facebook Developers アプリケーション構成ページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=facebook -s providerId=facebook -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=FACEBOOK_CLIENT_ID -s config.clientSecret=FACEBOOK_CLIENT_SECRET

Google ID プロバイダーの設定

  1. providerId として google を使用します。
  2. config 属性 (clientId および clientSecret) を指定します。これらの属性は、アプリケーションの Google Developers アプリケーション設定ページで確認できます。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=google -s providerId=google -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=GOOGLE_CLIENT_ID -s config.clientSecret=GOOGLE_CLIENT_SECRET

Twitter アイデンティティープロバイダーの設定

  1. twitterproviderId として使用します。
  2. config 属性 (clientId および clientSecret) を指定します。これらの属性は、アプリケーションの Twitter Application Management アプリケーション設定ページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=google -s providerId=google -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=TWITTER_API_KEY -s config.clientSecret=TWITTER_API_SECRET

GitHub ID プロバイダーの設定

  1. githubproviderId として使用します。
  2. config 属性 (clientId および clientSecret) を指定します。これらの属性は、アプリケーションの GitHub Developer Application Settings ページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=github -s providerId=github -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=GITHUB_CLIENT_ID -s config.clientSecret=GITHUB_CLIENT_SECRET

LinkedIn アイデンティティープロバイダーの設定

  1. linkedinproviderId として使用します。
  2. config 属性 (clientId および clientSecret) を指定します。これらの属性は、アプリケーションの LinkedIn Developer Console アプリケーションページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=linkedin -s providerId=linkedin -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=LINKEDIN_CLIENT_ID -s config.clientSecret=LINKEDIN_CLIENT_SECRET

Microsoft Live アイデンティティープロバイダーの設定

  1. microsoftproviderId として使用します。
  2. config 属性 clientId および clientSecret を指定します。これらの属性は、アプリケーションの Microsoft Application Registration Portal ページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=microsoft -s providerId=microsoft -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=MICROSOFT_APP_ID -s config.clientSecret=MICROSOFT_PASSWORD

Stack Overflow アイデンティティープロバイダーの設定

  1. stackoverflow コマンドを providerId として使用します。
  2. config 属性 (clientIdclientSecret、および key) を指定します。これらの属性は、アプリケーションの Stack Apps OAuth ページにあります。

    以下に例を示します。

    $ kcadm.sh create identity-provider/instances -r demorealm -s alias=stackoverflow -s providerId=stackoverflow -s enabled=true  -s 'config.useJwksUrl="true"' -s config.clientId=STACKAPPS_CLIENT_ID -s config.clientSecret=STACKAPPS_CLIENT_SECRET -s config.key=STACKAPPS_KEY

20.12. ストレージプロバイダー操作

Kerberos ストレージプロバイダーの設定

  1. components エンドポイントに対して create コマンドを使用します。
  2. レルム ID を parentId 属性の値として指定します。
  3. kerberosproviderId 属性値として指定し、org.keycloak.storage.UserStorageProviderproviderType 属性値として指定します。
  4. 以下に例を示します。

    $ kcadm.sh create components -r demorealm -s parentId=demorealmId -s id=demokerberos -s name=demokerberos -s providerId=kerberos -s providerType=org.keycloak.storage.UserStorageProvider -s 'config.priority=["0"]' -s 'config.debug=["false"]' -s 'config.allowPasswordAuthentication=["true"]' -s 'config.editMode=["UNSYNCED"]' -s 'config.updateProfileFirstLogin=["true"]' -s 'config.allowKerberosAuthentication=["true"]' -s 'config.kerberosRealm=["KEYCLOAK.ORG"]' -s 'config.keyTab=["http.keytab"]' -s 'config.serverPrincipal=["HTTP/localhost@KEYCLOAK.ORG"]' -s 'config.cachePolicy=["DEFAULT"]'

LDAP ユーザーストレージプロバイダーの設定

  1. components エンドポイントに対して create コマンドを使用します。
  2. ldapproviderId 属性の値に、org.keycloak.storage.UserStorageProviderproviderType 属性値として指定します。
  3. レルム ID を parentId 属性の値として指定します。
  4. 以下の例を使用して、Kerberos が統合する LDAP プロバイダーを作成します。

    $ kcadm.sh create components -r demorealm -s name=kerberos-ldap-provider -s providerId=ldap -s providerType=org.keycloak.storage.UserStorageProvider -s parentId=3d9c572b-8f33-483f-98a6-8bb421667867  -s 'config.priority=["1"]' -s 'config.fullSyncPeriod=["-1"]' -s 'config.changedSyncPeriod=["-1"]' -s 'config.cachePolicy=["DEFAULT"]' -s config.evictionDay=[] -s config.evictionHour=[] -s config.evictionMinute=[] -s config.maxLifespan=[] -s 'config.batchSizeForSync=["1000"]' -s 'config.editMode=["WRITABLE"]' -s 'config.syncRegistrations=["false"]' -s 'config.vendor=["other"]' -s 'config.usernameLDAPAttribute=["uid"]' -s 'config.rdnLDAPAttribute=["uid"]' -s 'config.uuidLDAPAttribute=["entryUUID"]' -s 'config.userObjectClasses=["inetOrgPerson, organizationalPerson"]' -s 'config.connectionUrl=["ldap://localhost:10389"]'  -s 'config.usersDn=["ou=People,dc=keycloak,dc=org"]' -s 'config.authType=["simple"]' -s 'config.bindDn=["uid=admin,ou=system"]' -s 'config.bindCredential=["secret"]' -s 'config.searchScope=["1"]' -s 'config.useTruststoreSpi=["ldapsOnly"]' -s 'config.connectionPooling=["true"]' -s 'config.pagination=["true"]' -s 'config.allowKerberosAuthentication=["true"]' -s 'config.serverPrincipal=["HTTP/localhost@KEYCLOAK.ORG"]' -s 'config.keyTab=["http.keytab"]' -s 'config.kerberosRealm=["KEYCLOAK.ORG"]' -s 'config.debug=["true"]' -s 'config.useKerberosForPasswordAuthentication=["true"]'

ユーザーストレージプロバイダーインスタンスの削除

  1. ストレージプロバイダーインスタンスの id 属性を使用して、components/ID などのエンドポイント URI を作成します。
  2. このエンドポイントに対して delete コマンドを実行します。

    以下に例を示します。

    $ kcadm.sh delete components/3d9c572b-8f33-483f-98a6-8bb421667867 -r demorealm

特定のユーザーストレージプロバイダーに対するすべてのユーザーの同期のトリガー

  1. ストレージプロバイダーの id 属性を使用して、user-storage/ID_OF_USER_STORAGE_INSTANCE/sync などのエンドポイント URI を作成します。
  2. action=triggerFullSync クエリーパラメーターを追加して create コマンドを実行します。

    以下に例を示します。

    $ kcadm.sh create user-storage/b7c63d02-b62a-4fc1-977c-947d6a09e1ea/sync?action=triggerFullSync

特定のユーザーストレージプロバイダーに対する変更済みのユーザーの同期のトリガー

  1. ストレージプロバイダーの id 属性を使用して、user-storage/ID_OF_USER_STORAGE_INSTANCE/sync などのエンドポイント URI を作成します。
  2. action=triggerChangedUsersSync クエリーパラメーターを追加し、create コマンドを実行します。

    以下に例を示します。

    $ kcadm.sh create user-storage/b7c63d02-b62a-4fc1-977c-947d6a09e1ea/sync?action=triggerChangedUsersSync

LDAP ユーザーのストレージ接続性のテスト

  1. testLDAPConnection エンドポイントで get コマンドを実行します。
  2. クエリーパラメーター bindCredentialbindDnconnectionUrl、および useTruststoreSpiを指定し、action クエリーパラメーターを testConnection に設定します。

    以下に例を示します。

    $ kcadm.sh create testLDAPConnection -s action=testConnection -s bindCredential=secret -s bindDn=uid=admin,ou=system -s connectionUrl=ldap://localhost:10389 -s useTruststoreSpi=ldapsOnly

LDAP ユーザーのストレージ認証のテスト

  1. testLDAPConnection エンドポイントで get コマンドを実行します。
  2. クエリーパラメーター bindCredentialbindDnconnectionUrl、および useTruststoreSpiを指定し、action クエリーパラメーターを testAuthentication に設定します。

    以下に例を示します。

    $ kcadm.sh create testLDAPConnection -s action=testAuthentication -s bindCredential=secret -s bindDn=uid=admin,ou=system -s connectionUrl=ldap://localhost:10389 -s useTruststoreSpi=ldapsOnly

20.13. マッパーの追加

ハードコーディングされたロールの LDAP マッパーの追加

  1. components エンドポイントで create コマンドを実行します。
  2. providerType 属性を org.keycloak.storage.ldap.mappers.LDAPStorageMapper に設定します。
  3. parentId 属性を LDAP プロバイダーインスタンスの ID に設定します。
  4. providerId 属性を hardcoded-ldap-role-mapper に設定します。role 設定パラメーターの値を指定するようにしてください。

    以下に例を示します。

    $ kcadm.sh create components -r demorealm -s name=hardcoded-ldap-role-mapper -s providerId=hardcoded-ldap-role-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config.role=["realm-management.create-client"]'

MS Active Directory マッパーの追加

  1. components エンドポイントで create コマンドを実行します。
  2. providerType 属性を org.keycloak.storage.ldap.mappers.LDAPStorageMapper に設定します。
  3. parentId 属性を LDAP プロバイダーインスタンスの ID に設定します。
  4. providerId 属性を msad-user-account-control-mapper に設定します。

    以下に例を示します。

    $ kcadm.sh create components -r demorealm -s name=msad-user-account-control-mapper -s providerId=msad-user-account-control-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea

ユーザー属性 LDAP マッパーの追加

  1. components エンドポイントで create コマンドを実行します。
  2. providerType 属性を org.keycloak.storage.ldap.mappers.LDAPStorageMapper に設定します。
  3. parentId 属性を LDAP プロバイダーインスタンスの ID に設定します。
  4. providerId 属性を user-attribute-ldap-mapper に設定します。

    以下に例を示します。

    $ kcadm.sh create components -r demorealm -s name=user-attribute-ldap-mapper -s providerId=user-attribute-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config."user.model.attribute"=["email"]' -s 'config."ldap.attribute"=["mail"]' -s 'config."read.only"=["false"]' -s 'config."always.read.value.from.ldap"=["false"]' -s 'config."is.mandatory.in.ldap"=["false"]'

グループの LDAP マッパーの追加

  1. components エンドポイントで create コマンドを実行します。
  2. providerType 属性を org.keycloak.storage.ldap.mappers.LDAPStorageMapper に設定します。
  3. parentId 属性を LDAP プロバイダーインスタンスの ID に設定します。
  4. providerId 属性を group-ldap-mapper に設定します。

    以下に例を示します。

    $ kcadm.sh create components -r demorealm -s name=group-ldap-mapper -s providerId=group-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config."groups.dn"=[]' -s 'config."group.name.ldap.attribute"=["cn"]' -s 'config."group.object.classes"=["groupOfNames"]' -s 'config."preserve.group.inheritance"=["true"]' -s 'config."membership.ldap.attribute"=["member"]' -s 'config."membership.attribute.type"=["DN"]' -s 'config."groups.ldap.filter"=[]' -s 'config.mode=["LDAP_ONLY"]' -s 'config."user.roles.retrieve.strategy"=["LOAD_GROUPS_BY_MEMBER_ATTRIBUTE"]' -s 'config."mapped.group.attributes"=["admins-group"]' -s 'config."drop.non.existing.groups.during.sync"=["false"]' -s 'config.roles=["admins"]' -s 'config.groups=["admins-group"]' -s 'config.group=[]' -s 'config.preserve=["true"]' -s 'config.membership=["member"]'

フルネームの LDAP マッパーの追加

  1. components エンドポイントで create コマンドを実行します。
  2. providerType 属性を org.keycloak.storage.ldap.mappers.LDAPStorageMapper に設定します。
  3. parentId 属性を LDAP プロバイダーインスタンスの ID に設定します。
  4. providerId 属性を full-name-ldap-mapper に設定します。

    以下に例を示します。

    $ kcadm.sh create components -r demorealm -s name=full-name-ldap-mapper -s providerId=full-name-ldap-mapper -s providerType=org.keycloak.storage.ldap.mappers.LDAPStorageMapper -s parentId=b7c63d02-b62a-4fc1-977c-947d6a09e1ea -s 'config."ldap.full.name.attribute"=["cn"]' -s 'config."read.only"=["false"]' -s 'config."write.only"=["true"]'

20.14. 認証操作

パスワードポリシーの設定

  1. レルムの passwordPolicy 属性を、特定のポリシープロバイダー ID と任意の設定が含まれる列挙式に設定します。
  2. 以下の例を使用して、パスワードポリシーをデフォルト値に設定します。デフォルト値には以下が含まれます。

    • 27,500 ハッシュの反復
    • 少なくとも 1 つの特殊文字
    • 少なくとも 1 つの大文字の文字
    • 最低でも 1 桁の文字
    • ユーザーの username と等しくない
    • 8 文字以上であること

      $ kcadm.sh update realms/demorealm -s 'passwordPolicy="hashIterations and specialChars and upperCase and digits and notUsername and length"'
  3. デフォルト値と異なる値を使用する場合は、括弧で設定を渡します。
  4. 以下の例を使用して、パスワードポリシーを以下のように設定します。

    • 25,000 ハッシュの反復
    • 少なくとも 2 つの特殊文字
    • 少なくとも 2 つの大文字
    • 少なくとも 2 つの小文字
    • 少なくとも 2 桁
    • 最低 9 文字の長さであること
    • ユーザーの username と等しくない
    • 少なくとも 4 つの変更の場合、繰り返すことはありません。

      $ kcadm.sh update realms/demorealm -s 'passwordPolicy="hashIterations(25000) and specialChars(2) and upperCase(2) and lowerCase(2) and digits(2) and length(9) and notUsername and passwordHistory(4)"'

現在のパスワードポリシーの取得

現在のレルム設定を取得し、passwordPolicy 属性以外のものをすべてフィルターします。

以下の例を使用して、demorealmpasswordPolicy を表示します。

$ kcadm.sh get realms/demorealm --fields passwordPolicy

認証フローの一覧表示

authentication/flows エンドポイントで get コマンドを実行します。

以下に例を示します。

$ kcadm.sh get authentication/flows -r demorealm

特定の認証フローの取得

authentication/flows/FLOW_ID エンドポイントで get コマンドを実行します。

以下に例を示します。

$ kcadm.sh get authentication/flows/febfd772-e1a1-42fb-b8ae-00c0566fafb8 -r demorealm

フローの実行の一覧表示

authentication/flows/FLOW_ALIAS/executions エンドポイントで get コマンドを実行します。

以下に例を示します。

$ kcadm.sh get authentication/flows/Copy%20of%20browser/executions -r demorealm

実行への設定の追加

  1. フローの実行を取得し、その ID を書き留めておきます。
  2. authentication/executions/{executionId}/config エンドポイントで create コマンドを実行します。

以下に例を示します。

$ kcadm create "authentication/executions/a3147129-c402-4760-86d9-3f2345e401c7/config" -r examplerealm -b '{"config":{"x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.crl-checking-enabled":"","x509-cert-auth.crldp-checking-enabled":false,"x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.ocsp-checking-enabled":"","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.keyusage":"","x509-cert-auth.extendedkeyusage":"","x509-cert-auth.confirmation-page-disallowed":""},"alias":"my_otp_config"}'

実行設定の取得

  1. フローの実行を取得し、設定 ID が含まれる authenticationConfig 属性を取得します。
  2. authentication/config/ID エンドポイントで get コマンドを実行します。

以下に例を示します。

$ kcadm get "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm

実行設定の更新

  1. フローの実行を取得し、設定 ID が含まれる authenticationConfig 属性を取得します。
  2. authentication/config/ID エンドポイントで update コマンドを実行します。

以下に例を示します。

$ kcadm update "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm -b '{"id":"dd91611a-d25c-421a-87e2-227c18421833","alias":"my_otp_config","config":{"x509-cert-auth.extendedkeyusage":"","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.crl-checking-enabled":"true","x509-cert-auth.confirmation-page-disallowed":"","x509-cert-auth.keyusage":"","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.crldp-checking-enabled":"false","x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.ocsp-checking-enabled":""}}'

実行設定の削除

  1. フローの実行を取得し、設定 ID が含まれる authenticationConfig 属性を取得します。
  2. authentication/config/ID エンドポイントで delete コマンドを実行します。

以下に例を示します。

$ kcadm delete "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm