第2章 OpenID Connect を使用したアプリケーションとサービスのセキュア化
本セクションでは、Red Hat Single Sign-On アダプターまたは汎用 OpenID Connect Relying Party ライブラリーを使用して、OpenID Connect でアプリケーションとサービスのセキュリティーを保護する方法を説明します。
2.1. Java アダプター リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On には、Java アプリケーションのさまざまなアダプターがあります。正しいアダプターの選択は、ターゲットプラットフォームによって異なります。
すべての Java アダプターは、Java アダプター設定 の章で説明されている共通の設定オプションセットを共有します。
2.1.1. Java アダプターの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On がサポートする各 Java アダプターは、単純な JSON ファイルで設定できます。これは次のようになります。
システムプロパティーの置き換えには ${…} エンクロージャーを使用できます。たとえば、${jboss.server.config.dir} は /path/to/Red Hat Single Sign-On に置き換えられます。環境変数の代替も、env 接頭辞 (例: ${env.MY_ENVIRONMENT_VARIABLE}) でサポートされます。
初期設定ファイルは管理コンソールから取得できます。これは、管理コンソールを開き、メニューから Clients を選択して、対応するクライアントをクリックします。クライアントのページが開いたら、インストール タブをクリックし、Keycloak OIDC JSON を選択します。
各設定オプションの説明は次のとおりです。
- realm
- レルムの名前これは 必須 です。
- resource
- アプリケーションの client-id各アプリケーションには、アプリケーションを識別するのに使用される client-id があります。これは 必須 です。
- realm-public-key
- レルム公開鍵の PEM 形式。これは管理コンソールから取得できます。これは 任意 ですが、設定することは推奨されません。設定しないと、アダプターは Red Hat Single Sign-On からダウンロードし、必要に応じて常に再ダウンロードを行います (例: Red Hat Single Sign-On はその鍵をローテーションします)。ただし、realm-public-key が設定されている場合、アダプターは Red Hat Single Sign-On から新しい鍵をダウンロードしません。そのため、Red Hat Single Sign-On が鍵をローテーションするとアダプターが中断されます。
- auth-server-url
-
Red Hat Single Sign-On サーバーのベース URL。他のすべての Red Hat シングルサインオンページおよび REST サービスエンドポイントはこれから派生します。通常、形式は
https://host:port/authです。これは 必須 です。 - ssl-required
-
Red Hat Single Sign-On サーバーとの間のすべての通信が HTTPS を介して行われるようにします。実稼働環境では、これを
allに設定する必要があります。これは 任意 です。デフォルト値は external です。つまり、外部要求に HTTPS がデフォルトで必要になります。有効な値は、all、external、および none です。 - confidential-port
- SSL/TLS を介してセキュアな接続のために、Red Hat Single Sign-On サーバーによって使用される機密ポート。これは 任意 です。デフォルト値は 8443 です。
- use-resource-role-mappings
- true に設定すると、アダプターはユーザーのアプリケーションレベルのロールマッピングのトークンを検索します。false の場合は、ユーザーロールマッピングのレルムレベルを確認します。これは 任意 です。デフォルト値は false です。
- public-client
- true に設定すると、アダプターはクライアントの認証情報を Red Hat Single Sign-On に送信しません。これは 任意 です。デフォルト値は false です。
- enable-cors
- これにより、CORS サポートが有効になります。CORS プリフライトリクエストを処理します。また、アクセストークンを調べて、有効な発信元を判別します。これは 任意 です。デフォルト値は false です。
- cors-max-age
-
CORS が有効な場合は、
Access-Control-Max-Ageヘッダーの値が設定されます。これは 任意 です。設定されていない場合、このヘッダーは CORS 応答で返されません。 - cors-allowed-methods
-
CORS が有効な場合は、
Access-Control-Allow-Methodsヘッダーの値が設定されます。これはコンマ区切りの文字列である必要があります。これは 任意 です。設定されていない場合、このヘッダーは CORS 応答で返されません。 - cors-allowed-headers
-
CORS が有効な場合は、
Access-Control-Allow-Headersヘッダーの値を設定します。これはコンマ区切りの文字列である必要があります。これは 任意 です。設定されていない場合、このヘッダーは CORS 応答で返されません。 - cors-exposed-headers
-
CORS が有効な場合は、
Access-Control-Expose-Headersヘッダーの値を設定します。これはコンマ区切りの文字列である必要があります。これは 任意 です。設定されていない場合、このヘッダーは CORS 応答で返されません。 - bearer-only
- これは、サービスに true に設定する必要があります。有効な場合、アダプターはユーザーの認証を試行しませんが、ベアラートークンのみを検証します。これは 任意 です。デフォルト値は false です。
- autodetect-bearer-only
-
アプリケーションが Web アプリケーションと Web サービス (例: SOAP または REST) の両方に対応する場合は、true に設定する必要があります。Web アプリケーションの認証されていないユーザーを Red Hat Single Sign-On ログインページにリダイレクトできますが、認証されていない SOAP または REST クライアントに HTTP
401ステータスコードを送信することができます。ログインページへのリダイレクトは理解できません。Red Hat Single Sign-On は、X-Requested-With、SOAPAction、またはAcceptなどの一般的なヘッダーに基づいて SOAP クライアントまたは REST クライアントを自動検出します。デフォルト値は false です。 - enable-basic-auth
- これは、Basic 認証もサポートするようにアダプターに指示します。このオプションが有効な場合には、シークレット も指定する必要があります。これは 任意 です。デフォルト値は false です。
- expose-token
-
trueの場合、(JavaScript HTTP 呼び出しを介して) 認証されたブラウザークライアントは、URLroot/k_query_bearer_tokenを使用して署名されたアクセストークンを取得できます。これは 任意 です。デフォルト値は false です。 - credentials
- アプリケーションの認証情報を指定します。これは、鍵が認証情報タイプであり、値が認証情報タイプの値であるオブジェクト表記です。現在、パスワードおよび jwt がサポートされています。これは、アクセスタイプが Confidential を持つクライアントにのみ 必須 になります。
- connection-pool-size
-
この設定オプションでは、Red Hat Single Sign-On サーバーへプールする接続の数を定義します。これは 任意 です。デフォルト値は
20です。 - socket-timeout-millis
-
接続の確立後にデータを待つソケットのタイムアウト (ミリ秒単位)。2 つのデータパケット間の最長の非アクティブ時間。タイムアウト値 0 は無限のタイムアウトとして解釈されます。負の値は未定義として解釈されます (該当する場合はシステムのデフォルト)。デフォルト値は
-1です。これは 任意 です。 - connection-timeout-millis
-
リモートホストとの接続を確立するためのタイムアウト (ミリ秒単位)。タイムアウト値 0 は無限のタイムアウトとして解釈されます。負の値は未定義として解釈されます (該当する場合はシステムのデフォルト)。デフォルト値は
-1です。これは 任意 です。 - connection-ttl-millis
-
クライアント向けの接続 Time to Live (TTL) (ミリ秒単位)。ゼロ以下の値は、無限の値として解釈されます。デフォルト値は
-1です。これは 任意 です。 - disable-trust-manager
-
Red Hat Single Sign-On サーバーに HTTPS が必要で、この設定オプションが
trueに設定されている場合は、トラストストアを指定する必要はありません。この設定は開発時のみ使用してください。これは SSL 証明書の検証を無効にするため、実稼働環境では 使用しないで ください。これは 任意 です。デフォルト値はfalseです。 - allow-any-hostname
-
Red Hat Single Sign-On サーバーに HTTPS が必要で、この設定オプションが
trueに設定されている場合、Red Hat Single Sign-On サーバーの証明書はトラストストア経由で検証されますが、ホスト名の検証は行われません。この設定は開発時のみ使用してください。これは SSL 証明書の検証を無効にするため、実稼働環境では 使用しないで ください。この設定は、テスト環境で役に立つ場合があります。これは 任意 です。デフォルト値はfalseです。 - proxy-url
- HTTP プロキシーが使用されている場合はその URL。
- truststore
-
値は、トラストストアファイルへのファイルパスです。
classpath:でパスを接頭辞にすると、代わりにデプロイメントのクラスパスからトラストストアが取得されます。Red Hat Single Sign-On サーバーへの送信 HTTPS 通信に使用されます。HTTPS 要求を実行するクライアントでは、通信先のサーバーのホストを確認する方法が必要です。これは、トラストストアが行なうことです。キーストアには、1 つ以上の信頼できるホスト証明書または認証局が含まれます。Red Hat Single Sign-On サーバーの SSL キーストアの公開証明書を抽出して、このトラストストアを作成できます。これは、ssl-requiredがnone、またはdisable-trust-managerがtrueでない限り、必須 になります。 - truststore-password
-
トラストストアのパスワード。これは、
トラストストアが設定され、トラストストアにパスワードが必要な場合は 必須 になります。 - client-keystore
- これはキーストアファイルに対するファイルパスです。このキーストアには、アダプターが Red Hat Single Sign-On サーバーに対して HTTPS を要求する際に双方向 SSL のクライアント証明書が含まれます。これは 任意 です。
- client-keystore-password
-
クライアントキーストアのパスワード。これは、
client-keystoreが設定されている場合は 必須 になります。 - client-key-password
-
クライアントのキーのパスワードこれは、
client-keystoreが設定されている場合は 必須 になります。 - always-refresh-token
- true の場合、アダプターはすべてのリクエストでトークンを更新します。警告: これを有効にすると、アプリケーションへのリクエストごとに Red Hat Single Sign-On へのリクエストが行われます。
- register-node-at-startup
- true の場合、アダプターは登録リクエストを Red Hat Single Sign-On に送信します。デフォルトは false で、アプリケーションがクラスター化されている場合にのみ便利です。詳細は、アプリケーションクラスタリング を参照してください。
- register-node-period
- Red Hat Single Sign-On に再登録アダプターを使用する期間。アプリケーションがクラスター化されている場合に役立ちます。詳細は、アプリケーションクラスタリング を参照してください。
- token-store
- 使用できる値は session および cookie です。デフォルトは session で、アダプターはアカウント情報を HTTP セッションに保存します。代替 cookie とは、cookie への情報の格納を意味します。詳細は、アプリケーションクラスタリング を参照してください。
- token-cookie-path
- cookie ストアを使用する場合、このオプションはアカウント情報を保存するために使用される cookie のパスを設定します。相対パスの場合は、アプリケーションがコンテキストルートで実行されていることを前提とし、そのコンテキストルートへの相対的として解釈されます。絶対パスの場合は、クッキーパスの設定に絶対パスが使用されます。デフォルトは、コンテキストルートへの相対パスを使用します。
- principal-attribute
-
UserPrincipal 名を入力する OpenID Connect ID Token 属性。トークン属性が null の場合、デフォルトは
subに設定されます。使用できる値はsub、preferred_username、email、name、nickname、given_name、family_nameです。 - turn-off-change-session-id-on-login
- 一部のプラットフォームでログインに成功すると、セキュリティー攻撃ベクトルをプラグインするために、セッション ID がデフォルトで変更されます。これをオフにする場合は、これを true に変更します。これは 任意 です。デフォルト値は false です。
- token-minimum-time-to-live
-
Red Hat Single Sign-On サーバーでアクティブなアクセストークンを事前更新してから失効する時間 (秒単位)。これは、アクセストークンが別の REST クライアントに送信され、評価前に期限切れになる可能性がある場合に特に便利です。この値は、レルムのアクセストークンの有効期間を超えてはいけないはずです。これは 任意 です。デフォルト値は
0秒であるため、アダプターは期限切れの場合にのみアクセストークンを更新します。 - min-time-between-jwks-requests
-
新しい公開鍵を取得するための Red Hat Single Sign-On への 2 つの要求間の最小間隔を指定する時間 (秒単位)。デフォルトは 10 秒です。アダプターは、不明な
kidでトークンを認識すると、常に新しい公開鍵をダウンロードしようとします。ただし、10 秒に 1 回以上試行することはありません (デフォルト)。これは、攻撃者が不正なkid強制アダプターを使用して多数のトークンを送信し、Red Hat Single Sign-On に多数のリクエストを送信するときに DoS を回避するためです。 - public-key-cache-ttl
-
新しい公開鍵を取得する Red Hat Single Sign-On への 2 つのリクエストの最大間隔を指定する時間 (秒単位)。デフォルトは 86400 秒 (1 日) です。アダプターは、不明な
kidでトークンを認識すると、常に新しい公開鍵をダウンロードしようとします。既知のkidでトークンを認識すると、以前ダウンロードした公開鍵のみを使用します。ただし、この設定した間隔 (デフォルトでは 1 日) につき少なくとも 1 回は新しい公開鍵がダウンロードされます。トークンのkidの規模が分かっている場合でも、常に新しい公開鍵がダウンロードされます。 - ignore-oauth-query-parameter
-
デフォルトは
falseです。trueに設定すると、ベアラートークン処理のaccess_tokenクエリーパラメーターの処理がオフになります。access_tokenを渡すだけでは、ユーザーを認証できません - redirect-rewrite-rules
-
必要な場合は、リダイレクト URI の書き換えルールを指定します。これは、キーが Redirect URI を照合する正規表現で、値は代替文字列になります。
$文字は、代替 String の後方参照に使用できます。 - verify-token-audience
-
trueに設定すると、ベアラートークンを使用した認証中に、アダプターはトークンにこのクライアント名 (リソース) がオーディエンスとして含まれているかどうかを確認します。このオプションは特に、主にベアラートークンで認証された要求を提供するサービスに有用です。これは、デフォルトではfalseに設定されますが、セキュリティーを強化する場合は、これを有効にすることが推奨されます。オーディエンスサポートの詳細は、Audience Support を参照してください。
2.1.2. JBoss EAP アダプター リンクのコピーリンクがクリップボードにコピーされました!
このアダプターは、ZIP ファイルまたは RPM からインストールできます。
2.1.3. ZIP ファイルからの JBOSS EAP アダプターのインストール リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP にデプロイされた WAR アプリケーションのセキュリティーを保護するには、Red Hat Single Sign-On アダプターサブシステムをインストールおよび設定する必要があります。次に、WAR のセキュリティーを保護する 2 つのオプションがあります。
- WAR でアダプター設定ファイルを指定し、auth-method を web.xml 内の KEYCLOAK に変更できます。
-
または、WAR を修正する必要がなく、
standalone.xmlなどの設定ファイルの Red Hat Single Sign-On アダプターサブシステム設定を介してセキュリティー保護できます。
本セクションでは、両方の方法を説明します。
アダプターは、使用しているサーバーのバージョンに応じて、別のアーカイブとして利用できます。
手順
Sotware Downloads サイトからアプリケーションサーバーに適用されるアダプターをインストールします。
JBoss EAP 7 にインストールします。
cd $EAP_HOME unzip rh-sso-7.6.11-eap7-adapter.zip
$ cd $EAP_HOME $ unzip rh-sso-7.6.11-eap7-adapter.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow この ZIP アーカイブには、Red Hat Single Sign-On アダプターに固有の JBoss モジュールが含まれています。また、アダプターサブシステムを設定するための JBoss CLI スクリプトも含まれています。
アダプターサブシステムを設定するには、適切なコマンドを実行します。
サーバーが実行されて いない場合に、JBoss EAP 7.1 以上へのインストール
./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli
$ ./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記JBoss EAP 6.4 ではオフラインスクリプトは利用できません。
サーバーを実行している場合に、JBoss EAP 7.1 以上へのインストール
./bin/jboss-cli.sh -c --file=bin/adapter-elytron-install.cli
$ ./bin/jboss-cli.sh -c --file=bin/adapter-elytron-install.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記JBoss EAP 7.1 以上で従来の非 Elytron アダプターを使用することもできます。つまり、
adapter-install-offline.cliを使用することができます。注記7.4.CP7 および 7.4.CP8 以降、EAP はそれぞれ OpenJDK 17 および Oracle JDK 17 をサポート しています。新しい Java バージョンでは elytron バリアントが必須になるため、JDK 17 でレガシーアダプターを使用しないでください。また、アダプターの CLI ファイルを実行した後、EAP が提供する
enable-elytron-se17.cliスクリプトを実行します。elytron アダプターを設定し、互換性のない EAP サブシステムを削除するには、両方のスクリプトが必要です。詳細は Security Configuration Changes の記事を参照してください。JBoss EAP 6.4 へのインストール
./bin/jboss-cli.sh -c --file=bin/adapter-install.cli
$ ./bin/jboss-cli.sh -c --file=bin/adapter-install.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.3.1. JBoss SSO リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP は、同じ JBoss EAP インスタンスにデプロイされた web アプリケーションに対するシングルサインオンのサポートが組み込まれています。これは、Red Hat Single Sign-On を使用する場合に有効にしないでください。
2.1.3.2. WAR のセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
本セクションでは、WAR パッケージ内の設定ファイルを追加および編集して、WAR を直接保護する方法を説明します。
手順
WAR の
WEB-INFディレクトリーにkeycloak.jsonアダプター設定ファイルを作成します。この設定ファイルの形式は、Java アダプター設定 セクションで説明されています。
-
web.xmlでauth-methodをKEYCLOAKに設定します。 標準のサーブレットセキュリティーを使用して URL に role-base 制約を指定します。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.3.3. Adapter サブシステムによる WAR のセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
WAR を変更して Red Hat Single Sign-On で保護する必要はありません。代わりに、Red Hat Single Sign-On Adapter サブシステム経由で外部からセキュリティー保護することができます。Keycloak を auth-method として指定する必要はありませんが、web.xml で security-constraints を定義する必要があります。ただし、WEB-INF/keycloak.json ファイルを作成する必要がありません。メタデータは、代わりに Red Hat Single Sign-On サブシステムのサーバー設定 (standalone.xml) で定義されます。
secure-deployment name 属性は、セキュリティーを保護する WAR を識別します。この値は web.xml に .war を追加した module-name です。残りの設定は、Java アダプター設定 で定義された keycloak.json 設定オプションとほぼ 1 対 1 で対応しています。
例外は credential 要素です。
これを容易にするために、Red Hat Single Sign-On 管理コンソールに移動し、この WAR が連携しているアプリケーションのクライアント/インストールタブに移動します。ここでは、カットアンドペーストできる XML ファイルの例を提供します。
同じレルムでセキュア化された複数のデプロイメントがある場合は、レルム設定を個別の要素で共有できます。以下に例を示します。
2.1.3.4. セキュリティードメイン リンクのコピーリンクがクリップボードにコピーされました!
セキュリティーコンテキストは EJB 階層に自動的に伝播されます。
2.1.4. RPM からの JBoss EAP 7 アダプターのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 7 では、チャンネル という用語はリポジトリーという用語に置き換えられました。これらの手順では、リポジトリーという用語のみが使用されています。
前提条件
RPM から JBoss EAP 7 アダプターをインストールする前に、JBoss EAP 7.4 リポジトリーにサブスクライブする必要があります。
- Red Hat Subscription Manager を使用して、Red Hat Enterprise Linux システムがお使いのアカウントに登録されている必要があります。詳細は、Red Hat Subscription Management のドキュメント を参照してください。
すでに別の JBoss EAP リポジトリーにサブスクライブしている場合は、最初にそのリポジトリーからサブスクライブを解除する必要があります。
Red Hat Enterprise Linux 6、7 の場合: Red Hat Subscription Manager を使用して、以下のコマンドで JBoss EAP 7.4 リポジトリーにサブスクライブします。お使いの Red Hat Enterprise Linux のバージョンに応じて、<RHEL_VERSION> を 6 または 7 に置き換えてください。
sudo subscription-manager repos --enable=jb-eap-7-for-rhel-<RHEL_VERSION>-server-rpms
$ sudo subscription-manager repos --enable=jb-eap-7-for-rhel-<RHEL_VERSION>-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Enterprise Linux 8 の場合: Red Hat Subscription Manager を使用して、以下のコマンドで JBoss EAP 7.4 リポジトリーにサブスクライブします。
sudo subscription-manager repos --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms
$ sudo subscription-manager repos --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
Red Hat Enterprise Linux のバージョンに応じて OIDC の JBoss EAP 7 アダプターをインストールします。
Red Hat Enterprise Linux 6、7 へのインストール
sudo yum install eap7-keycloak-adapter-sso7_6
$ sudo yum install eap7-keycloak-adapter-sso7_6Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Enterprise Linux 8 へのインストール
sudo dnf install eap7-keycloak-adapter-sso7_6
$ sudo dnf install eap7-keycloak-adapter-sso7_6Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RPM インストールのデフォルトの EAP_HOME パスは /opt/rh/eap7/root/usr/share/wildfly です。
OIDC モジュールのインストールスクリプトを実行します。
$EAP_HOME/bin/jboss-cli.sh -c --file=$EAP_HOME/bin/adapter-install.cli
$ $EAP_HOME/bin/jboss-cli.sh -c --file=$EAP_HOME/bin/adapter-install.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow
インストールが完了します。
2.1.5. RPM からの JBoss EAP 6 アダプターのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 7 では、チャンネル という用語はリポジトリーという用語に置き換えられました。これらの手順では、リポジトリーという用語のみが使用されています。
RPM から EAP 6 アダプターをインストールする前に、JBoss EAP 6 リポジトリーにサブスクライブする必要があります。
前提条件
- Red Hat Subscription Manager を使用して、Red Hat Enterprise Linux システムがお使いのアカウントに登録されている必要があります。詳細は、Red Hat Subscription Management のドキュメント を参照してください。
すでに別の JBoss EAP リポジトリーにサブスクライブしている場合は、最初にそのリポジトリーからサブスクライブを解除する必要があります。
Red Hat Subscription Manager を使用して、以下のコマンドを使用して JBoss EAP 6 リポジトリーにサブスクライブします。お使いの Red Hat Enterprise Linux のバージョンに応じて、<RHEL_VERSION> を 6 または 7 に置き換えてください。
sudo subscription-manager repos --enable=jb-eap-6-for-rhel-<RHEL_VERSION>-server-rpms
$ sudo subscription-manager repos --enable=jb-eap-6-for-rhel-<RHEL_VERSION>-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
以下のコマンドを使用して、OIDC の EAP 6 アダプターをインストールします。
sudo yum install keycloak-adapter-sso7_6-eap6
$ sudo yum install keycloak-adapter-sso7_6-eap6Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RPM インストールのデフォルトの EAP_HOME パスは /opt/rh/eap6/root/usr/share/wildfly です。
OIDC モジュールのインストールスクリプトを実行します。
$EAP_HOME/bin/jboss-cli.sh -c --file=$EAP_HOME/bin/adapter-install.cli
$ $EAP_HOME/bin/jboss-cli.sh -c --file=$EAP_HOME/bin/adapter-install.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow
インストールが完了します。
2.1.6. JBoss Fuse 6 アダプター リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On は、JBoss Fuse 6 内で実行される Web アプリケーションのセキュリティー保護をサポートします。
Fuse 6 のサポートされるバージョンは最新リリースのみです。以前のバージョンの Fuse 6 を使用する場合は、一部の関数が正常に機能しない可能性があります。特に、Hawtio 統合は Fuse 6 の以前のバージョンでは機能しません。
以下の項目のセキュリティーは Fuse でサポートされます。
- Pax Web War Extender を使用して Fuse にデプロイされた Classic WAR アプリケーション
- Pax Web Whiteboard Extender で OSGI として Fuse にデプロイされたサーブレット
- Camel Jetty コンポーネントで実行している Apache Camel エンドポイント
- 独自の個別 Jetty エンジン で実行される Apache CXF エンドポイント
- CXF サーブレットによって提供されるデフォルトのエンジンで実行される Apache CXF エンドポイント
- SSH および JMX 管理者アクセス
- Hawtio 管理コンソール
2.1.6.1. Fuse 6 での Web アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
最初に Red Hat Single Sign-On Karaf 機能をインストールする必要があります。次に、セキュリティー保護するアプリケーションのタイプに応じて手順を実行する必要があります。参照されるすべての Web アプリケーションには、Red Hat Single Sign-On Jetty オーセンティケーターを基盤の Jetty サーバーに挿入する必要があります。これを行う手順は、アプリケーションの種別によって異なります。詳細は、以下を参照してください。
2.1.6.2. Keycloak 機能のインストール リンクのコピーリンクがクリップボードにコピーされました!
最初に JBoss Fuse 環境に keycloak 機能をインストールする必要があります。keycloak 機能には、Fuse アダプターとサードパーティーのすべての依存関係が含まれます。Maven リポジトリーまたはアーカイブからインストールできます。
2.1.6.2.1. Maven リポジトリーからのインストール リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- オンラインであり、Maven リポジトリーにアクセスできる必要がある。
Red Hat Single Sign-On の場合には、アーティファクトをインストールできるように適切な Maven リポジトリーを設定しておく。詳細は、JBoss Enterprise Maven リポジトリーページ を参照してください。
Maven リポジトリーが https://maven.repository.redhat.com/ga/ であるとします。
$FUSE_HOME/etc/org.ops4j.pax.url.mvn.cfgファイルに以下を追加し、サポートされているリポジトリーのリストにリポジトリーを追加します。以下に例を示します。org.ops4j.pax.url.mvn.repositories= \ https://maven.repository.redhat.com/ga/@id=redhat.product.repo http://repo1.maven.org/maven2@id=maven.central.repo, \ ...org.ops4j.pax.url.mvn.repositories= \ https://maven.repository.redhat.com/ga/@id=redhat.product.repo http://repo1.maven.org/maven2@id=maven.central.repo, \ ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
- JBoss Fuse 6.3.0 Rollup 12 を起動します。
Karaf ターミナルで次のように入力します。
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow また、Jetty 9 機能をインストールする必要がある場合があります。
features:install keycloak-jetty9-adapter
features:install keycloak-jetty9-adapterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 機能がインストールされていることを確認します。
features:list | grep keycloak
features:list | grep keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.6.2.2. ZIP バンドルからのインストール リンクのコピーリンクがクリップボードにコピーされました!
このインストールオプションは、オフラインの場合、または Maven を使用して JAR ファイルやその他のアーティファクトを取得しない場合に便利です。
手順
- Red Hat Single Sign-On Fuse アダプターの ZIP アーカイブを ソフトウェアダウンロード サイトからダウンロードします。
これを JBoss Fuse のルートディレクトリーにデプロイメントします。次に、依存関係が
systemディレクトリーにインストールされます。既存の jar ファイルをすべて上書きできます。JBoss Fuse 6.3.0 Rollup 12 にこれを使用します。
cd /path-to-fuse/jboss-fuse-6.3.0.redhat-254 unzip -q /path-to-adapter-zip/rh-sso-7.6.11-fuse-adapter.zip
cd /path-to-fuse/jboss-fuse-6.3.0.redhat-254 unzip -q /path-to-adapter-zip/rh-sso-7.6.11-fuse-adapter.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Fuse を起動し、fuse/karaf ターミナルでこれらのコマンドを実行します。
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
対応する Jetty アダプターをインストールします。アーティファクトは JBoss Fuse
systemディレクトリーで直接利用できるため、Maven リポジトリーを使用する必要はありません。
2.1.6.3. クラシック WAR アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
手順
/WEB-INF/web.xmlファイルで、必要を宣言します。- <security-constraint> 要素のセキュリティー制約
- <login-config> 要素のログイン設定
<security-role> 要素のセキュリティーロール
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
/WEB-INF/jetty-web.xmlファイルにオーセンティケーターのあるjetty-web.xmlファイルを追加します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
WAR の
/WEB-INF/ディレクトリー内で、新しいファイル keycloak.json を作成します。この設定ファイルの形式は、Java アダプター設定 のセクションで説明されています。外部アダプターの設定 で説明されているように、このファイルを外部から利用できるようにすることもできます。 WAR アプリケーションが
org.keycloak.adapters.jettyをインポートし、さらにImport-PackageヘッダーでMETA-INF/MANIFEST.MFファイルに含まれるパッケージをインポートするようにしてください。プロジェクトにmaven-bundle-pluginを使用すると、OSGI ヘッダーがマニフェストに適切に生成されます。パッケージの*解決は、アプリケーションや Blueprint または Spring 記述子で使用されていないため、org.keycloak.adapters.jettyパッケージはインポートしませんが、jetty-web.xmlファイルで使用されます。インポートするパッケージのリストは、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.6.3.1. 外部アダプターの設定 リンクのコピーリンクがクリップボードにコピーされました!
keycloak.json アダプター設定ファイルを WAR アプリケーション内にバンドルせず、命名規則に基づいて外部に利用可能にし、読み込む場合は、この設定方法を使用します。
この機能を有効にするには、このセクションを /WEB_INF/web.xml ファイルに追加します。
<context-param>
<param-name>keycloak.config.resolver</param-name>
<param-value>org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver</param-value>
</context-param>
<context-param>
<param-name>keycloak.config.resolver</param-name>
<param-value>org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver</param-value>
</context-param>
そのコンポーネントは、java プロパティー keycloak.config または karaf.etc を使用してベースフォルダーを検索し、設定を見つけます。次に、フォルダーのいずれかで <your_web_context>-keycloak.json という名前のファイルを検索します。
たとえば、Web アプリケーションにコンテキスト my-portal がある場合、アダプター設定は $FUSE_HOME/etc/my-portal-keycloak.json ファイルから読み込まれます。
2.1.6.4. OSGI サービスとしてデプロイされたサーブレットのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
従来の WAR アプリケーションとしてデプロイされていない OSGI バンドルプロジェクトにサーブレットクラスがある場合は、このメソッドを使用できます。Fuse は Pax Web Whiteboard Extender を使用して、このようなサーブレットを Web アプリケーションとしてデプロイします。
手順
Red Hat Single Sign-On には
org.keycloak.adapters.osgi.undertow.PaxWebIntegrationServiceが同梱されており、jetty-web.xml を注入してアプリケーションのセキュリティー制約を設定できます。このようなサービスをアプリケーション内のOSGI-INF/blueprint/blueprint.xmlファイルで宣言する必要があります。サーブレットはそれに依存する必要があることに注意してください。設定例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
(プロジェクトが Web アプリケーションではない場合でも) プロジェクト内に
WEB-INFディレクトリーがあり、Classic WAR application セクションに、/WEB-INF/jetty-web.xmlファイルおよび/WEB-INF/keycloak.jsonファイルを作成します。security-constraints が Blueprint 設定ファイルで宣言されているため、web.xmlファイルは必要ありません。
-
(プロジェクトが Web アプリケーションではない場合でも) プロジェクト内に
META-INF/MANIFEST.MFのImport-Packageには、少なくとも以下のインポートが含まれている必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.6.5. Apache Camel アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
camel-jetty コンポーネントで実装された Apache Camel エンドポイントのセキュリティーを保護するには、KeycloakJettyAuthenticator で securityHandler を追加し、適切なセキュリティー制約を挿入します。OSGI-INF/blueprint/blueprint.xml ファイルを以下のような設定を持つ Camel アプリケーションに追加できます。ロール、セキュリティー制約のマッピング、および Red Hat Single Sign-On アダプター設定は、お使いの環境とニーズに合わせて若干異なる可能性があります。
以下に例を示します。
-
META-INF/MANIFEST.MFのImport-Packageには以下のインポートが含まれる必要があります。
2.1.6.6. Camel RestDSL リンクのコピーリンクがクリップボードにコピーされました!
Camel RestDSL は、REST エンドポイントを定義するのに使用される Camel 機能です。しかし、引き続き特定の実装クラスを使用し、Red Hat Single Sign-On との統合方法を説明します。
インテグレーションメカニズムを設定する方法は、RestDSL 定義のルートを設定する Camel コンポーネントに依存します。
以下の例は、Jetty コンポーネントを使用して統合を設定する方法を示しています。これには、上述の Blueprint の例で定義された一部の Bean への参照が含まれます。
2.1.6.7. 別の Jetty Engine での Apache CXF エンドポイントのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
手順
Red Hat Single Sign-On によって保護された CXF エンドポイントを別の Jetty エンジンで実行するには、以下の手順を実行します。
META-INF/spring/beans.xmlをアプリケーションに追加し、そのアプリケーションで、httpj:engine-factoryが注入された Jetty SecurityHandler でKeycloakJettyAuthenticatorを宣言します。CFX JAX-WS アプリケーションの設定は以下のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow CXF JAX-RS アプリケーションの場合、唯一の違いは、エンジンファクトリーに依存するエンドポイントの設定にある可能性があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
META-INF/MANIFEST.MFのImport-Packageには、これらのインポートが含まれる必要があります。
2.1.6.8. デフォルトの Jetty Engine での Apache CXF エンドポイントのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
一部のサービスは、起動時にデプロイされたサーブレットが自動的に含まれる場合があります。このようなサービスの 1 つは、http://localhost:8181/cxf コンテキストで実行している CXF サーブレットです。このようなエンドポイントの保護は複雑になる可能性があります。現在 Red Hat Single Sign-On が使用している 1 つの方法は ServletReregistrationService で、起動時に組み込みサーブレットをアンデプロイし、Red Hat Single Sign-On がセキュア化されたコンテキストに再デプロイできるようにします。
アプリケーション内の設定ファイル OSGI-INF/blueprint/blueprint.xml は、以下のようになります。アプリケーションにエンドポイント固有の JAX-RS customerservice エンドポイントを追加しますが、/cxf コンテキスト全体を保護することに注意してください。
そのため、デフォルトの CXF HTTP 宛先で実行している他のすべての CXF サービスもセキュア化されます。同様に、アプリケーションがアンデプロイされると、/cxf コンテキスト全体のセキュリティーも保護されなくなります。このため、別の Jetty Engine で CXF アプリケーションのセキュリティーを保護 で説明されているように、各アプリケーションに独自の Jetty エンジンを使用すると、各アプリケーションのセキュリティーをより詳細に制御できます。
-
WEB-INFディレクトリーは、(プロジェクトが web アプリケーションではない場合でも) プロジェクト内に置く必要がある場合があります。また、Classic WAR アプリケーション と同様の方法で/WEB-INF/jetty-web.xmlファイルおよび/WEB-INF/keycloak.jsonファイルを編集する必要もあります。セキュリティー制約がブループリント設定ファイルで宣言されているため、web.xmlファイルは必要ありません。 -
META-INF/MANIFEST.MFのImport-Packageには以下のインポートが含まれる必要があります。
2.1.6.9. Fuse 管理サービスのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
2.1.6.9.1. Fuse ターミナルへの SSH 認証の使用 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On は、主に Web アプリケーションの認証のユースケースに対応しています。ただし、他の Web サービスおよびアプリケーションが Red Hat Single Sign-On で保護されている場合は、SSH などの非 Web 管理サービスを Red Hat Single Sign-On の認証情報で保護するのが最善の方法です。これは、Red Hat Single Sign-On へのリモート接続を可能にする JAAS ログインモジュールを使用して実行できます。また、リソース所有者のパスワード認証情報 に基づいて認証情報を検証できます。
SSH 認証を有効にするには、次の手順を実行します。
手順
-
Red Hat Single Sign-On では、SSH 認証に使用されるクライアント (
ssh-jmx-admin-clientなど) を作成します。このクライアントでは、Direct Access Grants EnabledをOnに選択する必要があります。 $FUSE_HOME/etc/org.apache.karaf.shell.cfgファイルで、以下のプロパティーを更新または指定します。sshRealm=keycloak
sshRealm=keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような内容で
$FUSE_HOME/etc/keycloak-direct-access.jsonファイルを追加します (環境と Red Hat Single Sign-On クライアント設定に基づきます)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルは、SSH 認証の JAAS レルム
keycloakから JAAS DirectAccessGrantsLoginModule によって使用されるクライアントアプリケーション設定を指定します。Fuse を起動し、
keycloakJAAS レルムをインストールします。最も簡単な方法は、JAAS レルムが事前定義されているkeycloak-jaas機能をインストールすることです。より高いランクの独自の JAAS レルムkeycloakを使用すると、機能の定義済みレルムをオーバーライドできます。詳細は、JBoss Fuse ドキュメント を参照してください。Fuse 端末で以下のコマンドを使用します。
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak-jaas
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak-jaasCopy to Clipboard Copied! Toggle word wrap Toggle overflow 端末に以下を入力して、
adminユーザーとして SSH を使用してログインします。ssh -o PubkeyAuthentication=no -p 8101 admin@localhost
ssh -o PubkeyAuthentication=no -p 8101 admin@localhostCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
パスワード
passwordでログインします。
一部のオペレーティングシステムでは、SSH コマンドの -o オプション -o オプション -o HostKeyAlgorithms=+ssh-dss を使用する必要もあります。これは、後の SSH クライアントはデフォルトで ssh-dss アルゴリズムを使用できないためです。しかし、JBoss Fuse 6.3.0 Rollup 12 で現在使用されています。
ユーザーには、すべての操作を実行するためのレルムロール admin、または操作のサブセットを実行するための別のロール (たとえば、読み取り専用の Karaf コマンドのみを実行するようにユーザーを制限する viewer ロール) が必要であることに注意してください。利用可能なロールは $FUSE_HOME/etc/org.apache.karaf.shell.cfg または $FUSE_HOME/etc/system.properties で設定されます。
2.1.6.9.2. JMX 認証の使用 リンクのコピーリンクがクリップボードにコピーされました!
jconsole または他の外部ツールを使用して RMI 経由で JMX にリモートで接続する場合は、JMX 認証が必要な場合があります。jolokia エージェントはデフォルトで hawt.io にインストールされているため、hawt.io/jolokia を使用する方が良いでしょう。詳細は Hawtio 管理コンソール を参照してください。
手順
$FUSE_HOME/etc/org.apache.karaf.management.cfgファイルで、jmxRealm プロパティーを以下のように変更します。jmxRealm=keycloak
jmxRealm=keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
上記の SSH セクションで説明されているように、
keycloak-jaas機能をインストールして$FUSE_HOME/etc/keycloak-direct-access.jsonファイルを設定します。 - jconsole では、以下のような URL を使用できます。
service:jmx:rmi://localhost:44444/jndi/rmi://localhost:1099/karaf-root
service:jmx:rmi://localhost:44444/jndi/rmi://localhost:1099/karaf-root
および認証情報: admin/password (環境に応じて管理者権限を持つユーザーに基づきます)。
2.1.6.10. Hawtio 管理コンソールのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On で Hawtio 管理コンソールのセキュリティーを保護するには、次の手順を実行します。
手順
これらのプロパティーを
$FUSE_HOME/etc/system.propertiesファイルに追加します。hawtio.keycloakEnabled=true hawtio.realm=keycloak hawtio.keycloakClientConfig=file://${karaf.base}/etc/keycloak-hawtio-client.json hawtio.rolePrincipalClasses=org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipalhawtio.keycloakEnabled=true hawtio.realm=keycloak hawtio.keycloakClientConfig=file://${karaf.base}/etc/keycloak-hawtio-client.json hawtio.rolePrincipalClasses=org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipalCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
レルムの Red Hat Single Sign-On 管理コンソールでクライアントを作成します。たとえば、Red Hat Single Sign-On の
demoレルムでは、クライアントhawtio-clientを作成し、アクセスタイプとしてpublicを指定し、Hawtio を参照するリダイレクト URI (http://localhost:8181/hawtio/*) を指定します。対応する Web Origin も設定する必要があります (この場合は http://localhost:8181)。 -
以下の例のような内容を使用して、
$FUSE_HOME/etcディレクトリーにkeycloak-hawtio-client.jsonファイルを作成します。Red Hat Single Sign-On 環境に応じて、realm、resource、およびauth-server-urlプロパティーを変更します。resourceプロパティーは、前のステップで作成したクライアントを参照する必要があります。このファイルは、クライアント (Hawtio JavaScript アプリケーション) で使用されます。
以下の例のような内容を使用して、
$FUSE_HOME/etcディレクトリーにkeycloak-hawtio.jsonファイルを作成します。Red Hat Single Sign-On 環境に応じて、realmプロパティーおよびauth-server-urlプロパティーを変更します。このファイルは、サーバーのアダプター (JAAS ログインモジュール) 側で使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow JBoss Fuse 6.3.0 Rollup 12 を起動し、keycloak 機能がインストールされていない場合はインストールします。Karaf ターミナルのコマンドの例を以下に示します。
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow http://localhost:8181/hawtio にアクセスし、Red Hat Single Sign-On レルムからユーザーとしてログインします。
Hawtio に対して正常に認証するには、適切なレルムロールが必要です。利用可能なロールは、
hawtio.rolesの$FUSE_HOME/etc/system.propertiesファイルで設定されます。
2.1.6.10.1. JBoss EAP 6.4 での Hawtio のセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Hawtio 管理コンソールのセキュリティー保護 の説明に従って、Red Hat Single Sign-On を設定します。以下が前提となります。
-
Red Hat Single Sign-On レルムの
demoおよびクライアントhawtio-clientがある。 -
Red Hat Single Sign-On が
localhost:8080で実行されている。 -
デプロイされた Hawtio を持つ JBoss EAP 6.4 サーバーは
localhost:8181で実行されます。このサーバーのディレクトリーは、次のステップで$EAP_HOMEと呼ばれます。
手順
-
hawtio-wildfly-1.4.0.redhat-630396.warアーカイブを$EAP_HOME/standalone/configurationディレクトリーにコピーします。Hawtio のデプロイメントに関する詳細は、Fuse Hawtio のドキュメント を参照してください。 -
上記の内容の
keycloak-hawtio.jsonおよびkeycloak-hawtio-client.jsonファイルを$EAP_HOME/standalone/configurationディレクトリーにコピーします。 - JBoss アダプターのドキュメント で説明されているように、Red Hat Single Sign-On アダプターサブシステムを JBoss EAP 6.4 サーバーにインストールします。
$EAP_HOME/standalone/configuration/standalone.xmlファイルで、以下の例のようにシステムプロパティーを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Hawtio レルムを
security-domainsセクションの同じファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Secure-deploymentセクションhawtioをアダプターサブシステムに追加します。これにより、Hawtio WAR が JAAS ログインモジュールクラスを検索できるようになります。<subsystem xmlns="urn:jboss:domain:keycloak:1.1"> <secure-deployment name="hawtio-wildfly-1.4.0.redhat-630396.war" /> </subsystem><subsystem xmlns="urn:jboss:domain:keycloak:1.1"> <secure-deployment name="hawtio-wildfly-1.4.0.redhat-630396.war" /> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Hawtio を使用して JBoss EAP 6.4 サーバーを再起動します。
cd $EAP_HOME/bin ./standalone.sh -Djboss.socket.binding.port-offset=101
cd $EAP_HOME/bin ./standalone.sh -Djboss.socket.binding.port-offset=101Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Hawtio (http://localhost:8181/hawtio) にアクセスします。Red Hat Single Sign-On でセキュリティーが保護されています。
2.1.7. JBoss Fuse 7 Adapter リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On は、JBoss Fuse 7 内で実行している Web アプリケーションのセキュリティー保護をサポートします。
JBoss Fuse 7.4.0 は Undertow HTTP エンジンに組み込まれており、Undertow はさまざまな種類の Web アプリケーションの実行に使用されるため、JBoss Fuse 7 は基本的に JBoss EAP 7 アダプター と同じ Undertow アダプターを使用します。
唯一サポートされるのは Fuse 7 の最新バージョンです。以前のバージョンの Fuse 7 を使用する場合は、一部の関数が正常に機能しない可能性があります。特に、統合は 7.0.1 未満の Fuse 7 バージョンですべてのバージョンで機能しません。
以下の項目のセキュリティーは Fuse でサポートされます。
- Pax Web War Extender を使用して Fuse にデプロイされた Classic WAR アプリケーション
- Pax Web Whiteboard Extender で Fuse に OSGI サービスとしてデプロイされたサーブレットと、標準の OSGi Enterprise HTTP Service である org.osgi.service.http.HttpService#registerServlet() 経由で登録された追加サーブレット
- Camel Undertow コンポーネントで実行している Apache Camel Undertow エンドポイント
- 独自の個別の Undertow エンジンで実行される Apache CXF エンドポイント
- CXF サーブレットによって提供されるデフォルトのエンジンで実行される Apache CXF エンドポイント
- SSH および JMX 管理者アクセス
- Hawtio 管理コンソール
2.1.7.1. Fuse 7 での Web アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
最初に Red Hat Single Sign-On Karaf 機能をインストールする必要があります。次に、セキュリティー保護するアプリケーションのタイプに応じて手順を実行する必要があります。参照されるすべての Web アプリケーションには、Red Hat Single Sign-On の Undertow 認証メカニズムを基盤の Web サーバーに挿入する必要があります。これを行う手順は、アプリケーションの種別によって異なります。詳細は、以下を参照してください。
2.1.7.2. Keycloak 機能のインストール リンクのコピーリンクがクリップボードにコピーされました!
最初に、JBoss Fuse 環境に keycloak-pax-http-undertow 機能および keycloak-jaas 機能をインストールする必要があります。keycloak-pax-http-undertow 機能には、Fuse アダプターとサードパーティーのすべての依存関係が含まれます。keycloak-jaas には、SSH および JMX 認証にレルムで使用される JAAS モジュールが含まれます。Maven リポジトリーまたはアーカイブからインストールできます。
2.1.7.2.1. Maven リポジトリーからのインストール リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- オンラインであり、Maven リポジトリーにアクセスできる必要がある。
- Red Hat Single Sign-On の場合には、アーティファクトをインストールできるように適切な Maven リポジトリーを設定しておく。詳細は、JBoss Enterprise Maven リポジトリーページ を参照してください。
Maven リポジトリーが https://maven.repository.redhat.com/ga/ であるとします。
$FUSE_HOME/etc/org.ops4j.pax.url.mvn.cfgファイルに以下を追加し、サポートされているリポジトリーのリストにリポジトリーを追加します。以下に例を示します。config:edit org.ops4j.pax.url.mvn config:property-append org.ops4j.pax.url.mvn.repositories ,https://maven.repository.redhat.com/ga/@id=redhat.product.repo config:update feature:repo-refresh
config:edit org.ops4j.pax.url.mvn config:property-append org.ops4j.pax.url.mvn.repositories ,https://maven.repository.redhat.com/ga/@id=redhat.product.repo config:update feature:repo-refreshCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
- JBoss Fuse 7.4.0 を起動します。
Karaf ターミナルで、次のように入力します。
feature:repo-add mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features feature:install keycloak-pax-http-undertow keycloak-jaas
feature:repo-add mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features feature:install keycloak-pax-http-undertow keycloak-jaasCopy to Clipboard Copied! Toggle word wrap Toggle overflow Undertow 機能のインストールが必要になる場合があります。
feature:install pax-web-http-undertow
feature:install pax-web-http-undertowCopy to Clipboard Copied! Toggle word wrap Toggle overflow 機能がインストールされていることを確認します。
feature:list | grep keycloak
feature:list | grep keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.7.2.2. ZIP バンドルからのインストール リンクのコピーリンクがクリップボードにコピーされました!
これは、オフラインの場合、または Maven を使用して JAR ファイルやその他のアーティファクトを取得したくない場合に便利です。
手順
- Red Hat Single Sign-On Fuse アダプターの ZIP アーカイブを ソフトウェアダウンロード サイトからダウンロードします。
これを JBoss Fuse のルートディレクトリーにデプロイメントします。次に、依存関係が
systemディレクトリーにインストールされます。既存の jar ファイルをすべて上書きできます。これは JBoss Fuse 7.4.0 に使用します。
cd /path-to-fuse/fuse-karaf-7.z unzip -q /path-to-adapter-zip/rh-sso-7.6.11-fuse-adapter.zip
cd /path-to-fuse/fuse-karaf-7.z unzip -q /path-to-adapter-zip/rh-sso-7.6.11-fuse-adapter.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Fuse を起動し、fuse/karaf ターミナルでこれらのコマンドを実行します。
feature:repo-add mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features feature:install keycloak-pax-http-undertow keycloak-jaas
feature:repo-add mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features feature:install keycloak-pax-http-undertow keycloak-jaasCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
対応する Undertow アダプターをインストールします。アーティファクトは JBoss Fuse
systemディレクトリーで直接利用できるため、Maven リポジトリーを使用する必要はありません。
2.1.7.3. クラシック WAR アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
手順
/WEB-INF/web.xmlファイルで、必要を宣言します。- <security-constraint> 要素のセキュリティー制約
-
<login-config> 要素のログイン設定。
<auth-method>がKEYCLOAKであることを確認します。 <security-role> 要素のセキュリティーロール
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
WAR の
/WEB-INF/ディレクトリー内で、新しいファイル keycloak.json を作成します。この設定ファイルの形式は、Java アダプター設定 のセクションで説明されています。外部アダプターの設定 で説明されているように、このファイルを外部から利用できるようにすることもできます。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Fuse 6 アダプターとは異なり、MANIFEST.MF には特別な OSGi インポートは必要ありません。
2.1.7.3.1. 設定リゾルバー リンクのコピーリンクがクリップボードにコピーされました!
keycloak.json アダプター設定ファイルは、バンドル内に保存する (デフォルトの動作) が、ファイルシステムのディレクトリーに保存することができます。設定ファイルの実際のソースを指定するには、keycloak.config.resolver デプロイメントパラメーターを希望の設定リゾルバークラスに設定します。たとえば、従来の WAR アプリケーションで、以下のように web.xml ファイルに keycloak.config.resolver コンテキストパラメーターを設定します。
<context-param>
<param-name>keycloak.config.resolver</param-name>
<param-value>org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver</param-value>
</context-param>
<context-param>
<param-name>keycloak.config.resolver</param-name>
<param-value>org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver</param-value>
</context-param>
以下のリゾルバーは keycloak.config.resolver で利用できます。
- org.keycloak.adapters.osgi.BundleBasedKeycloakConfigResolver
-
これはデフォルトのリゾルバーです。設定ファイルは、セキュリティーが保護されている OSGi バンドル内に想定されるものです。デフォルトでは、
WEB-INF/keycloak.jsonという名前のファイルを読み込みますが、このファイル名はconfigLocationプロパティーで設定できます。 - org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver
このリゾルバーは、
keycloak.configシステムプロパティーで指定されるディレクトリー内の<your_web_context>-keycloak.jsonという名前のファイルを検索します。keycloak.configが設定されていない場合は、代わりにkaraf.etcシステムプロパティーが使用されます。たとえば、Web アプリケーションがコンテキスト
my-portalにデプロイされている場合、アダプター設定は、${keycloak.config}/my-portal-keycloak.jsonファイルまたは${karaf.etc}/my-portal-keycloak.jsonファイルから読み込まれます。- org.keycloak.adapters.osgi.HierarchicalPathBasedKeycloakConfigResolver
このリゾルバーは、上記の
PathBasedKeycloakConfigResolverと似ています。指定された URI パスについて、設定場所が最も具体的なものから順にチェックされます。たとえば、
/my/web-app/contextURI の場合は、最初の値が見つかるまで、以下の設定場所が検索されます。-
${karaf.etc}/my-web-app-context-keycloak.json -
${karaf.etc}/my-web-app-keycloak.json -
${karaf.etc}/my-keycloak.json -
${karaf.etc}/keycloak.json
-
2.1.7.4. OSGI サービスとしてデプロイされたサーブレットのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
従来の WAR アプリケーションとしてデプロイされていない OSGI バンドルプロジェクトにサーブレットクラスがある場合は、このメソッドを使用できます。Fuse は Pax Web Whiteboard Extender を使用して、このようなサーブレットを Web アプリケーションとしてデプロイします。
手順
Red Hat Single Sign-On は、
org.keycloak.adapters.osgi.undertow.PaxWebIntegrationServiceを提供します。これにより、アプリケーションの認証方法とセキュリティー制約を設定できます。このようなサービスをアプリケーション内のOSGI-INF/blueprint/blueprint.xmlファイルで宣言する必要があります。サーブレットはそれに依存する必要があることに注意してください。設定例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow (プロジェクトが Web アプリケーションではない場合でも) プロジェクト内に
WEB-INFディレクトリーがあり、Classic WAR application で説明されているように、/WEB-INF/keycloak.jsonファイルを作成します。security-constraints が Blueprint 設定ファイルで宣言されているため、web.xmlファイルは必要ありません。- Fuse 6 アダプターとは異なり、MANIFEST.MF には特別な OSGi インポートは必要ありません。
2.1.7.5. Apache Camel アプリケーションのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
Blueprint で適切なセキュリティー制約を注入し、使用されているコンポーネントを undertow-keycloak に更新することで、camel-undertow コンポーネントで実装された Apache Camel エンドポイントのセキュリティーを保護できます。OSGI-INF/blueprint/blueprint.xml ファイルを、以下のような設定を持つ Camel アプリケーションに追加する必要があります。ロール、セキュリティー制約のマッピング、およびアダプター設定は、お使いの環境とニーズに合わせて若干異なる可能性があります。
undertow-keycloak コンポーネントは、標準の undertow コンポーネントと比較すると、2 つの新しいプロパティーを追加します。
-
configResolverは、Red Hat Single Sign-On アダプター設定を提供するリゾルバー Bean です。利用可能なリゾルバーは Configuration Resolvers セクションに記載されています。 -
allowedRolesはロールのコンマ区切りのリストです。サービスにアクセスするユーザーは、アクセスを許可するために少なくとも 1 つのロールが必要です。
以下に例を示します。
-
META-INF/MANIFEST.MFのImport-Packageには以下のインポートが含まれる必要があります。
2.1.7.6. Camel RestDSL リンクのコピーリンクがクリップボードにコピーされました!
Camel RestDSL は、REST エンドポイントを定義するのに使用される Camel 機能です。しかし、引き続き特定の実装クラスを使用し、Red Hat Single Sign-On との統合方法を説明します。
インテグレーションメカニズムを設定する方法は、RestDSL 定義のルートを設定する Camel コンポーネントに依存します。
以下の例は、undertow-keycloak コンポーネントを使用して統合を設定する方法を示しています。これには、上述の Blueprint の例で定義された一部の Bean への参照が含まれます。
2.1.7.7. 別の Undertow エンジンでの Apache CXF エンドポイントのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
別の Undertow エンジンで Red Hat Single Sign-On でセキュリティー保護された CXF エンドポイントを実行するには、以下の手順を実行します。
手順
OSGI-INF/blueprint/blueprint.xmlをアプリケーションに追加し、Camel 設定 と同様に適切な設定リゾルバー Bean を追加します。httpu:engine-factoryでは、camel 設定を使用したorg.keycloak.adapters.osgi.undertow.CxfKeycloakAuthHandlerハンドラーを宣言します。CFX JAX-WS アプリケーションの設定は以下のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow CXF JAX-RS アプリケーションの場合、唯一の違いは、エンジンファクトリーに依存するエンドポイントの設定にある可能性があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
META-INF/MANIFEST.MFのImport-Packageには、これらのインポートが含まれる必要があります。
2.1.7.8. デフォルトの Undertow エンジンでの Apache CXF エンドポイントのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
一部のサービスは、起動時にデプロイされたサーブレットが自動的に含まれる場合があります。このようなサービスの 1 つは、http://localhost:8181/cxf コンテキストで実行している CXF サーブレットです。Fuse の Pax Web は、設定 admin を使用した既存のコンテキストの変更をサポートします。これは、Red Hat Single Sign-On によるエンドポイントを保護するのに使用できます。
アプリケーション内の設定ファイル OSGI-INF/blueprint/blueprint.xml は、以下のようになります。アプリケーションへのエンドポイント固有の JAX-RS customerservice エンドポイントを追加することに注意してください。
${karaf.etc}/org.ops4j.pax.web.context-anyName.cfg ファイル を作成する必要があります。これは、pax-web-runtime バンドルによって追跡されるファクトリー PID 設定として処理されます。このような設定には、標準の web.xml のプロパティーの一部に対応する以下のプロパティーが含まれる場合があります。
設定管理ファイルで利用可能なプロパティーの完全な説明は、Fuse のドキュメントを参照してください。上記のプロパティーは以下の意味になります。
bundle.symbolicNameおよびcontext.id-
org.ops4j.pax.web.service.WebContainer内のバンドルおよびそのデプロイメントコンテキストを特定します。 context.param.keycloak.config.resolver-
keycloak.config.resolverコンテキストパラメーターの値を、従来の WAR のweb.xmlと同じバンドルに提供します。利用可能なリゾルバーは、設定リゾルバー を参照してください。 login.config.authMethod-
認証方法。
KEYCLOAKでなければなりません。 security.anyName.urlおよびsecurity.anyName.roles個別のセキュリティー制約のプロパティーの値は、
web.xmlのsecurity-constraint/web-resource-collection/url-patternおよびsecurity-constraint/auth-constraint/role-nameに設定されます。ロールは、コンマとその周囲の空白で区切られます。anyName識別子は任意ですが、同じセキュリティー制約の個別のプロパティーに一致する必要があります。注記一部の Fuse バージョンには、ロールを
", "(コンマと単一スペース) で区切る必要のあるバグが含まれています。ロールを分離するには、必ずこの表記を使用してください。
META-INF/MANIFEST.MF の Import-Package には、少なくとも以下のインポートが含まれている必要があります。
2.1.7.9. Fuse 管理サービスのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
2.1.7.9.1. Fuse ターミナルへの SSH 認証の使用 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On は、主に Web アプリケーションの認証のユースケースに対応しています。ただし、他の Web サービスおよびアプリケーションが Red Hat Single Sign-On で保護されている場合は、SSH などの非 Web 管理サービスを Red Hat Single Sign-On の認証情報で保護するのが最善の方法です。これは、Red Hat Single Sign-On へのリモート接続を可能にする JAAS ログインモジュールを使用して実行できます。また、リソース所有者のパスワード認証情報 に基づいて認証情報を検証できます。
SSH 認証を有効にするには、次の手順を実行します。
手順
-
Red Hat Single Sign-On では、SSH 認証に使用されるクライアント (
ssh-jmx-admin-clientなど) を作成します。このクライアントでは、Direct Access Grants EnabledをOnに選択する必要があります。 $FUSE_HOME/etc/org.apache.karaf.shell.cfgファイルで、以下のプロパティーを更新または指定します。sshRealm=keycloak
sshRealm=keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような内容で
$FUSE_HOME/etc/keycloak-direct-access.jsonファイルを追加します (環境と Red Hat Single Sign-On クライアント設定に基づきます)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルは、SSH 認証の JAAS レルム
keycloakから JAAS DirectAccessGrantsLoginModule によって使用されるクライアントアプリケーション設定を指定します。Fuse を起動し、
keycloakJAAS レルムをインストールします。最も簡単な方法は、JAAS レルムが事前定義されているkeycloak-jaas機能をインストールすることです。より高いランクの独自の JAAS レルムkeycloakを使用すると、機能の定義済みレルムをオーバーライドできます。詳細は、JBoss Fuse ドキュメント を参照してください。Fuse 端末で以下のコマンドを使用します。
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak-jaas
features:addurl mvn:org.keycloak/keycloak-osgi-features/18.0.18.redhat-00001/xml/features features:install keycloak-jaasCopy to Clipboard Copied! Toggle word wrap Toggle overflow 端末に以下を入力して、
adminユーザーとして SSH を使用してログインします。ssh -o PubkeyAuthentication=no -p 8101 admin@localhost
ssh -o PubkeyAuthentication=no -p 8101 admin@localhostCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
パスワード
passwordでログインします。
一部のオペレーティングシステムでは、SSH コマンドの -o オプション -o オプション -o HostKeyAlgorithms=+ssh-dss を使用する必要もあります。これは、後の SSH クライアントはデフォルトで ssh-dss アルゴリズムを使用できないためです。しかし、デフォルトでは JBoss Fuse 7.4.0 で現在使用されています。
ユーザーには、すべての操作を実行するためのレルムロール admin、または操作のサブセットを実行するための別のロール (たとえば、読み取り専用の Karaf コマンドのみを実行するようにユーザーを制限する viewer ロール) が必要であることに注意してください。利用可能なロールは $FUSE_HOME/etc/org.apache.karaf.shell.cfg または $FUSE_HOME/etc/system.properties で設定されます。
2.1.7.9.2. JMX 認証の使用 リンクのコピーリンクがクリップボードにコピーされました!
jconsole または他の外部ツールを使用して RMI 経由で JMX にリモートで接続する場合は、JMX 認証が必要な場合があります。jolokia エージェントはデフォルトで hawt.io にインストールされているため、hawt.io/jolokia を使用する方が良いでしょう。詳細は Hawtio 管理コンソール を参照してください。
JMX 認証を使用するには、次の手順を実行します。
手順
$FUSE_HOME/etc/org.apache.karaf.management.cfgファイルで、jmxRealm プロパティーを以下のように変更します。jmxRealm=keycloak
jmxRealm=keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
上記の SSH セクションで説明されているように、
keycloak-jaas機能をインストールして$FUSE_HOME/etc/keycloak-direct-access.jsonファイルを設定します。 - jconsole では、以下のような URL を使用できます。
service:jmx:rmi://localhost:44444/jndi/rmi://localhost:1099/karaf-root
service:jmx:rmi://localhost:44444/jndi/rmi://localhost:1099/karaf-root
および認証情報: admin/password (環境に応じて管理者権限を持つユーザーに基づきます)。
2.1.7.10. Hawtio 管理コンソールのセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On で Hawtio 管理コンソールのセキュリティーを保護するには、次の手順を実行します。
手順
-
レルムの Red Hat Single Sign-On 管理コンソールでクライアントを作成します。たとえば、Red Hat Single Sign-On の
demoレルムでは、クライアントhawtio-clientを作成し、アクセスタイプとしてpublicを指定し、Hawtio を参照するリダイレクト URI (http://localhost:8181/hawtio/*) を指定します。対応する Web Origin (この場合は http://localhost:8181) を設定します。hawtio-clientクライアント詳細の Scope タブにある account クライアントの view-profile クライアントロールを含むように、クライアントスコープマッピングを設定します。 以下の例のような内容を使用して、
$FUSE_HOME/etcディレクトリーにkeycloak-hawtio-client.jsonファイルを作成します。Red Hat Single Sign-On 環境に応じて、realm、resource、およびauth-server-urlプロパティーを変更します。resourceプロパティーは、前のステップで作成したクライアントを参照する必要があります。このファイルは、クライアント (Hawtio JavaScript アプリケーション) で使用されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のような内容を使用して、
$FUSE_HOME/etcディレクトリーにkeycloak-direct-access.jsonファイルを作成します。Red Hat Single Sign-On 環境に応じて、realmプロパティーおよびurlプロパティーを変更します。このファイルは JavaScript クライアントによって使用されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のような内容を使用して、
$FUSE_HOME/etcディレクトリーにkeycloak-hawtio.jsonファイルを作成します。Red Hat Single Sign-On 環境に応じて、realmプロパティーおよびauth-server-urlプロパティーを変更します。このファイルは、サーバーのアダプター (JAAS ログインモジュール) 側で使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow JBoss Fuse 7.4.0 を起動し、Keycloak 機能をインストール します。次に、Karaf ターミナルで以下を入力します。
system:property -p hawtio.keycloakEnabled true system:property -p hawtio.realm keycloak system:property -p hawtio.keycloakClientConfig file://\${karaf.base}/etc/keycloak-hawtio-client.json system:property -p hawtio.rolePrincipalClasses org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipal restart io.hawt.hawtio-warsystem:property -p hawtio.keycloakEnabled true system:property -p hawtio.realm keycloak system:property -p hawtio.keycloakClientConfig file://\${karaf.base}/etc/keycloak-hawtio-client.json system:property -p hawtio.rolePrincipalClasses org.keycloak.adapters.jaas.RolePrincipal,org.apache.karaf.jaas.boot.principal.RolePrincipal restart io.hawt.hawtio-warCopy to Clipboard Copied! Toggle word wrap Toggle overflow http://localhost:8181/hawtio にアクセスし、Red Hat Single Sign-On レルムからユーザーとしてログインします。
Hawtio に対して正常に認証するには、適切なレルムロールが必要です。利用可能なロールは、
hawtio.rolesの$FUSE_HOME/etc/system.propertiesファイルで設定されます。
2.1.8. Spring Boot アダプター リンクのコピーリンクがクリップボードにコピーされました!
Spring Boot アダプターは非推奨となり、RH-SSO の 8.0 以降のバージョンには含まれません。このアダプターは、RH-SSO 7.x のライフサイクル期間、メンテナンスされます。ユーザーは Spring Security に移行して、Spring Boot アプリケーションを RH-SSO と統合する必要があります。
2.1.8.1. Spring Boot アダプターのインストール リンクのコピーリンクがクリップボードにコピーされました!
Spring Boot アプリケーションのセキュリティーを保護するには、Keycloak Spring Boot アダプター JAR をアプリケーションに追加する必要があります。その後、通常の Spring Boot 設定 (application.properties) を使用して追加の設定を提供する必要があります。
Keycloak Spring Boot アダプターは Spring Boot の自動設定を活用するため、このアダプター Keycloak Spring Boot スターターをプロジェクトに追加する必要があります。
手順
Maven を使用してスターターをプロジェクトに追加するには、以下を依存関係に追加します。
<dependency> <groupId>org.keycloak</groupId> <artifactId>keycloak-spring-boot-starter</artifactId> </dependency><dependency> <groupId>org.keycloak</groupId> <artifactId>keycloak-spring-boot-starter</artifactId> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow アダプター BOM 依存関係を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在、以下の埋め込みコンテナーはサポートされており、Starter の使用時には追加の依存関係は必要ありません。
- Tomcat
- Undertow
- Jetty
2.1.8.2. Spring Boot アダプターの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、Red Hat Single Sign-On を使用するように Spring Boot アプリケーションを設定します。
手順
keycloak.jsonファイルの代わりに、通常の Spring Boot 設定を介して Spring Boot アダプターのレルムを設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow keycloak.enabled = falseを設定して、Keycloak Spring Boot Adapter (テストなど) を無効できます。-
Policy Enforcer を設定するには、keycloak.json とは異なり、
policy-enforcerではなくpolicy-enforcer-configを使用します。 通常
web.xmlにある Java EE セキュリティー設定を指定します。Spring Boot Adapter は
login-methodをKEYCLOAKに設定し、起動時にsecurity-constraintsを設定します。以下は、設定例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Spring アプリケーションを WAR としてデプロイする予定の場合は、Spring Boot アダプターを使用せず、使用しているアプリケーションサーバーまたはサーブレットコンテナーの専用アダプターを使用してください。Spring Boot には web.xml ファイルも含まれている必要があります。
2.1.9. Java サーブレットフィルターアダプター リンクのコピーリンクがクリップボードにコピーされました!
Java Servlet アプリケーションをプラットフォームにデプロイする場合は、Red Hat Single Sign-On アダプターがないため、サーブレットフィルターアダプターを使用できます。このアダプターは、他のアダプターとは異なります。web.xml ではセキュリティー制約を定義しません。代わりに、Red Hat Single Sign-On サーブレットフィルターアダプターを使用してフィルターマッピングを定義し、セキュリティーを保護する url パターンを保護します。
Backchannel ログアウトの動作は、標準アダプターとは少々異なります。HTTP セッションを無効にする代わりに、セッション ID をログアウトとしてマークします。セッション ID に基づいて HTTP セッションを無効にする標準的な方法はありません。
上記のスニペットには、url-patterns が 2 つあります。/protected/* は保護する必要のあるファイルですが、/keycloak/* url-pattern は Red Hat Single Sign-On サーバーからコールバックを処理します。
設定された url-patterns の 下の一部のパスを除外する必要がある場合は、フィルターの init パラメーター keycloak.config.skipPattern を使用して、keycloak フィルターがフィルターチェーンにすぐに委譲するパスパターンを記述する正規表現を設定できます。デフォルトでは skipPattern が設定されていません。
パターンは、context-path なしで requestURI に対して一致します。コンテキストパス /myapp を指定すると、/myapp/index.html のリクエストはスキップパターンに対して /index.html と照合されます。
<init-param>
<param-name>keycloak.config.skipPattern</param-name>
<param-value>^/(path1|path2|path3).*</param-value>
</init-param>
<init-param>
<param-name>keycloak.config.skipPattern</param-name>
<param-value>^/(path1|path2|path3).*</param-value>
</init-param>
フィルターの url-pattern で対応しているセキュアなセクションを参照する管理 URL を使用して、Red Hat Single Sign-On 管理コンソールでクライアントを設定する必要があります。
管理 URL は、バックチャネルログアウトなどを行うための管理 URL へのコールバックを作成します。この例の管理 URL は http[s]://hostname/{context-root}/keycloak となります。
セッション ID マッパーをカスタマイズする必要がある場合は、フィルター init-param keycloak.config.idMapper でクラスの完全修飾名を設定できます。セッション ID マッパーは、ユーザー ID とセッション ID のマップに使用されるマッパーです。デフォルトでは、org.keycloak.adapters.spi.InMemorySessionIdMapper が設定されています。
<init-param>
<param-name>keycloak.config.idMapper</param-name>
<param-value>org.keycloak.adapters.spi.InMemorySessionIdMapper</param-value>
</init-param>
<init-param>
<param-name>keycloak.config.idMapper</param-name>
<param-value>org.keycloak.adapters.spi.InMemorySessionIdMapper</param-value>
</init-param>
Red Hat Single Sign-On フィルターには、他のアダプターと同じ設定パラメーターがあります。ただし、コンテキストパラメーターではなく、フィルター init パラメーターとして定義する必要があります。
このフィルターを使用するには、この maven アーティファクトを WAR pom に組み込みます。
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-servlet-filter-adapter</artifactId>
<version>18.0.18.redhat-00001</version>
</dependency>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-servlet-filter-adapter</artifactId>
<version>18.0.18.redhat-00001</version>
</dependency>
2.1.10. セキュリティーコンテキスト リンクのコピーリンクがクリップボードにコピーされました!
KeycloakSecurityContext インターフェイスは、トークンに直接アクセスする必要がある場合に利用できます。これは、トークン (ユーザープロファイル情報など) から追加情報を取得する場合や、Red Hat Single Sign-On が保護する RESTful サービスを呼び出す場合に便利です。
サーブレット環境では、HttpServletRequest の属性としてセキュアな呼び出しを利用できます。
httpServletRequest
.getAttribute(KeycloakSecurityContext.class.getName());
httpServletRequest
.getAttribute(KeycloakSecurityContext.class.getName());
または、HttpSession のセキュアでない要求で利用できます。
httpServletRequest.getSession()
.getAttribute(KeycloakSecurityContext.class.getName());
httpServletRequest.getSession()
.getAttribute(KeycloakSecurityContext.class.getName());
2.1.11. エラー処理 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On には、サーブレットベースのクライアントアダプターに対するエラー処理機能があります。認証でエラーが発生した場合、Red Hat Single Sign-On は HttpServletResponse.sendError() を呼び出します。web.xml ファイル内にエラーページを設定して、必要なエラーを処理できます。Red Hat Single Sign-On は 400、401、403、および 500 のエラーを出力できます。
<error-page>
<error-code>403</error-code>
<location>/ErrorHandler</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>/ErrorHandler</location>
</error-page>
Red Hat Single Sign-On は、取得可能な HttpServletRequest 属性も設定します。属性名は org.keycloak.adapters.spi.AuthenticationError で、org.keycloak.adapters.OIDCAuthenticationError にキャストする必要があります。
以下に例を示します。
2.1.12. ログアウト リンクのコピーリンクがクリップボードにコピーされました!
Web アプリケーションからログアウトするには、複数の方法でログアウトできます。Jakarta EE サーブレットコンテナーでは、HttpServletRequest.logout() を呼び出すことができます。他のブラウザーアプリケーションの場合は、ブラウザーを http://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout にリダイレクトできます。これは、ユーザーのブラウザーに SSO セッションがある場合にユーザーをログアウトします。実際のログアウトは、ユーザーがログアウトを確認すると行われます。OpenID Connect RP-Initiated Logout で説明されているように、オプションで id_token_hint、post_logout_redirect_uri、client_id などのパラメーターを含めることができます。そのため、id_token_hint パラメーターを指定すると、ログアウトを明示的に確認する必要はありません。ログアウト後、指定された post_logout_redirect_uri が提供されている限り、ユーザーは自動的にリダイレクトされます。post_logout_redirect_uri が含まれている場合には、client_id または id_token_hint パラメーターのいずれかを含める必要があります。
ログアウト処理の一部として外部 ID プロバイダーからのログアウトを回避したい場合は、パラメーター initiating_idp を指定して、値を問題の ID プロバイダーの ID (エイリアス) にすることができます。このパラメーターは、ログアウトエンドポイントが外部アイデンティティープロバイダーによって開始される単一ログアウトの一部として呼び出される場合に便利です。パラメーター initiating_idp は、RP-Initiated Logout 仕様で説明されているパラメーターに加えて、Red Hat Single Sign-On ログアウトエンドポイントのサポートされるパラメーターです。
HttpServletRequest.logout() オプションを使用する場合、アダプターは更新トークンを渡す Red Hat Single Sign-On サーバーに対してバックチャンネル POST 呼び出しを実行します。保護されていないページ (有効なトークンを確認しないページ) からメソッドが実行されると、更新トークンは利用できません。その場合、アダプターは呼び出しをスキップします。このため、現在のトークンが常に考慮され、必要に応じて Red Hat Single Sign-On server サーバーとの対話が実行されるように、保護されたページを使用して HttpServletRequest.logout() を実行することが推奨されます。
2.1.13. パラメーター転送 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On の初期認可エンドポイントリクエストでは、さまざまなパラメーターがサポートされます。ほとんどのパラメーターは、OIDC 仕様 に記載されています。一部のパラメーターは、アダプター設定に基づいてアダプターによって自動的に追加されます。ただし、呼び出しごとに追加できるパラメーターはいくつかあります。セキュアなアプリケーション URI を開くと、特定のパラメーターは Red Hat Single Sign-On 認可エンドポイントに転送されます。
例えば、オフライントークンを要求する場合は、次のように scope パラメーターを指定してセキュアなアプリケーションの URI を開くことができます。
http://myappserver/mysecuredapp?scope=offline_access
http://myappserver/mysecuredapp?scope=offline_access
およびパラメーター scope=offline_access を指定すると、Red Hat Single Sign-On 認可エンドポイントに自動的に転送されます。
サポートされるパラメーターは以下のとおりです。
-
scope - スコープのスペースで区切られたリストを使用します。スペースで区切られたリストは、通常、特定のクライアントで定義された クライアントスコープ を参照します。スコープの
openidは、アダプターによって常にスコープのリストに追加されることに注意してください。例えば、スコープオプションのaddress phoneを入力すると、Red Hat Single Sign-On へのリクエストにはスコープパラメーターscope=openid address phoneが含まれます。 prompt - Red Hat Single Sign-On では、以下の設定がサポートされます。
-
login- SSO は無視され、ユーザーがすでに認証済みであっても Red Hat Single Sign-On ログインページが常に表示されます。 -
consent-同意が必要なクライアントにのみ適用されます。これを使用すると、ユーザーが以前にこのクライアントに同意した場合でも、Consent ページが常に表示されます。 -
none- ログインページは表示されません。その代わりに、ユーザーはアプリケーションにリダイレクトされ、ユーザーが認証されていない場合はエラーが表示されます。この設定により、アプリケーション側でフィルター/インターセプターを作成し、ユーザーにカスタムのエラーページを表示できます。詳細は、仕様を参照してください。
-
-
max_age - ユーザーがすでに認証されている場合にのみ使用します。認証が永続する最大時間を指定します。ユーザーの認証時から測定されます。ユーザーが
maxAgeより長く認証されると、SSO は無視され、再認証が必要となります。 - login_hint - ログインフォームの username/email フィールドを事前に入力するのに使用されます。
- kc_idp_hint - Red Hat Single Sign-On に対して、ログインページの表示をスキップし、指定のアイデンティティープロバイダーに自動的にリダイレクトするために使用されます。詳細は、Identity Provider のドキュメント を参照してください。
ほとんどのパラメーターは、OIDC 仕様 に記載されています。唯一の例外は kc_idp_hint パラメーターで、これは Red Hat Single Sign-On に固有のもので、自動的に使用する ID プロバイダーの名前が含まれています。詳細は、Server Administration Guideの Identity Brokering のセクションを参照してください。
割り当てられたパラメーターを使用して URL を開くと、アダプターはアプリケーションで認証されている場合に Red Hat Single Sign-On にリダイレクトしません。たとえば、http://myappserver/mysecuredapp?prompt=login を開いても、アプリケーション mysecuredapp に対して認証済みの場合は、Red Hat Single Sign-On のログインページに自動的にリダイレクトされません。この動作は今後変更される可能性があります。
2.1.14. クライアント認証 リンクのコピーリンクがクリップボードにコピーされました!
機密 OIDC クライアントがバックチャネル要求を送信する必要がある場合 (トークンのコードを交換したり、トークンを更新する場合など)、Red Hat Single Sign-On サーバーに対して認証する必要があります。デフォルトでは、クライアント ID およびクライアントシークレット、署名済み JWT によるクライアント認証、またはクライアントシークレットを使用した署名済み JWT によるクライアント認証の 3 つの方法があります。
2.1.14.1. クライアント ID およびクライアントシークレット リンクのコピーリンクがクリップボードにコピーされました!
これは、OAuth2 仕様で説明されている従来の方法です。クライアントには、アダプター (アプリケーション) サーバーと Red Hat Single Sign-On サーバーの両方を認識する必要があるシークレットがあります。Red Hat Single Sign-On 管理コンソールで特定のクライアントのシークレットを生成し、このシークレットをアプリケーション側の keycloak.json ファイルに貼り付けることができます。
"credentials": {
"secret": "19666a4f-32dd-4049-b082-684c74115f28"
}
"credentials": {
"secret": "19666a4f-32dd-4049-b082-684c74115f28"
}
2.1.14.2. 署名済み JWT によるクライアント認証 リンクのコピーリンクがクリップボードにコピーされました!
これは RFC7523 の仕様に基づいています。これは、以下のように動作します。
-
クライアントには、秘密鍵と証明書が必要です。Red Hat シングルサインオンでは、クライアントアプリケーションのクラスパスかファイルシステムのどこかにある従来の
keystoreファイルから利用できます。 - クライアントアプリケーションを起動すると、がクライアントアプリケーションのベース URL であると仮定して、http://myhost.com/myapp/k_jwks のような URL を使用して JWKS 形式で公開鍵をダウンロードすることができます。この URL は Red Hat Single Sign-On で使用できます (下記参照)。
-
認証中、クライアントは JWT トークンを生成し、その秘密鍵で署名し、
client_assertionパラメーターの特定のバックチャンネル要求 (たとえば、code-to-token 要求) で Red Hat Single Sign-On に送信します。 Red Hat Single Sign-On には、JWT で署名を検証できるように、クライアントの公開鍵または証明書が必要です。Red Hat Single Sign-On では、クライアントの認証情報を設定する必要があります。まず、管理コンソールの
Credentialsタブで、クライアントの認証方法としてSigned JWTを選択する必要があります。次に、タブKeysで、以下のいずれかを選択できます。-
Red Hat Single Sign-On がクライアントの公開鍵をダウンロードできる JWKS URL を設定します。これは、http://myhost.com/myapp/k_jwks などの URL を指定できます (詳細は上記を参照してください)。クライアントはキーをいつでもローテーションできるため、このオプションは最も柔軟性の高いものであり、Red Hat Single Sign-On は設定を変更しなくても、必要に応じていつでも新しいキーをダウンロードします。より正確には、Red Hat Single Sign-On は、未知の
kid(キー ID) 署名したトークンを見つけると、新しいキーをダウンロードします。 - クライアントの公開鍵または証明書を、PEM 形式、JWK 形式、またはキーストアからアップロードします。このオプションを使用すると、公開鍵はハードコーディングされ、クライアントが新しいキーペアを生成する際に変更する必要があります。自分自身が利用可能でない場合は、Red Hat Single Sign-On の管理コンソールから独自のキーストアを生成することもできます。Red Hat Single Sign-On 管理コンソールの設定方法の詳細は、Server Administration Guide を参照してください。
-
Red Hat Single Sign-On がクライアントの公開鍵をダウンロードできる JWKS URL を設定します。これは、http://myhost.com/myapp/k_jwks などの URL を指定できます (詳細は上記を参照してください)。クライアントはキーをいつでもローテーションできるため、このオプションは最も柔軟性の高いものであり、Red Hat Single Sign-On は設定を変更しなくても、必要に応じていつでも新しいキーをダウンロードします。より正確には、Red Hat Single Sign-On は、未知の
アダプター側で設定するには、keycloak.json ファイルに以下のようなものを記述する必要があります。
この設定では、WAR のクラスパスに keystore-client.jks というキーストアファイルがある必要があります。接頭辞 classpath: を使用しない場合は、クライアントアプリケーションが実行しているファイルシステム上の任意のファイルを指定できます。
algorithm フィールドは、署名済み JWT に使用されるアルゴリズムを指定し、デフォルトは RS256 です。このフィールドは、キーペアと同期する必要があります。たとえば、RS256 アルゴリズムには RSA 鍵ペアが必要で、ES256 アルゴリズムには EC キーペアが必要です。詳細は、Cryptographic Algorithms for Digital Signatures and MACs を参照してください。
2.1.15. マルチテナンシー リンクのコピーリンクがクリップボードにコピーされました!
この場合、複数の Red Hat Single Sign-On レルムを使用して、1 つのターゲットアプリケーション (WAR) をセキュアにできることを意味します。レルムは、同じ Red Hat Single Sign-On インスタンスまたは別のインスタンスに配置できます。
実際には、これはアプリケーションが複数の keycloak.json アダプター設定ファイルを持つ必要があることを意味します。
異なるアダプター設定ファイルが異なるコンテキストパスにデプロイされた WAR の複数のインスタンスを持つことができます。しかし、これは不便である可能性があります。また、context-path 以外の項目に基づいてレルムを選択することもできます。
Red Hat Single Sign-On では、カスタム設定リゾルバーを設定して、リクエストごとに使用するアダプター設定を選択できるようになります。
これを実現するには、まず org.keycloak.adapterers.KeycloakConfigResolver の実装を作成する必要があります。以下に例を示します。
また、どの KeycloakConfigResolver 実装を web.xml のコンテキストパラメーター keycloak.config.resolver で使用するかを設定する必要があります。
2.1.16. アプリケーションクラスタリング リンクのコピーリンクがクリップボードにコピーされました!
本章では、JBoss EAP にデプロイされたクラスター化されたアプリケーションのサポートに関連します。
アプリケーションが次のいずれであるかに応じて、いくつかのオプションを利用できます。
- ステートレスまたはステートフル
- 分散可能 (複製可能 http セッション) または非分散可能
- ロードバランサーが提供するスティッキーセッションへの依存
- Red Hat Single Sign-On と同じドメインでホストされる
クラスタリングの処理は、通常のアプリケーションほど単純ではありません。主に、ブラウザーとサーバー側のアプリケーションがリクエストを Red Hat Single Sign-On に送信するため、ロードバランサーでスティッキーセッションを有効にするのは単純ではありません。
2.1.16.1. ステートレストークンストア リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Single Sign-On によってセキュア化された web アプリケーションは HTTP セッションを使用してセキュリティーコンテキストを保存します。つまり、スティッキーセッションを有効にするか、HTTP セッションを複製する必要があります。
HTTP セッションにセキュリティーコンテキストを保存する代わりに、アダプターを設定して Cookie にこれを保存するように設定できます。これは、アプリケーションをステートレスにしたい場合、またはセキュリティーコンテキストを HTTP セッションに保存したくない場合に役立ちます。
セキュリティーコンテキストの保存に cookie ストアを使用するには、アプリケーションの WEB-INF/keycloak.json を 編集して、以下を追加してください。
"token-store": "cookie"
"token-store": "cookie"
token-store のデフォルト値は session で、HTTP セッションにセキュリティーコンテキストを保存します。
クッキーストアを使用する 1 つの制限は、すべての HTTP リクエストに対してセキュリティーコンテキスト全体がクッキーに渡されることです。これにより、パフォーマンスに影響する可能性があります。
別の小さな制限については、Single-Sign Out のサポートは限定されています。アダプターにより KEYCLOAK_ADAPTER_STATE cookie が削除されるため、アプリケーション自体からの init servlet logout (HttpServletRequest.logout) がアプリケーション自体からも問題なく機能します。ただし、別のアプリケーションから初期化されたバックチャネルログアウトは、cookie ストアを使用して Red Hat Single Sign-On によって伝播されません。そのため、アクセストークンのタイムアウトに short 値を使用することが推奨されます (例: 1 分)。
一部のロードバランサーでは、Amazon ALB などのスティッキーセッション cookie 名またはコンテンツの設定は許可されません。これらの場合は、shouldAttachRoute オプションを false に設定することが推奨されます。
2.1.16.2. 相対 URI の最適化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On およびアプリケーションが同じドメイン (リバースプロキシーまたはロードバランサー経由) でホストされるデプロイメントシナリオでは、クライアント設定で相対 URI オプションを使用すると便利です。
相対 URI を使用すると、URI は Red Hat Single Sign-On へのアクセスに使用する URL と相対的に解決されます。
例えば、アプリケーションの URL が https://acme.org/myapp で、Red Hat Single Sign-On の URL が https://acme.org/auth の場合は、https://acme.org/myapp 代わりに redirect-uri /myapp を使用できます。
2.1.16.3. 管理 URL の設定 リンクのコピーリンクがクリップボードにコピーされました!
特定のクライアントの管理者 URL は、Red Hat Single Sign-On の管理コンソールで設定できます。これは、Red Hat Single Sign-On サーバーが、ユーザーのログアウトや失効ポリシーのプッシュなどのさまざまなタスクのためにアプリケーションにバックエンドリクエストを送信するのに使用されます。
たとえば、バックチャネルログアウトの仕組みは以下のようになります。
- ユーザーが 1 つのアプリケーションからログアウトリクエストを送信します。
- アプリケーションはログアウトリクエストを Red Hat Single Sign-On に送信します。
- Red Hat Single Sign-On サーバーは、ユーザーセッションを無効にします。
- 次に、Red Hat Single Sign-On サーバーは、セッションに関連付けられた管理 URL を持つアプリケーションにバックチャネルリクエストを送信します。
- アプリケーションがログアウトリクエストを受け取ると、対応する HTTP セッションが無効になります。
管理の URL に ${application.session.host} が含まれている場合は、HTTP セッションに関連するノードの URL に置き換えられます。
2.1.16.4. アプリケーションノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
前のセクションでは、Red Hat Single Sign-On が特定の HTTP セッションに関連付けられたノードにログアウトリクエストを送信する方法を説明します。ただし、場合によっては、管理者は、管理タスクを 1 つだけでなく、登録されているすべてのクラスターノードに伝達したいことがあります。たとえば、新しい not before ポリシーをアプリケーションにプッシュしたり、アプリケーションからすべてのユーザーをログアウトしたりするには、以下を実行します。
この場合、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 でも登録が解除されます。これは通常、ノードのシャットダウンまたはアプリケーションのアンデプロイメント中に行われます。これは、アンデプロイメントリスナーが呼び出されていない場合に強制シャットダウンが適切に動作しないため、自動登録解除が必要になります。
一部のクラスターアプリケーションでのみ必要であるため、起動登録および定期的な再登録はデフォルトでは無効になっています。
この機能を有効にするには、アプリケーションの WEB-INF/keycloak.json ファイルを編集し、以下を追加します。
"register-node-at-startup": true, "register-node-period": 600,
"register-node-at-startup": true,
"register-node-period": 600,
これは、アダプターが起動時に登録要求を送信し、10 分ごとに再登録します。
Red Hat Single Sign-On 管理コンソールでは、ノード再登録タイムアウトの最大数を指定できます (アダプター設定の register-node-period よりも大きくする必要があります)。管理コンソールを使用してクラスターノードを手動で追加および削除することもできます。これは、自動登録機能に依存したくない場合、または自動登録解除機能を使用せずに古いアプリケーションノードを削除する場合に便利です。
2.1.16.5. 各リクエストでトークンを更新する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、アプリケーションアダプターは、有効期限が切れている場合にのみアクセストークンを更新します。ただし、すべてのリクエストでトークンを更新するようにアダプターを設定することもできます。アプリケーションが Red Hat Single Sign-On サーバーにより多くのリクエストを送信するため、パフォーマンスに影響する可能性があります。
この機能を有効にするには、アプリケーションの WEB-INF/keycloak.json ファイルを編集し、以下を追加します。
"always-refresh-token": true
"always-refresh-token": true
これは、パフォーマンスに大きく影響することがあります。ポリシーの前にログアウトを伝播するのにバックチャネルメッセージに依存しない場合にのみ、この機能を有効にします。考慮すべきもう 1 つの点は、デフォルトではアクセストークンの有効期限が短いため、ログアウトが伝播されなくても、トークンはログアウトから数分以内に有効期限が切れることです。